목 차

1. 리버스 엔지니어링 개념 2. Why 리버스 엔지니어링?

3. 데이터의 중요성 4. 관계형 모델 이론 5. 데이터 아키텍쳐 6. 논리화(Logicalization) 7. 결론 8. Q & A

2

리버스 엔지니어링 개념

역공학(Reverse Engineering) 현행 시스템 의 구성 요소와 그들 간의 관계를 규명하여, 상위개념 또는 다른 요약된 형태로 표현하는 방법.

Reverse Engineering for a Data Model 현행 데이터베이스 의 구성요소(Objects and elements)를 근간으로 물리 데이터 모델을 만들고, 기업의 데이터가 갖는 업무 규칙을 논리 데이터 모델로 만들어 나가는 과정.

AS-IS Logical Data Model AS-IS Physical Data Model 현행 시스템 3

리버스 엔지니어링 개념

기존 문제 해결 논리데이터 모델 Reverse Engineering 물리데이터 모델 분석 기초조사 현행 시스템 Cleansing & Transformation ETL 미래 확장성 반영 TO-BE Data Architecting Forward Engineering 이행전략수립 Mapping Rule 개괄데이터 모델 개념데이터 모델 논리데이터 모델 물리데이터 모델 신규 시스템 4

Why 리버스 엔지니어링?

Gartner

“

2005년 까지 포춘 1000대 기업들은 데이터웨어하우스 또는 CRM 프로젝트에서 투자했던 비용보다 더 많은 비용을 데이터 품질관리 이슈로 인한 운영 비효율성으로 소비할 것이다. ( 가능성: 90% )

” “

2005년 까지 데이터웨어하우스 또는 CRM 을 구축한 업체의 50% 이상이 데이터 품질 문제에 대한 인식 부재로 인해 난항을 겪게 될 것이다. ( 가능성: 80% )

”

Ted Friedman Senior Research Analyst 5

Why 리버스 엔지니어링?

Paradigm 변화.

File System 인사부 인사 고객 영업부 영업 재고 Database System 인사부 영업부 회계부 D B M S 회계부 회계 Database 인사 고객 영업 재고 회계 6

Why 리버스 엔지니어링?

비즈니스의 변화.

카드 시스템 고객/상품 승인/결제 종금 시스템 리스/외환 고객/상품 방카슈랑스 고객/생보 손보/상품 CORE Banking System 고객/수신 계좌/상품 Inbound/Outbound 시스템 여신 시스템 고객/담보 신용/대출 상품/계좌 7

Why 리버스 엔지니어링?

데이터의 중복으로 불필요한 개발과 과다한 유지보수 비용.

데이터의 일관성 (Consistency) 과 정확성 (Correctness) 유지 불가능.

시스템 통합의 한계.

업무 요구에 비탄력적.

노동 집약적 - 낮은 생산성.

업무흐름에 따른 시스템 구축

–

중복된 데이터.

전사 데이터 모델 없이 시스템 구축.

8

Why 리버스 엔지니어링?

현행 시스템(AS-IS)의 명확한 파악

–

문제의 해결.

신규 시스템(TO-BE)의 원천

–

70~80%.

데이터 이행(Migration)의 기초.

기존 문제 해결 논리데이터 모델 Reverse Engineering 미래 확장성 반영 TO-BE Data Architecting Forward Engineering 물리데이터 모델 이행전략수립 분석 기초조사 현행 시스템 Cleansing & Transformation ETL Mapping Rule 개괄데이터 모델 개념데이터 모델 논리데이터 모델 물리데이터 모델 신규 시스템 9

데이터의 중요성

대 부분의 기업 에 있어 서 정 보시스 템의 데이터 베이 스 구조 는 사용자에게 숨겨진 형태로 구축되어 왔다. -> 정보의 고립화 프로그램 정보 검색 사용자 사용자 데이터 생성 데이터 수정 DBMS Database Management system 보고서 산출 분석/통계 보고서 산출 비정규 조회 “ 프 로 그 램 은 6 가 지 유 형 의 데 이 터 베 이 스 유 지 절 차 ” C.

Finkelstein

“

Programmer is the Navigator in the sea of data

”

Bachmann

“

프로그래머가 프로그램 언어를 잘못 사용하여 코딩을 고치는 경우는 5~10%도 안된다” James Martin 10

관계형 모델 이론

관 계형 모델 은 업무 에서 사 용되는 데이 터를 인식 , 구성 , 조작하는 정연하 고도 직관적인 방법이다. 즉 관계형 모델은 데이터가 사용자에게 어떻게 비쳐지며, 사용자가 데이터에 어떻게 조작을 하며, 데이터가 처리 될 때 어떻게 유지되어야 하는가에 대한 토대이다. 무엇보다도 중요한 것은 관 계형 모델이 지적인 개념 이라는 사실이다.

사용자 관점에서 본 데이터를 정의하는 – Halle The relational model is an orderly, predictable, and (for the most part) intuitive approach to perceiving, organizing, and manipulating business data. As such, the relational model is a template for how data appear to a user, how a user performs operations on the data, and how the data behave when they are manipulated. It is important to note that the relational model is an intellectual concept defining user perception of data.

- Handbook of Relational Database Design Candace C. Fleming & Barbara von 11

관계형 모델 이론

데이터 구조(Data Structure) 사용자가 인식하는 데이터의 구조

–

2차원의 테이블.

(organization of the data, as users perceive them) 데이터 조작(Data manipulation) 사용자가 관계형 데이터 구조에 행하는 일련의 처리형태.

(types of operations users perform on the relational data structure) 데이터 무결성(Data integrity) 사용자가 데이터 조작을 수행할 때 데이터가 어떻게(정확성, 일관성) 유지되야 하는가에 관한 일련의 업무규칙.

(set of business rules that govern how relational data value behave when users perform relational operations) 12

관계형 모델 이론

데이터 구조(Data Structure) “6 가 지 특 성 을 가 진 행 (Row) 과 열 (Column) 로 구 성 된 2 차 원 의 관계테이블로 표현.” 각 열은 하나의 값만을 가진다. – 1차 정규화 (Entries in Columns are single-valued.) 각 열은 동일한 성격의 값을 가진다. – Same Domain (Entries in Columns are of the same kind.) 각 행은 유일하게 식별된다. – Primary Key (Each row is unique.) 열의 순서는 의미가 없다.

(Sequence of columns(left to right) is insignificant.) 행의 순서는 의미가 없다.

(Sequence of rows(top to bottom) is insignificant.) 각 열은 유일한 이름을 가진다.

(Each column has a unique name.) 13

관계형 모델 이론

데이터 조작(Data Manipulation) SET 처리(not one record at a time) 관계 연산자 : 조회 Select(or Restrict) : 열(Column)에 의거한 행(Row)의 Subset.

Project : 열(Column)의 Subset.

Product : 두 관계 테이블간 행(Row)의 조합을 묶음.

Join : 열(Column)의 기준에 의거하여 각 행(Row)을 수평적으로 묶음.

Union : 중복을 없이하여 각 행(Row)을 수직적으로 묶음.

Intersection : 관계 테이블간의 공통된 행(Row).

Difference : 하나의 관계 테이블에만 있는 행(Row).

Division : 다른 관계 테이블의 모든 행에 대응하는 열을 제외한 열.

처리 연산자 : 관계 테이블의 내용에 변화.

Insert : 행의 입력.

Update : 행의 수정.

Delete : 행의 삭제.

14

관계형 모델 이론

데이터 무결성(Data Integrity) 실체 무결성 규칙(entity integrity rule) : 주식별자( 특정 행을 유일하게 인식하는 하나 이상의 열 )는 Null 값을 포함하지 않는다.

참조 무결성 규칙(referential integrity rule) : 관계 테이블의 모든 외부 식별자 값은 관련 있는 관계 테이블의 모든 주식별자 값이 존재해야 한다.

영역 무결성 규칙(domain integrity rule) : 테이블 내의 모든 열에 관한 무결성 규칙으로 데이터 타입, 길이, 허용 값, 기본값, 유일성, Null 여부 등에 관한 제한이다.

15

관계형 모델 이론

관계형 구조 6가지 특성을 갖는 Table Post-Define Schema DB구조 변경이 상대적으로 쉬움 조작 조회연산자, 처리연산자 SET(집합) 처리 Atomic Value 처리 무결성(Integrity) 실체, 참조, 영역 무결성 Key와 Access Path는 별개의 개 념 Data에 대한 접근경로가 유연함 비관계형 구조 Flat File Pre-define Schema DB구조 변경이 어려움 조작 READ 조회, 처리연산자 RECORD 처리 Pointer 처리 무결성(Integrity) 무결성 개념 없음 Key와 Access Path가 거의 동일 Data에 대한 접근경로가 제한적 16

데이터 아키텍쳐 Layer

개괄적 모델 • 건축물의 조감도, 데이터의 최상위 집합 • 전사적 차원에서 관리 • 기존 엔터티들을 추상화하여 생성 • 아티클을 이용하여 개괄적인 관리항목 정의 개념적 모델 • 주요 키이 엔터티와 핵심 행위 엔터티들로 구성 • 데이터 모델의 골격에 해당 • 세부적인 부분집합을 정의하여 명확화 • 개괄적 모델과 구체적 연결(Alignment) 논리적 모델 • 모든 논리적인 데이터 객체들을 도출 • 최종 식별자가 확정된 모델 • 정규화 및 필요한 반정규화를 실시한 모델 • 데이터 모델 상세화와 통합화를 완료한 모델 • 전략적인 이력관리 방안까지 확정된 모델 물리적 모델 • 논리적 모델과 독립적 • 테이블, 컬럼, 제약요건, 인덱스, 파티션 정의 • 메타 데이터 관리와 연계 • 부가적 단계를 모두 포함 17

데이터 아키텍쳐 프레임워크

자크만 프레임워크 건축 공사와 비교 데이터 객체 DA Toolset 개괄적 사람 사원 고객 상품 Planner 조감도 개념적 사원 정규 임시 상품 Inverter 평면 설계도 논리적 Modeler Wordict 입체 설계도 물리적 e.g. Physical Data Model Ent = Segment/Table/etc.

Reln = Pointer/Key/etc.

공사 설계도 테이블/컬럼 정의 Designer 부가적 무결성/인덱스/파티션/뷰 내장 공사 운영적 Manager 유지 보수 오브젝트 정의/백업/권한 보안/모니터링/SQL튜닝… 18

논리화(Logicalization)

현재의 물리적인 구조를 의미 중심의 논리적인 형태로 재구성!!

가상 엔터티 실체의 논리화 속성의 논리화 관계의 논리화

To-be

의

70~80%

서브타입세트1 현행 테이블 가상 속성 서브타입세트2 가상 배타적 관계 현행 컬럼 현행 컬럼 가상 속성 제거할 속성 가상 릴레이션쉽 가상 서브타입 19

논리화

–

실체의 논리화

현재의 평면도적인 ERD를 입체도적으로 상세화 하자!!

엔터티명칭 보완 속성의 그룹화 속성 종속성정의 보조식별자 지정 속성명칭 보완 관계속성을 릴레이션쉽으로 상세 서브타입 속성유형 정의 속성소유 구체화 의미적 관계표시 관계의 구체화 다차원 서브타입 선택사양 정확화 그룹화를통한 단순화 평면도 입체도 관계명의 구체화 20

논리화

–

실체(집합)의 정의

실체(Entity) 완성도 체크 리스트  엔티티명  엔티티요약 설명  엔티티 범주   명명 규칙을 준수하였는가?

포함하는 모든 속성을 정확히 표현하고 있는가?

  엔티티 정의 / 목적이 표현되어 있는가?

엔티티가 무엇을 대표하고 있는가를 표현 하는가?

 키/메인/액션/서브타입 엔티티 중 어디에 속하는가?

(* 각 범주별 정확도 체크에 활용됨)  현재 발생건 수/빈도  현재 발생된 어커런스의 수/ 빈도는 파악하였는가?

 발생건 수/ 빈도의 향 후변화 추이  변화 가능성이 예상 된다면 이를 파악하였는가?

 권한  다른 엔티티와의 관계   메타데이터 권한을 정의 하였는가? (엔티티 생성/ 변경/ 삭제) 데이터 권한을 정의 하였는가? (데이터 생성/ 변경/ 삭제)  다른 엔티티와 하나 이상의 관계를 가지고 있는가?

21

논리화

–

실체(집합)의 검증

실체(Entity) “실체(Entity)는 관계형 모형(Relational Model)의 기본 규칙을 만족하는 속성(Attributes)의 집합이다.” 엔티티 특성 데이터모델의 구현 주체인 조직(회사, 관공서 등등)이 저장하고픈 의미있는 정보를 나타내야 한다. – 관리 대상 여부 구현할 데이터모델 범위안에 위치해야 한다.

특정 인스턴스가 아닌 유사한 사물들을 대표해야 한다. 집합 실체가 포함할 내부연관성 있는 속성에 의해 결정된 단일개념을 대표해야 한다. – 독립성, 동질성 정규화 규칙을 만족해야 한다.

집합의 순수성을 확인한다. – 개체집합이냐? 행위집합이냐?

22

논리화

–

실체명 부여

“ 실 체 (Entity) 는 일 련 의 설 정 된 규 약 집 합 을 따 르 는 고 유 한 서술적인 이름을 부여받아야 한다.” 지켜야 할 명명특성 실체명은 현실 세계의 객체 및 정보를 대표하도록 한다.

실체명 자체로 의미를 표현하도록 한다.

물리적인 의미, 특성, 고려항목과는 무관하게 논리적으로 사물을 반영하도록 한다.(예: 인사기록파일 - > 사원) 개념의 완전한 표찰을 붙이는데 최소한의 어휘를 사용하도록 한다.

단수 명사를 사용하고 선택적으로 수식어를 사용한다.

지키지 말아야 할 명명특성 데이터 관리자의 승인을 받지 않은 약어, 동음이의어 사용 단일조직, 컴퓨터/ 정보시스템, 보고서/ 메뉴얼, 폼, 컴퓨터 화면 정보시스템 구성요소(테이블, 화일, 메뉴, 레포트, 입력화면, ...) 23

논리화

–

실체 정의

“ 모 든 실 체 (Entity) 는 사 전 에 정 해 진 규 칙 에 따 라 엔 티 티 가 포함하는 정보가 무엇(What), 목적(Why), 집합의 범위(Scope)에 대하여 정확히 기술하여야 한다.

실체를 정의함에 있어서 사전적인 의미에 국한하지 말고“실체 그 자체”를 표현할 수 있도록 정의한다.

정의할 실체의 중요성을 표현해야 한다.

단순 명료하게 기술한다.

실체가 생성되자 마자 기술한다.

판매지역(Sales Region) “고객의 기대, 언어, 관습 또는 거래 법규 관점에서 다른 곳과 차별화 되 는 특 징 또 는 특 성 을 가 졌 으 며 , 또 회 사 로 하 여 금 그 지 역 의 성격에 맞는 판매 및 판매지원 활동을 계획 및 수립할 것을 요구하는 지정된 지리상 영역.” 24

논리화

–

실체(집합)의 정의

실체(Entity) 정의의 상세화 25

논리화

–

실체/속성 상세 분석

1차 수집/보완된 기초정보를 토대로 상세 내용 분석.

테이블의 기본정보, 자료량,미결사항 주요 서브타입 상세 정의 본질식별자 정의 컬럼의 기본 정보 컬럼의 상세 정보 릴레이션 컬럼의 상세 참조정보 엔터티 개념의 구체적 정의 데이터 처리형태 및 특기사항 조사 26

논리화

–

속성 구조화

세 밀 화 최초에는 상위 단계만 정의해 두었다가 점차적으로 세밀화 현행시스템의 리버스 시 전체 적인 윤곽부터 찾아가는 방식 으로 접근 주요 내용별로 속성그룹을 생 성하여 일목요연하게 정돈할 목적으로 활용 평소에는 계층 접기를 해두어 단순화를 하고 필요 시에만 펼 치기를 사용 단 순 화 논 리 화 현행 시스템의 속성 논리화를 하기 위해 활용 분석을 통해 밝혀진 사실을 속 성 그룹화나 세분화를 하여 표 현 독립적 아티클 생성 표준관리를 위해 DRM 화를 하거나 참조한 DRM 단위를 표현 향후 독립적 엔터티나 화를 위한 분류 도메인 관리단위로 활용 객체 객 체 화 27

논리화

–

속성 정의

속성(Attribute) 완성도 체크리스트 “사물의 본질을 이루는 고유한 특성이나 성질”로서 모든 속성은 그 속성이 무엇인지 또 왜 업무에 중요한 것인지에 대해 완비된 명세로써 문서화 되야 한다.

속성명 속성요약 설명 속성 유형(기본키, 외부키, 일반속성) 도메인(Domain : 속성이 지닐 수 있는 값) 일반도메인 특수도메인 추출여부(원시속성, 추출/유도속성) 추출공식 소유권한(Metadata, 도메인 생성/수정/삭제/참조) 28

논리화

–

속성 검증

속성의 원자성 확인 “데이터 모형내 모든 속성은 자체적으로 완성된 구조, 즉 원자적(Atomic) 이어야 한다.” 속성 도메인 확인 “ 모든 속성은 반드시 두가지 이상의 인스턴스 값을 가져야 한다.” 추출 속성 정의 “ 추출(Derived) 및 계산된(Calculated) 속성은 추출 또는 계산과정에서 사용된 소스속성(Source Attribute)과 추출공식이 반드시 기술되어야 한다.

속성의 근원 확인 “속성은 오직 한개의 실체내에 근원을 두고 있다. 기본키(Primary key)는 다 른 실 체 와 의 관 계 형 성 을 위 해 다 른 실 체 로 이 동 할 수 있 지 만 , 일반속성은 다른 엔티티로 이동할 수 없고, 모형내 오직 하나의 실체에만 존재할 수 있다. ” 29

논리화

–

속성명 부여

속성의 의미를 명확히 표현하는 함축성 있는 명사 혹은 명사구.

해당 업무에서 널리 쓰이는 용어를 사용.

실체(Entity)명을 사용하지 말 것.

필요 시 표준약어를 제정.

가능한 복합명사를 사용(일자 -> 판매일자).

단 하나의 실체(Entity)에만 속하도록.

Attribute Naming Rules Object type + Qualifiers + Domain Name 표준 도메인(Standard Domain) ADDRESS AMOUNT DATE INDICATOR NAME PRICE TEXT DAY INITIALS NUMBER QUANTITY TIME CODE DESCRIPTION LINE PERCENTAGE RATE VALUE RATIO COUNT IDENTIFIER MONTH PERIOD WEIGHT 30

논리화

–

기본키 속성 확인

“모든 실체(Entity)는 인스턴스의 유일성 식별 을 보장받을 수 있는 하나의 기본키(Primary Key)를 가져야 한다.” 기본키 속성은 반드시 값을 가져야 한다. – Not Null 기본키 속성은 반드시 Unique해야 한다.

최소한의 속성 집합(Minimal Set)이어야 한다.

안정적: 한번설정되면 불변.

업무 활용도가 높은것.

비지능적: 복잡한 의미 를 내포하지 않아야 함.

31

논리화

–

본질식별자 속성 확인

그것 , 저것 , 거시기 ?

진주어 ( 眞主語 ) : 내용상의 실질적인 주어 가주어 ( 假主語 ) : 지시대명사, 문법상의 주어 고객

본질식별자

홍길동(아버지)와 의미상의 주어 OO일에 낳은 아이 본질 식별자란 그가 없다면 자신이 결코 태어날 수 없는 절대 종속인 것 보험계약 #증서번호 계약일자 상품 황진이(어머니)가 이름을 확정하는 것보다 자신의 출생의 비밀을 밝히는 것이 훨씬 우선적 아기 이름 인조식별자, 얼굴마담

실질식별자

본질 식별자를 정확히 밝혀내는 것은 엔터티 정의를 명확히 하는 중요한 과정 출생의 비밀을 모르고서는 집합이 명확해질 수 없다 32

논리화

–

본질식별자 속성 확인

부모없이 태어난 자손은 없다.

의미상의 주어(본질 식별자)란 ? ENTITY 탄생에 직접적인 역할을 한 속성들.

인조속성이 아닌 의미상의 주어(본질식별자)를 찾아라.

절대 종속인가? 상대 종속인가?

직접 종속인가? 간접 종속인가?

WHEN?

WHO?

HOW?

놓쳐 버린 Entity가 있더라도 각 단계에 충실하면 결국에는 다시 나타난다.

그러나 Key Entity를 놓치면 시행착오를 겪게 된다. 의미상의 주어(본질 식별자) 인조식별자 (얼굴마담) WHAT?

육하 원칙 WHERE?

WHY?

누가 ?

무엇을 ?

언제 ?

어디서?

관리할 속성 어떻게 ?

데이터의 발생 주체 데이터가 발생한 대상 데이터 발생 시기 데이터 발생 장소 다양한 속성 구매의뢰 의뢰번호 자재 의뢰부서 의뢰수량 승인수량 발주부서 의뢰일자 내외자구분 ………….

자재 부서 왜 ?

다양한 속성 33

논리화

–

외부키 속성 확인

“모든 종속 실체(Main or Action)는 반드시 하나 이상의 외부키 속성을 가져야 하며 다음 규칙을 준수해야 한다. ” 두 실체간의 관계는 부모실체의 기본키에 대응되는 외부키에 의해 설정될 수 있다.(Key Migration from Parent to Child) 부모실체의 기본키 전체가 자식실체의 외부키로 이동해야 한다.

복합키일 경우 자식실체에서 기본키와 일반속성으로 분할되어 이동할 수 없다.

외부키는 자식실체내에서“이중활용”될 수 없다.

34

논리화

–

속성의 정의

속성(Attribute) 정의의 상세화 35

논리화

–

관계의 정의

관계(Relationship) 완성도 체크 리스트  관계명  관계요약 설명  외부키  관계유형  기수성, 선택성  참조무결성  구분자   명명 규칙을 준수하였는가?

두 엔티티간의 업무적 관계를 표현하는 ‘동사형’으로 부여하였는가 ?

 관 계 가 왜 존 재 해 야 (업무규칙, 정규화,...) 하 는 가 를 기 술 하 고 있 는 가 ?

  외부키가 부모엔티티의 기본키(Primary key)와 일치하는가?

외부키 항목이 기본키와 기본키가 아닌 속성에 펼쳐져 있는가?

   Richard Barker의 표기법 정보공학(IEM) IDEF1X : Identifying/Non Identifying/Category  업무규칙에 근거하여 기수성/선택성을 정의하였는가?

 업무규칙에 근거하여 참조무결성을 정의하였는가?

 수퍼타입 엔티티에 구분자 속성이 포함되어 있는가?

36

논리화

–

관계의 정의

ENTITY_A # A 정확하게 1촌 종속 관계를 찾아야만 진정한 리버스 ENTITY_B # B 처리대상 선택 자식관계 분석 부모관계 분석 1촌 확정 조부 ENTITY_D # A # B # C 증조부 ENTITY_E # UID

A B C

D E 1촌 1촌 1촌 ENTITY_C # A # B 조부 증조부 참조관계 검색 검색된 테이블 언어학적 접근 테이블 상세정보 참조 검색어를 포함하는 속성들 37

결론 하려면 ??

현행시스템 오랜 기간 ?

?

?

Technique

목표시스템 고 비용 38

Q & A

39