[SQLP] 과목 1. 데이터 모델링의 이해 - (1) 데이터 모델링의 이해

Part 1. 데이터 모델의 이해

1. 모델링의 이해

가. 모델링의 정의

 - 살아가면서 나타날 수 있는 다양한 현상을 표기법에 의해 규칙을 가지고 표기하는 것

 - 모델을 만들어 가는 일

 - 현실세계를 단순화시켜 표현하는 것

나. 모델링의 특징

특징	설명
추상화	일정한 형식에 맞추어 표현
단순화	약속된 규약에 의해 쉽게 이해할 수 있도록 표현
명확화	대상에 대한 애매모호함을 제거하고 정확하게 현상을 기술하는 것

다. 모델링의 세가지 관점

관점
데이터 관점	업무, 데이터간의 관계가 무엇인지에 대한 모델링 (What, Data)
프로세스 관점	업무에서 실제 하고 있는 일 관점 모델링 (How, Process)
데이터와 프로세스의 상관관점	업무와 데이터가 어떻게 영향을 받고 있는지에 대한 모델링 (Interaction, Data VS Process)

2. 데이터 모델의 기본 개념의 이해

가. 모델링의 정의 및 목적

 - 업무 내용을 정확하게 분석

 - 실제 데이터베이스를 생성하여 개발 및 데이터관리에 사용

데이터모델링 이란?
- 정보시스템을 구축하기 위한 데이터 관점의 업무 분석 기법
- 현실세계의 데이터에 대해 약속된 표기법에 의해 표현하는 과정
- 데이터베이스를 구축하기 위한 분석/설계의 과정

나. 데이터 모델이 제공하는 기능

 - 시스템의 가시화 도움

 - 시스템의 구조와 행동 명세화

 - 시스템을 구축하는 구조화된 틀 제공

 - 시스템 구축 과정 문서화

 - 세부사항을 숨겨 다양한 관점을 볼 수 있도록 제공

 - 구체화 된 상세 수준의 표현 방법 제공

3. 데이터 모델링의 중요성 및 유의점

가. 파급효과 (Leverage) : 데이터 설계가 가장 중요함

나. 복잡한 정보 요구사항의 간결한 표현 (Conciseness) : 요구사항과 한계를 명확하고 간결하게 표현할 수 있는 도구

다. 데이터 품질 (Data Quality)

데이터 모델링 시 유의점	설명
중복 (Duplication)	여러 장소에 같은 정보를 저장하지 않도록 유의
비유연성 (Inflexibility)	데이터의 정의를 데이터 사용 프로세스와 분리 → 작은 변화로 큰 수정을 야기하지 않게 주의
비일관성 (Inconsistency)	데이터와 데이터 간 상호 연관 관계에 대해 명확하게 정의 → 데이터 모순 예방

4. 데이터 모델링의 3단계 진행

데이터 모델링	내용	수준
개념적 데이터 모델링	추상화 수준↑, 업무중심적, 포괄적 모델링 (전사적 데이터모델링, EA수립 시) - 핵심 엔터티와 그들 간의 관계 발견 - 엔터티-관계 다이어그램 생성 - 요구사항 발견 - 현 시스템이 어떻게 변형되어야 하는가 이해	추상적 구체적
논리적 데이터 모델링	Key, 속성, 관계 등 정확하게 표현, 재사용성↑, Entity 중심 - 논리적인 구조와 규칙을 명확하게 표현 - 식별자 확정, 정규화 , M:M관계 해소, 참조 무결성 규칙 정의 등 - 이력 관리 전략 정의
물리적 데이터 모델링	성능, 저장 등 물리적인 성격을 고려한 모델링 - 어떻게 컴퓨터 하드웨어에 표현될 것인가 정의

5. 프로젝트 생명주기(Life Cycle)에서 데이터 모델링

6. 데이터 모델링에서 데이터 독립성의 이해

가. 데이터 독립성의 필요성

 - 자신이 가지는 고유한 특징을 명확하게 함

 - 다른 기능의 변경으로부터 쉽게 변경되지 않고 자신의 고유한 기능을 가지고 기능을 제공함

 - 유지보수 비용 절감

 - 데이터 복잡도 낮춤

 - 중복된 데이터를 줄임

 - 사용자 요구사항에 대해 데이터베이스와 화면 간에 서로 독립성 유지

 - ↔ 데이터 종속성

 - 데이터 독립성 확보 시 얻는 효과

  1) 각 VIew의 독립성 유지, 계층별 View 에 영향을 주지 않고 변경 가능

  2) 단계별 스키마에 따라 DDL과 DML 다름

나. 데이터베이스 3단계 구조

 - ANSI/SPARC

다. 데이터 독립성 요소

단계	내용	관점
외부 단계 External Schema	- 사용자와 가까운 단계 - View 단계 여러 사용자 관점으로 구성 - 개개 사용자 단계, 개인이 보는 DB 스키마 - DB의 개개 사용자나 응용프로그래머가 접근하는 DB 정의	사용자 관점
개념 단계 Conceptual Schema	- 개념단계 하나의 개념적 스키마 - 모든 사용자 관점을 통합한 조직 전체의 DB를 기술 - DB에 저장되는 데이터와 그들간의 관계를 표현	통합 관점
내부 단계 Internal Schema	- DB가 물리적으로 저장된 형식 - 실제적으로 데이터가 저장되는 방법 표현	물리적 관점

라. 두 영역의 데이터 독립성

독립성	내용	특징
논리적 독립성	- 개념스키마가 변경 → 외부 스키마 영향 X - 논리 구조 변경 → 응용프로그램 영향 X	- 사용자 특성에 맞는 변경 가능 - 통합 구조 변경 가능
물리적 독립성	- 내부 스키마 변경 → 외부/개념 스키마 영향 X - 저장장치 구조변경 → 응용프로그램/개념스키마 영향 X	- 개념구조 변경 가능 (물리구조 영향 X) - 물리구조 변경 가능 (개념구조 영향 X)

마. 사상 (Mapping)

사상	내용
외부적/개념적 사상 (논리적 사상)	외부적 뷰와 개념적 뷰의 상호관련성 정의
개념적/내부적 사상 (물리적 사상)	개념적 뷰와 데이터베이스의 상화관련성 정의

7. 데이터 모델링의 중요한 세가지 개념

가. 데이터 모델링의 세 가지 요소

- 업무가 관여하는 어떤 것 (Things) → 엔터티
- 어떤 것이 가지는 성격 (Attributes) → 속성
- 업무가 관여하는 어떤 것 간의 관계 (Relationships) → 관계

나. 단수와 집합(복수)의 명명

개념	복수/집합 개념 타입/클래스	개별/단수 개념 어커런스/인스턴스
어떤 것 Thing	Entity Type	Entity
	Entity	Instance, Occurrence
어떤 것 간의 연관 Association Between Things	Relationship	Pairing
어떤 것의 성격 Characterstic of a Thing	Attribute	Attribute Value

8. 데이터 모델링의 이해관계자

가. 이해관계자의 데이터 모델링 중요성 인식

 - 개발자가 모델링도 같이 하는 경우 많음 → 업무를 이해하고 분석하여 표현하는 것이 중요

 - 모델러, DBA : 정확하게 모델링이 진행될 수 있도록 교육 및 제시

나. 데이터 모델링의 이해관계자

누가 모델링을 학습해야 하는가?
- 정보시스템을 구축하는 모든 사람 (코더 포함)
- 해당 업무에서 정보화를 추진하는 위치에 있는 사람
- 프로젝트 개발자, 현업업무 전문가, 전문모델러, DBA 등

9. 데이터 모델의 표기법인 ERD의 이해

가. 데이터 모델 표기법

 - 1976년 피터첸(Peter Chen), Entity-Relationshop Model(E-R Modeal)

 - Barker, IE(Information Engineering) 표기법 등

나. ERD 표기법을 이용하여 모델링하는 방법

 - ERD : 각 업무에서 도출된 엔터티와 엔터티 간의 관계를 이해하기 쉽게 도식화한 다이어그램으로 표현하는 방법

 - 데이터의 흐름과 프로세스와의 연관성을 이야기하는 데 가장 중요한 표기법이자 산출물

 - 일정한 규칙을 지정하여 그림으로써 데이터 모델을 누구나 공통된 시각으로 파악할 수 있고 의사소통을 원활하게 함

ERD 작업순서 는?
1. 엔터티를 그린다.
2. 엔터티를 적절하게 배치한다.
    → 가장 중요한 엔터티는 왼쪽 상단
    → 업무 흐름에 중심이 되는 엔터티는 중앙
    → 중심 엔터티와 관계를 가진 엔터티는 중심 엔터티 주변
3. 엔터티 간 관계를 설정한다. → 중복, Circle 발생되지 않도록 주의
4. 관계명을 기술한다.
5. 관계의 참여도를 기술한다. → 관계 차수 표현
6. 관계의 필수여부를 기술한다.

10. 좋은 데이터 모델의 요소

요소	설명
완전성 (Completeness)	모든 데이터가 데이터 모델에 정의되어 있어야 함
중복배제 (Non-Redundancy)	동일한 사실은 반드시 한 번만 기록
업무규칙 (Business Rules)	데이터 모델 분석만으로도 비즈니스 로직이 이해되어야 함
데이터 재사용 (Data Reusability)	통합성과 독립성을 고려해야 함
의사소통 (Communication)	설계자가 정의한 업무 규칙들을 동일한 의미로 받아들이고 활용할 수 있어야 함
통합성 (Integration)	동일한 데이터는 유일하게 정의, 이를 여러 다른 영역에서 참조, 활용할 수 있어야 함

 

Part 2. 엔터티 Entitiy

1. 엔터티의 개념

 - 사람, 장소, 물건, 사건, 개념 등의 명사

 - 업무상 관리가 필요한 관심사

 - 저장이 되기 위한 어떤 것

 - 업무에 필요하고 유용한 정보를 저장하고 관리하기 위한 집합적인 것, 인스턴스의 집합

 - 속성 : 개체들의 특성, 공통속성 및 개별속성

2. 엔터티의 특징

 - 반드시 해당 업무에서 필요하고 관리하고자 하는 정보

 - 유일한 식별자에 의해 식별 가능

 - 두 개 이상의 인스턴스 집합 (한 개는 X)

 - 업무 프로세스에 의해 이용되어야 함

 - 반드시 속성이 있어야 함 (관계엔터티의 경우, 주식별자만 속성을 가지고 있어도 엔터티로 인정)

 - 최소 한 개 이상의 관계가 있어야 함

   (단, 통계성, 코드성, 시스템 처리 시 내부 필요에 의한 엔터티 도출의 경우 관계 생략 가능)

3. 엔터티의 분류

가. 유무형에 따른 분류

분류	설명	예시
유형 엔터티	물리적인 형태, 안정적, 지속적으로 활용되는 엔터티	사원, 물품, 강사 등
개념 엔터티	물리적인 형태 없음, 개념적 정보로 구분	조직, 보험상품 등
사건 엔터티	업무를 수행함에 따라 발생되는 엔터티, 발생량 많음, 통계자료에 이용	주문, 청구, 미납 등

나. 발생시점에 따른 분류

분류	설명	예시
기본/키 엔터티	그 업무에 원래 존재하는 정보, 독립적으로 생성 가능, 타 엔터티의 부모역할, 고유한 주식별자를 가짐	사원, 부서, 고객, 상품, 자재 등
중심 엔터티	기본 엔터티로부터 발생, 업무의 중심적인 역할, 데이터 양이 많음, 다른 엔터티와의 관계를 통해 행위 엔터티 생성	계약, 사고, 예금원장, 청구, 주문, 매출 등
행위 엔터티	두 개 이상의 부모 엔터티로부터 발생, 자주 내용이 바뀜, 데이터량 증가, 분석초기에는 잘 나타나지 않음, 상세설계 또는 모델링 진행 시 도출 가능	주문목록, 사원변경이력 등

다. 스스로 생성될 수 있는지 여부에 따른 분류 - 독립 엔터티 / 의존 엔터티

5. 엔터티의 명명

 - 현업 업무에서 사용하는 용어 사용

 - 가능하면 약어를 사용하지 않음

 - 단수명사 사용

 - 모든 엔터티에서 유일하게 이름이 부여되어야 함

 - 엔터티 생성 의미대로 이름을 부여

 

Part 3. 속성 Attribute

1. 속성의 개념

 - 업무에서 필요로 함

 - 의미상 더이상 분리되지 않음

 - 엔터티를 설명하고 인스턴스의 구성요소가 됨

2. 엔터티, 인스턴스와 속성, 속성값에 대한 내용과 표기법

 - 한 개의 엔터티 = 두 개 이상의 인스턴스 집합

 - 한 개의 엔터티 = 두 개 이상의 속성을 가짐

 - 한 개의 속성 = 한 개의 속성값

3. 속성의 특징

 - 해당 업무에서 필요하고 관리하고자 하는 정보여야 함

 - 정해진 주식별자에 함수적 종속성을 가져야 함

 - 하나의 속성에는 한 개의 값만 가짐

 - 다중 값의 경우, 별도 엔터티를 이용하여 분리

4. 속성의 분류

가. 속성의 특성에 따른 분류

분류	설명
기본속성	업무 분석을 통해 바로 정의한 속성, 업무로부터 추출한 모든 속성, 단, 코드성 데이터, 일련번호, 다른 속성의 영향을 받아 생성된 속성 제외
설계속성	원래 업무상 존재하지는 않지만 설계를 하면서 도출해내는 속성, 데이터 모델링 및 업무 규칙화를 위해 새로 만들거나 변형하여 정의하는 속성, ex) 코드성속성 : 원래 속성을 변형하여 만든 설계 속성      일련번호    : 단일 식별자를 부여하기 위해 새로 정의하는 설계 속성
파생속성	다른 속성으로부터 계산이나 변형이 되어 생성되는 속성, 타 속성에 의해 지속적으로 영향을 받아 자신의 값이 변하는 성질을 가지고 있는 속성, 반드시 어떤 엔터티에 어떤 속성에 의해 영향을 받는지 정의되어야 함

나. 엔터티 구성방식에 따른 분류

분류	설명
PK (Primary Key)	엔터티를 식별할 수 있는 속성
FK (Foreign Key)	다른 엔터티와의 관계에서 포함된 속성
일반속성	PK, FK 가 아닌 모든 속성

다. 세부 의미 분리 여부에 따른 분류

분류	설명	예
단순속성	더이상 다른 속성들로 구성될 수 없는 단순한 속성	나이, 성별 등
복합속성	여러 세부 속성들로 구성된 속성	주소 (시, 구, 동, 번지 등)

라. 속성값의 성질에 따른 분류

분류	설명	예
단일값속성	속성값 내 한 개의 값을 가지는 경우	주민등록번호
다중값속성	속성값 내 여러개의 값을 가지는 경우	전화번호 (집, 휴대전화, 회사 등 여러 종류인 경우) → 1차정규화 필요함, 또는 별도 엔터티 구성

5. 도메인 Domain

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

 - 데이터 타입, 크기, 제약사항을 지정하는 것

6. 속성의 명명

 - 용어사전 사용 → 용어적 표준과 데이터 타입의 일관성 확보

 - 해당 업무에서 사용하는 이름 사용

 - 명사형 이용

 - 약어 사용은 가급적 제한

 - 전체 데이터 모델에서 유일성 확보하는 것이 좋음

 

Part 4. 관계 Relationship

1. 관계의 개념

가. 관계의 정의

 - 엔터티와 엔터티 간 논리적인 연관성을 표현

 - 엔터티의 정의, 속성 정의 및 관계 정의에 따라 영향을 받음

나. 관계의 페어링

 - 엔터티 안에 인스턴스가 개별적으로 관계를 가짐 → 집합 관계로 표현

 - 관계 페어링 : 자신이 관련된 인스턴스들과의 관계의 어커런스로 참여하는 형태 (FK)

2. 관계의 분류

 - 목적에 따른 분류 (ERD 에는 구분하여 그리지 않음)

분류	설명	예
존재에 의한 관계 → 연관관계	상태를 나타내는 관계	부서 - 사원 (소속 관계)
행위에 의한 관계 → 의존관계	이벤트를 나타내는 관계	고객 - 주문 (행위 관계)

3. 관계의 표기법

표기명	설명
관계명	관계의 이름 - 엔터티가 관계에 참여하는 형태 지칭 - 관계 시작점 ↔ 관계 끝점, 능동적 ↔ 수동적 - 애매한 동사는 피함 - 현재형으로 표현
관계차수	1:1, 1:M, N:M - 참여자의 수를 표현
관계선택사양	필수관계, 선택관계 - 필수참여 : 타 엔터티의 참여자와 연결이 되어야 하는 관계 - 선택참여 : 물리속성에서 FK 로 연결될 경우 Null을 허용함

4. 관계의 정의 및 읽는 방법

가. 관계 체크사항

 - 연관규칙이 존재하는가?

 - 정보의 조합이 발생되는가?

 - 관계연결에 대한 규칙이 서술되어 있는가?

 - 관계 연결을 가능하게 하는 동사(Verb)가 있는가?

나. 관계 읽기

 - Each → Source → Degree → Target → Optional → Relation Name

    ex) 각각의 사원은 한 부서에 때때로 속한다

 

Part 5. 식별자

1. 식별자 개념

 - 하나의 엔터티에 구성되어 있는 여러 개의 속성 중에 엔터티를 대표할 수 있는 속성

 - 하나의 엔터티는 반드시 하나의 유일한 식별자가 존재함

 - 논리 데이터 모델링 단계에서 사용 (※ 키 : 물리 데이터 모델링 단계에서 사용)

2. 식별자의 특징

 - 주식별자 특징

특징	설명
유일성	엔터티 내에 모든 인스턴스들이 유일하게 구분
최소성	구성 속성 수는 유일성을 만족하는 최소의 수 (다중PK)
불변성	자주 변하지 않는 것
존재성	반드시 값이 들어와야 함 (Nullable)

 - 식별자 별 특징

식별자	특징
대체 식별자	주식별자의 특징과 일치
외부 식별자	참조무결성 제약조건에 따른 특징

3. 식별자 분류 및 표기법

분류	식별자	설명
대표성 여부	주 식별자	어커런스를 구분할 수 있는 구분자, 타 엔터티와 참조관계를 연결할 수 있는 식별자
	보조 식별자	어커런스를 구분할 수 있는 구분자, 대표성을 가지지 못해 참조관계 연결 불가
스스로 생성 여부	내부 식별자	스스로 만들어지는 식별자
	외부 식별자	관계를 통해 타 엔터티로부터 받아오는 식별자
속성의 수	단일 식별자	하나의 속성으로 구성된 식별자
	복합 식별자	둘 이상의 속성으로 구성된 식별자
대체 여부	본질 식별자	업무에 의해 만들어지는 식별자
	인조 식별자	원조식별자가 복잡한 구성을 가짐으로 인해 인위적으로 만든 식별자

4. 주식별자 도출 기준

 - 자주 이용되는 속성

 - 명칭, 이름 등으로 기술되는 것은 지정하지 않음

 - 너무 많은 속성이 포함되지 않도록

5. 식별자관계와 비식별자관계에 따른 식별자

가. 식별자관계와 비식별자관계

 - 자식 엔터티에서 FK 를 주식별자로 사용할 것인지 결정

관계	설명
식별자관계	자식엔터티의 주식별자로 부모의 주식별자가 상속이 되는 경우
비식별자관계	부모 엔터티로부터 속성을 받았지만 자식 엔터티의 주식별자로 사용하지 않고 일반 속성으로 사용하는 경우

나. 비식별자 관계를 생성하는 경우

 - 부모 없는 자식이 생성될 수 있는 경우

 - 엔터티 별로 생성주기를 다르게 관리하는 경우

 - 각각의 엔터티가 별도의 관계를 가지는 경우

 - 자식 엔터티에서 별도의 주식별자를 생성하는 것이 더 유리하다고 판단되는 경우

다. 각 관계별 문제점

관계	설명
식별자 관계로만 설정할 경우	- 데이터 모델의 흐름이 길어질수록 PK 속성의 수가 증가하는 구조를 가짐 - 개발 복잡성과 오류가능성을 유발시킴
비식별자 관계로만 설정할 경우	- 불필요하게 부모 엔터티까지 찾아가야 하는 경우 발생

 - 일정한 규칙을 가지고 데이터 모델링을 하는 기술이 필요함

라. 식별자 관계와 비식별자 관계 모델링

항목	식별자관계	비식별자관계
목적	강한 연결관계	약한 연결관계
자식 주식별자 영향	자식 주식별자의 구성에 포함	자식 일반속성에 포함
표기법	실선 표현	점선 표현
연결 고려사항	- 반드시 부모 엔터티 종속 - 자식 주식별자 구성에 부모 주식별자 포함 - 상속받은 주식별자를 타 엔터티에 이전 필요	- 약한 종속관계 - 자식 주식별자를 독립적으로 구성 - 부모 주식별자 부분적으로 필요 - 상속받은 주 식별자 속성을 타 엔터티에 차단 - 부모 쪽의 관계 참여가 선택관계

 - 약한 연결 관계, 독립 PK 구성, PK 속성 단순화를 위해 비식별자 관계 고려함