BAB 4 PERANCANGAN DATABASE
Merancang Database merupakan suatu hal yang sangat penting. Kesulitan utama datam merancang database adalah bagaimana merancang sehingga database dapat memuaskan keperluan saat ini dan masa mendatang. Perancangan model konseptual perlu dilakukan di samping perancangan model phisik. Pada perancangan konseptual akan menunjukkan entity dan relasinya berdasarkan proses yang diinginkan oleh organisasi.
Merancang Model Konseptual Database
Tugas Database Administrator adalah merancang model konseptual database. Model konseptual :
Bukanlah pendekatan proses informasi seorang programmer aplikasi, tetapi merupakan kombinasi beberapa cara untuk memproses data untuk beberapa aplikasi.
Tidak tergantung pada aplikasi individual.
Tidak tergantung pada DBMS yang digunakan.
Tidak tergantung pada hardware yang digunakan.
Tidak tergantung pada phisikal model.
Tidaklah perlu dipikirkan tentang terapan dan operasi yang akan dilakukan pada database.
Pada perancangan model konseptual penekanan tinjauan dilakukan pada struktur data dan relasi antara file. Pendekatan yang dilakukan pada perancangan model konseptual adalah menggunakan model data relational.
Terdapat dua buah teknik yaitu:
• Teknik Normalisasi
• Teknik Entity Relationship
Teknik Normalisasi
Proses normalisasi adalah proses pengelompokan data elemen menjadi tabel tabel yang menunjukkan entity dan relasinya. Pada proses normalisasi selalu dilakukan pengujian database pada beberapa kondisi, antara lain:
menambah/ insert
menghapus/ delete
mengubah/ update
membaca/ retrieve
Bila ada kesulitan pada pengujian tersebut maka relasi tersebut dipecahkan pada beberapa tabel lagi atau dengan kata lain perancangan belumlah menghasilkan database yang optimal.
Beberapa konsep yang harus diketahui lebih dahulu yang berhubungan dengan normalisasi, yaitu:
Field/ atribute kunci
Kebergantungan fungsi (functional dependency)
Field/atribute kunci
Key(Kunci)
Setiap file/tabel selalu terdapat kunci dari file/tabel berupa satu field atau satu set field yang dapat mewakili record. Misalnya nomor pegawai merupakan kunci dari tabel pegawai suatu
perusahaan, setiap pencarian cukup dengan menyebut nomor pegawai tersebut maka dapat diketahui nama, alamat dan atribute lainnya mengenai seorang pegawai tersebut. Jadi Key adalah satu atau gabungan dari beberapa atribut yang dapat membedakan semua baris data (row) dalam table secara unik.
Macam-macam Filed/attribute kunci:
Candidate Key (Kunci Kandidat/Kunci Calon)
Primary Key (Kunci Primer)
Alternate Key (Kunci Alternatif)
Foreign Key (Kunci Tamu)
Candidate Key (Kunci Kandidat/Kunci calon)
Kunci kandidat adalah satu atribute atau satu set minimal atribute yang mengidentifikasikan secara unik suatu kejadian spesific dari entity. Jika satu kunci kandidat berisi lebih dari satu atribute, maka biasanya disebut sebagai composite key (kunci campuran/ gabungan).
Contoh:
File Pegawai berisi attribute:
No Induk Pegawai (NIP)
No KTP
Nama
Tempat Lahir
Tanggal Lahir
Alamat
Kota
Kunci kandidat disini adalah:
No Induk Pegawai (NIP), karena unik tidak mungkin ganda.
No KTP, karena unik tidak mungkin ganda.
Nama, sering dipakai sebagai kunci pencarian namun tidak dapat
dikatakan kunci karena sering seseorang punya nama yang sama.
Nama + Tanggal lahir, mungkin dapat dipakai sebagai kunci karena
kemungkinan sangat kecil seseorang punya nama sama yang lahir
pada hari yang sama.
Nama + tempat lahir + tanggal lahir, dapat dipakai sebagai kunci
Alamat, kota (bukan kunci).
Primary Key (Kunci primer)
Primary Key adalah satu atribute atau satu set minimal atribute yang tidak hanya mengidentitikasi secara unik suatu kejadian spesific, tapi juga dapat mewakili setiap kejadian dari suatu entity. Setiap kunci kandidat punya peluang menjadi primary key, tetapi sebaiknya
dipilih satu saja yang dapat mewakili secara menyeluruh terhadap entity yang ada.
Contoh:
No Induk (NIP), karena unik tidak mungkin ganda dan mewakili
secara menyeluruh terhadap entity Pegawai, dan setiap pegawai selalu
punya nomor induk
No KTP, ini hanya dipakai bila sampai dengan pembayaran gaji
pegawai ternyata nomor induk belum keluar.
NIP Nama_Pegawai Tgl_Lahir Alamat
2001 Anton 12-12-76 Solo
2002 Budi 02-02-75 Yogya
2003 Anton 11-11-76 Semarang
Alternate Key (Kunci alternatif)
Alternate Key adalah kunci kandidat yang tidak dipakai sebagai primary key. Kerap kali kunci alternatif dipakai sebagai kunci pengurutan dalam laporan.
Contoh: Kunci Alternatif untuk pengurutan
Kunci alternatif
NIP Nama_Pegawai Tgl_Lahir Alamat
2001 Anton 12-12-76 Solo
2002 Budi 02-02-75 Yogya
2003 Anton 11-11-76 Semarang
Sehingga:
NIP Nama_Pegawai Tgl_Lahir Alamat
2001 Anton 12-12-76 Solo
2003 Anton 11-11-76 Semarang
2002 Budi 02-02-75 Yogya
Foreign Key (Kunci Tamu/Asing)
Foreign Key adalah satu atribute (atau satu set atribute) yang melengkapi satu relationship (hubungan) yang menunjukkan ke induknya. Kunci tamu ditempatkan pada entity anak dan sama dengan kunci primary induk direlasikan.
Contoh:
Tabel Pegawai
NIP Nama_Pegawai Tgl_Lahir Alamat
2001 Anton 12-12-76 Solo
2002 Budi 02-02-75 Yogya
2003 Anton 11-11-76 Semarang
Tabel Golongan
Golongan Gaji_Pokok Tunjangan
1 1000000 100000
2 2000000 200000
3 3000000 300000
Tabel GAJI
No_Slip NIP Golongan Gaji_Kotor Pajak Gaji_Bersih
S001 2001 1 1100000 5% 1045000
S002 2002 2 2200000 10% 1980000
S003 2003 2 2200000 10% 1980000
Keterangan:
Primary Key: NIP(table Pegawai), Golongan (Tab. Golongan), SLIP (Tab.
Gaji)
Foreign Key: NIP, Golongan (pada table GAJI)
Dalam hal hubungan dua buah file yang punya relationship banyak lawan
banyak maka terdapat 2 buah kunci tamu pada file konektornya.
Contoh:
File Proyek berisi atribute
• Nomor Proyek
• Tgl Mulai
• Tgl Selesai
• Anggaran
File Pegawai berisi atribute
• No Induk
• Nama
Hubungan antara file tersebut adalah banyak lawan banyak yaitu satu Pegawai mengerjakan lebih dari 1 proyek dan satu proyek dikerjakan oleh beberapa pegawai maka untuk menunjukkan hubungan tersebut dipakai file konektor yang berisi kunci tamu dari kedua file.
File Proyek_Pegawai berisi atribute
Nomor Proyek
NIP
Jam Kerja (proyek tersebut dikerjakan oleh pegawai ter-tentu selama
sekian jam kerja)
Maka pada file Proyek_Pegawai terdapat kunci tamu yaitu Nomor
Proyek dan NIP. Kedua atribute tersebut juga merupakan kunci
primary.
Ketergantungan Fungsi (Functional Dependency)
Definisi dari functional dependence adalah:
Diberikan sebuah relasi R, atribute Y dari R adalah bergantung fungsi pada atribute X dari R jika dan hanya jika setiap nilai X dalam R punya hubungan dengan tepat satu nilai Y dalam R (dalam setiap satu waktu).
Pada tabel relasi Pegawai berisi attribute :
NIP
Nama
Tempat Lahir
Tanggal Lahir
Alamat
Kota
Isi dari atribute Nama bergantung pada NIP. Jika Anda mengetahui NIP pegawai, maka Anda dapat menentukan Nama pegawai tersebut. Notasi untuk kebergantungan fungsi ini adalah:
NIP -> Nama
atau
Nama = F(Noinduk)
Bentuk Bentuk Normalisasi
Pada proses normalisasi ini perlu dikenal dahulu definisi dari tahap normalisasi.
1. Bentuk tidak normal (Unnormalized Form) Bentuk ini memiliki ciri-ciri, yaitu :
Merupakan kumpulan data yang akan direkam
Tidak ada keharusan mengikuti suatu format tertentu
Dapat saja data tidak lengkap atau terduplikasi
Data dikumpulkan apa adanya sesuai dengan kedatangannya.
2. Bentuk Normal Kesatu (1NF/ First Normal Form) Bentuk normal ke satu mempunyai ciri yaitu:
Setiap data dibentuk dalam flat file (file data/ rata)
Data dibentuk dalam satu record demi satu record dan nilai dari field field berupa "atomic value".
Tidak ada set atribute yang berulang ulang atau atribute bernilai ganda (multivalue).
Tiap field hanya satu pengertian, bukan merupakan kumpulan kata yang mempunyai arti mendua, hanya satu arti saja dan juga bukanlah pecahan kata kata sehingga artinya lain.
Misalnya:
KELAS(Kode_kelas,nama_kelas,instruktur)
merupakan bentuk 1NF karena tidak ada yang berganda dan tiap atribute satu pengertian yang tunggal.
Contoh Data:
Kode_kelas Nama_kelas Instruktur
1234 FisikaDasar Suroso
1543 Matematika Paulus
1775 Teknik Program Bagus
SISWA(No_siswa, Nama, Wali_studi, Kelas1, Kelas2, Kelas3)
Siswa yang punya nomor siswa, nama dan wali studi mengikuti 3 mata pelajaran/ kelas. Disini ada perulangan kelas 3 kali ini bukan bentuk 1 NF.
Contoh Data:
No_siswa Nama Wali_studi Kelas-l Kelas2 Kelas3
22890100 Tanzania Zaman 1234 1543
22890101 Nia Rizki 1234 1775 1543
Bentuk normal kesatu dari bentuk diatas menjadi:
No_siswa Nama Wali_studi Kode_kelas
22890100 Tanzania Zaman 1234
22890100 Tanzania Zaman 1543
22890101 Nia Rizki 1234
22890101 Nia Rizki 1775
22890101 Nia Rizki 1543
3. Bentuk Normal Kedua (2NF/ Second Normal Form)
Bentuk normal kedua mempunyai syarat yaitu:
Bentuk data telah memenuhi kriteria bentuk normal kesatu.
Atribute bukan kunci haruslah bergantung secara fungsi pada kunci
utama/ primary key.
Sudah ditentukan kunci kunci field, dimana kunci field haruslah unik
dan dapat mewakili atribute lain yang menjadi anggotanya.
Dari contoh relasi SISWA pada bentuk normal kesatu, terlihat bahwa:
kunci utama/ primary key adalah nomor siswa.
Nama siswa dan Wali_studi bergantung fungsi pada No_siswa, tetapi kode_kelas bukanlah fungsi dari SISWA maka file SISWA dipecah menjadi 2 relasi yaitu:
Relasi SISWA
No_siswa Nama Wali_studi
22890100 Tanzania Zaman
22890101 Nia Rizki
Relasi AMBILKELAS
No_siswa Kode_kelas
22890100 1234
22890100 1543
22890101 1234
22890101 1775
22890101 1543
4. Bentuk Normal Ketiga (3NF/Third Normal Form)
Untuk menjadi bentuk normal ketiga maka relasi haruslah dalam bentuk normal kedua dan semua atribute bukan primer tidak punya hubungan yang transitif. Dengan kata lain, setiap atribute bukan kunci haruslah bergantung hanya pada primary key dan pada primary key secara menyeluruh.
Contoh pada bentuk normal kedua di atas termasuk juga bentuk normal ketiga karena seluruh atribute yang ada disitu bergantung penuh pada kunci primernya.
Penerapan Bentuk Normalisasi
Proses perancangan database dapat dimulai dari dokumen dasar yang dipakai dalam sistem.
PT SANTA PURI FAKTUR PEMBELIAN BARANG
Jalan Senopati 11
Yogyakarta
Kode Supplier: S02 Tanggal: 02/02/90
Nama Supplier: Gobel Nustra Nomor : 779
Kode
Nama Barang
Qty
Harea
Jumlah
R02
RICE COOKER CC3
10.0
150.000, 00
1. 500.000,00
Total Faktur
1. 500.000,00
Jatuh Tempo Faktur: 09/03/90
PT SANTA PURI FAKTUR PEMBELIAN BARANG
Jalan Senopati 11
Yogyakarta
Kode Supplier: G01 . Tanggal: 07/02/90
Nama Supplier: Gobel Nustra Nomor : 998
Kode
Nama Barang
Qty
Harea
Jumlah
A01
A02
AC SPLIT 1/2 PK AC
SPLIT 1 PK
10.0
10.0
1,350,000
2,000,000
13,500,000
20,000,000
Total Faktur
33,500,000
Jatuh Tempo Faktur: 09/03/90
1. Step I bentuk unnormalized
Bentuklah menjadi tabel unnormalized, dengan mencantumkan semua field data yang ada Menuliskan semua data yang akan direkam Terlihat record record yang tidak lengkap, sulit untuk membayangkan bagaimana bentuk record yang harus dibentuk untuk merekam data tersebut.
2. Step II bentuk normal kesatu
Bentuklah menjadi bentuk normal kesatu dengan memisah misahkan data pada field field yang tepat dan bernilai atomic, juga seluruh record harus lengkap adanya. Bentuk file adalah flat file.
Kelemahan-kelemahan bentuk normal kesatu yaitu:
a. Inserting/ penyisipan
Kita tidak dapat memasukkan kode dan nama supplier saja tanpa ada transaksi pembelian, sehingga supplier baru dapat masuk bila ada transaksi pembelian.
b. Deleting/ Penghapusan
Bila satu record di atas dihapus misalnya nomor factur 779, maka berakibat pula menghapus data supplier S02 (Hitachi), padahal data supplier masih diperlukan.
c. Updating/ Pengubahan
Kode dan nama supplier terlihat ditulis berkali kali, bila suatu ketika terjadi perubahan nama supplier misalnya maka harus mengganti disemua record yang mengandung nama tersebut. Bila ada yang terlewat maka membuat data tidak konsisten lagi.
d. Redundancy
Field jumlah di atas merupakan redundancy, karena setiap kali harga dikalikan dengan quantitas akan menghasilkan jumlah. Maka field tersebut dapatlah dibuang, bila tidak dibuang maka mengakibatkan tidak konsisten. Tidak konsisten disini disebabkan karena bila ada perubahan harga, hanya data harga yang diubah, data jumlah tidak maka nilai jumlah tidak sama dengan qty x harga.
3. Step III bentuk normal kedua
Pembentukan bentuk normal kedua dengan mencari kunci kunci field yang dapat dipakai sebagai patokan dalam pencarian dan sifatnya unik. Melihat kondisi dari permasalahan factur di atas dapat diambil kunci kandidat yaitu:
No factur (no fac)
Kode supplier
Kode barang
Bentuklah tiga tabel dengan kunci tersebut, lihatlah ketergantungan fungsional field field lain terhadap field kunci, maka didapatkan tabel sebagai berikut: Dengan pemecahan seperti di atas maka sebagian dari pertanyaan pengujian pada bentuk normal kesatu yaitu inserting, deleting, updating dapat terjawab. Kode dan nama supplier baru dapat masuk kapanpun tanpa harus ada transaksi pada tabel Nota, cukuplah dibuka tabel Supplier dan disisipkan satu record baru. Demikian pula pada saat update dan delete baik untuk tabel Supplier dan juga
tabel Barang. Namun permasalahan masih ada yaitu pada tabel Nota.
Field Qty dan Harga pada tabel tersebut tidak bergantung penuh pada kunci primer nomor nota, ia juga bergantung fungsi pada kode barang. Hal ini disebut sebagai kebergantungan yang transitif dan haruslah dipisahkan dalam dua tabel.
Masih terdapat redundancy yaitu setiap kali satu nota yang terdiri dari 5
macam barang yang dibeli maka 5 kali pula dituliskan no nota, tanggal nota, tempo, dan totai. Ini harus pula dipisahkan bila terjadi penggandaan tulisan berulang ulang.
4. Step IV Bentuk Normal Ketiga
Bentuk normal ketiga mempunyai syarat setiap tabel tidak mempunyai field
yang bergantung transitif, harus bergantung penuh pada kunci utama. Maka terbentuklah tabel sebagai berikut:
5. Step V Pengujian dengan data contoh
Pengujian disini untuk memastikan kebenaran isi tabel dan hubungan antar tabel tersebut. Ujilah bahwa setiap tabel haruslah punya hubungan dengan tabel yang lainnya. Bila tidak ada penghubunga antar tabel maka dapat dikatakan perancangan untuk membuat satu database adalah gagal.
6. Step VI Hubungan relasi antar label
Gambarkan hubungan relasi antar file yang ada Pengertian relasi di atas adalah
a. Satu supplier punya banyak nota
Nota punya relasi terhadap supplier dan dalam hal ini tidaklah dapat dibalik supplier punya relasi terhadap nota.
b. Satu nota punya bebebrapa transaksi barang
c. Satu barang terjadi beberapa kali transaksi pembelian barang.
7. Step VII Kelengkapan field field dalam perancangan
Permasalahan di atas hanya mengacu pada satu dokumen Factur pembelian barang, padahal pada kenyataan sesungguhnya tentulah factur tersebut punya dokumen pelengkap misalnya Nota Penjualan Barang, Laporan Stock barang Laporan Penjualan, Laporan pembelian dan masih banyak laporan dan dokumen data entry lainnya. Lewat step step perancangan seperti di atas maka diperoleh field field untuk melengkapi tabel tabel yang ada dalam satu database. Misalnya Tabel Barang dengan bertambahnya field yang lain menjadi:
Tabel Barang
Kode_Barang
Nama_Barang
Harga_Beli
Harga_Jual
Sisa_Stock_Akhir
Sisa_Stock_Awal_Bulan
No comments:
Post a Comment