Навчальне видання Корпоративні інформаційні системи, 3.2. Багатовимірна модель даних та багатовимірні СУБД, ХДЕУ, Харківський державний економічний університет
« Назад
3.2. БАГАТОВИМІРНА МОДЕЛЬ ДАНИХ ТА БАГАТОВИМІРНІ СУБД
3.2.1. Особливості багатовимірного представлення даних
Багатовимірна організація даних передбачає багатовимір: представлення структур даних і підтримку багатовимірЯ в мовах маніпулювання даними та не означає багатовимірні1 візуалізації даних. Дані представляються кінцевому користувачеві у вигляді чотирьох- або п'ятимірних гіперкубів, а засобами звичй* комфортної двовимірної бізнес-графіки [23; 40]. Навіть при невеликих обсягах даних звіт, наданий у виглядів вимірної таблиці (моделі автомобіля по осі Y та час по осі Х набагато наочніше й інформативнішим, ніж з реляційною форм організації (рис. З.1). РЕЛЯЦІЙНА МОДЕЛЬ
Якщо кількість моделей автомобілів дорівнює ЗО, кількість місяців - 12, при реляційному уявленні вийде звіт у 360 (ЗО х 12) рядків, який займає не менше 5-6 сторінок. У разі ж багатовимірного (у цьому випадку двовимірного) уявлення вийде досить компактна таблиця розміром ЗО х 12, яка цілком вміститься на одній сторінці і яку навіть при такому обсязі даних можна реально оцінювати й аналізувати. Основними поняттями, якими оперує користувач та проекту-альник у багатовимірній моделі даних, є: • вимір (Dimension); • чарунка (Cell), або показник (Measure). Вимір - це безліч однотипних даних, які утворюють одну з граней куба (аналог домену в реляційній моделі). Наприклад, дні, місяці, квартали, роки - це часові вимірювання, які найчастіше використовуються в аналізі. Прикладами географічних вимірювані міста, райони, регіони, країни і т. ін. Показник - це поле (зазвичай цифрове), значення якого однозначно визначається фіксованим набором вимірювань. У багатовимірній СУБД Oracle Express Server показник може бути визначений, як: • перемінна (Variable) - значення таких показників один раз вводяться з будь-якого зовнішнього джерела або формуються програмно, а потім у явному вигляді зберігаються в багатовимірній базі даних • формула (Formula) - значення таких показників обчислюються за деякою заздалегідь специфікованою формулою. Тобто для показника, який має тип «формула», у БД зберігається не його звз' чення, а формула, за якою це значення може бути обчислене у прикладі на рис. 3.1 кожне значення поля «Обсяг продажів» означно визначається комбінацією стовпців: «модель автомобіля та місяць продажу». Проте в реальній ситуації для однозначної ідентифікації значення показника потрібна більша кількість вимірів, наприклад:
У термінах багатовимірної моделі мова буде йти вже не про двовимірну таблицю, а про тримірний гіперкуб: • перший вимір - модель автомобіля; • другий вимір - менеджер, який продав автомобіль; • третій вимір - час (рік). На перетині граней гіперкуба, в чарунках, знаходяться значення показника «Обсяг продажів». 3.2.2. Операції маніпулювання вимірами
Формування «зрізу» (Slice) - це підмножина гіперкуба, яка буд. здобута внаслідок фіксації значення одного або більшої кілько» вимірів. Наприклад, обмеживши значення виміру «Модель автомобіля» — BMW, отримаємо підмножину гіперкуба (у цьому випадку - двомірну таблицю), яка містить інформацію про історію пш. дажів цієї моделі різними менеджерами в різні роки. Операція «обертання» (Rotate) - це зміна порядку предсталі лення (візуалізаціі) вимірів. Звичайно застосовується при двовиц! ірному представленні даних. Ця операція забезпечує можливі візуалізації даних у формі, найбільш комфортній для їх сприйняття. Наприклад, аналітик має можливість вивести звіт, в якому ' делі автомобілів перераховані по осі X, а менеджери по осі Y, і міняти місцями координати (виконавши обертання на 90 граду» Використання ієрархічних відносин (Hierarchical Relations!; Безліч відносин може мати ієрархічну структуру, яка відо жує залежність вимірювань один від одного. Часто зручніше не оголошувати нові виміри і потім встановлювати між ними множину відносин, а використовувати механі ієрархічних відносин. У цьому випадку всі потенційно можливі зш чення з різних вимірювань об'єднуються в одну множину. Операція агрегації (Drill Up) - це операція підйому за рівнях; консолідації даних у процесі аналізу або переходу від деталізоване даних до агрегованих. З точки зору користувача, «Підрозділ», «Регіон», «Фірма», «Країна» є точно такими ж вимірюваннями, які «Менеджер». Але кожний з них відповідає новому, більш високому рівні агрегації значень показника «Обсяг продажів». Наприклад, подивіч шись, наскільки успішно в 2002 р. Сидоров продавав моделі ВМWOpel, керуючий може захотіти дізнатися, як виглядає співвідношу ня продажу цих моделей на рівні підрозділу, де Сидоров потім отримати аналогічну довідку по регіону або фірмі. Операція деталізації (Drill Down). Це операція спуску за рівнями консолідації даних або переходу від агрегованих до деталі. Наприклад, почавши аналіз на рівні регіону, користувач має можливість отримати більш точну інформацію про роботу конкретного підрозділу або менеджера. До основних етапів проектування багатовимірної БД відносяться: • визначення запитів потенційних користувачів аналітичної системи; • вибір вимірювань, показників, відносин; • вибір рівня агрегації вимірів; • розробка процедур представлення та аналізу даних.
3.2.3. Гіперкубічні та полікубічні моделі данихУ різних БСУБД використовуються два основні варіанти організації даних _ гіперкубічна та полікубічна моделі. Відмінність між ними полягає в тому, що системи, які підтримують полікубічну модель (прикладом є Oracle Express Server), припускають наявність у багатовимірній БД декількох гіперкубів з різною розмірністю та різними вимірами. Наприклад, значення показника «Робочий час менеджера» не залежить від виміру «Модель автомобіля» та однозначно визначається двома вимірами: «Час» та «Менеджер». У полікубічній моделі в цьому випадку можуть бути присутні два різні гіперкуби:
У разі гіперкубічної моделі передбачається, що всі показники повинні визначатися одним і тим же набором вимірів. Тобто тільки через те, що «Обсяг продажів» визначається трьома вимінами, при описі показника «Робочий час менеджера» доведеться перебудувати модель і використати ще один вимір - «Модель автомобіля». 3.3. РЕЛЯЦІЙНИЙ OLAP (ROLAP)Забезпечення для реляційних системи продуктивності, наближеної до продуктивності MOLAP-систем потребує ретельної розробки схеми БД. Використання схеми «зірка» («star та») У реляційних системах забезпечує продуктивність, цілком порівнянну з продуктивністю систем на основі багатовимірних баз даних [23]. У цій схемі використовуються два види таблиць - таблиця Пактів (фактологічна таблиця) та кілька довідкових таблиць (таб-вимірювань). У таблиці фактів звичайно містяться дані, які найбільш інтенсивно використовуються для аналізу. Якщо провести аналогці багатовимірною моделлю, то запис фактологічної таблиці відповідає чарунці гіперкуба. У довідковій таблиці перераховані можливі значення одного з вимірів гіперкуба. Кожний вимір описуєть своєю власною довідковою таблицею. Фактологічна таблиця інде,І сується за складним ключем, який компонується з індивідуальну ключів довідкових таблиць. У реальних системах кількість рядків у фактологічній таблиці може складати десятки і сотні мільйони. Кількість довідкових таблиць звичайно не перевищує двох десяті Для збільшення продуктивності аналізу у фактологічній табі можуть зберігатися не тільки деталізовані, а й заздалегідь обчислені агреговані дані. Якщо БД включає велику кількість вимірювань, викорис вується схема «сніжинка» («snowflake»). У цій схемі атрибути відкових таблиць деталізують у додаткових довідкових таблицях. Для скорочення часу відгуку аналітичної системи можна використати деякі спеціальні засоби. До складу могутніх реляційних СУБ; звичайно входять оптимізатори запитів. При створенні сховищ да них на основі реляційних СУБД їх наявність набуває особливої ваг; Оптимізатори аналізують запит та визначають кращу, з позиції де якого критерію, послідовність операцій звертання до БД для його виконання. Наприклад, може мінімізуватися кількість фізичних зве; нень до дисків при виконанні запиту. Оптимізатори запитів використовують складні алгоритми статистичної обробки, які оперукяі Використання інструментів ROLAP у системах оперативне аналітичної обробки має певні переваги: 1. Вони дозволяють проводити аналіз безпосередньо над сховищем (оскільки в переважній більшості випадків корпоративні сховища даних реалізуються засобами реляційних СУБД). 2. У разі змінної розмірності задачі, коли зміни в структуру вимЧ3] доводиться вносити досить часто, ROL АР системи з динамічним прЧ ставленням розмірності є оптимальним рішенням, оскільки в них*р модифікації не вимагають фізичної реорганізації БД. ^^ 3. Системи ROLAP можуть функціонувати на набагато менш Головне обчислювальне навантаження в них лягає на сервер, де виконуються складні аналітичні SQL-запити, які формуються системою. 4. Реляційні СУБД забезпечують значно більш високий рівень захисту даних та розмежування прав доступу. 5. Реляційні СУБД реалізують реальний досвід роботи з дуже кими базами даних та розвиненими засобами адміністрування. Недоліками ROLAP-систем є, по-перше, обмежені можливості точки зору розрахунку значень функціонального типу; по-друге, менша продуктивність порівняно з MOLAP-системами. Це пов'язано з тім, що побудова схеми «зірка» вимагає створ, ня проміжної таблиці, яка є декартовим добутком довідкових чч, лиць, які використовуються в запиті. Потім виконується послідовний перегляд двох таблиць (фактологічної та проміжної), у проції якого відсіваються усі рядки, які не відповідають умовам виб0і Такий спосіб оптимізації дає ефект тільки тоді, коли проміжна ь лиця вміщується в ОЗП. Алі це не завжди так. Наприклад, запит посилається на 10 довідкових таблиць, у кожній з яких щ 10 рядків довжиною в 40 символів, унаслідок виконання операі декартового добутку вийде проміжна таблиця в 10 млрд рядків обсяг ОЗП для її розміщення становитиме 400 гігабайт. Як відзначив Е. Кодд, реляційний підхід ніколи не призначавсяд розв'язання задач, які вимагають синтезу, аналізу та консолідації} них. Спочатку передбачається, що такого роду функції повинні бу реалізовані за допомогою зовнішніх по відношенню до реляційних СУ] інструментальних засобів. Як уже відзначалося, реляційний і багаї вимірний підходи взаємно доповнюють один одного. Сьогодні БСУБД усе частіше і частіше використовують не тіш як самостійний програмний продукт, але й як аналітичні засс переднього плану по відношенню до систем сховищ даних аботр диційних оперативних систем, що реалізуються засобами ре: ційних СУБД (рис. 3.6). Взагалі 1С з аналітичними можливостями включає три ріі використання даних: • перший рівень - це загальнокорпоративна БД на основі ляційної СУБД із нормалізованою чи слабо нормалізованою о мою (деталізована БД); • другий рівень - це БД агрегованих даних рівня підрозд реалізована на основі БСУБД; • третій рівень - персональна БД агрегованих даних на р чому місці кінцевого користувача, де безпосередньо встановлю аналітичний інструментарій. 3.4. ЧАСОВІ БАЗИ ДАНИХ ТА БАГАТОВИМІРНИЙ АНАЛІЗ
Часові бази даних є самостійним класом багатовимірних моделей [39]. Це розширення реляційної моделі - Тетрод Relational Model (TRM), де відношення задані кортежами т, атрибутами, третім виміром є час. її різновидом є модель історц,, них даних - Historical Data Model (HDM). Часові СУБД переносять властивість часу у власну серед» СУБД, автоматично зберігаючи при цьому безліч версій об'єкті, даних, які залежать від часу. Крім того, ці СУБД мають мовні засобі, для вибірки даних по запитах, асоційованих із часом (у дослідниць. ких проектах такі можливості зазвичай є розширенням мови SQL> TSQL, TEMPSQL, HSQL). Незважаючи на необхідність зберігав безліч версій більшості об'єктів даних для оперативного достут до них у режимі on-line (або, принаймні, для досить швидкого дД тупу), міра використання такої технології має визначатися потребами бізнесу організації. Часові бази даних передбачається використовувати разом із сховищами даних, в яких асоційовані з головною агреговані миттєві знімки використовуються для представлен ня даних організації в історичній перспективі. Вважається, що щ сові бази будуть надавати більше можливості для збирання й обробки інформації, асоційованої з часом, ніж це дозволяють існуюч технології.
3.5. ПРОСТОРОВІ ДАНІ ІГЕОІНФОРМАЦІЙНІ СИСТЕМИ
У загальному випадку просторові дані є сутностями з просторовою прив'язкою. Просторові дані використовуються в рамках географічних та навігаційних інформаційних систем , мобільних 1С) [39]. Навігаційні або мобільні 1С - різновиди інформаційних систем (ПС), в яких параметри руху об'єктів ів'язані до географічної карти. БД мобільних систем називають КД які кочують», тому що вони розташовані в пам'яті портативного комп'ютера, підключеного по мережі до БД головного офісу компанії. Керування просторовою інформацією має справу з крапками, лініями та іншими геометричними об'єктами. До властивостей геометричних показників, які повинні зберігатися в просторовій базі даних, відносять:
Використовуючи географічні об'єкти, які зберігаються в БД ГІС, можна виконувати запити, характер яких демонструють такі приклади. 1.Де саме розташовані джерела ресурсів «YYY» у районі «XXX» та які їх запаси? 2.Який стан транспортного сполучення між джерелом сировини «YYY» та місцями його використання «NNN» та «МММ»? 3.Якою є міра забруднення навколишнього середовища в районі «XXX»? 4.Якими є обсяги виробництва і споживання товарів першої Не"бхідності в районі «XXX»? 5.Які існують джерела поповнення запасів товарів першої негідності в районі «XXX»? 6. Яким є потенціал робочої сили в районі «XXX»? 7. Знайти найкоротший шлях між пунктом «XXX» та пунктом ХХХ». 8. Знайти найдешевший шлях між пунктом «XXX» та пунктом УУУ. 9. Чи є будь-яке шосе, що будується в цей час між пунктоЗ 10. Чи є які-небудь тунелі між пунктом «XXX» та пункто». «YYY», придатні для перевезення небезпечних вантажів? 11. Який найкращий маршрут у ранкові/вечірні години пік щ. переїзду з пункту «XXX» у ділову частину міста? 12. Яка густина населення в певному географічному місці? Географічні інформаційні системи та навігаційні систец» Місце розташування крапки (крапкового об'єкта), наприклад свердловини, описується парою координат (X, Y). Векторна модель зручна для опису дискретних об'єктів і не підходить для опису їх безперервних властивостей. растрова модель оптимальна для роботи з безперервними властивостями. Растрове зображення являє собою набір значень для окремих елементарних складових (осередків), наприклад, відскановане фото або рисунок. Обидві моделі мають свої переваги і недоліки. Сучасні ГІС можуть працювати як із векторними, так і з растровими моделями даних. Продовжується дослідницька робота, пов'язана з обробкою запитів для користувачів мобільних інформаційних систем. Геоінформаційні рішення вдало вписуються в інструментарій маркетингових досліджень [34]. Масштабні маркетингові дослідження неможливі без маркетингової інформаційної системи (МІС), яка дозволяє адміністративному корпусу корпорації оперативно реагувати на зміни ринкової кон'юнктури, перебудовувати власну маркетингову політику за рахунок підвищення обсягів, точності, швидкості, надійності, достовірності передачі, накопичення, обробки інформації. Проблеми збору, систематизації, обробки маркетингової інформації для великих підприємств, особливо для корпорацій, - це проблеми переходу від хаосу, викликаного, з одного боку, перехідним періодом у розвитку економіки, з іншого - зростаючим потоком різноманітної інформації (у тому числі такої, яка поступає по каналах FIDONET, INTERNET, INTRANET, EXTRANET та з інших джерел) до організації і ясності. Збирання інформації про діяльність конкурентів, необхідної для функціонування МІС, є самостійною, надзвичайно трудомісткою задачею. Однак керівництво великих фірм не зупиняється перед витратами для організації такої діяльності. Повнофункціональна МІС має відповідати вимогам корпоративної динамічної СППР. Це зумовлене такими чинниками. По-перше, за колом задач, які вирішуються, та способами їх розв'язання відноситься до класу аналітичних систем, які дозволяють фахівцям маркетингу не тільки систематизувати первинну та вторинну маркетингову інформацію, а й виконувати аналіз даних з різних показників та в різних аспектах (часових, географічних, соціологічних, приймати рішення в умовах невизначеності. По-друге, концепт глобалізації бізнесу та створення віртуальних корпорацій вимагають розподілу компонентів інформаційної системи, спираючись принципу на технології корпоративних інформаційних систем. Розробка інтерфейсу, що призначений для користувача маркетингової системи, у стилі ГІС призначена не тільки для наочної відображення просторово розподілених даних - це елемент підвищення оперативності аналізу та прийняття управлінських рішень оскільки орієнтує користувача системи в географічному і вартісному аспектах аналізу маркетингової інформації, дозволяє отримати прогноз реалізації власної продукції, розробити стратегічну тактику щодо позиціювання продукції корпорації на ринку. Найбільш відомою на сьогоднішній день ГІС є Arc View GIS- розгалужень настільна система для проведення стандартних аналога них операцій та простого перегляду отриманих даних. Крім функціональності, одним з головних достоїнств ArcView GIS є забезпечена простоти роботи з пакетом навіть для недосвідченого користувача.
3.6. ПАРАЛЕЛЬНІ БАЗИ ДАНИХ - АЛЬТЕРНАТИВА БАГАТОВИМІРНОГО ПРЕДСТАВЛЕННЯ ДАНИХ
Як перспективну альтернативу БСУБ Д та ROLAP баз для реалізації on-line-запитів до великих БД у аналітичних системах застосовують паралельні БД- У цей час існують промислові реалізації паралельних реляційних баз даних Teradata NCR, Tandem, ORACLE-nCUBE [23]. Апаратною платформою цих СУБД є кластери ЕОМ та МРР обчислювальні системи з масовим паралелізмом, які включають паралельні системи з серійних мікропроцесорів, мікросхем пам'яті, дешевих серійних дисків. Для кластерів ЕОМ характерно таке: • побудова систем на основі стандартних програмно-апарат-парадигм Open Software Foundation Distributed Computing r" ironment (OSF DCE) та Open Network Computing (ONC), які підтримують загальні імена та можливості доступу;
Перший чинник, який визначив появлення паралельних систем _ сумарний обсяг ОЗП всіх ЕОМ системи може досягати декількох терабайт при відносно низькій ціні. Розвиток комунікаційних технологій з пропускною спроможністю на рівні 1 Гбайту в секунду дозволяє порівнювати по швидкодії розподілену пам'ять з пам'яттю окремого комп'ютера. Другий чинник, який визначив появлення паралельних систем,- це розвиток і застосування 64-розрядних операційних систем, що дозволило подолати обмеження на обсяг даних, які розміщуються в ОЗП. Третім чинником (один із головних) вдалої реалізації СУБД на паралельних системах є використання реляційної моделі даних, яка допускає паралелізм обробки кортежів та атрибутів відношень. Як розподілена, так і паралельна БД - це сукупність файлів БД, поділених в комп'ютерній мережі, здатних виступати як інтегроване ціле, прозоре для користувачів. При цьому дані розподіляють по ЕОМ за допомогою фрагментації та тиражування. В СУБД паралельних БД виділяють такі види паралелізму: • міжзапитиий ~ при якому паралельно виконуються запити, різних трансакцій; • внутризапитний - при якому паралельно виконуються до кілька операцій, які відносяться до одного запиту; • внутріопераційний ~ при якому виконуються паралельно частини однієї операції. Паралельна обробка взагалі подібна до розподіленої обробки Вздовж виконання запиту використовується інформація про розподіл даних. Розподілені відношення реконструюються шляхом звертання операцій, які були використані при розподілі даних. При цьому до операцій реляційної алгебри додаються оператори прийому та пересилки повідомлень. За наявності безлічі спільних рис між розподіленими та паралельними БД існує певна принципова відмінність: у розподіленій БД застосовуються два перших види паралелізму, у паралельній - всі три Коректність сумісного виконання паралельної роботи забезпечується численними інструментальними засобами - моделями т< програмними засобами виконання трансакцій та блокування. Оптимізація запитів пов'язана з пошуком варіанта, який вимагає найменшого часу виконання всіх операцій з даними. Особливо важливо оптимізувати порядок виконання з'єднань. Переваги паралельних систем баз даних: а) утилізація дешевих процесорів, мікросхем пам'яті та дискових пристроїв; б) використання переваг відомої реляційної моделі; в) можливість організації зберігання баз даних великих обсяги (Very Large Data Base (VLDB)); г) можливість організації оперативної аналітичної обробки даних.
3.7. ПРОГРАМНЕ ЗАБЕЗПЕЧЕННЯ ПРОМІЖНОГО ШАР^ ТА ЄДИНИЙ СИСТЕМНИЙ ОБРАЗ
Стандартизовані інтерфейси «клієнт-сервер» прийнято відновити до категорії програмного забезпечення проміжного (Middleware), яке визначають як «деякий набір або функцій, які забезпечують взаємодію двох різнорідних Програмні засоби цієї категорії придатні для комп’ютерних сервісів практично будь-якого виду, включаючи керування базами даних та інформацією [23,39]. По них відносять комерційні або самостійно розроблені програмні продукти, засновані на ШАРІ (Integrated DataBase Applicationratnrn Interface) - стандарті інтегрованих програмних засобів зв’язку ODBC (Open DataBase Connectivity) - стандарті зв'язку відкриті БД; RDA (Remote Data Access) - стандарті доступу до віддалених DRDA (Distributed Relational DataBase Architecture) - стандарті архітектури розподілених реляційних БД та інших стандартах, які надають інтерфейсі можливості для клієнта і сервера, необхідні для відділення інтерфейсів від механізмів керування даними. Системне програмне забезпечення проміжного шару є інструментом підтримки єдиного системного образу ECO (Single System. Image - SSI) системи підтримки даних. Воно не входить до складу операційної системи, оскільки повинно ефективно підтримувати особливості прикладної системи. Це ПО підтримує образ системи як сукупності одного або декількох логічних дисків та інших пристроїв зберігання даних (відбиває відмови компонент системи, управляє заміною таких компонент, що відмовили, встановлює альтернативні шляхи передачі даних, генерує необхідну кількість серверних додатків для клієнтських запитів, які змінюються, та ін.). Традиційним механізмом інтеграції баз даних за допомогою middleware є шлюзи (рис. 3.8), які забезпечують різні рівні інтероперабельності - від простих вибірок даних до керованих додатком засобів читання запису. Застосування програмного забезпечення проміжного шару було спорадичним, цілі його варіювалися від спроб надати деякий рівень абстракції прямого керування доступом до шлюзу з боку додатків. У період переходу до архітектури «клієнт-сервер» з'явився ще один до успадкованих систем. Він полягає у використанні брокерів об’єктних запитів ORB (Object Request Broker). При цьому нові необ'єктні клієнтські або серверні компоненти додатку вміщуються в об'єктно-орієнтовані оболонки (Wrapper). Це дозволяє клієнтам та серверам виконувати взаємодію за допомогою обєктно-орієнтованих методів. На рис. 3.9 показано, як функціонує середовище ORB. Концентрація розподілу об'єктів була розповсюджена не тільки на середовище обєктно-орієнтованої СУБД (ООСУБД), але й на інші середовища інформаційних систем завдяки стандарту загальної архітектури брокера об'єктних запитів - CORBA. Реалізація єдиного системного образу є однією з найважливіших характеристик паралельних систем БД. Міра реалізації ЕСО відображує інтегрованість ресурсів системи. Логічна структура паралельної системи закладається в СУБД. Частіше за усі використовуються і моделі. В одній із них пам'ять має дворівневу архітектуру та включає ОЗП і дискову зовнішню пам'ять. В іншій моделі пам'ять - однорівнева і тільки оперативна. Погоджувальний рівень програмного забезпечення middleware, який формує та підтримує образ системи обробки даних, використовується як проміжний шар між апаратно-програмними засобами та програмними засобами СУБД, яка побудована з орієнтацією на деяку паралельну логічну структуру обчислювальної системи. Звичайно вимоги до засобів реалізації ЕСО в паралельних базах даних формулюються як повна прозорість керування ресурсами, масштабованість, продуктивність, висока готовність. Прозорість керування передбачає такі можливості: • прозорість реєстрації користувача на будь-якому ПК; • єдиний адресний простір, який забезпечує підтримку виконання програм на базі моделі загальної пам'яті; • єдине керування розподілом завдань, включаючи паралельні завдання. Масштабованість передбачає, що при збільшенні ресурсів час Висока готовність забезпечується перерозподілом завдань користувача за придатними до роботи ресурсами системи. Висока готовність розподіленої зовнішньої пам'яті досягаєте. застосуванням масивів дисків, що резервуються RAID (redundq arrays of inexpensive disks), кодів з виявленням та корекцією now лок у пам'яті та трактах передачі даних, а також створенням с» темних контрольних точок для поновлення обчислень після виявлення збою або відмови. У кластерах ЕОМ висока готовність і реалізуються програмним забезпеченням middleware, яка стає за підтримкою працездатності, автоматичної реконфігурації її відмовах, перерозподілом додатків між ОМ кластеру. Ще один підхід до реалізації middlevjare в корпоративних інформаційних системах - використання медіаторів. Медіатор – це програмний модуль, призначений для спрощення, абстрагування, спрощення, злиття та пояснення даних, якими обмінюються додатки бази даних у деякому середовищі [39]. Ідея медіаторів спирається на такі поняття, як штучний інтелект і бази знань, а також баз даних та керування інформацією. Це ~ інтегрувальний шар інструментів обробки розподілених запитів до різнорідних БД; виконання трансакцій, підтримки сервісів ВД, сервісів словників Е У системах з інтеграцією різних БД або мультибазами даних медіатори можуть функціонувати в рамках багаторівневої архітектури. Фактично медіатори здатні використовувати вбудоване знання про паї множини або підмножини даних для того, щоб постачати інформації для додатків більш високого рівня. Вони повинні при цьому входити: складу проміжної ланки трьохрівневої архітектури, між користувачем (клієнтські додатки) і базою (безліччю баз) даних. Специфічні застосування медіаторів у середовищах мультибаз дляіз глобальною схемою полягають у з'ясуванні місця розташуй даних, необхідних для виконання потрібної операції, відібрав (як відображаються локальні бази даних у глобальну схему) тут; конфліктів (яким є результат відображення та узгодження даних, які протиріччя повинні бути усунені). Контрольні питання до розділу 31. Навести складові базової технології КІС. 2. Навести методи аналізу даних, на якому базується інструментарій організації даних у динамічних СППР. 3. Розкрити зміст поняття «багатовимірний аналіз». 4. Розкрити зміст поняття «MOLAP». 5. Розкрити зміст поняття«ROLAP». 6. Розкрити зміст поняття «HOLAP». 7. Навести головні поняття, які використовуються при багатовимірній організації даних. 8. Навести головні операції маніпулювання даними в багатовимірній моделі. 9. Навести різницю між гіперкубічною та полікубічною моделями даних. 10. Навести та обґрунтувати сферу застосування багатовимірних СУБД. 11. Розкрити зміст поняття «модель даних «зірка». 12. Навести аналогію між багатовимірною моделлю даних ъ моделлю «зірка». 13. Розкрити зміст поняття «модель даних «сніжинка». 14. Провести та пояснити сферу використання організації даних в ROLAP-системах. 15. Привести рівні використання даних в 1С з аналітичними можливостями. 16. Розкрити зміст поняття «часова БД». 17. Привести організацію даних у ГІС. 18. Пояснити різницю між векторною та растровою моделями даних у ГІС 19. Привести сферу використання ГІС. 20. Розкрити зміст поняття «навігаційні системи». 21. Розкрити зміст поняття «БД, яка кочує». 22. Розкрити зміст поняття «паралельна БД». 23. Пояснити переваги використання паралельних БД. 24. Розкрити зміст понять «програмне забезпечення проміжного шару» та «єдиний системний образ» 1С. 25. Розкрити зміст поняття «шлюз БД». 26. Пояснити зв'язок між єдиним системним образом 1С та технологією CORB А. 27. Розкрити зміст поняття «медіатор» в 1С. 28. Пояснити схему архітектури мультибази даних із глобальною схемою. З повагою ІЦ “KURSOVIKS”! |