[학습일기 #20] 데이터베이스 1일차

Ariel_Jeong·2026년 1월 14일

MySQL Workbench RDBMS mysql 데이터베이스

[학습 일기 시리즈]

목록 보기

20/44

오늘은 데이터베이스에 대한 수업 1일차였다.
데이터베이스에 대한 개념을 알고 있다고 생각했는데, 처음 접하는 내용들도 많았다.
잊지 않도록 다시 한번 정리해보자.

1. Database란?

👉 데이터를 정리된 구조로 안전하게 저장하고, 빠르게 검색·수정·관리할 수 있는 시스템

단순히 “데이터를 모아둔 공간”이 아니라,
중복을 최소화하고, 여러 사용자가 동시에 접근해도
데이터의 정확성과 일관성을 유지하도록 설계된 정보 관리 체계

아래 4 가지를 전제로 만들어졌다.

✔ 대용량 데이터
✔ 동시 접근
✔ 무결성 보장
✔ 빠른 검색

cf1) DB(Data-Base) vs. DBMS(Data-Base Management System)

DB (Database)
→ 실제 데이터가 저장되는 공간 자체
→ 테이블, 행, 컬럼, 데이터 값
DBMS (Database Management System)
→ Database를 생성·관리·제어하는 소프트웨어
→ MySQL, Oracle, PostgreSQL 등

👉 DB는 “저장소”, DBMS는 “관리 시스템”

cf2) CSV vs. Database 비교

항목	CSV	Database
데이터 크기	소규모에 적합	수백만~수억 건 가능
구조	단일 테이블	여러 테이블 관계
검색 속도	느림	인덱스로 매우 빠름
데이터 무결성	보장 불가	제약조건으로 보장
동시 사용	불가	가능
유지보수	어려움	안정적

👉 데이터가 커지고, 사람이 늘어나는 순간 CSV는 한계에 도달

cf3) 데이터 웨어하우스(DW)와 데이터 마트(DM)

DW (Data Warehouse)
→ 여러 시스템의 데이터를 모아둔 중앙 분석용 DB
→ 과거 데이터 포함
→ 분석·리포트 목적
DM (Data Mart)
→ DW에서 특정 부서/목적만 떼어낸 소형 DB
→ 마케팅, 영업, 헬스케어 분석 등

👉 DW = 전체 분석 창고 / DM = 목적별 작업대

1.1. 데이터베이스의 특징

통합된 데이터(Integrated data)
- 중복을 최소화하고 하나의 논리적 구조로 통합
- 동일 데이터가 여러 곳에 흩어지지 않음
저장된 데이터(Stored data)
- 메모리가 아닌 디스크에 영구 저장
- 시스템 재시작 후에도 유지
공용 데이터(Shared data)
- 여러 사용자가 동시에 접근 가능
- 권한과 제어로 충돌 방지
변화하는 데이터(Operational data)
- 지속적으로 삽입·수정·삭제됨
- 실시간 업무 처리용 데이터

1.2. 데이터베이스 종류

계층형
- 트리 구조
- 부모-자식 관계만 표현
- 구조 변경 어려움
네트워크형
- 그래프 구조
- 다대다 관계 표현 가능
- 구조 복잡
관계형(RDBMS. 매우 중요!!)
- 테이블 간 관계(PK-FK) 기반
- 정형 데이터 처리
- SQL 사용
- ex) Oracle, MySQL(Oracle), MS-SQL(Microsoft), DB2·Infomix(IBM), MariaDB(Sun Microsystems), Derby(Apache), SQLite(오픈소스)
NoSQL
- 스키마 유연
- 대규모 분산 시스템
- ex) Document-Oriented DB: CouchDB, MongoDB, Elasticsearch, Cloudant
  Key-Value DB: Dynamo, Redis, Riak, Coherence, SimpleDB
  Column-Oriented DB: Bigtable, Cassandra, HBase, HyperTable

👉 헬스케어·금융·공공 = RDBMS가 표준

1.3. SQL(Structured Query Language)이란?

관계형 데이터베이스에서
데이터 구조를 정의하고, 데이터를 조작하고, 권한과 트랜잭션을 제어하기 위한 표준 언어다.

SQL은 목적에 따라 크게 4가지로 나뉜다.

DDL(Data Definition Language), DML(Data Manipulation Language)

DDL(Data Definition Language) – 데이터 정의 언어
데이터베이스의 “뼈대(구조)”를 만드는 언어. 테이블, 컬럼, 제약조건 같은 형태 자체를 정의한다.
- CREATE: 새로운 객체를 생성. DB, Table, Index, View 등을 만듦
  📌 언제 쓰나: 새 프로젝트 시작, 새로운 테이블 설계
- ALTER: 이미 존재하는 객체의 구조를 변경. 컬럼 추가/삭제/타입 변경
  📌 언제 쓰나: 요구사항 변경, 컬럼 추가, 타입 수정
  ⚠️ 데이터가 많을수록 위험 → 신중히 사용
- RENAME: 객체 이름 변경. 테이블명, 컬럼명 변경
  📌 언제 쓰나: 네이밍 규칙 통일, 의미가 바뀐 경우
- DROP: 객체를 완전히 삭제. 구조 + 데이터 모두 제거
  📌 언제 쓰나: 더 이상 사용하지 않는 테이블
  ⚠️ 복구 불가 (ROLLBACK 안 됨) → 신중히 사용
DML(Data Manipulation Language) – 데이터 조작 언어
테이블 안의 “데이터 자체”를 다루는 언어.
- INSERT: 새로운 데이터 추가
  📌 언제 쓰나: 신규 데이터 저장
- SELECT: 데이터 조회. 가장 많이 사용되는 SQL
  📌 언제 쓰나: 데이터 분석. 서비스 조회 로직
- UPDATE: 기존 데이터 수정
  📌 값 변경, 상태 업데이트
  ⚠️ WHERE 없으면 전체 수정
- DELETE: 데이터 삭제
  📌 언제 쓰나: 데이터 제거
  ⚠️ WHERE 없으면 전체 삭제

cf) DCL(데이터 제어 언어), TCL(트랜젝션 제어 언어)

DCL(Data Control Language) – 데이터 제어 언어
“누가 이 DB를 사용할 수 있는가”를 제어하는 언어
- GRANT: 권한 부여
  📌 언제 쓰나: 사용자 추가. 읽기/쓰기 권한 분리
- REVOKE: 권한 회수
  📌 언제 쓰나: 보안 강화. 역할 변경
TCL(Transaction Control Language) – 트랜잭션 제어 언어
작업을 “확정할지 / 되돌릴지” 결정하는 언어
- COMMIT: 변경 사항을 확정. 디스크에 영구 반영
  📌 언제 쓰나: 작업 성공 시
- SAVEPOINT: 중간 저장 지점 생성
  📌 언제 쓰나: 복잡한 트랜잭션 중간 체크포인트
- ROLLBACK (TO): 이전 상태로 되돌림 또는 전체 취소
  📌 언제 쓰나: 오류 발생. 데이터 정합성 깨질 때

1.4. 데이터베이스 기본 용어 정리(필수 개념!)

1.4.1. Instance

특정 시점에 DB에 저장된 실제 데이터 상태

1.4.2. Row와 Column

Row: 데이터 한 건(ex. 환자 한 명)
Column(=Attribute): 데이터 속성(ex. 환자 id, 나이, 키, 몸무게 등등...)

1.4.3. Domain

컬럼이 가질 수 있는 값의 범위와 타입

1.4.4. Schema

테이블 구조 정의서(컬럼, 타입, 제약조건)

1.4.5. Table과 Entity

Table: 물리적 저장 구조(실제 표)
Entity: 현실 세계의 개체 개념(table을 의미하나 개념에 더 가까움)

1.4.6. Metadata

데이터를 설명하는 데이터
(ex. 사진 속성 정보에서 사진 파일이 언제, 어디서 생성되었는지 알려주는 추가데이터가
메타데이터라 볼 수 있음)

1.4.7. Index

검색 속도를 높이기 위한 자료 구조
→ 대신 저장 공간 증가

1.5. Key 🔑

1.5.1. Key란?

테이블의 행을 유일하게 식별하거나 테이블 간 관계를 정의하기 위한 속성

1.5.2. Key의 종류

Super Key: 유일 식별 가능한 모든 속성 조합. 최소일 필요 없음.
Candidate Key: Super Key 중에서 최소성(minimality)을 만족하는 키. 더 이상 쪼갤 수 없음.
Primary Key(PK): Candidate Key 중에서 시스템이 공식적으로 선택한 “대표 번호”
Alternate Key: Candidate Key 중에서 Primary Key로 선택되지 않은 키, 보통 UNIQUE 제약조건으로 중복만 막아 관리("이 값도 사실 유일하나 PK로 쓰지는 않겠다."ex. 이메일 주소)
Foreign Key(FK): 다른 테이블의 PK 참조
Surrogate Key: 비즈니스 의미 없이, 시스템에서 인위적으로 생성한 인조 식별키
- Auto Increment ID
- UUID
- 실무에서 PK의 90% 이상이 Surrogate Key

1.5.3. Primary Key(PK)

📌 PK의 성질

성질	왜 그래야 하나
NULL ❌	없으면 식별 불가
중복 ❌	두 명이 같은 번호면 붕괴
변경 ❌	다른 테이블이 전부 깨짐
테이블당 1개	기준은 하나여야 함

👉 PK는 “정체성”이기 때문에 바뀌면 안 된다

📌 PK 생성 전략

Auto Increment(⭐⭐⭐⭐⭐): 자동 번호 증가. 빠르고 단순. 실무 최다.
- 👉 단일 DB 환경 최강
UUID(⭐⭐): 랜덤 128bit(길고 무거움). 전역 유일. 인덱스 성능 저하
- 👉 분산 시스템에서만 고려
Composite Key(⭐): 여러 컬럼 결합. 의미는 명확. 관리 복잡(FK 설계 지옥, 조인 복잡)
- 👉 가능하면 피한다

📌 좋은 PK vs. 나쁜 PK

좋은 PK:
- 정수형 → 빠른 인덱스
- 의미 없음 → 요구사항 변경에 안전
- 변경 없음 → FK 안정
나쁜 PK:
- 주민번호 → 법/보안 문제
- 이메일 → 변경 가능
- 문자열 → 성능 저하

👉 PK는 “의미가 없을수록 좋다”

1.5.4. Foreign Key(FK)

📌 FK의 역할

테이블 간 관계 표현
존재하지 않는 데이터 참조 방지
데이터 정합성 유지

👉 “없는 환자의 진료 기록”을 막는다

📌 FK 기본 원칙

부모 테이블 PK 참조 → 기준은 하나여야 함
타입 완전 일치 → 비교/조인 오류 방지
참조 무결성 보장 → 고아 데이터 방지

📌 FK 사용 전략

의료·금융 → 반드시 사용(데이터 오류 = 사고)
초대규모 서비스 → 논리적 관리. 애플리케이션 레벨 검증(코드가 직접 중복 여부를 검사. 완전하지 않기에 안정성 떨어짐)

👉 성능 vs 안정성의 선택

📌 애플리케이션 레벨 검증의 진짜 역할

사용자 경험(UX)
- 빠른 피드백
- 친절한 에러 메시지
비즈니스 규칙 처리
- 나이 ≥ 19
- BMI 범위
- 특정 조합 불가
DB 에러를 미리 방지
- 실패 가능성 낮추기

👉 “편의 + 사전 검사”

📌 DB 레벨 검증의 역할

PK 중복 ❌
FK 무결성 ❌
UNIQUE 중복 ❌
CHECK 조건 ❌

👉 “최후의 보루”

📌 좋은 FK vs. 나쁜 FK

좋은 FK:
- 정수형 PK 참조
- 변경되지 않는 값
나쁜 FK:
- 이메일, 코드값
- 의미 있는 값 참조
- 변경 시 연쇄 오류

1.6. Integrity(데이터 무결성)란?

데이터가 정확하고, 일관되며, 모순 없이 유지되는 상태

✔ 도메인 무결성
✔ 엔티티 무결성
✔ 참조 무결성
✔ 업무 무결성

1.7. Normalization(정규화)란?

데이터 중복과 이상현상을 막기 위해
하나의 테이블에 몰려 있는 정보를 의미 단위로 나누는 과정

cf) 먼저 “정규화가 없을 때 벌어지는 사고”부터 보자

🚨 상황: 하나의 테이블로 다 때려 넣은 경우

[환자_검사_테이블]

환자ID | 환자이름 | 병원명 | 병원주소 | 검사명 | 검사결과
----------------------------------------------------
1      | 김민수   | 서울병원 | 서울 강남 | 혈압   | 120
1      | 김민수   | 서울병원 | 서울 강남 | 혈당   | 90
2      | 이지은   | 서울병원 | 서울 강남 | 혈압   | 110

🔥 이상현상(Anomaly)이란?

정규화가 안 된 테이블에서는 정상적인 작업을 했는데 데이터가 망가지는 현상이 생김

삽입 이상 (Insertion Anomaly)
- “아직 검사는 안 했는데 새 병원을 미리 등록하고 싶다” → ❌ 불가능
- 왜? → 검사명, 검사결과가 NULL이 되기 때문
  👉 필요 없는 정보 때문에, 필요한 정보를 못 넣음
삭제 이상 (Deletion Anomaly)
- “김민수의 혈당 검사 기록만 삭제하고 싶다”
- 그 결과?
  → 서울병원 정보도 같이 사라질 수 있음
  → 김민수의 병원 정보 유실
  👉 하나 지웠을 뿐인데, 다른 의미의 데이터가 같이 사라짐
갱신 이상 (Update Anomaly)
- “서울병원 주소가 바뀌었다”
- 몇 번 수정해야 할까?
  → 김민수 행
  → 이지은 행
  → 검사 종류 수만큼 반복
  👉 하나라도 빼먹으면 병원 주소가 서로 다르게 저장됨

👉 정규화의 목적은 딱 하나

"이상현상을 원천 차단하는 것"

1.7.1. 3NF

1NF(First Normal Form/제 1정규화): 원자성 만족 — “하나의 칸에는 하나의 값만”
모든 컬럼은 더 이상 쪼갤 수 없는 “원자값”만 가져야 한다
- 리스트 ❌
- 배열 ❌
- “여러 값 한 칸” ❌
2NF(Second Normal Form/제 2정규화): 부분 종속 제거 — “PK의 일부에만 매달린 속성 제거”
"부분 종속": 컬럼이 PK 전체가 아니라, PK의 일부에만 의존하는 상태
👉 PK 전체에만 의존하는 컬럼만 남긴다

# 2NF 전
[수강 테이블]
(학생ID, 과목ID) ← PK

학생ID | 과목ID | 학생이름 | 과목명 | 성적

# 2NF 후
[학생]
학생ID | 학생이름

[과목]
과목ID | 과목명

[수강]
학생ID | 과목ID | 성적

3NF(Third Normal Form/제 3정규화): 이행 종속 제거 — “PK 말고, 다른 컬럼을 거쳐 의존하는 관계 제거”
"이행 종속": PK가 아닌 컬럼을 거쳐서 다른 컬럼이 결정되는 관계

# 3NF 전
[직원]
직원ID | 부서ID | 부서명

# 3NF 후
[직원]
직원ID | 부서ID

[부서]
부서ID | 부서명

cf) 부분 종속 제거와 이행 종속 제거는 어떤게 다른가?
| 구분 | 핵심 질문 |
| ----- | ---------------- |
| 부분 종속 | PK 일부에만 매달렸나? |
| 이행 종속 | PK → A → B 구조인가? |

🔚 정규화 전체를 한 문장으로 정리하면

“한 테이블에 섞여 있던 서로 다른 의미의 정보들을 각자의 주인에게 돌려보내는 과정”

📌 그래서 실무에서 왜 중요하냐

데이터 수정이 한 번으로 끝남
중복 제거
무결성 유지
ERD가 깔끔해짐

Q1. 정규화를 너무 과하게 하면 오히려 어떤 문제가 생길까?

데이터는 깨끗해지지만, 시스템은 느려지고, 쓰기·읽기 모두 복잡해진다.
1️⃣ 조인이 폭발한다 (성능 문제)
조인 많아짐 → 인덱스 관리 복잡 → 쿼리 최적화 난이도 상승
👉 읽기 성능 급락

2️⃣ 쿼리가 사람이 이해하기 어려워진다 (유지보수 문제)
👉 “데이터는 논리적인데, 사람에게는 비논리적”

3️⃣ 트랜잭션 범위가 커진다 (안정성 문제)
트랜잭션 길어짐 → 락 경쟁 증가 → 데드락 위험 증가

4️⃣ 캐싱이 어려워진다
하나의 화면을 위해 여러 테이블 필요 → 부분 캐싱이 까다로움

Q2. 실무에서 일부러 3NF를 깨고 설계하는 경우는 어떤 상황일까?

“무결성보다 성능·단순성이 더 중요한 경우”
1️⃣ 읽기 성능이 최우선인 경우
👉 JOIN 제거 → 조회 속도 폭발적으로 개선

2️⃣ 값이 거의 변하지 않는 경우

3️⃣ 집계/통계 데이터
원본 데이터에서 계산한 파생 데이터
👉 정규화 개념을 적용할 대상이 아님

4️⃣ 외부 시스템 연동/로그 테이블
쓰기 많음, 수정 거의 없음, 조회는 패턴화 됨
👉 단순 구조가 훨씬 유리

1.8. 자료형

“이 컬럼에 어떤 형태의 값이 들어올 수 있으며 DB가 그 값을 어떻게 저장하고 비교할지 정해 놓은 규칙”

1.8.1. 정수형

TINYINT: 아주 작은 범위의 정수를 저장하는 자료형
- 용량: 1바이트
- 범위: -128 ~ 127
- 값의 종류가 매우 적을 때 사용
- 메모리 절약용
- 계산보다는 상태 표현에 적합
- ex. 성별, 범주형
SMALLINT: TINYINT보다 넓은 범위의 정수를 저장하는 자료형
- 용량: 2바이트
- 범위: ± 32K
- 중간 크기의 정확한 정수
- INT까지는 필요 없지만 상태값보다는 범위가 넓은 경우
- ex. 혈압, 키
INT: 일반적인 정수 데이터를 저장하는 표준 정수형
- 용량: 4바이트
- 범위: ± 21억
- 대부분의 정수 데이터를 커버(DB에서 가장 많이 사용됨)
- 인덱스 효율 좋음
- 연산 안정적
- ex. user_id
BIGINT: 아주 큰 범위의 정수를 저장하는 자료형
- 용량: 8바이트
- 범위: 매우 큼
- 대규모 서비스의 고유 번호
- “언젠가는 커질 수 있다”면 BIGINT
- ex. 로그 ID

1.8.2. 실수/정밀형

FLOAT/DOUBLE: 근사값(어림값)으로 소수를 저장하는 자료형
- “소수를 흉내 낸 이진수 근사값”을 저장하는 타입
- 예를 들어, 정확한 0.1(10진수)을 저장한 적이 없음. 0.1에 가장 가까운 이진수를 저장했을 뿐
- 그럼 왜 이런 위험한 타입 사용?
  → 연산을 하드웨어 수준에서 직접 처리하기 때문에 계산 속도가 매우 빠름
- 비교=, PK/FK, UNIQUE에 쓰면 사고남
DECIMAL: 소수를 “정확히” 저장하는 자료형
- 내부적으로 문자열에 가까운 방식(사람이 쓰는 10진수 그대로의 형태)
- 정확성이 최우선
- 돈 / 의료 수치 / BMI는 무조건 DECIMAL

1.8.3. 문자열/날짜/논리형

CHAR(n): 길이가 고정된 문자열
- 길이가 항상 같을 때 효율적
- 비교 속도 빠름
VARCHAR(n): 길이가 변할 수 있는 문자열
- 공간 절약
- 대부분의 문자열 컬럼에 사용
TEXT: 길이가 매우 긴 문자열
- 본문, 설명, 로그
- 인덱스 제약 많음
- “검색보다는 저장 목적”
DATE: 날짜(연·월·일)만 저장(시간 개념 없음)
DATETIME: 날짜 + 시간을 함께 저장(시스템 시간대와 독립적)
TIMESTAMP: UTC 기준 시간 값을 저장하고, 조회 시 시스템 시간대로 변환(시간대 이슈 발생 가능)
BOOLEAN/TINYINT: 참/거짓 상태를 표현
- 내부적으로는 숫자, 의미적으로는 논리값
ENUM: 미리 정해진 값 중 하나만 가질 수 있는 자료형
- 값의 범위를 강제
- 변경 시 스키마 수정 필요
- 유연성 ↓ / 무결성 ↑

1.9. 트랜잭션(Transaction) & ACID

트랜잭션 = ‘반드시 함께 성공하거나 함께 실패해야 하는’ 작업들의 묶음(논리적 작업 단위)

비유하자면,
은행에서 “계좌이체”를 한다고 해보자.

내 계좌에서 10만원 출금
상대 계좌에 10만원 입금

이 두 작업은 따로따로 성공하면 안 된다.
출금만 성공하고 입금이 실패하면?
→ 돈이 공중으로 사라진다(데이터 붕괴).

ACID: 트랜잭션이 믿을 수 있게 동작하도록 보장하는 4가지 성질

A: Atomicity(트랜잭션 안의 작업은 전부 성공하거나 전부 실패해야 한다)
C: Consistency(트랜잭션 전후로 DB는 항상 규칙(제약조건)을 만족하는 상태여야 한다)
I: Isolation(동시에 여러 트랜잭션이 실행돼도 서로 간섭하지 않는 것처럼 보이게 해야 한다)
D: Durability(COMMIT된 데이터는 시스템 장애가 나도 사라지지 않는다)

cf) 격리 수준(추후 내용 업데이트 필요)
Isolation은 “완벽할수록” 안전하지만 “느려질 수” 있기에 DB는 격리 수준을 선택할 수 있다.

Read Uncommitted (가장 위험/빠름)
Read Committed
Repeatable Read
Serializable (가장 안전/느림)

2. ERD 모델링

2.1. ERD(Entity-Relationship Diagram)란?

데이터베이스에 저장될 ‘대상(엔티티)’과 그 대상들 사이의 ‘관계’를
사람이 한눈에 이해할 수 있도록 시각적으로 표현한 설계도

2.2. Relationship & Crow-feet 표기법

2.2.1. Relationship

하나의 엔티티가 다른 엔티티와 어떤 개수 관계로 연결되는지를 나타낸 것
핵심 질문은 항상 이것이다 👇

“A 하나에 B가 몇 개까지 연결될 수 있는가?”

1:1 → 한 쪽의 하나가 다른 쪽의 하나와만 연결
- 사람 ↔ 주민등록증
- 사용자 ↔ 사용자 상세정보
1:N → 한 쪽의 하나가 다른 쪽(이쪽이 FK를 가진다)의 여러개와 연결
- 환자 1명 → 여러 번 방문
- 주문 1건 → 여러 상품
N:N → 한 쪽의 여러개가 다른 쪽의 여러개와 연결
- 학생 ↔ 과목
- 환자 ↔ 검사
- 문제점: RDBMS는 N:N 관계를 직접 표현할 수 없다 → 중간 테이블(연결 테이블)이 필요
```
# Before
[Student] >< [Course]
 N          N
 
# After
[Student] ──< [Enrollment] >── [Course]
  1            N             1
```

2.2.2. Crow-feet 표기법 🐦

기본 기호

|   → 1 (하나)
O   → 0 (없을 수도 있음. 선택(옵션))
<   → N (여러 개)

조합해서 읽으면?

① | → One

“최대 1개까지만 허용된다”(최대 개수만 말함)
의미: 0 또는 1
필수는 아님(“있어도 하나, 없어도 됨”)

📌 예시
사람 — 여권
(사람은 여권이 있을 수도 있고 없을 수도 있지만, 있으면 1개)

② < → Many

여러 개 가능
최소 개수는 표현 안 함
“많을 수 있음”만 표현

📌 단독으로는 잘 안 쓰고
보통 |<, O<처럼 조합해서 쓴다

③ || → One and only one

무조건 정확히 1개 (필수. 안 가진다는 선택지가 없음)

📌 예시
주문 — 주문번호
(주문은 반드시 주문번호가 있어야 함)

④ O| → Zero or one

없거나, 있으면 하나(최소·최대 모두 명시)
선택적 관계임을 명확히 선언(필수 아님)
최대 1

📌 예시
직원 — 주차공간
(직원은 주차공간이 없을 수도, 하나 있을 수도)

⑤ |< → One or many

최소 1, 최대 여러 개
반드시 하나 이상(“없으면 안 됨”)

📌 예시
주문 — 주문상품
(주문은 상품이 최소 1개는 있어야 함)

⑥ O< → Zero or many

없어도 되고, 여러 개도 가능
가장 흔히 쓰이는 형태(“선택적 다수”)

📌 예시
고객 — 주문
(고객은 주문이 없을 수도 있고, 여러 개일 수도 있음)

2.3. ERD 설계 방법

1) Entity 추출(현실 세계의 명사. ex. 환자, 방문, 검사)
2) Attribute 정리(엔티티의 성질. ex. 나이, 성별, 검사값)
3) PK 결정(정체성 부여)
4) Relationship 정의(1:1 / 1:N / N:N 판단)
5) FK 설정(관계를 DB 구조로 번역)
6) N:N 분해(중간 테이블 생성)
7) 제약조건 정의(NULL, UNIQUE, CHECK)
8) 정규화(3NF)

2.4. 실습 - train.csv 파일 참고해서 ERD 그리기

Ariel_Jeong

R&D 분야의 경험을 토대로 커리어 확장에 도전중인 개발꿈나무입니다.