[SQLD 요약] I. 데이터 모델링의 이해 (1)

 

 

SQLD 요약 / SQL Developer 요약

🔑 데이터 모델링/ 추상화/ 단순화/ 명확성/ 독립성/ ERD(Entity Relationship Diagram)/

       3층 스키마/ 사용자 - 외부/ 설계자 - 개념/ 개발자 - 내부/ 엔터티/ 속성/ 관계/ 관계차수/ 

       강한개체/ 약한개체/ 식별관계/ 비식별관계/ 식별자/ 기본키/ 최소성/ 대표성/ 유일성/ 불변성/ 외래키

 

 

I. 데이터 모델링의 이해

   01. 데이터 모델링의 이해

 

 

 

---

---

 

 

01. 데이터 모델링의 이해

 

 

[1] 데이터 모델링 (Data Modeling)

(1) 데이터 모델링 | 고객의 비즈니스 프로세스를 이해하고, 규칙을 정의하여, 데이터 모델로 표현함

• 현실세계를 DB로 표현하기 위해 추상화
• 고객과의 의사소통을 통해서, 고객의 업무 프로세스를 이해해야 함
• 업무 프로세스를 추상화 & 소프트웨어를 분석 및 설계하면서 점점 상세해짐
  
  
• 모델링 과정
  - 데이터 모델링 표기법 사용
  - 고객이 쉽게 이해할 수 있도록
  - 복잡하지 않게 모델링해야 함

 

• 데이터 모델링 특징: 추상화/ 단순화/ 명확성

추상화 Abstraction	단순화 Simplification	명확성 Clarity
- 현실세계를 간략하게 표현 - 공통적인 특징을 찾고 간략하게 표현	- 누구나 쉽게 이해 가능 - 복잡한 문제 X	- 모호하지 않고, 명확한 의미 해석 - 한 가지 의미를 가짐

 

 

• 데이터 모델링 단계: 개념적 모델링 → 논리적 모델링 → 물리적 모델링

개념적 모델링	논리적 모델링	물리적 모델링
- 업무적 & 전사적 관점에서 모델링 - 중요한 부분 위주로	- 변환 작업 (개념적→논리적) - 식별자 정의 & 독립성 확보	- 데이터베이스 실제 구축
- 업무 측면에서 모델링 수행 - 중요한 부분 위주로 (복잡 X) - 기술적 용어는 가급적 사용 X - 추상화 수준 가장 높음↑ - 엔터티, 속성 도출 → ERD 작성!	- 특정 데이터베이스 모델에 종속함 - 식별자를 도출, 정의하고 - 모든 릴레이션, 관계, 속성 등을 표현 - 정규화를 통해, 모델의 독립성을 확보하고   재사용성을 높임	- DB 관리시스템에   테이블, 인덱스, 함수 등을 생성 - 성능, 보안, 가용성 등을 고려

 

 

• 데이터 모델링 관점: 데이터/ 프로세스/ 데이터와 프로세스

데이터	프로세스	데이터와 프로세스
비즈니스 프로세스에서 사용되는 데이터	비즈니스 프로세스에서 수행하는 작업	데이터-프로세스 간의 관계
- 구조 분석 - 정적 분석	- 시나리오 분석 - 도메인 분석 / 동적 분석	- CRUD 분석   (Create, Read, Update, Delete)

 

 

• 데이터 모델링 고려사항: 독립성/ 정규화/ 고객 요구사항 표현/ 데이터 품질 확보
• 데이터 중복/ 비유연성/ 비일관성이 발생하지 않도록 모델링 해야함!

데이터 모델의 독립성	고객 요구사항의 표현	데이터 품질 확보
- 정규화를 통해 중복 데이터 제거 - 중복을 제거하여 모델 독립성 확보 - 독립성 확보된 모델은 고객 업무변화에   능동적 대응 가능!	- 고객 요구사항을 간결, 명확히 표현 - 모델을 통해 데이터 모델러와 고객 간의   의사소통이 가능하도록!	- 데이터 표준을 확보해야, 품질 향상 가능 - 데이터 표준을 정의하고 DB 구축 - 표준 준수율 관리해야 함

 

 

 

(2) 데이터 모델링을 위한 ERD | 엔터티-엔터티 간 관계를 정의하는 모델링 방법

• ERD: Entity Relationship Diagram
• 사실상 데이터 모델링 표준!
• 중요한 엔터티는 왼쪽 상단에 배치!
• 이해하기 쉬움 & 복잡하지 않아야 함
  
  
• ERD 절차: 엔터티 도출 → 엔터티 배치 → 엔터티 관계 설정 → 관계명 서술 → 관계 참여도 표현 → 관계 필수여부 표현

ERD 작성 절차	설명
① 엔터티 도출 및 그림	업무에서 관리해야 하는 집합을 도출
② 엔터티 배치	중요한 엔터티는 왼쪽 상단 배치
③ 엔터티 간 관계 설정	엔터티 간 관련성 파악
④ 관계명 서술	엔터티 간의 행위 or 존재
⑤ 관계 참여도 표현	한 엔터티와 다른 엔터티 간에 참여하는 관계의 수
⑥ 관계 필수여부 표현	반드시 존재해야 하는지 or 아닌지 표시

 

 

 

 

---

 

 

[2] 3층 스키마 (3-Level Schema)

(1) 3층 스키마 | 3단계 계층(View)으로 분리하여, 데이터베이스의 독립성을 확보하기 위한 방법

• 사용자/ 설계자/ 개발자가 DB를 보는 관점에 따라서, DB를 기술하고 관계를 정의한 ANSI 표준

3층 스키마

 

 

• 3층 스키마 구조: 사용자 - 외부/ 설계자 - 개념/ 개발자 - 내부

외부 스키마	개념 스키마	내부 스키마
- 사용자 관점 - 업무상 관련있는 접근	- 설계자 관점 - 사용자 전체 집단의 DB 구조	- 개발자 관점 - 물리적 저장 구조
- 관련 DB의 뷰를 표시 - 응용 프로그램이 접근하는 DB 정의	- 전체 DB 내의 규칙, 구조 표현 - 통합 데이터베이스 구조	- 데이터 저장 구조, 레코드 구조,   필드 정의, 인덱스 등

 

 

• 3층 스키마 독립성: 논리적 독립성 & 물리적 독립성

논리적 독립성	물리적 독립성	독립성 확보 시 장점
개념 스키마가 변경되어도 외부 스키마에 영향 X	내부 스키마가 변경되어도 개념 스키마에 영향 X	- 데이터 복잡도 증가 - 데이터 중복 제거 - 사용자 요구사항 변경에    대응력 향상 - 관리, 유지보수 비용 절감

 

---

 

[3] 엔터티 (Entity)

(1) 엔터티 | 업무에서 관리해야 하는 데이터

• 정보가 저장될 수 있는 장소, 사람, 사건, 개념 물건 등 (Thomas Bruce, 1992)
• 고객의 비즈니스 프로세스에서 관리, 저장되어야 하는 정보를 추출
• 예를 들어, 고객이 회원가입을 하여 계좌를 개설하는 비즈니스 프로세스 ⇒ 고객, 계좌 엔터티 도출
• 엔터티는 다른 개체와 확연히 구분되는 특성 가짐 → 모델의 독립성을 향상시킴

 

• 엔터티 특징: 식별자/ 인스턴스 집합/ 속성/ 관계/ 업무

식별자	인스턴스 집합	속성	관계	업무
유일한 식별자가 있어야 함	2개 이상의 인스턴스가 있어야 함	반드시 속성을 가지고 있어야 함	다른 엔터티와 최소 1개 이상의 관계	엔터티는 업무에서 관리되어야 하는 집합
"고객"의 회원ID, "계좌"의 계좌번호 등	"고객" 엔터티의 경우 고객 정보 2명 이상	"계좌"의 계좌번호, 담당자 등	"고객"은 "계좌"를 개설	"고객", "계좌"

 

테이블 = 릴레이션	Relationship	인스턴스
릴레이션에 기본키, 제약조건을 설정하면 테이블	릴레이션 간의 관계	릴레이션이 가질 수 있는 값 (데이터셋에서 행의 개수)

 

 

 

(2) 엔터티 종류 | 유무형에 따라서 - 유형/ 개념/ 사건 & 발생시점에 따라서 - 기본/ 중심/ 행위

• 물리적 형태의 존재여부에 따라서: 유형 엔터티/ 개념 엔터티/ 사건 엔터티

유형 엔터티	개념 엔터티	사건 엔터티
- 업무에서 도출됨 - 지속적으로 사용됨	- 물리적 형태 없음 - 개념적으로 사용됨	- 비즈니스 프로세스   실행하면서 생성됨
"고객", "사원" 등	"거래소 종목", "보험 상품" 등	"주문", "수수료 청구" 등

 

 

• 발생시점에 따라서: 기본 엔터티/ 중심 엔터티/ 행위 엔터티

기본 엔터티 = 키 엔터티	중심 엔터티 = 메인 엔터티	행위 엔터티
- 다른 엔터티의 도움없이 생성됨 - 다른 엔터티로부터 영향 받지 않음 - 독립적으로 생성되는 엔터티	- 키와 행위의 중간 (업무처리의 중심) - 기본 엔터티로부터 발생/파생됨 - 행위 엔터티를 생성함	- 2개 이상의 엔터티로부터 발생 - 업무처리 중에 발생되는 엔터티 - 자주 변경됨 & 지속적으로 정보 추가됨   → 데이터양이 가장 많을 것으로 예상됨
"고객", "부서", "상품" 등	"계좌", "주문", "주문취소"	"주문 이력", "취소 이력" 등

 

---

 

[4] 속성 (Attribute)

(1) 속성 | 업무에서 필요한 정보인 엔터티가 가지는 항목, 인스턴스의 구성요소

• 속성은 사물의 본질/ 성질/ 특징을 의미하며, 중복된 값이 존재할 수 있음
  
  
• 속성명 유의사항
  - 속성명은 업무에서 사용하는 명칭을 사용함
  - 속성명은 데이터 모델 내에서 유일해야 함
  - 속성명은 서술어, 약어를 지양해야 함

속성 Attribute	속성의 특징	도메인 Domain
- 업무에 필요한 정보를 저장 - 인스턴스의 구성요소 - 더 이상 분리되지 않음	- 속성은 1개의 값만 가짐 - 업무에서 관리되는 정보 - 주식별자에게 함수적으로 종속됨   (기본키 변경 → 속성값 변경)	하나의 속성이 가질 수 있는 모든 원자값들의 집합

 

 

(2) 속성 종류 | 분해여부에 따라서 - 단일/ 복합/ 다중값 & 특성에 따라서 - 기본/ 설계/ 파생

• 분해 여부에 따라서: 단일 속성/ 복합 속성/ 다중값 속성

단일 속성	복합 속성	다중값 속성
하나의 의미로 구성됨	여러 의미가 있음	속성에 여러 개의 값을 가질 수 있음 ⇒ 엔터티로 분해됨
"회원ID", "이름" 등	"주소", "주민번호" 등	"상품 리스트" 등

 

 

• 특성에 따라서: 기본 속성/ 설계 속성/ 파생 속성

 

기본 속성	설계 속성	파생 속성
- 비즈니스 프로세스에서 도출됨 - 본래의 속성	- 데이터 모델링 과정에서 발생함 - 유일한 값을 부여	- 다른 속성에 의해 만들어짐
"회원ID", "이름", "계좌번호" 등	"지점코드", "상품코드" 등	"합계", "평균", "중앙값" 등

 

 

 

 

---

 

 

[5] 관계 (Relationship)

(1) 관계 | 엔터티 간의 관련성

• 관계 종류: 존재 관계 & 행위 관계

존재 관계	행위 관계
엔터티 간의 상태	엔터티 간에 어떤 행위가 있음
(ex) "고객"과 "관리점"은 존재 관계          고객이 가입하면, 관리점이 할당되어 관리함.	(ex) "계좌"와 "주문이력"은 행위 관계          증권회사는 계좌를 개설하고 주문을 발주함.

 

 

• 필수적 관계 & 선택적 관계

필수적 관계 (표현: | )	선택적 관계 (표현 : O )
반드시 하나가 있어야 함	없을 수도 있는 관계
(ex) "고객" 엔터티가 있어야, "계좌" 엔터티 개설 가능	(ex) "고객"이 있지만 "계좌"는 없을 수도 있는 상황

 

 

• 관계 차수 (Cardinality): 2개 엔터티 간 관계에 참여하는 수
• 카디널리티 (Cardinality): 하나의 릴레이션에서 튜플의 전체 개수

1 대 1 관계	1 대 N 관계	M 대 N 관계
완전 1대1 : 1개 엔터티에 관계되는 엔터티의 관계가 1개 이며, 반드시 존재함	엔터티에 행이 1개 있을 때, 다른 엔터티의 값이 여러 개 있는 관계	2개 엔터티가 서로 여러 개의 관계를 가짐 ⇒ 1대N, N대1로 해소해야 함
선택적 1대1 : 관계가 1개이거나 없을 수 있음	(ex) "고객"은 "계좌"를 여러 개 개설 가능	(ex) "학생"과 "과목"의 관계 ⇒ "수강" 엔터티를 추가 도출하여 해소

 

 

(2) 식별 관계와 비식별 관계

• 강한 개체 & 약한 개체
  

강한 개체 Strong Entity	약한 개체 Weak Entity
- 다른 개체에게 지배/종속되지 않음 - 독립적으로 존재하는 개체	- 다른 개체에 의존함 - 다른 개체의 존재에 약한 개체의 존재가 달려 있음

 

 

• 식별 관계 & 비식별 관계

식별 관계 (Identification Relationship)	비식별 관계 (Non-Identification Relationship)
실선으로 표현 (강한 연결관계)	점선으로 표현 (약한 연결관계)
강한개체의 기본키를 다른개체의 기본키 중 하나로 공유함	강한개체의 기본키를 다른개체의 일반키로 공유함
강한개체의 기본키 값이 변경되면, 식별관계에 있는 엔터티의 값도 변경됨	다른 엔터티의 기본키가 아닌 칼럼으로 공유 (단순한 외래키로 참조함)
기본키를 공유받은 다른개체는 약한개체가 된다 (독립적으로 존재 불가능)	기본키를 공유받은 다른개체는 약한개체가 아님 (독립적으로 존재 가능)

 

---

 

[6] 엔터티 식별자 (Identifier)

(1) 식별자 | 엔터티를 대표할 수 있는 "유일성"을 만족하는 속성

• 식별자는 최소성/ 유일성/ Not Null 을 만족하고, 해당 엔터티를 대표할 수 있어야 함
• 식별자 예시: 회원ID, 계좌번호, 주민등록번호, 여권번호, 종목번호, 과목번호 등
  
  
• 데이터베이스 키 (Key): 기본키/ 후보키/ 슈퍼키/ 대체키/ 외래키

기본키 Primary Key	후보키 Candidate Key	슈퍼키 Super Key	대체키 Alternative Key	외래키 Foreign Key
후보키들 중에서 엔터티를 대표하는 키	유일성 만족 O 최소성 만족 O	유일성 만족 O 최소성 만족 X	여러 후보키들 중 기본키 선정하고 남은 키	하나 or 다수의 다른 테이블의 기본키 필드

 

• 주식별자 = 기본키 = Primary Key (PK): 최소성/ 대표성/ 유일성/ 불변성 만족

최소성	대표성	유일성	불변성
꼭 필요한 최소의 속성으로 구성되어야 함	기본키는 엔터티를 대표할 수 있어야 함	엔터티의 인스턴스를 유일하게 식별함	기본키는 자주 변경되지 않아야 함

 

• 외래키: 하나 혹은 다수의 다른 테이블의 기본키 필드
  - 참조 무결성을 확인하기 위해 사용되는 키 (참조 무결성 = Referential Integrity)
  - 허용된 데이터 값만 저장하기 위해 사용되는 키

 

 

(2) 식별자 종류 | 대표성 여부/ 생성 여부/ 속성의 수/ 대체 여부에 따라 식별자를 분류함

• 대표성 여부에 따라 - 주식별자/ 보조식별자
• 생성 여부에 따라 - 내부식별자/ 외부식별자
• 속성의 수에 따라 - 단일식별자/ 복합식별자
• 대체 여부에 따라 - 본질식별자/ 인조식별자

대표성 여부	생성 여부	속성의 수	대체 여부
주 식별자 - 유일성, 최소성 만족 - 엔터티를 대표함 - 다른 엔터티와 참조 관계로   연결될 수 있음	내부 식별자 - 엔터티 내부에서   스스로 생성됨 - (ex) 부서코드, 주문번호 등	단일 식별자 - 1개 속성으로 구성됨 - (ex) 고객 엔터티에서 회원ID	본질 식별자 - 비즈니스 프로세스에서   생성됨
보조 식별자 - 유일성, 최소성 만족 - 대표성 만족 X	외부 식별자 - 다른 엔터티와의   관계로인해 생성됨	복합 식별자 - 2개 이상의 속성으로 구성됨	인조 식별자 - 유일한 값을 만들기 위해   인위적으로 생성 - 최대한 범용적인 값을 사용

 

---

 

참고도서: SQL 개발자 이론서+기출문제_이기적, 2020