Етап 1.5. Визначення атрибутів, що є потенційними та первинними ключами

На цьому етапі потрібно визначити домени атрибутів, поміщених у локальну концептуальну модель даних для представлень «Автотранспортного підприємства». Доменом називають безліч припустимих значень для одного або більше атрибутів.

Потенційним ключем називається атрибут чи набір атрибутів, що унікальним образом ідентифікують окремі екземпляри типу сутності.

Первинним ключем називається деякий обраний потенційний ключ сутності.

Складеним ключем є потенційний ключ, що складається з двох і більше атрибутів.

Таблиця 2. 5. Сутності і їх первинні й альтернативні ключі

Сутність	Первинний ключ	Альтернативний ключ
Підприємство	Номер
Головний інженер	Номер
Диспетчер	Номер
Водій	Номер
Автомобіль	Номер	Державний номер
Маршрут	Номер
Бригада	Номер
Вантаж	Номер
Клієнт	Номер	Телефон
Замовлення	Номер

Етап 1.6. Спеціалізація або генералізація типів сутностей

На цьому етапі приймаються (необов'язкові) заходи для поліпшення вихідного варіанта ER-діаграми за допомогою застосування процедури генералізації або спеціалізації сутностей. При проведенні спеціалізації потрібно виділити розходження між сутностями, при генералізації навпаки – шукаються загальні характеристики сутностей.

Спеціалізація - це процес виявлення максимально можливої кількості розходжень між членами сутності шляхом виділення їхніх різних рис.

Генералізація - це процес виявлення мінімально можливої кількості розходжень між членами сутності шляхом виділення їх загальних рис.

Розглянемо взаємини між сутностями, що представляють працівників підприємства. У специфікаціях визначено три типи подібних сутностей Головний інженер, Диспетчер і Водій. Ці сутності багато однакових атрибутів, як показано на рис.2.1.

Таким чином виконаємо генералізацію сутностей.

Рис. 2. 1. Генералізація сутностей

Етап 1.7. Створення діаграми „сутність - зв’язок”

Для наочного представлення основних сутностей і зв’язків, визначених у специфікаціях, будується діаграма (ORM Source Model)

Рис. 2. 2. Діаграма «сутність-зв’язок»

Етап 1.8. Обговорення локальної концептуальної моделі даних з кінцевими користувачами

Перш ніж завершити виконання першого етапу розробки бази даних, необхідно обговорити створені локальні концептуальні моделі з користувачами. При виявленні яких-небудь помилок варто внести в проект відповідні зміни, для чого буде потрібно повернутися до виконання попередніх етапів. Цей цикл повинний повторюватися доти, поки користувач не погодиться з тим, що запропонований йому проект вірно відбиває представлення кожного типу користувача про роботу підприємства.

Розділ 3. Логічне проектування бази даних

Етап 2. Побудова та перевірка локальної логічної моделі даних на основі представлення про предметну область кожного з типів користувачів

На цьому етапі ми переробимо локальну концептуальну модель даних представлень з метою видалення з неї всіх елементів, що ускладнюють реалізацію даної моделі в середовищі реляційних СУБД. Крім того, ми перевіримо створену логічну модель даних, застосувавши до неї правила нормалізації і контролю можливості виконання всіх необхідних користувачеві транзакцій у тому вигляді, у якому вони описані в специфікаціях. Після завершення процесу перетворення структури концептуальної моделі з метою задоволення вимог, пропонованих до структури даних з боку реляційних СУБД, ми будемо посилатися на перетворену модель як на логічну модель даних.