[SQLD] 데이터 모델링의 이해

*본 포스트는 '유선배 SQL개발자 과외노트' 도서를 참고하여 작성되었습니다.

01. 데이터 모델의 이해

---

모델링이란?

데이터베이스의 모델링은 현실 세계를 단순화하여 표현하는 기법

 

모델링이 갖춰야 할 조건

• 현실 세계 반영
• 단순화하여 표현
• 관리하고자 하는 데이터를 모델로 설계

 

모델링의 특징

1. 추상화
   • 현실 세계를 일정한 형식으로 표현
   • 아이디어나 개념을 간략하게
2. 단순화
   • 복잡한 현실 세계를 정해진 표기법으로 단순하게 쉽게 표현
3. 명확화
   • 불분명함을 제거하고 명확하게 해석할 수 있도록 기술

 

모델링의 세 가지 관점

1. 데이터 관점
   • 어떤 데이터들이 업무와 얽혀 있는지, 데이터 간의 관계가 어떤지에 대해 모델링
2. 프로세스 관점
   • 이 업무가 실제로 처리하고 있는 일은 무엇인지 또는 앞으로 처리해야 하는 일은 무엇인지를 모델링
3. 데이터와 프로세스의 상관 관점
   • 프로세스의 흐름에 따라 데이터가 어떤 영향을 받는지 모델링

유의할 점

• 중복
  • 같은 데이터가 여러 엔터티에 중복으로 저장되는 현상 지양
• 비유연성
  • 데이터 모델의 설계에 따라 애플리케이션의 사소한 변경에도 데이터 모델이 수시로 변경되어야 하는 상황이 발생할 수 있다.
  • 이 상황은 시스템 유지보수에 어려움을 가중시키기 때문에 데이터 모델과 프로세스를 분리하여 유연성을 높여야 한다.
• 비일관성
  • 데이터 중복이 없는 경우에도 비일관성이 발생할 수 있다.
  • 개발자가 다른 데이터와의 연관성을 고려하지 않고 일부 데이터만 변경하면 생기는 문제이다.
  • 이 문제 발생을 방지하기 위해 데이터 모델링을 할 때 데이터 간의 연관 관계에 대해 명확히 정의해야 한다.

 

모델링의 세 가지 단계

1. 개념적 데이터 모델링
   • 전사(회사 전체 차원)적 데이터 모델링 수행 시 행해진다.
   • 추상화 레벨이 가장 높은 모델
   • 업무 중심적, 포괄적 수준의 모델링
2. 논리적 데이터 모델링
   • 재사용성이 가장 높은 모델링으로 데이터베이스 모델에 대한 Key, 속성, 관계 등을 모두 표현하는 단계
3. 물리적 데이터 모델링
   • 실제 데이터 베이스로 구현할 수 있도록 성능이나 가용성 등의 물리적인 성격을 고려하여 모델을 표현하는 단계

 

데이터의 독립성

애플리케이션에 영향을 주지 않고 데이터베이스의 구조를 변경할 수 있어야 독립성이 보장된다고 본다.

 

3단계 스키마 구조

1. 외부 스키마
   • 사용자의 관점: Multiple User’s View 단계로 각 사용자가 보는 데이터베이스의 스키마를 정의
2. 개념 스키마
   • 통합된 관점: Community View of DB 단계로 모든 사용자가 보는 데이터베이스의 스키마를 통합하여 전체 데이터베이스를 나타내는 것
   • 데이터베이스에 저장되는 데이터들을 표현하고 데이터 간의 관계를 나타낸다.
3. 내부 스키마
   • 물리적인 관점: Physical Representation 단계로 물리적인 저장 구조를 나타낸다.
   • 실질적인 데이터의 저장 구조나 컬럼 정의, 인덱스 등이 포함된다.

 

3단계 스키마 구조가 보장하는 독립성

• 논리적 독립성
  • 개념 스키마가 변경되어도 외부 스키마는 영향을 받지 않는다.
• 물리적 독립성
  • 내부 스키마가 변경되어도 외부/개념 스키마는 영향 받지 않는다.

 

ERD(Entity Relationship Diagram)

시스템에 어떤 엔터티들이 존재하며 그들 간에 어떤 관계가 있는지 나타내는 다이어그램

 

1. Peter Chen

대학 교재에서 사용하는 표기법 실무에서 사용 안 함

2. IDEFIX

실무에서 사용하는 경우도 있긴 함. ERWin(ERD를 그리는 툴)에서 사용되는 모델

 

3. IE/Crow's Foot

까마귀발 표기법. 가장 많이 사용한다. ERWin, ERStudio에서 사용되는 모델

4. Min-Max/ISO

각 엔터티의 참여도를 좀 더 상세하게 나타내는 표기법

5. UML

소프트웨어 공학에서 주로 사용되는 모델

 

6. Cause Method/Barker

Oracle에서 사용되는 모델

 

 

02. Entity

엔터티란

식별 가능한 객체

업무에 쓰이는 데이터를 용도별로 분류한 그룹

• 엔터티: Table
• 인스턴스: Row
• 속성: Column

각각의 엔터티에 대해 상세히 나타내는 것은 속성(Attribute)을 갖게 되는데, 속성의 개수는 엔터티마다 상이해서 용도에 따라 다르다.

 

엔터티 특징

1. 업무에서 쓰이는 정보여야 함
2. 유니크함을 보장할 수 있는 식별자여야 함(중복 또는 모호한 식별 X)
3. 2개 이상의 인스턴스를 가져야 함
4. 반드시 속성을 가져야 함
5. 다른 엔터티와 1개 이상의 관계를 가져야 함
   • 회원 엔터티는 주문 엔터티와, 주문 엔터티는 상품 엔터티와 관계를 가지는 것처럼

 

엔터티의 분류

 

유형 vs 무형

• 유형 엔터티
  • 물리적인 형태 존재, 안정적, 지속적
• 개념 엔터티
  • 물리적인 형태 없음, 개념적
• 사건 엔터티
  • 행위를 함으로써 발생, 빈번함, 통계 자료로 이용 가능

 

발생 시점

• 기본 엔터티
  • 업무에 원래 존재하는 정보
  • 독립적으로 생성
  • 자식 엔터티 가질 수 있음
  • 상품, 회원 등
• 중심 엔터티
  • 기본 엔터티로부터 파생
  • 행위 엔터티 생성
  • 업무에 있어서 중심적인 역할을 하며 데이터 양이 많이 발생
  • 주문, 매출, 계약 등
• 행위 엔터티
  • 2개 이상의 엔터티로부터 파생
  • 데이터가 자주 변경되거나 증가할 수 있음
  • 주문 내역, 이벤트 응모 이력 등

 

엔터티 이름 정할 때 주의점

• 업무에서 실제로 쓰이는 용어 사용
• 한글은 약어 사용 X
• 영어는 대문자로 표기
• 단수 명사로 표현, 띄어쓰기 X
• 다른 엔터티와 의미상 중복 불가
• 해당 엔터티가 가지고 있는 데이터가 뭔지 명확히 표현

 

03. 속성

속성이란?

엔터티의 특징을 나타내는 최소의 데이터 단위

프로세스에 필요한 항목이어야 한다.

속성값

엔터티에 속한 하나의 인스턴스를 구체적으로 나타내주는 데이터

하나의 속성은 한 개의 속성값만 가질 수 있다.

여러 개의 속성값을 갖는 경우 별도의 엔터티로 분리해야 한다.

엔터티, 인스턴스, 속성, 속성값의 관계

1. 한 개의 엔터티는 두 개 이상의 인스턴스
2. 한 개의 인스턴스는 두 개 이상의 속성
3. 한 개의 속성은 하나의 속성값

 

분류

특성에 따른 분류

• 기본 속성(Basic Attribute)
  • 업무 프로세스 분석을 통해 바로 정의가 가능한 속성
• 설계 속성(Disigned Attribute)
  • 업무에 존재하지는 않지만 설계하다 보니 필요하다고 판단되어 도출해낸 속성
  • 학번 부여와 같은 것 ↔ 주민등록번호는 부여한 게 아니라 원래 존재하는 기본 속성
• 파생 속성(Derived Attribute)
  • 다른 속성의 속성값을 계산하거나 특정한 규칙으로 변형하여 생성한 속성
  • 계산된 값이나 가공된 값이 이에 속함

구성방식에 따른 분류

• PK(Primary Key) 속성
  • 엔터티의 인스턴스들을 식별할 수 있는 속성
  • 인스턴스에 유니크함을 부여하는 속성
• FK(Foriegn Key) 속성
  • 다른 엔터티의 속성에서 가져온 속성
  • 다른 엔터티와 관계를 맺게 해주는 매개체 역할
• 일반 속성
  • PK, FK를 제외한 나머지 속성
  • 가격, 생년월일 등

 

도메인

속성이 가질 수 있는 속성값의 범위

데이터 타입과 크기로 나눌 수 있다

 

04. 관계

관계란?

엔터티와 엔터티와의 관계를 의미

어떠한 연관성이 있는지 타입을 분류하여 존재 관계와 행위 관계로 나눌 수 있다.

• 존재 관계
  • 존재 자체로 연관성이 있는 관계
  • 학생-학과
• 행위 관계
  • 특정한 행위를 함으로써 연관성이 생기는 관계
  • 회원-주문, 학생-출석부

 

표기법

• 관계명(Membership)
  • 관계의 이름
  • 포함된다, 소속된다 와 같이 어떠한 관계를 맺는 엔터티인지 나타낸다.

관계차수(Cardianlity)

• 관계에 참여하는 수
• 일반적으로 1:1, 1:M, M:N

• 관계선택사양(Optionality)
  • 해당 관계가 필수인지 선택인지의 여부

 

05. 식별자

식별자란?

모든 엔터티는 인스턴스를 가지고 있고 인스턴스는 속성으로 자신의 특성을 나타내는데

식별자는 이런 속성 중에서 각각의 인스턴스를 구별하게 해주는 대표적인 속성을 의미한다.

 

주식별자

기본키 PK에 해당하는 속성

여러 개의 속성이 주식별자가 될 수도 있다.

• 유일성
  • 각 인스턴스에 유니크함을 부여하여 식별이 가능하도록
• 최소성
  • 유일성을 보장하는 최소 개수의 속성이어야 함
• 불변성
  • 속성값이 되도록 변하지 않아야 함
• 존재성
  • 속성값이 NULL일 수 없음

 

분류

1. 대표성 여부
   • 주 식별자 - 다른 엔터티와 참조 관계로 연결
   • 보조 식별자 - 인스턴스를 식별할 수는 있지만 대표가 아님. 다른 엔터티와 참조 관계로 연결되지 않음
2. 스스로 생성되었는지 여부
   • 내부 식별자 - 엔터티 내부에서 스스로 생성된 식별자
   • 외부 식별자 - 다른 엔터티에서 온 식별자. 다른 엔터티와 연결고리 역할
3. 단일 속성의 여부
   • 단일 식별자 - 하나의 속성으로 구성된 식별자
   • 복합 식별자 - 두 개 이상의 속성으로 구성된 식별자

대체 여부

• 원조 식별자 - 업무 프로세스에 존재하는 식별자. 가공되지 않은 원래의 식별자(본질식별자)
• 대리 식별자 - 주 식별자의 속성이 두 개 이상인 경우 그 속성들을 하나로 묶어서 사용하는 식별자(인조 식별자)

 

식별자 관계 VS 비식별자 관계

1. 식별자 관계

 주 식별자는 반드시 존재해야 하므로 부모 엔터티가 있어야 생성 가능하며 단일 식별자인지 복합 식별자인지에 따라 1:1 이거나 1:M이거나가 결정된다.

 부모 엔터티의 식별자가 자식 엔터티의 주 식별자가 되는 관계

 

2. 비식별자 관계

 일반 식별자는 NULL 값이 들어갈 수 있으므로 부모 엔터티가 없는 자식 엔터티 생성이 가능하고 자식이 존재하는 상태에서 부모 엔터티가 삭제될 수도 있다.

 부모 엔터티의 식별자가 자식 엔터티의 일반 식별자가 되는 관계