3. Діаграма відношень логічних об'єктів-сутностей
Бази даних повинні проектуватися дуже акуратно, щоб гарантувати надійне й правильне зберігання даних. Найпоширеніший спосіб розробки бази даних складається в створенні моделі елементів даних і їхніх відношень. Концептуальна модель - це загальний опис баз даних, які не прив'язані до якого-небудь програмного забезпечення (Access, Oracle, SQL Server, SYBASE, DB2 і т.д.). Найпоширеніший метод зображення концептуальної моделі складається в створенні діаграми, що є візуальним поданням бази даних. Діаграми набагато полегшують розуміння відношенеь між елементами в базі даних.
Бази даних розробляються як групи зв'язаних об'єктів. Об'єкти відіграють роль іменників - це люди, місця, речі, що існують у світі (наприклад, співробітники, замовлення або книги). Відношення відіграють роль дієслів - вони показують дію (наприклад, покупець робить замовлення, співробітник є підлеглим, доктор лікує пацієнтів, а пацієнт може відвідати декількох докторів). Атрибути відіграють роль прикметників, які описують об'єкт. Прикладами атрибутів є ідентифікаційні номери, імена, телефонні номери тощо. Візуальна модель об'єктів і їхніх зв'язків називається діаграмою відношень логічних об'єктів-сутностей (ERD, або ER diagram, Entity-relationship diagram). У діаграмах відношень для подання об'єктів, їхніх атрибутів і зв'язків між ними використовуються символи.
Існує множина різних ERD і, на жаль, чіткого стандарту створення ERD немає. У наш час використовуються десятки різних ER-діаграм. Їхня кількість продовжує збільшуватися в міру того, як розроблювачі СУБД пропонують нові інструменти побудови діаграм разом зі своїми продуктами. Кілька років назад уважалося гарним тоном використовувати ERD, не пов'язані з конкретним продуктом розробки баз даних, будь він ієрархічний, мережний, реляційний або об’єктно-орієнтований. Згодом були розроблені стандарти, і розроблювачі могли вже не замислюватися про те, у якій системі буде використаний їхній проект. Сьогодні більшість професіоналів використовують ERD, дуже схожі на реляціні бази даних. Багато продуктів розробки баз даних навіть пропонують убудовані інструменти моделювання. Тому ми будемо використовуватим діаграму, схожу на ту, що використовується в програмах розробки баз даних. Об'єкти в цих діаграмах моделюються у вигляді таблиць (рамочок), зв'язки моделюються як сполучні лінії, а атрибути представляються у вигляді списків полів у рамках. Фактично ми будемо використовувати терміни об'єкт і таблиця й терміни атрибут і поле як синоніми. Власне кажучи, об'єкт -це людина, місце або річ, що існує в реальному світі; таблиця - це механізм, використовуваний для подання цієї людини, місця або речі.
Алфавит ER використовує лінії, що закінчуються «вороньєй лапкою», для подання зв'язків. Кожний зв'язок з'єднує батьківську таблицю з дочірньої. «Вороняччя лапка» завжди вказує на дочірню таблицю. На діаграмах на рис. 2.4 зображені зв'язки «один-до-багатьох» - приміром, один покупець робить кілька замовлень, один співробітник має декілько начальників. Таким чином, «покупець» - це батько, а «замовлення» - це нащадок, аналогічно «співробітник» - це батько, а «начальник» - це нащадок. Терміни батько й нащадок дуже часто використовуються при описі зв'язків у базах даних.
Рис. 2.4. Відношення «один-до-багатьох»
Рис. 2.5 Відношення «багато-до-багатьох»
Відношення «багато-до-багатьох» представлені на рис. 2.5. Доктор лікує декілько пацієнтів, а пацієнт може відвідати декілько докторів. Ви можете подумати, що потрібно малювати «вороняччу лапку» в обидва боки, але це було б неправильно, оскільки приведе до великого дублювання даних. Замість цього для подання відношень «багато-до-багатьох» потрібно створити нову асоціативну таблицю між двома даними, як показано на мал. 2.5. Будь-які інші варіанти приведуть до дублювання даних.
У таблиці атрибути представлені у вигляді полів. У випадку якщо атрибути - люди, поля найчастіше містять соціальну інформацію - ім'я, номер соціального страхування, дату народження, адреса тощо. Поля розташовуються усередині кожної таблиці, як показано на мал. 2.6.
Рис.2.6. Атрибути