[핵심 데이터 모델링] - 데이터 모델링이란?

soon·2023년 3월 13일

데이터 모델링이란?

📌 현실에 있는것 → 프로그래밍화 시키는 과정

데이터 시스템 구조를 사람이 이해할 수 있게 형상화 하는 과정.
사람이 정보로 의미있는 대상을 식별(개념적) ➡️ 기호 등을 통해 추상화하여 표현(논리적) ➡️ DB구축을 위해 구체화(물리적)
why? 현업 인터뷰, 업무 지침서 등 현행 업무를 파악하기 위해서 한다.

📌 데이터 모델의 종류

개체관계 모델(ER, Entity-Relationship Model)

관계 모델(Relational Model)

계층 모델(Hierarchical Model)

망 모델(network model)

📌 모델링 순서
개념 모델링 ➡️ 논리 모델링 ➡️ 물리 모델링

흔하게 보이는 영수증을 보게되면 생각보다 많은 정보들이 들어있다.
ex 매장명, 주소, 전화번호, 주문 상품 수량, 금액, 카드사, 카드번호 등등…

영수증의 데이터에서 관리해야할 데이터를 식별하고 모형화하여 하나의 엔티티와 속성들로 표현할 수 있다.
이러한 과정을 개념 모델링이라고도 부른다. 개념 모델링은 개념을 파악하고 업무를 파악하는 용도로 사용된다.

논리 모델링은 엔티티와 속성이 나누어진 개념 모델링을 업무에서 사용할 수 있게 체계화 하고 구체화하여 데이터 모델로 표현한다.

물리 모델링은 논리 모델링을 업무와 타협하는 단계이다.

ER모델 (Entity-Relationship Model)

ER모델은 표현하고자 하는 현실 세계의 업무를 개체와 관계라는 두 가지 개념으로 표현하는 모델이다.
ER표기법을 사용하여 표현한다.
ERD : ER에서 사용하는 실체와 관계를 도식화한 것, 이를 알기 쉽게 도형으로 표현한다.

ER모델의 질적 특성

완전성(Completeness) : ER모델은 현실 세계의 모든 업무적인 요구사항을 표현하고 있어야 한다.
정확성(Correctness) : ER모델의 개념대로 데이터 모델을 작성해야 한다. 요구사항 확인을 잘해야 한다.
최소성(Minimality) : 요구사항의 모든 특성이 ER모델에 한번만 나타나도록 설계해야 한다. 중복이 없어야 한다.
자명성(Self-explanation) : 요구사항을 쉽게 반영할 수 있도록 유연한 모델을 설계해야한다.

ER모델 구성요소

📌 엔티티, 관계, 속성, 식별자

엔티티(Entity) 클래스와 비슷함
관계(Relationship)
속성(Attribute) iv와 비슷함
식별자(Identifier)

엔티티(Entity)

엔티티는 고객, 상품, 직원, 조직, 서비스, 직업처럼 개념적인 것이다. 객체지향개념의 클래스와 비슷하다.
엔티티는 반드시 각 인스턴스를 식별할 수 있는 속성이나 관계가 하나 이상 정의되어야 한다.

슈퍼타입, 서브타입 엔티티로 확장 가능하다.
ex 고객 (슈퍼타입), 개인 고객, 법인 고객 (서브타입)
Java로 예를 들면 서브타입은 슈퍼타입을 상속받았다.

엔티티의 일반화
여러개의 엔티티를 공통의 성격으로 묶어 하나의 엔티티로 재정의한다.
두개의 하위수준 엔티티를 합쳐 하나의 상위수준으로 바꾸는 상향식 접근방식

ex 개인고객, 법인고객 ➡️ 고객으로 합침 - join을 하지않아 개발 생산성 증대,
but 속성의 의미가 불분명해 데이터 무결성 문제가 발생 할 수 있음
↘️ 데이터 무결성 문제 : 잘못된 데이터가 들어올 수 있음

💡DB제약조건 무결성 : PK, FK, Not Null 등등.. (잘못된 데이터가 들어오지 않게하기 위함)

엔티티의 특수화
일반화의 반대 개념으로, 하나의 상위수준 엔티티를 둘로 쪼개 두개의 하위수준 엔티티로 나누는 하향식 접근방식
엔티티의 집단화
여러 엔티티가 하나의 엔티티로 취급하는 경우
ex 고객과 상품간의 관계를 단일 엔티티(주문상품)으로 재정의 해 배송과 관계를 맺는다.
엔티티의 다양한 분류
관계에 따른 분류
- 강한 엔티티 : 독립적으로 존재하며, 엔티티 내에서 고유하게 인스턴스를 식별할 수 있다. 고객, 상품 등
- 약한 엔티티 : 다른 엔티티에 종속적이며, 자체 식별자를 가질 수 없고, 다른 엔티티의 식별자를 상속받아 사용한다. 주문상품은 주문에서 주문번호를 상속받아 식별자로 사용

형태에 따른 분류
- 독립 엔티티 : 사람, 물건, 장소, 개념처럼 원래부터 현실에 존재하는 엔티티 고객, 상품, 창고, 조직
- 업무중심 엔티티 : 업무를 처리하면서 발생하는 데이터 주문, 결제, 배송, 청구
- 종속 엔티티 : 업무중심 엔티티에서 1차 정규화로 분리된 엔티티 주문상품, 주문배송
- 교차 엔티티 : 엔티티 간에 발생하는 트랜잭션에 의해 성성된 엔티티

생성 관점에 따른 분류
- 핵심 엔티티 : 고객, 상품, 조직처럼 부모 엔티티가 없는 독립적인 엔티티
- 중요 엔티티 : 핵심 엔티티간의 거래 관계에 의해 생성되는 엔티티, 업무에 핵심이 되는 엔티티
  계약은 고객과 상품의 거래 관계에 의해 생성되며, 고객과 상품을 부모로 갖는다.
- 행위 엔티티 : 실제 업무 행위에 의해 지속해서 발생하는 거래 행위에 대한 엔티티

유무형에 따른 분류
- 실체 엔티티 : 고객, 상품과 같이 눈으로 볼 수 있는 물리적인 형태를 가지는 엔티티
- 비실체 엔티티
  - 개념 엔티티 : 조직, 보험상품, 서비스 등 형태는 없지만 개념적으로 존재하는 엔티티
  - 사건 엔티티 : 계약, 주문, 결제 등 업무 행위와 관련된 엔티티

📌 ER 모델의 구성요소

엔티티

관계 - 관계수, 선택성, 식별성, 관계명

속성

관계(Relationship)

엔티티와 엔티티 간에 존재하는 업무 규칙을 정의하고 엔티티 간에 어떤 관계가 이루어질 수 있는지 표현한다.

구성요소

관계수(cardinality)
선택성(optionality)
식별성(Identifier Inheritance)
관계명

관계수 (Cardinality)

엔티티간의 대응되는 최대 인스턴스 수
상대 엔티티 쪽에 까마귀 발 (Crow’s Foot)로 표시한다.
반드시 양쪽다 서로의 관계를 확인해야함

1 : 1
: 엔티티 하나가 다른 엔티티 하나와 관계를 가지는 경우다.
ex 직원과 인턴과정,
중요한 문서가 있을 때, 테이블을 쪼개 보여줄 수 있는 부분과 보안상 가려야하는 부분 1 : 1로 join해서 관계를 맺는다.
1 : M
: 엔티티 하나가 다른 엔티티 여러 개와 관계
ex 부서와 직원
M : N
: A엔티티가 B엔티티 개체 여러개와 관련있고, B엔티티 개체 하나는 A엔티티 개체 여러개와 관계가 있다. ex 학생과 수강과목

선택성 (Optionality)

필수냐 선택이냐 로 구분이 가능하다.
엔티티 인스턴스에 대한 상대 엔티티 인스턴스 존재 유무를 나타낸다.

필수 — 필수
: A 엔티티의 인스턴스에 대해 B 엔티티 인스턴스가 반드시 존재해야 하고,
B 엔티티의 인스턴스에 대해 A 엔티티의 인스턴스도 반드시 존재해야 한다.
ex상품을 선택하지 않고 주문을 하는 경우는 없으므로, 주문은 주문상품이 반드시 존재해야 한다.
필수 — 선택
: A 엔티티의 인스턴스에 대해 B 엔티티 인스턴스가 존재하지 않아도 되고,
B 엔티티 인스턴스에 대해 A 엔티티 인스턴스는 반드시 존재해야 한다.
ex주문하지 않은 고객은 있을 수 있으나, 모든 주문은 반드시 주문한 고객이 있어야 한다.
선택 — 선택
: A 엔티티 인스턴스에 대해 B 엔티티 인스턴스가 존재하지 않아도 되고,
B 엔티티 인스턴스에 대해 A엔티티 인스턴스도 존재하지 않아도 된다.
ex사원은 소개사원으로 등록된 계좌가 존재하지 않을 수 있고, 고객이 펀드상품에 가입할 때 소개 사원을 지정하지 않아도 되므로 계좌는 소개 사원이 존재하지 않을 수 있다.

식별자 상속 (Identifier Inheritance)

식별자 상속은 식별관계와 비식별 관계로 구분할 수 있다.

식별 관계는 참조되는 상위 엔티티 식별자가 참조하는 하위 엔티티 식별자로 상속되는 경우를 말한다.
ex) 고객주소의 고객번호(FK)가 주문 엔티티에서 고객번호(FK)로 상속된다.

비식별 관계는 식별자가 아닌 일반 속성으로 상속되는 관계를 말한다.
*️⃣ 다른 테이블의 PK이자 내 테이블의 FK, FK인 동시에 PK인것

📌 ER 모델의 구성요소

엔티티

관계 - 관계수, 선택성, 식별성, 관계명

속성

속성

데이터를 표현하는 가장 작은 단위, 하나의 엔티티는 두개 이상의 속성을 가진다.

속성명 : 실체의 특성을 규정하는 속성 명칭
식별자 여부 : 해당 속성이 엔티티 식별자에 해당하는지 표시
옵셔널리티 : 엔티티에 인스턴스가 발생할 때 값을 가져야 하는지에 대한 구분.
도메인 : 속성이 허용하는 데이터 형식과 범위를 가지고 있다.

식별자

엔티티에서 인스턴스를 개별적으로 식별할 수 있는 속성들이다.

특징 : 유일성, 최소성, 불변성, 존재성(Not null)

📌 관계형 데이터 모델 (RDB)

Key

제약조건

함수종속

정규화

관계형 데이터 모델이론

데이터를 2차원 테이블(표) 형식으로 정의하고 표현한 모델이다.
테이블 == 릴레이션
릴레이션은 스키마헤더 와 실제 값은 인스턴스본문로 구성된다.
관계형데이터모델이론

스키마 : 구조
- 릴레이션명
  - 표를 구성하는 각 열을 의미
- Attribute
  - 더는 쪼갤 수 없는 원자 값
  - 값이 서로 다르며 유일해야 함
인스턴스 : 실제 값
- Tuples
  - 릴레이션의 각 행
  - 중복된 튜플 허용 X
  - 값은 동일해도 OK

Key

슈퍼 키 (Super Key)

: 튜플을 고유하게 식별할 수 있는 속성 집합

릴레이션은 한 개 이상의 슈퍼 키를 가질 수 있음
슈퍼 키 값은 모든 튜플에서 유일해야 함
ex 사원번호 + 사원명 이 두개가 고유 값. 슈퍼키임

후보 키 (Candidate Key)

: 튜플을 고유하게 식별 할 수 있는 최소한의 속성 집합

모든 후보 키는 슈퍼 키지만, 모든 슈퍼 키가 후보 키는 아님 (슈퍼 키 가 후보 키 포함)

기본 키 (Primary Key)

: 하나 이상의 후보 키 중에서 선택된 단 한개의 키

유일성, 최소성을 가짐
NULL 값 불가능

대체 키 (Alternate Key)

: 후보 키 중에서 기본 키가 아닌 후보 키

외래 키 (Foreign Key)

: 어떤 릴레이션의 어트리뷰트 값이 → 다른 릴레이션에 속한 어트리뷰트의 기본 키를 참조하는 경우

NULL값 가능
중복된 튜플 OK

관계도

제약조건

📌 목적 : DB에 오염된 데이터가 들어오는걸 막기 위함

📌 PK, FK, Not Null, Unique, Domain <-외워

키 제약조건 (PK)
- 필드에 Unique와 Not Null 특징을 가짐
실체무결성 (Not Null)
- 필드에 NULL값을 저장할 수 없게 함
영역무결성 (Domain)
- 정의된 영역 내의 값만 받음
참조무결성 (FK)
- 외래키는 부모 릴레이션의 기본 키 값만 가능
Unique
- 중복값 X

함수종속

📌 관계형 DB설계 시, 정규화 과정에서 이 개념이 중요하게 사용된다.

ex “고객” 테이블이 { 고객번호, 고객명, 생년월일, 전화번호, 주소 } 속성을 가지고 있을 떄
고객번호 컬럼에 다른 컬럼들이 함수적으로 종속된다.
고객번호 → (고객명, 생년월일, 전화번호, 주소)

짧게 요약
테이블의 특정 컬럼 A의 값을 알게되면, 다른 컬럼 B의 값을 알 수 있을 때
컬럼 B는 A에 함수적 종속성이 있다.
고객번호를 알면 고객명을 알 수 있으며, “고객명은 고객번호에 함수적 종속성이 있다.”

정규화

📌 정규화 : 단계별로 테이블 쪼개기

중복을 없애기 위해 더 작은 단위의 테이블로 설계하는 과정

장점

데이터 입력, 수정, 삭제 과정에서 발생하는 이상 현상 최소화
데이터 구조 변경 시 유연성이 증가한다.
작은 단위로 세분화 할 경우 재활용성이 높아진다.
중복 최소화, 수행속도 향상

주의사항

: 성능의 저하가 심하면 어쩔 수 없이 다시 join한다. (역정규화)

제1정규형

: 중복되는 값이나, 중복열이 있을 경우 정규화 진행

같은 개념의 컬럼이 여러개, 다중 값을 가지는 경우 별도의 테이블로 분리함
엑셀에 데이터를 다 입력해서 중복값 찾아 정규화하기
분리된 테이블은 원 테이블의 기본키를 FK로 사용, 나머지 중 유일하게 식별 가능한 컬럼을 기본키로 추가.

제2정규형

: 제1정규형을 만족하고, 키가 아닌 어트리뷰트는 후보키 전체에 종속되어야 한다.

쉽게 “묶을 수 있는 걸 따로 묶어서 뺀다”

제3정규형

: 제2정규형을 만족하고, 키가 아닌 어트리뷰트들 간에는 서로 종속적인 관계가 없어야 한다.

키가 아닌 어트리뷰트가 다른 어트리뷰트에 포함되면 따로 테이블을 분리해야함

연결함정

: 정규화 과정에서 무손실 분해의 원칙이 지켜지지 않아,

원래 있던 관계성을 잃어 버리는 현상

부채꼴 함정
- 관계가 모호할 때가 있음
  
  ex
  회사에서 물품을 구매한 공급사를 관리하고, 여러 상품을 구매한다.
  각각, 관계를 표현했을 때 물품이 어느 공급사에서 구매한 것인지 알 수없는 현상이 발생
  
  해결방안
  회사 → 공급사, 공급사 → 물품 간의 관계 변환
균열 함정
- 일부 엔티티와 엔티티 사이의 관계가 존재하지 않을 때 발생
  
  ex
  공급사를 통하지 않고 직접 물품을 구매할 수는 없을까?
  
  해결방안
  이럴 경우 회사 → 물품 관계를 맺어줘야 함