Pertanyaan ini menunjukkan bahwa Anda tidak sepenuhnya memahami hubungan entitas (tidak bermaksud kasar). Di antaranya ada empat (secara teknis hanya 3) jenis di bawah ini:
One to One One to Many Many to One Many to Many
Satu lawan Satu (1:1): Dalam hal ini sebuah tabel telah dipecah menjadi dua bagian untuk tujuan memenuhi normalisasi, atau lebih biasanya prinsip terbuka tertutup.
Normalisasi kepatuhan:Anda mungkin memiliki aturan bisnis bahwa setiap pelanggan hanya memiliki satu akun. Secara teknis, dalam hal ini Anda bisa mengatakan pelanggan dan akun semua bisa berada di tabel yang sama, tetapi ini melanggar aturan normalisasi, jadi Anda membaginya dan membuat 1:1.
Prinsip Buka-Tutup kepatuhan:Tabel pelanggan, mungkin memiliki id, nama depan &belakang, dan alamat. Kemudian seseorang memutuskan untuk menambahkan tanggal lahir dan dengan itu kemampuan untuk menghitung usia bersama dengan banyak bidang lain yang sangat dibutuhkan. Ini adalah contoh satu lawan satu yang terlalu disederhanakan, tetapi Anda mendapatkan kegunaan utamanya adalah untuk memperluas basis data Anda tanpa merusak kode yang ada. Banyak kode yang ditulis (sayangnya) digabungkan dengan database sehingga perubahan dalam struktur tabel akan merusak kode. Menambahkan 1:1 seperti ini akan memperluas tabel untuk memenuhi persyaratan baru tanpa mengubah aslinya, sehingga memungkinkan kode lama untuk terus berfungsi secara normal dan kode baru menggunakan fitur db baru.
Kelemahan dari normalisasi dan perluasan tabel menggunakan hubungan 1:1 dengan cara ini adalah kinerja. Sering kali pada sistem yang sering digunakan, target pertama untuk meningkatkan kinerja database adalah de-normalisasi dan menggabungkan tabel tersebut ke dalam satu tabel, dan mengoptimalkan indeks sehingga menghilangkan kebutuhan untuk menggunakan gabungan dan membaca dari beberapa tabel. Normalisasi / De-Normalisasi bukanlah hal yang baik atau buruk, karena tergantung pada kebutuhan sistem. Sebagian besar sistem biasanya memulai perubahan kembali yang dinormalisasi saat diperlukan, tetapi perubahan ini perlu dilakukan dengan sangat hati-hati seperti yang disebutkan, jika kode digabungkan dengan erat ke struktur DB, hampir pasti akan menyebabkan sistem gagal. yaitu Ketika Anda menggabungkan 2 tabel, satu tidak ada lagi, semua kode yang menyertakan tabel yang sekarang tidak ada gagal hingga diubah (dalam istilah db, bayangkan menghubungkan hubungan ke salah satu tabel dalam 1:1, ketika Anda menghapus tabel tersebut , ini merusak hubungan, dan karenanya strukturnya harus sangat dimodifikasi untuk mengimbanginya. Sayangnya, desain buruk seperti itu jauh lebih mudah dikenali di dunia DB daripada di dunia perangkat lunak dalam banyak kasus dan Anda biasanya tidak menyadari ada yang salah dalam kode sampai semuanya berantakan) kecuali sistem dirancang dengan benar dengan pemisahan masalah dalam pikiran.
Ini adalah hal terdekat yang bisa Anda dapatkan dari pewarisan dalam pemrograman berorientasi objek. Tapi tidak persis sama.
Satu ke Banyak (1:M) / Banyak ke Satu (M:1): Kedua hubungan ini (maka mengapa 4 menjadi 3), adalah jenis hubungan yang paling populer. Mereka berdua adalah jenis hubungan yang sama, satu-satunya hal yang berubah adalah sudut pandang Anda. Contoh Seorang pelanggan memiliki banyak nomor telepon, atau secara bergantian, banyak nomor telepon dapat menjadi milik seorang pelanggan.
Dalam pemrograman berorientasi objek ini akan dianggap komposisi. Ini bukan warisan, tetapi Anda mengatakan satu item terdiri dari banyak bagian. Ini biasanya direpresentasikan dengan array / daftar / koleksi dll. di dalam kelas yang bertentangan dengan struktur pewarisan.
Banyak ke Banyak (L:M): Jenis hubungan dengan teknologi saat ini tidak mungkin. Untuk alasan ini kita perlu memecahnya menjadi dua hubungan satu ke banyak dengan tabel "asosiasi" yang bergabung dengan mereka. Sisi banyak dari dua hubungan satu ke banyak selalu pada tabel asosiasi / tautan.
Sebagai contoh Anda, orang yang mengatakan Anda membutuhkan banyak ke banyak benar. Karena dua ke banyak secara efektif merupakan hubungan banyak (artinya lebih dari satu) ke banyak. Ini adalah satu-satunya cara agar sistem Anda berfungsi. Kecuali jika Anda berniat untuk meneliti bidang kalkulus relasional untuk menemukan beberapa jenis hubungan baru yang memungkinkan hal ini.
Juga untuk hubungan seperti itu (m2m), Anda memiliki dua pilihan, buat kunci majemuk di tabel tautan sehingga kombinasi bidang menjadi entri unik (jika Anda tertarik dengan pengoptimalan db, ini adalah pilihan yang lebih lambat, tetapi membutuhkan lebih sedikit ruang). Sebagai alternatif, Anda membuat bidang ketiga dengan kolom id yang dibuat secara otomatis dan menjadikannya sebagai kunci utama (untuk pengoptimalan db, ini adalah pilihan yang lebih cepat, tetapi membutuhkan lebih banyak ruang).
Dalam contoh Anda khususnya di atas...
Ini akan menjadi hubungan banyak ke banyak dengan tabel nomor telepon sebagai tabel penghubung antara perusahaan dan pengguna. Seperti yang dijelaskan, untuk memastikan tidak ada nomor telepon yang berulang, Anda cukup menyetelnya sebagai kunci utama atau menggunakan kunci utama lain dan menyetel bidang nomor telepon menjadi unik.
Untuk pertanyaan semacam itu, itu benar-benar tergantung pada bagaimana Anda mengungkapkannya. Apa yang menyebabkan Anda bingung tentang hal ini, dan bagaimana Anda mengatasi kebingungan ini untuk melihat solusinya sederhana. Ulangi masalah sebagai berikut. Mulailah dengan bertanya apakah itu satu lawan satu, jika jawabannya tidak, lanjutkan. Selanjutnya tanyakan apakah one to many, jika jawabannya tidak move on. Satu-satunya pilihan lain yang tersisa adalah banyak ke banyak. Namun berhati-hatilah, pastikan Anda telah mempertimbangkan 2 pertanyaan pertama dengan cermat sebelum melanjutkan. Banyak orang database yang tidak berpengalaman sering kali memperumit masalah dengan mendefinisikan satu ke banyak sebanyak banyak ke banyak. Sekali lagi, jenis hubungan yang paling populer sejauh ini adalah satu ke banyak (saya akan mengatakan 90%) dengan banyak ke banyak dan satu ke satu membagi 10% sisanya 7/3 masing-masing. Tetapi angka-angka itu hanya perspektif pribadi saya, jadi jangan mengutipnya sebagai statistik standar industri. Maksud saya adalah membuat ekstra ekstra yakin itu pasti bukan satu ke banyak sebelum memilih banyak ke banyak. Ini sepadan dengan usaha ekstra.
Jadi sekarang untuk menemukan tabel penghubung di antara keduanya, putuskan mana yang merupakan tabel utama Anda, dan bidang apa yang perlu dibagikan di antara keduanya. Dalam hal ini, tabel perusahaan dan pengguna harus berbagi telepon. Oleh karena itu, Anda perlu membuat tabel telepon baru sebagai penghubung.
Alarm peringatan kesalahpahaman akan muncul segera setelah Anda memutuskan tidak ada dari 3 yang bekerja untuk Anda. Ini seharusnya cukup untuk memberi tahu Anda bahwa Anda tidak mengucapkan pertanyaan hubungan dengan benar. Anda akan menjadi lebih baik seiring berjalannya waktu, tetapi ini adalah keterampilan penting dan benar-benar harus dikuasai sesegera mungkin untuk kesehatan Anda sendiri.
Tentu saja Anda juga bisa pergi ke database berorientasi objek yang akan memungkinkan berbagai hubungan lain yang disebut hubungan "Hierarchacal". Itu bagus jika Anda berpikir untuk menjadi seorang programmer juga. Tapi saya tidak akan merekomendasikan ini karena akan membuat kepala Anda sakit ketika Anda mulai menemukan cara untuk menggabungkan berbagai jenis hubungan. Terutama mengingat tidak banyak kebutuhan karena hampir semua database di dunia hanya terdiri dari 3 jenis hubungan itu kecuali jika itu adalah sesuatu yang super duper spesial.
Semoga ini adalah jawaban yang masuk akal. Terima kasih telah meluangkan waktu untuk membacanya.
