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

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

1. 모델링(Modeling)

• 모델링 ⭐️⭐️
  데이터베이스의 모델링은 ‘현실 세계를 단순화하여 표현하는 기법’

  • 현실 세계 반영
  • 단순화하여 표현
  • 관리하고자 하는 데이터 모델로 설계

• 모델링 특징 (추단명) ⭐️⭐️

  • 추상화(Abstraction): 현실 세계를 일정한 형식으로 표현, 개념 간략하게 표현
  • 단순화(Simplication): 정해진 표기법으로 단순하고 쉽게 표현
  • 명확화(Clarity): 불분명함 제거, 명확하게 해석할 수 있도록 기술

• 모델링 3가지 관점

  • 데이터 관점(Data, What): 데이터 위주 모델링. 어떤 데이터들이 업무과 얽혀있는지, 그 데이터 간에는 어떤 관계가 있는지에 대해 모델링하는 방법
  • 프로세스 관점(Process, How): 프로세스 위주 모델링. 업무가 실제로 처리하고 있는 일이 무엇인지, 앞으로 처리해야 하는 일이 무엇인지 모델링 하는 방법
  • 데이터와 프로세스 상관 관점(Data vs. Process, Interaction): 데이터와 프로세스의 관계 위주 모델링. 프로세스 흐름에 따라 데이터가 어떤 영향을 받는지 모델링하는 방법

• 모델링 3가지 단계 (개논물) ⭐️⭐️

  • 개념적 데이터 모델링(Conceptual Data Modeling)
    • 전사적 데이터 모델링 수행 시 함
    • 추상화 레벨 가장 높음
    • 업무 중심이고 포괄적인 수준 모델링 진행됨
  • 논리적 데이터 모델링(Logical Data Modeling)
    • 재사용성 가장 높음
    • DB 모델에 대한 키, 속성, 관계 등을 모두 표현하는 단계
  • 물리적 데이터 모델링(Pysical Data Modeling)
    • 실제 DB에 구현할 수 있도록 성능, 가용성 등의 물리적 성격 고려하여 모델 표현하는 단계

• 데이터 독립성 ⭐️⭐️

  • ANSI-SPARC: DBMS의 추상적인 설계 표준. 스키마를 3단계로 분리, 분리하는 이유는 DB에 대한 사용자들의 관점과 DB가 실제로 표현되는 물리적인 방식을 분리하기 위함.
  • 3단계 스키마 구조 (외개내)
    • 외부 스키마(External Schema): 사용자 관점. 각 사용자가 보는 DB 스키마를 정의
    • 개념 스키마(Conceptual Schema): 통합된 관점. 모든 사용자가 보는 DB 스키마를 통합하여 전체 DB를 나타내는 것. DB에 저장되는 데이터들을 표현하고 데이터들 간의 관계 나타냄
    • 내부 스키마(Internal Schema): 물리적 관점. 물리적인 저장 구조 나타냄. 실질적인 데이터의 저장 구조나 컬럼 정의, 인덱스 등
  • 3단계 스키마 구조가 보장하는 독립성
    • 논리적 독립성: 개념 스키마 변경되어도 외부 스키마 영향받지 않음
    • 물리적 독립성: 내부 스키마 변경되어도 외부/개념 스키마 영향받지 않음

• ERD(Entity Relationship Diagram)

  • 시스템에 어떤 엔티티들이 존재하며 그들 간에 어떤 관계가 있는지를 나타내는 다이어그램
  • 표기 방식(https://seb.kr/w/ERD)
    
    
  • IE/Crow’s Foot 표기법
    
    
  • ERD 작성 순서 ⭐️
    1. 엔티티 도출하고 그리기
    2. 엔티티 적절하게 배치
    3. 엔티티 간의 관계 설정
    4. 관계명 기입
    5. 관계의 참여도 기입
    6. 관계의 필수/선택 여부 기입
       
       

• 데이터 모델링 유의사항 ⭐️⭐️

  • 중복: 같은 데이터가 여러 엔티티에 중복으로 저장되는 현상 지양해야 함
  • 비유연성: 데이터 모델의 설계에 따라 어플리케이션의 사소한 변경에도 데이터 모델이 수시로 변경 되어야 하는 상황이 생길 수 있음. 이런 상환은 시스템을 유지보수하는 데에 어려움을 가중시키므로 데이터 모델과 프로세스를 분리하여 유연성을 높이는 것이 바람직함
  • 비일관성: 다른 데이터와의 연관성을 고려하지 않고 일부 데이터만 변경할 수 있기에 데이터 간의 연관 관계에 대해 명확하게 정의해야 함. 데이터 중복이 없는 경우에도 발생할 수 있음

2. 엔티티(Entity)

• 엔티티 ⭐️⭐️

  • DB에서 엔티티는 ‘식별 가능한 객체’
  • 업무에서 쓰이는 데이터를 용도별로 분류한 그룹
  • 엔티티: Table, 인스턴스: Row, 속성: Column

• 엔티티 특징 ⭐️⭐️

  • 업무에서 쓰이는 정보
  • 유니크함을 보장할 수 있는 식별자 있어야 함
  • 2개 이상의 인스턴스 가지고 있어야 함
  • 반드시 속성을 가지고 있어야 함
  • 다른 엔티티와 1개 이상의 관계를 가지고 있어야 함
    • 통계성 엔티티나 코드성 엔티티의 경우 관계 생략 가능

• 엔티티 분류 ⭐️⭐️

  • 유형 vs. 무형 (유개사)

    유형 엔티티	물리적인 형태 존재. 안적정, 지속적 ex) 회원, 상품
    개념 엔티티	물리적인 형태 없음. 개념적 ex) 부서, 학과
    사건 엔티티	행위를 함으로써 발생. 빈번, 통계 자료로 이용 가능 ex) 주문, 이벤트 응모

  • 발생시점 (기중행)

    기본 엔티티	독립적으로 생성됨. 자식 엔티티를 가질 수 있음 ex) 상품, 회원
    중심 엔티티	기본 엔티티로부터 파생. 행위 엔티티 생성 ex) 주문
    행위 엔티티	2개 이상의 엔티티로부터 파생 ex) 주문 내역, 이벤트 응모 이력

    
    

• 엔티티 이름 정할 때 유의할 점 ⭐️⭐️

  • 한글 약어 사용x, 영문은 대문자로 표기
  • 단수 명사로 표현, 띄어쓰기x
  • 다른 엔티티와 의미상으로 중복x
  • 해당 엔티티가 갖고 있는 데이터가 무엇인지 명확하게 표현

3. 속성(Attribute)

• 속성 ⭐️⭐️
  엔티티의 특징을 나타내는 최소의 데이터 단위
  • 의미상 더 이상 쪼개지지 않은 레벨
  • 프로세스에 필요한 항목

• 속성값 ⭐️⭐️
  엔티티에 속한 하나의 인스턴스를 구체적으로 나타내주는 데이터

  • 하나의 속성은 한 개의 속성값만 가질 수 있음
  • 하나의 속성이 여러 개의 속성값을 갖는 경우 → 별도의 엔티티로 분리
    
    

• 속성 분류 ⭐️⭐️

  • 특성에 따른 분류 (기설파)

    기본속성(Basic Attribute)	업무 프로세스 분석을 통해 바로 정의가 가능한 속성
    설계속성(Designed Attribute)	업무에 존재하지는 않지만 설계하다 보니 필요하다고 판단되어 도출해낸 속성
    파생속성(Derived Attribute)	다른 속성의 속성값을 계산하거나 특정한 규칙으로 변형하여 생성한 속성

  • 구성방식에 따른 분류

    PK(Primary Key)속성	엔티티의 인스턴스들을 식별할 수 있는 속성
    FK(Foreign Key)속성	다른 엔티티의 속성에서 가져온 속성
    일반속성	PK, FK를 제외한 나머지 속성

• 도메인(Domain) ⭐️⭐️
  속성이 가질 수 있는 속성값의 범위

  • 엔티티를 정의할 때 데이터 타입과 크기로 나타낼 수 있다.
  • ex1) 우편번호: 다섯 자리 숫자, ex2) 학점: 0.1~4.5 사이의 실수

• 용어사전
  엔티티의 속성명을 정의할 때 명확한 의미의 이름을 부여하고 다른 엔티티와의 혼란을 예방하기 위해 이용하는 것
  

4. 관계(Relationship)

• 관계 ⭐️⭐️
  엔티티와 엔티티와의 관계를 의미

  • 어떠한 연관성이 있는지 타입을 분류하여 존재 관계와 행위 관계로 나눌 수 있음
  • 존재 관계: 존재 자체로 연관성이 있는 관계(실선)
    • 연관관계
    • 소스코드에서 멤버변수로 선언하여 사용
      ex) 직원-부서, 학생-학과
  • 행위 관계: 특정한 행위를 함으로써 연관성이 생기는 관계(점선)
    • 의존관계
    • 오퍼레이션에서 파라미터 등으로 이용
      ex) 회원-주문, 학생-출석부

• 관계 표기법 ⭐️⭐️

  관계명 (Membership)	관계의 이름	・ 엔티티와 엔티티가 어떠한 관계를 맺고 있는지를 나타내주는 문장 ・ 각 엔티티의 관점에서 관계명을 하나씩 가짐 ・ 현재형, 명확한 문장으로 표현
  관계차수 (Cardinality)	관계에 참여하는 수	・ 각 엔티티에서 관계에 참여하는 수 ・ 1:1, 1:M, M:N으로 구분
  관계선택사항(Optionality)	필수인지 선택인지의 여부	・ 필수적 관계(참여자가 반드시 존재해야 하는 관계) ・ 선택적 관계(참여자가 없을 수도 있는 관계

• 엔티티 사이 관계 정의 시 고려사항

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

5. 식별자(Identifiers)

• 식별자 ⭐️
  각각의 인스턴스를 구분 가능하게 만들어주는 속성
  

• 주식별자 ⭐️⭐️

  • 기본키(PK)에 해당하는 속성

  • 하나의 속성이 주식별자가 될 수도 있고, 여러 개의 속성이 주식별자가 될 수도 있음

    유일성	・ 각 인스턴스에 유니크함을 부여하여 식별이 가능하도록 함 ・ 하나의 키값으로 인스턴스를 유일하게 식별할 수 있음
    최소성	유일성을 보장하는 최소 개수의 속성이어야 함 ex) 회원 구분: 주민등록번호, 회원번호 → 2개 두는 건 공간 낭비
    불변성	속성값은 되도록 변하지 않아야 함
    존재성	속성값이 NULL 일 수 없음

• 식별자 분류 ⭐️⭐️

  • 대표성 여부 (주, 보조)

    주식별자(Primary Identifier)	・ 유일성, 최소성, 불변성, 존재성을 가진 대표 식별자 ・ 다른 엔티티와 참조 관계로 연결
    보조식별자(Alternate Identifier)	・ 인스턴스를 식별할 수는 있지만 대표 식별자가 아님 ・ 다른 엔티티와 참조 관계로 연결되지 않음

  • 스스로 생성되었는지 여부 (내, 외부)

    내부식별자(Internal Identifier)	・ 엔티티 내부에서 스스로 생성된 식별자
    외부식별자(External Identifier)	・ 다른 엔티티에서 온 식별자 ・ 다른 엔티티와의 연결고리 역할

  • 단일 속성 여부 (단일, 복합)

    단일식별자(Single Identifier)	・ 하나의 속성으로 구성된 식별자
    복합식별자(Composite Identifier)	・ 두 개 이상의 속성으로 구성된 식별자

  • 대체 여부 (본질, 인조)

    원조/본질식별자(Original Identifier)	・ 업무 프로세스에 존재하는 식별자 ・ 가공되지 않은 원래의 식별자(본질식별자)
    대리/인조식별자(Surrogate Identifier)	・ 주식별자의 속성이 두 개 이상인 경우 그 속성들을 하나로 묶어서 사용하는 식별자(인조 식별자)

• 식별자 관계 vs. 비식별자 관계 ⭐️

  • 식별자 관계(Identification Relationship)
    • 부모 엔티티의 식별자가 자식 엔티티의 주식별자가 되는 관계
    • 주식별자는 반드시 존재해야 하므로 부모 엔티티가 있어야 생성 가능
    • 복합식별자인지에 따라 1:1 또는 1:M
  • 비식별자 관계(Non-Identification Relationship)
    • 부모 엔티티의 식별자가 자식 엔티티의 주식별자가 아닌 일반 속성이 되는 관계
    • 일반 속성의 속성값은 NULL 이 될 수 있으므로 부모 엔티티가 없는 자식 엔티티 생성 가능,자식 엔티티가 존재하는 상태에서 부모 엔티티가 삭제 될 수도 있음