김영한의 실전 데이터베이스 - 설계 1편, 현대적 데이터 모델링 완전 정복

마지막에 professor_name을 pk로 두고 그에 따라 1:1이기때문에 과목명을 그냥 컬럼으로 두셨는데 그러면 그 과목명이 만약에 바뀐다면 (데이터베이스 -> DB) 그렇다면 데이터베이스 수업을 하는 모든 교

안녕하세요! 연관 엔티티의 네이밍 기준(연결 강조 vs 의미 있는 이름)에 대한 강의를 듣고 고민이 생겨 질문드립니다. 강사님의 조언대로 처

대충 빨리 듣고 필요한것만 정리 하고 넘어가고 싶은데 어렵고 지루하고 졸리고

28강 sql 파일 어딨나여?

2NF를 충족하기 위한 조건은 다음과 같은 것으로 알고 있습니다.제1 정규형을 만족하고,<p style="text-align

안녕하세요. 식별 vs 비셕별에 대한 db 설계 관련 내용 중에 영한님께서 일대다의 경우인 board 테이블(one)과 comment(many)에서 board 테이블의 id가 식별관계로 사용되는 경우 comment의

안녕하세요 학습중인 수업자료를 받아볼 수 있을까요??

이번 강의의 수업자료 pdf 보니, 제목 클릭 시 링크위치가 각 챕터가 아닌, 마지막 페이지 정리 내 제목들로 이동합니다.<p style="text-ali

안녕하세요 영한님! 기초부터 설계까지 영한님의 강의 덕분에 실무에서 테이블을 설계할 때 큰 자신감을 얻고 있습니다. 늘 감사드립니다.강의를 듣고 운영 중인 서비스의 ERD를 검토해보니 과거

안녕하세요. 질문이 있습니다!! <span style="color: #212

db의 슈퍼/서브 타입으로 설계된 부분을 보면 joined 전략으로 했을 경우 어쩔 수 없이 식별 관계로 해야하는 경우가 있던데 이럴 경우 sigle table 전략으로 푸는 게 나은 것 같으세요? 아니면 어쩔 수 없이

안녕하세요, 강사님. 이번 강의를 듣고 2가지 궁금증이 생겨 질문을 올리게 되었습니다.created_at과 upd

이런 식으로 실무적으로 접근했을 때 이 강의에서 예시를 들어주셨던 것처럼 (학생, 과목, 수강), (사용자, 영화, 평가) 엔티티를 개념적 모델링 단계에서 먼저 설계를 할텐데, 이때 설계 순서가 궁금합니다.

자연키를 기본키로 설정했을 때 발생할 수 있는 문제점에서 데이터의 역사성 훼손을 예로 들었는데 이 문제는 대리키를 기본키로 등록했어도 발생할 수 있는 문제 아닌가요?이 문제를 해결하기 위해서는 어쩔 수 없이 주문

실무에서 등록일,수정일, 등록자, 수정자 4개 컬럼을 테이블 별로 만들어서 쓰라고 하셨는데1) 모든 테이블에 4개 컬럼은 만든다 생각해도 되는지?2) 유지보수 상 운영 테이블을 직접 수정하는

이번에 설계 1편에서 자연 키와 대리 키 부분을 학습하면서,최근 구글이 이메일 변경을 부분적으로 검토하고 있다는 뉴스가 떠올랐습니다.예전에는 이메일 변경이

안녕하세요. 항상 좋은 강의 잘 듣고 있습니다. 다름이 아니라, 강의 및 강의 자료에 누락된 부분이 있는 것 같아 글 남깁니다.[물리적 모델링 - 실습] 파트에서 테이블 정의서 및 DDL 스크립트를 작성하

professor_bcnf, enrollment_bcnf로 테이블을 분리하는 과정에서 질문이 있습니다.  이전에 이름과 같은

"실전 개념적 모델링 - 시작" 파트를 들으면서 궁금한 점이 있어 질문드립니다. 주문, 결제 엔티티의 경우, 주문은 '결제'까지 포함하는 비

실무에서도 복수 항목에 대해서 원자성을 고려해 테이블을 분리하는지 궁금합니다. 예를 들어, 카드 정보라는 테이블이 있을 때, 혜택이라는 컬