- •Особливості інформаційних систем
- •Бази даних – основа інформаційних систем
- •Перспективи розвитку баз даних
- •Висновок
- •1 Системи керування файлами
- •2 Основні особливості систем, заснованих на інвертованих списках
- •3 Ієрархічні системи
- •Висновок
- •1 Основні поняття реляційних баз даних
- •2 Фундаментальні властивості відносин
- •3 Реляційна модель даних
- •Висновок
- •Проектування бази даних. Інфологічна і даталогічна моделі даних План
- •Інфологічна модель даних
- •Основні конструктивні елементи інфологічної моделі
- •1. Інфологічна модель даних
- •2. Основні конструктивні елементи інфологічної моделі
- •Висновок
- •2. Моделювання бд за допомогою мови інфологічного моделювання (мім)
- •3. Класифікація сутностей
- •Характеристика (атрибут 1, атрибут 2, ...) {список характеризуемих сутностей}.
- •Висновок
- •Проектування реляційних баз даних з використанням нормалізації План
- •Поняття про нормалізацію відносин
- •Одержання реляційної схеми з er-схеми
- •Поняття про нормалізацію відносин
- •Одержання реляційної схеми з er-схеми у висновку процесу проектування розглянемо етапи перетворення інфологічної моделі в реляційну схему бази даних.
- •Висновок
- •1. Структура найпростішої бази даних
- •2. Властивості полів бази даних
- •3. Типи даних
- •4. Безпека баз даних
- •5. Проектування баз даних. Режими роботи з базами даних
- •6. Проектування баз даних. Об'єкти бази даних
- •Література
3. Класифікація сутностей
К. Дейт визначає три основні класи сутностей: стрижневі, асоціативні і характеристичні, а також підклас асоціативних сутностей – позначення.
Стрижнева сутність (стрижень) – це незалежна сутність (трохи докладніше вона буде визначена нижче).
У розглянутих раніше прикладах стрижні – це "Студент", "Квартира", "Чоловіка", "Лікар", "Шлюб" (із приклада 2.2) і інші, назви яких поміщені в прямокутники.
Асоціативна сутність (асоціація) – це зв'язок виду "багато-до-багатьох" ("один-до-багатьох" і т.д.) між двома або більш або сутностями екземплярами сутності (як у прикладі 2.4). Асоціації розглядаються як повноправні сутності:
вони можуть брати участь в інших асоціаціях і позначеннях точно так само, як стрижневі сутності;
можуть мати властивості, тобто мати не тільки набір ключових атрибутів, необхідних для вказівки зв'язків, але і будь-яке число інших атрибутів, що характеризують зв'язок. Наприклад, асоціації "Шлюб" із прикладів 2.1 і 2.4 містять ключові атрибути "Код_М", "Код_Ж" і "Табельний номер чоловіка", "Табельний номер дружини", а також уточнюючі атрибути "Номер свідчення", "Дата реєстрації", "Місце реєстрації", "Номер запису в книгу ЗАГС" і т.д.
Характеристична сутність (характеристика) – це зв'язок виду "багато-до-одного" або "одна-до-однієї" між двома сутностями (окремий випадок асоціації). Єдина мета характеристики в рамках розглянутої предметної області складається в або описі уточненні деякої іншої сутності. Необхідність у них виникає в зв'язку з тим, що сутності реального світу мають іноді багатозначні властивості. Чоловік може мати кілька дружин (приклад 2.3), книга – кілька характеристик перевидання (виправлене, доповнене, перероблене, ...) і т.д.
Існування характеристики цілком залежить від сутності яку характеризує: жінки позбавляються статусу дружин, якщо вмирає їхній чоловік. Для опису характеристики використовується нова пропозиція МІМ, що має в загальному випадку вид:
Характеристика (атрибут 1, атрибут 2, ...) {список характеризуемих сутностей}.
Розширимо також мову ER-діаграм, запровадивши для зображення характеристики трапецію (рис. 2.2).
Рис. 5.6. Елементи розширеної мови ER-діаграм.
Сутність, що позначає, або позначення - це зв'язок виду "багато-до-одного" або "одна-до-однієї" між двома сутностями і відрізняється від характеристики тим, що не залежить від сутності, що позначається.
Розглянемо приклад, зв'язаний із зарахуванням співробітників у різні відділи організації. При відсутності твердих правил (співробітник може одночасно зараховуватися в кілька або відділів не зараховуватися ні в один відділ) необхідно створити опис з асоціацією Зарахування:
Відділи (Номер відділу, Назва відділу, ...)
Що служать (Табельний номер, Прізвище, ...)
Зарахування [Відділи M, Що Служать N]
(Номер відділу, Табельний номер, Дата зарахування).
Однак, за умови, що кожний зі співробітників повинен бути обов'язково зарахований в один з відділів, можна створити опис з позначенням Службовці:
Відділи (Номер відділу, Назва відділу, ...)
Що служать (Табельний номер, Прізвище, ... , Номер відділу,
Дата зарахування)[Відділи].
У даному прикладі службовці мають незалежне існування (якщо видаляється відділ, то з цього не випливає, що також повинні бути вилучені службовці такого відділу). Тому вони не можуть бути характеристиками відділів і названі позначеннями.
Позначення використовують для збереження повторюваних значень великих текстових атрибутів: "кодифікатори" досліджуваних студентами дисциплін, найменувань організацій і їхніх відділів, переліків товарів і т.п.
Опис позначення зовні відрізняється від опису характеристики тільки тим, що сутності, що позначаються, полягає не у фігурні дужки, а в квадратні:
ПОЗНАЧЕННЯ (атрибут 1, атрибут 2, ...)[СПИСОК
СУТНОСТЕЙ, ЩО ПОЗНАЧАЮТЬСЯ,].
Як правило, позначення не розглядаються як повноправні сутності, хоча це не привело б до якої-небудь помилки.
Позначення і характеристики не є цілком незалежними сутностями, оскільки вони припускають наявність деякої іншої сутності, що буде "позначатися" або "характеризуватися". Однак вони все-таки являють собою окремі випадки сутності і можуть, звичайно, мати властивості, можуть брати участь в асоціаціях, позначеннях і мати свої власні (більш низького рівня) характеристики. Підкреслимо також, що всі екземпляри характеристики повинні бути обов'язково зв'язані з яким-небудь екземпляром сутності яка характеризується. Однак допускається, щоб деякі екземпляри сутності яка характеризується не мали зв'язків. Правда, якщо це стосується шлюбів, то сутність "Чоловіки" повинна бути замінена на сутність "Чоловіка" (немає чоловіка без дружини).
Перевизначимо тепер стрижневу сутність як сутність, що не являється ні асоціацією, ні позначенням, ні характеристикою. Такі сутності мають незалежне існування, хоча вони і можуть позначати інші сутності, як, наприклад, співробітники позначають відділи. Розглянемо приклад побудови інфологічної моделі бази даних "Харчування", де повинна зберігатися інформація про блюда (рис. 5.7), і їх щоденне споживання, продукти, з яких готуються ці блюда, і постачальниках цих продуктів. Інформація буде використовуватися кухарем і керівником невеликого підприємства суспільного харчування, а також його відвідувачами.
Лобіо по-грузинському Ламану очищену квасолю, нашатковану цибулю посолити, посипати перцем і припустити в олії з невеликою кількістю бульйону; додати кінзу, зелень петрушки, рейган (васильок) і довести до готовності. Потім запекти в духовці. Квасоля стручкова (свіжа або консервована) 200, Цибуля зелений 40, Олія вершкова 30, Зелень 10, Вихід 210, Калорій 725. |
Рис. 5.7. Приклад кулінарного рецепта.
За допомогою зазначених користувачів виділені наступні об'єкти і характеристики проектованої бази:
блюда, для опису яких потрібні дані, що входять у їхні кулінарні рецепти: номер блюда, назва блюда, вид блюда, рецепт, вихід, назва, калорійність і вага кожного продукту, що входить у блюдо;
для кожного постачальника продуктів: найменування, адреса, назва продукту, що поставляється, дата постачання і ціна на момент постачання;
щоденне споживання блюд (витрата): блюдо, кількість порцій, дата.
Аналіз об'єктів дозволяє виділити:
стрижні: Блюда, Продукти і Міста;
асоціації: Склад (зв'язує Блюда з Продуктами) і
постачання: (зв'язує Постачальників із Продуктами);
позначення: Постачальники;
характеристики: Рецепти і Витрата.
ER-діаграма моделі показана на рис. 5.8. модель мовою МІМ має наступний вид:
Блюда (БЛ, Блюдо, Вид)
Продукти (ПР, Продукт, Калорійність)
Постачальники (ПОС, Місто, Постачальник) [Місто]
Склад [Блюда M, Продукти N] (БЛ, ПР, Вага (г))
Постачання [Постачальники M, Продукти N] (ПОС, ПР, Дата_П, Ціна, Вага (кг))
Міста (Місто, Країна)
Рецепти (БЛ, Рецепт) {Блюда}
Витрата (БЛ, Дата_Р, Порцій) {Блюда}
Рис. 5.8. Інфологічна модель бази даних "Харчування"
