티스토리 뷰
목차
1. 데이터 모델링이란
- 개념적 / 논리적 모델링
- 데이터 베이스 생명 주기
2. ER(Entity Relation) 모델
- 개체와 개체 타입 - 강한 개체 vs 약한 개체
- 속성 - 단일/다중, 단순/복합, 저장/유도, 키 속성
- 관계 - 차수(이항/삼항/순환), 카디널리티(1:1/1:N/N:M), 참여 제약 조건, IS-A 관계
- ERD 표기법 - 피터 첸 vs IE(새발, 까마귀발) 표기법
3. ER 모델 -> 관계 데이터 모델 사상(매핑)
- 개체
- 1단계: 강한 개체->릴레이션
- 2단계: 약한 개체->복합키 릴레이션
- 관계
- 3~4단계: 1:1 / 1:N 관계
- 5~6단계: N:M / N진 관계
- 속성
- 7단계: 다중값 속성
- tip!
2단계 데이터 모델링(개념 먼저 논리 나중!!!!!)
- 개념적 데이터 모델링 : 현실 -> er 다이어그램으로 만들기(개체 - 관계 모델) 추상화하기
- 논리적 데이터 모델링 : er 다이어그램 -> 테이블 1(속성1, 속성2, 속성3) 구체화하기
1. 요구사항 수집 및 분석
2. 설계
- 개념적 모델링(er 다이어그램 만듦)
- 논리적 모델링(er 다이어그램의 개념들 구체화(최대 몇 바이트인지 정의한다던가), erd-rdb 모델 사상, 정규화 등)
- 물리적 모델링(논리적 모델링 토대로 db 만듦.)
3. 데베 구현
단계 더해질수록 구체화, 윗단계일수록 추상화
1. 데이터 모델링이란
현실 세계 데이터 -> 컴퓨터 DB로 옮기는 변환 과정
단순화, 추상화 필요
흐름 : 현실 세계 파악 & 요구사항 분석 -> (추상화) -> 개념적 모델(ER 다이어그램) -> (데이터 모델링) -> 논리적 모델(관계 데이터 모델) -> (DB 구현) -> 데이터베이스
앞선 단계에선 추상화, 단계 진행될수록 구체화된다.
개념적 모델링 VS 논리적 모델링
설계 단계 : 개념적 모델링 먼저!! 논리적 모델링 나중!! 개념적 -> 논리적 -> 물리적 모델링
개념적 데이터 모델링
- 현실 세계 추상화 -> 데이터 뽑아내는 작업
- DBMS 와 무관, 모든 DBMS의 공통 작업
- 개체, 속성, 관계 로 구성한 후 ERD(Entity-Relation-Diagram)로 표현
- (중요!!!)산출물: 개체-관계모델(ER 다이어그램)
- 예) 도서-고객은 주문하기 관계가 있다. / 고객은 주문한다 도서를 / 도서는 주문받는다 고객에 의해
논리적 데이터 모델링
- er 다이어그램을 dbms에 맞게 사상(매핑)하는 과정
- 핵심 작업 3가지
1. er -> 릴레이션 스키마 매핑 (개체, 관계를 테이블로 변환)
2. 상세 속성 정의 (데이터 타입, 최대 길이 등 구체화)
3. 정규화 수행
- 산출물 : 릴레이션 스키마 (ex: 테이블 1(속성1, 속성2, 속성3) )
- 주의!!!! : 아직 실제 테이블 아님!!
- 개념적 데이터 모델링에서 다 도출 못했는데 추가로 필요한 걸 넣기도 함
(참고) 물리적 데이터 모델링
- 테이블 만드는 것
데이터베이스 생명주기
| 1단계 : 요구사항 수집 및 분석 | 어떤 사용자가 몇 년 동안 쓸 것인지, 사용자 요구 등 분석 | 요구사항 명세 |
| 2딘계 : 개념적 모델링 | entity - relation 도출 | Entity Relation Diagram |
| 3단계 : 논리적 모델링 | 각 개념 구체화 - ERD-RDB 모델 사상,맵핑 - 상세 속성 정의 - 정규화 |
릴레이션 스키마 |
| 4단계 : 물리적 모델링 | 인덱싱 기법이나 특화된 기능 보충 | 물리적 스키마 |
| 데이터 베이스 구현 |
시험 대비 정리
- 개념적 모델링의 산출물 = ER 다이어그램
- 논리적 모델링의 산출물 = 릴레이션 스키마 (테이블 아님!)
- 물리적 모델링의 산출물 = 실제 테이블 (물리적 스키마)
- 개념적 모델링은 DBMS와 무관하게 설계 가능
- 논리적 모델링의 핵심 3가지 : 매핑 + 속성 정의 + 정규화
- 단계가 내려갈수록 구체화, 올라갈수록 추상화
2. ER 모델 ENTITY - RELATION
세상 -> ENTITY + RELATION 으로 추상화하는 단계
특정 DBMS와 무관하게 설계 가능하다
2-1. 개체와 개체 타입
개체
독립적 실체, 각 개체만의 속성을 하나 이상 갖고 있어야 함!! 테이블에 컬럼 없으면 안되니까
개체 특징
- 기본키로 식별 가능해야 한다
- 반드시 자신의 특징을 나타내는 속성이 있어야 한다.
- 다른 개체와 최소 한 개 이상의 관계를 맺고 있다.
EX)
- 개체 타입 : 개체를 이름+속성으로 나타냄 : like 클래스
- 개체 인스턴스 : 실제 값을 가진 개체 : like 객체
- 개체 집합 : 특정 개체 타입에 대한 개체들 모음 : 객체들 집합
강한 개체 vs 약한 개체
| 강한 개체 | 약한 개체 |
| 독립적으로 존재 가능 | 강한 객체가 있어야만 존재 의의 o, 표현 가능, 강한 개체에 종속 |
| 자신의 기본키(pk)로 식별 | 강한 개체의 기본키 가져와서 식별 |
| 일반 사각형 | 이중 사각형 |
| 직원, 고객 | 부양가족(부양가족은 직원에 의존, 직원이 없으면 존재 의미가 없음), 주문(주문은 고객에 의존, 고객이 없으면 존재할 수 없음.), 학부모(학생이 없으면 불필요. ) |
| 약한개체와 관계 : 이중실선 = 으로 표기함!!! (뜻 : 강한 개체와의 필수참여, 즉 강한 개체 있어야만 존재 가능 의존성, 종속성 표시) |
| 약한 개체 |  |
|
| 식별 관계 | 약한 개체는 관계에 필수 참여(=), 강한개체(직원)와 약한개체(부양가족)은 1:다 관계 강한 거 하나에 약한 거 여러 개 매달려 있음 |
 |
| 키 | 강한 개체 구별하는 키 속성 |  |
| 식별자 | 약한 개체 구별하는 식별자, [강한개체 pk + 약한개체 식별자] 복합키처럼 이렇게 약한 개체의 키 구성 |
 |
2-2. 속성(Attribute)
- 개체 or 관계가 갖고 있는 고유 특성, 가장 작은 논리적 단위(원자성!!!)
속성 분류
1. 단일 값 vs 다중 값
| 단일 값 속성 | 다중 값 속성 |
| 값 하나만 | 값 여러 개 |
| 고객명, 나이 | 취미1,취미2, 연락처1,연락처2, 이름(한글),이름(한자),이름(영어) |
| 일반 타원 | 이중 타원 |
다중 값 속성 -> 제 1 정규형 쓴다.
- 개수 정해져 있을 땐 : 속성 연락처1, 연락처2 로 분리
- 개수 제한 없거나 가변적 : 별도 테이블 생성
(위에서 속성 분리하면 [이름 최대 10개 있는 사람 + 이름 하나만 있는 사람] 있을 때 속성 10개를 만들어놓고 나머진 낭비가 된다. 그러니 그럴 땐 테이블을 생성하자!!!)
2. 단순 vs 복합
| 단순 속성 | 복합 속성 |
| 더 이상 분해 못하는 속성 | 의미 분해 가능한 속성 |
| 적립금, 나이 | 주소(시/동/번지), 생년월일(연/월/일), 학번(입학연도/학과/순서), 주민번호 등 |
3. 저장 vs 유도
| 저장 속성 | 유도 속성 |
| 직접 저장되는 속성 | 다른 속성 값으로 계산하는 속성 |
| 생년월일, 가격, 할인율 | 나이(생년월일로 계산), 판매가격(가격,할인율로 계) |
| 실선 타원 | 점선 타원 |
- 만약 나이가 실선 타원이면 저장 속성이고, 그냥 해 바뀔 때마다 업데이트하겠다는 뜻
* 키 속성
- 개체를 유일하게 식별하게 하는 속성 primary key PK
- 속성 이름에 밑줄로 표시
- 약한 개체 : 키 대신 식별자 라고 부르고 점선으로 표시
2-3. 관계(Relation)와 관계 타입
관계 : 개체와 개체 사이 연관성 나타냄. 마름모로 표현
!!!!! 관계에도 속성이 있을 수 있다 !!!!! ex) 구매 관계 속성 : 구매일자, 결제방식
차수(관계 참여하는 개체 타입 개수)에 따른 관계 유형
| 이항관계(개체 타입 2) | 삼항관계(개체 타입(사각형) 3개) | 순환관계(개체 타입 1개가 자기 자신과 맺는 관계) |
| 학생-학과 | 직원-프로젝트-부품 | 학생-멘토링 |
| 학생은 / 소속된다 / 학과에 | 직원은 / 수행한다(부품을 사용해) / 프로젝트를 | 학생은 멘토링을 받기도, 하기도 한다.. 사원은 지시하기도 하고, 지시받기도 한다. (아래 텍스트는 역할 명시한 것.) |
 |
 |
  |
관계 대응 수, 카디널리티(관계에서 개체 간 대응 비율)에 따른 유형
| 1:1 | 1:N | N:M |
| 남편-혼인-아내 | 학과-소속-학생 | 학생-수강-강좌 |
최솟값과 최댓값 표기
(최솟값, 최댓값)
- min = 0 : 선택 참여
- min = 1 : 필수 참여
- max = * : 여러 번 가능
- max = 1 : 딱 한 번
학과 --- (0, *) --- 소속 --- (1, 1) --- 학생
학과 관점에서 학생 입장에서
학생 보는것 학과 상태 보는 것
학과 관점 : 학과 입장에서 학생 최소 0명(신설 학과여서), 최대 여러 명
학생 관점 : 학생 입장에서 학과 최소 1개, 최대 1
Q. 직원 한 명은 노트북을 사용할 수도 있고 안할수도 있다. 노트북도 배정된 직원이 있을 수도 없을 수도 있다.
직원 --- (0, 1) --- 사용 --- (0, 1) --- 노트북
참여 제약 조건
| 전체 참여 : 모든 개체가 반드시 관계에 참여해야 한다 |
부분 참여 : 일부 개체만 참여해도 됨 |
| 필수, 이중선 | 선택, 옵셔널리티, 단일선 |
| 최솟값 표기 시 1 | 최솟값 표기 시 0 |
학생은 수강관계에 부분참여 : 재학생만 수강에 참여
모든 강좌는 수강관계에 전체 참여 : 모든 강좌마다 수강 신청을 하는 학생이 최소 1명씩은 있다.
학생 -- 수강 == 강좌
이 부분이 매우 어려웠다. 이중 실선은 두 가지 쓰임새가 있다.
모든 약한 개체의 관계선은 이중 실선, 모든 이중 실선이 반드시 약한 개체인 것은 아님...
약한 개체 종속성 : 약한 개체는 강한 개체가 없음 존재할 수 없기 때문에 관계선에 이중 실선을 그어서 이 강한개체와의 관계에 반드시 참여해야 한다(전체 참여)를 표시한다. 존재 종속성을 시각화함.
IS-A 관계
: 상속 관계
예)
상위 클래스 : 학생
하위 클래스들 : 휴학생, 재학생, 졸업생(상위의 속성을 공통속성으로 갖고, 자신만의 고유속성 갖는다)
er 다이어그램 표기법 두 가지
| 피터 첸 표기법 | IE (Information Engineering) 표기법 : 새발 표기법 |
 |
 |
3. er 모델을 관계 데이터 모델로 사상(매핑)하기
모든 개체는 릴레이션으로 변환한다!
3-1. 개체 타입의 사상
[1단계] 강한 개체 -> 릴레이션으로
개체 이름 -> [직원 릴레이션]
개체의 속성 -> [직원 릴레이션의 속성]
- 키 속성 -> 기본키
- 복합 속성 -> 단순 속성으로 쪼갬
- 다중 값 속성은 뒤에서 한다. 여기선 생략
| 직원 아이디(기본키) | 나이 | 태어난 년도 | 태어난 월 | 태어난 일 |
[2단계] 약한 개체
약한 개체는 강한 개체의 pk를 외래키fk로 가져와 자신의 기본키를 만든다.(복합키 형태)
약한 개체 기본키(복합키 형태) : 강한 개체 기본키(외래키로 가져옴) + 자신의 식별자
3-2. 관계 타입의 사상
- 방법1, 방법2 : 한쪽에만 타인꺼 기본키를 내 외래키로 넣는 방법
여자(여자번호, 이름, 나이)
남자(남자번호, 이름, 나이)
| 방법1 : 남자가 여자 번호 가짐 | 방법2 : 여자가 남자 번호 가짐 |
| 여자(여자번호, 이름, 나이) 남자(남자번호, 이름, 나이, 여자번호(FK)) |
여자(여자번호, 이름, 나이, 남자번호(FK)) 남자(남자번호, 이름, 나이) |
- 방법3 : 개체에 대한 테이블 2개를 관계 릴레이션 하나로 결합 -> 각 기본키 다 가져옴.
결혼(남자번호, 여자번호, 여자이름, 여자나이, 남자이름, 남자나이)
- 방법4 : 개체1, 개체2, 관계 모두를 독립된 릴레이션으로 표현
여자(여자번호, 이름, 나이)
남자(남자번호, 이름, 나이)
결혼(여자번호, 남자번호)
[3단계] 이진 1:1 관계 타입
방법 1, 2, 3, 4 다 가능!!
- 방법 1, 2 : 한쪽 테이블에 외래키 추가
(예: 컴퓨터 테이블에 사원 번호 기본키를 외래키로 추가
사원 테이블에 컴퓨터 관리번호 기본키를 외래키로 추가)
- 방법 3 : 두 개체를 하나의 테이블로 합치기 -> 관리 힘들어진다.
- 방법 4 : 개체와 관계를 모두 독립된 테이블로 분리하기
(예: 사원, 컴퓨터, 사용 3개 테이블로 분리하기)
[4단계] 이진 1:N 관계 타입
방법 1, 2 로 매핑
- 반드시 N측 릴레이션에 1측 릴레이션의 기본키를 외래키로 추가하기!!!!!!!!!!!
(예: 학생 릴레이션에 학과 릴레이션의 기본키인 학과번호를 외래키로 넣기!!!!)
why?? 1측에 N개의 기본키들 다 넣으면 매우 비효율적이다!!!!!!!
[5단계] N:M 관계 타입
방법 4로 매핑,사상
- 관계를 따로 교차 릴레이션으로 만들고, 이 안에는 각 엔티티의 기본키를 넣는다.
(예: 교수(사번, 이름), 과목(과목코드, 과목명), 수업(사번, 과목코드) : 교차 릴레이션)
[6단계] N진 관계 타입 : er 모델 차수가 3 이상인 경우
방법 4로 매핑, 사상 : 다 분리하자!!!!!
- 5단계와 마찬가지로 개체들, 관계 각각 릴레이션으로 만든다. 이때, 관계 릴레이션에는 각 개체의 기본키를 모은 복합키가 들어간다.
[7단계] 다중 값 속성
| 속성의 개수 제한 정해진 경우(최댓값 정해진 경우) | 속성 개수 몇 개인지 모를 경우 |
| 학생(학번, 이름, 취미1, 취미2, 취미3) | 학생(학번, 이름) 취미(학번, 취미이름) |
| 단점 : 최대 100개일 경우, 누군 100개 다 있는데 누군 0개 -> 비효율 -> sparse matrix로 만들어짐 -> 공간 낭비 |
TIP!!!!!!!!!!!!!
[다대다 관계] : 무조건 분리하자!!!!!
- 각 개체 기본키를 관계 릴레이션에 외래키로 가져옴.
| 각 개체 기본키 가져와서 외래키로 놓고 복합키 | 대리키 추가 |
| 고객번호(fk) + 상품번호(fk) | 주문번호(pk) + 고객번호(fk) + 상품번호(fk) |
| 짱구가 핸드폰을 두 번 주문했을 때, 구분이 안간다. 고객번호 상품번호 001 핸드폰 001 핸드폰 이 두 주문을 구별하기 위해, 대리키 추가한다. -> |
주문번호 고객번호 상품번호 1 001 핸드폰 2 001 핸드폰 복합키만으로 구별 안 될 때 식별용 대리키(주문번호) 추가! |
[일대다 관계] : n측에 1측의 기본키를 외래키로 추가하자!!! 1측 기본키 : 1개, n측 기본키 : n개 당근 1개만 추가하는 게 말이 됨.
- 약한 개체 참여 시 : 위 내용 동일 + (강한개체의 기본키(외래키), 약한 개체 식별자) 로 기본키 구성하기
[일대일 관계] :
- 서로 외래키 주고받기 : 안좋음. 상호참조 발생
- 필수 참여 중심 : 반드시 참여해야 하는 쪽에만 외래키 넣기. 선택 참여쪽은 건드리지 않는다. 필수참여쪽만 외래키 집어넣기
- 테이블 합치기 : 관리 힘들다
[다중값 속성] : 무조건 새 테이블 만들기! + 키는 원래꺼+ 해서 (외래키 + 다중값 속성) 복합 기본키로 만들기!
[순환 관계] : 상사 1명 vs 사원 n명 일 경우 상사의 기본키를 외래키로 추가해서 사원쪽에 붙인다
'학교 강의 > 데이터베이스' 카테고리의 다른 글
| [데이터베이스] JAVA-DB 연결 : 환경세팅, JDBC, DAO, DTO, SOLID (1) | 2026.04.11 |
|---|---|
| [데이터베이스] 뷰, 인덱스, dbms 저장프로그램(프로시저, 트리거, 사용자 정의 함수) (0) | 2026.04.11 |
| [데이터베이스] 2. 관계 데이터 모델 (0) | 2026.03.18 |
| [데이터베이스] 1. 데이터베이스 시스템 (0) | 2026.03.07 |
| [데이터베이스] OT. 데이터베이스 기초 정리 (ERD, 관계형 모델, SQL, JDBC) (0) | 2026.03.07 |