1.1 Pendahuluan
Merancang database agak mirip dengan merancang arsitektur proyek Java. Anda dapat meletakkan semua data dalam beberapa tabel, atau Anda dapat membuat struktur data yang indah dari skema dan lusinan tabel.
Berikut adalah tugas-tugas yang biasanya dihadapi pengembang saat mendesain database:
- Memastikan bahwa semua informasi yang diperlukan disimpan dalam database.
- Memastikan kemungkinan memperoleh data pada semua permintaan yang diperlukan.
- Mengurangi redundansi dan duplikasi data.
- Memastikan Integritas Database
- Optimasi kecepatan akses data
Hal utama yang harus diingat adalah Anda tidak dapat membuat struktur database yang ideal, karena. itu, seperti kode Anda, juga akan terus berubah. Ada tiga hal yang harus Anda ingat ketika merancang struktur database Anda:
- Strukturnya harus cukup baik.
- Harus ada logika dalam segala hal yang bisa dipahami orang lain.
- Optimalisasi prematur adalah akar dari semua kejahatan.
Anda tidak harus membuat struktur database terbaik di dunia. Dia masih akan berubah. Tugas Anda adalah memastikan bahwa setelah 20 perubahan pada struktur database Anda, cukup mudah untuk mengetahuinya.
Kemungkinan besar di tahun-tahun pertama pekerjaan Anda, tidak ada yang akan mempercayai Anda untuk mendesain basis dari awal. Anda akan membuat perubahan pada skema yang ada. Anda perlu mencoba memahami prinsip-prinsip apa yang diatur dan mematuhinya . Dengan piagam mereka, mereka tidak naik ke biara orang lain.
Jangan mengoptimalkan database sampai diperlukan. Jika tabel hanya memiliki beberapa ratus baris, kemungkinan besar DBMS akan menyimpannya di memori dan menyimpan kueri ke dalamnya.
Di sisi lain, Anda harus dapat mempercepat pekerjaan permintaan penting hingga puluhan atau bahkan ratusan kali lipat. Dan alangkah baiknya jika Anda tahu bagaimana melakukannya. Bagaimana mereka mengatakan di sekolah menengah di tahun pertama? "Lupakan semua yang diajarkan di sekolah..."
Jika Anda tahu apa itu normalisasi basis data, maka saya segera menyenangkan Anda, dalam pekerjaan Anda kemungkinan besar Anda akan berurusan dengan de-normalisasi . Tidak ada yang lebih penting untuk tempat perlindungan proyek selain kecepatan database. Dan jika, untuk mempercepat pemilihan data dari database, Anda perlu menggabungkan 200 (!) Tabel menjadi satu (dengan redundansi yang sangat besar), Anda harus melakukan ini.
1.2 Desain Perpustakaan
Mari selami sedikit area subjek dan pikirkan tentang desain database menggunakan sesuatu yang sederhana seperti perpustakaan buku pada umumnya.
Tugas utama perpustakaan mana pun adalah memproses dana buku. Sangat mudah untuk membedakan tiga kelompok utama pengguna sistem: pembaca, pustakawan, administrator . Aktivitas masing-masing ditampilkan dalam diagram use case.
Sudah sekarang, beberapa entitas dan hubungan database masa depan dapat dibedakan:
Dengan pendekatan ini, tidak jelas bagaimana menghubungkan pembaca dengan buku (pembaca tidak memiliki aritas dalam hubungan “penerbitan / penerimaan”. Jika buku memiliki beberapa eksemplar, maka dapat diterbitkan untuk beberapa pembaca. Bahkan jika sebuah buku dipahami sebagai satu salinan, maka ketika disimpan dalam tabel buku pembaca saat ini, tidak mungkin memperoleh informasi tentang siapa (dan berapa kali) yang mengambil buku ini sebelumnya.
Solusinya mungkin pengenalan entitas tambahan - kartu untuk menerbitkan buku. Saat buku diberikan kepada pembaca, sebuah kartu dibuat, dan saat buku diserahkan, tanda yang sesuai diletakkan di atasnya. Dengan bantuan kartu-kartu ini, hutang setiap pengguna ditentukan dan statistik penggunaan buku dihitung. Saat memesan literatur oleh pembaca, kartu juga dimulai, jika literatur yang dipesan tidak diambil oleh pembaca dalam jangka waktu tertentu, kartu tersebut dimusnahkan. Ada batasan jumlah buku yang dapat dipesan oleh pembaca.
Saat memilih literatur, pengguna melihat katalog literatur dengan kemampuan untuk memfilter hasil pencarian berdasarkan penulis, judul, tahun publikasi.
Dimungkinkan untuk menghitung statistik untuk semua buku di perpustakaan, sementara jumlah salinan buku yang diterbitkan untuk jangka waktu tertentu. Anda juga dapat mengatur jumlah minimum contoh buku yang perhitungannya dilakukan. Berdasarkan statistik ini, buku-buku yang tidak terpakai dihapuskan dari perpustakaan.
Entitas utama berikut dari area subjek dapat dibedakan:
- pengguna (pustakawan dan administrator);
- pembaca;
- ruang baca;
- buku;
- kartu penerbitan buku;
- kartu pemesanan buku.
Diagram ER yang dimodifikasi dari database ditunjukkan pada gambar.
Menurut kasus penggunaan yang ditunjukkan pada Gambar 1, database harus mengimplementasikan kueri berikut (bukan daftar lengkap):
- menampilkan buku-buku yang sesuai dengan kondisi yang ditentukan;
- tampilkan pengguna yang memiliki kartu untuk menerbitkan buku yang belum ditutup tepat waktu (pustakawan sedang mencari debitur);
- tampilkan semua buku yang sesuai dengan kartu peminjam buku pengguna tertentu yang tidak ditutup tepat waktu (pengguna datang ke perpustakaan untuk membeli buku baru - Anda perlu melihat apakah dia debitur dan memberi tahu dia tentang hal itu);
- hapus semua kartu pemesanan yang dibuat lebih dari N detik yang lalu;
- tampilkan semua buku yang sesuai dengan kartu reservasi buku yang tidak ditutup dari pengguna yang ditentukan (pembaca memesan buku dan datang ke perpustakaan untuk mengambilnya - pustakawan perlu mendapatkan daftar ini untuk memberikannya).
1.3 Pembentukan skema
Untuk membentuk skema data, Anda harus terlebih dahulu melengkapi diagram ER dengan detail entitas (menyempurnakannya). Kadang-kadang, pada saat yang sama, Anda dapat menemukan kesalahan dalam membuat diagram ER - dalam tugas ini, ditemukan bahwa buku tersebut perlu "entah bagaimana" terhubung dengan ruang perpustakaan.
Ini dapat dilakukan dengan menempatkan "nomor aula" yang diperlukan dalam buku, namun, dengan pendekatan ini, buku yang sama harus dijelaskan dalam database beberapa kali (jika terjadi di aula yang berbeda). Pendekatan yang lebih tepat adalah memperkenalkan entitas tambahan "penempatan buku". Angka tersebut menunjukkan diagram ER dengan entitas tambahan dan alat peraga.
Diagram ER di atas mencerminkan tabel utama, hubungan, dan atribut; atas dasar itu, Anda dapat membangun model basis data. Tidak ada standar untuk diagram ER, tetapi ada sejumlah notasi (Chen, IDEFIX, Martin, dll.), tetapi baik standar maupun notasi tidak dapat ditemukan untuk model domain. Namun, selama pembuatan diagram seperti itu, bidang kunci (eksternal dan internal) harus disorot, terkadang indeks dan tipe data.
Dalam hal ini, dalam diagram berikut:
- untuk tautan, notasi Martin ("kaki gagak" digunakan);
- tabel ditampilkan sebagai persegi panjang yang dibagi menjadi 3 bagian:
- nama tabel;
- kunci internal (ditandai dengan spidol);
- bidang yang tersisa, sedangkan yang wajib ditandai dengan spidol.
Saat mengembangkan model ini, ada keinginan untuk menggabungkan tabel administrator dengan tabel pustakawan - namun tambahkan tabel pengguna:
- administrator tidak terkait dengan ruangan tertentu (Anda harus mengisi bidang yang sesuai dengan nilai nol);
- ini mungkin akan mempersulit distribusi hak akses - sekarang hanya administrator basis data (yang bekerja melalui panel DBMS khusus dan tidak memiliki akun dalam sistem yang sedang dikembangkan) yang memiliki akses ke tabel administrator. Namun, saat menggabungkan tabel, kueri pengguna memerlukan akses ke tabel baru.
Saat membuat diagram ini, cacat pada diagram ER ditemukan dan diperbaiki - sebuah tabel ditambahkan librarians_roomsyang menyatukan pustakawan dan aula. Hal ini diperlukan karena satu pustakawan dapat bekerja di beberapa ruangan, namun beberapa pustakawan dapat bekerja di ruangan yang sama.
Saat mendesain database, Anda harus bisa bernalar setidaknya seperti contoh di atas. Jika Anda berpikir bahwa Anda berhasil, mari melangkah lebih jauh: bahkan lebih banyak teori.
GO TO FULL VERSION