Сховища даних повернення до основ
Ретельне планування – запорука успішної реалізації проекту створення сховища даних
Отже, ви готові розпочати свій перший проект створення сховища даних. З чого почати? Або можливо, ви вже підходите до стадії впровадження сховища, але відчуваєте, що проект веде кудись убік, і вам необхідно вжити рішучих заходів, щоб повернути його на правильний курс. Що потрібно знати, щоб забезпечити його успішне завершення? Давайте відступимо ненадовго від подробиць застосування і повернемося до тих основних віх на шляху успішного розгортання сховища даних, які обов'язково повинні бути пройдені на етапах аналізу та проектування. Дорогою згадаємо основні необхідні терміни та обговоримо деякі труднощі, з якими доводиться стикатися на цьому шляху. Дотримання викладених рекомендацій може суттєво підняти шанси на успіх при створенні сховища даних.
Загальна термінологія
Насамперед, визначимо основні частини проекту: сховище даних, вітрина даних та робота зі зберігання даних. Незважаючи на те, що ці три терміни часто взаємно замінюють один одного, у кожного з них є свої особливості, і поняття, що лежать в їх основі, надають різний вплив на хід виконання проекту. Сховище є об'єднуючою моделлю даних для центрального вмістилища інформації про всю організацію повністю. Важливо, що з визначенні сховища ми навмисно не згадуємо кількість баз даних. Навпаки, ми вважаємо, що сховище є повною та інтегрованою моделлю даних підприємства, яка не прив'язана до конкретних відомостей про те, де або яким чином зберігається інформація.
Вітрина даних зберігає інформацію про діяльність певної групи у структурі підприємства. Всявідомості вітрини беруться із сховища даних і безпосередньо пов'язані з інформаційною моделлю підприємства. Часто вітрини даних містять сумовані або агреговані дані, якими легко можуть скористатися співробітники організації. Ще один спосіб розрізнити вітрину та сховище даних – поглянути на них з позиції споживачів інформації та формату її зберігання. Аналітики інформаційних підрозділів та засоби генерації стандартних звітів, як правило, використовують інформацію сховищ даних, яка зазвичай зберігається у закодованому та зашифрованому вигляді. Інші користувачі працюють з вітринами даних, в яких інформація зберігається в більш зручному для читання форматі. Наприклад, з метою зниження трудомісткості складання складних запитів і полегшення роботи тих користувачів, хто цілком вільно володіє мовою SQL, таблиці даних вітрини може бути ненормалізованими, тобто містити розкодовані значення величин.
Нарешті, робота із зберігання даних полягає у управлінні як сховищами, і вітринами даних. Цей процес включає задоволення всіх потреб, що виникають на етапах очищення та вивіряння інформації, а також супроводження баз даних. Крім того, він передбачає постійне уточнення та вдосконалення базових моделей даних.
p align="justify"> Важливий аспект у розробці сховища даних пов'язаний зі створенням словника даних, яким могли б користуватися не тільки члени команди проектувальників, але і кінцеві користувачі. Словник необхідний як джерело визначень даних, і навіть розуміння елементів даних сховища. На перший погляд це положення здається простим і безперечним, але при збиранні інформації з багатьох різних систем виникає проблема трактування даних, яку іноді усвідомлюють вже на етапі розгортання сховища. Проблема полягаєу цьому, що у різних системах спостерігаються незначні розбіжності у розумінні однаково званих понять. Проблему розбіжності трактування термінів можна проілюструвати з прикладу такого широко застосовуваного у охороні здоров'я поняття як Обслуговуючий лікар. У системі, що відстежує щоденну активність пацієнтів, це поняття означає лікаря, який відповідає за лікування хворого в даний час. В іншій системі, сфокусованій на обробці рахунків пацієнтів, застосовується дещо інше трактування. Обслуговуючим називається лікар, який здійснив візит до хворого, внаслідок чого на його ім'я виписується рахунок. Обидва визначення коректні у своєму контексті, але відмінність у тому тлумаченні ілюструє складності, що виникають при об'єднанні відомостей із цих двох систем.
Приклад з охорони здоров'я ілюструє проблему, яку потрібно вирішувати на найтоншому та найвідповідальнішому етапі проекту створення сховища даних - етапі формування команди для виконання проекту. Команда повинна складатися як з розробників, так і користувачів, причому дуже важливо, щоб до неї увійшли саме ті люди, які необхідні для успішного виконання проекту. Члени команди повинні володіти знаннями у відповідній галузі бізнесу, щоб уміти пояснити, як і для чого використовуються дані. Вони повинні знати системи настільки, щоб зуміти отримати необхідні дані. Крім того, вони неодмінно повинні мати необхідні аналітичні та проектні вміння та навички для того, щоб об'єднати всю зібрану інформацію в єдиному сховищі даних. Відмінність побудови сховища даних від інших проектів полягає в тому, що звичайні проекти націлені на якусь одну область бізнесу, у той час як сховище даних концентрується на об'єднанні даних та відповідних знань із самихрізноманітних проектів. Тому команда повинна мати глибину і широту, необхідні для охоплення всіх систем, що зачіпаються.
Концепція проекту
Тепер, коли визначено фазу проекту з найбільшим ризиком, настав час розглянути низку кроків, які слід зробити для зниження цього ризику. Щоб сформувати таку команду, яка забезпечить успішне виконання проекту, насамперед слід описати у формі концепції загальне бачення проекту, а потім розпочати встановлення його масштабів. Після того, як це буде зроблено, ви зможете ясніше побачити, яких користувачів та співробітників підрозділу ІТ необхідно залучити до участі в проекті. Концепція проекту складається з метою визначити призначення проекту, виходячи з перспектив бізнесу. Теоретично всі роботи з проекту прямо чи опосередковано націлені виконання завдань, поставлених у концепції. При цьому дуже важливо сформулювати ясні та реальні цілі проекту. Точне формулювання завдань дозволяє оцінити основні показники проекту для команди - терміни виконання, результати і вартість, що досягаються. цілі даного проекту. Решта треба або виключити зовсім, або відкласти до наступних етапів розвитку проекту. Концепція проекту виступає як критерій значимості кожному етапі життєвого циклу проекту. В ідеальному випадку всі роботи з проекту служать досягненню цілей, сформульованих у концепції.
Розглянемо як приклад зростаючу організацію, яка займається охороною здоров'я. У ній кожному виду обладнання відповідає свояінформаційна система. Тоді концепція побудови сховищ даних для такої організації може полягати в тому, щоб створити єдиний засіб для огляду, аналізу та відстеження хронологічних даних по всіх системах у відповідному свідомому контексті. Подібна концепція визначає мету, яку можна досягти шляхом впровадження сховища даних.
Визначення масштабів
Після визначення загального бачення проекту можна встановити його масштаби. Нездатність правильно задати масштаби проекту стоїть у ряді факторів ризику на другому місці після набору невідповідної команди для виконання робіт. Оскільки масштаб визначає обсяг того, що належить зробити, від правильності вибору залежить, чи буде проект успішно виконаний протягом заданого часу. Часто в проект створення сховища даних прагнуть включити дуже багато, намагаючись осягнути неосяжне. У результаті проект виходить за допустимі часові межі, а іноді його взагалі припиняють. Інша крайність, побудова " димоходів " , виникає у тому випадку, як у організації приймають рішення про побудову безлічі невеликих баз даних, кожна з яких фокусується на вузькій області бізнесу. Хоча в сукупності всі ці бази даних і можуть виглядати як сховище даних, по суті вони представляють лише покращений інтерфейс доступу до інформації оперативних систем (або покращений засіб складання звітів). Така конструкція не є сховищем даних, оскільки кожна з цих баз даних існує сама по собі, вони не пов'язані одна з одною єдиною інформаційною моделлю. У тих роботи зі сховищами даних створення системи " димоходів " не переслідує будь-якої мети лише на рівні підприємства.
Для вибору правильного масштабу проекту важливу роль відіграє розуміння визначень техосновоположних понять, що були наведені вище. Незважаючи на те, що сховище даних враховує весь бізнес підприємства цілком, не потрібно вводити його в експлуатацію відразу в повному обсязі. Якщо концентруватися на окремих сферах бізнесу в рамках загальної моделі, то процес проектування та розробки може бути ітеративним. При цьому протягом одного періоду часу можна вводити один-два фрагменти сховища. Ітеративна розробка призводить до швидшого повернення інвестицій, особливо при пріоритетному опрацюванні найважливіших галузей бізнесу, ніж створення єдиного великомасштабного сховища даних після завершення тривалого періоду розробки. З позицій масштабування такий підхід дозволяє контролювати розміри, вартість та терміни кожної ітерації без порушення цілісності загальної моделі сховища даних.
При плануванні проекту створення сховища даних часто не враховують один важливий аспект - створення необхідної для роботи інфраструктури. Занадто багато проектів сховищ даних зазнало невдачі вже після їх здачі в експлуатацію лише тому, що при проектуванні не було враховано витрати на супровід, включаючи необхідні ресурси, час та координацію діяльності з оновлення даних сховища. Проектувальники могли розробити найкращу у світі модель даних і створити величезну базу даних, але якщо користувачі не зможуть отримувати ту інформацію, яка їм необхідна, вони будуть вважати проект невдалим. Залежно від мінливості джерел інформації сховище досить швидко може перетворитися на склад застарілих відомостей. При визначенні періодичності оновлення інформації сховища необхідно виходити із частоти зміни даних у системах-джерелах, а також із потреб користувачів у своєчасному відображенні цихзмін.
Сутність сховищ даних
Досі ми обговорювали деякі проблеми планування проекту та основні принципи проектування, які застосовуються при створенні сховищ даних. Настала черга перейти до самої сутності роботи зі сховищами даних: придбання даних, їх перетворення та подання користувачам. Ці питання становлять основу роботи зі сховищами даних і потребують повного розуміння, щоб уникнути проблем із оновленням даних.
Придбанням даних називається завдання збору інформації в сховище з різних джерел даних. У переважній більшості випадків підприємства використовують кілька оперативних інформаційних систем, які автоматизують щоденну діяльність підприємства. Ці системи виступають у ролі джерел даних сховища. Такі системи можуть бути реалізовані різними способами: розміщуватися на центральній обчислювальній машині, або являти собою додаток з архітектурою клієнт/сервер, або відноситися до прикладних систем третіх фірм з власними сховищами інформації. Вони можуть розташовуватися в персональних комп'ютерах у вигляді електронних таблиць і баз даних, а також є довільною комбінацією перерахованих варіантів реалізації. Завдання полягає в тому, щоб ідентифікувати джерела даних та доставляти з них інформацію до сховища відповідно до продуманого розкладу.
Після збирання даних необхідно їх трансформувати. В ідеальній організації всі системи використовують одні й самі набори кодів і однакові визначення елементів даних. Насправді все не так - вище ми вже демонстрували на прикладі, що для тих самих за своєю суттю елементів даних у різних системах існують різні коди та визначення. Перетворенняданих є процес очищення інформації та перевірки її достовірності, в ході якого відсікаються всі неточні дані. В результаті значення, що пройшли всі перевірки, гарантовано відповідають стандартним визначенням. І нарешті, після завершення всіх процедур трансформації, дані потрапляють до сховища.
Тепер настає черга вирішувати завдання представлення даних. На цьому етапі сховище являє собою величезну нормалізовану базу даних, що містить повну (або часткову) інформацію про діяльність організації. Чудово! Але, на жаль, користувачі не можуть використовувати її в такому вигляді через те, що дані закодовані та зберігаються у нормалізованих таблицях. Подання даних зводиться до вилучення відомостей зі сховища та перетворення їх до такого виду, який був би зрозумілий та зручний користувачам. Один із способів представлення даних кінцевим користувачам - це розгортання вітрини даних, що містить сумовану та агреговану інформацію. Інший підхід – розмістити між користувачем та сховищем даних шар програмного забезпечення, що реалізує функції OLAP. Інші шляхи полягають у тому, щоб або самостійно побудувати спеціальні засоби формування звітів, або застосувати рішення трьох фірм. Вам слід вибрати найбільш прийнятний спосіб подання даних та застосувати його.
При виконанні цих завдань не забувайте, що отримані користувачами дані повинні бути цілісними, точними та своєчасними. Нездатність гарантувати виконання цих вимог може знищити успіх проекту, оскільки користувачі не працюватимуть із неточними чи застарілими відомостями. Один із шляхів мінімізації ризику появи поганих даних - залучення користувачів до процедур очищення, перевірки достовірності та трансформуванняданих, що виконуються на етапі перетворення. Чим більше користувачі беруть участь у процедурах введення даних у сховище та їх подальшого очищення та перетворення, тим більше довіри вони випробовуватимуть до інформації зі сховища даних. Крім того, необхідно підкреслювати роль та внесок користувачів у процес перевірки достовірності інформації. Поясніть їм, що завдяки своїм знанням та досвіду вони стають невід'ємною частиною команди і, зрештою, забезпечують достовірність та цілісність даних.