3. Лекція 6

4. Друга стадія концептуального проектування бд. (Моделі даних субд. Представлення концептуальної моделі засобами моделі даних субд)

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

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

5. 6.1. Представлення концептуальній моделі засобами моделі даних субд

Загальні уявлення про моделі даних СУБД

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

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

Враховуючи обидва вищезгадані боки, визначимо основні структури моделей даних СУБД, використовувані для представлення концептуальної моделі предметної області (сутностей, атрибутів, зв'язків).

Елемент даних (поле) – найменша пойменована одиниця даних. Використовується для представлення значення атрибуту.

З елементом даних нерозривно пов'язано поняття "Тип даних", який може приймати відповідне поле. У різних СУБД можуть використовуватися різні типи даних, найбільш поширеними з яких (використовувані в багатьох СУБД) є такі: числовий (numeric), символьний (char), дата (date) і т. д.

Запис – пойменована сукупність полів. Використовується для представлення сукупності атрибутів сутності (записи про сутність).

Екземпляр запису – запис з конкретними значеннями полів.

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

Файл – пойменована сукупність екземплярів записів одного типу. Використовується для представлення однорідного набору сутностей.

Набір файлів – пойменована сукупність файлів, що обробляються в системі. Використовується для представлення декількох наборів сутностей.

Введемо поняття "група", узагальнююче поняття "файл" і "запис".

Група – це пойменована сукупність елементів даних або елементів даних і інших груп.

Найважливішим поняттям концептуальної моделі є поняття зв'язку між сутностями (наборами сутностей). У моделях даних СУБД відповідне поняття передається поняттям "Групове відношення".

Групове відношення – пойменоване бінарне відношення, задане на двох множинах екземплярів даних груп. По характеру бінарних зв'язків розрізняють групові стосунки вигляду 1:1, 1:M, M:1, M:N. Такі пари чисел називають коефіцієнтами групового відношення. У груповому відношенні один член групи призначається власником відношення, інший – членом.

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

Для представлення групового відношення використовується дві форми:

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

За типом графів розрізняють:

• ієрархічну модель (граф без циклів – дерево);

• мережеву модель (орієнтований граф загального виду).

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

Модель даних СУБД описується таким чином:

• визначені можливі типи і характеристики логічних структур даних (полів, записів, файлів);

• задані правила складання структур загальнішого типу із структур простіших типів (наприклад, записів з полів, файлів із записів і т.д.);

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

• визначені можливі дії над структурами і правила їх виконання, що включають:

  • основні елементарні операції над даними;

  • узагальнені операції (процедури);

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

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

  • спеціальний клас процедур (тригери).

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

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

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

Побудова моделі даних бази даних (відображення концептуальної моделі в модель даних СУБД)

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

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