xAda beberapa teknologi database seperti: Flat File database, Hierarchical database, Network database, Relational database, Object

Oriented database dan Multimedia database, Web datatabase dan Data warehouse. Berikut ini paparan mengenai trend teknologi database tersebut. 1. Flat File Database file data pada spreadsheet (misal MS Excel), berupa satu file berisi baris-baris dengan jumlah kolom tetap yang disimpan berurutan dalam file. Jenis database ini populer penggunaannya pada tahun 1960 - 1980an. Kelemahan dari database flat file antara lain: Timbulnya data rangkap (redundancy data) dan Ketidakkonsistensi data (Inconsistency data) => file-file tersebut disusun oleh orang yang berbeda, sehingga sejumlah informasi dimungkinkan memiliki duplikasi data => pemboro san tempat penyimpanan dan bertambahnya biaya akses & inkonsistensi data. Misalnya, apabila terjadi perubahan sedangkan perubahan hanya diperbaiki pada file master dan tidak diperbaiki pada file transaksi lainnya. Kesukaran dalam Mengakses Data => sejumlah file disimpan pada media dan komputer yang berbeda sehingga bila membutuhkan data dengan segera diperlukan waktu untuk pencarian. Data terisolir (Isolation Data) => data tersebar dalam berbagai file, dan file-file tersebut disimpan dalam format yang berbeda, sehingga akan menyebabkan data terisolasi. Masalah Pengamanan (Security Problem) => file disimpan ditempat berbeda dan memiliki hak askes yang berbeda. 2. Hierarchical Database => populer tahun 1970 - 1990an. Dalam model ini, data direpresentasikan sebagai record dan link, dan record di oranisasikan sebagai struktur Tree (pohon). Model ini memiliki kelemahan yaitu : redudansi data pada record derajat berikutnya. Contoh: data pegawai yang mengambil diklat, record diklat harus ditulis ulang ketika diambil oleh pegawai yang berbeda. Fleksibilitas dalam menambah dan menyisipkan record baru => rendah dan kompleks => pemograman sangat kompleks, meskipun sebenarnya proses pengorganisasian data pada model ini efisien. y Network Database => populer pada tahun 1970 - 1990an. Data direpresentasikan dengan sekumpulan record, dan relasi antara data direpresentasikan oleh record dan link. Link dipandang sebagai pointer. Record-record diorganisasikan sebagai graf/ring. Contoh : model relational direpresentasikan dalam model network. Model ini memiliki kekurangan-kekurangan, antara lain: Tidak memungkinkan terjadinya relasi banyak-ke-banyak (many-to-many). fleksibilitas dalam menambah dan menyisipkan record baru sangat rendah dan kompleks => pemograman sangat kompleks, meskipun efisiens dalam proses pengorganisasian data dan menjamin tidak terjadinya redudansi.

3. Relational Database => berisi kumpulan tabel. setiap tabel mempunyai nama dan struktur yang unik. Dalam setiap tabel, masing-masing record data diorganisasikan dalam struktur yang sama dan memiliki field kunci yang akan menjadi penghubung antar tabel yang ada dan berkait satu sama lain. Pada model ini, data terorganisir dengan baik dan rapi sehingga dapat dengan mudah dimanipulasi untuk menghasilkan suatu informasi. Relational database mulai populer penggunaannya pada tahun 1980 sampai dengan sekarang. Model ini masih dipakai sampai dengan sekarang karena model ini memberikan kelebihan tersendiri dibandingkan dengan model-model sebelumnya, antara lain: Kemudahan dalam pembentukan struktur data masing-masing file. Kompleksitas untuk mengaitkan antar tabel tidak terjadi karena hubungan antar tabel ditentukan oleh field kunci (primary key) yang telah ditetapkan sebagai penghubung file. Pemograman menjadi sederhana, sedangkan tingkat fleksibilitas dalam mengorganisasikan data sangat tinggi. Kelebihan lainnya adalah independensi data dimana jika ada perubahan atau manipulasi data pada tabel master tidak berpengaruh pada tabel transaksi. Akses data lebih efisien sehingga performa akses data menjadi lebih cepat. Jaminan terhadap integritas dan keamanan data. Administrasi data menjadi lebih mudah. Berkurangnya waktu yang diperlukan dalam pengembangan aplikasi. 4. Object Oriented dan Multimedia Database Object Oriented Database (OOD) mulai dikembangkan pada tahun 1990 dan digunakan sampai dengan sekarang. OOD merupakan tanggapan terhadap perkembangan teknik pemograman berorientasi objek yang menekankan pada objek, atribut dan metode. OOD dikembangkan untuk menjawab permasalahan pada model relational database, antara lain: relational database tidak mampu menangani kebutuhan data yang kompleks dan aplikasi relational database lebih banyak membutuhkan kinerja yang tinggi. Dalam beberapa hal, teknik OOD ini sangat berbeda dengan sistem database yang dikenal sebelumnya. Namun kini juga mulai dikembangkan perpaduan antara OOD ini dengan model Relational Database. Sementara itu, perkembangan teknologi multimedia telah memungkinkan pemasukan data berupa gambar, grafik, audio, animasi dan video. Tampaknya kebutuhan untuk pengolahan database berbasis multimedia ini dapat teratasi dengan adanya OOD. Web Database Pada sistem Web yang statis, halaman Web hanya berfungsi untuk menyajikan informasiinformasi kepada user/pengguna. Sementara itu, penambahan fasilitas seperti video atau audio dapat membuat halaman Web tampak seperti dinamis. Sedangkan, untuk membuat Web yang bersifat interaktif, diperlukan fasilitas yang dapat menerima respon dari pengguna. Pembangunan Web yang interaktif dilakukan dengan mengintegrasikan halaman web dan Database Management Systems (DBMS). Untuk melakukannya, ada beberapa persyaratan dasar (Oetomo,2002) yang harus dipenuhi, antara lain:

1) Database tidak terikat oleh Web browser dan Web server tertentu dalam penyajiannya. 2) Adanya jaminan keamanan dalam melakukan akses data. 3) Pendekatan terhadap arsitektur sistem terbuka, artinya harus dapat mendukung interoperabilitas, seperti Web server yang berbeda, Distributed Common Object Model/Common Objec Model (DCOM/COM), Corba/Inter-ORB Protocol (IIOP) dan Java. 4) Overhead aplikasi yang minimal. Disamping persyaratan dasar tersebut, ada dua macam pilihan arsitektur Web-DBMS, yaitu: 1) Arsitektur tradisional Two Tiers Pada Arsitektur tradisional Two Tiers, Client berlaku sebagai tier-1 yang bertanggung jawab terhadap presentasi data kepada para pengguna, sedangkan server berlaku sebagai tier-2 yang bertanggung jawab untuk menyuplai layanan data kepada Client. Arsitektur Two Tier dikenal juga sebagai arsitektur Client-Server. 2) Arsitektur Three Tiers Arsitektur Three Tiers merupakan perbaikan dari Arsitektur Two Tiers. Pada Arsitektur Three Tiers, client berlaku sebagai tier-1 yang bertanggung jawab terhadap presentasi data kepada para pengguna. Application server berlaku sebagai tier-2 yang mengerjakan pemrosesan data dengan logika atau prosedur yang telah ditentukan, sedangkan Database Server berlaku sebagai tier-3 yang bertanggung jawab untuk menyuplai layanan data kepada Application Server. Proses kerja model arsitektur ini dimulai ketika Client meminta (request) informasi ke Application Server, lalu Aplication Server mengolah permintaan Client dengan mengambil atau menyimpan data dari/ke Database Server; Database Server mengembalikan informasi ke Application Server; Application Server mengembalikan informasi ke Client. Arsitektur Three Tiers ini dikembangkan karena keterbatasan pada arsitektur Two Tiers, yaitu jika ada perubahan fungsi suatu komponen pada satu sisi akan mempengaruhi kedua sisi yaitu Client dan Server. Hal ini tidak terjadi pada sistem Three Tiers. Arsitektur Three Tiers digunakan ketika diperlukan suatu rancangan Client-Server yang efektif, dimana dapat meningkatkan kinerja, fleksibilitas, kemudahan perawatan, kemampuan untuk digunakan ulang, dan skalabilitas. Berikut gambaran model arsitektur Three Tiers.

5. Model Web-DBMS ini masih dalam pengembangan, yang tentu saja masih mengandung beberapa kelemahan, seperti sistem keamanan database yang efektif, biaya overhead, keterbatasan fungsi dari bahasa pemograman yang digunakan dan unjuk kerja dari aplikasi yang telah dihasilkan. Namun demikian, model ini telah memberikan harapan untuk menciptakan halaman Web yang interaktif. Data Warehouse Data warehouse adalah suatu konsep dan kombinasi teknologi yang memfasilitasi organisasi untuk mengelola dan memelihara data historis yang diperoleh dari sistem atau
3

aplikasi operasional. Data warehouse mengumpulkan data historis yang kemudian dapat disajikan sebagai bahan komprehensif bagi manajemen untuk dapat mengambil keputusan, analisis kebutuhan organiasi, hingga peramalan kondisi organisasi berdasar data. Dengan data warehouse, seorang manajer dapat melihat trend yang terjadi untuk untuk meningkatkan kualitas dalam pengambilan keputusan dan terhindar dari resiko yang tidak diinginkan. Konsep dan teknologi Data warehouse tidak dapat diterapkan dalam satu langkah, berikut beberapa tahapan penerapan data warehouse tanpa mengganggu sistem atau aplikasi yang sudah ada (Ferdiana, 2008). 1) Melakukan penyalinan dan konversi data dari aplikasi atau sistem yang sudah ada menjadi satu jenis basis data. Langkah ini dikenal dengan Offline Operasional Database. 2) Melakukan penyalinan dan konversi data secara regular dalam jangka waktu yang telah ditentukan dari aplikasi atau sistem yang sudah ada menjadi satu jenis basis data. Mekanisme ini dilakukan dalam interval waktu tertentu dengan dukungan otomatisasi yang dimiliki oleh aplikasi teknologi data warehouse. Langkah ini dikenal dengan Offline Data warehouse. 3) Melakukan penyalinan dan konversi data secara real time atau dengan kata lain otomatisasi dilakukan setiap kali terjadi perubahan pada data dari aplikasi atau sistem yang sudah ada. Langkah ini dikenal dengan Real Time Data Warehouse. 4) Melakukan penyalinan dan konversi data secara real time atau dengan kata lain otomatisasi dilakukan setiap kali terjadi perubahan pada data dari aplikasi atau sistem yang sudah ada. Setiap terjadi perubahan data baik pada data warehouse maupun pada data operasional aplikasi keduanya saling mensinkronisasi. Langkah ini dikenal dengan Integrated Data Warehouse. Beberapa kelebihan dengan penggunaan teknologi data warehouse ini, antara lain: a) Data warehouse menghadirkan solusi satu pintu pengaksesan data. Pengguna tidak harus mengakses data dari sistem yang terpisah, data dapat diakses melalui satu akses sistem yang sama. b) Data warehouse menghadirkan manajemen data yang lebih terintegrasi dan memiliki skalabilitas tinggi dari sisi ketersediaan data suatu organisasi. c) Data warehouse memberikan solusi analisis historis suatu data, analisis histori suatu
4

data dapat membantu organisasi untuk melihat trend data yang membantu organisasi dalam memberi keputusan organiasional yang bergantung pada data. d) Data warehouse memberikan solusi pengambilan keputusan yang melibatkan banyak sistem dan aplikasi tanpa mengganggu proses yang terjadi pada operasional sistem yang bersangkutan. e) Data warehouse menghadirkan konsistensi data yang membantu bagi manajemen untuk melakukan peramalan forecasting kondisi organisasional berdasar pada data historis yang konsisten. Data warehouse dapat menjadi salah satu solusi organisasional dengan skala menengah untuk mengatur dan mengelola data historis perusahaan menjadi asset yang berperan dalam pengambilan keputusan, pembuatan pelaporan, hingga analisis ke depan. Dalam pembangunan sistem database, seorang analis sistem juga harus dapat menentukan model arsitektur sistem database mana yang akan digunakan. Arsitektur sistem database dapat dikategorikan menjadi tiga menurut penempatannya, yaitu: 1. Sistem Database Tunggal Pada arsitektur ini, database dan aplikasi diletakkan pada komputer yang sama dan tidak berada dalam lingkungan jaringan, sehingga database hanya dapat diakses oleh aplikasi tunggal (stand alone). Sistem ini biasanya digunakan pada organisasi berskala kecil. Gambar berikut mengilustrasikan sistem database tunggal.

2. Sistem Database Terpusat Pada arsitektur ini, lokasi database secara fisik berada pada komputer pusat dalam suatu lingkungan jaringan. Meskipun input dan akses data dilakukan dari terminal yang terhubung ke komputer tersebut dan pemrosesan pengolahan data hanya berlangsung di komputer pusat. Dengan sistem ini, komputer pusat menjadi titik kritis dari proses pengolahan database. Bila komputer pusat terganggu, maka secara keseluruhan sistem informasi tersebut akan terganggu. Gambar berikut mengilustrasikan sistem database terpusat.

3. Sistem Database Terdistribusi Pada arsitektur ini, salinan database, baik sebagian maupun secara keseluruhan, terdistribusi di beberapa lokasi. Pada model ini, titik kritis pada sistem terpusat dapat dihindari. Namun pada sistem ini, tantangan terbesar yang dihadapi adalah proses pengintegrasian untuk menjaga konsistensi data yang tersebar di beberapa lokasi. Berikut
5

gambaran mengenail sistem database terdistribusi. Lebih lanjut, beberapa komponen sistem database yang diperlukan dalam pengembangan sistem database, yaitu: Repositori - pusat penyimpanan data. Database Management System (DBMS) - perangkat lunak untuk mengelola database. Database - pusat penyimpanan data. Program Aplikasi - perangkat lunak pengguna data. User Interface - fasilitas interaksi antara pengguna dan data secara tekstual atau grafis. CASE Tools - Computer - Aided Software Engineering. Administrator Data - personil yang bertanggung-jawab memelihara database. Developer Sistem - personil yang bertanggung-jawab merancang program aplikasi beserta struktur datanya dalam database. End User - orang yang menggunakan aplikasi dan database.

PERENCANAAN DATA WAREHOUSE

1) Get Professional Advice 2) Plan the Data proses bisnisnya Pastikan data yang diperlukan untuk analisa harus tersedia sesuai dengan

3) Who will use the Data Warehouse biasanya pengguna data adalah level manager ke atas. Data yang tersedia harus cukup atraktif dan mudah difahami dengan cepat. 4) Integration to external applications. DW harus mampu mengekstrak data dari semua aplikasi eksternal yang ada dalam perusahaan 5) Pemilihan teknologi. Anda bisa memilih teknologi yang berasal dari DBMS (Data Base Managenement Systems) vendors seperti Oracle, IBM, Microsoft, OpenSource data bases seperti SQL.

PROYEK DATA WAREHOUSE

y y y y

Needs Gathering Physical Environment Setup Data Modeling ETL

6

y y y y y y y y y

OLAP Cube Design Front End Development Report Development Performance Tuning Query Optimization Quality Assurance Rolling out to Production Production Maintenance Incremental Enhancements

Setiap halaman yang tercantum di atas merupakan data warehouse tahap desain khas, dan memiliki beberapa bagian:
y y y

Task Description : Bagian ini menjelaskan apa yang biasanya harus dilakukan selama tahap gudang data desain tertentu. Time Requirement : Sebuah perkiraan kasar dari jumlah waktu ini data warehouse mengambil tugas tertentu. Deliverables : Biasanya pada akhir setiap tugas data warehouse, satu atau lebih dokumen akan diproduksi untuk menjelaskan langkah-langkah dan hasil dari tugas tertentu. Hal ini terutama penting bagi konsultan untuk mengkomunikasikan hasilnya kepada klien. Possible Pitfalls : Hal-hal yang harus diperhatikan. Adalah beberapa hal yang jelas tapi ada juga tidak begitu jelas. Tapi semuanya nyata.

NEEDS GATHERING Hal pertama yang tim proyek harus lakukan adalah mengumpulkan kebutuhan dari pengguna akhir. Pengguna akhir biasanya tidak akrab dengan proses atau konsep DW, Needs gathering ini bisa dilakukan dengan melakukan pertemuan dengan end users Tujuan utama dari tahap ini adalah untuk mengidentifikasi setiap keberhasilan dari setiap tahap dalampengembangan DW. Time Requirement Waktu Kebutuhan 2 - 8 weeks. 2 - 8 minggu. Deliverables
y y

Sebuah daftar laporan untuk disampaikan kepada pengguna akhir pada akhir fase saat ini. Sebuah rencana proyek diperbarui yang jelas mengidentifikasi beban sumber daya dan tonggak tanggal pengiriman.

Kemungkinan Pitfalls Ini merupakan fase yang paling rumit dari implementasi DW. Masalahnya adalah sering terjadi konflik kepentingan dari setiap departemen dalam penentuan needs dari masing masing departemen yang akan di-input ke dalam DW.

PENGATURAN LINGKUNGAN FISIK Diperlukan untuk mengatur server fisik dan database. Setidaknya, perlu untuk dibangun sebuah development environment dan production environment. Dalam proyek DW terdapat tiga lingkungan fisik: Development , testing , dan production. Tidaklah cukup untuk hanya memiliki lingkungan fisik yang terkoordinasi.. Proses yang terkait dengan lingkungan fisik(seperti ETL, OLAP Cube, dan pelaporan) juga perlu dikoordinir dengan benar untuk masing-masing lingkungan. Idealmya untuk setiap lingkungan fisik ialah menggunakan aplikasi dan server database yang berbeda satu sama lain. Memiliki lingkungan yang berbeda adalah sangat penting karena alasan berikut:
y y y

Semua perubahan dapat diuji tanpa mempengaruhi lingkungan produksi. Development dan jaminana mutu bisa terjadi selama pengguna mengakses DW. Ketika ada pertanyaan tentang data, dengan memiliki lingkungan yang terpisah (s) akan memungkinkan tim DW memeriksa data tanpa mempengaruhi lingkungan produksi.

Time Requirement Mendapatkan server dan database siap harus memakan waktu kurang dari 1 minggu. Deliverables
y

Hardware / Software akan meng-setup setiap dokumen untuk semua lingkungan, termasuk spesifikasi perangkat keras, dan skrip / pengaturan untuk perangkat lunak.

Possible Pitfalls Kemungkinan Pitfalls Untuk menghemat modal, sering tim DW akan memutuskan untuk hanya menggunakan database tunggal dan server tunggal untuk lingkungan yang berbeda.. Hal ini bermasalah karena alasanalasan berikut: 1. Kadang-kadang server perlu di-reboot untuk Development Environment. Memiliki Development environment yang terpisah akan mencegah lingkungan produksi dari gangguan akibat rebooting. 2. Mungkin ada interferensi ketika memiliki lingkungan database yang berbeda di satu kotak. Sebagai contoh, query pada development database dapat mempengaruhi kinerja pada database produksi.

DATA MODELLING
8

Dasar dari sistem data warehouse adalah model data. Sebuah model data yang baik akan memungkinkan sistem DW untuk tumbuh dengan mudah, serta memungkinkan untuk kinerja yang baik. Dalam proyek data warehouse proyek, model data logis dibangun berdasarkan kebutuhan pengguna, dan kemudian diterjemahkan ke dalam model data fisik. Data-data fisik ini harus konseptual dan logis, Bagian tersulit dalam pemodelan data adalah identifikasi sumber data. Kadang-kadang hal ini ditangguhkan sampai proses ETL selesai. tapi jika ini terjadi, maka kalau ada kesalahan dalam pemodelan proses perbaikannya akan lebih sulit Time Requirement 2 - 6 minggu. Deliverables Deliverables
y y y

Identification of data sources. Logical data model. Physical data model

Possible Pitfalls Kemungkinan Pitfalls Sangat penting untuk memiliki ahli subjek-materi sebagai bagian dari tim pemodelan data. Dia bisa seorang konsultan ataupun seorang staff ahli dari perusahaan. Tanpa orang ini, menjadi sulit untuk mendapatkan jawaban yang pasti dari banyak query ETL Proses ETL (Extraction, Transformation, Loading) biasanya waktu terpanjang dalam pengembangan proyek DW. Ini terjadi karena dibutuhkan waktu lama untuk mendapatkan sumber data, memahami kolom yang diperlukan, memahami aturan bisnis, dan memahami data logis dan fisik model. Time Requirement 1 - 6 weeks. Deliverables
y y

Data Mapping Document ETL Script / ETL Package in the ETL tool

Possible Pitfalls Kemungkinan Pitfalls

Pihak managemen sering memberikan waktu yang terlalu singkat untuk penyelesaianproyek ini. Yang kedua adalah proses ETL sering dibuat lebih rumit dari yang diperlukan. Dalam desain ETL, hal penting adalah optimasi tanpa mengortbankan kwalitas OLAP CUBE Sering terjadi user memiliki ide tentang apa yang mereka inginkan tapi tak mampu menjelaaskan secara rinci tentang report atau analisis yang ingin mereka lihat. Karena itu berikan informasi yang cukup jelas tapi ringkas. Data warehouse merupakan proses berulang-ulang tidak ada seorang pun dapat memenuhi semua keinginannya sekaligus. Time Requirement Waktu Kebutuhan 1 - 2 weeks. 1 - 2 minggu. Deliverables Deliverables
y y

Dokumentasi apa saja yang menentukan dimensi dan ukuran kubus OLAP. Actual OLAP cube / report.

Possible Pitfalls Kemungkinan Pitfalls Pastikan Anda proses pembangunan kubus OLAP dioptimalkan.. Hal yang umum bagi data warehouse untuk mendapatkan loading data dalam bentuk batch yang penuh sehingga setelah loading tak banyak waktu untuk melekukan refresh - OLAP. Akibatnya, tidak ada salahnya untuk mencoba jalur-jalur pengembangan kubus OLAP untuk memastikan kinerja yang optimal.

FRONT END DEVELOPMENT Terlepas dari kekuatan mesin OLAP dan integritas data, jika USER tidak dapat memvisualisasikan laporan, data gudang HANYALAH NOL BELAKA. Maka pembangunan front end adalah bagian penting dari sebuah data warehouse Yang paling penting adalah bahwa laporan harus perlu disampaikan melalui web, sehingga satusatunya hal kebutuhan pengguna adalah browser standar. The front-end options ranges from an internal front-end development using scripting languages such as ASP, PHP, or Perl, to off-the-shelf products such as Seagate Crystal Reports, to the more higher-level products such as Actuate. Pilihan front-end berkisar dari pembangunan front-end internal dengan menggunakan bahasa scripting seperti ASP, PHP, atau Perl. Banyak OLAP vendor menawarkan front-end sendiri. When choosing vendor tools, make sure it can be easily customized to suit the enterprise, especially the possible changes to the reporting requirements of the enterprise. Ketika memilih vendor tools, pastikan sesuai dengan kebutuhan perusahaan,
10

terutama dengan kemungkinan adanya perubahan persyaratan sistim pelaporan perusahaan. For example, if the enterprise decides to change from Solaris/Oracle to Microsoft 2000/SQL Server, will the front-end tool be flexible enough to adjust to the changes without much modification? Misalnya, jika perusahaan memutuskan untuk mengubah dari Solaris / Oracle ke Microsoft 2000/SQL Server, apakah front-end toolmya cukup fleksibel untuk menyesuaikan diri dengan perubahan tanpa banyak modifikasi? Misalnya, apakah laporan harus diterbitkan dengan interval teratur? Apakah ada persyaratan format yang sangat spesifik? Apakah ada kebutuhan untuk antarmuka GUI sehingga setiap pengguna dapat menyesuaikan laporan nya? Time Requirement Waktu Kebutuhan 1 - 4 weeks. 1 - 4 minggu. Deliverables Deliverables Front End Deployment Documentation Front End Deployment Dokumentasi Possible Pitfalls Kemungkinan Pitfalls End users tidak peduli seberapa kompleks atau majunya teknologi infrastruktur front end Anda. Yang mereka peduli adalah bahwa mereka menerima informasi mereka secara tepat waktu dan dalam cara mereka yang ditentukan REPORT DEVELOPMENT One would think that report development is an easy task. Orang akan berpikir bahwa pembangunan laporan adalah tugas yang mudah. How hard can it be to just follow instructions to build the report? Bagaimana bisa keras itu hanya mengikuti instruksi untuk membangun laporan? Unfortunately, this is not true. Sayangnya, hal ini tidak benar. There are several points the data warehousing team need to pay attention to before releasing the report. Ada beberapa hal bagi tim DW tim untuk diperhatikan sebelum merilis laporan. User customization : Apakah pengguna perlu untuk dapat memilih metrik mereka sendiri? Bagaimana pengguna harus dapat menyaring informasi? The report development process perlu menjadikan faktor-faktor di atas menjadi pertimbangan sehingga pengguna bisa mendapatkan informasi yang mereka butuhkan dalam waktu sesingkat mungkin. Report delivery : Apa metode penyampaian laporan yang dibutuhkan? Selain menyampaikan laporan ke ujung depan web, kemungkinan lain termasuk pengiriman melalui email, melalui pesan teks, atau dalam beberapa bentuk spreadsheet. There are reporting solutions in the marketplace that support report delivery as a flash file.. Such flash file essentially acts as a minicube, and would allow end users to slice and dice the data on the report without having to pull data from an external source..
11

Access privileges : Special attention needs to be paid to who has what access to what information. A sales report can show 8 metrics covering the entire company to the company CEO, while the same report may only show 5 of the metrics covering only a single district to a District Sales Director. Report development does not happen only during the implementation phase.. After the system goes into production, there will certainly be requests for additional reports.. These types of requests generally fall into two broad categories:: 1. 1. Data is already available in the data warehouse. In this case, it should be fairly straightforward to develop the new report into the front end. There is no need to wait for a major production push before making new reports available. 2. 2. Data is not yet available in the data warehouse.. This means that the request needs to be prioritized and put into a future data warehousing development cycle.. Time Requirement 1 - 2 weeks.. Deliverables Deliverables
y y y

Report Specification Documentation. Reports set up in the front end / reports delivered to user's preferred channel.

Possible Pitfalls Kemungkinan Pitfalls Make sure the exact definitions of the report are communicated to the users. Otherwise, user interpretation of the report can be errenous.. TUNING KINERJA There are three major areas where a data warehousing system can use a little performance tuning:
y

ETL - Given that the data load is usually a very time-consuming process (and hence they are typically relegated to a nightly load job) and that data warehousing-related batch jobs are typically of lower priority, that means that the window for data loading is not very long. ETL -. A data warehousing system that has its ETL process finishing right on-time is going to have a lot of problems simply because often the jobs do not get started ontime due to factors that is beyond the control of the data warehousing team. As a result, it is always an excellent idea for the data warehousing group to tune the ETL process as much as possible. Query Processing - Sometimes, especially in a ROLAP environment or in a system where the reports are run directly against the relationship database, query performance can be an
12

issue. A study has shown that users typically lose interest after 30 seconds of waiting for a report to return. Experience has been that ROLAP reports or reports that run directly against the RDBMS often exceed this time limit, and it is hence ideal for the data warehousing team to invest some time to tune the query, especially the most popularly ones. Report Delivery - It is also possible that end users are experiencing significant delays in receiving their reports due to factors other than the query performance. For example, network traffic, server setup, and even the way that the front-end was built sometimes play significant roles. It is important for the data warehouse team to look into these areas for performance tuning.

Time Requirement Waktu Kebutuhan 3 - 5 days. 3 - 5 hari. Deliverables Deliverables

y

Performance tuning document - Goal and Result

Possible Pitfalls Kemungkinan Pitfalls Make sure the development environment mimics the production environment as much as possible - Performance enhancements seen on less powerful machines sometimes do not materialize on the larger, production-level machines. Having long-running queries not only consumes system resources that makes the server and application run slowly, but also may lead to table locking and data corruption issues. So, query optimization becomes an important task. Jadi, optimasi query menjadi tugas penting. First, we offer some guiding principles for query optimization: OPTIMALISASI QUERY 1. 1. Understand how your database is executing your query Pahami bagaimana database Anda adalah mengeksekusi permintaan Anda Nowadays all databases have their own query optimizer, and offers a way for users to understand how a query is executed. For example, which index from which table is being used to execute the query? Sebagai contoh, yang indeks dari tabel yang sedang digunakan untuk mengeksekusi query? The first step to query optimization is understanding what the database is doing. Different databases have different commands for this. For example, in MySQL, one can use "EXPLAIN [SQL Query]" keyword to see the query plan.. In Oracle, one can use "EXPLAIN PLAN FOR [SQL Query]" to see the query plan.. 2. 2. Retrieve as little data as possible

13

The more data returned from the query, the more resources the database needs to expand to process and store these data. So for example, if you only need to retrieve one column from a table, do not use 'SELECT *'. '* SELECT' 3. 3. Store intermediate results Store antara hasil Sometimes logic for a query can be quite complex.. Often, it is possible to achieve the desired result through the use of subqueries, inline views, and UNION-type statements. For those cases, the intermediate results are not stored in the database, but are immediately used within the query. This can lead to performance issues, especially when the intermediate results have a large number of rows. The way to increase query performance in those cases is to store the intermediate results in a temporary table, and break up the initial SQL statement into several SQL statements. In many cases, you can even build an index on the temporary table to speed up the query performance even more. Granted, this adds a little complexity in query management (ie, the need to manage temporary tables), but the speedup in query performance is often worth the trouble. Below are several specific query optimization strategies. Di bawah ini adalah beberapa pertanyaan yang spesifik strategi optimasi.
y

y y

Use Index Using an index is the first strategy one should use to speed up a query. In fact, this strategy is so important that index optimization is also discussed. Aggregate Table Tabel Agregat Pre-populating tables at higher levels so less amount of data need to be parsed.. Vertical Partitioning Partisi Vertikal Partition the table by columns.. This strategy decreases the amount of data a SQL query needs to process. Horizontal Partitioning Partisi horizontal Partition the table by data value, most often time. This strategy decreases the amount of data a SQL query needs to process. Denormalization Denormalization The process of denormalization combines multiple tables into a single table. This speeds up query performance because fewer table joins are needed. Server Tuning Tuning server Each server has its own parameters, and often tuning server parameters so that it can fully take advantage of the hardware resources can significantly speed up query performance.

14