티스토리 뷰

반응형

📌 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)

  • 동일한 속성 타입들의 값의 집합
  • 데이터의 일관성과 정합성 유지

⚙️ 도출 절차

  1. 속성 목록 수집
  2. 합성명사 분리
  3. 공통 명사 추출 → 도메인으로 정의
  4. 도메인에 속성 할당
  5. 데이터 타입/길이 지정

🔗 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:1 유지

  2. 수평 분할
    → 자주 조회되는 튜플만 분리 (ex. 상위 20%)
    → 속성은 동일, 관계 없음

  3. 속성 중복
    → 조인 없이 데이터 사용 가능하지만, 무결성 위험

  4. 엔터티 통합
    → 자주 조인되는 테이블 통합
    → 이상 현상 주의 필요


🗃️ 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
링크
«   2025/04   »
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
글 보관함