2.4. Рівні моделей даних

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

Таблиця 2.3. Види структур комп'ютерної інформаційної системи

Структура	Склад
	Елементи	Зв'язки
Функціона-льна	Підсистеми (компоненти), функції інформаційної системи або її частини	Потоки інформації, що циркулює між елементами
Технічна	Оснащення інформаційної системи комплексом технічних засобів	Інформаційний обмін
Організаці-йна	Колективи людей і окремих виконавців	Інформаційні, супідрядності і взаємодії.
Документ-тальна	Неподільні компоненти і документи	Взаємодії, входимости і супідрядності
Алгоритмічна	Алгоритми	Інформаційні масиви
Програмна	Програмні модулі	Інформаційні масиви
Інформаційна	Форми існування і подання інформації в системі, інформаційні масиви	Операції перетворення інформації в системі; операції роботи з масивами: введення, коректування, перегляд, знищення і т.д.

Сутність функціонального розбиття добре відображена у відомій формулі:

“Програма=Дані + Алгоритми”.

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

Об'єктне розбиття останнім часом називають компонентним, що знайшло віддзеркалення в спеціальному терміні: "розроблення, засноване на компонентах" (Component Based Development – CBD). При цьому використовується інший принцип декомпозиції - система розбивається на “активну сутність ” – об'єкти або компоненти, які взаємодіють один з одним, обмінюючись повідомленнями і виступаючи один до одного у відношенні “клієнт/сервер”. Повідомлення, які може приймати об'єкт, визначені в його інтерфейсі. У цьому сенсі пересилання повідомлення "об'єкт-серверу" еквівалентна виклику відповідного методу об'єкту. Більшість існуючих CASE-засобів опираються в основному на структурні методології.

Прикладом системи, в якій здійснюється функціональне розбиття є BPwin (система моделювання потоків даних (розділ 7)), що підтримує методології IDEF0 (функціональна модель), IDEF3 (WorkFlow Diagram і DFD (DataFlow Diagram) (розділ 7). Функціональна модель призначена для опису існуючих бізнес-процесів на підприємстві і ідеального стану речей – того, до чого потрібно прагнути. Методологія IDEF0 забезпечує побудову ієрархічної системи діаграм – одиничних описів фрагментів системи. Спочатку проводиться опис системи загалом і її взаємодії з навколишнім світом (контекстна діаграма), після чого проводиться функціональна декомпозиція – система розбивається на підсистеми і кожна підсистема описується окремо (діаграми декомпозиції). Потім кожна підсистема розбивається на дрібніші і так далі до досягнення потрібного ступеня деталізації. Після кожного сеансу декомпозиції проводиться сеанс експертизи: кожна діаграма перевіряється експертами предметної області, представниками замовника, людьми, що безпосередньо беруть участь в бізнес-процесі. Така технологія створення моделі дозволяє побудувати модель, адекватну предметній області на всіх рівнях абстрагування.

На основі моделі процесів BPwin за допомогою іншого CASE-засобу – Erwin (розділ 13) можна побудувати модель даних. Прийнято виділяти два рівні представлення моделі даних – логічний і фізичний (рис. 2.2).

Рис. 2.2. Рівні моделювання.

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

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

Логічна модель даних має відображати в комп’ютерно-орієтовану даталогічну модель, "зрозумілу" СКБД. В процесі розвитку теорії і практичного використання баз даних, а також засобів обчислювальної техніки створювалися СКБД, що підтримують різні даталогічні моделі.

Мережева модель даних

Це одна з найбільш ранніх моделей даних. Типова мережева модель даних була запропонована робочою групою з баз даних системного комітету CODASYL (Conference of Data System Languages), основними функціями якого були аналіз відомих фірмових систем опрацювання керівних даних з єдиних позицій і в єдиній термінології, узагальнення досвіду організації таких систем і розроблення рекомендацій щодо створення відповідних систем. Детальніше функції CODASYL розглянуто у роботі Пржиялковского В.В. «Абстракции в проектировании БД» [80]. Структура даних мережевої моделі даних визначається в термінах елемент, аґреґат, запис, група, групове відношення, файл, база даних.

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

Подання зв'язків 1:1, 1:M, N:1 є окремим випадком зв'язку типу M:N і здійснюється аналогічно до розглянутого вище прикладу.

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

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

До недоліків мережевої моделі зазвичай відносять складність одержаної на її основі концептуальної схеми і велику складність розуміння відповідної схеми зовнішнім користувачем.

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

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

1. Групові відношення є відношеннями підлеглості. Група (запис) – власник відношення має підлеглі групи – члени відношень. Початкова група називається предком, підлегла – нащадком.

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

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

• у решту вершин входить тільки одне ребро (всі інші групи мають одного предка), а виходить довільна кількість ребер (групи мають довільну кількість нащадків);

• відсутні цикли.

3. Ієрархічна модель даних може подавати сукупність декількох дерев. У термінології ієрархічної моделі дерева, що описують структуру даних, називаються деревами опису даних, а самі структуровані дані (база даних) – деревами даних.

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

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

Як недоліки ієрархічної моделі можна назвати вищезгадані недоліки мережевої моделі. СКБД, що підтримує ієрархічну модель, достатньо широко використовувалися на обчислювальних системах IBM 360/370. Як приклади таких систем можна вказати IMS, ОКА і широко тиражоване в СРСР застосування ІНЕС. Прикладом ієрархічної СКБД для персональних ЕОМ є російська система НІКА (адаптація системи ІНЕС до IBM PC).

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

Враховуючи відзначені в попередніх підрозділах недоліки мережевих й ієрархічних моделей, можна сформулювати бажані вимоги до моделі даних:

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

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

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

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

Для формального опису таблиці використовується теоретико-множинне поняття відношення. Список назв стовпців таблиці (імен полів запису, відповідних атрибутам) називають схемою відношення і позначають R (A1, A2 …An) [71]. Сукупність схем відношень, що використовуються для подання концептуальної моделі, називається схемою реляційної бази даних, а поточні значення відповідних відношень – реляційною базою даних.

Відзначимо, що більшість СКБД для персональних ЕОМ підтримують саме реляційну модель даних. Як приклади таких найбільш поширених СКБД можна вказати всі dBase-подібні системи, Paradox, Access, FireBird, FoxPro, Oracle, MS SQL Server тощо. Детальніше реляційна модель даних буде розглянута далі.

Багатовимірна модель даних

Повернемося до поняття «сутність» концептуальної моделі. Сутність – це те, про що накопичується інформація в інформаційній системі. Часто виявляється, що інформація про певну сутність залежить ще від ряду параметрів. Розглянемо, наприклад, сутність Чисельність населення:

Чисельність населення

К-сть чоловіків

К-сть жінок

К-сть осіб обох статей

Значення атрибутів залежить від параметрів «рік», «адміністративний район». Якщо використовувати для опису відповідної концептуальної схеми реляційну модель, то необхідно вводити множину таблиць ЧИСЕЛЬНІСТЬ НАСЕЛЕННЯ по кожному року для кожного району. Так, при 60 адміністративних районах і необхідності аналізувати дані за 10 років кількість таблиць буде рівною 600. Дублюються аналогічні структури всіх таблиць, достатньо складне опрацювання даних, пов'язане з аналізом однотипних даних при зміні значення одного з параметрів тощо.

Найбільш відповідною моделлю даних для цього випадку є так звана багатовимірна модель, що використовується в технології OLAP (OnLine Analytical Processing – оперативне аналітичне опрацювання).

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

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

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

Об'єктно-орієнтована модель

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

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

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

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

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

5. Повідомлення: Взаємодія з об'єктами здійснюється шляхом пересилання повідомлень з можливістю отримання відповідей.

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

Висновки

1. Інформаційні системи відносяться до класу організаційних систем керування.

2. Задача розроблювачів програмних систем – створити в користувача розроблювальної системи ілюзію простоти.

3. Складні структури часто приймають форму ієрархій; корисні обидві ієрархії: і класів, і об'єктів.

4. Складні системи зазвичай створюються на основі стійких проміжних форм.

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

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

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

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

9. Є такі моделі даних – концептуальна, логічна, фізична.

10. У концептуальному моделюванні проектується схема понять прикладної області в їх взаємозв'язку.

11. Логічний рівень моделювання – це той, який реально використовує багато хто з теперішніх розробників завдяки доступності на ринку CASE-систем. Логічна модель будується за допомогою діаграм «сутність-зв’язок», атрибутів, категоризації. Розрізняють ієрархічну, мережну, реляційну, багатовимірну логічні моделі даних.

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

Контрольні питання

1. Визначення інформаційної системи.

2. Поняття складності системи.