Tips untuk Desain Database yang Lebih Baik

Selama bertahun-tahun, bekerja sebagai pemodel data dan arsitek basis data, saya telah memperhatikan bahwa ada beberapa aturan yang harus diikuti selama pemodelan dan pengembangan data. Berikut saya uraikan beberapa tips dengan harapan dapat membantu Anda. Saya telah membuat daftar tip dalam urutan kemunculannya selama siklus hidup proyek daripada membuat daftar berdasarkan kepentingan atau seberapa umum tip tersebut.

1. Rencanakan Sebelumnya

Gagal merencanakan berarti merencanakan kegagalan.

Alan Lakein

Satu masalah yang saya lihat adalah ketika pemodelan data terjadi bersamaan dengan pengembangan perangkat lunak. Ini seperti membangun fondasi sebelum menyelesaikan cetak biru. Di masa lalu, perencanaan tampak sebagai langkah yang jelas sebelum memulai pembangunan. Tim pengembang tidak akan membuat database tanpa perencanaan seperti halnya arsitek tidak akan membangun gedung tanpa cetak biru.

Dalam pengembangan aplikasi, sangat penting untuk memahami sifat data.

Perencanaan sering diabaikan sehingga pengembang bisa langsung “memulai coding”. Proyek dimulai dan ketika masalah muncul, tidak ada jeda dalam jadwal untuk mengatasinya. Pengembang mengambil jalan pintas dengan maksud untuk memperbaikinya nanti, tetapi hal ini jarang terjadi jika pernah terjadi.

Perencanaan yang cermat adalah bagaimana memastikan bahwa Anda mendapatkan database yang tepat yang tidak diretas bersama. Jika Anda tidak menghabiskan waktu dan upaya di muka untuk menangani data yang diperlukan oleh proses, Anda akan membayarnya nanti dengan database yang harus dikerjakan ulang, diganti, atau dihapus.

Meskipun perencanaan tidak selalu dilakukan, banyak pemodel data masih mengikuti panduan ini. Itu tidak berarti kami dapat memprediksi setiap kebutuhan desain terlebih dahulu, tetapi sebagian besar pemodel percaya bahwa perlu upaya untuk memahami data dan penggunaannya. Anda tidak akan menginginkan desain untuk pemrosesan transaksi ketika kebutuhannya adalah pembuatan laporan analitik.

Waktu telah berubah; Metodologi tangkas lebih lazim sehingga tim basis data harus memikirkan kembali pendekatan mereka terhadap pemodelan data. Di Agile, Model Domain dari Kasus Penggunaan digunakan sebagai ganti Diagram Hubungan Entitas. Namun, kebutuhan untuk perencanaan tidak berkurang. Kita perlu memahami data dan apa yang seharusnya dilakukan. Secara umum, beberapa Sprint pertama harus fokus pada desain data.

Jadi bukan Agile yang menjadi masalah bagi pemodel database, melainkan individu yang tidak memahami sifat data. Beberapa orang melihat pengembangan database sama dengan pengembangan aplikasi. Pemodelan basis data dan pengembangan perangkat lunak berbeda dan membutuhkan fokus yang tepat.

Basis data adalah inti dari sebagian besar aplikasi perangkat lunak. Anda harus meluangkan waktu untuk menganalisis persyaratan dan bagaimana model data akan memenuhinya. Ini mengurangi kemungkinan bahwa perkembangan akan kehilangan arah dan arah.

Pengembang harus memahami pentingnya data dan kontribusinya terhadap proses pengembangan. Kita hidup di era informasi. Aplikasi menampilkan dan memanipulasi data. Ini adalah informasi yang terkandung dalam data yang memberi makna pada aplikasi.

Tidak mungkin untuk meramalkan setiap persyaratan atau setiap masalah, tetapi penting untuk mempersiapkan masalah dengan perencanaan yang cermat.

2. Dokumentasikan Model Anda

Saat membuat model data, semuanya tampak jelas. Anda memberi nama benda-benda itu sehingga tujuannya jelas dan semua orang akan mengerti artinya hanya dengan membaca namanya. Ini mungkin benar, tetapi tidak sejelas yang Anda kira. Saat memilih nama untuk tabel dan kolom, jelaskan penggunaan masing-masing objek. Seiring waktu, makna objek tidak akan jelas tanpa dokumentasi.

Menggunakan konvensi penamaan adalah satu langkah menuju dokumentasi yang efektif. Ketika Anda harus membuat perubahan di masa mendatang, Anda akan menghargai dokumentasi yang ada. Dokumen singkat dan sederhana yang menjelaskan keputusan yang Anda buat dan menjelaskan desain akan membantu menjelaskan pilihan desain pada saat itu.

Anda menginginkan dokumentasi yang cukup sehingga database dapat dikelola oleh administrator baru dan mereka dapat memahami artinya tanpa harus kembali kepada Anda untuk penjelasan. Jika model data dan lingkungan tidak didokumentasikan, sulit untuk mempertahankan atau mengubahnya karena persyaratan berubah.

Sampai batas tertentu, dokumentasi tidak ada hubungannya dengan pemodelan data. Dokumentasi adalah tentang mengkomunikasikan desain dan membuatnya dapat dimengerti di masa mendatang.

Dokumentasi sering menjadi renungan. Ketika jadwal pendek, dokumentasi diabaikan. Padahal, ini utang teknis dengan biaya tinggi. Jalan pintas selama siklus pengembangan akan menimbulkan biaya di masa mendatang untuk perubahan basis data, identifikasi masalah, pelacakan bug, dan untuk memahami model data dan sifat data.

Sebagai contoh, model data sering memiliki bidang "ID" sebagai kunci utama untuk tabel atau sebagian dari nama kunci. Ini mungkin kunci utama seperti TransactionID pada Transaction meja. Jika beberapa tabel menggunakan “Number” sebagai bagian dari nama kunci, maka ada baiknya untuk mendokumentasikan alasannya. Mungkin ReferenceNumber digunakan sebagai nama kunci utama pada Pesan karena itulah yang disebut referensi di area bisnis. Misalnya, dalam layanan keuangan, pesan keuangan biasanya menyertakan nomor referensi.

Dokumentasikan definisi tabel, kolom, dan hubungan sehingga pemrogram dapat mengakses informasi. Dokumentasi harus menjelaskan ekspektasi struktur database.

Di alat Vertabelo, saya dapat segera menyertakan komentar pada item apa pun:tabel, kolom, referensi, kunci alternatif, yang berarti bahwa dokumentasi disimpan segera dengan model saya, bukan di beberapa dokumen tambahan untuk disimpan secara terpisah.

Dokumentasi yang buruk atau tidak ada sering kali disebabkan oleh pemikiran yang picik, tetapi jangan abaikan pentingnya. Ini masih merupakan masalah yang harus ditangani.

3. Ikuti Konvensi

Konvensi penamaan mungkin tidak tampak penting selama desain. Pada kenyataannya, nama memberikan wawasan untuk memahami sebuah model. Mereka adalah pengantar dan harus logis.

Penamaan yang tidak konsisten tidak ada gunanya. Ini hanya membuat frustasi para pengembang yang harus mengakses data, administrator database, dan pemodel yang harus membuat perubahan di masa depan.

Ketika "ID" digunakan untuk beberapa kunci buatan tetapi beberapa tabel menggunakan konvensi penamaan yang berbeda (seperti Nomor), pengembang, analis, dan DBA mungkin membuang waktu untuk memahami pengecualian. Konvensi penamaan yang lemah juga menyebabkan kesalahan dalam pengembangan karena penamaan yang tidak konsisten.

Bergandengan tangan dengan dokumentasi, menggunakan konvensi penamaan membuatnya di masa depan bagi seseorang untuk memahami model. Jangan beralih secara acak antara menggunakan “ID” (seperti CustomerID ) dan “Nomor” (AccountNumber ) sebagai kunci untuk tabel. Hanya membuat pengecualian terhadap konvensi ketika mereka dibenarkan. Dokumentasikan pengecualian dan mengapa konvensi tidak dihormati.

Hal yang sama berlaku untuk nama samar seperti “XRT1” – apakah itu tabel referensi yang diperluas? Tebakan Anda sama baiknya dengan tebakan saya. Saya berharap perancang tahu mengapa dia memilih nama yang begitu samar, tetapi saya ragu bahwa orang berikutnya yang mengakses database dapat menebak alasannya.

Konvensi penamaan adalah masalah pilihan pribadi. Pastikan keputusan konsisten dan didokumentasikan.

Jika saya berhasil meyakinkan Anda untuk menerapkan konvensi penamaan dalam desain database Anda, silakan baca artikel saya berikutnya yang sepenuhnya dikhususkan untuk subjek ini.

4. Pikirkan Baik-Baik Tentang Kunci

Kunci sering menimbulkan kontroversi:kunci utama, kunci asing, dan kunci buatan. Tabel membutuhkan kunci utama yang mengidentifikasi setiap baris. Seninya adalah memutuskan kolom mana yang harus menjadi bagian dari kunci utama dan nilai apa yang akan disertakan.

Untuk normalisasi yang tepat, setiap tabel membutuhkan kunci pengenal. Keunikan harus dijamin. Namun, kunci alami dan kunci utama tidak harus sama. Faktanya, mereka mungkin tidak, selama tabel memiliki kunci alami.

Beberapa pemodel data lebih memilih kunci buatan untuk keunikan. Namun beberapa pemodel lebih memilih kunci alami untuk memastikan integritas data.

Jadi, haruskah kita menggunakan kunci alami sebagai kunci utama? Satu tantangan muncul jika kunci alami harus diubah. Jika kunci alami terdiri dari banyak kolom, Anda mungkin perlu membuat perubahan di banyak tempat. Tantangan lainnya adalah menggunakan kunci buatan sebagai satu-satunya kunci untuk tabel.

Sebagai contoh, Anda mungkin memiliki tabel yang menyimpan informasi tentang produk. Tabel dapat didefinisikan dengan kunci buatan seperti urutan, kode untuk nama alfabet pendek untuk produk dan definisi produk. Jika keunikan dipastikan hanya dengan kunci buatan, mungkin ada dua baris dengan kode produk yang sama. Apakah ini produk yang sama yang dimasukkan dua kali? Mungkin kunci dengan kode produk lebih sesuai.

5. Gunakan Pemeriksaan Integritas dengan Hati-hati

Untuk memastikan integritas data, kita memerlukan kunci dan batasan asing. Berhati-hatilah untuk tidak menggunakan pemeriksaan integritas ini secara berlebihan atau kurang.

Tabel domain efektif untuk menegakkan integritas. Tabel domain berfungsi dengan baik bila ada banyak nilai yang harus diperiksa, atau nilai yang akan diperiksa sering berubah.

Salah satu masalahnya adalah pengembang memutuskan bahwa aplikasi akan memeriksa integritas. Masalahnya di sini adalah bahwa database pusat dapat diakses oleh banyak aplikasi. Selain itu, Anda biasanya ingin melindungi data di tempatnya:di database.

Jika nilai yang mungkin terbatas atau dalam rentang, maka batasan pemeriksaan mungkin lebih disukai. Katakanlah pesan didefinisikan sebagai Masuk atau Keluar, dalam hal ini tidak diperlukan kunci asing. Tapi, untuk sesuatu seperti mata uang yang valid, meskipun ini mungkin tampak statis, mereka sebenarnya berubah dari waktu ke waktu. Negara-negara bergabung dengan serikat mata uang dan mata uang berubah.

Aplikasi juga harus melakukan pemeriksaan integritas, tetapi jangan hanya mengandalkan aplikasi untuk pemeriksaan integritas. Mendefinisikan aturan integritas pada database memastikan bahwa aturan tersebut tidak akan pernah dilanggar. Dengan cara ini, data memenuhi aturan integritas yang ditentukan setiap saat.

6. Jangan Lupakan Indeks dalam Desain Anda

Beberapa desain pengindeksan berguna selama pemodelan basis data, bahkan jika indeks dapat berubah selama penerapan dan penggunaan yang sebenarnya. Tentu saja, mungkin saja memiliki terlalu banyak indeks, seperti halnya mungkin memiliki terlalu sedikit.

Pengindeksan adalah proses yang berkelanjutan. Selama desain, Anda memulai proses pada model Anda. Pekerjaan desain ada pada kunci dan batasan utama.

Indeks penting ketika mempertimbangkan kueri pada data. Saat memodelkan, Anda harus mempertimbangkan bagaimana data akan ditanyakan. Berhati-hatilah untuk tidak mengindeks secara berlebihan. Pengindeksan berkisar seputar pengoptimalan kueri.

7. Hindari Tabel Pencarian Umum

Saya sering melihat tabel pencarian umum untuk pasangan atribut. Mendefinisikan satu, tabel domain generik dianggap menyederhanakan desain. Gaya tabel domain ini membuat definisi abstrak untuk menyimpan teks. Saya pernah mendengarnya disebut tabel “Allowed Value” atau “Valid Values”, tetapi istilah tabel “MUCK” diciptakan untuk anti-pola ini pada tahun 2006:Massively Unified Code-Key.

Tabel MUCK berisi data yang tidak terkait.

Misalnya, Anda dapat memiliki tabel yang mendefinisikan domain, entri, dan deskripsi. Memikirkan kembali contoh pesan di atas, dua entri mungkin:

Sekarang tambahkan entri untuk domain lain:

Ini hanya kekacauan. Apa yang dimaksud dengan tabel?

Hanya untuk bersenang-senang, saya membuat contoh sederhana tabel MUCK (atau OTLT, "One True Lookup Table" jika Anda adalah penggemar Tolkien) dan menyertakan beberapa komentar. Harap perhatikan bahwa ini adalah anti-pola dan saya tidak menyarankan Anda menggunakannya dalam model data Anda.

Dengan tabel MUCK, batasan tidak dapat didefinisikan. MUCK bisa menjadi banyak baris tanpa arti. Saat Anda harus menanyakan tabel lain untuk memahami arti dari suatu bidang, ini tidak ideal.

Tabel "apa saja" ini membuat pemeriksaan integritas menjadi rumit atau bahkan tidak mungkin. Salah satu alasan tabel ini dapat dibuat adalah karena beberapa tabel dalam database memiliki definisi yang serupa. Kemudian pemeriksaan integritas data menjadi tidak mungkin. Juga, ukurannya mungkin menjadi cukup besar.

Normalisasi harus menjauh dari tabel MUCK. Sebuah tabel tunggal harus mewakili satu domain; daripada tabel tunggal (MUCK) yang mewakili semua domain. Tanpa tabel MUCK, kita dapat menempatkan batasan kunci asing.

Gunakan tabel terpisah untuk objek domain daripada menjejalkannya ke dalam satu tabel. Hal ini memungkinkan jenis kolom yang tepat, kendala dan hubungan. Tabel “Nilai yang Diizinkan” hanyalah sampah dan tidak memiliki tempat dalam model data.

8. Tentukan Strategi Pengarsipan

Terlalu sering, saya melihat database dibuat tanpa strategi penyimpanan dan pengarsipan data yang tepat. Berapa lama data disimpan online tersedia di tabel database aktif? Sebagian besar sistem dibangun untuk menyimpan data dalam database "selamanya". Untuk sebagian besar sistem, ini bukan strategi penyimpanan data jangka panjang yang masuk akal. Pada titik tertentu, data aktif harus diarsipkan.

Salah satu pendekatan yang saya anjurkan adalah memasukkan retensi data sebagai bagian dari pertimbangan desain Anda. Apakah Anda akan memiliki tabel aktif dan historis sehingga penyisipan baris baru di tabel aktif tetap cepat, sementara penelusuran pada data historis dapat dioptimalkan?

Ini menghindari keharusan mendesain ulang pengarsipan ke dalam database Anda di atas desain aslinya.

9. Tes Lebih Awal, Tes Sering

Mengutip Al Capone (atau John Van Buren, putra Presiden AS ke-8), "uji lebih awal, sering uji". Dengan cara ini, Anda mengikuti jalur Integrasi Berkelanjutan. Pengujian pada tahap pengembangan awal menghemat waktu dan uang.

Pengujian selalu menjadi tantangan dalam rencana pengembangan. Seringkali ada fase pengujian di akhir Agile Sprint dan pengujian sistem di akhir pengembangan. Pengujian umumnya adalah hal pertama yang harus dilakukan ketika waktu semakin singkat.

Dalam menguji database, tujuannya adalah untuk mensimulasikan lingkungan produksi:“A Day in the Life of the Database”. Berapa volume yang bisa diharapkan? Interaksi pengguna apa yang mungkin terjadi? Apakah kasus perbatasan sedang ditangani?

Jadi rencana pengujian dan pengujian yang tepat harus menjadi bagian integral dari pemodelan data dan pengembangan basis data.

Kesimpulan

Ini adalah masalah utama yang saya lihat saat bekerja dengan pemodel data dan meninjau model data. Dengan memperhatikan tips ini, database Anda akan dirancang lebih baik dan lebih kuat. Namun, pengembalian beberapa investasi ini tidak selalu jelas atau terlihat. Rencanakan, dokumentasikan, gunakan standar, buat kunci, pastikan integritas, lakukan pengindeksan, hindari MUCK, kembangkan strategi, dan UJI!

Tak satu pun dari aktivitas ini akan memakan banyak waktu namun berdampak besar pada kualitas model data Anda.

Apa pandangan Anda tentang kiat-kiat ini?

Apakah Anda punya kiat sendiri?