ка тарифних планів по якомусь параметру, наприклад, по соціальному позиціонуванню, тоді ціни всередині тарифів однієї групи формуються виходячи з особливостей соціальної групи. Ще одним прикладом угруповання тарифів може бути форма платежу: тарифи бувають передплатної і постоплатной. Врахувати цю особливість просто необхідно, найкращий варіант - створити ще одну таблицю tarif_groups як розширення вимірювання по тарифах. Висловлюючись термінами сховищ даних, дана таблиця буде консольної (outrigger table), вона буде містити два основних поля, первинний ключ tarif_group_id і назва тарифної групи tarif_group_name, також повинні бути присутніми додаткові службові поля: begin_date, end_date, record_date для визначення термінів дії тарифної групи і дати внесення запису про конкретній групі. Таблиця tarif_groups буде батьківської для таблиці tarifs, їх зв'язок визначена як один-до-багатьох, отже, поле tarif_group_id повинно міститися і в таблиці tarifs як зовнішній ключ. p align="justify"> Другою особливістю даної таблиці вимірювань є достатня регулярність зміни характеристик тарифних планів, наприклад, може змінюватися ціна на надані послуги, а також відносно часте поява і зникнення тарифних планів, наприклад, сезонних або рекламних. На відміну від таблиць вимірів, розглянутих вище, дані з цієї таблиці безпосередньо беруть участь у розрахунках виручки компанії, отже, їх точність і історичність найбільш критичні. У цьому випадку, при зміні характеристик пропонованих тарифів не можна просто оновлювати дані в сховищі, необхідно підтримувати історію змін. Кожна зміна буде вноситися в таблицю вимірювань новим записом, з відповідними датами в полях, що визначають терміни дії тарифу та дати внесення запису. Такий захід дозволить отримувати вірну інформацію у звітах за інтервали часу, усередині яких були змінені ті чи інші тарифні характеристики. Це буде враховано при проектуванні ETL-процесу. p align="justify"> Визначившись з усіма таблицями сховища, звернемо увагу на зв'язку між ними. Як вже згадувалося, таблиця фактів (у нашому випадку - facts) це головна таблиця в схемі, всі запити до сховища спрямовані, в основному, на вилучення даних про події, що зберігаються саме в ній. Таблиця фактів і таблиці вимірів пов'язані ідентифікують зв'язками, при цьому первинні ключі таблиць вимірів мігрують в таблицю фактів як зовнішніх ключів. Сукупність цих ключів і буде унікальним складовим ключем таблиці фактів, в нашому випадку це сукупність ключів client_id, region_id, tarif_id, date_id. p align="justify"> Треба звернути увагу на те, що зв'язків між таблицями вимірювань не існує, тому запити, що стосуються кількох таблиць вимірів, без задіяння таблиці фактів як сполучною між ними, неможливі. Наприклад, при необхідності підрахунку кількості клієнтів по регіону або тарифного плану, запит буде будуватися через таблицю фактів, ця особливість ставить завдання внесення в таблицю фактів записів про появу нових клієнтів, навіть не вчинили жодн...
