L
? оклад; int NOT NULL
· Диспетчеризація
? номер автобуса; int NOT NULL FK
? номер прав водія; int NOT NULL FK
? номер маршруту; int NOT NULL FK
? таб. номер контролера; int NOT NULL FK
? дата виїзду; date NOT NULL
· Валідатор
? номер валідатора; int NOT NULL PK
? номер автобуса; int NULL FK
· Валідація
? номер валідатора; int NOT NULL FK
? дата виїзду; date NOT NULL FK
? таб. номер контролера; int NOT NULL FK
? число пасажирів; int NOT NULL
? кол-во посадок контролера; int NOT NULL
При переході від інфологічної моделі до реляційної була розкрита зв'язок М: М між відносинами «Водитель» та «Автобус». Ставленням-зв'язкою в даному випадку стало ставлення «Диспетчеризація». У нього в якості FK був доданий атрибут «номер прав водія», який увійшов до складу композитного PK. Виходячи з наведених вище відносин, побудуємо схему вийшла БД (Рис. 2.6)
Рис 2.6 Схема реляційної моделі БД до нормалізації
. 4 Нормалізація, схема бази даних
Побудова коректної схему РБД в процесі датологіческой проектування тісно пов'язаний з поняттям нормалізації (спосіб декомпозиція, зазначений вище).
Нормалізація - це процес перетворення БД до виду, відповідальному нормальним формам (НФ), шляхом розбиття вихідного безлічі відносини на більше, частина яких є проекціями. Нормалізація має своєю метою усунути надмірність БД.
Поняття нормалізації тісно пов'язане з поняттям функціональної залежності. Функціональна залежність (ФЗ) визначає відносини між об'єктами та їх властивостями в розглянутій ПО.
ФЗ RA RB називається повною, якщо набір атрибутів B ФЗ від A і не залежить функціонально від будь-якої підмножини А.
ФЗ R.А R.В називається транзитивної, якщо існує такий набір атрибутів С, який задовольняє наступним властивостям: 1. С? А; 2. У? С; 3. існує ФЗ
R.А R.С; 4. не існує ФЗ R.С R.А; 5. не існує ФЗ R.С R.B.
НФ - відносини знаходиться в 1НФ, якщо на перетині кожного стовпця і кожного рядка знаходяться тільки елементарні значення атрибутів. Дане визначення є надлишковим, тому в РБД на перетині рядка і стовпця і так знаходяться тільки одне значення. Тому всі відносини спочатку знаходяться в 1НФ.
НФ - відношення знаходиться в 2НФ, якщо воно знаходиться в 1НФ і не містить неповних ФЗ не первинні атрибутів від первинного ключа.
Відносини «Водитель», «Автобус», «Маршрут», «Контролер» і «Валідатор» знаходяться в 2НФ, тому у ні не складова ключ.
У відношенні «Диспетчеризація» існує не повна ФЗ. Атрибути «час виїзду з парку» і «час прибуття в парк" не залежать від частини складного ключа «таб. номер контролера ». У зв'язку з цим відношення «Диспетчеризація» розпадається на 2-а:
· Диспетчеризація
? номер автобуса; int NOT NULL FK
? номер прав водія; int NOT NULL FK
? номер маршруту; int NOT NULL FK
? дата виїзду; date NOT NULL
· Розподіл
? номер маршруту; int NOT NULL FK
? таб. номер контролера; int NOT NULL FK
? дата виїзду; date NOT NULL
Дані відносини знаходяться в 2НФ.
У відношенні «Валідація» теж існують не повні ФЗ. Атрибут «число пасажирів» не залежить від частини складного ключа «таб. номер контролера ». У зв'язку з цим відношення «Валідація» розпадається на 2-а:
· Валідація
? номер валідатора; int NOT NULL FK
? дата виїзду; date NOT NULL FK
? число пасажирів; int NOT NULL
· Відвідуваність
? номер валідатора; int NOT NULL FK
? дата виїзду; date NOT NULL FK
? таб. номер контролера; int NOT NULL FK
? кол-во посадок контролера; int NOT NULL
Дані відносини знаходяться в 2НФ.
НФ - відношення знаходиться в 3НФ, якщо воно знаходиться у 2НФ і не містить транзитивних залежностей. Всі відносини даної моделі знаходяться в 3НФ, тому ні в жодному з них немає транзитивних залежностей.
