Melhor estrutura de banco de dados relacional para esses dados

Estou no processo de criar um esquema de banco de dados para o seguinte cenário:

• Existem usuários
• Os usuários têm funções (como "Desenvolvedor" ou "CEO")
• As funções têm aplicativos (como "Topdesk")
• Os aplicativos têm permissões (como "Atualizar a Base de Conhecimento")
• Uma função pode ter permissões, se a função já tiver acesso ao aplicativo

Assumindo que não haja ambiente de alto desempenho (sem necessidade de otimizar a velocidade), qual seria a melhor maneira de implementar esse esquema? O ambiente de banco de dados pode ser MySQL, MSSQL ... trata-se mais do design de banco de dados relacional.

Eu mesmo propus o seguinte:

A parte sobre a qual tenho mais incerteza é a tabela Applications_Permissions_Roles. É uma tabela de ligação em cima de outra tabela de ligação. Eu nunca usei ou vi isso antes. Outra maneira de fazer isso seria substituí-lo por uma tabela de vinculação entre Funções e Permissões e, em seguida, usar código ou restrições para garantir as relações necessárias ... mas isso não parece ser uma boa solução para mim. Essas coisas devem ser aplicadas no nível do banco de dados, se possível (e parece possível), não no nível do código.

Em segundo lugar, é necessário o link entre Permissions.Application e Applications.Id? Eu o uso porque talvez não haja linhas em Roles_Applications (como quando você acabou de adicionar um novo aplicativo) e, em seguida, não é possível determinar quais permissões pertencem a qual aplicativo. Também é um ponto de referência único para pesquisar a qual aplicativo uma permissão pertence. Eu acho que isso está certo, mas também faz um círculo no design do banco de dados. Erros MSSQL nele ao tentar definir ON_DELETE ou ON_UPDATE para cascata.

Alguma sugestão, ou é assim que deve ser feito? Quaisquer outras sugestões relacionadas à convenção de nomenclatura e outras também são bem-vindas (talvez como comentário).

Obrigado
Luc

Editar: Título alterado, espero torná-lo mais claro. O anterior foi mais abrangente, mas provavelmente muito complicado.

A maneira como você modelou está bem. Seu modelo garante que as regras de negócios sejam aplicadas pelo banco de dados.

Existem algumas coisas que você poderia fazer como alternativa. Uma seria eliminar a chave substituta Roles_Applications. Como uma tabela de interseção, você pode usar as duas chaves estrangeiras juntas como uma chave primária composta. Se você fizesse isso, isso se propagaria Rolee chegaria Applicationà sua Applications_Permissions_Rolesmesa. Isso teria a vantagem de oferecer a você mais "um balcão único" para os dados de permissão do aplicativo (ou seja, menos junções) sem comprometer sua normalização de forma alguma.

Outra maneira que você poderia seguir seria simplificar um pouco e definir uma permissão padrão para cada aplicativo. Você pode chamá-lo como quiser, como "acesso padrão" ou "acesso básico" ou "usuário" ou o que fizer sentido para você. Isso permitiria que você aplanasse seu modelo e essencialmente soltasse a Roles_Applicationstabela e participasse Applications_Permissions_Rolesdiretamente Roles. Isso mudaria a natureza da consulta que você usaria para perguntar "quais funções podem acessar quais aplicativos?" mas suas regras de negócios ainda serão aplicadas pelo esquema.

Roles_Applicationnão parece representar algo real aqui. O que é, além de significar que uma função específica tem algum nível de permissões para um aplicativo, mesmo que você precise fazer check-out Applications_Permissions_Rolespara determinar qual é esse nível? Como exemplo, aqui está um CEO obtendo acesso de gravação ao calendário do aplicativo no seu modelo atual:

Funções

ID    Name
--    ----
1     CEO

Formulários

ID    Name
--    ----
C     Calendar

Permissões

ID    Application_ID  Permission
--    --------------  ----------
10    C               Write

Funções_Aplicativos

ID    Role_ID    Application_ID
--    -------    --------------
50    1          C

Applications_Permissions_Roles

Role_Application_ID    Permission_ID
-------------------    -------------
50                     10

Eu acho que essa série de relacionamentos pode ser modelada sem o Roles_Applications. Se removermos isso (como Joel Brown sugere, mas sem a alteração de assumir que existem "permissões padrão"):

Funções

ID    Name
--    ----
1     CEO

Formulários

ID    Name
--    ----
C     Calendar

Applications_Permissions (nee Permissions)

ID    Application_ID  Permission
--    --------------  ----------
10    C               Write

Applications_Permissions_Roles

Role_ID    Application_Permission_ID
-------    -------------
1          10

A Permissionstabela antiga não possui apenas permissões, como "leitura" e "gravação", que podem ser aplicadas a aplicativos como "Topdesk" e "Calendário": contém permissões específicas de aplicativos, como "gravação no Topdesk" e " escrever no calendário "e" Alterar o relógio do sistema no Windows ". Para deixar isso mais claro, eu nomeei a tabela, Applications_Permissionsmas é claro que essa não é uma etapa necessária.

Essa abordagem tem o efeito de nivelar o modelo, assim como a segunda sugestão de Joel, mas sem adicionar a lógica do aplicativo ou o conceito de permissões padrão. Roles_Applicationsnão estava trazendo nada à parte além de uma indicação de que uma função tem algum nível de acesso a um aplicativo. Essa informação é transmitida com mais brevidade pela existência de um registro Applications_Permissions_Rolescom o valor apropriado de Role_ID.