Mengubah Model ER kepada Model Relational: Panduan untuk Pemula

Hai sana, para ahli pangkalan data masa depan! Hari ini, kita akan melangkah ke dalam perjalanan menarik dari dunia Model Entitas-Relasi (ER) ke negeri Model Relational. Jangan khawatir jika kamu merasa sedikit kesulitan – kita akan melakukannya langkah demi langkah, dan pada akhirnya, kamu akan mengubah diagram ER menjadi skema relational seperti seorang ahli!

Mengapa Mengubah ER ke Relational?

Sebelum kita memulai, mari bicarakan mengapa kita melakukan ini. Bayangkan kamu sedang membangun sebuah rumah. Model ER adalah seperti rancangan anda – ia menunjukkan gambaran besar. Tetapi untuk benar-benar membangun rumah, kamu butuh rencana detil. Itu di mana Model Relational memasuki permainan. Ia memberikan kita cara nyata untuk mengimplementasikan desain pangkalan data kita dalam sistem manajemen pangkalan data nyata (DBMS).

Sekarang, mari kita mulai!

Pemetaan Entitas

Apa Itu Entitas?

Entitas adalah seperti "sesuatu" dalam dunia pangkalan data kita. Itu bisa menjadi orang, tempat, atau objek – apa pun yang kita ingin menyimpan informasi tentang.

Cara Memetakan Entitas

Ketika kita memetakan entitas ke model relational, kita membuat sebuah tabel. Itu saja! Setiap atribut entitas menjadi kolom di tabel.

mari lihat contoh:

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 Kunci tentang Kunci Utama

Bayangkan kunci utama sebagai kartu ID unik seorang murid. Tidak ada dua murid yang seharusnya memiliki kartu ID yang sama, begitu pula tidak ada dua baris di tabel kita yang seharusnya memiliki nilai kunci utama yang sama.

Pemetaan Hubungan

Hubungan dalam model ER menunjukkan bagaimana entitas terhubung. Dalam dunia relational, 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, tapi 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 butuh 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 adalah seperti sidekick – ia tidak bisa eksis tanpa superhero (entitas kuat). Dalam istilah pangkalan data, ia tidak memiliki kunci utama sendiri.

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

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

Kunci utama untuk Room akan berupa kombinasi BuildingID dan RoomNumber.

## Pemetaan Entitas Hierarkis

Entitas hierarkis adalah seperti pohon keluarga dalam dunia pangkalan data kita. Kita memiliki beberapa pilihan untuk memetakannya:

### 1. Pendekatan Tabel Tunggal

Kita menempatkan semuanya 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 penggabungan 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 di sana kamu punya nya, teman-teman! Kita telah melintasi perjalanan dari dunia konseptual model ER ke realm konkrit model relational. Ingat, latihan membuat sempurna. Cobalah membuat diagram ER sendiri dan konversikan mereka ke model relational. Sebelum kamu tahu, kamu akan berbicara dalam bahasa pangkalan data secara lancar!

Terus belajar, terus tumbuh, dan yang paling penting, bersenang-senang dengan pangkalan data mu. Sampai jumpa lagi, selamat coding!

Credits: Image by storyset