본문 바로가기
Database/Database

데이터 베이스 모델링

by curious week 2025. 3. 14.

1. 데이터베이스 모델링 개요

데이터베이스 모델링은 데이터의 의미를 파악하고, 데이터와 관련된 업무 프로세스를 개념적으로 정의하고 분석하는 작업이다.
비즈니스 모델에서 필요한 데이터를 체계적으로 구조화하여 데이터베이스에 저장하고 활용할 수 있도록 모델링하는 과정이다.

1.1 데이터 모델

데이터 모델은 데이터의 의미, 타입, 연산 등을 명시하는 개념적 표기법의 집합이다.
이를 통해 데이터를 효율적으로 저장하고 활용할 수 있도록 한다.

1.2 데이터 모델링

데이터 모델링은 비즈니스에서 요구하는 실세계의 다양한 형태의 데이터를 DBMS에서 효율적으로 저장할 수 있는 구조로 변환하는 과정이다.
이를 위해 다음과 같은 단계를 거친다.

1.3 데이터베이스 모델링 과정

  1. 사용자 요구 분석
    • 데이터를 다룰 업무 및 데이터의 특성을 분석
    • 요구사항을 수집하여 데이터 모델링의 기초를 마련
  2. 개념적 데이터 모델링 (Conceptual Data Modeling)
    • 사용자 요구사항을 바탕으로 데이터를 추상화하고 일반화
    • ER(Entity-Relationship) 모델을 통해 데이터 타입, 속성, 관계, 제약조건 등을 정의
    • 해석 오류를 방지하고, 데이터의 개념적 구조를 명확히 함
  3. 논리적 데이터 모델링 (Logical Data Modeling)
    • 개념적 모델을 바탕으로 DBMS의 구현 모델에 맞춰 데이터 구조 표현
    • 관계형 데이터 모델을 적용하여 테이블 구조를 생성
    • 데이터 정의 언어(DDL)를 활용한 스키마 설계 수행
  4. 물리적 데이터 모델링 (Physical Data Modeling)
    • 논리적 모델을 실제 DBMS에서 최적화하여 구현
    • 데이터 저장 방식, 인덱스 구성, 파일 구조, 접근 경로 등을 결정
    • 효율적인 데이터 저장과 조회 성능을 고려하여 내부 스키마 설계

2. 사용자 요구사항 분석

데이터베이스의 구조가 점점 복잡해지고, 수명 주기가 단축되는 최근 경향에 따라 신속하고 정확한 요구사항 분석이 필수적이다.
요구사항 분석은 도출 → 분석 → 기록 단계를 거쳐 수행된다.

2.1 사용자 요구사항 분석의 필요성

  • 데이터베이스의 복잡성이 증가함에 따라 체계적인 요구사항 정리가 필요하다.
  • 데이터의 변화 속도가 빨라지면서 정확하고 빠른 요구사항 분석이 필수가 되었다.
  • 업무 흐름과 데이터 구조를 명확하게 정의하여 개발과 운영의 오류를 방지할 수 있다.

2.2 요구사항 분석 과정

사용자 요구사항 분석은 제안 요청서(RFP) → 요구사항 도출 → 요구사항 명세서 작성 → 요구사항 분석 → 요구사항 정의서 작성 → 요구사항 기록 단계로 진행된다.

1) 제안 요청서(RFP, Request for Proposal)

  • 프로젝트를 발주하는 측(사용자)이 필요로 하는 기능과 요구사항을 정리한 문서
  • 개발의 목표와 범위를 명확하게 기술

2) 요구사항 도출

  • 업무 관계자 인터뷰 진행
  • 개발 프로젝트의 배경, 목표 및 범위 파악
  • 제안 요청서의 요구사항을 기능별로 분류 및 상세화
  • 외부 자료 수집 및 분석 수행

3) 요구사항 명세서 작성

  • 도출된 요구사항을 체계적으로 문서화
  • 명확한 기술 개요 및 기능별 요구사항 정리

4) 요구사항 분석

  • 제안 요청서 및 명세서를 기반으로 요구사항의 명확성, 완전성, 모호성 검증
  • 기능적 요구사항과 비기능적 요구사항을 분류하여 정리
  • 프로젝트의 위험 요소 분석
  • 용어 정의 및 데이터 구조 분석
  • 사용자 인터페이스 명세화
  • 요구사항이 불완전할 경우 요구사항 도출 단계 재수행

5) 요구사항 정의서 작성

  • 최종적으로 확정된 요구사항을 정의한 문서 작성
  • 요구사항 목록을 정리하고 관리자 승인 절차 수행

6) 요구사항 기록 및 관리

  • 요구사항을 형식에 맞춰 문서화하고 프로젝트 종료까지 지속적으로 관리
  • 변경된 요구사항이 프로젝트 전반에 반영될 수 있도록 지속적 업데이트

3. 요구사항 명세서

요구사항 명세서에는 **기능적 요구사항(Functional Requirements)**과 **비기능적 요구사항(Non-functional Requirements)**을 포함해야 한다.

3.1 기능적 요구사항 (Functional Requirements)

  1. 시스템이 수행해야 하는 주요 기능을 정의
  2. 사용자가 시스템에서 기대하는 동작 및 서비스 제공 내용

예시

  • 회원 가입 및 로그인 기능 제공
  • 상품 조회 및 결제 시스템 지원
  • 게시판에서 글 작성, 수정, 삭제 기능

3.2 비기능적 요구사항 (Non-functional Requirements)

  1. 성능, 보안, 확장성, 유지보수성 등 시스템 품질 관련 요구사항

예시

  • 웹사이트 응답 속도는 2초 이내여야 한다.
  • 데이터베이스는 초당 1,000개의 트랜잭션을 처리할 수 있어야 한다.
  • 사용자의 비밀번호는 암호화되어 저장되어야 한다.

4. IEEE-Std-830 스타일의 요구사항 명세

국제 표준인 IEEE-Std-830 스타일은 요구사항 문서 작성을 위한 표준 형식이다.
이 스타일을 따르면 요구사항의 명확성, 일관성, 검증 가능성을 보장할 수 있다.

4.1 요구사항 문서의 구성 요소

  1. 소개 (Introduction)
    • 프로젝트 개요 및 목적
    • 시스템 범위 정의
    • 문서의 대상 및 참고 문서
  2. 기능적 요구사항 (Functional Requirements)
    • 주요 기능 설명
    • 기능별 입력/출력 데이터 정의
    • 예외 처리 및 오류 처리 방식
  3. 비기능적 요구사항 (Non-functional Requirements)
    • 성능 요구사항
    • 보안 요구사항
    • 확장성 및 유지보수성
  4. 시스템 개요 및 구조 (System Overview)
    • 데이터 흐름도(DFD) 및 시스템 아키텍처 다이어그램 포함
  5. 데이터 요구사항 (Data Requirements)
    • 데이터베이스 스키마 개요
    • 주요 데이터 속성 및 제약 조건
  6. 기타 요구사항 (Additional Requirements)
    • 법적 준수 사항
    • 외부 시스템과의 연동 요구사항

요구사항 분석과 문서화의 중요성

요구사항 분석 및 문서화는 프로젝트의 성패를 좌우하는 중요한 과정이다.
잘 정리된 요구사항은 개발자가 시스템을 올바르게 구현할 수 있도록 가이드하는 역할을 한다.
또한, 요구사항이 변경될 경우 빠르게 반영하여 프로젝트 진행 중 혼란을 방지할 수 있다.


5. ER 모델 (Entity-Relationship Model)

ER 모델은 개체(Entity)와 개체 간의 관계(Relationship)를 정형화하여 표현하는 데이터 모델이다.
데이터 구조와 관계를 **ERD(Entity-Relationship Diagram)**로 표현한다.

5.1 개체 (Entity)

개체(Entity): 현실 세계에 존재하는 유무형의 사물
개체 집합(Entity Set): 같은 속성을 공유하는 개체들의 모임

5.2 관계 (Relationship)

관계(Relationship): 개체와 개체 사이의 연관성
관계 집합(Relationship Set): 개체 집합 간의 연결 관계


6. 속성 (Attributes)

속성은 개체를 구체적으로 설명하는 특성이며, 속성 값의 특성에 따라 여러 종류로 구분된다.

속성의 종류

단순 속성 더 작은 구성 요소로 나눌 수 없는 속성
복합 속성 더 작은 구성 요소로 나눌 수 있는 속성
단일값 속성 한 개체에 대해 하나의 속성 값만 가질 수 있는 속성
다중값 속성 한 개체에 대해 여러 개의 속성 값을 가질 수 있는 속성 ({}로 표현)
유도 속성 다른 속성의 값으로부터 유추될 수 있는 속성
저장 속성 실제 값을 저장해야 하는 속성 (()로 표현)

7. 제약조건 (Constraints)

데이터 모델에서 제약조건은 데이터의 무결성을 유지하기 위한 규칙이다.

7.1 사상수 (Mapping Cardinality)

한 개체 집합의 개체가 다른 개체 집합의 개체와 관계를 맺을 수 있는 수량

  • 1:1 관계 (One-to-One, →)
  • 1:N 관계 (One-to-Many, →)
  • M:N 관계 (Many-to-Many, -)

7.2 참가 제약조건 (Participation Constraints)

개체가 관계 집합에 참여하는 방식에 대한 제한

  • 전체적 참가 (Total Participation): 한 개체 집합의 모든 개체가 관계 집합에 참여 (이중선)
  • 부분적 참가 (Partial Participation): 일부 개체만 관계 집합에 참여 (단일선)

7.3 키 (Key)

각 개체를 구별하는 유일한 속성의 집합

  • 개체를 고유하게 구분하는 역할
  • 관계 집합에서 특정 관계를 찾는 역할

8. 특수 개체 집합

8.1 재귀적 관계 (Recursive Relationship)

한 개체 집합이 자기 자신과 관계를 맺는 경우

8.2 약한 개체 집합 (Weak Entity Set)

개체의 존재가 관계를 맺고 있는 개체의 존재에 종속되는 개체 집합 (이중선으로 표현)
강한 개체 집합과 연결됨

'Database > Database' 카테고리의 다른 글

SQL(3)  (0) 2025.03.28
SQL(2)  (0) 2025.03.28
SQL(1)  (1) 2025.03.28
관계형 모델  (1) 2025.03.14
데이터베이스 개요  (1) 2025.03.05