Лекція 4

Тема 4. Моделі та типи даних

План.

1. Моделі даних та концептуальне моделювання.

2. Об’єктні моделі даних.

3. Моделі даних на основі записів: реляційна модель даних; мережева модель даних; ієрархічна модель даних.

4. Фізичні моделі даних.

Рекомендована література.

[1], гл. 3.

[2], гл. 2, п.2.3.

1. Моделі даних та концептуальне моделювання Класифікація моделей даних.

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

Поняття „дані” в концепції БД – це набір конкретних значень, параметрів, які характеризують об’єкт, умову, ситуацію або інші фактори. Приклад даних: Шевченко Микола Степанович, 1500 грн. і т. п. Дані не мають певної структури і вони не є певною інформацією. Дані стають інформацією тоді, коли користувач задає їм певну структуру (модель). Не існує однозначного визначення цього терміну, у різних авторів ця абстракція визначається з деякими відмінностями, але проте можна виділити щось загальне в цих визначеннях.

Модель даних – це деяка абстракція, яка будучи застосована до конкретних даних, дозволяє користувачам і розробникам трактувати їх вже як інформацію – відомості, які містять не лише дані, а і зв’язки між ними.

На мал. 2.3 представлена класифікація моделей даних.

Рис. 2.3.

Класифікация моделей даних

Уточнимо:

Модель даних — це сукупність структури даних, операцій над ними (операції маніпулювання да­ними) та обмежень цілісності. Іншими словами, модель визначає, в який спосіб відбувається об’єднання даних у структури різної складності, які існують обмеження на значення даних і як здійснюється оперування цими даними.

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

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

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

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

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

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

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

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

Документальні моделі даних відповідають уявленню про слабоструктуровану інформацію, орієнтовану в основному на вільні формати документів, текстів на природній мові

У БД з 3-х архітектурою використовують поняття моделі даних по відношенню до кожного рівня.

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

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

Поняття про моделі даних і концептуальне моделювання.

Модель даних – інтегрований набір понять для опису даних, зв’язків між ними і обмежень, які накладаються на дані в деякій установі.

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

Модель розглядають, як поєднання 3-х компонентів:

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

2. керуюча частина, яка визначає типи допустимих операцій з даними ( операції оновлення і добування даних, зміни структури БД);

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

Мета побудови моделі даних полягає в представлені даних в зрозумілому вигляді.

Для відображення архітектури ANSI-SPAPC розглядають 3 зв’язані моделі даних:

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

2. концептуальна модель даних, яка відображає представлення даних, не залежить від типу обраної СУБД;

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

Моделі даних поділяються на 3 категорії:

1. о б’єктні (object-based); використовуються для опису даних на

2. на основі записів(record- based); зовнішньому і концептуальному рівнях

3. фізичні моделі – на внутрішньому рівні.

Об’єктні моделі

При їх побудові використовуються такі поняття:

1. Сутність – окремий об’єкт (співробітник, місце, поняття, подія) установи, який повинен бути представлений в БД.

2. Атрибут – властивість, яка описує деякий аспект об’єкта і значення якого треба зафіксувати (ім’я, вік ...)

3. Зв’язок – асоціативне відношення між сутностями.

Типи об’єктних моделей:

1. модель типу „сутність-зв’язок” (ER-моделі(Entity-relationship mode))

2. семантична модель

3. функціональна модель

4. ОО модель

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

Моделі даних на основі записів..

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

Класичні моделі:

• ієрархічна

• мережева

• реляційна

Сучасні моделі:

• постреляційна

• багатовимірна

• об’єктно-орієнтовна

• розподільча

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

У такій моделі зв’язки описуються за допомогою впорядкованого графа(дерева)

Тип даних „дерево” історично з’явився першим. Його поява зв’язана з тим, що в реальному світі багато зв’язків відповідають ієрархії – „дерево”.

Тип „дерево” нагадує тип даних „запис” мови Pascal, „структури” мови С: допускається вкладеність типів, кожен із яких знаходиться на деякому рівні.

Тип „дерево” – складений, включає підтипи (піддерева), кожен із яких є типом „дерево”.

Переваги – ефективне використання пам’яті ЕОМ, непогані показники часу виконання основних операцій над даними. з ієрархічно впорядкованою інформацією.

Недоліки – громіздкість для обробки з досить складними логічними зв’язками, складність розуміння для користувача.

Основними інформаційними одиницями в ієрархічній моделі є: база даних (БД), сегмент, поле.

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

Наприклад, якщо потрібна адреса клієнта (без поділу), тоді адреса – елемент даних, якщо потрібна адреса по частинах, наприклад, місто, тоді його виділяють як окремий елемент даних: тоді зберігають його + скорочену адресу.

Сегмент називають записом. Виділяють тип сегмента (тип запису) і екземпляр сегмента/запису.

Тип сегмента – по-іменована сукупність типів елементів даних, які в нього входять. наприклад, група (номер, староста) – тип сегмента,

(24, Іванов) – екземпляр

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

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

Сегменти об’єднуються в орієнтований граф

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

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

Кожна фізична БД задовольняє таким обмеженням:

• в кожній фізичній БД існує один кореневий сегмент;

• кожен логічно вихідний сегмент може бути зв’язаний з довільним числом логічно підлеглих сегментів;

• кожен логічно підлеглий сегмент може бути зв’язаним тільки з одним логічно вихідним (батьківським) сегментом;

• між екземплярами сегментів також існують ієрархічні зв’язки.

A (a₁,a₂)

B(b₁,b₂,b₃,b₄)

C(c₁,c₂,c₃)

D(d₁,d₂,d₃,d₄)

E(e₁,e₂,e₃,e₄)

Екземпляри – потомки одного типа, зв'зані з одним екземпляром сегмента – предка, називається близнюком.

Наприклад, B₁, B₂,B₃ – близнюки.

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

Різні по довжині і структурі

a1, b1,b2,b3,c1,d1,d2,e1

Запис 1

a2,d4,b5,c2,c3,d3,d4,e2,e3,e4

Запис 2

Ієрархічна модель даних - найбільш проста серед всіх датологічних (концептуальних) моделей.

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

Рішення.

Виділимо задачі, які потрібно розв’язати при розробці додатку:

1. При отриманні замовлення слід вияснити, яку модель замовляє замовник: типову чи індивідуальну;

2. Якщо замовляється типова, то виясняється тип моделі її наявність на складі і вартість. При оформлені слід зменшити кількість одиниць такої моделі, на кількість, що купляється. Покупець може поцікавитись специфікацією;

3. Для індивідуальної моделі слід описати весь склад цієї моделі.

Крім того може знадобитись інформація про наявність конкретних деталей на складі. Тоді буде потрібно друге нове дерево – Склади.

Філіал
Адреса	Керівник

Типові моделі
Ім.’я	Вартість	Кількість замовлень	Кількість на складі

Індивідуальні моделі
№ замов-лення	Вартість	Кількість

Склад моделі
Ім’я блока	Характе-ристика	Фірма виробник	Вартість

Склад моделі, що замовляється
Ім’я блока	Характе-ристика	Фірма виробник	Вартість

Склад
Номер	Адреса	Кладовщик

Деталь

Назва

Характеристика
Параметр	О диниці виміру	Величина

Наявність
Фірма	Гарантія	Вартість	Кількість