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

모델링(Modeling)

현실 세계를 단순화하여 표현하는 기법

 

모델링이 갖춰야 할 조건

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

모델링의 특징

추상화(Abstraction)

현실 세계를 일정한 형식으로 표현하는 것. 즉 아이디어나 개념을 간략하게 표현하는 과정

단순화(Simplification)

복잡한 현실 세계를 정해진 표기법으로 단순하고 쉽게 표현한다는 의미

명확화(Clarity)

불분명함을 제거하고 명확하게 해석할 수 있도록 기술한다는 의미

 

모델링의 세 가지 관점

데이터 관점(What, Data)

어떤 데이터들이 업무와 얽혀있는지, 그리고 그 데이터 간에는 어떤 관계가 있는지에 대해서 모델링하는 방법

프로세스 관점(How, Process)

이 업무가 실제로 처리하고 있는 일은 무엇인지 또는 앞으로 처리해야 하는 일은 무엇인지를 모델링하는 방법

데이터와 프로세스의 상관 관점(Data vs. Process, Interaction)

프로세스의 흐름에 따라 데이터가 어떤 영향을 받는지를 모델링하는 방법

 

모델링의 세 가지 단계

개념적 데이터 모델링(Conceptual Data Modeling)

전사적 데이터 모델링 수행 시 행해지며 추상화 레벨이 가장 높은 모델링이다. 이 단계에서는 업무 중심적이고 포괄적인 수준의 모델링이 진행된다.

논리적 데이터 모델링(Logical Data Modeling)

재사용성이 가장 높은 모델링으로 데이터베이스 모델에 대한 Key, 속성, 관계 등을 모두 표현하는 단계이다.

물리적 데이터 모델링(Physical Data Modeling)

실제 데이터베이스로 구현할 수 있도록 성능이나 가용성 등의 물리적인 성격을 고려하여 모델을 표현하는 단계이다.

 

3단계 스키마 구조

외부 스키마(External Schema)

사용자의 관점 : Multiple User's View 단계로 각 사용자가 보는 데이터베이스의 스키마를 정의한다.

개념 스키마(Conceptual Schema)

통합된 관점 : Community View of DB 단계로 모든 사용자가 보는 데이터베이스의 스키마를 통합하여 전체 데이터베이스를 나타내는 것. 데이터베이스에 저장되는 데이터들을 표현하고 데이터들 간의 관계를 나타낸다.

내부 스키마(Internal Schema)

물리적인 관점 : Physical Representation 단계로 물리적인 저장 구조를 나타낸다. 실질적인 데이터의 저장 구조나 칼럼 정의, 인덱스 등이 포함된다.

 

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

ANSI-SPARC 아키텍처에서 이렇게 스키마를 3단계 구조로 나누는 이유는 데이터베이스에 대한 사용자들의 관점과 데이터 베이스가 실제로 표현되는 물리적인 방식을 분리하여 독립성을 보장하기 위한 것이라고 하였다. 그렇다면 어떤 독립성이 보장되는지 알아보자.

 

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

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

 

ERD(Entity Relationship Diagram)

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

 

ERD 표기 방식

Peter Chen : 주로 대학교재에서 사용하는 표기법으로 실무에서 사용하는 경우는 드물다.

IDEFIX : 실무에서 사용하는 경우도 있으며 ERWin에서 사용되는 모델(ERWin은 ERD를 그리는 모델링 툴)

IE/Crow's Foot : 까마귀발 표기법이라고도 부르며 가장 많이 사용한다. ERWin,  ERStudio에서 사용되는 모델

Min-Max/ISO : 각 엔터티의 참여도를 좀 더 상세하게 나타내는 표기법

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

Case*Method/Barker : Oracle에서 사용되는 모델로 Crow's Foot과 비슷하다.

 

ERD 작성 순서

어떤 표기법을 사용하든 ERD를 작성하는 순서는 공통된 룰이며, 다음의 표기 순서를 따른다.

1. 엔터티를 도출하고 그린다.
2. 엔터티를 적절하게 배치한다.
3. 엔터티 간의 관계를 설정한다.
4. 관계명을 기입한다.
5. 관계의 참여도를 기입한다.
6. 관계의 필수/선택 여부를 기입한다.

 

엔터티(Entity)

데이터베이스에서 엔터티는 식별이 가능한 객체이다. 쉽게 말해서 업무에서 쓰이는 데이터를 용도별로 분류한 그룹이라고 할 수 있다.

 

엔터티의 특징

• 업무에서 쓰이는 정보여야 함
• 유니크함을 보장할 수 있는 식별자가 있어야 함
• 2개 이상의 인스턴스를 가지고 있어야 함
• 반드시 속성을 가지고 있어야 함
• 다른 엔터티와 1개 이상의 관계를 가지고 있어야 함

 

엔터티의 분류

유형 vs. 무형

유형 엔터티	물리적인 형태 존재. 안정적, 지속적 예) 상품, 회원
개념 엔터티	물리적인 형태 없음. 개념적 예) 부서, 학과
사건 엔터티	행위를 함으로써 발생. 빈번함, 통계자료로 이용 가능 예) 주문, 이벤트 응모

 

발생 시점

기본 엔터티	독립적으로 생성됨. 자식 엔터티를 가질 수 있음 예) 상품, 회원
중심 엔터티	기본 엔터티로부터 파생. 행위 엔터티 생성 예) 주문
행위 엔터티	2개 이상의 엔터티로부터 파생 예) 주문 내역, 이벤트 응모 이력

 

엔터티의 이름을 정할 때 주의할 점

• 업무에서 실제로 쓰이는 용어 사용
• 한글은 약어를 사용하지 않고 영문은 대문자로 표기
• 단수 명사로 표현하고 띄어쓰기는 하지 않음
• 다른 엔터티와 의미상으로 중복될 수 없음(주문, 결제 엔터티는 중복될 수 있음)
• 해당 엔터티가 갖고 있는 데이터가 무엇인지 명확하게 표현

 

속성(Attribute)

사람이나 사물 같은 개념의 특징을 설명해 줄 수 있는 항목. 의미상 더 이상 쪼개지지 않는 레벨이어야 하고 프로세스에 필요한 항목이어야 한다.

 

속성값

각각의 속성은 속성값을 가지며 속성값은 엔터티에 속한 하나의 인스턴스를 구체적으로 나타내주는 데이터라고 볼 수 있다.

하나의 속성은 한 개의 속성값만 가질 수 있다. 만약 하나의 속성이 여러 개의 속성값을 갖는 경우 별도의 엔터티로 분리하는 것이 바람직하다.

 

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

엔터티 > 인스턴스 > 속성 > 속성값

 

• 한 개의 엔터티는 두 개 이상의 인스턴스를 갖는다.
• 한 개의 인스턴스는 두 개 이상의 속성을 갖는다.
• 한 개의 속성은 하나의 속성값을 갖는다.

 

분류

특성에 따른 분류

기본 속성	업무 프로세스 분석을 통해 바로 정의가 가능한 속성
설계 속성	업무에 존재하지는 않지만 설계하다 보니 필요하다고 판단되어 도출해낸 속성
파생 속성	다른 속성값을 계산하거나 특정한 규칙으로 변형하여 생성한 속성

 

구성 방식에 따른 분류

PK(Primary Key)속성	엔터티의 인스턴스들을 식별할 수 있는 속성
FK(Foreign Key)속성	다른 엔터티의 속성에서 가져온 속성
일반 속성	PK, FK를 제외한 나머지 속성

 

도메인(Domain)

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

 

관계(Relationship)

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

 

존재 관계

엄마와 아기처럼 존재 자체로 연관성이 있는 관계

예) 직원과 부서, 학생과 학과

 

행위 관계

특정한 행위를 함으로써 연관성이 생기는 관계

예) 회원과 주문, 학생과 출석부

 

표기법

관계명(Membership)	관계의 이름
관계차수(Cardinality)	관계에 참여하는 수
관계선택사양(Optionality)	필수인지 선택인지의 여부

 

식별자(Identifiers)

각각의 인스턴스를 구분 가능하게 만들어주는 대표 격인 속성

예) 학번, 군번, 사번

 

주식별자

기본키, PK에 해당하는 속성. 하나의 속성 혹은 여러 개의 속성이 주식별자가 될 수 있다.

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

 

분류

대표성 여부

주식별자 (Primary Identifier)	유일성, 최소성, 불변성, 존재성을 가진 대표 식별자 다른 엔터티와 참조 관계로 연결
보조식별자 (Alternate Identifier)	인스턴스를 식별할 수는 있지만 대표 식별자가 아님 다른 엔터티와 참조 관계로 연결되지 않음

 

스스로 생성되었는지 여부

내부식별자 (Internal Identifier)	엔터티 내부에서 스스로 생성된 식별자
외부식별자 (Foreign Identifier)	다른 엔터티에서 온 식별자. 다른 엔터티와의 연결고리 역할

 

단일 속성의 여부

단일식별자 (Single Identifier)	하나의 속성으로 구성된 식별자
복합식별자 (Composite Identifier)	두 개이상의 속성으로 구성된 식별자

 

대체 여부

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

 

식별자 관계

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

 

비식별자 관계

부모 엔터티의 식별자가 자식 엔터티의 주식별자가 아닌 일반 속성이 되는 관계. 일반 속성의 속성값은 NULL이 될 수 있으므로 부모 엔터티가 없는 자식 엔터티 생성이 가능하고 마찬가지의 이유로 자식 엔터티가 존재하는 상태에서 부모 엔터티가 삭제될 수도 있다.