티스토리 뷰
📌 01. 모델링(Modeling)
📍 01-01. 모델링의 필요성
현실 세계는 복잡하며, 이를 단순화하고 정확하게 표현하기 위해 모델링이 필요합니다.
이는 의사소통, 시뮬레이션, 문제해결, 교육, 연구 등 다양한 분야에서 활용됩니다.
📍 01-02. 모델링의 특징
항목 | 설명 |
---|---|
단순화 | 복잡한 현실에서 필요한 요소만 선택 |
추상화 | 관련 있는 현상을 일정한 형식으로 묶음 |
명확화 | 누구나 이해하기 쉽도록 정확히 표현 |
🧩 02. 데이터 모델링(Data Modeling)
📍 02-01. 데이터 모델링의 필요성
✅ 파일 저장의 한계
- 메모리에만 저장된 데이터는 휘발성 → 디스크 파일로 저장 필요
- 시스템 장애나 복구 어려움, 사람이 읽기 어려운 이진 파일
✅ 엑셀 저장의 한계
- 시각적으로 편리하지만 중복 많고 확장성 낮음
- 행 수가 많아지면 속도 저하, 관리 어려움
✅ 관계형 DB 저장의 이점
- 데이터 유형과 관계를 시각적으로 명확히 파악
- 중복 제거로 관리 용이성 향상
- 안정적이고 확장 가능한 데이터 관리 가능
✅ 관계형 DB 설계 필요성
- 테이블 구성 기준을 정의하고, 컬럼의 의미와 관계를 파악하여 설계
📍 02-02. 소프트웨어 개발과 데이터 모델링
✅ 폭포수 모델 기반 개발 절차
요구사항 분석 → 설계 → 구현 → 테스트 → 유지보수
- 정보 시스템: 데이터를 입력받아 처리하고 정보를 산출하는 시스템
✅ 데이터 모델링 유형
모델링 | 설명 |
---|---|
데이터 관점 모델링 | ERD 설계, DB 구축 및 튜닝 |
프로세스 모델링 | 업무 절차와 흐름 정의 |
상관 모델링 | 데이터가 업무에 미치는 영향 모델링 |
📍 02-03. 데이터 모델 표기법
✅ 피터첸 표기법
- 1976년, 피터첸이 제안한 ER 모델
- 국내 대학에서 교육용으로 주로 사용
✅ IE 표기법 vs 바커 표기법
표기법 | 특징 |
---|---|
IE 표기법 | 일반적인 데이터 모델링에 사용 |
바커 표기법 | 논리 모델링에서 더 구체적인 관계 표현 가능 (배타관계, 서브타입 등) |

📍 02-04. 관계형 모델 (Relational Model)
✅ 릴레이션이란?
- 데이터를 테이블 형태(행/열)로 표현
- 각 테이블 간 관계 설정 가능

✅ 무결성이란?
정확하고 일관된 데이터 상태를 보장하는 제약 조건
- 정합성: 데이터 간 논리적 일치
- 무결성: 데이터가 정확하고 완전한 상태
✅ 무결성의 종류
유형 | 설명 |
---|---|
엔터티 무결성 | 각 행은 고유해야 하며, 대표 속성은 NULL 불가 |
참조 무결성 | 외래키는 참조되는 기본키와 일치하거나 NULL이어야 함 |
도메인 무결성 | 속성 값은 지정된 타입, 범위, 규칙을 따라야 함 |
업무 무결성 | 기업 업무에 따라 정의된 데이터 처리 규칙 |
🧱 01. 엔터티(Entity)
📌 01-01. 엔터티란?
💡 업무의 관심 대상이 되는 정보를 담거나, 그 정보가 필요한 유형 또는 무형의 객체
예: 고객, 주문, 사원, 학생 등
📌 01-02. 엔터티와 속성 도출
🔍 엔터티 도출 과정
- 업무 기술서, 인터뷰 자료 등에서 명사를 추출
- 명사가 속성인지, 엔터티인지 판단
- 중복/유사 명사는 정리하고, 최종 후보 리스트 작성
📋 도출 기준
- 두 개 이상의 인스턴스 필요
- 명확한 주제/식별자 존재
- 하나의 주제를 표현하는 명확한 명칭
📌 01-03. 엔터티의 종류
종류 | 설명 | 예시 |
---|---|---|
실체 엔터티 | 본질적 속성을 가지는 실체 | 고객, 제품, 창고 |
기준 엔터티 | 참조용 기준 데이터 | 우편번호, 이자율 |
행위 엔터티 | 업무 활동에서 발생 | 주문, 계약, 신청 |
가공 엔터티 | 집계/요약된 데이터 | 월별매출, 통계 |
📌 01-04. 속성(Attribute) 종류

🧩 분해 기준에 따른 구분
- 단일 속성: 하나의 의미로 구성된 속성 (부서명, 재고 수량)
- 복합 속성: 두 개 이상의 세부 속성으로 구성된 속성 (주소(시, 구, 동), 전화번호 등 )
- 다가 속성: 속성에 여러 값을 지니고 있는 속성 (주문 목록, 결제 내역 → 1NF 위배 가능)
🧩 특성에 따른 구분
- 기초 속성: 엔터티 본질 설명하는 속성
- 관계 속성: 타 엔터티와의 연관성을 나타내는 속성
- 추출 속성: 원본 속성의 값을 연산해서 채울 수 있는 속성이다.
📌 01-05. 식별자 (Identifier)

🔐 주식별자 (Primary Key)
- 엔터티의 인스턴스를 고유하게 식별하는 속성
- 특징: 유일성, 최소성, 불변성, 존재성
- 유일성 : 주식별자에 의해 엔티티 내에 모든 인스턴스들을 유일하게 구분되어야 한다. (중복되지 않는다.)
- 최소성 : 주식별자를 구성하는 속성의 수는 유일성을 만족하는 최소의 수가 되어야 한다.
- 불변성 : 주식별자가 한번 특정 엔터티에 지정되면 그 식별자의 값은 변하지 않아야 한다.
- 존재성 : 주식별자가 지정되면 반드시 데이터 값이 존재해야한다. (NULL은 허용되지 않는다.)
- 없을 경우 새로운 속성 추가 가능 (예: ID)
🔗 외래식별자 (Foreign Key)
- 부모 엔터티의 주식별자를 참조
- 자식 엔터티에 외래키 속성 생성 필요 시 추가 정의
📌 01-06. 도메인(Domain)
- 동일한 속성 타입들의 값의 집합
- 데이터의 일관성과 정합성 유지
⚙️ 도출 절차
- 속성 목록 수집
- 합성명사 분리
- 공통 명사 추출 → 도메인으로 정의
- 도메인에 속성 할당
- 데이터 타입/길이 지정
🔗 02. 관계 (Relationship)
📌 02-01. 관계란?
- 두 개 이상의 엔터티 간의 연관성
- 하위(자식) 엔터티의 속성으로 관계 표현
관계 유형
구분 | 설명 |
---|---|
종속 관계 | 부모 엔터티 없이는 자식이 존재 불가 |
참조 관계 | 부모 없이도 자식이 존재 가능 (단순 참조용) |
📌 02-02. 관계의 구성 요소

🔁 카디널리티 (Cardinality)
- 관계 수 표현:
- 1:1, 1:M, M:N
- M:N 관계는 교차 엔터티로 분리해 일대다(1:M) 관계로 해소 필요
🔘 옵셔널리티 (Optionality)
- 상위(부모) 엔터티와 하위(자식)엔터티가 서로 연관되는 값이 반드시 존재해야 하는지 존재하지 않아도 되는지를 의미한다.
- 서로 연관되는 값이 반드시 존재하면(최소 1개 이상) Mandatory이다.
- 서로 연관되는 값이 반드시 존재하지 않아도 된다면(최소 0개 이상) Optional이다.
🔺 관계 디그리 (Degree)
- 하나의 관계에 포함된 엔터티의 개수를 뜻한다.
- 하나의 관계는 하나의 엔터티나 두개의 엔터티 뿐 아니라 3개 이상의 엔터티에서도 발생한다.
- 1개체 관계 (Unary Relationship): 한 개의 엔터티가 연관된 관계(재귀 관계(Recursive Relationships))
- 2개체 관계 (Binary Relationships): 두 개의 엔터티가 연관된 관계
- 3개체 관계 (Ternary Relationships): 세 개의 엔터티가 연관된 관계
- N개체 관계 (N-ary Relationships): N개의 엔터티가 연관된 관계
📌 02-03. 특별한 관계 유형
① 일대일 관계 (1:1)

- 각 인스턴스가 오직 하나의 다른 인스턴스와 관계
- 성능 또는 업무 규칙상 나누는 경우도 있음
② 배타 관계 (Exclusive)

- 두 개 이상의 상위(부모) 엔터티와 관계를 가지며 상호 배타적(하위(자식)엔터티의 하나의 인스턴스가 한번에 하나의 부모 엔터티와 관계를 가지게 됨)일 때의 관계를 말한다.
③ 재귀 관계 (Recursive)

- 한 엔터티가 자기 자신과 관계
- 계층 구조(예: 부서 → 상위/하위 부서) 표현에 적합
🧠 01. 개념 모델 (Conceptual Model)
📌 01-01. 개념 모델이란?

💡 개념 모델은 요구사항 분석을 바탕으로 핵심 엔터티와 속성, 그리고 엔터티 간의 관계를 도출하여 상위 수준에서 시스템을 표현하는 데이터 모델입니다.
🔷 01-01-01. UML을 통한 개념 모델링
- 클래스 다이어그램 등 UML을 활용하여 시스템의 구조를 시각적으로 표현할 수 있음
🔷 01-01-02. ERD를 통한 개념 모델링
- ERD(Entity-Relationship Diagram)를 통해 데이터 중심의 모델을 구성
- 주요 엔터티, 속성, 관계를 시각화하여 데이터의 구조와 범위를 파악
🎯 01-02. 개념 모델의 목적
- 다양한 이해관계자(사용자, 기획자, 개발자, 모델러 등)가 공통의 이해를 갖도록 데이터 중심으로 요구사항을 표현
- 업무 흐름과 시스템 구조를 빠르게 파악하여 개발의 큰 틀을 마련
- 개발 이후에도 시스템 유지보수와 확장 시 참고할 수 있는 기준 제공
⚠️ 01-03. 개념 모델의 주의 사항
주의점 | 설명 |
---|---|
충분한 의사소통 | 이해관계자 간 해석의 차이를 줄이기 위한 소통이 필수 |
데이터 중심 표현 | 관계형 모델이므로 데이터만 표현, 프로세스는 제외 |
모델링 기간 확보 | 논리 모델링 시간 중 약 1/3을 투자해도 아깝지 않음 |
복잡성 지양 | 너무 세부적이거나 복잡한 모델은 오히려 혼란을 유발 |
⚠️ 01. 이상 (Anomaly)
📌 01-01. 이상이란?
💡 데이터베이스에 중복된 데이터가 있을 때, 삽입, 수정, 삭제 등의 연산 과정에서 예상치 못한 문제(비정상적 현상)가 발생하는 것을 의미합니다.
이상 현상은 다음과 같이 3가지로 구분됩니다.
📌 01-02. 삽입 이상 (Insertion Anomaly)
- 일부 데이터를 저장하려면 불필요한 정보까지 입력해야 하는 문제
- 예: 상품 정보를 추가하려면 주문번호, 수량도 입력해야만 등록 가능

📌 01-03. 갱신 이상 (Update Anomaly)

- 중복된 데이터 중 일부만 수정되어 데이터 불일치 발생
- 예: 상품의 단가 변경 시, 일부 행만 수정하면 다른 행과 불일치 발생
📌 01-04. 삭제 이상 (Deletion Anomaly)

- 데이터를 삭제할 때 원하지 않는 정보까지 함께 삭제되는 문제
- 예: 주문 삭제 시 상품 정보도 함께 사라지는 현상
🧩 02. 논리 모델 (Logical Model)
📌 02-01. 논리 모델이란?
개념 모델을 구체화하여 속성, 엔터티, 관계를 모두 도출하고
정규화(Normalization)를 통해 이상 현상을 방지하는 단계입니다.
📌 02-02. 논리 모델의 목적
- 요구사항을 명확하게 반영
- 데이터 중복 제거 및 구조 안정성 확보
- 이상 현상 방지를 위한 기반 마련
📌 02-03. 논리 모델의 주의사항
- 모든 업무 요건을 빠짐없이 반영
- 더 이상 제거할 속성이나 엔터티가 없어야 함
- 인조 식별자 사용 여부를 효율성 기준으로 결정
- 성능 최적화보다는 논리적 구조에 집중
📐 03. 정규화 (Normalization)
📌 03-01. 정규화란?
💡 데이터 중복을 제거하고 이상 현상(Anomaly)을 방지하기 위해 릴레이션을 분해하는 작업
🎯 03-01-01. 정규화의 목적
목적 | 설명 |
---|---|
안정성 | 함수 종속을 기반으로 정확한 엔터티 구조 설계 |
확장성 | 구조 변경 시 유연하게 대처 가능 |
🔄 03-01-02. 함수 종속
- 어떤 속성 X의 값이 주어지면, Y의 값이 항상 유일하게 결정되는 관계
X → Y
형태의 종속성
📌 03-02. 정규화 단계
🧩 03-02-01. 제 1 정규형 (1NF)
- 모든 속성은 원자값(단일값)이어야 함
- 복합 속성이나 다가 속성을 분리하거나 테이블로 분해

- 예: 주소를
시, 구, 동
으로 분리 또는 새로운 테이블로 추출
🧩 03-02-02. 제 2 정규형 (2NF)

- 부분 함수 종속 제거
- 기본키의 일부 속성에만 의존하는 속성 분리
🧩 03-02-03. 제 3 정규형 (3NF)

- 이행적 종속 제거
- 일반 속성 간의 종속관계를 분리하여 새로운 테이블 생성
🧩 03-02-04. 보이스-코드 정규형 (BCNF)

- 모든 결정자가 반드시 주식별자(Primary Key)여야 함
🧩 03-02-05. 제 4 정규형 (4NF)

- 다가 종속 속성들 간에 직접적인 관련이 없으면 각각 테이블로 분리
🧩 03-02-06. 제 5 정규형 (5NF)

- 조인 종속성 제거, 무손실 조인과 비부가적 조인이 모두 성립해야 함
- 릴레이션을 분해 후 다시 조인했을 때 원래 릴레이션으로 완벽하게 복원 가능해야 함
🏗️ 01. 물리 모델 (Physical Model)
📌 01-01. 물리 모델이란?
- 실제 DBMS 환경에 맞춰 데이터베이스를 이식, 구현하기 위한 설계 단계
- 테이블 구조보다는 성능 요소 (인덱스, 뷰, 테이블 타입 등)에 중점
- 필요 시 비정규화도 고려
논리적 DB 설계 | 물리적 DB 설계 |
---|---|
DBMS 독립적 | 특정 DBMS에 종속됨 |
📌 01-02. 물리 모델의 목적
- 성능 최적화를 위한 구조 변경 (예: 비정규화, 인덱스 추가 등)
📌 01-03. 주의 사항
- 구조 변경은 전체의 10% 이내가 적절
- SQL 작성 이후 필요한 뷰/인덱스 도출
- 비정규화는 꼭 필요한 경우에만 고려
- 슈퍼타입/서브타입의 물리적 변환 설계 필요
🧬 02. 슈퍼타입과 서브타입
📌 02-01. 개념
- 슈퍼타입: 공통 속성을 가진 상위 엔터티
- 서브타입: 슈퍼타입에서 구분된 세부 엔터티
- 서브타입은 배타적 관계로 관리되는 경우가 많음

예시:
- 소모임 엔터티를 기준으로 요리/코딩/등산 소모임을 서브타입으로 분리
- 실력 구분, 경력 등은 서브타입에 따라 달라짐
📌 02-02. 서브타입의 물리 모델 변환
1️⃣ 통합 엔터티 방식
장점 | 단점 |
---|---|
조회/접근이 간편 (조인 불필요) | 컬럼 수 증가, NULL 속성 증가 |
뷰 활용 가능 | NOT NULL 제약 어려움 |
2️⃣ 서브타입별 엔터티 분리
장점 | 단점 |
---|---|
서브타입 구분 불필요 | 데이터 통합 시 UNION 필요 |
테이블 크기 감소 | UID 관리 복잡 |
3️⃣ NULLABLE 속성 고려

- 배타적 관계일 경우, 서브타입 속성은 NULL 허용이 필요
🚀 03. 성능 개선
📌 03-01. 뷰(View)와 인덱스(Index)
🪟 뷰(View)
- 여러 테이블을 묶어 가상의 테이블 생성
- 권한 제어나 복잡한 쿼리를 단순화 가능
🔍 인덱스(Index)
- WHERE나 JOIN 절에서 사용되는 컬럼에 대해 검색 성능 향상
- 전체 튜플의 10~15% 미만이 조회 대상일 때 효과적
- 기본키는 자동 인덱스 생성
📌 03-02. 비정규화 (Denormalization)
✅ 목적
- 검색 속도 개선, 성능 튜닝
- 정규화로 인한 조인 비용을 줄이기 위함
💡 비정규화의 4가지 유형
수직 분할
→ 속성이 많은 테이블을 그룹화하여 나눔
→ 카디널리티는 1:1 유지수평 분할
→ 자주 조회되는 튜플만 분리 (ex. 상위 20%)
→ 속성은 동일, 관계 없음속성 중복
→ 조인 없이 데이터 사용 가능하지만, 무결성 위험엔터티 통합
→ 자주 조인되는 테이블 통합
→ 이상 현상 주의 필요
🗃️ 04. 테이블 타입
📌 04-01. 문자 데이터 타입
타입 | 설명 |
---|---|
CHAR(n) | 고정길이 문자 |
VARCHAR2(n) | 가변길이 문자 |
NCHAR / NVARCHAR | 유니코드 문자 지원 |
LONG / CLOB / NCLOB | 대용량 문자 |
📌 04-02. 숫자 데이터 타입
타입 | 설명 |
---|---|
NUMBER(P,S) | 정밀한 가변 숫자 |
FLOAT(P) | 부동소수점 |
BINARY_FLOAT / DOUBLE | 이진 부동소수점 (성능 목적) |
📌 04-03. 날짜 데이터 타입
타입 | 설명 |
---|---|
DATE | 연, 월, 일, 시, 분, 초 |
TIMESTAMP | 밀리초까지 지원 |
📌 04-04. LOB (Large Object) 타입
타입 | 설명 |
---|---|
CLOB / NCLOB | 대용량 문자 데이터 |
BLOB | 대용량 이진 데이터 |
BFILE | 외부 파일 위치 정보 저장 |
'Database' 카테고리의 다른 글
[Database] VIEW (0) | 2025.03.23 |
---|---|
[Database] INDEX (0) | 2025.03.23 |
[Database] CONSTRAINTS (0) | 2025.03.23 |
[Database] DDL (0) | 2025.03.23 |
[Database] Database 개요 (0) | 2025.03.23 |
- Total
- Today
- Yesterday
- PMI
- sk ai camp
- KPT
- dictionary
- 회고록
- SQL
- 시퀸스자료형
- 모듈
- database
- Stored Procedure
- 플레이데이터
- 패키지
- procedure
- Python
- sk네트웍스 family ai 캠프 11기
- Databse
- 파이썬
- Constraints
- DBMS
- 자료형
- 분기문
- 튜플
- 모델링
- 조건문
- set
- 클래스
- DDL
- view
- tuple
- 반복문
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | ||
6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 |
20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | 29 | 30 |