Отправляет email-рассылки с помощью сервиса Sendsay
  Все выпуски  

Iнформацiйнi технологi. Аналiтичнi матерiали


Бази даних та сховища даних: сп╕льн╕ та в╕дм╕нн╕ риси

Науков╕ публ╕кац╕╖ | База даних | Бази даних | Моделювання | Реляц╕йний | Система управл╕ння базами даних

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

Наведемо дек╕лька найб╕льш поширених визначень бази даних (БД).

База даних – сукупн╕сть екземпляр╕в р╕зних тип╕в запис╕в ╕ в╕дношень м╕ж записами та елементами.

Базу даних можна визначити як сукупн╕сть вза╓мозв'язаних даних (прост╕ чи складен╕ типи), що збер╕гаються разом на одному нос╕╖ та описують якусь предметну область за наявност╕ тако╖ м╕н╕мально╖ надм╕рност╕, яка допуска╓ ╖х використання оптимальним чином для одного або дек╕лькох застосувань. Розр╕зняють ╕╓рарх╕чн╕, мережев╕, реляц╕йн╕, часов╕ (темпоральн╕), постреляц╕йн╕ (об’╓ктно-ор╕╓нтован╕, з гн╕здуванням), розпод╕лен╕ та багатовим╕рн╕ бази даних.

Використання бази даних припуска╓ роботу з нею дек╕лькох прикладних програм (застосувань), що вир╕шують завдання р╕зних користувач╕в.

Сховище даних – це а╜ре╜ований ╕нформац╕йний ресурс, що м╕стить консол╕довану ╕нформац╕ю з ус╕╓╖ проблемно╖ област╕ та використову╓ться для п╕дтримки прийняття р╕шень.

Консол╕дована ╕нформац╕я – це одержан╕ з дек╕лькох джерел та системно ╕нте╜рован╕ р╕знотипн╕ ╕нформац╕йн╕ ресурси, як╕ в сукупност╕ над╕лен╕ ознаками повноти, ц╕л╕сност╕, несуперечност╕ та складають адекватну ╕нформац╕йну модель проблемно╖ област╕ з метою ╖╖ анал╕зу опрацювання та ефективного використання в процесах п╕дтримки прийняття р╕шень.

Типове сховище даних зазвичай в╕др╕зня╓ться в╕д традиц╕йно╖ реляц╕йно╖ бази даних. По-перше, традиц╕йн╕ бази даних призначен╕ для того, щоб допомогти користувачам виконувати повсякденну роботу, тод╕ як сховища даних призначен╕ для прийняття р╕шень. Наприклад, продаж товару ╕ виписування рахунку зд╕йсню╓ться з використанням бази даних, призначено╖ для опрацювання транзакц╕й, а анал╕з динам╕ки продаж╕в за дек╕лька рок╕в, що дозволя╓ спланувати роботу з постачальниками, — за допомогою сховища даних.

По-друге, традиц╕йн╕ бази даних характеризуються пост╕йними зм╕нами у процес╕ роботи користувач╕в, а сховище даних в╕дносно стаб╕льне: дан╕ у ньому зазвичай оновлюються за розкладом (наприклад, щотижня, щодня або щогодини — залежно в╕д потреб). В ╕деал╕ процес
поповнення (або як дал╕ ми будемо називати завантаження) ╓ просто додаванням нових даних за певний пер╕од часу без зм╕ни попередньо╖ ╕нформац╕╖, що вже м╕ститься в сховищ╕.

╤, по-трет╓, традиц╕йн╕ бази даних найчаст╕ше ╓ джерелом даних, що потрапляють у сховище. Кр╕м того, сховище може поповнюватися за рахунок зовн╕шн╕х джерел, наприклад статистичних зв╕т╕в. Дан╕, що надходять до бази даних з ╕ншо╖ бази, ╓ невеликого обсягу (тисяч╕ запис╕в), мають ту ж схему даних, що ╕ база даних-приймач. На в╕дм╕ну в╕д них сховища даних у визначен╕ терм╕ни отримують значно б╕льш╕ обсяги даних, як╕ можуть в╕др╕хнятися в╕д приймача форматом, а ╕нколи ╕ типом, що вимага╓ застосування додаткових процедур трансформування та завантаження даних (так зван╕ процедури Extract, Transform, Load).

Як бази даних, так ╕ сховища даних, можуть будуватись на основ╕ певно╖ системи керування базами даних (СКБД) (реляц╕йна, постреляц╕йна тощо). СКБД забезпечу╓ загальний репозитор╕й для збер╕гання ╕ опрацювання структурованих даних. СКБД п╕дтриму╓ наб╕р вза╓мозв'язаних послуг ╕ дозволя╓ розробникам зосередитись на специф╕чних проблемах ╖х застосувань, а не на завданнях, як╕ виникають при потреб╕ в узгодженому й ефективному керуванн╕ великими обсягами даних. Проте СКБД вимагають, щоб вс╕ дан╕ знаходилися п╕д ╓диним адм╕н╕стративним керуванням ╕ в╕дпов╕дали ╓дин╕й схем╕. У в╕дпов╕дь на задоволення цих обмежень СКБД можуть забезпечити розвинен╕ засоби ман╕пулювання даними та опрацювання запит╕в з╕ зрозум╕лою ╕ строгою семантикою, а також строг╕ транзакц╕йн╕ ╜арант╕╖ оновлень, паралельного доступу ╕ довготривалого збер╕гання (так зван╕ властивост╕ ACID).

Враховуючи специф╕ку, cховище даних ма╓ так╕ особливост╕ проектування та побудови:

  • отримання ╕нформац╕╖ з р╕зних джерел даних (у тому числ╕ ╕ з реляц╕йних баз даних) у детал╕зованому та а╜ре╜ованому вигляд╕ (збер╕гаються результати застосування функц╕й агрегац╕╖ – суми, середнього значння, максимуму, м╕н╕муму тощо);
  • багатовим╕рне подання ╕нформац╕╖ – ╕гноруються деяк╕ вимоги нормал╕зац╕╖ (дотримують максимум 3-о╖ нормально╖ форми), що значно п╕двищу╓ швидк╕сть опрацювання ╕нформац╕╖, оск╕льки зменшу╓ к╕льк╕сть операц╕й з’╓днання;
  • наявн╕сть метаданих для опису джерел метаданих та структури самого сховища даних – у базах даних також використовують словники для опису структур даних, а у сховищах даних мета дан╕ (словники, дан╕ про дан╕) повинн╕ будуватися за класиф╕кац╕йною схемою Захмана. За ц╕╓ю схемою описую об'╓кти ( що?), суб'╓кти (хто?), м╕сцезнаходження (де?), час (коли?), фактори впливу, чинники (чому?), способи (як?);
  • наявн╕сть пакетного завантаження даних в сховище даних та вивантаження даних;
  • наявн╕сть процедур анал╕зу даних та отримання нових даних;
  • ор╕╓нтован╕сть даних на анал╕тичне, а не на статичне опрацювання.
  • Сховища даних краще пристосован╕ до збер╕гання та анал╕тичного опрацювання великих обсяг╕в даних ╕, в основному, ╓ ╕нте╜рац╕╓ю реляц╕йно╖ та багатовим╕рно╖ моделей. На сьогодн╕ ╓ так╕ арх╕тектури побудови сховищ даних: корпоративна ╕нформац╕йна фабрика Б╕лла ╤нмона, шина Ральфа К╕мбола, зведення даних корпорац╕╖ TDAN. Вони мають розвинен╕ засоби ╕нте╜рац╕╖ даних з р╕зних джерел та дозволяють працювати як з детал╕зованою, так ╕ а╜ре╜ованою ╕нформац╕╓ю.

    Парадигма для реляц╕йних даних в сховищ╕ даних (парадигма корпоративно╖ ╕нформац╕йно╖ фабрики К╤Ф – Corporate Information Factory, CIF) розроблена ╤нмоном ╕ передбача╓, що дан╕ повинн╕ перебувати на низькому р╕вн╕ ступен╕ детал╕зац╕╖ ╕ в трет╕й нормальн╕й форм╕ (3НФ, 3NF). Б╕лл ╤нмон п╕дтриму╓ повторний або сп╕ральний п╕дх╕д до розвитку великого сховища даних. За цим п╕дходом розвиток сховища в╕дбува╓ться ╕терац╕йно, тобто у раз╕ виникнення потреби дода╓ться одна таблиця за один раз, що забезпечу╓ лише незначну зм╕ну схеми даних. Тому такий п╕дх╕д до проектування сховища ще називають сп╕ральним п╕дходом.

    ╢ альтернативний п╕дх╕д до арх╕тектури сховищ даних, в╕домий як Сховище даних з арх╕тектурою шини, або п╕дх╕д Ральфа К╕мбола, або Просторове Сховище. У ц╕й модел╕ первинн╕ дан╕ перетворяться в ╕нформац╕ю, придатну для використання, на етап╕ п╕дготовки даних. При цьому обов'язково приймаються до уваги вимоги до швидкост╕ опрацювання ╕нформац╕╖ ╕ якост╕ даних. Як ╕ в модел╕ Б╕лла ╤нмона, п╕дготовка даних почина╓ться з╕ скоординованого добування даних ╕з джерел. Ряд операц╕й в╕дбува╓ться
    централ╕зовано, наприклад, п╕дтримка ╕ збер╕гання загальних дов╕дкових даних, ╕нш╕ д╕╖ можуть бути розпод╕леними.

    Область подання просторово структурована, при цьому вона може бути централ╕зованою або розпод╕леною. Просторова модель сховища даних м╕стить ту ж атомарну ╕нформац╕ю, що й нормал╕зована модель, але ╕нформац╕я структурована по-╕ншому, щоб полегшити ╖╖ використання й виконання запит╕в. Ця модель включа╓ як атомарн╕ дан╕, так ╕ узагальнювальну ╕нформац╕ю (а╜ре╜ати у зв'язаних таблицях або багатом╕рних кубах) в╕дпов╕дно до вимог продуктивност╕ або просторового розпод╕лу даних. Запити в процес╕ виконання звертаються до усе нижчого р╕вня детал╕зац╕╖ без додаткового перепрограмування з боку користувач╕в або розроблювач╕в застосування.

    На в╕дм╕ну в╕д п╕дходу Б╕лла ╤нмона, просторов╕ модел╕ будуються для обслуговування б╕знес-процес╕в (як╕, у свою чергу, пов'язан╕ з б╕знес-показниками або б╕знес-под╕ями), а не б╕знес-в╕дд╕л╕в. Наприклад, дан╕ про замовлення, як╕ повинн╕ бути доступн╕ для загалькорпоративного використання, вносяться в просторове сховище даних т╕льки один раз, на в╕дм╕ну в╕д К╤Ф-п╕дходу, у якому ╖х довелося б трич╕ коп╕ювати у в╕трини даних в╕дд╕л╕в маркетин╜у, продаж╕в ╕ ф╕нанс╕в. П╕сля того, як у сховищ╕ появля╓ться ╕нформац╕я про основн╕ б╕знес-процеси, консол╕дован╕ просторов╕ модел╕ можуть видавати ╖хн╕ перехресн╕
    характеристики. Матриця корпоративного сховища даних з арх╕тектурою шини виявля╓
    й п╕дсилю╓ зв'язок м╕ж показниками б╕знес-процес╕в (фактами) ╕ описовими атрибутами (вим╕рами).

    Г╕бридна арх╕тектура, яка по╓дну╓ особливост╕ реляц╕йно╖ та багатовим╕рно╖ моделей,
    запропонована Дугласом Хекн╕. ╤ншою назвою модел╕ ╓ Узгоджувана в╕трина даних. За тако╖ арх╕тектури передбача╓ться подв╕йне проектування схеми сховища даних – розроблення нормал╕зованого центрального (корпоративного сховища) та багатовим╕рних (побудованих за арх╕тектурою шини) в╕трин даних. Корпоративне нормал╕зоване сховище дозволя╓ коректно збер╕гати дан╕, а ненормал╕зован╕ в╕трини – швидко виконувати запити користувач╕в.

    Зведення даних – предметно ор╕╓нтована, ╕сторична ╕ ун╕кально зв'язана множина нормал╕зованих таблиць, як╕ п╕дтримують одну або б╕льше функц╕ональних предметних областей. Це – г╕бридний п╕дх╕д, що по╓дну╓ кращ╕ особливост╕ 3-о╖ нормально╖ форми (3НФ) ╕ схеми «з╕рка». Модель гнучка, масштабу╓ться, посл╕довна ╕ пристосована до потреб
    р╕зних предметних областей. Вона в╕дпов╕да╓ потребам сховища даних ╕ в╕дкида╓ потребу у використанн╕ в╕трин даних та, на в╕дм╕ну в╕д г╕бридного п╕дходу Хекн╕, не вимага╓ подв╕йно╖ роботи для надбудови арх╕тектури шина над арх╕тектурою корпоративно╖ фабрики.

    Зведення даних може керувати масивними наборами ╜ранульованих даних в меншому, б╕льш нормал╕зованому ф╕зичному простор╕, наприклад 3НФ ╕ схем╕ «з╕рка». Базу╓ться на математичних принципах, як╕ п╕дтримують нормал╕зован╕ модел╕ даних. Внутр╕шня частина модел╕ зведення даних – близьк╕ структури, як╕ в╕дпов╕дають традиц╕йним визначення схеми «з╕рка» ╕ 3НФ, що включають вим╕ри, зв’язки багато-до багатьох ╕ стандартн╕ табличн╕ структури. В╕дм╕нност╕ полягають в подан╕ зв’язк╕в, структуризац╕╖ поля ╕ ╜ранульованому,
    пов’язаному з часом, збер╕ганн╕ даних.

    ╢ так╕ п╕двиди сховища даних: в╕трина даних, оперативне сховище даних.

    В╕трина даних (ВД) — зр╕з сховища даних, масив тематично╖, вузьконапрямлено╖ ╕нформац╕╖, що ор╕╓нтований, наприклад, на користувач╕в одн╕╓╖ робочо╖ групи або департаменту.

    Двор╕внева арх╕тектура сховища даних передбача╓ побудову в╕трин даних без створення центрального сховища, при цьому ╕нформац╕я надходить ╕з ре╓страц╕йних систем ╕ обмежена конкретною предметною областю. При побудов╕ в╕трин використовуються основн╕ принципи побудови сховищ даних, тому ╖х можна вважати сховищами даних у м╕н╕атюр╕.

    Побудова повноц╕нного корпоративного сховища даних зазвичай викону╓ться в трьохр╕внев╕й арх╕тектур╕. На першому р╕вн╕ розташован╕ р╕зноман╕тн╕ джерела даних - внутр╕шн╕ системи, що ре╓струють, дов╕дков╕ системи, зовн╕шн╕ джерела (дан╕ ╕нформац╕йних агентств, макроеконом╕чн╕ показники). Другий р╕вень м╕стить центральне сховище, куди ст╕ка╓ться ╕нформац╕я в╕д вс╕х джерел з першого р╕вня, ╕, можливо, оперативне сховище даних (сховище поточно╖ ╕нформац╕╖, розглянуто дал╕), що не м╕стить ╕сторичних даних ╕ викону╓ дв╕ основн╕ функц╕╖:

  • по-перше, воно ╓ джерелом анал╕тично╖ ╕нформац╕╖ для оперативного керування,
  • по-друге, тут п╕дготовляються дан╕ для наступного завантаження в центральне сховище.
  • Операц╕йне сховище даних (ОСД) – це предметно-ор╕╓нтований, ╕нте╜рований, зм╕нюваний наб╕р консол╕дованих даних, який м╕стить поточну (не ╕сторичну) детал╕зовану ╕нформац╕ю.

    На перший погляд, операц╕йне сховище даних дуже схоже на сховище за структурою ╕ зм╕стом. Зазвичай за деякими характеристиками ОСД ╕ сховище даних дуже схож╕, але ОСД ма╓ ряд властивостей, як╕ ╕стотно в╕др╕зняють його в╕д сховища. Як ОСД, так ╕ сховище даних ╓
    предметно-ор╕╓нтованим ╕нте╜рованим набором консол╕дованих даних. З ц╕╓╖ точки зору вони схож╕, оск╕льки як в одному, так ╕ в ╕ншому випадку дан╕ повинн╕ бути завантажен╕ з транзакц╕йних систем. Але на цьому ╖х схож╕сть зак╕нчу╓ться. ОСД м╕стить дан╕, що зм╕нюються, тод╕ як в сховищ╕ дан╕ п╕сля завантаження не зм╕нюються. ╤нша в╕дм╕нн╕сть поляга╓ у тому, що операц╕йне сховище м╕стить т╕льки дан╕, актуальн╕ на певний момент часу, тод╕ як в сховищ╕ м╕стяться як поточн╕, так ╕ ╕сторичн╕ дан╕. При цьому  актуальн╕сть даних в сховищ╕ значно нижча, н╕ж в операц╕йному сховищ╕. Як правило, в сховищ╕ м╕стяться дан╕, завантажен╕ протягом останн╕х 24 годин, тод╕ як актуальн╕сть даних в ОСД може вим╕рюватися секундами. Ще одн╕╓ю в╕дм╕нн╕стю ОСД в╕д сховища ╓ те, що в ньому
    м╕стяться т╕льки детальн╕ дан╕, тод╕ як сховище м╕стить як детальн╕, так ╕ а╜ре╜ован╕ дан╕.


    В избранное