SQLD 데이터 모델링의 이해

아니·2024년 5월 20일
0

한걸음 두걸음

목록 보기
3/4
post-thumbnail

Intro

SQLD 시험이 5일도 안남았다!

다시 한 번 정리해보자 😎👍

벼락맞기 여러분 모두 화이팅~!!

데이터 모델의 이해

모델

현실 세계에서 일어날 수 있는 다양한 현상을 일정한 표기법에 의해 표현해놓은 모형

모델링

현실 세계를 추상화, 단순화, 명확화하여 표현하는 기법

모델링의 특징

  • 추상화
    • 현실 세계를 일정한 현식으로 표현
    • 아이디어나 개념을 간략하게 표현
  • 단순화
    • 복잡한 현실 세계를 정해진 표기법으로 단순하고 쉽게 표현
  • 명확화
    • 불분명함을 제거하고 명확하게 해석할 수 있도록 기술

모델링의 세가지 관점

  • 데이터 관점
    • 데이터 위주의 모델링
    • 데이터가 얽혀있는 업무와 데이터 간의 관계에 대해 모델링
  • 프로세스 관점
    • 프로세스 위주의 모델링
    • 이 업무의 현재와 미래에 대해 모델링
  • 데이터와 프로세스의 상관 관점
    • 데이터와 프로세스의 관계를 위주로 한 모델링
    • 프로세스의 흐름에 따라 데이터가 받는 영향에 대해 모델링

모델링의 세가지 단계

  • 개념적 데이터 모델링
    • 추상화 레벨이 가장 고점
    • 업무 중심적이고 포괄적인 수준의 모델링이 진행
  • 논리적 데이터 모델링
    • 재사용성이 가장 높은 모델링
    • 모델에 대한 Key, 속성, 관계 등을 모두 표현
  • 물리적 데이터 모델링
    • 실제 데이터베이스로 옮기는 단계
    • 성능과 가용성 등의 물리적인 성격 고려

데이터

데이터의 품질

  • 중복
    • 같은 데이터가 엔티티에 중복으로 저장되는 현상을 지양
  • 비유연성
    • 애플리케이션의 사소한 변경에 데이터 모델이 자주 변경되는 것을 지양
    • 데이터 모델과 프로세스를 분리하여 유연성을 높임
  • 비일관성
    • 연관성을 고려하지 않고 데이터를 변경할 가능성
    • 데이터 간의 연관 관계에 대해 명확하게 정의 지향

데이터의 독립성

  • ANSI-SPARC

    • DBMS의 추상적 설계 표준
  • 3단계 스키마 구조

    • 외부 스키마
      • 각 사용자가 보는 데이터베이스의 스키마를 정의
    • 개념 스키마
      • 모든 사용자가 보는 데이터베이스의 스키마를 통합
      • 데이터베이스에 저장되는 데이터 들을 표현하고 데이터 간의 관계를 나타냄
    • 내부 스키마
      • 물리적인 저장 구조
      • 실질적인 데이터의 저장 구조, 컬럼 정의, 인덱스 등이 포함
  • 3단계 스키마 구조가 보장하는 독립성

    • 논리적 독립성
      • 개념 스키마가 변경되어도 외부 스키마에는 영향을 주지 않는다.
    • 물리적 독립성
      • 내부 스키마가 변경되어도 외부/개념 스키마에는 영향을 주지 않는다.

ERD

시스템에 어떤 엔티티들이 있고, 그들 간 어떤 관계가 있는지를 표현

ERD 작성 순서

  1. 엔티티를 도출하고 그린다.
  2. 엔티티를 적절하게 배치한다.
  3. 엔티티 간 관계를 표현한다.
  4. 관계명을 기입한다.
  5. 관계의 참여도를 기입한다.
  6. 관계의 필수 여부를 기입한다.

엔티티

식별이 가능한 객체

업무에서 쓰이는 데이터를 용도 별로 분류한 그룹

엔티티의 특징

  1. 업무에서 쓰이는 정보여야 함
  2. 유니크함을 보장할 수 있는 식별자가 있어야 함
  3. 2개 이상의 인스턴스를 가지고 있어야 함
  4. 반드시 속성을 가지고 있어야 함
  5. 다른 엔티티와 1개 이상의 관계를 가지고 있어야 함

엔티티의 분류

  • 유무형에 따른 분류
    • 유형 엔티티
      • 물리적인 형태 존재
      • 지속적, 안정적
    • 개념 엔티티
      • 물리적인 형태가 아님
      • 개념적
    • 사건 엔티티
      • 행위로 발생
      • 통계 자료로 사용 가능
  • 발생 시점에 따른 분류
    • 기본 엔티티
      • 업무에 원래 존재하는 정보
      • 독립적으로 생성, 자식 엔티티를 가질 수 있음
    • 중심 엔티티
      • 기본 엔티티로부터 파생, 행위 엔티티 생성
      • 업무에 있어 중심적인 역할
      • 데이터의 양 많음
    • 행위 엔티티
      • 2개 이상의 엔티티로부터 파생
      • 데이터가 자주 변경/증가

엔티티 명명 규칙

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

속성

사물이나 개념의 특징을 설명해 줄 수 있는 것

  • 의미 상 더 쪼개질 수 없음
  • 프로세스에 필요한 항목

속성값

  • 각각의 속성은 속성값을 가짐
  • 하나의 속성에 속성값이 여러개라면 별도의 엔티티로 분리하는 것이 바람직

속성의 분류

  • 특성에 따른 분류
    • 기본 속성
      • 업무 프로세스 분석을 통해 바로 정의 가능한 속성
    • 설계 속성
      • 업무에 존재 X
      • 그러나 설계 시 필요하다 느껴 도출된 속성
    • 파생 속성
      • 다른 속성값을 계산/특정 규칙으로 변형하여 저장한 속성
  • 구성방식에 따른 분류
    • PK 속성
      • 엔티티의 인스턴스를 식별할 수 있는 속성
    • FK 속성
      • 다른 엔티티의 속성에서 가져온 속성
    • 일반 속성
      • 그외 속성

도메인

속성이 가질 수 있는 속성값의 범위

용어사전

  • 속성의 이름을 정확하고 직관적으로 부여
  • 영어의 혼란 방지

시스템 카탈로그

  • 시스템 자체에 관련이 있는 데이터 저장 (메타데이터)
  • 시스템 테이블로 구성, SQL로 조회 가능
    • Only SELECT

관계

앤티티와 엔티티 간의 관계

존재 관계

  • 존재 자체로 연관

행위 관계

  • 특정한 행위로써 연관

표기법

  • 관계명
    • 관계의 이름
    • 현재형의 명확한 문장
  • 관계차수
    • 1:1, 1:N, N:M
  • 관계선택사양
    • 필수인지 선택인지의 여부

식별자

엔티티가 가진 속성 중 인스턴스를 구분 가능하게 해주는 대표격인 속성을 의미한다.

주식별자

  • 기본티(PK)에 해당
  • 1개 이상의 속성이 주식별자가 된다
  • 유일성
    • 각 인스턴스에 유니크함을 부여해야 한다
  • 최소성
    • 유일성을 보장하는 속성은 최소 개수여야 한다
  • 불변성
    • 속성값이 되도록이면 변하지 않아야 한다
  • 존재성
    • 속성값이 NULL일 수 없다

식별자의 분류

  • 대표성 여부
    • 주식별자
      • 유일성, 최소성, 불변성, 존재성을 가진 대표 식별자
      • 다른 엔티티와 참조관계 연결
    • 보조식별자
      • 인스턴스 식별가능 But 대표 식별자가 아님
      • 다른 엔티티와 참조관계 연결 X
  • 스스로 생성되었는지 여부
    • 내부식별자
      • 엔티티 내부에서 스스로 생성
    • 외부식별자
      • 다른 엔티티에서 생성
      • 다른 엔티티와의 연결고리
  • 단일 속성의 여부
    • 단일식별자
      • 속성 1개로 이루어진 식별자
    • 복합식별자
      • 속성 2개 이상으로 이루어진 식별자
  • 대체 여부
    • 원조/본질식별자
      • 업무 프로세스에 원래 존재하던 식별자
    • 대리/인조식별자
      • 주식별자의 속성이 2개 이상인 경우
      • 속성을 하나로 묶어 사용

식별자/비식별자 관계

  • 식별자 관계
    • 부모 엔티티의 식별자가 자식 엔티티의 주식별자
    • 자식 엔티티는 부모 엔티티가 있어야 생성이 가능
    • 단일/복합 여부에 따라 1:1/1:N이 결정
  • 비식별자 관계
    • 부모 엔티티의 식별자가 자식 엔티티의 일반속성
    • 부모 엔티티가 없어도 자식 엔티티를 생성할 수 있음
    • 자식 엔티티가 존재할 때 부모 엔티티를 삭제할 수 있음

정규화

데이터의 정확성과 일관성을 유지하고 보장하기 위헤 엔티티를 작은 단위로 분리하는 과정
데이터의 조회 성능은 향상되는 경우도, 저하되는 경우도 있음

다만 입력, 수정, 삭제 성능은 일반적으로 향상

제 1정규형

  • 모든 속성은 반드시 하나의 값만 가져야 한다
    • 속성값이 여러개인 속성을 단일 엔티티로 분해

제 2정규형

  • 모든 속성은 모든 주식별자에 종속되어야 한다
    • 주식별자가 복합식별자인 경우 신경써줘야 함
    • 일부 속성이 주식별자의 일부에만 종속될 수 있음

제 3정규형

  • 주식별자가 아닌 모든 속성간의 종속은 허용하지 않는다

정규화의 주의사항

  • 지나친 정규화는 되려 불필요한 성능저하가 일어날 수 있음

반정규화

일반적으로 데이터의 조회 성능을 향상시키기 위해 시행

데이터의 중복을 허용/데이터를 그룹핑하는 과정

조회 성능은 향상될 수 있으나 입력, 수정, 삭제 성능은 저하될 수 있다

데이터 정합성 이슈가 일어날 수도;;

반정규화는 정규화가 끝난 뒤 시행

테이블 반정규화

  • 테이블 병합
    • 업무 프로세스 상 JOIN이 많은 경우 시행
    • 1:1 관계 테이블 병합
    • 1:N 관계 테이블 병합
      • 테이블 병합에 적절하지 않음
    • 슈퍼 서브타입 테이블 병합
  • 테이블 분할
    • 테이블 수직 분할/속성 분할
      • 엔티티의 일부 속성을 병도의 엔티티로 분할
      • 자주 사용하는 속성이 아닐 때
      • 대부분의 인스턴스가 해당 속성값을 NULL로 가질 때
    • 테이블 수평 분할/인스턴스 분할/파티셔닝
      • 엔티티의 인스턴스를 특정 기준으로 분할(파티셔닝)
  • 테이블 추가
    • 중복 테이블 추가
      • 데이터의 중복을 감안
      • 성능사아 반!드!시! 필요하다 판단할 경우 별도의 엔티티로 추가
    • 통계 테이블 추가
      • 속성값을 계산하여 별도의 엔티티의 속성으로 관리
    • 이력 테이블 추가
      • 엔티티의 History 저장에 효과적
    • 부분 테이블 추가
      • 자주 요구되는 기능에 필요한 속성을 뽑아 테이블로 관리

컬럼 반정규화

  • 중복 컬럼 추가
    • 업무 프로세스에서 JOIN이 많을 때 성능 측면을 고려
  • 파생 컬럼 추가
    • 부하가 염려되는 계산값을 미리 계산해 추가
  • 이력 테이블 컬럼 추가
    • 조회 기준을 두어 조회 성능 이점

관계 반정규화

JOIN이 많을 때 성능 측면을 고려

트랜잭션

데이터를 조작하기 위한 하나의 논리적인 작업 단위

NULL

존재하지 않음, 값이 없음

NULL의 연산

  • 가로 연산
    • NULL이 포함되어 있으면 결과값이 NULL이 된다
  • 세로 연산
    • 다른 인스턴스의 데이터와 연산할 때는 NULL을 제외한다.
profile
개발이랑 맨날 싸우긴 하는데 우리 개발이 심성은 착해요

0개의 댓글

관련 채용 정보