P. 1
Data Warehousing (2)

Data Warehousing (2)

|Views: 83|Likes:
Published by Condro Triharyono
data warehousing definisi
data warehousing definisi

More info:

Categories:Types, Business/Law
Published by: Condro Triharyono on Mar 08, 2013
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as RTF, PDF, TXT or read online from Scribd
See more
See less

10/04/2013

pdf

text

original

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. 1

Semua 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 akses

Ini 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 query

Kadang-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 3

Perhatikan bahwa kedua tabel dan indeks dapat dipartisi. B-tree pengindeksan Menambahkan indeks banyak metode lain yang umum untuk mempercepat query. bergabung mungkin lebih efisien. 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. dan bentuk. jika Anda menggunakan kunci pengganti dalam hubungannya dengan pemodelan dimensi. Partisi Ini mungkin adalah metode yang paling umum kedua mempercepat query. Ada banyak diskusi ini dalam literatur. Perhatikan bahwa partisi datang dalam banyak hal. Juga. Dimensi pemodelan Dengan teknologi database tertentu. dan "Data Warehousing di Dunia Nyata" telah sangat baik non-teknologi diskusi yang spesifik dari topik ini. bentuk. Agregat navigator / redirectors permintaan Ini adalah teknologi yang secara otomatis mengarahkan query ke data agregat jika data tersebut tersedia dan sesuai untuk query. Dan. Buku-buku "The Data Warehouse Lifecycle Toolkit". . beberapa alat permintaan dapat menghasilkan SQL lebih efisien jika data dimodelkan dimensi. itu membagi satu tabel menjadi beberapa tabel biasanya didasarkan pada waktu data tabel mewakili. "The Data Warehouse Toolkit". Setidaknya.Ini mungkin adalah metode yang paling digunakan untuk mempercepat query. Catatan. model ini dapat mengurangi jumlah jenis / penggabungan yang berlangsung ketika bergabung tabel. Parallelizing eksekusi query Perkembangan teknologi database telah membuat melakukan hal ini jauh lebih mudah.

kardinalitas rendah) dan cenderung berada dalam klausa WHERE sering.bagaimanapun. Bit dipetakan pengindeksan Teknik ini dapat bekerja dengan baik pada wilayah yang mengambil rendahnya jumlah nilai yang berbeda (misalnya. Benar-benar denormalizing tabel agregat Jika tabel ini dapat sangat diindeks dan dapat dipertahankan dengan menyegarkan lengkap. persyaratan pengolahan join dapat dihilangkan. Memuat tabel sepenuhnya dalam memori Menganggap memori yang tersedia untuk melakukan ini dan Anda telah meneliti topik lain dalam makalah ini. jumlah pengguna yang menjalankan query dan jumlah data yang akan dikembalikan dalam query kadang-kadang dapat membatasi efektivitas dari teknik ini. Lihatlah ke dalam topik RAID untuk lebih jelasnya. Menemukan file yang berbeda digunakan secara bersamaan pada disk yang berbeda 5 . Striping file Ini berarti menyebarkan file melalui disk fisik beberapa. ini mungkin merupakan strategi yang menarik. Mengurangi lebar tabel besar yang bisa dipindai Ada juga banyak cara untuk melakukan hal ini. Pengarsipan / membersihkan data yang Kadang-kadang biaya harus memindai melalui data yang lebih tua melebihi manfaat dari memiliki itu tersedia dalam kemungkinan tidak mungkin seseorang ingin memeriksanya. Sebelum mendapatkan mewah dengan ini ada baiknya meluangkan waktu untuk memahami apa yang sebenarnya membutuhkan ruang dalam tabel database Anda.

permintaan penjadwalan sumber daya konsumtif untuk off-jam kali dapat membebaskan sumber daya untuk permintaan lain selama prime time. Defragmentation meja dan file indeks Ini adalah hal yang lebih mendasar. 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 antrian Seperti penjadwalan. Solid State Disk Seharusnya harga telah turun dalam beberapa tahun terakhir. . hal ini tidak mempercepat permintaan menyerah. Disk controller Terlalu sedikit dapat menjadi hambatan permintaan. Apa alat permintaan Anda mencoba untuk melakukan melalui SQL dan apa yang dilakukannya internal Buku "The Data Warehouse Toolkit" memiliki diskusi yang baik di mana alat query mungkin jatuh pendek.Ini adalah hal-hal dasar tetapi dapat membantu. Namun. Namun. Query penjadwalan kemampuan Hal ini tidak selalu mempercepat query yang diberikan. 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.

alat ini dapat memeriksa untuk melihat apakah hasilnya disimpan. citra laporan dapat disimpan. alat akan membaca hasil query diambil sebelumnya diatur daripada data warehouse. jika subset dari set hasil diambil sebelumnya diinginkan.Query akselerator Ini membantu Anda menghasilkan SQL lebih efisien. Query alat caching hasil Beberapa alat menyimpan hasil dari beberapa permintaan. Ada alat yang memungkinkan pengambilan cerdas data laporan disimpan. Menyimpan gambar dari laporan Jika laporan berdasarkan query yang digunakan oleh banyak orang dan on-line pengambilan laporan diperlukan. Jika permintaan yang sama dijalankan lagi. 7 . Permintaan itu perlu dijalankan hanya sekali dan mungkin pada waktu kurang sibuk. Query nanny Ini adalah istilah saya untuk teknologi yang memperingatkan (memarahi?) Pengguna jika dia mengajukan sebuah permintaan yang tidak efisien. "Productionizing" sering digunakan. Perhatikan bahwa mereka mungkin lebih bermanfaat bagi mereka yang melaporkan off dari database yang sangat normal. Beberapa memberikan petunjuk tentang bagaimana membuat query lebih efisien dan beberapa (saya telah mendengar) benar-benar mencoba untuk memperbaiki query. Atau. permintaan sumber daya yang sangat konsumtif Query tertentu mungkin harus ditulis oleh seseorang dengan banyak pengetahuan bagaimana membuat query yang efisien. Query gubernur Permintaan berhenti ini biasanya setelah sejumlah tertentu dari baris telah kembali dan / atau waktu yang ditentukan telah berlalu.

membayar untuk melacak aliran data dari server ke workstation pengguna untuk melihat apakah ada komponen jaringan cocok. dalam sebuah gudang data khas sebagian besar pengguna (biasanya dengan lebih "operasional" kebutuhan) menjalankan IS ditulis. query parameter. Tabel kompresi Membaca blok sedikit data yang dapat mengakibatkan kinerja query ditingkatkan. beberapa alat memudahkan untuk mengambil subset kecil dari catatan yang memenuhi kriteria queri. . Perhatikan ada banyak pendekatan untuk mengompresi data yang Anda mungkin harus bereksperimen dengan.Meskipun belum tentu cantik. Namun. Sebuah jumlah yang relatif kecil pengguna (biasanya dengan lebih "analitis" kebutuhan) berjalan sangat berpotensi sumber daya konsumtif ad hoc query. 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). Hal ini membuat lebih cepat untuk menguji permintaan dan luka bawah jumlah permintaan tes berpotensi mahal. kadang-kadang cara terbaik untuk menangani ini menggunakan campuran dari data warehouse adalah untuk membuat salinan terpisah dari data warehouse untuk setiap kelompok pengguna. Membuat dua salinan dari data warehouse . Jaringan kemacetan Meskipun Anda tidak perlu menjadi seorang ahli pada topologi jaringan. tetapi pengguna Anda mungkin memiliki kartu antarmuka jaringan 10Mbps .. pengguna . Fast Ethernet mungkin dalam fasilitas baru Anda. Multi-tier arsitektur / partisi Aplikasi Beberapa alat query memungkinkan Anda untuk menjalankan komponen yang berbeda (misalnya. Atau. "tingkatan" atau "partisi") dari alat pada server hardware yang berbeda.Alat query preview subset dari catatan Jika permintaan sedang dikembangkan. Sebagai contoh.satu untuk "operasional" pengguna dan satu untuk "analitis" pengguna Ini sebenarnya sulit untuk menarik garis antara apa yang penggunaan operasional dan apa gunanya analisis data warehouse.

Juga. Teknologi database yang dirancang khusus untuk data warehousing Google data warehouse peralatan. kali ini tala dapat mengambil IS jauh dari gudang data masalah yang solusinya lebih berarti bagi bisnis lainnya. Kolumnar database Banyak dari peralatan data warehouse fitur arsitektur ini. Sejalan dengan apa yang saya katakan. cari tahu bagaimana jaringan Anda orang keseimbangan beban. Anda akan mencegah beberapa masalah jika Anda menghabiskan waktu mengajar pengguna Anda tentang apa. memori. Meskipun banyak IS orang suka menghabiskan waktu mereka query tuning. biaya dari listrik dan kawat mungkin worth it. trial and error. Pada kenyataannya bidang mempercepat query melibatkan banyak dugaan. cari tahu biaya menjatuhkan kabel lebih sehingga Anda dapat menempatkan pengguna yang menjalankan set hasil yang besar memproduksi query pada segmen jaringan khusus. secara umum. Biaya pemasangan lebih CPU / lebih cepat.Anda mungkin memiliki kartu yang diiklankan untuk tampil di 100Mbps yang pada kenyataannya tampil di 30Mbps. hal perbuatan dengan intuisi. 9 . Beberapa pemikiran akhir tentang mempercepat query: Anda terbaik berharap bahwa banyak pertanyaan Anda akan menjalankan "lama" waktu. Dan jika perlu. dan membuat tidak nyaman trade-off. disk Kadang-kadang membeli logam (jauh) cara paling murah untuk mempercepat query Anda. Mereka lebih digunakan untuk berurusan dengan proses transaksi diprediksi dibandingkan tuntutan data yang sangat variabel pergudangan. akan memakan waktu yang lama. Anda dapat menghabiskan banyak waktu query tala. Jika Anda telah menginvestasikan jutaan dalam gudang data.

Juga tidak termasuk dalam daftar topik pernyataan bahwa pengetahuan tentang topik pasti akan mempercepat loading. Tulisan ini tidak akan mencoba untuk memberikan penjelasan rinci tentang topik ini. mengubah dan memuat data (selanjutnya hanya disebut sebagai loading) atau untuk membuat proses ini lebih rentan terhadap kesalahan. Jika data warehouse Anda tidak ada untuk mendukung sehari-hari monitoring dan analisis. Anda ingin memastikan Anda mengatur faktor indeks mengisi sehingga disk drive server Anda jangan buang waktu mencari ruang di mana untuk menulis update indeks. Anda mungkin ingin belajar tentang menjatuhkan indeks sebelum beban database dan kemudian kembali membangun mereka setelah beban. meskipun. Fasilitas apa yang database memiliki data bongkar muat dan mana fasilitas tersebut tidak masuk akal untuk menggunakan . Jika Anda tidak menjatuhkan indeks. DBA Anda harus tahu beberapa cara untuk mempercepat beban yang hanya berlaku untuk teknologi vendor DBMS Anda. mencoba merancang proses loading Anda sehingga Anda tidak terikat dengan beban pada interval tertentu. Bagaimana drop dan membangun kembali indeks dan cara mengatur faktor indeks mengisi Jika Anda memperbarui sebagian besar database (saya sudah mendengar perkiraan 10-25% up). jika Anda memutuskan untuk memperbarui mingguan atau bulanan. Seberapa sering pengguna benar-benar membutuhkan data diperbarui Sering 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.Apa 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. Daftar ini tidak mencakup poin relevan dengan teknologi vendor tertentu itu. kenyataannya sangat berbeda. pelaksana gudang data dapat menggunakan kertas ini sebagai titik awal dalam pencarian mereka cara untuk mempercepat loading. Jika data warehouse Anda tidak ada untuk minggu-ke-minggu pemantauan dan analisis. Mungkin ada beberapa "krisis" saat-saat ketika Anda harus memuat lebih sering. By the way. Sebaliknya. pertanyaan mengapa harus diperbarui setiap hari. pertanyaan mengapa harus diperbarui setiap minggu. 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.

dan beban dalam satu proses. By the way. Apa masukan format file akan mempercepat loading massal Sering kali operasi dilakukan pada data masukan pada platform sistem pengumpan (misalnya. ukuran pembatasan skalabilitas. Anda. Mengingat keadaan. meskipun. mengubah. tidak perlu untuk membuat file intermediate. Bagaimana indeks digunakan oleh optimizer database Anda Anda perlu mempelajari ini sehingga Anda dapat mengetahui apakah indeks Anda benar-benar akan terbiasa. Dimana tidak masuk akal untuk mengubah data 11 . dan pembatasan seberapa canggih transformasi Anda efisien dapat. menyortir. menghilangkan bidang dikemas dan ditandatangani) dapat mempercepat loading. Cara memuat database melalui sungai Alat ETL tertentu akan memungkinkan Anda untuk mengekstrak. Perhatikan bahwa loader massal tertentu melakukan lebih dari beban .mereka akan memformat data dan data kadang-kadang agregat. Apa pemeriksaan integritas harus dilakukan dalam proses pemuatan Setelah Anda melakukan beban awal tabel data warehouse. komponen.Database Banyak cara untuk mempercepat loading pada mengorbankan memeriksa integritas data. Artinya. Anda mungkin bisa lolos dengan indeks kurang dari dalam versi yang lebih tua. berbagai jenis paralelisme dapat memiliki luas berbagai jumlah efek. harus berhati-hati tentang data. Cara memparalelkan beban meja dan pemeliharaan indeks atau penciptaan kembali Menjatuhkan indeks dan bongkar muat secara paralel drastis dapat meningkatkan waktu loading. platform sumber. Anda mungkin ingin memulai "diskusi" tentang bagaimana semua kesalahan yang Anda temukan harus terjebak dalam sistem pengumpan (sebaiknya pada saat entri data). dan paralelisme data. mempelajari perbedaan antara pipa. Dalam versi yang lebih baru dari perangkat lunak DBMS.

Apa domain pemeriksaan integritas harus dalam database data warehouse Tergantung pada bagaimana Anda mengatasi dua masalah di atas. Anda mungkin ingin melakukannya pada platform tersebut. Data statistik yang tersedia di meja penggunaan agregat Seperti Anda mungkin telah membaca nauseum iklan.) Apa tingkat data masuk akal untuk agregat dan apa yang non-aditif langkah yang masuk akal untuk memasukkan dalam tabel agregat Anda . meskipun. 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). Masalah dengan melakukan hal ini pada platform sistem sumber.Mungkin ada tempat lebih cepat untuk melakukannya daripada di gudang data sistem database Anda. Dimana proses dapat dilakukan dalam memori Jika Anda sudah mendapat memori yang tersedia. 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. Dimana tidak masuk akal untuk agregat data Kadang-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 ingin bekerja dengan file datar dan semacam berdedikasi / merge utilitas baik pada platform gudang data atau. jika sumber data berada di platform lain. Sorts terutama dapat dipercepat dengan melakukan dalam memori. belajar bagaimana menggunakannya. membangun data warehouse adalah iteratif usaha. Anda mungkin akan membuat agregat yang jarang terbiasa. adalah bahwa Anda akan membutuhkan orang-orang yang terampil dalam platform itu dan Anda mungkin akan menyerang orang lain fiefdom. Anda harus menyelidiki sensibilitas menggabungkan integritas referensial atau jenis lain yang memiliki integritas domain memeriksa dalam database Anda.

Faktor yang menyulitkan. dimensi pelanggan. Anda mungkin menemukan bahwa setelah tingkat tertentu dari kegiatan pembaruan yang lebih cepat untuk membangun kembali daripada untuk memperbarui. Ini adalah aturan kasar dan ambang batas yang sebenarnya akan bervariasi. Bagaimana mengubah sistem feeder sehingga perubahan pada catatan ditulis ke file datar Meskipun ini biasanya tidak layak. Sadarilah bahwa Anda mungkin memiliki pilihan dalam bagaimana Anda melakukan ini dan pilihan akan berbeda dalam kecepatan. produk. Ada beberapa teknologi kecepatan transfer yang tinggi untuk menyelidiki. jika hal ini dilakukan maka dapat menghilangkan waktu yang 13 . meskipun. Namun demikian. dan penjual. pelanggan. wilayah. itu lebih cepat untuk membangun kembali. dan agregat penjual dan mengatakan. Anda mungkin menemukan bahwa Anda mendapatkan manfaat paling dengan menciptakan suatu daerah. Apakah Anda secara bertahap harus memperbarui atau membangun kembali tabel Kadang-kadang Anda memiliki pilihan untuk secara bertahap memperbarui tabel atau membangun kembali meja. adalah penggunaan non-aditif tindakan dalam agregat Anda karena mereka akan memaksa Anda untuk kembali agregat. jangan lupa tentang rekaman. jika Anda memiliki pilihan. Juga. Bahkan jika Anda harus mengirimkan rekaman semalam untuk pengiriman awal. jangan lupa tentang menggunakan teknologi kompresi dalam hubungannya dengan mentransfer. tape kadang-kadang cara tercepat untuk mentransfer data. Juga. Apa non-FTP cara mentransfer data FTP-ing bisa lambat. produk agregat menambahkan sedikit untuk kinerja pertanyaan Anda. Sebuah aturan praktis kadang-kadang menyatakan adalah bahwa jika 20% dari catatan akan diperbarui. bahwa. Apa metode alternatif untuk menangkap perubahan data Menganggap Anda secara bertahap harus memperbarui database data warehouse Anda dan Anda tidak mengeluarkan dari catatan transaksi tanggal dicap dalam sistem pengumpan. produk. wilayah. Anda mungkin menemukan Anda memiliki tugas teknis menakutkan dalam menangkap informasi yang berubah. sebuah wilayah tambahan. Cukuplah untuk mengatakan bahwa Anda harus berpikir dua kali sebelum menambahkan langkah-langkah untuk agregat Anda. pelanggan.Katakanlah Anda memiliki wilayah. mungkin patut bereksperimen dengan mereka. wilayah.

Anda menjalankan resiko jika perubahan format laporan. kadangkadang masuk akal untuk menempatkan gambar laporan dalam file dan menggunakan perangkat lunak yang dirancang khusus untuk mengekstrak data dari file gambar laporan.dibutuhkan untuk pergi melalui kadang-kadang waktu proses. memutahirkan copy. jika Anda memiliki jendela yang ketat untuk memuat data warehouse dan loading yang . By the way. Anda ingin melakukan analisis risiko sehingga Anda dapat mengetahui apakah itu sepadan dengan usaha untuk memulai kembali membangun kemampuan dalam proses intermediate. (Meskipun berhatihati bahwa Anda memahami bagaimana mirroring dapat ditangani oleh hardware dan software). dan mengembalikan cermin dengan copy diperbarui. Namun teknik ini sering masuk akal untuk penggalian data sistem yang kode belum tersentuh dalam sepuluh tahun terakhir. Bagaimana menjadwalkan proses pemuatan Loading data warehouse biasanya membutuhkan cukup beberapa proses. Anda bisa "memecahkan" cermin. jika sebuah disk dicerminkan sementara massal dimuat. Demikian pula. Dan Anda ingin memastikan bahwa Anda memiliki dukungan manusia dan otomatis untuk penjadwalan seperti yang Anda mau. Cara menggunakan software laporan Scraping Jika laporan yang memiliki data yang Anda butuhkan untuk mengekstrak tersedia. backup panas memungkinkan Anda untuk memiliki data warehouse database Anda tersedia ketika dukungan itu. Namun. Dengan disk cermin. Anda ingin memahami di mana ada dan tidak dependensi sehingga Anda dapat "multi-task" proses ini sebanyak mungkin. Ini berarti bahwa Anda masih dapat memiliki gudang data yang tersedia Anda saat memuat itu. memakan berbelit-belit untuk menentukan apa pengumpan data sistem telah berubah. waktu loading dapat sangat meningkatkan) tetapi mereka dapat memberikan beberapa fleksibilitas sangat diinginkan dan ruang untuk bernapas. Bagaimana mengatur sebuah pos pemeriksaan restartable Sekali lagi. Dimana ada dependensi. siklus backup parsial diikuti oleh full backup juga layak melihat ke dalam. Cara melakukan mirroring disk dan backup panas Disk mirroring dan backup panas tidak akan mempercepat loading database data warehouse (pada kenyataannya. Jelas. pemeriksaan tidak akan dengan sendirinya mempercepat proses loading.

Arsitektur puritan membenci solusi ini tapi kadang-kadang hanya masuk akal untuk menangani laporan Anda membutuhkan cara ini. indeks. Anda mungkin ingin membuat input data yakin. Bagaimana untuk defragment file tabel dan indeks Ini adalah pengetahuan dasar mungkin akan melakukan Anda baik untuk tahu. 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. tabel data warehouse.membutuhkan waktu yang cukup. Cara membuat salinan database sistem transaksi Jika Anda benar-benar ingin menggunakan gudang data Anda hanya untuk pelaporan produksi. Bagaimana untuk mendistribusikan data pada disk fisik beberapa Jika Anda mampu beberapa disk. Cara menggunakan kontroler beberapa disk 15 . dan log (jika Anda tidak menonaktifkan logging) berada pada disk fisik yang berbeda. Bahkan. Anda mungkin akan lebih baik hanya menyalin database transaksi berkala seperti. Partial memperbarui of multidimensional (MOLAP) database Banyak 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. 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 loading Teknologi RAID dapat baik membantu dan merugikan kecepatan loading.

pengguna sistem. atau penerimaan tanpa berpikir industri mainstream. perhatikan berapa banyak keleluasaan biasanya ada dalam desain dan implementasi sistem data warehousing sebagai lawan sistem pemrosesan transaksi. Dalam upaya pergudangan data. Beberapa komentar akhir . karena kurangnya waktu. Dalam sistem pemrosesan transaksi. data pengembang pergudangan sering gagal untuk memahami berbagai pilihan yang mereka miliki. Dan. tekanan politik. jangan biarkan data warehouse Anda menjadi sumber utama bagi operasional yang berorientasi permintaan dan fungsi melaporkan bahwa. 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. fungsi sistem biasanya tunduk relatif sedikit kebijaksanaan. Bahwa menjadi kata. Pertama. Sebaliknya ini adalah daftar suatu petunjuk yang dapat mendorong pengembang data warehouse untuk berpikir dua kali sebelum membuat mereka manajemen proyek..Dalam waktu jangka pemuatan lama biasanya akan menyebabkan masalah lebih besar dari kali query yang panjang.Anda akan ingin kecepatan tinggi interkoneksi pada kontroler ini. dan mungkin bahkan 20 jam. tingkat pelayanan yang diberikan kepada pengguna. dan teknis yang kumulatif dampak adalah untuk memaksa sumber daya jauh lebih berkomitmen untuk usaha pergudangan data dari apa yang diharapkan . seharusnya dalam sistem pengumpan pemrosesan transaksi. kecuali itu dilakukan oleh desain. tetapi pada akhirnya taktik terbaik Anda adalah kemampuan untuk memahami apa yang sebenarnya paling penting bagi bisnis dan manajemen user harapan yang baik.. keputusan desain politik. Namun. dalam gambaran besar. dan. Anda dapat membuang teknologi yang lebih dan lebih banyak di ini. meskipun. 14 16. saya berharap pointer ini akan memberikan jeda sedikit . Apa biaya pemasangan lebih CPU / lebih cepat. dalam banyak kasus. memori. data yang akan disimpan dalam sistem. umumnya ada kebijaksanaan yang jauh lebih besar atas faktor-faktor. .. teknologi yang akan digunakan. disk Kadang-kadang membeli logam (jauh) cara paling murah untuk mempercepat loading.. Bagaimana Simpan Uang di Upaya Warehousing Data Anda Esai ini bukan daftar taktik yang akan digunakan dalam mengembangkan teknologi pilihan Anda.

Pun mereka mungkin berharap waktu respon untuk menjadi sama seperti memindahkan sel dalam lembar kerja Excel.Memiliki alasan selain kemanfaatan untuk membangun sebuah laporan atau query dalam data warehouse yang bertentangan dengan sistem transaksi pengumpan pengolahan Anda 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. Anda menetapkan diri untuk mahal (dan mungkin abadi) ulang desain Anda ketika kinerja data warehouse tidak memenuhi harapan awal dari pengguna. Menetapkan harapan tentang waktu respon sebelum pengguna menggunakan data warehouse Ini "jelas" tidak pernah disebutkan poin cukup: 1) data kinerja pergudangan dapat berfluktuasi jauh lebih banyak daripada kinerja pemrosesan transaksi sistem (misalnya. 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. sistem produksi dua yang menyediakan fungsionalitas duplikat.Anda terbaik mendiskusikan masalah kinerja dengan pengguna Anda di awal penyelidikan gudang data Anda. 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. Sekarang. Jika unbundling ini dilakukan diam-diam. Dan karena kau pengembang data warehouse Anda mungkin akan memutuskan bahwa laporan atau query lebih mudah untuk dilakukan di gudang data -. . dengan biaya besar. Anda dapat dengan cepat kembali diri Anda ke dalam mendukung. kinerja rata-rata cenderung menurun 3) Jika data warehouse anda sedang digunakan untuk pekerjaan akhir ad hoc pengguna. Sebelum Anda menyadarinya. Anda kemungkinan besar tidak akan bisa "tune" sistem data warehouse Anda untuk semuanya pengguna Anda akan melemparkan di itu. Jika Anda tidak membahas masalah kinerja yang diharapkan dengan pengguna Anda. Sebagai pengguna mulai menggunakan sistem. 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. Selamat Datang di lereng licin! Anda akan menemukan lebih banyak laporan dan query yang bisa "dua arah". Melakukan pekerjaan untuk menentukan ekonomi tingkat layanan yang berbeda Dapatkan apresiasi berapa banyak kenaikan pada biaya gudang tingkat layanan data. 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. Jenis 17 .

. platform ini masih sedang digunakan dengan sukses untuk data warehousing. tetapi jika Anda memiliki investasi yang besar dalam platform ini dan "penjaga" dari platform tersebut tidak terlalu tahan. Sebelum data pergudangan disebut data pergudangan. midrange proprietary. meskipun Anda tidak akan membacanya di media perdagangan. 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. .Pelaporan terhadap data sistem pemrosesan transaksi tidak selalu tepat. platform ini sedang digunakan cukup berhasil untuk sistem data warehousing. Jadilah skeptis tentang membandingkan jenis analisis ini antara set yang berbeda dari teknologi. Anda mungkin menemukan melakukan analisis berharga. dan sistem file jaringan operasi server adalah platform yang sah untuk data warehousing. tapi kecuali Anda secara otomatis ingin menerima kebijaksanaan utama yang sepertinya tidak pernah mempertimbangkan varietas wajah situasi orang. Jika Anda melakukan pekerjaan rumah Anda. Pada 1990-an. vendor terkenal historis menguntungkan. pengetahuan yang penting adalah bagaimana membuat penyesuaian dengan himpunan teknologi akan mengubah kinerja biaya dan diharapkan. adalah berguna untuk melakukan analisis.analisis adalah "seni" tapi sebuah seni yang database Anda / hardware vendor / konsultan (dengan mempertanyakan setiap asumsi yang mereka buat) harus dapat membantu Anda dengan. kebijaksanaan utama yang dilakukan yang lain "180". By the way. Lakukan analisis apakah platform organisasi Anda telah menggunakan untuk waktu yang lama sesuai untuk usaha pergudangan data Anda Mainframe. Pada 1980-an kebijaksanaan utama melakukan "180" dan mengatakan bahwa "data tidak akan digandakan" dan bahwa Anda harus pergi melawan hal yang nyata. (Dan kemudian di tahun 2000an Anda akan dipertimbangkan dalam avant garde dan Anda akan menjadi sumber kebijaksanaan utama.) Tawar-menawar dengan database dan vendor hardware Kemungkinan Anda akan membeli database Anda dan perangkat keras Anda dari beberapa. Lakukan analisis apakah pengguna Anda secara langsung harus melaporkan / query terhadap data yang tersimpan dalam sistem pemrosesan transaksi Pada 1970-an. Bahkan. Platform tidak selalu tepat. kebijaksanaan industri mainstream adalah bahwa data harus diekstrak dan dilaporkan melawan.

Menerapkan teknik query meningkatkan efisiensi desain yang tidak memerlukan perangkat keras atau perangkat lunak khusus Khusus belajar tentang menggunakan tabel agregat dan partisi. dan paling tidak untuk mempercepat pengambilan informasi.Jika Anda akan memiliki sejumlah besar pengguna yang hanya menjalankan laporan kaleng. Berpikir dua kali sebelum membangun sarana untuk melakukan perhitungan yang kompleks bahwa pengguna bisnis sedikit mengerti Ini 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. 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. paling efektif. dengan pengguna data warehouse. sering kali itu tidak. Merinci data mungkin membersihkan tugas dan. mempertimbangkan alternatif untuk menyediakan para pengguna dengan laporan "penuh sesak nafas" berbasis klien dan permintaan. menguji apakah masing-masing tugas jurusan yang layak usaha Anda mungkin akan datang dengan daftar panjang masalah data banyak yang tidak sebanding dengan upaya untuk membersihkan. (Perkiraan bahwa 75% -. Meskipun teknik ini dapat digunakan secara berlebihan. Teknik ini dapat digunakan dengan semua jenis metode akses database atau file. Tetapi alternatif biasanya ada jika Anda melihat. Kadang-kadang. OLAP alat Dalam data warehouse yang khas. Dalam hal ini. mereka umumnya adalah cara paling sederhana mahal. bahwa pengguna bisnis yang paling memiliki waktu yang sulit memahami. Alternatif untuk menyediakan pengguna laporan kaleng dengan alat penuh sesak nafas bervariasi berdasarkan pada teknologi yang Anda gunakan dan politik situasi. 19 . sebagian besar pengguna ketat akan menjalankan laporan kaleng. Perhatikan bahwa "layak" adalah penilaian bahwa pengembang data warehouse dan pengguna harus setuju atas. pengembang data warehouse harus diplomatis mendiskusikan apakah perlu menghitung satu set angka yang pengguna bisnis mungkin hanya akan mengerti.

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. laporan. Segera memutus data warehouse sebagai "memperbaiki" bisa menjadi kesalahan mahal. Jika Anda tidak melakukan pekerjaan biaya berapa banyak biaya untuk memperbaiki sistem pemrosesan transaksi. Terimalah bahwa data pergudangan akan menjadi berantakan teknis . jumlah data. Pertanyaan apakah Anda benar-benar akan mendapatkan keuntungan dari kategori tertentu alat Untuk beberapa implementasi data warehouse. 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. Anda mungkin akan lebih baik coding dengan tangan daripada menggunakan apa yang disebut "data mart" alat. dan waktu Anda harus memuat database. jika Anda tidak memiliki kebutuhan untuk slice-dan-dadu atau kemampuan pemodelan alat OLAP. Anda mungkin tidak MEMBUTUHKAN data warehouse Kadang-kadang generator laporan yang baik akan baik-baik saja. dan alat query dapat memenuhi kebutuhan pelaporan Anda lebih dari cukup. melakukan pekerjaan biaya berapa banyak itu akan memperbaiki sistem pemrosesan transaksi sebelum Anda membuat keputusan data warehouse Ini mungkin tidak mengejutkan bahwa motivasi utama untuk pembangunan gudang data yang banyak adalah untuk berkeliling kesulitan yang disebabkan oleh sistem pemrosesan transaksi bermasalah. Jika Anda harus melakukan cukup rumit transformasi data dan / atau Anda memiliki sumber data yang relatif sedikit dan target. Anda mungkin tidak pernah memahami apa yang sebenarnya menyebabkan masalah.Jika alasan utama Anda sedang mempertimbangkan data warehousing adalah untuk berkeliling kesulitan yang disebabkan oleh sistem pemrosesan transaksi 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. Database yang Anda gunakan untuk proses transaksi dapat melakukan dengan baik berdasarkan jumlah pengguna. Misalnya. beberapa jenis alat hanya tidak masuk akal bisnis yang baik.

Tidak ada aturan untuk menentukan di mana titik ini. Mungkin alasan Yang memucat penting untuk inisial adalah bahwa pengambilan keputusan Strategis biasanya tidak dilakukan Yang sering. 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. menggunakan gudang data yang Illustrasi keputusan nihil membuat latihan. 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. pengambilan keputusan Strategis latihan. biarkan SAYA menentukan pengambilan keputusan Strategis. Menggunakan Data Warehousing Dalam. pemodelan (Bukan Dalam. Gunakan pertimbangan Anda dan intuisi untuk membuat tekad. Mungkin ADA ribuan definisi diterbitkan. Saya Ingin menawarkan beberapa Wawasan Ke Dalam. Menciptakan "KHUSUS" database.Jika ada orang yang pernah menulis "The Zen Of Data Warehousing" (binasa pikiran .silahkan). berantakan (dan lebih mahal dan kurang menguntungkan) mereka berakhir menjadi.) SAYA menegaskan bahwa sebagian Besar penggunaan gudang data yang tidak untuk pengambilan keputusan Strategis. pengambilan keputusan Strategis Dan digunakan Ulasan Sangat menguntungkan. salah satu konsep mungkin akan bahwa di beberapa titik. Namun demikian. dan jumlah Pelaporan resmi adalah Tugas Yang memucat memakan waktu ketika menggunakan gudang data yang Illustrasi pengambilan keputusan Strategis 21 . Sebaliknya. (Tentu Saja "banyak" adalah istilah relatif yang. Illustrasi esai inisial. beberapa data warehouse Bisa digunakan Dalam. Saya Percaya bahwa gudang Data Yang memucat digunakan terutama untuk memantau keputusan pasca Efek keputusan. yang lebih teknis elegan Anda mencoba untuk membuat sistem ini. PERTAMA. Apa Berikut adalah beberapa pengamatan mengenai bagaimana Pribadi Andari BENAR-BENAR dapat menggunakan data warehouse Dalam. arti kata IS).

) Andari melakukan pekerjaan inisial karena ketika Andari membangun data warehouse. Andari mungkin Perlu membuat basis data KHUSUS Seringkali Andari Perlu menjalankan pertanyaan berulang-Ulang terhadap bagian bahasa Dari data warehouse. Bisa membawa lebih REVENUES bahasa Dari beberapa SISTEM Pelaporan kaleng Yang digunakan selama bertahun-years. bagian bahasa Dari keputusan Strategis Yang efektif membuat latihan adalah untuk melihat bisnisdan Illustrasi Perspektif Yang berbeda. IS biasanya harus memakai topi bisnisdan Dan MENCARI Tahu Apa Yang sebenarnya dibutuhkan oleh bisnisdan. Biasanya pekerjaan harus dilakukan Artikel Baru CEPAT Dan diminta Artikel Baru PEMBERITAHUAN: sedikit SIGNIFIKAN Pekerjaan Suami biasanya harus dilakukan Dalam. (Baru kata Lain. Atau. Dan menggabungkan Data Yang tidak pernah sebelumnya telah digabungkan Pekerjaan Yang Andari lakukan memungkinkan bisnisdan untuk melihat sudut Pandang Yang tidak pandangan UMUM bahasa Dari bisnisdan. Mereka beberapa Hari menggunakan SISTEM. meskipun. seperti Yang SAYA sebutkan. Andari mungkin Perlu . Suami adalah "mencari tahu sebagai Andari pergi Bersama pekerjaan" di mana IS sering harus mengambil bagian bahasa Dari Analis bisnisdan. 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. Andari Artikel Baru dibangun Sesuai Apa Yang kemudian pandangan UMUM bisnisdan. Penggunakan Sistem pengambilan keputusan Strategis cenderung relatif yang pendek-Hidup JUMLAH waktu Yang dihabiskan menggunakan inisial SISTEM kadang-kadang dapat diukur Illustrasi Hari dihitung Artikel Baru Satu Tangan. menggunakan perhitungan Yang berbeda untuk Nomor diturunkan.Kemudian SAYA Akan pergi Ke detil lebih ACLS mengenai TOPIK inisial. Subset mungkin salat Satu Yang diciptakan oleh permintaan Ekstrak Artikel Baru kendala Yang cukup rumit. Persyaratan inisial biasanya Ambigu. Biasanya tidak ADA waktu untuk wawancara resmi diperpanjang Dan data latihan modeling. Andari mungkin harus Data agregat berbeda. APA pun bahasa Dari sakit Panjang untuk beberapa Minggu.

) Andari mungkin harus "memberi Makan" Data Ke pengguna mempertahankan model spreadsheet Sebagian Besar penggunaan data warehousing untuk pengambilan keputusan Strategis PADA akhirnya melibatkan "Makan" pengguna dipertahankan spreadsheet. (Untuk menempatkan inisial Illustrasi istilah: sedikit lebih Teknis. Kadang-kadang Data kebersihan JAUH lebih: sedikit perhatian Illustrasi pengambilan keputusan Strategis Kadang-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. Andari Tetap Jejak Audit Yang memungkinkan Andari melacak bagaimana Data Yang berasal bahasa Dari SISTEM pengumpan. lihat Diskusi Ralph Kimball tentang "Metode studi therapy terapi". banyak bahasa Dari perhitungan antar-PT BUMI. memberi Makan data spreadsheet Ke Dalam. pengambilan keputusan Strategis latihan. seringkali ADA ADA Saja Cara untuk menghindari Ekstrak. (Untuk lebih ACLS tentang ide BACAKAN mirip tentang Database KHUSUS. Perhatikan JUGA bahwa seringkali Perlu. PADA gilirannya. Andari mungkin berpikir Andari membuat data warehouse sehingga Andari tidak Akan harus membangun KHUSUS "Ekstrak" TAPI.Dan pengguna Yang memucat berpengetahuan tentang melakukan perubahan di Customers spreadsheet. mungkin untuk tidak mengejutkan.berulang 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. perhitungan pada dimensi Lintas). Demi kesederhanaan Dan efisiensi. Andari mungkin harus membuat beberapa DAFTAR ISI CONTENTS Yang Ulasan Sangat diformat 23 . membuat perhitungan. Database KHUSUS Yang telah Andari buat. bahwa APA pun Harapan Data. 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 . Suami "umpan" Yang BAIK Link Ke Data Yang tersimpan di gudang data yang sebenarnya atau pemuatan Data Ke spreadsheet. SAYA sarankan. Banyak Alat OLAP memungkinkan banyak fleksibilitas Dalam. tetapi kemampuan inisial cenderung terlalu Sulit BAGI pengguna Yang terburu-Buru Dalam. tentu Saja Andari terbaik adalah untuk membuat KHUSUS database. bagaimanapun.

Jangan meletakkan Segala sesuatu mungkin Andari Bisa memikirkan Dalam. biasanya ADA beberapa memberi Dan menerima. Illustrasi 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. pengambilan keputusan Strategis latihan. By the way. Perhatikan bahwa biasanya ADA Politik Dalam. Jangan. Ketika Andari awalnya merancang gudang. Namun. apakah DAFTAR ISI CONTENTS DAFTAR ISI CONTENTS-Dan Grafik harus dibuat secara manual (yaitu. Penghasilan kena pajak sebelumnya membangun hubungan saling Percaya Artikel Baru "pengambil keputusan" Ulasan Sangat membantu. Grafik biasanya dibuat untuk latihan. jangan mencoba untuk merancang untuk setiap kontingensi Yang dapat terjadi Dalam. Dalam. data warehouse. JUGA. Banyak pengguna Bahasa Dari Andari Akan Ingin melihat dipol untuk DAFTAR ISI CONTENTS Illustrasi rangka untuk menyampaikan kredibilitas. 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 bertanya Jangan berasumsi bahwa pengguna memiliki apresiasi Penuh bahasa Dari kekuatan Teknologi. spreadsheet) atau dihasilkan secara Langsung Bahasa Dari database. . Alat Presentasi. Artikel Baru pengolah kata. meskipun terburu-Buru. IS harus mengambil bagian bahasa Dari Analis bisnisdan untuk memacu imajinasi pengguna. pengambilan keputusan Strategis latihan Andari tidak dapat meramalkan Akan Apa Yang Akan dibutuhkan Illustrasi latihan. mendapatkan Lingkaran Mutasi. DAFTAR ISI CONTENTS DAFTAR ISI CONTENTSinisial biasanya diciptakan untuk membujuk seseorang. Andari mungkin Ingin pengguna untuk mengkomunikasikan INFORMASI Illustrasi DAFTAR ISI CONTENTS tercetak Yang terlihat hanya "jadi".INFORMASI Bahasa Dari data warehouse harus dikomunikasikan kepada orangutan-orangutan Yang tidak memiliki sampai / atau Ingin AKSes Langsung Ke data warehouse. Kecuali Andari memiliki beberapa pengguna Artikel Baru insting Yang BAIK tentang Teknologi. Cobalah untuk mendapatkan di "Lingkaran" Mutasi Pengguna Akan cenderung BAIK terlalu meremehkan atau melebih-lebihkan kekuatan gudang Data Dalam.

Jangan "Produksi-ize" pekerjaan Andari Pekerjaan Teknis dilakukan Dalam.) Do mengatasi masalah pada dimensi pelan-pelan berubah. bisnisdan Andari. JUGA. pengambilan keputusan Strategis latihan. identifikasi. bahwa Andari Perlu memodifikasi Produksi Andari database data warehouse. yaitu. Dan jangan membuat Diri Andari sepenuhnya Tergantung PADA Sumber Daya Luar Yang ketersediaan Andari tidak Bisa mengontrol. finansial. Dan internal "entitas". Andari mungkin Bisa sampai debit sungai ketika latihan Muncul inisial.meskipun. Teknologi Saja tidak Akan membuat orangutan ITU pembuat keputusan Yang lebih BAIK 25 . lakukan pekerjaan Andari Terus di sekitar sehingga Andari dapat mencopoti Kode untuk membuat keputusan Strategis berikutnya latihan. Latihan-latihan inisial Datang Tiba-Tiba. 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. Jangan mengklaim bahwa data yang Pergudangan Sendiri tentu Akan meningkatkan pengambilan keputusan Strategis Perlu sering diulang bahwa Acute seseorang adalah pembuat keputusan Yang Biasa-Biasa Saja. Lakukan Yang terbaik untuk menyesuaikan pada dimensi Kedudukan Bahasa Dari Data Yang digunakan Dalam. Produk. meskipun. cobalah untuk menyimpan data yang atom Illustrasi beberapa Format Elektronik dpt. Pelajari spreadsheet Dan bagaimana data warehouse Andari dapat berinteraksi Artikel Baru mereka Kami di Dunia data warehouse sering Lupa bahwa spreadsheet adalah JAUH Alat pendukung keputusan Yang memucat sering digunakan. latihan-latihan inisial biasanya tidak "kekuatan industri" Dan ITU mungkin tidak sebanding Artikel Baru Company 's name untuk membuatnya begitu. Acute pengetahuan Kunci bahasa Dari SISTEM Andari berada di Kepala Konsultan. Para Konsultan Teknis telah pergi Dan tidak tersedia ketika Peluang Muncul. Jangan biarkan pengetahuan tentang SISTEM tinggal di benak para Konsultan Teknis Luar Inisial bagian usang Dan jelas nasihat Perlu diulang. (Itu berarti pelanggan. orangutan-orangutan Dan menurut Departemen. Andari dapat Belajar.

hanya Usage) Illustrasi pengambilan keputusan Strategis latihan. Nah. Jangan lewatkan kesempatan Suami Sulit untuk Menghitung ROI Yang diharapkan bahasa Dari sebuah Proyek data warehouse. Anda mungkin memiliki eksposur lebih dari yang Anda miliki dengan sistem pemrosesan transaksi yang khas. mungkin penting. 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 . dan loading dan katalog informasi dapat sangat meringankan beban di sini. membuat perubahan. 10 sumber. katakanlah. seolah-olah sistem ini pernah mencapai stabilitas tersirat dengan istilah itu. 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. dll Tentu saja ini ada kekhawatiran baru untuk siapa pun melakukan pemeliharaan sistem. meskipun kekacauan bahasa Dari pekerjaan. Kebanyakan bisnisdan harus pergi PADA iman bahwa upaya entah bagaimana Akan sia-sia. itu adalah kesalahan besar untuk . menjaga informasi dan menilai dampak perubahan teknis didorong ke sistem feeder mungkin lebih sulit daripada melacak perubahan bisnis didorong. banyak perubahan akan memerlukan cukup banyak usaha. perubahan pengujian. Acute Andari tidak membenarkan data warehouse sebelum membangun ITU. untuk membenarkan data warehouse Penghasilan kena pajak Fakta. Dan meskipun penggunaan cerdas dari ekstraksi data. kadang-kadang. seperti disebutkan dalam halaman gotchas saya. keberhasilan (atau. alat pembersih. Ulasan Sangat Bisa memperkuat keyakinan bahwa data warehouse adalah Sepadan Artikel Baru kas. ITU pintar. Di sini saya menyajikan beberapa masalah yang mungkin Anda hadapi ketika sistem Anda "dalam produksi". Dan Cara terbaik Andari Akan melakukan inisial adalah "anekdot" Artikel Baru Cerita perang Yang sukses di tingkat pengambilan keputusan seperti Strategis latihan. Jika IS organisasi Anda memiliki pertemuan perubahan kendali. Bagaimana Anda akan menangani isu-isu akan tergantung pada lingkungan Anda. Daftar ini disajikan karena. meskipun Kami 100 TB database.terutama di Kepemilikan Modal pengambilan keputusan Strategis di mana. By the way. Jika Anda bertanggung jawab untuk sistem diberi makan dari. JAUH lebih Masih Proforma diketahui Bahasa Dari dikenal .

Anda mungkin harus mendorong pengguna akhir menjadi "air dalam". 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. Sayangnya. Anda akan tergoda untuk menambahkan data ini. salah satu bagian dari nasihat adalah untuk belajar tentang lebih murah. Terutama demi kelengkapan. Hal ini biasanya datang lebih cepat dari yang Anda harapkan. kapan.pengembang DW / DSS untuk tidak menghadiri pertemuan-pertemuan rutin. 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. Anda restrukturisasi data dan tidak layak upaya untuk merestrukturisasi data tertentu. Sebuah sangat umum IS harapan adalah bahwa pengguna akhir akan mengambil alih mayoritas penulisan tugas permintaan dan laporan. cara alternatif penyimpanan. Anda juga mungkin harus meyakinkan Anda IS staf bahwa laporan dan alat query bangunan tidak "mainan". Dan jika Anda seperti kebanyakan DW / DSS pengembang. Entah Anda berada di beberapa jenis batas kapasitas atau lebih mungkin. dan bagaimana untuk membersihkan data yang Ada datang satu titik ketika tidak masuk akal bisnis untuk menyimpan data tertentu dalam sistem pergudangan. Anda harus mencari tahu apakah. Anda harus menentukan query dan laporan harus IS tertulis dan yang harus user ditulis Mungkin ketika Anda bisa mulai masuk ke daerah ini Anda punya ide tentang siapa yang akan melakukan apa. Sebelum Anda masuk ke sebuah diskusi tentang membersihkan data. setelah Anda telah di produksi sementara Anda telah melihat bagaimana realitas telah berbeda dari harapan Anda.Anda mungkin memiliki tantangan di dua front. bila Anda telah menyerah kepada godaan ini beberapa kali. Anda akan menemukan peluang tak terbatas untuk menyempurnakan DW / DSS database sistem Saya pernah melihat sebuah kutipan dari direktur IS dari bisnis ritel terkenal yang mengatakan 27 . Anda akan menemukan Anda telah meledak ukuran dan kompleksitas data warehouse Anda tanpa pertimbangan yang tepat apakah ukuran dan kompleksitas tambahan memiliki nilai bisnis. 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! ______"). .

Anda harus mempertimbangkan waktu pengembang. Omong-omong. Anda mungkin telah menjual konsep DW sebagai cara yang "query pembunuh" tidak akan tarik ke bawah "produksi" Anda sistem. Hal ini tidak mungkin dari sebuah "ahli" bisa meramalkan semua masalah. seperti dalam poin terakhir. Ini "struktur" dapat banyak hal . Anda harus berhati-hati Anda tidak . Pertama.tabel terpisah dalam sistem relasional. Ada dua aspek dari beban ini. 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. Masalah yang Anda hadapi adalah menyeimbangkan keinginan Anda untuk mempercepat dengan kebutuhan untuk berhati-hati dengan berapa banyak beban pemeliharaan Anda ingin mengambil. Anda akan yakin apakah untuk membuat laporan tertentu / query dalam sistem data warehousing atau dalam sistem transaksi "feeder" pengolahan Anda terbaik disarankan untuk memiliki beberapa pedoman mengenai apa yang terjadi di mana. Kedua. Dan banyak masalah begitu gila bahwa mereka hanya cara Anda akan menyelesaikannya adalah atas dasar trial-and-error. dimensi di dunia OLAP. 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 menemukan bahwa ada berbagai cara untuk menyeret sistem ke merangkak." Jika Anda sedang mengizinkan tingkat wajar pengguna akhir mengembangkan akses ke sistem dan sistem Anda yang besar dan kompleks.bahwa data pergudangan terbesar pelajaran yang ia pelajari adalah "tidak ada ahli pergudangan banyak data di luar sana. Jika tidak. setelah beberapa saat Anda akan melihat berbagai cara untuk menambah atau memperbaiki struktur agregat biasanya dalam nama mengurangi waktu akhir pengguna pengambilan . Anda akan harus menyeimbangkan kebutuhan untuk membangun struktur agregat untuk memproses efisiensi dengan keinginan untuk tidak membangun sebuah mimpi buruk pemeliharaan Banyak DW / DSS sistem melibatkan struktur bangunan mengandung informasi yang dikumpulkan. Sekarang bahwa Anda telah dimasukkan ke dalam sistem data warehouse. dll Pokoknya. Anda harus mempertimbangkan jumlah waktu yang diperlukan untuk memperbarui sistem Anda secara berulang. Meskipun. Anda mungkin akhirnya menemukan bahwa Anda memiliki hampir tiruan dari sistem pemrosesan transaksi Anda dalam sistem pergudangan data Anda.

Anda akan menemukan banyak situasi di mana tidak jelas apakah akan pergi tugas berat atau ringan. Pada tingkat yang paling sederhana. Anda akan pasti yang alat yang paling tepat untuk tugas tertentu DW / DSS sistem IS hadir dengan lain set alat dengan menggunakan tumpang tindih. tidak menjaga pekerjaan mereka dalam 10 direktori yang berbeda dan menyimpan deskripsi pekerjaan mereka. misalnya. Anda harus mencari cara untuk menguji pengaruh perubahan struktur pada permintaan pengguna akhir tertulis dan laporan Setelah beberapa saat Anda akan membuat beberapa perubahan struktur database yang dapat mempengaruhi laporan dan query yang pengguna akhir Anda telah menulis. Ini berarti. jika Anda telah berinvestasi dalam teknologi database relasional dan multidimensi.menetapkan diri untuk membangun klon dari sistem pemrosesan transaksi disfungsional. Banyak organisasi juga memiliki alat berat dan alat yang lebih ringan yang memiliki tujuan yang sama. mungkin saya menyarankan agar Anda membuat mereka menjadi kebiasaan rumah tangga yang baik sejak dini. ini berarti menentukan jika dan ketika Anda akan memproses pembaruan sistem data warehousing. Para dependensi di DW / DSS pengolahan update dapat mendapatkan cukup kompleks. Anda akan menemukan bahwa mempertahankan arsitektur data warehouse mungkin jauh lebih sulit daripada membangun arsitektur 29 . itu adalah melemparkan-up untuk yang teknologi database akan melakukan pekerjaan yang lebih baik. Agar kebutuhan untuk kembali menguji pekerjaan mereka tidak datang sebagai kejutan terlalu buruk kepada pengguna akhir Anda. Pada tingkat yang lebih sulit. Anda harus menentukan bagaimana masalah dengan pengumpan sistem update pengolahan mempengaruhi DW / DSS sistem update pengolahan Sekali lagi. Anda akan menemukan bahwa untuk banyak aplikasi. pada tingkat teknis. jika Anda memiliki 10 sistem data warehouse Anda makan. Misalnya. Anda akan menemukan bahwa tidak jelas apa yang adalah alat yang terbaik untuk banyak aplikasi. ini berarti menentukan apakah dan bagaimana proses pembaruan parsial ke sistem pergudangan. Anda akan harus mengembangkan apresiasi apa yang harus dilakukan ketika ada masalah pengolahan dengan satu atau beberapa sistem-sistem pengumpan. Mengambil waktu untuk memahami dependensi terutama jika Anda tidak memiliki sistem pengumpan yang paling berperilaku baik.

Anda mungkin menemukan bahwa itu adalah diskusi yang sedang berlangsung tentang bagaimana untuk menangani tanggung jawab untuk rekonsiliasi rutin. orang yang menjaga matanya pada perkembangan ini harus: 1) Memiliki penilaian beberapa . Anda harus ulang bagaimana Anda telah menerapkan keamanan Sebagian besar perusahaan. Kecuali ada seseorang yang bertanggung jawab untuk menjaga matanya pada pembangunan gudang data berikutnya. Seringkali tidak ada "benar" cara untuk menangani isu-isu yang muncul dalam membandingkan sejarah. . harus melakukan yang terbaik Anda sehingga Anda tahu ada masalah. Anda. jika Anda memiliki pengguna akhir mendamaikan informasi.Dengan arsitektur. ada sekarang adalah pertanyaan tentang bagaimana. Anda akan menemukan bahwa menugaskan keamanan adalah tindakan penyeimbangan. dan sumber data untuk informasi spesifik. Jika perusahaan tiba-tiba mulai menggunakan kode "150" untuk jeruk.harapan Anda tentang apa yang harus tetap konsisten akan berubah dari waktu ke waktu 2) Mampu bekerja secara persuasif. definisi dari data yang diperoleh." Anda akan menemukan bahwa bisnis perubahan makna atribut dari waktu ke waktu dan bahwa perubahan ini dapat diabaikan Misalnya. By the way. apel dengan apel dan jeruk untuk perbandingan jeruk harus dibuat untuk tujuan sejarah. katakan bahwa Anda bekerja untuk sebuah perusahaan distribusi buah. baik. mudah untuk cepat kehilangan manfaat dari kerja keras biasanya diperlukan untuk membangun arsitektur. meskipun. beberapa kali ada kecenderungan untuk menjadi kendur dalam proses apa pun yang Anda telah menerapkan sistem untuk mendamaikan. jika data mereka sistem pergudangan yang digunakan untuk pelaporan ad hoc. Juga. Anda akan harus terus mendamaikan sistem feeder dengan DW / DSS sistem Setelah hal-hal yang berjalan lancar untuk sementara waktu. Anda ingin meminimalkan pelanggaran keamanan. akan menemukan skema keamanan mereka terlalu longgar atau terlalu ketat. Mungkin ia memiliki suatu kebijakan untuk menggunakan kategori kode "100" untuk penjualan apel dan jeruk. bukan dengan cara koersif . saya lihat konsistensi penggunaan dimensi. meskipun dimensi meja Anda perubahan mekanisme menangkap dapat menangani perubahan (saya harap Anda tahu tentang pelan-pelan berubah dimensi).data warehouse pengembang terutama membenci "arsitektur polisi. 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. nama atribut.

sistem buku besar." Jika saya mampu menulis esai pada "The Zen of Data Warehousing" (yang saya tidak akan). Jill Dyché mencatat banyak departemen TI tidak benar-benar tahu bagaimana bisnis menggunakan gudang data. saya akan mencoba untuk membuat pernyataan umum tentang penggunaan alat tersebut. Kadang-kadang tanda sebuah gudang besar adalah bahwa pengguna "menjalankannya" mereka sendiri. Namun demikian. Untuk mengkonfirmasi "jelas" 31 . Dalam esai ini. katakanlah.Anda akan harus melakukan euthanasia pada beberapa DW / DSS sistem DW / DSS sistem cenderung sering diganti. adalah mungkin untuk mendapatkan gambaran umum hanya apa alat intelijen bisnis digunakan untuk mengakses data warehouse yang digunakan untuk. mungkin sebagian besar. Mereka dijalankan untuk mengkonfirmasi seseorang yang biasanya tidak kerupuk didefinisikan gagasan namun intuitif merasa gagasan "okayness. 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. jika TI tidak tahu semua menggunakan spesifik. Anda mungkin berada dalam untuk kejutan. dari query dan laporan dibuat dengan alat intelijen bisnis. Hal ini tidak selalu buruk. aku akan mengatakan fungsi utama dari alat intelijen bisnis adalah untuk mendukung non-aksi. Anda akan merasa jauh lebih mahal (dan kompleks) untuk mempertahankan data warehouse daripada membangun satu. meskipun. Apa Business Intelligence Tools yang Digunakan untuk Pada bagian pada "rahasia kecil yang kotor dari data warehousing" dalam buku menarik nya "edata". Penggunaan utama dari alat intelijen bisnis adalah: Untuk memastikan bahwa "segala sesuatu" baik-baik saja Surprise! Tidak ada yang akan dilakukan dengan banyak. Mereka mengalami entropi jauh lebih cepat daripada. 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).

Untuk membandingkan informasi tentang pelanggan. Orang-orang mengetahui menggunakan alat sederhana untuk menyajikan informasi kepada orang lain dengan cara yang lebih mudah dibaca. rekening keuangan Kadang-kadang ini adalah sisi dengan perbandingan sisi serangkaian langkah-langkah. yang paling awal. Kadangkadang ini adalah identifikasi yang paling. paling.Kebanyakan pengguna akhir laporan dan query pada akhirnya diproduksi untuk memiliki nuansa usus cukup baik untuk apa yang terjadi di daerah mereka yang memprihatinkan. 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. Sebaliknya. yang terbaru. bisnis alat intelijen tidak mengatakan apa-apa ini orang yang luar biasa bahwa orang tidak sudah menduga. Pelanggan B biasanya membayar terlambat dan masih mengambil diskon pembayaran awal. Untuk mengidentifikasi luar biasa Biasanya konsumen akhir dari output alat itu memiliki kriteria agak kabur dari apa yang keluar dari biasa. dll Untuk membandingkan jenis informasi yang sama dalam periode waktu yang berbeda . mereka ingin memahami beberapa aspek kecil dari sebuah operasi seperti Nasabah A selalu membayar tepat waktu. produk. Namun informasi yang dihasilkan dengan alat memberi mereka rasa percaya diri merasa usus mereka baik-baik saja. Untuk mengetahui bagaimana sesuatu yang "bekerja" Kebanyakan orang tidak mencari beberapa Unified Theory grand cara kerja perusahaan XYZ. dll Untuk menyampaikan informasi dengan cara yang lebih mudah dicerna Alat ini sering digunakan untuk menyampaikan apa yang seseorang atau beberapa orang sudah tahu. biaya / keuntungan pusat.

atau beberapa jenis lain tujuan. kuota. Untuk menyiasati departemen Teknologi Informasi yang tidak memiliki waktu atau sumber daya untuk menulis laporan Seringkali pengguna akhir menggunakan alat ini keluar dari ketidaksabaran dengan departemen TI. Atau. ukuran apa yang sebenarnya terjadi dibandingkan dengan anggaran.hanya beberapa data yang kredibilitasnya harus diterima atas tindakan yang akan diambil. Untuk mengkonfirmasi dan kadang-kadang untuk menemukan tren dan hubungan Dengan segala hormat kepada orang-orang yang bekerja keras pada data mining. departemen TI memberikan pengguna alat ini untuk meringankan tekanan dari dirinya sendiri." Perhatikan mereka tidak harus setuju pada semua data . Untuk memberikan laporan "catatan" Untuk semua jenis alasan itu sering perlu bagi orang untuk setuju bahwa "ini adalah angkaangka. perbandingan tahunan. Ya. Untuk mengambil sepotong kecil informasi dari volume besar informasi Alat-alat ini membuat memilih bahwa jarum maya keluar dari tumpukan jerami maya jauh lebih sederhana. Alat bisnis intelijen melakukan fungsi mengkonfirmasi intuisi mereka. prakiraan. Untuk memeriksa kinerja dibandingkan tujuan formal dan informal atau kendala Artinya. Pengguna akhir dalam kasus ini sering menulis laporan bahwa hampir tidak bisa disebut analisis. mingguan. 33 .Ini hanyalah harian biasa. saya berpikir bahwa sebagian besar pelaku bisnis baik memiliki perasaan intuitif tren yang paling penting dan hubungan antara faktor yang mempengaruhi bisnis mereka. kuartalan. bulanan. alat ini juga dapat membantu menemukan tren dan hubungan tetapi sulit (meskipun berpotensi menguntungkan) untuk menyaring tren berarti dan palsu. bisnis alat intelijen sering digunakan untuk menghasilkan "resmi" informasi.

Untuk menyediakan data untuk bagaimana jika analisa atau prakiraan Artinya. sebagian besar alat-alat ini tidak digunakan sebagai masukan satunya untuk membuat keputusan non-sepele. Seringkali mereka cerdik digunakan untuk membantu memperkuat kasus untuk melakukan (atau tidak melakukan) sesuatu. Mereka juga tidak langsung pasokan apa yang saya akan mempertimbangkan untuk menjadi intelijen bisnis. dan kemampuan untuk menempatkan informasi yang dimuntahkan oleh alat ke dalam konteks informasi yang jauh lebih luas daripada data warehouse . transaksi sistem pengolahan. Keputusan yang dibuat dan intelijen bisnis mengumpulkan hanya dengan kombinasi output dari alat intelijen bisnis. Alat dapat melakukan beberapa apajika-ing dan peramalan sendiri namun sebagian besar pengguna bisnis lebih nyaman melakukan pekerjaan ini di spreadsheet. alat-alat yang digunakan untuk memberi makan data ke dalam spreadsheet mana yang sebenarnya apa-jika analisis atau perkiraan akan dilakukan. repositori pengetahuan dapat menangani. penilaian manusia dan intuisi. Apakah Web Analytics berbeda? Topik web analytics adalah salah satu topik yang dibahas lebih dalam niche data pergudangan / pendukung keputusan. Untuk mengulang poin yang saya telah dibuat dalam esai lain. Esai ini tidak dimaksudkan untuk menjadi primer how-to melainkan untuk meningkatkan beberapa pertanyaan dalam pikiran pembaca. Web analytics adalah proses menganalisis catatan dari apa tindakan pengguna mengambil dengan mouse dan keyboard nya saat mengunjungi sebuah situs . 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. Dalam esai ini saya ingin menantang beberapa hiperbola industri biasa.Untuk membantu advokasi posisi Alat ini tidak hanya untuk presentasi "objektif" dari fakta-fakta.

35 . Data web hanyalah salah satu sumber data . mereka adalah orang yang sangat berbeda dari analis keuangan dan pemasaran bahwa data pergudangan / keputusan pengembang pendukung digunakan untuk bekerja dengan. 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 data Orang-orang ini sulit untuk menemukan! Maaf tentang stereotip tetapi. Penerima manfaat utama dari analisis web data web designer Tidak banyak taruhan--perusahaan Anda (dan taruhan--karir Anda) keputusan akan dibuat dengan hasil analisis web data. jika data dapat ditandai seperti biasa. Pengusaha akan ingin dan paling diuntungkan dari data web yang sangat agregat yang biasanya dikombinasikan dengan non-web data Data Kebanyakan web memiliki detail jauh lebih dari pemasaran biasa atau orang keuangan ingin melihat. tidak berbasis web. data web harus peringkat di antara yang paling biasa. Di sisi lain. 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. Sebagian akan digunakan untuk membuat keputusan sedikit banyak tentang cara memodifikasi desain sebuah situs web. Bahkan. untuk non dot-com perusahaan. tidak banyak perusahaan jatuh ke dalam kategori itu).dengan kebiasaan sendiri dan dengan keterbatasan yang datang dengan semua sumber data lain Jika Anda telah bekerja dengan berbagai sumber data lain. 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. kecuali untuk dot-com. Anda mungkin tahu banyak tentang apa yang perlu Anda ketahui tentang bekerja dengan data web.Itu adalah semua itu. efek kumulatif dari keputusan-keputusan kecil mungkin perusahaan dan karir membahayakan. data web memiliki kebiasaan tapi apa data (terutama data sedetail data web mentah) tidak memiliki kebiasaan. yang sebagian besar. Dan orang-orang berpikir dalam hal kinerja relatif dari "saluran". Ya. jika perusahaan Anda adalah taruhan kelanjutan pada penggunaan pintar dari situs web (dan. Ini tidak berarti bahwa misterius.

adalah apa yang orang akan lakukan dengan data web tua. Anda dapat memberikan "real-time" akses ke data web namun pengguna Anda tidak akan mampu menganalisis secara real time Saya 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. meskipun. pada per jam berulang. (Jika Anda ingin menjadi sedikit lebih akademis. kecuali pada tingkat yang sangat agregat. Nilai data web rinci menurun cukup cepat dari waktu ke waktu Meskipun banyak data pelaksana pergudangan tidak akan mengakuinya. data yang paling kehilangan nilai dari waktu ke waktu. Dalam nada yang sama. Sekarang bayangkan apa yang akan terjadi jika pusat biaya dan hirarki pelaporan mereka akan berubah setiap hari. sulit dan mungkin berarti untuk membandingkan data yang lebih tua dengan data baru. kadang-kadang web analisis data dapat menjadi pengganti murah untuk seorang desainer web yang sangat mahal. mencurahkan analisis bermakna. Data web jauh "kotor" daripada data warehouse data biasa .) Karena situs web berubah begitu banyak.Aku tidak tahu siapa para pakar bekerja dengan tetapi kebanyakan orang yang saya temui yang menganalisis data tidak polymaths yang bisa. . Bayangkan melakukan sebuah pusat analisis biaya pengeluaran tradisional. meskipun. Apa yang saya belum membaca. nilai yang diharapkan dari penurunan data yang dari waktu ke waktu. nilai data lama web rinci meragukan Saya telah membaca publikasi memprediksi gudang berukuran petabyte bulan dan bahkan bertahun-tahun dari data web. Mungkin setiap situs web yang menghasilkan bahwa perubahan banyak data rinci sehingga sering bahwa. Ini adalah jenis apa rasanya untuk menganalisis beberapa data web. Di sisi lain. nilai dari data web menurun dengan cepat.Seringkali web hasil analisis data kesimpulan yang akan segera jelas bagi seorang desainer web yang baik Web analisis data dapat berfungsi sebagai pengganti yang sangat mahal untuk seorang desainer web yang baik.

Jika data sesi yang diambil dari beberapa server. Anda mungkin harus mengkategorikan pengguna dengan urutan mereka mengklik. mengidentifikasi urutan aktivitas pengguna di situs web. maksud saya mungkin ada banyak. Anda mungkin harus mengkategorikan halaman di situs web. dan mengidentifikasi ketika pengguna mulai dan berhenti melihat sebuah situs web. Informasi ini juga harus berkorelasi dengan analisis file log. Ini kategorisasi bisa jadi sangat kabur. Jika situs Anda menghasilkan halaman secara dinamis.Data web sering menimbulkan masalah dengan mengidentifikasi pengguna situs web. meskipun tidak persis kategorisasi. Dengan itu.ketika pengguna mulai dan berhenti mengakses situs web. banyak cara untuk mengkategorikan tanpa alasan kuat untuk menggunakan salah satu metode kategorisasi atas yang lain. Juga. Data mungkin memiliki kesenjangan atau data mungkin menjadi tersangka. Web Data bergantung pada beberapa kategorisasi yang cukup kabur Semua yang Anda ketahui tentang pengguna situs web adalah (apa yang Anda pikirkan adalah) urutan klik nya. 37 . Jika halaman terdiri dari daerah yang dihasilkan secara dinamis beberapa. Anda mungkin memiliki masalah yang unik Jika jam server 'tidak benar-benar (!) Di sync. Anda akan memiliki waktu yang sulit melacak aktivitas pengguna. 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 kosong Sekarang ada kesadaran bahwa banyak penghakiman yang hanya dapat diberikan oleh manusia diperlukan untuk untuk bekerja data yang paling pertambangan. mengidentifikasi apa yang dilihat. Definisi sesi bisa sembarangan. Banyak dari masalah ini tidak dipecahkan diberikan tujuan desain dari sebuah situs web. Juga. Anda mungkin harus menulis sistem Anda sendiri untuk melacak konten dinamis. Seperti yang dapat Anda bayangkan. Untuk membuat ini masuk akal data. semua masalah dengan data web membuat lebih sulit untuk melakukan tugas-tugas penilaian bahwa perangkat lunak tidak bisa lakukan. Anda juga harus mendefinisikan "sesi" . maka Anda memiliki masalah yang lebih rumit.

adalah palsu. Juga. . nilai marjinal analisis tambahan bisa turun cukup cepat. Anda menemukan Anda melakukan ini dengan menganalisis klik dari pelanggan yang meninggalkan situs tanpa membeli. Mereka mengatakan bahwa pada beberapa titik dalam segmentasi pasar sebenarnya mungkin untuk mendapatkan hasil marginal negatif. dalam istilah akademis yang lebih. . beberapa ahli yang seharusnya publikasi saya telah membaca telah mempertanyakan efektivitas halus segmentasi pasar (yang di pasar paling ekstrim adalah segmentasi untuk satu orang). Analisis pola mengklik. bisa sangat diperdebatkan. Beberapa penulis pemasaran telah mempertanyakan efektivitas sangat ditargetkan pemasaran beberapa upaya perusahaan melalui analisis web Meskipun saya tidak mengklaim menjadi ahli pemasaran. Anda mendapatkan sedikit informasi yang biasanya tidak besar. halaman terakhir seseorang mengklik seharusnya penting untuk menganalisis. Ingat. 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 web Kecuali pengguna situs web telah membeli sesuatu dari situs ini. Meskipun tampaknya berlawanan. jauh lebih efektif dapat ditindaklanjuti oleh pengamatan perilaku kelompok bukan oleh pengamatan perilaku individu. seperti yang disebutkan sebelumnya. Anda perlu mengkombinasikan data web dengan data dari internal dan eksternal (seperti dan Equifax.Seringkali analisis sepintas web data yang menghasilkan sebagian besar dari nilai yang dapat diperoleh dari analisis data Atau. (Saya membaca bahwa informasi pendaftaran kebanyakan.) Dan bahkan jika pengguna situs telah membeli sesuatu.Pada kenyataannya. biasanya satu-satunya hal yang Anda tahu tentang pelanggan non polanya mengklik. Data web tidak memberikan informasi yang banyak tentang mengapa seseorang tidak menjadi pelanggan Ketika Anda membaca bahwa data web seharusnya untuk membantu Anda menemukan mengapa seseorang tidak pelanggan. jika diberikan. Saya menafsirkan tulisan-tulisan mereka berarti bahwa pemasar harus rendah hati tentang pemahaman mereka tentang perilaku konsumen. dll) non-Web data belajar sesuatu tentang pengguna situs web. Anda tahu sedikit tentang pengguna situs.

Artinya. data analisis web harus dilakukan secara cerdas. Tapi seperti semua aplikasi lain dari data warehousing / pendukung keputusan. Web analisis data bisa sangat menguntungkan. dan membuat keputusan kami pada berapa banyak kita ingin menganalisis dengan mata untuk manfaat marjinal diharapkan versus biaya marjinal yang diharapkan. 39 . jujur mengakui masalah data kita tidak bisa menyelesaikan atau sebagian dapat memecahkan. kita harus tahu siapa kita yang sebenarnya adalah pengguna.Esai ini tidak dimaksudkan untuk menghalangi orang dari menganalisis data web.

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->