[SQLD] 1과목. 데이터 모델링의 이해 요약 정리

Jiseong Choi·2025년 5월 24일

SQLD

목록 보기
1/2

오늘은 SQLD 자격증 시험을 준비하기 위해 데이터 모델링 내용에 대해 요약 정리를 해보려고 한다!

PART 1. 데이터 모델의 이해

✅ 모델링이란?

→ 현실세계를 단순화하여 표현하는 것.

🔹 모델링의 특징

  • 추상화: 현실세계를 일정한 형식에 맞추어 표현
  • 단순화: 현실세계를 약속된 규약에 의해 제한된 표기법이나 언어로 표현하여 쉽게 이해할 수 있도록하는 개념
  • 명확화: 누구나 이해하기 쉽게 하기 위해 정확하게 현상을 기술하는 것

🔹 모델링의 세가지 관점

  • 데이터 관점: 업무와 데이터, 데이터간의 관계성
  • 프로세스 관점: 업무가 실제로 무엇을 하는지 (진행)
  • 데이터와 프로세스의 상관 관점: 처리하는 일의 방법에 따라 데이터가 어떤 영향을 받고 있는지

✅ 데이터 모델링이란?

→ 현실 세계의 데이터를 추상화하고 단순화하여 데이터베이스에 저장할 수 있도록 구조화 하는 과정

🔹 목적:
1. 정보에 대한 표기법을 통일하여 업무 내용 분석 정확도 증대
2. 데이터 모델을 기초로 DB 생성

🔹 기능:
가시화 / 명세화 / 구조화된 툴 제공 / 문서화 / 다양한 관점 제공 / 구체화

🔹 중요성

  • 파급효과(Leverage): 데이터 모델 변경이 전체 시스템에 미치는 영향이 큼. (초기에 정확하게 설계 중요)
  • 간결한 표현(Conciseness): 정보 요구사항과 한계를 간결하게 표현하는 도구
  • 데이터 품질
    • 유일성: 데이터 중복 저장 방지 (무결성 확보)
    • 유연성: 데이터 정의와 데이터 사용 프로세스 분리 (시스템 변화에 유연하게 대응 가능)
    • 일관성: 데이터의 일관성을 유지

🔹 유의점

  • 중복(Duplication): 동일한 정보가 여러 곳에 중복 저장되어 데이터 일관성이 깨질 우려
  • 비유연성(Inflexibility): 사소한 업무변화에 데이터 모델이 수시로 변경되면 안됨
  • 비일관성(Inoonsistency): 데이터 간의 참조 무결성이 깨지면 안됨

🔹 이해관계자:
개발자 / DBA / 모델러 / 현업업무전문가, 완성된 모델을 정확히 해석할 수 있어야 함

✅ 데이터 모델링 3단계

  1. 개념적 모델링:
    • 엔티티와 속성을 도출하고 ERD를 작성한다.
    • 업무 중심적이고 포괄적인 수준의 모델링이다.
  2. 논리적 모델링:
    • 식별자를 도출하고 속성과 관계등을 정의한다.
    • 정규화를 수행하여 데이터 모델의 독립성과 재사용성을 확보하고,
      논리 데이터 모델은 데이터 모델링 완료 상태이다.
  3. 물리적 모델링:
    • DB를 구축한다.
    • 성능 및 보안 등 물리적인 성격을 고려한다.

👉🏻 프로젝트 생명주기(Life Cycle): 계획 > 분석 > 설계 > 개발 > 테스트 > 전환/이행 단계로 구성된다.
계획과 분석 단계는 개념적 모델링, 분석 단계는 논리적 모델링, 설계 단계는 물리적 모델링에 해당한다.

✅ DB의 3단계 구조

→ 데이터 독립성 확보를 목표로 한다.

🔹 DB 독립성의 필요성
→ 데이터의 중복성과 데이터 복잡도 증가로 인한 유지보수 비용 증가, 요구사항 대응 저하

🔹 3층 스키마(3-level Schema)

  • 외부 스키마: 개개 사용자가 보는 개인적 DB 스키마
  • 개념 스키마: 모든 사용자 관점을 통합한 전체 DB
  • 내부 스키마: 물리적 장치에서 데이터가 실질적 저장

🔹 데이터 독립성

  • 논리적 독립성: 개념 스키마가 변경되어도 외부 스키마에 영향 ❌ (논리적 사상 없음)
  • 물리적 독립성: 내부 스키마가 변경되어도 외부/개념 스키마는 영향 ❌ (물리적 사상 없음)

💡Mapping(사상)이란?
→ 상호 독립적인 개념을 연결시켜주는 다리

🔹 데이터 모델링 3요소
→ 엔터티(Entity), 관계(Relationship), 속성(Attribute)

✅ ERD(Entity Relationship Diagram)

[ 엔터티 도출 ] → [ 엔터티 배치 ] → [ 엔터티 간 관계 설정 ] → [ 관계명 기술 ]
→ [ 관계차수 표현( 1:1 , 1:N, M:N ) ] → [ 관계선택사양 표현: 필수 / 선택 ]

💡엔터티: 사각형, 관계: 마름모, 속성: 타원형

✅ 좋은 데이터 모델의 요소

  1. 완전성: 업무에 필요한 모든 데이터가 모델에 정의
  2. 중복배제: 하나의 DB내에 동일한 사실은 한번만
  3. 업무규칙: 많은 규칙을 사용자가 공유하도록 제공
  4. 데이터 재사용: 데이터가 독립적으로 설계돼야 함
  5. 의사소통: 업무규칙은 엔터티, 서브타입, 속성, 관계 등의 형태로 최대한 자세히 표현
  6. 통합성: 동일한 데이터는 한 번만 정의. 참조활용

PART 2. 엔터티

: 업무에서 관리해야 하는 데이터의 집합, 명사형, 인스턴스의 집합

🔹 엔터티의 특징
1. 반드시 해당 업무에서 필요하고 관리하고자 함
2. 유일한 식별자에 의해 식별 가능
3. 두 개 이상의 인스턴스의 집합
4. 업무 프로세스에 의해 이용되어야 함
5. 반드시 속성이 있어야 함
(예외적으로 관계엔터티의 경우는 주식별자 속성만 가지고 있어도 엔터티로 인정)
6. 다른 엔터티와 최소 1개 이상의 관계가 있어야 함.
(관계를 생략하여 표현해야하는 경우는 통계성 엔터티, 코드성 엔터티, 시스템 처리시
내부 필요에 의한 엔터티 도출과 같은 경우)

✅ 엔터티의 분류

🔹 유무형에 따른 분류: 유형, 개념, 사건 엔터티

  • 유형 엔터티: 물리적 형태가 있고, 안정적이고 지속적으로 활용되는 엔터티
    ex) 사원, 물품, 강사 등
  • 개념 엔터티: 물리적 형태가 없고, 개념적인 정보를 담고 있는 엔터티
    ex) 조직, 보험 상품 등
  • 사건 엔터티: 업무 수행시 발생하는 엔터티. 주로 특정 행위의 발생을 기록한다.
    ex) 주문, 청구, 미납 등

🔹 발생 시점에 따른 분류: 기본/키, 중심, 행위 엔터티

  • 기본 엔터티(Key Entity): 원래 존재하는 정보, 타엔터티의 부모 역할, 자신의 고유한 주식별자를 가진다.
    ex) 사원, 부서 등
  • 중심 엔터티(Main Entity): 기본 엔터티로부터 발생한다. 다른 엔터티와의 관계로 많은 행위 엔터티를 생성한다.
    ex) 계약, 사고, 주문 등
  • 행위 엔터티(Active Entity): 2개 이상의 부모 엔터티로부터 발생하며, 내용이 자주 바뀌거나 양이 증가한다.
    ex) 주문 목록, 사원 변경 이력 등

✅ 엔터티의 명명규칙

  1. 현업 업무에서 사용하는 용어를 사용한다.
  2. 약어 사용을 지양한다.
  3. 단수 명사를 사용한다.
  4. 고유한 이름 사용한다. (유일성 보장)
  5. 생성 의미대로 부여한다. (명확성)

PART 3. 속성

: 인스턴스의 구성요소로, 엔터티가 가지는 의미상 분리되지 않는 최소의 단위이다.

✅ 엔터티와 인스턴스 및 속성과 속성값 간의 관계

  • 한 개의 엔터티는 2개 이상의 인스턴스 집합이다.
  • 한 개의 인스턴스는 2개 인상의 속성을 가진다.
  • 한 개의 속성은 1개의 속성값을 가진다.

✅ 속성 표기법

: IE 표기법, Barker 표기법

✅ 속성의 특징

  1. 업무에서 필요하고 관리하고자 하는 정보이다.
  2. 주식별자에 함수적으로 종속된다.
  3. 속성값을 하나만 가진다.
    (하나 이상의 속성값이면 정규화가 필요하다.)

✅ 속성의 분류

🔹 특성에 따른 분류

  • 기본 속성: 비즈니스 프로세스에서 도출되는 본래의 속성
  • 설계 속성: 데이터 모델링 과정에서 업무 규칙화를 위해 발생하는 속성. ex) 일련 번호
  • 파생 속성: 다른 속성에 의해 만들어지는 속성. 빠른 성능을 낼 수 있도록 원래 속성의 값을 계산한다.
    (↔ 저장 속성은 유도 속성을 생성하는데 사용되는 속성)

🔹 분해 가능 여부에 따른 분류

  • 단일 속성: 하나의 의미
  • 복합 속성: 여러 의미, 단일 속성으로 분해 가능. ex) 주소
  • 다중값 속성: 여러 값, 엔터티로 분해 가능

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

  • 기본키 속성(Primary Key): 엔터티를 식별할 수 있는 속성
  • 외래키 속성(Foreign Key): 다른 엔터티와의 관계에서 포함된 속성
  • 일반 속성: 엔터티에 포함되고 PK나 FK 속성이 아닌 속성

💡도메인: 각 속성이 가질 수 있는 값의 범위. ex) 5글자

✅ 속성의 명명규칙

  1. 해당업무에서 사용하는 이름 부여
  2. 서술식 속성명은 사용 금지
  3. 약어 사용 금지
  4. 전체 데이터모델에서 유일성 확보

PART 4. 관계

: 엔터티의 인스턴스 사이의 논리적인 연관성으로서 존재의 형태로서나 행위로서 서루에게 연관성이 부여된 상태

  • 존재에 의한 관계. ex) 소속된다.
  • 행위에 의한 관계. ex) 주문한다.

🔹 관계의 페어링
: 엔터티 안에 인스턴스가 개별적으로 관계를 가지는 것.

🔹 UML의 연관 관계, 의존 관계

  • 연관(존재적) 관계: 항상 이용하는 관계
  • 의존 관계: 상대방, 행위에 의해 발생하는 관계

✅ 관계의 표기법

🔹 관계명: 관계의 이름
🔹 관계 차수: 관계 내 튜플의 전체 개수, 1은 직선 N은 삼발로 표시
→ M:N 관계: 관계형 DB에서 M:N 관계의 조인은 카테시안 곱이 발생한다.
🔹 관계 선택성(관계선택사양, Optionality): 필수는 1 선택은 0으로 표시

✅ 관계의 종류

🔹 ERD 기준: 존재적 관계와 행위에 의한 관계를 구분하지 않고 표기한다.

  • 존재 관계: 엔터티 간의 상태
  • 행위 관계: 엔터티 간에 발생하는 행위

🔹 UML(Unified Modeling Language) 기준

  • 연관 관계(Association): 실선 표기
  • 의존 관계(Dependency): 점선 표기

🔹 식별자에 따른 분류

  • 식별 관계: 부모 엔터티의 식별자를 자식 엔터티에서 주식별자로 사용
    ※ 약한 엔터티: 부모 엔터티에 종속되어 존재 (↔ 강한 엔터티는 독립적으로 존재한다.)
  • 비식별 관계: 부모 엔터티의 식별자를 자식 엔터티에서 일반 컬럼으로 참조 사용, 약한 종속 관계
    ※ 식별 관계만으로 연결되면 주식별자 수가 많아질 수밖에 없으므로
    관계 강약 분석, 자식 엔터티의 독릭 PK 필요성, SQL 복잡성과 개발 생산성 고려 필요.

✅ 관계 체크사항

  1. 2개의 엔터티 사이에 관심이 있는 연관 규칙이 존재하는가
  2. 2개의 엔터티 사이에 정보의 조합이 발생하는가
  3. 업무기술서, 장표에 관계 연결에 대한 규칙을 서술 하였는가
  4. 업무기술서, 장표에 관계 연결을 가능하게 하는 동사가 존재하는가

PART 5. 식별자

: 엔터티 내에서 인스턴스를 구분하는 구분자.

  • 식별자는 논리 데이터 모델링 단계에서 사용
  • Key는 물리 데이터 모델링 단계에서 사용

✅ 식별자의 특징

  • 유일성: 주식별자에 의해 모든 인스턴스들이 유일하게 구분할 수 있다.
  • 최소성: 주식별자를 구성하는 속성의 수는 유일성을 만족하는 최소의 수가 되어야 한다.
  • 불변성: 지정된 주식별자의 값은 자주 변하지 않아야 한다.
  • 존재성: 주식별자가 지정이 되면 반드시 값이 들어와야 한다.

✅ 식별자 분류

🔹 대표성 여부에 따른 분류: 주식별자, 보조식별자

  • 주식별자: 대표성을 만족하는 식별자, 타 엔터티와 참조 관계를 연결할 수 있다.
  • 보조식별자: 유일성과 최소성만 만족하는 식별자로, 참조 관계 연결에 사용할 수 없다.

⚙️ DB 키의 종류

  • 기본키(PK, Primary Key): 엔터티를 대표하는 키, 후보키 중 선정된다.
  • 후보키: 유일성과 최소성을 만족하는 키
  • 슈퍼키: 유일성만 만족하는 키
  • 외래키(FK, Foreign Key): 여러 테이블의 기본 키 필드,
    참조 무결성(Referential Integrity)을 확인하기 위해 사용됨 (허용된 데이터 값만 저장하기 위함)

🔹 생성 여부에 따른 분류: 내부식별자, 외부식별자

  • 내부 식별자: 자연스럽게 존재(스스로 생성되는)하는 식별자 (~ 본질 식별자)
  • 외부 식별자: 다른 엔터티와의 관계를 통해 생성되는 식별자

🔹 속성 수에 따른 분류: 단일식별자, 복합식별자

  • 단일 식별자: 하나의 속성으로 구성
  • 복합 식별자: 2개 이상의 속성으로 구성

🔹 대체 여부에 따른 분류: 본질식별자, 인조식별자

  • 본질 식별자: 업무에 의해 만들어지는 식별자, 대체될 수 없는 식별자
  • 인조 식별자: 인위적으로 만들어지는 대체 가능한 식별자 (순서번호, Sequence Number)를 사용하여 생성된 식별자.
    1) 후보 식별자 중 주식별자로 선정할 것이 없거나,
    2) 주식별자가 너무 많은 컬럼으로 구성되어 있을 때 사용

✅ 주식별자 도출 기준

  1. 해당 업무에서 자주 이용되는 속성
  2. 명칭, 내역 등과 같이 이름으로 기술되는 것들은 사용하지 않는다.
  3. 복합으로 주식별자로 구성할 경우 너무 많은 속성은 지양한다.

✅ 식별자 관계

🔹 식별자 관계(Identifying Relationship)
: 부모 엔터티의 주식별자가 자식 엔터티의 주식별자의 일부 또는 전부로 상속되는 관계

✔️ 특징:

  • 강한 연결: 부모가 없으면 자식이 존재할 수 없는 생명 주기의 종속성을 가진다.
  • 표기: ERD에서는 실선으로 표기한다.

✔️ 주요 사용 경우:

  1. 부모로부터 받은 식별자를 자식 엔터티의 주식별자로 직접 활용하는 경우.

🔹 비식별자(Non-identifying Relationship)
: 부모 엔터티의 주식별자가 자식의 일반 속성으로 상속되는 관계

✔️ 특징:

  • 약한 연결: 부모 엔터티가 없어도 자식 엔터티가 독립적으로 존재할 수 있거나,
    자식 엔터티의 식별 방식이 부모와 관계없이 독자적으로 정의되는 경우가 많다.
  • 표기: ERD에서는 점선으로 표기한다.

✔️ 주요 사용 경우:

  1. 부모 없는 자식이 생성될 수 있는 경우
  2. 부모와 자식의 생명주기가 다른 경우
  3. 여러 개의 엔터티가 하나의 엔터티로 통합되었는데 각각의 엔터티가 별도의 관계를 가진 경우
  4. 자식 엔터티에 별도의 주식별자를 생성하는 것이 더 유리한 경우
  5. SQL 문장이 길어져 복잡성 증가되는 것을 방지
profile
나 혼자 공부하고, 끄적이는 공간. (Node.JS / Back-End Developer)

0개의 댓글