Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Лекція 2 Принципи побудови УІС.doc
Скачиваний:
1
Добавлен:
01.05.2025
Размер:
119.81 Кб
Скачать

Принципи конструювання баз даних Три основні моделі даних в субд

Термін «модель даних» був введений американським математиком Коддом в 1970 р. при обгрунтуванні реляційної моделі даних. Це поняття відповідає такому смисловому аспекту терміну «модель», який розуміється як засіб, інструмент для моделювання.

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

У Гості поняття моделі даних для СУБД визначається як «сукупність правил породження структур даних в базах даних, операцій над ними, а також обмежень цілісності, що визначають допустимі зв'язки і значення даних, послідовності їх зміни».

Таким чином, в поняття «Модель даних» входять три складові:

  • засоби для організації даних;

  • операції для обробки, маніпулювання даними;

  • обмеження, що забезпечують цілісність даних.

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

На кожному рівні роботи з даними – инфологическом (до представлення даних в ЕОМ), логічному і внутрішньому (при розміщенні даних в ЕОМ) використовуються свої інструментальні засоби. На инфологическом найчастіше використовується проста модель «сущность-атрибут-связь». На внутрішньому рівні всі СУБД використовують в різних реалізаціях схожі прийоми і засоби, такі як сторінкова організація логічних записів БД в наборах даних, організація службових індексних файлів, схожі методи доступу і так далі

Інструментальні засоби логічного рівня найбільш типізуються не дивлячись на те, що кожна СУБД є оригінальною моделлю даних. Тому «моделлю даних» у вузькому сенсі називають тип моделі даних логічного рівня.

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

Ієрархічна модель

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

Вузол – інформаційна модель елементу, що знаходиться на даному рівні ієрархії.

Властивості ієрархічної моделі даних:

Декілька вузлів нижчого рівня пов'язано тільки з одним вузлом вищого рівня.

Ієрархічне дерево має тільки одну вершину (корінь), не підпорядковану ніякий іншій вершині.

Кожен вузол має своє ім'я (ідентифікатор).

Існує тільки один шлях від кореневого запису до більш приватного запису даних.

Мережева модель

Мережева модель БД схожа на ієрархічну. Вона має ті ж основні складові (вузол, рівень, зв'язок), проте характер їх відносин принципово інший. У мережевій моделі прийнятий вільний зв'язок між елементами різних рівнів.

Основні поняття реляційної моделі даних

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

Поняття «Тип даних» адекватне поняттю типу даних в мовах програмування (підтримуються символьні, числові і інші типи даних).

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

Схема відношення – це іменована безліч пар { ім'я атрибуту, ім'я домена} або, якщо поняття домена не підтримується, то { ім'я атрибуту, ім'я типу даних}.

Кортеж, відповідний даній схемі відношення, – це безліч пар { ім'я атрибуту, значення}, яка містить одне входження кожного імені атрибуту, що належить схемі відношення: «значення» є допустимим значенням домена (або типу даних, якщо поняття домена не підтримується) даного атрибуту.

Відношення – це безліч кортежів, відповідних одній схемі відношення. Іноді, щоб не плутатися, говорять «відношення-схема» і «відношення-екземпляр»; іноді схему відношення називають заголовком відношення, а відношення як набір кортежів – тілом відношення.

Схема БД – це набір іменованих схем відносин. Реляційна БД – це набір відносин, імена яких співпадають з іменами схем відносин в схемі БД.

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

Головною структурною одиницею в реляційній моделі даних є не окремі записи-кортежі, а безліч кортежів – відносини.

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

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

В даний час СУБД реляційного типу мають найбільше застосування.

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

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

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

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

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