On—Line Transaction Processing

— Консолідація (rolling up). Включає такі узагальнюючі операції, як просте підсумовування значень (згортка) або розрахунок з використанням складних обчислень, що включають інші пов'язані дані. Наприклад, показником для окремих компаній можуть бути просто підсумовані з метою отримання показників для кожного міста, а показники для міст можуть бути «згорнуті» до показників за окремими країнами.

— Операція спуску (drill doun). Операція, зворотна консолідації, яка включає відображення докладних відомостей для розглянутих консолідованих даних.

— Розбиття з поворотом (slicing and dicing). Дозволяє одержати уявлення даних з різних точок зору. Наприклад, один зріз даних про доходи може містити всі відомості про доходи від продажів товарів зазначеного типу по кожному місту. Інший зріз може представляти дані про доходи окремої компанії в кожному з міст.

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

1.3 Моделі сховища даних

 

Забезпечуючи  багатомірне концептуальне уявлення з боку користувача інтерфейсу до вихідної бази даних, всі продукти OLAP діляться на кілька класів за типом вихідної БД. Багатомірний гіперкуб, використовуваний в OLAP—технології, може бути реалізований в рамках реляційної моделі або існувати як окрема база даних спеціальної багатовимірної структури. В залежності від цього прийнято розрізняти багатовимірний (MOLAP) і реляційний (ROLAP) підходи до побудови сховища даних.

У MOLAP—моделі багатовимірне представлення даних реалізується фізично. У спеціалізованих СУБД, заснованих на багатовимірному поданні даних, дані організовані не у формі реляційних таблиць, а у вигляді впорядкованих багатовимірних масивів:

— Гіперкубів (всі збережені в базі даних осередки повинні мати однакову розмірність, тобто знаходитися в максимально повному базисі вимірювань) і

— Полі кубів (кожна змінна зберігається з власним набором вимірів, і всі пов'язані з цим Складність обробки перекладаються на внутрішні механізми системи).

Використання  багатовимірних баз даних в системах оперативної аналітичної обробки має наступні достоїнства:

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

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

Недоліки MOLAP—моделі:

— Багатовимірні СУБД не дозволяють працювати з великими базами даних.

— Багатовимірні СУБД в порівнянні з реляційними дуже неефективно використовують зовнішню пам'ять. У переважній більшості випадків інформаційний гіперкуб є сильно розрідженим, а оскільки дані зберігаються в упорядкованому вигляді, невизначені значення вдається видалити тільки за рахунок вибору оптимального порядку сортування, що дозволяє організувати дані в максимально великі безперервні групи. Але навіть в цьому випадку проблема вирішується тільки частково. Крім того, оптимальний з точки зору зберігання розріджених даних порядок сортування швидше за все не буде збігатися з порядком, який найчастіше використовується у запитах.

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

— Обсяг вихідних даних для аналізу не занадто великий (не більше декількох гігабайт), тобто рівень агрегації даних досить високий.

— Набір інформаційних вимірів стабільний (оскільки будь—яка зміна в їх структурі майже завжди вимагає повної перебудови гіперкуба).

— Час відповіді системи на нерегламентовані запити є найбільш критичним параметром.

Приклади OLAP—серверів, що використовують MOLAP—архітектуру: Oracle Express Server фірми Oracle, IBM Informix MetaCube, IBM DB2 OLAP, Arbor Essbase.

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

Для більшості сховищ даних найбільш ефективним способом моделювання N—мірного куба фактів є схема «зірка» (star schema).

Основними складовими структури сховищ даних  є таблиця фактів (fact table) і таблиці  вимірів (dimension tables).

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

— факти, пов'язані з транзакціями (Transaction facts). Вони засновані на окремих подіях (типовими прикладами яких є телефонний дзвінок або зняття грошей з рахунку за допомогою банкомату);

— факти, пов'язані з «моментальними знімками» (Snapshot facts). Засновані на стані об'єкта (наприклад, банківського рахунку) в певні моменти часу, наприклад на кінець дня або місяця. Типовими прикладами таких фактів є обсяг продажів за день або денна виручка;

— факти, пов'язані з елементами документа (Line—item facts). Засновані на тому чи іншому документі (наприклад, рахунку за товар або послуги) і містять детальну інформацію про елементи цього документа (наприклад, кількості, ціні, відсотку знижки);

— факти, пов'язані з подіями або станом об'єкта (Event or state facts). Представляють виникнення події без подробиць про нього (наприклад, просто факт продажу або факт відсутності такої без інших подробиць).

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

Зауваження:

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

2. У таблиці фактів відсутні  будь—які відомості про те, як групувати записи при обчисленні агрегатних даних.

Таблиця вимірювань містить незмінні чи рідко  змінювані дані. У кожній таблиці  вимірювань перераховані можливі значення одного з вимірів гіперкуба. У  переважній більшості випадків ці дані представляють собою по одному запису для кожного члена нижнього рівня ієрархії в вимірі. Таблиці вимірів також містять як мінімум одне описове поле (зазвичай з ім'ям члена виміру) і, як правило, ціло чисельне ключове поле (зазвичай це сурогатний ключ) для однозначної ідентифікації члена вимірювання. Кожна таблиця вимірювань повинна знаходитися у відношенні «один до багатьох» з таблицею фактів.

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

 

Рис. 1.7 Схема «зірка»

 

У схемі «зірка» кожне вимірювання куба міститься в одній таблиці, в тому числі і при наявності декількох рівнів ієрархії (держава - регіон – населений пункт в таблиці «Покупець», рік - місяць - день у таблиці «Період»).

У складних завданнях з багаторівневими  вимірами використовуються різні розширення схеми «зірка» - схема «сніжинка» (snowflake schema). Це розширення може проявлятися у двох різновидах.

1. У разі великого числа складних  атрибутів в таблиці вимірювань, деякі атрибути можуть бути  деталізовані в окремих таблицях  вимірів. Іншими словами окремі  вимірювання містяться не в  одній, а в кількох пов'язаних  між собою таблицях. Додаткові таблиці вимірювань в такій схемі, зазвичай відповідні верхнім рівням ієрархії виміру і знаходяться в співвідношенні «один до багатьох» в головній таблиці вимірювань, відповідної нижньому рівню ієрархії, іноді називають консольними таблицями (outrigger table).Наприклад, з таблиці «Покупець» можна вилучити опису регіону, населеного пункту (залишивши лише їх ключі) і зберігати їх в окремих додаткових таблицях. Це зменшить ступінь дублювання інформації, але знижує швидкість виконання запитів, оскільки збільшує ступінь нормалізації. Тому навіть за наявності ієрархічних вимірів з метою підвищення швидкості виконання запитів до сховища даних нерідко перевага віддається схемі «зірка».

2. Інша розширення пов'язане  зі створенням окремих таблиць  фактів для всіх можливих поєднань рівнів узагальнення різних вимірів.

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

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

Нижче наведено фрагмент для одного виміру в схемі «сніжинка».

 

Рис. 1.8 Схема «сніжинка»

 

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

Приклад: отримати середні обсяги продажів товарів кожного постачальника  з розбивкою по покупцям і по місяцях.

 

Рис. 1.9 Приклад запиту

1.4 Висновки до I розділу

 

З практичного  погляду OLAP є якраз тим, чого очікували від СППР протягом багатьох років, тобто перспективною системою, яка проста для використання, містить спеціалізовані (спеціально виділені) дані і пристосована до потреб користувачів. Ця система використовує сховища даних, а також містить велику кількість інструментальних засобів кінцевого користувача для організації доступу до даних і проведення їх аналізу.

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

Досягнутий  на даний час стан технологічних  засобів і вимоги кінцевих користувачів щодо узгоджених і швидких відповідей визначають, що найкращим підходом до організації оброблення даних  є установлення багатовимірної бази даних у сервері OLAP. Прикладами багатовимірних серверів можуть бути Lightship Server від Pilot Software і Essbase від Arbor Software. 

Функціональні можливості OLAP характеризують підтримку  кінцевих користувачів—аналітиків динамічним багатовимірним аналізом консолідованих підприємницьких даних і навігаційними діями, включаючи: обчислення і моделювання, що застосовується за допомогою вимірності, ієрархії і/або компонентів; аналіз трендів за послідовні періоди; квантування підмножин (підмножини даних аналізують за допомогою тонких зрізів) для візуалізації на екрані; практичне оброблення з підвищенням рівня деталізації до найглибших рівнів консолідації основних даних; прямий доступ до основних деталізованих даних; повернення до порівнянь у нових вимірах із застосуванням візуалізації.

OLAP здійснюється  в багатокористувацькому клієнт/серверному режимі і уможливлює узгоджену швидку відповідь на запити, незалежно від обсягу і складності бази даних. OLAP допомагає користувачеві синтезувати інформацію підприємства завдяки порівняльному, конкретизованому перегляду даних, а також завдяки аналізу фактичних і розрахункових показників у варіантах аналізу типу «що …, якщо…?». Все це досягається за допомогою використання сервера OLAP. 

 

 

 

 

 

 

РОЗДІЛ 2

СИСТЕМА УПРАВЛІННЯ КОНТЕНТОМ DRUPAL

 

2.1 Призначення систем управління контентом

 

В Інтернеті часто можна зустріти слоган «створи свій куточок в Інтернеті». Так от, системи управління вмістом, CMS - це і є той самий куточок. З одного боку, це інтерфейс користувача - відвідувача сайту, де господар показує, що у нього є, організує різні WEB-сервіси, а відвідувач може дивитися, купувати, спілкуватися. З іншого боку - це інтерфейс адміністраторської панелі, недоступний для відвідувачів, де і відбувається управління ресурсом - адміністрування, управління виглядом сайту, спілкування з відвідувачами і клієнтами WEB-сайту.

Ролі CMS відводиться значна частина  в загальному розвитку Інтернету. Всесвітня  мережа постійно розвивається семимильними кроками, чому сприяють і загальна комп'ютеризація, і зростаюча зв'язок offline-світу і бізнесу з online способами доставки інформації. Виникає все більшу кількість бажаючих мати своє представництво в Інтернеті. Фактично, з виникненням CMS-конструкторів сайту зняті технічні обмеження на створення свого WEB-сайту - найчастіше досить лише розібратися в інтерфейсі, запланувати структуру сайту і виходить готовий сервіс. Залишилося лише підтримувати сайт, оновлювати інформацію, залучати відвідувачів. Все це стало можливо завдяки широкому розповсюдженню систем управління контентом.

CMS - це абревіатура  від Content Management System, що в дослівному  перекладі означає «система управління контентом сайту» або просто «система управління сайтом». Іноді CMS називають «движок» сайту. CMS - це програмне забезпечення, яке дозволяє розробляти і підтримувати динамічні інформаційні web-сайти. Різні CMS дозволяють проектувати сайти різної складності, аж до Інтернет - магазинів та інформаційних порталів. Найбільше CMS підходять для формування новинних і тематичних сайтів.