AGREGASI BASIS DATA
PROSES LANJUTAN
Sebuah diagram E-R yang telah mengakomodasi semua fakta yang ada, bisa saja telah dianggap selesai untuk selanjutnya diimplementasikan. Akan tetapi, sebenarnya kita dapat melakukan berbagai proses lanjutan (perubahan diagram E-R) yang mengarah pada penyempurnaan dan optimasi model data karena pertimbangan-pertimbangan efisiensi ruang atau kecepatan dan kemudahan pengaksesan data.
- Key Alternatif (Alternate Key)
Kita telah ketahui key suatu himpunan entitas/relasi dipilih dari atribut yang dapat menjamin keunikan entitas. Sebuah key dapat dikategorikan baik, jika ia berukuran kecil dan sekuensial. Semakin kecil ukurannya dan semakin berurutan nilai-nilainya diantara entitas-entitas yang ada, maka semakin baik key tersebut.
- Pengkodean Internal
Data/informasi yang dapat dilihat oleh pemakai awam (end-user) bisa berbeda dengan bagaimana data/informasi itu disimpan. Itulah yang dikenal sebagai Abstraksi Data. Apa yang dilihat oleh pemakai awam bisa jadi merupakan hasil pengolahan yang tidak disimpan sama sekali dalam basis data. Atau bisa pula, dinyatakan dalam bentuk lain. Salah satu alasan mengapa kita menyatakan suatu data (atribut) dalam bentuk lain adalah untuk efisiensi rung penyimpanan. Dan cara yang ditempuh untuk menyatakan suatu data dalam bentuk lain itu adalah melaui pengkodean (data coding).
Dari pemakaiannya, kita bisa membedakan adanya pengkodean eksternal (user-defined coding) dan pengkodean internal (system coding). Pengkodean eksternal mewakili pengkodean yang telah digunakan secara terbuka dan dikenal dengan baik oleh para pemakai awam (end-user). Namun, yang perlu diingat, pengkodean internal tidak hanya dapat diterapkan pada pembuatan key alternative, tapi juga diterapkan pada atribut data lain (non-key) yang memang kita kelola.
Ada 3 (tiga) bentuk pengkodean yang dapat kita pilih, yaitu:
- Sekuensial
Dimana pengkodean dilakukan dengan mengasosiasikan data dengan kode terurut (biasanya berupa bilangan asli atau abjad), misalnya data nilai mutu kuliah (‘Sempurna’,’Baik’,’Cukup’,’Kurang’,’Buruk’) dikodekan dengan ‘A’,’B’,’C’,’D’ dan ‘E’.
- Mnemonic
Dimana pengkodean dilakukan dengan membentuk suatu singkatan dari data yang ingin dikodekan, misalnya data jenis-kelamin (‘Laki-laki’ dan ‘Perempuan’) dikodekan dengan ‘L’ dan ‘P’.
- Blok
Dimana pengkodean dinyatakan dalam format tertentu, misalnya data no.induk mahasiswa dengan format XXYYYY yang terbentuk atas XX=dua dijit terakhir, angka tahun masuk dan YYYY=no.urut mahasiswa.
- Dekomposisi Himpunan Entitas dan Normalisasi
Sebuah himpunan entitas yang ada dalam sebuah diagram E-R dapat kita dekomposisi menjadi beberapa himpunan entitas baru karena pertimbangan efisiensi ruang penyimpanan atau karena pertimbangan kemudahan/kecepatan pengaksesan data. Upaya dekomposisiini senantiasa akan menghasilkan satu himpunan entitas kuat (strong entity set) dan satu atau beberapa himpunan entitas lemah atau sub entitas.
Secara umum ada dua bentuk dekomposisi himpunan entitas, yaitu:
- Dekomposisi Atribut (Dekomposisi Vertikal).
- Dekomposisi Entitas (Dekomposisi Horisontal).
Dekomposisi merupakan langkah yang lazim dilakukan dalam rangka penerapan aturan Normalisasi pada tabel-tabel basis data. Dalam prakteknya, dekomposisi himpunan entitas disini juga disemangati (banyak dipengaruhi) oleh upaya penerapan aturan Normalisasi tersebut terhadap himpunan entitas yang ada dalam Diagram E-R.
- Dekomposisi Atribut (Dekomposisi Vertikal)
Dikomposisi ini akan dilakukan dengan cara membagi sebuah himpunan entitas menjadi dua atau lebih dengan pemisahan atribut.
- Dekomposisi Enitas (Dekomposisi Horizontal)
Dekomposisi ini dilakukan dengan cara membagi sebuah himpunan entitas menjadi dua atau lebih dengan pemisahan entitas.
- Fleksibilitas
Dalam perancangan basis data, perlu pula dipertimbangkan adanya faktor fleksibilitas. Factor ini memang bukan factor utama, tapi seringkali pula menjadi salah satu parameter untuk menentukan bagus/tidaknya sebuah desain basis data. Pertimbangan tentang efisiensi ruang penyimpanan dan dukungan pada kecepatan akses data menjadi lebih baik. Namun kualitas desain basis data yang paling baik adalah yang juga mempertimbangkan factor fleksibilitas ini. Sayangnya, pengakomodasian factor ini, dalam banyak keadaan, berbanding terbalik dengan pertimbangan tentang efisiensi ruang penyimpanan dan kecepatan akses. Artinya, demi fleksibilitas, kita akan membutuhkan ruang penyimpanan yang lebih besar dan bentuk pengaksesan yang lebih kompleks (sehingga waktu aksesnya bisa menjadi lebih lama).
Desain basis data yang telah kita buat, barangkali memang telah cukup memadai dengan kondisi saat ini. Seringkali desain basis data itu kita bangun berdasarkan sejumlah asumsi atau fakta-fakta (hasil analisis) yang berhasil kita kumpulkan. Asumsi biasanya menyederhanakan kenyataan sesungguhnya atau meniadakan anomali-anomali yang ada. Fakta-fakta yang bisa kita kumpulkan sekarang bisa saja berbeda dengan apa yang kita temukan pada kurun waktu yang akan dating. Padahal, dalam sebuah pembangunan sistem informasi, pembuatan desain basis data dilakukan diawal pekerjaan. Berikutnya setelah desain itu jadi, barulah tahap penulisan aplikasi (coding) dilakukan. Akan menjadi fatal akibatnya, jika pekerjaan pembangunansistem informasi yang telah selesai ternyata tidak memadai untuk mengelola data/informasi saat itu, karena kondisinya ternyata telah berbeda dengan kondisi pada waktu desain basis data dibuat. Hal yang sama bahkan dapat pula terjadi tidak lama setelah pemakaian aplikasi. Karena itulah, factor fleksibilitas ini menjadi penting. Fleksibilitas dalam desain basis data perlu dipertimbangkan untuk mengantisipasi kondisi-kondisi yang menurut perhitungan kita bisa saja terjadi pada sekian waktu yang akan datang.
Fleksibilitas dalam desain basis data dapat direalisasikan dalam bentuk:
- Penambahan atribut.
- Pemilihan domain atribut yang lebih luas (direalisasikan pada tahap implementasi).
- Generalisasi.
- Perubahan struktur entitas dari yang berorientasi-kolom (column oriented).
- Penambahan Atribut
Fleksibilitas basis data dapat dilakukan dengan menyediakan sejumlah atribut cadangan/tambahan untuk mengantisipasi kebutuhan yang saat ini belum jelas/ada, tetapi mungkin terjadi pada masa yang akan datang.
- Pemilihan Domain Atribut yang Lebih Luas (direalisasikan pada tahap implementasi)
- Generalisasi
- Perubahan Struktur Entitas dari yang Berorientasi Kolom (column-oriented) menjadi Berorientasi Baris (row-oriented)
Bentuk fleksibilitas semacam ini akan selalu ‘mengorbankan’ kemudahan/kecepatan akses data. Untuk menampung semua fakta yang mungkin, kita akan melengkapi himpunan entitas dan relasi dengan atribut-atribut yang kita butuhkan. Akan tetapi, ada kalanya tidak semua entitas membutuhkan semua atribut-atribut tersebut, atau yang lebih fatal jika di saat yang akan datang, ada kebutuhan penyimpanan data yang tidak terantisipasi dengan keberadaan atribut-atribut tersebut.
Source :
http://chyntea.blogspot.com/2009/01/agregasi.html
0 komentar