
- •Організація баз даних
- •1. Бази даних
- •1.1. Приклад бази даних
- •1.2. Вимоги до бази даних
- •3. Інфологічна модель даних "сутність — зв'язок"
- •3.1. Основні елементи моделі
- •3.5. Класи сутностей
- •3.7. Поняття "ключ бази даних"
- •4. Даталогічні моделі даних
- •4.1. Ієрархічна модель
- •Задачі для самостійної роботи
3.5. Класи сутностей
В літературі визначають три основні класи сутностей: стрижневі, асоціативні та характеристичні, а також підклас асоціативних сутностей — позначення.
Стрижнева сутність (стрижень) — це незалежна сутність. У розглянутих раніше прикладах стрижні — це СТУДЕНТ, КВАРТИРА, ЧОЛОВІК, ЛІКАР, ШЛЮБ (з прикладу 2) та інші, назви яких розміщені в прямокутниках.
Асоціативна сутність (асоціація) — це зв'язок вигляду"багато-до-багатьох" та "один-до-багатьох" між двома або більше сутностями або екземплярами сутності (як у прикладі 4). Асоціації розглядаються як повноправні сутності:
вони можуть брати участь в інших асоціаціях і позначеннях так само, як стрижневі сутності;
можуть мати властивості, тобто мати не тільки набір ключових атрибутів, необхідних для вказівки зв'язків, але і будь-яке число інших атрибутів, що характеризують зв'язок. Наприклад, асоціації ШЛЮБ із прикладів 1 і 4 містять ключові атрибути {"Код_М", "Код_Ж" і "Табельний номер чоловіка", "Табельний номер дружини"}, а також уточнюючі атрибути: "Номер свідоцтва", "Датареєстрації', "Місцереєстрації', "Номер запису в книзі ЗАГС" тощо.
Характеристична сутність (характеристика) — це зв'язок вигляду "багато-до-одного" або "один-до-одного" між двома сутностями. Єдина мета характеристики в рамках аналізованої предметної галузі складається в описі або уточненні якоїсь іншої сутності.
Необхідність у цьому виникає у зв'язку з тим, що сутності реального світу мають іноді багатозначні властивості. Чоловік може мати декілька дружин (приклад 3), книга — декілька характеристик перевидання (доповнене, перероблене,...) тощо. Існування характеристики цілком залежить від відповідної сутності: жінки позбавляються статусу дружин, якщо вмирає їхній чоловік.
Для опису характеристики використовується нова пропозиція МІМ, що має в загальному випадку вигляд:
ХАРАКТЕРИСТИКА (атрибут 1, атрибут 2, ..,)
(СПИСОК ХАРАКТЕРИЗОВАНИХ СУТНОСТЕЙ).
Позначаюча сутність, або позначення — це зв'язок вигляду "багато-до-одного" або "один-до-одного" між двома сутностями і відрізняється від характеристики тим, що не залежить від позначеної сутності.
Розглянемо приклад, пов'язаний із зарахуванням співробітників у різноманітні відділи організації. За відсутності жорстких правил (співробітник може одночасно зараховуватися в декілька відділів або не зараховуватися в жоден відділ) необхідно створити опис з асоціацією "Зарахування":
Відділи (Номер відділу, Назва відділу, ,..)
Службовці (Табельний номер, Прізвище, ...)
Зарахування [Відділи М, Службовці N]
(Номер відділу, Табельний номер,;Дата зарахування).
Проте, за умови, що кожний із співробітників повинен бути обов'язково зарахований в один із відділів, можна створити опис із позначенням "Службовці":
Відділи (Номер відділу, Назва відділу, ...)
Службовці (Табельний номер, Прізвище, … Номер відділу)
Датазарах, (Відділи)
У цьому прикладі службовці мають незалежне існування (якщо розформується відділ, то з цього не випливає, що також повинні бути звільнені службовці такого відділу), тому вони не можуть бути характеристиками відділів і названі позначеннями.
Позначення використовують для збереження повторюваних значень великих текстових атрибутів: "кодифікатори" дисциплін, найменувань організацій і їхніх відділів, переліку товарів тощо.
Опис позначення зовнішньо відрізняється від опису характеристики тільки тим, що позначені сутності записуються не у фігурних дужках, а в квадратних:
ПОЗНАЧЕННЯ (атрибут 1, атрибут 2, ...) [СПИСОК ПОЗНАЧЕНИХ СУТНОСТЕЙ].
Як правило, позначення не розглядаються як повноправні сутності, хоча де не призводить до помилок.
Позначення і характеристики не є цілком незалежними сутностями, оскільки вони припускають наявність деякої іншої сутності, яка буде "позначатися" або "характеризуватися". Про те вони все ж є окремими випадками сутності і можуть, звичайно, мати властивості, можуть брати участь в асоціаціях, позначеннях і мати свої власні (більш низького рівня) характеристики. Підкреслимо також, що всі екземпляри характеристики повинні бути обов'язково пов'язані з яким-небудь екземпляром характеризованої сутності. Проте припускається, щоб деякі екземпляри характеризованої сутності не мали зв'язків.
Можна також визначити стрижневу сутність як сутність, що не є ані асоціацією, ані позначенням, ані характеристикою. Такі сутності мають незалежне існування, хоча вони і можуть позначати інші сутності, як, наприклад, співробітники позначають відділи.
3.6. Приклад інфологічної моделі бази даних
Розглянемо приклад побудови інфологічної моделі бази даних Харчування, у яких має зберігатися інформація про страви, їх щоденне споживання, продукти, із яких вони готуються, постачальників продуктів. Інформація буде використовуватися кухарем і керівником невеликого ресторану, а також його відвідувачами.
За допомогою користувачів виділені такі об'єкти та характеристики проектованої бази.
Страви, для опису яких потрібні такі дані: номер страви з книги кулінарних рецептів, назва страви, вид страви (закуска, суп, друга страва тощо), рецепт (технологія приготування страви), вихід (вага порції), назва, калорійність і вага кожного продукту, що входить у страву.
Для кожного постачальника продуктів: найменування, адреса, назва продукту, що поставляється, дата постачання та ціна на момент постачання.
Щоденне споживання страв (витрати): страва, кількість порцій,дата.
Аналіз об'єктів дозволяє виділити:
стрижні Страви, Продукти і Міста,
асоціації Склад (зв'язує Страви з Продуктами) і Постачання (зв'язує Постачальників із Продуктами);
позначення Постачальники;
характеристики Рецепти і Витрати.
ER-діаграма моделі показана на рис. 8, а модель мовою МІМ К має такий вигляд:
Страви (СТ, Страва, Вид)
Продукти (ПР, Продукт, Калорійність)
Постачальники (ПОС, Місто, Постачальник) [Місто]
Склад [Страви М, Продукти N] (СТ, ПР, Вага (г))
Постачання [Постачальники М, Продукти N] (ПОС, ПР, Дата_П, Ціна, Вага(кг))
Міста (Місто, Країна)
Рецепти (СТ, Рецепт){Страви)
Витрата (СТ, Дата_Р, Порцій) (Страви)
У цих моделях Страва, Продукт і Постачальник — найменування, а СТ, ПР і ПОС — цифрові коди страв, продуктів і організацій, що поставляють ці продукти.
Рис.
8. Інфологічна модель бази даних
"Харчування"