데이터 모델링

데이터 모델은 현실 세계의 정보나 데이터를 시스템으로 구축하기 위해 추상화하여 체계적으로 표현한 모형이다.

출처 : 핵심 데이터 모델링 (저자 : 유동오)

출처 : 핵심 데이터 모델링 (저자 : 유동오)

접근 방식

어떤 방식이든 프로젝트 관련자들과 중간 과정을 공유하고 의견을 반영하는 것이 반드시 필요하다

• 하향식(Top-Down) : 전체 데이터를 큰 개념으로 분할하고 단위 개념을 식별하면서 정의해 나가는 방식. 보통 큰 규모 프로젝트에서 사용한다
• 상향식(Bottom-Up) : 관리해야 할 데이터 항목들을 조사한 후, 이에 따라 데이터 모델링을 진행하는 방식. 비교적 작은 규모 프로젝트에서 사용한다

하향식은 많은 경험과 업무 지식이 필요하다

현행 분석 및 방향성 수립

• 현업담당자와 협업
• 문서를 통한 업무 요건 파악
• 리버스 모델 활용 : 현행 ERD가 없어 DB 메타정보를 활용하여 엔티티 및 속성, 관계를 도출하는 것. Erwin 이라는 프로그램을 사용하여 리버스 모델링을 할 수 있다
  ERD가 있는 것이 가장 좋지만 없는 경우가 많다

데이터 모델의 종류

• 개체관계(ER) 모델 : 개체와 개체 간의 관계를 표현
• 관계 모델
• 계층 모델
• 망 모델

대부분 ER 모델을 사용한다

ER 모델

구성요소

Entity

현실 세계에 실제로 존재하는 실체 또는 개념
* 실체 : 고객, 상품, 직원
* 개념 : 조직, 서비스, 직업

엔티티의 조건

• 적어도 둘 이상의 인스턴스가 존재할 수 있어야 한다
• 최소한 둘 이상의 속성이 있어야 한다
• 각 인스턴스를 식별할 수 있는 속성이나 관계가 하나 이상 정의되어야 한다

엔티티 정의하기

• Generalization : 하위 수준 엔티티를 결합하여 상위 수준 엔티티로 통합
• Specialization : 상위 수준 엔티티를 두 개 이상의 하위 수준 엔티티로 분할
• Aggregation : 한 엔티티가 다른 엔티티를 포함하지만, 완전히 종속되진 않는 느슨한 포함 관계
  aggregation은 ERD 상 개념이고 실제 테이블에서 FK로 구현된다

Relationship

엔티티와 엔티티 간에 존재하는 업무 규칙을 정의하고, 엔티티 간에 어떤 관계가 이루어질 수 있는지 표현

구성요소

• Cardinality : 엔티티 인스턴스 하나가 다른 엔티티 인스턴스 몇 개와 대응되는지 표현 (최대 인스턴스 수)
  1 : 1, 1 : M, M : N

• Optionality : 해당 엔티티 인스턴스에 대해 상대 엔티티에 인스턴스가 반드시 존재해야 하는지 표현

• Identifier Inheritence : 다른 엔티티의 식별자를 상속받을 때, 식별자로 받을지, 일반 속성으로 받을지 표현
  즉, 해당 테이블에서 FK가 PK인지 아니면 일반 컬럼인지에 따라 구분한다

• Relationsip Name : 관계 이름

Attribute

데이터를 표현하는 가장 작은 단위

구성요소

• 속성명 : 속성의 이름

• 식별자 여부 : PK 인지 아닌지

• Optionality : Not Null 인지 아닌지
  이외에 Conditional로 구분할 때도 있는데, Conditional은 특정 조건에 대해서 값을 가져야 할 때이다. 실제로 구현할 때는 어플리케이션 로직, 트리거, CHECK 제약 조건 등을 이용해서 구현할 수 있다

• Domain : 속성이 허용하는 데이터 형식과 범위. 즉, 속성의 자료형과 제약 조건(값의 범위)을 말한다

Identifier

엔티티에서 인스턴스를 개별적으로 식별할 수 있는 속성

특징

• 유일성 : 인스턴스를 유일하게 식별할 수 있어야 한다. 중복 X
• 최소성 : 유일성을 만족하는 최소 속성들로 구성해야 한다
• 불변성 : 식별자 값이 변하지 않아야 한다
• 존재성 : 반드시 데이터 값이 존재해야 한다. Not Null

고유 속성 여부에 따른 종류

• 본질 식별자 : 실세계에서 일반적으로 통용되는 식별자
• 인조 식별자 : 데이터 관리를 위해 별도로 추가한 식별자

가능하면 본질 식별자를 사용하는 것이 좋지만, 인조 식별자를 사용하는 경우가 더 많다

대표성 여부에 따른 종류

• 주 식별자 : 주 식별자로 지정한 식별자
• 대체 식별자 : 주 식별자 외의 식별자

관계형 데이터 모델

관계형 데이터 모델 : 데이터를 2차원 테이블 형식으로 정의하고 표현한 모델
Relation : 데이터를 표현한 2차원 테이블. 릴레이션 스키마(테이블 헤더)와 릴레이션 인스턴스(tuple)로 구성된다

릴레이션 스키마는 릴레이션명과 어트리뷰트로 구성된다
어트리뷰트는 더 쪼갤 수 없는 원자 값으로 구성된다

튜플은 모두 다른 값을 가지며 중복된 튜플을 허용하지 않는다. 또한, 순서와 무관하다 (Set)

Key

• Super Key : 튜플을 고유하게 식별할 수 있는 속성 집합
  = 유일성 O
• Candidate Key : 튜플을 고유하게 식별할 수 있는 최소한의 속성 집합
  = 유일성 O, 최소성 O
• Primary Key : 후보키 중 지정된 기본키
• Alternate Key : 기본키가 아닌 후보키
• Foreign Key : 다른 릴레이션의 기본키를 참조하는 키

Constraints

• Key Constraint : 중복 X. 위의 모든 키에 해당하는 제약조건
• Entity Integrity : 기본키는 Not Null 이고 오직 하나의 값만 존재해야 한다. 기본키에만 해당하는 제약조건
• Domain Integrity : 어트리뷰트 값은 정의된 도메인에 속한 값이어야 한다
• Referencial Integrity : 자식 릴레이션의 외래키는 부모 릴레이션의 기본키 값 이외의 값을 가질 수 없고 두 릴레이션 값의 일관성을 유지해야 한다

Functional Dependency

함수 종속성 : 어떤 릴레이션 R에서 속성 X의 값 각각에 대해 속성 Y의 값이 오직 하나만 연관되어 있을 때 Y는 X에 대해 함수적으로 종속되어 있다고 한다 (X→Y)

예시 : 고객번호 → (고객명, 생년월일, 전화번호, 주소)

종류

• Full Functional Dependency : X에 대해 Y가 함수적으로 종속되어 있지만, X의 부분 집합에 대해서는 종속되지 않은 경우
  예시 : (주문번호, 상품코드) → (주문수량) 일 때, (주문번호) → (주문수량) 또는 (상품코드) → (주문수량) 은 아닌 경우

• Partial Functional Dependency : 완전 함수종속이 아닌 경우
  예시 : (주문번호, 상품코드) → (상품단가) 일 때, 상품코드 → 상품단가 는 종속되어 있다

• Transitive Functional Dependency : X → Y, Y → Z 일 때, X → Z 가 성립한다. 이 때 속성 Z는 X에 대해 이행적 함수종속성을 갖는다고 한다
  예시 : (주문번호) → (고객번호), (고객번호) → (고객명) 이면 (주문번호) → (고객명) 이다

Normalization

정규화 : 이상(Anomaly) 현상을 최소화하기 위해 좀 더 작은 단위의 테이블로 설계하는 과정

이상 현상

• Insertion Anomaly : 새로운 데이터를 추가할 때 불필요한 다른 정보도 같이 입력해야만 하는 문제
  예시 : 새로운 동아리를 등록할 때, 학생 정보도 같이 등록해야 됨 → 가입한 학생이 없는 동아리를 등록할 수 없다
• Deletion Anomaly : 하나의 데이터를 삭제할 때, 관련 없는 정보까지 함께 삭제되는 문제
  예시 : 위 예시에서 학생 정보를 삭제하면 동아리 존재 사실 자체가 삭제된다
• Update Anomaly : 하나의 값을 수정할 때, 중복된 모든 값들을 일일이 수정해야 하는 문제
  예시 : '철수'가 동아리 3개를 하고 있는데, '김철수'로 바꾸려면 3개 튜플을 다 변경해야 한다

Normal Forms(정규형)

제1정규형

모든 속성이 원자값을 가져야 한다. 즉, 중복 컬럼과 다중 값을 제거하는 것이다

예시
중복 컬럼 : 전화번호1, 전화번호2 와 같이 의미적으로 같은 컬럼 → 전화번호 테이블을 따로 만든다
다중 값 : 전화번호 컬럼 안에 두 개의 전화번호가 들어있는 경우 (010-1234-5678, 010-1111-2222) → 전화번호 테이블을 따로 만든다

하지만 전화번호도 세 부분으로 더 나눌 수 있는 것 아닌가?
원자성에 대해 이 부분이 모호할 수 있는데, 정의된 규칙은 없고 업무에 따라 선택하면 된다. 전화번호의 예로 봤을 때, 이 데이터를 사용하는 프로그램에서 항상 파싱을 해서 사용하는 경우이면 컬럼을 나눠서 저장하는 것이 좋고 아니면 하나의 컬럼으로 저장하는 것이 좋다

제2정규형

제1정규형을 만족하면서 부분 함수종속을 제거한 것

기본키가 복합키인 경우에만 해당된다

제3정규형

제2정규형을 만족하면서 이행적 함수종속을 제거한 것. 즉, PK에 의해서만 다른 컬럼들 값이 결정되어야 한다
→ 사실, BCNF에는 맞는 말이지만 3NF에는 완전히 들어맞진 않는다

BCNF(Boyce-Codd Normal Form)

제3정규형을 만족하면서 모든 결정자가 후보키인 것. 즉, 다른 컬럼들 값을 결정하는 결정자는 유일성과 최소성을 만족해야한다
→ PK는 유일성과 최소성을 만족해야한다

3NF vs. BCNF

조건	3NF 만족?	BCNF 만족?
결정자가 기본키(PK)	✅	✅
결정자가 후보키 (PK 아님)	✅	✅
결정자가 후보키도 아님	✅ (조건부)	❌

* 조건부 : 종속되는 속성 B가 후보키의 일부일 때만
* 후보키의 일부 : 후보키가 복합키일 때 그 속성 중 하나인 경우

제4정규형

Multi-valued Dependency 제거
Multi-valued Dependency : 하나의 키에 대해 서로 독립적인 여러 값이 종속될 경우

예시
(직원명, 기술, 프로젝트) 컬럼이 있을 때, 기술과 프로젝트는 관련이 없지만 데이터가 반복해서 들어가는 상황

직원명	기술	프로젝트
철수	Java	프로젝트A
철수	Python	프로젝트A
철수	Java	프로젝트B
철수	Python	프로젝트B

제5정규형

Join Dependency 제거
Join Dependency : 비손실 조인이 불가능한 구조

테이블을 여러 개로 분해한 후 다시 조인했을 때 원래 데이터가 정확히 복원되어야 하며,
조인을 해야만 알 수 있는 의미 없는 중복 정보는 제거해야 한다

예시
아래 테이블을 (프로젝트-공급자), (프로젝트-부품), (공급자-부품) 의 세 테이블로 쪼개지 말고 함께 써야한다

프로젝트	공급자	부품
P1	S1	A
P1	S1	B
P1	S2	A

Trap

• Connection Trap
• Fan Trap
• Chasm Trap