Olá David, tudo bem?
Desde já peço desculpas pela demora em obter retorno.
Analisei o seu código referente a criação de chaves estrangeiras das tabelas vendas e itens notas e tenho alguns pontos de melhorias.
Na tabela de vendas, ela terá duas chaves estrangeiras, uma será o campo CPF
orginado da tabela de CLIENTES
e o campo MATRICULA
referente a matrícula da tabela de VENDEDORES
.
ALTER TABLE TABELA_DE_VENDAS ADD CONSTRAINT FK_CLIENTES
FOREIGN KEY (CPF) REFERENCES CLIENTES (CPF);
ALTER TABLE TABELA_DE_VENDAS ADD CONSTRAINT FK_VENDEDORES
FOREIGN KEY (MATRICULA) REFERENCES VENDEDORES (MATRICULA);
A tabela ITENS_NOTAS
terá duas chaves estrangeiras, o campo CÓDIGO
referente ao código da tabela PRODUTOS
e o campo NUMERO
referente ao campo numero da tabela VENDAS
.
ALTER TABLE itens_notas ADD CONSTRAINT FK_VENDAS
FOREIGN KEY (NUMERO)
REFERENCES VENDAS (NUMERO);
ALTER TABLE itens_notas ADD CONSTRAINT FK_PRODUTOS
FOREIGN KEY (CODIGO)
REFERENCES PRODUTOS (CODIGO);
Portanto, a engenharia reversa ficará assim:
Na imagem acima a tabela notas corresponde a tabela vendas.
Em relação às direções do relacionamento, é possível ter relacionamentos multidirecionais em um banco de dados relacional, como em relação muitos para muitos. No entanto, os sistemas de bancos de dados relacionais geralmente não permitem implementar um relacionamento muitos para muitos direto entre duas tabelas, sendo necessário o uso de uma tabela intermediária para estabelecer a relação.
Em relação a relacionamentos ambíguos, o modelo de banco de dados relacional, que utiliza a linguagem SQL para manipulação dos dados, não permite relacionamentos ambíguos. A integridade referencial é garantida por meio de restrições que definem as regras de relacionamento entre as tabelas.
Espero ter ajudado a esclarecer suas dúvidas.
Se tiver mais alguma dúvida, fico à disposição.
Abraços e bons estudos!
Caso este post tenha lhe ajudado, por favor, marcar como solucionado ✓. Bons Estudos!