Aspek Arsitektur Data Warehouse Halaman ini adalah daftar dari aspek arsitektur data warehouse. Arsitektur adalah istilah yang cukup samar-samar. Saya pikir arsitektur sebagai keputusan desain sistem yang biasanya tidak mudah berubah. Keputusan ini tidak mudah berubah karena jumlah pekerjaan, uang, dan politik yang terlibat dalam melakukannya. Ini daftar dari aspek arsitektur bahwa data warehouse pengambil keputusan akan harus berurusan dengan diri mereka sendiri. Ada beberapa isu arsitektur banyak lainnya yang mempengaruhi data warehouse, misalnya, topologi jaringan, tetapi ini harus dibuat dengan semua sistem organisasi dalam pikiran (dan dengan orang lain selain tim data warehouse menjadi pengambil keputusan utama.) Daftar ini tidak akan mencoba untuk memberikan penjelasan rinci tentang berbagai jenis arsitektur. Sebaliknya, saya menyajikan daftar ini karena literatur data warehousing biasanya muddles subyek arsitektur dengan lumping berbagai jenis keputusan bersama atau melupakan beberapa jenis keputusan. Juga, literatur membuat keputusan ini tampaknya jauh lebih hitam dan putih dari mereka. Sebagai contoh, di bidang apa yang saya sebut pelaporan dan pementasan arsitektur menyimpan data, banyak literatur membahas hanya "perusahaan" data warehouse, data mart tergantung, dan pilihan data independen mart. Pada kenyataannya, ada banyak variasi lebih yang digunakan yang tidak dapat dengan mudah diberi label tajam. Konsistensi data arsitektur Ini adalah pilihan dari apa sumber data, dimensi, aturan bisnis, semantik, dan metrik organisasi memilih untuk dimasukkan ke dalam penggunaan umum. Itu juga merupakan pilihan yang sama pentingnya dari apa sumber data, dimensi, aturan bisnis, semantik, dan metrik organisasi memilih untuk tidak dimasukkan ke dalam penggunaan umum. Ini adalah jauh aspek yang paling sulit dari arsitektur untuk menerapkan dan memelihara karena melibatkan politik organisasi. Namun, menentukan arsitektur ini lebih berkaitan dengan menentukan tempat data warehouse dalam bisnis Anda daripada keputusan arsitektur lainnya. Menurut pendapat saya, keputusan yang terlibat dalam menentukan arsitektur ini harus mendorong semua keputusan arsitektur lainnya. Sayangnya, ini penentuan arsitektur ini tampaknya sering akan mundur ke daripada sadar dibuat. Pelaporan menyimpan data dan pementasan arsitektur menyimpan data Alasan utama kami menyimpan data dalam sistem data warehousing begitu mereka dapat: 1) dilaporkan melawan, 2) dibersihkan, dan (kadang-kadang) 3) diangkut ke toko lain data di mana mereka dapat dilaporkan melawan dan / atau dibersihkan. Menentukan di mana kita menyimpan data untuk melaporkan melawan adalah apa yang saya sebut data pelaporan arsitektur toko. 1Semua keputusan lainnya adalah apa yang saya sebut pementasan arsitektur menyimpan data. Seperti disebutkan sebelumnya, ada variasi tak terbatas arsitektur ini. Banyak tulisan-tulisan pada aspek atau arsitektur mengambil sebuah nada agama. Bahwa, daripada membahas apa yang akan membuat paling masuk akal bagi organisasi pelaksana data warehouse, diskusi sering salah satu dari kemurnian dan keindahan arsitektur atau konsepsi penulis tentang kebenaran dan kekeliruan. Data pemodelan arsitektur Ini adalah pilihan apakah Anda ingin menggunakan denormalized, normalisasi, berorientasi objek, proprietary multidimensi, dll model data. Seperti yang Anda tebak, itu masuk akal bagi suatu organisasi untuk menggunakan berbagai model. Alat arsitektur Ini adalah pilihan Anda alat yang Anda akan gunakan untuk pelaporan dan untuk apa yang saya sebut infrastruktur. Pengolahan tingkatan arsitektur Ini adalah pilihan Anda dari apa platform fisik akan melakukan apa potongan pemrosesan konkuren yang terjadi ketika menggunakan data warehouse. Hal ini dapat berkisar dari arsitektur sederhana seperti berbasis host pelaporan ke salah satu serumit diagram pada halaman 32 dari Ralph Kimball "Data Webhouse Toolkit". Arsitektur keamanan Jika Anda perlu untuk membatasi akses ke tingkat baris atau kolom, Anda mungkin akan harus menggunakan beberapa cara lain untuk mencapai hal ini selain mekanisme keamanan yang biasa di organisasi Anda. Perhatikan bahwa sementara keamanan tidak mungkin secara teknis sulit untuk diterapkan, dapat menyebabkan kekhawatiran politik. Sebagai komentar terakhir, izinkan saya menyatakan bahwa dalam jangka panjang, keputusan pada arsitektur konsistensi data mungkin akan memiliki pengaruh lebih banyak pada pengembalian investasi dalam gudang data daripada keputusan arsitektur lainnya. Untuk mendapatkan keuntungan terbaik dari sebuah gudang data (atau sistem lainnya), praktek bisnis yang harus mengubah dalam hubungannya dengan atau sebagai akibat dari implementasi sistem. Sadar penentuan arsitektur konsistensi data hampir selalu merupakan prasyarat untuk menggunakan data warehouse untuk menghasilkan perubahan praktik bisnis.Apa yang harus Belajar Tentang Dalam Rangka untuk Speed Up Data Warehouse query Tulisan ini adalah daftar cucian pelaksana item data warehouse mungkin ingin mempelajari lebih lanjut tentang untuk mempercepat data permintaan gudang atau untuk membuat data warehouse "lingkungan" lebih responsif terhadap sebagian besar pengguna permintaan data warehouse. Tulisan ini tidak akan mencoba untuk memberikan penjelasan rinci tentang topik ini. Juga tidak termasuk topik dalam daftar ini pernyataan bahwa pengetahuan tentang topik pasti akan mempercepat query. Sebaliknya, data warehouse pelaksana dapat menggunakan kertas ini sebagai titik awal dalam pencarian mereka cara untuk mempercepat query. Daftar ini mencakup topik-topik yang relevan dengan banyak akses teknologi relasional database alat dan data. Beberapa topik yang berlaku, untuk yang terbaik dari pengetahuan saya, dengan teknologi satu atau dua vendor 'tidak terdaftar. SQL SELECT pernyataan Ini adalah pengetahuan batuan dasar. Hal ini sangat berguna untuk mendapatkan buku tentang SQL (ada cukup beberapa yang baik) dan review (atau belajar) topik ini. Meskipun Anda mungkin berpikir bahwa kemampuan SQL query tool anda generasi mengurangi kebutuhan akan pengetahuan ini, Anda akhirnya akan menemukan pengetahuan SQL cukup membantu. Bagaimana database Anda bergabung tabel, tabel serikat, indeks menggunakan, pilih jalur aksesIni adalah pengetahuan landasan lagi. Sayangnya, informasi ini tidak mungkin bahwa diakses. Jika informasi itu ada, mungkin buruk ditulis, ditulis untuk audiens akademik, dan / atau tersebar di antara banyak manual. Namun demikian, ada baiknya melakukan upaya bertekad untuk memahami topik ini. - Komunitas vendor / konsultan akan melakukan sendiri dengan baik jika mencoba jauh lebih sulit untuk mengkomunikasikan informasi ini secara koheren dan dipahami. Statistik apa database Anda memberikan pada eksekusi queryKadang-kadang orang-orang dari kita membangun toko informasi bagi pengguna untuk menganalisis melupakan kebutuhan kita sendiri informasi. Anda perlu informasi ini untuk mengidentifikasi permintaan yang terutama sumber daya konsumtif. Anda mungkin akan peduli dengan rumpun pertanyaan yang jauh lebih konsumtif dari rata-rata. Terkadang penyelesaian masalah konsumsi adalah penulisan ulang sederhana query. Kadang-kadang resolusi yang lebih teknis terlibat dan memerlukan melakukan banyak hal yang tercantum dalam makalah ini. Dan kadang-kadang solusinya adalah melakukan apa-apa - Anda hanya harus menerima bahwa data warehouse Anda harus mendukung pertanyaan ini menuntut. Agregat tabel 3Ini mungkin adalah metode yang paling digunakan untuk mempercepat query. Ada banyak diskusi ini dalam literatur. Buku-buku "The Data Warehouse Lifecycle Toolkit", "The Data Warehouse Toolkit", dan "Data Warehousing di Dunia Nyata" telah sangat baik non-teknologi diskusi yang spesifik dari topik ini. Agregat navigator / redirectors permintaanIni adalah teknologi yang secara otomatis mengarahkan query ke data agregat jika data tersebut tersedia dan sesuai untuk query. PartisiIni mungkin adalah metode yang paling umum kedua mempercepat query. Perhatikan bahwa partisi datang dalam banyak hal, bentuk, dan bentuk. Setidaknya, itu membagi satu tabel menjadi beberapa tabel biasanya didasarkan pada waktu data tabel mewakili. Perhatikan bahwa kedua tabel dan indeks dapat dipartisi. B-tree pengindeksanMenambahkan indeks banyak metode lain yang umum untuk mempercepat query. Perhatikan bahwa orang-orang dengan pola pikir proses transaksi mungkin memiliki waktu yang sulit menerima sebagai banyak menggunakan indeks ini sebagai biasanya membantu dalam data warehouse. Dimensi pemodelanDengan teknologi database tertentu, model ini dapat mengurangi jumlah jenis / penggabungan yang berlangsung ketika bergabung tabel. Dan, beberapa alat permintaan dapat menghasilkan SQL lebih efisien jika data dimodelkan dimensi. Juga, jika Anda menggunakan kunci pengganti dalam hubungannya dengan pemodelan dimensi, bergabung mungkin lebih efisien. Parallelizing eksekusi queryPerkembangan teknologi database telah membuat melakukan hal ini jauh lebih mudah. Catatan,bagaimanapun, jumlah pengguna yang menjalankan query dan jumlah data yang akan dikembalikan dalam query kadang-kadang dapat membatasi efektivitas dari teknik ini. Pengarsipan / membersihkan data yangKadang-kadang biaya harus memindai melalui data yang lebih tua melebihi manfaat dari memiliki itu tersedia dalam kemungkinan tidak mungkin seseorang ingin memeriksanya. Mengurangi lebar tabel besar yang bisa dipindaiAda juga banyak cara untuk melakukan hal ini. Sebelum mendapatkan mewah dengan ini ada baiknya meluangkan waktu untuk memahami apa yang sebenarnya membutuhkan ruang dalam tabel database Anda. Benar-benar denormalizing tabel agregatJika tabel ini dapat sangat diindeks dan dapat dipertahankan dengan menyegarkan lengkap, persyaratan pengolahan join dapat dihilangkan. Memuat tabel sepenuhnya dalam memoriMenganggap memori yang tersedia untuk melakukan ini dan Anda telah meneliti topik lain dalam makalah ini, ini mungkin merupakan strategi yang menarik. Bit dipetakan pengindeksanTeknik ini dapat bekerja dengan baik pada wilayah yang mengambil rendahnya jumlah nilai yang berbeda (misalnya, kardinalitas rendah) dan cenderung berada dalam klausa WHERE sering. Striping fileIni berarti menyebarkan file melalui disk fisik beberapa. Lihatlah ke dalam topik RAID untuk lebih jelasnya. Menemukan file yang berbeda digunakan secara bersamaan pada disk yang berbeda 5Ini adalah hal-hal dasar tetapi dapat membantu. Defragmentation meja dan file indeksIni adalah hal yang lebih mendasar. Solid State DiskSeharusnya harga telah turun dalam beberapa tahun terakhir. Disk controllerTerlalu sedikit dapat menjadi hambatan permintaan. Apa alat permintaan Anda mencoba untuk melakukan melalui SQL dan apa yang dilakukannya internalBuku "The Data Warehouse Toolkit" memiliki diskusi yang baik di mana alat query mungkin jatuh pendek. Alasan Anda perlu belajar tentang hal ini adalah untuk mencegah menggunakan alat query di mana itu tidak efisien atau untuk tahu kapan Anda mungkin membangun beberapa "mendapatkan arounds". Query penjadwalan kemampuanHal ini tidak selalu mempercepat query yang diberikan. Namun, permintaan penjadwalan sumber daya konsumtif untuk off-jam kali dapat membebaskan sumber daya untuk permintaan lain selama prime time. Query antrianSeperti penjadwalan, hal ini tidak mempercepat permintaan menyerah. Namun, fasilitas ini memberi Anda sarana sehingga prioritas query (seperti permintaan yang diperlukan untuk memperoleh informasi untuk penutupan bulanan buku-buku keuangan) dapat mengeksekusi lebih cepat.Query akseleratorIni membantu Anda menghasilkan SQL lebih efisien. Perhatikan bahwa mereka mungkin lebih bermanfaat bagi mereka yang melaporkan off dari database yang sangat normal. Query gubernurPermintaan berhenti ini biasanya setelah sejumlah tertentu dari baris telah kembali dan / atau waktu yang ditentukan telah berlalu. Query nannyIni adalah istilah saya untuk teknologi yang memperingatkan (memarahi?) Pengguna jika dia mengajukan sebuah permintaan yang tidak efisien. Beberapa memberikan petunjuk tentang bagaimana membuat query lebih efisien dan beberapa (saya telah mendengar) benar-benar mencoba untuk memperbaiki query. "Productionizing" sering digunakan, permintaan sumber daya yang sangat konsumtifQuery tertentu mungkin harus ditulis oleh seseorang dengan banyak pengetahuan bagaimana membuat query yang efisien. Menyimpan gambar dari laporanJika laporan berdasarkan query yang digunakan oleh banyak orang dan on-line pengambilan laporan diperlukan, citra laporan dapat disimpan. Permintaan itu perlu dijalankan hanya sekali dan mungkin pada waktu kurang sibuk. Ada alat yang memungkinkan pengambilan cerdas data laporan disimpan. Query alat caching hasilBeberapa alat menyimpan hasil dari beberapa permintaan. Jika permintaan yang sama dijalankan lagi, alat ini dapat memeriksa untuk melihat apakah hasilnya disimpan. Atau, jika subset dari set hasil diambil sebelumnya diinginkan, alat akan membaca hasil query diambil sebelumnya diatur daripada data warehouse. 7Alat query preview subset dari catatanJika permintaan sedang dikembangkan, beberapa alat memudahkan untuk mengambil subset kecil dari catatan yang memenuhi kriteria queri. Hal ini membuat lebih cepat untuk menguji permintaan dan luka bawah jumlah permintaan tes berpotensi mahal. Membuat dua salinan dari data warehouse - satu untuk "operasional" pengguna dan satu untuk "analitis" penggunaIni sebenarnya sulit untuk menarik garis antara apa yang penggunaan operasional dan apa gunanya analisis data warehouse. Namun, dalam sebuah gudang data khas sebagian besar pengguna (biasanya dengan lebih "operasional" kebutuhan) menjalankan IS ditulis, query parameter. Sebuah jumlah yang relatif kecil pengguna (biasanya dengan lebih "analitis" kebutuhan) berjalan sangat berpotensi sumber daya konsumtif ad hoc query. - Meskipun belum tentu cantik, kadang-kadang cara terbaik untuk menangani ini menggunakan campuran dari data warehouse adalah untuk membuat salinan terpisah dari data warehouse untuk setiap kelompok pengguna. Multi-tier arsitektur / partisi AplikasiBeberapa alat query memungkinkan Anda untuk menjalankan komponen yang berbeda (misalnya, "tingkatan" atau "partisi") dari alat pada server hardware yang berbeda. Tabel kompresiMembaca blok sedikit data yang dapat mengakibatkan kinerja query ditingkatkan. Perhatikan ada banyak pendekatan untuk mengompresi data yang Anda mungkin harus bereksperimen dengan. Jaringan kemacetanMeskipun Anda tidak perlu menjadi seorang ahli pada topologi jaringan, jika beberapa pengguna Anda akan menjalankan query yang menghasilkan set hasil yang besar (dan tidak berasumsi bahwa hanya laporan panjang membawa kembali hasil besar set untuk alat query), membayar untuk melacak aliran data dari server ke workstation pengguna untuk melihat apakah ada komponen jaringan cocok. Sebagai contoh, Fast Ethernet mungkin dalam fasilitas baru Anda, tetapi pengguna Anda mungkin memiliki kartu antarmuka jaringan 10Mbps .. Atau, penggunaAnda mungkin memiliki kartu yang diiklankan untuk tampil di 100Mbps yang pada kenyataannya tampil di 30Mbps. Juga, cari tahu bagaimana jaringan Anda orang keseimbangan beban. Mereka lebih digunakan untuk berurusan dengan proses transaksi diprediksi dibandingkan tuntutan data yang sangat variabel pergudangan. Dan jika perlu, cari tahu biaya menjatuhkan kabel lebih sehingga Anda dapat menempatkan pengguna yang menjalankan set hasil yang besar memproduksi query pada segmen jaringan khusus. Jika Anda telah menginvestasikan jutaan dalam gudang data, biaya dari listrik dan kawat mungkin worth it. Teknologi database yang dirancang khusus untuk data warehousingGoogle data warehouse peralatan. Kolumnar databaseBanyak dari peralatan data warehouse fitur arsitektur ini. Biaya pemasangan lebih CPU / lebih cepat, memori, diskKadang-kadang membeli logam (jauh) cara paling murah untuk mempercepat query Anda.Beberapa pemikiran akhir tentang mempercepat query: Anda terbaik berharap bahwa banyak pertanyaan Anda akan menjalankan "lama" waktu. Anda akan mencegah beberapa masalah jika Anda menghabiskan waktu mengajar pengguna Anda tentang apa, secara umum, akan memakan waktu yang lama.Sejalan dengan apa yang saya katakan, Anda dapat menghabiskan banyak waktu query tala. Meskipun banyak IS orang suka menghabiskan waktu mereka query tuning, kali ini tala dapat mengambil IS jauh dari gudang data masalah yang solusinya lebih berarti bagi bisnis lainnya.Pada kenyataannya bidang mempercepat query melibatkan banyak dugaan, hal perbuatan dengan intuisi, trial and error, dan membuat tidak nyaman trade-off.9Apa yang harus Belajar Tentang di Order untuk Speed Up data Memuat Gudang Tulisan ini merupakan daftar cucian pelaksana item data warehouse mungkin ingin mempelajari lebih lanjut tentang dalam rangka mempercepat proses penggalian, mengubah dan memuat data (selanjutnya hanya disebut sebagai loading) atau untuk membuat proses ini lebih rentan terhadap kesalahan. Tulisan ini tidak akan mencoba untuk memberikan penjelasan rinci tentang topik ini. Juga tidak termasuk dalam daftar topik pernyataan bahwa pengetahuan tentang topik pasti akan mempercepat loading. Sebaliknya, pelaksana gudang data dapat menggunakan kertas ini sebagai titik awal dalam pencarian mereka cara untuk mempercepat loading. Daftar ini tidak mencakup poin relevan dengan teknologi vendor tertentu itu. DBA Anda harus tahu beberapa cara untuk mempercepat beban yang hanya berlaku untuk teknologi vendor DBMS Anda. Seberapa sering pengguna benar-benar membutuhkan data diperbaruiSering kali data warehouse pengembang tanpa bertanya menyerah pada tuntutan yang paling ekstrim untuk kesegaran data atau mereka secara otomatis mengasumsikan data perlu diperbarui jauh lebih sering daripada masuk akal bisnis. Meskipun kadang-kadang Anda membaca artikel konyol dalam pers perdagangan dan dari analis industri (yang telah menciptakan istilah "latency informasi" mengerikan) tentang bagaimana dunia bisnis ingin tahu segala sesuatu dengan segera, kenyataannya sangat berbeda. Jika data warehouse Anda tidak ada untuk mendukung sehari-hari monitoring dan analisis, pertanyaan mengapa harus diperbarui setiap hari. Jika data warehouse Anda tidak ada untuk minggu-ke-minggu pemantauan dan analisis, pertanyaan mengapa harus diperbarui setiap minggu. By the way, meskipun, jika Anda memutuskan untuk memperbarui mingguan atau bulanan, mencoba merancang proses loading Anda sehingga Anda tidak terikat dengan beban pada interval tertentu. Mungkin ada beberapa "krisis" saat-saat ketika Anda harus memuat lebih sering. Bagaimana drop dan membangun kembali indeks dan cara mengatur faktor indeks mengisiJika Anda memperbarui sebagian besar database (saya sudah mendengar perkiraan 10-25% up), Anda mungkin ingin belajar tentang menjatuhkan indeks sebelum beban database dan kemudian kembali membangun mereka setelah beban. Jika Anda tidak menjatuhkan indeks, Anda ingin memastikan Anda mengatur faktor indeks mengisi sehingga disk drive server Anda jangan buang waktu mencari ruang di mana untuk menulis update indeks. Fasilitas apa yang database memiliki data bongkar muat dan mana fasilitas tersebut tidak masuk akal untuk menggunakanDatabase Banyak cara untuk mempercepat loading pada mengorbankan memeriksa integritas data. Perhatikan bahwa loader massal tertentu melakukan lebih dari beban - mereka akan memformat data dan data kadang-kadang agregat. Apa masukan format file akan mempercepat loading massalSering kali operasi dilakukan pada data masukan pada platform sistem pengumpan (misalnya, menyortir, menghilangkan bidang dikemas dan ditandatangani) dapat mempercepat loading. Cara memparalelkan beban meja dan pemeliharaan indeks atau penciptaan kembaliMenjatuhkan indeks dan bongkar muat secara paralel drastis dapat meningkatkan waktu loading. By the way, mempelajari perbedaan antara pipa, komponen, dan paralelisme data. Mengingat keadaan, berbagai jenis paralelisme dapat memiliki luas berbagai jumlah efek. Cara memuat database melalui sungaiAlat ETL tertentu akan memungkinkan Anda untuk mengekstrak, mengubah, dan beban dalam satu proses. Artinya, tidak perlu untuk membuat file intermediate. Anda, meskipun, harus berhati-hati tentang data, platform sumber, ukuran pembatasan skalabilitas, dan pembatasan seberapa canggih transformasi Anda efisien dapat. Bagaimana indeks digunakan oleh optimizer database AndaAnda perlu mempelajari ini sehingga Anda dapat mengetahui apakah indeks Anda benar-benar akan terbiasa. Dalam versi yang lebih baru dari perangkat lunak DBMS, Anda mungkin bisa lolos dengan indeks kurang dari dalam versi yang lebih tua. Apa pemeriksaan integritas harus dilakukan dalam proses pemuatanSetelah Anda melakukan beban awal tabel data warehouse, Anda mungkin ingin memulai "diskusi" tentang bagaimana semua kesalahan yang Anda temukan harus terjebak dalam sistem pengumpan (sebaiknya pada saat entri data). Dimana tidak masuk akal untuk mengubah data11Mungkin ada tempat lebih cepat untuk melakukannya daripada di gudang data sistem database Anda. Anda mungkin ingin bekerja dengan file datar dan semacam berdedikasi / merge utilitas baik pada platform gudang data atau, jika sumber data berada di platform lain, Anda mungkin ingin melakukannya pada platform tersebut. Masalah dengan melakukan hal ini pada platform sistem sumber, meskipun, adalah bahwa Anda akan membutuhkan orang-orang yang terampil dalam platform itu dan Anda mungkin akan menyerang orang lain fiefdom. Dimana proses dapat dilakukan dalam memoriJika Anda sudah mendapat memori yang tersedia, belajar bagaimana menggunakannya. Sorts terutama dapat dipercepat dengan melakukan dalam memori. Apa domain pemeriksaan integritas harus dalam database data warehouseTergantung pada bagaimana Anda mengatasi dua masalah di atas, Anda harus menyelidiki sensibilitas menggabungkan integritas referensial atau jenis lain yang memiliki integritas domain memeriksa dalam database Anda. Dimana tidak masuk akal untuk agregat dataKadang-kadang jika Anda melakukan menggabungkan luar lingkungan database data warehouse Anda dapat membuat beberapa file output agregat dalam satu "lulus" dari data masukan. Anda mungkin akan harus belajar bagaimana menggunakan memori sangat hati-hati jika Anda melakukan hal ini (dan memiliki banyak memori pada server di mana Anda melakukan diagregasi). Data statistik yang tersedia di meja penggunaan agregatSeperti Anda mungkin telah membaca nauseum iklan, membangun data warehouse adalah iteratif usaha. Anda mungkin akan membuat agregat yang jarang terbiasa. Anda perlu statistik ini untuk membuat kasus untuk menghapus agregat (meskipun lebih dulu hal ini bisa membuat Anda menjadi aspek politik unik dari manajemen data warehouse.) Apa tingkat data masuk akal untuk agregat dan apa yang non-aditif langkah yang masuk akal untuk memasukkan dalam tabel agregat AndaKatakanlah Anda memiliki wilayah, wilayah, dimensi pelanggan, produk, dan penjual. Anda mungkin menemukan bahwa Anda mendapatkan manfaat paling dengan menciptakan suatu daerah, wilayah, pelanggan, produk, dan agregat penjual dan mengatakan, bahwa, sebuah wilayah tambahan, wilayah, pelanggan, produk agregat menambahkan sedikit untuk kinerja pertanyaan Anda. Faktor yang menyulitkan, meskipun, adalah penggunaan non-aditif tindakan dalam agregat Anda karena mereka akan memaksa Anda untuk kembali agregat. Cukuplah untuk mengatakan bahwa Anda harus berpikir dua kali sebelum menambahkan langkah-langkah untuk agregat Anda. Apa non-FTP cara mentransfer dataFTP-ing bisa lambat. Ada beberapa teknologi kecepatan transfer yang tinggi untuk menyelidiki. Juga, jangan lupa tentang rekaman. Bahkan jika Anda harus mengirimkan rekaman semalam untuk pengiriman awal, tape kadang-kadang cara tercepat untuk mentransfer data. Juga, jangan lupa tentang menggunakan teknologi kompresi dalam hubungannya dengan mentransfer. Apakah Anda secara bertahap harus memperbarui atau membangun kembali tabelKadang-kadang Anda memiliki pilihan untuk secara bertahap memperbarui tabel atau membangun kembali meja. Anda mungkin menemukan bahwa setelah tingkat tertentu dari kegiatan pembaruan yang lebih cepat untuk membangun kembali daripada untuk memperbarui. Sebuah aturan praktis kadang-kadang menyatakan adalah bahwa jika 20% dari catatan akan diperbarui, itu lebih cepat untuk membangun kembali. Ini adalah aturan kasar dan ambang batas yang sebenarnya akan bervariasi. Namun demikian, jika Anda memiliki pilihan, mungkin patut bereksperimen dengan mereka. Apa metode alternatif untuk menangkap perubahan dataMenganggap Anda secara bertahap harus memperbarui database data warehouse Anda dan Anda tidak mengeluarkan dari catatan transaksi tanggal dicap dalam sistem pengumpan, Anda mungkin menemukan Anda memiliki tugas teknis menakutkan dalam menangkap informasi yang berubah. Sadarilah bahwa Anda mungkin memiliki pilihan dalam bagaimana Anda melakukan ini dan pilihan akan berbeda dalam kecepatan. Bagaimana mengubah sistem feeder sehingga perubahan pada catatan ditulis ke file datarMeskipun ini biasanya tidak layak, jika hal ini dilakukan maka dapat menghilangkan waktu yang 13dibutuhkan untuk pergi melalui kadang-kadang waktu proses, memakan berbelit-belit untuk menentukan apa pengumpan data sistem telah berubah. Cara menggunakan software laporan ScrapingJika laporan yang memiliki data yang Anda butuhkan untuk mengekstrak tersedia, kadangkadang masuk akal untuk menempatkan gambar laporan dalam file dan menggunakan perangkat lunak yang dirancang khusus untuk mengekstrak data dari file gambar laporan. Anda menjalankan resiko jika perubahan format laporan. Namun teknik ini sering masuk akal untuk penggalian data sistem yang kode belum tersentuh dalam sepuluh tahun terakhir. Cara melakukan mirroring disk dan backup panasDisk mirroring dan backup panas tidak akan mempercepat loading database data warehouse (pada kenyataannya, jika sebuah disk dicerminkan sementara massal dimuat, waktu loading dapat sangat meningkatkan) tetapi mereka dapat memberikan beberapa fleksibilitas sangat diinginkan dan ruang untuk bernapas. Dengan disk cermin, Anda bisa "memecahkan" cermin, memutahirkan copy, dan mengembalikan cermin dengan copy diperbarui. Ini berarti bahwa Anda masih dapat memiliki gudang data yang tersedia Anda saat memuat itu. (Meskipun berhatihati bahwa Anda memahami bagaimana mirroring dapat ditangani oleh hardware dan software). Demikian pula, backup panas memungkinkan Anda untuk memiliki data warehouse database Anda tersedia ketika dukungan itu. By the way, siklus backup parsial diikuti oleh full backup juga layak melihat ke dalam. Bagaimana menjadwalkan proses pemuatanLoading data warehouse biasanya membutuhkan cukup beberapa proses. Jelas, Anda ingin memahami di mana ada dan tidak dependensi sehingga Anda dapat "multi-task" proses ini sebanyak mungkin. Dimana ada dependensi, Anda ingin melakukan analisis risiko sehingga Anda dapat mengetahui apakah itu sepadan dengan usaha untuk memulai kembali membangun kemampuan dalam proses intermediate. Dan Anda ingin memastikan bahwa Anda memiliki dukungan manusia dan otomatis untuk penjadwalan seperti yang Anda mau. Bagaimana mengatur sebuah pos pemeriksaan restartableSekali lagi, pemeriksaan tidak akan dengan sendirinya mempercepat proses loading. Namun, jika Anda memiliki jendela yang ketat untuk memuat data warehouse dan loading yangmembutuhkan waktu yang cukup, ketersediaan pos pemeriksaan bisa menjadi penyelamat ketika crash beban (yang tidak pada waktu yang terburuk). Tertentu bagaimana bentuk teknologi RAID dapat baik kecepatan dan lambat loadingTeknologi RAID dapat baik membantu dan merugikan kecepatan loading. Partial memperbarui of multidimensional (MOLAP) databaseBanyak dari alat ini memungkinkan Anda untuk menghitung ulang hanya beberapa nomor dihitung disimpan dalam "kubus". Sebagian besar alat-alat yang memiliki kemampuan akan memperingatkan Anda bahwa Anda melakukannya dengan risiko kemungkinan mendapatkan data yang tidak selaras. Bagaimana untuk mendistribusikan data pada disk fisik beberapaJika Anda mampu beberapa disk, Anda mungkin ingin membuat input data yakin, tabel data warehouse, indeks, dan log (jika Anda tidak menonaktifkan logging) berada pada disk fisik yang berbeda. Bahkan, Anda mungkin ingin belajar tentang striping untuk menyebarkan file melalui beberapa disk dan partisi untuk membagi file ke file logis fisik banyak tersebar di disk yang berbeda. Bagaimana untuk defragment file tabel dan indeksIni adalah pengetahuan dasar mungkin akan melakukan Anda baik untuk tahu. Cara membuat salinan database sistem transaksiJika Anda benar-benar ingin menggunakan gudang data Anda hanya untuk pelaporan produksi, Anda mungkin akan lebih baik hanya menyalin database transaksi berkala seperti. Arsitektur puritan membenci solusi ini tapi kadang-kadang hanya masuk akal untuk menangani laporan Anda membutuhkan cara ini. Cara menggunakan kontroler beberapa disk15Anda akan ingin kecepatan tinggi interkoneksi pada kontroler ini. Apa biaya pemasangan lebih CPU / lebih cepat, memori, diskKadang-kadang membeli logam (jauh) cara paling murah untuk mempercepat loading.Beberapa komentar akhir - Dalam waktu jangka pemuatan lama biasanya akan menyebabkan masalah lebih besar dari kali query yang panjang. Hal ini tidak benar-benar jarang bahwa data warehouse tim pengembangan menemukan diri mereka dengan sistem yang mereka telah berjanji untuk memperbarui setiap hari tapi kemudian mereka menemukan waktu update membentang sampai 12,, 14 16, dan mungkin bahkan 20 jam. Anda dapat membuang teknologi yang lebih dan lebih banyak di ini, tetapi pada akhirnya taktik terbaik Anda adalah kemampuan untuk memahami apa yang sebenarnya paling penting bagi bisnis dan manajemen user harapan yang baik. Dan, kecuali itu dilakukan oleh desain, jangan biarkan data warehouse Anda menjadi sumber utama bagi operasional yang berorientasi permintaan dan fungsi melaporkan bahwa, dalam gambaran besar, seharusnya dalam sistem pengumpan pemrosesan transaksi.Bagaimana Simpan Uang di Upaya Warehousing Data Anda Esai ini bukan daftar taktik yang akan digunakan dalam mengembangkan teknologi pilihan Anda. Sebaliknya ini adalah daftar suatu petunjuk yang dapat mendorong pengembang data warehouse untuk berpikir dua kali sebelum membuat mereka manajemen proyek, keputusan desain politik, dan teknis yang kumulatif dampak adalah untuk memaksa sumber daya jauh lebih berkomitmen untuk usaha pergudangan data dari apa yang diharapkan .Pertama, meskipun, perhatikan berapa banyak keleluasaan biasanya ada dalam desain dan implementasi sistem data warehousing sebagai lawan sistem pemrosesan transaksi. Dalam sistem pemrosesan transaksi, data yang akan disimpan dalam sistem, pengguna sistem, tingkat pelayanan yang diberikan kepada pengguna, teknologi yang akan digunakan, dan, dalam banyak kasus, fungsi sistem biasanya tunduk relatif sedikit kebijaksanaan. Dalam upaya pergudangan data, umumnya ada kebijaksanaan yang jauh lebih besar atas faktor-faktor. Namun, karena kurangnya waktu, tekanan politik, atau penerimaan tanpa berpikir industri mainstream, data pengembang pergudangan sering gagal untuk memahami berbagai pilihan yang mereka miliki.Bahwa menjadi kata, saya berharap pointer ini akan memberikan jeda sedikit ....Memiliki alasan selain kemanfaatan untuk membangun sebuah laporan atau query dalam data warehouse yang bertentangan dengan sistem transaksi pengumpan pengolahanAnda mungkin tidak akan jauh ke usaha pergudangan data Anda ketika Anda melihat laporan atau permintaan yang bisa dilakukan dalam sistem data warehousing atau dalam sistem pengumpan pemrosesan transaksi. Dan karena kau pengembang data warehouse Anda mungkin akan memutuskan bahwa laporan atau query lebih mudah untuk dilakukan di gudang data -. Selamat Datang di lereng licin! Anda akan menemukan lebih banyak laporan dan query yang bisa "dua arah". Sebelum Anda menyadarinya, Anda bisa berakhir dengan sistem data warehousing yang berlaku "produksi" Anda laporan dan sistem query generasi dan yang memerlukan tingkat layanan yang sama sebagai sistem transaksi pengumpan pengolahan. Anda bahkan mungkin berakhir melakukan proses transaksi data pergudangan Anda (analis data warehousing beberapa sopan menyebutnya "mekanisme umpan balik") untuk mengirim data dikoreksi kembali ke sistem pemrosesan transaksi. Sekarang, dengan menggunakan data warehouse untuk unbundling tersebut yang query dan pelaporan fungsi dari sistem pemrosesan transaksi dapat menjadi investasi yang baik jika Anda melakukannya dengan desain. Jika unbundling ini dilakukan diam-diam, Anda dapat dengan cepat kembali diri Anda ke dalam mendukung, dengan biaya besar, sistem produksi dua yang menyediakan fungsionalitas duplikat. Menetapkan harapan tentang waktu respon sebelum pengguna menggunakan data warehouseIni "jelas" tidak pernah disebutkan poin cukup: 1) data kinerja pergudangan dapat berfluktuasi jauh lebih banyak daripada kinerja pemrosesan transaksi sistem (misalnya, untuk beberapa alasan setiap pengguna akan ingin melakukan analisis tren tahun lima pada waktu yang sama) 2) Tidak semua orang mulai menggunakan data warehouse pada tingkat yang sama. Sebagai pengguna mulai menggunakan sistem, kinerja rata-rata cenderung menurun 3) Jika data warehouse anda sedang digunakan untuk pekerjaan akhir ad hoc pengguna, Anda kemungkinan besar tidak akan bisa "tune" sistem data warehouse Anda untuk semuanya pengguna Anda akan melemparkan di itu. - Anda terbaik mendiskusikan masalah kinerja dengan pengguna Anda di awal penyelidikan gudang data Anda. Pun mereka mungkin berharap waktu respon untuk menjadi sama seperti memindahkan sel dalam lembar kerja Excel. Jika Anda tidak membahas masalah kinerja yang diharapkan dengan pengguna Anda, Anda menetapkan diri untuk mahal (dan mungkin abadi) ulang desain Anda ketika kinerja data warehouse tidak memenuhi harapan awal dari pengguna. Melakukan pekerjaan untuk menentukan ekonomi tingkat layanan yang berbedaDapatkan apresiasi berapa banyak kenaikan pada biaya gudang tingkat layanan data. Jenis 17analisis adalah "seni" tapi sebuah seni yang database Anda / hardware vendor / konsultan (dengan mempertanyakan setiap asumsi yang mereka buat) harus dapat membantu Anda dengan. By the way, pengetahuan yang penting adalah bagaimana membuat penyesuaian dengan himpunan teknologi akan mengubah kinerja biaya dan diharapkan. Jadilah skeptis tentang membandingkan jenis analisis ini antara set yang berbeda dari teknologi. Lakukan analisis apakah platform organisasi Anda telah menggunakan untuk waktu yang lama sesuai untuk usaha pergudangan data AndaMainframe, midrange proprietary, dan sistem file jaringan operasi server adalah platform yang sah untuk data warehousing. Sebelum data pergudangan disebut data pergudangan, platform ini sedang digunakan cukup berhasil untuk sistem data warehousing. Bahkan, meskipun Anda tidak akan membacanya di media perdagangan, platform ini masih sedang digunakan dengan sukses untuk data warehousing. Platform tidak selalu tepat, tetapi jika Anda memiliki investasi yang besar dalam platform ini dan "penjaga" dari platform tersebut tidak terlalu tahan, adalah berguna untuk melakukan analisis. Lakukan analisis apakah pengguna Anda secara langsung harus melaporkan / query terhadap data yang tersimpan dalam sistem pemrosesan transaksiPada 1970-an, kebijaksanaan industri mainstream adalah bahwa data harus diekstrak dan dilaporkan melawan. Pada 1980-an kebijaksanaan utama melakukan "180" dan mengatakan bahwa "data tidak akan digandakan" dan bahwa Anda harus pergi melawan hal yang nyata. Pada 1990-an, kebijaksanaan utama yang dilakukan yang lain "180". - Pelaporan terhadap data sistem pemrosesan transaksi tidak selalu tepat, tapi kecuali Anda secara otomatis ingin menerima kebijaksanaan utama yang sepertinya tidak pernah mempertimbangkan varietas wajah situasi orang, Anda mungkin menemukan melakukan analisis berharga. (Dan kemudian di tahun 2000an Anda akan dipertimbangkan dalam avant garde dan Anda akan menjadi sumber kebijaksanaan utama.) Tawar-menawar dengan database dan vendor hardwareKemungkinan Anda akan membeli database Anda dan perangkat keras Anda dari beberapa, vendor terkenal historis menguntungkan. Jika Anda melakukan pekerjaan rumah Anda, Anda akan menemukan bahan tertulis (tidak secara khusus tentang data warehousing meskipun) dan konsultan yang tersedia untuk memberitahu Anda bagaimana untuk menangani dengan vendor tertentu.Jika Anda akan memiliki sejumlah besar pengguna yang hanya menjalankan laporan kaleng, mempertimbangkan alternatif untuk menyediakan para pengguna dengan laporan "penuh sesak nafas" berbasis klien dan permintaan, OLAP alatDalam data warehouse yang khas, sebagian besar pengguna ketat akan menjalankan laporan kaleng. (Perkiraan bahwa 75% -. 98% dari pengguna data warehouse secara ketat melaporkan pengguna telah muncul dalam pers perdagangan) Sejumlah besar uang yang dapat dihabiskan lisensi dan mendukung fungsi bahwa pengguna akan jarang digunakan. Alternatif untuk menyediakan pengguna laporan kaleng dengan alat penuh sesak nafas bervariasi berdasarkan pada teknologi yang Anda gunakan dan politik situasi. Tetapi alternatif biasanya ada jika Anda melihat. Menerapkan teknik query meningkatkan efisiensi desain yang tidak memerlukan perangkat keras atau perangkat lunak khususKhusus belajar tentang menggunakan tabel agregat dan partisi. Teknik ini dapat digunakan dengan semua jenis metode akses database atau file. Meskipun teknik ini dapat digunakan secara berlebihan, mereka umumnya adalah cara paling sederhana mahal, paling efektif, dan paling tidak untuk mempercepat pengambilan informasi. Merinci data mungkin membersihkan tugas dan, dengan pengguna data warehouse, menguji apakah masing-masing tugas jurusan yang layak usahaAnda mungkin akan datang dengan daftar panjang masalah data banyak yang tidak sebanding dengan upaya untuk membersihkan. Perhatikan bahwa "layak" adalah penilaian bahwa pengembang data warehouse dan pengguna harus setuju atas. Berpikir dua kali sebelum membangun sarana untuk melakukan perhitungan yang kompleks bahwa pengguna bisnis sedikit mengertiIni bukan yang lazim untuk satu pengguna bisnis untuk memutuskan bahwa dia membutuhkan data warehouse untuk menyimpan atau melaporkan satu set nomor yang sangat sulit untuk menentukan dan yang lebih penting, bahwa pengguna bisnis yang paling memiliki waktu yang sulit memahami. Dalam hal ini, pengembang data warehouse harus diplomatis mendiskusikan apakah perlu menghitung satu set angka yang pengguna bisnis mungkin hanya akan mengerti. Kadang-kadang, sering kali itu tidak. 19Jika alasan utama Anda sedang mempertimbangkan data warehousing adalah untuk berkeliling kesulitan yang disebabkan oleh sistem pemrosesan transaksi disfungsional, melakukan pekerjaan biaya berapa banyak itu akan memperbaiki sistem pemrosesan transaksi sebelum Anda membuat keputusan data warehouseIni mungkin tidak mengejutkan bahwa motivasi utama untuk pembangunan gudang data yang banyak adalah untuk berkeliling kesulitan yang disebabkan oleh sistem pemrosesan transaksi bermasalah. Segera memutus data warehouse sebagai "memperbaiki" bisa menjadi kesalahan mahal. Jika Anda tidak melakukan pekerjaan biaya berapa banyak biaya untuk memperbaiki sistem pemrosesan transaksi, Anda mungkin tidak pernah memahami apa yang sebenarnya menyebabkan masalah. Dan kemudian Anda menetapkan diri untuk situasi di mana masalah yang sama terulang di gudang data dan Anda akhirnya mendukung kedua sistem pengolahan transaksi disfungsional dan gudang data disfungsional. Jika sebagian besar kebutuhan bisnis Anda adalah untuk melaporkan data dalam satu sistem pemrosesan transaksi dan / atau semua data historis yang Anda butuhkan berada dalam sistem itu dan / atau data dalam sistem yang bersih dan / atau perangkat keras Anda dapat mendukung pelaporan terhadap hidup sistem data dan / atau struktur data sistem relatif sederhana dan / atau perusahaan Anda tidak memiliki banyak minat pengguna akhir ad hoc permintaan / laporan alat, Anda mungkin tidak MEMBUTUHKAN data warehouseKadang-kadang generator laporan yang baik akan baik-baik saja. Pertanyaan apakah Anda benar-benar akan mendapatkan keuntungan dari kategori tertentu alatUntuk beberapa implementasi data warehouse, beberapa jenis alat hanya tidak masuk akal bisnis yang baik. Misalnya, jika Anda tidak memiliki kebutuhan untuk slice-dan-dadu atau kemampuan pemodelan alat OLAP, laporan, dan alat query dapat memenuhi kebutuhan pelaporan Anda lebih dari cukup. Jika Anda harus melakukan cukup rumit transformasi data dan / atau Anda memiliki sumber data yang relatif sedikit dan target, Anda mungkin akan lebih baik coding dengan tangan daripada menggunakan apa yang disebut "data mart" alat. Database yang Anda gunakan untuk proses transaksi dapat melakukan dengan baik berdasarkan jumlah pengguna, jumlah data, dan waktu Anda harus memuat database. Sebelum membeli data alat pertambangan melakukan yang terbaik untuk menilai apakah mereka akan menghasilkan "ditindaklanjuti" wawasan sepadan dengan usaha dalam membuat pekerjaan data mining tool. Terimalah bahwa data pergudangan akan menjadi berantakan teknisJika ada orang yang pernah menulis "The Zen Of Data Warehousing" (binasa pikiran - silahkan), salah satu konsep mungkin akan bahwa di beberapa titik, yang lebih teknis elegan Anda mencoba untuk membuat sistem ini, berantakan (dan lebih mahal dan kurang menguntungkan) mereka berakhir menjadi. Tidak ada aturan untuk menentukan di mana titik ini. Gunakan pertimbangan Anda dan intuisi untuk membuat tekad.Menggunakan Data Warehousing Dalam, Pembuatan Keputusan Strategis Meskipun Andari dapat membaca banyak definisi bahasa Dari gudang Data Yang mengatakan bahwa SISTEM inisial dirancang untuk "pengambil keputusan Strategis" (atau beberapa istilah Lain Yang serupa) ADA: sedikit menulis tentang BENAR-BENAR menggunakan gudang data yang Illustrasi proses penelaahan pengambilan keputusan Strategis. Illustrasi esai inisial, Saya Ingin menawarkan beberapa Wawasan Ke Dalam, menggunakan gudang data yang Illustrasi keputusan nihil membuat latihan.PERTAMA, biarkan SAYA menentukan pengambilan keputusan Strategis. Mungkin ADA ribuan definisi diterbitkan. Untuk tujuan bekerja SAYA katakan bahwa keputusan Strategis adalah salat Satu Yang melibatkan menghabiskan banyak tagihan dan sampai / atau menembakkan / re-menugaskan / mempekerjakan banyak orangutan sampai / atau Yang Akan menyebabkan banyak rasa Sakit / sukacita sampai berikutnya keputusan Strategis dibuat. (Tentu Saja "banyak" adalah istilah relatif yang.)SAYA menegaskan bahwa sebagian Besar penggunaan gudang data yang tidak untuk pengambilan keputusan Strategis. Mungkin alasan Yang memucat penting untuk inisial adalah bahwa pengambilan keputusan Strategis biasanya tidak dilakukan Yang sering. Sebaliknya, Saya Percaya bahwa gudang Data Yang memucat digunakan terutama untuk memantau keputusan pasca Efek keputusan. Namun demikian, beberapa data warehouse Bisa digunakan Dalam, pengambilan keputusan Strategis Dan digunakan Ulasan Sangat menguntungkan.Apa Berikut adalah beberapa pengamatan mengenai bagaimana Pribadi Andari BENAR-BENAR dapat menggunakan data warehouse Dalam, pengambilan keputusan Strategis latihan. Menciptakan "KHUSUS" database, pemodelan (Bukan Dalam, arti kata IS), dan jumlah Pelaporan resmi adalah Tugas Yang memucat memakan waktu ketika menggunakan gudang data yang Illustrasi pengambilan keputusan Strategis 21Kemudian SAYA Akan pergi Ke detil lebih ACLS mengenai TOPIK inisial. Penggunakan Sistem pengambilan keputusan Strategis cenderung relatif yang pendek-HidupJUMLAH waktu Yang dihabiskan menggunakan inisial SISTEM kadang-kadang dapat diukur Illustrasi Hari dihitung Artikel Baru Satu Tangan. Mereka beberapa Hari menggunakan SISTEM, meskipun, Bisa membawa lebih REVENUES bahasa Dari beberapa SISTEM Pelaporan kaleng Yang digunakan selama bertahun-years. Biasanya pekerjaan harus dilakukan Artikel Baru CEPAT Dan diminta Artikel Baru PEMBERITAHUAN: sedikit SIGNIFIKANPekerjaan Suami biasanya harus dilakukan Dalam, APA pun bahasa Dari sakit Panjang untuk beberapa Minggu. Suami adalah "mencari tahu sebagai Andari pergi Bersama pekerjaan" di mana IS sering harus mengambil bagian bahasa Dari Analis bisnisdan. Biasanya tidak ADA waktu untuk wawancara resmi diperpanjang Dan data latihan modeling. The "persyaratan" biasanya diperoleh bahasa Dari pertemuan "bisnisdan" Yang IS mungkin harus berjuang untuk masuk: sedikit Ke atau terkait bekas bahasa Dari peserta pertemuan inisial. Persyaratan inisial biasanya Ambigu. IS biasanya harus memakai topi bisnisdan Dan MENCARI Tahu Apa Yang sebenarnya dibutuhkan oleh bisnisdan. Andari mungkin harus Data agregat berbeda, menggunakan perhitungan Yang berbeda untuk Nomor diturunkan, Dan menggabungkan Data Yang tidak pernah sebelumnya telah digabungkanPekerjaan Yang Andari lakukan memungkinkan bisnisdan untuk melihat sudut Pandang Yang tidak pandangan UMUM bahasa Dari bisnisdan. (Baru kata Lain, bagian bahasa Dari keputusan Strategis Yang efektif membuat latihan adalah untuk melihat bisnisdan Illustrasi Perspektif Yang berbeda.) Andari melakukan pekerjaan inisial karena ketika Andari membangun data warehouse, Andari Artikel Baru dibangun Sesuai Apa Yang kemudian pandangan UMUM bisnisdan. Andari mungkin Perlu membuat basis data KHUSUSSeringkali Andari Perlu menjalankan pertanyaan berulang-Ulang terhadap bagian bahasa Dari data warehouse. Subset mungkin salat Satu Yang diciptakan oleh permintaan Ekstrak Artikel Baru kendala Yang cukup rumit. Atau, seperti Yang SAYA sebutkan, Andari mungkin Perluberulang Kali mengakses agregat Baru Dan perhitungan atau Andari mungkin harus AKSes data yang berulang Kali secara bersamaan Yang tidak Illustrasi gudang Data Produksi atau Yang berada Illustrasi Database Produksi tetapi tidak mudah digabungkan. Demi kesederhanaan Dan efisiensi, tentu Saja Andari terbaik adalah untuk membuat KHUSUS database. Andari mungkin berpikir Andari membuat data warehouse sehingga Andari tidak Akan harus membangun KHUSUS "Ekstrak" TAPI, mungkin untuk tidak mengejutkan, seringkali ADA ADA Saja Cara untuk menghindari Ekstrak. (Untuk lebih ACLS tentang ide BACAKAN mirip tentang Database KHUSUS, lihat Diskusi Ralph Kimball tentang "Metode studi therapy terapi".) Andari mungkin harus "memberi Makan" Data Ke pengguna mempertahankan model spreadsheetSebagian Besar penggunaan data warehousing untuk pengambilan keputusan Strategis PADA akhirnya melibatkan "Makan" pengguna dipertahankan spreadsheet. Suami "umpan" Yang BAIK Link Ke Data Yang tersimpan di gudang data yang sebenarnya atau pemuatan Data Ke spreadsheet. Spreadsheet digunakan karena pengguna Perlu mengubah perhitungan Yang rumit mungkin sebagai bagian bahasa Dari analisis secara skenario tetapi biasanya karena ADA keraguan Terus-menerus tentang bagaimana perhitungan tertentu harus dilakukan - Dan pengguna Yang memucat berpengetahuan tentang melakukan perubahan di Customers spreadsheet. (Untuk menempatkan inisial Illustrasi istilah: sedikit lebih Teknis, banyak bahasa Dari perhitungan antar-PT BUMI, perhitungan pada dimensi Lintas). Banyak Alat OLAP memungkinkan banyak fleksibilitas Dalam, membuat perhitungan, tetapi kemampuan inisial cenderung terlalu Sulit BAGI pengguna Yang terburu-Buru Dalam, pengambilan keputusan Strategis latihan. Perhatikan JUGA bahwa seringkali Perlu, PADA gilirannya, memberi Makan data spreadsheet Ke Dalam, Database KHUSUS Yang telah Andari buat. Kadang-kadang Data kebersihan JAUH lebih: sedikit perhatian Illustrasi pengambilan keputusan StrategisKadang-kadang analisis secara Yang dilakukan Artikel Baru Data Yang Ulasan Sangat diringkas sampai / atau kebutuhan untuk kecepatan * Mengurangi kebutuhan Data Yang Ulasan Sangat bersih desa. SAYA sarankan, bagaimanapun, bahwa APA pun Harapan Data, Andari Tetap Jejak Audit Yang memungkinkan Andari melacak bagaimana Data Yang berasal bahasa Dari SISTEM pengumpan. Andari mungkin harus membuat beberapa DAFTAR ISI CONTENTS Yang Ulasan Sangat diformat23INFORMASI Bahasa Dari data warehouse harus dikomunikasikan kepada orangutan-orangutan Yang tidak memiliki sampai / atau Ingin AKSes Langsung Ke data warehouse. Illustrasi pengambilan keputusan Strategis latihan, meskipun terburu-Buru, Andari mungkin Ingin pengguna untuk mengkomunikasikan INFORMASI Illustrasi DAFTAR ISI CONTENTS tercetak Yang terlihat hanya "jadi". DAFTAR ISI CONTENTS DAFTAR ISI CONTENTSinisial biasanya diciptakan untuk membujuk seseorang. Banyak pengguna Bahasa Dari Andari Akan Ingin melihat dipol untuk DAFTAR ISI CONTENTS Illustrasi rangka untuk menyampaikan kredibilitas. JUGA, Grafik biasanya dibuat untuk latihan. By the way, biasanya ADA beberapa memberi Dan menerima, apakah DAFTAR ISI CONTENTS DAFTAR ISI CONTENTS-Dan Grafik harus dibuat secara manual (yaitu, Artikel Baru pengolah kata, Alat Presentasi, spreadsheet) atau dihasilkan secara Langsung Bahasa Dari database.Sekarang beberapa Saran: Mungkin penentu memucat penting bahasa Dari MANFAAT Yang Akan Andari dapatkan bahasa Dari Teknologi adalah kemampuan untuk mengetahui pertanyaan Andari Yang memucat Mendalam bahwa Teknologi memungkinkan Andari untuk bertanyaJangan berasumsi bahwa pengguna memiliki apresiasi Penuh bahasa Dari kekuatan Teknologi. Kecuali Andari memiliki beberapa pengguna Artikel Baru insting Yang BAIK tentang Teknologi, IS harus mengambil bagian bahasa Dari Analis bisnisdan untuk memacu imajinasi pengguna. Cobalah untuk mendapatkan di "Lingkaran" MutasiPengguna Akan cenderung BAIK terlalu meremehkan atau melebih-lebihkan kekuatan gudang Data Dalam, pengambilan keputusan Strategis latihan. Suami berarti bahwa BAIK IS dapat melewatkan kesempatan atau dihadapkan Artikel Baru Tugas Yang mustahil Yang harus dilakukan Artikel Baru CEPAT. Perhatikan bahwa biasanya ADA Politik Dalam, Dalam, mendapatkan Lingkaran Mutasi. Namun, Penghasilan kena pajak sebelumnya membangun hubungan saling Percaya Artikel Baru "pengambil keputusan" Ulasan Sangat membantu. Ketika Andari awalnya merancang gudang, jangan mencoba untuk merancang untuk setiap kontingensi Yang dapat terjadi Dalam, pengambilan keputusan Strategis latihanAndari tidak dapat meramalkan Akan Apa Yang Akan dibutuhkan Illustrasi latihan. Jangan meletakkan Segala sesuatu mungkin Andari Bisa memikirkan Dalam, data warehouse. Jangan,meskipun, cobalah untuk menyimpan data yang atom Illustrasi beberapa Format Elektronik dpt. Lakukan Yang terbaik untuk menyesuaikan pada dimensi Kedudukan Bahasa Dari Data Yang digunakan Dalam, bisnisdan Andari. (Itu berarti pelanggan, Produk, finansial, Dan internal "entitas", yaitu, orangutan-orangutan Dan menurut Departemen, identifikasi.) Do mengatasi masalah pada dimensi pelan-pelan berubah. Dan jangan membuat Diri Andari sepenuhnya Tergantung PADA Sumber Daya Luar Yang ketersediaan Andari tidak Bisa mengontrol. Latihan-latihan inisial Datang Tiba-Tiba. Jangan biarkan pengetahuan tentang SISTEM tinggal di benak para Konsultan Teknis LuarInisial bagian usang Dan jelas nasihat Perlu diulang. Para Konsultan Teknis telah pergi Dan tidak tersedia ketika Peluang Muncul. Acute pengetahuan Kunci bahasa Dari SISTEM Andari berada di Kepala Konsultan, Andari mungkin Bisa sampai debit sungai ketika latihan Muncul inisial. Pelajari spreadsheet Dan bagaimana data warehouse Andari dapat berinteraksi Artikel Baru merekaKami di Dunia data warehouse sering Lupa bahwa spreadsheet adalah JAUH Alat pendukung keputusan Yang memucat sering digunakan. Orang Yang mendukung gudang data yang BENAR-BENAR Yang Akan digunakan untuk mendukung keputusan harus didorong untuk Belajar bahasa scripting bahasa Dari spreadsheet (Yang BAGI kebanyakan orangutan adalah Visual Basic for Applications) sehingga mereka memiliki fleksibilitas Illustrasi Datang Artikel Baru Solusi Dalam, pengambilan keputusan Strategis latihan. Jangan "Produksi-ize" pekerjaan AndariPekerjaan Teknis dilakukan Dalam, latihan-latihan inisial biasanya tidak "kekuatan industri" Dan ITU mungkin tidak sebanding Artikel Baru Company 's name untuk membuatnya begitu. Andari dapat Belajar, meskipun, bahwa Andari Perlu memodifikasi Produksi Andari database data warehouse. JUGA, lakukan pekerjaan Andari Terus di sekitar sehingga Andari dapat mencopoti Kode untuk membuat keputusan Strategis berikutnya latihan. Jangan mengklaim bahwa data yang Pergudangan Sendiri tentu Akan meningkatkan pengambilan keputusan StrategisPerlu sering diulang bahwa Acute seseorang adalah pembuat keputusan Yang Biasa-Biasa Saja, Teknologi Saja tidak Akan membuat orangutan ITU pembuat keputusan Yang lebih BAIK 25terutama di Kepemilikan Modal pengambilan keputusan Strategis di mana, meskipun Kami 100 TB database, JAUH lebih Masih Proforma diketahui Bahasa Dari dikenal . Jangan lewatkan kesempatan SuamiSulit untuk Menghitung ROI Yang diharapkan bahasa Dari sebuah Proyek data warehouse. Kebanyakan bisnisdan harus pergi PADA iman bahwa upaya entah bagaimana Akan sia-sia. Nah, keberhasilan (atau, kadang-kadang, hanya Usage) Illustrasi pengambilan keputusan Strategis latihan, meskipun kekacauan bahasa Dari pekerjaan, Ulasan Sangat Bisa memperkuat keyakinan bahwa data warehouse adalah Sepadan Artikel Baru kas. Acute Andari tidak membenarkan data warehouse sebelum membangun ITU, ITU pintar, mungkin penting, untuk membenarkan data warehouse Penghasilan kena pajak Fakta. Dan Cara terbaik Andari Akan melakukan inisial adalah "anekdot" Artikel Baru Cerita perang Yang sukses di tingkat pengambilan keputusan seperti Strategis latihan.Pemeliharaan Masalah untuk Sistem Data Warehousing Aspek penting lainnya dari data warehousing dan sistem pendukung keputusan (selanjutnya disebut sebagai DW / DSS sistem dan saya tahu itu adalah berlebihan) di mana saya melihat sedikit diskusi publik adalah pemeliharaan sistem ini. Di sini saya menyajikan beberapa masalah yang mungkin Anda hadapi ketika sistem Anda "dalam produksi", seolah-olah sistem ini pernah mencapai stabilitas tersirat dengan istilah itu. Bagaimana Anda akan menangani isu-isu akan tergantung pada lingkungan Anda. Daftar ini disajikan karena, seperti disebutkan dalam halaman gotchas saya, dulu adalah forearmed!Anda akan ditantang untuk belajar tentang bisnis dan perubahan sistem feeder yang akan mempengaruhi DW / DSS sistem Anda sebagai pengembang sistem ingin tahu perkembangan yang akan mempengaruhi DW / DSS sistem waktu untuk memungkinkan waktu yang cukup untuk menilai apa yang terkena dampak , membuat perubahan, perubahan pengujian, dll Tentu saja ini ada kekhawatiran baru untuk siapa pun melakukan pemeliharaan sistem. Jika Anda bertanggung jawab untuk sistem diberi makan dari, katakanlah, 10 sumber, Anda mungkin memiliki eksposur lebih dari yang Anda miliki dengan sistem pemrosesan transaksi yang khas. Dan meskipun penggunaan cerdas dari ekstraksi data, alat pembersih, dan loading dan katalog informasi dapat sangat meringankan beban di sini, banyak perubahan akan memerlukan cukup banyak usaha. By the way, menjaga informasi dan menilai dampak perubahan teknis didorong ke sistem feeder mungkin lebih sulit daripada melacak perubahan bisnis didorong. Jika IS organisasi Anda memiliki pertemuan perubahan kendali, itu adalah kesalahan besar untukpengembang DW / DSS untuk tidak menghadiri pertemuan-pertemuan rutin. Anda harus mencari tahu apakah, kapan, dan bagaimana untuk membersihkan data yangAda datang satu titik ketika tidak masuk akal bisnis untuk menyimpan data tertentu dalam sistem pergudangan. Hal ini biasanya datang lebih cepat dari yang Anda harapkan. Entah Anda berada di beberapa jenis batas kapasitas atau lebih mungkin, Anda restrukturisasi data dan tidak layak upaya untuk merestrukturisasi data tertentu. Ketika Anda berada pada titik ini Anda mungkin menyadari bahwa sistem DW / DSS telah menjadi tempat berkembang biak bagi tikus paket informasi perusahaan ("Mengapa hanya minggu lalu meminta analisis akan kembali tahun 1956! ______"). Sebelum Anda masuk ke sebuah diskusi tentang membersihkan data, salah satu bagian dari nasihat adalah untuk belajar tentang lebih murah, cara alternatif penyimpanan. Anda harus menentukan query dan laporan harus IS tertulis dan yang harus user ditulisMungkin ketika Anda bisa mulai masuk ke daerah ini Anda punya ide tentang siapa yang akan melakukan apa. Dan jika Anda seperti kebanyakan DW / DSS pengembang, setelah Anda telah di produksi sementara Anda telah melihat bagaimana realitas telah berbeda dari harapan Anda. Sebuah sangat umum IS harapan adalah bahwa pengguna akhir akan mengambil alih mayoritas penulisan tugas permintaan dan laporan. Dan realitas terlalu umum adalah bahwa IS berakhir mengambil alih hampir seluruh penulisan query dan laporan atau IS menulis beberapa semikaleng query dan potensi sistem untuk menjawab pertanyaan ad hoc tidak pernah akan sepenuhnya direalisasikan. - Anda mungkin memiliki tantangan di dua front. Anda mungkin harus mendorong pengguna akhir menjadi "air dalam". Anda juga mungkin harus meyakinkan Anda IS staf bahwa laporan dan alat query bangunan tidak "mainan". Anda akan termotivasi untuk menyimpan data dalam data warehouse "demi data itu"Anda dan / atau pengguna sistem akan melihat "lubang" dalam data yang Anda simpan di gudang data. Terutama demi kelengkapan, Anda akan tergoda untuk menambahkan data ini. Sayangnya, bila Anda telah menyerah kepada godaan ini beberapa kali, Anda akan menemukan Anda telah meledak ukuran dan kompleksitas data warehouse Anda tanpa pertimbangan yang tepat apakah ukuran dan kompleksitas tambahan memiliki nilai bisnis. Anda akan menemukan peluang tak terbatas untuk menyempurnakan DW / DSS database sistemSaya pernah melihat sebuah kutipan dari direktur IS dari bisnis ritel terkenal yang mengatakan 27bahwa data pergudangan terbesar pelajaran yang ia pelajari adalah "tidak ada ahli pergudangan banyak data di luar sana." Jika Anda sedang mengizinkan tingkat wajar pengguna akhir mengembangkan akses ke sistem dan sistem Anda yang besar dan kompleks, Anda akan menemukan bahwa ada berbagai cara untuk menyeret sistem ke merangkak. Hal ini tidak mungkin dari sebuah "ahli" bisa meramalkan semua masalah. Dan banyak masalah begitu gila bahwa mereka hanya cara Anda akan menyelesaikannya adalah atas dasar trial-and-error. Omong-omong, Anda mungkin telah menjual konsep DW sebagai cara yang "query pembunuh" tidak akan tarik ke bawah "produksi" Anda sistem. Sekarang bahwa Anda telah dimasukkan ke dalam sistem data warehouse, Anda akan menemukan bahwa pengguna hanya sebagai tergantung pada sistem data warehousing untuk kebutuhan berulang karena mereka pada apa yang disebut sistem produksi dan permintaan pembunuh terluka dimanapun terjadi. Anda akan harus menyeimbangkan kebutuhan untuk membangun struktur agregat untuk memproses efisiensi dengan keinginan untuk tidak membangun sebuah mimpi buruk pemeliharaanBanyak DW / DSS sistem melibatkan struktur bangunan mengandung informasi yang dikumpulkan. Ini "struktur" dapat banyak hal - tabel terpisah dalam sistem relasional, dimensi di dunia OLAP, dll Pokoknya, setelah beberapa saat Anda akan melihat berbagai cara untuk menambah atau memperbaiki struktur agregat biasanya dalam nama mengurangi waktu akhir pengguna pengambilan . Masalah yang Anda hadapi adalah menyeimbangkan keinginan Anda untuk mempercepat dengan kebutuhan untuk berhati-hati dengan berapa banyak beban pemeliharaan Anda ingin mengambil. Ada dua aspek dari beban ini. Pertama, Anda harus mempertimbangkan waktu pengembang. Kedua, Anda harus mempertimbangkan jumlah waktu yang diperlukan untuk memperbarui sistem Anda secara berulang. Anda akan yakin apakah untuk membuat laporan tertentu / query dalam sistem data warehousing atau dalam sistem transaksi "feeder" pengolahanAnda terbaik disarankan untuk memiliki beberapa pedoman mengenai apa yang terjadi di mana. Jika tidak, Anda mungkin akhirnya menemukan bahwa Anda memiliki hampir tiruan dari sistem pemrosesan transaksi Anda dalam sistem pergudangan data Anda. Anda akan ditekan untuk menerapkan sarana untuk interaktif memperbaiki data dalam gudang data (dan mungkin mengirim kembali koreksi ke sistem pemrosesan transaksi)Dan Anda meskipun data warehouse Anda adalah read-only! Saya tidak mengatakan ini adalah selalu buruk. Meskipun, seperti dalam poin terakhir, Anda harus berhati-hati Anda tidakmenetapkan diri untuk membangun klon dari sistem pemrosesan transaksi disfungsional. Anda akan pasti yang alat yang paling tepat untuk tugas tertentuDW / DSS sistem IS hadir dengan lain set alat dengan menggunakan tumpang tindih. Anda akan menemukan bahwa tidak jelas apa yang adalah alat yang terbaik untuk banyak aplikasi. Misalnya, jika Anda telah berinvestasi dalam teknologi database relasional dan multidimensi, Anda akan menemukan bahwa untuk banyak aplikasi, pada tingkat teknis, itu adalah melemparkan-up untuk yang teknologi database akan melakukan pekerjaan yang lebih baik. Banyak organisasi juga memiliki alat berat dan alat yang lebih ringan yang memiliki tujuan yang sama. Anda akan menemukan banyak situasi di mana tidak jelas apakah akan pergi tugas berat atau ringan. Anda harus mencari cara untuk menguji pengaruh perubahan struktur pada permintaan pengguna akhir tertulis dan laporanSetelah beberapa saat Anda akan membuat beberapa perubahan struktur database yang dapat mempengaruhi laporan dan query yang pengguna akhir Anda telah menulis. Agar kebutuhan untuk kembali menguji pekerjaan mereka tidak datang sebagai kejutan terlalu buruk kepada pengguna akhir Anda, mungkin saya menyarankan agar Anda membuat mereka menjadi kebiasaan rumah tangga yang baik sejak dini. Ini berarti, misalnya, tidak menjaga pekerjaan mereka dalam 10 direktori yang berbeda dan menyimpan deskripsi pekerjaan mereka. Anda harus menentukan bagaimana masalah dengan pengumpan sistem update pengolahan mempengaruhi DW / DSS sistem update pengolahanSekali lagi, jika Anda memiliki 10 sistem data warehouse Anda makan, Anda akan harus mengembangkan apresiasi apa yang harus dilakukan ketika ada masalah pengolahan dengan satu atau beberapa sistem-sistem pengumpan. Pada tingkat yang paling sederhana, ini berarti menentukan jika dan ketika Anda akan memproses pembaruan sistem data warehousing. Pada tingkat yang lebih sulit, ini berarti menentukan apakah dan bagaimana proses pembaruan parsial ke sistem pergudangan. Para dependensi di DW / DSS pengolahan update dapat mendapatkan cukup kompleks. Mengambil waktu untuk memahami dependensi terutama jika Anda tidak memiliki sistem pengumpan yang paling berperilaku baik. Anda akan menemukan bahwa mempertahankan arsitektur data warehouse mungkin jauh lebih sulit daripada membangun arsitektur29Dengan arsitektur, saya lihat konsistensi penggunaan dimensi, definisi dari data yang diperoleh, nama atribut, dan sumber data untuk informasi spesifik. Kecuali ada seseorang yang bertanggung jawab untuk menjaga matanya pada pembangunan gudang data berikutnya, mudah untuk cepat kehilangan manfaat dari kerja keras biasanya diperlukan untuk membangun arsitektur. By the way, orang yang menjaga matanya pada perkembangan ini harus: 1) Memiliki penilaian beberapa - harapan Anda tentang apa yang harus tetap konsisten akan berubah dari waktu ke waktu 2) Mampu bekerja secara persuasif, bukan dengan cara koersif - data warehouse pengembang terutama membenci "arsitektur polisi." Anda akan menemukan bahwa bisnis perubahan makna atribut dari waktu ke waktu dan bahwa perubahan ini dapat diabaikanMisalnya, katakan bahwa Anda bekerja untuk sebuah perusahaan distribusi buah. Mungkin ia memiliki suatu kebijakan untuk menggunakan kategori kode "100" untuk penjualan apel dan jeruk. Jika perusahaan tiba-tiba mulai menggunakan kode "150" untuk jeruk, meskipun dimensi meja Anda perubahan mekanisme menangkap dapat menangani perubahan (saya harap Anda tahu tentang pelan-pelan berubah dimensi), ada sekarang adalah pertanyaan tentang bagaimana, baik, apel dengan apel dan jeruk untuk perbandingan jeruk harus dibuat untuk tujuan sejarah. Seringkali tidak ada "benar" cara untuk menangani isu-isu yang muncul dalam membandingkan sejarah. Anda, meskipun, harus melakukan yang terbaik Anda sehingga Anda tahu ada masalah. Anda harus ulang bagaimana Anda telah menerapkan keamananSebagian besar perusahaan, jika data mereka sistem pergudangan yang digunakan untuk pelaporan ad hoc, akan menemukan skema keamanan mereka terlalu longgar atau terlalu ketat. Anda akan menemukan bahwa menugaskan keamanan adalah tindakan penyeimbangan. Anda ingin meminimalkan pelanggaran keamanan, tetapi di sisi lain Anda tidak ingin meminimalkan kemungkinan pengguna menemukan beberapa wawasan bisnis yang berguna sebagai akibat dari nya memeriksa sesuatu yang orang lain mungkin berpikir berada di luar ruang lingkup masalah sehari-hari. Anda akan harus terus mendamaikan sistem feeder dengan DW / DSS sistemSetelah hal-hal yang berjalan lancar untuk sementara waktu, beberapa kali ada kecenderungan untuk menjadi kendur dalam proses apa pun yang Anda telah menerapkan sistem untuk mendamaikan. Juga, jika Anda memiliki pengguna akhir mendamaikan informasi, Anda mungkin menemukan bahwa itu adalah diskusi yang sedang berlangsung tentang bagaimana untuk menangani tanggung jawab untuk rekonsiliasi rutin.Anda akan harus melakukan euthanasia pada beberapa DW / DSS sistemDW / DSS sistem cenderung sering diganti. Mereka mengalami entropi jauh lebih cepat daripada, katakanlah, sistem buku besar. Jika perusahaan Anda digunakan untuk menjaga dan menambal sistem selama Anda tetap kulkas (dan hari ini ada perusahaan seperti itu mencelupkan kaki mereka di DW / DSS untuk pertama kalinya), Anda mungkin berada dalam untuk kejutan. Anda akan merasa jauh lebih mahal (dan kompleks) untuk mempertahankan data warehouse daripada membangun satu.Apa Business Intelligence Tools yang Digunakan untuk Pada bagian pada "rahasia kecil yang kotor dari data warehousing" dalam buku menarik nya "edata", Jill Dych mencatat banyak departemen TI tidak benar-benar tahu bagaimana bisnis menggunakan gudang data. Hal ini tidak selalu buruk, meskipun, jika TI tidak tahu semua menggunakan spesifik. Kadang-kadang tanda sebuah gudang besar adalah bahwa pengguna "menjalankannya" mereka sendiri.Namun demikian, adalah mungkin untuk mendapatkan gambaran umum hanya apa alat intelijen bisnis digunakan untuk mengakses data warehouse yang digunakan untuk. Dalam esai ini, saya akan mencoba untuk membuat pernyataan umum tentang penggunaan alat tersebut. Mungkin data warehouse orang pendukung dapat melakukan pekerjaan yang lebih baik jika mereka memiliki rasa yang lebih baik untuk apa alat-alat yang benar-benar digunakan untuk.Penggunaan utama dari alat intelijen bisnis adalah: Untuk memastikan bahwa "segala sesuatu" baik-baik sajaSurprise! Tidak ada yang akan dilakukan dengan banyak, mungkin sebagian besar, dari query dan laporan dibuat dengan alat intelijen bisnis. Mereka dijalankan untuk mengkonfirmasi seseorang yang biasanya tidak kerupuk didefinisikan gagasan namun intuitif merasa gagasan "okayness." Jika saya mampu menulis esai pada "The Zen of Data Warehousing" (yang saya tidak akan), aku akan mengatakan fungsi utama dari alat intelijen bisnis adalah untuk mendukung non-aksi. Untuk mengkonfirmasi "jelas" 31Kebanyakan pengguna akhir laporan dan query pada akhirnya diproduksi untuk memiliki nuansa usus cukup baik untuk apa yang terjadi di daerah mereka yang memprihatinkan. bisnis alat intelijen tidak mengatakan apa-apa ini orang yang luar biasa bahwa orang tidak sudah menduga. Namun informasi yang dihasilkan dengan alat memberi mereka rasa percaya diri merasa usus mereka baik-baik saja. Untuk mengidentifikasi luar biasaBiasanya konsumen akhir dari output alat itu memiliki kriteria agak kabur dari apa yang keluar dari biasa. Intelijen bisnis alat semacam melakukan tugas ganda dalam bahwa mereka membantu memperbaiki kriteria apa yang luar biasa dan mengidentifikasi apa yang sesuai dengan kriteria yang halus keluar dari ordinariness. Untuk mengetahui bagaimana sesuatu yang "bekerja"Kebanyakan orang tidak mencari beberapa Unified Theory grand cara kerja perusahaan XYZ. Sebaliknya, mereka ingin memahami beberapa aspek kecil dari sebuah operasi seperti Nasabah A selalu membayar tepat waktu, Pelanggan B biasanya membayar terlambat dan masih mengambil diskon pembayaran awal, dll Untuk menyampaikan informasi dengan cara yang lebih mudah dicernaAlat ini sering digunakan untuk menyampaikan apa yang seseorang atau beberapa orang sudah tahu. Orang-orang mengetahui menggunakan alat sederhana untuk menyajikan informasi kepada orang lain dengan cara yang lebih mudah dibaca. Untuk membandingkan informasi tentang pelanggan, produk, biaya / keuntungan pusat, rekening keuanganKadang-kadang ini adalah sisi dengan perbandingan sisi serangkaian langkah-langkah. Kadangkadang ini adalah identifikasi yang paling, paling, yang paling awal, yang terbaru, dll Untuk membandingkan jenis informasi yang sama dalam periode waktu yang berbedaIni hanyalah harian biasa, mingguan, bulanan, kuartalan, perbandingan tahunan. Untuk memeriksa kinerja dibandingkan tujuan formal dan informal atau kendalaArtinya, ukuran apa yang sebenarnya terjadi dibandingkan dengan anggaran, prakiraan, kuota, atau beberapa jenis lain tujuan. Untuk mengambil sepotong kecil informasi dari volume besar informasiAlat-alat ini membuat memilih bahwa jarum maya keluar dari tumpukan jerami maya jauh lebih sederhana. Untuk menyiasati departemen Teknologi Informasi yang tidak memiliki waktu atau sumber daya untuk menulis laporanSeringkali pengguna akhir menggunakan alat ini keluar dari ketidaksabaran dengan departemen TI. Atau, departemen TI memberikan pengguna alat ini untuk meringankan tekanan dari dirinya sendiri. Pengguna akhir dalam kasus ini sering menulis laporan bahwa hampir tidak bisa disebut analisis. Untuk memberikan laporan "catatan"Untuk semua jenis alasan itu sering perlu bagi orang untuk setuju bahwa "ini adalah angkaangka." Perhatikan mereka tidak harus setuju pada semua data - hanya beberapa data yang kredibilitasnya harus diterima atas tindakan yang akan diambil. bisnis alat intelijen sering digunakan untuk menghasilkan "resmi" informasi. Untuk mengkonfirmasi dan kadang-kadang untuk menemukan tren dan hubunganDengan segala hormat kepada orang-orang yang bekerja keras pada data mining, saya berpikir bahwa sebagian besar pelaku bisnis baik memiliki perasaan intuitif tren yang paling penting dan hubungan antara faktor yang mempengaruhi bisnis mereka. Alat bisnis intelijen melakukan fungsi mengkonfirmasi intuisi mereka. Ya, alat ini juga dapat membantu menemukan tren dan hubungan tetapi sulit (meskipun berpotensi menguntungkan) untuk menyaring tren berarti dan palsu.33Untuk membantu advokasi posisiAlat ini tidak hanya untuk presentasi "objektif" dari fakta-fakta. Seringkali mereka cerdik digunakan untuk membantu memperkuat kasus untuk melakukan (atau tidak melakukan) sesuatu. Untuk menyediakan data untuk bagaimana jika analisa atau prakiraanArtinya, alat-alat yang digunakan untuk memberi makan data ke dalam spreadsheet mana yang sebenarnya apa-jika analisis atau perkiraan akan dilakukan. Alat dapat melakukan beberapa apajika-ing dan peramalan sendiri namun sebagian besar pengguna bisnis lebih nyaman melakukan pekerjaan ini di spreadsheet.Untuk mengulang poin yang saya telah dibuat dalam esai lain, sebagian besar alat-alat ini tidak digunakan sebagai masukan satunya untuk membuat keputusan non-sepele. Mereka juga tidak langsung pasokan apa yang saya akan mempertimbangkan untuk menjadi intelijen bisnis. Keputusan yang dibuat dan intelijen bisnis mengumpulkan hanya dengan kombinasi output dari alat intelijen bisnis, penilaian manusia dan intuisi, dan kemampuan untuk menempatkan informasi yang dimuntahkan oleh alat ke dalam konteks informasi yang jauh lebih luas daripada data warehouse , transaksi sistem pengolahan, repositori pengetahuan dapat menangani.Apakah Web Analytics berbeda? Topik web analytics adalah salah satu topik yang dibahas lebih dalam niche data pergudangan / pendukung keputusan. Meskipun telah ada beberapa tulisan yang cerdas pada topik, sebagian besar dari apa yang tertulis tampaknya menjadi pujian tidak perlu diragukan lagi sama perubahan revolusioner yang seharusnya menganalisis data ini akan membawa.Esai ini tidak dimaksudkan untuk menjadi primer how-to melainkan untuk meningkatkan beberapa pertanyaan dalam pikiran pembaca. Dalam esai ini saya ingin menantang beberapa hiperbola industri biasa. Web analytics adalah proses menganalisis catatan dari apa tindakan pengguna mengambil dengan mouse dan keyboard nya saat mengunjungi sebuah situsItu adalah semua itu. Ini tidak berarti bahwa misterius. Bahkan, jika data dapat ditandai seperti biasa, data web harus peringkat di antara yang paling biasa. Data web hanyalah salah satu sumber data - dengan kebiasaan sendiri dan dengan keterbatasan yang datang dengan semua sumber data lainJika Anda telah bekerja dengan berbagai sumber data lain, Anda mungkin tahu banyak tentang apa yang perlu Anda ketahui tentang bekerja dengan data web. Ya, data web memiliki kebiasaan tapi apa data (terutama data sedetail data web mentah) tidak memiliki kebiasaan. Penerima manfaat utama dari analisis web data web designerTidak banyak taruhan--perusahaan Anda (dan taruhan--karir Anda) keputusan akan dibuat dengan hasil analisis web data. Sebagian akan digunakan untuk membuat keputusan sedikit banyak tentang cara memodifikasi desain sebuah situs web. Di sisi lain, jika perusahaan Anda adalah taruhan kelanjutan pada penggunaan pintar dari situs web (dan, kecuali untuk dot-com, tidak banyak perusahaan jatuh ke dalam kategori itu), efek kumulatif dari keputusan-keputusan kecil mungkin perusahaan dan karir membahayakan. Pengusaha akan ingin dan paling diuntungkan dari data web yang sangat agregat yang biasanya dikombinasikan dengan non-web dataData Kebanyakan web memiliki detail jauh lebih dari pemasaran biasa atau orang keuangan ingin melihat. Dan orang-orang berpikir dalam hal kinerja relatif dari "saluran", yang sebagian besar, untuk non dot-com perusahaan, tidak berbasis web. Orang yang akan mendapatkan informasi yang paling dari data web adalah orang yang mengerti merancang situs web sehingga mereka digunakan secara menguntungkan dan yang mengerti kekuatan analisis dataOrang-orang ini sulit untuk menemukan! Maaf tentang stereotip tetapi, setidaknya dalam paparan saya terbatas untuk desainer web yang baik dan orang-orang yang mungkin tidak hands-on desainer tetapi memiliki perasaan yang baik untuk kekuatan sebuah situs web, mereka adalah orang yang sangat berbeda dari analis keuangan dan pemasaran bahwa data pergudangan / keputusan pengembang pendukung digunakan untuk bekerja dengan. Kebanyakan siswa dari desain web yang efektif baik tidak menyerang saya sebagai orang-orang yang ingin duduk dengan alat query / laporan atau tool OLAP dan memperbaiki beberapa analisis selama tiga jam. 35Seringkali web hasil analisis data kesimpulan yang akan segera jelas bagi seorang desainer web yang baikWeb analisis data dapat berfungsi sebagai pengganti yang sangat mahal untuk seorang desainer web yang baik. Di sisi lain, meskipun, kadang-kadang web analisis data dapat menjadi pengganti murah untuk seorang desainer web yang sangat mahal. Nilai data web rinci menurun cukup cepat dari waktu ke waktuMeskipun banyak data pelaksana pergudangan tidak akan mengakuinya, data yang paling kehilangan nilai dari waktu ke waktu. (Jika Anda ingin menjadi sedikit lebih akademis, nilai yang diharapkan dari penurunan data yang dari waktu ke waktu.) Karena situs web berubah begitu banyak, nilai dari data web menurun dengan cepat. Bayangkan melakukan sebuah pusat analisis biaya pengeluaran tradisional. Sekarang bayangkan apa yang akan terjadi jika pusat biaya dan hirarki pelaporan mereka akan berubah setiap hari. Ini adalah jenis apa rasanya untuk menganalisis beberapa data web. Dalam nada yang sama, nilai data lama web rinci meragukanSaya telah membaca publikasi memprediksi gudang berukuran petabyte bulan dan bahkan bertahun-tahun dari data web. Apa yang saya belum membaca, meskipun, adalah apa yang orang akan lakukan dengan data web tua. Mungkin setiap situs web yang menghasilkan bahwa perubahan banyak data rinci sehingga sering bahwa, kecuali pada tingkat yang sangat agregat, sulit dan mungkin berarti untuk membandingkan data yang lebih tua dengan data baru. Anda dapat memberikan "real-time" akses ke data web namun pengguna Anda tidak akan mampu menganalisis secara real timeSaya membaca pakar yang mengatakan sekarang Anda harus pergi keluar dan membangun sarana biasanya mahal untuk membiarkan pengguna web menganalisis data yang dihasilkan hingga milidetik lalu. - Aku tidak tahu siapa para pakar bekerja dengan tetapi kebanyakan orang yang saya temui yang menganalisis data tidak polymaths yang bisa, pada per jam berulang, mencurahkan analisis bermakna. Data web jauh "kotor" daripada data warehouse data biasaData web sering menimbulkan masalah dengan mengidentifikasi pengguna situs web, mengidentifikasi apa yang dilihat, mengidentifikasi urutan aktivitas pengguna di situs web, dan mengidentifikasi ketika pengguna mulai dan berhenti melihat sebuah situs web. Data mungkin memiliki kesenjangan atau data mungkin menjadi tersangka. Banyak dari masalah ini tidak dipecahkan diberikan tujuan desain dari sebuah situs web. Web Data bergantung pada beberapa kategorisasi yang cukup kaburSemua yang Anda ketahui tentang pengguna situs web adalah (apa yang Anda pikirkan adalah) urutan klik nya. Untuk membuat ini masuk akal data, Anda mungkin harus mengkategorikan pengguna dengan urutan mereka mengklik. Juga, Anda mungkin harus mengkategorikan halaman di situs web. Ini kategorisasi bisa jadi sangat kabur. Dengan itu, maksud saya mungkin ada banyak, banyak cara untuk mengkategorikan tanpa alasan kuat untuk menggunakan salah satu metode kategorisasi atas yang lain. Juga, meskipun tidak persis kategorisasi, Anda juga harus mendefinisikan "sesi" - ketika pengguna mulai dan berhenti mengakses situs web. Definisi sesi bisa sembarangan. Jika data sesi yang diambil dari beberapa server, Anda mungkin memiliki masalah yang unikJika jam server 'tidak benar-benar (!) Di sync, Anda akan memiliki waktu yang sulit melacak aktivitas pengguna. Jika situs Anda menghasilkan halaman secara dinamis, Anda mungkin harus menulis sistem Anda sendiri untuk melacak konten dinamis.Informasi ini juga harus berkorelasi dengan analisis file log. Jika halaman terdiri dari daerah yang dihasilkan secara dinamis beberapa, maka Anda memiliki masalah yang lebih rumit. Web Data isu membuat lebih sulit untuk melakukan tugas-tugas penilaian pengguna yang diperlukan untuk menggunakan alat data mining untuk memisahkan informasi yang berguna dari omong kosongSekarang ada kesadaran bahwa banyak penghakiman yang hanya dapat diberikan oleh manusia diperlukan untuk untuk bekerja data yang paling pertambangan. Seperti yang dapat Anda bayangkan, semua masalah dengan data web membuat lebih sulit untuk melakukan tugas-tugas penilaian bahwa perangkat lunak tidak bisa lakukan.37Seringkali analisis sepintas web data yang menghasilkan sebagian besar dari nilai yang dapat diperoleh dari analisis dataAtau, dalam istilah akademis yang lebih, nilai marjinal analisis tambahan bisa turun cukup cepat. Data mungkin tidak begitu kotor dan begitu fuzzy yang menganalisis lebih lanjut tidak mungkin worth it. Data web dengan sendirinya tidak memberikan banyak informasi tentang pengguna situs webKecuali pengguna situs web telah membeli sesuatu dari situs ini, Anda tahu sedikit tentang pengguna situs. (Saya membaca bahwa informasi pendaftaran kebanyakan, jika diberikan, adalah palsu.) Dan bahkan jika pengguna situs telah membeli sesuatu, Anda perlu mengkombinasikan data web dengan data dari internal dan eksternal (seperti dan Equifax, dll) non-Web data belajar sesuatu tentang pengguna situs web. Data web tidak memberikan informasi yang banyak tentang mengapa seseorang tidak menjadi pelangganKetika Anda membaca bahwa data web seharusnya untuk membantu Anda menemukan mengapa seseorang tidak pelanggan, Anda menemukan Anda melakukan ini dengan menganalisis klik dari pelanggan yang meninggalkan situs tanpa membeli. Juga, halaman terakhir seseorang mengklik seharusnya penting untuk menganalisis. - Pada kenyataannya, Anda mendapatkan sedikit informasi yang biasanya tidak besar. Ingat, biasanya satu-satunya hal yang Anda tahu tentang pelanggan non polanya mengklik. Analisis pola mengklik, seperti yang disebutkan sebelumnya, bisa sangat diperdebatkan. Beberapa penulis pemasaran telah mempertanyakan efektivitas sangat ditargetkan pemasaran beberapa upaya perusahaan melalui analisis webMeskipun saya tidak mengklaim menjadi ahli pemasaran, beberapa ahli yang seharusnya publikasi saya telah membaca telah mempertanyakan efektivitas halus segmentasi pasar (yang di pasar paling ekstrim adalah segmentasi untuk satu orang). Mereka mengatakan bahwa pada beberapa titik dalam segmentasi pasar sebenarnya mungkin untuk mendapatkan hasil marginal negatif. Saya menafsirkan tulisan-tulisan mereka berarti bahwa pemasar harus rendah hati tentang pemahaman mereka tentang perilaku konsumen. Meskipun tampaknya berlawanan, jauh lebih efektif dapat ditindaklanjuti oleh pengamatan perilaku kelompok bukan oleh pengamatan perilaku individu.Esai ini tidak dimaksudkan untuk menghalangi orang dari menganalisis data web. Web analisis data bisa sangat menguntungkan. Tapi seperti semua aplikasi lain dari data warehousing / pendukung keputusan, data analisis web harus dilakukan secara cerdas. Artinya, kita harus tahu siapa kita yang sebenarnya adalah pengguna, jujur mengakui masalah data kita tidak bisa menyelesaikan atau sebagian dapat memecahkan, dan membuat keputusan kami pada berapa banyak kita ingin menganalisis dengan mata untuk manfaat marjinal diharapkan versus biaya marjinal yang diharapkan.39