Apa itu Hubungan Satu-ke-Banyak dalam Basis Data? Penjelasan dengan Contoh

Hubungan satu-ke-banyak adalah salah satu hubungan database yang paling umum. Jika Anda ingin mempelajari kapan dan bagaimana menggunakan hubungan satu-ke-banyak, maka artikel ini adalah titik awal yang bagus.

Anda pasti akan menggunakan hubungan satu-ke-banyak untuk menyimpan informasi dalam basis data relasional apa pun, baik Anda merancang perangkat lunak tingkat perusahaan atau hanya membuat basis data sederhana untuk melacak koleksi perangko paman Anda.

Pengantar Singkat Model Relasional

Database relasional adalah komponen inti dari setiap aplikasi transaksional modern. Model relasional terdiri dari tabel (data yang diatur dalam baris dan kolom) yang memiliki setidaknya satu kunci unik yang mengidentifikasi setiap baris. Setiap tabel mewakili entitas. Ini ditunjukkan dalam contoh berikut, versi tabel yang sangat sederhana yang mewakili pesanan pelanggan:

Diagram di atas, yang saya buat secara online menggunakan Vertabelo, memiliki satu tabel. Setiap baris dalam tabel mewakili satu urutan, dan setiap kolom (juga dikenal sebagai atribut ) mewakili setiap informasi yang terkandung dalam pesanan.

Bagi yang belum mengenal alat desain Vertabelo, artikel Apa Simbol yang Digunakan dalam Diagram ER? menjelaskan simbol dan konvensi yang digunakan. Anda mungkin juga ingin mempelajari lebih lanjut tentang model relasional dan database menggunakan kursus pemodelan database kami.

Apa Itu Hubungan dan Mengapa Kita Membutuhkannya?

Jika kita melihat lebih dalam pada tabel yang digunakan pada contoh sebelumnya, kita akan melihat bahwa tabel tersebut tidak benar-benar mewakili urutan yang lengkap. Itu tidak memiliki semua informasi yang Anda harapkan. Anda akan melihat bahwa itu tidak termasuk data apa pun yang terkait dengan pelanggan yang membuat pesanan, juga tidak ada informasi tentang produk atau layanan yang dipesan.

Apa yang harus kita lakukan untuk menyelesaikan desain ini untuk menyimpan data pesanan? Haruskah kami menambahkan informasi pelanggan dan produk ke Pesanan meja? Itu akan membutuhkan penambahan kolom (atribut) baru untuk nama pelanggan, pengenal pajak, alamat, dll. seperti yang ditunjukkan di bawah ini:

Jika kita melakukan itu, kita akan segera mengalami masalah. Kebanyakan pelanggan memesan lebih dari satu, sehingga sistem ini akan menyimpan informasi pelanggan berkali-kali, sekali untuk setiap pesanan setiap pelanggan. Sepertinya itu bukan langkah yang cerdas.

Selain itu, apa yang terjadi ketika pelanggan mengubah nomor telepon mereka? Jika seseorang perlu menelepon pelanggan, mereka mungkin menemukan nomor lama pada pesanan sebelumnya – kecuali jika seseorang memperbarui ratusan (atau bahkan ribuan) pesanan yang ada dengan informasi baru. Dan hal yang sama berlaku untuk perubahan lainnya.

Model relasional mengharuskan kita untuk mendefinisikan setiap entitas sebagai tabel terpisah dan membangun hubungan di antara mereka. Menyimpan semua informasi dalam satu tabel tidak akan berhasil.

Ada beberapa jenis hubungan antar tabel, tetapi mungkin yang paling umum adalah hubungan satu-ke-banyak, yang sering ditulis sebagai 1:N. Hubungan semacam ini berarti bahwa satu baris dalam suatu tabel (biasa disebut tabel induk) dapat memiliki hubungan dengan banyak baris dalam tabel lain (biasa disebut tabel anak). Beberapa contoh umum dari hubungan satu-ke-banyak adalah:

• Pembuat mobil membuat banyak model berbeda, tetapi model mobil tertentu hanya dibuat oleh satu pembuat mobil.
• Satu pelanggan dapat melakukan beberapa pembelian, tetapi setiap pembelian dilakukan oleh satu pelanggan.
• Satu perusahaan dapat memiliki banyak nomor telepon, tetapi satu nomor telepon dimiliki oleh satu perusahaan.

Ada juga jenis hubungan antar tabel lainnya; jika Anda ingin mempelajari lebih lanjut tentang mereka, lihat artikel ini tentang hubungan banyak-ke-banyak.

Kembali ke contoh pesanan awal kami, Customer tabel akan menjadi tabel induk dan Order meja anak; seorang pelanggan dapat memiliki banyak pesanan, sedangkan satu pesanan dapat dimiliki oleh satu pelanggan.

Harap dicatat bahwa definisi satu-ke-banyak memungkinkan baris dalam tabel induk untuk dikaitkan ke banyak baris pada setiap tabel anak, tetapi tidak memerlukannya. Sebenarnya, desain memungkinkan pelanggan untuk memiliki nol pesanan (yaitu pelanggan baru yang belum melakukan pembelian pertama), satu pesanan (pelanggan yang relatif baru yang telah melakukan satu pembelian) atau banyak pesanan (pelanggan tetap).

Menampilkan Hubungan Satu-ke-Banyak dalam Diagram ER

Mari kita lihat contoh yang lebih lengkap dari sistem pemesanan pelanggan sederhana menggunakan diagram ER (atau hubungan entitas). (Jika Anda ingin mempelajari lebih lanjut tentang diagram ini, Fitur Vertabelo:Diagram Logis adalah titik awal yang bagus.) Inilah modelnya:

Ini adalah desain yang lebih realistis. Anda akan melihat bahwa ada entitas baru (tabel) dalam diagram, yang sekarang berisi tabel Customer , Order , Order Detail , dan Product . Namun, hal terpenting yang Anda perhatikan adalah sekarang ada hubungan di antara tabel .

Dalam model database, hubungan diwakili oleh garis yang menghubungkan dua entitas. Karakteristik hubungan ini diwakili oleh konektor yang berbeda:

• Bila ada satu garis vertikal, entitas terdekat konektor tersebut hanya memiliki satu baris yang terpengaruh oleh hubungan tersebut. Ini adalah 'satu' dalam satu-ke-banyak.
• Bila ada konektor multi-baris yang terlihat seperti kaki gagak, entitas terdekat konektor tersebut memiliki beberapa baris yang terpengaruh oleh hubungan; itu 'banyak'.

Melihat gambar dan mengetahui notasi, mudah dipahami bahwa diagram mendefinisikan bahwa setiap Order dapat memiliki banyak Order Details dan bahwa setiap Order Details milik satu Order .

Mengimplementasikan Hubungan Satu-ke-Banyak Antar Tabel

Untuk mendefinisikan hubungan satu-ke-banyak antara dua tabel, tabel anak harus mereferensikan baris pada tabel induk. Langkah-langkah yang diperlukan untuk mendefinisikannya adalah:

1. Tambahkan kolom ke tabel anak yang akan menyimpan nilai pengenal utama. (Sebenarnya, sebagian besar mesin basis data mengizinkannya menjadi kunci unik apa pun dari tabel induk, bukan hanya kunci utama.) Kolom dapat didefinisikan sebagai wajib tergantung pada kebutuhan bisnis Anda; meski begitu, kolom kunci asing biasanya dibuat

Catatan: Ini adalah praktik yang baik untuk menjaga nama kolom referensi sama seperti di tabel referensi (induk). Ini membuatnya lebih mudah untuk memahami hubungannya.

2. Tambahkan kunci asing kendala di tabel anak. Hal ini menunjukkan bahwa setiap nilai yang disimpan di kolom baru ini merujuk ke satu baris pada tabel induk.

Batasan kunci asing adalah fitur yang tersedia pada basis data relasional yang memberlakukan bahwa:

1. Saat Anda menambahkan baris ke tabel anak, nilai kolom referensi harus cocok dengan satu (dan hanya satu) nilai di tabel induk. (Itulah sebabnya kolom atau kumpulan kolom yang membentuk kunci utama atau kunci unik harus dirujuk).
2. Jika seseorang mencoba menghapus baris dari tabel induk atau mencoba mengubah nilai kunci unik/utama yang digunakan sebagai referensi dan ada tabel anak yang mereferensikan baris itu, operasi akan gagal.

Kedua fitur ini memastikan bahwa database menjaga integritasnya. Tidak ada peluang untuk membuat pesanan yang merujuk ke pelanggan yang tidak ada, atau menghapus pelanggan yang sudah memiliki pesanan.

Membuat Kunci Asing

Sintaks kunci asing biasanya tergantung pada mesin basis data target. Setelah Anda menentukan model logis Anda, Anda dapat menggunakan fitur “Buat model fisik…” pada diagram logis Vertabelo untuk mengubah model (agnostik basis data) Anda menjadi model fisik yang cocok dengan penyedia basis data Anda. Vertabelo juga akan menghasilkan skrip SQL yang diperlukan yang memungkinkan Anda membuat tabel dan hubungan di database target Anda.

Beberapa Contoh Praktis Hubungan 1:N

Sekarang mari kita tinjau beberapa contoh hubungan satu-ke-banyak-dunia nyata.

Hubungan Satu-ke-Banyak Menggunakan Kunci Utama

Ini mungkin skenario yang paling umum ketika mendefinisikan hubungan satu-ke-banyak. Tabel anak menggunakan nilai kunci utama dari tabel induk untuk membangun hubungan.

Contoh ini menjelaskan layanan streaming online dasar. Mari kita tinjau apa yang disimpan di setiap tabel dan bagaimana hubungannya dengan tabel lain dalam model kita:

1. Setiap ServiceType mendefinisikan bagaimana akun 'berperilaku' (misalnya berapa banyak pengguna yang dapat terhubung ke sistem pada saat yang sama, jika akun telah mengaktifkan Full HD, dll.). Ia memiliki satu relasi dengan entitas lain:
   • Hubungan satu-ke-banyak dengan Account , artinya setiap jenis layanan dapat memiliki banyak akun dengan jenis tersebut.
2. Setiap Account menyimpan informasi tentang satu pelanggan. Ini memiliki dua hubungan langsung ke entitas lain:
   • Setiap akun milik satu ServiceType , seperti yang dijelaskan di atas.
   • Tabel ini memiliki hubungan satu-ke-banyak dengan Profile tabel, artinya lebih dari satu pengguna dapat terhubung ke sistem kami menggunakan akun yang sama.
3. Setiap Profile mewakili pengguna dalam sistem kami. Ia memiliki dua hubungan dengan entitas lain:
   • Setiap profil dimiliki oleh satu Account . Ini memungkinkan semua anggota keluarga (atau mungkin sekelompok teman) untuk berbagi akun yang sama sementara masing-masing memiliki atribut pribadi mereka sendiri (mis. nama profil).
   • Setiap profil memiliki Avatar yang unik .
4. Setiap Avatar adalah gambar yang memungkinkan kami mengidentifikasi setiap pengguna akun dengan cepat. Ia memiliki satu hubungan dengan entitas lain:
   • Hubungan satu-ke-banyak dengan Profile , artinya satu avatar dapat ditetapkan ke profil di akun yang berbeda.

Hubungan Satu-ke-Banyak dengan Kunci Unik Alami atau Pengganti

Penggunaan kunci primer pengganti adalah cara pemodelan tabel yang diterima secara luas. (Kunci utama pengganti dihasilkan oleh database dan tidak memiliki nilai bisnis yang sebenarnya.) Metode ini menghasilkan kunci yang lebih sederhana untuk digunakan dan menambahkan beberapa fleksibilitas ketika diperlukan perubahan.

Namun, ada situasi – mis. ketika kita perlu berinteraksi dengan sistem eksternal – di mana menggunakan kunci yang dihasilkan dalam database kita adalah pendekatan yang buruk. Untuk skenario tersebut, biasanya lebih baik menggunakan kunci alami, yang merupakan nilai unik yang merupakan bagian dari entitas yang disimpan dan tidak dibuat secara otomatis oleh database kami.

Contoh berikut menunjukkan model data dasar organisasi yang melacak kendaraan (yaitu merek, model, warna, dan tahun mobil), pemiliknya, dan pelanggaran transit terkait. Ketika kami mendefinisikannya, kami menggunakan kunci primer pengganti untuk membangun hubungan antara kendaraan dan merek, model dan pemilik, karena semua informasi ini ditangani secara internal oleh sistem kami.

Dalam sistem ini, bagaimana seorang polisi di kota lain dapat melaporkan mobil yang diparkir secara ilegal menggunakan kunci utama kendaraan kita (VehicleID )? Informasi seperti itu tidak tersedia secara alami di kendaraan yang diparkir, tetapi plat nomornya ada di sana. Itu berarti bahwa cara paling sederhana untuk menerima dan mengaitkan informasi dari sumber eksternal (dalam contoh ini, departemen kepolisian mana pun di negara ini) adalah dengan menggunakan kunci unik alami alih-alih kunci primer pengganti.

Implementasi fisik dari diagram logika ini untuk SQL Server tersedia di sini:

Hubungan Satu-ke-Banyak pada Tabel yang Sama

Contoh sebelumnya berfokus pada hubungan antara dua tabel atau lebih, tetapi ada juga skenario di mana hubungan terjadi antara baris tabel yang sama. Hubungan satu-ke-banyak semacam ini juga disebut hubungan hierarkis; itu digunakan di banyak sistem untuk mewakili struktur seperti pohon, yaitu bagan organisasi, akun buku besar, atau produk dan bagian komponennya.

Pertama kali Anda perlu membuat struktur semacam ini, Anda akan tergoda untuk mendefinisikan tabel untuk setiap level dalam hierarki Anda, seperti yang ditunjukkan pada diagram berikut:

Ada banyak masalah dalam pendekatan ini:

• Semua tabel hampir identik dan menyimpan informasi yang identik.
• Jika organisasi Anda menambahkan level baru, Anda harus mengubah model data dan menambahkan tabel baru, kunci asing baru, dll.
• Jika seorang karyawan menerima promosi, Anda harus menghapusnya dari satu tabel dan memasukkannya ke tabel lain.

Oleh karena itu, cara terbaik untuk memodelkan struktur semacam ini adalah dengan menggunakan satu tabel yang mereferensikan dirinya sendiri, seperti yang ditunjukkan pada diagram ini:

Di sini kita melihat satu Employee tabel dan kolom bernama EmployeeID_Manager . Kolom tersebut merujuk pada karyawan lain di organisasi yang sama yang merupakan supervisor/manajer dari karyawan saat ini.

Saya menambahkan _Manager akhiran untuk membedakan antara ID baris saat ini dan ID pengelola. (Kita bisa menggunakan ManagerID sebagai gantinya, tetapi saya lebih suka untuk mempertahankan nama asli dari kolom yang direferensikan dan, dalam kasus di mana keduanya berada di tabel yang sama, tambahkan sufiks yang menjelaskan peran yang sebenarnya dimilikinya).

Memahami hubungan hierarkis lebih kompleks daripada hubungan satu-ke-banyak lainnya. Tetapi jika Anda lupa tentang tabel tempat semua informasi disimpan dan membayangkan bahwa sebenarnya ada tabel yang berbeda, masing-masing mewakili level dalam hierarki, ini akan lebih mudah untuk divisualisasikan. Bayangkan Anda membuat hubungan antara dua entitas dan kemudian menggabungkannya menjadi satu entitas.

Apa Selanjutnya?

Contoh yang diberikan akan membantu Anda mengidentifikasi skenario berbeda yang memerlukan hubungan satu-ke-banyak. Anda dapat mulai mendesain struktur database Anda sendiri menggunakan Vertabelo Database Modeler, alat berbasis web yang memungkinkan Anda tidak hanya membuat model logis tetapi juga membuat versi fisiknya untuk penyedia database yang Anda butuhkan.

Sekarang giliran Anda – gunakan bagian komentar untuk memberi tahu kami tentang pendapat Anda tentang artikel ini, ajukan pertanyaan tambahan, atau bagikan pengalaman pemodelan basis data Anda.