Логическое проектирование
Лекция №05, 06 - Логическое проектирование Нормализация
Описание: Логическое проектирование. Нормализация отношений. Необходимость нормализации. Аномалии добавления, удаления и обновления БД. Явная и неявная избыточность данных. Декомпозиция отношений. Понятие нормальной формы. 1-я, 2-я, 3-я, 4-я нормальные формы. Нормальная форма Бойса-Кодда. Устранение дефектов.
|
Содержание
[убрать]
- 1 Логическое проектирование базы данных
- 2 Нормализация и нормальные формы
- 2.1 Первая нормальная форма (1НФ)
- 2.2 Вторая нормальная форма (2НФ)
- 2.3 Третья нормальная форма (ЗНФ)
- 2.4 Нормальная форма Бойса-Кодда (НФБК)
- 2.5 Четвертая нормальная форма (4НФ)
- 3 Дефекты
- 3.1 Проблемы/дефекты ER моделирования
- 3.2 Дефекты типа "разветвление"
- 3.3 Дефекты типа "разрыв"
- 4 Аномалии
- 4.1 Аномалии вставки
- 4.2 Аномалии удаления
- 4.3 Аномалии обновления
- 5 Резюме
- 6 Дополнительная литература
- 7 Использованная литература
|
Логическое проектирование базы данных
Логическое проектирование базы данных - процесс создания модели используемой на предприятии информации на основе выбранной модели организации данных, но без учета типа целевой СУБД и других физических аспектов реализации.
Логическое проектирование является вторым этапом проектирования базы данных, на котором происходит уточнение и преобразование концептуальной модели, созданной на предыдущем этапе, в логическую модель данных. Логическая модель данных создается на основе выбранной модели организации данных целевой СУБД (реляционная, сетевая, иерархическая или объектно-ориентированная), но этапе игнорирует все остальные характеристики выбранной СУБД, например, любые особенности физической организации ее структур хранения данных и построения индексов.
В процессе разработки логическая модель данных постоянно тестируется и проверяется на соответствие требованиям пользователей. Для проверки правильности логической модели данных используется метод нормализации, который гарантирует, что отношения, выведенные из существующей модели данных, не будут обладать избыточностью данных, способной вызвать нарушения в процессе обновления данных после их физической реализации.
Созданная логическая модель данных является источником информации для этапа физического проектирования и предоставляет разработчику физической модели данных средства проведения всестороннего анализа различных аспектов работы с данными, что имеет исключительно важное значение для выбора действительно эффективного проектного решения. Логическая модель данных играет также важную роль на этапе эксплуатации и сопровождения уже готовой системы. При правильно организованном сопровождении поддерживаемая в актуальном состоянии модель данных позволяет точно и наглядно представить любые вносимые в базу данных изменения, а также оценить их влияние на прикладные программы и использование данных, уже имеющихся в базе. (Уже было в проектировании баз данных)
Нормализация и нормальные формы
Нормализация - метод создания набора отношений с заданными свойствами на основе требований к данным, установленных в некоторой организации.
Дополнительно: (Добавить перед резюме)
Процесс нормализации был впервые предложен Э. Ф. Коддом. Нормализация часто выполняется в виде последовательности тестов с целью проверки соответствия (или несоответствия) некоторого отношения требованиям заданной нормальной формы. Сначала были предложены только три вида нормальных форм: первая (1НФ), вторая (2НФ) и третья (ЗНФ). Затем Р. Бойсом и Э. Ф. Коддом было сформулировано более строгое определение третьей нормальной формы, которое получило название нормальной формы Бойса-Кодда (НФБК). Все эти нормальные формы основаны на функциональных зависимостях, существующих между атрибутами отношений, Нормальные формы более высокого порядка, которые превосходят НФБК, были введены позднее. К ним относятся четвертая (4НФ) и пятая (5НФ) нормальные формы. Но на практике эти нормальные формы более высоких порядков используются крайне редко.
Отношение было представлено как состоящее из некоторого количества атрибутов, а реляционная схема — из некоторого количества отношений. Атрибуты могут группироваться в отношения с образованием реляционной схемы на основе либо собственного опыта разработчика базы данных, либо посредством вывода реляционной схемы из разработанной ER-диаграммы. При использовании любого из этих двух подходов часто требуется применять определенный формальный метод, способный помочь проектировщику базы данных найти оптимальную группировку атрибутов для каждого отношения в схеме.
Процесс нормализации является формальным методом, позволяющим определять отношения на основе их первичных или потенциальных ключей и функциональных зависимостей, существующих между их атрибутами. Проектировщики баз данных могут использовать нормализацию в виде наборов тестов, применяемых к отдельным отношениям с целью нормализации реляционной схемы до заданной конкретной формы, что позволит предотвратить возможное возникновение аномалий обновления.
Нормализация — это формальный метод анализа отношений на основе их первичного ключа (или потенциальных ключей) и существующих функциональных зависимостей. Он включает ряд правил, которые могут использоваться для проверки отдельных отношений таким образом, чтобы вся база данных могла быть нормализована до желаемой степени. Если некоторое требование не удовлетворяется, то противоречащее данному требованию отношение должно быть разделено на отношения, каждое из которых (в отдельности) удовлетворяет всем требованиям нормализации.
Чаще всего нормализация осуществляется в виде нескольких последовательно выполняемых этапов, каждый из которых соответствует определенной нормальной форме, обладающей известными свойствами. В ходе нормализации формат отношений становится все более ограниченным (строгим) и менее восприимчивым к аномалиям обновления.
Дополнительно:
Связь нормальных форм
При работе с реляционной моделью данных важно понимать, что для создания отношений приемлемого качества обязательно только выполнение требований первой нормальной формы (1НФ). Все остальные формы могут использоваться по желанию проектировщиков. Но для того чтобы избежать аномалий обновления, нормализацию рекомендуется выполнять как минимум до третьей нормальной формы (ЗНФ). На рисунке показана взаимосвязь между различными нормальными формами. Согласно этому рисунку, некоторые отношения в форме 1НФ могут находиться также в форме ЗНФ, отношения 2НФ — в форме ЗНФ и т.д.
Предположим, что задано множество функциональных зависимостей для каждого от этого рисунка. Схема взаимосвязей между отдельными нормальными формами отношения и что в каждом отношении имеется назначенный первичный ключ. Эта информация имеет исключительно важное значение для нормализации и служит для проверки того, находится ли отношение в определенной нормальной форме.
Первая нормальная форма (1НФ)
Ненормализованная форма (ННФ) - таблица, содержащая одну или несколько повторяющихся групп данных.
Первая нормальная форма (1НФ) - отношение, в котором на пересечении каждой строки и каждого столбца содержится одно и только одно значение.
Для преобразования ненормализованной таблицы в первую нормальную форму (1НФ) в исходной таблице следует найти и устранить все повторяющиеся группы данных. Повторяющейся группой называется группа, состоящая из одного или нескольких атрибутов таблицы, в которой возможно наличие нескольких значений для единственного значения ключевого атрибута (атрибутов) таблицы. Существуют два способа исключения повторяющихся групп из ненормализованных таблиц.
- Повторяющиеся группы устраняются путем ввода соответствующих данных в пустые столбцы строк с повторяющимися данными, т.е. пустые места заполняются дубликатами неповторяющихся данных (этот способ частно называют "выравниванием" таблицы). Полученная таблица, теперь называемая отношением, содержит элементарные (или единственные) значения на пересечении каждой строки с каждым столбцом и поэтому находится в 1НФ. Однако, полученное отношение имеет определенную избыточность данных, устраняемую в ходе дальнейшей нормализации.
- Один атрибут или группа атрибутов назначаются ключом ненормализованной таблицы, а затем повторяющиеся группы изымаются и помещаются в отдельные отношения вместе с копиями ключа исходной таблицы, в новых отношениях устанавливаются свои первичные ключи. При наличии в ненормализованной таблице нескольких повторяющихся групп или повторяющихся групп, содержащихся в других повторяющихся группах, данный прием применяется до тех пор, пока повторяющихся групп совсем не останется. Полученный набор отношений будет находиться в первой нормальной форме только тогда, когда ни в одном из них не будет повторяющихся групп атрибутов. Данный способ находится в 1НФ и обладает меньшей избыточностью данных, чем первый способ.
При использовании первого подхода выровненное отношение 1НФ раскладывается в ходе дальнейшей нормализации на те же отношения, которые могли быть сразу же получены с помощью второго подхода.
Пример приведения таблицы к первой нормальной форме (Википедия)
Исходная, ненормализованная, таблица:
|
Сотрудник
|
Номер телефона
|
|
Иванов И. И.
|
283-56-82
390-57-34
|
|
Петров П. Ю.
|
708-62-34
|
Таблица, приведённая к 1NF:
|
Сотрудник
|
Номер телефона
|
|
Иванов И. И.
|
283-56-82
|
|
Иванов И. И.
|
390-57-34
|
|
Петров П. Ю.
|
708-62-34
|
Вторая нормальная форма (2НФ)
Полная функциональная зависимость: если А и B - атрибуты отношения, то атрибут B находится в полной функциональной зависимости от атрибута А, если атрибут B является функционально зависимым от А, но не зависит ни от одного собственного подмножества атрибута А.
Функциональная зависимость А->B является полной функциональной зависимостью, если удаление какого-либо атрибута из А приводит к утрате этой зависимости. Функциональная зависимость А->В называется частичной, если в А есть некий атрибут, при удалении которого эта зависимость сохраняется.
Вторая нормальная форма применяется к отношениям с составными ключами, т.е. к таким отношениям, первичный ключ которых состоит из двух или нескольких атрибутов. Дело в том, что отношение с первичным ключом на основе единственного атрибута всегда находится, по крайней мере, в форме 2НФ. Отношение, которое не находится в форме 2НФ, может быть подвержено аномалиям обновления.
Вторая нормальная форма (2НФ) - отношение, которое находится в первой нормальной форме и каждый атрибут которого, не входящий в состав первичного ключа, характеризуется полной функциональной зависимостью от этого первичного ключа.
Нормализация отношений 1НФ с приведением к форме 2НФ предусматривает устранение частичных зависимостей. Если в отношении между атрибутами существует частичная зависимость, то функционально-зависимые атрибуты удаляются из него и помещаются в новое отношение вместе с копией их детерминанта. (лучше переписать)
Детерминант - один атрибут или группа атрибутов, от которой полностью функционально зависит другой атрибут.
Пример приведения таблицы ко второй нормальной форме (Википедия)
Пусть Начальник и Должность вместе образуют первичный ключ в такой таблице:
|
Начальник
|
Должность
|
Зарплата
|
Наличие компьютера
|
|
Гришин
|
Кладовщик
|
20000
|
Нет
|
|
Васильев
|
Программист
|
40000
|
Есть
|
|
Васильев
|
Кладовщик
|
25000
|
Нет
|
Зарплату сотруднику каждый начальник устанавливает сам, но её границы зависят от должности. Наличие же компьютера у сотрудника зависит только от должности, то есть зависимость от первичного ключа неполная.
В результате приведения к 2NF получаются две таблицы:
|
Начальник
|
Должность
|
Зарплата
|
|
Гришин
|
Кладовщик
|
20000
|
|
Васильев
|
Программист
|
40000
|
|
Васильев
|
Кладовщик
|
25000
|
Здесь первичный ключ, как и в исходной таблице, составной, но единственный не входящий в него атрибут Зарплата зависит теперь от всего ключа, то есть полно.
|
Должность
|
Наличие компьютера
|
|
Кладовщик
|
Нет
|
|
Программист
|
Есть
|
Третья нормальная форма (ЗНФ)
Транзитивная зависимость: если для атрибутов А, В и С некоторого отношения существуют зависимости вида А->B и B->C, это означает, что атрибут C транзитивно зависит от атрибута А через атрибут B (при условии, что атрибут А функционально не зависит ни от атрибута В, ни от атрибута С).
Транзитивная зависимость является одним из типов функциональной зависимости.
Третья нормальная форма (ЗНФ) - отношение, которое находится и в первой и во второй нормальных формах и не имеет атрибутов, не входящих в первичный ключ атрибутов, которые находились бы в транзитивной функциональной зависимости от этого первичного ключа. (лучше переписать)
Нормализация отношений 2НФ с образованием отношений ЗНФ предусматривает устранение транзитивных зависимостей. Если в отношении существует транзитивная зависимость между атрибутами, то транзитивно зависимые атрибуты удаляются из него и помещаются в новое отношение вместе с копией их детерминанта.
Определения второй (2НФ) и третьей (ЗНФ) нормальных форм, приведенные выше, не допускают наличия частичных или транзитивных зависимостей от первичного ключа отношения, поскольку только при этом условии можно избежать аномалий обновления. Но в этих определениях не рассматриваются другие потенциальные ключи отношения, даже если они существуют. Приведем общие определения форм 2НФ и ЗНФ, в которых учитываются потенциальные ключи отношения.
Следует отметить, что реализация этого требования не влечет за собой корректировку определения формы 1НФ, поскольку эта нормальная форма не зависит от ключей и функциональных зависимостей. В качестве общих определений укажем, что атрибут первичного ключа входит в состав любого потенциального ключа и что частичные, полные и транзитивные зависимости рассматриваются с учетом всех потенциальных ключей отношения.
Вторая нормальная форма (2НФ) - отношение, находящееся в первой нормальной форме, в котором каждый атрибут, отличный от атрибута первичного ключа, является полностью функционально независимым от любого потенциального ключа.
Третья нормальная форма (ЗНФ) - отношение, находящееся в первой и второй нормальной форме, в котором ни один атрибут, отличный от атрибута первичного ключа, не является транзитивно зависимым ни от одного потенциального ключа.
При использовании этих общих определений форм 2НФ и ЗНФ необходимо убедиться в отсутствии частичных и транзитивных зависимостей от всех потенциальных ключей, а не только от первичного ключа. Такое требование может повлечь за собой усложнение процесса нормализации, но эти общие определения налагают дополнительные ограничения на отношения и могут позволить выявить скрытую избыточность в отношениях, которая в ином случае могла остаться незамеченной.
Необходимо найти компромисс между стремлением к максимальному упрощению процесса нормализации путем исследования зависимостей только от первичных ключей, что позволяет выявить лишь наиболее обременительную и очевидную избыточность в отношениях, и тенденцией к использованию общих определений для повышения вероятности выявления скрытой избыточности. Но на практике чаще всего результаты декомпозиции являются одинаковыми, независимо от того, используются ли определения форм 2НФ и ЗНФ, основанные на первичных ключах, или общие определения, приведенные в настоящем разделе.
Пример приведения таблицы к третьей нормальной форме (Википедия)
Исходная таблица: (Не указан первичный ключ)
|
Фамилия
|
Отдел
|
Телефон
|
|
Гришин
|
1
|
11-22-33
|
|
Васильев
|
1
|
11-22-33
|
|
Петров
|
2
|
44-55-66
|
В результате приведения к 3NF получаются две таблицы:
|
Фамилия
|
Отдел
|
|
Гришин
|
1
|
|
Васильев
|
1
|
|
Петров
|
2
|
|
Отдел
|
Телефон
|
|
1
|
11-22-33
|
|
2
|
44-55-66
|
Нормальная форма Бойса-Кодда (НФБК)
Отношения базы данных проектируются таким образом, чтобы можно было исключить в них присутствие частичных или транзитивных зависимостей, поскольку эти зависимости приводят к появлению аномалий обновления. До сих пор мы использовали определения второй и третьей нормальных форм, для получения которых требуется найти и исключить частичные и транзитивные зависимости от первичного ключа. Однако, как описано в разделе 13.8, в этих определениях не рассматриваются такие же зависимости от потенциальных ключей отношения, если таковые имеются, В разделе 13.8 приведены общие определения форм 2НФ и ЗНФ. Применение этих общих определений может позволить выявить дополнительную избыточность, вызванную зависимостями от всех потенциальных ключей. Но даже после ввода этих дополнительных ограничений в отношениях все еще могут существовать зависимости, которые приводят к появлению избыточности в отношениях ЗНФ, С учетом этого недостатка третьей нормальной формы была разработана более строгая нормальная форма, получившая название нормальной формы Бойса-Кодда (НФБК). (Не нужно)
Определение нормальной формы Бойса-Кодда
Нормальная форма Бойса-Кодда (НФБК) основана на функциональных зависимостях, в которых учитываются все потенциальные ключи отношения. Тем не менее в форме НФБК предусмотрены более строгие ограничения по сравнению с общим определением формы ЗНФ.
Нормальная форма Бойса-Кодда (НФБК): отношение находится в НФБК тогда и только тогда, когда каждый его детерминант является потенциальным ключом.
Для проверки принадлежности отношения к НФБК необходимо найти все его детерминанты и убедиться в том, что они являются потенциальными ключами. Напомним, что детерминантом является один атрибут или группа атрибутов, от которой полностью функционально зависит другой атрибут.
Различие между ЗНФ и НФБК заключается в том, что функциональная зависимость А—>В допускается в отношении ЗНФ, если атрибут В является первичным ключом, а атрибут А не обязательно является потенциальным ключом. Тогда как в отношении НФБК эта зависимость допускается только тогда, когда атрибут А является потенциальным ключом. Следовательно, нормальная форма Бойса-Кодда является более строгой версией формы ЗНФ, поскольку каждое отношение НФБК является также отношением ЗНФ, но не всякое отношение ЗНФ является отношением НФБК.
Пример приведения таблицы к нормальной форме Бойса—Кодда (Википедия)
Исходная таблица:
|
Номер клиента
|
Дата собеседования
|
Время собеседования
|
Номер комнаты
|
Номер сотрудника
|
|
С345
|
13.10.03
|
13.00
|
103
|
А138
|
|
С355
|
13.10.03
|
13.05
|
103
|
А136
|
|
С368
|
13.09.03
|
13.00
|
102
|
А154
|
|
С366
|
13.09.03
|
13.30
|
105
|
А207
|
В результате приведения к форме Бойса—Кодда получаются две таблицы:
|
Номер клиента
|
Дата собеседования
|
Время собеседования
|
Номер Сотрудника
|
|
С345
|
13.10.03
|
13.00
|
А138
|
|
С355
|
13.10.03
|
13.05
|
А136
|
|
С368
|
13.09.03
|
13.00
|
А154
|
|
С366
|
13.09.03
|
13.30
|
А207
|
|
Дата собеседования
|
Номер сотрудника
|
Номер комнаты
|
|
13.10.03
|
А138
|
103
|
|
13.10.03
|
А136
|
103
|
|
13.09.03
|
А154
|
102
|
|
13.09.03
|
А207
|
105
|
Четвертая нормальная форма (4НФ)
Как было сказано выше, НФБК позволяет устранить любые аномалии, вызванные функциональными зависимостями. Однако в результате теоретических исследований был выявлен еще один тип зависимости — многозначная зависимость (Multi-Valued Dependency — MVD), которая при проектировании отношений также может вызвать проблемы, связанные с избыточностью данных.
Возможность существования в отношении многозначных зависимостей возникает вследствие приведения исходных таблиц к форме 1НФ, для которой не допускается наличие некоторого набора значений на пересечении одной строки и одного столбца. Например, при наличии в отношении двух многозначных атрибутов для достижения непротиворечивого состояния строк необходимо повторить в них каждое значение одного из атрибутов в сочетании с каждым значением другого атрибута. Подобный тип ограничения порождает многозначную зависимость и приводит к избыточности данных.
Четвертая нормальная форма (4НФ) - отношение в нормальной форме Бойса-Кодда, которое не содержит нетривиальных многозначных зависимостей.
Четвертая нормальная форма (4НФ) является более строгой разновидностью нормальной формы Бойса-Кодда, поскольку в отношениях 4НФ нет нетривиальных многозначных зависимостей и поэтому нет и избыточности данных. Нормализация отношения НФБК с получением отношений 4НФ заключается в устранении многозначных зависимостей из отношения НФБК путем выделения в новое отношение одного или нескольких участвующих в МЗЗ атрибутов вместе с копией одного или нескольких детерминантов.
Пример приведения таблицы к четвертой нормальной форме (Википедия)
Предположим, что рестораны производят разные виды пиццы, а службы доставки ресторанов работают только в определенных районах города. Составной ключ таблицы такого отношения включает три поля: {Ресторан, Вид пиццы, Район доставки}.
Такая таблица не соответствует 4NF, так как существует многозначная зависимость:
- {Ресторан} >> {Вид пиццы}
- {Ресторан} >> {Район доставки}
То есть, например, при добавлении нового вида пиццы придется внести по одной новой записи для каждого района доставки. Возможна логическая аномалия, при которой определенному виду пиццы будут соответствовать лишь некоторые районы доставки из обслуживаемых рестораном районов.
Для предотвращения аномалии нужно разбить многозначную зависимость — разместить независимые факты в разных таблицах. В данном примере - {Ресторан, Вид пиццы} и {Ресторан, Район доставки}.
|
Исходная таблица
|
|
Ресторан
|
Вид пиццы
|
Район доставки
|
|
A1 Pizza
|
Thick Crust
|
Springfield
|
|
A1 Pizza
|
Thick Crust
|
Shelbyville
|
|
A1 Pizza
|
Thick Crust
|
Capital City
|
|
A1 Pizza
|
Stuffed Crust
|
Springfield
|
|
A1 Pizza
|
Stuffed Crust
|
Shelbyville
|
|
A1 Pizza
|
Stuffed Crust
|
Capital City
|
|
Elite Pizza
|
Thin Crust
|
Capital City
|
|
Elite Pizza
|
Stuffed Crust
|
Capital City
|
|
Vincenzo's Pizza
|
Thick Crust
|
Springfield
|
|
Vincenzo's Pizza
|
Thick Crust
|
Shelbyville
|
|
Vincenzo's Pizza
|
Thin Crust
|
Springfield
|
|
Vincenzo's Pizza
|
Thin Crust
|
Shelbyville
|
|
Ресторан
Вид пиццы
A1 Pizza
Thick Crust
A1 Pizza
Stuffed Crust
Elite Pizza
Thin Crust
Elite Pizza
Stuffed Crust
Vincenzo's Pizza
Thick Crust
Vincenzo's Pizza
Thin Crust
Ресторан
Район доставки
A1 Pizza
Springfield
A1 Pizza
Shelbyville
A1 Pizza
Capital City
Elite Pizza
Capital City
Vincenzo's Pizza
Springfield
Vincenzo's Pizza
Shelbyville
|
Объекты денормализации
- Большое количество соединений таблиц
- Расчетные значения
- Длинные поля
Дефекты
Проблемы/дефекты ER моделирования
Дефектами соединения (connection trap), обычно возникают вследствие неправильной интерпретации смысла некоторых связей. Мы рассмотрим два основных типа дефектов соединения: дефект типа "разветвление" (fan trap) и дефект типа "разрыв" (chasm trap), а также укажем способы выявления и устранения этих проблем в создаваемых ER-моделях.
В общем случае для выявления дефектов соединения необходимо убедиться в том, что смысл каждой связи определен четко и ясно. При недостаточном понимании сути установленных связей может быть создана модель, которая не будет являться истинным представлением реального мира.
Дефекты типа "разветвление"
Дефект типа разветвление
Дефект типа "разветвление". Имеет место в том случае, когда модель отображает связь между типами сущностей, но путь между отдельными сущностями этого типа определен неоднозначно.
Дефект типа "разветвление" возникает в том случае, когда две или несколько связей типа 1:М исходят из одной сущности. Потенциальный дефект типа "разветвление" показан на рисунке, на котором две связи типа 1:М (Has и Operates) исходят из одной и той же сущности Division.
На основании этой модели можно сделать вывод, что один отдел (Division) может состоять из нескольких отделений компании (Branch) и в нем может работать многочисленный штат сотрудников. Проблемы начинаются при попытках выяснить, в каком отделении компании работает каждый из сотрудников отдела.
Дефекты типа "разрыв"
Дефект типа разрыв
Дефект типа "разрыв". Появляется в том случае, когда в модели предполагается наличие связи между типами сущностей, но не существует пути между отдельными сущностями этих типов.
Дефект типа "разрыв" может возникать, если существует одна или несколько связей с минимальной кратностью, равной нулю (которая обозначает необязательное участие), и эти связи составляют часть пути между взаимосвязанными сущностями. На рисунке потенциальный дефект типа "разрыв" показан на примере связей между сущностями Branch, Staff и PropertyForRent.
Рассмотрев эту модель, можно сделать вывод, что одно отделение компании имеет много сотрудников, которые работают со сдаваемыми в аренду объектами. Однако не все сотрудники непосредственно работают с объектами и не все сдаваемые в аренду объекты недвижимости в каждый конкретный момент находятся в ведении кого-либо из сотрудников компании. В данном случае проблема возникает, когда необходимо выяснить, какие объекты недвижимости приписаны к тому или иному отделению компании.
Аномалии
Избыточность данных и аномалии обновления
Основная цель проектирования реляционной базы данных заключается в группировании атрибутов в отношения таким образом, чтобы минимизировать избыточность данных и тем самым сократить объем памяти, необходимый для физического хранения отношений, представленных в виде таблиц. Проблемы, связанные с избыточностью данных, можно проиллюстрировать, сравнив отношения Staff и Branch таблицах 1 и 2 с отношением StaffBranch таблице 3. Отношение StaffBranch является альтернативной формой представления отношений Staff и Branch. Упомянутые отношения описываются следующим образом:
- Staff (staffNo, sName, position, salary, branchNo)
- Branch (branchNo, bAddress)
- StaffBranch (staffNo, sName, position, salary, branchNo, bAddress)
Обратите внимание, что здесь первичный ключ каждого отношения выделен жирным начертанием.
|
Таблица 1
|
|
staffNo
|
sName
|
position
|
salary
|
branchNo
|
|
SL21
|
John White
|
Manager
|
30000
|
B005
|
|
SG37
|
Ann Beech
|
Assistant
|
12000
|
B003
|
|
SG14
|
David Ford
|
Supervisor
|
18000
|
B003
|
|
SA9
|
Mary Howe
|
Assistant
|
9000
|
B007
|
|
SG5
|
Susan Brand
|
Manager
|
24000
|
B003
|
|
SL41
|
Julie Lee
|
Assistant
|
9000
|
B005
|
|
Таблица 2
|
|
branchNo
|
bAddress
|
|
B005
|
22 Deer Rd, London
|
|
B007
|
16 Argyll St, Aberdeen
|
|
B003
|
163 Main St, Glasgow
|
|
Таблица 3
|
|
staffNo
|
sName
|
position
|
salary
|
branchNo
|
bAddress
|
|
SL21
|
John White
|
Manager
|
30000
|
B005
|
22 Deer Rd, London
|
|
SG37
|
Ann Beech
|
Assistant
|
12000
|
B003
|
163 Main St, Glasgow
|
|
SG14
|
David Ford
|
Supervisor
|
18000
|
B003
|
163 Main St, Glasgow
|
|
SA9
|
Mary Howe
|
Assistant
|
9000
|
B007
|
16 Argyll St, Aberdeen
|
|
SG5
|
Susan Brand
|
Manager
|
24000
|
B003
|
163 Main St, Glasgow
|
|
SL41
|
Julie Lee
|
Assistant
|
9000
|
B005
|
22 Deer Rd, London
|
В отношении Staff Branch содержатся избыточные данные, поскольку сведения об отделении компании повторяются в записях, относящихся к каждому сотруднику данного отделения. В противоположность этому в отношении Branch сведения об отделении содержатся только в одной строке, а в отношении Staff повторяется только номер отделения компании (branchNo), который представляет собой место работы каждого сотрудника. При работе с отношениями, содержащими избыточные данные, могут возникать проблемы, которые называются аномалиями обновления и подразделяются на аномалии вставки, удаления и модификации.
Аномалии вставки
Существуют два основных типа аномалий вставки, которые иллюстрируются с помощью отношения Staff Branch (см, таблицу 3).
- При вставке сведений о новых сотрудниках в отношение Staff Branch. необходимо указать и сведения об отделении компании, в котором эти сотрудники работают. Например, при вставке сведений о новом сотруднике отделения 'В007' требуется ввести сведения о самом отделении 'В007', которые должны соответствовать сведениям об этом же отделении в других строках отношения StaffBranch. Отношения, показанные в табл. 1 и 2, не подвержены влиянию этой потенциальной несовместимости данных, поскольку для каждого сотрудника в отношение Staff потребуется ввести только соответствующий номер отделения компании. Кроме того, сведения об отделении компании с номером 'BOO7' заносятся в базу данных однократно, в виде единственной строки отношения Branch.
- Для вставки сведений о новом отделении компании, которое еще не имеет собственных сотрудников, требуется присвоить значение NULL всем атрибутам описания персонала отношения StaffBranch, включая и табельный номер сотрудника staffNo. Но поскольку атрибут staffNo является первичным ключом отношения StaffBranch, то попытка ввести значение NULL в атрибут staffNo вызовет нарушение целостности сущностей и потому будет отклонена. Следовательно, в отношение StaffBranch невозможно ввести строку о новом отделении компании, содержащую значение NULL в атрибуте staffNo. Структура отношений, представленных в табл. 1 и 2, позволяет избежать возникновения этой проблемы, поскольку сведения об отделениях компании вводятся в отношение Branch независимости ввода сведений о сотрудниках. Сведения о сотрудниках, которые будут работать в новом отделении компании, могут быть введены в отношение Staff позже.
Аномалии удаления
При удалении из отношения Staff Branch строки с информацией о последнем сотруднике некоторого отделения компании сведения об этом отделении будут полностью удалены из базы данных. Например, после удаления из отношения Staff Branch строки для сотрудника 'Mary Howe с табельным номером ' SA9' из базы данных неявно будут удалены все сведения об отделении с номером В007 . Однако структура отношений, показанных в табл. 1 и 2, позволяет избежать возникновения этой проблемы, поскольку строки со сведениями об отделениях компании хранятся отдельно от строк со сведениями о сотрудниках. Связывает эти два отношения только общий атрибут branchNo. При удалении из отношения Staff строки с номером сотрудника ' SA9' сведения об отделении 'ВО07' в отношении Branch останутся нетронутыми.
Аномалии обновления
При попытке изменения значения одного из атрибутов для некоторого отделения компании в отношении Staff Branch (например, адреса отделения 'ВООЗ') необходимо обновить соответствующие значения в строках для всех сотрудников этого отделения. Если такой модификации будут подвергнуты не все требуемые строки отношения Staff Branch., база данных будет содержать противоречивые сведения. В частности, в нашем примере для отделения компании с номером 'ВООЗ' в строках, относящихся к разным сотрудникам, ошибочно могут быть указаны разные значения адреса этого отделения.
Все приведенные выше примеры иллюстрируют то, что представленные в табл. 1 и 2 отношения Staff и Branch обладают более приемлемыми свойствами, чем отношение Staff Branch, представленное в табл. 3. Это доказывает, что отношение Staff Branch подвержено аномалиям обновления, но этих аномалий можно избежать путем декомпозиции первоначального отношения на отношения Staff и Branch. С декомпозицией крупного отношения на более мелкие связаны два важных свойства. Во-первых, свойство соединения без потерь гарантирует, что любой экземпляр первоначального отношения может быть определен с помощью соответствующих экземпляров более мелких отношений. Во-вторых, свойство сохранения зависимостей гарантирует, что ограничения на первоначальное отношение можно поддерживать, просто применяя такие же ограничения к каждому из более мелких отношений. Иными словами, для проверки того, не нарушается ли ограничение, которое распространялось на первоначальное отношение, нет необходимости выполнять операции соединения на более мелких отношениях.
Резюме
Дополнительно:
- Тип сущности — это группа объектов с одинаковыми свойствами, которые характеризуются независимым существованием (с точки зрения проектировщика).
- Сущностью называется отдельный экземпляр типа сущности, который может быть однозначно идентифицирован.
- Тип связи — это множество осмысленных ассоциаций между типами сущностей. Экземпляром связи называется однозначно идентифицируемая ассоциация, которая включает по одному экземпляру сущности каждого типа, участвующих в этой связи,
- Степенью типа связи называется количество сущностей, участвующих в данной связи.
- Рекурсивной связью называется связь, в которой несколько раз участвует одна и та же сущность, но в разных ролях.
- Атрибутом называется свойство типа сущности или типа связи.
- Домен атрибута представляет собой множество допустимых значений, которые могут быть присвоены одному или нескольким атрибутам.
- Простой атрибут состоит из одного компонента, который характеризуется не зависимым существованием.
- Составной атрибут состоит из нескольких компонентов, каждый из которых характеризуется независимым существованием.
- Однозначный атрибут — это атрибут, содержащий по одному значению для каждого экземпляра сущности определенного типа.
- Многозначный атрибут — это атрибут, содержащий несколько значений для каждого экземпляра сущности определенного типа.
- Производным атрибутом называется атрибут, содержащий значение, производное от значения связанного с ним атрибута или множества атрибутов, причем не обязательно из той же сущности.
- Потенциальным ключом называется атрибут или набор атрибутов, которые однозначно идентифицируют отдельные экземпляры типа сущности,
- Первичным ключом называется некоторый выбранный потенциальный ключ сущности, однозначно идентифицирующий каждый экземпляр сущности определенного типа.
- Составным ключом является потенциальный ключ, который состоит из двух или нескольких атрибутов.
- Сильный тип сущности — это сущность, существование которой не зависит ни от какой другой сущности. Слабый тип сущности — это сущность, существование которой зависит от другой сущности.
- Кратностью называется количество (заданное как одно значение или как диапазон значений) возможных экземпляров типа сущности, которые могут быть связаны с одним экземпляром соответствующего типа сущности с помощью определенной связи.
- Кратностью сложной связи называется количество (заданное как одно значение или как диапазон значений) возможных экземпляров типа сущности в n-арной связи, которое регистрируется после фиксации остальных (n-1) значений.
- Кардинальность описывает максимальное количество возможных связей для каждой сущности, участвующей в связи данного типа.
- Степень участия определяет, должны ли участвовать в конкретной связи все или только некоторые экземпляры сущности.
- Дефект типа "разветвление" возникает, если в модели данных представлена некоторая связь между типами сущностей, но путь между некоторыми экземплярами сущности определен неоднозначно.
- Дефект типа "разрыв" возникает, когда в модели предполагается связь между типами сущностей, но не существует пути между некоторыми экземплярами сущностей.
Логическое проектирование