[SQL자격검정실전문제] 1. 데이터 모델링의 이해

데이터 모델링의 기본 개념 및 핵심 정리

1. 데이터 모델링의 기본 개념

1.1 모델링의 특징

• 추상화: 현실세계를 일정한 형식에 맞추어 표현하는 것
• 단순화: 복잡한 현실을 제한된 언어나 표기법으로 이해하기 쉽게 하는 것
• 정확화: 모호함을 배제하고 누구나 이해 가능하도록 정확하게 현상을 기술하는 것
• 시스템 구현 목적: 시스템 구현을 포함한 업무 분석 및 업무 형상화를 목적으로 함
• 일정한 표기법: 업무 정보를 구성하는 기초 정보들을 일정한 규칙으로 표현함

1.2 모델링의 유의점

• 중복 (Duplicity): 데이터베이스가 여러 장소에 같은 정보를 저장하지 않도록 주의
• 비유연성 (Inflexibility): 데이터 정의와 사용 프로세스를 분리하여, 작은 변화가 앱과 DB에 중대한 변화를 일으키지 않도록 함
• 비일관성 (Inconsistency): 데이터 간 상호 연관 관계를 명확히 정의하여 데이터 모순 방지

2. 데이터 독립성

2.1 데이터 독립성의 구성요소 (ANSI-SPARC 3단계)

데이터 독립성은 외부, 개념, 내부 계층으로 분리됩니다.

계층	설명
외부 스키마 (External)	개별 사용자나 응용 프로그래머가 보는 논리적 구조
개념 스키마 (Conceptual)	모든 사용자의 관점을 통합한 전체 데이터베이스의 논리적 구조
내부 스키마 (Internal)	물리적 저장 장치에서 데이터가 실제로 저장되는 방식

2.2 데이터 독립성의 종류

독립성은 위 계층 사이의 대응(Mapping) 관계를 통해 실현됩니다.

1) 논리적 데이터 독립성 (Logical Data Independence)

• 개념: 개념 스키마가 변경되어도 외부 스키마(응용 프로그램)는 영향을 받지 않는 성질
• 내용: 새로운 테이블 추가, 컬럼 통합/분리 시에도 화면이나 프로그램 코드를 수정할 필요가 없음
• 구현: 외부 스키마와 개념 스키마 사이의 사상(Mapping)을 통해 이루어짐

2) 물리적 데이터 독립성 (Physical Data Independence)

• 개념: 내부 스키마가 변경되어도 개념/외부 스키마는 영향을 받지 않는 성질
• 내용: 인덱스 추가/삭제, 저장 장치(HDD/SSD) 교체, 파일 구조 변경 시에도 논리 구조나 응용 프로그램은 유지됨
• 구현: 개념 스키마와 내부 스키마 사이의 사상(Mapping)을 통해 이루어짐

💡 2.3 문제 핵심 정리

• 통합된 모든 사용자 관점은 개념 스키마와 관련이 있다.
• 물리적인 저장구조를 표현하는 스키마는 내부 스키마다.
• View 단계는 여러 사용자 관점으로 구성하는 외부 스키마에 해당한다.
• 논리적인 데이터 독립성을 고려하는 단계는 외부 단계와 개념적 단계다.

3. 스키마

스키마는 DB의 구조와 제약조건에 대해 전반적인 명세를 정의한 것입니다. 표준적으로 3층 스키마 구조를 가집니다.

3.1 스키마의 3계층 구조

• 외부 스키마: 사용자/프로그래머 관점. 전체 DB 중 일부 논리 구조 (예: View)
• 개념 스키마: 기관 전체/통합적 관점. 전체 테이블 구조. DB당 하나만 존재
• 내부 스키마: 시스템 설계자/관리자 관점. 물리적 저장 방식 (레코드 크기, 인덱스, 압축 등)

3.2 스키마 간의 사상(Mapping)

• 외부-개념 사상 (응용 인터페이스): 논리적 데이터 독립성 유지
• 개념-내부 사상 (저장 인터페이스): 물리적 데이터 독립성 유지

💡 3.3 문제 핵심 정리

개념 스키마는 조직 전체 관점의 통합적 표현이며, DB에 저장되는 데이터와 그들 간의 관계를 표현합니다.

4. 데이터 모델의 구성 요소

데이터 모델은 보통 아래 3가지로 정형화됩니다.

1. 구조 (Structure): 데이터가 어떻게 조직되고 표현되는가? (엔터티, 속성, 관계 등)
2. 연산 (Operation): 데이터에 대해 어떤 처리가 가능한가? (조회, 삽입, 수정 등)
3. 제약조건 (Constraint): 데이터가 반드시 지켜야 할 규칙 (키 제약, 무결성 등)

4.1 엔터티 (Entity)

현실 세계에서 관리하고자 하는 대상의 집합입니다.

엔터티의 특징

• 식별 가능성: 각 인스턴스를 구분할 수 있는 식별자를 가져야 함
• 속성의 존재: 하나 이상의 속성을 가짐
• 인스턴스의 집합: 개별 객체가 아닌 집합의 개념임
• 업무적 의미: 업무적으로 의미가 있어야 함
• 관계: 보통 타 엔터티와 관계를 가짐 (관계가 없으면 속성일 확률이 높음)

엔터티의 분류

분류 기준	종류	내용 및 예시
유무형 (물리적 형태)	유형	눈에 보이고 잡히는 것 (사원, 물품, 강사)
	개념	논리적 추상체 (부서, 학과, 서비스 등급, 보험 상품)
	사건	업무 중 발생하는 동적 데이터 (주문, 청구, 미납)
발생시점 (흐름 기준)	기본(키)	독립적으로 존재. 고유 PK 보유 (고객, 사원, 부서, 상품)
	중심	기본 엔터티 기반 핵심 로직 담당 (주문, 계약, 매출, 예금 원장)
	행위	중심 엔터티 수행 과정에서 발생 (주문 상세, 이력, 배송 내역)

🏷️ 엔터티 명명 규칙: 현업 용어 사용 / 약어 사용 지양 / 단수 명사 사용 / 유일한 이름 부여 / 생성 의미대로 명명

4.2 속성 (Attribute)

엔터티가 가지는 최소 단위의 정보입니다.

• 한 엔터티는 2개 이상의 인스턴스 집합이고, 2개 이상의 속성을 가짐
• 한 속성은 한 개의 속성값을 가짐 (원자성)

속성의 분류

• 기본 속성: 본래부터 존재하는 속성 (사원명, 부서코드)
• 설계 속성: 관리를 위해 인위적으로 만든 속성 (사원번호, 주문상태코드)
• 파생 속성: 타 속성에서 가공된 속성. 성능을 위해 사용하며 최소화 권장 (나이, 총금액)

4.3 도메인 (Domain)

각 속성이 가질 수 있는 원자값들의 집합이자 표준 가이드라인입니다.

• 구성 요소: 데이터 타입, 길이, 제약 조건, 기본값
• 목적: 데이터 일관성 및 재사용성 확보

4.4 관계 (Relationship)

엔터티 간의 비즈니스적 연결 고리입니다.

• 차수 (Cardinality): 1:1, 1:N, M:N (M:N은 물리 DB에서 교차 엔터티로 해결)
• 선택 사양: 필수(Mandatory), 선택(Optional - 점선 표시)

UML에서의 관계 구분

• 연관 관계 (Association): 존재적 관계. 실선 표현. 멤버 변수로 선언하여 사용
• 의존 관계 (Dependency): 행위적 관계. 점선 표현. 파라미터 등으로 이용

📝 관계 정의 시 확인 사항: 연관 규칙 존재 여부, 정보의 조합 발생 여부, 업무 기술서 내 동사(Verb) 및 규칙 존재 여부

❓ 식별자 관계 vs 비식별자 관계

구분	식별자 관계	비식별자 관계
연결 강도	강한 연결 관계	약한 연결 관계
상속	자식 주식별자 구성에 포함	자식 일반 속성에 포함
표현	실선 (Solid Line)	점선 (Dashed Line)

* 조인 관계를 최소화하려면 식별자 관계로 연결하는 것이 유리합니다.

4.5 식별자 (Identifier)

좋은 식별자의 4대 조건

1. 유일성 | 2. 최소성 | 3. 불변성 | 4. 존재성(Not Null)

식별자 분류

• 대표성 여부: 주식별자(대표) vs 보조식별자
• 생성 방식: 내부 식별자(스스로 생성) vs 외부 식별자(FK)
• 속성 수: 단일 식별자 vs 복합 식별자
• 업무 연관성: 본질 식별자 vs 인조 식별자(관리 편의를 위해 인위적 생성)