Підкласи в об’єктно-орієнтованих системах
Існує значна подібність між зв’язком isa та відношенням підкласу до базового класу в об’єктно-орієнтованій мові. Розбіжності: в ER-проектуванні об’єкт може належати до різних підкласів, в ООП це, як правило, неможливо. Приклад:
Рис.2.13. Приклад можливої належності сутності до двох підкласів
У прикладі на рис.2.13 контрагент одночасно може бути і постачальником, і покупцем. В ООП для такого випадку доводиться створювати окремий підклас.
Приклад er-діаграми генеалогічної бд
Нижче наведений приклад ER-діаграми генеалогічної БД, яка містить зв’язки материнства, батьківства, шлюбу.
Не розглядаються:
одностатеві шлюби;
гареми (полігамія);
проміскуітет;
шведська родина;
розірвані шлюби.
Рис.2.14. ER-діаграма генеалогічної БД
Термін проміскуїтет був введений в XIX столітті для позначення стадії неврегульованих статевих стосунків у первісному людському суспільстві, що передували виникненню шлюбу і сім'ї. [http://ru.wikipedia.org/wiki/Промискуитет ]
Шведська сім'я — так в просторіччі називається форма поліаморії, при якій троє чоловік різної статі (один чоловік і дві жінки або двоє чоловіків і одна жінка) живуть разом, в одному приміщенні.
Принципи проектування er-моделі
Найбільші вади у проект закладаються на перших етапах, зокрема, етапі проектування ER-моделі. Ці вади існують у проекті довгі роки, оскільки їх важко виправити. Тому до цього етапу треба підходити дуже обачно. Виділяємо наступні принципи ER-проектування:
Достовірність
Множини сутностей та їхні атрибути мають відповідати реальним вимогам. Перед тим як уводити в модель нову множину сутностей, атрибут або зв’язок, треба спитати себе, чи все достеменно відомо про ту частину реального світу, яка має бути змодельована.
Відсутність надмірності
Зберігання одної інформації в кількох місцях крім зайвого розходу пам’яті, тягне більш серйозні наслідки: потенційні протиріччя (якщо зміни вносяться не у всі місця).
Приклад надмірності: в базі фільмів (рис.2.3) крім зв’язку Owns зберігати назву студії як властивість фільму.
Простота
Включайте в проект лише ті структурні елементи, без яких ніяк не можна обійтись.
Вибір підходящих зв’язків
Коли ми вирішуємо питання, чи потрібний той чи інший зв’язок, загальна відповідь така:
„Невідомо; рішення залежить від того, який сенс ми вкладаємо в кожний зв’язок.”
Приклад: У базі фільмів чи потрібний зв’язок Stars-in , чи не можна цю інформацію отримати з множини сутностей Contracts? Відповідь залежить від сенсу, який ми вкладаємо в Contracts. Зокрема, під цим ми можемо розуміти довгострокові контракти, які прямо не пов’язані зі зйомками фільмів; артист може бути наданий іншій студії для зйомок згідно окремого контракту між двома студіями.
Використання елементів адекватних типів
Зв’язок Багато до одного може бути замінений ідентифікуючим атрибутом, якщо окрема сутність із власними атрибутами не потрібна, і навпаки.
Рис.2.15. Ілюстрація використання елементів адекватних типів у ER-проектуванні.
Моделювання обмежень у er- моделі Класифікація обмежень
Приблизна класифікація обмежень:
Ключ (key) – атрибут або підмножина атрибутів, що унікальним чином визначає певну сутність у складі підмножини сутностей. Ніякі дві сутності не можуть мати однакові комбінації значень атрибутів, що складають ключ. Втім, припустимим є співпадання окремих, але не всіх, значень ключових атрибутів будь-яких двох сутностей.
Обмеження унікальності (single-value constraint): певне значення в певному контексті має бути унікальним. Ключ – приклад обмеження унікальності. Взагалі, це може бути значення на стороні один у зв’язку багато до одного.
Обмеження посилальної цілісності (referential integrity constraint): певне значення, на яке посилається інший об’єкт, має існувати в БД. Це є заборона на „висячі” посилання.
Обмеження домену (domain constraint): довільна вимога, яка також має бути зафіксована в БД, як-от: кожній сутності кінофільм може бути співставлено не більше 10 сутностей актор.