Estou criando um diagrama conceitual [sim, eu sei que incluí atributos e chaves - mas é apenas para consolidar o que estou fazendo enquanto aprendo] - então, por favor, trate-o como conceitual, com foco em Relacionamentos e tabelas e não como diagrama;)

Minha dificuldade é: estou tentando descobrir a melhor maneira de modelar os relacionamentos de Perfil, Local e Organização.

Primeiro de tudo, REGRAS:

• Um ou mais perfis podem ser membros / amigos de uma ou mais organizações ; e vice versa.
• Um ou mais perfis podem ser membros / amigos de outros perfis.
• Uma ou mais organizações podem ser membros / amigos de outras organizações.

Amigo e Membro diferem, pois os Amigos são como somente leitura e os Membros [dependendo do nível] têm acesso total para alterar as coisas.

Para complicar ainda mais as coisas, os Locais têm seu próprio conjunto de regras refináveis ​​"adicionais". Por exemplo, uma Organização possui dois Locais , mas, dependendo das regras de Localização, um Membro [ Perfil ] dessa Organização pode ter acesso total em um Local, mas acesso restrito ao Local. de outros. [Desculpe: você provavelmente precisará abrir a imagem em outra janela para obter um melhor tamanho de visualização.]

Então, como você pode ver, o conceito de Perfis e Organizações é o mesmo, assim como o conceito ainda não modelado de Amigos e Membros [...] que eu imagino que será tratado da mesma forma que as tabelas intermediárias atuais, com a configuração Proprietário / Admin / Membro / Amigo etc. no registro]. Por isso, por que estou pensando no seguinte conceito:

Consulte a Opção 2 na imagem acima: que removeria as tabelas Organização e Organização_Locations atuais e seus relacionamentos, substituindo-a pela Tabela Organização da Opção 2 como um relacionamento um tanto recursivo com o Perfil .

Suponho que o cerne da questão é se eu estou sendo muito programado com o polimorfismo em detrimento da simplicidade e flexibilidade, confundindo-me inteiramente no processo;)

Obrigado por seus pensamentos antecipadamente, muito apreciado - M :).

Diagrama revisado:

Em resposta às perguntas da MDCCL:

1. Sim, o perfil é constituído por uma pessoa e tem o mesmo significado - embora a sua lógica seja direcionada - acredito que você esteja correto: organização e pessoa podem ser subtipos de perfil ; portanto, um perfil é composto de uma pessoa ou uma organização.
2. Um endereço de email por perfil.
3. Sim. Como acima, a organização deve ter pelo menos um endereço de email.
4. Correto, um endereço fixo.
5. É uma possibilidade, mas uma raridade - embora, pelo que estou aprendendo -, devamos, portanto, modelá-lo para longevidade futura etc., e apenas para confirmar, um Local pode ser possuído por mais de uma Pessoa.

6. A localização é definitivamente a entidade integral entre a maioria dos outros. Talvez eu esclareça o que pode ser feito de forma sucinta aqui, e deixe que você leia minhas outras respostas que, esperamos, pertencem a adições benéficas a essa pergunta primeiro [ depois veja minha resposta ao nº 6 no final ];) Re: O Dono da Função. An **Organization** can be an Owner of zero or more **Locations**. A Person can be an owner of zero of more Locations[portanto, como você supôs anteriormente; Simplificando, um perfil pode ser o proprietário de zero ou mais locais.

7. Sim, um perfil que é proprietário de um local assume todas as permissões de função [superusuário]; um perfil que seja um administrador pode alterar determinados detalhes do local , mas principalmente ajuda / edita os detalhes / dados fornecidos por todos os outros perfis - este será fornecido principalmente pelo (s) membro (s) básico (s) dos locais ; que deixa o Membro básico , que pode ler somente todos os detalhes do local relacionados e fornecer dados que devem ser examinados por um administrador / proprietário . Além disso, qualquer perfil[Organização / Pessoa] é muito parecido com um Membro Básico 'somente leitura' - vamos chamá-lo de Convidado - mas apenas se o Local estiver definido como Público [e não Privado ], embora eles não possam fornecer informações como um Membro Básico pode .

8. Corrigir.
9. Sua intuição é incrível! Sim, it is foreseen that a single Location could contain one to many LocationTypes- para complicar ainda mais as coisas - prevê-se que esses LocationTypes individuais possam ter permissões variáveis ​​para perfis associados ao local 'pai'; dos quais, as permissões seriam filtradas do Local para o LocationType / s [muito parecido com as permissões de segurança da pasta do SO]. Observo através do seu diagrama que você pode estar se referindo ao tipo mais como uma descrição?
10. Sim.
11. Veja 12.
12. Correto, a capacidade do Perfil1 [Pessoa ou Organização] para atuar nos Locais pertencentes ao Perfil2 [Pessoa ou Organização] [se forem Amigos / Membros com permissões corretas] é fundamental.
13. Muito razoável - a) concordo. b) concordo. c) Sim, hmm? ... Talvez seja o mesmo que Perfil [pessoa] para Perfil [pessoa] = Amigos . Qualquer que seja a descrição, ela giraria em torno da Localização , pois a Organização atuaria sobre outras Localização da Organização ; embora semanticamente, duvido que qualquer organização queira parecer subserviente como um "membro" da organização desse local para poder fazê-lo, "não importa quão boa seja a causa".

[6] Isso ainda é um pouco cinza para mim, mas aqui vai ... Para meu possível prejuízo, a semelhança entre as relações Membro / Amigo é tão próxima que pensei em combiná-las; Em retrospecto, com seu diagrama e interpretação, parece que você pode estar certo em mantê-los separados [ eu diferenciaria o relacionamento único por meio da propriedade enum: Proprietário / Administrador / Membro / Amigo ]. Seu conceito como, por exemplo: Um local que é propriedade de uma organização terá de zero a muitos perfis [pessoa ou organização], mas deve haver uma clara diferença entre como os perfis atuam no local por meio de sua relação [membro ou amigo ] denotado por meio de funções.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.

É ótimo que você dedique algum tempo para entender, classificar e modelar os dados com os quais está lidando, pois, a partir de minha experiência pessoal, tudo isso torna todo o processo de desenvolvimento mais fácil e flexível para futuras mudanças. E tenho certeza de que você também já está ciente disso.

Modelo de dados preliminar e regras de negócios assumidas

Definei uma lista de regras de negócios que assumi após ler sua pergunta e examinar atentamente seus diagramas, a fim de descrever minha compreensão de suas especificações. Depois de definir essa lista, derivei um modelo de dados IDEF1X ^[1] que decidi enviar como documento .PDF em uma plataforma externa (Dropbox), pois, devido ao seu formato, esse modelo de dados não se encaixa bem em uma imagem incorporada. Esses dois instrumentos serão úteis como referência para alguns pontos importantes que enumero abaixo na seção intitulada Aspectos a serem resolvidos, a fim de seguir adiante .

Primeiro, aqui está o…

• Modelo Preliminar de Dados para Organizações e Perfis .

Como é apenas isso, preliminar, considere-o como um meio para nos ajudar a alcançar o modelo de dados final desejado.

Regras de negócios assumidas

O referido modelo de dados preliminar foi derivado de uma coleção de regras de negócios (inferidas da sua pergunta) que enumerarei da seguinte maneira:

Organizações e perfis

Observe que Profileatualmente é entendido como sinônimo Person.

• An Organizationé amigo de um para muitos Profiles .
• An Organizationé amigo de um para muitos Organizations .
• An Organizationé membro de um para muitos Organizations .
• A Profileé um membro de um para muitosOrganizations .
• A Profileé amigo de um para muitos Profiles .
• A Profileé um membro de um para muitos Profiles .

Locais e endereços

• Um Organizationé dono de um para muitos Locations .
• A Locationé classificado por um para muitos LocationTypes ( apenas um em um determinado momento).
• Um Locationpode ter um-para-muitos Addresses ( um Physical , um para Shipping, um para Billing, ou um que serve a propósitos todos disseram, ou um que combina dois propósitos e outra que serve apenas um deles).

• Um Addresspode ser mantido por um para muitos Profiles ou, em outras palavras, um Profilemantém um para muitos Addresses .

• Um específico Addresspode ser utilizado por um-para-muitos Profiles (servindo como Physicalpara um Profile , a ser utilizado para Billingpor um diferente , etc.). Então, um Addressfunciona de maneira semelhante para Locationse Profiles.

  • Assim, um indivíduo Addresspode ser, ao mesmo tempo , de tipo Physical, Shipping e Billing .

Locais e funções

• A Locationabre um para muitos Roles .
• A Rolepode ser realizado em um para muitos Locations .
• A Profile(uma vez definido como Memberum Organization) pode executar um para muitos Roles , em um para muitos Locations (mas apenas um específico Roleem cada Locationum em um momento específico, ou seja, nunca dois ou mais Roles ao mesmo tempo) )

Aspectos a serem resolvidos para seguir em frente

Para continuar avançando na resolução do seu modelo de dados, aqui está uma lista de pontos relevantes que, uma vez elaborados, ajudarão a alcançar esse objetivo:

1. Supus que o termo Profileem seu contexto tenha um significado semelhante (ou o mesmo) ao de Person, mas poderia ser um pouco diferente. Dessa forma, você diria que, no seu cenário, as entidades Organizatione Personsão subtipos de Profile?

2. Pode um Profile(ou Person) possuir um para muitos EmailAddresses , ou é Profile(ou Person) fixo para exatamente um EmailAddress ?

3. Deseja fornecer a possibilidade de um Organizationcontato ser contatado por meio de Telephonee Email, ou você deseja restringir isso para apenas Profile(ou Person)?

4. Eu suponho que a Locationseja fixo exatamente para umAddress do tipo Physical, isso está correto?

5. É possível que um Locationseja compartilhado por um para muitos diferentes Organizations ou , caso contrário, um Locationpossa pertencer a apenas um Organization ?

6. Você declarou por meio de comentários que o fato de ser a Membere a Friendé o mesmo. Como você pode ver no meu modelo de dados preliminares proposto, eu segui suas especificações originais e descrevi todas as combinações possíveis de associação e amizade entre Organizatione Profile(ou Person) em diferentes entidades, pois acho que isso pode ser útil no esforço de definir o melhor possível estrutura para essa parte do seu cenário. Neste sentido:

   • Suponho que a declaração an Organization is a Member of another Organizationtenha efeitos diferentes dos da declaração a Profile (or Person) is a Member of an Organizationchamada entidade Location.
   • Como você pode ver no modelo de dados, acho que o Rolede Owneré válido apenas para um Organizatione, para mim, o válido Rolespara um Profile(ou Person), dentro de um Locationare Admine Member. O que você acha disso tudo? Como você está em contato direto com as regras de negócios que se aplicam à sua situação, é necessário me informar se minhas suposições estão corretas.

7. Pode um Profile(ou Person) jogar diferente Rolesdentro do mesmo Location? ou seja, pode Personser, ao mesmo tempo, o Admine também um Memberdo mesmo Location? Quais são as regras nesse sentido?

8. Eu acho que o mesmo Profile(ou Person) pode jogar diferente Rolesem diferente Locations. Por exemplo: Um específico Profile(ou Person) é o "Admin" em Location"1" e o mesmo Profile(ou Person) é um " Member" em Location"2", ao mesmo tempo. Estou certo?

9. É possível que um particular Locationtenha diferentes LocationTypesao mesmo tempo, ou um indivíduo está Locationfixo para manter exatamente um LocationType?

10. O atributo Organization.Websiterepresenta o endereço do site de uma organização específica, como "dba.stackexchange.com"?

11. Se Profile"1" (entendido como Person) é um Member(ou Friend) de Profile"2", é possível que Profile"1" execute um Roleem uma Locationpropriedade de Profile"2"? Considero que esses cenários são válidos apenas para os relacionamentos entre um Organizatione um Member Personentão, o que você acha?

12. De maneira semelhante, se Organization"1" é um Member(ou Friend) de Organization"2", é possível para Organization"1" executar um Roleem uma Locationpropriedade de Organization"2"? Mais uma vez, acho que esse tipo de cenário é válido apenas para os relacionamentos entre an Organizatione a Member Person, isso está correto?

13. Nesse sentido, enquanto escrevo essas perguntas, acho que seria razoável dizer que existem apenas três tipos diferentes de relacionamentos envolvendo Organizationse Persons, e podemos definir:

    • (a) A relação entre an Organizatione a Personcomo “ Membership”.
    • (b) A relação entre um Persone outro diferente Personcomo “ Friendhip”.
    • (c) Ainda precisamos encontrar um nome significativo para descrever o relacionamento entre um indivíduo Organizatione outro diferente Organization.
    • Então, deixe-me saber o que você pensa sobre (a), (b) e (c).

14. É possível para um Organizationser um Friend(ou uma Member) de um-para-muitos diferentes Organizationsao mesmo tempo? Ou só é possível para um Organizationter apenas um relacionamento com exclusivamente um diferenteOrganization?

Modelo de dados sucessivo representando o primeiro avanço

Em atenção às suas respostas e resoluções aos aspectos pendentes listados acima, criei o seguinte…

• Modelo Preliminar de Dados para Organizações e Perfis - Primeiro Avanço .

Embora ainda não me sinta à vontade com ele, este novo modelo de dados expressa as seguintes regras de negócios:

• Um Profileé qualquer um Organization ou uma Person. ^[2]
• A Profilepode ser o amigo que oferece de um para muitos FriendProfiles e a Profilepode ser o amigo que aceita de um para muitos FriendProfiles . ^[3]
• A Locationpode consistir em um para muitos Locations . ^[4]

Respostas aos seus comentários específicos subsequentes

É realmente interessante observar / agravar a separação de preocupações [por exemplo, LocationAddress e ProfileAddress] - porque eu obviamente queria me apressar e manter todas elas sem as relações corretas [engraçado, engraçado, não parecia certo com o meu ERD original].

Sim, essa é uma boa comparação, embora eu não a chamasse de separação de preocupações (que é, certamente, um princípio fundamental na programação e design de aplicativos), uma vez que esse termo geralmente pertence ao estágio de desenvolvimento de aplicativos e atualmente nos encontramos no estágio de compreensão dos dados e design de sua estrutura lógica.

Pela minha experiência pessoal, considero que esta fase tem a ver com colocar as coisas significativas em todo o seu contexto, tem a ver com as associações existentes entre as diferentes entidades que são relevantes no cenário de interesse específico e, em seguida, descrevendo essas coisas em um modelo de dados. No caso específico sobre o qual você está comentando, a Addressentidade pode ter diferentes tipos de conexões com outras entidades, uma com Profilee outra com Location.

E, sim, quando algo não parece certo ou natural , pode ser um sinal de que é preciso fazer mais esforço para entender os dados pertinentes. Dessa forma, a Addressentidade é uma das coisas que considero que precisam de mais atenção, pois acho que o relacionamento entre a Profilee a Address poderia ser tratado por meio da Locationentidade (devido ao fato de que todos Locationdevem ter pelo menos um físico Address), portanto, poderíamos descartar a ProfileAddressentidade associativa descrita no modelo mais recente, mas você deve continuar analisando esses pontos e me informar suas idéias.

Além disso, é prática comum no IDEF1X alterar negações de PK / FK em entidades para melhor legibilidade [por exemplo, ProfileId - LocationOwnerProfileId]?

Sim, esse é um comentário muito inteligente, pois o IDEF1X recomenda o uso de nomes de funções para denominar ESTRANGEIRAS, a fim de capturar o significado de tais atributos de acordo com a entidade em que está sendo usado. Também é importante notar que isso também está fortemente relacionado ao conceito de migração de chaves primárias . De fato, o uso de nomes de funções precede o IDEF1X, pois foi originalmente apresentado pelo Dr. EF Codd em seu texto seminal de 1970. Dessa maneira, pode-se ver claramente a fidelidade que o padrão IDEF1X mantém em relação ao modelo relacional .

Eu ficaria intrigado em aprender o que você não gosta particularmente / sente que não modela, com / na solução?

Além dos detalhes já descritos acima sobre a Addressentidade, não tenho certeza se os Rolesrealizados por um dado Profileem particular Locationsão equivalentes a um Organizationou a um Person. Na minha perspectiva, um Personprimeiro precisa estar associado a um Organizatione, em seguida, isso Organizationindicaria Personexecutar um Roleem um particular Location, mas você conhece melhor o cenário, portanto essas regras podem ser desnecessárias. A este respeito, vou insistir sobre o fato de que seria muito útil para mim saber a descrição contextual ou significado que os futuros utilizadores desta estrutura de dados dar a Organization, Profilee,Location, mas entendo que isso pode ser considerado uma informação confidencial, portanto, isso seria uma limitação.

Com a estrutura atual, parece que todo mundo ( Organizationou Person) pode estar relacionado a qualquer pessoa (de novo Organizationou Person) e pode ser / fazer qualquer coisa ( Role) em qualquer lugar ( Location), mas, talvez, isso é exatamente o que você e os usuários estão esperando deste banco de dados , para o qual você fornecerá restrições bem definidas, é claro. Se for esse o caso, estamos quase fornecendo uma solução final. Como, naturalmente, sua opinião é decisiva nessa situação, você também deve analisar essas idéias e me informar suas conclusões para que possamos dar os passos finais.

Segundo avanço viável

Infelizmente, a comunicação parou há algumas semanas, acho que por causa dos compromissos de trabalho que você deve cumprir, o que é completamente razoável. Eu teria ficado muito mais satisfeito se tivéssemos desenvolvido um modelo mais estável e robusto, mas, devido às nossas interações anteriores, posso assumir que fui capaz de apontá-lo na direção certa.

Além do que já foi apresentado neste processo de perguntas e respostas, considero que fornecer uma nova progressão a partir dos modelos de dados anteriores pode ser útil para outros buscadores com um problema semelhante. Então, eu criei o…

Modelo Preliminar de Dados para Organizações e Perfis - Segundo Avanço

Como pode ser visto em tal modelo de dados, removi o relacionamento muitos-para-muitos que descrevi nos modelos anteriores entre Profilee Address, uma vez que um dado Profilejá está relacionado a um-para-muitos Addresses por meio de sua propriedade Locations.

Outra mudança ilustrada neste novo avanço é o fato de agora incluir a possibilidade de que um dado Locationpossa pertencer a um para muitos Profiles . Conseqüentemente, alterei a LocationPRIMARY KEY (descartando o LocationOwnerProfileIdatributo) e, em seguida, adicionei uma entidade associativa ( muitos para muitos ) relacionada Profilea ele Location.

Notas

_{1. IDEF1X é uma técnica de modelagem de dados altamente recomendável que foi definida como padrão em dezembro de 1993 pelo Instituto Nacional de Padrões e Tecnologia dos EUA ( NIST ).}

_{2. Esta é uma ocorrência de um cluster de (super) subtipo de tipo . Caso você esteja interessado, aqui está uma resposta na qual trato de maneira mais detalhada com esse tipo de relacionamento.}

_{3. Um exemplo de um relacionamento hierárquico muitos para muitos e é muito semelhante à estrutura que deu uma solução definitiva para o “Problema de Exploração de Peças” . É claro que essa solução foi introduzida pelo Dr. Edgar Frank Codd em seu artigo de 1970 extremamente influente "Um modelo relacional de dados para grandes bancos de dados compartilhados" .}

_{4. Como tal, esta é uma instância de um relacionamento hierárquico um para muitos (ou muitos para um) .}

Eu acho que você está tentando combinar conceitos da modelagem de objetos e conceitos da modelagem de dados de uma maneira que não esteja ajudando a esclarecer sua própria compreensão do problema. Espero poder limpar a desordem um pouco sem muita divagação.

O modelo relacional, como tal, não suporta herança, não importa o polimorfismo. Isso significa que um padrão de design bastante especializado deve ser usado ao modelar uma situação da vida real que é facilmente manipulada por herança e polimorfismo em um modelo de objeto. Mais sobre esse padrão de design especial mais tarde.

Quando o modelo ER foi desenvolvido, ele deveria ser uma alternativa independente de implementação à modelagem relacional. A princípio, também não tinha nada parecido com herança. Mas, em algum momento das décadas de 1980 ou 1990, o modelo foi estendido para fornecer alguns dos mesmos recursos expressivos que você obtém com a herança. Isso era conhecido como "modelo de ER estendido", mas, para todos os efeitos práticos, o modelo de ER de hoje inclui recursos de EER.

Um recurso EER atende pelo nome "generalização / especialização". Você pode procurar e ler esse conceito na web. Gen-spec fornece praticamente a mesma capacidade expressiva que classes e subclasses fornecem em um modelo de objeto. No entanto, a especificação de geração não lida com os problemas que envolvem o design da tabela relacional para uma situação de especificação de geração. Mais sobre isso mais tarde.

Na modelagem de ER, um relacionamento sempre envolve as mesmas entidades. Portanto, o relacionamento de amizade entre uma organização e um perfil não é a mesma coisa que o relacionamento de amizade entre um perfil e outro perfil. Os dois relacionamentos precisam de nomes diferentes. Você se amarrará se não seguir esta regra.

Ou você precisa criar uma entidade generalizada da qual Organizações, Perfis e, possivelmente, Locais sejam todas especializações. Não entendo bem o seu caso para ajudá-lo com isso.

Seguindo em frente, percebo que você está combinando seu modelo relacional e seu modelo de ER juntos em um único modelo. Os arquitetos de banco de dados mais experientes fazem isso. Mas eu aconselho você a manter os dois modelos separados (embora reconciliados um com o outro) até obter a proficiência.

Por fim, como projetar tabelas relacionais que representam uma situação gen-spec? Tente procurar esses dois padrões de design "Herança de tabela de classe" e "Herança de tabela única". Existem duas tags para elas no Stackoverflow. Existem também algumas boas apresentações dos padrões na web. Eu particularmente gosto do tratamento de Martin Fowler. Ele parece saber como pensam os modeladores de objetos. Espero que isto ajude.