[SQLD] 1. 데이터모델의 이해
[SQLD] 1. 데이터모델의 이해
데이터 모델링
- 정의
- 비즈니스 요구사항을 분석하고, 데이터의 구조와 관계를 설계하는 과정
- 목적
- 효율적인 데이터 저장과 관리, 데이터 무결성 확보, 비즈니스 규칙 표현
- 중요성
- 데이터베이스 설계의 기초가 되며, 시스템 개발의 성공에 직접적인 영향을 미침
용어 정리
엔터티(Entity)
- 정의
- 현실 세계의 객체나 개념을 데이터베이스 내에서 표현한 것
- 특징
- 업무에서 관리되어야 하는 관심의 대상으로, 명사형으로 표현
- 분류
- 유형 엔터티
- 물리적 형태가 있는 엔터티
- 예시: 사원, 물품, 강의실
- 개념 엔터티
- 개념적으로만 존재하는 엔터티
- 예시: 부서, 프로젝트, 과목
- 사건 엔터티
- 특정 사건이나 이벤트를 표현하는 엔터티
- 예시: 주문, 수강, 예약
- 유형 엔터티
속성(Attribute)
- 정의
- 엔터티가 가진 구체적인 특성으로, 각 엔터티를 설명하는 세부 정보
- 특징
- 하나의 값만 가지며, 다른 속성으로 더 이상 분해될 수 없는 단위
- 분류
- 기본 속성
- 비즈니스 프로세스에서 도출되는 일반적인 속성
- 예시: 고객명, 주문일, 제품명
- 설계 속성
- 데이터 모델링 과정에서 발생하는 속성
- 예시: 고객ID(일련번호), 주문번호
- 파생 속성
- 다른 속성에서 계산되어 생성되는 속성
- 예시: 나이(생년월일로 계산), 주문 총액(수량 × 단가)
- 기본 속성
인스턴스(Instance)
- 정의
- 엔터티의 개별 사례 또는 실제 데이터로, 한 행(row)에 해당하는 데이터
- 예시
- ‘홍길동’ : 고객 엔터티의 인스턴스
- ‘아이폰 15’ : 제품 엔터티의 인스턴스
관계(Relationship)
- 정의
- 엔터티 간의 연관성을 표현한 것
- 표현 방식
- “~은 ~을 가진다”, “~은 ~에 속한다” 등으로 표현
- 분류
- 1:1 관계
- 두 엔터티 간에 하나의 인스턴스가 서로 한 개씩 대응되는 관계
- 예시: 사용자와 프로필
- 1:N 관계
- 한 엔터티의 하나의 인스턴스가 다른 엔터티의 여러 인스턴스와 대응되는 관계
- 예시: 고객과 주문
- N:M 관계
- 양쪽 엔터티의 인스턴스가 서로 여러 개와 대응될 수 있는 관계
- 예시: 학생과 과목
erDiagram "사용자" ||--|| "프로필" : "1:1" "고객" ||--o{ "주문" : "1:N" "학생" }o--o{ "과목" : "N:M" - 1:1 관계
식별자(Identifier)
- 정의
- 각 인스턴스를 유일하게 구분할 수 있는 속성 또는 속성의 집합
- 분류
- 기본키(Primary Key): 엔터티 내에서 각 인스턴스를 유일하게 식별하는 속성
- 외래키(Foreign Key): 다른 엔터티와의 관계를 표현하는 속성
- 예시: 고객 엔터티의 고객ID, 주문 엔터티의 주문번호
특징
단순화 (Simplification)
- 복잡한 현실 세계를 단순화하여 핵심 개념만 추출
- 비즈니스 규칙에서 핵심적인 요소만을 식별하고 불필요한 세부 사항 제거
- 예시: 온라인 쇼핑몰에서 고객의 모든 정보가 아닌, 주문과 관련된 필수 정보만 모델링
추상화 (Abstraction)
- 비즈니스 요구사항에서 본질적인 요소를 도출하여 일반화
- 구체적인 구현 방법보다는 “무엇”을 저장할지에 집중
- 예시: 회원 가입 시 입력하는 여러 항목 중에서 필요한 데이터만 추출하여 ‘고객’ 엔터티로 추상화
명확화 (Clarity)
- 데이터의 구조와 관계를 명확하게 정의하여 모호함 제거
- 모든 이해관계자가 동일하게 이해할 수 있도록 표준화된 표기법 사용
- 예시: ERD를 통해 ‘고객’과 ‘주문’의 관계를 1:N으로 명확하게 표현
모델링 관점
데이터 관점
- 정의
- 데이터의 저장, 접근, 관리 등 데이터 자체에 관한 정의
- 중점사항
- 데이터 구조, 관계, 제약조건을 명확히 정의
- 도구
- ERD(Entity-Relationship Diagram)를 주로 사용
- 예시: 고객 테이블과 주문 테이블 간의 관계를 정의하고, 각 테이블의 컬럼과 제약조건 설계
프로세스 관점
- 정의
- 비즈니스 프로세스와 데이터가 어떻게 상호작용하는지 분석
- 중점사항
- 데이터 흐름, 업무 절차, 데이터 변환 과정 정의
- 도구
- DFD(Data Flow Diagram), UML 활동 다이어그램 등 활용
- 예시: 주문 처리 프로세스에서 고객 확인, 재고 확인, 결제 처리, 배송 지시 등의 단계별 데이터 흐름 정의
데이터와 프로세스 관점
- 정의
- 두 관점을 동시에 고려하여, 데이터와 업무 흐름의 상관관계 파악
- 중점사항
- 데이터가 어떤 프로세스에 의해 생성, 수정, 삭제되는지 정의
- 도구
- CRUD 매트릭스, UML 클래스 다이어그램, 시퀀스 다이어그램 등
- 예시: 주문, 취소, 반품 등의 프로세스가 고객, 주문, 상품, 재고 데이터에 어떤 영향을 미치는지 매트릭스로 정의
모델링 유의점
중복 (Duplication)
- 문제점
- 동일 데이터가 여러 곳에 중복 저장되면 데이터 일관성 유지가 어려움
- 해결방안
- 정규화를 통해 데이터 중복을 최소화하고, 필요한 경우 뷰(View)를 활용
- 예시: 고객 정보가 고객 테이블과 주문 테이블에 모두 저장되어 있다면, 고객 정보 변경 시 모든 테이블을 업데이트해야 하는 문제 발생
비유연성 (Inflexibility)
- 문제점
- 변화하는 비즈니스 요구사항에 대응하지 못하는 경직된 데이터 구조
- 해결방안
- 데이터 정의를 프로세스와 분리하고, 변경 가능성을 고려한 유연한 설계
- 예시: 회원의 결제 방식을 카드로만 제한했다가 계좌이체, 페이 등 다양한 결제 방식이 추가될 때 대응하기 어려운 구조
비일관성 (Inconsistency)
- 문제점
- 데이터베이스 내의 정보가 모순되거나 상반된 내용을 갖는 상태
- 해결방안
- 데이터 간 상호연관 관계를 명확히 정의
- 제약조건을 통한 데이터 무결성 확보
- 트랜잭션 관리를 통한 일관성 유지
- 예시: 주문 테이블에는 배송 완료로 표시되어 있지만, 배송 테이블에는 배송 중으로 표시되는 경우
모델링의 3가지 요소
대상 (Object)
- 정의
- 모델링할 실제 비즈니스 대상으로, 엔터티로 표현됨
- 식별 방법
- 비즈니스 프로세스에서 관리되어야 할 핵심 개념 추출
- 예시: 고객, 주문, 제품, 배송, 결제 등
속성 (Attribute)
- 정의
- 대상이 가진 특징으로, 하나의 값을 가지는 더 이상 분해할 수 없는 단위
- 식별 방법
- 각 엔터티가 가져야 할 특성 및 요구되는 데이터 항목 정의
- 예시: 고객의 이름, 주문의 날짜, 제품의 가격 등
관계 (Relationship)
- 정의
- 대상 간의 연결 고리로, 비즈니스 규칙을 반영
- 식별 방법
- 엔터티 간의 상호작용 및 연관성 분석
- 예시: 고객과 주문은 1:N 관계, 주문과 제품은 N:M 관계
데이터 모델링 단계
개념적 모델링 (Conceptual Modeling)
- 정의
- 비즈니스 관점에서 핵심 엔터티와 관계를 식별하는 단계
- 목적
- 비즈니스 요구사항 정의 및 범위 설정
- 산출물
- 개념적 ERD(엔터티-관계 다이어그램)
- 주요 활동
- 핵심 엔터티 식별 및 정의
- 엔터티 간 관계 파악
- 업무 규칙 및 제약사항 정의
- 대략적인 엔터티-관계 다이어그램 작성
- 특징
- 실제 데이터베이스 구현 세부사항을 고려하지 않음
- 비즈니스 관점에서 높은 수준의 추상화
- 비기술적 용어 사용으로 모든 이해관계자가 이해 가능
- 예시: 쇼핑몰 도메인에서 고객(Customer), 주문(Order), 제품(Product), 배송(Shipment), 결제(Payment) 등의 주요 엔터티를 도출하고 이들 간의 관계를 표현
논리적 모델링 (Logical Modeling)
- 정의
- 개념적 모델에 식별된 엔터티와 관계에 대해 상세한 속성을 정의하는 단계
- 목적
- DBMS에 독립적인 논리적 데이터 구조 설계
- 산출물
- 정규화된 논리적 ERD, 속성 정의서, 관계 정의서
- 주요 활동
- 엔터티별 세부 속성(칼럼) 정의
- 주식별자(PK) 및 외래식별자(FK) 지정
- 정규화 수행 (1NF~5NF)
- 엔터티 간 관계(1:1, 1:N, N:M) 상세 정의
- 제약조건 설정 (필수값, 유일성 등)
- 특징
- DBMS에 독립적인 모델링
- 데이터 중복 최소화 및 무결성 확보를 위한 정규화 적용
- N:M 관계의 해소 (교차 엔터티 생성)
- 예시
- 고객(Customer): 고객ID(PK), 이름, 이메일, 전화번호, 주소, 가입일자
- 주문(Order): 주문ID(PK), 고객ID(FK), 주문일시, 총금액, 주문상태
- 제품(Product): 제품ID(PK), 제품명, 가격, 카테고리, 재고수량, 설명
- 주문상세(OrderDetail): 주문상세ID(PK), 주문ID(FK), 제품ID(FK), 수량, 단가
- 관계: 고객(1) - 주문(N), 주문(1) - 주문상세(N), 제품(1) - 주문상세(N)
물리적 모델링 (Physical Modeling)
- 정의
- 논리적 모델을 특정 DBMS에 맞게 구현하기 위한 물리적 스키마 설계 단계
- 목적
- 실제 데이터베이스 성능과 효율성을 고려한 구현 계획 수립
- 산출물
- 테이블 정의서, 인덱스 정의서, SQL DDL 스크립트
- 주요 활동
- 테이블, 컬럼, 제약조건 등의 물리적 명세 작성
- 인덱스 설계 및 최적화
- 데이터 타입, 길이, NULL 허용 여부 등 세부 사항 정의
- 파티셔닝, 클러스터링 등 성능 관련 설계
- SQL DDL 스크립트 작성
- 특징
- 특정 DBMS의 특성 반영 (MySQL, Oracle, SQL Server 등)
- 데이터 용량, 처리 성능, 접근 빈도 등을 고려한 최적화
- 실제 운영 환경을 고려한 현실적인 설계
- 고려사항
- 성능: 쿼리 실행 속도, 처리량
- 보안: 데이터 접근 제어, 암호화
- 가용성: 백업, 복구, 고가용성 설계
- 확장성: 데이터 증가에 대비한 설계
예시 코드
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
31
32
33
34
35
-- 고객 테이블: 각 고객을 고유하게 식별하는 CustomerID 사용
CREATE TABLE Customer (
CustomerID INT PRIMARY KEY,
CustomerName VARCHAR(100) NOT NULL,
Email VARCHAR(100) UNIQUE NOT NULL,
Phone VARCHAR(20)
);
-- 제품 테이블: 제품의 상세 정보 관리
CREATE TABLE Product (
ProductID INT PRIMARY KEY,
ProductName VARCHAR(100) NOT NULL,
Price DECIMAL(10,2) NOT NULL,
Stock INT DEFAULT 0
);
-- 주문 테이블: 고객 주문 정보 관리
CREATE TABLE OrderTable (
OrderID INT PRIMARY KEY,
CustomerID INT NOT NULL,
OrderDate DATE NOT NULL,
TotalAmount DECIMAL(10,2),
FOREIGN KEY (CustomerID) REFERENCES Customer(CustomerID)
);
-- 주문 상세 테이블: 주문 내 제품 정보 (다대다 관계를 분해)
CREATE TABLE OrderDetail (
OrderDetailID INT PRIMARY KEY,
OrderID INT NOT NULL,
ProductID INT NOT NULL,
Quantity INT NOT NULL,
UnitPrice DECIMAL(10,2) NOT NULL,
FOREIGN KEY (OrderID) REFERENCES OrderTable(OrderID),
FOREIGN KEY (ProductID) REFERENCES Product(ProductID)
);
스키마 3단계와 스키마 독립성
- 사용자 관점과 실제 구현 방식을 명확히 분리하기 위해 외부 스키마(External Schema), 개념 스키마(Conceptual Schema), 내부 스키마(Internal Schema)의 3단계로 나눔
- ANSI/SPARC 아키텍처로도 알려져 있으며, 데이터베이스 시스템의 복잡성을 관리하고 유연성을 향상시키는 데 중요한 역할
스키마의 종류
외부 스키마 (External Schema)
- 정의
- 사용자나 애플리케이션별로 필요한 데이터의 뷰(View)를 정의
- 특징
- 각 사용자 그룹이 데이터베이스를 어떻게 보는지 정의하는 사용자 관점의 스키마, 여러 개의 외부 스키마가 존재하며, 각 사용자 그룹의 요구사항에 맞게 커스터마이징됨
- 목적
- 불필요한 데이터는 숨기고 필요한 데이터만 노출하여 보안성을 강화
예시
1 2 3 4 5 6 7 8 9 10
-- 영업부서를 위한 외부 스키마 (고객 정보와 주문 정보만 포함) CREATE VIEW Sales_CustomerOrders AS SELECT c.customer_id, c.name, c.phone, o.order_id, o.order_date, o.total_amount FROM Customers c JOIN Orders o ON c.customer_id = o.customer_id; -- 인사부서를 위한 외부 스키마 (직원 정보만 포함, 급여 정보 제외) CREATE VIEW HR_EmployeeInfo AS SELECT employee_id, name, department, position, hire_date FROM Employees;
개념 스키마 (Conceptual Schema)
- 정의
- 전체 데이터베이스의 논리적 구조를 정의하며, 엔터티, 속성, 관계, 제약조건 등이 포함됨
- 특징
- 데이터베이스의 전체적인 뷰를 제공하며, 한 조직 내에서는 보통 하나만 존재
- 목적
- 데이터 무결성과 일관성을 유지하기 위한 규칙을 정의
예시
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
-- 고객 테이블 생성 (개념 스키마의 일부) CREATE TABLE Customers ( customer_id INT PRIMARY KEY, name VARCHAR(100) NOT NULL, email VARCHAR(100) UNIQUE, phone VARCHAR(20), address VARCHAR(200), registration_date DATE DEFAULT CURRENT_DATE ); -- 주문 테이블 생성 (개념 스키마의 일부) CREATE TABLE Orders ( order_id INT PRIMARY KEY, customer_id INT NOT NULL, order_date TIMESTAMP DEFAULT CURRENT_TIMESTAMP, total_amount DECIMAL(10,2) NOT NULL, status VARCHAR(20) DEFAULT 'Pending', FOREIGN KEY (customer_id) REFERENCES Customers(customer_id) );
내부 스키마 (Internal Schema)
- 정의
- 실제 데이터 저장 방식, 파일 구조, 인덱스, 저장소 최적화 등을 정의
- 특징
- 데이터베이스의 물리적 구현 방식을 반영하며, 성능과 효율성에 직접적인 영향을 미침
- 목적
- 실제 저장 장치에서의 레코드 구조, 저장 경로, 인덱싱 방법 등을 포함
- 관리
- DBMS 및 하드웨어 종속적인 부분으로, 시스템 관리자나 DBA(Database Administrator)가 주로 관리
예시
1 2 3 4 5 6 7 8 9 10 11 12 13 14
-- 주문 테이블에 인덱스 생성 (내부 스키마의 일부) CREATE INDEX idx_orders_customer ON Orders(customer_id); -- 자주 조회되는 주문 상태에 대한 인덱스 추가 CREATE INDEX idx_orders_status ON Orders(status); -- 테이블스페이스 설정 (Oracle 예시) CREATE TABLESPACE orders_tbs DATAFILE 'orders_data.dbf' SIZE 500M AUTOEXTEND ON NEXT 100M MAXSIZE 2000M; -- 주문 테이블의 물리적 저장 위치 지정 ALTER TABLE Orders MOVE TABLESPACE orders_tbs;
스키마 독립성
- 데이터베이스의 한 수준에서 변경이 발생했을 때, 다른 수준에 영향을 미치지 않도록 하는 개념
- 데이터베이스 시스템의 유연성과 확장성을 크게 향상
논리적 독립성 (Logical Independence)
- 정의
- 개념 스키마와 외부 스키마 간의 독립성
- 특징
- 개념 스키마가 변경되어도 외부 스키마는 영향을 받지 않음
- 목적
- 새로운 엔터티나 관계가 추가되거나 기존 구조가 변경되어도 사용자 뷰는 일관성을 유지할 수 있음
- 실제 구현 방법
- 외부 스키마를 뷰(View)로 구현하여 기본 테이블의 변경에도 뷰 정의만 수정하면 됨
예시
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
1. 기존 상황: - 개념 스키마: Customers 테이블(customer_id, name, contact_info) - 외부 스키마: Customer_Contact_View(customer_id, name, contact_info) 2. 개념 스키마 변경: - Customers 테이블에서 contact_info 컬럼을 email과 phone으로 분리 3. 독립성 유지 방법: - 외부 스키마(뷰)를 재정의하여 기존 인터페이스 유지 CREATE OR REPLACE VIEW Customer_Contact_View AS SELECT customer_id, name, CONCAT(email, ' / ', phone) AS contact_info FROM Customers; 4. 결과: 애플리케이션은 변경 없이 계속 동일한 뷰를 사용할 수 있음
물리적 독립성 (Physical Independence)
- 정의
- 내부 스키마와 개념 스키마 간의 독립성
- 특징
- 물리적 저장 구조, 인덱싱 방법, 접근 경로 등이 변경되어도 개념 스키마와 외부 스키마는 영향을 받지 않음
- 목적
- 하드웨어 업그레이드, 성능 최적화, 파일 구조 변경 등에 유연하게 대응할 수 있음
- 관리
- DBMS가 내부적으로 처리하며, 논리적 데이터 접근 방식은 동일하게 유지
예시 시나리오
1 2 3 4 5 6 7 8 9 10
1. 기존 상황: - 내부 스키마: 데이터는 'orders_data.dbf'에 저장되고, 인덱스는 idx_orders_customer로 설정됨 - 개념 스키마: Orders 테이블 (order_id, customer_id, total_amount) 2. 물리적 변경: - 데이터 파일을 새로운 저장소로 이동하거나 인덱스 방법을 변경 3. 독립성 유지 방법: - 물리적 스키마 변경이 이루어져도 개념 스키마와 외부 스키마는 영향을 받지 않음 - 쿼리는 여전히 동일한 방식으로 실행됨
ERD
- 데이터베이스의 논리적 구조를 시각적으로 표현
- 데이터베이스 설계의 핵심 문서로, 개발자, 분석가, 그리고 비즈니스 이해관계자 간의 의사소통을 원활하게 해줌
ERD의 주요 구성 요소
엔터티 (Entity)
- 정의
- 현실 세계의 객체나 개념을 데이터베이스 내에서 표현
- 특징
- 엔터티 이름은 명사형으로, 단수 형태로 작성
- 각 엔터티는 최소한 하나의 인스턴스(행)를 가질 수 있어야 함
- 표기
- 강한 엔터티(Strong Entity): 단일 사각형
- 약한 엔터티(Weak Entity): 이중 사각형
예시
erDiagram CUSTOMER { int customer_id PK string name string email }
속성 (Attribute)
- 정의
- 엔터티의 특성이나 성질을 설명하는 데이터 항목
- 예시: 고객의 이름, 주문 날짜
- 특징
- 주 식별자(PK)는 보통 밑줄이나 별도의 표기로 표시
- 단일값 속성(Single-valued)과 다중값 속성(Multi-valued)으로 구분
- 파생 속성(Derived Attribute): 다른 속성에서 계산될 수 있는 속성
예시
1 2 3 4 5 6 7 8 9
┌─────────────────────┐ │ Customer │ ├─────────────────────┤ │ customer_id (PK) │ │ name │ │ email │ │ phone │ │ address │ └─────────────────────┘
관계 (Relationship)
- 정의
- 엔터티 간의 연관성을 표현하는 요소
- 특징
- 관계명은 동사형으로 표현
- 관계의 차수(Cardinality)를 1:1, 1:N, N:M 등으로 명시
- 관계에 참여하는 최소/최대 인스턴스 수를 표시 (선택적/필수적 참여)
- 관계 자체가 속성을 가질 수도 있음
- 예시: 주문-제품 관계에서의 주문 수량
예시
erDiagram CUSTOMER ||--o{ ORDER : places ORDER }o--|| CUSTOMER : "belongs to"
ERD 작성 절차
1. 요구사항 분석
- 비즈니스 요구사항과 규칙을 파악하여 도메인 내 핵심 개념 및 프로세스를 분석
- 사용자 인터뷰, 문서 검토 등을 통해 필요한 데이터를 도출
예시
1 2 3 4 5 6 7
온라인 서점 시스템 개발 요구사항: 1. 고객은 여러 권의 책을 주문할 수 있다. 2. 각 책은 제목, 저자, 출판사, 가격, ISBN 정보를 가진다. 3. 고객은 이름, 이메일, 전화번호, 배송지 주소 정보를 가진다. 4. 주문은 주문일자, 배송상태, 결제방법, 총액 정보를 포함한다. 5. 각 책은 여러 카테고리에 속할 수 있다. 6. 고객이 리뷰를 작성할 수 있으며, 리뷰는 평점과 코멘트를 포함한다.
2. 엔터티 식별
- 도메인의 주요 객체(명사)를 엔터티로 식별
- 강한 엔터티와 약한 엔터티를 구분
예시
1 2 3 4 5 6
1. Customer (고객) 2. Book (책) 3. Order (주문) 4. Category (카테고리) 5. Review (리뷰) 6. OrderItem (주문항목) - 주문과 책의 N:M 관계를 해소하기 위한 연결 엔터티
3. 속성 결정
- 각 엔터티가 가져야 할 세부 속성을 정의
- 기본키(Primary Key)와 외래키(Foreign Key)를 식별
- 필수 속성과 선택적 속성 구분
- 복합 속성, 다중값 속성, 파생 속성 등을 고려
예시
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
Book 엔터티의 속성: - book_id (PK): 책 식별자 - title: 책 제목 - author: 저자 - publisher: 출판사 - price: 가격 - isbn: ISBN 코드 - publication_date: 출판일 - stock_quantity: 재고 수량 Order 엔터티의 속성: - order_id (PK): 주문 식별자 - customer_id (FK): 고객 식별자 - order_date: 주문일자 - status: 배송상태 - payment_method: 결제방법 - total_amount: 주문 총액
4. 관계 정의
- 엔터티 간의 관계와 연결 규칙(1:1, 1:N, N:M)을 설정
- N:M 관계는 필요에 따라 연결 엔터티로 해소
예시
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
1. Customer (1) ---places---> (N) Order (한 고객이 여러 주문을 할 수 있음) 2. Order (1) ---contains---> (N) OrderItem (한 주문은 여러 주문항목을 포함함) 3. Book (1) ---included in---> (N) OrderItem (한 책은 여러 주문항목에 포함될 수 있음) 4. Book (N) ---belongs to---> (M) Category (한 책은 여러 카테고리에 속할 수 있고, 한 카테고리는 여러 책을 포함할 수 있음) => BookCategory 연결 엔터티로 해소 5. Customer (1) ---writes---> (N) Review (한 고객이 여러 리뷰를 작성할 수 있음) 6. Book (1) ---receives---> (N) Review (한 책은 여러 리뷰를 받을 수 있음)
5. 식별자 설정
- 각 엔터티의 고유 식별자(주식별자)를 지정
- 자연키(Natural Key)와 대리키(Surrogate Key) 중 적절한 방식을 선택
- 복합키 사용 검토
- 외래키를 통해 엔터티 간 참조 무결성을 설정
예시
1 2 3 4 5 6 7
1. Customer: customer_id (대리키, 일련번호) 2. Book: book_id (대리키, 일련번호) - ISBN을 자연키로 고려했으나 변경 가능성 때문에 대리키 선택 3. Order: order_id (대리키, 일련번호) 4. OrderItem: order_id + book_id (복합키) 5. Category: category_id (대리키) 6. Review: review_id (대리키) 7. BookCategory: book_id + category_id (복합키)
6. ERD 작성
- 도출된 정보를 바탕으로 ERD 도구(예: draw.io, ERwin, MySQL Workbench 등)를 사용하여 다이어그램을 작성
- 엔터티, 속성, 관계, 카디널리티, 참여도를 명확히 표기
- 필요시 주석이나 보충 설명 추가
예시
erDiagram CUSTOMER ||--o{ ORDER : places CUSTOMER ||--o{ REVIEW : writes BOOK ||--o{ REVIEW : receives BOOK ||--o{ ORDER_ITEM : "included in" ORDER ||--o{ ORDER_ITEM : contains BOOK }|--|| PUBLISHER : "published by" BOOK }o--o{ CATEGORY : "belongs to" CUSTOMER { int customer_id PK string name string email UK string phone string address date registration_date } BOOK { int book_id PK string title string author int publisher_id FK decimal price string isbn UK date publication_date int stock_quantity } ORDER { int order_id PK int customer_id FK date order_date string status string payment_method decimal total_amount } ORDER_ITEM { int order_id PK,FK int book_id PK,FK int quantity decimal price } CATEGORY { int category_id PK string name string description } REVIEW { int review_id PK int customer_id FK int book_id FK int rating string comment date review_date } PUBLISHER { int publisher_id PK string name string address string contact }
데이터 모델 표기법의 종류
1. Chen 표기법
- 피터 첸(Peter Chen)이 제안한 가장 전통적인 ERD 표기법
- 엔터티는 사각형, 관계는 마름모, 속성은 타원으로 표시
- 관계의 카디널리티는 선 위에 1, N, M 등으로 표시
- 직관적이지만 복잡한 모델에서는 공간을 많이 차지함
2. Crow’s Foot 표기법
- 가장 널리 사용되는 표기법 중 하나로, 관계의 끝에 까마귀 발 모양으로 N을 표시
- 엔터티는 사각형으로 표시하며, 속성은 엔터티 내부에 나열
관계의 필수/선택적 참여는 선의 시작 부분에 (필수) 또는 O (선택적)으로 표시 - 직관적이고 공간 효율적이어서 실무에서 많이 사용
3.IE (Information Engineering) 표기법**
- 엔터티는 사각형, 관계는 선으로 표시
- 기본키(PK)와 외래키(FK)를 명확히 구분
- 관계 카디널리티를 Crow’s Foot과 유사하게 표시하지만 세부 표기에 차이가 있음
- 많은 CASE(Computer-Aided Software Engineering) 도구에서 채택한 방식
4. UML 클래스 다이어그램
- 객체지향 분석과 설계에서 사용되는 표기법
- 엔터티는 클래스로 표현되며, 속성과 메서드를 포함할 수 있음
- 관계는 연관(association), 집합(aggregation), 합성(composition) 등 다양한 유형으로 표현
- 데이터베이스 설계 외에도 소프트웨어 구조 설계에도 활용
| 표기법 | 엔터티 표현 | 관계 표현 | 속성 표현 |
|---|---|---|---|
| Chen | 사각형 | 마름모(관계) | 타원(속성) |
| Crow’s Foot | 사각형 | ` | |
| IE | 사각형 | ` | |
| UML 클래스 | 클래스 다이어그램 | 1..* 등의 표기 사용 | 속성과 메서드 포함 가능 |
This post is licensed under CC BY 4.0 by the author.