В начало

Лекция 12

Реляционная модель данных.

Нормализация. Нормальные формы.

Технология отображение концептуальной модели базы данных на реляционную модель данных

 

1. Основные понятия реляционной модели данных

 

Как было показано в предыдущей лекции, для определения реляционной модели данных необходимо объявить структуру данных, способ манипулирования ими и ограничения целостности (слайд 2).

 

1.1. Структурный компонент реляционной модели

С точки зрения структуры данных реляционная модель является удобной и наиболее привычной формой представления данных в виде таблицы. Понятию «таблица» соответствует понятие «отношение» (relation). Отсюда и произошло название модели – реляционная. Т.е., применительно к базам данных понятия «реляционная БД» и «табличная БД» по существу являются синонимами. В отличие от иерархической и сетевой модели, такой способ представления 

1) понятен пользователю-непрограммисту;

2) позволяет легко изменять схему – присоединять новые элементы данных и записи без изменения соответствующих подсхем; 

3) обеспечивает необходимую гибкость при обработке непредвиденных запросов.

К тому же любая сетевая или иерархическая схема может быть представлена двумерными отношениями.

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

Основными понятиями, с помощью которых определяется реляционная модель, являются следующие:  домен, отношение, кортеж, кардинальность, атрибуты, степень, первичный ключ. Соотношение понятий иллюстрируется на слайде (слайд 3).

Домен – это совокупность значений, из которой берутся значения соответствующих атрибутов определенного отношения. С точки зрения программирования домен – это тип данных, определяемый системой (стандартный) или пользователем.

Первичный ключ – это столбец или некоторое подмножество столбцов, которые уникально, т.е. единственным образом определяют строки.   Первичный ключ, который включает более одного столбца, называется множественным, или комбинированным, или составным. Правило целостности объектов утверждает, что первичный ключ не может быть полностью или частично пустым, т.е. иметь значение null.

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

Сформулируем правила назначения первичных ключей сущностей:

1).        Первичный ключ должен однозначно идентифицировать любой экземпляр сущности.

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

3).        Первичный ключ может быть составным, но увеличение количества столбцов, входящих в него, противоречит требованию компактности. Требование компактности также не удастся выполнить, если, например, в качестве первичного ключа выбрать атрибут строкового типа данных большой длины.

4). Значения первичного ключа не должны подвергаться частым модификациям. Идеально, если бизнес-логика предметной области такова, что эти значения вообще не предполагается изменять.

5). Правила модификации первичного ключа должны контролироваться внутренней бизнес-логикой предметной области, а не решениями, которые принимаются над ней. Например, в базе данных, разрабатываемой для нужд деканата, для сущности СТУДЕНТ не стоит выбирать в качестве первичного ключа серию и номер паспорта студента. Хотя эти данные в принципе и обладают свойствами обязательности и уникальности, но их изменение может быть инициировано студеном, а не администрацией факультета.

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

 

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

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

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

Понятия реляционной модели представляют специальную терминологию, введенную авторами теоретических основ, однако они имеют и более привычные аналоги (но не во всем эквиваленты!), соответствие которых приведено в следующей таблице (слайд 4).

 

12.1.2. Управляющий компонент реляционной модели

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

 

12.1.3. Целостность данных (слайд 5)

Целостность на уровне доменов

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

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

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

 

Целостность на уровне отношений

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

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

Обычно для ситуации наличия неизвестных или неполных данных используются типы данных, пополненные так называемым NULL-зпачением.

NULL-значение – это некий указатель на то, что значение неизвестно. Проблема использования NULL-значения в теории реляционных баз данных окончательно не решена. Практически все реализации современных реляционных СУБД позволяют использовать NULL-значения, несмотря на их недостаточную теоретическую обоснованность.

Правило целостности отношений гласит: каждое отношение должно иметь по крайней мере один потенциальный ключ, входящие в состав которого атрибуты не могут принимать null-значений. Этот потенциальный ключ лучше всего объявлять первичным ключом таблицы, соответствующей данному отношению.

Следует отметить, что большинство СУБД вполне позволяют создавать таблицы и без первичных ключей. Однако нарушение правила целостности отношений на практике сразу дает о себе знать. Например, для СУБД MS SQL-сервер станет невозможным доступ к данным по технологии OLE DB Provider.

 

Целостность внешних ключей (целостность на уровне БД)

Различные объекты предметной области, информация о которых хранится в базе данных, всегда взаимосвязаны. Наиболее типичный способ подобной связи между отношениями описывается ограничением внешнего ключа (FK, Foreign Key).

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

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

NULL-значения для атрибутов внешнего ключа допустимы только в том случае, когда атрибуты внешнего ключа не входят в состав никакого потенциального ключа.

Поскольку внешние ключи фактически служат ссылками на кортежи в другом (или в том же самом) отношении, то эти ссылки не должны указывать на несуществующие объекты.

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

 

12.1.4. Правила Кодда

В целом концепция реляционной модели определяется следующими двенадцатью правилами Кодда (слайд 6):

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

2.  Правило гарантированного доступа. Логический доступ ко всем и каждому элементу данных (атомарному значению) в реляционной базе данных должен обеспечиваться путём использования комбинации имени таблицы, первичного ключа и имени столбца.

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

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

5.  Правило исчерпывающего подъязыка данных. Реляционная система может поддерживать различные языки и режимы взаимодействия с пользователем (например, режим вопросов и ответов). Однако должен существовать по крайней мере один язык, операторы которого можно представить в виде строк символов в соответствии с некоторым четко определенным синтаксисом и который в полной мере поддерживает  определение данных; определение представлений; обработку данных (интерактивную и программную); условия целостности; идентификация прав доступа; границы транзакций (начало, завершение и отмена).

6.  Правило обновления представлений. Все представления, которые теоретически можно обновить, должны быть доступны для обновления.

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

8.  Правило независимости физических данных. Прикладные программы и утилиты для работы с данными должны на логическом уровне оставаться нетронутыми при любых изменениях способов хранения данных или методов доступа к ним.

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

10.  Правило независимости условий целостности. Должна существовать возможность определять условия целостности, специфические для конкретной реляционной базы данных, на подъязыке реляционной базы данных и хранить их в каталоге, а не в прикладной программе.

11. Правило независимости распространения. Реляционная СУБД не должна зависеть от потребностей конкретного клиента.

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

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

Правило 3 требует, чтобы отсутствующие данные можно было представить с помощью недействительных значений (NULL).

Правило 4 гласит, что реляционная база данных должна сама себя описывать. Другими словами, база данных должна содержать набор системных таблиц, описывающих структуру самой базы данных.

Правило 5 требует, чтобы СУБД использовала язык реляционной базы данных, например SQL. Такой язык должен поддерживать все основные функции СУБД – создание базы данных, чтение и ввод данных, реализацию защиты базы данных и т.д.

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

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

Правила 8 и 9 означают отделение пользователя и прикладной программы от низкоуровневой реализации базы данных. Они утверждают, что конкретные способы реализации хранения или доступа, используемые в СУБД, и даже изменения структуры таблиц базы данных не должны влиять на возможность пользователя работать с данными.

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

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

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

 

12.2. Нормализация.

При работе с отношениями, содержащими избыточные данные, могут возникать проблемы, которые называются аномалиями обновления и подразделяются на аномалии вставки, аномалии удаления и аномалии модификации. Рассмотрим, например, отношение, представленное на слайде (слайд 7).

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

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

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

Перечисленных аномалий можно избежать путем нормализации исходного отношения.

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

 

12.2.1. Функциональные зависимости

В основе процесса нормализации лежит концепция функциональной зависимости. Функциональная зависимость описывает связь между атрибутами отношения: если в отношении R, содержащем атрибуты A и B, атрибут B функционально зависит от атрибута A, то каждое отдельное значение атрибута A связано только с одним значением атрибута B (причем в качестве A и B могут выступать группы атрибутов). Атрибут или группа атрибутов A называются при этом детерминантом функциональной зависимости (слайд 8).

Таким образом, при наличии функциональной зависимости A→B кортежи (строки), имеющие одинаковое значение атрибута A, совпадают и по значению атрибута B. Однако обратное не верно: одно и то же значение атрибута B может соответствовать разным значениям атрибута A. Например, из функциональной зависимости Сотрудник→Должность следует, что везде, где будет указываться сотрудник «Еремеев В.К.», ему будет соответствовать должность «Профессор», но должность «Профессор» могут иметь и другие сотрудники. 

Функциональная зависимость A→B является полной функциональной зависимостью, если удаление какого-либо атрибута из группы атрибутов A приводит к потере этой зависимости. Функциональная зависимость A→B является частичной функциональной зависимостью, если в группе атрибутов A есть один или несколько атрибутов, при удалении которых эта зависимость сохраняется.

Если для атрибутов A, B и C некоторого отношения существуют функциональные зависимости A→B, B→C, говорят, что атрибут C связан транзитивной зависимостью с атрибутом A через атрибут B (при этом атрибут A не должен функционально зависеть ни от атрибута B, ни от атрибута C).

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

В качестве примера рассмотрим фрагмент таблицы «Прием экзаменов (зачетов)». Таблица отражает связь дисциплины и формы отчетности с фамилией преподавателя. В этой таблице существует многозначная зависимость «Дисциплина - Преподаватель»: дисциплину «Математический анализ» ведут несколько преподавателей (Раков И. И., Рыбин К. К., Карпов К. Ю.) и, соответственно, все они могут участвовать в приеме экзаменов (зачетов). Другая многозначная зависимость – «Дисциплина – Форма отчетности»: по одной и той же дисциплине может проводиться и экзамен, и зачет. При этом Форма отчетности и Преподаватель не связны функциональной зависимостью, что приводит к появлению избыточности (чтобы добавить фамилию еще одного преподавателя, придется ввести в таблицу две новых строки).

 

12.2.2. Нормальные формы

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

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

Реляционная таблица находится в первой нормальной форме (1НФ),  если (слайд 10)

-       каждое значение любого ее атрибута является атомарным;

-       в таблице отсутствуют одинаковые строки;

-       каждый столбец уникально поименован именем атрибута и содержит текущее значение этого атрибута;

-       каждый атрибут ассоциирован с определенным доменом (типом данных).

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

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

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

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

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

В следующих нормальных формах (4НФ и 5НФ) учитываются не только функциональные, но и многозначные зависимости между атрибутами. Для того чтобы привести определения этих нормальных форм, введем понятие полной декомпозиции таблицы (слайд 12).

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

Далее дадим определения высших нормальных форм (слайд 13).

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

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

 

12.3. Процедура нормализации (слайд 14)

Процедура приведения таблиц к 3НФ основывается на том, что единственными функциональными зависимостями в любой таблице должны быть зависимости вида А→K, где K - первичный ключ, а А - некоторый атрибут. Цель нормализации состоит в удалении других функциональных зависимостей.

Возможны два случая:

1. Таблица имеет составной первичный ключ, например, (К1,К2), и включает также атрибут А, который функционально зависит от части этого ключа (например, от К2), но не от полного ключа. В этом случае рекомендуется сформировать другую таблицу, содержащую атрибуты К2 и А (первичный ключ - К2), и удалить атрибут А из первоначальной таблицы (слайд 15).

2. Таблица имеет первичный (возможный) ключ К, атрибут А1, который не является возможным ключом, но функционально зависит от К, и другой не ключевой атрибут А2, который функционально зависит от А1. Решение здесь, по существу, то же самое, что и прежде - формируется другая таблица, содержащая атрибуты А1 и А2, с первичным ключом А1, а атрибут А2 удаляется из первоначальной таблицы (слайд 16).

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

12.4. Получение реляционной схемы из ER-диаграммы (слайд 17)

1. Каждая простая сущность превращается в таблицу (отношение). Имя сущности становится именем таблицы.

2. Связь «многие ко многим» рассматривается как сущность-связь и превращается в таблицу (отношение). Тем самым связь «многие ко многим» трансформируется в две связи «многое к одному».

3. Каждый атрибут становится возможным столбцом с тем же именем. Столбцы, соответствующие необязательным атрибутам, могут содержать неопределенные значения; столбцы, соответствующие обязательным атрибутам, - не могут. Если атрибут является множественным, то для него строится отдельное отношение.

4. Компоненты уникального идентификатора сущности превращаются в первичный ключ. Если имеется несколько возможных уникальных идентификаторов, выбирается наиболее используемый. Если в состав уникального идентификатора входят связи, то к числу столбцов первичного ключа добавляется копия уникального идентификатора сущности, находящейся на дальнем конце связи (этот процесс может продолжаться рекурсивно). Для именования этих столбцов используются имена концов связей и/или имена сущностей.

5. Связи «многие к одному» и «один к одному» становятся внешними ключами. Т.е. создается копия уникального идентификатора с конца связи "один", и соответствующие столбцы составляют внешний ключ.

6. Индексы создаются для первичного ключа (уникальный индекс), а также внешних ключей и тех атрибутов, которые будут часто использоваться в запросах.

7. Если в концептуальной схеме присутствуют подтипы, то возможны два варианта.

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

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

8. Если остающиеся внешние ключи все принадлежат одному домену, т.е. имеют общий формат, то создаются два столбца: идентификатор связи и идентификатор сущности. Столбец идентификатора связи используется для различения связей. Столбец идентификатора сущности используется для хранения значений уникального идентификатора сущности на дальнем конце соответствующей связи.

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