7. Функциональные зависимости

При проектировании базы данных необходимо определить уникальность данных, называемая функциональной зависимостью. Это ограничение позволяет избежать избыточности информации. Функциональная зависимость – это утверждение о том, что две записи, совпадающие в двух атрибутах, должны совпадать и в остальных атрибутах. Для реализации функциональной зависимости используются ключи и суперключи. Суперключ – множество атрибутов, которые функционально обуславливают все остальные атрибуты отношения. Ключ – суперключ, ни одно из подмножеств которого не в состоянии функционально обосновать все другие атрибуты отношения. [3]

Как было сказано ранее, все таблицы нормализованы по третьей форме.

Ключевым полем (первичный ключ) в таблице «clients» является поле e_mail так, как при регистрации электронной почты требуется уникальность e-mail. Остальные поля отношения не могут быть уникальными и определять остальные.

В таблице «publishing» вводится специальное поле ID – уникальный идентификатор как уникальное так, как названия издательств могут повторяться и в одном городе может находиться несколько издательств.

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

В таблице «product» все поля могут повторяться, так несколько клиентов могут заказать книгу с одинаковым тиражом и содержанием. Вводится ID как первичный ключ.

В таблице «inks» уникальным полем является color. От цвета краски зависит ее стоимость, расход, и цена лакировки.

В таблице «substrate» уникальным будет сочетание type, strength именно от этих параметров зависит стоимость материала.

В таблице «plate» уникальным является поле type. Все печатные формы разделяются по типу печати. И для каждого типа формы ставится в соответствие цена и время на изготовление.

В таблице «stitching» уникальным атрибутом является тип брошюровочных работ. Стоимость определятся типом сшивания.

8. Начальное заполнение таблиц

Для демонстрации особенностей базы данных, работы типовых запросов, триггеров и хранимых процедур созданные таблицы заполняются тестовыми данными. Ниже приведены заполненные таблицы. Исходные коды заполнения базы данных приведены в приложении A листинг 2.

На рис. 3 изображено заполнение таблицы «clients» тестовыми данными.

Рис. 3. Данные таблицы “clients”.

На рис. 4 изображено заполнение таблицы «publishing» тестовыми данными.

Рис. 4. Данные таблицы “publishing”.

На рис. 5 изображено заполнение таблицы «orders» тестовыми данными.

Рис. 5. Данные таблицы “orders”.

На рис. 6 изображено заполнение таблицы «product» тестовыми данными.

Рис. 6. Данные таблицы “product”.

На рис. 7 изображено заполнение таблицы «inks» тестовыми данными.

Рис. 7. Данные таблицы “inks”.

На рис. 8 изображено заполнение таблицы «plate» тестовыми данными.

Рис. 8. Данные таблицы “plate”.

На рис. 9 изображено заполнение таблицы «substrate» тестовыми данными.

Рис. 9. Данные таблицы “substrate”.

На рис. 10 изображено заполнение таблицы «stitching» тестовыми данными.

Рис. 10. Данные таблицы “stitching”.

На рис. 11 изображено заполнение таблицы «clts2pub» тестовыми данными.

Рис. 11. Данные таблицы “clts2pub”.

На рис. 12 изображено заполнение таблицы «clts2Ord» тестовыми данными.

Рис. 12. Данные таблицы “clts2Ord”.

На рис. 13 изображено заполнение таблицы «ord2prod» тестовыми данными.

Рис. 13. Данные таблицы “ord2prod”.

На рис. 14 изображено заполнение таблицы «ink2prod» тестовыми данными.

Рис. 14. Данные таблицы “ink2prod”.

На рис. 15 изображено заполнение таблицы «sub2prod» тестовыми данными.

Рис. 15. Данные таблицы “sub2prod”.

На рис. 16 изображено заполнение таблицы «stitch2prod» тестовыми данными.

Рис. 16. Данные таблицы “stitch2prod”.

На рис. 17 изображено заполнение таблицы «plate2prod» тестовыми данными.

Рис. 17. Данные таблицы “plate2prod”.