Relacionamentos One-to-one, One-to-many e Many-to-many - Curso de SQL com MySQL - Aula 2

Nesse vídeo vamos falar sobre os relacionamentos entre entidades usando SQL (ou qualquer SGBD que quiser na verdade).
Para relacionamentos tradicionais que conhecemos, temos três tipos possíveis:
One-to-one (um para um)
One-to-many (um para muitos ou muitos para um)
Many-to-many (muitos para muitos)
Vamos discutir essas relações, vamos falar sobre o diagrama entidade e relacionamento, sobre crows foot notation, cardinalidade e obrigatoriedade de relações, e muito mais.
Sobre a playlist:
Nessa playlist você vai aprender a linguagem SQL com o Curso de SQL com MySQL que promovo como bônus em todos os meus cursos. É importante que todo dev tenha conhecimento de SQL por que isso vai fazer parte da sua rotina. Melhor ainda quando conseguimos conteúdo de qualidade e grátis.
LINK DA PLAYLIST COMPLETA:
• Curso de SQL com MySQL...
Todas as SQLs criadas neste curso estão no link a seguir:
github.com/lui...
Cursos de Python, JavaScript, TypeScript, GraphQL e mais com desconto:
www.otaviomira...
Twitter: / otaviomirandabr
#relacionamentos #mysql #sql

[@capivaraGamer1234-q1m]

Tipos de relação: 1 para 1: 03:37 1 para muitos: 10:13 muitos para muitos: 14:28 outros: 19:42

[@ronaldo2000-ww]

Fala professor, tenho vários cursos seu lá na Udemy, e gosto muito da sua didática, fico feliz que tenha disponibilizado um cursão desses de graça pra todos! Abraço!

Muito obrigado Ronaldo 🙏

[@jonasnunees]

A explicação sobre obrigatoriedade e cardinalidade foi sensacional. Isso era uma coisa que quebrava muito a minha cabeça

[@Ifixphone7]

Curso bom demais, estou em um projeto e garrei demais nessa parte de relacionamentos, mas com suas aulas to conseguindo desenrolar.

[@lucianosoares3407]

Melhor professor que conheço, comprei o react, e tenho mais dois em vistas ja pra comprar na udemy, diferenciado de mais! Contéudo de qualidade e gratuito.

[@vitorrafael5494]

Excelente vídeo. Estou começando agora a estudar sql, e estou começando pelo celular mesmo.

[@hileiacouto1499]

Sua aula é maravilhosa!!!!!!!!!!!!!!!!!!!!!!!!!!

[@okadakelly]

Muito Obrigada por esse curso!

[@maiadidata]

Falar de Otavio Miranda é chover no molhado pois sempre irei dizer que suas aulas são excelentes.

[@erciliamariacoelhodecarval2255]

aula maravilhosa! parabéns pela didática!

[@misaelalexandrino1143]

Muito obrigado pela aula!

[@FNetoG]

Olá professor, já o conheço da Udemy, muita sabedoria da sua parte, gosto muito das suas aulas, obrigado por este curso vem mesmo a calhar, pois vou ter um curso destes aqui em Portugal e assim já tenho umas boas dicas. Um abraço.

[@milianor8194]

Muito legal essas aulas. já estudei o sql mas sempre me esqueço rsrsrs.

[@VHANSEN]

te entendo

[@vanegee525]

Aula concluida

[@Everaldobass]

Excelente curso, direto ao ponto.

[@ezequieldev9770]

otavio qual progama vc esta utilizando para fazer o der

[@matheusaraujo4495]

Muito boa a explicação! Valeu!

[@magnoodilon1327]

Excelente, aula sensacional!!!

[@Brian74-22]

9:30 o seu exemplo foi um pouco confuso, um exemplo melhor seria postagem, para ter uma postagem é obrigatório ter um perfil, mas para ter um perfil não é obrigatorio uma postagem

[@SuperRenatoduarte]

ele é irmão do Guanabara? pq é igualzinho excelente conteúdo!!

[@beniltosantos7720]

ate o rosto e o cenário de gravação dele é igualzinho kkkkkk

[@JOJOBIZARRO-cg2ko]

Pra quem não sabe ID é uma identificação especial ou seja 1 e 2 não podem ter o mesmo ID.

[@andreluis6154]

Qual o nome do programa para desenhar essa estrutura de tabelas ???

[@brjf1986]

03:40 Uma ligação entre a tabela de apartamento, e a tabela de vaga de garagem, em um prédio que tenha uma vaga por apartamento, e essas vagas mudem de tempos em tempos, todo ano tem sorteio das vagas, por existir vagas boas e vagas ruins, para mudar de ano em ano. Tem-se dois cadastros, e, ou no cadastro do ap, coloca o ID da vaga que está com ele, ou no cadastro da vaga coloca o ID do ap que tá com ela. E a cada sorteio anual, muda apenas essa informação, não tendo que redigitar tudo de novo, caso tivesse a informação da vaga no cadastro do AP. Na tabela da vaga tem numero, tamanho, horário que bate sol, se é coberta ou não, se tem divisória, se tem portão, divisa lateral, divisa no fundo, se é dupla/junta com outra, tem vários detalhes na vaga. Abraço

[@1986carlosdiego]

Boa noite Professor, espero que se encontre bem. Por favor, você tem o curso disponível de MySql na Udemy?

[@lojalearnsoftwares]

um perfil não pode ter vários usuários? Se sim, não seria relacionamento many-to-many?

[@andremarques2055]

acredito que seria one-to-many, um perfil para muitos usuários, se estiver errado me corrija, por favor

[@jonasnunees]

Acredito que o exemplo seja parecido como um perfil do LinkedIn por exemplo, onde cada pessoa faz o perfil do seu jeito com uma descrição própria, suas experiências de trabalho, seus cursos e competências etc. ou seja, cada usuário tem um perfil e cada perfil só pode ser atrelado aquele usuário. Por isso que o relacionamento nesse caso é de 1:1

[@josuealves3561]

Qual o nome do programa que usou pra desenhar o diagrama das relações???

[@derickrosadj]

Também gostaria de saber

[@lidroxd6869]

.

[@Josemqmachado]

Em uma relação 1:1 quando se gera o modelo lógico não é criado uma tabela que contem as chaves primarias das duas entidades? Não entendi pq no exemplo de users e profiles, a tabela profile tem uma FK de user. O certo não seria uma nova tabela (users+profiles)?

[@jonasnunees]

@@Josemqmachado isso só ocorre quando a relação é de muitos pra muitos. No caso de um pra um poderia não precisar ter duas tabelas se quisesse

[@natanrelva]

Qual o nome do programa ?

[@Josemqmachado]

10:25: "Uma Primary Key de uma tabela viaja como Foreign Key pra outra tabela, e pode ser tanto como desse lado pra cá como desse lado pra cá". Me surgiu uma dúida considerável nessa afirmação. Em uma de minhas anotações da aula de banco de dados, eu registrei que em uma relação 1:N o lado que tiver o N é que vai receber a Foreign Key, porém, você disse que tanto faz, fiquei confuso. Com sua afirmação dá a entender que a tabela Users pode receber, como Foreign Key, o atribudo ID_profiles, isso seria realmente possivel?

[@williangaioto4028]

quem recebe o ID da tabela users é a profiles, pois ela vai precisar desse ID para definir em qual usuario estarão os arquirvos, espero ter explicado bem kkkkk

[@apertaplays]

Não entendi NADA