Chapter 16 Membangun Data Warehouse

71
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

description

dmdw

Transcript of Chapter 16 Membangun Data Warehouse

Nama : MardaleniBp: 1010963003

Membangun Data WarehouseChapter 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 pendengarBab 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. Mudah-mudahan, 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 teman-temannya 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 lapisan-lapisan 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 lintas-perusahaan. 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 pertanyaan-pertanyaan secara langsung. Jika kita bertemu dengan orang yang memiliki lebih banyak tangan-on 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 benar-benar 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 kadang-kadang 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 tugas-tugas 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 desainModel 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 kacang-dan-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 menunda-nunda 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 masing-masing 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 input-output. 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 tabelKarena 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 penerbitansebenarnya 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 langkah-langkah 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 kadang-kadang 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 terseb