9 Kesalahan Desain Database Paling Umum

Anda mungkin telah membuat beberapa kesalahan ini ketika Anda memulai karir desain database Anda. Mungkin Anda masih membuatnya, atau Anda akan membuatnya di masa depan. Kami tidak dapat kembali ke masa lalu dan membantu Anda membatalkan kesalahan Anda, tetapi kami dapat menyelamatkan Anda dari sakit kepala di masa depan (atau sekarang).

Membaca artikel ini dapat menghemat banyak waktu untuk memperbaiki masalah desain dan kode, jadi mari selami. Saya telah membagi daftar kesalahan menjadi dua kelompok utama:yang non-teknis di alam dan yang sangat teknis . Kedua kelompok ini merupakan bagian penting dari desain database.

Jelas, jika Anda tidak memiliki keterampilan teknis, Anda tidak akan tahu bagaimana melakukan sesuatu. Tidak mengherankan melihat kesalahan ini dalam daftar. Tapi keterampilan non-teknis? Orang mungkin melupakannya, tetapi keterampilan ini juga merupakan bagian yang sangat penting dari proses desain. Mereka menambahkan nilai pada kode Anda dan menghubungkan teknologi dengan masalah dunia nyata yang perlu Anda pecahkan.

Jadi, mari kita mulai dengan masalah non-teknis terlebih dahulu, lalu beralih ke masalah teknis.

Kesalahan Desain Basis Data Non-Teknis

#1 Perencanaan Buruk

Ini jelas merupakan masalah non-teknis, tetapi merupakan masalah besar dan umum. Kita semua bersemangat ketika sebuah proyek baru dimulai dan, saat memasukinya, semuanya tampak hebat. Pada awalnya, proyek ini masih berupa halaman kosong dan Anda serta klien Anda dengan senang hati mulai mengerjakan sesuatu yang akan menciptakan masa depan yang lebih baik bagi Anda berdua. Ini semua hebat, dan masa depan yang hebat mungkin akan menjadi hasil akhir. Tapi tetap saja, kami harus tetap fokus. Ini adalah bagian dari proyek di mana kita dapat membuat kesalahan penting.

Sebelum Anda duduk untuk menggambar model data, Anda harus yakin bahwa:

• Anda benar-benar mengetahui apa yang dilakukan klien Anda (yaitu rencana bisnis mereka terkait dengan proyek ini dan juga gambaran keseluruhan mereka) dan apa yang mereka ingin capai dari proyek ini sekarang dan di masa depan.
• Anda memahami proses bisnis dan, jika atau bila diperlukan, Anda siap memberikan saran untuk menyederhanakan dan menyempurnakannya (misalnya untuk meningkatkan efisiensi dan pendapatan, mengurangi biaya dan jam kerja, dll).
• Anda memahami aliran data di perusahaan klien. Idealnya, Anda mengetahui setiap detail:siapa yang menangani data, siapa yang membuat perubahan, laporan mana yang diperlukan, kapan dan mengapa semua ini terjadi.
• Anda dapat menggunakan bahasa/terminologi yang digunakan klien Anda. Meskipun Anda mungkin atau mungkin bukan ahli di bidang mereka, klien Anda pasti ahli. Minta mereka untuk menjelaskan apa yang tidak Anda mengerti. Dan saat Anda menjelaskan detail teknis kepada klien, gunakan bahasa dan terminologi yang mereka pahami.
• Anda tahu teknologi mana yang akan Anda gunakan, dari mesin database dan bahasa pemrograman hingga alat lainnya. Apa yang Anda putuskan untuk digunakan terkait erat dengan masalah yang akan Anda selesaikan, tetapi penting untuk menyertakan preferensi klien dan infrastruktur TI mereka saat ini.

Selama fase perencanaan, Anda harus mendapatkan jawaban atas pertanyaan berikut:

• Tabel mana yang akan menjadi tabel pusat dalam model Anda? Anda mungkin akan memiliki beberapa di antaranya, sementara tabel lainnya adalah tabel biasa (mis. user_account, role). Jangan lupa tentang kamus dan relasi antar tabel.
• Nama apa yang akan digunakan untuk tabel dalam model? Ingatlah untuk menjaga terminologi yang sama dengan apa pun yang digunakan klien saat ini.
• Aturan apa yang akan diterapkan saat memberi nama tabel dan objek lain? (Lihat Butir 4 tentang konvensi penamaan.)
• Berapa lama seluruh proyek akan berlangsung? Ini penting, baik untuk jadwal Anda maupun untuk linimasa klien.

Hanya ketika Anda memiliki semua jawaban ini, Anda siap untuk berbagi solusi awal untuk masalah tersebut. Solusi tersebut tidak harus berupa aplikasi yang lengkap – mungkin berupa dokumen pendek atau bahkan beberapa kalimat dalam bahasa bisnis klien.

Perencanaan yang baik tidak khusus untuk pemodelan data; itu berlaku untuk hampir semua proyek TI (dan non-TI). Melewati hanya sebuah pilihan jika 1) Anda memiliki proyek yang sangat kecil; 2) tugas dan tujuannya jelas, dan 3) Anda benar-benar terburu-buru. Contoh historis adalah insinyur peluncuran Sputnik 1 yang memberikan instruksi lisan kepada teknisi yang merakitnya. Proyek ini terburu-buru karena berita bahwa AS berencana untuk segera meluncurkan satelit mereka sendiri – tetapi saya rasa Anda tidak akan terburu-buru.

#2 Komunikasi yang Tidak Memadai dengan Klien dan Pengembang

Saat Anda memulai proses desain database, Anda mungkin akan memahami sebagian besar persyaratan utama. Beberapa sangat umum terlepas dari bisnisnya, mis. peran dan status pengguna. Di sisi lain, beberapa tabel dalam model Anda akan sangat spesifik. Misalnya, jika Anda membuat model untuk perusahaan taksi, Anda akan memiliki tabel untuk kendaraan, pengemudi, klien, dll.

Namun, tidak semuanya akan terlihat jelas di awal proyek. Anda mungkin salah memahami beberapa persyaratan, klien mungkin menambahkan beberapa fungsi baru, Anda akan melihat sesuatu yang dapat dilakukan secara berbeda, prosesnya mungkin berubah, dll. Semua ini menyebabkan perubahan pada model. Sebagian besar perubahan memerlukan penambahan tabel baru, tetapi terkadang Anda akan menghapus atau memodifikasi tabel. Jika Anda sudah mulai menulis kode yang menggunakan tabel ini, Anda juga harus menulis ulang kode tersebut.

Untuk mengurangi waktu yang dihabiskan untuk perubahan tak terduga, Anda harus:

• Bicaralah dengan pengembang dan klien dan jangan takut untuk mengajukan pertanyaan bisnis yang penting. Saat Anda merasa siap untuk memulai, tanyakan pada diri Anda Apakah situasi X tercakup dalam database kami? Klien saat ini melakukan Y dengan cara ini; apakah kita mengharapkan perubahan dalam waktu dekat? Setelah kami yakin model kami memiliki kemampuan untuk menyimpan semua yang kami butuhkan dengan cara yang benar, kami dapat mulai membuat kode.
• Jika Anda menghadapi perubahan besar dalam desain Anda dan Anda sudah memiliki banyak kode yang ditulis, Anda tidak boleh mencoba perbaikan cepat. Lakukan seperti yang seharusnya dilakukan, apa pun situasinya saat ini. Perbaikan cepat dapat menghemat waktu sekarang dan mungkin akan berfungsi dengan baik untuk sementara waktu, tetapi dapat berubah menjadi mimpi buruk di kemudian hari.
• Jika Anda merasa ada yang baik-baik saja sekarang tetapi bisa menjadi masalah di kemudian hari, jangan abaikan. Analisis area itu dan terapkan perubahan jika itu akan meningkatkan kualitas dan kinerja sistem. Ini akan memakan waktu, tetapi Anda akan menghasilkan produk yang lebih baik dan tidur yang lebih nyenyak.

Jika Anda mencoba untuk menghindari membuat perubahan pada model data Anda saat Anda melihat potensi masalah — atau jika Anda memilih perbaikan cepat daripada melakukannya dengan benar — Anda akan membayarnya cepat atau lambat.

Juga, tetap berhubungan dengan klien Anda dan pengembang selama proyek berlangsung. Selalu periksa dan lihat apakah ada perubahan yang dibuat sejak diskusi terakhir Anda.

#3 Dokumentasi Buruk atau Hilang

Bagi kebanyakan dari kita, dokumentasi datang di akhir proyek. Jika kami terorganisir dengan baik, kami mungkin telah mendokumentasikan banyak hal di sepanjang jalan dan kami hanya perlu menyelesaikan semuanya. Tapi jujur, biasanya tidak demikian. Menulis dokumentasi terjadi tepat sebelum proyek ditutup — dan tepat setelah mental kita selesai dengan model data itu!

Harga yang dibayarkan untuk proyek yang terdokumentasi dengan buruk bisa sangat tinggi, beberapa kali lebih tinggi dari harga yang kami bayar untuk mendokumentasikan semuanya dengan benar. Bayangkan menemukan bug beberapa bulan setelah Anda menutup proyek. Karena Anda tidak mendokumentasikan dengan benar, Anda tidak tahu harus mulai dari mana.

Saat Anda bekerja, jangan lupa untuk menulis komentar. Jelaskan semua yang membutuhkan penjelasan tambahan, dan pada dasarnya tuliskan semua yang menurut Anda akan berguna suatu hari nanti. Anda tidak pernah tahu apakah atau kapan Anda akan membutuhkan info tambahan itu.

Kesalahan Desain Basis Data Teknis

#4 Tidak Menggunakan Konvensi Penamaan

Anda tidak pernah tahu pasti berapa lama proyek akan bertahan dan apakah Anda akan memiliki lebih dari satu orang yang mengerjakan model data. Ada titik ketika Anda benar-benar dekat dengan model data, tetapi Anda belum benar-benar mulai menggambarnya. Inilah saatnya untuk memutuskan bagaimana Anda akan memberi nama objek dalam model Anda, dalam database, dan dalam aplikasi umum. Sebelum membuat model, Anda harus mengetahui:

• Apakah nama tabel tunggal atau jamak?
• Apakah kita akan mengelompokkan tabel menggunakan nama? (Misalnya, semua tabel terkait klien berisi "klien_", semua tabel terkait tugas berisi "tugas_", dll.)
• Apakah kita akan menggunakan huruf besar dan kecil, atau hanya huruf kecil?
• Nama apa yang akan kita gunakan untuk kolom ID? (Kemungkinan besar, itu akan menjadi "id".)
• Bagaimana kita akan menamai kunci asing? (Kemungkinan besar “id_” dan nama tabel yang dirujuk.)

Bandingkan bagian dari model yang tidak menggunakan konvensi penamaan dengan bagian yang sama yang menggunakan konvensi penamaan, seperti yang ditunjukkan di bawah ini:

Hanya ada beberapa tabel di sini, tetapi masih cukup jelas model mana yang lebih mudah dibaca. Perhatikan bahwa:

• Kedua model "berfungsi", jadi tidak ada masalah di sisi teknis.
• Dalam contoh konvensi non-penamaan (tiga tabel di atas), ada beberapa hal yang secara signifikan memengaruhi keterbacaan:menggunakan bentuk tunggal dan jamak dalam nama tabel; nama kunci utama non-standar (employees_id , id_role ); dan atribut dalam tabel yang berbeda memiliki nama yang sama (mis. nama muncul di kedua “employee ” dan “roles ” tabel).

Sekarang bayangkan kekacauan yang akan kita buat jika model kita berisi ratusan tabel. Mungkin kita bisa bekerja dengan model seperti itu (jika kita membuatnya sendiri) tapi kita akan membuat seseorang sangat tidak beruntung jika mereka harus mengerjakannya setelah kita.

Untuk menghindari masalah nama di masa mendatang, jangan gunakan kata-kata khusus SQL, karakter khusus, atau spasi di dalamnya.

Jadi, sebelum Anda mulai membuat nama apa pun, buatlah dokumen sederhana (mungkin hanya beberapa halaman) yang menjelaskan konvensi penamaan yang Anda gunakan. Ini akan meningkatkan keterbacaan seluruh model dan menyederhanakan pekerjaan di masa mendatang.

Anda dapat membaca lebih lanjut tentang konvensi penamaan di dua artikel ini:

• Konvensi Penamaan dalam Pemodelan Basis Data
• Pandangan Logis Tanpa Emosi pada Konvensi Penamaan SQL Server

#5 Masalah Normalisasi

Normalisasi adalah bagian penting dari desain database. Setiap database harus dinormalisasi ke setidaknya 3NF (kunci utama ditentukan, kolom bersifat atomik, dan tidak ada grup berulang, dependensi parsial, atau dependensi transitif). Ini mengurangi duplikasi data dan memastikan integritas referensial.

Anda dapat membaca lebih lanjut tentang normalisasi di artikel ini. Singkatnya, setiap kali kita berbicara tentang model database relasional, kita berbicara tentang database yang dinormalisasi. Jika database tidak dinormalisasi, kami akan mengalami banyak masalah terkait integritas data.

Dalam beberapa kasus, kami mungkin ingin mendenormalisasi database kami. Jika Anda melakukan ini, punya alasan yang sangat bagus. Anda dapat membaca lebih lanjut tentang denormalisasi basis data di sini.

#6 Menggunakan Model Entity-Attribute-Value (EAV)

EAV adalah singkatan dari entitas-atribut-nilai. Struktur ini dapat digunakan untuk menyimpan data tambahan tentang apapun dalam model kita. Mari kita lihat satu contoh.

Misalkan kita ingin menyimpan beberapa atribut pelanggan tambahan. “customer ” tabel adalah entitas kami, “attribute ” jelas merupakan atribut kita, dan “attribute_value ” tabel berisi nilai atribut tersebut untuk pelanggan tersebut.

Pertama, kami akan menambahkan kamus dengan daftar semua kemungkinan properti yang dapat kami berikan kepada pelanggan. Ini adalah “attribute " meja. Itu bisa berisi properti seperti "nilai pelanggan", "detail kontak", "info tambahan", dll. "customer_attribute ” tabel berisi daftar semua atribut, dengan nilai, untuk setiap pelanggan. Untuk setiap pelanggan, kami hanya akan memiliki catatan untuk atribut yang mereka miliki, dan kami akan menyimpan “attribute_value ” untuk atribut itu.

Ini bisa terlihat sangat bagus. Ini akan memungkinkan kami untuk menambahkan properti baru dengan mudah (karena kami menambahkannya sebagai nilai di “customer_attribute " meja). Dengan demikian, kami akan menghindari membuat perubahan dalam database. Hampir terlalu bagus untuk menjadi kenyataan.

Dan itu terlalu bagus. Sementara model akan menyimpan data yang kita butuhkan, bekerja dengan data seperti itu jauh lebih rumit. Dan itu mencakup hampir semua hal, mulai dari menulis kueri SELECT sederhana hingga mendapatkan semua nilai terkait pelanggan hingga memasukkan, memperbarui, atau menghapus nilai.

Singkatnya, kita harus menghindari struktur EAV. Jika Anda harus menggunakannya, gunakan hanya saat Anda yakin 100% benar-benar dibutuhkan.

#7 Menggunakan GUID/UUID sebagai Kunci Utama

GUID (Pengidentifikasi Unik Global) adalah angka 128-bit yang dihasilkan menurut aturan yang ditentukan dalam RFC 4122. Terkadang juga dikenal sebagai UUID (Pengidentifikasi Unik Universal). Keuntungan utama GUID adalah unik; kemungkinan Anda menekan GUID yang sama dua kali benar-benar tidak mungkin. Oleh karena itu, GUID tampak seperti kandidat yang bagus untuk kolom kunci utama. Tapi bukan itu masalahnya.

Aturan umum untuk kunci utama adalah kita menggunakan kolom bilangan bulat dengan properti peningkatan otomatis disetel ke "ya". Ini akan menambahkan data secara berurutan ke kunci utama dan memberikan kinerja yang optimal. Tanpa kunci sekuensial atau stempel waktu, tidak ada cara untuk mengetahui data mana yang dimasukkan terlebih dahulu. Masalah ini juga muncul saat kami menggunakan nilai dunia nyata UNIK (mis. ID PPN). Meskipun mereka memegang nilai UNIK, mereka tidak membuat kunci utama yang baik. Gunakan mereka sebagai kunci alternatif.

Satu catatan tambahan: Saya lebih suka menggunakan atribut integer yang dihasilkan secara otomatis satu kolom sebagai kunci utama. Ini jelas merupakan praktik terbaik. Saya sarankan Anda menghindari penggunaan kunci primer komposit.

#8 Pengindeksan Tidak Memadai

• Apa Itu Indeks Basis Data?
• Semua Tentang Indeks:Dasar-dasar
• Semua Tentang Indeks Bagian 2:Struktur dan Kinerja Indeks MySQL

Versi singkatnya adalah saya menyarankan Anda menambahkan indeks di mana pun Anda mengharapkannya. Anda juga dapat menambahkannya setelah database dalam produksi jika Anda melihat bahwa menambahkan indeks di tempat tertentu akan meningkatkan kinerja.

#9 Data Berlebihan

Data yang berlebihan umumnya harus dihindari dalam model apa pun. Ini tidak hanya memakan ruang disk tambahan tetapi juga sangat meningkatkan kemungkinan masalah integritas data. Jika ada sesuatu yang berlebihan, kita harus berhati-hati agar data asli dan "salinan" selalu dalam keadaan yang konsisten. Faktanya, ada beberapa situasi di mana data yang berlebihan diinginkan:

• Dalam beberapa kasus, kita harus menetapkan prioritas untuk tindakan tertentu — dan untuk mewujudkannya, kita harus melakukan perhitungan yang rumit. Perhitungan ini dapat menggunakan banyak tabel dan menghabiskan banyak sumber daya. Dalam kasus seperti itu, akan lebih bijaksana untuk melakukan perhitungan ini selama jam kerja (sehingga menghindari masalah kinerja selama jam kerja). Jika kita melakukannya dengan cara ini, kita dapat menyimpan nilai yang dihitung itu dan menggunakannya nanti tanpa harus menghitung ulang. Tentu saja, nilainya berlebihan; namun, apa yang kami peroleh dalam kinerja jauh lebih besar daripada apa yang kami hilangkan (beberapa ruang hard drive).
• Kami juga dapat menyimpan sekumpulan kecil data pelaporan di dalam database. Misalnya, di penghujung hari, kami akan menyimpan jumlah panggilan yang kami lakukan hari itu, jumlah penjualan yang berhasil, dll. Data pelaporan hanya boleh disimpan dengan cara ini jika kami perlu sering menggunakannya. Sekali lagi, kami akan kehilangan sedikit ruang hard drive, tetapi kami akan menghindari penghitungan ulang data atau menghubungkan ke database pelaporan (jika ada).

Dalam kebanyakan kasus, kita tidak boleh menggunakan data yang berlebihan karena:

• Menyimpan data yang sama lebih dari satu kali dalam database dapat memengaruhi integritas data. Jika Anda menyimpan nama klien di dua tempat yang berbeda, Anda harus membuat perubahan apa pun (masukkan/perbarui/hapus) ke kedua tempat tersebut secara bersamaan. Ini juga memperumit kode yang Anda perlukan, bahkan untuk operasi yang paling sederhana.
• Meskipun kami dapat menyimpan beberapa nomor agregat dalam basis data operasional kami, kami harus melakukan ini hanya ketika kami benar-benar membutuhkannya. Basis data operasional tidak dimaksudkan untuk menyimpan data pelaporan, dan menggabungkan keduanya umumnya merupakan praktik yang buruk. Siapa pun yang membuat laporan harus menggunakan sumber daya yang sama dengan pengguna yang mengerjakan tugas operasional; kueri pelaporan biasanya lebih kompleks dan dapat memengaruhi kinerja. Oleh karena itu, Anda harus memisahkan database operasional dan database pelaporan Anda.

Sekarang Giliran Anda untuk Menimbang

Saya harap membaca artikel ini telah memberi Anda beberapa wawasan baru dan akan mendorong Anda untuk mengikuti praktik terbaik pemodelan data. Mereka akan menghemat waktu Anda!

Apakah Anda mengalami salah satu masalah yang disebutkan dalam artikel ini? Apakah Anda pikir kami melewatkan sesuatu yang penting? Atau apakah menurut Anda kami harus menghapus sesuatu dari daftar kami? Tolong beri tahu kami di komentar di bawah.