상세 컨텐츠

본문 제목

[SQLD기본 개념]PART1. 데이터 모델링의 이해-제1장 데이터 모델링의 이해

SQLD기본개념

by qkrtnals 2024. 5. 12. 01:01

본문

1. 데이터 모델링의 이해
모델링 : 현실 세계를 단순화하여 표현하는 기법

모델링이 갖춰야하는 조건

  • 현실 세계 반영
  • 단순화하여 표현
  • 관리하고자 하는 데이터를 모델로 설계 현실 세계에서 필요한 데이터를 저장하는 데이터 베이스를 구축하기 위한 분석/ 설계의 과정

    모델링의 특징
  1. 추상화 : 현실 세계를 일정한 형식으로 표현하는 것 즉 , 아이디어나 개념을 간략하게 표현
  2. 단순화 : 복잡한 현실 세계를 정해진 표기법으로 단순하고 쉽게 표현
  3. 명확화 : 불분명함을 제거하고 명확하게 해석할 수 있도록 기술한다는 의미

모델링의 세가지 관점

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

데이터의 품질을 보장하기 위해 유의해야할점

중복 : 같은 데이터가 여러 엔티티에 중복으로 저장되는 현상 지양
비유연성 : 데이터 모델과 프로세스를 분리하여 유연성을 높이는 것이 바람직
비일관성 : 데이터의 중복이 없는 경우에도 비일관성 발생, 데이터 모델링을 할 때 데이터 간의 연관 관계에 대해 명확하게 정의

 

모델링의 세가지 단계 

  1. 개념적 데이터 모델링 : 전사적 데이터 모델링 수행 시 행해지며 추상화 레벨이 가장 높은 모델링, 업무 중심적이고 포괄적인 수준의 모델링
  2. 논리적 데이터 모델링 : 재사용성이 가장 높은 모델링으로 데이터베이스 모델에 대한 key, 속성, 관계 등을 모두 표현하는 수준의 모델링
  3. 물리적 데이터 모델링 : 실제 데이터 베이스로 구현할 수 있도록 성능이나 가용성 등의 물리적 성격을 고려하여 모델링 

데이터 독립성

데이터베이스에 대한 사용자들의 관점과 데이터베이스가 실제로 표현되는 물리적 방식을 분리하기 위함

 

3단계 스키마 구조

  • 외부 스키마
    사용자의 관점 : Multiple User’s View 단계로 각 사용자가 보는 데이터베이스의 스키마를 정의
  • 개념 스키마
    통합된 관점 : Community View of DB단계로 모든 사용자가 보는 데이터 베이스의 스키마를 통합하여 전체 데이터베이스를 나타냄. 데이터 표현 및 관계 나타냄
  • 내부 스키마
    물리적 관점 : Physical Representation단계로 물리적인 저장 구조 나타냄. 실질적인 데이터의 저장 구조나 칼럼 정의, 인덱스 등이 포함 

 3단계 스키마 구조가 보장하는 독립성

  • 논리적 독립성 : 개념 스키마 변경 → 외부 스키마 영향 X
  • 물리적 독립성 : 내부 스키마 변경 → 외부/개념 스키마 영향 X

    ERD : Entity Relationship Diagram

ERD작성순서

  1. 엔티티 도출 + 그림
  2. 엔티티 적절히 배치
  3. 엔티티 간의 관계 설정
  4. 관계명 기입
  5. 관계의 참여도 기입
  6. 관계의 필수/ 선택 여부 기입

2. 엔티티

엔티티란? : 사전적인 의미는 독립체 , 데이터 베이스에서 엔티티는 식별이 가능한 객체라는 의미를 가지고 있음
엔티티 : Table
인스턴스 : Row
속성 : Column
각각의 엔티티는 자신을 상세하게 나타내기 위해 속성을 갖게 됨


엔티티의 특징

  • 업무에서 쓰이는 정보
    : 실질적으로 업무에서 쓰이는 정보여야 엔티티로 도출하는 의미가 있었음
  • 유니크함을 보장할 수 있는 식별자가 있어야함
    : 엔티티에 속한 각각의 인스턴스가 중복되거나 식별이 모호하면 이 엔티티는 설계가 잘못된 것
  • 2개 이상의 인스턴스를 가지고 있어야함
  • 반드시 속성을 가지고 있어야 함
    : 자신을 자세히 설명할 수 있는 속성을 가지고 있어야함
  • 다른 엔티티와 1개 이상의 관계를 가지고 있어야 함
    : 각각의 엔티티는 다른 엔티티와의 연관성을 가지고 있어야함

엔티티의 분류

  1. 유형 vs 무형
  • 유형 엔티티 : 물리적인 형태 존재, 안정적, 지속적
  • 개념 엔티티 : 물리적인 형태 없음, 개념적
  • 사건 엔티티 : 행위를 함으로써 발생 , 빈번함, 통계 자료로 이용 가능
  1. 발생 시점
  • 기본 엔티티 : 업무에 원래 존재하는 정보 : 독립적으로 생성 , 자식 엔티티 가질 수 O
  • 중심 엔티티 : 기본 엔티티로부터 파생되고 행위 엔티티 생성 : 업무에 있어서 중심적인 역할을 하며 데이터의 양이 많이 발생
  • 행위 엔티티 : 2개 이상의 엔티티로부터 파생 : 데이터가 자주 변경되거나 증가할 수 있음

엔티티의 이름을 정할 때 주의할점

  • 업무에서 실제로 쓰이는 용어 사용
  • 한글을 약어를 사용하지 않고 영문은 대문자
  • 단수 명사로 표현 띄어쓰기는 X
  • 다른 엔티티와 의미상 중복 X
  • 해당 엔티티가 갖고 있는 데이터가 무엇인지 명확하게 표현
  1. 속성

속성이란 ?
: 개념의 특징을 설명해줄 수 있는 항목들 : 쪼개지지 않는 레벨이어야 하고 프로세스에 필요한 항목


속성값
: 각각의 속성은 속성값을 가지며 속성값은 엔티티에 속한 인스턴스를 구체적으로 나눠주는 데이터
: 하나의 속성은 한 개의 속성값만 가짐
: 하나의 속성이 여러개의 속성값을 가지는 경우 별도의 엔티티로 분리하는 것이 바람직


엔티티 인스턴스 속성 속성값의 관계

  • 한 개의 엔티티는 두 개 이상의 인스턴스
  • 한 개의 인스턴스는 두 개 이상의 속성 포함
  • 한 개의 속성은 하나의 속성값 포함

분류
1) 특성에 따른 분류
-기본속성
: 업무 프로세스 분석을 통해 바로 정의가 가능한 속성
→ 엔티티의 가장 일반적인 속성
-설계 속성
: 업무에 존재하진 않지만 설계하다 보니 필요하다고 판단되어 도출해낸 속성
→ 예를 들어 다른 인스턴스의 속성값과 중복될 수 있고 이런 이유로 유니크함을 보장하지 못할때 적용
-파생 속성
: 다른 속성의 속성값을 계산하거나 특정한 규칙으로 변형하여 생성한 속성
→ 계산된 값이나 가공된 값이 이에 속함
→ 반드시 데이터의 정합성이 고려되고 계산과정에서 누락되는 데이터가 없도록 해야함
2) 구성방식에 따른 분류

  • PK 속성 (Primary Key)
    : 엔티티의 인스턴스들을 식별할 수 있는 속성
    → 엔티티에 속한 각 인스턴스에 유니크함을 부여하는 속성
  • FK속성(Foreign Key)
    : 다른 엔티티의 속성에서 가져온 속성
    → 다른 엔티티와 관계를 맺게 해주는 매개체 역할을 하는 속성
  • 일반 속성
    : PK,FK을 제외한 나머지 속성

도메인
: 속성이 가질 수 있는 속성값의 범위
용어 사전
: 속성의 이름을 정확하면서도 직관적으로 부여하고 용어의 혼란을 없애기 위해 사용
시스템 카탈로그
: 사용자 테이블과는 별개로 시스템 자체에 관련이 있는 데이터를 담고 있는 데이터 베이스
: 시스템 테이블로 구성되어있어 SQL을 이용하여 조회 가능
: 시스템 카탈로그에 저장된 데이터 → 메타 데이터
: SELECT만 가능

4. 관계

관계란?
: 엔티티와 엔티티와의 관계를 의미

존재 관계
: 존재 자체로 연관성이 있는 관계를 의미
ex) 직원과 부서, 학생과 학과

행위 관계
: 특정한 행위를 함으로써 연관성이 생기는 관계
ex) 회원과 주문, 학생과 출석부

표기법

  • 관계명 : 관계의 이름
    → 엔티티와 엔티티가 어떠한 관계를 맺고 있는지 나타내는 문장
    → 모든 관계는 두개의 관계명을 가짐 ⇒ 각 엔티티의 관점에서 관계명을 하나씩 가짐
    → 관계명은 반드시 명확한 문장으로 표현 + 현재형
  • 관계차수 : 관계에 참여하는 수
    → 각 엔티티에서 관계에 참여하는 수를 의미하며 일반적으로 1:1 , 1:M, M:N
  • 관계선택사양 : 필수인지 선택인지의 여부
    → 필수적 관계 : 참여자가 반드시 존재해야 하는 관계
    → 선택적 관계 : 참여자가 없을 수도 있는 관계
  1. 식별자

식별자란?
: 모든 엔티티는 인스턴스를 가지고 있고 인스턴스는 속성으로 자신의 특성을 나타내는데 이런 속성 중 각각의 인스턴스를 구분가능하게 만들어주는 대표적인 속성

주식별자
: 기본키,PK(Primary Key)에 해당하는 속성
: 하나의 속성이나 여러 개의 속성이 주식별자가 될 수 있음

주식별자의 특징

  • 유일성
    : 각 인스턴스에 유니크함을 부여하여 식별이 가능하도록 함
  • 최소성
    : 유일성을 보장하는 최소 개수의 속성이어야 함
  • 불편성
    : 속성값이 되도록 변하지 않아야함
  • 존재성
    : 속성값이 NULL일 수 없음

주식별자의 분류

1) 대표성 여부

  • 주식별자
    : 유일성, 최소성,불변성,존재성을 가진 대표 식별자
  • 보조식별자
    : 인스턴스를 식별할 수는 없지만 대표 식별자가 아님 : 다른 엔티티와 참조 관계로 연결 X

    2) 스스로 생성되었는지 여부
  • 내부 식별자
    : 엔티티 내부에서 스스로 생성된 식별자
  • 외부 식별자
    : 다른 엔티티에서 온 식별자, 다른 엔티티와의 연결고리 역할

    3) 단일 속성의 여부
  • 단일 식별자
    : 하나의 속성으로 구성된 식별자
  • 복합 식별자
    : 두 개 이상의 속성으로 구성된 식별자

    4) 대체 여부
  • 원조 식별자(→본질 식별자)
    : 업무 프로세스에 존재하는 식별자, 가공 X
  • 대리 식별자(→인조 식별자)
    : 주식별자의 속성이 두 개 이상인 경우 그 속성들을 묶어서 사용하는 식별자

식별자 관계
: 부모 엔티티의 식별자가 자식 엔티티의 주식별자가 되는 관계
: 주식별자는 반드시 존재해야하므로 부모 엔티티가 있어야 생성 가능

비식별자 관계
: 부모 엔티티의 식별자가 자식 엔티티의 주식별자가 아닌 일반 속성이 되는 관계
: 일반 속성의 속성값은 NULL이 될 수 있으므로 부모 엔티티가 없는 자식 엔티티 생성 가능
: 마찬가지의 이유로 자식 엔티티가 존재하는 상태에서 부모 엔티티가 삭제될 수도 있음

관련글 더보기