Model Kubus Data Melihat data sebagai kubus.

Slides:



Advertisements
Presentasi serupa
Kiky Rizky Nova Wardani, S.Kom
Advertisements

Data Warehousing :: DWH Design
Model Kubus Data Melihat data sebagai kubus.
PERINTAH SQL.
5.
SISTEM BUKU BESAR DAN PELAPORAN
OLAP - PERTEMUAN 8 – OLAP.
Pertemuan #2 OLAP.
Team Keamanan Data Direktorat Sistem Informasi Universitas Airlangga
DML Lanjutan Pertemuan Minggu Ke-10.
Data Warehouse dan Decision Support
Dimentional Design Retail Store.
Data Mart dan Metadata Data Warehouse
Pengenalan Data Warehouse
Desain Data Warehouse (Dimensional Modelling)
Dimensional Modeling Achmad Yasid.
Dimensional Modeling Achmad Yasid.
Data Warehousing Sistem Basis Data Lanjut Prepared by: MT. Wilson
PEMODELAN DATA.
PENJELASAN UMUM SILABUS SISTEM BASIS DATA
Data Mart dan Metadata Data Warehouse
Arsitektur Data Warehouse
Dika Anjar Pratiwi Ken Mentari Tilammura Agung Wibowo.
Sumber Data untuk DW Data operasional dalam organisasi, misalnya basis data pelanggan dan produk, dan Sumber eksternal yang diperoleh misalnya melalui.
SISTEM INFORMASI Pertemuan 5.
Dimensional Modeling (Advance)
Desain Database Disusun Oleh : Dr. Lily Wulandari
P E R T E M U A N 12 SISTEM BASIS DATA.
Pertemuan VII Perancangan Datawarehouse. Perancangan Datawarehouse dengan Microsoft SQL Server.
Perancangan Data Warehouse
Konsep dan Teknik Data Mining
Pertemuan VI Desain Data Warehouse (Dimensional Modelling)
Desain Data Warehouse (Dimensional Modelling)
PERTEMUAN 10 QUERY KOMERSIAL LANJUTAN Agus Riyanto, S.Kom.
Surrogate Key & Slowly Changing Dimensions. SURROGATE KEY.
Pertemuan VIII Dimensional Modelling. Relational Database Model FMMFFMMF Anderson Green Lee Ramos Attribute 1 Name Attribute 2 Age Attribute.
Informasi Dalam Praktik
DATA WAREHOUSE (2nd) Presented by HANIM M.A – M. IRWAN AFANDI.
Presented by HANIM M.A. DATA WAREHOUSE (2nd) Presented by HANIM M.A.
MANAJEMEN INFORMASI: PERANCANGAN DATABASE
Pemodelan Data Dimensional dengan OLAP
Pertemuan Ke-6 Aljabar Relasional
Model Data Relasional.
PEMBANDINGAN KINERJA JEDOX PALO VERSI 1. 0c DENGAN VERSI 2
KECERDASAN BISNIS Data Warehouse, Data Mart, OLAP, dan Data Mining
Penambahan Operasi OLAP dan Fungsi Agregat pada Temporal Data Warehouse Tanaman Pangan Kabupaten Karo Oleh : Karina Gusriani – G Pembimbing : Ibu.
Pemrograman Visual Akuntansi III
Konsep Teknologi Informasi B
Data Warehouse, Data Mart, OLAP, dan Data Mining
Operasi-Operasi pada Data Warehouse
Charitas Fibriani, S.Kom, M.Eng
Operator Summary Slice Dice Drill-down Roll-up Pivot
Perancangan Data Warehouse
Presented by HANIM M.A. DATA WAREHOUSE (2nd) Presented by HANIM M.A.
Perancangan Penyimpanan Data
Perancangan Fisik Basis Data
Perancangan Data Logis dan Fisik
METODE PENGEMBANGAN DATAWAREHOUSE
Business Intelligent Ramos Somya, S.Kom., M.Cs.
Metodologi dan Pengembangan Data Warehouse
Analisis Multidimensional
PRODI MIK | FAKULTAS ILMU-ILMU KESEHATAN
Business Intelligence Ramos Somya, S.Kom., M.Cs.
DATA WAREHOUSE AND OLAP TECHNOLOGI FOR DATA MINING
Introduction to Data Warehouse By: Marcello Singadji
Business Intelligent Ramos Somya, S.Kom., M.Cs.
Model Data Relasional.
Operasi-Operasi pada Data Warehouse Business Intelligent Ramos Somya, S.Kom., M.Cs.
Skema Star (Dalam RDBMS)
Kiky Rizky Nova Wardani, S.Kom
Transcript presentasi:

Model Kubus Data Melihat data sebagai kubus

Skema Star (Dalam RDBMS) Ukuran

Contoh Skema Star Ukuran

Skema Star Dengan Data Sampel

Skema Star Dengan Data Sampel Fakta product nomor 110 selama periode 002: 30 unit terjual di toko S1. Total penjualan dalam dollar 1500, dan total cost dalam dollar 1200 40 unit terjual di toko S3. Total penjualan dalam dollar 2000, dan total cost dalam dollar 1200 Ukuran tabel fakta: Misal jumlah total toko 1000, jumlah total product 10000, jumlah total periode 24 (data berharga 2 tahun) Misal rata-rata 50% (atau 5000) record penjualan selama suatu bulan tertentu.

Skema Star Dengan Data Sampel Ukuran tabel fakta: Taksiran jumlah baris dalam tabel fakta dihitung sebagai berikut: total baris= 1000 toko x 5000 produk aktif x 24 bulan = 120,000,000 baris Tebal fakta memiliki 6 field, dimana rata-rata field panjangnya 4 byte. Total size=120,000,000 baris x 6 field x 4 byte/field = 2,880,000,000 bytes

Skema Star “Klasik” Suatu tabel fakta tunggal dengan data detail dan ringkasan Primary key tabel fakta hanya memiliki satu kolom key per dimensi Masing-masing key dibangun Masing-masing dimensi adalah suatu tabel tunggal, yang didenormalisasi Keuntungan: Mudah dipahami, mudah didefinisikan secara hierarki, mengurangi jumlah join fisik, low maintenance, metadata sangat sederhana Kekurangan: Ringkasan data dalam tabel fakta menghasilkan kinerja yang buruk untuk level ringkasan dan juga untuk tabel dimensi yang besar

Skema Star “Klasik” Contoh: Kekurangan terbesar: tabel dimensi harus membawa suatu indikator level sehingga setiap record dan setiap query harus menggunakannya. Dalam contoh dibawah, tanpa level kendali, key untuk seluruh store dalam region NORTH, termasuk agregasi pada region dan distrik akan dikeluarkan dari tabel fakta, mengeluarkan error. Contoh: Select A.STORE_KEY, A.PERIOD_KEY, A.dollars from Fact_Table A where A.STORE_KEY in (select STORE_KEY from Store_Dimension B where region = “North” and Level = 2) dan seterusnya….. Level diperlukan bila agregasi disimpan dengan fakta detail.

Problem “Level” Level adalah suatu problem sebab level potensial menyebabkan error. Jika pembuat query, manusia atau program, melupakan ini, jawaban yang salah dipastikan bisa terjadi. Salah satu alternatif: model konstelasi fakta...

Skema Konstelasi Fakta District Fact Table Region Fact Table District_ID PRODUCT_KEY PERIOD_KEY Region_ID PRODUCT_KEY PERIOD_KEY Dollars Units Price Dollars Units Price

Skema Konstelasi Fakta Dalam konstelasi fakta, tabel agregasi dibuat terpisah dari detail, karenanya adalah tak mungkin mengambil, misalnya, detail Store ketika meng-query tabel fakta District. Keuntungan Utama: Indikator “Level” tidak diperlukan lagi didalam tabel dimensi, karena tidak ada data agregasi yang disimpan dengan level detail lebih rendah. Kerugian: Tabel dimensi masih tetap sangat besar dalam beberapa kasus, yang akan memperlambat kinerja; front-end harus mampu mendeteksi keberadaan fakta agregasi, yang memerlukan metadata yang lebih ekstensif

Alternatif Lain Untuk “Level” Konstelasi fakta adalah suatu alternatif yang baik untuk skema star, tetapi ketika dimensi memiliki kardinalitas yang sangat tinggi, sub-selects dalam tabel dimensi bisa menjadi suatu sumber kelambatan. Suatu alternatif adalah menormalisasikan tabel dimensi melalui level atribut, dimana setiap tabel dimensi yang lebih kecil menunjuk ke suatu tabel agregasi fakta yang sesuai, “Skema Snowflake” ...

Skema Snowflake STORE KEY Store Dimension District_ID PRODUCT KEY Store Description City State District ID District Desc. Region_ID Region Desc. Regional Mgr. District_ID PRODUCT KEY PERIOD KEY Dollars Units Price Store Fact Table District Fact Table PRODUCT_KEY PERIOD_KEY RegionFact Table

Skema Snowflake Tidak ada LEVEL dalam tabel dimensi Tabel dimensi dinormalisasikan dengan menguraikan pada level atribut Masing-masing tabel dimensi memiliki satu key untuk setiap level dari hierarki dimensi Key level terendah mengabungkan tabel dimensi ke tabel fakta dan tabel level atribut lebih rendah Bagaimana ini bekerja? Cara terbaik query dibangun adalah dengan memahami level ringkasan apa yang ada, dan mencari tabel atribut snowflake normal, membatasinya untuk kunci, lalu memilih dari tabel fakta

Skema Snowflake Fitur tambahan: tabel dimensi Store asli, yang didenormalisasi sepenuhnya, dipertahankan utuh, karena query tertentu bisa mengambil keuntungan melalui seluruh isi yang dikandungnya. Dalam praktek, mulai dengan skema start dan buat “snowflakes” dengan query. Ini mengurangi kebutuhan untuk membuat ekstraksi terpisah untuk setiap tabel, dan integritas referensial diwarisi dari tabel dimensi Keuntungan: Kinerja terbaik saat query melibatkan agregasi Kerugian: maintenance dan metadata yang rumit, ledakan jumlah tabel didalam database

Suatu Konsep Hierarki: Dimensi (location) all all region Europe ... North_America country Germany ... Spain Canada ... Mexico city Vancouver ... Frankfurt ... Toronto office L. Chan ... M. Wind

Data Multidimensi Volume Sales sebagai suatu fungsi dari product, month, dan region Dimensi: Product, Location, Time Path intisari hierarkikal Region Industry Region Year Category Country Quarter Product City Month Week Office Day Product Month

Contoh Kubus Data Volume Sales sebagai suatu fungsi time, city, dan product NY LA SF Juice Cola Milk Cream 10 47 30 12 3/1 3/2 3/3 3/4 Date

Contoh Kubus Data Date Product Country Semua, Semua, Semua Total penjualan TV Setahun di U.S.A. Date 1Qtr 2Qtr 3Qtr 4Qtr sum TV Product PC U.S.A VCR sum Canada Country Mexico sum Semua, Semua, Semua

Bentuk Kubus Yang Terkait Dengan Kubus Data 0-D(apex) cuboid all product country date 1-D cuboids product,country date, country product,date 2-D cuboids product, date, country 3-D(base) cuboid

Browsing Suatu Kubus Data Visualisasi Kapabilitas OLAP Manipulasi Interaktif

Operasi Kubus Data OLAP Roll up (drill-up): merujuk ke peningkatan hierarki atau pengurangan dimensi (diberikan total sales by “city”, di roll-up untuk mendapatkan total sales by “state”) Drill down (roll down, kebalikan roll-up): merujuk ke penurunan hierarki atau penambahan dimensi (diberikan total sales by “state”, di roll-down untuk mendapatkan total sales by “city”) Slice: merujuk ke pemilihan dimensi yang digunakan untuk melihat kubus (“customer” by “product” by “date”)

Operasi Kubus Data OLAP Dice: merujuk ke pemilihan posisi sesungguhnya sepanjang dimensi (bagian dari kubus slice dimana product = “Mr. Snowman”) Pivot (rotasi): reorientasi kubus, visualisasi, 3D ke sebarisan bidang 2D Operasi lain: drill across: melibatkan lebih dari satu tabel fakta drill through: melalui level terbawah dari kubus tersebut ke tabel back-end relasionalnya (menggunakan SQL)

Operasi Kubus Data OLAP

Operasi Kubus Data OLAP

Rancangan Suatu Data Warehouse: Suatu Kerangka Analisa Bisnis Tinjauan perihal rancangan dari suatu data warehouse Top-down Memungkinkan seleksi informasi yang relevan, yang perlu untuk data warehouse (perspektif user) Sumber data Membuka informasi yang akan ditangkap, disimpan, dan ditangani oleh sistem operasi (perspektif sumber data)

Rancangan Suatu Data Warehouse: Suatu Kerangka Analisa Bisnis Terdiri dari tabel-tabel fakta dan dimensi tabel (tinjauan dari dalam data warehouse) Query bisnis Melihat perspektif data dalam warehouse dari sisi tinjauan end-user

Contoh Kubus Data

Contoh Kubus Data

Contoh Kubus Data

Contoh Kubus Data