Kapan kita harus menggunakan entitas yang lemah saat memodelkan basis data?

12

Ini pada dasarnya adalah pertanyaan tentang apa itu entitas yang lemah? Kapan kita harus menggunakannya? Bagaimana mereka harus dimodelkan?

Apa perbedaan utama antara entitas normal dan entitas lemah? Apakah entitas yang lemah terkait dengan objek nilai saat melakukan Desain Berbasis Domain?

Untuk membantu menjaga pertanyaan pada topik di sini adalah contoh yang diambil dari Wikipedia yang dapat digunakan orang untuk menjawab pertanyaan ini: masukkan deskripsi gambar di sini

Dalam contoh OrderItemini dimodelkan sebagai entitas yang lemah, tapi saya tidak bisa mengerti mengapa itu tidak dapat dimodelkan sebagai entitas normal.
Pertanyaan lain adalah bagaimana jika saya ingin melacak riwayat pesanan (yaitu perubahan dalam statusnya) apakah itu entitas yang normal atau lemah?

design database database-design entity Songo
sumber

Jawaban:

10

Secara formal entitas "lemah" memiliki karakteristik sebagai berikut.

1.  It is existence-dependent on another entity, i.e., 
    it cannot exist without the entity with which it has a relationship.

2.  It inherits at least part of it's primary key from the entity to which 
    it is related. 


    i.e. -> A weak entity's primary key must be a composite key that includes 
       the primary key of the entity on which it is existence-dependent.

Saya akan mengatakan bahwa dalam praktiknya Anda tidak akan secara terang-terangan memutuskan untuk membuat sesuatu entitas yang "lemah"; Anda sebaliknya akan menyusun data untuk mewakili apa pun yang Anda coba modelkan. Jika, setelah Anda melakukan ini, Anda melihat entitas tertentu dan memiliki karakteristik entitas "lemah", Anda dapat mendokumentasikan atau membuat diagram sesuai dengan itu jika karena alasan tertentu Anda merasa perlu untuk secara eksplisit menyebut ini atau demi formalitas.

Ed Hastings
sumber
hmmm jadi bagaimana dengan contoh saya? di sini OrderItemtergantung pada Orderkarena tidak orderItemsada yang bisa ada tanpa menjadi milik order, tetapi saya tidak dapat melihat mengapa saya tidak dapat menggunakan ItemLineNumberuntuk hanya mengidentifikasi item ?! Sebenarnya saya mungkin hanya membuat ItemLineNumberotomatis dihasilkan intuntuk memastikan keunikan dan menggunakan kunci asing orderIDuntuk menghubungkan kedua entitas bersama ?!
Songo
2
Jika Anda menetapkan OrderItem Anda untuk memiliki id sekuensial yang mengidentifikasi secara unik, dan OrderId bukan bagian dari kunci, maka Anda memperlakukan OrderItem sebagai warga negara urutan pertama dan tidak benar-benar memiliki entitas yang lemah. Anda bisa FK tabel lain ke OrderItem secara individual jika Anda mau; tidak perlu sudah memiliki OrderId untuk mendapatkan di OrderItems. Di sisi lain jika Anda mengetikkan OrderItem dengan OrderId dan sequenceId (atau yang serupa) yang relevan dengan Order, Anda akan memiliki entitas yang lemah dan item baris individual hanya akan dapat dirujuk menggunakan OrderId dan sequenceId. Penggunaan model sebagaimana dimaksud.
Ed Hastings
2
Juga, komentar tangensial, bisa sangat menggoda untuk hanya memberikan setiap tabel kunci primer sekuensial sendiri, dan menjaga hubungan sesederhana mungkin dengan bidang tunggal PK-> hubungan FK. Ini bagus untuk basis data sederhana khususnya, dan mudah untuk dipikirkan. Namun, ketika memodelkan hubungan yang lebih kompleks dan / atau canggih, kunci komposit menjadi sangat berguna dan memberi Anda lebih banyak opsi untuk memodelkan nuansa.
Ed Hastings
1

Sebuah OrderItemtidak bisa ada tanpa pesanan atau produk. Karena itu lemah karena dependensi mengendalikannya.

Jika Anda misalnya menghapus pesanan Anda tidak memiliki cara untuk mengetahui di mana barang harus dikirim. Atau jika Anda menghapus produk Anda tidak tahu harus mengirim apa.

jgauffin
sumber
-1

Menurut pemahaman saya dalam diagram di atas, mereka telah memasukkan dua entitas / tabel alih-alih satu yaitu pesanan dan item pesanan sehingga mengakses informasi menjadi mudah ketika dua entitas dirancang. Dan item pesanan tergantung pada entitas pesanan sehingga dianggap sebagai entitas yang lemah. karena karakteristik dari entitas yang lemah itu tergantung pada entitas yang lain. Misalkan jika Anda tidak memasukkan entitas item pesanan, bagaimana Anda dapat mengetahui harga barang pesanan, diskon. dan seperti kata jgauffin. Jika Anda misalnya menghapus pesanan, Anda tidak memiliki cara untuk mengetahui di mana barang harus dikirim. Atau jika Anda menghapus produk Anda tidak tahu harus mengirim apa.

Diagram ER harus dirancang sesuai dengan kebutuhan bisnis.

sam
sumber
-1

Lihat, pesanan memiliki banyak item pesanan (atribut multinilai). Jadi menurut aturan kita membuat tabel terpisah.

Sekarang, katakanlah 2 pelanggan memiliki pesanan yang sama. Baik membeli iPhone dengan harga yang sama, diskon, tanggal yang sama, dll. Jadi idealnya harus ada dua tuple yang tepat untuk urutan iPhone dalam kaitannya dengan pemesanan. Tetapi menurut batasan relasi, semua tupel harus unik. Jadi mari kita hubungkan dua pesanan ke item_line_number.no masalah yang sama uptil sekarang. Sekarang pertimbangkan salah satu pelanggan membatalkan. Apakah pesanan iPhone. Juga tuple item_line_number akan dihapus. Sekarang pelanggan lain yang membeli iPhone juga dihapus karena korespondensi M: 1. Jadi akhirnya database tidak konsisten. Itu sebabnya kami menggunakan kunci deskriptor yang akan dipesan. Menghapus satu iPhone yang dipesan tidak menyebabkan korupsi basis data.

VIVEK baropia
sumber