SQLD - Week 1 - Part1 - CH1. 데이터 모델링의 이해

• 책 <2023 유선배 SQL개발자(SQLD) 과외노트>로 기본 이론 단권화
• 유튜브 <홍쌤의 데이터랩>, 강의자료 단권화
• 참고 : 블로그 myminju

데이터 모델

정의

• 현실 세계를 단순화/추상화하여 표현하는 기법
• 현실세계에서 필요한 데이터를 저장한 DB 구축을 위한 분석/설계 과정
  • but, 데이터베이스 구축만이 목적은 아님
• 분석한 모델로 DB를 생성해 개발 및 데이터관리에 사용하기 위함
• 데이터모델링 자체로도 업무를 설명하고 분석하므로 중요한 의미를 가짐

조건 - 특징

• 현실세계 반영 : 추상화
• 표현 단순화 : 단순화
• 관리하고자 하는 데이터를 모델로 설계 : 명확화

데이터 모델링 유의점

• 중복 (duplication) : 한 테이블 또는 여러 테이블에 같은 정보를 저장하지 않도록 설계
• 비유연성 (inflexibility) : 사소한 업무 변화에 대해서 잦은 모델 변경이 되지 않도록 주의
  • 데이터 정의를 프로세스와 분리
• 비일관성 (inconsistency) : 데이터베이스 내의 정보가 모순되거나 상반된 내용을 갖지 않도록 주의
  • 데이터간 상호연관 관계를 명확히 정의
  • 데이터 품질 관리 필요
  • 데이터의 중복이 없더라도 비일관성은 발생가능

요소

• 완전성 : 업무에 필요한 모든 데이터가 모델에 정의되어있음
• 중복 배제 / 통합성 : 하나의 DB에는 동일한 사실은 한번만
• 업무규칙 : 많은 규칙을 사용자가 공유하도록 제공
• 데이터 재사용 : 데이터가 독립적으로 설계되어 재사용 가능
• 의사소통 : 업무규칙은 엔터티, 서브타임, 속성, 관계 등의 형태로 최대한 자세히 표현

관점

1. 데이터 관점 : 데이터가 어떤 업무와 얽혀있는지, 데이터간 어떤 상관관계가 있는지에 대해 모델링
2. 프로세스 관점 : 업무가 어떤 일을 처리하는지, 앞으로 처리할 일은 무엇인지에 대해 모델링
3. 데이터-프로세스의 상관관점 : 프로세스 흐름에 따라 데이터가 어떤 영향을 받는지에 대해 모델링

단계

1. 개념적 데이터 모델링 : 업무 분석후 핵심 엔터티(entity)를 추출하는 단계
   • 추상화 수준이 가장 높음
   • 업무중심적으로 포괄적으로 진행
   • 도출된 핵심 엔터티들과의 관계를 표현하기 위해 ERD 작성
2. 논리적 데이터 모델링 : 개념적 모델링의 결과를 토대로 세부속성, 식별자, 관계 등을 표현하는 단계
   • 재사용성이 가장 높음
   • 데이터 정규화 수행
3. 물리적 데이터 모델링 : 논리 모델링이 끝나면 직접 물리적으로 생성하는 단계
   • 실제 구현하기 위한 성능, 가용성을 고려해서 설계
   • 가장 구체적인 데이터 모델링(추상화 수준이 가장 낮음)

관계형 데이터 모델링상 데이터 구조

• 열은 유일한 이름을 가져야 함
• 1정규형 : 열은 하나의 값을 가져야 함
• 도메인 무결성 : 열의 값은 비슷한 형식이어야 함
• 엔터티 무결성 : 행은 유일하게 구분할 수 있어야 함
• 행과 열의 순서는 무의미함

3단계 스키마 구조

• ANSI-SPARC에서 정의한 3단계 스키마 구조 1) 외부 스키마 : View 단계로 여러 사용자 관점으로 구성된 개인적 DB 스키마 2) 개념 스키마 : 모든 사용자 관점을 통합한 전체 DB - 위 두 단계에서 논리적인 데이터 독립성을 고려 3) 내부 스키마 : 물리적인 저장구조 - 데이터 저장구조, 컬럼 정의, 인덱스 등

• 특징 : 데이터 독립성 보장

  • 논리적 독립성 : 개념 스키마 변경 -> 외부 스키마 영향 X
    • 논리적인 구조가 변경되어도 응용프로그램 영향도는 X
    • 사용자 특성에 맞게 변경 가능, 통합 구조의 변경도 가능
  • 물리적 독립성 : 내부 스키마 변경 -> 외부/개념 스키마 영향 X
    • 데이터베이스 파일 구조의 변화가 논리스키마에 영향을 주지 X
    • 데이터베이스 색인구조 변화가 응용프로그램에 영향을 주지 X

Entity 엔터티

ERD(Entity Relationship Diagram)

• 테이블 간 서로의 상관 관계를 그림으로 표현한것
• 구성요소
  • 엔터티(Entity) : 업무가 관리하고자 하는 대상(객체)
  • 속성(Attribute) : 대상들이 갖는 속성(하나의 특징으로 정의될수 있는것)
  • 관계(Relationship) : 대상들 간의 관계
• IE / Crow’s Foot(Barker) 기법을 주로 사용
• 작성순서
  • entity 도출하고 그리기
  • 엔터티 배치
  • 엔터티간의 관계 설정
  • 관계명 기술
  • 관계 참여도 기입
  • 관계의 필수여부 기입
• 특징 : 존재에 의한 관계-행위에 의한 관계를 구분하지 않고 표현

Entity 정의

• 독립체 ; 데이터를 용도별로 분류한 그룹
• 업무에 필요하고 유용한 정보를 저장/관리하기 위한 집합, 보이지않는 개념 포함
• 인스턴스의 집합
  • table: entity / row: instance(인스턴스) / column: property (속성) / identifier (식별자)

특징

• 업무에서 쓰이는 정보
• 유니크함을 보장하는 식별자가 있어야함
• 2개 이상의 인스턴스를 가지고 있어야함
  • 해당 엔터티에 인스턴스가 1개만 존재할 예정이라면 엔터티로 만들필요 없음
• 반드시 속성을 가져야함
  • 각 엔터티는 2개 이상의 속성을 가짐
  • 하나의 인스턴스는 1개의 속성을 가짐
• 다른 엔터티와 1개 이상의 관계를 가져야함

종류

• 독립 엔터티 : 사람, 물건, 장소 등과 같이 현실세계에 존재하는 엔터티
• 업무중심 엔터티 : Transcation이 실행되면서 발생하는 엔터티
• 종속 엔터티 : 주로 1차 정규화로 인해 관련 중심 엔터티로부터 분리된 엔터티
• 교차 엔터티 : M:N 관계를 해소하기 위한 목적으로 만들어진 엔터티(e.g. M:N → 1:N)

분류

• 유형 vs 무형
  • 유형 : 물리적인 형태 존재(실체가 있는 대상)
    • 상품, 회원, 사원
  • 개념 : 개념적 정보
    • 부서, 학과, 조직, 보험상품
  • 사건 : 업무/행위를 함으로써 발생 -통계자료로 이용가능
    • 주문, 이벤트 응모
• 발생시점 : 기본 -> 중심 -> 행위
  • 기본 : 독립적으로 생성됨, 고유한 주식별자를 가짐
    • 업무에 원래 존재하는 정보
    • 자식 엔터티를 가질수 있음
      • 상품, 회원
  • 중심 : 기본 엔터티에서 파생, 행위 엔터티를 생성
    • 업무에서 핵심 역할을 함
    • 데이터 양이 많이 발생
      • 주문, 매출, 계약
  • 행위 : 2개 이상의 엔터티에서 파생
    • 자주 내용이 바뀌거나 데이터 양이 증가
    • 분석 초기 단계보다 상세 설계단계/프로세스와 상관모델링을 진행하면서 도출
      • 주문내역, 이벤트 응모 이력

엔터티 명명 주의사항

• 업무에서 실제로 사용하는 용어 사용
• 한글 약어X, 영문 대문자 표기
• 단수명사 사용
• 띄어쓰기X
• 다른 엔터티와 의미상으로 중복X(주문, 결제 엔터티는 중복O) => 용어사전 활용

속성

• 엔터티의 특징을 나타내는 최소의 데이터 단위 : ‘컬럼’으로 표현할수 있는 단위
• 더이상 분리되지 않는 최소한의 데이터 단위
• 인스턴스 구성요소
  • 1개 엔터티 - 2개 이상의 인스턴스 집합
  • 1개 인스턴스 - 2개 이상의 속성을 가짐
  • 1개 속성 - 1개의 속성값을 가짐(원자성)
    • 참고) 원자성 : 인스턴스가 해당 속성에 대해 단일하고 명확한 값을 가진다.
• 특징
  • 정해진 주식별자에 함수적 종속성을 가져야함

분류

• 특성에 따른 분류
  • 기본 속성 Basic Attribute : 업무 프로세스 분석을 통해 바로 정의가 가능한 속성
    • 대부분의 속성이 여기에 해당
  • 설계 속성 Designed Attribute : 업무에 존재하지않지만 설계하다보니 필요하다고 판단되어 도출해낸 속성
    • 합리적인 모델링을 위해 추가
    • 유니크한 식별자 (일련번호)
    • e.g. 학생 엔터티에 ‘이름, 학과, 학년’ 속성 존재 -> 인스턴스 값이 중복될수 있음
      • ‘학번’ 추가
  • 파생 속성 Derived Attribute : 다른 속성의 속성값을 게산하거나 특정한 규칙으로 변형하여 생성한 속성
    • 빠른 성능을 낼수 있도록 원래 속성의 값을 계산 (계산된 값, 총 개수)
    • 적을수록 좋음
• 구성방식에 따른 분류
  • PK(Prime Key) 속성 : 기본키
    • 각 인스턴스에 유니크함을 부여
    • 상품코드, 회원번호, 사번
  • FK(Foreign Key) 속성 : 외래키
    • 다른 엔터티와 관계를 맺게 해주는 매개체 역할
      • 다른 엔터티의 PK값과 일치하거나 NULL 값일수도 있음
    • 부서코드, 학과코드, 회원등급코드
  • 일반속성 : PK, FK 제외한 나머지 속성
    • 상품명, 이름, 생년월일

속성명 부여 주의사항

• 해당 업무에서 사용하는 이름 부여
• 서술식 속성명은 사용X
• 약어 사용은 가급적 제한
• 전체 데이터 모델에서 유일성 확보

도메인

• 속성값의 범위
  • 각 속성이 가질수 있는 값의 범위
• 데이터타입, 크기, 제약사항 지정

관계

정의

• 엔터티-엔터티 간의 관계
• 존재관계 : 존재 자체로 연관성 있는 관계
  • 학생-학과, 직원-부서
• 행위관계 : 특정 행위를 함으로써 연관성이 생기는 관계
  • 회원-주문, 학생-출석부
• ERD에서는 존재관계, 행위관계를 구분하지 않음

표기법

1) 관계명(Membership) : 관계의 이름 - 엔터티가 서로 어떤 관계를 맺고 있는지 나타냄 - 모든 관계는 두 개의 관계명을 가짐 -> 각 엔터티의 관점에서 하나씩 가짐 - 명확한 문장으로 ‘현재형’으로 표현해야함 2) 관계차수(Cardinality) : 관계에 참여하는 수 - 1:1, 1:N, M:N 3) 관계선택사양(Optionality) : 필수/선택 여부

관계 - 차수 - 페어링 차이

• 차수 : 하나의 엔터티와 다른 엔터티 간의 레코드 연결 방식
• 관계의 페어링 : 두 엔터티 간의 특정 연결을 설명
• 예)
  • 학생과 강의 엔터티는 ‘관계’를 가짐
  • 한 학생은 여러 강의 수강 가능, 한 강의도 여러 학생에게 수강될수 있음 → 차수 - M:N
  • 인스턴스 관계를 보면 ‘학생 A가 강의 B를 2023년 1학기 수강, 성적은 A+을 받았다’와 같은 특정한 페어링을 형성

두 엔터티 사이의 관계를 도출할때 확인해야할 사항

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

식별자

• 하나의 엔터티에 구성된 여러 개 속성중에 엔터티를 대표할 수 있는 속성
• 논리모델링 : 식별자 / 물리모델링 : 키
• 각 인스턴스를 구분 가능하게 만드는 속성
• 역할
  • 정규화 수행의 결정자
  • 종속자 도출하는 결정자
• 조건
  • NOT NULL
  • UNIQUE
  • 최소 속성으로 구성
• SQL문의 조인 관계를 최소화 하는 경우 식별자 관계로 연결해야함

식별자의 무결성

• 엔터티 무결성 : 엔터티는 행을 유일하게 구분할수 있어야 함
• 도메인 무결성 : 열의 값은 비슷한 형식이어야함
• 참조 무결성 : Primary/Foreign Key 제약 조건
• 사용자정의 무결성 : 단가 X 수량 = 금액 등과 같은 업무 규칙에 의해 정의

주식별자

• 기본키/PK(Primary Key)에 해당하는 속성
  • 유일성 : 주식별자가 각 인스턴스에 유니크함을 부여, 구분지음
  • 최소성 : 유일성을 보장하는 최소 개수여야함
  • 불변성 : 한번 할당되면 변하지 않아야함
  • 존재성 : NULL 불가

분류

• 대표성 여부 : 주식별자 Primary Identifier / 보조식별자 Alternate Identifier
• 스스로 생성여부 : 내부식별자 Internal Identifier / 외부식별자 Foreign Identifier
• 속성의 수 : 단일식별자 Single Identifier / 복합식별자 Composite Identifier
• 대체 여부 : 원조식별자(본질식별자) Original Identifier / 대리식별자(인조식별자) Surrogate Identifier

본질식별자 vs 인조식별자

1) 본질식별자

• 업무에 의해 만들어지는 식별자(꼭 필요한 식별자)

2) 인조식별자

• 인위적으로 만들어지는 식별자 (꼭 필요하지 않지만 관리의 편이성 등의 이유로 인위적으로 만들어지는 식별자)
  • 본질식별자가 복잡한 구성을 가질때 인위적으로 생성(후보 식별자중 PK로 선정할 만한게 없을때)
  • 꼭 필요한 경우에만 사용을 권장
• 주로 각 행을 구분하기 위한 기본키로 사용
  • 자동으로 증가하는 일련번호 같은 형태
  • e.g. 매매 엔터티의 매매번호
• 장점 : SQL이 간단해짐
• 단점
  • 인스턴스 생성기준을 인조식별자만으로 판단하기 어려움
  • 모델만 보고 업무를 이해하기 어려움
    • 특히 행위엔터티에서 가독성 저하
  • 유니크 인덱스를 추가로 사용해서 추가로 키를 관리해야함
  • 중복 데이터로 인한 품질 문제 발생
• 아래의 경우엔 인조식별자 사용이 better!
  • 복합키 변경이 빈번할 때
  • AUTO-INCREMENT 컬럼에서 보조 인덱스 필요, PK 크기가 같을떄
  • 복합키가 4개 이상일 때

비식별자

• 약한 연결관계 표현
• 자식 일반 속성에 포함됨
• 점선으로 표현
• 연결 고려사항
  • 약한 종속관계
  • 자식 주식별자 구성을 독립적으로 구성
  • 자식 주식별자구성에 부모 주식별자 부분 필요
  • 상속받은 주식별자 속성을 타 엔터티에 차단 필요
  • 부모쪽의 관계참여가 선택관계

SQL Structured Query Language

• 구조적이고
• 집합적이고
• 선언적인 질의 언어
• 비절차적 언어