🔶 몇 가지 코멘트 남깁니다~ * DB 정규화를 소개하는 영상입니다 - 1부 영상 : czcams.com/video/EdkjkifH-m8/video.html (현재 영상) - 2부 영상 : czcams.com/video/5QhkZkrqFL4/video.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를 파악해서는 안되는 좋은 예시인 것 같기도 하여 댓글 남겨봅니다 ㅎㅎ.. 영상은 정말 유익합니다! 좋은 영상 남겨주셔서 항상 감사드립니다.
안녕하세요 쉬운 코드님! 양질의 강의 덕분에 부족한 부분들을 많이 알 수 있어서 감사히 생각하고 있습니다! 이번 강의에서도 설명해주신 functional dependency와 관련해서 여쭤보고 싶은 것이 있습니다! class에 의하여 bank_name이 결정되므로 bank_name이 class에 functional dependency 하다고 설명해주셨는데요, 사실 우리가 현실 세게를 생각해보면 은행에 의해서 등급이 결정되지 등급에 의하여 은행이 결정되진 않는것 같습니다. 뭔가 현실 세계에 OOP를 대입하려고 했을 때 겪었던 패러다임의 혼동을 동일하게 느꼈는데요 역으로 class가 bank_name에 함수 종속성을 가진다고 해도 참인 명제일지 궁금합니다!
안녕하세요! 질문에 있습니다! 만약 대학생의 강좌수강 table 이라고 가정한다면 그학생의 전공이 복수전공일때 (컴공+생물) 그럼 이 전공 2개도 전부 나눠줘야 1NF에 만족하게되는건가요? 오직다른건 전공뿐이에요! 나머지 요소(성적, 학생ID, 강좌이름,교수명등 )는 전부 동일합니다. 설명이 잘전달됬는지 모르겠네요 ㅠㅠ
안녕하세요, 영상을 보다가 질문이 있어서 댓글 남깁니다. 마지막에 account_card테이블을 분리한 뒤에 두 테이블 모두 2NF를 만족한다고 하신 부분에서 제가 영상 내용을 잘 이해하고 있는지 궁금합니다. account_card 테이블에서 card_id는 super key이자, candidate_key 이자, primary key가 되고, non-prime attribute는 account_id 가 되는 것이 맞나요?
오!! 네네 맞습니다~!! 좋은 질문 주셨어요~ 제가 영상 만들 때는 account_card 테이블에서는 candidate_key가 (account_id, card_id) 뿐이라고만 생각해서 그래서 이 키를 primary key로 만들고 둘 다 언더바(_) 표시를 해줬었는데요, 질문주신 것을 읽고 다시 생각해보니, 한 카드는 한 계좌와만 연동이 되고, 한 카드가 여러 계좌와 연동되는 경우는 없기 때문에 card_id 만으로도 key(= candidate key)가 될 수 있을 것 같습니다 그래서 다시 정리하면 말씀하신 것이 정확히 딱 맞습니다 (저보다 나으시네요 👍) 이건 제가 실책한 부분이 있어서 따로 댓글로도 써서 고정해 둘게요~! 질문 주셔서 정말 감사합니다 ! 덕분에 제가 잘못한 부분을 발견할 수 있었어요 👍
@@ez. 답변 감사합니다! 저는 지금 백엔드 개발자로 취업 준비를 하고 있는데, 비전공자이다 보니 CS 공부를 어떻게 해야할지 막막해 하던 참에 쉬운코드님 영상을 보게되었습니다. '내맘내고 백발백중' 목록은 저에게 정말 단비같은 존재에요! 좋은 영상을 꾸준히 제작해주심에 정말 감사드린다는 말씀 꼭 드리고 싶습니다!
11:10 어트리뷰트에대해서 데이터들이 중복된게 있다 이말씀이신거고 card_id 속성으로인해 튜플이 중복인건아닌거죠?? 이런 릴레이션은 잘못된 건가요? 여러릴레이션을 보면 영상과 비슷하게 각 튜플에대해 몇몇속성의 데이터들은 중복되어있는 경우도있던데 중복의 개념이 햇갈려 질문드립니다
넵, 11:10은 card_id를 나눠서 저장하게 되면서 bank_name, ~~~ empl_name 까지의 attribute에서는 마지막 두 튜플이 중복된 데이터를 가진다는 의미입니다 >> 이런 릴레이션은 잘못된 건가요? 잘못이라고 하기엔 애매하고요, 1NF를 위반한다고 말할 수 있습니다. '위반하면 잘못아니냐?' 라고 하실 수도 있지만, 실무에서 현실적으로 특히 1NF는 논란이 많습니다 그래서 각 서비스의 상황에 따라서는 위반을 하더라도 여러 값들을 한 튜플의 속성 값으로 저장하기도 합니다~ 하지만 어쨌든 그렇게 하면 1NF를 위반하는 것 또한 맞습니다
좋은 강의 감사합니다! 질문이 생겨 남깁니다. 5분쯤에 {bank_name, account_num}을 super key로 잡을 수 있다 하셨습니다. 그런데 한 계좌에서 하나 이상의 카드와 연동될 수 있으니 bank_name, account_num이 같아도 card_id가 다른 행이 생길 수 있지 않나 싶습니다.
안녕하세요 강의 잘 듣고있습니다! 질문이 하나있습니다! 2NF 설명하신 것 중에 : 모든 non~ 모든 key에 fully functionall depent 해야한다에서 key는 모든 후보키라고 생각해도 상관 없는거죠? 찾아보니 다들 기본키라고만 적어놓으셔서, 결국 후보키도 기본키가 될 수 있으니 후보키라고 생각하는게 맞나요?
🔶 몇 가지 코멘트 남깁니다~
* DB 정규화를 소개하는 영상입니다
- 1부 영상 : czcams.com/video/EdkjkifH-m8/video.html (현재 영상)
- 2부 영상 : czcams.com/video/5QhkZkrqFL4/video.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
이것보다 잘 설명한 강의를 본적이 없다
너무 재미있게 보았습니다. 이렇게 체계적으로 데이터베이스를 설계하는 것이었군요.
감사합니다
저도 감사합니다 :)
와 ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ 감탄밖에안나옴 사실
헿 감사합니다 👍
@@ez. 제가더감사합니다
1NF를 했을 때 발생하는 문제를 2NF가 해결할 수 있고.. 그렇게 단계적으로 발생하는 문제를 해결하는 형태였군요 학부때 데이터 설계 배울 때 너무 추상적이고 이해하기 힘들었는데 이제 좀 이해가네요...!! FD를 판단하는 게 먼저일거라고 생각지 못했어요 영상 너무 유익해요 감사합니다!😀
네 맞습니다 처음부터 순서대로 진행하면 되고요, 만약 이미 1NF를 만족하고 있다면 바로 2NF를 점검하면 되고, 2NF도 이미 만족하고 있다면 3NF를 점검하면 되고,, 이런 순서로 보시면 될 것 같아요 :)
영상을 유익하게 봐주셔서 정말 감사합니다~!! 👍👍
감사합니다!
저도 언제나 댓글로 응원해 주셔서 감사합니다 :)
db완전 초보인데 감사합니다~ 진짜 꼭 필요한거만 담긴 단비같은 강의 ㅠㅠ 덕분에 몰랐던거를 점점 알게되는거 같아요!! 까먹지않도록 강의 영상 다시보면서 복습 열심히 해야겠어요!!
넵~! 정규화가 RDB에서는 중요한 개념이라 잘 알고 계시면 분명 도움 많이 되실 겁니다 :)
8:43 class(은행 계좌 등급) 로 bank_name 에 FD가 있다고 설명하셨는데, 스키마의 의미로 파악하면 FD가 있다고 보기 어렵지 않을까 생각이 되어 문의 드립니다.
계좌 등급의 이름은 다른 은행에서 중복될 가능성이 있다고 생각돼서요.
이전 강의의 FD를 설명하실 때 테이블 state 보고 FD를 파악해서는 안되는 좋은 예시인 것 같기도 하여 댓글 남겨봅니다 ㅎㅎ..
영상은 정말 유익합니다! 좋은 영상 남겨주셔서 항상 감사드립니다.
안녕하세요 쉬운 코드님! 양질의 강의 덕분에 부족한 부분들을 많이 알 수 있어서 감사히 생각하고 있습니다!
이번 강의에서도 설명해주신 functional dependency와 관련해서 여쭤보고 싶은 것이 있습니다!
class에 의하여 bank_name이 결정되므로 bank_name이 class에 functional dependency 하다고 설명해주셨는데요,
사실 우리가 현실 세게를 생각해보면 은행에 의해서 등급이 결정되지 등급에 의하여 은행이 결정되진 않는것 같습니다.
뭔가 현실 세계에 OOP를 대입하려고 했을 때 겪었던 패러다임의 혼동을 동일하게 느꼈는데요
역으로 class가 bank_name에 함수 종속성을 가진다고 해도 참인 명제일지 궁금합니다!
영상 너무 감사합니다. 질문이 하나 있는데요. 모든 후보키를 찾아라한다면 (account_num, class)도 포함되는 건가요? 아니면 후보키라는 정의가 주어진 함수종속성만을 따져서 정의하는 건가요?
안녕하세요! 질문에 있습니다! 만약 대학생의 강좌수강 table 이라고 가정한다면 그학생의 전공이 복수전공일때 (컴공+생물) 그럼 이 전공 2개도 전부 나눠줘야 1NF에 만족하게되는건가요? 오직다른건 전공뿐이에요! 나머지 요소(성적, 학생ID, 강좌이름,교수명등 )는 전부 동일합니다. 설명이 잘전달됬는지 모르겠네요 ㅠㅠ
안녕하세요, 영상을 보다가 질문이 있어서 댓글 남깁니다.
마지막에 account_card테이블을 분리한 뒤에 두 테이블 모두 2NF를 만족한다고 하신 부분에서
제가 영상 내용을 잘 이해하고 있는지 궁금합니다.
account_card 테이블에서 card_id는 super key이자, candidate_key 이자, primary key가 되고,
non-prime attribute는 account_id 가 되는 것이 맞나요?
오!! 네네 맞습니다~!!
좋은 질문 주셨어요~
제가 영상 만들 때는 account_card 테이블에서는 candidate_key가 (account_id, card_id) 뿐이라고만 생각해서 그래서 이 키를 primary key로 만들고 둘 다 언더바(_) 표시를 해줬었는데요,
질문주신 것을 읽고 다시 생각해보니, 한 카드는 한 계좌와만 연동이 되고, 한 카드가 여러 계좌와 연동되는 경우는 없기 때문에 card_id 만으로도 key(= candidate key)가 될 수 있을 것 같습니다
그래서 다시 정리하면
말씀하신 것이 정확히 딱 맞습니다 (저보다 나으시네요 👍)
이건 제가 실책한 부분이 있어서 따로 댓글로도 써서 고정해 둘게요~!
질문 주셔서 정말 감사합니다 !
덕분에 제가 잘못한 부분을 발견할 수 있었어요 👍
@@ez. 답변 감사합니다!
저는 지금 백엔드 개발자로 취업 준비를 하고 있는데, 비전공자이다 보니 CS 공부를 어떻게 해야할지
막막해 하던 참에 쉬운코드님 영상을 보게되었습니다.
'내맘내고 백발백중' 목록은 저에게 정말 단비같은 존재에요!
좋은 영상을 꾸준히 제작해주심에 정말 감사드린다는 말씀 꼭 드리고 싶습니다!
@@user-ek6jn9ie9s 오오 백엔드 개발자로 취업 준비시라니 정말 반가워요 !
쉬운코드 채널을 통해서 여러모로 도움을 드릴 수 있어서 저도 너무 좋고 뿌듯합니다 👍ㅎㅎ
좋은 곳에 당당히 취업하실 수 있도록 앞으로도 꾸준히 좋은 영상으로 응원할게요~!
11:10 어트리뷰트에대해서 데이터들이 중복된게 있다 이말씀이신거고 card_id 속성으로인해 튜플이 중복인건아닌거죠?? 이런 릴레이션은 잘못된 건가요?
여러릴레이션을 보면 영상과 비슷하게 각 튜플에대해 몇몇속성의 데이터들은 중복되어있는 경우도있던데 중복의 개념이 햇갈려 질문드립니다
넵, 11:10은 card_id를 나눠서 저장하게 되면서 bank_name, ~~~ empl_name 까지의 attribute에서는 마지막 두 튜플이 중복된 데이터를 가진다는 의미입니다
>> 이런 릴레이션은 잘못된 건가요?
잘못이라고 하기엔 애매하고요, 1NF를 위반한다고 말할 수 있습니다. '위반하면 잘못아니냐?' 라고 하실 수도 있지만, 실무에서 현실적으로 특히 1NF는 논란이 많습니다
그래서 각 서비스의 상황에 따라서는 위반을 하더라도 여러 값들을 한 튜플의 속성 값으로 저장하기도 합니다~
하지만 어쨌든 그렇게 하면 1NF를 위반하는 것 또한 맞습니다
좋은 강의 감사합니다! 질문이 생겨 남깁니다.
5분쯤에 {bank_name, account_num}을 super key로 잡을 수 있다 하셨습니다. 그런데 한 계좌에서 하나 이상의 카드와 연동될 수 있으니 bank_name, account_num이 같아도 card_id가 다른 행이 생길 수 있지 않나 싶습니다.
아 한 행에 카드를 모두 넣으셨군요 1NF 만족시키면서 문제가 발생한거고, 해결했습니다!!
크 맞습니다~!! 1NF부터 BCNF까지 한큐에 설명할 수 있는 예제를 만들다 보니 처음에 그렇게 시작하게 됐어요
그런데 관호님께서 인사이트가 있으셔서 1NF를 이미 머리속에서 생각하신거구요~ 정말 최고십니다!!! 👍
계좌하나를 카드를 여러개로 쓸수있나요 원래? db말고 새로운사실을 알게되엇네요 ㅋㅋ 그런데 최소성을 만족하지않는 슈퍼키인 {뱅크네임,계좌번호}도 후보키가될수있는건가요?
@@parkjj111 네 맞습니다 ㅎㅎ 한 계좌에 여러 카드 연동이 가능합니다 :)
혹시 최소성이 무엇을 의미하는건가요?
안녕하세요 강의 잘 듣고있습니다! 질문이 하나있습니다!
2NF 설명하신 것 중에 : 모든 non~ 모든 key에 fully functionall depent 해야한다에서
key는 모든 후보키라고 생각해도 상관 없는거죠?
찾아보니 다들 기본키라고만 적어놓으셔서, 결국 후보키도 기본키가 될 수 있으니 후보키라고 생각하는게 맞나요?
네 맞습니다 key는 후보키(candidate key)라고 보시면 됩니다
보통 candidate key를 줄여서 그냥 key라고 부릅니다
@@ez. 감사합니다 :)
Geeksforgeek에 candidate key는 튜플들을 구별할수있는 미니멀한 수퍼키라고되어잇는데 1개짜리가잇는데 두개짜리가 어떻게 후보키가되나요..?
약간 혼돈을 하신 것 같아요~
미니멀의 의미가 한개짜리가 있고 두개짜리가 있을 때 한개짜리가 미니멀하다의 의미가 아니라서 그렇습니다~
슈퍼키를 구성하는 attributes 중에서 하나라도 없으면 더이상 키의 역할을 하지 못할 때 이를 미니멀 슈퍼키라고 합니다
감사합니다
저도 시청 감사합니다 :)
감사합니다