Database
 sql >> Teknologi Basis Data >  >> RDS >> Database

Pengantar Model Data ER

Model Data Hubungan Entitas , juga disebut ER , adalah salah satu dari berbagai model data yang dapat Anda gunakan untuk mempertimbangkan data Anda.

Secara khusus, ini adalah model data konseptual , karena tidak terkait dengan implementasi tertentu. Itu adalah tugas yang diserahkan kepada model data logika.

Model Data ER sangat umum, sangat tinggi, sehingga dapat diimplementasikan oleh berbagai jenis database yang sangat berbeda.

Ini bagus karena Anda tidak memikirkan detail penerapan, tetapi Anda hanya memikirkan data Anda dan bagaimana data itu diatur . Dan saat melakukannya, Anda dipaksa untuk menganalisis masalah dengan cara yang tidak Anda pikirkan sebelumnya.

Menurut saya diagram ER sangat bagus dalam membantu Anda menganalisis skenario yang melibatkan data.

Model ER memberi Anda alat untuk merepresentasikan, menggunakan notasi grafis, semua data yang Anda perlukan untuk dimodelkan, hubungan antara berbagai jenis data, dan informasi yang terkait dengannya.

Ada 2 item yang menyusun Model ER:

  • entitas
  • hubungan

Entitas adalah jenis data, seperti item atau orang, yang memiliki properti umum.

Relasi adalah relasi antar entitas.

Biarkan saya memberi Anda sebuah contoh, mari kita bicara tentang buku dan penulisnya. Kami memiliki 2 entitas :

  • buku
  • penulis

Buku tertentu adalah turunan dari entitas buku.

Karena kami memiliki 2 entitas, kami memiliki 2 relasi diantara mereka. Salah satunya adalah hubungan antara satu buku, dan entitas penulis. Salah satunya adalah hubungan antara penulis tunggal, dan entitas buku. Jika kita memikirkannya, kita memiliki:

  • sebuah buku memiliki penulis
  • seorang penulis dapat menulis banyak buku berbeda

Notasi visual untuk entitas

Dengan contoh sederhana ini, kita dapat mulai memperkenalkan notasi visual yang akan membantu kita membuat Model Data ER dari skenario kita.

Catatan:Ada banyak cara berbeda untuk menggambar diagram ER. Saya akan menggunakan yang, menurut saya , lebih visual dan lebih masuk akal.

Entitas direpresentasikan sebagai persegi panjang, dengan beberapa teks di dalamnya untuk mengidentifikasinya:

Notasi visual untuk relasi

Relasi antar entitas direpresentasikan, dalam bentuknya yang paling dasar, menggunakan garis yang menghubungkan dua relasi, dan sebuah berlian dengan beberapa teks di dalamnya untuk mengidentifikasi jenis relasi:

Perhatikan bahwa saya tidak membuat 2 hubungan "buku memiliki penulis" dan "penulis menulis buku". Saya membuat satu hubungan "ditulis" antara Buku dan Penulis.

Kardinalitas

Setelah kita memiliki relasi, sekarang kita harus menunjukkan angka-angka yang terlibat. Saat ini, kami memiliki banyak pertanyaan:

  • Berapa banyak penulis yang dapat dimiliki sebuah buku?
  • Dapatkah seorang penulis menulis banyak buku?
  • Apakah seorang penulis perlu menulis setidaknya satu buku untuk disebut penulis?
  • Dapatkah sebuah buku ditulis oleh banyak penulis?
  • Dapatkah sebuah buku ada tanpa setidaknya seorang penulis?

Semua itu adalah pertanyaan yang bagus untuk ditanyakan, dan dalam hal ini saya pikir jawabannya cukup jelas. Dan ketika jawabannya tidak jelas, Anda dapat memikirkan masalahnya dan menambahkan batasan Anda sendiri.

Ada berbagai cara untuk secara visual menunjukkan kardinalitas pada diagram. Beberapa lebih suka mengubah bentuk garis saat terhubung ke entitas.

Saya lebih suka angka, yang membuat segalanya lebih jelas:

Angka-angka di atas berarti ini:sebuah buku dapat ditulis oleh 1 penulis atau lebih. n berarti sejumlah elemen.

Dan seorang penulis dapat menulis dari 0 buku (mungkin sedang menulis satu sekarang) hingga jumlah buku yang tak terbatas.

Yang pertama disebut hubungan nol-ke-banyak . Yang kedua adalah hubungan satu-ke-banyak .

Kami juga dapat memiliki:

  • hubungan satu-ke-satu
  • hubungan banyak-ke-banyak
  • hubungan nol-ke-satu

Atribut

Setiap entitas dapat memiliki satu atau lebih atribut.

Katakanlah kita akan menggunakan hubungan di atas di toko buku. Setiap penulis memiliki nama, bio, URL situs web.

Setiap buku memiliki judul, penerbit, tahun penerbitan, ISBN. Penerbit bisa menjadi entitas juga, jika kita mau. Tapi kita juga bisa mendefinisikannya sebagai atribut sebuah buku.

Ini adalah bagaimana kami dapat mewakili informasi di atas:

Atribut pengenal

Entitas harus diidentifikasi dengan kunci unik. Entitas buku dapat diidentifikasi secara unik dengan atribut ISBN. Setiap buku memiliki satu ISBN (mengingat bahwa kami tidak mewakili satu salinan buku, tetapi sebuah "judul") buku.

Kami mengidentifikasi atribut kunci utama dengan mendasarinya:

Penulis, di sisi lain, tidak memiliki pengenal unik saat ini. Dua penulis dapat memiliki nama yang sama.

Oleh karena itu kita harus menambahkan atribut kunci yang unik. Misalnya id atribut:

Atribut pengenal dapat menjangkau beberapa atribut.

Misalnya, ID paspor dan negara penulis secara unik mengidentifikasi orang tersebut, dan dapat menggantikan id atribut yang kami tambahkan:

Pilih yang mana? Ini masalah apa yang lebih masuk akal dalam aplikasi Anda. Jika kami memodelkan toko buku, kami tidak dapat berharap untuk memiliki negara dan id paspor semua penulis buku. Oleh karena itu, kami akan menggunakan id secara acak kami akan memilih dan mengasosiasikan dengan setiap penulis.

Atribut relasi

Atribut tidak unik untuk entitas. Hubungan juga dapat memiliki atribut.

Pertimbangkan kita perlu memodelkan perpustakaan. Selain entitas buku dan penulis, sekarang kami memperkenalkan entitas pembaca , orang yang meminjam buku untuk membacanya. Kami mengambil nama dan nomor kartu identitasnya ketika mereka meminjamnya:

Tapi kami masih ketinggalan informasi. Kita perlu mengetahui kapan orang tersebut meminjam buku, dan tanggal pengembaliannya, sehingga kita dapat menyimpan informasi tentang semua sejarah buku tertentu di perpustakaan kita. Informasi ini bukan milik buku atau entitas pembaca; itu milik relasi:

Entitas yang lemah

Kami berbicara tentang kunci utama di atas, dan bagaimana bantuan mengidentifikasi entitas secara unik.

Beberapa entitas bergantung pada entitas lain untuk keberadaannya, dan disebut entitas lemah .

Misalkan kita perlu membuat model pesanan untuk toko online.

Untuk setiap pesanan, kami akan menyimpan id pesanan, yang dimulai dari 1 dan bertambah seiring waktu, tanggal dan waktu pemesanan, dan informasi tentang pelanggan, sehingga kami tahu siapa yang harus ditagih dan ke mana harus mengirimkannya.

Kemudian kita juga perlu tahu apa yang mereka pesan. Kami membuat entitas lemah "item yang dipesan", yang mewakili setiap item di troli pada saat checkout.

Entitas ini akan menyimpan harga barang pada saat checkout (jadi ketika kami mengubah harga produk yang dijual, itu tidak akan mempengaruhi pesanan yang sudah dilakukan), jumlah barang yang dipesan, dan opsi yang dipilih. Katakanlah kita menjual kaos, maka dari itu kita perlu menyimpan warna dan ukuran kaos yang dipesan.

Ini adalah entitas yang lemah karena entitas item yang dipesan tidak dapat ada tanpa entitas pesanan.

Hubungan rekursif

Entitas dapat memiliki relasi rekursif dengan dirinya sendiri. Misalkan kita memiliki entitas orang. Kita dapat memodelkan hubungan orang tua-anak dengan cara ini:

Seseorang dapat memiliki dari 0 hingga n anak, seorang anak memiliki 2 orang tua (mengingat skenario paling sederhana).

Hubungan ISA

ISA adalah singkatan dari IS-A, dan ini adalah cara untuk memodelkan generalisasi dalam model ER.

Kami menggunakannya untuk mengelompokkan entitas serupa di bawah payung umum. Misalnya penulis dan pembaca, dalam kasus buku dan contoh perpustakaan, dapat digeneralisasi menggunakan entitas orang.

Keduanya memiliki nama, jadi kami mengekstrak nama hingga entitas orang, dan hanya mengelola kekhasan menjadi penulis atau pembaca di entitas yang sesuai:

Hubungan non-biner

Tidak setiap hubungan benar-benar biner. Mari kita ambil skenario pelajaran.

Sebuah pelajaran berlangsung di sebuah ruangan sekolah hari ini pukul 10:00, dengan seorang guru, berbicara di depan kelas tentang fisika.

Jadi, pelajaran diberikan pada waktu tertentu dalam sehari, itu melibatkan mata pelajaran, guru, kelas, dan ruangan.

Kita dapat memodelkannya dengan cara ini:


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Opsi Basis Data/Pelaporan Penggunaan Paket

  2. Migrasi Database ke Azure SQL Database

  3. Perbedaan Antara Pernyataan JDBC dan Pernyataan yang Disiapkan

  4. Aqua Data Studio

  5. Statistik Inkremental TIDAK digunakan oleh Pengoptimal Kueri