Apa Langkah-Langkah Dalam Desain Basis Data?

Desain database adalah salah satu faktor terpenting yang berkontribusi pada kinerja aplikasi. Akibatnya, seberapa baik database dirancang adalah yang paling penting. Desain basis data adalah tentang mengatur data secara efisien berdasarkan alur kerja produk, peta jalan masa depan, dan pola penggunaan yang diharapkan.

Output dari latihan desain database adalah model data. Sebuah model data mewakili semua objek, entitas, atribut, hubungan, dan kendala dalam sistem. Secara garis besar, model data dapat terdiri dari dua jenis:logis atau fisik . Representasi model data dilakukan dengan membuat diagram ER, juga dikenal sebagai diagram hubungan entitas, diagram ERD, atau diagram database.

Model data fisik berkaitan dengan detail implementasi aktual dalam database. Model data logis, di sisi lain, mengabstraksikan teknis implementasi. Ini membuat model data logis dapat dikonsumsi untuk bisnis. Salah satu perbedaan utama antara kedua model adalah bahwa model logis adalah database-agnostik sedangkan model fisik harus spesifik untuk database yang digunakan.

Desain database yang tepat sering diremehkan dan diabaikan selama pengembangan aplikasi. Biaya pengabaian ini biasanya disadari jauh kemudian ketika fitur aplikasi baru masuk atau ketika fitur lama memerlukan perubahan. Ini adalah saat desain database tidak lagi masuk akal. Meskipun tidak mungkin untuk membuktikan desain database di masa depan, sangat mungkin untuk melakukan upaya terbaik untuk memahami kasus penggunaan bisnis dan mendesain database yang sesuai. Baca lebih lanjut tentang tips tentang desain database yang lebih baik di sini.

Dengan mengingat hal itu, mari kita ikuti langkah-langkah dalam desain database.

Langkah 1:Kumpulkan Persyaratan Bisnis

Langkah pertama adalah berbicara dengan bisnis tentang persyaratan mereka. Jika percakapan efektif, itu harus menghasilkan informasi yang cukup untuk mulai mengerjakan model data konseptual, yang merupakan abstraksi dari model logis. Berbicara dengan bisnis, pertama-tama, memberikan gambaran lengkap tentang proses bisnis, yang, pada gilirannya, memberikan informasi tentang berbagai titik data yang penting untuk ditangkap dan dilacak oleh bisnis. Misalnya, dalam model pemesanan taksi, ada baiknya mengajukan pertanyaan berikut:

Apakah bisnis menginginkan data pelacakan kendaraan di database terlepas dari apakah ada perjalanan yang aktif atau tidak? Jika ya, maka kolom vehicle_trip_id dalam tabel vehicle_trips akan nullable . Jika tidak, itu tidak akan nullable .
Apakah bisnis menginginkan riwayat perubahan pada trip_status disimpan dalam database? Jika ya, maka setiap kali trip_status berubah, akan ada rekor lain di trips meja. Jika tidak, setiap kali trip_status perubahan, trip_status akan diperbarui di tempat.

Seperti yang ditunjukkan dalam contoh ini, berdasarkan masukan dari bisnis, Anda akhirnya akan memilih satu opsi di atas yang lain. Ini akan mengakibatkan perubahan entitas terkait dan hubungan mereka.

Pengumpulan kebutuhan juga umumnya melibatkan memulai percakapan tentang keamanan data, seperti data mana yang akan disembunyikan dan dienkripsi. Latihan pengumpulan persyaratan menghasilkan dokumen persyaratan yang sering kali didukung oleh draf kerja model data konseptual.

Langkah 2:Pahami Peta Jalan Bisnis

Bisnis mengubah proses mereka sepanjang waktu; kemampuan mereka untuk beradaptasi membuat mereka cenderung gagal. Mengubah proses bisnis berarti mengubah alur kerja dan model data. Meskipun tidak mungkin untuk mengetahui perubahan ini sebelumnya, sangat mungkin untuk mengetahui peta jalan bisnis.

Misalnya, jika sebuah perusahaan memiliki rencana untuk menargetkan wilayah geografis baru, model tersebut harus memenuhi dukungan bahasa, mata uang, zona waktu, dan sebagainya. Manfaat memahami peta jalan bisnis jangka panjang sering kali muncul dalam transisi yang lebih mulus ke proses bisnis baru.

Izinkan saya membagikan satu contoh lagi, yaitu tentang prioritas bisnis yang terus berkembang. Bisnis taksi terkena dampak buruk pada awal COVID-19. Sebagai perusahaan taksi, Anda ingin bertindak lebih dulu untuk meyakinkan orang-orang bahwa Anda melakukan segalanya untuk memastikan bahwa perjalanan Anda di dalam taksi seaman mungkin, bahwa kendaraan didesinfeksi setiap hari, bahwa pengemudi memakai masker sama sekali kali, dan bahwa ada pembersih tangan yang tersedia di dalam kabin. Sekarang, untuk menangkap semua informasi ini, ubah menjadi dua entitas, drivers dan vehicles , akan diperlukan. Beberapa bidang bendera Boolean perlu ditambahkan ke entitas ini untuk memenuhi kasus penggunaan bisnis ini.

Langkah 3:Identifikasi Entitas dan Atribut

Setelah persyaratan bisnis dikumpulkan, informasi tersebut dapat digunakan untuk mengidentifikasi entitas bersama dengan set atribut penting. Satu atau lebih entitas umumnya memetakan langsung ke proses bisnis, dan hubungan antara entitas tersebut juga meniru alur kerja proses bisnis.

Langkah ini juga digunakan untuk mengidentifikasi atribut mana yang akan bertindak sebagai pengidentifikasi dalam entitas. Identifier menerjemahkan ke kunci utama dalam model fisik. Selain itu, pada langkah ini juga umum untuk menentukan tipe data untuk semua atribut.

Misalnya, dalam model pemesanan taksi, Anda harus mengidentifikasi atribut yang akan bertindak sebagai bidang wajib untuk pendaftaran pengguna dan pengemudi dari aplikasi pemesanan. Pendaftaran pengguna akan dilakukan menggunakan user_phone dan registrasi driver akan dilakukan menggunakan driver_phone .

Demikian pula, entitas dan atribut lain diidentifikasi selama langkah ini, setelah dipetakan ke alur kerja proses bisnis.

Langkah 4:Identifikasi Hubungan

Setelah mengidentifikasi entitas dan atributnya, langkah selanjutnya adalah menentukan hubungan antar entitas berdasarkan alur kerja bisnis yang didokumentasikan dalam fase pengumpulan persyaratan. Selain menetapkan bahwa ada hubungan antara dua entitas, penting juga untuk mengidentifikasi mana dari empat jenis hubungan berikut yang ada di antara mereka. Pertimbangkan dua entitas arbitrer, A dan B:

Satu-ke-satu → Satu record di A berhubungan dengan paling banyak satu record di B.
Satu-ke-banyak → Satu record di A berhubungan dengan banyak record di B.
Many-to-one → Banyak record di A berhubungan dengan paling banyak satu record di B.
Many-to-many → Banyak record di A berhubungan dengan banyak record di B.

Dalam model pemesanan taksi, hanya satu jenis hubungan yang digunakan, yaitu satu-ke-banyak. Ambil hubungan antara users dan trips sebagai contoh. Dalam model, ada asumsi bahwa hanya satu pengguna yang dapat dikaitkan dengan perjalanan, yang menyiratkan bahwa tidak ada taksi bersama atau gabungan. Tetapi jika ada taksi bersama atau gabungan, mungkin akan ada hubungan banyak-ke-banyak antara users dan trips , jika banyak pengguna berbagi trip_id yang sama .

Langkah 5:Buat Diagram ER Logis

Dengan entitas, atribut, dan hubungan entitas yang ditentukan, langkah selanjutnya adalah menggambar diagram ER. Semua langkah yang tercantum di atas dapat dilakukan di dalam Vertabelo. Tidak ada aturan keras dan cepat untuk cara pemodelan logis seharusnya dilakukan, dengan kemungkinan pengecualian dari notasi referensi.

Sebagai contoh, lihat contoh diagram logika ER berikut. Ini menangkap alur kerja bisnis sederhana dari sebuah perusahaan taksi, di mana pengguna dapat memesan tumpangan dengan kemampuan untuk melacak kendaraan.

Langkah 6:Validasi Diagram Logical ER

Pemodelan logis adalah proses di mana banyak informasi bisnis perlu diterjemahkan ke dalam desain database. Tanpa pemeriksaan menyeluruh, fase pengembangan basis data ini rentan terhadap kesalahan yang dapat terbukti cukup mahal di tahap selanjutnya.

Untuk menangani hal ini, Vertabelo memiliki daftar pemeriksaan menyeluruh yang dapat dilakukan pada model logis. Pemeriksaan dapat dilakukan di semua perincian, dari model secara keseluruhan hingga atribut individual, dan semua yang ada di antaranya. Beberapa pemeriksaan sederhana adalah:

Nama entitas, atribut, hubungan, dll., tidak boleh nol dan harus unik.
Entitas harus memiliki setidaknya 1 atribut.
Identifier (PK) harus ditentukan untuk setiap entitas.
Model harus menggunakan salah satu tipe data yang terdaftar untuk atribut.

Semua pemeriksaan ini opsional dan dapat dikonfigurasi untuk dilewati, jika ada kerangka validasi lain. Validasi yang tepat dari Vertabelo membantu Anda melanjutkan ke langkah berikutnya dengan gesekan seminimal mungkin.

Langkah 7:Buat diagram ER Fisik

Setelah diagram logika ER dibuat, langkah selanjutnya adalah membuat model data fisik. Model data fisik akan khusus untuk database tempat Anda ingin menerapkan model data. Semua database memiliki implementasi unik dari aturan nomenklatur, tipe data, dan batasan. Oleh karena itu, Data Definition Language (DDL) sering kali berbeda antara satu database dengan database lainnya.

Untuk membuat model data fisik, ikuti langkah-langkah berikut:

Temukan tipe data terdekat dalam database target untuk menggantikan tipe data umum yang dipilih dalam model data logis.
Ikuti aturan nomenklatur untuk tabel, kolom, dan batasan seperti yang ditentukan oleh database target.
Ubah model untuk menyelaraskan dengan alur kerja kueri yang telah ditentukan sebelumnya. Ini biasanya menghasilkan peningkatan redundansi untuk menyimpan gabungan.
Terakhir, Anda dapat membuat indeks, partisi, kunci distribusi, dan kunci pengurutan. Ini adalah saat Anda dapat membuat modifikasi yang meningkatkan performa pada model.

Langkah-langkah ini dapat dilakukan menggunakan alat pemodelan data apa pun yang dapat Anda gunakan untuk membuat model data dari awal. Namun, Vertabelo memiliki opsi untuk mengonversi model data logis menjadi model data fisik lengkap untuk semua sistem basis data utama seperti MySQL, PostgreSQL, Oracle, Microsoft SQL Server, Amazon Redshift, Google BigQuery, dan banyak lagi. Setelah model data logis diubah menjadi model data fisik, Anda dapat melanjutkan dengan empat langkah yang telah kita diskusikan.

Vertabelo juga memiliki opsi untuk menambahkan skrip pra dan pasca penerapan di tingkat tabel bersama dengan komentar apa pun di tingkat model yang sangat terperinci. Komentar menjadi berguna ketika fitur pembuatan dokumentasi yang ditawarkan oleh Vertabelo digunakan. Dokumen database dapat diekspor ke salah satu dari tiga format berikut:HTML, PDF, atau DOCX.

Melanjutkan contoh pemesanan taksi, mari kita lihat model data fisik yang dihasilkan oleh Vertabelo.

Langkah 8:Validasi Diagram ER Fisik

Sama seperti diagram ER logis yang divalidasi, Vertabelo memiliki alat untuk memvalidasi diagram ER fisik dengan beberapa pemeriksaan tambahan, seperti apakah ada FK atau tidak dan apakah panjang nama tabel atau nama kolom melebihi batas berdasarkan database yang dipilih.

Validasi tidak perlu dijalankan secara eksplisit. Itu terjadi saat diagram dimodifikasi. Masalah dengan model termasuk dalam salah satu dari tiga kategori:kesalahan, peringatan, dan petunjuk, dalam urutan tingkat keparahan yang berkurang. Ada artikel bermanfaat dan ditulis dengan baik yang membahas tentang kesalahan umum yang dibuat selama proses desain basis data.

Langkah 9:Perbaiki Masalah Dengan Diagram ER Fisik

Hasil validasi dapat mengidentifikasi masalah yang perlu diperbaiki. Beberapa masalah yang paling umum adalah:

Kunci asing tempat hubungan entitas telah ditentukan tidak ada.
Kunci utama dari tabel tidak ada.
Tipe data yang tidak didukung untuk database yang dipilih.

Setelah masalah ini dan masalah serupa lainnya diselesaikan, model siap untuk diekspor ke skrip SQL yang dapat diterapkan untuk sistem manajemen database yang dipilih.

Langkah 10:Buat Skrip DDL untuk Menerapkan Model

Desain database bukan hanya tentang membuat diagram ER. Latihan pemodelan data menggunakan diagram ER hanya berhasil jika menghasilkan sesuatu yang dapat digunakan. Vertabelo memiliki opsi yang mudah untuk mengekspor model fisik ke skrip SQL yang siap digunakan. Setelah dibuat, semua masalah yang tertunda dapat diselesaikan secara langsung dalam skrip SQL.

Namun, mengubah skrip SQL yang dihasilkan tidak disarankan. Ini menyebabkan melayang antara model data fisik dan skrip SQL yang digunakan pada database, yang juga dapat berarti penyimpangan antara tabel aktual dan dokumentasi database.

Sekarang kita telah mencapai akhir dari proses desain database, mari kita lihat kode SQL yang dihasilkan oleh Vertabelo.

Bagikan Pendapat Anda

Desain database adalah aktivitas berdampak tinggi dalam pengembangan perangkat lunak. Bidang desain database telah berkembang selama bertahun-tahun dengan cara-cara baru untuk mewakili desain untuk bisnis, untuk para insinyur, dan untuk analis data. Hal ini sering menghasilkan jenis diagram, standar pemodelan, dan notasi baru. Sebagian besar evolusi telah dibahas di bagian dasar-dasar desain.

Kami akan senang melihat pengalaman Anda dalam mendesain database. Kirim surat kepada kami di [email protected].