02 데이터 모델링 기본 개념 2

 

[ 데이터베이스 구축 단계 ]

 

 

 

 

2.3. 데이터베이스 라이프 사이클

 

 

- 요구 사항 분석 단계

• 데이터베이스에서 관리해야 하는 데이터를 도출하고 분석하는 단계이다.
• 요구 사항은 업무를 수행하는 데 필요한 데이터에 대한 요구일 수도 있고 데이터 구조에 대한 요구일 수도 있고 업무를 빨리 처리할 수 있도록 하는 성능에 대한 요구일 수도 있다.
• 요구 사항은 사용자의 의견을 최우선으로 따른다. 주로 현업과 인터뷰를 통해 도출한다.

 

- 개념 모델링 단계

• 개념 모델을 구축한다.
• 개념 모델은 사실 요구 사항을 분석하고 나서 도출되는 데이터 측면의 결과물이다.
• 요구 사항 분석과 개념 모델은 수행한 내용과 결과의 관계이므로 현실적으로 별개의 단계는 아니다.
• 주로 ERD를 사용해서 표현한다.
• 개념 모델링 단계에서는 핵심 데이터를 대상으로 모델링을 수행해야 하며 통합된 모델이 도출돼야 한다.

 

- 논리 모델링 단계

• 핵심 데이터를 포함한 모든 데이터를 대상으로 모델리을 수행하는 단계이다.
• 이 단계에서 해야 할 가장 중요한 타스크는 정규화(Normalization)이다. 정규화는 함수 종속(Functional Dependency)에 의해 데이터를 분해하는 것이다.
• 이 단계에서는 더 분해할 수 없는 엔터티의 모습이 나타나게 된다. 이렇게 더 분해되지 않도록 최대한 분해된 모델을 정규형이라고 하고 정규화된 모델을 논리 모델(Logical Model)이라고 한다.

 

- 물리 설계 단계

• 논리 모델을 물리 모델로 매핑하고 목적에 따라 테이블을 분해하거나 합치는 작업을 한다.
• 이 단계에서는 가능한 성능을 최적화해야 한다. 그러기 위해서 중요한 작업이 비정규화(Denormalization)이다.
• 인덱스 설계가 포함된다. 인덱스 설계는 대단히 중요한데 물리 설계 단계에서 완전하게 이루어지지 않는다.

 

- 데이터베이스 구축 단계

• 물리 설계에서 도출된 여러 객체(테이블, 인덱스, 제약 등)를 생성하는 단계이다.
• 물리 설계에서 스크립트가 나오므로 이 단계에서는 모델러보다는 DBA가 수행하게 된다.

 

 

2.4. 주제 영역(Subject Area)

 

 

- 데이터 아키텍처의 최상위 단계로 비즈니스의 목표를 달성하는 데 필요한 데이터 집합을 의미한다.

 

- 여기저기에 산재된 유사한 성격의 데이터를 체계화해 그룹으로 묶은 것을 의미한다.

 

- 주제 영역을 정의하려면 기업에 존재하는 모든 데이터를 파악해야 한다.

 

- 주제 영역이 한없이 늘어날 수 없으므로 모든 데이터는 10개 또는 20개로 정의된 주제 영역에 속해야 한다.

 

- 각 주제 영역의 상세화 수준도 균일해야 한다.

 

- 고객이나 조직, 계좌와 같은 주제 영역은 실체 성격의 주제 영역이다. 이런 주제 영역은 누가 모델링을 하더라도 유사해질 수 있다.

 

- 이벤트, 거래 등의 주제 영역은 행위 성격의 주제 영역으로 모델링을 수행하는 사람에 따라 모델이 달라질 수 있다.

 

- 하위 개념의 서브 주제 영역으로 분류할 수 있으며 주제 영역 내에서는 데이터를 상세하게 정의한 엔터티를 관리하게 된다.

 

- 주제 영역은 기업의 정보 체계 구조를 한눈에 파악하고 관리하기 위해 구축된다. 즉 데이터 모델링을 하지 않더라도 주제 영역은 정의돼야 한다.

 

- 논리 모델과 주제 영역은 완전하게 연결(Alignment)돼야 한다.

 

- 이렇게 주제 영역의 하위 레벨에 개념 모델과 논리 모델, 몰리 모델 등의 데이터 모델이 존재하는 것이 이상적이지만 실무에서 이렇게 관리되는 예는 매우 드물다. 일단 주제 영역을 도출하는 예가 많지 않으며 주제 영역을 도출했더라도 활요하지 않는다. (현행은 업무 영역이나 어플리케이션 영역으로 데이터 모델이나 물리 테이블이 관리되는 경우가 많음)

 

 

 

2.5. 데이터 표준화

 

 

- 일정한 기준에 따라 통일시키는 것이 데이터 표준화의 핵심이다.

 

- 속성이 데이터 표준화의 주된 대상이다.

 

- 데이터 표준화를 수행하는 이유는 데이터의 품질을 높이기 위해서이다. 일관된 사용은 데이터 오류를 줄여주므로 품질이 높아진다.

 

- 표준화를 할 때는 사전적인 의미에 얽매일 필요는 없을 것 같다. 그보다 더 중요한 것은 일관되도록 사용하는 것이다. 예를 들어 사원과 직원이라는 용어 중에서 사원을 사용하기로 원칙을 정했다면 '사원번호'와 '직원번호'가 같이 사용되면 안된다. 같이 사용되지 않도록 시스템에서 제어해 줘야 한다.

 

- 데이터 표준화의 출발은 단어를 정의하는 것이다. 단어를 정의할 때 주의할 것이 이음동의어(Synonym)와 동음이의어(Homonym)이다. 두 가지 모두 허용하지 않는 것이 바람직하다고 생각한다.

 

- 도메인(Domain)은 데이터 타입과 길이, 포멧 등이 같은 값의 집합이다. 하나의 속성에는 허용된 유효한 값의 형태가 같아야 하므로 도메인이 하나만 사용돼야 한다.

 

- 표준화 원칙의 예

• 특정한 날짜를 의미할 때는 '일자'를 사용한다. 예) 입금일자
• '시분초'까지 의미할 때는 '일시'를 사용한다. 예) 방문일시
• 년, 월, 일 중 일부만 의미할 때는 '년', '년월', '월', '월일', '일' 등으로 사용한다. 예) 회계년, 기준년월, 적용월, 이체일
• 비율을 의미할 때는 '율'을 사용한다. 예) 이율
• '율'은 맞춤법에 따라서 '율수수로율)'이나 '률(증거금률)'로 사용해야 하지만 일관성을 위해 하나만 사용하는 것이 좋다.

 

 

2.6. ERD(Entity Relationship Diagram)

 

 

- ERD는 데이터를 함축적이고 이해하기 쉽게 표현해 주는 다이어그램이다.

 

- ERD를 작성할 때는 엔터티를 배치하는 것이 중요하다.

• 상위(부모) 엔터티와 하위(자식) 엔터티는 상하 또는 좌우로 위치하는 것이 좋다.
• 슈퍼타입과 서브타입 관계는 상하 또는 좌우로 위치하는 것이 좋다.
• 실체 엔터티는 모델의 위쪽에 위치시키는 것이 좋다.
• 행위 엔터티는 일반적으로 실체 엔터티의 아래쪽에 있게 된다.
• 가공 엔터티는 별도로 위치시킬 수 있고 연관된 행위 엔터티 주변에 위치시킬 수도 있다.
• 관계가 존재하는 두 개의 행위 엔터티는 좌우로 나란히 위치시키는 것이 좋다.
• 교차 엔터티(Association Entity)는 양쪽 엔터티 사이에 위치하는 것이 좋다.
• 데이터 마트에서 주로 사용되는 팩트(Fact) 엔터티와 디멘젼(Dimension) 엔터티의 관계라면 팩트 엔터티 사방으로 디멘젼 엔터티를 배치시킬 수 있다.

- 엔터티의 속성 순서를 적절하게 위치시키는 것도 모델의 가독성을 높이는 효과를 가져다준다. 논리 모델이나 물리 모델에서 엔터티의 속성 순서는 나름대로 의미가 있다.

 

- 주 식별자는 엔터티의 최상단에 위치해야 한다. 주 식별자 다음으로 대체 식별자가 오는 것이 좋다.

 

- 일반 속성은 기초 속성(Basic Attributes)이 엔터티 위쪽에 위치하게 된다.

 

- 추출 속성(Derived Attributes)과 중복 속성은 기초 속성과 주로 같이 사용되는 속성이라면 같은 위치에 존재하는 것이 좋다.

 

- 기초 속성과 주로 같이 사용되지 않으면 엔터티 아래쪽에 존재하는 것이 좋다.

 

- 엔터티 가장 하단에는 시스템 속성(System Attributes)이 위치해야 한다.

 

- 물리적 요소를 고려해서 논리 모델링 단계에서 속성의 순서를 정하는 것이 바람직하다.

 

- 관계선을 표현할 때는 관계선이 서로 얽히지 않게 표현해야 한다.

 

- 관계선이 엔터티를 통과하지 않도록 한다.

 

- ERD는 엔터티의 스키마를 표현하는 도구이므로 ERD만으로 이해나는 데 한계가 있을 수 있다. 중요 데이터에 대해서는 사례 데이터를 릴레이션으로 생성해 놓는 것이 좋다.

 

- ERD와 사례 데이터 릴레이션이 있다면 데이터를 이해하는 데 많은 도움이 될 것이다.