Bir veritabanı 1: 1 ilişkisini kullanmanın mantıklı olduğu bir zaman var mı?

Geçen gün normalleşmeyi düşünüyordum ve bu benim başıma geldi, bir veritabanında 1: 1 ilişkinin olması gereken bir zaman düşünemiyorum.

• Name:SSN? Onları aynı masada bulurdum.
• PersonID:AddressID? Yine, aynı masa.

1 milyonlarca örnek oluşturabilirim: çok ya da çok: çok (uygun ara tablolarla), ama asla 1: 1.

Açık bir şey mi kaçırıyorum?

1: 1 ilişkisi tipik olarak daha büyük bir varlığı bir nedenle bölümlere ayırdığınızı gösterir. Genellikle fiziksel şemadaki performans nedenlerinden kaynaklanır, ancak mantık tarafında da büyük bir veri parçasının aynı anda "bilinmiyor" olması bekleniyorsa (bu durumda 1: 0'a sahip olabilirsiniz) veya 1: 1, ancak artık yok).

Mantıksal bir bölüme örnek olarak: bir çalışanla ilgili verileriniz var, ancak yalnızca sağlık kapsamına sahip olmayı seçtiyse toplanması gereken daha büyük bir veri kümesi var. Hem daha kolay güvenlik bölümlemesi sağlamak hem de sigortayla ilgili olmayan sorgularda bu verilerin taşınmasını önlemek için sağlık kapsamıyla ilgili demografik verileri farklı bir tabloda tutardım.

Fiziksel bir bölüme örnek olarak birden çok sunucuda barındırılan veriler verilebilir. Sağlık kapsamı demografik verilerini başka bir durumda (örneğin İK ofisinin olduğu yerde) tutabilirim ve birincil veritabanı yalnızca bağlı bir sunucu aracılığıyla ona bağlanabilir ... hassas verileri diğer konumlara çoğaltmaktan kaçınarak, (burada nadir olduğu varsayılarak) gerekli olan sorgular.

Fiziksel bölümleme, daha büyük bir varlığın tutarlı alt kümelerine ihtiyaç duyan sorgularınız olduğunda yararlı olabilir .

Bunun bir nedeni veritabanı verimliliğidir. 1: 1 ilişkisine sahip olmak, bir satır / tablo kilidi sırasında etkilenecek alanları bölmenizi sağlar. Tablo A'nın bir ton güncellemesi varsa ve tablo b'nin bir ton okuması varsa (veya başka bir uygulamadan bir ton güncellemesi varsa), tablo A'nın kilitlenmesi tablo B'de neler olduğunu etkilemez.

Diğerleri iyi bir noktaya değiniyor. Güvenlik, uygulamaların vb. Sisteme nasıl çarptığına bağlı olarak da iyi bir neden olabilir. Farklı bir yaklaşım benimseme eğilimindeyim, ancak belirli verilere erişimi kısıtlamanın kolay bir yolu olabilir. Bir tutam içinde belirli bir masaya erişimi reddetmek gerçekten çok kolay.

Bu konudaki blog girişim.

Seyreklik. Veri ilişkisi teknik olarak 1: 1 olabilir, ancak her satır için karşılık gelen satırların bulunması gerekmez. Dolayısıyla, yirmi milyon satırınız varsa ve bunların yalnızca% 0,5'i için bazı değerler kümesi varsa, bu sütunları seyrek olarak doldurulabilecek bir tabloya iterseniz alan tasarrufu çok büyüktür.

Yüksek dereceli cevapların çoğu, 1: 1 ilişkiler için çok yararlı veritabanı ayarlama ve optimizasyon nedenleri verir, ancak 1: 1 ilişkilerinin doğal olarak meydana geldiği "vahşi" örneklerden başka bir şeye odaklanmak istemiyorum.

Lütfen bu örneklerin çoğunun veritabanı uygulamasının önemli bir özelliğine dikkat edin: 1: 1 ilişkisi hakkında hiçbir tarihsel bilgi tutulmaz. Yani, bu ilişkiler herhangi bir zamanda 1: 1'dir. Veritabanı tasarımcısı ilişki katılımcılarındaki değişiklikleri zaman içinde kaydetmek istiyorsa, ilişkiler 1: M veya M: M olur; 1: 1 doğalarını kaybederler. Anlaşılan, işte gidiyor:

• "Is-A" veya süper tip / alt tip veya miras / sınıflandırma ilişkileri: Bu kategori, bir varlık başka bir varlığın belirli bir türü olduğunda geçerlidir. Örneğin, tüm çalışanlar için geçerli özniteliklere sahip bir Çalışan varlığı ve daha sonra bu çalışan türüne özgü özniteliklere sahip belirli çalışan türlerini belirtmek için farklı kuruluşlar olabilir, örn. Doktor, Muhasebeci, Pilot vb. Bu tasarım, çoğu çalışan belirli bir alt türün özel niteliklerine sahip değildir. Bu kategorideki diğer örnekler, üst tür olarak Ürün ve alt tür olarak ManufacturingProduct ve MaintenanceSupply olabilir; Süper tip hayvan ve alt tip köpek ve kedi; vb. Nesneye yönelik bir miras hiyerarşisini ilişkisel bir veritabanına (nesne-ilişkisel modelde olduğu gibi) eşlemeye çalıştığınızda, bu tür senaryoları temsil eden bir ilişki türü olduğuna dikkat edin.

• Bir kuruluş biriminin yalnızca bir patronu ve bir kişinin yalnızca bir kuruluş biriminin patronu olabileceği yönetici, başkan, başkan vb. Gibi "patron" ilişkileri . Bu kurallar geçerliyse, bir departmanın yöneticisi, bir şirketin CEO'su vb. Gibi 1: 1 ilişkiniz vardır. "Patron" ilişkileri yalnızca insanlar için geçerli değildir. Aynı tür bir ilişki, örneğin bir şirketin merkezi olarak yalnızca bir mağaza varsa veya örneğin bir ülkenin başkentiyse sadece bir şehir oluşur.

• Bazı kıt kaynak tahsisi , örneğin bir çalışan bir seferde sadece bir şirket otomobili tahsis edilebilir (örneğin kamyon şoförü başına bir kamyon, taksi şoförü başına bir taksi, vb.). Yakın zamanda bir meslektaşım bana bu örneği verdi.

• Evlilik (en azından çokeşliliğin yasa dışı olduğu yasal yargı bölgelerinde): bir kişi aynı anda yalnızca bir kişiyle evlenebilir. Bu örneği, bir şirket çalışanları arasındaki evlilikleri kaydettiğinde 1: 1 tek yönlü ilişkiye örnek olarak kullanılan bir ders kitabından aldım.

• Eşleşen rezervasyonlar : Benzersiz bir rezervasyon yapıldıktan sonra iki ayrı varlık olarak yerine getirildiğinde. Örneğin, bir araç kiralama sistemi bir kuruluştaki rezervasyonu ve ardından ayrı bir kuruluştaki gerçek bir kiralamayı kaydedebilir. Her ne kadar böyle bir durum alternatif olarak tek bir varlık olarak tasarlanabilse de, tüm rezervasyonlar yerine getirilmediğinden ve tüm kiralamaların rezervasyon gerektirmediği ve her iki durum da çok yaygın olduğu için varlıkları ayırmak mantıklı olabilir.

Daha önce yaptığım uyarıyı, çoğu tarihsel bilginin kaydedilmemesi durumunda 1: 1 ilişkiler olduğunu tekrarlıyorum. Dolayısıyla, bir çalışan bir kuruluştaki rolünü değiştirirse veya bir yönetici farklı bir departmanın sorumluluğunu alırsa veya bir çalışan bir aracı yeniden atarsa ​​veya biri dul kalırsa ve yeniden evlenirse, ilişki katılımcıları değişebilir. Veritabanı bu 1: 1 ilişkileri hakkında daha önceki bir geçmişi depolamazsa, meşru 1: 1 ilişkileri kalır. Ancak veritabanı geçmiş bilgileri kaydediyorsa (her ilişki için başlangıç ​​ve bitiş tarihleri ​​eklemek gibi), hemen hemen hepsi M: M ilişkilerine dönüşür.

Tarihsel notanın iki önemli istisnası vardır: Birincisi, bazı ilişkiler o kadar nadiren değişir ki, tarihsel bilgiler normalde depolanmaz. Örneğin, çoğu IS-A ilişkisi (örneğin ürün tipi) değişmezdir; yani asla değişemezler. Dolayısıyla, tarihsel kayıt noktası tartışmalıdır; bunlar her zaman doğal 1: 1 ilişkiler olarak uygulanır. İkincisi, rezervasyon ve kiralama bağımsız tarihlerdir, çünkü rezervasyon ve kiralama birbirinden ayrı tarihlerdir. Varlıkların başlangıç ​​tarihleri ​​olan 1: 1 ilişkisinden ziyade kendi tarihleri ​​olduğundan, tarihsel bilgiler depolanmış olsa bile bunlar 1: 1 ilişkiler olarak kalacaktır.

Sorunuz, ifade etme şekliniz nedeniyle çeşitli şekillerde yorumlanabilir. Yanıtlar bunu gösteriyor.

Gerçek dünyadaki veri öğeleri arasında kesinlikle 1: 1 ilişki olabilir. Bu konuda soru yok. "Bir" ilişki genellikle bire birdir. Araba bir araçtır. Bir araba bir araçtır. Bir araç bir araba olabilir. Bazı araçlar kamyonlardır, bu durumda bir araç araba değildir. Birkaç cevap bu yorumu ele almaktadır.

Ama bence gerçekten istediğin şey ... 1: 1 ilişkiler olduğunda tablolar bölünmeli mi? Başka bir deyişle, tam olarak aynı anahtarları içeren iki tablonuz olması gerekir mi? Uygulamada, çoğumuz diğer birincil anahtarları değil, yalnızca birincil anahtarları analiz ediyoruz, ancak bu soru biraz farklı.

1NF, 2NF ve 3NF için normalleştirme kuralları hiçbir zaman bir tablonun aynı birincil anahtarla iki tabloya ayrıştırılmasını (bölünmesini) gerektirmez. BCNF, 4NF veya 5NF'ye bir şema koymanın hiç aynı tuşlara sahip iki tabloya neden olup olmayacağını çözemedim. Başımın tepesinden, cevabın hayır olduğunu tahmin edeceğim.

6NF adı verilen normalizasyon seviyesi vardır. 6NF için normalleştirme kuralı kesinlikle aynı birincil anahtara sahip iki tablo ile sonuçlanabilir. 6NF'nin, NULLS'tan tamamen kaçınılabilmesi için 5NF'ye göre avantajı vardır. Bu, hepsi olmasa da bazı veritabanı tasarımcıları için önemlidir. 6NF'ye bir şema koymak için hiç uğraşmadım.

6NF'de eksik veriler, bazı sütunlarda NULL olan bir satır yerine, atlanan bir satırla temsil edilebilir.

Tabloları bölmek için normalleştirme dışında nedenler vardır. Bazen bölünmüş tablolar daha iyi performans sağlar. Bazı veritabanı motorlarında, tabloyu gerçekten bölmek yerine bölümlere ayırarak aynı performans avantajlarından yararlanabilirsiniz. Bu, veritabanı motoruna işleri hızlandırmak için gerekli araçları verirken, mantıksal tasarımı kolay anlaşılır tutma avantajına sahip olabilir.

Onları öncelikle birkaç nedenden dolayı kullanıyorum. Birincisi, veri değişim hızı arasındaki önemli farktır. Tablolarımdan bazılarında, önceki 5 sürümlerini izlediğim denetim izleri bulunabilir, ancak bu 5 sütunu ayrı bir tabloya bölen bir denetim izi mekanizması ile daha verimli olan 10 sütunun 5'inin önceki sürümlerini izlemeyi önemsersem. Ayrıca, yalnızca yazma kayıtları (bir muhasebe uygulaması için diyelim) olabilir. Dolar tutarlarını veya hesaplarını değiştiremezsiniz, eğer bir hata yaptıysanız, yanlış kayıttan düzeltme yazmak için ilgili bir kayıt yapmanız ve ardından bir düzeltme girişi oluşturmanız gerekir. Güncellenemez veya silinemez gerçeğini zorlayan tablo kısıtlamaları var, ancak bu nesne için dövülebilir birkaç öznitelik olabilir, bunlar değişiklik kısıtlaması olmaksızın ayrı bir tabloda tutulur. Bunu yaptığım başka bir zaman tıbbi kayıt başvurularında. Bir ziyaretle ilgili olarak, oturum kapatıldıktan sonra değiştirilemeyen veriler ve ziyaretle ilgili, imzalandıktan sonra değiştirilebilecek diğer veriler vardır. Bu durumda verileri bölerim ve oturumu kapattığında kilitli tablodaki güncellemeleri reddeden kilitli tabloya bir tetikleyici koyacağım, ancak doktorun oturumunu kapatmadığı verilerde güncellemelere izin vereceğim.

Başka bir poster 1: 1 'in normalleşmediğini, bazı durumlarda, özellikle alt tiplemede buna katılmamaya yorum yaptı. Bir çalışan tablom olduğunu ve birincil anahtarın SSN olduğunu varsayalım (bu bir örnek, bunun başka bir iş parçacığı için iyi bir anahtar olup olmadığı konusundaki tartışmayı kaydedelim). Çalışanlar geçici ya da kalıcı olarak farklı türlerde olabilir ve eğer kalıcılarsa, ofis telefon numarası gibi doldurulması gereken daha fazla alana sahiptirler, ancak yalnızca '= Kalıcı' türünde boş bırakılmamalıdır. 3. normal form veritabanında, sütun sadece anahtara, yani çalışana, ancak aslında çalışan ve türe bağlıdır, bu nedenle 1: 1 ilişkisi mükemmel şekilde normaldir ve bu durumda arzu edilir. Normalde doldurulmuş 10 sütunum varsa, aşırı seyrek tabloları da önler,

Düşünebileceğim en yaygın senaryo, BLOB'larınız olduğunda. Büyük görüntüleri bir veritabanında saklamak istediğinizi varsayalım (genellikle bunları saklamanın en iyi yolu değil, ancak bazen kısıtlamalar daha uygun hale getirir). Blob olmayan verilerin aramalarını iyileştirmek için genellikle blobun ayrı bir tabloda olmasını istersiniz.

Saf bilim açısından, evet, işe yaramazlar.

Gerçek veritabanlarında, nadiren kullanılan bir alanı ayrı bir tabloda tutmak bazen yararlıdır: bu ve yalnızca bu alanı kullanarak sorguları hızlandırmak; kilitleri önlemek için, vb.

Alanlara erişimi kısıtlamak için görünümleri kullanmak yerine, bazen sınırlı alanları yalnızca belirli kullanıcıların erişebildiği ayrı bir tabloda tutmak mantıklıdır.

Ayrıca, miras kullandığınız bir OO modelinizin olduğu ve miras ağacının DB'ye kalıcı olması gereken durumları da düşünebilirim.

Örneğin, her ikisi de Hayvandan miras alan bir Kuş ve Balık sınıfınız var. DB'nizde, Animal sınıfının ortak alanlarını içeren bir 'Animal' tablosunuz olabilir ve Animal tablosunun Bird tablosuyla bire bir ilişkisi ve Fish ile birebir ilişkisi vardır. tablo.

Bu durumda, Kuş ve Balık özelliklerini tutmak için çok sayıda boş değerli sütun içeren bir Hayvan tablonuz olması gerekmez; burada balık verilerini içeren tüm sütunlar, kayıt bir kuşu temsil ettiğinde NULL olarak ayarlanır.

Bunun yerine, Kuşlar tablosunda, Hayvan tablosundaki kayıtla bire bir ilişkisi olan bir kaydınız var.

Çok fazla bilginiz varsa 1-1 ilişkiler de gereklidir. Tablodaki her kayıtta bir kayıt boyutu sınırlaması vardır. Bazen kayıtlar çok büyük olmayacak şekilde tablolar ikiye bölünür (ana tablodaki en sık sorgulanan bilgilerle). Veritabanları, tabloların dar olması durumunda sorgulamada daha etkilidir.

Ayrıca, halihazırda üretimde olan ve "gerçek" bir veritabanı değişikliğinden daha az (algılanan) riski olan bir tabloyu genişletmenin bir yoludur. Eski bir sistemde 1: 1 ilişki görmek, genellikle ilk tasarımdan sonra alanların eklendiğini gösteren iyi bir göstergedir.

SQL'de her iki tarafta zorunlu olan iki tablo arasında 1: 1 ilişkisini uygulamak imkansızdır (tablolar salt okunur değilse). En pratik amaçlar için, SQL'deki "1: 1" ilişkisi gerçekten 1: 0 | 1 anlamına gelir.

Referans kısıtlamalarında zorunlu kardinaliteyi destekleyememe, SQL'in ciddi sınırlamalarından biridir. "Ertelenebilir" kısıtlamalar gerçekten dikkate alınmaz, çünkü kısıtlamanın bir süre zorunlu tutulmadığını söylemenin bir yoludur.

Verileri popüler ORM'lerden biriyle kullanıyorsanız, Nesne Hiyerarşinizle eşleştirmek için bir tabloyu birden çok tabloya bölmek isteyebilirsiniz.

1: 1 ilişki kurduğumda bunun ilişkisel bir neden değil, tamamen sistemik bir nedenden ötürü olduğunu gördüm.

Örneğin, bir kullanıcının ayrılmış yönlerini 1 tabloya koymanın ve kullanıcının düzenlenebilir alanlarını farklı bir tabloya koymanın, bu alanlardaki izinlerle ilgili bu kuralları mantıksal olarak daha kolay yazmasına izin verdiğini buldum.

Ama haklısın, teoride, 1: 1 ilişkiler tamamen çelişkilidir ve neredeyse bir fenomendir. Ancak mantıksal olarak veritabanının soyutlanmasını kolaylaştıran programlar ve optimizasyonlar sağlar.

Çoğu zaman, birileri "iyi, neden 1: çok" olamaz diye tasarımların 1: 1 olduğu düşünülür? Kavramları birbirinden erken ayırmak, bu ortak senaryonun beklentisiyle yapılır. Kişi ve Adres çok sıkı bağlanmaz. Bir çok insanın birden fazla adresi vardır. Ve bunun gibi...

Genellikle iki ayrı nesne alanı, bir veya her ikisinin birden çoğaltılabileceğini gösterir (x: çok). Eğer iki nesne felsefi olarak gerçekten, gerçekten 1: 1 olsaydı, o zaman daha çok bir ilişkidir. Bu iki "nesne" aslında bir bütün nesnenin parçalarıdır.

yalnızca belirli senaryolarda gereken genişletilmiş bilgiler. programların tablolar üzerinde derlendiği eski uygulamalarda ve programlama dillerinde (RPG gibi) (tablo değişirse programları yeniden derlemeniz gerekir). Dosyalar boyunca etiketleme, tablo boyutu hakkında endişelenmeniz gereken durumlarda da yararlı olabilir.

Çoğu zaman mantıksal yapıdan daha fiziksel bir şeydir. G / Ç'yi fiziksel aygıtlar arasında bölme veya daha az sıklıkta erişilen verileri veya aynı nesnedeki özelliklerin geri kalanından daha güvenli tutulması gereken verileri ayırmakla ilişkili diğer sorgu optimizasyonlarından yararlanmak için bir tabloyu dikey olarak bölümlemek için yaygın olarak kullanılır (SSN, Maaş vb.).

1-1 bir ilişki öngören tek mantıklı düşünce, belirli niteliklerin yalnızca bazı varlıklara uygulandığı zamandır. Bununla birlikte, çoğu durumda verileri varlık çıkarma yoluyla modellemenin daha iyi / daha normalleştirilmiş bir yolu vardır.

1: 1 bir ilişki için en iyi nedeni veritabanı tasarımının bir SuperType SubType olduğunu. Bu modele dayanarak bir Gayrimenkul MLS veri yapısı oluşturdum. Beş farklı veri feed'i vardı; Konut, Ticari, Çok Aile, Oteller ve Arazi.

Beş ayrı veri beslemesinin her biri için ortak olan verileri içeren bir SuperType oluşturdum. Bu, tüm veri türlerinde çok hızlı "basit" aramalara izin verdi.

Beş veri feed'inin her biri için benzersiz veri öğelerini saklayan beş ayrı SubTypes oluşturuyorum. Her SuperType kaydının, uygun SubType kaydıyla 1: 1 ilişkisi vardı.

Bir müşteri ayrıntılı bir arama yapmak isterse, örneğin PropertyResidential gibi bir Super-Sub türü seçmek zorunda kaldı.

Bence 1: 1 ilişkisi RDBMS'de bir sınıf Kalıtımını eşler. Ortak öznitelikleri içeren bir A tablosu vardır, yani kısmi sınıf durumu RDBMS'de, özel nitelikleri içeren A tablosuyla 1: 1 ilişkisi olan bir tablo B ile RDBMS'de eşlenir. Tablo A ekinde ayrıca "döküm" işlevselliğini temsil eden bir "tür" alanı bulunur

Hoşçakal Mario

Önemli bir performans avantajı varsa, bire bir ilişki tablosu oluşturabilirsiniz. Nadiren kullanılan alanları ayrı bir tabloya koyabilirsiniz.

1: 1 ilişkiler normalleşirse, 1: 1 olacak bir şey aynı tabloda tutulursa, gerçekten mantıklı değildir.

Gerçek dünyada olsa da, genellikle farklıdır. Uygulama arayüzünüzle eşleşmesi için verilerinizi parçalara ayırmak isteyebilirsiniz.

Veritabanınızda bir tür yazılı nesne varsa muhtemelen.

Bir tabloda, T1, bire bir ilişki içeren C1, C2, C3… sütunlarına sahipsiniz. Tamam, normalize edilmiş formda. Şimdi bir tablo T2'de, C1, C2, C3,… sütunları olduğunu (adlar farklı olabilir, ancak türleri ve rolü aynı olduğunu söyleyin) de bire bir ilişki ile. T1 ile aynı nedenlerle T2 için sorun yok.

Ancak bu durumda, C1, C2, C3… ve T1'den T3'e ve T2'den T3'e bire bir ilişki tutan ayrı bir T3 tablosu için uygun görüyorum. Daha önce bir ila birden çok C1, C2, C3… var olan başka bir tablo varsa daha uygun görüyorum. Tablo A'dan tablo B'deki birden çok satıra söyleyin. T1'den B'ye bire bir ilişki, T2'den B'ye aynıdır ve yine de aynıdan A'dan B'ye çoklu ilişki.

Normalleşmenin buna katılmadığına inanıyorum ve bunun dışında bir fikir olabilir: bazı tablolardan bire bir ilişki ve bire birden çok ilişki kullanarak, nesne türlerini tanımlama ve aynı türdeki nesneleri kendi depolama havuzlarına taşıma diğer bazı tablolardan ilişki.

Güvenlik açısından gereksizdir, ancak güvenlik kontrollerini gerçekleştirmenin daha iyi yolları vardır. Düşünün, sadece bir kapıyı açabilecek bir anahtar oluşturursunuz. Anahtar başka bir kapıyı açabiliyorsa, alarmı çalmalısınız. Temel olarak, "CitizenTable" ve "VotingTable" seçeneklerine sahip olabilirsiniz. Vatandaş Bir Oylama Oyunda saklanan Aday Bir oyu. Vatandaş tekrar oylama tablosunda belirirse, bir alarm olmalıdır. Tavsiye olun, bu birebir ilişki çünkü aday alanına atıfta bulunmuyoruz, oylama tablosuna ve vatandaş tablosuna atıfta bulunuyoruz.

Misal:

 Citizen Table
 id = 1, citizen_name = "EvryBod"
 id = 2, citizen_name = "Lesly"
 id = 3, citizen_name = "Wasserman"

 Candidate Table
 id = 1, citizen_id = 1, candidate_name = "Bern Nie"
 id = 2, citizen_id = 2, candidate_name = "Bern Nie"
 id = 3, citizen_id = 3, candidate_name = "Hill Arry"

Sonra, oylama tablosunu şu şekilde görürsek:

 Voting Table
 id = 1, citizen_id = 1, candidate_name = "Bern Nie"
 id = 2, citizen_id = 2, candidate_name = "Bern Nie"
 id = 3, citizen_id = 3, candidate_name = "Hill Arry"
 id = 4, citizen_id = 3, candidate_name = "Hill Arry"
 id = 5, citizen_id = 3, candidate_name = "Hill Arry"

3 numaralı vatandaşın Bern Nie'yi aldatan ateşli bir pantolon olduğunu söyleyebiliriz. Sadece bir örnek.

Üçüncü taraf bir üründen bir veritabanı ile uğraşırken, muhtemelen sıkı bağlantıyı önlemek için veritabanlarını değiştirmek istemezsiniz. ancak verileri ile 1: 1'e karşılık gelen verileriniz olabilir

Her yerde birebir ilişki paylaşan tamamen bağımsız iki varlık vardı. Çok sayıda örnek olmalı:

kişi <-> diş hekimi (1: N, bu yüzden yanlış!)

kişi <-> doktor (1: N, bu yüzden de yanlış!)

kişi <-> eş (onun 1: 0 | 1, bu yüzden çoğunlukla yanlış!)

EDIT: Evet, özellikle her iki tarafta 0 veya 1 değil, her zaman 1: 1 arıyor olsaydım, oldukça kötü örneklerdi. Sanırım beynim yanlış ateşliydi :-)

Tekrar deneyeceğim. Biraz düşündükten sonra, (yazılım ilerledikçe) birlikte olması gereken iki ayrı varlığa sahip olmanın tek yolunun, daha yüksek kategorizasyonda birlikte var olmaları olduğu ortaya çıkıyor. O zaman, eğer sadece ve daha düşük bir ayrışmaya düşerseniz, işler ayrıdır ve olmalıdır, ancak daha yüksek seviyede birbirleri olmadan yaşayamazlar. Bağlam, o zaman anahtar.

Tıbbi bir veritabanı için, vücudun belirli bölgeleri hakkında farklı bilgileri saklamak ve bunları ayrı bir varlık olarak saklamak isteyebilirsiniz. Bu durumda, bir hastanın sadece bir kafası vardır ve buna sahip olması gerekir, ya da bir hasta değildir. (Ayrıca bir kalbi ve diğer gerekli tek organları vardır). Örneğin ameliyatları izlemekle ilgileniyorsanız, her bölge benzersiz bir ayrı varlık olmalıdır.

Bir üretim / envanter sisteminde, araç montajını izliyorsanız, motorun araba gövdesinden farklı bir şekilde ilerlemesini izlemek istersiniz, ancak bire bir ilişki vardır. Bir bakımın bir motoru ve sadece bir motoru olmalıdır (ya da artık bir 'araba' olmaz). Bir motor sadece bir araca aittir.

Her durumda ayrı varlıkları büyük bir kayıt olarak üretebilirsiniz, ancak ayrışma seviyesi düşünüldüğünde, bu yanlış olur. Bu belirli bağlamlarda, gerçekten daha bağımsız bir seviyede olsalar da, daha yüksek bir düzeyde görünmeyebilirler.

Paul.