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

Повернемося до поняття "сутність" концептуальної моделі.

Сутність – це те, про що накопичується інформація в інформаційній системі. Часто виявляється, що інформація про певну сутність залежить ще від ряду параметрів. Розглянемо, наприклад, сутність УСПІШНІСТЬ СТУДЕНТІВ з наступними атрибутами: кількість двійок, кількість трійок, кількість четвірок, кількість п'ятірок.

Значення атрибутів залежить від параметрів "курс", "навчальний рік". Якщо використовувати для опису відповідної концептуальної схеми реляційну модель, то необхідно вводити множину таблиць УСПІШНІСТЬ СТУДЕНТІВ по кожному року для кожного курсу. Так, при 5 курсах і необхідності аналізувати дані за 10 років кількість таблиць буде рівною п'ятдесят. Дублюються аналогічні структури всіх таблиць, досить складна обробка даних, пов'язана з аналізом однотипних даних при зміні значення одного з параметрів і т. д.

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

Багатовимірні структури представляються як гіперкуби даних. Кожна грань куба є розмірністю. Основними поняттями, використовуваними в багатовимірних моделях даних, є "вимір" (dimension) і "комірка" (cell).

Вимір – впорядкований набір значень, що приймаються конкретним параметром, відповідний одній з граней гіперкуба. Для нашого прикладу можна вказати як виміри: навчальний рік – 2006-2007, 2007-2008, 2008-2009; курси – 1,2,3 і так далі

Комірка або показник – це поле, відповідне атрибуту сутності, значення якого однозначно визначається фіксованим набором значень параметрів (значеннями "вимірами", наприклад, 2008-2009 навчальний рік, перший курс).

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

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

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

Масове використання СУБД, що підтримують багатовимірну модель даних, лише починається. В ролі найбільш відомих СУБД такого типу можна вказати Oracle Express Server.

7. 6.3. Засоби автоматизованого проектування концептуальної моделі

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

Причина застосування цих засобів полягає у використанні в переважній більшості реальних розробок баз даних спіральної моделі життєвого циклу програмного забезпечення, що передбачає послідовне створення декількох версій програмного забезпечення. Кожна наступна версія включає попередню (можливо, не повністю) і є відповіддю на зауваження користувача, отримані в результаті тестування попередньої версії. При створенні баз даних перша модель програмного забезпечення, на жаль, дуже рідко є вдалою. Найчастіше замовник відкидає першу версію, оскільки вона недостатньо повно відповідає його вимогам. Причина такої ситуації полягає в тому, що замовник не може відразу, до створення початкової версії програми, чітко і повно сформулювати свої вимоги. Зазвичай після отримання першого варіанту програмного забезпечення замовник висуває додаткові вимоги, які не можна реалізувати в рамках створеної бази даних. Це змушує розробників вносити зміни в структуру бази даних, а також, відповідно, в інтерфейс користувача для доступу до бази даних. Таких ітерацій може бути декілька до моменту отримання рішення, адекватного запитам замовника. Але навіть після отримання задовільного рішення процес розробки бази даних не завершується. Життя не стоїть на місці, і запити замовника міняються з часом. Частину цих змін можна реалізувати без зміни структури бази даних, змінюючи лише інтерфейс користувача, інші ж вимагають зміни і інтерфейсу, і структури бази даних. Варто відмітити, що подібні зміни є дуже хворобливими – робота по їх внесенню може виявитися трудомісткою і, що найнеприємніше, зажадати заміни великої кількості відлагодженого програмного коду. Іншими словами, замінений код був написаний даремно, насправді його не потрібно було писати.

Таким чином, створення працездатної бази даних можна умовно розділити на три етапи:

• проектування бази даних, в процесі якого створюються робочі прототипи;

• кодування – створення структур баз даних і закінченого інтерфейсу користувача і

• супровід готової бази даних.

Основна ідея застосування засобів автоматизованого проектування баз даних полягає в тому, що процес ручного кодування починається лише після закінчення процесу проектування. На стадії проектування схема бази даних і інтерфейс користувача для доступу до бази даних створюються автоматично, виходячи з опису концептуальної моделі, за допомогою так званих CASE-засобів (Computer Aided Software/System Engineering). Звичайно, створений таким чином інтерфейс не є закінченим програмним продуктом, проте він дозволяє замовникові оцінити можливості кінцевого продукту і внести свої корективи. Лише після схвалення замовником робочого прототипу розробники приступають до ручного кодування – створення закінченого додатку.

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

На практиці частіше за все CASE-засоби використовуються для створення схеми бази даних у вигляді ER-діаграм і генерації структур баз даних для конкретної СУБД. Після отримання від замовника змін розробники вносять відповідні виправлення до діаграми "сутність – зв'язок" і заново генерують структури баз даних. Засоби автоматичної генерації інтерфейсів використовуються рідше.

В наш час практично кожен виробник СУБД пропонує власний програмний продукт автоматизованого проектування. Це Oracle Designer (Oracle), Power Desinger (Sybase) та інші. Демонстраційні версії даних програмних продуктів можна завантажити з відповідних сайтів (www.oracle.com, www.sybase.com).

Крім того, на ринку представлені рішення третіх фірм, що не виробляють СУБД. Одними з найпоширеніших є програмні продукти фірми AllFusion – AllFusion ERwin Data Modeler і AllFusion Process Modeler (раніше – BPwin) та інші. На російському ринку дані програми пропонує фірма Interface Ltd. (www.interface.ru). Створення діаграми "сутність – зв'язок" здійснюється за допомогою AllFusion ERwin Data Modeler, подальше моделювання, включаючи генерацію програмного коду створення бази даних виробляється за допомогою програми AllFusion Process Modeler.

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

На сайті Interface Ltd. доступна для завантаження демонстраційна версія AllFusion ERwin Data Modeler, яка є повнофункціональною версією, обмеженою за часом.

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

Питання даної лекції розглядаються в [1]÷[19].