• 모델링의 중요한 요소
  • 데이터 관점 - 업무가 어떤 데이터와 관련이 있는지, 데이터 간의 관계는 무엇인지에 대해서 모델링 하는 방법(What, Data)
  • 프로세스 관점 - 업무를 통해 어떤 일을 처리하는지, 무엇을 해야 하는지를 모델링하는 방법(How, Process)
  • 데이터와 프로세스의 상관 관점 - 업무에서 일을 처리하는 방법에 따라 데이터가 어떻게 영향을 받는지 모델링하는 방법(Interaction)

1.엔티티타입

엔티티 타입의 개념

• 업무에 필요하고 유용한 정보를 저장하고 관리하기 위한 것으로 영속적으로 존재하는 단위
• 엔티티 타입은 엔티티의 집합이라고 할 수 있고, 반대로 엔티티라는 것은 엔티티 타입에 속한 인스턴스 하나에 해당
• 데이터베이스 테이블에 해당되는 데이터 모델리에서 가장 중요한 표기법
  (예: 강사에는 이강삼, 김강사, 박강사가 있는데, 이강사, 김강사, 박강사는 각각 강사라는 엔티티 타입의 엔티티이다.)

• 엔터티 타입의 특징

1. 반드시 시스템을 구축하고자 하는 업무에서 필요하고 관리하고자 하는 정보여야 한다
   예) 환자라는 엔티티타입은 병원에서는 필요하지만 회사에서는 필요하지 않음
2. 유일한 식별자에 의해 식별이 가능해야 한다
3. 영속적으로 존재하는 엔티티의 집합이 되어야 한다
   예) LG CNS라는 회사라는 엔티티타입을 도출하였으나 회사 이름은 "LG CNS"밖에 없으므로 의미가 없음
4. 업무 프로세스(Business Process)는 그 엔티티타입을 반드시 이용해야 한다.
   예) 업무 프로세스에서 전혀 이용되지 않으면 의미 없음
5. 엔티티타입에는 반드시 속성(Attribute)이 포함되어야 한다.
6. 엔티티타입은 다른 엔티티타입과 최소 한 개 이상의 관계가 있어야 한다.
   예) 일반적으로는 관계가 존재 하나, 통계 엔티티타입의 경우는 고립된 경우가 있음

엔티티타입의 분류

• 유무형에 따른 분류(자체의 성격에 따라 분류)
  • 유형(Tangible) 엔티티타입
    물리적인 형태가 이고 안정적이며 지속적으로 활용되는 엔티티타입
    예) 사원, 물품, 강사
  • 개념(Conceptual) 엔티티타입
    물리적인 형태가 없고, 관리해야 할 개념적 정보로 구분되는 엔티티타입
    예) 조직, 상품, 장소
  • 사건(Event) 엔티티타입
    업무를 수행에 따라 발생되는 엔티티타입으로 비교적 발생량이 많으며 각종 통계자료에 이용될 수 있음
    예) 주문, 청구, 미납

• 발생 시점에 따른 분류
  • 기본 엔티티타입
    업무에 원래 존재하는 정보로서 다른 엔티티타입과의 관계에 의해 생성되지 않고 독립적으로 생성되며 자신은 타 엔티티타입의 부모 역할을 한다
  • 중심 엔티티타입
    기본 엔티티타입에서 발생되고 그 업무에서 중심적인 역할을 한다. 데이터 양이 많으며 다른 엔티티타입과의 관계를 통해 많은 행위 엔티티타입을 생성한다.
  • 행위 엔티티타입
    두개 이상의 부모 엔티티타입에서 발생되고 내용이 자주 바뀌거나 데이터양이 증가된다. 분석 초기 단계에서는 잘 나타나지 않으며 상세 설계 단계나 프로세스와 상관 모델링을진행하면서 도출 될 수 있다

엔티티타입의 명명

• 가능하면 현업에서 사용하는 용어를 사용한다
• 가능하면 약어를 사용하지 않는다
• 단수 명사를 사용한다
• 엔티티타입에 부여되는 이름은 유일해야 한다
• 가급적 엔티티타입이 생성되는 의미에 따라 이름을 부여한다

2. 속성

속성의 개념

• 업무에 필요한 엔티티에서 관리하고자 하는, 더 이상 분리되지 않는 최소의 데이터 단위
• 엔티티 타입에는 두 개 이상의 엔티티가 존재하고 각각의엔티티는 고유의 성격을 표현하는 속정 정보를 한 개 또는 그 이상 가진다.
  예) 사원은 이름, 주소, 전화번호, 직책을 가질 수 있는데, 이 사원이라는 엔티티타입에 속한 엔티티의 성격을 구첵적으로 나태나는 항목이 바로 속성이다.
• 엔티티타입 내에 있는 하나의 엔티티는 각각의 속성에 대해 한 개의 속성값만 가질 수 있다.
  예) 사원의 이름은 홍길동이고 주소는 서울시 강남구, 직책은 대리다.
  엔티티 타입 : 사원 /엔티티 : 홍길동이라는 사람 / 속성 : 이름, 주소, 전화번호, 직책 / 속성 값 : 홍길동, 서울시 강남구, 대리

• 엔티티 타입, 엔티티, 속성, 속성 값에 대한 관계
  규칙 1. 한 개의 엔티티타입은 두 개 이상의 엔티티 집합 이어야 한다.
  규칙 2. 한 개의 엔티티는 두 개 이상의 속성을 갖는다.
  규칙 3. 한 개의 속성은 한 개의 속성값을 갖는다.

속성의 분류

• 속성의 특성에 따른 분류
  • 기본 속성(Basic Attribute)
    \-업무로부터 추출한 모든 속성
    \-가장 일반적이고 많은 속성을 차지
    예) 제품이름, 제조년월, 원가
  • 설계 속성(Designed Attribute)
    \-데이터 모델링을 위해 업무를 규칙화하려고 속성을 새로 만들거나 변형하여 정의하는 속성
    예)코드, 일련번호
  • 파생 속성(Derived Attribute)
    \-다른 속성에 영향을 받아 발생하는 속성
    \-다른 속성의 영향을 받기 때문에 프로세스 설계 시 데이터 정합성을 유지하기 위해 유의해야 함
    예) 계산값

• 엔티티 구성방식에 따른 분류
  • 엔티티를 식별할 수 있는 속성인 PK(Primary Key) 속성
  • 다른 엔티티와의 관계에서 포함된 속성 FK(Foreign Key) 속성
  • 엔티티에 포함되어 있고 PK, FK에 포함되지 안흔 속성인 일반 속성

속성의 명명

1. 해당 업무에서 사용하는 이름을 부여한다
2. 서술식 속성명은 사용하지 않는다
3. 약어 사용은 가급적자제한다
4. 엔티티타입에서 유일하게 식별가능 하도록 지정한다

3. 식별자

식별자 개념

• 식별자(Identifier)란 여러 개의 집합체를 담고 있는 하나의 엔티티타입에서 각각의 엔티티를 구분할 수 있는 결정자
• 모든 엔티티타입에는 반드시 하나 이상의 식별자가 있어야 한다

식별자 특징

• 식별자에 의해 엔티티타입 내 모든 엔티티들이 유일하게 구분되어야 함
• 특정 엔티티타입에 식별자가 지정되면 그 식별자는 변하지 않아야 함
• 주식별자의 경우 식별자가 지정되면 주식별자 속성에 반드시 데이터값이 있어야 함

식별자 구분

• 주식별자(Primary Identifier)/보조 식별자(Alternate Identifier) \-자신의 엔티티타입 내에서의 대표성 여부에 따라 구분
  • 주식별자는 엔티티타입의 대표성을 나타내는 유일한 식별자
  • 보조 식별자는 주식별자를 대신하여 보적으로 엔티티를 식별할 수 있는 식별자
  • 둘 다 엔티티를 유일하게 식별할 수 있음
  • 주 식별자는 엔티티타입 하나에 한 개. 보조 식별자는 엔티티타입 하나에 두 개 이상
  • 물리 테이블에서는 주식별자가 PK, 보조 식별자는 Unique Index로 사용
    예) 카드사의 고객 테이블에서 카드번호를 주식별자, 주민등록 번호는 보조 식별자로 활용

• 내부 식별자/외부 식별자(Foreign Identifier) \-엔티티타입 내에서 스스로 생성되었는지 여부에 따라 구분
  • 내부 식별자는 자신의 엔티티타입 내에서 스스로 생성되어 존재하는 식별자임.
  • 외부 식별자는 다른 엔티티타입으로부터 관계에 의해 주식별자 속성을 상속받아 자신의 속성에 포함되는 식별자임
  • 외부 식별자가 주식별자 영역에 포함될 수고 있고, 일반 속성에 포함될 수도 있음
  • 외부 식별자는 물리 테이블에서 FK로 활용

• 단일 식별자(Single Identifier)/복합 식별(Composit Identifier) - 단일 속성 또는 복합 속성이냐에 따라 구분
  • 주식별자의 구성이 한 가지 속성으로만 이루어진 경우 단일 식별자
  • 두 개 이상의 속성으로 구성된 경우는 복합 식별자

• 원조 식별자/대리 식별자(Artificial identified, Surrogate Identifier) - 대체 여부에 따라 구분
  • 주식별자의 속성이 복합 식별자일 경우 여러 개의 속성을 묶어 하나의 속성으로 만들어 주 식별자로 활요하는 경우 대리 식별자 라고 함.

4. 관계

관게의 개념

• 관계란 두 개의 엔티티타입 사이의 논리적인 관계, 즉 엔티티와 엔티티가 존재의 형태나 행위로서 서로에게 영향을 주는 것을 말함.
• 데이터 모델에서의 관계란 업무의 흐름을 나타냄

관계 패어링

• 관계 패어링이란 각각의 엔티티들이 자신이 관련된 엔티티들과 관계의 어커런스로 참여하는 형태
• 엔티티와 엔티티 사이에 관계가 설정되어 있는 어커런스가 관게 패어링 임

관계의 명명

• 각각의 관계에는 두 개의 멤버십(Membership)이 있다.
• 각각의 멤버십에 의해 두 가지 관점으로 표현될 수 있다.
• 멤버십은 엔티티타입이관계에 참여하는 것을 말한다.

• 명명 규칙
  • 애매한 동사를 피하라
  • 현재형으로 표현하라

관계의 카디낼리티

• 두 개의 엔티티타입간 관계에서 참여자의 수를 표현하는 것을 카디낼리티(Cardinality)라고 함
• 가장 일반적인 표현방법은 1:M, 1:1, M:N이다.
• 가장 중요하게 고려해야 할 사항은 한 개의 멤버십이 존재하느냐 아니면 두 개 이상의 멤버십이 존재하느냐를 파악하는 것이다

• 1:1(One To One) 관계룰 표시하는 방법
  관계에 참여하는 각각의 엔티티는 관계를 맺는 다른 엔티티에 대해 단지 하나의 관계만을 가지고 있다.

<한 개의 구매신청서에 대해 한 개의 구매주문을 신청하고 한 개의 구매 주문에는 한 개의 구매 신청 내용을 작성한다>

• 1:M(One To Many) 관계를 표시하는 방법
  관계에 참여하는 각각의 엔티티는 관계를 맺는 다른 엔티티타입의 엔티티에 대해 하나 잇ㅇ의 수와 관계를 가진다. 그러나 반대 방향은 단지 하나의 관계만 가진다.

<한 명의 사원은 한 부서에 소속되고 한 부서에는 여러 사원을 포함한다>

• M:N(Many To maNy) 관계를 표시하는 방법
  관계에 참여하는 각각의 엔티티에는 관계를 맺는 다른 엔티티타입의 엔티티에 대해 하나 이상의 수와 관계가 있다.
  반대 방향도 동일하게 관계에 참여하는 각각의 엔티티에는 관계를 맺는 다른 엔티티타입의 엔티티에 대해 하나 이상의 수와 관계가 있다.

<하나의 주문에는 여러 개의 제품을 포함할 수 있고, 한 제품은 여러 개의 주문서를 통해 신청 될 수 있다>

관계를 읽는 방법

관계 모델을 읽는 방법은 먼저 읽는 엔티티타입의 참여도를 읽고 그 다음 엔티티타입을 읽고 관계명을 읽는다.

관계에 참여하는 방법

• 필수 참여는 참여하는 모든 참여자가 반드시 타 엔티티타입의 참여자와 연결되어야 하는 관계
• 선택 참여는 참여하는 모든 참여자가 반드시 타 엔티티타입의 참여자와 연결되지 않아도 되는 관계
  예) 주문서에는 반드시 주문목록이 있어야 하며, 주문목록에는 주문받은 목록도 있고, 주문받지 않는 목록이 있을수도 있으므로 목록과 주문목록과의 관계는 선택 참여가 된다.

<하나의 주문목록에는 한 개의 목록을 항상 포함하고 한 목록은 여러 개의 주문모록에 의해 포함될 수 있다>

관계의 종류

• 정상 관계(Normal Relationship)
  엔티티타입과 엔티티타입이 독립적으로 분리되어 있으면서 상호간에 한 가지 관계만 성립하는 형태

• 자기 참조 관계(Self Relationship, Recursive Relationship)
  하나의 엔티티타입내에서 엔티티와 엔티티가 관계를 맺고 있는 형태.
  예) 부서, 부품, 메뉴등 계층 구조 형태를 표현할 대 유용

• 병렬관계(Parallel Relationship)
  엔티티타입과 엔티티타입이 독립적으로 분리되어 있으면서 두 개 이상의 관계가 상호간에 존재하는 형태의 관계

• 슈퍼타입과 서브타입 관계(Super-Type Sub-Type Relationship)
  • 공통 속성을 가지는 슈퍼타입과 공통 부분을 제외하고, 두 개 이상의 엔티티타입간의 속성에 차이가 있을 때 별도의 서브타입으로 존재 할 수 있음
  • 이때 슈퍼타입과 서브타입의 관계 형식은 1:1이다.
  • 이때, 서브타입을 구분하는 형식에 따라, 슈퍼타입의 특정 엔티티가 반드시 하나의 서비스타입에만 속해야 하는 배타적 관계(Exclusive Relationship)와 슈퍼타입의 특정 엔티티가 두 개 이상의 서브타입에 포함될 수 있는 포함관계(Inclusive Relationship)로 구분할 수 있음
    
  • 왼쪽 모델은 배타적 관계의 표현으로, 직원은 반드시 일반 직원이나 촉탁 지원 중 하나에만 속할 수 있음
  • 오른쪽 모델은 포함 관계를 표현한 것으로 접수할 때 인터넷 접수를 한 사람이 다시 방문하여 방문 접수할 수 있는 경우를 표현

• 주식별자/비식별자 관계(Identifying/Non-Identifying Relationship)
  • 주식별자 관계 : 부모 엔티티타입의 주식별자가 자식 엔티티타입의 주식별자로 상속
  • 비식별자 관계 : 부모 엔티티타입의 주식별자가 자식 엔티티타입의 일반속성으로 상속되는 비식별자 관계

5. 엔티티 슈퍼타입과 서브타입

엔티티 슈퍼타입과 서브 타입의 개념

• 여러 개의 엔티티타입이 비슷하고 일부의 속성이나 관계만 다를 경우 여러 개의 엔티티타입을 한 개의 엔티티타입으로 묶어 통합하고, 하나의 엔티티타입 안에 다른 엔티티타입의 모습을 서브 타입으로 나누어 표시하는 경우가 있다.
• 이를 엔티티타입이 통합되었다라고 한다.
• 통합하여 표시하는 엔티티타입을 슈퍼타입이라 하고, 슈퍼타입 안에 포함되어 표시된 비슷한 성격의 엔티티타입을 서브타입이라 한다.
  예) 방문 접수, 전화 접수 인터넷 접수의 경우 접수라는 부분은 동일한 성격을 가지고, 접수 방법만 다름.
  이럴 경우 접수라는 슈퍼 타입이 생성되고 슈퍼 타입에 따른 방문 접수, 전화 접수, 인터넷 접수라는 세 개의 서브타입이 슈퍼타입 안에 묶인다.
  
  예) 직원이라는 엔티티타입의 경우 정규 직원과 촉탁 직원의 성격이 다르고 관계도 다름 직원이라는 엔티티타입에서 정규 직원과 촉탁 직원이라는 서브 엔티티타입이 생성됨
  
  • 분석된 한 개의 엔티티타입에서 기능별로 여러 개의 엔티티 서브타입으로 분화하는 과정을 엔티티타입 세분화 라고 함
  • 여러 개의 비슷한 엔티티타입이 한 개의 엔티티타입으로 묶이는 과정을 엔티티타입 통합이라 함

엔티티 슈퍼타입과 서브타입의 표시방법

• 슈퍼타입과 서브타입으로 나뉘는 구분이 반드시 존재해야 함

엔티티 슈퍼타입과 서브 타입을 표시하기 위한 특징

• 서브타입간의 관계가 서로 Exclusive인지 Inclusive인지 결정해야 한다. 대부분 배타적인 관계지만 촉탁 직원이면서 시간 직원으로 등록하여 별도로 일할 수 있다고 하면 Incclusive 관계로 구분
• 각각의 서브타입은 정확하게 하나의 슈퍼타입에만 속해야 한다.
• 슈퍼타입과 서브타입 사이에는 서브타입을 구분할 수 있는 구분자가 반드시 있어야 하고, 구분자의 위치는 슈퍼타입의 속성으로 포함된다.
• 서브타입에 있는 엔티티의 어커런스는 구분자에 의해 식별 가능해야 한다.
• 서브타입에 대한 서브타입을 지정할 수 있지만 모델의 복잡성이 증가하므로 될 수 있으면 서브타입의 수준을 1로 유지하도록 한다.
• 만약 서브타입으로 분리된 하나의 엔티티타입이 있는데 이 서브타입이 슈퍼타입의 엔티티타입에 대한 모든 엔티티들이 포함된다면 서브타입을 더 세분화할 필요가 있음
  예) 직원이라는 슈퍼타입과 일반 직원이라는 서브타입만 존재한다면 아직 서브타입이 덜 분석되었다는 이야기다. 일반직원 안에 촉탁직원이 포함되어 있고, 시간 직원이 포함되어 있기 때문에 더 세분화 하여 서브타입을 분리해야 한다.

6. 서브젝트 에어리어

• 서브젝트 에어리어란 해당 업무 내에서 연관이 ㅇ많은 엔티티타입을 그룹으로 묶어 표시하는 개념
• 데이터 모델링 작업을 쉽게 할 뿐만 아니라 프로세스도 구분되어 효율적인 개발 시스템을 작성하도록 돕는 역할을 한다
• 시스템의 복잡도를 감소시키고 개발 범위를 분담하며, 모델의 Readability를 위해 업무 단위별로 구분하여 표현

서브젝트 에어리어 구분

• 시스템을 분석하기 이전부터 업무별로 영역을 지정하는 경우가 많음. 잘못 지정된 업무 구분은 모델에도 치명적인 결함을 줄 수 있음
  예) 교육시스템을 구축하는 프로젝트의 경우 언어분야(수강생, 수강신청, 과목, 강사, 강의실)와 모델링 분야(수강생, 수강신청, 과목, 강사, 강의실),
  방법론(수강생, 수강신청, 과목, 강사, 강의실) 분야로 나눌 경우 똑같은 엔티티들이 각 오브젝트 다 표현되야 될 경우도 있음
• 데이터 모델과 프로세스 모델 관점에서 본 서브젝트 에어리어는 시간의 진행에 따른 수직적인 분할이 적절
  예) 교육시스템을 구축하는 프로젝트의 경우 수강신청(수강생, 수강신청, 과목)/강의(강사, 강의실, 강의, 과목)라는 서브젝트 에어리어라 분리하면, 시간에 따라 서브젝트 에어리어가 지정되어 있으므로 프로젝트 전체를 훨씬 단순하고 구조적으로 만들며, 서브시스템별 범위

• 이률적으로 시간에 따라 수직적으로 분할을 권장하는 것이 아니라 반드시 업무간 상관 관계와 업무로 인해 발생되는 결과물들이 검증된 이후에 결정되어야 함

서브젝트 에어리어 명명법

• 업무에서 가장 많이 사용되는 요어를 쓰는 것이 가장 좋다

7. 정규화

• 정규화(Normalization)란 다양한 유형의 검사를 통해 데이터 모델을 좀 더 구조화 하고 개선시켜 나가는 절차에 관련된 이론이다.
• 정규화의 기본 원칙은 하나의 테이블에는 중복된 데이터가 없도록 하는 것임
• 정규화의 특징
  • 정규화는 적절한 엔티티타입에 각각의 속성들을 배치하고 엔티티타입을 충분히 도출해 가는 단계적인 분석 방법이다.
  • 정규화 기술은 엔티티타입에 속성들이 상호 종속적인 관계를 갖는 것을 배경으로 종속 관계를 이용하여 엔티티타입을 정제하는 방법이다.
  • 각각의 속성들이 데이터 모델에 포함될 수 있는 정규화의 원리를 이용하여 데이터를 분서하는 방법에서 활용 될 수 있다.
  • 정규화는 현재 데이터를 검증할 수 있고 데이터의 표현 관점에서 엔티티타입을 정의하는 데 이용할 수 있다.
  • 정규화는 엔티티타입을 오브젝트별로 분석하는 방법이 아닌 개별 데이터를 이요한 수학적인 접근 방법을 통해 분석한다.

오브젝트 분석과 정규화 작업에 의한 엔티티타입 도출 방법 비교

함수의 종속성

• 함수의 종속성(FUNCTIONAL DEPENDENCY)은 데이터들이 어떤 기준값에 의해 종속되는 현상을 지칭하는 것
• 이때 기준값을 결정자(DETERMINANT)라 하고 종속되는 값을 종속자(DEPENDENT)라고 한다.
  예) 주민등록번호 \-> (이름, 출생지, 호주) : 주민등록번호가 출생지, 호주를 함수적으로 결정한다라고 말 할 수 있다.

• 함수의 족송성을 이용하여 정규화 작업이나 각 오브젝트에 속성을 배치하는 작업에 이용하는 것
• 정규화의 궁금적인 목적은 반복적인 데이터를 분리하고 각 데이터가 종속된 테이블에 적절하게(프로세스에 의해 데이터 정합성이 지켜질 수 있어야 함) 배치 되도록 하는 것이다.

정규화에 대한 설명 및 예제

• 하나의 제품에 대해 여러 개의 주문서가 접수된 내용을보여주는 초기 데이터 이다.
  

• 이와 깉이 데이터의 내용이 반복되는 속성으로 인해 일부 속성이 중복(Redundancy)된다면 입력, 수정, 삭제의 경우에 데이터를 제대로 관리할 수 없다.

1차 정규화(복수의 속성값을 갖는 속성의 분리)

• 모든 엔티티타입에는 하나의 속성만을 가지고 있어야 하며 반복되는 속성의 집단은 별도의 엔티티타입으로 분리한다
  

• 1차 정규화를 수행하였지만 여전히 데이터를 조작하는데 문제가 발생할 수 있다.
• 입력 이상
  • 새로운 주문이 접수되면 반드시 제품번호를 입력한 이후에 주문을 등록할 수 있다.
  • 주문에 대한 기본적인 정보들을 입력한 이후에 제품번호를 입력하는 경우라면 입력 당시에 제품 번호가 존재하지 않아 입력 작업이 불가능 하다
• 수정 이상
  • 주문번호 AB345에 대한 우선순위를 1에서 10으로 수정하려면 제품번호 1001, 1007 두개에 해당하는 AB345를 수정해야 한다. 한번 수행할 작업을 여러 번 수행하므로 수정 작업 성능 저하 뿐만 아니라 수정작업 중 에러가 발생하거나 로직에 의해 버그가 존재할 경우 데이터 일관성(Data Consistency)이 무너진다.
• 삭제 이상
  • 주문한 제품정보가 삭제될 경우 주문에 관련된 정보도 삭제 된다.

• 1차 정규화를 정상적으로 진행하여도 각각의 속성이 자신의 테이블에 있는 식별자에 완전히 종속적이지 않는 경우 문제가 발생하므로 2차 정규화를 진행한다.

2차 정규화(주식별자에 종속적이지 않은 속성 분리)

• 2차 정규화를 진행하여도 주식별자를 구성하는 속성과 관계없이 속성간의 종속 관계 때문에 문제가 발생할 수 있다.
• 입력이상
  • 주문에 새로운 고객을 등록하려고 하지만, 만약 고객이 주문하지 않는다면 이 고객을 등록 할 수 없다.
• 수정 이상
  • 한 고객이 여러 번 주문한 경우 고객 정보가 반복적으로 테이블에 발생되므로 고객정보를 변경할 때 문제가 발생 할 수 있다.
• 삭제 이상
  • 고객번호 4520이 주문을 취소하였다면 주문에 관련된 정보만 삭제되는 것이 아니라 고객 정보도 모두 삭제 된다.

• 2차 정규화를 정상적으로 진행하여도 각 테이블에 있는 속성들이 별도의 종속적인 관계를 가지고 있는 경우에 3차 정규화를 진행한다.

3차 정규화(속성에 종속적인 속성 분리)

보이스-코드 정규화

• 1,2,3차 정규화는 모두 하나의 주식별자를 가졌을때를 가정하여 진행한다. 만약 하나의 테이블에 여러 개의 식별자가 존재하면 비록 1차~3차 정규형을 모두 만족하더라도 데이터를 조작하는데 문제가 발생할 수 있다.
• 복잡한 식별자 관계의해 발생하는 문제를 해결하기 위해 3차 정규화를 보완한 보이스-코드 정규화(Boyce-Code Normalization)를 진행한다.
• 보이스-코드 정규화란 테이블에 존재하는 식별자가 여러 개 존재할 경우 식별자가 중복되어 나타나는 현상을 제거하기 위한 것이다.

\*3차 정규형을 만족하지만, 다음과 같은 문제가 있다.

• 입력 이상
  • 만약 새로운 사반(주)에서 새로운 제품을 납품하면 납품업체코드 01과 납품회사명 사반(주)가 모두 입력된다. 두 개의 유일한 데이터를 동시에 여러 오루에 입력해야 하므로 중복 입력이 발생할 뿐만 아니라 트랜잭션 제어가 되지 않을 경우에는 데이터일관성이 무너질 수 있다.
• 수정 이상
  • 만약 납품회사명을 수정하려 하면 데이터가 중복되어 존재하므로 여러 개의 로우에 해당하는 데이터를 수정해야 한다. 데이터에 대한 일관성(Data Consistency)이 무너지는 경우가 발생할 수 있다.
• 삭제 이상
  • 제품 코드가 B001이고 납품 업체 코드가 03인 납품정보를 삭제 하면 시그마(주)라는 납품 업체 정보도 사라진다.

4차 정규화(특정 속성값에 따라 선택적인 속성의 분리)

• 하나의 테이블에 두 개 이상의 독립적인 다가 속성(Multi-Valued Attribute)이 존재하는 경우 다가 종속(Multi-Valued Dependency)이 발생되어 문제가 발생한다.
• 아래 모델에서 사원은 보유하는 기술이 있다는 사실을 관리하고 보유한 기술은 지원한 프로젝트와는 아무런 상관이 없다는 것\을 전제로 한다.

• 업무규칙은 다음과 같다.
  • 한 명의 사원은 여러 개의 프로젝트를 지원할 수 있다.
  • 한 프로젝트는 여러 명의 사원으로부터 지원될 수 있다.
  • 한 명의 사원은 여러 개의 기술을 보유할 수 있다.
  • 하나의 기술 형식은 여러 명의 사원이 보유할 수 있다.

• 입력 이상
  • 만약 10이라는 사원번호를 가진 직원이 JA라는 새로운 프로젝트를 경험하게 되어 데이터를 입력하려면 프로젝트와 상관없는 기술코드를 입력해야 한다.
• 수정 이상
  • 만약 직원이 경험한 프로젝트 코드가 PA에서 BB로 변경되어야 한다면 보유하고 있는 기술 수만큼 반복적으로 수정되어야 한다.
• 삭제 이상
  • 만약 직원이 보유한 기술을 삭제하면 경험한 프로젝트까지 모두 삭제되어 데이터가 남지 않게 된다.

• 비슷한 유형의 모델이 존재한다면 다음과 같이 업무 규칙만 조금 변경하여 살펴보자.
• 아래의 모델은 모델에서 사원은 지원하는 기술이 있다는 사실을 관리하고 지원한 기술은 지원한 프로젝트와는관련이있다는것을 전제로 한다.

• 모델의 업무 규칙은 다음과 같다.
  • 한 명의 사원은 여러 개의 프로젝트를 지원할 수 있다.
  • 한 프로젝트는 여러 명의 사원으로부터 지원될 수 있다.
  • 한 명의 사원은 여러 개의 기술 지원할 수 있다.
  • 하나의 기술은 여러 사원에 의해 활용될 수 있다.
  • 하나의 프로젝트는 여러 개의 기술로 지원될 수 있다.
  • 하나의 기술은 여러 개의 프로젝트를 지원할 수 있다.

• {*}기술과 프로젝트 엔티티타입에 사이에는 관계가 존재한다는 것{*} 이다.

• 지원 프로젝트에 대한 지원 기술을 찾을 수 없다. 사원 엔티티타입으로부터 관계를 양쪽으로 주는 모습이므로 지원 기술과 지원 프로젝트는 서로 같이 존재 하지 않는경우 이다.

8. ERD 표기법

• ERD는 각각 업무 분석에서 도출된 엔티티타입과 엔티티타입 간의관계를 이해 쉽게 그림으로 표시하는 방법

ERD를 작성하는 순서

1. 엔티티타입을 그린다
2. 엔티티타입을 적절하게 배치한다
3. 엔티티타입간 관계를 설정한다
4. 관계명을 기술한다
5. 관계의 참여도를 기술한다
6. 관계의 필수여부를 기술한다

ERD에서 엔티티타입의 매치 방법

• 업무를 진행하는 순서에 따라 엔티티타입을 왼쪽 편부터 오른쪽으로 위에서 아래로 표시한다.
• 업무 흐름에 중신이 되는 엔티티타입, 보통 업무 흐름에 있어 주잇ㅁ이 되는 엔티티타입은 타 엔티티타입과 많은 관계를 가지고 있으므로 중앙에 배치한다
• 업무를 진행하는 중심 엔티티타입과 관계를 갖는 엔티티타입들은 중심에 배치된 엔티티타입을 주위에 배치하도록 한다

ERD관계의 연결

• 초기에는 PRIMARY KEY로 속성이 상속되는 주식별자 관계를 설정한다 중복되는 관계가 발생되지 않도록 하고 순환 관계도 발생하지 않도록 유의한다.

ERD관계명의 표시

• 관계 설정이 완료되면 연결된 관계에 관계명을 부여한다.
  

ERD 관계카디낼리티와 선택성 표시

• 엔티티타입 간에 엔티티들이 얼마나 관계에 참여하는지 나타내는 카디낼리티를 표현한다.