[ SQL 스터디 - 1주차 ] 데이터 모델링의 이해

 
위 포스트는 "혼자 공부하는 SQL" 책 Chapter 2-1 내용과
"유선배 SQL개발자(SQLD) 과외노트" 책 Part 1-1 내용을 바탕으로 정리한 글입니다.
 

한빛미디어 - 혼자 공부하는 SQL (우재남 저) : 무료 동영상 강의 제공

2024 SD에듀 유선배 SQL개발자(SQLD) 과외노트 | 정미나 - 교보문고

 
 
 

** 프로젝트 진행 단계

 
프로젝트란

현실 세계에서 일어나는 업무를 컴퓨터 시스템으로 옮겨놓는 과정이다.
즉 대규모 소프트웨어를 작성하기 위한 전체 과정이라고 할 수 있다.

** 프로그램과 소프트웨어의 구분
프로그래밍 언어를 통해서 만들어진 결과물을 "소프트웨어"라고 부른다.

소프트웨어와 프로그래밍은 거의 비슷한 용어로, 
소프트웨어는 좀 더 큰 단위, 프로그램은 좀 더 작은 단위로 부르기도 한다.
( BUT ! 대부분의 상황에서 구분 없이 사용됨 )

 
 
이 소프트웨어는 개발 절차를 갖추어서 만들어야 하는데,
소프트웨어 공학에서 기본적으로 언급되는 소프트웨어 개발 절차 중 
"폭포수 모델"에 대해 알아보겠다.
 
 

폭포수 모델은

각 단계가 폭포가 떨어지듯 진행되기 때문에 붙여진 이름이다.
총 6단계로 구성되어 있는 이 모델의 단계를 살펴보자.
 
운영하고 있는 슈퍼마켓의 물건을 온라인으로도 판매하기 위해
인터넷 쇼핑몰을 구축한다 가정하며 설명하겠다.
 

1. 프로젝트 계획
슈퍼마켓의 물건들을 온라인으로 판매하기 위한 계획 단계

2. 업무 분석
슈퍼마켓에서 업무가 어떻게 돌아가고 있는지 파악하는 것
ex) 물건은 어디서 들어오는지, 물건을 어떻게 계산하는지 ...

3. 시스템 설계
앞으로 정리한 업무 분석을 컴퓨터에 적용시키기 위해 알맞은 형태로 다듬는 과정

4. 프로그램 구현
앞에서 완성한 시스템 설계의 결과를 실제 프로그래밍 언어로 코딩하는 단계
ex) JavaScript, PHP,JSP 등의 프로그래밍 언어를 사용

5. 테스트
코딩된 프로그램에 오류가 없는지 확인하는 과정

6. 유지보수
실제 온라인 쇼핑몰을 운영하면서 문제점을 보완하고 기능을 추가하는 과정

 
 
각 단계가 구분되어 프로젝트의 진행 단계가 명확하다는 장점이 있으나,
폭포에서 내려가기는 쉬워도 다시 거슬러 올라가는 것은 힘들다는 단점이 존재한다.
 
바로 다음에 학습할 데이터베이스 모델링은
폭포수 모델에서 업부 분석과 시스템 설계에 해당된다.
 
 
 

** 데이터 모델의 이해

 
(1) 모델링이란?

---

 
데이터베이스에서 모델이란

현실 세계에서 일어날 수 있는 다양한 현상에 대해서 일정한 표기법에 의해 표현해 놓은 모형이라고 할 수 있으며,
 

모델링이란

이런 모델을 만들어가는 일이라고 할 수 있다.
 
 

데이터베이스의 모델링 예시

 
 

위 그림과 같이 데이터베이스의 모델링은

"현실 세계를 단순화하여 관리하고자 하는 데이터를 모델로 표현하는 기법" 을 의미한다.
 
DBMS의 데이터베이스 개체로 옮기기 위한 과정인데,
즉 현실에서 쓰이는 것을 테이블과 같은 모델로 변경하기 위한 작업이라고 생각하면 된다.
 
 
 

(2) 모델링의 특징 [ 3가지 - 추단명 ]

---

 
모델링의 특징은 "추상화", "단순화", "명확화"로 크게 3가지로 구분할 수 있다.
 

추상화(Abstraction)는 
현실 세계를 일정한 형식으로 표현한 것이다.
즉, 아이디어나 개념을 간략하게 표현하는 과정이다.

단순화(Simplication)는
복잡한 현실 세계를 정해진 표기법으로 단순하고 쉽게 표현한다는 의미이다.

명확화(Clarity)는
불분명함을 제거하고 명확하게 해석할 수 있도록 기술한다는 의미이다.

 
 
 
 
 
데이터 모델링은 세 가지 "관점"과, "단계"로 구분되는데
우선 관점부터 살펴보자.
 
 

(3) 모델링의 세 가지 관점

---

 
관점은 크게 데이터, 프로세스, 데이터와 프로세스의 상관 관점으로 나눌 수 있다.
 
첫번째로 데이터 관점(What, Data)은
데이터 위주의 모델링이라고 할 수 있다.
어떤 데이터들이 업무와 얽혀있는지, 그리고 그 데이터 간에는 어떤 관계가 있는지에 모델링하는 방법이다.
 
두번째로 프로세스 관점(How, Process)은
프로세스 위주의 모델링이라고 할 수 있다.
이 업무가 실제로 처리하고 있는 일은 무엇인지 또는 앞으로 처리해야 하는 일은 무엇인지를 모델링하는 방법이다.
 
마지막으로 데이터와 프로세스의 상관 관점(Data vs. Process, Interaction)은
데이터와 프로세스의 관계를 위주로 한 모델링이라고 할 수 있다.
프로세스의 흐름에 따라 데이터가 어떤 영향을 받는지를 모델링하는 방법이다.
 
 
 
 

(4) 모델링의 세 가지 단계

---

 
단계는 크게 개념적, 논리적, 물리적 데이터 모델링으로 나눌 수 있다.
 
첫번째로 개념적 데이터 모델링(Conceptual Data Modeling)은
전사적 데이터 모델링 수행 시 행해지며 추상화 레벨이 가장 높은 모델링이다.

전사적

(全社的)

• 회사 전체 차원의 것.
• 회사 전체 차원인.

이 단계에서는 업무 중심적이고 포괄적인 수준의 모델링이 진행된다.
 
 
두번째로 논리적 데이터 모델링(Logical Data Modeling)은
재사용성이 가장 높은 모델링으로, 데이터베이스 모델에 대한 Key, 속성, 관계 등을 모두 표현하는 단계이다.
 
마지막으로 물리적 데이터 모델링(Physical Data Modeling)은
실제 데이터베이스로 구현할 수 있도록 성능이나 가용성 등의 물리적인 성격을 고려하여 모델을 표현하는 단계이다.
 
 
즉 개념적 -> 논리적 -> 물리적 순으로 구체화 단계가 올라간다.
 
 
 
 

(5) 데이터의 독립성 [ 스키마 3단계 구조 ] 

---

 
ANSI - SPARC(American National Standards Institute, Standards Planning and Requirements Committee) 아키텍처는
1975년 제안된 데이터베이스 관리 시스템(DBMS)의 추상적인 설계 표준이다.
 
 
이 아키텍처에서는 스키마를 3단계 구조로 나누는데,
이는 DB에 대한 사용자들의 관점과 DB가 실제로 표현되는 물리적인 방식을 분리하기 위해서이다.

** 스키마

 

 
우선 3단계 구조에 대해 알아보자. (외개내)

* 외부 스키마(External Schema) // 사용자 관점
Multiple User's View 단계로, 각 사용자가 보는 DB의 스키마를 정의한다.

* 개념 스키마(Conceptual Schema) // 통합된 관점
Community View of DB 단계로, 모든 사용자가 보는 DB의 스키마를 통합하여 전체 DB를 나타내는 것이다.
DB에 저장되는 데이터들을 표현하고 데이터들 간의 관계를 나타낸다.

* 내부 스키마(Internal Schema) // 물리적인 관점
Physical Representation 단계로, 물리적인 저장 구조를 나타낸다.
실질적인 데이터의 저장 구조나 컬럼 정의, 인덱스 등이 포함된다.

 
 
이렇게 3단계로 스키마 구조로 분리하여 독립성을 보장할 수 있다.
이때 독립성은 "논리적 독립성"과 "물리적 독립성"이 보장 되어진다.
 

* 논리적 독립성
개념 스키마가 변경되어도 외부 스키마는 영향받지 않는다.
사용자 특성에 맞는 변경이 가능하고 통합 구조의 변경이 가능하다.

 

* 물리적 독립성
내부 스키마가 변경되어도 외부/개념 스키마는 영향받지 않는다.
물리적인 DB가 바뀌어도 응용 프로그램과 개념 스키마에는 영향도가 없다.

 
 
 
 

(6) ERD(Entity Relationship Diagram)

---

 

** ERD란?
시스템에 어떤 엔터티들이 존재하며 그들 간에 어떤 관계가 있는지를 나타내는 다이어그램이다.

** 엔터티

업무에서 쓰이는 데이터를 용도별로 분류한 그룹(Table)

 
ERD 표기 방식에는 
Peter Chen, IDEF1X, IE/Crow's Foot, Min-Max/ISO, UML, Case *Method/Barker 이 있는데,
여러 가지 표기법 중 IE/Crow's Foot 표기법을 중점적으로 알아보겠다.
 
 
IE/Crow's Foot 표기법은
까마귀발 표기법이라고도 부르며 가장 많이 사용한다.
ERWin, ERStudio라는 ERD를 그리는 모델링 툴에서 사용되는 모델이다.
 

기호	의미
□	엔터티
○	0개
|	1개
∈ (비슷하게 구현하려고 했는데 실패.. 뾰족해야함 )	2개 이상
________	부모 엔터티의 식별자가 자식 엔터티의 주식별자 (식별자 관계)
--------------	부모 엔터티의 식별자가 자식 엔터티의 일반 속성 (비식별자 관계)

 
 
 
ERD의 작성 순서는 6단계로 구분한다.
어떤 표기법을 사용하든 ERD를 작성하는 순서는 공통된 룰이며, 다음의 표기 순서를 따른다.

1. 엔터티를 도출하고 그린다.
2. 엔터티를 적절하게 배치한다.
3. 엔터티 간의 관계를 설정한다.
4. 관계명을 기입한다.
5. 관계의 참여도를 기입한다.
6. 관계의 필수 / 선택 여부를 기입한다.

 
 
 
 
 
 

** 엔터티(Entity)

 

(1) 엔터티란?

---

 

데이터베이스에서 엔터티는

식별이 가능한 "객체"라는 의미를 가지고 있다.
업무에서 쓰이는 데이터를 용도별로 분류한 그룹(Table)이라고 할 수 있다.
 
 
위에서 살펴보았던 데이터베이스 모델링의 예시이다.

 
고객, 상품과 같이 식별이 가능한 객체들, 용도별로 분류한 테이블을
데이터베이스에서 엔터티라고 부른다.
'주문한다'와 같은 실체가 없는 행동도 테이블로 변환할 수 있으며, 이 역시 엔터티이다.
 
 
cf) 엔터티는 Table, 인스턴스는 Row, 속성은 Column이다  
 
 

 
(2) 엔터티의 특징

---

 
엔터티의 특징은 크게 5가지로 구분할 수 있다.

1. 업무에서 쓰이는 정보여야 함
2. 유니크함을 보장할 수 있는 식별자가 있어야 함 (인스턴스 중복됨x, 식별 모호x)
3. 2개 이상의 인스턴스를 가지고 있어야 함
4. 반드시 속성을 가지고 있어야 함
5. 다른 엔터티와 1개 이상의 관계를 가지고 있어야 함

 
 
 

(3) 엔터티의 분류

---

엔터티는 크게 2가지 기준으로 분류할 수 있다.
 
 
첫번째로
"형태의 유무"에 따라 분류할 수 있다.

유형 엔터티	- 물리적인 형태 존재 O, 안정적, 지속적 ex) 상품, 회원
개념 엔터티	- 물리적인 형태 존재 X, 개념적 ex) 부서, 학과
사건 엔터티	- 행위를 함으로써 발생, 빈번함, 통계 자료로 이용 가능 ex) 주문, 이벤트 응모

 
 
두번째로
"발생 시점"에 따라 분류할 수 있다.

기본 엔터티	- 독립적으로 생성됨, 자식 엔터티를 가질 수 있음, 다른 엔터티의 부모 역할 ex) 상품, 회원
중심 엔터티	- 기본 엔터티로부터 파생, 행위 엔터티 생성 ex) 주문
행위 엔터티	- 2개 이상의 엔터티로부터 파생, 설계 초기 단계보다는 상세 설계단계에서 노출됨 ex) 주문 내역, 이벤트 응모 이력

 
기본 엔터티 (상품, 회원)
        ↓
중심 엔터티 (주문)
        ↓
행위 엔터티 (주문 내역, 이벤트 응모 이력)
 
 
 
 
 

(4) 엔터티의 이름을 정할 때 주의할 점

---

* 업무에서 실제로 쓰이는 용어 사용
* 한글은 약어를 사용하지 않고 영문은 대문자로 표기
* 단수 명사로 표현하고 띄어쓰기는 하지 않음 
* 다른 엔터티와 의미상으로 중복될 수 없음 (주문, 결제 엔터티는 중복될 수 있음)
* 해당 엔터티가 갖고 있는 데이터가 무엇인지 명확하게 표현

 
1. 집계 -> 무엇을 집계했는지가 불분명
2. 월매출내역들 -> 단수로 명명해야 
3. 주문한 회원 -> 띄어쓰기를 해야함
 
 
 
 
 
 

** 속성(Attribute)

 
 

(1) 속성이란?

---

 
속성은 사물이나 개념의 특징을 설명해줄 수 있는 항목들을 말한다.
즉 엔터티의 특징을 나타내는 최소의 데이터 단위이다. 
 
속성은 크게 2가지 특징을 가지고 있는데,

* 의미상 더 이상 쪼개지지 않는 레벨이어야 하고,
* 프로세스에 필요한 항목이어야 한다.

 
 
 
 

(2) 속성값

---

 
속성값은 엔터티에 속한 하나의 인스턴스를 구체적으로 나타내주는 데이터를 말한다.
하나의 속성은 한 개의 속성값만 가질 수 있다.
속성에 속성값이 여러 개일 경우 별도의 엔터티로 분리한다.
 
 
 
 
 

(3) 엔터티, 인스턴스, 속성, 속성값의 관계

---

 
이제까지 학습한 내용을 잠시 정리해보겠다.
 
아래와 같이 데이터를 용도별로 분류한 그룹 ( = 테이블 )을

"엔터티"라고 한다.

 
여러 테이블 즉, 엔터티가 존재하겠지만
편의상 이 엔터티를  '샤이니 엔터티' 라고 부르며 설명하겠다.
 

활동명	이름	생년월일	출생지
ONEW	이진기	1989.12.14	경기도 수원시
JONGHYUN	김종현	1990.04.08	서울특별시 종로구
KEY	김기범	1991.09.21	대구광역시 수성구
MINHO	최민호	1991.12.09	인천광역시 연수구
TAEMIN	이태민	1993.07.18	서울특별시 도봉구

 
 
샤이니 엔터티에는 현재 5개의 인스턴스가 있다.
이태민의 데이터가 들어있는 인스턴스, 최민호의 데이터가 들어있는 인스턴스.
즉  'TAEMIN / 이태민 / 1993.07.18 / 서울특별시 도봉구' 가 하나의 인스턴스이다.

* 데이터

하나하나의 단편적인 정보를 말한다.

 
엑셀로 설명하자면 이 엔터티에는 5개의 행이 있는데, 행 개념으로 표현한 이것을

"인스턴스" 라고 한다.

** 행

실질적인 진짜 데이터를 말하며, 행 데이터 라고 한다.

엑셀에서 테이블의 가로줄을 의미한다.

 
 
공통적으로 각각의 인스턴스에는 멤버들의 특징을 설명할 수 있는 활동명, 이름, 생년월일, 출생지라는 데이터가 있다.
 
엑셀로 설명하자면 이 엔터티는 4개의 열이 있다고 표현할 수 있는데,
이 '활동명', '이름', '생년월일', '출생지' 각각의 열 이름을 엔터티의 특징을 나타내는 최소의 데이터 단위.

즉 "속성" 이라고 한다.

** 열

엑셀에서 테이블의 세로줄을 의미한다.

각 테이블은 여러 개의 열(컬럼,필드)로 구성된다.

 
각각의 속성은 "속성값" 으로 표현된다.

속성	속성값
활동명	TAEMIN
이름	이태민
생년월일	1993.07.18
출생지	서울특별시 도봉구

 
하나의 인스턴스가 가지고 있는 속성에 대한 구체적인 데이터를

"속성값"이라고 한다.

열이름이 속성이라면, 속성값은 이에 대한 데이터라고 생각하면 된다.
 
 
우리는 이 엔터티, 인스턴스, 속성, 속성값의 관계를 크게 3가지로 정리할 수 있다.

1. 한 개의 엔터티는 두 개 이상의 인스턴스를 갖는다.
2. 한 개의 인스턴스는 두 개 이상의 속성을 갖는다.
3. 한 개의 속성은 하나의 속성값을 갖는다.

 

** 정리
엔터티 ⊃ 인스턴스 ⊃ 속성 의 관계가 성립

 
 
 
 

(4) 분류

---

속성은 크게 특성과 구성방식에 따라 2가지 방식으로 분류할 수 있다.
 
ㄱ. 특성에 따른 분류

기본속성 (Basic Attribute)	업무 프로세스 분석을 통해 바로 정의가 가능한 속성
설계속성 (Designed Attribute)	업무에 존재하지는 않지만 설계하다 보니 필요하다고 판단되어 도출해낸 속성
파생속성 (Derived Attribute)	다른 속성의 속성값을 계산하거나 특정한 규칙으로 변형하여 생성한 속성

 
ㄴ. 구성 방식에 따른 분류

PK(Primary Key) 속성	- 엔터티의 인스턴스들을 식별할 수 있는 속성 - 엔터티에 속한 각 인스턴스에 유니크함을 부여하는 속성
FK(Foreign Key) 속성	- 다른 엔터티의 속성에서 가져온 속성 - 다른 엔터티와 관계를 맺게 해주는 매개체 역할을 하는 속성
일반속성	- PK, FK를 제외한 나머지 속성

 
 
 
 

(5) 도메인 (Domain)

---

속성이 가질 수 있는 속성값의 범위
엔터티를 정의할 때 데이터 타입과 크기로 나타낼 수 있다.
 
cf1 ) 용어 사전
프로젝트에서 속성의 이름을 정확하면서도 직관적으로 부여하고 용어의 혼란을 없애기 위해 사용하는 업무사전이다. 
 
cf2 ) 시스템 카탈로그
- 사용자 테이블과는 별개로 시스템 자체에 관련이 있는 데이터를 담고 있는 데이터베이스이다.
- 시스템 테이블로 구성되어 있어 SQL을 이용하여 조회할 수 있다.
- 시스템 카탈로그에 저장된 데이터를 메타 데이터라고 하며,
  SELECT만 가능하고 INSERT,UPDATE,DELETE는 불가능하다.
 
 
 
 
 

** 관계 (Relationship)

 

(1) 관계란?

---

엔터티와 엔터티와의 관계를 의미한다.
어떠한 연관성이 있는지 타입을 분류하여 "존재 관계"와 "행위 관계"로 나눌 수 있다.
 

 

(2) 존재 관계

---

존재 자체로 연관성이 있는 관계를 의미한다.
직원 - 부서, 학생 - 학과 엔터티가 이에 속한다.

 
 

(3) 행위 관계

---

특정 행위를 함으로써 연관성이 생기는 관계를 의미한다.
회원 - 주문, 학생 - 출석부 엔터티가 이에 속한다.
 
 
 

(4) 표기법

---

엔터티 간의 관계를 나타낼 때의 표기법은 크게 3가지 방식으로 나눌 수 있다.

관계명 (Membership)	관계의 이름
관계차수 (Cardinality)	관계에 참여하는 수
관계선택사양 (Optionality)	필수인지 선택인지의 여부

 
 

# 관계명

엔터티와 엔터티가 어떠한 관계를 맺고 있는지를 나타내주는 문장이다.

멤버 엔터티 관점에서는 '소속된다' 라는 관계명

 
모든 관계는 두 개의 관계명을 가지고 있는데, 
각 엔터티의 관점에서 관계명을 하나씩 가지기 때문이다.
 
위 그림에서 '포함한다' 라는 표현은 연예인 엔터티의 관점에서 관계명을 나타내주는 문장이다.
반대로 멤버 엔터티의 관점에서는 '소속된다'라는 관계명으로 관계가 맺어진다.
 
그리고 관계명은 반드시 명확한 문장으로 표현해야 하며, 진행형이어야 한다.

바람직하지 않은 관계명	바람직한 관계명
연관성이 있다 관계가 있다 출석을 했다	주문한다 소속된다 출석을 한다

 
 

# 관계차수

각 엔터티에서 관계에 참여하는 수를 의미한다.
일반적으로 1:1, 1:M, M:N 형식으로 구분할 수 있다.

1:1 관계
1:M 관계
N:M 관계

 

 
# 관계선택사양

관계선택사양은 이 관계가 필수요소인지 선택사항인지를 나타내는 말이다.

필수적 관계	참여자가 반드시 존재해야 하는 관계
선택적 관계	참여자가 없을 수도 있는 관계

 
 
 

** 식별자(Identifiers)

 
(1) 식별자란?

---

모든 엔터티는 인스턴스를 가지고 있고, 인스턴스는 속성으로 자신의 특성을 나타낸다.
그 중 식별자는 각각의 인스턴스를 구분 가능하게 만들어주는 대표적인 속성을 의미한다.
 
ex) 학번, 군번, 사번, 회원번호, 상품코드 ...
 
 
 

(2) 주식별자

---

주식별자는 기본키, PK(Primary Key)에 해당하는 속성이다.
하나의 속성이 주식별자가 될 수도 있고, 여러 개의 속성이 주식별자가 될 수 있다.
 
 
주식별자는 다음과 같이 4가지 특징을 가지고 있다.

유일성	각 인스턴스에 유니크함을 부여하여 식별이 가능하도록 한다.
최소성	유일성을 보장하는 최소 개수의 속성이어야 한다.
불변성	속성값이 되도록 변하지 않아야 한다.
존재성	속성값이 NULL일 수 없다.

 
여러 개의 속성이 주식별자가 될 수 있는것이지,
하나의 엔터티에서 주식별자가 많을 수록 좋은 것이 아니다.
 
주식별자는 유일성을 보장하는 최소 개수의 속성이어야 한다.
 
 

(3) 분류

---

이 식별자를 분류하는 방식은 여러 가지로 나뉜다.
대표적인 4가지 방식으로 분류 기준을 살펴보자.
 
# 대표성 여부

주식별자 (Primary Identifier)	- 유일성, 최소성, 불변성, 존재성을 가진 대표 식별자 - 다른 엔터티와 참조 관계로 연결
보조식별자 (Alternate Identifier)	- 인스턴스를 식별할 수는 있지만 대표 식별자가 아님 - 다른 엔터티와 참조 관계로 연결되지 않음

 
# 스스로 생성되었는지 여부

내부식별자 (Internal Identifier)	엔터티 내부에서 스스로 생성된 식별자
외부식별자 (Foreign Identifier)	다른 엔터티에서 온 식별자, 다른 엔터티와의 연결고리 역할

 
# 단일 속성의 여부

단일식별자 (Single Identifier)	하나의 속성으로 구성된 식별자
복합식별자 (Composite Identifier)	두 개 이상의 속성으로 구성된 식별자

 
# 대체 여부

원조식별자 (Original Identifier)	업무 프로세스에 존재하는 식별자 가공되지 않은 원래의 식별자 (본질식별자)
대리식별자 (Surrogate Identifier)	주식별자의 속성이 두 개 이상인 경우 그 속성들을 하나로 묶어서 사용하는 식별자 (인조식별자)

 
 
 
상품가격 엔터티에서 식별자의 특성에 대해 알아보자.

 
 
1. 복합 식별자
2. 주식별자
3. 대리식별자
 
 
 

(4) 식별자 vs. 비식별자 관계

---

 
# 식별자 관계(Identification Relationship)
- 부모 엔터티의 식별자가 자식 엔터티의 주식별자가 되는 관계
- 주식별자는 반드시 존재해야 하므로(존재성), 부모 엔터티가 있어야 생성 가능하다.
- 단일식별자인지 복합 식별자인지에 따라 1:1이거나 1:M 이거나가 결정된다.
 

 
 
# 비식별자 관계(Non-Identification Relationship)
- 부모 엔터티의 식별자가 자식 엔터티의 주식별자가 아닌 일반 속성이 되는 관계
- 일반 속성의 속성값은 NULL이 될 수 있다. -> 부모 엔터티가 없는 자식 엔터티의 생성이 가능
- 자식 엔터티가 존재하는 상태에서 부모 엔터티가 삭제될 수도 있다.

 
BUT ! 자식 엔터티의 데이터는 부모 엔터티에 반드시 존재해야 한다.