Правило корисності

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

Зручність моделі

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

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

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

Конфігурації сховищ даних

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

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

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

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

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

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

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

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

Глобальне сховище даних збирає величезні обсяги інформації з безлічі головних сховищ даних, розосереджених по підприємству У ньому використовується спеціальний процес Exstract-Transform-Load (ETL) (Витягти-перетворити-завантажити) для перетворення даних з різних форматів в єдиний, спеціально призначений для полегшеного вилучення інформації Глобальні сховища даних найчастіше використовуються в якості місця розміщення архівів, зберігання історичних даних і звільнення оперативних сховищ від рідко використовуваних даних Ці дані найчастіше консолідовані, що полегшує пошук і звітність, а також скорочує вірогідність помилок

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

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

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

У створеній Біллом Гейтсом цифровий нервовій системі сховище даних виступає в ролі памяті організації У ній зберігається історія, вона використовується для розкриття даних, зокрема для аналізу тенденцій (У чому і чому організація зазнає поразки на ринку і в чому виграє) Ця частина цифрової нервової системи використовується організаціями для роздумів щодо того, як подолати проблеми і добитися успіху По суті, це і є основним завданням сховищ даних і кубів бізнес-логіки

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

Стилі проектування головних сховищ даних

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

Реляційні бази даних

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

Обєктно-орієнтовані бази даних

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

Таблиця 12 Порівняння термінології баз даних

Стиль розробників

Загальний список

Елемент

списку

Елемент інформації в списку

Електронна таблиця

Електронна таблиця, або робочий лист, або іменований діапазон

Рядок

Стовпець або осередок

Історична інформація

Файл

Запис

Поле

Реляційна алгебра або логічне проектування

Сутність

Кортеж або відношення

Атрибут

SQL або фізичне проектування

Таблиця

Рядок

Стовпець

Обєктно-орієнтований аналіз та проектування

Клас

Примірник

обєкта

Властивість

Так як обєктно-орієнтовані бази даних в основному зберігають обєкти, їх ключовою характеристикою є здатність зберігати складні обєкти, такі як файли XML або класи NET

Обєктно-орієнтовані СУБД підходять для додатків, в яких очікуються суттєві зміни схеми, включення складних типів даних, множинні відносини між класами, в тому числі мультіассоціаціі, і потрібно легкість підключення даних до додатка

Існують три основні типи обєктно-орієнтованих баз даних

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

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

■ Обєктно-реляційні сховища даних Ці сховища підтримують обєкти додатків і моделюють структуру класів в реляційної СУБД Такі бази поєднують переваги обєктно-орієнтованих моделей з традиційними можливостями запитів і звітів реляційних баз даних

Більш повну інформацію про нову модель обєктно-реляційних баз даних На замітку Nordic ви можете отримати на сайті автора (www SQLServerBible Com)

Узагальнена модель СУБД

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

Рис 12 Узагальнена схема, при якій в реляційну СУБД впроваджені елементи обєктно-орієнтованої СУБД

Архітектура підприємства

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

Коли компанія Microsoft використовує термін архітектура, вона зазвичай має на увазі своє середовище NET Framework або проектування систем, які потребують залучення декількох продуктів Microsoft для вирішення завдання

Термін архітектура продукту відноситься до компонування різних компонентів у структурі програми

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

Термін архітектура даних відноситься до організації та конфігурації сховищ даних

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

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

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

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

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

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

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

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

Джерело: Нільсен, Пол Microsoft SQL Server 2005 Біблія користувача : Пер з англ – М: ООО ІД Вільямс , 2008 – 1232 с : Ил – Парал тит англ

Схожі статті:


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

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*