6-1. DW 아키설계, 프로젝트 산출물

1. DW 모델링의 개요

​

가. DW 모델링 유형

1) EDW - ER모델링 기법을 적용하지만 차이점은 운영계 시스템으로부터 Reverse Modeling 과정을 거침

2) Data Mart - 다차원 모델링 기법적용

​

나. Reverse Modeling 의 목적

- 현행 시스템을 형상화하여 운영계 시스템의 데이터실체와 데이터구조를 파악할 수 있음

- 최종적으로 사용되고 있는 물리적인 스키마로부터 리버스 모델링을 수행하는 과정에서 변경,추가된 항목을 도출 할 수 있음

- EDW Data Model의 기초자료로 이용하여 분석작업의 효율화를 이룸

- ETT 작업 EDW Data Model의 데이터와 mapping 관계를 파악할 수 있음

- 데이터 무결성이 깨진 오류 데이터 등 cleansing 대상을 파악할 수 있음

​

2. 다차원 모델링 기법의 개요

​

가. 다차원 모델링 기법의 정의

-관계형 데이터베이스로 다차원 데이터를 구현 하는데 사용되는 기법으로 Data Warehouse의 요소기술

 

나. 다차원 모델링 기법의 종류

1) Star Schema - 정규화된 Fact Table을 중심으로 비정규화된 Dimension Table들이 배치되는 형태의 모델링 기법

2) Snowflake Schema - 정규화된 Fact Table을 중심으로 정규화된(제3 정규형 수준) Dimension Table들이 배치되는 형태의 모델링 기법

​

​

다. 다차원 모델의 특징

- 식별된 질문에 답하는 데 필요한 세분화 수준을 정의

- 모델링 단계에서 DSS / EIS 분석자 참여

- 논리적 DW 모델링에서는 Performance 보다는 Integrity, Completeness Clarity(완벽한 명확성) 중요

​

3. 다차원 모델링 기법의 특징

4. 다차원 모델링 기법

​

가. 스타스키마 (Star Schema)

- 다차원 의사결정 지원 데이터를 관계형 데이터베이스로 전환하는 데 사용되는 데이터 모델링 기법

- 사실 테이블을 중심으로 차원 테이블들이 관계를 맺고 있는 형태가 별 모양과 유사해서 Star Schema 명칭부여

 

 

 

 

 

 

나. 스노우플레이크 스키마 (Snowflake Schema)

- 스타스키마에서 차원이 대용량일 경우 발생하는 처리속도 저하 문제를 해결하기 위해 제시된 데이터모델링 기법

- 스타스키마의 차원 테이블을 완전 정규화시킨 것임.

 

 

 

5. 다차원 모델링 기법 비교

​

6. DW 모델링의 성능향상 기법

가. Aggregation (De-normalization : 비정규화) 기법

- Query 수행능력 향상

- CPU 사용시간 감소

- View 이용

- Summarized Table 이용

나. Partition 기법

- large Size Table을 다수의 Small Size Table로 분할함으로써 질의응답 속도향상

- 메타데이터 필요

​

다. PCTAS(Parallel Create Table As Select) 기법

- Parallel Query 수행, 속도 10 ~15배 향상

- Table Create 시 Parallel Option을 사용

​

라. DW 모델링 기법의 경향

- Snowflake Schema의 최대 장점은 정규화를 통해서 저장공간을 절약하는 것인데, 비용부담이 적어지면서 검색속도만 저하시키는 결과를 초래하여 별로 사용되지 않음

​

​

데이터베이스 스키마(Database Schema) 란?

​

데이터베이스의 구조와 제약 조건에 관한 전반적인명세를 기술한 메타데이터의 집합이며, 데이터베이스를 구성하는 데이터 개체(Entity), 속성(Attribute), 관계(Relationship) 및 데이터 조작 시 데이터 값들이 갖는 제약 조건 등에 관해 전반적으로 정의한다.

스키마는 사용자의 관점에 따라 외부 스키마, 개념 스키마, 내부 스키마로 나뉜다.

​

외부 스키마(External Schema) : 서브 스키마라고도 불린다. 하나의 외부 스키마는 여럿이 공유 가능하며, 하나의 DB시스템에 여러 개의 외부 스키마가 존재할 수 있다. 프로그래머나 사용자의 입장에서 데이터베이스의 모습으로 조직의 일부분을 정의한다.

​

개념 스키마(Conceptual Schema) : 모든 응용 시스템과 사용자들이 필요로 하는 데이터를 통합한 조직 전체의 데이터베이스 구조를 논리적으로 정의하며 개체간의 관계와 제약조건을 나타낸다. 또한, 데이터베이스의 접근 권한, 보안 및 무결성 규칙에 관한 명세를 정의한다.

​

내부 스키마(Internal Schema) : 시스템 프로그래머, 설계자의 관점에서 바라본다. 전체 데이터베이스의 물리적 저장 형태를 기술하기에 하나만 존재하여야 한다. 일반적으로 스키마를 말할 때 내부스키마를 가리킨다.

​

1. OLTP (온라인 트랜젝션 처리 = on-line transaction processing)

- 여러 과정 또는 연산이 하나의 단위 프로세스로 실행되도록 하는 프로세스

- 현재 업무의 효율적인 처리에만 관심이 있음

- 관계형 데이터베이스(RDB)

 

2. OLAP (온라인 분석처리 = online analytical processing)

- 다차원으로 이루어진 데이터로부터 통계적인 요약정보를 제공할 수 있는 기술

- 의사결정에 도움되는 데이터 분석에 관심이 있음

- 다차원 데이터베이스(MDB OR MDDB)

 

3. 다차원 모델링의 정의

- DW 모델링 시 사실 테이블(FACT)과 차원 테이블(DIMENSION) 간 상호관계를 정의하여 다차언으로 구현하는 모델링 기법

 

4. 다차원 모델링의 구성요소

- 사실(FACT) : 중심 테이블로서 관련성이 높은 매체 집합

- 차원(DIMENSION) : 부속 테이블. 각 FACT를 분석하는 하나의 관점

- 속성(ATTRIBUTE) : 각 차원의 테이블이 가지고 있는 속성. 사실을 검색하고 여과하고 분류할 때 사용됨.

- 속성계층(HIERARCHIES) : 차원 내 정의된 속성들 간 존재 계층 관계. 아래로 가기(DRILL-DOWN) 및 위로가기(ROLL-UP)등 기능

 

5. 다차원 모델링의 기법

- Star Schema

: 정규화된 Fact Table을 중심으로 비정규화된 Dimension Table들이 배치되는 형태의 모델링 기법

- Snowflake Schema

: 정규화된 Fact Table을 중심으로 정규화된(제 3정규형 수준) Dimension Table들이 배치되는 형태의 모델링 기법

 

6. 스타 스키마와 스노우 플레이크 기법 비교

 

	Star Schema	Snowflake Schema
장점	- 조인의 수가 적으므로 쿼리에 대한 성능이 좋다. - 모델이 단순하여 사용자가 이해하기 쉽다.	- 정규화가 잘되어 있어 데이터의 중복이 적다. - 테이블의 크기가 작아 저장 공간이 작다. - Performance flexibility, maintain 능력을 향상 시킬 수 있다.
단점	- 중복이 많다. - 많은 수의 요약이 필요하다. - 많은 저장 공간이 필요하다. - 데이터 일관성에 문제가 발생한다. - Inflexible하다.	- 조인의 수가 많아 속도가 저하된다. - 복잡하기 때문에 사용자가 이해하기 어렵다. - 데이터베이스 내 관리 테이블의 수가 증가한다.

 

7. 스키마의 개념

- 데이터 베이스의 구조와 제약 조건에 관한 전반적인 명세를 기술한 메타데이터의 집합이다.

- 스키마는 데이터 베이스를 구성하는 데이터 개체(Entity), 속성(Attribute), 관계(Relationship) 및 데이터 조작 시 데이터 값들이 갖는 제약 조건 등에 관해 전반적으로 정의한다.

- 스키마는 사용자의 관점에 따라 외부 스키마, 개념 스키마, 내부 스키마로 나누어진다.

 

8. 스키마의 특징, 3계층

- 데이터베이스 관리 시스템은 외부적 스키마에 따라 명시된 사용자의 요구를 개념적 스키마에 적합한 형태로 변경하고 이를 다시 내부적 스키마에 적합한 형태로 변환한다.

- 스키마는 데이터 구조적 특성을 의미한다.

- 스키마는 데이터 사전(Data Dictionary)에 저장된다.

- 스키마는 현실 세계의 특정한 한 부분의 표현으로서 특정 데이터 모델을 이용해서 만들어진다.

- 스키마는 시간에 따라 불변인 특성을 갖는다.

- 스키마는 데이터 논리적 단위에 명칭을 부여하고 그 의미를 기술한다.

 

 

1) 외부스키마(External Schema) = 사용자 뷰(View)

è 외부스키마는 사용자나 응용프로그래머가 각 개인의 입장에서 필요로 하는 데이터베이스의 논리적 구조를 정의한 것

è 외부스키마는 전체 데이터베이스의 한 논리적인 부분으로 볼 수 있으므로 서브 스키마(Sub Schema)라고도 함

è 하나의 데이터베이스 시스템에는 여러개의 외부스키마가 존재할 수 있으며 하나의 외부스키마를 여러개의 응용 프로그램이나 사용자가 공용할 수도 있음

è 같은 데이터베이스에 대해서도 서로 다른 관점을 정의할 수 있도록 허용함

è 일반 사용자는 질의어(SQL)을 이용하여 DB를 쉽게 사용할 수 있음

è 응용 프로그래머는 C, JAVA 등의 언어를 사용하려 DB에 접근함

EX) 한 사용자는 SELECT * FROM TABLE; 을 사용해 데이터를 볼 수 있다. 다른 사용자는 JOIN을 통해 테이블을 결합해 조회할 수 있다.

SELECT 쿼리를 던졌을 때 볼 수 있는 테이블을 외부스키마의 대표적인 예 라고 할 수 있다.

 

2) 개념스키마(Conceptual Schema) = 전체적인 뷰(View)

è 개념스키마는 데이터베이스의 전체적인 논리적 구조로서, 모든 응용 프로그램이나 사용자들이 필요로 하는 데이터를 종합한 조직 전체의 데이터베이스로 하나만 존재함

è 개념스키마는 개체간의 관계와 제약 조건을 나타내고 데이터베이스의 접근 권한, 보안 및 무결성 규칙에 관한 명세를 정의함

è 데이터베이스 파일에 저장되는 데이터의 형태를 나타내는 것으로, 단순히 스키마(Schema)라고 하면 개념스키마를 의미함

è 기관이나 조직체의 관점에서 데이터베이스를 정의

è 데이터베이스 관리자(DBA)에 의해서 구성됨

EX) E-R 다이어그램의 테이블 구조와 같이 테이블의 구성과 속성이 어떻게 되는지 또한 어떤 테이블과 릴레이션을 갖고 있는지 등의 점을 개념스키마라고 한다.

 

3) 내부스키마(Internal Schema) = 저장스키마(Storage Schema)

è 내부스키마는 물리적 저장장치의 입장에서 본 데이터베이스 구조로, 물리적인 저장장치와 밀접한 계층

è 내부스키마는 실제로 데이터베이스에 저장될 레코드의 물리적인 구조를 정의하고, 저장 데이터 항목의 표현 방법, 내부 레코드의 물리적 순서 등을 나타냄

è 시스템 프로그래머나 시스템 설계자가 보는 관점의 스키마

EX) INSERT 문에 의해 저장되는 VALUES가 어떠한 알고리즘으로 하드디스크의 어떠한 부분에 저장이 되는데 이러한 시스템적, 물리적의 시각의 스키마를 내부스키마라고 한다.

 

 

 

 

 

1. 데이터 모델

 

1.1 데이터 모델의 정의

데이터의 집합을 기술하는데 사용되는 개념이며, 데이터를 조작할 수 있는 연산들의 모임을 의미한다. 데이터는 키(주 식별자)와 일반 칼럼(속성, Attribute)올 표현이 되며 키와 칼럼들이 모인 로우(레코드), 하나 이상의 로우가 모인 테이블(모델링 단계에서는 엔티티)이 되는데, 모든 용어들이 데이터의 표현에 사용된다.

 

1.2 데이터 모델의 종류

가. 개념적 모델(Conceptual Model)

현실 세계의 업무규칙(업무처리흐름상의 규칙, 양식 등의 자료를 구성하는 데이터들의 상관관계 규칙)을 개략적으로 데이터 모델을 사용하여 표현을 하되, 각각의 사업장, 부서 등에 대해서 개별적인 데이터 모델이 작성될 수 있다.

나. 논리적 모델(Logical Model)

개념적 데이터 모델을 통합한 것으로써, 각각의 사업장, 부서 등의 데이터를 구성하는 속성들의

도메인(자릿수, 형태, 초기 값 등)이 통합되어 표현 된다.

 

논리적 데이터 모델은 특히 다음과 같은 특성을 가지고 있다.

■ 데이터베이스 설계 시 사용

■ 주어진 현실세계로부터 개념의 집합을 명세

■ 높은 수준의 추상화에서 현실세계를 표현하는 도구

■ 현실세계를 이해하기 쉽고 해석하기 쉽도록 현실세계를 명세

 

논리적 데이터 모델의 평가기준은 다음과 같다.

■ 표현성(Expressiveness)

■ 단순성(Simplicity)

■ 최소성(Minimality)

■ 정형성((Formality)

 

다. 물리적 모델(Physical Model)

논리적 데이터 모델과 비교한 물리적 데이터 모델의 특징은 다음과 같다.

■ 특정 DBMS에 의해 지원됨

■ 컴퓨터에 의해 처리될 수 있는 데이터 명세를 지원

■ 종류 : 계층형 모델, CODASYL 모델, 관계형 모델

 

 

1.3 데이터베이스 구축과정으로 본 데이터 모델의 의의

데이터베이스 구축과정은 현실세계의 데이터와 업무를 데이터 모델의 세계로 Mapping시키는 과정이라고 할 수 있다. 데이터베이스는 현실 세계의 데이터와 업무를 그들의 세계로 안내하는데 있어서 그들이 채택한 모델을 통하여 안내한다. 즉, 모델의 표현규칙, 작성규칙을 따라 현실세계의 자료와 업무가 표현된다. 다시 말하면 컴퓨터세계와 현실세계의 연결다리 역할을 하는 것이 바로 이 모델이다. 데이터베이스 관리시스템(DBMS) 또한 이 모델을 근거로 각종 자동화 처리기를 제작했다. 따라서, 데이터베이스 시스템을 구축 시에 필수적으로 그들이 채택한 데이터 모델에 대하여 정통할 필요가 있다.

 

 

 

2. 데이터 모델링

 

2.1 데이터 모델링 절차

다음은 일반적인 데이터 모델링 절차이다.

일반론적인 데이터 모델링 절차 그림에서 '데이터 모델 콘테스트' 및 '업종별 표준 데이터 모델'의 제작과 관련하여 엔티티 정의, 관계 정의, 엔티티-관계도 작성, 주/부 식별자 정의, 외부 식별자 정의, 세부속성 정의에 대해서만 설명하기로 한다. 나머지 부분들은 일반 책자들에 잘 설명이 되어 있으므로 참고하기 바란다.

 

2.2 엔티티 정의

가. 엔티티의 종류

엔티티의 종류는 독립 엔티티(Kernel Entity, Master Entity), 업무중심 엔티티(Transaction Entity), 종속 엔티티(Dependent Entity), 교차 엔티티(Associative Entity, Relative Entity)의 4종류로 분류된다.

1) 독립 엔티티(Kernel Entity, Master Entity)

사람, 물건, 장소, 개념처럼 원래부터 현실세계에 존재하는 엔티티.

예) 사원, 고객, 영업부, 창고, 생산계획, 계정과목 …

 

2) 업무중심 엔티티(Transaction Entity)

업무가 실행되면서 발생하는 엔티티

예) 주문, 납품, 대금청구, 대금지급 …

 

3) 종속 엔티티(Dependent Entity)

주로 1차 정규화(1st Normalization)로 인하여 관련 중심엔티티로 부터 분리된 엔티티

예) 주문품목, 납품품목 …

 

4) 교차 엔티티(Associative Entity, Relative Entity)

다:다 관계를 해소하려는 목적으로 인위적으로 만들어진 엔티티

 

나. 엔티티의 자격조건

엔티티의 종류는 독립 엔티티(Kernel Entity, Master Entity), 업무중심 엔티티(Transaction Entity), 종속 엔티티(Dependent Entity), 교차 엔티티(Associative Entity, Relative Entity)의 4종류로 분류된다.

 

다. 엔티티의 예

다음 표는 엔티티의 사례를 보여주는 표이다.

① 사람

(사원(직원, 행원, 공원,…), 계약자(가입자, 회원,…), 이용자(학생, 환자,…))

② 물건

(재료(부품, 원자재, 연료, …), 상품(제품,…), 시설(건물, 창고, 운송센터,…), 지점(영업소, 소매점,…))

③ 사건

(계약(수주,발주,…), 작업(공정, 보관, 선전, 광고,…), 사고(재해, 고장,…))

④ 장소

(구획(창고, 선반, 진열케이스, 생산라인, …), 지역(판매구역, 관할구, 선거구,…), 하천, 항만(부두, 선창,…))

⑤ 개념

(목표, 계획(지침, 방침, 지표, 판매목표, 생산계획, 판매계획, 인원계획,…), 시간(월, 일, 년, 시각, 시각분할,…), 평가(기준, 지표))

⑥ 금전

(예입금(구좌,…), 예산(년간예산, 수정예산, 실행예산,…), 차입(단기, 장기,…), 융자(단기, 장기,…))

 

 

 

 

 

2.3 관계(Relationship) 정의

가. 기수성(Cardinality)

기수성은 다음과 같이 정의된다.

■ 1:1, 1:M, M:N 관계

■ 해당엔티티 1건에 대한 상대엔티티의 기수성을 상대 엔티티쪽에 표기

■ 표기 방법(James Martine 표기법)

 

나. 선택성(Optionality)

선택성은 다음과 같이 정의된다.

■ 집합의미 (포함, 불포함)

■ 1:0 (Optional), 1:1 (Mandatory)

■ 해당엔티티 1건에 대한 상대엔티티의 기수성을 상대엔티티쪽에 표기

■ 표기 방법(James Martine 표기법)

 

다. 관계의 완성 : 기수성과 선택성의 통합 [James Martin]

기수성과 선택성을 통합하면 관계가 완성이 된다.

■ 해당 엔티티를 기준으로 기수성의 경우의 수와 선택성의 경우의 수를 합하여 최소값과

최대값의 경우의 수를 구한 후 해당 엔티티쪽에 최대값을 바깥쪽에 최소값을 표기한다.

■ 상대 엔티티도 유사한 방법으로 표기한다.

 

라. 관계의 완성 사례

다음은 '고객'엔티티와 '주문'엔티티에 대하여 관계를 작성하는 절차를 보여주는 사례이다.

■ 기수성 : 각 고객은 하나 이상의 주문을 할 수도 있고 안 할 수도 있다.

■ 선택성 : 각 주문은 고객이 하는 것도 있고 그렇지 않을 수도 있다. (사원이 할 수도 있다.)

 

관계를 완성할 때 흔히 나올 수 있는 경우에 대한 대처 방법을 설명하기로 한다.

첫째, 기수성과 선택성의 통합 시 다:다 관계가 나올 수가 있는데 이는 Table Join이 안되므

로 (외부 키의 표시가 불능) 교차 엔티티를 이용하여 표기한다.

 

둘째, 관계는 두 엔티티간의 업무규칙(Business Rule)을 토대로 인위적인 방법으로 기수성

과 선택성을 구하여 이를 통합하여 완성된다.

 

셋째, 관계(Relationship) 표기의 의미는 두 엔티티 중에서 외부키(Foreign Key)가 놓이는

자식 엔티티를 구분하기 위한 것이 첫째 임무이다. 외부키는 부모엔티티의 기본키(Pri

mary Key)가 되기 때문이다. 둘째 임무는 외부키 무결성(관계무결성)을 구하기 위한

것이다.

 

넷째, 기수성 표기, 선택성 표기, 관계통합 표기 방법이 각 교수나 RDBMS 업체에 따라 다를

수 있는데 큰 문제가 되지 않는다. 왜 관계(Relationship)를 구하는 가의 이유만 알면

되기 때문이다.

 

 

 

 

 

2.4 엔티티

가. 작도방법

다음은 엔티티-관계도를 효과적으로 작성하는 기법을 설명하기로 한다.

■ 사각형의 도형 안에 엔티티명을 기록

■ 업무흐름의 진행순서와 관련된 엔티티는 진행순서를 고려하여 좌에서 우 또?고")

■ 중심에 배열된 엔티티와 관계를 가진 연관엔티티(종속엔티티)를 가까운 쪽으로 배열

("주문" : "주문품목", "출고" : "출고품목")

■ 배열된 엔티티와 관계를 갖는 핵심엔티티(Kernal Entity)를 외곽으로 전개

("주문", "고객", "영업담당자", "창고", "품목", "제품")

■ 해당엔티티의 한 건에 대한 상대엔티티의 기수성(Cardinality)을 상대 엔티티쪽에 표기함으

로써 관계의 기수성을 표기 :

■ 해당엔티티의 한 건에 대한 상대엔티티의 선택성(Optionality)을 상대 엔티티쪽에 표기함으

로써 관계의 선택성을 표기 :

 

나. 주요성공요소

엔티티-관계도를 작성하는데 있어서 주요성공요소는 다음과 같다.

■ 엔티티를 식별하고, 관계를 도출한 후 ERD작도법에 맞추어 ERD를 작성

■ 업무흐름 및 업무규칙의 ERD작도 시 활용

 

다. 엔티티-관계도와 관련된 실무적인 의미 및 검증기준

다음은 엔티티-관계도의 실무적인 의미와 작성시 유의사항이다.

첫째,

엔티티-관계도는 데이터베이스의 형상(Schema)을 결정하는 매우 중요한 그림이다.

둘째,

엔티티-관계도는 업무흐름을 나타낼 수 있어야 하며, 중요한 데이터속성들이 모두 표현되어 있어야 한다. 따라서 엔티티-관계도는 표현규칙 및 작성규칙에 충실하게 따라서 작성이 되어야 한다.

셋째,

엔티티-관계도를 그리다 보면 선이 겹치는 경우가 많이 발생하는데, 이는 상기한 작도방법을 따르지 않은 것으로 많은 문제를 야기할 수 있다.

 

다음은 실무적으로 엔티티-관계도를 효과적으로 작성하는 절차이다.

■ 엔티티의 배열

■ 관계의 연결

■ 기수성 정의 (기수성명 표기)

■ 선택성 정의 (선택성명 표기)

■ 기수성과 선택성의 통합 : 엔티티-관계도의 완성

■ 관계가 다:다일 경우에 교차엔티티를 이용하여 일대다로 분리함

 

다음은 엔티티-관계도의 검증기준이다.

■ 작성규칙 및 데이터모델 표현규칙 적합성, 단순성, 확장성, 비중복성, 공유성

■ 모든 속성의 표현

■ 관계표기의 적합성

■ 사용자의 데이터요구(화면, 보고서 등)에의 성능 우수성

 

 

 

 

 

2.5 주식별자(Primary Identifier, primary Key, 주키) 정의

다음은 주식별자에 대한 정의절차이다. 이해하기 쉬우므로 간략하게 절차만 설명한다.

 

 

■ 각 엔티티별로 하나의 주식별자 선택

■ 후보 식별자 중 가장 중요한 하나를 주식별자로, 나머지를 대체키로 지정

■ Subtype엔티티의 주식별자는 Supertype엔티티의 주식별자와 동일하게 선택

■ 데이터 이름에 대한 표준약어목록의 이용

 

 

2.6 외부식별자(Foreign Identifier, Foreign Key, 외부키) 정의

가. 외부식별자의 특징

외부식별자는 다음과 같은 특징을 가진다.

■ 두 엔티티간의 관계를 결정하여 주는 속성으로 관계에 의한 자식엔티티에 위치하며 부모엔

티티의 주식별자가 같은 값을 갖는다.

■ 논리적 데이터 모델내의 모든 관계에 관련된 외부키를 규명한다.

 

나. 외부식별자의 표기 사례

다음 그림은 외부식별자의 표기 예를 보여준다.

 

 

2.7 속성 정의

가. 속성 정의

속성이란 엔티티를 구성하는 더 이상 분리될 수 없는 정보단위로 식별자 종류(기본, 대체, 외부 키)와 비식별자(non-key)로 구분한다.

 

나. 효과적인 속성 정의방법

다음과 같은 방법으로 속성을 찾아 정의한다.

■ 정보 분석단계에서 수집된 각종자료 참조

■ 엔티티, 관계 정의시 파악

■ 기존 정보시스템 분석 - 관련 DB나 file의 field

■ 속성의 이름을 부여 - 표준화 규칙 사용, 자료사전에 기록

 

다. 속성 정의 예

다음 표는 제품 엔티티에 대한 속성 정의 예이다.

엔티티

속성

속성유형

식별자구분

비고

제품

제품코드

설계

PK

 

제품명

기초

 

 

기대수요

기초

 

 

 

재주문요구

기초

 

 

 

 

 

 

 

2.8 데이터 모델 검증 및 주요성공요소

가. 데이터 모델 검증 방법

데이터 모델 검증은 아래와 같은 범위의 품질기준에 맞추어 검증한다.

■ Group Check

Business rule에 의한 완전한 이해와 E-R Modeling에 대한 완전한 이해를 가진 숙련된 분석가가 최선의 답이며, Project 팀 내의 동료끼리 상호 모델을 Check하고 오류를 찾아 본다.

■ 사용자(End User) 확인

정기적으로 사용자에게 모델을 제시하면서 확인하거나, 사용자를 참여시켜 Error와 누락된 것을 check한다.

■ 업무규칙(Business Rule)

■ 엔티티품질 검증

■ 속성품질 검증

■ 관계품질 검증

■ 완전성 검증

사용자 INTERVIEW, 서류양식, 장표, 보고서 등과 비교 점검하여 추가되거나 누락된 것이 없는지를 확인하고, 향후 입력, 출력보고서가 모두 적용될 수 있는지를 점검한다.

 

나. 주요성공요소

데이터 모델링을 잘하기 위하여 다음과 같은 내용들을 숙지한다.

첫째,

분석단계의 Data Modeling(산출물: Logical ERD)과 설계단계(산출물: Physical ERD)의 구분

■ Business Rule이 같기 때문에 분석단계의 ERD(Entity로 표시)와 설계단계의

ERD(Table로 표시)의 근본구조는 달라지지 않는다.

■ 분석단계의 ERD에서 약 20%내외만이 수정이 되어 설계단계의 ERD로 바뀐다.

■ 설계단계에서는 성능(Performance)을 고려한 Summary, Duplicate, Processin

g Table이 만들어진다.

둘째,

엔티티-관계도(ERD) 작성 및 검증요령

■ 현재의 장표, 양식, 업무 매뉴얼, 보고기준 (정보관리대상, 유일한 키의 존재, 키 이외의 속성 가질 것) 엔티티(Entity)

를 추출 하여 적어 놓는다.)

■ 엔티티 사이의 Business Rule을 분석하여 그들 사이의 관계를 찾는다.

관계유형>

▶ Dynamic flow(업무흐름도에 의존 :주문→생산지시→제품입고 → 출고 →납품)

▶ Static flow(데이터 자체의 관계 : BOM Type, Super-Sub Type)

▶ Transient flow(시간이 가면 변하는 것 : 정산-미정산 분개의 확정 시점)

■ 향후 입력화면, 출력보고서가 현재의 ERD에서 추측될 수가 있고 계산하기 편한

가 등의 기준으로 엔티티-관계도를 검증한다.

세째,

엔티티(Entity, Table)를 분해한 후 합칠 수 있다

■ 엔티티-관계도 작성시 핵심엔티티(독립엔티티, 코드엔티티 : kernel Entity)를

구별함

■ Sub-system만 제작한 다음 나중에 통합할 수 있다.

네째,

엔티티-관계도를 제대로 못 그리는 이유 : Business Rule을 제대로 분석하지 못했기 때문

■ Business Rule에 숨어있는 Data를 분석해내지 못했고 그들 Data사이의 관계를

분석하지 못했기 때문

■ ER 방법론 미 숙지

■ Business Rule해독 90%, ER방법론 숙지 10%

다섯째,

관계형 데이터베이스 모델링은 속성(Attribute)끼리의 Logical Model이다

■ 속성(Attribute끼리의 Business Rule → Relationship

■ 물리적 의미(Physical meaning) → Relational Key(외부키)의 정의

여섯째,

관계형 데이터베이스는 속성(Attribute)접근 방식이지 Pointer접근방식(COBOL문의 OCCURS, Redefine)이 아님, 즉 같은 TYPE의 속성은 중복되면 안 된다.

일곱째,

엔티티-관계도(ERD)작성시 속성 검출 및 정규화 유의사항

■ 속성(Attribute)은 가장 최소로 자른다. (예 : 년월일→년, 월, 일)

■ 주키(Primary Key)가 나누어지는 것은 분석이 잘못되었기 때문이다

■ 1차, 2차, 3차 정규화를 잘 할 것

여덟째,

다대다(Many to Many)관계가 해소되어야 하는 이유와 해소 방법

■ 속성(Attribute)사이에만 관계(Relationship)가 생성하는데, Many to Many는

관계를 맞출 수가 없다.

■ 비교엔티티 (연결엔티티, 교차엔티티)를 집어넣어준다

: 양쪽의 엔티티(Entity)와 속성(Attribute)이 서로 key나 Data부분의 속성

(Attribute)으로 들어가기만 하면 된다.

아홉째,

Logical Design(Data중심)과 Physical Design(사용하는 DBMS, System 중심)을 완전히 분리할 것

■ Summary Table은 Relationship으로 표시가 불가하다.

(Logical Data Modeling에서는 표시가 안됨)

■ Physical개념 : Processing 개념

열째,

엔티티-관계도 (ERD)를 작성시 Top-Down과 Bottom-up을 병행하면서 진행한다. 왜냐하면 Entity의 분할과 Attribute의 상세한 define이 발생하기 때문이다.

열한째,

엔티티-관계도 작성시 선택성(Optionality)을 구분해줄 필요가 있으나 치명적이지 않다.

 

 

 

 

 

 

프로젝트 산출물 목록 Project 관리

프로젝트 관리 산출물 (1권)

1) 프로젝트 수행 계획서

2) 프로젝트 Work plan

3) 프로토타이핑 계획서

3) 설계 단계 완료 QA 보고서

4) 시스템 유지보수 지원 계획

5) 프로젝트 완료 보고서

프로젝트 산출물 (2, 3, 4권)

1) 분석 단계

- 인터페이스 요건 정의서 (요구사항 정의서)

- 기능 요구사항 정의서

- 기술 요구사항 정의서

- 현행패턴 목록 및 흐름도 (요구사항 분석서)

2) 설계 단계

- 인터페이스 매핑 설계서 (표준패턴 정의서)

- EAI 시스템 표준화 설계 보고서

- Naming 표준화 (시스템, IF ID, Notation등 포함)

- 인터페이스 Header 표준화

- HUB(Message Flow) 패턴 표준화

- EAI 시스템 설계서

- MQ Object 설계서

- WBI Object 설계서

- 공통 함수 설계서

- In-House Adapter 설계서

- Built-In Adapter 설계서 (MTE)

- Monitoring & 장애 대응 설계

- EAI Architecture 설계서

3) 개발 단계

- 공통 함수 목록

- 개발 Adapter 목록

- EAI Object 목록

- 개발자 가이드라인

4) 테스트 단계

- EAI 시스템 테스트 계획서

- EAI 시스템 단위 테스트 결과서

- EAI 시스템 Link 테스트 결과서

- Adapter 및 HUB성능 테스트 결과서

5) 지식 전수

- EAI 시스템 교육 교재

- 제품 설치 안내서

- 시스템 운영 절차서

- EAI Object 운영 절차 (MQ, WBI)

- Adapter 운영 관리

- Monitoring & Tracking 운영 관리

- 장애 관리