СХОВИЩА ДАНИХ І МАГАЗИНИ ДАНИХ

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

Примітка Відзначимо в якості невеликого відступу, що так було не завжди

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

переваги від спільного функціонування оперативних систем і систем підтримки прийняття рішень знаходять все більше розуміння (див [219]) Однак докладний розгляд інтеграції цих систем виходить за рамки даної глави

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

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

Сховище даних

Подібно банку оперативних даних (а також магазину даних див наступний підрозділ), сховище даних – це спеціальна база даних Цей термін виник, очевидно, в кінці 1980-х років [2215], [2218], хоча відповідне визначення даного поняття було сформульовано трохи пізніше В [2219] сховище даних визначається як предметно-орієнтоване, інтегроване, постійне, що змінюється в часі сховище інформації для підтримки управлінських рішень . Тут термін постійне означає, що, будучи введеними, дані згодом не змінюються, хоча і можуть бути видалені Сховища даних зявилися з двох причин: по-перше, для систем підтримки прийняття рішень необхідно було надати окремий, чистий, узгоджений джерело даних, і, по-друге, цієї мети було потрібно досягти, не надаючи впливу на функціонування оперативних систем

За визначенням очікувана робоче навантаження на сховище даних обумовлена ​​навантаженням в системі підтримки прийняття рішень Тому можна припустити, що сховище даних буде піддаватися частим зверненнями із запитами, крім того, в ній буде періодично здійснюватися обробка в пакетному режимі для оновлення даних До того ж для сховищ даних характерний вельми великий обєм займаної памяті – часто він становить багато терабайти, а збільшення цього обсягу може досягати 50% на рік або навіть більше Внаслідок цього буває важко домогтися високої продуктивності системи, хоча і не можна сказати, що це неможливо Можуть також виникнути проблеми, повязані з масштабністю бази даних Причини подібних труднощів зазвичай включають: а) помилки проектування бази даних (що обговорювалися в останньому підрозділі розділу 223) б) неефективне використання реляційних операцій (що було коротко описано в розділі 222) в) наявність недоліків в реалізації реляційної моделі в цільовій СУБД г) недостатні можливості масштабування, передбачені в самій цільової СУБД д) наявність помилок в архітектурі проекту, що обмежують обсяги і перешкоджають масштабированию платформи Пункти а) і б) вже розглядалися в цьому розділі, п в) докладно обговорювалося в частині II і в інших розділах книги, а опісаніепп г) і д) виходить за рамки даної книги

Магазини даних

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

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

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

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

Нижче описані три основні підходи до створення магазинів даних

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

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

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

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

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

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

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

Багатовимірні схеми

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

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

7Здесь слово каталог не має нічого спільного скаталогамі баз даних в сучасному сенсі етоготерміна

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

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

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

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

Примітка Сенс терміна розмірність розяснюється в розділі 226

З метою демонстрації припустимо, що знову необхідно модифікувати базу даних постачальників і деталей, але на цей раз таким чином, щоб показати кожну поставку за певний період часу, коли здійснювалася ця поставка Привласнимо поставці за певний період ідентифікатор ТI # і введемо ще одну таблицю тт, Щоб звязати ідентифікатори з відповідними періодами Тепер виправлена таблиця SP і нова таблиця періодів часу TI будуть виглядати так, як показано на рис 2238 Відповідно до термінології схем типу зірка, таблиця поставок SP являє собою таблицю фактів, а таблиця періодів часу TI – таблицю розмірностей (у цю схему також входять таблиця постачальників S і таблиця деталей Р, як показано на рис 224)

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

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

8 У шпальтах FROM і ТО таблиці TI містяться дані типу тимчасової оцінки Для спрощення rfa малюнку показані не реальні значеніявременнихотметок, асімволіческіеобозначенія

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

Рис 223 Приклад таблиці фактів (SP) і таблиці розмірностей (TI)

Рис 224 Схема типу зірка для бази даних постачальників і деталей (в якій враховуються періоди часу)

У читача може виникнути питання: в чому ж відмінність схеми типу зірка від схеми, яку можна було вважати справжнім реляційним проектом Дійсно, проста схема типу зірка, подібна показаної на рис 224, може здатися дуже схожою на справжній реляційний проект (і навіть ідентичною йому) Але, на жаль, в загальному випадку при використанні схем типу зірка виникає цілий ряд описаних нижче проблем

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

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

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

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

5 Знову-таки, через відсутність суворого теоретичного підходу таблиці розмірно стей можуть виявитися неоднорідними Така помилка зазвичай виникає, коли таб особи фактів використовується для розміщення даних, що відносяться до різних рівнів агрегування Наприклад, в таблицю поставок можуть бути (помилково) додано рядки, що містять підсумкові кількості деталей, що поставляються за кожен день, кожен місяць, кожен квартал, кожен рік і навіть зведений поточний підсумок на оп ределенную дату Насамперед, така зміна приводить до того, що стовпці ідентифікатора періоду часу (TI #) і кількості (QTY) У таблиці SP не матимуть у різних рядках однаковий сенс Припустимо тепер, що стовпці FROM і то в таблиці розмірностей тт замінені комбінаціями стовпців YEAR,

MONTH, DAY І ТД Тоді всі ЦІ стовпці YEAR, MONTH, DAY І ін

ПОВИННІ будуть допускати використання невизначених значень Крім того, можливо, буде потрібно також стовпець прапорця, що позначає відповідний період часу

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

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

Джерело: Дейт К Дж, Введення в системи баз даних, 8-е видання: Пер з англ – М: Видавничий дім «Вільямс», 2005 – 1328 с: Ил – Парал тит англ

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


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

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

Ваш отзыв

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

*

*