ER-모델링

I. 엔티티타입 개념

가. 엔티티타입 정의

엔티티타입	공통적인 정의(속성)를 가지는 모든 엔티티의 집합 -업무에서 관리하고자 하는 데이터의 한 형태(예: 사람, 사물, 장소, 사건 등) -데이터베이스에서 테이블(Table)로 구현
엔티티(Entity)	엔티티타입의 개별 발생건(Occurrence or Instance)

나. 엔티티타입의 분류

일반적인 분류	실체(Tangible) 엔티티타입	– 물리적인 형태가 있는 엔티티타입 – 안정적이며, 지속적으로 활용되고 공유의 대상인 경우가 많음 예 : 직원, 제품, 고객 등
	개념(Conceptual) 엔티티타입	– 물리적인 형태는 없으나 관리의 필요에 의해 사용되는 엔티티타입 예 : 조직, 계정, 상품, 장소 등
	사건(Event) 엔티티타입	– 업무를 수행하는 행위와 관련된 엔티티타입 예 : 발송, 주문, 구매, 계약, 청구 등
모델관점의 분류	중심(Central) 엔티티타입	– 단위주제영역 내에서 가장 핵심이 되는 (대표성) 엔티티타입 – 예 : 고객, 주문, 제품
	독립(Independent) 엔티티타입	– 다른 엔티티타입의 존재와는 독립적으로 존재가 가능한 엔티티타입 – 일반적으로 중심엔티티타입이며, 공유의 대상이 되는 경우 – 예 : 고객, 제품
	의존(Dependent) 엔티티타입	– 다른 엔티티타입의 존재가 선행되어야 존재가 가능한 엔티티타입 – 예: 고객주소, 주문, 주문항목
	특성(Characteristic) 엔티티타입	– 특정 엔티티타입의 특징을 상세히 설명해주는 엔티티타입 – 특징을 가지는 엔티티타입(고객)과 동일한 주제영역 내에 존재 – 예 : 고객주소
	연관(Associative) 엔티티타입	– 두개이상의 엔티티타입에 의존적인 엔티티타입 – 다대다(M:N)의 관계를 해결하면서 나타나는 엔티티타입 – 예: 주문항목

다. 엔티티타입의 통합

- 비슷한 유형의 엔티티타입들을 하나 혹은 다수의 엔티티타입으로 그룹핑하는것

1). 엔티티타입의 통합의 대상

- 엔티티타입의 구조가 비슷하여 통합 후에도 복잡성이 증가하지 않는 경우

- 통합한 정보의 조회 및 분석이 빈번한 경우(예:금융기관의 계좌 혹은 상품 등의 통합)

- 동일한 유형의 엔티티타입의 추가가 빈번하리라고 예상되는 경우

2). 엔티티타입의 방법

일반화(Generalization	– 유사한 속성 및 도메인으로 인하여 서로 다른 엔티티타입들을 하나로 통합 – 데이터구조의 유연성 확보
전문화(Specialization)	- 일반화의 반대개념

3). 엔티티타입의 통합의 장단점

장점	- 종합적인 정보의 도출 및 분석이 용이 : 통합된 엔티티타입에 동일한 모습으로 관리 가능 - 프로세스 및 화면의 통합이 가능 : 중복개발의 배제, 효율적인 전산개발 및 유지보수 용이 - 엔티티타입 및 관계간의 복잡성 제거 : 다수의 엔티티타입 및 관계가 통합된 형태로 나타남
단점	- 엔티티타입 및 프로세스의 복잡성 증가 : 속성이 많아지고 프로세스가 복잡해짐 - 유지보수의 복잡성 증가: 특정 부분의 변경이 필요한 경우 정보구조의 변경이 어려움 - 시스템의 성능 저하 가능성 : 방대한 건수의 발생시, 데이터 저장공간의 낭비 가능성

4). 엔티티타입의 통합 - 고려사항

-  확실한 목표를 설정하여 수행 : 통합의 효과를 기대할 수 있는 엔티티타입의 통합 고려

-  점진적인 통합을 고려 : 핵심적인 부분들의 우선 통합을 추진

II. 관계(Relationship)

가. 관계 정의(Definition)

특징	표현
엔티티타입 간에 관련이 생기게 되는 업무적 이유 Foreign Key로 구현되어 참조무결성으로 데이터의 정합성 유지

나. 페어링(Pairing)과 관계(Relationship)

- 관계: 두개의 엔티티타입간의 연관성

- 페어링: 관계의 개별 발생 건(Instance)

다. 관계 멤버쉽(Membership)

- 관계를 양쪽 방향에서 각각 바라본 관점

라. 관계멤버쉽의 표현요소

카디낼리티(Cardinality)	선택성(Optionality)
– 의미: 하나의 엔티티가 가질 수 있는 페어링의 수 – 유형: 일대일(1:1), 일대다(1:M), 다대다(M:N)	– 의미: 페어링의 존재여부 – 유형: 필수적(Mandatory), 선택적(Optional)

마. 카디낼리티(Cardinality)의 유형

일대일 (1:1)
일대다 (1:M)
다대다 (M:N)

바.선택성(Optionality)의 유형

양방향 필수(Fully Mandatory)
단방향 선택(Partly Optional)
양방향 선택(Fully Optional)

카디낼리티/선택성 결합

-각 고객은 <때때로> <하나이상의> 주문을 발주한다

-각 주문은 <항상> <하나의> 고객에 의해 발주된다

사. 다대다(M:N)의 해결 – 관계에 숨어있는 추가적인 숨은 정보(속성)를 파악 – 엔티티타입을 추가하여 다대다(M:N)의 관계를 일대다(1:M)로 해결 :추가된 엔티티타입에 일대다(1:M)의 관계 (선택성 상속) 반영 III. 외부키(Foreign Key) 가. 관계(Relationship)의 물리적 구현 – 상위(Parent) 엔티티타입의 식별자가 하위(Child) 엔티티타입의 속성으로 구현 나. 참조 무결성(RI) 1).생성(Insert) RI - 하위 엔티티가 새로 생성될때 하위 엔티티가 가지고 있는 외부키(Foreign Key)의 입력값에 대한 정합성을 유지해 주는 기능 – 직원 엔티티 생성시, 입력되는 부서코드가 부서 엔티티 중의 하나인지를 확인 2). 수정(Update) RI - 상위 엔티티의 Primary Key값이 변경되었을 경우, 페어링을 맺고있는 하위 엔티티의 모든 외부키값을 자동으로 변경해 주는 기능 – 연쇄적인 수정(Update) RI 발생 – Primary Key 값의 변경을 방지함으로써 정합성 유지(즉,부서코드 변경방지:삭제 및 입력으로 보완) 3). 삭제(Delete) RI - 엔티티가 삭제되는 경우, 해당 엔티티 및 페어링으로 연결된 다른 엔티티의 삭제를 처리해주는 기능 - 상위(Parent) 엔티티를 삭제하려는 경우 : 페어링으로 연결된 하위(Child) 엔티티 삭제처리 여부 - 하위(Child) 엔티티를 삭제하려는 경우 :  페어링으로 연결된 상위(Parent) 엔티티  삭제여부 상위 엔티티 삭제 Cascade Delete 페어링으로 연결된 모든 하위 엔티티도 함께 삭제 Nullify Delete 모든 하위 엔티티의 외부키 값을 NULL로 정의 Restricted Delete 하위 엔티티가 존재하지 않는 경우에만 상위 엔티티 삭제 하위 엔티티 삭제 Pendent Delete 마지막 하위 엔티티의 삭제시, 페어링으로 연결된 상위 엔티티도 함께 삭제 Disassociate 상위 엔티티와 관계없이 하위 엔티티의 삭제 허용 Restricted Delete 페어링으로 연결된 상위 엔티티가 존재하면 하위 엔티티의 삭제를 불허 다. 관계(Relationship) 의 장단점 장점 – 정보의 중복 최소화 – 정보의 정합성을 자동으로 유지 단점 – 정보처리 시간의 지연 : 인덱스 관리를 위한 처리 – 데이터베이스 관리의 복잡성 : :백업 및 복구시의 제약, 부분적 변경시의 제약