Estoy creando un diagrama conceptual [sí, sé que he incluido atributos y claves, pero esto es solo para mí para consolidar lo que estoy haciendo mientras estoy aprendiendo], así que trátelo como Conceptual con el enfoque en Relaciones y tablas y no cómo diagramar;)

Mi obstáculo mental es: estoy tratando de determinar la mejor manera de modelar las relaciones de Perfil, Ubicación y Organización.

En primer lugar, REGLAS:

• Uno o más perfiles pueden ser miembros / amigos de una o más organizaciones ; y viceversa.
• Uno o más perfiles pueden ser miembros / amigos de otros perfiles.
• Una o más organizaciones pueden ser miembros / amigos de otras organizaciones.

Amigo y Miembro difieren, en eso, los Amigos son como de solo lectura y los Miembros [según el nivel] tienen acceso completo para modificar las cosas.

Para complicar aún más las cosas, las ubicaciones tienen su propio conjunto de reglas refinables "adicionales", por ejemplo, una organización posee dos ubicaciones , pero dependiendo de las reglas de ubicación, un miembro [ perfil ] de esa organización puede tener acceso completo en una ubicación, pero acceso restringido en el otro. [Lo sentimos: lo más probable es que tengas que abrir la imagen en otra ventana para ver mejor el tamaño.]

Como puede ver, el concepto de Perfiles y Organizaciones es muy similar, así como este concepto aún por modelar de Amigos y Miembros [...] que imagino se manejará de manera muy similar a las tablas intermedias actuales con la configuración Propietario / Administrador / Miembro / Amigo, etc. en el registro]. Por lo tanto, por qué estoy pensando en el siguiente concepto:

Vea la Opción 2 en la imagen de arriba: que eliminaría las Tablas actuales de Organización y Organización_Ubicaciones y sus relaciones, reemplazándola con la Tabla de Organización de Opción 2 como una relación algo recursiva con Perfil .

Supongo que el quid de la cuestión es si estoy teniendo una mentalidad demasiado programática con el polimorfismo en detrimento de la simplicidad y la flexibilidad, confundiéndome por completo en el proceso;)

Gracias por sus pensamientos de antemano, muy apreciado - M :).

Diagrama revisado:

En respuesta a las preguntas de MDCCL:

1. Sí, el Perfil está compuesto por una Persona y tiene el mismo significado, aunque hacia dónde se dirige su justificación, creo que tiene razón: la Organización y la Persona podrían ser subtipos de Perfil ; por lo tanto, un perfil está compuesto por una persona o una organización.
2. Una dirección de correo electrónico por perfil.
3. Si. Como se indicó anteriormente, la organización debe tener al menos una dirección de correo electrónico.
4. Correcto, una dirección fija.
5. Es una posibilidad, pero una rareza, aunque por lo que estoy aprendiendo, uno debería modelarlo para la longevidad futura, etc., y solo para confirmar, una ubicación podría ser propiedad de más de una persona.

6. La ubicación es definitivamente la entidad integral entre la mayoría de los demás. Quizás aclararé lo que se puede hacer sucintamente aquí, luego le dejaré leer mis otras respuestas, que espero correspondan a adiciones beneficiosas a esta pregunta primero [ luego vea mi respuesta al # 6 al final ];) Re: The Role Owner. An **Organization** can be an Owner of zero or more **Locations**. A Person can be an owner of zero of more Locations[por lo tanto, como supusiste anteriormente; En pocas palabras, un perfil puede ser propietario de cero o más ubicaciones / s.

7. Sí, un perfil que es propietario de una ubicación asume todos los permisos de rol [superusuario]; un perfil que es un administrador puede modificar ciertos detalles de la ubicación , pero principalmente ayuda / edita los detalles / datos proporcionados a través de todos los otros perfiles : esto será proporcionado principalmente por 'miembro / s básico' de dichas ubicaciones ; lo que deja a Basic Member , que puede leer solo todos los detalles de ubicación relacionados y proporcionar datos que deben ser examinados por un administrador / propietario . Más allá de esto, cualquier perfil[Organización / Persona] es muy similar a un Miembro básico 'solo lectura', llamémoslo Invitado , pero solo si la Ubicación está establecida como Pública [y no Privada ], aunque no pueden proporcionar información como un Miembro básico puede .

8. Correcto.
9. ¡Tu intuición es asombrosa! Sí, it is foreseen that a single Location could contain one to many LocationTypespara complicar aún más las cosas, se anticipa que esos LocationTypes individuales podrían tener permisos variables para los Perfiles asociados con la Ubicación 'Principal'; de los cuales, los permisos se filtrarían desde la ubicación a LocationType / s [al igual que los permisos de seguridad de la carpeta del sistema operativo]. ¿Noto a través de su diagrama que podría estar refiriéndose a escribir más como una descripción?
10. Si.
11. Ver 12.
12. Correcto, la capacidad de Profile1 [Persona u Organización] de actuar sobre las Ubicaciones propiedad de Profile2 [Persona u Organización] [si son Amigos / Miembros con los permisos correctos] es primordial.
13. Muy razonable - a) de acuerdo. b) de acuerdo. c) Sí, ¿hmm? ... Tal vez debería ser lo mismo que Perfil [persona] a Perfil [persona] = Amigos . Cualquiera sea la descripción, girará en torno a la Ubicación , ya que las Organizaciones actuarán sobre otras Ubicaciones de la Organización ; aunque semánticamente, dudo que cualquier organización quiera parecer subordinada como un 'miembro' de la organización de esa ubicación para poder hacerlo, 'sin importar cuán buena sea la causa'.

[6] Esto todavía es un poco gris para mí, pero aquí va ... Posiblemente en mi detrimento, la similitud entre las relaciones Miembro / Amigo es tan cercana que pensé combinarlas; en retrospectiva con su diagrama e interpretación, parece que puede tener razón para mantenerlos separados [ iba a diferenciar la relación única a través de la propiedad enum: Propietario / Administrador / Miembro / Amigo ]. Su concepto como, por ejemplo: Una ubicación que es propiedad de una organización tendrá un perfil de cero a muchos [Persona u organización] actuará sobre ella, aunque debe haber una clara diferencia entre cómo actúan los perfiles en la ubicación a través de su relación [Miembro o amigo ] denotado a través de Roles.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.

Es genial que se esté tomando el tiempo para comprender, clasificar y modelar los datos con los que está tratando ya que, desde mi experiencia personal, todo esto hace que todo el proceso de desarrollo sea más fácil y muy flexible para futuros cambios. Y estoy bastante seguro de que también ya lo sabe.

Modelo de datos preliminares y reglas comerciales asumidas

Definí una lista de reglas comerciales que asumí después de leer su pregunta y examinar detenidamente sus diagramas, para describir mi comprensión de sus especificaciones. Después de definir dicha lista, obtuve un modelo de datos IDEF1X ^[1] que decidí cargar como documento .PDF en una plataforma externa (Dropbox), ya que debido a su formato, este modelo de datos no encaja bien en una imagen incrustada. Estos dos instrumentos serán útiles como referencias para algunos puntos importantes que enumero a continuación en la sección titulada Aspectos a resolver para seguir avanzando .

Primero, aquí está el ...

• Modelo de datos preliminares de organizaciones y perfiles .

Como es solo eso, preliminar, considérelo como un medio para ayudarnos a lograr el modelo de datos final deseado.

Reglas comerciales asumidas

Dicho modelo de datos preliminares se derivó de una colección de reglas comerciales (inferidas de su pregunta) que enumeraré de la siguiente manera:

Organizaciones y perfiles

Tenga en cuenta que Profileactualmente se entiende como sinónimo de Person.

• An Organizationes amigo de uno a muchos Profiles .
• An Organizationes amigo de uno a muchos Organizations .
• An Organizationes miembro de uno a muchos Organizations .
• A Profilees miembro de uno a muchosOrganizations .
• A Profilees amigo de uno a muchos Profiles .
• A Profilees miembro de uno a muchos Profiles .

Ubicaciones y direcciones

• Un Organizationposee uno a muchos Locations .
• A Locationse clasifica por uno a muchos LocationTypes ( solo uno en un momento dado).
• A Locationpuede tener uno-a-muchos Addresses ( uno Physical , uno para Shipping, uno para Billing, o uno que sirve a todos dichos efectos, o uno que combina dos propósitos y otra que sirve solamente uno de ellos).

• Un Addresspuede ser mantenido por uno a muchos Profiles o, dicho de otra manera, un Profilemantiene uno a muchos Addresses .

• A específica Addresspuede ser utilizado por uno-a-muchos Profiles (que sirve como Physicalpara uno Profile , siendo utilizado para Billingpor una diferente , etc.). Entonces, un Addressfunciona de manera similar para Locationsy Profiles.

  • Así, un individuo Addresspuede ser, al mismo tiempo , de tipo Physical, Shipping y Billing .

Ubicaciones y roles

• A Locationabre uno a muchos Roles .
• A Rolepuede llevarse a cabo en uno a muchos Locations .
• A Profile(una vez que se ha establecido como Memberde una Organization) se puede llevar a cabo uno-a-muchos Roles , en uno-a-muchos Locations (pero sólo una específica Roleen cada uno Locationen un punto particular en el tiempo, es decir, nunca se dos o más Roles al mismo tiempo )

Aspectos a resolver para seguir avanzando

Para seguir avanzando en la resolución de su modelo de datos, aquí hay una lista de puntos relevantes que, una vez que los resolvamos, nos ayudarán a alcanzar este objetivo:

1. Supuse que el término Profileen su contexto tiene un significado similar (o el mismo) que el de Person, pero podría ser un poco diferente. De esta manera, ¿diría que, en su escenario, las entidades Organizationy los Personsubtipos son Profile?

2. ¿Puede un Profile(o Person) ser propietario de uno a muchos EmailAddresses , o un Profile(o Person) está fijado exactamente a uno EmailAddress ?

3. ¿Le gustaría brindar la posibilidad de Organizationque se contacte a través de Telephoney Email, o desea restringirlo para que solo sea posible para un Profile(o Person)?

4. Supongo que a Locationse fija exactamente a uno Address del tipo Physical, ¿es esto correcto?

5. ¿Es posible que uno Locationsea ​​compartido por uno a muchos diferentes Organizations o , de lo contrario, solo Locationpuede ser propiedad de uno Organization ?

6. Usted ha declarado a través de comentarios que el hecho de ser Memberay Friendes lo mismo. Como puede ver en mi modelo de datos preliminares propuesto, le seguí las especificaciones originales y describí todas las combinaciones posibles de membresía y amistad entre Organizationy Profile(o Person) en diferentes entidades, ya que creo que puede ser útil en el esfuerzo de definir lo mejor posible estructura para esa parte de su escenario. En este sentido:

   • Supongo que la declaración an Organization is a Member of another Organizationtiene diferentes efectos que la declaración sobre a Profile (or Person) is a Member of an Organizationla entidad llamada Location.
   • Como puede ver en el modelo de datos, creo que el Rolede Ownersolo es válido para un Organizationy, para mí, el válido Rolespara un Profile(o Person), dentro de un Locationare Adminy Member. Que piensas sobre todo esto? Dado que está en contacto directo con las reglas comerciales que se aplican a su situación, debe decirme si mis suposiciones son correctas.

7. ¿Puede un Profile(o Person) jugar diferente Rolesdentro del mismo Location? es decir, ¿puede un Personser, al mismo tiempo, el Adminy también un Memberde lo mismo Location? ¿Cuáles son las reglas al respecto?

8. Creo que lo mismo Profile(o Person) puede jugar diferente Rolesen diferente Locations. Por ejemplo: Un Profile(o Person) específico es el "Administrador" en Location"1", y este mismo Profile(o Person) es un " Member" en Location"2", al mismo tiempo. Estoy en lo cierto?

9. ¿Es posible que un particular Locationtenga diferentes LocationTypesal mismo tiempo, o es un individuo Locationfijo para mantener exactamente uno LocationType?

10. ¿El atributo Organization.Websiterepresenta la dirección del sitio web de una organización en particular, como “dba.stackexchange.com”?

11. Si Profile"1" (entendido como Person) es un Member(o Friend) de Profile"2", ¿es posible que Profile"1" lleve a cabo Roleuna Locationpropiedad de Profile"2"? Considero que tales escenarios solo son válidos para las relaciones entre an Organizationy a Member Person, entonces, ¿qué opinas?

12. De manera similar, si Organization"1" es un Member(o Friend) de Organization"2", ¿es posible que Organization"1" lleve a cabo Roleuna Locationpropiedad de Organization"2"? Nuevamente, creo que este tipo de escenarios solo son válidos para las relaciones entre an Organizationy a Member Person, ¿es esto correcto?

13. En este sentido, mientras escribo estas preguntas, creo que sería razonable decir que solo hay tres tipos diferentes de relaciones que involucran Organizationsy Persons, y podemos definir:

    • (a) La relación entre an Organizationy a Personcomo " Membership".
    • (b) La relación entre ay Personotro diferente Personcomo " Friendhip".
    • (c) Todavía tenemos que encontrar un nombre significativo para describir la relación entre un individuo Organizationy otro diferente Organization.
    • Entonces, hágame saber lo que piensa sobre (a), (b) y (c).

14. ¿Es posible que un Organizationsea ​​un Friend(o un Member) de uno a muchos diferentes Organizationsal mismo tiempo? O solo es posible que una persona Organizationtenga solo una relación exclusiva con otraOrganization?

Modelo de datos sucesivo que representa el primer avance

En atención a sus respuestas y resoluciones a los aspectos pendientes que he enumerado anteriormente, he creado lo siguiente ...

• Modelo de datos preliminares de organizaciones y perfiles: primer avance .

Aunque todavía no me siento del todo cómodo, este nuevo modelo de datos expresa las siguientes reglas de negocio:

• A Profilees o bien una Organization o un Person. ^[2]
• A Profilepuede ser el amigo que ofrece uno a muchos FriendProfiles , y un Profilepuede ser el amigo que acepta uno a muchos FriendProfiles . ^[3]
• A Locationpuede consistir en uno a muchos Locations . ^[4]

Respuestas a sus comentarios específicos posteriores

Es realmente interesante para mí notar / agravar la separación de las preocupaciones [por ejemplo, LocationAddress y ProfileAddress], porque obviamente quería apresurarme y mantenerlas sin las relaciones correctas [curiosamente, no me sentí bien con mi ERD original].

Sí, esa es una buena comparación, aunque no lo llamaría separación de preocupaciones (que es, sin duda, un principio fundamental en la programación y diseño de aplicaciones), ya que este término comúnmente se refiere a la etapa de desarrollo de aplicaciones y actualmente nos encontramos en el etapa de entender los datos y diseñar su estructura lógica.

Desde mi experiencia personal, considero que esta fase tiene que ver con poner las cosas significativas en todo su contexto, tiene que ver con ver las asociaciones que existen entre las diferentes entidades que son relevantes en el escenario particular de interés, y luego representando estas cosas en un modelo de datos. En el caso específico sobre el que está comentando, la Addressentidad puede tener diferentes tipos de conexiones con otras entidades, una con Profiley otra diferente con Location.

Y sí, cuando algo no se siente bien o natural , bien puede ser una señal de que uno debe esforzarse más para comprender los datos pertinentes. De esta manera, la Addressentidad es una de las cosas que considero que necesita más atención, ya que creo que la relación entre a Profiley an Address podría manejarse por medio de la Locationentidad (debido al hecho de que cada uno Locationdebe tener al menos un físico Address), por lo tanto, podríamos descartar la ProfileAddressentidad asociativa representada en el último modelo, pero debe continuar analizando estos puntos y hacerme saber sus ideas.

Además, ¿es una práctica común en IDEF1X cambiar las denominaciones PK / FK en las entidades para una mejor legibilidad [por ejemplo, ProfileId - LocationOwnerProfileId]?

Sí, esa es una observación muy inteligente de su parte, ya que IDEF1X recomienda el uso de nombres de roles para denominar CLAVES EXTRANJERAS, a fin de capturar el significado de dichos atributos de acuerdo con la entidad en la que se está utilizando. También vale la pena señalar que esto también está fuertemente relacionado con el concepto de migración de claves primarias . De hecho, el uso de nombres de roles precede a IDEF1X, ya que fue presentado originalmente por el Dr. EF Codd en su texto seminal de 1970. De esta manera, se puede ver claramente la fidelidad que el estándar IDEF1X mantiene hacia el modelo relacional .

Me intrigaría saber qué no le gusta particularmente / siente que no modela, con / en la solución.

Además de los detalles ya descritos anteriormente sobre la Addressentidad, no estoy seguro de si los Rolesrealizados por un determinado Profileen un particular Locationson equivalentes para un Organizationo un Person. Desde mi punto de vista, un Personprimero debe asociarse con un Organization, y luego esto Organizationnombraría a dicho Personpara realizar un Roleen particular Location, pero usted conoce mejor el escenario, por lo que estas reglas pueden ser innecesarias. En este sentido, voy a insistir sobre el hecho de que sería muy útil para mí saber la descripción contextual o significado de que los futuros usuarios de esta estructura de datos para dar Organization, ProfileyLocation, pero entiendo que esto puede considerarse información confidencial, por lo que sería una limitación.

Con la estructura actual, parece que todos ( Organizationo Person) pueden estar relacionados con cualquier persona (de nuevo, Organizationo Person) y pueden / hacer cualquier cosa ( Role) en cualquier lugar ( Location) pero, perharps, esto es exactamente lo que usted y los usuarios esperan de esta base de datos , para lo cual proporcionará restricciones bien definidas, por supuesto. Si este es el caso, casi estamos proporcionando una solución final. Dado que, naturalmente, su opinión es decisiva en esta situación, también debe analizar estas ideas y luego informarme sus conclusiones para que podamos dar los pasos finales.

Segundo avance factible

Desafortunadamente, la comunicación se detuvo hace unas semanas, supongo que debido a los compromisos laborales que debe cumplir, lo cual es completamente razonable. Hubiera estado mucho más contento si hubiéramos desarrollado un modelo más estable y robusto, pero, debido a nuestras interacciones anteriores, puedo suponer que he podido orientarlo en la dirección correcta.

Además de lo que ya se ha presentado en este proceso de preguntas y respuestas, considero que proporcionar una nueva progresión de los modelos de datos anteriores puede ser útil para otros buscadores con un problema similar. Entonces, he creado el ...

Modelo de datos preliminares de organizaciones y perfiles: segundo avance

Como se puede ver en dicho modelo de datos, he eliminado la relación de muchos a muchos que he representado en los modelos anteriores entre Profiley Address, dado que un hecho Profileya está relacionado con uno a muchos a Addresses través de su propiedad Locations.

Otro cambio que se ilustra en este nuevo avance es el hecho de que ahora incluye la posibilidad de que un dado Locationpueda ser propiedad de uno a muchos Profiles . En consecuencia, he cambiado la LocationCLAVE PRIMARIA (descartando el LocationOwnerProfileIdatributo) y luego agregué una entidad asociativa ( muchas a muchas ) que se relaciona Profilecon Location.

Notas

_{1. IDEF1X es una técnica de modelado de datos altamente recomendable que fue definida como un estándar en diciembre de 1993 por el Instituto Nacional de Estándares y Tecnología ( NIST ) de EE. UU .}

_{2. Esta es una ocurrencia de un (super) grupo de subtipo de tipo . En caso de que le interese, aquí hay una respuesta en la que trato de manera más detallada este tipo de relaciones.}

_{3. Un ejemplo de una relación jerárquica de muchos a muchos , y es muy similar a la estructura que dio una solución definitiva al "Problema de Explotación de Partes" . Tal solución fue, por supuesto, presentada por el Dr. Edgar Frank Codd en su artículo de 1970, enormemente influyente, "Un modelo relacional de datos para grandes bancos de datos compartidos" .}

_{4. Como tal, esta es una instancia de una relación jerárquica de uno a muchos (o de muchos a uno) .}

Creo que está tratando de combinar conceptos del modelado de objetos y conceptos del modelado de datos de una manera que no lo ayude a aclarar su propia comprensión del problema. Espero poder despejar el desorden un poco sin divagar demasiado.

El modelo relacional, como tal, no admite la herencia, no importa el polimorfismo. Esto significa que se debe usar un patrón de diseño bastante especializado al modelar una situación de la vida real que se maneja fácilmente por herencia y polimorfismo en un modelo de objetos. Más sobre ese patrón de diseño especial más adelante.

Cuando se desarrolló por primera vez el modelo ER, se suponía que era una alternativa agnóstica de implementación al modelo relacional. Al principio, tampoco tenía nada como herencia. Pero en algún momento en los años ochenta o noventa, el modelo se amplió para proporcionar algunas de las mismas capacidades expresivas que se obtienen con la herencia. Esto se conocía como el "modelo ER extendido", pero a todos los efectos prácticos, el modelo ER de hoy incluye características EER.

Una característica de EER se conoce con el nombre de "generalización / especialización". Puede buscar y leer sobre este concepto en la web. Gen-spec proporciona la misma capacidad expresiva que las clases y subclases proporcionan en un modelo de objetos. Sin embargo, Gen-spec no trata los problemas relacionados con el diseño de tablas relacionales para una situación gen-spec. Más sobre eso más tarde.

En el modelado ER, una relación siempre involucra las mismas entidades. Por lo tanto, la relación de amistad entre una organización y un perfil no es lo mismo que la relación de amistad entre un perfil y otro perfil. Las dos relaciones necesitan nombres diferentes. Simplemente te atarás en nudos si no sigues esta regla.

O eso, o necesita encontrar una entidad generalizada de las cuales las Organizaciones, Perfiles y posiblemente Ubicaciones sean todas especializaciones. No entiendo su caso lo suficientemente bien como para ayudarlo con eso.

Continuando, noto que está combinando su modelo relacional y su modelo ER juntos en un solo modelo. Los arquitectos de bases de datos más experimentados hacen esto. Pero le aconsejo que mantenga los dos modelos separados (aunque reconciliados entre sí) hasta que haya adquirido competencia.

Finalmente, ¿cómo se diseñan tablas relacionales que representan una situación gen-spec? Intente buscar estos dos patrones de diseño "Herencia de tabla de clase" y "Herencia de tabla única". Hay dos etiquetas para estas en Stackoverflow. También hay algunas presentaciones bastante buenas de los patrones en la web. Me gusta especialmente el tratamiento de Martin Fowler. Parece saber cómo piensan los modeladores de objetos. Espero que esto ayude.