лучшие книги по экономике
Главная страница

Главная

Замовити роботу

Последние поступления

Форум

Создай свою тему

Карта сайта

Обратная связь

Статьи партнёров


Замовити роботу
Книги по
алфавиту

Б
В
Г
Д
Е
Ж
З
И
К
Л
М
Н
О

системи підтримки прийняття рішень

Страницы [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ 14 ] [ 15 ]
[ 16 ] [ 17 ] [ 18 ] [ 19 ] [ 20 ] [ 21 ] [ 22 ] [ 23 ] [ 24 ] [ 25 ] [ 26 ] [ 27 ] [ 28 ] [ 29 ] [ 30 ] [ 31 ] [ 32 ]
[ 33 ] [ 34 ] [ 35 ] [ 36 ] [ 37 ] [ 38 ] [ 39 ] [ 40 ] [ 41 ] [ 42 ] [ 43 ] [ 44 ] [ 45 ] [ 46 ] [ 47 ] [ 48 ] [ 49 ] [ 50 ]

 

10.1.3. Взаємопов’язана архітектура орієнтованих на дані СППР


Архітектура орієнтованих на дані СППР має низку взаємопов’язаних елементів. Команди проектувальників мають починати розроблення проекту СППР з дослідження принципів побудови сховищ даних і орієнтованих на дані СППР з метою отриман­ня архітектурного шаблону, зокрема для виявлення типових компонентів системи (наприклад, інтерфейсів), і того, як вони пристосовуються до типової організації, які є характерні чинники успіху або невдачі проекту. Після цього розробники мають накреслити карту типових даних і інтерфейсів, що можуть використовуватися за специфічних умов досліджуваної компанії, вияснити, які суб’єкти підключаться до ОДСППР та які типові запити вони можуть робити. Як мінімум, потрібно забезпечити розроблення відповідних структур для збереження даних, отримати засадні принципи добування і менеджерські інструменти фільтрування даних, мати інтерфейси інструментальних засобів створення запитів, а також деякі наперед визначені схеми і таблиці з метою використання їх у разі аналізування даних та засоби подання інформації.
Компоненти сховища (масиву) даних складаються з однієї або більше баз даних, збудованих з використанням реляційної СКБД, багатовимірної системи керування базою даних або обох типів цих систем. Як уже зазначалося, бізнес-дані вибираються з операційних баз даних та із зовнішніх джерел даних. Зовнішні джерела забезпечують тими даними, які не можуть бути знайдені в системах оброблення транзакцій компанії, але які доречні для аналізу бізнес-процесів, як наприклад, цінами акцій та іншими ринковими показниками. Сховище даних є компіляцією багатьох «моментальних знімків» фінансових, операційних і бізнесових ситуацій компанії. Коли формуються бізнесові дані для сховища даних, то операційні дані підсумовуються і впорядковуються в структурах, які оптимізовані з метою проведення швидкого аналізу, пошуку або вибирання даних. Процес старіння елементів у масивах даних запобігається шляхом переміщення поточних детальних даних на місце застарілих.
Компоненти, що забезпечують виділення і фільтрування даних використовуються для вибирання і перевіряння достовірності даних, отримуваних від операційної бази даних і зовнішніх джерел. Наприклад, для визначення відносної частки ринку для вибраних асортиментів продукції СППР потребує даних стосовно продуктів конкурентів. Такі дані можуть бути розміщені в зовнішніх базах даних, які створюються й підтримуються за допомогою індустріальної групи або компаній, що торгують на ринку такими даними. Як це випливає з назви, ці компоненти вибирають дані з різних джерел, фільтрують їх, щоб підібрати доречні дані, і форматують так, щоб можна було їх додавати до сховищ даних СППР.
Аналітик даних або менеджер можуть створювати запити для доступу до бази даних СППР за допомогою спеціального «інструментального засобу запитів кінцевого користувача», інтерфейс якого відповідно настроюється для полегшення використання.
Інструментальні засоби кінцевого користувача для аналізу та подання інформації допомагають менеджеру виконувати обчислення і вибирати найвідповідніший формат подання. Наприклад, менеджер може бажати отримувати зведені звіти у вигляді таблиць, карт, секторних або стовпчикових діаграм. Інструментальний засіб запиту та інструментальний засіб подання належать до зовнішнього інтерфейсу СППР. Клієнт/серверна технологія забезпечує можливість цим компонентам взаємодіяти з іншими, щоб сформувати завершену архітектуру СППР.
Як тільки архітектура програмного забезпечення розроблена для СППР, що призначається для досягнення наперед визначених цілей конкретної компанії, то потім виникає багато запитань, пов’язаних з проектуванням, розробленням та реалізацією нової орієнтованої на дані системи підтримки прийняття рішень.
10.1.4. Загальне проектування і процес
розроблення орієнтованих на дані СППР

Різні автори по-своєму налагоджували процес розроблення орієнтованих на дані СППР. Раніше були розглянуті два загальні підходи до побудови СППР: «розроблення життєвого циклу системи» і «швидке макетування». Для відносно малих проектів ОДСППР, подібних до вітрин даних, доцільно застосовувати швидке макетування, а для створення проектів корпоративних сховищ даних або ОДСППР можна здійснювати п’ять загальних, орієнтованих на рішення, кроків.
Перший крокпочаткове збирання даних або діагностика. Цей крок передбачає ідентифікування й інтерв’ювання головних майбутніх користувачів СППР, визначення провідних тем СППР, ідентифікацію моделі даних транзакцій, визначення рівня монопольного використання даних, частоти оцінювання і оновлення системи, вимог до інтерфейсу кінцевого користувача, а також форм подання даних. За розроблення проекту головну увагу слід приділяти творцям рішень і самим рішенням протягом усіх кроків.
Другий крокпроектування і створення карти (Mapping) розміщення масиву даних (Data Store). У середовищі реляційної СКБД спочатку необхідно вибрати зіркоподібну схему структури даних і виявити факти, виміри, атрибути, а потім створити діаграми зіркоподібних схем, єрархію атрибутів і рівні агрегування. Ці концептуальні моделі слід подати у вигляді реляційних таблиць. У середовищі багатовимірної бази даних мають бути визначені ключові змінні і виміри. В базу даних вмонтовують доречні для СППР дані.
Третій крокзавантаження і тестування даних. Створення бази даних СППР включає підготовку до введення даних, визначення переліку початкових даних для завантаження і процесу актуалізації або оновлення. В той же час аналітики визначають необхідні перетворення транзакцій і будь-яких зовнішніх даних, таблиць операційних даних транзакцій, інтегрують і трансформують дані. Дані завантажуються, індексуються й перевіряються на достовірність і, нарешті, перевіряють метадані та куби даних або зіркоподібні схеми.
Четвертий крокпобудова і випробовування орієнтованих на дані СППР. Аналітикам потрібно створити меню, розробити вихідні формати даних, визначити передбачувані запити, підготувати тести для інтерфейсів і результатів, знайти оптимальні рішення щодо швидкості й точності роботи системи. При цьому вони мусять спілкуватися з кінцевими користувачами протягом макетування і тестування елементів проекту, підготувавши їх до використання середовища розроблення СППР. У такий спосіб творці рішень мають бути серйозно залученими до процесу побудови і випробування нової, орієнтованої на дані СППР.
Останній крокрозгортання (Rollout) і зворотний зв’язок (Feedback). Цей крок передбачає реальне розгортання СППР, забезпечення додаткової підготовки, установлення зворотного зв’язку з користувачами, супроводження системи і в багатьох випадках також її розширення та вдосконалення. За такого підходу є підстави сподіватися, що СППР дасть змогу удосконалити створення рішень і тим самим принесе користь як компанії загалом, так і творцям рішень зокрема.
10.2. Концепція сховищ даних
і її реалізація в інформаційних системах

10.2.1. Побудова сховищ даних
Практика свідчить, що різні компанії та організації будують сховища даних з метою створення своїх специфічних додатків, причому в багатьох із них перше сховище даних, зазвичай, призначається для виконавчих інформаційних систем. Схови­ще даних потенційно орієнтоване на різні джерела (рис. 10.3), включаючи операційні бази даних або дані транзак­цій. Інші внутрішні дані, які надходять від електронних таб­лиць і внутрішньокорпоративних документів, та зовнішні дані, як наприклад бази даних новин чи цін акцій, можуть також бути збережені в сховищі даних. У типовій організації операційні дані розпорошені через використання кількох СКБД у дуже різ­них форматах і на різних апаратних платформах. Наприклад,
операційні дані можуть міститися у великих ЕОМ (мейнфреймах) типу IBM або DEC і знаходитися у файлах інформаційних систем менеджменту (на рис. 10.3 — IMS), забезпечуватися вір­туальним методом доступу до файлів даних (VSAM), або знаходитися в СКБД DB2 і базах даних. Успадковані інформаційні системи, як наприклад ті, що зображені на рис. 10.3 з ілюстративною метою, є загальним джерелом даних для сховищ даних.
Дані, які вибираються зі щойно названих джерел, необхідно «очистити» для того, щоб перетворити їх формат на прийнятний з метою використання в сховищі. Інакше кажучи, дані мають подаватися у форматах, відповідних тим додаткам, для яких розроб­ляється сховище даних. Наприклад, якщо деякі потрібні операційні дані рідко використовуються на індивідуальному транзакційному рівні, то їх потрібно підсумувати або агрегувати перед збереженням у сховищі.
Важливим чинником стимулювання організації сховищ даних у корпораціях стала поява спеціального програмного забезпечення, призначеного для побудови та зберігання сховища даних,
а також для забезпечення доступу до них. Як видно із рис. 10.3, до групи продавців цих програмних продуктів належать як добре відомі розробники СППР та ВІС (наприклад Pilot, Comshare, IRI) і баз даних (наприклад, Oracle, Focus), так і менш знайомі продавці (Red Brick, Platinum, Carleton), які мають значний вплив у сфері організації сховищ даних. У табл. 10.3 подані основні розробники та створювані ними інструментальні засоби, призначені для побудови окремих компонентів та виконання функцій сховищ даних. Проте слід зауважити, що кількість як самих розробників, так і інструментальних засобів створення сховищ даних постійно зростає, так само як зростають обсяги продажу програмних продуктів сховищ даних, які 2000 року перевищили 5 млрд доларів США.



Рис. 10.3. Будова і використання сховищ даних


Таблиця 10.3
ІНСТУМЕНТАЛЬНІ ЗАСОБИ ТА ЇХ ВИРОБНИКИ
ДЛЯ СТВОРЕННЯ СХОВИЩ ДАНИХ


Функція (елемент)
сховищ даних

Виробники та їхні
інстументальні засоби

Проектування

Oracle:Designer/2000
Sybase: Power Designer

Доставка даних

Oracle: Web Server SpyGlass
IBM: Lotus Notes, WWW
Sybase: Sybase Enterprise Connect, Replication Server, OmniConnect

Підготовка
даних

Oracle: Open Gateways, Symmetric Replication, Parallel Loader
IBM: Data Propagator Relational, Data Refresher, Data Propagator Non-Relational, Vality’s Integrity
Sybase: Carleton Passport, Informatica Power Mart

Перетворення даних

Prism: Warehouse Manager
Carleton: Passport
Apertus: Enterprise Integrator
ETI: Extract
Harte Hanks: Trillium
Platinum: Transport, InfoRefiner

Тиражування даних

Platinum: IntoPump

Керування
даними

Microsoft: SQL Server
Oracle: Oracle
Sybase: Sybase IQ, Sybase SQL Server 11, Sybase MPP
Informix: Informix
IBM: DB2 PE, DB2/400 SMP, DB2/MVS (включаючи Paraller Sysplex)

Керування
метаданими

IBM: Data Guide
Sybase: Prism Warehouse Manager, Intellidex MetaCenter

Добування знань

Angoss: KrowledgeSeeker
SABRE: Decision Technologies
ISL: KDW/Clementine

Доступ
до даних

Andyne: GQL/Pablo
Business Objects: Business Objects
Cognos: PowerPlay, Impromptu

Information Advantage: DecisionSuite

MicroStratiegy: DSS Agent/Server
Oracle: Express
Platinum: Info Beacon, Forest & Trees
Sybase: PowerBuilder, InfoMaker

Закінчення табл. 10.3


Функція (елемент)
сховищ даних

Виробники та їхні
інстументальні засоби

Доступ
до даних

Software AG: Esperant
Oracle: Developer/2000, Discoverer, Oracle Express
IBM: Lotus Approach, Intelligent Decision Server, Arbor Essbase, Informatiоn Advantage Deсisiоn Suite, Cognos Impromptu і Powerplay, Business Objects і Pilot Discovery Server

Керування

CA: UnicenterTNG
NCR: Teradata Tools,TopEnd
Oracle: Enterprise Manager
Sybase: WarehouseArchitect

Проміжний шар

Sybase: ODBC, JDBC, Netimpact Dynamo, Sybase Open Client/ Open Server
IBM: DataJoiner

Сховище даних містить тільки моментальні знімки фактичних даних на конкретний день, як, наприклад, на останню п’ятницю або на останній день місяця. Обновлення даних залежить від потреб користувачів і бізнесового циклу, який асоціюється з даними. Наприклад, торговому менеджеру, який установлює ціни на кожний день, необхідне обновлення даних щодня або навіть частіше. Фінансовий аналіз на кінець місяця потребує тільки помісячної актуалізації даних. Технологічний цикл обновлення даних у сховищі, як правило, триває менше однієї години, тому обновлення суттєво не впливає на поточні бізнесові дії та їх результати.
Як уже зазначалося, сховище даних також містить метадані — інформацію про дані, тобто відомості про те, звідки й від кого дані надходять, хто має доступ до них і як часто, які бізнесові процеси вони забезпечують і які критичні фактори успіху вони підтримують. Ці метадані життєво важливі для підтримки сховищ даних і для кінцевих користувачів, яким потрібно знати, як розміщувати дані.
Дані, які містяться в сховищах даних, можуть бути доступними через програмне забезпечення клієнта, що використовується для підтримки прийняття рішень. Воно може призначатися для ВІС (наприклад, Lightship, Commander), СППР (наприклад, Visual IFPS, Express), або незапланованих (ad hoc) запитів (наприклад, Business Objects, Visualizer). У всіх випадках мається на увазі, що програмне забезпечення легке для користування, так що організаційний персонал з обмеженою комп’ютерною майстерністю і досвідом може ефективно його застосовувати.

Незважаючи на те, що з формального погляду сховище даних являє собою різновид звичайної БД, котра призначена для зберігання в погодженому вигляді фактичної інформації, що поступає з різних оперативних систем та зовнішніх джерел, процес їх проектування суттєво відрізняється.
Для звичайних БД процес їх створення відбувається за схемою: вивчення предметної галузі; побудова інформаційної моделі; розроблення на основі інформаційної моделі проекту бази даних; створення бази даних. Обов’язкові етапи створення сховищ даних відрізняються від такої схеми. Такими етапами є: визначення інформаційних потреб користувачів щодо даних, котрі нагромаджуються в базах даних операційних систем (OLTP-систем), що служать джерелами оперативних даних; вивчення локальних баз даних OLTP-систем; виокремлення від кожної бази даних підмножини даних, необхідних для завантаження в сховище даних; інтегрування локальних підмножин даних і розроблення загальної погодженої схеми сховища. Для виконання робіт зі створення сховищ даних за даною схемою існують різні інструментальні засоби, зокрема, програмний продукт «Oracle Designer» та його спрощена версія «Oracle Data Mart Designer».
Коли сховища даних уже створені та оптимізовані, необхідно ефективно завантажувати нові дані в систему без переривання процесу підтримки прийняття рішень. Однак у разі збільшення обсягу даних розробникам необхідно визначити нові синтаксичні формати та формати запитів, які є швидшими й легшими, а також визначити нові підходи до поєднання реляційних таблиць та добування даних з цих дуже великих баз даних з використанням різновиду програмних агентів — інтелектуальних («розумних») агентів (Intelligent agents), що розглянуті раніше.
10.2.2. Архітектура сховищ даних
Узагальнена схема архітектури сховища даних
Оскільки, як буде описано нижче, кожна велика компанія-розробник сховищ даних пропонує своє бачення їх архітектури і ряду відповідних інструментальних засобів, то є певний сенс розглянути деяку узагальнену архітектуру сховищ даних, не прив’я­зуючись до реально наявної системи. Така узагальнена архітектура показана на рис. 10.4, де виділені окремі компоненти, інструментальні засоби та джерела сховища даних. Опишемо деякі з них.


Рис. 10.4. Узагальнена архітектура сховища даних


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

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

Визначаючи програмно-технологічну архітектуру сховища да­них, потрібно мати на увазі, що система підтримки прийняття рішень, на яких би візуальних засобах вона не ґрунтувалася, має надавати користувачеві можливість деталізування інформації, тобто операцію Drill down. Керівник підприємства чи фірми, отримавши дані в інтегрованому вигляді й висновки, зроблені на їх основі, може зажадати детальніших даних, що уточнюють джерело даних або причини висновків. З погляду проектувальника сховищ даних, це означає, що в деяких випадках необхідно забезпечувати взаємодію бази даних із системою оброблення транзакцій.
Альтернативні (фірмові) архітектури сховищ даних
Ідея сховищ даних (СД), запропонована Б. Інмоном, і концепція оперативного аналітичного оброблення даних (OLAP), розроблена Е. Коддом, вдало доповнили одна одну. За минуле десятиріччя аналітики розробили біля десятка аналітичних інформаційних систем різної архітектури на основі сховищ і вітрин даних, призначених для підтримки прийняття рішень і аналітичних дослід­жень. До них належать: віртуальні сховища даних; незалежні віт­рини даних; централізовані сховища даних; інмонова модель з ку­лями детальних і консолідованих даних; розширена інмонова модель з персональними вітринами даних; інверсна інмонова модель; цент­ралізоване сховище з накопиченням даних у незалежних вітринах; централізоване сховище з тематичними вітринами даних; централізо­ване очищення даних з паралельними сховищами і вітринами даних.
Відповідно до цього провідні фірми пропонують свої рішення, що ґрунтуються на продуктах, які розробляються та випускаються ними (див. табл.10.3). У створенні великих сховищ даних лідирують корпорації IBM, Informix, NCR, Oracle, Red Brick, SAS, Sybase, Microsoft. Крім того, на ринку таких продуктів для побудови і використання сховищ даних значне місце займають Brann Software. Business Objects, Cayenne Software, Computer Associates, MicroStrategy, Prism Solutions, Brio Technology, Cognos, Platinum Technology.
IBM: Visual Warehouse
Корпорація IBM (International Business Machines) належить до тих компаній, що надають повний перелік послуг, програмне і апаратне забезпечення, необхідне для побудови сховищ даних. Під назвою Visual Warehouse фірма IBM пропонує архітектурні варіанти вітрин даних і програмного компонента для їх створення. Це технологія збору даних з різних транзакційних систем, локальних і віддалених плоских файлів, великих блоків двійкових об’єктів (Binary Large Object Block — BLOB) та інших джерел. Пакет Visual Warehouse містить інтегровані програмні продукти, відповідні різним рівням архітектури. Дані з цих джерел трансформуються за правилами метаданих, що визначаються за допомогою графічного інтерфейсу користувача на платформі Win — OS/2 або Microsoft Windows. На основі одного або кількох джерел для користувача або групи користувачів можна підготовляти бізнес-огляди.
Informix: MetaCube
Компанія «Informix» пропонує сервер Informix Dynamic Server і п’ять опцій для розширення його функцій: Advanced Decision Support, що підтримує оптимізацію оброблення запитів за допомогою спеціалізованих індексів підтримки рішень (Decision Support Indexes); Extended Parallel для використання Informix Dynamic Server у багатопроцесорних комплексах різної архітектури; MetaCube, що забезпечує багатовимірний аналіз інформації в реляційних інтерактивних системах аналітичного оброблення (OLAP); Universal Data Option для підтримки нових типів даних; Web Integration Option для інтеграції баз даних з Web-ceрверами.
NCR: Scalable Data Warehouse
Компанія «NCR» володіє досить відпрацьованою методикою, в яку вкладено весь п’ятнадцятирічний досвід створення і впровадження більше 600 сховищ даних. Фірмі належить рекорд з розроблення найбільшого у світі сховища (від 7 до 24 Тб різних даних). Основою технології її продукту Scalable Data Warehouse є реляційна СКБД NCR Teradata, розроблена спеціально для архітектури з масовим паралелізмом і яка функціонує під керуванням ОС UNIX SVR4. Наявна також можливість перенесення СКБД Teradata на ОС Windows NT корпорації «Microsoft» і Solaris фірми, «Sun Microsystems». Ця технологія дає змогу будувати сховища даних на основі СКБД Informix, SQL Server і Oracle. Як апаратне забезпечення NCR пропонує свої сервери WorldMark 5100, масштабована архітектура яких полегшує розширення сховища. Компанія також надає консультаційні послуги щодо підготовки архітектурного проекту сховища даних, його реалізації і керування ним.
Oracle: архітектура мережевих обчислень
За побудови корпоративних інформаційних сховищ Oracle використовує традиційну архітектуру, що реалізовує довільний доступ до будь-яких даних з різних джерел. Розроблена корпорацією «Oracle» архітектура мережевих обчислень дає основу для переходу від принципу клієнт — сервер до концепції Web. Ця архітектура містить п’ять логічних куль. Кулю джерел утворюють транзакційні бази даних, успадковані додатки на мейнфреймах, додатки клієнт-сервера, плоскі файли й інші зовнішні джерела даних. Інфор­мація вибирається із джерел, перетворюється, денормалізується і транспортується в сховище або вітрину даних.
Продукти інституту SAS
На відміну від основних постачальників програмного забезпечення для сховищ даних SAS Institute пропонує організовувати сховища не на основі реляційних СКБД, а в SAS-наборах, підтримуючих пакетне завантаження і читання великих обсягів даних. SAS-набори — це аналоги таблиць у реляційних СКБД, що являють собою файли обсягом до 2 Гб для деяких ОС UNIX, які можуть розташовуватися в різних каталогах і на різних дисках. Сховище утворюється з безлічі таких наборів і досягає 3 Тб. Архітектура сховищ SAS зображена на рис. 10.5 (термін cron function означає функцію планування з економією часу і затримкою завдань), а інструментальні засоби для їх створення перераховані в табл. 10.4. Побудова сховищ даних, згідно з методикою SAS Institute, включає процеси завантаження, керування даними і експлуатації сховища. За допомогою продуктів SAS можна створити централізоване, розподілене або віртуальне сховище. Модульний принцип цього програмного забезпечення дає змогу використовувати його в різній архітектурі.
Таблиця 10.4
SAS-ЗАСОБИ СТВОРЕННЯ СХОВИЩ ДАНИХ


Компонент
сховища даних

Інструментальні засоби для його створення

Проектування

Data Warehouse Administrator

Підготовка даних

BASE/SAS, SAS/FSP, SAS/Access

Керування даними

SAS System

Доставка даних

SAS/Connect, SAS/SPDS, SAS/Share

Управління

Data Warehouse Administrator

Доступ до даних

SAS/MDDB, SAS/EIS, Enterprise Miner, Enterprise Reporter, SAS/Assist, SAS/Insight, SAS/Graph, SAS/AF. SAS/Stat, SAS/ETS


Рис. 10.5. Архітектура сховища даних інституту SAS
Sybase: WarehouseNOW
У компанії «Sybase» централізований підхід вважають досить ризикованим, тому основний акцент тут переноситься на створення розподілених вітрин даних, які надалі можуть бути об’єд­нані в централізоване сховище.
Для проектування корпоративних сховищ даних є сімейство продуктів PowerDesigner, що складається з шести інтегрованих модулів: Process Analyst — для дослідження потоків даних; Data­Architect — для послідовного розроблення концептуальної і фізичної моделей; AppModeler — для створення фізичної моделі даних і об’єктів додатків; MetaWorks — для групової роботи, спільного доступу до інформації і керування моделлю; WarehouseArchitect — для проектування сховищ даних; Viewer — для графічного перег­ляду інформації про модель.
Microsoft Data Warehousing Framework
Однією з останніх розробок у галузі створення сховищ даних є пропозиція корпорації «Microsoft» під назвою «Data Warehousing Framework». Кілька років тому «Microsoft» дійшла висновку про існування насущної потреби в ряді інтегруючих технологій, які б забезпечували легкість спільної роботи продуктів різних виробників. Таке розуміння привело до створення концепції Microsoft Data Warehousing Framework (інфраструктура побудови сховищ даних Microsoft), що являє собою план розвитку не тільки майбутніх продуктів Microsoft, таких як SQL Server 7.0, але й технологій, необхідних для інтеграції продуктів багатьох сторонніх виробників, включаючи як ділових партнерів Microsoft, так і її конкурентів.
Висновок
Розглядаючи фірмові архітектури сховищ даних, мож­на дійти несподіваного висновку: ці рішення не конкурують
одне з одним, а швидше адресовані різним сегментам ринку. Більше того, за створення корпоративної інформаційної системи на основі сховищ даних можлива її модульна побудова з використанням програмного забезпечення різних фірм. Таке рішення може найповніше врахувати специфіку конкретної організації, її потреби, фінансові можливості, наявність кваліфікованих фахів­ців з програмного забезпечення. Тому важко розробити конк-
ретні рекомендації щодо вибору тієї чи іншої архітектури та інструментальних засобів побудови сховища даних. Можна лише
дати деякі орієнтири для цього, виходячи з обмеженої низки мір­кувань.
Якщо важливе значення мають конфіденційність і безпека даних, що розміщуються в сховищі, то найкраще використати програмно-апаратні комплекси IBM, що зарекомендували себе як найзахищеніші. Програмні рішення на основі продуктів фірми «Informix» відомі своєю невисокою ціною і їх можна рекомендувати для організацій з обмеженим бюджетом. Фірма «NCR» володіє не тільки рекордним сервером WorldMark і СКБД Teradata, але і величезним досвідом створення сховищ: її послугами можна скористатися як для реалізації терабайтних проектів, так і для отримання консультацій.
Сервер баз даних Oracle реалізований практично на всіх апаратних платформах, що в сукупності зі стійким станом фір­ми дає змогу рекомендувати його для використання в довго­тривалих проектах, розрахованих на масштабованість. Фірма «SAS» крім засобів створення сховищ пропонує один з кращих пакетів аналітичної і статистичної обробки даних, який може бути використаний на робочому місці в поєднанні з будь-яким сховищем або вітриною даних. Рішення фірми «Sybase», відомі своєю швидкодією, являють особливий інтерес для тих, хто зупинив свій вибір на розподілених незалежних вітринах
даних. Середовище розроблення сховищ даних корпорації «Microsoft» забезпечує по-справжньому потужну платформу для бізнес-аналізу.
10.2.3. Моделі побудови сховищ даних
Багатовимірна модель
Найвдалішою формою подання даних, що надає можливість багатовимірної їх параметризації, є не плоска реляційна модель, а багатовимірна. Базовані на сервері системи інтерактивного аналітичного оброблення на основі багатовимірних моделей мають назву «MOLAP-системи» (Multidimensional OLAP). Мультивимірне зображення даних може бути подане у вигляді кубів і/або гіперкубів, де дані звично розміщені в клітинках пам’яті на перетині причинно зумовлених або описово доречних вимірів.
Куби і/або гіперкуби фактичних поточних значень формуються з двовимірних файлів або реляційних баз даних. Вимірність масиву характеризує значення в елементах пам’яті. Значення в елементах пам’яті ніколи не бувають значеннями вимірних категорій. Замість цього вони є значеннями атрибутів, які змінюються через розмірність. На рис. 10.6 зображено приклад трьохвимір­ного масиву даних — куба, який заповнюється значеннями
проданих одиниць продукції в різний час з відповідними значеннями прибутковості. Наприклад, виділений на рисунку елемент 181,0 означає, що продукція А в період з 18 до 24 доби була реалізована в обсязі 181 одиниці, при цьому прибуток від реалізації одиниці вимірювання цієї продукції був у межах від 40 до 60 копійок.

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

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

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

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

Показники, що знаходяться в комірках багатовимірної моделі, можна відшукувати за будь-яким виміром чи їх комбінацією. Тобто, аналізуючи обсяги продажу, можна підрахувати кількість виробів, проданих протягом останнього року, підсумувавши дані про обсяги продажу за кожен місяць. Якщо неохідно з’ясувати, який з регіональних відділів продажу мав кращі результати, то можна здійснити пошук за регіонами і знайти максимальний обсяг продажу по певному регіону.
Моделі сховища даних реляційного типу
Альтернативним варіантом побудови сховища даних є моделі реляційного типу, що утворюють основу реляційних систем інтерактивного аналітичного оброблення (OLAP) — ROLAP. Продавці ROLAP приєднуються до доктрини OLAP, згідно з якою кінцеві користувачі повинні мати можливість презентувати багатовимірне зображення бізнесових даних. Але вони сильно розходяться в думках щодо того, чи необхідно фізично зберігати дані багатовимірно, чи достатньо використовувати логічну модель, яка трансформує дані в куб або гіперкуб для забезпечення багатовимірного подання даних. Фахівці ROLAP розробили прин­ципи вимірного моделювання на основі застосування таких видів структур моделей даних, як зіркоподібна (Star Schema), «сніжинка» (Snowflake Schema), сузір’я (Constellation) і якісна (Qualities). Найчастіше застосовуються перші два види структур, тобто «зірка» чи «сніжинка».

Страницы [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ 14 ] [ 15 ]
[ 16 ] [ 17 ] [ 18 ] [ 19 ] [ 20 ] [ 21 ] [ 22 ] [ 23 ] [ 24 ] [ 25 ] [ 26 ] [ 27 ] [ 28 ] [ 29 ] [ 30 ] [ 31 ] [ 32 ]
[ 33 ] [ 34 ] [ 35 ] [ 36 ] [ 37 ] [ 38 ] [ 39 ] [ 40 ] [ 41 ] [ 42 ] [ 43 ] [ 44 ] [ 45 ] [ 46 ] [ 47 ] [ 48 ] [ 49 ] [ 50 ]


ВНИМАНИЕ! Содержимое сайта предназначено исключительно для ознакомления, без целей коммерческого использования. Все права принадлежат их законным правообладателям. Любое использование возможно лишь с согласия законных правообладателей. Администрация сайта не несет ответственности за возможный вред и/или убытки, возникшие или полученные в связи с использованием содержимого сайта.
© 2007-2019 BPK Group.