План-конспект лекции "Нормализация данных "

При построении баз данных необходимо следовать определённым правилам. Эти правила получили название нормализации баз данных. Нормализация базы данных является не обязательной, но эти правила существенно упростят работу по составлению запросов и способствуют улучшению масштабируемости.

Нормализация базы данных – это рекомендации по проектированию.

• Возможность существенно упростить выборки. Получение данных из базы относительно простыми запросами.

• Целостность данных. Избежание потерь или искажения информации в базе данных.

• Отсутствие избыточности. Данные в таблице не дублируются, что существенно снижает её размер.

• Благоприятные предпосылки к росту базы.

Для приведения базы к нормальной форме необходимо выполнить следующие действия:

1. Постараться объединить данные в группы.

2. Найти логические связи между этими группами данных. Для установки связей связываемые поля должны быть одного типа и таблица формата InnoDB.

Отношения — это указатели, которые показывают, как соотносятся данные в одной таблице с данными в другой. Проще говоря, ссылка с одного столбца первой таблицы на другой столбец второй таблицы. Бывают трех видов — один-к-одному, один-к-многим, многие-к-многим.

Отношение один-к-одному означает что поле 1 соотносится с полем 2. Пример — у каждого человека свой номер паспорта. 1 человек- 1 паспорт. Тут отношение один-к-одному.

Один-к-многим указывает, что поле 1 может соотносится как с полем 2, так и с полем 3, полемN.

Отношение многие-к-многим бывает, когда нескольким значениям из одной таблицы соответствует несколько значений другой таблицы. Например, в категории блога может быть много постов, а у блога может быть много категорий. Еще такое отношение может встречаться в составных ключах. Такой связи следует избегать, поскольку она ведет к избыточности данных. В том-же вордпрессе категории и посты соотносятся через третью таблицу — wp_relationships.

Создание структуры базы данных (схема) и отношений между таблицами можно ускорить, использую различные CASE-средства

Как писалось выше, нормализация — это приведение структуры бд в порядок в соответствии с несколькими правилами. Правилам нужно следовать точно, и приводить к формам нужно в порядке их следования.

Чтобы привести таблицу к 1НФ, нужно соблюсти два правила:

1. Атомарность или неделимость. Каждая колонка должна содержать одно неделимое значение.

2. Таблица не должна содержать повторяющихся колонок или групп данных.

Например, если таблица содержит в одном поле полный адрес человека (улица, город, почтовый код), не будет отвечать правилам 1НФ, поскольку будет содержать различные значения в одном столбце, что будет нарушением правила об атомарности. Или если бд содержит данные о фильмах и в ней есть столбцы актер 1, актер 2, актер 3, также не будет отвечать правилам, поскольку будет иметь место повторению данных.

Начинать нормализацию следует с проверки структуры бд на совместимость с 1НФ. Все столбцы, которые не являются атомарными, должны быть разбиты на составляющие их столбцы. Если в таблице есть повторяющиеся столбцы, то им нужно выделить отдельную таблицу.

Чтобы привести таблицу к первой нормальной форме, следует:

• Найти все поля, которые содержат многосоставные части информации. Те данные, которые можно разбить на составные части, нужно выносить в отдельные поля. Полное имя на имя и фамилию.

• Выносите повторяющиеся данные в отдельную таблицу.

Подсказки

• Простейший путь приведения к 1НФ — это пройтись глазами по всем столбцам. Проверьте каждый ряд на отсутствие повторения схожих данных и делимости.

• Разные источники трактуют процесс нормализации по своему, в основном более сухим, техническим языком. Более важен результат нормализации, а не повторение правил и умных слов.

Для приведения таблиц ко второй нормальной форме (2НФ), приводимые таблицы должны быть уже в 1НФ. Нормализация должна проходить по порядку.

Теперь, во второй нормальной форме, должно быть соблюдено условие — любой столбец, который не является ключом (в том числе внешним), должен зависеть от первичного ключа. Обычно такие столбцы, имеющие значения, который не зависят от ключа, легко определить. Если данные, содержащиеся в столбце, не имеют отношения к ключу, который описывает строку, то их следует отделять в свою отдельную таблицу. В старую таблицу надо возвращать первичный ключ.

Чтобы привести базу ко второй нормальной форме, надо

• Определить все столбцы, которые не находятся в прямой зависимости от первичного ключа этой таблицы.

Создаем внешние ключи и обозначаем их отношения между таблицами. Конечным шагом нормализации до 2НФ будет являться выделение внешних ключей для связи с ассоциированными таблицами. Первичный ключ одной таблицы должен быть внешним ключом в другой.

Подсказки:

• Другой способ приведения схемы к 2НФ — посмотреть на отношения между таблицами. Идеальный вариант — создать все отношения вида один-к-многим. Отношения вида многие-к-многим нуждаются в реструктуризации.

• Можно вводить такие промежуточные таблицы, у которых все столбцы являются ключами. В таких таблицах не требуется свой собственный первичный ключ, поскольку он может быть комбинацией двух внешних ключей.

• Нормализованная должным образом таблица никогда не будет иметь повторяющихся рядов (двух и более рядов, значения которых не являются ключами и содержат совпадающие данные).

• Чтобы упростить нормализацию, помните, что при приведении к 1НФ вы ищете дубли горизонтально (дубли столбцов), а при приведении к 2НФ — вертикально (дубли рядов).

База данных будет находиться в третьей нормальной форме, если она приведена ко второй нормальной форме и каждый не ключевой столбец независим друг от друга. Если следовать процессу нормализации правильно до этой точки, с приведением к 3НФ может и не возникнуть вопросов.

Следует знать, что 3НФ нарушается, если изменив значение в одном столбце, потребуется изменение и в другом столбце.  В примере с форумом (рисунок вверху), проблем с приведением к 3НФ не возникнет, но можно рассмотреть как образец гипотетическую ситуацию, где это может произойти.

Возьмём, как образец, одиночную таблицу, которая хранит некую информацию о бизнес клиентах: имя, фамилию, телефон, адрес, город, штат, почтовый индекс и все в этом духе.  Такая таблица не будет находится в 3НФ, поскольку тут много полей будет взаимозависимо — улица будет зависеть от города, город от штата, почтовый индекс тоже под вопросом. Все эти поля будут подчинены друг другу, а не человеку, к которому относится эта запись.

Чтобы нормализовать такую базу, нужно создать по таблице для штатов, городов (с внешним ключом, ведущим в таблицу штатов) и для почтовых кодов. Все они будут ссылаться назад на клиентскую таблицу.

Если вы чувствуете, что все эти действия могут быть излишними, вы правы.  Честно, в верхних уровнях нормализации часто нет необходимости.  Смысл в том, что нужно стараться нормализовать базу данных, но иногда приходиться идти на уступки ради того, чтобы не допустить чрезмерного усложнения. Потребности приложения и структура данных в базе подскажут, насколько потребуется проводить процесс нормализации.

Чтобы привести базу к третьей нормальной форме, надо:

1. Определить, в каких полях каких таблиц имеется взаимозависимость. Как только что говорилось, поля, которые зависят больше друг от друга (как город от штата), чем от ряда в целом.

2. Создайте соответствующие таблицы. Если есть проблемный столбец в шаге 1, создавайте раздельные таблицы для него. Как города и штаты, в примере с клиентами.

3. Создайте или выделите первичные ключи. Каждая таблица должна иметь первичный ключ. Для примера с клиентами это будут city ID и state ID.

4. Создайте необходимые внешние ключи, которые образуют любое из отношений. В нашем примере нужно добавить state ID в таблицу городов и city ID в таблицу клиентов. Это свяжет каждого клиента с городом и штатом, где они живут.

Подсказки:

Вообще, можно было бы и не нормализовывать базу с клиентами до такой степени. Если оставить города и штаты в таблице клиентов, самое страшное, что могло бы случиться — если бы город изменил название, нужно было бы менять его во всех записях о клиентах, которые живут в этом городе. Но города редко меняют свои имена.

Несмотря на то, что имеются правила как нормализовывать базы данных, разные люди сделают это разными способами.  Проектирование баз данных допускает личные предпочтения и интерпретации. Важно, чтобы в базе не было явных нарушений нормальных форм, которые могут привести в дальнейшем к проблемам.

Введение в СУБД MуSQL

Система управления базами данных (СУБД) MySQL – разработка шведской компании MySQL AB. СУБД MySQL является программным обеспечением с открытым исходным кодом, распространяемым по лицензии GNU (GPL) и коммерческой лицензии для ситуаций, не подпадающих под действие лицензии GPL. Современную разработку и поддержку СУБД MySQL осуществляет корпорация Oracle, получившая права на торговую марку вместе с поглощённой Sun Microsystems, которая ранее приобрела шведскую компанию MySQL AB. Субд MySQL поддерживает реляционную модель данных, т. е. представляет собой реляционную СУБД.

В современных реалиях СУБД MySQL - одна из самых популярных баз данных для веб-приложений. Фактически, является стандартом de facto для большинства веб-серверов, которые работают под управлением операционных систем семейства Linux.

Начиная с версии 5.0, СУБД MySQL практически полностью удовлетворяет стандарту структурированного языка запросов SQL и, следовательно, совместима с другими базами данных.

Эта СУБД позволяет выбирать различные движки для системы хранения, которые позволяют менять функционал инструмента (ПО) и выполнять обработку данных, хранящихся в различных типах таблиц. Гибкость СУБД MySQL обеспечивается поддержкой большого количества типов таблиц: пользователи могут выбрать как таблицы типа MyISAM, поддерживающие полнотекстовый поиск, так и таблицы InnoDB, поддерживающие транзакции на уровне отдельных записей. Более того, СУБД MySQL поставляется со специальным типом таблиц EXAMPLE, демонстрирующим принципы создания новых типов таблиц. Благодаря открытой архитектуре и GPL-лицензированию, в СУБД MySQL постоянно появляются новые типы таблиц. Она также имеет простой в использовании интерфейс, и пакетные команды, которые позволяют удобно обрабатывать огромные объемы данных. Система невероятно надежна и не стремится подчинить себе все доступные аппаратные ресурсы.

Рассмотрим основные достоинства СУБД MySQL:

• Высокое качество – MySQL характеризуется устойчивой работой;

• Распространяется бесплатно;

• Прекрасно документирована;

• Предлагает большое количество функций, даже в бесплатной версии;

• Пакет MySQL включен в стандартные репозитарии наиболее распространенных дистрибутивов операционной системы Linux;

• Поддерживает набор пользовательский интерфейсов;

• Может работать с другими базами данных, включая DB2 и Oracle;

• Наряду с Oracle, MySQL считается одной из самых быстрых СУБД в мире;

• Открытый код доступен для просмотра и модернизации, что позволяет постоянно улучшать программный продукт;

• СУБД MySQL, разработанная с использованием языков C/C++, протестирована на многих платформах, среди которых Windows, Linux, FreeBSD, Mac OS X, OS/2, Solaris и др;

• MySQL поддерживает API (Application Programming Interface, программный интерфейс приложения) для С, C++, Eiffel, Java, Perl, PHP, Python, Ruby и Tcl. MySQL можно успешно применять как для построения Web-страниц с использованием PHP и Java;

• СУБД MySQL предоставляет широкий выбор типов таблиц, в том числе и сторонних разработчиков, что позволяет реализовать оптимальную для решаемой задачи производительность и функциональность;

• Локализация в MySQL выполнена корректно. У пользователя, как правило, не возникает проблем при обработке русского содержимого БД.

Рассмотрим основные недостатки СУБД MySQL:

• Придется потратить много времени и усилий, чтобы заставить MySQL выполнять несложные задачи, хотя другие системы делают это автоматически, например: создавать инкрементные резервные копии;

• Отсутствует встроенная поддержка XML;

• Для бесплатной версии доступна лишь платная техподдержка.

В ранних версия MySQL (начиная с версии MySQL 4.1) появились такие важные нововведения, как полная поддержка вложенных запросов и поддержка транзакций. А в версии MySQL 5.0 стали доступными следующие важные механизмы:

• хранимые процедуры и функции, объединяющие в себе целые последовательности запросов;

• триггеры, т. е. хранимые процедуры, привязанные к событию изменения таблицы;

• представления – выборки данных, которые можно представить как полноценные реально существующие таблицы базы данных;

• курсоры, позволяющие цикле просмотреть каждую строку результирующей таблицы запросов;

• информационная схема, т. е. переносимый набор представлений системной таблицы, в которой хранится разнообразная внутренняя информация.

• обработчики ошибок;

Вывод – идеально подходит для организаций, которым требуется надежный инструмент управления базами данных, но бесплатный; одна из самых распространенных СУБД для веб-серверов.

Аналог СУБД MySQL – MariaDB

Данная СУБД является бесплатной, но как и многие другие бесплатные приложения, предлагает платные версии. Есть множество доступных плагинов расширений, пожалуй, это самая быстро - развивающаяся СУБД на данный момент времени.

MariaDB фактически - это ответвление от СУБД MySQL (форк), разрабатываемое сообществом под лицензией GNU GPL. Разработку и поддержку MariaDB осуществляет компания MariaDB Corporation Ab и фонд MariaDB Foundation. Толчком к созданию стала необходимость обеспечения свободного статуса СУБД, в противовес политике лицензирования MySQL компанией Oracle. Система лицензирования MariaDB обязывает участников, желающих добавить свой код в основную ветку СУБД, обмениваться своими авторскими правами с MariaDB Foundation для охраны лицензии и возможности создавать критические исправления для MySQL.

Ведущий разработчик — Майкл Видениус, автор оригинальной версии MySQL и основатель компании Monty Program AB.

Ядро базы данных позволяет делать выбор из нескольких систем хранения, и это делает использование ресурсов более оптимизированным, что повышает производительность запросов и обработки.  В состав MariaDB включена подсистемы хранения данных XtraDB для возможности замены InnoDB, как основной подсистемы хранения. Также включены подсистемы Aria, PBXT и FederateX. Она полностью совместима с MySQL, и прекрасно подходит в качестве замены, т.к. полностью соответствует как набор команд, так и API. Многие разработчики MySQL были вовлечены в процесс разработки, а сейчас принимают участие в развитии.

Рассмотрим основные достоинства СУБД MariaDB:

• Система работает быстро

• Индикаторы дадут вам знать, как обрабатывается запрос.

• Расширяемая архитектура и плагины позволяют настраивать инструмент в соответствии с вашими потребностями.

• Шифрование доступно в сети, сервере и уровне приложения.

Рассмотрим основные недостатки СУБД MariaDB:

• На данный момент стабильность ниже, чем у MySQL, поэтому даже на новых проектах можно рекомендовать устанавливать mysql.

• Движок довольно новый, поэтому пока нет никаких гарантий дальнейших обновлений.

• Как и во многих других бесплатных базах данных, вам придется платить за поддержку.

Идеальна как альтернатива MySQL, если MySQL не устраивает по каким-то причинам.

15