1. 데이터 모델링의 이해

1-1. 데이터 모델링의 이해

📂 데이터 모델의 이해

1. 모델링의 이해

• 모델링이란? 복잡한 현실세계를 추상화, 단순화 명확화하기 위해 일정한 표기법에 의해 표현하는 기법

• 모델링의 특징

  • 1) 추상화 : 현실세계를 일정한 형식에 맞추어 표현을 한다는 의미
  • 2) 단순화 : 복잡한 현실세계를 약속된 규약에 의해 제한된 언어로 표현하여 쉽게 이해 할 수 있도록 한다는 의미
  • 3) 명확화 : 누구나 이해하기 쉽도록 애매모호함을 제거하고 정확하게 현상을 기술한다는 의미

• 모델링의 3가지 관점

  • 1) 데이터 관점 : 업무와 데이터의 관계 또는 데이터 간의 관계에 대해 모델링 (Data, What) -> 이 장의 중심
  • 2) 프로세스 관점 : 업무가 실제하고 있는 일이 무엇인지 또는 무엇을 해야 하는지 모델링 (Process, How)
  • 3) 데이터와 프로세스의 상관관점 : 업무가 처리하는 일의 방법에 따라 데이터가 어떻게 영향을 받는지 모델링 (Interaction)

2. 데이터 모델링의 기본 개념

• 데이터 모델링이란?

  • 정보시스템을 구축하기 위한 데이타관점의 업무 분석 기법
  • 현실세계의 데이타(what)에 대해 약속된 표기법에 의해 표현하는 과정
  • 데이터베이스를 구축하기 위한 분석/설계의 과정

• 데이터 모델이 제공하는 기능

  • 시스템 가시화 / 시스템 명세화 / 구조화된 틀 제공 / 문서화 / 세부사항 숨기는 관점 제공

• 데이터 모델링의 중요성

  • 1) 파급효과 : 데이터 구조 변경에 의해 많은 영향이 갈 수 있다.

  • 2) 복잡한 정보 요구사항의 간결한 표현 : 데이터 모델은 구축할 시스템의 정보 요구사항과 한계를 가장 명확하고 간결하게 표현할 수 있는 도구임. (예를 들면 건축물의 설계도면)

  • 3) 데이터 품질 (Data Quality) : 데이터 구조가 데이터의 품질을 결정하는 중요한 요소이기 때문에 모델링시 유의해야 한다.

    • 중복 유의 / 비유연성 유의 (프로세스 변화에도 데이터모델이 변경되지 않을 수 있도록 유연하게 설계) / 비일관성 유의 (데이터 상호 연관관계에 대한 명확한 정의가 필요)

• 데이터 모델링의 3가지 요소

  • 1) 어떤 것 (엔터티, Things) / 2) 어떤 것의 성격(Attributes) / 3) 어떤 것 간의 관계(Relationship)

  • 복수	단수
    엔터티 (ex. 과목)	인스턴스 (ex. 수학,영어)

    • ex. 과목은 엔터티에 해당하고, 수학,영어는 '과목'이라는 엔터티의 인스턴스이다.

3. 데이터 모델링의 3단계 진행

• 개념적 모델링 -> 논리적 모델링 -> 물리적 모델링

• 1) 개념적 모델링 : 사용자와 개발자가 데이터 요구사항을 발견하는 것 지원. 추상적이므로 상위 문제에 대한 구조화 가능. 전 조직에 걸쳐 이루어진다면, 전사적 데이터 모델이라고도 불림.

• 2) 논리적 모델링 : 데이터 설계 프로세스의 Input으로써, 논리적인 구조와 규칙을 명확하게 표현. 식별자 확정, 정규화, M:M관계 해소, 참조 무결성 규칙 정의 등으로 신뢰성 있는 데이터구조 얻음.

• 3) 물리적 모델링 : 논리 데이터 모델이 어떻게 하드웨어에 표현될 것인지 다룸(=물리적 스키마).

• 프로젝트 생명주기(life cycle)에서 데이터 모델링

  • 프로젝트 생명주기 : 분석(논리적/개념적 모델링 과정 포함) -> 설계(물리적 모델링 포함) -> 개발 -> 테스트 -> 전환/이행

4. 데이터 독립성

• 데이터 독립성의 필요성

  • 1) 유지보수 비용증가 / 2) 데이터 중복성 증가 / 3) 데이터 복잡도 증가 / 4) 요구사항 대응 저하

• 데이터 독립성 모델(ANSI/SPARC)의 3단계 구조

  • 1) 내부적 단계[내부스키마] -- (물리적 데이터 독립성) --> 2) 개념적 단계[개념스키마] -- (논리적 데이터 독립성) --> 외부 단계[외부스키마]
  • 

  • 항목	설명
    외부스키마	사용자 관점으로 구성. 접근하는 특성에 따른 스키마 구성
    개념스키마	모든 사용자 관점을 통합한 조직 전체의 DB 기술함. DB에 저장되는 데이터와 관계를 표현하는 스키마.
    내부스키마	DB가 물리적으로 저장되는 방법을 표현하는 스키마
    논리적 독립성	개념스키마가 변경되어도 외부스키마에 영향 없도록. 사용자 특성에 맞는 변경 가능. 통합구조 변경가능.
    물리적 독립성	내부스키마가 변경되어도 외부/개념스키마에 영향 없도록.

5. 데이터 모델의 표기법 ERD

• ERD 작업 순서 : ① 엔터티를 그린다. → ② 엔터티를 적절하게 배치한다 → ③ 엔터티간 관계를 설정한다. → ④ 관계명을 기술한다. → ⑤ 관계의 참여도를 기술한다. → ⑥ 관계의 필수 여부를 기술한다.
• 엔터티(사각형), 관계(마름모), IE표기법 혹은 Baker표기법 주로 사용

6. 좋은 데이터 모델의 요소

• 1) 완전성(Completeness) : 업무에 필요로 하는 모든 데이터가 데이터 모델에 정의
• 2) 중복배제(Non-Redundancy) : DB에 동일한 사실은 반드시 한번만 기록 (ex. 나이, 생년월일은 데이터 중복)
• 3) 업무규칙(Business Rules) : 업무규칙을 데이터 모델로 표현하고 모든 사용자가 공유할 수
  있도록 제공
• 4) 데이터 재사용(Data Reusablity) : 데이터의 통합성과 독립성에 대해서 충분히 고려
• 5) 의사소통(Communication) : 데이터의 모델은 진정한 의사소통의 도구로서의 역할을 한다.
• 6) 통합성(Integration) : 동일한 데이터는 조직의 전체에서 한번만 정의되고 이를 여러 다른 영역에서 참조, 활용

---

📂 엔터티

1. 엔터티(Entity)의 개념

• 사람, 장소, 물건, 사건, 개념 등의 명사에 해당한다.
• 업무상 관리가 필요한 관심사에 해당한다.
• 저장이 되기 위한 어떤 것(Thing)이다.

2. 엔터티의 특징

• 반드시 해당 업무에서 필요하고 관리하고자 하는 정보이어야 한다.
• 유일한 식별자에 의해 식별이 가능해야 한다.
• 영속적으로 존재하는 인스턴스의 집합이어야 한다.
  (한개가 아닌 두개 이상의 row)
• 엔터티는 업무 프로세스에 의해 이용되어야 한다.
• 엔터티는 반드시 속성이 있어야 한다.
  (주식별자만 존재하는 엔터티도 부적절. 단, 관계엔터티는 주식별자만 갖고 있어도 엔터티로 인정함)
• 엔터티는 다른 엔터티와 최소 한 개 이상의 관계가 있어야 한다.
  (단, 통계성 엔터티, 코드성 엔터티(읽기효율성↓), 시스템 처리 내부 엔터티 도출의 경우 제외)
• 명명 : 현업용어 사용 / 약어 사용하지 않기 / 단수명사 사용 / 모든 엔터티 유일한 이름 / 엔터티 생성 의미대로 부여

3. 엔터티의 분류

• 유무형에 따른 분류

  • 유형엔터티(사원, 물품) : 물리적인 형태가 있고, 안정적이며 지속적으로 활용되는 엔터티
  • 개념엔터티(조직, 보험상품) : 물리적인 형태가 존재하지 않고, 관리해야할 개념적 정보로
    구분이 되는 엔터티
  • 사건엔터티(주문, 청구, 미납) : 업무를 수행함에 따라 발생되는 엔터티로서 비교적 발생량이 많으며 각종 통계자료에 이용

• 발생시점에 따른 분류

  • 기본엔터티(상품, 사원, 부서) : 그 업무에 원래 존재하는 정보로서 다른 엔터티와 관계에 의해 생성되지않고 독립적으로 생성이 가능하고 자신은 타 엔터티의 부모의 역할을 한다. 다른 엔터티로부터 주식별자를 상속받지않고 "자신의 고유한 주식별자"를 가짐.
  • 중심엔터티(계약, 접수, 주문) : "기본 엔터티"로부터 발생되고 그 업무에 있어서 중심적인 역할을 한다. 데이터의 양이 많이 발생한다.
  • 행위엔터티(거래내역, 주문내역, 변경이력) : "두개 이상의 부모 엔터티"로부터 발생되고, 자주 내용이 바뀌거나 데이터량이 증가한다.

---

📂 속성

1. 속성(Attribute)의 개념

• 속성이란? 업무에서 필요로 하는 인스턴스로 의미상 더 이상 분리되지 않는 최소의 데이터 단위이다.

2. 속성의 특징

• 속성의 특징

  • 엔터티와 마찬가지로 반드시 해당 업무에서 필요하고 관리하고자 하는 정보
  • 정규화 이론에 근간하여 정해진 주식별자에 함수적 종속성을 가져야 함
  • 하나의 속성에는 한개의 값만 가짐. 다중값일 경우 별도의 엔터티로 분리

• 엔터티, 인스턴스, 속성, 속성값의 관계

  • 한 개의 엔터티는 두 개 이상의 인스턴스들의 집합이어야 함.
  • 한 개의 엔터티는 두 개 이상의 속성을 갖는다.
  • 한 개의 속성은 한 개의 속성값을 갖는다.

• 속성의 명명

  • 해당업무에서 사용하는 이름 부여 / 서술식 속성명 사용하지 않음 / 약어사용 가급적 제한 / 유일성 확보

3. 속성의 분류

• 속성의 특성에 따른 분류

  • 기본속성(제품이름) : 업무로부터 추출한 모든 속성이 여기에 해당되며, 가장 일반적이고 대부분 여기에 속함.
  • 설계속성(약품코드) : 업무를 규칙화하기 위해 속성을 새로 만들거나 변형하여 정의하는 속성
  • 파생속성(계산값) : 다른 속성에 영향을 받아 발생하는 속성. 보통 계산된 값들이 이에 해당됨.

• 엔터티 구성방식에 따른 분류

  • 식별과 관계에 따른 분류
    ㆍPK 속성 : 엔터티를 식별할 수 있는 속성
    ㆍFK 속성 : 다른 엔터티와의 관계에서 포함되는 속성
    ㆍ일반 속성 : PK, FK에 포함되지 않는 속성
  • 세부 의미로 쪼갤 수 있는지에 따라
    ㆍ단순형(나이, 성별) : 더 이상 다른 속성들로 구성될 수 없다.
    ㆍ복합형(시, 구, 동, 번지) : 여러 세부 속성들로 구성될 수 있다.
  • 동일한 성질이 있는지 없는지에 따라
    ㆍ단일값 속성(주민번호)
    ㆍ다중값 속성(차량색상-지붕, 차체, 외부 색)

4. 도메인

• 도메인(Domain) : 각 속성이 가질 수 있는 값의 범위. 엔터티 내에서 속성에 대한 데이터타입과 크기, 제약사항을 지정하는 것.

📂 관계

1. 관계의 개념

• 관계(Relationship) : 엔터티의 인스턴스 사이의 논리적인 연관성

2. 관계의 분류

• 존재적 관계(부서, 사원) / 행위적 관계(고객, 주문)
• ERD : 존재적 관계와 행위에 의한 관계를 구분하여 표현하지 않음
• UML : 연관관계(존재적 관계, 실선), 의존관계(행위적 관계, 점선)

3. 관계의 표기법

• 관계명 : 엔터티가 관계에 참여하는 형태를 지칭. 관계의 이름
  • 관계시작점 : 관계가 시작되는 엔터티 편
  • 관계끝점 : 관계를 받는 엔터티 편
  • 관계시작점과 끝점 모두 관계명을 가져야하며, 능동적이거나 수동적으로 명명된다.
• 관계차수 : 1:1, 1:M, M:M
  • 두 개의 엔터티간 관계에서 참여자의 수를 표현

  • 차수	IE 표기법	Barker 표기법
    1:1	실선 & 선(1)	실선
    1:M	실선 & 선(1) + 까마귀발(M)	점선&선(1) + 실선&까마귀발(M)
    M:M	실선 & 까마귀발(M)	실선&까마귀발(M)

    1:1 IE > 실선에 선추가, Baker
    
• 관계선택사양 : 필수관계, 선택관계
  • 필수참여관계 : 참여하는 모든 참여자가 관계를 가짐
  • 선택참여관계 : 외래키로 연결될 경우 Null 허용

4. 관계 체크사항 및 읽는 방법

• 체크사항
  • 두 개의 엔터티 사이에 관심있는 연관규칙이 존재하는가?
  • 두 개의 엔터티 사이에 정보의 조합이 발생되는가?
  • 업무기술서, 장표에 관계연결에 대한 규칙이 서술되어 있는가?
  • 업무기술서, 장표에 관계연결을 가능하게 하는 동사(Verb)가 있는가?
• 읽기
  • 엔터티(각각의/하나의), 기준엔터티, 관계차수(한/여러), 관련엔터티, 선택사양(항상/때때로), 관계명
    ex) 각 부서에는 여러 사원이 항상 소속된다.
    각 사원은 한 부서에 때때로 속한다.

📂 식별자

1. 식별자(Identifiers) 개념

• 식별자란 ? 엔터티내에서 인스턴스들을 구분할 수 있는 구분자

• 주식별자의 특징

  • 유일성 : 주식별자에 의해 엔터티내에 모든 인스턴스들이 유일하게 구분되어야 함
  • 최소성 : 주식별자를 구성하는 속성의 수는 유일성을 만족하는 최소의 수가 되어야 함
  • 불변성 : 값은 변하지 않아야 함
  • 존재성 : 반드시 값이 있어야 함(Not Null)

• 주식별자 도출기준
  • 해당 업무에서 자주 이용되는 속성을 주식별자로 지정
  • 명칭, 내역 등과 같이 이름으로 기술되는 것을 피함
  • 복합으로 주식별자를 구성할 경우 속성의 수가 많아지지 않도록 함

2. 식별자의 분류 및 표기법

• 분류
  • 대표성여부
    • 주식별자(PK) : 엔터티 내에서 각 어커런스를 구분할 수 있으며, 타 엔터티와 참조관계를 연결 가능.
    • 보조식별자 : 엔터티 내에서 각 어커런스를 구분할 수 있으나, 대표성을 가지지 못해 참조관계 연결 못함.
  • 스스로 생성 여부
    • 내부식별자 : 엔터티 내부에서 스스로 만들어지는 식별자
    • 외부식별자 : 타 엔터티와의 관계를 통해 타 엔터티로부터 받아오는 식별자(FK)
  • 속성의 수
    • 단일식별자 : 하나의 속성으로 구성된 식별
    • 복합식별자 : 둘 이상의 속성으로 구성된 식별자
  • 대체여부
    • 본질식별자 : 업무에 의해 만들어지는 식별자(주민번호)
    • 인조식별자 : 원조식별자가 복잡한 구성일 경우 인위적으로 만든 식별자(고객식별자)
• 표기법
  • IE 표기법
    ┌──────┐
    │주식별자 │: 일반속성 상단에 위치함
    ├──────┤
    │보조식별자 │: 일반속성과 같이 위치함
    │일반속성 │
    └──────┘
  • Barker 표기법
    ┌──────┐
    │#주식별자 │: # 표시
    │*보조식별자 │: * 표시
    │o일반속성 │: o 표시
    └──────┘
    

3. 식별자 관계와 비식별자 관계

• 엔터티에 주식별자가 지정되고 엔터티간 관계를 연결하면, 자식엔터티에서 부모엔터티로부터 받은 외부식별자를 자신의 주식별자로 이용할 것인지 또는 부모와 연결이 되는 속성으로만 이용할 것인지 결정해야 함

• 식별자 관계 (주식별자로 이용 O)

  • 부모엔터티로부터 받은 외부식별자를 자신의 주식별자로 이용하는 경우 (1:1 관계)
  • 부모엔터티로부터 받은 외부식별자와 본인의 속성과 함께 주식별자로 구성하는 경우(1:M 관계)

• 비식별자 관계 (주식별자로 이용 X)

  • 부모엔터티로부터 받은 외부식별자를 일반적인 속성으로 이용하는 경우
  • 자식엔터티에서 별도의 주식별자를 생성하는 것이 더 유리하다고 판단될 때, 비식별자 관계에 의한 외부식별자로 표현
  • 엔터티별로 데이터 생명주기를 다르게 관리할 경우(부모엔터티가 먼저 소멸될 수 있는 경우)

• 문제점

  • 식별자 관계로만 설정할 때 : 주식별자 속성이 지속적으로 증가하는 구조이므로, 개발자 복잡성과 오류가능성 유발
  • 비식별자 관계로만 설정할 때 : 많은 조인구문 사용에 따른 복잡성 증가, 성능 저하 유발

4. 식별자 관계와 비식별자 관계 모델링

• 적절한 관계모델링은 데이터 모델의 균형감을 준다.

• 비식별자관계 선택 프로세스
  관계의 강/약 분석 (약한 관계 -> 비식별자관계 고려)
  -> 자식테이블 독립PK필요 (독립 PK구성 필요 -> 비식별자관계 고려)
  -> SQL복잡도 증가 / 개발생산성 저하
  -> PK속성 단순화(비식별자관계 고려)
  

• 식별자와 비식별자 관계 비교

  • 	식별자 관계	비식별자 관계
    목적	강한 연결관계	약한 연결관계
    자식엔터티	자식 주식별자의 구성에 포함	자식 일반속성에 포함
    표기법	실선	점선