SQLD - 1. 데이터 모델링의 이해

데이터 모델의 이해

모델링의 개념

• 현실세계의 데이터를 약속된 표기법에 따라 도식화한 것
• 데이터베이스 구축 및 업무 형상화(추상화, 가시화, 명세화)를 진행하여 이를 설계, 개발 또는 시스템 관리에 사용

모델링의 특징

추상화(Abstraction)

• 대상의 주요 특징을 추출하여 일정한 형식으로 표현

단순화(Simplification)

• 복잡한 현실세계를 그대로 표현하지 않고 단순하게 표현
• UML(Unified Modeling Language), ERD(Entity Relationship Diagram)과 같은 약속된 표기법을 사용

명확화(Clarity)

• 보는 사람 관점에 따라 다르게 해석되지 않도록 대상을 명확하게 모호하지 않게 표현

데이터 모델링

• 일정한 표기법을 사용하여 대상이 되는 데이터를 추상화, 단순화, 명확화 하여 표현
• 주의사항으로 중복(Duplication) 최소화, 비유연성(Inflexibility) 최소화, 비일관성(Inconsistency) 최소화
• 응용 프로그램과 테이블은 느산하게 결합하는 것이 유리

모델링의 세 가지 관점

데이터 관점(대상, what)

• 업무 데이터에 집중하여 어떤 데이터들이 서로 관계를 맺고 사용되는지 모델링

프로세스 관점(처리방법, How)

• 업무 흐름에 집중하여, 업무가 실제로 처리하는 일이 어떻게 처리되는지 모델링(동적 분석, 도메인 분석 기반)

데이터와 프로세스의 상관 관점(대상과 처리방법의 상관관계, Interaction)

• 업무의 데이터와 프로세스가 서로 어떻게 관계를 맺고 영향을 주고받는지를 모델링(CRUD 분석 기반)

모델링의 세 가지 단계

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

• 가장 높은 추상화 레벨을 가진 모델링으로 업무와 개념 중심으로 포괄적인 수준에서 모델링을 수행
• 전사적 차원의 데이터 모델링을 수행할 때 이루어짐
• EA(Enterprise Architecture)를 수립할 때 많이 이용되며, 이 단계에서 엔터티(Entity)와 속성(Attribute)을 도출

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

• 데이터 모델에 대한 키(Key), 속성(Attribute), 관계(Relationship) 등을 정의하고 정규화를 통해 중복 데이터를 최소화
• 서로 다른 DBMS(Database Management System)에 적용이 가능한 수준에서 추상화 레벨을 가지므로 재사용성 높음

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

• 특정 DBMS에 맞추어 구현이 가능한 수준에서 모델링을 수행하는 것으로 DBMS의 성능이나 저장, 보안, 가용성 등 물리적인 성격을 고려하여 설계
• 가장 낮은 수준의 추상화 레벨을 가지며 성능 향상을 위해 반정규화를 수행, 테이블, 인덱스, 함수 등을 생성

ANSI-SPARC에서 정의한 3단계 스키마 구조

• 데이터 독립성을 보장하기 위한 설계방법으로 3단계 스키마 구조를 가지며 사용자, 설계자, 개발자 관점에서 스키마를 정의한 것

외부 스키마(External Schema)

• 사용자 또는 애플리케이션(응용 프로그래머) 관점에서 DB 스키마를 정의
• 다중 사용자 뷰 제공

개념 스키마(Conceptual Schema)

• 설계자 또는 모든 사용자(조직 전체) 관점에서 DB 스키마를 통합하여 전체 DB에 저장되는 데이터와 그 관계를 정의
• 통합된 뷰 제공

내부 스키마(Internal Schema)

• 개발자 관점에서 디스크나 메모리 상의 물리적, 실질적 저장구조를 나타내며, 테이블, 칼럼, 인덱스 등을 정의
• 물리적 뷰 제공

논리적 데이터 독립성

• 외부 스키마와 개념 스키마 간의 독립성
• 개념 스키마가 변경되어도 외부 스키마는 영향X

물리적 데이터 독립성

• 개념 스키마와 내부 스키마 간의 독립성
• 내부 스키마가 변경되어도 개념 스키마와 외부 스키마는 영향 X

데이터 모델링의 유의사항

• 데이터 정의를 프로세스와 분리하여 유연성을 향상
• DB내 같은 데이터를 저장하지 않도록 하여 중복성 최소화
• 데이터 상호 간의 연관관계를 정의하여 데이터 일관성 유지
• 데이터의 정의(스키마, 테이블)와 데이터를 사용하는 방법(프로세스, 프로그램)을 느슨하게 결합하여 유지보수성 향상

ERD

• DB를 구성하는 데이터 논리적 구성요소를 엔터티(Entity)로 정의하고 엔터티들 간의 관계를 특별한 표기법으로 나타냄으로써 스키마를 설계하는 방법을 제공
• 1976년 피터 첸(Peter Chen)에 의해 Entity-Relationship Model(E-R Model)이라는 표기법이 만들어짐

ERD 작성순서

1. 엔터티 도출
2. 도출된 엔터티를 적절하게 배치, 중요 엔터티는 왼쪽 상단에 배치
3. 엔터티 간의 관계 설정
4. 관계명 기술(행위 관계, 존재 관계 표현)
5. 관계의 참여도(Cardinality)를 기술(1:1, 1:N, N:N 표현)
6. 관계의 필수/선택 여부를 기술(Not Null 여부)

---

엔터티(Entity)

엔터티의 개념

• DB 구성요소 중 독립적으로 식별 가능한 객체(Object)로 보다 상세히 표현하기 위해 속성(Attribute)이라는 하위요소를 가짐
• ERD로 표현할 때 PK(Primary Key, 주식별자) 속성과 일반 속성은 칸막이로 구분

엔터티의 특징

• 업무에서 필요로 하고 관리하고자 하는 정보이어야 함
• 식별이 가능하도록 유일한 식별자를 가져야 함
• 영속적으로 존재하는 인스턴스가 두 개 이상인 집합을 이루어야 함
• 하위요소로 반드시 속성을 가져야 함
• 다른 엔터티와 한 개 이상의 관계를 가져야 함(통계성 엔터티나 코드성 엔터티의 경우 관계 생략 가능)
• 교차 엔터티(Interaction Entity): N:N(다대다) 관계를 해소하기 위하여 만들어진 엔터티

엔터티의 분류

발생 시점/상속 관계에 따른 분류

• 기본 엔터티: 자신의 고유한 주식별자를 가지는 독립적으로 생성되는 엔터티
• 중심 엔터티: 기본 엔터티로부터 주식별자를 상속받아 생성되며 업무의 중심 역할을 하는 엔터티
• 행위 엔터티: 두 개 이상의 엔터티를 상속받아 생성되는 엔터티, 내용이 자주 변경되거나 데이터 양이 계속 증가

물리적 형태의 존재 여부에 따른 분류

• 유형 엔터티: 물리적 형태가 존재하는 엔터티
• 개념 엔터티: 물리적 형태 없이 개념적으로 정의되는 엔터티
• 사건 엔터티: 업무를 수행하면서 발생하는 행위나 이벤트를 나타내는 엔터티

---

속성(Attribute)

속성의 개념

• 엔터티에 대한 자세하고 구체적인 정보를 나타낸 것으로 엔터티의 하위요소
• 의미상으로 더 이상 분리되지 않는 최소의 데이터 단위
• 개수 제한은 없지만 처리하고자 하는 업무 프로세스에 꼭 필요한 것으로 정의하여 최소화

속성값

• 속성이 가질 수 있는 특정 값을 의미
• 하나의 엔터티 인스턴스에서 각각의 속성은 한 개의 속성값만을 가짐
• 만약 한 개 이상의 속성값을 가질 수 있는 경우에는 1차 정규화를 수행하여 한 개만 갖도록 해야 함

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

• 한 개의 엔터티는 두 개 이상의 인스턴스를 가져야 함(엔터티는 인스턴스의 집합)
• 한 개의 엔터티는 두 개 이상의 속성을 가져야 함(엔터티는 속성의 집합)
• 한 개의 속성은 한 개의 속성값만 가짐

속성의 분류

속성의 특성에 따른 분류

• 기본 속성: 엔터티가 본래부터 가지고 있어야 하는 속성
• 설계 속성: 엔터티가 본재부터 가지고 있던 속성은 아니지만 설계 시 필요하다고 판단되어 도출된 속성
• 파생 속성: 원래의 속성으로부터 계산되거나 특정 규칙에 따라 변형되어 만들어진 속성

속성의 구성 방식에 따른 분류

• PK(Primary Key, 기본키) 속성: 해당 엔터티의 인스턴스를 유일하게 식별할 수 있는 속성
• FK(Foreign Key, 외래키) 속성: 관계를 통해 다른 엔터티의 속성을 가져와 포함시키는 속성
• 일반 속성: 키(PK, FK)가 아닌 나머지 속성

도메인

• 속성이 가질 수 있는 값의 범위(값의 데이터 타입과 크기)를 정의한 것
• 도메인이 지정된 속성은 해당 도메인의 데이터 타입, 크기, 제약사항 등을 따름

---

관계(Relationship)

관계의 개념

• 엔터티와 엔터티 간에 맺고 있는 연관성을 의미
• 엔터티 관계는 존재적 관계와 행위적 관계로 나눌 수 있으나 ERD에서는 이 둘을 구분하지 않고 동일하게 표현
• UML의 클래스 다이어그램에서는 연관관계와 의존관계로 구분하며 표기도 실선과 점선으로 다르게 표현 (ERD에서는 실선과 점선의 구분은 식별자 관계와 비식별자 관계를 구분할 때 사용)

존재적 관계

• 존재 자체로 서로 연관성을 갖는 관계를 의미(예: 회원과 등급)

행위적 관계

• 한 엔터티가 일으키는 특정 행위가 연관성이 발생하는 관계를 의미(예: 회원과 주문)

엔터티 관계를 도출할 때 참고사항

• 두 개의 엔터티 사이에 정보의 조합이 발생하는가?
• 두 개의 엔터티 사이에 관심 있는 연관규칙이 존재하는가?
• 업무기술서, 장표에 관계연결을 가능하게 하는 동사(Verb)가 있는가?
• 업무기술서, 장표에 관계연결에 대한 규칙이 서술되어 있는가?

표기법

관계명(Membership)

• 관계의 이름, 존재적 관계와 행위적 관계를 기술

관계차수(Cardinality)

• 1:1(일대일), 1:N(일대다), N:N(다대다)과 같이 관계를 맺는 엔터티 인스턴스의 차수

관계선택사양(Optionality)

• 필수적 관계인지 선택적 관계인지를 나타냄(Not Null 여부를 의미, 필수적 관계인 경우 Null 값을 가질 수 없음)
• 선택적 관계인 경우에는 까치발 기호에 O 표시가 덧붙음

---

식별자(Identifier)

식별자의 개념

• 유일하게 구별할 수 있는 엔터티의 대표 속성

주식별자

• 엔터티 인스턴스를 유일하게 구별해 주는 대표성을 가진 식별자로써 PK(Primary Key)에 해당하는 속성
• 아래 네 가지 성질을 만족해야 함
  • 유일성: 인스턴스를 유일하게 구별할 수 있어야 함
  • 최소성: 유일성을 보장하면서도 최소 개수의 속성이어야 함
  • 불변성: 최초 생성 시 부여된 값에서 변경되지 않아야 함
  • 존재성: 반드시 값을 가져야 함(Not Null)
• 해당 업무에서 자주 사용되는 속성을 주식별자로 지정하는 것이 유히
• 후보키(Candidate Key): 유일성과 최소성을 만족하는 속성

식별자의 분류

대표성 여부

• 주식별자(Primary Identifier): 인스턴스를 유일하게 구별할 수 있는 유일성, 최소성, 불변성, 존재성을 만족하는 대표성에 따른 식별자, 다른 엔터티와 참조 관계를 연결할 수 있음
• 보조식별자(Alternate Identifier): 인스턴스를 유일하게 구별할 수 있는 식별자이기는 하나 대표성을 가지지 못하며 다른 엔터티와 참조관계를 연결할 수 없는 식별자

스스로 생성 여부

• 내부식별자(Intenal Identifier): 엔터티 내부에서 스스로 만들어지는 식별자
• 외부식별자(External Identifier): 관계를 통해 다른 엔터티로부터 받아오는 식별자(FK)

속성의 수

• 단일식별자(Single Identifier): 식별자를 구성하는 속성이 하나인 식별자
• 복합식별자(Composite Identifier): 식별자를 구성하는 속성이 둘 이상인 식별자 (너무 많은 속성을 포함하지 않는 것이 유리)

대체 여부

• 본질식별자, 원조식별자(Original Identifier): 업무(비즈니스 프로세스)에 존재하는 본래의 식별자
• 인조식별자, 대리식별자(Surrogate Identifier): 업무에 존재하지 않으나 원조식별자가 복잡하게 구성되어 있어 인위적으로 만든 식별자

식별자 관계, 비식별자 관계

식별자 관계

• 엔터티 간의 강한 연결 관계를 표현하며 ERD로 그릴 때 실선으로 표현
• 부모 엔터티의 식별자가 자식 엔터티의 주식별자 구성에 포함되며, 같은 생명주기를 가질 때 적합
• 부모 엔터티의 주식별자를 자식 엔터티에서 받아 손자 엔터티까지 계속 흘려보내고 싶을 때 고려

비식별자 관계

• 엔터티 간의 약한 연결 관계를 표현하며 ERD로 그릴 때 점선으로 표현
• 부모 엔터티의 식별자가 자식 엔터티의 일반 속성이 되며, 다른 생명주기를 가질 때 적합
• 여러 개의 엔터티를 통합하면서 각각의 여러 관계가 통합되거나 자식 엔터티에서 독립적인 주식별자의 구조를 갖길 원할 때 고려