Повна версія

Головна arrow Інформатика arrow Бази даних: проектування

  • Увеличить шрифт
  • Уменьшить шрифт


<<   ЗМІСТ   >>

Реляційні бази даних

Неправильним буде вважати, що в інформаційних системах використовуються тільки реляційні бази даних. Найчастіше можна зустріти реалізацію баз даних на основі ієрархічної, мережевої, реляційної і інших моделей. Проте, більшість інформаційних систем ґрунтуються на реляційних базах даних, основу яких заклав Е. Кодд в кінці 1960-х рр., Визначивши основні правила і операції, які повинні застосовуватися при реалізації таких баз даних. Багато моделей баз даних, які можна зустріти в інформаційних системах, так чи інакше ґрунтуються на принципах реляційних баз даних і використовують різні додаткові інструменти для поліпшення роботи з окремими видами даних, наприклад, з географічними даними, даними в реальному режимі часу (потокові дані), багатовимірними даними та ін.

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

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

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

атрибутами і значеннями на перетині відповідного атрибута із записом (кортежем).

image12

Мал. 1.12. Приклад відносини в реляційної моделі


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

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

R {A, T}, i = {1..n} (11)

В даному поданні під A, розуміється атрибут, що описує одну характеристику даних, а під T- тип даних, з яким повинні відповідати подаються в відношенні дані. Представлений вище приклад є неформальним викладом [1] відносини. У його заголовку не вказані типи даних, якими описуються подаються в тілі відносини відомості.

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

Вод терміном "Домен" в теорії баз даних розуміється допустиме безліч названих значень одного типу мають певний сенс

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

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

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

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

Опис кортежів використовує ряд важливих властивостей, деякі з яких представлені нижче:

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

для компонентів кортежу, аналогічно елементам домену, чи не передбачається будь-яке упорядкування;

кожна підмножина кортежів представляється гоже кортежем.

Об'єднуючи домени і кортежі, можна сформувати ставлення, яке в загальному вигляді визначається в такий спосіб;

R [<Тема>] {<Список кортежів>}. (1.2)

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

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

image13

Мал. 1.13. Приклад відносини "Співробітники"

Будь-яке відношення в реляційній базі даних характеризується наступними властивостями.

1. Кожен кортеж містить тільки одне значення відповідного типу по кожному атрибуту (відношення нормалізовано).

Кожному атрибуту в представленому прикладі в рамках кожного кортежу поставлено у відповідність тільки одне значення, що видно на перетині виділеного домену "ПІБ співробітника" і кортежу з ПІБ "Петров Петро Петрович". Ставлення, яке відповідає цій властивості, є нормалізованим [3] , тобто знаходиться в даному випадку в першій нормальній формі, 1НФ.

2. Атрибути не є впорядкованими по якомусь правилу.

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

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

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

Дана властивість випливає з того, що тіло відношення представляється

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

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

4. Стосовно відсутні дублікати кортежів.

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

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

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

image14

Мал. 1.14. Приклад реляційної моделі даних


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

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

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

image15

Мал. 1.15. Приклад розширеного уявлення реляційної моделі даних


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

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

Таблиця 13

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

вид уявлення

використовувана

термінологія

призначення

Модель з відображенням найменування відносини, атрибутивного складу, зв'язків

сутність

Атрибут

зв'язок

Тип даних

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

Модель з відображенням заголовка і тіла з можливими даними

ставлення

Заголовок

Атрибут / Домен

Тип даних

тіло

кортеж

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

Модель з відображенням структур фізичного представлення даних в СУБД

Таблиця

Атрибут / 11оле / Колонка

Тип даних

зв'язок

Використовується для відображення варіанти подання структури, яка буде реалізована на фізичному рівні в СУБД


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

  • [1] Бойко В. В .. Савінков В. М. Проектування баз ланних інформаційних систем.
  • [2] Типи даних будуть розглядатися в рамках наступних глав.
  • [3] Термін "Нормалізація" і нормальні форми будуть розглядатися в гл. 2.
 
<<   ЗМІСТ   >>