640 likes | 986 Views
Desain Data Warehouse (Dimensional Modelling ). Mendisain Sebuah Data Warehouse. Mendisain database untuk data warehouse adalah problem utama dalam mendisain data warehouse Ada dua pendekatan utama dalam perancangan data warehouse Pemodelan dan normalisasi entity relationship (ER)
E N D
Mendisain Sebuah Data Warehouse • Mendisain database untuk data warehouse adalah problem utamadalammendisain data warehouse • Adaduapendekatanutamadalamperancangan data warehouse • Pemodelandannormalisasi entity relationship (ER) • Pemodelanberdimensi
Perancangan Database MenggunakanPendekatan E-R yang Tradisional • Entities and Relationships • AturanNormalisasi(Umumnya 3NF) • Menjagaintegritas database denganmenghindarianomali (prosespada basis data yang memberikanefeksamping yang tidakdiharapkan, misalnyamenyebabkanketidakkonsistenan data ataumembuatsesuatu data menjadihilangketika data lain dihapus)
Bentuk Normal Pertama (1NF) Definisi bentuk normal pertama adalah sbb: • Suatu relasi dikatakan dalam bentuk normal pertama jika dan hanya jika setiap atribut bernilai tunggal untuk setiap baris.
Bentuk Normal Kedua (2NF) Bentuk normal kedua didefinisikan berdasarkan dependensi Fungsional • Suatu relasi berada dalam bentuk normal kedua(2NF) jika dan hanya jika:Telah melalui bentuk normal pertama • Semua atribut bukan kunci memiliki ketergantungan sepenuhnya terhadap kunci primer
Ketergantunganfungsisepenuhnya Suatuatribut Y mempunyaiketergantunganfungsi penuhterhadapatribut X, jikaYmempunyaiketergantunganfungsiterhadap X Y tidakmemilikidependensiterhadapbagiandari X Definisidiatasdituangkandalambentuknotasi X Y Contoh: Nilai : (NPM, Kd-Mt-Kul, Nilai) {NPM, Kd-Mt-Kul} Nilai NPM Nilai (Tidakmemiliki dependency) Kd-Mt-KulNilai (Tidakmemiliki dependency)
Berdasarkan diagram dependensifungsionaldiatas, pendekomposisianakanmenghasilkanduabuahrelasi, yang misalnyadisebutdenganPEGAWAI dan HISTORY PEGAWAI sepertiberikutini.
Bentuk Normal ketiga (3NF) DefinisiBentuk normal ketiga: • Suatu relasi berada dalam bentuk normal ketiga (3NF) jika Telahmelaluibentuk normal Kedua • Semuaatributbukankuncitidakmemilikidependensitransitifterhadapkunci primer KhususuntukRelasi PEGAWAI sudahdapatmemenuhisyaratuntukbentuk normal ketiga (3NF), karena TGLLAHIR danALAMATtidakmemilikihubungantransitifterhadap NIP.
Ketergantungantransitif SuatuAtribut Z mempunyaiketergantungantransitif terhadap X, bila: Y memilikiketergantunganfungsiterhadap X Z memilikiketergantunganfungsiterhadap Y Definisidiatasdituangkandalambentuknotasi X Y Z Contoh: JADWAL : (MT-KULIAH, RUANG, LANTAI, WAKTU) Dengandemikiannotasidapatditulis : MT-KULIAH RUANG LANTAI LANTAI ketergantungantransitifterhadap MT-KULIAH.
Namun Relasi HISTORY-PEGAWAI belum termasuk normal 3NF dan harus didekomposisi lagi, Menjadi:
Contoh Normalisasi • Sebuahperusahaanmanufakturmembuatprodukdaribeberapakomponen. Setiapprodukmempunyaisuatunomorproduk yang tersendiri, namadanwaktuperakitan. Semuakomponenmempunyainomorkomponentersendiri, diskripsi, kode supplier danharga.
Database Yang Sudah Dinormalisasikan • Product (ProductCode, Name, Time) • Parts (ProductCode, ComponentCode, Qty) • Component (ComponentCode, Description, Supplier, Cost) Parts Product Component
Conceptual Modeling of Data Warehouses • Modeling data warehouses: (Dimensional Modeling) • Star schema: A fact table in the middle connected to a set of dimension tables • Snowflake schema: A refinement of star schema where some dimensional hierarchy is normalized into a set of smaller dimension tables, forming a shape similar to snowflake • Fact constellations: Multiple fact tables share dimension tables, viewed as a collection of stars, therefore called galaxy schema or fact constellation
Example of Star Schema item time item_key item_name brand type supplier_type time_key day day_of_the_week month quarter year location branch location_key street city province_or_street country branch_key branch_name branch_type Sales Fact Table time_key item_key branch_key location_key units_sold dollars_sold avg_sales Measures
Example of Snowflake Schema supplier item time item_key item_name brand type supplier_key supplier_key supplier_type time_key day day_of_the_week month quarter year city location branch location_key street city_key city_key city province_or_street country branch_key branch_name branch_type Sales Fact Table time_key item_key branch_key location_key units_sold dollars_sold avg_sales Measures
Example of Fact Constellation item time item_key item_name brand type supplier_type time_key day day_of_the_week month quarter year location location_key street city province_or_street country shipper branch shipper_key shipper_name location_key shipper_type branch_key branch_name branch_type Shipping Fact Table time_key Sales Fact Table item_key time_key shipper_key item_key from_location branch_key to_location location_key dollars_cost units_sold units_shipped dollars_sold avg_sales Measures
Apa sebenarnya multi-dimensionaldatabase? • Suatu pendekatan pada perancangan database yang dapat memberikan database yang mudah dimengerti dan mudah dinavigasikan • Tujuannya adalah untuk mendorong pengertian, eksplorasi dan pembelajaran • Setiap nomor mempunyai satu set atribut yang terasosiasikan • Apa yang direpresentasikan, kapan dibuat, darimana datangnya, produk apa saja yang terkait, promosi apa, dll
Multi-Dimensionality • Biasanya mengenai ruangan informasi dalam bentuk cubes atau hyper cubes atau n-cubes • Setiap atribut terkait dengan setiap nomor merepresentasikan suatu dimensi • Ukuran, waktu, tempat, produk, lokasi dll • Tampilan database yang dihasilkan mudah untuk dinavigasikan dan dipindahkan • Slice and dice • Report template
Tahapan dalam Proses Disain 1. Memilih proses bisnis 2. Memilih inti dari fact table 3. Memilih dimensi 4. Memilih fact yang terukur (umumnya numeric, additive quantities) 5. Melengkapi tabel dimensi (Kimball, 1996)
Tahapan Ekstra Dalam Proses Disain • Menentukan strategi untuk mengubah dimensi secara pelan-pelan • Membuat agregat dan komponen penyimpanan fisik lainnya • Menentukan waktu histori dari database • Menentukan tingkat keperluan data yang mana yang perlu diekstrak dan diload ke dalam data warehouse KimbalL (1996)
Contoh: Usaha Retail • Perusahaan grocery besar dengan perkiraan 500 outlet • Setiap outlet mempunyai sekitar 60000 produk dalam tampilannya • SKU – Stock Keeping Unit • UPC – Universal Product Code
Usaha Retail • Perlu untuk memaksimalkan keuntungan dan tetap menjaga stok agar tetap ada • Keputusan penting untuk masalah harga dan promosi • Tipe promosi adalah: • Discount harga sementara • Reklame surat kabar • Tampilan lemari dan lorong • Kupon
Usaha Retail • Memilih Proses Bisnis • Pergerakan barang harian • Memilih inti dari tabel fact • SKU by store by promotion by day • Memilih dimensi • Waktu, Produk, Toko dan Promosi
Usaha Retail • Memilih fact terukur
Usaha Retail: Dimensi • Lengkapitabeldimensi
Catatan Untuk Masalah Hierarchies • Hirarki yang jelas tidak diperlukan untuk mendukung drilling down • Detailnya sering harus disimpan secara eksplisit • Hirarki di dalam dimensi sangat penting • Memungkinkan untuk melakukan drill up dan drill down • Contoh: day, week, month, quarter, year • Hirarki independen yang berkelipatan
Terms • Fact table • Dimension tables • Measures
Dimension Hierarchies sType store city region è snowflake schema è constellations
Cube Fact table view: Multi-dimensional cube: dimensions = 2
3-D Cube day 2 day 1 Fact table view: Multi-dimensional cube: dimensions = 3
Aggregates • Add up amounts for day 1 • In SQL: SELECT sum(amt) FROM SALE • WHERE date = 1 81
Aggregates • Add up amounts by day • In SQL: SELECT date, sum(amt) FROM SALE • GROUP BY date
Another Example • Add up amounts by day, product • In SQL: SELECT date, sum(amt) FROM SALE • GROUP BY date, prodId rollup drill-down
Aggregates • Operators: sum, count, max, min, median, ave • Using dimension hierarchy • average by region (within store) • maximum by month (within date)
Cube Aggregation rollup drill-down Example: computing sums day 2 . . . day 1 129
Cube Operators day 2 . . . day 1 sale(c1,*,*) 129 sale(c2,p2,*) sale(*,*,*)
Extended Cube * day 2 sale(*,p2,*) day 1
Aggregation Using Hierarchies day 2 day 1 customer region country (customer c1 in Region A; customers c2, c3 in Region B)
Pivoting day 2 day 1 Fact table view: Multi-dimensional cube: