Nama : Mardaleni

Bp: 1010963003

Membangun Data Warehouse

Chapter 16

The gears bergeser agak dramatis dalam bab ini. Dari pada berfokus pada teknik pemodelan
dimensi, kita mengalihkan perhatian kita untuk segala sesuatu yang lain yang terjadi selama
desain data warehouse dan implementasi proyek. Kami akan berjalan melalui kehidupan proyek
data warehouse dari awal melalui pemeliharaan, mengidentifikasi praktik terbaik pada setiap
langkah, serta sebagai kerentanan potensial. Cakupan yang lebih komprehensif dari lifecycle data
warehouse tersedia dalam The Data Warehouse Lifecycle Toolkit, oleh Ralph Kimball, Laura
Reeves, Margy Ross, dan Warren Thornthwaite (Wiley, 1998). Bab ini adalah kilat kursus
diambil dari teks lengkap, yang beratnya di di kekar 750 + halaman.
Beberapa orang mungkin merasa bahwa isi bab ini hanya berlaku untuk data warehouse manajer
proyek. Kita tentu tidak merasa bahwa hal ini terjadi. menerapkan data warehouse membutuhkan
kegiatan terintegrasi. Kami percaya bahwa setiap orang di tim proyek, termasuk analis bisnis,
arsitek, desainer basis data, data stager, dan pengembang aplikasi analitik, membutuhkan
pemahaman tingkat tinggi tentang siklus hidup lengkap dari sebuah data werehouse. seperti
Sisa buku ini, kami telah menulis bab ini sehingga dapat diakses dengan luas oleh pendengar
Bab 16 mencakup konsep berikut:

Iktisar dimensi bisnis lifecycle

Perencanaan proyek data werehouse dan komunikasi dan manajemen yang sedang
berlangsung

Taktik untuk mengumpulkan kebutuhan bisnis, termasuk prioritas Proses untuk

mengembangkan arsitektur teknis dan kemudian memilih produk
Lokakarya desain Dimensi
Pertimbangan desain fisik, termasuk agregasi dan pengindeksan
Rekomendasi pementasan data
Desain aplikasi analitik dan pengembangan
Rekomendasi untuk penyebaran, pemeliharaan, dan pertumbuhan masa depan
untuk menghindari Kesalahan umum ketika membangun dan mengelola data warehouse

Bisnis Dimensi Lifecycle Road Map

Ketika mengemudi ke tempat kita belum pernah ke sana sebelumnya, sebagian besar dari kita
bergantung pada peta jalan . Demikian pula, peta jalan ini sangat berguna jika kita akan memulai
di Perjalanan asing dari data warehousing. Para penulis dari The Data Warehouse Lifecycle
Toolkit menarik pada dekade pengalaman untuk mengembangkan dimensi bisnis pendekatan
siklus hidup. Kami memilih nama itu karena itu diperkuat beberapa prinsip-prinsip kunci untuk
keberhasilan data werehouse. Pertama dan terpenting, data warehouse proyek harus fokus pada
kebutuhan bisnis. Kedua, data yang disajikan untuk bisnis pengguna harus dimensi. Mudahmudahan, ini muncul karena tidak ada Kejutan untuk setiap pembaca pada saat ini! Akhirnya,
sedangkan data werehouse adalah proses yang berkelanjutan, setiap pelaksanaan proyek harus
memiliki siklus yang terbatas dengan awal dan akhir yang spesifik.
Kami menggunakan diagram pada Gambar 16.1 untuk merangkum kegiatan utama dari bisnis
siklus hidup dimensi. Diagram menggambarkan urutan tugas, ketergantungan, dan concurrency.
Ini berfungsi sebagai peta jalan untuk membantu tim melakukan hal yang benar pada saat yang
tepat. Diagram tidak mencerminkan timeline mutlak. Sementara kotak sama-sama lebar, ada
perbedaan besar dalam waktu dan usaha yang diperlukan untuk setiap kegiatan utama.

Road Map Point Utama Tujuan

Sebelum kita menyelam ke spesifik, mari kita luangkan waktu untuk menyesuaikan diri kita
sendiri ke
peta jalan. Siklus Data warehouse dimulai dengan perencanaan proyek, sebagai salah satu
harapkan. Selama modul ini kita menilai kesiapan organisasi untuk data werehouse inisiatif,
menetapkan ruang lingkup awal dan pembenaran, mendapatkan sumber daya, dan meluncurkan
proyek. Manajemen proyek yang sedang berlangsung melayani sebagai landasan untuk menjaga
jalur lifecycle.
Tugas besar kedua pada Gambar 16.1 berfokus pada definisi kebutuhan bisnis.
Perhatikan dua arah panah antara perencanaan proyek dan bisnis persyaratan definisi karena ada
banyak interaksi antara kedua kegiatan. Menyelaraskan data warehouse dengan kebutuhan bisnis
benar-benar penting. Best-of-breed teknologi tidak akan menyelamatkan data warehouse yang
gagal untuk fokus pada bisnis. Desainer Data warehouse harus memahami kebutuhan bisnis dan
menerjemahkannya ke dalam pertimbangan desain. Bisnis pengguna dan kebutuhan mereka
berdampak pada hampir setiap desain dan Keputusan pelaksanaan dibuat selama proyek
werehouse. dalam Gambar ini 16.1 peta jalan, hal ini tercermin dari tiga jalur paralel yang
mengikuti. Jalur atas Gambar 16.1 penawaran dengan teknologi. arsitektur teknis desain
menetapkan

kerangka

keseluruhan

untuk

mendukung

integrasi

beberapa

teknologi.

Menggunakan kemampuan yang diidentifikasi dalam desain arsitektur sebagai daftar belanja,

kita kemudian mengevaluasi dan memilih produk tertentu. Perhatikan bahwa Temukan produk
tidak kotak pertama di peta jalan. Salah satu yang paling sering kesalahan yang dilakukan oleh
tim pemula adalah untuk memilih produk tanpa pemahaman yang jelas dari apa yang mereka
capai. Hal ini mirip dengan meraih palu apakah Anda perlu pon paku atau mengencangkan
sekrup.
Jalur tengah yang berasal dari kebutuhan bisnis definisi berfokus pada data. Kita mulai dengan
menerjemahkan kebutuhan ke model dimensi, seperti kami sudah berlatih. Model dimensi ini
kemudian berubah menjadi struktur fisik. Kami fokus pada strategi penyetelan kinerja, seperti
agregasi, pengindeksan, dan partisi, selama kegiatan desain fisik. Terakhir tapi tidak sedikit,
pementasan data ekstrak-transformasi-load (ETL) proses yang dirancang dan dikembangkan.
Seperti yang telah disebutkan sebelumnya, kotak berukuran sama tidak mewakili upaya
berukuran sama; ini tampak jelas bila kita berpikir tentang beban kerja diferensial antara desain
fisik dan kegiatan pementasan data. Set terakhir tugas melahirkan dengan definisi kebutuhan
bisnis adalah desain dan pengembangan aplikasi analitik. Data warehouse proyek tidak dilakukan
ketika kita mengirimkan data. Aplikasi Analytic, dalam bentuk parameter-driven template dan
analisis, akan memenuhi persentase besar kebutuhan analisis pengguna bisnis.
Kami mempertemukan teknologi, data, dan jalur aplikasi analitik, bersama dengan dosis yang
baik dari pendidikan dan dukungan, untuk penyebaran baik diatur. Dari sana, pemeliharaan
diperlukan untuk memastikan bahwa data gudang dan komunitas pengguna yang tetap sehat dan
poised untuk memanfaatkan investasi. Akhirnya, kami menangani data masa depan pertumbuhan
gudang dengan memulai proyek berikutnya, masing-masing kembali ke awal seluruh siklus
hidup .
Sekarang kita memiliki pemahaman tingkat tinggi tentang struktur keseluruhan peta jalan itu,
kami akan menyelidiki setiap kotak Gambar 16.1 untuk lebih jelasnya.
Perencanaan Dan Manajemen Proyek
Tidak mengherankan, kami meluncurkan data werehouse dengan serangkaian kegiatan
perencanaan proyek.kadang-kadang kita melihat sebuah tugas sebagai sebuah marshmallow
karena mereka lembut, lengket, dan dapat mengacaukan pekerjaan proyek data warehouse yang
serius.

Menilai kesiapan
Sebelum pindah full-steam kedepan dengan pengeluaran data warehouse yang signifikan, adalah
bijaksana untuk mengambil waktu sejenak untuk menilai kesiapan organisasi untuk melanjutkan.
Berdasarkan pengalaman kumulatif kami dari ratusan gudang data, kami telah mengidentifikasi
lima faktor yang membedakan proyek yang sebagian besar adalah lancar dibandingkan dengan
mereka yang mensyaratkan perjuangan terus-menerus. faktor-faktor ini adalah indikator utama
keberhasilan data warehouse. Anda tidak perlu nilai tinggi pada setiap faktor untuk bergerak
maju, tetapi setiap kekurangan mewakili risiko atau kerentanan. Kami akan menjelaskan
karakteristik dalam urutan peringkat penting. Faktor yang paling penting untuk sukses data
warehouse adalah memiliki kuat sponsor bisnis. Sponsor bisnis harus memiliki visi untuk potensi
dampak data warehouse pada organisasi. Mereka harus bergairah dan secara pribadi yakin nilai
proyek sementara realistis pada saat yang sama. Secara optimal, sponsor bisnis memiliki catatan
keberhasilan dengan internal lainnya
inisiatif. Dia harus menjadi pemimpin politik yang cerdik yang bisa meyakinkan atau temantemannya untuk mendukung gudang. Kadang-kadang ada permintaan yang kuat untuk sebuah
gudang data yang berasal dari satu sponsor. Bahkan jika orang ini dan nya peluang mencakup
gudang karakteristik yang kita cari, kita masih dapat menemukan masalah dalam hal ini skenario
karena sponsor tunggal cenderung untuk pindah, baik secara internal maupun eksternal. Ini
adalah penyebab paling umum untuk data warehouse stagnasi. Beberapa tim yang dihadapkan
dengan terlalu banyak permintaan yang datang dari seluruh penjuru organisasi. Dengan asumsi
bahwa Anda (atau manajemen Anda) tidak berusaha untuk mengatasi semua permintaan dalam
satu gerakan, ini adalah cara yang bagus untuk memulai. Akhirnya, bisnis sponsor mungkin
hilang dalam aksi, tapi ini tidak menghentikan organisasi TI bergerak maju, hampir menjamin
kesalahan start data warehouse. Ini adalah skenario paling berisiko; proyek harus memperlambat
sampai bisnis yang tepat sponsor telah diidentifikasi (atau mungkin direkrut) dan telah
menyuarakan komitmen untuk proyek.
Faktor kesiapan kedua adalah memiliki yang kuat, motivasi bisnis yang menarik untuk
membangun data warehouse. Faktor ini sering sejalan dengan sponsorship. Sebuah proyek data
warehouse tidak bisa hanya memberikan yang baik untuk dimiliki kemampuan; perlu untuk
memecahkan masalah bisnis penting untuk menggalang sumber daya yang diperlukan untuk

peluncuran yang sukses dan umur sehat. Compelling motivasi biasanya menciptakan rasa
urgensi, apakah motivasi adalah dari eksternal (misalnya, faktor kompetitif) dan internal
(misalnya, ketidakmampuan untuk menganalisis kinerja cross-organisasi berikut akuisisi)
sumber. Faktor ketiga ketika menilai kesiapan adalah kelayakan. Ada beberapa aspek kelayakan,
seperti kelayakan teknis atau sumber daya, namun data kelayakan adalah yang paling penting.
Apakah kita mengumpulkan data nyata dalam sumber operasional yang nyata sistem untuk
mendukung kebutuhan bisnis? Data kelayakan merupakan perhatian utama karena tidak ada
perbaikan jangka pendek jika kita belum mengumpulkan cukup sumber data bersih pada
granularity yang tepat.
Faktor berikutnya proyek tidak menunjukan puncak tapi masih mempengaruhi kemungkinan
Anda untuk sukses. Faktor keempat berfokus pada hubungan antara bisnis dan organisasi TI.
Dalam perusahaan Anda, apakah organisasi TI memahami dan menghormati bisnis? Sebaliknya,
apakah bisnis memahami dan menghormati organisasi TI? Ketidakmampuan untuk jujur
menjawab ya untuk pertanyaan-pertanyaan ini tidak berarti bahwa Anda tidak dapat melanjutkan.
Sebaliknya, ini menunjukkan bahwa Anda perlu waspada menjaga bisnis dan perwakilan TI
berbaris ke drum yang sama. Dalam banyak hal inisiatif data warehouse dapat menjadi peluang
untuk memperbaiki pagar di antara organisasi-organisasi ini, dengan asumsi bahwa Anda berdua
memberikan.
Aspek terakhir dari kesiapan adalah budaya analitik saat ini dalam perusahaan Anda. Apakah
analis bisnis membuat keputusan berdasarkan fakta dan angka, atau keputusan mereka
berdasarkan intuisi, bukti anekdotal, dan reaksi usus? The pengusaha sudah dibenamkan dalam
jumlah kemungkinan akan lebih mudah menerima data warehouse. Namun, Anda bisa sukses
dengan baik skenario selama sewaktu Anda mempersiapkan diri untuk peningkatan beban
pergeseran pola pikir budaya (dengan bantuan sponsor bisnis), serta kebutuhan untuk analisis
tambahan pengembangan aplikasi, pendidikan, dan dukungan sumber daya. Jika proyek Anda
tidak siap untuk melanjutkan, biasanya karena sponsor bisnis kekurangan, kami menyarankan
dua pendekatan untuk menopang kesiapan Anda. Pertama adalah melakukan analisis kebutuhan
bisnis tingkat tinggi dan prioritas.
Kita akan berbicara lebih banyak tentang proses ini di bagian utama berikutnya, sehingga
menantikan. Alternatif lain adalah untuk menciptakan sebuah bukti dari konsep. Bukti dari

konsep yang cepat dan demonstrasi kotor kemampuan potensi data warehouse. mereka adalah
alat penjualan daripada bukti teknis desain. Tim menggunakan teknik ini karena pengguna bisnis
seharusnya tidak bisa menjelaskan apa yang mereka inginkan tanpa melihat sesuatu untuk
bereaksi terhadap. Sementara bukti dari konsep dapat membuat pemahaman bersama, kita tidak
menunjukkan bahwa itu menjadi alat pertama ditarik darikotak peralatan Anda. Bukti konsep
sering membutuhkan usaha yang lebih cepat dan kotor menyiratkan. Biasanya, mereka
diselenggarakan bersama-sama dengan lakban namun memiliki kecenderungan untuk berubah
menjadi sistem produksi tanpa ulang diperlukan. Hal ini menantang mengelola harapan
pengguna tepat. Mereka yang suka bermain dengan alat condong ke teknik ini, tetapi Anda harus
menyadari bahwa mungkin ada lebih metode yang efektif dan efisien untuk mencapai tujuan
yang sama.
Penjajakan
Setelah Anda merasa nyaman dengan kesiapan organisasi, saatnya untuk menempatkanbatas di
sekitar proyek awal. Penjajakan memerlukan masukan bersama kedua organisasi TI dan
manajemen bisnis. Ruang lingkup data warehouse Anda proyek harus baik berarti dari segi nilai
untuk organisasi dan dikelola. Ketika Anda pertama kali memulai, Anda harus fokus pada data
dari proses bisnis tunggal. Simpan lebih menantang, lintas-proses proyek dalam tahap
selanjutnya. Kadang-kadang lingkup didorong oleh penyelesaian sasaran tanggal, seperti akhir
tahun fiskal. Anda dapat mengatur ruang lingkup untuk tanggal jatuh tempo efektif, namun hal
ini dapat menimbulkan risiko tambahan. Bahkan dengan waktu yang ditetapkan bingkai, Anda
perlu mempertahankan fokus Anda pada scoping proyek yang bersifat menarik dan dapat
dilakukan. Kadang-kadang tim proyek merasa bahwa jadwal pengiriman cor beton sebelum
perencanaan proyek bahkan dimulai. prioritas yang proses, yang kami akan menjelaskan selama
definisi kebutuhan bisnis, dapat digunakan untuk meyakinkan TI dan manajemen bisnis yang
penyesuaian yang diperlukan.
Akhirnya, ingat untuk menghindari hukum juga ketika scoping-terlalu kuat dari komitmen terlalu
singkat waktu yang melibatkan terlalu banyak sistem sumber dan juga banyak pengguna terlalu
banyak lokasi dengan persyaratan analitik terlalu beragam.
pembenaran

Sebuah membunuh akronim mengelilingi proses pembenaran, tapi jangan biarkan mereka
mengintimidasi Anda. Pembenaran membutuhkan estimasi manfaat dan biaya terkait dengan data
warehouse; mudah-mudahan, manfaat diantisipasi terlalu lebih besar daripada biaya. IT biasanya
bertanggung jawab untuk menurunkan biaya. Anda perlu menentukan biaya perkiraan untuk
perangkat keras dan perangkat lunak yang diperlukan. Data warehouse cenderung berkembang
cepat, jadi pastikan perkiraan memungkinkan beberapa ruang untuk pertumbuhan jangka pendek.
Tidak seperti pengembangan sistem operasional, di mana kebutuhan sumber daya ekor setelah
produksi, dukungan gudang berkelanjutan kebutuhan tidak akan menurun lumayan dari waktu ke
waktu. Kami mengandalkan bisnis untuk menentukan manfaat keuangan dari gudang data.
Gudang biasanya dibenarkan berdasarkan peningkatan pendapatan atau keuntungan Kesempatan
bukan hanya fokus pada pengurangan biaya. menyampaikan versi tunggal kebenaran atau akses
fleksibel untuk informasi tidak cukup keuangan pembenaran. Anda harus mengupas lapisanlapisan untuk menentukan kuantitatif dampak dari meningkatnya pengambilan keputusan
dimungkinkan oleh gigitan suara tersebut. Jika Anda sedang berjuang dengan gudang
pembenaran, ini mungkin gejala yang Anda berfokus pada sponsor bisnis yang salah atau
masalah.
Staffing
Proyek Data warehouse membutuhkan integrasi tim lintas fungsional dengan sumber daya dari
kedua bisnis dan masyarakat TI. Hal ini umum untuk orang yang sama untuk mengisi lebih dari
satu peran, terutama karena biaya masuk untukData pergudangan telah jatuh. Penugasan sumber
daya ditunjuk untuk peran tergantung pada besarnya proyek dan ruang lingkup, serta individu
yang ketersediaan, kapasitas, dan pengalaman. Dari sisi bisnis rumah, Anda harus perwakilan
untuk mengisi berikut peran:
Sponsor bisnis. Sponsor bisnis klien utama gudang, seperti advokat terkuat. Sponsorship
kadang-kadang mengambil bentuk komite pengarah eksekutif, terutama untuk inisiatif lintasperusahaan.
Sopir Bisnis. Jika Anda bekerja di sebuah organisasi besar, sponsor mungkin terlalu jauh atau
tidak dapat diakses oleh tim proyek. Dalam hal ini sponsor kadang-kadang delegasi atau dia

tanggung jawab kurang strategis gudang untuk seorang manajer menengah dalam organisasi.
Driver ini harus memiliki yang sama
karakteristik sebagai sponsor.
Memimpin bisnis. Proyek bisnis memimpin adalah orang yang dihormati yang sangat terlibat
dalam proyek, kemungkinan berkomunikasi dengan manajer proyek setiap hari. Orang yang
sama yang berfungsi sebagai driver bisnis atau ahli subjek terkadang mengisi peran ini.
Bisnis pengguna. Secara optimal, pengguna bisnis adalah penggemar antusias dari data
warehouse. Anda harus melibatkan mereka awal dan sering, yang diawali dengan proyek lingkup
dan kebutuhan bisnis. Dari sana, Anda harus menemukan cara-cara kreatif untuk menjaga
kepentingan dan keterlibatan mereka di seluruh siklus hidup. Ingat, keterlibatan pengguna sangat
penting untuk penerimaan data warehouse. Tanpa pengguna bisnis, data warehouse adalah
latihan teknis dalam kesia-siaan.
Beberapa posisi lain yang dikelola baik dari bisnis atau organisasi TI. Tengah ini dapat sumber
daya teknis yang memahami bisnis atau sumber daya bisnis yang mengerti teknologi. Peran
Straddler termasuk berikut:
Analis sistem bisnis. Orang ini bertanggung jawab untuk menentukan bisnis kebutuhan dan
menerjemahkannya ke dalam arsitektur, data, dan analisis persyaratan aplikasi.
Bisnis ahli subjek. Orang ini sering saat pergi-untuk sumber daya untuk analisis ad hoc. Dia
mengerti apa artinya data, bagaimana digunakan, dan di mana inkonsistensi data yang mengintai.
analitik mereka dan wawasan data sangat berguna, terutama selama pemodelan dan proses
aplikasi analitik.
Pengembang aplikasi analitik. Pengembang aplikasi Analytic bertanggung jawab untuk
merancang dan mengembangkan set starter template analitik, seperti serta menyediakan
dukungan aplikasi yang sedang berjalan.
Data warehouse pendidik. Pendidik harus yakin dengan data mereka, aplikasi, dan alat akses
pengetahuan karena komunitas bisnis tidak membedakan antara kiriman gudang tersebut. Peran
berikut biasanya yang dikelola dari organisasi TI (atau perusahaan konsultan eksternal). Jika

Anda bekerja dengan konsultan karena sumber daya atau keahlian kendala, Anda harus
mempertahankan kepemilikan internal
proyek. Bersikeras pembinaan dan keterampilan yang luas / transfer pengetahuan sehingga Anda
dapat berfungsi lebih mandiri pada proyek berikutnya. Akhirnya, Anda harus jelas memahami
apakah Anda membeli pengalaman berarti lebih dari staf augmentasi (mungkin dengan konsultan
yang hanya tahu bagaimana mantra OLAP).
Manajer Proyek. Manajer proyek adalah posisi kritis. Dia harus merasa nyaman dengan dan
dihormati oleh eksekutif bisnis, serta teknis analis. Komunikasi dan manajemen proyek Manajer
proyek keterampilan harus tinggi.
Arsitek teknis. Arsitek bertanggung jawab untuk teknis secara keseluruhan dan arsitektur
keamanan. Dia mengembangkan rencana yang mengikat bersama-sama diperlukan fungsi teknis
dan membantu mengevaluasi produk berdasarkan arsitektur secara keseluruhan.
Spesialis dukungan teknis. Spesialis teknis cenderung hampir ensiklopedis tentang spektrum
yang relatif sempit teknologi.
Modeler Data. Data modeler kemungkinan berasal dari pemodelan data transaksional latar
belakang dengan penekanan pada normalisasi. Dia harus merangkul konsep pemodelan dimensi
dan bersikap empati terhadap persyaratan bisnis daripada berfokus ketat pada menghemat ruang
atau mengurangi beban kerja pementasan.
Database administrator. Seperti modeler data, database administrator harus bersedia
menyisihkan beberapa aksioma administrasi database tradisional, seperti memiliki hanya satu
indeks di atas meja relasional.
Koordinator Metadata. Orang ini memastikan bahwa semua metadata dikumpulkan, dikelola,
dan disebarluaskan. Sebagai peran pengawas, koordinator adalah bertanggung jawab untuk
mengingatkan orang lain dari tugas metadata-sentris mereka.
Steward Data. Data steward bertanggung jawab untuk perjanjian perusahaan pada gudang ini
sesuai dimensi dan fakta. Jelas, ini adalah politik peran yang menantang.

Desainer pementasan data. Perancang pementasan bertanggung jawab untuk merancang proses
ETL Data pementasan. Dia biasanya terlibat dalam pembuatan dibandingkan membeli keputusan
tentang software pementasan.
Data pengembang pementasan. Berdasarkan arahan dari desainer pementasan, yang
pengembang pementasan memberikan dan mengotomatisasi proses pementasan menggunakan
baik alat pementasan atau rutinitas yang diprogram secara manual.
Dukungan Data warehouse. Terakhir, namun tidak sedikit, data warehouse membutuhkan
backroom berkelanjutan dan sumber daya front room dukungan. Paling sering peran ini
ditugaskan untuk individu yang terlibat dalam proyek di kapasitas sebelumnya.
MENGEMBANGKAN DAN MEMPERTAHANKAN RENCANA PROYEK
Mengembangkan rencana proyek data warehouse melibatkan identifikasi semua tugas yang
diperlukan untuk melaksanakan data warehouse. Sumber daya yang tersedia di pasar untuk
membantu Anda menyusun daftar tugas proyek. Sebagai contoh, CD-ROM yang datang dengan
The Data Warehouse Lifecycle Toolkit mencakup hampir Daftar tugas 200-item.
Setiap manajer proyek yang baik tahu bahwa anggota tim inti, seperti data pementasan desainer,
harus mengembangkan perkiraan upaya untuk tugas-tugas mereka. proyek Manajer tidak bisa
mendikte jumlah waktu diperbolehkan dan mengharapkan kesesuaian.Rencana proyek harus
mengidentifikasi pengguna penerimaan pos pemeriksaan setelah setiap tonggak utama dan
penyampaian untuk memastikan bahwa proyek tersebut masih di jalur dan bahwa bisnis ini
masih erat terlibat.
Proyek data warehouse menuntut komunikasi yang luas. Selama proyek fase perencanaan, kami
sarankan bahwa manajer proyek membangun komunikasi matriks, seperti Tabel 16.1
menggambarkan, untuk membantu memastikan bahwa strategi komunikasi dijalankan.

Proyek Data warehouse rentan terhadap scope creep sebagian besar disebabkan kami keinginan
yang kuat untuk memenuhi kebutuhan pengguna. Kita harus waspada paling tentang akumulasi
perubahan kecil yang bola salju. Sementara tidak ada satu permintaan terlalu sulit, diambil secara
total, mereka dapat mewakili perubahan yang signifikan ruang lingkup proyek. Kami memiliki
beberapa pilihan ketika dihadapkan dengan perubahan. Pertama, kita dapat meningkatkan
cakupan dengan menambahkan waktu, sumber daya, atau uang untuk mengakomodasi
perubahan. Jika tidak, total upaya dapat tetap tidak berubah jika pengguna melepaskan sesuatu
yang telah di lingkup untuk mengakomodasi berubah. Akhirnya, kita hanya bisa mengatakan
tidak tanpa benar-benar mengatakan tidak dengan menangani berubah karena permintaan
tambahan. Yang paling penting untuk diingat tentang ruang lingkup perubahan adalah bahwa
mereka tidak harus dilakukan dalam vakum IT. Jawabannya tergantung pada situasi. Sekarang
adalah waktu untuk meningkatkan kemitraan Anda dengan bisnis untuk sampai pada jawaban
dengan mana setiap orang bisa hidup.
Kunci untuk perencanaan dan manajemen proyek data warehouse meliputi:
1 Memiliki sponsor bisnis yang kuat
2 Menyeimbangkan bernilai tinggi dan kemampuan pelaksanaan untuk menentukan ruang
lingkup

3 Bekerja dengan tim terbaik untuk mengembangkan rencana proyek rinci

4. Menjadi manajer proyek yang sangat baik dengan memotivasi, mengelola, dan
berkomunikasi atas, bawah, dan seluruh organisasi
Persyaratan Bisnis Definition
Merangkul pengguna bisnis untuk memahami kebutuhan mereka dan Garner mereka buy-in
adalah sangat penting untuk sukses data pergudangan. bagian ini berfokus pada back-to-dasar
teknik untuk mencapai hal itu.
persyaratan Perencanaan awal
Sebelum duduk dengan komunitas bisnis untuk mengumpulkan persyaratan, kami menyarankan
agar Anda mengarahkan diri untuk sesi produktif dengan mempertimbangkan berikut:
Pilih Forum
Kami mengumpulkan persyaratan dengan bertemu dengan perwakilan pengguna bisnis
sementara sesi Data jalinan dengan guru sistem sumber dan materi pelajaran ahli. Pendekatan
dual-cabang ini memberi kita wawasan tentang kebutuhan bisnis dalam hubungannya dengan
realitas data. Namun, kita tidak bisa meminta manajer bisnis tentang rincian atau dimensi kritis
mereka data. Kita perlu berbicara dengan mereka tentang apa yang mereka lakukan, mengapa
mereka melakukannya, bagaimana mereka membuat keputusan, dan bagaimana mereka berharap
untuk membuat keputusan di masa depan. seperti organisasi terapi, kita mencoba untuk
mendeteksi masalah dan peluang.
Ada dua teknik utama untuk mengumpulkan persyaratan-wawancara atau sesi difasilitasi.
Keduanya memiliki kelebihan dan kekurangan. wawancara mendorong banyak partisipasi
individu. Mereka juga mudah untuk jadwal. Sesi yang difasilitasi dapat mengurangi waktu yang
telah berlalu untuk mengumpulkan persyaratan, meskipun mereka memerlukan komitmen waktu
lebih dari masing-masing peserta. Berdasarkan pengalaman kami, survei bukan alat yang wajar
untuk mengumpulkan persyaratan karena mereka datar dan dua dimensi. The dipilih sendiri
responden hanya menjawab pertanyaan-pertanyaan yang kami bertanya di muka. Tidak ada
pilihan untuk menyelidiki lebih dalam, seperti ketika kita muka dengan muka. Selain itu, jangan

lupa bahwa hasil sekunder pengumpulan persyaratan adalah untuk menciptakan sebuah ikatan
antara pengguna dan inisiatif pergudangan. Ini hanya tidak akan terjadi dengan survei. Kami
umumnya menggunakan pendekatan hybrid dengan wawancara untuk mengumpulkan rincian
berdarah dan kemudian fasilitasi untuk membawa kelompok untuk konsensus. Sementara kami
akan menjelaskan ini Pendekatan hybrid secara lebih rinci, banyak diskusi berlaku untuk
fasilitasi murni juga. Forum Pilihan tergantung pada kemampuan tim, organisasi ini budaya, dan
apa yang telah Anda dikenakan pengguna Anda untuk. Ini adalah kasus di mana satu ukuran pasti
tidak cocok untuk semua.
Mengidentifikasi dan Siapkan Tim Persyaratan
Terlepas dari pendekatan, Anda perlu mengidentifikasi dan menyiapkan tim proyek anggota yang
terlibat. Jika Anda melakukan wawancara, Anda perlu mengidentifikasi pewawancara memimpin
yang tanggung jawab utama adalah untuk meminta besar terbuka pertanyaan. Sementara itu, juru
tulis wawancara mengambil catatan berlebihan. Sementara tape perekam dapat memberikan
cakupan lebih lengkap setiap wawancara, kita tidak menggunakan satu karena perubahan
dinamika rapat. Preferensi kami adalah untuk memiliki kedua orang di dalam ruangan dengan
otak lain dan pasang mata dan telinga agak mengandalkan pada mesin berputar. Kami sering
mengundang satu atau dua proyek tambahan Anggota (tergantung pada jumlah orang yang
diwawancarai) sebagai pengamat sehingga mereka dapat mendengar input pengguna langsung.
Sebelum Anda duduk dengan pengguna, Anda perlu memastikan bahwa Anda mendekatisesi
dengan pola pikir yang benar. Anda tidak harus menganggap bahwa Anda sudah tahu semuanya.
Jika dilakukan dengan benar, Anda pasti akan belajar selama persyaratan ini wawancara. Di sisi
lain, Anda harus melakukan beberapa pekerjaan rumah oleh meneliti sumber-sumber yang
tersedia, seperti laporan tahunan, situs Web, dan intern struktur organisasi.
Karena kunci untuk mendapatkan jawaban yang benar adalah mengajukan pertanyaan yang tepat,
kami sarankan bahwa kuesioner dirumuskan sebelum pertemuan friendly. kuesioner tidak harus
dilihat sebagai sebuah naskah. Ini adalah alat untuk mengatur pikiran Anda dan berfungsi sebagai
perangkat fallback dalam kasus pikiran Anda berjalan kosong selama wawancara sesi.
Pilih, Jadwal, dan Siapkan Bisnis perwakilan

Jika ini adalah perampokan pertama Anda ke data pergudangan (atau upaya pertama Anda untuk
menyelamatkan stovepipes data), Anda harus berbicara dengan pengusaha yang mewakili
horisontal luasnya di seluruh organisasi. Cakupan ini sangat penting untuk merumuskan data
warehouse bus matriks cetak biru. Anda perlu memiliki pemahaman awal dari data umum dan
kosa kata di seluruh fungsi bisnis inti untuk membangun lingkungan extensible.
Dalam komunitas pengguna target, Anda harus mencakup organisasi secara vertikal. Tim proyek
Data warehouse secara alami tertarik ke arah negara adidaya analis dalam bisnis. Sementara
wawasan berharga, Anda tidak bisa mengabaikan eksekutif senior dan manajemen menengah.
Jika tidak, Anda rentan untuk menjadi terlalu terfokus pada taktis sini-dan-sekarang tapi
melupakan arah strategis masa depan organisasi.
Penjadwalan perwakilan bisnis dapat menjadi persyaratan tugas yang paling berat. Jadilah sangat
baik untuk administrator (atau administrator bos Anda adalah Anda mencoba untuk
menjadwalkan sesi dengan staf eksekutif). Kami lebih memilih untuk memenuhi dengan para
eksekutif mereka sendiri, sedangkan kita bisa bertemu dengan homogen kelompok 2-3 orang
bagi mereka yang lebih rendah pada bagan organisasi. Kami memungkinkan 1 jam untuk
pertemuan individu dan 11/2 jam untuk kelompok-kelompok kecil. The scheduler perlu untuk
memungkinkan 1/2 jam antara pertemuan untuk wawancara dan lainnya kebutuhan. Wawancara
ini sangat melelahkan karena Anda harus benar-benar fokus selama sesi. Akibatnya, kami hanya
menjadwalkan tiga untuk empat sesi dalam sehari karena otak kita berubah lembek setelah itu.
Ketika datang untuk mempersiapkan diwawancarai, pendekatan yang optimal adalah melakukan
proyek peluncuran pertemuan dengan pengguna. Sponsor bisnis memainkan peran penting,
menekankan atau komitmen dan pentingnya semua orang partisipasi. Pertemuan peluncuran
menyebarkan pesan yang konsisten tentang proyek. Hal ini juga menghasilkan rasa kepemilikan
bisnis proyek. Jika pertemuan peluncuran adalah mimpi buruk logistik, sponsor harus
mendistribusikan memo peluncuran mencakup topik-topik yang sama. Demikian juga, tim
wawancara harusmempersiapkan diwawancarai dengan menyorot topik yang akan dibahas dalam
sesi mendatang. Kami tidak menyertakan salinan kuesioner, yang tidak ditujukan untuk
diseminasi publik. Kami melakukan meminta diwawancarai untuk membawa salinan laporan
utama mereka dan analisis.
Mengumpulkan Kebutuhan Bisnis

Sudah waktunya untuk duduk tatap muka untuk mengumpulkan kebutuhan bisnis. The Proses
biasanya mengalir dari pengenalan melalui pertanyaan terstruktur untuk wrap-up akhir, seperti
yang akan kita bahas.
peluncuran
Tanggung jawab untuk memperkenalkan wawancara harus ditetapkan sebelum berkumpul di
ruang konferensi. Kickoff Orang yang ditunjuk harus skrip poin utama yang akan disampaikan
dalam beberapa menit pertama ketika Anda mengatur nada pertemuan wawancara. Anda harus
fokus pada proyek dan wawancara tujuan tapi tidak mengoceh tentang hardware, software, dan
teknis lainnya jargon. Pendahuluan harus menyampaikan garing, pesan bisnis-sentris.
Arus wawancara
Tujuan dari wawancara adalah untuk mendapatkan pengguna bisnis untuk berbicara tentang apa
yang mereka lakukan dan mengapa mereka melakukannya. Sederhana, tidak mengancam tempat
untuk memulai adalah dengan bertanya tentang tanggung jawab pekerjaan mereka dan fit
organisasi. Ini adalah bola lob yang diwawancarai dapat merespon dengan mudah. Dari sana, kita
biasanya bertanya tentang kinerja utama mereka metrik. Menentukan bagaimana mereka
melacak kemajuan dan keberhasilan menerjemahkan langsung ke dalam model dimensi. Mereka
menceritakan tentang bisnis utama mereka proses dan fakta tanpa kami meminta pertanyaanpertanyaan secara langsung. Jika kita bertemu dengan orang yang memiliki lebih banyak tanganon pengalaman data, kami tidak langsung menyelidiki untuk lebih memahami dimensi bisnis,
bersama dengan hirarki roll-up. Sekali lagi, kita pergi ke dunia mereka daripada memintamereka
untuk bertemu di kandang kami. Pertanyaan seperti "Bagaimana Anda membedakan antara
produk (atau agen, penyedia, atau fasilitas)? "atau" Bagaimana Anda alami mengkategorikan
produk? "membantu mengidentifikasi atribut dimensi kunci dan hirarki. Jika orang yang
diwawancara lebih analitik, kita bertanya tentang jenis analisis dia atau dia saat ini melakukan.
Memahami sifat analisis ini dan apakah mereka ad hoc atau standar memberikan masukan ke
dalam akses data persyaratan alat, serta proses desain template aplikasi. Mudah-mudahan,
diwawancarai

telah

membawa

salinan

spreadsheet

utama

mereka

dan

laporan.

Daripadamenyembunyikannya mereka dalam sebuah folder, akan sangat membantu untuk

memahami bagaimana diwawancarai menggunakan analisis saat ini, serta peluang untuk

perbaikan. Bertentangan dengan saran dari beberapa pakar industri, Anda tidak bisa merancang
lingkungan analitik extensible hanya dengan mendapatkan pengguna untuk setuju di atas lima
laporan atau pertanyaan. Pertanyaan pengguna 'terikat untuk berubah. Akibatnya, kita harus
menahan godaan untuk mempersempit fokus desain kami untuk seharusnya lima.
Jika kita bertemu dengan para eksekutif bisnis, kita biasanya tidak menyelidiki Rincian baru saja
dijelaskan. Sebaliknya, kita bertanya kepada mereka tentang visi mereka untuk leveraging yang
lebih baik informasi dalam organisasi. Mungkin tim proyek membayangkan lingkungan benarbenar ad hoc, sedangkan manajemen bisnis lebih tertarik dalam penyampaian analisis standar.
Kita perlu memastikan data gudang penyampaian sesuai dengan permintaan bisnis dan harapan.
Kami meminta setiap diwawancarai tentang dampak peningkatan akses terhadap informasi.
Kami mungkin sudah menerima dana awal untuk proyek tersebut, tapi tidak pernah salahnya
untuk menangkap lebih banyak potensi, manfaat terukur.
Aturan dasar untuk wawancara yang efektif meliputi:

Ingat peran wawancara Anda; mendengarkan dan menyerap seperti spons.

Upayakan untuk aliran percakapan; tidak menyelam terlalu cepat (atau mengeluarkan

salinan potensi elemen data).

Verifikasi komunikasi dan menangkap terminologi justru karena sebagian besar

organisasi menggunakan terminologi konsisten.

Menetapkan dasar sebaya dengan orang yang diwawancarai; menggunakan nya kosakata.

Wrap-Up
Saat wawancara datang ke sebuah kesimpulan, kami meminta setiap diwawancarai tentang nya
atau kriteria kesuksesannya untuk proyek tersebut. Tentu saja, setiap kriteria harus dapat diukur.
Mudah digunakan dan cepat berarti sesuatu yang berbeda untuk setiap orang, sehingga Anda
harus mendapatkan orang yang diwawancarai untuk mengartikulasikan spesifik, seperti harapan
mereka mengenai jumlah pelatihan yang dibutuhkan untuk menjalankan laporan yang telah
ditetapkan.
Pada titik ini dalam wawancara kita membuat disclaimer yang luas. The diwawancarai harus
memahami bahwa hanya karena kita bahas kemampuan dalam pertemuan tersebuttidak
menjamin bahwa itu akan dimasukkan dalam fase pertama proyek. Kami terima diwawancarai

untuk wawasan brilian mereka dan membiarkan mereka tahu apa yang terjadi berikutnya dan apa
keterlibatan mereka akan. Kami juga mengambil keuntungan dari kesempatan ini untuk
mengelola harapan.
Melakukan Data-Centric Wawancara
Sementara kami fokus pada pemahaman kebutuhan bisnis, itu adalah bermanfaat untuk
menyelingi sesi dengan guru sistem sumber data atau subjek ahli materi untuk mengevaluasi
kelayakan mendukung kebutuhan bisnis. Wawancara data fokus ini sangat berbeda dari yang
baru saja dijelaskan. Tujuannya adalah untuk menilai bahwa data inti yang diperlukan ada
sebelum momentum membangun belakang persyaratan. Audit Amore data lengkap akan terjadi
selama proses pemodelan dimensi. Kami sedang berusaha untuk belajar cukup pada saat ini
untuk mengelola ekspektasi organisasi tepat.
Dokumentasi Postcollection dan Tindak Lanjut
Segera setelah wawancara, tim wawancara harus membahasnya. Anda ingin memastikan bahwa
Anda berada pada halaman yang sama tentang apa yang telah dipelajari, serta sebagai sedang
dipersiapkan untuk kejutan atau inkonsistensi. Hal ini juga membantu untuk meninjau catatan
Anda dengan cepat untuk mengisi setiap celah sementara wawancara masih segar dalam memori
Anda. Demikian juga, Anda harus memeriksa laporan berkumpul untuk mendapatkan lebih lanjut
wawasan Pengunjung ke dimensi yang harus didukung dalam data gudang.
Pada titik ini saatnya untuk mendokumentasikan apa yang Anda dengar. Sementara dokumentasi
Kegiatan paling favorit semua orang, sangat penting untuk kedua validasi pengguna dan proyek
bahan referensi tim. Ada dua tingkat dokumentasi yang biasanya hasil dari proses persyaratan.
Yang pertama adalah untuk menulis setiap individu wawancara. Kegiatan ini bisa sangat
memakan waktu karena write-up seharusnya tidak hanya aliran-of-kesadaran transkrip tetapi
harus membuat akal untuk seseorang yang tidak dalam wawancara. Tingkat kedua dari
dokumentasi adalah dokumen temuan konsolidasi. Kami mengatur dokumen dengan terlebih
dahulu mengidentifikasi proses bisnis utama. Seperti yang telah disebutkan sebelumnya, kita
mengatasi fase awal sebuah gudang data pada proses-by-proses dasar. Akibatnya, adalah logis
untuk mengatur persyaratan bisnis ke dalam ember yang sama yang akan, pada gilirannya,

menjadi upaya implementasi. Catatan dari semua wawancara ditinjau untuk menangkap temuan
yang terkait dengan masing-masing bisnis inti proses.
Ketika menuliskan dokumen temuan, kita biasanya dimulai dengan eksekutif Singkatnya, diikuti
dengan gambaran proyek yang membahas proses yang digunakan dan peserta yang terlibat.
Sebagian besar laporan berpusat pada temuan persyaratan kami. Untuk setiap proses bisnis
utama yang dibahas, kita menjelaskan mengapa bisnis pengguna ingin menganalisis hasil proses,
apa kemampuan yang mereka inginkan, mereka keterbatasan saat ini, dan potensi manfaat atau
dampak. Kami menyertakan daftar sampel pertanyaan yang bisa dijawab setelah metrik proses
tersedia dalam data warehouse. Komentar tentang kelayakan menangani data dihasilkan oleh
setiap proses juga didokumentasikan. Kita kadang-kadang membawa proses bersama-sama
dalam sebuah matriks untuk menyampaikan peluang seluruh organisasi. Dalam hal ini kita tidak
mengacu pada data warehouse matriks bus. Baris dari matriks peluang masih mengidentifikasi
proses bisnis. Namun, dalam matriks peluang, daripada mengidentifikasi dimensi umum sebagai
kolom, kita malah mengidentifikasi organisasi kelompok atau fungsi. Anehnya, matriks akan
cukup padat karena banyak kelompok membutuhkan akses ke inti yang sama kinerja proses
bisnis metrik.
Prioritas dan Konsensus
Dokumen Temuan persyaratan berfungsi sebagai dasar untuk presentasi kembali perwakilan
manajemen senior, serta bagi orang lain yang berpartisipasi. Tak pelak kami telah menemukan
lebih dari yang dapat ditangani dalam sebuah iterasi tunggal, sehingga kita perlu
memprioritaskan upaya kami. Seperti yang kita bahas dengan ruang lingkup proyek, Anda tidak
harus membuat keputusan ini dalam ruang hampa. Anda perlu memanfaatkan (atau angkat)
kemitraan dengan komunitas bisnis untuk tiba di prioritas dengan yang semua orang bisa hidup.
Persyaratan wrap-up presentasi diposisikan sebagai ulasan temuan dan Pertemuan prioritas.
Peserta termasuk relatif perwakilan bisnis tingkat tinggi, serta manajer data warehouse dan
lainnya yang terlibat IT manajemen. Sesi ini dimulai dengan gambaran bisnis masing-masing
diidentifikasi proses. Anda ingin semua orang di ruang untuk memiliki pemahaman umum
berbagai peluang, serta apa yang dimaksud ketika kita mengatakan "pemesanan penjualan
analisis, "misalnya. Setelah temuan telah ditinjau, sekarang saatnya untuk memprioritaskan.

Kuadran empat sel teknik, diilustrasikan pada Gambar 16.2, adalah alat yang efektif untuk
mencapai konsensus pada rencana pengembangan data warehouse yang berfokus pada awal yang
tepat peluang. Sumbu vertikal Kuadran mengacu pada dampak potensial atau nilai untuk bisnis.
Sumbu horizontal menyampaikan kelayakan.

Tema proses bisnis ditempatkan dalam kuadran berdasarkan perwakilan 'Perjanjian komposit
pada dampak dan kelayakan. Proyek-proyek yang menjamin perhatian segera terletak di sudut
kanan atas karena mereka highimpact proyek, serta sangat layak. Proyek di sel kiri bawah harus
dihindari seperti wabah misi-mereka mustahil melakukan sedikit untuk bisnis. Demikian juga,
proyek di sel kanan bawah tidak membenarkan jangka pendek perhatian, meskipun kadangkadang tim proyek tertarik di sini karena proyek-proyek ini adalah bisa dilakukan tetapi tidak
sangat penting. Dengan kata lain, tidak ada yang akan melihat jika proyek tidak berjalan dengan
baik. Akhirnya, proyek di sel kiri atas mewakili bermakna peluang. Proyek-proyek ini memiliki
potensi besar payback bisnis tetapi Saat ini tidak layak. Sementara tim proyek data warehouse
difokuskan pada proyek di sel kanan atas berbayang, tim TI lainnya harus membahas saat ini
keterbatasan kelayakan mereka di sel kiri atas.
Jalur Siklus Hidup Teknologi

Definisi kebutuhan bisnis yang segera diikuti oleh tiga jalur bersamaan berfokus pada teknologi,
data, dan aplikasi analitik, masing-masing. Dalam beberapa bagian berikutnya kita akan nol
dalam pada jalur teknologi, yang meliputi desain arsitektur teknis dan pemilihan produk yang
membawa arsitektur dengan realitas.
Teknik Arsitektur Desain
Sama seperti cetak biru untuk rumah baru, arsitektur teknis cetak biru untuk jasa teknik gudang
dan elemen. arsitektur Rencana berfungsi sebagai kerangka kerja untuk mendukung integrasi
teknologi. Seperti cetak biru perumahan, arsitektur teknis terdiri dari rangkaian model yang
menyelidiki lebih rinci tentang masing-masing komponen utama. Dalam kedua situasi, arsitektur
memungkinkan kita untuk menangkap masalah di atas kertas (seperti memiliki mesin cuci piring
terlalu jauh dari wastafel) dan meminimalkan midproject kejutan. Ini mendukung koordinasi
upaya paralel saat melaju pembangunan melalui penggunaan kembali komponen modular.
arsitektur mengidentifikasi komponen segera diperlukan dibandingkan dengan mereka yang akan
dimasukkan di kemudian hari (seperti dek dan disaring teras). Sebagian besar penting, arsitektur
berfungsi sebagai alat komunikasi. konstruksi rumah cetak biru memungkinkan arsitek,
kontraktor umum, subkontraktor, dan pemilik rumah untuk berkomunikasi dari dokumen umum.
Tukang ledeng tahu bahwa listrik memiliki kekuatan di tempat untuk pembuangan sampah.
Demikian juga, arsitektur teknis data warehouse mendukung komunikasi mengenai set konsisten
persyaratan teknis dalam tim, ke atas untuk manajemen, dan luar untuk vendor.
Dalam Bab 1 kita bahas beberapa komponen utama dari arsitektur teknis, termasuk layanan data
pementasan, layanan akses data, dan metadata. dalam bagian berikutnya kita mengalihkan
perhatian kita pada proses menciptakan teknis
desain arsitektur.
Delapan-Langkah untuk Membuat Arsitektur Teknis
Tim Data warehouse pendekatan proses desain arsitektur teknis dari ujung-ujung spektrum.
Beberapa tim hanya tidak memahami manfaat dari arsitektur dan merasa bahwa topik dan tugastugas yang terlalu samar-samar.

Mereka begitu terfokus pada pengiriman data warehouse bahwa arsitektur terasa seperti
gangguan dan hambatan untuk kemajuan, sehingga mereka memilih untuk memotong arsitektur
desain. Sebaliknya, mereka mengumpulkan komponen teknis yang diperlukan untuk iterasi
pertama dengan bailing benang dan permen karet, tetapi integrasi dan interface mendapatkan
pajak seperti yang kita menambahkan lebih banyak data, lebih banyak pengguna, atau fungsi
lainnya. Akhirnya, tim ini sering berakhir membangun kembali karena nonarchitectured struktur
tidak bisa menahan tekanan. Pada ekstrem yang lain, beberapa tim ingin berinvestasi dua tahun
merancang arsitektur sementara melupakan bahwa Tujuan utama dari data warehouse adalah
untuk memecahkan masalah bisnis, bukan mengatasi setiap masuk akal (dan tidak begitu masuk
akal) tantangan teknis.
Baik akhir spektrum arsitektur sehat; yang paling tepat Tanggapan terletak di suatu tempat di
tengah. Kami telah mengidentifikasi proses delapan langkah untuk membantu Anda menavigasi
perairan desain arsitektur ini. Ingat, setiap data yang gudang memiliki arsitektur teknis.
Pertanyaannya adalah apakah Anda adalah direncanakan dan eksplisit atau implisit hanya.
Membentuk Satuan Tugas Arsitektur Berdasarkan pengalaman kami, hal ini sangat berguna
untuk memiliki gugus tugas kecil dua sampai tiga orang fokus pada desain arsitektur. Biasanya,
itu adalah arsitek teknis, bekerja sama dengan desainer pementasan data dan aplikasi analitik
pengembang, untuk memastikan kedua backroom dan representasi ruang depan di gugus tugas.
Kelompok ini perlu menetapkan piagamnya dan kiriman garis waktu. Hal ini juga perlu untuk
mendidik anggota tim (dan mungkin orang lain dalam organisasi TI) tentang pentingnya
arsitektur. Kumpulkan Persyaratan-Arsitektur terkait Seperti yang Anda ingat dari Gambar 16.1,
mendefinisikan arsitektur teknis tidak kotak pertama dalam diagram siklus hidup. Arsitektur
dibuat untuk mendukung highvalue kebutuhan bisnis; itu tidak dimaksudkan untuk menjadi
alasan untuk membeli terbaru, produk terbesar. Akibatnya, masukan kunci ke dalam proses
desain harus berasal dari temuan definisi kebutuhan bisnis. Namun, kita mendengarkan dengan
kebutuhan bisnis dengan filter yang sedikit berbeda untuk mendorong arsitektur desain. Fokus
utama kami adalah untuk mengungkap implikasi arsitektur terkait dengan kebutuhan bisnis yang
kritis. Kami juga mendengarkan dengan seksama untuk waktu apapun, ketersediaan, dan kinerja
kebutuhan. Selain memanfaatkan proses definisi kebutuhan bisnis, kami juga melakukan
wawancara tambahan dalam organisasi TI. ini adalah murni sesi yang berfokus pada teknologi
untuk memahami standar saat ini, direncanakan arah teknis, dan batas-batas bisa diganggu gugat.

Selain itu, kami dapat mengungkap pelajaran dari proyek penyampaian informasi sebelumnya,
serta sebagai kesediaan organisasi untuk mengakomodasi perubahan operasional nama gudang,
seperti mengidentifikasi transaksi diperbarui dalam sistem sumber. Persyaratan Dokumen
Arsitektur Setelah kami memanfaatkan persyaratan proses definisi bisnis dan dilakukan
tambahan wawancara IT, kita perlu mendokumentasikan temuan kami. di menunjukkan kita
memilih untuk menggunakan format tabular sederhana. Kami hanya daftar setiap bisnis
persyaratan yang berdampak pada arsitektur, dan daftar cucian implikasi arsitektur. Misalnya,
jika ada kebutuhan untuk memberikan penjualan global data kinerja pada dasar malam setelah
akuisisi baru-baru ini beberapa perusahaan, implikasi teknis mungkin termasuk 24/7 ketersediaan
di seluruh dunia, mirroring untuk beban data, metadata yang kuat untuk mendukung akses
global, memadai bandwidth jaringan, dan pementasan yang cukup tenaga kuda untuk menangani
integrasi kompleks data operasional.
Mengembangkan Tingkat Tinggi Model Arsitektur
Setelah persyaratan arsitektur telah didokumentasikan, kita mulai merumuskan model untuk
mendukung kebutuhan diidentifikasi. Pada titik ini arsitektur satgas sering disekap dirinya dalam
ruang konferensi selama beberapa hari berat berpikir. Kelompok Tim persyaratan arsitektur
menjadi komponen utama, seperti pementasan data, akses data, metadata, dan infrastruktur. dari
ada draft tim dan memurnikan model arsitektur tingkat tinggi. ini gambar mirip dengan halaman
depan elevasi pada cetak biru perumahan. Ini menggambarkan apa arsitektur gudang akan
terlihat seperti dari jalan, tapi itu berbahaya sederhana karena detail signifikan yang tertanam di
halaman yang mengikuti.
Desain dan Tentukan Subsistem
Sekarang kita mengerti bagaimana potongan-potongan besar akan hidup berdampingan, sekarang
saatnya untuk melakukan desain rinci dari subsistem. Untuk masing-masing komponen, seperti
data pementasan jasa, gugus tugas akan mendokumentasikan daftar cucian kemampuan yang
diperlukan. Semakin spesifik, semakin baik, karena apa yang penting bagi data warehouse Anda
belum tentu penting untuk saya. Upaya ini sering membutuhkan awal penelitian untuk lebih
memahami pasar. Untungnya, tidak ada kekurangan dari informasi dan sumber daya yang
tersedia di Internet, serta dari jaringan dengan rekan-rekan. Hasil spesifikasi subsistem dalam

tambahan rinci model grafis. Selain mendokumentasikan kemampuan subsistem utama, kami
juga harus mempertimbangkan persyaratan keamanan kami, serta infrastruktur fisik dan
konfigurasi kebutuhan. Seringkali, kita dapat memanfaatkan tingkat perusahaan sumber daya
untuk membantu dengan strategi keamanan. Dalam beberapa kasus infrastruktur pilihan, seperti
perangkat keras server dan perangkat lunak database, yang telah ditentukan. Namun, jika Anda
sedang membangun sebuah gudang data yang besar, lebih dari 1 TB dalam ukuran, Anda harus
meninjau kembali keputusan platform infrastruktur ini untuk memastikan bahwa mereka dapat
skala yang sesuai kebutuhan. Ukuran, skalabilitas, kinerja, dan fleksibilitas juga kunci faktor
yang perlu dipertimbangkan saat menentukan peran kubus OLAP secara keseluruhan Anda
arsitektur teknis.
Tentukan Arsitektur Tahapan pelaksanaan
Seperti rumah impian pemilik rumah, Anda mungkin tidak dapat melaksanakan semua aspek
arsitektur teknis sekaligus. Beberapa kemampuan wajib dinegosiasikan, sedangkan yang lain
bagus-to-have yang dapat ditangguhkan sampai nanti. Sekali lagi, kita merujuk kembali ke
kebutuhan bisnis untuk menetapkan prioritas arsitektur. Kita harus menyediakan unsur-unsur
yang cukup arsitektur untuk mendukung end-to-end persyaratan iterasi awal proyek. Ini akan
menjadi tidak efektif untuk fokus hanya pada data pementasan layanan sementara mengabaikan
kemampuan yang diperlukan untuk metadata dan akses layanan.
Dokumen Teknik Arsitektur
Kita perlu untuk mendokumentasikan arsitektur teknis, termasuk rencana implementasi fase,
bagi mereka yang tidak diasingkan di ruang konferensi. Arsitektur teknis dokumen perencanaan
harus mencakup detil yang memadai sehingga yang profesional terampil dapat melanjutkan
pembangunan kerangka kerja, seperti tukang kayu bingkai rumah berdasarkan cetak biru itu.
Review dan Finalisasi Arsitektur teknis
Akhirnya kami datang lingkaran penuh dengan proses desain arsitektur. dengan Draft rencana di
tangan, gugus tugas arsitektur kembali ke mendidik organisasi dan mengelola ekspektasi.
Rencana arsitektur harus dikomunikasikan, di berbagai tingkat detail, untuk tim proyek, rekan IT,

bisnis sponsor, dan lead bisnis. Setelah review, dokumentasi harus diperbarui dan dimanfaatkan
dengan segera dalam proses pemilihan produk.
Pemilihan Produk dan Instalasi
Dalam banyak hal rencana arsitektur mirip dengan daftar belanja. Kami kemudian pilih produk
yang sesuai dengan kerangka rencana untuk memberikan fungsi yang diperlukan. Kami akan
menjelaskan tugas-tugas yang terkait dengan pemilihan produk dengan agak cepat kecepatan
karena banyak konsep-konsep evaluasi ini berlaku untuk setiap teknologi seleksi. Tugas meliputi:
Memahami proses pembelian perusahaan. Langkah pertama sebelum memilih produk baru
adalah untuk memahami hardware dan software purchaseapproval intern proses, apakah kita
suka atau tidak. Mungkin pengeluaran perlu harus disetujui oleh komite alokasi modal (yang
hanya bertemu terakhir minggu dan tidak akan mulai lagi selama 2 bulan).
Mengembangkan matriks evaluasi produk. Menggunakan rencana arsitektur sebagai awal titik,
kami mengembangkan evaluasi matriks berbasis spreadsheet yang mengidentifikasi kriteria
evaluasi, bersama dengan faktor bobot untuk menunjukkan pentingnya. Semakin spesifik
kriteria, semakin baik. Jika kriteria terlalu samar-samar atau generik, setiap vendor akan
mengatakan itu dapat memenuhi kebutuhan kita. umum Kriteria mungkin termasuk fungsi,
arsitektur teknis, desain perangkat lunak karakteristik, dampak infrastruktur, dan kelangsungan
hidup vendornya.
Melakukan riset pasar. Kita harus dihubungi pembeli saat memilih produk, yang berarti riset
pasar yang lebih luas untuk lebih memahami para pemain dan penawaran mereka. Potensi
sumber penelitian meliputi Internet, publikasi industri, kolega, konferensi, vendor, dan analis
(meskipun menyadari bahwa pendapat analis mungkin tidak seobjektif kami mengarah untuk
percaya). Permintaan informasi atau request for proposal (RFP) adalah alat produk-evaluasi
klasik. Sementara beberapa organisasi tidak punya pilihan tentang penggunaan, kita menghindari
teknik ini, jika mungkin. membangun instrumen dan mengevaluasi tanggapan yang sangat
memakan waktu untuk tim. Demikian juga, menanggapi permintaan tersebut sangat memakan
waktu untuk vendor. Selain itu, vendor termotivasi untuk menanggapi pertanyaan dalam cahaya
yang paling positif, sehingga evaluasi respon sering lebih dari kontes kecantikan. Pada akhirnya,
nilai pengeluaran mungkin tidak menjamin upaya.

Persempit pilihan untuk daftar pendek dan melakukan evaluasi rinci. meskipun kebanyakan
produk yang tersedia di pasar, biasanya hanya sejumlah kecil vendor dapat memenuhi kedua
fungsi dan persyaratan teknis. Dengan membandingkan nilai awal dari matriks evaluasi, kita
harus fokus pada daftar sempit vendor tentang siapa kita serius dan mendiskualifikasi sisanya.
Setelah kita sedang berhadapan dengan sejumlah vendor, kita bisa memulai evaluasi rinci.
Perwakilan bisnis harus terlibat dalam proses ini jika kita mengevaluasi alat akses data. Sebagai
evaluator, kita harus mendorong proses daripada membiarkan vendor untuk melakukan
mengemudi (yang pasti akan mencakup gambar drive-by dari kantor pusat mereka bangunan).
Kami berbagi informasi yang relevan dari rencana arsitektur sehingga bahwa sesi fokus pada
kebutuhan kita bukan pada lonceng dan peluit produk. Pastikan untuk berbicara dengan referensi
penjual, baik yang tersedia secara resmi dan mereka menimbulkan dari jaringan resmi Anda. Jika
memungkinkan, referensi harus mewakili instalasi berukuran hampir sama.
Melakukan prototipe, jika perlu. Setelah melakukan evaluasi rinci, kadang-kadang pemenang
gelembung ke atas, sering didasarkan pada tim pengalaman sebelumnya atau hubungan. Dalam
kasus lain, pemimpin muncul karena ada komitmen perusahaan. Dalam kedua kasus, ketika
calon tunggal muncul sebagai pemenang, kita dapat melewati langkah prototipe (dan terkait
investasi waktu dan uang). Jika ada vendor adalah jelas pemenang, kami melakukan prototipe
dengan tidak lebih dari dua produk. Sekali lagi, mengambil alih proses dengan mengembangkan
bisnis terbatas namun realistis studi kasus. Mintalah vendor untuk menunjukkan solusi mereka
menggunakan kecil sampel set data yang diberikan melalui format file datar. Menonton lebih dari
bahu mereka karena mereka sedang membangun solusi sehingga Anda memahami apa yang
diperlukan. Seperti yang kita menyarankan sebelumnya dengan bukti konsep, pastikan untuk
mengelola organisasi harapan tepat.
Pilih produk, instal diadili, dan bernegosiasi. Ini adalah waktu untuk memilih produk.
Daripada segera menandatangani di garis putus-putus, melestarikan negosiasi Anda kekuasaan
dengan membuat pribadi, bukan publik, komitmen untuk satu vendor. Dengan kata lain,
membuat pilihan Anda, tetapi jangan biarkan vendor tahu bahwa Anda benar-benar dijual.
Sebaliknya, memulai masa percobaan di mana Anda memiliki kesempatan untuk menempatkan
produk ke penggunaan nyata di lingkungan Anda. dibutuhkan energi yang signifikan untuk
menginstal produk, dilatih, dan mulai menggunakannya, sehingga Anda harus berjalan

menyusuri jalan ini hanya dengan vendor dari siapa Anda sepenuhnya berniat untuk membeli;
sidang tidak boleh dikejar dengan yang lain ban-menendang latihan. Sebagai percobaan menarik
untuk menutup, Anda memiliki kesempatan untuk bernegosiasi pembelian yang bermanfaat bagi
semua pihak yang terlibat.
Siklus Hidup data
Jalur Dalam diagram siklus hidup yang ditemukan pada Gambar 16.1, jalur tengah mengikuti
definisi kebutuhan bisnis berfokus pada data. Kami mengalihkan perhatian kita dalam arah
sepanjang beberapa bagian berikutnya.
Modeling dimensi
Mengingat fokus pertama 15 bab dari buku ini, kita tidak akan menghabiskan banyak waktu
membahas teknik pemodelan dimensi sini. Ini hanyalah penampung untuk semua yang telah kita
bahas sebelumnya. Kami akan, bagaimanapun, luangkan waktu untuk meninjau proses
pemodelan keseluruhan dimensi. Kami menekankan empat langkah proses sebelumnya, tetapi di
sini kita akan membahas langkah-langkah dalam proyek yang lebih besar konteks. Segera setelah
definisi kebutuhan bisnis, kita harus merancang (atau kembali) data warehouse bus matriks,
seperti yang diperkenalkan dalam Bab 3 Kami sudah disusun baris matriks ketika
mendokumentasikan dan menyajikan pengguna persyaratan dalam konteks proses bisnis.
Canvassing data inti sumber dengan berbicara dengan para veteran IT dapat lebih
menyempurnakan baris. Demikian juga, kita menghasilkan daftar mengesankan dimensi
potensial dan kemudian menandai persimpangan.
Langkah prioritas akhir dari kegiatan kebutuhan bisnis diidentifikasi proses bisnis yang spesifik
yang akan ditangani terlebih dahulu. Ini, tentu saja, sesuai ke deretan matriks. Ini juga membahas
pertanyaan pertama fourstep kami pendekatan pemodelan dimensi: mengidentifikasi proses
bisnis. Pada titik ini saatnya untuk melakukan analisis yang lebih mendalam tentang data yang
dihasilkan oleh proses ini. Sementara kami melakukan audit tingkat tinggi selama bisnis definisi
persyaratan, kita perlu menggali ke dalam seluk-beluk untuk mengevaluasi granularity,
konsistensi sejarah, nilai-nilai yang valid, dan ketersediaan atribut. seringkali bisnis ahli subjek
atau analis daya dari komunitas bisnis dapat menjelaskan dengan cepat pada inkonsistensi data

atau kekhasan berdasarkan tantangan yang mereka temui ketika mencoba untuk menganalisis
data.
Setelah data-analisis kami pekerjaan rumah selesai, kami melakukan workshop desain untuk
membuat skema dimensi. Dalam pengalaman kami, itu lebih efektif dan efisien minimal
memiliki tim kecil (terdiri dari sistem bisnis analis, ahli materi pelajaran bisnis, analis daya
bisnis, dan data modeler) bekerja melalui desain daripada mengandalkan pembuat model
sendirian duduk di atau menara gading nya untuk merancang secara independen. Lokakarya
Kelompok difasilitasi Pendekatan tampaknya tiba di desain yang tepat lebih cepat. selama studi
kasus sebelumnya, langkah 2 sampai 4 (yaitu, biji-bijian, dimensi, dan fakta) yang ditangani
dalam urutan tertib. Dalam kehidupan nyata, jangan heran jika Tim desain mengunjungi kembali
deklarasi granularity setelah direndam dalam dimensi atau fakta. Meskipun kemajuan yang
dibuat dalam setiap lokakarya, masalah juga diidentifikasi pasti. Tanggung jawab untuk
menyelesaikan masalah desain perlu ditugaskan. Seseorang juga harus bertanggung jawab
terhadap penebangan dan mendokumentasikan set lengkap masalah dan resolusi mereka. Jelas,
tim harus memanfaatkan temuan kebutuhan bisnis untuk memastikan bahwa model dapat
mendukung kebutuhan kunci dan pertanyaan. Setelah tim pemodelan cukup yakin tentang
produk kerjanya, kita berkomunikasi dan memvalidasi desain dengan khalayak yang lebih luas,
pertama dalamIT dan tim data warehouse dan kemudian dengan orang lain dalam komunitas
bisnis. Untuk memulai, matriks adalah alat komunikasi utama dengan khalayak sehingga setiap
orang mendapatkan apresiasi yang lebih besar, visi terpadu dan rencana. dari ada, kita fokus pada
skema tertentu. Kita bisa berharap pertemuan sentris IT-berpotensi untuk mengidentifikasi tetapi
juga mudah-mudahan untuk menyelesaikan masalah data. Sesi bisnis-pengguna awalnya akan
melibatkan kecilkelompok pengguna diidentifikasi untuk memvalidasi desain. Kelompok ini
harus fokus pada jenis analisis dan pertanyaan itu berharap untuk meminta data. Saat kita siap
menghadirkan desain dimensi untuk kelompok yang lebih besar dari pengguna bisnis, sering
membantu untuk menyederhanakan skema untuk menyembunyikan bergabung kunci dan
banyak-ke-satu keriput yang telah dikenal untuk membanjiri pengguna. ilustrasi Modern bantuan
sendok-makan desain untuk orang-orang yang belum nyaman dengan Output pemodelan alat ini.
Dokumentasi pada model divalidasi harus mengidentifikasi tabel dan kolom nama, definisi, dan
baik aturan perhitungan fakta atau perlahan-lahan berubah aturan dimensi untuk atribut dimensi.

Biasanya ditangkap di pemodelan alat, informasi ini adalah beberapa masukan pertama (atau
link) ke katalog metadata. Sebagai alat dan kemitraan matang, informasi akan mengalir lebih
mudah antara alat pemodelan, pementasan, akses, dan metadata. Dokumentasi skema selanjutnya
dilengkapi dengan menambahkan sistem sumber tertentu, bidang, dan aturan transformasi untuk
memperoleh sumber-to-sasaran pemetaan bersama dengan tim pementasan. Hal ini membantu
untuk mengadopsi konvensi penamaan standar untuk elemen data awal proses.
Physical desain
Model dimensi yang dikembangkan dalam kebutuhan bagian sebelumnya akan diterjemahkan
menjadi desain fisik. Dalam pemodelan dimensi, logis dan fisik desain memiliki kemiripan yang
sangat dekat. Kami tentu tidak ingin database administrator untuk mengubah skema dimensi
kami indah menjadi dinormalisasi struktur selama desain fisik. Model fisik akan berbeda dari
model logis dalam hal rincian yang ditetapkan untuk database fisik, termasuk nama kolom fisik
(jangan takut untuk menggunakan nama panjang), data jenis, deklarasi kunci (jika sesuai), dan
diperbolehkannya nulls. di titik desain fisik juga berpendapat dengan demikian kegiatan kacangdan-baut sebagai Tuning kinerja, partisi, dan tata letak file. Berlawanan dengan kepercayaan
umum, menambahkan lebih banyak hardware bukanlah satu-satunya senjata kami arsenal untuk
tuning kinerja.
Membuat indeks dan tabel agregat jauh lebih banyak alternatif hemat biaya. Kami akan meninjau
secara singkat rekomendasi di kedua daerah, memahami bahwa pertimbangan desain fisik cepat
turun ke Platform spesifik, yang berubah dengan cepat. Perlu diketahui juga bahwa agregasi dan
strategi pengindeksan terikat untuk berkembang seperti yang kita lebih memahami penggunaan
aktual. Namun, jangan menggunakan perubahan tak terelakkan sebagai alasan untuk menundanunda pada topik ini. Kita harus mengantarkannya tepat diindeks dan agregat data dengan awal
peluncuran untuk memastikan bahwa gudang memberikan kinerja query yang memadai.
Strategi Agregasi
Setiap data warehouse harus berisi precalculated dan prestored agregasi tabel. Mengingat aturan
ketat kami tentang menghindari tabel fakta campuran granularity, setiap tabel fakta agregasi yang
berbeda harus menempati fakta fisik sendiri tabel. Ketika kita mengumpulkan fakta, kita baik
menghilangkan dimensi atau asosiasi fakta-fakta dengan dimensi yang digulung. Bandara

digulung, dimensi agregat tabel harus menyusut versi dimensi yang terkait dengan granular tabel
fakta dasar. Dengan cara ini, tabel dimensi gabungan sesuai dengan tabel dimensi dasar. Hal ini
tidak praktis untuk berpikir tentang membangun semua kombinasi agregasi potensial.
Jika kita memiliki tabel fakta yang sangat sederhana dengan hanya empat dimensi dan masingmasing dimensi memiliki tiga atribut yang adalah kandidat untuk agregasi, ada 256 berbeda
potensial tabel fakta agregat. Karena kita tidak mungkin membangun, toko, dan mengelola
semua agregat ini, kita perlu mempertimbangkan dua primer faktor ketika merancang strategi
agregasi kami. Pertama, kita perlu berpikir tentang pola akses pengguna bisnis '. Dengan kata
lain, data apa yang mereka sering meringkas dengan cepat? Jawaban atas pertanyaan ini dapat
berasal dari kebutuhan bisnis analisis wawasan, serta dari input diperoleh dengan memantau pola
penggunaan aktual. Kedua, kita perlu menilai distribusi statistik dari data. Sebagai contoh,
berapa banyak contoh yang unik yang kita miliki pada setiap tingkat hirarki, dan apa kompresi
seperti yang kita berpindah dari satu tingkat ke yang berikutnya? Jika 50 produk kami
menggulung menjadi 10 merek, kita hanya meringkas 5 baris dasar (rata-rata) untuk menghitung
merek agregat. Dalam hal ini tidak sebanding dengan upaya untuk secara fisik prestore yang
agregat. Di sisi lain, jika kita dapat menghindari menyentuh 100 basis baris dengan mengakses
agregat sebaliknya, itu jauh lebih masuk akal. agregasi permainan intinya mengurangi inputoutput. Secara umum, ruang disk dibutuhkan oleh tabel agregat harus sekitar dua kali ruang
dikonsumsi oleh data tingkat dasar.
Ketersediaan sebuah navigator agregat pertimbangan lain secara keseluruhan kami Strategi
agregasi. Tanpa navigator agregat, jumlah agregat skema untuk pengguna analitik untuk memilih
secara manual dari sangat terbatas-mungkin tidak lebih dari dua agregat per tabel fakta dasar.
agregat fungsi navigator duduk antara klien meminta dan database relasional sistem manajemen.
Navigator memotong permintaan SQL klien dan, sedapat mungkin, memodifikasi sehingga ia
mengakses yang paling tepat meningkatkan kinerja agregat. Navigator agregat membuat
produktif menggunakan tabel agregat sementara buffering aplikasi client. klien tidak perlu secara
khusus menulis permintaan mereka untuk mengakses basis tertentu dibandingkan tabel fakta
gabungan, yang mengharuskan pertanyaan ditulis ulang ketika agregat ditambahkan atau
menjatuhkan. Navigator menangani perubahan portofolio agregat di belakang layar sehingga
klien dapat tetap menyadari, sebagaimana mestinya. Akhirnya, kita harus mempertimbangkan

peran OLAP kubus sebagai bagian dari agregasi kami Strategi karena mereka sangat cocok untuk
respon cepat terhadap diringkas data. Beberapa produk memungkinkan integrasi antara agregat
data dalam kubus dan skema rinci dalam struktur relasional.
Strategi Index awal
Database administrator dapat hiperventilasi ketika mereka belajar dimensi yang tabel sering
memiliki lebih dari satu indeks. Tabel dimensi akan memiliki indeks yang unik pada primary key
tunggal-kolom. Selain itu, kami sarankan indeks B-tree pada kolom atribut tinggi kardinalitas
digunakan untuk kendala. Indeks Bit-dipetakan harus ditempatkan pada semua menengah dan
atribut rendah kardinalitas.
Sementara itu, tabel fakta adalah raksasa dari data warehouse, jadi kita perlu Indeks mereka lebih
hati-hati. Kunci utama dari tabel fakta hampir selalu subset dari kunci asing. Kami biasanya
menempatkan satu, indeks concatenated pada dimensi utama dari tabel fakta. Karena banyak
permintaan dimensi adalah dibatasi pada dimensi saat ini, kunci asing tanggal harus terkemuka
istilah indeks. Selain itu, memiliki tombol tanggal di posisi pertama mempercepat Proses
pemuatan data dimana data tambahan yang mengelompok berdasarkan tanggal. karena sebagian
besar pengoptimalan sekarang mengizinkan lebih dari satu indeks untuk digunakan pada saat
yang sama di menyelesaikan query, kita dapat membangun indeks terpisah pada independen lain
dimensi kunci asing dalam tabel fakta. Lebih jarang, indeks adalah ditempatkan pada fakta-fakta
jika mereka digunakan untuk jangkauan atau banding kendala.
Membuat rencana penyimpanan fisik untuk gudang data tidak berbeda dengan bahwa untuk
database relasional lainnya. Administrator database ingin mempertimbangkan tata letak file
database, termasuk striping untuk meminimalkan input-output pertengkaran. Tabel fakta besar
biasanya dipartisi berdasarkan tanggal, dengan data tersegmentasi bulan, triwulan, atau tahun
menjadi terpisah partisi penyimpanan sementara muncul kepada pengguna sebagai tabel tunggal.
Keuntungan dari partisi menurut tanggal ada dua. Pertanyaan akan berperforma lebih baik karena
mereka hanya mengakses partisi diperlukan untuk menyelesaikan query. Demikian juga, dalam
banyak kasus beban data akan berjalan lebih cepat karena kita hanya perlu membangun kembali
indeks untuk partisi, bukan untuk seluruh tabel. Partisi juga dapat diarsipkan dengan mudah.
Akhirnya, database administrator harus menerapkan sistem monitoring penggunaan sedini

mungkin. Pemantauan penggunaan akan menjadi penting untuk tuning kinerja berkelanjutan,
seperti serta untuk memberikan dukungan kepada pengguna, perencanaan kapasitas, dan internal
marketing.
Data Staging Desain dan Pengembangan
Kegiatan terakhir dalam jalur data desain dan pengembangan pementasan atau sistem ETL. Kita
kadang-kadang mengacu pada pementasan sebagai gunung es dari data proyek gudang.
Sementara gunung es terlihat tangguh dari helm kapal, kita sering tidak mendapatkan apresiasi
penuh besarnya sampai kita berbenturan dengan itu dan menemukan massa yang bersembunyi di
bawah permukaan air.
Seperti yang dijelaskan pada Bab 1, pementasan data mengambil data mentah dari operasional
sistem dan mempersiapkan untuk model dimensi dalam penyajian data daerah. Ini adalah
layanan backroom, bukan layanan permintaan, yang memerlukan kuat sistem aplikasi.
Sayangnya, banyak tim hanya berfokus pada E dan L dari singkatan ETL. Sebagian besar angkat
berat terjadi pada transformasi (T) langkah, di mana kita menggabungkan data, menangani
masalah kualitas, mengidentifikasi data yang diperbarui, mengelola key pengganti, membangun
agregat, dan menangani kesalahan.
Seperti telah mantra kami di seluruh bab ini, Anda harus terlebih dahulu merumuskan
pementasan rencana. Serupa dengan arsitektur teknis, kami merancang aplikasi pementasan
menggunakan serangkaian skema yang dimulai pada tingkat tinggi dan kemudian bor ke dalam
spesifik untuk setiap tabel. Anda perlu memutuskan apakah kita membeli Data pementasan alat
atau membangun kemampuan kita sendiri. Kami biasanya merekomendasikan menggunakan
produk yang tersedia secara komersial. Meskipun Anda tidak dapat mengharapkan untuk
mengembalikan investasi Anda pada iterasi pertama karena kurva belajar, alat akan menyediakan
integrasi metadata lebih besar dan meningkatkan fleksibilitas, usabilitas, dan rawatan dalam
jangka panjang.
Keputusan mendasar lainnya yang akan dibuat menyangkut struktur data toko yang dihasilkan
dari atau digunakan untuk mendukung kegiatan pementasan, sebagaimana kita bahas dalam Bab
1 Normalisasi sumber data sebelum denormalized untuk model dimensi mungkin cocok untuk
menjalin hubungan berduri atau jika sumber sudah normal, tetapi sering tidak diperlukan. Untuk

beberapa, itu tak terduga untuk berpikir tentang menanggulangi kegiatan pementasan tanpa
penggunaan dari struktur normal meskipun ruang penyimpanan tambahan dan usaha diperlukan.
Dalam hal ini data dinormalisasi memenuhi zona nyaman lebih perlu dari syarat mutlak.
Dimensi pementasan tabel
Karena dimensi perlu untuk menyesuaikan dan digunakan kembali seluruh model dimensi,
biasanya mereka adalah tanggung jawab otoritas yang lebih terpusat. The otoritas dimensi
bertanggung jawab untuk menentukan, memelihara, dan menerbitkan dimensi tertentu untuk data
mart yang sesuai. Tindakan penerbitan
sebenarnya semacam replikasi sinkron karena semua mart hilir harus memiliki salinan identik
dari dimensi pada waktu yang sama. Sementara otoritas dimensi telah terpusat tanggung jawab,
ada kemungkinan beberapa pihak berwenang di organisasi kami, masing-masing bertanggung
jawab atas satu atau lebih inti dimensi.
Dimensi dapat diproses secara bersamaan. Namun, semua dimensi terlibat dalam skema harus
dipublikasikan sebelum pementasan data fakta. Tabel dimensi pementasan melibatkan langkahlangkah berikut. Alat pementasan dapat memberikan banyak fungsi ini.
Mengekstrak data dimensi dari sistem sumber operasional. yang diekstraksi Data dapat
dipindahkan ke area stage dimensi dengan baik keluaran ke mengajukan dan menggunakan File
Transfer Protocol (FTP) atau melakukan transfer aliran. Audit statistik dari ekstrak harus
dikumpulkan.
Bersihkan nilai atribut. Tindakan yang tepat harus diambil untuk menangani berikut situasi,
bersama dengan banyak orang lain: nama dan alamat parsing, nilai-nilai deskriptif tidak
konsisten, decode hilang, kode dipenuhi dengan beberapa arti dari waktu ke waktu, data yang
tidak valid, dan data yang hilang.
Kelola tugas kunci pengganti. Karena kita menggunakan kunci pengganti di data gudang, kita
harus memiliki sebuah tabel referensi silang utama terus-menerus dalam area stage untuk setiap
dimensi. Tabel referensi silang melacak kunci pengganti ditugaskan untuk kunci operasional
pada titik waktu, bersama dengan profil atribut. Jika data cross-referensi utama ditangani sebagai
meja datar, bidang akan termasuk yang diidentifikasi dalam Gambar 16.3.

Seperti ditunjukkan dalam Gambar 16.4, kita menginterogasi sumber dimensi diekstraksi data
untuk menentukan apakah itu adalah deretan dimensi baru, update ke yang ada baris, atau tidak.
Rekor baru dari sumber operasional diidentifikasi mudah pada lulus awal karena kunci sumber
operasional tidak terletak di tabel master referensi silang. Dalam hal ini ditunjuk aplikasi
pementasan kunci pengganti baru dan menyisipkan baris baru ke dalam tabel master.

Untuk segera menentukan apakah baris telah berubah, kita bergantung pada redundansi siklik
checksum (CRC) algoritma. Jika CRC identik untuk diekstrak merekam dan baris terbaru dalam

tabel master, maka kita mengabaikan catatan diekstraksi. Kita tidak perlu untuk memeriksa setiap
kolom untuk memastikan bahwa dua baris sama persis.
Jika CRC untuk catatan diekstrak berbeda dari CRC terbaru di tabel referensi silang, maka kita
perlu mempelajari setiap kolom untuk menentukan apa yang diubah dan kemudian bagaimana
perubahan akan ditangani. Jika berubah kolom adalah tipe 1 atribut, maka kita hanya menimpa
nilai atribut. Jika kolom harus ditangani dengan respon tipe 3, perubahan yang dibuat hanya di
baris yang sudah ada. Namun, pengolahan adalah sedikit lebih sulit dengan tipe 2 perubahan.
Dalam hal ini kita menambahkan baris baru ke cross-referensi utama tabel dengan kunci
pengganti baru yang mencerminkan nilai-nilai atribut baru, serta sebagai tanggal yang tepat
efektif, tanggal kedaluwarsa, dan indikator terbaru. Tanggal kadaluarsa dan indikator yang paling
baru pada versi sebelumnya perlu diperbarui untuk mencerminkan bahwa baris sebelumnya tidak
lagi berlaku. Jika kita menggunakan kombinasi teknik SCD dalam satu meja, kita harus
membangun aturan bisnis untuk menentukan perubahan teknik diutamakan.
Langkah terakhir dalam Gambar 16.4 adalah untuk memperbarui kunci pengganti terbaru meja
tugas. Tabel ini terdiri dari dua kolom-operasional Tombol sumber dan kunci pengganti terbaru
yang ditugaskan. Jika kita sudah menangani perubahan menggunakan tipe 2 teknik, tabel ini
akan berisi hanya yang paling baris terakhir. Kami membuat tabel ini untuk memberikan
pencarian cepat ketika menetapkan fakta tabel key pengganti.
Membangun memuat gambar baris dimensi dan mempublikasikan dimensi direvisi. setelah tabel
dimensi mencerminkan ekstrak terbaru (dan telah yakin kualitas terjamin), diterbitkan untuk
semua data mart yang menggunakan dimensi.
Fakta Tabel Staging
Sementara tabel dimensi direplikasi ke semua mart tanggal yang sesuai, tabel fakta data secara
eksplisit tidak diduplikasi. Dengan arsitektur bus data warehouse, batas-batas di sekitar tabel
fakta didasarkan pada bisnis sumber proses (es), bukan pada garis organisasi. Akibatnya, tabel
fakta terisolasi di lokasi yang unik namun tersedia bagi semua yang membutuhkan akses. Tidak
seperti dimensi tabel yang memerlukan otoritas terpusat untuk menjamin konsistensi seluruh
organisasi, tabel fakta dapat dikelola secara lebih terdistribusi, dengan asumsi bahwa setiap

menjanjikan untuk menggunakan dimensi sesuai kewenangan dimensi ini , bukan replikasi data
tabel fakta yang sama di beberapa lokasi. Kami uraikan langkah yang diperlukan untuk
panggung data tabel fakta:
1 Extract Bahkan data dari sistem sumber operasional.
2 Menerima dimensi diperbarui dari otoritas dimensi. Kami ingin untuk memastikan bahwa kita
memiliki set lengkap baris dimensi yang mungkin ditemui dalam data fakta.
3 Pisahkan data fakta dengan rincian yang diperlukan. Sistem sumber Operasional kadangkadang mencakup data pada berbagai tingkat detail dalam yang sama mengajukan. The
granularities harus dipisahkan pada awal proses pementasan.
4. Transform data fakta yang diperlukan. Transformasi umum meliputi perhitungan aritmatika,
konversi waktu, equivalization mata uang atau Satuan ukuran, normalisasi fakta (seperti
pengobatan 12 datedefined ember pada catatan operasional tunggal), dan penanganan nulls.
5. Ganti kunci sumber operasional dengan kunci pengganti. Untuk mengganti operasional kunci
dengan kunci pengganti, kita menggunakan kunci pengganti terbaru tabel tugas yang dibuat oleh
otoritas dimensi. Membuat satu lulus lebih dari tabel fakta untuk setiap dimensi, kita dengan
cepat mengganti pengganti terbaru tiap-tiap tombol operasional yang dihadapi. Kita harus
memastikan referensial integritas pada saat ini daripada menunggu proses load data. Jika kunci
operasional tabel fakta itu tidak menemukan kecocokan dalam key pengganti tabel tugas, kita
memiliki beberapa pilihan. Proses ini dapat dihentikan. The baris dipertanyakan dapat ditulis ke
file ketegangan reloadable. Jika tidak, kita secara otomatis bisa membuat pengganti kunci dan
dimensi baris baru untuk tombol operasional tak tertandingi. Daripada menetapkan diketahui
tunggal kunci dummy untuk semua kunci operasional merepotkan dihadapi, kami menetapkan
tombol pengganti yang berbeda untuk setiap tombol operasional nonlocated. The atribut
deskriptif untuk ini baru ditugaskan kunci pengganti mungkin membaca sesuatu seperti
"Deskripsi tidak diketahui untuk Key Operational XYZ." Dalam hal ini cara, ketika kunci
operasional baru dijelaskan dengan benar, Anda dapat sering menghindari meninjau kembali
kunci pengganti di tabel fakta.

6 Tambahkan tombol tambahan untuk konteks dikenal. Kita kadang-kadang menambahkan

pengganti kunci yang tidak tersedia pada catatan operasional, seperti yang tepat kunci promosi
untuk point-of-sale transaksi atau demografi kunci minidimension yang mengidentifikasi profil
pelanggan saat ini. pengganti kunci untuk menunjukkan "Tidak Berlaku" atau "Tanggal Akan
Ditentukan" akan ditugaskan sesuai.
7 Kualitas-menjamin data tabel fakta. Tentu saja, kita harus menghasilkan jumlah baris lebih dan
lintas-endapan untuk membandingkan dengan statistik ekstrak.
8 Membangun atau memperbarui tabel agregasi fakta. Tabel agregat biasanya yang dibuat di luar
platform database relasional karena mereka konstruksi sangat bergantung pada jenis-dan-sum
pemrosesan sekuensial. Sadarilah bahwa pembalikan atau penyesuaian-periode sebelumnya
dapat mendatangkan malapetaka pada agregasi subsistem.
9. Massal memuat data. Jika tabel fakta tabrakan kunci terjadi selama beban, kita lagi memiliki
beberapa pilihan. Kita bisa menghentikan proses, menulis baris ke file suspense reloadable, atau
additively memperbarui baris sasaran.
10 Tanda pengguna. Akhirnya, menginformasikan komunitas bisnis bahwa fakta tabel telah
diterbitkan dan siap beraksi.
Jalur Siklus Hidup Analytic Aplikasi
Set terakhir kegiatan paralel mengikuti definisi kebutuhan bisnis pada Gambar 16.1 adalah track
aplikasi analitik, di mana kita merancang dan mengembangkan aplikasi yang membahas
sebagian dari persyaratan analisis pengguna. Sebagai pengembang aplikasi dihormati pernah
mengatakan kepada kami, "Ingat, ini adalah bagian yang menyenangkan! "Kami akhirnya
menggunakan investasi di bidang teknologi dan data untuk membantu pengguna membuat
keputusan yang lebih baik. Aplikasi menyediakan mekanisme kunci untuk memperkuat
hubungan antara tim proyek dan bisnis masyarakat. Mereka melayani untuk menyajikan wajah
data warehouse untuk nya pengguna bisnis, dan mereka membawa kebutuhan bisnis kembali ke
tim aplikasi pengembang.
Sementara beberapa orang mungkin merasa bahwa data warehouse harus benar-benar ad hoc
lingkungan query, memberikan aplikasi analitik parameter-driven akan memuaskan persentase

yang besar dari kebutuhan masyarakat bisnis. Tidak ada gunanya membuat setiap awal pengguna
dari awal. Membangun satu set aplikasi analitik menetapkan kerangka kerja analitis yang
konsisten bagi organisasi daripada memungkinkan setiap makro Excel untuk menceritakan kisah
yang sedikit berbeda. aplikasi Analytic juga melayani untuk merangkum keahlian analitik
organisasi, menyediakan melejitkan untuk kurang analitis miring.
Analytic Application Spesifikasi
Setelah definisi kebutuhan bisnis, kita perlu meninjau temuan dan laporan sampel dikumpulkan
untuk mengidentifikasi satu set starter sekitar 10 15 aplikasi analitik. Kami ingin mempersempit
fokus awal kami yang paling penting kemampuan sehingga kita dapat mengelola ekspektasi dan
memastikan pengiriman tepat waktu. Masukan dari masyarakat bisnis akan sangat penting untuk
proses prioritas ini. Sementara 15 aplikasi mungkin tidak terdengar seperti banyak, jumlah
analisis tertentu yang dapat dibuat dari template tunggal hanya dengan mengubah variabel akan
mengejutkan Anda.
Sebelum kita mulai merancang aplikasi awal, sangat membantu untuk menetapkan standar untuk
aplikasi, seperti menu pull-down umum dan konsisten Output tampilan dan nuansa.
Menggunakan standar, kita tentukan setiap template aplikasi, menangkap informasi yang
memadai tentang tata letak, variabel input, perhitungan, dan istirahat sehingga baik pengembang
aplikasi dan bisnis perwakilan memiliki pemahaman yang sama.
Selama kegiatan spesifikasi aplikasi, kita juga harus memberikan pertimbangan untuk organisasi
aplikasi. Kita perlu mengidentifikasi navigasi terstruktur jalan untuk mengakses aplikasi, yang
mencerminkan cara pengguna berpikir tentang bisnis mereka. Memanfaatkan Web dan informasi
disesuaikan portal yang strategi dominan untuk menyebarkan akses aplikasi.
Analytic Application Development
Ketika kita pindah ke tahap pengembangan untuk aplikasi analitik, kita lagi perlu fokus pada
standar. Standar untuk konvensi penamaan, perhitungan, perpustakaan, dan coding harus
ditetapkan untuk meminimalkan ulang di masa depan. Kegiatan pengembangan aplikasi dapat
mulai setelah desain database lengkap, alat akses data dan metadata dipasang, dan bagian dari

sejarah Data telah dimuat. Spesifikasi template aplikasi harus revisited ke account untuk
perubahan yang tak terelakkan untuk model data sejak spesifikasi diselesaikan.
Setiap alat di pasar memiliki trik khusus produk yang dapat menyebabkan itu untuk melompat
melalui lingkaran mundur. Daripada mencoba untuk mempelajari teknik-teknik melalui
percobaan dan kesalahan, Anda harus berinvestasi dalam pendidikan alat-spesifik sesuai atau
tambahan sumber daya untuk tim pengembangan.
Sementara aplikasi yang sedang dikembangkan, beberapa manfaat tambahan hasil. Pengembang
aplikasi, dipersenjatai dengan alat akses data yang kuat, akan segera menemukan tusuk jarum
masalah dalam tumpukan jerami Data meskipun jaminan kualitas yang dilakukan oleh aplikasi
pementasan. Inilah salah satu alasan mengapa kita lebih memilih untuk mendapatkan dimulai
pada kegiatan pengembangan aplikasi sebelum penyelesaian seharusnya pementasan. Tentu saja,
kita perlu memberikan waktu dalam jadwal untuk mengatasi kelemahan yang diidentifikasi oleh
aplikasi analitik.
Para pengembang juga akan menjadi pertama yang realistis menguji waktu respon query.
Sekarang adalah waktu untuk mulai meninjau strategi kinerja-tuning kami. Kegiatan jaminan
kualitas pengembangan aplikasi tidak dapat diselesaikan sampai data stabil. Kita perlu
memastikan bahwa ada cukup waktu dalam jadwal di luar cutoff pementasan data akhir untuk
memungkinkan tertib wrap-up tugas pengembangan aplikasi.
Deployment
Teknologi, data, dan trek aplikasi analitik berkumpul di deployment. Sayangnya, konvergensi ini
tidak terjadi secara alami tetapi membutuhkan substansial preplanning. Mungkin yang lebih
penting, penyebaran yang berhasil menuntut keberanian dan kemauan untuk menilai kesiapan
proyek untuk menyebarkan jujur. Deployment mirip dengan melayani makanan liburan besar
untuk teman dan kerabat. Ini bisa sulit untuk memprediksi secara tepat berapa lama waktu yang
dibutuhkan untuk memasak kalkun. Tentu saja, jika termometer kalkun ini tidak menunjukkan
kematangan, masak dipaksa untuk memperlambat lauk untuk mengkompensasi lag. Dalam kasus
penyebaran data warehouse, data tersebut merupakan hidangan utama, analog untuk kalkun.
Memasak (atau staging) data adalah tugas yang paling tak terduga. Sayangnya, data
pergudangan, bahkan jika data tidak sepenuhnya matang, kita sering masih melanjutkan dengan

penyebaran karena kita mengatakan kepada tamu gudang mereka akan disajikan pada tanggal
dan waktu tertentu.
Karena kita tidak mau memperlambat laju penyebaran, kami berbaris ke kantor mereka dengan
data matang. Tidak pengguna heran kadang-kadang menahan diri dari datang kembali untuk
membantu kedua. Selain kritis menilai kesiapan penyampaian data warehouse, kami juga perlu
paket dengan pendidikan dan dukungan untuk penyebaran. Karena komunitas pengguna harus
menerima gudang untuk itu harus dianggap berhasil, pendidikan sangat penting. Program
pendidikan harus fokus pada lengkap gudang penyampaian: data, aplikasi analitik, dan data alat
akses (yang sesuai). Jika kita memilih untuk mengembangkan bahan-bahan pendidikan in-house,
kita harus memungkinkan setidaknya 1 sampai 2 hari pembangunan untuk setiap jam pendidikan.
Pertimbangkan hal berikut untuk program pendidikan yang efektif:
?? Memahami audiens target Anda; tidak membanjiri.
?? Jangan melatih komunitas bisnis awal sebelum ketersediaan data dan analitik aplikasi.
?? Menunda pendidikan (dan penyebaran) jika data warehouse tidak siap untuk menjadi dirilis.
?? Mendapatkan komitmen dari pihak sponsor untuk "tidak berpendidikan, tidak ada akses"
kebijakan.
Strategi dukungan data warehouse tergantung pada kombinasi manajemen harapan dan realitas
kiriman data warehouse. Dukungan sering disusun dalam struktur-baris pertama dua tingkat
keahlian berada dalam area bisnis, sedangkan dukungan terpusat menyediakan sekunder garis
pertahanan. Selain mengidentifikasi sumber dukungan dan prosedur, kita juga perlu menentukan
pemeliharaan aplikasi dan melepaskan rencana, serta strategi komunikasi yang sedang
berlangsung.
Sama seperti rilis produk perangkat lunak berjalan melalui serangkaian tahap sebelum
ketersediaan umum, sehingga harus data warehouse. Tahap uji alpha terdiri dari tim proyek inti
melakukan sistem tes end-to-end. Seperti setiap pengujian sistem, Anda pasti mengalami
masalah, jadi pastikan ada waktu yang cukup dalam jadwal untuk ulang tak terelakkan. Dengan
pengujian beta, kami melibatkan seperangkat terbatas pengguna bisnis untuk melakukan tes

penerimaan pengguna, terutama yang berlaku untuk relevansi bisnis dan kualitas gudang
kiriman. Akhirnya, data warehouse dirilis untuk ketersediaan umum, meskipun sebagai
peluncuran dikendalikan.
Pemeliharaan Dan Pertumbuhan
Kami telah berhasil melewati penyebaran, jadi sekarang kita siap untuk menendang kembali dan
bersantai. Tidak begitu cepat! Tugas kita masih jauh dari sempurna setelah kami dikerahkan.
Kami perlu untuk terus berinvestasi sumber daya dalam bidang berikut: Dukungan. Dukungan
pengguna sangat penting segera setelah penyebaran di Untuk memastikan bahwa komunitas
bisnis akan ketagihan. Untuk pertama beberapa minggu setelah pendidikan pengguna, tim
dukungan harus bekerja secara proaktif dengan pengguna. Kita tidak bisa duduk kembali bilik
kami dan berasumsi bahwa tidak ada berita dari dunia usaha adalah berita baik. Jika kita tidak
mendengar dari mereka, maka kemungkinan bahwa tidak ada yang menggunakan data gudang.
Relokasi (setidaknya untuk sementara) untuk komunitas bisnis sehingga bahwa pengguna
memiliki akses yang mudah untuk mendukung sumber daya. Jika masalah dengan data atau
aplikasi yang terungkap, jujur dengan bisnis untuk membangun kredibilitas saat mengambil
tindakan segera untuk memperbaiki masalah. Sekali lagi, jika penyampaian gudang Anda tidak
berkualitas tinggi, tak terduga tuntutan dukungan untuk rekonsiliasi data dan aplikasi ulang dapat
luar biasa.
Pendidikan.
Kita perlu menyediakan program pendidikan berkelanjutan untuk data gudang. Kurikulum harus
mencakup penyegaran formal dan canggih kursus, serta kursus pengantar ulangi. Pendidikan
lebih informal dapat ditawarkan kepada para pengembang dan pengguna kekuatan untuk
mendorong pertukaran tersebut ide.
Dukungan teknis.
Data warehouse tidak lagi bagus untuk dimiliki tapi kebutuhan harus diperlakukan sebagai
lingkungan produksi, lengkap dengan tingkat layanan perjanjian. Tentu saja, dukungan teknis
harus proaktif memantau kinerja dan tren kapasitas sistem. Kami tidak ingin bergantung pada
bisnis masyarakat untuk memberitahu kami bahwa kinerja telah terdegradasi.

Dukungan Program.
Sementara pelaksanaan fase tertentu dari data gudang dapat mereda, program data warehouse
hidup. Kita perlu terus memantau kemajuan terhadap keberhasilan yang telah disepakati-on
kriteria. Kita perlu untuk memasarkan kesuksesan kami. Kita juga perlu memastikan bahwa
implementasi yang ada tetap di jalur dan terus mengatasi kebutuhan bisnis. Ulasan pos
pemeriksaan yang sedang berlangsung adalah alat kunci untuk menilai dan mengidentifikasi
peluang untuk perbaikan dengan kiriman sebelumnya. Data gudang paling sering jatuh keluar
jalur ketika mereka kehilangan fokus mereka untuk melayani kebutuhan informasi dari pengguna
bisnis.
Jika kita sudah melakukan tugas kita dengan benar, pasti akan ada permintaan untuk
pertumbuhan, baik bagi pengguna baru, data baru, aplikasi baru, atau perangkat tambahan utama
untuk kiriman yang ada. Seperti yang kita menyarankan sebelumnya ketika membahas scoping,
tim data warehouse tidak harus membuat keputusan tentang pertumbuhan ini Pilihan dalam
ruang hampa. Pengelola perlu dilibatkan dalam prioritas yang proses. Sekali lagi, ini mungkin
waktu yang baik untuk meningkatkan prioritas yang analisis kuadran diilustrasikan pada Gambar
16.2. Jika Anda belum melakukannya, akan sangat membantu untuk memiliki komite sponsor
bisnis eksekutif di tempat untuk berbagi tanggung jawab untuk prioritas tersebut. Setelah
prioritas baru telah didirikan, maka kita kembali ke awal bab ini dan melakukan itu semua lagi!
Mudah-mudahan, kita dapat memanfaatkan banyak pekerjaan sebelumnya, terutama mengenai
arsitektur teknis dan data.
Kesalahan Umum Data Warehousing Untuk Di Hindari
Kami sudah bilang apa yang harus dilakukan dalam bab ini; sekarang kita akan
menyeimbangkan rekomendasi tersebut dengan daftar apa yang tidak boleh dilakukan. Kami
menutup Bab 15 dengan daftar kesalahan pemodelan dimensi umum. Di sini kita telah terdaftar
untuk menghindari kesalahan ketika membangun dan mengelola data warehouse. Kesalahan
digambarkan sebagai serangkaian karikatur negatif. Maafkan jejak sinisme Anda mungkin
dideteksi. Tujuan kami adalah bagi Anda untuk belajar dari karikatur ini berdasarkan kesalahan
dibuat oleh tim data warehouse yang tidak disebutkan namanya. Seperti kata George Santayana,

"Mereka yang tidak bisa mengingat masa lalu dikutuk untuk mengulanginya. "Mari kita semua
tidak setuju untuk mengulang kesalahan-kesalahan ini.
Seperti dalam daftar kesalahan pemodelan dimensi Bab 15, kami telah terdaftar ini kesalahan
dalam urutan terbalik, berakhir dengan yang paling penting. Namun, salah satu dari ini bisa
show-sumbat.
Kesalahan 10: Menerima premis bahwa mereka yang bertanggung jawab perusahaan itu besar
sistem sumber terlalu penting dan sibuk untuk menghabiskan waktu dengan data warehouse tim.
Tentu saja, mereka tidak bisa mengubah prosedur operasional mereka secara signifikan untuk
melewati data ke atau dari gudang. Jika organisasi Anda benar-benar memahami dan nilai-nilai
data warehouse, maka sistem sumber operasional harus mitra yang efektif dengan Anda dalam
men-download data yang diperlukan dan di upload dibersihkan data yang sesuai.
Kesalahan 9: Setelah data warehouse telah digulirkan, mengatur pertemuan perencanaan untuk
membahas komunikasi dengan pengguna bisnis, jika anggaran memungkinkan. newsletter, sesi
pelatihan, dan dukungan pribadi berkelanjutan komunitas bisnis harus gating item untuk
peluncuran pertama dari data warehouse.
Kesalahan 8: Pastikan personil pendukung data warehouse memiliki kantor yang bagus di
Bangunan IT, yang hanya sebuah perjalanan singkat dari pengguna bisnis, dan mengatur data
nomor dukungan gudang dengan banyak pilihan nada sentuh. Data warehouse dukungan orang
harus secara fisik berada di departemen bisnis, dan sementara bertugas, mereka harus
menghabiskan seluruh waktu mereka dikhususkan untuk konten bisnis dari departemen yang
mereka layani. Hubungan tersebut menimbulkan kepercayaan dan kredibilitas dengan pengguna
bisnis.
Kesalahan 7: Melatih setiap pengguna pada setiap fitur dari alat akses data dalam pelatihan
pertama kelas, menunda pendidikan isi data karena kelas menggunakan data boneka (nyata Data
tidak akan siap untuk pasangan lain dari bulan), dan menyatakan sukses di penyelesaian kelas
pelatihan pertama karena data warehouse telah diluncurkan ke pengguna bisnis. Pelatihan
Penundaan sampai data mart pertama Anda siap untuk pergi hidup pada data real. Jauhkan sesi
latihan pertama pendek, dan hanya fokus pada penggunaan sederhana dari alat akses.
Mengalokasikan lebih banyak waktu untuk isi data dan aplikasi analitik daripada alat. Rencana

pada serangkaian permanen mulai kelas pelatihan, serta tindak lanjut kelas pelatihan. mengambil
kredit untuk tonggak penerimaan pengguna ketika pengguna masih menggunakan data gudang
enam bulan setelah mereka telah dilatih.
Kesalahan 6: Asumsikan bahwa pengguna bisnis secara alami akan tertarik ke arah data yang
kuat dan mengembangkan pembunuh sendiri aplikasi analitis mereka. Bisnis pengguna tidak
aplikasi pengembang. Mereka akan merangkul gudang data hanya jika satu set aplikasi analitik
prebuilt memanggilnya mereka.
Kesalahan 5: Sebelum menerapkan data warehouse, melakukan analisis yang komprehensif
menjelaskan semua aset data yang mungkin dari perusahaan dan semua penggunaan
dimaksudkan informasi, dan menghindari ilusi menggoda pembangunan berulang, yang hanya
alasan untuk tidak mendapatkan itu benar pada kali pertama. Sangat sedikit organisasi dan
manusia dapat mengembangkan rencana komprehensif yang sempurna untuk data gudang
dimuka. Tidak hanya aset data dari suatu organisasi terlalu luas dan kompleks untuk menjelaskan
sepenuhnya, tetapi juga driver bisnis yang mendesak akan berubah secara signifikan selama
masa gudang data. Mulailah dengan ringan arsitektur data warehouse bus dimensi sesuai dan
sesuai fakta, dan kemudian membangun gudang data Anda iteratif. Anda akan terus mengubah
dan membangun selamanya.
Kesalahan 4: Jangan repot-repot eksekutif senior dari organisasi Anda dengan data gudang
sampai Anda telah menerapkan dan dapat menunjukkan keberhasilan yang signifikan. Para
eksekutif senior harus mendukung upaya data warehouse dari awal. Jika tidak, organisasi Anda
mungkin tidak akan dapat menggunakan data warehouse secara efektif. Dapatkan dukungan
mereka sebelum meluncurkan proyek.
Kesalahan 3: Mendorong pengguna bisnis untuk memberikan umpan balik terus menerus
sepanjang siklus pengembangan tentang sumber data baru dan metrik kinerja utama mereka ingin
mengakses, dan pastikan untuk menyertakan persyaratan tersebut di inprocess yang rilis. Anda
harus berpikir seperti seorang pengembang perangkat lunak dan mengelola tiga tahap sangat
terlihat mengembangkan setiap data mart: (1) bisnis persyaratan pengumpulan panggung, di
mana setiap saran dianggap serius, (2) tahap implementasi, di mana perubahan dapat
diakomodasi tetapi harus dinegosiasikan dan umumnya akan menyebabkan jadwal slip, dan (3)

tahap peluncuran, di mana fitur proyek dibekukan. Di kedua dan tahap ketiga, Anda harus
menghindari berbahaya scope creep (dan berhenti menjadi seperti orang akomodatif).
Kesalahan 2: Setuju untuk memberikan high-profile customer-centric Data mart, idealnya
pelanggan profitabilitas atau kepuasan pelanggan, sebagai penyampaian pertama Anda. Ini jenis
data mart dikonsolidasikan, mart tingkat kedua dengan dependensi yang serius pada berbagai
sumber data. Profitabilitas pelanggan membutuhkan semua sumber pendapatan dan semua
sumber biaya, serta skema alokasi untuk memetakan biaya ke pendapatan! Untuk penyampaian
pertama, berfokus pada satu sumber data, dan melakukan data mart lebih ambisius nanti.
Kesalahan 1: Jangan berbicara dengan pengguna bisnis; lebih, bergantung pada konsultan atau
internal yang ahli untuk memberikan interpretasi mereka atas persyaratan data warehouse
pengguna. Tugas Anda adalah untuk menjadi publisher dari data yang benar. Untuk mencapai
tujuan pekerjaan Anda, Anda harus mendengarkan pengguna bisnis, yang selalu benar. Tidak ada
pengganti untuk interaksi langsung dengan pengguna. Mengembangkan kemampuan untuk
mendengarkan. Para pengguna bisnis, bukan, menentukan kesesuaian dan kegunaan dari data
gudang deliverable. Anda akan berhasil hanya jika Anda melayani bisnis kebutuhan pengguna.
Ringkasan
Bab ini memberikan tur kecepatan tinggi siklus hidup data warehouse proyek. Kami menyentuh
pada proses kunci dan praktik terbaik dari desain data werehouse dan upaya pelaksanaan.
Sementara setiap proyek adalah sedikit berbeda dari depan, mau tidak mau Anda harus
memusatkan perhatian pada masing-masing tugas utama yang kita bahas untuk memastikan
inisiatif sukses.