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

1 2 3

Ім'я файлу: Лекція 2 Моделі і типи даних.docx
Розширення: docx
Розмір: 1425кб.
Дата: 24.01.2024
скачати
Пов'язані файли:
карта хворого.docx
Документ Microsoft Office Word (2).docx
Туризм в Італії.pptx
геометрія конспект.docx
СХЕМА ТЕХПРОЦЕСУ.doc
Курсова Саміленко В.О. кінцева (3).docx
Дошкільна педагогіка.docx
твір.rtf
Завдання .docx
Фетишизм.docx
Дмитрів Богдан (2).pdf
59283 (1).doc

Лекція 2 . МОДЕЛІ І ТИПИ ДАНИХ
Збережені в базі дані мають певну логічну структуру - іншими словами, описуються деякою моделлю представлення даних (моделлю даних), підтримуваної СУБД. До числа класичних відносяться наступні моделі даних:

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

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

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

В ієрархічній моделі зв'язок між даними можна описати за допомогою упорядкованого графа (або дерева). Спрощено уявлення зв'язків між даними в ієрархічній моделі показане на рис. 2.1 .

Рисунок 2.1 - Представлення зв’язків в ієрархічній моделі
У 1968 році була введена в експлуатацію перша промислова СУБД система IMS фірми IBM (рис. 2.2). Це була перша ієрархічно база даних завдяки якій визначили ряд фундаментальних понять в теорії систем баз даних, які і досі є основними для мережевої моделі даних.

Таку форму використовують:

сервери каталогів, такі, як LDAP і Active Directory (допускають чітке уявлення у вигляді дерева)
файлові, база налаштувань Windows WMI і реєстр Windows.
Google App Engine Datastore API

Рисунок 2.2 - Деревоподібна структура файлової системи
Ієрархічні моделі мають деревоподібну структуру, де кожному вузлу відповідає один сегмент, який представляє собою пойменований лінійний кортеж полів даних. Кожному сегменту відповідає один вхідний і кілька вихідних сегментів. Кожен елемент структури лежить на єдиному ієрархічному шляху, що починається від кореневого. Ієрархічні бази даних найбільш придатні для моделювання структур, за своєю природою є ієрархічними. Як приклади можна привести військові підрозділи або складні механізми, що складаються з більш простих вузлів, які в свою чергу теж можна піддати декомпозиції. Проте існує значна кількість організацій, які не зводяться до простої ієрархії. У цій моделі запит, спрямований вниз по ієрархії, простий, однак запит, спрямований вгору по ієрархії, більш складний. До переваг ієрархічної моделі даних відносяться ефективне використання пам'яті ЕОМ і непогані показники часу виконання основних операцій над даними. Ієрархічної базою даних є файлова система, що складається з кореневої директорії, в якій є деревоподібна структура піддиректорій і файлів.

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

Графічно таку структуру можна зобразити у вигляді дерева, що складається з об'єктів різних рівнів. Верхній рівень займає один об'єкт, другий - об'єкти другого рівня і так далі.

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

Рисунок 2.3 - Приклад типу «дерево»
Дані в базі з наведеною схемою (рис. 2.3) можуть виглядати, на приклад, як показано на рис. 2.4.

Рисунок 2.4 - Дані в ієрархічній базі
Для організації фізичного розміщення ієрархічних даних в пам'яті ЕОМ можуть використовуватися такі групи методів:

уявлення лінійним списком з послідовним розподілом пам'яті (адресна арифметика, ліво спискові структури);
уявлення зв'язковими лінійними списками (методи що використовують покажчики і довідники).

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

пошук зазначеного примірника БД (наприклад, дерева з значенням 10 в поле ВІД_НОМЕР);
перехід від одного дерева до іншого;
перехід від одного запису до іншого всередині дерева (наприклад, до наступного запису типу Співробітники);
вставка нового запису в зазначену позицію;
видалення поточного запису і т. д.

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

До переваг ієрархічної моделі даних відносяться ефективність використання пам'яті ЕОМ і непогані показники часу виконання основних операцій над даними. Ієрархічна модель даних зручна для роботи з ієрархічно впорядкованою інформацією.

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

На ієрархічній моделі даних засноване порівняно обмежена кількість СУБД, в числі яких можна назвати системи IMS, PC / Focus, Team-Up і Data Edge.

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

Мережева модель даних є більш загальною структурою по порівнянні з ієрархічною. Основні принципи мережевої моделі даних були розроблені в середині 60-х років, еталонний варіант мережевої моделі даних описаний в звітах робочої групи по мовам баз даних (CОnference on DАta SYstem Languages) CODASYL (1971).

У мережевих БД поряд з вертикальними реалізовані і горизонтальні зв'язки. Кожен окремий сегмент (осередок) може мати довільне число безпосередніх вихідних (старших) сегментів, а також довільне число породжених (молодших) (рис. 2.5). Це забезпечує подання відносини "багато до багатьох".

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

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

Для опису схеми мережевої БД використовується дві групи типів: «записі» і «зв'язок ». Мережева БД складається з набору записів і набору відповідних зв'язків. На формування зв’язку особливих обмежень не накладається. Якщо в ієрархічних структурах запис-нащадок могла мати тільки один запис-предка, то в мережевий моделі даних запис-нащадок може мати довільне число записів-предків. Приклад мережевий моделі наведено на рис. 2.6.

Рисунок 2.6 - Приклад схеми мережевої БД
Фізичне розміщення даних в базах мережевого типу може бути організовано практично тими ж методами, що і в ієрархічних базах даних.

До числа найважливіших операцій маніпулювання даними баз мережевого типу можна віднести наступні:

пошук запису в БД;
перехід від предка до першого нащадку;
перехід від нащадка до предка;
створення нового запису;
видалення поточного запису;
оновлення поточного запису;
включення запису в зв'язок;
виключення запису з зв'язку;
зміна зв'язків і т. п.

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

Недоліком мережевої моделі даних є висока складність і жорсткість схеми БД, побудованої на її основі, а також складність для розуміння і виконання обробки інформації в БД звичайним користувачем. Крім того, в мережевий моделі даних ослаблений контроль цілісності зв'язків внаслідок допустимості встановлення довільних зв'язків між записами.

Системи на основі мережевої моделі не отримали широкого розповсюдження на практиці. Найбільш відомими мережевими СУБД є: IDMS, db_VistaIII.

2.3. Реляційна модель

Реляційна модель даних ґрунтується на понятті відношення (relation). Реляційна модель даних - створена Едгаром Коддом логічна модель даних, що описує:

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

Едгар Франк - (23 серпня 1923 -18 квітня 2003 року) - британський вчений, роботи якого заклали основи теорії реляційних баз даних. Працюючи в компанії IBM, він створив реляційну модель даних. У 1970 видав роботу «A Relational Model of Data for Large Shared Data Banks», яка вважається першою роботою по реляційної моделі даних.

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

У 2002 р. журнал Forbes помістив реляційну модель даних в список найважливіших інновацій останніх 85 років.

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

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

Реляційна модель даних передбачає структуру даних, обов'язковими об'єктами якої є:

• відношення;

• атрибут;

• домен;

• кортеж;

• ступінь;

• кардинальність;

• первинний ключ.

Відношення - це плоска (двовимірна) таблиця, що складається з стовпців і рядків:

ID	Прізвище	Ім'я	Посада	р.н.
1	Петров	Ігор	директор	1968
2	Іванов	Олег	юрист	1973
3	Кім	Олена	Бухгалтер	1980
4	Сенін	Ілля	Менеджер	1981
5	Васін	Сергій	Менеджер	1978

Атрибут - це пойменований стовпець відносини.

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

Кортеж - це рядок відносини.

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

Кардинальність - це кількість кортежів, яке містить відношення.

Первинний ключ - це унікальний ідентифікатор для таблиці.

Відносини і їх реалізація в реляційної моделі даних .

Ставлення R на безлічі доменів D 1 , D 2 , ..., D n - це підмножина декартова множення цих доменів:

R ⊆ D 1 × D 2 × ... × D n

Приклад. Визначено домени: D1 - безліч прізвищ викладачів, D2 - безліч аудиторій, D3 - безліч навчальних груп, D4 - безліч навчальних дисциплін. Записати відносини: 1) закріплення викладачів за навчальними курсами; 2) розклад занять в групах.

Рішення.

1) закріплення викладачів за навчальними курсами:

R ⊆ D 1 × D 4.

Це відношення визначає безліч викладачів, які ведуть безліч навчальних дисциплін.

2) розклад занять в групах:

R ⊆ D 2 × D 3 × D 4.

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

Властивості відносин:

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

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

Види відносин:

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

Іменоване відношення - це змінна відносини, певна в СУБД (системи управління базами даних) за допомогою оператора CREATE (CREATE TABLE, CREATE BASE RELATION, CREATE VIEW, CREATE SNAPSHOT).

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

Похідне відношення - це відношення, яке визначено через інші іменовані відносини. Похідне відношення залежить від існування інших - базових - відносин.

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

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

Знімки (snapshot) - це те саме, що і уявлення, але з фізичним збереженням і з періодичним оновленням.

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

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

Ключі відносини можуть бути наступними:

суперключ;
потенційний ключ;
первинний ключ;
зовнішній ключ;
сурогатний ключ.

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

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

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

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

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

У відношенні може бути більше одного потенційного ключа.

Первинний ключ (primary key, PK) - це один з потенційних ключів відношення, обраний в якості основного ключа. Припустимо оголошення одного і тільки одного первинного ключа. Атрибути первинного ключа не можуть набувати значень Null.

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

Сурогатний ключ - це службовий атрибут, доданий до вже наявних інформаційних атрибутів відносин. Призначення сурогатного ключа - служити первинним ключем відношення. Значення цього атрибута генерується штучно.
Приклад. Є база даних мережі аптек. У ній є таблиця "Аптеки", в яку занесені всі аптеки мережі, і є таблиця "Препарати". Крім того, є таблиця "Наявність", в яку заносяться дані про наявність препаратів в кожній аптеці. У таблиці наявність є поля: "Аптека" (в ній - ідентифікатори аптек), "Препарат" (в ній - ідентифікатори препаратів), "Кількість". Виникає проблема: в разі надходження в аптеку деякої кількості препарату можна не помітити, що в тій же аптеці той же препарат вже міститься в деякої кількості і зробити нову запис в таблиці, в якій аптека і препарат будуть повторюватися. Як на рівні ключів уникнути цієї проблеми?

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

Поняття реляційної цілісності:

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

Визначник NULL. Значення Null позначає той факт, що значення не визначене. Null не належить ніякому типу даних і може бути присутнім серед значень будь-якого атрибута, визначеного на будь-якому типі даних. Двомісна «арифметична» операція з Null дає Null. Операція порівняння з Null дає UNKNOWN.

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

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

Посилальна цілісність: видалення кортежу. Існує три підходи видалення кортежу з відносини, на яку веде посилання.

Обмеження видалення-Delete: Restrict.
Каскадне видалення-Delete: Cascade.
Установка значення NULL, переклад значення зовнішнього ключа в невизначений стан - Delete: Set NULL.

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

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

Установка значення NULL. При видаленні кортежу, на який є посилання, у всіх кортежів значення зовнішнього ключа автоматично стає повністю невизначеним.
Приклад. Є база даних порталу новин. У ній є таблиця "Рубрики" (політика, економіка, спорт і т. п.), є таблиця "Автор" (прізвища та імена авторів). Є таблиця "Тексти", в якій в кожному записі про текст новини є поля "Рубрика" (з ідентифікаторами рубрик з відповідної таблиці) і "Автор" (з ідентифікаторами рубрик з відповідної таблиці). Якими способами можна домогтися, щоб при видаленні рубрики і автора була дотримана посилальна цілісність даних?

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

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

Гідність реляційної моделі даних полягає в простоті, зрозумілості та зручності фізичної реалізації на ЕОМ. Саме простота і зрозумілість для користувача з'явилися основною причиною їх широкого використання

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

Прикладами реляційних СУБД є: dBase III Plus і dBase IY (фірма Ashton-Tate), DB2 (IBM), R: BASE (Microrim), FoxPro і FoxBase (Fox Software), Paradox і dBASE for Windows (Borland), Visual FoxPro і Access (Microsoft), Clarion (Clarion Software), Ingres (ASK Computer Systems) і Oracle (Oracle).

1 2 3

скачати

© Усі права захищені
написати до нас