Optimasi Entity Relationship Diagram
Optimasi adalah mengupayakan sesuatu yang sudah kita rancang yang kemudian nantinya dapat menjadi lebih baik. Pada prinsipnya Optimasi adalah untuk meminimalisir adanya penambahan kolom dan tabel pada sebuah sistem. Optimasi memiliki dua tujuan :
1. Efisien
Adalah sesuatu yang dapat kita lakukan agar sebuah data base kita menjadi lebih efisien. Dalam hal ini penyimpanan akan lebih sederhana, lebih kecil, sehingga performa ketika kita melakukan penarikan data menjadi lebih baik. Apa yang dapat kita lakukan agar data base kita menjadi efisien :
a. Menambahkan Entitas Lemah (Weak Entity)
b. Menambahkan Kode (Kunci Alternatif)
Contoh Kasus :
Entitas Mahasiswa : NIM, Nama, Alamat, Asal Sekolah, Alamat Sekolah, JK, Agama
Tabel Mahasiswa
| NIM | Nama | ... | Asal Sekolah | Alamat Sekolah |
|---|---|---|---|---|
| 111 | Putu | ... | SMKN 1 Denpasar | Jl. Cokroaminoto No.84 |
| 112 | Kadek | ... | SMKN1Denpasar | Jl. Cokroaminoto No.84 |
| ... | ... | ... | ... | ... |
| 199 | Ketut | ... | SMKN1Denpasar | Jl. Cokroaminoto No.84 |
Dengan ditemukannya baris data berulang-ulang pada tabel mahasiswa, yaitu data dari atribut Asal Sekolah dan Alamat Sekolah perlu dilakukan penambahan entitas lemah dengan nama entitas sekolah.
Entitas Sekolah : Nama Sekolah, Alamat Sekolah
Untuk dapat berelasi dengan entitas mahasiswa maka perlu menambahkan atribut primary key pada entitas sekolah, atribut tersebut adalah Kode Sekolah sehingga menjadi :
Entitas Sekolah : Kode Sekolah, Nama Sekolah, Alamat Sekolah
Sehingga relasi yang terjadi adalah Mahasiswa memiliki Sekolah, dengan derajat kardinalitas banyak (Many) ke satu (One) :
a. Satu mahasiswa memiliki satu sekolah
b. Satu sekolah dimiliki banyak mahasiswa
Hasil akhir :
Mahasiswa : NIM, Nama, Alamat, JK, Agama
memiliki
Entitas Sekolah : Nama Sekolah, Alamat Sekolah
Data yang ditemukan berulang-ulang tidak lagi ditulis, sehingga cukup menuliskan/menginputkan sekali saja pada tabel sekolah tersebut.
2. Fleksibilitas
Ketika kita membuat sebuah sistem, terkadang kita tidak bisa membuat hal tersebut betul-betul sesuai dengan apa yang dibutuhkan pada masa yang akan datang. Sebagai contoh pada sebuah sistem yang saat ini setiap kebutuhannya terpenuhi, kemudian ketika adanya sebuah kebijakan maka kebutuhan tersebut tidak dapat terpenuhi kembali. Hal tersebut mengakibat perlunya penambahan tabel dan sebagainya. Dalam hal ini perlu kita memikirkan sistem tersebut dapat berkembang dan beradaptasi dengan adanya kebijakan-kebijakan tersebut. Berikut ini yang dapat dlakukan ketika terdapat perubahan kebijakan sehingga data base masih dapat berfungsi dengan baik :
a. Penambahan atribut
Contoh :
Entitas KRS : NIM, Kode Matkul, Nilai
| NIM | Kode Matkul | Nilai |
|---|---|---|
| 111 | MKU-17502 | A |
| 112 | MKP-17502 | B |
Jika sebuah entitas disimpan dengan atribut seperti tabel diatas maka yang terjadi adalah penyimpanan berlaku untuk satu semester saja. Sehingga perlu penambahan atribut tahun dan semester untuk dapat menentukan tahun dan semester dari masing-masing record data tersebut.
Entitas KRS : Tahun, Semester, Kode Matkul, Nilai
| Tahun | Semester | NIM | Kode Matkul | Nilai |
|---|---|---|---|---|
| 2022 | I | 111 | MKU-17502 | A |
| 2022 | I | 112 | MKP-17502 | B |
b. Pemilihan domain atribut yang lebih luas
Contoh :
Jaman dahulu programer membuat sistem dengan dua digit huruf tahun, yaitu 97,98,99 dengan maksud menulis tahun, 1997, 1998, 1999. Kemudian masalah yang muncul adalah ketika tahun 2000. Sistem akan membaca tahun tersebut menjadi 00 yang kemudian berlanjut menjadi minus, sehingga kebanyakan sistem pada saat itu tidak bisa jalan. Masalah ini dahulu disebut dengan Year 2 kilo (Y2K) atau Millenium Bug . Dengan masalah tersebut menjadi perhatian semua programer saat untuk menyimpan domain atribut tahun menjadi lebih luas, sehingga dapat menyimpan data menjadi lebih lama.
Contoh lain adalah pemilihan tipe atribut dalam suatu sistem penjumlahan, antara tipe data integer (bersifat bulat) dan numerik. Lebih baik memilih numerik sehingga data yang disimpan dapat menghasil koma dan tidak bilangan bulat saja.
c. Melakukan generalisasi
Contoh :
Pada sistem perpustakaan, terdapat beberapa entity dengan relasi masing-masing dengan privilege berbeda-beda. Buku dipinjam oleh mahasiswa ataupun buku dipinjam oleh dosen. Bagaimana jika suatu saat ada sebuah kebijakan yang tidak hanya membatasi peminjaman terhadap buku kepada mahasiswa dan dosen saja? peminjaman dikembangkan kepada masyarakat umum, siswa, dan guru. Sehingga sistem perlu dikembangkan terus dan dibongkar ulang lagi untuk penambahan entitas tersebut. Disitulah yang disebut dengan sistem tidak end user computing bergantung pada programer yang mengembangkan.
Untuk mengantisipasi hal tersebut perlu dilakukan generalisasi (dibuat umum) terhadap entitas mahasiswa, dosen, masyarakat umum, siswa, dan guru menjadi entitas Anggota, sehingga relasi yang terjadi adalah buku dipinjam oleh anggota. Selanjutnya muncul pertanyaan bagaimana kita membedakan privilege yang terjadi pada setiap anggota? Maka perlu penambahan entitas lagi dengan nama Jenis, relasi yang terjadi adalah anggota memiliki jenis. Untuk atribut dari entitas jenis tersebut adalah privilege yang membedakan setiap jenis anggota, misalnya : kode jenis, nama jenis, lama meminjam, denda, maksimal meminjam.
d. Perubahan struktur entitas dari yang berbasis kolom ke yang berbasis baris
Contoh :
Pada sistem perpustakaan, terdapat entitas sirkulasi yang berisi atribut ID sirkulasi, tanggal pinjam, ID Anggota, ID Buku 1, ID Buku 2, dan ID Buku 3 seperti pada tabel dibawah ini :
Bagaimana solusi ketika ada perubahan kebijakan seperti itu tidak harus melakukan perubahan terhadap tabelnya? Maka perlu dibuat dua buah tabel. Yang pertama adalah tabel sirkulasi seperti pada gambar dibawah ini :
Post a Comment for "Optimasi Entity Relationship Diagram"