김상하 대표컨설턴트 fithigh@hanmail

1. 세 션 2 – • 데이터모델링 및 DB설계 • 핵심기법 30題 세미나 • - 핵심실무기법 30 題 - 김상하 대표컨설턴트 fithigh@hanmail.net

2. 목 차 1. 논리적 구조 전환설계기법 2. 논리적 조작 전환설계기법 3. 논리적 무결성 전환설계기법 4. 액세스 메커니즘 고려한 DB설계기법 5. 데이터모델 역정규화기법 6. DBMS환경 고려한 DB설계기법 7. 기타 설계기법

3. 1. 논리적 구조 전환설계기법 핵심실무기법1 : 전환 설계 실무 작업과정의 이해 ▣ 사전 작업 ▷ 데이터모델의 전환설계 작업 실시를 위해 최종적으로 데이터모델을 정련. 각 영역별로 모델을 체크아웃 받아 각 영역 모델러가 수행. ▷ 엔티티타입, 속성에 대한 영문명칭을 최종적으로 확인. ▷ 일관성검사를 실시하여 데이터모델의 완전성을 최종 확인. ▷ 특히 Parent가 Optional인 관계를 최종 확인한다. 이런 경우, 데이터베이스로 구현될 때 FK가 Null값을 허용해야 한다. 따라서, 업무적으로 반드시 필요한 경우인지 최종 확인 (FK는 업무적인 경우를 제외하고 가급적 Mandatory로 설정). ▣ 전환 ▷ 전환 작업은 각 영역별로 데이터모델을 모두 체크 인 한 상태에서 일괄적으로 수행. ▣ 정련(Refinement) 작업 ▷ FK의 명칭을 변경한다. FK의 명칭은 명명규칙 표준화에 따라, Parent 테이블의 컬럼 명 만을 입력. ▷ 테이블의 컬럼 순서를 조정한다. 테이블의 컬럼 순서는 데이터베이스의 실제 구현순서 이므로 향후 데이터전환 매핑 작업 및 전환프로그램의 순서에 영향을 미치므로 정확하게 업무요건을 반영하여 순서를 정함. ▷Number Type의 속성 중 “Smallint”와 “Integer”로 구현된 컬럼은 “Decimal”로 변경. ▷ 데이터 전환작업과 관련하여 SAM파일 작성시 필요한 작업. ▣ 데이터베이스 구축 ▷ 각 업무영역 모델러의 전환설계 정련작업이 종료된 후, DBA가 일괄적으로 DDL생성작업을 수행. ▷ 향후 데이터모델의 변경사항은 모델변경관리절차에 따라 운영되며, 데이터모델에 대한 모든 변경 및 성능조정작업은 DBA만이 수행.

4. 1. 논리적 구조 전환설계기법 핵심실무기법2 : 엔티티 타입별 설계 ▣ 삭제대상 엔티티타입 ▷ 고립(Isolated) 엔티티타입 반드시 삭제대상은 아니지만, 관계가 없는 경우 업무적으로 의미없는 데이터일 가능성이 크므로 삭제 고려. ▷ 독자(Solitary) 엔티티타입 어커런스가 하나만 있는 경우 삭제. ▷ 통합코드대상 엔티티타입 통합코드테이블에 반영할 코드성 엔티티타입 중에서 아직 삭제되지 않은 것 삭제. ▣ 집계/통계성 엔티티타입 ▷ 금액관련 부분 엔티티타입. ▷ 계수관련 부분 엔티티타입. ▣ 메타화된 엔티티타입 ▷ 분석단계에서 데이터모델의 유연성을 증대시키기 위하여 메타화시킨 엔티티타입을 비정규화 할 것을 고려함. ▷ 속성들의 특성에 따라, 별도의 엔티티타입으로 분리하여 속성이 아닌 엔티티 어커런스(Occurrence)로 처리하도록 설계된 경우 거래특성을 감안하여 일반속성으로 비정규화할 것을 고려함. ▣ 변경이력 데이터 ▷ “XX정보변경이력”에서 통합관리.

5. 1. 논리적 구조 전환설계기법 핵심실무기법3 : 속성(Attribute) 설계(계속) ▣ 특성 ▷ Category( Basic), Optional(선택하지 않음), Domain(Text, Number, Date, Time, Timestamp). ▣ 이력정보 ▷ 엔티티타입의 특성에 따라, 등록일/시간/영업점/조작자 등의 속성을 추가. ▷ Timestamp는 필요 시만 적용함. ▣ 디폴트 값 ▷ 디폴트 값은 DB구축 후 DBA가 일괄 부여. ▷ 예) Text : space, Number : 0, Date : 0001-01-01. ▣ 허용 값 ▷ 필요 시 허용 값, 날짜범위, 숫자범위 등을 지정함 허용 값으로 설정하면 설정된 값만을 DBMS가 유효하게 처리하므로 프로그램 로직에서 유효성을 검증할 필요가 없음. 따라서, 자주 변경되지 않는 항목에 대해서 허용 값을 지정. ▷ 통합코드는 코드테이블을 항상 참조하므로 대상에서 제외함. ▣ Domain ▷ 한글 값은 Text로 지정함. ▣ 메모필드 ▷ 속성의 길이가 100byte를 초과할 경우에는 데이터 길이에 대한 처리방안을 DBA와 상의함. ▷ DBMS에는 제약이 없지만, 단말처리 시 데이터 길이에 대한 제약이 있을 수 있음.

6. 1. 논리적 구조 전환설계기법 핵심실무기법3 : 속성(Attribute) 설계 ▣ Flag ▷ Child 엔티티타입 어커런스의 존재유무를 판단할 수 있는 Flag 속성 추가 반영. ▣ 순서 ▷ 원칙적으로 속성의 순서는 DBMS 성능에 영향을 주지 않음 □ 식별자는 맨 처음에 오도록 위치시킴. □ 가능한한 자주 변경되는 속성들을 그룹핑하여 위치시키는 것이 좋음. □ 자주 사용되는 속성들이 앞부분에 위치시킴. (성능상으로는 유리한 점은 없으나 유지보수 및 성능튜닝 시 작업하기 편리하므로) □ 메모필드와 같이 길이가 긴 텍스트성 속성을 후반부로 위치함. ▷ 외부 키(FK)의 순서는 DBA가 데이터구조목록에서 작업할 것임 □ 엔티티관계도에서는 작업할 사항이 없으며, DB구축 후 FK의 순서를 지정해 주면 DBA가 반영할 것임. □ 속성의 순서는 엔티티관계도에서 정의한 순서대로 구현되지만, 외부 키는 무조건 맨 뒤에 위치시키므로 외부 키에 대한 순서는 별도 작업을 통해 수행함.

7. 1. 논리적 구조 전환설계기법 핵심실무기법4 : 관계(Relationship) 설계 ▣ Locking Option ▷ Sometimes: Referencing으로 지정. ▷ Always : Modifying 으로 지정. ▣ 예상치 ▷ Optionality의 비율 및 Cardinality의 예상 수치를 입력함. ▷ Child 엔티티타입의 예상 치와 유사하게 도출되어야 함. ▣ Deletion Rule ▷ Parent 엔티티타입 : Disallow로. ▷ Child엔티티타입 : Delete each Occurrence로 지정. ▣ 재귀적 관계 ▷ 별도의 엔티티타입으로 분리하여 Parallel Relationship 설정. ▣ 관계해지 ▷ 업무 영역간(14개 BA) 및 통합코드테이블과의 관계는 해지함. ▷ 업무영역 내 관계는 유지함. ▣ Cardinality ▷ Child 엔티티타입의 관계가 Mandatory인 경우, Optional로 변경. ▷ 가능한 관계 : 1(M):1(O), 1(M):다(O), 1(O):다(O) ▷ 조정필요(사용불가) : 1(M):1(M), 1(O):1(O), 1(M):다(M), 1(O):다(M), 다:다

8. 1. 논리적 구조 전환설계기법 핵심실무기법5 : 주식별자(Primary Identifier) 설계 ▣ 특성 ▷ Primary Key는 반드시 PRIMARY를 선택함. ▣ Secondary ▷ Secondary Index 설정 시에는 반드시 DBA의 확인을 받음. ▣ 순서 ▷ DB구축 후 데이터구조 목록에서 DBA가 일괄작업 함. ▷ DBA에게 식별자의 순서를 제출해야 함.

9. 2. 논리적 조작 전환설계기법 핵심실무기법6 : 트랜잭션(프로그램) & 테이블 매트릭스 ▣ 개요 ▷ 각각의 트랜잭션(프로그램)들이 테이블과 어떻게 연관되어 있는가를 설명하는 표. ▷ 트랜잭션(프로그램)에서 C(Create), R(Read)하는 테이블 내역을 알 수 있음. ▣ 트랜잭션(프로그램) & 테이블 매트릭스

10. 2. 논리적 조작 전환설계기법 핵심실무기법7 : 트랜잭션 분석표 분석 ▣ 개요 ▷ 각각의 트랜잭션들이 테이블들을 어떻게, 어떤 순서로, 어떤 빈도로 사용하는 가를 서술하는 도형. ▷ 테이블의 처리 단계만을 나타냄. ▷ 트랜잭션별로 사용하는 데이터와 이의 사용 유형, 빈도 등을 파악하기 위한 다이어그램.

11. 3. 논리적 무결성 전환설계기법 핵심실무기법8 : 참조 무결성(Referential Integrity Rule) 설계 ▣ Parent Entity Type의 Deletion Rule ▷ 관계가 신규로 생성되는 경우, 별도의 Deletion Rule을 적용하지 않는 이상, 모델 변경 시 일괄적으로 상기의 규칙(Parent : Restrict, Child : No Effect)을 적용함. ▣ Child Entity Type의 Deletion Rule ▷ Child Entity Type의 RI는 DBMS에서 지원하지 않음 소스코드에서 별도의 RI모듈로 구현됨. AP는 신경쓰지 않아도 무방함. ▣ 영향도 분석 예 ▷ Parent 엔티티타입의 RI는 적정하게 설정되어 있으므로 변경사항 없음. ▷ Child 엔티티타입의 RI변경은 DDL, DSL 등 데이터 오브젝트에는 영향이 없으나, 프로시저의 자동 코딩과정에서 별도의 RI체크 모듈이 생성됨. 따라서 현재 잘못 적용된 Child 엔티티타입의 RI를 변경하지 않으면, 삭제(Delete)하는 프로그램에 오류가 발생할 수 있음.

12. 4. 액세스 메커니즘 고려한 DB설계기법 핵심실무기법9 : 인덱스(Index) 설계 ▣ Primary Index (Data Structure List / Data Store List) 정의 시 ▷ clustering, unique, other properties 선택. ▣ Index 추가 정의 ▷ DBA 와 협의 후 변경(Index를 사용할 경우 Read Access는 빨라지지만 추가적인 기억 장소와 indexed field에 대한 수정이 필요. ▣ Index 변경 ▷ DBA 와 협의 후 변경. ▣ Index 삭제 ▷ DBA 와 협의 후 변경 (Foreign Key에 의한 index는 필요할 경우 삭제할 수 있음.)

13. 4. 액세스 메커니즘 고려한 DB설계기법 핵심실무기법10 : 복합 인덱스(Composite Index) 설계 ▣ Composite Index의 길이가 32bytes를 넘는 경우 ▷ 무의미한 Designed Attribute로 대체를 고려. ▷ Identifier길이 6 bytes이하. ▣ Inherit Relationship’s Foreign Key를 Table의 PK에 포함시키는 경우 ▷ Composite Index의 Attribute 개수, 길이가 큰 경우 변경 고려. ▷ Index로 사용되는 Composite Attribute 정렬 순서는 검증 필요.

14. 5. 데이터모델 역정규화 기법 핵심실무기법11 : 반복 그룹(Repeating Group) 처리 ▣ 지침 ▷ 발생건수가 미정인 (Variable Occurrence) Repeating Group은 반드시 Normalize. ▷ 발생건수가 확정된 (Fixed Occurrence) Repeating Group은 Access Pattern을 감안하여 Vertical 또는 Horizontal Approach를 적용 □ Normalization에 위배되는 것은 아님. □ Vertical Approach : 다수의 Column 생성. □ Horizontal Approach : Row를 분리. ▣ 고려사항 ▷ Variable Occurrence Repeating Group의 문제점 □ Column의 정의가 Variable Length로 될 것임. □ Column의 의미가 불명확. □ Indexing, Predicate의 처리가 불가능. ▷ Fixed Occurrence의 Vertical/Horizontal Approach의 비교 □ Space Requirement . Key Length : 길면 Horizontal Approach가 유리. . Optionality :높으면 Vertical Approach가 유리. □ I/O, Response Time 거의 차이가 없는데, 그 이유는 DB2의 I/O, Buffer Pool는 4K 단위이며 대부분 이 범위에 포함. □ Horizontal Approach는 SQL Call시 Fetch가 많으므로 불리. □ SQL Coding . Horizontal Approach : Column Function이 쉬움. . Vertical Approach : Application/SQL이 복잡. □ 유연성 Horizontal Approach가 유리.

15. 5. 데이터모델 역정규화 기법 핵심실무기법12 : 정규화(Normalization) 처리 ▣ 지침 ▷ 한 Attribute는 반드시 하나의 Biz 의미를 가짐 □ Concatenate되지 않아야 함. □ Repeating Group을 갖지 않아야 함. ▷ ERD는 3rd Normal Form까지 작성한 후 Performance를 고려하여 De-normalize. ▷ De-normalize시에는 반드시 그 이유를 명확하게 기술. ▷ De-normalize의 이유가 없어지면 Model을 변경할 수 있게 함. ▣ 고려사항 ▷ Attribute에 SQL의 String Function이 사용되지 않아야 함 (Attribute의 의미가 불명확).

16. 5. 데이터모델 역정규화 기법 핵심실무기법13 : 정규화(Normalization)와 역정규화(De-normalization) 처리 ▣ 지침 ▷ Normalize와 De-normalize의 균형유지 필요 Read Performance와 Redundant Data로 인한 불이익 간의 Trade-off. ▣ 고려사항 ▷ Normalize될수록 Update가 많은 경우에 유리. ▷ De-normalize될수록 Query가 많은 경우에 유리. ▷ Over-Normalize의 증상 □ 대부분의 Access에 Join이 필요한 경우. □ 많은 SQL에서 Join Limit(15개의 Join)에 제한을 받는 경우. ▷ Over-De-normalize의 증상 Update Anomaly가 발생하는 경우 (Data Redundant가 원인). ▷ Join을 피하기 위해 De-normalize하는 경우를 제외하면 대부분 SQL이 복잡해짐.

17. 5. 데이터모델 역정규화 기법 핵심실무기법14 : 역정규화(De-normalization) 유형별 처리(계속) ▣ 지침 ▷ Type Vertical Split, Combining Tables, Pre-Joined Table, Multi-Valued Column, Derived Column. ▷ Vertical Split □ Column의 수가 너무 많은 경우 다수의 Table로 분리 . Row가 4K Page를 초과할 경우 무조건 분리. . Row에서 사용자 또는 Subsystem의 Access부분이 상이하여 Lock Contention이 발생하면 분리. □ Outer Join이 발생하지 않도록 유의 Optionality가 발생하면 Outer Join이 필요하게 됨. ▷ Combining Tables □ 1 : 1의 관계를 갖는 Table을 통합. □ Index가 많아질 수 있음. □ Index의 Blank Value가 많아져 분포가 불균형하게 됨. □ Outer Join을 방지할 수 있음. □ Optionality가 높은 경우 Disk Space가 낭비됨. ▷ Pre-Joined Table □ 2nd, 3rd Normal Form De-normalize한 것으로 일부Column을 미리 Join한 것 예) 부서코드, 부서명 (부서 Table의 Column을 Pre-join). ▷ Multi-Valued Column □ Model의 유연성 확보 특정 값이 추가될 경우 Table을 추가하지 않고 구분에 ‘특정 값’만 추가하여 처리 가능.

18. 5. 데이터모델 역정규화 기법 핵심실무기법15 : 역정규화(De-normalization) 유형별 처리 ▷ Derived Column □ User Derived . AVG, SUM 등의 계산결과. . Indicator : Relation의 Optionality가 높은 경우 효과적. □ System Derived . System 일자, 입력자 ID 등. □ Data의 성격과 Access Pattern을 고려하여 적용. ▣ 고려사항 Horizontal Split은 Partitioned Table Space와 동일.

19. 5. 데이터모델 역정규화 기법 핵심실무기법16 : 역정규화(De-normalization) 효과적인 처리 ▣ 지침 ▷ 흔히 존재하는 Relationship인 경우, 1:1 Relationship의 dependent 부분을 Parent Table로 이동. ▷ 흔히 존재하는 Relationship이고 자주 참조될 경우, 1:M Relationship의 dependent 부분의 primary와 current를 Parent Table로 이동. ▷ 관련된 열(row)이 드물게 존재할 경우(30 % 미만), Relationship에 대한 dependency flag(종속성 표시)를 Parent Table에 추가하고 그 Parent Table을 access할 때마다 존재유무를 check. ▣ 고려사항 ▷ Application의 추가부담 요소 고려. ▷ Access Pattern을 고려. 핵심실무기법17 : 엔티티의 데이터베이스 매핑 ▣ 1 Entity : 1 Table : 1 Table Space Mapping을 할 것인지 여부 ▷ 1 DB => 50 Tables ▷ 1 Table space => 5 Tables ▣ 1 Relationship : 1 Foreign Key : 1 Index Space로 구현할 것인지 여부 ▷ 평균 Max Cardinality : 75,000 이하

20. 6. DBMS환경 고려한 DB설계 기법 핵심실무기법18 : 적정한 엔티티 설계 ▣ 1 Entity의 Attribute 개수가 5개 이하인 경우 ▷ 1 Entity당 5 ~ 10개 Attribute가 적당 ▣ 1개 Entity당 1개 Attribute만 있는 경우 ▷ 전체의 5% 이하가 적당 ▣ 1 Entity의 Attribute 개수가 50개 이상인 경우 ▷ Business Rule 재검토 ▣ 1 Entity의 Row Size가 250 bytes를 넘는 경우 ▷ 전체의 5% 이하가 적당 ▷ 1 Entity당 60 ~ 80 bytes ▣ 1 Entity의 Row Size가 32 bytes 이하인 경우 ▷ Business Rule 재검토 ▣ 1 Entity의 고유 Attribute가 없는 경우 ▷ Business Rule 재검토 ▣ Super-Sub type Entities의implementation ▷ 1개의Table로Merge(권장) OR 각각별개의Table로split

21. 6. DBMS환경 고려한 DB설계 기법 핵심실무기법19 : 적정한 엔티티 어커런스 설계 ▣ Entity Occurrence가 100만 건을 넘는 경우 ▷ Business Rule 재검토 ▣ Entity Occurrence가 1000만 건을 넘는 경우 ▷ Business Rule 재검토 ▣ Entity Occurrence가 1억 건을 넘는 경우 ▷ Table을 적절하게 분리 핵심실무기법20 : 적정한 Foreign Key의 Attribute 설계기법 ▣ Foreign Key의 Attribute 개수가 3개 이하 또는 8개 이상인 경우 ▷ Business Rule 재검토 ▣ Foreign Key의 Attribute 길이가 32 bytes를 넘는 경우 ▷ Business Rule 재검토

22. 6. DBMS환경 고려한 DB설계 기법 핵심실무기법21 : 적정한 Numeric Attribute 설계 ▣ Numeric Attribute 의 소수점 위 자릿수가 15을 넘는 경우 ▷ Business Rule 재검토 ▣ Numeric Attribute 의 소수점 아래 자릿수가 15를 넘는 경우 ▷ Business Rule 재검토 핵심실무기법22 : 적정한 Foreign Key의 Attribute 설계기법 ▣ Foreign Key의 Attribute 개수가 3개 이하 또는 8개 이상인 경우 ▷ Business Rule 재검토 ▣ Foreign Key의 Attribute길이가 32bytes를 넘는 경우 ▷ Business Rule 재검토

23. 6. DBMS환경 고려한 DB설계 기법 핵심실무기법23 : 적정한 Attribute 특성 지정 ▣ Attribute ▷ Attribute에 관련된 Foreign Key Optionality는 전부 Mandatory로 지정 Deletion Rule이 Set Null인 경우 Optional로 지정, 나머지는 전부 Mandatory로 지정 ▷ not null with default 지정 예] char => space, number => zero, date => ‘00010101’ ▷ permitted value 사용 : 허용 값의 개수가 많지 않고 자주 변화하지 않는 경우 지정 예] Attributes – Detail – Value => Range나 지정 값을 입력, Default 값 지정 ▷ 한글 Attribute Text Domain 선택 핵심실무기법24 : 적정한 Numeric Attribute 특성 지정 기법(DB2 경우) ▣ number data type Attribute의 물리적 변환 Rule ▷ 4자리이하 => Small Integer ▷ 5자리이상 8자리이하 => Integer ▷ 9자리이상 15자리이하 => Decimal ▷ 16자리이상 18자리이하 => Float

24. 6. DBMS환경 고려한 DB설계 기법 핵심실무기법25 : 적정한 Relationship 설계 반영 ▣ 1:1 Mandatory Relationship ▷ Entity Merge 고려 ▣ 1:1 Optional Relationship ▷ Main Entity의 Optional Attribute로 Merge 고려 (Optional에 해당하는 Entity type의 발생．빈도가 Mandatory보다 적은 경우에는 그대로 유지, 비슷한 경우에는 하나로 Merge ) ▣ Self Referencing Recursive Relationship ▷ Main Entity Vs Structure Entity로 분리 ( parallel Relationship ) ▣ 2개의 Entity간의 Relationship이 3개 이상인 경우 ▷ Mutually Exclusive Relation으로 변환 ▣ Code Table과 그것을 참조하는 Business Data Entity간의 Relationship ▷ 해제 ▣ 1:1 Mandatory Relationship ▷ Entity Merge 고려

25. 6. DBMS환경 고려한 DB설계 기법 핵심실무기법26 : 적정한 Column 설계 ▣ De-normalized Attribute (Data Redundancy 허용) 정의 ▷ 자주 create, update되지 않는 column이어야 함. ▷ 모델 차원이 아닌 Data Structure List, Data Store List에서 반영함. ▣ Long Textual Columns ▷ redefine one or more shorter columns

26. 6. DBMS환경 고려한 DB설계 기법 핵심실무기법27 : 기타 설계 ▣ Potentially Redundant or Bill-Of-Materials (Recursive or Self Relationship )의 Refinement ▷ 1:m 의 Parallel Relationship으로 구현하는 방법 (Main Entity : Structure Entity). ▣ Redundant Relationships (cyclic) 의 제거 확인 ▣ Naming Standard의 적용 여부 (Entity, Relationship 등) ▣ Subject Area내의 Relationship 집중도와 Subject Area간 Relationship 집중도의 차이 확인 ▷ Highly Cohesion & Loosely Coupling. ▣ Primary Key, Foreign Key, Index의 sorting (ASC,DEC 지정 변경) ▷ Mutually Exclusive Relation으로 변환. ▣ 집계/통계성의 Entity 별도 정의 및 활용 여부 ▷ Performance를 위하여 별도 정의. ▣ 1 Table의 index 개수가 5개를 넘는 경우 ▷ 자주 Update 안 되는 경우 5개 이상 Index 정의도 무방. ▣ Facilitate Maximum Throughput (DB2) ▷ Choice of locking options. ▷ Clustering. ▷ Table partitioning or segmentation. ▷ Commit processing. ▷ Segmentation of updates.

27. 7. 기타 설계 기법 핵심실무기법28 : 뷰 테이블 설계 (계속) ▣ Work set 정의 ▷ 입/출력 뷰로 사용하는 경우 □ 프로시저 액션 블록에서 단일 Work set을 설정하여 입출력 뷰로만 사용하는 경우 . 거래코드별로 하나의 입출력 뷰를 지정하여 사용하는 경우 - 명명 : wk_ionnnn (nnnn : 거래코드). - 예 : wk_io9401. . 여러 거래코드에서 공용으로 사용하는 입출력 뷰를 지정하는 경우 - 명명 : wk_ssnn(ss: 업무영역영문이니셜, nn : 단순일련번호). - 예 : wk_fc01. ▷ 프로그램 로직 작성시 사용하는 경우 □ 공용 Work set . 공통팀에서 제공함 : 사용자는 데이터항목의 추가삭제 불가함 - IEF_SUPPLIED : action_entry, select_char 등. - COMMON : log등록일시, applid, taskno 등. - DATE_INFO. - EXIT_STATE : rtcd, 메시지번호, 메시지상세번호 등. - MESSAGE : 출력상황flag, 출력편집Key, 출력편집구분 등. - LOGHDR : log_11, log유형, 화면거래처리구분 등. - USER_WORK : t_1, t_2, …m_1,…n_1, 등.

28. 7. 기타 설계 기법 핵심실무기법28 : 뷰 테이블 설계 □ 영역별 Work set . 각 영역에서 정의함. 단, 아래의 경우에만 생성가능하며 그 이외의 것은 등록할 수 없음 - LOG_거래코드 : 각 거래코드별 로그사용자 데이터항목 정의 - WK_ss00 : 각 업무영역별 공용으로 사용하는 사용자 Work set - 예 : wk_fc00, wk_nh00 . 현재 사용자가 임의로 지정한 Workset이 많이 존재하고 있음. 이 Workset은 삭제 대상이므로 ‘USER_WORK’또는 ‘WK_ss00’으로 대치하시기 바람 ▣ 뷰 명명규칙 ▷ Import View □ im wk_io9401, im wk_fc07, im 고객기본정보, im_1 고객기본정보, im_직장 고객주소, im_자택 고객주소, im common, im wk_fc00 (단, 프로시저AB에서는 사용 불가). ▷ Export View □ om wk_io9401, om wk_fc07, om 고객기본정보, om_1 고객기본정보, om_직장 고객주소, om_자택 고객주소, om common, om wk_fc00(단, 프로시저AB에서는 사용 불가). ▷ Local View □ tm wk_fc07, tm 고객기본정보, tm exit_state, tm wk_fc00. ▷ Entity Action View □ 고객기본정보, create 고객기본정보, read 고객기본정보, 직장 고객주소.

29. 7. 기타 설계 기법 핵심실무기법29 : 코드 테이블 설계 (계속) ▣ 코드유형 테이블 ▷ 유형구분(4자리) 및 분류구분(1자리:0~4) 을 Key 로 관리. ▷ 분류구분 ‘0’은 별도 구분이 없는 경우이고, ‘1’~’4’까지는 단계(대중소 등)가 있는 경우. ▷ 테이블의 항목명중 ~코드, ~구분 등을 관리. ▷ 코드 유형은 동일한 명칭을 등록 하여선 안되며, 명칭으로 어느 영역인지 이해가 잘 되지 않는 경우에는 영역 명을 접두어로 사용하여 등록. ▷ 코드유형 범위 □ 0 ~ 4999 : 통상 코드 유형. □ 5000 번대 : 이중 관리되는 경우로 각 영역 및 코드테이블 양쪽에 존재. □ 9000 번대 : 화면에만 사용되는 별도 코드. ▣ 코드상세 테이블 ▷ 코드유형의 Key (5자리) 및 코드값(10자리) 를 Key 로 관리. ▷ 분류구분이 ‘0’이 아닌 경우 상위 레벨의 정보를 관리. ▷ ‘사용 안 함’ 필드를 이용하여, 과거 사용코드 및 더 이상 사용하지 않을 코드를 관리. ▷ 한 유형 아래에 코드 상세 명은 동일할 명칭을 사용할 수 없음. ▣ 코드관련 유의사항 ▷ ‘사용안함’ 항목이 set 된 경우 단말 화면의 POP-UP 및 COMBO BOX 의 코드로 Display되지 않음. ▷ 7654 거래(코드상세등록), 6543 거래 (코드유형등록) 의 구분 ‘5’의 삭제는 실지 코드나 유형을 삭제하는 거래가 아니라, 사용 안 함으로 set 하는 거래이며, 재거래 시 다시 복원. ▷ 한번 등록된 거래는 삭제되지 않음이 원칙이다. 왜냐하면, 각종 원장내의 사용안함으로 등록된 코드값이 존재할 수 있으며, 비록 해당 원장에는 삭제정리가 될 수는 있으나, history, log, input log 등에서 삭제가 되지 않는 불일치가 발생하기 때문. 따라서, 신규 등록시 주의하여야 함.

30. 7. 기타 설계 기법 핵심실무기법29 : 코드 테이블 설계 ▷ 코드테이블 및 영역의 테이블로 이중 관리되는 경우 영역 담당자가 관리에 주의. ▷ 코드의 신규등록, 변경 등의 사항은 SM 관리에 준하여 운영. ▷ 코드의 변경은 한 영역에서 변경할 때, 타 영역에 미치는 영향이 크므로 여러 팀이 함께 사용하는 경우에는 반드시 공지를 하여야 함. ▷ 코드테이블 등록 거래는 24/365 거래로 등록이 되어 있으나, 단말 화면의 COMBO BOX, POP-UP 화면에도 적용하려면 단말 팀에 구두로 신청을 하여야 함. 온라인 거래가 한참 발생 중에 적용을 하려면 단말 시스템에 성능에 영향이 있기 때문. 특히, 보험 화면은 월 1회 정도 적용되므로 각 개발 담당자는 이 부분을 고려하여, 적용시점을 잘 판단하여야 함. (코드 등록 및 변경 부분과 단말 화면 - 당사 및 보험 - 적용은 별도 문제이다.) ▷ 코드상세테이블의 코드값에 따른 코드명은 변경은 가능하나, 의미가 다른 내용으로는 변경이 불가하며, 유사한 이름으로는 변경이 가능. 코드값이 추가된 경우에는 관련된 영역 및 분석계(EDW 담당)에도 가급적 전달을 하여 업무가 원활히 이루어 질 수 있도록 서로가 노력하여야 함. ▷ 코드테이블에 등록이 되지 않은 코드값을 원장은 가지고 있을 때, JOIN 하면 없는 코드값을 가진 Row 는 조회 시 출력이 되지 안으므로 이점 유의하여 등록 (사용 안 함 제외) 되지 않은 코드값이 없도록 함. ▣ 코드테이블 사용 방법 ▷ 프로그램에서 코드명이 필요한 경우 □ ‘공통코드상세관리’ 테이블을 직접 읽음. □ 등록된 유형 및 분류구분을 정하여야 함. □ ‘공통코드상세관리 통합코드’ 뷰를 로컬에 만들고 해당 코드를 SET 하여야 함. (해당 업무 속성 명으로 조건절에 기술하는 경우는 자릿수가 달라 Performance 가 떨어짐) 예) AND THAT 공통코드유형 유형 IS EQUAL TO ‘0123’ AND THAT 공통코드유형 분류구분 IS EQUAL TO ‘2’

31. 7. 기타 설계 기법 핵심실무기법30 : 데이터베이스 설계시의 분석모델의 보완(계속) ▣ Subject Area 보완 ▷ Naming : 명사 또는 복합 명사로 ( 한글 ) 지정. ▷ Description : 내용 입력. ▷ Properties : Role 을 General로 지정. ▣ Entity Type 보완 ▷ Naming : 명사 또는 복합 명사로 ( 한글 ) 지정. ▷ Description : 내용 입력. ▷ Properties : Role 을 General로 지정 □ Entity Occurrence ( min, avg, max, growth rate )는 사실에 근거한 정확한 수치 입력. □ Business Object Type, Encapsulation Type, Data Structure 속성 지정, ▣ Attribute 보완 ▷ Naming : 명사 또는 복합 명사로 ( 한글 ) 지정. ▷ Description : 내용 입력. ▷ Properties : Role 을 General로 지정 □ Category : Basic과 Designed만 사용, Derived 사용불가. □ Domain : Timestamp, 한글(MixedText), 영문(Text), 숫자(Number), 일자(date), DBCS Text 는 사용불가. □ Optional, Case Sensitive, Varying Length는 아래 그림과 같이 선택하지 않음. □ 소수점 이하 자리는 Decimal Places에 지정 (Length : 정수부분 자릿수와 소수부분 자릿수 합). □ 테이블 설계 Name은 영문으로 Table Column Naming Rule에 따라 지정. □ COBOL Data Type은 Default로 지정 (숫자는 DECIMAL).

32. 7. 기타 설계 기법 핵심실무기법30 : 데이터베이스 설계시의 분석모델의 보완 ▣ Identifier 보완 ▷ Naming □ 명사 또는 복합 명사로 ( 영문 ) 지정 ( DBA Naming Rule 준수), Composite Identifier 지정. □ Single Attribute / Multiple Attribute / Single Relationship / Multiple Relationship / Attribute + Relationship. ▷ Properties 2개 이상의 Identifier를 지정 시 반드시 Primary Identifier는 Primary option선택 (Name은 DBA Naming Rule 준수). ▣ Relationship 보완 ▷ Naming : 동사로 ( 한글 ) 지정. ▷ Description : 내용 입력. ▷ Properties □ Optionality / Cardinality의 정확성 확인. □ Associate is Option은 Relationship이 Sometimes인 경우 => Referencing으로 Mandatory인 경우 Modifying로 지정. □ Transferable / Transient Option은 선택하지 않음. □ Sometimes Relationship인 경우 실제 Relationship paring이 발생할 확률과 발생 건수( min, avg, max )를 지정. □ Deletion Rule은 Disallow로 지정한다.( Parent => Child ) : DBA 지침. □ Mandatory Relationship인 경우 실제 Relationship paring이 발생할 확률과 발생 건수( min, avg, max )는 default로 정함.