[SQLD]데이터 모델링의 이해 💡

김예진·2024년 1월 30일

SQLD 자격증 준비

SQLD

목록 보기

1/3

1. 데이터 모델의 이해

1-1) 모델링의 정의 및 특성

데이터 모델링의 정의를 이해하기 전에 모델링에 대한 정의에 대해서 알아보자.

* 모델링의 정의

우리가 살고 있는 3차원의 현실 세계를 단순화하여 표현하는 것
현실 세계를 추상화하여 그 구조를 표현한 것
현실세계에 존재하는 사물이나 사건에 관한 관점 및 양상을 연관된 주제를 위하여 명확하게 하는 것

* 모델링의 특징

특징	설명
추상화	현실 세계를 일정한 형식에 맞게 표현하는 것
단순화	현실 세계를 서로가 약속한 규약을 준수하는 표기법이나 언어로 표현하는 것
명확화	현실 세계를 명확하게 기술 모델을 보는 여러 관계자가 쉽게 애매모호험을 제거하여 표현

"모델링은 추상화, 단순화, 명확화하기 위해 일정한 표기법으로 모델을 표현하는 기법"

1-2) 모델링의 3가지 관점

IT시스템의 대상이 되는 비즈니스를 분석하여 IT시스템으로 구성하는 과정에서 비즈니스의 내용과 IT시스템의 모습을 적절한 표기법으로 표현한 것을 모델링으로 3가지의 관점이 있다.

ㄱ. 데이터 관점 (Data, What)

비즈니스와 관련된 데이터는 무엇인지 or 데이터 관의 관계는 무엇인지
What 에 대한 관점

ㄴ. 프로세스 관점 (Process, How)

해당 비즈니스로 인해 일어나는 일은 어떠한 일인지
How에 대한 관점

ㄷ. 상관 관점 (Data vs Process)

데이터 관점과 프로세스 관점 간 서로 어떠한 영향을 받는지

1-3) 데이터 모델링의 정의

데이터 관점으로 업무를 분석하는 기법으로 약속된 표기법으로 데이터의 구조를 표현하는 과정

현실 세계의 비즈니스를 IT시스템으로 구현하기 위해 데이터 관점으로 업무를 분석하는 기법
현실 세계의 비즈니스를 약속된 표기법으로 표현하는 과정
IT시스템의 근간이 되는 데이터베이스를 구축하기 위한 분석 및 설계의 과정

IT시스템은 RDBMS기반으로 구축되어 있으며 데이터 모델링을 총해 정의된 데이터 모델을 기반으로 물리적인 데이터베이스가 구축되고 SQL문을 활용한다.

1-4) 데이터 모델이 제공하는 기능

데이터 모델링 과정을 통해 데이터 모델을 도출하는데 다양한 기능을 제공한다.

항목	설명
가시화	IT시스템의 모습을 가시화하는 기능을 제공
명세화	IT시스템의 구조와 발생하는 동작을 명세화하는 기능을 제공
구조화된 틀	IT시스템을 구현하기 위해 필요한 구조화된 틀을 제공
문서화	IT시스템 구축 시 산출물로 사용되는 문서를 제공
다양한 관점	다른 영역의 세부사항을 숨김으로써 다양한 영역에 집중할 수 있는 관점을 제공
상세 수준의 표현 방법	원하는 목표에 따라 구체화된 상세 수준의 표현 방법을 제공

1-5) 데이터 모델이 중요한 이유

ㄱ. 파급효과 (Leverage)

: 데이터 설계 과정에서 비효율적인 데이터 설계 및 업무 요건을 충족하지 못하는 데이터 설계를 한다면 전 과정에 걸쳐서 엄청난 비용이 발생할 수 있다.

ㄴ. 복잡한 정보 요구사항의 간결한 표현 (Conciseness)

: 좋은 제이터 모델 설계를 통해 IT 시스템에서 구현해야 할 정보 요구사항을 명확하고 간결하게 표현할 수 있다.

ㄷ. 데이터 품질 (Data Quality)

: 데이터 모델의 잘못된 설계로 인해 '데이터 중복, 비유연성, 비일관성' 이 발생할 수 있고 이로 인해 데이터 품질이 저하될 수 있다.

1-6) 데이터 모델링의 3단계

현실 세계 -> 개념적 구조 -> 논리적 구조 -> 물리 구조(데이터베이스)

1단계

개념적 데이터 모델링

IT시스템에서 구현하고자 하는 대상에 대해 포괄적 수준의 데이터 모델링을 진행
전사적 데이터 모델링 시 많이 사용하는 단계

2단계

논리적 데이터 모델링

IT시스템에서 구현하고자 하는 비즈니스를 만족하기 위한 기본키, 속성, 관계, 외래키 등을 정확하게 표현하는 단계

3단계

물리적 데이터 모델링

논리 데이터 모델을 기반으로 실제 물리 DB 구축을 위해 성능, 저장공간 등의 물리적인 특성을 고려하여 설계하는 단계
이 단계에서 완성된 물리 데이터 모델로 물리 DB을 구축

1-7) 데이터 독립성의 필요성

데이터 독립성
: 하위 단계의 데이터 구조가 변경되더라도 상위 단계에는 영향을 미치지 않는 속성을 말한다.

데이터 구조가 변경되더라도 응용 프로그램 단에는 아무런 영향을 미치지 않도록 하는 것

출현 배경
- 보유한 데이터의 복잡도를 낮추고 중복된 데이터를 줄여 시간의 흐름에 따라 증가하는 유지보수 비용 절감 - 사용자의 요구사항은 지속적으로 변하므로 그에 따른 화면과 물리 DB간 독립성을 유지하기 위해

1-8) 데이터베이스의 3단계 구조

ㄱ. 외부단계

외부 스키마 (External Schema)

사용자 관점

각각의 사용자가 보는 DB스키마
개인 사용자 혹은 응용 프로그램 개발자가 접근하는 DB 스키마

ㄴ. 개념적 단계

개념 스키마 (Conceptual Schema)

통합 관점

모든 사용자의 관점을 하나로 통합한 비즈니스 전체의 DB를 기술한 스키마
응용 프로그램 및 사용자들이 필요한 데이터를 통합한 전체 DB를 기술한 것
실제 DB에 저장되는 데이터와 응용 프로그램 및 사용자들 간의 관계를 표현하는 스키마

ㄷ. 내부적 단계

내부 스키마 (Internal Schema)

물리적 관점

DB가 물리적으로 저장된 형식을 표현한 스키마
물리적 하드웨어 장치에 데이터가 실제로 저장되는 방법을 표현한 스키마

1-9) 3단계 구조 속 데이터 독립성

ㄱ. 논리적 데이터 독립성

개념 스키마가 변경되어도 외부 스키마에는 영향을 미치지 않도록 지원하는 것
논리적 구조 가 변경되어도 응용 프로그램에 영향을 미치지 않는다.

사용자 특성에 맞는 변경이 가능
통합 구조의 변경이 가능

ㄴ.물리적 데이터 독립성

내부 스키마가 변경되어도 외부/개념 스키마는 영향을 받지 않도록 지원하는 것
저장 장치의 구조 변경 은 응용 프로그램/개념 스키마에 영향을 미치지 않는다.

물리 구조에 영향 없이 개념 구조의 변경이 가능
개념 구조에 영향 없이 물리 구조의 변경이 가능

1-10) 3단계 구조 속 사상(매핑)

각 단계별 데이터 독립성의 보장이 가능한 이유는 각 단계와 단계 사이를 연결하는 사상(매핑)이 있기 때문으로 2가지의 사상이 있다.

ㄱ. 외부적/개념적 사상 (논리적 사상)

외부적 뷰와 개념적 뷰의 상호 호환성을 정의하는 사상

사용자가 접근하는 형식에 따라 다른 타입의 필드를 가질 수 있고, 이 경우 개념적 뷰의 필드 타입은 변화가 없다.
```
	"논리적 데이터 독립성을 보장"
```

ㄴ. 개념적/내부적 사상 (물리적 사상)

개념적 뷰와 저장된 데이터베이스의 상호 관련성을 정의하는 사상

저장된 데이터베이스 구조가 바뀐다면 개념적/내부적 사상이 바뀌어야 개념 스키마가 그대로 남아 있는다.
```
	"물리적 데이터 독립성을 보장"
```

1-11) 데이터 모델링의 3가지 요소

ㄱ. 업무가 관여하는 어떤 것 (Things)

복수 / 집합 개념 타입 / 클래스	개별 / 단수 개념 어커런스 / 인스턴스
엔터티 타입 (Entity Type)	엔터티 (Entity)
엔터티 (Entity)	인스턴스 (Instance) 어커런스 (Occurrence)

EX)
어떤 것의 전체를 지칭하는 것 = 엔터티 타입 or 엔터티
엔터티 내에 추가된 것 = 인스턴스 or 어커런스

ㄴ. 어떤 것이 가지는 성격 (Attributes)

"Characteristic of a Thing"

복수 / 집합 개념 타입 / 클래스	개별 / 단수 개념 어커런스 / 인스턴스
속성 (Attributes)	속성값 (Attribute Value)

EX)
어떤 것이 가지는 성격 = 속성

ㄷ. 업무가 관여하는 어떤 것 간의 관계 (Relationships)

"Association between Things"

복수 / 집합 개념 타입 / 클래스	개별 / 단수 개념 어커런스 / 인스턴스
관계 (Relationship)	페어링 (Pairing)

EX)
관계에 포함된 개별 연관성 = 페어링

1-12) 좋은 데이터 모델의 요소

IT시스템의 성공적인 구축에 있어서 데이터 모델은 매우 중요한 역할이다.

완전성
: 업무에 필요한 데이터가 모두 정의되어야 함
중복 배제
: 동일한 사실은 단 한번만 저장해야 함
업무 규칙
: 데이터 모델 분석만으로도 비즈니스 로직이 이해되어야 함
데이터 재사용
: 데이터 통합성과 독립성을 고려하여 재사용이 가능해야 함
의사소통
: 데이터 모델을 보고 이해 당사자들끼리 의사소통이 이루어질 수 있어야 함
통합성
: 동일한 데이터는 유일하게 정의해서 다른 영역에서 참고해야 함

1-13) 데이터 모델링의 유의사항

중복(Duplication)

데이터 모델은 같은 데이터를 사용하는 사람, 시간 그리고 장소를 파악하는데 도움을 주어 데이터베이스가 여러 장소에 같은 정보를 저장하는 잘못을 하지 않도록 한다.

비유연성(Inflexibility)

데이터 모델을 어떻게 설계했느냐에 따라 사소한 업무변화에도 데이터 모델이 수시로 변경되어 유지보수의 어려움을 가중시킬 수 있다. 데이터의 정의를 데이터의 사용 프로세스와 분리함으로써 데이터 모델링은 데이터 혹은 프로세스의 작은 변화가 애플리케이션과 데이터 베이스에 중대한 변화를 일으킬 수 있는 가능성을 줄인다.

비일관성(Inconsistency)

데이터 중복이 없더라도 비일관성은 발생할 수 있다. 개발자가 서로 연관된 다른 데이터와 모순된다는 고려 없이 일련의 데이터를 수정할 수 있기 때문에 이와 같은 문제가 발생할 수 있다. 데이터 모델링을 할 때 데이터와 데이터 간의 상호 연관 관계에 대해 명확하게 정의한다면 이러한 위험을 사전에 예방하는 데 도움을 줄 수 있다.

사용자가 처리하는 프로세스 혹은 이와 관련된 프로그램과 테이블의 연계성을 높이는 것은 데이터 모델이 업무 변경에 대해 취약하게 만드는 단점에 해당한다.

2. 엔터티

비즈니스 관점에서 IT시스템을 통해 저장 및 관리해야 하는 집합적인 어떤 것

2-1) 엔터티의 개념

사람, 사물, 사건, 개념 등의 명사에 해당
비즈니스 관점에서 IT시스템을 통해 관리가 필요한 관심사에 해당
결국 비즈니스를 구현하기 위해 저장해야 하는 어떤 것 (Thing)

2-2) 엔터티와 인스턴스

하나의 엔터티는 여러 개의 인스턴스를 가질 수 있으므로 엔터티 = 인스턴스의 집합이라고 할 수 있다.

EX)
엔터티 : 상가
인스턴스 : 스타벅스, 이디야

위의 엔터티와 인스턴스는 1:N 관계라고 할 수 있다.

2-3) 엔터티의 특징

특징	설명
업무에서 필요로 하는 정보	- 비즈니스 요구 조건 만족을 위해 반드시 필요하고 저장 및 관리하고자 하는 정보여야 함 환자라는 엔터티는 병원에서만 반드시 필요하고 일반 회사는 그렇지 않음
식별가능해야 함	- 유일한 식별자에 의해 식별이 가능해야 함 (집합 내에서 단 1개를 짚어낼 수 있어야 함)
인스턴스의 집합	- 영속적으로 존재하는 2개 이상의 인스턴스 집합이어야 함 상가는 여러 개를 의미한다.
업무 프로세스에 의해 이용	- 엔터티는 비즈니스 프로세스에 의해 반드시 이용되어야 함 - 업무 프로세스에 의해 명령문이 발생하지 않는 고립된 엔터티의 경우는 제거하거나 누락된 프로세스가 존재하는지 살펴 프로세스를 추가해야 함
속성을 포함	- 엔터티에는 반드시 속성이 포함되어야 함 - 속성을 포함하지 않고 엔터티의 이름만 가지고 있는 경우는 관계가 생략되어 있거나 업무 분석이 미진하여 속성 정보가 누락되는 경우에 해당
관계의 존재	- 엔터티는 다른 엔터티와 반드시 관계가 있어야 함 업무적 특성에 따라 관계가 없는 엔터티를 엔터티로 도출할 수도 있음

2-4) 엔터티의 분류

엔터티는 유무형에 따른 분류와 발생시점에 따른 분류로 구분된다.

유무형에 따른 분류

구분	예시	설명
유형	사원, 물품, 강사	- 실체가 존재하고 물리적인 형태가 있으며 안정적이고 지속적으로 활용되는 엔터티
개념	조직, 보험상품	- 물리적인 형태가 존재하는 것은 아니지만 비즈니스적으로 관리해야 할 개념적 정보를 저장하는 엔터티
사건	주문, 청구, 미납	- 비즈니스를 수행함으로써 발생되는 엔터티 - 유행 / 개념 엔터티에 비해 데이터 발생량이 많으며 다양한 통계 자료에 이용될 수 있음

발생시점에 따른 분류

구분	예시	설명
기본	사원, 부서, 고객, 상품, 자재	- 비즈니스에서 스스로 태어난 존재에 대한 정보로서 타 엔터티와의 관계에 의해서 생성되는 것이 아닌 독립적으로 생성이 가능한 엔터티 - 기본 엔터티는 타 엔터티의 부모 역할을 하게 됨
중심	계약, 사고, 예금원장, 청구, 주문, 매출	- 기본 엔터티로부터 발생되며 비즈니스에 있어서 중심적인 역할을 하는 엔터티 - 데이터의 양이 많이 발생되고 타 엔터티와의 관계 속에서 많은 행위 엔터티를 도출
행위	주문목록, 사원변경이력	- 2개 이상의 부모 엔터티로부터 발생되는 엔터티 - 다양하고 복잡한 비즈니스를 처리하는 과정에서 데이터양이 많아질 수 있음 - 상세 설계 단계 혹은 프로세스와 상관 모델링을 진행하면서 도출

2-5) 엔터티의 명명규칙

가능한한 업무 담당자들이 사용하는 용어를 사용한다.
가능하면 약어를 사용하지 않는다.
엔터티는 단수명사여야 한다.
엔터티의 이름은 해당 모델 내에서 유일한 이름이어야 한다.
엔터티의 생성 의미에 맞게 이름을 부여한다.

3. 속성

인스턴스에서 관리하고자 하는 의미상 더 이상 분리되지 않는 최소의 데이터 단위

3-1) 속성의 개념

비즈니스에서 필요로 함
엔터티에 대한 설명으로 인스턴스의 구성요소가 됨
의미상 더 이상 분리되지 않는 데이터 단위

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

1개의 엔터티는 2개 이상의 인스턴스의 집합
지하철역은 2개 이상의 역이 존재한다.

1개의 엔터티는 2개 이상의 속성
각각의 지하철역은 역명과 노선명을 가진다.

1개의 속성은 1개의 속성값
각각의 지하철역의 역명은 단 하나이다. 강남역은 강남역!

3-3) 속성의 표기법

속성명에 표시

# 은 식별자임을 의미
* 은 필수값임을 의미
◦ 은 선택값임을 의미

3-4) 속성의 특징

ㄱ. 엔터티와 마찬가지로 반드시 비즈니스에서 필요로 하고 IT시스템에서 저장 및 관리하고자 하는 정보여야 함
ex) 지하철역 엔터티의 역명 속성
ㄴ. 정규화 이론에 따라 속성이 속해 있는 엔터티의 주식별자에 함수적 종석성을 가져야 함
ex) 지하철역 엔터티의 식별자인 지하철역번호가 노선명과 역명을 결정
ㄷ. 하나의 속성에는 1개의 값만을 가진다. 하나의 속성에 여러 개의 값이 있는 다중 값일 경우 별도의 엔터티를 이용하여 분리함
ex) 특정 지하철역의 노선명과 역명은 각각 하나씩

3-5) 속성의 분류

속성은 특성에 따른 분류와 엔터티 구성 방식에 따른 분류로 구분된다.

특성에 따른 분류

특성	설명
기본 속성 (Basic Attribute)	비즈니스 분석을 통해 도출된 속성을 의미 ex) 상가 엔터티의 상호명 속성
설계 속성 (Designed Attribute)	비즈니스 분석을 통해 도출된 것은 아니지만 데이터 모델 설계를 하면서 도출하는 속성 ex) 상가 엔터티의 표준산업분류코드 속성
파생 속성 (Derived Attribute)	다른 속성에 의해서 계산이나 변형이 되어 생성되는 속성 ex) 상가 엔터티의 주소정보를 기반으로 위도, 경도 속성의 값을 구할경우 위도, 경도 속성

엔터티 구성 방식에 따른 분류

구성방식	설명
PK(Primary Key) 속성	엔터티에서 단 하나의 인스턴스를 식별할 수 있는 속성 ex) 상가 엔터티의 상호번호 속성
FK(Foreign Key) 속성	타 엔터티와의 관계를 통해 포함된 속성 ex) 지하철승하차 엔터티의 지하철역번호 속성
일반 속성	엔터티 내에 존재하면서 PK 혹은 FK 속성이 아닌 속성 ex) 상가 엔터티의 상호명 속성

3-6) 도메인

속성이 가질 수 있는 값의 범위를 도메인이라고 한다.
각 속성의 속성값은 정의된 도메인 이외의 값을 가질 수 없다.

- 학생 엔터티의 학점 속성의 도메인은 실수 값으로 정의
- 학생 엔터티의 핸드폰번호 속성은 문자열로 정의

3-7) 속성의 명명규칙

비즈니스에 사용하는 이름을 부여한다.
속성명을 서술식으로 명명하지 않는다.
속성 명명 시 약어 사용은 가급적 하지 않는다.
전체 데이터 모델 내에서 유일한 이름의 속성명으로 명명하는 것이 좋다.

4. 관계

4-1) 관계의 정의

엔터티끼리 상호 연관성이 있는 상태
데이터 모델 내에 존재하는 엔터티 간 논리적인 연관성

cf) 관계는 존재에 의한 관계 & 행위에 의한 관계 가 있다.

4-2) 관계의 페어링

엔터티 내의 인스턴스가 개별적으로 관계를 가지는 것

관계는 엔터티 안에 인스턴스가 개별적으로 관계를 가지는 것이고 이것의 집합을 관계로 표현한다.

개별 인스턴스가 각각 다른 종류의 관계를 가지고 있다면 두 엔터티 사이에 2개 이상의 관계가 형성될 수 있다.

관계는 관계 페어링을 논리적 으로 표현한 것

4-3) 관계의 표기법

관계의 표기 시에는 관계 차수 및 관계 선택사양을 명확하게 해야 한다.

관계 차수

2개의 엔터티 간 관계에서 참여자의 수를 표현하는 것
1 : N, 1 : 1, N : M

관계 선택사양

필수참여관계
ex) '열차문' 이 완전히 닫혀야만 '열차는 출발' !
열차의 출발과 열차문의 완전한 닫힘을 "필수적인 연관관계"
선택참여관계
ex) '열차의 출발 안내 방송' 은 '열차의 출발' 과는 상관없이 언제든지 방송할 수 있다. 안내와 상관없이 열차는 출발!
열차의 출발과 출발 안내 방송은 필수적인 상황은 아니므로 "선택적인 연관관계"

4-4) 관계정의 시 체크 사항

엔터티 간의 관계를 정의할 때는 체크 사항을 만족하는지 확인
1. 2개의 엔터티 사이에 관심 있는 연관 규칙이 존재하는가?
2. 2개의 엔터티 사이에 정보의 조합이 발생되는가?
3. 업무기술서, 장표에 관계연결에 대한 규칙이 서술되어 있는가?
4. 업무기술서, 장표에 관계연결을 가능하게 하는 동사가 있는가?

5. 식별자

엔터티에서 단 하나의 인스턴스를 구별해 낼 수 있는 논리적인 이름

5-1) 식별자의 개념

엔터티의 각 인스턴스를 개별적으로 식별하기 위해 사용되는 하나의 속성 혹은 속성들의 조합을 식별자라고 한다.
엔터티 내에서 하나의 행을 콕 집어낼 때 사용하는 것

5-2) 식별자의 특징

특징	내용
유일성	- 엔티티 내에 존재하는 각각의 인스턴스 집합은 주식별자에 의해 유일하게 구분할 수 있다. ex) 사원 엔티티의 사원번호 속성은 주식별자로 고유하게 부여된다.
최소성	- 유일성을 만족한다면 주식별자를 구성하는 속성의 수는 최소한의 수로 이루어져야 한다. ex) 사원번호만으로 고유한 구조인데 '사원분류코드 + 사원번호' 조합은 부적절한 구조이다.
불변성	- 엔터티 내 특정 인스턴스에 주식별자가 한번 정해지면 그 값은 변하지 말아야 한다. ex) 한번 정해진 사원번호의 값은 다른 값으로 변경되지 않아야 한다.
존재성	- 주식별자가 지정되면 반드시 데이터 값이 존재해야 한다. (NULL 허용 불가) - 주식별자로 정해진 속성은 반드시 데이터 값이 존재해야 한다. - 주식별자는 NULL을 허용하지 않는다. ex) 사원번호가 없는 회사직원은 없다.

5-3) 식별자의 분류

대표성 여부

식별자	설명
주식별자	- 엔터티 내에서 각각의 행을 구별할 수 있는 구분자 - 다른 엔터티와 참조관계를 가질 때 연결할 수 있는 식별자 ex) 사원번호, 고객번호
보조식별자	- 엔터티 내에서 각각의 행을 구별할 수 있는 구분자지만 대표성을 가지지 못하므로 다른 엔터티와 참조관계를 가질 때 연결할 수 없다. ex) 주민등록번호

스스로 생성 여부

식별자	설명
내부식별자	- 엔터티 내부에서 스스로 만들어지는 식별자 ex) 고객번호
외부식별자	- 다른 엔터티와의 관계를 통해 다른 엔터티로부터 받아오는 식별자 ex) 주문 엔터티의 고객번호

속성의 수

식별자	설명
단일식별자	- 하나의 속성으로 구성된 식별자 ex) 고객 엔터티의 고객번호
복합식별자	- 둘 이상의 속성으로 구성된 식별자 - 과도한 복합식별자는 지양 ex) 주문상세 엔터티의 주문번호 + 상세순번

대체 여부

식별자	설명
본질식별자	- 비즈니스에 의해 만들어지는 식별자 ex) 고객번호
인조식별자	- 비즈니스적으로 만들어지지는 않지만 본식별자가 복잡한 구성을 가지고 있기 때문에 만든 식별자 ex) 주문 엔터티의 주문번호 (원래는 고객번호+주문순번)

5-4) 식별자 도출 기준

비즈니스에서 자주 이용되는 속성을 주식별자로 지정한다.
명칭, 장소와 같이 이름으로 기술되는 속성은 가능하면 주식별자로 하지 않는다.
주식별자를 복합식별자로 할 경우 지나치게 많은 속성이 포함되지 않도록 한다.

5-5) 식별자 관계 or 비식별자 관계

부모 엔터티로부터 받은 외부식별자를 주식별자로 이용할 것인지 (식별자 관계)
부모와 연결이 되는 속성으로서만 이용할 것인지 (비식별자 관계)
업무 특징, 자식 엔터티의 주식별자 구성, SQL작성 전략에 의해 결정!!

식별자 관계

자식 엔터티의 주식별자로 부모 엔터티의 주식별자가 상속이 되는 경우를 의미한다.

부모로부터 받은 식별자를 자식 엔터티의 주식별자로 이용하는 경우는 NULL이 허용되지 않는다.
→ 부모 엔터티가 생성되어야 자식 엔터티가 생성된다.
자식 엔터티에서 외부식별자가 주식별자 역할을 한다.
부모 엔터티의 식별자가 자식 엔터티에서도 식별자 역할을 하는 것이다.

" 식별자 관계로만 관계를 맺을 경우,
SQL문의 복잡성이 올라가고 조인 조건이 누락되는 실수가 발생할 확률이 높아진다. "

비식별자 관계

부모 엔터티로부터 속성을 물려 받았지만 자식 엔터티의 주식별자로 사용하지 않고 일반적인 속성으로만 사용하는 경우를 의미한다.

자식 엔터티에서 받은 속성이 반드시 필수가 아니어도 무방하기 때문에 부모 없는 자식이 생성될 수 있는 경우를 의미한다.

부모 엔터티의 주식별자를 자식 엔터티의 주식별자 속성으로 사용해도 되지만 자식 엔터티에서 별도의 주식별자를 생성하는 것이 더 유리하다고 판단될 때, 비식별자 관계에 의한 외부식별자로 표현한다.

5-6) 관계 설정 고려사항

기본적으로 식별자 관계로 모든 관계를 연결하면서 조건에 해당할 경우 비식별자 관계로 조정한다.

관계의 강/약 분석에서 약한 관계일 경우!
자식 테이블 독립 PK가 필요한 독립 PK구성이 필요한 경우!
SQL복잡성이 증가하여 PK 속성을 단순화해야 할 경우!

항목	식별자 관계	비식별자 관계
목적	강한 연결 관계를 표현한다.	약한 연결 관계를 표현한다.
자식 주식별자 영향	부모 엔터티의 주식별자 속성이 자식 엔터티의 주식별자의 구성에 포함된다.	부모 엔터티의 주식별자 속성이 자식 엔터티의 일반 속성이 된다.
연결 고려사항	- 부모 엔티티에 종속되는 경우에 사용한다. - 자식 엔터티의 주식별자 구성에 부모 엔터티 의 주식별자 속성이 필요한 경우에 사용한다. - 부모 엔터티에게서 상속받은 주식별자 속성 을 타 엔터티에 이전이 필요한 경우 사용한다.	- 약한 종속 관계인 경우에 사용한다. - 자식 엔터티의 주식별자 구성을 독립적으로 구성할 경우에 사용한다. - 부모 엔터티로부터 상속받은 주식별자 속성 을 타 엔터티에게 이전하지 않도록 차단이 필요한 경우에 사용한다. - 부모 엔터티의 주식별자가 NULL이 허용되 는 (선택 관계) 경우에 사용한다.

김예진

HAPPY

다음 포스트