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

김상하 대표컨설턴트[email protected]

-세 션 2 –

데이터모델링 및 DB 설계 핵심기법 30 題 세미나

- 핵심실무기법 30 題 -

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

핵심실무기법 2 : 엔티티 타입별 설계

▣ 삭제대상 엔티티타입 ▷ 고립 (Isolated) 엔티티타입 반드시 삭제대상은 아니지만 , 관계가 없는 경우 업무적으로 의미없는 데이터일 가능성이 크므로 삭제 고려 . ▷ 독자 (Solitary) 엔티티타입 어커런스가 하나만 있는 경우 삭제 . ▷ 통합코드대상 엔티티타입 통합코드테이블에 반영할 코드성 엔티티타입 중에서 아직 삭제되지 않은 것 삭제 .

▣ 집계 / 통계성 엔티티타입 ▷ 금액관련 부분 엔티티타입 . ▷ 계수관련 부분 엔티티타입 .

▣ 메타화된 엔티티타입 ▷ 분석단계에서 데이터모델의 유연성을 증대시키기 위하여 메타화시킨 엔티티타입을 비정규화 할 것을 고려함 . ▷ 속성들의 특성에 따라 , 별도의 엔티티타입으로 분리하여 속성이 아닌 엔티티 어커런스 (Occurrence) 로 처리하도록 설계된 경우 거래특성을 감안하여 일반속성으로 비정규화할 것을 고려함 .

▣ 변경이력 데이터 ▷ “XX 정보변경이력”에서 통합관리 .

1. 논리적 구조 전환설계기법

5

핵심실무기법 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

▣ Flag ▷ Child 엔티티타입 어커런스의 존재유무를 판단할 수 있는 Flag 속성 추가 반영 .

▣ 순서 ▷ 원칙적으로 속성의 순서는 DBMS 성능에 영향을 주지 않음 □ 식별자는 맨 처음에 오도록 위치시킴 . □ 가능한한 자주 변경되는 속성들을 그룹핑하여 위치시키는 것이 좋음 . □ 자주 사용되는 속성들이 앞부분에 위치시킴 . ( 성능상으로는 유리한 점은 없으나 유지보수 및 성능튜닝 시 작업하기 편리하므로 ) □ 메모필드와 같이 길이가 긴 텍스트성 속성을 후반부로 위치함 .

▷ 외부 키 (FK) 의 순서는 DBA 가 데이터구조목록에서 작업할 것임 □ 엔티티관계도에서는 작업할 사항이 없으며 , DB 구축 후 FK 의 순서를 지정해 주면 DBA 가 반영할 것임 . □ 속성의 순서는 엔티티관계도에서 정의한 순서대로 구현되지만 , 외부 키는 무조건 맨 뒤에 위치시키므로 외부 키에 대한 순서는 별도 작업을 통해 수행함 .

핵심실무기법 3 : 속성 (Attribute) 설계


7

핵심실무기법 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

핵심실무기법 5 : 주식별자 (Primary Identifier) 설계

▣ 특성 ▷ Primary Key 는 반드시 PRIMARY 를 선택함 .

▣ Secondary ▷ Secondary Index 설정 시에는 반드시 DBA 의 확인을 받음 .

▣ 순서 ▷ DB 구축 후 데이터구조 목록에서 DBA 가 일괄작업 함 . ▷ DBA 에게 식별자의 순서를 제출해야 함 .


9

핵심실무기법 6 : 트랜잭션 ( 프로그램 ) & 테이블 매트릭스

▣ 개요 ▷ 각각의 트랜잭션 ( 프로그램 ) 들이 테이블과 어떻게 연관되어 있는가를 설명하는 표 . ▷ 트랜잭션 ( 프로그램 ) 에서 C(Create), R(Read) 하는 테이블 내역을 알 수 있음 .

▣ 트랜잭션 ( 프로그램 ) & 테이블 매트릭스

2. 논리적 조작 전환설계기법

10

핵심실무기법 7 : 트랜잭션 분석표 분석

▣ 개요 ▷ 각각의 트랜잭션들이 테이블들을 어떻게 , 어떤 순서로 , 어떤 빈도로 사용하는 가를 서술하는 도형 . ▷ 테이블의 처리 단계만을 나타냄 . ▷ 트랜잭션별로 사용하는 데이터와 이의 사용 유형 , 빈도 등을 파악하기 위한 다이어그램 .

일련번호 트랜잭션 명 이용형태

사용테이블 평균 이용 횟수 트랜잭션 당 월

1

제품별 공급자 등록

읽기 공급자 0.97 291

읽기 제품 0.95 300

쓰기 제품별공급자 0.03 10

2 제품 등록 쓰기 제품 1 900

3

재고 등록

읽기 제품 5 450

읽기 납품 5 450

읽기 납품내역 40 3600

읽기 창고 10 1000

쓰기 재고 5 4500

2. 논리적 조작 전환설계기법

11

핵심실무기법 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) 하는 프로그램에 오류가 발생할 수 있음 .

3. 논리적 무결성 전환설계기법

12

핵심실무기법 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 는 필요할 경우 삭제할 수 있음 .)

4. 액세스 메커니즘 고려한 DB 설계기법

13

핵심실무기법 10 : 복합 인덱스 (Composite Index) 설계

▣ Composite Index 의 길이가 32bytes 를 넘는 경우 ▷ 무의미한 Designed Attribute 로 대체를 고려 .

▷ Identifier 길이 6 bytes 이하 .

▣ Inherit Relationship’s Foreign Key 를 Table 의 PK 에 포함시키는 경우 ▷ Composite Index 의 Attribute 개수 , 길이가 큰 경우 변경 고려 .

▷ Index 로 사용되는 Composite Attribute 정렬 순서는 검증 필요 .

4. 액세스 메커니즘 고려한 DB 설계기법

14

핵심실무기법 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 가 유리 .

5. 데이터모델 역정규화 기법

15

핵심실무기법 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

핵심실무기법 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

핵심실무기법 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

핵심실무기법 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

핵심실무기법 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

핵심실무기법 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

6. DBMS 환경 고려한 DB 설계 기법

21

핵심실무기법 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

핵심실무기법 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

핵심실무기법 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

핵심실무기법 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

핵심실무기법 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

핵심실무기법 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

핵심실무기법 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, 등 .

7. 기타 설계 기법

28

핵심실무기법 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

핵심실무기법 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

핵심실무기법 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

핵심실무기법 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

핵심실무기법 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 로 정함 .


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

Documents

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