Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
tema3.doc
Скачиваний:
43
Добавлен:
15.02.2016
Размер:
458.75 Кб
Скачать

2.2. Моделі представлення даних

Перші БД були розроблені у 1960-их рр. і пройшли декілька етапів розвитку: плоскі, мережеві та ієрархічні моделі даних, реляційні моделі даних, децентралізовані (розподілені) системи БД, об'єктно-орієнтовані БД, застосування ХML у БД. Упродовж багатьох років роль плоскої бази даних виконували плоскі таблиці (плоскі БД) типу списків в Excel. Приблизно від 2000 року більше половини БД використовують реляційну модель.

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

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

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

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

Рис. 1. Приклад ієрархічної структури даних

В ієрархічній моделі зв'язок даних "один до одного" (1:1) означає, що кожному значенню (екземпляру) елемента даних А відповідає одне і тільки одне значення, пов'язаного з ним елемента В. Наприклад, поміж такими елементами пар даних, як код лікарського препарату і його найменуванням є вищезазначений зв'язок, так як тільки кожному коду лікарського препарату відповідає одне його найменування.

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

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

Мережева модель даних.

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

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

Рис. 2. Приклад мережевої структури даних

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

Реляційна модель даних

Поняття реляційний (англ. relation — співвідношення, зв’язок) пов'язане з розробками відомого американського фахівця в галузі систем баз даних Е. Кодда. У реляційній моделі даних об'єкти і взаємозв'язки між ними представляються за допомогою таблиць. Взаємозв'язки також подаються як об'єкти. Кожна таблиця представляє один об'єкт і складається з рядків і стовпців. Порядок розміщення рядків і стовпців у таблиці довільний; таблиця такого типу називається відношенням. У сучасній практиці для рядка використовується термін «запис», а для стовпця термін «поле». Таблиця повинна мати поле чи комбінацію полів, що єдиним способом ідентифікують кожний рядок у таблиці (ключове поле).

Таблиця має такі властивості:

  • кожний елемент таблиці є одним елементом даних;

  • усі стовпці в таблиці однорідні; це означає, що елементи стовпця мають однаковий тип;

  • стовпцям присвоєні унікальні імена;

  • у таблиці немає двох однакових рядків.

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

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

Розглянемо приклад, в якому розглядається таблиця з даними пацієнтів медичної клініки "МедСервіс".

Patients (Пацієнти)

PatientlD

(Код пацієнта)

Surname (Прізвище)

Name (Ім’я)

Address (Адреса)

City (Місто)

1

Smith

Julie

25 Oak Street

Airport West

2

Wong

Alan

1/47 Haines Avenue

Box Hill

3

Arthur

Michelle

357 North Road

Yarraville

Patients (Пацієнти)

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

Стовпці

Кожен стовпець у таблиці має унікальне ім'я і містить різноманітні дані. Кожному стовбцю відповідає певний тип даних. Наприклад, у таблиці Patients, можна побачити, що стовпець PatientlD (Код_пацієнта) зберігає цілочисельну інформацію, а інші три стовбці – стрічкову (тобто текст і числа). Стовпці називають полями або атрибутами.

Рядки

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

Значення

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

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

Розрізняють первинні і вторинні (зовнішні) ключі.

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

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

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

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

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

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

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

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

ПРИКЛАД:

Пацієнтів потрібно розрізняти. Зазвичай імена не дуже підходять для цього - якщо ваше ім'я досить поширене, думається, цілком зрозуміло, чому так складно відрізнити одного Сидорова Івана Петровича від інших Сидорових Іванів Петровичів. Взяти, наприклад, Julie Smith з таблиці Patients. Якщо відкрити телефонну книгу, то може виявитися, що такі ім'я та прізвище зустрічаються у ній дуже часто.

Існує кілька способів відрізнити Julie Smith від інших. Наприклад, найімовірніше, вона - єдина Julie Smith, проживає за даною адресою. Однак рядок "Julie Smith, яка мешкає за адресою 25, Oak Street, Airport West" занадто довга і звучить надто офіційно. До того ж подібний спосіб ідентифікації передбачає використання декількох стовпців таблиці.

Стовпець ідентифікації в таблиці називається первинним ключем (primary key). Ключ може складатися з декількох стовпців. Наприклад, якщо б ми вирішили ідентифікувати Julie Smith по рядку "Julie Smith, of 25 Oak Street, Airport West", то ключ складався б із стовпців Name, Address і City. При цьому не можна було б гарантувати його унікальність.

Зазвичай бази даних складаються з декількох таблиць, для яких ключ служить сполучною ланкою. На рис.3 показано базу даних, в яку додана друга таблиця. У ній розміщуються відомості про візити, зроблені пацієнтами. Кожна стрічка в таблиці Visits (Візити) представляє собою один візит, зроблений одним пацієнтом. Пацієнта можна ідентифікувати за Кодом пацієнта (PatientlD), що зберігається в таблиці.

PatientlD

(Код пацієнта)

Surname (Прізвище)

Name (Ім’я)

Address (Адреса)

City (Місто)

1

Smith

Julie

25 Oak Street

Airport West

2

Wong

Alan

1/47 Haines Avenue

Box Hill

3

Arthur

Michelle

357 North Road

Yarraville

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]