[데이터 아키텍처 준전문가(DAsP)] 과목 4. 데이터 모델링 (3) 논리 데이터 모델링

1. 논리 데이터 모델링 이해

1) 논리 데이터 모델링

항목	상세 내용
논리 데이터 모델링 정의	• 데이터베이스 설계 프로세스 기초 설계 단계 • 비즈니스 정보의 구조와 규칙을 표현할 수 있는 기법 • ERD로 표현된 개념적 구조를 데이터베이스에 저장할 형태로 표현한 논리적 구조 • 물리적인 스키마 설계 전 단계
논리 데이터 모델의 구성요소	• 엔터티 • 관계 (연관도 및 관계 수) • 슈퍼타입 및 서브타입 • 속성 및 도메인 • 주요키, 후보키, 대체키, 외래키 • 업무 규칙
논리 데이터 모델링 이해	• 개념 데이터 모델링에서 정의한 핵심 엔터티와 관계를 바탕으로 속성을 정의하고 식별자를 확정하는 과정 • 정규화를 통해 새로운 엔터티가 생성되거나 새로운 관계 생성 • M:N 관계들이 해소되면서 새로운 행위 엔터티가 생성되는 과정 • 사용자 IP 주소, ViewCount 같은 시스템 관리 관점에서 필요한 데이터 속성까지 모델링에 반영 • 논리 데이터 모델링 단계에서는 실제 사용할 DBMS 시스템 유형을 고려하지 않음
논리 데이터 모델링 목적 및 효과	• 비즈니스에 대한 데이터 관점에서의 이해를 도움 • 전사적인 통합 데이터 체계 확립 • 데이터의 일관성 및 정확성 유지를 위한 규칙 도출 • 안정적인 데이터베이스 설계의 토대 마련 • 사용자와의 명확한 의사소통을 위한 수단으로 활용 가능
논리 데이터 모델링의 성공 요인	• 현업 사용자와 함께 데이터 모델링 진행 • 절차보다는 데이터에 초점을 두고 모델링 진행 • 데이터의 구조와 무결성을 함께 고려 • 개념화, 정규화 기법 채택으로 데이터 무결성 확보 • 다이어그램을 이용하여 업무 표현 • 데이터 모델링을 지원하는 데이터 사전 구축

 

 

2) 데이터 정규화

• RDBMS에서 데이터의 보존성을 높이고 중복성을 줄여 저장공간의 최소화와 조회 속도 향상하기 위한 테이블을 구성하는 과정
• 1~5단계의 정규화 과정과 반정규화 과정이 있음
• 복잡합 자료 구조가 아니라면 제3정규화 과정까지 진행
• 정규화 과정을 통해 도출된 엔터티의 속성들의 기본 데이터 유형들을 지정
• 정규화된 설계 이점
  • 기억 장소 크기의 최소화
  • 데이터 불일치 위험 최소화
  • 수정 및 삭제로 인한 이상 가능성 최소화
  • 데이터 구조의 안정성 최대화

 

✔️ 데이터 정규화 단계

단계	내용
1NF (제1정규형)	• 릴레이션에 속한 모든 도메인이 원자값만으로 되어 있는 릴레이션 • 릴레이션의 모든 속성이 단순 영역에서 정의
2NF (제2정규형)	• 릴레이션이 1NF • 키가 아닌 모든 속성이 기본키에 대해 함수적 종속 관계를 만족
3NF (제3정규형)	• 릴레이션이 2NF • 키가 아닌 모든 속성이 키본키에 대해 이행적 종속 관계를 이루지 않도록 제한
BCNF (Boyce-Codd 정규형)	• 릴레이션에서 결정자가 모두 후보키인 릴레이션
4NF (제4정규형)	• 릴레이션이 2NF • 키가 아닌 모든 속성이 키본키에 대해 이행적 종속 관계를 이루지 않도록 제한
5NF (제5정규형)	• 릴레이션이 모든 조인 종속성의 만족이 릴레이션의 후보키를 통해서만 만족

 

 

✔️ 데이터 정규화 유형

항목	내용
제1정규화	• 속성 원자값 원칙, 중복성 제거 원칙, PK 설정 원칙 준수 • 모든 엔터티는 Unique Key이자, PK가 존재해야 함 • 모든 속성 값은 원자성, 즉 단일값 형태로 데이터 형태가 표현되어야 하며 중복되면 안 됨 • 값이 중복되는 2개 이상의 속성은 별도 엔터티로 분리
제2정규화	• 부분적 함수의 종속성 제거 원칙 준수 • 기본키가 2개 이상으로 구성된 엔터티에서 일반 속성이 PK속성 중 일부 속성에 대해서만 부분적 종속성이 있는 속성일 경우 제거 • 2차 정규화의 결과로 속성이 삭제될 수 있음
제3정규화	• 이행적 함수의 종속성 제거 원칙 준수 • 엔터티 내 모든 속성들은 기본키에 의존성을 가져야 함 • 기본키에 의존하지 않고 일반 속성에 의존하는 속성을 제거 및 분리

 

 

제1정규화	제2정규화	제3정규화

 

 

2. 속성 정의

1) 속성

항목	상세 내용
속성 정의	• 더 이상 분리될 수 없는 최소 데이터 보관 단위 • 릴레이션의 열 • 파일 관리 시스템 관점 : 필드(field)에 대응 • 엔터티에서 관리되는 구체적인 정보 항목 • 엔터티와 같이 업무 내용, 다양한 문서를 통해 도출됨 • 먼저 후보들을 도출하고 속성이 될 수 있는 조건에 부합하는지 확인하여 최종적으로 속성 정의
속성 특징	• 일종의 집합 • 릴레이션도 속성 (물리 데이터 모델링 단계에서 보면 관계 또한 속성) • 속성 간 서로 독립적 (제2정규형 : 속성은 반드시 식별자에 직접 종속되어야 함) • 업무에 필요한 정보 • 1개의 속성값만 가지며, 다중값일 경우 별도 엔터티를 이용하여 분리
엔터티, 인스턴스, 속성, 속성값의 관계	• 1개의 엔터티는 2개 이상의 인스턴스 집합 • 1개의 엔터티는 2개 이상의 속성을 가짐 (식별자 외 1개 이상 필요) • 1개의 속성은 1개의 속성값을 가짐
업무 규칙	속성이 가질 수 있는 값을 통제하여 논리적 데이터 모델의 무결성을 유지하기 위한 명세 • 키 업무 규칙 : 엔터티의 주키와 외래키의 값을 정확하게 유지하기 위한 업무 규칙 → 주엔터티의 삭제 규칙과 종엔터티의 입력 규칙 정의 • 속성 업무 규칙 : 엔터티 속성이 갖는 값의 타입, 범위, 특성 등 정의 • 연쇄반응 : 입력, 수정, 삭제, 조회 작업의 정당성과 이 작업이 다른 엔터티 또는 동일 엔터티의 속성값에 미치는 영향 규정

 

 

✔️ 속성 분류

구분	명칭	설명
특성	기본속성	• 업무로부터 추출한 값 • ex. 이름, 성별, 이메일주소
	설계속성	• 규칙화를 위해 변형/새로 정의한 값 • ex. 과목코드, 지역코드
	파생 속성	• 다른 속성에 영향을 받아 발생한 값 • ex. 예금이자, 평균성적
엔터티 구성 방식	PK (Primary Key)	엔터티를 식별할 수 있는 속성
	FK (Foreign Key)	다른 엔터티와의 관계에서 포함된 속성
	일반속성	PK, FK에 포함되지 않은 속성
	단순형	원자값 속성
	복합형	세부 속성으로 나뉠 수 있는 속성

 

 

2) 속성 후보 도출

항목	상세 내용
속성 후보 수집처	• 구 시스템 문서 자료 • 현업 장표/보고서 • 사용자와 협의 • DFD (데이터 흐름도)의 DD (Data Dictionary) • 전문서적 및 자료 • 다른 시스템 자료
속성 후보 선정 원칙	• 원시(Source) 속성으로 보이는 후보는 버리지 않음 • 소그룹별로 후보 군을 만들고 가장 근접한 엔터티에 할당
속성의 기본 구성 요소	• 속성명 : 함축성 있는 명사(구), 업무에서 일반적으로 사용하는 용어 • 도메인 : 업무적인 제약 조건으로 파악된 특성 (데이터 타입, 길이, 허용값, 디폴트값, 알고리즘) • 선택성 : 반드시 값을 가져야 하는지 여부 (필수조건/금지조건/무관계조건)

 

 

3) 속성 검증 및 확정

항목	검증 방법	대표 유형
최소 단위 분할	• 집합 개념의 속성은 단순 개념으로 분할 • 가능한 최소 단위까지 분할한 후 관리 필요에 따라 통합 • 분할 및 통합 기준은 업무의 요구사항에 따름 • 일자, 시간, 성명, 주민등록번호, 우편번호 등은 일반적으로 분할하지 않는 것이 좋음	• 일자 형태의 속성 : 매출일자 • 외부에서 공인된 속성 : 우편번호 유형 • 전화번호 유형 : 전화, 팩스 번호 • 주소 유형 : 고객 주소 → 지역주소+상세주소
하나의 값만을 가지는지 검증 필요	• 여러 값을 가지거나 반복되는 속성은 잘못된 속성 • 반복되는 속성은 새로운 엔터티로 분할해야 할 1차 정규화 대상	• 계약일 : 고객 엔터티 속성 (x) 가입 계약 속성 (o) → 고객은 여러 개의 계약일을 가질 수 있기 때문 • 차량번호 : 유일 값
추출 속성에 따른 검증		• 현재 정보만 관리 : 현주소, 고객 등급 • 최초 정보만 보관 : 최초가입일, 모집사원 • 집계 정보만 관리 : 인원수, 가족수 • 추출 릴레이션만 관리 : 가입 계약번호, 관리 사원 • 대표 정보만 관리 : 대표 이메일ID, 법인 대표자 정보 • 다른 속성의 일부 정보만 분리 : 성별, 결혼 여부 • 일부분만 추출 값 : 인원수, 법인 대표자 정보

 

 

4) 가공 속성 규칙

• 모델 내 반드시 기술 권장
• 도출 속성 : 하나 이상의 속성 값을 누적함으로써 선택적으로 주제를 도출하는 속성에 대해 값을 창출하기 위해 추가 계산 작업을 수행함으로서 도출되는 속성
  • 경영층이 원하고 필요로 하는 정보를 대표함
  • 사용자들의 데이터 요구 사항을 나타냄
  • 향후 과정에서 PK로서의 역할을 맡아서는 안 됨
  • 데이터 모델에 도출 속성을 포함시키는 것은 물리적 구현에 대한 것을 내포하지 않음
• 계산 속성 : 엔터티의 단일 사례에 대한 특성을 기술하며, 일반적으로 관련 속성의 또 다른 단일 사례로부터 계산

 

5) 속성 정의 시 유의사항

사항	상세 내용
명확한 속성 명칭 사용	• 직업 : 상위 분류 단위인지, 세부 분류 단위인지 정의 • 학점 : A/B인지, 2학점/3학점인지 정의
유일한 복합명사 사용	• 순번 : 인조식별자로 사용 • 상태 : 애매모호함 • 보험기간 : 12개월, 1년으로 표현되는지 • 최초납입영수일자 : 잘 표현됨
단수형 사용
표준 단어 제정	모델링 전 표준 단어를 제정하면 기준을 준수하기가 용이하고 일관성 생김
자의적인 전용 금지	속성의 의미를 추상적으로 정의했을 때, 개발 막바지에 속성 추가가 필요할 때, ERP 패키지의 경우 미리 전용의 용도로 속성을 정의해두는 경우 발생

 

 

6) 속성 업무 규칙 정의

도메인 정의	내용
속성	• 자료 형태 : Integer, Decimal, Character • 길이 : 5 Digits, 35 Characters • 포맷 : nnn-nn-nnnn (ex. 전화번호) • 값의 허용 범위 : 0 < x < 50 • 의미 : 구매 주문서의 주문 가격 • 유일성 : Unique, Nonunique • Null 값 허용 여부 • Default 값
주키 (기본키)	• 유일한 값 • 합성 주키를 이루는 속성은 Not Unique 가능 • 주키와 주키를 이루는 속성은 반드시 Not Null • 주키와 주키를 이루는 속성은 유일성이 지켜지는 한 Default 값 가능 • 서브타입 주키의 도메인은 관련 슈퍼타입 주키 도메인의 부분집합으로 정의
대체키	• 유일한 값 • 합성 대체키를 이루는 속성은 Not Unique 가능 • 대체키와 합성 대체키를 이루는 속성은 Null값 가능
외래키	• 외래키 속성의 자료 형태, 길이, 포맷은 해당 주 엔티티의 주키 속성의 도메인과 동일

 

 

3. 엔터티 상세화

1) 식별자 확정

✔️엔터티 구체화 4단계

단계	상세 내용
식별자 확정 단계	논리적 의미의 식별자 → 실질적 식별자 생성
정규화 단계	논리적 데이터 모델의 일관성을 유지하고 중복을 제거하여 안정적인 모델을 만드는 단계
M:N 관계 해소 단계	핵심 엔티티 간의 M:N 단계가 해소되면서 교차 엔터티가 생성되는 단계
참조 무결성 정의 단계

 

 

✔️ 식별자 확정 단계

항목	상세 내용
본질 식별자	• 키 엔터티는 부모가 없이 창조된 집합으로 식별자를 만들어야 함 • 행위 엔터티는 항상 부모가 누구인지 확인하는 방식으로 진행 • 키 엔터티의 본질 식별자 : (사원 엔터티) 주민등록번호 / 인조 식별자 : 사원번호 • 절대 종속 : 부모 엔터티가 반드시 있어야만 존재하는 것 • 상대 종속 : 엔터티의 탄생에 아무런 영향을 미치지 않음 • 직접 종속 : 부모 엔터티와의 관계가 1촌 • 간접 종속 : 부모 엔터티와의 관계가 1촌이 아닌 경우 • 행위 엔터티의 본질 식별자 : 절대 종속 & 직접 종속 • 절대 종속 관계, 상대 종속 관계 모두 1:M 직접 관계이면 상위 엔터티의 식별자가 하위 엔터티에 상속됨
후보 식별자 도출	• 각 인스턴스를 유일하게 식별할 수 있어야 함 • 나머지 속성을 직접 식별할 수 있어야 하며, NULL이 될 수 없음 • 후보 식별자로 속성 집합을 선택하는 경우, 개념적으로 유일해야 함 • 후보 식별자의 데이터는 자주 변경되지 않는 것이어야 함
대체(보조) 식별자	• 식별자를 대신할 수 있는 속성 또는 관계 • ex) 사원번호, 주민번호 등
인조 식별자 지정	• 최대한 범용적인 값 사용 (ex. 사원번호, 상품코드 등) • 유일한 값을 만들기 위한 인조 식별자 사용 • 하나의 인조 식별자 속성으로 대체할 수 없는 형태 주의 • 편의성/단순성 확보를 위한 인조 식별자 사용 (속성명이 너무 길 때) • 의미의 체계화를 위한 인조 식별자를 사용할 수 있음 (코드화) • 내부적으로만 사용하는 인조 식별자 (시스템 필요성에 의해)
식별자 확정	[UID BAR 의미] • 식별자로서의 역할 : 구별될 수 있도록 유일한 값을 만드는 데 도움 • 정보로서의 역할 : 참조하는 엔터티의 입장에서 상속 받았기 때문에 자신의 정보도 증가함 [UID 상속과 단절 원리] • 실질적인 처리 단순화를 가져다 줄 수 있음 [식별자 확정 절차] 1) 키 엔터티 식별자 확정 : 최상위 엔터티, 서로 독립적으로 식별자를 확정할 수 있음 2) 메인 엔터티 식별자 확정 : 하위 엔터티 상황을 고려하여 결정, 식별자 속성을 적게 함 3) 하위 엔터티 식별자 확정 : 인조 속성을 적게 사용, 유일성에는 좋지만 정보로서 가치 없음

 

 

2) 정규화

항목	상세 내용
정규화의 의미	• 변경 이상이 발생하면 데이터의 일관성과 무결성을 해칠 수 있음 • 입력 이상 : 별도의 사실이 발생하기 전까지 데이터를 삽입할 수 없음 • 삭제 이상 : 일부 정보를 삭제함으로써 유지되어야 할 정보까지 삭제될 수 있음 • 갱신 이상 : 일부 갱신함으로써 정보의 이상현상 (무결성 파괴, 정보의 모순성)이 발생할 수 있음
정규화의 장점	• 중복 값이 줄어듦 • NULL 값이 줄어듦 • 복잡한 코드로 데이터 모델을 보완할 필요 없음 • 새로운 요구 사항의 발견 과정을 도움 • 업무 규칙의 정밀한 포착 보증 • 데이터 구조의 안정성 최대화

 

✔️ 정규화 단계

항목	정의	정규화 작업
1차 정규형 (1NF)	• 모든 속성은 반드시 하나의 값을 가져야 함 (중복 x) • 각 속성의 모든 값은 동일한 형식이어야 함 • 각 속성은 유일한 이름을 가져야 함 • 레코드 간 식별이 가능해야 함	• 의미상의 주어(본질 식별자)를 알아야 식별자 부분 종속인지 구분할 수 있음 • 속성의 의미가 명확해야 종속성을 비교할 수 있음 • 속성 식별자 전체에 종속되어 있지 않으면 잘못된 위치이며, 새로운 엔터티 (부모 엔터티)를 생성하고 UID BAR를 상속받게 됨 • 1차 정규화를 수행하면 보통 자식 엔터티가 생김
2차 정규형 (2NF)	• 식별자가 아닌 모든 속성은 식별자 전체 속성에 완전 종속되어야 함	• 키가 복합 속성일 때, 일부 속성이 일부 키에 종속이 발생하는 것 • 2차 정규화를 수행하면 보통 부모 엔터티가 생김
3차 정규형 (3NF)	• 2차 정규형을 만족하고, 식별자를 제외한 나머지 속성들 간의 종속이 존재하면 안됨	• 평가코드, 평가 내역 속성이 서로 간 종속적임
BCNF 정규형	• BCNF : Boyce-Codd Normal Form • 모든 결정자가 키인 릴레이션 • 결정자 하나라도 키가 아니면 안됨 • 2, 3차 정규형을 보완하려는 목적 • 부분 종속이나 이행종속이 없는 3차 정규형도 변경이상 현상이 발견할 수 있음 (이는 Non-Key 속성이 결정자로 동작하기 때문)	[3차 정규화 문제점] • 한 릴레이션에 여러 개의 후보키가 있음 • 후보키가 적어도 둘 이상의 속성으로 이루어진 복합키 • 모든 후보키가 적어도 하나 이상의 공통 속성이 포함되는 경우 [3차 정규형을 만족하고 BCNF가 아닌 경우] • 각 속성이 하나의 값으로 구성된 경우 (1NF) • Non-Key 속성인 D는 후보키 A+B, B+C에 완전 함수 종속 (2NF) • Non-Key 속성이 D 하나뿐이므로 Non-Key 간 종속 관계 없음 (3NF)

 

1차 정규형	2차 정규형	3차 정규형

 

 

3) M:N 관계 해소

• 최종적인 단계에서 존재할 수 없음
• M:N 관계 해소 의의
  • 새로운 릴레이션 엔터티를 추가하여 1:M 관계로 변경
  • 연관 실체 엔터티는 M:N 관계 미결 시 간과한 추가 업무 규칙, 논리 내포 가능
  • M:N 관계는 데이터 종속성에 대한 결정을 어렵게 하며, 논리적 완성과 부분 집합 식별 능력 제한

4) 참조 무결성 규칙 정의

• 관계 테이블의 모든 외부 식별자 값은 관련 있는 관계 테이블의 주 식별자 값이 존재해야 함
• PK와 마찬가지로 FK도 데이터 무결성에 대한 업무 규칙 내포
• DB 설계 관점에서 선택하지 말고, 사용자 업무 규칙에 따라 적절한 규칙 선택

입력 규칙
Dependent	대응되는 부모 실체에 인스턴스가 있을 경우에만 자식 실체에 입력을 허용
Automatic	자식 실체 인스턴스의 입력을 항상 허용하고 대응 부모 건이 없을 경우 이를 자동 생성
Nullify	자식 실체는 항상 허용하고 대응되는 부모 건이 없는 경우 자식 실체의 참조키를 Null값으로 처리
Default	자식 실체 인스턴스의 입력을 항상 허용하고 대응 부모 건이 없을 경우 FK를 지정된 기본값으로 처리
Customized	특정한 검증 조건이 만족될 때에만 자식 실체 인스턴스의 입력을 허용
No Effect	조건 없이 자식 실체 인스턴스의 입력 허용
삭제 규칙
Restrict	대응되는 자식 실체의 인스턴스가 없을 경우에만 부모 실체 삭제 허용
Cascade	부모 실체 인스턴스의 삭제를 항상 허용하고, 대응되는 자식 실체의 인스턴스를 자동 삭제
Nullify	부모 실체 인스턴스의 삭제를 항상 허용하고, 대응되는 자식 실체의 인스턴스가 존재하면 그것의 FK를 Null값으로 수정
Default	부모 실체 인스턴스의 삭제를 항상 허용하고, 대응되는 자식 실체의 인스턴스가 존재하면 그것의 FK를 기본 값으로 수정
Customized	특정한 검증 조건이 만족될 때에만 부모 실체 인스턴스의 삭제를 허용
No Effect	조건 없이 부모 실체 인스턴스의 삭제 허용

 

 

4. 이력 관리 정의

1) 이력 관리 정의

• 모든 데이터를 대상으로 하지 않음
• 꼭 필요한 데이터에 한정하여 이력 관리 수행
• 시점 이력과 선분 이력 중 적합한 형태를 결정하는 것이 중요

2) 이력 관리 대상 선정

• 사용자 조사
  • 변경 내역을 감시할 필요가 있는가?
  • 시간의 경과에 따라 데이터 또는 관계가 변할 수 있는가?
  • 과거의 데이터를 조회할 필요가 있는가?
  • 과거 버전을 보관할 필요가 있는가?
• 이력 데이터의 종류

  유형	상세 내용
  발생 이력 데이터	• 발생할 때마다 이력 정보 남김 • 이벤트 발생 시 / 날마다 남기는 것이 있음
  변경 이력 데이터	• 변경될 때마다 전/후 차이를 확인해야 할 경우
  진행 이력 데이터	• 진행에 따라 남기는 것 (ex) 주문

 

• 이력 관리 형태

  유형	상세 내용
  시점 이력	• 변경이 발생한 시각만 관리 • 특정한 시점의 데이터 추출할 경우, 불필요한 작업 수행
  선분 이력	• 변경 시작부터 종료 시점까지 관리 • 하나의 지점은 =로 찾을 수 없으니 통과하는 선분을 찾을 수 있음 • 선분이 아무리 길어도 레코드는 하나임

 

• 선분 이력 관리 유형

  유형	상세 내용
  인스턴스 레벨 이력 관리	• 하나의 인스턴스에 변경이 발생하면 전체 행(인스턴스)을 새롭게 생성 • 한 번의 액세스로 해당 시점의 모든 데이터 참조 가능 • 로그성 데이터가 목적일 때 좋음 • 다른 이력 관리 유형에 비해 저장은 쉽지만, 저장 공간의 낭비 발생 • 하나 이상의 컬럼에 변경이 있을 경우, 이벤트가 모호해짐 (이벤트가 자식 정보를 갖게 된다면 해당 이벤트를 찾기 어려움) • 실제 변경 데이터를 찾기 위해서 과거의 데이터와 비교해야 함 • 특정 순간의 스냅샷만 보는게 아니라면 처리가 복잡해지는 경향이 있음 • 변화가 빈번하게 발생하는 상황에서 고려해볼 수 있는 유형
  속성 레벨 이력 관리	• 대상 속성에 변화가 생길 때만 이력을 생성하는 방식 • 실제 어떤 데이터가 변경되었는지가 분명함 • 하나의 이력 관리 엔터티에서 다른 엔터티와 통합 이력 관리가 가능함 • 독립적 처리 가능 • 변화가 자주 발생하지 않고 이력 관리 대상이 많은 경우 사용 • 특정 속성들에 변화가 집중되는 경우 유용함 • 여러 속성에 대한 이력 필요 시, 많은 Merge가 발생함 • 다른 유형에 비해 액세스 쿼리에서 조건 검색이 어려움
  주제 레벨 이력 관리	• 유사하거나 연동될 확률이 높은 것별로 레벨 이력 관리 • 인스턴스, 속성 레벨의 장점을 합친 형태 • 목적이 분명한 엔터티를 생성함으로써 확장성을 확보할 수 있는 용도로 사용할 수 있음 • 변경 부분만 처리 가능 (독립적) • 다른 엔터티와 통합 이력 관리 가능 • 속성 레벨의 단점 해소 가능 • 전체를 참조할 때 인스턴스 레벨에 비해 Merge가 발생하는 문제가 있음 • 부분에 따라 변경 정도의 차이가 심한 경우 유리함

 

3) 선분 이력 관리용 식별자 확정

항목	상세 내용
선분 이력에서 식별자 결정 시 고려사항	• 성능 문제 고려 • 실제 데이터는 Unique 하지만 의미적으로 Unique 하지 않는 일이 발생 • Unique 여부를 검증할 수 있는 조치를 병행해야 함
선분 이력에서 종료점 처리 시 주의사항	• 종료점이 미정이므로 NULL     • 논리적으로 타당하지만 비교가 불가능하여 인덱스를 사용하지 못하므로 수행 속도가 저하됨 • 수렴하므로 최대치 부여     • 아직 종료되지 않았으므로 무한히 계속되는 것으로 간주     • 최대치를 부여하고 가능한 테이블 생성 시 Default constraint를 부여하며 수행 속도에 유리

 

✔️ 선분 이력을 하기 좋은 항목

• 매일, 매주 등 불규칙하게 바뀌는 상품 가격

---

 

📌 참고 포스팅 📌

[데이터 모델링] 3. 논리적 데이터 모델링

 

[데이터 모델링] 4. 데이터 정규화 (Normalization)