데이터 모델의 이해

모델링

모델링이란?

데이터베이스에서 모델링은 ‘ 현실세계를 단순화 하여 표현하는 기법’ 이다.

키워드 : 설계, 디자인, 형상

모델링이 갖춰야 할 조건

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

모델링의 특징

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

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

모델링의 세 가지 관점

1. 데이터 관점(What, Data)

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

1. 프로세스 관점(How, Process)

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

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

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

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

중복(Duplication) 같은 데이터가 여러 엔티티에 중복으로 저장되는 현상을 지양해야 한다.

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

모델링의 세 가지 단계

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

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

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

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

1. 물리적 데이터 모델링(Pysical Data Modeling)

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

데이터의 독립성

ANSI-SPARC 아키텍처는 1975년에 제안된 데이터베이스 관리 시스템(DBMS)의 추상적인 설계 표준이다. 이 아키텍처는 스키마를 3단계 구조로 나누는데, 이렇게 분리하는 목적은 데이터베이스에 대한 사용자들의 관점과 실제로 표현되는 물리적인 방식을 분리하기 위함이다. 데이터베이스가 존재하는 목적중 하나는 사용자에게 뷰를 제공하는 것이다. 하지만 사용자 입장에서는 필요한 데이터만 볼 수 있으면 되고 데이터베이스의 내부 구조에 대해서는 굳이 알 필요가 없다.

3단계 스키마 구조

1. 외부 스키마(External Schema)

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

1. 개념 스키마(Conceptual Schema)

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

1. 내부 스키마(Internal Schema)

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

ERD(Entity Relationship Diagram)

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

ERD 표기방식

1. Peter Chen : 주로 대학교재에서 사용하는 표기법으로 실무에서 사용하는 경우는 드물다.
2. IDEF1X : 실무에서 사용하는 경우도 있으며 ERWin 에서 사용되는 모델이기도 하다
3. IE/Crow’s Foot : 까마귀발 표기법이라고도 부르며 가장 많이 사용한다. ERWin, ERStudio에서 사용되는 모델이다.
4. Min-Max/ISO : 각 엔티티들의 참여도를 좀더 상세하게 나타내는 표기법이다.
5. UML : 소프트웨어 공학에서 주로 사용되는 모델이다.
6. Case*Method/Barker : Oracle에서 사용되는 모델로 Crow’s Foot과 비슷하다.

IE/Crow’s Foot 표기법

여러 가지 표기법중 이 책에서는 IE/Crow’s Foot 표기법을 주로 사용하고 일부 Barker 표기법을 사용하도록 할 것이다. IE/Crow’s Foot 표기법에 대해 간략히 설명하면 다음과 같다.

ERD 작성순서

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

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

엔티티

엔티티란?

엔티티의 사전적 의미는 **‘독립체’**이다. 데이터베이스에서 엔티티는 식별이 가능한 객체라는 의미를 가지고 있다. 다음은 내로라하는 전문가들이 각자 엔티티에 대해 정의해 놓은 것이다.

이름 시기 정의

Peter Chen	1976	식별할 수 있는 사물
C.J Date	1986	데이터베이스 내에서 식별 가능한 객체
James Martin	1989	정보를 저장할 수 있는 어떤 것
Thomas Bruce	1992	정보를 저장할 수 있는 사람, 장소, 물건, 사건 그리고 개념 등

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

각각의 엔티티는 자신을 더 상세하기 나타내기 위해 **속성(Attribute)**을 갖게 되는데, 속성의 개수는 엔티티마다 상이해서 용도에 따라 매우 많을 수 도 있고 적을 수도 있다. 예를 들어 ‘회원’이라는 엔터티는 ‘아이디’, ‘비밀번호’, ‘이름’ … 같은 속성을 갖을 수 있고, ‘상품’ 이라는 엔티티는 ‘상품코드’, ‘상품명’ … 이라는 속성을 갖을 수 있다. 그리고 만약 삼품엔티티에 ‘새우깡’이라는 상품과 ‘자갈치’라는 상품이 있다고 가정한다면 상품은 엔티티의 인스턴스가 된다.

엔티티의 특징

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

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

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

속성

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

사람이나 사물을 정의 할때 보통 여러가지 특징들이 수식어로 붙게 되는 것을 볼 수 있다. 예를들어 아티스트에게는 이름, 생년월일, 소속사, 데뷔 연도 등의 수식어가 붙을 수 있는 이렇게 사물이나 개념의 특징을 설명해줄 수 있는 항목들을 속성이라고 한다.

분류

1. 특성에 따른 분류

기본속성(Basic Attribute) 업무 프로세스 분석을 통해 바로 정의가 가능한 속성

설계속성(Designed Attribute)	업무에 존재하지 않지만 설계하다 보니 필요하다고 판단되어 도출해낸 속성
파생속성(Derived Attribute)	다른 속성의 속성값을 계산하거나 특정한 규칙으로 변형하여 생성한 속성

기본속성

엔티티의 가장 일반적인 속성으로 업무 프로세스 분석을 통해 바로 정의가 가능한 속성들이 여기에 속한다. 엔티티의 가장 많은 퍼센테이지를 차지하는 속성이며 일부 설계속성과 파생속성을 제외한 모든 속성이 기본속성 이다.

설계속성

업무에 존재하지는 않지만 설계 과정에서 합리적인 모델링을 위해 만들어진 속성이다. 예를 들어 ‘학생’ 이라는 엔티티에 이름, 학과, 학년 이라는 속성이 존재한다고 가정했을때 이 속성들의 속성값은 다른 인스턴스의 속성값과 중복될 수 있고 이런 이유로 유니크함을 보장하지 못한다. 이때 학번이라는 설계속성을 만들어서 학생 개개인에게 고유번호를 할당함으로써 인스턴스에 유니크함을 부여하는 것이다.

파생속성

다른 속성으로부터 파생된 속성을 의미하는것으로 계산된 값이나 가공된 값이 이에 속한다. 예를 들어 상품 주문 프로세스를 생각해보면 상품을 주문하여 결제하는 순간 주문 내역과 주문 상품 인스턴스가 생성되고 주문 상품 인스턴스에는 주문한 상품의 개수가 속성으로 존재하게 될 것이다. 이런 경우 한 상품의 재고 계산을 하기 위해서는 모든 주문 이력의 주문 상품 개수를 가져와 합산해야하는데, 그렇게 되면 사용자에게 이 상품의 품절 여부를 알려주는 속도가 느릴 수 있다. 주문 상품 엔티티에서 미리 상품의 구매 수량을 구한다음 재고를 계산하여 속성으로 가지고 있는 경우 이것은 파생속성에 해당한다. 하지만 파생 속성을 설계할 경우 반드시 데이터의 정합성이 고려 되어야하고 계산 과정에서 누락되는 데이터가 생기는 경우 결과값이 엉터리가 될 수 있는 위험한 요소가 존재하기 때문에 불가피하게 필요한 경우에만 정의하는것이 바람직하다.

1. 구성방식에 따른 분류

PK(Primary Key) 속성 엔티티의 인스턴스들을 식별 할수 있는 속성

FK(Foregin Key) 속성	다른 엔티티의 속성에서 가져온 속성
일반속성	PK, FK를 제외한 나머지 속성

도메인

속성이 가질 수 있는 속성값의 범위를 도메인이라고 한다. 예를 들면 우편번호는 다섯 자리의 숫자라는 범위를 가지고 있고 이것은 엔티티를 정의할 때 데이터 타입과 크기로 나타낼 수 있다.

용어 사전 어떤 시스템이든 속성명은 업무와 직결되는 항목이다. 그래서 속성의 이름을 정확하면서도 직관적으로 부여하고(속성명을 보고 어떤 데이터가 저장된 컬럼이라는 걸 직감할 수 있도록) 용어 혼란을 없애기 위해 용어사전이라는 업무사전을 프로젝트에서 이용한다.

시스템 카탈로그

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

관계

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

존재관계

엄마와 아기처럼 존재 자체로 연관성이 있는 관계를 의미한다. 예를 들면 직원과 부서, 학생과 학과 엔티티가 이에 속한다.

행위 관계

특정한 행위를 함으로서 연관성이 생기는 관계를 의미한다. 예를들면 회원과 주문, 학생과 출석부 엔티티가 이에 속한다.

표기법

관계명(Membership) 관계의 이름

관계차수	관계에 참여하는 수
관계선택사양	필수인지 선택인지의 여부

관계명

엔티티와 엔티티가 어떠한 관계를 맺고 있는지 나타내주는 문장이다. 모든 관계는 두 개의 관계명을 가지고 있는데 이유는 각 엔티티의 관점에서 관계명을 하나씩 가지고 있기 때문이다. 관계명은 반드시 명확한 문장으로 표현해야하며 현재형이다.

관계차수

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

관계선택사양

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

식별자

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

주식별자

주식별자는 기본키, 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:M이거나가 결정된다.

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

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