Konsep analisis data multidimensi erat kaitannya dengan analisis operasional yang dilakukan dengan menggunakan sistem OLAP.

OLAP (On-Line Analytical Processing) adalah teknologi pemrosesan data analitik operasional yang menggunakan metode dan alat untuk mengumpulkan, menyimpan, dan menganalisis data multidimensi untuk mendukung proses pengambilan keputusan.

Tujuan utama sistem OLAP adalah untuk mendukung aktivitas analitis dan permintaan sewenang-wenang (istilah ad-hoc sering digunakan) dari analis pengguna. Tujuan analisis OLAP adalah untuk menguji hipotesis yang muncul.

Asal usul teknologi OLAP adalah pendiri pendekatan relasional, E. Codd. Pada tahun 1993, ia menerbitkan artikel berjudul "OLAP untuk Analis Pengguna: Apa yang Seharusnya". Makalah ini menguraikan konsep dasar analisis online dan mengidentifikasi 12 persyaratan berikut yang harus dipenuhi oleh produk yang memungkinkan analisis online. Tokmakov G.P. Basis data. Konsep database, model data relasional, bahasa SQL. Hal.51

Di bawah ini tercantum 12 aturan yang diuraikan oleh Codd yang mendefinisikan OLAP.

1. Multidimensi -- sistem OLAP pada tingkat konseptual harus menyajikan data dalam bentuk model multidimensi, yang menyederhanakan proses analisis dan persepsi informasi.

2. Transparansi -- sistem OLAP harus menyembunyikan dari pengguna implementasi nyata dari model multidimensi, metode pengorganisasian, sumber, sarana pemrosesan dan penyimpanan.

3. Ketersediaan -- Sistem OLAP harus menyediakan model data tunggal, konsisten dan holistik kepada pengguna, menyediakan akses ke data terlepas dari bagaimana atau di mana data tersebut disimpan.

4. Performa yang konsisten saat mengembangkan laporan - performa sistem OLAP tidak boleh menurun secara signifikan seiring dengan bertambahnya jumlah dimensi tempat analisis dilakukan.

5. Arsitektur klien-server -- sistem OLAP harus dapat bekerja di lingkungan klien-server, karena Sebagian besar data yang saat ini perlu diproses secara operasional dan analitis disimpan secara terdistribusi. Ide utamanya di sini adalah bahwa komponen server alat OLAP harus cukup cerdas dan memungkinkan pembangunan skema konseptual umum berdasarkan generalisasi dan konsolidasi berbagai skema logis dan fisik dari database perusahaan untuk memberikan efek transparansi.

6. Kesetaraan dimensi -- Sistem OLAP harus mendukung model multidimensi yang semua dimensinya sama. Jika perlu, karakteristik tambahan dapat diberikan pada dimensi individual, namun kemampuan ini harus diberikan pada dimensi mana pun.

7. Manajemen dinamis matriks renggang -- sistem OLAP harus menyediakan pemrosesan matriks renggang yang optimal. Kecepatan akses harus dipertahankan terlepas dari lokasi sel data dan konstan untuk model dengan jumlah dimensi berbeda dan tingkat ketersebaran data berbeda.

8. Dukungan untuk mode multi-pengguna - sistem OLAP harus menyediakan kemampuan bagi beberapa pengguna untuk bekerja sama dengan satu model analitik atau membuat model berbeda untuk mereka dari satu data. Dalam hal ini, pembacaan dan penulisan data dimungkinkan, sehingga sistem harus menjamin integritas dan keamanannya.

9. Operasi silang tak terbatas -- Sistem OLAP harus memastikan bahwa hubungan fungsional yang dijelaskan menggunakan bahasa formal tertentu antara sel-sel hypercube dipertahankan saat melakukan operasi irisan, rotasi, konsolidasi, atau penelusuran apa pun. Sistem harus secara mandiri (otomatis) melakukan konversi hubungan yang mapan, tanpa mengharuskan pengguna untuk menimpanya.

10. Manipulasi data intuitif -- Sistem OLAP harus menyediakan cara untuk melakukan operasi pemotongan, rotasi, konsolidasi, dan pengeboran pada hypercube tanpa pengguna harus melakukan banyak manipulasi antarmuka. Dimensi yang ditentukan dalam model analitik harus berisi semua informasi yang diperlukan untuk melakukan operasi di atas.

11. Pilihan fleksibel untuk memperoleh laporan - sistem OLAP harus mendukung berbagai cara visualisasi data, yaitu laporan harus disajikan dalam orientasi apa pun yang memungkinkan. Alat pelaporan harus menyajikan data atau informasi yang disintesis yang dihasilkan dari model data dalam orientasi apa pun yang memungkinkan. Artinya baris, kolom, atau halaman harus menampilkan dimensi 0 hingga N sekaligus, di mana N-- nomor pengukuran seluruh model analitik. Selain itu, setiap dimensi konten yang ditampilkan dalam satu postingan, kolom, atau halaman harus mengizinkan subkumpulan elemen (nilai) apa pun yang terdapat dalam dimensi tersebut untuk ditampilkan dalam urutan apa pun.

12. Dimensi tak terbatas dan jumlah tingkat agregasi - penelitian tentang kemungkinan jumlah dimensi yang diperlukan dalam model analitik menunjukkan bahwa hingga 19 dimensi dapat digunakan secara bersamaan. Oleh karena itu, sangat disarankan agar alat analisis dapat memberikan setidaknya 15, dan sebaiknya 20 pengukuran secara bersamaan. Selain itu, setiap dimensi umum tidak boleh dibatasi dalam jumlah tingkat agregasi dan jalur konsolidasi yang ditentukan pengguna.

Aturan Tambahan Codd.

Kumpulan persyaratan yang menjadi definisi de facto OLAP ini seringkali menimbulkan berbagai keluhan, misalnya aturan 1, 2, 3, 6 adalah persyaratan, dan aturan 10, 11 adalah keinginan yang tidak diformalkan. Tokmakov G.P. Basis data. Konsep database, model data relasional, bahasa SQL. P. 68 Jadi, 12 persyaratan Codd yang tercantum tidak memungkinkan kita untuk mendefinisikan OLAP secara akurat. Pada tahun 1995, Codd menambahkan enam aturan berikut ke daftar di atas:

13. Pengambilan Batch vs. Interpretasi -- Sistem OLAP harus menyediakan akses ke data miliknya sendiri dan data eksternal secara efektif.

14. Dukungan untuk semua model analisis OLAP -- Sistem OLAP harus mendukung keempat model analisis data yang ditentukan oleh Codd: kategorikal, interpretatif, spekulatif, dan stereotip.

15. Pemrosesan data yang tidak dinormalisasi -- sistem OLAP harus diintegrasikan dengan sumber data yang tidak dinormalisasi. Modifikasi data yang dilakukan di lingkungan OLAP tidak boleh mengakibatkan perubahan pada data yang disimpan di sistem eksternal asli.

16. Menyimpan hasil OLAP: menyimpannya secara terpisah dari data sumber - sistem OLAP yang beroperasi dalam mode baca-tulis harus menyimpan hasil secara terpisah setelah data sumber diubah. Dengan kata lain, keamanan data asli terjamin.

17. Penghapusan nilai yang hilang - Sistem OLAP, saat menyajikan data kepada pengguna, harus membuang semua nilai yang hilang. Dengan kata lain, nilai yang hilang harus berbeda dengan nilai nol.

18. Menangani Nilai yang Hilang -- Sistem OLAP harus mengabaikan semua nilai yang hilang tanpa memperhatikan sumbernya. Fitur ini terkait dengan aturan ke-17.

Selain itu, Codd membagi 18 aturan menjadi empat kelompok berikut, menyebutnya fitur. Kelompok-kelompok ini diberi nama B, S, R dan D.

Fitur utama (B) meliputi aturan berikut:

Representasi data konseptual multidimensi (aturan 1);

Manipulasi data intuitif (aturan 10);

Ketersediaan (aturan 3);

Ekstraksi batch vs. interpretasi (aturan 13);

Dukungan untuk semua model analisis OLAP (aturan 14);

Arsitektur klien-server (aturan 5);

Transparansi (aturan 2);

Dukungan multi-pengguna (aturan 8)

Fitur Khusus (S):

Pemrosesan data yang tidak dinormalisasi (aturan 15);

Menyimpan hasil OLAP: menyimpannya secara terpisah dari data sumber (aturan 16);

Penghapusan nilai-nilai yang hilang (aturan 17);

Menangani nilai yang hilang (aturan 18). Fitur Pelaporan (kanan):

Fleksibilitas pelaporan (aturan 11);

Kinerja pelaporan standar (aturan 4);

Konfigurasi lapisan fisik otomatis (aturan asli yang dimodifikasi 7).

Kontrol Dimensi (D):

Universalitas pengukuran (aturan 6);

Jumlah dimensi dan tingkat agregasi yang tidak terbatas (aturan 12);

Operasi tak terbatas antar dimensi (aturan 9).

melakukan

Banyak yang telah ditulis tentang OLAP belakangan ini. Kita dapat mengatakan bahwa ada kemajuan pesat dalam teknologi ini. Benar, bagi kami ledakan ini agak terlambat, namun hal ini tentu saja terkait dengan situasi umum di negara tersebut.

Sistem informasi skala perusahaan, pada umumnya, berisi aplikasi yang dirancang untuk analisis data multidimensi yang kompleks, dinamikanya, trennya, dll. Analisis tersebut pada akhirnya dimaksudkan untuk mendukung pengambilan keputusan. Sistem ini sering disebut sistem pendukung keputusan.

Sistem pendukung keputusan biasanya memiliki sarana untuk menyediakan data agregat kepada pengguna untuk berbagai sampel dari kumpulan asli dalam bentuk yang nyaman untuk persepsi dan analisis. Biasanya, fungsi agregat tersebut membentuk kumpulan data multidimensi (dan karenanya non-relasional) (sering disebut hypercube atau metacube), yang sumbunya berisi parameter, dan sel berisi data agregat yang bergantung padanya - dan data tersebut juga dapat disimpan dalam tabel relasional, tetapi V pada kasus ini kita berbicara tentang organisasi data yang logis, dan bukan tentang implementasi fisik penyimpanannya). Sepanjang setiap sumbu, data dapat diatur ke dalam hierarki, yang mewakili tingkat detail yang berbeda. Berkat model data ini, pengguna dapat merumuskan kueri kompleks, menghasilkan laporan, dan memperoleh subkumpulan data.

Teknologi analisis data multidimensi yang kompleks disebut OLAP (On-Line Analytical Processing).

OLAP adalah komponen kunci dari pergudangan data.

Konsep OLAP dijelaskan pada tahun 1993 oleh Edgar Codd, seorang peneliti database terkenal dan penulis model data relasional (lihatE.F. Codd, SB Codd, dan C.T. Salley, Menyediakan OLAP (pemrosesan analitik online) kepada analis pengguna: Sebuah mandat TI. Laporan teknis, 1993).

Pada tahun 1995, berdasarkan persyaratan yang ditetapkan oleh Codd, apa yang disebut tes FASMI (Analisis Cepat Informasi Multidimensi Bersama) dirumuskan, yang mencakup persyaratan berikut untuk aplikasi analisis multidimensi:

· memberikan hasil analisis kepada pengguna dalam waktu yang dapat diterima (biasanya tidak lebih dari 5 detik), bahkan dengan biaya analisis yang kurang rinci;

· kemampuan untuk melakukan analisis logis dan statistik apa pun yang spesifik untuk aplikasi tertentu dan menyimpannya dalam bentuk yang dapat diakses oleh pengguna akhir;

· akses multi-pengguna ke data dengan dukungan mekanisme penguncian yang sesuai dan sarana akses resmi;

· representasi data konseptual multidimensi, termasuk dukungan penuh untuk hierarki dan banyak hierarki (ini adalah persyaratan utama OLAP);

· kemampuan untuk mengakses informasi apa pun yang diperlukan, terlepas dari volume dan lokasi penyimpanannya.

Perlu dicatat bahwa fungsionalitas OLAP dapat diimplementasikan dengan berbagai cara, mulai dari alat analisis data paling sederhana dalam aplikasi perkantoran hingga sistem analisis terdistribusi berdasarkan produk server. Pengguna dapat dengan mudah melihat data dalam struktur multidimensi yang berlaku untuk masalah mereka sendiri.

2. Apa itu OLAP

OLAP adalah singkatan dari English On-Line Analytical Processing - ini bukan nama produk tertentu, tetapi keseluruhan teknologi. Dalam bahasa Rusia, paling mudah untuk menyebut pemrosesan analitis operasional OLAP. Meskipun dalam beberapa publikasi pemrosesan analitis disebut online dan interaktif, kata sifat “online” paling akurat mencerminkan arti teknologi OLAP.

Pengembangan solusi manajemen oleh seorang manajer termasuk dalam kategori area yang paling sulit untuk diotomatisasi. Namun, saat ini terdapat peluang untuk membantu manajer dalam mengembangkan solusi dan, yang paling penting, secara signifikan mempercepat proses pengembangan solusi, pemilihan dan penerapannya. Anda dapat menggunakan OLAP untuk ini.

Mari kita lihat bagaimana proses pengembangan solusi biasanya terjadi.

Secara historis, solusi untuk mengotomatisasi aktivitas operasional adalah yang paling berkembang. Kita berbicara tentang sistem pemrosesan data transaksional (OLTP), lebih sederhananya disebut sistem operasional. Sistem ini memastikan pencatatan fakta-fakta tertentu, penyimpanan jangka pendek dan pelestariannya dalam arsip. Dasar dari sistem tersebut disediakan oleh sistem manajemen basis data relasional (RDBMS). Pendekatan tradisional adalah mencoba menggunakan sistem operasional yang sudah dibangun untuk mendukung pengambilan keputusan. Biasanya mereka mencoba membangun sistem pertanyaan yang dikembangkan ke sistem operasi dan menggunakan laporan yang diperoleh setelah interpretasi secara langsung untuk mendukung keputusan. Laporan dapat dibuat berdasarkan kustomisasi, mis. manajer meminta laporan, dan secara teratur, ketika laporan dibuat berdasarkan pencapaian peristiwa atau waktu tertentu. Misalnya, proses pendukung keputusan tradisional mungkin terlihat seperti ini: seorang manajer menemui spesialis informasi dan menyampaikan pertanyaannya kepadanya. Kemudian spesialis departemen informasi membuat permintaan ke sistem operasional, menerima laporan elektronik, menafsirkannya dan kemudian menyampaikannya kepada personel manajemen. Tentu saja, skema seperti itu sampai batas tertentu memberikan dukungan pengambilan keputusan, namun memiliki efisiensi yang sangat rendah dan sejumlah besar kelemahan. Jumlah data yang sangat kecil digunakan untuk mendukung keputusan-keputusan penting. Ada masalah lain juga. Proses ini sangat lambat, karena proses penulisan permintaan dan interpretasi laporan elektronik memakan waktu lama. Dibutuhkan waktu berhari-hari, pada saat manajer mungkin perlu mengambil keputusan sekarang juga, dengan segera. Jika kita memperhitungkan bahwa manajer, setelah menerima laporan, mungkin tertarik pada pertanyaan lain (misalnya, mengklarifikasi atau memerlukan pertimbangan data dalam konteks yang berbeda), maka siklus lambat ini harus diulangi, dan karena proses analisis data dari operasional sistem akan terjadi secara iteratif, bahkan semakin banyak waktu yang terbuang. Masalah lainnya adalah masalah bidang aktivitas yang berbeda antara seorang spesialis teknologi informasi dan seorang manajer, yang dapat berpikir dalam kategori yang berbeda dan, akibatnya, tidak saling memahami. Kemudian diperlukan pengulangan klarifikasi tambahan, dan sekali lagi ini adalah waktu yang selalu terbatas. Masalah besar lainnya adalah laporan yang sulit dipahami. Manajer tidak punya waktu untuk memilih nomor yang diminati dari laporan, terutama karena jumlahnya mungkin terlalu banyak (ingat laporan multi-halaman yang sangat besar, yang sebenarnya menggunakan beberapa halaman, dan sisanya digunakan untuk berjaga-jaga). Kami juga mencatat bahwa pekerjaan interpretasi paling sering dilakukan oleh spesialis di departemen informasi. Artinya, seorang spesialis yang kompeten terganggu oleh pekerjaan menggambar diagram yang rutin dan tidak efektif, dll., yang, tentu saja, tidak dapat memberikan pengaruh yang baik pada kualifikasinya. Selain itu, bukan rahasia lagi bahwa dalam rantai penafsiran terdapat pihak-pihak yang berkepentingan dengan sengaja memutarbalikkan informasi yang masuk.

Kekurangan di atas membuat kita berpikir tentang efisiensi sistem operasi secara keseluruhan dan biaya yang terkait dengan keberadaannya, karena ternyata biaya pembuatan sistem operasi tidak dikompensasi secara memadai oleh efisiensi pengoperasiannya.

Pada kenyataannya, masalah-masalah ini bukan disebabkan oleh buruknya kualitas sistem operasi atau kegagalan konstruksinya. Akar permasalahannya terletak pada perbedaan mendasar antara aktivitas operasional yang diotomatisasi oleh sistem operasi dan aktivitas yang mengembangkan dan mengambil keputusan. Perbedaan ini terletak pada kenyataan bahwa data sistem operasi hanyalah catatan peristiwa dan fakta tertentu yang terjadi, tetapi bukan informasi dalam arti umum. Informasi adalah sesuatu yang mengurangi ketidakpastian di bidang apa pun. Dan alangkah baiknya jika informasi mengurangi ketidakpastian dalam pengambilan keputusan. E.F. yang terkenal pernah berbicara tentang ketidaksesuaian sistem operasi yang dibangun di atas RDBMS untuk tujuan ini. Codd, pionir teknologi sistem manajemen basis data relasional pada tahun 1970an: “Meskipun sistem manajemen basis data relasional tersedia bagi pengguna, sistem tersebut tidak pernah diakui menyediakan kemampuan sintesis, analisis, dan konsolidasi yang kuat (fungsi yang disebut analisis data multidimensi)". Kita berbicara secara khusus tentang sintesis informasi, tentang mengubah data dari sistem operasional menjadi informasi dan bahkan menjadi penilaian kualitatif. OLAP memungkinkan transformasi ini.

OLAP didasarkan pada gagasan model data multidimensi. Pemikiran manusia menurut definisinya bersifat multidimensi. Ketika seseorang mengajukan pertanyaan, ia memberikan batasan-batasan, sehingga merumuskan pertanyaan dalam banyak dimensi, sehingga proses analisis dalam model multidimensi sangat dekat dengan realitas pemikiran manusia. Menurut dimensi dalam model multidimensi, faktor-faktor yang mempengaruhi kegiatan perusahaan diplot (misalnya: waktu, produk, cabang perusahaan, geografi, dll.). Dengan cara ini, diperoleh hypercube (tentu saja, namanya tidak terlalu berhasil, karena kubus biasanya dipahami sebagai bangun datar dengan sisi yang sama, yang dalam hal ini jauh dari kasus), yang kemudian diisi dengan indikator kegiatan perusahaan (harga, penjualan, rencana, keuntungan, kerugian dan sebagainya.). Ini dapat diisi dengan data nyata dari sistem operasi dan data perkiraan berdasarkan data historis. Dimensi hypercube bisa rumit, hierarkis, dan hubungan dapat dibangun di antara keduanya. Selama proses analisis, pengguna dapat mengubah sudut pandang data (yang disebut operasi mengubah tampilan logis), sehingga melihat data dari berbagai perspektif dan memecahkan masalah tertentu. Berbagai operasi dapat dilakukan pada kubus, termasuk peramalan dan perencanaan kondisional (analisis bagaimana-jika). Selain itu, operasi dilakukan secara bersamaan pada kubus, yaitu. produknya, misalnya, akan menghasilkan produk hypercube, yang masing-masing selnya merupakan produk dari sel-sel hypercubes pengganda yang sesuai. Secara alami, dimungkinkan untuk melakukan operasi pada hypercubes yang memiliki jumlah dimensi berbeda.

3. Sejarah penciptaan teknologi OLAP

Ide mengolah data pada array multidimensi bukanlah hal baru. Faktanya, ini dimulai pada tahun 1962, ketika Ken Iverson menerbitkan bukunya “A Programming Language” (APL). Implementasi praktis pertama APL terjadi pada akhir tahun enam puluhan oleh IBM. APL adalah bahasa yang sangat elegan dan terdefinisi secara matematis dengan variabel multidimensi dan operasi yang diproses. Ini dimaksudkan untuk menjadi alat orisinal dan ampuh untuk bekerja dengan transformasi multidimensi dibandingkan dengan bahasa pemrograman praktis lainnya.

Namun, idenya untuk waktu yang lama tidak digunakan secara luas, karena waktu untuk antarmuka grafis dan perangkat pencetakan berkualitas tinggi belum tiba, dan tampilan karakter Yunani memerlukan layar, keyboard, dan perangkat pencetakan khusus. Belakangan, kata-kata dalam bahasa Inggris terkadang digunakan untuk menggantikan operator Yunani, tetapi penganut APL menghentikan upaya untuk mempopulerkan bahasa favorit mereka. APL juga menghabiskan sumber daya mesin. Pada masa itu, penggunaannya mahal. Program-program tersebut sangat lambat untuk dijalankan dan, terlebih lagi, menjalankannya sangat mahal. Dibutuhkan banyak memori, jumlah yang mengejutkan pada saat itu (sekitar 6 MB).

Namun, rasa frustrasi atas kesalahan awal ini tidak mematikan gagasan tersebut. Itu digunakan dalam banyak aplikasi bisnis di tahun 70an, 80an. Banyak dari aplikasi ini memiliki fitur sistem pemrosesan analitis modern. Oleh karena itu, IBM mengembangkan sistem operasi untuk APL yang disebut VSPC, dan beberapa orang menganggapnya sebagai lingkungan yang ideal untuk penggunaan pribadi hingga spreadsheet ada di mana-mana.

Namun APL terlalu sulit untuk digunakan, terutama karena selalu ada ketidakkonsistenan antara bahasa itu sendiri dan perangkat keras yang digunakan untuk mengimplementasikannya.

Pada tahun 1980an, APL tersedia pada mesin pribadi, namun tidak menemukan penggunaan pasar. Alternatifnya adalah memprogram aplikasi multidimensi menggunakan array dalam bahasa lain. Ini adalah tugas yang sangat sulit bahkan bagi programmer profesional, memaksa mereka untuk menunggu produk perangkat lunak multidimensi generasi berikutnya.

Pada tahun 1972, beberapa produk perangkat lunak aplikasi multidimensi yang sebelumnya digunakan untuk tujuan pendidikan mulai digunakan secara komersial: Express. Itu masih dalam bentuk yang sepenuhnya ditulis ulang sampai sekarang, tetapi konsep asli tahun 70-an tidak lagi relevan. Saat ini, di tahun 90an, Express adalah salah satu teknologi OLAP yang paling populer, dan Oracle(r) akan mempromosikannya dan menambahkan kemampuan baru.

Produk multidimensi lebih banyak muncul di tahun 80an. Pada awal dekade, produk bernama Stratagem, yang kemudian disebut Acumate (sekarang dimiliki oleh Kenan Technologies), masih dipromosikan hingga awal tahun 90-an, tetapi saat ini, tidak seperti Express, praktis tidak digunakan.

Comshare System W adalah produk multidimensi dengan gaya berbeda. Diperkenalkan pada tahun 1981, ini adalah yang pertama yang lebih fokus pada pengguna akhir dan pengembangan aplikasi keuangan. Dia memperkenalkan banyak konsep yang tidak diadopsi dengan baik, seperti aturan yang sepenuhnya non-prosedural, tampilan layar penuh dan pengeditan data multidimensi, penghitungan ulang otomatis, dan integrasi batch dengan data relasional. Namun, Comshare System W cukup berat untuk perangkat keras pada saat itu dibandingkan dengan produk lain dan semakin jarang digunakan di masa mendatang, semakin sedikit penjualannya, dan tidak ada perbaikan yang dilakukan pada produk tersebut. Meskipun masih tersedia di UNIX, ini bukan server klien, sehingga tidak meningkatkan penawarannya di pasar analitik. Pada akhir 1980an, Comshare merilis produk untuk DOS dan kemudian untuk Windows. Produk ini disebut Commander Prism dan menggunakan konsep yang sama dengan System W.

Produk kreatif lainnya di akhir tahun 80an disebut Metafora. Itu ditujukan untuk pemasar profesional. Ia juga memperkenalkan banyak konsep baru yang baru mulai digunakan secara luas saat ini: komputasi client-server, penggunaan model multidimensi pada data relasional, pengembangan aplikasi berorientasi objek. Namun, standar Perangkat keras Mesin pribadi pada masa itu tidak mampu menjalankan Metafora, dan vendor terpaksa mengembangkan standar mereka sendiri untuk mesin dan jaringan pribadi. Metafora secara bertahap mulai bekerja dengan sukses pada mesin pribadi serial, namun produk tersebut dibuat khusus untuk OS/2 dan memiliki antarmuka pengguna grafisnya sendiri.

Metafora kemudian mengadakan aliansi pemasaran dengan IBM, yang kemudian diakuisisi. Pada pertengahan tahun 1994, IBM memutuskan untuk mengintegrasikan teknologi Metaphor (berganti nama menjadi DIS) dengan teknologi masa depannya dan dengan demikian menghentikan pendanaan untuk lini terpisah, tetapi pelanggan menyatakan ketidaksenangan mereka dan menuntut dukungan berkelanjutan untuk produk tersebut. Dukungan dilanjutkan untuk pelanggan yang tersisa, dan IBM merilis kembali produk tersebut dengan nama baru DIS, namun tidak membuatnya populer. Namun konsep Metaphor yang kreatif dan inovatif tidak dilupakan dan terlihat di banyak produk saat ini.

Pada pertengahan tahun 80an, lahir istilah EIS (Executive Information System). Produk pertama yang secara jelas menunjukkan arah ini adalah Pusat Komando Pilot. Itu adalah produk yang memungkinkan komputasi kolaboratif, yang sekarang kita sebut komputasi klien-server. Karena kekuatan komputer pribadi pada tahun 1980an terbatas, produk ini sangat “berpusat pada server”, namun prinsip ini masih sangat populer hingga saat ini. Pilot tidak lama menjual Command Center, namun memperkenalkan banyak konsep yang dapat dikenali dalam produk OLAP saat ini, termasuk dukungan otomatis untuk interval waktu, penghitungan klien-server multidimensi, dan kontrol proses analisis yang disederhanakan (mouse, layar sentuh). , dll.). Beberapa konsep ini kemudian diterapkan kembali di Server Analisis Percontohan.

Pada akhir tahun 1980an, spreadsheet mendominasi pasar alat yang menyediakan analisis kepada pengguna akhir. Spreadsheet multidimensi pertama diperkenalkan oleh Compete. Ini dipasarkan sebagai produk yang sangat mahal bagi para profesional, namun vendor gagal memastikan bahwa produk tersebut dapat menangkap pasar, dan Computer Associates memperoleh hak atas produk tersebut bersama dengan produk lainnya termasuk Supercalc dan 20/20. Dampak utama dari akuisisi CA Compete adalah penurunan tajam harga dan penghapusan perlindungan salinan, yang tentu saja berkontribusi terhadap distribusinya. Namun, hal itu tidak berhasil. Bersaing adalah dasar dari Supercalc 5, namun aspek multidimensinya tidak dipromosikan. Compete lama terkadang masih digunakan karena fakta bahwa banyak sumber daya yang diinvestasikan di dalamnya pada satu waktu.

Lotus adalah perusahaan berikutnya yang mencoba memasuki pasar spreadsheet multidimensi dengan produk Improv-nya, yang dijalankan pada mesin NeXT. Hal ini setidaknya memastikan bahwa penjualan 1-2-3 tidak akan menurun, namun ketika akhirnya dirilis untuk Windows, Excel sudah memiliki pangsa pasar yang besar, sehingga mencegah Lotus melakukan perubahan apa pun terhadap distribusi pasar. Lotus, seperti CA dengan Compete, memindahkan Improv ke pasar kelas bawah, tetapi ini bukan syarat untuk promosi pasar yang sukses, dan perkembangan baru di bidang ini tidak berlanjut. Ternyata pengguna komputer pribadi lebih menyukai spreadsheet 1-2-3 dan tidak tertarik pada kemampuan multidimensi baru kecuali jika spreadsheet tersebut sepenuhnya kompatibel dengan spreadsheet lama. Demikian pula, konsep spreadsheet desktop kecil yang ditawarkan sebagai aplikasi pribadi belum terbukti nyaman atau diterapkan di dunia bisnis nyata. Microsoft (r) mengikuti jalur ini dengan menambahkan PivotTable (dalam edisi Rusia ini disebut “tabel pivot”) ke Excel. Meskipun hanya sedikit pengguna Excel yang mendapatkan manfaat dari penggunaan fitur ini, ini mungkin satu-satunya bukti meluasnya penggunaan kemampuan analisis multivariat di dunia hanya karena ada begitu banyak pengguna Excel di dunia.

4. OLAP, ROLAP, MOLAP…

Diketahui bahwa ketika Codd menerbitkan aturannya untuk membangun DBMS relasional pada tahun 1985, aturan tersebut menimbulkan reaksi keras dan kemudian berdampak kuat pada industri DBMS secara umum. Namun, hanya sedikit orang yang mengetahui bahwa pada tahun 1993 Codd menerbitkan sebuah karya berjudul “OLAP for User Analysts: What It Should Be.” Di dalamnya, ia menguraikan konsep dasar analisis online dan menetapkan 12 aturan yang harus dipenuhi oleh produk yang menyediakan kemampuan analisis online.

Berikut aturannya (teks asli dipertahankan bila memungkinkan):

1. Representasi multidimensi konseptual. Analis pengguna melihat dunia perusahaan bersifat multidimensi. Oleh karena itu, model OLAP pada intinya harus multidimensi. Diagram konseptual multidimensi atau representasi khusus memfasilitasi pemodelan dan analisis serta penghitungan.

2. Transparansi. Apakah produk OLAP merupakan bagian dari alat pengguna atau tidak, fakta ini harus transparan kepada pengguna. Jika OLAP disediakan oleh komputasi client-server, maka fakta ini juga harus, jika memungkinkan, tidak terlihat oleh pengguna. OLAP harus disediakan dalam konteks arsitektur yang benar-benar terbuka, memungkinkan pengguna, dimanapun dia berada, untuk berkomunikasi melalui alat analisis dengan server. Selain itu, transparansi harus dicapai ketika alat analisis berinteraksi dengan lingkungan database yang homogen dan heterogen.

3. Ketersediaan. Pengguna analis OLAP harus mampu melakukan analisis berdasarkan skema konseptual umum yang berisi data seluruh perusahaan dalam database relasional serta data dari database lama, metode akses umum, dan model analitik umum. Ini berarti bahwa OLAP harus menyediakan skema logisnya sendiri untuk akses dalam lingkungan database yang heterogen dan melakukan transformasi yang sesuai untuk menyediakan data kepada pengguna. Selain itu, perlu untuk berhati-hati terlebih dahulu mengenai di mana dan bagaimana, serta jenis organisasi fisik data apa yang sebenarnya akan digunakan. Sistem OLAP seharusnya hanya mengakses data yang benar-benar diperlukan, daripada mengadopsi pendekatan umum “saluran dapur” yang memberikan masukan yang tidak perlu.

4. Kinerja yang konsisten dalam pengembangan laporan. Jika jumlah dimensi atau ukuran database meningkat, analis pengguna tidak akan mengalami penurunan kinerja yang signifikan. Performa yang konsisten sangat penting sekaligus menjaga kemudahan penggunaan pengguna akhir dan membatasi kompleksitas OLAP. Jika analis pengguna mengalami perbedaan kinerja yang signifikan berdasarkan jumlah dimensi, maka ia akan cenderung mengkompensasi perbedaan tersebut dengan strategi desain, yang akan menyebabkan data disajikan dengan cara lain selain cara data sebenarnya disajikan. perlu disajikan. Menghabiskan waktu menjelajahi sistem untuk mengkompensasi kekurangannya bukanlah tujuan produk analitik dirancang.

5. Arsitektur klien-server. Sebagian besar data yang perlu diproses dengan cepat dan analitis saat ini disimpan di mainframe dengan akses PC. Oleh karena itu, ini berarti produk OLAP harus dapat beroperasi di lingkungan client-server. Dari sudut pandang ini, komponen server dari alat analisis harus secara substansial “cerdas” sehingga berbagai klien dapat terhubung ke server dengan kompleksitas minimal dan pemrograman integrasi. Server yang cerdas harus mampu memetakan dan mengkonsolidasikan antara skema database logis dan fisik yang berbeda. Hal ini akan memberikan transparansi dan membangun kerangka konseptual, logis dan fisik yang umum.

6. Multidimensi umum. Setiap dimensi harus diterapkan tanpa memperhatikan struktur dan kemampuan operasionalnya. Kemampuan operasional tambahan dapat diberikan pada dimensi yang dipilih, dan karena dimensinya simetris, fungsi tunggal dapat diberikan pada dimensi mana pun. Struktur dasar data, rumus dan format laporan tidak boleh bias terhadap dimensi apapun.

7. Kontrol dinamis matriks renggang. Desain fisik alat OLAP harus sepenuhnya disesuaikan dengan model analitik spesifik untuk pengelolaan matriks renggang yang optimal. Untuk matriks renggang tertentu, hanya ada satu skema fisik optimal. Skema ini memberikan efisiensi memori maksimum dan pengoperasian matriks, kecuali, tentu saja, seluruh kumpulan data tidak muat dalam memori. Data fisik yang mendasari alat OLAP harus dikonfigurasikan ke subset dimensi apa pun, dalam urutan apa pun, untuk operasi praktis pada model analitik berukuran besar. Metode akses fisik juga harus berubah secara dinamis dan berisi berbagai jenis mekanisme, seperti: penghitungan langsung, pohon B dan turunannya, hashing, dan kemampuan untuk menggabungkan mekanisme ini jika diperlukan. Ketersebaran (diukur sebagai persentase sel kosong terhadap semua sel yang mungkin) adalah salah satu karakteristik propagasi data. Kegagalan dalam mengatur ketersebaran dapat membuat efisiensi operasional tidak dapat dicapai. Jika alat OLAP tidak dapat mengontrol dan mengatur distribusi nilai data yang dianalisis, model yang diklaim praktis, berdasarkan banyak jalur dan dimensi konsolidasi, mungkin pada kenyataannya tidak diperlukan dan tidak ada harapan.

8. Dukungan multi-pengguna. Seringkali, beberapa pengguna analitik perlu bekerja secara kolaboratif dengan model analitik yang sama atau membuat model berbeda dari data yang sama. Oleh karena itu, alat OLAP harus menyediakan kemampuan berbagi (kueri dan penyelesaian), integritas, dan keamanan.

9. Operasi silang tanpa batas. Tingkat rollup dan jalur konsolidasi yang berbeda, karena sifat hierarkinya, mewakili hubungan ketergantungan dalam model atau aplikasi OLAP. Oleh karena itu, alat itu sendiri harus menyiratkan penghitungan yang sesuai dan tidak mengharuskan pengguna analitis untuk mendefinisikan ulang penghitungan dan operasi ini. Perhitungan yang tidak dihasilkan dari hubungan yang diwariskan ini memerlukan definisi dengan rumus yang berbeda menurut beberapa bahasa yang berlaku. Bahasa seperti itu memungkinkan penghitungan dan manipulasi data dari dimensi apa pun dan tidak membatasi hubungan antar sel data atau memperhatikan jumlah atribut data umum dari sel tertentu.

10. Manipulasi data intuitif. Reorientasi jalur konsolidasi, perincian, pembesaran, dan manipulasi lain yang diatur oleh jalur konsolidasi harus diterapkan melalui dampak terpisah pada sel model analitik, dan tidak memerlukan penggunaan sistem menu atau tindakan ganda lainnya dengan antarmuka pengguna. Pandangan analis pengguna terhadap dimensi yang ditentukan dalam model analitik harus berisi semua informasi yang diperlukan untuk melakukan tindakan di atas.

11. Pilihan fleksibel untuk menerima laporan. Analisis dan penyajian data menjadi sederhana ketika baris, kolom, dan sel data yang akan dibandingkan secara visual satu sama lain akan berdekatan satu sama lain atau menurut beberapa fungsi logis yang terjadi di perusahaan. Alat pelaporan harus menyajikan data atau informasi yang disintesis yang dihasilkan dari model data dalam orientasi apa pun yang memungkinkan. Artinya baris, kolom, atau halaman harus menampilkan dimensi dari 0 hingga N sekaligus, dengan N adalah jumlah dimensi keseluruhan model analitik. Selain itu, setiap dimensi konten yang ditampilkan dalam satu postingan, kolom, atau halaman juga harus dapat menampilkan subset elemen (nilai) apa pun yang terkandung dalam dimensi tersebut, dalam urutan apa pun.

12. Dimensi dan jumlah tingkat agregasi tidak terbatas. Sebuah studi tentang kemungkinan jumlah dimensi yang diperlukan dalam model analitik menunjukkan bahwa hingga 19 dimensi dapat digunakan secara bersamaan. Oleh karena itu, sangat disarankan agar alat analisis mampu menyediakan setidaknya 15 dimensi secara bersamaan, dan sebaiknya 20 dimensi. Selain itu, masing-masing dimensi umum tidak boleh dibatasi dalam jumlah tingkat agregasi dan jalur konsolidasi yang ditentukan pengguna-analis.

Faktanya, pengembang produk OLAP saat ini mengikuti aturan ini, atau setidaknya berusaha untuk mengikutinya. Aturan-aturan ini dapat dianggap sebagai landasan teoretis dari pemrosesan analitis operasional; sulit untuk membantahnya. Selanjutnya, banyak konsekuensi yang diambil dari 12 aturan tersebut, namun tidak akan kami kutip, agar tidak memperumit narasi yang tidak perlu.

Mari kita lihat lebih dekat perbedaan produk OLAP dalam implementasi fisiknya.

Seperti disebutkan di atas, OLAP didasarkan pada gagasan pemrosesan data menggunakan struktur multidimensi. Ketika kami mengatakan OLAP, yang kami maksud adalah bahwa secara logis struktur data produk analitik bersifat multidimensi. Bagaimana tepatnya hal ini diterapkan adalah persoalan lain. Ada dua jenis utama pemrosesan analitis, yang mencakup produk tertentu.

MOLAP . Sebenarnya OLAP multidimensi (multidimensi). Produk ini didasarkan pada struktur data non-relasional yang menyediakan penyimpanan, pemrosesan, dan penyajian data multidimensi. Oleh karena itu, database disebut multidimensi. Produk di kelas ini biasanya memiliki server database multidimensi. Selama proses analisis, data dipilih secara eksklusif dari struktur multidimensi. Struktur seperti ini sangat produktif.

ROLAP . OLAP Relasional. Sesuai dengan namanya, struktur multidimensi pada alat tersebut diimplementasikan melalui tabel relasional. Dan data dalam proses analisis dipilih dari database relasional dengan alat analisis.

Kelemahan dan kelebihan masing-masing pendekatan secara umum sudah jelas. OLAP multidimensi memberikan kinerja yang lebih baik, tetapi struktur tidak dapat digunakan untuk memproses data dalam jumlah besar, karena dimensi yang besar akan memerlukan sumber daya perangkat keras yang besar, dan pada saat yang sama, ketersebaran hypercubes bisa sangat tinggi dan, oleh karena itu, penggunaan daya perangkat keras tidak akan dibenarkan. Sebaliknya, OLAP relasional menyediakan pemrosesan pada sejumlah besar data yang disimpan, karena dimungkinkan untuk menyediakan penyimpanan yang lebih ekonomis, tetapi pada saat yang sama kecepatannya jauh lebih rendah dibandingkan OLAP multidimensi. Alasan serupa mengarah pada identifikasi kelas alat analisis baru - HOLAP. Ini adalah pemrosesan analitis operasional hibrid. Alat kelas ini memungkinkan Anda menggabungkan kedua pendekatan - relasional dan multidimensi. Akses dapat dilakukan ke data database multidimensi dan data relasional.

Ada jenis pemrosesan analitik operasional lain yang agak eksotis - DOLAP. Ini adalah OLAP “desktop”. Kita berbicara tentang pemrosesan analitik di mana hypercubes berukuran kecil, dimensinya kecil, kebutuhannya sederhana, dan untuk pemrosesan analitik seperti itu, mesin pribadi di desktop sudah cukup.

Pemrosesan analitik operasional dapat secara signifikan menyederhanakan dan mempercepat proses persiapan dan pengambilan keputusan oleh personel manajemen. Pemrosesan analitis online bertujuan mengubah data menjadi informasi. Hal ini secara mendasar berbeda dari proses pendukung keputusan tradisional, yang paling sering didasarkan pada peninjauan laporan terstruktur. Secara analogi, perbedaan antara laporan terstruktur dan OLAP sama seperti antara berkendara keliling kota dengan trem dan mengendarai mobil pribadi. Saat Anda naik trem, ia bergerak di atas rel, sehingga Anda tidak dapat melihat dengan jelas bangunan di kejauhan, apalagi mendekatinya. Sebaliknya, mengendarai mobil pribadi memberikan kebebasan bergerak sepenuhnya (tentunya Anda harus mengikuti peraturan lalu lintas). Anda dapat berkendara ke gedung mana pun dan mencapai tempat-tempat yang tidak dilalui trem.

Laporan terstruktur menjadi rel yang menghambat kebebasan dalam mempersiapkan keputusan. OLAP adalah kendaraan untuk pergerakan efisien di sepanjang jalan raya informasi.

Mengirimkan karya bagus Anda ke basis pengetahuan itu sederhana. Gunakan formulir di bawah ini

Pelajar, mahasiswa pascasarjana, ilmuwan muda yang menggunakan basis pengetahuan dalam studi dan pekerjaan mereka akan sangat berterima kasih kepada Anda.

Diposting pada http://www.allbest.ru/

Pekerjaan kursus

disiplin: Database

Subjek: TeknologiOLAP

Lengkap:

Chizhikov Alexander Alexandrovich

Perkenalan

1. Klasifikasi produk OLAP

2. Klien OLAP - Server OLAP: pro dan kontra

3. Sistem inti OLAP

3.1 Prinsip desain

Kesimpulan

Daftar sumber yang digunakan

Aplikasi

DI DALAMmelakukan

Sulit untuk menemukan seseorang di dunia komputer yang, setidaknya secara intuitif, tidak memahami apa itu database dan mengapa database diperlukan. Berbeda dengan DBMS relasional tradisional, konsep OLAP tidak begitu dikenal luas, meskipun hampir semua orang mungkin pernah mendengar istilah misterius “kubus OLAP”. Apa itu Pemrosesan Analitik OnLine?

OLAP bukanlah produk perangkat lunak yang terpisah, bukan bahasa pemrograman, atau bahkan teknologi tertentu. Jika kita mencoba untuk mencakup OLAP dalam semua manifestasinya, maka itu adalah seperangkat konsep, prinsip, dan persyaratan yang mendasari produk perangkat lunak yang memudahkan analis untuk mengakses data. Meskipun tidak ada seorang pun yang tidak setuju dengan definisi tersebut, diragukan bahwa definisi tersebut akan membawa orang non-spesialis sedikit pun lebih dekat dalam memahami subjek tersebut. Oleh karena itu, dalam upaya Anda memahami OLAP, lebih baik mengambil jalan yang berbeda. Pertama, kita perlu mencari tahu mengapa analis perlu secara khusus memfasilitasi akses terhadap data.

Faktanya adalah analis adalah konsumen khusus informasi perusahaan. Tugas analis adalah menemukan pola dalam data dalam jumlah besar. Oleh karena itu, analis tidak akan memperhatikan satu fakta pun; ia memerlukan informasi tentang ratusan atau ribuan peristiwa. Omong-omong, salah satu poin penting yang menyebabkan munculnya OLAP adalah produktivitas dan efisiensi. Mari kita bayangkan apa yang terjadi ketika seorang analis perlu memperoleh informasi, tetapi tidak ada alat OLAP di perusahaan. Analis secara mandiri (yang tidak mungkin) atau dengan bantuan seorang programmer membuat query SQL yang sesuai dan menerima data yang diinginkan dalam bentuk laporan atau mengekspornya ke spreadsheet. Banyak sekali permasalahan yang muncul dalam kasus ini. Pertama, analis terpaksa melakukan sesuatu selain pekerjaannya (pemrograman SQL) atau menunggu pemrogram menyelesaikan tugasnya - semua ini berdampak negatif pada produktivitas tenaga kerja, tingkat serangan jantung dan stroke meningkat, dan seterusnya. Kedua, satu laporan atau tabel, sebagai suatu peraturan, tidak menyelamatkan para raksasa pemikiran dan bapak analisis Rusia - dan seluruh prosedur harus diulangi lagi dan lagi. Ketiga, seperti yang telah kita ketahui, analis tidak menanyakan hal-hal sepele - mereka membutuhkan semuanya sekaligus. Ini berarti (meskipun teknologi maju dengan pesat) bahwa server DBMS relasional perusahaan yang diakses oleh analis dapat berpikir secara mendalam dan untuk waktu yang lama, memblokir transaksi lainnya.

Konsep OLAP muncul justru untuk memecahkan masalah tersebut. Kubus OLAP pada dasarnya adalah laporan meta. Dengan memotong laporan meta (kubus, yaitu) sepanjang dimensi, analis sebenarnya menerima laporan dua dimensi "biasa" yang menarik baginya (ini belum tentu laporan dalam arti biasa - kita berbicara tentang struktur data dengan fungsi yang sama). Keuntungan dari kubus sudah jelas - data hanya perlu diminta dari DBMS relasional sekali - saat membuat kubus. Karena analis, pada umumnya, tidak bekerja dengan informasi yang ditambah dan diubah dengan cepat, kubus yang dihasilkan relevan untuk waktu yang cukup lama. Berkat ini, tidak hanya gangguan dalam pengoperasian server DBMS relasional dihilangkan (tidak ada pertanyaan dengan ribuan dan jutaan jalur respons), namun kecepatan akses ke data untuk analis itu sendiri juga meningkat tajam. Selain itu, seperti yang telah disebutkan, kinerja juga ditingkatkan dengan menghitung subsum hierarki dan nilai agregat lainnya pada saat kubus dibuat.

Tentu saja Anda harus mengeluarkan biaya untuk meningkatkan produktivitas dengan cara ini. Kadang-kadang dikatakan bahwa struktur data hanya “meledak” - sebuah kubus OLAP dapat memakan ruang puluhan atau bahkan ratusan kali lebih banyak daripada data aslinya.

Sekarang kita memiliki sedikit pemahaman tentang cara kerja OLAP dan apa fungsinya, ada baiknya kita memformalkan pengetahuan kita dan memberikan kriteria OLAP tanpa terjemahan simultan ke dalam bahasa manusia biasa. Kriteria ini (total 12) dirumuskan pada tahun 1993 oleh E.F. Codd - pencipta konsep DBMS relasional dan, secara bersamaan, OLAP. Kami tidak akan mempertimbangkannya secara langsung, karena kemudian diubah menjadi apa yang disebut tes FASMI, yang menentukan persyaratan untuk produk OLAP. FASMI merupakan singkatan dari nama tiap butir soal:

Cepat (cepat). Properti ini berarti bahwa sistem harus memberikan respons terhadap permintaan pengguna rata-rata dalam lima detik; namun, sebagian besar permintaan diproses dalam waktu satu detik, dan permintaan yang paling rumit harus diproses dalam waktu dua puluh detik. Studi terbaru menunjukkan bahwa pengguna mulai meragukan keberhasilan suatu permintaan jika dibutuhkan lebih dari tiga puluh detik.

Analisis (analitis). Sistem harus mampu menangani analisis logis dan statistik apa pun yang umum digunakan dalam aplikasi bisnis, dan memastikan bahwa hasilnya disimpan dalam bentuk yang dapat diakses oleh pengguna akhir. Alat analisis dapat mencakup prosedur untuk menganalisis deret waktu, distribusi biaya, konversi mata uang, pemodelan perubahan struktur organisasi, dan beberapa lainnya.

Bersama. Sistem harus memberikan peluang luas untuk membatasi akses ke data dan pengoperasian banyak pengguna secara bersamaan.

Multidimensi (multidimensi). Sistem harus memberikan pandangan data yang secara konseptual multidimensi, termasuk dukungan penuh untuk berbagai hierarki.

Informasi. Kekuatan berbagai produk perangkat lunak ditandai dengan jumlah input data yang diproses. Sistem OLAP yang berbeda mempunyai kapasitas yang berbeda: solusi OLAP tingkat lanjut dapat menangani data setidaknya seribu kali lebih banyak dibandingkan solusi yang paling tidak berdaya. Saat memilih alat OLAP, ada sejumlah faktor yang perlu dipertimbangkan, termasuk duplikasi data, kebutuhan memori, penggunaan ruang disk, metrik kinerja, integrasi dengan gudang informasi, dan sebagainya.

1. Klasifikasi produk OLAP

Jadi, inti dari OLAP adalah bahwa informasi awal untuk analisis disajikan dalam bentuk kubus multidimensi, dan dimungkinkan untuk memanipulasinya secara sewenang-wenang dan memperoleh bagian informasi yang diperlukan - laporan. Dalam hal ini, pengguna akhir melihat kubus sebagai tabel dinamis multidimensi yang secara otomatis merangkum data (fakta) dalam berbagai bagian (dimensi), dan memungkinkan pengelolaan perhitungan dan formulir laporan secara interaktif. Operasi ini dilakukan oleh mesin OLAP (atau mesin perhitungan OLAP).

Saat ini, banyak produk telah dikembangkan di seluruh dunia yang menerapkan teknologi OLAP. Untuk memudahkan navigasi di antara mereka, klasifikasi produk OLAP digunakan: berdasarkan metode penyimpanan data untuk analisis dan berdasarkan lokasi mesin OLAP. Mari kita lihat lebih dekat setiap kategori produk OLAP.

Saya akan mulai dengan klasifikasi berdasarkan metode penyimpanan data. Izinkan saya mengingatkan Anda bahwa kubus multidimensi dibangun berdasarkan data awal dan agregat. Data sumber dan agregat untuk kubus dapat disimpan dalam database relasional dan multidimensi. Oleh karena itu, tiga metode penyimpanan data yang saat ini digunakan: MOLAP (Multidimensional OLAP), ROLAP (Relational OLAP) dan HOLAP (Hybrid OLAP). Oleh karena itu, produk OLAP dibagi menjadi tiga kategori serupa berdasarkan metode penyimpanan data:

1.Dalam kasus MOLAP, data sumber dan agregat disimpan dalam database multidimensi atau dalam kubus lokal multidimensi.

2.Dalam produk ROLAP, data sumber disimpan dalam database relasional atau dalam tabel lokal datar di server file. Data agregat dapat ditempatkan di tabel layanan dalam database yang sama. Konversi data dari database relasional menjadi kubus multidimensi terjadi atas permintaan alat OLAP.

3. Saat menggunakan arsitektur HOLAP, data asli tetap berada di database relasional, dan agregat ditempatkan di database multidimensi. Kubus OLAP dibuat atas permintaan alat OLAP berdasarkan data relasional dan multidimensi.

Klasifikasi selanjutnya didasarkan pada lokasi mesin OLAP. Berdasarkan fitur ini, produk OLAP dibagi menjadi server OLAP dan klien OLAP:

Di alat OLAP server, penghitungan dan penyimpanan data agregat dilakukan oleh proses terpisah - server. Aplikasi klien hanya menerima hasil query terhadap kubus multidimensi yang disimpan di server. Beberapa server OLAP mendukung penyimpanan data hanya dalam database relasional, beberapa hanya dalam database multidimensi. Banyak server OLAP modern mendukung ketiga metode penyimpanan data: MOLAP, ROLAP, dan HOLAP.

Klien OLAP dirancang berbeda. Konstruksi kubus multidimensi dan penghitungan OLAP dilakukan di memori komputer klien. Klien OLAP juga dibagi menjadi ROLAP dan MOLAP. Dan beberapa mungkin mendukung kedua opsi akses data.

Masing-masing pendekatan ini mempunyai kelebihan dan kekurangannya masing-masing. Bertentangan dengan kepercayaan umum tentang keunggulan alat server dibandingkan alat klien, dalam beberapa kasus, penggunaan klien OLAP bagi pengguna bisa lebih efektif dan menguntungkan daripada menggunakan server OLAP.

2. Klien OLAP - Server OLAP: pro dan kontra

Saat membangun sistem informasi, fungsionalitas OLAP dapat diimplementasikan menggunakan alat OLAP server dan klien. Dalam praktiknya, pilihannya adalah trade-off antara kinerja dan biaya perangkat lunak.

Volume data ditentukan oleh kombinasi karakteristik berikut: jumlah record, jumlah dimensi, jumlah elemen dimensi, panjang dimensi dan jumlah fakta. Diketahui bahwa server OLAP dapat memproses data dalam jumlah yang lebih besar daripada klien OLAP dengan kekuatan komputer yang sama. Ini karena server OLAP menyimpan hard drive database multidimensi yang berisi kubus yang telah dihitung sebelumnya.

Saat melakukan operasi OLAP, program klien mengeksekusi kueri dalam bahasa mirip SQL, tidak menerima seluruh kubus, tetapi fragmen yang ditampilkan. Pada saat pengoperasian, klien OLAP harus memilikinya memori akses acak seluruh kubus Dalam kasus arsitektur ROLAP, pertama-tama perlu memuat seluruh larik data yang digunakan untuk menghitung kubus ke dalam memori. Selain itu, seiring bertambahnya jumlah dimensi, fakta, atau anggota dimensi, jumlah agregat bertambah secara eksponensial. Dengan demikian, jumlah data yang diproses oleh klien OLAP berbanding lurus dengan jumlah RAM pada PC pengguna.

Namun, perhatikan bahwa sebagian besar klien OLAP menyediakan komputasi terdistribusi. Oleh karena itu, jumlah rekaman yang diproses, yang membatasi kerja alat OLAP klien, dipahami bukan sebagai volume data primer dalam database perusahaan, namun sebagai ukuran sampel agregat darinya. Klien OLAP menghasilkan permintaan ke DBMS, yang menjelaskan kondisi penyaringan dan algoritma untuk pengelompokan awal data primer. Server menemukan, mengelompokkan catatan, dan mengembalikan pilihan ringkas untuk penghitungan OLAP lebih lanjut. Ukuran sampel ini bisa puluhan atau ratusan kali lebih kecil dibandingkan volume catatan primer dan non-agregat. Akibatnya, kebutuhan akan klien OLAP pada sumber daya PC berkurang secara signifikan.

Selain itu, banyaknya dimensi tunduk pada keterbatasan persepsi manusia. Diketahui rata-rata orang bisa mengoperasikan 3-4 secara bersamaan, maksimal 8 dimensi. Dengan jumlah dimensi yang lebih besar dalam tabel dinamis, persepsi informasi menjadi jauh lebih sulit. Faktor ini harus diperhitungkan saat menghitung awal RAM yang mungkin dibutuhkan oleh klien OLAP.

Panjang dimensi juga mempengaruhi ukuran ruang alamat mesin OLAP saat menghitung kubus OLAP. Semakin panjang dimensinya, semakin banyak sumber daya yang dibutuhkan untuk mengurutkan array multidimensi, dan sebaliknya. Hanya pengukuran singkat dalam data sumber yang merupakan argumen lain yang mendukung klien OLAP.

Karakteristik ini ditentukan oleh dua faktor yang dibahas di atas: volume data yang diproses dan kekuatan komputer. Ketika jumlah, misalnya, dimensi meningkat, kinerja semua alat OLAP menurun karena peningkatan jumlah agregat yang signifikan, namun tingkat penurunannya berbeda. Mari kita tunjukkan ketergantungan ini pada grafik.

Skema 1. Ketergantungan kinerja alat OLAP klien dan server pada peningkatan volume data

Karakteristik kecepatan server OLAP kurang sensitif terhadap pertumbuhan data. Hal ini dijelaskan oleh teknologi berbeda untuk memproses permintaan pengguna oleh server OLAP dan klien OLAP. Misalnya, selama operasi penelusuran, server OLAP mengakses data yang disimpan dan “menarik” data dari “cabang” ini. Klien OLAP menghitung seluruh kumpulan agregat pada saat pemuatan. Namun, hingga jumlah data tertentu, kinerja alat server dan klien sebanding. Untuk klien OLAP yang mendukung komputasi terdistribusi, cakupan perbandingan kinerja dapat diperluas ke volume data yang mencakup kebutuhan analisis OLAP dari sejumlah besar pengguna. Hal ini dibuktikan dengan hasil pengujian internal MS OLAP Server dan klien OLAP "Kontur Standard". Pengujian dilakukan pada IBM PC Pentium Celeron 400 MHz, 256 Mb untuk sampel 1 juta catatan unik (yaitu gabungan) dengan 7 dimensi yang berisi 10 hingga 70 anggota. Waktu pemuatan kubus dalam kedua kasus tidak melebihi 1 detik, dan berbagai operasi OLAP (menelusuri, menelusuri, memindahkan, memfilter, dll.) diselesaikan dalam seperseratus detik.

Ketika ukuran sampel melebihi jumlah RAM, pertukaran dengan disk dimulai dan kinerja klien OLAP turun tajam. Hanya mulai saat ini kita dapat berbicara tentang keunggulan server OLAP.

Harus diingat bahwa “titik puncaknya” menentukan batas kenaikan tajam dalam biaya solusi OLAP. Untuk tugas setiap pengguna tertentu, poin ini mudah ditentukan melalui tes kinerja klien OLAP. Tes semacam itu dapat diperoleh dari perusahaan pengembang.

Selain itu, biaya solusi server OLAP meningkat seiring dengan bertambahnya jumlah pengguna. Faktanya adalah server OLAP melakukan penghitungan untuk semua pengguna di satu komputer. Oleh karena itu, semakin besar jumlah pengguna, semakin besar pula RAM dan daya pemrosesan. Jadi, jika volume data yang diproses berada dalam kisaran kinerja yang sebanding antara sistem server dan klien, maka, jika hal-hal lain dianggap sama, penggunaan klien OLAP akan lebih menguntungkan.

Menggunakan server OLAP dalam ideologi “klasik” melibatkan pengunggahan data DBMS relasional ke dalam database multidimensi. Pengunggahan dilakukan selama jangka waktu tertentu, sehingga data server OLAP tidak mencerminkan keadaan saat ini. Hanya server OLAP yang mendukung mode operasi ROLAP yang bebas dari kelemahan ini.

Demikian pula, sejumlah klien OLAP memungkinkan Anda mengimplementasikan arsitektur ROLAP dan Desktop dengan akses langsung ke database. Hal ini memastikan analisis data sumber secara online.

Server OLAP hadir persyaratan minimal dengan kekuatan terminal klien. Secara obyektif, persyaratan klien OLAP lebih tinggi, karena... ia melakukan perhitungan di RAM PC pengguna. Keadaan armada perangkat keras organisasi tertentu merupakan indikator terpenting yang harus diperhitungkan saat memilih alat OLAP. Namun ada juga “pro” dan “kontra” di sini. Server OLAP tidak menggunakan kekuatan komputasi yang sangat besar seperti komputer pribadi modern. Jika suatu organisasi sudah memiliki armada PC modern, tidak efektif jika menggunakannya hanya sebagai terminal tampilan dan pada saat yang sama menimbulkan biaya tambahan untuk server pusat.

Jika kekuatan komputer pengguna "tidak sesuai harapan", klien OLAP akan bekerja lambat atau tidak dapat bekerja sama sekali. Membeli satu server yang kuat mungkin lebih murah daripada mengupgrade semua PC Anda.

Di sini berguna untuk mempertimbangkan tren dalam pengembangan perangkat keras. Karena jumlah data untuk analisis hampir konstan, peningkatan daya PC yang stabil akan menyebabkan perluasan kemampuan klien OLAP dan perpindahan server OLAP ke dalam segmen database yang sangat besar.

Saat menggunakan server OLAP melalui jaringan, hanya data yang akan ditampilkan yang ditransfer ke PC klien, sedangkan klien OLAP menerima seluruh volume data primer.

Oleh karena itu, jika klien OLAP digunakan, lalu lintas jaringan akan lebih tinggi.

Namun, saat menggunakan server OLAP, operasi pengguna, misalnya, merinci, menghasilkan kueri baru ke database multidimensi, dan, akibatnya, transfer data baru. Eksekusi operasi OLAP oleh klien OLAP dilakukan dalam RAM dan, karenanya, tidak menyebabkan aliran data baru di jaringan.

Perlu juga dicatat bahwa perangkat keras jaringan modern menyediakan level tinggi lebar pita.

Oleh karena itu, dalam sebagian besar kasus, menganalisis database berukuran “sedang” menggunakan klien OLAP tidak akan memperlambat pekerjaan pengguna.

Biaya server OLAP cukup tinggi. Hal ini juga harus mencakup biaya komputer khusus dan biaya berkelanjutan untuk pengelolaan database multidimensi. Selain itu, implementasi dan pemeliharaan server OLAP memerlukan personel yang berkualifikasi tinggi.

Biaya klien OLAP jauh lebih rendah daripada biaya server OLAP. Administrasi dan tambahan peralatan teknis tidak diperlukan server. Tidak ada persyaratan tinggi untuk kualifikasi personel saat mengimplementasikan klien OLAP. Klien OLAP dapat diimplementasikan lebih cepat daripada server OLAP.

Pengembangan aplikasi analitik menggunakan alat OLAP klien merupakan proses yang cepat dan tidak memerlukan pelatihan khusus. Seorang pengguna yang mengetahui implementasi fisik database dapat mengembangkan aplikasi analitis secara mandiri, tanpa keterlibatan spesialis IT. Saat menggunakan server OLAP, Anda perlu mempelajari 2 sistem yang berbeda, terkadang dari vendor berbeda, - untuk membuat kubus di server, dan untuk mengembangkan aplikasi klien. Klien OLAP menyediakan antarmuka visual tunggal untuk mendeskripsikan kubus dan menyiapkan antarmuka pengguna untuk kubus tersebut.

Mari kita telusuri proses pembuatan aplikasi OLAP menggunakan alat klien.

Diagram 2. Membuat aplikasi OLAP menggunakan alat klien ROLAP

Prinsip operasi klien ROLAP adalah deskripsi awal dari lapisan semantik, di belakangnya tersembunyi struktur fisik data sumber. Dalam hal ini, sumber data dapat berupa: tabel lokal, RDBMS. Daftar sumber data yang didukung ditentukan oleh produk perangkat lunak tertentu. Setelah ini, pengguna dapat secara mandiri memanipulasi objek yang dia pahami dalam kaitannya dengan area subjek untuk membuat kubus dan antarmuka analitis.

Prinsip pengoperasian klien server OLAP berbeda. Di server OLAP, saat membuat kubus, pengguna memanipulasi deskripsi fisik database.

Pada saat yang sama, deskripsi khusus dibuat di kubus itu sendiri. Klien server OLAP dikonfigurasi hanya untuk kubus.

Mari kita jelaskan prinsip pengoperasian klien ROLAP menggunakan contoh pembuatan laporan penjualan dinamis (lihat Diagram 2). Biarkan data awal untuk analisis disimpan dalam dua tabel: Penjualan dan Transaksi.

Saat membuat lapisan semantik, sumber data - tabel Penjualan dan Penawaran - dijelaskan dalam istilah yang dapat dipahami oleh pengguna akhir dan diubah menjadi “Produk” dan “Penawaran”. Bidang "ID" dari tabel "Produk" diubah namanya menjadi "Kode", dan "Nama" menjadi "Produk", dll.

Kemudian objek bisnis Penjualan dibuat. Objek bisnis adalah meja datar yang menjadi dasar pembentukan kubus multidimensi. Saat membuat objek bisnis, tabel "Produk" dan "Transaksi" digabungkan berdasarkan bidang "Kode" produk. Karena semua bidang tabel tidak diperlukan untuk ditampilkan dalam laporan, objek bisnis hanya menggunakan bidang “Item”, “Tanggal” dan “Jumlah”.

Selanjutnya, laporan OLAP dibuat berdasarkan objek bisnis. Pengguna memilih objek bisnis dan menyeret atributnya ke area kolom atau baris tabel laporan. Dalam contoh kita, berdasarkan objek bisnis “Penjualan”, laporan penjualan produk berdasarkan bulan telah dibuat.

Saat bekerja dengan laporan interaktif, pengguna dapat mengatur kondisi pemfilteran dan pengelompokan dengan gerakan mouse sederhana yang sama. Pada titik ini, klien ROLAP mengakses data dalam cache. Klien server OLAP menghasilkan kueri baru ke database multidimensi. Misalnya dengan menerapkan filter berdasarkan produk pada laporan penjualan, Anda bisa mendapatkan laporan penjualan produk yang kami minati.

Semua pengaturan aplikasi OLAP dapat disimpan dalam repositori metadata khusus, dalam aplikasi, atau dalam repositori sistem database multidimensi. Implementasinya tergantung pada produk perangkat lunak tertentu.

Jadi, dalam kasus apa penggunaan klien OLAP bisa lebih efektif dan menguntungkan bagi pengguna dibandingkan menggunakan server OLAP?

Kelayakan ekonomi menggunakan server OLAP muncul ketika volume data sangat besar dan melimpah untuk klien OLAP, jika tidak, penggunaan server OLAP lebih dibenarkan. Dalam hal ini, klien OLAP menggabungkan karakteristik kinerja tinggi dan biaya rendah.

PC yang kuat untuk analis adalah argumen lain yang mendukung klien OLAP. Saat menggunakan server OLAP, kapasitas ini tidak digunakan. Di antara kelebihan klien OLAP adalah sebagai berikut:

Biaya implementasi dan pemeliharaan klien OLAP jauh lebih rendah dibandingkan biaya server OLAP.

Saat menggunakan klien OLAP dengan mesin tertanam, data ditransfer melalui jaringan satu kali. Saat melakukan operasi OLAP, tidak ada aliran data baru yang dihasilkan.

Menyiapkan klien ROLAP disederhanakan dengan menghilangkan langkah perantara - membuat database multidimensi.

3. Sistem inti OLAP

3.1 Prinsip desain

data inti klien aplikasi

Dari uraian di atas terlihat jelas bahwa mekanisme OLAP merupakan salah satu metode analisis data yang populer saat ini. Ada dua pendekatan utama untuk memecahkan masalah ini. Yang pertama disebut Multidimensional OLAP (MOLAP) - implementasi mekanisme menggunakan database multidimensi di sisi server, dan yang kedua Relational OLAP (ROLAP) - membangun kubus dengan cepat berdasarkan Kueri SQL ke DBMS relasional. Masing-masing pendekatan ini mempunyai pro dan kontra. Analisis komparatif mereka berada di luar cakupan pekerjaan ini. Hanya implementasi inti dari modul ROLAP desktop yang akan dijelaskan di sini.

Tugas ini muncul setelah menggunakan sistem ROLAP yang dibangun berdasarkan komponen Decision Cube yang disertakan dalam Borland Delphi. Sayangnya, penggunaan kumpulan komponen ini menunjukkan kinerja yang buruk pada data dalam jumlah besar. Masalah ini dapat diatasi dengan mencoba memotong data sebanyak mungkin sebelum memasukkannya ke dalam kubus. Tapi ini tidak selalu cukup.

Anda dapat menemukan banyak informasi tentang sistem OLAP di Internet dan media, tetapi hampir tidak ada yang disebutkan tentang cara kerjanya di dalamnya.

Skema kerja:

Skema umum pengoperasian sistem OLAP desktop dapat direpresentasikan sebagai berikut:

Diagram 3. Pengoperasian sistem OLAP desktop

Algoritma operasinya adalah sebagai berikut:

1. Memperoleh data berupa tabel datar atau hasil eksekusi query SQL.

2.Caching data dan mengubahnya menjadi kubus multidimensi.

3.Menampilkan kubus yang dibangun menggunakan tab silang atau bagan, dll. Secara umum, sejumlah tampilan dapat dihubungkan ke satu kubus.

Mari kita pertimbangkan bagaimana sistem seperti itu dapat diatur secara internal. Kita akan memulainya dari sisi yang bisa dilihat dan disentuh, yakni dari tampilannya. Tampilan yang digunakan dalam sistem OLAP paling sering hadir dalam dua jenis - tab silang dan bagan. Mari kita lihat tab silang, yang merupakan cara dasar dan paling umum untuk menampilkan kubus.

Pada gambar di bawah, baris dan kolom yang berisi hasil agregat ditampilkan dengan warna kuning, sel yang berisi fakta berwarna abu-abu terang, dan sel yang berisi data dimensi berwarna abu-abu gelap.

Dengan demikian, tabel dapat dibagi menjadi beberapa elemen berikut, yang akan kita kerjakan di masa mendatang:

Saat mengisi matriks dengan fakta, kita harus melakukan hal berikut:

Berdasarkan data pengukuran, tentukan koordinat elemen yang akan ditambahkan ke dalam matriks.

Tentukan koordinat kolom dan baris jumlah yang dipengaruhi oleh penambahan elemen.

Tambahkan elemen ke matriks dan total kolom dan baris yang sesuai.

Perlu dicatat bahwa matriks yang dihasilkan akan sangat jarang, itulah sebabnya pengorganisasiannya dalam bentuk array dua dimensi (opsi yang terletak di permukaan) tidak hanya tidak rasional, tetapi, kemungkinan besar, tidak mungkin karena besarnya dimensi matriks ini, untuk penyimpanan yang tidak ada Jumlah RAM yang cukup. Misalnya, jika kubus kita berisi informasi penjualan selama satu tahun, dan hanya memiliki 3 dimensi - Pelanggan (250), Produk (500) dan Tanggal (365), maka kita akan mendapatkan matriks fakta dengan dimensi berikut: nomor elemen = 250 x 500 x 365 = 45.625.000. Meskipun faktanya mungkin hanya ada beberapa ribu elemen terisi dalam matriks. Selain itu, semakin besar jumlah dimensinya, maka matriksnya akan semakin renggang.

Oleh karena itu, untuk bekerja dengan matriks ini, Anda perlu menggunakan mekanisme khusus untuk bekerja dengan matriks renggang. Berbagai pilihan untuk mengatur matriks renggang dimungkinkan. Mereka dijelaskan dengan cukup baik dalam literatur pemrograman, misalnya, dalam volume pertama buku klasik "The Art of Programming" oleh Donald Knuth.

Sekarang mari kita perhatikan bagaimana kita dapat menentukan koordinat suatu fakta, dengan mengetahui dimensi yang bersesuaian dengannya. Untuk melakukan ini, mari kita lihat lebih dekat struktur header:

Dalam hal ini, Anda dapat dengan mudah menemukan cara untuk menentukan jumlah sel yang bersangkutan dan jumlah totalnya. Beberapa pendekatan dapat diusulkan di sini. Salah satunya adalah dengan menggunakan pohon untuk menemukan sel yang cocok. Pohon ini dapat dibangun dengan melintasi pilihan. Selain itu, rumus perulangan analitik dapat dengan mudah ditentukan untuk menghitung koordinat yang diperlukan.

Data yang disimpan dalam tabel perlu diubah agar dapat digunakan. Oleh karena itu, untuk meningkatkan kinerja saat membuat hypercube, sebaiknya temukan elemen unik yang disimpan dalam kolom yang berdimensi kubus. Selain itu, Anda dapat melakukan agregasi awal fakta untuk rekaman yang memiliki nilai dimensi yang sama. Seperti disebutkan di atas, nilai unik yang tersedia di bidang pengukuran penting bagi kami. Kemudian struktur berikut dapat diusulkan untuk menyimpannya:

Skema 4. Struktur untuk menyimpan nilai unik

Dengan menggunakan struktur ini, kami mengurangi kebutuhan memori secara signifikan. Yang cukup relevan, karena... Untuk meningkatkan kecepatan pengoperasian, disarankan untuk menyimpan data dalam RAM. Selain itu, Anda hanya dapat menyimpan array elemen, dan membuang nilainya ke disk, karena kita hanya memerlukannya saat menampilkan tab silang.

Ide-ide yang dijelaskan di atas menjadi dasar pembuatan pustaka komponen CubeBase.

Diagram 5. Struktur pustaka komponen CubeBase

TСubeSource melakukan caching dan konversi data ke dalam format internal, serta agregasi data awal. Komponen TCubeEngine melakukan perhitungan dan operasi hypercube dengannya. Faktanya, ini adalah mesin OLAP yang mengubah tabel datar menjadi kumpulan data multidimensi. Komponen TCubeGrid menampilkan tab silang dan mengontrol tampilan hypercube. TСubeChart memungkinkan Anda melihat hypercube dalam bentuk grafik, dan komponen TСubePivote mengontrol pengoperasian inti kubus.

Jadi, saya melihat arsitektur dan interaksi komponen yang dapat digunakan untuk membangun mesin OLAP. Sekarang mari kita lihat lebih dekat struktur internal komponennya.

Tahap pertama dari sistem adalah memuat data dan mengubahnya menjadi format internal. Pertanyaan logisnya adalah: mengapa hal ini perlu, karena Anda cukup menggunakan data dari tabel datar, melihatnya saat membuat potongan kubus. Untuk menjawab pertanyaan ini, mari kita lihat struktur tabel dari sudut pandang mesin OLAP. Untuk sistem OLAP, kolom tabel dapat berupa fakta atau dimensi. Namun, logika untuk bekerja dengan kolom-kolom ini akan berbeda. Dalam hypercube, dimensi sebenarnya adalah sumbu, dan nilai dimensi adalah koordinat pada sumbu tersebut. Dalam hal ini, kubus akan terisi sangat tidak merata - akan ada kombinasi koordinat yang tidak sesuai dengan catatan mana pun dan akan ada kombinasi yang sesuai dengan beberapa catatan di tabel asli, dan situasi pertama lebih umum, yaitu , kubus akan mirip dengan alam semesta - ruang kosong, di beberapa tempat terdapat gugusan titik (fakta). Jadi, jika kita melakukan praagregasi data selama pemuatan data awal, yaitu menggabungkan catatan yang memiliki nilai pengukuran yang sama, sambil menghitung nilai fakta gabungan awal, maka di masa mendatang kita harus bekerja dengan lebih sedikit catatan, yang akan meningkatkan kecepatan kerja dan mengurangi kebutuhan jumlah RAM.

Untuk membuat irisan hypercube, kita memerlukan kemampuan berikut - menentukan koordinat (nilai pengukuran sebenarnya) untuk catatan tabel, serta menentukan catatan yang memiliki koordinat tertentu (nilai pengukuran). Mari kita pertimbangkan bagaimana kemungkinan-kemungkinan ini dapat diwujudkan. Cara termudah untuk menyimpan hypercube adalah dengan menggunakan database dengan format internalnya sendiri.

Secara skematis, transformasi dapat direpresentasikan sebagai berikut:

Gambar 6: Mengonversi Database Format Internal ke Database yang Dinormalisasi

Artinya, alih-alih satu tabel, kami mendapat database yang dinormalisasi. Faktanya, normalisasi mengurangi kecepatan sistem, mungkin dikatakan oleh spesialis database, dan dalam hal ini mereka pasti benar, ketika kita perlu mendapatkan nilai untuk elemen kamus (dalam kasus kita, nilai pengukuran). Namun masalahnya adalah kita tidak membutuhkan nilai-nilai ini sama sekali pada tahap pembuatan irisan. Seperti disebutkan di atas, kami hanya tertarik pada koordinat di hypercube kami, jadi kami akan menentukan koordinat untuk nilai pengukuran. Hal termudah untuk dilakukan adalah memberi nomor ulang pada nilai elemen. Agar penomorannya tidak ambigu dalam satu dimensi, pertama-tama kita mengurutkan daftar nilai dimensi (kamus, dalam istilah database) berdasarkan abjad. Selain itu, kami akan menomori ulang fakta-faktanya, dan fakta-fakta tersebut telah dikumpulkan sebelumnya. Kami mendapatkan diagram berikut:

Skema 7. Penomoran ulang database yang dinormalisasi untuk menentukan koordinat nilai pengukuran

Sekarang yang tersisa hanyalah menghubungkan elemen-elemen tabel yang berbeda satu sama lain. Dalam teori database relasional, hal ini dilakukan dengan menggunakan tabel perantara khusus. Kita cukup mengasosiasikan setiap entri dalam tabel pengukuran dengan sebuah daftar, yang unsur-unsurnya akan berupa banyaknya fakta yang menjadi dasar pengukuran tersebut digunakan (yaitu, untuk menentukan semua fakta yang mempunyai nilai yang sama). koordinat yang dijelaskan oleh pengukuran ini). Faktanya, setiap record akan dicocokkan dengan nilai koordinat di mana ia berada di hypercube. Di masa depan, koordinat record dalam hypercube akan dipahami sebagai jumlah record yang sesuai dalam tabel nilai pengukuran. Kemudian untuk contoh hipotetis kita mendapatkan himpunan berikut yang mendefinisikan representasi internal hypercube:

Diagram 8. Representasi internal hypercube

Ini akan menjadi representasi internal hypercube kami. Karena kami tidak membuatnya untuk database relasional, kami cukup menggunakan bidang dengan panjang variabel sebagai bidang untuk menghubungkan nilai pengukuran (kami tidak akan dapat melakukan ini di RDB, karena jumlah kolom tabel sudah ditentukan sebelumnya di sana).

Kita dapat mencoba menggunakan sekumpulan tabel sementara untuk mengimplementasikan hypercube, tetapi metode ini akan memberikan kinerja yang terlalu rendah (misalnya, sekumpulan komponen Decision Cube), jadi kita akan menggunakan struktur penyimpanan data kita sendiri.

Untuk mengimplementasikan hypercube, kita perlu menggunakan struktur data yang akan memastikan performa maksimal dan konsumsi RAM minimal. Jelasnya, struktur utama kami adalah untuk menyimpan kamus dan tabel fakta. Mari kita lihat tugas yang harus dilakukan kamus dengan kecepatan maksimum:

memeriksa keberadaan suatu elemen dalam kamus;

menambahkan elemen ke kamus;

mencari nomor rekaman yang mempunyai nilai koordinat tertentu;

mencari koordinat berdasarkan nilai pengukuran;

mencari nilai pengukuran berdasarkan koordinatnya.

Berbagai tipe dan struktur data dapat digunakan untuk mengimplementasikan persyaratan ini. Misalnya, Anda dapat menggunakan array struktur. Dalam kasus nyata, array ini memerlukan mekanisme pengindeksan tambahan yang akan meningkatkan kecepatan memuat data dan mengambil informasi.

Untuk mengoptimalkan pengoperasian hypercube, perlu ditentukan tugas mana yang perlu diselesaikan sebagai prioritas, dan dengan kriteria apa kita perlu meningkatkan kualitas pekerjaan. Hal utama bagi kami adalah meningkatkan kecepatan program, sementara jumlah RAM yang dibutuhkan tidak terlalu besar. Peningkatan kinerja dimungkinkan melalui pengenalan mekanisme tambahan untuk mengakses data, misalnya pengenalan pengindeksan. Sayangnya, hal ini meningkatkan overhead RAM. Oleh karena itu, kami akan menentukan operasi mana yang perlu kami lakukan dengan kecepatan tertinggi. Untuk melakukan ini, pertimbangkan masing-masing komponen yang mengimplementasikan hypercube. Komponen ini memiliki dua tipe utama - tabel dimensi dan fakta. Untuk pengukuran, tugas umumnya adalah:

menambahkan nilai baru;

penentuan koordinat berdasarkan nilai pengukuran;

penentuan nilai berdasarkan koordinat.

Saat menambahkan nilai elemen baru, kita perlu memeriksa apakah kita sudah memiliki nilai tersebut, dan jika demikian, jangan menambahkan yang baru, tetapi gunakan koordinat yang ada, jika tidak kita perlu menambahkan elemen baru dan menentukan koordinatnya. Untuk melakukan ini, Anda memerlukan cara untuk dengan cepat menemukan keberadaan elemen yang diinginkan (selain itu, masalah seperti itu muncul ketika menentukan koordinat berdasarkan nilai elemen). Untuk tujuan ini, optimal menggunakan hashing. Dalam hal ini, struktur optimalnya adalah menggunakan pohon hash di mana kita akan menyimpan referensi ke elemen. Dalam hal ini, elemennya akan menjadi garis kamus dimensi. Maka struktur nilai pengukurannya dapat direpresentasikan sebagai berikut:

PFactLink = ^TFactLink;

TFactLink = catatan

FaktaTidak: bilangan bulat; // indeks fakta dalam tabel

TDimensionRecord = catatan

Nilai: tali; // nilai pengukuran

Indeks: bilangan bulat; // nilai koordinat

Tautan Fakta: Tautan Fakta; // penunjuk ke awal daftar elemen tabel fakta

Dan di pohon hash kami akan menyimpan tautan ke elemen unik. Selain itu, kita perlu menyelesaikan masalah transformasi terbalik - menggunakan koordinat untuk menentukan nilai pengukuran. Untuk memastikan kinerja maksimal, pengalamatan langsung harus digunakan. Oleh karena itu, Anda dapat menggunakan larik lain, yang indeksnya adalah koordinat dimensi, dan nilainya adalah tautan ke entri terkait dalam kamus. Namun, Anda dapat melakukannya dengan lebih mudah (dan menghemat memori) jika Anda mengatur susunan elemen sedemikian rupa sehingga indeks elemen tersebut adalah koordinatnya.

Pengorganisasian array yang mengimplementasikan daftar fakta tidak menimbulkan masalah khusus karena strukturnya yang sederhana. Satu-satunya catatan adalah disarankan untuk menghitung semua metode agregasi yang mungkin diperlukan dan yang dapat dihitung secara bertahap (misalnya, jumlah).

Jadi, kami telah menjelaskan metode untuk menyimpan data dalam bentuk hypercube. Ini memungkinkan Anda menghasilkan sekumpulan titik dalam ruang multidimensi berdasarkan informasi yang terletak di gudang data. Agar seseorang dapat bekerja dengan data ini, data tersebut harus disajikan dalam bentuk yang nyaman untuk diproses. Dalam hal ini, tabel pivot dan grafik digunakan sebagai jenis utama penyajian data. Terlebih lagi, kedua metode ini sebenarnya merupakan proyeksi dari sebuah hypercube. Untuk memastikan efisiensi maksimum saat membangun representasi, kita akan mulai dari apa yang diwakili oleh proyeksi tersebut. Mari kita mulai dengan tabel pivot, sebagai tabel terpenting untuk analisis data.

Mari temukan cara untuk menerapkan struktur seperti itu. Ada tiga bagian yang membentuk tabel pivot: header baris, header kolom, dan tabel aktual nilai fakta gabungan. Yang paling dengan cara yang sederhana Tampilan tabel fakta akan menggunakan array dua dimensi, yang dimensinya dapat ditentukan dengan membuat header. Sayangnya, metode yang paling sederhana akan menjadi yang paling tidak efisien, karena tabel akan sangat jarang, dan memori akan digunakan dengan sangat tidak efisien, akibatnya hanya mungkin untuk membuat kubus yang sangat kecil, karena jika tidak, mungkin tidak akan cukup. Penyimpanan. Oleh karena itu, kita perlu memilih struktur data untuk menyimpan informasi yang akan menjamin kecepatan maksimum pencarian/penambahan elemen baru dan pada saat yang sama konsumsi RAM minimum. Struktur ini akan disebut matriks renggang, yang dapat Anda baca lebih detail dari Knuth. Ada berbagai cara untuk mengatur matriks. Untuk memilih opsi yang sesuai dengan kita, pertama-tama kita akan mempertimbangkan struktur header tabel.

Judul memiliki struktur hierarki yang jelas, jadi wajar jika diasumsikan menggunakan pohon untuk menyimpannya. Dalam hal ini, struktur simpul pohon dapat digambarkan secara skematis sebagai berikut:

Lampiran C

Dalam hal ini, logis untuk menyimpan tautan ke elemen yang sesuai dari tabel dimensi kubus multidimensi sebagai nilai dimensi. Ini akan mengurangi biaya memori untuk menyimpan irisan dan mempercepat pekerjaan. Tautan juga digunakan sebagai node induk dan anak.

Untuk menambahkan elemen ke pohon, Anda harus memiliki informasi tentang lokasinya di hypercube. Sebagai informasi tersebut, Anda perlu menggunakan koordinatnya, yang disimpan dalam kamus besaran pengukuran. Mari kita lihat skema untuk menambahkan elemen ke pohon header tabel pivot. Dalam hal ini kami menggunakan nilai koordinat pengukuran sebagai informasi awal. Urutan pencantuman dimensi ini ditentukan oleh metode agregasi yang diinginkan dan cocok dengan tingkat hierarki pohon header. Sebagai hasil dari pekerjaan tersebut, Anda perlu mendapatkan daftar kolom atau baris tabel pivot yang perlu Anda tambahkan elemennya.

AplikasiD

Kami menggunakan koordinat pengukuran sebagai data awal untuk menentukan struktur ini. Selain itu, untuk lebih pastinya, kita akan berasumsi bahwa kita sedang mendefinisikan kolom yang kita minati dalam matriks (kita akan membahas cara mendefinisikan sebuah baris nanti, karena akan lebih mudah menggunakan struktur data lain di sana; alasan untuk pilihan ini juga lihat di bawah). Sebagai koordinat, kita mengambil bilangan bulat – bilangan nilai pengukuran yang dapat ditentukan seperti dijelaskan di atas.

Jadi, setelah melakukan prosedur ini, kita akan mendapatkan array referensi ke kolom matriks renggang. Sekarang Anda perlu melakukan semua tindakan yang diperlukan dengan string. Untuk melakukan ini, Anda perlu menemukan elemen yang diperlukan di dalam setiap kolom dan menambahkan nilai yang sesuai di sana. Untuk setiap dimensi dalam koleksi, Anda perlu mengetahui jumlah nilai unik dan kumpulan nilai sebenarnya.

Sekarang mari kita lihat bentuk di mana nilai-nilai di dalam kolom perlu direpresentasikan - yaitu, cara menentukan baris yang diperlukan. Ada beberapa pendekatan yang dapat Anda gunakan untuk mencapai hal ini. Cara paling sederhana adalah dengan merepresentasikan setiap kolom sebagai vektor, namun karena kolom tersebut sangat jarang, memori akan digunakan dengan sangat tidak efisien. Untuk menghindari hal ini, kita akan menggunakan struktur data yang akan memberikan efisiensi lebih besar dalam merepresentasikan array satu dimensi (vektor) yang jarang. Yang paling sederhana adalah daftar biasa, tertaut tunggal atau ganda, namun tidak ekonomis dari sudut pandang pengaksesan elemen. Oleh karena itu, kami akan menggunakan pohon, yang akan memberikan akses lebih cepat ke elemen.

Misalnya, Anda dapat menggunakan pohon yang sama persis dengan kolom, namun kemudian Anda harus membuat pohon sendiri untuk setiap kolom, yang akan menyebabkan overhead memori dan waktu pemrosesan yang signifikan. Mari kita melakukannya sedikit lebih cerdik - kita akan membuat satu pohon untuk menyimpan semua kombinasi dimensi yang digunakan dalam string, yang akan identik dengan yang dijelaskan di atas, namun elemen-elemennya tidak akan menjadi penunjuk ke string (yang tidak ada seperti itu ), tetapi indeksnya, dan nilai indeks itu sendiri tidak menarik bagi kami dan hanya digunakan sebagai kunci unik. Kami kemudian akan menggunakan kunci ini untuk menemukan elemen yang diinginkan dalam kolom. Kolomnya sendiri paling mudah direpresentasikan sebagai pohon biner biasa. Secara grafis, struktur yang dihasilkan dapat direpresentasikan sebagai berikut:

Diagram 9. Gambar tabel pivot sebagai pohon biner

Anda dapat menggunakan prosedur yang sama seperti prosedur yang dijelaskan di atas untuk menentukan kolom tabel pivot guna menentukan nomor baris yang sesuai. Dalam hal ini, nomor baris bersifat unik dalam satu tabel pivot dan mengidentifikasi elemen dalam vektor yang merupakan kolom tabel pivot. Pilihan paling sederhana untuk menghasilkan angka-angka ini adalah dengan mempertahankan penghitung dan menambahnya sebanyak satu saat menambahkan elemen baru ke pohon header baris. Vektor kolom ini sendiri paling mudah disimpan sebagai pohon biner, dimana nilai nomor baris digunakan sebagai kuncinya. Selain itu, dimungkinkan juga untuk menggunakan tabel hash. Karena prosedur untuk bekerja dengan pohon-pohon ini dibahas secara rinci di sumber lain, kami tidak akan membahas hal ini dan akan mempertimbangkan skema umum untuk menambahkan elemen ke kolom.

Secara umum urutan tindakan penambahan elemen pada matriks dapat digambarkan sebagai berikut:

1. Tentukan nomor baris yang unsurnya ditambahkan

2.Tentukan sekumpulan kolom yang elemennya akan ditambahkan

3. Untuk semua kolom, temukan elemen dengan nomor baris yang diperlukan dan tambahkan elemen saat ini ke dalamnya (penambahan mencakup menghubungkan jumlah nilai fakta yang diperlukan dan menghitung nilai agregat, yang dapat ditentukan secara bertahap).

Setelah menjalankan algoritma ini, kita akan mendapatkan sebuah matriks, yaitu tabel ringkasan yang perlu kita buat.

Sekarang beberapa kata tentang pemfilteran saat membuat irisan. Cara termudah untuk melakukan ini adalah pada tahap pembuatan matriks, karena pada tahap ini ada akses ke semua bidang yang diperlukan, dan, sebagai tambahan, nilai dikumpulkan. Dalam hal ini, ketika mengambil entri dari cache, kepatuhannya terhadap kondisi pemfilteran diperiksa, dan jika tidak terpenuhi, entri tersebut akan dibuang.

Karena struktur yang dijelaskan di atas sepenuhnya menggambarkan tabel pivot, tugas memvisualisasikannya akan menjadi hal yang sepele. Dalam hal ini, Anda dapat menggunakan komponen tabel standar yang tersedia di hampir semua alat pemrograman untuk Windows.

Produk pertama yang melakukan kueri OLAP adalah Express (IRI). Namun, istilah OLAP sendiri diciptakan oleh Edgar Codd, “bapak database relasional.” Dan pekerjaan Codd didanai oleh Arbor, sebuah perusahaan yang telah merilis produk OLAP miliknya sendiri, Essbase (kemudian diakuisisi oleh Hyperion, yang diakuisisi oleh Oracle pada tahun 2007) pada tahun sebelumnya. Produk OLAP terkenal lainnya termasuk Layanan Analisis Microsoft (sebelumnya disebut Layanan OLAP, bagian dari SQL Server), Oracle OLAP Option, Server DB2 OLAP IBM (pada dasarnya EssBase dengan tambahan dari IBM), SAP BW, produk Brio, BusinessObjects, Cognos, MicroStrategy dan produsen lainnya.

Dari segi teknis, produk yang ada di pasaran dibagi menjadi “OLAP fisik” dan “virtual”. Dalam kasus pertama, ada program yang melakukan penghitungan awal agregat, yang kemudian disimpan dalam database multidimensi khusus yang menyediakan pengambilan cepat. Contoh produk tersebut adalah Microsoft Analysis Services, Oracle OLAP Option, Oracle/Hyperion EssBase, Cognos PowerPlay. Dalam kasus kedua, data disimpan dalam DBMS relasional, dan agregat mungkin tidak ada sama sekali atau mungkin dibuat berdasarkan permintaan pertama di DBMS atau cache perangkat lunak analitis. Contoh produk tersebut adalah SAP BW, BusinessObjects, Microstrategy. Sistem yang didasarkan pada “OLAP fisik” secara konsisten memberikan waktu respons yang lebih baik terhadap pertanyaan dibandingkan sistem “OLAP virtual”. Vendor OLAP virtual mengklaim skalabilitas yang lebih besar pada produk mereka untuk mendukung volume data yang sangat besar.

Dalam karya ini, saya ingin melihat lebih dekat produk BaseGroup Labs - Deductor.

Deduktor adalah platform analitik, mis. dasar untuk menciptakan solusi aplikasi yang lengkap. Teknologi yang diterapkan di Deductor memungkinkan Anda melewati semua tahapan membangun sistem analitik berdasarkan satu arsitektur: mulai dari membuat gudang data hingga memilih model secara otomatis dan memvisualisasikan hasil yang diperoleh.

Komposisi sistem:

Deductor Studio adalah inti analitis dari platform Deductor. Deductor Studio menyertakan serangkaian mekanisme lengkap yang memungkinkan Anda memperoleh informasi dari sumber data arbitrer, melakukan seluruh siklus pemrosesan (pembersihan, transformasi data, pembuatan model), menampilkan hasil dengan cara yang paling nyaman (OLAP, tabel, bagan , pohon keputusan...) dan mengekspor hasil.

Deductor Viewer adalah stasiun kerja pengguna akhir. Program ini memungkinkan Anda meminimalkan persyaratan personel, karena semua operasi yang diperlukan dilakukan secara otomatis menggunakan skrip pemrosesan yang telah disiapkan sebelumnya; tidak perlu memikirkan metode memperoleh data dan mekanisme pemrosesannya. Pengguna Dedustor Viewer hanya perlu memilih laporan yang diinginkan.

Gudang Deduktor adalah gudang data lintas platform multidimensi yang mengumpulkan semua informasi yang diperlukan untuk menganalisis area subjek. Penggunaan satu repositori memungkinkan akses yang mudah, kecepatan pemrosesan yang tinggi, konsistensi informasi, penyimpanan terpusat dan dukungan otomatis untuk seluruh proses analisis data.

4. Klien-Server

Server Deduktor dirancang untuk pemrosesan analitis jarak jauh. Ini memberikan kemampuan untuk “menjalankan” data secara otomatis melalui skrip yang ada di server dan melatih ulang model yang ada. Menggunakan Deductor Server memungkinkan Anda mengimplementasikan arsitektur tiga tingkat lengkap yang berfungsi sebagai server aplikasi. Akses ke server disediakan menggunakan Deductor Client.

Prinsip kerja:

1. Impor data

Analisis informasi apa pun di Deduktor dimulai dengan impor data. Sebagai hasil impor, data dibawa ke dalam bentuk yang sesuai untuk analisis selanjutnya menggunakan semua mekanisme yang tersedia dalam program. Sifat data, format, DBMS, dll. tidak menjadi masalah, karena mekanisme untuk bekerja dengan semua orang adalah satu kesatuan.

2. Ekspor data

Kehadiran mekanisme ekspor memungkinkan Anda mengirimkan hasil yang diperoleh ke aplikasi pihak ketiga, misalnya mentransfer perkiraan penjualan ke sistem untuk menghasilkan pesanan pembelian atau memposting laporan yang telah disiapkan di situs web perusahaan.

3. Pengolahan data

Pemrosesan di Deduktor berarti tindakan apa pun yang terkait dengan beberapa jenis transformasi data, misalnya pemfilteran, pembuatan model, pembersihan, dll. Sebenarnya, di blok ini tindakan paling penting dari sudut pandang analisis dilakukan. Fitur paling signifikan dari mekanisme pemrosesan yang diterapkan di Deduktor adalah bahwa data yang diperoleh dari pemrosesan dapat diproses kembali dengan metode apa pun yang tersedia pada sistem. Dengan demikian, Anda dapat membuat skenario pemrosesan yang rumit dan sewenang-wenang.

4. Visualisasi

Anda dapat memvisualisasikan data di Deductor Studio (Viewer) pada setiap tahap pemrosesan. Sistem secara mandiri menentukan bagaimana ia dapat melakukan hal ini, misalnya, jika jaringan saraf dilatih, selain tabel dan diagram, Anda dapat melihat grafik jaringan saraf. Pengguna perlu memilih opsi yang diinginkan dari daftar dan mengkonfigurasi beberapa parameter.

5. Mekanisme integrasi

Deductor tidak menyediakan alat entri data - platform ini hanya berfokus pada pemrosesan analitis. Untuk menggunakan informasi yang disimpan dalam sistem heterogen, disediakan mekanisme ekspor-impor yang fleksibel. Interaksi dapat diatur menggunakan eksekusi batch, bekerja dalam mode server OLE dan mengakses Server Deduktor.

6.Replikasi ilmu

Deduktor memungkinkan Anda untuk mengimplementasikan salah satu fungsi terpenting dari sistem analitik apa pun - mendukung proses replikasi pengetahuan, mis. memberikan kesempatan kepada pegawai yang belum memahami metode analisis dan cara memperoleh hasil tertentu untuk menerima jawaban berdasarkan model yang disiapkan oleh seorang ahli.

Zkesimpulan

Dalam karya ini, kami memeriksa bidang modernitas seperti itu teknologi Informasi, sebagai sistem analisis data. Alat utama untuk pemrosesan informasi analitis - teknologi OLAP - dianalisis. Inti dari konsep OLAP dan pentingnya sistem OLAP dalam proses bisnis modern diungkapkan secara rinci. Struktur dan proses pengoperasian server ROLAP dijelaskan secara rinci. Sebagai contoh penerapan teknologi data OLAP, diberikan platform analitik Deductor. Dokumentasi yang diserahkan telah dikembangkan dan memenuhi persyaratan.

Teknologi OLAP adalah alat yang ampuh untuk pemrosesan data waktu nyata. Server OLAP memungkinkan Anda mengatur dan menyajikan data di berbagai area analitis dan mengubah data menjadi informasi berharga yang membantu perusahaan membuat keputusan yang lebih tepat.

Penggunaan sistem OLAP memberikan kinerja dan skalabilitas tingkat tinggi secara konsisten, mendukung volume data multi-gigabyte yang dapat diakses oleh ribuan pengguna. Dengan bantuan teknologi OLAP, akses informasi dilakukan secara real time, yaitu. Pemrosesan kueri tidak lagi memperlambat proses analisis, sehingga memastikan kecepatan dan efisiensinya. Alat administrasi visual memungkinkan Anda mengembangkan dan mengimplementasikan aplikasi analitis yang paling rumit sekalipun, menjadikan prosesnya sederhana dan cepat.

Dokumen serupa

Konsep OLAP (On-Line Analytical Processing) didasarkan pada pemrosesan data analitis operasional, fitur penggunaannya di klien dan di server. Karakteristik umum dari persyaratan dasar sistem OLAP, serta metode penyimpanan data di dalamnya.

abstrak, ditambahkan 12/10/2010


OLAP: karakteristik umum, maksud, tujuan, sasaran. Klasifikasi produk OLAP. Prinsip membangun sistem OLAP, pustaka komponen CubeBase. Ketergantungan kinerja alat OLAP klien dan server pada peningkatan volume data.

tugas kursus, ditambahkan 25/12/2013


Penyimpanan data abadi. Esensi dan pentingnya alat OLAP (On-line Analytical Processing). Database dan data warehouse, karakteristiknya. Struktur, arsitektur penyimpanan data, pemasoknya. Beberapa tip untuk meningkatkan kinerja kubus OLAP.

tes, ditambahkan 23/10/2010


Pembangunan sistem analisis data. Membangun algoritme untuk mendesain kubus OLAP dan membuat kueri untuk tabel pivot yang dibuat. Teknologi OLAP untuk analisis data multidimensi. Memberikan informasi kepada pengguna untuk membuat keputusan manajemen.

tugas kursus, ditambahkan 19/09/2008


Informasi dasar tentang OLAP. Pemrosesan data analitik operasional. Klasifikasi produk OLAP. Persyaratan untuk alat pemrosesan analitis online. Penggunaan database multidimensi dalam sistem pemrosesan analitik operasional, kelebihannya.

tugas kursus, ditambahkan 06/10/2011


Pengembangan subsistem analisis website menggunakan teknologi Microsoft Access dan Olap. Aspek teoritis pengembangan subsistem analisis data pada sistem informasi portal musik. Teknologi Olap dalam subsistem analisis objek penelitian.

tugas kursus, ditambahkan 06.11.2009


Pertimbangan alat OLAP: klasifikasi etalase dan gudang informasi, konsep kubus data. Arsitektur sistem pendukung keputusan. Implementasi perangkat lunak dari sistem "Abitura". Membuat laporan Web menggunakan teknologi Layanan Pelaporan.

tugas kursus, ditambahkan 05.12.2012


Penyimpanan data, prinsip organisasi. Proses untuk bekerja dengan data. Struktur OLAP, aspek teknis penyimpanan data multidimensi. Layanan Integrasi, mengisi gudang data dan data mart. Kemampuan sistem yang menggunakan teknologi Microsoft.

tugas kursus, ditambahkan 05.12.2012


Konstruksi diagram gudang data untuk perusahaan perdagangan. Deskripsi diagram hubungan penyimpanan. Menampilkan informasi produk. Pembuatan kubus OLAP untuk analisis informasi lebih lanjut. Pengembangan pertanyaan untuk mengevaluasi efisiensi supermarket.

tes, ditambahkan 19/12/2015


Tujuan penyimpanan data. Arsitektur SAP BW. Membangun pelaporan analitis berdasarkan kubus OLAP dalam sistem SAP BW. Perbedaan utama antara gudang data dan sistem OLTP. Ikhtisar area fungsional BEx. Membuat kueri di BEx Query Designer.

Pada tahun 1993, pendiri pendekatan relasional untuk konstruksi basis data, Edgar Codd dan mitranya (Edgar Codd, ahli matematika dan rekan IBM), menerbitkan sebuah artikel yang diprakarsai oleh Arbor Software (hari ini perusahaan terkenal"Hyperion Solutions"), bertajuk "Penyediaan OLAP (Online Analytical Processing) untuk Pengguna Analitik", yang menguraikan 12 fitur teknologi OLAP, yang kemudian diperluas menjadi enam fitur lainnya. Ketentuan tersebut menjadi isi utama dari sebuah teknologi baru dan sangat menjanjikan.

Fitur utama teknologi OLAP (Dasar):

• representasi data konseptual multidimensi;
• manipulasi data intuitif;
• ketersediaan dan detail data;
• ekstraksi data batch vs. interpretasi;
• model analisis OLAP;
• arsitektur client-server (OLAP dapat diakses dari desktop);
• transparansi (akses transparan terhadap data eksternal);
• dukungan multi-pengguna.

Fitur spesial:

• pemrosesan data yang tidak diformalkan;
• menyimpan hasil OLAP: menyimpannya secara terpisah dari data sumber;
• pengecualian nilai-nilai yang hilang;
• Menangani nilai-nilai yang hilang.

Fitur presentasi laporan:

• fleksibilitas dalam pelaporan;
• kinerja pelaporan standar;
• pengaturan otomatis lapisan fisik pengambilan data.

Manajemen dimensi:

• universalitas pengukuran;
• jumlah dimensi dan tingkat agregasi yang tidak terbatas;
• jumlah operasi antar dimensi yang tidak terbatas.

Secara historis, saat ini istilah "OLAP" tidak hanya menyiratkan tampilan multidimensi data dari pengguna akhir, tetapi juga tampilan multidimensi data dalam database target. Inilah sebabnya mengapa istilah “OLAP Relasional” (ROLAP) dan “OLAP Multidimensi” (MOLAP) muncul sebagai istilah yang independen.

Layanan OLAP adalah alat untuk menganalisis data dalam jumlah besar secara real time. Dengan berinteraksi dengan sistem OLAP, pengguna akan dapat secara fleksibel melihat informasi, memperoleh potongan data yang berubah-ubah, dan melakukan operasi analitis penelusuran, roll-up, distribusi ujung ke ujung, dan perbandingan dari waktu ke waktu menggunakan banyak parameter secara bersamaan. Semua pekerjaan dengan sistem OLAP terjadi berdasarkan area subjek dan memungkinkan Anda membangun model situasi bisnis yang masuk akal secara statistik.

Perangkat lunak OLAP adalah alat untuk analisis operasional data yang terdapat di gudang. Fitur utama adalah bahwa alat-alat ini ditujukan untuk digunakan bukan oleh seorang spesialis di bidang teknologi informasi, bukan oleh ahli statistik, tetapi oleh seorang profesional di bidang manajemen terapan - manajer suatu departemen, departemen, manajemen, dan, akhirnya, seorang sutradara. Alat tersebut dirancang untuk memungkinkan analis berkomunikasi dengan masalahnya, bukan dengan komputer. Pada Gambar. Gambar 6.14 menunjukkan kubus OLAP dasar yang memungkinkan Anda mengevaluasi data dalam tiga dimensi.

Kubus OLAP multidimensi dan sistem algoritma matematika yang sesuai pengolahan statistik memungkinkan Anda menganalisis data dengan kompleksitas apa pun pada interval waktu apa pun.

Beras. 6.14. Kubus OLAP dasar

Memiliki mekanisme yang fleksibel untuk manipulasi data dan tampilan visual (Gbr. 6.15, Gbr. 6.16), manajer pertama-tama mempertimbangkan sisi yang berbeda data yang mungkin (atau mungkin tidak) terkait dengan masalah yang sedang dipecahkan.

Selanjutnya, ia membandingkan berbagai indikator bisnis satu sama lain, mencoba mengidentifikasi hubungan tersembunyi; dapat melihat data lebih dekat, secara rinci, misalnya, mengelompokkannya menjadi beberapa komponen berdasarkan waktu, wilayah, atau pelanggan, atau, sebaliknya, menggeneralisasi lebih jauh penyajian informasi untuk menghilangkan detail yang mengganggu. Setelah itu, dengan menggunakan modul evaluasi dan simulasi statistik, beberapa opsi untuk perkembangan peristiwa dibangun, dan opsi yang paling dapat diterima dipilih darinya.

Beras. 6.15.

Seorang manajer perusahaan, misalnya, mungkin mempunyai hipotesis bahwa penyebaran pertumbuhan aset di berbagai cabang perusahaan bergantung pada rasio spesialis dengan pendidikan teknis dan ekonomi di dalamnya. Untuk menguji hipotesis ini, manajer dapat meminta dari gudang dan menampilkan pada grafik rasio minat untuk cabang-cabang yang pertumbuhan asetnya pada kuartal saat ini menurun lebih dari 10% dibandingkan tahun lalu, dan untuk cabang-cabang yang pertumbuhan asetnya pada kuartal berjalan menurun lebih dari 10% dibandingkan tahun lalu, dan untuk cabang-cabang yang meningkat lebih dari. 25%. Dia harus bisa menggunakan pilihan sederhana dari menu yang disediakan. Jika hasil yang diperoleh secara signifikan terbagi dalam dua kelompok yang bersesuaian, maka hal ini harus menjadi insentif untuk pengujian lebih lanjut terhadap hipotesis yang diajukan.

Saat ini, arah yang disebut pemodelan dinamis (Simulasi Dinamis), yang sepenuhnya mengimplementasikan prinsip FASMI di atas, telah berkembang pesat.

Dengan menggunakan pemodelan dinamis, analis membangun model situasi bisnis yang berkembang seiring waktu, menurut skenario tertentu. Selain itu, hasil dari pemodelan tersebut dapat berupa beberapa situasi bisnis baru yang menghasilkan sebuah pohon solusi yang memungkinkan dengan penilaian kemungkinan dan prospek masing-masing.

Beras. 6.16. IS analitis untuk ekstraksi data, pemrosesan, dan penyajian informasi

Tabel 6.3 menunjukkan karakteristik komparatif analisis statis dan dinamis.

OLAP (OnLine Analytical Processing) bukan nama produk tertentu, tetapi keseluruhan teknologi pemrosesan analitis operasional, yang melibatkan analisis data dan perolehan laporan. Pengguna diberikan tabel multidimensi yang secara otomatis merangkum data di berbagai bagian dan memungkinkan Anda mengelola perhitungan dan formulir laporan dengan cepat.

Meskipun dalam beberapa publikasi pemrosesan analitis disebut online dan interaktif, kata sifat “online” paling akurat mencerminkan arti teknologi OLAP. Pengembangan solusi manajemen oleh seorang manajer termasuk dalam kategori area yang paling rentan terhadap otomatisasi. Namun, saat ini terdapat peluang untuk membantu manajer dalam mengembangkan solusi dan, yang paling penting, secara signifikan mempercepat proses pengembangan solusi, pemilihan dan penerapannya.

Sistem pendukung keputusan biasanya memiliki sarana untuk menyediakan data agregat kepada pengguna untuk berbagai sampel dari kumpulan asli dalam bentuk yang nyaman untuk persepsi dan analisis. Biasanya, fungsi agregat tersebut membentuk kumpulan data multidimensi, sering disebut hypercube atau metacube, yang sumbunya berisi parameter, dan sel berisi data agregat yang bergantung padanya - dan data tersebut juga dapat disimpan dalam tabel relasional, tetapi dalam hal ini kita berbicara tentang organisasi logis data, dan bukan tentang implementasi fisik penyimpanannya.

Sepanjang setiap sumbu, data dapat diatur ke dalam hierarki, yang mewakili tingkat detail yang berbeda.

Menurut dimensi dalam model multidimensi, faktor-faktor yang mempengaruhi kegiatan perusahaan dikesampingkan (misalnya: waktu, produk, cabang perusahaan, dll). Kubus OLAP yang dihasilkan kemudian diisi dengan indikator aktivitas perusahaan (harga, penjualan, rencana, laba, surplus, dll.). Perlu dicatat bahwa, tidak seperti kubus geometris, permukaan kubus OLAP tidak harus berukuran sama. Ini dapat diisi dengan data nyata dari sistem operasi dan data perkiraan berdasarkan data historis. Dimensi hypercube bisa rumit, hierarkis, dan hubungan dapat dibangun di antara keduanya. Selama proses analisis, pengguna dapat mengubah sudut pandang data (yang disebut operasi mengubah tampilan logis), sehingga melihat data dari berbagai perspektif dan memecahkan masalah tertentu. Berbagai operasi dapat dilakukan pada kubus, termasuk peramalan dan perencanaan kondisional (analisis bagaimana-jika).

Berkat model data ini, pengguna dapat merumuskan kueri kompleks, menghasilkan laporan, dan memperoleh subkumpulan data. Pemrosesan analitik operasional dapat secara signifikan menyederhanakan dan mempercepat proses persiapan dan pengambilan keputusan oleh personel manajemen. Pemrosesan analitis online bertujuan mengubah data menjadi informasi. Hal ini secara mendasar berbeda dari proses pendukung keputusan tradisional, yang paling sering didasarkan pada peninjauan laporan terstruktur.

Teknologi OLAP mengacu pada jenis analisis cerdas dan melibatkan 12 prinsip:

1. Representasi multidimensi konseptual. Analis pengguna melihat dunia perusahaan bersifat multidimensi, dan oleh karena itu, model OLAP pada intinya harus multidimensi.

2. Transparansi. Arsitektur sistem OLAP harus terbuka, memungkinkan pengguna, dimanapun dia berada, berkomunikasi menggunakan alat analisis - klien - dengan server.

3. Ketersediaan. Pengguna analis OLAP harus mampu melakukan analisis berdasarkan skema konseptual umum yang berisi data seluruh perusahaan dalam database relasional serta data dari database lama, metode akses umum, dan model analitik umum. Sistem OLAP seharusnya hanya mengakses data yang benar-benar dibutuhkan, daripada mengadopsi pendekatan umum “corong dapur” yang memberikan masukan yang tidak perlu.

4. Kinerja yang konsisten dalam pengembangan laporan. Seiring bertambahnya jumlah dimensi atau ukuran database, analis pengguna tidak akan mengalami penurunan kinerja yang signifikan.

5. Arsitektur klien-server. Sebagian besar data yang saat ini perlu diproses secara analitis online terdapat pada mainframe dengan akses ke stasiun kerja pengguna melalui LAN. Artinya produk OLAP harus dapat bekerja di lingkungan client-server.

6. Multidimensi umum. Setiap dimensi harus diterapkan tanpa memperhatikan struktur dan kemampuan operasionalnya. Struktur data dasar, rumus, dan format pelaporan tidak boleh bias terhadap satu dimensi mana pun.

7. Manajemen dinamis dari matriks renggang. Desain fisik alat OLAP harus sepenuhnya disesuaikan dengan model analitik spesifik untuk pengelolaan matriks renggang yang optimal. Ketersebaran (diukur sebagai persentase sel kosong terhadap semua sel yang mungkin) adalah salah satu karakteristik propagasi data.

8. Dukungan multi-pengguna. Alat OLAP harus menyediakan kemampuan untuk berbagi kueri dan penyelesaian di antara banyak analis pengguna dengan tetap menjaga integritas dan keamanan.

9. Operasi silang tanpa batas. Karena sifat hierarkinya, berbagai operasi dapat mewakili hubungan dependen dalam model OLAP, yaitu lintas fungsi. Eksekusinya tidak mengharuskan pengguna analitis untuk mendefinisikan ulang perhitungan dan operasi ini.

10. Manipulasi data intuitif. Pandangan pengguna analis terhadap dimensi yang ditentukan dalam model analitik harus berisi semua informasi yang diperlukan untuk melakukan tindakan pada model OLAP, yaitu. mereka tidak memerlukan penggunaan sistem menu atau beberapa operasi antarmuka pengguna lainnya.

11. Opsi pelaporan yang fleksibel. Alat pelaporan harus berupa sintesis data atau informasi yang dihasilkan dari model data dalam orientasi apa pun yang memungkinkan. Artinya, baris, kolom, atau halaman laporan harus menampilkan beberapa dimensi model OLAP secara bersamaan, dengan kemampuan untuk menampilkan subkumpulan elemen (nilai) apa pun yang terdapat dalam dimensi tersebut, dalam urutan apa pun.

12. Dimensi dan jumlah tingkat agregasi tidak terbatas. Sebuah studi tentang kemungkinan jumlah dimensi yang diperlukan yang diperlukan dalam model analitik menunjukkan bahwa hingga 19 dimensi dapat digunakan secara bersamaan oleh pengguna-analis. Hal ini mengarah pada rekomendasi jumlah dimensi yang didukung oleh sistem OLAP. Selain itu, masing-masing dimensi umum tidak boleh dibatasi dalam jumlah tingkat agregasi yang ditentukan oleh analis pengguna.

Sistem OLAP khusus yang saat ini ditawarkan di pasaran meliputi CalliGraph dan Business Intelligence.

Untuk mengatasi masalah analisis data sederhana, dimungkinkan untuk menggunakan solusi anggaran - Aplikasi Office Excel dan Access dari Microsoft, yang berisi alat teknologi OLAP dasar yang memungkinkan Anda membuat tabel pivot dan membuat berbagai laporan berdasarkan tabel tersebut.