Kavramsal bir diyagram oluşturuyorum [evet, nitelikleri ve anahtarları eklediğimi biliyorum - ama bu sadece öğrenirken yaptığım şeyleri pekiştirmek için] - bu yüzden lütfen İlişkiler ve tablolar ve diyagram değil;)

Zihin engelim: Profil, Yer ve Organizasyon ilişkilerini modellemenin en iyi yolunu bulmaya çalışıyorum.

Her şeyden önce, KURALLAR:

• Bir veya daha fazla Profil bir veya daha fazla Kuruluşun Üyesi / Arkadaşı olabilir ; ve tam tersi.
• Bir veya daha fazla Profil , diğer Profillerin Üyesi / Arkadaşı olabilir.
• Bir veya daha fazla Kuruluş , diğer Kuruluşların Üyesi / Arkadaşı olabilir.

Arkadaş ve Üye farklıdır, çünkü Arkadaşlar salt okunur gibidir ve Üyeler [düzeye bağlı olarak] değişikliklere tam erişime sahiptir.

İşleri daha da karmaşık hale getirmek için, Konumların kendi "daha fazla" yeniden düzenlenebilir kuralları vardır, örneğin bir Kuruluşun iki Konumu vardır , ancak Konum kurallarına bağlı olarak, söz konusu Kurumun bir Üyesi [ Profili ] bir Konumda tam erişime sahip olabilir, ancak diğer. [Üzgünüz: büyük olasılıkla daha iyi görüntüleme boyutu için resmi başka bir pencerede açmanız gerekecek.]

Gördüğünüz gibi, Profiller ve Organizasyonlar kavramı aynıdır, bunun yanı sıra henüz modellenmemiş Arkadaşlar ve Üyeler kavramı [... Sahip olduğum mevcut ara tablolar gibi ele alınacaktır / Yönetici / Üye / Arkadaş vb. Bu nedenle, neden aşağıdaki konsepti düşünüyorum:

Yukarıdaki görüntüdeki Option.2'ye bakın : bu, geçerli Organization ve Organization_Locations Tablolarını ve ilişkilerini kaldıracak ve Profile ile biraz yinelemeli bir ilişki olarak Option.2 Organizasyon Tablosu ile değiştirecektir .

Meselenin özü, basitlik ve esnekliğe zarar vermek için çok programlı olarak çok programlı olarak düşünülüp düşünülmediğimi, kendimi tamamen süreçte karıştırdığım;

Düşünceleriniz için şimdiden teşekkürler, çok takdir - M :).

Gözden Geçirilmiş Diyagram:

MDCCL'nin sorularına yanıt olarak:

1. Evet, Profil bir Kişiden oluşur ve aynı anlamı taşır - mantığınızın nereye gittiğine rağmen - haklı olduğuna inanıyorum: Organizasyon ve Kişi Profilin alt tipleri olabilir ; bu nedenle, Profil bir Kişi veya bir Kuruluştan oluşur.
2. Profil başına bir E-posta Adresi.
3. Evet. Yukarıdaki gibi, Kuruluşun en azından bir E-posta Adresi olmalıdır.
4. Doğru, bir sabit adres.
5. Bu bir olasılıktır, ancak nadiren - öğrendiğim kadarıyla - bu nedenle gelecekteki uzun ömürlülük vb.

6. Yer kesinlikle diğerleri arasında ayrılmaz bir varlıktır. Belki burada özlü bir şekilde ne yapılabileceğini açıklığa kavuşturacağım, sonra ilk önce bu soruya faydalı eklemeler getirecek olan diğer cevaplarımı okumanıza izin vereceğim [ sonra sonunda # 6'ya cevabımı görüyorum ];) Re: Rol Sahibi. An **Organization** can be an Owner of zero or more **Locations**. A Person can be an owner of zero of more Locations[bu nedenle, daha önce tahmin ettiğiniz gibi; basitçe ifade etmek gerekirse, bir Profil sıfır veya daha fazla Konumun sahibi olabilir.

7. Evet, bir profili bir olan Sahibi a Konum tüm varsayar Rol İzinlerini [süper kullanıcı]; Bir Profil bir olan Yönetici ilişkin bazı ayrıntıların değiştirebiliyor Konum /, ama esas yardımcı olan diğer tüm aracılığıyla sağlanan ayrıntılar / verileri düzenler / Profil s - bu öncelikle tarafından sağlanacaktır 'Temel Üyesi / s' sözü Yer / sn; bu , ilgili tüm Konum ayrıntılarını salt okunur okuyabilen ve Yönetici / Sahip tarafından incelenmesi gereken verileri sağlayan Temel Üyeden ayrılır . Bunun ötesinde, herhangi bir Profil[Kuruluş / Kişi] çok benzer Temel Üye edelim terimini onları bir - 'salt okunur' Misafir - ancak Konum olarak ayarlanırsa, yalnızca Kamu [değil Özel ] onlar gibi girdi tedarik edemez rağmen, Temel Üyesi can .

8. Doğru.
9. Sezginiz inanılmaz! Evet, it is foreseen that a single Location could contain one to many LocationTypes- işleri daha da karmaşık hale getirmek için - bu tek tek Konum Tiplerinin 'Üst' Konumla ilişkili Profiller için farklı izinlere sahip olabileceği öngörülmektedir; bunlardan izinler Konum'dan KonumTürü / s'lerine [işletim sistemi klasörü güvenlik izinlerine çok benzer] süzülür. Diyagramınız aracılığıyla, açıklama olarak daha fazla yazmanız gerektiğini belirtiyor musunuz?
10. Evet.
11. Bkz.
12. Doğru, Profile1 [Kişi veya Kuruluş] ' un sahip olduğu Profile2 [Kişi veya Kuruluş]' un sahip olduğu Konumlar [
13. Çok makul - a) katılıyorum. b) katılıyorum. c) Evet, hmm? ... Belki de Profile [person] to Profile [person] = Friends ile aynı olmalıdır . Tanım ne olursa olsun, Kuruluş (lar) diğer Kuruluş Konumları üzerinde hareket edeceğinden , Konum etrafında döner ; anlamsal olarak da olsa, herhangi bir Kuruluşun 'neden ne kadar iyi olursa olsun' bunu yapabilmek için o Konumun Kuruluşunun 'Üyesi' olarak itaatkâr görünmesini isteyeceğinden şüpheliyim .

[6]. Bu benim için hala biraz gri, ama işte gidiyor ... Muhtemelen benim zararım için, Üye / Arkadaş ilişkileri arasındaki benzerlik o kadar yakın ki onları birleştirmeyi düşündüm; diyagramınız ve yorumunuzla birlikte, onları ayrı tutmak doğru görünebilir [ tek ilişki enum özelliği ile ayırt edecektim: Sahip / Yönetici / Üye / Arkadaş ]. Örneğinizdeki kavramınız: Bir Kuruluşun Sahip Olduğu Bir Konum, birçok Profil [Kişi veya Organizasyon] üzerinde hareket etmeyecek şekilde sıfır olacaktır, ancak Profillerin ilişki yoluyla yere nasıl davrandıkları arasında açık bir fark olmalıdır [Üye veya Arkadaş ] Roles aracılığıyla gösterilir.So perhaps, the default relation between any Profile is Friend [much like Guest at Answer#7], enabling them to view the read-only Location data and msg/email the Location Owner/Admin - but not allow them to receive Location updates, news, etc., as a Member would.

Karşılaştığınız verileri anlamak, sınıflandırmak ve modellemek için zaman ayırmanız harika, çünkü kişisel deneyimimden tüm bunlar, tüm geliştirme sürecini gelecekteki değişiklikler için daha kolay ve çok esnek hale getiriyor. Ve eminim ki zaten bunun farkındasınız.

Ön veri modeli ve varsayılan iş kuralları

Şartnamenizi anladığımı açıklamak için, sorunuzu okuduktan ve diyagramlarınızı yakından inceledikten sonra benim üstlendiğim iş kurallarının bir listesini tanımladım. Bu listeyi tanımladıktan sonra, harici veri tabanına (Dropbox) .PDF belgesi olarak yüklemeye karar verdiğim bir IDEF1X ^[1] veri modelini türettim, çünkü biçimi nedeniyle bu veri modeli gömülü bir görüntüye tam uymuyor. Bu iki araç, ilerlemeye devam etmek için Unsurlar'ın çözmesi başlıklı bölümde aşağıda sıraladığım bazı önemli noktalara referans olarak faydalı olacaktır .

İlk olarak, işte…

• Organizasyonlar ve Profiller Ön Veri Modeli .

Sadece bu olduğundan, ön, istenen nihai veri modelini gerçekleştirmemize yardımcı olan bir araç olarak düşünün.

Varsayılan iş kuralları

Bahsedilen ön veri modeli, aşağıdaki şekilde numaralandıracağım iş kurallarından (sorunuzdan çıkarılmıştır) bir derlemeden türetilmiştir:

Organizasyonlar ve profiller

NotProfile anda eş anlamlı olarak anlaşılmaktadır Person.

• An Organization, bire çok bir dosttur Profiles.
• An Organization, bire çok bir dosttur Organizations.
• An Organization, bire çok üyesidir Organizations.
• A Profile, bire çok üyesidir Organizations.
• A Profile, bire çok bir dosttur Profiles.
• A Profile, bire çok üyesidir Profiles.

Konumlar ve adresler

• Bir Organizationsahibi birini çoğa Locations .
• A Location, bire çok olarak sınıflandırılır LocationTypes( belirli bir zamanda yalnızca bir tane ).
• Bir Locationolabilecek bire birçok Addresses ( tek Physical , tek için Shipping, bir tane için Billing, ya da bir bütün söyledi amaca hizmet eder, veya bir o birleştirir iki amaç ve hizmet veren başka tek tanesi).

• Bir Address, bir-çok tarafından tutulabilir Profilesveya başka bir deyişle, bir -çokProfile tutar . Addresses

• Spesifik bir Addresstarafından kullanılabilir bire çok Profiles (şekilde hizmet Physicaliçin bir Profile için kullanılan, Billingtarafından farklı bir , vs.). Yani, bir Addressiçin benzer bir şekilde çalışır Locationsve Profiles.

  • Böylece, tek bir Addressolabilir, aynı zamanda tipte Physical, Shipping ve Billing .

Konumlar ve roller

• A bire çokLocation açılır . Roles
• A Role, bir-çok halinde gerçekleştirilebilir Locations .
• Bir Profile(o kadar ayarlanmış olan Memberbir bölgesinin Organization) yapabilir -çok tek- Roles de, birden-çok Locations (ancak sadece bir spesifik Roleher Locationzaman içinde belirli bir noktada, yani, daha fazla hiçbir iki ya da Roles aynı anda ).

İlerlemeye devam etmek için çözülmesi gereken hususlar

Veri modelinizin çözünürlüğünde ilerlemeye devam etmek için, bunları çalıştırdığımızda, bu hedefe ulaşmamıza yardımcı olacak ilgili noktaların bir listesi:

1. ProfileBağlamınızdaki terimin , onunla aynı (veya aynı) bir anlama sahip olduğunu varsaydım Person, ancak biraz farklı olabilir. Bu şekilde, senaryonuzda varlıkların Organizationve Personalt tiplerinin olduğunu söyleyebilir misiniz Profile?

2. Bir Can Profile(veya Person) kendi bire birçok EmailAddresses , ya bir edilir Profile(veya Person) sabitlenmiş tam olarak bir EmailAddress ?

3. Bir imkanın sağlamak ister misiniz Organizationüzerinden ulaşılmasını Telephoneve Email, veya bunun sadece mümkün olması sınırlamak istediğiniz bir Profile(veya Person)?

4. Ben varsayalım Locationsabitlenir tam olarak bir Address Çeşidi Physicalbu doğrudur?

5. Bir için mümkün mü Locationtarafından paylaşılacak tek çoğa farklı Organizations veya aksi bir Locationmülkiyetinde edilebilir tek Organization ?

6. Yorumlarla a Memberve a olmanın Friendaynı olduğunu söylediniz. Önerilen ön veri modelimde de görebileceğiniz gibi, size orijinal spesifikasyonları izledim ve mümkün olan en iyi olanı tanımlama çabasında yardımcı olabileceğini düşündüğüm için farklı işletmelerdeki Organizationve Profile(veya Person) arasındaki olası üyelik ve dostluk kombinasyonlarını tasvir ettim. senaryo bölümünüzün yapısı. Bu manada:

   • İfadenin çağrılan varlık ile ilgili an Organization is a Member of another Organizationifadeden farklı etkileri olduğunu varsayıyorum .a Profile (or Person) is a Member of an OrganizationLocation
   • Eğer veri modelinde de görebileceğiniz gibi, ben düşünüyorum Roleait Ownerbir için geçerlidir Organizationgeçerlidir, bana göre ve Rolesbir Profile(ya da Person), bir iç Locationvardır Adminve Member. Bütün bunlar hakkında ne düşünüyorsun? Durumunuz için geçerli olan iş kuralları ile doğrudan temas halinde olduğunuz için, varsayımlarımın doğru olup olmadığını bana söylemelisiniz.

7. Bir Profile(veya Person) Rolesaynı içinde farklı oynayabilir Locationmi? yani bir olabilir Personaynı anda olmak, Adminaynı zamanda bir ve Memberaynı Location? Bu konudaki kurallar nelerdir?

8. Aynı Profile(veya Person) farklı Rolesfarklı oynayabilir düşünüyorum Locations. Örneğin: Belirli bir Profile(veya Person) Location“1” deki “Yönetici” dir ve aynı Profile(veya Person) aynı zamanda “2” Memberiçindeki bir “ ” dir Location. Haklı mıyım?

9. Belirli bir kişinin aynı anda Locationfarklı olması mümkün mü LocationTypes, yoksa bir kişi Locationtam olarak bir tanesine sahip olmaya sabit LocationTypemi?

10. Bu özellik Organization.Website, “dba.stackexchange.com” gibi belirli bir kuruluşun web sitesi adresini temsil ediyor mu?

11. Eğer Profile“1” (olarak anlaşılır Person) “2” nin bir Member(veya Friend) ise Profile, Profile“1” Rolein Locationait olduğu bir Profile“2” ye ait olması mümkün müdür ? Bu tür senaryoların sadece Organizationa ve a arasındaki ilişkiler için geçerli Member Personolduğunu düşünüyorum, ne düşünüyorsunuz?

12. Benzer şekilde, eğer içinde Organization“1” bir olan Member(veya Friend) ait Organization“2”, bu mümkündür Organization“1” dışında bir yürütmek için Rolebir de Locationsahip olduğu Organization“2”? Yine, bu tür senaryoların sadece Organizationa ve a arasındaki ilişkiler için geçerli olduğunu düşünüyorum Member Person, bu doğru mu?

13. Bu bakımdan bu sorunlar-yazıyorum -henüz ben orada karıştığı sadece üç çeşit ilişkiler olduğunu söylemek mantıklı olacaktır düşünüyorum Organizationsve Personsve biz tanımlayabilirsiniz:

    • (a) a Organizationve a arasındaki ilişki Person“ Membership” olarak.
    • (b) a Personve diğeri arasındaki ilişki Person“ Friendhip” den farklı .
    • (c) Bir birey ile farklı bir kişi arasındaki ilişkiyi tanımlamak için henüz anlamlı bir isim bulmadık .OrganizationOrganization
    • Öyleyse, (a), (b) ve (c) hakkında ne düşündüğünüzü söyleyin.

14. A'nın aynı anda bir -çok farklı Organizationolması Friend(veya a Member) olması mümkün müdür ? Ya da sadece a'nın sadece bir farklı ile bir ilişkisi olması mümkündür.OrganizationsOrganizationOrganization?

İlk ilerlemeyi gösteren ardışık veri modeli

Yukarıda listelediğim beklemedeki yönlere verdiğiniz yanıtlara ve kararlarınıza dikkat ederek aşağıdakileri yarattım…

• Organizasyonlar ve Profiller Ön Veri Modeli - İlk İlerleme .

Henüz onunla pek rahat hissetmeme rağmen, bu yeni veri modeli aşağıdaki iş kurallarını ifade ediyor:

• Bir Profileolan ya bir Organization ya da bir Person. ^[2]
• A Profile, bir-çok kişiyi sunan arkadaş olabilir FriendProfilesve a -bir-çok kişiyiProfile kabul eden arkadaş olabilir . ^[3] FriendProfiles
• Bir Locationoluşabilir birden-birçok Locations . ^[4]

Sonraki spesifik yorumlarınızın cevapları

Endişelerin ayrılmasını not etmek / birleştirmek benim için gerçekten ilginç [örn.

Evet, bu iyi bir karşılaştırmadır, ancak endişelerin ayrılması olarak adlandırılmasam da (ki bu kesinlikle uygulama programlama ve tasarımında temel bir ilkedir ), çünkü bu terim yaygın olarak uygulama geliştirme aşamasıyla ilgilidir ve şu anda kendimizi verileri anlama ve mantıksal yapısını tasarlama aşaması.

Kişisel deneyimlerime göre, bu aşamanın önemli şeyleri tüm bağlamlarına koymakla ilgisi olduğunu, belirli ilgi senaryosunda alakalı olan farklı varlıklar arasında var olan ilişkileri görmekle ve bunları bir veri modelinde tasvir ediyor. Hakkında yorum yaptığınız belirli bir durumda, Addressişletmenin diğer varlıklarla, biri ile diğeri ile farklı bağlantıları olabilir .ProfileLocation

Ve evet, bir şey doğru veya doğal hissetmediğinde , ilgili verileri anlamak için daha fazla çaba sarf etmek gerektiğinin bir işareti olabilir. Bu şekilde, Addressvarlık bir ilişkisi olduğunu düşünüyorum çünkü ben, bu yeterli yeri daha fazla dikkat düşünün şeylerden biridir Profileve bir Address olabilir yoluyla ele alınması Locationnedeniyle her gerçeğine (varlık Locationönerilen en az bir tek fiziksel Address), bu nedenle olabilir görevden ProfileAddressson modelde öngörülen ilişkisel varlık, ancak bu noktaları analiz eden devam ve bana fikirlerinizi bildirmeniz gerekir.

Ayrıca, IDEF1X'te daha iyi okunabilirlik için varlıklardaki PK / FK ifadelerini değiştirmek yaygın bir uygulamadır [örneğin ProfileId - LocationOwnerProfileId]?

Evet, bu sizden çok zekice bir açıklama çünkü IDEF1X, DIE KEYS'i tanımlamak için rol adlarının kullanılmakta olduğu varlığa göre anlamını yakalamak için kullanılmasını önerdiğinden . Bunun ayrıca birincil anahtar göçü kavramıyla da yakından ilişkili olduğunu belirtmek gerekir . Nitekim, rol adlarının kullanımı IDEF1X'ten önce gelmektedir, çünkü aslen Dr. EF Codd tarafından 1970 seminal metninde sunuldu. Bu şekilde, IDEF1X standardının ilişkisel modele doğru sadakatini açıkça görebilirsiniz .

Çözümde / ile özellikle neyi sevmediğinizi / modellemediğini hissettiğinizi öğrenmek ister miyim?

Zaten yaklaşık Yukarıda açıklanan detaylar yanında Addressvarlık, ben olmadığından emin değilim Rolesverilen yürüttüğü Profilebir özellikle Locationbir eşdeğer olan Organizationveya bir Person. Benim açımdan bir Personilk ihtiyaçlarını bir ile ilişkili olduğu Organizationve daha sonra bu Organizationsözü atayacağını Personbir gerçekleştirmek için Rolebir özellikle Location, ancak bu kurallar gereksiz olabilir bu nedenle, daha iyi senaryoyu biliyoruz. Bu bağlamda, bana içeriksel açıklama veya bilmek için çok yararlı olacağını gerçeği hakkında ısrar edeceğim anlamını bu veri yapısı-ver geleceği kullanıcıları bu Organization, ProfileveLocation, ancak bunun gizli bilgiler olarak kabul edilebileceğini anlıyorum, bu yüzden bu bir sınırlama olacaktır.

Mevcut yapı ile, herkes ( Organizationveya Person) herhangi biriyle (tekrar Organizationveya Person) ilişkili olabilir ve Roleherhangi bir yerde ( Location) herhangi bir şey olabilir ( ) olabilir, ancak perharps, tam olarak sizin ve kullanıcıların bu veritabanından bekledikleri şeydir elbette ki iyi tanımlanmış kısıtlamalar sunacaksınız. Bu durumda, neredeyse nihai bir çözüm sağlıyoruz. Doğal olarak, fikriniz bu durumda belirleyici olduğundan, bu fikirleri de analiz etmeli ve ardından son adımları atabilmemiz için sonuçlarınızı bana bildirmelisiniz.

Uygulanabilir ikinci ilerleme

Ne yazık ki, iletişim birkaç hafta önce durdu, sanırım yerine getirmeniz gereken iş taahhütleri yüzünden, bu tamamen makul. Daha istikrarlı ve sağlam bir model geliştirmiş olsaydık çok daha memnun olurdum, ancak önceki etkileşimlerimiz nedeniyle sizi doğru yöne yönlendirebileceğimi varsayabilirim.

Bu soru ve cevap sürecinde daha önce sunulanlara ek olarak, önceki veri modellerinden yeni bir ilerleme sağlamanın benzer bir sorunu olan diğer arayanlar için yararlı olabileceğini düşünüyorum. Bu yüzden,…

Organizasyonlar ve Profiller Ön Veri Modeli - İkinci İlerleme

Bu tür veri modelinde görüldüğü gibi, kaldırdık çok-sayıda I arasında önceki modellerinde gösterilmiştir ki ilişki Profileve Addressbelirli bir yana, Profilezaten ilgilidir birden-çok Addresses kendi ait yoluyla Locations.

Bu yeni ilerlemede gösterilen bir başka değişiklik, şimdi bir verili bire-çokLocation kişiye ait olma olasılığını içermesidir . Sonuç olarak, değişmiş (uzaklaştırarak birincil anahtar (bir birleştirici varlık ardından ilave öznitelik) ve çok-sayıda ile ilgilidir) ile . ProfilesLocationLocationOwnerProfileIdProfileLocation

notlar

_{1. IDEF1X , Aralık 1993'te ABD Ulusal Standartlar ve Teknoloji Enstitüsü ( NIST ) tarafından standart olarak tanımlanan oldukça tavsiye edilen bir veri modelleme tekniğidir .}

_{2. Bu, bir (süper) tip-alt tip kümesinin bir oluşumudur . İlgilenmeniz durumunda , bu tür ilişkilerle daha ayrıntılı bir şekilde uğraştığım bir cevap .}

_{3. Çoktan çoğa hiyerarşik bir ilişki örneği ve “Parça Keşfi Sorunu” na kesin çözüm veren yapıya çok benzer . Böyle bir çözüm, elbette, Dr. Edgar Frank Codd tarafından 1970 yılında son derece etkili olan “Büyük Paylaşılan Veri Bankaları için İlişkisel Bir Veri Modeli” kitabında tanıtıldı .}

_{4. Bu şekilde, bu bire çok (veya çoktan bire) hiyerarşik ilişkinin bir örneğidir .}

Bence, nesne modellemeden kavramları ve veri modellemeden kavramları kendi sorununuzu anlamanıza yardımcı olmayacak şekilde bir araya getirmeye çalışıyorsunuz. Umarım dağınıklığı çok fazla karıştırmadan biraz temizleyebilirim.

İlişkisel model, bu nedenle, kalıtımı desteklemez, polimorfizmi dikkate almaz. Bu, bir nesne modelinde kalıtım ve polimorfizm tarafından kolayca ele alınabilen gerçek bir yaşam durumunu modellerken oldukça özel bir tasarım deseninin kullanılması gerektiği anlamına gelir. Daha sonra bu özel tasarım deseni hakkında daha fazla bilgi.

ER modeli ilk geliştirildiğinde, ilişkisel modellemeye alternatif agnostik bir alternatif olması gerekiyordu. İlk başta miras gibi bir şey yoktu. Ancak 1980'lerde veya 1990'larda bir süre, model, kalıtımla elde ettiğiniz aynı etkileyici yeteneklerden bazılarını sağlamak için genişletildi. Bu "genişletilmiş ER modeli" olarak biliniyordu, ancak tüm pratik amaçlar için bugünün ER modeli EER özelliklerini içeriyor.

Bir EER özelliği "genelleme / uzmanlık" adını taşır. Web üzerinde bu konsepti arayabilir ve okuyabilirsiniz. Gen-spec, bir nesne modelinde sınıfların ve alt sınıfların sağladığı aynı ifade yeteneğini sağlar. Ancak Gen-spec, bir gen-spec durumu için ilişkisel tablo tasarımını çevreleyen sorunlarla ilgilenmez. Daha sonra.

ER modellemesinde, bir ilişki her zaman aynı varlıkları içerir. Bu nedenle, bir kuruluş ile bir profil arasındaki arkadaşlık ilişkisi, bir profil ile başka bir profil arasındaki arkadaşlık ilişkisi ile aynı şey değildir. İki ilişkinin farklı isimlere ihtiyacı vardır. Eğer bu kurala uymazsan, kendini düğümlere bağlarsın.

Ya bu, ya da Kuruluşların, Profillerin ve Muhtemelen Konumların hepsi uzmanlaşan genelleştirilmiş bir varlık bulmanız gerekir. Davanızı bu konuda size yardımcı olacak kadar iyi anlamıyorum.

Devam ederken, ilişkisel modelinizi ve ER modelinizi tek bir modelde birleştirdiğinizi fark ettim. Çoğu deneyimli veritabanı mimarı bunu yapar. Ancak, yetkinlik kazanana kadar iki modeli ayrı tutmanızı öneririm (birbirleriyle uzlaştırılmış olsa da).

Son olarak, bir gen-spec durumunu temsil eden ilişkisel tablolar nasıl tasarlanır? Bu iki tasarım modelini "Sınıf-tablo-kalıtım" ve "Tek-Tablo-Kalıtım" konusuna bakmayı deneyin. Stackoverflow'da bunlar için iki etiket vardır. Web'deki desenlerin oldukça iyi sunumları da var. Özellikle Martin Fowler'ın tedavisini seviyorum. Nesne modelcilerinin nasıl düşündüğünü biliyor gibi görünüyor. Bu yardımcı olur umarım.