모델링
현실 세계의 개념들을 추상화, 단순화, 명확화 한 것.
모델링의 특징
- 추상화 : 다양한 것을 일정한 형식에 맞춰 표현.
- 단순화 : 동일한 규약으로 이해하기 쉽도록 하는 것.
- 명확화 : 애매모호함을 제거, 정확하게 현상을 기술.
모델링의 세가지 관점
- 데이터 관점 : 업무와 데이터, 데이터간의 관계성
- 프로세스 관점 : 업무가 실제로, 무엇을 하는지
- 데이터와 프로세스의 상관관점 : 처리하는 일의 방법에 따라 데이터가 어떤 영향을 받고 있는지
-> 데이터베이스를 구축하기 위한 모델링은 데이터 관점을 중심으로 진행되기 때문에 이하 ‘모델링’을 지칭하는 것은 데이터 관점을 말하는 것.
모델링의 정의
- 정보시스템을 구축하기 위한 데이터관점의 업무 분석 기법
- 데이터에 대한 약속된 표기법에 의해 표현하는 과정
- 데이터베이스를 구축하기 위한 분석/설계의 과정
데이터 모델이 제공하는 기능
가시화, 명세화, 구조화된 틀, 문서화, 다양한 관점, 상세한 표현 방법
데이터 모델링의 중요성 및 유의점
- 파급효과
: 잘못된 데이터 모델링으로 인한 변경 작업으로 전체 시스템에 큰 영향을 미칠 수 있다는 것 - 복합한 정보 요구사항의 간결한 표현
: 간결한 데이터 모델링은 사용자들이 파악하기 쉽고 빠르다. - 데이터 품질
: 데이터 보관 기간 ↑ 가치 ↑ ( 활용을 많이 하게 되기 때문)
데이터 품질의 관한 중요성 및 유의점
- 중복 : 같은 정보를 저장하는 잘못 유의
- 비유연성 : 데이터의 작은 변화에 애플리케이션, DB에 큰 변화가 생길 가능성을 줄임(유지보수 가능성)
- 비일관성 : 데이터간의 상호 연관 관계에 대한 정확한 정의가 있어야 함. (신용 상태에 대한 갱신없이 고객의 납부 이력 정보를 갱신하는 것)
데이터 모델링의 3단계 진행
추상화 수준에 따라 개념적, 논리적, 물리적 데이터 모델링
개념적 데이터 모델링
추상화 수준이 높고 업무 중심적이며 포괄적인 수준의 모델링.
- 조직, 사용자의 요구사항 분석 -> 핵심 엔티티와 관계성을 반결 -> 엔티티 관계 다이어그램 생성.
- 시스템 기능에 대해 논의할 수 있는 기반을 형성하며 데이터 요구사항을 발견하는 것을 지원하는 단계.
논리적 데이터 모델링
업무의 구체적인 모습과 흐름에 따른 구체화된 업무 중심의 데이터 모델링.
- key, 속성, 관계 등을 정확하게 표현하며 재사용성↑
- 비즈니스 정보와 논리적인 구조와 규칙을 명확하게 표현
- 비즈니스 데이터에 존재하는 사실들을 인식, 기록함
- 신뢰성있는 데이터 구조를 얻기 위해 일관성을 확보, 중복 제거, 엔티티 속성 적절함을 고려한다.
- 식별자 확정, 정규화, m:m 관계 해소, 참조 무결성 규칙 정의 등으로 모델을 상세화 한다.
물리적 데이터 모델링
실제 DB의 저장구조에 따른 테이블 스페이스, 성능 등 물리적인 성격을 고려하여 설계.
- 물리적 스키마 : 데이터가 컴퓨터에 저장되는 방법 정의
- 테이블, 칼럼 등 물리적 저장 구조와 사용될 저장 장치, 자료를 추출하기 위해 사용될 접근 방법 사용.
데이터 독립성이 필요한 이유
- 유지 보수 비용 ↓
- 데이터 복잡도 ↓
- 데이터 중복 ↓
- 요구사항 대응 ↑
데이터 독립성 요소
외부 스키마 : 각 사용자 단계로 각 사용자가 보는 개인적 DB 스키마 (사용자 관점)
개념 스키마 : 모든 사용자 관점을 통합한 조직 전체의 DB를 기술하는 것.(통합 관점)
내부 스키마 : 물리적 장치에서 데이터가 실제적으로 저장되는 방법을 표현(물리적 저장구조)
두 영역의 데이터 독립성
논리적 독립성 : 개념 스키마 변경 -> 외부 스키마에 영향 X
물리적 독립성 : 내부 스키마 변경 -> 외부/개념 스키마 영향 X
Mapping(사상)
상호 독립적인 개념을 연결 시켜주는 다리.
외부/개념 사상(논리적 사상) : 외부적 뷰와 개념적 뷰의 상호 관련성 정의
개념/내부 사상(물리적 사상) : 개념적 뷰와 저장된 DB의 상호 관련성 정의
데이터모델링의 3가지 요소
어떤 것(Things, 엔티티), 성격(Attributes, 속성), 관계
💡 프로젝트에 참여하는 모두가 데이터 모델링을 알아야 함.
ERD(Entity Relationship Diagram)
업무분석에서 도출된 엔티티와 엔티티간의 관계를 이해하기 쉽게 도식화한 다이어그램.
데이터 흐름과 프로세스 와의 연관성을 이야기하는데 가장 중요한 표기법이자 산출물
ERD 작업순서
엔티티 그림 -> 엔티티 배치 -> 엔티티 관계 설정 -> 관계명 기술 -> 관계 참여도 기술 -> 관계 필수여부 기술
좋은 데이터 모델의 요소
1 완전성 : 필요로 하는 모든 데이터가 정의
2 중복배제 : DB 내에 동일한 사실은 한번만 기록
3 업무규칙 : 모든 규칙은 모든 사용자에게 공유
4 데이터 재사용 : 데이터 독립적으로 설계
5 의사소통 : 업무규칙들은 데이터 모델에 엔티티, 서브타입, 속성, 관계 등의 형태로 최대한 자세하게 표현
6 통합성 : 동일 데이터는 조직 전체에 한번만 정의 -> 다른 영역에서 참조, 활용.
엔티티
엔티티란 실체, 객체의 어떠한 개념을 가진 명사에 해당하며,
업무상 관리가 필요한 관심사, 저장 되기 위한 어떤 것을 말한다.
인스턴스의 집합으로서 그 집합에 속하는 개체들의 특성을 설명할 수 있는 속성(attribute)와 그들이 행하는 행위(Operation or Method)의 집합으로 정의할 수 있다.
엔티티는 자신으로부터 생성된 인스턴스들의 전체가 공유할 수 있는 공통 속성과 인스턴스 일부만 해당하는 개별 속성을 가진다.
엔티티의 특징
- 반드시 해당 업무에 필요하며, 관리하고자 하는 정보
- 유일한 식별자에 의해 식별이 가능해야 함
- 영속적으로 존재하는 인스턴스의 집합(2개 이상을 가짐)
- 업무 프로세스에 의해 이용되어야 함
- 반드시 속성을 가짐(관계 엔티티의 경우에는 주 식별자만 가져도 인정한다)
- 다른 엔티티와 최소 한 개 이상의 관계를 가진다( 통계성, 코드성, 시스템 처리 시 내부 필요에 의한 엔티티 도출은 예외)
엔티티의 분류
엔티티는 실체 유형, 발생되는 시점에 의해 분류
1. 유무형의 따른 분류
- 유형 : 물리적인 형태, 엔티티를 구분하기 용이(사원, 회사)
- 개념 : 개념적 정보 ( 조직, 보험 상품)
- 사건 : 업무를 수행함에 따라 발생되는 것(청구, 미납)
- 발생 시점에 따른 분류
- 기본 : 업무에 원래 존재하는 정보, 관계에 의해 생성되지 않고 독립적으로 생성, 타 엔티티의 부모역할을 하며 고유한 주식별자를 가진다. (사원, 회사)
- 중심 : 기본 엔티티로부터 발생, 업무의 중심. 다른 엔티티와의 관계를 통해 많은 행위 엔티티를 생성. (사고, 주문)
- 행위 : 두 개 이상의 부모엔티티로부터 발생, 자주 내용이 바뀌거나 데이터량이 증가.(주문 목록)
엔티티의 명명
- 업무에서 사용하는 용어일 것
- 약어를 사용하지 않을 것
- 단수명사를 사용할 것
- 고유성을 가질 것
- 생성 의미대로 이름을 부여할 것
속성
업무에서 필요로 하는 인스턴스로 관리하고자 하는 의미상 더 이상 분리되지 않는 최소의 데이터 단위.
인스턴들의 성격을 구체적으로 나타내는 정보.
- 한 개의 엔티티는 두 개 이상의 인스턴스 집합이어야 함.
- 한 개의 엔티티는 두 개 이상의 속성을 갖는다.
- 한 개의 속성은 한 개의 속성값을 갖는다.
속성의 특징
- 반드시 해당 업무에 필요하고 관리하고자 하는 정보
- 정규화 이론에 근간하여 정해진 주식별자의 함수적 종속성을 가져야 한다.
- 하나의 속성에는 한 개의 값만을 가진다. 하나의 속성에 여러 개의 값이 있는 다중 값일 경우 별도의 엔티티를 이용하여 분리한다.
속성의 분류
- 업무 분석을 통해 정의(일반적) : 기본 속성
- 설계하면서 도출해내는 속성 : 설계 속성 (식별번호)
- 다른 속성으로부터 계산이나 변형되어 생성 : 파생 속성
파생 속성
- 데이터 정합성을 유지하기 위해 유의해야 할 점이 많으며 가급적 파생속성을 적게 정의하는 것이 좋다.
- 업무로직이 속성 내부로 숨지 않도록 하는것이 좋다.
- 파생 속성의 원인이 되는 속성을 이용할 때에는 파생 속성도 함께 고려해야 한다.
엔티티 구성방식에 따른 분류
- PK(Primary Key) : 엔티티 식별 속성
- FK(Foreign Key) : 다른 엔티티와의 관계에 포함된 속성
- 일반 속성
속성은 세부 의미를 쪼갤 수 있느냐 없느냐에 따라 복합, 단순 속성으로도 구분할 수 있다.
도메인
각 속성이 가질 수 있는 값의 범위. 데이터 타입, 크기, 제약사항을 지정하는 것.
속성의 명명
- 해당 업무에서 사용하는 이름을 부여
- 서술식 속성명은 사용하지 않는다.
- 약어 사용은 가급적 제한한다
- 전체 데이터모델에서 유일성 확보
관계
상호 연관성. 엔티티의 인스턴스 사이의 논리적인 연관성으로서 존재의 형태, 행위로서 서로에게 연관성이 부여된상태. 관계 페어링의 집합을 논리적으로 표현한 것.
관계의 페어링
- 페어링 : 엔티티 안에 인스턴스가 개별적으로 관계를 가지는 것. 페어링의 집합을 관계로 표현한다.
- 관계 페어링 : 인스턴스들은 자신이 관련된 인스턴스들과 관계의 어커런스로 참여하는 형태.
- 관계의 표현 : 이항 관계, 삼항 관계, n항 관계
관계의 분류
어떤 목적(존재, 행위)으로 연결되었는지에 따라 관계를 분류.
- 존재에 의한 관계 : 사원은 부서에 항상 속해있다.
- 행위에 의한 관계 : 주문은 고객이 주문을 할 때 발생.
UML(Unified Modeling Language), 클래스 다이어그램의 관계 중 연관관계(Association)와 의존관계(Dependency)가 있다.
- 연관관계 : 항상 이용하는 관계, 존재적 관계에 해당.
(실선, 멤버변수로 선언하여 사용) - 의존관계 : 상대방 클래스의 행위에 의한 관계에 해당.
(점선, 행위(Method)의 파라미터)
ERD에서는 해당 관계를 구분하지 않고 표현하지만 UML의 클래스 다이어그램에서는 이것을 구분하여 표현한다.
관계의 표기법
- 관계명 : 관계의 이름, 관계에 참여하는 형태 지칭.
- 관계차수 : 1:1, 1:m, m:n
- 관계선택사양 : 필수관계, 선택관계
관계 체크사항
- 두 개의 엔티티 사이에 관심있는 연관규칙이 존재?
- 두 개의 엔티티 사이에 정보의 조합이 발생?
- 업무기술서, 장표에 관계연결에 대한 규칙 서술?
- 업무기술서, 장표에 관계연결을 가능하게 하는 동사 있?
식별자
엔티티의 인스턴스들을 각각 구분할 수 있는 논리적인 이름, 구분자이다.
💡식별자? key?
식별자 : 업무적으로 구분이 되는 정보
-> 논리적 데이터 모델링 단계에서 사용
key : 데이터베이스 테이블에 접근하기 위한 매개체
-> 물리 데이터 모델링 단계에서 사용
식별자의 특징-> 주식별자 특징
- 유일성 : 주식별자에 의해 엔티티 내에 모든 인스턴스들을 유일하게 구분
- 최소성 : 주식별자를 구성하는 속성의 수는 유일성을 만족하는 최소의 수가 되어야 함.
- 불변성 : 주식별자가 한 번 특정 엔티티에 지정되면 그 식별자의 값은 변하지 않아야 함.
- 존재성 : 주식별자가 지정되면 반드시 데이터값이 존재(Null X)
대체식별자의 특징은 주식별자와 일치하나, 외부식별자의 경우에는 주식별자의 특징과 일치하지 않으며 참조무결성 제약조건에 따른 특징을 가진다.
식별자 종류
엔티티 내에 대표성에 따라
- 주 : 구분자, 타 엔티티와 참조 관계를 연결할 수 있는 식별자
- 보조 : 구분자이나 대표성을 가지지 못해 참조 관계 연결을 하지 못함.
엔티티 내에 스스로 생성 여부
- 내부 : 엔티티 내부에서 스스로 만들어지는 식별자
- 외부 : 타 엔티티와의 관계를 통해 타 엔티티로부터 받아오는 식별자
단일 속성으로 식별되는가
- 단일 : 하나의 속성으로 구성된 식별자
- 복합 : 둘 이상의 속성으로 구성된 식별자
의미 있는 식별자 속성을 대체
- 본질 : 업무에 의해 만들어지는 식별자
- 인조 : 업무적으로 만들어지지 않지만 원조식별자가 복잡한 구성을 가지고 있기 때문에 인위적으로 만든 식별자
주식별자 도출 기준
- 해당 업무에서 자주 이용되는 속성을 주식별자로 지정
- 명칭, 내역 등과 같이 이름으로 기술되는 것들은 지정X
- 복합으로 주식별자로 구성할 경우 너무 많은 속성 X
식별자 관계
- 주식별자 : 자식의 주식별자로 부모의 주식별자 상속
- 부모로부터 받은 식별자를 자식엔터티의 주식별자 로 이용하는 경우
강한 연결관계 표현, 실선 표기
- 비식별자 : 부모 속성을 자식의 일반 속성으로 사용
- 부모 없는 자식이 생성될 수 있는 경우
- 부모와 자식의 생명주기가 다른 경우
- 여러개의 엔터티가 하나의 엔터티로 통합되어 표현 되었는데 각각의 엔터티가 별도의 관계를 가진 경우
- 자식엔터티에 별도의 주식별자를 생성하는 것이 더 유리한 경우
- SQL 문장이 길어져 복잡성 증가되는 것 방지
약한 연결관계 표현, 점선 표기
모델링의 특징
- 추상화
- 단순화
- 명확화
상세화
모델링의 3가지 관점
- 데이터 관점
- 프로세스 관점
- 데이터와 프로세스의 상관 관점 : 관계 위주
데이터의 품질 보장을 위해 유의해야 할 점
- 중복 : 중복 x
- 비유연성 : 유연하게 설계
- 비일관성 : 일관성 있게 설계
모델링의 3가지 단계
- 개념적 데이터 모델링 : 추상화 수준이 가장 높음
- 논리적 데이터 모델링 : 재사용성이 가장 높음 - key, 속성, 관계 등 모두 표현하는 단계
- 물리적 데이터 모델링 : 실제 DB에 구현할 수 있도록 물리적인 성격을 고려
3단계 스키마 구조 - 데이터의 독립성
- 외부 스키마 : 사용자 관점
- 개념 스키마 : 데이터 간 관계 관점
- 내부 스키마 : 물리적인 관점 - 실제 DB에 저장하는 구조 / 저장 구조, 칼럼 정의, 인덱스 등
이로 인해 논리적, 물리적 독립성이 보장된다.
- 논리적 독립성 : 개념 스키마가 변경되어도 외부 스키마는 영향 X
- 물리적 독립성 : 내부 스키마가 변경되어도 외부/개념 스키마는 영향 X
ERD(Entity Relationship Diagram)
IE/Crow's Foot 모델이 가장 많이 사용된다.
https://ppomelo.tistory.com/51
ERD 작성 순서
- 엔티티를 도출하고 그리기
- 배치
- 엔티티 간 관계 설정
- 관계명 기입
- 관계 참여도 기입
- 관계의 필수/선택 여부 기입
02 엔티티(Entity)
엔티티 용어
- 엔티티 - Table
- 인스턴스 - Row
- 속성 - Column
엔티티의 특징
- 업무에서 실제로 사용
- Unique Key가 있어야 함
- 2개 이상의 인스턴스를 갖고 있어야 함 (1개이거나, 앞으로도 쭉 1개일 경우 엔티티 X)
- 속성(Column)이 있어야 함
- 다른 엔티티와 1개 이상의 관계를 갖고 있어야 함
엔티티의 종류 - 유/무형에 따른 분류
- 유형 엔티티 : 물리적 형태, 안정성, 지속성 (회원, 상품 등)
- 개념 엔티티 : 물리적 형태 없음, 개념적(부서, 학과 등)
- 사건 엔티티 : 행위로 발생(주문, 이벤트 응모 등)
엔티티의 종류 - 발생 시점에 따른 분류
- 기본 엔티티 : 업무에 원래 존재하는 정보 (상품, 회원, 사원, 부서 등)
- 중심 엔티티 : 기본 엔티티로부터 파생, 행위 엔티티 생성(주문, 매출, 계약 등)
- 행위 엔티티 : 2개 이상의 엔티티로부터 파생, 데이터가 자주 변경되거나 증가 가능 (주문 내역, 이벤트 응모 이력 등)
03 속성(Attribute)
속성의 특징
- 더 이상 쪼개지지 않는 레벨
- 프로세스에 필요한 항목
- 업무상 불필요하면 삭제하는 게 낫다.
- 속성은 한 개의 값만 가져야 한다. (원자값, atomic) == 하나의 속성은 하나의 속성 값만 가진다.
- 하나의 엔티티는 두 개 이상의 속성을 갖는다.
- 엔티티의 구체적이고 명확한 정보를 나타낸다.
속성의 분류 - 특성에 따른 분류
- 기본 속성(Basic) : 업무 프로세스를 통해 바로정의 / 가장 많은 비중을 차지한다.
- 설계 속성(Designed) : 업무에 존재하지는 않지만, 필요하다고 판단해서 도출해 낸 속성 - ex) 학생의 고유 번호
- 파생 속성(Derived) : 다른 속성의 속성값에 대해 계산된 값 또는 가공된 값 - ex) 재고, 좋아요 수 등
데이터 정합성이 고려되어야 한다.
속성의 분류 - 구성 방식에 따른 분류
- PK속성 : 인스턴스의 Unique 함을 부여하는 속성
- FK 속성 : 다른 엔티티와 관계를 맺게 해주는 속성 - FK는 null 값 가능
- 일반 속성 : PK, FK를 제외한 나머지 속성
도메인(Domain)
- 속성이 가질 수 있는 속성값의 범위 - ex) 우편 번호는 다섯 자리 숫자라는 범위를 갖고 있다.
용어 사전 : 업무상 Rule을 정하기 위해 업무용 지침을 정하기도 한다.
시스템 카탈로그 : 시스템 관련 DB / 여기 담긴 데이터를 메타데이터라고 하고, SELECT만 가능하다.
04 관계(Relationship)
관계의 종류
- 존재 관계 : 엄마 - 아기처럼 존재 자체로 연관성이 있는 관계 (직원-부서, 학생-학과 등)
- 행위 관계 : 행위를 함으로써 연관성이 생기는 관계 (회원-주문, 학생-출석 등)
관계 표기법
- 관계명 : 엔티티 간에 어떤 관계를 맺고 있는지를 나타내는 문장 - 항상 양쪽에서 하나씩 두 개의 관계명
-> 명확한 문장 / 현재형 - 관계 차수 : 각 엔티티에서 관계에 참여하는 수 (1:1 / 1:M / M:N )
- 관계 선택 사양 : 필수인지, 선택인지의 여부
관계 명 / 관계 차수
관계 선택 사양
05 식별자(Identifiers)
식별자란?
각각의 인스턴스를 구분 가능하게 만들어주는 대표적인 속성
주 식별자(PK)의 속성
PK(Primary Key), 기본키, 주식별자라고 불린다.
하나의 속성이 주 식별자가 될 수도 있고, 여러 개의 속성이 주 식별자가 될 수도 있다.
- 유일성 : 각 인스턴스에 유니크함을 부여해서 식별이 가능하도록 한다.
- 최소성 : 유일성을 보장하는 최소 개수의 속성이어야 한다.
- 불변성 : 속성값이 되도록 변하지 않아야 한다.
- 존재성 : 속성값이 Null일 수 없다.
식별자의 분류
[대표성 여부]
- 주 식별자 : 유일성, 최소성, 불변성, 존재성을 가진 대표 식별자 / 다른 엔티티와 참조 관계로 연결
- 보조 식별자 : 인스턴스를 식별할 수는 있지만, 참조 관계로 연결되지는 않음 / 다른 엔티티와 참조 관계 X
[스스로 생성되었는지 여부]
- 내부 식별자 : 엔티티 내부에서 스스로 생성된 식별자
- 외부 식별자 : 다른 엔티티에서 온 생성자, 다른 엔티티와의 연결고리 역할 (FK)
[단일 속성의 여부]
- 단일 식별자 : 하나의 속성으로 구성된 식별자
- 복합 식별자 : 두 개 이상의 속성으로 구성된 식별자
[대체여부]
- 원조 식별자 : 업무 프로세스에 존재하는 식별자 ( 가공되지 않은 원래의 식별자 )
- 대리 식별자 : 주 식별자의 속성이 두 개 이상인 경우, 그 속성들을 하나로 묶어서 사용하는 식별자 (두 개를 묶어서 만들어냄)
식별자 vs 비식별자
식별자 관계
자식 엔티티에 PK가 따로 없고, 다른 엔티티의 PK를 FK로 사용한다.
부모 엔티티가 있어야 자식 엔티티를 생성할 수 있다. (1:1 또는 1:M)
비식별자 관계
부모 엔티티의 식별자가 자식 엔티티의 일반 속성이 되는 관계이다.
부모 엔티티가 없어도 자식 엔티티를 생성할 수 있고, 부모 엔티티가 삭제되어도 자식 엔티티가 존재할 수 있다.
01 정규화(Normalization)
정규화란?
정규화는 데이터 정합성(데이터의 정확성과 일관성을 유지, 보장)을 위해 엔티티를 작은 단위로 분리하는 과정이다.
제1 정규화
하나의 속성은 반드시 하나의 값만 가져야 한다.
예를 들어, "취미"이라는 럼에 "농구, 영화감상, 클라이밍"과 같이 여러 개의 값이 들어가면 안 된다.
"취미" 컬럼에 여러 개의 값이 들어가던 것을 테이블을 분리해서 1 정규화에 만족하도록 수정했다.
제2 정규화
엔티티의 모든 일반 속성은 반드시 모든 주식별자에 종속되어야 한다.
주식별자(PK)가 단일 식별자가 아닌 복합 -식별자일 경우 제2 정규화를 통해 테이블을 분리한다.
제3 정규화
주 식별자가 아닌 모든 속성 간에는 서로 종속될 수 없다.
(이행적 함수 종속성을 제거)
02 반정규화(De-Normalization)
반정규화는 데이터의 조회 성능을 향상하기 위해 데이터의 중복을 허용하거나, 데이터를 그룹핑하는 과정이다.
- 조회 성능 향상 가능성
- 입력, 수정, 삭제 성능 저하 가능성
- 데이터 정합성 문제 발생 가능성
- 반정규화는 반드시 정규화 과정이 끝난 후 진행된다.
테이블 반정규화 - 테이블 병합
업무 프로세스 상 JOIN이 많이 발생하는 경우, 테이블을 병합하는 것이 성능 측면에서 유리할 경우 테이블 병합을 고려한다.
1 : 1 관계 테이블 병합
1 : 1 관계를 맺고 있는 테이블을 하나의 PK를 갖는 하나의 테이블로 병합하는 방법이다.
1 : M 관계 테이블 병합
1 : M 관계를 맺고 있지만, 항상 같이 조회되어 JOIN이 많이 발생하는 경우, 테이블 병합을 고려할 수 있다.
단, 테이블은 병합되어도 일부 요소에 대해서는 중복 데이터가 생길 수 있다.
테이블 반정규화 - 테이블 분할
테이블 수직 분할
엔티티의 일부 속성을 별도의 엔티티로 분할한다. (1 : 1 관계 성립)
테이블 수평 분할
엔티티의 속성 중 하나를 기준으로 별도의 엔티티로 분할한다. (DB 파티셔닝)
예를 들면, "주문 일자" 컬럼을 기준으로 연도별로 테이블을 분리할 수 있다.
테이블 추가
- 중복 테이블 추가 : 데이터의 중복을 감안하더라도 성능상 반드시 필요하다고 판단되는 경우 별도의 엔티티 추가한다.
- 통계 테이블 추가 : 여러 엔티티를 조회하여 통계를 계산할 일이 많은 경우 미리 계산하여 엔티티로 저장한다.
(x월 지출 금액, x년도 인원 등) - 이력 테이블 추가 : 과거의 이력을 저장해야 하는 경우, 별도의 엔티티를 추가한다.
- 부분 테이블 추가 : 특정 프로세스를 진행 시에 특정 속성에 대한 조회가 다량으로 발생하는 경우, 해당 프로세스에서 필요한 정보만 부분 테이블로 추가한다.
백업 테이블 추가
컬럼 반정규화
- 중복 컬럼 추가 : 컬럼을 추가하는 것이 유리할 경우
- 파생 컬럼 추가 : 프로세스 수행 시 부하가 염려되는 계산 값을 미리 컬럼으로 저장하여 보관하는 방식 (조회수 등)
- 이력 테이블 컬럼 추가 : 대량의 이력 테이블을 조회하는 경우, 조회 기준이 될만한 컬럼을 미리 추가해 놓는 방식
(최신 데이터 여부 YN 등)
관계 반정규화
중복 관계를 추가하는 것이 성능 측면에서 유리할 경우 추가한다.
03 트랜잭션(Transaction)
데이터를 조작하기 위한 하나의 논리적인 작업 단위이다.
트랜잭션 자세한 설명 게시글
📁[Database/데이터베이스 이론] - [Database] 트랜잭션의 동작 원리와 ACID 속성
(ex)
OX 퀴즈를 맞힌 사람에 한해, 선착순 100개의 쿠폰을 지급하는 경우. 아래와 같은 하나의 단위로 묶을 수 있다.
1. OX 퀴즈 정답 여부 확인
2. 이벤트 응모 이력을 저장한다.
3. 쿠폰을 발행한다.
OX퀴즈의 정답 여부를 확인하고, 이벤트 응모 이력을 저장했는데 쿠폰을 발행하려는 순간 선착순 100개의 쿠폰이 모두 소진된 경우를 생각해 보자. 이 경우 쿠폰 발행은 실패하게 되고, 이벤트 응모 이력 저장 또한 취소되어야 한다.
이 경우, 롤백(rollback)하여 2번 이벤트 응모 이력 저장 이전으로 되돌리는 것이 바람직하다.
04 NULL 값 처리
NULL이란?
NULL은 존재하지 않음, 값이 없음을 의미한다.
A의 "지출" 컬럼에 해당하는 데이터는 0이고, B의 "지출" 컬럼에 해당하는 데이터는 NULL인 경우를 생각해 보자.
언뜻 보면 두 가지 경우가 같아 보일 수 있으나, 0은 데이터가 입력되었으나 0인 것이고, NULL은 데이터가 입력되지 않은 경우를 말한다.
- 데이터를 집계할 때, NULL은 집계 대상에서 제외된다.
- NULL이 포함된 사칙연산의 결과는 항상 NULL이다.
가로 연산에서의 NULL 처리
가로 연산(하나의 row에서의 값 처리)의 경우에 NULL이 포함되어 있으면, 해당 결괏값은 NULL이 된다.
ex) USER A의 "수입" - "지출"을 계산하는 것을 가정
- USER A의 "수입" = 100,000
- USER A의 "지출" = NULL
- USER A의 수입 + USER A의 지출 = NULL <- 계산 결과
"수입"은 100,000원이고, "지출"은 NULL인 경우 결과값은 NULL이다.
반면, "지출"이 0인 경우 결과값은 정상적으로 100,000원이 될 것이다.
세로 연산에서의 NULL 처리
세로 연산(다른 인스턴스의 데이터와 연산)의 경우에는 NULL 값을 그냥 제외한다.
ex) USER A의 "수입"과 USER B의 "수입"을 더하는 경우를 가정
- USER A의 "수입" = 100,000
- USER B의 "수입" = NULL
- USER A의 수입 + USER B의 수입 = 100,000 <- 계산 결과
+ 기타 정리
성능 데이터 모델링
데이터베이스의 성능을 향상시키기 위해 설계 단계부터 성능과 관련된 사항들이 모델링에 반영되는 것
순서
- 데이터 모델에 맞게 정규화 수행
- DB 용량 및 트랜잭션 유형을 파악하여 성능 저하를 일으키는 부분이 없는지 검토
- 용량과 트랜잭션 유형에 맞게 반정규화 수행
- 성능 향상을 위한 PK/FK 조정, 이력모델 조정, 슈퍼/서브타입 조정 등을 수행
- 데이터 모델의 성능을 검증.
'여가 생활 > 맛집 탐방' 카테고리의 다른 글
| 데이터베이스 개념(임시) (2) | 2025.05.07 |
|---|