Empat Kesalahan Umum Dalam Mendesain Database

MENGABAIKAN NORMALISASI

Desain 1

Sangat buruk membuat tabel dengan mengulangi nama kolom ditambahkan dengan angka. Perhatikan contoh tabel Customer Disamping :

Pertanyaannya adalah : Apakah selalu ada 12 pembayaran? Apakah urutan pembayaran signifikan? Apakah nilai NULL untuk pembayaran berati UNKNOWN (tidak diisi sebelumnya), atau tidak ada pembayaran? Dan kapan pembayaran dilakukan?

Desain 2

Pembayaran tidak menggambarkan Nasabah dan tidak harus disimpan dalam tabel Nasabah. Rincian pembayaran harus disimpan dalam tabel Pembayaran, di mana Anda juga dapat merekam informasi tambahan mengenai pembayaran, seperti saat pembayaran dilakukan, dan untuk apa pembayaran itu:

Dalam desain kedua, setiap kolom menyimpan satu unit informasi tentang  pembayaran, dan setiap baris mewakili sebuah contoh spesifik dari pembayaran.

desain kedua ini memerlukan lebih sedikit kode di dalam pemrosesan dan hal ini jauh lebih mungkin, bahwa Anda akan dapat mengetahui apa yang sedang terjadi dalam sistem tanpa harus memburu programmer asli.

STANDAR PENAMAAN YANG BURUK

Nama yang kita pilih tidak hanya untuk memungkinkan kita untuk mengidentifikasi tujuan objek, tetapi untuk mengizinkan semua programmer masa depan, pengguna, dan sebagainya dengan cepat dan mudah memahami bagaimana bagian komponen dari database yang telah kita buat itu. 

Pertimbangkan, sebagai contoh, sebuah kolom yang bernama, X304_DSCR. Apa sih artinya? kita mungkin memutuskan, setelah pusing memikirkannya, bahwa itu berarti "deskripsi X304". Mungkin itu, tapi mungkin DSCR berarti diskriminator, atau discretizator? Kecuali kita telah membuat DSCR sebagai singkatan standar perusahaan untuk deskripsi, maka X304_DESCRIPTION adalah nama yang jauh lebih baik, sehingga kita tidak sulit untuk memikirkannya.

“Penamaan yang Tidak Konsisten” Kita harus menghindari nama seperti "Part Number" atau, dalam gaya Microsoft, [Part Number], sehingga memerlukan pengguna untuk memasukkan data-data dan pengenal dalam kode mereka. Hal ini menjengkelkan dan sesuatu yang tidak perlu.

alternatif lainnyapada penamaan part_number, partNumber atau PartNumber. Sekali lagi, konsistensi adalah kunci. Jika Anda memilih PartNumber maka tidak apa-apa - asalkan kolom berisi nomor faktur disebut InvoiceNumber, dan bukan salah satu variasi lain yang mungkin sehingga menjadi lebih membingungkan.

MENGGUNAKAN IDENTITAS / KOLOM SEBAGAI SATU-SATUNYA KUNCI PADA TABEL

Bentuk Normal Pertama menyatakan bahwa semua baris dalam tabel harus secara unik diidentifikasi. Oleh karena itu, setiap tabel harus memiliki primary key. 

Desain 5

Sekarang, anggap tabel berikut (Desain 5), dimana PartID adalah kolom IDENTITAS dan merupakan kunci utama untuk table.

Berapa banyak baris yang ada di tabel ini? Nah, tampaknya ada tiga, namun baris dengan PartIDs 1 dan 2 sebenarnya baris yang sama, namun digandakan? Atau apakah mereka dua baris yang berbeda yang harus unik tetapi salah mengetik?  Aturan praktis yang saya gunakan adalah sederhana. Jika manusia tidak bisa memilih mana baris yang mereka inginkan dari table tanpa   pengetahuan tentang kunci pengganti, maka Anda perlu untuk mempertimbangkan kembali desain Anda. Hal ini mengapa harus ada kunci pengganti untuk menjamin keunikan, dalam hal ini mungkin pada PartNumber.

SATU TABLE UNTUK MENYIMPAN DOMAIN SEMUA NILAI

Desain 3

Sebagai contoh, perhatikan potongan model berikut (Desain 3) di mana saya membutuhkan nilai domain untuk:

1. Pelanggan CreditStatus
2. Jenis Pelanggan
3. Status Faktur
4. Faktur Item Baris backorder Status
5. Faktur Item Baris Via Kapal Carrier

Desain 4

Diawal terdapat lima domain table, tapi mengapa hanya  menggunakan satu tabel domain generic (GenericDomainId) ?

Kesalahan terjadi karena Semua Keterangan key disimpan pada table GenericDomainID. Sebaiknya masing masing domain terdapat pada table yang berbeda (Desain 4).

Sumber :

http://www.simple-talk.com/sql/database-administration/ten-common-database-design-mistakes/
Diakses pada tanggal 22/12/2010 Pukul 10.18 WIB