Лекція 1:

Архітектура і принципи розподіленого підходу. Вимоги та критерії побудови інформаційних систем на базі розподілених баз даних (РБД).

Під розподіленої (Distributed DataBase – DDB) зазвичай розуміють базу даних, декомпозовану і фрагментовану на кілька вузлів обчислювальної мережі, з можливим управлінням різними СУБД.

РБД повинна володіти (вимоги):

1. Локальними і глобальними (розподіленими) засобами доступу до даних (СКБД).

2. Однакової логікою прикладних програм у всіх АРМах мережі.

3. Малим часом реакції на запити користувачів.

4. Надійністю, яка виключає руйнування цілісності системи в разі виходу з ладу її окремих компонент (вузлів).

5. Відкритістю, що дозволяє нарощувати обсяг локальних БД і додавати нові АРМ.

6. Розвинений системою управління резервного копіювання і відновлення даних на випадок збоїв.

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

8. Високу ефективність, за рахунок вибору оптимальних алгоритмів використання мережевих ресурсів.

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

Принципи побудови РБД:

1. Мінімізація інтенсивності обміну даними (мережевого трафіку).

2. Оптимальним розміщенням серверних і клієнтських додатків в мережі.

3. Декомпозиція даних на часто і рідко використовувані сегменти (для правильного налаштування реплікації – розміщення найбільш часто використовуваних даних на АРМ кінцевих користувачів).

4. Періодичне збереження копій даних і виконання дій з підтримки цілісності розподіленої інформаційної системи.

Критерії побудови РБД:

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

2. Моделювання передбачуваного мережевого трафіку при роботі РБД з різними моделями реплікації даних.

3. Кластеризація елементів даних і програм їх обробки. Мета – домогтися максимальної автономності та слабозв’язаності кластерів.

4. Прив’язка кластерів даних до ймовірних користувачам або АРМ.

5. Підтримка еталонної копії даних і обмеження реплікаційного механізму.

6. Розробка і реалізація правил приведення локальної і центральної БД в несуперечливий стан.

Розподілені архітектури БД прийнято поділяти за типами на:

• Системи не дублюючого розбиття (при великому обсязі часто мінливих даних).

• Системи часткового дублювання (при невеликому обсязі часто мінливих даних).

• Системи повного дублювання (при невеликому обсязі рідко мінливих даних).

У висновку сформулюємо ряд властивостей, яким по К. Дейту повинна задовольняти РБД:

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

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

• Безперервні операції. Цю властивість можна трактувати як можливість безперервного доступу до даних в рамках DDB незалежно від їх розташування і незалежно від операцій, що виконуються на локальних вузлах. Цю властивість можна виразити гаслом "дані доступні завжди, а операції над ними виконуються безперервно".

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

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

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

• Обробка розподілених запитів. Ця властивість DDB трактується як можливість виконання операцій вибірки над розподіленою базою даних, сформульованих в рамках звичайного запиту на мові SQL. Тобто операцію вибірки з DDB можна сформулювати за допомогою тих же мовних засобів, що і операцію над локальною базою даних.

• Обробка розподілених транзакцій. Цю властивість DDB можна трактувати як можливість виконання операцій оновлення розподіленої бази даних (INSERT, UPDATE, DELETE), що не руйнує цілісність і узгодженість даних. Ця мета досягається застосуванням двофазового або двофазного протоколу фіксації транзакцій (two-phase commit protocol), що став фактичним стандартом обробки розподілених транзакцій. Його застосування гарантує узгоджена зміна даних на декількох вузлах в рамках розподіленої (або, як її ще називають, глобальної) транзакції.

• Прозорість мережі. Доступ до будь-яких баз даних може здійснюватися по мережі. Спектр підтримування конкретної СУБД мережевих протоколів не повинен бути обмеженням системи з розподіленими базами даних. Дана якість формулюється максимально широко – в розподіленій системі можливі будь-які мережеві протоколи.

• Незалежність від обладнання. Ця властивість означає, що в якості вузлів розподіленої системи можуть виступати комп’ютери будь-яких моделей і виробників – від мейнфреймів до "персоналок".

• Незалежність від операційних систем. Ця властивість випливає з попереднього і означає різноманіття операційних систем, керуючих вузлами розподіленої системи.

• Незалежність від систем управління. Ця властивість означає, що в розподіленій системі можуть мирно співіснувати СУБД різних виробників і можливі операції пошуку і поновлення в базах даних різних моделей і форматів.

Лекція 2:

Багатовимірне представлення даних. Загальна схема організації сховища даних. Характеристики, типи і основні відмінності технологій OLAP і OLTP. Схеми зірка і сніжинка. Агрегування.

Сховище даних і OLAP. Призначення. Основні характеристики.

Сховище даних (Data Warehouse) – предметно-орієнтований, інтегрований, прив’язаний до часу і незмінний набір даних, призначений для підтримки прийняття рішень.

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

Основні характеристики сховищ даних:

• містить історичні дані;

• зберігає докладні відомості, а також частково і повністю узагальнені дані;

• дані в основному є статичними;

• нерегламентований, неструктурований і евристичний спосіб обробки даних;

• середня і низька інтенсивність обробки транзакцій;

• непередбачуваний спосіб використання даних;

• призначений для проведення аналізу;

• орієнтований на предметні області;

• підтримка прийняття стратегічних рішень;

• обслуговує відносно мала кількість працівників керівної ланки.

Термін OLAP (On-Line Analytical Processing) служить для опису моделі представлення даних і відповідно технології їх обробки в сховищах даних. В OLAP застосовується багатовимірне уявлення агрегованих даних для забезпечення швидкого доступу до стратегічно важливої ​​інформації з метою поглибленого аналізу. Застосування OLAP повинні володіти наступними основними властивостями:

• багатовимірне представлення даних;

• підтримка складних розрахунків;

• правильний облік чинника часу.

Переваги OLAP:

• підвищення продуктивності виробничого персоналу, розробників прикладних програм. Своєчасний доступ до стратегічної інформації.

• надання користувачам достатніх можливостей для внесення власних змін в схему.

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

• зменшення навантаження на системи OLTP і сховища даних.

OLAP і OLTP. Характеристики та основні відмінності.

OLAP	OLTP
Сховище даних має включати як внутрішні корпоративні дані, так і зовнішні дані.	Основним джерелом інформації, що надходить в оперативну БД, є діяльність корпорації, а для проведення аналізу даних потрібне залучення зовнішніх джерел інформації (наприклад, статистичних звітів).
Обсяг аналітичних БД як мінімум на порядок більше обсягу оперативних. Для проведення достовірного аналізу і прогнозування в сховищі даних потрібно мати інформацію про діяльність корпорації та стан ринку протягом декількох років.	Для оперативної обробки потрібні дані за кілька останніх місяців.
Сховище даних має містити одноманітно представлену і узгоджену інформацію, максимально відповідати змісту оперативних БД. Необхідна компонента для вилучення і "очищення" інформації з різних джерел. У багатьох великих корпораціях одночасно існують кілька оперативних ІС з власними БД.	Оперативні БД можуть містити семантично еквівалентну інформацію, представлену в різних форматах, з різними за значенням часу її надходження, іноді навіть суперечливу.
Набір запитів до аналітичної бази даних передбачити неможливо. Сховища даних існують, щоб відповідати на нерегламентовані запити аналітиків. Можна розраховувати тільки на те, що запити будуть надходити не надто часто і зачіпати великі обсяги інформації. Розміри аналітичної БД стимулюють використання запитів з агрегатами (сума, мінімальне, максимальне, середнє значення і т.д.).	Системи обробки даних створюються в розрахунку на рішення конкретних завдань. Інформація з БД вибирається часто і невеликими порціями. Зазвичай набір запитів до оперативної БД відомий вже при проектуванні.
При малій мінливості аналітичних БД (тільки при завантаженні даних) виявляються розумними впорядкованість масивів, швидші методи індексації при масовій вибірці, зберігання заздалегідь агрегованих даних.	Системи обробки даних за своєю природою є сильно мінливими, що враховується в використовуваних СУБД (нормалізована структура БД, рядки зберігаються не упорядковано, B-дерева для індексації, транзактність).
Інформація аналітичних БД настільки критична для корпорації, що потрібна велика грануляція захисту (індивідуальні права доступу до певного рядка і / або стовпця таблиці).	Для систем обробки даних зазвичай вистачає захисту інформації на рівні таблиць.

Правила Кодда для olap систем

У 1993 році Кодд опублікував працю під назвою "OLAP для користувачів-аналітиків: яким він повинен бути". У ньому він виклав основні концепції оперативної аналітичної обробки і визначив 12 правил, яким повинні задовольняти продукти, що надають можливість виконання оперативної аналітичної обробки.

1. Концептуальне багатовимірне уявлення. OLAP-модель повинна бути багатовимірною в своїй основі. Багатовимірна концептуальна схема або призначене для користувача подання полегшують моделювання та аналіз так само, втім, як і обчислення.

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

3. Доступність. OLAP повинен надавати свою власну логічну схему для доступу в гетерогенне середовище БД і виконувати відповідні перетворення для надання даних користувачеві. Більш того, необхідно заздалегідь подбати про те, де і як, і які типи фізичної організації даних дійсно будуть використовуватися. OLAP-система повинна виконувати доступ тільки до дійсно потрібних даних, а не застосовувати загальний принцип "кухонної лійки", який тягне непотрібне введення.

4. Постійна продуктивність при розробці звітів. Продуктивність формування звітів не повинна істотно падати з ростом кількості вимірювань і розмірів бази даних.

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

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

7. Динамічне управління розрідженими матрицями. OLAP системи повинні автоматично налаштовувати свою фізичну схему в залежності від типу моделі, обсягів даних і розрідженості бази даних.

8. Багатокористувацька підтримка. OLAP-інструмент повинен надавати можливості спільного доступу (запиту і доповнення), цілісності та безпеки.

9. Необмежені перехресні операції. Всі види операцій повинні бути дозволені для будь-яких вимірювань.

10. Інтуїтивна маніпуляція даними. Маніпулювання даними здійснювалося за допомогою прямих дій над осередками в режимі перегляду без використання меню і множинних операцій.

11. Гнучкі можливості отримання звітів. Виміри повинні бути розміщені в звіті так, як це потрібно користувачеві.

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