Praktik Terbaik Desain Basis Data untuk Aplikasi Berkinerja Tinggi

Agar aplikasi memiliki kinerja yang baik, Anda memerlukan server aplikasi yang kuat, bandwidth yang terjamin dan cukup, dan pekerjaan pemrograman yang dilakukan dengan baik. Tetapi ada satu aspek yang tidak selalu diperhitungkan dan biasanya berdampak besar pada kinerja aplikasi apa pun: desain basis data .

Sekarang kita akan melihat praktik terbaik desain database untuk memastikan bahwa akses data bukanlah hambatan yang berdampak negatif pada kinerja aplikasi.

Apa tujuan dari desain database yang baik?

Selain meningkatkan kinerja akses data, desain yang baik memberikan manfaat lain, seperti menjaga konsistensi, akurasi, dan keandalan data, serta mengurangi ruang penyimpanan dengan menghilangkan redundansi. Manfaat lain dari desain yang baik adalah database lebih mudah digunakan dan dipelihara. Siapa pun yang harus mengelolanya hanya perlu melihat diagram hubungan entitas (ERD) untuk memahami strukturnya.

ERD adalah alat dasar desain database. Mereka dapat dibuat dan divisualisasikan pada tiga tingkat desain: konseptual , logis , dan fisik .

Desain konseptual menunjukkan diagram yang sangat ringkas, dengan hanya elemen yang diperlukan untuk menyepakati kriteria dengan pemangku kepentingan proyek, yang tidak perlu memahami detail teknis database. Desain logis menunjukkan entitas dan hubungan mereka secara rinci tetapi dengan cara database-agnostik.

Ada banyak alat yang dapat Anda gunakan untuk memfasilitasi desain database dari ERD. Di antara yang terbaik adalah DbSchema , SqlDBM , dan Vertabelo .

Skema Db

DbSchema memungkinkan Anda mendesain dan mengelola database SQL, NoSQL, atau Cloud secara visual. Alat ini memungkinkan Anda untuk merancang skema di komputer dan menyebarkannya ke beberapa database dan menghasilkan dokumentasi dalam diagram HTML5, menulis kueri, dan menjelajahi data secara visual, antara lain. Ini juga menawarkan sinkronisasi skema, pembuatan data acak, dan pengeditan kode SQL dengan pelengkapan otomatis.

SqlDBM

SqlDBM adalah salah satu alat desain diagram database terbaik karena menyediakan cara mudah untuk mendesain database Anda di browser apa pun. Tidak ada mesin database atau alat pemodelan lain yang diperlukan untuk menggunakannya, meskipun SqlDBM memungkinkan Anda untuk mengimpor skema dari database yang ada. Ini sangat ideal untuk kerja tim, karena memungkinkan Anda untuk berbagi proyek desain dengan rekan kerja.

Vertabel

Vertabelo adalah alat desain basis data visual online yang memungkinkan Anda merancang basis data secara logis dan secara otomatis memperoleh skema fisik. Itu dapat membalikkan rekayasa, menghasilkan diagram dari database yang ada, dan mengontrol akses ke diagram dengan membedakan hak akses ke pemilik, editor, dan pemirsa.

Akhirnya, desain fisik adalah yang menambahkan ke ERD semua detail yang diperlukan untuk mengubahnya menjadi database yang dapat digunakan dalam DBMS tertentu, seperti MySQL, MariaDB, MS SQL Server, atau lainnya. Mari kita lihat praktik terbaik yang perlu diingat saat merancang ERD sehingga database yang dihasilkan berfungsi dengan baik.

Tentukan jenis database yang akan dirancang

Dua tipe dasar database biasanya dibedakan: relasional dan dimensional .

Database relasional digunakan untuk aplikasi tradisional yang mengeksekusi transaksi pada data – yaitu, mereka mendapatkan informasi dari database, memprosesnya, dan menyimpan hasilnya.

Di sisi lain, basis data Dimensi digunakan untuk pembuatan gudang data: penyimpanan informasi yang besar untuk analisis data dan penambangan data untuk mendapatkan wawasan.

Langkah pertama dalam setiap tugas desain database adalah memilih salah satu dari dua tipe database utama untuk digunakan: relasional atau dimensional. Sangat penting untuk memiliki ini jelas sebelum Anda mulai merancang. Jika tidak, Anda dapat dengan mudah jatuh ke dalam kesalahan desain yang pada akhirnya akan menyebabkan banyak masalah dan akan sulit (atau tidak mungkin) untuk diperbaiki.

Mengadopsi Konvensi Penamaan

Nama-nama yang digunakan dalam desain database sangat penting karena, begitu sebuah objek dibuat dalam database, mengubah namanya bisa berakibat fatal. Mengubah hanya satu huruf dari nama dapat merusak ketergantungan, hubungan, dan bahkan seluruh sistem.

Itulah mengapa sangat penting untuk bekerja dengan konvensi penamaan yang sehat: seperangkat aturan yang menyelamatkan Anda dari kesulitan mencoba 50 kemungkinan berbeda untuk menemukan nama objek yang tidak dapat Anda ingat.

Tidak ada panduan universal tentang bagaimana seharusnya konvensi penamaan untuk melakukan tugasnya. Tetapi yang penting adalah membuat konvensi penamaan sebelum memberi nama objek apa pun dalam database dan mempertahankan konvensi itu selamanya. Konvensi penamaan menetapkan pedoman seperti apakah akan menggunakan garis bawah untuk memisahkan kata atau menggabungkannya secara langsung, apakah akan menggunakan semua huruf kapital atau kata dengan huruf besar (gaya Camel Case), apakah akan menggunakan kata jamak atau tunggal untuk menamai objek dan seterusnya.

Mulailah dengan desain konseptual, kemudian desain logis, dan akhirnya desain fisik.

Itu adalah tatanan alam. Sebagai seorang desainer, Anda mungkin tergoda untuk memulai dengan membuat objek langsung di DBMS untuk melewati langkah-langkah. Tetapi ini akan mencegah Anda memiliki alat untuk berdiskusi dengan pemangku kepentingan untuk memastikan bahwa desain memenuhi persyaratan bisnis.

Setelah desain konseptual, Anda harus beralih ke desain logis untuk memiliki dokumentasi yang memadai untuk membantu programmer memahami struktur database. Sangat penting untuk menjaga desain logis diperbarui agar tidak bergantung pada mesin database yang akan digunakan. Dengan cara ini, jika Anda akhirnya memigrasi database ke mesin yang berbeda, desain logis akan tetap berguna.

Akhirnya, desain fisik dapat dibuat oleh pemrogram sendiri atau oleh DBA, mengambil desain logis dan menambahkan semua detail implementasi yang diperlukan untuk mengimplementasikannya pada DBMS tertentu.

Membuat dan memelihara kamus data

Bahkan jika ERD jelas dan deskriptif, Anda harus menambahkan kamus data untuk membuatnya lebih jelas. Kamus data mempertahankan koherensi dan konsistensi dalam desain database, terutama ketika jumlah objek di dalamnya bertambah secara signifikan.

Tujuan utama kamus data adalah untuk memelihara satu tempat penyimpanan informasi referensi tentang entitas model data dan atributnya. Kamus data harus berisi nama semua entitas, nama semua atribut, format dan tipe datanya, dan deskripsi singkat masing-masing.

Kamus data menyediakan panduan yang jelas dan ringkas untuk semua elemen yang membentuk database. Ini menghindari pembuatan beberapa objek yang mewakili hal yang sama, yang menyulitkan untuk mengetahui objek mana yang akan digunakan saat Anda perlu menanyakan atau memperbarui informasi.

Pertahankan kriteria yang konsisten untuk kunci utama

Keputusan untuk menggunakan kunci alami atau kunci pengganti harus konsisten dalam model data. Jika entitas dalam model data memiliki pengidentifikasi unik yang dapat dikelola secara efisien sebagai kunci utama dari tabel masing-masing, tidak perlu membuat kunci pengganti.

Tetapi biasanya entitas diidentifikasi oleh beberapa atribut dari tipe yang berbeda – tanggal, angka, dan/atau string karakter yang panjang – yang mungkin tidak efisien untuk membentuk kunci utama. Dalam kasus ini, lebih baik untuk membuat kunci pengganti tipe bilangan bulat, yang memberikan efisiensi maksimum dalam manajemen indeks. Dan kunci pengganti adalah satu-satunya pilihan jika suatu entitas tidak memiliki atribut yang secara unik mengidentifikasinya.

Gunakan tipe data yang benar untuk setiap atribut.

Data tertentu memberi kita pilihan untuk memilih tipe data mana yang akan digunakan untuk mewakilinya. Tanggal, misalnya. Kita dapat memilih untuk menyimpannya di bidang tipe tanggal, bidang tipe tanggal/waktu, bidang tipe varchar, atau bahkan bidang tipe numerik. Kasus lain adalah data numerik yang tidak digunakan untuk operasi matematika tetapi untuk mengidentifikasi suatu entitas, seperti nomor SIM atau kode pos.

Dalam hal tanggal, akan lebih mudah untuk menggunakan tipe data mesin, yang membuatnya lebih mudah untuk memanipulasi data. Jika Anda hanya perlu menyimpan tanggal acara tanpa menentukan waktu, tipe data yang akan dipilih adalah Tanggal; jika Anda perlu menyimpan tanggal dan waktu saat peristiwa tertentu terjadi, tipe datanya harus DateTime.

Menggunakan jenis lain, seperti varchar atau numerik, untuk menyimpan tanggal mungkin nyaman tetapi hanya dalam kasus yang sangat khusus. Misalnya, jika tidak diketahui sebelumnya dalam format apa tanggal akan diekspresikan, akan lebih mudah untuk menyimpannya sebagai varchar. Jika kinerja pencarian, pengurutan, atau pengindeksan sangat penting dalam menangani bidang tipe tanggal, konversi sebelumnya ke float dapat membuat perbedaan.

Data numerik yang tidak terlibat dalam operasi matematika harus direpresentasikan sebagai varchar, menerapkan validasi format dalam rekaman untuk menghindari inkonsistensi atau pengulangan. Jika tidak, Anda menghadapi risiko bahwa beberapa data melebihi batasan bidang numerik dan memaksa Anda untuk memfaktorkan ulang desain saat sudah dalam produksi.

Penggunaan tabel pencarian

Beberapa desainer yang tidak berpengalaman mungkin percaya bahwa penggunaan tabel pencarian yang berlebihan untuk menormalkan desain dapat memperumit ERD database yang tidak perlu karena menambahkan sejumlah besar tabel "satelit" yang terkadang tidak memiliki lebih dari beberapa elemen. Mereka yang berpikir ini harus memahami bahwa penggunaan tabel pencarian memiliki lebih banyak manfaat daripada kerugian. Jika kompleksitas atau ukuran ERD menjadi masalah, ada alat desain ERD yang memungkinkan Anda memvisualisasikan diagram dengan cara yang berbeda untuk dipahami terlepas dari kerumitannya.

Kueri contoh ini menggambarkan penggunaan tabel pencarian yang benar dalam database yang dirancang dengan baik:

 SELECT StreetName, StreetNumber, Cities.Name AS City, States.Name AS State FROM Addresses INNER JOIN Cities ON Cities.CityId = Addresses.CityId INNER JOIN States ON States.StateId = Addresses.StateId

Dalam hal ini, kami menggunakan tabel pencarian untuk Kota dan Negara Bagian.

Manfaat tabel pencarian termasuk mengurangi ukuran database, meningkatkan kinerja pencarian, dan memberlakukan pembatasan pada kumpulan data yang valid yang dapat berisi bidang, antara lain. Ini juga merupakan praktik yang baik untuk semua tabel pencarian untuk menyertakan bidang Bit atau Boolean yang menunjukkan apakah catatan dalam tabel sedang digunakan atau sudah usang. Bidang ini dapat digunakan sebagai filter untuk menghindari elemen usang sebagai opsi di UI aplikasi.

Normalisasi atau denormalisasi sesuai dengan tipe database

Dalam database relasional yang digunakan untuk aplikasi tradisional, normalisasi adalah suatu keharusan. Normalisasi mengurangi ruang penyimpanan yang diperlukan dengan menghindari redundansi. Ini meningkatkan kualitas informasi dan menyediakan banyak alat untuk mengoptimalkan kinerja dalam kueri yang kompleks.

Namun, dalam jenis database lain, teknik yang dikenal sebagai denormalisasi diterapkan. Dalam database dimensional, yang digunakan sebagai gudang data, denormalisasi menambahkan informasi redundan tertentu yang berguna dalam tabel skema.

Meskipun tampaknya merupakan konsep yang berlawanan, denormalisasi tidak berarti membatalkan normalisasi. Ini sebenarnya adalah teknik pengoptimalan yang diterapkan pada model data setelah dinormalisasi untuk menyederhanakan penulisan dan pelaporan kueri.

Merancang model fisik di bagian

Dalam proyek pengembangan perangkat lunak, perancang basis data menyajikan model konseptual skala besar kepada pemangku kepentingan, di mana tidak ada detail implementasi yang ditampilkan. Pada gilirannya, untuk bekerja dengan pengembang, perancang harus menyediakan model fisik dengan semua detail setiap entitas dan atribut. Namun, kedua model tidak perlu dibuat sepenuhnya di awal proyek.

Saat menerapkan metodologi tangkas, setiap pengembang di awal setiap siklus pengembangan membutuhkan satu atau lebih cerita pengguna untuk dikerjakan selama siklus itu. Tugas perancang basis data adalah menyediakan setiap pengembang dengan submodel fisik yang hanya mencakup objek yang mereka butuhkan untuk unit kerja.

Pada akhir setiap siklus pengembangan, submodel yang dibuat selama siklus tersebut digabungkan sehingga model fisik lengkap berbentuk paralel dengan pengembangan aplikasi.

Memanfaatkan tampilan dan indeks dengan baik

Tampilan dan indeks adalah dua alat dasar dalam desain database untuk meningkatkan kinerja aplikasi. Penggunaan tampilan memungkinkan penanganan abstraksi yang menyederhanakan kueri, menyembunyikan detail tabel yang tidak perlu. Pada gilirannya, tampilan membuat tugas pengoptimalan kueri lebih mudah untuk mesin basis data karena memungkinkan mereka mengantisipasi bagaimana data akan diperoleh dan memilih strategi terbaik untuk memberikan hasil kueri lebih cepat.

Indeks dapat meningkatkan kinerja kueri lambat berdasarkan pengalaman pengguna setelah database dalam produksi. Namun, pembuatan indeks dapat dilakukan sebagai bagian dari tugas desain database, mengantisipasi kebutuhan aplikasi.

Untuk pembuatan indeks, Anda perlu memiliki perkiraan perkiraan besarnya setiap tabel – dalam hal jumlah catatan – dan kemudian membuat indeks untuk tabel yang lebih besar. Untuk memilih bidang yang akan disertakan dalam indeks, Anda harus mempertimbangkan terutama bidang yang mewakili kunci asing dan bidang yang akan digunakan sebagai filter dalam pencarian.

Ketika Anda berpikir bahwa pekerjaan sudah selesai, sekarang saatnya untuk refactor.

Desain database selalu dapat ditingkatkan. Ketika tidak ada perubahan pada database karena persyaratan baru atau kebutuhan bisnis baru, ini adalah kesempatan yang baik untuk melakukan prosedur refactoring yang meningkatkan desain. Refactoring berarti: memperkenalkan perubahan yang meningkatkan desain tanpa mempengaruhi semantik database.

Ada banyak teknik refactoring untuk meningkatkan desain database yang berada di luar cakupan artikel ini, tetapi ada baiknya mengetahui keberadaan mereka untuk menggunakannya saat dibutuhkan.

Memiliki daftar praktik terbaik ini kapan pun Anda perlu mendesain database akan memungkinkan Anda memperoleh hasil terbaik sehingga aplikasi selalu mempertahankan kinerja optimal dalam akses data.