Лекція 4
Тема 4. Моделі та типи даних
План.
Моделі даних та концептуальне моделювання.
Об’єктні моделі даних.
Моделі даних на основі записів: реляційна модель даних; мережева модель даних; ієрархічна модель даних.
Фізичні моделі даних.
Рекомендована література.
[1], гл. 3.
[2], гл. 2, п.2.3.
1. Моделі даних та концептуальне моделювання Класифікація моделей даних.
Одними з основних у концепції баз даних є узагальнення категорії „дані” і „модель даних”.
Поняття „дані” в концепції БД – це набір конкретних значень, параметрів, які характеризують об’єкт, умову, ситуацію або інші фактори. Приклад даних: Шевченко Микола Степанович, 1500 грн. і т. п. Дані не мають певної структури і вони не є певною інформацією. Дані стають інформацією тоді, коли користувач задає їм певну структуру (модель). Не існує однозначного визначення цього терміну, у різних авторів ця абстракція визначається з деякими відмінностями, але проте можна виділити щось загальне в цих визначеннях.
Модель даних – це деяка абстракція, яка будучи застосована до конкретних даних, дозволяє користувачам і розробникам трактувати їх вже як інформацію – відомості, які містять не лише дані, а і зв’язки між ними.
На мал. 2.3 представлена класифікація моделей даних.
Рис. 2.3.
Класифікация моделей даних
Уточнимо:
Модель даних — це сукупність структури даних, операцій над ними (операції маніпулювання даними) та обмежень цілісності. Іншими словами, модель визначає, в який спосіб відбувається об’єднання даних у структури різної складності, які існують обмеження на значення даних і як здійснюється оперування цими даними.
Основою для будь-якої структури даних є відображення елементарної одиниці даних у вигляді такої трійки: <об’єкт, властивість об’єкта, значення властивості>. Сукупність взаємопов’язаних між собою елементарних одиниць даних може відображуватися різноманітними способами, що приводить до формування різних структур, а відтак - різних моделей даних. Моделі даних поділяються на два класи: сильно та слабко типізовані.
У сильно типізованих моделях усі дані мають належати до певної категорії, або типу. Якщо дані не підпадають під жодну з категорій, їх потрібно типізувати штучно. Деякі моделі будуються у такий спосіб, що категорії визначаються наперед і не можуть змінюватися динамічно. У цьому випадку модельований світ начебто вміщується в гамівну сорочку. Наприклад, категорія «службовець» - строго фіксована, й усі її об’єкти повинні мати однакові властивості та структуру.
Сильно типізовані моделі мають значні переваги, бо дають змогу побудувати абстракції властивостей даних і дослідити їх у термінах категорій. Більшість моделей, що використовуються в автоматизованих системах, зокрема й базах даних, належать до сильно типізованих. (Це стосується й усіх моделей даних, що розглядаються далі.)
Для слабко типізованих моделей належність даних до тієї чи іншої категорії не має жодного значення. Категорії використовуються настільки, наскільки це доцільно в кожному конкретному випадку. Окремі дані можуть існувати як незалежно, так і у зв’язку з іншими. Інформація про категорії (якщо вони використовуються) розглядається як додаткова.
На відміну від сильно типізованих моделей, слабко типізовані забезпечують інтеграцію даних і категорій. Найкращі можливості такої інтеграції надаються численням предикатів, яке у багатьох моделях даних використовується для зображення знань, що не підтримуються базовими засобами моделювання.
Найбільший інтерес викликають моделі даних, використовувані на концептуальному рівні. По відношенню до них зовнішні моделі називаються підсхемами і використовують ті ж абстрактні категорії, що і концептуальні моделі даних.
Окрім трьох розглянутих рівнів абстракції при проектуванні БД існує ще один рівень, передуючий їм. Модель цього рівня повинна виражати інформацію про наочну область у вигляді, незалежному від використовуваної СУБД. Ці моделі називаються інфологічними, або семантичними, і відображають в природній і зручній для розробників і інших користувачів формі інформаційно-логічний рівень абстрагування, пов'язаний з фіксацією і описом об'єктів наочної області, їх властивостей і їх взаємозв'язків.
Міфологічні моделі даних використовуються на ранніх стадіях проектування для опису структур даних в процесі розробки застосування, а даталогічні моделі вже підтримуються конкретній СУБД.
Документальні моделі даних відповідають уявленню про слабоструктуровану інформацію, орієнтовану в основному на вільні формати документів, текстів на природній мові
У БД з 3-х архітектурою використовують поняття моделі даних по відношенню до кожного рівня.
Фізична модель даних оперує категоріями, що стосуються організації зовнішньої пам’яті і структур зберігання, які використовуються в даному операційному середовищі. В якості фізичних моделей використовуються різні методи розміщення даних, основаних на файлових структурах: організація файлів прямого і послідовного доступу, індексних файлів, інвертованих файлів, файлів, які використовують різні методи хешування, взаємопов’язаних файлів.
Сучасні СУД використовують сторінкову організацію даних, як найбільш перспективну.
Поняття про моделі даних і концептуальне моделювання.
Модель даних – інтегрований набір понять для опису даних, зв’язків між ними і обмежень, які накладаються на дані в деякій установі.
Модель є представленням „реального світу” об’єктів і подій, а також існуючих між ними зв’язків.
Модель розглядають, як поєднання 3-х компонентів:
структурна частина, т. б. набір правил, за яким може бути побудована база даних;
керуюча частина, яка визначає типи допустимих операцій з даними ( операції оновлення і добування даних, зміни структури БД);
набір обмежень підтримки цілісності даних (необов’язково), які гарантують коректність використовуваних даних.
Мета побудови моделі даних полягає в представлені даних в зрозумілому вигляді.
Для відображення архітектури ANSI-SPAPC розглядають 3 зв’язані моделі даних:
зовнішня модель даних, яка відображає представлення кожного типу користувача – предметна область;
концептуальна модель даних, яка відображає представлення даних, не залежить від типу обраної СУБД;
внутрішня модель даних, яка відображає концептуальну схему визначеним чином, яке зрозуміле обраній цільовій СУБД.
Моделі даних поділяються на 3 категорії:
о б’єктні (object-based); використовуються для опису даних на
на основі записів(record- based); зовнішньому і концептуальному рівнях
фізичні моделі – на внутрішньому рівні.
Об’єктні моделі
При їх побудові використовуються такі поняття:
Сутність – окремий об’єкт (співробітник, місце, поняття, подія) установи, який повинен бути представлений в БД.
Атрибут – властивість, яка описує деякий аспект об’єкта і значення якого треба зафіксувати (ім’я, вік ...)
Зв’язок – асоціативне відношення між сутностями.
Типи об’єктних моделей:
модель типу „сутність-зв’язок” (ER-моделі(Entity-relationship mode))
семантична модель
функціональна модель
ОО модель
Зараз ER-модель стала одним з основних методів концептуального проектування БД і саме її ми будемо використовувати.
Моделі даних на основі записів..
Дані, що зберігаються в БД мають певну структуру – певну модель даних, яка підтримується СУБД. Розглядають таку класифікацію:
Класичні моделі:
ієрархічна
мережева
реляційна
Сучасні моделі:
постреляційна
багатовимірна
об’єктно-орієнтовна
розподільча
Ієрархічна модель.:
У такій моделі зв’язки описуються за допомогою впорядкованого графа(дерева)
Тип даних „дерево” історично з’явився першим. Його поява зв’язана з тим, що в реальному світі багато зв’язків відповідають ієрархії – „дерево”.
Тип „дерево” нагадує тип даних „запис” мови Pascal, „структури” мови С: допускається вкладеність типів, кожен із яких знаходиться на деякому рівні.
Тип „дерево” – складений, включає підтипи (піддерева), кожен із яких є типом „дерево”.
Переваги – ефективне використання пам’яті ЕОМ, непогані показники часу виконання основних операцій над даними. з ієрархічно впорядкованою інформацією.
Недоліки – громіздкість для обробки з досить складними логічними зв’язками, складність розуміння для користувача.
Основними інформаційними одиницями в ієрархічній моделі є: база даних (БД), сегмент, поле.
Поле даних визначається як мінімальна неподільна одиниця даних, яка доступна користувачеві за допомогою СУБД.
Наприклад, якщо потрібна адреса клієнта (без поділу), тоді адреса – елемент даних, якщо потрібна адреса по частинах, наприклад, місто, тоді його виділяють як окремий елемент даних: тоді зберігають його + скорочену адресу.
Сегмент називають записом. Виділяють тип сегмента (тип запису) і екземпляр сегмента/запису.
Тип сегмента – по-іменована сукупність типів елементів даних, які в нього входять. наприклад, група (номер, староста) – тип сегмента,
(24, Іванов) – екземпляр
Екземпляр сегмента утворюється із конкретних значень полів або елементів даних, які нього входять.
Кожен тип сегмента в рамках ієрархічної моделі утворює деякий набір однорідних записів. Для ідентифікації кожного запису слід мати ключ.
Сегменти об’єднуються в орієнтований граф
На концептуальному рівні визначається поняття БД в термінології ієрархічної моделі.
Схема ієрархічної БД представляє собою сукупність окремих дерев, кожне дерево в рамках моделі над фізичною БД.
Кожна фізична БД задовольняє таким обмеженням:
в кожній фізичній БД існує один кореневий сегмент;
кожен логічно вихідний сегмент може бути зв’язаний з довільним числом логічно підлеглих сегментів;
кожен логічно підлеглий сегмент може бути зв’язаним тільки з одним логічно вихідним (батьківським) сегментом;
між екземплярами сегментів також існують ієрархічні зв’язки.
A (a1,a2)
B(b1,b2,b3,b4)
C(c1,c2,c3)
D(d1,d2,d3,d4)
E(e1,e2,e3,e4)
Екземпляри – потомки одного типа, зв'зані з одним екземпляром сегмента – предка, називається близнюком.
Наприклад, B1, B2,B3 – близнюки.
Набір всіх екземплярів сегментів, підлеглих одному екземпляру кореневого сегмента називається фізичним записом.
Різні по довжині і структурі
a1, b1,b2,b3,c1,d1,d2,e1 |
Запис 1 |
a2,d4,b5,c2,c3,d3,d4,e2,e3,e4 |
Запис 2 |
Ієрархічна модель даних - найбільш проста серед всіх датологічних (концептуальних) моделей.
Приклад. Організація займається зборкою і продажем комп’ютерів, які комплектуються із готових деталей за індивідуальним замовленням. Є декілька базових моделей, які продаються без попередніх домовленостей за наявності на сховищі. В організації існує декілька філіалів і декілька сховищ, на яких зберігаються комплектуючі. Потрібно автоматизувати облік продукції, що продається.
Рішення.
Виділимо задачі, які потрібно розв’язати при розробці додатку:
При отриманні замовлення слід вияснити, яку модель замовляє замовник: типову чи індивідуальну;
Якщо замовляється типова, то виясняється тип моделі її наявність на складі і вартість. При оформлені слід зменшити кількість одиниць такої моделі, на кількість, що купляється. Покупець може поцікавитись специфікацією;
Для індивідуальної моделі слід описати весь склад цієї моделі.
Крім того може знадобитись інформація про наявність конкретних деталей на складі. Тоді буде потрібно друге нове дерево – Склади.
-
Філіал
Адреса
Керівник
Типові моделі |
|||
Ім.’я |
Вартість |
Кількість замовлень |
Кількість на складі |
Індивідуальні моделі |
||
№ замов-лення |
Вартість |
Кількість |
Склад моделі |
|||
Ім’я блока |
Характе-ристика |
Фірма виробник |
Вартість |
Склад моделі, що замовляється |
|||
Ім’я блока |
Характе-ристика |
Фірма виробник |
Вартість |
-
Склад
Номер
Адреса
Кладовщик
-
Деталь
Назва
-
Характеристика
Параметр
О диниці виміру
Величина
-
Наявність
Фірма
Гарантія
Вартість
Кількість