Anda di halaman 1dari 2

 Tabel Fisik Database

Tabel basis data fisik dibangun dari model data dengan setiap entitas dalam model yang
diubah menjadi tabel fisik terpisah. Di bagian atas setiap tabel adalah atribut yang
membentuk kolom. Memotong kolom untuk membentuk baris tabel adalah tuple. Sebuah
tuple, yang memberikan definisi yang tepat ketika pertama kali diperkenalkan, mirip dengan
catatan dalam sistem file datar. Sesuai dengan konvensi, kami akan menggunakan istilah
catatan atau kejadian daripada tupel. Tabel yang dirancang dengan benar memiliki empat
karakteristik berikut:
1. Nilai setidaknya satu atribut dalam setiap kejadian (baris) harus unik. Atribut ini
adalah kunci utama. Nilai atribut (non key) lainnya di baris tidak harus unik.
2. Semua nilai atribut dalam kolom apa pun harus dari kelas yang sama.
3. Setiap kolom dalam tabel tertentu harus diberi nama yang unik. Namun, tabel yang
berbeda dapat berisi kolom dengan nama yang sama.
4. Tabel harus sesuai dengan aturan normalisasi. Ini berarti mereka harus bebas dari
ketergantungan structural termasuk kelompok berulang, dependensi parsial, dan
dependensi transitif (lihat appendix bab ini untuk diskusi lengkap).

 Kaitan antara Tabel Relasional


Tabel yang terkait secara logis perlu terhubung secara fisik untuk mencapai asosiasi yang
dijelaskan dalam model data.
 Tampilan Pengguna
Tampilan pengguna adalah kumpulan data yang dilihat oleh pengguna tertentu. Contoh
pandangan pengguna adalah layar komputer untuk memasukkan atau melihat data, laporan
manajemen, atau dokumen sumber seperti faktur. Tampilan mungkin digital atau fisik
(kertas), tetapi dalam semua kasus, mereka berasal dari tabel database yang mendasari.
Pandangan sederhana dapat dibangun dari satu tabel, sementara pandangan yang lebih
kompleks mungkin memerlukan beberapa tabel. Selanjutnya, satu tabel dapat
menyumbangkan data ke banyak pandangan yang berbeda.
Organisasi besar akan memiliki ribuan tampilan pengguna yang didukung oleh ribuan tabel
individual. Tugas mengidentifikasi semua pandangan dan menerjemahkannya ke dalam
tabel yang dinormalisasi adalah tanggung jawab yang penting dari perancang basis data
yang memiliki implikasi kontrol internal. Masalah dan teknik yang terkait dengan tugas ini
diperiksa selanjutnya.

Anomali, Dependensi Struktural, dan Normalisasi Data


Bagian ini membahas mengapa tabel database yang perlu dinormalisasi.
 Anomali Database
Jawaban atas pertanyaan di atas adalah tabel yang dinormalisasi dengan tidak semestinya
dapat menyebabkan masalah pemrosesan DBMS yang membatasi, atau bahkan menolak
pengguna mengakses informasi yang mereka butuhkan. Satu atau lebih dari anomali ini
akan ada dalam tabel yang tidak dinormalisasi atau dinormalisasi pada tingkat rendah,
seperti bentuk normal pertama (INF) atau bentuk normal kedua (2NF). Agar bebas dari
anomali, tabel harus dinormalisasi ke tingkat normal ketiga (3NF).
Perbarui Anomali. Anomali pembaruan hasil dari redundansi data dalam tabel yang tidak
dikenali. Untuk lebih menghargai implikasi dari anomali pembaruan, pertimbangkan situasi
yang lebih realistis.
Penyisipan Anomali. Untuk menunjukkan efek anomali penyisipan, asumsikan bahwa
vendor baru telah memasuki pasar dan organisasi belum membeli dari vendor tetapi
mungkin ingin melakukannya di masa depan.
Penghapusan Anomali. Penghapusan anomali melibatkan penghapusan data yang tidak
disengaja dari tabel. Kehadiran anomali penghapusan kurang mencolok, tetapi berpotensi
lebih serius daripada pembaruan dan penyisipan anomali.

Anda mungkin juga menyukai