[Dúvida] Estou insegura quanto a cardinalidade das relações.

Débora,

Basta usar as palavras mágicas que todos nós aprendemos em Hogwarts... aliás, qual é a sua casa em Hogwarts mesmo?

Exemplos (pode estar errado):

• Cliente-Projeto - Meu cliente pode estar um ou em vários projetos, mas meu projeto só pode ter um e somente um cliente. (agora agite a varinha mágica levemente da direita para esquerda).
• Projeto-Arquiteto - Meu projeto tem um e somente um arquiteto, mas meu arquiteto tem zero, um ou muitos Projetos. (agora agite a varinha mágica levemente de baixo para cima).
• Projeto-Agenda - Meu projeto tem uma e somente uma agenda, minha agenda pode ter zero, um ou muitos projetos. (agora agite a varinha mágica levemente de cima para baixo).
• Projeto-Tipo - Meu projeto tem um e somente um tipo, meu tipo pode estar em nenhum, um ou vários projetos. (agora agite a varinha mágica levemente da esquerda para direita).

Mas, ao conversar com meus botões, me vem a pergunta:

• Um projeto pode ter mais de um arquiteto?

Hummm... se um projeto tiver mais de um arquiteto, e um arquiteto tiver mais de um projeto então o relacionamento é "N para N", vai precisar de uma tabela intermediária para quebrar o relacionamento "N-N" em dois de "N-1" e "1-N", pois nenhum banco de dados relacional conhecido pelo homem até os dias de hoje trabalha com tabelas "N-N".

[]'s,

Fabio I.

Oi, Débora! Tudo bem?

Essa matéria no início pode ser um pouco confusa mesmo, mas não se preocupe! Com o tempo você vai com certeza aprimorando a interpretação sobre as cardinalidades. Em breve provavelmente será automático! =)

Portanto, vou te ajudar nessa parte de interpretação, pois notei que ainda há um pouco de dificuldade ao montar os relacionamentos. Uma maneira mais tranquila de ler os relacionamentos, se talvez for mais fácil, inclusive, é por uma entidade de cada vez. Assim você delimita a primeira parte e depois consegue ter o sentido da segunda no seu modelo. Quando pegamos duas entidades simultaneamente para selecionar as cardinalidades, a análise fica mais confusa, já que cada entidade pode ter algo que mude sua singularidade.

Vamos às análises!

• Relação Cliente-Projeto: temos que um cliente estará associado a um projeto, no mínimo. E no máximo, um cliente poderá estar associado a n projetos. Certo. Isso será lido da direção "cliente" para "projeto". Ali teremos a cardinalidade (1, n), sim. E um projeto pode ter no mínimo um cliente (1), e vários clientes (n), contendo uma cardinalidade de (1, n). Certinho também!

• Relação Projeto-Arquiteto: por enquanto, também está ok!

• Relação Projeto-Agenda: para pegar um projeto, você precisa ter uma agenda disponível. Certo, o mínimo é 1. Contudo, qual é o máximo de agendas em um projeto? Faça a seguinte pergunta: há como inteirar mais de um projeto em sua agenda? Pela regra de negócio que aparenta, não. Ou seja, o máximo é 1. Ficando, assim, (1,1) na direção "projeto" para "agenda" e vice-versa.

• Relação Projeto-Tipo de Projeto: aqui está também certo. Contudo, você concorda que ali poderia se encaixar o "tipo de projeto" como um atributo da entidade Projeto? Na aula 05, a seguinte após a que você inseriu sua dúvida, conta sobre os atributos. Ele poderia se encaixar. No seu modelo faria sentido ter um detalhe sobre essa entidade com esse termo.

Sobre a entidade associativa: iremos utilizar quando há uma relação de n:n, ou seja, de muitos para muitos. Não são todos relacionamentos do seu modelo que precisarão de uma entidade associativa, mas é relevante inserir nos que precisam. E, lembrando que um relacionamento fraco não remete à cardinalidade, mas sim à ligação com uma entidade fraca. Se o número da cardinalidade continua 1:n ou afins, não é necessário trocar para uma entidade associativa.

Espero ter ajudado. Se a dúvida persistir, estou à disposição.

Abraços e bons estudos!

Caramba! É a MariaDB em pessoa! KKKKK!!!

Na verdade, na relação Projeto-Agenda eu posso e preciso pegar mais de um projeto. Para que assim eu consiga receber mais dinheiros. hehehe Assim, só tenho uma agenda, mas muitos espaços disponíveis nela (pelo menos assim penso) Então sim, posso pegar mais de um projeto. E é assim que acontece na verdade. Mas daí eu estipulo datas de entregas diferentes.

Débora,

Mais dinheiros ser bom! KKKKK!!!

Perfeito, "Projeto-Agenda" vira uma relação "N-N" (muitos-para-muitos). Exemplo:

===============================================================

Modelagem de dados: 1:N ou N:N?

Você sabe quando usar um relacionamento do tipo 1:N ou N:N? Optar pelo tipo incorreto pode impactar diretamente no negócio. Portanto, a decisão por qual usar deve ser tomada com cuidado na fase de modelagem, como veremos neste DevCast.

https://www.devmedia.com.br/modelagem-1-n-ou-n-n/38894

===============================================================

Veja que o relacionamento acima é de Filmes / Atores , um filme pode ter muitos atores e um ator está em vários filmes. Então é preciso uma tabela intermediária para "quebrar" em dois relacionamentos "1-N" (um para muitos) ou "N-1" (muitos para um), tanto faz, mas sempre o lado "N" fica por conta da tabela intermediária, que neste caso se chama "Atuação".

Você vai precisar de uma tabela assim e talvez a tabela "Agenda" precise de um código para chave primária, pois se você usar como chave primária, por exemplo: YYYYMMDDhhmmss (ano, mês, dia, hora, minuto, segundo) pode ser que um mesmo projeto ocupe o mesmo lugar, tenha a mesmo código... isso seria muito ruim.

https://lucid.app/lucidchart/2407acaa-bbd1-4da4-a799-f9362f836361/edit?viewport_loc=182%2C159%2C1518%2C1164%2C0_0&invitationId=inv_fe93f0d3-1645-458c-aae7-77f655a4a93e

Essa é a diferença do MER para o destino final: DER. No Banco de Dados NÃO existe relacionamento "N-N", isso precisa ser pensado antes de colocar no Banco de Dados.

Por favor, leia o link abaixo e veja o vídeo:

===============================================================

MER e DER: Modelagem de Bancos de Dados

Veja neste artigo as definições de Modelo Entidade Relacionamento (MER) e Diagrama Entidade Relacionamento (DER), utilizados na modelagem de bancos de dados.

https://www.devmedia.com.br/mer-e-der-modelagem-de-bancos-de-dados/14332

===============================================================

Diagrama ER: cardinalidade de relacionamento N:N

10 de jul. de 2020

EdukaTI

https://www.youtube.com/watch?v=wmBkKi63QHs

===============================================================

[]'s,

Fabio I.

Obrigada Maria e obrigada Fábio! Vocês me ajudaram a compreender melhor! Vou fazer os ajustes e quem sabe publicar como [Projeto] do exercício dessa aula.

Mais uma vez, graditão a vocês!