10.5. Правила Кодда для olap-систем.

1. багатовимірне концептуальне представлення даних, 2. прозорість: і технологія OLAP архітектура системи і БД мають бути прозорими для користувача 3. доступність: OLAP-засоби повинні здійснювати доступ до потрібних даних , що зберігаються в різних неоднорідних джерелах 4. постійна продуктивність при підготовці звітів:користувачі не повинні зауважувати різких змін швидкості обробки запитів при зростанні обсягів інформації 5. архітектура «клієнт-сервер» 6. універсальність вимірів(еквівалентність по структурних і функціональних можливостях) 7. динамічне керування – OLAP повинна вміти адаптувати свою фізичну схему до конкретної аналітичної моделі. 8. багатокористувацька підтримка: повинна забезпечувати паралельну роботу групи користувачів з 1 чи кількома моделями корпоративних даних. 9. необмеженість перехресних операцій між вимірами: OLAP має вміти розпізнавати ієрархії вимірів і авоматично виконувати перехресні підсумкові обчислення всередині і серед вимірів. 10. підтримка інтуїтивного інтерфейсу маніпулювання даними

10.6. Загальна характеристика способів реалізації olap-систем.

загальна характеристика способів реалізації OLAP систем

Першим продуктом, що виконував OLAP-запити, був Express (компанія IRI). Проте, сам термін OLAP був запропонований, «батьком реляційних БД» Едгаром Коддом. А робота Кодда фінансувалася Arbor, компанією, що випустила свій власний OLAP-продукт Essbase (пізніше куплений Hyperion, яка в 2007 р. була поглинена компанією Oracle) роком раніше. Як результат, «OLAP» Кодда з'явився в їх описі Essbase.

Інші добре відомі OLAP-продукти включають Microsoft Analysis Services (що раніше називалися OLAP Services, частина SQL Server), DB2 OLAP Server від IBM (фактично, EssBase з доповненнями від IBM), продукти MicroStrategy і інших виробників.

З технічної точки зору, представлені на ринку продукти діляться на «фізичний OLAP» і «віртуальний».

У першому випадку наявна програма, що виконує попередній розрахунок агрегатів, які потім зберігаються в спеціальній багатовимірній БД, що забезпечує швидкий доступ. Приклади таких продуктів: Microsoft Analysis Services, Oracle OLAP Option, Oracle/Hyperion EssBase, Cognos PowerPlay.

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

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

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

Найбільше застосування OLAP знаходить в продуктах для бізнес-планування і сховищах даних.

10.7. Архітектура rolap-систем.

Основою є звичайні традиційні реляційні БД. Дані у сховищі представлені у вигляді моделі, що дістала назву «зірка» Модель складається з 2 типів таблиць: 1. фактів(центр зірки) – містить складовий ключ, з допомогою якого зв’язується з таблицями вимірів. Вміщує показники якого напрямеу діяльності компанії, а також ключі таблиць вимірів. 2. вимірів фактів – містять додаткові характеристики ключових полів .Таблиці вимірів виступають як батьківські таблиці, а таблиця фактів є підпорядкованою дочірною таб. Дані таблиць у моделі »зірка» можуть бути ненормалізовані. Якщо дані таблиць вимірів нормалізовані, то така модель наз. «сніжинка». Тобто в цій моделі може бути певна ієрархічна підпорядкованість між окремими таблицями вимірів. Таблиці, що приєднуються до таблиць вимірів, наз консольними, а таблиці, до яких вони приєднуються – нащадками ROLAP моделі дозволяють зберегти великі обсяги даних, але вони не досить ефективні при виконанні аналітичних операцій.