2.5 Определение первичных ключей
На основании рассмотренных выше связей между атрибутами объектов в качестве первичных ключей для каждого из объектов, я могу назвать следующие атрибуты:
Истец - код истца;
Ответчик - код ответчика;
Представитель ответчика - код представителя;
Иск - код иска;
Вид иска - код типа иска;
Перечень населенных пунктов - код населенного пункта.
2.6 Формирование концептуальной модели
На основании рассмотренных связей между объектами можно построить концептуальную модель предметной области «Каховский районный суд» (см. рисунок 2.2)
Рисунок 2.2 – Схема данных БД «Каховский районный суд»
2.7 Определение бинарных связей между объектами и построение er-диаграмм экземпляров сущностей
1. Истец подает Иск
Applicant_id Claim_id
1
000
4555
2
000
4556
3
000
4557
3000 4558
2. Представитель представляет Истца
Represent_id Applicant_id
1
000
4555
2
000
4556
3
000
4557
3000 4558
3. Истец проживает Населенный пункт
Applicant_id Town_id
1
000
4555
2
000
4556
3
000
4557
3000 4558
4. Ответчика вызывают по Иск
Respondent_id Claim_id
1
000
4555
2
000
4556
3
000
4557
3000 4558
Построим ER-диаграммы:
Во всех построенных ER-диаграммах тип связи между сущностями определен как 1 кN. Следовательно, для всех них применимо единое правило получение предварительных отношений, которое гласит: если степень бинарной связи определена как 1 кN, и класс принадлежности сущностей является обязательным, то необходимо построить 2 отношения. Причем в отношенииN-связной сущности необходимо добавить ключ односвязной сущности как атрибут.
2.8 Нормализация предварительных отношений
Нормализация – это разбиение таблицы на две или более, обладающих лучшими свойствами при включении, изменении и удалении данных. Окончательная цель нормализации сводится к получению такого проекта базы данных, в котором каждый факт появляется лишь в одном месте, т.е. исключена избыточность информации. Это делается не столько с целью экономии памяти, сколько для исключения возможной противоречивости хранимых данных.
Каждая таблица в реляционной БД удовлетворяет условию, в соответствии с которым в позиции на пересечении каждой строки и столбца таблицы всегда находится единственное атомарное значение, и никогда не может быть множества таких значений. Любая таблица, удовлетворяющая этому условию, называется нормализованной. Фактически, ненормализованные таблицы, т.е. таблицы, содержащие повторяющиеся группы, даже не допускаются в реляционной БД.
Всякая нормализованная таблица автоматически считается таблицей в первой нормальной форме, сокращенно 1НФ. Таким образом, строго говоря, "нормализованная" и "находящаяся в 1НФ" означают одно и то же. Однако на практике термин "нормализованная" часто используется в более узком смысле – "полностью нормализованная", который означает, что в проекте не нарушаются никакие принципы нормализации.
Теперь в дополнение к 1НФ можно определить дальнейшие уровни нормализации – вторую нормальную форму (2НФ), третью нормальную форму (3НФ) и т.д. По существу, таблица находится в 2НФ, если она находится в 1НФ и удовлетворяет, кроме того, некоторому дополнительному условию, суть которого будет рассмотрена ниже. Таблица находится в 3НФ, если она находится в 2НФ и, помимо этого, удовлетворяет еще другому дополнительному условию и т.д.
Таким образом, каждая нормальная форма является в некотором смысле более ограниченной, но и более желательной, чем предшествующая. Это связано с тем, что "(N+1)-я нормальная форма" не обладает некоторыми непривлекательными особенностями, свойственным "N-й нормальной форме". Общий смысл дополнительного условия, налагаемого на (N+1)-ю нормальную форму по отношению к N-й нормальной форме, состоит в исключении этих непривлекательных особенностей. Теория нормализации основывается на наличии той или иной зависимости между полями таблицы. Определены два вида таких зависимостей: функциональные и многозначные.
Функциональная зависимость. Поле В таблицы функционально зависит от поля А той же таблицы в том и только в том случае, когда в любой заданный момент времени для каждого из различных значений поля А обязательно существует только одно из различных значений поля В.
Полная функциональная зависимость. Поле В находится в полной функциональной зависимости от составного поля А, если оно функционально зависит от А и не зависит функционально от любого подмножества поля А.
Многозначная зависимость. Поле А многозначно определяет поле В той же таблицы, если для каждого значения поля А существует хорошо определенное множество соответствующих значений В.
Реляционная база данных содержит как структурную, так и семантическую информацию. Структура базы данных определяется числом и видом включенных в нее отношений, и связями типа "один ко многим", существующими между кортежами этих отношений. Семантическая часть описывает множество функциональных зависимостей, существующих между атрибутами этих отношений.
Можно сказать, что функциональные зависимости представляют собой связи типа "один ко многим", существующие внутри отношения.
Некоторые функциональные зависимости могут быть нежелательны.
Избыточная функциональная зависимость - зависимость, заключающая в себе такую информацию, которая может быть получена на основе других зависимостей, имеющихся в базе данных.
Корректной считается такая схема базы данных, в которой отсутствуют избыточные функциональные зависимости. В противном случае приходится прибегать к процедуре декомпозиции (разложения) имеющегося множества отношений. При этом порождаемое множество содержит большее число отношений, которые являются проекциями отношений исходного множества. Обратимый пошаговый процесс замены данной совокупности отношений другой схемой с устранением избыточных функциональных зависимостей называется нормализацией.
1NF - первая нормальная форма.
Для обсуждения первой нормальной формы необходимо дать два определения:
Простой атрибут - атрибут, значения которого атомарны (неделимы).
Сложный атрибут - получается соединением нескольких атомарных атрибутов, которые могут быть определены на одном или разных доменах. (его также называют вектор или агрегат данных).
Определение первой нормальной формы:
отношение находится в 1NF если значения всех его атрибутов атомарны.
2NF - вторая нормальная форма.
Очень часто первичный ключ отношения включает несколько атрибутов - в таком случае его называют составным. Не ключевой атрибут функционально полно зависит от составного ключа если он функционально зависит от всего ключа в целом, но не находится в функциональной зависимости от какого-либо из входящих в него атрибутов. Отношение находится во 2НФ, если оно находится в 1НФ и каждый не ключевой атрибут функционально полно зависит от ключа.
3NF - третья нормальная форма.
Перед обсуждением третьей нормальной формы необходимо ввести понятие транзитивной функциональной зависимости.
Пусть X, Y, Z - три атрибута некоторого отношения.
При этом X --> Y и Y --> Z, но обратное соответствие отсутствует, т.е. Z -/-> Y и Y -/-> X.
Тогда Z транзитивно зависит от X.
Отношение находится в 3НФ, если оно находится во 2НФ и каждый неключевой атрибут нетранзитивно зависит от первичного ключа.
BCNF - нормальная форма Бойса-Кодда.
Отношение находится в BCNF, если оно находится во 3НФ и в ней отсутствуют зависимости атрибутов первичного ключа от неключевых атрибутов.
Ситуация, когда отношение будет находится в 3NF, но не в BCNF, возникает при условии, что отношение имеет два (или более) возможных ключа, которые являются составными и имеют общий атрибут. Заметим, что на практике такая ситуация встречается достаточно редко, для всех прочих отношений 3NF и BCNF эквивалентны.
Рассмотрим полученные отношения реляционной базы данных на предмет функциональных зависимостей.
Объект «Aplicant_Represent_Table»
Represent_id -> Represent_FIO Authority, Represent_Phone
Объект « Applicant_Table»
Applicant_id -> Applicant_FIO, Applicant_adress, Applicant_adress_fact, Applicant_Phone, Applicant_Represent_FIO, Applicant_IK,, Applicant_Passport, Represent_id
Объект « Claim_Table »
Claim_id -> Claim_Type, Claim_Date, Claim_conditions, Claim_Evidence, Claim_requirements, Claim_docs, Claim_word_doc, Applicant_id, Claim_type_id, Town_id, Respondent_id
Объект « Claim_Type_Table»
Claim_type_id -> Claim_Type_Name
Объект « List_of_Towns»
List_of_Towns -> Town_name
Объект « List_Representative»
representative_id -> representative_name
Объект «List_Town»
Town_id ->Town_name
Объект «Respondent_Table»
Respondent_id -> Respondent_FIO, Respondent_adress, Respondent_adress, Respondent_adress_fact, Respondent_Phone, Respondent_IK, Respondent_IK
На основании рассмотренных выше функциональных зависимостей можно сделать вывод о том, что множество первичных ключей и детерминантов совпадают, а следовательно полученные в результате отношения находятся в нормальной форме Бойса-Кодда. Отношения, которые находятся в нормальной форме Бойса-Кодда, могут быть использованы для построения реляционной базы данных, следовательно, можно сделать вывод о том, что процесс нормализации завершен. Цель проектирования достигнута.
Структура таблицы Claim_Tableпредставлена на рисунке 2.3
Рисунок 2.3 – Таблица «Claim_Table»
Структура таблицы Respondent_Tableпредставлена на рисунке 2.4
Рисунок 2.4 – Таблица «Respondent_Table»
Структура таблицы Applicant_Table представлена на рисунке 2.5
Рисунок 2.5 – Таблица «Applicant_Table»
Структура таблицы Aplicant_Represent_Table представлена на рисунке 2.6
Рисунок 2.6 – Таблица «Aplicant_Represent_Table»
Структура таблицы Claim_Type_Table представлена на рисунке 2.7
Рисунок 2.7 – Таблица «Claim_Type_Table»
Структура таблицы List_of_Towns представлена на рисунке 2.8
Рисунок 2.8 – Таблица «List_of_Towns»