pengantar
Seperti yang sering terjadi, arsitek database perlu mengembangkan database untuk solusi tertentu.
Suatu Jumat malam, dalam perjalanan pulang kerja, saya berpikir tentang bagaimana saya akan menciptakan layanan untuk mempekerjakan karyawan di berbagai perusahaan. Lagi pula, tidak ada layanan yang memungkinkan Anda untuk dengan cepat memahami seberapa cocok seorang kandidat untuk Anda. Tidak mungkin membuat filter kompleks yang menyertakan atau mengecualikan sekumpulan keterampilan, proyek, atau posisi tertentu. Layanan yang biasanya ditawarkan paling banyak adalah filter menurut perusahaan dan sebagian lagi berdasarkan keahlian.
Dalam artikel ini, saya akan membiarkan diri saya sedikit mengencerkan presentasi materi yang ketat dengan mencampurkan informasi teknis dengan contoh non-teknis dari kehidupan.
Untuk memulai, mari kita analisis pembuatan database di MS SQL Server untuk layanan pencarian kerja.
Materi ini dapat ditransfer ke DBMS lain seperti MySQL atau PostgreSQL.
Dasar-dasar aturan desain
Untuk mendesain skema database, Anda perlu mengingat 7 aturan formal dan konsep normalisasi dan denormalisasi. Mereka adalah dasar dari semua aturan desain.
Mari kita jelaskan lebih detail 7 aturan formal:
- hubungan satu-ke-satu:
1.1) dengan koneksi wajib:
contoh dapat menjadi warga negara dan paspornya: setiap warga negara harus memiliki paspor; satu paspor untuk setiap warga negara
Hubungan ini dapat diimplementasikan dalam dua cara:
1.1.1) dalam satu entitas (tabel): Gbr.1. Entitas warga Di sini, tabel Warga adalah entitas warga, dan atribut PassportData (bidang) berisi semua data paspor warga negara dan tidak boleh kosong (BUKAN NIHIL). 2) dalam dua entitas (tabel) yang berbeda: Gbr. 2. Hubungan antara Warga Negara dan Entitas Data Paspor
Di sini, tabel Citizen adalah entitas warga, dan tabel PassportData adalah entitas data paspor warga (paspor itu sendiri). Entitas warga berisi atribut PassportID (bidang) yang merujuk ke kunci utama dari tabel PassportData. Pada gilirannya, entitas data paspor berisi atribut (bidang) CitizenID, yang mengacu pada kunci utama CitizenID dari tabel Citizen. Kolom Citizen table PassportID tidak boleh kosong (NOT NULL). Penting juga untuk menjaga integritas bidang CitizenID pada tabel PassportData untuk memastikan hubungan satu-ke-satu. Dengan kata lain, bidang PassportID dari tabel Citizen dan bidang CitizenID dari tabel PassportData harus mengacu pada catatan yang sama seolah-olah itu adalah entitas yang sama (tabel) yang disajikan dalam klausul 1.1.1.
1.2) dengan tautan opsional:
contohnya adalah seseorang dengan atau tanpa paspor untuk negara tertentu. Dalam kasus pertama, dia akan menjadi warga negara yang bersangkutan, dan dalam kasus kedua, dia tidak akan.
Hubungan ini dapat diimplementasikan dengan dua cara:
1.2.1) dalam satu entitas (tabel): Gbr.3. Entitas Orang Tabel Person adalah entitas seseorang, dan atribut PassportData (bidang) berisi semua data paspornya dan boleh kosong (NULL). 2) dalam dua entitas (tabel): Gbr. 4. Hubungan antara entitas Person dan PassportData
Tabel Person adalah entitas orang tersebut, dan tabel PassportData adalah entitas data paspor orang tersebut (paspor itu sendiri). Entitas manusia berisi atribut PassportID (bidang) yang merujuk ke kunci utama dari tabel PassportData. Pada gilirannya, identitas data paspor berisi atribut (bidang) PersonID, yang mengacu pada kunci utama PersonID dari tabel Person. Bidang PassportID dari tabel Person dapat berupa NULL. Penting juga untuk menjaga integritas bidang PersonID dari tabel PassportData. Ini diperlukan untuk memastikan komunikasi satu-ke-satu. Bidang PassportID dari tabel Person dan bidang PersonID dari tabel PassportData harus mengacu pada catatan yang sama seolah-olah itu adalah entitas yang sama (tabel) yang ditunjukkan dalam klausul 1.2.1. Atau, bidang ini harus nol, yaitu berisi NULL.
- :
2.1) :
. .
:
2.1.1) ():
.5. Parent
Parent , () ChildList . (NOT NULL). ChildList (NoSQL) XML, JSON .
2.1.2) ():
.6. Parent Child
Parent , Child — . Child ParentID, ParentID Parent. ParentID Child (NOT NULL).
2.2) :
, .
:
2.2.1) ():
.7. Person
Parent , () ChildList . (NULL). ChildList (NoSQL) XML, JSON .
2.2.2) ():
.8. Person Child
Parent , Child — . Child ParentID, ParentID Parent. ParentID Child (NULL).
2.2.3) , () () :
.9. Person
() Person () ParentID, PersonID Person (NULL).
« » .
- :
. , «» «», , . , , .
- :
: , . , .
, NoSQL, , . , 3 ():
.10. Person RealEstate
Person RealEstate . () () PersonRealEstate. () PersonID RealEstateID PersonID Person RealEstateID RealEstate . , PersonRealEstate (PersonID; RealEstateID) PersonRealEstate.
. , . , 1.1.2 1.2.2.
Hubungan satu-ke-banyak dan banyak-ke-satu dapat diimplementasikan melalui lebih dari dua entitas. Untuk ini, atribut yang diperlukan ditambahkan yang mengacu pada kunci utama dari entitas terkait yang diperlukan. Implementasi ini serupa dengan contoh yang dijelaskan di atas pada paragraf 1.1.2 dan 1.2.2.
Di manakah tujuh aturan formal itu?
Di sini mereka:
- Klausul 1 (Klausul 1.1 dan Klausul 1.2) - aturan formal pertama dan kedua
- Klausul 2 (Klausul 2.1 dan Klausul 2.2) - aturan formal ketiga dan keempat
- klausul 3 (mirip dengan klausul 2) - aturan formal kelima dan keenam
- butir 4 - aturan formal ketujuh
Dalam teks di atas, ketujuh aturan formal ini dikelompokkan menjadi empat blok fungsional.
Saat berbicara tentang normalisasi , Anda perlu memahami esensinya. Normalisasi menyebabkan penurunan pengulangan penyimpanan informasi, dan oleh karena itu menurunkan kemungkinan anomali dalam data. Namun, normalisasi saat memisahkan entitas mengarah ke konstruksi kueri yang lebih kompleks untuk manipulasi data (penyisipan, modifikasi, pemilihan, dan penghapusan).
Proses normalisasi terbalik disebut denormalisasi . Ini adalah penyederhanaan pembuatan kueri akses data karena agregasi dan penumpukan entitas (misalnya, seperti yang ditunjukkan di atas dalam klausul 2.1.1 dan 2.2.1 menggunakan data yang tidak terstruktur secara lengkap (NoSQL)).
Itulah inti dari aturan desain database.
Apakah Anda yakin Anda memahami hubungan dalam tujuh aturan formal? Apakah Anda mengerti, dan tidak mengenali? Bagaimanapun, mengetahui dan memahami adalah dua konsep yang sangat berbeda.
Saya akan menjelaskan lebih detail. Tanyakan pada diri Anda, dapatkah Anda membuat sketsa model database, meskipun diperbesar berdasarkan entitas, untuk bidang subjek apa pun dan untuk sistem informasi apa pun dalam beberapa jam? (kehalusan dan detail dapat diselesaikan dengan bertanya kepada analis dan perwakilan pelanggan). Jika pertanyaan itu mengejutkan Anda, dan Anda berpikir bahwa ini tidak mungkin, maka Anda mengetahui tujuh aturan formal, tetapi tidak memahaminya.
Untuk beberapa alasan, banyak sumber mengabaikan fakta bahwa hubungan ini tidak ditemukan, tetapi diungkapkan. Mereka awalnya ada di dunia nyata baik di antara subjek dan di antara subjek dan objek.
Juga, hubungan ini bisa berubah, berpindah darisatu ke satu ke satu ke banyak , banyak ke satu atau banyak ke banyak . Kewajiban komunikasi bisa berubah atau tetap tidak berubah.
Izinkan saya memberi tahu Anda tentang satu kasus ketika, dari pengetahuan tentang tujuh aturan formal, saya sampai pada pemahaman tentang hubungan ini.
Pada suatu waktu, saya merasa malu dengan fakta bahwa di universitas saya mengetahui tujuh aturan formal ini, tetapi dalam praktik industri (universitas mengirim mahasiswa ke berbagai perusahaan untuk mendapatkan pengalaman profesional) untuk waktu yang sangat lama saya membangun model basis untuk bidang studi yang berbeda. Saya memikirkannya dan menyadari bahwa saya tidak memahami hubungan ini.
Mengamati orang membantu saya, dan inti dari hubungan itu terungkap dalam mimpi. Saya akan menceritakan kembali mimpi ini dalam bentuk yang disederhanakan: hanya yang memungkinkan Anda untuk lebih memahami tujuh aturan formal ini - tanpa merinci yang lainnya.
Mimpi itu tentang sebuah keluarga dengan ayah, ibu dan anak. Sang ayah meninggal dalam kecelakaan mobil, dan ibunya mulai minum, dan anak-anak akhirnya dibawa ke panti asuhan. Anak-anak ini dibiarkan tanpa orang tua untuk waktu yang lama. Kemudian beberapa anak memiliki wali, ada beberapa dari mereka juga.
Apakah Anda melacak jenis hubungan yang ada di antara subjek, dan bagaimana hubungan ini berubah?
Mari kita lihat lebih dekat.
- Ketika keluarga itu lengkap, dengan beberapa anak, hubungan antara orang tua dan anak menjadi banyak ke banyak .
- , . , , , , .
- .
- — .
- , : , ().
Hubungan antara suami dan istri adalah satu-ke-satu dengan ikatan wajib dalam pernikahan formal, atau satu-ke-satu dengan ikatan opsional sebelum pendaftaran. Hanya boleh ada satu istri, sama seperti hanya ada satu suami. Setidaknya di Rusia. Tetapi di negara lain, poligami dimungkinkan, dan kemudian hubungan antara suami dan istri akan menjadi satu dengan banyak , dan antara istri dan suami - banyak dengan satu .
Semoga Anda sekarang lebih dekat untuk memahami tujuh aturan formal ini.
Layak untuk terus-menerus berlatih: mengamati orang dan mengidentifikasi hubungan yang ada baik antara subjek maupun antara subjek dan objek. Di atas menggambarkan warga negara dan paspornya sebagai hubungan satu-ke-satu dengan tautan wajib... Pada saat yang sama, contoh seseorang dan paspornya adalah hubungan satu-ke-satu dengan tautan opsional .
Setelah memahami tujuh aturan formal, Anda dapat dengan mudah merancang model database dengan kerumitan apa pun untuk sistem informasi apa pun.
Anda juga akan melihat bahwa ada banyak cara untuk mengimplementasikan suatu hubungan, dan hubungan itu sendiri dapat berubah. Model database (skema) adalah snapshot dari hubungan antar entitas pada titik waktu tertentu. Itulah mengapa penting untuk menentukan entitas itu sendiri - gambar objek dari dunia nyata atau area subjek, dan hubungannya satu sama lain, dengan mempertimbangkan perubahan di masa depan.
Model database yang dirancang dengan baik, dengan mempertimbangkan hubungan yang berubah dalam kenyataan atau dalam domain, tidak perlu diubah selama bertahun-tahun atau bahkan beberapa dekade. Hal ini sangat penting untuk gudang data, di mana perubahan memerlukan penghematan ulang data dalam jumlah besar (dari beberapa gigabyte hingga banyak terabyte).
Penting untuk diingat bahwa tabel dalam model relasional adalah hubungan entitas, dan baris (tupel) adalah contoh dari hubungan ini. Namun untuk mempermudah, tabel sering kali dipahami sebagai entitas, dan baris tabel adalah contoh entitas. Hubungan mereka diekspresikan melalui hubungan dalam bentuk kunci asing.
Merancang Skema Database untuk Menemukan Pelamar Kerja
Setelah kita membahas dasar-dasar aturan desain database di bagian satu, mari buat skema database untuk mencari pencari kerja.
Untuk memulainya, mari kita tentukan apa yang penting bagi karyawan dari perusahaan yang mencari kandidat:
- untuk SDM:
1.1) perusahaan tempat pelamar bekerja
1.2) posisi yang sebelumnya dipegang oleh pelamar di perusahaan tersebut
1.3) keterampilan dan kemampuan yang digunakan pelamar dalam pekerjaannya;
serta durasi pekerjaan pelamar di masing-masing perusahaan di setiap posisi dan durasi penggunaan keterampilan dan kemampuan masing-masing.
- untuk spesialis teknis:
2.1) posisi yang dipegang oleh pelamar di perusahaan-perusahaan ini;
2.2) keterampilan dan kemampuan yang digunakan pelamar dalam pekerjaannya;
2.3) proyek yang diikuti oleh pelamar;
serta durasi kerja pelamar di setiap posisi dan di setiap proyek, durasi penggunaan setiap keterampilan dan kemampuan
Pertama, mari kita identifikasi entitas yang diperlukan:
- Karyawan
- Perusahaan
- Position (posisi)
- Proyek
- Ketrampilan
- Perusahaan dan karyawan itu seperti banyak ke banyak , karena seorang karyawan dapat bekerja di beberapa perusahaan, dan banyak orang bekerja untuk perusahaan.
- Posisi dan karyawan terkait dengan cara yang serupa: beberapa karyawan dapat menempati satu posisi baik dalam satu atau beberapa perusahaan.
- , , . , — .
- : .
- , .
- .
Karena sangat penting untuk mencatat berapa lama seorang karyawan telah bekerja di posisi tertentu di perusahaan tertentu, serta di setiap proyek, diagram database kami adalah sebagai berikut: Gbr. 11. Skema Database untuk Menemukan Pelamar Kerja Di sini, tabel JobHistory bertindak sebagai entitas dari riwayat pekerjaan setiap pencari kerja. Artinya, ini adalah resume yang memperkenalkan hubungan banyak-ke-banyak antara karyawan entitas, perusahaan, posisi, dan proyek. Proyek dan keterampilan berhubungan satu sama lain sebanyak banyak dan oleh karena itu berkomunikasi satu sama lain melalui entitas ProjectSkill (tabel).
Ketika Anda memahami hubungan antara subjek dan antara subjek dan objek - tujuh aturan formal yang telah disebutkan - skema ini atau yang serupa dapat diterapkan "di lutut": di selembar kertas, dalam waktu kurang dari satu jam. Dan ini juga memperhitungkan kelelahan setelah hari kerja yang bermanfaat.
Di sini dimungkinkan untuk menyederhanakan skema penambahan data jika "keterampilan" tertanam dalam entitas "proyek" melalui data terstruktur tidak lengkap (NoSQL) dalam bentuk XML, JSON, atau cukup daftar nama keterampilan yang dipisahkan dengan titik koma. Tapi itu akan membuat lebih sulit untuk mengambil sampel berdasarkan keterampilan dan memfilter berdasarkan keterampilan.
Model serupa ada di jantung database proyek Geecko .
Seperti yang Anda lihat, tidak ada yang rumit dalam desain sistem informasi dalam hal desain basis data. Ini hanyalah cerminan objek dan subjek dari kenyataan, ditransfer ke "entitas" skema database. Hubungan antara entitas ini ditetapkan pada titik waktu tertentu, dengan mempertimbangkan perubahan masa depan.
Apa sebenarnya yang kita ambil dari kenyataan dan dimasukkan ke dalam esensi skema, dan hubungan apa yang kita bangun dalam model, akan bergantung pada apa yang kita inginkan dari sistem informasi secara umum, di sini dan di masa depan. Dengan kata lain, data apa yang ingin kita terima pada saat ini dan setelah waktu tertentu di kemudian hari.
Sedikit lirik
Setelah Anda menjalankan model tersebut, berhentilah sejenak dan pikirkan: dunia kecil baru baru saja dibuat. Ia memiliki entitasnya sendiri dari dunia nyata dan hubungannya sendiri. Ya, ini adalah dunia digital, tapi sekarang akan berkembang dengan caranya sendiri. Itu akan berkomunikasi (berintegrasi) dengan sistem lain (dunia), juga dibuat sesuai dengan aturan mereka sendiri. Data akan mengalir dalam sistem ini seperti darah dalam organisme hidup.
Dan sebelum tidur, pikirkan tentang fakta bahwa tujuh aturan formal selalu ada, dan aturan itu mengelilingi kita di mana-mana. Tidak lebih dan tidak kurang, selalu tujuh. Semua hubungan dalam kehidupan nyata dapat diuraikan menjadi tujuh aturan formal ini. Dan ketika Anda berpikir atau bermimpi, bagaimana entitas berhubungan satu sama lain - tidak sesuai dengan tujuh aturan formal yang sama?
Secara umum, saya yakin bahwa hubungan ini (tujuh aturan formal) diungkapkan oleh psikoterapis yang sangat baik, mungkin seorang wanita. Itu sudah sangat lama, jauh sebelum konsep teknologi informasi muncul. Dan yang paling menarik adalah bahwa hubungan ini hidup di luar database dan TI - yang terakhir hanya menggunakannya untuk memodelkan sistem informasi.
Tapi kami sedikit menyimpang dari topik. Saya hanya mendorong Anda untuk mendekati proses ini dengan jiwa Anda pada saat membuat sistem baru. Dan percayalah, momen penciptaan akan terjadi. Sistem yang dirancang dengan cara ini akan menjadi yang paling hidup dari semua makhluk hidup di dunia digital.
Kata Penutup
Diagram untuk contoh diimplementasikan menggunakan Alat Diagram Database untuk SQL Server . Namun, DBeaver memiliki fungsi serupa .