5 11 Repeating Group Variable Occurrence Repeating Group
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 거의 차이가 없는데, 그 이유는 DB 2의 I/O, Buffer Pool는 4 K 단위이며 대부분 이 범위에 포함. □ Horizontal Approach는 SQL Call시 Fetch가 많으므로 불리. □ SQL Coding. Horizontal Approach : Column Function이 쉬움. . Vertical Approach : Application/SQL이 복잡. □ 유연성 Horizontal Approach가 유리. 14
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와 동일. 18
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 Space Mapping을 할 것인지 여부 ▷ 1 DB => 50 Tables ▷ 1 Table space => 5 Tables ▣ 1 Relationship : 1 Foreign Key : 1 Index Space로 구현할 것인지 여부 ▷ 평균 Max Cardinality : 75, 000 이하 19
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 20
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 특성 지정 기법(DB 2 경우) ▣ number data type Attribute의 물리적 변환 Rule ▷ ▷ 4자리이하 => Small Integer 5자리이상 8자리이하 => Integer 9자리이상 15자리이하 => Decimal 16자리이상 18자리이하 => Float 23
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 고려 24
6. DBMS환경 고려한 DB설계 기법 핵심실무기법 26 : 적정한 Column 설계 ▣ De-normalized Attribute (Data Redundancy 허용) 정의 ▷ 자주 create, update되지 않는 column이어야 함. ▷ 모델 차원이 아닌 Data Structure List, Data Store List에서 반영함. ▣ Long Textual Columns ▷ redefine or more shorter columns 25
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 (DB 2) ▷ ▷ ▷ Choice of locking options. Clustering. Table partitioning or segmentation. Commit processing. Segmentation of updates. 26
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로 정함. 32
- Slides: 32