По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
Нормализация базы данных (БД) - это метод проектирования реляционных БД, который помогает правильно структурировать таблицы данных. Процесс направлен на создание системы с четким представлением информации и взаимосвязей, без избыточности и потери данных. В данной статье рассказывается, что такое нормализация базы данных, и объясняются принципы ее работы на практическом примере. Что такое нормализация базы данных? Нормализация базы данных - это метод создания таблиц БД со столбцами и ключами путем разделения (или декомпозиции) таблицы большего размера на небольшие логические единицы. В данном методе учитываются требования, предъявляемые к среде БД. Нормализация - это итеративный процесс. Как правило, нормализация БД выполняется через серию тестов. Каждый последующий шаг разбивает таблицу на более легкую в управлении информацию, чем повышается общая логичность системы и простота работы с ней. Зачем нужна нормализация базы данных? Нормализация позволяет разработчику БД оптимально распределять атрибуты по таблицам. Данная методика избавляет от: атрибутов с несколькими значениями; задвоения или повторяющихся атрибутов; атрибутов, не поддающихся классификации; атрибутов с избыточной информацией; атрибутов, созданных из других признаков. Необязательно выполнять полную нормализацию БД. Однако она гарантирует полноценно функционирующую информационную среду. Этот метод: позволяет создать структуру базы данных, подходящую для общих запросов; сводит к минимуму избыточность данных, что повышает эффективность использования памяти на сервере БД; гарантирует максимальную целостность данных, устраняя аномалий вставки, обновления и удаления. Нормализация базы данных преобразует общую целостность данных в удобную для пользователя среду. Избыточность баз данных и аномалии Когда вы вносите изменения в таблицу избыточностью, вам придется корректировать все повторяющиеся экземпляры данных и связанные с ними объекты. Если этого не сделать, то таблица станет несогласованной, и при внесении изменений возникнут аномалии. Так выглядит таблица без нормализации: Для таблицы характерна избыточность данных, а при изменении этих данных возникают 3 аномалии: Аномалия вставки. При добавлении нового «Сотрудника» (employee) в «Отдел» (sector) Finance, обязательно указывается его «Руководитель» (manager). Иначе вы не сможете вставить данные в таблицу. Аномалия обновления. Когда сотрудник переходит в другой отдел, поле «Руководитель» содержит ошибочные данные. К примеру, Джейкоб (Jacob) перешел в отдел Finance, но его руководителем по-прежнему показывается Адам (Adam). Аномалия удаления. Если Джошуа (Joshua) решит уволиться из компании, то при удалении строки с его записью потеряется информация о том, что отдел Finance вообще существует. Для устранения подобных аномалий используется нормализация базы данных. Основные понятия в нормализации базы данных Простейшие понятия, используемые в нормализации базы данных: ключи - атрибуты столбцов, которые однозначно (уникально) определяют запись в БД; функциональные зависимости - ограничения между двумя взаимосвязанными атрибутами; нормальные формы - этапы для достижения определенного качества БД. Нормальные формы базы данных Нормализация базы данных выполняется с помощью набора правил. Такие правила называются нормальными формами. Основная цель данных правил - помочь разработчику БД в достижении нужного качества реляционной базы. Все уровни нормализации считаются кумулятивными, или накопительными. Прежде чем перейти к следующему этапу, выполняются все требования к текущей форме. Стадии нормализации: Стадия Аномалии избыточности Ненормализованная (нулевая) форма (UNF) Это состояние перед любой нормализацией. В таблице присутствуют избыточные и сложные значения Первая нормальная форма (1NF) Разбиваются повторяющиеся и сложные значения; все экземпляры становятся атомарными Вторая нормальная форма (2NF) Частичные зависимости разделяются на новые таблицы. Все строки функционально зависимы от первичного ключа Третья нормальная форма (3NF) Транзитивные зависимости разбиваются на новые таблицы. Не ключевые атрибуты зависят от первичного ключа Нормальная форма Бойса-Кода (BCNF) Транзитивные и частичные функциональные зависимости для всех потенциальных ключей разбиваются на новые таблицы Четвертая нормальная форма (4NF) Удаляются многозначные зависимости Пятая нормальная форма (5NF) Удаляются JOIN-зависимости (зависимости соединения) База данных считается нормализованной после достижения третьей нормальной формы. Дальнейшие этапы нормализации усложняю структуру БД и могут нарушить функционал системы. Что такое Ключ? Ключ БД (key) - это атрибут или группа признаков, которые однозначно описывают сущность в таблице. В нормализации используются следующие типы ключей: суперключ (Super Key) - набор признаков, которые уникально определяют каждую запись в таблице; потенциальный ключ (Candidate Key) - выбирается из набора суперключей с минимальным количеством полей; первичный ключ (Primary Key) - самый подходящий кандидат из набора потенциальных ключей; служит первичным ключом таблицы; внешний ключ (Foreign Key) - первичный ключ другой таблицы; составной ключ (Composite Key) - уникальный ключ, образованный двумя и более атрибутами, каждый из которых по отдельности не является ключом. Поскольку таблицы разделяются на несколько более простых единиц, именно ключи определяют точку ссылки для объекта БД. Например, в следующей структуре базы данных: Примерами суперключей являются: employeeID; (employeeID, name); email Все суперключи служат уникальным идентификатором каждой строки. К примеру, имя сотрудника и его возраст не считаются уникальными идентификаторами, поскольку несколько людей могут быть тезками и одногодками. Потенциальные ключи выбираются из набора суперключей с минимальным количеством полей. В нашем примере это: employeeID; email Оба параметра содержат минимальное количество полей, поэтому они хорошо подходят на роль потенциальных ключей. Самый логичный выбор для первичного ключа - поле employeeID, поскольку почта сотрудника может измениться. На такой первичный ключ легко ссылаться в другой таблице, для которой он будет считаться внешним ключом. Функциональные зависимости базы данных Функциональная зависимость БД отражает взаимосвязь между двумя атрибутами таблицы. Функциональные зависимости бывают следующих типов: тривиальная функциональная зависимость - зависимость между атрибутом и группой признаков; исходный элемент является частью группы; нетривиальная функциональная зависимость - зависимость между атрибутом и группой признаков; признак не является частью группы; транзитивная зависимость - функциональная зависимость между тремя атрибутами: второй атрибут зависит от первого, а третий - от второго. Благодаря транзитивности, третий атрибут зависит от первого; многозначная зависимость - зависимость, в которой несколько значений зависят от одного атрибута. Функциональные зависимости - это важный этап в нормализации БД. В долгосрочной перспективе такие зависимости помогают оценить общее качество базы данных. Примеры нормализации базы данных. Как нормализовать базу данных? Общие этапы в нормализации базы данных подходят для всех таблиц. Конкретные методы разделения таблицы, а также вариант прохождения или не прохождения через третью нормальную форму (3NF) зависят от примеров использования. Пример ненормализованной базы данных В одном столбце ненормализованной таблицы содержится несколько значений. В худшем случае в ней присутствует избыточная информация. Например: Добавление, обновление и удаление данных - все это сложные задачи. Выполнение любых изменений текущих данных сопряжено с высоким риском потери информации. Шаг 1: Первая нормальная форма (1NF) Для преобразования таблицы в первую нормальную форму значения полей должны быть атомарными. Все сложные сущности таблицы разделяются на новые строки или столбцы. Чтобы не потерять информацию, для каждого сотрудника дублируются значения столбцов managerID, managerName и area. Доработанная таблица соответствует первой нормальной форме. Шаг 2: Вторая нормальная форма (2NF) Во второй нормальной форме каждая строка таблицы должна зависеть от первичного ключа. Чтобы таблица соответствовала критериям этой формы, ее необходимо разделить на 2 части: Manager (managerID, managerName, area) Employee (employeeID, employeeName, managerID, sectorID, sectorName) Итоговая таблица во второй нормальной форме представляет собой 2 таблицы без частичных зависимостей. Шаг 3: третья нормальная форма (3NF) Третья нормальная форма разделяет любые транзитивные функциональные зависимости. В нашем примере транзитивная зависимость есть у таблицы Employee; она разбивается на 2 новых таблицы: Employee (employeeID, employeeName, managerID, sectorID) Sector (sectorID, sectorName) Теперь таблица соответствует третьей нормальной форме с тремя взаимосвязями. Конечная структура выглядит так: Теперь база данных считается нормализованной. Дальнейшая нормализация зависит от ваших конкретных целей. Заключение В статье рассказывалось, как с помощью нормализации БД можно сократить избыточность информации. В долгосрочной перспективе нормализация БД позволяет свести к минимуму потерю данных и улучшить их общую структуру. Если же вы хотите повысить производительность доступа к данным, то воспользуйтесь денормализацией БД. А если вы испытываете трудности с нормализацией базы данных, то рассмотрите возможность перехода на другой тип БД.
img
В этой первой части статьи мы сначала рассмотрим некоторые методы обслуживания сетей. Существуют различные модели, которые помогут вам поддерживать ваши сети и сделать вашу жизнь проще. Во второй части статьи мы рассмотрим некоторые теоретические модели, которые помогут вам в устранении неполадок. Ну что давайте начнем рассматривать техническое обслуживании сети! Обслуживание сети в основном означает, что вы должны делать все необходимое для поддержания сети в рабочем состоянии, и это включает в себя ряд задач: Устранение неполадок в сети; Установка и настройка аппаратного и программного обеспечения; Мониторинг и повышение производительности сети; Планирование будущего расширения сети; Создание сетевой документации и поддержание ее в актуальном состоянии; Обеспечение соблюдения политики компании; Обеспечение соблюдения правовых норм; Обеспечение безопасности сети от всех видов угроз. Конечно, этот список может отличаться для каждой сети, в которой вы работаете. Все эти задачи можно выполнить следующим образом: Структурированные задачи; Interrupt-driven задачи. Структурированный означает, что у вас есть заранее определенный план обслуживания сети, который гарантирует, что проблемы будут решены до того, как они возникнут. Как системному администратору, это сделает жизнь намного проще. Управляемый прерыванием означает, что вы просто ждете возникновения проблемы, а затем исправляете ее так быстро, как только можете. Управляемый прерыванием подход больше похож на подход "пожарного" ...вы ждете, когда случится беда, а затем пытаетесь решить проблему так быстро, как только можете. Структурированный подход, при котором у вас есть стратегия и план обслуживания сети, сокращает время простоя и является более экономичным. Конечно, вы никогда не сможете полностью избавиться от Interrupt-driven, потому что иногда все "просто идет не так", но с хорошим планом мы можем точно сократить количество задач, управляемых прерываниями. Вам не нужно думать о модели обслуживания сети самостоятельно. Есть ряд хорошо известных моделей обслуживания сети, которые используются сетевыми администраторами. Лучше всего использовать одну из моделей, которая лучше всего подходит для вашей организации и подкорректировать, если это необходимо. Вот некоторые из известных моделей обслуживания сети: FCAPS: Управление неисправностями. Управление конфигурацией. Управление аккаунтингом. Управление производительностью. Управление безопасностью. Модель обслуживания сети FCAPS была создана ISO (Международной организацией стандартизации). ITIL: библиотека ИТ-инфраструктуры - это набор практик для управления ИТ-услугами, который фокусируется на приведении ИТ-услуг в соответствие с потребностями бизнеса. TMN: сеть управления телекоммуникациями - это еще одна модель технического обслуживания, созданная ITU-T (сектор стандартизации телекоммуникаций) и являющаяся вариацией модели FCAPS. TMN нацелена на управление телекоммуникационными сетями. Cisco Lifecycle Services: конечно, Cisco имеет свою собственную модель обслуживания сети, которая определяет различные фазы в жизни сети Cisco: Подготовка Планирование Проектирование Внедрение Запуск Оптимизация Выбор модели обслуживания сети, которую вы будете использовать, зависит от вашей сети и бизнеса. Вы также можете использовать их в качестве шаблона для создания собственной модели обслуживания сети. Чтобы дать вам представление о том, что такое модель обслуживания сети и как она выглядит, ниже приведен пример для FCAPS: Управление неисправностями: мы будем настраивать наши сетевые устройства (маршрутизаторы, коммутаторы, брандмауэры, серверы и т. д.) для захвата сообщений журнала и отправки их на внешний сервер. Всякий раз, когда интерфейс выходит из строя или нагрузка процессора превышает 80%, мы хотим получить сообщение о том, чтобы узнать, что происходит. Управление конфигурацией: любые изменения, внесенные в сеть, должны регистрироваться в журнале. Чаще всего используют управление изменениями, чтобы соответствующий персонал был уведомлен о планируемых изменениях в сети. Изменения в сетевых устройствах должны быть зарегистрированы и утверждены до того, как они будут реализованы. Управление аккаунтингом: Мы будем взимать плату с (гостевых) пользователей за использование беспроводной сети, чтобы они платили за каждые 100 МБ данных или что-то в этом роде. Он также обычно используется для взимания платы с людей за междугородние VoIP-звонки. Управление производительностью: производительность сети будет контролироваться на всех каналах LAN и WAN, чтобы мы знали, когда что-то пойдет не так. QoS (качество обслуживания) будет настроено на соответствующих интерфейсах. Управление безопасностью: мы создадим политику безопасности и реализуем ее с помощью брандмауэров, VPN, систем предотвращения вторжений и используем AAA (Authorization, Authentication and Accounting) для проверки учетных данных пользователей. Сетевые нарушения должны регистрироваться, и должны быть приняты соответствующие мероприятия. Как вы видите, что FCAPS - это не просто "теоретический" метод, но он действительно описывает "что", "как" и "когда" мы будем делать. Какую бы модель обслуживания сети вы ни решили использовать, всегда есть ряд рутинных задач обслуживания, которые должны иметь перечисленные процедуры, вот несколько примеров: Изменения конфигурации: бизнес никогда не стоит на месте, он постоянно меняется. Иногда вам нужно внести изменения в сеть, чтобы разрешить доступ для гостевых пользователей, обычные пользователи могут перемещаться из одного офиса в другой, и для облегчения этой процедуры вам придется вносить изменения в сеть. Замена оборудования: старое оборудование должно быть заменено более современным оборудованием, и также возможна ситуация, когда производственное оборудование выйдет из строя, и нам придется немедленно заменить его. Резервные копии: если мы хотим восстановиться после сетевых проблем, таких как отказавшие коммутаторы или маршрутизаторы, то нам нужно убедиться, что у нас есть последние резервные копии конфигураций. Обычно вы используете запланированные резервные копии, поэтому вы будете сохранять текущую конфигурацию каждый день, неделю, месяц или в другое удобное для вас время. Обновления программного обеспечения: мы должны поддерживать ваши сетевые устройства и операционные системы в актуальном состоянии. Обновления позволяют исправлять ошибки ПО. Также обновление проводится для того, чтобы убедиться, что у нас нет устройств, на которых работает старое программное обеспечение, имеющее уязвимости в системе безопасности. Мониторинг: нам необходимо собирать и понимать статистику трафика и использования полосы пропускания, чтобы мы могли определить (будущие) проблемы сети, но также и планировать будущее расширение сети. Обычно вы создаете список задач, которые должны быть выполнены для вашей сети. Этим задачам можно присвоить определенный приоритет. Если определенный коммутатор уровня доступа выходит из строя, то вы, вероятно, захотите заменить его так быстро, как только сможете, но нерабочее устройство распределения или основного уровня будет иметь гораздо более высокий приоритет, поскольку оно влияет на большее число пользователей Сети. Другие задачи, такие как резервное копирование и обновление программного обеспечения, могут быть запланированы. Вы, вероятно, захотите установить обновления программного обеспечения вне рабочего времени, а резервное копирование можно запланировать на каждый день после полуночи. Преимущество планирования определенных задач заключается в том, что сетевые инженеры с меньше всего забудут их выполнить. Внесение изменений в вашу сеть иногда влияет на производительность пользователей, которые полагаются на доступность сети. Некоторые изменения будут очень важны, изменения в брандмауэрах или правилах списка доступа могут повлиять на большее количество пользователей, чем вы бы хотели. Например, вы можете установить новый брандмауэр и запланировать определенный результат защиты сети. Случайно вы забыли об определенном приложении, использующем случайные номера портов, и в конечном итоге устраняете эту проблему. Между тем некоторые пользователи не получат доступ к этому приложению (и возмущаются, пока вы пытаетесь его исправить...). Более крупные компании могут иметь более одного ИТ-отдела, и каждый отдел отвечает за различные сетевые услуги. Если вы планируете заменить определенный маршрутизатор завтра в 2 часа ночи, то вы можете предупредить парней из отдела "ИТ-отдел-2", о том, что их серверы будут недоступны. Для этого можно использовать управление изменениями. Когда вы планируете внести определенные изменения в сеть, то другие отделы будут проинформированы, и они могут возразить, если возникнет конфликт с их планированием. Перед внедрением управления изменениями необходимо подумать о следующем: Кто будет отвечать за авторизацию изменений в сети? Какие задачи будут выполняться во время планового технического обслуживания windows, linux, unix? Какие процедуры необходимо соблюдать, прежде чем вносить изменения? (например: выполнение "copy run start" перед внесением изменений в коммутатор). Как вы будете измерять успех или неудачу сетевых изменений? (например: если вы планируете изменить несколько IP-адресов, вы запланируете время, необходимое для этого изменения. Если для перенастройки IP-адресов требуется 5 минут, а вы в конечном итоге устраняете неполадки за 2 часа, так как еще не настроили. Из-за этого вы можете "откатиться" к предыдущей конфигурации. Сколько времени вы отводите на устранение неполадок? 5 минут? 10 минут? 1 час? Как, когда и кто добавит сетевое изменение в сетевую документацию? Каким образом вы создадите план отката, чтобы в случае непредвиденных проблем восстановить конфигурацию к предыдущей конфигурации? Какие обстоятельства позволят отменить политику управления изменениями? Еще одна задача, которую мы должны сделать - это создать и обновить вашу сетевую документацию. Всякий раз, когда разрабатывается и создается новая сеть, она должна быть задокументирована. Более сложная часть состоит в том, чтобы поддерживать ее в актуальном состоянии. Существует ряд элементов, которые вы должны найти в любой сетевой документации: Физическая топологическая схема (физическая карта сети): здесь должны быть показаны все сетевые устройства и то, как они физически связаны друг с другом. Логическая топологическая схема (логическая карта сети): здесь необходимо отобразить логические связи между устройствами, то есть как все связано друг с другом. Показать используемые протоколы, информация о VLAN и т. д. Подключения: полезно иметь диаграмму, которая показывает, какие интерфейсы одного сетевого устройства подключены к интерфейсу другого сетевого устройства. Инвентаризация: вы должны провести инвентаризацию всего сетевого оборудования, списков поставщиков, номера продуктов, версии программного обеспечения, информацию о лицензии на программное обеспечение, а также каждое сетевое устройство должно иметь инвентарный номер. IP-адреса: у вас должна быть схема, которая охватывает все IP-адреса, используемые в сети, и на каких интерфейсах они настроены. Управление конфигурацией: перед изменением конфигурации мы должны сохранить текущую запущенную конфигурацию, чтобы ее можно было легко восстановить в предыдущую (рабочую) версию. Еще лучше хранить архив старых конфигураций для дальнейшего использования. Проектная документация: документы, которые были созданы во время первоначального проектирования сети, должны храниться, чтобы вы всегда могли проверить, почему были приняты те или иные проектные решения. Это хорошая идея, чтобы работать с пошаговыми рекомендациями по устранению неполадок или использовать шаблоны для определенных конфигураций, которые все сетевые администраторы согласны использовать. Ниже показаны примеры, чтобы вы понимали, о чем идет речь: interface FastEthernet0/1 description AccessPoint switchport access vlan 2 switchport mode access spanning-tree portfast Вот пример интерфейсов доступа, подключенных к беспроводным точкам доступа. Portfast должен быть включен для связующего дерева, точки доступа должны быть в VLAN 2, а порт коммутатора должен быть изменен на "доступ" вручную. interface FastEthernet0/2 description VOIP interface FastEthernet0/2 description ClientComputer switchport access vlan 6 switchport mode access switchport port-security switchport port-security violation shutdown switchport port-security maximum 1 spanning-tree portfast spanning-tree bpduguard enable Вот шаблон для интерфейсов, которые подключаются к клиентским компьютерам. Интерфейс должен быть настроен на режиме "доступа" вручную. Безопасность портов должна быть включена, поэтому допускается только 1 MAC-адрес (компьютер). Интерфейс должен немедленно перейти в режим переадресации, поэтому мы настраиваем spanning-tree portfast, и, если мы получаем BPDU, интерфейс должен перейти в err-disabled. Работа с предопределенными шаблонами, подобными этим, уменьшит количество ошибок, потому что все согласны с одной и той же конфигурацией. Если вы дадите каждому сетевому администратору инструкции по ""защите интерфейса", вы, вероятно, получите 10 различных конфигураций interface GigabitEthernet0/1 description TRUNK switchport trunk encapsulation dot1q switchport mode trunk switchport trunk nonegotiate Вот еще один пример для магистральных соединений. Если вы скажете 2 сетевым администраторам "настроить магистраль", вы можете в конечном итоге получить один интерфейс, настроенный для инкапсуляции 802.1Q, а другой-для инкапсуляции ISL. Если один сетевой администратор отключил DTP, а другой настроил интерфейс как "dynamic desirable", то он также не будет работать. Если вы дадите задание им настроить магистраль в соответствии с шаблоном, то у нас будет одинаковая конфигурация с обеих сторон.
img
Сегодня хотим предложить крутой функционал, который тебе захочется установить на своей IP – АТС Asterisk прямо сейчас! Речь пойдет про отправку записи разговора на адрес электронной почты со всеми причитающимися метаданными звонка. Работает это примерно вот так: ваш сотрудник поговорил по телефону, положил трубку, после чего, ответственному по электронной почте приходит письмо с записью разговора, датой и временем звонка, а также номерами А и Б. Настроить эту «фичу» очень легко. Приступаем к настройке. Bash скрипт для Asterisk Сам по себе скрипт написан на bash. Скрипт будет инициироваться сразу после окончания звонка и в него будут переданы нужные для работы переменные. Но об этом чуть позже: #!/bin/bash dt=$(date '+%m/%d/%Y %r'); echo -e "Привет! Появилась новая запись разговоров на нашем сервере Asterisk Звонок был совершен $dt Нам позвонил этот номер - $5 Вызов принял - $7 Запись разговора во вложении " | mail -a /var/spool/asterisk/monitor/$1/$2/$3/$6 -s "Новая запись разговоров" info@merionet.ru Пробежимся по переменным, которые будут относится к звонку и будут передаваться (все кроме $dt) с Asterisk: $1 - год звонка; $2 - месяц звонка; $3 - день звонка; $4 - дата и время в формате строки; $5 - источник звонка (звонящий); $6 - имя файла аудио – записи разговора; $7 - куда был совершен вызов; $dt - генерируем дату звонка; Переходим в консоль сервера Asterisk. Первым делом создаем файл с расширением .sh в него мы поместим наш скрипт: touch /var/lib/asterisk/bin/rectoemail.sh Даем файлу нужные права и разрешения: chown asterisk:asterisk rectoemail.sh chmod 774 rectoemail.sh Теперь открываем сам файл скрипта для редактирования: vim /var/lib/asterisk/bin/rectoemail.sh И добавляем скрипт в файл. Для того, чтобы сделать это, скопируйте скрипт из статьи. В режиме редактирования через vim нажмите «o» на клавиатуре, затем нажмите правую кнопку мыши – скрипт будет добавлен в файл. После этого, нажмите Esc на клавиатуре и комбинацию :x! + Enter для сохранения изменений. Готово. Доработка в FreePBX Теперь нужно поставить наш скрипт на автоматический запуск. Переходим в раздел Settings → Advanced Settings. Убеждаемся, что параметры Display Readonly Settings и Override Readonly Settings установлены в значение Yes. Теперь находим параметр Post Call Recording Script и добавляем в его поле следующую строчку: bash /var/lib/asterisk/bin/rectoemail.sh ^{YEAR} ^{MONTH} ^{DAY} ^{TIMESTR} ^{FROMEXTEN} ^{CALLFILENAME}.^{MIXMON_FORMAT} ^{ARG3} Готово. Сохраняем настройки и переходим к тестам:
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59