O TEMA DO FÓRUM ESTÁ EM MANUTENÇÃO. FEEDBACKS AQUI: ACESSAR

Cardinalidade e Relacionamentos [DB]

Iniciado por Selitto, 31/08/2017 às 13:44

31/08/2017 às 13:44 Última edição: 31/08/2017 às 14:05 por Selitto

Sei que meu modelo não está bem certo, gostaria que pudessem me ajudar.
Spoiler


[close]


Como se comporta uma relação aonde tenho Usuários e esses relacionamentos, me disseram 1..n porque tenho vários usuarios.


E como relaciono dois usuários com empréstimo por exemplo no modelo lógico? Preciso de 2 chaves estrangeiras para id-usuario e os livros? Meu professor disse que não pode ter 2 relações entre tabelas.

Preciso mesmo de ajuda para montar esse banco, o que estou achando mais difícil, é como ter essas relações aonde preciso de 2 usuários, por exemplo numa avaliação preciso saber quem fez e quem recebeu? Empréstimo que solicitou e quem recebeu? assim por diante. Vou por o modelo lógico para quem puder baixar e por no workbench:

http://www.mediafire.com/file/bqjczt3668ce8ap/Logico.mwb

EDIT:
Spoiler

[close]

Está certo a relação de 1 para N.

Por exemplo, 1 usuário envia N mensagens, mas cada mensagem só tem 1 usuário.

O mesmo ocorre no caso do empréstimo: 1 usuário empresta N livros, mas cada empréstimo só é realizado por 1 usuário.

Um exemplo da tabela de empréstimo seria:

CREATE TABLE `emprestimo` 
  ( 
     `id`              INT NOT NULL, 
     `livro_id`        INT NOT NULL, 
     `usuario_id`      INT NOT NULL, 
     `recebedor_id`    INT NOT NULL, 
     `data_emprestimo` DATE NOT NULL, 
     `data_retorno`    DATE NOT NULL, 
     `retornado`       TINYINT NOT NULL, 
     PRIMARY KEY (`id`), 
     INDEX (`livro_id`), 
     INDEX (`usuario_id`), 
     INDEX (`recebedor_id`) 
  ) 
engine = innodb;


Uma relação 1 para 1 é raro, já que você geralmente pode colocar ambas na mesma tabela. A sua relação de usuário-endereço é um exemplo. Geralmente usuários possuem mais de 1 endereço, o que faria 1 para N.

Já a relação de categoria e livro poderia ser uma relação N para N, já que 1 livro pode ter mais de 1 categoria e a categoria pode pertencer a 1 ou mais livros. Nesse cenário, cria-se um tabela intermediária, e a chave primária é o composto das chaves primárias das duas tabelas. Dessa forma você evita ter o mesmo relacionamento de categoria e livro repetido:

CREATE TABLE `livro_categoria` 
  ( 
     `livro_id`     INT NOT NULL, 
     `categoria_id` INT NOT NULL, 
     PRIMARY KEY (`livro_id`, `categoria_id`) 
  ) 
engine = innodb;


Citação de: Kyo Panda online 31/08/2017 às 14:09
Está certo a relação de 1 para N.

Por exemplo, 1 usuário envia N mensagens, mas cada mensagem só tem 1 usuário.

O mesmo ocorre no caso do empréstimo: 1 usuário empresta N livros, mas cada empréstimo só é realizado por 1 usuário.

Um exemplo da tabela de empréstimo seria:

CREATE TABLE `emprestimo` 
  ( 
     `id`              INT NOT NULL, 
     `livro_id`        INT NOT NULL, 
     `usuario_id`      INT NOT NULL, 
     `recebedor_id`    INT NOT NULL, 
     `data_emprestimo` DATE NOT NULL, 
     `data_retorno`    DATE NOT NULL, 
     `retornado`       TINYINT NOT NULL, 
     PRIMARY KEY (`id`), 
     INDEX (`livro_id`), 
     INDEX (`usuario_id`), 
     INDEX (`recebedor_id`) 
  ) 
engine = innodb;


Uma relação 1 para 1 é raro, já que você geralmente pode colocar ambas na mesma tabela. A sua relação de usuário-endereço é um exemplo. Geralmente usuários possuem mais de 1 endereço, o que faria 1 para N.

Já a relação de categoria e livro poderia ser uma relação N para N, já que 1 livro pode ter mais de 1 categoria e a categoria pode pertencer a 1 ou mais livros. Nesse cenário, cria-se um tabela intermediária, e a chave primária é o composto das chaves primárias das duas tabelas. Dessa forma você evita ter o mesmo relacionamento de categoria e livro repetido:

CREATE TABLE `livro_categoria` 
  ( 
     `livro_id`     INT NOT NULL, 
     `categoria_id` INT NOT NULL, 
     PRIMARY KEY (`livro_id`, `categoria_id`) 
  ) 
engine = innodb;


Não estou na parte da criação do banco ainda rs.
Eu pensei que teria que ter esse recebedor, mas não sei como colocar, se for com chave estrangeira cria uma ligação na tabela, mas já tem uma ligação com usuário.
Avaliações e mensagens seriam assim? Preciso do id de quem fez e quem recebeu, quem mandou a mensagem e quem recebeu? Sei lá, viu o meu logico? Eu mudei agora pouca, falta algo nas tabelas N---M

Não há problemas em ter duas chaves estrangeiras para a mesma tabela. E sim, seria da mesma forma a avaliação.

Valeu pela ajuda, infelizmente eu ainda não consegui assimilar e criar o modelo lógico certo. Que merda :T.T:

Ai depois de um tempo se alguém ainda puder ajudar: Cheguei a esse modelo lógico, acho que é o melhor que consegui para depois implementar o modelo físico.
Professor disse que eu teria quer ter esse SOLICITANTE E SOLICITADO, então usei como chave em todas outras tabelas que necessitam da interação de 2 usuarios.



Valeu ! To aceitando qualquer dica.
Pra quem quer ter mais noção >>>> https://www.figma.com/file/RZE2K40n6BRh2wWXDT1PeVms/Livrei-App