<김기창의 데이터 모델링 강의>(1장~3장) 내용을 기억하기 위한 글

매타드란? 저자가 전달한 의미에 내가 어떻게 받아들였는지 또는 머릿속에 스치는 나만의 예제를 반영.

<나는 나의 스무살을 가장 존중한다>에서 사용하는 meta word 의 줄임말 메타드를 저만의 단어로 사용합니다.

<제 1장>

기본개념. 저자가 많이 사용하는 단어

실체엔티티란?

관계가 속성이다? (속성은 컬럼을 뜻함.)

집합개념?

실체엔티티 중요한 이유: 모델 구조적으로 최상위에 존재하기 때문.

도서관에 존재하는 '책'은 실체지만 '도서'는 실체가 아니다. 왜냐? 책이 몇만권이 발행되었든 상관없이 도서정보는 하나이다.

예제로 나오는 상품 엔티티가 모두 실체 엔티티는 아니라는 것. 실체를 의미할 때도 있고, 실체를 나타내는 기본 정보를 의미할 때도 있다.

실체라고 생각하는 것은 실체를 나타내는 개념이나 역할을 의미할 수도 있다. (고객이자 사원 역할을 하는 것처럼. -> 한 사람이 두 역할이란 이유로 두 사람이 될 수는 없는 법)

실체개수와 엔티티 인스턴스 개수를 같게 유지해야하므로 변경이력 같은 건 다른 테이블에서 관리

 

주식별자

= pk(식별번호 같은것)

실체 엔티티의 주 식별자가 여러 속성으로 구성된다면, 가독성 down, 관리 힘들고 잘못된 설계로 이어질 가능성

-> 실체엔티티는 최상위 엔티티니까 !

실체엔티티나 행위엔티티를 제외한 엔티티들은 명사형으로 정의.(ex - 회원탈퇴 x, 탈퇴회원 o)

-> 쉽게 생각하기 ! ~했음 과 같은 동사를 뒤에 붙였을 때 자연스러우면 , 실체 엔티티의 이름으로 적절하지 않은 것.

​

🐥 메타드 : 실체엔티티가 무엇을 의미하는 지는 알겠지만, 단어가 좀 낯선 느낌이다. 계좌 같은 것도 실제 존재하지 않지만, 관리측면에서 실체 엔티티라고 한다. 그냥 너무 당연한 소리를 하는 느낌이다. 고객이나 사원도 사람이니 당연히 실체 엔티티인데 , 말을 어렵게 하는 경향이 있다. 자신만의 세계에 빠져있는 인물 같긴한데 , 들어주자 한번

​

​

<제 2장 - 실제엔티티의 사촌. 기준엔티티>

• 사람을 관리하는 실체엔티티와 역할을 관리하는 기준엔티티.(한사람이 사원이면서 고객이기도 할 때 기준엔티티를 사용)
• 실체엔터티는 보이는 것을 관리, 기준엔티티는 개념적인 것을 관리한다.
• 상품분류나 우편번호 데이터도 기준엔티티. 추상적인 엔티티.
• 기준엔티티는 주 식별자가 인조식별자가 아닌, 복잡한 식별자를 사용.
  
  • 예시 ) 수수료율 같은 경우 거래소에 따라서, 상품유형에 따라, 등등 수수료율이 다 달라질 수 있다. 말그대로 수수료율을 정하는 업무기준에 따라 식별자는 얼마든지 달라짐. 따라서 주 식별자를 (거래소, 상품유형) 이렇게 정의할 수 있다.

🐥 메타드: 우리가 자주쓰는 식별자 id 는 인조식별자(Artificial Identifier)라고 하는구나. (getById 와 같은 orm 라이브러리로 인해 일반적으로는 id 를 pk 로 사용하는 컨벤션이 있다. 이 때 id 를 인조식별자라고 함.)

 

참조무결성

참조무결성 문제.

user <-> group 사이에 참조무결성은 어떻게 되나? 두 엔티티간에 참조무결성 제약이 존재하지 않으면, 기준엔티티 값의 변화가 하위 엔티티에 영향을 미치지 않게됨. 예를들어 우편주소 엔티티, 고객 엔티티가 있을 때, 고객엔티티는 우편주소 엔티티의 주 식별자 인 (우편번호, 우편번호순번) 을 가지고 있다. 우편주소를 변경해도 해당 고객은 시점의 주소를 보관하고 있으며, 우편주소와 실제 관계가 없다. (=업무의 변경이 일어나지 않는다)

​

​

참조무결성 관계가 존재하도록 설계할 지 판단하는 기준

• 입력 당시의 속성을 가지고 있어야하냐 아니냐
• 단순히 두 엔티티 간 관계가 존재할 것 같아서 관계선으로 관리하는 것을 지양하라.

​

기준엔티티 통합 의미 2가지

• 엔티티를 통합한다.
• 업무의 기준이 되는 속성들을 하나의 엔티티에서 통합관리한다.

​

도서엔티티 -> 기본정보 관리

환율엔티티 -> 기준정보 관리

​

엔티티 종류 실체, 기준, 행위, 가공 엔티티 네가지.

실체, 기준, 행위, 가공 엔티티 네가지 는 실무에서 정의하는 것이 아님. 엔티티 성격을 알기 위해 하는 구분일뿐이다 !

​

행위엔티티: 행위에 의해 발생한 데이터 . (압도적으로 많음, 발생순서 존재, 일정기간이 지나면 특정 인스턴스 미사용)

🐥 메타드: b2b 관리자가 자사의 임직원들한테 제공할 강의를 전체 강의에서 선택하는 것은 행위엔티티로 정의하는가?

​

가공엔티티: 집계, 요약, 임시 엔티티 등

다른엔티티와 관계가 발생하지 않음.

집계엔티티는 집계를 하려는 기준이 주 식별자임 -> 인조식별자 사용할 때도 있지만 흔치 않음.

메타드)

🐥 메타드: 당연한 소리를 명확하게 정의했다고 생각함. 집계 엔티티에는 id가 없어도 되겠다.

​

저자의 팁) 색상으로 엔티티 성질을 구분해놓으라.

실체엔티티는 몇개 없으니까 노란색으로 관리.

실체와 유사한 기준엔티티는 초록색으로 관리.

대부분이 행위엔티티이므로 색을 칠하지 않지만(대부분은 행위엔티티이므로 흰색으로 그대로 둠), 강조하고 싶은 행위엔티티만 하늘색.

​

각 엔티티는 성격별로 분리되어야한다. ex) 행위엔티티는 행위엔티티의 성격만을 가지고있어야한다.

⚠️ 실체엔티티는 다른 엔티티와 혼합해서 사용하면 치명적이니 주의하라.

​

🐥 메타드: 예제가 있긴 한데, 책에 중간중간 문제가 하나 있으면 좋겠다. 실제엔티티와 기준엔티티, 행위엔티티를 구분하는 문제라든지.. 풀어볼 수 있는 문제 헷갈리는 개념을 설명할 땐 퀴즈만 한 게 없음! 

​

​

<제3강 - 식별자 상속의 시발점. 종속 엔티티>

설계 엔티티 정의 순서

1) 실체엔티티

2) 자립엔티티

​

자립엔티티와 종속엔티티

데이터 간 관계에 따라 자립, 종속 엔티티로 구분한다.

자립엔티티와 종속엔티티는 CASE 툴에서 달리표현된다. ex) 일반적으로 자립이 완전 네모, 종속엔티티는 둥근네모.

이해 tip !) 자립엔티티가 압도적으로 많음. 종속엔티티를 이해하는게 더 쉬움. 종속엔티티가 아니면 자립엔티티이기 때문.

​

종속엔티티

• 종류로는 존재종속과 함수종속, ...
• 존재종속: 단순히 밀접한 연관관계가 아닌, 두 데이터 자체 가 태생적으로 연결된 것.
• ex) 상품과 상품가격. 상품엔티티가 없으면 상품가격엔티티 존재 불가.
• 설계 예제 ) 가격은 상품 자체 특성이라 상품엔티티에서 속성으로 관리해도 되는데 매일 변하기 때문에 별도의 엔티티에서 관리. 1정규화에 의해 생성되는 별도의 엔티티

🐥 메타드: 가격에 대한 시점이 중요할까? 그렇다면 가격변동을 보관해야하니까 product_price 엔티티가 따로 있어야하지 않을까 , 주문정보에 가격이 들어가면 안되나? 구매 가격의 할인정보 등 정보를 같이 가지고 있어야할 수도 있겠다.

테이블정보: pk (상품번호, 기준일자), 상품가격

​

🐥 메타드: 1정규화 , 2정규화, 3정규화 대학생 때 배웠던 기억이 새록새록

​

다대다 관계

다대다 관계는 관계형 데이터베이스에서 구현할 수 없는 관계이므로 교차엔티티를 설계하여 다대다 관계를 해소한다.

주문번호entity - pk(id) ,주문일자, 배송주소

주문상품entity - pk(주문번호, 상품번호)

상품entity - pk(id), 상품명, 상품가격

 

​

상위엔티티와 부모엔티티 용어 구분하기

존재종속되어야 부모엔티티라고 표현.종속관계는 주식별자와 연결된다.

​

​

종속관계에 대해서

관계는 종속관계, 참조관계로 분류.

관계는 데이터성격 자체에서 생긴관계와 업무요건(기획정의)에 의해 생긴 관계가 있다.

종속관계 중에는 업무요건에 의해 생긴 관계가 있다.

종속관계는 종속 엔티티보다 느슨하며 범위가 넓다.

업무종속관계: 업무(기획 정의)에 의해 생긴 종속관계. 예를들어 리그 없이 구단이 존재할 수 있는 지 없는지를 기획 상 정의할 수도 있다.

존재종속관계: 종속엔티티에 의해 생긴 종속관계

참조관계: 단지 연관성을 관리하려는 관계. 관계를 삭제하더라도 속성에 대한 연관성을 모르게됨.

​

​

식별자 상속 (식별관계와 비식별관계)

( 주식별자로 상속 vs 일반속성으로 상속 ) 에 따라 식별관계와 비식별관계로 구분.

🐥 메타드: 상속된 엔티티의 식별자 중에 부모엔티티의 주 식별자가 있냐 없냐. 예를들어 상품과 상품가격

상품가격의 주 식별자에 상품번호가 있으면 식별관계, 아니면 비식별 관계.

간단원칙 !! 두 엔티티가 종속관계일 때는 식별 관계, 참조관계일 때는 비식별 관계로 설계하기. 반대 예외는 있다.

⚠️ 하지만 주의할 것 !! 참조관계를 식별관계로 상속하는 것을 피해야한다. 그렇게 했다간 예외없이 망한다!!

업무종속관계는 업무변경 가능성을 판단하기 ! -> 식별일 수도, 비식별일 수도.

​

데이터의 성격만으로 엔티티를 명확히 정의하라 !