(2부) DB 정규화(normalization) 2부입니다!! 3NF, BCNF와 2NF 참고 사항, 역정규화(denormalization)까지 설명합니다!!

[@ez.]

몇 가지 코멘트 남깁니다~ 🔸 DB 정규화를 소개하는 영상입니다 - 1부 : kzbin.info/www/bejne/e5XOm56fm61go5o - 2부 : kzbin.info/www/bejne/a4LLnI2hp9Z5gpY (현재 영상) 🔸 key와 functional dependency의 차이 : - key는 테이블의 튜플을 유니크하게 식별합니다 - FD는 X → Y 관계에서 Y의 값을 유니크하게 결정합니다 자세한 내용은 블로그에 정리했습니다 : easy-code-yo.tistory.com/41 🔸 determine의 영어 발음을 왜 '디터ㄹ마인'이라고 하는가? 입에 잘못 붙어서 그렇습니다 ㅠ '디터ㄹ민'이 맞는 발음입니다 참고로 attribute의 발음은 '애트리뷰ㅌ' 입니다 이것도 가끔 제가 '어트리뷰ㅌ'라고 잘못 발음할 때가 있습니다 🔸 15:44 화면에서 오타 정정합니다 ㅠㅠ "과도한 조인과 중복 데이터 최소화 사이에서" -> "과도한 조인과 중복 데이터 사이에서"

[@CortFoxs]

항상 감사합니다 어떤 로드맵을 따라 공부해야할 지 모르고 막막하던 찰나에 쉬운코드님의 내맘내고 덕분에 필요한 지식을 쌓아가는 거 같습니다. 얼마나 잘 알려주시려 노력하시는 지 보이기에 더욱 감사하기만 합니다. 언제나 감사히 생각하는 사람이 있다는 점 알고 힘나셨으면 합니다.

[@ez.]

댓글 읽고 울뻔 했습니다 🥹 많은 에너지를 들여서 영상들을 올리고 있는데 이렇게 말씀해 주시니까 기분좋고 보람차고 뿌듯하고 그렇네요 :) 앞으로도 힘내겠습니다!! 감사합니다!!!! 👍👍👍

[@mindolll]

이렇게 쉽게 깊이있는 내용을 설명하는 채널은 처음 봤어요, 공들인 영상 감사합니다.👍

[@ez.]

헤헤 좋게 봐주셔서 감사합니다 :) 👍

[@한국인-u6i]

책으로 봐도 이해되지 않던 부분을 1,2부 두편을 보니 정확히 이해가 되네요! 너무 유익한 시간이었습니다!!

[@박승균-f5k]

좋은 영상 매번 감사드립니다. CS 핵심 개념들을 되짚어보는데 큰 도움이 되고 있습니다. 목소리톤도 차분하시고 어떻게 하면 이해가 잘 될지 신경을 많이 써주신 것 같으세요. 바로 구독 눌렀습니다!

[@ez.]

와우! 구독 감사합니다 !!! 실무에서 개발을 해보니 컴공이 중요하다는 것을 많이 느껴서 많은 분들이 조금이라도 더 쉽게 이해하실 수 있도록 이렇게 컴공부터 정리해서 올리고 있어요 :) 좋은 말씀 해주셔서 감사합니다 ! 앞으로도 꾸준히 파이팅 해볼게요 !! 👍

[@be-1iever]

두번 돌려보니까 완전 말끔하게 이해됐습니다!! 유익한 강의 감사합니다

[@sunkyoungjin7744]

너무 감사합니다!! 정주행후 따로 또 복습하겠습니다~~

[@ez.]

멋지십니다 👍👍👍

[@aa-tr3vh]

그저 GOAT

[@영삼-f5x]

으아 교수님 FD부터 봤지만, 너무 어려운 내용입니다. 좀 더 공부하고 2회독 해봐야겠습니다.

[@peachpotato6]

덕분에 정규화 이해가 정말 잘됐습니다 감사합니다!

[@myoji5580]

역정규화를 하는 기준을 좀 더 알려주셨으면 좋았겠네요. Join 비용이라던가, 필드에 거의 고정이고 추가되는 것이 거의 없으면 따로 분리를 안한다던가 등요 지금도 훌륭한 강의입니다.

[@이은경-u7g7q]

좋은 강의 감사합니다!!! 너무 잘 듣고 있습니다. 영상 속에서 company를 따로 빼지 않는 역정규화를 하게 되면 뒤에 3nf를 만족하게 수행하더라도 이 테이블은 1nf만 만족하는 테이블이 되는 건지 궁금합니다.

[@박병호-s9e]

감사합니다!😄

[@ez.]

오늘도 정말 최고십니다~! 😊👍

[@윤경식-b9b]

정말 뜨거운 강의 감사드립니다. 제 나름대로 이해한 내용을 간단하게 정리해봤는데, 혹시 확인해주실 수 있을까요? 1정규화: 모든 튜플의 value는 원자값이여야 한다. 2정규화: 키의 부분집합 중 키로서의 역할을 수행하지 못하는 친구는 분리한다. 3정규화: non-prime attribute끼리 fd할 경우 분리한다. B정규화: non-prime attribute가 X가 되어 fd한 관계가 있는 경우 분리한다. 긴 글 읽어주셔서 감사합니다.

[@ez.]

우아 ㅠㅠ 늘 애청해 주시는 것도 감사한데 슈퍼땡스까지!! 정말 감사합니다 ㅠㅠㅠㅠ 대부분 잘 정리해 주셨어요~! :) 여기서 2정규화만 수정하면 좋을 것 같아요~ 2정규화 : non-prime attribute가 key에 대해서 partially dependent 하다면 분리한다 즉, key의 부분집합(정확히는 proper subset)만으로도 non-prime attribute를 FD할 수 있다면 분리한다 이렇게 이해하시면 좋을 것 같습니다 👍 참고로 2정규화 할 때 만약에 해당 테이블에 key가 여러개가 있다면 (참고로 key는 candidate key의 줄임말입니다) non-prime attribute가 그 key들 중에 하나라도 partially dependent 하다면 분리해야 해요

[@윤경식-b9b]

@@ez. 답변 감사드립니다! 말씀해주신 내용 읽고 다시 영상을 봤는데, 저는 partially dependent 하다는 건 해당 키셋에서 부분집합이 key로써의 역할을 할 수 있는 경우를 의미한다고 이해했습니다. 이유는 부분집합이 key 역할을 할 수 있다면 역으로 봤을 때 해당 부분집합에 포함되지 못한 key는 독립적으로 존재했을 때 key로써의 역할을 하지 못하기 때문이라고 생각했습니다. 저번 영상의 예시를 봤을 때도 카드 아이디의 경우 독립적으로 보면 키로써의 역할을 수행할 수 없는 key였습니다. 혹시 제가 이렇게 이해하는 것이 잘못되었나요? 긴 글 읽어주셔서 감사합니다. 제가 많이 부족합니다 ㅠㅠ

[@ez.]

오 아닙니다~ 누구나 부족한걸요~! 저도 많이 부족합니다 ㅠㅠ 어쩌면 제가 잘못 이해하고 설명한 걸수도 있기 때문에, 뭔가 잘 이해가 안되실 때는 언제든지 편히 다시 질문해 주세요 :) 그럼 저도 제 생각을 자세히 말씀드려볼게요~ 우선 몇 가지 정리하고 넘어가자면, 1. partially dependent 개념 자체는 key와는 독립적인 개념이에요 (이 부분은 혹시나 functional dependency 영상을 안보셨다면 보시면 이해가 되실 것 같고요) 2. 이 partially dependent 개념이 2정규화에서 사용되면서 이때 key와 연결지어 사용됩니다 3. 그리고 key의 뜻은, 테이블의 tuple을 항상 unique하게 식별할 수 있는 attributes 집합이면서도, 그 집합에서 attribute를 하나라도 제외하면 더 이상 tuple을 unique하게 식별할 수 없는 attributes 집합을 의미합니다 4. 그렇기 때문에 key의 부분 집합(정확히는 proper subset)은 모두 key로서의 역할을 수행하지 못합니다 (즉, tuple을 unique하게 식별하지 못합니다. 즉, 더 이상 key가 아닙니다) 그러면 본론으로 들어가서, 처음 써주신 댓글에서 2정규화를 아래와 같이 써주셨는데요, >> 2정규화: 키의 부분집합 중 키로서의 역할을 수행하지 못하는 친구는 분리한다. 제가 이 부분에서 어색함을 느꼈던 이유는, (4번에서 정리한 것처럼) 사실 key의 개념에 따르면 key의 부분 집합(정확히는 proper subset)은 모두 언제나 key로서의 역할을 수행하지 못하기 때문입니다 예를 들어, 선수 정보를 저장하는 Player 테이블의 스키마가 아래와 같다고 해볼게요~ Player {team_id, back_number, name, birthdate} 이때 key는 {team_id, back_number}가 됩니다 왜냐하면 같은 팀 안에서는 등번호가 unique하고 team_id는 각 팀별로 unique 하니까, {team_id, back_number}로 key를 구성하면 해당 테이블의 선수 정보를 unique하게 식별할 수 있기 때문이죠 그런데 적어주신 2정규화 개념대로라면, key의 부분집합인 {team_id}와 {back_number}는 key로서의 역할을 수행할 수 없기 때문에 이 둘을 분리를 해야하는데요, 사실 2정규화의 FM대로라면 이 둘은 분리를 하면 안됩니다 왜냐하면 team_id나 back_number 각각은 독립적으로 non-prime attribute인 name이나 birth_date를 functionally determine할 수 없기 때문에, name이나 birth_date는 둘 다 key인 {team_id, back_number}에 대해서 (partially가 아니라) fully functionally dependent 하고 있어서 2정규화를 이미 만족하고 있기 때문이죠 그래서 2정규화의 개념을 FM대로 정확히 말씀드리는게 좋겠다는 생각이 들었고 아래와 같이 쓰게 됐어요 >> 2정규화 : non-prime attribute가 key에 대해서 partially dependent하다면 분리한다 즉, key의 부분집합(정확히는 proper subset)만으로도 non-prime attribute를 FD할 수 있다면 분리한다 너무 자세히 설명드려서 오히려 부담을 드린건 아닌지 모르겠네요 최대한 잘 설명드리고 싶은 마음에 글이 길어졌다 정도로 예쁘게(??) 봐주시면 좋겠습니다 :) p.s. 영상 예제를 바탕으로 설명글도 썼었는데 너무 글이 길어져서 그 부분은 일단 삭제 했습니다 복사를 해두었기 때문에 필요하시면 드릴 수 있습니다 👍

[@윤경식-b9b]

@@ez. 오히려 굉장히 자세하게 설명해주셔서 감사합니다! 제가 이해를 잘못한 것 같았는데, 이제는 이해한 것 같습니다. 매번 고퀄리티의 강의 감사합니다!!

[@ez.]

@@윤경식-b9b 저도 항상 애청해 주셔서 감사합니다 😊👍

[@김민지-n6t3e]

정규화에 대해 자주 듣긴 했는데, 어려운 개념이라고 느껴져서 공부를 미루다가 이 영상을 통해 용기를 얻었습니다! 영상 잘 봤습니다, 감사합니다.👍 영상 중간중간에, 교과서에서 '~하게 설명이 있다.' 라는 말씀을 하셨는데, 여기서 교과서는 컴공과의 전공서적을 말씀하시는건가요? 시중에서 구할 수 있는 교과서라면 저도 한번 봐보고 싶어서 질문 드립니다!

[@ez.]

크!! 1부 2부 모두 유익하게 봐주셔서 감사해요 :) 네 맞습니다~ 컴공과에서 사용하는 교과서를 얘기하는 건데요, 제가 학부 때 썼던 교과서는 오래된 책이었고 어디 있는지도 몰라서 대학원에서 썼던 교과서를 틈틈히 참고했어요 books.google.co.kr/books/about/Database_Systems.html?id=NRsCQwAACAAJ&redir_esc=y 이 책인데요, 그런데 제 개인적으로는 이 책이 추천할 정도는 아닌거 같아요 ㅠ 개념 설명을 무미 건조하게 쭉 설명하기 때문에 잘 읽히지도 않고 설명도 이해하기 쉽게 써진 책이 아니라서요 ㅠ

[@jjumen]

좋은 영상 만들어주셔서 감사합니다. 질문이 하나 있습니다. 9:25 BCNF 설명해주실 때 데이터 테이블인 ACCOUNT_CLASS의 경우 테이블 대신 enum으로 관리해도 좋을까요? 이럴 경우 따로 테이블을 생성하지 않아도 될까요?

[@한준규-c2q]

추가적으로 마지막 설명에 과도한 조인과 중복 데이터 최소화 사이에서 적정 수준을 잘 선택할 필요가 있다고 하셨는데, 과도한 조인 = 테이블이 분리되어있음 중복 최소화 = 테이블이 분리되어 있음(정규화되어서) 결국 같은말이 아닌가 싶어요 ! 과도한 조인과 데이터 중복 사이에서라는 말이 혹시 더 어울리지 않을까 조심스레 말씀드려봅니다..!

[@ez.]

헉 그렇네요~! 이건 제가 잘못 썼습니다 알려주셔서 감사합니다 :)

[@parkpark3394]

안녕하세요. 영상 잘 보고 있습니다. 정규화를 열심히 공부하고 있는데요. 궁금한 점이 생겨서 여쭙니다. R(A, B, C, D)가 있고 이 릴레이션의 종속성이 {AB→C, AB→D, C→A, D→B}라고 하면 우선 후보키가 {A,B}, {A,D}, {B,C}, {C,D}가 나오게 되는데 이때 AB→C, C→A 관계에서 C와 A가 키의 부분집합이 되니까 이행함수 속성이 존재하지 않아 3NF를 자연스럽게 만족하게 되나요? 만약 아니라면 3NF로는 어떻게 분해가 될까요? 추가적으로 BCNF로도 분해가 된다면 BCNF상태의 릴레이션도 궁금합니다.

[@ez.]

안녕하세요~! 항상 영상을 애청해 주셔서 감사합니다~! 질문주신 부분은 양해를 구해야할 것 같습니다 채널 운영 정책 상, 영상과 직접적으로 관련있지 않은 질문들은 답변을 드리지 않고 있습니다 ㅠㅠ 여러 사정 상 모든 질문에 답변드리기가 어려움이 있어서 그렇습니다 ㅠ 그래서 첫번째 질문만 답변드리면 네, 맞습니다~ 3NF를 자연스럽게 만족하게 됩니다

[@parkpark3394]

네 그럼에도 불구하고 답변을 주셔서 감사드려요! 힌트를 주신 덕분에 해당 개념을 명확히 이해할 수 있었습니다~

[@한준규-c2q]

안녕하세요! 강의 잘 듣고 있습니다. 질문이 하나 있는데 여쭤봐도 될까요?? 중간에 제약사항은 어떠한 이유로 존재하는건가요?? 제약사항을 무시하고 후보키의 부분집합을 데려다가 3NF를 해버리면, 기존 후보키가 사라지게 되어서 그런가요? 만약 이런거라면 기본 후보키가 사라지면 어떠한 단점이 있는건가요?? ㅎㅎ 답변해주시면 감사하겠씁니다 : )

[@ez.]

그 부분은 저도 찾아봐야할 것 같아요~ 3NF를 정의한 분이 왜 그런 조건을 넣었는지를요

[@한준규-c2q]

@@ez. 앗 넵 저도 찾아보겠습니다 :)

[@정다운-k9k]

unique 하게 식별할 수 있는 여부를 빠르게 아는 방법이 있을까요? 이 부분이 제일 헷갈려서요..

[@hyeonsu-hl2ff]

그건 해당 컬럼의 성격에 따라 다르다고 생각합니다. 보통 채번을 통한 id 값이 있고 uuid가 될 수도 있겠죠 그 값이 해당 컬럼 내에서 '유일'하다면 유니크 한거죠

[@데브훈]

안녕하세요, 질물사항이 있어서 댓글 남깁니다. 3NF 정규화할 때 | bank_name | account_num | account_id | class | ratio | , | empl_id | account_id | empl_name | 구성으로 테이블을 정규화해도 괜찮을까요? 두 번째 테이블의 account_id는 외래키로 사용하는 것으로 하겠습니다.!

[@ez.]

안녕하세요 :) 질문에 답변드리면, 그렇게는 정규화 하면 안될 것 같아요~ㅠㅠ 우선 두번째 테이블에서 unique하게 tuple을 식별할 수 있는 attribute는 account_id 하나 뿐이기 때문에, (account_id는 외래키로 사용하겠다고 하셨지만) 원하든 원치않든 account_id는 두번째 테이블에서 key로서의 정체성을 가지게 됩니다 (empl_id는 key가 될 수 없습니다. 왜냐하면 한 임직원이 여러 개의 account를 가질 수 있기 때문입니다) 한편 두번째 테이블에서 여전히 account_id -> empl_id, emp_id -> empl_name 이렇게 두 개의 FD가 존재하고 있습니다 그러면 결국 nonprime attribute인 empl_name이 key인 account_id에 transitively dependent 하게 돼서 3NF를 위반하게 됩니다

[@runalex]

학부떄도 그랬지만 정규화는 너무 어렵다. 감으로는 알겠는데 이걸 이론적으로 표현하는게 항상 어려움