Kenali diagram ER (Entity Relationship), bagian-bagiannya, dan apa yang sering salah saat membuatnya.
Pernahkah Anda membuat model basis data relasional? Atau mungkin Anda mencoba membuat yang pertama? Anda tahu (atau Anda akan segera mengetahuinya) bahwa menerjemahkan masalah dunia nyata ke logika basis data terkadang cukup sulit.
Salah satu alat yang mungkin bisa membantu Anda adalah diagram ER. Kebijaksanaan desain database umum menyatakan bahwa semakin baik diagram ER Anda, semakin mudah untuk membangun model database. Item penting ini menentukan nada untuk semua frustrasi atau kesuksesan di masa depan. Dengan diagram ER yang baik, membuat model database relasional cukup mudah. Tentu saja, kesalahan dapat dibuat dalam setiap fase pemodelan basis data. Namun, memiliki diagram ER yang baik dapat membantu Anda menghindari beberapa kesalahan tersebut.
Jadi, mari kita lihat apa itu diagram ER dan bagaimana kita bisa menghindari kesalahan umum.
Apa itu Diagram ER?
"ER Diagram", atau ERD, adalah kependekan dari Entity Relationship Diagram. Ini memetakan masalah yang akan dimodelkan, tetapi dengan cara terstruktur yang menunjukkan hubungan antar entitas.
Blok Bangunan Diagram ER
Diagram ER terdiri dari elemen-elemen berikut:
- Entitas
- Hubungan
- Atribut entitas atau hubungan
Elemen pertama dari diagram ER adalah entitas . Entitas adalah objek atau kejadian yang ingin kita simpan informasinya. Pada dasarnya, ini adalah apa saja yang dapat kami kumpulkan datanya. Misalnya, kami mungkin menyimpan data tentang karyawan, siswa, guru, pembeli, produk, departemen, pembayaran, lokasi, dll.
Setelah kita memiliki entitas, kita perlu membuat hubungan . Relasi menunjukkan bagaimana satu entitas terhubung dan terkait dengan satu atau lebih entitas lain.
Elemen terakhir dari diagram ER adalah entitas atau relasi atribut . Atribut adalah deskripsi properti milik entitas atau hubungan. Atribut memiliki nilai. Beberapa atribut untuk entitas yang disebutkan di atas dapat berupa:
- Karyawan, siswa, guru, pembeli – ID, nama, nama keluarga, tanggal lahir, alamat, dll.
- Produk – ID, kategori, deskripsi, warna, nomor seri, dll.
- Departemen – ID, nama departemen, kepala departemen, jumlah karyawan, dll.
- Pembayaran – ID, tanggal dan waktu, jumlah.
- Lokasi – Kota, kode pos, wilayah, negara, benua.
Jenis Hubungan
Sebelum kita masuk ke kesalahan yang biasa ditemukan dalam diagram ER, penting untuk memahami kemungkinan jenis hubungan. Sebagian besar kesalahan ERD pada dasarnya adalah kesalahan definisi hubungan antar entitas.
Ada tiga jenis hubungan antar entitas:
- Satu-ke-satu (1:1)
- Satu-ke-banyak (1:N)
- Banyak-ke-banyak (M:N)
Hubungan satu-ke-satu (1:1)
Jenis hubungan pertama adalah satu-ke-satu , atau 1:1 . Dalam hubungan ini, satu instance dari satu entitas hanya dapat dihubungkan dengan satu instance dari entitas lain (dan tentu saja sebaliknya).
Katakanlah kita memiliki entitas siswa dengan atribut nama dan nama keluarga . Kami juga memiliki entitas id dengan satu-satunya atribut id . Hubungan 1:1 berarti bahwa satu siswa hanya dapat memiliki satu nomor ID. Ini juga berarti bahwa satu nomor ID hanya dapat dimiliki oleh satu siswa.
Hubungan ini sangat jarang terlihat dalam database. Jika hanya satu ID yang dapat dihubungkan dengan hanya satu siswa, tidak perlu memisahkannya menjadi dua entitas yang berbeda.
Berikut ini contoh hubungan ini:
Hubungan satu-ke-banyak (1:N)
Jenis hubungan database yang paling umum adalah satu-ke-banyak atau 1:N . Hubungan satu ke banyak berarti bahwa setiap instance tunggal dari satu entitas dapat dihubungkan dengan beberapa instance entitas lain. Ini juga berarti bahwa setiap instance dari entitas kedua dapat diasosiasikan dengan hanya satu instance dari entitas pertama.
Misalnya, ada entitas pembeli dengan atribut id , nama , dan nama keluarga . Kami ingin menjalin hubungan dengan entitas pembayaran yang memiliki atribut id , tanggal , dan nilai . Ini adalah hubungan 1:N karena satu pembeli dapat melakukan satu atau banyak pembayaran. Namun, satu pembayaran tidak dapat dilakukan oleh beberapa pembeli; hanya dapat dilakukan oleh satu pembeli.
Ini contohnya:
Hubungan ini juga dapat dilihat sebaliknya. Dalam situasi ini, ini disebut banyak-ke-satu atau N:1 . Tentu saja, ini bukan jenis hubungan baru. Ini sama dengan 1:N, tetapi dilihat dari arah yang berlawanan.
Sebagai contoh, misalkan kita memiliki entitas karyawan dengan atribut id , nama , dan nama keluarga . Kami ingin membentuk karyawan hubungan dengan entitas departemen yang memiliki atribut id dan nama . Hubungan antara dua entitas ini adalah N:1. Artinya, setiap karyawan hanya dapat bekerja di satu departemen, tetapi beberapa karyawan dapat bekerja di departemen yang sama.
Hubungan banyak-ke-banyak (M:N)
A Banyak-ke-banyak atau M:N hubungan berarti bahwa setiap instance dari entitas pertama dapat dikaitkan dengan lebih dari satu instance dari entitas kedua. Ini juga berarti bahwa setiap instance dari entitas kedua dapat dikaitkan dengan beberapa instance dari entitas pertama.
Mari kita lihat bagaimana ini bekerja di antara entitas siswa dan kuliah . Katakanlah siswa memiliki atribut id , nama , dan nama keluarga . Entitas kuliah memiliki atribut id dan nama . Hubungan banyak ke banyak dapat diartikan sebagai berikut:satu mahasiswa dapat menghadiri satu atau lebih kuliah, sementara satu kuliah dapat dihadiri oleh satu atau lebih mahasiswa.
Berikut diagram untuk contoh ini:
Dalam pemodelan basis data, hubungan seperti itu biasanya dibagi menjadi dua atau lebih hubungan 1:N atau N:1 dengan memperkenalkan entitas baru.
Kesalahan Umum Terjadi Saat Membuat Diagram ER
Banyak kesalahan diagram ER yang masuk ke dalam salah satu dari empat kategori ini:
- Hubungan yang salah antar entitas
- Menggunakan instance entitas alih-alih entitas
- Membingungkan atribut dengan entitas
- Atribut kompleks
Mari kita lihat satu per satu.
Hubungan yang salah antar entitas
Kesalahan paling umum terjadi saat mendefinisikan hubungan antar entitas . Biasanya tidak ada kesalahan dalam hubungan 1:1. Namun, sangat mudah untuk mengacaukan hubungan 1:N dengan hubungan M:N. Ini biasanya berasal dari tidak memahami persyaratan yang diberikan oleh pengguna akhir. Sangat penting untuk memiliki persyaratan yang sangat jelas dan pemahaman yang mendalam tentang mengapa database diperlukan dan bagaimana database itu akan digunakan. Jika kita membuat diagram ER dengan data yang tidak mencukupi dan pemahaman yang tidak lengkap, kemungkinan besar akan mengakibatkan hubungan antara entitas yang salah didefinisikan.
Mari kita lihat sebuah contoh. Jika Anda membuat database untuk bank, kemungkinan besar Anda akan membuat diagram ER dengan entitas klien memiliki atribut id , nama , dan nama keluarga . Anda juga akan memiliki entitas bernama akun dengan atribut id dan ketik . Jika Anda kurang berpengalaman dalam industri perbankan, Anda mungkin akan berpikir selalu ada hubungan 1:N antara klien dan akun entitas, seperti yang ditunjukkan di bawah ini.
Satu nasabah dapat memiliki beberapa rekening dalam satu bank. Namun, akun hanya dapat dimiliki oleh satu pelanggan. Apakah ini benar? Mungkin iya, mungkin juga tidak. Cukup banyak bank yang menawarkan rekening bersama yang dapat digunakan oleh beberapa klien. Apakah Anda membuat diagram ER untuk bank yang menawarkan layanan seperti itu? Jika bank tidak menawarkan rekening bersama, maka Anda benar:hubungan antara klien dan akun adalah 1:N. Namun, jika bank memang menawarkan rekening bersama, maka hubungannya adalah M:N.
Menggunakan instance entitas alih-alih entitas
Kesalahan umum lainnya adalah menggunakan instance entitas alih-alih entitas. Instance entitas adalah kejadian tunggal dari entitas tertentu – yaitu entitas yang sebenarnya bisa menjadi atribut dari kategori yang lebih besar.
Katakanlah kita bekerja di perusahaan yang mengalokasikan ponsel dan laptop untuk karyawan tertentu. Jadi, di database kami, kami memiliki entitas bernama laptop dengan atribut id dan model dan entitas yang disebut karyawan dengan atribut id , nama , dan nama keluarga , Baik?
Ada masalah di sini:laptop sebenarnya bukan entitas – ada juga ponsel yang harus diperhitungkan. Solusinya adalah mengganti entitas laptop dengan entitas yang lebih umum, seperti peralatan . Entitas ini dapat memiliki atribut ID , ketik , dan model , seperti yang ditunjukkan di bawah ini. jenis dapat terdiri dari nilai seperti telepon , PC , tablet , dan laptop . Dengan cara ini, tidak perlu membuat entitas terpisah untuk setiap jenis peralatan.
Anda dapat menemukan contohnya di sini:
Membingungkan atribut dengan entitas
Kesalahan umum berikutnya adalah membingungkan atribut dengan entitas. Katakanlah kita telah memutuskan untuk membuat entitas bernama karyawan yang akan terdiri dari atribut id , nama , nama keluarga , tanggal_lahir , id_departemen , nama_departemen , dan kepala_departemen . Entitas ini akan membuat kita mendapat masalah saat membuat model database karena terdiri dari terlalu banyak atribut yang tidak secara unik mendefinisikan entitas tertentu .
Ingat, kami mendefinisikan entitas sebagai segala sesuatu yang dapat kami kumpulkan datanya. Dengan mengingat hal itu, kita dapat melihat bahwa karyawan saat ini entitas dapat dibagi menjadi dua entitas:karyawan dan departemen , seperti yang ditunjukkan di bawah ini.
Atribut kompleks
Kesalahan umum terakhir yang akan kita bicarakan adalah memasukkan atribut kompleks dalam suatu entitas. Dengan kata lain, kita memiliki atribut yang seharusnya menjadi entitasnya sendiri .
Katakanlah kita memiliki entitas yang disebut siswa yang ditentukan oleh atribut berikut:id , nama , nama keluarga , tanggal_lahir , alamat , dan lulus_ujian . Di sini, lulus_ujian adalah atribut kompleks yang terdiri dari lebih dari satu informasi, yaitu ID dan tanggal ujian serta nilai siswa. Membiarkannya seperti itu akan menjadi kesalahan. Sebagai gantinya, kita harus membuat entitas baru keluar dari atribut kompleks ini . Entitas baru dapat diberi nama ujian dan terdiri dari atribut berikut:id , tanggal , id_siswa , dan skor .
Anda dapat menemukan contohnya di sini:
Apakah Anda Mendapatkan Tip Diagram ER yang Berguna?
Keempat jenis kesalahan ini adalah yang paling umum dalam proses pembuatan diagram ER. Tentu saja, tidak ada daftar lengkap kesalahan umum atau jenis kesalahan. Dalam kehidupan nyata, banyak jenis kesalahan yang mungkin terjadi. Kurangnya perencanaan, dukungan teknis yang tidak memadai, dan proses desain database yang terburu-buru semuanya berkontribusi pada masalah mereka sendiri. Jika Anda pernah membuat database atau berpartisipasi di dalamnya dari sisi bisnis, Anda mungkin pernah mengalaminya! Semua keadaan itu menyebabkan berbagai kesalahan, beberapa di antaranya cukup unik.
Apakah Anda memiliki contoh diagram ER yang tidak terlalu bagus? Atau mungkin ada beberapa kesalahan lain yang sering Anda temukan? Tolong beri tahu saya di bagian komentar.
