데이터 모델링 (Database Modeling) 실무 (엔티티 / 속성 / 관계 / 식별자 / 정규화 단계)

데이터 모델링 (Database Modeling) 실무 (데이터표준화 / 도메인 / 논리 모델링 / 물리 모델링 / 정규화

데이터 모델링 개요 - 표기법(IE)

• 정보공학 표기법은 제임스 마틴이 개발했다.
• 까마귀발(Crow's foot) 모델이라고도 한다.

 

 

 

엔티티 표기

• 하나 이상의 속성으로 구성

속성의 표기

• 속성은 하나의 엔티티에 종속되어 표기
• 키 속성과 일반 속성으로 구분하여 서로 다른 영역에 표기한다.

관계의 표기

• 바커 표기법과 정보공학 표기법의 가장 큰 차이점은 옵션과 필수 표기이다. > outer Join
  바커 표기법은 점선, 실선으로 구분하나 정보공학 표기법은 I,O으로 구분한다.

 

---

 

데이터 모델링 성공 요소

• 전 단계에 걸쳐 체계적 방법 채택
• 프로세스와는 독립적인 개념으로 데이터를 인식해야 한다.
• 데이터 중심의 접근 방법 필요
• 데이터 구조와 무결성(업무 규칙) 측면의 관점을 융합
• 정규화(Normalization) 기법 채택

데이터 모델링 시 품질을 낮추는 요인

• 업무 요구 분석이 부족한 경우
• 속성 간의 관계 도출을 경시 등 자료 간의 관계 분석이 미흡할 경우
• 표준형 테이블 설계 기술에 대한 이해가 부족할 경우 (정규화 이론)

요구사항 분석에서 모호성 해결하기 

• 추상화 레벨에 맞는 정확한 용어 사용
• 필요 이상의 구체적인 용어보다는 일반적인 개념 사용 (표현은 구체적으로)
• 동음이의어와 이음동의어를 통일
• 용어사전을 통해 용어의 의미를 정확히 이해하고 모호성을 배제

 

---

논리 모델링

엔티티

의미 있는 유용한 정보를 제공하기 위해 기록, 관리하고자 하는 데이터 유형으로 사람, 사물, 장소, 개념 등의 실체

(대상의 특징을 표현하기 위한 둘 이상의 속성이 있어야 하며 이름은 항상 명사형으로 표기)

 

 

 

키 엔티티

• 자신의 부모를 가지지 않는 엔티티, 처음부터 존재하는 엔티티 
• ex) 사원, 부서, 고객, 상품, 자재 등

 

메인 엔티티

• 다른 엔티티들이 존재하는 상태에서 생성되는 엔티티 중 업무의 중심이 되는 엔티티
• ex) 보험 계약, 사고, 예금 원장, 청구, 출하지시, 공사, 주문, 매출 등 

 

액션 엔티티

• 반드시 다른 엔티티들이 존재하는 상태에서 생성
• ex) 상태 이력, 차량 수리 내역, 상세 주문 내역 등 

 

후보 엔티티 선정 기준

- 관리해야 할 데이터를 간직하고 있는 엔티티인가?

 

 

 

관계(Cardinality)

• 실체 간에 존재하는 상호 연관성으로 해당 실체와 관련된 업무가 수행되는 일련의 규칙
• 2개 엔티티 간의 관계 내용을 양방향으로 표시
• 자신과 대상의 관점에서 표현
• 제 3의 관점은 배제
• 관계 정의 절차로는 관계 추출 → 관계 분류 → 관계 검증 
• 선택(Optional) 관계와 필수(Mandatory) 관계
  선택 : 있을 수도 있고 없을 수도 있는 경우
  필수 : 반드시 있어야한 하는 경우

 

반응형

식별관계

부모 테이블(참조되는 테이블)의 기본키를 자식 테이블(참조하는 테이블)의 기본키로 이용하는 방법

• 반드시 부모 테이블에 데이터가 존재해야만 자식 테이블에 데이터를 추가할 수 있다.
• 데이터 정합성을 데이터베이스 단계에서 보장한다.
  여기서 데이터 정합성(Data Consistency)이란, 어떤 데이터들이 값이 서로 일치하는 상태를 의미하는데
  중복 데이터를 많이 사용하면 데이터끼리 정합성을 맞추기 어렵다.
• 자식 테이블에서 부모 테이블의 기본키를 기본키로 사용하고 있는 구조라 구조 변경이 자유롭지 못하다.

 

비 식별관계

부모 테이블(참조되는 테이블)의 기본키를 자식 테이블(참조하는 테이블)의 외래키로 이용하는 방법

 

 

식별자

엔티티의 인스턴스들 사이의 유일성을 보장하는 속성

• 하나 또는 그 이상의 속성(Attribute)으로 구성
• 모든 엔티티는 반드시 식별자가 있어야 한다.
• 식별자를 구성하는 모든 속성은 반드시 데이터가 존재해야 한다. (NOT NULL)
• 메인 엔티티와 액션 엔티티는 의미상의 주어가 식별자로 정해질 수 있으나, 상황에 따라 인조키로 대체될 수 있다.

 

---

속성(Attribute)

더 이상 분할되지 않는 최소의 데이터 보관 단위

• 엔터티 내부에 표현되며 관리하고자 하는 데이터들이다.
• 속성들은 반드시 식별자에 종속되어야 하며, 제 2 정규형에 해당한다.
• 식별자와 비식별자(설명자)로 분류할 수 있다.
  식별자 (Identifier / Primary Key) : 엔티티를 서로 유일하게 식별하는 역할의 속성
  비식별자 (Descriptor) : 특정 엔티티를 묘사하는 역할의 속성

 

속성 정의 4단계

• 최소 단위로 분할한다.
  ex) 고객 엔티티 내부의 주소 또는 전화번호
• 하나의 값인지 검증한다.
  ex) 고객 엔티티의 주문일자
• 추출 속성인지 검토한다.
  ex) 특정 기간의 총 매출액, 최대/최소/평균 등의 통계 정보
• 관리 수준을 검토한다.
  ex) 부양자 수만 관리할 것인지 각 상세 수준까지 관리할 것인지 (미래의 관리 수준도 고려)

 

[속성 분류] 

기초 속성(Basic Attribute)

• 관리되고 유지되는 기본적인 속성
  ex) 주문일자, 납기일자, 수량, 단가

 

설계 속성(Designed Attribute)

• 원래 존재하지는 않지만 필요에 따라 설계자가 생성한 속성
  ex) 주문번호, 고객번호, 주문 상태, 일련번호, 품목코드

 

추출 속성(Derived Attribute)

• 다른 속성으로부터 계산 등의 가공 처리를 통해 만들어진 중복성을 지닌 속성
  ex) 주문 총액, 금액

 

---

정규화

불필요한 데이터의 중복을 제거하여 안정성을 갖게 하는 작업을 의미

• 데이터의 중복이 제거된다.
• 데이터의 일관성이 유지된다.
• 과도한 정규화 작업시 테이블 증가로 인한 응답 속도가 지연될 수도 있다. (조인이 많을 경우)

 

정규화를 하지 않을 경우

• 데이터 중복, 메모리 낭비, 일관성 결여
• 입력, 변경, 삭제 이상 현상 발생 우려

 

[정규화 단계] 

1차 정규형

• 모든 속성은 하나의 값만을 가져야 한다.
• 각 속성의 모든 값은 동일한 형식이어야 한다.
• 각 속성은 유일한 이름을 가져야 한다.

2차 정규형

• 1차 정규형을 만족하며, 식별자가 아닌 모든 속성은 식별자에 완전 종속이어야 한다.

3차 정규형

• 2차 정규형을 만족하며, 이행 종속이 없어야 한다.
  이행 종속 관계란, A→B이고 B→C일 때 A→C를 만족하는 관계

BCNF 정규형

• 모든 결정자는 키가 되어야 한다.
• 다시 말해, 모든 결정자가 후보키 집합에 속해야 한다. 
  (후보키 집합에 없는 칼럼이 결정자가 되어서는 안 된다는 의미)