Kesalahan Umum yang Dibuat dalam Desain Basis Data

Apakah Anda bekerja dengan database yang menyimpan ratusan catatan atau jutaan catatan, desain database yang tepat selalu penting. Tidak hanya itu akan membuat pengambilan informasi lebih mudah, itu juga akan menyederhanakan perluasan database di masa depan. Sayangnya, sangat mudah untuk jatuh ke beberapa perangkap yang dapat membuat hal-hal menjadi sulit di masa depan.

Ada seluruh buku yang ditulis tentang masalah normalisasi database, tetapi jika Anda hanya menghindari kesalahan umum ini, Anda akan berada di jalur yang benar untuk desain database yang baik.

Kesalahan Database # 1: Mengulang Bidang dalam Tabel

Aturan dasar praktis untuk desain database yang baik adalah mengenali pengulangan data dan menempatkan kolom berulang di tabel mereka sendiri. Mengulangi bidang dalam tabel adalah umum bagi mereka yang berasal dari dunia spreadsheet, tetapi sementara spreadsheet cenderung datar menurut desain, database harus relasional. Ini seperti pergi dari 2D ke 3D.

Untungnya, bidang berulang biasanya mudah dikenali. Coba lihat tabel ini:

Id pemesanan Produk1 Product2 Product3
1 Boneka beruang Jelly Beans
2 Jelly Beans

Apa yang terjadi ketika pesanan berisi empat produk? Kami perlu menambahkan bidang lain ke tabel untuk mendukung lebih dari tiga produk. Dan jika kami telah membuat aplikasi klien di sekeliling meja untuk membantu kami memasukkan data, kami mungkin perlu memodifikasinya dengan bidang produk baru. Dan bagaimana kita menemukan semua pesanan dengan Jellybeans dalam pesanan? Kami akan dipaksa untuk menanyakan setiap bidang produk dalam tabel dengan pernyataan SQL yang mungkin terlihat seperti: SELECT * FROM Products WHERE Product1 = 'Jelly Beans' ATAU Product2 = 'Jelly Beans' OR Product3 = 'Jelly Beans'.

Alih-alih memiliki satu tabel yang menjejali semua informasi bersama-sama, kita harus memiliki tiga tabel yang masing-masing memegang sepotong informasi yang berbeda. Dalam contoh ini, kami ingin tabel Pesanan dengan informasi tentang pesanan itu sendiri, tabel Produk dengan semua produk kami dan tablet ProductOrders yang menautkan produk ke pesanan.

Id pemesanan ID Pelanggan Tanggal pemesanan Total
1 7 1/24/17 19,99
2 9 1/25/17 24,99
ID Produk Produk Menghitung
1 Boneka beruang 1
2 Jelly Beans 100
ProductOrderID ID Produk Id pemesanan
101 1 1
102 2 1

Perhatikan bagaimana setiap tabel memiliki bidang ID uniknya sendiri. Ini adalah kunci utama. Kami menghubungkan tabel dengan menggunakan nilai kunci primer sebagai kunci asing di tabel lain. Baca lebih lanjut tentang kunci primer dan kunci asing.

Kesalahan Database # 2: Menyematkan Tabel dalam Tabel

Ini adalah kesalahan umum lainnya, tetapi itu tidak selalu menonjol sebanyak bidang berulang. Saat mendesain database, Anda ingin memastikan semua data dalam tabel terkait dengan dirinya sendiri. Ini seperti permainan anak itu tentang menemukan apa yang berbeda. Jika Anda memiliki pisang, stroberi, buah persik dan televisi, pesawat televisi mungkin berada di tempat lain.

Sepanjang baris yang sama, jika Anda memiliki tabel orang-orang penjualan, semua informasi dalam tabel itu harus berhubungan secara khusus dengan orang penjualan itu. Informasi tambahan apa pun yang tidak unik bagi staf penjualan itu dapat termasuk di tempat lain dalam database Anda.

SalesID Pertama Terakhir Alamat Nomor telepon Kantor Nomor kantor
1 Sam Elliot 118 Main St, Austin, TX (215) 555-5858 Austin Downtown (212) 421-2412
2 Alice Smith 504 2nd Street, New York, NY (211) 122-1821 New York (Timur) (211) 855-4541
3 Joe Paroki 428 Aker St, Austin, TX (215) 545-5545 Austin Downtown (212) 421-2412

Meskipun tabel ini mungkin terlihat seperti semua yang terkait dengan penjual individu, sebenarnya tabel tersebut disematkan dalam tabel. Perhatikan bagaimana Office dan OfficeNumber mengulang dengan "Austin Downtown". Bagaimana jika nomor telepon kantor berubah? Anda perlu memperbarui seluruh rangkaian data untuk satu bagian informasi yang berubah, yang tidak pernah bagus. Bidang-bidang ini harus dipindahkan ke meja mereka sendiri.

SalesID Pertama Terakhir Alamat Nomor telepon OfficeID
1 Sam Elliot 118 Main St, Austin, TX (215) 555-5858 1
2 Alice Smith 504 2nd Street, New York, NY (211) 122-1821 2
3 Joe Paroki 428 Aker St, Austin, TX (215) 545-5545 1
OfficeID Kantor Nomor kantor
1 Austin Downtown (212) 421-2412
2 New York (Timur) (211) 855-4541

Jenis desain ini juga memberi Anda kemampuan untuk menambahkan informasi tambahan ke tabel Office tanpa membuat mimpi buruk kekacauan di tabel staf penjualan. Bayangkan berapa banyak pekerjaan itu hanya untuk melacak alamat jalan, kota, negara bagian dan kode pos jika semua informasi itu ada di meja orang penjualan!

Kesalahan Database # 3: Menaruh Dua atau Lebih Banyak Informasi ke dalam Satu Bidang

Menanamkan informasi kantor ke dalam meja staf penjualan bukan satu-satunya masalah dengan database itu. Bidang alamat berisi tiga bagian informasi: alamat jalan, kota dan negara bagian. Setiap bidang dalam database hanya boleh berisi satu bagian informasi. Ketika Anda memiliki banyak informasi dalam satu bidang, ini bisa menjadi lebih sulit untuk meminta informasi database.

Misalnya, bagaimana jika kita ingin menjalankan kueri pada semua staf penjualan dari Austin? Kami perlu mencari di dalam bidang alamat, yang tidak hanya tidak efisien, tetapi dapat mengembalikan informasi yang buruk. Lagi pula, apa yang terjadi jika seseorang tinggal di jalan Austin di Portland, Oregon?

Seperti inilah tampilan tabel:

SalesID Pertama Terakhir Alamat 1 Alamat 2 Kota Negara Zip Telepon
1 Sam Elliot 118 Main St Austin TX 78720 2155555858
2 Alice Smith 504 St-2 New York NY 10022 2111221821
3 Joe Paroki 428 Aker St Apt 304 Austin TX 78716 2155455545

Ada beberapa hal yang perlu diperhatikan di sini. Pertama, "Address1" dan "Address2" tampaknya jatuh di bawah kesalahan bidang berulang.

Namun, dalam hal ini mereka mengacu pada potongan data terpisah yang berhubungan langsung dengan orang penjualan daripada kelompok data berulang yang harus masuk ke dalam tabelnya sendiri.

Juga, sebagai kesalahan bonus untuk menghindari, perhatikan bagaimana format untuk nomor telepon telah dilucuti dari meja. Anda harus menghindari menyimpan format kolom jika memungkinkan. Dalam hal nomor telepon, ada beberapa cara orang menulis nomor telepon: 215-555-5858 atau (215) 555-5858. Ini akan membuat mencari orang penjualan dengan nomor telepon mereka atau melakukan pencarian orang-orang penjualan di kode area yang sama lebih sulit.

Kesalahan Database # 4: Tidak Menggunakan Kunci Utama yang Benar

Dalam banyak kasus, Anda akan ingin menggunakan nomor yang bertambah secara otomatis atau beberapa nomor atau alfanumerik lain yang dihasilkan untuk kunci utama Anda. Anda harus menghindari menggunakan informasi aktual apa pun untuk kunci utama meskipun kedengarannya seperti itu akan menjadi pengidentifikasi yang baik.

Sebagai contoh, kita masing-masing memiliki nomor jaminan sosial kita sendiri, jadi menggunakan nomor jaminan sosial untuk database karyawan mungkin terdengar seperti ide yang bagus. Tetapi meski jarang, mungkin bahkan nomor jaminan sosial berubah, dan kami tidak ingin kunci utama kami berubah.

Dan itulah masalah dengan menggunakan informasi aktual sebagai nilai kunci. Itu bisa berubah.

Kesalahan Database # 5: Tidak Menggunakan Konvensi Penamaan

Ini mungkin tidak terdengar seperti masalah besar ketika Anda pertama kali mulai merancang database Anda, tetapi setelah Anda sampai ke titik penulisan query terhadap database untuk mengambil informasi, memiliki konvensi penamaan akan membantu ketika Anda menghafal nama-nama kolom.

Bayangkan betapa sulitnya proses itu jika nama disimpan sebagai FirstName, LastName dalam satu tabel dan first_name, last_name di tabel lain.

Dua konvensi penamaan yang paling populer adalah kapitalisasi huruf pertama dari setiap kata di lapangan atau memisahkan kata menggunakan garis bawah. Anda mungkin juga melihat beberapa pengembang memanfaatkan huruf pertama dari setiap kata kecuali kata pertama: firstName, lastName.

Anda juga akan ingin memutuskan menggunakan nama tabel tunggal atau nama tabel jamak. Apakah ini tabel Pesanan atau tabel Pesanan? Apakah ini tabel Pelanggan atau Pelanggan? Sekali lagi, Anda tidak ingin terjebak dengan tabel Pesanan dan meja Pelanggan.

Konvensi penamaan yang Anda pilih tidak sepenting proses memilih dan berpegang teguh pada konvensi penamaan.

Kesalahan Database # 6: Indexing yang Tidak Tepat

Pengindeksan adalah salah satu hal tersulit untuk mendapatkan yang benar, terutama bagi mereka yang baru di desain database. Semua kunci primer dan kunci asing harus diindeks. Ini adalah tabel tautan apa bersama-sama, jadi tanpa indeks, Anda akan melihat kinerja yang sangat buruk dari basis data Anda.

Tetapi yang terlalu sering dilewatkan adalah bidang lain. Ini adalah kolom "WHERE". Jika Anda sering akan mempersempit pencarian Anda dengan menggunakan bidang dalam klausa WHERE, Anda perlu berpikir tentang meletakkan indeks di bidang itu. Namun, Anda tidak ingin terlalu mengindeks tabel, yang juga dapat merusak kinerja.

Bagaimana cara memutuskannya? Ini adalah bagian dari seni desain database. Tidak ada batasan keras tentang berapa banyak indeks yang harus Anda letakkan di atas meja. Terutama, Anda ingin mengindeks bidang apa pun yang sering digunakan dalam klausa WHERE. Baca lebih lanjut tentang pengindeksan database Anda dengan benar.