Deplux2편 - SQLD 1과목 1장 : 데이터 모델링의 이해
SQLD 과목1: 데이터 모델링의 이해
제1장. 데이터 모델링의 이해
1.1 데이터 모델의 이해
1.1.1 모델링이란?
모델링이란 현실 세계의 복잡한 현상을 일정한 표기법에 의해 단순화·추상화하여 표현하는 것이다.
모델링의 3가지 특징:
- 추상화(Abstraction): 현실 세계를 일정한 형식에 맞추어 간략하게 표현
- 단순화(Simplification): 복잡한 현실을 정해진 표기법으로 단순하게 표현
- 명확화(Clarity): 대상에 대한 애매모호함을 제거하고 정확하게 현상을 기술
1.1.2 데이터 모델링이란?
데이터 모델링은 정보시스템을 구축하기 위해 어떤 데이터가 존재하는지, 업무가 필요로 하는 정보가 무엇인지를 분석하는 방법이다.
데이터 모델링의 3가지 관점:
| 관점 | 설명 | 예시 |
|---|---|---|
| 데이터 관점 (What) | 업무가 어떤 데이터와 관련이 있는가 | 고객, 주문, 상품 |
| 프로세스 관점 (How) | 업무가 실제로 하고 있는 일은 무엇인가 | 주문처리, 배송, 결제 |
| 상관 관점 (Interaction) | 데이터와 프로세스의 관계는 무엇인가 | 어떤 프로세스가 어떤 데이터를 생성/변경하는가 |
1.1.3 데이터 모델링의 3단계
개념적 모델링 → 논리적 모델링 → 물리적 모델링
(추상적) (구체적)
| 단계 | 설명 | 주요 산출물 |
|---|---|---|
| 개념적 데이터 모델링 | 업무 중심의 포괄적 수준의 모델링. 전사적 관점에서 주요 엔터티와 관계를 정의 | 개념 ERD, 핵심 엔터티 도출 |
| 논리적 데이터 모델링 | 비즈니스 정보의 논리적 구조와 규칙을 명확하게 표현. 정규화 수행 | 상세 ERD, 속성 정의, 정규화된 모델 |
| 물리적 데이터 모델링 | 실제 데이터베이스에 이식할 수 있도록 성능, 저장 등 물리적 성격을 고려하여 설계 | 테이블, 인덱스, 파티션 설계 |
1.1.4 데이터 모델링에서 데이터 독립성의 이해
3단계 스키마 구조 (ANSI/SPARC)
외부 스키마 (External Schema) ← 사용자 관점
↕ 논리적 데이터 독립성
개념 스키마 (Conceptual Schema) ← 통합된 전체 관점
↕ 물리적 데이터 독립성
내부 스키마 (Internal Schema) ← 물리적 저장 구조
| 스키마 | 설명 |
|---|---|
| 외부 스키마 | 각 사용자 또는 응용프로그래머가 개인의 입장에서 필요한 데이터베이스의 논리적 구조를 정의한 것. 여러 개 존재 가능 |
| 개념 스키마 | 조직 전체의 데이터베이스 구조를 논리적으로 정의한 것. 하나만 존재. 통합 관점 |
| 내부 스키마 | 데이터가 물리적으로 저장된 형식을 정의. 하나만 존재 |
데이터 독립성의 종류:
| 독립성 | 설명 |
|---|---|
| 논리적 독립성 | 개념 스키마가 변경되어도 외부 스키마에 영향 없음 |
| 물리적 독립성 | 내부 스키마가 변경되어도 개념 스키마에 영향 없음 |
1.1.5 데이터 모델링의 중요한 3가지 개념
| 개념 | 설명 | 비유 |
|---|---|---|
| 엔터티(Entity) | 업무에 필요하고 유용한 정보를 저장하고 관리하기 위한 것 | 명사 (사람, 장소, 사건) |
| 속성(Attribute) | 업무에서 필요한 엔터티의 세부 정보 항목 | 형용사/수식어 |
| 관계(Relationship) | 엔터티 간의 업무적 연관성 | 동사 |
1.2 엔터티 (Entity)
1.2.1 엔터티의 정의
엔터티란 업무에 필요하고 유용한 정보를 저장하고 관리하기 위한 것으로, 변별할 수 있는 사물이다.
1.2.2 엔터티의 특징
엔터티가 되려면 다음 6가지 조건을 모두 만족해야 한다:
- 업무에서 필요로 하는 정보여야 한다 (업무에서 관리하고자 하는 대상)
- 유일한 식별자에 의해 식별이 가능해야 한다 (각 인스턴스를 구별할 수 있어야 함)
- 영속적으로 존재하는 두 개 이상의 인스턴스의 집합이어야 한다 (최소 2개 이상)
- 업무 프로세스에 의해 이용되어야 한다 (CRUD가 있어야 함)
- 반드시 속성이 있어야 한다 (속성이 없는 엔터티는 존재할 수 없음)
- 다른 엔터티와 최소 1개 이상의 관계가 있어야 한다
시험 핵심: "통계성 엔터티"나 "코드성 엔터티"는 다른 엔터티와 관계가 없을 수 있다는 예외가 있다.
1.2.3 엔터티의 분류
(1) 유무형에 따른 분류
| 분류 | 설명 | 예시 |
|---|---|---|
| 유형 엔터티 | 물리적 형태가 있고 안정적이며 지속적 | 사원, 물품, 강사 |
| 개념 엔터티 | 물리적 형태 없이 관리해야 할 개념적 정보 | 조직, 보험상품, 부서 |
| 사건 엔터티 | 업무 수행 시 발생하는 것. 데이터량이 가장 많음 | 주문, 청구, 미납 |
(2) 발생 시점에 따른 분류
| 분류 | 설명 | 예시 |
|---|---|---|
| 기본 엔터티 (Key Entity) | 독립적으로 생성되며 타 엔터티의 부모 역할. 자신의 부모 엔터티 없음 | 사원, 부서, 고객, 상품 |
| 중심 엔터티 (Main Entity) | 기본 엔터티로부터 발생하고 업무의 중심 역할 | 계약, 사고, 주문, 청구 |
| 행위 엔터티 (Active Entity) | 2개 이상의 부모 엔터티로부터 발생. 데이터량이 많고 자주 변경됨 | 주문목록, 사원변경이력 |
1.2.4 엔터티의 명명 규칙
- 가능하면 현업 업무에서 사용하는 용어 사용
- 약어 사용 금지 (가능한 한)
- 단수 명사 사용
- 유일한 이름 부여 (동일 모델 내 중복 불가)
- 엔터티가 생성되는 의미대로 이름 부여
1.3 속성 (Attribute)
1.3.1 속성의 정의
속성이란 업무에서 필요로 하는 인스턴스로 관리하고자 하는 의미상 더 이상 분리되지 않는 최소의 데이터 단위이다.
1.3.2 엔터티, 인스턴스, 속성, 속성값의 관계
엔터티 ─ 인스턴스(행/Row) ─ 속성(열/Column) ─ 속성값(데이터)
관계 규칙:
- 한 개의 엔터티는 두 개 이상의 인스턴스의 집합이어야 한다
- 한 개의 엔터티는 두 개 이상의 속성을 갖는다
- 한 개의 속성은 한 개의 속성값을 갖는다 (다가 속성 X)
1.3.3 속성의 분류
(1) 특성에 따른 분류
| 분류 | 설명 | 예시 |
|---|---|---|
| 기본 속성 (Basic) | 업무로부터 추출한 모든 일반적인 속성 | 이름, 주소, 전화번호 |
| 설계 속성 (Designed) | 원래 업무에는 없지만 설계 과정에서 도출한 속성 | 일련번호, 코드 |
| 파생 속성 (Derived) | 다른 속성에 의해 계산되거나 변환되어 생성된 속성 | 합계, 평균, 나이 |
시험 핵심: 파생 속성은 가급적 적게 정의하는 것이 좋다. 데이터 정합성 문제가 발생할 수 있기 때문이다.
(2) 엔터티 구성 방식에 따른 분류
| 분류 | 설명 | 예시 |
|---|---|---|
| PK 속성 | 엔터티의 인스턴스를 식별할 수 있는 속성 | 사원번호, 주문번호 |
| FK 속성 | 다른 엔터티와의 관계에서 포함된 속성 | 부서코드(사원 테이블 내) |
| 일반 속성 | PK, FK가 아닌 나머지 속성 | 이름, 주소, 금액 |
1.3.4 도메인 (Domain)
도메인이란 각 속성이 가질 수 있는 값의 범위를 말한다.
예시:
- 학년: 1~4 (정수)
- 성별: '남', '여'
- 연락처: 전화번호 형식의 문자열
1.3.5 속성의 명명 규칙
- 해당 업무에서 사용하는 이름 부여
- 서술식 속성명은 사용 금지 ("주문한 일자" → "주문일자")
- 약어 사용 가급적 제한
- 전체 데이터 모델에서 유일한 이름 부여 권장
1.4 관계 (Relationship)
1.4.1 관계의 정의
관계란 엔터티의 인스턴스 사이의 논리적인 연관성으로서 존재의 형태 또는 행위로서 서로에게 연관성이 부여된 상태를 말한다.
1.4.2 관계의 분류
| 분류 | 설명 | 예시 |
|---|---|---|
| 존재적 관계 | 엔터티 간 존재 자체로 연관이 있는 관계 | 부서 - 사원 (사원은 부서에 소속됨) |
| 행위적 관계 | 특정 행위에 의해 발생하는 관계 | 고객 - 주문 (고객이 주문을 함) |
1.4.3 관계의 표기법
관계를 표현할 때 3가지를 고려한다:
- 관계명 (Membership): 관계의 이름 (동사형)
- 관계차수 (Cardinality/Degree): 1:1, 1:M, M:N
- 관계선택사양 (Optionality): 필수(Mandatory) / 선택(Optional)
(1) 관계차수
| 표기 | 설명 | ERD 표기 |
|---|---|---|
| 1:1 | 양쪽 모두 하나씩만 관계 | 실선 하나 |
| 1:M | 한쪽이 여러 개와 관계 (가장 흔함) | 까마귀발 표기 |
| M:N | 양쪽 모두 여러 개와 관계 → 반드시 해소해야 함 | 양쪽 까마귀발 |
(2) 관계선택사양 (선택성)
| 표기 | 설명 | ERD 표기 |
|---|---|---|
| 필수 (Mandatory) | 반드시 관계를 가져야 함 | ` |
| 선택 (Optional) | 관계를 가질 수도, 가지지 않을 수도 있음 | O (원) |
1.4.4 관계 읽기
관계를 읽을 때는 다음 순서로 읽는다:
기준 엔터티 → 관계선택사양 → 관계차수 → 대상 엔터티 → 관계명
예시: "각 부서는 반드시 여러 명의 사원을 포함한다"
1.4.5 관계와 조인의 관계
관계가 설정되면 SQL에서 JOIN으로 구현된다.
-- 부서(1) - 사원(M) 관계 SELECT e.사원명, d.부서명 FROM 사원 e JOIN 부서 d ON e.부서코드 = d.부서코드;
1.5 식별자 (Identifier)
1.5.1 식별자의 정의
식별자란 하나의 엔터티에 구성되어 있는 여러 개의 속성 중에 엔터티를 대표할 수 있는 속성을 의미하며, 하나의 엔터티는 반드시 하나의 유일한 식별자가 존재해야 한다.
1.5.2 식별자의 특징
| 특징 | 설명 |
|---|---|
| 유일성 | 주식별자에 의해 엔터티 내에 모든 인스턴스들이 유일하게 구분되어야 한다 |
| 최소성 | 주식별자를 구성하는 속성의 수는 유일성을 만족하는 최소한의 수여야 한다 |
| 불변성 | 주식별자가 한 번 지정되면 그 값은 변하지 않아야 한다 |
| 존재성 | 주식별자가 지정되면 반드시 데이터 값이 존재해야 한다 (NOT NULL) |
1.5.3 식별자의 분류
(1) 대표성 여부에 따라
| 분류 | 설명 | 예시 |
|---|---|---|
| 주식별자 (Primary Identifier) | 엔터티를 대표하는 유일한 식별자. PK로 구현 | 사원번호, 주문번호 |
| 보조식별자 (Alternate Identifier) | 유일성은 만족하지만 대표성은 없음. Unique로 구현 | 주민등록번호 (사원번호가 PK일 때) |
(2) 스스로 생성 여부에 따라
| 분류 | 설명 | 예시 |
|---|---|---|
| 내부식별자 | 엔터티 내부에서 스스로 생성된 식별자 | 사원번호, 부서코드 |
| 외부식별자 | 다른 엔터티와의 관계를 통해 받아온 식별자 (FK) | 사원 테이블의 부서코드 |
(3) 속성의 수에 따라
| 분류 | 설명 | 예시 |
|---|---|---|
| 단일식별자 | 하나의 속성으로 구성 | 사원번호 |
| 복합식별자 | 두 개 이상의 속성으로 구성 | (주문번호, 상품번호) |
(4) 대체 여부에 따라
| 분류 | 설명 | 예시 |
|---|---|---|
| 본질식별자 (원조식별자) | 업무에 의해 만들어지는 가장 가까운 식별자 | 주민등록번호, 수강(학번+과목코드) |
| 인조식별자 (대리식별자) | 원조식별자가 복잡할 때 인위적으로 만든 식별자 | 수강번호 (시퀀스) |
시험 핵심: 인조식별자를 남용하면 데이터 품질이 저하될 수 있다. 본질식별자를 우선 사용하되, 복합식별자가 지나치게 복잡할 때만 인조식별자를 사용해야 한다.
1.5.4 식별자 관계와 비식별자 관계
이것은 매우 중요한 개념이다. 부모 엔터티의 식별자가 자식 엔터티에 전이될 때의 관계를 정의한다.
(1) 식별자 관계 (Identifying Relationship)
| 항목 | 설명 |
|---|---|
| 정의 | 부모의 식별자가 자식의 **주식별자(PK)**에 포함되는 관계 |
| ERD 표기 | 실선 |
| 특징 | 자식은 부모 없이 존재할 수 없음 (강한 종속) |
[주문] ──── [주문상세]
주문번호(PK) 주문번호(PK, FK) + 상품번호(PK)
(2) 비식별자 관계 (Non-Identifying Relationship)
| 항목 | 설명 |
|---|---|
| 정의 | 부모의 식별자가 자식의 **일반 속성(FK)**으로만 전이되는 관계 |
| ERD 표기 | 점선 |
| 특징 | 자식이 독립적으로 존재 가능 (약한 종속) |
[부서] ···· [사원]
부서코드(PK) 사원번호(PK), 부서코드(FK)
(3) 식별자 관계 vs 비식별자 관계 선택 기준
| 기준 | 식별자 관계 | 비식별자 관계 |
|---|---|---|
| 강한 연관 관계 | O | X |
| 자식 독립 존재 가능 | X | O |
| 자식의 주식별자 구성에 부모 PK 포함 여부 | O | X |
| SQL 조인 시 | PK만으로 조인 가능 | FK 별도 조인 필요 |
| 부모 종속 여부 | 부모 없이 자식 존재 불가 | 부모 없이 자식 존재 가능 |
시험 핵심: 식별자 관계를 지나치게 많이 사용하면 PK 속성이 계속 늘어나 복잡해진다. 반대로 비식별자 관계만 사용하면 불필요한 조인이 증가한다. 적절한 균형이 중요하다.