¿Cómo debo modelar una relación de "uno u otro"?

12

Digamos que tengo una entidad llamada Software y dos subtipos FreeSoftware y NonFreeSoftware. La entidad NonFreeSoftware tiene atributos como fecha de compra, proveedor, etc. La entidad FreeSoftware tiene atributos como licencia, url de código fuente, etc.

Entonces, si quiero modelar otra entidad, OperatingSystem, ¿cómo debo hacerlo? Existe una relación de "es una" con el Software, pero una relación de "uno u otro" con FreeSoftware y NonFreeSoftware.

Creo que me falta algo en la forma en que estoy analizando esta jerarquía.

jl6
fuente
Revisa esta respuesta . Cubre los detalles de implementación de modelar este tipo de relación.
Nick Chammas

Respuestas:

8

La forma de gestionar esto es que sus subtipos deben estar determinados por el supertipo (es decir, la PK del subtipo también es un FK del subtipo al supertipo).

El desafío es comprender si algo es verdaderamente mutuamente excluyente o no. Los atributos de los subtipos deberían aplicarse solo a esos subtipos, pero puede ser que algunos subtipos sean mutuamente excluyentes y otros no.

Si tiene algunos subtipos mutuamente excluyentes, puede usar un atributo de partición en el supertipo para indicar cuál de los (dos o más) subtipos mutuamente excluyentes se aplica. Este atributo de partición se puede usar con restricciones o disparadores para imponer la exclusividad mutua.

Si tiene subtipos que no son mutuamente excluyentes, pueden existir sin utilizar ningún atributo de partición.

Considere este modelo de datos:

ERD

Tiene tres supertipos, pero los tipos FREE_SOFTWAREy NON-FREE_SOFTWAREson mutuamente excluyentes, según el SOFTWARE.free_not_freeatributo de partición de marca. Cualquier pieza de software también es potencialmente una OPERATING_SYSTEM, independientemente de si es gratuita o no.

Joel Brown
fuente
1
Ligeramente OT: ¿qué usaste para hacer este diagrama ER?
Daniel Serodio
@DanielSerodio: utilicé Visio con formas inteligentes que construí yo mismo en base a la notación ERD James Martin. Las formas usan una textura de línea personalizada para darles una apariencia informal, lo que me parece útil para recordarle a la gente cuando un diagrama es un "boceto" o diseño de borrador.
Joel Brown
@JoelBrown ¿Estaría dispuesto a compartir sus plantillas? Estas son formas realmente bonitas
imoatama
2
@imoatama: ha pasado un tiempo, pero finalmente pude publicar la plantilla aquí: moosewarevisioerd.codeplex.com Tenga en cuenta, como en la descripción, que las formas inteligentes de la plantilla se construyeron para una versión anterior de Visio y algunos de los comportamientos de la las formas de conector de relación pueden ser un poco flaky. Algún día llegaré a arreglar esto.
Joel Brown
1

¿Por qué OperatingSystem sería una entidad completamente nueva? Debería estar dentro del Software, ya que eso es lo que es. Y un sistema operativo (si es de código cerrado) tendría una fecha de compra, proveedor, etc. Y el sistema operativo de código abierto tendría una licencia, URL de código fuente, etc.

Recomendaría una relación con SoftwareTypealgo o algo por el estilo. Ahí es cuando podría / debería especificar si el Software es un SO, una aplicación o cualquier otro tipo de software que admita.

Thomas Stringer
fuente
Me gustaría que OperatingSystem fuera una entidad separada, ya que es una especialización de Software. Puede tener atributos que ningún otro Software tendrá (como el tipo de núcleo, el indicador RTOS o no, el indicador multiusuario, etc.).
jl6
1
@ jl6 Todavía ruego diferir aquí. Cada pieza de software (ya sea un sistema operativo o no) tendrá atributos específicos. Esos se pueden almacenar en otro lugar. Está minimizando la escalabilidad al mantener el sistema operativo separado.
Thomas Stringer
Si entiendo correctamente, está recomendando una entidad de Software y una entidad de SoftwareType. ¿Está diciendo que Free, NonFree y OperatingSystem son solo instancias diferentes de SoftwareType? Estoy seguro de que tienes razón, pero ¿dónde guardas los diversos atributos de los diferentes tipos?
jl6