Posibniki.com.ua Інформатика Корпоративні інформаційні системи РОЗДІЛ 5 КОРПОРАТИВНІ СХОВИЩА ДАНИХ


< Попередня  Змiст  Наступна >

РОЗДІЛ 5 КОРПОРАТИВНІ СХОВИЩА ДАНИХ


Проаналізувати структурні схеми тиражування даних та визначити сфери їх застосування.5.1. Концепція сховищ і вітрин даних та її розвиток

5.2. Архітектура інформаційних сховищ

5.3. Адміністрування інформаційних сховищ

5.4. Інструментальні засоби архівації та очистки інформаційних сховищ

Резюме

Терміни і поняття

Запитання для перевірки знань

Завдання для індивідуальної роботи Вивчивши матеріал цього розділу, ви будете ЗНАТИ:

— основні властивості сховищ даних;

— сутність концепції вітрин даних;

— архітектурні рівні сховищ даних — ROLAP, MOLAP, HOLAP;

— порядок адміністрування інформаційних сховищ;

— використання метаданих у процесі автоматизованого адміністрування даними, а також УМІТИ:

— визначати сферу застосування корпоративних сховищ і вітрин даних;

— розробляти архітектурні варіанти корпоративних сховищ даних;

— використовувати засоби OLAP-аналізу.

5.1. КОНЦЕПЦІЯ СХОВИЩ І ВІТРИН ДАНИХ ТА ЇЇ РОЗВИТОК

Першими з проблемою неефективності аналітичних додатків у OLTP-системах зіткнулися великі західні корпорації, у чиїх системах оброблення даних на початок 90-х років ХХ ст. нагромадилися величезні обсяги інформації, а якість виконання аналітичних завдань значно відставала від можливостей обчислювальної техніки. Ідею сховищ даних уперше запропонував Б. Інмон (Bill Inmon) 1992 року. У своїй книзі «Building the Data Warehouse», де він досліджував проблеми організації корпоративних баз даних, Б. Інмон дав класичне визначення сховища даних (Data Warehouse — DW), схарактеризувавши його як предметно-орієнтований, інтегрований, незмінний набір даних, що підтримує хронологію та організований для цілей підтримки управління.

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

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

По-третє, традиційні бази даних найчастіше є джерелом даних, що потрапляють у сховище. Крім того, сховище може поповнюватися із зовнішніх джерел, наприклад зі статистичних звітів. Дані, що надходять до бази даних з іншої бази, невеликі за обсягом і мають ту саму структуру даних, що й база данихприймач. На відміну від них сховища даних у визначені терміни отримують значно більші обсяги даних, які можуть відрізнятися від приймача форматом, а інколи і типом, що вимагає застосування додаткових процедур трансформування та завантаження даних (так звані процедури Extract, Transform, Load).

Як бази даних, так і сховища даних можуть будуватися за певною системою управління базами даних (СУБД) (реляційна, постреляційна тощо). СУБД забезпечує загальний репозиторій для зберігання й опрацювання структурованих даних і підтримує набір взаємопов’язаних послуг, а також дає змогу розробникам зосередитися на специфічних проблемах їх застосувань, а не на завданнях, що виникають за потреби в узгодженому й ефективному управлінні великими обсягами даних. Проте СУБД вимагають, щоб усі дані перебували під єдиним адміністративним управлінням і відповідали єдиній схемі. У відповідь на задоволення цих обмежень СУБД можуть забезпечити розвинені засоби маніпулювання даними й опрацювання запитів зі зрозумілою і строгою семантикою, а також чіткі транзакційні гарантії оновлень, паралельного доступу і тривалого зберігання (так звані властивості ACID).

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

Розглянемо основні властивості сховища даних.

Предметна орієнтація. На відміну від баз даних у традиційних OLTP-системах, де дані підібрано відповідно до конкретних додатків, інформація в DW зорієнтована на завдання оперативного аналізу й підтримки прийняття рішень. Для систем підтримки прийняття рішень (Decision Support System — DSS) і OLАP-систем (On-Line Analytical Processing) необхідна інформація, організована відповідно до основних аспектів діяльності підприємства (замовники, продаж, склад тощо). Це відрізняє сховище даних від оперативної бази даних, де дані організовано відповідно до процесів (виписування рахунків, відвантаження товару тощо). Предметна організація даних у сховищі сприяє як

значному спрощенню аналізу, так і пришвидшенню виконання аналітичних запитів. Оскільки в DW-технології об’єкти даних виходять на перший план, особливі вимоги висувають до структур БД: у них міститься лише та інформація, що може бути корисною для підтримки прийняття рішень. Інтегрованість даних. Дані в інформаційне сховище надходять із різних джерел, де вони можуть мати різні імена, атрибути, одиниці вимірювання і способи кодування. Після того, як дані зчитано з оперативних БД, вони очищаються від індивідуальних ознак, тобто приводяться до єдиного вигляду, потрібною мірою агрегуються (тобто обчислюються сумарні показники) і завантажуються в DW. Такі інтегровані дані куди простіше аналізувати. Інваріантність у часі. У OLTP-системах істинність даних гарантована лише в момент читання, оскільки вже наступної миті вони можуть змінитися внаслідок чергової транзакції. Дані у сховищі завжди безпосередньо пов’язані з певним періодом. Дані з оперативних БД завантажуються у сховище у вигляді «історичних пластів», кожен з яких належить до конкретного періоду.

Часова інваріантність даних у сховищі досягається введенням поля з атрибутом «час» (день, тиждень, місяць, рік) у ключі таблиць. У результаті записи у таблицях DW ніколи не змінюються, бо являютьи собою знімки даних, зроблені в конкретні відрізки часу. У DW містяться ніби моментальні знімки даних. Кожен елемент у своєму ключі явно чи опосередковано зберігає часовий параметр, наприклад день, місяць або рік, що дає змогу аналізувати тенденції в розвитку бізнесу.

Стабільність (незмінюваність) даних. Якщо у OLTP-системах записи можна постійно долучати, виділяти і редагувати, то потрапивши до сховища в певний «історичний пласт», дані вже ніколи не будуть змінені. Стосовно них можливі лише дві операції — початкове завантаження і читання. Це й визначає специфіку проектування структури бази даних для сховищ.

Якщо в перебігу створення OLTP-систем розробники мають враховувати такі моменти, як відкочування транзакцій після збою сервера, боротьбу зі взаємним блокуванням процесів (deadlocks), зберігання цілісності даних, то для сховищ даних ці проблеми менш актуальні: перед розробниками стоять інші завдання, пов’язані, наприклад, із забезпеченням високої швидкості доступу до даних.

Мінімізація збитковості інформації. Оскільки інформація у сховища даних завантажується з OLTP-систем, постає питання: чи не веде це до надмірності даних? Як стверджує Б. Інмон, насправді надмірність мінімальна (близько 1 %), що пояснюється такими чинниками:

— під час завантаження інформації з OLTP-систем до сховищ дані фільтруються, причому багато з них узагалі не потрапляють до сховищ як беззмістовні в плані використання у системах підтримки прийняття рішень;

— інформація в OLTP-системах має зазвичай оперативний характер, а дані, що втратили актуальність, вилучаються. У сховищах даних, навпаки, зберігається вся історія даних у хронологічному порядку, і в цьому плані перекриття даними сховищ вмісту OLTP-систем виявляється незначним;

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

щаються від непотрібної інформації й доводяться до єдиного формату, а це вже зовсім інші дані.

Зауважимо, що при розгляді останньої властивості сховищ даних слід відрізняти інформаційну збитковість (про яку йдеться) від фізичної збитковості, яка залежить від способу зберігання інформації на машинних носіях. Ідеться про зберігання багатовимірних баз даних на OLАP-серверах (Multidimensional Data Base — MDD). OLАP-сервери, або сервери багатовимірних БД, можуть зберігати свої багатовимірні дані по-різному. Річ у тому, що в будь-якому сховищі даних — і в звичайному, і в багатовимірному — поряд з детальними даними часто зберігаються підсумкові показники (агреговані показники, агрегати), такі, наприклад, як суми обсягу випуску продукції за місяцями (роками), за видами продукції тощо. Агрегати зберігаються з єдиною метою — прискорити виконання запитів. Якби кожного разу під час звернення до бази для отримання суми обсягу випуску продукції корпорації за рік доводилося підсумовувати мільйони даних щоденних випусків, то швидкість виконання такого запиту була б неприйнятною. Тому під час завантаження даних у багатовимірну БД обчислюються і зберігаються всі сумарні показники або їх частина. Крім того, зберігання інформації у вигляді гіперкуба потребує використання додаткової інформації — адресних посилань, таблиць метаданих тощо, а це призводить до різкого збільшення обсягів пам’яті для зберігання багатовимірних баз даних. За швидкість оброблення запитів до сумарних даних доводиться платити збільшенням обсягів даних і часу на їх завантаження. Причому збільшення може бути значним. Вхідний масив розміром 200 Мбайт може легко розростися до обсягу 5 Гбайт у вигляді, необхідному для зберігання в MDD. Масив такого розміру потребує добового часу для завантаження й об’єднання. Обмеження на розмір масиву після розширення до 10 Гбайт виробничі аналітики вважають верхньою межею практичного використання MDD.

Одним із найважливіших питань, що постають перед розробниками сховищ даних, є вибір системи управління базами даних, яку буде покладено в основу цього складного продукту. Вимоги до програмного забезпечення такого класу суворі. Окрім надійності й достатньої швидкості роботи СУБД має володіти OLАP-можливостями та іншим спеціальним інструментарієм, опрацьовувати скільки завгодно великі обсяги даних, а також мати підтримку надійної фірмивиробника. Інвестиції, що їх корпорація вкладатиме у створення потужної інформаційно-аналітичної системи, мають бути зорієнтовані на перспективу, адже цінність сховища даних зростає пропорційно часу його використання. І корпоративне сховище даних, від якості якого залежатиме продуктивність усієї КІС, має бути бездоганне як щодо поточної функціональності, так і в плані репутації компанії, яка його створила, оскільки передбачається довгострокова підтримка і постійний розвиток продукту.

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

Вітрина даних. Вітрина даних (Data Mart) за своїм вихідним призначенням — це набір тематично пов’язаних баз даних, що містять інформацію, яка належить до окремих сфер діяльності корпорації. Власне, вітрина даних — це спрощений

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

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

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

На другому рівні підтримуватимуться вітрини даних на основі багатовимірної системи управління базами даних (прикладом такої системи є Oracle Express Server). Такі СУБД майже ідеально підходять для цілей розроблення OLAP-систем, але поки що не дозволяють зберігати надто великі обсяги даних (граничний розмір багатовимірної бази даних становить 40 Гбайт). Утім коли йдеться про вітрини даних, це й непотрібно. Крім того, вітрина даних не обов’язково має бути цілком сформованою. Вона може містити посилання на сховище даних і добирати звідти інформацію у міру надходження запитів. Звісно, це дещо збільшує час відгуку, але знімає проблему обмеженого обсягу багатовимірної бази даних.

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


< Попередня  Змiст  Наступна >
Iншi роздiли:
5.3. АДМІНІСТРУВАННЯ ІНФОРМАЦІЙНИХ СХОВИЩ
5.4. ІНСТРУМЕНТАЛЬНІ ЗАСОБИ АРХІВАЦІЇ ТА ОЧИСТКИ ІНФОРМАЦІЙНИХ СХОВИЩ
КОРПОРАТИВНІ ІНФОРМАЦІЙНІ СИСТЕМИ В СИСТЕМІ ОРГАНІЗАЦІЙНОГО УПРАВЛІННЯ РОЗДІЛ 6 РЕАЛІЗАЦІЯ ПРОМИСЛОВОЇ ЛОГІСТИКИ В КОРПОРАТИВНИХ ІНФОРМАЦІЙНИХ СИСТЕМАХ
6.2. КОМПОНЕНТИ ЛОГІСТИКИ ТА ЗАГАЛЬНА ХАРАКТЕРИСТИКА ЇХ
6.3. ПОКАЗНИКИ ОРГАНІЗАЦІЙНО-ЕКОНОМІЧНОЇ СТІЙКОСТІ ПІДПРИЄМСТВА
Дисциплiни

Медичний довідник новиниКулінарний довідникАнглійська моваБанківська справаБухгалтерський облікЕкономікаМікроекономікаМакроекономікаЕтика та естетикаІнформатикаІсторіяМаркетингМенеджментПолітологіяПравоСтатистикаФілософіяФінанси

Бібліотека підручників та статтей Posibniki (2022)