[1과목] 데이터 모델링의 이해 - 데이터 모델의 이해, 엔터티, 속성, 관계, 식별자

❉ 2024년 출제과목 변동

 

[단권화 작업]

① 사용한 책 : https://product.kyobobook.co.kr/detail/S000001399867

② 참고한 요약본 출처 : https://yurimac.tistory.com/40

③ 독학 인터넷 강의 : https://youtu.be/QB_GYdHUHmA?si=93orI4I3aXJaokF5

 

✧ 용어 정리

✦ 컬럼 = 속성 = 열

✦ 행들의 집합 = 인스턴스

✦ 테이블 = 엔터티

 

Part1, 데이터 모델링의 이해

 

📍데이터 모델링의 개념

• 정보 시스템을 구축하기 위한 데이터 관점의 업무 분석 기법
  • 시스템 구현을 포함해 업무 분석 및 업무 형상화 목적으로~
  • But, 단순 시스템 구현을 위한 사전작업에 의미 있는건 아님!
• 현실 세계의 데이터(what)를 약속된 표기법으로 표현하는 과정
• 데이터베이스를 구축하기 위한 분석 및 설계의 과정
  • 데이터 모델링 자체로서 업무의 흐름을 설명하고, 분석하는 부분에 의미를 가지고 있다.
• 현실 세계의 비즈니스 프로세스와 데이터 요구사항을 추상적이고 구조화된 형태로 표현하는 과정
• 데이터베이스의 구조와 관계를 정의하며, 이를 통해 데이터의 저장/조작/관리 방법을 명확하게 정의

 

📍모델링의 특징

1. 단순화 Simplification

• 현실을 단순화하여 핵심 요소에 집중하고 불필요한 세부사항을 제거
• 단순화를 통해 복잡한현실 세계를 이해하고 표현하기 쉬워짐

2. 추상화 Abstraction 

• 현실세계를 일정한 형식에 맞추어 간략하게 대략적으로 표현하는 과정
• 다양한 현상을 일정한 양식인 표기법에 따라 표현

3. 명확화 Clarity

• 대상에 대한 애매모호함을 최대한 제거하고 정확하게 현상을 기술하는 과정
• 명확화를 통해 모델을 이해하는 이들의 의사소통을 원활히 함 

 

📍데이터 모델링 유의점 ★☆

1. 중복 Duplication

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

2. 비유연성 Inflexibility

• 어떻게 설계했냐에 따라 사소한 업무 변화 될 때마다 데이터 모델이 수시로 변경될 수 O, 유지보수 비용, 어려움 ⬆️
  •  ex) 새로운 과목 추가될 때마다 컬럼을 새로 추가하는게 아니라 행을 추가할 수 있도록 설계
• 데이터의 정의를 데이터의 사용 프로세스와 분리함
  ➡️ 데이터 혹은 프로세스의 작은 변화가 애플리케이션과 데이터 베이스에 중대한 변화를 일으킬 수 있는 가능성을 줄임

3. 비일관성 Inconsistency

• 데이터 베이스 내의 정보가 모순되거나 상반된 내용을 갖는 상태를 의미
  
  • 서로 연관된 다른 데이터와 모순된다는 고려 없이 데이터를 수정해서 발생하는 문제!
• 데이터 품질 관리 필요
• 데이터의 중복이 없더라도 비일관성은 발생할 수 있음!! 
  • ex) 중복 데이터는 없는데, 과목코드가 서로 다르게 설정되어있어서 조인이 안될 수 있잖아.
  • ex) 신용 상태에 대한 갱신 없이 고객의 납부 이력 정보를 갱신하는 경우 
• 데이터 간 상호연관관계를 명확히 정의해서 이런 위험을 사전에 예방
• 사용자가 처리하는 프로세스와 테이블의 연계성을 높이는건 데이터 모델이 업무 변경에 대해 취약하게 만드는 단점이 됨

 

📍데이터 모델링 3가지 요소

• 대상 Entity = 어떤 것 Things : 업무가 관리하고자 하는 대상 (객체) ➡️ 학생 
• 속성, 성격 Attribute  : 대상들이 갖는 속성 (하나의 특징으로 정의될 수 있는 것)
  • ➡️ 학생의 세부 속성을 알 수 있는 학생 이름, 전화번호, 주소 등 
  • 업무에서 필요로하는 인스턴스로 관리하고자 하는 의미상 분리되지 않는 최소의 데이터 단위]
• 관계 Relationship : 대상들 간의 관계  ➡️ 선생님 테이블과의 관계

- 한 개의 엔터티는 2개 이상의 인스턴스 집합
- 한 개의 엔터티는 2개 이상의 속성을 가짐
- 한 개의 속성은 1개의 속성값을 가짐

 

 

📍데이터 모델링의 3단계 

(현실 세계) → 추상화, 단순화, 정확화  →  (모델)

 

1. 개념적 모델링

• 업무 중심적이고, 포괄적(전사적)인 수준의 모델링
• 추상화 수준이 가장 높음 ★
• 업무를 분석 뒤 업무의 핵심 엔터티(Entity)를 추출하는 단계 
  • 학교 시스템 데이터베이스 구축 시, 핵심 엔터티 = 학생, 선생님, 교과과목...
• 도출된 핵심 엔터티(Entity) 들과의 관계들을 표현하기 위해 ERD 작성 (Entity Relationship Diagram)

 

2. 논리적 모델링 (좀 더 구체적으로 정의하는 단계)

• 개념적 모델링의 결과를 토대로 세부속성, 식별자, 관계 등을 표현하는 단계
  • 학생 엔터티에는 이름, 주민번호가 필요하더라~
  • 주 식별자는 뭐다~
  • 어떤 테이블과는 이런 관계를 가지고 있다~
• 데이터 구조를 정의하기 때문에 비슷한 업무나 프로젝트에서 동일한 형태의 데이터 사용 시 재사용 가능
• 동일한 논리적 모델을 사용하는 경우 쿼리도 재사용 가능
• 데이터 정규화 수행
  • 데이터를 어떻게 쪼갤지
  • 엔터티를 이정도 속성만 갖고, 나머지는 다른 엔터티에 넣는게 좋겠다! 라는 등
• 재사용성이 높은 논리적 모델은 유지보수가 용이해짐

 

3. 물리적 모델링

• 논리 모델링이 끝나면 이를 직접 실제로 물리적으로 생성하는 과정
• 데이터베이스 성능, 디스크 저장구조, 하드웨어의 보안성, 가용성 등을 고려
  • 데이터 베이스의 전반적인 성능
  • 각각 테이블마다 보안, 권한 통제 등
• 추상화 수준은 가장 낮음, 가장 구체적인 데이터 모델링!

 

[데이터 독립성 요소]
- 외부 스키마 (논독) : 개개 사용자가 보는 개인적 DB 스키마 → 여러 사용자 관점으로 구성
- 개념 스키마 (논독) : 모든 통합된 사용자 관점을 통합한 전체 DB (논리적 독립성 O)
- 내부 스키마 (물독) : 물리적 장치에서 데이터가 실제적 저장 (물리적 독립성 O)
===============================================
[데이터 독립성]
- 논리적 독립성 : 개념 스키마 변경, 외부 스키마에 영향 X → 외부단계&개념적단계에 고려
- 물리적 독립성 : 내부 스키마 변경, 외부/개념 스키마에 영향 X → 내부단계에 고려
① 물리적 독립성은 물리스키마가 변경되어도 논리 스키마에 영향을 주지 않는다. 
② 물리적 독립성은 파일 저장 구조의 변경이 논리 스키마와 응용프로그램에 영향을 주지 않는다.

 

📍데이터 모델의 표기법 : ERD (Entity Relationship Diagram)

• 엔터티(Entity)와 엔터티 간의 관계(Relationship)를 시각적으로 표현한 다이어그램
  • 데이터 베이스 내에 어떤 엔터티가 있고, 어떤 속성/주식별자/참고관계는 어떤지~ 볼 수 있는 설계도 st
• 가장 중요한 엔터티를 왼쪽 상단에 배치, 조금 아래쪽 중앙에 배치
• 관계는 존재에 의한 관계와 행위에 의한 관계로 구분될 수 있으나 ERD에서는 관계를 연결할 때, 존재와 행위를 구분하지 않고 단일화된 표기법을 사용한다.

- 1976년 피터 첸 Peter Chen이 만든 표기법, 데이터 모델링 표준으로 사용
- IE, Baker 기법이 많이 쓰임
- 엔터티 관계 속성으로 이뤄짐

 

📍ERD 작성절차 : 6단계

1. 엔터티를 도출한 후 그린다

2. 엔터티 적절하게 배치

3. 엔터티 간의 관계를 설정

4. 관계명을 서술 : 엔터티마다 관계가 어떤거다.

5. 관계의 참여도 기술 : 이 엔터티는 필수적인거다, 선택적인 거다 정의

6. 관계의 필수 여부를 확인 

 

좋은 데이터 모델의 요소
1. 완전성  : 업무에 필요한 모든 데이터가 모델에 정의
2. 중복배제 : 하나의 DB 내에 동일한 사실은 한번만.
3. 업무규칙 :  많은 규칙을 사용자가 공유하도록 제공
4. 데이터 재사용 : 데이터가 독립적으로 설계돼야 함
5. 의사소통 : 업무규칙은 엔터티, 서브타입, 속성, 관계 등의 형태로 최대한 자세히 표현
6. 통합성 : 동일한 데이터는 한번만 정의 참조 , 활용

 

 

---

 

 

Part2, 엔터티 (Entity)

📍엔터티(Entity)의 개념

• 현실 세계에서 독립적으로 식별가능한 객체나 사물을 나타냄
  • 모델링할 때 필요한 그 대상
  • 데이터를 표현하는 최소한의 단위
  • 구성요소 : 컬럼(열, 속성)과 인스턴스(행)로 구성되어있음
  • 개념적으로 엔터티, 물리적으로 설계되면 테이블
  • 업무에 필요하고 유용한 정보를 저장하고 관리하기 위한 집합적인 것 보이지 않는 개념 포함
• 엔터티는 업무상 분석해야하는 대상(instance)들로 이루어진 집합
• 엔터티는 다른 엔터티와 관계가 있어야 한다. 단, 통계성 엔터티나 코드성 엔터티의 경우 관계를 생략할 수 있다.
• 유일한 식별자에 의해 식별이 가능해야 한다.
• 엔터티는 반드시 속성이 있어야 한다.
• 영속적으로 존재하는 인스턴스의 집합이어야 한다. (한개 아니고, 두개 이상) 
  • 행들의 집합 = 인스턴스
  • 인스턴스는 엔터티의 특정한 속성 값들로 구성되며, 엔터티의 개념을 현실에서 구체적으로 나타낸 것
  • ex. 엔터티와 속성, 인스턴스의 관계

용어	예시 - 학교 시스템을 구축한다면..
엔터티 Entity	학생, 교수, 수강과목 • • •
속성 Attribute	학번, 이름, 학과 등 (학생을 설명할 수 있는 요소들)
식별자 Indentifier	학번 (고유한 학번으로 각 학생을 식별할 수 있는 식별자)
인스턴스	특정 학생의 데이터 - 학번 : 201935049, 이름 : 홍길동, 학과 : 경영학과

 

 

📍엔터티(Entity)의 특징

1. 유일한 식별자에 의해 식별 가능

• 각각의 행들을 구분할 수 있는 식별자가 필요하다!!!!!!
• 인스턴스가 식별자에 의해 한개씩만 존재하는지 검증 필요
• 유일한 식별자는 그 엔터티만의 인스턴스만의 고유 이름
  • 이름은 동명이인이 있을 수 있으므로, 사번/학번 등이 고유 식별자가 됨

2. 해당 업무에  필요하고 관리하고자 하는 정보

• 설계하는 업무의 시스템 구축에 필요한 정보여야 함
  • ex) 학교 시스템 구축에 학생 정보가 필요하지, 다른 업무에는 학생 정보가 불필요하다.

3. 인스턴스들의 집합

• 영속적으로 존재하는 2개 이상의 인스턴스의 집합
• 인스턴스가 한 개 밖에 없는 에터티는 집합이 아니므로 성립이 안됨

4. 엔터티는 반드시 속성을 가짐

• 각 엔터티는 그것들을 세분화할 수 있는 2개이상의 속성을 가짐
• 하나의 인스턴스는 각각의 속성들에 대한 1개의 속성 값만을 가짐
  • ex) 학생 엔터티에서 한 학생의 데이터(인스턴스)의 이름(속성) 정보에는 반드시 하나의 값만 저장됨

5. 엔터티는 업무 프로세스에 의해 이용

• 업무적으로 필요해서 선정했지만, 실제 사용되지 않으면 잘못 설계된 것
• 모델링 시 발견하기 어려운 경우 데이터 모델 검증이나 상관 모델링 시 단위 프로세스 교차점검으로 문제 도출
• 누락된 프로세스의 경우 추후 해당 프로세스 추가
• 반대로 사용되지 않는 고립 엔터티는 제거 고려 필요

6. 다른 엔터티와 최소 1개이상의 관계 성립

• 엔터티는 업무적 연관성을 갖고 다른 엔터티와 연관의 의미를 가짐 (부모자식, 1:1 관계 등)
• 관계가 없는 엔터티 도출은 부적절한 엔터티이거나 적절한 관계를 찾지 못한 것

 

📍엔터티의 분류

1. 유형과 무형에 따른 분류

 

① 유형 엔터티

• 물리적 형태가 있음 (실체가 있는 대상)
• 안정적이며 지속적으로 활용되는 엔터티
• 업무로부터 구분하기가 가장 용이한 엔터티 (ex. 사원, 물품, 감사 등)

② 개념 엔터티

• 물리적인 형태 없음
• 관리해야할 개념적 정보로부터 구분되는 엔터티
  • ex. 조직-실체없잖아. 여기까지가 a 조직이야. 여기부터는 b 조직이야 개념적으로 정의하는,
  • ex. 보험상품-눈에 보이지 않는.. 

③ 사건 엔터티

• 업무를 수행에 따라 발생하는 엔터티
• 발생량이 많고 각종 통계자료에 이용 (ex. 주문, 청구, 미납 등)

 

2. 발생 시점에 따른 분류 ★

 

① 기본 엔터티

• 그 업무에 원래 존재하는 정보
• 다른 엔터티와 관계에 의해 생성되지 않고 독립적으로 자체적으로 생성
• 타 엔터티의 부모 역할을 하는 엔터티
• 다른 엔터티로부터 주식별자를 상속받지 않고 자신의 고유한 주식별자를 가짐 (ex. 사원, 부서, 고객, 상품 등)
  • 우선 사원이 있어야, 사번변경이력 뭐 이런 데이터를 만들 수 있겠지?

② 중심 엔터티

• 기본 엔터티로부터 파생되는 개념. 그 업무에서 중심적인 역할
• 많은 데이터가 발생되고, 다른 엔터티와의 관계를 통해 많은 행위 엔터티를 생성 (ex. 계약, 사고, 청구, 주문, 매출 등)
  • 그 사원으로 부터 파생된 계약 관련 데이터

③ 행위 엔터티

• 2개 이상의 부모엔터티로부터 발생
• 자주 내용이 바뀌거나 데이터 양이 증가
• 분석 초기 단계보다는 상세 설계 단계나 프로세스와 상관모델링을 진행하면서 도출 
  • ex. 주문 : 1)고객과 2)상품 엔터티로부터 발생하므로 행위 엔터티이기도 함
  • ex. 사원 변경이력 등

 

📍엔터티의 명명

• 현업에서 사용하는 용어 사용
• 가능하면 약자 사용은 자제
• 단수 명사 사용 (학생들 → 학생)
• 모든 엔터티에서 유일하게 이름 부여 (중복 x)
• 엔터티 생성 의미대로 이름 부여 (주문이면 주문)

 

📍엔터티와 인스턴스 표기법

• 엔터티는 사각형으로 표현

 

• 속성은 조금씩 다름
  • IE 표기법 : 엔터티 이름이 위에, 주식별자, 맨 밑에는 일반 식별자
  • Barker 표기법 : 네모박스 안에 엔터티 이름, 그 내부에 #으로 주식별자가 pk, 아래에 나열 (null에 따라 o, ☆)

 

---

 

 

Part3, 속성

📍속성(Attribute)의 개념

• 속성은 업무에서 필요로 하는 고유한 성질, 특징을 의미 (관찰대상) → 컬럼으로 표현할 수 있는 단위
  • 가계부 's 일자, 품목, 금액과 같은• • • 
• (이상하지만..) 속성도 집합이다.
• 업무상 인스턴스로 관리하고자 하는 더 이상 분리되지 않는 최소의 데이터 단위
• 인스턴스의 구성요소
  • 학생 엔터티에 이름, 학번, 학과번호 등이 속성이 될 수 있음

 

📍엔터티, 인스턴스, 속성, 속성값의 관계

• 한 개의 엔터티는 2개 이상의 인스턴스의 집합이어야 한다. (하나의 테이블은 두 개 이상의 행을 가짐)
• 한 개의 엔터티는 2개 이상의 속성을 갖는다. (하나의 테이블은 두 개 이상의 컬럼으로 구성됨)
• 한 개의 속성은 1개의 속성값을 갖는다. (각 컬럼의 값은 하나씩만 삽입 가능)
  • 과목이라는 속성에 한 칸에 수학, 과학 다 들어갈 수 없음!!
• 속성은 엔터티에 속한 엔티티에 대한 자세하고 구체적인 정보를 나타냄. 각 속성은 구체적인 값을 가짐

 

📍속성의 특징

• 반드시 해당 업무에서 필요하고 관리하고자 하는 정보여야 한다
• 정해진 주식별자에 함수적 종속성을 가져야 한다.
  • 각 학생을 구분하는 학번. 학번에 의해서 구분되는걸 함수적 종속성이라고 함!!
• 하나의 속성은 한 개의 값만을 가진다. (한 컬럼의 값은 각 인스턴스마다 하나씩만 저장)
• 하나의 속성에 여러 개의 값이 있는 다중값일 경우 별도의 엔터티를 이용하여 분리한다.
• 하나의 인스턴스는 속성마다 반드시 하나의 속성값을 가진다
• 각 속성이 하나의 값을 갖고 있음을 의미 (속성의 원자성)
  • 원자성 : 데이터 모델에서 각 엔터티의 인스턴스가 해당 속성에 대해 단일하고 명확한 값을 가지는 것을 의미

 

📍함수적 종속성

• 한 속성의 값이 다른 속성의 값에 종속적인 관계를 갖는 특징을 말함
• 즉, 어떤 속성 A의 값에 의해 다른 속성 B도 유일하게 결정된다면, B는 A에 함수적으로 종속됐다 하고, 
• 이를 수식으로 나타내면 A → B 라고 표현함

1. 완전 함수적 종속

• 특정 컬럼이 기본키에 대해 완전히 종속될 때를 말함
• PK를 구성하는 컬럼이 2개 이상일 경우 PK 값 모두에 의한 종속 관계를 나타낼때 완전 함수 종속성 만족
• ex. (주문번호 + 제품 번호)에 의해 수량 컬럼의 값이 결정됨

주문번호와 제품번호를 2개 다 고려했을 때 수량이 결정됨.

2. 부분 함수적 종속

• 기본키 전체가 아니라, 기본키 일부에 대해 종속될 때를 말함
• ex. 수강기록 테이블에서 학생번호와 과목이 PK라고 가정할 때,
• 강사는 과목에 의해서만 결정되는거기 때문에 PK중에 일부한테만 종속되는 거기 때문에 부분 함수적 종속관계

 

 

📍속성의 분류

1. 속성의 특성에 따른 분류

 

① 기본 속성 ★ (일반속성 아니고 기본속성!!!)

• 업무로부터 추출된 모든 일반적인 속성
• 엔터티에 가장 일반적으로 많이 존재하는 속성 ex. 상품명, 지점명, 원금, 예치기간 등

② 설계 속성

• 기본 속성 외에 업무를 규칙화하기 위해 새로 만들어지거나 기본 속성을 변형하여 만들어지는 속성
• ex. 상품코드(상품을 구분하기 위한), 지점코두, 예금분류, 일련번호 등

③ 파생 속성

• 다른 속성에 의해 만들어지는 속성
• 일반적으로 계산된 값들이 해당
• 데이터 정합성을 유지하기 위해, 빠른 성능을 위해 가급적 적게 정의하는 것이 좋음 ex. 상품별 매출 총합, 평균 이자 등  

 

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

 

① PK (Primary Key, 기본키) = 주식별자

• 인스턴스를 식별할 수 있는 속성

② FK (Foreign Key, 외래키) 속성

• 다른 엔터티와의 관계에서 포함된 속성, 참조속성을 가질 때
• 사원, 부서코드, 부서 엔터티에 정의된 부서코드만 할당받기

③ 일반 속성

• 엔터티에 포함되어있고, PK/ FK 에 포함되지 않는 속성

 

3. 분해 여부에 따른 분류 ★ (분해를 얼마나 할 수 있느냐에 따라)

 

① 단일 속성 (unique)

• 하나의 의미로 구성된 경우 ex. 회원 ID, 이름 등

② 복합 속성

• 여러 개의 의미로 구성된 경우 ex. 주소 (시, 구, 동 등으로 분해 가능)

③ 다중값 속성

• 속성에 여러개의 값을 가질 수 있는 경우
• 다중값 속성은 엔터티로 분해 ex. 상품 리스트, 한명당 여러개의 전화번호를 가지고 있을 수 있음 (투폰) 등

 

 

📍속성의 명명 규칙

• 해당 업무에서 사용하는 이름을 부여
• 서술식 속성명은 사용하지 않음
• 약어의 사용은 가급적 제한
• 전체 데이터 모델에서 유일한 명칭

 

📍도메인 Domain

• 도메인은 각 속성이 가질 수 있는 값의 범위를 의미함
  • 학년 = 1,2,3,4,5,6학년
• 엔터티 내에서 속성에 대한 데이터 타입과 크기, 제약사항을 지정하는 것 

 

---

 

Part3, 관계

📍관계(Relationship)의 개념

• 관계는 엔터티 간의 연관성을 나타낸 개념
• 관계를 정의할 때는 인스턴스 (각 행 데이터)간의 논리적인 연관성을 파악하여 정의
• 엔터티를 어떻게 정의하느냐에 따라 관계가 변하기도 함
• 관계 페어링의 집합 : ex) 강사 - 가르친다 (관계) - 수강생
  • 패어링 : 엔터티 안에 인스턴스가 개별적으로 관계를 가지는 것

 

📍관계의 종류

① 존재적 관계

• 한 엔터티의 존재가 다른 엔터티의 존재에 영향을 미치는 관계
• 엔터티 간의 연관된 상태를 의미
• ex. 부서 엔터티가 삭제되면 사원 엔터티의 존재에 영향을 미침

② 행위적 관계

• 엔터티 간의 어떤 행위가 있는 것을 의미
• ex. 고객 엔터티의 행동에 의해  가 발생

❉ ERD에서는 존재관계와 행위관계를 구분하지 않는다.

 

 

📍관계의 구성

• 관계명
• 차수 Cardinality
• 선택성 Optionality : 필요한 관계냐 선택적인 관계냐

❉ 관계의 표기법 3가지
1) 관계명 : 관계의 이름
2) 관계차수 : 1:1, 1:m, m:n (두 엔터티 간의 관계에서 참여자의 수를 나타냄)(=관계의 기수성동)
3) 관계선택성(관계선택사양) : 필수 관계, 선택관계

 

 

📍관계의 차수 Cardinality

• 한 엔터티의 레코드(인스턴스)가 다른 엔터티의 레코드(인스턴스)와 어떻게 연결되는지를 나타내는 표현
• 주로 1:1, 1:N, N:M 등으로 표현

① 1 대 1 관계

•  완전 1 대 1 관계 : 하나의 엔터티에 관계되는 엔터티가 반드시 하나로 존재하는 경우
  • ex) 사원은 반드시 소속 부서가 있어야함 (사원입장에서는 부서가 꼬옥~!)
• 선택적 1 대 1 관계 : 하나의 엔터티에 관계되는 엔터티가 하나이거나 없을 수 있는 경우, 한쪽이 없어도 되는 거
  • ex) 사원은 하나의 소속부서가 있거나 아직 발령 전이면 없을 수 있음 

②  1 대 N 관계

•  엔터티에 하나의 행에 다른 엔터티의 값이 어러개 있는 관계
  • ex) 고객은 여러 개 계좌를 소유할 수 있음
  • ex) 한 부서 입장에서 여러 직원이 있을 수 있음

③  M 대 N 관계

• 두 엔터티가 다대다의 연결 관계 가지고 있음
• 이 경우 조인 시 카테시안 곱이 발생하고, 그럼 성능이 좋지 않으므로
  두 엔터티를 연결하는 연결 엔터티의 추가로 1대 N관계로 해소할 필요가 있음
• ex) 한 학생이 여러 강의를 수강할 수 있고, 한 강의 기준으로도 여러 학생이 보유할 수 있음
  ➡️ 이 두 엔터티의 연결엔터티로는 구매이력 엔터티가 필요함, (연결 엔터티를 통해서 두 관계를 연결하고 다대다를 해소함)

 

 

📍관계의 페어링

• 엔터티 안에 인스턴스(행)가 개별적으로 관계를 가지는 것
• 관계란 페어링의 집합을 의미함

❉ 관계와 차수, 페어링 차이
- 학생과 강의 엔터티는 관계를 가짐
- 한 학생은 여러 강의를 수강할 수 있고, 한 강의도 여러 학생에게 수강될 수 있으므로 M 대 N 관계이며, 이 때 차수는 M : N
- 인스턴스의 관계를 보면, "학생 A가 강의 B를 2023년 1학기에 수강했고, 성적은 A+를 받았다."와 같은 특정한 페어링이 형성
➡️ 이런식으로 관계의 차수는 하나의 엔터티와 다른 엔터티 간의 레코드 연결방식을 나타내는 반면, 
페어링은 두 엔터티 간의 (인스턴스 측면에서 연결고리) 특정 연결을 설명하고, 추가정보를 제공하는 용도로 사용

 

 

---

 

 

Part4, 식별자

📍식별자 개념

• 하나의 엔터티에 구성된 여러 개의 속성 중에 엔터티를 대표할 수 있는 속성을 나타냄
• 하나의 유일한 식별자가 존재해야함
• 식별자는 논리 모델링에서 사용하는 용어, 물리 모델링에서는 키 (key)라고 표현
  • [논리 모델링] 학생 엔터티의 주식별자는 학생번호 속성 
  • [물리 모델링] 학생 테이블의 기본키는 학생번호 컬럼

 

📍주식별자 특징

① 유일성 : 주식별자에 의해 모든 인스턴스를 유일하게 구분

• ex) 학생 엔티티에서 이름 속성은 동명이인이 발생할 수 있으므로 모든 인스턴스를 완벽하게 구분할 수 없으므로, 학생번호와 같은 유일한 식별자를 주식별자로 사용
• 유일성에 의해 이름은 주식별자가 될 수 없음

② 최소성 : 주식별자를 구성하는 속성은 유일성을 만족하는 최소한의 속성으로 구성

• ex) 학생 엔터티의 주식별자는 학생번호만으로 충분한데, 학생번호 + 이름으로 구성할 필요 없음

③ 불변성 : 주식별자가 한번 특정 엔터티에 지정되면 그 식별자의 값은 변하지 않아야함 (항상 고유값으로 존재해야 함)

• ex) 학생 엔터티에 주식별자인 학생번호가 때에 따라 변하면 안됨
• 변하면 이전 기록 말소됨

② 최소성 : 주식별자가 지정되면 반드시 값이 존재해야 하며 NULL은 허용 안됨

 

 

📍식별자 분류

1. "대표성 여부"에 따른 식별자의 분류

주 식별자	보조 식별자
유일성과 최소성을 만족하면서 엔터티를 대표하는 식별자	엔터티 내에서 각 인스턴스를 구분할 수 있는 구분자지만, 대표성을 가지지 못해 참조관계 연결성을 할 수 없는 식별자
엔터티 내에서 각 인스턴스/어커런스를 유일하게 구분할 수 있는 식별자	유일성과 최소성은 만족하지만 대표성을 만족하지 못하는 식별자 (주민번호로 조회할 수는 없는..)
타 엔터티와 참조관계를 연결할 수 있는 식별자

 

 

2. "스스로 생성 여부"에 따른 식별자의 분류

내부 식별자	외부 식별자
다른 엔터티 참조 없이 엔터티 내부에서 스스로 생성되는 식별자	- 다른 엔터티와 관계로 인하여 만들어지는 식별자 (외래키) 우편번호는 식별자이지만, 그건 외부에서 가져온 데이터 - 다른 엔터티로부터 상속되어 정의된 식별자

 

 

3. "속성의 수"에 따른 식별자의 분류

단일 식별자	복합 식별자
하나의 속성으로 구성 (학번)	2개 이상의 속성으로 구성 (여러개 컬럼을 가져야만 식별자 역할을 하는 경우)

 

 

4. "대체 여부"에 따른 식별자의 종류

본질 식별자	인조 식별자
비즈니스 프로세스에서 만들어지는 식별자 (부서번호, 사번 = 업무적으로 의미있는 식별자, 사원 인스턴스의 탄생과 함께 업무적으로 부여되는 본질적인 식별자)	- 인위적으로 시스템적으로 만들어지는 식별자 (추가적인 인덱스 필요) - 자동 증가하는 일련번호 같은 형태 (주문번호 = 주문일자+주문순서+상품코드 | 인조식별자)
엔터티 내의 집합을 명확하게 설명할 수 있는 업무적으로 의미가 부여된 식별자	인조식별자는 대체로 본질 식별자가 복잡한 구성을 가질 때 만들어진다.
	인조식별자를 사용하면 중복데이터를 막기 어려워진다 (인조식별자 보다 이메일 주소가 중복되지 않도록 이메일 주소에 고유성 제약을 둬야 함)

 

 

 

❉ 식별자 표기법

• [IE 표기법] 주식별자를 맨 윗칸에 기술하고, 주식별자가 아니면 아랫칸에 기술
• [Barker 표기법] 주식별자는 #으로 표시

 

📍주식별자 도출 기준

① 해당 업무에서 자주 이용되는 속성을 주식별자로 지정한다.

• 같은 식별자 조건을 만족하더라도 업무적으로 더 많이 사용되는 속성을 주식별자로 지정 (where절에서 많이 쓰는)
• ex) 학생번호와 주민번호 중에 학생번호가 주식별자, 주민번호는 보조식별자

② 명칭이나 내역 등과 같은 이름은 피함

• 이름 자체를 주식별자로 사용하는 행위를 피함
• ex) 부서명 보다는 부서코드를 부여하여 부서코드로 주식별자로 사용

③ 속성의 수를 최대한 적게 구성

• 주식별자를 너무 많은 속성으로 구성 시, 조인으로 인한 성능저하 발생 우려
• 일반적으로 7~8개 이상의 주식별자 구성은 새로운 인조 식별자를 생성하여 모델을 단순화 시키는 것이 좋음!
  • ex) 주문 엔터티에 대해 주문일자 + 주문상품코드 + 고객번호 + • •  등으로 구성  (각각 다 달라지니까)
    ➡️ 주문번호 속성 이라는 인조 식별자를 추가

 

📍관계 간 엔터티 구분

1. 강한 개체

• 독립적으로 존재할 수 있는 엔터티
• ex) 고객과 계좌 엔터티 중 고객이 존재해야 계좌가 존재하니 고객이 더 강한 개체. 고객은 독립적으로 존재 가능

2. 약한 개체

• 독립적으로 존재할 수 없는 엔터티
• ex) 고객과 계좌 엔터티 중, 계좌는 독립적으로 존재할 수 없음 (고객에 의해 파생되는 엔터티) 

 

📍식별관계와 비식별 관계 ★

항목	식별자 관계	비식별자 관계
목적	강한 연결관계 표현	약한 연결관계 표현
자식 주식별자 영향	자식 주식별자의 구성에 포함됨	자식 일반 속성에 포함됨
표기법	실선 표현	점선 표현
연결 고려사항	- 반드시 부모엔터티에 종속 - 자식 주식별자 구성에 부모 주식별자 포함 필요 - 상속받은 주식별자 속성을 타 엔터티에 이전 필요	- 약한 종속관계 - 자식 주식별자 구성을 독립적으로 구성 - 자식 주식별자구성에 부모 주식별자 부분 필요 - 상속받은 주식별자 속성을 타 엔터티에 차단 필요 - 부모쪽의 관계참여가 선택관계

 

1.  식별 관계 Identification Relationship

• 하나의 엔터티의 기본키를 다른 엔터티가 기본키⭕️의 하나로 공유하는 관계
• 식별관계는 ERD에서 실선으로 표시
• ex) 사원과 교육이력 엔터티에서 양쪽 모두 기본키 중 일부가 사원번호임

사원	교육이력
# 사원번호	# 사원번호 (FK) # 수강일자

 

2. 비식별 관계 Non-Identification Relationship

• 강한 개체의 기본키를 다른 엔터티의 기본키가 아닌❌ 일반속성으로 관계를 가지는 것
• 비식별관계는 ERD에서 점선으로 표시
• ex) 부서와 사원의 관계에서 부서의 부서번호(기본키)를 사원 엔터티에서는 일반키로 가짐 (사원에서는 사원번호가 기본키)

비식별자 : 부모속성을 자식의 일반속성으로 사용
1. 부모 없는 자식이 생성될 수 있는 경우
2. 부모와 자식의 생명주기가 다른 경우 (별도로 소멸)
3. 여러개의 엔터티가 하나의 엔터티로 통합되어 표현되었는데 각각의 엔터티가 별도의 관계를 가진 경우
4. 자식 엔터티에 별도의 주식별자를 생성하는 것이 더 유리한 경우
5. SQL 문장이 길어져 복잡성 증가되는 것 방지
- 약한 연결관계표현, 점선 표기
- 비식별자 관계로만 설정시 부모 엔터티와 조인하여 성능 저하

 

 

❉ UML (통합 모델링 언어)에서의 관계
- 연관관계 (실선) : 항상 이용하는 관계, ex> 소속된다.
- 의존관계 (점선) : 상대 행위에 의해 발생하는 관계, ex> 주문한다.
================================
연관관계는 소스코드에서 멤버변수로 선언하여 사용하게 하고, 의존관계는 오퍼레이션에서 파라미터 등으로 이용할 수 있도록 되어있다.