Contoh tipe entitas kuat dan lemah

Entitas lemah adalah entitas yang hanya bisa eksis apabila dimiliki oleh entitas lain. Sebagai contoh: KAMAR hanya bisa eksis di dalam BUMN. Di sisi lain, sebuah TIRE bisa dianggap sebagai entitas yang kuat, karena ia juga bisa eksis tanpa terikat pada sebuah Mobil.

Hanya untuk bermain-main dengan itu, pertanyaan adalah tipe entitas yang kuat dan jawaban adalah lemah. Pertanyaan selalu ada, tetapi jawaban membutuhkan pertanyaan untuk ada.

Contoh: Jangan bertanya "Mengapa?" jika Ayah Anda adalah seorang Profesor Kimia.

Sebuah polis asuransi perusahaan mengasuransikan seorang karyawan dan tanggungannya, TANGGUNGAN tidak dapat ada tanpa KARYAWAN; yaitu, seseorang tidak bisa mendapatkan pertanggungan asuransi sebagai tanggungan kecuali jika orang tersebut adalah tanggungan seorang karyawan.TANGGUNGAN adalah entitas yang lemah dalam hubungan " KARYAWAN memiliki TANGGUNGAN "

A lemah badan adalah entitas yang dapat't diidentifikasi sepenuhnya oleh atribut sendiri dan mengambil foreign key sebagai atribut (umumnya dibutuhkan primary key dari entitas terkait) dalam hubungannya.

Contoh

Keberadaan kamar sepenuhnya tergantung pada keberadaan sebuah hotel. Sehingga ruang dapat dilihat sebagai weak entity dari hotel. Contoh lain adalah rekening bank bank tertentu tidak memiliki keberadaan jika bank doesn't ada lagi.

Kuat badan

Hal ini dapat ada tanpa yang lain entitas.

Contoh

Customer(customerid, name, surname)

Entitas lemah

Hal ini tergantung pada yang dominan entitas, dan itu tidak bisa ada tanpa yang kuat entitas.

Contoh

Adress(addressid, adressName, customerid)

Lemah badan juga disebut dependent entities, sejak itu's keberadaannya bergantung pada entitas yang lain. Entitas tersebut diwakili oleh dua garis persegi panjang dalam E-R diagram.

Kuat entitas juga disebut entitas independen.

./Database/DataModels/RelationalDataModel/WeakEntity

Hal itu mungkin dapat ditulis dalam dua faktor:

• KETERGANTUNGAN: Tergantung pada keberadaan mengidentifikasi entity set (total, satu-ke-banyak hubungan).
• IDENTIFIKASI: tidak memiliki primary key. Ia memiliki kunci parsial (atau discriminator). Perlu menggunakan primary key dari tabel yang lain untuk identifikasi.

Jika kita mau berpikir database memegang pertanyaan dan jawaban, maka pertanyaan akan menjadi kuat badan dan jawaban akan menjadi lemah badan. Jadi, Pertanyaan (id, teks) dan Jawaban (nomor, question_id, teks) akan menjadi meja kami. Tapi mengapa Jawabannya's tabel entitas lemah?

• Ketergantungan terhadap pertanyaan meja. Setiap jawaban dihubungkan ke satu pertanyaan (asumsi) dan agar hal itu tidak bisa sendiri. Itulah mengapa kita memiliki orang-orang yang mengajukan satu pertanyaan dan menjawabnya sendiri sehingga mereka dapat membantu orang lain dan mendapatkan beberapa tambahan kesukaan.

• Identifikasi dari primary key dari pertanyaan. Seseorang tidak akan mampu mengidentifikasi jawaban (dengan asumsi bahwa id adalah nomor pengenal) karena pertanyaan yang mungkin bisa dijawab dengan jawaban dan identifier mungkin ada pertanyaan lain juga. Kunci utama dari jawaban tabel: (jumlah, question_id).

Entitas lemah yang ada untuk memecahkan masalah yang multi-atribut bernilai masalah.

Ada dua jenis multi-valued attributes. Salah satu yang cukup banyak nilai-nilai untuk sebuah benda seperti "hobi" sebagai atribut untuk mahasiswa. Siswa dapat memiliki banyak hobi yang berbeda. Jika kita meninggalkan hobi dalam mahasiswa himpunan entitas, "hobi" tidak akan menjadi unik lagi. Kami menciptakan sebuah entitas yang terpisah ditetapkan sebagai hobi. Kemudian kita link hobi dan mahasiswa seperti yang kita butuhkan. Hobi entitas set sekarang adalah sebuah entitas asosiatif set. Apakah itu adalah lemah atau tidak, kita perlu memeriksa apakah masing-masing entitas memiliki cukup pengidentifikasi unik untuk mengidentifikasi itu. Dalam banyak pendapat, hobi nama dapat cukup untuk mengidentifikasi itu.

Jenis lain dari multi-valued attribute masalah tidak perlu entitas lemah untuk memperbaikinya. Let's mengatakan item himpunan entitas dalam kelontong sistem persediaan. Adalah item kategori item atau benar-benar item? Pertanyaan ini penting, karena pelanggan dapat membeli item yang sama pada suatu waktu dan jumlah tertentu, tetapi ia juga dapat membeli item yang sama pada waktu yang berbeda dengan jumlah yang berbeda. Anda dapat melihat item yang sama tetapi dari objek yang berbeda. Item sekarang adalah multi-valued attribute. Kami menyelesaikannya dengan terlebih dahulu memisahkan kategori item dengan item yang sebenarnya. Dua yang sekarang berbeda entitas set. Kategori item telah deskriptif atribut item, seperti item yang biasanya anda pikirkan. Item yang sebenarnya tidak dapat memiliki atribut deskriptif lagi karena kita tidak dapat memiliki redundant masalah. Item yang sebenarnya hanya dapat memiliki waktu tanggal dan jumlah item. Anda dapat menghubungkan mereka seperti yang anda butuhkan. Sekarang, let's berbicara tentang apakah satu entitas lemah dari yang lain. Deskriptif atribut yang lebih dari cukup untuk mengidentifikasi masing-masing entitas dalam kategori item himpunan entitas. Item yang sebenarnya hanya memiliki waktu tanggal dan jumlah. Bahkan jika kita menarik keluar semua atribut dalam record, kita masih belum bisa mengidentifikasi entitas. Berpikir tentang hal itu hanya waktu dan jumlah. Item yang sebenarnya himpunan entitas adalah entitas lemah ditetapkan. Kami mengidentifikasi setiap entitas pada himpunan dengan bantuan duplikat kunci utama dari kategori item himpunan entitas.

Setelah browsing mesin pencari untuk beberapa jam saya datang di sebuah situs dengan ERD contoh berikut ini: http://www.exploredatabase.com/2016/07/description-about-weak-entity-sets-in-DBMS.html

I've diciptakan ERD. Sayangnya mereka tidak menentukan primary key dari entitas lemah.

Jika bangunan hanya bisa memiliki satu dan hanya satu apartemen, maka tampaknya parsial diskriminator nomor kamar tidak akan dibuat (yaitu dibuang).

Lemah Tipe Entitas: Suatu entitas dan kasus tidak bisa keluar tanpa dikaitkan dengan contoh-contoh dari beberapa badan lain yang disebut entitas lemah tipe. Hal ini tidak bisa eksis secara independen. Misalnya: PC Kita adalah tergantung pada kami tidak akan membuka atau menutup dengan sendiri.

Strong Entity Type: Suatu entitas yang terkait dengan contoh dari entitas lain tipe ini disebut tipe entitas kuat. Hal ini dapat keluar secara independen. Misalnya: seseorang dapat melakukan setiap hal bisa pergi di mana-mana dan menggunakan hal yang pernah

Sebuah objek data yang ada tanpa tergantung pada keberadaan objek data ini dikenal sebagai Data yang Kuat Obyek.

Pertama Kuat/Lemah Referensi jenis diperkenalkan di ARC. Di Non ARC menetapkan/mempertahankan sedang digunakan. Referensi yang kuat berarti bahwa anda ingin "sendiri" objek anda referensi dengan properti ini/variabel. Compiler akan mengurus bahwa setiap objek yang anda tetapkan untuk akomodasi ini tidak akan hancur selama anda poin untuk itu dengan referensi yang kuat. Hanya setelah anda mengatur properti nihil, objek bisa hancur.

Lemah referensi berarti anda menandakan bahwa anda don't ingin memiliki kontrol atas objek's seumur hidup atau don't ingin "sendiri" objek. Objek anda referensi lemah hanya hidup karena setidaknya satu objek lain memegang referensi yang kuat untuk itu. Setelah itu tidak ada lagi kasus, objek akan hancur dan lemah anda akan secara otomatis mendapatkan set nihil. Penggunaan yang paling sering kasus lemah referensi di iOS untuk IBOutlets, Delegasi dll.

Untuk info lebih lanjut Lihat : http://www.informit.com/articles/article.aspx?p=1856389&seqNum=5