Relacionamento com chave estrangeira composta

[Guest --Carlos --]

Olá. Estou com um problema e gostaria de saber se alguém tem alguma sugestão para resolvê-lo.

Tenho a seguinte tabela:

create table FuncaoModulo

(

siglaFuncao char (4) not null,

siglaModulo char (4) not null,

FOREIGN KEY (siglaModulo) REFERENCES Modulo(sigla), -> referencia uma tabela simples com campos sigla e descricao

FOREIGN KEY (siglaFuncao) REFERENCES Funcao(sigla) -> referencia uma tabela simples com campos sigla e descricao

)

Tenho outra tabela que eu criei assim (mas pode ser alterada =) )

CREATE TABLE PerfilFuncao

(

siglaPerfil char(4) not null,

siglaFuncao char(4) not null,

siglaModulo char(4) not null,

FOREIGN KEY (siglaPerfil) REFERENCES Perfil(sigla),

FOREIGN KEY (siglaModulo) REFERENCES FuncaoModulo(siglaModulo),

FOREIGN KEY (siglaFuncao) REFERENCES FuncaoModulo(siglaFuncao)

)

O que eu tinha em mente? Criar uma relação entre perfis de usuário e módulos / funções de um sistema.

No entanto fazendo assim acontece o seguinte:

Supondo que eu tenha os seguintes registros em FuncaoModulo:

siglaFuncao siglaModulo

-------------- --------------

altr prod

incl usua

Pelas foreign keys da tabela PerfilFuncao ele só deixa criar registros a partir de valores que estejam em FuncaoModulo. Até aí, tudo bem. No entanto ele deixa cruzar dados, tipo, criar a dupla altr/usua ou incl/prod. Eu queria saber se existe um jeito de só permitir usar A DUPLA DE UM REGISTRO, não deixar cruzar as colunas, tipo, no exemplo, só deixar incluir incl/usua ou altr/prod.

Obrigado desde já.

[Denis Courcy]

Oi, Carlos!

Por favor passe o conceito das tabelas (todas) para que possamos montar um DER adequado.

O que você passou está incompleto e confuso.

[Guest Visitante]

Acho que seria isso:

CREATE TABLE Funcao

(

sigla char(4) Primary key not null,

descricao varchar(100) not null

)

CREATE TABLE Perfil

(

sigla char(4) Primary key not null,

descricao varchar(100) not null

)

CREATE TABLE Modulo

(

sigla char(4) Primary key not null,

descricao varchar(100) not null

)

CREATE TABLE Usuario

(

nome char(4) Primary key not null,

senha varchar(100) not null,

ativo boolean

)

CREATE TABLE FuncaoModulo

(

siglaFuncao char (4) not null,

siglaModulo char (4) not null,

FOREIGN KEY (siglaModulo) REFERENCES Modulo(sigla),

FOREIGN KEY (siglaFuncao) REFERENCES Funcao(sigla)

)

CREATE TABLE PerfilUsuario

(

siglaPerfil char(4) Primary key not null,

nomeUsuario varchar(100) not null,

FOREIGN KEY (siglaPerfil) REFERENCES Perfil(sigla),

FOREIGN KEY (nomeUsuario) REFERENCES Usuario(nome)

)

CREATE TABLE PerfilFuncao

(

siglaPerfil char(4) not null,

siglaFuncao char(4) not null,

siglaModulo char(4) not null,

FOREIGN KEY (siglaPerfil) REFERENCES Perfil(sigla),

FOREIGN KEY (siglaModulo) REFERENCES FuncaoModulo(siglaModulo),

FOREIGN KEY (siglaFuncao) REFERENCES FuncaoModulo(siglaFuncao)

)

Obrigado!

[Denis Courcy]

Ok. Carlos! Já desenhei o modelo conforme as tabelas que você passou. Mas preciso do conceito. ou seja, o que as tabelas fazem e o que você deseja que seja feito.

Isto tudo é para saber se o modelo que você idealizou é o que foi desenhado ou se há a necessidade de melhorá-lo.

[Guest --Carlos --]

Hummm, ok Denis. Desculpe por não ter entendido.

O conceito é o seguinte... estou planejando um sistema de cadastro e gerenciamentos de funções, módulos, perfis e usuários para um sistema.

1) As funções (tabela funcao, no caso) seriam coisas do tipo incluir, alterar, excluir, consultar, etc...

2) Os módulos (tabela modulo) seriam as transações em nível macro, algo como Produtos, Pessoas, Empresas, etc...

3) No caso de Produtos eu poderia ter as funções Alterar e Excluir e no caso de Pessoas eu poderia ter Incluir e Alterar, por exemplo. Essa relação eu havia pensado como sendo a tabela FuncaoModulo, que faria o relacionamento das tabelas funcao e modulo, obviamente =)

4) A seguir eu teria uma série de Perfis de acesso (tabela perfil) que seriam os tipos de usuários possíveis, como administrador, gerente, usuário comum, etc...

Esses perfis seriam ligados com a tabela FuncaoModulo, através de PerfilFuncao, para assim eu determinar quais funcionalidades esse perfil teria acesso no sistema. Esse é o meu problema. Seguindo meu exemplo do item 3, onde eu teria como funcionalidades possíveis Alterar ou Excluir Produtos e Incluir ou Alterar Pessoas; eu não poderia permitir a um perfil Excluir Pessoas ou Incluir Produtos, por exemplo, pois são funcionalidades que não "existem", ou seja, não estão cadastradas em FuncaoModulo. Posso fazer isso a nível de programa, fazendo uma pesquisa pela dupla funcao/modulo, mas gostaria de ter essa garantia também no BD, e é isso que não estou conseguindo.

5) Por último eu teria os usuários do sistema, que seriam relacionados a um ou mais perfis de acesso, isso se daria por meio da tabela PerfilUsuario.

Creio que seja isso que você queria saber... obrigado pela ajuda até o momento.

[Carlos {Gaspa}]

Por favor. Ninguém tem nenhuma idéia?

[Carlos {Gaspa}]

Ninguém tem nenhuma idéia?

Onde foi parar o Denis q estava perguntando os detalhes?

[Denis Courcy]

Oi, Carlos!

Desculpe por não ter respondido antes. Estou tremendamente atarefado no trabalho e tenho respondido a perguntas simples com repostas simples. Seu caso é um pouco mais complicado.

Como mencionei no post anterior, fiz modelo das tabelas e ligações que você passou. está em anexo.(usuarioperfilacesso_modelocarlos.pdf)

Porém, achei seu método um tanto complicado. Como gosto de coisas simples e práticas (a manutenção futura é muito mais fácil) desenhei um outro modelo que exponho a seguir e que está no anexo(01_Segurançaa_e_Acesso_Log_v2.pdf):

1. Cadastrar os Ítens de menu de acesso que serão controlados

2. Cadastrar os Perfís de acesso, estabelecendo a ligação com os menus de acess e classificando os tipos de direitos de acesso que serão permitidos (inclusão, alteração exclusão). O modo "Somente Consulta" existe quando há um registro contendo o ítem de menu mas os direitos de acesso estão marcados como "Não".

3. Cadastrar o usuário e informar o tipo de perfil que ele terá acesso. De acordo com o projeto (que eu uso em meu sistema) o usuário tem um perfil obrigatório e pode ter ter mais um (opcional) que possibilita uma extensão de suas atividades habituais ora desempenhadas.

No cadastro de usuário existem dois indicadores.

O indicador de supervisão, por default é marcado como "Não", informa que este usuário é um supervisor de caixa e que tem direito a confirmar "assinar" as seguintes operações: abertura de caixa, fechamento de caixa, sangria e devolução (extorno).

O indicador de Habilitação, por default é marcado como "Sim", informa se o usuário está habilitado a operar o sistema. Por motivo de audotoria, o usuártio só pode ser excluido se não houver transação no log de operações do mesmo. Então, quando já existe operação para este usuário e necessito excluir este usuário, em vez de excluí-lo, eu marco este indicador como "Não".

Espero que goste e que isto de ajude. Qualquer coisa é só perguntar novamente.

usuarioperfilacesso_modelocarlos.pdf

01_Seguran_a_e_Acesso_Log_v2.pdf