Saat menulis posting blog tentang pemodelan basis data, Anda harus siap bahwa model abstrak Anda tidak memenuhi kebutuhan sebagian besar pembaca. Alasannya sederhana. Model database kehidupan nyata biasanya dibuat terkait erat dengan kebutuhan bisnis dan pengembangan tertentu, sedangkan model blog tidak.
Selama beberapa minggu terakhir, saya telah menulis posting blog tentang membuat model database. Topik berkisar dari pendekatan umum untuk pemodelan basis data melalui forum online sederhana hingga model untuk survei online yang lebih kompleks.
Untuk setiap model database yang saya buat, saya mencoba untuk memahami dengan jelas domain bisnis dan memikirkan gambaran besar model tersebut.
Tantangan Pengembangan Database Abstrak
Biasanya, sebagai solusi arsitek , saya mengambil persyaratan bisnis tertentu dan mengubahnya menjadi detail teknis tentang apa yang perlu dibuat dari sisi teknis:menerjemahkan dari bahasa bisnis ke bahasa teknis – merancang algoritme pada tingkat tinggi dan memodelkan persyaratan data untuk algoritme.
Sayangnya, saya tidak bisa membuat blog tentang model database dunia nyata yang saya buat di tempat kerja. Untuk satu hal, mereka sangat spesifik untuk domain bisnis dan untuk yang lain saya dibatasi oleh perjanjian kerahasiaan. Untuk blog, saya membuat murni abstrak konsep tanpa persyaratan bisnis khusus kecuali yang saya bayangkan ada dalam domain bisnis. Sekarang, itu bagus; Saya memiliki imajinasi yang cukup bagus dan saya sering menunjukkan bahwa persyaratan Anda mungkin berbeda ketika saya menjelaskan pilihan yang saya buat. Tetapi proses blogging ini membuat saya berpikir tentang betapa berbedanya proses ini dengan membuat model dalam proyek nyata.
Proses Pengembangan Kehidupan Nyata
Dalam situasi nyata, saya akan bekerja sama dengan tim pengembangan setelah membuat solusi tingkat tinggi dan desain teknis dalam interaktif sedemikian rupa sehingga model sesuai dengan kebutuhan pengembangan.
Pengembang mungkin mengeluh bahwa model data terlalu dinormalisasi untuk mendukung kinerja tinggi, atau mereka mungkin meminta normalisasi tambahan di area tertentu. Jika ada Kunci Alternatif yang hilang, pengembang akan mengeluh dengan cepat dan kami juga akan melihatnya selama pengujian kinerja database.
Kami akan mempertimbangkan apa panjang bidang yang tepat harus didasarkan pada panjang maksimum data yang akan disimpan dan pada desain layar untuk input dan tampilan data. Tentu saja, panjang bidang yang tepat dalam model database konseptual tidak penting.
Kami akan mengerjakan contoh data apa yang akan disimpan dalam tabel dan bagaimana data itu akan digunakan oleh aplikasi, dan membuat skrip untuk mengisi tabel terlebih dahulu untuk pengujian unit aplikasi. Dengan cara ini, kami akan menangkap kasus sudut untuk memastikan bahwa model mendukung batas aplikasi.
Jadi, pada dasarnya, kami akan memijat model hingga benar-benar mendukung kebutuhan bisnis dan non-fungsional sistem menggunakan proses berulang hingga kami mengembangkan model menjadi sesuatu yang dapat kami terima meskipun ada kompromi di dalamnya.
Seperti yang saya katakan, ini akan menjadi proses yang sangat berulang yang mungkin berlanjut selama berbulan-bulan sementara kode aplikasi, antarmuka pengguna, dan antarmuka aplikasi sedang dikembangkan.
Batasan Umpan Balik dengan Niat Baik
Dalam situasi blogging saat ini, sementara jumlah pembaca saya yang memang terbatas memberi saya umpan balik tentang masalah dan tantangan yang mereka amati dengan model, itu pasti dangkal. Saya ragu ada pembaca yang langsung menggunakan model untuk membuat aplikasi dan menemukan apa yang benar-benar berfungsi dan di mana ada masalah.
Jadi komentar seperti "model tidak dipikirkan dengan baik" hampir pasti benar. Di sisi lain, “ada FK yang hilang” cukup tepat, tetapi semoga saya telah menjelaskan dalam teks artikel mengapa saya memasukkan kunci asing atau tidak.
Kesimpulan
Sekarang, tolong jangan membaca posting ini sebagai keluhan atau komentar tentang umpan balik yang dibuat pembaca, melainkan saya merenungkan sulitnya membuat model database ketika Anda tidak berada dalam lingkungan yang memungkinkan pertukaran interaktif dengan iteratif. proses pengembangan.
Mungkin ada situasi lain di mana pemodel database terputus dari proses pengembangan, tetapi sekarang saya menyadari betapa berbahayanya hal itu dan betapa rentannya mereka terhadap masalah.
Dapatkah Anda membayangkan model database yang tidak pernah berubah? Tidak pernah satu penyesuaian kolom, tidak pernah tambahan kunci asing, tidak pernah perlu tabel baru. Sejujurnya, satu-satunya situasi yang bisa saya bayangkan seperti itu adalah ketika aplikasi yang menggunakan database tidak lagi berkembang dan telah mencapai jalan buntu:end of life.
