728x90
정규화: 잘못 설계된 관계형 스키마를 쪼개어 바람직한 스키마로 만들어 가는 과정
- DB 논리적 설계단계에서 수행
- 수준이 높을수록 유연한 데이터 구축, 정확성 상승, 물리적 접근이 복잡, 조회 성능이 저하
- 정규화의 목적 : 단순화, 무결성, 안정성
- 어떠한 릴레이션이라도 DB 내에서 표현 가능
- 효과적인 검색 알고리즘 생성 가능
- 중복배제, 저장공간의 최소화
- 데이터 삽입 시 릴레이션을 재구성할 필요성을 줄임
- 정규화를 거치지 않을 시 데이터들이 불필요하게 중복되는 현상인 이상(Anomaly)이 발생할 수 있다.
- 삽입 이상 : 삽입 시 원하지 않은 값들도 함께 삽입되는 현상
- 삭제 이상 : 삭제 시 상관없는 값들도 함께 삭제되는 현상
- 갱신 이상 : 갱신 시 일부분만 갱신되어 정보에 모순이 생기는 현상
- 정규화의 원칙
- 스키마를 다른 스키마로 변환할 시 정보의 손실이 있어서는 안된다
- 분리의 원칙 : 하나의 독립된 관계성은 하나의 독립된 릴레이션으로 분리시켜 표현해야 한다.
- 데이터의 중복성이 감소되어야 한다
- 정규화 과정
- 1NF : 모든 도메인은 원자값(Atomic)만으로 구성
- 2NF : 기본키가 아닌 모든 속성이 기본키에 완전 함수적 종속(부분적 함수 종속 제거)
- 3NF : 기본키가 아닌 모든 속성이 기본키에 이행적 함수 종속 제거
- BCNF : 결정자가 모두 후보키인 정규형
- 결정자 : 속성 간 종속성 규명 시 기준이 되는
반정규화 : 성능향상 편의성 등을 위해 의도적으로 정규화 원칙을 위배하는 행위
통합, 분할, 중복 등을 수행(일관성 및 정합성이 저하될 수 있음)
- 일관성과 무결성을 우선으로 할지, 성능과 단순화를 우선으로 할지를 결정하여야 함
- 테이블 통합 : 두개의 테이블에서 동일하게 자주 처리되는 경우, 테이블 통합을 고려
- 1:1 통합, 1:N 통합, 슈퍼타입/서브타입 테이블 통합이 있다
- 간편해지지만 레코드 증가로 인해 처리량이 증가
- 입력, 수정, 삭제 규칙이 복잡해질 수 있다
- Not null, Default, Check(속성값의 범위) 등의 제약조건을 설계하기 어렵다
- 테이블 분할
- 수평분할 : 레코드별로 사용빈도의 차이에 따라 테이블을 분할
- 수직분할 : 속성이 너무 많을 경우 속성을 기준으로 테이블을 분할
- 갱신 위주의 속성 분할 : 갱신 시 레코드 잠금으로 인해 작업을 수행할 수 없으므로
- 갱신이 자주 일어나는 속성들을 수직 분할하여 사용
- 자주 조회되는 속성 분할 : 자주 조회되는 속성이 극히 일부일 경우
- 크기가 큰 속성 분할
- 보안을 적용해야 하는 속성 분할
- 중복 테이블 추가
- 여러 테이블에서 사용하거나 다른 서버 테이블을 이용해야 하는 경우 효율성 향상
- 추가하는 경우
- 정규화로 인해 수행 속도가 느려지는 경우
- 많은 범위의 데이터를 자주 처리해야 하는 경우
- 특정 범위의 데이터만 자주 처리해야 하는 경우
- 처리 범위를 줄이지 않고는 수행 속도를 개선할 수 없는 경우
- 중복 테이블을 추가하는 방법
- 진행 테이블의 추가 : 이력관리 등의 목적으로 추가하는 테이블
- 이력관리 : 속성 값의 변화를 관리
- 특정 부분만을 포함하는 테이블의 추가
- 특정 부분만 사용하는 경우 특정 부분만으로 새로운 테이블 생성
- 집계 테이블의 추가 : 각 원본 테이블에 트리거를 설정. 오버헤드에 유의
- 진행 테이블의 추가 : 이력관리 등의 목적으로 추가하는 테이블
- 중복 속성 추가 : 데이터 조회경로를 단축하기 위해 자주 사용하는 속성을 하나 더 추가
'Springboot' 카테고리의 다른 글
[Springboot] UnsatisfiedDependencyException (0) | 2023.08.01 |
---|---|
[Springboot] OneToMany VS ManyToOne (0) | 2023.07.30 |
[springboot] 07-21 ~ 07-27 (0) | 2023.07.27 |
[Springboot] RefreshToken Redis에 저장하기 (0) | 2023.07.19 |
[Springboot] DAO, DTO, VO (0) | 2023.07.18 |