Como devo modelar um relacionamento "ou / ou"?

Digamos que eu tenha uma entidade chamada Software e dois subtipos FreeSoftware e NonFreeSoftware. A entidade NonFreeSoftware possui atributos como data da compra, fornecedor, etc. A entidade FreeSoftware possui atributos como licença, URL do código fonte etc.

Portanto, se eu quiser modelar outra entidade, o OperatingSystem, como devo fazê-lo? Existe uma relação "é uma" com o Software, mas uma relação "com / ou" com o FreeSoftware e o NonFreeSoftware.

Acho que estou perdendo algo na maneira como estou analisando essa hierarquia.

database-design subtypes

— jl6
fonte

Revise esta resposta . Ele cobre os detalhes de implementação da modelagem desse tipo de relacionamento.

— Nick Chammas

Respostas:

A maneira de gerenciar isso é que seus subtipos devem ser determinados pelo super-tipo (ou seja, a PK do sub-tipo também é uma FK do sub-tipo ao super-tipo.)

O desafio é entender se algo é verdadeiramente mutuamente exclusivo ou não. Os atributos dos subtipos devem aplicar-se apenas a esses subtipos, mas pode ser que alguns subtipos sejam mutuamente exclusivos e outros não.

Se você tiver alguns subtipos mutuamente exclusivos, poderá usar um atributo de particionamento no supertipo para indicar qual dos (dois ou mais) subtipos mutuamente exclusivos se aplica. Esse atributo de particionamento pode ser usado com restrições ou gatilhos para impor a exclusividade mútua.

Se você tiver subtipos que não são mutuamente exclusivos, eles poderão existir sem usar nenhum atributo de particionamento.

Considere este modelo de dados:

ERD

Você tem três supertipos, mas os tipos FREE_SOFTWAREe NON-FREE_SOFTWAREsão mutuamente exclusivos, com base no SOFTWARE.free_not_freeatributo de particionamento de sinalizador. Qualquer parte do software também é potencialmente uma OPERATING_SYSTEM, independentemente de ser ou não gratuita.

— Joel Brown
fonte

Ligeiramente OT: o que você usou para fazer esse diagrama de ER?

— Daniel Serodio

@DanielSerodio - usei o Visio com formas inteligentes e construí-me com base na notação James Martin ERD. As formas usam uma textura de linha personalizada para fornecer uma aparência informal, o que acho útil para lembrar as pessoas quando um diagrama é um "esboço" ou design de rascunho.

— Joel Brown

@JoelBrown Você gostaria de compartilhar seus estênceis? Estes são realmente agradáveis formas

— imoatama

@imoatama - Já faz um tempo, mas finalmente consegui postar o estêncil aqui: moosewarevisioerd.codeplex.com Observe como na descrição que as formas inteligentes do estêncil foram criadas para uma versão mais antiga do Visio e alguns dos comportamentos do as formas do conector de relacionamento podem ser um pouco confusas. Um dia eu vou resolver isso.

— Joel Brown

Por que o OperatingSystem seria uma entidade completamente nova? Ele deve se enquadrar no software, pois é isso que é. E um sistema operacional (se de código fechado) teria uma data de compra, fornecedor etc. O sistema operacional de código aberto teria uma licença, URL do código-fonte etc.

Eu recomendaria um relacionamento para SoftwareTypealgo assim. É quando você pode / deve especificar se o Software é um sistema operacional, aplicativo ou qualquer outro tipo de software suportado.

— Thomas Stringer
fonte

Eu gostaria que o OperatingSystem fosse uma entidade separada, pois é uma especialização de Software. Pode ter atributos que nenhum outro Software terá (como tipo de kernel, sinalizador RTOS ou não, sinalizador multiusuário, etc.).

— Jl6

@ jl6 Eu ainda imploro para diferir aqui. Todo software (seja um SO ou não) terá atributos específicos. Aqueles podem ser armazenados em outro lugar. Você está minimizando a escalabilidade mantendo o SO separado.

— Thomas Stringer

Se bem entendi, você está recomendando uma entidade de software e uma entidade de SoftwareType. Você está dizendo que Free, NonFree e OperatingSystem são apenas instâncias diferentes do SoftwareType? Tenho certeza de que você está correto, mas onde você armazena os vários atributos dos diferentes tipos?

— Jl6