İlişkileri tanımlamak ve tanımlamamak arasındaki fark nedir?

Farklılıkları tam olarak kavrayamadım. Hem kavramları tanımlayabilir, hem de gerçek dünya örneklerini kullanabilir misiniz?

• Bir tanımlama ilişki bir çocuğun tablodaki bir satırın varlığı bir üst tablodaki bir satıra bağlıdır ne zaman olacağı. Bu da çocuğun tablo için bir pseudokey oluşturmak için bu gün yaygın bir uygulama olduğu için kafa karıştırıcı, ama olabilir değil çocuğun birincil anahtarın üst kısmına yabancı anahtar olun. Resmi olarak, bunu yapmanın "doğru" yolu, yabancı anahtarı çocuğun birincil anahtarının bir parçası haline getirmektir. Fakat mantıklı ilişki, çocuğun ebeveyn olmadan var olamayacağıdır.

  Örnek: A'nın Personbir veya daha fazla telefon numarası vardır. Sadece bir telefon numarası olsaydı, bir sütununda saklayabiliriz Person. Birden fazla telefon numarasını desteklemek istediğimizden PhoneNumbers, birincil anahtarı tabloya person_idreferans veren ikinci bir tablo yapıyoruz Person.

  Ayrı bir tablonun özellikleri olarak modellendikleri halde, telefon numaralarını bir kişiye ait olarak düşünebiliriz. Bu, bunun tanımlayıcı bir ilişki olduğuna dair güçlü bir ipucudur (kelimenin tam anlamıyla person_idbirincil anahtarına dahil olmasak bile PhoneNumbers).

• Tanımlayıcı olmayan bir ilişki , üst öğenin birincil anahtar özniteliklerinin alt öğenin birincil anahtar öznitelikleri olmaması gerektiğidir . Bunun iyi bir örneği Person.state, birincil anahtarını referans alan yabancı anahtar gibi bir arama tablosudur States.state. Personile ilgili bir çocuk masasıdır States. Ancak bir satır Person, stateözniteliği tarafından tanımlanmaz . Yani state, birincil anahtarının bir parçası değildir Person.

  Tanımlayıcı olmayan bir ilişki isteğe bağlı veya zorunlu olabilir , yani yabancı anahtar sütunu sırasıyla NULL'a izin verir veya NULL'a izin vermez.

Ayrıca benim cevap bakınız etmek Hala Sigara belirlenmesi İlişkiler vs belirlenmesi Hakkında Confused

Gerçek dünyadan bir açıklama daha var:

Bir kitap bir sahibine aittir ve bir sahibi birden çok kitaba sahip olabilir. Ancak, kitap sahibi olmadan da var olabilir ve mülkiyeti bir sahibinden diğerine değişebilir. Bir kitap ve bir sahip arasındaki ilişki, tanımlayıcı olmayan bir ilişkidir.

Ancak bir kitap bir yazar tarafından yazılır ve yazar birden fazla kitap yazmış olabilir. Ancak kitabın bir yazar tarafından yazılması gerekiyor - yazar olmadan var olamaz. Bu nedenle, kitap ve yazar arasındaki ilişki tanımlayıcı bir ilişkidir.

Bill'in cevabı doğrudur, ancak diğer tüm cevaplar arasında kimsenin en önemli yönü belirtmediğini görmek şaşırtıcıdır .

Tekrar tekrar söylenir, ilişkide ve tanımlayıcı bir çocuğun ebeveyn olmadan var olamayacağı söylenir. (örneğin, kullanıcı287724 ). Bu doğrudur, ama noktayı tamamen özlüyor. Bunu başarmak için yabancı anahtarın geçersiz olması yeterli olacaktır . Birincil anahtarın bir parçası olması gerekmez.

İşte asıl sebep:

Belirleyici bir ilişkinin amacı , yabancı anahtarın ASLA DEĞİŞTİRİLMEMESİ , çünkü birincil anahtarın bir parçasıdır ... bu nedenle tanımlamak !!!

Tanımlayıcı ilişki, üst nesne olmadan bir alt nesnenin var olamayacağını belirtir

Tanımlamayan ilişkiler, nesneler arasında 1: 1 veya 1: n kardinalite arasında düzenli bir ilişki olduğunu belirtir.

Tanımlamayan ilişkiler, üst tablonun gerekli olmadığı durumlarda isteğe bağlı olarak veya üst tablonun kardinalitesini ayarlayarak bir üst öğenin gerekli olduğu durumlarda zorunlu olarak belirtilebilir ...

İşte iyi bir açıklama:

İki varlık arasındaki ilişkiler ya "tanımlayıcı" ya da "tanımlayıcı değil" olarak sınıflandırılabilir. İlişkileri belirleme, üst öğenin birincil anahtarı alt öğenin birincil anahtarına dahil edildiğinde bulunur. Öte yandan, üst varlığın birincil anahtarı alt varlığa dahil edildiğinde, ancak alt varlığın birincil anahtarının bir parçası olmadığında tanımlayıcı olmayan bir ilişki vardır. Ek olarak, tanımlayıcı olmayan ilişkiler ayrıca "zorunlu" veya "zorunlu olmayan" olarak sınıflandırılabilir. Alt tablodaki değer boş olamazsa, tanımlayıcı olmayan zorunlu bir ilişki vardır. Diğer yandan, alt tablodaki değer boş olabildiğinde zorunlu olmayan tanımlayıcı olmayan bir ilişki vardır.

http://www.sqlteam.com/article/database-design-and-modeling-fundamentals

Tanımlayıcı bir ilişkiye basit bir örnek:

Parent
------
ID (PK)
Name

Child
-----
ID (PK)
ParentID (PK, FK to Parent.ID) -- notice PK
Name

İşte karşılık gelen tanımlayıcı olmayan bir ilişki:

Parent
------
ID (PK)
Name

Child
-----
ID (PK)
ParentID (FK to Parent.ID) -- notice no PK
Name

user287724'ün cevabı , kitap ve yazar ilişkisine aşağıdaki örneği vermektedir:

Ancak bir kitap yazar tarafından yazılmıştır ve yazar birden fazla kitap yazmış olabilir. Ancak kitabın bir yazar tarafından yazılması gerekir, yazar olmadan var olamaz. Dolayısıyla kitap ve yazar arasındaki ilişki tanımlayıcı bir ilişkidir.

Bu çok kafa karıştırıcı örneğidir ve kesinlikle geçerli bir örnek değil bir için identifying relationship.

Evet, bir booken az biri olmadan yazılamaz author, ancak authorbir (yabancı anahtar) bookolduğu BELİRLENMESİ DEĞİLbook içinde booksmasaya!

Sen kaldırabilirsiniz authordan (FK) booksatır ve hala bazı diğer alan (tarafından kitap satırı belirleyebilir ISBN, ID... vs), ANCAK kitabın DEĞİL yazarı !!

Ben geçerli bir örneği identifying relationship(ürün tablosu) ve (belirli ürün ayrıntıları tablosu) arasındaki ilişki olacağını düşünüyorum1:1

products table
+------+---------------+-------+--------+
|id(PK)|Name           |type   |amount  |
+------+---------------+-------+--------+
|0     |hp-laser-510   |printer|1000    |
+------+---------------+-------+--------+
|1     |viewsonic-10   |screen |900     |
+------+---------------+-------+--------+
|2     |canon-laser-100|printer|200     |
+------+---------------+-------+--------+

printers_details table
+--------------+------------+---------+---------+------+
|Product_ID(FK)|manufacturer|cartridge|color    |papers|
+--------------+------------+---------+---------+------+
|0             |hp          |CE210    |BLACK    |300   |
+--------------+------------+---------+---------+------+
|2             |canon       |MKJ5     |COLOR    |900   |
+--------------+------------+---------+---------+------+
* please note this is not real data

Bu örnekte Product_IDde printers_detailsmasaya bir FK referanslar olarak kabul edilir products.idmasa ve AYRICA bir PK içinde printers_detailsmasa, bunun nedeni tanımlayıcı bir ilişkidir Product_IDyazıcılar tabloda (FK) BELİRLENMESİ IS çocuk tablonun içinde satır, biz kaldıramazsınız product_idbunun birincil anahtar kaybetti çünkü çocuk tablosundan herhangi satırı daha tanıyamıyor nedeniyle

2 satıra koymak istiyorsanız:

tanımlayıcı bir ilişki, alt tablodaki FK, alt tabloya hala başvururken alt tabloda bir PK (veya tanımlayıcı) olarak kabul edildiğinde ilişkidir.

Başka bir örnek , bazı ülke veritabanı için bir ithalat ve ihracatta 3 tablonuz (ithalat - ürünler - ülkeler) olduğunda olabilir

importTablo (bu alanları vardır çocuktur product_id(FK), country_idbirimler, ulaşım yolunu (hava, deniz) İthal (FK), ithalat miktarını, fiyatını) we may use the (product_id , theher tanımlamak için country_id`) Burada "her ikisi de aynı yıl" ise, her iki sütun da alt tabloda (içe aktarma) bir birincil anahtar oluşturabilir ve ayrıca üst tablolara başvurabilir.

Lütfen mutluyum ve nihayet kavramını anlıyorum identifying relationshipve non identifying relationshipbu yüzden lütfen bana tamamen geçersiz bir örnek için tüm bu oylamalarda yanlış olduğumu söyleme

Evet mantıklı olarak bir kitap yazar olmadan yazılamaz, ancak yazar olmadan bir kitap tanımlanabilir, Aslında yazarla tanımlanamaz!

Yazarı% 100 kitap satırından kaldırabilir ve yine de kitabı tanımlayabilirsiniz! .

Belirleyici olmayan ilişki

Tanımlayıcı olmayan bir ilişki, çocuğun ebeveynle ilişkili olduğu, ancak kendi başına tanımlanabileceği anlamına gelir.

PERSON    ACCOUNT
======    =======
pk(id)    pk(id)
name      fk(person_id)
          balance

HESAP ve KİŞİ arasındaki ilişki tanımlayıcı değil.

İlişki belirleme

Belirleyici bir ilişki, ebeveynin çocuğa kimlik vermek için gerekli olduğu anlamına gelir. Çocuk sadece ebeveyn nedeniyle var olur.

Bu, yabancı anahtarın da birincil anahtar olduğu anlamına gelir.

ITEM      LANGUAGE    ITEM_LANG
====      ========    =========
pk(id)    pk(id)      pk(fk(item_id))
name      name        pk(fk(lang_id))
                      name

ITEM_LANG ve ITEM arasındaki ilişki tanımlanıyor. ITEM_LANG ve LANGUAGE arasında da.

Üst öğe silindiğinde alt öğenin silinmesi gerektiğini düşünüyorsanız, tanımlayıcı bir ilişkidir.

Ebeveyn silinmiş olsa bile alt öğe saklanmalıdırsa, tanımlayıcı olmayan bir ilişkidir.

Örnek olarak, kursiyerler, eğitimler, diplomalar ve eğitim oturumları içeren bir eğitim veri tabanım var:

• kursiyerlerin eğitim oturumlarıyla tanımlayıcı bir ilişkisi vardır
• eğitimlerin eğitim oturumlarıyla tanımlayıcı bir ilişkisi vardır
• ancak kursiyerlerin diplomalarla tanımlayıcı olmayan bir ilişkisi var

Sadece ilgili stajyer, eğitim veya diplomadan biri silinirse eğitim oturumları silinmelidir.

Tanımlayan akrabalık, çocuk varlığın tamamen ana varlığın varlığına bağlı olduğu anlamına gelir. Örnek hesap tablosu kişi tablosu ve kişisel hesap Kişi hesap tablosu yalnızca hesap ve kişi tablosunun varlığıyla tanımlanır.

Tanımlamayan ilişki, alt tablonun üst tablo örneğinin varlığı ile tanımlanmadığı, hesap türü ve hesap tablosu olarak account.accounttype tablosu tanımlanmadığı anlamına gelir.

Aşağıdaki bağlantıda iyi açıklandığı gibi, tanımlayıcı bir ilişki, ER kavramsal modelinde ebeveyniyle zayıf bir varlık türü ilişkisine benzer. Veri modelleme için UML stili CAD'ler ER sembolleri veya kavramları kullanmaz ve ilişki türleri şunlardır: tanımlayıcı, tanımlayıcı olmayan ve spesifik olmayan.

Bunları tanımlamak, çocuğun kendi türlerinde gerçek bir birincil anahtara sahip olmayan ve bu nedenle kendine özgü olarak tanımlanamayan zayıf bir varlık (geleneksel ER modelinde bile tanımlayıcı ilişki olarak adlandırılır) olduğu ilişkiler ebeveynidir. . Fiziksel modeldeki alt tabloya her erişim, ebeveynin birincil anahtarına bağımlı olur (anlamsal olarak dahil edilir), bu da çocuğun birincil anahtarının bir parçasına veya toplamına (ayrıca yabancı bir anahtardır) dönüşür ve genellikle bir bileşik anahtarla sonuçlanır. çocuk tarafında. Çocuğun nihai mevcut anahtarları yalnızca sözde veya kısmi anahtarlardır, ebeveynin PK'sı olmadan bu tür Varlık veya Varlık Kümesi örneğini tanımlamak için yeterli değildir.

Tanımlayıcı olmayan ilişki, tamamen bağımsız varlık kümelerinin sıradan ilişkileri (kısmi veya toplam) olup, örnekleri birbirlerinin benzersiz olarak tanımlanması için birincil anahtarlarına bağlı değildir, ancak kısmi veya toplam ilişkiler için yabancı anahtarlara ihtiyaç duyabilirler, ancak çocuğun birincil anahtarı olarak. Çocuğun kendi birincil anahtarı vardır. Üst kimlik. Her ikisi de bağımsız. İlişkinin temeline bağlı olarak, birinin PK'si diğerine (N tarafı) FK olarak gider ve kısmi ise, toplam ise boş olabilir, boş olmamalıdır. Ancak, böyle bir ilişkide FK, tanımlayıcı bir ilişki söz konusu olduğunda olduğu gibi asla çocuğun PK'si olmayacaktır.

http://docwiki.embarcadero.com/ERStudioDA/XE7/en/Creating_and_Editing_Relationships

Do çocuk yardımına ebeveynden göç niteliklerini belirlemek ¹ çocuk?

• Eğer evet : tanımlama-bağımlılık var, ilişki tanımlıyor ve alt varlık "zayıf" dir.
• Eğer değil mevcut değildir kimlik-bağımlılık, ilişki tanımlayıcı olmayan ve alt varlık "güçlü".

Kimlik bağımlılığının varoluş bağımlılığını ima ettiğini, ancak bunun tersi olmadığını unutmayın. NULL olmayan her FK, ebeveyn olmadan bir çocuğun var olamayacağı anlamına gelir, ancak bu tek başına ilişkiyi tanımlamaz.

Bu (ve bazı örnekler) hakkında daha fazla bilgi için, ERwin Yöntemler Kılavuzu'nun "İlişkileri Tanımlama" bölümüne bakın .

PS Partiye (son derece) geç kaldığımı fark ettim, ama diğer cevapların ya tamamen doğru olmadığını (kimlik-bağımlılık yerine varoluş-bağımlılık açısından tanımlayan) ya da biraz kıvrımlı olduğunu hissediyorum. Umarım bu cevap daha fazla netlik sağlar ...

¹ Çocuğun FK değeri, çocuğun PRIMARY KEY veya (NULL olmayan) UNIQUE kısıtlamasının bir parçasıdır.

Sipariş işlemeden iyi bir örnek gelir. Bir müşterinin siparişinde genellikle siparişi tanımlayan bir Sipariş Numarası, sipariş tarihi ve Müşteri Kimliği gibi sipariş başına bir kez gerçekleşen bazı veriler ve bir dizi satır öğesi bulunur. Her satır öğesi, bir sipariş içindeki bir satır öğesini, sipariş edilen bir ürünü, o ürünün miktarını, ürünün fiyatını ve satır öğesinin miktarını miktarla çarparak hesaplanabilecek bir öğe numarası içerir. fiyat.

Bir satır öğesini tanımlayan sayı, öğeyi yalnızca tek bir sipariş bağlamında tanımlar. Her siparişteki ilk satır öğesi "1" öğe numarasıdır. Bir satır öğesinin tam kimliği, öğe numarası ve parçası olduğu sipariş numarasıdır.

Siparişler ve satır öğeleri arasındaki ana çocuk ilişkisi tanımlayıcı bir ilişkidir. ER modellemesinde yakından ilişkili bir kavram, satır öğesinin bir sipariş subentitesi olduğu "subentity" adıyla geçer. Genellikle, bir alt öğenin bağlı olduğu varlıkla zorunlu bir çocuk-ebeveyn kimlik ilişkisi vardır.

Klasik veritabanı tasarımında, LineItems tablosunun birincil anahtarı (OrderNumber, ItemNumber) olur. Bugünün bazı tasarımcıları, bir öğeye birincil anahtar görevi gören ve DBMS tarafından otomatik olarak eklenen ayrı bir ItemID verecekti. Bu durumda klasik tasarımı tavsiye ederim.

Diyelim ki şu tablolarımız var:

user
--------
id
name


comments
------------
comment_id
user_id
text

Bu iki tablo arasındaki ilişki ilişkiyi tanımlayacaktır. Çünkü yorumlar diğer kullanıcılara değil, yalnızca sahibine ait olabilir. Örneğin. Her kullanıcının kendi yorumu vardır ve kullanıcı silindiğinde bu kullanıcının yorumları da silinmelidir.

Belirleyici bir ilişki iki güçlü varlık arasındadır. Tanımlayıcı olmayan bir ilişki her zaman güçlü bir varlık ile zayıf bir varlık arasındaki ilişki olmayabilir. Bir çocuğun kendisinin birincil anahtarı olduğu bir durum olabilir, ancak varlığının varlığı ana varlığına bağlı olabilir.

Örneğin: bir satıcı ile satıcının kendi birincil anahtarına sahip olabileceği bir kitabın satıldığı bir kitap arasında bir ilişki olabilir, ancak varlığı yalnızca bir kitap satıldığında oluşturulur

Bill Karwin'e dayanan referans