них про дзвінки, смс і GPRS-трафіку за той часовий інтервал, який на наступних етапах розробки буде обраний як критерій історичності сховища. br/>
3.2 Проектування сховища даних
Другим етапом розробки аналітичної системи є проектування сховища даних. До проектування сховищ даних зазвичай ставляться такі вимоги:
Спочатку, аналітична система орієнтована на коло користувачів з числа аналітиків і керуючого складу, при цьому залучення інженерів-програмістів, що спеціалізуються на створенні запитів до баз даних, що не передбачається. У зв'язку з цим, структура даних сховища повинна бути зрозуміла користувачам. p align="justify"> Дані в сховищі повинні регулярно поповнюватися. Потрібен ретельно документувати правила поповнення та резервного копіювання даних. p align="justify"> Оскільки звіт буде створювати кінцевий користувач, повинні бути спрощені вимоги до запитів з метою виключення тих запитів, які могли б вимагати множинних тверджень SQL в традиційних реляційних СУБД.
Повинні бути виділені статичні дані, які регулярно модифікуються: щодня, щотижня, щоквартально.
Обробка запитів до сховища повинна бути проведена з високою продуктивністю, бажано в реальному масштабі часу, тому повинна бути забезпечена підтримка складних запитів SQL, які вимагають послідовної обробки тисяч або мільйонів записів.
Ці вимоги істотно відрізняють структуру реляційних БД і сховищ даних. Нормалізація даних в реляційних базах призводить до створення безлічі пов'язаних між собою таблиць. В результаті, виконання складних запитів неминуче призводить до об'єднання багатьох таблиць, що істотно збільшує час відгуку. Проектування сховища даних передбачає створення денормалізованной структури даних (допускається надмірність даних і можливість виникнення аномалій при маніпулюванні даними), орієнтованої в першу чергу на високу продуктивність при виконанні аналітичних запитів. Нормалізація робить модель занадто складною, ускладнює її розуміння і погіршує ефективність виконання запиту. p align="justify"> Для ефективного проектування сховищ даних використовуємо розмірну (Dimensional) модель. Dimensional - методологія проектування, спеціально призначена для розробки сховищ даних. Моделювання Dimensional подібно з моделюванням зв'язків та сутностей для реляційної моделі, але відрізняється цілями. Реляційна модель акцентується на цілісності та ефективності введення даних. Розмірна (Dimensional) модель орієнтована в першу чергу на виконання складних запитів до БД. p align="justify"> У розмірному моделюванні прийнятий стандарт моделі, званий схемою зірка (star schema), яка забезпечує високу швидкість виконання запиту за допомогою денормалізації і розділення даних. Неможливо створити універсальну денормалізованную структуру даних, що забезпечує високу продуктивність при виконанні будь-якого аналітичного запиту. Тому сх...
