Дипломна робота на тему: Методи І моделі стратегічного планування діяльності підприємства на підставі інтегрованих сховищ даних

Вид материала

Содержание

2.2 Введення в сховища даних Oracle. Technical white paper.
BI системи включає такі фази, як консолідація, дослідження й публікація. На додаток до цьому BI
Архітектура сховища даних
Джерела даних
Область перетворення
Тип 1 або перезапис
Тип 2 або новий запис
Тип 3 або нові колонки
Область презентації даних
Засоби доступу до даних
Засоби для виконання довільних запитів
Засоби для одержання аналітичних звітів
Засоби пошуку закономірностей (Data Mining).

Подобный материал:

1 2 3 4 5

2.2 Введення в сховища даних Oracle. Technical white paper.

Огляд

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

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

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

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

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

Введення

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

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

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

Нащастя, Oracle створив єдину інтегровану платформу для BI.

Архітектура сховища даних

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

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

Джерела даних

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

Область перетворення

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

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

Тип 1 або перезапис Користувач не може бачити історії. Старі значення атрибутів перезаписуються. Якщо в співробітника змінився телефон, то старе значення пропадає. Застосовується для тих атрибутів, які не мають потреби у відстеженні змін.

Тип 2 або новий запис Користувач може бачити старі дані по-старому а нові – по-новому. Глибина історії не обмежена. Нехай 1 січня 2004 року співробітника підвищили з керівника відділу до керівника департаменту. Тоді за даними сховища до 1 січня він буде вважатися керівником відділу, а після першого – керівником департаменту. Якщо його ще раз підвищать то збережуться всі три значення й т.д. Це основний тип відстеження змін атрибутів.

Тип 3 або нові колонки Користувач може бачити дані й по-старому й по-новому. Глибина історії обмежена звичайно однією зміною. Нехай до 1 січня 2004 сенсорні кіоски продавав відділ перспективних розробок, а після 1 числа – відділ мультимедійних систем. Тоді на продажі кіосків можна глянути й з нової точки зору: всі кіоски продав відділ мультимедійних систем і зі старої: всі кіоски продав відділ перспективних розробок. Деякі називають цей вид змін альтернативною реальністю. Цей тип часто застосовується у випадку реорганізації.

Є ще один важливий тип, це гібрид типу 1 з типом 2, що сполучить переваги цих двох методів.

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

Область презентації даних

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

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

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

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

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

Засоби доступу до даних

Засоби доступу до даних звертаються тільки до області презентації даних. Їх можна розділити на: