Сховища даних і планування ресурсів підприємства | DWH і ERP

АРХІВ DATA ЦЕНТРАЛЬНИЙ: ІСТОРІЯ ВИД ЕВОЛЮЦІЇ

Двома домінуючими темами корпоративних технологій у 90-х роках були: i сховище даних та ERP. Тривалий час ці дві потужні течії були частинами корпоративних ІТ, ніколи не перетинаючись. Це було майже так, ніби вони були матерією та антиматерією. Але зростання обох явищ неминуче призвело до їх перетину. Сьогодні компанії стикаються з проблемою, що робити з ERP та сховище даних. У цій статті буде описано, що це за проблеми та як компанії їх вирішують.

НА ПОЧАТКУ…

На початку було сховище даних. Інформаційне сховище створено для протидії прикладній системі обробки транзакцій. У перші дні запам'ятовування дані він мав бути просто контрапунктом до програм обробки транзакцій. Але в наш час існують набагато витонченіші погляди на те, що a сховище даних. У сучасному світі сховище даних він вставлений у структуру, яку можна назвати корпоративною інформаційною фабрикою.

ФАБРИКА КОРПОРАТИВНОЇ ІНФОРМАЦІЇ (CIF)

Корпоративна інформаційна фабрика має стандартні архітектурні компоненти: рівень трансформації та інтеграції коду, що об’єднує дані поки я дані вони переміщуються із середовища застосування до середовища сховище даних компанії; a сховище даних компанії, де знаходиться дані докладні та комплексні історики. The сховище даних компанії служить основою, на якій можуть будуватися всі інші частини середовища сховище даних; сховище оперативних даних (ODS). ODS — це гібридна структура, яка містить деякі аспекти сховище даних та інші аспекти середовища OLTP; вітрини даних, де різні відділи можуть мати власні версії сховище даних; a сховище даних дослідження, у якому «філософи» компанії можуть надсилати свої запити протягом 72 годин без шкідливого впливу на сховище даних; і ближня рядкова пам'ять, у якій дані старий і дані об'ємну деталь можна зберігати дешево.

ДЕ ERP ПОЄДНУЄТЬСЯ З ФАБРИКА КОРПОРАТИВНОЇ ІНФОРМАЦІЇ

ERP зливається з Фабрикою корпоративної інформації у двох місцях. Спочатку як базова програма (базова лінія), яка забезпечує i дані додатка до сховище даних. У цьому випадку i дані, створені як побічний продукт процесу транзакції, інтегруються та завантажуються в сховище даних компанії. Друга точка об'єднання між ERP і CIF і ODS. Фактично, у багатьох середовищах ERP використовується як класичний ODS.

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

ОКРЕМІ ODS ТА БАЗОВІ ЗАСТОСУВАННЯ

Існує багато причин, які спонукають до поділу архітектурних складових. Мабуть, найбільш показовим питанням для розділення різних компонентів архітектури є те, що кожен компонент архітектури має власний погляд. Базовий додаток має іншу мету, ніж ODS. Намагайтеся перекривати

базовий прикладний погляд на світ ODS або навпаки не є правильним способом роботи.

Отже, перша проблема ERP у CIF полягає в тому, щоб перевірити, чи існує різниця між базовими програмами та ODS.

МОДЕЛІ ДАНИХ В КОРПОРАТИВІ ФАБРИКА ІНФОРМАЦІЇ

Щоб досягти згуртованості між різними компонентами архітектури CIF, повинна існувати модель дані. Моделі дані вони служать сполучною ланкою між різними компонентами архітектури, такими як базові програми та ODS. Моделі дані вони стають «інтелектуальною дорожньою картою», щоб отримати правильне значення від різних архітектурних компонентів CIF.

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

ПЕРЕМІСТИТИ І DATA ERP В ДАНИХ WAREHOUSE

Якщо походження в дані є базовою програмою та/або ODS, коли ERP вставляє дані нель сховище даних, ця вставка має відбуватися на найнижчому рівні «деталізації». Просто підсумуйте або агрегуйте i дані оскільки вони виходять із базової програми ERP або ERP ODS, це неправильно. THE дані потрібні деталі сховище даних створити основу процесу СППР. Такі дані буде багато в чому змінено завдяки вітринам даних і дослідженням сховище даних.

Переміщення дані від базового прикладного середовища ERP до сховище даних діяльності компанії здійснюється досить спокійно. Це переміщення відбувається приблизно через 24 години після оновлення або створення в ERP. Факт наявності «ледачого» руху в дані нель сховище даних компанії дозволяє дані надходження з ERP на «депозит». Одного разу я дані зберігаються в базовій програмі, то ви можете безпечно перемістити дані ERP на підприємстві. Ще одна мета, досяжна завдяки «ледачому» руху дані це чітке розмежування між операційними процесами та СППР. З «швидким» рухом дані межа між СППР і оперативним залишається невизначеною.

Рух Росії дані від ОДС ЄРП до сховище даних компанії проводиться періодично, зазвичай щотижня або щомісяця. У цьому випадку рух о дані в її основі лежить необхідність «почистити» старі дані істориків. Звичайно, ODS містить i дані які набагато новіші, ніж дані історики знайшли в сховище даних.

Переміщення дані нель сховище даних це майже ніколи не робиться «оптом» (у оптовий спосіб). Скопіюйте таблицю із середовища ERP до сховище даних це не має сенсу. Набагато більш реалістичним підходом є переміщення вибраних одиниць дані. Тільки дані які змінилися після останнього оновлення сховище даних саме їх слід перемістити в сховище даних. Один із способів дізнатися, які саме дані змінилися з моменту останнього оновлення, щоб переглянути позначки часу дані знайдені в середовищі ERP. Конструктор вибирає всі зміни, які відбулися з моменту останнього оновлення. Інший підхід полягає у використанні методів фіксації змін дані. За допомогою цих методів журнали та журнальні стрічки аналізуються, щоб визначити, які саме дані необхідно перемістити із середовища ERP до середовища сховище даних. Ці методи найкращі, оскільки журнали та стрічки журналів можна читати з файлів ERP без подальшого впливу на інші ресурси ERP.

ІНШІ УСКЛАДНЕННЯ

Однією з проблем ERP у CIF є те, що відбувається з іншими джерелами програм або з дані ODS, до якого вони повинні робити внесок сховище даних але вони не є частиною середовища ERP. Враховуючи закритий характер ERP, особливо SAP, намагаються інтегрувати ключі із зовнішніх джерел дані з i дані які надходять із ERP під час переміщення дані нель сховище даних, це великий виклик. І яка саме ймовірність того, що i дані додатків або ODS за межами середовища ERP буде інтегровано в сховище даних? Шанси насправді дуже високі.

ЗНАЙТИ DATA ІСТОРИЧНЕ З ERP

Інша проблема з i дані ERP є те, що випливає з потреби мати дані історики в межах сховище даних. Зазвичай сховище даних потреби дані істориків. А технологія ERP зазвичай їх не зберігає дані історичний, принаймні не настільки, щоб це було необхідно в сховище даних. При великій кількості дані історія починає накопичуватися в середовищі ERP, це середовище потрібно очистити. Наприклад, припустимо, що a сховище даних має бути завантажено п'ять років дані історичні, тоді як ERP зберігає їх максимум шість місяців дані. Поки компанію задовольняє збір серії дані істориків з часом, то немає жодних проблем у використанні ERP як джерела для сховище даних. Але коли сховище даних він повинен повернутися в минуле і знайти богів дані історії, які раніше не були зібрані та збережені ERP, тоді середовище ERP стає неефективним.

ERP ТА МЕТАДАНІ

Ще одне зауваження щодо ERP e сховище даних це метадані, що існують у середовищі ERP. Подібно до того, як метадані переходять із середовища ERP до сховище даних, метадані потрібно перемістити таким же чином. Крім того, метадані мають бути перетворені у формат і структуру, необхідні інфраструктурі сховище даних. Існує велика різниця між оперативними метаданими та метаданими DSS. Операційні метадані насамперед призначені для розробника та

програміст. Метадані DSS насамперед призначені для кінцевого користувача. Існуючі метадані в програмах ERP або ODS потрібно конвертувати, і це конвертування не завжди є легким і простим.

ОТРИМАННЯ ДАНИХ ERP

Якщо ERP використовується як постачальник дані за іл сховище даних повинен бути міцний інтерфейс, який переміщує дані від середовища ERP до середовища сховище даних. Інтерфейс повинен:

• ▪ бути простим у використанні
• ▪ дозволити доступ до дані ERP
• ▪ приймати значення дані які збираються перенести на сховище даних
• ▪ знати обмеження ERP, які можуть виникнути під час доступу до дані ERP:
• ▪ посилальна цілісність
• ▪ ієрархічні відносини
• ▪ неявні логічні зв'язки
• ▪ умова застосування
• ▪ всі структури дані підтримується ERP тощо…
• ▪ бути ефективним у доступі дані, надаючи:
• ▪ прямий рух дані
• ▪ придбання здачі дані
• ▪ підтримувати своєчасний доступ до дані
• ▪ зрозуміти формат дані, і так далі… ІНТЕРФЕЙС З SAP Інтерфейс може бути двох типів, домашній або комерційний. Деякі з основних торгових інтерфейсів включають:

• ▪ SAS
• ▪ Prims Solutions
• ▪ D2k і так далі… КІЛЬКА ТЕХНОЛОГІЙ ERP Ставлення до середовища ERP як до єдиної технології є великою помилкою. Існує багато технологій ERP, кожна з яких має свої сильні сторони. Найбільш відомі виробники на ринку:

• ▪ SAP
• ▪ Oracle Financials
• ▪ PeopleSoft
• ▪ Дж. Д. Едвардс
• ▪ Баан SAP SAP є найбільшим і найповнішим програмним забезпеченням ERP. Програми SAP містять багато типів програм у багатьох сферах. SAP має репутацію:

• ▪ дуже великий
• ▪ дуже складно і дорого реалізувати
• ▪ потребує багато людей і консультантів для впровадження
• ▪ для реалізації потрібні спеціальні люди
• ▪ впровадження потребує багато часу. Крім того, SAP має репутацію компанії, що запам’ятовує її дані дуже обережно, що ускладнює доступ до них для тих, хто не знаходиться в зоні SAP. Сильна сторона SAP полягає в тому, що вона здатна захоплювати та зберігати велику кількість дані. Нещодавно SAP оголосила про намір розширити свої додатки на сховище даних. Використання SAP як постачальника має багато плюсів і мінусів сховище даних. Перевагою є те, що SAP уже встановлено і що більшість консультантів уже знають SAP.
  Недоліки SAP як постачальника сховище даних їх багато: SAP не має досвіду в світі сховище даних Якщо SAP є постачальником сховище даних, необхідно «винести» i дані від SAP до сховище даних. Dato послужний список закритої системи SAP, навряд чи буде легко отримати i від SAP у ній (???). Є багато застарілих середовищ, які забезпечують роботу SAP, наприклад IMS, VSAM, ADABAS, ORACLE, DB2 тощо. SAP наполягає на підході «не винайдено тут». SAP не хоче співпрацювати з іншими постачальниками для використання або створення сховище даних. SAP наполягає на створенні всього свого програмного забезпечення самостійно.

Хоча SAP є великою та потужною компанією, вона намагається переписати технологію ELT, OLAP, системне адміністрування та навіть основний код dbms це просто божевілля. Замість того, щоб співпрацювати з постачальниками сховище даних протягом тривалого часу SAP дотримується підходу «вони знають найкраще». Таке ставлення стримує успіх SAP у цій сфері сховище даних.
Відмова SAP дозволити зовнішнім постачальникам оперативно та витончено отримувати доступ до своїх дані. Сама суть використання a сховище даних є легкий доступ дані. Вся історія SAP базується на ускладненні доступу дані.
Відсутність у SAP досвіду роботи з великими обсягами дані; в області сховище даних є обсяги дані ніколи не бачив SAP і керувати цими великими обсягами дані потрібно мати відповідну технологію. SAP, очевидно, не знає про цей технологічний бар’єр, який існує для входу в сферу діяльності сховище даних.
Корпоративна культура SAP: компанія SAP створила бізнес із отримання дані від системи. Але для цього потрібно мати інший менталітет. Традиційно компанії-розробники програмного забезпечення, які добре вміли передавати дані в середовище, не вміли змусити дані йти іншим шляхом. Якщо SAP вдасться здійснити такий тип перемикання, вона стане першою компанією, яка це зробить.

Коротше кажучи, залишається сумнівним, чи варто компанії обирати SAP своїм постачальником сховище даних. Є дуже серйозні ризики, з одного боку, і дуже мало винагород, з іншого. Але є ще одна причина, яка відлякує вибір SAP як постачальника сховище даних. Тому що кожна компанія повинна мати те саме сховище даних з усіх інших компаній? The сховище даних це серце конкурентної переваги. Якби кожна компанія прийняла те саме сховище даних було б важко, хоча й неможливо, досягти конкурентної переваги. SAP, здається, вважає, що a сховище даних його можна розглядати як файли cookie, і це ще одна ознака їхньої ментальності додатків «отримати дані».

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

Ці середовища включають такі дії, як обробка банківських кас, процеси бронювання авіаквитків, процеси страхових претензій тощо. Чим ефективнішою була система транзакцій, тим очевиднішою була потреба у відокремленні операційного процесу від DSS (системи підтримки прийняття рішень). Однак з кадровими та кадровими системами ви ніколи не стикаєтеся з великими обсягами операцій. І, звісно, ​​коли людину приймають на роботу чи залишають компанію, це є записом транзакції. Але порівняно з іншими системами, системи кадрів і персоналу просто не мають багато транзакцій. Тому в кадрових і кадрових системах не зовсім очевидно, що існує потреба в DataWarehouse. Багато в чому ці системи являють собою об'єднання систем DSS.

Але є ще один фактор, який необхідно враховувати, якщо ви маєте справу зі сховищами даних і PeopleSoft. У багатьох середовищах, i дані людських і особистих ресурсів є вторинними щодо основного бізнесу компанії. Більшість компаній займаються виробництвом, продажем, наданням послуг тощо. Людські ресурси та кадрові системи зазвичай є вторинними (або допоміжними) основним напрямком діяльності компанії. Тому це двозначно і незручно сховище даних окремо для кадрів і кадрової підтримки.

У цьому плані PeopleSoft дуже відрізняється від SAP. У SAP обов’язкова наявність a сховище даних. З PeopleSoft це не так однозначно. Для PeopleSoft сховище даних є необов’язковим.

Найкраще, що можна сказати про дані PeopleSoft - це те сховище даних можна використовувати для архівування i дані що стосуються старих людських і особистих ресурсів. Друга причина, чому компанія хоче використовувати a сховище даних a

Шкода середовища PeopleSoft полягає в дозволі та вільному доступі до інструментів аналізу дані від PeopleSoft. Але крім цих причин, можуть бути випадки, коли краще не мати сховища даних дані PeopleSoft.

Підводячи підсумок

Є багато ідей щодо будівництва а сховище даних в програмному забезпеченні ERP.
Деякі з них:

• ▪ Є сенс мати a сховище даних це як будь-що інше в галузі?
• ▪ Наскільки гнучким є ERP сховище даних Програмне забезпечення?
• ▪ ERP сховище даних програмне забезпечення може обробляти обсяг дані який розташований в асховище даних арена"?
• ▪ Що таке запис трасування, який виконує постачальник ERP, незважаючи на те, що це простий і недорогий, з точки зору часу, дані? (Яка історія постачальників ERP щодо доставки недорогих, своєчасних і легких до доступу даних?)
• ▪ Яке розуміння постачальником ERP архітектури DSS та корпоративної інформаційної фабрики?
• ▪ Постачальники ERP розуміють, як досягти дані в середовищі, а також зрозуміти, як їх експортувати?
• ▪ Наскільки постачальник ERP відкритий для інструментів сховища даних?
  Усі ці міркування необхідно враховувати, визначаючи, де розмістити сховище даних який прийматиме i дані ЕРП та ін дані. Загалом, якщо немає вагомих причин робити інакше, будівництво рекомендується сховище даних за межами середовища постачальника ERP. РОЗДІЛ 1 Огляд організації BI Ключові моменти:
  Інформаційні сховища працюють навпаки архітектури бізнес-аналітики (BI):
  Корпоративна культура та ІТ можуть обмежити успіх у розбудові організацій BI.

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

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

По суті, пасивний Dw, у кращому випадку, забезпечує лише i дані чистий і оперативний для асоціацій користувачів. Створення інформації та аналітичне розуміння повністю залежать від користувачів. Судіть, чи DW (Інформаційне сховище) успіх суб'єктивний. Якщо ми оцінюємо успіх за здатністю ефективно збирати, інтегрувати та очищати дані на передбачуваній основі, тоді так, DW має успіх. З іншого боку, якщо ми подивимося на збір, консолідацію та використання інформації організацією в цілому, то DW є провалом. DW надає невелику інформаційну цінність або взагалі її не має. Як наслідок, користувачі змушені задовольнятися, таким чином створюючи інформаційні бункери. У цьому розділі представлено комплексне уявлення про архітектуру компанії BI (Business Intelligence). Ми починаємо з опису BI, а потім переходимо до обговорення дизайну та розробки інформації, на відміну від простого надання інформації. дані користувачам. Потім обговорення зосереджено на розрахунку вартості ваших зусиль BI. На завершення ми визначимо, як IBM відповідає вимогам вашої організації до архітектури BI.

Опис архітектури BI організація

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

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

Мати правильні бізнес-інструменти означає мати чіткі відповіді на ключові питання, такі як:

• ▪ Хто з наших клієнти вони змушують нас заробляти більше чи вони змушують нас втрачати гроші?
• ▪ Де живуть наші найкращі клієнти у зв'язку з, щодо магазин/ склад, який вони відвідують?
• ▪ Які з наших продуктів і послуг можна продавати найбільш ефективно і кому?
• ▪ Які продукти можна продавати найбільш ефективно і кому?
• ▪ Яка кампанія продажу є найуспішнішою і чому?
• ▪ Які канали збуту для яких продуктів найбільш ефективні?
• ▪ Як ми можемо покращити стосунки з нашими найкращими людьми клієнти? Більшість компаній мають дані приблизні способи відповіді на ці запитання.
  Операційні системи генерують велику кількість продукту, клієнтів і дані ринку з точок продажу, бронювання, обслуговування клієнтів і систем технічної підтримки. Завдання полягає в тому, щоб отримати та використовувати цю інформацію. Багато компаній отримують прибуток лише від невеликих частин свого капіталу дані для стратегічного аналізу.
  I дані решта, часто в поєднанні з i дані отримана із зовнішніх джерел, таких як урядові звіти та інша придбана інформація, є золотою шахтою, що тільки чекає на дослідження, і дані їх просто потрібно уточнити в інформаційному контексті вашої організації.

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

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

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

Однак наразі велика частина такого типу інформації залишається в силосах дані осіб або відділів, які проводять аналіз. Організація в цілому майже не помітна для розуміння. Лише шляхом змішування цього типу інформаційного вмісту з вашою корпоративною базою даних ви зможете усунути інформаційні роз’єми та покращити середовище вашої бази даних.
Є дві основні перешкоди для розвитку організації BI.
По-перше, ми маємо проблему самої організації та її дисципліни.
Хоча ми не можемо допомогти зі змінами політики організації, ми можемо допомогти зрозуміти компоненти BI організації, її архітектуру та те, як технологія IBM сприяє її розвитку.
Друга перешкода, яку потрібно подолати, — відсутність інтегрованої технології та знання методу, який стосується всього простору BI, а не лише невеликого компонента.

IBM наближається до змін у технології інтеграції. Ви зобов’язані створити продуманий дизайн. Ця архітектура повинна бути розроблена з технологією, обраною для необмеженої інтеграції, або, принаймні, з технологією, яка відповідає відкритим стандартам. Крім того, керівництво вашої компанії має переконатися, що діяльність з BI виконується згідно з планом і не допускає розвитку інформаційних силосів, які виникають через корисливі програми чи цілі.
Це не означає, що середовище BI не чутливе до реагування на різні потреби та вимоги різних користувачів; натомість це означає, що реалізація цих індивідуальних потреб і вимог здійснюється на користь усієї організації BI.
Опис архітектури організації BI можна знайти на сторінці 9 на рисунку 1.1 Архітектура демонструє багате поєднання технологій і методів.
З традиційного погляду архітектура включає в себе наступні компоненти складу

Атомний шар(Atomic Layer).

Це основа, серце всієї DW і, отже, стратегічної звітності.
I дані зберігається тут збереже історичну цілісність, повідомляє о дані і включають похідні показники, а також очищаються, інтегруються та зберігаються за допомогою вилучення моделі.
Усі наступні використання цих дані і пов’язана інформація отримана з цієї структури. Це відмінне джерело для майнінгу дані і для звітів зі структурованими запитами SQL

Оперативний склад дані або звітної основи дані(Сховище оперативних даних (ODS) або звітність база даних.)

Це структура дані спеціально розроблений для технічної звітності.

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

Постанова зона.

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

Фінікові ринки.

Ця частина архітектури являє собою структуру дані використовується спеціально для OLAP. Наявність вітрин даних, якщо i дані зберігаються в схемах зірок, що перекриваються дані багатовимірний у реляційному середовищі або у файлах дані Конфіденційність, яка використовується певною технологією OLAP, такою як DB2 OLAP Server, не має значення.

Єдиним обмеженням є те, що архітектура полегшує використання дані багатовимірний.
Архітектура також включає критичні технології та методики Bi, які виділяються як:

Просторовий аналіз

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

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

Видобуток даних.

Видобуток дані дозволяє нашим компаніям збільшувати кількість клієнти, щоб передбачити тенденції продажів і дозволити керувати відносинами з клієнти (CRM), tra altre iniziative della BI.

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

Як зазначено в архітектурі BI, атомарний рівень Dwhouse, а також вітрини даних є чудовим джерелом дані для видобутку. Ці ж заклади також повинні бути одержувачами результатів екстракції, щоб забезпечити доступність для найширшої аудиторії.

Агенти.

Існують різні «агенти», які перевіряють клієнта на кожну точку, наприклад, операційні системи компанії та саму dw. Ці агенти можуть бути вдосконаленими нейронними мережами, навченими дізнаватися про тенденції в кожній точці, як-от майбутній попит на продукт на основі стимулювання збуту, механізми на основі правил реагувати на дате сукупність обставин або навіть прості агенти, які повідомляють про винятки «вищим керівникам». Ці процеси зазвичай відбуваються в реальному часі і, отже, повинні бути тісно пов'язані з їх рухом дані. Всі ці структури з дані, технології та техніки гарантують, що ви не будете ночувати, створюючи організацію свого BI.

Ця діяльність розвиватиметься поетапно для невеликих точок.
Кожен крок є незалежним проектом і називається ітерацією у вашій ініціативі DW або BI. Ітерації можуть включати впровадження нових технологій, починаючи з нових методів, додаючи нові структури дані , завантаження i дані додатково або з розширенням аналізу вашого середовища. Більш детально цей параграф розглядається в розділі 3.

Окрім традиційних структур DW та інструментів BI, існують інші функції вашої організації BI, які вам потрібно розробити, наприклад:

Точки контакту з клієнтами (Customer touch точок).

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

Основи дані оперативні та користувацькі асоціації (Опер

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

Аналітики. (Аналітики)

Основним бенефіціаром середовища BI є аналітик. Саме йому вигідний поточний видобуток дані оперативні, інтегровані з різними джерелами дані , доповнений такими функціями, як географічний аналіз (геокодування) і представлений у технологіях BI, які забезпечують вилучення, OLAP, розширені звіти SQL і географічний аналіз. Основним аналітичним інтерфейсом для середовища звітності є портал BI.

Однак аналітик не єдиний, хто виграє від архітектури BI.
Керівники, великі асоціації користувачів і навіть члени, постачальники тощо клієнти повинні знайти переваги в бізнесі BI.

Петля зворотного живлення.

Архітектура BI – це навчальне середовище. Характерним принципом розвитку є можливість стійких структур дані оновлюватися відповідно до використовуваної технології BI та дій користувача. Прикладом є оцінка клієнтів.

Якщо відділ продажів моделює бали клієнтів для використання нової послуги, тоді відділ продажів не повинен бути єдиною групою, яка отримує користь від послуги.

Натомість вилучення моделі має виконуватися як природна частина потоку даних усередині підприємства, а оцінки клієнтів мають стати невід’ємною частиною інформаційного контексту сховища, видимою для всіх користувачів. IBM Suite, орієнтований на Bi-bI, включаючи DB2 UDB, DB2 OLAP Server, включає більшість основних технологічних компонентів, визначених на малюнку 1.1.

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

Надання інформаційного контенту (Надання інформаційне наповнення)

Проектування, розробка та впровадження вашого BI-середовища – складне завдання. Дизайн повинен охоплювати поточні та майбутні вимоги бізнесу. Архітектурне креслення має бути повним, щоб включати всі висновки, зроблені на етапі проектування. Виконання має залишатися відданим єдиній меті: розробці архітектури BI, яка формально представлена ​​в проекті та базується на бізнес-вимогах.

Особливо важко стверджувати, що дисципліна забезпечить відносний успіх.
Це просто, оскільки ви не розробляєте BI-середовище відразу, а робите це невеликими кроками з часом.

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

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

не випадкова подія, а скоріше ретельно сконструйований «добре продуманий». опера мистецтва як мозаїки змішаних технологій.

Дизайн інформаційного наповнення

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

Навіть до початку будь-якого офіційного проектування планувальник проекту часто може відразу визначити один або два компоненти.
Однак баланс компонентів, які можуть знадобитися для вашої архітектури, знайти нелегко. На етапі проектування основна частина архітектури пов’язує сеанс розробки додатків (JAD) із метою визначення бізнес-вимог.

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

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

Однак існують інші типи бізнесу, які нам потрібно планувати. Коли бізнес-вимоги викладені у формі стратегічних бізнес-запитань, експерту-проектувальнику легко розрізнити міри/факти та розмірні вимоги.

Якщо користувачі JAD не знають, як викласти свої вимоги у формі бізнес-проблеми, дизайнер часто надасть приклади, щоб швидко розпочати сеанс збору вимог.
Експерт-дизайнер може допомогти користувачам зрозуміти не тільки стратегічний трейдинг, але й те, як його формувати.
Підхід до збору вимог розглядається в розділі 3; поки що ми просто хочемо вказати на необхідність проектування для всіх типів вимог BI.

Стратегічна бізнес-проблема — це не лише бізнес-вимога, але й підказка до дизайну. Якщо вам потрібно відповісти на багатовимірне запитання, то ви повинні запам’ятати, представити i дані розмірний, і якщо потрібно запам'ятати дані Багатовимірний, ви повинні вирішити, який тип технології чи техніки ви збираєтеся використовувати.

Ви реалізуєте зарезервовану схему кубічної зірки чи обидва? Як бачите, навіть проста бізнес-задача може істотно вплинути на дизайн. Але ці типи бізнес-вимог є звичайними і зрозумілими, принаймні дизайнерам і планувальникам із досвідом проектування.

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

Але які вимоги не зрозумілі ні користувачам, ні команді Dw? Вам колись знадобиться просторовий аналіз?
Моделі майнінгу дані чи будуть вони необхідною частиною вашого майбутнього? Хто знає?

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

Більш проблематично стає, коли дизайнер і розробник не можуть розпізнати застосування однієї з цих передових, але критично важливих технологій.
Як ми часто чули від дизайнерів: «Ну, чому б нам не відкласти це, поки не отримаємо іншу річ? «Їх справді цікавлять пріоритети чи вони просто уникають незрозумілих їм вимог? Швидше за все, це остання гіпотеза. Припустімо, ваша команда продажів повідомила бізнес-вимогу, як зазначено на малюнку 1.3, як ви бачите, вимога оформлена у формі бізнес-проблеми. Різниця між цією проблемою та типовою розмірною проблемою полягає в відстані. У цьому випадку відділ продажів хоче щомісяця знати загальний обсяг продажів продуктів, складів і клієнти які проживають у межах 5 миль від складу, де вони купують.

На жаль, дизайнери чи архітектори можуть просто ігнорувати просторову складову, кажучи: «У нас є клієнт, продукт і дані депозиту. Дотримуймося дистанції до наступної ітерації.

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

Дизайн для інформаційного контексту (Дизайн інформаційного наповнення)

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

Однак усі відомі вимоги відображені в проекті, тому, коли нам потрібно буде впровадити певну технологію, ми будемо готові це зробити. Дещо в проекті відображатиме традиційне мислення.

Цей набір дані використовується для підтримки подальшого використання дані вимірів, керуючись бізнес-проблемами, які ми визначили. У міру формування додаткових документів, наприклад, проектної розробки дані, ми почнемо формалізувати, як i дані вони поширюються в навколишньому середовищі. Ми з’ясували необхідність представлення i дані розмірним способом, розділивши їх (відповідно до конкретних потреб) на вітрини даних.

Наступне запитання, на яке потрібно відповісти: як будуть створюватися ці вітрини даних?
Ви будуєте зірки, щоб підтримувати куби, чи тільки куби, чи лише зірки? (або правильні кубики, або правильні зірочки). Створіть архітектуру для залежних вітрин даних, які вимагають атомарного рівня для всіх дані ви набуваєте? Дозволити незалежним вітринам даних отримати i дані безпосередньо з операційних систем?

Яку технологію Cube ви спробуєте стандартизувати?

У вас величезна кількість богів дані необхідні для розмірного аналізу чи вам потрібні кубики від вашої національної служби продажів щотижня чи обидва? Чи створюєте ви щось настільки потужне, як DB2 OLAP Server для фінансів або куби Cognos PowerPlay для вашої торгової організації, чи обидва? Це важливі архітектурні рішення, які відтепер впливатимуть на ваше середовище BI. Так, ви встановили потребу в OLAP. Тепер як ви будете виконувати таку техніку та технологію?

Як деякі з найпередовіших технологій впливають на ваш дизайн? Припустімо, ви визначили потребу в просторі у вашій організації. Тепер ви повинні згадати випуски архітектурного креслення, навіть якщо ви не плануєте створювати просторові компоненти протягом кількох місяців. Архітектор повинен проектувати сьогодні, виходячи з того, що потрібно. Передбачити потребу в просторовій аналітиці, яка генерує, зберігає, виконує та надає доступ до неї дані просторовий. Це, у свою чергу, має служити обмеженням щодо типу технології програмного забезпечення та специфікацій платформи, які ви можете розглянути на даний момент. Наприклад, система адміністрування с база даних реляційний рівень (RDBMS), який ви виконуєте для свого атомарного рівня, повинен мати доступний надійний просторовий екстент. Це забезпечить максимальну продуктивність під час використання геометрії та просторових об’єктів у ваших аналітичних програмах. Якщо ваша RDBMS не може впоратися з дані (просторово-центричний) внутрішньо, тому вам доведеться встановити a база даних (просторово-центричний) зовнішній. Це ускладнює керування проблемами та погіршує вашу загальну продуктивність, не кажучи вже про додаткові проблеми, створені для ваших адміністраторів баз даних, оскільки вони, ймовірно, мають мінімальне розуміння основ дані просторовий також. З іншого боку, якщо ваш механізм RDMBS обробляє всі просторові компоненти, а його оптимізатор усвідомлює особливі потреби (наприклад, індексування) просторових об’єктів, тоді ваші администратори баз даних можуть легко впоратися з керуванням проблемами, а ви зможете максимізувати продуктивність.

Крім того, вам потрібно налаштувати проміжну область і рівень атомарного середовища, щоб включити очищення адреси (a

ключовий елемент просторового аналізу), а також подальше збереження космічних об’єктів. Послідовність випусків малюнків продовжується тепер, коли ми ввели поняття чіткого напряму. З одного боку, ця програма визначатиме тип програмного забезпечення, необхідного для ваших зусиль ETL.

Вам потрібні такі продукти, як Trillium, щоб надати йому чисту адресу, чи постачальник ETL на ваш вибір, щоб надати таку функцію?
Наразі важливо, щоб ви оцінили рівень проектування, який необхідно завершити, перш ніж розпочати впровадження свого складу. Наведені вище приклади повинні продемонструвати безліч проектних рішень, які повинні слідувати за визначенням будь-якої конкретної бізнес-вимоги. Якщо прийнято правильно, ці проектні рішення сприяють взаємозалежності між фізичними структурами вашого середовища, вибором використовуваної технології та потоком розповсюдження інформаційного вмісту. Без цієї традиційної архітектури BI ваша організація буде залежати від хаотичного змішування існуючих технологій, у кращому випадку нещільно з’єднаних разом для забезпечення видимої стабільності.

Підтримувати інформаційне наповнення

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

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

статичні звіти та OLAP, чи відмінності між ROLAP та OLAP? Чи один із членів вашої команди чітко розуміє, як видобувати та як це може вплинути на сховище або як сховище може підтримувати продуктивність видобування? Член команди розуміє цінність дані космічна чи агентна технологія? Чи є у вас хтось, хто цінує унікальне застосування інструментів ETL порівняно з технологією брокера повідомлень? Якщо у вас його немає, придбайте його. BI набагато більший за нормалізований атомарний рівень, OLAP, зіркові схеми та ODS.

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

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

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

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

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

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

Дисципліна також є темою, яка повинна розглядатися всією організацією і зазвичай встановлюється та доручається керівникам.
Чи готові менеджери дотримуватися розробленого підходу? Підхід, який обіцяє створити інформаційний контент, який зрештою принесе цінність усім сферам діяльності підприємства, але, можливо, ставить під загрозу індивідуальні чи департаментські плани? Пам’ятайте вислів «Думати про все важливіше, ніж думати про одне». Цей вислів справедливий для організацій BI.

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

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

Короткострокові та довгострокові цілі

Архітектори та дизайнери проектів повинні формалізувати довгострокове бачення загальної архітектури та плани розвитку в організації BI. Це поєднання короткострокового прибутку та довгострокового планування представляє дві сторони зусиль BI. Короткостроковий прибуток — це аспект BI, який пов’язаний з ітераціями вашого складу.

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

Обґрунтуйте свої зусилля з BI

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

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

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

У цьому полягає проблема створення BI: як ви виправдаєте інвестиції? Якщо саме місце зберігання не має внутрішньої цінності, розробники проекту повинні дослідити, визначити та формалізувати переваги, отримані тими особами, які використовуватимуть склад для покращення конкретних бізнес-процесів або цінності захищеної інформації, або обох.

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

Підключіть свій проект, щоб дізнатися про Ділові запити

Надто часто планувальники проектів намагаються пов’язати вартість складу з аморфними цілями підприємства. Заявляючи, що «цінність складу базується на нашій здатності задовольняти стратегічні запити», ми приємно відкриваємо дискусію. Але одного цього недостатньо, щоб визначити, чи є сенс інвестувати в інвентар. Найкраще пов’язати складські ітерації з конкретними відомими бізнес-вимогами.

Вимірювання ROI

Розрахувати рентабельність інвестицій у складських умовах може бути особливо складно. Особливо важко, якщо перевага

Принцип конкретного повторення - це те, що не відчутно або легко виміряти. Одне дослідження показало, що користувачі бачать дві основні переваги ініціатив BI:

• ▪ Створити здатність приймати рішення
• ▪ Створити доступ до інформації
  Ці переваги є м’якими (або помірними). Легко зрозуміти, як ми можемо розрахувати рентабельність інвестицій, виходячи з таких серйозних (або значних) переваг, як зниження транспортних витрат, але як ми вимірюємо здатність приймати кращі рішення?
  Це, безперечно, виклик для планувальників проектів, коли вони намагаються переконати компанію інвестувати в певний склад. Збільшення продажів або зменшення витрат більше не є центральними темами, що рухають середовищем BI.
  Натомість ви розглядаєте бізнес-запити щодо кращого доступу до інформації, щоб певний відділ міг швидше приймати рішення. Це стратегічні чинники, які однаково важливі для підприємства, але більш неоднозначні та їх важче охарактеризувати в реальних показниках. У цьому випадку розрахунок рентабельності інвестицій може бути оманливим, якщо не недоречним.
  Планувальники проекту повинні мати можливість продемонструвати відчутну цінність для керівників, щоб вирішити, чи варті інвестиції в певну ітерацію. Однак ми не пропонуватимемо новий метод розрахунку рентабельності інвестицій, а також не будемо наводити жодних аргументів за чи проти нього.
  Існує багато доступних статей і книг, які обговорюють основи розрахунку ROI. Ви можете досліджувати такі спеціальні цінні пропозиції, як вартість інвестування (VOI), які пропонують такі групи, як Gartner. Натомість ми зосередимося на основних аспектах будь-якої рентабельності інвестицій або інших ціннісних пропозицій, які вам потрібно розглянути. Застосування ROI Крім аргументу про «тверді» переваги проти «м’яких» переваг, пов’язаних із зусиллями BI, існують інші питання, які слід враховувати під час застосування ROI. Наприклад:

Приписуйте надто багато заощаджень зусиллям DW, які все одно прийдуть
Припустімо, ваша компанія перейшла з архітектури мейнфрейму на розподілене середовище UNIX. Таким чином, будь-яка економія, яка може (чи не може бути) реалізована в результаті цих зусиль, не повинна бути віднесена виключно до складу, якщо взагалі (?).

Не враховувати все – це дорого. І є багато речей, які слід враховувати. Розглянемо наступний список:

• ▪ Початкова вартість, включаючи техніко-економічне обґрунтування.
• ▪ Вартість виділеного обладнання з відповідним сховищем і комунікаціями
• ▪ Вартість програмного забезпечення, включаючи управління дані і розширення клієнт/сервер, програмне забезпечення ETL, технології DSS, інструменти візуалізації, програми для планування та робочого процесу, а також програмне забезпечення для моніторингу.
• ▪ Вартість проектування конструкції дані, зі створенням та оптимізацією
• ▪ Вартість розробки програмного забезпечення, безпосередньо пов’язана з зусиллями BI
• ▪ Вартість підтримки на місці, включаючи оптимізацію продуктивності, включаючи контроль версій програмного забезпечення та довідкові операції Застосуйте рентабельність інвестицій «Великого вибуху». Будівництво складу одним гігантським зусиллям приречене на провал, тому навіть розрахуйте рентабельність інвестицій для ініціативи великого підприємства. Пропозиція дивує, і планувальники продовжують робити слабкі спроби оцінити вартість усіх зусиль. Чому планувальники намагаються оцінити бізнес-ініціативу в грошовому вираженні, якщо загальновідомо та загальновизнано, що оцінити конкретні повтори важко? Як це можливо? За кількома винятками це неможливо. Не робіть цього. Тепер, коли ми визначили, чого не слід робити під час розрахунку рентабельності інвестицій, ось кілька пунктів, які допоможуть нам створити надійний процес для оцінки цінності ваших зусиль BI.

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

Зменште ROI на частини, які можна ідентифікувати. Необхідним кроком до обґрунтованого розрахунку ROI є зосередження цього розрахунку на конкретному проекті. Потім це дозволить вам оцінити вартість на основі конкретних вимог бізнесу

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

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

Зменшіть витрати та вигоди в неминучому прибутку. Це найкращий спосіб базувати свої оцінки на чистій поточній вартості (NPV), а не намагатися передбачити майбутню вартість майбутніх прибутків.

Зведіть до мінімуму час розподілу рентабельності інвестицій. Він добре задокументований протягом тривалого періоду часу, протягом якого він використовувався у вашій ROI.

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

Визначте повторюваний процес. Це має вирішальне значення для розрахунку будь-якої довгострокової вартості. Єдиний повторюваний процес повинен бути задокументований для всіх наступних послідовностей проекту.

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

Питання щодо переваг ROI

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

• Як би ви оцінили розуміння дані стежити за цим проектом вашої компанії?
• Як би ви оцінили покращення процесу в результаті цього проекту?
• Як би ви виміряли вплив нових ідей і висновків, які стали доступними завдяки цій ітерації
• Яким був вплив нових і продуктивних обчислювальних середовищ у результаті отриманих знань? Якщо відповідей на ці запитання небагато, можливо, компанія не варта вкладених інвестицій. Питання з високою оцінкою вказують на значне підвищення цінності та повинні служити орієнтиром для подальшого дослідження. Наприклад, висока оцінка за вдосконалення процесу має спонукати розробників до вивчення того, як процеси були вдосконалені. Ви можете виявити, що деякі або всі отримані прибутки є відчутними, і тому можна легко застосувати грошову оцінку. Отримати максимум від першої ітерації склад Найбільший результат ваших корпоративних зусиль часто досягається на перших кількох ітераціях. Ці перші зусилля традиційно створюють найкорисніший інформаційний вміст для громадськості та допомагають створити технологічну основу для наступних програм BI. Зазвичай кожна наступна підпослідовність дані складських проектів приносять усе менше додаткової вартості підприємству в цілому. Це особливо вірно, якщо ітерація не додає нових тем або не відповідає потребам нової спільноти користувачів.

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

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

Але ці перші кроки приносять найбільшу цінність, тому розробникам проектів часто доводиться виправдовувати інвестиції.
Проекти, створені після вашої BI-ініціативи, можуть мати нижчі (порівняно з першими) прямі витрати, але приносити меншу цінність для компанії.

А власникам організацій варто почати думати про викидання накопичень дані і менш актуальні технології.

Інтелектуальний аналіз даних: видобуток Давати

Численні архітектурні компоненти вимагають варіацій у технологіях і техніках інтелектуального аналізу даних.
наприклад, різні «агенти» для вивчення об’єктів інтересу клієнти, операційних систем компанії та для самої dw. Ці агенти можуть бути передовими нейронними мережами, навченими на тренди POT, такі як майбутній попит на продукт на основі стимулювання збуту; двигуни на основі правил реагують на набір дате обставини, наприклад, медичний діагноз і рекомендації щодо лікування; або навіть простих агентів із роллю звітності про винятки топ-менеджерам. Зазвичай ці процеси екстракції дані si

перевірити в реальному часі; тому вони повинні бути повністю об'єднані з рухом дані стессі.

Онлайн аналітична обробка Обробка

Аналітика онлайн

Здатність нарізати, нарізати кубиками, згортати, деталізувати та виконувати аналіз
що-якщо, знаходиться в межах, у центрі уваги технологічного набору IBM. Наприклад, для DB2 існують функції онлайн-аналітичної обробки (OLAP), які передають розмірний аналіз у програмний механізм. база даних те ж саме.

Ці функції додають багатомірну корисність SQL, одночасно використовуючи всі переваги природної частини DB2. Іншим прикладом інтеграції OLAP є засіб вилучення DB2 OLAP Server Analyzer. Ця технологія дозволяє швидко й автоматично аналізувати куби OLAP-сервера DB2, щоб знаходити та створювати значення значень дані незвичайний або несподіваний у всьому кубі для бізнес-аналітика. І, нарешті, функції DW Center надають архітекторам засоби для керування, серед іншого, профілем куба сервера DB2 OLAP як природної частини процесів ETL.

Просторовий аналіз. Просторовий аналіз

Простір представляє половину аналітичних опор (лідів), необхідних для панорами
аналітичний широкий (час представляє іншу половину). Атомарний рівень сховища, зображений на малюнку 1.1, включає як час, так і простір. Мітки часу прив’язують аналізи за часом, а інформацію про адресу – за простором. Мітки часу проводять аналіз за часом, а інформація про адресу проводить аналіз за простором. На діаграмі показано геокодування – процес перетворення адрес у точки на карті або точки в просторі, щоб такі поняття, як відстань і всередині/зовні можна було використовувати в аналізі – проводиться на атомарному рівні та просторовий аналіз, доступний для аналітик. IBM надає просторові розширення, розроблені спільно з Інститутом дослідження систем навколишнього середовища (ESRI). база даних DB2, щоб космічні об’єкти могли зберігатися як звичайна частина база даних реляційний. DB2

Spatial Extenders також надають усі розширення SQL, щоб скористатися перевагами просторового аналізу. Наприклад, розширення SQL для запитів
відстань між адресами або те, чи знаходиться точка всередині чи поза визначеною багатокутною областю, є аналітичним стандартом із Spatial Extender. Додаткову інформацію див. у розділі 16.

Database-Resident Tools Інструменти Database-Мешканець

DB2 має багато постійних BI-функцій SQL, які допомагають у виконанні аналізу. До них належать:

• Функції рекурсії для виконання аналізу, наприклад «пошук усіх можливих маршрутів польоту з Сан Франциско a Нью-Йорк".
• Аналітичні функції для ранжирування, кумулятивні функції, куб і зведення для полегшення завдань, які зазвичай виникають лише за допомогою технології OLAP, тепер є природною частиною двигуна база даних
• Можливість створення таблиць, що містять результати
  Продавці база даних лідери змішують більше можливостей BI база даних стессо.
  Основні постачальники база даних вони змішують більше можливостей BI в база даних стессо.
  Це забезпечує кращу продуктивність і більше варіантів виконання для рішень BI.
  Особливості та функції DB2 V8 детально розглядаються в наступних розділах:
  Технічна архітектура та основи керування даними (розділ 5)

• Основи DB2 BI (розділ 6)
• Матеріалізовані таблиці запитів DB2 (Розділ 7)
• Функції OLAP DB2 (Розділ 13)
• DB2 Enhanced BI Features and Functions (Розділ 15) Спрощена система доставки даних Система доставки дані спрощений

Архітектура, зображена на малюнку 1.1, включає численні структури дані фізичний. Один – склад ім дані операційний. Загалом, ODS є предметно-орієнтованим, інтегрованим і поточним об’єктом. Ви б створили ODS для підтримки, наприклад, офісу продажів. Продажі ОРВ доповнять дані з багатьох різних систем, але збереже лише, наприклад, сьогоднішні транзакції. ODS також можна оновлювати багато разів на день. У той же час процеси підштовхують дані інтегровані в інші програми. Ця структура спеціально розроблена для інтеграції дані поточний і динамічний і може бути вірогідним кандидатом для підтримки аналітики в реальному часі, наприклад надання послуг агентам клієнти поточну інформацію про продажі клієнта шляхом отримання інформації про тенденції продажів із самого складу. Інша структура, показана на малюнку 1.1, є формальним станом для dw. Це не тільки місце для виконання необхідної інтеграції, якість дані, і про перетворення дані вхідного складу, але також є надійним і тимчасовим складом для дані репліки, які можна використовувати в аналізах у реальному часі. Якщо ви вирішите використовувати ODS або проміжну зону, один із найкращих інструментів для заповнення цих структур дані використання різних операційних джерел є гетерогенним розподіленим запитом DB2. Ця можливість надається додатковою функцією DB2 під назвою DB2 Relational Connect (тільки для запитів) і через DB2 DataJoiner (окремий продукт, який надає можливість запиту, вставки, оновлення та видалення до різнорідних розподілених RDBMS).

Ця технологія дозволяє архітекторам дані щоб зв'язати дані виробництво з аналітичними процесами. Технологія не тільки може адаптуватися практично до будь-яких вимог реплікації, які можуть виникнути з аналітикою в реальному часі, але також може підключатися до широкого спектру баз даних дані найпопулярніші, включаючи DB2, Oracle, Sybase, SQL Server, Informix та інші. DB2 DataJoiner можна використовувати для заповнення структури дані формальна як ODS або навіть постійна таблиця, представлена ​​на складі, призначена для швидкого відновлення миттєвих оновлень або для продажу. Звичайно, ці самі структури дані можна заповнити за допомогою

ще одна важлива технологія, призначена для відтворення дані, IBM DataPropagator Relational. (DataPropagator є окремим продуктом для центральних систем. DB2 UNIX, Linux, Windows і OS/2 містять служби реплікації даних дані як стандартна функція).
Ще один спосіб пересування дані На підприємстві працює інтегратор корпоративних програм, також відомий як брокер повідомлень. Ця унікальна технологія забезпечує неперевершений контроль для націлювання та переміщення дані навколо компанії. IBM має найпоширеніший брокер повідомлень, MQSeries, або різновид продукту, який включає вимоги e-commerce, IBM WebSphere MQ.
Per più discussione su come sfruttare MQ per sostenere un magazzino e un ambiente BI, visitare веб-сайт del libro. Per ora, è sufficiente dire che questa tecnologia è un mezzo eccellente per catturare e trasformare (utilizzando MQSeries Integrator) дані центровані (цільові) оператори, набрані для рішень BI. Технологія MQ була інтегрована та упакована в UDB V8, що означає, що чергами повідомлень тепер можна керувати так, ніби вони були таблицями DB2. Концепція зварювання повідомлень у черзі та всесвіту база даних реляційні напрями до потужного середовища доставки дані.

Нульова затримка. Нульова затримка

Кінцевою стратегічною метою IBM є аналіз без затримок. Як визначено
Gartner, система BI повинна мати можливість робити висновки, асимілювати та надавати інформацію аналітикам на вимогу. Проблема, звичайно, полягає в тому, як змішати дані поточний і в реальному часі з необхідною історичною інформацією, такою як i дані пов’язаний шаблон/тенденція або витягнуте розуміння, наприклад, профілювання клієнтів.

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

Досягнення нульової затримки насправді залежить від двох основних механізмів:

• Повне об'єднання дані які аналізуються за допомогою усталених методів та інструментів, створених BI
• Система доставки дані Ці передумови для нульової затримки нічим не відрізняються від двох цілей, поставлених IBM і описаних вище. Близьке спаровування дані Це частина програми бездоганної інтеграції IBM. І створити систему доставки дані Ефективність повністю залежить від доступної технології, яка спрощує процес доставки дані. У результаті дві з трьох цілей IBM мають вирішальне значення для реалізації третьої. IBM свідомо розвиває свою технологію, щоб гарантувати, що нульова затримка є реальністю для складських зусиль. Анотація / Узагальн Організація BI надає дорожню карту для створення вашого середовища
  ітеративно. Його потрібно налаштувати відповідно до потреб вашого бізнесу, як поточних, так і майбутніх. Без широкого архітектурного бачення складські ітерації є чимось більшим, ніж випадковими реалізаціями центрального складу, які мало сприяють створенню широкого інформаційного підприємства. Першою перешкодою для керівників проектів є те, як виправдати інвестиції, необхідні для розвитку організації BI. Хоча розрахунок рентабельності інвестицій залишається основою впровадження складів, його стає все складніше точно передбачити. Це призвело до інших методів визначення того, чи ви отримуєте свої гроші. Наприклад, цінність інвестицій2 (VOI) рекламується як рішення. Це покладено на архітекторів с дані і планувальники проектів навмисно генерують і надають інформацію асоціаціям користувачів, а не просто надають їм послуги дані. Між ними є величезна різниця. Інформація – це те, що впливає на прийняття рішень і ефективність; відносно, я дані вони є будівельними блоками для отримання цієї інформації.

Навіть якщо я критично ставлюся до джерела дані Щоб відповідати бізнес-запитам, середовище BI має виконувати більшу роль у створенні інформаційного контенту. Ми повинні вжити додаткових заходів, щоб очистити, інтегрувати, трансформувати або іншим чином створити інформаційний вміст, на який користувачі зможуть діяти, а потім ми повинні переконатися, що ці дії та рішення, де це розумно, відображаються в середовищі BI. Якщо ми перемістимо склад лише для обслуговування дані, гарантується, що асоціації користувачів створять інформаційний вміст, необхідний для виконання дій. Це гарантує, що їхня громада зможе приймати кращі рішення, але підприємство страждає від браку знань, які вони використовували. Dato Оскільки архітектори та планувальники проектів ініціюють конкретні проекти в середовищі BI, вони залишаються підзвітними підприємству в цілому. Простий приклад цієї двосторонньої характеристики ітерацій BI можна знайти в джерелі дані. Всі дані отримані для конкретних бізнес-запитів повинні бути заповнені на першому атомарному рівні. Це забезпечує розробку інформаційного активу підприємства, а також управління, вирішення конкретних запитів користувачів, визначених у ітерації.

WhatisaDataWarehouse?

Інформаційне сховище це серце архітектури інформаційних систем з 1990 року та підтримує інформаційні процеси, пропонуючи надійну інтегровану платформу дані історичні дані взяті за основу для подальшого аналізу. THE сховище даних вони пропонують легку інтеграцію у світі несумісних прикладних систем. Інформаційне сховище це перетворилося на тренд. Інформаційне сховище організувати та зберігати i дані необхідні для інформаційно-аналітичних процесів, що базуються на тривалій історичній часовій перспективі. Все це тягне за собою значні та постійні зобов'язання щодо будівництва та обслуговування сховище даних.

Отже, що таке a сховище даних? сховище даних і:

• ▪ предметно-орієнтований
• ▪ інтегрована система
• ▪ варіант часу
• ▪ енергонезалежний (не можна стерти)

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

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

ПРЕДМЕТНА ОРІЄНТАЦІЯ ОРІЄНТАЦІЯ ТЕМАТИЧНИЙ

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

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

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

Відмінності між вибором застосування процесу/функції та вибором предмета також виявляються як відмінності у змісті дані на детальному рівні. THE дані dw не включають i дані які не використовуватимуться для процесу DSS під час додатків

оперативна орієнтація дані містять i дані щоб негайно задовольнити функціональні вимоги/вимоги до обробки, які можуть або не можуть бути корисними для аналітика DSS.
Інший важливий спосіб, у якому операційно-орієнтовані програми дані відрізняються від дані dw є в звітах dei дані. Я дані операції підтримують безперервний зв’язок між двома або більше таблицями на основі активного бізнес-правила. THE дані dw перетинають спектр часу, і зв’язків, знайдених у dw, багато. Багато торгових правил (і, відповідно, багато відносин між дані ) представлені на складі дані між двома або більше столами.

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

ІНТЕГРАЦІЯ ІНТЕГРАЦІЯ

Найважливішим аспектом середовища dw є те, що i дані знайдені в dw легко інтегруються. ЗАВЖДИ. БЕЗ ВИНЯТКІВ. Сама суть середовища dw полягає в тому, що i дані що містяться в складських межах, інтегровані.

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

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

Кодування: Кодування:

Розробники додатків по-різному обирали кодування поля – статі. Дизайнер представляє стать як «м» і «ж». Інший дизайнер представляє стать як «1» і «0». Інший дизайнер представляє стать як «х» і «у». Інший дизайнер представляє стать як «чоловічий» і «жіночий». Не має великого значення, яким чином стать потрапляє в DW. «М» і «Ж», мабуть, такі ж гарні, як і вся п’єса.

Важливо те, що з якого б джерела не виникло статеве поле, це поле потрапляє в DW у послідовному інтегрованому стані. Отже, коли поле завантажується в DW із програми, де воно було представлено у форматі «M» і «F», дані необхідно конвертувати у формат DW.

Вимірювання атрибутів: вимірювання Атрибути:

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

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

Якою б не була тема дизайну, результат однаковий – i дані повинні зберігатися в DW єдиним і глобально прийнятним способом, навіть якщо базові операційні системи зберігають їх по-різному дані.

Коли аналітик DSS дивиться на DW, метою аналітика має бути використання дані які знаходяться на складі,

а не сумніватися в достовірності чи послідовності дані.

ЧАСОВА ВАРІАНЦІЯ

Все дані у DW вони точні до певного моменту часу. Ця основна характеристика в дані у DW дуже відрізняється від тих дані знайдені в робочому середовищі. THE дані операційного середовища такі ж точні, як і на момент доступу. Іншими словами, в операційному середовищі, коли здійснюється доступ до диска дані, очікується, що він відображатиме точні значення на момент доступу. Тому що я дані у DW є точними як у певний момент часу (тобто не «прямо зараз»), сказано, що я дані знайдені в DW є «часовою дисперсією».
Часова дисперсія дані DW згадується різними способами.
Найпростіший спосіб полягає в тому, що i дані DW представляють дані протягом тривалого періоду – від п’яти до десяти років. Часовий горизонт, представлений для операційного середовища, набагато коротший, ніж сьогоднішні поточні значення від шістдесяти дев'яноста
Програми, які повинні добре функціонувати та бути доступними для обробки транзакцій, повинні мати мінімальну кількість дані якщо вони дозволяють будь-який ступінь гнучкості. Таким чином, робочі програми мають короткий часовий горизонт, як тема розробки аудіопрограм.
Другий спосіб появи «часової дисперсії» у DW — це структура ключа. Кожна ключова структура в DW містить, неявно чи явно, елемент часу, наприклад день, тиждень, місяць тощо. Елемент часу майже завжди знаходиться в нижній частині об’єднаного ключа, знайденого в DW. У таких випадках елемент часу буде існувати неявно, як-от у випадку, коли весь файл дублюється наприкінці місяця чи кварталу.
Третій спосіб відображення дисперсії часу полягає в тому, що i дані DW після правильної реєстрації неможливо оновити. THE дані DW для всіх практичних цілей є довгою серією миттєвих знімків. Звичайно, якщо знімки були зроблені неправильно, знімки можна змінити. Але якщо припустити, що знімки зроблені правильно, вони не будуть змінені, щойно зроблені. В деяких

У деяких випадках модифікація знімків у DW може бути неетичною або навіть недійсною. THE дані оперативні, будучи точними на момент доступу, їх можна оновлювати за потреби.

ЕНЕРГОНЕТКИЙ

Четвертою важливою характеристикою DW є його енергонезалежність.
Оновлення, вставки, видалення та модифікації регулярно вносяться до операційних середовищ на основі кожного запису. Але основні маніпуляції з дані які потрібні в DW, набагато простіше. Є лише два види операцій, які відбуваються в DW – початкове завантаження дані і доступ до дані. Оновлення немає дані (у загальному розумінні оновлення) у DW як звичайна операція обробки. Є кілька дуже потужних наслідків цієї базової різниці між операційною обробкою та обробкою DW. На рівні проектування необхідність бути обережним щодо аномального оновлення не є фактором у DW, оскільки оновлення дані не здійснюється. Це означає, що на фізичному рівні проектування можна мати свободу для оптимізації доступу дані, зокрема в роботі з темами фізичної нормалізації та денормалізації. Іншим наслідком простоти операцій DW є базова технологія, яка використовується для запуску середовища DW. Необхідність підтримки вбудованих оновлень записів за записами (як це часто буває з операційною обробкою) вимагає, щоб технологія мала дуже складну основу під уявною простотою.
Технологія, яка підтримує резервне копіювання та відновлення, транзакції та цілісність дані виявлення та усунення тупикових блокувань досить складне й не є необхідним для обробки DW. Характеристики DW, проектна спрямованість, інтеграція дані в DW, дисперсія часу та простота керування дані, все це призводить до середовища, яке дуже, дуже відрізняється від класичного операційного середовища. Джерело майже всіх дані DW є робочим середовищем. Спокусливо думати, що існує величезна надмірність дані між двома середовищами.
Насправді, перше враження, яке складається у багатьох людей, це велика надмірність дані між робочим середовищем і середовищем о

DW. Таке тлумачення є поверхневим і свідчить про нерозуміння того, що відбувається в DW.
Фактично є мінімум надмірності дані між робочим середовищем і i дані DW. Розглянемо наступне: I дані їх фільтрують дате перемикання з робочого середовища на середовище DW. багато дані вони ніколи не виходять за межі робочого середовища. Крім того, що я дані які необхідні для обробки DSS, знаходять свій напрямок у середовищі

▪ часовий горизонт дані воно дуже відрізняється від одного середовища до іншого. THE дані в робочому середовищі вони дуже свіжі. THE дані у DW вони набагато старші. Лише з точки зору часового горизонту між операційним середовищем і DW дуже мало збігів.

▪ DW містить дані резюме, які ніколи не зустрічаються в навколишньому середовищі

▪ Я дані зазнають фундаментальної трансформації, коли вони переходять до малюнку 3, що найбільше ілюструє дані суттєво змінено, якщо їх вибрано та переміщено до DW. Іншими словами, більшість дані він фізично та радикально змінюється, коли його переміщують у DW. З точки зору інтеграції вони не однакові дані які знаходяться в робочому середовищі. У світлі цих факторів надмірність о дані між двома середовищами є рідкісною подією, яка призводить до менш ніж 1% надмірності між двома середовищами. СТРУКТУРА СКЛАДУ DW мають чітку структуру. Існують різні рівні зведення та деталізації, які розмежовують DW.
Різні компоненти DW:

• метадані
• Давати актуальні деталі
• Давати старих деталей
• Давати трохи узагальнено
• Давати високо узагальнено

Безумовно, головна турбота про дані актуальні деталі. Це головне занепокоєння, оскільки:

• I дані актуальні деталі відображають останні події, які завжди викликають великий інтерес і
• i дані поточних деталей є об’ємним, оскільки зберігається на найнижчому рівні деталізації
• i дані Поточні дані майже завжди зберігаються на дисковій пам’яті, доступ до якої є швидким, але дорогий і складний у використанні дані чим старше вони дані які зберігаються в певній пам’яті маса. Доступ до нього здійснюється епізодично та зберігається на рівні деталізації, сумісному з дані актуальні деталі. Хоча зберігати на альтернативному носії не обов’язково через великий обсяг дані у поєднанні з спорадичним доступом до дані, підтримка пам'яті для дані більш старі детальні дані зазвичай не зберігаються на диску. THE дані узагальнено трохи є дані які відганяються від знайденого низького рівня деталізації до поточного рівня деталізації. Цей рівень DW майже завжди зберігається на дисковому сховищі. Проблеми проектування, що постають перед архітектором дані у побудові цього рівня DW є:

• За яку одиницю часу складається зведення, зроблене вище
• Який вміст, атрибути трохи узагальнять вміст дані Наступний рівень дані знайдено в DW, це те, що з дані високо узагальнено. THE дані дуже узагальнені компактні та легкодоступні. THE дані дуже узагальнені іноді зустрічаються в середовищі DW, а в інших випадках i дані дуже узагальнені знаходяться поза безпосередніми стінами технології, яка містить DW. (у будь-якому випадку, я дані дуже узагальнені є частиною DW незалежно від того, де i дані фізично розміщені). Останнім компонентом DW є метадані. У багатьох аспектах метадані знаходяться в іншому вимірі, ніж інші дані DW, оскільки метадані не містять жодних дате взяті безпосередньо з робочого середовища. Метадані відіграють особливу та дуже важливу роль у DW. Метадані використовуються як:

• каталог, який допоможе аналітику DSS знайти вміст DW,
• посібник із картографування дані про те, як я дані були перетворені з робочого середовища на середовище DW,
• посібник з алгоритмів, що використовуються для підсумовування між дані поточних деталей ei дані злегка узагальнено, i дані Коротко кажучи, метадані відіграють набагато більшу роль у середовищі DW, ніж вони коли-небудь мали в робочому середовищі СТАРИЙ НОСІЙ ДЕТАЛЕЙ Для зберігання такого роду можна використовувати магнітну стрічку дані. Насправді існує велика різноманітність носіїв інформації, які слід розглядати для зберігання старих даних дані деталізації. Залежно від обсягу дані, частоти доступу, вартості інструментів і типу доступу, цілком ймовірно, що іншим інструментам знадобиться старий рівень деталізації в DW. ПОТОК ДАНИХ Є нормальний і передбачуваний перебіг дані всередині DW.
  I дані вони потрапляють у DW з операційного середовища. (ПРИМІТКА. З цього правила є кілька дуже цікавих винятків. Однак майже всі дані введіть DW з операційного середовища). Dato що я дані введіть DW з операційного середовища, воно трансформується, як було описано раніше. За умови введення DW, i дані введіть поточний рівень деталізації, як показано. Він знаходиться там і використовується, доки не відбудеться одна з трьох подій:

• очищається,
• підсумовується та/або ▪è Застарілий процес у DW переміщується i дані поточні деталі a дані старих деталей, виходячи з вік дані. Процес

резюме використовує деталізацію дані обчислити i дані злегка узагальнений і дуже узагальнений рівні дані. Є деякі винятки з показаного потоку (буде обговорено пізніше). Однак, зазвичай, для переважної більшості дані знайдений у DW, потік дані це як зображено.

ВИКОРИСТАННЯ СХОВИЩА ДАНИХ

Не дивно, що різні рівні дані в межах DW вони не отримують різних рівнів використання. Як правило, чим вищий рівень узагальнення, тим більше i дані вони використовуються.
Багато застосувань зустрічається в дані дуже узагальнені, тоді як старі дані деталей майже не використовуються. Є вагома причина перевести організацію на парадигму використання ресурсів. Більше підсумував я дані, тим швидше й ефективніше дістатися до дані. Якщо магазин виявляє, що він виконує багато процесів на рівні деталізації DW, тоді споживається відповідна велика кількість машинних ресурсів. Це в інтересах кожного якнайшвидше опрацювати якомога вищий рівень узагальнення.

Для багатьох магазинів використовувався аналітик DSS у середовищі до DW дані на рівні деталізації. Багато в чому прибуття о дані детальне резюме нагадує ковдру безпеки, навіть якщо доступні інші рівні резюме. Одним із напрямків діяльності архіт дані полягає в тому, щоб відучити користувача DSS від постійного використання дані на найнижчому рівні деталізації. Архітектору доступні дві мотивації дані:

• шляхом встановлення системи повернення коштів, коли кінцевий користувач оплачує спожиті ресурси та
• які вказують на те, що дуже хороший час відгуку може бути досягнутий, коли поведінка з i дані має високий рівень узагальнення, тоді як низький час відповіді походить від поведінки дані на низькому рівні ІНШІ РОЗУМИ Існують деякі інші міркування щодо створення та управління DW.
  Перше міркування стосується індексів. THE дані на вищих рівнях узагальнення їх можна вільно індексувати, тоді як i дані

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

Перегородку можна зробити на двох рівнях – на рівні dbms і на прикладному рівні. У дивізії на рівні dbms, то dbms інформується про підрозділи та відповідно їх контролює. У разі поділу на прикладному рівні лише програміст інформується про поділ, і відповідальність за їх адміністрування покладається на нього

Нижче рівня dbms, багато роботи виконується автоматично. З автоматичним адмініструванням підрозділів пов’язано багато негнучкості. У разі поділів на прикладному рівні дані Дель сховище даних, багато роботи обтяжує програміста, але кінцевим результатом є гнучкість в адмініструванні дані нель сховище даних

АЛТРЕ АНОМАЛІЯ

У той час як компоненти в сховище даних Вони працюють, як описано майже для всіх дані, є деякі корисні винятки, які потрібно обговорити. Виняток становить о дані публічні зведені дані. Це дані підсумки, які були розраховані з сховище даних але вони використовуються суспільством. THE дані Публічні резюме зберігаються та керуються в сховище даних, хоча, як зазначалося раніше, вони розраховані. Бухгалтери працюють над складанням таких щокварталу дані такі як доходи, квартальні витрати, квартальний прибуток тощо. Робота, яку виконують бухгалтери, є зовнішньою сховище даних. Проте, я дані використовуються «внутрішньо» всередині компанії – від marketing , продажі тощо. Ще одна аномалія, про яку ми не будемо говорити, це аномалія дані зовнішній.

Ще один винятковий вид дані які можна знайти в a сховище даних це постійні детальні дані. Це викликає необхідність постійного зберігання дані на детальному рівні з етичних або юридичних причин. Якщо компанія піддає своїх працівників впливу небезпечних речовин, це необхідно дані докладний і постійний. Якщо компанія виробляє продукцію, яка зачіпає громадську безпеку, наприклад, запчастини для літаків, це необхідно дані постійні реквізити, а також якщо компанія укладає небезпечні контракти.

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

ПІДСУМОК

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

• Стара деталь
• Актуальна деталь
• Давати трохи узагальнено
• Давати дуже узагальнені метадані також є важливою частиною сховище даних. АНОТАЦІЯ Поняття про зберігання дані Останнім часом воно привернуло багато уваги і стало трендом 90-х. Це пов’язано зі здатністю сховище даних подолати обмеження систем підтримки управління, таких як системи підтримки прийняття рішень (DSS) та виконавчі інформаційні системи (EIS). Навіть якщо концепція сховище даних виглядає багатообіцяюче, реалізувати i сховище даних може бути проблематичним через масштабні складські процеси. Незважаючи на складність складських проектів дані, багато постачальників і консультантів, які запаси дані вони стверджують, що зберігання о дані струм не викликає проблем. Однак на початку цього дослідницького проекту майже не було проведено незалежного, ретельного та систематичного дослідження. Тому важко сказати, що насправді відбувається в галузі, коли вони будуються сховище даних. У цьому дослідженні вивчалася складська практика компанії дані contemporary, який має на меті розвинути глибше розуміння австралійської практики. Огляд літератури забезпечив контекст і основу для емпіричного дослідження. Є ряд результатів цього дослідження. По-перше, це дослідження виявило діяльність, яка виникла під час розвитку сховище даних. У багатьох областях, i дані зібрані підтвердили практику, описану в літературі. По-друге, питання та проблеми, які можуть вплинути на розвиток сховище даних були виявлені цим дослідженням. Нарешті, переваги, отримані австралійськими організаціями, пов'язані з використанням сховище даних були виявлені.

Капітоло 1

Контекст дослідження

Концепція сховища даних набула широкого розголосу та стала новою тенденцією в 90-х роках (McFadden 1996, TDWI 1996, Shah and Milstein 1997, Shanks et al. 1997, Eckerson 1998, Adelman and Oates 2000). Це можна побачити зі зростаючої кількості статей про сховища даних у галузевих виданнях (Little and Gibson 1999). Багато статей (див., Наприклад, Fisher 1995, Hackathorn 1995, Morris 1995a, Bramblett and King 1996, Graham et al. 1996, Sakaguchi and Frolick 1996, Alvarez 1997, Brousell 1997, Clarke 1997, McCarthy 1997, O 'Donnell 1997, Edwards 1998, TDWI 1999) повідомили про значні переваги, отримані організаціями, які впроваджують i сховище даних. Вони підтвердили свою теорію неофіційними доказами успішного впровадження, високими показниками рентабельності інвестицій (ROI), а також надавши вказівки чи методології для розробки сховище даних

(Шенкс та ін. 1997, Седдон і Бенджамін 1998, Літтл і Гібсон 1999). У крайньому випадку Graham et al. (1996) повідомили про середню віддачу від трирічної інвестиції в 401%.

Однак значна частина сучасної літератури не помічає складнощів, пов’язаних із здійсненням таких проектів. Проекти сховище даних вони, як правило, складні та великомасштабні, а отже, мають високу ймовірність невдачі, якщо їх не ретельно контролювати (Шах і Мільштейн 1997, Екерсон 1997, Фолі 1997b, Циммер 1997, Борт 1998, Гіббс і Клаймер 1998, Рао 1998). Вони вимагають величезних людських і фінансових ресурсів, а також часу та зусиль для їх створення (Hill 1998, Crofts 1998). Типові витрати часу та фінансових коштів складають приблизно два роки та два-три мільйони доларів відповідно (Braly 1995, Foley 1997b, Bort 1998, Humphries et al. 1999). Цей час і фінансові засоби потрібні для контролю та консолідації багатьох різних аспектів сховищ даних (Cafasso 1995, Hill 1998). Окрім апаратного та програмного забезпечення, інші функції, які відрізняються від видобутку дані до процесів завантаження дані, об’єм пам’яті для керування оновленнями та мета дані для навчання користувачів, необхідно враховувати.

На момент початку цього дослідницького проекту було дуже мало наукових досліджень у сфері сховищ даних, особливо в Австралії. Це було очевидно з браку опублікованих статей про сховища даних у журналах чи інших наукових роботах того часу. Багато доступних наукових праць описували досвід США. Відсутність академічних досліджень у сфері сховищ даних викликала вимоги до ретельних досліджень та емпіричних досліджень (McFadden 1996, Shanks et al. 1997, Little and Gibson 1999). Зокрема, дослідження процесу впровадження сховище даних необхідно проводити для розширення загальних знань щодо впровадження сховище даних і слугуватиме основою для майбутніх досліджень (Шенкс та ін. 1997, Літтл та Гібсон 1999).

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

Питання дослідження

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

«Яка нинішня практика сховище даних в Австралії?"

Щоб ефективно відповісти на це запитання, необхідно розглянути низку додаткових дослідницьких питань. Зокрема, з літератури, яка представлена ​​в розділі 2, було визначено три підпитання для керівництва цим дослідницьким проектом: сховище даних від австралійських організацій? З якими проблемами ви зіткнулися?

Які переваги ви отримали?
Для відповідей на ці запитання було використано дослідницький дизайн із застосуванням опитування. Як дослідницьке дослідження, відповіді на вищезазначені запитання не є повними (Шенкс та ін. 1993, Денскомб 1998). У цьому випадку для покращення відповідей на ці запитання потрібна тріангуляція. Проте розслідування забезпечить міцну основу для майбутньої роботи з вивчення цих питань. Детальне обговорення обґрунтування та дизайну методу дослідження представлено в Розділі 3.

Структура дослідницького проекту

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

Частина I: Контекстуальне дослідження

Перша частина дослідження складалася з огляду поточної літератури щодо різних типів сховищ даних, включаючи системи підтримки прийняття рішень (DSS), виконавчі інформаційні системи (EIS), тематичні дослідження сховище даних і поняття сховище даних. Крім того, результати форумів сховище даних а групи експертів і практиків під керівництвом дослідницької групи Monash DSS зробили внесок у цей етап дослідження, який мав на меті отримати уявлення про практику сховище даних та визначити ризики, пов’язані з їх прийняттям. Протягом цього періоду контекстуального дослідження було встановлено розуміння проблемної області, щоб забезпечити базові знання для наступних емпіричних досліджень. Однак це був постійний процес під час проведення дослідження.

Частина ІІ: Емпіричні дослідження

Відносно нова концепція сховищ даних, особливо в Австралії, породила потребу в опитуванні, щоб отримати широку картину досвіду користувача. Ця частина була виконана після того, як проблемна область була встановлена ​​шляхом широкого огляду літератури. Концепція зберігання даних, сформована на етапі контекстуального дослідження, була використана як вхідні дані для початкової анкети цього дослідження. Після цього була проведена перевірка анкети. Ви експерти в сховище даних брали участь у тестуванні. Метою тестування первинної анкети була перевірка повноти та точності питань. За результатами тестування анкету було доопрацьовано та модифікований варіант надіслано учасникам опитування. Повернені анкети потім були проаналізовані на i дані в таблицях, діаграмах та інших форматах. THE

результати аналізу дані вони утворюють знімок практики сховищ даних в Австралії.

ОГЛЯД СХОЖИЩ ДАНИХ

Концепція сховищ даних розвивалася разом із вдосконаленням комп’ютерних технологій.
Він спрямований на подолання проблем, з якими стикаються групи підтримки додатків, такі як система підтримки прийняття рішень (DSS) і виконавча інформаційна система (EIS).

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

Решта цього розділу представляє огляд концепції сховищ даних і обговорює, як сховище даних може подолати проблеми груп підтримки додатків.
Термін "Інформаційне сховище” популяризував Вільям Інмон у 1990 році. Його часто цитоване визначення бачить Інформаційне сховище як колекція дані предметно-орієнтований, інтегрований, енергонезалежний і змінний у часі для підтримки управлінських рішень.

Використовуючи це визначення, Інмон підкреслює, що i дані проживає в а сховище даних вони повинні володіти наступними 4 характеристиками:

• ▪ Предметно-орієнтований
• ▪ Інтегрований
• ▪ Енергонезалежний
• ▪ Змінна протягом часу Під предметно-орієнтованим Inmon означає, що i дані нель сховище даних у найбільших організаційних сферах, які були

визначені в моделі дані. Наприклад все дані щодо і клієнти містяться в предметній області КЛІЄНТИ. Так само всі дані пов’язані з продуктами, містяться в предметній області PRODUCTS.

Інтегрований Inmon означає, що i дані надходять із різних платформ, систем і місць об’єднуються та зберігаються в одному місці. Як наслідок дані схожі мають бути перетворені в послідовні формати, щоб їх можна було легко додавати та порівнювати.
Наприклад, чоловічий і жіночий рід в одній системі позначаються літерами M і F, а в іншій — 1 і 0. Щоб інтегрувати їх належним чином, один або обидва формати повинні бути перетворені таким чином, щоб обидва формати були однаковими. У цьому випадку ми можемо змінити M на 1 і F на 0 або навпаки. Предметно-орієнтований і інтегрований вказують на те, що сховище даних призначений для забезпечення функціонального та поперечного бачення дані компанією.

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

Для змінних із часом Inmon вказує, що i дані нель сховище даних завжди містять індикатори часу дані вони зазвичай перетинають певний часовий горизонт. Наприклад a
сховище даних може містити 5 років історичних цінностей клієнти з 1993 по 1997 рр. Наявність історії та динамічного ряду дані дозволяє аналізувати тенденції.

Un сховище даних він може зібрати своє дані із систем OLTP; із джерел дані поза організацією та/або іншими спеціальними проектами системи захоплення дані.
I дані екстракти можуть пройти процес очищення, у цьому випадку i дані трансформуються та інтегруються перед збереженням у база даних Дель сховище даних. Потім я дані

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

I дані мешканці в межах с база даних Дель сховище даних вони зберігаються як у детальному, так і в зведеному форматах.
Рівень резюме може залежати від характеру дані. Я дані детальний може складатися з дані струм e дані істориків
I дані роялті не включені в сховище даних поки я дані нель сховище даних оновлюються.
На додаток до зберігання i дані самі, а сховище даних він також може зберігати інший тип дате називаються МЕТАДАНІ, що описують дані жителів у його база даних.
Існує два типи метаданих: метадані розробки та аналітичні метадані.
Метадані розробки використовуються для керування та автоматизації процесів вилучення, очищення, відображення та завантаження дані нель сховище даних.
Інформація, що міститься в метаданих розробки, може містити деталі операційних систем, деталі елементів, які потрібно видобути, модель дані Дель сховище даних і бізнес-правила конвертації дані.

Другий тип метаданих, відомий як аналітичні метадані, дозволяє кінцевому користувачеві досліджувати вміст сховище даних знайти дані доступні та їх значення в зрозумілих, нетехнічних термінах.

Тому метадані аналітики працюють як міст між сховище даних і програми кінцевого користувача. Ці метадані можуть містити бізнес-модель, описи дані відповідно до бізнес-моделі, попередньо визначені запити та звіти, інформація для доступу користувачів та індекс.

Для належного функціонування метадані аналізу та розробки мають бути об’єднані в єдині інтегровані метадані зберігання.

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

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

Метою цієї коаліції є створення стандартного набору метаданих, який дозволяє різним інструментам сховища даних перетворювати метадані
Їхні зусилля привели до народження Специфікації обміну мета-даними (MDIS), яка дозволить обмінюватися інформацією між архівами Microsoft і відповідними файлами MDIS.

Існування дані як узагальнений/індексований, так і деталізований дає користувачеві можливість виконати DRILL DROWN (буріння) з дані індексовані до детальних і навпаки. Існування дані докладні історії дозволяють створювати аналіз тенденцій з часом. Крім того, метадані аналітики можна використовувати як каталог база даних Дель сховище даних щоб допомогти кінцевим користувачам знайти дані необхідно.

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

ІНФОРМАЦІЙНЕ СХОВИЩЕ ПРОТИ OLTP СИСТЕМ

Багато інформаційних систем в організаціях призначені для підтримки повсякденних операцій. Ці системи, відомі як OLTP SYSTEMS, фіксують постійно оновлювані щоденні транзакції.

I дані у цих системах вони часто змінюються, додаються або видаляються. Наприклад, адреса клієнта змінюється, коли він переїжджає з одного місця в інше. У цьому випадку нова адреса буде зареєстрована шляхом зміни поля адреси база даних. Основна мета цих систем – скоротити транзакційні витрати та водночас скоротити час обробки. Приклади систем OLTP включають критичні дії, такі як введення замовлення, нарахування заробітної плати, рахунок-фактура, виробництво, обслуговування клієнтів клієнти.

На відміну від систем OLTP, які були створені для процесів, заснованих на транзакціях і подіях, тобто сховище даних були створені для забезпечення підтримки процесів на основі аналітики дані і процеси прийняття рішень.

Зазвичай це досягається шляхом інтегрування i дані з різних OLTP і зовнішніх систем в одному «контейнері». дані, як обговорювалося в попередньому розділі.

Модель процесу сховища даних Monash

Модель процесу для сховище даних Monash розроблено дослідниками дослідницької групи Monash DSS Research Group і базується на літературі сховище даних, про досвід підтримки розробки системних галузей, про обговорення з постачальниками додатків для використання на сховище даних, на групу експертів з використання сховище даних.

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

Планування потужностей
Dw, як правило, має дуже великий розмір і дуже швидко зростає (Best 1995, Rudin 1997a) в результаті кількості дані історії, які вони зберігають від своєї тривалості. Зростання також може бути викликано дані доповнення, запитувані користувачами для збільшення вартості дані що вони вже мають. Відповідно вимоги до зберігання для дані можна значно покращити (Eckerson 1997). Таким чином, за допомогою планування потужностей важливо переконатися, що система, що будується, може зростати разом із зростанням потреб (Бест 1995, ЛаПлант 1996, Ланг 1997, Екерсон 1997, Рудін 1997а, Фолі 1997а).
Плануючи масштабованість бази даних, необхідно знати очікуване зростання розміру сховища, типи запитів, які ймовірно будуть зроблені, і кількість підтримуваних кінцевих користувачів (Бест 1995, Рудін 1997b, Фолі 1997a). Створення масштабованих програм вимагає поєднання масштабованих серверних технологій і технік проектування масштабованих програм (Best 1995, Rudin 1997b. Обидва вони необхідні для створення високомасштабованих програм. Технології масштабованих серверів можуть полегшити та зробити вигідним додавання пам’яті, пам’яті та ЦП без зниження продуктивності виконання (Lang 1997, Telephony 1997).

Існує дві основні масштабовані серверні технології: симетрична багаторазова обробка (SMP) і масова паралельна обробка (MPP) (IDC 1997, Humphries et al. 1999). Сервер SMP зазвичай має кілька процесорів, які спільно використовують пам'ять, системну шину та інші ресурси (IDC 1997, Humphries et al. 1999). Для його збільшення можна додати додаткові процесори Potenza обчислювальний. Ще один спосіб збільшити Potenza SMP-сервера, об’єднати численні SMP-машини. Ця техніка відома як кластеризація (Humphries et al. 1999). Сервер MPP, з іншого боку, має кілька процесорів, кожен із власною пам’яттю, системою шини та іншими ресурсами (IDC 1997, Humphries et al. 1999). Кожен процесор називається вузлом. Збільшення в Potenza обчислення можна досягти

додавання додаткових вузлів до серверів MPP (Humphries et al. 1999).

Слабкість серверів SMP полягає в тому, що занадто багато операцій вводу-виводу (I/O) можуть перевантажувати системну шину (IDC 1997). Ця проблема не виникає на серверах MPP, оскільки кожен процесор має власну систему шини. Однак з'єднання між кожним вузлом, як правило, набагато повільніше, ніж система шини SMP. Крім того, сервери MPP можуть додати додатковий рівень складності для розробників програм (IDC 1997). Таким чином, на вибір між серверами SMP і MPP може вплинути багато факторів, включаючи складність додатків, співвідношення ціна/продуктивність, необхідна потужність обробки, заборонені додатки dw і збільшення розміру база даних dw і в кількості кінцевих користувачів.

Для планування потужності можна використовувати численні методи розробки масштабованих програм. Використовуються різні періоди сповіщення, такі як дні, тижні, місяці та роки. Маючи різні періоди сповіщення, база даних її можна розділити на керовано згруповані частини (Inmon et al. 1997). Інший прийом полягає у використанні зведених таблиць, які будуються шляхом узагальнення дані da дані докладно. Так я дані узагальнені більш компактні, ніж детальні, що потребує менше місця в пам’яті. Отже дані деталі можна зберігати в менш дорогій одиниці зберігання, що економить ще більше місця. Хоча використання зведених таблиць може заощадити місце в пам’яті, вони потребують багато зусиль, щоб підтримувати їх актуальними та відповідати потребам бізнесу. Однак ця техніка широко використовується і часто використовується в поєднанні з попередньою технікою (Best 1995, Inmon 1996a, Chauduri and Dayal
1997).

Визначення Інформаційне сховище Технічні архітектури Визначення методів архітектури dw

Перші прихильники сховищ даних передусім уявляли централізовану реалізацію dw, у якій усі дані, включаючи i дані зовнішні, були об'єднані в єдине,
фізичне зберігання (Inmon 1996a, Bresnahan 1996, Peacock 1998).

Основна перевага цього підходу полягає в тому, що кінцеві користувачі можуть отримати доступ до корпоративного перегляду дані організаційний (Ovum 1998). Ще одна перевага полягає в тому, що він пропонує стандартизацію дані через організацію, що означає, що існує лише одна версія або визначення для кожної термінології, яка використовується в сховищі dw (метаданих) (Flanagan and Safdie 1997, Ovum 1998). Недоліком цього підходу, з іншого боку, є те, що він дорогий і складний у створенні (Flanagan and Safdie 1997, Ovum 1998, Inmon et al. 1998). Незабаром після архітектури зберігання дані централізований став популярним, концепція вилучення менших підмножин еволюціонувала дані для підтримки потреб конкретних програм (Varney 1996, IDC 1997, Berson and Smith 1997, peacock 1998). Ці малі системи є похідними від більшої сховище даних централізований. Вони названі сховище даних залежні відомчі або залежні вітрини даних. Залежна архітектура вітрини даних відома як трирівнева архітектура, де перший рівень складається з сховище даних централізована, друга складається з родовищ с дані відомчий і третій складається з доступу до дані та інструментами аналізу (Demarest 1994, Inmon et al. 1997).

Вітрини даних зазвичай будуються після сховище даних централізований був побудований для задоволення потреб конкретних підрозділів (White 1995, Varney 1996).
Вітрини даних зберігають дані дуже актуальні стосовно конкретних одиниць (Inmon et al. 1997, Inmon et al. 1998, IA 1998).

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

корпоративні організації. Цей метод відомий як метод «зверху вниз», де вітринки даних будуються після сховище даних (павич 1998, Гофф 1998).
Збільшуючи потребу в ранньому показі результатів, деякі організації почали створювати незалежні вітрини даних (Flanagan and Safdie 1997, White 2000). У цьому випадку вітрини даних отримують своє дані прямо з основ дані OLTP, а не з централізованого та інтегрованого складу, що усуває необхідність мати центральний склад на місці.

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

Кожна вітрина даних повинна зберігати всі дані потрібно локально, щоб не впливати на системи OLTP. Це призводить до того, що i дані вони зберігаються в різних вітринах даних (Inmon et al. 1997). Ще одним недоліком цієї архітектури є те, що вона призводить до створення складних взаємозв’язків між вітринами даних та їхніми джерелами даних. дані які важко проводити та контролювати (Inmon et al. 1997).

Іншим недоліком є ​​те, що кінцеві користувачі не можуть отримати доступ до огляду інформації про компанію, оскільки i дані різних вітрин даних не інтегровані (Ovum 1998).
Ще одним недоліком є ​​те, що для кожної термінології, яка використовується у вітринах даних, може бути більше одного визначення, що створює неузгодженість дані в організації (Ovum 1998).
Незважаючи на зазначені вище недоліки, незалежні біржі даних все ще привертають інтерес багатьох організацій (IDC 1997). Одним з факторів, який робить їх привабливими, є те, що вони швидше розвиваються і вимагають менше часу та ресурсів (Бреснахан 1996, Берсон і Сміт 1997, Овум 1998). Отже, вони служать переважно як тестові проекти, які можуть бути використані для швидкого визначення переваг та/або недоліків у проекті (Parsaye 1995, Braly 1995, Newing 1996). У цьому випадку частина, яка буде реалізована в пілотному проекті, має бути невеликою, але важливою для організації (Newing 1996, Mansell-Lewis 1996).

Вивчаючи прототип, кінцеві користувачі та адміністрація можуть вирішити, продовжувати чи зупиняти проект (Flanagan and Safdie 1997).
Якщо рішення буде продовжено, вітринки даних для інших галузей повинні будуватися по черзі. Є два варіанти для кінцевих користувачів залежно від їхніх потреб у створенні незалежних матриць даних: інтегрована/об’єднана та неінтегрована (Ovum 1998)

У першому методі кожна нова вітрина даних повинна бути створена на основі поточних вітрин даних і моделі дані використовується компанією (Varney 1996, Berson and Smith 1997, Peacock 1998). Необхідність використання моделі дані компанії означає, що необхідно переконатися, що існує лише одне визначення для кожної термінології, яка використовується на вітринах даних, це також гарантує, що різні вітрини даних можна поєднувати, щоб дати огляд інформації компанії (Bresnahan 1996). Цей метод називається «знизу вгору» і є найкращим, коли є обмеження фінансових засобів і часу (Flanagan and Safdie 1997, Ovum 1998, Peacock 1998, Goff 1998). У другому способі побудовані вітрини даних можуть задовольнити лише потреби конкретного підрозділу. Варіантом федеративної вітрини даних є сховище даних поширюється в якому база даних Проміжне програмне забезпечення Hub Server використовується для об’єднання багатьох вітрин даних в одне сховище дані поширений (White 1995). У цьому випадку, i дані компанії розподілені в кількох вітринах даних. Запити кінцевих користувачів пересилаються база даних проміжне програмне забезпечення концентратора сервера, яке витягує всі дані за запитом вітрин даних і повертає результати додаткам кінцевих користувачів. Цей метод надає бізнес-інформацію кінцевим користувачам. Проте проблеми незалежних вітрин даних досі не усунені. Існує ще одна архітектура, яку можна використовувати, яка називається сховище даних віртуальний (White 1995). Однак ця архітектура, яка описана на малюнку 2.9, не є архітектурою зберігання даних. дані реальний, оскільки він не переміщує завантаження з систем OLTP на сховище даних (Demarest 1994).

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

дані історія та огляд інформації про компанію, як i дані з різних систем OLTP не інтегровані. Отже, ця архітектура не може задовольнити аналіз дані комплекс, наприклад прогнози.

Вибір програм доступу та відновлення дані

Мета будівництва а сховище даних полягає в тому, щоб передати інформацію кінцевим користувачам (Inmon et al. 1997, Poe 1996, McFadden 1996, Shanks et al. 1997, Hammergren 1998); одну або кілька програм доступу та відновлення дані повинні бути надані. На сьогоднішній день існує велика різноманітність цих програм, з яких користувач може вибрати (Hammergren 1998, Humphries et al. 1999). Вибрані вами програми визначають успіх ваших складських зусиль дані в організації, оскільки програми є найпомітнішою частиною сховище даних до кінцевого користувача (Inmon et al. 1997, Poe 1996). Бути успішним a сховище даних, має бути в змозі підтримувати аналітичну діяльність дані кінцевого користувача (Poe 1996, Seddon and Benjamin 1998, Eckerson 1999). Таким чином, необхідно визначити «рівень» того, чого хоче кінцевий користувач (Poe 1996, Mattison 1996, Inmon et al. 1997, Humphries et al. 1999).

Загалом кінцевих користувачів можна згрупувати в три категорії: керівники, бізнес-аналітики та досвідчені користувачі (Poe 1996, Humphries et al. 1999). Керівним користувачам потрібен легкий доступ до попередньо визначених наборів звітів (Humphries et al. 1999). Ці коефіцієнти можна легко отримати за допомогою навігації в меню (Poe 1996). Крім того, звіти повинні представляти інформацію за допомогою графічного представлення, такого як таблиці та шаблони, для швидкої передачі інформації (Humphries et al. 1999). Бізнес-аналітики, які можуть не мати технічних можливостей самостійно розробляти звіти з нуля, повинні мати можливість модифікувати поточні звіти відповідно до своїх конкретних потреб (Poe 1996, Humphries et al. 1999). З іншого боку, досвідчені користувачі — це тип кінцевих користувачів, які мають можливість генерувати та писати запити та звіти з нуля (Poe 1996, Humphries et al. 1999). Це ті, хто

вони розробляють звіти для інших типів користувачів (Poe 1996, Humphries et al. 1999).

Після визначення вимог кінцевого користувача необхідно вибрати програми для доступу та відновлення дані серед усіх доступних (Poe 1996, Inmon et al. 1997).
Доступ до дані Інструменти пошуку можна розділити на 4 типи: інструменти OLAP, інструменти EIS/DSS, інструменти запитів і звітів, а також інструменти інтелектуального аналізу даних.

Інструменти OLAP дозволяють користувачам створювати спеціальні запити, а також запити, зроблені на база даних Дель сховище даних. Крім того, ці продукти дають користувачам можливість детальніше ознайомитися з дані від загального до детального.

Інструменти EIS/DSS надають виконавчі звіти, такі як аналіз «що, якщо» та доступ до звітів, керованих меню. Звіти мають бути попередньо визначені та об’єднані з меню для полегшення навігації.
Інструменти запитів і звітів дозволяють користувачам створювати попередньо визначені та спеціальні звіти.

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

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

Щоб підвищити цінність сховища даних, команда розробників також може надати веб-доступ до свого сховища даних. Веб-сховище даних дозволяє користувачам отримувати доступ до дані з віддалених місць або під час подорожі. Додаткова інформація може

надаватися за нижчих витрат через скорочення витрат на навчання.

2.4.3 Інформаційне сховище Фаза операції

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

Визначення стратегій оновлення даних

Після початкового завантаження, i дані нель база даних сховища даних необхідно періодично оновлювати, щоб відтворити внесені в них зміни дані оригінали. Тому ви повинні вирішити, коли оновлювати, як часто планувати оновлення та як оновлювати дані дані. Пропонується оновити дані коли систему можна перевести в автономний режим. Частота оновлення визначається командою розробників на основі вимог користувача. Існує два підходи до оновлення сховища даних: повне оновлення та постійне завантаження змін.

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

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

Існує принаймні 5 підходів, які можна використати для зняття i дані новий або модифікований. Щоб отримати ефективну стратегію оновлення даних дані може бути корисною суміш цих підходів, яка фіксує всі зміни в системі.

Перший підхід, який використовує мітки часу, припускає, що всі призначені дані відредагував і оновив позначку часу, щоб ви могли легко ідентифікувати всіх дані змінені та нові. Цей підхід, однак, не отримав широкого застосування в більшості сучасних операційних систем.
Другий підхід полягає у використанні дельта-файлу, створеного програмою, яка містить лише внесені зміни дані. Використання цього файлу також збільшує цикл оновлення. Однак навіть цей метод не був використаний у багатьох додатках.
Третій підхід полягає у скануванні файлу журналу, який в основному містить інформацію, схожу на дельта-файл. Єдина відмінність полягає в тому, що файл журналу створюється для процесу відновлення, і його може бути важко зрозуміти.
Четвертий підхід полягає у зміні коду програми. Однак більшість програмного коду старі та крихкі; тому слід уникати цієї техніки.
Останній підхід полягає у порівнянні дані джерела з основним файлом dei дані.

Контроль діяльності сховища даних

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

Крім того, аудит сховища даних також можна використовувати для визначення типів запитів, їх розміру, кількості запитів на день, часу реакції на запит, охоплених секторів і кількості дані оброблені. Ще одна мета проведення аудиту сховищ даних — виявити дані які не використовуються. Ці дані їх можна видалити зі сховища даних, щоб скоротити час

відповіді на виконання запиту та стежити за зростанням дані які знаходяться в межах база даних сховища даних.

Управління безпекою сховища даних

Сховище даних містить дані інтегрований, критичний, чутливий, до якого можна легко дістатися. З цієї причини його слід захистити від неавторизованих користувачів. Одним із способів реалізації безпеки є використання функції del СУБД для призначення різних привілеїв різним типам користувачів. Таким чином, профіль доступу необхідно підтримувати для кожного типу користувача. Інший спосіб захистити сховище даних — зашифрувати його, як зазначено в база даних сховища даних. Доступ до дані і інструменти пошуку повинні розшифрувати дані перед представленням результатів користувачам.

2.4.4 Інформаційне сховище Фаза розгортання

Це останній етап у циклі впровадження сховища даних. Діяльність, яка буде виконана на цьому етапі, включає навчання користувачів використанню сховища даних і проведення перевірок сховища даних.

Навчання користувачів

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

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

На основі того, що вони дізналися, інші користувачі можуть почати досліджувати сховище даних.
Інший підхід полягає в тому, щоб навчати багатьох користувачів одночасно, ніби ви проходите курс у класі. Цей метод підходить, коли є багато користувачів, яких потрібно навчати одночасно. Ще один метод полягає в навчанні кожного користувача окремо, одного за іншим. Цей спосіб підходить, коли користувачів мало.

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

Збір відгуків

Після розгортання сховища даних користувачі зможуть використовувати i дані які знаходяться в сховищі даних для різних цілей. Здебільшого аналітики чи користувачі використовують i дані у сховищі даних для:

1. 1 Визначте тенденції компанії
2. 2 Проаналізуйте профілі купівлі клієнти
3. 3 Розділіть i клієнти і
4. 4 Надайте найкращі послуги клієнти – налаштувати послуги
5. 5 Сформулюйте стратегії marketing
6. 6 Надайте конкурентоспроможні пропозиції для аналізу витрат і допомоги в контролі
7. 7 Підтримка прийняття стратегічних рішень
8. 8 Визначте можливості виділитися
9. 9 Підвищення якості поточних бізнес-процесів
10. 10 Перевірте прибуток

Дотримуючись напряму розвитку сховища даних, можна провести серію перевірок системи для отримання зворотного зв’язку

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

Оскільки сховище даних має поступовий підхід, дуже важливо вчитися на успіхах і помилках попередніх розробок.

2.5 Підсумок

У цьому розділі обговорювалися підходи, наявні в літературі. У розділі 1 обговорювалося поняття сховища даних та його роль у науці прийняття рішень. У розділі 2 описано основні відмінності між сховищами даних і системами OLTP. У розділі 3 ми обговорювали модель сховища даних Monash, яка використовувалася в розділі 4 для опису дій, пов’язаних із процесом розробки сховища даних, ці тези не ґрунтувалися на ретельному дослідженні. Те, що відбувається в реальності, може дуже відрізнятися від того, що повідомляється в літературі, однак ці результати можуть бути використані для створення базової основи, яка підкреслює концепцію сховища даних для цього дослідження.

Капітоло 3

Методи дослідження та проектування

У цій главі розглядаються дослідницькі та методи дизайну цього дослідження. У першій частині представлений загальний огляд методів дослідження, доступних для пошуку інформації, крім того, обговорюються критерії вибору найкращого методу для конкретного дослідження. У розділі 2 обговорюються два методи, вибрані за щойно викладеними критеріями; з них один буде обрано та прийнято з причинами, викладеними в розділі 3, де також викладено причини виключення іншого критерію. Розділ 4 представляє план дослідження, а розділ 5 – висновки.

3.1 Дослідження в інформаційних системах

Дослідження в інформаційних системах не просто обмежуються технологічною сферою, але також мають бути розширені, щоб включати поведінкові та організаційні цілі.
Ми завдячуємо цим дисертаціям різних дисциплін, починаючи від суспільних і закінчуючи природничими науками; це призводить до потреби в певному спектрі методів дослідження, що включають кількісні та якісні методи, які будуть використовуватися для інформаційних систем.
Усі доступні методи дослідження є важливими, насправді деякі дослідники, такі як Дженкінс (1985), Нунамейкер та ін. (1991) і Галлієрс (1992) стверджують, що не існує конкретного універсального методу для проведення досліджень у різних областях інформаційних систем; фактично метод може бути придатним для певного дослідження, але не для інших. Це призводить до необхідності вибору методу, який підходить для нашого конкретного дослідницького проекту: для цього вибору Benbasat et al. (1987) стверджують, що необхідно враховувати характер і мету дослідження.

3.1.1 Характер дослідження

Різні методи, засновані на природі дослідження, можна класифікувати за трьома традиціями, широко відомими в інформаційній науці: позитивістське, інтерпретаційне та критичне дослідження.

3.1.1.1 Позитивістські дослідження

Позитивістське дослідження також відоме як наукове або емпіричне дослідження. Він прагне: «пояснити та передбачити, що станеться в соціальному світі, дивлячись на закономірності та причинно-наслідкові зв’язки між елементами, які його утворюють» (Шенкс та ін., 1993).

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

3.1.1.2 Інтерпретаційне дослідження

Інтерпретаційне дослідження, яке часто називають феноменологією або антипозитивізмом, описується Нойманом (1994) як «систематичний аналіз соціального значення дії шляхом прямого та детального спостереження за людьми в природних ситуаціях, щоб досягти розуміння та до тлумачення того, як люди створюють і підтримують свій соціальний світ». Інтерпретаційні дослідження відкидають припущення, що спостережувані явища можна спостерігати об’єктивно. Насправді вони базуються на суб'єктивних інтерпретаціях. Крім того, дослідники-інтерпретатори не нав’язують апріорні значення явищам, які вони вивчають.

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

3.1.1.3 Критичні дослідження

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

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

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

3.1.2 Мета дослідження

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

3.1.2.1 Пошукові дослідження

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

Однак також можна використовувати кількісні методи, такі як дослідницькі опитування або експерименти.

3.1.3.3 Описове дослідження

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

3.1.2.3 Пояснювальні дослідження

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

3.1.2.4 Профілактичні дослідження

Профілактичні дослідження мають на меті передбачити події та поведінку, що знаходяться під спостереженням і які вивчаються (Marshall and Rossman 1995). Прогноз — це стандартна наукова перевірка правди. Цей тип дослідження зазвичай передбачає опитування або аналіз дані істориків. (Інь 1989)

Наведене вище обговорення демонструє, що існує ряд можливих методів дослідження, які можна використовувати в конкретному дослідженні. Однак повинен існувати один конкретний метод, який більше підходить, ніж інші, для певного типу дослідницького проекту. (Galliers 1987, Yin 1989, De Vaus 1991). Таким чином, кожен дослідник повинен ретельно оцінити сильні та слабкі сторони різних методів, щоб прийняти найбільш прийнятний і сумісний метод дослідження з дослідницьким проектом. (Дженкінс 1985, Перван і Клас 1992, Бономія 1985, Інь 1989, Гімілтон і Айвз 1992).

3.2. Можливі методи дослідження

Метою цього проекту було вивчення досвіду австралійських організацій з i дані зберігається з розвитком сховище даних. Dato Оскільки наразі в Австралії недостатньо досліджень у сфері сховищ даних, цей дослідницький проект все ще знаходиться на теоретичній фазі дослідницького циклу та має дослідницьку мету. Вивчення досвіду австралійських організацій, які використовують сховища даних, вимагає інтерпретації реального суспільства. Отже, філософське припущення, що лежить в основі дослідницького проекту, дотримується традиційної інтерпретації.

Після ретельного вивчення доступних методів було визначено два можливих методи дослідження: опитування та тематичні дослідження, які можна використовувати для пошукових досліджень (Шенкс та ін. 1993). Галлієрс (1992) аргументує придатність цих двох методів для цього конкретного дослідження у своїй переглянутій таксономії, кажучи, що вони придатні для побудови теорії. У наступних двох підрозділах докладно розглядається кожен метод.

3.2.1 Опитовий метод дослідження

Опитовий метод дослідження походить від стародавнього методу перепису. Перепис складається зі збору інформації про все населення. Цей метод дорогий і непрактичний, особливо якщо населення велике. Таким чином, порівняно з переписом, опитування зазвичай зосереджується на зборі інформації для невеликої кількості або вибірки представників населення (Fowler 1988, Neuman 1994). Вибірка відображає генеральну сукупність, з якої вона взята, з різними рівнями точності, залежно від структури вибірки, розміру та використаного методу відбору (Fowler 1988, Babbie 1982, Neuman 1994).

Метод опитування визначається як «миттєві знімки практик, ситуацій або поглядів у певний момент часу, зроблені за допомогою анкет або інтерв’ю, з яких можна зробити висновки.
зроблено» (Galliers 1992:153) [моментальний знімок практик, ситуацій або поглядів у певний момент часу, зроблений за допомогою анкет чи інтерв’ю, з яких можна зробити висновки]. Опитування мають на меті зібрати інформацію про деякі аспекти дослідження від певної кількості учасників шляхом постановки запитань (Fowler 1988). Ці анкети та інтерв’ю, які включають особисті телефонні інтерв’ю та структуровані інтерв’ю, також є методами збору дані найчастіше використовується в дослідженнях (Blalock 1970, Nachmias and Nachmias 1976, Fowler 1988), можна використовувати спостереження та аналіз (Gable 1994). З усіх цих методів збору дані, використання опитувальника є найпопулярнішим методом, оскільки воно гарантує, що i дані

зібрані дані структуровані та відформатовані, що полегшує класифікацію інформації (Hwang 1987, de Vaus 1991).

При аналізі i дані, стратегія розслідування часто використовує кількісні методи, такі як статистичний аналіз, але також можна використовувати якісні методи (Galliers 1992, Pervan

і Клас 1992, Гейбл 1994). Зазвичай, i дані зібрані дані використовуються для аналізу розподілів і моделей асоціацій (Fowler 1988).

Хоча опитування, як правило, підходять для досліджень, пов’язаних із питанням «що?» (що) або похідні від нього, такі як «скільки» і «скільки», їх можна поставити через запитання «чому» (Sonquist and Dunkelberg 1977, Yin 1989). Відповідно до Сонквіста та Данкельберга (1977), дослідницькі дослідження спрямовані на перевірку гіпотез, оцінку програм, опис населення та розробку моделей людської поведінки. Крім того, опитування можна використовувати для вивчення певної думки населення, умов, думок, характеристик, очікувань і навіть минулої або теперішньої поведінки (Neuman 1994).

Опитування дозволяють досліднику виявити зв’язки між популяцією, і результати, як правило, є більш загальними, ніж інші методи (Sonquist and Dunkelberg 1977, Gable 1994). Опитування дозволяють дослідникам охопити більшу географічну територію та охопити велику кількість респондентів (Blalock 1970, Sonquist і Dunkelberg 1977, Hwang і Lin 1987, Gable 1994, Neuman 1994). Нарешті, опитування можуть надати інформацію, яка недоступна в іншому місці або у формі, необхідній для аналізу (Fowler 1988).

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

дослідження (Yin 1989, de Vaus 1991, Gable 1994, Denscombe 1998). Іншим недоліком є ​​те, що проведення опитування може бути дуже дорогим з точки зору часу та ресурсів, особливо якщо воно передбачає особисті інтерв’ю (Fowler 1988).

3.2.2. Запитовий метод дослідження

Метод опитувального дослідження передбачає поглиблене вивчення конкретної ситуації в контексті її реального світу протягом визначеного періоду часу без будь-якого втручання з боку дослідника (Shanks & C. 1993, Eisenhardt 1989, Jenkins 1985). В основному цей метод використовується для опису зв'язків між змінними, які вивчаються в конкретній ситуації (Galliers 1992). Розслідування можуть охоплювати один або кілька випадків, залежно від аналізованого явища (Франц і Робі 1987, Айзенхардт 1989, Інь 1989).

Метод опитувального дослідження визначається як «емпіричне дослідження, яке вивчає сучасне явище в його фактичному контексті, використовуючи численні джерела, зібрані від одного або кількох суб’єктів, таких як люди, групи чи організації» (Yin 1989). Немає чіткого поділу між явищем і його контекстом, а також немає експериментального контролю чи маніпулювання змінними (Yin 1989, Benbasat et al. 1987).

Існує різноманітна техніка збору дані які можуть бути використані в методі опитування, який включає прямі спостереження, перегляд архівних записів, анкетування, огляд документації та структуровані інтерв’ю. Наявність різноманітних технологій збирання врожаю дані, дослідження дозволяють дослідникам мати справу з обома дані якісний і кількісний водночас (Bonoma 1985, Eisenhardt 1989, Yin 1989, Gable 1994). Як і у випадку з методом опитування, дослідник опитування виступає як спостерігач або дослідник, а не як активний учасник досліджуваної організації.

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

теорії в процесі збирання дані. Також підходить для сцени

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

Порівняно з іншими методами, опитування дозволяють досліднику отримувати важливу інформацію більш детально (Galliers 1992, Shanks et al. 1993). Крім того, опитування дозволяють досліднику зрозуміти природу та складність досліджуваних процесів (Benbasat et al. 1987).

Є чотири основні недоліки, пов'язані з методом опитування. Перший – це відсутність контрольованих відрахувань. Суб'єктивність дослідника може змінити результати та висновки дослідження (Yin 1989). Другий недолік – відсутність контрольованого спостереження. На відміну від експериментальних методів, дослідник не може контролювати досліджувані явища, оскільки вони досліджуються в їх природному контексті (Gable 1994). Третій недолік - відсутність тиражності. Це пояснюється тим, що дослідник навряд чи спостерігатиме ті самі події та не може перевірити результати конкретного дослідження (Lee 1989). Нарешті, як наслідок невідтворюваності, важко узагальнити результати, отримані в результаті одного чи кількох досліджень (Galliers 1992, Shanks et al 1993). Проте всі ці проблеми не є непереборними і можуть бути зведені до мінімуму дослідником шляхом застосування відповідних дій (Lee 1989).

3.3. Обґрунтуйте методику дослідження прийнято

З двох можливих методів дослідження для цього дослідження найбільш підходящим вважається метод опитування. Розслідування було припинено після ретельного розгляду відповідних

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

3.3.1. Невідповідність методу дослідження розслідування

Метод опитування вимагає поглибленого вивчення конкретної ситуації в одній або кількох організаціях протягом певного періоду часу (Eisenhardt 1989). У цьому випадку термін може перевищувати часові рамки, надані для цього дослідження. Ще одна причина відмови від застосування методу опитування полягає в тому, що результати можуть страждати від недостатньої точності (Yin 1989). Суб’єктивність дослідника може впливати на результати та висновки. Інша причина полягає в тому, що цей метод більше підходить для дослідження питань типу «як» або «чому» (Yin 1989), тоді як дослідницьке питання для цього дослідження відноситься до типу «що». І останнє, але не менш важливе: важко узагальнити результати лише одного чи кількох досліджень (Galliers 1992, Shanks et al. 1993). Виходячи з цього обґрунтування, метод опитування не був обраний, оскільки він був непридатним для цього дослідження.

3.3.2. Зручність способу пошуку розслідування

Коли проводилося це дослідження, практика зберігання даних не була широко прийнята австралійськими організаціями. Отже, не було багато інформації щодо їх впровадження в австралійських організаціях. Доступна інформація надійшла від організацій, які впровадили або використовували a сховище даних. У цьому випадку метод опитування є найбільш підходящим, оскільки він дозволяє отримати інформацію, недоступну в іншому місці, або у формі, необхідній для аналізу (Fowler 1988). Крім того, метод опитування дозволяє досліднику отримати гарне уявлення про практики, ситуації або погляди в певний час (Galliers 1992, Denscombe 1998). Огляд був потрібен, щоб розширити знання про австралійський досвід сховищ даних.

Крім того, Сонквіст і Дункельберг (1977) стверджують, що результати опитування є більш загальними, ніж інші методи.

3.4. Дизайн дослідження опитування

Опитування практик сховищ даних було проведено в 1999 році. Цільову групу сформували австралійські організації, зацікавлені в дослідженнях сховищ даних, оскільки вони, ймовірно, вже були поінформовані про дані які вони зберігають і, отже, можуть надати корисну інформацію для цього дослідження. Цільову групу було визначено шляхом початкового опитування всіх австралійських членів Інституту сховищ даних (Tdwi-aap). У цьому розділі обговорюється дизайн етапу емпіричного дослідження цього дослідження.

3.4.1. Техніка збирання врожаю дані

З трьох методів, які зазвичай використовуються в опитуванні (тобто анкета поштою, телефонне інтерв’ю та особисте інтерв’ю) (Nachmias 1976, Fowler 1988, de Vaus 1991), анкета поштою була прийнята для цього дослідження. Перша причина для прийняття останнього полягає в тому, що він може охопити географічно розсіяне населення (Blalock 1970, Nachmias and Nachmias 1976, Hwang and Lin 1987, de Vaus 1991, Gable 1994). По-друге, поштова анкета підходить для високоосвічених учасників (Fowler 1988). Поштова анкета для цього дослідження була адресована спонсорам проекту зі сховищ даних, директорам та/або менеджерам проекту. По-третє, поштові анкети підходять, коли доступний захищений список розсилки (Salant and Dilman 1994). TDWI, у цьому випадку, довірена асоціація сховищ даних надала список розсилки своїх австралійських членів. Ще одна перевага поштової анкети перед телефонною анкетою чи особистими інтерв'ю полягає в тому, що вона дозволяє респондентам відповідати точніше, особливо коли респондентам необхідно ознайомитися з нотатками або обговорити запитання з іншими людьми (Fowler 1988).

Потенційним недоліком може бути час, необхідний для проведення анкетування поштою. Зазвичай опитування поштою проводиться в такій послідовності: надсилання листів, очікування відповідей і надсилання підтвердження (Fowler 1988, Bainbridge 1989). Таким чином, загальний час може бути більшим, ніж час, необхідний для особистого інтерв'ю або телефонного інтерв'ю. Однак загальний час може бути відомий заздалегідь (Fowler 1988, Denscombe 1998). Час, витрачений на проведення особистих інтерв'ю, не може бути відомий заздалегідь, оскільки він змінюється від одного інтерв'ю до іншого (Fowler 1988). Телефонні інтерв’ю можуть бути швидшими, ніж поштові анкети та особисті інтерв’ю, але можуть мати високий відсоток невідповідей через недоступність деяких людей (Fowler 1988). Крім того, телефонні інтерв’ю, як правило, обмежуються відносно короткими списками питань (Bainbridge 1989).

Іншим недоліком поштової анкети є високий відсоток невідповідей (Fowler 1988, Bainbridge 1989, Neuman 1994). Однак було вжито контрзаходів, пов’язуючи це дослідження з довіреною установою сховищ даних (тобто TDWI) (Bainbridge 1989, Neuman 1994), яка надсилає два листи-нагадування тим, хто не відповідає (Fowler 1988, Neuman 1994), а також включає додатковий лист пояснюючи мету дослідження (Neuman 1994).

3.4.2. Одиниця аналізу

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

3.4.3. Зразок опитування

«Список розсилки» учасників опитування отримано від TDWI. З цього списку 3000 австралійських організацій були обрані як основа для вибірки. Вибірці було надіслано додатковий лист із поясненням проекту та мети опитування, а також бланк відповідей та попередньо оплачений конверт для повернення заповненої анкети. З 3000 організацій 198 погодилися взяти участь у дослідженні. Така невелика кількість відповідей була очікуваною дате велика кількість австралійських організацій, які тоді прийняли або впроваджували стратегію зберігання даних у своїх організаціях. Таким чином, цільова група для цього дослідження складається лише з 198 організацій.

3.4.4. Зміст анкети

Структура анкети базувалася на моделі сховища даних Монаша (розглянуто раніше в частині 2.3). Зміст анкети базувався на аналізі літератури, представленому в розділі 2. Копію анкети, надісланої учасникам опитування, можна знайти в Додатку B. Анкета складається з шести розділів, які відповідають фазам розглянутої моделі. Наступні шість параграфів коротко підсумовують зміст кожного розділу.

Розділ А: Основна інформація про організацію
Цей розділ містить запитання, що стосуються профілю організацій-учасниць. Крім того, деякі запитання стосуються статусу проекту зі сховища даних учасника. Конфіденційна інформація, така як назва організації, не була розкрита в аналізі опитування.

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

Розділ C: Дизайн
У цьому розділі містяться запитання щодо планування діяльності сховище даних. Зокрема, питання стосувалися обсягу виконання, тривалості проекту, вартості проекту та аналізу витрат і вигод.

Розділ D: Розвиток
У розділі розвитку є питання, що стосуються діяльності розвитку сховище даних: збірник вимог кінцевого споживача, джерела дані, логічна модель дані, прототипи, планування потужностей, технічні архітектури та вибір інструментів розробки сховищ даних.

Розділ E: Операція
Експлуатаційні питання, пов'язані з роботою та розширюваністю сховище даних, як він розвивається на наступному етапі розвитку. Там якість даних, стратегії оновлення дані, зернистість дані, масштабованість сховище даних і питання безпеки сховище даних були серед запитань.

Розділ F: Розвиток
Цей розділ містить запитання щодо використання сховище даних кінцевими користувачами. Дослідника цікавило призначення та корисність в сховище даних, прийняті стратегії перегляду та навчання та стратегія контролю сховище даних усиновлений.

3.4.5. Швидкість відповіді

Незважаючи на те, що опитування поштою критикують за низький відсоток відповідей, було вжито заходів для збільшення відсотка повернення (як обговорювалося раніше в частині 3.4.1). Термін «коефіцієнт відповідей» означає відсоток людей у ​​конкретній вибірці опитування, які відповіли на запитання анкети (Denscombe 1998). Для розрахунку частоти відповідей для цього дослідження була використана наступна формула:

Кількість людей, які відповіли
Частка відповідей = ———————————————————————————– X 100 Загальна кількість надісланих анкет

3.4.6. Пілотне випробування

Перед тим, як опитувальник було надіслано до вибірки, питання були досліджені шляхом проведення пілотних тестів, як запропоновано Лаком і Рубіном (1987), Джексоном (1988) і де Во (1991). Метою пілотних тестів є виявлення будь-яких незручних, двозначних виразів і питань, які важко інтерпретувати, уточнення будь-яких визначень і термінів, що використовуються, і визначення приблизного часу, необхідного для заповнення анкети (Warwick і Lininger 1975, Jackson 1988, Salant і Ділман 1994). Пілотні тести були проведені шляхом вибору суб’єктів із характеристиками, подібними до останніх суб’єктів, як запропонував Девіс Е. Козенца (1993). У цьому дослідженні шість фахівців зі сховищ даних були обрані в якості пілотних суб’єктів. Після кожного пілотного випробування вносилися необхідні корективи. Завдяки проведеним пілотним тестам учасники зробили свій внесок у переформатування та скидання остаточної версії анкети.

3.4.7. Методи аналізу за Давати

I дані опитувань, зібраних із закритих анкет, було проаналізовано за допомогою статистичного пакету програм під назвою SPSS. Багато відповідей було проаналізовано за допомогою описової статистики. Деякі анкети були повернуті неповними. До них ставилися з більшою увагою, щоб гарантувати, що i дані пропущені не були наслідком помилок при введенні даних, а тому, що запитання не підходили реєстранту, або реєстрант вирішив не відповідати на одне чи кілька конкретних запитань. Ці відсутні відповіді були проігноровані під час аналізу дані і були закодовані як «- 9», щоб гарантувати їх виключення з процесу аналізу.

При підготовці анкети закриті питання були попередньо закодовані шляхом присвоєння номера кожному варіанту. Потім число було використано для підготовки дані під час аналізу (Denscombe 1998, Sapsford and Jupp 1996). Наприклад, у питанні 1 розділу Б було шість варіантів: рада директорів, вищий керівник, ІТ-відділ, бізнес-підрозділ, консультанти та інше. У файлі дані SPSS було створено змінну, яка вказує на «ініціатора проекту» з шістьма мітками значень: «1» для «ради директорів», «2» для «старшого керівника» тощо. Використання шкали Лайкертіна в деяких закритих питаннях також дозволило легко ідентифікувати за допомогою відповідних числових значень, введених у SPSS. Для запитань із невичерпними відповідями, які не були взаємовиключними, кожен варіант розглядався як одна змінна з двома мітками значення: «1» для «відміченого» та «2» для «не відзначеного».

Відкриті питання трактувалися по-різному від закритих. Відповіді на ці запитання не були внесені до SPSS. Натомість їх аналізували вручну. Використання цього типу запитань дозволяє нам отримати інформацію про вільно висловлені ідеї та особистий досвід респондентів (Bainbridge 1989, Denscombe 1998). Там, де це було можливо, було зроблено класифікацію відповідей.

Для аналізу данівикористовуються прості методи статистичного аналізу, такі як частота відповідей, середнє значення, стандартне відхилення та медіана (Argyrous 1996, Denscombe 1998).
Гамма-тест показав хороші результати для отримання кількісних показників асоціацій між дані порядкові (Norusis 1983, Argyrous 1996). Ці тести були доречними, оскільки використовувані порядкові шкали не мали багатьох категорій і могли бути представлені в таблиці (Norusis 1983).

3.5 Підсумок

У цьому розділі обговорювалися методологія дослідження та дизайн, прийняті для цього дослідження.

Вибір найбільш прийнятного методу дослідження для конкретного дослідження враховує
врахування ряду правил, включаючи характер і тип дослідження, а також переваги та недоліки кожного можливого методу (Jenkins 1985, Benbasat et al. 1097, Galliers and Land 1987, yin 1989, Hamilton and Ives 1992, Galliers 1992, Нойман 1994). Враховуючи відсутність існуючих знань і теорії щодо впровадження сховищ даних в Австралії, це дослідження потребує інтерпретаційного методу дослідження з пошуковою здатністю досліджувати досвід австралійських організацій. Обраний метод дослідження було обрано для збору інформації щодо прийняття концепції сховищ даних австралійськими організаціями. Методикою збору було обрано поштову анкету дані. Обґрунтування методу дослідження та техніки збирання дані вибрані будуть надані в цьому розділі. Крім того, було представлено обговорення одиниці аналізу, використаної вибірки, відсотка відповідей, змісту анкети, попереднього тесту анкети та методу аналізу дані.

Проектування a Інформаційне сховище:

Поєднання зв’язків сутностей і розмірного моделювання

РЕЗЮМЕ
Зберігання i дані є актуальною проблемою для багатьох організацій. Ключове питання в розробці комп'ютерних накопичувачів дані це його дизайн.
Дизайн повинен підтримувати виявлення концепцій у сховище даних до застарілої системи та інших джерел дані а також легкість розуміння та ефективність у реалізації сховище даних.
Значна частина зберігання літератури с дані рекомендує використовувати моделювання зв’язків сутностей або розмірне моделювання для представлення дизайну сховище даних.
У цій статті ми показуємо, як обидва представлення можна поєднати в одному підході до малювання сховище даних. Використовується системний підхід

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

СКЛОЩИЩЕ ДАНИХ

Un сховище даних його зазвичай визначають як «предметно-орієнтований, інтегрований, змінний у часі та енергонезалежний збір даних на підтримку рішень керівництва» (Inmon and Hackathorn, 1994). Предметно-інтегроване вказує на те, що сховище даних розроблено таким чином, щоб перетинати функціональні межі систем Legaci, щоб запропонувати інтегровану перспективу дані.
Варіант часу впливає на історичний або часовий характер дані в а сховище даних, що дозволяє аналізувати тенденції. Енергонезалежний вказує на те, що сховище даних він не оновлюється постійно, як a база даних OLTP. Швидше він періодично оновлюється, с дані надходять із внутрішніх і зовнішніх джерел. The сховище даних він спеціально розроблений для пошуку, а не для оновлення цілісності та продуктивності операцій.
Ідея зберігання i дані не нова, це була одна з цілей управління дані з шістдесятих (The Martin, 1982).
I сховище даних вони пропонують інфраструктуру дані для систем підтримки управління. Системи підтримки управління включають системи підтримки прийняття рішень (СППР) та виконавчі інформаційні системи (ЕІС). DSS — це комп’ютерна інформаційна система, розроблена для покращення прийняття рішень людиною. EIS зазвичай є системою доставки дані що дозволяє керівникам компаній легко отримати доступ до перегляду дані.
Загальна архітектура а сховище даних висвітлює роль сховище даних в управлінській підтримці. А також пропонувати інфраструктуру дані для EIS і DSS, ін сховище даних до нього можна отримати прямий доступ через запити. THE дані включені в a сховище даних базуються на аналізі вимог до управлінської інформації та отримані з трьох джерел: внутрішніх застарілих систем, систем збору даних спеціального призначення та зовнішніх джерел даних. THE дані у внутрішніх застарілих системах вони часто надлишкові, суперечливі, низької якості та зберігаються в різних форматах, тому їх потрібно узгодити та очистити, перш ніж їх можна буде завантажити в

сховище даних (Inmon, 1992; McFadden, 1996). THE дані надходять із систем зберігання дані ad hoc і з джерел дані зовнішні часто використовуються для доповнення (оновлення, заміни) i дані із застарілих систем.

Є багато вагомих причин для розвитку a сховище даних, які включають покращене прийняття рішень за рахунок ефективного використання більшої кількості інформації (Ives 1995), підтримку зосередженості на цілісних угодах (Graham 1996) та скорочення дані для EIS і DSS (Graham 1996, McFadden 1996).

Недавнє емпіричне дослідження показало, що в середньому рентабельність інвестицій для сховище даних на 401% через три роки (Graham, 1996). Однак інші емпіричні дослідження сховище даних виявлено значні проблеми, включаючи складність у вимірюванні та розподілі переваг, відсутність чіткої мети, недооцінку мети та складність процесу зберігання переваг дані, зокрема щодо джерел і чистоти дані. Зберігання i дані можна розглядати як вирішення проблеми управління дані між організаціями. Маніпуляція дані як соціальний ресурс він залишався однією з ключових проблем в управлінні інформаційними системами в усьому світі протягом багатьох років (Brancheau та ін. 1996, Galliers та ін. 1994, Нідерман та ін. 1990, Перван 1993).

Популярний підхід до управління дані у вісімдесятих це була розробка моделі дані соціальні. Модель дані social був розроблений, щоб запропонувати стабільну основу для розробки нових прикладних систем і база даних а також реконструкція та інтеграція застарілих систем (Brancheau et al.

1989, Goodhue та ін. 1988:1992, Кім і Еверест 1994). Проте існує багато проблем із цим підходом, зокрема, складність і вартість кожного завдання, а також тривалий час, необхідний для отримання відчутних результатів (Beynon-Davies 1994, Earl 1993, Goodhue et al. 1992, Periasamy 1994, Shanks 1997). ).

Il сховище даних це окрема база даних, яка існує разом із застарілими базами даних, а не замінює їх. Таким чином, це дозволяє керувати керуванням дані і уникнути дорогої реконструкції застарілих систем.

ІСНУЮЧІ ПІДХОДИ ДО ПРОЕКТУВАННЯ ДАНИХ

WAREHOUSE

Процес побудови та вдосконалення a сховище даних його слід розуміти більше як еволюційний процес, а не як життєвий цикл розвитку традиційних систем (Дезіо, 1995, Shanks, O'Donnell and Arnott 1997a ). У проект входить багато процесів сховище даних такі як ініціалізація, планування; інформація, отримана з вимог, поставлених керівникам компанії; джерела, перетворення, очищення о дані і синхронізація із застарілих систем та інших джерел дані; системи доставки в розробці; моніторинг сховище даних; і безглуздість еволюційного процесу та побудови а сховище даних (Stinchi, O'Donnell and Arnott 1997b). У цьому журналі ми зосереджуємося на тому, як малювати дані зберігаються в контексті цих інших процесів. Існує ряд запропонованих підходів до архітектури сховище даних в літературі (Inmon 1994, Ives 1995, Kimball 1994 McFadden 1996). Кожна з цих методологій має короткий огляд з аналізом їх сильних і слабких сторін.

Підхід Інмона (1994). Інформаційне сховище дизайн

Інмон (1994) запропонував чотири ітераційні кроки для розробки a сховище даних (див. малюнок 2). Першим кроком є ​​розробка шаблону дані соціальні, щоб зрозуміти, як я дані їх можна інтегрувати між функціональними сферами всередині організації шляхом поділу дані зберігати в районах. Модель дані це зроблено для зберігання дані що стосуються прийняття рішень, в т.ч дані істориків, і вкл дані виведені та агреговані. Другим кроком є ​​визначення тематичних областей для впровадження. Вони базуються на пріоритетах, визначених конкретною організацією. Третій крок передбачає малювання a база даних для предметної області зверніть особливу увагу на включення відповідних рівнів деталізації. Inmon рекомендує використовувати модель сутностей і зв’язків. Четвертий крок — ідентифікація вихідних систем дані необхідні та розробити процеси трансформації для захоплення, очищення та форматування i дані.

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

Айвз (1995) Підхід до Інформаційне сховище дизайн

Айвз (1995) пропонує чотириетапний підхід до проектування інформаційної системи, який, на його думку, можна застосувати до проектування сховище даних (дивіться малюнок 3). Підхід значною мірою базується на інформаційній інженерії для розробки інформаційних систем (Мартін, 1990). Першим кроком є ​​визначення цілей, критичних факторів і факторів успіху та ключових показників ефективності. Ключові бізнес-процеси та необхідна інформація моделюються, щоб привести нас до моделі дані соціальні. Другий крок передбачає розробку визначальної архітектури дані зберігається за областями, база даних di сховище даних, необхідні технологічні компоненти, набір організаційної підтримки, необхідної для впровадження та роботи сховище даних. Третій крок включає вибір необхідних програмних пакетів та інструментів. Четвертий крок – детальне проектування та будівництво сховище даних. Айвз зазначає, що зберігання дані це обмежений ітераційний процес.

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

Підхід Кімболла (1994). Інформаційне сховище дизайн

Кімбол (1994) запропонував п'ять ітераційних кроків для розробки a сховище даних (див. малюнки 4). Його підхід особливо присвячений дизайну соло сховище даних а також щодо використання розмірних моделей, надаючи перевагу моделям сутностей і зв’язків. Кімбол аналізує ці багатовимірні моделі, тому що бізнес-лідерам легше зрозуміти бізнес, це ефективніше під час складних консультацій, а дизайн база даних фізичний є більш ефективним (Kimball 1994). Кімбол визнає, що розвиток a сховище даних це повторюється, і це сховище даних окремі таблиці можна об'єднати, розділивши їх на таблиці загальних розмірів.

Першим кроком є ​​визначення конкретної предметної області, яку потрібно вдосконалити. Другий і третій кроки стосуються розмірного моделювання. На другому кроці заходи визначають цікаві речі в предметній області та групують у таблицю фактів. Наприклад, у предметній області продажів показники інтересу можуть включати кількість проданих товарів і долар як валюту продажу. Третій крок передбачає визначення параметрів, які є способами групування фактів. У предметній області продажів релевантні параметри можуть включати товар, місце та період часу. Таблиця фактів має багатокомпонентний ключ, який зв’язує її з кожною з таблиць вимірювань, і зазвичай містить дуже велику кількість фактів. Навпаки, таблиці параметрів містять описову інформацію про параметри та інші атрибути, які можна використовувати для групування фактів. Пов’язана запропонована таблиця фактів і розмірів утворює те, що називається зірковою схемою через її форму. Четвертий крок передбачає побудову a база даних багатовимірний для вдосконалення візерунка зірки. Останнім кроком є ​​ідентифікація вихідних систем дані необхідні та розробити процеси трансформації для захоплення, очищення та форматування i дані.

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

Підхід Макфаддена (1996) до даних Дизайн складів

McFadden (1996) пропонує п'ятиетапний підхід до розробки a сховище даних (див. Малюнок 5).
Його підхід ґрунтується на синтезі ідей із літератури та орієнтований на проектування єдиного сховище даних. Перший крок передбачає аналіз вимог. Хоча технічні специфікації не прописані, нотатки Макфаддена ідентифікують сутності дані специфікації та їхні атрибути, а також посилається на читачів Watson і Frolick (1993) для захоплення вимог.
На другому кроці розробляється модель відносин сутності сховище даних а потім підтверджено керівниками підприємств. Третій крок включає визначення відображення із застарілих систем і зовнішніх джерел сховище даних. Четвертий крок включає процеси розробки, розгортання та синхронізації дані нель сховище даних. На останньому етапі розробляється поставка системи з особливим акцентом на інтерфейс користувача. Макфедден зазначає, що процес малювання, як правило, повторюється.

Сильні сторони підходу Макфаддена вказують на участь бізнес-лідерів у визначенні вимог, а також важливість ресурсів дані, їх очищення та збір. Його недоліки включають відсутність процесу розбиття великого проекту сховище даних у багатьох інтегрованих етапах, і

труднощі з розумінням моделей сутностей і зв’язків, які використовуються при проектуванні сховище даних.

Вибирають нас не лише ті, хто нам близький.