§ Атрибути, що входять до UID, позначаються символом "#"
Малюнок 3 Сутності з атрибутами в ER-діаграмі
Кожна сутність повинна мати зв'язок, що представляє інформаційні потреби і правила організації. Зв'язок (Relationship) - двунаправленная асоціація між двома сутностями або сутністю і їй самій (рекурсивна зв'язок).
Кожен напрямок зв'язку має (Малюнок 4):
§ Ім'я, наприклад, "бере участь в" або "закріплений за"
§ "має бути" - суцільна лінія на ER-діаграмі
§ "може бути" - пунктирна лінія на ER-діаграмі
§ "один і тільки один" - одиночна лінія на ER-діаграмі
§ "один або більше" - куряча лапка на ER-діаграмі
Рекурсивна зв'язок на ER-діаграмі позначається петлею.
Синтаксис уявлення зв'язків:
Кожен Співробітник може брати участь в одному або більше Проектів.
Кожен Проект повинен бути закріплений за одним або більше Працівників.
Кожен Співробітник може працювати під керівництвом одного і тільки одного Співробітника.
Кожен Співробітник може керувати одним або більше Співробітниками.
Малюнок 4 Подання зв'язків в ER-діаграмі
Унікальний ідентифікатор може складатися не тільки з атрибутів. Сутність може бути унікально помітна, також, за допомогою зв'язку. Наприклад, підпроект однозначно ідентифікується своїм номером, але, якщо проектів кілька, тоді номера підпроектів можуть повторюватися. Щоб, незважаючи на це, підпроект можна було однозначно ідентифікувати, номер проекту, що містить даний підпроект, також, повинен бути частиною унікального ідентифікатора (UID). На ER-діаграмі входження зв'язку в UID позначається поперечної рисою. Зв'язок, що входить в унікальний ідентифікатор, повинна бути обов'язковою з потужністю "один і тільки один" в напрямку, що має відношення до UID.
типи зв'язків
Існує три типи зв'язків:
§ Багато до одного
§ Багато до багатьох
Один до одного
Потужність "один і тільки один" в обох напрямках. Відображає такий характер відносин між об'єктами, коли кожного примірника однієї сутності відповідає тільки один екземпляр іншої сутності і навпаки. Це досить рідкісний вид зв'язку. Якщо при проектуванні бази даних з'являється такий вид зв'язку, рекомендується розглянути питання, чи не можна об'єднати ці дві сутності. Наприклад, якщо в нашому прикладі додати ще одну сутність "Паспортні дані", то зв'язок між цією сутністю і сутністю "Співробітник" буде "один до одного". У цьому випадку буде краще додати атрибут "паспортні дані" до суті "Співробітник".
Багато до одного
Потужність "один або більше" в одному напрямку і "один і тільки один" в іншому. Такий зв'язок в реляційної моделі зустрічається найбільш часто. У нашому прикладі такий зв'язок реалізована між сутностями "Підпроект" і "Проект".
Багато до багатьох
Потужність "один або більше" в обох напрямках. У нашому прикладі такий зв'язок реалізована між сутностями "Співробітник" і "Проект". Реляційна модель не дозволяє безпосередньо реалізувати зв'язок "багато до багатьох", тому що в цьому випадку не уникнути ситуації, коли множинні значення змушені зберігатися в одному стовпці, а це суперечить принципу неподільності, згідно з яким кожна клітинка повинна містити одну порцію даних. Таким чином, зв'язок "багато до багатьох" замінюється декількома зв'язками "багато до одного" і видається за допомогою сутності перетину (Малюнок 5).
Малюнок 5 Практична реалізація зв'язку «багато до багатьох» в ER-діаграмі
Не забувайте, що при логічному проектуванні системи необхідно нормалізувати модель даних, щоб усунути надмірність інформації.
Правила цілісності і ключі
Умови цілісності бази даних - це обмеження, спрямовані на збереження бази даних правильної і узгодженою. Дотримання цих обмежень має контролюватися сервером бази даних або прикладним додатком.
Обмеження, що забезпечують виконання бізнес-правил (наприклад, співробітник певного відділу не може брати участь в роботі над жодним проектом)
Сервер бази даних контролює цілісність даних за допомогою ключів:
Первинний ключ (PK) служить для унікальної ідентифікації рядка. Первинний ключ повинен бути унікальний і визначено. Первинний ключ може складатися з декількох стовпців (складовою первинний ключ). У складеному первинному ключі унікальною повинна бути комбінація значень в стовпцях, що становлять первинний ключ. Жодна частина первинного ключа не може містити невизначені значення.
Таблиця може мати кілька колонок, які претендують на роль первинного ключа (унікальних колонок). Унікальний ключ - стовпець або поєднання стовпців, які можуть використовуватися в якості первинного ключа. У цьому випадку один з таких унікальних ключів слід оголосити первинним ключем, а інші залишити унікальними (альтернативними) ключами.
Зовнішній ключ (FK) - стовпець або поєднання стовпців в одній таблиці, які містять посилання на первинний або унікальний ключ в тій же або іншій таблиці. Зовнішній ключ заснований на значеннях даних і є логічним покажчиком. Значення зовнішнього ключа повинні збігатися зі значеннями відповідних первинних або унікальних ключів або бути NULL. Якщо зовнішній ключ є частиною первинного ключа, він повинен бути визначений.
фізичне проектування
Після того, як побудована ER-модель бази даних, необхідно перетворити її в табличну модель і передбачити додаткові об'єкти, призначені для прискорення пошуку інформації (індекси) і зручності виведення даних (подання). Крім того, необхідно продумати, як краще зберігати об'єкти бази даних: на яких носіях, який обсяг пам'яті виділити. Саме фізичне проектування забезпечує продуктивність системи.
Відображення ER-моделі в табличну модель
Для відображення ER-моделі в табличну модель використовується бланк примірника таблиці бази даних. Бланк повинен містити ім'я таблиці бази даних, і являти собою таблицю, колонки якої є іменами стовпців таблиці бази даних, а рядки містять інформацію про ці шпальтах: типи ключів, обов'язковість і унікальність, зовнішні ключі, типи даних і максимальна довжина. Тут же рекомендується привести приклади даних, які будуть зберігатися у шпальтах таблиць бази даних.
При заповненні бланка примірника таблиці використовується власна система позначень: