ERD(Entity-Relationship Diagram) 표기법 3종(Chen·IE·Crow's Foot) 비교와
데이터베이스 설계 3단계(개념적·논리적·물리적) 완벽 가이드. 정보처리기사 시험 출제 범위,
dbdiagram.io·ERD Cloud·Mermaid·AI ERD 생성 도구, MySQL DDL 변환까지. 2026.05 업데이트.
요약 (Quick Answer) — ERD 한눈에
ERD란? Entity-Relationship Diagram(개체-관계 다이어그램). 데이터베이스 설계 시 엔티티(테이블)와 관계를 시각적으로 표현하는 다이어그램.
데이터베이스 설계 3단계:
| 단계 | 목적 | 산출물 | 사용 표기법 |
|---|---|---|---|
| 1. 개념적 설계 | 무엇을 저장할지 정의 | 개념적 ERD | Chen |
| 2. 논리적 설계 | DBMS 종류 결정 후 매핑 | 논리적 ERD + 정규화 | IE, Crow's Foot |
| 3. 물리적 설계 | 실제 DBMS 스키마 | DDL(CREATE TABLE) + 인덱스 | Crow's Foot |
ERD 표기법 3대 표준 (2026):
| 표기법 | 별명 | 특징 | 사용처 |
|---|---|---|---|
| Chen | 박스+다이아몬드 | 학술적, 상세함 | 개념적 모델링, 교과서 |
| IE (Information Engineering) | Martin notation | 산업 표준 | 일반 기업 |
| Crow's Foot ⭐ | 까마귀 발 | 현장에서 가장 많이 사용 | dbdiagram·ERD Cloud·Vertabelo |
2026 추천 도구:
- 무료: dbdiagram.io, ERD Cloud, Mermaid (코드로 ERD)
- GUI: DBeaver, MySQL Workbench
- AI 생성: ChatGPT·Claude에게 "이 테이블들로 ERD 그려줘" 한 줄로 Mermaid 코드 생성
검증 환경: 정보처리기사·기술사 출제 기준 / MySQL 8 / 2026.05 업데이트
ERD(Entity-Relationship Diagram)란?
ERD는 데이터베이스에 저장될 데이터와 관계를 시각적으로 표현하는 다이어그램입니다. 1976년 Peter Chen이 발표한 ER 모델이 모든 현대 데이터베이스 설계의 출발점입니다.
ERD의 3가지 핵심 구성요소
| 구성요소 | 의미 | 표현 (Crow's Foot) |
|---|---|---|
| 엔티티(Entity) | 정보를 저장할 대상 (회원, 주문, 상품) | 사각형 |
| 속성(Attribute) | 엔티티의 특성 (이름, 가격, 날짜) | 사각형 안 필드 목록 |
| 관계(Relationship) | 엔티티 간 연결 (1:1, 1:N, N:M) | 선과 카디널리티 기호 |
카디널리티(Cardinality) — 관계의 수량
| 관계 | 의미 | 예시 |
|---|---|---|
| 1:1 | 일대일 | 사람과 주민등록번호 |
| 1:N | 일대다 | 출판사와 책 (한 출판사가 여러 책) |
| N:M | 다대다 | 학생과 강의 (보통 중간 테이블로 분해) |
데이터베이스 설계 3단계
데이터베이스 설계는 개념적 모델링 → 논리적 모델링 → 물리적 모델링 세 단계로 진행됩니다.
1단계: 개념적 설계 (Conceptual Design)
- 목적: "무엇을 저장할 것인가?"
- DBMS 무관: 어떤 데이터베이스를 쓸지 결정하지 않은 상태
- 산출물: 개념적 ERD (엔티티·속성·관계만 표현)
- 표기법: Chen 표기법이 전통
- 예: "구독자가 출판사의 책을 구독한다" 같은 비즈니스 규칙 시각화
2단계: 논리적 설계 (Logical Design)
- 목적: "관계형 DB로 어떻게 매핑할 것인가?"
- DBMS 종류 결정: RDBMS/NoSQL/그래프 등
- 산출물: 논리적 ERD + 정규화된 테이블 구조
- 표기법: IE 또는 Crow's Foot
- 추가 작업: 정규화(1NF~3NF), 기본키·외래키 정의
3단계: 물리적 설계 (Physical Design)
- 목적: "특정 DBMS에 어떻게 구현할 것인가?"
- DBMS 버전 명시: MySQL 8, PostgreSQL 15, Oracle 23ai 등
- 산출물: DDL(CREATE TABLE), 인덱스 전략, 파티셔닝
- 표기법: Crow's Foot (실제 컬럼·타입·인덱스 포함)
- 추가 작업: 성능 최적화, 인덱스 설계, 저장공간 계산
💡 현장 팁: 작은 프로젝트는 1단계를 생략하고 2단계부터 시작하는 경우가 많습니다. 다만 시험에서는 3단계 모두 묻는 것이 일반적입니다.
ERD 표기법 3대 표준 비교 — Chen vs IE vs Crow's Foot
| 항목 | Chen | IE (Martin) | Crow's Foot |
|---|---|---|---|
| 개발자 | Peter Chen (1976) | James Martin (1989) | Gordon Everest (1976) |
| 엔티티 표현 | 사각형 (이름만) | 사각형 + 속성 목록 | 사각형 + 속성 목록 ⭐ |
| 속성 표현 | 타원형으로 별도 | 사각형 안 필드 목록 | 사각형 안 필드 목록 |
| 관계 표현 | 다이아몬드 | 선 + 라벨 | 선 + 카디널리티 기호 |
| 카디널리티 | 1, N, M 숫자 표기 | 1, N, M | 까마귀 발 모양 ⭐ |
| 선호 단계 | 개념적 설계 | 논리적·물리적 | 논리적·물리적 ⭐ |
| 현장 사용 빈도 | 낮음 (학술용) | 중간 | 가장 높음 ⭐ |
| 도구 지원 | 제한적 | 전통적 CASE 도구 | 거의 모든 도구 |
| 정보처리기사 출제 | ✅ | ✅ | ✅ |
Chen 표기법 예시
[구독자] ── 〈구독〉 ── [출판사]
│
타원: 고객번호, 이름, 나이엔티티는 사각형, 속성은 타원, 관계는 다이아몬드. 시각적으로 가장 풍부하지만 큰 ERD에서는 복잡해집니다.
IE (Martin) 표기법 예시
┌─────────────┐ ┌─────────────┐
│ 구독자 │1───N│ 출판사 │
├─────────────┤ ├─────────────┤
│ PK 고객번호 │ │ PK 발행호 │
│ 이름 │ │ 발송일 │
└─────────────┘ └─────────────┘엔티티 박스 안에 속성을 나열. 1·N 숫자로 카디널리티 표현.
Crow's Foot 표기법 예시 ⭐
┌─────────────┐ ┌─────────────┐
│ 구독자 │||───∈│ 출판사 │
├─────────────┤ ├─────────────┤
│ PK 고객번호 │ │ PK 발행호 │
│ 이름 │ │ 발송일 │
└─────────────┘ └─────────────┘||= "정확히 1개"∈(까마귀 발) = "0개 이상 N개"|∈= "1개 이상 N개"
Crow's Foot 표기법은 까마귀 발 모양 세 줄 기호로 관계의 "many" 쪽을 표현하며, 카디널리티와 modality를 명확히 보여주기 때문에 2026년 현장에서 가장 널리 사용됩니다.
어떤 걸 선택해야 하나?
| 상황 | 추천 |
|---|---|
| 학교 과제, 교과서, 학술 논문 | Chen |
| 일반 기업 데이터 모델링 | Crow's Foot ⭐ |
| 정보처리기사·기술사 시험 | 세 가지 모두 출제 가능 — 모두 익히기 |
| 현대 도구(dbdiagram, ERD Cloud) 사용 | Crow's Foot (기본 표기법) |
| Mermaid·PlantUML로 코드 ERD | Crow's Foot (지원 표기법) |
정규화(Normalization) 핵심 3단계
논리적 설계 단계에서 데이터 중복을 줄이고 무결성을 보장하기 위한 과정입니다.
1NF (제1정규형)
규칙: 모든 컬럼이 원자값(atomic)이어야 함.
❌ 위반 예시:
| 회원ID | 취미 |
|---|---|
| 1 | 독서, 영화, 등산 |
✅ 1NF 만족:
| 회원ID | 취미 |
|---|---|
| 1 | 독서 |
| 1 | 영화 |
| 1 | 등산 |
2NF (제2정규형)
규칙: 1NF + 모든 비주요 속성이 기본키 전체에 종속.
부분 함수 종속을 제거합니다. 복합키(예: (주문ID, 상품ID))에서 일부 키에만 의존하는 속성은 분리합니다.
❌ 위반 예시: 주문상세 테이블에서 (주문ID, 상품ID)가 기본키인데, 상품명이 상품ID에만 의존
✅ 2NF: 상품명을 별도의 상품 테이블로 분리
3NF (제3정규형)
규칙: 2NF + 이행 함수 종속 제거.
A → B 이고 B → C라면 논리적으로 A → C가 성립하는데, 이런 이행적 함수 종속을 제거합니다.
❌ 위반 예시: 회원ID → 부서코드 → 부서명 (부서명이 이행적으로 회원에 종속)
✅ 3NF: 회원 테이블과 부서 테이블 분리
정규화 단계별 요약
| 단계 | 핵심 규칙 | 제거 대상 |
|---|---|---|
| 1NF | 원자값만 허용 | 다중값·반복 그룹 |
| 2NF | 1NF + 부분 종속 제거 | 부분 함수 종속 |
| 3NF | 2NF + 이행 종속 제거 | 이행 함수 종속 |
| BCNF | 3NF + 모든 결정자가 후보키 | 결정자 이상 |
| 4NF | BCNF + 다치 종속 제거 | 다치 종속 |
| 5NF | 4NF + 조인 종속 제거 | 조인 종속 |
💡 현장 실무: 정규화는 3NF까지가 표준입니다. BCNF, 4NF, 5NF는 시험에서만 보고 실무는 거의 안 합니다. 성능을 위해 의도적 역정규화(denormalization) 도 자주 사용됩니다 — 예를 들어 자주 조회하는 컬럼은 일부러 중복 저장.
2026 ERD 도구 추천 5선
1. dbdiagram.io — 코드로 ERD 그리기 ⭐
- 무료, 가입 불필요 (저장하려면 가입)
- DBML(Database Markup Language) 으로 텍스트 기반 ERD
- Crow's Foot 자동 적용
- MySQL, PostgreSQL, SQL Server DDL 자동 변환
Table 구독자 {
고객번호 int [pk]
이름 varchar(20)
연락처 varchar(20)
}
Table 출판사 {
발행호 int [pk]
발송일 date
구독자_고객번호 int [ref: > 구독자.고객번호]
}→ 위 코드만 입력하면 dbdiagram.io가 자동으로 Crow's Foot ERD를 그려주고, MySQL/PostgreSQL DDL까지 export해줍니다.
2. ERD Cloud — 한국어 인터페이스 ⭐
- 한국 개발자가 만든 무료 도구
- 직관적 드래그 앤 드롭
- 한국어 메뉴와 가이드
- 단점: 가입 필수
한국 학생·정보처리기사 응시자에게 가장 편한 도구입니다. 한국어 폰트·한글 필드명 지원이 깔끔합니다.
3. Mermaid — 마크다운 호환
GitHub README, Notion, Obsidian, GitLab, 모든 마크다운 환경에서 렌더링됩니다.
erDiagram
구독자 ||--o{ 출판사 : 구독한다
구독자 {
int 고객번호 PK
string 이름
}
출판사 {
int 발행호 PK
date 발송일
}위 코드를 마크다운 문서에 그대로 넣으면 ERD가 자동 렌더링됩니다. 문서와 ERD를 함께 버전 관리할 수 있는 것이 가장 큰 장점.
4. DBeaver — DB 연결 직접 역공학
실제 운영 중인 DB에 연결해 자동으로 ERD를 생성합니다. 무료 Community 버전이 있습니다.
레거시 시스템의 ERD 문서가 없을 때, DBeaver로 DB에 붙여 ERD를 자동 생성하면 즉시 현행화 가능합니다.
5. MySQL Workbench — MySQL 공식
무료, MySQL 사용자에게 최적입니다. Forward Engineering(ERD → DDL)과 Reverse Engineering(DB → ERD) 모두 지원합니다.
도구 비교표
| 도구 | 무료 | 코드 기반 | GUI | 자동 DDL | 한국어 | DB 역공학 |
|---|---|---|---|---|---|---|
| dbdiagram.io | ✅ | ✅ | △ | ✅ | ❌ | ❌ |
| ERD Cloud | ✅ | ❌ | ✅ | ✅ | ✅ | ❌ |
| Mermaid | ✅ | ✅ | ❌ | ❌ | ✅ | ❌ |
| DBeaver | ✅ | ❌ | ✅ | ✅ | ✅ | ✅ |
| MySQL Workbench | ✅ | ❌ | ✅ | ✅ | ✅ | ✅ |
상황별 추천
- 혼자 빠르게 그릴 때 → dbdiagram.io
- 한국어 환경이 편할 때 → ERD Cloud
- 문서·README에 ERD를 넣을 때 → Mermaid
- 레거시 DB의 ERD를 뽑을 때 → DBeaver 또는 MySQL Workbench
ChatGPT·Claude로 ERD 자동 생성하기 (2026 트렌드)
2026년에는 AI에게 요구사항을 설명하면 Mermaid·DBML 형식의 ERD를 즉시 생성할 수 있습니다. 표기법을 이해하고 있다면 AI는 강력한 가속기가 됩니다.
기본 프롬프트 템플릿
다음 요구사항을 충족하는 ERD를 Mermaid 형식으로 그려줘:
- 회원, 상품, 주문 테이블 필요
- 한 회원은 여러 주문 가능 (1:N)
- 한 주문에 여러 상품 (N:M)
- MySQL 8 기준 DDL도 함께
- 정규화 3NF까지 준수Claude / ChatGPT 응답 예시
erDiagram
회원 ||--o{ 주문 : 한다
주문 ||--o{ 주문상세 : 포함
상품 ||--o{ 주문상세 : 등록
회원 {
int 회원ID PK
varchar 이름
varchar 이메일
}
주문 {
int 주문ID PK
int 회원ID FK
datetime 주문일시
}
상품 {
int 상품ID PK
varchar 상품명
decimal 가격
}
주문상세 {
int 주문ID FK
int 상품ID FK
int 수량
}AI는 N:M 관계를 자동으로 주문상세 중간 테이블로 분해했습니다. 이어서 다음과 같이 CREATE TABLE 문까지 자동 생성합니다.
CREATE TABLE 회원 (
회원ID INT PRIMARY KEY AUTO_INCREMENT,
이름 VARCHAR(50) NOT NULL,
이메일 VARCHAR(100) UNIQUE NOT NULL
) ENGINE=InnoDB CHARSET=utf8mb4;
CREATE TABLE 상품 (
상품ID INT PRIMARY KEY AUTO_INCREMENT,
상품명 VARCHAR(100) NOT NULL,
가격 DECIMAL(10,2) NOT NULL
) ENGINE=InnoDB CHARSET=utf8mb4;
CREATE TABLE 주문 (
주문ID INT PRIMARY KEY AUTO_INCREMENT,
회원ID INT NOT NULL,
주문일시 DATETIME DEFAULT CURRENT_TIMESTAMP,
CONSTRAINT fk_order_member
FOREIGN KEY (회원ID) REFERENCES 회원(회원ID)
) ENGINE=InnoDB CHARSET=utf8mb4;
CREATE TABLE 주문상세 (
주문ID INT NOT NULL,
상품ID INT NOT NULL,
수량 INT NOT NULL DEFAULT 1,
PRIMARY KEY (주문ID, 상품ID),
CONSTRAINT fk_detail_order
FOREIGN KEY (주문ID) REFERENCES 주문(주문ID),
CONSTRAINT fk_detail_product
FOREIGN KEY (상품ID) REFERENCES 상품(상품ID)
) ENGINE=InnoDB CHARSET=utf8mb4;AI에게 더 잘 시키는 프롬프트 패턴
| 패턴 | 효과 |
|---|---|
"~을 Crow's Foot 표기법으로 그려줘" |
표기법 명시 — AI가 정확한 형식 선택 |
"3NF까지 정규화하고 BCNF는 적용하지 마" |
정규화 수준 통제 |
"감사(audit) 컬럼 createdAt·updatedAt 포함" |
실무 표준 자동 반영 |
"MySQL 8 / utf8mb4 / InnoDB 기준 DDL" |
환경 명시 |
"한국어 컬럼명 유지, 영문 변환 금지" |
한국어 컨텍스트 보존 |
AI ERD 생성의 한계와 검증 포인트
AI는 빠르게 ERD를 그려주지만 다음 4가지는 사람이 직접 검증해야 합니다.
- 비즈니스 컨텍스트: AI는 도메인 규칙을 모릅니다. 예) "환불 가능 기간 7일"은 ERD가 아닌 비즈니스 로직 — 이를 status 컬럼으로 모델링할지 별도 테이블로 분리할지는 사람의 판단.
- 성능 트레이드오프: 인덱스 전략, 파티셔닝, 역정규화 결정은 AI가 자동으로 최적화하지 못합니다.
- 법규·보안 요구사항: 개인정보 보호(GDPR·개인정보보호법) 관련 컬럼 분리, 암호화 컬럼 명시는 사람이 추가해야 합니다.
- 레거시 호환성: 기존 시스템과의 통합 시 ID 체계, 명명 규칙 등은 AI가 모릅니다.
💡 AI 시대의 ERD 학습 가치: AI가 ERD를 그려주지만 표기법 해석과 검증은 여전히 사람의 몫입니다. 표기법을 모르면 AI 결과의 오류를 발견할 수 없습니다. 2026년 ERD 학습은 "그리는 능력"보다 "검증하는 능력"이 더 중요해졌습니다.
실전 DDL 예제 — MySQL 8 기준
기존 본문의 DDL은 DB2 전용 문법(mode db2sql, !!)을 사용해 일반 환경에서 동작하지 않습니다. MySQL 8 기준 표준 DDL로 갱신합니다.
-- 출판사 테이블 (참조 대상이므로 먼저 생성)
CREATE TABLE Publisher (
idPublisher INT PRIMARY KEY AUTO_INCREMENT,
sendDate DATE NOT NULL,
passwordOwner VARCHAR(255) NOT NULL, -- 평문 비밀번호 X, 해시 저장
publishNumber INT UNIQUE NOT NULL,
createdAt TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
updatedAt TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
) ENGINE=InnoDB CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
-- 구독자 테이블
CREATE TABLE Reader (
idReader INT PRIMARY KEY AUTO_INCREMENT,
readerName VARCHAR(50) NOT NULL,
readerAge INT,
readerSex ENUM('M','F','OTHER'),
readerAddDo VARCHAR(20),
readerAddCity VARCHAR(20),
readerAddGu VARCHAR(20),
readerAddDong VARCHAR(20),
readerAddDetail VARCHAR(200),
readerTerm INT COMMENT '현재 구독 개월',
readerTotalTerm INT COMMENT '누적 구독 개월',
readerTel VARCHAR(20),
publisherId INT NOT NULL,
createdAt TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
CONSTRAINT fk_reader_publisher
FOREIGN KEY (publisherId) REFERENCES Publisher(idPublisher)
ON DELETE RESTRICT
ON UPDATE CASCADE,
INDEX idx_reader_publisher (publisherId)
) ENGINE=InnoDB CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;변경 사항:
- DB2 전용 문법 → 표준 MySQL 8
passwordOwnerINTEGER → VARCHAR(255) (해시 저장용)readerAgeTIMESTAMP() → INT (논리적 오류 수정)readerSexBOOL → ENUM (성별은 boolean 아님)- 외래키와 인덱스 명시
utf8mb4캐릭터셋 (이모지·한자 지원)createdAt,updatedAt감사 컬럼 추가 (2026 표준)
정보처리기사·기술사 시험 출제 포인트
ERD는 정보처리기사·기술사 시험의 단골 출제 영역입니다. 자주 묻는 포인트:
자주 나오는 객관식
- Crow's Foot 표기법에서 N(다수) 쪽 기호: 까마귀 발 모양 세 줄
- 개념적/논리적/물리적 모델링 순서: 개념 → 논리 → 물리
- 정규화 1NF 조건: 모든 컬럼이 원자값
- 정규화 2NF 조건: 1NF + 부분 함수 종속 제거
- 정규화 3NF 조건: 2NF + 이행 함수 종속 제거
- 카디널리티 종류: 1:1, 1:N, N:M
자주 나오는 서술형
- ERD의 구성요소 3가지: 엔티티, 속성, 관계
- 개체 vs 인스턴스 차이: 개체는 클래스, 인스턴스는 객체
- 약한 개체와 강한 개체 차이
- 식별자 종류: 기본키, 후보키, 슈퍼키, 대체키, 외래키
자주 나오는 실습형
- 요구사항 → ERD 변환
- ERD → DDL 변환
- 정규화 사례 분석 (어느 단계 위반인지)
자주 묻는 질문 (FAQ)
Q. ERD 표기법 중에서 어떤 걸 먼저 배워야 하나요?
A. Crow's Foot을 먼저 배우세요. 2026년 현장에서 가장 많이 쓰이고, dbdiagram·ERD Cloud·MySQL Workbench 등 모든 도구의 기본 표기법입니다. Chen 표기법은 시험과 교과서에서 나오므로 두 번째로 학습.
Q. 개념적·논리적·물리적 모델링 차이가 뭔가요?
A. 개념적은 "무엇을 저장할지"(DBMS 무관), 논리적은 "관계형 DB로 어떻게 매핑할지"(정규화 포함), 물리적은 "특정 DBMS에 어떻게 구현할지"(DDL, 인덱스, 성능)입니다. 3단계가 분리된 이유는 비즈니스 요구사항과 기술 구현을 단계적으로 분리하기 위함입니다.
Q. AI가 ERD를 그려주는데 굳이 표기법을 배워야 하나요?
A. 반드시 배워야 합니다. AI가 생성한 ERD의 오류·누락·비효율을 검증할 수 있어야 합니다. AI는 비즈니스 컨텍스트나 성능 트레이드오프를 자동으로 알지 못합니다. 표기법 이해는 AI 시대에 더 중요해진 메타 스킬입니다.
Q. 정규화는 어디까지 해야 하나요?
A. 실무는 3NF까지가 표준입니다. BCNF, 4NF, 5NF는 학술적이며, 성능을 위해 의도적 역정규화도 자주 사용됩니다. 시험에서는 BCNF까지 출제됩니다.
Q. ERD에서 N:M 관계는 어떻게 처리하나요?
A. 반드시 중간 테이블(Junction Table, Bridge Table)로 분해합니다. 예: 학생-강의 N:M → 학생, 강의, 수강(학생ID + 강의ID)의 1:N + N:1 구조로 변환.
Q. NoSQL(MongoDB, Firestore)에도 ERD를 그리나요?
A. 전통적 의미의 ERD는 RDB용이지만, NoSQL에서도 문서 구조와 참조 관계를 시각화하는 다이어그램을 그립니다. dbdiagram.io, Hackolade 같은 도구가 NoSQL 지원.
Q. 약한 개체(Weak Entity)란?
A. 자체 기본키만으로는 식별되지 않고 다른 강한 개체와의 관계로 식별되는 개체. 예: "주문상세"는 "주문ID + 상품ID"의 조합으로만 식별되는 약한 개체. Chen 표기법에서는 이중 사각형으로 표현.
Q. 이 글의 구독자/출판사 예제는 어떤 표기법인가요?
A. 본문 이미지는 새발(Crow's Foot) 표기법입니다. 2011년 학생 시절 ERwin Data Modeler로 작성한 것을 재게시한 자료입니다.
2. 논리적 설계
2.1 ERD
 |
 |
|---|
(ERD로 작성)
(새발표기법)
2.2 TABLE 기술서
TABLE
| 테이블명 | 설명 |
|---|---|
| 구독자 | 회원의 정보 저장 |
| 출판사 | 관리자의 정보 저장 |
- Reader TABLE
| 한글 필드명 | 설명 | |
|---|---|---|
| 고객번호 | 회원에게 부여된 고유 번호(FK) | |
| 이름 | 회원의 이름 | |
| 나이 | 회원의 나이 | |
| 성별 | 회원의 성별 | |
| 주소 | 도 | 회원 주소지의 도 |
| 시 | 회원 주소지의 도 | |
| 구 | 회원 주소지의 도 | |
| 동 | 회원 주소지의 도 | |
| 상세 | 회원 주소지의 나머지 상세 주소 | |
| 구독기간 | 회원의 구독 기간 | |
| 총구독기간 | 회원의 총 구독 기간 | |
| 연락처 | 회원의 연락처 |
- Publisher TABLE
| 한글 필드명 | 설명 |
|---|---|
| 고객번호 | 회원에게 부여된 고유 번호 |
| 발행호 | 출판사에서 출간한 책의 발행 호 |
| 발송일 | 출판사에서 출간한 책의 전체 발송날짜 |
| 비밀번호 | 출판사(관리자)임을 인증할 수 있는 비밀번호 |
3. 물리적 설계
3.1 ERD
(새발표기법)
3.2 TABLE 기술서
TABLE
| 테이블명 | 영문 TABLE명 |
|---|---|
| 구독자 | Reader |
| 출판사 | Publisher |
- Reader TABLE
| 한글 필드명 | 영문 필드명 | 데이터타입 | 비고 | |
|---|---|---|---|---|
| 고객번호 | idReader | DOUBLE | Primary key | |
| 이름 | ReaderName | CHAR(10) | ||
| 나이 | ReaderAge | INTEGER | ||
| 성별 | ReaderSex | BOOL | ||
| 주소 | 도 | ReaderAdd_do | INTEGER | |
| 시 | ReaderAdd_city | CHAR(10) | ||
| 구 | ReaderAdd_gu | CHAR(10) | ||
| 동 | ReaderAdd_dong | CHAR(10) | ||
| 상세 | ReaderAdd_detail | CHAR(10) | ||
| 구독기간 | ReaderTerm | INTEGER | ||
| 총구독기간 | Reader3Term | DATE | ||
| 연락처 | ReaderTel | INTEGER |
- Publisher TABLE
| 한글 필드명 | 영문 필드명 | 데이터타입 | 비고 |
|---|---|---|---|
| 고객번호 | ReaderNum | NUMBERIC(8) | Primary Key |
| 발행호 | idPublisher | INTEGER | |
| 발송일 | sendDate | DATE | |
| 비밀번호 | passwordOwner | INTEGER |
4. DDL**문**
CREATE TABLE Publisher (
sendDate DATE,
passwordOwner INTEGER,
idPublisher INTEGER,
ReaderNum NUMERIC(8) NOT NULL
);
DROP INDEX XPKPublisher;
CREATE UNIQUE INDEX XPKPublisher ON Publisher
(
ReaderNum ASC
);
ALTER TABLE Publisher
ADD PRIMARY KEY (ReaderNum);
CREATE TABLE Reader (
ReaderName CHAR(10),
ReaderAge TIMESTAMP(),
ReaderSex SMALLINT,
ReaderAdd_do CHAR(10),
ReaderAdd_city CHAR(10),
ReaderAdd_gu CHAR(10),
ReaderAdd_dong CHAR(10),
ReaderAdd_detail CHAR(30),
ReaderTel NUMERIC(12),
ReaderTerm INTEGER,
Reader3Term TIMESTAMP,
ReaderNum NUMERIC(8) NOT NULL
);
DROP INDEX XPKReader;
CREATE UNIQUE INDEX XPKReader ON Reader
(
ReaderNum ASC
);
ALTER TABLE Reader
ADD PRIMARY KEY (ReaderNum);
ALTER TABLE Reader
ADD FOREIGN KEY (ReaderNum)
REFERENCES Publisher (ReaderNum)
ON DELETE RESTRICT;
create trigger tD_Publi after DELETE on Publisher
REFERENCING OLD AS OLD for each row mode db2sql
WHEN (0 < (select count(*) from Reader where Reader.ReaderNum =
old.ReaderNum))
BEGIN ATOMIC
SIGNAL SQLSTATE '75001' ('Cannot DELETE Publisher because Reader
exists.');
END
!!
create trigger tI_Reade after INSERT on Reader
REFERENCING NEW AS NEW for each row mode db2sql
WHEN ((0 = (select count(*) from Publisher where new.ReaderNum =
Publisher.ReaderNum))
)
BEGIN ATOMIC
SIGNAL SQLSTATE '75001' ('Cannot INSERT Reader because Publisher
does not exist.');
END
!!
댓글