Для поиска темы - пользуйтесь СИСТЕМОЙ ПОИСКА


Стоимость дипломной работы


Home Материалы для работы Вибір моделі даних Сховища

Вибір моделі даних Сховища
загрузка...
Рейтинг пользователей: / 0
ХудшийЛучший 

Вибір моделі даних Сховища


В найпростішому варіанті для Сховищ Даних використовується та модель даних, яка лежить в основі системи транзакції. Якщо, як це часто буває, система транзакції функціонує на реляційній СУБД (Oracle, InterBase, Informix, Sybase і т. п.), найскладнішою задачею стає виконання запитів ad-hoc, оскільки неможливо наперед оптимізувати структуру БД так, щоб всі запити працювали ефективно.
Проте практика прийняття рішень показала, що існує залежність між частотою запитів і ступенем агрегованості даних, з якими запити оперують, а саме чим більш агрегованими є дані, тим частіше запит виконується. Іншими словами, коло користувачів, що працюють з узагальненими даними, ширше, ніж те, для якого потрібні детальні дані. Це спостереження лягло в основу підходу до пошуку і вибірки даних, званого Оперативною Аналітичною Обробкою (On-line Analytical Processing, OLAP).
Olap-системи побудовані на двох базових принципах:
- всі дані, необхідні для ухвалення рішень, заздалегідь агреговані на всіх відповідних рівнях і організовані так, щоб забезпечити максимально швидкий доступ до них;
- мова маніпулювання даними заснована на використовуванні бізнес-понять.
В основі OLAP лежить поняття гіперкубу, або багатовимірного кубу даних, в осередках якого зберігаються аналізовані (числові) дані, наприклад об'єми продажу. Є вимірювання сукупності значень інших даних, скажемо назви товарів і назви місяців року. В найпростішому випадку двовимірного кубу (квадрату) ми одержуємо таблицю, що показує значення рівнів продажу по товарах і місяцях. Подальше ускладнення моделі даних може йти по декількох напрямах:
- збільшення числа вимірювань - дані про продаж і не тільки по місяцях і товарах, але і по регіонах. В цьому випадку куб стає тривимірним;
- ускладнення вмісту осередку - наприклад нас може цікавити не тільки рівень продажу, але і, скажімо, чистий прибуток або залишок на складі. В цьому випадку в осередку буде декілька значень;
- введення ієрархії в межах одного вимірювання - загальне поняття «Час» природним чином пов'язаний з ієрархією значень: рік складається з кварталів, квартал з місяців і т.д.
Поки йдеться не про фізичну структуру зберігання, а лише про логічну модель даних. Іншими словами, визначається лише призначений для користувача інтерфейс моделі даних. В рамках цього інтерфейсу вводяться наступні базові операції:
-  поворот;
- проекція. При проекції значення в осередках, що лежать на осі проекції, підсумовуються по деякому закону;
- розкриття (drill-down). Одне із значень вимірювання замінюється сукупністю значень з наступного рівня ієрархії вимірювання; відповідно замінюються значення в осередках гіперкуба;
- згортка (roll-up/drill-up). Операція, зворотна розкриттю;
- перетин (slice-and-dice).
Залежно від відповіді на питання, чи існує гіперкуб як окрема фізична структура або лише як віртуальна модель даних, розрізняють системи MOLAP (Multidimensional OLAP) і ROLAP (Relational OLAP). По-перше гіперкуб реалізується як окрема база даних спеціальної нереляційної структури, що забезпечує максимально ефективний по швидкості доступ до даних, але вимагаюча додаткового ресурсу пам'яті. Molap-системи вельми чутливі до об'ємів зберігаючих даних. Тому дані зі сховища спочатку розміщаються в спеціальній багатовимірній базі (Multidimensional Data Base, MDB), а потім ефективно обробляються Olap-сервером.
Однією з перших виробників таких систем стала компанія Arbor Software, що випустила продукт Essbase. Компанія Oracle пропонує систему Oracle Express, інтегровану з універсальним Oracle Server. Відомі і інші виробники Molap-систем, наприклад SAS Institute. Проте, на відміну від Essbase, їх продукти часто інтегровані в додатки, створені для конкретних вертикальних або горизонтальних ринків, і поставляються лише у складі цих додатків.
Для систем ROLAP гіперкуб - це лише призначений для користувача інтерфейс, який емулюється на звичайній реляційній СУБД. В цій структурі можна зберігати дуже великі об'єми даних, проте її недолік полягає в низькій і неоднаковій ефективності OLAP - операцій. Досвід експлуатації Rolap-продуктів показав, що вони більше підходять на роль інтелектуальних генераторів звітів, чим дійсно оперативних засобів аналізу. Вони застосовуються в таких областях, як роздрібна торгівля, телекомунікації, фінанси, де кількість даних велика, а високої ефективності запитів не вимагається. Прикладами промислових Rolap-систем служать MetaCube фірми Informix і Discoverer 3.0 фірми Oracle. На практиці іноді реалізується комбінація цих підходів.
Деякі постачальники програмних продуктів (Sybase - Sybase IQ, Teradata) поставляють складніші рішення, засновані на спеціальних методах зберігання і індексації даних і зв'язків між даними.
При визначенні програмно-технологічної архітектури Сховища слід мати на увазі, що система прийняття рішення, на які б візуальні засоби уявлення вона не спиралася, повинна надати користувачу можливість деталізації інформації. Керівник підприємства, отримавши інтегроване представлення даних чи висновки, зроблені на його основі, може зажадати більш детальні відомості, що уточнюють джерело даних або причини висновків. З погляду проектувальника СППР, це означає, що необхідно забезпечити взаємодію СППР не тільки з Сховищем Даних, але і в деяких випадках з системою транзакції.


 
загрузка...

Добавить комментарий


Защитный код
Обновить