Olap untuk perusahaan kecil. Desain kubus data

Sebagai bagian dari pekerjaan ini, pertanyaan-pertanyaan berikut akan dipertimbangkan:

  • Apa itu kubus OLAP?
  • Apa itu ukuran, dimensi, hierarki?
  • Jenis operasi apa yang dapat dilakukan pada kubus OLAP?
Konsep kubus OLAP

Postulat utama OLAP adalah multidimensi dalam penyajian data. Dalam terminologi OLAP, konsep kubus, atau hypercube, digunakan untuk mendeskripsikan ruang data diskrit multidimensi.

kubus adalah struktur data multidimensi dari mana pengguna analis dapat meminta informasi. Kubus dibuat dari fakta dan dimensi.

Data- ini adalah data tentang objek dan peristiwa di perusahaan yang akan dianalisis. Fakta dari tipe yang sama membentuk ukuran. Ukuran adalah jenis nilai dalam sel kubus.

pengukuran adalah elemen data tempat analisis fakta dilakukan. Kumpulan elemen semacam itu membentuk atribut dimensi (misalnya, hari dalam seminggu dapat membentuk atribut dimensi "waktu"). Dalam tugas analisis bisnis perusahaan komersial, kategori seperti "waktu", "penjualan", "produk", "pelanggan", "karyawan", "lokasi geografis" sering bertindak sebagai pengukuran. Dimensi paling sering adalah struktur hierarkis yang merupakan kategori logis yang dengannya pengguna dapat menganalisis data aktual. Setiap hierarki dapat memiliki satu atau lebih level. Jadi hierarki dimensi "letak geografis" dapat mencakup tingkatan: "negara - wilayah - kota". Dalam hierarki waktu, misalnya, urutan level berikut dapat dibedakan: Sebuah dimensi dapat memiliki beberapa hierarki (dalam hal ini, setiap hierarki dari satu dimensi harus memiliki atribut kunci yang sama dari tabel dimensi).

Kubus dapat berisi data aktual dari satu atau lebih tabel fakta, dan paling sering berisi beberapa dimensi. Setiap kubus tertentu biasanya memiliki subjek analisis arah tertentu.

Gambar 1 menunjukkan contoh kubus yang dirancang untuk menganalisis penjualan produk minyak oleh perusahaan tertentu berdasarkan wilayah. Kubus ini memiliki tiga dimensi (waktu, produk, dan wilayah) dan satu ukuran (nilai penjualan dinyatakan dalam istilah moneter). Nilai ukuran disimpan dalam sel (sel) kubus yang sesuai. Setiap sel secara unik diidentifikasi oleh satu set anggota dari masing-masing dimensi, yang disebut tupel. Misalnya, sel yang terletak di pojok kiri bawah kubus (berisi nilai $98399) diberikan oleh tuple [Juli 2005, Far East, Diesel]. Di sini nilai $98399 menunjukkan volume penjualan (dalam satuan moneter) solar di Timur Jauh pada Juli 2005.

Perhatikan juga bahwa beberapa sel tidak berisi nilai apa pun: sel ini kosong karena tabel fakta tidak berisi data untuknya.

Beras. 1. Cube dengan informasi tentang penjualan produk minyak bumi di berbagai daerah

Tujuan akhir pembuatan kubus tersebut adalah untuk meminimalkan waktu pemrosesan kueri yang mengekstrak informasi yang diperlukan dari data aktual. Untuk menyelesaikan tugas ini, kubus biasanya berisi data ringkasan yang telah dihitung sebelumnya yang disebut agregasi(agregasi). Itu. kubus mencakup ruang data yang lebih besar dari yang sebenarnya - ada poin yang logis dan dihitung di dalamnya. Fungsi agregat memungkinkan Anda menghitung nilai titik dalam ruang logis berdasarkan nilai sebenarnya. Fungsi agregasi yang paling sederhana adalah SUM, MAX, MIN, COUNT. Jadi, misalnya, dengan menggunakan fungsi MAX, untuk kubus yang ditunjukkan pada contoh, Anda dapat mengidentifikasi kapan puncak penjualan solar terjadi di Timur Jauh, dll.

Ciri khusus lain dari kubus multidimensi adalah sulitnya menentukan titik asal. Misalnya, bagaimana Anda menetapkan titik 0 untuk dimensi Produk atau Wilayah? Solusi untuk masalah ini adalah dengan memperkenalkan atribut khusus yang menggabungkan semua elemen dimensi. Atribut ini (dihasilkan secara otomatis) hanya berisi satu elemen - Semua ("Semua"). Untuk fungsi agregasi sederhana seperti penjumlahan, Semua elemen setara dengan jumlah nilai semua elemen dalam ruang aktual dari dimensi yang diberikan.

Konsep penting dalam model data multidimensi adalah subruang, atau subkubus. Subkubus adalah bagian dari total ruang kubus dalam bentuk beberapa figur multidimensi di dalam kubus. Karena ruang multidimensi sebuah kubus adalah diskrit dan dibatasi, subkubusnya juga diskrit dan dibatasi.

Operasi pada kubus OLAP

Operasi berikut dapat dilakukan pada kubus OLAP:

  • memotong;
  • rotasi;
  • konsolidasi;
  • detail.
mengiris(Gambar 2) adalah kasus khusus dari subkubus. Ini adalah prosedur untuk membentuk subset dari array data multidimensi yang sesuai dengan nilai tunggal dari satu atau lebih elemen dimensi yang tidak termasuk dalam subset ini. Misalnya, untuk mengetahui bagaimana penjualan produk minyak berkembang dari waktu ke waktu hanya di wilayah tertentu, yaitu di Ural, Anda perlu memperbaiki dimensi "Barang" pada elemen "Ural" dan mengekstrak subset (subkubus) yang sesuai dari kubus.
  • 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 penukaran baris dan kolom tabel. Selain itu, memutar kubus data berarti memindahkan dimensi non-tabel ke lokasi dimensi yang ada di halaman yang ditampilkan, dan sebaliknya.

    OLAP bukanlah produk perangkat lunak tunggal, bukan bahasa pemrograman, dan bahkan bukan teknologi tertentu. Jika Anda mencoba untuk menutupi OLAP dalam semua manifestasinya, maka ini adalah sekumpulan konsep, prinsip, dan persyaratan yang mendasari produk perangkat lunak yang memudahkan analis untuk mengakses data. Ayo cari tahu Untuk apa analis membutuhkan sesuatu yang istimewa memudahkan akses data.

    Faktanya adalah bahwa analis adalah konsumen khusus informasi perusahaan. Tugas seorang analis adalah menemukan pola dalam kumpulan data besar. Oleh karena itu, analis tidak akan memperhatikan satu fakta bahwa pada hari Kamis hari keempat sejumlah tinta hitam dijual ke rekanan Chernov - dia membutuhkan informasi sekitar ratusan dan ribuan acara serupa. Fakta tunggal dalam database mungkin menarik, misalnya, bagi seorang akuntan atau kepala departemen penjualan, yang kompetensinya adalah transaksi tersebut. Satu catatan tidak cukup untuk seorang analis - misalnya, dia mungkin memerlukan semua transaksi dari cabang atau kantor perwakilan tertentu selama satu bulan atau satu tahun. Pada saat yang sama analis membuang detail yang tidak perlu seperti NPWP pembeli, alamat persisnya dan nomor teleponnya, indeks kontrak dan sejenisnya. Pada saat yang sama, data yang dibutuhkan seorang analis untuk bekerja harus mengandung nilai numerik - ini karena inti dari aktivitasnya.

    Jadi, seorang analis membutuhkan banyak data, data ini bersifat selektif dan juga bersifat “ set atribut - nomor". Yang terakhir berarti analis bekerja dengan tabel dari jenis berikut:

    Di Sini " Negara", "Produk", "Tahun" adalah atribut atau pengukuran, A " Volume penjualan" - jadi nilai numerik atau ukuran. Tugas analis, kami ulangi, adalah mengidentifikasi hubungan persisten antara atribut dan parameter numerik.. Melihat tabel, Anda dapat melihat bahwa itu dapat dengan mudah diterjemahkan ke dalam tiga dimensi: di salah satu sumbu kami menempatkan negara, di sisi lain - barang, di tahun ketiga. Dan nilai dalam larik tiga dimensi ini akan menjadi volume penjualan yang sesuai.

    Representasi 3D dari tabel. Segmen abu-abu menunjukkan bahwa tidak ada data untuk Argentina pada tahun 1988

    Justru array tiga dimensi dalam istilah OLAP itulah yang disebut kubus. Faktanya, dari sudut pandang matematika yang ketat, larik seperti itu tidak selalu berupa kubus: untuk kubus nyata, jumlah elemen di semua dimensi harus sama, sedangkan kubus OLAP tidak memiliki batasan seperti itu. Namun, terlepas dari perincian ini, istilah "kubus OLAP", karena singkatnya dan pencitraannya, telah diterima secara umum. Kubus OLAP tidak harus 3D sama sekali. Itu bisa dua dimensi dan multidimensi, tergantung pada masalah yang dipecahkan. Analis yang sangat berpengalaman mungkin memerlukan sekitar 20 pengukuran - dan produk OLAP yang serius dirancang hanya untuk angka seperti itu. 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", "Brasil", "Venezuela", dan seterusnya.

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

    Namun, kubus itu sendiri tidak cocok untuk dianalisis. Jika masih memungkinkan untuk merepresentasikan atau menggambarkan kubus tiga dimensi secara memadai, maka dengan enam atau sembilan belas dimensi situasinya jauh lebih buruk. Itu sebabnya sebelum digunakan kubus biasa diekstraksi dari kubus multidimensi tabel dua dimensi. Operasi ini disebut "memotong" kubus. Sekali lagi, istilah ini kiasan. Analis, seolah-olah, mengambil dan "memotong" dimensi kubus sesuai dengan tanda yang menarik baginya. Dengan cara ini, analis menerima potongan kubus dua dimensi dan bekerja dengannya. Dengan cara yang hampir sama, penebang menghitung cincin tahunan pada potongan gergaji.

    Karenanya, sebagai aturan, hanya dua dimensi yang tetap "tidak dipotong" - sesuai dengan jumlah dimensi tabel. Kebetulan hanya dimensi yang tetap "tidak dipotong" - jika kubus berisi beberapa jenis nilai numerik, nilai tersebut dapat diplot sesuai dengan salah satu dimensi tabel.

    Jika Anda melihat lebih dekat pada tabel yang kami gambarkan pertama kali, Anda dapat melihat bahwa data di dalamnya kemungkinan besar bukan yang utama, tetapi diperoleh sebagai hasil dari penjumlahan untuk barang yang lebih kecil. Misalnya, satu tahun dibagi menjadi kuartal, kuartal menjadi bulan, bulan menjadi minggu, minggu menjadi hari. Suatu negara terdiri dari daerah, dan daerah terdiri dari daerah. Terakhir, di kota itu sendiri, distrik dan gerai ritel tertentu dapat dibedakan. Produk dapat digabungkan menjadi kelompok produk dan seterusnya. Dalam istilah OLAP, gabungan bertingkat seperti itu disebut cukup logis hierarki. Alat OLAP memungkinkan kapan saja untuk berpindah ke tingkat hierarki yang diinginkan. Selain itu, sebagai aturan, beberapa jenis hierarki didukung untuk elemen yang sama: misalnya, hari-minggu-bulan atau hari-dekade-kuartal. Sumber data diambil dari tingkat hierarki yang lebih rendah dan kemudian diringkas untuk mendapatkan nilai dari 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 Hirarki

    Inilah salah satu poin penting yang menyebabkan munculnya OLAP - produktivitas dan efisiensi. Bayangkan apa yang terjadi ketika seorang analis perlu mendapatkan informasi, dan alat OLAP tidak tersedia di perusahaan. Analis secara mandiri (yang tidak mungkin) atau dengan bantuan programmer membuat kueri SQL yang sesuai dan menerima data yang menarik dalam bentuk laporan atau mengekspornya ke spreadsheet. Ada banyak masalah dengan ini. Pertama, analis dipaksa untuk melakukan sesuatu selain pekerjaannya (pemrograman SQL) atau menunggu pemrogram melakukan tugas untuknya - semua ini berdampak negatif pada produktivitas tenaga kerja, penyerangan, serangan jantung dan peningkatan tingkat stroke, dan sebagainya. . Kedua, satu laporan atau tabel, sebagai aturan, tidak menyelamatkan para raksasa pemikiran dan bapak analisis Rusia - dan seluruh prosedur harus diulangi lagi dan lagi. Ketiga, seperti yang telah kami ketahui, analis tidak meminta hal-hal sepele - mereka membutuhkan semuanya sekaligus. Ini berarti (walaupun teknologinya berkembang pesat) bahwa server database relasional perusahaan yang diakses oleh analis dapat berpikir secara mendalam dan untuk waktu yang lama, memblokir sisa transaksi.

    Konsep OLAP muncul justru untuk mengatasi masalah tersebut. Kubus OLAP pada dasarnya adalah laporan meta. Dengan memotong laporan-meta (kubus, yaitu) berdasarkan dimensi, analis sebenarnya menerima laporan dua dimensi "biasa" yang menarik baginya (ini belum tentu laporan dalam pengertian istilah yang biasa - kita berbicara tentang struktur data dengan fungsi yang sama). Keuntungan kubus sangat jelas - data hanya perlu diminta dari DBMS relasional sekali - saat membuat kubus. Karena analis biasanya tidak bekerja dengan informasi yang ditambahkan dan diubah dengan cepat, kubus yang dihasilkan relevan untuk waktu yang cukup lama. Berkat ini, gangguan dalam pengoperasian server DBMS relasional tidak hanya dihilangkan (tidak ada kueri dengan ribuan dan jutaan jalur respons), tetapi kecepatan akses data untuk analis itu sendiri juga meningkat secara dramatis. Selain itu, seperti yang telah disebutkan, kinerja juga ditingkatkan dengan menghitung subsum hierarki dan nilai agregat lainnya pada saat konstruksi kubus. Artinya, jika awalnya data kami berisi informasi tentang pendapatan harian untuk produk tertentu di satu toko, maka saat membentuk kubus, aplikasi OLAP menghitung total untuk berbagai tingkat hierarki (minggu dan bulan, kota dan negara).

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

    Jawablah pertanyaan:

      Apa yang terjadi kubus OLAP?

      Apa yang terjadi label dimensi tertentu? Berikan contoh.

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

    Sistem informasi perusahaan yang serius, sebagai aturan, berisi aplikasi yang dirancang untuk analisis data yang kompleks, dinamika, tren, dll. Dengan demikian, manajemen puncak menjadi konsumen utama dari hasil analisis. Analisis tersebut pada akhirnya dimaksudkan untuk memudahkan pengambilan keputusan. Dan untuk membuat keputusan manajemen apa pun, perlu memiliki informasi yang diperlukan untuk ini, biasanya kuantitatif. Untuk melakukan ini, perlu mengumpulkan data ini dari semua sistem Informasi perusahaan, mengarah ke format umum dan baru kemudian menganalisis. Untuk melakukan ini, buat gudang data (Data Warehouses).

    Apa itu gudang data?

    Biasanya - tempat pengumpulan semua informasi yang bernilai analitik. Persyaratan untuk penyimpanan tersebut mengikuti definisi klasik OLAP dan akan dijelaskan di bawah ini.

    Terkadang Gudang memiliki tujuan lain - integrasi semua data perusahaan, untuk menjaga integritas dan relevansi informasi dalam semua sistem informasi. Itu. repositori mengakumulasi tidak hanya analitik, tetapi hampir semua informasi, dan dapat menerbitkannya dalam bentuk direktori kembali ke sistem lain.

    Gudang data tipikal biasanya berbeda dari database relasional tipikal. Pertama, basis data konvensional dirancang untuk membantu pengguna melakukan pekerjaan sehari-hari, sedangkan gudang data dirancang untuk membuat keputusan. Misalnya, menjual produk dan mengeluarkan faktur dilakukan menggunakan database yang dirancang untuk memproses transaksi, dan menganalisis dinamika penjualan selama beberapa tahun, yang memungkinkan Anda merencanakan pekerjaan dengan pemasok menggunakan gudang data.

    Kedua, basis data reguler tunduk pada perubahan konstan selama pekerjaan pengguna, dan gudang data relatif stabil: data di dalamnya biasanya diperbarui sesuai jadwal (misalnya, mingguan, harian, atau per jam, tergantung pada kebutuhan). Idealnya, proses pengisian ulang hanya menambahkan data baru selama periode waktu tertentu tanpa mengubah informasi lama yang sudah tersimpan.

    Dan, ketiga, database konvensional paling sering menjadi sumber data yang masuk ke repositori. Selain itu, repositori dapat diisi ulang dari sumber eksternal, seperti laporan statistik.

    Bagaimana penyimpanan dibuat?

    ETL– konsep dasar: Tiga tahap:
    • Ekstraksi - mengekstraksi data dari sumber eksternal dalam format yang dapat dimengerti;
    • Transformasi - transformasi struktur data sumber menjadi struktur yang nyaman untuk membangun sistem analitik;
    Mari tambahkan satu tahap lagi - pembersihan data ( pembersihan) - proses menyaring data yang tidak relevan atau mengoreksi kesalahan berdasarkan metode statistik atau pakar. Agar tidak menghasilkan laporan selanjutnya seperti "Penjualan 20011".

    Mari kita kembali ke analisis.

    Apa itu analisis dan mengapa itu dibutuhkan?

    Analisis adalah studi tentang data untuk membuat keputusan. Sistem analitik disebut demikian - sistem pendukung keputusan ( DSS).

    Di sini perlu ditunjukkan perbedaan antara bekerja dengan DSS dan sekumpulan sederhana laporan yang diatur dan tidak diatur. Analisis dalam DSS hampir selalu bersifat interaktif dan iteratif. Itu. analis menggali data, menyusun dan mengoreksi kueri analitik, dan menerima laporan, yang strukturnya mungkin tidak diketahui sebelumnya. Kami akan kembali ke hal ini secara lebih mendetail di bawah saat kami membahas bahasa kueri. MDX.

    OLAP

    Sistem pendukung keputusan biasanya memiliki sarana untuk menyediakan pengguna dengan data agregat untuk berbagai sampel dari kumpulan awal dalam bentuk yang sesuai untuk persepsi dan analisis (tabel, bagan, dll.). Pendekatan tradisional segmentasi data sumber menggunakan pemilihan satu atau lebih set data multidimensi (sering disebut hypercube atau metacube) dari data sumber, sumbu yang berisi atribut, dan sel berisi data kuantitatif agregat. (Selain itu, data semacam itu dapat disimpan dalam tabel relasional, tetapi dalam hal ini kita berbicara tentang organisasi data yang logis, dan bukan tentang implementasi fisik penyimpanannya.) Sepanjang setiap sumbu, atribut dapat diatur sebagai hierarki yang mewakili tingkat yang berbeda detail. Berkat model data ini, pengguna dapat merumuskan kueri kompleks, membuat laporan, dan menerima subkumpulan data.

    Teknologi analisis data multidimensi yang kompleks disebut OLAP (On-Line Analytical Processing). OLAP adalah komponen kunci dari pergudangan data tradisional. Konsep OLAP dijelaskan pada tahun 1993 oleh Edgar Codd, seorang peneliti database terkenal dan penulis model data relasional. Pada tahun 1995, berdasarkan persyaratan yang digariskan oleh Codd, apa yang disebut tes FASMI (Analisis Cepat Informasi Multidimensi Bersama - 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 khusus untuk aplikasi ini, dan menyimpannya dalam bentuk yang dapat diakses oleh pengguna akhir;
    • akses multi-pengguna ke data dengan dukungan untuk mekanisme penguncian yang sesuai dan alat akses resmi;
    • representasi data konseptual multidimensi, termasuk dukungan penuh untuk hierarki dan banyak hierarki (ini adalah persyaratan utama OLAP);
    • kemampuan untuk mengakses informasi yang diperlukan, terlepas dari 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. Itu. OLAP bukan teknologi, tapi ideologi.

    Sebelum berbicara tentang berbagai implementasi OLAP, mari kita lihat lebih dekat apa itu kubus dari sudut pandang logika.

    Konsep multidimensi

    Kami akan menggunakan database Northwind yang disertakan dengan Microsoft untuk mengilustrasikan prinsip OLAP. Server SQL dan yang merupakan database tipikal yang menyimpan informasi tentang operasi perdagangan perusahaan yang bergerak di bidang pasokan makanan grosir. Data tersebut meliputi informasi tentang pemasok, pelanggan, daftar barang yang dipasok dan kategorinya, data pesanan dan barang pesanan, daftar karyawan perusahaan.

    kubus

    Mari kita ambil contoh tabel Faktur1, yang berisi pesanan perusahaan. Bidang dalam tabel ini akan menjadi sebagai berikut:
    • Tanggal pemesanan
    • Negara
    • Kota
    • Nama Pelanggan
    • Perusahaan pengantar
    • Nama Produk
    • Jumlah barang
    • Harga pesanan
    Data agregat apa yang bisa kita dapatkan berdasarkan tampilan ini? Biasanya ini adalah jawaban untuk pertanyaan seperti:
    • Berapa nilai total pesanan yang dilakukan oleh pelanggan dari negara tertentu?
    • Berapa total biaya pesanan yang dilakukan oleh pelanggan dari negara tertentu dan dikirim oleh perusahaan tertentu?
    • Berapa nilai total pesanan yang dilakukan oleh pelanggan dari negara tertentu pada tahun tertentu dan dikirim oleh perusahaan tertentu?
    Semua data ini dapat diperoleh dari tabel ini dengan kueri SQL yang cukup jelas dengan pengelompokan.

    Hasil kueri ini akan selalu berupa kolom angka dan daftar atribut yang mendeskripsikannya (misalnya, negara) - ini adalah kumpulan data satu dimensi atau, dalam istilah matematika, vektor.

    Bayangkan kita perlu mendapatkan informasi tentang total biaya pesanan dari semua negara dan distribusinya oleh perusahaan operator - kita sudah mendapatkan tabel (matriks) angka, di mana header kolom akan mencantumkan operator, header baris akan berisi negara , dan sel akan berisi jumlah pesanan. Ini adalah array data dua dimensi. Kumpulan data seperti itu disebut tabel pivot ( tabel pivot) atau tab silang.

    Jika kita ingin mendapatkan data yang sama, tetapi dalam konteks tahun, maka akan ada satu perubahan lagi, yaitu. kumpulan data akan menjadi tiga dimensi (tensor bersyarat urutan ke-3 atau "kubus" 3 dimensi).

    Jelas, jumlah maksimum dimensi adalah jumlah semua atribut (Tanggal, Negara, Pelanggan, dll.) yang menggambarkan data gabungan kami (jumlah pesanan, jumlah barang, dll.).

    Jadi kita sampai pada konsep multidimensi dan perwujudannya - kubus multidimensi. Tabel ini akan dipanggil tabel fakta". Dimensi atau Sumbu Kubus ( ukuran) adalah atribut yang koordinatnya dinyatakan oleh nilai individu dari atribut yang ada di tabel fakta. Itu. misalnya, jika informasi tentang pesanan disimpan dalam sistem dari tahun 2003 hingga 2010, sumbu tahun ini akan terdiri dari 8 titik yang sesuai. Jika pesanan datang dari tiga negara, maka sumbu negara akan berisi 3 titik, dan seterusnya. Terlepas dari berapa banyak negara yang termasuk dalam Direktori Negara. Titik-titik pada sumbu disebut "anggota" ( Anggota).

    Data agregat itu sendiri dalam hal ini akan disebut "ukuran" ( ukuran). Untuk menghindari kebingungan dengan "dimensi", lebih baik menyebut yang terakhir sebagai "sumbu". Serangkaian ukuran membentuk sumbu "Ukuran" lainnya ( Pengukuran). Ini memiliki anggota (poin) sebanyak jumlah pengukuran (kolom gabungan) dalam tabel fakta.

    Anggota dimensi atau sumbu dapat dikelompokkan bersama dalam satu atau lebih hierarki ( hirarki). Mari kita jelaskan apa itu hierarki dengan sebuah contoh: kota-kota dari urutan dapat digabungkan menjadi distrik, distrik di suatu wilayah, wilayah suatu negara, negara menjadi benua atau entitas lain. Itu. ada struktur hierarkis - benua negara-wilayah-kabupaten-kota– 5 tingkat ( Tingkat). Untuk kabupaten, data dikumpulkan untuk semua kota yang termasuk di dalamnya. Untuk area untuk semua distrik yang memuat semua kota, dll. Mengapa kita membutuhkan banyak hierarki? Misalnya, pada sumbu tanggal pesanan, kita mungkin ingin mengelompokkan poin (yaitu hari) dalam sebuah hierarki Tahun bulan hari atau oleh Tahun-Minggu-Hari: dalam kedua kasus, tiga tingkat. Jelas Minggu dan Bulan mengelompokkan hari secara berbeda. Ada juga hierarki, jumlah level yang tidak deterministik dan bergantung pada data. Misalnya, folder di disk komputer.

    Agregasi data dapat terjadi dengan menggunakan beberapa fungsi standar: sum, minimum, maximum, average, count.

    MDX

    Mari beralih ke bahasa kueri dalam data multidimensi.
    Bahasa SQL pada awalnya dirancang bukan untuk pemrogram, tetapi untuk analis (dan karenanya memiliki sintaks yang menyerupai bahasa alami). Namun seiring waktu, ini menjadi semakin rumit dan sekarang hanya sedikit analis yang tahu cara menggunakannya dengan baik, jika ada. Ini telah menjadi alat bagi programmer. Bahasa kueri MDX, dikabarkan telah dikembangkan oleh mantan rekan senegaranya Moishe (atau Mosha) Posumansky di belantara Microsoft Corporation, juga awalnya ditujukan untuk analis, tetapi konsep dan sintaksnya (yang samar-samar menyerupai SQL, dan sepenuhnya sia-sia, karena ini hanya membingungkan), bahkan lebih rumit dari SQL. Namun demikian, dasar-dasarnya masih mudah dipahami.

    Kami akan mempertimbangkannya secara rinci karena ini adalah satu-satunya bahasa yang telah menerima status standar dalam kerangka standar protokol XMLA umum, dan kedua, karena ada implementasi sumber terbuka dalam bentuk proyek Mondrian dari perusahaan Pentaho. Sistem analisis OLAP lainnya (misalnya, Oracle OLAP Option) biasanya menggunakan ekstensi sintaks SQL mereka sendiri, namun, mereka juga menyatakan dukungan untuk MDX.

    Bekerja dengan susunan data analitik hanya menyiratkan pembacaannya dan tidak menyiratkan penulisan. Itu. dalam bahasa MDX tidak ada klausa untuk mengubah data, tetapi hanya ada satu klausa pemilihan - pilih.

    Di OLAP, dari kubus multidimensi, Anda dapat membuatnya irisan– yaitu ketika data disaring sepanjang satu atau lebih sumbu, atau proyeksi- saat kubus "runtuh" ​​di sepanjang satu atau beberapa sumbu, menggabungkan data. Misalnya, contoh pertama kami dengan jumlah pesanan dari negara - ada proyeksi kubus pada sumbu Negara. Kueri MDX untuk kasus ini akan terlihat seperti ini:

    Pilih ... Anak-anak pada baris dari
    Ada apa disini?

    Pilihkata kunci dan sintaks disertakan semata-mata untuk kecantikan.
    adalah nama sumbu. Semua nama yang tepat di MDX ditulis dalam tanda kurung siku.
    adalah nama hierarki. Dalam kasus kami, ini adalah hierarki Negara-Kota.
    adalah nama anggota sumbu pada tingkat pertama hierarki (yaitu negara) Semua adalah anggota meta yang menggabungkan semua anggota sumbu. Ada anggota meta di setiap sumbu. Misalnya, di sumbu tahun ada "Semua tahun", dll.
    Anak-anak adalah fungsi anggota. Setiap anggota memiliki beberapa fungsi yang tersedia. seperti orang tua. Level, Hierarki, mengembalikan masing-masing leluhur, level dalam hierarki, dan hierarki itu sendiri, tempat anggota tersebut berada dalam kasus ini. Anak-anak - Mengembalikan kumpulan anggota anak dari anggota ini. Itu. dalam kasus kami, negara.
    pada baris– Menentukan cara mengatur data ini di tabel ringkasan. Dalam hal ini, di tajuk baris. Nilai yang mungkin di sini adalah: di kolom, di halaman, di paragraf, dll. Dimungkinkan juga untuk menentukan hanya dengan indeks, mulai dari 0.
    dari merupakan indikasi dari kubus dari mana pemilihan dibuat.

    Bagaimana jika kita tidak membutuhkan semua negara, tetapi hanya beberapa negara tertentu? Untuk melakukan ini, Anda dapat secara eksplisit menunjukkan dalam permintaan negara-negara yang kami butuhkan, dan tidak memilih semua dengan fungsi Children.

    Pilih ( ..., ... ) pada baris dari
    Kurung kurawal dalam hal ini adalah set deklarasi ( mengatur). Himpunan adalah daftar, pencacahan anggota dari satu sumbu.

    Sekarang mari tulis kueri untuk contoh kedua kita - output dalam konteks pengirim:

    Pilih ...Anak-anak pada baris .Anggota pada kolom dari
    Ditambahkan di sini:
    - sumbu;
    .Anggota adalah fungsi sumbu yang mengembalikan semua anggota di atasnya. Fungsi yang sama tersedia untuk hierarki dan level. Karena hanya ada satu hirarki pada sumbu ini, maka indikasinya bisa dihilangkan, karena level dan hirarkinya juga sama, maka Anda bisa menampilkan semua anggota dalam satu daftar.

    Saya pikir sudah jelas bagaimana kita bisa melanjutkan ini ke contoh ketiga kita dengan merinci per tahun. Tapi lebih baik tidak detail per tahun, tapi filter - mis. membangun potongan. Untuk melakukannya, tulis kueri berikut:

    Pilih ..Anak pada baris .Anggota pada kolom dari mana (.)
    Filternya dimana?

    Di mana- kata kunci
    merupakan salah satu anggota hirarki . Nama lengkap, termasuk semua istilah, adalah: .. , tapi karena nama anggota ini unik di dalam sumbu, maka semua kualifikasi nama perantara dapat dihilangkan.

    Mengapa anggota tanggal dalam tanda kurung? Tanda kurung adalah tupel ( tupel). Tuple adalah satu atau lebih koordinat bermacam-macam kapak. Misalnya, untuk memfilter sepanjang dua sumbu sekaligus, dalam tanda kurung, kami mencantumkan dua istilah dari berbeda pengukuran dipisahkan dengan koma. Artinya, tuple mendefinisikan "irisan" dari kubus (atau "penyaringan" jika terminologi tersebut lebih dekat).

    Tuple digunakan untuk lebih dari sekedar memfilter. Tuple juga bisa di header baris/kolom/halaman, dll.

    Ini diperlukan, misalnya, untuk menampilkan hasil kueri tiga dimensi dalam tabel dua dimensi.

    Pilih crossjoin(...Children, ..Children) pada baris .Anggota pada kolom dari mana (.)
    Sambung silang adalah sebuah fungsi. Ini mengembalikan satu set tupel (ya, satu set dapat berisi tupel!), Yang dihasilkan dari produk Cartesian dari dua set. Itu. set hasil akan berisi semua kemungkinan kombinasi Negara dan Tahun. Header baris dengan demikian akan berisi beberapa nilai: Negara-Tahun.

    Pertanyaannya, di mana indikasi karakteristik numerik apa yang harus ditampilkan? Dalam hal ini, ukuran default yang ditentukan untuk kubus ini digunakan, yaitu. Harga pesanan. Jika kita ingin menampilkan ukuran lain, maka kita ingat bahwa ukuran adalah anggota dimensi Pengukuran. Dan kami bertindak dengan cara yang sama seperti sumbu lainnya. Itu. memfilter kueri dengan salah satu ukuran akan menampilkan dengan tepat ukuran ini di dalam sel.

    Pertanyaan: bagaimana memfilter di mana berbeda dari memfilter dengan menentukan anggota sumbu di baris. Jawaban: praktis tidak ada. Hanya saja di mana irisan diindikasikan untuk sumbu yang tidak berpartisipasi dalam pembentukan judul. Itu. sumbu yang sama tidak bisa hadir dalam waktu yang bersamaan pada baris, dan masuk Di mana.

    Anggota yang dihitung

    Untuk kueri yang lebih kompleks, Anda dapat mendeklarasikan anggota terhitung. Anggota sumbu atribut dan sumbu ukuran. Itu. Anda dapat mendeklarasikan, misalnya, ukuran baru yang akan menampilkan kontribusi masing-masing negara terhadap jumlah total pesanan:

    Dengan anggota. sebagai '.CurrentMember / ..', FORMAT_STRING='0.00%' pilih ...Anak-anak pada baris dari mana .
    Penghitungan berlangsung dalam konteks sel yang semua atribut koordinatnya diketahui. Koordinat yang sesuai (anggota) dapat diperoleh dengan fungsi CurrentMember untuk setiap sumbu kubus. Harus dipahami disini bahwa ungkapan .Member Saat Ini / ..' tidak membagi satu istilah dengan yang lain, tetapi membagi data agregat yang relevan irisan kubus! Itu. irisan untuk wilayah saat ini akan dibagi menjadi irisan untuk semua wilayah, mis. nilai total semua pesanan. FORMAT_STRING - mengatur format untuk menghasilkan nilai, mis. %.

    Contoh lain dari anggota yang dihitung, tetapi sudah pada sumbu tahun:

    Dengan anggota. sebagai'. - .'
    Jelas bahwa laporan tidak akan memiliki unit, tetapi perbedaan dari irisan yang sesuai, mis. perbedaan jumlah pesanan dalam dua tahun ini.

    Tampilan di ROLAP

    Sistem OLAP entah bagaimana didasarkan pada beberapa jenis penyimpanan data dan sistem organisasi. Ketika berbicara tentang RDBMS, mereka berbicara tentang ROLAP (Mari tinggalkan MOLAP dan HOLAP untuk belajar mandiri). ROLAP - OLAP pada basis data relasional, mis. dijelaskan dalam bentuk tabel dua dimensi konvensional. Sistem ROLAP mengonversi kueri MDX ke SQL. Masalah komputasi utama untuk database adalah agregasi cepat. Untuk mengumpulkan lebih cepat, data dalam database biasanya sangat didenormalisasi, mis. tidak disimpan dengan sangat efisien dalam hal ruang disk dan kontrol integritas basis data. Plus juga berisi tabel tambahan yang menyimpan data yang dikumpulkan sebagian. Oleh karena itu, untuk OLAP, skema basis data terpisah biasanya dibuat, yang hanya mengulang sebagian struktur basis data transaksional asli dalam bentuk direktori.

    Navigasi

    Banyak sistem OLAP menawarkan alat untuk navigasi interaktif melalui kueri yang sudah terbentuk (dan, karenanya, data yang dipilih). Dalam hal ini, yang disebut "pengeboran" atau "pengeboran" (bor) digunakan. Terjemahan yang lebih memadai ke dalam bahasa Rusia adalah kata "memperdalam". Tapi ini soal selera. Di beberapa lingkungan, kata "pengeboran" sudah melekat.

    Mengebor- ini adalah penyempurnaan laporan dengan mengurangi tingkat agregasi data, dikombinasikan dengan pemfilteran di sepanjang beberapa sumbu lain (atau beberapa sumbu). Pengeboran terdiri dari beberapa jenis:

    • menelusuri– memfilter berdasarkan salah satu sumbu asli laporan dengan output informasi mendetail tentang turunan dalam hierarki anggota pemfilteran yang dipilih. Misalnya, jika ada laporan distribusi pesanan menurut Negara dan Tahun, maka saat Anda mengklik tahun 2007, laporan akan ditampilkan dalam konteks Negara dan bulan yang sama tahun 2007.
    • sisi bor– memfilter di bawah satu atau beberapa sumbu yang dipilih dan menghapus agregasi di sepanjang satu atau beberapa sumbu lainnya. Misalnya, jika ada laporan distribusi pesanan menurut Negara dan Tahun, maka saat Anda mengklik 2007, laporan lain akan ditampilkan dalam konteks, misalnya, Negara dan Pemasok yang difilter menurut 2007.
    • menelusuri– penghapusan agregasi pada semua sumbu dan pemfilteran simultan pada sumbu – memungkinkan Anda untuk melihat data asli dari tabel fakta, dari mana nilai dalam laporan diperoleh. Itu. saat Anda mengklik nilai sel, sebuah laporan ditampilkan dengan semua pesanan yang memberikan jumlah tersebut. Semacam pengeboran instan ke dalam "perut" kubus.
    Itu saja. Sekarang, jika Anda memutuskan untuk mengabdikan diri pada Business Intelligence dan OLAP, inilah saatnya untuk mulai membaca literatur yang serius.

    Tag: Tambahkan tag

    Rumah Syarat Artikel Kursus Pengalaman perusahaan Blog Tips Download Untuk mitra Kontak Promosi

    Artikel > Otomasi penganggaran dan akuntansi manajemen >

    Alexander Karpov, kepala proyek bud-tech.ru, penulis seri buku "Penganggaran Praktis 100%" dan buku "Menyiapkan dan mengotomatiskan akuntansi manajemen"

    www.budtech.ru

    Mungkin, bagi sebagian orang, penggunaan teknologi OLAP (On-line Analytic Processing) dalam konstruksi pelaporan akan tampak eksotis, jadi penggunaan OLAP-CUBE untuk mereka sama sekali bukan salah satu persyaratan terpenting untuk mengotomatiskan penganggaran dan akuntansi manajemen.

    Nyatanya, sangat nyaman menggunakan CUBE multidimensi saat bekerja dengan pelaporan manajemen. Saat mengembangkan format anggaran, Anda mungkin menghadapi masalah formulir multivariat (lebih lanjut tentang ini dapat ditemukan di Buku 8 "Teknologi untuk menetapkan penganggaran di perusahaan" dan dalam buku "Menetapkan dan mengotomatiskan akuntansi manajemen").

    Hal ini disebabkan karena manajemen perusahaan yang efektif membutuhkan pelaporan manajemen yang lebih rinci. Artinya, sistem menggunakan lebih banyak bagian analitik yang berbeda (dalam sistem informasi, analitik ditentukan oleh sekumpulan direktori).

    Secara alami, ini mengarah pada fakta bahwa manajer ingin menerima laporan di semua bagian analitis yang mereka minati. Dan ini berarti bahwa laporan tersebut entah bagaimana harus dipaksa untuk "bernafas". Dengan kata lain, kita dapat mengatakan bahwa dalam hal ini kita berbicara tentang fakta bahwa, dari segi makna, laporan yang sama harus memberikan informasi di bagian analitis yang berbeda. Oleh karena itu, laporan statis tidak lagi cocok untuk banyak manajer modern. Mereka membutuhkan dinamika yang dapat disediakan oleh CUBE multidimensi.

    Dengan demikian, teknologi OLAP telah menjadi elemen yang sangat diperlukan dalam sistem informasi yang modern dan menjanjikan. Oleh karena itu, saat memilih produk perangkat lunak, Anda perlu memperhatikan apakah menggunakan teknologi OLAP.

    Dan Anda harus bisa membedakan CUBE asli dari imitasi. Tabel pivot di MS Excel adalah salah satu tiruannya. Ya, alat ini terlihat seperti CUBE, tetapi sebenarnya bukan, karena ini adalah tabel statis, bukan tabel dinamis. Selain itu, mereka memiliki implementasi yang jauh lebih buruk dari kemampuan membuat laporan yang menggunakan elemen dari direktori hierarkis.

    Untuk memastikan relevansi penggunaan KUB saat membangun pelaporan manajemen, kami dapat memberikan contoh anggaran penjualan yang paling sederhana. Dalam contoh ini, irisan analitik berikut relevan untuk perusahaan: produk, cabang, dan saluran distribusi. Jika ketiga analitik ini penting bagi perusahaan, maka anggaran penjualan (atau laporan) dapat ditampilkan dalam beberapa cara.

    Perlu dicatat bahwa jika Anda membuat garis anggaran berdasarkan tiga irisan analitis (seperti pada contoh yang dipertimbangkan), ini memungkinkan Anda membuat model anggaran yang cukup rumit dan menyusun laporan mendetail menggunakan KUB.

    Misalnya, anggaran penjualan dapat disusun hanya dengan menggunakan satu analitik (buku referensi). Contoh anggaran penjualan berdasarkan analitik "Produk" tunggal ditampilkan di Gambar 1.

    Beras. 1. Contoh anggaran penjualan yang dibuat berdasarkan satu "Produk" analitik di OLAP-CUBE paket perangkat lunak INTEGRAL

    Anggaran penjualan yang sama dapat disusun menggunakan dua analitik (buku referensi). Contoh anggaran penjualan yang dibuat berdasarkan dua analitik "Produk" dan "Afiliasi" disajikan di Gambar 2.

    Beras. 2. Contoh anggaran penjualan yang dibuat berdasarkan dua "Produk" analitik dan "Afiliasi" dalam OLAP-CUBE paket perangkat lunak INTEGRAL

    .

    Jika ada kebutuhan untuk membuat laporan yang lebih detail, maka anggaran penjualan yang sama dapat disusun menggunakan tiga analitik (buku referensi). Contoh anggaran penjualan yang dibangun berdasarkan tiga analitik "Produk", "Afiliasi", dan "Saluran distribusi" disajikan di Gambar 3.

    Beras. 3. Contoh anggaran penjualan yang dibuat berdasarkan tiga "Produk", "Cabang", dan "Saluran distribusi" analitik dalam OLAP-CUBE paket perangkat lunak INTEGRAL

    Perlu diingat bahwa KUB yang digunakan untuk membuat laporan memungkinkan Anda menampilkan data dalam urutan yang berbeda. Pada Gambar 3 anggaran penjualan pertama-tama "diterapkan" oleh produk, kemudian oleh cabang, dan kemudian oleh saluran distribusi.

    Data yang sama dapat disajikan dalam urutan yang berbeda. Pada gambar 4 anggaran penjualan yang sama "diluncurkan" pertama berdasarkan produk, kemudian saluran distribusi, dan kemudian cabang.

    Beras. 4. Contoh anggaran penjualan yang dibuat berdasarkan tiga "Produk", "Saluran distribusi", dan "Afiliasi" analitik dalam OLAP-CUBE paket perangkat lunak INTEGRAL

    Pada gambar 5 anggaran penjualan yang sama “diluncurkan” pertama-tama oleh cabang, kemudian oleh produk, dan kemudian oleh saluran distribusi.

    Beras. 5. Contoh anggaran penjualan yang dibuat berdasarkan tiga "Cabang" analitik, "Produk", dan "Saluran distribusi" di OLAP-CUBE kompleks perangkat lunak INTEGRAL

    Faktanya, ini tidak semua opsi yang memungkinkan untuk mendapatkan anggaran penjualan.

    Selain itu, Anda perlu memperhatikan fakta bahwa KUB memungkinkan Anda bekerja dengan struktur hierarki direktori. Dalam contoh yang disajikan, direktori hierarki adalah "Produk" dan "Saluran distribusi".

    Dari sudut pandang pengguna, dalam contoh ini, ia menerima beberapa laporan manajemen (lihat Gambar. Beras. 1-5), tetapi dari sudut pandang pengaturan di produk perangkat lunak, ini adalah satu laporan. Hanya dengan bantuan CUBE, dapat dilihat dengan beberapa cara.

    Biasanya, dalam praktiknya, sejumlah besar opsi keluaran untuk berbagai laporan manajemen dimungkinkan jika artikel mereka didasarkan pada satu atau lebih analis. Dan kumpulan analitik itu sendiri bergantung pada kebutuhan pengguna untuk perincian. Benar, orang tidak boleh lupa bahwa, di satu sisi, semakin banyak analis, semakin banyak laporan terperinci yang dapat dibuat. Tapi, di sisi lain, itu berarti model keuangan penganggaran akan lebih kompleks. Bagaimanapun, jika ada KUB, perusahaan akan dapat melihat pelaporan yang diperlukan dalam berbagai versi, sesuai dengan kepentingan bagian analitis.

    Beberapa fitur OLAP-CUBE perlu disebutkan.

    Ada beberapa dimensi dalam OLAP-CUBE hierarkis multidimensi: tipe baris, tanggal, baris, pencarian 1, pencarian 2, dan pencarian 3 (lihat Gambar. Beras. 6). Secara alami, laporan menampilkan tombol dengan direktori sebanyak yang ada di baris anggaran yang berisi jumlah maksimum direktori. Jika tidak ada satu direktori pun di baris anggaran mana pun, maka laporan tidak akan berisi tombol apa pun dengan direktori.

    Beras. 6. Pengukuran OLAP-CUBE dari paket perangkat lunak INTEGRAL

    Awalnya, OLAP-CUBE dibangun di atas semua dimensi. Secara default, saat laporan pertama kali dibuat, dimensi ditempatkan persis di area tersebut, seperti yang ditampilkan di gambar 6. Artinya, dimensi seperti "Tanggal" terletak di area dimensi vertikal (dimensi di area kolom), dimensi "Baris", "Pencarian 1", "Pencarian 2" dan "Pencarian 3 " - di area pengukuran horizontal (dimensi di baris area) dan dimensi "Tipe Baris" di area dimensi "tidak diperluas" (dimensi di area halaman). Jika dimensi berada di area terakhir, maka data dalam laporan tidak akan "diperluas" oleh dimensi tersebut.

    Masing-masing dimensi ini dapat ditempatkan di salah satu dari tiga area tersebut. Setelah pengukuran ditransfer, laporan langsung dibuat ulang sesuai dengan konfigurasi pengukuran yang baru. Misalnya, Anda dapat menukar tanggal dan string dengan direktori. Atau Anda dapat memindahkan salah satu buku referensi ke area pengukuran vertikal (lihat Gambar. Beras. 7). Dengan kata lain, laporan di OLAP-CUBE dapat "diputar" dan memilih versi keluaran laporan yang paling nyaman bagi pengguna.

    Beras. 7. Contoh pembuatan ulang laporan setelah mengubah konfigurasi pengukuran paket perangkat lunak INTEGRAL

    Konfigurasi pengukuran dapat diubah baik dalam bentuk utama KUB atau dalam editor peta perubahan (lihat. Beras. 8). Di editor ini, Anda juga dapat menarik dan melepas pengukuran dari satu area ke area lain dengan mouse. Selain itu, Anda dapat menukar pengukuran di area yang sama.

    Selain itu, dalam bentuk yang sama, Anda dapat mengonfigurasi beberapa parameter pengukuran. Untuk setiap dimensi, Anda dapat mengkustomisasi lokasi total, urutan elemen, dan nama elemen (lihat. Beras. 8). Anda juga dapat menentukan nama elemen yang akan ditampilkan dalam laporan: disingkat (Nama) atau lengkap (Nama Lengkap).

    Beras. 8. Editor peta pengukuran kompleks perangkat lunak "INTEGRAL"

    Parameter pengukuran dapat diedit langsung di masing-masingnya (lihat. Beras. 9). Untuk melakukan ini, klik ikon yang terletak di tombol di sebelah nama pengukuran.

    Beras. 9. Contoh mengedit direktori 1 Produk dan layanan dalam paket perangkat lunak INTEGRAL

    Dengan editor ini, Anda dapat memilih elemen yang ingin ditampilkan dalam laporan. Secara default, semua item ditampilkan dalam laporan, namun jika perlu, beberapa item atau folder dapat dihilangkan. Misalnya, jika Anda hanya perlu menampilkan satu grup produk dalam laporan, maka semua grup produk lainnya harus dihapus centangnya di editor dimensi. Setelah itu, laporan hanya akan berisi satu grup produk (lihat Gambar. Beras. 10).

    Anda juga dapat mengurutkan item di editor ini. Selain itu, elemen dapat diatur ulang dengan berbagai cara. Setelah pengelompokan ulang seperti itu, laporan tersebut langsung dibuat ulang.

    Beras. 10. Contoh menampilkan hanya satu grup produk (folder) dalam laporan di paket perangkat lunak INTEGRAL

    Di editor dimensi, Anda dapat dengan cepat membuat grup Anda sendiri, menyeret elemen dari direktori ke sana, dll. Secara default, hanya grup Lainnya yang dibuat secara otomatis, tetapi Anda juga dapat membuat grup lain. Jadi, dengan menggunakan editor dimensi, Anda dapat mengonfigurasi elemen mana dari buku referensi dan urutan apa yang harus ditampilkan dalam laporan.

    Perlu dicatat bahwa semua penataan ulang tersebut tidak dicatat. Artinya, setelah laporan ditutup atau setelah dihitung ulang, semua direktori akan ditampilkan di laporan sesuai dengan metodologi yang dikonfigurasi.

    Nyatanya, semua perubahan tersebut dapat dilakukan pada awalnya saat menyetel senar.

    Misalnya, dengan menggunakan batasan, Anda juga dapat menentukan elemen atau grup direktori mana yang harus ditampilkan dalam laporan, dan mana yang tidak.

    Catatan: topik artikel ini dibahas lebih detail di workshop "Manajemen anggaran perusahaan" Dan "Pengaturan dan otomatisasi akuntansi manajemen" dilakukan oleh penulis artikel ini - Alexander Karpov.

    Jika pengguna hampir secara teratur perlu menampilkan hanya elemen atau folder direktori tertentu dalam laporan, lebih baik membuat pengaturan seperti itu terlebih dahulu saat membuat baris laporan. Jika kombinasi berbeda dari elemen referensi dalam laporan penting bagi pengguna, maka tidak ada batasan yang perlu ditetapkan saat menyiapkan metodologi. Semua batasan tersebut dapat dikonfigurasi dengan cepat menggunakan editor dimensi.

    Informasi Umum

    Microsoft Excel memungkinkan Anda membuat laporan PivotTable berdasarkan data sumber Online Analytical Processing (OLAP). Saat Anda bekerja dengan laporan PivotTable yang didasarkan pada data sumber OLAP dan laporan yang didasarkan pada data sumber non-OLAP, Anda mungkin melihat perbedaan dalam kemampuan dan perilaku alat tersebut. Artikel ini membahas beberapa perbedaan utama antara laporan PivotTable berdasarkan data sumber OLAP dan laporan PivotTable berdasarkan data sumber non-OLAP.

    Dapatkan Data dan Perbarui Perbedaan

    Basis data OLAP diatur untuk memfasilitasi ekstraksi dan analisis data dalam jumlah besar. Sebelum Excel menampilkan data ringkasan dalam PivotTable, server OLAP melakukan penghitungan untuk meringkas data. Hanya data ringkasan yang diperlukan dikembalikan ke Excel, sesuai kebutuhan.

    Dengan database non-OLAP eksternal, semua catatan individual dikembalikan dan Excel melakukan peringkasan. Oleh karena itu, database OLAP memberi Excel kemampuan untuk menganalisis data eksternal dalam jumlah yang jauh lebih besar.

    Server OLAP mengirim data baru ke Excel setiap kali tata letak laporan atau tampilan PivotTable atau PivotChart berubah. Saat menggunakan data sumber non-OLAP, data diperbarui secara berbeda dan opsi penyegaran berbeda tersedia di kotak dialog Opsi PivotTable.

    Data non-OLAP bisa dikembalikan ke Microsoft Excel sebagai rentang data eksternal atau laporan PivotTable atau PivotChart. Data OLAP hanya bisa dikembalikan ke Excel sebagai laporan PivotTable atau PivotChart.

    Permintaan latar belakang

    Anda tidak dapat mengaktifkan opsi kueri latar belakang dalam kotak dialog Opsi PivotTable saat laporan PivotTable didasarkan pada sumber data OLAP.

    Permintaan dengan parameter

    Laporan PivotTable berdasarkan sumber data OLAP tidak mendukung kueri dengan parameter.

    Optimalisasi memori

    Kotak centang Optimalkan Memori di kotak dialog Opsi PivotTable tidak tersedia saat laporan PivotTable didasarkan pada sumber data OLAP.

    Opsi margin halaman

    Dalam laporan PivotTable yang didasarkan pada data sumber non-OLAP, Anda bisa menggunakan opsi margin halaman untuk mengambil data untuk setiap item satu per satu atau untuk semua item sekaligus. Opsi margin halaman ini tidak tersedia dalam laporan berdasarkan data sumber OLAP. Data sumber OLAP selalu diambil untuk setiap item sesuai kebutuhan, memungkinkan laporan menampilkan informasi dari database OLAP yang besar.

    Perbedaan dalam perhitungan

    Opsi margin halaman

    Anda tidak dapat mengubah fungsi untuk meringkas bidang data dalam laporan PivotTable berdasarkan data sumber OLAP. Keterbatasan ini terjadi karena total dihitung di server OLAP. Fungsi akhir

    Tidak dapat membuat bidang terhitung atau item terhitung dalam PivotTable berdasarkan sumber data OLAP.

    Kolom kalkulasi dan anggota kalkulasi

    Saat bekerja dengan subtotal dalam laporan PivotTable yang didasarkan pada data sumber OLAP, pembatasan berikut ini berlaku.

    Anda tidak dapat mengubah fungsi total untuk subtotal dalam laporan PivotTable.

    OLAP-CUBE (pelaporan manajemen dinamis)

    Tidak dapat menampilkan subtotal untuk bidang kolom internal atau internal dalam laporan PivotTable.

    Karena total dihitung di server OLAP, Anda tidak bisa mengubah Item Halaman Tersembunyi Perantara di kotak dialog Opsi PivotTable.

    Subtotal

    Opsi Tandai Total * dalam kotak dialog Opsi PivotTable hanya dapat digunakan dalam laporan PivotTable yang didasarkan pada data sumber OLAP. Opsi ini menandai semua subtotal dan total keseluruhan dengan tanda bintang (*) untuk menunjukkan bahwa nilai-nilai ini berisi item yang tersembunyi dan ditampilkan.

    Perbedaan Tata Letak dan Desain

    Dimensi dan Ukuran

    Saat bekerja dengan laporan PivotTable berdasarkan data sumber OLAP, dimensi hanya bisa digunakan sebagai bidang baris, kolom, atau halaman. Ukuran hanya dapat digunakan sebagai bidang data. Saat Anda menyeret dimensi ke area data bidang atau dimensi ke area baris, kolom, atau margin halaman, Anda menerima pesan kesalahan berikut:

    Bidang yang akan dipindahkan tidak dapat ditempatkan di area PivotTable ini.

    Saat laporan PivotTable berdasarkan data sumber OLAP aktif, toolbar PivotTable menampilkan ikon di samping setiap baris bidang. Ikon memperlihatkan di mana Excel akan memungkinkan Anda untuk menempatkan bidang dalam laporan PivotTable. Jika ikon berada di pojok kiri atas, bidang adalah dimensi yang dapat diseret ke bidang baris, kolom, atau halaman area. Jika ikon berada di pojok kanan bawah, bidang adalah ukuran yang dapat diseret ke area bidang data.

    Dimensi dan Ukuran

    Microsoft Excel memungkinkan Anda mengganti nama bidang yang ditambahkan ke PivotTable. Saat laporan PivotTable didasarkan pada data sumber OLAP, nama kustom Anda akan hilang saat bidang dihapus dari PivotTable.

    Mengelompokkan dan memisahkan elemen

    Di Excel 2000, Anda tidak bisa mengelompokkan item dalam laporan PivotTable yang didasarkan pada data sumber OLAP;

    Mengganti nama bidang

    Laporan PivotTable berdasarkan data sumber OLAP menampilkan level data terendah yang tersedia di server OLAP.

    Mengelompokkan dan memisahkan elemen

    Untuk data sumber non-OLAP, item dalam laporan PivotTable baru pertama kali muncul diurutkan dalam urutan menaik menurut nama item.

    Detail

    Perintah Perlihatkan Halaman tidak tersedia dalam laporan PivotTable berdasarkan data sumber OLAP.

    Tampilkan Item Tanpa Data

    Opsi Perlihatkan Item Tanpa Data di kotak dialog Bidang PivotTable tidak tersedia di laporan PivotTable yang didasarkan pada data sumber OLAP.

    Di bawah ini adalah daftar pertanyaan tentang topik Teknologi informasi dalam pengelolaan "Sinergi" MFPU / MFPA

    … adalah sistem otomatis interaktif yang membantu…

    OLAP dalam arti kata yang sempit diartikan sebagai ...

    Sistem OLAP (pemrosesan analitik online) adalah ...

    Sistem OLTP ternyata tidak banyak berguna karena ...

    Sistem kontrol otomatis (informasi otomatis…

    Dalam Proyek MS...

    Dalam sistem OLTP, pembaruan data terjadi ...

    Diagram yang dirancang untuk menganalisis rencana kerja menggunakan metode ...

    Sistem informasi adalah sekumpulan elemen yang saling berhubungan...

    teknologi informasi adalah...

    Keamanan informasi adalah...

    Perkembangan teknologi informasi di masyarakat dipengaruhi oleh hal-hal sebagai berikut...

    Pertukaran informasi dalam struktur badan manajemen organisasi tentang ...

    Sistem informasi eksekutif (Sistem Informasi Eksekutif…

    Tanda-tanda sistem informasi "kecil" meliputi ...

    Tanda-tanda sistem informasi skala "sedang" meliputi ...

    Metode pemrosesan informasi adalah...

    Prinsip modular membangun sistem informasi akuntansi ...

    Gambar tersebut menunjukkan penggalan diagram jenis ..., dibuat di pro ...

    Pada diagram jaringan di Proyek MS, tugas dari proyek eksternal…

    Pada diagram jaringan di Proyek MS, tugas yang tidak terkait dengan ...

    Pada diagram jaringan di MS Project, tugas yang merupakan akhir dari…

    Pada diagram jaringan di MS Project, tugas ringkasan, digabungkan

    Komposisi dan jumlah pekerjaan otomatis termasuk ...

    Ilmu aktivitas informasi, proses informasi dan ...

    Organisasi sistem informasi di mana pada server jauh ...

    Tujuan utama dari sistem OLAP adalah untuk...

    Tujuan utama dari sistem ERP adalah untuk mengotomatisasi...

    Tujuan utama dari metodologi MPS adalah…

    Karakteristik utama dari sistem OLAP adalah...

    Subsistem dukungan teknis meliputi ...

    Urutan tahapan teknologi untuk modifikasi primer ...

    Saat jaringan komputer pribadi dalam bentuk intrapro…

    Terapan perangkat lunak Komputer ini dirancang untuk...

    Contoh dari mata pelajaran teknologi informasi adalah teknologi...

    Proses pendukung keputusan melibatkan…

    Jaringan Berskala Perusahaan atau Corporate Network adalah informasi…

    Sistem kecerdasan buatan adalah…

    Sistem pemrosesan transaksi adalah sistem yang dirancang untuk…

    Sistem pemrosesan transaksi mematuhi…

    Sistem Pendukung Keputusan (DS…

    Metode dan alat modern untuk analisis dan perencanaan proses di…

    Pembuatan sistem informasi otomatis terintegrasi…

    Sistem informasi yang dibuat menjadi tidak layak pakai...

    Kekhususan dari sistem informasi dukungan manajemen dimanifestasikan ...

    Menggunakan sistem OLTP tradisional, Anda dapat ...

    Struktur sistem informasi perusahaan adalah...

    Untuk mempercepat dan mempermudah pekerjaan para manajer SDM di perusahaan..

    Untuk mempercepat dan mempermudah pekerjaan HR manager di perusahaan call…

    Fakta-fakta yang dirasakan tetap dari dunia di sekitar kita mewakili ...

    Serangkaian tindakan yang paling akurat mencerminkan proses mengelola…

    Tugas ekonomi yang diselesaikan dalam mode dialog menjadi ciri ...

    Sistem pakar dirancang untuk memproses...

    Apakah pelanggaran keamanan atau berada di area keamanan…

    OLAP itu mudah

    Menakjubkan dekat...

    Dalam perjalanan kerja, saya sering perlu membuat laporan yang rumit, sepanjang waktu saya mencoba menemukan kesamaan di dalamnya untuk membuatnya lebih sederhana dan universal, saya bahkan menulis dan menerbitkan artikel tentang hal ini “Pohon Osipov ”. Namun, mereka mengkritik artikel saya dan mengatakan bahwa semua masalah yang saya ajukan telah lama diselesaikan di OLAP (www.molap.rgtu.ru) dan merekomendasikan untuk melihat tabel pivot di EXCEL.
    Ternyata sangat sederhana sehingga, setelah menggunakan tangan saya yang cerdik untuk ini, saya mendapatkan skema yang sangat sederhana untuk mengunggah data dari 1C7 atau basis data lainnya (selanjutnya, 1C berarti basis data apa pun) dan analisis dalam OLAP.
    Saya pikir banyak skema unggahan OLAP terlalu rumit, saya memilih kesederhanaan.

    Karakteristik :

    1. Hanya EXCEL 2000 yang diperlukan untuk bekerja.
    2. Pengguna sendiri dapat merancang laporan tanpa pemrograman.
    3. Mengunggah dari 1C7 dalam format file teks sederhana.
    4. Untuk entri akuntansi, sudah ada proses pembongkaran universal yang berfungsi dalam konfigurasi apa pun. Untuk membongkar data lain, ada pemrosesan sampel.
    5. Anda dapat mendesain ulang formulir laporan dan kemudian menerapkannya ke data yang berbeda tanpa mendesain ulangnya.
    6. Performa yang cukup baik. Pada tahap panjang pertama, data pertama kali diimpor ke EXCEL dari file teks dan kubus OLAP dibuat, lalu laporan apa pun dapat dibuat dengan cepat berdasarkan kubus ini. Misalnya, data penjualan barang di toko selama 3 bulan dengan bermacam-macam 6000 barang dimuat ke EXCEL dalam 8 menit di Cel600-128M, peringkat berdasarkan barang dan grup (laporan OLAP) dihitung ulang dalam 1 menit.
    7. Data diunduh dari 1C7 secara penuh untuk periode yang ditentukan (semua pergerakan, untuk semua gudang, perusahaan, akun). Saat mengimpor ke EXCEL, dimungkinkan untuk menggunakan filter yang hanya memuat data yang diperlukan untuk analisis (misalnya, dari semua pergerakan, hanya penjualan).
    8. Saat ini, metode telah dikembangkan untuk menganalisis pergerakan atau residu, tetapi bukan pergerakan dan residu secara bersamaan, meskipun pada prinsipnya hal ini dimungkinkan.

    Apa itu OLAP : (www.molap.rgtu.ru)

    Misalkan Anda memiliki jaringan perdagangan. Biarkan data tentang operasi perdagangan diunggah ke file teks atau tabel dalam bentuk:

    Tanggal - tanggal operasi
    Bulan - bulan beroperasi
    Minggu - minggu beroperasi
    Jenis - pembelian, penjualan, pengembalian, penghapusan
    Counterparty - organisasi eksternal yang berpartisipasi dalam operasi
    Penulis - orang yang mengeluarkan faktur

    Dalam 1C, misalnya, satu baris tabel ini akan sesuai dengan satu baris faktur, beberapa bidang (Kontraktor, Tanggal) diambil dari header faktur.

    Data untuk analisis biasanya diunggah ke sistem OLAP untuk jangka waktu tertentu, yang pada prinsipnya, periode lain dapat dibedakan dengan menggunakan filter beban.

    Tabel ini adalah sumber untuk analisis OLAP.

    Pengguna sendiri yang menentukan bidang tabel mana yang akan menjadi Dimensi, Data mana, dan Filter mana yang akan diterapkan. Sistem itu sendiri membangun laporan dalam bentuk tabel visual. Dimensi dapat ditempatkan di judul baris atau kolom tabel laporan.
    Seperti yang Anda lihat, dari satu tabel sederhana Anda bisa mendapatkan banyak data dalam bentuk berbagai laporan.


    Cara pakai sendiri :

    Buka paket data dari paket distribusi tepat ke direktori c:\fixin (untuk sistem perdagangan dimungkinkan untuk c:\reports). Baca readme.txt dan ikuti semua petunjuk di dalamnya.

    Pertama, Anda harus menulis pemrosesan yang mengunggah data dari 1C ke file teks (tabel). Anda perlu menentukan komposisi bidang yang akan diunggah.
    Misalnya, pemrosesan universal siap pakai yang berfungsi dalam konfigurasi apa pun dan membongkar posting selama periode tertentu untuk analisis OLAP membongkar bidang berikut untuk analisis:

    Tanggal|Hari Dalam Seminggu|Minggu|Tahun|Kuartal|Bulan|Dokumen|Perusahaan|Debit|Nomenklatur Dt
    |NomenklaturGrupDt|NomenklaturDtSection|Kredit|Jumlah|Jumlah Valas|Kuantitas
    |Mata Uang|DtContractors|DtGroupContractors|KtContractors|KtGroupContractors|
    CTMiscellaneousObjects

    Dimana di bawah awalan Dt (Kt) terdapat subconto Debit (Kredit), Group adalah group dari subconto ini (bila ada), Section adalah group dari suatu group, Class adalah group dari suatu section.

    Untuk sistem perdagangan, bidangnya bisa sebagai berikut:

    Arah|Jenis Gerakan|Untuk Uang Tunai|Produk|Kuantitas|Harga|Jumlah|Tanggal|Perusahaan
    |Gudang|Mata Uang|Dokumen|Hari Kerja|Minggu|Tahun|Kuartal|Bulan|Penulis
    |Kategori Produk|Kategori Gerakan|Kategori Rekanan|Grup Produk
    |ValAmount|Harga Biaya|Kontraktor

    Untuk analisis data, tabel "Analisis pergerakan.xls" ("Analisis akuntansi.xls") digunakan. Saat membukanya, jangan nonaktifkan makro, jika tidak, Anda tidak akan dapat memperbarui laporan (dipicu oleh makro dalam bahasa VBA). File-file ini mengambil data awalnya dari file C:\fixin\motions.txt (C:\fixin\buh.txt), jika tidak, file tersebut sama.

    Dasar-dasar OLAP

    Oleh karena itu, Anda mungkin perlu menyalin data Anda ke salah satu file ini.
    Agar data Anda dimuat ke EXCEL, pilih atau tulis filter Anda sendiri dan klik tombol "Hasilkan" pada lembar "Ketentuan".
    Lembar laporan dimulai dengan awalan "Dari". Buka lembar laporan, klik "Refresh" dan data laporan akan berubah sesuai dengan data terbaru yang dimuat.
    Jika Anda tidak puas dengan laporan standar, ada lembar OtchTemplate. Salin ke sheet baru dan sesuaikan tampilan laporan dengan menggunakan tabel pivot pada sheet ini (lebih lanjut tentang bekerja dengan tabel pivot di buku EXEL 2000). Saya merekomendasikan menyiapkan laporan pada kumpulan data kecil, dan kemudian menjalankannya pada larik besar, karena tidak ada cara untuk menonaktifkan penggambaran ulang tabel setiap kali tata letak laporan berubah.

    Catatan Teknis :

    Saat mengunggah data dari 1C, pengguna memilih folder tempat mengunggah file. Saya melakukan ini karena kemungkinan beberapa file (sisa dan gerakan) akan diunggah dalam waktu dekat. Kemudian, dengan menekan tombol "Kirim" di Explorer —> "Untuk analisis OLAP di EXCEL 2000" data disalin dari folder yang dipilih ke folder C:\fixin. (agar perintah ini muncul di daftar perintah "Kirim", Anda perlu menyalin file "Untuk analisis OLAP di EXCEL 2000.bat" ke direktori C:\Windows\SendTo) Oleh karena itu, unggah data segera beri nama ke file motions.txt atau buh.txt.

    format file teks:
    Baris pertama file teks berisi judul kolom yang dipisahkan oleh "|", baris yang tersisa berisi nilai kolom ini yang dipisahkan oleh "|".

    Untuk mengimpor file teks ke Excel, Microsoft Query (bagian dari EXCEL) digunakan; untuk operasinya, file shema.ini diperlukan di direktori impor (C:\fixin) yang berisi informasi berikut:


    ColNameHeader=Benar
    Format=Dibatasi(|)
    MaxScanRows=3
    Set Karakter=ANSI
    ColNameHeader=Benar
    Format=Dibatasi(|)
    MaxScanRows=3
    Set Karakter=ANSI

    Penjelasan: motions.txt dan buh.txt adalah nama bagian, sesuai dengan nama file yang diimpor, menjelaskan cara mengimpor file teks ke Excel. Parameter yang tersisa berarti baris pertama berisi nama kolom, pemisah kolom adalah "|", rangkaian karakter adalah Windows ANSI (untuk DOS - OEM).
    Jenis field ditentukan secara otomatis berdasarkan data yang terdapat pada kolom (tanggal, nomor, string).
    Daftar bidang tidak perlu dijelaskan di mana pun - EXCEL dan OLAP akan menentukan sendiri bidang mana yang terdapat dalam file dengan tajuk di baris pertama.

    Perhatian, periksa pengaturan regional Anda "Control Panel" -> "Regional Settings". Dalam pemrosesan saya, angka-angka diunggah dengan pemisah koma, dan tanggalnya dalam format "DD.MM.YYYY".

    Saat Anda mengklik tombol "Hasilkan", data dimuat ke tabel pivot di lembar "Dasar", dan semua laporan di lembar "Kembalikan" mengambil data dari tabel pivot ini.

    Saya memahami bahwa pecinta MS SQL Server dan basis data yang kuat akan mengeluh bahwa semuanya terlalu disederhanakan bagi saya, bahwa pemrosesan saya akan dibengkokkan pada sampel tahunan, tetapi pertama-tama saya ingin memberikan manfaat analisis OLAP kepada organisasi menengah . Saya akan memposisikan produk ini sebagai alat analisis tahunan untuk grosir, analisis triwulanan untuk pengecer, dan analisis operasional untuk organisasi mana pun.

    Saya harus mengotak-atik VBA sehingga data diambil dari file dengan daftar bidang apa pun dan dimungkinkan untuk menyiapkan formulir laporan terlebih dahulu.

    Deskripsi pekerjaan di EXCEL (untuk pengguna):

    Petunjuk untuk menggunakan laporan:
    1. Kirim data yang diunduh untuk dianalisis (tanyakan kepada administrator). Untuk melakukannya, klik kanan folder tempat Anda mengunggah data dari 1C dan pilih perintah "Kirim", lalu "Ke analisis OLAP di EXCEL 2000".
    2. Buka file "Motion Analysis.xls".
    3. Pilih nilai Filter, filter yang Anda perlukan dapat ditambahkan pada tab "Nilai".
    4. Klik tombol "Hasilkan", dan data yang diunduh akan dimuat ke dalam EXCEL.
    5. Setelah memuat data ke EXCEL, Anda dapat melihat berbagai laporan. Untuk melakukannya, cukup klik tombol "Segarkan" di laporan yang dipilih. Lembar laporan dimulai dengan Rep.
    Perhatian! Setelah Anda mengubah nilai filter, Anda perlu mengklik kembali tombol "Hasilkan" agar data di EXCEL dimuat ulang dari file unggahan sesuai dengan filter.

    Memproses dari demo:

    Memproses motionsbuh2011.ert - versi terbaru bongkar transaksi dari Akuntansi 7.7 untuk analisis di Excel. Ini memiliki kotak centang "Tambahkan ke file", yang memungkinkan Anda mengunggah data sebagian demi periode, melampirkannya ke file yang sama, dan tidak mengunggah lagi ke file yang sama:

    Processing motionswork.ert mengunggah data penjualan untuk dianalisis di Excel.

    Contoh laporan :

    Catur dengan memposting:

    Beban kerja operator berdasarkan jenis tagihan:

    P.S. :

    Jelas bahwa menurut skema serupa, Anda dapat mengatur pembongkaran data dari 1C8.
    Pada tahun 2011, saya dihubungi oleh pengguna yang perlu menyelesaikan pemrosesan ini di 1C7 agar dapat mengunggah data dalam jumlah besar, saya menemukan agen outsourcing dan melakukan pekerjaan ini. Jadi perkembangannya cukup relevan.

    Pemrosesan Motionsbuh2011.ert telah ditingkatkan untuk menangani pengunggahan data yang besar.

    Definisi pertama yang jelas OLAP(On-line Analytical Processing) diusulkan pada tahun 1993 oleh E.F. Codd dalam sebuah artikel yang diterbitkan dengan dukungan Arbor Software (sekarang Hyperion Software). Artikel tersebut menyertakan 12 aturan yang kini telah dikenal luas dan dijelaskan di situs web vendor aplikasi OLAP mana pun. Kemudian, pada tahun 1995, enam aturan yang kurang dikenal ditambahkan ke dalamnya, semuanya dibagi menjadi empat kelompok dan disebut "fitur" (fitur). Berikut adalah aturan yang menentukan aplikasi OLAP, dengan komentar dari Nigel Pendse, salah satu pembuat situs Laporan OLAP.

    Fitur utama OLAP meliputi:

    1. Multidimensi model data. Sedikit yang membantah pernyataan ini, dan ini dianggap sebagai ciri utama OLAP. Bagian dari persyaratan ini adalah kemampuan untuk membuat berbagai proyeksi dan bagian model.

    2. Mekanisme manipulasi data yang intuitif. Codd percaya bahwa manipulasi data harus dilakukan melalui tindakan langsung di sel tabel, tanpa menggunakan menu atau yang rumit. Dapat diasumsikan bahwa ini menyiratkan penggunaan operasi mouse, tetapi Codd tidak menyatakannya. Banyak produk tidak mengikuti aturan ini. Dari sudut pandang kami, karakteristik ini tidak banyak berpengaruh pada kualitas proses analisis data. Kami percaya bahwa program tersebut harus menawarkan kemungkinan untuk memilih model kerja, karena tidak semua pengguna menyukai hal yang sama.

    3. Ketersediaan. OLAP adalah Mediator. Codd secara khusus menekankan bahwa mesin OLAP adalah perantara antara sumber data yang heterogen dan antarmuka pengguna. Sebagian besar produk menyediakan fitur ini, tetapi aksesibilitas data seringkali kurang dari yang diinginkan vendor perangkat lunak lain.

    4. Ekstraksi data batch. Aturan ini mengharuskan produk menawarkan database mereka sendiri untuk menyimpan data yang dianalisis dan akses dinamis (langsung) ke data eksternal. Kami setuju dengan Codd dalam hal ini dan menyesal karena hanya sedikit produk OLAP yang cocok dengannya. Bahkan program yang menawarkan fitur seperti itu jarang membuatnya mudah dan cukup otomatis. Hasilnya, Codd mendukung representasi data multidimensi plus prakalkulasi sebagian dari basis data multidimensi besar dengan akses ujung ke ujung yang transparan ke informasi terperinci. Saat ini, ini dilihat sebagai definisi OLAP hybrid, yang menjadi arsitektur paling populer, jadi Codd melihat tren utama di area ini dengan sangat akurat.

    5. Arsitektur Klien-Server. Codd percaya bahwa tidak hanya setiap produk harus menjadi klien/server, tetapi setiap komponen server dari produk OLAP harus cukup pintar sehingga klien yang berbeda dapat dihubungkan dengan upaya dan pemrograman minimum. Ini adalah pengujian yang jauh lebih sulit daripada arsitektur klien-server sederhana, dan relatif sedikit produk yang lulus. Kami mungkin berpendapat bahwa pengujian ini mungkin lebih sulit dari yang seharusnya, dan tidak ada gunanya mendikte arsitektur sistem kepada pengembang.

    6. Transparansi. Tes ini juga sulit tetapi perlu. Kepatuhan penuh berarti bahwa pengguna, katakanlah, sebuah spreadsheet dapat memiliki akses penuh ke fasilitas yang disediakan oleh mesin OLAP dan bahkan mungkin tidak mengetahui dari mana data berasal. Untuk mencapai hal ini, produk harus menyediakan akses dinamis ke sumber data yang heterogen dan modul spreadsheet berfitur lengkap. Server OLAP ditempatkan di antara spreadsheet dan gudang data.

    7. Pekerjaan multipemain. Codd mendefinisikan bahwa untuk dianggap sebagai alat OLAP strategis, aplikasi harus lebih dari sekadar membaca dan menginterpretasikan data, dan dengan demikian, mereka harus menyediakan akses bersamaan (termasuk pengambilan dan pembaruan data), integritas, dan keamanan.

    Fitur spesial

    8. Menangani Data yang Didenormalisasi. Ini berarti bahwa integrasi antara mesin OLAP dan sumber data yang tidak dinormalisasi dimungkinkan. Codd menekankan bahwa saat memperbarui data yang dilakukan di lingkungan OLAP, data yang didenormalisasi di sistem eksternal harus dapat diubah.

    9. Menyimpan hasil OLAP secara terpisah dari data asli. Pada kenyataannya, ini berkaitan dengan penerapan produk, bukan kemampuannya, tetapi hanya sedikit yang akan membantah pernyataan ini. Intinya, Cobb mendukung sistem yang diterima secara luas di mana aplikasi OLAP harus membuat analisis langsung pada data transaksi dan perubahan pada data OLAP harus dipisahkan dari data transaksi.

    10. Sorot data yang hilang. Ini berarti bahwa data yang hilang harus berbeda dari nol. Biasanya, semua sistem OLAP modern mendukung fitur ini.

    11. Menangani Nilai yang Hilang. Semua nilai yang hilang harus diabaikan dalam analisis, terlepas dari sumbernya.

    Karakteristik pelaporan

    12. Pelaporan yang fleksibel. Dimensi yang berbeda harus berbaris sesuai dengan kebutuhan pengguna. Sebagian besar produk memenuhi persyaratan ini dalam lingkup editor laporan khusus. Saya berharap fitur yang sama tersedia di penampil interaktif, tetapi ini jauh lebih jarang. Inilah salah satu alasan mengapa kami lebih memilih fungsi analisis dan pelaporan digabungkan dalam satu modul.

    1. Konsep kubus olap

    13. Kinerja pelaporan yang konsisten. Artinya kinerja sistem saat membangun laporan tidak boleh turun secara signifikan dengan bertambahnya dimensi atau ukuran database.

    14. Throttling Lapisan Fisik Otomatis. Sistem OLAP harus secara otomatis menyesuaikan struktur fisik untuk menyesuaikannya dengan tipe dan struktur model.

    Kontrol dimensi

    15. Fungsi umum. Semua dimensi harus memiliki kemampuan yang sama dalam struktur dan fungsi.

    16. Dimensi tak terbatas dan tingkat agregasi. Faktanya, dengan jumlah yang tidak terbatas, Codd berarti 15-20, mis. angka yang diketahui melebihi kebutuhan maksimum analis.

    17. Operasi tak terbatas antara data pengukuran yang berbeda. Codd percaya bahwa untuk sebuah aplikasi disebut multidimensi, itu harus mendukung setiap perhitungan menggunakan data dari semua dimensi.

    Detail tentang produk Hyperion - di situs www.hyperion.ru

    versi cetak

    Kembali

    10.8 Bekerja dengan tabel pivot (objek PivotTable)

    Objek Excel.PivotTable, secara terprogram bekerja dengan tabel pivot dan kubus OLAP di Excel menggunakan VBA, objek PivotCache, membuat tata letak tabel pivot

    Selama pengoperasian sebagian besar perusahaan, apa yang disebut data mentah tentang aktivitas diakumulasikan. Misalnya, untuk perusahaan perdagangan, data penjualan barang dapat diakumulasikan - untuk setiap pembelian secara terpisah, untuk perusahaan komunikasi seluler - statistik beban di stasiun pangkalan, dll. Sangat sering, manajemen suatu perusahaan memerlukan informasi analitik yang dihasilkan berdasarkan informasi mentah - misalnya, untuk menghitung kontribusi setiap jenis produk terhadap pendapatan perusahaan atau kualitas layanan di bidang tertentu. stasiun. Sangat sulit untuk mengekstrak informasi seperti itu dari informasi mentah: Anda perlu menjalankan kueri SQL yang sangat kompleks yang memakan waktu lama dan sering kali mengganggu pekerjaan yang sedang berlangsung. Oleh karena itu, saat ini semakin banyak data mentah yang digulung terlebih dahulu di Gudang Data, dan kemudian di kubus OLAP, yang sangat nyaman untuk analisis interaktif. Cara termudah untuk memikirkan kubus OLAP adalah sebagai tabel multidimensi, di mana, alih-alih dua dimensi standar (kolom dan baris, seperti pada tabel biasa), mungkin ada banyak dimensi. Istilah "bagian" umumnya digunakan untuk menggambarkan dimensi dalam kubus. Misalnya, departemen pemasaran mungkin memerlukan informasi berdasarkan waktu, wilayah, jenis produk, saluran penjualan, dan sebagainya. Menggunakan kubus (berlawanan dengan kueri SQL standar), sangat mudah untuk mendapatkan jawaban atas pertanyaan seperti “berapa banyak produk jenis ini yang dijual pada kuartal keempat tahun lalu di wilayah Barat Laut melalui distributor regional.

    Tentu saja, Anda tidak dapat membuat kubus seperti itu di basis data biasa. Kubus OLAP memerlukan produk perangkat lunak khusus. SQL Server hadir dengan database OLAP dari Microsoft yang disebut Analysis Services. Ada solusi OLAP dari Oracle, IBM, Sybase, dll.

    Untuk bekerja dengan kubus seperti itu, klien khusus dibuat di Excel.

    Dalam bahasa Rusia disebut tabel pivot(pada layar grafis, tersedia melalui menu Data -> tabel pivot), dan dalam bahasa Inggris - tabel pivot. Dengan demikian, objek yang diwakili oleh klien ini disebut PivotTable. Perlu dicatat bahwa ini dapat bekerja tidak hanya dengan kubus OLAP, tetapi juga dengan data biasa di tabel atau database Excel, tetapi banyak fitur yang hilang.

    PivotTable dan objek PivotTable adalah produk perangkat lunak dari Panorama Software yang telah diakuisisi oleh Microsoft dan diintegrasikan ke dalam Excel.

    Oleh karena itu, bekerja dengan objek PivotTable agak berbeda dengan bekerja dengan objek Excel lainnya. Mencari tahu apa yang harus dilakukan seringkali sulit. Oleh karena itu, disarankan untuk menggunakan perekam makro secara aktif untuk menerima petunjuk. Pada saat yang sama, saat bekerja dengan tabel pivot, pengguna sering kali harus melakukan operasi berulang yang sama, jadi otomatisasi diperlukan dalam banyak situasi.

    Seperti apa rasanya bekerja secara terprogram dengan tabel pivot?

    Hal pertama yang perlu kita lakukan adalah membuat objek PivotCache yang akan mewakili kumpulan rekaman yang diambil dari sumber OLAP. Secara kondisional, objek PivotCache ini dapat dibandingkan dengan QueryTable. Hanya satu objek PivotCache yang dapat digunakan per objek PivotTable. Objek PivotCache dibuat menggunakan metode Add() dari koleksi PivotCaches:

    Redupkan PC1 Sebagai PivotCache

    Atur PC1 = ActiveWorkbook.PivotCaches.Add(xlExternal)

    PivotCaches adalah kumpulan standar, dan dari metode yang patut dipertimbangkan secara mendetail, hanya metode Add() yang dapat diberi nama di dalamnya. Metode ini membutuhkan dua parameter:

    • Jenis Sumber- diperlukan, menentukan jenis sumber data untuk tabel pivot. Anda bisa memilih untuk membuat PivotTable berdasarkan rentang di Excel, data dari database, sumber data eksternal, PivotTable lain, dan seterusnya. Dalam praktiknya, biasanya masuk akal untuk menggunakan OLAP hanya jika ada banyak data - oleh karena itu, diperlukan penyimpanan eksternal khusus (misalnya, Layanan Analisis Microsoft). Dalam situasi ini, xlExternal dipilih.
    • Sumber data- diperlukan dalam semua kasus kecuali jika nilai parameter pertama adalah xlExternal. Sebenarnya, ini menentukan rentang data yang menjadi dasar pembuatan PivotTable. Biasanya mengambil objek Range.

    Tugas selanjutnya adalah mengonfigurasi parameter objek PivotCache. Seperti yang telah disebutkan, objek ini sangat mirip dengan QueryTable, dan kumpulan properti serta metodenya sangat mirip. Beberapa properti dan metode yang paling penting adalah:

    • Sambungan ADO- kemampuan untuk mengembalikan objek Koneksi ADO yang dibuat secara otomatis untuk menyambungkan ke sumber data eksternal. Digunakan untuk mengonfigurasi lebih lanjut properti koneksi.
    • koneksi- bekerja persis sama dengan properti objek QueryTable dengan nama yang sama. Itu dapat menerima string koneksi, objek Recordset yang disiapkan, file teks, permintaan Web. File Permintaan Microsoft. Paling sering, saat bekerja dengan OLAP, string koneksi ditulis secara langsung (karena tidak masuk akal untuk menerima objek Recordset, misalnya, untuk mengubah data - sumber data OLAP hampir selalu hanya-baca). Misalnya, menyetel properti ini untuk terhubung ke database Foodmart (database sampel Layanan Analisis) di server LONDON mungkin terlihat seperti ini:

    PC1.Connection = "OLEDB;Provider=MSOLAP.2;Sumber Data=LONDON1;Katalog Awal = FoodMart 2000"

    • properti Tipe Perintah Dan teks perintah jelaskan jenis perintah yang dikirim ke server database dan teks dari perintah itu sendiri dengan cara yang sama. Misalnya, untuk mengakses kubus Penjualan dan membuatnya sepenuhnya di-cache pada klien, Anda dapat menggunakan kode seperti

    PC1.CommandType = xlCmdCube

    PC1.CommandText = Array("Penjualan")

    • Properti Koneksi Lokal memungkinkan Anda terhubung ke kubus lokal (berkas *.cub) yang dibuat oleh Excel. Tentu saja, sangat tidak disarankan untuk menggunakan file seperti itu untuk bekerja dengan volume data "produksi" - hanya untuk tujuan membuat tata letak, dll.
    • Properti MemoriDigunakan mengembalikan jumlah RAM yang digunakan oleh PivotCache. Jika PivotTable berdasarkan PivotCache ini belum dibuat dan dibuka, kembalikan 0. Dapat digunakan untuk memeriksa apakah aplikasi Anda akan berfungsi pada klien yang lemah.
    • Properti OLAP mengembalikan True jika PivotCache tersambung ke server OLAP.
    • Optimalkan Cache- kemampuan untuk mengoptimalkan struktur cache. Pemuatan data awal akan memakan waktu lebih lama, tetapi kemudian kecepatan kerja dapat meningkat. Untuk sumber OLE DB tidak berfungsi.

    Properti yang tersisa dari objek PivotCache sama dengan properti objek QueryTable, dan karenanya tidak akan dibahas di sini.

    Metode utama objek PivotCache adalah metode CreatePivotTable(). Dengan bantuan metode ini, tahap selanjutnya dilakukan - pembuatan tabel pivot (objek PivotTable). Metode ini membutuhkan empat parameter:

    • TabelTujuan adalah satu-satunya parameter yang diperlukan.

      Menerima objek Rentang, di sudut kiri atas tempat tabel pivot akan ditempatkan.

    • nama tabel- Nama tabel pivot. Jika tidak ditentukan, maka nama formulir "PivotTable1" akan dibuat secara otomatis.
    • membaca data- jika disetel ke True, maka semua isi kubus akan di-cache secara otomatis. Anda harus sangat berhati-hati dengan parameter ini, karena penggunaannya yang salah dapat meningkatkan beban klien secara dramatis.
    • Versi Default- Properti ini biasanya tidak ditentukan. Memungkinkan Anda menentukan versi PivotTable yang sedang dibuat. Secara default, versi terbaru digunakan.

    Membuat tabel pivot di sel pertama lembar pertama buku kerja mungkin terlihat seperti ini:

    PC1.Buat Rentang PivotTable("A1")

    Tabel pivot telah dibuat, tetapi segera setelah dibuat tabel tersebut kosong. Ini menyediakan empat area di mana Anda dapat menempatkan bidang dari sumber (pada layar grafik, semua ini dapat dikonfigurasi baik menggunakan jendela Daftar Bidang Tabel Pivot- terbuka secara otomatis atau dengan tombol Tata letak di layar terakhir PivotTable Wizard):

    • daerah kolom- ini berisi dimensi ("bagian" di mana data akan dianalisis), yang anggotanya lebih kecil;
    • daerah garis- dimensi-dimensi itu, yang anggotanya lebih banyak;
    • luas halaman- pengukuran yang hanya perlu disaring (misalnya, untuk menampilkan data hanya untuk wilayah ini dan itu atau hanya untuk tahun ini dan itu);
    • wilayah data- sebenarnya, bagian tengah meja. Data numerik tersebut (misalnya, jumlah penjualan) yang kami analisis.

    Mengandalkan pengguna untuk menempatkan elemen dengan benar di keempat area itu sulit.

    Selain itu, mungkin perlu waktu. Oleh karena itu, seringkali perlu menyusun data dalam PivotTable secara terprogram. Operasi ini dilakukan dengan menggunakan objek CubeField. Properti utama dari objek ini adalah Orientasi, yang menentukan di mana bidang ini atau itu akan ditempatkan. Misalnya, letakkan dimensi Pelanggan di area kolom:

    PT1.CubeFields("").Orientasi = xlColumnField

    Kemudian - dimensi Waktu ke area string:

    PT1.CubeFields("").Orientasi = xlRowField

    Kemudian - dimensi Produk ke area halaman:

    PT1.CubeFields("").Orientasi = xlPageField

    Dan terakhir, indikator (data numerik untuk analisis) Penjualan Unit:

    PT1.CubeFields(".").Orientasi = xlDataField

    Sekarang tabel pivot dibuat dan sangat mungkin untuk bekerja dengannya. Namun, seringkali perlu melakukan satu operasi lagi - untuk memperluas tingkat hierarki dimensi yang diinginkan. Misalnya, jika kita tertarik pada analisis triwulanan, maka kita perlu memperluas tingkat Kuartal dari dimensi Waktu (hanya tingkat teratas yang ditampilkan secara default). Tentu saja, pengguna dapat melakukannya sendiri, tetapi Anda tidak selalu dapat mengandalkannya untuk menebak di mana harus mengklik mouse. Perluas secara terprogram, misalnya, hierarki dimensi Waktu ke tingkat perempat untuk tahun 1997 menggunakan objek PivotField dan PivotItem:

    PT1.PivotFields(“.”).PivotItems(“.”).DrilledDown = True

    / Secara kubik. Penggunaan kubus OLAP dalam praktik manajemen perusahaan besar


    Berhubungan dengan

    Teman sekelas

    Konstantin Tokmachev, arsitek sistem

    dengan cara kubisme.
    Penggunaan kubus OLAP dalam praktik manajemen perusahaan besar

    Mungkin waktu telah berlalu ketika sumber daya komputasi korporasi dihabiskan hanya untuk pendaftaran informasi dan laporan akuntansi. Pada saat yang sama, keputusan manajerial dibuat "dengan mata" di kantor, di rapat dan sesi. Mungkin sudah waktunya di Rusia untuk kembali ke sistem komputasi perusahaan sumber daya utama mereka - memecahkan masalah kontrol berdasarkan data yang terdaftar di komputer.

    Tentang manfaat intelijen bisnis

    Dalam lingkaran manajemen perusahaan, antara data "mentah" dan "pengungkit" yang memengaruhi objek yang dikelola, terdapat "indikator kinerja" - KPI. Mereka seolah-olah membentuk "dasbor", yang mencerminkan keadaan berbagai subsistem dari objek yang dikendalikan. Untuk membekali perusahaan dengan indikator kinerja yang informatif dan mengontrol perhitungannya serta nilai yang diperoleh adalah pekerjaan seorang analis bisnis. Layanan analisis otomatis, seperti utilitas MS SQL Server Analysis Services (SSAS) dan dispositif utamanya, kubus OLAP, dapat memberikan bantuan yang signifikan dalam mengatur pekerjaan analitis perusahaan.

    Ada satu catatan lagi yang harus dibuat di sini. Misalnya, dalam tradisi Amerika, spesialisasi yang difokuskan untuk bekerja dengan kubus OLAP disebut BI (Business Intelligence). Seharusnya tidak ada ilusi bahwa BI Amerika sesuai dengan "analis bisnis" Rusia. Jangan tersinggung, tetapi seringkali analis bisnis kami adalah "di bawah akuntan" dan "di bawah pemrogram", seorang spesialis dengan pengetahuan kabur dan gaji kecil, yang benar-benar tidak memiliki alat dan metodologinya sendiri.

    Seorang spesialis BI, pada kenyataannya, adalah seorang matematikawan terapan, seorang spesialis kelas atas yang menggunakan metode matematika modern untuk melayani perusahaan (apa yang disebut Riset Operasi - metode riset operasi). BI lebih sejalan dengan "analis sistem" khusus yang dulu ada di Uni Soviet, yang diproduksi oleh fakultas VMK Universitas Negeri Moskow. M.V. Lomonosov. Kubus OLAP dan layanan analisis dapat menjadi basis yang menjanjikan untuk tempat kerja seorang analis bisnis Rusia, mungkin setelah beberapa peningkatan dalam kualifikasinya menuju BI Amerika.

    Baru-baru ini, tren berbahaya lainnya telah muncul. Berkat spesialisasi, saling pengertian antara berbagai kategori karyawan korporasi telah hilang. Seorang akuntan, manajer, dan pemrogram, seperti "angsa, kanker, dan tombak" dalam dongeng I.A. Krylov, menarik korporasi ke arah yang berbeda.

    Akuntan sibuk melaporkan, jumlahnya, baik dalam arti maupun dinamika, tidak terkait langsung dengan proses bisnis perusahaan.

    Manajer sibuk dengan segmen proses bisnisnya, tetapi tidak dapat menilai secara global, di tingkat perusahaan secara keseluruhan, hasil dan prospek tindakannya.

    Terakhir, programmer yang dulu (berkat pendidikan) menjadi penghantar ide teknis lanjutan dari bidang sains ke bidang bisnis, telah berubah menjadi pelaksana pasif dari fantasi seorang akuntan dan manajer, sehingga tidak lagi jarang terjadi pada akuntan dan pada umumnya setiap orang yang tidak malas. Pemrogram 1C yang belum tahu, buta huruf, tetapi bergaji relatif tinggi adalah momok nyata bagi perusahaan Rusia. (Hampir seperti pemain sepak bola domestik.) Saya tidak berbicara tentang apa yang disebut "ekonom dan pengacara", semuanya telah dikatakan tentang mereka sejak lama.

    Jadi, posisi analis bisnis yang dilengkapi dengan peralatan SSAS berteknologi tinggi yang mengetahui dasar-dasar pemrograman dan akuntansi mampu mengkonsolidasikan pekerjaan perusahaan terkait dengan analisis dan perkiraan proses bisnis.

    Manfaat kubus OLAP

    OLAP-cube adalah alat modern untuk menganalisis basis data sistem komputer perusahaan yang memungkinkan karyawan dari semua tingkat hierarki diberikan serangkaian indikator yang diperlukan yang menjadi ciri proses produksi perusahaan. Intinya bukan hanya antarmuka yang ramah pengguna dan bahasa permintaan yang fleksibel untuk kubus MDX (MultiDimensional eXpressions) memungkinkan Anda merumuskan dan menghitung indikator analitik yang diperlukan, tetapi juga dalam kecepatan dan kemudahan luar biasa yang digunakan kubus OLAP ini. Selain itu, kecepatan dan kemudahan ini, dalam batas tertentu, tidak bergantung pada kerumitan perhitungan dan volume database.

    Beberapa pemahaman tentang OLAP
    kubus dapat memberikan "tabel pivot" MS Excel. Objek-objek ini memiliki logika yang mirip dan antarmuka yang serupa. Namun, seperti yang akan terlihat dari artikel, 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 analitik? Kubus OLAP dirancang sedemikian rupa sehingga semua indikator di semua bagian yang memungkinkan telah dihitung sebelumnya (seluruhnya atau sebagian), dan pengguna hanya perlu "menarik" indikator yang diperlukan (ukuran ukuran) dan bagian (dimensi dimensi ) dengan mouse, dan program menggambar ulang pelat.

    Semua analitik yang mungkin di semua bagian membentuk satu bidang besar, atau lebih tepatnya, bukan bidang, tetapi hanya kubus OLAP multidimensi. Apa pun permintaan yang diajukan pengguna (manajer, analis bisnis, manajer) ke layanan analitik, kecepatan respons disebabkan oleh dua hal: pertama, analitik yang diperlukan dapat dengan mudah dirumuskan (baik dipilih dari daftar berdasarkan nama, atau diberikan dengan rumus dalam bahasa MDX ), dan kedua, sebagai aturan, sudah dihitung.

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

    Ini berarti beberapa fitur menarik dari kubus OLAP sekaligus. Faktanya, penghalang antara pengguna dan data menghilang. Penghalang berupa pemrogram aplikasi, yang pertama-tama perlu menjelaskan masalahnya (menetapkan tugas). Kedua, Anda harus menunggu hingga pemrogram aplikasi membuat algoritme, menulis dan men-debug program, lalu dapat dimodifikasi. Jika ada banyak karyawan dan persyaratannya bervariasi dan dapat diubah, maka diperlukan seluruh tim pemrogram terapan. Dalam pengertian ini, kubus OLAP (dan analis bisnis yang berkualifikasi) dalam hal pekerjaan analitis menggantikan seluruh tim pemrogram aplikasi, seperti ekskavator yang kuat dengan pengemudi backhoe saat menggali parit menggantikan seluruh brigade pekerja tamu dengan sekop!

    Dalam hal ini, kualitas lain yang sangat penting dari data analitik yang diperoleh tercapai. Karena kubus OLAP adalah satu untuk seluruh perusahaan, mis. Karena ini adalah bidang yang sama dengan analis untuk semua, inkonsistensi yang mengganggu dalam data dikecualikan. Ketika seorang manajer harus menetapkan tugas yang sama kepada beberapa karyawan independen untuk menghilangkan faktor subjektivitas, tetapi mereka tetap memberikan jawaban yang berbeda, yang setiap orang lakukan untuk menjelaskannya, dll. Kubus OLAP memastikan keseragaman data analitik pada berbagai tingkat hierarki perusahaan, mis. jika manajer ingin merinci indikator tertentu yang menarik baginya, maka dia pasti akan sampai pada data tingkat rendah yang digunakan bawahannya, dan ini hanya akan menjadi data yang menjadi dasar penghitungan indikator tingkat yang lebih tinggi. , dan bukan data lain, diterima dengan cara lain, di waktu lain, dll. Artinya, seluruh perusahaan melihat analitik yang sama, tetapi pada tingkat konsolidasi yang berbeda.

    Mari kita ambil contoh. Misalkan seorang manajer mengontrol piutang. Selama KPI tunggakan piutang berwarna hijau, maka semuanya normal, tidak diperlukan tindakan manajemen. Jika warnanya berubah menjadi kuning atau merah, ada yang salah: kami memotong KPI oleh departemen penjualan dan langsung melihat divisi "berwarna merah". Bagian selanjutnya tentang manajer - dan penjual, yang pelanggannya terlambat membayar, ditentukan. (Selanjutnya, jumlah keterlambatan dapat dipecah oleh pembeli, persyaratan, dll.) Pimpinan perusahaan dapat langsung menangani 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 menjadi jumlah tunggakan - itu bisa menjadi rata-rata tertimbang periode tunggakan atau, secara umum, tingkat perputaran piutang.

    Perhatikan bahwa kompleksitas dan fleksibilitas bahasa MDX, bersama dengan hasil yang cepat (terkadang seketika), memungkinkan untuk menyelesaikan (dengan mempertimbangkan tahapan pengembangan dan debugging) tugas kontrol kompleks yang, dalam kondisi lain, mungkin tidak dapat dilakukan. sama sekali karena kerumitan untuk pemrogram terapan, dan ketidakpastian awal dalam perumusan. (Kerangka waktu yang lama untuk pemrogram aplikasi untuk memecahkan masalah analitis karena formulasi yang kurang dipahami dan modifikasi program yang lama ketika perubahan kondisi sering ditemui dalam praktik.)

    Perhatikan juga fakta bahwa setiap karyawan perusahaan dapat mengumpulkan dari bidang umum analis OLAP persis tanaman yang dia butuhkan untuk bekerja, dan tidak puas dengan "strip" yang telah dia potong dalam "laporan standar" komunal ”.

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

    Artinya, kubus OLAP memungkinkan Anda membuat pekerjaan analitik (yang sebenarnya dilakukan tidak hanya oleh analis catatan, tetapi, sebenarnya, oleh hampir semua karyawan perusahaan, bahkan ahli logistik dan manajer yang mengontrol saldo dan pengiriman) lebih selektif, “ dari wajah bukan dalam ekspresi umum” , yang menciptakan kondisi untuk meningkatkan kerja dan meningkatkan produktivitas.

    Menyimpulkan pengantar kami, kami mencatat bahwa penggunaan kubus OLAP dapat meningkatkan manajemen perusahaan ke tingkat yang lebih tinggi. Keseragaman data analitik di semua tingkat hierarki, keandalan, kompleksitas, kemudahan membuat dan memodifikasi indikator, pengaturan individu, kecepatan pemrosesan data yang tinggi, dan terakhir, menghemat uang dan waktu yang dihabiskan untuk mendukung jalur analitik alternatif (pemrogram aplikasi, independen perhitungan seorang karyawan), prospek terbuka untuk penggunaan kubus OLAP dalam praktik perusahaan besar Rusia.

    OLTP + OLAP: umpan balik dalam rantai manajemen perusahaan

    Sekarang pertimbangkan gagasan umum kubus OLAP dan titik penerapannya dalam rantai manajemen perusahaan. Istilah OLAP (OnLine Analytical Processing) diperkenalkan oleh ahli matematika Inggris Edgar Codd selain istilah sebelumnya OLTP (OnLine Transactions Processing). Ini akan dibahas nanti, tetapi E. Codd, tentu saja, tidak hanya mengusulkan istilah, tetapi juga teori matematika OLTP dan OLAP. Tanpa merinci, dalam interpretasi modern OLTP adalah basis data relasional, dianggap sebagai mekanisme untuk mendaftar, menyimpan, dan mengambil informasi.

    Metodologi solusi

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

    Perhatikan bahwa informasi yang terdaftar di database sistem ERP memang merupakan sumber daya yang sangat berharga. Intinya bukan hanya informasi yang terdaftar memberikan alur kerja korporasi saat ini (penerbitan dokumen, koreksi mereka, kemungkinan pencetakan dan rekonsiliasi, dll.) Dan bukan hanya kemungkinan penghitungan laporan keuangan(pajak, audit, dll). Dari sudut pandang manajemen, jauh lebih penting bahwa sistem OLTP (database relasional), pada kenyataannya, adalah model digital aktual dari aktivitas perusahaan dalam ukuran penuh.

    Tetapi untuk mengelola prosesnya, tidak cukup hanya mendaftarkan informasi tentangnya. Proses tersebut harus disajikan sebagai sistem indikator numerik (KPI) yang mencirikan jalannya. Selain itu, rentang nilai yang diizinkan harus ditentukan untuk indikator. Dan hanya jika nilai indikator melampaui interval yang diizinkan, tindakan kontrol harus dilakukan.

    Mengenai logika (atau mitologi) manajemen seperti itu ("manajemen dengan penyimpangan") bertemu dan filsuf Yunani kuno Plato, yang menciptakan gambar juru mudi (cyber nose), yang bersandar pada dayung saat 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 satu sistem lagi - sistem untuk menganalisis informasi yang dikumpulkan. Add-in ini, yang dalam loop kontrol memainkan peran umpan balik antara manajemen dan objek kontrol, adalah sistem OLAP atau, singkatnya, kubus OLAP.

    Sebagai implementasi perangkat lunak OLAP, kami akan mempertimbangkan utilitas Layanan Analisis MS, yang merupakan bagian dari pengiriman standar MS SQL Server, disingkat SSAS. Perhatikan bahwa menurut ide E. Codd, kubus OLAP dalam analitik harus memberikan kebebasan penuh yang sama untuk bertindak seperti yang diberikan oleh sistem OLTP dan database relasional (SQL Server) dalam menyimpan dan mengambil informasi.

    Logistik OLAP

    Sekarang mari kita pertimbangkan konfigurasi khusus perangkat eksternal, aplikasi, dan operasi teknologi yang menjadi dasar operasi otomatis kubus OLAP.

    Kami akan berasumsi bahwa perusahaan menggunakan sistem ERP, misalnya, 1C7 atau 1C8, di mana informasi didaftarkan dengan cara biasa. Basis data sistem ERP ini terletak di server tertentu dan dikelola oleh MS SQL Server.

    Kami juga akan berasumsi bahwa perangkat lunak diinstal di server lain, termasuk MS SQL Server dengan utilitas MS Analysis Services (SSAS), serta program 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 gratis yang disebut blat, yang dipanggil (dengan parameter) dari baris perintah dan menyediakan layanan email.

    Di stasiun kerja karyawan, di dalam jaringan lokal, antara lain, program MS Excel (versi 2003 atau lebih tinggi) diinstal, serta, mungkin, driver khusus untuk memungkinkan MS Excel bekerja dengan Layanan Analisis MS (kecuali driver yang sesuai sudah disertakan dalam MS Excel).

    Untuk kepastian, kami akan berasumsi bahwa stasiun kerja karyawan memiliki sistem operasi Windows XP, dan di server - Windows Server 2008. Selain itu, biarkan MS SQL Server 2005 digunakan sebagai SQL Server, dan Edisi Perusahaan (EE) atau Edisi Pengembang (DE) diinstal di server dengan kubus OLAP. Dalam edisi ini, dimungkinkan untuk menggunakan apa yang disebut. "tindakan semi-aditif", yaitu. fungsi agregat tambahan (statistik) selain jumlah reguler (misalnya nilai ekstrem atau rata-rata).

    Desain kubus OLAP (OLAP kubisme)

    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 di bagian pembeli, barang, tanggal, dll. Karena terjemahan langsung dari bahasa Inggris dalam literatur Rusia pada kubus OLAP, indikator disebut "ukuran", dan pemotongan disebut "dimensi". Ini adalah terjemahan yang benar secara matematis, tetapi secara sintaksis dan semantik tidak terlalu berhasil. Kata Rusia "measure", "measurement", "dimension" hampir tidak berbeda dalam arti dan ejaan, sedangkan bahasa Inggris "measure" dan "dimension" berbeda baik dalam ejaan maupun arti. Oleh karena itu, kami lebih suka istilah statistik tradisional Rusia yang artinya mirip dengan "indikator" dan "pemotongan".

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

    Dalam skema ini, OLAP dan OLTP tidak memiliki tabel umum, dan analitik OLAP dihitung sedetail mungkin pada tahap Cube Update (Proses) sebelum tahap penggunaan. Skema ini disebut MOLAP (Multidimensional OLAP). Kerugiannya adalah asinkron dengan ERP dan biaya memori yang tinggi.

    Meskipun secara formal kubus OLAP dapat dibangun 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 "warehouse" (gudang).

    Ada beberapa alasan mengapa hal ini terjadi.

    • Pertama, menautkan kubus OLAP ke tabel dalam database nyata pasti akan menimbulkan masalah teknis. Mengubah data dalam tabel dapat memicu penyegaran kubus, dan menyegarkan kubus belum tentu merupakan proses yang cepat, sehingga kubus akan berada dalam kondisi pembangunan kembali permanen; pada saat yang sama, prosedur pembaruan kubus dapat memblokir (selama membaca) data dari tabel database, memperlambat pekerjaan pengguna dalam mendaftarkan data di sistem ERP.
    • Kedua, kehadiran terlalu banyak indikator dan pemotongan akan secara dramatis meningkatkan area penyimpanan kubus di server. Jangan lupa bahwa kubus OLAP tidak hanya menyimpan data awal, seperti dalam sistem OLTP, tetapi juga semua indikator yang diringkas untuk semua bagian yang memungkinkan (dan bahkan untuk semua kombinasi dari semua bagian). Selain itu, kecepatan memperbarui kubus dan, pada akhirnya, kecepatan membangun dan memperbarui analitik dan laporan pengguna berdasarkan itu akan melambat.
    • Ketiga, terlalu banyak bidang (ukuran dan aspek) akan menimbulkan masalah di antarmuka pengembang OLAP, karena daftar elemen akan menjadi tidak terbatas.
    • Keempat, Kubus OLAP sangat sensitif terhadap pelanggaran integritas data. Kubus tidak dapat dibangun jika data kunci tidak ditemukan oleh tautan yang ditentukan dalam struktur tautan bidang kubus. Pelanggaran integritas sementara atau permanen, bidang kosong sering terjadi di database sistem ERP, tetapi ini jelas tidak cocok untuk OLAP.

    Anda juga dapat menambahkan bahwa sistem ERP dan kubus OLAP harus ditempatkan di server yang berbeda untuk berbagi beban. Namun, jika ada tabel umum untuk OLAP dan OLTP, ada juga masalah lalu lintas jaringan. Masalah praktis yang tidak dapat dipecahkan muncul dalam kasus ini jika perlu menggabungkan beberapa sistem ERP yang heterogen (1C7, 1C8, MS Dynamics AX) menjadi satu kubus OLAP.

    Mungkin, adalah mungkin untuk menumpuk masalah teknis lebih lanjut. Namun yang terpenting, ingatlah bahwa, tidak seperti OLTP, OLAP bukanlah alat untuk mendaftarkan dan menyimpan data, melainkan alat analitik. Artinya, tidak perlu memuat dan memuat data "kotor" dari ERP ke OLAP "untuk berjaga-jaga". Sebaliknya, Anda harus terlebih dahulu mengembangkan konsep untuk mengelola perusahaan, setidaknya di tingkat sistem KPI, dan kemudian merancang gudang data aplikasi (gudang) yang terletak di server yang sama dengan kubus OLAP dan berisi sejumlah kecil ERP yang disempurnakan. data yang diperlukan untuk manajemen.

    Tanpa mempromosikan kebiasaan buruk, kubus OLAP dalam kaitannya dengan OLTP dapat disamakan dengan "alembic" yang terkenal di mana "produk bersih" diekstraksi dari "massa yang difermentasi" dari registrasi nyata.

    Jadi, kami mendapatkan bahwa sumber data untuk OLAP adalah database khusus (gudang) yang terletak di server yang sama dengan OLAP. Pada dasarnya, 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.

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

    Arsitektur solusi

    Biarlah ada banyak sistem ERP dari perusahaan tertentu (memegang) di server yang berbeda, yang kami ingin lihat data analitiknya dikonsolidasikan dalam satu kubus OLAP. Kami menekankan bahwa dalam teknologi yang dijelaskan, kami menggabungkan data dari sistem ERP di tingkat gudang, membiarkan desain kubus OLAP tidak berubah.

    Di server OLAP, kami membuat gambar (salinan kosong) dari database semua sistem ERP ini. Untuk salinan kosong ini, kami secara berkala (setiap malam) melakukan replikasi sebagian dari database ERP yang aktif berjalan terkait.

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

    Kemudian prosedur standar untuk memperbarui / membangun kubus sesuai dengan data gudang diluncurkan (Operasi proses di antarmuka SSAS).

    Mari kita komentari beberapa aspek teknologi. Apa jenis pekerjaan yang dilakukan SP?

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

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

    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 dari gambar salinan (jika salinan tabel pada awalnya tidak berisi semua bidang).

    Tentu saja, tidak mungkin menyalin seluruh baris tabel, tetapi hanya menambahkan catatan baru. Namun, hal ini menimbulkan ketidaknyamanan yang serius saat memperhitungkan revisi ERP "backdating", yang sering ditemukan dalam sistem kehidupan nyata. Jadi lebih mudah, tanpa basa-basi lagi, untuk menyalin semua catatan (atau perbarui "ekor" mulai dari tanggal tertentu).

    Selanjutnya, tugas utama SP adalah mengubah data dari sistem ERP ke format gudang. Jika hanya ada satu sistem ERP, maka tugas transformasi terutama direduksi menjadi menyalin dan mungkin memformat ulang data yang diperlukan. Tetapi jika Anda perlu menggabungkan beberapa sistem ERP dalam kubus OLAP yang sama struktur yang berbeda, maka transformasi menjadi lebih rumit.

    Yang paling sulit adalah tugas mengkonsolidasikan beberapa sistem ERP yang berbeda dalam sebuah kubus, jika kumpulan objeknya (direktori barang, kontraktor, gudang, dll.) berpotongan sebagian, objek tersebut memiliki arti yang sama, tetapi secara alami mereka dijelaskan secara berbeda di direktori sistem yang berbeda(dalam arti kode, pengidentifikasi, nama, dll.).

    Kenyataannya, gambaran seperti itu muncul di perusahaan induk besar, ketika beberapa perusahaan otonom sejenis yang membentuknya melakukan jenis kegiatan yang kurang lebih sama di wilayah yang kurang lebih sama, tetapi menggunakan sistem pendaftaran mereka sendiri dan tidak terkoordinasi. Dalam hal ini, saat menggabungkan data di tingkat gudang, Anda tidak dapat melakukannya tanpa tabel pemetaan tambahan.

    Mari perhatikan arsitektur penyimpanan gudang. Biasanya, skema kubus OLAP direpresentasikan sebagai "bintang", mis. sebagai tabel data yang dikelilingi oleh "sinar" direktori - tabel nilai kunci sekunder. Tabel adalah blok "indikator", buku referensi adalah potongannya. Pada saat yang sama, direktori, pada gilirannya, dapat berupa pohon tidak seimbang yang sewenang-wenang atau hierarki yang seimbang, misalnya, klasifikasi barang atau rekanan bertingkat. Dalam kubus OLAP, bidang numerik dari tabel data dari gudang secara otomatis menjadi "indikator" (atau mengukur ukuran), dan bagian (atau dimensi) dapat ditentukan melalui tabel kunci sekunder.

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

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

    Kedua, "ray" dari tanda bintang mungkin bukan satu direktori, tetapi seluruh sistem file (hierarkis).

    Ketiga, berdasarkan pemotongan dimensi yang ada, pemotongan hierarkis baru dapat ditentukan menggunakan antarmuka pengembang OLAP (katakanlah, dengan level yang lebih sedikit, dengan urutan level yang berbeda, dll.)

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

    MS Excel sebagai antarmuka dengan OLAP

    Yang menarik adalah antarmuka pengguna dengan kubus OLAP. Secara alami, utilitas SSAS sendiri menyediakan antarmuka terlengkap. Ini adalah 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, yang mencakup sebagian besar atau lebih kecil fungsinya. Namun di antara mereka ada satu yang menurut kami memiliki kelebihan yang tak terbantahkan. Ini MS Excel.

    Antarmuka dengan MS Excel disediakan oleh driver khusus, yang dapat diunduh secara terpisah atau disertakan dengan Excel. Itu tidak mencakup semua fungsionalitas OLAP, tetapi dengan pertumbuhan nomor versi MS Excel, cakupan ini menjadi lebih luas (katakanlah, di MS Excel 2007 grafik KPI muncul, yang tidak ada di MS Excel 2003, dll.).

    Tentu saja, selain fungsionalitas yang cukup lengkap, keunggulan utama MS Excel adalah distribusi program ini di mana-mana dan pengenalan yang dekat dengannya dari sebagian besar pengguna kantor. Dalam pengertian ini, tidak seperti program antarmuka lainnya, perusahaan tidak perlu memperoleh tambahan apa pun dan tidak perlu melatih siapa pun sebagai tambahan.

    Keuntungan besar MS Excel sebagai antarmuka dengan OLAP adalah kemungkinan pemrosesan independen lebih lanjut dari data yang diperoleh dalam laporan OLAP (yaitu, kelanjutan studi data yang diperoleh dari OLAP di lembar lain dari Excel yang sama, tidak lagi menggunakan alat OLAP, tetapi menggunakan alat Excel biasa).

    Siklus perawatan facubi setiap malam

    Sekarang mari kita gambarkan siklus komputasi harian (malam hari) dari operasi OLAP. Perhitungan dilakukan di bawah kendali program facubi, ditulis dalam C # 2005 dan diluncurkan menggunakan Penjadwal Tugas di server dengan gudang dan SSAS. Pada awalnya, facubi mengakses internet dan membaca kurs saat ini (digunakan untuk mewakili sejumlah indikator dalam mata uang). Selanjutnya, langkah-langkah berikut dilakukan.

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

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

    • data ERP dibawa di bawah format kubus yang diperlukan; kita berbicara tentang tabel dan bidang tabel. (Terkadang tabel yang diperlukan perlu "dibentuk", katakanlah, dari beberapa lembar MS Excel.) Data serupa dapat memiliki format berbeda di ERP yang berbeda, misalnya, bidang ID kunci dalam direktori 1C7 memiliki kode 36 karakter dengan panjang 8 , dan bidang _idrref dalam direktori 1C8 - bilangan heksadesimal dengan panjang 32;
    • selama pemrosesan kontrol logis atas data dilakukan (termasuk meresepkan default "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 yang sesuai dari ERP yang berbeda dapat memiliki arti yang sama, katakanlah, ini adalah rekanan yang sama. Tugas mengkonsolidasikan kode diselesaikan dengan membuat tabel pemetaan, di mana kode yang berbeda dari objek yang sama disatukan.

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

    Menurut daftar periksa, facubi mengirimkan pesan email tentang kemajuan langkah pemrosesan.

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

    Pengguna jaringan lokal dengan akses ke server SSAS akan menerima laporan "langsung" yang dikonfigurasi untuk kubus OLAP. (Pada prinsipnya, mereka sendiri, tanpa surat 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 laporan OLAP di MS Excel) laporan "mati" khusus akan dihitung yang tidak menghubungi server SSAS.

    Evaluasi hasil

    Kami berbicara di atas tentang asinkron OLTP dan OLAP. Dalam versi teknologi yang dipertimbangkan, siklus pembaruan kubus OLAP dilakukan pada malam hari (misalnya, dimulai pada jam 1 pagi). Artinya pada hari kerja saat ini, pengguna bekerja dengan data kemarin. Karena OLAP bukanlah alat logging (lihat versi terbaru dokumen), tetapi alat manajemen (pahami tren prosesnya), backlog ini biasanya tidak kritis. Namun, jika perlu, bahkan dalam versi arsitektur kubus (MOLAP) yang dijelaskan, dimungkinkan untuk memperbarui beberapa kali sehari.

    Waktu pelaksanaan prosedur pembaruan bergantung pada fitur desain kubus OLAP (kompleksitas lebih atau kurang, definisi indikator dan bagian yang kurang lebih berhasil) dan pada volume database sistem OLTP eksternal. Menurut pengalaman, prosedur pembangunan gudang memakan waktu dari beberapa menit hingga dua jam, prosedur pembaruan kubus (Proses) membutuhkan waktu 1 hingga 20 menit. Kita berbicara tentang kubus OLAP kompleks yang menggabungkan lusinan struktur bintang, tentang lusinan "sinar" (pemotongan referensi) yang umum untuknya, tentang ratusan indikator. Memperkirakan volume database sistem ERP eksternal dengan mengirimkan dokumen, kita berbicara tentang ratusan ribu dokumen dan, karenanya, jutaan lini produk per tahun. Kedalaman historis pemrosesan yang menarik bagi pengguna adalah tiga hingga lima tahun.

    Teknologi yang dijelaskan 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 korporasi didominasi oleh perusahaan perdagangan pembelian (RRK), yang lain adalah perusahaan produksi (pabrik pengolahan ikan dan makanan laut di Republik Moldova dan Dewan Keamanan). Semua perusahaan adalah kepemilikan 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 termasuk dalam tanggung jawab seorang analis bisnis penuh waktu. Tugas tersebut telah berputar selama bertahun-tahun dalam mode otomatis, setiap hari memasok berbagai kategori karyawan perusahaan dengan pelaporan terkini.

    Pro dan kontra dari solusi

    Seperti yang diperlihatkan oleh pengalaman, varian dari solusi yang diusulkan cukup andal dan mudah dioperasikan. Ini mudah dimodifikasi (menghubungkan / memutuskan ERP baru, membuat indikator dan bagian baru, membuat dan memodifikasi laporan Excel dan milisnya) dengan invarian program kontrol facubi.

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

    Basis data gudang yang "disempurnakan", di mana beberapa sistem ERP heterogen dikonsolidasikan (selama konstruksi kubus), bahkan tanpa OLAP apa pun, memungkinkan penyelesaian (di server SSAS, menggunakan metode kueri Transact SQL atau metode SP, dll.) a banyak tugas manajemen yang diterapkan. Ingatlah bahwa struktur basis data gudang disatukan dan jauh lebih sederhana (dalam hal jumlah tabel dan jumlah bidang tabel) daripada struktur basis data ERP asli.

    Kami secara khusus mencatat bahwa dalam solusi yang kami usulkan ada kemungkinan untuk mengkonsolidasikan berbagai sistem ERP dalam satu kubus OLAP. Hal ini memungkinkan Anda mendapatkan analitik untuk seluruh holding dan mempertahankan kontinuitas jangka panjang dalam analitik saat perusahaan pindah ke sistem akuntansi ERP lainnya, misalnya, saat berpindah dari 1C7 ke 1C8.

    Kami menggunakan model kubus MOLAP. Keunggulan model ini adalah keandalan dalam pengoperasian dan kecepatan tinggi dalam memproses permintaan pengguna. Kontra - OLAP dan OLTP asinkron, serta memori dalam jumlah besar untuk menyimpan OLAP.

    Sebagai kesimpulan, mari kita berikan satu argumen lagi yang mendukung OLAP, yang mungkin lebih tepat di Abad Pertengahan. Karena kekuatan probatifnya bertumpu pada otoritas. Ahli matematika Inggris E. Codd yang sederhana dan jelas diremehkan mengembangkan teori basis data relasional di akhir tahun 60-an. Kekuatan teori ini sedemikian rupa sehingga sekarang, setelah 50 tahun, sudah sulit menemukan basis data non-relasional dan bahasa kueri basis data selain SQL.

    Teknologi OLTP, berdasarkan teori database relasional, adalah ide pertama E. Codd. Padahal, konsep kubus OLAP adalah ide keduanya, yang diungkapkannya di awal tahun 90-an. Bahkan jika Anda bukan ahli matematika, Anda mungkin berharap ide kedua sama efektifnya dengan yang pertama. Artinya, dalam hal analitik komputer, ide OLAP akan segera mengambil alih dunia dan menggantikan yang lainnya. Hanya karena topik analitik menemukan solusi matematisnya yang lengkap di OLAP, dan solusi ini "memadai" (istilah B. Spinoza) untuk tugas praktis analitik. "Cukup" berarti di Spinoza bahwa bahkan Tuhan sendiri tidak dapat memberikan ide yang lebih baik ...

    1. Larson B. Pengembangan intelijen bisnis di Microsoft SQL Server 2005. - St. Petersburg: "Piter", 2008.
    2. Codd E. Kelengkapan Relasional Subbahasa Basis Data, Sistem Basis Data, Courant Ilmu Komputer Seri Sumposia 1972, v. 6, tebing Englwood, N.Y., Prentice–Hall.

    Berhubungan dengan