Mempelajari Desain Diagram Hubungan Entitas

Halo Artikel ini dikhususkan untuk salah satu model desain yang paling populer, dan juga banyak dikenal - ER ( Entity Relationship ), yang diusulkan oleh para ilmuwan di bidang ilmu komputer - Peter Chen, pada tahun 1976.


Dalam perjalanan artikel, dalam bahasa yang sederhana, menggunakan contoh-contoh sederhana dari kehidupan, kami akan mengembangkan berbagai versi diagram yang akan tergantung pada jenis koneksi mereka. Ayo mulai!

Desain Berorientasi Objek

Pertama-tama, saya ingin mengatakan beberapa kata tentang OOP (Object Oriented Programming / Designing) sehingga tidak ada masalah dengan memahami paradigma diagram itu sendiri. Lebih mudah bagi saya untuk abstrak model ini dengan prinsip OOP, di mana esensi adalah objek, atribut adalah karakteristiknya, dan koneksi adalah sedikit perantara (dalam beberapa kasus, sebagai metode).

Mulai cepat

Kelebihan utama dari model desain Entity Relationship adalah bahwa ia bersifat universal. Anda dapat merancang basis data (Database), pengoperasian program, prinsip-prinsip interaksi, dll.

Apa yang perlu Anda ketahui di awal studi?

- Anda perlu tahu di awal bahwa pekerjaan utama dilakukan pada hubungan esensi dan komunikasi. Untuk persepsi yang lebih mudah, perlu diingat bahwa esensi adalah kata benda yang ada di dalam persegi panjang, dan koneksi adalah kata kerja yang ada dalam belah ketupat. Berikut ini sebuah contoh:



Saya pikir Anda mengerti apa itu. Programmer kami mengajarkan Python. Tampaknya semuanya logis. Tapi di sini, hanya, apa unit-unit ini dalam contoh?

- Ini adalah indikator dari jenis koneksi! Dalam contoh ini, jenis koneksi adalah Satu-ke-Satu:

$$

$$1: 1$$

Kami akan kembali ke jenis komunikasi, tetapi sedikit kemudian, dan sekarang kita perlu mengurai lagi TETAPI
- Grafik harus dibaca di kedua arah. Jika Anda membaca dari kiri ke kanan, maka semuanya logis, seperti yang dikatakan sebelumnya, tetapi jika sebaliknya ... maka kita akan berpikir beberapa kali tentang apa itu logika. Memang, ditulis seperti itu dan itu benar! Ini hanyalah salah satu dari beberapa fitur model ini, yang terkadang membingungkan. Namun, tidak ada yang mencegah Anda, seperti banyak, di sisi unit, dari menambahkan panah, seperti dalam contoh di bawah ini:



PS Saya harap Anda tertarik. Anda dapat membuat diagram seperti itu di editor diagram - Dia.

Atribut

Jadi, kami memiliki seorang programmer, tetapi kami tidak tahu apa-apa tentang dia ... Tanpa itu seorang programmer bukanlah seorang programmer?
- Tanpa atribut apa pun!

Mari kita lengkapi contoh kita:



Ya, atribut tidak benar-benar membedakan programmer kami dari orang biasa ... tetapi di masa depan kami akan memperbaikinya dengan atribut baru! Dalam pandangan saya, atributnya adalah COLUMN (kolom) dalam tabel Database.

Atribut kosong

Jika tidak perlu menunjukkan nama keluarga di tabel database Anda (maka atribut akan opsional), maka atribut harus terdiri dari dua oval: eksternal dan internal (di dalamnya nama atribut).

Mengidentifikasi atribut

Anda mungkin melihat garis bawah nama atribut dalam diagram - ini normal. Anda tidak perlu takut dengan ini, mungkin itu hanya atribut pengidentifikasi. Artinya, itu adalah atribut yang harus selalu diisi, yang diperlukan (kunci utama). Sebagai contoh - id terkenal.

Nah, sekarang kita perlu memberi pengetahuan programmer (bahasa apa, teknologi yang dia tahu).
"Tapi kita tidak akan segera mendaftar dengan setiap atribut yang terpisah komponen pengetahuannya?"
Itu benar, kita akan menggunakan atribut gabungan ( atribut yang terdiri dari atribut komponen)! Saya ingin mencatat bahwa atribut-komponen juga dapat berupa komposit. Satu-satunya pertanyaan adalah bagaimana Anda akan mengimplementasikannya.

Jenis-jenis Komunikasi

Bagus Kami dapat menemukan ini. Sekarang perhatikan jenis komunikasi yang tersisa!

Mari kita lanjutkan dengan jenis koneksi - Satu ke banyak:

$$

$$1: N$$

Izinkan saya menunjukkan kepada Anda sebuah contoh:



Sekarang programmer kami juga mempelajari Perl. Tidak buruk.
Namun, saya ingin mencatat bahwa contoh yang disebutkan di atas hanyalah pengecualian, untuk menunjukkan dengan jelas apa hubungan itu, karena mungkin ada seribu cabang, yang konyol untuk digambarkan. Di masa depan, kita akan kembali ke catatan singkat dan benar, dan pola rapuh ini patut diingat sehingga ada gagasan umum tentang apa itu. Saya harap saya berhasil menjelaskan kepada Anda apa yang dimaksud dengan tipe koneksi "Satu ke banyak".
* Rasio satu entitas dengan beberapa entitas dan sebaliknya *

Sebelum melanjutkan mempelajari jenis tautan, Anda harus mengetahui bahwa atribut juga ada di tautan .
Saya tidak akan menunjukkannya sebagai contoh - mungkin, dapat dipahami tanpa masalah, dengan kata-kata. Bayangkan saja Anda memiliki koneksi Transaksi. Misalkan dalam proyek Anda, Anda perlu menyimpan semua informasi tentang transaksi yang disimpan, apakah itu menyimpan ke file atau database - itu tidak masalah. Anda perlu menghemat waktu, pengecualian (kesalahan yang terjadi) dan sesuatu yang lain. Dalam kasus kami, semua hal di atas adalah atribut yang akan dimiliki oleh koneksi. Atribut semacam itu juga dapat berupa komposit, identifikasi, opsional. Pertanyaannya hanya dalam implementasi. Mari kita lanjutkan.

Jenis koneksi terakhir tetap - Banyak ke banyak:

$$

$$M: N$$

Seperti biasa, saya akan menunjukkan kepada Anda dengan contoh, tetapi tidak dengan Programmer, tetapi dengan contoh hubungan Penonton dengan Film, pada layanan apa pun untuk menonton Film:



Ada dua masalah yang diperdebatkan. Mari kita mulai.

Pertama:
- Mengapa komunikasi lebih seperti entitas?

Untuk menyederhanakan hubungan tipe "Banyak ke banyak", entitas perantara digunakan .

"Mengapa tidak ada cabang?"

- Penampil dapat berlangganan banyak Film.
- Film dapat memiliki banyak pemirsa yang berlangganan.

Sekarang, mari kita pertimbangkan cara lain untuk menerapkan hubungan Much to Many, yang akan sedikit lebih sulit untuk ditulis, tetapi mungkin lebih dimengerti bagi mereka yang tidak tahu tentang entitas perantara:



Seperti yang mungkin Anda perhatikan, dalam contoh ini ada jenis koneksi "Satu ke banyak", dan bahkan beberapa.
Ini benar dan mudah dijelaskan. Faktanya adalah, tipe koneksi "Banyak ke banyak" sama dengan dua komunikasi "Satu ke banyak".

$$

$$M: N = 1: N + N: 1$$

Anda mungkin tertarik mengapa kami, antara koneksi dan entitas, memiliki dua sisi.
Ini sudah agak sulit untuk dijelaskan. Baca dengan cermat.
Faktanya adalah bahwa ada koneksi opsional dan wajib . Ingat identitas:

Koneksi opsional menciptakan partisipasi parsial, sedangkan yang wajib membuat partisipasi penuh.

- Apakah partisipasi parsial dan penuh?

Partisipasi parsial juga merupakan salah satu pengecualian, agak mirip dengan atribut opsional, hanya tergantung pada entitas. Bayangkan fotonya. Ada dua entitas:
Pembeli dan Produk. Jenis koneksi - Satu ke banyak.
Mereka memiliki koneksi yang sama - Membeli. Tetapi kita perlu memahami hal lain. Tanpanya pembeli bukan pembeli?
- Tanpa setidaknya satu pembelian!
Kasing ini merupakan perwakilan dari koneksi parsial, karena kami memberikan pilihan untuk "Beli dan menjadi pembeli atau menolak." Dalam hal ini, kami akan memiliki satu keunggulan antara tautan "Pembelian" dan entitas "Produk". Sekarang pertimbangkan partisipasi penuh.

Partisipasi penuh adalah kasus ketika tidak ada pilihan. Pemrogram kami akan tetap menjadi pemrogram, meskipun ia tidak belajar apa-apa, karena kami memperbaiki diagram bahwa ia harus mempelajari sesuatu, dan tidak ada pengecualian. Kami memperbaiki bisnis ini dengan dua sisi. Jenis partisipasi tergantung pada bagaimana Anda merancang, apakah pengambilan sampel diperlukan pada tahap komunikasi.
Ini dilakukan Kami melanjutkan.

Ingat contoh "Satu ke Banyak", di mana setelah tautan "Mengajar" ada nama-nama YP (Bahasa Pemrograman), yang mengarah ke sejumlah besar cabang, karena itu tidak benar dalam hal penulisan. Bayangkan saja, karena kita tidak perlu melakukan cabang ke setiap PL. Kami hanya dapat membuat entitas "Bahasa pemrograman", di mana kami menempatkan atribut yang akan bertanggung jawab untuk nama, usia, kekuatan dan banyak lagi. Saya pikir kamu mengerti. Saya menyarankan Anda untuk menggunakan entri singkat "Banyak untuk banyak orang."

Entitas yang lemah

Pertimbangkan konsep terakhir.

Bayangkan Anda memiliki tabel “Parent” dan “Child”, masing-masing, entitas yang sama dalam diagram. Bisakah yang satu ada tanpa yang lain? Saya kira tidak. Baik secara biologis maupun secara logis umum.

Esensi yang lemah: tidak ada apel tanpa pohon apel

.

Dalam contoh ini, entitas "Anak" adalah entitas yang lemah.

Entitas lemah adalah entitas yang tidak dapat eksis tanpa entitas lain.

Kami membuat entitas "Anak", dengan harapan Orang Tua / Orang Tua tidak memiliki anak dengan nama yang sama, karena jika tidak, entitas kami, yang dapat berupa tabel dalam database, hampir tidak dapat disebut Normalisasi (tabel di mana aturan Otomasi Data dan ada pengidentifikasi kunci utama), karena kita tidak bisa basi membedakan anak-anak.

Namun, kasus seperti itu memang terjadi, tetapi Anda dapat memperbaikinya dengan menambahkan atribut tambahan. Dalam hal ini, atribut "Nama" adalah yang menciptakan situasi yang serupa, dan itu disebut komponen kunci dari entitas yang lemah . Nama atribut tersebut, di oval, digarisbawahi dengan garis putus-putus, dan esensi dan koneksi ditempatkan dalam angka tambahan di mana mereka disusun.

Saya akan menyajikan ini kepada Anda sebagai contoh:

Kesimpulan

Sebagai kesimpulan, saya ingin mengatakan bahwa salah satu pekerjaan dasar yang kompeten dan mendasar adalah penjelasan yang baik tentang tugas-tugas, presentasi produk yang baik yang perlu dikembangkan, dan inilah yang desain model bantu. Entity Relatioship adalah model desain yang telah populer selama beberapa dekade. Hal ini memungkinkan Anda untuk membuat grafik yang elegan, yang, dengan pendekatan yang tepat, dapat ditambahkan dan dimodifikasi di masa mendatang. Luangkan waktu untuk belajar. Terima kasih atas perhatian anda!

Sumber

- Buku "MySQL Guide" Karangan:
Seyed M.M. "Saied" Tahagghoghi, Hugh E. Williams
- en.wikipedia.org/wiki/Entity –relationship_model