Организация баз данных
к текущим действиям никакого отношения.
Например, может наблюдаться такая парадоксальная ситуация.
Отношение задано во второй нормальной форме, если оно является
отношением в первой нормальной форме и каждое свойство, не являющийся
первичным свойством в этом отношении, полностью зависит от любого
возможного ключа этого отношения.
Если все возможные ключи отношения содержат по одному свойству, то это
отношение задано во второй нормальной форме, так как в этом случае все
свойства, не являющиеся первичными, полностью зависят от возможных ключей.
Если ключи состоят более чем из одного свойства, отношение, заданное в
первой нормальной форме, может не быть отношением во второй нормальной
форме. Приведение отношений ко второй нормальной форме заключается в
обеспечении полной функциональной зависимости всех свойств от ключа за счет
разбиения таблицы на несколько, в которых все имеющиеся свойства будут
иметь полную функциональную зависимость от ключа этой таблицы. В процессе
приведения модели ко второй нормальной форме в основном исключаются
аномалии дублирования данных.
Отношение задано в третьей нормальной форме, если оно задано во второй
нормальной форме и каждое свойство этого отношения, не являющийся
первичным, не транзитивно зависит от каждого возможного ключа этого
отношения.
Транзитивная зависимость выявляет дублирование данных в одном
отношении. Если А, В и С - три свойства одного отношения и С зависит от В,
а В от А, то говорят, что С транзитивно зависит от А. Преобразование в
третью нормальную форму происходит за счет разделения исходного отношения
на два.
Таблица 2. Свойства и первичные ключи измененных или добавленных объектов
информационной модели.
|Объект |Первичный ключ |Свойства |
|ТОВАР |Уникальный ключ товара |Уникальный ключ товара |
| | |Уникальный ключ поставщика |
| | |Уникальный ключ заказчика |
| | |Наименование товара |
| | |Дата изготовления |
| | |Акцизная марка |
| | |Расшифровка штрих-кода |
| | |Срок годности |
| | |Вес Брутто |
| | |Вес Нетто |
| | |Цена за единицу |
| | |Суммарная цена |
| | |Вид упаковки |
|ЗАКАЗЧИК |Уникальный ключ заказчика |Уникальный ключ заказчика |
| | |Наименование заказчика |
| | |Юридическая принадлежность |
| | |Ф.И.О. руководителя |
| | |Адрес |
| | |Телефон/факс |
| | |Предполагаемая цена |
|ПОСТАВЩИК |Уникальный ключ поставщика|Уникальный ключ поставщика |
| | |Наименование поставщика |
| | |Юридическая принадлежность |
| | |Ф.И.О. руководителя |
| | |Адрес |
| | |Телефон/факс |
|СЧЕТА |Номер счёта |Номер счёта |
| | |Дата продажи |
| | |Уникальный ключ товара |
| | |НДС |
| | |Сумма к оплате |
|ДОГОВОР |Номер договора |Номер договора |
| | |Дата заключения |
| | |Уникальный ключ поставщика |
|НАКЛАДНЫЕ |Номер накладной |Номер накладной |
| | |Уникальный ключ заказчика |
| | |Пометка об оплате |
| | |Дата накладной |
Графическое представление второй таблицы
| | | |З |Н |
| | | | | |
| |Т | |П |Д |
| | | | | |
| | | |С | |
Табличная с определёнными связями, окончательная концептуальная модель.
| | |ТОВАР | | |
| | |Уник. ключ поставщика| | |
| | |Уник. ключ заказчика | | |
| | |Наименование товара | | |
| | |Дата изготовления | | |
| | |Акцизная марка | | |
| | |Расшиф. Штрих-кода | | |
|ЗАКАЗЧИК | |Срок годности | |ПОСТАВЩИК |
|Уник. ключ | |Вес Брутто | |Уник. ключ |
|заказчика | | | |поставщика |
|Наименов. | |Вес Нетто | |Наименов. поставщика|
|Заказчика | | | | |
|Юрид-ская. принад.| |Цена за единицу | |Юрид-ская. принад. |
|Ф.И.О. | |Суммарная цена | |Ф.И.О. руководителя |
|руководителя | | | | |
|Адрес | |Вид упаковки | |Адрес |
|Телефон/факс | |Уник. ключ товара | |Телефон/факс |
|Предполагаемая | | | |Номер договора |
|цена | | | | |
|Номер накладной | | | |Дата заключения |
|Пометка об оплате | | | | |
|Дата накладной | |СЧЕТА | | |
| | |Уник. ключ товара | | |
| | |Номер счёта | | |
| | |Дата продажи | | |
| | |НДС | | |
| | |Сумма к оплате | | |
Графическое представление концептуальной модели в третьей нормальной форме
| | | |З | |
| | | | | |
| |Т | |П | |
| | | | | |
| | | |С | |
Концептуальная модель переносится затем в модель данных, совместимую с
выбранной СУБД. Возможно, что отраженные в концептуальной модели
взаимосвязи между объектами окажутся впоследствии нереализуемыми средствами
выбранной СУБД. Это потребует изменения концептуальной модели. Версия
концептуальной модели, которая может быть обеспечена конкретной СУБД,
называется логической моделью.
Логическая модель отражает логические связи между элементами данных вне
зависимости от их содержания и среды хранения. Логическая модель данных
может быть реляционной, иерархической или сетевой. Пользователям выделяются
подмножества этой логической модели, называемые внешними моделями,
отражающие их представления о предметной области. Внешняя модель
соответствует представлениям, которые пользователи получают на основе
логической модели, в то время как концептуальные требования отражают
представления, которые пользователи первоначально желали иметь и которые
легли в основу разработки концептуальной модели. Логическая модель
отображается в физическую память, такую, как диск, лента или какой-либо
другой носитель информации.
Иерархическая модель данных строится по принципу иерархии типов
объектов, то есть один тип объекта является главным, а остальные,
находящиеся на низших уровнях иерархии, — подчиненными. Между главным и
подчиненными объектами устанавливается взаимосвязь «один ко многим». В то
же время для каждого экземпляра главного объекта может быть несколько
экземпляров подчиненных типов объектов. Взаимосвязи между объектами
напоминают взаимосвязи в генеалогическом дереве за единственным
исключением: для каждого порожденного (подчиненного) типа объекта может
быть только один исходный (главный) тип объекта.
Итак, полученную концептуальную модель, будем считать логико-
иерархической моделью данных. Потому что по моему мнению, больше
преобразований не получится. Конечную модель можно считать оконченной.
Физическая модель, определяющая размещение данных, методы доступа и
технику индексирования, назыв
| |  скачать работу |
Организация баз данных |
