того, можна легко визначити аналітичну рекуррентную формулу для обчислення необхідної координати. p align="justify"> Дані, що зберігаються в таблиці необхідно перетворити для їх використання. Так, з метою підвищення продуктивності при побудові гиперкуба, бажано знаходити унікальні елементи, що зберігаються в стовпцях, які є вимірами куба. Крім того, можна виробляти попереднє агрегування фактів для записів, що мають однакові значення розмірностей. Як вже було сказано вище, для нас важливі унікальні значення, наявні в полях вимірювань. Тоді для їх зберігання можна запропонувати наступну структуру:
В
Схема 4. Структура зберігання унікальних значень
При використанні такої структури ми значно знижуємо потребу в пам'яті. Що досить актуально, тому для збільшення швидкості роботи бажано зберігати дані в оперативній пам'яті. Крім того, зберігати можна тільки масив елементів, а їхні значення вивантажувати на диск, так як вони будуть нам турбуватися тільки при виведенні крос-таблиці. p align="justify"> Описані вище ідеї були покладені в основу при створенні бібліотеки компонентів CubeBase.
В
Схема 5. Структура бібліотеки компонентів CubeBase
СubeSource здійснює кешування і перетворення даних у внутрішній формат, а також попереднє агрегування даних. Компонент TСubeEngine здійснює обчислення гиперкуба та операції з ним. Фактично, він є OLAP-машиною, здійснює перетворення плоскої таблиці в багатовимірний набір даних. Компонент TCubeGrid виконує висновок на екран крос-таблиці та управління відображенням гиперкуба. TСubeChart дозволяє побачити гиперкуб у вигляді графіків, а компонент TСubePivote управляє роботою ядра куба. p align="justify"> Отже, мною була розглянута архітектура і взаємодія компонентів, які можуть бути використані для побудови OLAP машини. Тепер розглянемо докладніше внутрішній устрій компонентів. p align="justify"> Першим етапом роботи системи буде завантаження даних і перетворення їх у внутрішній формат. Закономірним буде питання - а навіщо це треба, адже можна просто використовувати дані з плоскою таблиці, переглядаючи її при побудові зрізу куба. Для того щоб відповісти на це питання, розглянемо структуру таблиці з точки зору OLAP машини. Для OLAP системи колонки таблиці можуть бути або фактами, або вимірами. При цьому логіка роботи з цими колонками буде різна. У гіперкубі вимірювання фактично є осями, а значення вимірювань - координатами на цих осях. При цьому куб буде заповнений сильно нерівномірно - будуть поєднання координат, яким не відповідатимуть ніякі записи і будуть поєднання, яким відповідає декілька записів у вихідній таблиці, причому перша ситуація зустрічається частіше, тобто куб буде схожий на всесвіт - порожній простір, в окремих місцях якого зустрічаються скупчення точок (фактів). Таким чином, якщо ми при початковій завантаженні даних зробимо преагрегірованіе даних, тобто об'єднаєм...
