2 3 Класифікація сутностей три класи сутностей

2.3. Класифікація сутностей

Три класи сутностей

Настав момент розібратися в термінології. К.Дейт [3] визначає три основні класу сутностей: стрижневі. асоціативні і характеристичні. а також підклас асоціативних сутностей - позначення.

Стрижнева сутність (стрижень)

У розглянутих раніше прикладах стрижні - це "Студент", "Квартира", "Чоловіки", "Лікар", "Шлюб" (з прикладу 2.2) та інші, назви яких поміщені в прямокутники.

Асоціативна сутність (асоціація)

Асоціативна сутність (асоціація) - це зв'язок виду "багато-до-багатьох" ( "1-ко-многим" і т.д.) між двома або більше сутностями або екземплярами сутності (як в прикладі 2.4). Асоціації розглядаються як повноправні суті:

вони можуть брати участь в інших асоціаціях і позначеннях точно так же, як стрижневі сутності;

можуть мати властивості, тобто мати не тільки набір ключових атрибутів, необхідних для вказівки зв'язків, а й будь-яке число інших атрибутів, що характеризують зв'язок.

Наприклад, асоціації "Шлюб" із прикладів 2.1 і 2.4 містять ключові атрибути "Код_М", "Код_Ж" і "Табельний номер чоловіка", "Табельний номер дружини", а також уточнюючі атрибути "Номер свідоцтва", "Дата реєстрації", "Место_регістраціі "," Номер запису в книгу ЗАГС "і т.д.

Характеристична сутність (характеристика)

Характеристична сутність (характеристика) - це зв'язок виду "багато-до-одного" або "одна-до-одного" між двома сутностями (окремий випадок асоціації). Єдина мета характеристики в рамках розглянутої предметної області полягає в описі чи уточнення деякої іншої сутності. Необхідність в них виникає в зв'язку з тим, що сутності реального світу мають іноді багатозначні властивості. Чоловік може мати кілька дружин (приклад 2.3), книга - кілька характеристик перевидання (виправлене, доповнене, перероблене.) І т.д.

Існування характеристики повністю залежить від характеризується сутності: жінки позбавляються статусу жінок, якщо вмирає їх чоловік.

Для опису характеристики використовується нова пропозиція ЯІМ, що має в загальному випадку вид:

ХАРАКТЕРИСТИКА (атрибут 1, атрибут 2.)

Розширимо також мову ER-діаграм, ввівши для зображення характеристики трапецію (рис. 2.2).

Мал. 2.2. Елементи розширеного мови ER-діаграм

Позначає сутність або позначення

Позначає сутність або позначення - це зв'язок виду "багато-до-одного" або "одна-до-одного" між двома сутностями і відрізняється від характеристики тим, що не залежить від позначається сутності.

Розглянемо приклад, пов'язаний із зарахуванням співробітників в різні відділи організації.

При відсутності жорстких правил (співробітник може одночасно зараховуватися в кілька відділів або НЕ зараховуватися ні в один відділ) необхідно створити опис з асоціацією Зарахування:

Відділи (Номер відділу, Назва відділу.)

Службовці (Табельний номер, Прізвище.)

Зарахування [Відділи M, Службовці N]

(Номер відділу, Табельний номер, Дата зарахування).

Однак, за умови, що кожен із співробітників повинен бути обов'язково зарахований в один з відділів, можна створити опис з позначенням Службовці:

Відділи (Номер відділу, Назва відділу.)

Службовці (Табельний номер, Прізвище. Номер відділу,

В даному прикладі службовці мають незалежне існування (якщо видаляється відділ, то з цього не випливає, що також повинні бути видалені службовці такого відділу). Тому вони не можуть бути характеристиками відділів і названі позначеннями.

Позначення використовують для зберігання значень, що повторюються великих текстових атрибутів: "кодифікатори" вивчаються студентами дисциплін, найменувань організацій і їх відділів, переліків товарів і т.п.

Опис позначення зовні відрізняється від опису характеристики тільки тим, що позначаються суті полягає не в фігурні дужки, а в квадратні:

Ідентифікація (атрибут 1, атрибут 2.) [СПИСОК

Як правило, позначення не розглядаються як повноправні суті, хоча це не привело б до будь-якої помилку.

Позначення і характеристики не є повністю незалежними сутностями, оскільки вони припускають наявність деякої іншої сутності, яка буде "позначатися" або "характеризуватися". Однак вони все ж є окремі випадки сутності і можуть, звичайно, мати властивості, можуть брати участь в асоціаціях, позначеннях і мати свої власні (нижчого рівня) характеристики. Підкреслимо також, що всі екземпляри характеристики повинні бути обов'язково пов'язані з будь-яким екземпляром характеризується сутності. Однак допускається, щоб деякі екземпляри характеризується суті не мали зв'язків. Правда, якщо це стосується шлюбів, то сутність "Чоловіки" повинна бути замінена на сутність "Чоловіки" (немає чоловіка без дружини).

Перевизначити тепер стрижневу сутність як сутність, яка не є ні асоціацією, ні позначенням, ні характеристикою. Такі суті мають незалежне існування, хоча вони і можуть позначати інші сутності, як, наприклад, співробітники позначають відділи.

На закінчення розглянемо приклад побудови інфологічної моделі бази даних "Харчування", де повинна зберігатися інформація про страви (рис. 2.3), їх щоденному споживанні, продуктах, з яких готуються ці страви, і постачальників цих продуктів. Інформація буде використовуватися кухарем і керівником невеликого підприємства громадського харчування, а також його відвідувачами.

1. Лобио по грузинськи
Ламану очищену квасолю, нашатковану цибулю посолити, посипати перцем і припустити в маслі з невеликою кількістю бульйону; додати кінзу, зелень петрушки, Рейган (базилік) і довести до готовності. Потім запекти в духовці.
Квасоля стручкова (свіжа або консервована) 200,
Цибуля зелена 40, Масло вершкове 30, Зелень 10.
Вихід 210. Калорій 725.

Мал. 2.3. Приклад кулінарного рецепта

За допомогою зазначених користувачів виділені наступні об'єкти і характеристики проектованої бази:

Страви, для опису яких потрібні дані, що входять до їх кулінарні рецепти: номер страви (наприклад, з книги кулінарних рецептів), назва страви, вид блюда (закуска, суп, гаряче і т.п.), рецепт (технологія приготування страви), вихід (вага порції), назва, калорійність і вага кожного продукту, що входить в блюдо.

Щоденне споживання страв (витрата): страва, кількість порцій, дата.

Аналіз об'єктів дозволяє виділити:

стрижні Страви, Продукти та Міста;

асоціації Склад (пов'язує Страви з Продуктами) і

Поставки (пов'язує Постачальників з Продуктами);

характеристики Рецепти і Витрата.

ER-діаграма моделі показана на рис. 2.4. а модель на мові ЯІМ має наступний вигляд:

Страви (БЛ, Блюдо, Вид)

Продукти (ПР, Продукт, Калорійність)

Постачальники (ПОС, Місто, Постачальник) [Місто]

Склад [Страви M, Продукти N] (БЛ, ПР, Вага (г))

Поставки [Постачальники M, Продукти N] (ПОС, ПР, Дата_П, Ціна, Вага (кг))

Міста (Місто, Країна)

Рецепти (БЛ, Рецепт)

Витрата (БЛ, Дата_Р, Працюй)

У цих моделях Страва, Продукт і Постачальник - найменування, а БЛ, ПР і ПОС - цифрові коди страв, продуктів і організацій, що постачають ці продукти.

2 3 Класифікація сутностей три класи сутностей

Мал. 2.4. Инфологическая модель бази даних "Харчування"

2.4. Про первинних і зовнішніх ключах

Нагадаємо, що ключ або можливий ключ - це мінімальний набір атрибутів, за значеннями яких можна однозначно знайти необхідний екземпляр сутності. Мінімальність означає, що виключення з набору будь-якого атрибута не дозволяє ідентифікувати сутність по що залишилися. Кожна сутність має хоча б одним можливим ключем. Один з них приймається за первинний ключ. При виборі первинного ключа слід віддавати перевагу несоставнимі ключам або ключам, складеним з мінімального числа атрибутів. Недоцільно також використовувати ключі з довгими текстовими значеннями (краще використовувати цілочисельні атрибути). Так, для ідентифікації студента можна використовувати або унікальний номер залікової книжки, або набір із прізвища, імені, по батькові, номера групи і може бути додаткових атрибутів, так як не виключена поява в групі двох студентів (а частіше студенток) з однаковими прізвищами, іменами та батькові. Погано також використовувати в якості ключа не номер страви, а його назва, наприклад, "Закуска з плавлених сирків" Дружба "з шинкою і солоним огірком" або "Заєць в сметані з картопляними крокетами і салатом з червоної капусти".

Не допускається, щоб первинний ключ стрижневий суті (будь-який атрибут, який бере участь в первинному ключі) брав невизначений значення. Інакше виникне суперечлива ситуація: з'явиться не володіє індивідуальністю, і, отже, не існуючий екземпляр стрижневий суті. З тих же причин необхідно забезпечити унікальність первинного ключа.

Тепер про зовнішні ключі:

Якщо сутність З пов'язує суті А і В, то вона повинна включати зовнішні ключі, відповідні первинним ключам сутностей А і В.

Якщо сутність У позначає сутність А, то вона повинна включати зовнішній ключ, відповідний первинному ключу суті А.

У п. 2.3 розглядалося приклад, де "Службовці" позначали "Відділи" і включали зовнішній ключ "Номер відділу", відповідний первинному ключу сутності "Відділи".

Зв'язок між первинними і зовнішніми ключами сутностей ілюструється рис. 2.5.

Мал. 2.5. Структури: а - асоціації; б - позначення (характеристики)

Тут для позначення будь-якої з асоційованих сутностей (стрижнів, характеристик, позначень або навіть асоціацій) використовується новий узагальнюючий термін "Мета" або "Цільова сутність".

Таким чином, при розгляді проблеми вибору способу представлення асоціацій і позначень в базі даних основне питання, на який слід отримати відповідь: "Які зовнішні ключі?". І далі, для кожного зовнішнього ключа необхідно вирішити три питання:

1. Чи може даний зовнішній ключ приймати невизначені значення (NULL-значення)? Інакше кажучи, чи може існувати деякий екземпляр сутності даного типу, для якого невідома цільова сутність, що вказується зовнішнім ключем? У разі поставок це, ймовірно, неможливо - поставка, здійснювана невідомим постачальником, або поставка невідомого продукту не мають сенсу. Але у випадку з співробітниками така ситуація однак могла б мати сенс - цілком можливо, що будь-якої співробітник в даний момент не зарахований взагалі ні в який відділ. Зауважимо, що відповідь на це питання не залежить від примхи проектувальника бази даних, а визначається фактичним чином дій, прийнятим в тій частині реального світу, яка повинна бути представлена в даній базі даних. Подібні зауваження мають відношення і до питань, що обговорюються нижче.

2. Що має статися при спробі ВИДАЛЕННЯ цільової суті, на яку посилається зовнішній ключ? Наприклад, при видаленні постачальника, який здійснив принаймні одну поставку. Існує три можливості:

Операція видалення "каскадіруется" з тим, щоб видалити також поставки цього постачальника.

Для всіх поставок такого постачальника NULL-значення зовнішній ключ встановлюється в невизначене значення, а потім оновлюється первинний ключ постачальника. Така можливість, звичайно, не застосовується, якщо даний зовнішній ключ не повинен містити NULL-значень.

Таким чином, для кожного зовнішнього ключа в проекті проектувальник бази даних повинен специфікувати не тільки поле або комбінацію полів, що складають цей зовнішній ключ, і цільову таблицю, яка ідентифікується цим ключем, але також і відповіді на зазначені вище три питання (три обмеження, які відносяться до цього зовнішньому ключу).

Нарешті, про характеристики - позначають сутності, існування яких залежить від типу позначаються сутностей. Позначення представляється зовнішнім ключем в таблиці, що відповідає цій характеристиці. Але три розглянуті вище обмеження на зовнішній ключ для даного випадку повинні специфіковані в такий спосіб:

NULL-значення не припустимі

ВИДАЛЕННЯ З (мета) КАСКАДІРУЕТСЯ

ОНОВЛЕННЯ (первинний ключ цілі) КАСКАДІРУЕТСЯ

Зазначені специфікації представляють залежність по існуванню характеристичних сутностей.

2.5. обмеження цілісності

Поняття цілісності даних

Цілісність (від англ. Integrity - незайманість, недоторканність, безпеку, цілісність) - розуміється як правильність даних в будь-який момент часу. Але ця мета може бути досягнута лише в певних межах: СУБД не може контролювати правильність кожного окремого значення, що вводиться в базу даних (хоча кожне значення можна перевірити на правдоподібність). Наприклад, не можна виявити, що вводиться значення 5 (що представляє номер дня тижня) в дійсності має дорівнювати 3. З іншого боку, значення 9 явно буде помилковим і СУБД повинна його відкинути. Однак для цього їй слід повідомити, що номери днів тижня повинні належати набору (1,2,3,4,5,6,7).

Підтримка цілісності бази даних може розглядатися як захист даних від невірних змін або руйнувань (не плутати з незаконними змінами та руйнуваннями, які є проблемою безпеки). Сучасні СУБД мають ряд засобів для забезпечення підтримки цілісності (так само, як і засобів забезпечення підтримки безпеки).

види цілісності

Виділяють три групи правил цілісності:

Цілісність по сутностей.

Цілісність, що визначається користувачем.

У п. 2.4 була розглянута мотивування двох правил цілісності, загальних для будь-яких реляційних баз даних.

Не допускається, щоб будь-якої атрибут, який бере участь в первинному ключі, брав невизначений значення.

Значення зовнішнього ключа повинно або:

бути рівним значенню первинного ключа мети;

бути повністю невизначеним, тобто кожне значення атрибута, який бере участь в зовнішньому ключі має бути невизначеним.

Для будь-якої конкретної бази даних існує ряд додаткових специфічних правил, які відносяться до неї однієї і визначаються розробником. Найчастіше контролюється:

унікальність тих або інших атрибутів,

діапазон значень (екзаменаційна оцінка від 2 до 5),

приналежність набору значень (пол "М" або "Ж").

2.6. Про побудову інфологічної моделі

Вимоги до БД з боку адміністратора і прикладного програміста

Основна складність сприйняття рекомендацій, наведених в четвертому розділі та додатку Б, чисто психологічного плану.

Дійсно, для визначення переліку та структури збережених даних треба зібрати інформацію про реальних і потенційних додатках, а також про користувачів бази даних, а при побудові інфологічної моделі слід дбати лише про надійність зберігання цих даних, геть забуваючи про додатки і користувачів, для яких створюється база даних.

Це пов'язано з абсолютно розрізняються вимогами до бази даних прикладних програмістів і адміністратора бази даних. Перші хотіли б мати в одному місці (наприклад, в одній таблиці) всі дані, необхідні їм для реалізації запиту з прикладної програми або з терміналу. Другі ж піклуються про виключення можливих спотворень збережених даних при введенні в базу даних нової інформації та оновленні або видаленні існуючої. Для цього вони видаляють з бази даних дублікати і небажані функціональні зв'язки між атрибутами, розбиваючи базу даних на безліч маленьких таблиць (див. П. 4.6). Так як багаторічний світовий досвід використання інформаційних систем, побудованих на основі баз даних, показує, що недоліки проекту неможливо усунути будь-якими хитрощами в програмах додатків, то досвідчені проектувальники не дозволяють собі йти назустріч прикладним програмістам (навіть тоді, коли вони самі є такими).

2 3 Класифікація сутностей три класи сутностей