|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
АвтоАвтоматизацияАрхитектураАстрономияАудитБиологияБухгалтерияВоенное делоГенетикаГеографияГеологияГосударствоДомДругоеЖурналистика и СМИИзобретательствоИностранные языкиИнформатикаИскусствоИсторияКомпьютерыКулинарияКультураЛексикологияЛитератураЛогикаМаркетингМатематикаМашиностроениеМедицинаМенеджментМеталлы и СваркаМеханикаМузыкаНаселениеОбразованиеОхрана безопасности жизниОхрана ТрудаПедагогикаПолитикаПравоПриборостроениеПрограммированиеПроизводствоПромышленностьПсихологияРадиоРегилияСвязьСоциологияСпортСтандартизацияСтроительствоТехнологииТорговляТуризмФизикаФизиологияФилософияФинансыХимияХозяйствоЦеннообразованиеЧерчениеЭкологияЭконометрикаЭкономикаЭлектроникаЮриспунденкция |
ОСНОВНІ ВІДМІННОСТІ СИСТЕМ ОБРОБЛЕННЯ ТРАНЗАКЦІЙ (OLTP) І АНАЛІТИЧНИХ СИСТЕМ
Закінчення табл. 10.2
Аналітичні завдання залежно від концепції аналізу можна поділити на дві групи: завдання статичного та завдання оперативного аналізу. Ці дві групи аналітичних завдань суттєво відрізняються між собою. Перша група завдань характеризується тим, що вони реалізуються на основі традиційної технології автоматизації розв'язання. За цієї технології спочатку формулюється технічне завдання, яке передається програмісту для програмування. Програміст складає програму та тестує її і лише після цього отримує результат у вигляді регламентованих, тобто чітко визначених форм. За такого підходу виникає велика затримка в часі між моментом виникнення потреби в аналізі та отриманням відповідного результату. Дуже часто результат аналізу, який був потрібний аналітику, отримують пізно і рішення приймається без його врахування. Тому для прийняття оперативних рішень такий вид аналізу не підходить. Рис. 10.1. Узагальнена схема інформаційної аналітичної системи Саме потреба в оперативному багатоаспектному бізнес-аналізі привела до виникнення нової OLAP-технології розв'язання аналітичних завдань. Ця технологія призначена забезпечувати аналітиків динамічним багатовимірним аналізом консолідованих даних. Як уже зазначалося, розв'язання аналітичних завдань не може обмежуватись лише даними транзакційних систем. Для порівняльного аналізу та виявлення тенденцій потрібно мати великі обсяги зовнішніх даних з різних статистичних збірників, з елект- ронних та інших джерел. Зручним способом зберігання далих для розв'язання оперативних аналітичних завдань є сховища даних, що утворюють основу аналітичних інформаційних систем. Уза-гальнена схема інформаційної аналітичної системи, котра ураховує описані засади, показана на рис. 10.1. Орієнтовані на дані СППР мусять мати дані найвищої якості інакше дані можуть призвести до невдач у розв'язанні проблем. Дані найвищої якості — це точні, своєчасні, значимі (важливі) і повні (комплектні) дані. Оцінювання або вимірювання якості джерел даних є попереднім завданням, яке пов'язане з оцїльован-ням технічної здійснимості проекту орієнтованої на дані СППР. 10.1.2. Базові концепції та визначення Зважаючи на те, що сховища даних і системи оперативного аналітичного оброблення (OLAP-системи) в принциповому плані виконують фактично такі самі функції, а саме: на основі нагромаджених за багато періодів даних про поточні ділові операції появляється можливість отримувати інформацію для створення кращих, основаних на фактах, управлінських рішень, деякі коментатори стали їх ототожнювати. Насправді, сховища даних і OLAP — різні види орієнтованих на дані СППР. Сховище даних (Data Warehouses) є специфічною базою даних, яка проектується і наповнюється, щоб підтримувати створення рішень в організації. Це є пакет, своєрідна система керування базою даних, що існує окремо від оперативних систем, обновлюється і структурується для термінових оперативних запитів і управлінських підсумків. За змістом та часовим горизонтом вона відрізняється від оперативних систем. При цьому сховище даних є незмінним у часІ' а, отже, здатним підтримувати різноманітні види аналізу. Переважно такі бази даних є архівами операційних даних, відібраних для забезпечення підтримки прийняття рішень та оптимізованих для взаємодії з СППР організації. На рис. 10.2 зображена спрощена схема формування та використання сховища даних у СППР. Дані беруться з різноманітних джерел оперативних даних. Після переміщення проводиться їх відбір для гарантування того, що вони мають достатню значимість, є безперервними і точними. Потім дані завантажу-ються в реляційні таблиці, які в змозі підтримувати різноманітні ви-ди аналізу та запитів, і оптимізуються для тих таблиць, які, як очікується, будуть найчастіше застосовуватися. І, нарешті, дані зберігаються для подальшого використання в СППР. Рис. 10.2. Схема формування і використання сховища даних у СППР Згідно з концепцією засновника сховищ даних Б. Інмона (Bill Inmon) «сховище даних є тематично орієнтованою, інтегрованою, динамічною (time-variant), довготривалою сукупністю даних для підтримання процесів менеджерів, котрі розробляють рішення». Р. Кімбал (Ralph Kimball, 1996), інший піонер створення сховищ даних, уважає, що «сховище даних містить копії даних транзак-цій, специфічно структурованих для запитів і аналізу». Головними властивостями сховищ даних, які виділені Інмоном, є: Тематична (суб'єктна) орієнтованість — означає фокусування на темах, пов'язаних з бізнесом або організаційною активністю суб'єктів подібно діям споживачів (клієнтів), службовців і постачальників, тобто сховища даних мають орієнтуватися на предметну галузь, а не на специфіку програмних засобів, які будуть взаємодіяти з цими додатками. Інтегрованість — означає, що дані зберігаються в узгодже-юму форматі завдяки використанню іменованих правил (умовних позначень, домовленостей), обмежень домена (області допустимих значень, сфери дії), фізичних атрибутів і вимірів. Динамічність (time-variant) — це відповідність даних пев-им моментам часу, тобто це є часові ряди (або серії), що не мають поточного статусу. Довготривалість — означає, що дані тільки читаються і не інюються з часом, як тільки вони переміщуються в сховище, зберігаються для підтримки рішень. Крім цих характеристик існують і інші важливі властивості сховищ даних, зокрема: Підсумовуваність даних — операційні дані набувають придатної для підтримки рішень форми, тобто бази даних утримують агреговані значення для управлінських рішень як окремий відбиток від баз даних, які використовуються для онлайнового оброблення транзакцій — OLTP (On Line Transaction Processing). Масштабність — мається на увазі, що в сховищах даних зберігається набагато більше даних, ніж у звичайних базах даних. Ненормалізованість — дані в сховищах можуть бути надмірними, ненормалізованими. Наявність метаданих — метадані в СППР на основі сховищ даних обов'язкові. Ці метадані життєво важливі для підтримки сховищ даних і для кінцевих користувачів, яким потрібно знати, як розмістити дані. Сховища даних недешеві. До цих пір потрібні багатомільйонні загальні витрати і тривалий час для їх проектування та реалізації. Велике корпоративне сховище даних може потребувати 2—3 мільйонів доларів, необхідних для створення програмного та апаратного забезпечення, оплати праці розробників, витрат на навчання та 2—З років для його створення. Оскільки сховища даних розробляються з метою забезпечення кожного менеджера підприємства загальним рядом даних, то вони, як правило, великі за обсягом даних і збільшуються з часом. Типові розміри потрібної пам'яті — від 50 гігабайт (гігабайт = 1 073 741 844 байтам) до понад один Тб (терабайт = 1000 гігабайтам). Проте, незважаючи на значні фінансові та витрати часу, організація сховищ даних стає все популярнішою. Нині побудова сховищ даних є головним напрямом розвитку інформатики. Оцінки дещо різняться, але можна впевнено стверджувати, що більше половини корпорацій, які входять до 500 найуспішніших, мають або планують мати сховища даних. Зі сховищем даних пов'язаний термін «вітрина даних» (Data Mart). Інколи застосовують такі його синоніми: кіоск даних, під-множина сховища даних, сховище даних рівня підприємства, ярмарка даних. Вітрина даних — це певна частина сфокусованих на окрему тему даних або виокремлені елементи сховища даних. Наприклад, деякі компанії скоріше будують вітрину даних щодо споживачів, ніж багатопредметне сховище даних. Така вітрина даних містить всю необхідну інформацію про споживачів. Багато організацій і бізнесових структур починають будувати свої пов- масштабні (корпоративні) сховища даних шляхом побудови серії сфокусованих вітрин даних. Коли сховище даних уже створене та оптимізоване, то необхідно ефективно завантажувати нові дані в систему без переривання процесу підтримки прийняття рішень. Однак у разі збільшення кількості даних розробникам необхідно визначати нові синтаксичні формати та формати запитів, які були б швидшими та легшими. Найпоширенішим засобом організації сховищ даних для задоволення різних аналітичних запитів є використання багатовимірної моделі даних, що пов'язується з поняттям OLAP, зокрема, з його реляційним різновидом. Група продавців технології OLAP, яка є асоціацією захисників програмних продуктів OLAP, що має призначення сприяти більшому розумінню системи і її головних принципів, сформувала Раду OLAP. Рада запропонувала таке визначення OLAP: Оперативне (онлайнове) аналітичне оброблення (On-line analytical processing — OLAP) є категорією технології програмного забезпечення, яке дало змогу аналітикам, менеджерам і виконавцям підсилити подання даних завдяки швидкому, узгодженому, інтерактивному доступу до широкого діапазону можливих зображень інформації, яка була одержана шляхом перетворення неопрацьованих (первинних) даних для відображення в реальній вимірності, зрозумілій користувачам, стану підприємства. З практичного погляду OLAP є якраз тим, чого очікували від СППР протягом багатьох років, тобто перспективною системою, яка проста для використання, містить спеціалізовані (спеціально виділені) дані і пристосована до потреб користувачів. Ця система використовує сховища даних, а також містить велику кількість інструментальних засобів кінцевого користувача для організації доступу до даних і проведення їх аналізу. OLAP здійснюється в багатокористувацькому клієнт/сервер-ному режимі і уможливлює узгоджену швидку відповідь на запити, незалежно від обсягу і складності бази даних. OLAP допомагає користувачеві синтезувати інформацію підприємства завдяки порівняльному, конкретизованому перегляду даних, а також завдяки аналізу фактичних і розрахункових показників у варіантах аналізу типу «що..., якщо...?». Все це досягається за допомогою використання сервера OLAP. Сервер OLAP є високорозрядним, багатокористувацьким механізмом (або процесором бази даних) маніпулювання даними, специфічно розробленим для того, щоб підтримувати і здійснюва- ти операції з багатовимірними структурами даних. Багатовимірна структура упорядкована так, щоб кожний елемент даних був розміщений і забезпечений доступом на основі перетину компонентів вимірностей, які визначають той елемент. Сервер і структура даних оптимізовані для швидкого пошуку інформації, для проведення аналізу типу «на даний випадок» (ad-hoc) у будь-якому аспекті, а також для швидкого та гнучкого обчислення і перетворення первинних даних, що грунтується на формул ьних взаємоза-лежностях. Досягнутий на даний час стан технологічних засобів і вимоги кінцевих користувачів щодо узгоджених і швидких відповідей визначають, що найкращим підходом до організації оброблення даних є установлення багатовимірної бази даних у сервері OLAP. Прикладами багатовимірних серверів можуть бути Lightship Server від Pilot Software і Essbase від Arbor Software. Функціональні можливості OLAP характеризують підтримку кінцевих користувачів-аналітиків динамічним багатовимірним аналізом консолідованих підприємницьких даних і навігаційними діями, включаючи: обчислення і моделювання, що застосовується за допомогою вимірності, єрархії і/або компонентів; аналіз трендів за послідовні періоди; квантування під-множин (підмножини даних аналізують за допомогою тонких зрізів) для візуалізації на екрані; практичне оброблення з підвищенням рівня деталізації до найглибших рівнів консолідації основних даних; прямий доступ до основних деталізованих даних; повернення до порівнянь у нових вимірах із застосуванням візуалізації. 10.1.3. Взаємопов 'язана архітектура орієнтованих на дані СППР Архітектура орієнтованих на дані СППР має низку взаємопов'язаних елементів. Команди проектувальників мають починати розроблення проекту СППР з дослідження принципів побудови сховищ даних і орієнтованих на дані СППР з метою отримання архітектурного шаблону, зокрема для виявлення типових компонентів системи (наприклад, інтерфейсів), і того, як вони пристосовуються до типової організації, які є характерні чинники успіху або невдачі проекту. Після цього розробники мають накреслити карту типових даних і інтерфейсів, що можуть використовуватися за специфічних умов досліджуваної компанії, Компоненти сховища (масиву) даних складаються з однієї або більше баз даних, збудованих з використанням реляційної СКБД, багатовимірної системи керування базою даних або обох типів цих систем. Як уже зазначалося, бізнес-дані вибираються з операційних баз даних та із зовнішніх джерел даних. Зовнішні джерела забезпечують тими даними, які не можуть бути знайдені в системах оброблення транзакцій компанії, але які доречні для аналізу бізнес-процесів, як наприклад, цінами акцій та іншими ринковими показниками. Сховище даних є компіляцією багатьох «моментальних знімків» фінансових, операційних і бізнесових ситуацій компанії. Коли формуються бізнесові дані для сховища даних, то операційні дані підсумовуються і впорядковуються в структурах, які оптимізовані з метою проведення швидкого аналізу, пошуку або вибирання даних. Процес старіння елементів у масивах даних запобіга-ється шляхом переміщення поточних детальних даних на місце застарілих. Компоненти, що забезпечують виділення і фільтрування даних використовуються для вибирання і перевіряння достовірності даних, отримуваних від операційної бази даних і зовнішніх джерел. Наприклад, для визначення відносної частки ринку для вибраних асортиментів продукції СППР потребує даних стосовно продуктів конкурентів. Такі дані можуть бути розміщені в зовнішніх базах даних, які створюються й підтримуються за допомогою індустріальної групи або компаній, що торгують на ринку такими даними. Як це випливає з назви, ці компоненти вибирають дані з різних джерел, фільтрують їх, щоб підібрати доречні Дані, і форматують так, щоб можна було їх додавати до сховищ Даних СППР. Аналітик даних або менеджер можуть створювати запити для доступу до бази даних СППР за допомогою спеціального «інструментального засобу запитів кінцевого користувача», інтерфейс якого відповідно настроюється для полегшення використання. Інструментальні засоби кінцевого користувача для аналізу та подання інформації допомагають менеджеру виконувати обчислення і вибирати найвідповідніший формат подання. Наприклад, менеджер може бажати отримувати зведені звіти у вигляді таблиць, карт, секторних або стовпчикових діаграм. Інструментальний засіб запиту та інструментальний засіб подання належать до зовнішнього інтерфейсу СППР. Клієнт/серверна технологія забезпечує можливість цим компонентам взаємодіяти з іншими, щоб сформувати завершену архітектуру СППР. Як тільки архітектура програмного забезпечення розроблена для СППР, що призначається для досягнення наперед визначених цілей конкретної компанії, то потім виникає багато запитань, пов'язаних з проектуванням, розробленням та реалізацією нової орієнтованої на дані системи підтримки прийняття рішень. 10.1.4. Загальне проектування і процес розроблення орієнтованих на дані СППР Різні автори по-своєму налагоджували процес розроблення орієнтованих на дані СППР. Раніше були розглянуті два загальні підходи до побудови СППР: «розроблення життєвого циклу системи» і «швидке макетування». Для відносно малих проектів ОДСППР, подібних до вітрин даних, доцільно застосовувати швидке макетування, а для створення проектів корпоративних сховищ даних або ОДСППР можна здійснювати п'ять загальних, орієнтованих на рішення, кроків. Перший крок — початкове збирання даних або діагностика. Цей крок передбачає ідентифікування й інтерв'ювання головних майбутніх користувачів СППР, визначення провідних тем СППР, ідентифікацію моделі даних транзакцій, визначення рівня монопольного використання даних, частоти оцінювання і оновлення системи, вимог до інтерфейсу кінцевого користувача, а також форм подання даних. За розроблення проекту головну увагу слід приділяти творцям рішень і самим рішенням протягом усіх кроків. Другий крок — проектування і створення карти (Mapping) розміщення масиву даних (Data Store). У середовищі реляцій-ної СКБД спочатку необхідно вибрати зіркоподібну схему структури даних і виявити факти, виміри, атрибути, а потім створити діаграми зіркоподібних схем, єрархію атрибутів і рівні агрегу-вання. Ці концептуальні моделі слід подати у вигляді реляційних таблиць. У середовищі багатовимірної бази даних мають бути визначені ключові змінні і виміри. В базу даних вмонтовують доречні для СППР дані. Третій крок — завантаження і тестування даних. Створення бази даних СППР включає підготовку до введення даних, визначення переліку початкових даних для завантаження і процесу актуалізації або оновлення. В той же час аналітики визначають необхідні перетворення транзакцій і будь-яких зовнішніх даних, таблиць операційних даних транзакцій, інтегрують і трансформують дані. Дані завантажуються, індексуються й перевіряються на достовірність і, нарешті, перевіряють метадані та куби даних або зіркоподібні схеми. Четвертий крок — побудова і випробовування орієнтованих на дані СППР. Аналітикам потрібно створити меню, розробити вихідні формати даних, визначити передбачувані запити, підготувати тести для інтерфейсів і результатів, знайти оптимальні рішення щодо швидкості й точності роботи системи. При цьому вони мусять спілкуватися з кінцевими користувачами протягом макетування і тестування елементів проекту, підготувавши їх до використання середовища розроблення СППР. У такий спосіб творці рішень мають бути серйозно залученими до процесу побудови і випробування нової, орієнтованої на дані СППР. Останній крок — розгортання (Rollout) і зворотний зв'язок (Feedback). Цей крок передбачає реальне розгортання СППР, забезпечення додаткової підготовки, установлення зворотного зв'язку з користувачами, супроводження системи і в багатьох випадках також її розширення та вдосконалення. За такого підходу є підстави сподіватися, що СППР дасть змогу удосконалити створення рішень і тим самим принесе користь як компанії загалом, так і творцям рішень зокрема. 10.2. Концепція сховищ даних і її реалізація в інформаційних системах 10.2.1. Побудова сховищ даних Практика свідчить, що різні компанії та організації будують сховища даних з метою створення своїх специфічних Додатків, причому в багатьох із них перше сховище даних, зазвичай, призначається для виконавчих інформаційних систем. Сховище даних потенційно орієнтоване на різні джерела (рис. 10.3), включаючи операційні бази даних або дані транзак-цій. Інші внутрішні дані, які надходять від електронних таблиць і внутрішньокорпоративних документів, та зовнішні дані, як наприклад бази даних новин чи цін акцій, можуть також бути збережені в сховищі даних. У типовій організації операційні дані розпорошені через використання кількох СКБД у дуже різних форматах і на різних апаратних платформах. Наприклад, операційні дані можуть міститися у великих ЕОМ (мейнфрей-мах) типу IBM або DEC і знаходитися у файлах інформаційних систем менеджменту (на рис. 10.3 — IMS), забезпечуватися віртуальним методом доступу до файлів даних (VSAM), або знаходитися в СКБД DB2 і базах даних. Успадковані інформаційні системи, як наприклад ті, що зображені на рис. 10.3 з ілюстративною метою, є загальним джерелом даних для сховищ даних. Дані, які вибираються зі щойно названих джерел, необхідно «очистити» для того, щоб перетворити їх формат на прийнятний з метою використання в сховищі. Інакше кажучи, дані мають подаватися у форматах, відповідних тим додаткам, для яких розробляється сховище даних. Наприклад, якщо деякі потрібні операційні дані рідко використовуються на індивідуальному транзак-ційному рівні, то їх потрібно підсумувати або агрегувати перед збереженням у сховищі. Важливим чинником стимулювання організації сховищ даних у корпораціях стала поява спеціального програмного забезпечення, призначеного для побудови та зберігання сховища даних, а також для забезпечення доступу до них. Як видно із рис. 10.3, до групи продавців цих програмних продуктів належать як добре відомі розробники СППР та ВІС (наприклад Pilot, Comshare, IRI) і баз даних (наприклад, Oracle, Focus), так і менш знайомі продавці (Red Brick, Platinum, Carleton), які мають значний вплив у сфері організації сховищ даних. У табл. 10.3 подані основні розробники та створювані ними інструментальні засоби, призначені для побудови окремих компонентів та виконання функцій сховищ даних. Проте слід зауважити, що кількість як самих розробників, так і інструментальних засобів створення сховищ даних постійно зростає, так само як зростають обсяги продажу програмних продуктів сховищ даних, які 2000 року перевищили 5 млрд доларів США.
Таблиця 10.3 ІНСТУМЕНТАЛЬНІ ЗАСОБИ ТА ЇХ ВИРОБНИКИ ДЛЯ СТВОРЕННЯ СХОВИЩ ДАНИХ
Закінчення табл. 10.3
Сховище даних містить тільки моментальні знімки фактичних даних на конкретний день, як, наприклад, на останню п'ятницю або на останній день місяця. Обновлення даних залежить від потреб користувачів і бізнесового циклу, який асоціюється з даними. Наприклад, торговому менеджеру, який установлює ціни на кожний день, необхідне обновлення даних щодня або навіть частіше. Фінансовий аналіз на кінець місяця потребує тільки помісячної актуалізації даних. Технологічний цикл обновлення даних у сховищі, як правило, триває менше однієї години, тому обновлення суттєво не впливає на поточні бізнесові дії та їх результати. Як уже зазначалося, сховище даних також містить метадані — інформацію про дані, тобто відомості про те, звідки й від кого дані надходять, хто має доступ до них і як часто, які бізнесові процеси вони забезпечують і які критичні фактори успіху вони підтримують. Ці метадані життєво важливі для підтримки сховищ даних і для кінцевих користувачів, яким потрібно знати, як розміщувати дані. Дані, які містяться в сховищах даних, можуть бути доступними через програмне забезпечення клієнта, що використовується Для підтримки прийняття рішень. Воно може призначатися для ВІС (наприклад, Lightship, Commander), СППР (наприклад, Visual IFPS, Express), або незапланованих (ad hoc) запитів (наприклад, Business Objects, Visualizer). У всіх випадках мається на увазі, що програмне забезпечення легке для користування, так що організаційний персонал з обмеженою комп'ютерною майстерністю і Досвідом може ефективно його застосовувати. Незважаючи на те, що з формаїьного погляду сховище даіних являє собою різновид звичайної Б], котра призначена для зберігання в погодженому вигляді фак-ичної інформації, що поступає з різних оперативних систем та зо.нішніх джерел, процес їх піро-ектування суттєво відрізняється. Для звичайних БД процес їх створення відбувається за схемою: вивчення предметної галузі; тобудова інформаційної моделі; розроблення на основі інформаційної моделі проекту бази даних; створення бази даних. Обов'якові етапи створення сховшщ даних відрізняються від такої схеми. Такими етапами є: визначення інформаційних потреб користувачів щодо даних, котрі нагромаджуються в базах даних операційних систем (OLTP-систем), що служать джерелами эперативних даних; вивчеиня локальних баз даних OLTP-систем; виокремлення від кожної бази даних підмножини даних, необхідних для завантаження в с хо-вище даних; інтегрування локальних підмножин даних і розроблення загальної погодженої схеми сховища. Для виконання робіт зі створення сховищ даних за даною схемою існують різні інструментальні засоби, зокрема, трограмний продукт «Oracle Designer» та його спрощена версія ^Oracle Data Mart Designer». Коли сховища даних уже створені та оптимізовані, необхідно ефективно завантажувати нові дані в систему без переривання процесу підтримки прийняття рішень. Однак у разі збільшення обсягу даних розробникам необхідно визначити нові синтаксичні формати та формати запитів, які є швидшими й легшими, а також визначити нові підходи до поєднання реляційних таблиць та добування даних з цих дуже великих баз даних з використанням різновиду програмних агентів — інтелектуальних («розумних») агентів (Intelligent agents), що розглянуті раніше. 10.2.2. Архітектура сховищ даних Поиск по сайту: |
Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Студалл.Орг (0.012 сек.) |