По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Нормализация базы данных (БД) - это метод проектирования реляционных БД, который помогает правильно структурировать таблицы данных. Процесс направлен на создание системы с четким представлением информации и взаимосвязей, без избыточности и потери данных.
В данной статье рассказывается, что такое нормализация базы данных, и объясняются принципы ее работы на практическом примере.
Что такое нормализация базы данных?
Нормализация базы данных - это метод создания таблиц БД со столбцами и ключами путем разделения (или декомпозиции) таблицы большего размера на небольшие логические единицы. В данном методе учитываются требования, предъявляемые к среде БД.
Нормализация - это итеративный процесс. Как правило, нормализация БД выполняется через серию тестов. Каждый последующий шаг разбивает таблицу на более легкую в управлении информацию, чем повышается общая логичность системы и простота работы с ней.
Зачем нужна нормализация базы данных?
Нормализация позволяет разработчику БД оптимально распределять атрибуты по таблицам. Данная методика избавляет от:
атрибутов с несколькими значениями;
задвоения или повторяющихся атрибутов;
атрибутов, не поддающихся классификации;
атрибутов с избыточной информацией;
атрибутов, созданных из других признаков.
Необязательно выполнять полную нормализацию БД. Однако она гарантирует полноценно функционирующую информационную среду. Этот метод:
позволяет создать структуру базы данных, подходящую для общих запросов;
сводит к минимуму избыточность данных, что повышает эффективность использования памяти на сервере БД;
гарантирует максимальную целостность данных, устраняя аномалий вставки, обновления и удаления.
Нормализация базы данных преобразует общую целостность данных в удобную для пользователя среду.
Избыточность баз данных и аномалии
Когда вы вносите изменения в таблицу избыточностью, вам придется корректировать все повторяющиеся экземпляры данных и связанные с ними объекты. Если этого не сделать, то таблица станет несогласованной, и при внесении изменений возникнут аномалии.
Так выглядит таблица без нормализации:
Для таблицы характерна избыточность данных, а при изменении этих данных возникают 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)
Теперь таблица соответствует третьей нормальной форме с тремя взаимосвязями. Конечная структура выглядит так:
Теперь база данных считается нормализованной. Дальнейшая нормализация зависит от ваших конкретных целей.
Заключение
В статье рассказывалось, как с помощью нормализации БД можно сократить избыточность информации. В долгосрочной перспективе нормализация БД позволяет свести к минимуму потерю данных и улучшить их общую структуру.
Если же вы хотите повысить производительность доступа к данным, то воспользуйтесь денормализацией БД.
А если вы испытываете трудности с нормализацией базы данных, то рассмотрите возможность перехода на другой тип БД.
Недавно в одной из наших статей мы рассматривали методы конфигурации Cisco Call Manager Express - CME (он же Cisco Unified Communications Manager Express - CUCME)
Сегодня мы рассмотрим установку приложения Cisco Configuration Professional (CCP) , которое представляет собой инструмент управления на основе графического интерфейса GUI для маршрутизаторов Integrated Services Routers (ISR) на операционной системе Windows.
Установка
Сначала нам нужно скачать установочные файлы CCP с сайта Cisco.com в разделе загрузок. Запустив установочный файл, проходим через все этапы установки, указав путь установки программы. Во время установки будет произведена проверка требований для работы Cisco Configuration Professional – Internet Explorer с плагином Java JRE, Adobe Flash Player 10, 1 Гб ОЗУ, разрешение экрана минимум 1024х768 .
После установки необходимо подключиться к роутеру одним из доступных способов (консольный порт, telnet, ssh) и выполнить пару команд:
Router# configure terminal //переходим в режим конфигурации
Router(config)#username admin privilege 15 secret password //где admin это наш логин для входа, а password - пароль
Router(config)#ip http server //настраиваем роутер как HTTP сервер
Router(config)# ip http secure-server //настраиваем роутер как HTTPS сервер
Router(config)# ip http authentication local //настраиваем локальную аутентификацию
Также настроим Telnet/SSH аутентификацию
Router(config)#line vty 0 4
Router(config-line)#login local
Router(config)#transport input telnet ssh
Теперь настало время запускать CCP. После запуска мы увидим такое окно.
Здесь в поле IP Address/Hostname указываем адрес, по которому можно подключиться к маршрутизатору для управления им, в полях Username и Password указываем созданные нами логин с паролем. Для подключения с использованием HTTPS, вместо HTTP нужно поставить галочку Connect Securely.
После этого CCP найдет наш роутер и он появится в поле Community Information со статусом Discovered.
Теперь можно начинать настраивать наше оборудование, нажав в верхнем левом углу клавишу Configure.
NoSQL СУБД, или нереляционные базы данных, обладают уникальными возможностями, которые компенсируют ограничения моделей реляционных баз. Нереляционные СУБД – это общее название для 4 основных подгрупп:
базы данных типа «ключ-значение»
колоночные базы данных
графовые базы данных
документные базы данных
В этой статье мы расскажем о том, что такое документная база данных, опишем ее плюсы и минусы, а также рассмотрим примеры.
Документная база данных
Документная (или документоориентированная) база данных – это тип нереляционных СУБД, который хранит данные не в столбцах и строках, а в виде документов JSON. JSON является нативным языком, используемым для хранения и запросов данных. Такие документы можно сгруппировать в коллекции, которые образуют системы баз данных.
Каждый документ состоит из нескольких пар «ключ-значение». Ниже приведен пример документа из 4 пар «ключ-значение»:
{
"ID" : "001",
"Book" : "Java: The Complete Reference",
"Genre" : "Reference work",
"Author" : "Herbert Schildt",
}
JSON позволяет разработчикам приложений хранить и запрашивать данные в том же формате документной модели, который используется ими для структурирования кода приложений. Объектную модель можно преобразовать в такие форматы, как JSON, BSON и XML.
Сравнение реляционной и документной базы данных
Реляционная система управления базами данных (РСУБД) основана на языке структурированных запросов (SQL). Для нереляционных баз они не нужны.
РСУБД занимается созданием связей между файлами для хранения и считывания данных. Документные базы данных ориентированы на сами данные, а связи между ними представлены в виде вложенных данных.
Ключевое сравнение реляционных и документных баз данных:
РСУБД
Система документных баз данных
Выстроена вокруг концепции о связях
Сосредоточена на данных, а не связях
Структурирует данные в кортежи (или строки)
Вместо строк в документах имеются свойства без теоретических определений.
Определяет данные (образует связи) через ограничения и внешние ключи (например, дочерняя таблица ссылается на основную таблицу через ее идентификатор).
Для определения схем не нужен язык DDL.
Для создания связей использует язык DDL (язык описания данных).
Вместо внешних ключей связи реализованы через вложенные данные (в одном документе могут содержаться другие, вложенные в него, документы, из-за чего между двумя сущностями документов формируется связь 1 ко многим (или многие к одному)).
Обеспечивает исключительную согласованность. В некоторых случаях она просто необходима (например, ежедневные банковские операции).
Обеспечивает согласованность в конечном счете (с периодом несогласованности).
Особенности документной базы данных
Документные базы данных обеспечивают быстрые запросы, структуру, которая отлично подходит для обработки больших данных, гибкое индексирование и упрощенный принцип поддержания баз данных. Такая СУБД эффективна для веб-приложений и была полностью интегрирована крупными ИТ-компаниями уровня Amazon.
Несмотря на то, что базы данных SQL могут похвастаться отличной стабильность и вертикальной структурой, им свойственна «тяжеловесность» данных. В сценариях использования, когда требуется моментальный доступ к данным (например, медицинские приложения), лучше выбирать документные базы данных. Так вы сможете легко запрашивать данные в той же модели документа, в которой писался код приложения.
Примеры использования документной базы данных
База данных «Книга»
Для создания баз данных «Книга» используются как реляционные, так и нереляционные СУБД, хотя и по-разному.
В реляционных СУБД связи между книгами и авторами выражаются через таблицы с идентификаторами ID: таблица Author (Автор) и таблица Books (Книги). Данная модель не допускает пустых значений, поэтому за каждым «Автором» должна быть закреплена как минимум одна запись в таблице «Книги».
В документной модели вы можете вкладывать данные. Такая модель показывает взаимосвязи проще и естественнее: в каждом документе с авторами есть свойство Books с массивом связанных документов «Книги». При поиске по автору отображается вся коллекция книг.
Управление содержимым
Разработчики пользуются документными базами данных для создания блогов, платформ с потоковыми видео и аналогичных сервисов. Каждый файл сохраняется в виде отдельного документа, и со временем, по мере разрастания сервиса, такую базу легче поддерживать. На значимые изменения в данных (как, например, изменения модели данных) не требуется простоя, поскольку им не нужно обновление схемы.
Каталоги
Когда дело касается хранения и чтения файлов каталога, документные базы данных оказываются в разы эффективнее реляционных СУБД. В каталогах могут храниться тысячи атрибутов, а документная база данных обеспечивает их быстрое считывание. В документных базах данных атрибуты, связанные с одним продуктом, хранятся в одном документе. Изменение атрибутов в одном из продуктов не влияет на другие документы.
Плюсы и минусы документной базы данных
Ниже представлены главные плюсы и минусы документной базы данных:
Плюсы документной БД
Минусы документной БД
Отсутствие схемы
Ограничения по проверке на согласованность
Быстрое создание и обслуживание
Проблемы с атомарностью
Отсутствие внешних ключей
Безопасность
Открытые форматы
Встроенное управление версиями
Плюсы
Отсутствие схемы. Нет ограничений по формату и структуре хранилищ данных. Это хорошо для сохранения существующих данных в больших объемах и разных структурных состояниях, особенно в непрерывно преобразующихся системах.
Быстрое создание и обслуживание. Как только вы создали документ, ему требуется лишь минимальная поддержка – она может оказаться не сложнее разового добавления вашего сложного объекта.
Отсутствие внешних ключей. Когда эта динамика связей отсутствует, документы становятся независимыми друг от друга.
Открытые форматы. Чистый процесс сборки, в котором для описания документов используется XML, JSON и другие производные.
Встроенное управление версиями. По мере того, как увеличивает размер ваших документов, повышается и их сложность. Управление версиями уменьшает количество конфликтов.
Минусы
Ограничения по проверке на согласованность. В примере с базой данных «Книга» можно искать книги по несуществующему автору. При поиске по коллекциям книг вы можете находить документы, не связанные с коллекцией авторов. Кроме того, в каждом списке для каждой книги может дублироваться информация об авторе. В некоторых случаях такая несогласованность не особо важна. Но при более высоких стандартах непротиворечивости РСУБД несогласованность серьезно снижает производительность баз данных.
Проблемы с атомарностью. Реляционные системы позволяют изменять данные из одного места без использования JOIN. Все новые запросы на чтение унаследуют изменения, внесенные в данные по одной команде (например, обновление или удаление строки). Для документных баз данных изменение, затрагивающее 2 коллекции, выполняется через 2 отдельных запроса (по одному на коллекцию). Это нарушает требования к атомарности.
Безопасность. Почти в половине современных веб-приложений отмечается активная утечка конфиденциальных данных. Поэтому владельцам нереляционных баз данных следует быть крайне внимательными к уязвимостям веб-приложения.
Лучшие документные базы данных
Amazon DocumentDB
Особенности:
совместимость с MongoDB;
полная управляемость;
высокая производительность с низкой задержкой запросов;
строгое соответствие требованиям и безопасность;
высокая доступность.
Как используется:
Вся команда разработки Amazon пользуется Amazon DocumentDB для повышения оперативности и продуктивности. Им нужны были вложенные индексы, агрегирование, ad-hoc запросы (запросы узкой специализации), а также полностью управляемый процесс.
BBC использует документные БД для запросов и хранения данных из нескольких потоков данных с компиляцией их в единый канал для клиентов. Они перешли на Amazon DocumentDB, чтобы получить полностью управляемы сервис с высокой доступностью, прочностью и резервным копированием по умолчанию.
Rappi выбрали Amazon DocumentDB для сокращения времени на написание кода, Dow Jones – для упрощения операций, а Samsung – для более гибкой обработки больших журналов.
MongoDB
Особенности:
ad-hoc запросы;
оптимизированное индексирование для запросов;
сегментирование;
балансировка нагрузки.
Как используется:
Forbes сократил время компоновки на 58%, получив прирост в 28% по количеству подписок, за счет более быстрого создания новых функций, более простого объединения и более качественной обработки разнообразных типов данных.
Toyota заметила, что разработчикам было проще работать с документными БД на больших скоростях за счет использования нативных JSON-документов. Больше времени тратилось на создание ценности бизнеса, а не на моделирование данных.
Cosmos DB
Особенности:
быстрое чтение в любом масштабе;
99,999% доступность;
полная управляемость;
NoSQL/Native Core API;
бессерверное, экономичное/мгновенное масштабирование.
Как используется:
Coca-Cola получает информацию за минуты, что способствует глобальному масштабированию. До перехода на Cosmos DB на это уходили часы.
ASOS искали распределенную базу данных, которая легко и гибко масштабируется для обслуживания 100+ миллионов розничных клиентов по всему миру.
ArangoDB
Особенности:
валидации схем;
разноплановое индексирование;
быстрые распределенные кластеры;
эффективность с большими наборами данных;
поддержка многих нереляционных моделей данных;
объединение моделей в единые запросы.
Как используется:
Оксфордский университет разработал онлайн-тестирование на сердечно-легочные заболевания, благодаря чему снизил посещаемость больниц и усовершенствовал результаты анализов.
FlightStats привел к единому стандарту разрозненную информацию о полетах (статус рейса, погодные условия, задержки в аэропорту, справочные данные), что позволило получить точные, прогнозирующие и аналитические результаты.
Couchbase Server
Особенность:
возможность управления глобальными развертываниями;
крайняя гибкость и адаптивность;
быстрота в крупных масштабах;
простые облачные интеграции.
Как используется:
BT использовал гибкую модель данных Couchbase для ускорения собственных возможностей по высокопроизводительной поставке контента, а также легкого масштабирования в моменты резкого повышения спроса.
eBay перешел от Oracle к более экономичному и функциональному решению (их документной системы/хранилища типа «ключ-значение»). Возросла доступность и производительность приложения, а разработчики могли пользоваться своим опытом в SQL для ускорения пайплайна CI/CD (конвейера сборки) через более гибкую схему.
CouchDB
Особенности:
графический интерфейс на базе браузера;
простейшие репликации;
аутентификация пользователя;
свойства ACID (Атомарность – Согласованность – Изолированность – Прочность).
Как используется:
Meebo (соцсеть) пользуется CouchDB для веб-интерфейса и его приложений.
The BBC выбрал CouchDB за платформы динамического контента
Как выбрать?
Структуру данных определяют важнейшие требования, предъявляемые к приложению. Вот несколько ключевых вопросов:
Вы будете больше читать или записывать? В случае, если вы чаще записываете данные, лучше подойдут реляционные системы, поскольку они позволяют избегать задвоений при обновлениях.
Насколько важна синхронизация? Благодаря стандартам ACID, реляционные системы справляются с этой задачей лучше.
Насколько сильно потребуется изменять вашу схему базы данных в будущем? Документные БД – это беспроигрышный вариант, если вы работаете с разнообразными данными в масштабе и ищете минимальной поддержки.
Нельзя сказать, что документная СУБД или SQL база лучше во всем. Правильный выбор зависит от вашего сценария использования. Принимая решение, подумайте, какие типы операций будут выполняться чаще всего.
Заключение
В данной статье мы объяснили особенности документной базы данных, поговорили о плюсах и минусах системы, а также рассмотрели сценарии использования. Кроме того, был приведен список лучших документных СУБД и рассказано, как компании из рейтинга Forbes 500 пользуются этими системами для повышения эффективности своей деятельности и процессов разработки.