01 데이터 모델링의 이해

seo0·2024년 2월 7일

1. 데이터 모델의 이해

모델링이란?

데이터베이스의 모델링은 현실 세계를 단순화하여 표현하는 기법
모델은 현실 세계에서 일어날 수 있는 다양한 현상에 대해서 일정한 표기법에 의해 표현해 놓은 모형이라고 할 수 있으며 모델링은 이런 모델을 만들어가는 일이라고 할 수 있음

모델링은 현실 세계에서 필요한 데이터를 저장하는 데이터베이스를 구축하기 위한 분석/설계의 과정이라고 할 수 있음

모델링의 특징

추상화(Abstraction)

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

단순화(Simplification)

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

명확화(Clarity)

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

데이터베이스의 모델링은 현실세계를 추상화, 단순화, 명확화하기 위해 일저한 표기법에 의해 표현하는 기법

모델링의 세가지 관점

데이터 관점(What, Data)

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

프로세스 관점(How, Process)

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

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

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

데이터의 품질(데이터의 신뢰도, 정확성 등을 나타내는 척도)을 보장하기 위해 데이터 모델링 시 유의할 사항

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

모델링의 3가지 단계

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

전사적 데이터 모델링 수행 시 행해지며 추상화 레벨이 가장 높은 모델링
-> 업무 중심적이고 포괄적인 수준의 모델링이 진행됨

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

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

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

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

데이터의 독립성

데이터베이스가 존재하는 목적 중 하나는 사용자에게 데이터를 보여줄 수 있는 뷰를 제공하는 것

스키마는 3단계 구조로 나누는데, 이러헤 분리하는 목적은 데이터베이스에 대한 사용자들의 관점과 데이터베이스가 실제로 표현되는 물리적인 방식을 분리하기 위함

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

3단계 스키마의 구조

외부 스키마(External Schema)

사용자의 관점 : Multiple User's View 단계로 각 사용자가 보는 데이터베이스의 스키마를 정의
View 단계로 여러개의 사용자 관점으로 구성되는 것

개념 스키마(Conceptual Schema)

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

내부 스키마(Internal Schema)

물리적인 관점 : Physical Representation 단계로 물리적인 저장 구조를 나타냄
실질적인 데이터의 저장구조나 컬럼 정의, 인덱스 등이 포함
물리적인 저장 구조를 나타내는 것

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

데이터베이스에 대한 사용자들의 관점과 데이터베이스가 실제로 표현되는 물리적인 방식을 분리하여 독립성을 보장하기 위한 것

논리적 독립성

개념 스키마가 변경되어도 외부 스키마는 영향받지 않는다.

물리적 독립성

내부 스키마가 변경되어도 외부/개념 스키마는 영향받지 않는다.

ERD(Entity Relationship Diagram)

시스템에 어떤 엔티티들이 존재하며 그들간에 어떤 관계가 있는지를 나타내는 다이어그램으로 까마귀발 표기법이라고 부르는 IE/Crow's Foot 표기 방식을 가장 많이 사용함

IE/Crow's Foot 표기법

기호	의미
직사각형	엔티티
○	0개
│	1개
까마귀발	2개 이상
직선	부모 엔티티의 식별자가 자식 엔티티의 주 식별자(식별자 관계)
점선	부모 엔티티의 식별자가 자식 엔티티의 일반 속성(비식별자 관계)

ERD 작성 순서

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

2. 엔티티(Entity)

엔티티란?

엔티티의 사전적 의미는 독립체
데이터베이스에서 엔티티는 식별이 가능한 객체라는 의미로 업무에서 쓰이는 데이터를 용도별로 분류한 그룹이라고 할 수 있음

각 엔티티는 자신을 더 상세하게 나타내기 위해 속성(Attribute)을 갖게 되는데, 속성의 개수는 엔티티마다 상이해서 용도에 따라 매우 많을 수도 있고 매우 적을 수도 있음

엔티티에 존재하는 하나의 데이터를 인스턴스라고 하는데 만약 상품 엔티티에 새우깡과 자갈치라는 상품이 있다면 각각은 상품 엔티티의 인스턴스가 됨.

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

엔티티 특징

업무에서 쓰이는 정보여야 함
실질적으로 업무에서 쓰이는 정보여야 엔티티로 도출하는 의미가 있음
유니크함을 보장할 수 있는 식별자가 있어야 함
엔티티에 속한 각각의 인스턴스가 중복되거나 식별이 모호하면 이 엔티티는 설계가 잘못된 것
2개 이상의 인스턴스를 가지고 있어야 함
현재 인스턴스가 1개만 존재하고 앞으로도 쭉 1개만 존재할 예정이라면 이것은 엔티티로 볼 수 없음
반드시 속성을 가지고 있어야 함
엔티티는 반드시 자신을 상세하게 나타낼 수 있는 속성이 있어야 함
다른 엔티티와 1개 이상의 관계를 가지고 있어야 함
각각의 엔티티는 다른 엔티티와의 연관성을 가지고 있어야 함

엔티티의 분류

유형 vs. 무형

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

발생 시점

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

기본 엔티티는 독립적으로 생성되어 자신만의 주 식별자를 가지며 다른 엔티티의 부모 역할을 하게 된다. 중심 엔티티는 기본엔티티로부터 발생되어 많은 데이터를 갖게 되며, 행위 엔티티를 생성한다. 행위 엔티티는 두개 이상의 부모 엔티티로부터 파생되고 보통 설계 초기 단계보다는 상세 설계 단계에서 많이 도출된다.

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

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

3. 속성(Attribute)

속성이란?

사물이나 개념의 특징을 설명해줄 수 있는 항목들을 속성이라 함
즉, 속성은 엔티티의 특징을 나타내는 최소의 데이터 단위로 의미상 더이상 쪼개지지 않는 레벨이어야 하고 프로세스에 필요한 항목이어야함

속성값

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

하나의 속성은 한 개의 속성값만 가질 수 있기 때문에 만약 하나의 속성이 여러개의 속성값을 갖는 경우 별도의 엔티티로 분리하는 것이 좋음

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

엔티티 ⊃ 인스턴스 ⊃ 속성의 관계가 성립된다는 것은 알 수 있는데 이것을 각각의 표기법으로 나타내면 아래와 같음

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

분류

특성에 따른 분류

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

기본 속성

엔티티의 가장 일반적인 속성으로 업무 프로세스 분석을 통해 바로 정의가 가능한 속성들이 여기에 속함

엔티티의 가장 많은 퍼센티지를 차지하는 속성이며 일부 설계 속성과 파생 속성을 제외한 모든 속성이 기본 속성에 속함

설계 속성

업무에 존재하지는 않지만 설계 과정에서 합리적인 모델링을 위해 만들어진 속성
예 ) 학생이라는 엔티티에 이름, 학과, 학년이라는 속성만으로 각 인스턴스의 유니크함이 보장되지 않기 때문에 각 학생에게 학번이라는 설계 속성을 만들어서 부여

파생 속성

다른 속성으로부터 파생된 속성을 의미하는 것으로 계산된 값이나 가공된 값이 이에 속함
예 ) 주문 상품 엔티티에서 미리 상품의 구매 수량을 확인한 다음 재고를 계산하여 속성으로 가지고 있는 경우 파생 속성에 해당

파생 속성을 설계할 경우 반드시 데이터의 정합성이 고려되어야 하고, 계산 과정에서 누락되는 데이터가 생기는 경우 결과값이 엉터리가 될 수 있는 위험 요소가 존재하기 때문에 불가피하게 필요한 경우에만 정의하는 것이 바람직함

구성방식에 따른 분류

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

PK 속성

엔티티에 속한 각 인스턴스에 유니크함을 부여하는 속성

FK 속성

다른 엔티티와 관계를 맺게 해주는 매개체 역할을 해주는 속성

일반 속성

PK, FK를 제외한 나머지 속성을 일반속성이라 함

도메인(Domain)

속성이 가질 수 있는 속성값의 범위를 도메인이라고 함

용어사전

어떤 시스템이든 속성명은 업무와 직결되는 항목으로 속성의 이름을 정확히 하면서도 직관적으로 부여하고 용어의 혼란을 없애기 위해 용어사전이라는 업무사전을 프로젝트에서 사용

시스템 카탈로그

사용자 테이블과는 별개로 시스템 자체에 관련이 있는 데이터를 담고 있는 데이터베이스이며, 시스템 테이블로 구성되어 있어 SQL을 이용하여 조회할 수 있음
시스템 카탈로그에 저장된 데이터를 메타 데이터라고 하며 SELECT만 가능하고, INSERT, UPDATE, DELETE는 불가능

4. 관계(Relationship)

관계란?

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

존재 관계

존재 자체로 연관성이 있는 관계를 의미
예 ) 직원과 부서, 학생과 학과

행위 관계

특정 행위를 함으로써 연관성이 생기는 관계
예 ) 회원과 주문, 학생과 출석부

표기법

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

관계명

엔티티와 엔티티가 어떠한 관계를 맺고 있는지를 나타내주는 문장
관계명은 반드시 명확한 문장으로 표현해야하며 현재형

바람직하지 않은 관계명	바람직한 관계명
연관성이 있다. 관계가 있다. 출석을 했다.	주문한다. 소속된다. 출석을 한다.

관계 차수

각 엔티티에서 관계에 참여하는 수를 의미하며 일반적으로 1:1, 1:N, N:M 형식으로 구분

관계 선택 사양

관계 선택 사양은 이 관계가 필수 요소인지 선택사항인지를 타나내는 말

관계선택사양	설명
필수적 관계	참여자가 반드시 존재해야하는 관계
선택적 관계	참여자가 없을 수도 있는 관계

5. 식별자(Identifiers)

식별자란?

모든 엔티티는 인스턴스를 가지고 있고 인스턴스는 속성으로 자신의 특성을 나타냄
식별자는 이런 속성 중에 각각의 인스턴스를 구분 가능하게 만들어주는 대표적인 속성을 의미

주식별자

주식별자는 기본키, PK(Primary Key)에 해당하는 속성
하나의 속성이 주식별자가 될 수도, 여러개의 속성이 주식별자가 될 수도 있음

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

분류

대표적으로 대표성 여부, 스스로 생성되었는지 여부, 단일 속성의 여부, 대체 여부가 분류의 기준이 됨

대표성 여부

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

스스로 생성되었는지 여부

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

단일 속성의 여부

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

대체 여부

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

식별자 관계 vs. 비식별자 관계

식별자 관계(Identification Relationship)

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

비식별자 관계(Non-Identification Relationship)

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

seo0

이전 포스트

SQLD 자격증

다음 포스트