데이터 모델링

모델링이 업인데... 막상 이론은 아무리 공부해놔도 시간이 지나면 흐릿해 진다.
현업에서 모델링할 때 이런 이론은 몸에 배어 있달까? 거의 감각적으로 처리하긴 하는데...

세미나를 준비한다던가... 인터뷰를 준비할 때는 말로 표현할 수 있어야 하다보니...
상대적으로 정확한 용어가 필요해지곤 한다.

매번 책 찾아보기도 귀찮고 이 참에 한번 정리해 봤다.

1. 모델링이란? 
   1. 업무의 내용과 정보 시스템의 모습을 적절한 표기법으로 표현하는 것을 말한다.
      
   2. 목적
      1. 업무 내용의 정확한 분석
      2. 실제 데이터 베이스를 생성하여 개발하고 데이터를 관리
         
   3. 주요 요소
      1. 데이터 모델링
      2. 프로세스 모델링
      3. 데이터-프로세스 상관 모델링
         
         
2. 주요 개념
   1. Entity Type (= Entity Set)
      업무에 필요하고 유용한 정보를 저장하고 관리하기 위한 것으로 영속적으로 존재하는 단위
      
      1. Entity Type은 Entity의 집합 or Entity는 Entity Type의 instance
         예) [과목] Entity Type은 [국어], [영어], [수학] Entity의 집합이다. or [국어], [영어], [수학]은 [과목] Entity Type의 Entity이다.
         cf) ERD(Entity Relationship Diagram)는 Entity간 realationship을 나타낸 diagram으로 정의될 수 있으나, 여기서의 Entity는 Entity Type을 의미한다.
         
      2. Entity Type의 조건
         1. 업무에서 필요하고 관리하고자 하는 정보여야 한다.
         2. Identifier(identifier)에 의해 각각의 Entity Type이 유일하게 식별되어야 한다.
         3. 영속적으로 존재하는 2개이상의 Entity 집합이어야 한다. 즉, 1개이 Entity만을 가진 Entity Type은 의미가 없다.
         4. Business Process에서 반드시 이용되어야 한다.
         5. Attribute가 있어야 한다.
         6. Entity Type간의 relationship이 존재해야 한다. (단, 코드나 통계와 같은 경우 고립된 Entity Type을 허용한다.)
            
      3. Entity Type의 분류
         1. 유/무형에 따른 분류
            1. Tangible Entity Type : 물리적인 형태가 존재 (사원, 물품, 강사)
            2. Conceptual Entity Type : 관리해야할 개념적 정보 (부서, 장소)
            3. Event Entity Type : 업무 수행에 따라 발생하는 정보. 일반적으로 발생량이 많고 각종 통계에 이용 (주문, 청구, 미납)
               
         2. 발생시점에 따른 분류
            1. Fundamental Entity Type
               다른 Entity Type간의 relationship에 의해 생성되지 않고 독립적으로 존재하는 Entity Type으로, 주로 타 Entity Type의 parent가 된다. 예) 사원, 부서
            2. Main Entity Type
               Fundamental Entity Type에서 발생하며 업무에서 중심적인 역할을 한다. 예) 접수, 계약
            3. Activity Entity Type
               둘 이상의 Entity Type에서 발생한다. 예) 주문내역
               
      4. Entity Type의 명명
         1. 업무에서 사용하는 용어
         2. 약어 사용을 피한다.
         3. 단수 명사
         4. 중복되지 않는 유일한 이름
         5. 가급적 생성되는 의미에 따라 명명
            Main Entity Type과 Activity Entity Type의 이름을 지을 때 특히 중요한 기준
            예) 고객이 제품을 주문하는 경우, 고객 Entity Type과 제품 Entity Type 사이에 Intersection Entity Type형태의 Activity Entity Type을 생성하게 되는데
            이름 후보로는 [고객제품], [주문] 등이 가능하다.
            이 경우 [고객제품]은 "고객이 주문한 제품"외에 "고객의 제품"과 같은 해석이 가능하여 혼돈의 여지가 있으므로 [주문]이 적절하다.
            
   2. Attribute
      Entity를 구성하는 더 이상 분리되지 않는 최소의 데이터 단위
      
      1. Attribute의 분류
         1. Basic Attribute : 업무로부터 추출한 가장 일반적인 속성
         2. Designed Attribute : 코드, 일련번호와 같은 업무의 규칙화를 위해 설계된 속성
         3. Derived Atrribute : 계산된 속성과 같이 다른 속성에서 파생되는 속성
            
      2. Attribute의 명명
         1. 업무에서 사용하는 용어 사용
         2. 서술식 또는 소유격의 속성명은 사용하지 않는다.
         3. 약어 사용을 피한다.
         4. Entity Type에서 유일한 이름이라야 한다.
            가급적 모든 Attribute의 이름을 유일하게 작성한다.
            
   3. Identifier
      Entity Type에서 각각의 Entity를 구분할 수 있는 결정자이며, 모든 Entity Type에는 하나 이상의 Identifier가 있어야 한다.
      
      1. 구분
         1. Primary Identifier vs. Alternative Identifier
         2. Internal Identifier vs. Foreign Identifer
         3. Single Identifier vs. Composite Identifer
         4. Original Identifer vs. Artificial Identifer (= Surrogate Identifier)
            
   4. Relationship
      두개의 Entity Type이 존재 또는 행위로 서로에게 영향을 주는 것
      "부서 - 사원" : 존재에 의한 관계
      "고객 - 주문" : 행위에 의한 관계
      
      1. Relationship pairing
         1. Entity간의 관계 (영업부 - 홍길동, 영업부 - 일지매)
            
      2. Relationship의 종류
         1. Normal Relationship
         2. Recursive Relationship
         3. Parallel Relationship
         4. Super-Type Sub-Type Relationship
         5. Identifying Relationship / Non-Identifying Realtionship
            
      3. Cardinality
         1. Entity Type간 Relationship에서 참여자의 수를 표현한 것
         2. 1 : M
         3. 1 : 1
         4. M : N
            
      4. Relationship에 대한 Membership
         1. Mandatory Membership
         2. Optional Membership
            
      5. Relationship의 명명
         1. 두개의 Entity Type을 각각 시작점과 끝점으로 하는 두개의 Relationship 이름이 필요
         2. 애매한 동사를 피한다. (관계되다, 관련이 있다, 이다, 한다 등)
         3. 현재형을 사용한다.
            
      6. Relationship을 읽는 방법
         1. 일반적인 부서 - 사원 관계의 경우
            1. 하나의 부서는 여러 사원을 포함한다.
            2. 한명의 사원은 하나의 부서에 소속된다.
               
               
3. 정규화
   반복적인 데이터를 분리하고 각 데이터를 종속 테이블에 적절히 배치하는 것
   
   1. 1차 정규화
      복수의 속성 값을 갖는 속성을 분리한다.
      
   2. 2차 정규화
      Primary Identifier에 종속적이지 않거나 부분적으로 종속적인 속성을 분리한다.
      
   3. 3차 정규화
      속성에 종속적인 속성을 분리한다.
      
   4. 보이스-코드 정규화
      Composite Identifier의 경우 Identifer에서 발생하는 중복을 분리한다.
      
   5. 4차 정규화
      하나의 Entity Type에 복수의 독립적인 다가 속성을 가지고 있는 경우 이를 분리한다.
      예) 사원-기술-프로젝트 => 사원-기술, 사원-프로젝트 (기술과 프로젝트는 서로 독립적임)
      
   6. 5차 정규화
      
      
4. 반정규화
   정규화된 엔티티 타입, 속성, 관계에 대해 시스템의 성능향상과 개발(development)과 운영(maintenance)의 단순화를 위해 데이터모델을 조정하는 프로세스
   
   1. 1차 정규화에 대한 반정규화
      최대 발생 값이 고정되어 있는 경우 동일 속성에 대해 복수의 속성값을 인정한다.
       예) 업체의 연락처를 최대 2개까지 저장한다는 규칙이 있을 때 업체 Entity Type에 연락처 속성을 2개로 한다.
      
   2. 2차 정규화에 대한 반정규화
      1:M관계에 있는 두 Entity Type을 하나의 Entity Type으로 통합하고 각 Entity Type의 Primary Identifer로 만든다.
      
   3. 3차 정규화에 대한 반정규화
      1:1관계에 있는 두 Entity Type을 하나의 Entity Type으로 통합하고 Primary Identifier 중 하나를 일반 속성으로 만든다.
       예) 접수, 접수확인을 하나의 Entity Type으로 통합
      
   4. Relationship의 반정규화
      Join하는 Entity Type의 수를 줄이기 위해 간접적인 Relationship관계의 두 Entity Type간에 직접적인 Relationship을 추가한다.
      예) 고객 - 주문 - 주문목록 - 배송의 관계가 있다고 할때, 특정 배송 건에 대한 고객 정보를 빠르게 얻기 위해 고객 - 배송 관계를 추가한다.
      
   5. 기타
      1:M의 M에 해당하는 이력 정보 중 최근 이력을 1에 해당하는 Entity Type에 속성으로 추가한다.
      예) 고객 - 상담이력 관계에서 고객 별 최근 상담 1건을 보여줘야 하는 빈도가 높다면, 최근 상담내용을 고객 Entity Type에 속성으로 추가한다.