Mengkonversi Model ER ke Model Relasional: Panduan untuk Pemula

Hai teman-teman, para ahli basis data masa depan! Hari ini, kita akan memulai perjalanan menarik dari realm Model Entitas-Relasi (ER) ke negeri Model Relasional. Jangan khawatir jika Anda merasa sedikit kebingungan – kita akan mengambil ini langkah demi langkah, dan pada akhirnya, Anda akan mengubah diagram ER menjadi skema relasional seperti seorang ahli!

Mengapa Mengkonversi ER ke Relasional?

Sebelum kita memulai, mari bicarakan mengapa kita melakukan ini. Bayangkan Anda membangun sebuah rumah. Model ER seperti blueprint Anda – itu menunjukkan gambaran besar. Tetapi untuk benar-benar membangun rumah, Anda memerlukan rencana rinci. Itu dimana Model Relasional memasuki gambaran. Itu memberikan kita cara nyata untuk mengimplementasikan desain basis data kita dalam sistem manajemen basis data nyata (DBMS).

Sekarang, mari kita mulai kerjanya!

Pemetaan Entitas

Apa Itu Entitas?

Entitas seperti sebuah "barang" dalam dunia basis data kita. Itu bisa menjadi orang, tempat, atau objek – apa pun yang kita inginkan untuk menyimpan informasi tentang.

Cara Menggambar Entitas

Ketika kita memetakan entitas ke model relasional, kita membuat sebuah tabel. Itu begitu sederhana! Setiap atribut entitas menjadi kolom dalam tabel.

mari lihat contohnya:

Student
ID (PK)
Name
Age
Major
```

Di sini, kita telah memetakan entitas 'Student' ke tabel 'Student'. 'ID' adalah kunci utama (PK) kita, yang secara unik mengidentifikasi setiap murid.

Kata Terhadap Kunci Utama

Bayangkan kunci utama seperti kartu identitas unik seorang murid. Tidak ada dua murid yang seharusnya memiliki kartu identitas yang sama, begitu pula tidak ada dua baris dalam tabel kita yang seharusnya memiliki nilai kunci utama yang sama.

Pemetaan Hubungan

Hubungan dalam model ER menunjukkan bagaimana entitas terhubung. Dalam dunia relasional, kita menggunakan kunci asing untuk mewakili hubungan ini.

Hubungan Satu-ke-Banyak

Ini seperti seorang guru dan murid-muridnya. Satu guru bisa memiliki banyak murid, tetapi setiap murid hanya memiliki satu guru (dalam konteks ini).

| Teacher | | Student | |--------------| |--------------| | TeacherID(PK)| | StudentID(PK)| | Name | | Name | | Subject | | TeacherID(FK)|

Lihat 'TeacherID' di tabel Student? Itu adalah kunci asing (FK) kita. Itu mereferensikan TeacherID di tabel Teacher, menciptakan hubungan.

### Hubungan Banyak-ke-Banyak

Pikirkan murid dan mata kuliah. Satu murid bisa mengambil banyak mata kuliah, dan satu mata kuliah bisa memiliki banyak murid. Untuk ini, kita memerlukan tabel penghubung:


| Student      |   | Enrollment   |   | Course       |
|--------------|   |--------------|   |--------------|
| StudentID(PK)|   | StudentID(FK)|   | CourseID(PK) |
| Name         |   | CourseID(FK) |   | CourseName   |
|              |   | Grade        |   |              |

Tabel Enrollment menghubungkan Murid dan Mata Kuliah, memungkinkan hubungan banyak-ke-banyak.

Pemetaan Set Entitas Lemah

Set entitas lemah seperti teman – dia tidak bisa eksis tanpa superhero (entitas kuat). Dalam istilah basis data, dia tidak memiliki kunci utama sendiri.

Misalnya kita memiliki 'Room' sebagai set entitas lemah dari 'Building':

| Building | | Room | |--------------| |--------------| | BuildingID(PK)| | RoomNumber | | BuildingName | | Capacity | | | | BuildingID(FK)|

Kunci utama untuk Room akan menjadi kombinasi BuildingID dan RoomNumber.

## Pemetaan Entitas Hierarkis

Entitas hierarkis seperti pohon keluarga dalam dunia basis data kita. Kita memiliki beberapa opsi untuk memetakan ini:

### 1. Pendekatan Tabel tunggal

Kita menaruh segalanya di satu tabel:


| Person       |
|--------------|
| PersonID(PK) |
| Name         |
| Type         |
| EmployeeID   |
| StudentID    |

Ini berkerja, tetapi bisa mengakibatkan banyak nilai null.

2. Pendekatan Tabel per Tipe

Kita membuat tabel untuk tipe dasar dan tabel terpisah untuk setiap subtipe:

| Person | | Employee | | Student | |--------------| |--------------| |--------------| | PersonID(PK) | | PersonID(FK) | | PersonID(FK) | | Name | | EmployeeID | | StudentID | | | | Department | | Major |

Pendekatan ini lebih fleksibel tetapi memerlukan penyingkapan untuk pengambilan data.

### 3. Pendekatan Tabel per Tipe Konkrit

Kita membuat tabel terpisah untuk setiap tipe, mengulangi atribut umum:


| Employee     |   | Student      |
|--------------|   |--------------|
| PersonID(PK) |   | PersonID(PK) |
| Name         |   | Name         |
| EmployeeID   |   | StudentID    |
| Department   |   | Major        |

Pendekatan ini menghindari nilai null tetapi bisa mengakibatkan redundant data.

Kesimpulan

Dan begitu saja, teman-teman! Kita telah mengembara dari dunia konseptual model ER ke realm nyata model relasional. Ingat, latihan membuat sempurna. Cobalah membuat diagram ER Anda sendiri dan konversikan mereka ke model relasional. Sebelum Anda sadari, Anda akan bisa berbicara dengan lancar dalam bahasa basis data!

Tetap belajar, tetap tumbuh, dan terutama, bersenang-senang dengan basis data Anda. Sampaijumpa lagi, selamat coding!

Credits: Image by storyset