Ответы на вопросы по дисциплине «Базы данных и субд».
36. Модели систем управления данными: сетевая, иерархическая, реляционная модель. Нормальные формы (1нф, 2нф, 3нф, нфбк).
Модель данных – интегрированный набор понятий для описания и обработки данных, связей между ними и ограничений, накладываемых на данные в некоторой организации.
В
сетевой модели данные представлены
в виде коллекций записей, а связи – в
виде наборов. Сетевая БД состоит из
набора записей и набора связей между
этими записями. В отличие от реляционной
модели, связи здесь явным образом
моделируются наборами, которые реализуются
с помощью указателей. Сетевую модель
можно представить как граф с записями
в виде узлов графа и наборами в виде его
ребер. Пример сетевой модели:
Иерархическая модель является ограниченным подтипом сетевой модели. В ней данные также представлены как коллекции записей, а связи — как наборы. Однако в иерархической модели узел может иметь только одного родителя. Иерархическая модель может быть представлена как древовидный граф с записями в виде узлов (которые также называются сегментами) и множествами в виде ребер. Пример иерархической модели представлен ниже.
Реляционная модель данных основана на понятии математических отношений. В реляционной модели данные и связи представлены в виде таблиц, каждая из которых имеет несколько столбцов с уникальными именами. Ниже представлен пример реляционной схемы, содержащей сведения об отделениях компании и персонале организации.
Сущность Branch (отделения компании):
BranchId |
Street |
City |
1 |
22 Deer Rd |
London |
2 |
16 Argyll St |
Aberdeen |
Сущность Staff (сотрудники компании):
StaffId |
FirstName |
LastName |
BranchId |
1 |
John |
White |
1 |
2 |
Ann |
Ford |
2 |
3 |
David |
Brand |
1 |
Пользователь реляционной системы видит данные в виде таблиц и никак иначе. Важной отличительной особенностью реляционных систем является отсутствие указателей между записями (между отношениями Staff и Branch нет явно заданной связи; ее существование можно заметить, только зная, что атрибут BranchId в отношении Staff эквивалентен атрибуту BranchId в отношении Branch).
Большинство современных коммерческих систем основано на реляционной модели, тогда как самые первые системы баз данных создавались на основе сетевой или иерархической модели. При использовании сетевой или иерархической модели от пользователя требуется знание физической организации базы данных, к которой он должен осуществлять доступ, в то время как при работе с реляционной моделью независимость от данных обеспечивается в значительно большей степени. Следовательно, если в реляционных системах для обработки информации в базе данных принят декларативный подход (т.е. они указывают, какие данные следует извлечь), то в сетевых и иерархических системах — навигационный подход (т.е. они указывают, как их следует извлечь).
Нормализация – метод создания набора отношений с заданными свойствами на основе требований к данным, установленных в некоторой организации.
Пример отношения StaffBranch, содержащего избыточные данные:
StaffId |
Name |
Position |
Salary |
BranchId |
BranchAddress |
1 |
John White |
Manager |
30000 |
1 |
22 Deer Rd, London |
2 |
David Ford |
Assistant |
12000 |
2 |
163 Main St, Glasgow |
3 |
Susan Brand |
Supervisor |
18000 |
1 |
22 Deer Rd, London |
В отношении Staff Branch содержатся избыточные данные, поскольку сведения об отделении компании (BranchAddress) повторяются в записях, относящихся к каждому сотруднику данного отделения. В результате при работе с данным отношением могут возникнуть следующие проблемы (эти проблемы решаются при помощи нормализации):
Аномалии вставки. 1. При вставке сведений о новых сотрудниках в отношение Staf fBranch необходимо указать и сведения об отделении компании, в котором эти сотрудники работают. 2. Непонятно, как вставить сведения о новом отделении компании, которое еще не имеет собственных сотрудников.
Аномалии удаления. При удалении из отношения StaffBranch строки с информацией о последнем сотруднике некоторого отделения компании сведения об этом отделении будут полностью удалены из базы данных.
Аномалии модификации. При попытке изменения значения одного из атрибутов для некоторого отделения компании в отношении StaffBranch (например, адреса отделения) необходимо обновить соответствующие значения в строках для всех сотрудников этого отделения. Если такой модификации будут подвергнуты не все требуемые строки отношения StaffBranch., база данных будет содержать противоречивые сведения.
Для понимания нормализации необходимо знать определения из следующего вопроса (отношение, первичный ключ).
Ненормализованная форма (ННФ) – таблица, содержащая одну или несколько повторяющихся трупп данных.
Первая нормальная форма (1НФ) – отношение, в котором на пересечении каждой строки и каждого столбца содержится одно и только одно значение.
Пример ненормализованной формы:
ClientId |
ClientName |
PropertyId |
PropertyAddress |
1 |
John Kay |
1 2 |
6 Lawrence St Glasgow 5 Novar Dr, Glasgow |
2 |
Aline Stewart |
3 4 |
6 Lawrence St, Glasgow 2 Manor Rd, Glasgow |
В таблице хранится, какой клиент какой объект недвижимости арендует. Предполагается, что один и тот же клиент не может дважды арендовать один и тот же объект недвижимости. Видно, что клиенту John Kay соответствует 2 объекта (1 и 2), в результате на пересечении некоторых строк и столбцов находится 2 значения.
После приведения к 1НФ таблица ClientRental примет следующий вид:
ClientId |
ClientName |
PropertyId |
PropertyAddress |
1 |
John Kay |
1 |
6 Lawrence St, London |
1 |
John Kay |
2 |
5 Novar Dr, Glasgow |
2 |
Aline Stewart |
1 |
6 Lawrence St, London |
2 |
Aline Stewart |
2 |
5 Novar Dr, Glasgow |
Вторая нормальная форма (2НФ). Необходимо ввести следующие определения.
Функциональная зависимость. Описывает связь между атрибутами отношения. Если в отношении R, содержащем атрибуты А и В, атрибут B функционально зависит от атрибута А, то каждое значение атрибута А связано только с од«им значением атрибута B. (Атрибуты A и B могут состоять из одного или нескольких атрибутов). В примере выше атрибут ClientAddress функционально зависит от атрибута ClientId.
Детерминантом функциональной зависимости называется минимальная группа атрибутов, от которой зависит некоторый другой атрибут или группа атрибутов (в примере выше детерминантом является атрибут ClientId).
Полная функциональная зависимость. Если А и B – атрибуты отношения, то атрибут B находится в полной функциональной зависимости от атрибута А, если атрибут B является функционально зависимым от А, но не зависит ни от одного собственного подмножества атрибута A.
Вторая нормальная форма (2НФ) – отношение, которое находится в первой нормальной форме и каждый атрибут которого, не входящий в состав первичного ключа, характеризуется полной функциональной зависимостью от этого первичного ключа.
Рассмотрим получившуюся выше таблицу в 1НФ. Предполагается, что каждый клиент может арендовать объект недвижимости только однажды, поэтому первичным ключом является пара атрибутов (ClientId, PropertyId) (ClientId не является первичным ключом: как видно по таблице, клиент может встречаться несколько раз). Рассмотрим функциональную зависимость ClientId ClientName. Имеет место нарушение 2НФ: атрибут ClientName зависит от части первичного ключа – ClientId, а не от весго первичного ключа (ClientId, PropertyId). Аналогично, PropertyAddress зависит от части первичного ключа – атрибута PropertyId. Необходимо разбить отношение на 3:
Client:
ClientId |
ClientName |
1 |
John Kay |
2 |
Aline Stewart |
Property:
PropertyId |
PropertyAddress |
1 |
6 Lawrence St, London |
2 |
5 Novar Dr, Glasgow |
ClientRental:
ClientId |
PropertyId |
1 |
1 |
1 |
2 |
2 |
1 |
2 |
2 |
Третья нормальная форма (3НФ). Введем следующее определение.
Транзитивная зависимость. Если для атрибутов А, B и C некоторого отношения существуют зависимости вида A B и B C, это означает, что атрибут C транзитивно зависит от атрибута А через атрибут B (при условии, что атрибут А функционально не зависит ни от атрибута B, ни от атрибута C). Транзитивная зависимость является одним из типов функциональной зависимости.
Третья нормальная форма (ЗНФ). Отношение, которое находится в первой и во второй нормальных формах и не имеет атрибутов, не входящих в первичный ключ, которые находились бы в транзитивной функциональной зависимости от этого первичного ключа.
По-другому можно сформулировать так: отношение находится в 3НФ в том и только том случае, если все неключевые атрибуты отношения взаимно независимы и полностью зависят от первичного ключа.
Рассмотрим в качестве примера приведенное выше отношение StaffBranch:
StaffId |
Name |
Position |
Salary |
BranchId |
BranchAddress |
1 |
John White |
Manager |
30000 |
1 |
22 Deer Rd, London |
2 |
David Ford |
Assistant |
12000 |
2 |
163 Main St, Glasgow |
3 |
Susan Brand |
Supervisor |
18000 |
1 |
22 Deer Rd, London |
Атрибут BranchAddress зависит от BranchId, который в свою очередь функционально зависит от первичного ключа. Это пример нарушения 3НФ. Необходимо разбить отношение на два:
Staff:
StaffId |
Name |
Position |
Salary |
BranchId |
1 |
John White |
Manager |
30000 |
1 |
2 |
David Ford |
Assistant |
12000 |
2 |
3 |
Susan Brand |
Supervisor |
18000 |
1 |
Branch:
BranchId |
BranchAddress |
1 |
22 Deer Rd, London |
2 |
163 Main St, Glasgow |
1 |
22 Deer Rd, London |
Нормальная форма Бойса-Кодда (НФБК). Определение для 3НФ предполагает, что отношение имеет только один потенциальный ключ (а именно первичный ключ). В связи с этим было дано более строгое определение, учитывающее возможное наличие нескольких потенциальный ключей.
Нормальная форма Бойса-Кодда (НФБК). Отношение находится в НФБК тогда и только тогда, когда каждый его детерминант является потенциальным ключом.
Применим данное определение к отношению StaffBranch. Детерминант BranchId (BranchId является детерминантом, так как от него зависит BranchAddress) не является потенциальным ключом, следовательно, НФБК нарушена. Необходимо провести декомпозицию отношений, что и было сделано.