Perancangan Database: Langkah 8 Dalam Siklus Hidup Proyek Pengembangan BI

Tahap 4: Perancangan

Langkah 8: Perancangan Database/Data warehouse

Berbagai aktivitas dalam perancangan database/data warehouse
Aktivitas-aktivitas dalam Perancangan Database/Data warehouse. [Baca dan bandingkan juga: Siklus Hidup Pengembangan Sistem Basis Data]

Aktivitas-aktivitas dalam desain database tidak harus dilakukan secara linear. Gambar di samping menunjukkan aktivitas mana saja yang dapat dilakukan secara bersamaan. Berikut dibawah ini adalah daftar deskripsi singkat mengenaik aktivitas-aktivitas yang berkaitan dengan langkah 8, yaitu perancangan database.

1. Review-lah berbagai requirements untuk akses data

Administrator database harus mereview akses data dan berbagai requirements analisa (reports, queries, dsb), yang dianalisa dan difinalisasi pada langkah 6, yaitu: membuat prototype aplikasi. Administrator database juga harus mereview hasil prototype bersama dengan si pemimpin developer aplikasi untuk membantu menentukan skema desain yang paling sesuai untuk database target BI.

Baca juga dan bandingkan:

2. Tentukan berbagai requirements untuk agregasi dan summarisasi.

Sebelum melakukan skema desain final untuk database target BI, administrator database perlu untuk memfinalisasi berbagai requirements agregasi dan summarisasi data dengan perwakilan orang-orang bisnis dan pemimpin deveoper aplikasi. Berilah perhatian khusus pada pertumbuhan/ledakan agregasi dan summarisasi data dan pertumbuhan/ledakan data secara umum. Orang-orang bisnis sering meminta data hanya untuk "berjaga-jaga" mungkin mereka akan membutuhkannya nanti suatu hari, dan kemudian mereka jarang menggunakannya, jika pernah.

3. Desain database target untuk BI.

Klaim yang sangat luas bahwa semua aplikasi BI hanya tentang analisa multidimensi dan pelaporan multidimensi tidaklah benar! Sebagai contoh, beberapa analis keuangan (para ahli statistik) yang memberi laporan ke CFO atau CEO akan dengan tegas menyatakan kebutuhan mereka seperti ini: "Saya harus mampu untuk mengajukan pertanyaan tentang data secara rinci dengan cara apapun. Jangan mencoba untuk memasukkan saya ke kotakdengan pola-pola pelaporan yang telah ditentukan. Saya tidak mau!" Analis-analis seperti ini perlu fleksibilitas total untuk membuat query ad-hoc terhadap data rinci historikal dan selalu bersedia untuk memberikan kinerja tinggi, bahkan meskipun itu berarti bahwa query-query mereka akan dijalankan selama berjam-jam atau semalam. Meskipun analis jenis ini adalah minoritas, tetapi orang-orang seperti pasti ada, dan Anda harus mempertimbangkan requirements mereka untu akses data. Oleh karena itu, meskipun desain database target BI Anda akan berdasarkan pada skema multidimensinal, beberapa akan berdasarkan pada skema ER (entity-realationship). Desain database didokumentasikan sebagai model data fisikal.

Berbagai requirement untuk akses data dan berbagai requirements untuk agregasi data dan summarisasi data akan menentukan desain database yang paling tepat. Jika ada pola pelaporan yang jelas atau jika requirements meminta adanya kemampuan untuk analisa slice-and-dice, maka desain database yang paling tepat adalah yang multidimensi. Jika tidak ada requirements pelaporan dan jika si analis bisnis bersikeras bahwa mereka membutuhkan akses ad hoc data rinci mereka, maka desain yang paling tepat adalah desain ER, yang lebih banyak normalisasi dan sedikit atau bahkan tidak ada agregasi atau summarisasi.

Ini bukan hanya dua skema desain yang berlaku untuk database BI. Untuk beberapa jenis requirements akses dan analisa, desain hybrid mungkin adalah yang paling tepat.

4. Desain struktur database fisikal.

Clustering, partitioning, indexing, danmenempatkan dataset dengan tepat adalah empat karakteristik yang paling penting pada desain database fisikal. Administrator database harus mengelompokkan (cluster) tabel-tabel yang paling sering digunakan untuk mengurangi pergerakan disk-arm. Administrator database juga harus menentukan di mana menempatkan dataset dan bagaimana mempartisi tabel di beberapa disk. Akhirnya, admininstrator database harus memilih strategi indeks yang diterapkan pada database.
Video tentang desain database

5. Buat/Membangun database target BI.

Database fisikal dibuat/dibangun ketika DDL (Data Definition Language) dijalankan pada DBMS. Administrator database menggunakan DDL untuk menggambarkan struktur database (misalnya, storage groups, partisi database, dsb) ke DBMS.

Keamanan database dibuat bila DCL (Data Control Language) dijalankan pada DBMS. Dalam database relasional standar, keamanan diberlakukan pada level tabel atau view. Karena sifat alami database BI adalah dimensional, kemampuan untuk menelusuri ke data secara detail, kadang-kadang lintas database, menyajikan risiko keamanan seringkali diabaikan.

Berikan otorisasi database baik kepada individu maupun kelompok dimana -individu-individu tersebut sudah ditetapkan. Mengelola keamanan pada tingkat individu bisa dengan cepat menjadi mimpi buruk bagi proses maintenance, itulah sebabnya mengapa sebagian besar organisasi memilih untuk mengatur 'group ID'. Setiap 'group ID' diberikan beberapa bentuk akses untuk 'create', 'read', 'update', 'delete' (CRUD) ke tabel. Audit trail kemudian bisa menunjukkan "user ID" di 'group ID' mana yang mengakses database. Jika ada pelanggaran keamanan, "penyusup" sering ditemukan melalui jejak audit ini.

6. Buatlah/develop prosedur untuk maintenance database.

Setelah database masuk ke dalam produksi, akan sangat penting untuk menyediakan waktu untuk mengambil backup database atau me-reorganisasi tabel-tabel yang terfragmentasi. Oleh karena itu, tetapkan prosedur untuk mengatasi fungsi-fungsi maintenance database.

7. Persiapkan untuk memantau dan tune desain basis data.

Setelah aplikasi BI diimplementasikan, database target BI harus dipantau dan di-tune. Desain database terbaik tidak menjamin kinerja yang baik terus menerus, sebagian karena tabel-tabel menjadi ter-fragment dan sebagian karena penggunaan aktual dari database target BI berubah seiring waktu. Pantaulah kinerja query pada saat runtime dengan utilitas/tool performance-monitoring yang memiliki kemampuan diagnostik. Ini tidak membantu untuk mengetahui kinerja yang telah menurun tanpa mengetahui penyebabnya. Mendiagnosis masalah kinerja biasanya jauh lebih sulit daripada menemukan masalahnya.

8. Persiapkan untuk memantau dan tune desain query.

Karena kinerja merupakan suatu tantangan pada aplikasi BI, Anda harus menjelajahi semua trik pertukaran/modifikasi untuk mengatasi masalah ini. Eksekusi query parallel adalah salah satu trik yang bisa meningkatkan kinerja query.

Seri Siklus Hidup Proyek Pengembangan BI (Business Intelligence):
Kategori: ,

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)