(1부) DB 정규화(normalization)는 DB를 설계하는 공식적인 방법이죠~ 1부에서는 정규화 개념과 정규화 과정의 앞 부분인 1NF, 2NF를 설명합니다 :) 

🔶 몇 가지 코멘트 남깁니다~ * DB 정규화를 소개하는 영상입니다 - 1부 영상 : ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-EdkjkifH-m8.html (현재 영상) - 2부 영상 : ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-5QhkZkrqFL4.html * 03:44 한 계좌는 한 개 이상의 카드와 연동될 수 있지만, 그 어떤 카드와도 연동되지 않을 수도 있습니다 그리고 card_id는 모든 카드마다 unique 하다고 하겠습니다 * 16:38 account_card 테이블에 primary key를 지정할 때는 두 가지 가능성이 존재합니다 1. {account_id, card_id}를 primary key로 지정 만약 계좌에 연결된 카드가 없을 때 card_id에 "None"을 저장하기로 결정했다면 이때는 account_id와 card_id를 합쳐서 {account_id, card_id}를 primary key로 지정해야 합니다 2. {card_id}를 primary key로 지정 만약 연결된 카드가 없는 계좌는 아예 account_card 테이블에 저장하지 않기로 결정했다면 이때는 card_id만으로도 primary key를 지정할 수 있습니다 왜냐하면 account_card 테이블에는 카드와 연동된 계좌만 저장될 것이라서 card_id에는 유효한 카드 id만 저장될 것이고, 각각의 card_id는 카드마다 unique하다고 가정했기 때문에, card_id만으로도 account_card의 tuple을 식별할 수 있기 때문입니다 물론 이 경우에도 {account_id, card_id}를 primary key로 지정해도 됩니다 저라면 연결된 카드가 없는 계좌는 아예 account_card 테이블에 저장하지 않기로 결정할 것 같고 primary key로는 {account_id, card_id}로 할 것 같습니다 왜냐하면 실제 조회 자체는 account_id로 많이 조회할 것 같은데 {card_id}로 primary key를 지정하면 account_id에 인덱스를 추가로 걸어줘야 조회 성능이 잘 나오기 때문입니다 * key와 functional dependency의 차이 : - key는 테이블의 튜플을 유니크하게 식별합니다 - FD는 X → Y 관계에서 Y의 값을 유니크하게 결정합니다 자세한 내용은 블로그에 정리했습니다 : easy-code-yo.tistory.com/41

이것보다 잘 설명한 강의를 본적이 없다

너무 재미있게 보았습니다. 이렇게 체계적으로 데이터베이스를 설계하는 것이었군요.

와 ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ 감탄밖에안나옴 사실

감사합니다

1NF를 했을 때 발생하는 문제를 2NF가 해결할 수 있고.. 그렇게 단계적으로 발생하는 문제를 해결하는 형태였군요 학부때 데이터 설계 배울 때 너무 추상적이고 이해하기 힘들었는데 이제 좀 이해가네요...!! FD를 판단하는 게 먼저일거라고 생각지 못했어요 영상 너무 유익해요 감사합니다!😀

8:43 class(은행 계좌 등급) 로 bank_name 에 FD가 있다고 설명하셨는데, 스키마의 의미로 파악하면 FD가 있다고 보기 어렵지 않을까 생각이 되어 문의 드립니다. 계좌 등급의 이름은 다른 은행에서 중복될 가능성이 있다고 생각돼서요. 이전 강의의 FD를 설명하실 때 테이블 state 보고 FD를 파악해서는 안되는 좋은 예시인 것 같기도 하여 댓글 남겨봅니다 ㅎㅎ.. 영상은 정말 유익합니다! 좋은 영상 남겨주셔서 항상 감사드립니다.

db완전 초보인데 감사합니다~ 진짜 꼭 필요한거만 담긴 단비같은 강의 ㅠㅠ 덕분에 몰랐던거를 점점 알게되는거 같아요!! 까먹지않도록 강의 영상 다시보면서 복습 열심히 해야겠어요!!

안녕하세요 쉬운 코드님! 양질의 강의 덕분에 부족한 부분들을 많이 알 수 있어서 감사히 생각하고 있습니다! 이번 강의에서도 설명해주신 functional dependency와 관련해서 여쭤보고 싶은 것이 있습니다! class에 의하여 bank_name이 결정되므로 bank_name이 class에 functional dependency 하다고 설명해주셨는데요, 사실 우리가 현실 세게를 생각해보면 은행에 의해서 등급이 결정되지 등급에 의하여 은행이 결정되진 않는것 같습니다. 뭔가 현실 세계에 OOP를 대입하려고 했을 때 겪었던 패러다임의 혼동을 동일하게 느꼈는데요 역으로 class가 bank_name에 함수 종속성을 가진다고 해도 참인 명제일지 궁금합니다!

감사합니다!

안녕하세요, 영상을 보다가 질문이 있어서 댓글 남깁니다. 마지막에 account_card테이블을 분리한 뒤에 두 테이블 모두 2NF를 만족한다고 하신 부분에서 제가 영상 내용을 잘 이해하고 있는지 궁금합니다. account_card 테이블에서 card_id는 super key이자, candidate_key 이자, primary key가 되고, non-prime attribute는 account_id 가 되는 것이 맞나요?

안녕하세요! 질문에 있습니다! 만약 대학생의 강좌수강 table 이라고 가정한다면 그학생의 전공이 복수전공일때 (컴공+생물) 그럼 이 전공 2개도 전부 나눠줘야 1NF에 만족하게되는건가요? 오직다른건 전공뿐이에요! 나머지 요소(성적, 학생ID, 강좌이름,교수명등 )는 전부 동일합니다. 설명이 잘전달됬는지 모르겠네요 ㅠㅠ

영상 너무 감사합니다. 질문이 하나 있는데요. 모든 후보키를 찾아라한다면 (account_num, class)도 포함되는 건가요? 아니면 후보키라는 정의가 주어진 함수종속성만을 따져서 정의하는 건가요?

11:10 어트리뷰트에대해서 데이터들이 중복된게 있다 이말씀이신거고 card_id 속성으로인해 튜플이 중복인건아닌거죠?? 이런 릴레이션은 잘못된 건가요? 여러릴레이션을 보면 영상과 비슷하게 각 튜플에대해 몇몇속성의 데이터들은 중복되어있는 경우도있던데 중복의 개념이 햇갈려 질문드립니다

좋은 강의 감사합니다! 질문이 생겨 남깁니다. 5분쯤에 {bank_name, account_num}을 super key로 잡을 수 있다 하셨습니다. 그런데 한 계좌에서 하나 이상의 카드와 연동될 수 있으니 bank_name, account_num이 같아도 card_id가 다른 행이 생길 수 있지 않나 싶습니다.

안녕하세요 강의 잘 듣고있습니다! 질문이 하나있습니다! 2NF 설명하신 것 중에 : 모든 non~ 모든 key에 fully functionall depent 해야한다에서 key는 모든 후보키라고 생각해도 상관 없는거죠? 찾아보니 다들 기본키라고만 적어놓으셔서, 결국 후보키도 기본키가 될 수 있으니 후보키라고 생각하는게 맞나요?

Geeksforgeek에 candidate key는 튜플들을 구별할수있는 미니멀한 수퍼키라고되어잇는데 1개짜리가잇는데 두개짜리가 어떻게 후보키가되나요..?

감사합니다

감사합니다