Bir “ya / ya” ilişkisini nasıl modellemeliyim?

Yazılım adında bir varlığım ve FreeSoftware ve NonFreeSoftware adlı iki alt türüm olduğunu varsayalım. FreeSoftware varlığının satın alma tarihi, satıcı vb. Özellikleri vardır. FreeSoftware varlığının lisans, kaynak kodu url'si vb. Özellikleri vardır.

Başka bir varlığı, İşletim Sistemini modellemek istersem, bunu nasıl yapmalıyım? Yazılım ile "ilişki", FreeSoftware ve NonFreeSoftware ile "ya / veya" ilişki vardır.

Sanırım bu hiyerarşiyi analiz etme şeklimde bir şey eksik.

database-design subtypes

— jl6
kaynak

Gözden bu cevabı . Bu tür bir ilişkiyi modellemenin uygulama ayrıntılarını kapsar.

— Nick Chammas

Yanıtlar:

Bunu yönetmenin yolu, alt türlerinizin süper tür tarafından belirlenmesi gerektiğidir (yani alt türün PK'si, alt türden süper türe kadar bir FK'dir.)

Buradaki zorluk, bir şeyin karşılıklı olarak münhasır olup olmadığını anlamaktır. Alt türlerin öznitelikleri yalnızca bu alt türlere uygulanmalıdır, ancak bazı alt türlerin birbirini dışlaması ve bazılarının uygun olmaması olabilir.

Bazı birbirini dışlayan alt türleriniz varsa, birbirini dışlayan (iki veya daha fazla) alt türden hangisinin geçerli olduğunu belirtmek için süper türde bir bölümleme özniteliği kullanabilirsiniz. Bu bölümleme özelliği, karşılıklı münhasırlığı zorunlu kılmak için kısıtlamalarla veya tetikleyicilerle birlikte kullanılabilir.

Karşılıklı olarak dışlanmayan alt türleriniz varsa, bunlar herhangi bir bölümleme özniteliği kullanılmadan var olabilir.

Bu veri modelini düşünün:

ERD

Üç süper türünüz var, ancak FREE_SOFTWAREve bölüm NON-FREE_SOFTWAREtürleri, SOFTWARE.free_not_freebayrak bölümleme özniteliğine bağlı olarak birbirini dışlar . Herhangi bir yazılım parçası OPERATING_SYSTEM, özgür olup olmadığına bakılmaksızın potansiyel olarak birdir.

— Joel Brown
kaynak

Biraz OT: Bu ER diyagramını yapmak için ne kullandınız?

— Daniel Serodio

@DanielSerodio - Visio'yu James Martin ERD notasyonuna dayanarak oluşturduğum akıllı şekillerle kullandım. Şekiller, bir diyagram "taslak" veya taslak tasarım olduğunda insanlara hatırlatmakta yardımcı bulduğum gayri resmi bir görünüm vermek için özel bir çizgi dokusu kullanır.

— Joel Brown

@JoelBrown Şablonlarınızı paylaşmak ister misiniz? Bunlar gerçekten güzel şekiller

— imoatama

@imoatama - Bir süre oldu, ama sonunda şablonun buraya gönderilmesini sağladım : moosewarevisioerd.codeplex.com Açıklamada, şablonun akıllı şekillerinin Visio'nun eski bir sürümü ve bazı davranışları için oluşturulduğuna dikkat edin. ilişki bağlayıcı şekiller biraz pul pul olabilir. Bir gün bunu düzeltmeye gideceğim.

— Joel Brown

İşletim Sistemi neden tamamen yeni bir varlık olsun? Yazılımın altına düşmelidir, olduğu gibi. Ve bir işletim sisteminin (kapalı kaynak ise) bir satın alma tarihi, satıcısı vb. Olacaktır ve açık kaynaklı işletim sisteminin bir lisansı, kaynak kodu URL'si vb. Olacaktır.

SoftwareTypeBu hatlar boyunca bir ya da bir şeyle ilişki öneriyorum . O zaman Yazılımın bir işletim sistemi mi yoksa uygulama mı olduğunu ya da desteklediğiniz diğer herhangi bir yazılım türü olup olmadığını belirtebilirsiniz.

— Thomas Stringer
kaynak

OperatingSystem'ın Yazılım uzmanlığı olduğu için ayrı bir varlık olmasını istiyorum. Başka hiçbir Yazılımın sahip olmayacağı özniteliklere sahip olabilir (çekirdek türü, RTOS veya bayrak değil, çok kullanıcılı bayrak vb.).

— jl6

@ jl6 Hala burada farklı olmaya yalvarıyorum. Her yazılım parçasının (bir işletim sistemi olsun ya da olmasın) belirli nitelikleri olacaktır. Bunlar başka yerlerde saklanabilir. İşletim sistemini ayrı tutarak ölçeklenebilirliği en aza indiriyorsunuz.

— Thomas Stringer

Doğru anlarsam, bir Software varlığı ve SoftwareType varlığı önerirsiniz. Free, NonFree ve OperatingSystem'ın sadece farklı SoftwareType örnekleri olduğunu mu söylüyorsunuz? Doğru olduğunuzdan eminim, ancak farklı türlerin çeşitli özelliklerini nerede saklıyorsunuz?

— jl6