даних зробимо преагрегірованіе даних, тобто об'єднаємо записи, які мають однакові значення вимірювань, розрахувавши при цьому попередні агреговані значення фактів, то надалі нам доведеться працювати з меншою кількістю записів, що підвищить швидкість роботи і зменшить вимоги до об'єму оперативної пам'яті.
Для побудови зрізів гиперкуба нам необхідні наступні можливості - визначення координат (фактично значення вимірів) для записів таблиці, а також визначення записів, що мають конкретні координати (значення вимірів). Розглянемо яким чином можна реалізувати ці можливості.
Для зберігання гиперкуба найпростіше використовувати базу даних свого внутрішнього формату.
Тобто замість однієї таблиці ми отримали нормалізовану базу даних. Взагалі-нормалізація знижує швидкість роботи системи, - можуть сказати фахівці по базах даних, і в цьому вони будуть безумовно праві, у разі коли нам треба отримати значення для елементів словників (у нашому випадку значення вимірів). Але вся справа в тому, що нам ці значення на етапі побудови зрізу взагалі не потрібні. Як вже було сказано вище, нас цікавлять тільки координати в нашому гіперкубі, тому визначимо координати для значень вимірів. Найпростішим буде перенумерувати значення елементів. Для того, щоб у межах одного виміру нумерація була однозначною, попередньо відсортуємо списки значень вимірів (словники, висловлюючись термінами БД) в алфавітному порядку. Крім того, перенумеруем і факти, причому факти преагрегірованние.
Тепер залишилося тільки зв'язати елементи різних таблиць між собою. У теорії реляційних баз даних це здійснюється за допомогою спеціальних проміжних таблиць. Нам достатньо кожного запису в таблицях вимірів поставити у відповідність список, елементами якого будуть номери фактів, при формуванні яких використовувалися ці виміри (тобто визначити всі факти, що мають однакове значення координати, описуваної цим виміром). Для фактів відповідно кожного запису поставимо у відповідність значення координат, за якими вона розташована в гіперкубі. Надалі всюди під координатами записи в гіперкубі будуть розумітися номери відповідних записів у таблицях значень вимірів.
.2.2 Реалізація гиперкуба
Можна було б спробувати використовувати для реалізації гиперкуба набір тимчасових таблиць, але цей метод забезпечить занадто низька швидкодія (приклад - набір компонент Decision Cube), тому будемо використовувати свої структури зберігання даних.
Для реалізації гиперкуба нам необхідно використовувати структури даних, які забезпечать максимальну швидкодію і мінімальні витрати оперативної пам'яті. Очевидно, що основними у нас будуть структури для зберігання словників і таблиці фактів. Розглянемо завдання, які повинен виконувати словник з максимальною швидкістю:
перевірка наявності елемента в словнику;
додавання елемента в словник;
пошук номерів записів, що мають конкретне значення координати;
пошук координати за значенням виміру;
пошук значення вимірювання за його координаті.
Для реалізації цих вимог можна використовувати різні типи і структури даних. Наприклад, можна використовувати масиви структур. У реальному випадку до цих масивів необхідні додаткові механізми і...
