Головна → Безпека комп'ютера Корпоративна модель даних може бути. Створення моделі сховищ даних на основі корпоративної моделі даних

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

Надіслати свою гарну роботу до бази знань просто. Використовуйте форму нижче

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

Розміщено на http://www.allbest.ru/

1. Реляційна модель даних

1.1. Реляційна модель даних. Основні визначення
1.2 Операції над відносинами

2. Корпоративні інформаційні системи
Список використаної літератури

1. Реляційна модель даних

1.1. Реляційна модель даних. Основні визначення

У математичних дисциплінах поняття "таблиця" відповідає поняття "відношення" (relation). Таблиця відбиває об'єкт реального світу - сутність, а кожен її рядок відбиває конкретний екземпляр сутності. Кожен стовпець має унікальне для таблиці ім'я. Рядки не мають імен, порядок їхнього слідування не визначено, а кількість логічно не обмежена. Однією з основних переваг реляційної моделі даних є однорідність (кожен рядок таблиці має один формат). Користувач сам вирішує питання, чи мають відповідні сутності однорідністю. Цим вирішується проблема придатності моделі.

Основні поняття:

* Відношення є двовимірною таблицею, що містить деякі дані.

* Сутність - об'єкт будь-якої природи, дані про який зберігаються у БД. Атрибути – властивості, що характеризують сутність (стовпці).

* Ступінь відношення - кількість стовпців.

* Схема відношення - список імен атрибутів, наприклад, СПІВРОБІТНИК (№, ПІБ, Рік народження, Посада, Кафедра).

* Домен - сукупність значень атрибутів відношення (тип даних).

* Кортеж - рядок таблиці.

* Кардинальність (потужність) – кількість рядків у таблиці.

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

* Зовнішній ключ - це атрибут (атрибути) однієї таблиці, який може бути первинним ключем іншої таблиці. Є посиланням на первинний ключ іншої таблиці.

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

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

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

1.2 Операції над відносинами

Щоб привести таблицю до першої нормальної форми (1НФ), потрібно дотриматись двох правил:

1. Атомарність чи неподільність. Кожна колонка повинна мати одне неподільне значення.

2. Таблиця не повинна містити колонок або груп даних, що повторюються.

Наприклад, якщо таблиця містить в одному полі повну адресу людини (вулиця, місто, поштовий код), не відповідатиме правилам 1НФ, оскільки міститиме різні значення в одному стовпці, що буде порушенням правила про атомарність. Або якщо бд містить дані про фільми і в ній є стовпці актор1, актор2, актор3, також не відповідатиме правилам, оскільки матиме місце повторення даних.

Починати нормалізацію слід з перевірки структури БД на сумісність із 1НФ. Усі стовпці, які є атомарними, мають бути розбиті на складові їх стовпці. Якщо таблиці є повторювані стовпці, їм потрібно виділити окрему таблицю.

Щоб привести таблицю до першої нормальної форми, слід:

* Знайти всі поля, які містять багатоскладові частини інформації.

* Ті дані, які можна розбити на складові, потрібно виносити в окремі поля.

* Винести повторювані дані в окрему таблицю.

* Перевірити, чи всі таблиці підходять під умови першої нормальної форми.

Для приведення таблиць до другої нормальної форми (2НФ), таблиці повинні бути вже в 1НФ. Нормалізація має відбуватися по порядку.

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

Щоб привести базу до другої нормальної форми, треба:

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

* Створити необхідні поля в таблицях users і forums, виділити з існуючих полів або створити нові первинні ключі.

* Для кожної таблиці потрібен свій первинний ключ

* Створити зовнішні ключі та позначаємо їх відносини між таблицями. Кінцевим кроком нормалізації до 2НФ буде виділення зовнішніх ключів зв'язку з асоційованими таблицями. Первинний ключ однієї таблиці має бути зовнішнім ключем до іншої.

Підказки:

Інший спосіб приведення схеми до 2НФ - подивитися на відносини між таблицями. Ідеальний варіант - створити всі відносини виду один до багатьох. Відносини виду багато хто до багатьох потребує реструктуризації.

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

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

Щоб привести базу до третьої нормальної форми, треба:

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

* Створити відповідні таблиці. Якщо є проблемний стовпець у кроці 1, створити окремі таблиці для нього.

* Створити чи виділити первинні ключі. Кожна таблиця повинна мати первинний ключ.

* Створити необхідні зовнішні ключі, які утворюють будь-яке із відносин.

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

2. Корпоративні інформаційні системи

реляційна модель дані система

Система (від грецького systema - ціле, складене з частин з'єднання) - це сукупність елементів, взаємодіючих друг з одним, які утворюють певну цілісність, єдність. Наведемо деякі поняття, що часто використовуються для характеристики системи.

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

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

3. Структура системи - склад, порядок та принципи взаємодії елементів системи, що визначають основні властивості системи. Якщо окремі елементи системи рознесені за різними рівнями і внутрішні зв'язки між елементами організовані тільки від вищих до нижчих рівнів і навпаки, то говорять про ієрархічну структуру системи. Чисто ієрархічні структури зустрічаються практично рідко, тому, дещо розширюючи це поняття, під ієрархічною структурою зазвичай розуміють такі структури, де серед інших зв'язків ієрархічні зв'язку мають чільне значення.

4. Архітектура системи - сукупність властивостей системи, суттєвих для користувача.

5. Цілісність системи - принципова незводність властивостей системи до суми властивостей окремих її елементів (емерджентність властивостей) і, водночас, залежність властивостей кожного елемента від його місця та функції усередині системи.

Інформаційна система - взаємопов'язана сукупність засобів, методів і персоналу, що використовуються для зберігання, обробки та видачі інформації на користь досягнення поставленої мети»

У Федеральному законі «Про інформацію, інформатизації та захист інформації» дається таке визначення:

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

Класифікація за масштабом

За масштабом інформаційні системи поділяються на такі групи:

* Поодинокі;

* групові;

* Корпоративні.

p align="justify"> Корпоративна інформаційна система - це масштабована система, призначена для комплексної автоматизації всіх видів господарської діяльності великих і середніх підприємств, у тому числі корпорацій, що складаються з групи компаній, що вимагають єдиного управління.

Корпоративною інформаційною системою може вважатися система, що автоматизує понад 80% підрозділів підприємства.

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

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

Корпоративні інформаційні системи є розвитком систем для робочих груп, вони орієнтовані великі компанії і можуть підтримувати територіально рознесені вузли чи мережі. В основному вони мають ієрархічну структуру з кількох рівнів. Для таких систем характерна архітектура клієнт-сервер зі спеціалізацією серверів або багаторівнева архітектура. Під час створення таких систем можуть використовуватися самі сервери баз даних, як і розробки групових інформаційних систем. Однак у великих інформаційних системах найбільшого поширення набули сервери Oracle, DB2 і Microsoft SQL Server.

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

Класифікація у сфері застосування

За сферою застосування інформаційні системи зазвичай поділяються на чотири групи:

* Системи обробки транзакцій;

* Системи прийняття рішень;

* інформаційно-довідкові системи;

* офісні інформаційні системи.

Список використаної літератури

1. Агальцов, В.П. Бази даних. У 2-х т. т. 2. Розподілені та віддалені бази даних: Підручник/В.П. Агальці. - М: ІД ФОРУМ, НІЦ ІНФРА-М, 2013.

2. Голіцина, О.Л. Бази даних: Навчальний посібник/ О.Л. Голіцина, Н.В. Максимов, І.І. Попов. – К.: Форум, 2012.

3. Карпова, І.П. Бази даних: Навчальний посібник/І.П. Корпова. – СПб.: Пітер, 2013.

4. Кирилів, В.В. Введення в реляційні бази даних. Введення в реляційні бази даних/В.В. Кирилов, Г.Ю. Громів. – СПб.: БХВ-Петербург, 2012.

5. Пирогов, В.Ю. Інформаційні системи та бази даних: організація та проектування: Навчальний посібник / В.Ю. Пирогів. – СПб.: БХВ-Петербург, 2009.

6. Г.М. Федорова. Інформаційні системи. – К.: Академія, 2013.

7. А.Є. Сатуніна, Л.А. Сисоєва. Управління проектом корпоративної інформаційної системи підприємства - М.: Фінанси та статистика, Інфра-М, 2009.

Розміщено на Allbest.ru

...

Подібні документи

Сутність та характеристика типів моделей даних: ієрархічна, мережева та реляційна. Базові поняття реляційної моделі даних. Атрибути, схема відношення бази даних. Умови цілісності даних. Зв'язки між таблицями. Загальні уявлення про модель даних.

курсова робота , доданий 29.01.2011

Корпоративні інформаційні системи та бази даних, їх використання для вдосконалення та налагодження ведення бізнесу. Класифікація корпоративних інформаційних систем Інформаційні системи OLTP. Оперативна аналітична обробка.

курсова робота , доданий 19.01.2011

Бази даних із двовимірними файлами та реляційні системи управління базами даних (СУБД). Створення бази даних та обробка запитів до них за допомогою СУБД. Основні типи бази даних. Базові поняття реляційних баз даних. Фундаментальні характеристики відносин.

реферат, доданий 20.12.2010

Концепція системи бази даних. Реляційна модель та її характеристики. Цілісність у реляційній моделі. Реляційна алгебра. Запитання проектування БД. Нормальні форми відносин. Проектування БД шляхом сутність-зв'язок. ER-діаграми. Мова SQL.

курс лекцій, доданий 03.10.2008

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

презентація , додано 14.10.2013

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

реферат, доданий 19.12.2011

Види та функції системи управління базами даних Microsoft Access. Ієрархічна, мережева, реляційна модель опису баз даних. Основні поняття таблиці баз даних. Особливості створення об'єктів бази даних; основні форми. Доступ до Internet у Access.

контрольна робота , доданий 08.01.2011

Сучасні системиуправління базами даних (СУБД). Аналіз ієрархічної моделі даних. Реляційна модель даних. Постреляционная модель даних як розширена реляційна модель, яка знімає обмеження неподільності даних, які у записах таблиць.

наукова робота , доданий 08.06.2010

Моделі даних управління базами даних. Концептуальні моделі даних. Роль баз даних у інформаційних системах. Реляційна модель даних. Визначення предметної галузі. Побудова моделі баз даних для інформаційної системи "Домашні тварини".

курсова робота , доданий 19.04.2011

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

Галузеві моделі даних

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

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

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

Як правило, виділяються моделі більше високого рівня(і більш загальні за змістом) та нижчого (відповідно, більш детальні). Верхній рівень моделювання – це так звані концептуальні моделі даних(conceptual data models), які дають загальну картину функціонування підприємства чи організації. Концептуальна модель включає основні концепції чи предметні галузі, критичні для функціонування організації; зазвичай їх кількість вбирається у 12-15. Така модель описує класи сутностей, важливих для організації (бізнес-об'єкти), їх характеристики (атрибути) та асоціації між парами цих класів (тобто зв'язки). Оскільки в бізнес-моделюванні термінологія ще остаточно не встояла, у різних англомовних джерелах концептуальні моделі даних можуть також називатися subject area model (що можна перекласти як моделі предметних областей) або subject enterprise data model (предметні корпоративні моделі даних).

Наступний ієрархічний рівень – це логічні моделі даних(logical data models). Вони також можуть називатися корпоративними моделями даних або бізнес-моделями. Ці моделі містять структури даних, їхні атрибути та бізнес-правила та подають інформацію, яку використовує підприємство, з погляду бізнес-перспективи. У такій моделі дані організовані у вигляді сутностей та зв'язків між ними. Логічна модель представляє дані в такий спосіб, що вони легко сприймаються бізнес-користувачами. У логічній моделі може бути виділено словник даних – перелік всіх сутностей зі своїми точними визначеннями, що дозволяє різним категоріям користувачів мати загальне розуміння всіх вхідних та інформаційних вихідних потоків моделі. Наступний, більше низький рівеньмоделювання - це вже фізична реалізація логічної моделі за допомогою конкретних програмних засобів та технічних платформ.

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

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

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

Компанія може мати два шляхи створення корпоративної логічної моделі даних: будувати її самостійно або скористатися готовою. галузевою моделлю(Industry logical data model). У разі відмінності у термінах відбивають лише різні підходидо побудови однієї й тієї ж логічної моделі. У тому випадку, якщо компанія самостійно розробляє та впроваджує власну логічну модель даних, то така модель, як правило, має назву просто корпоративної логічної моделі. Якщо ж організація вирішує користуватися готовим продуктом професійного постачальника, тоді можна говорити про галузевій логічної моделі даних. Остання є готовою логічною моделлю даних, з високим ступенем точності відбиває функціонування певної галузі. Галузева логічна модель – це предметно-орієнтований та інтегрований вид усієї інформації, яка має знаходитись у корпоративному Сховищі даних для отримання відповідей як на стратегічні, так і на тактичні бізнес-питання. Як і будь-яка інша логічна модель даних, галузева модель залежить від прикладних рішень. Вона також не включає похідні дані або інші обчислення для швидкого отримання даних. Як правило, більшість логічних структур такої моделі знаходять гарне втілення у її ефективній фізичній реалізації. Такі моделі розробляються багатьма постачальниками для різних галузей діяльності: фінансової сфери, виробництва, туризму, охорони здоров'я, страхування і т.д.

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

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

Спеціаліст у галузі бізнес-аналітики (Business Intelligence) Стів Хобермен (Steve Hoberman) виділяє п'ять факторів, які необхідно брати до уваги при вирішенні питання про придбання галузевої моделі даних. Перший – це час та засоби, необхідні для побудови моделі. Якщо організації необхідно швидко досягти результатів, то галузева модель надасть перевагу. Використання галузевої моделі не може негайно забезпечити картину всієї організації, але здатне заощадити значну кількість часу. Замість власне моделювання час буде витрачено на зв'язування існуючих структур з галузевою моделлю, а також на обговорення того, як краще налаштувати її під потреби організації (наприклад, які визначення мають бути змінені, а які елементи даних – додані).

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

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

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

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

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

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

Галузеві моделі даних забезпечують компаніям єдине інтегроване подання їхньої бізнес-інформації. Багатьом компаніям буває непросто здійснити інтеграцію своїх даних, хоча це є необхідною умовою більшості загальнокорпоративних проектів. За даними дослідження Інституту Сховищ даних (The Data Warehousing Institute, TDWI), понад 69% опитаних організацій виявили, що інтеграція є суттєвим бар'єром для впровадження нових додатків. Навпаки, здійснення інтеграції даних приносить компанії суттєвий дохід.

Галузева модель даних, крім зв'язків з уже існуючими системамидає великі переваги при здійсненні загальнокорпоративних проектів, таких як планування ресурсів підприємства (Enterprise Resource Planning, ERP), управління основними даними, бізнес-аналітика, підвищення якості даних та підвищення кваліфікації співробітників.

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

Публікації

Стів Хобермен (Steve Hoberman). Використання галузевої логічної моделі даних як корпоративної моделі.
Клодіа Імхоф (Claudia Imhoff). Оперативне створення Сховищ даних та виконання проектів Business Intelligence за допомогою моделювання даних (Fast-Tracking Data Warehousing & Business Intelligence Projects via Intelligent Data Modeling)

Щоб продавати, треба розуміти, що продаємо

Визначимося з термінологією та поняттями. ( Data Warehouse) - це не система ключових показників ефективності (КПЕ, KPI), це не велика база даних, це не аналітичний OLAP-інструмент, це не інтелектуальна система, що дозволяє видобувати нові дані та отримувати статистичні залежності, це не система єдиної НСІ – це все не ХД, якщо говорити про нього в контексті окремо взятого пункту.

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

Потенційні клієнти на корпоративне сховище даних та що вони отримують?

Як визначити потенційних корпоративних клієнтів, яким необхідне сховище даних?

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

Які вигоди клієнт отримує від запровадження корпоративного сховища даних?

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

З чого складається корпоративне сховище даних

З яких компонентів будує корпоративне сховище даних із технічної точки зору?

Компоненти корпоративного сховища даних підприємства

У клієнта завжди є Операційні системи – джерела данихдля корпоративного сховища даних Це, наприклад, бухгалтерські, білінгові, банківські тощо. системи.
Використовуючи ETL-додаток (програмне забезпечення, що дозволяє витягувати, трансформувати та завантажувати дані), дані із систем-джерел потрапляють до бази даних сховища даних. Як ETL-засоби можуть використовуватися: Informatica Power Center, IBM DataStage, Oracle Data Integrator, Oracle WareHouse Builder. Існують і продукти від інших вендорів, але вони майже не представлені на російському ринку.
Сама база данихкорпоративного сховища не є абстрактною за своєю структурою (набором таблиць, полів у них та взаємозв'язків між таблицями), а створена на основі моделі даних. Як база даних у переважній більшості використовується або Oracle, або Teradata.
Модель данихє описом усіх сутностей, об'єктів бази даних корпоративного сховища даних і включає: концептуальну модель даних, логічну модель даних та фізичну модель бази даних . На рівні концептуальної моделі визначаються сутності та взаємозв'язки між ними. На рівні логічної моделі сутності діляться на бізнес-області, їм дається докладний та повний опис, прописуються взаємозв'язки. При розробці фізичної моделі бази даних визначається вся структура бази даних - від таблиць та полів у них, до партицій та індексів. Моделі данихСьогодні на ринок постачають IBM, SAP і Oracle, але купівля моделі даних не означає автоматичну побудову правильного корпоративного сховища.Модель даних- це коробковий продукт. Її необхідно модифікувати під потреби конкретного клієнта.
Далі, вже використовуючи дані з корпоративного сховища даних, проводиться налаштування областей аналізу, звітності та вітрин даних. Згодом користувачі можуть самостійно будувати необхідну звітність і проводити багатовимірний аналіз. Як інструменти аналізу в основному використовуються Business Objects, Oracle Discoverer, IBM AlphaBlocks та інші продукти.

Як виглядають компоненти корпоративного сховища даних (модель даних, процесори ETL, вітрини даних)

Наведемо наочні приклади моделі даних, реалізації ETL-процесу, форми підтримки єдиної НСІ, вітрин даних.

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

ETL процесусунення дублікатів у вихідних даних

Форма введення даних для формування єдиного довідника

Вітрина даниху формі табличного звіту

Вітрина данихз графіком та кольоровим
виведенням даних за заданою умовою

Вітрина данихз графіком

Супутнє програмне та апаратне забезпечення

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

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

Крім самих серверів для зберігання значного обсягу інформації, необхідні дискові масиви.

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

Як правило, фахівцям та користувачам клієнта потрібне проходження курсів навчання.

Ковтун М.В. Серпень 2010

Зайцев С.Л., к.ф.-м.н.

Повторювані групи

Групами, що повторюються, є атрибути, для яких єдиний екземпляр сутності може мати більше одного значення. Наприклад, особа може мати більше однієї навички. Якщо з точки зору вимог бізнесу нам потрібно знати рівень володіння навичкою для кожного, і кожна персона може мати тільки дві навички, ми можемо створити сутність, показану на рис. 1.6. Тут представлена сутність ПЕРСОНАз двома атрибутами для збереження навичок та рівня володіння навичками для кожного.

Мал. 1.6. У цьому прикладі використовуються повторювані групи.

Проблема повторюваних груп у тому, що ми можемо точно знати, скільки навичок може мати персона. У реальному житті в деяких людей є одна навичка, у деяких - кілька, а в деяких - поки що жодного. На малюнку 1.7 представлена модель, наведена до першої нормальної форми. Зверніть увагу на доданий Ідентифікатор навички , який унікально визначає кожен НАВИК.

Мал. 1.7. Модель, наведена до першої нормальної форми.

Один факт в одному місці

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

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

У попередньому прикладі НАВИКзалежить від Ідентифікатор персониі от Ідентифікатор навички.Це означає, що у вас не з'явиться НАВИКдоти, доки не з'явиться ПЕРСОНА,що володіє цією навичкою. Це також ускладнює зміну Назви навички. Необхідно знайти кожний запис з Назвою навички та змінити її для кожної Персони, яка володіє цією навичкою.

На малюнку 1.8 представлена модель у другій нормальній формі. Зауважте, що додано сутність НАВИК, та атрибут НАЗВАнавички перенесено в цю сутність. Рівень досвіду залишився, відповідно, на перетині ПЕРСОНИ ТА НАВИКИ.

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

Кожен атрибут залежить від ключа

Кожен атрибут сутності має залежати від первинного ключа цієї сутності. У попередньому прикладі Назва школиі Географічний районприсутні у таблиці ПЕРСОНАале не описують персону. Для досягнення третьої нормальної форми необхідно перемістити атрибути у сутність, де вони залежатимуть від ключа. Малюнок 1.9. показує модель у третій нормальній формі.

Мал. 1.9. У третій нормальній формі Назва школиі Географічний регіонперенесені у сутність, де їх значення залежить від ключа.

Відносини багато-багатьом

Відносини багато хто до багатьохвідбивають реальність навколишнього світу. Зверніть увагу, що на малюнку 1.9 існує відношення багато-багатьом між ПЕРСОНОЮі ШКОЛОЙ. Ставлення точно відбиває той факт, що ПЕРСОНАможе вчитися у багатьох ШКОЛАХі в ШКОЛІможе вчитися багато ПЕРСОН.Для досягнення четвертої нормальної форми створюється асоціативна сутність, яка усуває відношення моногіє-багатьом за рахунок формування окремого запису для кожної унікальної комбінації школи та персони. На малюнку 1.10 представлена модель у четвертій нормальній формі.

Мал. 1.10. У четвертій нормальній формі відношення моногіє до багатьох між ПЕРСОНОЮі ШКОЛОЙдозволяється за рахунок введення асоціативної сутності, в якій відводиться окремий запис для кожної унікальної комбінації ШКОЛИі ПЕРСОНИ.

Формальні визначення нормальних форм

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

У заданому відношенні R атрибут Y функціонально залежить від атрибуту X. У символьному вигляді R.X -> R.Y (читається як "R.X функціонально визначає R.Y") - в тому і тільки в тому випадку, якщо кожне значення X в R асоціюється строго з одним значенням Y в R (у кожний конкретний час). Атрибути X і Y можуть бути складовими (Дейт К. Дж. Введення в системи баз даних. 6-те видання. Вид. Вільямс: 1999, 848 с.).

Відношення R відповідає першій нормальній формі (1NF) тоді і тільки тоді, коли всі його домени містять тільки атомарні значення (Дейт, там же).

Відношення R відповідає другий нормальній формі (2NF) тоді і тільки тоді, коли воно відповідає 1NF, і кожен неключовий атрибут повністю залежить від первинного ключа (Дейт, там же).

Відношення R відповідає третій нормальній формі (3NF) тоді і тільки тоді, коли воно відповідає 2NF, і кожен неключовий атрибут не транзитивно залежить від первинного ключа (Дейт, там же).

Відношення R відповідає нормальній формі Бойса-Кодда (BCNF) тоді і лише тоді, коли кожен детермінант є кандидатом на використання як ключ.

ПРИМІТКА Нижче наводиться коротке пояснення деяких абревіатур, що використовуються у визначеннях Дейта.

MVD (multi-valued dependency) – багатозначна залежність. Використовується лише для сутностей із трьома та більше атрибутами. При багатозначній залежності значення атрибуту залежить лише від частини первинного ключа.

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

JD (join dependency) - залежність щодо об'єднання. Залежно від об'єднання первинний ключ батьківської сутності простежується до нащадків, щонайменше, третього рівня зберігаючи здатність використовуватися в об'єднанні за вихідним ключем.

Відношення відповідає четвертій нормальній формі (4NF) тоді і тільки тоді, коли R існує MVD, наприклад A®B. При цьому всі атрибути R функціонально залежать від A. Іншими словами, R присутні тільки залежності (FD або MVD) форми K®X (тобто функціональна залежність атрибуту X від кандидата на використання в якості ключа K). Відповідно, R відповідає вимогам 4NF, якщо воно відповідає BCNF і всі MVD фактично є FD (Дейт, там же).

Для п'ятої нормальної форми відношення R задовольняє залежності по об'єднанню (JD) * (X, Y, ..., Z) тоді і тільки тоді, коли R еквівалентно його проекцій на X, Y, ..., Z де X, Y,. .., Z підмножини безлічі атрибутів R.

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

Бізнес-нормальні форми

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

Перша бізнес-нормальна форма (1BNF) виносить групи, що повторюються, в іншу сутність. Ця сутність отримує власне ім'я та первинні (складові) ключові атрибути з вихідної сутності та її групи, що повторюється.

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

Третя бізнес-нормальна форма (3BNF) виносить атрибути, які від первинного ключа, в іншу сутність, де вони повністю залежить від первинного ключа цієї сутності.

Четверта бізнес-нормальна форма (4BNF) виносить атрибути, які залежать від значення первинного ключа або є необов'язковими у вторинну сутність, де вони повністю залежать від значення первинного ключа або де вони повинні (обов'язково) бути присутніми в цій сутності.

П'ята бізнес-нормальна форма (5BNF) проявляється як структурна сутність, якщо є рекурсивна чи інша залежність між екземплярами вторинної сутності, або якщо рекурсивна залежність існує між екземплярами її первинної сутності.

Завершена логічна модель даних

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

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

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

ПРИМІТКА Множинність зв'язку описує максимальну кількість екземплярів вторинної сутності, які можуть бути пов'язані з екземпляром вихідної сутності.Необхідність існування абоможливість відсутності зв'язку служить визначення мінімального числа екземплярів вторинної сутності, які можуть бути пов'язані з екземпляром вихідної сутності.

Фізична модель даних

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

У ERwin фізична модель є графічним уявленням реально реалізованої бази даних. Фізична база даних складатиметься з таблиць, стовпців та зв'язків. Фізична модель залежить від платформи, обраної для реалізації, та вимог до використання даних. Фізична модель для IMS серйозно відрізнятиметься від такої ж моделі для Sybase. Фізична модель для OLAP-звітів виглядатиме інакше, ніж модель для OLTP (оперативної обробки транзакцій).

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

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

Збір вимог щодо використання даних

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

Вимоги до доступу та продуктивності

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

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

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

Вимоги до формування звітів та стандартних запитів, які допомагають адміністратору бази даних формувати індекси

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

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

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

Компоненти фізичної моделі даних

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

Зворотне проектування

Коли логічна модель недоступна, виникає необхідність відтворення моделі з бази даних. У ERwin цей процес називається зворотним проектуванням. Зворотне проектування може здійснюватися кількома способами. Розробник моделі може досліджувати структури даних у базі даних та відтворити таблиці у візуальному середовищі моделювання. Ви можете імпортувати мову опису даних (DDL - data definitions language) в інструмент, який підтримує проведення зворотного проектування (наприклад, Erwin). Розвинені засоби, такі як ERwin, включають функції, що забезпечують зв'язок через ODBC з існуючою базою даних для створення моделі шляхом прямого читання структур даних. Зворотне проектування з використанням ERwin детально обговорюватиметься в одній з наступних публікацій.

Використання корпоративних функціональних кордонів

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

ПРИМІТКА Деякі мої колеги називають ці корпоративні функціональні межі моделюванням реального світу. Моделювання реального світу спонукає розробника моделі розглядати інформацію у термінах реально властивих їй відносин та взаємозв'язків.

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

Що таке корпоративна модель?

Корпоративна модель даних (EDM - enterprise data model)містить сутності, атрибути та відносини, які представляють інформаційні потреби корпорації. EDM зазвичай поділяється у відповідність до предметних областей, які представляють групи сутностей, що належать до підтримки конкретних потреб бізнесу. Деякі предметні області можуть покривати такі специфічні бізнес-функції, як управління контрактами, інші об'єднувати сутності, що описують продукти чи послуги.

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

EDMтакож включає специфічні сутності, які визначають область визначення значень ключових атрибутів. Ці сутності немає батьків і визначаються як незалежні. Незалежні сутності часто використовуються підтримки цілісності зв'язків. Ці сутності ідентифікуються кількома різними іменами, такими як кодові таблиці, таблиці посилань, таблиці типів чи класифікаційні таблиці. Ми використовуватимемо термін "корпоративний бізнес-об'єкт". Корпоративний бізнес-об'єкт – це сутність, яка містить набір значень атрибутів, що не залежать від жодної іншої сутності. Корпоративні бізнес-об'єкти у межах корпорації слід використовувати однаково.

Побудова корпоративної моделі даних шляхом нарощування

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

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

Поняття методології моделювання

Існує кілька методологій візуального моделювання даних. ERwin підтримує дві:

IDEF1X (Integration Definition for Information Modeling – інтегрований опис інформаційних моделей).

IE (Information Engineering – інформаційна інженерія).

IDEF1X - хороша методологія та використання її нотації широко поширене

Інтегрований опис інформаційних моделей

IDEF1X - високо структурована методологія моделювання даних, що розширює методологію IDEF1, прийняту як стандарт FIPS (Federal Information Processing Standards - федеральний орган стандартів обробки інформації). IDEF1X використовує строго структурований набір типів конструкцій моделювання та призводить до моделі даних, яка потребує розуміння фізичної природи даних до того, як така інформація може стати доступною.

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

Інформаційний інжиніринг

Клайва Фінклештейна часто називають батьком інформаційного інжинірингу, хоча подібні ж концепції викладав разом з ним і Джеймс Мартін (Martin, James. New Jersey: Prentice Hall, 1983.). Інформаційний інжиніринг використовує керувати інформацією підхід, спрямований бізнесом, і застосовує іншу нотацію для представлення бізнес-правил. IE служить розширенням та розвитком нотації та базових концепцій методології ER, запропонованої Пітером Ченом.

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

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

Висновок

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

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

Модель даних складається з логічної та фізичної моделей, що відображають вимоги до інформації та бізнес-правила. Логічна модель має бути приведена до третьої нормальної форми. Третя нормальна форма обмежує, додає, оновлює та видаляє аномалії структур даних для підтримки принципу "один факт в одному місці". Зібрані вимоги до інформації та бізнес-правила мають бути проаналізовані та досліджені. Їх необхідно порівняти з корпоративною моделлю для гарантії того, що вони не конфліктують з існуючими моделями об'єктів, і включають всі необхідні об'єкти.

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

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

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

ПРИМІТКА Множинність зв'язку описує максимальну кількість екземплярів вторинної сутності, які можуть бути пов'язані з екземпляром вихідної сутності.Необхідність існування чи можливість відсутності зв'язку служить для визначення мінімального числа екземплярів вторинної сутності, які можуть бути пов'язані з екземпляром вихідної

У цій статті йтиметься про архітектуру сховищ даних. Чим керуватися за її побудові, які підходи працюють – і чому.

"Казка брехня - та в ній натяк ..."

Посадив дід… сховище. І виросло сховище велике-превелике. Ось тільки до пуття не знав, як воно влаштоване. І затіяв дід ревом. Покликав дід бабусю, онучку, кота та мишку на сімейну раду. І говорить таку тему: «Виросло у нас сховище. Дані з усіх систем стікаються, таблиць мабуть-невидимо. Користувачі звіти свої готують. Начебто все добре – жити та жити. Та тільки один сум – ніхто не знає, як воно влаштоване. Дисків вимагає мабуть-невидимо - не напасешся! А тут ще користувачі до мене ходити повадилися з різними скаргами: то звіт зависає, то дані застарілі. А то й зовсім біда – приходимо ми зі звітами до царя-батюшки, а цифри між собою не сходяться. Не рівна година – розгнівається цар – не зносити тоді голови – ні мені, ні вам. Ось вирішив я вас зібрати і порадитися: що робитимемо?».

Окинув він своїм поглядом збори і питає:
- Ось ти, бабко знаєш, як воно влаштоване наше сховище?
- Ні, діду, не знаю. Та й звідки мені знати? Он там які браві хлопці його охороняють! Одні всищі які! Не підступишся. Я зайшла якось їх провідати, пиріжків напекла. А вони пиріжки з'їли, вуса витерли і кажуть: «Та чого ти прийшла, бабко? Яке тобі сховище? Ти скажи – який тобі звіт потрібен – ми тобі зробимо! Ти головне пиріжки частіше приноси! Аж надто вони в тебе смачні.»
- А ти, онучко кохана, чи знаєш, як влаштовано наше сховище?
- Ні, діду, не знаю. Дали мені якось доступ до нього. Підключилася я, дивлюся - а там таблиць - мабуть-невидимо. І у схеми різні сховані. Очі розбігаються…. Я спершу розгубилася. А потім придивилася - якісь із них порожні, інші заповнені, та лише наполовину. А ще дані, схоже, повторюються. Не дивно, що дисків не напасешся, з такою надмірністю!
- Ну а ти, кіт, що скажеш про сховище наше? Чи є в ньому щось хороше?
- Та як не сказати, дідусь - скажу. Я на внучкине прохання намагався в окремій схемі пілотик змастити – вітринку маленьку. Щоб зрозуміти, яка торгівля для нашої держави вигідна – які продукти добре купці йдуть, ті данину платять – скарбницю поповнюють. А які – геть погано. І став я зі сховища цього дані собі підбирати. Фактів назбирав. І став намагатися порівняти їх проти товарів. І що ж, діду, я побачив – продукти вони начебто й однакові, а дивишся в таблички – різні! Взявся я їх тоді гребінцем внучкиним зачісувати. Чесав-чухав - і привів до деякого одноманітності, очей ласкавого. Але рано я зрадів - другого дня запустив я свої скриптики чудові дані у вітринці оновити - а в мене все і роз'їхалося! "Як так?" - думаю, - внучка-то, напевно, засмутиться - сьогодні треба було б наш пілотік міністру показувати. Як же ми підемо з такими даними?
- Так, сумні казки, кіт, розповідаєш. Ну а ти, мишка-норушка, невже не намагалася дізнатися про сховище? Ти в нас дівчина жвава, в'язка, товариська! Що ти нам розповіси?
- Та як, дідусю, не намагатися - звичайно, я мишка тиха, та спритна. Попросила якось онука кота модель даних нашого державного сховища роздобути. А кіт, звичайно, до мене прийшов – на тебе, каже, мишка, вся надія! Ну що добра справа добрим людям (і котам) не зробити? Пішла я до замку, де начальник сховища модель даних у сейфі ховає. І причаїлася. Дочекалася, коли він ту модель із сейфа витягне. Тільки він за кавою вийшов – я стрибнув на стіл. Дивлюся на модель нічого зрозуміти не можу! Як так? Не впізнаю наше сховище! У нас таблиць тисячі незліченні, даних – невгамовні потоки! А тут - все струнко та красиво ... Подивився він на цю модель - і назад у сейф прибрав.
- Так, зовсім дивні речі, ти нам, мишка, повідала.
Дуже задумався дід.
- Що робитимемо, друже мої? Адже з таким сховищем довго не проживеш… Користувачі геть скоро – зовсім терпіння втратять.

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

Розбір польотів

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

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

У принципі, у нас непогане сховище: якщо не чіпати – все працює. Щоправда, щойно потрібно внести зміну – починаються «локальні обвали».
Дані завантажуються щодня, за регламентом, у межах одного великого процесу, протягом 8ч. І це нас влаштовує. Але якщо раптом виникає збій – це потребує ручного втручання. І далі може працювати непередбачено довго, т.к. будуть потрібні участь людини в процесі.
Накотили реліз – чекай на проблеми.
Якесь одне джерело не змогло вчасно віддати дані – чекають на всі процеси.
Цілісність даних контролює база даних – тому наші процеси падають помилково, коли вона порушується.
У нас дуже велике сховище – 2000 таблиць в одній спільній схемі. І ще 3000 у багатьох інших схем. Ми вже слабо уявляємо, як вони влаштовані та з якого приводу з'явилися. Тому нам буває складно щось перевикористати. І доводиться багато завдань вирішувати наново. Оскільки так простіше і швидше (ніж розбиратися «в чужому коді»). У результаті маємо розбіжності і функціонал, що дублюється.
Ми очікуємо, що джерело даватиме якісні дані. Але виявляється, що це негаразд. У результаті багато часу витрачаємо на вивірку своїх фінальних звітів. І дуже в цьому досягли успіху. У нас навіть є налагоджений процес. Щоправда, це триває час. Але користувачі звикли.
Користувач не завжди довіряє нашим звітам та вимагає обґрунтування тієї чи іншої цифри. У якихось випадках він правий, а в якихось ні. Але дуже складно їх доводити, т.к. у нас не передбачено засобів "наскрізного аналізу" (або data lineage).
Ми могли б залучити додаткових розробників. Але у нас проблема – як нам включити їх у роботу? Як найефективніше розпаралелити роботи?
Як розвивати систему поступово, не вдаючись у розробку «ядра системи» на цілий рік?
Сховище даних асоціюється із корпоративною моделлю. Але ми точно знаємо (бачили у банку XYZ), що будувати модель можна нескінченно довго (у банку XYZ шість місяців ходили та обговорювали бізнес-сутності, без будь-якого руху). А навіщо вона взагалі? Чи, може, краще без неї, якщо з нею стільки проблем? Може її взагалі якось згенерувати?
Ми вирішили вести модель. Але як системно розвивати модель даних сховища? Чи потрібні нам правила гри і які вони можуть бути? Що це нам дасть? А якщо ми помилимося з моделлю?
Чи маємо ми зберігати дані, чи історію їхніх змін, якщо «бізнесу вони не потрібні»? Не хотілося б «зберігати сміття» та ускладнювати використання цих даних для реальних завдань. Чи сховище збереже історію? Яка вона буває? Як сховище працює з часом?
Чи потрібно намагатися уніфікувати дані на сховищі, якщо ми маємо систему управління НСІ? Якщо є МДМ, чи це означає, що тепер вся проблема з майстер-даними вирішена?
У нас незабаром очікується заміна ключових облікових систем. Чи сховище даних повинно бути готовим до зміни джерела? Як цього досягти?
Чи потрібні нам метадані? Що під цим розумітимемо? Де вони можуть бути використані? Як можна продати? Чи потрібно їх зберігати «в одному місці»?
Наші Замовники украй не стабільні у своїх вимогах та бажаннях – постійно щось змінюється. У нас взагалі бізнес дуже динамічний. Поки що ми щось робимо – це вже стає непотрібним. Як нам зробити так, щоб видавати результат максимально швидко – як гарячі пиріжки?
Користувачі потребують оперативності. Але ми можемо наші основні процеси завантаження запускати часто, т.к. це навантажує системи-джерела (погано позначається на продуктивності) – тому ми вішаємо додаткові потоки даних – які будуть забирати точково – те, що нам потрібно. Щоправда, виходить багато потоків. І частину даних ми потім викинемо. До того ж, буде проблема збіжності. Але інакше ніяк…

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

Антикрихкість

Дивлячись на наш список, можна зробити один висновок. Не складно створити якусь «базу даних для звітності», накидати туди даних чи навіть побудувати певні регламентні процеси оновлення даних. Система починає якось жити, з'являються користувачі, а з ними зобов'язання та SLA, виникають нові вимоги, підключаються додаткові джерела, зміна методологій – все це треба враховувати в процесі розвитку.

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

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

Така властивість об'єкту – руйнуватися під впливом хаосу, випадкових подій та потрясінь - Нассим Ніколас Талеб називає крихкістю . А також вводить протилежне поняття: антикрихкість – коли предмет не руйнується від стресу та випадковостей, а отримує від нього пряму вигоду. («Антихрупність. Як отримати вигоду з хаосу»)
Інакше це можна назвати адаптивність або стійкість до змін .

Що це означає у цьому контексті? Які є джерела хаосу для ІТ-систем? І що означає «здобути вигоду з хаосу» з погляду ІТ архітектури?
Перша думка, яка спадає на думку – зміни, які приходять ззовні. Що є зовнішнім світом системи? Для сховища зокрема. Звичайно, насамперед – зміни з боку джерел даних для сховища:

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

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

Не менш критичні зміни ініціюються з боку споживачів сховища (зміна вимог):

раніше для побудови звіту даних вистачало – тепер потрібно підключити додаткові поля чи нове джерело даних;
раніше реалізовані методики обробки даних застаріли – потрібно переробити алгоритми та все, на що це впливає;
раніше всіх влаштовувало поточне значення атрибуту довідника на інформаційній панелі – тепер потрібне значення, актуальне на момент виникнення аналізованого факту/події;
виникла вимога до глибини історії зберігання даних, якої раніше не було – зберігати дані не за 2 роки, а за 10 років;
раніше було достатньо даних за станом «на кінець дня/періоду» - тепер потрібний стан даних «всередині дня», або на момент певної події (наприклад, ухвалення рішення щодо кредитної заявки – для Basel II);
раніше нас влаштовувала звітність за даними на вчора (T-1) або пізніше, зараз нам потрібен T0;
і т.д.

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

Але це ще не все.
Говорячи про мінливість, ми передусім згадуємо зовнішні чинники. Адже всередині ми можемо все контролювати, нам так здається, чи не так? І так і ні. Так, більшість факторів, які поза зоною впливу – зовнішні. Але є й “внутрішня ентропія”. І саме через її наявність нам іноді потрібно повернутися "у точку 0". Почати гру спочатку.
У житті ми часто схильні розпочинати з нуля. Чому нам це властиво? І чи так це погано?
Що стосується ІТ. Для самої системи – це може бути дуже добре – можливість переглянути окремі рішення. Особливо коли ми можемо зробити це локально. Рефакторинг - процес розплутування тієї павутини, яка періодично виникає в процесі розвитку системи. Повернення «до початку» може бути корисним. Але має ціну.
При грамотному управлінні архітектурою ця ціна знижується - і процес розвитку системи стає більш контрольованим і прозорим. Простий приклад: якщо дотримується принципу модульності – можна переписати окремий модуль, не торкнувшись зовнішніх інтерфейсів. І цього не можна зробити за монолітної конструкції.

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

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

Приклад системи з «казки про сховище» - це якраз вельми хитка система, побудована на крихких підходах до проектування. І якщо так відбувається – руйнація настає досить швидко, саме для цього система класу.
Чому я можу так стверджувати? Тема сховищ не нова. Підходи та інженерні практики, які були за цей час вироблені, були спрямовані саме на це збереження життєздатності системи.
Найпростіший приклад: одна з найчастіших причин провалу проектів сховищ «на зльоті» - це спроба побудувати сховище над системами-джерелами, які перебувають у стадії розробки, без узгодження інтеграційних інтерфейсів – спроба забрати дані безпосередньо з таблиць. Через війну пішли у розробку – цей час база даних джерела змінилася – і потоки завантаження у сховище стали непрацездатні. Переробляти щось пізно. А якщо ще й не підстрахувалися, зробивши кілька шарів таблиць усередині сховища – все можна викинути і починати заново. Це лише один із прикладів, причому один із простих.

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

Що таке сховище даних та навіщо ми його будуємо

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

Як взагалі люди дійшли того, що необхідні сховища даних? І чим вони відрізняються від просто «дуже великої бази даних»?
Давним-давно, коли у світі жили просто «системи обробки бізнес-даних», був поділу ІТ-систем такі класи як фронтальні oltp-системи, бэк-офисные dss, системи обробки текстових даних, сховища даних, і т.д.
Це був той час, коли Майклом Стоунбрейкером було створено першу реляційна СУБД Ingres.
І це був час, коли ера персональних комп'ютеріввихором увірвалася в комп'ютерну індустрію і назавжди перевернула всі уявлення ІТ суспільства того часу.

Тоді можна було легко зустріти корпоративні програми, написані на базі СУБД класу desktop – таких як Clipper, dBase та FoxPro. А ринок клієнт-серверних додатків та СУБД лише набирав обертів. Одна за іншою з'являлися сервери баз даних, які надовго займуть свою нішу в ІТ-просторі - Oracle, DB2 і т.д.
І було поширено термін «додаток баз даних». Що включало в себе таку програму? Спрощено - деякі форми введення, якими користувачі могли одночасно вводити інформацію, деякі розрахунки, які запускалися «по кнопці» чи «за розкладом», і навіть якісь звіти, які можна було побачити на екрані чи зберегти як файлів і надіслати на Друк.
«Нічого особливого – звичайна програма, тільки є база даних,» - так зауважив один із моїх наставників на ранньому етапі трудового шляху. Чи так нічого особливого? - Подумала тоді я.

Якщо придивитися - то особливості все-таки є. У міру зростання користувачів, обсягу інформації, що надходить, у міру зростання навантаження на систему – її розробники-проектувальники, щоб зберегти швидкодію на прийнятному рівні йдуть на якісь «хитрощі». Найперше – це поділ монолітної «системи обробки бізнес-даних» на програму обліку, яка підтримує роботу користувачів у режимі on-line, і окремо виділяють програму для batch-обробки даних та звітності. Кожна з цих програм має свою базу даних і навіть розміщується на окремому примірнику сервера БД, з різними налаштуваннями під різний характер навантаження – OLTP та DSS. І між ними вишиковуються потоки даних.

Це все? Здавалося б – проблему вирішено. Що ж відбувається далі?
А далі компанії зростають, їх інформаційні потреби множаться. Зростає і кількість взаємодій із зовнішнім світом. І в результаті є не одне велика програма, яке повністю автоматизує всі процеси, а кілька різних, від різних виробників. Число систем, що породжують інформацію – систем-джерел даних у компанії збільшується. І рано чи пізно, виникне потреба побачити та зіставити між собою інформацію, отриману з різних систем. Так у компанії з'являється Сховища даних – новий клас систем.
Загальноприйняте визначення цього класу систем звучить так.

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

Таким чином, консолідаціяданих із різних систем, можливість подивитися на них якимось «єдиним» (уніфікованим) чином – це одна з ключових властивостей систем класу сховищ даних. Це причина, через яку з'явилися сховища в ході еволюції ІТ-систем.

Ключові особливості сховищ даних

Давайте подивимося докладніше. Які ключові особливостіє у цих систем? Що відрізняє сховища даних від інших ІТ-систем підприємства?

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

По-друге, це історичні дані – "Corporate memory" - Так називають сховища даних. Щодо роботи з часом у сховищах все дуже цікаво. В облікових системах дані є актуальними в моменті. Потім користувач робить якусь операцію – і дані оновлюються. При цьому історія змін може і не зберегтися – це залежить від практики обліку. Візьмемо, наприклад, залишок на банківському рахунку. Нас може цікавити актуальний залишок на «зараз», на кінець дня або на момент певної події (наприклад, у момент розрахунку скорингового балу). Якщо перші два вирішуються досить просто, то для останнього, швидше за все, будуть потрібні спеціальні зусилля. Користувач, працюючи зі сховищем, може звертатися до минулих періодів, здійснювати їх порівняння з поточним тощо. Саме подібні можливості, пов'язані з часом, суттєво відрізняють сховища даних від систем обліку – отримання стану даних у різних точках осі часу – на певну глибину у минулому.

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

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

Архітектурна концепція

Кожен, хто стикався зі сховищем, швидше за все спостерігав якусь «шарувату структуру» - т.к. саме ця архітектурна парадигма прижилася для систем класу. І невипадково. Шари сховища можна як окремі компоненти системи – зі своїми завданнями, зоною відповідальності, «правилами гри».
Рівнева архітектура – це засіб боротьби зі складністю системи – кожен наступний рівень абстрагований від складнощів внутрішньої реалізації попереднього. Такий підхід дозволяє виділяти однотипні завдання та вирішувати їх одноманітним чином, не винаходячи щоразу «велосипед» з нуля.
Схематично концептуальна архітектурна схема представлена малюнку. Це спрощена схема, яка відображає лише ключову ідею – концепцію, але без «анатомічних подробиць», які виникатимуть за більш глибокого опрацювання деталей.

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

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

Core Data Layer – ядро сховища - центральний компонент системи, який відрізняє сховище від просто "платформи batch-інтеграції", або "великого звалища даних", оскільки його основна роль - це консолідація данихз різних джерел, приведення до єдиних структур, ключів Саме при завантаженні в ядро здійснюється основна робота з якістю даних та загальні трансформації, які можуть бути складними.
Завдання цього шару– абстрагувати своїх споживачів від особливостей логічного устрою джерел даних та необхідності зіставляти дані з різних систем, забезпечити цілісність та якість даних.

Data Mart Layer - аналітичні вітрини – компонент, основна функція якого – перетворення даних до структур, зручним для аналізу (якщо з вітринами працює BI – це, зазвичай, dimensional model), чи відповідно до вимог системи-споживача.
Зазвичай, вітрини беруть дані з ядра – як надійного і вивіреного джерела – тобто. користуються сервісом цього компонента щодо приведення даних до єдиного виду. Будемо називати такі вітрини регулярними . В окремих випадках вітрини можуть брати дані безпосередньо зі стейджингу - оперуючи первинними даними (у ключах джерела). Такий підхід зазвичай використовується для локальних завдань, де не потрібна консолідація даних з різних систем і де потрібна оперативність більш ніж якість даних. Такі вітрини називають операційними . Деякі аналітичні показники можуть мати складні методики розрахунків. Тому для таких нетривіальних розрахунків та трансформацій створюють так звані вторинні вітрини .
Завдання шару вітрин– підготовка даних відповідно до вимог конкретного споживача – BI-платформи, групи користувачів або зовнішньої системи.

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

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

Таке чітке розподілення системи на окремі компоненти істотно підвищує керованість розвитку системи:

знижується складність завдання, що ставиться розробнику функціоналу того чи іншого компонента (він не повинен одночасно вирішувати і питання інтеграції із зовнішніми системами, і продумувати процедури очищення даних, і думати про оптимальне подання даних для споживачів) – завдання простіше декомпозувати, оцінити та виконати невеликий delivery;
можна підключати на роботу різних виконавців (і навіть команд, чи підрядників) – т.к. такий підхід дозволяє ефективно розпаралелювати завдання, знижуючи їх взаємний вплив один на одного;
наявність персистентного стейджинга дозволяє швидко підключити джерела даних, не проектуючи повністю ядро, чи вітрини для всієї предметної області, а далі поступово добудовувати інші верстви відповідно до пріоритетів (причому дані будуть у сховище – доступні системним аналітикам, що значно полегшить завдання подальшого розвитку сховища);
наявність ядра дозволяє всю роботу з якістю даних (а також, можливі промахи та помилки) приховати від вітрин і від кінцевого користувача, а головне – використовуючи цей компонент як єдине джерело даних для вітрин, можна уникнути проблем зі збіжністю даних внаслідок реалізації загальних алгоритмів одному місці;
виділення вітрин дозволяє врахувати відмінності та специфіку розуміння даних, які можуть бути у користувачів різних підрозділів, а їхнє проектування під вимоги BI дозволяє не тільки видавати агреговані цифри, а забезпечити перевірку достовірності даних шляхом надання можливостей drill down до первинних показників;
наявність сервісного шару дозволяє виконувати наскрізний аналіз даних (data lineage), використовувати уніфіковані засоби аудиту даних, загальні підходи до виділення дельти змін, роботи з якістю даних, управління завантаженням, засоби моніторингу та діагностики помилок, прискорює вирішення проблем.

Такий підхід до декомпозиції також робить систему більш стійкою до змін (у порівнянні з «монолітною конструкцією») - забезпечує її антикрихкість:

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

Далі ми пройдемося по кожному з наведених вище компонентів і подивимося на них трохи докладніше.

Ядро системи

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

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

Модель ядра сховища та корпоративна модель даних

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

Міф 1 Корпоративна модель даних – це величезна модель, що з тисяч сутностей (таблиць).
Насправді. У будь-якій предметній області, у будь-якому бізнес-домені, у даних будь-якої компанії, навіть найскладнішої, основних сутностей небагато – 20-30.

Міф 2 Не потрібно розробляти жодну «свою модель» - купуємо галузеву референсну модель – і робимо все за нею. Витрачаємо гроші – зате отримуємо гарантований результат.
Насправді. Референсні моделі можуть бути дуже корисні, т.к. містять галузевий досвід моделювання цієї галузі. З них можна знайти ідеї, підходи, практики іменування. Перевірити «глибину охоплення» області, щоб не упустити з уваги щось важливе. Але ми навряд чи зможемо використовувати таку модель з коробки - як є. Це такий самий міф, як наприклад – покупка ERP-системи (або CRM) та її впровадження без будь-якого «докручування під себе». Цінність таких моделей народжується в їхній адаптації до реалій саме цього бізнесу, саме цієї компанії.

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

Час на розробку моделі справді буде потрібно. Але це час, витрачене на «малювання сутностей» - це час, необхідне аналізу предметної області, вникнення у те, як влаштовані дані. Саме тому в цьому процесі дуже беруть участь аналітики, а також залучаються різні бізнес-експерти. І робиться це точково, вибірково. А не шляхом організації зустрічей за участю шаленої кількості людей, розсилок величезних анкет тощо.
Якісний бізнес та системний аналіз - ось, що є ключовим при побудові моделі ядра сховища. Потрібно багато чого зрозуміти: де (у яких системах) породжуються дані, як вони влаштовані, у яких бізнес-процесах вони циркулюють тощо. Якісний аналіз ще жодній системі не шкодив. Швидше, навпаки – проблеми виникають із «білих плям» у нашому розумінні.

Розробка моделі даних – це процес винаходу і придумування чогось нового. Фактично модель даних у компанії вже існує. І процес її проектування швидше схожий на розкопки. Модель акуратно і ретельно витягується на світ із «ґрунту» корпоративних даних і вбирається в структуровану форму.

Міф 4 У нас в компанії бізнес настільки динамічний, і все так швидко змінюється, що даремно нам робити модель - вона застаріє раніше, ніж ми введемо цю частину системи в експлуатацію.
Насправді. Згадаймо, що ключовий фактор ядра – стабільність. І насамперед, топології моделі. Чому? Тому що саме цей компонент є центральним і впливає на решту. Стабільність – це вимога і до моделі ядра. Якщо модель дуже швидко застаріває – значить вона неправильно спроектована. Для її розробки обрані не ті підходи та «правила гри». І це питання якісного аналізу. Ключові сутності корпоративної моделі змінюються дуже рідко.
Але якщо нам спаде на думку зробити для компанії, які торгують скажімо, кондитерськими виробами, замість довідника «Продукти» зробити «Цукерки», «Торти» та «Пироги». То коли з'явиться піца в переліку товарів - так, потрібно буде вводити безліч нових таблиць. І це якраз питання підходу.

Міф 5 Створення корпоративної моделі – це дуже серйозна, складна та відповідальна справа. І страшно зробити помилку.
Насправді. Модель ядра хоч і має бути стабільною, але все ж таки не «відлита в металі». Як і будь-які інші проектні рішення, її структуру можна переглядати та видозмінювати. Просто не потрібно забувати про цю її якість. Але це зовсім не означає, що на неї "не можна дихати". І це не означає, що неприпустимі тимчасові рішення та «заглушки», які мають бути заплановані до переробки.

Міф 6 Якщо у нас джерело даних – це, наприклад, система НСІ (або система управління майстер-даними – МДМ), то вона вже по-хорошому має відповідати корпоративній моделі (особливо, якщо вона нещодавно спроектована, і не встигла обрости «побочкою», «традиціями»). » та часниками). Виходить, що для цього випадку нам модель ядра не потрібна?
Насправді. Так, у цьому випадку побудова моделі ядра сховища сильно полегшується - т.к. ми слідуємо готової концептуальної моделі верхнього рівня. Але не виключається зовсім. Чому? Тому що при побудові моделі певної системи діють деякі свої правила - які типи таблиць використовувати (для кожної сутності), як версіонувати дані, з якою гранулярністю вести історію, які метаатрибути (технічні поля використовувати) і т.п.

Крім того, яка б чудова та всеохоплююча система НСІ та МДМ у нас не була – як правило, виникнуть нюанси, пов'язані з існуванням локальних довідників «про те саме» в інших облікових системах. І цю проблему, чи хочемо ми цього, чи ні – доведеться вирішувати на сховищі – адже звітність та аналітику збирати тут.

Шар первинних даних (або історизований staging або операційний шар)

Він позначений як Primary Data Layer. Роль цього компонента: інтеграція із системами-джерелами, завантаження та зберігання первинних даних, а також попереднє очищення даних - перевірка на відповідність правилам форматно-логічного контролю, зафіксованих у «угоді про інтерфейс взаємодії» з джерелом.
Крім того, даний компонент вирішує дуже важливе для сховища завдання - виділення "справжньої дельти змін" - незалежно від того, чи дозволяє джерело відстежувати зміни в даних чи ні і яким чином (за яким критерієм їх можна "зловити"). Як тільки дані потрапили в стейджинг – для решти верств питання виділення дельти вже зрозуміле – завдяки маркуванню мета-атрибутами.

Дані в цьому шарі зберігаються в структурах, максимально близьких до системи-джерела – щоб зберегти первинні дані якомога ближче до їхнього первозданного вигляду. Ще одна назва цього компонента – «операційний шар».
Чому б просто не використовувати усталений термін "staging"? Справа в тому, що раніше, до «епохи великих даних та VLDB», дисковий простірбуло дуже дорого – і найчастіше первинні дані якщо й зберігалися, то обмежений інтервал часу. І часто ім'ям “staging” називають очищуєтьсябуфер.
Тепер же технології зробили крок вперед - і ми можемо дозволити собі не тільки зберігати всі первинні дані, але історизувати їх з тим ступенем гранулярності, який тільки можливий. Не означає, що ми повинні контролювати зростання даних і скасовує необхідність управляти життєвим циклом інформації, оптимізуючи вартість зберігання даних, залежно від «температури» використання – тобто. відводячи «холодні дані», які менш затребувані, на дешевші носії та платформи зберігання.

Що нам дає наявність «історизованого стейджингу»:

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

Які можуть виникнути складності при побудові стейджингу, що «історизується»:

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

Що ще цікавого можна сказати про цей прошарок.
По-перше, якщо ми відходимо від парадигми "наскрізних процесів завантаження" - то для нас більше не працює правило "караван йде зі швидкістю останнього верблюда", точніше ми відмовляємося від принципу "каравану" і переходимо на принцип "конвеєра": взяв дані з джерела – поклав у свій шар – готовий брати таку порцію. Це означає, що
1) ми не чекаємо, поки відбудеться обробка на інших шарах;
2) ми не залежимо від графіка надання даних іншими системами.
Простіше кажучи, ми ставимо на розклад процес завантаження, який бере дані з одного джерела через певний спосіб підключення до нього, перевіряє, чи виділяє дельту – і поміщає дані в цільові таблиці стейджингу. І все.

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

Шар аналітичних вітрин

Шар Вітрин (Data Mart Layer) відповідає за підготовку та надання даних кінцевим споживачам – людям чи системам. На цьому рівні максимально враховуються вимоги споживача як логічні (понятійні), так і фізичні. Сервіс повинен надавати те, що необхідно – не більше, не менше.

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

Найбільше значення з погляду аналітичних завдань є вітрини «для людей» - точніше для інструментів BI, з якими вони працюють.
Втім, є категорія «особливо розвинених користувачів» – аналітики, дослідники даних – яким не потрібні ні BI-інструменти, ні регламентні процеси наповнення зовнішніх спеціалізованих систем. Їм потрібні деякі «загальні вітрини» і «своя пісочниця», де вони можуть створювати таблиці та трансформації на власний розсуд. У цьому випадку відповідальність сховища полягає у забезпеченні наповнення даними цих загальних вітрин у відповідність до регламенту.
Окремо можна назвати таких споживачів як кошти Data Mining – глибокого аналізу даних. Такі інструменти мають свої вимоги до перепідготовки даних, і з ними працюють експерти з дослідження даних. Для сховища завдання зводиться – знову ж таки до підтримки сервісу із завантаження деяких вітрин узгодженого формату.

Проте, повернемося до аналітичних вітрин. Саме вони становлять інтерес з погляду розробників-проектувальників сховища у цьому шарі даних.
На мою думку, найкращий підхід до проектування вітрин даних, перевірений часом, на який зараз «заточені» практично всі платформи BI – це підхід Ральфа Кімбалла. Він відомий під назвою dimensional modeling - Багатомірне моделювання. Існує безліч публікацій на цю тему. Наприклад, з основними правилами можна ознайомитись у публікації . І, звичайно ж, можна рекомендувати від гуру багатовимірного моделювання. Інший корисний ресурс – «Поради Кімбалла»
Багатомірний підхід до створення вітрин описаний і опрацьований настільки добре – як з боку «євангелістів методу», так і з боку провідних вендорів ПЗ, що немає сенсу тут якось докладно на ньому зупинятися – першоджерело завжди краще.

Хотілося б зробити лише один акцент. «Звітність та аналітика» буває різною. Є «важкий reporting» - попередньо замовлені звіти, які формуються у вигляді файлів і доставляються користувачам за передбаченими каналами доставки. А є інформаційні панелі – BI dashboards. За своєю суттю це web-додатки. І на час відгуку цих додатків пред'являються такі самі вимоги, як й у будь-якого іншого web-приложения. Це означає, що нормальний час оновлення панелі BI – це секунди, а не хвилини. Важливо пам'ятати при розробці рішення. Як цього досягти? Стандартний метод оптимізації: дивимося, із чого складається час відгуку і що ми можемо впливати. На що найбільше витрачається час? На фізичні (дискові) читання БД, передачі даних по мережі. Як зменшити обсяг даних, що зчитуються і передаються за один запит? Відповідь очевидна і проста: потрібно дані або агрегувати, або накласти фільтр на великі таблиці фактові таблиці, що беруть участь у запиті, і виключити з'єднання великих таблиць (звернення до фактових таблиць повинні йти тільки через вимірювання).

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

Не завжди достатньо просто побудувати «правильну зірку» – і отримати зручну структуру для BI. Іноді потрібно десь застосувати денормалізацію (оглядаючись при цьому, як це вплине на завантаження), а десь зробити вторинні вітрини та агрегати. Десь додати індекси чи проекції (залежно від СУБД).

Таким чином, шляхом “проб та помилок” можна отримати структуру, оптимальну для BI – яка врахує особливості як СУБД, так і BI-платформи, а також вимоги користувача щодо подання даних.
Якщо ми дані беремо з «ядра», то така переробка вітрин матиме локальний характер, ніяк не впливаючи на складну обробку первинних даних, отриманих безпосередньо із систем-джерел – ми лише «перекладаємо» дані у зручний для BI формат. І можемо собі дозволити зробити це багато разів, у різний спосіб, у відповідність до різними вимогами. На даних ядра робити це набагато простіше і швидше, ніж збирати з «первинки» (структура та правила якої, як ми знаємо, до того ж може «плисти»).

Сервісний шар

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

До цього шару відносять дві області зберігання даних:

область метаданих - використовується для механізму керування завантаженням даних;
область якості даних – для реалізації офф-лайн перевірок якості даних (тобто тих, що не вбудовані безпосередньо в процеси ETL).

Можна по-різному побудувати процес керування завантаженням. Один із можливих підходів такий: розбиваємо усі безліч таблиць сховища на модулі. У модуль можуть бути включені таблиці лише одного шару. Таблиці, що входять до складу кожного модуля, завантажуємо в рамках окремого процесу. Назвемо його керуючий процес . Запуск процесу керування ставиться на свій розклад. Керуючий процес оркеструє виклики атомарних процесів, кожен із яких завантажує одну цільову таблицю, і навіть містить деякі спільні кроки.
Очевидно, що досить просто розділити таблиці staging на модулі – за системами-джерелами, точніше їх точками підключення. Але для ядра це вже складніше – т.к. там необхідно забезпечити цілісність даних, отже треба враховувати залежності. Тобто. виникатимуть колізії, які потрібно вирішувати. І є різні методи їхнього вирішення.

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

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

Не ставлю завдання тут повністю висвітлити цю тему – організації завантаження – лише розставляю акценти, куди варто звернути увагу.
Наведений підхід – це лише один із варіантів. Він досить адаптивний. І його "концептуальним прототипом" послужив конвеєр Toyota і система "точно під час" (just-in-time). Тобто. ми тут відходимо від широко поширеної парадигми виключно «нічного завантаження даних», а завантажуємо невеликими порціями протягом дня – у міру готовності даних у різних джерелах: що прийшло – те й завантажили. При цьому у нас працює безліч паралельних процесів. А «гарячий хвіст» нових даних буде «моргати» - і через якийсь час вирівнюватися. Ми маємо врахувати таку особливість. І у разі потреби формувати користувальницькі вітринами «зрізами», де все вже цілісне. Тобто. не можна одночасно досягти і оперативності, і консистентності (цілісності). Потрібен баланс – десь важливе одне, десь інше.

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

Проектування та ведення моделей даних сховища

Чому при розробці будь-якої системи, де задіяна база даних (а в сховищі – особливо), важливо приділяти увагу проектування моделей даних? Чому б просто не накидати набір таблиць, де завгодно – хоч у текстовому редакторі? Навіщо нам ці картинки?
Як не дивно, такі питання ставлять навіть досвідчені розробники.
Взагалі, ніщо не заважає накидати таблиці - і почати їх використовувати. Якщо… якщо при цьому в голові (!) розробник має струнку загальну картину тієї структури, яку він сприймає. А якщо розробників кілька? А що, якщо ці таблиці використовуватиме хтось ще? А якщо пройде час – людина залишить цю область, а потім до неї знову повернеться?

Чи можна розібратися без моделі? В принципі можна. І розібратися, і «прикинути картинки на папірці», і «пошерстити – поселити» дані. Але набагато простіше, зрозуміліше та швидше скористатися готовим артефактом – моделлю даних. А також розуміти «логіку її устрою» - тобто. добре б мати загальні правила гри.

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

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

Проектування моделей даних – це окрема, дуже велика тема. При проектуванні сховищ використовуються два основні підходи.
Для ядра добре підходить підхід «сутність-зв'язок» - коли будується нормалізована (3NF) модель з урахуванням саме дослідження предметної області, точніше виділеної її області. Тут грає та сама «корпоративна модель», про яку йшлося вище.

При проектуванні аналітичних вітрин підходить багатовимірна модель . Цей підхід добре лягає розуміння бізнес-користувачів – т.к. це модель, проста і зручна для людського сприйняття – люди оперують зрозумілими та звичними поняттями метрик (показників) та розрізів, за якими вони аналізуються. І це дозволяє просто і чітко вибудувати процес збору вимог – ми малюємо набір «матриць розрізів та показників», спілкуючись із представниками різних підрозділів. А потім зводимо в одну структуру - "модель аналізу": формуємо "шину вимірювань" і визначаємо факти, які на них визначені. Принагідно опрацьовуємо ієрархії та правила агрегації.

Далі просто перейти до фізичної моделі, додавши елементи оптимізації з урахуванням особливостей СУБД. Наприклад, для Oracle це буде секціонування, набір індексів тощо. Для Vertica буде використано інші прийоми – сортування, сегментація, секціонування.
Також може знадобитися спеціальна денормалізація - коли ми свідомо вносимо надмірність у дані, завдяки яким покращуємо швидкодію запитів, але при цьому ускладнюємо оновлення даних (бо надмірність потрібно буде враховувати та підтримувати в процесі завантаження даних). Можливо, з метою покращення швидкодії, нам також доведеться створити додаткові таблиці-агрегати, або використовувати такі додаткові можливостіСУБД як проекції у Vertica.

Отже, під час моделювання даних сховища ми фактично вирішуємо кілька завдань:

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

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

Резюмуємо.

Модель даних – це не набір «красивих картинок», а процес її проектування – це процес їх малювання. Модель відбиває наше розуміння предметної області. А процес її складання – це процес її вивчення та дослідження. Ось на це витрачається час. А зовсім не на те, щоб намалювати і розфарбувати.
Модель даних – це проектний артефакт, спосіб обміну інформацією структурованому вигляді між учасниками команди. Для цього вона має бути всім зрозуміла (це забезпечується нотацією та поясненням) та доступна (опублікована).
Модель даних не створюється один раз і заморожується, а створюється та розвивається у процесі розвитку системи. Ми самі задаємо правила її розвитку. І можемо їх змінювати, якщо бачимо – як зробити краще, простіше, ефективніше.
Модель даних (фізична) дозволяє консолідувати та використовувати набір кращих практик, вкладених у оптимізацію – тобто. використовувати ті прийоми, які спрацювали для цієї СУБД.

Особливості проектів сховищ даних

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

Сховище даних – це замовлення ПЗ

Сховище даних - це завжди "замовна розробка", а не коробкове рішення. Так, існують галузеві BI-додатки, що включають референсну модель даних, передналаштовані ETL-процеси з поширених джерел (наприклад, ERP систем), набір типових панелей BI і звітів. Але на практиці сховище вкрай рідко впроваджується як «коробка». Я працюю зі сховищами близько 10 років, і жодного разу не бачила такої історії. Завжди виринають свої нюанси, пов'язані з унікальними особливостями компанії – як бізнесу, так і ІТ-ландшафту. Тому сподіватися, що архітектуру надасть «вендор», який постачає рішення дещо необачно. Архітектура таких систем часто «визріває» всередині самої організації. Або її формують фахівці компанії-підрядника, що є основним виконавцем у проекті.

Сховище даних – це інтеграційний проект

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

Сховище даних – це колективний проект

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

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

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

Сховище даних має більший термін життя в порівнянні з іншими системами

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

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

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

Поступовий ітеративний розвиток

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

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

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

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

Сховища даних – «мульти-проектна історія»

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

Баланс інновацій та перевірених рішень

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

Тут важливо дотриматися балансу – і зберегти досить «екологічний» підхід як до ресурсів, так і до інформації, що зберігається. Інакше можна дуже швидко перетворити сховище на слабоструктуровану «смітник», в якому якщо і можна буде розібратися, то шляхом чималих зусиль.
Так, у нас з'явилося більше можливостей, але це не означає, що потрібно заперечувати всі напрацьовані та перевірені часом практики, які зрозуміло як і навіщо використовувати, і «пускатися в усі тяжкі» лише ведені туманною примарою «інновацій».
Дотримуватись балансу – означає використовувати нові методи та підходи там, де вони відкривають нові можливості, але разом з тим використовувати старі перевірені – для вирішення нагальних завдань, які ніхто не скасовував.
Що можемо зробити ми як розробники та проектувальники прикладних рішень? Насамперед, знати та розуміти технологічні зміни платформ, на яких ми працюємо, їх можливості, особливості та межі застосування.

Подивимося на СУБД – як найбільш критичну та важливу для сховищ технологічну платформу.
Останнім часом явно намітився дрейф реляційних баз даних, створених спочатку як «універсальних» у бік спеціалізації. Вже давно провідні вендори випускають різні опції - для додатків різного класу (OLTP, DSS & DWH). Крім того, з'являються додаткові можливості для роботи з текстом, гео-даними тощо.

Але цим справа не обмежилася - почали з'являтися продукти, які спочатку орієнтовані певний клас завдань – тобто. спеціалізовані СУБД. Вони можуть використовувати реляційну модель, а можуть і ні. Важливо те, що вони спочатку «заточені» не просто на зберігання та обробку «бізнесу інформації» в цілому, а під певні завдання.

Мабуть, централізація та спеціалізація – це два взаємодоповнюючі тренди, які періодично змінюють один одного, забезпечуючи розвиток та баланс. Також як і еволюційний (поступовий) поступовий розвиток та кардинальні зміни. Так, у 90-х роках Майкл Стоунбрейкер був одним із авторів Маніфесту баз даних III покоління, в якому чітко звучала думка, що світові не потрібна ще одна революція у світі баз даних. Однак через 10 років він публікує роботи, в яких анонсує передумови початку нової ери у світі СУБД - саме виходячи з їхньої спеціалізації.
Він наголошує на тому, що поширені універсальні СУБД побудовані на «безрозмірній» (one-size-fits-all) архітектурі, яка не враховує ні змін апаратних платформ, ні поділу додатків на класи, для яких можна придумати більш оптимальне рішення, ніж реалізуючи Універсальні вимоги.
І починає розвивати низку проектів у відповідність до цієї ідеї. Один із яких – C-Store – колонкова СУБД, спроектована в архітектурі shared nothing (SN), спочатку створена спеціально для систем класу сховищ даних. Далі цей продукт отримав комерційний розвиток як HP Vertica.

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

Епілог

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

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

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

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

Це цікаво: