Desain basisdata adalah organisasi data menurut model database. Perancang menentukan data apa yang harus disimpan dan bagaimana elemen data saling berhubungan. Dengan informasi ini, mereka dapat mulai menyesuaikan data dengan model database. Sistem manajemen basis data mengelola data yang sesuai.
Desain basis data melibatkan pengklasifikasian data dan pengidentifikasian hubungan timbal balik. Representasi teoritis dari data ini disebut ontologi. Ontologi adalah teori di balik desain database.
Menentukan data yang akan disimpan
Dalam sebagian besar kasus, orang yang melakukan desain database adalah orang dengan keahlian di bidang desain database, bukan keahlian dalam domain dari mana data yang akan disimpan diambil mis. informasi keuangan, informasi biologis, dll. Oleh karena itu, data yang akan disimpan dalam database harus ditentukan melalui kerja sama dengan orang yang memang memiliki keahlian dalam domain tersebut, dan siapa yang mengetahui data apa yang harus disimpan dalam sistem.
Proses ini adalah salah satu yang umumnya dianggap sebagai bagian dari analisis kebutuhan, dan membutuhkan keterampilan dari desainer database untuk memperoleh informasi yang dibutuhkan dari mereka yang memiliki pengetahuan domain. Ini karena mereka yang memiliki pengetahuan domain yang diperlukan seringkali tidak dapat mengungkapkan dengan jelas apa persyaratan sistem mereka untuk database karena mereka tidak terbiasa berpikir dalam hal elemen data diskrit yang harus disimpan. Data yang akan disimpan dapat ditentukan dengan Spesifikasi Kebutuhan.
Menentukan hubungan data
Setelah perancang basis data mengetahui data yang akan disimpan di dalam basis data, mereka kemudian harus menentukan di mana ketergantungan berada di dalam data. Terkadang ketika data diubah, Anda dapat mengubah data lain yang tidak terlihat. Misalnya, dalam daftar nama dan alamat, dengan asumsi situasi di mana beberapa orang dapat memiliki alamat yang sama, tetapi satu orang tidak dapat memiliki lebih dari satu alamat, alamat tergantung pada nama. Ketika diberikan nama dan daftar alamat dapat ditentukan secara unik; namun, kebalikannya tidak berlaku - ketika diberi alamat dan daftar, nama tidak dapat ditentukan secara unik karena banyak orang dapat tinggal di sebuah alamat. Karena sebuah alamat ditentukan oleh sebuah nama, sebuah alamat dianggap bergantung pada sebuah nama.
(CATATAN: Kesalahpahaman yang umum adalah bahwa model relasional disebut demikian karena menyatakan hubungan antara elemen data di dalamnya. Ini tidak benar. Model relasional dinamakan demikian karena didasarkan pada struktur matematika yang dikenal sebagai hubungan.)
Menyusun data secara logis
Setelah hubungan dan ketergantungan di antara berbagai bagian informasi telah ditentukan, dimungkinkan untuk mengatur data ke dalam struktur logis yang kemudian dapat dipetakan ke dalam objek penyimpanan yang didukung oleh sistem manajemen basis data. Dalam kasus database relasional, objek penyimpanan adalah tabel yang menyimpan data dalam baris dan kolom. Dalam database Object, objek penyimpanan berhubungan langsung dengan objek yang digunakan oleh bahasa pemrograman berorientasi objek yang digunakan untuk menulis aplikasi yang akan mengelola dan mengakses data. Hubungan dapat didefinisikan sebagai atribut dari kelas objek yang terlibat atau sebagai metode yang beroperasi pada kelas objek.
Cara pemetaan ini umumnya dilakukan sedemikian rupa sehingga setiap kumpulan data terkait yang bergantung pada satu objek, apakah nyata atau abstrak, ditempatkan dalam sebuah tabel. Hubungan antara objek-objek dependen ini kemudian disimpan sebagai link antara berbagai objek.
Setiap tabel dapat mewakili implementasi dari objek logis atau hubungan yang menggabungkan satu atau lebih instance dari satu atau lebih objek logis. Hubungan antar tabel kemudian dapat disimpan sebagai tautan yang menghubungkan tabel anak dengan orang tua. Karena hubungan logis yang kompleks itu sendiri adalah tabel, mereka mungkin akan memiliki tautan ke lebih dari satu induk.
Diagram ER (model hubungan entitas)
Contoh diagram Entity-relationship
Desain database juga menyertakan diagram ER (entity-relationship model). Diagram ER adalah diagram yang membantu merancang database dengan cara yang efisien.
Atribut dalam diagram ER biasanya dimodelkan sebagai oval dengan nama atribut, dihubungkan dengan entitas atau relasi yang memuat atribut tersebut.
Model ER umumnya digunakan dalam desain sistem informasi; misalnya, mereka digunakan untuk menggambarkan kebutuhan informasi dan/atau jenis informasi yang akan disimpan dalam database selama fase desain struktur konseptual.[3]
Saran proses desain untuk Microsoft Access
Tentukan tujuan database - Ini membantu mempersiapkan langkah-langkah selanjutnya.
Temukan dan atur informasi yang diperlukan - Kumpulkan semua jenis informasi untuk dicatat dalam database, seperti nama produk dan nomor pesanan.
Bagi informasi ke dalam tabel - Bagi item informasi menjadi entitas atau subjek utama, seperti Produk atau Pesanan. setiap mata pelajaran kemudian menjadi sebuah tabel.
Ubah item informasi menjadi kolom - Putuskan informasi apa yang perlu disimpan di setiap tabel. Setiap item menjadi bidang, dan ditampilkan sebagai kolom dalam tabel. Misalnya, tabel Karyawan mungkin menyertakan bidang seperti Nama Belakang dan Tanggal Sewa.
Tentukan kunci utama - Pilih kunci utama setiap tabel. Kunci utama adalah kolom, atau kumpulan kolom, yang digunakan untuk mengidentifikasi setiap baris secara unik. Contohnya mungkin ID Produk atau ID Pesanan.
Mengatur hubungan tabel - Lihat setiap tabel dan putuskan bagaimana data dalam satu tabel terkait dengan data di tabel lain. Tambahkan bidang ke tabel atau buat tabel baru untuk memperjelas hubungan, jika perlu.
Perbaiki desain - Analisis desain untuk kesalahan. Buat tabel dan tambahkan beberapa catatan data sampel. Periksa apakah hasil datang dari tabel seperti yang diharapkan. Lakukan penyesuaian pada desain, sesuai kebutuhan.
Terapkan aturan normalisasi - Terapkan aturan normalisasi data untuk melihat apakah tabel terstruktur dengan benar. Buat penyesuaian pada tabel, sesuai kebutuhan.
Normalisasi
Di bidang desain basis data relasional, normalisasi adalah cara sistematis untuk memastikan bahwa struktur basis data cocok untuk kueri tujuan umum dan bebas dari karakteristik tertentu yang tidak diinginkan—anomali penyisipan, pembaruan, dan penghapusan yang dapat menyebabkan hilangnya integritas data.
Bagian standar dari panduan desain database adalah bahwa desainer harus membuat desain yang sepenuhnya dinormalisasi; denormalisasi selektif selanjutnya dapat dilakukan, tetapi hanya untuk alasan kinerja. Trade-off adalah ruang penyimpanan vs kinerja. Semakin dinormalisasi desainnya, semakin sedikit redundansi data yang ada (dan oleh karena itu, dibutuhkan lebih sedikit ruang untuk disimpan), namun, pola pengambilan data umum sekarang mungkin memerlukan penggabungan, penggabungan, dan pengurutan yang kompleks untuk terjadi - yang memakan lebih banyak data membaca, dan menghitung siklus. Beberapa disiplin pemodelan, seperti pendekatan pemodelan dimensi untuk desain gudang data, secara eksplisit merekomendasikan desain yang tidak dinormalisasi, yaitu desain yang sebagian besar tidak mematuhi 3NF. Normalisasi terdiri dari bentuk normal yaitu 1NF,2NF,3NF,BOYCE-CODD NF (3.5NF),4NF dan 5NF
Database dokumen mengambil pendekatan yang berbeda. Sebuah dokumen yang disimpan dalam database seperti itu, biasanya akan berisi lebih dari satu unit data yang dinormalisasi dan seringkali juga hubungan antar unit. Jika semua unit data dan hubungan yang bersangkutan sering diambil bersama-sama, maka pendekatan ini mengoptimalkan jumlah pengambilan. Ini juga menyederhanakan bagaimana data direplikasi, karena sekarang ada unit data yang dapat diidentifikasi dengan jelas yang konsistensinya mandiri. Pertimbangan lain adalah bahwa membaca dan menulis satu dokumen dalam database tersebut akan memerlukan satu transaksi - yang dapat menjadi pertimbangan penting dalam arsitektur Microservices. Dalam situasi seperti itu, seringkali, sebagian dokumen diambil dari layanan lain melalui API dan disimpan secara lokal untuk alasan efisiensi. Jika unit data akan dibagi di seluruh layanan, maka membaca (atau menulis) untuk mendukung konsumen layanan mungkin memerlukan lebih dari satu panggilan layanan, dan ini dapat mengakibatkan pengelolaan beberapa transaksi, yang mungkin tidak disukai.
Skema konseptual
Desain fisik
Desain fisik database menentukan konfigurasi fisik database pada media penyimpanan. Ini termasuk spesifikasi rinci elemen data, tipe data, opsi pengindeksan dan parameter lain yang berada dalam kamus data DBMS. Ini adalah desain rinci dari sebuah sistem yang mencakup modul & spesifikasi hardware & software database dari sistem. Beberapa aspek yang dibahas pada lapisan fisik:
- Keamanan - pengguna akhir, serta keamanan administratif.
- Replikasi - bagian data apa yang disalin ke database lain, dan seberapa sering. Apakah ada banyak master, atau satu?
- Ketersediaan tinggi - apakah konfigurasi aktif-pasif, atau aktif-aktif, topologi, skema koordinasi, target keandalan, dll semua harus ditentukan.
- Partisi - jika database didistribusikan, maka untuk satu entitas, bagaimana data didistribusikan di antara semua partisi database, dan bagaimana kegagalan partisi diperhitungkan.
- Skema pencadangan dan pemulihan.
Pada tingkat aplikasi, aspek lain dari desain fisik dapat mencakup kebutuhan untuk mendefinisikan prosedur tersimpan, atau tampilan kueri yang terwujud, kubus OLAP, dll.
Sumber Artikel: en.wikipedia.org