Реляційні таблиці

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

Для деяких стовпців допускається, що значення стовпця в визначеному рядку може приймати значення NULL. Значення NULL означає одну з двох можливостей: "не визначене в цей момент значення" або "непридатне значення".

Одним з наслідків вимоги до моделі РБД, який полягає у неприпустимості дублювання рядків, є наявність у кожної таблиці первинного ключа (primary key). Ключ - ця мінімальна множина стовпців (можливо один) таких, що значення в цих стовпцях єдиним способом ідентифікують один рядок у таблиці. Таблиця може містити багато подібних ключів. Один з цих ключів довільним чином вибирається як найбільш важливий - це первинний ключ, (primary key). Інші ключі називаються потенційними (candidate) або альтернативними (alternative) ключами.

На практиці таблиця СУРБД не зобов'язана мати ключ. Це значить, що таблиця (без унікального ключа) може містити ідентичні рядки - дивна марна властивість реляційної бази даних, коли два рядки, що містять однакові значення в усіх своїх стовпцях ніяк не можна відрізнити. У системах ОБД і ОРБД подібне розрізнення забезпечується за рахунок наявності OID (два об'єкти можуть бути рівними, але не ідентичними, наприклад, як дві копії однієї книги).

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

На рис. 3.5 показано одна з подібних систем нотації. У якості цільової бази даних тут використовувалася база даних DB2 компанії IBM.

Рис. 3.5. Визначення таблиць реляційної бази даних

Таблиця Employee складається з восьми стовпців. Останні три стовпці допускають в якості значень використання значення NULL. Стовпець emp_id являє собою первинний ключ. Стовпці {family_name, date_of_birth} визначають потенційні (альтернативні) ключі. Стовпець gender визначений на домені Gender.

Оскільки на РБД накладається обмеження, яке полягає в тому, що стовпці можуть приймати тільки атомічні однократні значення, моделювання імені і телефонного номера працівника викликає в нас певні труднощі. У попередньому випадку ми використовували два стовпці : family_name і firstname. Стовпці не згруповані і ніяк не зв'язані в моделі. В останньому випадку ми віддали перевагу рішенню з двома стовпцями (phone_numl, phone_num2), що допускають наявність максимум двох телефонних номерів у кожного працівника.

Після того, як таблиця визначена за допомогою CASE-засобів, можна автоматично згенерувати програмний код для створення таблиці, як показано нижче. Згенерований текст програми включає визначення домена Gender і визначення бізнес-правила, визначеного на цьому домені.

Завдання: Виконати системне проектування програмної системи. Обґрунтувати вибір бази даних і виконати її проектування.

Надати звіт, що містить результати системного проектування і проектування бази даних

Контрольні питання:

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

2. Що таке триланкова архітектура? У чому її переваги і недоліки?

3. Що таке домінантний клас?

4. Що таке відношення з'єднання?

5. Які відмінності між об'єктною і реляційною моделлю БД?