Программирование >>  Проектирование баз данных 

1 ... 25 26 27 [ 28 ] 29 30 31 ... 184


Shipment

i Registration Number arture Date ! Name in

tination Consignment ->ignment ignment ignment Value o! II aaty

Cus Declaration Required

ненормализованная (повторяющаяся группа)

Shipment

I Registration Number , arture Date

Ship Name Ongin Destination Customs Value Ship Capacity

Customs Declaration Required

первая нормальная форма

Consighmenli


Number 0 Declared Value Consignee Insured Value

Рис. 3.11 Первая нормальная форма

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

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

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

существует уже упомянутое выще ограничение: превышение установленного числа экземпляров повторяющейся группы не допускается (в нашем случае это четыре партии).

Ясно, что мы столкнемся с серьезными проблемами, если наша модель не будет в первой нормальной форме! Чтобы нормализовать эту структуру в 1НФ, мы просто извлекаем данные о партиях (Consignment) из информации о грузе (Shipment) и помещаем их в отдельную структуру данных. Эта новая структура становится подчиненной структурой структуры Shipment, как показано на рис. 3.11.

Вторая нормальная форма (2НФ). Сущность находится во второй нормальной форме, если она находится в первой нормальной форме, а каждый



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

Продолжим рассматривать пример, приведенный на рис. 3.11. Ясно, что грузоподъемность корабля (Capacity) не зависит от даты убытия (Departure Date), а зависит лищь от самого корабля - за исключением крайне невероятного случая, когда каждый корабль после плавания переоборудуется.

На рис. 3.12 мы устраняем это и трансформируем нащу модель в 2НФ. Как и при преобразовании в 1НФ, это действие предполагает изъятие зависимых атрибутов из сущности Shipment и создание связанной подчиненной сущности (в данном случае называемой Ship).

Shipment

Departure Date Origin Destination Customs Value Customs Declaration Required

Consignment

Number -O Declared Value Consignee Insured Value

Ship

Registration Number

Name

Capacity

Puc. 3.12. Вторая нормальная форма

Если реализовать модель, не соответствующую 2НФ, то возникнут следующие проблемы.

Мы не сможем зарегистрировать название (Name) и грузоподъемность (Capacity) корабля (Ship), который еще не доставил ни одного груза, например, если он строится или заказан. Единственный путь рещения Этой проблемы - определить для него фиктивный груз (Shipment) - ужасный ляп!

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



Если корабль все-таки переоборудуется и получает новую грузоподъемность, как зарегистрировать этот простой факт? Обновить все записи Shipment, включая те, которые были созданы до переоборудования? Но в этом случае окажется, что корабль ранее плавал недогруженным, тогда как на самом деле он был полон. Если же мы решим обновить только те записи Shipment, которые появляются после переоборудования, то тоже возникнут проблемы, так как корабль не эксплуатируется и, вероятно, грузы для него отсутствуют.

Сушествуют и многие другие ямы , в которые мы можем попасть, если не обеспечим соответствие 2НФ. Ясно, что 2НФ - именно то, что нужно, но достаточно ли этого?

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

В наших примерах, приведенных на рис. 3.11 и 3.12, Customs Declaration Required ( Необходимость таможенной декларации ) является, по сути, свойством атрибутов Origin ( Пункт отправления ) и Destination ( Пункт назначения ). Если корабль плавает между двумя портами в одной стране или между двумя странами существует режим свободной торговли, то таможенной очистке груз не подлежит. Таким образом, пример на рис. 3.12 явно нарушает ЗНФ, так что давайте исправим его.

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

Shipment

Departure Date Customs Value

Ship

Registration Number

Name

Capacity

Route


Consignment

Number -O Declared Value Consignee Insured Value

Origin Destination

Customs Clearance Required

Рас. 3 13 Третья нормальная форма



1 ... 25 26 27 [ 28 ] 29 30 31 ... 184

© 2006 - 2024 pmbk.ru. Генерация страницы: 0
При копировании материалов приветствуются ссылки.
Яндекс.Метрика