Pemodelan Data
(Data Modeling)
➔Designing the Dimensional Data Store
kita mulai dengan merancang DDS . Para pengguna akan menggunakan data warehouse untuk melakukan analisis dalam enam bidang usaha : penjualan produk , penjualan berlangganan , pelanggan profitabilitas , kinerja pemasok , segmentasi kampanye CRM , dan hasil kampanye CRM . Jadi , kita perlu menganalisa setiap area bisnis satu per satu untuk memodelkan proses bisnis dalam rangka menciptakan model data. Mari kita lakukan area bisnis pertama : penjualan produk . Sebuah data mart order- item dalam industri ritel adalah contoh klasik dari data warehousing .
Sebuah peristiwa(event) penjualan produk terjadi ketika seorang pelanggan membeli produk , daripada berlangganan paket . Peran(roles ( siapa, di mana , dan apa )) dalam acara ini adalah pelanggan, produk, dan toko . Tingkat ((level) atau dalam istilah pemodelan dimensi, langkah-langkah ) adalah kuantitas , harga satuan , nilai , biaya unit langsung , dan biaya satuan tidak langsung . Kami mendapatkan tingkat ini dari kebutuhan bisnis dalam Bab 4 ; dengan kata lain , mereka pengguna apa yang perlu untuk melakukan tugas mereka . Kami menempatkan langkah-langkah dalam tabel fakta dan peran ( ditambah tanggal ) dalam tabel dimensi . Peristiwa bisnis menjadi kenyataan baris tabel
➔Dimension Tables
mari kita bahas tabel dimensi. Sebuah tabel dimensi adalah tabel yang berisi berbagai atribut menjelaskan kunci dimensi dalam tabel fakta. Seperti disebutkan sebelumnya dalam bab ini, fakta peristiwa toko meja bisnis. Atribut menjelaskan kondisi badan pada saat acara bisnis yang terjadi. Sebagai contoh, dalam tabel fakta pada Gambar 5-1, kita memiliki kunci dimensi disebut customer_key. Tabel 5-1 mengatakan bahwa kolom ini berisi kunci (atau ID) pelanggan membeli produk. Pada Gambar 5-1, Anda dapat melihat bahwa tabel dimensi pelanggan adalah "terkait" dengan tabel fakta menggunakan customer_keycolumn tersebut. Customer_keycolumn adalah utama keyin tabel dimensi pelanggan, dan itu adalah kunci asing pada tabel fakta. Hal ini dikenal dalam dunia database sebagai integritas referensial
Integritas referensial(Referential integrity) adalah konsep membangun hubungan orangtua-anak(parent-child) antara dua tabel, dengan tujuan untuk memastikan bahwa setiap baris dalam tabel anak memiliki entri induk yang sesuai dalam tabel induk. Integritas referensial dapat "mengeras" atau "dipaksakan" secara fisik sebagai kendala database fisik (orang data warehouse menyebutnya hardRI). Sebuah kendala database aturan yang mengatur nilai-nilai yang diijinkan pada kolom tertentu. Atau, integritas referensial dapat dikelola oleh ETL dan tidak diberlakukan sebagai kendala fisik data (data warehouse orang menyebutnya RI lunak ini). ETL akan memeriksa bahwa nilai-nilai pada tabel fakta kunci dimensi ada di tabel dimensi.
Atribut disimpan sebagai kolom dalam tabel dimensi. Mereka dikenal Tabel dimensi berisi berbagai atribut menjelaskan kondisi dari entitas yang terlibat dalam acara bisnis yang disimpan dalam tabel fakta.sebagai dimensi attributes.
Kita juga akan membahas konsep perlahan-lahan berubah dimensi (slowly changing dimension (SCD)). SCD adalah teknik pemodelan data untuk menyimpan nilai-nilai sejarah atribut dimensi. Hal ini penting untuk membahasnya dalam konteks dimensi karena kemampuan untuk melestarikan nilai-nilai atribut sejarah.
➔Date Dimension
Hampir setiap tunggal Data mart memiliki dimensi tanggal di dalamnya. Ini mencerminkan sifat dari data mart dimensi dalam baris tabel fakta adalah kegiatan bisnis yang terjadi pada tanggal tertentu. Karena dimensi tanggal digunakan di hampir setiap mart data dalam data warehouse, penting untuk model dimensi tanggal dengan benar. Hal ini penting untuk dimensi tanggal mengandung atribut yang diperlukan oleh semua tabel fakta dalam semua data mart
Kolom atau atribut dalam dimensi tanggal dapat dikategorikan ke dalam empat kelompok
Tanggal format(date format): Kolom format tanggal berisi tanggal dalam berbagai format.
Tanggal kalender atribut(Calendar date attributes): Atribut tanggal kalender mengandung berbagai unsur tanggal, seperti hari, nama bulan, dan tahun.
Fiskal atribut(Fiscal attributes: Kolom atribut fiskal mengandung unsur-unsur yang terkait dengan kalender fiskal, seperti minggu fiskal, periode fiskal, dan tahun fiskal.
Indikator kolom(Indicator columns): Kolom Indikator mengandung nilai-nilai Boolean digunakan untuk menentukan apakah tanggal tertentu memenuhi kondisi tertentu, seperti apakah itu adalah hari libur nasional.
Yang biasanya digunakan dikolom format tanggal dalam dimensi saat ini adalah sebagai berikut (dengan contoh-contoh untuk 17 Februari 2008):
• datesuch as “02/17/2008”
• sql_datesuch as “02/17/2008 00:00:00.000”
• ansi_datesuch as “2008-02-17”
➔Slowly Changing Dimension
SCD yang merupakan teknik yang digunakan untuk menyimpan nilai historis atribut dimensi. Nilai-nilai atribut dimensi berubah seiring berjalannya waktu. Ketika nilai atribut ini berubah, Anda dapat menimpa nilai-nilai lama dengan yang baru, atau Anda dapat mempertahankan nilai lama. Ada dua metode melestarikan nilai atribut tua: Anda dapat menyimpan nilai-nilai lama sebagai baris, atau Anda dapat menyimpannya sebagai kolom
Sekarang Anda memahami bagaimana nilai-nilai sejarah yang disimpan dalam tabel dimensi (yaitu sebagai baris atau kolom), saya akan berbicara tentang tiga jenis SCD:
•SCD tipe 1 menimpa nilai-nilai lama atribut sehingga nilai-nilai lama tidak disimpan.
• SCD tipe 2 menjaga nilai-nilai lama dengan membuat baris baru untuk setiap perubahan, seperti
• SCD tipe 3 menjaga nilai-nilai lama dengan menempatkan mereka dalam kolom lain,
Umumnya, SCD tipe 2 lebih fleksibel untuk menyimpan nilai historis dimensi atribut, karena Anda dapat menyimpan banyak versi lama yang Anda inginkan tanpa mengubah struktur tabel. SCD tipe 3 menggunakan kolom untuk menyimpan nilai-nilai lama, yang menyebabkan tidak fleksibel. Ini sangat ideal untuk situasi di mana Anda tidak memiliki banyak versi lama (lima atau lebih sedikit) dan Anda tahu hanya akan ada sejumlah versi. Tipe 3 ini juga cocok ketika perubahan dalam atribut ini mempengaruhi sejumlah besar baris. Dengan kata lain, banyak baris dimensi mengubah nilai atribut ini pada waktu yang sama (simultan). Untuk penjelasan rinci tentang SCD, silakan lihat Ralph Kimball dan buku Margy Ross ', The Data Warehouse Toolkit (Wiley, 2002). Anda dapat menyimpan nilai-nilai sejarah yang menggunakan cara lain, misalnya dengan menempatkan mereka di meja lain, tapi SCD tipe 1, 2, dan 3 adalah yang paling populer, jadi mari kita langsung saja.
Panduan ini mengklasifikasikan atribut dimensi sebagai lambat atau cepat berubah bukan aturan tegas dan memiliki beberapa pertimbangan. Pertimbangan pertama adalah ukuran dimensi, yaitu, jumlah baris. Semakin besar dimensi, semakin besar kecenderungan untuk mengklasifikasikan atribut sebagai cepat berubah. Pertimbangan kedua adalah hubungan antara atribut dengan atribut lainnya dalam dimensi. The longgar kopling antara atribut dengan atribut lainnya dalam dimensi, semakin banyak kecenderungan untuk mengklasifikasikan atribut sebagai cepat berubah. Pertimbangan ketiga adalah seberapa sering atribut lainnya dalam perubahan dimensi. Semakin sedikit sering atribut lain berubah, semakin kita cenderung untuk mengklasifikasikan atribut sebagai cepat berubah
➔Product, Customer, and Store Dimensions
Sekarang kita telah membahas konsep SCD , mari kita bahas yang lain tiga dimensi : dimensi produk, dimensi pelanggan , dan dimensi toko . Berbeda dengan dimensi tanggal yang baru saja kita bahas , atribut produk bervariasi dari industri ke industri . Oleh karena itu , ketika Anda Data model dalam industri yang berbeda , perlu diingat bahwa atribut produk dapat benar-benar berbeda dari yang dibahas dalam bagian ini . Di sinilah pengalaman industri menjadi berguna .Untuk membuat dimensi produk, kita melihat sistem sumber
➔Subscription Sales Data Mart
Persyaratan lain yang kita miliki dari studi kasus adalah penjualan berlangganan, pelanggan profitabilitas, kinerja pemasok, segmentasi kampanye CRM, dan hasil kampanye CRM. Secara umum, langkah-langkah untuk merancang mart ini adalah sama; mereka hanya membutuhkan pengetahuan bisnis yang berbeda untuk desain mereka. Sebuah data mart (tabel fakta dan dimensi) menyimpan koleksi kegiatan bisnis di daerah bisnis tertentu. Untuk merancang tabel fakta dan dimensi, kita perlu memiliki pengetahuan bisnis di daerah bisnis. Sebagai contoh, untuk menentukan apa yang kolom kita perlu memiliki dalam tabel Hasil Kampanye kenyataannya, kita perlu memiliki tingkat tertentu pengetahuan bisnis dalam CRM
Ada beberapa hal yang saya ingin menyebutkan pada saat ini . Pertama , karena alasan kinerja serta desain kesederhanaan dan konsistensi , lebih baik untuk tetap berpegang pada skema bintang daripada kepingan salju . skema bintang adalah lebih sederhana dan lebih konsisten daripada skema snowflake karena hanya memiliki satu tingkat di semua dimensi . Karena skema bintang sederhana , lebih mudah untuk proses ETL untuk memuat data ke dalamnya . Sebuah skema snowflake adalah ketika Anda menormalkan dimensi menjadi beberapa tabel yang lebih kecil dengan struktur hirarki . Hal ini digunakan bila Anda ingin mendapatkan keuntungan dari kurang redundansi data. Manfaat dari skema snowflake adalah bahwa beberapa aplikasi analisis bekerja lebih baik dengan skema kepingan salju dari skema bintang . Manfaat lain dari skema snowflake adalah bahwa ruang disk kurang diperlukan . Sebuah skema snowflake dapat menurunkan kinerja query , tetapi juga dapat meningkatkan performa query . Ini mengurangi fakta kinerja tabel query karena kita harus bergabung lebih tabel untuk tabel fakta . Hal ini meningkatkan kinerja query ketika kita ingin mendapatkan nilai yang berbeda dari atribut dimensi tertentu . Jika atribut ini dinormalisasi ke dalam tabel subdimensi sendiri , pilih permintaan yang berbeda berjalan lebih cepat .
Kedua, jika dimensi sudah ada, kita menggunakan yang sudah ada bukan menciptakan versi lain. Sebagai contoh, jangan membuat dimensi pelanggan lain. Jika kita membutuhkan lebih banyak atribut, memperpanjang kolom dimensi.
Ketiga, kita harus konsisten dengan definisi data kita. Definisi untuk setiap ukuran dan setiap atribut dimensi harus akurat dan unik. Istilah yang sama digunakan sebagai ukuran atau atribut tidak boleh digunakan setiap tempat lain di gudang data dengan arti yang berbeda.
➔Supplier Performance Data Mart
Pemasok data kinerja mart memiliki empat dimensi: tanggal, minggu, pemasok, dan produk. Dimensi pemasok mendukung SCD tipe 2, ditandai dengan cap efektif dan kadaluwarsa dan is_currentcolumn tersebut
Tujuan dari data ini mart adalah untuk mendukung pengguna untuk menganalisis "kinerja pemasok," Untuk menentukan ukuran pada tabel fakta, kita perlu menentukan periode di mana kami ingin mengevaluasi kinerja. Hal ini dapat dilakukan dengan membahas persyaratan dengan bisnis.
➔CRM Data Marts
Persyaratan bisnis untuk segmentasi promosi CRM adalah (dari Bab 4): untuk memungkinkan pengguna CRM untuk memilih pelanggan berdasarkan izin komunikasi (berlangganan / berhenti berlangganan, e-mail/phone/post, dan sebagainya), atribut geografis (alamat, kota , dan sebagainya), atribut demografis (usia, jenis kelamin, pekerjaan, pendapatan, hobi, dan sebagainya), kepentingan (selera musik, kepentingan topik buku, jenis film favorit, dan sebagainya), sejarah pembelian (nilai order, tanggal pesanan , jumlah item, lokasi toko, dan sebagainya), rincian langganan (rincian paket, tanggal berlangganan, jangka waktu, lokasi toko, dan sebagainya), dan atribut dari produk yang dibeli (misalnya, genre musik, artis, jenis film yang , dan sebagainya) untuk tujuan pengiriman promosi CRM
beberapa terminologi CRM pertama. Langganan Komunikasi adalah ketika seorang pelanggan berlangganan komunikasi, seperti surat kabar mingguan. Komunikasi permissionis ketika seorang pelanggan memungkinkan kita atau mitra pihak ketiga untuk menghubungi mereka (atau berkomunikasi dengan mereka) baik melalui telepon, e-mail, pos, dan sebagainya. Preferensi komunikasi memiliki dua makna: preferensi saluran komunikasi dan preferensi isi komunikasi. Saluran ini adalah tentang bagaimana mereka ingin dihubungi, seperti melalui telepon, pos, e-mail, atau pesan teks. Konten tersebut tentang subjek yang mereka ingin tahu, seperti musik pop, film komedi, atau penulis favorit tertentu. Preferensi isi komunikasi juga dikenal sebagai kepentingan.
➔ Data Hierarchy
Dalam tabel dimensi, ada struktur tertentu yang disebut hirarki. Hirarki ini penting karena menyediakan Anda dengan jalur yang dapat Anda gunakan untuk menggulung dan menelusuri ketika menganalisis data.
Dalam tabel dimensi, kadang-kadang atribut (kolom) adalah bagian dari atribut lain, yang berarti bahwa nilai-nilai atribut dapat dikelompokkan berdasarkan atribut lainnya. Atribut yang dapat digunakan untuk kelompok dikatakan pada tingkat yang lebih tinggi dari atribut yang sedang dikelompokkan. Artinya, jika A adalah himpunan bagian dari B, maka A adalah pada tingkat yang lebih tinggi daripada B. Tingkat ini dalam tabel dimensi disebut hirarki dimensi.
Untuk menerapkan hirarki dalam situasi Anda sendiri, pertama lihat kolom (atribut) dalam tabel dimensi untuk menemukan apakah ada kelompok atau himpunan bagian. Mengatur atribut di tingkat yang tepat, yang berarti bahwa Anda harus menempatkan atribut-tingkat yang lebih tinggi di atas atribut-tingkat yang lebih rendah. Uji data untuk membuktikan bahwa semua anggota atribut tingkat rendah dapat dikelompokkan berdasarkan atribut-tingkat yang lebih tinggi. Identifikasi apakah ada beberapa jalur (cabang) dalam struktur hirarki;
➔Source System Mapping
Setelah kami menyelesaikan desain DDS, langkah berikutnya adalah untuk memetakan setiap kolom dalam DDS ke sistem sumber sehingga kita tahu di mana untuk mendapatkan data dari ketika mengisi kolom tersebut. Ketika melakukan hal ini, kita juga perlu menentukan transformasi atau perhitungan yang diperlukan untuk mendapatkan kolom sumber ke dalam kolom target. Hal ini diperlukan untuk memahami fungsi bahwa logika ETL harus melakukan ketika mengisi setiap kolom pada tabel DDS
Hasil akhirnya adalah bahwa menyimpan data dimensi yang kita dirancang di bagian sebelumnya akan benar-benar dipetakan ke sistem sumber. Oleh karena itu, kita tahu di mana setiap kolom akan bersumber dari, termasuk transformasi
➔Designing the Normalized Data Store
untuk merancang menyimpan data dinormalisasi, yang merupakan database dinormalisasi yang berada di antara panggung dan DDS. Silakan lihat aliran data diagram arsitektur. Sebuah NDS adalah toko data master yang berisi data yang lengkap, termasuk semua data transaksi historis dan semua versi sejarah data master. The NDS berisi menguasai tabel dan tabel transaksi. Sebuah transaksi tableis tabel yang berisi transaksi bisnis atau acara bisnis. Sebuah tabel master adalah tabel yang berisi orang-orang atau benda yang terlibat dalam acara bisnis.
Langkah Pertama, kita daftar semua entitas berdasarkan tabel sumber dan berdasarkan fakta dan atribut dimensi di DDS. Idealnya, diagram NDS termasuk kardinalitas di "crow’s feet" format untuk mencerminkan hubungan antara entitas seperti one-to-many. Format kaki gagak terdiri dari simbol lingkaran (nol), garis (satu), atau garpu (banyak) di dekat meja, seperti yang ditunjukkan pada Gambar 5-13
Untuk mendukung beberapa DDSS konsisten, semua kunci data warehouse perlu didefinisikan dan dipelihara di NDS sehingga semua DDSS memiliki kunci yang konsisten. Dari sudut pandang data integrasi, kita perlu memiliki kunci DW untuk setiap meja di NDS. Kita perlu untuk memetakan data referensi dari beberapa sistem sumber. Untuk membuat pemetaan, kita mengidentifikasi primary key dari tabel dalam sistem sumber dan mencocokkannya dengan kunci DW dalam tabel NDS. Ketika mengisi tabel NDS, kita membangun ETL sesuai dengan pemetaan ini. Ketika merancang NDS, kita harus mengikuti aturan normalisasi. Tujuan dari normalisasi adalah untuk menghapus data yang berlebihan dan membuatnya lebih mudah untuk mempertahankan data. Kita perlu ingat bahwa normalisasi dapat mempengaruhi kinerja. Tidak ada aturan yang pasti bahwa kita perlu merancang NDS ke bentuk normal ketiga
Langkah kedua adalah daftar kolom. Kami mendasarkan ini pada kolom DDS dan pada kolom sistem sumber.
Langkah ketiga adalah menuliskan sumber dan transformasi. Hal ini seharusnya tidak sulit karena kita mendefinisikan mereka ketika kami melakukan pemetaan sistem sumber di DDS