실전 데이터 모델링 데이터 모델 상세화 및 모델 관리

1. 실전 데이터 모델링 데이터 모델 상세화 및 모델 관리 명 재 호

2. 목차 • 데이터 모델의 다양한 Source • 현행 논리모델 • DRM 활용 • Attribute Pool 활용 • 데이터 표준화 • 데이터 모델 상세화 • 정규화 • M;M 해소 • 계층형 데이터 모델 • 배타적 데이터 모델 • 이력관리 데이터 모델 • 물리 데이터 모델

3. 제 1 부 데이터 모델의 다양한 Source

4. 물리적 데이터 모델링 정규화 작업 엔터티 통합 이력관리 대상 선정 이력관리 형태 결정 제 1 정규화 수직적 통합 최종 논리적 모델 제 2 정규화 수평적 통합 제 3 정규화 차원적 통합 M:M 릴레이션쉽 해소 릴레이션쉽 통합 Storage 설계 식별자 매핑 매핑 우선순위 결정 물리적 모델 Partition 설계 일반 속성 매핑 테이블 단위 결정 Constraints 설계 일반 릴레이션쉽 매핑 TO-BE 데이터 모델링 데이터 모델 상세화 데이터 모델 통합 이력관리 결정 추가적인 설계 컬럼 매핑 테이블 매핑

5. 현행 모델을 기반으로 목표 모델 생성 목표 데이터 아키텍쳐 구축

6. 데이터 표준화 프로세스 논리 모델 물리 모델 데이터 표준화 적용 표준화 준수 표준화 적용 표준화 리파지토리 용어 표준 속성,컬럼 표준 도메인 표준 데이터 모델 표준

7. 부품창고 도서관 지식관리시스템 주제영역별 물리모델 주제영역별 논리모델 주제영역별 개괄모델 특정 DA/DC 특정영역데이터모델 특정 엔터티 특정 속성/아티클 DRM 생성기 DRM Repository 조립생산 참조, 복제, 조정 데이터참조모델(DRM)의 개념 유사 MicroSoft PowerPoint의 Online Clip Art 참조,복제,가공 데이터 관련 모든 객체(부품)들 품질, 생산성 향상 • Auto Indexing • Contents Parsing • Ontology

8. 통신회사의 고객 관련 데이터 모델을 참조하고 싶어요 통합고객을 정의 하기 위해 유사한 집합들을 모두 참조하려고 해요. 2사람의 남성이 컴퓨터를 보고 토론하는 그림은 어디 있나요? 주소정보를 관리 하는 속성들의 유형들을 참조하고 싶어요. 데이터참조모델(DRM) 개념 분류영역 부여 클립아트 키워드 30개 엔터티 고객관리, 통신업무, CRM, 통합고객, 무선통신, 유선통신 사람, 남성, 사무실, 사무용품, 컴퓨터 토론 2사람 고객 관계에서 종속성도출 넥타이 발생일자(속성) PC 개인고객서브타입 가입계약 푸른색 와이셔츠 40개 속성 관리사원(관계) 오로지… 전화기 키워드 검색 고객관리(서브시스템) 작성일자 Owner 엔터티 정의(키워드 도출) 실질 및 본질식별자 확장하자! 아티클 아티클 반의어 동의어 유사어 의미구조

9. 데이터 모델 표준(Global DRM) 활용 DRM 검색 ICON DRM 열기 ICON DRM Web page 모델 보기 DOWNLOAD 작업중인 Modeler로 Download

10. 아티클 의의 연락처 전화번호 주소 자택연락처 • 새로운 모델링 축 실체 집합과 별도로 속성집합을 모델링 하여 사용자가 요구한 정보를 표현 • 과정의 표현 실체 모델링과 동일한 과정으로 진행이 가능함 (상향식, 하향식) • 속성의 공용 부품화 동일 속성그룹을 같은 타입으로 정의하여 공용화 함. • 논리적·물리적 속성 표준화 도메인으로 물리적 속성 표준을 정의하고 아티클에 의한 속성의 논리적 표준을 정의함. 자택전화번호 자택주소 지역번호 국번 일련번호 우편번호 지역주소 상세주소 직장전화번호 직장주소 지역번호 국번 일련번호 우편번호 지역주소 상세주소 지역번호 직장연락처 전화번호 주소 연락처정보 지역번호 우편번호 주소 국번 지역주소 자택주소 일련번호 상세주소 직장주소 전화번호 주택전화 직장전화 새로운 모델링 요소 - 아티클 • 속성그룹은 사용자가 가진 정보에 대한 개념을 객체화 한 것 • 모델링 초기에 속성을 정의할 수 있는 것을 개괄적 모델에서는 표현이 가능하게 함.

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

12. 제 2 부 데이터 모델 상세화

13. 데이터모델 상세화 • 데이터 모델 상세화 • 정규화(Normalization) • M:M Relationship 해소 • 데이터 모델 통합 • 수직적 통합 : 계층형 데이터 모델 ( 순환관계 ) • 수평적 통합 : Sub-Type 데이터 모델 • 관계의 통합 : 베타적 데이터 모델 • 차원의 통합 • 이력 관리 데이터 모델

14. 정규화 • 정규화 작업은 관계형 데이터베이스의 개념이지만 그 원칙은 데이터 모델링에 적용된다 • 정규화 단계별 규칙을 사용하여 ATTRIBUTE의 위치를 적절히 하는 것 • 정규화 작업이 완료된 E-R Model은 바로 정규화된 관계형 데이터베이스 설계로 옮겨진다. • 제3정규형은 데이터중복을 제거하기 위한 데이터베이스 설계의 일반적인 목표 • 그 이상의 정규형은 별로 폭넓게 사용되지 않는다. 제 1 정규형 모든 ATTRIBUTE는 반드시 하나의 값을 가져야 한다(반복형태가 있어서는 안됨) 제 2 정규형 모든 ATTRIBUTE는 반드시 UID 전부에 종속되어야 한다 (UID 일부에만 종속되어서는 안됨) 제 3 정규형 UID 가 아닌 모든 ATTRIBUTE 간에는 서로 종속될 수 없다(ATTRIBUTE 간 종속성 배제) 계약상품모델

15. 제품 제품코드 제품명 제품내역 공급자 공급자코드 공급자명 제품공급 공급자 공급자코드 공급자명 공급제품목록 현재가 수량 단위 제품 제품코드 제품명 제품내역 M:M Relationship • 실세계의 업무 중 대부분은 M : M 관계 • 키이엔터티와 키이엔터티 간에는 대부분 M : M 관계 • 지속적으로 발생되는 대다수의 ENTITY는 M : M 관계 • M : M 릴레이션쉽은 새로운 릴레이션 엔터티를 추가하여 M : 1 관계로 변경 릴레이션 엔터티

16. X X Y Y A B C A B C 10 20 30 10 20 30 A 10 A 20 C 10 B 20 C 30 A 10 A 20 C 10 B 20 C 30 연락장교 파견 연락장교 파견 M:M 관계 해결 원리 먼저 ‘A’를 찾는다. 10으로 Y집합을 찾는다. X집합의 ‘A’에 대응되는 Y집합을 찾으려면… 계약상품모델

17. 회사 팀 #* ID 본부 부서 #* ID 부서 팀 본부 #* ID 회사 #* ID 계층형 데이터 모델 • 하위계층의 UID는 상위계층 UID의 집합 • 조직이 변경되면 ID 를 바꾸어야 한다 • 인조(artificial) UID를 생성하라 • 종속적인 UID : - PERFORMANCE 유리 • - 구조변경에 취약 • 독립적인 UID : - PERFORMANCE 불리 • - 구조변경에 쉽게 대응

18. 조직 팀 #* ID 조직코드 조직명 부서장 위치 구성되어 부서 #* ID 본부 #* ID 회사 #* ID 순환(recursive) 관계 데이터모델 계층구조를 통합하면 순환구조 순환구조는 새로운 형태의 관계가 아님 • 하나의 순환 Entity는 각 Entity의 모든 Attribute를 포함해야 한다 • 각 계층에 있는 속성은 동일하게 하는 것이 가장 좋다 • 순환 모델은 Mandatory 관계로 취급될 수 없다 • (무한 LOOP 발생) 반드시 Optional 관계임 • 순환모델은 조직의 변경(추가,삭제)에 쉽게 대응

19. 계층 구조의 통합 복잡한 관계를 가지고 있는 엔터티가 자식을 둘 때 자식은 더 복잡한 관계에 빠진다. …… 만약 이 엔터티 들이 유사한 형태로 되어 있어 통합을 한다면…

20. …… 계층 구조의 통합 순환구조 생성 옆으로 아래로 추가되어도 무관 단순한 관계 새로운 계층이 추가되어도 Relation의 변경이 없다! 부서전표모델

21. 조직 #부서코드 …………… 상위부서코드 부서코드 ………상위부서 110 …… 120 …… 110 220 …… 220 순환 구조의 유의사항 ERD에는 나타나 있지 않지만 테이블의 컬럼에 ‘상위부서코드’라는 명칭으로 생성된 컬럼은 사실은 순환관계 O 최상위는 NULL이 옳음 최상위에 동일한 값을 지정하는 것은 잘못임 X

22. 부품 부품코드 Relation Entity 구성되어 조립규칙 소요량 부품간 소요량은 ? 부품 # 부품코드 부품명 Relation Entity BOM 데이터모델 • BOM(Bill Of Material) 모델은 M : M 순환관계 • 새로운 Relation ENTITY를 추가하여 M : 1 관계로 게시물 모델

23. 배타적 관계 데이터모델 • 어떤 ENTITY가 두개이상의 다른 ENTITY의 합집합과 Relationship을 가지는 것을 배타적(Exclusive) 관계 혹은 아크(Arc)관계라고 한다. • 아크(arc) 내에 있는 Relationship은 보통 동일하다 • 배타적 관계는 항상 Mandatory이거나 Optional 이어야 한다 • 배타적 관계는 반드시 하나의 ENTITY에만 속해야 한다 (하나의 아크가 여러 ENTITY를 가질 수 없다) • 어떤 ENTITY는 다수의 아크를 가질 수 있다. 그러나 지정된 Relationship은 단 하나의 아크에만 사용되어야 한다 은행계좌 개인 법인 하나의 릴레이션쉽으로 통합

24. 공정 창고 공정 창고 입출고 입출고 배타적 관계의 특성 점선 직선 둘 중의 하나는 반드시 존재 각각의 점선이 배타적 관계로 연결하면 직선으로 바뀐다. 입출고모델

25. 집합A 집합A 집합B 집합C ∪ = 집합B 집합C 집합B 집합C ∩ Ø (공집합) = SUB-TYPE MODEL • SUPER-TYPE이란 SUB-TYPE을 가지는ENTITY • SUPER-TYPE은 두개이상의 독립적인 SUB-TYPE으로 구성 • SUPER-TYPE은 각 SUB-TYPE들의 공통적인ATTRIBUTE 와 RELATIONSHIP 보유 • SUB-TYPE은 자신의 ATTRIBUTE나 독립적인RELATIONSHIP을 가진다 • 자신의 ATTRIBUTE 나 RELATIONSHIP을 가지지 않는 SUB-TYPE도 존재할 수 있으나 이런 경우는 일반적인 ATTRIBUTE로 처리하는 것이 좋다. • SUPER-TYPE의 모든 INSTANCE는 SUB-TYPE중 단 하나와 반드시연결 • SUB-TYPE은 서로 중첩되지 않아야하며 그 전체집합은 SUPER-TYPE과 1 : 1 • 전체집합에 확신이 없다면 ‘기타’구분을 생성 • SUPER-TYPE과 SUB-TYPE은 결코 부모 : 자식 관계가 아니다. 역할통합(강좌모델)

26. 연예인 텔런트 기타 가수 ≠ Ø 탈렌트 가수 심층 연구 (SUB-TYPE) 이런 경우의 SUB-TYPE 정의는 ? 김민종은 가수이면서 텔런트 이러한 경우에도 굳이 SUB-TYPE을 정의하려 한다면 가수이면서 텔런트인 사람은 어떻게 정의할 것인가 ? • INSTANCE를 추가하는 방법 • SUB-TYPE을 추가하는 방법

27. 이력관리 1 1 attribute M 1 M 1:1 관계는 1:M 으로 속성을 이력관리하면 1:M 엔터티 생성 이력관리 이력관리 M M M M # uid 추가 이력관리 시의 관계 변화

28. 전통적인 이력관리 방법 • EVENT 발생 시 마다 생성 Event가 발생할 때마다 사진을 찍어 두어야 이력을 관리할 수 있는가? • DAILY 마다 생성 아무 변화가 없는 경우도 데이터 생성 그러나 완벽한 이력관리는 불가능

29. A 1 4 …. A 5 12 …. A 13 18 …. A 19 99 …. B 1 9 …. B 10 20 …. B 21 99 …. C 1 7 …. C 8 99 …. 5 12 1 4 13 18 A 19 99 서로 다른 범위의 로우에서 임의의 동일시점의 데이터 액세스 가능 1 9 21 99 B 10 20 1 7 C 8 99 BETWEEN Relationship 어음수불 # 수불일련번호 어음시작번호 어음종료번호 소진여부 거래처 # 거래처코드 거래처명 주소 ......… 관계를 맺지 않아도 이미 릴레이션쉽이 존재 BETWEEN으로 연결되지만 1:M 관계 유지 발행은행으로서 Relationship이 필요한가? 고객 지급어음 # 어음번호 사용일자 발행금액 ........ 지급처로서 은행

30. 어음책 …… 1~20 21~40 10 11 ? 낱장의 어음이 반드시 하나의 어음책에 들어 있다고 해서 1:M 관계를 부여해야 하는가? 지급어음 10 10 10 … 10 11 11 11 1 …………… 2 …………… 3 …………… ……………… 19 ..……….. 22 …………. 30 …………. 40 …………. BETWEEN RELATION의 개념 Relation을 준다는 것은 결국 어음책번호를 지급어음에 갖다 두겠다는 의미 그러나 Relation을 없애더라도 관계는 존재 (between relation) 어음 1장마다 1레코드인 집합

31. Y 이력(선분)과 EVENT(점)의 차이 1350의 주인은 09:00:00가 아니라 09:00:00~10:10:09이 주인 1355 1352 1350 US$ 11:27:30 10:10:10 09:00:00 812 810 800 12:05:10 09:40:57 09:00:00 특정 시점의 데이터를 찾으려면 <= 은 것들을 모두 읽어 MAX를 구해야 함 선분을 표시하기 위한 두 점에서 하나를 빼면 선분이 없어진다. 사용중지 명변 개통 이벤트 해제 해지 정지 정상 이 력 해지 정상

32. 점 이력 모델 이력 모델 사원별, 부서개편일 전의 부서코드를 찾아라. (부서개편일 : 2002년 3월 1일) 부서변경이력 사원번호 부서코드 변경일자 … 7788 7788 7788 8123 8123 8123 … 10 30 20 40 30 10 … … NULL … 1999/ 02/ 04 2000/ 07/ 21 2002/ 05/ 15 2000/ 03/ 23 2001/ 11/ 05 2002/ 09/ 17 … Subquery를 이용한 방법 (1) 1 SELECT 사원번호, 부서코드 FROM 부서변경이력WHERE 변경일자 = (select MAX(변경일자) from 부서변경이력 where 변경일자 < ‘2002/03/01’); Subquery를 이용한 방법 (2) 2 SELECT 사원번호, 부서코드 FROM 부서변경이력WHERE ROWID = ( select /*+ index_desc(부서변경이력 idx_변경일자) */ ROWID RID from 부서변경이력 where 변경일자 < ‘2002/03/01 and rownum <= 1);

33. 선분이력 이력 모델 LCD257 부품상태변경이력 : 2002/10/12 부품번호 상태코드 유효시작일 유효종료일 발생순번 Z CDR788 LCD257 LCD257 LCD257 LCD257 LCD257 ~~~ E A C E F Z ~~~ 2002/10/12 2002/10/10 2002/10/12 2002/10/12 2002/10/12 2002/10/14 ~~~ 9999/12/31 2002/10/12 2002/10/12 2002/10/12 2002/10/14 9999/12/31 ~~~ 5 1 1 2 3 1 ~~~ F E A C 2002/10/10 2002/10/14 2002/10/12 9999/12/31 1.코드번호 ‘LCD257’인 부품의 당일 초기상태는 ? (2002/10/12 기준) SELECT 부품번호, 상태코드, 발생순번 FROM 부품상태변경이력 WHERE 유효시작일 < ‘2002/10/12’ AND 유효종료일 => ‘2002/10/12’ AND 부품번호 = ‘LCD257’

34. = 시작컬럼 종료컬럼 1 4 5 12 13 18 19 99 100 110 111 120 121 199 200 207 208 289 290 320 321 400 401 500 501 600 601 700 701 9999 종료컬럼 시작컬럼 4 1 12 5 18 13 99 19 110 100 120 111 199 121 207 200 289 208 320 290 400 321 500 401 600 501 700 601 9999 701 물리 설계 고려사항 Column_nameBETWEEN :시작값 AND :종료값 한 컬럼의 범위처리 :Value BETWEEN시작컬럼AND종료컬럼 두 컬럼의 범위처리 시작컬럼 <= :value AND 종료컬럼 >= :value :value가 10 이라면 :value가 520 이라면 • 앞부분 데이터 액세스 시는 시작컬럼+종료컬럼이 유리 • 뒷부분 데이터 액세스는 종료컬럼+시작컬럼이 유리 • rownum=1 조건추가 • 종료컬럼의 Default는 최고값으로 지정 (예; ‘99991231’) 서비스계약이력 모델

35. Y X 10 = 10 Between X and Y X <= 10 <= Y X <= 10 and Y >= 10 = 위 두 문장은 동일하다. (속도도 동일) 물리 설계 고려사항 – 종료점 처리 이러한 원리로 점을 통과하는 선분을 찾으면 원하는 이력 재현 가능 • 종료점이 미정이므로 NULL • 논리적으로는 타당하지만 비교가 불가능 • 인덱스를 사용하지 못하므로 수행속도 저하 • 수렴하므로 최대치 부여 • 아직 종료되지 않았으므로 무한히 계속되는 것으로 간주 • 최대치 부여 (예; 일자라면 9999/12/31) • 가능한 TABLE creation 시 Default constraints 부여 • 수행속도에 유리

36. 제 3 부 물리 데이터 모델링 (Physical Data Modeling)

37. 기초 설계단계 접근 절차 ENTITY별 테이블 단위 결정 1단계 • UID를 기본키(primary key)로 • 속성 식별자(#) 전환 • 릴레이션쉽 식별자(uid bar) 전환 2단계 일반 속성(non-key attribute)의 컬럼 전환 3단계 일반 RELATIONSHIP의 컬럼 전환 4단계 배타적 관계 전환형태 결정 5단계 각종 제약조건, 파라메터 결정 6단계

38. 물리적 모델 정의 논리적 모델 물리적 모델 기업 환경 (분산 DB..) 고려 Mapping Rule 적용 DB2 적용 DBMS 메타데이터 관리 부가적 정보정의 DA Repository 데이터베이스 물리적 데이터 모델 파티션 정의 인덱스 정의 무결성 정의 Storage 파라미터

39. 이력관리 반정규화 물리적 모델 분산 환경 적용 DBMS 집계 테이블 본사 집계 Oracle 본사 지사집계 DB2 공장 월집계 SQL Server 해외 아키텍처 단계에 충실한 물리적 모델 개 념 적 모 델 새로운 요구사항 본 질 적 논 리 모 델 처리 속도를 고려한 집계 필요 실 용 적 논 리 모 델 물리적 요건의 변화에 최소한의 영향만 미치는 방화벽 역할 물리 모델은 반드시 논리 모델에 근거한다.

40. 엔터티2 #키2 속성21 엔터티1 #키2 속성11 속성12 엔터티3 #키3 속성31 속성34 속성32 속성35 서브타입세트2 서브타입세트1 서브타입세트31 서브타입21 속성22 속성23 서브타입1 속성13 서브타입33 속성36 서브타입34 서브타입22 속성24 속성25 서브타입2 속성14 서브타입세트32 서브타입35 속성37 서브타입36 속성38 격자 단위는 서브타입 각 면은 서브타입세트 TABLE21 #KEY2 COL21 KEY1(fk1) COL22 COL23 TABLE5 #KEY1(fk1) #KEY3 COL31 COL32 SUBTYPESET31 COL36 COL37 TABLE10 #KEY1 COL11 COL12 SUBTYPESET1 COL13 COL14 TABLE22 #KEY2 COL21 KEY1(fk1) COL24 COL25 TABLE6 #KEY1(fk1) #KEY3 COL31 COL34 COL35 SUBTYPESET31 COL36 COL38 다양한 물리 모델의 생성 하나의 논리적 집합(엔터티 혹은 서브타입)은 하나 이상의 테이블이 될 수 있으며 속성의 일부만으로 생성될 수 도 있다.

41. 표준 · 참조 선별 · 정재 리버스 정보 컬럼 생성의 표준화 및 자동화 컬럼은 데이터 아키텍처 관리 요소 중 가장 많은 개수를 가지며 비즈니스의 실제정보를 담는 그릇이다. 따라서 중요하면서도 오염되기 쉬운 대상이다. 개발자 직접 정의 디자이너 작업 자동생성 특정 컬럼 개별 정의 전체 컬럼 일괄 정의 • 리버스 단계에서 수집된 자원을 재사용하고 • 용어사전에서 표준을 설정하여 참조 자원을 제공 • 특별한 의미와 미등록 부분을 정의함 용어사전 정의/참조 캐빈 베이컨식 찾기

42. 개인 # 주민번호 은행계좌 # 계좌번호 * 계약일 단체 # 코드 법인 # 사업자번호 외부키 분리 컬럼명 ACCTNO CDATE JUMIN_NO PART_NO BUSINESS_ID 키형태 PK FK FK FK Nulls/ Unique NN,U NN 7540 940614 581101-101211 견본 데이터 5579 931201 298-02-11 외부키 결합 6714 940516 711024-281071 9451 930718 10-234-1955 3040 921009 211-05-29 컬럼명 ACCTNO CDATE OWNER_ID TYPE 키형태 PK FK Nulls/ Unique NN,U NN NN NN 7540 940614 581101-101211 J 견본 데이터 5579 931201 298-02-11 P 6714 940516 711024-281071 J 9451 930718 10-234-1955 B 3040 921009 211-05-29 P 배타적 관계의 컬럼 전환 배타적 관계

43. # 사원번호 * 성명 o 주소 사원 임시직 * 일당 o특근 정규직 본봉 수당 * O 가입하여 배치되어 부서 # 부서코드 노조 # 코드 복잡한 E-R모델을 테이블로 전환 • 하나의 테이블로 통합 • 여러 개의 테이블로 분할 • 아크(ARC) 형태로 적용 물리데이터 모델링