Merancang kubus data. Membuat kubus OLAP menggunakan Microsoft Query

Beras. 2. Irisan kubus OLAP

Rotasi(Gambar 3) - operasi mengubah lokasi pengukuran yang disajikan dalam laporan atau pada halaman yang ditampilkan. Misalnya, operasi rotasi mungkin melibatkan penataan ulang baris dan kolom tabel. Selain itu, memutar kubus data akan memindahkan dimensi di luar tabel ke tempatnya dengan dimensi yang ada di halaman yang ditampilkan, dan sebaliknya.

Anotasi: Kuliah ini membahas dasar-dasar perancangan kubus data untuk gudang data OLAP. Contoh ini menunjukkan metode pembuatan kubus data menggunakan alat CASE.

Tujuan kuliah

Setelah mempelajari materi pada kuliah ini, Anda akan mengetahui:

• apa yang dimaksud dengan kubus data gudang data OLAP ;
• cara mendesain kubus data gudang data OLAP ;
• apa yang dimaksud dengan dimensi kubus data;
• bagaimana suatu fakta dikaitkan dengan kubus data;
• apa yang dimaksud dengan atribut dimensi;
• apa itu hierarki;
• apa yang dimaksud dengan metrik kubus data;

dan belajar:

• membangun grafik multidimensi ;
• desain sederhana grafik multidimensi.

Perkenalan

Teknologi OLAP bukanlah teknologi tunggal perangkat lunak, Bukan bahasa pemrograman. 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.

Analis adalah konsumen utama informasi perusahaan. Tugas analis adalah menemukan pola dalam data dalam jumlah besar. Oleh karena itu, analis tidak akan memperhatikan fakta individu bahwa pada hari tertentu sejumlah pulpen dijual kepada pembeli Ivanov - ia memerlukan informasi tentang ratusan dan ribuan peristiwa serupa. Fakta tunggal di gudang data mungkin menarik, misalnya, bagi seorang akuntan atau kepala departemen penjualan, yang kompetensinya merupakan pendukung kontrak tertentu. Bagi seorang analis, satu catatan saja tidak cukup - dia, misalnya, mungkin memerlukan informasi tentang semua kontrak tempat penjualan selama satu bulan, kuartal, atau tahun. Analis mungkin tidak tertarik dengan NPWP pembeli atau nomor teleponnya - ia bekerja dengan data numerik tertentu, yang merupakan inti dari aktivitas profesionalnya.

Sentralisasi dan penataan yang nyaman bukanlah segalanya yang dibutuhkan seorang analis. Dia membutuhkan alat untuk melihat dan memvisualisasikan informasi. Laporan tradisional, bahkan yang dibuat berdasarkan satu gudang data, namun kurang memiliki fleksibilitas tertentu. Mereka tidak dapat “dipelintir”, “diperluas”, atau “diciutkan” untuk mendapatkan tampilan data yang diinginkan. Semakin banyak “potongan” dan “bagian” data yang dapat dieksplorasi oleh seorang analis, semakin banyak ide yang dimilikinya, yang pada gilirannya memerlukan lebih banyak “potongan” untuk verifikasi. OLAP berfungsi sebagai alat untuk analisis data oleh seorang analis.

Meskipun OLAP bukan merupakan atribut penting dari gudang data, OLAP semakin banyak digunakan untuk menganalisis informasi yang dikumpulkan di gudang data ini.

Data operasional dikumpulkan dari berbagai sumber, dibersihkan, diintegrasikan dan disimpan dalam gudang data. Selain itu, data tersebut sudah tersedia untuk dianalisis menggunakan berbagai alat pelaporan. Kemudian data (seluruhnya atau sebagian) disiapkan untuk analisis OLAP. Mereka dapat dimuat ke dalam database OLAP khusus atau dibiarkan dalam database relasional. Elemen terpenting dalam penggunaan OLAP adalah metadata, yaitu informasi tentang struktur, penempatan dan transformasi data. Berkat mereka, interaksi efektif berbagai komponen penyimpanan terjamin.

Dengan demikian, OLAP dapat didefinisikan sebagai seperangkat alat untuk analisis data multidimensi yang terakumulasi dalam gudang data. Secara teoritis, alat OLAP dapat diterapkan langsung ke data operasional atau data operasionalnya salinan persisnya. Namun, ada risiko data yang dianalisis tidak sesuai untuk analisis ini.

OLAP pada klien dan server

OLAP didasarkan pada analisis data multidimensi. Itu dapat diproduksi menggunakan berbagai alat, yang dapat dibagi menjadi alat OLAP klien dan server.

Alat klien OLAP adalah aplikasi yang menghitung data agregat (jumlah, rata-rata, nilai maksimum atau minimum) dan menampilkannya, sedangkan data agregat itu sendiri disimpan dalam cache di dalam ruang alamat alat OLAP tersebut.

Jika data sumber terdapat dalam DBMS desktop, penghitungan data agregat dilakukan oleh alat OLAP itu sendiri. Jika sumber data awal adalah DBMS server, banyak alat OLAP klien mengirimkan kueri SQL yang berisi operator GROUP BY ke server, dan sebagai hasilnya menerima data agregat yang dihitung di server.

Biasanya, fungsionalitas OLAP diimplementasikan dalam alat pemrosesan data statistik (dari produk kelas ini hingga pasar Rusia produk dari Stat Soft dan SPSS banyak digunakan) dan di beberapa spreadsheet. Secara khusus, ia memiliki alat analisis multidimensi yang baik Microsoft Excel 2000. Dengan menggunakan produk ini, Anda dapat membuat dan menyimpan kubus OLAP multidimensi lokal kecil sebagai file dan menampilkan bagian dua atau tiga dimensinya.

Banyak alat pengembangan berisi pustaka kelas atau komponen yang memungkinkan Anda membuat aplikasi yang mengimplementasikan fungsionalitas OLAP sederhana (seperti, misalnya, komponen Decision Cube di Borland Delphi dan Borland C++Builder). Selain itu, banyak perusahaan menawarkan kontrol ActiveX dan perpustakaan lain yang mengimplementasikan fungsi serupa.

Perhatikan bahwa alat OLAP klien digunakan, sebagai suatu peraturan, dengan jumlah dimensi yang kecil (biasanya disarankan tidak lebih dari enam) dan variasi nilai yang kecil untuk parameter ini - lagipula, data agregat yang dihasilkan harus sesuai dengan ruang alamat alat tersebut, dan jumlahnya bertambah secara eksponensial seiring bertambahnya jumlah pengukuran Oleh karena itu, bahkan alat OLAP klien yang paling primitif, sebagai suatu peraturan, memungkinkan penghitungan awal jumlah RAM yang diperlukan untuk membuat kubus multidimensi di dalamnya.

Banyak (tetapi tidak semua) alat klien OLAP memungkinkan Anda menyimpan konten cache dengan data agregat sebagai file, yang, pada gilirannya, memungkinkan Anda menghindari penghitungan ulang. Perhatikan bahwa peluang ini sering digunakan untuk mengasingkan data agregat untuk tujuan mentransfernya ke organisasi lain atau untuk dipublikasikan. Contoh khas dari data agregat yang dapat diasingkan adalah statistik morbiditas di berbagai wilayah dan kelompok umur yang berbeda informasi terbuka diterbitkan oleh kementerian kesehatan berbagai negara dan Organisasi Kesehatan Dunia. Pada saat yang sama, data asli itu sendiri, yang merupakan informasi tentang kasus penyakit tertentu, merupakan data rahasia dari institusi medis dan tidak boleh jatuh ke tangan perusahaan asuransi, apalagi dipublikasikan.

Gagasan menyimpan cache data agregat dalam sebuah file dikembangkan lebih lanjut di alat server OLAP, di mana penyimpanan dan perubahan data agregat, serta pemeliharaan penyimpanan yang memuatnya, dilakukan oleh aplikasi atau proses terpisah yang disebut file. server OLAP. Aplikasi klien dapat meminta penyimpanan multidimensi tersebut dan menerima data tertentu sebagai tanggapannya. Beberapa aplikasi klien juga dapat membuat penyimpanan tersebut atau memperbaruinya berdasarkan data sumber yang diubah.

Keuntungan menggunakan alat OLAP server dibandingkan dengan alat OLAP klien serupa dengan keuntungan menggunakan DBMS server dibandingkan dengan desktop: dalam hal menggunakan alat server, perhitungan dan penyimpanan data agregat terjadi di server, dan aplikasi klien hanya menerima hasil kueri terhadapnya, yang memungkinkan secara umum, mengurangi lalu lintas jaringan, waktu tunggu permintaan dan kebutuhan sumber daya yang dikonsumsi oleh aplikasi klien. Perhatikan bahwa alat analisis dan pemrosesan data skala perusahaan, biasanya, didasarkan pada alat OLAP server, misalnya, Oracle Express Server, Microsoft SQL Server 2000 Analysis Services, Hyperion Essbase, produk dari Crystal Decisions, Business Objects, Cognos, SAS Lembaga. Karena semua produsen DBMS server terkemuka memproduksi (atau memiliki lisensi dari perusahaan lain) satu atau beberapa alat OLAP server, pilihannya cukup luas, dan di hampir semua kasus Anda dapat membeli server OLAP dari produsen yang sama dengan server database itu sendiri. .

Perhatikan bahwa banyak alat OLAP klien (khususnya, Microsoft Excel 2003, Seagate Analysis, dll.) memungkinkan Anda mengakses penyimpanan OLAP server, dalam hal ini bertindak sebagai aplikasi klien yang melakukan kueri tersebut. Selain itu, ada banyak produk yang merupakan aplikasi klien untuk alat OLAP dari berbagai produsen.

Aspek teknis penyimpanan data multidimensi

Gudang data multidimensi berisi data agregat dengan tingkat detail yang berbeda-beda, misalnya volume penjualan berdasarkan hari, bulan, tahun, berdasarkan kategori produk, dll. Tujuan penyimpanan data agregat adalah untuk mengurangi waktu tunggu permintaan, karena dalam banyak kasus, untuk analisis dan prakiraan, ini bukan data rinci, tetapi ringkasan data yang menarik. Oleh karena itu, saat membuat database multidimensi, beberapa data agregat selalu dihitung dan disimpan.

Perlu diperhatikan bahwa menyimpan semua data agregat tidak selalu dapat dibenarkan. Faktanya adalah ketika dimensi baru ditambahkan, volume data yang membentuk kubus tumbuh secara eksponensial (terkadang mereka berbicara tentang “pertumbuhan eksplosif” volume data). Lebih tepatnya, tingkat pertumbuhan volume data agregat bergantung pada jumlah dimensi kubus dan anggota dimensi di berbagai tingkat hierarki dimensi tersebut. Untuk mengatasi masalah “pertumbuhan eksplosif”, berbagai skema digunakan yang memungkinkan tercapainya kecepatan eksekusi kueri yang dapat diterima saat menghitung tidak semua kemungkinan data agregat.

Data mentah dan agregat dapat disimpan dalam struktur relasional atau multidimensi. Oleh karena itu, tiga metode penyimpanan data saat ini digunakan.

• MOLAP(OLAP Multidimensi) - data sumber dan agregat disimpan dalam database multidimensi. Menyimpan data dalam struktur multidimensi memungkinkan Anda memanipulasi data sebagai array multidimensi, sehingga kecepatan penghitungan nilai agregat sama untuk semua dimensi. Namun, dalam kasus ini, database multidimensi bersifat mubazir, karena data multidimensi seluruhnya berisi data relasional asli.
• ROLAP(OLAP Relasional) - data asli tetap berada dalam database relasional yang sama dengan lokasi aslinya. Data agregat ditempatkan di tabel layanan yang dibuat khusus untuk menyimpannya dalam database yang sama.
• TERSEMBUNYI(Hybrid OLAP) - data asli tetap berada dalam database relasional yang sama dengan lokasi aslinya, dan data agregat disimpan dalam database multidimensi.

Beberapa alat OLAP mendukung penyimpanan data hanya dalam struktur relasional, beberapa hanya dalam struktur multidimensi. Namun, sebagian besar alat OLAP server modern mendukung ketiga metode penyimpanan data. Pilihan metode penyimpanan bergantung pada volume dan struktur data awal, persyaratan kecepatan eksekusi kueri, dan frekuensi pembaruan kubus OLAP.

Perhatikan juga bahwa sebagian besar alat OLAP modern tidak menyimpan nilai "kosong" (contoh nilai "kosong" adalah tidak adanya penjualan produk musiman di luar musim).

Konsep Dasar OLAP

tes FAMSI

Teknologi analisis data multidimensi yang kompleks disebut OLAP (On-Line Analytical Processing). OLAP adalah komponen kunci dari organisasi gudang data. Konsep OLAP dijelaskan pada tahun 1993 oleh Edgar Codd, seorang peneliti database terkenal dan penulis model data relasional. Pada tahun 1995, berdasarkan persyaratan yang ditetapkan oleh Codd, apa yang disebut tes FASMI(Analisis Cepat Informasi Multidimensi Bersama) - analisis cepat informasi multidimensi bersama, termasuk persyaratan berikut untuk aplikasi analisis multidimensi:

• Cepat(Cepat) - memberikan hasil analisis kepada pengguna dalam waktu yang dapat diterima (biasanya tidak lebih dari 5 detik), bahkan dengan biaya analisis yang kurang detail;
• Analisis(Analisis) - kemampuan untuk melakukan analisis logis dan statistik khusus untuk aplikasi tertentu dan menyimpannya dalam bentuk yang dapat diakses oleh pengguna akhir;
• Bersama(Berbagi) - akses multi-pengguna ke data dengan dukungan mekanisme penguncian yang sesuai dan sarana akses resmi;
• Multidimensi(Multidimensi) - representasi data konseptual multidimensi, termasuk dukungan penuh untuk hierarki dan banyak hierarki (ini adalah persyaratan utama OLAP);
• Informasi(Informasi) - aplikasi harus dapat mengakses informasi apa pun yang diperlukan, berapa pun volume dan lokasi penyimpanannya.

Perlu dicatat bahwa fungsionalitas OLAP dapat diimplementasikan cara yang berbeda, dimulai dengan alat analisis data paling sederhana dalam aplikasi perkantoran dan diakhiri dengan sistem analisis terdistribusi berdasarkan produk server.

Representasi informasi multidimensi

kotak

OLAP menyediakan cara yang mudah dan cepat untuk mengakses, melihat, dan menganalisis informasi bisnis. Pengguna menerima yang alami dan intuitif model data, mengorganisasikannya dalam bentuk kubus multidimensi (Cubes). Sumbu sistem koordinat multidimensi merupakan atribut utama dari proses bisnis yang dianalisis. Misalnya untuk penjualan bisa berupa produk, wilayah, jenis pembeli. Waktu digunakan sebagai salah satu dimensi. Pada perpotongan sumbu pengukuran (Dimensi) terdapat data yang secara kuantitatif mencirikan proses – ukuran (Measures). Ini bisa berupa volume penjualan dalam jumlah kecil atau dalam istilah moneter, saldo stok, biaya, dll. Pengguna yang menganalisis informasi dapat "memotong" kubus ke arah yang berbeda, mendapatkan ringkasan (misalnya, berdasarkan tahun) atau, sebaliknya, terperinci ( berdasarkan minggu ) informasi dan melakukan manipulasi lain yang terlintas dalam pikirannya selama proses analisis.

Seperti ukuran dalam kubus tiga dimensi yang ditunjukkan pada Gambar. 26.1, jumlah penjualan digunakan, dan waktu, produk, dan toko digunakan sebagai dimensi. Pengukuran ditunjukkan pada tingkat tertentu pengelompokan: produk dikelompokkan berdasarkan kategori, toko - berdasarkan negara, dan data waktu transaksi - berdasarkan bulan. Nanti kita akan melihat tingkatan pengelompokan ( hierarki) lebih detail.

Beras. 26.1.

"Memotong" sebuah kubus

Kubus tiga dimensi pun sulit ditampilkan di layar komputer sehingga nilai besaran yang diinginkan dapat terlihat. Apa yang dapat kita katakan tentang kubus yang lebih dari tiga dimensi? Untuk memvisualisasikan data yang disimpan dalam kubus, biasanya digunakan dua dimensi yang sudah dikenal, yaitu tampilan tabel dengan judul baris dan kolom hierarki yang kompleks.

Representasi dua dimensi dari sebuah kubus dapat diperoleh dengan "memotongnya" melintang sepanjang satu atau lebih sumbu (dimensi): kita memperbaiki nilai semua dimensi kecuali dua, dan kita mendapatkan tabel dua dimensi biasa. Sumbu horizontal tabel (header kolom) mewakili satu dimensi, sumbu vertikal (header baris) mewakili dimensi lain, dan sel tabel mewakili nilai ukuran. Dalam hal ini, serangkaian ukuran sebenarnya dianggap sebagai salah satu dimensi: kita memilih satu ukuran untuk ditampilkan (dan kemudian kita dapat menempatkan dua dimensi dalam judul baris dan kolom), atau menampilkan beberapa ukuran (dan kemudian salah satu dari ukuran tersebut). sumbu tabel akan ditempati oleh nama-nama ukuran, dan yang lainnya oleh nilai-nilai satu-satunya dimensi yang "tidak dipotong").

Arsitektur aplikasi OLAP

Segala sesuatu yang dikatakan di atas tentang OLAP pada dasarnya berkaitan dengan penyajian data multidimensi. Bagaimana data disimpan, secara kasar, tidak menjadi perhatian pengguna akhir atau pengembang alat yang digunakan klien.

Multidimensi dalam aplikasi OLAP dapat dibagi menjadi tiga tingkatan.

• Representasi data multidimensi - alat pengguna akhir yang menyediakan visualisasi multidimensi dan manipulasi data; Lapisan representasi multidimensi mengabstraksi struktur fisik data dan memperlakukan data sebagai multidimensi.
• Pemrosesan multidimensi adalah sarana (bahasa) untuk merumuskan kueri multidimensi (bahasa relasional tradisional SQL tidak cocok di sini) dan prosesor yang dapat memproses dan mengeksekusi kueri tersebut.
• Penyimpanan multidimensi adalah sarana pengorganisasian data secara fisik yang memastikan eksekusi kueri multidimensi yang efisien.

Dua level pertama wajib ada di semua alat OLAP. Tingkat ketiga, meskipun tersebar luas, tidak diperlukan, karena data untuk representasi multidimensi dapat diekstraksi dari struktur relasional biasa; Pemroses kueri multidimensi dalam hal ini menerjemahkan kueri multidimensi menjadi kueri SQL yang dijalankan oleh DBMS relasional.

Produk OLAP tertentu, biasanya, adalah alat presentasi data multidimensi (klien OLAP - misalnya, Tabel Pivot di Excel 2000 dari Microsoft atau ProClarity dari Knosys) atau DBMS server multidimensi (server OLAP - misalnya, Oracle Express Server atau Layanan Microsoft OLAP).

Lapisan pemrosesan multidimensi biasanya dibangun ke dalam klien OLAP dan/atau server OLAP, tetapi dapat diisolasi dalam bentuknya yang murni, seperti komponen Layanan Tabel Pivot Microsoft.

/ Secara kubisme. Penerapan kubus OLAP dalam praktik manajemen perusahaan besar

Dalam kontak dengan

Teman sekelas

Konstantin Tokmachev, arsitek sistem

Dengan gaya kubisme.
Penerapan kubus OLAP dalam praktik manajemen perusahaan besar

Mungkin zamannya telah berlalu ketika sumber daya komputasi suatu perusahaan hanya dihabiskan untuk mencatat informasi dan laporan akuntansi. Pada saat yang sama, keputusan manajemen dibuat “secara langsung” di kantor, pada rapat dan sesi. Mungkin di Rusia sudah waktunya untuk mengembalikan sistem komputasi perusahaan ke sumber daya utamanya - menyelesaikan masalah manajemen berdasarkan data yang terdaftar di komputer

Tentang manfaat analisis bisnis

Dalam lingkaran manajemen perusahaan, antara data "mentah" dan "pengungkit" yang mempengaruhi objek yang dikelola, terdapat "indikator kinerja" - KPI. Mereka membentuk semacam "dasbor", yang mencerminkan keadaan berbagai subsistem dari objek yang dikendalikan. Melengkapi perusahaan dengan indikator kinerja yang informatif dan memantau penghitungan serta nilai yang diperoleh adalah pekerjaan seorang analis bisnis. Layanan analisis otomatis, seperti utilitas MS, dapat memberikan bantuan yang signifikan dalam mengatur pekerjaan analitis suatu perusahaan. SQLServer Analysis Services (SSAS) dan fitur utamanya adalah kubus OLAP.

Satu hal lagi yang perlu disampaikan di sini. Misalnya, dalam tradisi Amerika, spesialisasi yang berfokus pada bekerja dengan kubus OLAP disebut BI (Business Intelligence). Seharusnya tidak ada ilusi bahwa BI Amerika sama dengan “analis bisnis” Rusia. Jangan tersinggung, tetapi seringkali analis bisnis kita adalah “under-accountant” dan “under-programmer”, seorang spesialis dengan pengetahuan yang tidak jelas dan gaji yang kecil, yang sebenarnya tidak memiliki alat dan metodologi sendiri.

Faktanya, seorang spesialis BI adalah seorang ahli matematika terapan, seorang spesialis berkualifikasi tinggi yang menerapkan metode matematika modern ke dalam gudang senjata perusahaan (apa yang disebut Riset Operasi - metode riset operasi). BI lebih konsisten dengan spesialisasi “analis sistem” yang pernah ada di Uni Soviet, lulusan Fakultas Matematika Komputasi dan Matematika Universitas Negeri Moskow. M.V. Lomonosov. Layanan kubus dan analisis OLAP dapat menjadi dasar yang menjanjikan untuk tempat kerja seorang analis bisnis Rusia, mungkin setelah beberapa pelatihan lanjutan ke arah BI Amerika.

DI DALAM Akhir-akhir ini Tren berbahaya lainnya telah muncul. Berkat spesialisasi, saling pengertian antara berbagai kategori karyawan perusahaan telah hilang. Seorang akuntan, manajer dan programmer, seperti “angsa, udang karang, dan tombak” dalam dongeng I.A. Krylov, menarik korporasi ke arah yang berbeda.

Akuntan sibuk dengan pelaporan, jumlah-jumlahnya, baik makna maupun dinamikanya, tidak berhubungan langsung dengan proses bisnis perusahaan.

Manajer sibuk dengan bagiannya dalam proses bisnis, tetapi tidak mampu mengevaluasi secara global, di tingkat perusahaan secara keseluruhan, hasil dan prospek tindakannya.

Terakhir, programmer yang dulunya (berkat pendidikannya) menjadi penghantar ide-ide teknis tingkat lanjut dari bidang sains ke bidang bisnis, telah berubah menjadi eksekutor pasif fantasi akuntan dan manajer, jadi tidak ada lagi. sudah tidak lazim lagi departemen TI perusahaan digerakkan oleh akuntan dan, secara umum, semua orang yang tidak malas. Kurangnya inisiatif, buta huruf, tetapi programmer 1C yang dibayar relatif tinggi adalah momok nyata bagi perusahaan-perusahaan Rusia. (Hampir seperti pemain sepak bola dalam negeri.) Saya bahkan tidak berbicara tentang apa yang disebut “ekonom dan pengacara”; semuanya telah dikatakan tentang mereka sejak lama.

Jadi, posisi seorang analis bisnis yang dibekali dengan peralatan SSAS yang intensif pengetahuan, menguasai dasar-dasar pemrograman dan akuntansi, mampu memantapkan pekerjaan perusahaan dalam kaitannya dengan analisis dan peramalan proses bisnis.

Keuntungan dari kubus OLAP

Kubus OLAP adalah obat modern analisis database sistem komputer perusahaan, yang memungkinkan karyawan di semua tingkat hierarki menyediakan serangkaian indikator yang diperlukan yang menjadi ciri proses produksi perusahaan. Intinya bukan hanya antarmuka yang nyaman dan bahasa kueri yang fleksibel untuk kubus MDX (MultiDimensional eXpressions) yang memungkinkan Anda merumuskan dan menghitung indikator analitik yang diperlukan, tetapi juga kecepatan dan kemudahan luar biasa yang digunakan kubus OLAP untuk melakukan hal ini. Apalagi kecepatan dan kemudahan ini, dalam batas tertentu, tidak bergantung pada kerumitan perhitungan dan ukuran database.

Beberapa pengenalan OLAP-
kubus dapat diberikan oleh "tabel pivot" dari MS Excel. Objek-objek ini memiliki logika serupa dan antarmuka serupa. Namun, seperti yang dapat dilihat dari artikel tersebut, fungsionalitas OLAP jauh lebih kaya, dan kinerjanya jauh lebih tinggi, sehingga “tabel pivot” tetap menjadi produk desktop lokal, sedangkan OLAP adalah produk tingkat perusahaan.

Mengapa kubus OLAP sangat cocok untuk memecahkan masalah analitis? Kubus OLAP dirancang sedemikian rupa sehingga semua indikator di semua bagian yang memungkinkan telah dihitung sebelumnya (seluruhnya atau sebagian), dan pengguna hanya dapat “menarik” indikator (ukuran) dan dimensi (dimensi) yang diperlukan dengan mouse, dan program dapat menggambar ulang tabel.

Semua kemungkinan analitik di semua bagian membentuk satu bidang besar, atau lebih tepatnya, bukan bidang, tetapi hanya kubus OLAP multidimensi. Apapun permintaan pengguna (manajer, analis bisnis, eksekutif) terhadap layanan analitik, kecepatan respons dijelaskan oleh dua hal: pertama, analitik yang diperlukan dapat dengan mudah dirumuskan (baik dipilih dari daftar berdasarkan nama, atau ditentukan oleh a rumus dalam bahasa MDX ), kedua, sebagai aturan, sudah dihitung.

Perumusan analitik dimungkinkan dalam tiga cara: bidang database (atau lebih tepatnya, bidang gudang), atau bidang perhitungan yang ditentukan pada tingkat desain kubus, atau ekspresi bahasa MDX saat bekerja secara interaktif dengan kubus.

Ini berarti beberapa fitur menarik dari kubus OLAP. Pada dasarnya, penghalang antara pengguna dan data hilang. Hambatannya berupa seorang pemrogram aplikasi yang pertama-tama perlu menjelaskan masalah (set a task). Kedua, Anda harus menunggu pemrogram aplikasi membuat algoritme, menulis dan men-debug program, dan mungkin memodifikasinya. Jika jumlah karyawan banyak dan kebutuhan mereka bervariasi dan dapat diubah, maka diperlukan seluruh tim pemrogram aplikasi. Dalam hal ini, kubus OLAP (dan analis bisnis yang berkualifikasi) menggantikan seluruh tim pemrogram aplikasi dalam hal pekerjaan analitis, seperti halnya ekskavator yang kuat dengan operator ekskavator menggantikan seluruh tim pekerja migran dengan sekop saat menggali parit!

Pada saat yang sama, kualitas lain yang sangat penting dari data analitis yang diperoleh tercapai. Karena hanya ada satu kubus OLAP untuk seluruh perusahaan, yaitu. Ini adalah bidang yang sama dengan analis untuk semua orang, yang menghilangkan perbedaan yang mengganggu dalam data. Ketika seorang manajer harus menanyakan tugas yang sama kepada beberapa karyawan independen untuk menghilangkan faktor subjektivitas, tetapi mereka tetap memberikan jawaban yang berbeda, yang harus dijelaskan oleh setiap orang, dll. Kubus OLAP memastikan keseragaman data analitik di berbagai tingkat hierarki perusahaan, mis. jika seorang manajer ingin merinci suatu indikator tertentu yang menarik baginya, maka dia pasti akan sampai pada data tingkat yang lebih rendah yang digunakan bawahannya, dan inilah data yang menjadi dasar penghitungan indikator tingkat yang lebih tinggi. , dan bukan data lain, diterima dengan cara lain, di waktu lain, dan seterusnya. Artinya, seluruh perusahaan melihat analitik yang sama, tetapi pada tingkat agregasi yang berbeda.

Mari kita beri contoh. Katakanlah seorang manajer mengendalikan piutang. Selama KPI piutang yang telah jatuh tempo berwarna hijau, berarti semuanya normal dan tidak diperlukan tindakan pengelolaan. Jika warnanya berubah menjadi kuning atau merah, berarti ada yang salah: kami memotong KPI berdasarkan departemen penjualan dan langsung melihat departemen “berwarna merah”. Bagian selanjutnya oleh manajer - dan penjual yang kliennya terlambat pembayaran diidentifikasi. (Selanjutnya, jumlah yang telah jatuh tempo dapat dibagi berdasarkan pelanggan, berdasarkan persyaratan, dll.) Pimpinan perusahaan dapat langsung menghubungi pelanggar di tingkat mana pun. Namun secara umum, KPI yang sama (pada tingkat hierarkinya) dilihat oleh kepala departemen dan manajer penjualan. Oleh karena itu, untuk memperbaiki situasi, mereka bahkan tidak perlu menunggu “panggilan di atas karpet”... Tentu saja, KPI itu sendiri tidak harus berupa jumlah pembayaran yang telah jatuh tempo - bisa berupa rata-rata tertimbang jangka waktu pembayaran yang telah jatuh tempo atau, secara umum, tingkat perputaran piutang.

Mari kita perhatikan bahwa kompleksitas dan fleksibilitas bahasa MDX, bersama dengan hasil yang cepat (terkadang seketika), memungkinkan kita untuk menyelesaikan (dengan mempertimbangkan tahapan pengembangan dan debugging) tugas-tugas kontrol yang kompleks yang mungkin tidak dapat dilakukan sama sekali. karena kompleksitas bagi pemrogram aplikasi dan ketidakpastian awal dalam formulasi. (Batas waktu yang lama bagi pemrogram aplikasi untuk memecahkan masalah analitis karena formulasi yang kurang dipahami dan modifikasi program yang lama ketika kondisi berubah sering ditemui dalam praktik.)

Mari kita juga memperhatikan fakta bahwa setiap karyawan perusahaan dapat mengumpulkan dari lapangan umum seorang analis OLAP hasil panen yang dia butuhkan untuk pekerjaannya, dan tidak puas dengan “strip” yang dipotong untuknya di komunal. “laporan standar”.

Antarmuka multi-pengguna untuk bekerja dengan kubus OLAP dalam mode klien-server memungkinkan setiap karyawan, secara independen dari yang lain, memiliki blok analitik (laporan) sendiri (bahkan buatan sendiri dengan beberapa keahlian), yang, setelah ditentukan, secara otomatis diperbarui - dengan kata lain, kondisinya selalu terkini.

Artinya, kubus OLAP memungkinkan Anda membuat pekerjaan analitis (yang sebenarnya dilakukan tidak hanya oleh analis penerimaan, namun, pada kenyataannya, oleh hampir semua karyawan perusahaan, bahkan ahli logistik dan manajer yang mengontrol saldo dan pengiriman) lebih selektif, “tidak secara umum”, yang menciptakan kondisi untuk meningkatkan pekerjaan dan meningkatkan produktivitas.

Untuk meringkas pendahuluan kami, kami mencatat bahwa penggunaan kubus OLAP dapat meningkatkan manajemen perusahaan lebih banyak lagi level tinggi. Keseragaman data analitik di semua tingkat hierarki, keandalan, kompleksitas, kemudahan membuat dan memodifikasi indikator, pengaturan individual, kecepatan pemrosesan data yang tinggi, dan terakhir, menghemat uang dan waktu yang dihabiskan untuk mendukung jalur analitis alternatif (pemrogram aplikasi, perhitungan independen karyawan) membuka prospek penggunaan kubus OLAP dalam praktik perusahaan besar Rusia.

OLTP + OLAP: putaran umpan balik dalam rantai manajemen perusahaan

Sekarang mari kita lihat gambaran umum kubus OLAP dan penerapannya dalam rantai manajemen perusahaan. Istilah OLAP (OnLine Analytical Processing) diperkenalkan oleh ahli matematika Inggris Edgar Codd selain istilah OLTP (OnLine Transactions Processing) yang diperkenalkan sebelumnya. Hal ini akan dibahas nanti, namun E. Codd tentu saja tidak hanya mengajukan istilah, tetapi juga teori matematika OLTP dan OLAP. Tanpa menjelaskan secara rinci, dalam interpretasi modern, OLTP adalah database relasional, dianggap sebagai mekanisme untuk merekam, menyimpan, dan mengambil informasi.

Metodologi solusi

Sistem ERP (Enterprice Resource Planning), seperti 1C7, 1C8, MS Dynamics AX, memiliki antarmuka perangkat lunak yang berorientasi pengguna (memasukkan dan mengedit dokumen, dll.) dan database relasional (DB) untuk menyimpan dan mengambil informasi yang disajikan saat ini produk perangkat lunak ketik MS SQL Server (SS).

Perhatikan bahwa informasi yang terdaftar dalam database sistem ERP memang merupakan sumber daya yang sangat berharga. Intinya bukan hanya informasi yang terdaftar memastikan aliran dokumen perusahaan saat ini (mengekstraksi dokumen, koreksinya, kemampuan untuk mencetak dan merekonsiliasi, dll.) dan tidak hanya kemungkinan perhitungan laporan keuangan(pajak, audit, dll). Dari sudut pandang manajemen, yang jauh lebih penting adalah bahwa sistem OLTP (database relasional), pada kenyataannya, adalah model digital sebenarnya dari aktivitas perusahaan.

Namun untuk mengelola prosesnya, mendaftarkan informasi tentangnya saja tidak cukup. Proses tersebut harus disajikan dalam bentuk sistem indikator numerik (KPI) yang mencirikan kemajuannya. Selain itu, rentang nilai yang dapat diterima untuk indikator harus ditentukan. Dan hanya jika nilai indikator berada di luar interval yang diizinkan, tindakan pengendalian harus dilakukan.

Mengenai logika (atau mitologi) kendali (“kontrol dengan penyimpangan”), keduanya filsuf Yunani kuno Plato, yang menciptakan gambaran juru mudi (cybernose), yang bersandar pada dayung ketika perahu menyimpang dari jalurnya, dan ahli matematika Amerika Norbert Wiener, yang menciptakan ilmu sibernetika menjelang era komputer.

Selain sistem pencatatan informasi yang biasa menggunakan metode OLTP, diperlukan sistem lain – sistem untuk menganalisis informasi yang dikumpulkan. Add-on ini, yang dalam loop kontrol berperan sebagai umpan balik antara manajemen dan objek kontrol, adalah sistem OLAP atau, singkatnya, kubus OLAP.

Sebagai implementasi perangkat lunak OLAP, kami akan mempertimbangkan utilitas MS Analysis Services, yang merupakan bagian dari pengiriman standar MS SQL Server, disingkat SSAS. Perhatikan bahwa, menurut rencana E. Codd, kubus OLAP dalam analitik harus memberikan kebebasan bertindak komprehensif yang sama seperti yang disediakan sistem OLTP dan database relasional (SQL Server) dalam menyimpan dan mengambil informasi.

Logistik OLAP

Sekarang mari kita lihat konfigurasi spesifik perangkat eksternal, program aplikasi, dan operasi teknologi yang menjadi dasar operasi otomatis kubus OLAP.

Kami berasumsi bahwa perusahaan menggunakan sistem ERP, misalnya 1C7 atau 1C8, di mana informasi dicatat seperti biasa. Database sistem ERP ini terletak pada server tertentu dan didukung oleh MS SQL Server.

Kami juga akan berasumsi bahwa server lain telah menginstal perangkat lunak, termasuk MS SQL Server dengan utilitas MS Analysis Services (SSAS), serta MS SQL Server Management Studio, MS C#, MS Excel, dan MS Visual Studio. Program-program ini bersama-sama membentuk konteks yang diperlukan: alat dan antarmuka yang diperlukan untuk pengembang kubus OLAP.

Server SSAS memiliki program yang didistribusikan secara bebas yang disebut blat, yang disebut (dengan parameter) dari garis komando dan menyediakan layanan pos.

Di tempat kerja karyawan, di dalam jaringan lokal, antara lain, program MS Excel (versi tidak kurang dari 2003) diinstal, serta, mungkin, driver khusus untuk memastikan bahwa MS Excel berfungsi dengan MS Analysis Services (kecuali driver terkait sudah disertakan dalam MS Excel).

Untuk lebih jelasnya, kita asumsikan sistem operasi Windows XP diinstal pada workstation karyawan, dan Windows Server 2008 diinstal pada server. Selain itu, mari kita gunakan MS SQL Server 2005 sebagai SQL Server, dan biarkan Enterprise Edition (EE) diinstal. di server dengan kubus OLAP ) atau Edisi Pengembang (DE). Dalam edisi ini dimungkinkan untuk menggunakan apa yang disebut. “tindakan semi-aditif”, yaitu fungsi agregat tambahan (statistik) selain jumlah biasa (misalnya, ekstrem atau rata-rata).

Desain kubus OLAP (kubisme OLAP)

Katakanlah beberapa patah kata tentang desain kubus OLAP itu sendiri. Dalam bahasa statistik, kubus OLAP adalah sekumpulan indikator kinerja yang dihitung di semua bagian yang diperlukan, misalnya, indikator pengiriman berdasarkan bagian oleh pelanggan, berdasarkan barang, berdasarkan tanggal, dll. Karena terjemahan langsung dari bahasa Inggris ke literatur Rusia pada kubus OLAP, indikator disebut “ukuran”, dan bagian disebut “dimensi”. Ini adalah terjemahan yang benar secara matematis, tetapi secara sintaksis dan semantik tidak terlalu berhasil. Kata-kata Rusia “measure”, “dimension”, “dimension” hampir sama dalam arti dan ejaan, sedangkan kata “measure” dan “dimension” dalam bahasa Inggris berbeda baik dalam ejaan maupun makna. Oleh karena itu, kami lebih memilih istilah statistik tradisional Rusia “indikator” dan “potongan”, yang memiliki arti serupa.

Ada beberapa opsi untuk implementasi perangkat lunak kubus OLAP dalam kaitannya dengan sistem OLTP tempat data direkam. Kami hanya akan mempertimbangkan satu skema, yang paling sederhana, paling andal, dan tercepat.

Dalam desain ini, OLAP dan OLTP tidak berbagi tabel, dan analitik OLAP dihitung sedetail mungkin selama tahap pembaruan kubus (Proses), yang mendahului tahap penggunaan. Skema ini disebut MOLAP (Multidimensional OLAP). Kerugiannya adalah ketidaksinkronan dengan ERP dan biaya memori yang tinggi.

Meskipun secara formal sebuah kubus OLAP dapat dibangun dengan menggunakan semua (ribuan) tabel database relasional sistem ERP sebagai sumber data dan semua (ratusan) bidangnya sebagai indikator atau bagian, pada kenyataannya hal ini tidak boleh dilakukan. Dan sebaliknya. Untuk memuat ke dalam kubus, lebih tepat menyiapkan database terpisah yang disebut "showcase" atau "gudang".

Ada beberapa alasan yang memaksa kita melakukan hal ini.

• Pertama, mengikat kubus OLAP ke tabel basis nyata data tentu akan menimbulkan permasalahan teknis. Mengubah data dalam tabel dapat memicu penyegaran kubus, dan menyegarkan kubus belum tentu merupakan proses yang cepat, sehingga kubus akan terus-menerus dibangun kembali; Pada saat yang sama, prosedur pembaruan kubus dapat memblokir (saat membaca) data tabel database, memperlambat pekerjaan pengguna dalam mendaftarkan data di sistem ERP.
• Kedua, Memiliki terlalu banyak indikator dan pemotongan akan meningkatkan area penyimpanan kubus secara signifikan di server. Jangan lupa bahwa kubus OLAP tidak hanya menyimpan data awal, seperti pada sistem OLTP, tetapi juga semua indikator yang dijumlahkan untuk semua bagian yang mungkin (dan bahkan semua kombinasi dari semua bagian). Selain itu, kecepatan memperbarui kubus dan, pada akhirnya, kecepatan membangun dan memperbarui analitik dan laporan pengguna berdasarkan kubus tersebut akan melambat.
• Ketiga, terlalu banyak bidang (indikator dan bagian) akan menimbulkan masalah pada antarmuka pengembang OLAP, karena daftar elemennya akan menjadi sangat banyak.
• Keempat, Kubus OLAP sangat sensitif terhadap pelanggaran integritas data. Kubus tidak dapat dibangun jika data kunci tidak terletak pada tautan yang ditentukan dalam struktur koneksi bidang kubus. Pelanggaran integritas sementara atau permanen, bidang kosong sering terjadi dalam database sistem ERP, tetapi ini sama sekali tidak cocok untuk OLAP.

Anda juga dapat menambahkan bahwa sistem ERP dan kubus OLAP harus ditempatkan di server yang berbeda untuk berbagi beban. Tapi kemudian, jika ada tabel umum untuk OLAP dan OLTP, masalah lalu lintas jaringan juga muncul. Masalah yang praktis tidak terpecahkan muncul ketika perlu untuk mengkonsolidasikan beberapa sistem ERP yang berbeda (1C7, 1C8, MS Dynamics AX) ke dalam satu kubus OLAP.

Mungkin kita bisa terus menumpuk masalah teknis. Namun yang terpenting, ingatlah bahwa, tidak seperti OLTP, OLAP bukanlah alat untuk merekam dan menyimpan data, melainkan alat analisis. Artinya, tidak perlu mengunggah dan mengunduh data “kotor” dari ERP ke OLAP “untuk berjaga-jaga.” Sebaliknya, Anda harus terlebih dahulu mengembangkan konsep pengelolaan perusahaan, setidaknya pada tingkat sistem KPI, lalu merancang aplikasi gudang data (warehouse), yang terletak di server yang sama dengan kubus OLAP, dan berisi file kecil , menyempurnakan jumlah data dari ERP yang diperlukan untuk manajemen.

Tanpa promosi kebiasaan buruk, kubus OLAP dalam kaitannya dengan OLTP dapat disamakan dengan “kubus diam” yang terkenal, yang melaluinya “produk murni” diekstraksi dari “massa yang difermentasi” dari registrasi sebenarnya.

Jadi, kami mendapatkan bahwa sumber data untuk OLAP adalah database khusus (gudang) yang terletak di server yang sama dengan OLAP. Umumnya ini berarti dua hal. Pertama, harus ada prosedur khusus yang akan membuat gudang dari database ERP. Kedua, kubus OLAP tidak sinkron dengan sistem ERP-nya.

Dengan mempertimbangkan hal di atas, kami mengusulkan versi arsitektur proses komputasi berikut.

Arsitektur solusi

Misalkan ada banyak sistem ERP dari perusahaan (holding) tertentu yang berlokasi di server berbeda, data analitik yang ingin kita lihat digabungkan dalam satu kubus OLAP. Kami menekankan bahwa dalam teknologi yang dijelaskan, kami menggabungkan data dari sistem ERP di tingkat gudang, sehingga desain kubus OLAP tidak berubah.

Di server OLAP kami membuat gambar (salinan kosong) dari database semua sistem ERP ini. Kami secara berkala (setiap malam) melakukan replikasi parsial dari database ERP aktif yang sesuai ke salinan kosong ini.

Selanjutnya, SP (prosedur tersimpan) diluncurkan, yang, pada server OLAP yang sama tanpa lalu lintas jaringan, berdasarkan replika parsial database sistem ERP, membuat (atau mengisi ulang) gudang (gudang) - sumber data kubus OLAP.

Kemudian prosedur standar untuk memperbarui/membangun kubus berdasarkan data gudang diluncurkan (Proses operasi di antarmuka SSAS).

Mari mengomentari beberapa aspek teknologi. Pekerjaan apa yang dilakukan SP?

Sebagai hasil dari replikasi parsial, data terkini muncul dalam gambar beberapa sistem ERP di server OLAP. Omong-omong, replikasi parsial dapat dilakukan dengan dua cara.

Pertama, dari semua tabel di database sistem ERP, selama replikasi parsial, hanya tabel yang diperlukan untuk membangun gudang yang disalin. Ini dikendalikan oleh daftar nama tabel yang tetap.

Kedua, replikasi parsial juga dapat berarti bahwa tidak semua bidang tabel disalin, tetapi hanya bidang yang terlibat dalam pembangunan gudang. Daftar bidang yang akan disalin ditentukan atau dibuat secara dinamis di SP pada gambar salinan (jika tidak semua bidang awalnya ada dalam salinan tabel).

Tentu saja, dimungkinkan untuk tidak menyalin seluruh baris tabel, tetapi hanya menambahkan catatan baru. Namun, hal ini menciptakan ketidaknyamanan yang serius ketika memperhitungkan revisi ERP “secara surut,” yang sering terjadi dalam sistem kehidupan nyata. Jadi lebih mudah, tanpa basa-basi lagi, untuk menyalin semua catatan (atau memperbarui “ekor” mulai dari tanggal tertentu).

Selanjutnya tugas utama SP adalah mengkonversi data sistem ERP ke format gudang. Jika hanya ada satu sistem ERP, maka tugas konversi utamanya adalah menyalin dan mungkin memformat ulang data yang diperlukan. Namun jika Anda perlu mengkonsolidasikan beberapa sistem ERP dalam satu kubus OLAP yang sama struktur yang berbeda, maka transformasi menjadi lebih rumit.

Tugas mengkonsolidasikan beberapa sistem ERP yang berbeda dalam sebuah kubus sangat sulit jika kumpulan objeknya (direktori barang, kontraktor, gudang, dll.) sebagian tumpang tindih, objek tersebut memiliki arti yang sama, tetapi secara alami dijelaskan secara berbeda dalam direktori sistem yang berbeda(dalam arti kode, pengenal, nama, dll).

Kenyataannya, gambaran seperti itu muncul di perusahaan induk besar, ketika beberapa perusahaan otonom penyusunnya yang sejenis melakukan jenis kegiatan yang kurang lebih sama di wilayah yang kira-kira sama, tetapi menggunakan sistem pendaftaran mereka sendiri dan tidak disepakati. Dalam hal ini, ketika mengkonsolidasikan data di tingkat gudang, tabel pemetaan tambahan sangat diperlukan.

Mari kita perhatikan arsitektur penyimpanan gudang. Biasanya, skema kubus OLAP direpresentasikan dalam bentuk "bintang", yaitu. sebagai tabel data yang dikelilingi oleh "sinar" direktori - tabel nilai kunci sekunder. Tabel adalah blok “indikator”; buku referensi adalah bagiannya. Dalam hal ini, direktori, pada gilirannya, dapat berupa pohon tidak seimbang yang sewenang-wenang atau hierarki yang seimbang, misalnya, klasifikasi barang atau kontraktor bertingkat. Dalam kubus OLAP, bidang numerik tabel data dari gudang secara otomatis menjadi “indikator” (atau ukuran), dan bagian (atau dimensi) dapat ditentukan menggunakan tabel kunci sekunder.

Ini adalah deskripsi visual “pedagogis”. Faktanya, arsitektur kubus OLAP bisa jauh lebih kompleks.

Pertama, sebuah gudang dapat terdiri dari beberapa “bintang”, kemungkinan dihubungkan melalui direktori umum. Dalam hal ini, kubus OLAP akan menjadi gabungan dari beberapa kubus (beberapa blok data).

Kedua, "sinar" dari tanda bintang tidak hanya berupa satu direktori, tetapi seluruh sistem file (hierarki).

Ketiga, berdasarkan bagian dimensi yang ada, bagian hierarki baru dapat ditentukan menggunakan alat antarmuka pengembang OLAP (misalnya, dengan level yang lebih sedikit, dengan urutan level yang berbeda, dll.)

Keempat, berdasarkan indikator dan bagian yang ada, dengan menggunakan ekspresi bahasa MDX, indikator (perhitungan) baru dapat ditentukan. Penting untuk dicatat bahwa kubus baru, indikator baru, bagian baru secara otomatis terintegrasi penuh dengan elemen aslinya. Perlu juga dicatat bahwa perhitungan yang dirumuskan dengan buruk dan bagian hierarki dapat memperlambat pengoperasian kubus OLAP secara signifikan.

MS Excel sebagai antarmuka dengan OLAP

Yang menarik adalah antarmuka pengguna dengan kubus OLAP. Tentu saja, antarmuka terlengkap disediakan oleh utilitas SSAS itu sendiri. Ini termasuk toolkit pengembang kubus OLAP, perancang laporan interaktif, dan jendela untuk pekerjaan interaktif dengan kubus OLAP menggunakan kueri dalam bahasa MDX.

Selain SSAS itu sendiri, ada banyak program yang menyediakan antarmuka ke OLAP, mencakup fungsinya pada tingkat yang lebih besar atau lebih kecil. Namun di antara mereka ada satu yang menurut kami memiliki kelebihan yang tidak dapat disangkal. Ini adalah MS Excel.

Antarmuka dengan MS Excel disediakan oleh driver khusus, dapat diunduh secara terpisah atau disertakan dalam distribusi Excel. Ini tidak mencakup semua fungsi OLAP, tetapi dengan pertumbuhan nomor versi MS Excel, cakupan ini menjadi lebih luas (misalnya, di MS Excel 2007 muncul representasi grafis KPI, yang tidak ada di MS Excel 2003, dll. ).

Tentu saja, selain fungsinya yang cukup lengkap, keunggulan utama MS Excel adalah tersebar luasnya program ini dan akrab dengan sebagian besar pengguna kantoran. Dalam hal ini, tidak seperti program antarmuka lainnya, perusahaan tidak perlu membeli tambahan apa pun dan tidak perlu melatih siapa pun tambahan.

Keuntungan besar MS Excel sebagai antarmuka dengan OLAP adalah kemampuan untuk memproses lebih lanjut secara mandiri data yang diperoleh dalam laporan OLAP (yaitu, terus mempelajari data yang diperoleh dari OLAP pada lembar lain dari Excel yang sama, tidak lagi menggunakan alat OLAP, tetapi menggunakan alat Excel biasa).

Siklus perawatan malam Facubi

Sekarang kami akan menjelaskan siklus komputasi harian (setiap malam) dari operasi OLAP. Perhitungan dilakukan di bawah kendali program facubi, ditulis dalam C# 2005 dan diluncurkan melalui Penjadwal Tugas di server dengan gudang dan SSAS. Pada awalnya, facubi membuka Internet dan membaca nilai tukar saat ini (digunakan untuk mewakili sejumlah indikator dalam suatu mata uang). Selanjutnya, lakukan langkah-langkah berikut.

Pertama, facubi meluncurkan SP yang melakukan replikasi parsial database berbagai sistem ERP (elemen penahan) yang tersedia di jaringan lokal. Replikasi dilakukan, seperti yang kami katakan, ke "latar belakang" yang telah disiapkan sebelumnya - gambar sistem ERP jarak jauh yang terletak di server SSAS.

Kedua, melalui SP, pemetaan dilakukan dari replika ERP ke penyimpanan gudang - DB khusus, yang merupakan sumber data kubus OLAP dan terletak di server SSAS. Dalam hal ini, tiga tugas utama diselesaikan:

• data ERP disesuaikan dengan format kubus yang dibutuhkan; Kita berbicara tentang tabel dan bidang tabel. (Terkadang tabel yang diperlukan perlu "dibuat", misalnya, dari beberapa lembar MS Excel.) Data serupa mungkin memiliki format berbeda di ERP yang berbeda, misalnya, bidang ID kunci di direktori 1C7 memiliki kode karakter 36 digit dengan panjang 8 , dan bidang _idrref di direktori 1С8 – bilangan heksadesimal dengan panjang 32;
• selama pemrosesan kontrol data logis dilakukan (termasuk penulisan default sebagai pengganti data yang hilang, jika memungkinkan) dan kontrol integritas, yaitu. memeriksa keberadaan kunci primer dan sekunder di pengklasifikasi yang sesuai;
• konsolidasi kode objek yang memiliki arti yang sama di ERP yang berbeda. Misalnya, elemen direktori ERP yang berbeda mungkin memiliki arti yang sama, katakanlah, mereka adalah rekanan yang sama. Masalah konsolidasi kode diselesaikan dengan membuat tabel pemetaan, di mana kode-kode berbeda dari objek yang sama disatukan.

Ketiga, facubi meluncurkan prosedur standar untuk memperbarui data kubus Proses (dari prosedur utilitas SSAS).

Berdasarkan daftar periksa, facubi mengirimkan email tentang kemajuan langkah pemrosesan.

Setelah menjalankan facubi, Penjadwal Tugas meluncurkan beberapa file excel secara bergantian, di mana laporan telah dibuat sebelumnya berdasarkan indikator kubus OLAP. Seperti yang kami katakan, MS Excel memiliki antarmuka perangkat lunak khusus (driver yang dapat diunduh secara terpisah atau bawaan) untuk bekerja dengan kubus OLAP (dengan SSAS). Saat Anda memulai MS Excel, program MS VBA (seperti makro) diaktifkan, yang memastikan bahwa data dalam laporan diperbarui; laporan diubah jika perlu dan dikirim melalui surat (program blat) kepada pengguna sesuai dengan daftar periksa.

Pengguna jaringan lokal yang memiliki akses ke server SSAS akan menerima laporan "langsung" yang dikonfigurasi untuk kubus OLAP. (Pada prinsipnya, mereka sendiri, tanpa email apa pun, dapat memperbarui laporan OLAP di MS Excel yang terletak di komputer lokal mereka.) Pengguna di luar jaringan lokal akan menerima laporan asli, tetapi dengan fungsi terbatas, atau untuk mereka (setelah memperbarui OLAP laporan di MS Excel) laporan khusus “mati” yang tidak mengakses server SSAS akan dihitung.

Evaluasi hasil

Kami berbicara di atas tentang asinkronnya OLTP dan OLAP. Dalam varian teknologi yang dipertimbangkan, siklus pembaruan kubus OLAP dilakukan pada malam hari (misalnya, dimulai pada jam 1 pagi). Artinya pada hari kerja saat ini, pengguna sedang mengerjakan data kemarin. Karena OLAP bukanlah alat perekam (lihat revisi terbaru dokumen), namun alat manajemen (pahami tren proses), kelambatan seperti itu biasanya tidak kritis. Namun, jika perlu, bahkan dalam versi arsitektur kubus yang dijelaskan (MOLAP), pembaruan dapat dilakukan beberapa kali sehari.

Waktu pelaksanaan prosedur pembaruan bergantung pada fitur desain kubus OLAP (kompleksitas yang lebih besar, definisi indikator dan bagian yang kurang lebih berhasil) dan pada volume database sistem OLTP eksternal. Berdasarkan pengalaman, prosedur pembangunan gudang memakan waktu beberapa menit hingga dua jam, prosedur pembaruan kubus (Proses) memakan waktu 1 hingga 20 menit. Kita berbicara tentang kubus OLAP kompleks yang menyatukan lusinan struktur tipe bintang, lusinan “sinar” umum (bagian referensi), dan ratusan indikator. Saat memperkirakan volume database sistem ERP eksternal berdasarkan dokumen pengiriman, kita berbicara tentang ratusan ribu dokumen dan, karenanya, jutaan lini produk per tahun. Kedalaman pemrosesan historis yang menarik bagi pengguna adalah tiga hingga lima tahun.

Teknologi yang dijelaskan telah digunakan di sejumlah perusahaan besar: sejak 2008 di Perusahaan Ikan Rusia (RRK) dan Perusahaan Laut Rusia (RM), sejak 2012 di Perusahaan Santa Bremor (SB). Beberapa perusahaan pada dasarnya adalah perusahaan perdagangan dan pembelian (PPC), yang lain adalah perusahaan produksi (pabrik pengolahan ikan dan makanan laut di Republik Moldova dan Republik Belarus). Semua perusahaan adalah perusahaan besar yang menyatukan beberapa perusahaan dengan sistem akuntansi komputer yang independen dan beragam - mulai dari sistem ERP standar seperti 1C7 dan 1C8 hingga sistem akuntansi “peninggalan” berdasarkan DBF dan Excel. Saya akan menambahkan bahwa teknologi yang dijelaskan untuk mengoperasikan kubus OLAP (tanpa memperhitungkan tahap pengembangan) tidak memerlukan karyawan khusus sama sekali, atau merupakan tanggung jawab seorang analis bisnis penuh waktu. Tugas ini telah berjalan secara otomatis selama bertahun-tahun, memberikan laporan terkini setiap hari kepada berbagai kategori karyawan perusahaan.

Pro dan kontra dari solusi tersebut

Pengalaman menunjukkan bahwa solusi yang diusulkan cukup andal dan mudah digunakan. Hal ini mudah dimodifikasi (koneksi/pemutusan ERP baru, pembuatan indikator dan bagian baru, pembuatan dan modifikasi laporan Excel dan milisnya) dengan invarian dari program kontrol facubi.

MS Excel sebagai antarmuka dengan OLAP memberikan ekspresi yang cukup dan memungkinkan berbagai kategori karyawan kantor dengan cepat mengenal teknologi OLAP. Pengguna menerima laporan OLAP “standar” harian; menggunakan antarmuka MS Excel dengan OLAP, dapat secara mandiri membuat laporan OLAP di MS Excel. Selain itu, pengguna dapat terus mempelajari informasi laporan OLAP secara mandiri menggunakan kemampuan biasa MS Excel-nya.

Basis data gudang yang "disempurnakan", yang menggabungkan beberapa sistem ERP heterogen (selama konstruksi kubus), bahkan tanpa OLAP apa pun, memungkinkan Anda menyelesaikannya (di server SSAS, menggunakan metode kueri di Transact SQL atau metode SP , dll.) banyak masalah manajemen terapan. Mari kita ingat bahwa struktur database gudang terpadu dan lebih sederhana (dalam hal jumlah tabel dan jumlah bidang tabel) dibandingkan struktur database ERP asli.

Kami secara khusus mencatat bahwa dalam solusi yang kami usulkan terdapat kemungkinan untuk menggabungkan berbagai sistem ERP dalam satu kubus OLAP. Hal ini memungkinkan Anda memperoleh analitik untuk seluruh kepemilikan dan mempertahankan kesinambungan analitik jangka panjang ketika sebuah perusahaan berpindah ke sistem ERP akuntansi lain, misalnya, ketika berpindah dari 1C7 ke 1C8.

Kami menggunakan model kubus MOLAP. Keunggulan model ini adalah keandalan dalam pengoperasian dan kecepatan pemrosesan permintaan pengguna yang tinggi. Kekurangan: OLAP dan OLTP tidak sinkron, serta memori dalam jumlah besar untuk menyimpan OLAP.

Sebagai kesimpulan, berikut adalah argumen lain yang mendukung OLAP yang mungkin lebih tepat di Abad Pertengahan. Karena kekuatan pembuktiannya bertumpu pada kewenangan. Seorang matematikawan Inggris yang sederhana dan jelas diremehkan, E. Codd, mengembangkan teori database relasional di akhir tahun 60an. Kekuatan teori ini sedemikian rupa sehingga sekarang, setelah 50 tahun, sudah sulit untuk menemukan database non-relasional dan bahasa query database selain SQL.

Teknologi OLTP berdasarkan teori database relasional merupakan ide pertama E. Codd. Padahal, konsep kubus OLAP merupakan ide keduanya yang diungkapkannya di awal tahun 90an. Bahkan tanpa menjadi ahli matematika, Anda bisa berharap bahwa gagasan kedua akan sama efektifnya dengan gagasan pertama. Artinya, dalam hal analisis komputer, ide-ide OLAP akan segera mengambil alih dunia dan menggantikan ide-ide lainnya. Hanya karena topik analitik menemukan solusi matematisnya yang komprehensif di OLAP, dan solusi ini “memadai” (istilah B. Spinoza) untuk masalah praktis analitik. “Cukup” dalam Spinoza berarti bahwa Tuhan sendiri tidak dapat memikirkan hal lain yang lebih baik...

1. Larson B. Pengembangan analisis bisnis di Microsoft SQL Server 2005. – St. Petersburg: “Peter”, 2008.
2. Codd E. Kelengkapan Relasional Subbahasa Basis Data, Sistem Basis Data, Seri Sumposia Ilmu Komputer Courant 1972, v. 6, Tebing Englwood, NY, Prentice – Hall.

Dalam kontak dengan

Secara umum, setiap spesialis saat ini mengetahui apa itu OLAP. Setidaknya, konsep “OLAP” dan “data multidimensi” terhubung erat dalam pikiran kita. Namun demikian, topik ini diangkat kembali, saya harap, akan disetujui oleh sebagian besar pembaca, karena agar gagasan tentang sesuatu tidak menjadi ketinggalan zaman, Anda perlu berkomunikasi secara berkala dengan orang pintar atau membaca artikel di publikasi yang bagus...

Gudang data (tempat OLAP dalam struktur informasi perusahaan)

Istilah "OLAP" terkait erat dengan istilah "gudang data" (Data Warehouse).

Berikut adalah definisi yang dirumuskan oleh “bapak pendiri” data warehousing, Bill Inmon: “Data warehouse adalah kumpulan data yang spesifik domain, terikat waktu, dan tidak dapat diubah untuk mendukung pengambilan keputusan manajemen.”

Data di gudang berasal dari sistem operasional (sistem OLTP), yang dirancang untuk mengotomatisasi proses bisnis. Selain itu, repositori dapat diisi ulang dari sumber eksternal, seperti laporan statistik.

Mengapa membangun gudang data - lagipula, gudang tersebut berisi informasi yang jelas-jelas berlebihan yang sudah “hidup” di database atau file sistem operasi? Jawabannya bisa singkat: tidak mungkin atau sangat sulit menganalisis data secara langsung dari sistem operasi. Hal ini disebabkan oleh berbagai alasan, termasuk fragmentasi data, penyimpanannya dalam format DBMS yang berbeda dan di “sudut” berbeda jaringan perusahaan. Namun bahkan jika suatu perusahaan menyimpan semua datanya di server database pusat (yang sangat jarang terjadi), seorang analis hampir pasti tidak akan memahami strukturnya yang rumit dan terkadang membingungkan. Penulis memiliki pengalaman yang cukup menyedihkan saat mencoba “memberi makan” analis yang lapar dengan data “mentah” dari sistem operasional - ternyata “terlalu berlebihan bagi mereka”.

Dengan demikian, tujuan repositori adalah untuk menyediakan “bahan mentah” untuk analisis di satu tempat dan dalam struktur yang sederhana dan mudah dipahami. Ralph Kimball, dalam kata pengantar bukunya "The Data Warehouse Toolkit", menulis bahwa jika, setelah membaca keseluruhan buku, pembaca hanya memahami satu hal - yaitu, bahwa struktur gudang harus sederhana - penulis akan mempertimbangkannya tugas selesai.

Ada alasan lain yang membenarkan munculnya penyimpanan terpisah - permintaan analitis yang kompleks untuk informasi operasional memperlambat pekerjaan perusahaan saat ini, memblokir tabel untuk waktu yang lama dan menyita sumber daya server.

Menurut pendapat saya, repositori tidak selalu berarti akumulasi data yang sangat besar - yang utama adalah mudah untuk dianalisis. Secara umum, ada istilah terpisah untuk fasilitas penyimpanan kecil - Data Mart (kios data), tetapi dalam praktik kami di Rusia Anda jarang mendengarnya.

OLAP - alat analisis yang mudah digunakan

Sentralisasi dan penataan yang nyaman bukanlah segalanya yang dibutuhkan seorang analis. Ia masih membutuhkan alat untuk melihat dan memvisualisasikan informasi. Laporan tradisional, bahkan yang dibuat dalam satu repositori, kekurangan satu hal, yaitu fleksibilitas. Mereka tidak dapat "dipelintir", "diperluas" atau "diciutkan" untuk mendapatkan tampilan data yang diinginkan. Tentu saja, Anda dapat menghubungi seorang programmer (jika dia ingin datang), dan dia (jika dia tidak sibuk) akan membuat laporan baru dengan cukup cepat - katakanlah, dalam waktu satu jam (saya sedang menulis ini dan saya tidak percaya itu sendiri - itu tidak terjadi secepat itu dalam hidup; mari kita beri dia tiga jam). Ternyata seorang analis dapat menguji tidak lebih dari dua ide per hari. Dan dia (jika dia seorang analis yang baik) dapat memunculkan beberapa ide seperti itu dalam satu jam. Dan semakin banyak “potongan” dan “bagian” data yang dilihat oleh analis, semakin banyak ide yang dimilikinya, yang pada gilirannya memerlukan lebih banyak “potongan” untuk verifikasi. Andai saja dia memiliki alat yang memungkinkannya memperluas dan menciutkan data dengan mudah dan mudah! OLAP bertindak sebagai alat tersebut.

Meskipun OLAP bukan merupakan atribut penting dari gudang data, OLAP semakin banyak digunakan untuk menganalisis informasi yang terkumpul di gudang.

Komponen-komponen yang termasuk dalam repositori tipikal ditunjukkan pada Gambar. 1.

Beras. 1. Struktur gudang data

Data operasional dikumpulkan dari berbagai sumber, dibersihkan, diintegrasikan, dan disimpan dalam penyimpanan relasional. Selain itu, data tersebut sudah tersedia untuk dianalisis menggunakan berbagai alat pelaporan. Kemudian data (seluruhnya atau sebagian) disiapkan untuk analisis OLAP. Mereka dapat dimuat ke dalam database OLAP khusus atau disimpan dalam penyimpanan relasional. Elemen terpentingnya adalah metadata, yaitu informasi tentang struktur, penempatan, dan transformasi data. Berkat mereka, interaksi efektif berbagai komponen penyimpanan terjamin.

Ringkasnya, kita dapat mendefinisikan OLAP sebagai seperangkat alat untuk analisis multidimensi atas data yang terakumulasi di gudang. Secara teoritis, alat OLAP dapat diterapkan langsung ke data operasional atau salinan persisnya (agar tidak mengganggu pengguna operasional). Namun dengan demikian, kami mengambil risiko mengambil langkah yang telah dijelaskan di atas, yaitu mulai menganalisis data operasional yang secara langsung tidak sesuai untuk dianalisis.

Pengertian dan konsep dasar OLAP

Pertama, mari kita pahami: OLAP adalah Pemrosesan Analitik Online, yaitu analisis data operasional. 12 prinsip penentu OLAP dirumuskan pada tahun 1993 oleh E. F. Codd, “penemu” database relasional. Kemudian, definisinya direvisi menjadi apa yang disebut tes FASMI, yang mengharuskan aplikasi OLAP menyediakan kemampuan untuk menganalisis informasi multidimensi bersama dengan cepat ().

tes FASMI

Cepat(Cepat) - analisis harus dilakukan dengan cepat pada semua aspek informasi. Waktu respons yang dapat diterima adalah 5 detik atau kurang.

Analisis(Analisis) - tipe dasar analisis numerik dan statistik harus dapat dilakukan, yang telah ditentukan sebelumnya oleh pengembang aplikasi atau ditentukan secara bebas oleh pengguna.

Bersama(Dibagikan) - banyak pengguna harus memiliki akses ke data, sementara akses ke informasi rahasia perlu dikontrol.

Multidimensi(Multidimensi) adalah karakteristik OLAP yang utama dan paling penting.

Informasi(Informasi) - aplikasi harus dapat mengakses informasi apa pun yang diperlukan, berapa pun volume dan lokasi penyimpanannya.

OLAP = Tampilan Multidimensi = Kubus

OLAP menyediakan cara yang mudah dan cepat untuk mengakses, melihat, dan menganalisis informasi bisnis. Pengguna menerima model data yang alami dan intuitif, mengaturnya dalam bentuk kubus multidimensi (Cubes). Sumbu sistem koordinat multidimensi merupakan atribut utama dari proses bisnis yang dianalisis. Misalnya untuk penjualan bisa berupa produk, wilayah, jenis pembeli. Waktu digunakan sebagai salah satu dimensi. Di perpotongan sumbu - dimensi (Dimensi) - terdapat data yang secara kuantitatif mencirikan proses - ukuran (Measures). Ini bisa berupa volume penjualan dalam jumlah kecil atau dalam istilah moneter, saldo stok, biaya, dll. Pengguna yang menganalisis informasi dapat "memotong" kubus ke arah yang berbeda, mendapatkan ringkasan (misalnya, berdasarkan tahun) atau, sebaliknya, terperinci ( berdasarkan minggu ) informasi dan melakukan manipulasi lain yang terlintas dalam pikirannya selama proses analisis.

Seperti ukuran dalam kubus tiga dimensi yang ditunjukkan pada Gambar. 2, jumlah penjualan digunakan, dan waktu, produk, dan toko digunakan sebagai dimensi. Pengukuran disajikan pada tingkat pengelompokan tertentu: produk dikelompokkan berdasarkan kategori, toko berdasarkan negara, dan data waktu transaksi berdasarkan bulan. Nanti kita akan melihat tingkatan pengelompokan (hierarki) secara lebih rinci.

Beras. 2. Contoh kubus

"Memotong" sebuah kubus

Kubus tiga dimensi pun sulit ditampilkan di layar komputer sehingga nilai besaran yang diinginkan dapat terlihat. Apa yang dapat kita katakan tentang kubus yang lebih dari tiga dimensi? Untuk memvisualisasikan data yang disimpan dalam kubus, biasanya digunakan tampilan dua dimensi yang sudah dikenal, yaitu tabel, dengan judul baris dan kolom hierarki yang kompleks.

Representasi dua dimensi dari sebuah kubus dapat diperoleh dengan "memotongnya" pada satu atau lebih sumbu (dimensi): kita memperbaiki nilai semua dimensi kecuali dua, dan kita mendapatkan tabel dua dimensi biasa. Sumbu horizontal tabel (header kolom) mewakili satu dimensi, sumbu vertikal (header baris) mewakili dimensi lain, dan sel tabel mewakili nilai ukuran. Dalam hal ini, serangkaian ukuran sebenarnya dianggap sebagai salah satu dimensi - kita memilih satu ukuran untuk ditampilkan (dan kemudian kita dapat menempatkan dua dimensi dalam judul baris dan kolom), atau menampilkan beberapa ukuran (dan kemudian salah satu dari ukuran tersebut). sumbu tabel akan ditempati oleh nama ukuran, dan yang lainnya - nilai dari satu-satunya dimensi yang "tidak dipotong").

Lihatlah gambar. 3 - ini adalah potongan kubus dua dimensi untuk satu ukuran - Penjualan Unit (potongan terjual) dan dua dimensi "belum dipotong" - Toko (Store) dan Waktu (Waktu).

Beras. 3. Irisan kubus 2D untuk satu takaran

Pada Gambar. Gambar 4 hanya menunjukkan satu dimensi "belum dipotong" - Toko, tetapi menampilkan nilai dari beberapa ukuran - Penjualan Unit (unit terjual), Penjualan Toko (jumlah penjualan) dan Biaya Toko (biaya toko).

Beras. 4. Irisan kubus 2D untuk beberapa ukuran

Representasi dua dimensi dari sebuah kubus juga dimungkinkan jika lebih dari dua dimensi tetap “tidak dipotong”. Dalam hal ini, dua atau lebih dimensi kubus yang “dipotong” akan ditempatkan pada sumbu irisan (baris dan kolom) - lihat Gambar. 5.

Beras. 5. Irisan kubus 2D dengan beberapa dimensi pada satu sumbu

Tag

Nilai-nilai yang “diletakkan” sepanjang dimensi disebut anggota atau label. Label digunakan baik untuk "memotong" kubus dan untuk membatasi (memfilter) data yang dipilih - ketika dalam dimensi yang tetap "tidak dipotong" kita tidak tertarik pada semua nilai, tetapi pada subkumpulan nilai tersebut, misalnya, tiga kota dari beberapa lusin. Nilai label muncul dalam tampilan kubus 2D sebagai judul baris dan kolom.

Hierarki dan level

Label dapat digabungkan menjadi hierarki yang terdiri dari satu atau lebih level. Misalnya, label dimensi Penyimpanan secara alami dikelompokkan ke dalam hierarki dengan tingkatan:

Negara

Negara

Kota

Toko.

Nilai agregat dihitung berdasarkan tingkat hierarki, misalnya volume penjualan untuk Amerika Serikat (tingkat "Negara") atau untuk California (tingkat "Negara Bagian"). Dimungkinkan untuk menerapkan lebih dari satu hierarki dalam satu dimensi - misalnya, untuk waktu: (Tahun, Kuartal, Bulan, Hari) dan (Tahun, Minggu, Hari).

Arsitektur aplikasi OLAP

Segala sesuatu yang dikatakan di atas tentang OLAP pada dasarnya berkaitan dengan penyajian data multidimensi. Bagaimana data disimpan, secara kasar, tidak menjadi perhatian pengguna akhir atau pengembang alat yang digunakan klien.

Multidimensi dalam aplikasi OLAP dapat dibagi menjadi tiga tingkatan:

• Representasi data multidimensi - alat pengguna akhir yang menyediakan visualisasi multidimensi dan manipulasi data; Lapisan representasi multidimensi mengabstraksi struktur fisik data dan memperlakukan data sebagai multidimensi.
• Pemrosesan multidimensi adalah sarana (bahasa) untuk merumuskan kueri multidimensi (bahasa relasional tradisional SQL tidak cocok di sini) dan prosesor yang dapat memproses dan mengeksekusi kueri tersebut.
• Penyimpanan multidimensi adalah sarana pengorganisasian data secara fisik yang memastikan eksekusi kueri multidimensi yang efisien.

Dua level pertama wajib ada di semua alat OLAP. Tingkat ketiga, meskipun tersebar luas, tidak diperlukan, karena data untuk representasi multidimensi dapat diekstraksi dari struktur relasional biasa; Pemroses kueri multidimensi dalam hal ini menerjemahkan kueri multidimensi menjadi kueri SQL yang dijalankan oleh DBMS relasional.

Produk OLAP tertentu, biasanya, adalah alat representasi data multidimensi, klien OLAP (misalnya, Tabel Pivot di Excel 2000 dari Microsoft atau ProClarity dari Knosys), atau DBMS server multidimensi, server OLAP (misalnya, Oracle Server Ekspres atau Layanan Microsoft OLAP).

Lapisan pemrosesan multidimensi biasanya dibangun ke dalam klien OLAP dan/atau server OLAP, tetapi dapat diisolasi dalam bentuknya yang murni, seperti komponen Layanan Tabel Pivot Microsoft.

Aspek teknis penyimpanan data multidimensi

Seperti disebutkan di atas, alat analisis OLAP juga dapat mengekstrak data langsung dari sistem relasional. Pendekatan ini lebih menarik pada saat server OLAP tidak termasuk dalam daftar harga produsen DBMS terkemuka. Namun saat ini, Oracle, Informix, dan Microsoft menawarkan server OLAP yang lengkap, dan bahkan manajer TI yang tidak suka membuat "kebun binatang" perangkat lunak dari produsen berbeda di jaringan mereka dapat membeli (atau lebih tepatnya, membuat permintaan terkait ke manajemen perusahaan ) Server OLAP dengan merek yang sama dengan server database utama.

Server OLAP, atau server database multidimensi, dapat menyimpan data multidimensinya dengan cara yang berbeda. Sebelum mempertimbangkan metode ini, kita perlu membicarakan aspek penting seperti penyimpanan unit. Faktanya adalah bahwa di gudang data mana pun - baik biasa maupun multidimensi - bersama dengan data terperinci yang diambil dari sistem operasional, indikator ringkasan (indikator agregat, agregasi) juga disimpan, seperti jumlah volume penjualan per bulan, berdasarkan kategori barang, dll. Agregat disimpan secara eksplisit dengan tujuan mempercepat eksekusi query. Memang, di satu sisi, sebagai suatu peraturan, sejumlah besar data terakumulasi di gudang, dan di sisi lain, analis dalam banyak kasus tidak tertarik pada indikator terperinci, tetapi pada indikator umum. Dan jika jutaan penjualan individu harus dijumlahkan setiap kali untuk menghitung total penjualan untuk tahun tersebut, kemungkinan besar kecepatannya tidak dapat diterima. Oleh karena itu, ketika memuat data ke dalam database multidimensi, seluruh indikator total atau sebagiannya dihitung dan disimpan.

Tapi, seperti yang Anda tahu, Anda harus membayar semuanya. Dan untuk kecepatan pemrosesan permintaan data ringkasan, Anda harus membayar untuk peningkatan volume data dan waktu untuk memuatnya. Selain itu, peningkatan volume bisa menjadi bencana besar - dalam salah satu pengujian standar yang dipublikasikan, penghitungan agregat lengkap untuk 10 MB data awal memerlukan 2,4 GB, yaitu data bertambah 240 kali lipat! Derajat “pembengkakan” data saat menghitung agregat bergantung pada jumlah dimensi kubus dan struktur dimensi tersebut, yaitu rasio jumlah “ayah” dan “anak” pada tingkat pengukuran yang berbeda. Untuk mengatasi masalah penyimpanan unit, terkadang digunakan sirkuit yang kompleks, yang memungkinkan pencapaian peningkatan kinerja kueri yang signifikan saat menghitung tidak semua kemungkinan agregat.

Sekarang tentang berbagai pilihan untuk menyimpan informasi. Data granular dan agregat dapat disimpan dalam struktur relasional atau multidimensi. Penyimpanan multidimensi memungkinkan Anda memperlakukan data sebagai array multidimensi, yang memastikan penghitungan indikator total yang sama cepatnya dan berbagai transformasi multidimensi di sepanjang dimensi mana pun. Beberapa waktu lalu, produk OLAP mendukung penyimpanan relasional atau multidimensi. Saat ini, sebagai suatu peraturan, produk yang sama menyediakan kedua jenis penyimpanan ini, serta jenis penyimpanan ketiga - campuran. Ketentuan berikut ini berlaku:

• MOLAP(OLAP Multidimensi) - data detail dan agregat disimpan dalam database multidimensi. Dalam hal ini, redundansi terbesar diperoleh, karena data multidimensi berisi data relasional sepenuhnya.
• ROLAP(OLAP Relasional) - data terperinci tetap berada di tempat aslinya "berada" - dalam database relasional; agregat disimpan dalam database yang sama dalam tabel layanan yang dibuat khusus.
• TERSEMBUNYI(Hybrid OLAP) - data terperinci tetap ada (dalam database relasional), dan agregat disimpan dalam database multidimensi.

Masing-masing metode ini memiliki kelebihan dan kekurangannya masing-masing dan harus digunakan tergantung pada kondisi - volume data, kekuatan DBMS relasional, dll.

Saat menyimpan data dalam struktur multidimensi, terdapat potensi masalah "penggembungan" karena menyimpan nilai kosong. Lagi pula, jika dalam array multidimensi ruang dicadangkan untuk semua kemungkinan kombinasi label dimensi, namun hanya sebagian kecil yang benar-benar terisi (misalnya, sejumlah produk hanya dijual di sejumlah kecil wilayah), maka sebagian besar kubus akan kosong, meskipun ruang tersebut akan terisi. Produk OLAP modern dapat mengatasi masalah ini.

Bersambung. Di masa depan, kita akan berbicara tentang produk OLAP spesifik yang diproduksi oleh produsen terkemuka.

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. Mari kita cari tahu Untuk apa analis membutuhkan sesuatu yang istimewa memudahkan akses ke 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 fakta terpisah bahwa pada hari Kamis batch keempat tinta hitam dijual kepada rekanan Chernov - dia memerlukan informasi sekitar ratusan dan ribuan peristiwa serupa. Fakta tunggal dalam database mungkin menarik, misalnya, bagi akuntan atau kepala departemen penjualan, yang bertanggung jawab atas transaksi tersebut. Bagi seorang analis, satu catatan saja tidak cukup - dia, misalnya, mungkin memerlukan semua transaksi di cabang atau kantor perwakilan tertentu selama satu bulan atau satu tahun. Pada saat yang sama, analis membuang rincian yang tidak perlu seperti NPWP pembeli, alamat lengkap dan nomor teleponnya, indeks kontrak dan sejenisnya. Pada saat yang sama, data yang diperlukan oleh seorang analis untuk pekerjaannya harus berisi nilai numerik - hal ini disebabkan oleh esensi aktivitasnya.

Jadi, analis memerlukan data yang banyak, data ini bersifat selektif dan juga bersifat “ kumpulan atribut - nomor". Yang terakhir berarti analis bekerja dengan tabel jenis berikut:

Di Sini " Negara", "Produk", "Tahun" adalah atribut atau pengukuran, A " Volume penjualan" - dengan demikian nilai numerik atau ukuran. Tugas analis, kami ulangi, adalah mengidentifikasi hubungan yang kuat antara atribut dan parameter numerik. Melihat tabel tersebut, Anda akan melihat bahwa tabel tersebut dapat dengan mudah diubah menjadi tiga dimensi: kita akan menempatkan negara di salah satu sumbu, barang di sumbu lainnya, dan tahun di sumbu ketiga. Dan nilai dalam array tiga dimensi ini akan menjadi volume penjualan yang sesuai.

Representasi tabel tiga dimensi. Segmen abu-abu menunjukkan bahwa tidak ada data untuk Argentina pada tahun 1988

Array tiga dimensi inilah yang disebut kubus dalam istilah OLAP. Faktanya, dari sudut pandang matematika yang ketat, array seperti itu tidak selalu berupa kubus: kubus nyata harus memiliki jumlah elemen yang sama di semua dimensi, tetapi kubus OLAP tidak memiliki batasan seperti itu. Namun, terlepas dari rincian ini, istilah “kubus OLAP”, karena singkatnya dan kiasannya, telah diterima secara umum. Kubus OLAP tidak harus berbentuk tiga dimensi. Ini bisa bersifat dua dimensi dan multidimensi, tergantung pada masalah yang dipecahkan. Analis yang sangat berpengalaman mungkin memerlukan sekitar 20 dimensi - dan produk OLAP yang serius dirancang untuk jumlah tersebut. Aplikasi desktop yang lebih sederhana mendukung sekitar 6 dimensi.

Pengukuran Kubus OLAP terdiri dari apa yang disebut tanda atau anggota. Misalnya, dimensi Negara terdiri dari label Argentina, Brazil, Venezuela, dan sebagainya.

Tidak semua elemen kubus harus diisi: jika tidak ada informasi tentang penjualan produk karet di Argentina pada tahun 1988, nilai pada sel yang bersangkutan tidak akan ditentukan. Aplikasi OLAP juga tidak perlu menyimpan data dalam struktur multidimensi - yang utama adalah data ini terlihat persis seperti ini bagi pengguna. Omong-omong, justru metode khusus penyimpanan kompak data multidimensi yang “vakum” (elemen tidak terisi) dalam kubus tidak menyebabkan pemborosan memori.

Namun, kubus itu sendiri tidak cocok untuk dianalisis. Jika masih memungkinkan untuk membayangkan atau menggambarkan kubus tiga dimensi secara memadai, maka dengan kubus enam atau sembilan belas dimensi situasinya jauh lebih buruk. Itu sebabnya sebelum digunakan yang biasa diekstraksi dari kubus multidimensi tabel dua dimensi. Operasi ini disebut "memotong" kubus. Istilah ini, sekali lagi, bersifat kiasan. Analis seolah-olah mengambil dan “memotong” dimensi kubus sesuai dengan tanda yang dia minati. Dengan cara ini, analis menerima potongan kubus dua dimensi dan mengerjakannya. Dengan cara yang hampir sama, penebang pohon menghitung lingkaran tahunan pada pohon yang ditebang.

Oleh karena itu, sebagai suatu peraturan, hanya dua dimensi yang tetap “belum dipotong” - sesuai dengan jumlah dimensi dalam tabel. Kebetulan hanya satu dimensi yang tetap "tidak dipotong" - jika kubus berisi beberapa jenis nilai numerik, nilai tersebut dapat diplot di sepanjang salah satu dimensi tabel.

Jika Anda melihat lebih dekat tabel yang kami gambarkan pertama kali, Anda akan melihat bahwa data di dalamnya kemungkinan besar bukan data primer, tetapi diperoleh sebagai hasil. penjumlahan pada elemen yang lebih kecil. Misalnya, satu tahun dibagi menjadi empat perempat, empat perempat menjadi bulan, bulan menjadi minggu, minggu menjadi hari. Suatu negara terdiri dari wilayah-wilayah, dan wilayah terdiri dari wilayah-wilayah berpenduduk. Terakhir, di kota itu sendiri, distrik dan gerai ritel tertentu dapat diidentifikasi. Produk dapat digabungkan menjadi kelompok produk dan sebagainya. Dalam istilah OLAP, asosiasi multi-level seperti itu disebut secara logis hierarki. Alat OLAP memungkinkan untuk berpindah ke tingkat hierarki yang diinginkan kapan saja. Selain itu, sebagai aturan, beberapa jenis hierarki didukung untuk elemen yang sama: misalnya, hari-minggu-bulan atau hari-dekade-kuartal. Sumber data diambil dari hierarki tingkat yang lebih rendah kemudian dijumlahkan untuk memperoleh nilai pada tingkat yang lebih tinggi. Untuk mempercepat proses transisi, nilai penjumlahan untuk level yang berbeda disimpan dalam sebuah kubus. Jadi, apa yang tampak seperti satu kubus dari sisi pengguna, secara kasar, terdiri dari lebih banyak kubus primitif.

Contoh hierarki

Inilah salah satu poin penting yang menyebabkan munculnya OLAP – 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, peningkatan badai, serangan jantung dan stroke, dan sebagainya. . 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. Artinya, jika awalnya data kami berisi informasi tentang pendapatan harian untuk produk tertentu di satu toko, kemudian ketika membentuk kubus, aplikasi OLAP menghitung total untuk berbagai tingkat hierarki (minggu dan bulan, kota dan negara).

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

Jawablah pertanyaan:

Apa yang terjadi kubus OLAP?

Apa yang terjadi tag pengukuran tertentu? Berikan contoh.

Bisakah mereka Pengukuran dalam kubus OLAP, berisi nilai non-numerik.