🔹 데이터 모델링 이해

🔸 데이터 모델링 개요

• 3단계 데이터 모델링에서 각 단계별 활동과 산출물
  개념 데이터 모델링 : 핵심 엔티티와 그들 간의 관계를 발견하고 그 것을 표현하기 위해서 개체-관계 다이어그램을 생성한다. 사용자와 시스템 개발자가 데이터 요구 사항을 발견하는 것을 지원한다. 현 시스템이 어떻게 변형되어야 하는가를 이해하는데 유용하다.
  논리 데이터 모델링 : 어떻게 데이터에 액세스하고 누가 데이터에 액세스하며, 그러한 액세스는 전산화와는 독립적으로, 다시 말해 누가, 어떻게 그리고 전산화는 별개로 비즈니스 데이터에 존재하는 사실들을 인식 기록하는 것이다.
  물리 데이터 모델링 : 논리 데이터 모델을 기반으로 목표하는 DBMS의 특성 및 구현 환경 등을 감안한 스키마를 일정한 기준과 규칙에 의해 도출하고 칼럼의 데이터 타입과 크기를 정의한다.

• 모델링의 기본 원칙
  커뮤니케이션 원칙 : 최종 사용자 데이터에 대한 뷰를 개념화하고 추상화하여 시스템 설계자들에게 전달하는 것.
  모델링 상세화 원칙 : 데이터는 데이터의 본질과 잠재적 사용을 이해할 수 있을 만큼 상세화 되어야 한다는 것.
  논리적 표현 원칙 : 조직의 데이터에 대한 논리적 측면을 최대한 표현하는 것.

• 좋은 데이터 모델의 요소
  완전성(Completeness), 중복 배제(Non-Redundancy), 비즈니스 룰(Business Rules), 데이터 재사용(Data Reusability), 안정성 및 확장성(Stability and Flexibility), 간결성(Elegance), 의사소통(Communication), 통합성(Integration)

🔸 데이터 모델링 기법 이해

• ER 모델의 구성 요소
  엔티티(Entity) : 업무 활동상 지속적인 관심을 가지고 있어야 하는 대상으로서 그 대상들 간의 동질성을 지닌 것으로 볼 수 있는 개체 집합이나 그들이 행하는 행위의 집합으로 정의할 수 있다.
  애트리뷰트(Attribute) : Entity 내에서 관리하고자 하는 정보들의 항목으로 더 이상 분리되지 않는 단위의 값이다.
  식별자 : Entity의 각 개체들은 인스턴스라고 하는데, 인스턴스는 그들을 지칭하거나 식별해주는 속성인 식별자를 가지고 있다. 예를 들면 직원 인스턴스는 직원 번호, 주민 번호로 식별된다.
  관계 : 엔티티와 엔티티 간 연관성을 표현하는 것으로 엔티티의 정의에 따라 영향을 받기도 하고 속성 정의 및 관계 정의에 따라서도 다양하게 변할 수 있다.
  카디날리티 : 데이터베이스가 지켜야 할 제약 조건들을 명시한다. 관계에 참여하는 하나의 개체에 대해 다른 엔티티에서 몇 개의 개체가 참여하는지를 나타낸다.
  존재 종속 : 만약 한 엔티티의 존재가 다른 엔티티들의 존재에 영향을 받는다면 이를 존재 종속이라 한다.
  서브타입 : 확장된 개체-관계 다이어그램은 서브타입의 개념을 도입했다. 서브타입 엔티티이며 그것의 전체 집합인 슈퍼타입의 부분집합이다.

• 슈퍼타입, 서브타입, 배타적 서브타입과 포괄적 서브타입에 대한 예시
  슈퍼타입과 서브타입은 결코 부모 자식 관계가 아니다.(동일 Level)
  어떤 엔티티가 두 개 이상의 다른 엔티티의 합집합과 관계(Relationship)를 가지는 것을 배타적 관계 혹은 아크(Arc) 관계라고 한다.

• 객체 지향 모델링에 대하여
  객체 : 객체를 기술하는 데이터와 그 기술 데이터를 운영하는 메소드로 구성된다.
  객체 클래스 : 속성 유형과 메소드를 공유하는 객체가 그룹화되어 객체 클래스가 된다.
  연관 : 객체 간의 자연적 관계
  상속 : 한 객체가 다른 객체의 성질을 이어 받는 것
  캡슐화 : 객체들이 한 객체 내부에 일어나는 것은 그 객체 외부에서 일어나는 것과는 관계가 없다는 것

• 객체 지향 모델링과 논리 모델링과의 관계
  객체 지향 모델링과 논리 모델링은 공통점이 많다. 객체지향 모델링 개념은 논리 데이터 모델링의 개념과 매우 유사하다. 그러나 많은 유사점에도 불구하고 차이점 또한 존재한다.

• 객체 지향 모델링의 장점
  재사용 코드와 같은 개념이 실제로 가능한 환경을 제공한다는 것.

🔸 데이터 모델링 표기법 이해

• 바커 표기법(Baker Notation)
  엔티티, 속성, 관계(선택조건, 필수조건), 식별자, 엔티티와 엔티티 간의 관계(1:1, 1:M, M:M)
  서브타입 : 슈퍼타입 안에 서브타입을 상자로 나타낸다.
  관계표현 : 관계선은 실선과 점선으로 구분한다. 실선은 필수, 점선은 선택을 뜻한다.

• I/E(Information Engineering : 정보공학) 표기법
  엔티티, 속성, 관계(선택조건, 필수조건), 식별자
  엔티티는 네모 상자로 표현하고 속성은 엔티티 안에 위치한다. 속성의 식별자는 개체의 상단에 나타내며 수평선이 식별자 밑에 그려진다.
  서브타입 : 서브타입은 배타적 또는 포괄적일 수 있다. 배타적 서브타입은 X자가 있는 돔, 포괄적 서브타입은 X자가 없는 돔으로 표현한다. 관계는 실선으로 그려져 있다.

🔹 개념 데이터 모델링

🔸 주제 영역 정의

• 주제 영역이란?
  주제 영역은 기업이 사용하는 데이터의 최상위 집합이다.

• 주제 영역의 목적
  데이터의 계층적 구조를 파악하는데 도움이 된다.
  업무 기능과 병행하여 분석하는 경우 분석의 최상위 단위 역할을 하여 품질 확보에 기여한다.
  주제 영역 계층과 업무 기능 계층 간의 대응 관계를 확인한다.

• 주제 영역의 장점
  데이터 및 업무 활동 모델의 품질보증, 프로젝트 관리 용이, 모델 개발 조정 용이, 레포지토리 관리 용이

• 주제 영역 도출 방법
  업무에서 사용하는 데이터의 명사형 도출
  업무 기능의 이름으로부터 도출
  하향식 접근(주제 영역에서 데이터 집합)/상향식 접근(데이터 집합을 그룹핑하여 주제 영역 도출)
  분석 단계에서의 도출(아키텍처 모델을 정련하는 과정)

🔸 후보 엔티티 선정

• 후보 엔티티의 수집 방법
  문서, 현업 장표, 인터뷰, 관련 전문 서적, 타 시스템 자료, 보고서, 현장 조사

• 후보 엔티티의 식별 방법
  후보 엔티티의 개념 정립을 명확히 한다.
  우리가 관리하고자 하는 것인지를 따져본다.
  가로와 세로를 가진 집합인지를 확인한다.

• 후보 엔티티 검증 방법
  검토하고자 하는 대상이 집합이 되는지 여부만 확인한다.

• 후보 엔티티의 3가지 분류 형태
  키 엔티티 : 자신의 부모를 가지지 않는 엔티티를 말한다. 다른 엔티티의 도움을 받지 않더라도 어떤 개체를 새롭게 정의할 수 있는 집합이다.
  메인 엔티티 : 키 엔티티를 제외한 다른 모든 엔티티는 부모 엔티티를 가지고 있어야만 태어난다.
  액션 엔티티 : 키 엔티티와 메인 엔티티가 아닌 모든 것이다.

🔸 핵심 엔티티 정의

• 서브타입 지정 이유와 지정 시 고려해야할 사항
  지정 이유 : 엔티티를 명확히하는 단계에서 또 하나의 중요한 작업은 엔티티 내에 들어가는 구체적인 서브타입(부분집합)의 종류를 명시하는 것이다.
  고려 사항 : 교집합 허용 불가, 서브타입의 합이 전체 집합, 서브타입 표현의 기준

🔸 관계 정의

• 관계 형태 표현
  1:1 릴레이션십, M:1 릴레이션십, M:M 릴레이션십

🔸 개념 데이터 모델 작성

• 순환관계란?
  하나의 엔티티가 다른 엔티티가 아닌 자기 자신과 관계를 맺는 관계. 하나의 순환 엔티티는 각 엔티티의 모든 속성을 포함해야 한다. 각 계층에 있는 속성은 동일하게 하는 것이 가장 좋다. 순환 모델의 특징은 조직의 변경(추가/삭제)에 쉽게 대응할 수 있다는 것이다.

• BOM 관계란?
  네트워크 구조(M:M 순환 관계)이다. 상세 모델링 과정에서 새로운 관계 엔티티를 추가하여 두 개의 1:M 관계로 구성된 모델로 구체화된다.

• Arc 관계란?
  어떤 엔티티가 두 개 이상의 다른 엔티티의 합집합과 릴레이션십을 가지는 것. 아크 내에 있는 릴레이션은 보통 동일하다. 아크 내에 있는 릴레이션십은 항상 필수적이거나 선택사양이어야 한다. 아크는 반드시 하나의 엔티티에만 속해야 한다. 어떤 엔티티는 다수의 아크를 가질 수 있다. 그러나 지정된 릴레이션십은 단 하나의 아크에만 사용되어야 한다.

🔹 논리 데이터 모델링

🔸 속성 정의

• 속성이란?
  엔티티에서 관리되는 구체적인 정보 항목으로서 더 이상 분리될 수 없는 최소의 데이터 보관 단위이다. 엔티티에 속하는 모든 인스턴스들이 공통으로 가지는 특성으로 각 엔티티들은 일련의 속성들에 의해 상세화된다.

• 속성의 특징
  어원적 의미(가공되지 않은 원천적인 것을 의미). 속성도 일종의 집합이다. 릴레이션십도 속성이다. 속성들 간은 서로 독립적이다.

• 속성 후보 도출처 및 방법
  속성 후보 도출처 : 구 시스템의 문서 자료, 현업 장표/보고서, 사용자와의 협의, DFD의 DD, 전문서적 및 자료, 다른 시스템의 자료
  방법 : 원시 속성으로 보이는 후보는 버리지 않는다. 소그룹별로 후보군을 만들고 가장 근접한 엔티티에 할당한다.

• 속성의 구성 요소
  속성명 : 속성의 내용이나 목적이 무엇인지 알려주는 명사 또는 명사구
  도메인 : 속성이 지닐 수 있는 값에 대한 업무적인 제약 조건으로 파악된 일련의 특성
  선택성 : 모든 건의 해당 속성이 반드시 값을 가져야 하는지의 여부를 나타냄

• 속성 검증 방법
  최소 단위까지 분할한다.
  하나의 값만을 가지는지 검증한다.
  추출 속성인지 검증한다.
  보다 상세하게 관리할 필요성에 대해 검토한다.

• 속성 정의 시 유의사항
  의미가 명확한 속성 명칭을 부여한다.
  유일한 복합 명사를 사용한다.
  단수형으로 속성명을 사용한다.
  표준 단어 제정.
  작의적인 전용 금지.

🔸 엔티티 상세화

• 식별자의 종류 및 특징
  본질 식별자 : 엔티티 상세화 단계에서 정의되어질 핵심, 액션(행위) 엔티티에 대한 본질 식별자를 정의한다.
  후보 식별자 : 각 인스턴스를 유일하게 식별할 수 있어야한다. 나머지 속성들을 직접 식별할 수 있어야 한다. NULL이 될 수 없다. 후보 식별자로 속성 집합을 선택하는 경우네는 개념적으로 유일해야 한다. 후보 식별자의 데이터는 자주 변경되지 않는 것이어야 한다.
  대체(보조) 식별자 : 원래의 식별자를 대신할 수 있는 또 다른 속성들이나 릴레이션십을 말한다. 보조 식별자는 여러 참조 엔티티 중에서 원래의 식별자보다 보조 식별자로 연결을 맺는 것이 자신에게 훨씬 유리한 경우에 의미가 있게 된다.
  인조 식별자 : 식별자 확정 시 기존의 본질 식별자를 실질 식별자로 인정할 수 없는 상황이 발생했을 때, 전부 혹은 일부를 임의의 값을 가진 속성들로 대체하여 새롭게 구성한 식별자이다. 최대한 범용적인 값을 사용하며 유일한 값을 만들기 위해 인조 식별자를 사용한다. 하나의 인조 식별자 속성으로 대체할 수 없는 형태를 주의한다. 편의성/단순성 확보를 위한 인조 식별자를 사용할 수 있다. 의미의 체계화를 위한 인조 식별자를 사용할 수 있다. 내부적으로만 사용한다.

• 정규화란?
  논리적 데이터 모델을 일관성 있고 중복을 제거하여 보다 안정성을 갖는 바람직한 자료 구조로 만들기 위해 여러 단계를 거치는 것이다. 정규화 과정을 통해서 변경 이상의 엔티티를 정규화 된 엔티티로 변환하게 된다.

• 정규화의 이상 현상 발생 원인과 종류
  변경 이상 : 엔티티에 데이터를 삽입, 수정, 삭제할 때 오류가 발생할 개연성을 가지고 있다. 구체적으로 삽입, 수정, 삭제 이상 등이 있고 정규화 과정을 통해서 변경 이상의 엔티티를 정규화된 엔티티로 변환하게 된다.
  1. 입력 이상 : 별도의 사실이 발생하기 전까지 원하는 데이터를 삽입할 수 없다. 어떤 데이터를 삽입하려고 할 때 불필요하게 원하지 않는 데이터도 함께 삽입되게 된다.
  2. 삭제 이상 : 일부 정보를 삭제함으로써 유지되어야 할 정보까지도 삭제되는 연대 삭제가 발생한다.
  3. 갱신 이상 : 일부 속성 값을 갱신함으로써 원하지 않는 정보의 이상 현상(무결성 파괴, 정보의 모순성)이 발생한다.

• 제 1, 2, 3차 정규형
  1. 제 1차 정규형 : 모든 속성은 반드시 하나의 값을 가져야 한다. 반복 형태가 있어서는 안된다. 각 속성의 모든 값은 동일한 형식이어야 한다. 각 속성들은 유일한 이름을 가져야 한다. 레코드들은 서로 간의 식별이 가능해야 한다.
  - 정규화 작업
  속성의 값이 여러 건이 된다면 1차 정규형을 위배하는 것이 된다.
  어떤 속성이 다수의 값을 가지고 있다면 M:1 관계에 새로 엔티티를 추가한다.
  관계형 모델에서는 관계 정의상 한 속성이 하나의 값만을 가져야 한다.
  비정규형 관계가 관계로서의 모습을 갖추기 위해선 여러 개의 복합적인 의미를 가지고 있는 속성이 분해되어 하나의 의미만을 표현하는 속성들로 분해되어야 한다.
  비정규형 관계가 관계로서의 모습을 갖추기 위해선 하나의 속성이 하나의 값을 가질 수 있어야 하며 이 조건을 만족시키기 위해서는 튜플이 늘어나야 하거나 또는 다른 관계로 분리되어야 한다.
  분석 또는 모델링 진행 과정에서 발생하여 최종적인 모델링 완성 단계에서는 나올 수 없다. 그러나 모델링 초기 단계에서는 상세히 분해된 속성보다는 위와 같은 레벨의 속성 추출이 복잡도를 줄일 수 있으므로 실전에서는 효율적이고 유리하게 이용될 수도 있다.
  

2. 제 2차 정규형 : 식별자가 아닌 모든 속성들은 식별자 전체 속성에 완전 종속되어야 한다. 물리 데이터 모델의 테이블로 말하면 기본 키가 아닌 모든 컬럼들이 기본 키에 종속적이어야 2차 정규형을 만족할 수 있다는 것이다.
- 정규화 작업
식별자가 학번+코스코드로 이루어진 학과등록 엔티티에서 학번 속성에 평가코드와 평가내역 속성들이 종속적이면 2차 정규형을 위반하고 있는 것이다.
본질 식별자를 알아야 식별자 부분 종속인지를 구분할 수 있다.
속성의 의미가 명확해야 종속성을 비교할 수 있다.
어떤 속성 식별자 전체에 종속되어 있지 않으면 잘못된 위치이며 새로운 엔티티, 즉 상위 부모 엔티티를 생성하고 UID BAR를 상속받게 된다.

3. 3차 정규형 : 2차 정규형을 만족하고 식별자를 제외한 나머지 속성들 간의 종속이 존재하면 안된다. 이것이 3차 정규형을 만족하는 것이다.
- 정규화 작업
학과 등록 엔티티에서 평가코드, 평가내역 속성들이 서로 간에 종속적(평가내역 속성은 평가코드 속성에 종속적)이면 3차 정규형을 위반하고 있는 것이다.
3차 정규형을 위반하고 있을 시에는 평가항목 엔티티처럼 부모 엔티티가 생성되고 그 부모 엔티티로부터 UID BAR가 없는 관계를 상속받게 된다.
- 3차 정규형 문제점
한 릴레이션에 여러 개의 후보 키가 있으며 모든 후보 키들이 적어도 둘 이상의 속성으로 이루어지는 복합 키이며 모든 후보 키들이 적어도 하나 이상의 공통 속성이 포함되는 경우이다.

• BNCF 정규형이란?
  모든 결정자가 키인 릴레이션이다. 어떠한 결정자 하나라도 키가 아닌 릴레이션이라면 BNCF가 될 수 없다.
  기존의 2차 정규형과 3차 정규형을 보완하려는 목적으로 만들어졌다. 즉 부분 종속이나 이행 종속이 없는 3차 정규형도 변경 이상현상이 나타날 수 있기 때문이고 이것은 어떤 Non-Key 속성이 결정자로 동작하기 때문에 발생한다.
  3차 정규형을 만족하고 BNCF가 아닌 경우 : 각 속성이 단 하나의 값으로 구성된 경우(1차 정규형). Non-Key 속성은 후보 키에 완전 함수 종속이므로 2차 정규형에 속한다. Non-Key 속성이 하나 뿐일 때, Non-Key 속성 간의 종속 관계가 존재하지 않으면 제 3차 정규형을 만족한다.

• M:M 관계를 왜 해소해야 하는지, 해소 과정
  해소 의의 : M:M 관계는 불특정 관계로도 알려져 있으며 데이터 구조에 있어서 어떠한 실제적 방법으로도 구현이 불가능하다. 연관 실체 엔티티는 M:M 관계 미결 시 간과해 버렸을 추가 업무 규칙 또는 업무 논리를 내포할 수 있다.
  M:M 관계는 데이터 종속성에 대한 결정을 어렵게 하여 모델의 논리적 완성과 부분 집합 식별 능력을 제한한다. M:M 관계 해결 시까지 모델은 불안정 상태에 머물 것이다. 모델은 정규화되지 못하고 모델에 대한 문서화 작업도 완비되지 못할 것이다.
  해소 과정 : M:M 릴레이션십은 새로운 릴레이션 엔티티를 추가하여 M:1 관계로 변경한다.

• 참조 무결성이란?
  관계 테이블의 모든 외부 식별자 값은 관련 있는 관계 테이블의 모든 주 식별자 값이 존재해야 한다. 실체의 주 식별자(PK)와 마찬가지로 외부 식별자(FK)도 데이터 무결성에 관한 업무 규칙을 내포하고 있다. 데이터베이스 설계 관점에서 선택하지 말고 사용자의 업무 규칙에 따라 적절한 규칙을 선택해야 한다.

• 참조 무결성을 유지하고자 할 때의 규칙들
  1. 입력 규칙
  Dependent : 대응되는 부모 실체에 인스턴스가 있는 경우에만 자식 실체에 입력을 허용한다.
  Automatic : 자식 실체 인스턴스의 입력을 항상 허용하고 대응되는 부모 건이 없는 경우 이를 자동 생성한다.
  Nullify : 자식 실체 인스턴스의 입력을 항상 허용하고 대응되는 부모 건이 없는 경우 자식 실체의 참조키(FK)를 Null 값으로 처리한다.
  Default : 자식 실체 인스턴스의 입력을 항상 허용하고 대응되는 부모 건이 없는 경우 참조키(FK)를 지정된 기본 값으로 처리한다.
  Customized : 특정한 검증 조건이 만족되는 경우에만 자식 실체 인스턴스의 입력을 허용한다.
  No Effect : 자식 실체 인스턴스의 입력을 조건 없이 허용한다.
  2. 삭제 규칙
  Restrict : 대응되는 자식 실체의 인스턴스가 없는 경우에만 부모 실체 인스턴스 삭제를 허용한다.
  Cascade : 부모 실체 인스턴스의 삭제를 항상 허용하고 대응되는 자식 실체의 인스턴스를 자동 삭제한다.
  Nullify : 부모 실체 인스턴스의 삭제를 항상 허용하고 대응되는 자식 실체의 인스턴스가 존재하면 그것의 참조키(FK)를 Null 값으로 수정한다.
  Default : 부모 실체 인스턴스의 삭제를 항상 허용하고 대응되는 자식 실체의 인스턴스가 존재하면 그것의 참조키(FK)를 기본 값으로 수정한다.
  Customized : 특정한 검증 조건이 만족되는 경우에만 부모 실체 인스턴스의 삭제를 허용한다.
  No Effect : 부모 실체 인스턴스 삭제를 조건 없이 허용한다.

🔸 이력 관리 정의

• 이력 관리란?
  데이터는 현재의 프로세스만 처리하고 버리는 것이 아니라 오랜 기간의 데이터를 유지시켜 좀 더 가치 있는 정보를 제공할 수 있는 밑거름이 되도록 해야한다. 모든 업무가 언제 시작해서 언제 끝났는지에 관한 정보가 기록되어 있다.

• 이력 데이터의 종류
  발생 이력 데이터 : 어떤 데이터가 발생할 때마다 이력 정보를 남기는 이력(이력을 관리하는 방법으로 사용)
  변경 이력 데이터 : 데이터가 변경될 때마다 변경 전과 후의 차이를 확인해야 한다면 변경 이력을 남길 수 있다.
  진행 이력 데이터 : 업무의 진행에 따라서 이 데이터를 이력 정보로 남겨야만 하는 경우

• 이력 관리 형태
  시점 이력 : 데이터의 변경이 발생한 시각만을 관리
  선분 이력 : 데이터 변경의 시작 시점부터 그 상태의 종료 시점까지 관리

🔹 물리 데이터 모델링

🔸 논리-물리 모델 변환

• 논리 데이터 모델과 물리 데이터 모델에서 사용되는 용어 비교

  논리 데이터 모델	물리 데이터 모델
  Entity	Table
  Attribute	Column
  Primary UID	Primary Key
  Secondary(Alternate) UID	Unique Key
  Relationship	Foreign Key
  Business Constraints	Check Constraints

테이블은 데이터를 저장하기 위해서 생성된 데이터베이스에서의 가장 기본적인 오브젝트이다. 테이블은 기본적으로 컬럼(column)과 로우(row)를 가진다.

컬럼의 명칭은 속성의 명칭과 반드시 일치할 필요는 없으나 프로그래머와 사용자의 혼돈을 피하기 위해 가능한 표준화된 약어를 사용한다. SQL의 예약어 사용을 피한다. 가능한 컬럼 명칭은 짧은 것이 좋으며 짧은 명칭은 SQL 해독 시간을 감소시킨다. 필수 입력 속성은 Nulls/Unique 란에 NN을 표시한다. 실제 테이블의 설계를 검증하기 위한 목적으로 가능하다면 표본 데이터를 입력시킨다.

논리 데이터 모델에서의 Primary UID에 속하는 물리 데이터 모델에서는 기본 키로 생성된다. 키 형태 란에 엔티티의 Primary UID에 속하는 모든 속성들에 PK를 표시한다. PK로 표시된 모든 컬럼들은 Nulls/Unique란에 반드시 NN, U로 표시되어야 한다. 여러 개의 컬럼으로 UID가 구성되어 있는 경우는 각각의 컬럼에 NN, U1을 표시하고 또 다른 Unique Key가 있다면 U2로 표시한다.

논리 데이터 모델에서 정의한 Secondary UID 또는 Alternate Key들은 해당 집합과 상태 집합과의 선택적인 관계를 가질 수 있도록 하는데 중요한 역할을 수행한다. Secondary UID들은 물리 데이터 모델에서는 Unique Key로 생성된다. 변환 절차는 기본적으로 Primary UID 변환 절차와 동일하다.

• Primary UID를 기본키(Primary Key)로 변환하는 절차
  키 형태 란에 엔티티의 Primary UID에 속하는 모든 속성들에 PK를 표시한다.
  PK로 표시된 모든 컬럼들은 Nulls/Unique 란에 반드시 NN, U로 표시되어야 한다.
  여러 개의 컬럼으로 UID가 구성되어 있는 경우는 각각의 컬럼에 NN, U1을 표시한다. 또다른 Unique Key(Secondary UID)가 있다면 U2로 표시한다.

• 관계(Relationship) 변환 절차
  1. 1:M 관계 변환
  1에 있는 PK를 M의 FK로 변환한다. 필수 관계가 아닌 경우에는 NN을 체크하지 않는다.
  표본 데이터를 추가한다.
  UID BAR가 있는 경우는 전 단계에서 실시한다.
  2. 1:1 관계 변환
  Mandatory 반대쪽에 있는 테이블의 기본 키를 Mandatory쪽 테이블의 외래 키로 변환한다.
  NN 표시를 한다.
  3. 1:M 순환 관계 변환
  해당 테이블 내에 외래 키 컬럼을 추가한다. 외래 키는 같은 테이블 내의 다른 로우의 기본 키 컬럼을 참조하게 된다.
  외래 키 컬럼 명칭은 가능한 한 단계 명칭을 반영한다. 외래 키는 결코 NN(Not Null)이 될 수 없다.
  4. 배타적 관계 변환
  외래 키 분리 방법 : 각각의 관계를 컬럼으로 생성하는 방법이다. 이 방법을 사용하면 실제 외래 키 제약조건을 생성할 수 있다는 장점이 있다. 하지만 각각의 키 컬럼들이 Optional이어야 한다. 또한 다음과 같은 체크 제약 조건을 추가적으로 생성하여야 한다.
  외래 키 결합 방법 : 각각의 관계를 하나의 관계 컬럼으로 생성하는 방법이다. 이 방법을 사용하면 실제 외래 키 제약조건을 생성할 수 없다는 단점이 있다. 또한 각각의 관계를 구분할 수 있는 추가적인 컬럼이 필요하게 된다.

🔸 반정규화

• 반정규화를 왜 하는지, 수평 분할과 수직 분할을 해야하는 이유
  하나의 테이블을 수직 혹은 수형으로 분할하는 것을 테이블 분할, 파티셔닝이라고 한다.
  - 수평 분할
  레코드를 기준으로 테이블을 분할
  하나의 테이블에 데이터가 너무 많이 있고 레코드 중에서 특정한 덩어리의 범위만을 주로 액세스 하는 경우에 사용한다.
  분할된 각 테이블은 서로 다른 디스크에 위치시켜 물리적인 디스크의 효용성을 극대화할 수 있다.
  현재는 이러한 수평 테이블의 분할은 DBMS 차원에서 제공하고 있다.
  - 수직 분할
  하나의 테이블이 가지는 컬럼의 갯수가 많아지기 때문에 일언나다.
  조회 위주의 컬럼과 갱신 위주의 컬럼으로 나뉘는 경우 : 데이터를 갱신하는 작업이 일어날 때 업데이트하려는 레코드, 즉 레코드에 잠금을 수행하기 때문
  특별히 자주 조회되는 컬럼이 있는 경우 : 컬럼 수가 아주 많은 테이블에서 주로 사용되어지는 컬럼들이 극히 일부라고 가정한다면 이러한 일부 컬럼들로 이루어진 테이블을 생성하여 실제 물리적인 I/O의 양을 줄여서 데이터 액세스 성능을 향상시킨다.
  특정 컬럼 크기가 아주 큰 경우 : 데이블의 컬럼에 텍스트 및 이미지 데이터가 포함될 때 성능이 저하될 가능성이 있다.
  특정 컬럼에 보안을 적용해야 하는 경우 : 해당 컬럼에 대해서 권한을 제어하기 위해서는 보안을 적용하고자 하는 컬럼을 분리해서 이를 별도의 테이블로 만들어서 그 테이블에 대한 권한을 제어하기 위한 목적으로 수직 분할을 할 수 있다.
  
  
• 중복 테이블을 생성하는 이유
  매우 많은 양의 데이터가 대상이 되고 하나의 테이블이 아닌 여러 개의 테이블에서 필요한 데이터를 추출하는 경우가 대부분인데 이를 위해 특정 통계 테이블을 두거나 중복 테이블을 추가할 수 있다.
  • 중복 테이블 생성 판단 근거
    정규화에 충실하면 종속성, 활용성은 향상되나 수행 속도 증가가 발생하는 경우 고려한다.
    많은 범위를 자주 처리해야 하는 경우에 고려한다.
    특정 범위의 데이터만 자주 처리되는 경우에 고려한다.
    처리 범위의 데이터만 자주 처리되는 경우에 고려한다.
    요약 자료만 주로 요구되는 경우에 고려한다.
    추가된 테이블의 처리를 위한 오버헤드를 고려하여 결정한다.
    인덱스의 조정이나 부분 범위 처리로 유도, 클러스터링을 이용하여 해결할 수 있는지를 철저히 검토한 후 결정한다.
  • 중복 컬럼 생성
    논리 데이터 모델링 과정에서 정규화를 통하여 중복 컬럼을 최대한 제거하는 작업을 수행하지만 물리 데이터 모델링 과정에서 이러한 정규화를 어기면서 다시 데이터의 중복(중복 컬럼 생성)을 수행하곤 한다.
    중복 컬럼 생성 상황 :
    빈번하게 조인을 일으키는 컬럼에 대해서 고려해 볼 수 있다.
    조인의 범위가 다량인 경우를 온라인화해야 하는 경우처럼 속도가 중요한 컬럼에 대해서는 중복 컬럼을 고려할 수 있다.
    액세스의 조건으로 자주 사용되는 컬럼에 대해서 고려해 볼 수 있다.
    자주 사용되는 액세스 조건이 다른 테이블에 분산되어 있어 상세한 조건 부여에도 불구하고 액세스 범위를 줄이지 못하는 경우에 자주 사용되는 조건들을 하나의 테이블로 모아서 조건의 변별성을 극대화할 수 있다.
    복사된 컬럼의 도메인은 원본 컬럼과 동일하게 해야 한다. 이것은 데이터의 일관성을 위한 필수적인 사항이다.
    접근 경로의 단축을 위해서 부모 테이블의 컬럼을 자식 테이블에 중복시킬 수 있다.
    상위 레벨의 테이블에 집계된 컬럼을 추가할 수 있다.
    하위 레벨의 테이블로 중복 컬럼을 복사할 수 있다.
    연산된 결과를 주로 사용하는 경우에도 미리 연산을 하여 중복 컬럼을 생성할 수 있다.
    여러 컬럼들의 조합 또는 복잡한 연산의 결과를 통해서 판단할 수 밖에 없는 값이 검색의 조건으로 사용되는 경우에는 연산의 결과를 중복 컬럼으로 생성할 수 있다.
    여러 개의 로우로 구성되는 값을 하나의 로우에 나열하는 경우이다. 즉 로우로 관리하던 데이터를 컬럼으로 관리하는 경우이다.
    기본 키의 컬럼이 길거나 여러 개의 컬럼으로 구성되어 있는 경우 인위적인 기본 키를 추가할 수 있다.