[1과목] Part1. 데이터 모델링의 이해

1) 데이터 모델링의 이해

1. 모델링의 이해

• 모델링의 정의

  현실세계를 추상화, 단순화, 명확화하기 위해 일정한 표기법에 의해 표현하는 기법

• 모델링의 특징

  추상화, 단순화, 명확화

• 모델링의 3가지 관점 ⭐️⭐️⭐️⭐️⭐️

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

• 데이터 모델링의 정의

  업무에 필요로 하는 데이터를 시스템 구축 방법론에 의해 분석하고 설계하여 정보시스템을 구축하는 과정

• 데이터 모델링의 목적

  💡 단지 데이터베이스 만을 구축하기 위한 용도로만 쓰이는 것이 아니라 데이터 모델링 자체로 업무를 설명하고 분석하는 부분에서도 매우 중요

  • 업무 정보를 구성하는 기초가 되는 정보들을 일정한 표기법에 의해 표현 ➡️ 정보시스템 구축의 대상 업무를 정확하게 분석하기 위해 (데이터 관점의 업무 분석 기법)
  • 분석된 모델을 가지고 실제 데이터베이스를 생성하여 개발 및 데이터 관리에 사용하기 위해

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

  • 시스템 가시화
  • 시스템의 구조와 행동을 명세화
  • 시스템을 구축하는 구조화된 틀 제공
  • 시스템을 구축하는 과정에서 결정한 것을 문서화
  • 다양한 관점 제공
  • 특정 목표에 따라 구체화된 상세 수준의 표현방법을 제공

3. 데이터 모델링의 중요성 및 유의점

• 데이터 모델링의 중요성

  파급효과(Leverage), 복잡한 정보 요구사항의 간결한 표현(Conciseness), 데이터 품질(Data Quality)

• 데이터 모델링 유의점

  • 중복(Duplication)

  • 비유연성(Inflexibility)

    💡 사소한 업무변화에도 데이터 모델이 수시로 변경 됨으로써 유지보수의 어려움을 가중시킬 수 있다. (데이터 정의를 데이터 사용 프로세스와 분리)

  • 비일관성(Inconsistency)

    💡 데이터의 중복이 없더라도 발생할 수 있다. (데이터와 데이터간 상호 연관 관계에 대한 명확한 정의 필요)

4. 데이터 모델링 3단계 진행 ⭐️

• 개념적 데이터 모델링 (추상적 ⬆️)
  • 추상화 수준이 높고 업무중심적이고 포괄적인 수준의 모델링
  • 전사적 데이터 모델링, EA 수립 시 많이 이용
• 논리적 데이터 모델링
  • 업무의 구체적인 모습과 흐름에 따른 구체화된 업무중심의 모델
  • 시스템으로 구축하고자 하는 업무에 대해 Key, 속성, 관계 등을 정확하게 표현, 재사용성 높음
• 물리적 데이터 모델링 (구체적 ⬆️)
  • 실제로 데이터베이스에 이식할 수 있도록 성능, 저장 등 물리적인 성격을 고려하여 설계
  • 데이터 타입, 유형, DBMS 특성을 반영하여 최종적으로 실제 데이터 베이스 구축

5. 프로젝트 생명주기에서 데이터 모델링

6. 데이터 모델링에서 데이터 독립성의 이해

• 데이터 독립성의 필요성
  • 유지보수 비용을 절감하고, 데이터 복잡도를 낮추며, 중복된 데이터를 줄이기 위한 목적
  • 사용자의 요구사항에 대해 화면과 데이터베이스간에 서로 독립성을 유지하기 위한 목적
• 데이터 독립성 확보 효과 (↔️ 데이터 종속성)
  • 각 View의 독립성을 유지하고 계층별 View에 영향을 주지 않고 변경이 가능하다.
  • 단계별 Schema에 따라 데이터 정의어(DDL)와 데이터 조작어(DML)가 다름을 제공한다.

ANSI/SPARC 3단계 구조(three-level architecture) ⭐️⭐️⭐️

사용자, 설계자, 개발자가 데이터베이스를 보는 관점에 따라 데이터베이스를 기술하고 이들 간의 관계를 정의한 ANSI 표준

• 외부 스키마 (External Schema)

  사용자 관점, 접근하는 특정에 따른 스키마 구성

  • Multiple User's View
    • View 단계 여러 개의 사용자 관점으로 구성
    • 개개 사용자 단계로서 각각의 사용자가 보는 개인적 DB 스키마
    • DB의 개개 사용자나 응용 프로그래머가 접근하는 DB 정의

  🔥 외부 스키마와 개념 스키마 사이에서는 논리적 독립성을 유지할 수 있다.

  • 내용
    • 개념 스키마가 변경되어도 외부 스키마에는 영향을 미치지 않도록 지원하는 것
    • 논리적 구조가 변경되어도 응용 프로그램에 영향 없음
  • 특징
    • 사용자 특성에 맞는 변경 가능
    • 통합 구조 변경 가능

• 개념 스키마 (Conceptual Schema)

  통합 관점

  • Community View of DB
    • 설계자 관점
    • 모든 사용자 관점을 통합한 조직 전체 관점의 통합적인 표현

  🔥 개념 스키마와 내부 스키마 사이에서는 물리적 독립성을 유지할 수 있다.

  • 내용
    • 내부 스키마가 변경되어도 외부/개념 스키마는 영향을 받지 않도록 지원하는 것
    • 저장장치의 구조변경은 응용프로그램과 개념스키마에 영향 없음
  • 특징
    • 물리적 구조 영향없이 개념 구조 변경 가능
    • 개념 구조 영향없이 물리적인 구조 변경 가능

• 내부 스키마 (Internal Schema)

  물리적 저장구조

  • Physical Representation
    • 개발자 관점
    • 물리적인 저장 구조를 나타내는 것

• 사상(Mapping)

  상호 독립적인 개념을 연결시켜주는 다리를 뜻한다.

  논리적 사상, 물리적 사상

  • 외부적/개념적 사상 (논리적 사상)
    • 사용자가 접근하는 형식에 따라 다른 타입의 필드를 가질 수 있음. 개념적 뷰의 필드 타입은 변화가 없음
  • 개념적/내부적 사상 (물리적 사상)
    • 만약 저장된 데이터베이스 구조가 바뀐다면 개념적/내부적 사상이 바뀌어야 함. 그래야 개념적 스키마가 그대로 남아있게 됨

7. 데이터 모델링의 중요한 세 가지 개념

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

  엔터티, 속성, 관계

  💡 1) 업무가 관여하는 어떤 것(Thing), 2) 어떤 것이 가지는 성격(Attribute), 3) 업무가 관여하는 어떤 것 간의 관계(Relationships)

8. 데이터 모델링의 이해관계자

9. 데이터 모델의 표기법 : ERD

• 데이터 모델 표기법
• ERD 표기법을 이용하여 모델링하는 방법

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

• 완전성
• 중복배제
• 업무규칙
• 데이터 재사용
• 의사소통
• 통합성

2) 엔터티

1. 엔터티의 개념

🚨 해당 업무에 필요하고 유용한 정보를 저장하고 관리하기 위한 집합적인 것 (Thing); 인스턴스의 집합

2. 엔터티

3. 엔터티의 특징 ⭐️⭐️⭐️

• 반드시 해당 업무에서 필요하고 관리하고자 하는 정보이어야 한다.

• 유일한 식별자로 식별 가능해야 한다.

• 영속적으로 존재하는 인스턴스의 집합이어야 한다.

  ('한 개'가 아니라 '두 개 이상')

• 업무 프로세스에 의해 이용되어야 한다.

• 반드시 속성이 있어야 한다.

  • 그 집합에 속하는 개체들의 특성을 설명할 수 있는 속성을 갖는다.

  • 주식별자만 존재하고 일반 속성은 전혀 없는 경우도 적절하지 않다.

    단, 예외적으로 "관계 엔터티"의 경우는 주식별자 속성만 가지고 있어도 엔터티로 인정한다.

• 다른 엔터티와 최소 1개 이상의 관계가 있어야 한다.

  • 관계를 생략하여 표현해야하는 경우
    • 통계성 엔터티(Read Only)
    • 코드성 엔터티
    • 시스템 처리 시 내부 필요에 의한 엔터티
      • 예) 트랜잭션 로그 테이블 등

4. 엔터티 분류 ⭐️

• 유무형에 따른 엔터티 분류

  • 유형 엔터티(Tangible Entity)
    • 물리적인 형태가 있고, 안정적이며 지속적으로 활용되는 엔터티
      • 예시) 고객, 사원, 보험 상품, 강사 …
  • 개념 엔터티(Conceptual Entity)
    • 물리적인 형태는 존재하지 않고 개념적 정보로 구분되는 엔터티
      • 예시) 조직, 프로모션, 보험 상품 …
  • 사건 엔터티(Event Entity)
    • 업무를 수행함에 따라 발생
    • 비교적 발생량이 많고 각종 통계 자료에 활용 가능
      • 예) 주문, 보험 청구, 미납 …

• 발생 시점에 따른 엔터티 분류

  • 기본/키 엔터티(Fundamental Entity, Key Entity)
    • 업무에 원래 존재하는 정보
    • 엔터티와의 관계에 의해 생성되지 않고 독립적으로 생성 가능
    • 타 엔터티의 부모의 역할, 다른 엔터티의 주 식별자를 상속받지 않고 자신의 고유한 주식별자를 갖는다.
      • 예) 사원, 부서, 고객, 상품, 자재
  • 중심 엔터티(Main Entity)
    • 기본 엔터티로부터 발생
    • 업무에서 중심적인 역할
    • 데이터의 양이 많이 발생되고 다른 엔터티와의 관계를 통해 많은 행위 엔터티를 생성한다.
      • 예) 계약, 사고, 청구, 주문, 매출 …
  • 행위 엔터티(Active Entity)
    • 두개 이상의 부모 엔터티로부터 발생되고 자주 내용이 바뀌거나 데이터량이 증가된다.
    • 분석 초기 단계에서는 잘 나타나지 않으며 상세 설계단계나 프로세스와 상관 모델링을 진행하면서 도출될 수 있다.
      • 예) 주문 목록, 사원변경이력 …

• 스스로 생성될 수 있는지 여부

  • 독립 엔터티
  • 의존 엔터티

5. 엔터티의 명명

1. 가능하면 현업업무에서 사용하는 용어를 사용
2. 가능하면 약어를 사용하지 않는다.
3. 단수명사를 사용한다.
4. 모든 엔터티에서 유일하게 이름이 부여되어야 한다.
5. 생성의미대로 이름을 부여한다.

3) 속성(Attribute)

1. 속성의 개념

💡 업무에서 필요로 하는 인스턴스로 관리하고자 하는 의미상 더 이상 분리되지 않는 최소의 데이터 단위

2. 엔터티, 인스턴스와 속성, 속성값에 대한 내용과 표기법

1. 엔터티, 인스턴스, 속성, 속성값의 관계
2. 속성의 표기법
   • IE 표기법
   • Barker 표기법

3. 속성의 특징

• 해당 업무에 필요하고 관리하고자 하는 정보이어야한다.

• 정규화 이론에 근간하여 정해진 주식별자에 함수적 종속성(FD)을 가져야한다.

• 하나의 속성에는 한 개의 값만을 가진다.

  (다중값일 경우 별도의 엔터티를 이용하여 분리)

4. 속성의 분류 ⭐️⭐️

• 속성 특성에 따른 분류

  1. 기본 속성(Basic Attribute)

     • 업무로부터 분석(추출)한 모든 속성

       코드성 데이터, 일련번호, 다른 속성을 계산하거나 영향을 받아 생성된 속성을 제외한 모든 속성

  2. 설계 속성(Designed Attribute)

     • 업무상 필요한 데이터 이외에 데이터 모델링을 위해, 업무를 규칙화하기 위해 속성을 새로만들거나 변형하여 정의하는 속성

       예) 코드성 속성, 일련 번호

       • 코드성 속성: 원래 속성을 업무상 필요에 의해 변형하여 만든 설계속성
       • 일련번호: 단일한 식별자를 부여하기 위해 모델상에서 새로 정의하는 설계속성

  3. 파생 속성(Derived Attribute)

     💡 데이터를 조회할 때 빠른 성능을 낼 수 있도록 하기 위해 원래의 속성의 값을 계산하여 저장할 수 있도록 만든 속성

     • 다른 속성으로부터 계산이나 변형이 되어 생겨나는 속성으로 보통 계산된 값들이 이에 해당된다.

     • 타 속성에 의해 지속적으로 영향을 받기 때문에 프로세스 설계 시 데이터 정합성을 유지하기 위해 유의해야할 점이 많으며 가급적 적게 정의하는 것이 좋다.

       예) 이자: 타 속성(원금, 예치기간, 이자율 등)에 의해 지속적으로 영향을 받아 자신의 값이 변하는 성질을 가진다.

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

  • PK 속성
    • 엔터티를 식별할 수 있는 속성
  • FK 속성
    • 다른 엔터티와의 관계에서 포함된 속성
  • 일반 속성

• 세부 의미를 쪼갤 수 있는지에 따라

  • 단순형(Simple Attribute)
    • 예) 나이, 성별 등
  • 복합형(Composite Attribute)
    • 예) 주소 속성: 시, 구, 동, 번지 등과 같은 여러 세부 속성들로 구성

• 값의 개수에 따라

  • 단일값(Single Value)
    • 예) 주민등록번호
  • 다중값(Multi Value)
    • 예) 전화번호: 집, 휴대전화, 회사 전화번호와 같이 여러 개의 값을 가질 수 있다.

5. 도메인(Domain) ⭐️

💡 각 속성의 가질 수 있는 값의 범위 엔터티 내에서 속성에 대한 데이터타입과 크기 그리고 제약사항을 지정하는 것

6. 속성의 명명(Naming)

• 현업에서 사용하는 이름을 부여한다.

• 일반적으로 서술식 속성명은 사용하지 않는다.

  명사형을 이용하고 수식어가 많이 붙지않도록 유의 (소유격 사용 ❌)

• 약어 사용은 가급적 제한한다.

• 전체 데이터 모델에서 유일성 확보하는 것이 좋다. (데이터 정합성 유지, 안정적인 반정규화 적용)

4) 관계

1. 관계의 개념

• 관계의 정의

  💡 엔터티의 인스턴스 사이의 논리적인 연관성으로서 존재의 형태로서나 행위로서 서로에게 연관성이 부여된 상태(비즈니스적인 연관성)

• 관계의 페어링

  엔터티 내에 인스턴스와 인스턴스 사이의 관계가 설정되어있는 어커런스

  엔터티는 인스턴스의 집합을 논리적으로 표현하였다면 관계는 관계 패어링의 집합을 논리적으로 표현한 것

2. 관계의 분류 ⭐️⭐️⭐️

💡 UML에는 클래스다이어그램의 관계 중 연관관계와 의존 관계가 있다. 즉, ERD에서는 존재적 관계와 행위에 의한 관계를 구분하지 않고 표현했다면 클래스 다이어그램에서는 이것을 구분하여 연관관계와 의존관계로 표현하고 있는 것이다. (연관관계: 실선, 의존관계: 점선)

• 존재에 의한 관계 (행위에 따른 이벤트에 의해 발생 ❌)
  • 예) 부서와 사원의 관계 (존제 자체로 관계 성립)
• 행위에 의한 관계
  • 예) 고객과 주문간의 관계 (주문 시에만 관계 성립)

3. 관계의 표기법

• 관계명 (Relationship Membership) : 관계의 이름
• 관계 차수 (Relationship Degree/Cardinality) : 1:1, 1:M, M:N
• 관계선택사양 (Relationship Optionality)
  • 필수 참여관계 (Mandatory Membership)
    • ERD에서 관계를 나타내는 선에 아무런 표시를 하지 않는다.
  • 선택 참여관계(Optional Membership)
    • ERD에서 관계를 나타내는 선에서 선택 참여하는 엔터티 쪽을 원으로 표시한다.
    • 만약 관계가 표시된 양쪽 엔터티에 모두 선택참여가 표시된다면, 즉 0:0(Zero to Zero)의 관계가 된다면 그 관계는 잘못될 확률이 많으므로 검토 필요
    • 선택참여된 항목은 물리속성에서 Foreign Key로 연결될 경우 Null을 허용할 수 있는 항목이 된다.
    • 만약 선택참여로 지정해야 할 관계를 필수참여로 잘못 지정하면 애플리케이션에서 데이터가 발생할 때 반드시 한 개의 트랜잭션으로 제어해야 하는 제약사항이 발생

4. 관계의 정의 및 읽는 방법

• 관계 체크사항 ⭐️⭐️

  • 두 개의 엔터티 사이에 관심있는 연관규칙이 존재하는가?
  • 두 개의 엔터티 사이에 정보의 조합이 발생되는가?
  • 업무기술서, 장표에 관계연결에 대한 규칙이 서술되어 있는가?
  • 업무기술서, 장표에 관계연결을 가능하게 하는 **동사(Verb)**가 있는가?

• 관계 읽기

  1. 기준(Source) 엔터티를 한 개(One) 또는 각(Each)으로 읽는다.
  2. 대상(Target) 엔터티의 관계참여도 즉 개수(하나, 하나 이상)를 읽는다.
  3. 관계선택사양과 관계명을 읽는다.

5) 식별자

1. 식별자(Identifiers) 개념

💡 각각을 구분할 수 있는 논리적인 이름 여러 개의 속성 중에 엔터티를 대표할 수 있는 속성 엔터티 내에서 인스턴스들을 구분할 수 있는 구분자이다.

2. 식별자의 특징

• 주식별자의 특징 ⭐️⭐️⭐️⭐️⭐️

  • 유일성
  • 최소성
  • 불변성
  • 존재성 (반드시 데이터 값이 존재 / Not Null)

• 외부식별자 특징

  💡 주식별자의 특징과 일치하지 않으며 참조무결성 제약조건(Referential Integrity)에 따른 특징을 가지고 있다.

3. 식별자의 분류 및 표기법 ⭐️⭐️⭐️

• 식별자 분류

  • 대표성 여부
    • 주식별자 : 타엔터티와 참조관계 연결 가능
    • 보조식별자 : 대표성을 가지지 못해 참조관계 연결 불가능
  • 스스로 생성 여부
    • 내부 식별자
    • 외부 식별자 : 타엔터티와의 관계를 통해 받아오는 식별자
  • 속성의 수
    • 단일 식별자
    • 복합 식별자
  • 대체 여부
    • 본질 식별자 : 업무에 의해 만들어지는 식별자
    • 인조 식별자 : 업무적으로 만들어지지는 않지만 원조 식별자가 복잡한 구성을 가지고 있기 때문에 인위적으로 만든 식별자

• 식별자 표기법

4. 주식별자 도출기준

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

5. 식별자 관계와 비식별자 관계에 따른 식별자

• 식별자 관계와 비식별자 관계의 결정

• 외부 식별자(Foreign Identifier)

  • 자기 자신의 엔터티에서 필요한 속성이 아니라 다른 엔터티와의 관계를 통해 자식 쪽 엔터티에 생성되는 속성
  • 데이터베이스 생성 시에 Foreign Key 역할을 한다.
  • 부모 엔터티로부터 받은 외부 식별자를 자신의 주식별자로 이용할 것인지 또는 부모와 연결이 되는 속성으로서만 이용할 것인지를 결정해야 한다.

• 식별자 관계(Identifying Relationship)

  💡 자식 엔터티의 주식별자로 부모의 주식별자가 상속이 되는 경우

  • 부모로부터 받은 속성만을 주식별자로 이용하는 경우 ➡️ 1:1 관계
  • 부모로부터 받은 속성을 포함하여 함께 구성되는 경우 ➡️ 1:M 관계

• 비식별자 관계(Non-Identifying Relationship)

  💡 부모 엔터티로부터 속성을 받았지만 자식 엔터티의 주식별자로 사용하지 않고 일반적인 속성으로만 사용하는 경우

  1. 자식 엔터티에서 받은 속성이 반드시 필수가 아니어도 무방하기 때문에 부모 없는 자식이 생성될 수 있는 경우
  2. 엔터티별로 생명주기(Life Cycle)를 다르게 관리할 경우
  3. 여러 개의 엔터티가 하나의 엔터티로 통합되어 표현되었는데 각각의 엔터티가 별도의 관계를 가질 때
  4. 자식 엔터티에 주식별자로 사용하여도 되지만 자식 엔터티에서 별도의 주식별자를 생성하는 것이 더 유리하다고 판단될 때

• 식별자 관계로만 설정할 경우의 문제점

• 비식별자 관계로만 설정할 경우의 문제점

• 식별자 관계와 비식별자 관계 모델링

  • 비식별자 관계 선택 프로세스
  • 식별자와 비식별자 관계 비교

• 식별자와 비식별자를 적용한 데이터 모델