Вітрина даних (Data Mart ) є вузькоспеціалізованою підсистемою сховища даних (Data Warehouse), його окремий елемент.

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

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

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

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

Створення вітрини даних

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

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

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

• Створення агрегатних даних
• Зміна форматів даних.
• Перевірку достовірності та цілісності даних.
• Видалення надлишкових даних
• І т.д.

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

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

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

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

Малюнок 3. Структура СППР із самостійними ВД

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

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

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

Малюнок 4. Структура СППР з ХД та ВД

Перевагами такого рішення є простота створення та наповнення ВД, оскільки наповнення походить з єдиного стандартизованого джерела очищених даних – з ХД, простота розширення за рахунок додавання нових ВД, а також зниження навантаження на основне ХД.

Недоліки полягають у надмірності, оскільки дані зберігаються й у ХД, й у ВД, і навіть додаткові видатки розробку СППР з ХД і ВД.

1. Поняття та модель даних olap

   1. Концепція olap

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

Основне призначення OLAP-систем – підтримка аналітичної діяльності, довільних запитів користувачів – аналітиків. Мета OLAP-аналізу – перевірка гіпотез, що виникають.

1. Категорії даних в ХД

Усі дані у ХД поділяються на три категорії (Малюнок 5):

Малюнок 5. Архітектура ХД

детальні дані – дані, які переносяться безпосередньо з OLTP-підсистем. Відповідають елементарним подіям, що фіксуються в OLTP-системах. Поділяються на:

виміри – набори даних, необхідні опису подій (товар, продавець, покупець, магазин, …);

факти - дані, що відображають сутність події (кількість проданого товару, сума продажів, …);

агреговані (узагальнені) дані – дані, які отримуються на підставі детальних шляхом підсумовування за певними вимірами;

метадані - дані про дані, що містяться в ХД. Можуть описувати:

• об'єкти предметної області, інформація про які міститься у ХД;

  місця та способи зберігання даних;

  дії, що виконуються над даними;

  час виконання різних дійнад даними;

  причини виконання різноманітних дій над даними.

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

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

· OLTP (Online Transaction Processing) - онлайнова обробка транзакцій, що використовує такий спосіб організації СУБД, при якому система працює з невеликими транзакціями за розмірами, але що йдуть великим потоком, і при цьому клієнту вимагається від системи максимально швидкий час відповіді;

· OLAP (Online Analytical Processing) - аналітична обробкаінформації в реальному часі, що включає складання та динамічну публікацію звітів та документів та реалізує принципи побудови систем підтримки прийняття рішень – Decision Support System (DSS) і систем інтелектуального аналізу даних – Data Mining .

При реалізації технологій OLAPта OLTP використовується нова формаорганізації внутрішньомашинної інформаційної бази, що представляє сукупність взаємозалежних компонентів: Операційної базиДаних (ОБД), Сховищ даних (ХД) - Data Warehouse (DW) та Вітрин Даних (Рис. 5.6).

Мал. 5.6 - Організація внутрішньомашинної інформаційної бази ІВ

Операційні БД систем OLTP (Online Transaction Processing) - онлайнова обробка транзакцій, є основним джерелом інформації. Їх доповнюють зовнішні дані , представлені зазвичай у текстовому форматі.

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

Властивостісховищ даних:

· Наочна орієнтація - дані представляють предмет, а не процеси;

· Інтеграція;

· Сувора і однотипна хронологія - обов'язкова прив'язка даних за часом;

· Незмінність - дані не змінюються, а поповнюються за рахунок ОБД та зовнішніх даних.

Структура даниху сховищі даних:

· мета дані (дані про дані) - інформація про джерело і зроблені над вихідними даними операціях;

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

· агреговані дані.

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

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

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

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

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

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

Мал. 5.7 – Шість рівнів архітектури сховища даних

Перший рівень представлений джерелами даних , Які виступають транзакційні та успадковані системи, архіви, розрізнені файли відомих форматів, документи MS Office, а також будь-які інші джерела структурованих даних.

На другому рівні розміщується система вилучення, перетворення та завантаження даних (ETL - Extract, Transformation and Load). Основне завдання ETL – витягти дані з різних систем, привести їх до узгодженого вигляду та завантажити у сховище.

Роль наступного рівня– надійний, захищений від несанкціонованого доступу, збереження даних . Відповідно до запропонованої потрійної стратегії на цьому рівні повинні розміщуватися також системи ведення метаданих та нормативно-довідкової інформації (НДІ) . Оперативний склад даних (Operational Data Store) необхідний тоді, коли потрібно якомога оперативніший доступ до нехай неповних, не до кінця узгоджених даних, доступних з найменшою можливою затримкою. Зони тимчасового зберігання (Staging area) потрібні для реалізації специфічного бізнес-процесу, наприклад, коли перед завантаженням даних контролер даних повинен переглянути їх і дати дозвіл на їх завантаження в сховище.

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

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

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

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

· MOLAP (Multidimensional OLAP) або OLAP з багатьма вимірами – вихідні та агреговані дані зберігаються у багатовимірній БД;

· ROLAP (Relational OLAP) або реляційний OLAP – вихідні дані знаходяться у своїй реляційній БД, агреговані дані поміщають у спеціально створені службові таблиці в тій же БД;

HOLAP (Hybred OLAP)або гібридний OLAP – вихідні дані знаходяться у своїй реляційній БД, агреговані дані зберігаються у багатовимірній БД.

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

Особливістю інформаційної системи банку є необхідність обробки двох типів даних, а саме оперативних та аналітичних. Тому в процесі функціонування ІХС доводиться вирішувати два класи завдань: забезпечення повсякденної роботи банку щодо введення та обробки інформації та організація інформаційного сховища з метою аналізу даних для виявлення тенденцій розвитку, прогнозування станів, оцінки та управління ризиками тощо. Завдання першого класу повністю вирішуються OLTP-системами (OnLine Transactional Processing - оперативна обробкатранзакції). Для роботи з аналітичними даними призначені OLAP-системи (OnLine Analytical Processing -оперативна аналітична обробка), які побудовані за технологією сховища даних та служать для агрегованого аналізу великих обсягівданих. Ці системи є складовоюсистем прийняття рішень або управлінських системкласу middle та top management, тобто. систем, призначених для користувачів середнього та вищого рівняуправління банку.

Таким чином, можливості ІХС можуть бути розширені шляхом спільного використання транзакційних OLTP-системта сховищ даних (Data Warehouse).

Відмінними рисами сховища даних є:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Структура вітрин даних також орієнтована багатовимірну організацію даних як куба. Однак їх побудова через обмеженість інформаційного діапазону, що забезпечує потреби однієї функціональної області, значно простіше і вигідніше, ніж створення сховища даних. Фізична структура бази даних у вітрині даних створюється за моделлю «зірка» (star schema), що є оптимальною при вирішенні групи завдань, для якої побудована вітрина, оскільки забезпечує високу швидкість виконання запитів за допомогою поділу даних. Зіркоподібна схема передбачає наявність однієї центральної таблиці фактів (fact table), в якій містяться підсумовуючі або фактичні дані, і оточуючих таблиць вимірювань (dimensional table), що відображають описову інформацію. Таблиця фактів та таблиці вимірювань пов'язані між собою ідентифікуючими зв'язками, при цьому ключове поле таблиці фактів повністю складається з усіх первинних ключівтаблиць вимірів.

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

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

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

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

При розробці сховища даних виникають і повинні бути вирішені такі питання:
1) які дані повинні бути поміщені в сховища
2) Як знайти та витягти ці дані
3) Як забезпечити коректність даних?

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

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

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

Вітрини даних

Концепція вітрин даних була запропонована у 1992 році. Поява концепції вітрин даних пов'язана з тим, що виявилося, хоча сховище даних річ хороша, але розробка її і використання відбувається протягом декількох років. І це позначається на витратах на підприємствах, які довго не окупаються. Через те, що часто інформаційна структураПідприємств буває складна і заплутана - створити сховище даних неможливо зробити одним махом. Друге проблема, як уже було сказано з інвестиціями. По-третє, дуже часто існуючі Операційні системиОЛТП доводиться теж переробляти, щоб вони теж зберігали або запам'ятовували дані, які потрібні для кубів. Важливий пункт те, що існуючі технологіїу прийняттях рішень важко піддаються модифікації та зміні і тому під них доводиться підлаштовуватись, тобто підлаштовувати свої дані та під існуючі технології. Тому поява вітрин даних була спробою пом'якшити вимоги до сховищ даних. По суті під вітриною даних розуміють спеціалізовані сховища, які обслуговують один із напрямів діяльності. Наприклад: маркетинг, облік запасів, і ст.д. Зі всього сховища даних виділяють напрями і вони автоматизуються. Як правило в першу чергу беруться ті процеси, які легко автоматизуються, добре вивчені, не так складні і впровадження цих вітрин даних дозволяє вже на маленьких прикладах швидко отримати окупність. Таким чином дуже часто розробка сховища даних і вітрин даних йде паралельно, тобто в перспективі потрібно сховище даних, але розробляються походу вітрини, які починають давати віддачу, з іншого боку дозволяють розробникам показати замовникам, що ефект є. Так само як і для сховищ даних стандартом є структура зірки та таблиця фактів.

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

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

На сьогодні є багато промислових системякі підходять під поняття вітрин даних. Насамперед фірма інформатика випустила продукт PowerMarcSuit. Далі Stgentehnology випустила DataMapSollution. Oracale випустила продукт DataMapSuit. У 94 році було запропоновано об'єднати концепції вітрин даних та сховища даних та використовувати сховища для вітрин даних. Оскільки програмне забезпеченнядля аналізу сховищ даних складається дуже довго, а саме сховище зробити важко, зібрати дані з'єднати в базу не так складно, важко приробити їй програмне забезпечення, яке б аналіз робила, тому метою об'єднання було те, щоб самі вітрини даних ґрунтувалися б на даних, які зберігаються у сховищах. Ну і було запропоновано так звану багаторівнева архітектураіз трьох рівнів.

Перший рівень загальнокорпоративної бази даних з урахуванням розподіленої СУБД.

Другий рівень бази даних підрозділів. Як правило, на основі десктоп СУБД. Тут зберігаються агреговані дані, тобто реляційні базиданих зберігають операційні дані, а агреговані дані відкидаються на 2 рівень, де можна використовувати Десктоп СУБД.

І третій рівень – це конкретні місця користувачів-аналітиків. Ті користувачі, які на основі вітрин даних роблять якісь висновки.