1장 데이터 모델링의 이해

모델링(Modeling) => 복잡한 현실세계를 추상화, 단순화, 명확화 하기 위해 일정한 표기법으로 표현하는 기법

- 3차원의 현실세계를 단순하게 표현한 것

- 현실 세계를 추상화하여 그 구조를 표현한 것

- 현실 세계에 존재하는 사물이나 사건에 대한 관점 및 양상을 연관된 주체를 위해 명확하게 표현

 

특징 

1) 추상화 - 일적한 형식에 맞게 표현

2) 단순화 - 서로 약속한 규약을 준수하는 표기법이나 언어로 표현

3) 명확화 - 애매모호함을 제거하고 명확하게 표현 

 

모델링의 3 관점

1. 데이터 관점 (Data, what) - 비즈니스와 관련된 데이터는 무엇인지, 데이터 간의 관계는 무엇인지

2. 프로세스 관점 (Process, How) - 비즈니스로 일어나는 일은 어떠한 일인지

3. 상관 관점 (Data vs Process) - 데이터 관점과 프로세스 관점 간 어떠한 영향을 받는지

 

 

데이터 모델의 기능

- 가시화 / 명세화 / 구조화된 틀 / 문서화 / 다양한 관점 제공 / 상세 수준의 표현 방법 제공

 

 

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

- 중복 : 같은 시간 같은 데이터 제공

- 비 유연성 : 사소한 업무 변화에 데이터 모델이 수시로 변경되서는 안됨

- 비 일관성 : 신용 상태에 대한 갱신 없이 고객의 납부 이력 정보를 갱신 할 수 없음

(데이터 모델의 잘못된 설계로 인해 데이터 중복, 비유연성, 비일관성이 발생 할 수 있음)

 

- 파급효과(Leverage) : 비효율적인 데이터 설계 및 업무 요건 충족 못할 시 엄청난 손실 비용 발생

 

- 복잡한 정보 요구사항의 간결한 표현 (Conciseness) : 정보 요구사항을 명확하고 간결하게 표현

 

 

 

데이터 모델링

1. 개념적 데이터 모델링 - 포괄적인 수준의 모델링, 전사적 데이터 모델링 시 많이 사용

2. 논리적 데이터 모델링 -  기본키, 속성, 관계, 외래키 등을 정확하게 표현하는 단계

3. 물리적 데이터 모델링 -  논리적 데이터 모델을 기반으로 실제 물리 DB를 구축하기 위해서 성능, 저장공간 등의 물리적인 특성을 고려하여 설계

 

현실세계 => 개념 데이터 모델링 (추상적) => 개념적 구조 => 논리 데이터 모델링 => 논리적 구조

=> 물리 데이터 모델링(구체적) => 물리 구조(데이터 베이스)

 

 

 

프로젝트 생명 주기 (Project Life Cycle)

- 정보전략계획 -> 분석 -> 설계 -> 개발 -> 테스트 -> 전환 / 이행

  

정보 전략 계획 : 개념적 데이터 모델링

분석 : 개념적 데이터 모델링 , 논리적 데이터 모델링

설계 : 물리적 데이터 모델링

 

 

 

데이터 독립성

=> 각 View의 독립성을 유지하고 계층별 View에 영향을 주지 않고 변경 가능

=> 단계별 Schema에 따라 데이터 정의어 DDL과 데이터 조작어 DML이 다름

 

외부 스키마 : 개개인 사용자가 보는 개인적인 DB 스키마

 

------------------ 논리적 데이터 독립성 ( 외부적 / 개념적 사상)

 

개념 스키마 : 모든 사용자 관점을 통합한 전체 DB 스키마 / 실제 DB 데이터와 응용 프로그램, 사용자와의 관계를 정의

 

----------------- 물리적 데이터 독립성 (물리적 사상)

 

내부 스키마 : 물리적 장치에서 데이터가 실제적 저장하는 DB 스키마 / 하드웨어 장치에 데이터가 저장되는 방법을 표현

 

 

 

1) 논리적 데이터 독립성 : 개념 스키마가 변경되어도 외부 스키마에는 영향을 주지 않음

논리적 구조가 변경되어도 응용 프로그램에 영향을 미치지 않음

=> 사용자 특성에 맞는 변경이 가능, 통합 구조의 변경이 가능

 

2) 물리적 데이터 독립성 : 내부 스키마가 변경되어도, 외부/개념 스키마에 영향을 주지 않음

저장장치의 구조 변경은 응용 프로그램/개념 스키마에 영향을 미치지 않음

=> 물리 구조에 영향 없이 개념 구조 변경 가능 , 개념 구조 영향 없이 물리 구조 변경 가능

 

Mapping(사상) => 상호 독립적인 개념을 연결시켜주는 역할

 

 

데이터 모델링의 3요소

1. 업무가 관여하는 어떤 것 (Things) 

2. 어떤 것이 가지는 성격 (Attributes)

3. 업무가 관여하는 어떤 것간의 관계 (Relationships)

 

데이터 모델링은 프로젝트에 참가한 모두가 알아야 함

 

Thing => 엔터티 타입, 엔터티 : 복수 (집합)

                인스턴스, 어커런스 : 단수 (개별)

Association => 관계 : 복수 / 페어링 : 단수

Characteristic => 속성 : 복수 / 속성값 : 단수

 

 

ERD (Entity Relationship Diagram)

=> 데이터 모델을 표기하는 표기법

=> 개념적 데이터 모델링

 

1. 비즈니스에 필요한 엔터티를 그린다.

2. 엔터티를 적절히 배치한다.

3. 각 엔터티 간의 관계를 설정

4. 설정한 관계의 관계명을 기술

5. 설정한 관계의 참여도를 기술

6. 설정한 관계의 필수 여부를 기술

 

좋은 데이터 모델 요소 

- 완전성 , 중복 배제, 업무 규칙 , 데이터 재사용 , 의사소통, 통합성

 

엔터티(Entity)

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

- 비즈니스 관점에서 IT 시스템을 통해 관리가 필요한 관심사에 해당

- 비지니스를 구현하기 위해 저장해야 하는 어떤 것(Thing)

 

엔터티의 특징

- 비지니스 요구 조건 만족을 위해 반드시 필요하고, 저장 및 관리하고자 하는 정보

- 유일한 식별자에 의한 식별이 가능해야, 집합 내에서 1건을 콕 짚어낼 수 있어야 한다.

- 영속적으로 존재하는 인스턴스(2개 이상)의 집합이어야 한다.

- 엔터티는 비즈니스 프로세스에 의해 반드시 이용되어야 한다.

- 엔터티는 반드시 속성을 가져야 한다.

- 엔터티는 다른 엔터티와 최소 1개 이상의 관계가 있어야 한다.

 

 

업무에서 필요로 하는 정보 - 비즈니스 요구 조건 만족을 위해 반드시 필요하고, 저장 및 관리하고자 하는 정보

식별 가능해야 함 - 유일한 식별자에 의해 식별이 가능해야 한다

인스턴스의 집합 - 영속적으로 존재하는 2개 이상의 인스턴스 집합이어야 한다

업무 프로세스에 의해 이용 - 엔터티는 비즈니스 프로세스에 의해 반드시 이용되어야 한다

속성을 포함 - 엔터티에는 반드시 속성이 포함되어 있음

관계의 존재 - 엔터티는 다른 엔터티와 최소 1개 이상의 관계가 있다

 

 

 

엔터티의 분류

- 유무형 : 유형 엔터티, 개념 엔터티, 사건 엔터티

- 발생지점 : 기본 엔터티, 중심 엔터티, 행위 엔터티

 

 

속성(Attribute)

- 비즈니스에서 필요로 한다

- 엔터티에 대한 설명이며 인스턴스의 구성요소가 된다

- 의미상 더 이상 분리되지 않는 데이터 단위이다.

 

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

1. 1개의 엔터티는 2개의 이상의 인스턴스의 집합이어야 한다.

2. 1개의 엔터티는 2개 이상의 속성을 갖는다.

3. 1개의 속성은 1개의 속성값을 갖는다.

 

특징

- 반드시 비즈니스에서 필요하고 IT 시스템에서 저장 및 관리하고자 하는 정보여야 한다.

- 정규화 이론에 따라 속성이 속해 있는 엔터티의 주식별자에 함수적 종속성을 가져야 한다.

- 하나의 속성에는 1개의 값만을 가진다. 하나의 속성에 여러 개의 값이 있는 다중 값일 경우 별도의 엔터티를 이용하여 분리한다.

 

분류

 

특성

- 기본속성 : 비즈니스 분석을 통해 도출된 속성

- 설계속성 : 비즈니스 분석을 통해 도출된건 아니지만 데이터 모델 설계를 하면서 도출된 속성

- 파생속성 : 다른 속성에 의해서 계산이나 변형이 되어 생성되는 속성

 

엔터티 구성방식

- PK(Primary Key) 속성 : 엔터티에서 단 하나의 인스턴스를 식별할 수 있는 속성을 PK 기본키 속성

- FK(Foreign Key) 속성 : 타 엔터티와의 관계를 통해 포함된 속성을 FK 외래키 속성

- 일반 속성 : 엔터티 내에 존재하면서 PK 혹은 FK 속성이 아닌 속성을 일반 속성

 

 

도메인 - 속성의 값의 범위 및 유형

 

 

관계(RelationShip)

- 엔터티 안에 인스턴스가 개별적으로 관계 가지는 것(페어링)

- 관계 페어링(RelationShip Pairing) : 엔터티 내에 인스턴스가 개별적으로 관계를 가지는 것

 

1:1 관계 , 1:M관계 , M:M관계

 

필수 참여 관계 - 서로에게 관련이 있고 필수적인 관계 (실선)

선택 참여 관계 - 서로에게 관련이 있지만 필수적이지는 않은 관계 (점선)

 

 

식별자(Identifier)

- 엔터티 즉, 인스턴스의 집합에서 단 하나의 인스턴스를 구별해내는 구별자

- ex) 고객번호, 사원번호, 주문번호, 상품 번호

- 유일성 : 엔터티 내에 존재하는 각각의 인스턴스 집합은 주 식별자에 의해 유일히 구분 된다

- 최소성 : 유일성을 만족한다면 주 식별자를 구성하는 속성의 수는 최소한의 수로 이루어져야 한다

- 불변성 : 엔터티 내 특정 인스턴스에 주 식별자가 한번 정해지면 그 값은 변하지 말아야 한다

- 존재성 : 주 식별자가 지정되면 NULL 값 없이 반드시 값이 지정 되어야 한다

 

주 식별자 : 엔터티 내에 각각 행을 구분하는 구분자, 다른 엔터티와 참조 관계를 가질 때 연결할 수 있는 식별자

보조 식별자 : 엔터티 내에 각각 행을 구분하는 구분자, 다른 엔터티와 참조 시 연결은 못함

 

내부 식별자 : 엔터티 내부에서 스스로 만들어지는 식별자

외부 식별자 : 다른 엔터티와의 관계를 통해서 만들어지는 식별자

 

단일 식별자 : 하나의 속성으로 구성된 식별자

복합 식별자 : 둘 이상의 속성으로 구성된 식별자

 

본질 식별자 : 비즈니스에 의해 만들어지는 식별자

인조 식별자 : 인위적으로 만든 식별자 

 

* 이름으로 기술되는 속성은 주식별자로 가급적 사용하지 않는다

* 주 식별자를 복합 식별자로 할 경우 지나치게 많은 속성을 포함시키지 않는다

 

 

외래키 Foreign Key : 다른 엔터티의 기본키를 참조하는 속성

 

 

비식별자 관계 : 부모 엔터티로부터 속성을 물려받았으나 이를 주 식별자로 사용하지 않고 일반적인 속성으로만 사용하는 것

 

- 반드시 필수가 아닌 경우

- 자식 엔터티에서 별도로 주 식별자를 만드는게 유리한 경우

 

 

식별자 관계로만 설정한 경우 문제점

1. 관계가 도출될 때마다 PK 속성의 수가 지속적으로 증가함

2. 테이블간 조인 시, 조인에 참여하는 식별자 속성의 개수가 많을 수록 SQL문의 복잡도 올라가고 실수확률 높아짐

 

 

<정리>

식별자 관계

- 강한 연결 관계

- 부모 엔터티의 주 식별자 속성이 자식 엔터티의 주 식별자 구성에 포함

- 부모 엔터티에 종속되는 경우 사용

 

비식별자 관계

- 약한 연결 관계

- 부모 엔터티의 주 식별자 속성이 자식 엔터티의 일반 속성이 된다.

- 부모 자식간 약한 종속 관계인 경우에 사용