관계형 DATABASE 구축을 위한 DATA MODELING

목 차 1 . DBMS의 발전 2 . 정보 SYSTEM 구축 3 . DATA MODELING 목 차 1 . DBMS의 발전 2 . 정보 SYSTEM 구축 3 . DATA MODELING 4 . 관계형 DATABASE 전환 5 . DATA MODELING WORKSHOP

1 . DBMS의 발전 1.1 DATA MANAGEMENT SYSTEM의 발전 단계 1.2 FILE SYSTEM 1.3 DATABASE의 특징 1.4 DBMS (DataBase Management System) 1.5 DATABASE 종류 1.6 관계형 DBMS의 특성 1.7 관계형 DATABASE의 도입 효과

1.1 DATA MANAGEMENT SYSTEM의 발전 단계 SAM FILE SYSTEM ISAM VSAM HDB DBMS NDB RDB OODB

1.2 FILE SYSTEM 1.2.1 FILE SYSTEM 특징 1.2.2 FILE SYSTEM 문제점 부분 업무 처리에 중점 각 FILE의 소유 및 책임의 명확성 Program 논리가 Data 형식 및 구성에 의존 1.2.2 FILE SYSTEM 문제점 Data의 불일치 Data 공유의 제한성 기억 장소 낭비 File 변경의 어려움 ( 과다한 Program 유지보수) Back-Up, Recovery 관리의 어려움 Security 관리의 어려움

1.3 DATABASE의 특징 DATA의 독립성 (Independency) 유지 DATA의 무결성 (Integrity) 유지 DATA의 중복성 (Redundancy) 감소 DATA의 불일치 (Inconsistency) 배제 DATA의 공유 (Share) DATA의 표준화 (Standardization) DATA의 보안성 (Security)

1.4 DBMS (DataBase Management System) USER1 DBMS DATABASE USER2 USER3 1.4.1 DBMS : User와 Database를 연결하며 Database의 모든 Access를 처리하는 Software Data의 물리적, 논리적 독립 보장 Data의 무결성 유지 Data의 불일치 제거 Data의 공유 1.4.2 DBS (DataBase System) : 전산화된 Record 유지 System 1.4.3 DBA (DataBase Administrator) : Database 관련 전체 System을 제어하는 개인 또는 Group

1.5 DATABASE의 종류 1.5.1 계층형 (Hierachical) DataBase 장 점 단 점 자료구조 : TREE 구조 ENTITY2 ENTITY1 ENTITY6 ENTITY5 ENTITY3 ENTITY4 Father - Son 의 관계 장 점 단 점 DATA처리의 신속함 성능 예측의 용이 업무변환에 대한 적응력 부족 운용의 복잡함 (추가,삭제) N : M의 관계가 복잡 고도의 숙련된 전산요원 필요

1.5.2 망 (Network) DataBase 장 점 단 점 자료구조 : Owner 와 Member의 관계 ENTITY2 장 점 단 점 NODE 간의 대등한 위치 N : M 의 관계 표현 SYSTEM 설계의 복잡성 DATA의 종속성 운용의 복잡함 숙련된 전산요원 필요

1.5.3 관계형 (Relational) DataBase ENTITY2 ENTITY1 ENTITY6 ENTITY5 ENTITY3 ENTITY4 장 점 단 점 업무 변화에 대한 적응력 탁월 SYSTEM 설계의 단순화 사용자의 편리성 높은 생산성 유지 보수의 편리성 SYSTEM 자원의 요구 설계 미숙시 문제점 발생

1.6 관계형 DBMS의 특성 1.6.1 물리적 독립성 1.6.2 접근의 독립성 1.6.3 DATA의 독립성 1.6.1 물리적 독립성 DISK, BLOCK, CYLINDER, BYTE, DATA 항목의 위치와 같은 물리적 구성에의 종속을 제거 1.6.2 접근의 독립성 PROGRAM으로 부터 요구되는 RECORD와 FILE의 탐색과 접근을 위한 경로를 제거 1.6.3 DATA의 독립성 새로운 DATA 항목의 추가를 제외하고는 적용 업무 DATABASE 변경을 사용자에게 숨김

1.7 관계형 DATABASE의 도입 효과 양질의 적용 업무구축 1.7.1 응용 PROGRAM의 신속한 작성 1.7.2 유지보수 노력 및 비용의 절감 1.7.3 DATA 처리 및 변경에 대한 신속한 적응 1.7.4 환경 변화에 대한 신속한 대응 양질의 적용 업무구축

2 . 정보 SYSTEM 구축 2.1 DATA 환경의 변화 2.2 전통적 개발 방법론 2.3 SOFTWARE공학 과 정보공학 2.2 전통적 개발 방법론 2.3 SOFTWARE공학 과 정보공학 2.4 정보공학적 개발 방법론 2.5 DATA 중심 개발 방법론 2.6 DATA 관리 절차 2.7 SYSTEM 구축 단계별 산출물 2.8 요구 분석

2.1 DATA 환경의 변화 FILE SYSTEM APPL. DATABASE 관리대상별 DATABASE INFO. SYSTEM 업무의 복잡화 및 거대화 환경 변화의 신속화 정보 기술의 발전 사용자의 다양한 요구 변화 FILE SYSTEM APPL. DATABASE 관리대상별 DATABASE INFO. SYSTEM 단위업무개발 END-USER 컴퓨팅 경영 정보 제공 의사 결정 지원 자료중복 무결성미비 PROGRAM 개발부하 유지보수 어려움 요구분석 DATA 분석 및 설계 DATA 관리

2.2 전통적 개발 방법론 코딩&테스팅 (Coding & Testing) 분석 (Analysis) 설계 (Design) 유지보수 (Maintenence) 노동 집약적 절차 중심 방법 유지 보수 비용 증가 및 어려움 단계별 관리의 어려움 산출물 관리의 어려움 낮은 생산성 정보의 고립화

2.3 SOFTWARE 공학 과 정보공학 * 제품관리 * 공정관리 * 품질관리 * 비용관리 2.3.1 SOFTWARE 공학 단위 PROJECT에 대한 구조적 (STRUCTURED) 기법 SOFTWARE PROGRAM의 분석 및 설계 전산 처리에 대한 LOGIC 산출물을 대상으로 * 제품관리 * 공정관리 * 품질관리 * 비용관리

생산성이 높은 SYSTEM을 품질이 좋고 , 유지보수가 쉽게 2.3.2 정보 공학 기업 전산화 구축의 요구에 대한 정보 SYSTEM 제공 COMPUTER에 DATA를 저장하고 유지보수하며 DATA로 부터 필요한 정보를 추출하도록 하는것 기업 업무 전반에 걸쳐 사용되는 구조적 기법 정보 SYSTEM 전반에 걸쳐 전략적으로 계획하고 진행 (요구 분석부터 유지 보수까지) 정보 공학의 목적 생산성이 높은 SYSTEM을 품질이 좋고 , 유지보수가 쉽게

정보 SYSTEM 의 PYRAMID (3 SIDES / 4 LEVELS) Strategy Activity Data Analysis System Design Construction Data Activity Technology 3 Sides 정보 시스템의 구성은 항상 3 면이 균형있게 고려되어야 한다. Data : 조직이 현재 관리하거나 관리 대상이되는 모든 Data Activity : Data를 이용한 조직의 모든 업무 수행 활동 Technology : 정보 System 구축에 관련되는 모든 실행 기법

4 Levels 정보 시스템 구성 3 면을 대상으로 각각의 4 단계를 고려한다. Strategy : 가장 효율적으로 기업을 운영하는데 필요한 정보의 전략적 관점 기업을 개선하는데 기술이 어떻게 이용되는지에 관한 전략적 관점 Data, Activity, Technology의 최상위 계층으로 전략 계획을 수립 기업이 필요로하는 정보에 대한 전략적 Vision 제시와 전략 계획 수행 최고 경영층과 정보 System 최고 관리자가 함께 전략 전반에 걸쳐 미래의 기법, 제품과 Sevice, 목표와 목적등 모든 내용과 연관지어 함께 작업하는 단계 Analysis : 완전히 정규화된 논리적 데이타 모델의 제시 기업을 운영하는데 필요한 처리 과정과 통합 방법을 나타내는 단계로 기업 운영에 필요한 논리 Model의 구축과 Data를 사용하는 활동, Data를 저장 유지보수하며 조작하는 기법을 제시 이 단계는 Detail한 부분이 아닌 무엇이 필요하고 어떻게 구축할 것인가의 방법을 고려 Design : 특별한 순서에의해 사용된 Record의 설계 특별한 과정을 처리, 수행하기위한 절차의 설계단계 Data의 상세 Design, Data 처리 System과 Data와의 직접연결, H/W와 S/W의 관계등을 나타냄 어떻게 작업이 수행되며 사용자 단계의 처리등을 고려하는 단계, 그러나 사용자 I/O를 제외하고 상세한 구축등은 고려하지 않음 Construction : Data를 이용한 응용 Program 단계 Code생성기에 대한 상세한 Program 논리 또는 입력에 관한 설계 Physical DB의 구조, 응용 Program의 접근, H/W 및 S/W의 선정등의 활동 이 단계에서 Files, DBMS, Program의 구조,기술적 설계, 상세구축등을 고려한다

2.4 정보 공학적 개발 방법론 PLANNING ANALYSIS DESIGN 분 석 DATA MODELING SCHEMA 설계 분 석 DATA MODELING SCHEMA 설계 PROGRAM 타당성검토 현황조사 방향설정 PROJECT 계획수립 업무활동분석 업무조직분석 업무흐름분석 업무현상조사 업무활동분할 REVIEW 자료분석 장표문서수집 자료항목추출 실체, 관계 정의 주/부/외부키 정의 키 규칙 정의 속성 정의 속성 규칙 정의 정규화 통합 , 검증 데이타모델 -> RDB Table/Column 정의 규칙정의 참조무결성 범위무결성 Schema생성 (Table,View,..) DB,LOG,DISK 전략구축 Program설계 MENU설계 Repository 관리 CASE이용 JAD -> Prototyping

2.5 DATA 중심 개발 방법론 2 3 데이타모델링 RDB 설계 데이타베이스 경영정보제공 1 4 업무분석 및 자료분석 Application Design End-User Computing Application 생성

2.6 DATA 관리 절차 DATA 관리 DB 설계 USER # 1 5 6 USER # 2 데이타모델 S/W 스키마 물리 DB 3 USER # 3 1 CPU 데이타사전 8 DISK 기존FILE 2 4 7 기존DB TERMINAL DATA 관리 DB 설계 1. 정규통합화 4. 데이타항목정의 5. 기계효율분석 3. 안정성분석 6. 분산분석 2. 분석 7. 서브스키마생성 8. 환원

2.7 구축 단계별 산출물 PLANNING ANALYSIS DESIGN 분 석 DATA MODELING SCHEMA 설계 2.7 구축 단계별 산출물 PLANNING ANALYSIS DESIGN 분 석 DATA MODELING SCHEMA 설계 PROGRAM 타당성검토 프로젝트계획 범위목표설정 위원회구성 일정계획 업무활동분석 조직도 업무분장표 업무흐름도 면담조사표 자료분석 양식조사표 자료항목조사표 E-R Diagram D-S Diagram Key 규칙 정의 속성 규칙 정의 Table List Trigger List (RI) Rule Default (DI) Type View Index Procedure Program List Menu 체계도 View Table 관련도 Index Table

2.8 요구 분석 요구 분석 명세 업무활동분석 자료분석 조직도 분석 지역 / 조직 (Location/Organization) 분석 조직 / 기능 (Organization/Function) 분석 기능 / 업무 (Function/Business) 분석 CSF (Critical Success Factor) 분석 목표 및 문제점 (Goal & Problem) 분석 업무 / 실체 (Business/Entity) 분석 업무활동분석 양식 / 문서 조사 자료 항목 조사 자료분석

3 . DATA MODELING 3.1 DATA MODELING 개요 3.2 DATA MODELING 위치 3.7 용어 비교 3.8 실체 (ENTITY) 3.9 관계 (RELATIONSHIP) 3.10 식별자 (IDENTIFIER) 3.11 속성 (ATTRIBUTE) 3.12 정규화 (NORMALIZATION) 3.13 영역 (DOMAIN) 3.14 통합 3.15 검증

3.1 DATA MODELING 개요 DATA BASE 3.1.1 DATA MODEL 자료생성 산출물 자료갱신 정보 SYSTEM의 중심은 DATA이다 자료검색,조회 문서,장표,보고서 집계,분석자료 도표 의사결정지원,분석 감사 자료생성 자료갱신 산출물 DATA BASE 3.1.2 DATA MODELING이란 기업의 정보 구조를 실체(Entyty)와 관계(Relation)를 중심으로 명확하게 체계적으로 표현하고 문서화하는 기법 - 정보시스템의 중심을 Data의 관점에서 접근하는 분석방법으로 모든 Data구조를 연계한 정보구조 구축 - 전사적인 Data Model을 상호 연관관계를 고려하여 최적의 데이타베이스 구조 도출 3.1.3 DATA MODELING의 목적 * 연관 조직의 정보 요구에대한 정확한 이해 제공 * 분석자,개발자,사용자 간의 의사 소통 수단 * DATA 중심의 분석 방법 * 신규/개선 SYSTEM 개발의 기초 제공

3.2 DATA MODELING 위치 REAL WORLD 현실세계 (현실업무) 개념세계 (개발대상업무) 정보 MODELING 비교, 검토 DATA MODELING DATA MODEL PHYSICAL DB DATA 구조화 COMPUTER WORLD

3.3 Data Modeling 순서 Current 정보 System 정보전략계획수립 물리적 Data Modeling 상향식 방법론 (Botton-Up) 물리적 Data Modeling 논리적 Data Modeling 개념적 Data Modeling Process 재설계 하향식 방법론 (Top-Down) Data와 Process의 통합화 논리적 데이타베이스 구조 R-DBMS 특성고려 물리적 데이타베이스 구조

3.3.1 개념적 (Conceptual) Data Modeling 현재 운용중인 정보시스템을 역공학(Reverse-Engineering), 재공학(Re -Engineering)을 이용하여 정보시스템을 재구축(Re-Structuring)을 하는 단계. Current 개발대상업무 Re-Engineering Re-Structuring 현 Data Model 새로운 Data Model Reverse - Engineering Foward - Engineering 새로운 정보시스템 현 정보시스템

3.3.2 논리적 (Logical) Data Modeling 데이타구조에 대한 논리적인 설계를 하는 단계로써 정확한 업무 분석을 통한 자료의 흐름을 분석하여 현재 사용중인 양식, 문서, 장표를 중심으로 자료항목을 추출하여 추출된 실체(Entity)와 속성(Attribute)들의 관계(Relation)를 구조적으로 설계하는 단계 3.3.3 물리적 (Physical) Data Modeling 관계데이타모형(Relational Data Modeling)이라고하며 이 단계는 논리데이타 모형을 DBMS의 특성 및 효율적 데이타베이스 시스템이 되기 위한 데이타 분산 등을 고려하여 데이타베이스 스키마를 구축하는 단계

3.4 개발 주기와 DATA MODELING 3.3.1 전략단계 3.3.2 분석단계 영역정의 속성정의 SYSTEM 입력 실체정의 SUB-TYPE 실체정의 관계정의 전략정의 3.3.2 분석단계 상세영역 정의 상세속성 정의 전략정의 상세실체 KEY정의 상세관계 정의 요구명세 업무/실체 관계정의

3.5 DATA MODELING 단계 DATA MODELING 근거자료 산출물 1. 사용자 부문의 업무 파악 2. 중요 실체 관계를 파악하여 E-R Diagram 작성 3. 도출된 실체에 대한 상세정의 4. 식별자 정의 및 식별자 업무규칙 정의 5. 실체별로 속성의 상세화 (정규화) 6. 필요한 속성 및 영역의 상세정의 7. 속성에 대한 업무규칙 정의 8. 각 단계 종료후 사용자와 함께 MODEL 검토 사용자 INTERVIEW 장표,양식,대장 INTERVIEW양식 실체 항목 정의 E-R Diagram 단위 업무 조사표 INTERVIEW 양식 단위 업무 조사표 E-R Diagram 실체 List 실체 상세 정의 (식별자 관계업무 포함) (속성 상세화) 속성/영역 상세 정의 속성 업무 규착 정의

3.6 DATA MODELING 체계 (LDM) 1. 실체정의 2. 식별자정의 3. 상세화 4. 통합 5. 검증 1.1 실체정의 2.1 주/부 식별자정의 3.1 세부 속성확정 4.1 사용자 VIEW조합 5.1 실체검증 1.2 관계정의 2.2 외부 식별자정의 3.2 정규화 4.2 DATA 모형통합 5.2 관계검증 2.3 식별자 업무규칙정의 3.3 도메인 정의 4.3 안정성 / 확장성 분석 5.3 속성검증 3.4 속성별 업무규칙정의

3.7 용어 비교 FILE SYSTEM DATA MODELING RDB FILE RECORD KEY FIELD 3.7 용어 비교 FILE SYSTEM DATA MODELING RDB FILE RECORD KEY FIELD ENTITY (실체) TUPLE (튜플) IDENTIFIER(식별자) ATTRIBUTE (속성) TABLE ROW (열) KEY COLUMN (행) OODB OBJECT : DATA + PROCESS , DATA + OPERATION MESSAGE : 지령 , 명령 CLASS : DATA TYPE : 예 ) 사람 , 회사 INSTANCE : DOMAIN : 예 ) 최용락, PRO SOFTWARE INHERITANCE : 상속성, 유전인자 ENCAPSULATION

3.8 실체 (ENTITY) 3.8.1 정의 : 정보를 갖고있거나 그에 대한 정보를 알아야하는 유형,무형의 사물이나 객체 * 상호배타성 : 사물,객체는 한개의 실체에만 속해야 함 * 식별성 : 각 실체는 유일하게 식별가능해야 하며 실체내의 사례가 상호 구분될 수 있어야 함 ( 반드시 유일한 주 식별자 존재 ) 3.8.2 실체 파악 : 각 실체에 내재된 본질 파악 * 실체 파악의 장애 제거 * INTERVIEW를 기초로 파악 * 서류자료( 장표,문서,대장 )를 이용 * TOP-DOWN 방식 * 상식, 논리, 관찰력 * 실체 정의 사항 파악 : 실체명, 동의어, VOLUME 및 성장율, .....

3.8.3 하위실체 와 상위실체 (SUB-TYPE 과 SUPER-TYPE) * 실체는 상호 배타적인 2개 이상의 실체로 분할될 수 있다 * 두 실체는 상호 공통의 속성이나 관계를 갖을 수 있다 * 하위실체는 상위실체의 속성,관계,기능을 암시적으로 포함한다 자동차 고객 예 국내고객 승용차 소형 중형 서울 경기 버 스 해외고객 화물차 ASIA AMERICA 기타차량

참조실체 (Reference Entity) 3.8.4 실체 TYPE * 핵심실체 (기본실체) * 개념실체 * 관련실체 참조실체 (Reference Entity) 해당 실체에 관계를 갖고 자기쪽에서 선택적 관계를 갖고있는실체로써 다른 실체의 정확한 정의를 위해 필요한 실체 자동차 자동차 TYPE 교차실체 (Intersaction Entity) : 행위실체 두 실체간의 다 : 다 (N : N)의 관계를 해소하기 위하여 추가된 실체 제품 주문 거래선

3.9 관계 (RELATIONSHIP) 3.9.1 정의 : 두개 이상의 실체간에 명명되어진 의미있는 연결 3.9.2 관계표현 실체 # 1 실체 # 2 실체 # 1 실체 # 1 실체 # 1 실체 # 1 재귀관계 : 순환관계 ( Recursive Relationship ) 실체 # 1

3.9.3 관계파악 : 실체와 실체와의 연결을 IDENTIFIER를 기준으로 설정 3.9.4 관계의 상세화 * N : N 의 관계를 제거한다 (교차실체 추가) * 배타관계를 파악한다 판매 회사 사원 사무직 사원 생산직 * 중복된 관계를 없앤다 * 관계, 배타성등은 주식별자 또는 부식별자의 일부가될 수 있다 ( 부분관계 ) 실체 # 1 실체 # 2 S * 관계 정의 사항 파악 : 차수, 관계이름, 선택성, .....

3.9.5 실체, 관계 예제 구매발주 업무 1) 각 부서에서 구매의뢰를 한다 2) 구매의뢰에 따라 구매발주가 이루어진다 3.9.5 실체, 관계 예제 구매발주 업무 1) 각 부서에서 구매의뢰를 한다 2) 구매의뢰에 따라 구매발주가 이루어진다 3) 한 구매의뢰는 여러번 발주될 수 있다 4) 자재는 자재 MASTER에 자재코드로 관리된다 5) 한 거래처에 대해 한건의 구매당 한장의 구매발주서가 발행된다 6) 한 구매발주서에는 여러 품목을 발주할 수 있다 7) 단일 의뢰 및 발주에는 한 품목을 여러번 의뢰, 발주할 수 없다

3.10 식별자 (IDENTIFIER) 3.10.1 주 식별자 (Primary Identifier) * 각 실체의 한 사례가 그 실체의 다른 모든 사례와 구분할 수 있는 유일한 것 * 유일 식별자가될 수 있는 식별자를 후보 식별자(Candidate Identifier)라 하며 주 식별자는 그 중의 하나로 선택 * 한개의 속성, 속성의 조합, 관계의 조합, 또는 속성과 관계의 조합 3.10.2 부 식별자 (Alternate Identifier) * 후보 식별자중에서 주 식별자로 지정되지 않은 식별자 * 기타 INDEX로 활용하고자 하는 식별자 ( SORT, IF, WHERE 에 자주 사용) 3.10.3 외부 식별자 (Foreign Identifier) * 두 실체간의 관계를 결정해 주는 속성으로써 관계에 의한 종 실체(ChildEntity) 쪽에 위치하며 주 실체(ParentEntity)의 주 식별자와 같은 값을 갖는 식별자

자재 Master 거래선 Master 발주 Detail 발주 Master 3.10.4 식별자 예제 자재 Master 거래선 Master # 자재코드 # 거래선코드 자재명(AK) 규격 측정단위 상호 사업자번호(AK) 전화번호 발주 Detail 발주 Master # 발주번호(FK) # 자재코드(FK) # 발주번호 거래선코드(FK) 발주일자 수량 단가 금액

3.10.5 식별자 업무규착 정의 * 목적 : 참조 무결성( Referential Integrity)을 유지하기 위함 3.10.5 식별자 업무규착 정의 * 목적 : 참조 무결성( Referential Integrity)을 유지하기 위함 한 실체에 입력, 수정, 삭제가 발생하거나 외부 식별자 변경시 발생하는 영향을 관리 3.10.5.1 입력규칙 : Child 쪽 입력시 Parent와 관련된 규칙 * 의존형태 : Dependent Insert * 자동형태 : Automatic Insert * 기본형태 : Default Insert * 지정형태 : Customized Insert * NULL형태 : Nullify Insert * 무 관련형태 : No Effect Insert 3.10.5.2 삭제규칙 : Parent 쪽 삭제시 Child와 관련된 규칙 * 제한형태 : Restrict Delete * 연쇄형태 : Cascade Delete * 기본형태 : Default Delete * 지정형태 : Customized Delete * NULL형태 : Nullify Delete * 무 관련형태 : No Effect Delete 3.10.5.3 수정규칙 : Parent 쪽 수정시 Child와 관련된 규칙 * 제한형태 : Restrict Update * 연쇄형태 : Cascade Update

3.11 속성 (ATTRIBUTE) 3.11.1 정의 : 실체의 성질,분류,식별,수량,상태등을 나타내는 세부항목 정보의 요소로써 관리되는 항목 속성은 정확한 실체에 할당되어야하고 반드시 해당되는 실체를 기술하는 사항이어야 함. 실체에 포함되는 속성의 숫자는 가능하면 10개 항목 이하로 구성 3.11.2 속성 TYPE * 기초 속성 * 추출 속성 * 설계 속성 3.11.3 속성의 정규화 1차 정규화 : 한 실체의 한 사례는 한개의 속성에 대해 한개의 값만 갖도록 여러개의 값을 갖을 경우 새로운 실체와 1 : N의 관계 추가 2차 정규화 : 속성은 주 식별자 전체 (Whole Primary Identifier)에 의존해야 함 3차 정규화 : 속성은 주 식별자에 종속되어야 함

3.11.4 속성 파악 : 알고자하는 정보의 정확한 파악 3.11.5 속성 업무 규칙 가공 정보에 대한 파악 속성 정의 사항 파악 : 명칭, 설명,형식,길이,유효값, 기본값, .... 3.11.5 속성 업무 규칙 한 실체의 어떤 속성에 대해 입력, 수정, 삭제 발생시 같은 실체나 다른 실체에 존재하는 다른 속성들에 미치는 영향을 관리하는 규칙 이는 한 속성에 대해 발생하는 사건( Event)에 대해 연쇄적으로 발생하는 작용으로 연쇄작용 (TRIGGER Operation)이라 한다 * 속성값에 대한 무결성(Integrity), 일치성(Consistency)을 유지하는 모든 업무 규칙의 연쇄작용 정의 * 연쇄작용을 발생시키는 작업,작업대상, 발생되는 조건, 연쇄작용의 결과로 수행 되어질 작업의 정의 * 동일 실체내의 속성에 영향을 미치는 내용의 정의 * 다른 실체내의 속성에 영향을 미치는 내용의 정의 * 중복 자료의 유지에 관한 정의 * 추출 속성에 관련된 원시 속성(Source Attribute)의 Event에 대한 연쇄작용 정의

3.12 정규화 (NORMALIZATION) 3.12.1 특성 : 정규화된 DATA MODEL은 정확성, 일치성, 단순성, 비 중복성,안정성을 보장 3.12.2 정규화 목적 * 자료 저장 공간의 최소화 * DB 내부 자료의 무결성 유지 극대화 * Data 구조의 안정성 최대화 3.12.3 정규화된 수학적 표현 * 1차 정규화 : 반복되는 속성이나 Group 속성 제거 새로운 실체와 1 : N 의 관계 추가 * 2차 정규화 : 주 식별자에 완전 기능 종속되지 않는 속성 제거 불 완전 함수적 종속 (Non Fully Dependency) 제거 * 3차 정규화 : 주 식별자에 이행종속 (Transitive Dependency) 되는 속성 제거 비 식별자에 종속되는 속성 제거 * 4차 정규화 : 주 식별자에 다가종속(Multi-Valued Dependency)되는 속성을 두가지 이상 두지 않음 3.12.4 비 정규화 (DENOMALIZATION) : Data Modeling 규칙에 얽매이지 않고 수행 System이 물리적으로 구현되었을때 순전히 Performance 향상을 목적

3.13 영역 (DOMAIN) 3.12.1 정의 : Group 속성에 의거한 원자값(Atomic Value)들이 같은 구성 형태로 유효한 규칙에 따른 제한된 범위 (속성이 포함하는 유효한 값) 3.12.2 영역 정의 사항 파악 : 속성명,자료형태, 길이, 형식, 제한범위, 유일성, Null여부,유효값, 기본값, 설명,추출알고리즘..... 3.12.3 영역 정의 특성 * 주 식별자 : Unique 이며 Not-Null 2개 이상의 속성으로 구성되면 각 속성은 Not-Unique 해도 됨 * 부 식별자 : Unique 이거나 Not-Unique 구성하는 각 속성은 Null 허용 (가능하면 Not-Null로) * 외부 식별자 : 외부 식별자 영역 특성은 관련 Parent의 주 식별자와 동일 1 : 1 이거나 1 : 0 의 관계일때 Unique * 추출 속성 영역 정의 : 제한 범위에 추출 알고리즘 명시 추출 알고리즘이 없으면 원시 속성과 같은 영역 특성

3.14 통합 3.14.1 사용자 VIEW 조합 : 서로 다른 업무 영역내의 다른 사용자간의 Data Model 통합 3.14 통합 3.14.1 사용자 VIEW 조합 : 서로 다른 업무 영역내의 다른 사용자간의 Data Model 통합 목적 : 사용자 VIEW간의 중복성, 불일치성 제거 및 새로운 관계 추가, 업무 규칙 추가 진행단계 : 실체 및 관련 업무 규칙 통합 관계 및 관련 업무 규칙 통합 속성 및 관련 업무 규칙 통합 3.14.2 DATA 모형 통합 : 실체 통합 목적 : 동일한 (유사한) 주 식별자와 주 식별자 영역을 갖는 실체들을 통합 진행단계 : 기존 DB Schema와 신규 Data Model 통합 기존 Schema와 신규 Data Model간의 실체 통합 기존 Schema와 신규 Data Model간의 관계 통합 기존 Schema와 신규 Data Model간의 속성 통합

3.14.3 안정성/확장성 분석 : 목적 : 현재 업무를 분석한 Data Model을 향후 변경 가능성에 쉽게 대처할 수 있도록 안정성, 확장성을 고려하여 Data Model을 수정함 효과 : 정규화된 DB는 DB 변경에 따른 System 변경을 최소화 함 진행단계 : 실체 변경 가능성 분석 관계 변경 가능성 분석 식별자 변경 가능성 분석 속성 변경 가능성 분석 업무 규칙 변경 가능성 분석

3.15 검증 3.15.1 정의 : E-R Modeling의 검증은 품질 보증 및 완전성을 보장한다 3.15 검증 Group Check 및 User확인 완전성 검증 실체,관계,속성 품질 검증 규칙 검증 3.15.1 정의 : E-R Modeling의 검증은 품질 보증 및 완전성을 보장한다 3.15.2 GROUP CHECK 및 USER확인 Group Check : 업무의 완전한 이해와 E-R에 대한 완전한 이해를 갖은 숙련된 분석가와 함께 Project Team 내의 동료끼리 상호 Model을 Check 하고 Error를 찾아본다 User 확인 : 정기적 혹은 수시로 User에게 Model을 제시하면서 확인한다 User를 적극 참여시켜 Error와 누락 부분을 Check한다 3.15.3 규칙 검증 : 분석된 모든 규칙을 다시 검증한다

3.15.4 실체 품질 검증 : 3.15.5 관계 품질 검증 3.15.6 속성 품질 검증 3.15.7 완전성 검증 3.15.4 실체 품질 검증 : * 단수의 의미있는 이름 * 상호 배타성 * 최소한 2 개의 속성 * 대체로 10 개 이하의 속성 * 동의어 / 동음이의어 * 상세 정의 * 주 식별자 * 최소 한개 이상의 관계 * 분산 요구 * 실체를 생성,조회,수정,삭제,저장하는 업무기능 * 시간에 따른 변화 * 자료 정규화 3.15.5 관계 품질 검증 * 각 Node의 이름 * 2 개 이상 Node와의 관계 * 각 Node의 차수와 선택성 * 유효한 관계 * 1:1 이거나 1: 0 의 관계 * 중복된 관계 * 시간에 따른 변화 * 필수적 관계 (실체를 항상 관계 지을 수 있는가) 3.15.6 속성 품질 검증 * 단수의 의미있는 이름 * 속성당 값이 한개 * 반복 , Group 값은 없는가 * 형식,길이,허용치,유도식등의 정의 * 시간에 따른 변화 * 관련 영역이 존재하는가 * 주 식별자의 일부에만 의존 * 비 식별자에 의존 3.15.7 완전성 검증 * 사용자 Interview,System문서, 장표,보고서, .... 등과 비교 * 입력 화면, 출력보고서가 모두 산출될 수 있는가

4 . 관계형 DATABASE 전환 4.1 SCHEMA 단계 4.2 관계형 DB 전환 체계도 관계형 DataBase 전환은 논리 Data모형(LDM)을 각 DBMS의 기능과 성능 및 Data의 분산 형태등을 고려하여 관계형 DataBase Schema로 변환하는 과정이다 4.1 SCHEMA 단계 4.2 관계형 DB 전환 체계도 4.3 데이타의 분할 및 테이블의 분할 4.4 APPLICATION 개발 단계

4.1 SCHEMA 단계 4.1.1 SCHEMA 설계 단계 근거 자료 산출물 R-DB 설계 1. Data Model을 RDB Schema로 변환 2. 업무규칙정의를 Trigger Code로 변환 3. Performance 분석을 통한 비정규화를 실시하여 무결성 유지를 위한 Trigger를 실시 4. TABLE 생성 5. VIEW 생성 6. INDEX 생성 E-R Diagram 실체상세정의표 KEY 업무규칙 속성업무규칙 Table List Table 정의표 Trigger Code Table 정의 (추가, 수정) Physical Table Physical View Physical Index Index List

4.1.2 DATA SCHEMA 단계 USER # 1 USER # 2 USER # n DATA MODELING USER View # 1 USER View # n 개념 Schema (Conceptual Schema) R-DB 설계 물리적 Schema (Physical Schema) DATABASE

4.2 관계형 DB 전환 체계도 1. Data 사용량 분석 2. Data 분산 분석 3. Data 구조 전환 4. Data 무결성 전환 1.1 Data 구조도 작성 2.1 분산/집중 요구 분석 3.1 DBMS 환경 적용 4.1 실체 무결성 전환 1.2 Data 요구 정의 2.2 분산 Data 형태 파악 3.2 TABLE 정의 4.2 참조 무결성 전환 1.3 Data 사용량 분석 2.3 분산 결정 및 검증 3.3 Column 정의 4.3 Domain 무결성 정의

4.2.1 Data 사용량 분석 Data 사용량 분석은 구축 System의 기능, 성능에 많은 영향을 주게 되므로 기존의 Data Volumn뿐 아니라 향후 요구되어지는 Data 의 증가량에 대한 정확한 분석을 필요로 한다 이 분석 결과로 기존 자원(Resource)의 활용 효율을 기획할 수 있으며 새로운 요구등을 분석할 수 있다 분석 결과 활용 Data 분산 설계의 기초 자료 Phisical DB 설계의 기초 자료 -. 저장 공간의 확보 -. Disk 상의 배치 결정 -. DataBase 분할 Performance 향상 Tunning의 기초 -. Access 방법의 Tunning -. Index Tunning -. DB구조 재정의 Tunning

4.2.1.1 Data 구조도 (Data Structured Diagram) 작성 ERD의 물리적 확장 -. 실체 : 기본키, 실체건수, Row길이, 실체유형 -. 관계 : 차수비율, 외부키 업무 규칙 -. 참조 시작점 (Entry Point) (자재코드,자재명) (지역재고KEY) (지역코드,지역명) 자재 Master 지역/재고 Detail 지역Master 1 : 5 5000 : 1 자재 코드 지역코드 자재 코드 지역코드 (IA/DR) (DR/ID) 7000 10 / M 235 M 3만 5천 1500 / M 110 D 7 None 240 M 4.2.1.2 Data 요구 정의 사용자의 관점에서 예상되는 Data요구의 주요 성격 분류 -. 처리성격 -. 처리수준 -. 처리유형 -. 성능기대치 사용자와 함께 중요한 Data 요구에 대한 규명 기능, 성능 측면에서 문제가 발생될 수 있는 Transaction, Query, Batch Job 등을 규명 선택된 처리에 대하여 Data Access Diagram 작성

4.2.1.3 Data 사용량 분석 1. 대상 System의 ERD와 Action Diagram 작성 DUA 1 2. 실체간 관계의 평균 차수 (Cardinarity Number) 산출 및 표기 DUA 2 3. Action Diagram의 각 Data Access Line에 Access 경로 기록 DUA 3 4. 각 Access 경로에 평균 차수 산출 및 기록 DUA 4 5. Action Diagram의 각 Step별 수행 확률 및 평균 반복 횟수 기록 DUA 5 6. “5”항을 기초로 단위 시간 동안의 Data Access 횟수 기록 DUA 6 7. 해당 Program에 대한 Data Access 집계표 작성 DUA 7 (Buffer에 의한 Access는 제외됨) 8. 동시에 수행되어지는 복수 Program의 분석 DUA 8 (각각에 대하여 “3” - “7” 까지 분석하여 집계) 9. Access 경로별로 분리하여 집계 DUA 9 10. ERD 상의 Access 경로별로 해당 실체에 대한 Access 횟수 표시 DUA 10

DUA 1 CUSTOMER ORDER PRODUCT ORDER- PRODUCT BACK-ORDER INVOICE Order processing procedure read CUSTOMER if customer is invalid process invalid-order print REJECT-NOTICE else if CREDIT-RATING < 3 process poor-credit order print REJECT-NOTICE set ORDER-TOTAL = 0 create ORDER if not subscription customer prepare invoice header print INVOICE-HEAD create INVOICE for each product ordered read PRODUCT if product is invalid print error message if QOH < ORD-QTY create BACK-ORDER print BACK-ORDER-NOTICE ORD-PRICE = STD-COST L-TOT = ORD-QTY * ORD-PRICE ORD-TOT = ORD-TOT + L-TOT create ORDER-PRODUCT create INVOICE-PRODUCT print INVOICE-LINE ORD-TOT = ORD-TOT * (1 - DISCOUNT / 100) ORD-STAT = “Y” update ORDER update INVOICE print INVOICE-TOTAL DUA 1 CUSTOMER ORDER PRODUCT ORDER- PRODUCT BACK-ORDER INVOICE INVOICE- PRODUCT

DUA 2 CUSTOMER ORDER PRODUCT ORDER- PRODUCT BACK-ORDER INVOICE 1 1 ORDER PRODUCT 5 2.7 1 1 50000 1 1 1 ORDER- PRODUCT 3.5 1 0.04 30000 BACK-ORDER 1.4 1.8 INVOICE 5 1 50000 INVOICE- PRODUCT 3.5

DUA 3 DUA 4 Order processing procedure read CUSTOMER *** access path from entry to CUSTOMER ***************************** *** average path cardinarity : NA if customer is invalid process invalid-order print REJECT-NOTICE else if CREDIT-RATING < 3 process poor-credit order print REJECT-NOTICE set ORDER-TOTAL = 0 create ORDER *** access path from CUSTOMER to ORDER ********************** *** average path cadinarity : 5 if not subscription customer prepare invoice header print INVOICE-HEAD create INVOICE *** access path from CUSTOMER to INVOICE ************************* *** average path cardinarity : 5 for each product ordered read PRODUCT *** access path from entry to PRODUCT ****************************** if product is invalid print error message if QOH < ORD-QTY create BACK-ORDER *** access path from ORDER to BACK-ORDER ******************* *** average path cardinarity : 0.04 print BACK-ORDER-NOTICE ORD-PRICE = STD-COST L-TOT = ORD-QTY * ORD-PRICE ORD-TOT = ORD-TOT + L-TOT create ORDER-PRODUCT *** access path from ORDER to ORDER-PRODUCT ************ *** average path cardinarity : 3.5 create INVOICE-PRODUCT *** access path from INVOICE to INVOICE-PRODUCT ******** print INVOICE-LINE ORD-TOT = ORD-TOT * (1 - DISCOUNT / 100) ORD-STAT = “Y” update ORDER *** access path from CUSTOMER to ORDER ************************** update INVOICE print INVOICE-TOTAL Order processing procedure read CUSTOMER *** access path from entry to CUSTOMER ***************************** if customer is invalid process invalid-order print REJECT-NOTICE else if CREDIT-RATING < 3 process poor-credit order print REJECT-NOTICE set ORDER-TOTAL = 0 create ORDER *** access path from CUSTOMER to ORDER ********************** if not subscription customer prepare invoice header print INVOICE-HEAD create INVOICE *** access path from CUSTOMER to INVOICE ************************* for each product ordered read PRODUCT *** access path from entry to PRODUCT ****************************** if product is invalid print error message if QOH < ORD-QTY create BACK-ORDER *** access path from ORDER to BACK-ORDER ******************* print BACK-ORDER-NOTICE ORD-PRICE = STD-COST L-TOT = ORD-QTY * ORD-PRICE ORD-TOT = ORD-TOT + L-TOT create ORDER-PRODUCT *** access path from ORDER to ORDER-PRODUCT ************ create INVOICE-PRODUCT *** access path from INVOICE to INVOICE-PRODUCT ******** print INVOICE-LINE ORD-TOT = ORD-TOT * (1 - DISCOUNT / 100) ORD-STAT = “Y” update ORDER *** access path from CUSTOMER to ORDER ************************** update INVOICE print INVOICE-TOTAL DUA 3 DUA 4

DUA 5 Order processing procedure *** average no. of execution per transaction : 1 read CUSTOMER *** access path from entry to CUSTOMER ***************************** *** average path cardinarity : NA if customer is invalid *** probability of this branch : 0.007 *** average no. of execution per transaction : 0.007 process invalid-order print REJECT-NOTICE else *** probability of this branch : 0.993 *** average no. of execution per transaction : 0.993 if CREDIT-RATING < 3 *** probability of this branch : 0.024 *** average no. of execution per transaction : 0.023832 process poor-credit order print REJECT-NOTICE *** probability of this branch : 0.969 *** average no. of execution per transaction : 0.969165 set ORDER-TOTAL = 0 create ORDER *** access path from CUSTOMER to ORDER ********************** *** average path cadinarity : 5 if not subscription customer *** probability of this branch : 0.3 *** average no. of execution per transaction : 0.2907504 prepare invoice header print INVOICE-HEAD create INVOICE *** access path from CUSTOMER to INVOICE ************************* *** average path cardinarity : 5 for each product ordered *** average no. of iterations per bracket : 3.5 *** average no. of execution per transaction : 3.392088 read PRODUCT *** access path from entry to PRODUCT ****************************** if product is invalid print error message *** probability of this branch : 0.005 *** average no. of execution per transaction : 0.01696044 *** probability of this branch : 0.995 *** average no. of execution per transaction : 3.2224836 if QOH < ORD-QTY *** probability of this branch : 0.04 *** average no. of execution per transaction : 0.12839934 create BACK-ORDER *** access path from ORDER to BACK-ORDER ******************* *** average path cardinarity : 0.04 print BACK-ORDER-NOTICE else *** probability of this branch : 0.96 *** average no. of execution per transaction : 3.0935842 ORD-PRICE = STD-COST L-TOT = ORD-QTY * ORD-PRICE ORD-TOT = ORD-TOT + L-TOT create ORDER-PRODUCT *** access path from ORDER to ORDER-PRODUCT ************ *** average path cardinarity : 3.5 if not subscription customer *** probability of this branch : 0.3 *** average no. of execution per transaction : 0.92507526 create INVOICE-PRODUCT *** access path from INVOICE to INVOICE-PRODUCT ******** print INVOICE-LINE ORD-TOT = ORD-TOT * (1 - DISCOUNT / 100) ORD-STAT = “Y” update ORDER *** access path from CUSTOMER to ORDER ************************** *** average path cardinarity : 5 *** average no. of execution per transaction : 0.2907504 update INVOICE *** access path from CUSTOMER to INVOICE ************************* print INVOICE-TOTAL

DUA 7 DUA 6 Action Diagram : ORDER Processing Procedure for each order read CUSTOMER *** average no. of exwcutions per peak hour : 200******************* if customer is invalid process invalid-order print REJECT-NOTICE else if CREDIT-RATING < 3 process poor-credit order print REJECT-NOTICE set ORDER-TOTAL = 0 create ORDER *** average no. of exwcutions per peak hour : 193.8336************* if not subscription customer prepare invoice header print INVOICE-HEAD create INVOICE *** average no. of exwcutions per peak hour : 58.15008************* for each product ordered read PRODUCT *** average no. of exwcutions per peak hour : 678.4176************ if product is invalid print error message if QOH < ORD-QTY create BACK-ORDER ** average no. of exwcutions per peak hour : 25.79868*********** print BACK-ORDER-NOTICE ORD-PRICE = STD-COST L-TOT = ORD-QTY * ORD-PRICE ORD-TOT = ORD-TOT + L-TOT create ORDER-PRODUCT *** average no. of exwcutions per peak hour : 618.71684********* create INVOICE-PRODUCT *** average no. of exwcutions per peak hour : 185.61505****** print INVOICE-LINE ORD-TOT = ORD-TOT * (1 - DISCOUNT / 100) ORD-STAT = “Y” update ORDER *** average no. of exwcutions per peak hour : 193.8336************ update INVOICE *** average no. of exwcutions per peak hour : 58.15008************ print INVOICE-TOTAL DUA 7 DUA 6 Action Diagram : ORDER Processing Procedure Number Of Transactions in the Peak Hour : 200 Access to buffer, not to phisical database (Y)***** Number of refferences in the peak hour******* Number of references per transaction*** Average path cardinality************ Type of access (CRUD)********* Access to********** Access from** Number 1 Entry CUSTOMER R NA 1 200 2 CUSTOMER ORDER C 5 0.969 193.834 3 CUSTOMER INVOICE C 5 0.291 58.150 4 Entry PRODUCT R NA 3.392 678.418 5 ORDER BACK-ORDER C 0.04 0.129 25.799 6 ORDER ORDER-PRODUCT C 3.5 3.094 618.717 7 INVOICE INVOICE-PRODUCT C 3.5 0.928 185.615 8 CUSTOMER ORDER U 5 0.969 193.834 Y 9 CUSTOMER INVOICE U 5 0.291 58.150 Y TOTAL NUMBER OF REFERENCES : 9.803 1960.532

DUA 8 Action Diagram 1 : ORDER Processing Procedure Number Of Transactions in the Peak Hour : 200 Action Diagram 2 : Customer Order Enquiry Number Of Transactions in the Peak Hour : 30 DUA 8 Action Diagram 3 : Invoice Follow-up Number Of Transactions in the Peak Hour : 100 Access number********** Action diagram********** Number of references in the peak hour********** Number of references per transaction********** Average path cadinarity********* Type of access (CRUD)********** Access to********** Access from********** Entry CUSTOMER ORDER ORDER-PRODUCT INVOICE PRODUCT BACK-ORDER INVOICE-PRODUCT R C U NA 5 3.5 1 1.8 0.04 0.96 0.99 3.392 0.969 4.95 0.291 3.094 17.325 0.129 0.693 3.36 0.928 200 27.9 100 678.418 193.834 148.5 58.150 618.717 519.75 350 180 25.799 20.79 4 336 185.615 2 3 6 7 8 TOTAL NUMBER OF REFERENCES : 3847.473

DUA 9 Number of accesses in the peak hour Access From Access To Entry CUSTOMER ORDER ORDER-PRODUCT INVOICE CUSTOMER ORDER PRODUCT INVOICE ORDER-PRODUCT BACK-ORDER INVOICE-PRODUCT 227.9 100 678.418 342.334 58.150 1488.467 180 50.589 336 185.615 TOTAL NUMBER OF REFERENCES : 3847.473

DUA 10 CUSTOMER PRODUCT ORDER ORDER- PRODUCT BACK-ORDER INVOICE 1,2 1 228 3 CUSTOMER 1,2 678 100 100 342 100 3 PRODUCT ORDER 1,2,3 1142 ORDER- PRODUCT 1 3 1,2,3 51 BACK-ORDER 3 180 INVOICE 3 58 1 336 187 INVOICE- PRODUCT

4.2.2 Data 분산 분석 Allocating Data to Devices Data와 Device의 할당은 각 DBMS의 구조를 이해하고 Data Base의 크기 및 관리되는 File의 종류 그리고 File의 유형등을 이해하여야 한다. 또한 각 테이블간의 친화력 및 처리 방법 및 자주 사용하는 유형등을 고려하여야 한다 지역적으로 여러 Node에 Data를 존재시킬 필요가 있거나 Client/Server 환경의 DownSizing을 고려하는 경우 등 필요에 따라 Data의 분산을 고려하게 된다 분산시에는 해당 Data의 특성을 고려하여 집중적으로 부하가 걸리는 Node가 없도록 Data의 분산 형태를 결정해야 한다 4.2.2.1 Data 분산/집중 요인 Data 분산 요인 Data 집중 요인 Data 중복 요인 4.2.2.2 분산 Data의 형태 Duplicated Data Subset Data Reorganized Data Partitioned Data Seperate-Schema Data Incompatable Data

4.2.2.3 분산 결정 및 검증 업무활동 / 사업장 대비표 실체 / 사업장 대비표 District Office 4.2.2.3 분산 결정 및 검증 업무활동 / 사업장 대비표 실체 / 사업장 대비표 District Office Warehouse Head Office Factory A Factory B Factory C Branch Office LOCATION District Office Branch Office Head Office Warehouse Factory A Factory B Factory C District Office Branch Office Head Office Warehouse Factory A Factory B Factory C PROCESS LOCATION LOCATION DATA STRUCTURE DATA STRUCTURE KEY : U = Use C = Create and Use KEY M = Master data : unique in one location. V = Variant : dIfferent schema version on different locations P = Partitioned data : same schema, different values. D= Replicated data : identical data in different locations. S = Subset data. R = Reorganized data. T = Teleprocessing : data not stored on this location. KEY : X = Major Involvement / = Minor Involvement

Data의 분산이 더 작은 전송을 나타내기 위해서는 Node간 교통량 분석 N 개의 사업장 Au : 시간당 Data를 사용하는 처리 수 Ac : 시간당 Data를 변경(Change)하는 처리 수 T : 시간당 전송횟수 집중 Data일 경우 시간당 전송횟수 합계 Tc = (Au + Ac) * (N - 1) / N 분산 Data일 경우 시간당 전송횟수 합계 Td = Ac * (N - 1) Data의 분산이 더 작은 전송을 나타내기 위해서는 (Au + Ac) * (N - 1) / N > Ac * (N - 1) Au / Ac > (N - 1)

4.2.3 DATA 구조 전환 4.2.3.1 DBMS 환경 적용 4.2.3.2 TABLE 정의 4.2.3.1.3 DBMS Parameter 파악 및 설정 4.2.3.2 TABLE 정의 4.2.3.2.1 1단계 : 실체 변환 단순한 실체 (Sub-Type이 없거나 아닌 것) : Table로 변환 4.2.3.2.2 2단계 : 속성 변환 각 속성 : 같은 이름의 Column으로 변환 선택적 일때 Null , 필수적 일때 Not Null로 지정 4.2.3.2.3 3단계 : 기본 키 (Primary Key) 변환 실체 (Entity)의 기본 키 (PK) : Table의 기본 키로 변환

4.2.3.3 COLUMN 정의 4.2.3.2.4 4단계 : 외래 키 (Foreign Key) 변환 1 : 1 이거나 N : 1 관계는 외부 식별자 (FK)가 된다 “1” 쪽 참조 실체의 주 식별자(PK)를 “N” 쪽의 Column으로 등록한다 선택적 관계이면 Null , 필수적 관계이면 Not Null로 지정 4.2.3.2.5 5단계 : INDEX 설계 기본 키 (PK) : 유일 Index 외래 키 (FK) 다중 Column Index에서 나온 Column은 다시 Index로 지정할 필요 없다 Select 와 Where 구에 자주 나타나는 속성은 Index로 지정 4.2.3.2.6 6단계 : SUB-TYPE 변환 Sub Type은 자신의 속성을 갖고 Super Type의 속성과 관계를 계승받음 구현방법 : 1) 전체를 한개의 Table로 구현 (구분 Column 추가) 2) Sub Type용 Table을 따로 구현 4.2.3.2.7 7단계 : 배타 관계 구현 공통 영역으로 구현 명시적 FK로 구현 4.2.3.3 COLUMN 정의 4.2.3.3.1 LDM을 근거로 변환 4.2.3.3.2 DOMAIN 규칙 정의

4.2.4 DATA 무결성 전환 4.2.4.1 실체 무결성 전환 (Entity Integrity Rule) Primary Key 는 Null 이 될수 없으며 Unique 하다 4.2.4.2 참조 무결성 전환 (Referential Integrity Rule) Foreign Key를 포함한 Table에서 FK인 속성은 참조 Table에서는 PK이다 FK Column은 참조 Table의 값과 일치되든지 Null 값이어야 한다 4.2.4.3 허용 무결성 전환 (Domain Integrity Rule) 특정 Column이 취할 수 있는 값의 범위를 정의 항상 일정한 규칙을 갖고 유지되도록 정의

4.3 데이타의 분할 및 테이블의 분할 중복 데이타의 허용 설계 속성의 이용 테이블의 분할을 이용 * 정규화 규칙에 얽매이지 않는 성능향상을 목적으로한 비정규화(De-Nomalization) 을 통한 중복 데이타를 허용. * Table의 중복과 Column의 중복을 고려 설계 속성의 이용 * 특정 업무에 있어서 지속적으로 대상 테이블 전체를 스캔하는 업무등을 처리하기 위하여 사용 * 특정 Table을 지속적으로 ORDER-BY , GROUP-BY를 수행하여 상태등을 비교하는 업무등에 사용 테이블의 분할을 이용 * 테이블이 너무 커져서 데이타베이스 버퍼 블럭을 제대로 사용하지 못 할때 고려 * 서로 연관있는 항목별로 분할 * 성능이 고려되는 테이블에 입력/수정/삭제가 빈번히 발생되면 고려

2. Application 에 대한 Data Model을 근거 자료 산출물 1. 업무를 대,중,소 분류하고 단위업무 정의 2. Application 에 대한 Data Model을 확인하며 논리 Access Map을 작성 3. Application Spec 작성 사용자 Interview 양식, 장표 업무흐름도 업무기능계층도 단위업무기능도 LAM Application Table Application List 단위 Application정의 Application 생성 근거 자료 산출물 1. Form (화면, 보고서)을 작성 가능하면 JAD기법 이용 2. Source Code 생성 및 실행 Module 생성 Program Spec 장표, 양식 화면 Form 보고서 Form Source Program Run Module

5 . DATA MODELIMG WORKSHOP 5.1. Data Modeling Workshop 단계 5.2. 세금 계산서 처리 업무 5.3. 전표 처리 업무 5.4. VIDEO SHOP 관리 업무 5.5. 문서 관리 업무 5.6. 인사 관리 업무 5.7. 항공 예약 업무 5.8. 학사 관리 업무 5.9. 정보시스템 관리 업무

5.1. Data Modeling Workshop 단계 5.1.1 실체 정의 5.1.2 실체 관계도 작성 5.1.3 식별자 정의 5.1.4 외부 식별자 업무 규칙 정의 5.1.5 세부 속성 정의 5.1.6 도메인 정의 5.1.7 속성 업무 규칙 정의 5.1.8 Data 모형 검증 (정규화 검증 포함)

5.2. 세금 계산서 처리 업무 세금계산서에는 매입 / 매출이 있다 매입 세금계산서는 3종류가 있다 (세금계산서, 수입세금계산서, 계산서) 수입세금계산서에는 수입 신고번호와 $ 금액이 나타난다 매입 / 매출 세금계산서에는 회계에 연결하기위한 전표번호를 갖는다 매출 세금계산서는 2종류가 있다 (세금계산서, 계산서) 각 세금계산서는 사업자등록번호별로 고유의 책번호를 갖는다 매출 세금계산서가 외국인 경우에는 수출 신고번호와 $ 금액을 갖는다 1) 주어진 양식과 산출물을 분석하여 위의 면담 결과 요약 내용을 포함하는 E-R Diagram을 작성하라 2) 단계별 산출물을 작성하라 5.3. 전표 처리 업무 1) 주어진 전표는 조흥은행의 수입 결재 전표이다 이 전표의 속성을 분석하여 E-R Diagram을 작성하라 2) 단계별 산출물을 작성하라

5.4. VIDEO SHOP 관리 업무 1) 위의 면담 결과 요약 내용을 이용하여 E-R Diagram을 작성하라 회원제를 실시하는 VIDEO TAPE 상점들이 있다 회원은 회비를 납부한 경우에만 자격을 획득한다 상점들은 지역별로 관리된다 각 상점에서는 TAPE 관리를 TAPE에 부여된 일련번호로 관리한다 동일한 일련번호를 가진 TAPE가 여러개 존재할 수 없다 TAPE에는 상세정보를 관리하며 관리되는 내용은 TAPE종류등을 분류 관리하고, 제작사, 유형, 감독, 주연배우 등을 관리한다 TAPE는 최초 대여시 최초 대여 발생일을 관리한다 대여는 대여 관리번호로 관리되며 대여 관리번호는 일자별 순번으로 한다 대여는 각 TAPE의 대여 개시 일자와 대여 종료 일자를 관리한다 TAPE 대여금은 일자별로 일일 이용료를 적용하며 이용료는 일반 가격과 회원 가격이 있다 TAPE 대여료는 대여 일수를 기준으로하며 대여 개시에 할 수도 있고 대여 종료시에 할 수도 있다 TAPE에 손상이 발생되면 대여할 수 없는 것으로 표시하고 일정시점에 파기한다 상점 관리자를 돕기위해 TAPE별로 총 대여 횟수 및 일수를 관리한다 TAPE 목록에는 현재 상점에 비치되지 않은 TAPE 정보도 관리한다 1) 위의 면담 결과 요약 내용을 이용하여 E-R Diagram을 작성하라 2) 단계별 산출물을 작성하라

5.5. 문서 관리 업무 1) 위의 면담 결과 요약 내용을 이용하여 E-R Diagram을 작성하라 문서는 관리 번호로 관리 된다 문서는 작성 부서 및 작성자가 있으며 분류 체계에 따라 관리 된다 문서가 당사의 것이 아닌 경우에는 발신처와 접수자를 관리한다 문서는 각 부서별로 관리 된다 보관 문서에는 보존 년한이 있으며, 작성일자, 폐기일자, 발신, 수신, 특기사항을 관리한다 각 부서에는 같은 종류의 문서가 2개 이상 존재할 수 없다 각 부서는 문서를 FILE HOLDER별, BOX별로 관리하며 CABINET에 보관한다 문서는 FILE HOLDER에 FILE HOLDER는 BOX에, BOX는 CABINET에 보관된다 각 부서의 문서에는 관리 담당자가 있으며 HOLDER, BOX, CABINET에도 관리 담당자가 있다 보관되던 문서는 일정 기간이 경과된 후 보관 창고로 옮겨진다 문서는 부서간 이동이 있을 수 있다 문서의 조회는 관리번호별, 분류코드별, 제목별로 검색가능해야 하며 현재 보관위치를 정확히 제시해야 한다 1) 위의 면담 결과 요약 내용을 이용하여 E-R Diagram을 작성하라 2) 단계별 산출물을 작성하라

5.6. 인사 관리 업무 5.7. 항공 예약 업무 1) 주어진 인사 기록 카드 내용을 이용하여 E-R Diagram을 작성하라 2) 단계별 산출물을 작성하라 5.7. 항공 예약 업무 부서는 인사부, 운항부, 예약부, 정비부가 있다 조종사는 비행시간에 따라 수당을 지급한다 승무원은 운항 기본시간을 초과하면 특별 수당이 지급된다 예약부 직원은 예약 건수별로 수당이 지급된다 운항부에서는 운항 Schedule을 조정한다 운항부에서 조종사와 승무원을 배치한다 운항은 운항 기본시간이 있으며 출발 및 도착시간을 관리한다 운항되는 비행기는 출발공항 및 도착공항, 그리고 경유공항을 관리한다 단 경유공항은 한 곳으로 한정한다 탑승 업무는 공항에서 운항부 직원이 수행한다 정비부에서는 비행기에 대하여 정기정비와 특별정비를 수행하여 History관리한다 1) 위의 면담 결과 요약 내용을 이용하여 E-R Diagram을 작성하라 2) 단계별 산출물을 작성하라

5.8. 학사 관리 업무 1) Data Modeling 하여 E-R Diagram을 작성하라 2) 단계별 산출물을 작성하라 학생은 여러 강의를 들을 수 있다 교수는 여러 강의를 담당할 수 있다 선수과목을 이수해야 들을 수 있는 과목이있다 학기별 과목별로 평점이 산출된다 평점은 A, B, C, D, F 학점이고 각각 5, 4, 3, 2, 0의 점수를 갖는다 평점 F는 과락이다 강의는 주당 배정시간이 있고 학점비중치를 갖는다 한 학기당 학생은 20학점 이상을 신청할 수 없다 학생은 학년 및 전공학과가 있다 전공과목에는 필수과목과 선택과목이 있다 강의는 제한인원이 있어 초과 인원은 수강신청을 받지 않는다 과락을 하지 않는한 같은 과목을 2번 이상 신청할 수 없다 평균학점은 (과목별 학점비중치 * 평점점수) (신청한 과목별 학점비중치 합계) 이다 평균학점이 2.0미만 이거나 과락이 2개 이상이면 학사경고가 된다 학사경고가 2회 이면 정학이다 전공 필수과목을 모두 이수하고 총 140학점 이상이면 졸업한다 1) Data Modeling 하여 E-R Diagram을 작성하라 2) 단계별 산출물을 작성하라

5.9. 정보시스템 관리 업무 1. 각 회사마다 사내의 업무가 전산화됨으로써 각 업무별로 또는 각 부서의 요구에 따라서 많은 1. 각 회사마다 사내의 업무가 전산화됨으로써 각 업무별로 또는 각 부서의 요구에 따라서 많은 PROGRAM들이 존재할 것이다. 그러나 이런 PROGRAM들을 관리하지 않고 있기 때문에, 적시에 원하는 PROGRAM을 찾기 어려우며, 그 PROGRAM이 존재하는지 조차도 몰라서 사장되기도 하며, 심지어는 다시 작성하는 일도 무척 많이 발생한다. 이것은 해당 PROGRAM담당자가 부재중이거나 바뀌면 더욱 심화될 수 있다. 따라서 이제는 PROGRAM을 관리해야 할 필요성을 느끼게된다. 만약 우리가 PROGRAM의 유형에 따라서 관리하고 각 PROGRAM에서 처리하는 항목들을 관리한다면, 어느 누구라도 원하는 PROGRAM을 찾아서 쉽게 참조할 수 있을 것이다. 이 경우 PROGRAM 수의 증가도 감소시킬 수 있으며, 기존 PROGRAM의 재사용 차원에서 많은 개발비용 및 유지보수 비용을 감소시킬 수 있을 것이다. 2. 사내 업무를 전산화하는 중에 있는, 개발자들은 업무개발이나 코딩 중에, 서로 의사소통을 해야 하는 경우가 많이 발생하게된다. 통상적으로, 업무진척도 제출하는 경우도 있고, 테스트 중에 오류를 발견하여 이를 해결하여야 하는 경우도 있고, 제안을 하는 경우도 있을 것이다. 그러나 그 사항을 메모해 두었다가, 적어도 2인 이상이 반드시 직접 만나거나 통화상으로 의견을 나누어야만 처리가 가능하게된다. 따라서 위와 같은 작업을 전산화한다면 작업 load를 줄일 수 있을 것이고. 특히 개발자들이, 물리적으로 멀리 떨어져 있거나 지속적으로 만날 수 없는 경우라면, 시간적으로 상당한 능률상승을 기대할 수 있을 것이다.

정보시스템 관리 업무 Workshop (목표) 1. 사내에 산재해 있는 PROGRAM과 개발중인 PROGRAM을 효율적으로 관리하여, 궁극적으로는 신속한 업무 진행을 도모하는 것을 목표로 하고 있다. 2. 이용 대상은 PROGRAM개발자(즉, 전산실담당자)와 PROGRAM관리자(즉, 전산실 담당자로 PROGRAM 개발자와 동일할 수도 있다)와 그 PROGRAM을 사용하는 모든 부서의 사원을 대상으로 한다. 3. PROGRAM개발자 입장에서 목적은 다음과 같다. - 개발자간에 필요한 개발진행 보고서를 전산화함으로써, 개발자간의 N * (N-1) / 2의 통신비용을 가능한 줄인다. - PROGRAM을 업무의 단위별로 유형별로 관리하고, 각 PROGRAM에서 처리하는 자료별로 관리함으로써, 기존에 작성된 PROGRAM을 참조하거나 재활용할 수 있게 하여 개발비용을 감소시킬 수 있게 한다. - TEST하여 오류가 발생하거나 제안을 하고자 할 때에는, 해당 PROGRAM별로 그 내용을 관리하므로 PROGRAM 작성자를 조회해서 E-MAIL할 번거러움을 없앤다. 또한, 발생 즉시 그 내용을 등록하기 때문에 시간지연으로 인해 잊어버릴 염려를 없앤다. 4. PROGRAM 관리자 입장에서 목적은 다음과 같다. - PROGRAM을 업무의 단위별로 유형별로 관리하고, 각 PROGRAM에서 처리하는 자료를 관리함으로써 사용자 요구에 부합하는 PROGRAM 작성과 정정을 용이하게 하여 유지보수비용을 감소시킬 수 있게 한다. 한 PROGRAM을 여러 부서에서 참조할 때는 유지보수차원에서 그 부서를 관리한다. 5. PROGRAM 사용자 입장에서 목적은 다음과 같다. - 사용자가 필요로 하는 PROGRAM이 등록되어 있다면 조회하여 적시에 신속히 활용할 수 있도록 하는 데 있다. - PROGRAM 사용중에 사용자가 발견한 오류나 제안이 있을 때, 해당 PROGRAM별로 그 내용을 관리하므로 PROGRAM 관리자를 조회해서 E-MAIL할 번거러움을 없앤다. 또한, 발생 즉시 그 내용을 등록하기 때문에 시간지연으로 인해 잊어버릴 염려가 없다.

정보시스템 관리 업무 Workshop 회사에서 관리하는 정보 자원에 대한 관리를 한다. 각 부서에서 정보시스템부에 정보관리 관련 프로젝트 및 응용Program 개발을 요청한다. 정보시스템부에서는 여러 종류의 H/W 및 O/S를 사용하며 관리한다. 또한 여러 종류의 R-DBMS를 사용하고있다. 사용중이거나 개발중인 Database는 여러개의 Table로 구성되어있고 각 Table은 Column들의 집합으로 구성된다. 응용 Program은 Column들의 유형별 집합이며 개발된 응용 Program은 변경관리를한다. 정보시스템부의 응용 Program 관리를 돕기위하여 Table단위당 Column관리, 작성자별 관리, 사용부서별 관리등을 행한다. 중복된 개발을 피하기위하여 Column별 사용 Program, Program별 사용 Column관리를 행한다.