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