Pentingnya Diagram ER

Saya seorang mahasiswa dan saya sedang mengembangkan beberapa proyek sebagai bagian dari akademisi saya.

Saat mengembangkan database untuk salah satu proyek, kami menemukan situasi di mana kami memikirkan apakah ERD diperlukan atau tidak. Saat ini, tidak semua dari kita sepakat untuk mengembangkan ERD terlebih dahulu, dan kemudian mengembangkan database darinya.

Mayoritas orang lebih suka mengembangkan database dengan cepat sesuai dengan persyaratan sistem dan langsung di atas kertas.

Sekarang, saya adalah pengikut ketat prinsip-prinsip Database. Saya pikir database harus dikembangkan dari ERD saja. Jadi, saya hanya ingin tahu yang berikut:

• Apakah industri mengikuti prinsip-prinsip ini?
• Apakah saya hanya membuang-buang waktu untuk mengembangkan ERD?
• Apa manfaat mengembangkan ERD?

Polos dan sederhana, pikirkan mengembangkan database tanpa ERD sebagai membangun rumah tanpa rencana bangunan. Mungkin bisa dilakukan karena Anda berpikir bahwa hanya dengan meletakkan batu bata satu sama lain sudah cukup untuk membangun sesuatu, namun saat orang lain mengambil tanggung jawab atas proyek ada potensi bencana.

Dalam pengalaman saya, Anda tidak akan mendapat banyak manfaat dari ERD kecuali Anda menggunakannya bersama dengan alat CASE (ERWin, MySQL Workbench dll.) Yang juga akan memungkinkan Anda untuk melakukan beberapa operasi yang sangat membantu seperti teknik maju dan mundur. Bahkan tanpa fungsi-fungsi ini memiliki skema terpusat dari database lengkap berguna karena kadang-kadang kendala yang diterapkan dalam database itu sendiri tidak cukup untuk menceritakan kisah lengkap tentang hubungan antara entitas database tertentu.

Berikut adalah contoh yang melibatkan MySQL yang, seperti Anda ketahui, mengimplementasikan beberapa mesin penyimpanan internal, terutama MyISAM dan InnoDB. Ada perbedaan yang signifikan di antara mereka salah satu yang paling penting adalah bahwa MyISAM tidak mendukung kendala. Terlepas dari kenyataan itu MyISAM banyak digunakan untuk aplikasi web yang berarti bahwa logika relasional perlu diimplementasikan baik melalui logika bisnis (kode aplikasi) atau dengan cara lain. Masalahnya adalah ketika Anda meneruskan insinyur ERD dengan tabel MyISAM (entitas) MySQL akan diam-diam mengabaikan kendala yang ditetapkan oleh ERD dan Anda akan berakhir dengan database yang tidak secara jelas mengidentifikasi sifat hubungan antara entitas. Dengan kata lain setelah Anda mengembangkan tata letak database tidak ada cara bagi pengembang kode untuk menerapkan logika bisnis yang tepat tanpa ERD.

ERD sangat bagus untuk memiliki gambaran yang jelas tentang struktur basis data Anda. Selain menjadi artefak dokumen penting untuk proyek Anda, itu memudahkan ketika Anda perlu mengimplementasikan kueri, terutama bergabung di antara tabel. Bayangkan betapa menyenangkannya memiliki konfigurasi monitor ganda, di sebelah kiri Anda memiliki ERD dan di sebelah kanan editor kueri Anda. Anda dapat dengan jelas melihat hubungan di antara tabel dan menulis kueri Anda berdasarkan itu. Jika proyek basis data Anda cukup sederhana, dan proyek Anda tidak memerlukannya, mungkin boleh saja hidup tanpanya.

ERD akan menghemat lebih banyak waktu daripada yang Anda pikirkan, Jika Anda melakukan semuanya dengan cepat, maka Anda akan macet ketika Anda ingin membuat tabel persimpangan.

Jika Anda menemukan database beberapa tahun kemudian tanpa ERD, Anda harus menghabiskan banyak waktu untuk melihat apa yang terjadi di proyek Anda.

Saya memiliki perusahaan dan kami merancang ERD, jangan pernah berpikir tentang database tanpa ERD. (Sebenarnya ini adalah eksperimen pribadi saya)

ERD dulu lebih umum beberapa waktu lalu. IMO mereka lebih atau kurang opsional sekarang.

Saat ini, beberapa tim yang sangat sukses sama sekali tidak peduli dengan ERD, namun memberikan sistem yang sangat baik: kuat, berkinerja tinggi, dan mudah dipertahankan dalam jangka panjang. Ini terutama benar dalam pengembangan Agile, ketika kita memulai dari yang kecil, dengan seperangkat alat yang minimalis.

ERD adalah cara komunikasi yang baik, tentu saja, tetapi tidak berarti satu-satunya cara, atau yang terbaik dalam semua situasi. Beberapa tim lebih suka cara dokumentasi dan komunikasi lainnya.

Tidak ada aturan khusus dalam industri ini.

Sangat penting untuk merancang sebelum menulis kode produksi. Ini juga penting untuk prototipe; orang basis data mengembangkan prototipe dengan menulis SQL. (Ingat apa yang dikatakan Fred Brooks tentang prototipe?)

Bahasa grafis, yang ER hanya satu, belum terbukti sangat bagus dalam menangkap semua semantik dari database dengan cara yang mudah dan sederhana untuk dipahami.

Mereka juga belum terbukti menjadi alat komunikasi yang sangat efektif, kecuali antar pengembang. Tetapi dalam mendesain basis data, komunikasi penting bukanlah antara pengembang; itu antara pengembang dan pakar domain (antara pengembang dan pebisnis).

Object-Role Modeling (ORM) memiliki bahasa grafis, tetapi didasarkan pada "fakta" (kalimat sederhana). Pelaku bisnis dapat memvalidasi fakta dengan cukup mudah. Para pebisnis tidak dapat dengan mudah memvalidasi diagram ER atau diagram ORM.