Інфологіческая модель баз даних "Сутність-зв'язок "

Інфологіческая модель баз даних "Сутність-зв'язок" Основні поняття

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

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

Атрибут - пойменована характеристика сутності. Його найменування повинне бути унікальним для конкретного типу сутності, але може бути однаковим для різного типу сутностей (наприклад, КОЛІР може бути визначений для багатьох сутностей: СОБАКА, АВТОМОБИЛЬ, дим і т.д.). Атрибути використовуються для визначення того, яка інформація повинна бути зібрана про сутність. Прикладами атрибутів для сутності АВТОМОБИЛЬ є ТИП, МАРКА, номерний знак, колір та т.д. Тут також існує розходження між типом і екземпляром. Тип атрибута КОЛІР має багато екземплярів чи значень:

Червоний, Синій, банановий, Біла ніч і т.д.,

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

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

Ключ - мінімальний набір атрибутів, за значеннями яких можна однозначно знайти необхідний екземпляр сутності. Мінімальність означає, що виключення з набору будь-якого атрибута не дозволяє ідентифікувати сутність по що залишилися. Для суті Розклад (п. 1.2) ключем є атрибут Номер_рейса або набір: Пункт_отправленія, Время_вилета і Пункт_назначенія (за умови, що з пункту в пункт вилітає в кожен момент часу один літак).

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

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

Між двома сутностей, наприклад, А і В можливі чотири види зв'язків.

Перший тип - зв'язок ОДИН-К-ОДНОМУ (1:1): у кожен момент часу кожному представнику (екземпляру) сутності А відповідає 1 чи 0 представників сутності В:

Студент може не "заробити" стипендію, одержати звичайну чи одну з підвищених стипендій.

Другий тип - зв'язок ОДИН-КО-багато (1: М): одному представнику сутності А відповідають 0, 1 або кілька представників сутності В.

Квартира може пустувати, в ній може жити один чи кілька мешканців.

Так як між двома сутностями можливі зв'язки в обох напрямках, то існує ще два типи зв'язку БАГАТО-К-ОДНОМУ (М: 1) і БАГАТО-КО-багато (М: N).

Приклад 2.1. Якщо зв'язок між сутностями ЧОЛОВІКА і ЖІНКИ називається ШЛЮБ, то існує чотири возможнихпредставленія такого зв'язку:

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

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

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

У наведених прикладах для підвищення ілюстративності розглянутих зв'язків не показані атрибути сутностей і асоціацій у всіх ER-діаграмах. Так, введення лише декількох основних атрибутів в опис шлюбних зв'язків значно ускладнить ER-діаграму (мал. 2.1, а). У зв'язку з цим мову ER-діаграм використовується для побудові невеликих моделей і ілюстрації окремих фрагментів великих. Частіше ж застосовується менш наочний, але більш змістовний мова інфологіческого моделювання (ЯІМ), в якому сутності й асоціації представляються пропозиціями виду: СУТНІСТЬ (атрибут 1, атрибут 2, ..., атрибут n) АСОЦІАЦІЯ [СУТНІСТЬ S1, СУТНІСТЬ S2, ...] (атрибут 1, атрибут 2, ..., атрибут n)

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

Так, розглянутий вище приклад безлічі зв'язків між сутностями, може бути описаний на ЯІМ наступним чином: Лікар (Номер_врача, Прізвище, Ім'я, По батькові, Спеціальність) Пацієнт (Регістраціонний_номер, Номер ліжка, Прізвище, Ім'я, По батькові, Адреса, Дата народження, Підлога) Лечащій_врач [Лікар 1, Пацієнт M] (Номер_врача, Регістраціонний_номер) Консультант [Лікар M, Пацієнт N] (Номер_врача, Регістраціонний_номер).

Рис. 2.1. Приклади ER-діаграм
Для виявлення зв'язків між сутностями необхідно, як мінімум, визначити самі сутності. Але це не просте завдання, тому що в різних предметних областях один і той же об'єкт може бути сутністю, або атрибутом асоціацією. Проілюструємо таке твердження на прикладах, пов'язаних з описом шлюбних зв'язків (див. приклад 2.1).
Приклад 2.2. Відділ записів актів цивільного стану (РАЦС) має справу не з усіма людьми, а тільки з тими, хто звернувся з проханням про реєстрації шлюбу, народження або смерті. Тому в країнах, де допускаються лише традиційні шлюби, відділи РАЦС можуть розміщувати відомості про реєстрованих шлюби в єдиній суті: Шлюб (Номер_свідетельства, Фамілія_мужа, Імя_мужа, Отчество_мужа, Дата_рожденія_мужа, Фамілія_жени, ..., Дата_регістраціі, Место_регістраціі, ...),
ER-діаграма якої наведено на рис. 2.1, б.
Приклад 2.3. Тепер розглянемо ситуацію, коли відділ РАЦС розташований в країні, що допускає багатоженство. Якщо для реєстрації шлюбів використовувати сутність "Шлюб" прикладу 2.2, то будуть дублюватися відомості про чоловіків, що мають кілька дружин (див. табл. 2.1).
Таблиця 2.1       Номер свідоцтва          Прізвище чоловіка          ...          Прізвище дружини          ...          Дата реєстрації         1-ЮБ 154745         Пєтухов         ...         Курочкіна         ...         06/03/1991         1-ЮБ 163489         Пєтухов         ...         Пеструшкіна         ...         11/08/1991         1-ЮБ 169887         Пєтухов         ...         Рябова         ...         12/12/1992         1-ЮБ 169878         Селезньов         ...         Уточкина         ...         12/12/1992         1-ЮБ 154746         Парасюк         ...         Свінюшкіна         ...         06/03/1991         1-ЮБ 169879         Парасюк         ...         Льоха         ...         12/12/1992         ...         ...         ...         ...         ...         ...
Дублювання можна виключити створенням додаткової сутності "Чоловіки" Чоловіки (Код_М, Прізвище, Ім'я, По батькові, дата народження, місце народження)
і заміною суті "Шлюб" характеристикою (див. п. 2.3) з посиланням на відповідне опис по суті "Чоловіки". Шлюб (Номер свідоцтва, Код_М, Прізвище дружини, ..., Дата реєстрації, ...){ Чоловіки).
ER-діаграма зв'язку цих сутностей показана на рис. 2.1, в, а приклад їх примірників в табл. 2.2 і 2.3.
Таблиця 2.2       Код_М          Прізвище          Назва          По батькові          Рік/р.          Місце нар.         111         Пєтухов         Альфред         Остапович         1971         м. Цапелька         112         Селезньов         Вавіла         Абрамович         1973         м. Гусєв         113         Парасюк         Горацій         Федулович         1972         м. Свиньїн         ...         ...         ...         ...         ...         ...
Таблиця 2.3       Номер свідоцтва          Код_М          Прізвище дружини          Ім'я дружини          Дата реєстрації          ...         1-ЮБ 154745         111         Курочкіна         Августина         06/03/1991         ...         1-ЮБ 163489         111         Пеструшкіна         Маріана         11/08/1991         ...         1-ЮБ 169877         111         Рябова         Мілана         12/12/1992         ...         1-ЮБ 169878         112         Уточкина         Вероніка         12/12/1992         ...         1-ЮБ 154746         113         Свінюшкіна         Ельвіра         06/03/1991         ...         1_ЮБ 169879         113         Льоха         Руфіна         12/12/1992         ...         ...         ...         ...         ...         ...         ...
Приклад 2.4. Нарешті, розглянемо випадок, коли будь-якої організації потрібні були дані про наявність у ній сімейних пар, а для зберігання відомостей про співробітників вже є сутність Співробітники (Табельний_номер, Прізвище, Ім'я, ...).
Використання, розглянутої в прикладі 2.2, сутності "Шлюб" недоцільно: у "Співробітники" вже є прізвища, імена, по батькові подружжя. Тому створимо асоціацію Шлюб [Співробітник 1, Працівник 1] (Табельний_номер_мужа, Табельний_номер_жени, ...),
що зв'язує між собою певні екземпляри сутності "Співробітники" (мал. 2.1, г).
На закінчення відзначимо, що ER-діаграма рис. 2.1, а описує структуру розміщення даних про шлюби у відділах ЗАГС країн, що допускають групові шлюби, а ER-діаграми прикладу 2.1, опису будь-яких видів шлюбів в організаціях, де є сутності "чоловіків" і "жінки", що включають неодружених і незаміжніх.
Що ж таке "зв'язок"? У ER-діаграмах це лінія, що з'єднує геометричні фігури, що зображують сутності, атрибути, асоціації та інші інформаційні об'єкти. У тексті ж цей термін використовується для вказівки на взаємозалежність сутностей. Якщо ця взаємозалежність має атрибути, то вона називається асоціацією. Класифікація сутностей
Настав момент розібратися в термінології. К. Дейт [3] визначає три основні класу сутностей: стрижневі, асоціативні та характеристичні, а також підклас асоціативних сутностей - позначення.
Стрижнева сутність (стрижень) - це незалежна сутність (трохи докладніше вона буде визначена нижче).
У розглянутих раніше прикладах стрижні - це "Студент", "Квартира", "Чоловіки", "Лікар", "Шлюб" (з прикладу 2.2) та інші, назви яких поміщені в прямокутники.
Асоціативна сутність (асоціація) - це зв'язок виду "многие-ко-многим" ( "-ко-многим" і т.д.) між двома або більше сутностями або екземплярами суті (як у прикладі 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.4. Інфологіческая модель бази даних "Харчування" Про первинних і зовнішніх ключах
Нагадаємо, що ключ або можливий ключ - це мінімальний набір атрибутів, за значеннями яких можна однозначно знайти необхідний екземпляр сутності. Мінімальність означає, що виключення з набору будь-якого атрибута не дозволяє ідентифікувати сутність по що залишилися. Кожна сутність має хоча б одним можливим ключем. Один з них приймається за первинний ключ. При виборі первинного ключа слід віддавати перевагу несоставним ключів або ключів, складеним з мінімального числа атрибутів. Недоцільно також використовувати ключі з довгими текстовими значеннями (переважно використовувати цілочисельні атрибути). Так, для ідентифікації студента можна використовувати або унікальний номер залікової книжки, або набір із прізвища, імені, по батькові, номер групи і може бути додаткових атрибутів, так як не виключена поява у групі двох студентів (а частіше студенток) з однаковими прізвищами, іменами та по батькові. Погано також використовувати в якості ключа не номер страви, а його назву, наприклад, "Закуска з плавлених сирків "Дружба" з шинкою і солоним огірком "або" Заєць в сметані з картопляними крокетами і салатом з червоної капусти ".
Не допускається, щоб первинний ключ стрижневий суті (будь-який атрибут, який бере участь в первинному ключі) брав невизначений значення. Інакше виникне суперечлива ситуація: з `явиться не володіє індивідуальністю, і, отже не існуючий екземпляр стрижневий сутності. З тих же причин необхідно забезпечити унікальність первинного ключа.
Тепер про зовнішні ключі: Якщо сутність З пов'язує суті А і В, то вона повинна включати      зовнішні ключі, що відповідають первинним ключів сутностей А і В. Якщо сутність У позначає сутність А, то вона повинна включати      зовнішній ключ, що відповідає первинному ключу суті А.
У п. 2.3 розглядався приклад, де "Службовці" позначали "Відділи" і включали зовнішній ключ "Номер відділу", відповідний первинного ключу сутності "Відділи".
Зв'язок між первинними і зовнішніми ключами сутностей ілюструється рис. 2.5.

Рис. 2.5. Структури: а - асоціації; б - позначення (характеристики)
Тут для позначення будь-якої з асоційованих сутностей (стрижнів, характеристик, позначень або навіть асоціацій) використовується новий узагальнюючий термін "Мета" або "Цільова сутність".
Таким чином, при розгляді проблеми вибору способу представлення асоціацій і позначень у базі даних основне питання, на який слід отримати відповідь: "Які зовнішні ключі?". І далі, для кожного зовнішнього ключа необхідно вирішити три питання:
1. Чи може цей зовнішній ключ приймати невизначені значення (NULL-значення)? Інакше кажучи, чи може існувати деякий примірник суті даного типу, для якого невідома цільова сутність, що вказується зовнішнім ключем? У разі поставок це, мабуть, неможливо - поставка, здійснювана невідомим постачальником, або поставка невідомого продукту не мають сенсу. Але у випадку з співробітниками така ситуація однак могла б мати сенс - цілком можливо, що який-небудь співробітник в даний момент не зарахований взагалі ні в який відділ. Зауважимо, що відповідь на дане питання не залежить від примхи проектувальника бази даних, а визначається фактичним чином дій, прийнятим в тій частині реального світу, яка повинна бути представлена в розглянутій базі даних. Подібні зауваження мають відношення і до питань, що обговорюються нижче.
2. Що має статися при спробі ВИДАЛЕННЯ цільової суті, на яку посилається зовнішній ключ? Наприклад, при видаленні постачальника, який здійснив принаймні одну поставку. Існує три можливості:      КАСКАДІРУЕТСЯ         Операція видалення "каскадіруется" з тим, щоб видалити також поставки цього   постачальника.         ОБМЕЖУЄТЬСЯ         Видаляються лише ті постачальники, які ще не здійснювали поставок. Інакше операція видалення   відкидається.         ВСТАНОВЛЮВАТИСЯ         Для всіх поставок видаляється постачальника NULL-значення зовнішній ключ встановлюється в невизначене   значення, а потім цей постачальник видаляється. Така можливість, звичайно, не застосовується, якщо даний зовнішній ключ не повинен містити NULL-значень.
3. Що має відбуватися при спробі ОНОВЛЕННЯ первинного ключа цільової суті, на яку посилається деякий зовнішній ключ? Наприклад, може бути зроблена спроба оновити номер такого постачальника, для якого є принаймні один відповідна постачання. Цей випадок для визначеності знову розглянемо докладніше. Є ті самі три можливості, як і при видаленні:      КАСКАДІРУЕТСЯ         Операція оновлення "каскадіруется" з тим, щоб оновити також і зовнішній ключ   впоставках цього постачальника.         ОБМЕЖУЄТЬСЯ         Оновлюються первинні ключі лише тих постачальників, які ще не здійснювали поставок. Інакше операція   оновлення відкидається.         ВСТАНОВЛЮВАТИСЯ         Для всіх поставок такого постачальника NULL-значення зовнішній ключ встановлюється в невизначене   значення, а потім оновлюється первинний ключ постачальника. Така можливість, звичайно, не застосовується, якщо даний зовнішній ключ не повинен містити   NULL-значень.
Таким чином, для кожного зовнішнього ключа в проекті проектувальник бази даних повинен специфікувати не тільки поле або комбінацію полів, що становлять цей зовнішній ключ, і цільову таблицю, яка ідентифікується цим ключем, але також і відповіді на зазначені вище питання (три обмеження, які відносяться до цього зовнішньому ключу).
Нарешті, про характеристики - позначають сутності, існування яких залежить від типу що позначаються сутностей. Позначення представляється зовнішнім ключем в таблиці, що відповідає цій характеристиці. Але три розглянуті вище обмеження на зовнішній ключ для даного випадку повинні специфікувати наступним чином: NULL-значення не допустімиУДАЛЕНІЕ З (мета) КАСКАДІРУЕТСЯОБНОВЛЕНІЕ (первинний ключ цілі) КАСКАДІРУЕТСЯ
Зазначені специфікації представляють залежність по існуванню характеристичних сутностей. Обмеження цілісності
Цілісність (від англ. integrity - незайманість, недоторканність, збереження, цілісність) - розуміється як правильність даних у будь-який момент часу. Але ця мета може бути досягнута лише у певних межах: СУБД не може контролювати правильність кожного окремого значення, що вводиться в базу даних (хоча кожне значення можна перевірити на правдоподібність). Наприклад, не можна виявити, що вводиться значення 5 (що представляє номер дня тижні) в дійсності має дорівнювати 3. З іншого боку, значення 9 явно буде помилковим і СУБД повинна його відхилити. Однак для цього їй слід повідомити, що номери днів тижня повинні належати набору (1,2,3,4,5,6,7).
Підтримка цілісності бази даних може розглядатися як захист даних від невірних змін або руйнувань (не плутати з незаконними змінами та руйнуваннями, що є проблемою безпеки). Сучасні СУБД мають ряд засобів для забезпечення підтримки цілісності (так само, як і засобів забезпечення підтримки безпеки).
Виділяють три групи правил цілісності: Цілісність по сутностей. Цілісність за посиланнями. Цілісність, що визначається користувачем.
У п. 2.4 була розглянута мотивування двох правил цілісності, загальних для будь-яких реляційних баз даних. Не допускається, щоб будь-якої атрибут, який бере участь в первинному      ключі, брав невизначений значення. Значення зовнішнього ключа повинно або:   бути рівним значенню первинного ключа мети;   бути повністю невизначеним, тобто кожне       значення атрибуту, який бере участь в зовнішньому ключі має бути       невизначеним. Для будь-якої конкретної бази даних існує ряд додаткових      специфічних правил, які ставляться до неї однієї і визначаються      розробником. Найчастіше контролюється:
унікальність тих або інших атрибутів,
діапазон значень (екзаменаційна оцінка від 2 до 5),
приналежність набору значень (стать "М" або "Ж "). Про побудову інфологіческой моделі
Читач, що познайомився лише з матеріалом даної і попередньої голів, не зможе правильно сприйняти і оцінити тих порад і рекомендацій з побудови хорошою інфологіческой моделі, які десятиліттями формувалися найбільшими фахівцями в галузі обробки даних. Для цього треба, принаймні, вивчити наступні матеріали. В ідеалі ж потрібно, щоб читач попередньо реалізував хоча б один проект інформаційної системи, запропонував його реальним користувачам і побув адміністратором бази даних настільки довго, щоб усвідомити хоча б невелику дещицю проблем, що виникають із-за недостатньо продуманого проекту. Досвід автора і всіх знайомих йому фахівців з інформаційних систем показує, що будь-які теоретичні рекомендації сприймаються всерйоз лише після кількох безрезультатних спроб пожвавлення невдало спроектованих систем. (Хоча є й такі проектувальники, які продовжують вірити, що зможуть реанімувати вмираючий проект за допомогою зміни програм, а не інфологіческой моделі бази даних.)
Основна складність сприйняття рекомендацій, наведених у четвертому розділі та додатку Б, чисто психологічного плану.
Дійсно, для визначення переліку та структури збережених даних треба зібрати інформацію про реальних і потенційних додатках, а також про користувачів бази даних, а при побудові інфологіческой моделі слід дбати лише про надійність зберігання цих даних, геть забуваючи про додатках і користувачів, для яких створюється база даних.
Це пов'язано з абсолютно відрізняються вимогами до бази даних прикладних програмістів та адміністратора бази даних. Перші хотіли б мати в одному місці (наприклад, в одній таблиці) всі дані, необхідні їм для реалізації запиту з прикладної програми або з терміналу. Другі ж піклуються про виключення можливих спотворень збережених даних при введенні в базу даних нової інформації та оновлення або видалення існуючої. Для цього вони видаляють з бази даних дублікати і небажані функціональні зв'язки між атрибутами, розбиваючи базу даних на безліч маленьких таблиць (див. п. 4.6). Так як багаторічний світовий досвід використання інформаційних систем, побудованих на основі баз даних, показує, що недоліки проекту неможливо усунути будь-якими хитрощами в програмах додатків, то досвідчені проектувальники не дозволяють собі йти назустріч прикладним програмістам (навіть тоді, коли вони самі є такими).
І хоча автор усвідомлює, що більшість людей вважає за краще вчитися на власних помилках, він все ж таки ще раз радить недосвідченим проектувальникам баз даних: чітко розмежовувати такі поняття як запит на дані та ведення      даних (введення, зміна та видалення); пам'ятати, що, як правило, база даних є інформаційною      основою не одного, а декількох додатків, частина з яких з'явиться в      майбутньому; поганий проект бази даних не може бути виправлений за допомогою будь-яких      (навіть самих витончених) додатків. ЛІТЕРАТУРА Атре Ш. Структурний підхід до організації баз даних. - М.: Фінанси      і статистика, 1983. - 320 с. Бойко В.В., Савінков В.М. Проектування баз даних інформаційних      систем. - М.: Фінанси і статистика, 1989. - 351 с. Дейт К. Посібник з реляційної СУБД DB2. - М.: Фінанси і      статистика, 1988. - 320 с. Джексон Г. Проектування реляційних баз даних для використання      з мікроЕОМ. -М.: Світ, 1991. - 252 с. Кириллов В.В. Структурізованний мову запитів (SQL). - СПб.: ИТМО,      1994. - 80 с. Мартін Дж. Планування розвитку автоматизованих систем. - М.:      Фінанси і статистика, 1984. - 196 с. Мейер М. Теорія реляційних баз даних. - М.: Світ, 1987. - 608 с. Тіорі Т., Фрай Дж. Проектування структур баз даних. У 2 кн., --      М.: Світ, 1985. Кн. 1. - 287 с.: Кн. 2. - 320 с. Ульман Дж. Бази даних на Паскалі. - М.: Машиностроение, 1990. --      386 с. Хаббард Дж. Автоматизоване проектування баз даних. - М.:      Світ, 1984. - 294 с. Цікрітізіс Д., Лоховскі Ф. Моделі даних. - М.: Фінанси і статистика,      1985. - 344 с.