티스토리 뷰
현실세계를 도출해 내서 개념적모델링(ERD)를 거친 후, 만들어진 ERD를 가지고 정규화를 통해 테이블을 상세화하는 과정을 논리적 모델링의 단계라고 한다.
실제 값을 넣어봤을때 어떤 이상 현상이 발생되는지, 그리고 그 이상현상을 해결하기 위해서 어떤 정규화 과정을 진행 해야 하는지 알아보는 단계이다.
정규화(DB normalization)
데이터 모델링 목적
데이터 증가 -> 데이터 중복 증가 -> 애플리케이션으로 해결 가능
-> SQL 응답 속도 저하 ->SQL 튜닝으로 해결 가능
고객사의 변화 / PM/PL(프로젝트 팀장)의 변화 -> 데이터모델링에 대한 관심 증가 -> 데이터 모델링 기술력 확보
이렇게 해결 가능 한데, 굳이 정규화(데이터 모델링)이 필요 한가?
해결 가능하지만, 데이터의 근본적인 원인을 해결하지 않으면 나중에 더 큰 일을 초래할 수 있기 때문에 근본적인 문제를 해결하기 위해서 데이터 모델링이라는 작업을 해야 한다.
정규화는 데이터모델링에서 가장 핵심적인 개념이다.
관계형 데이터베이스에서 데이터를 구조화 하는 작업(중복을 찾아 제거해 나가는 과정)
정규화의 목적
데이터의 중복을 방지하고 보다 효율적으로 데이터를 저장하기 위함
삽입, 삭제, 갱신 이상의 발생 가능성을 줄이기 위함.
비정규화 테이블 -> (반복 속성 제거, 모든 속성이 원자값을 가짐) ->
제 1정규형 -> (부분 함수적 종속 제거, 키가 아닌 모든 속성이 기본키 그룹에 완전하게 함수적 종속) ->
제 2정규형 -> (이행적 함수적 종속 제거, 키가 아닌 모든 속성이 기본키에 직접 종속(비이행적) ->
제 3정규형 -> (후보키가 아닌 결정자 제거, 모든 결정자가 후보키) ->
BCNF -> (다치종속 제거) ->
제 4정규형 -> (조인 종속성 이용) ->
제 5정규형
실무에서는 실질적으로 3정규화까지만 알면된다. 5정규화까지 하여서 쪼개면 굳이 쪼갤 필요가 없는 것까지 쪼개면 많은 문제가 발생하기 때문.
정규화의 장단점 : 정규화를 통해 하나의 엔티티를 두개의 엔티티로 쪼개놓음으로서 하나의 엔티티가 하나의 정보만을 가지게 표현할 수 있는데, 중복 제거를 해서 삽입,삭제,갱신이상에 대해서는 해결을 했지만, 너무 많이 쪼개버리게 되면 다 조인을 해서 조회를 해야하기 때문에 이상현상이 발생할 수도 있다. 따라서, 조회를 많이 해야 한다면 엔티티를 많이 쪼개면 안된다. 하지만 정규화에서는 최대한 엔티티를 쪼개고 물리DB를 통해 반정규화를 통해 조회시스템을 최적화 시킬 수 있다. 쉽게 말해 쪼개놓은 엔티티를 다시 합치거나 아니면 중복된 속성을 가져다 쓰거나 이런 과정을 반정규화때 진행을 하면 된다. 즉 쉽게 말해 일관성을 확보하고 적절한 속성을 확보하여 하나의 엔티티에서는 하나의 정보만을 담도록 하는게 정규화이다.
이상(Anomaly)
: 이상 현상을 해결하기 위해 정규화 과정을 해야한다.
삽입 이상
불필요한 정보를 함께 저장하지 않고는 어떤 정보를 저장하는 것이 불가능
ex) 주문에 대한 정보만 입력해도 제품에 대한 정보도 같이 입력해야 함.
제품에 대한 정보만 입력하고 싶을때 주문에 대한 정보는 NULL값을 가진다.
갱신 이상
반복된 데이터 중에 일부만 수정하면 데이터의 불일치가 발생(다 수정을 해야한다)
ex) 동일한 제품명을 중복되어 있는 수만큼 수정 해야 함, 한번만 수정하거나 일부만 수정할 경우 일관성이 맞지 않는 문제가 발생.
삭제 이상
유용한 정보를 함께 삭제하지 않고는 어떤 정보를 삭제하는 것이 불가능
ex) 주문에 대한 정보(주문번호, 주문수량)를 삭제할 때 제품번호, 제품명, 단가도 같이 삭제됨
즉, 452794라면 주문을 취소했을 때, 옷장에 대한 정보까지도 삭제가 되어버린다.
delete 문을 사용하면 한 행이 삭제되니 어디에도 옷장에 대한 정보가 남아있지 않으니
정규화 과정
제 1정규화
엔티티에서 하나의 속성이 복수의 값을 갖도록 설계되었을 때 하나의 속성이 단일 값을 갖도록 하는 것
하나의 속성에는 하나의 값.
사번 | 사원명 | 취미 |
1001 | 김개똥 | 등산 낚시 |
1001 | 김개똥 | 테니스 |
사번 | 사원명 | 취미 |
1001 | 김개똥 | 등산 |
1001 | 김개똥 | 낚시 |
1001 | 김개똥 | 테니스 |
주 식별자의 유일성을 잃을 뿐더러 취미라는 속성때문에 같은 정보가 계속 중복되어 발생을 한다.
null값으로 인해 메모리 낭비가 심하다.
취미라는 속성때문에 반복되는 사원 정보를 부모엔티티로 뽑아내는 과정이 필요하다.
'DB 모델링 > 3_논리적 모델링' 카테고리의 다른 글
3) 제 3 정규화 (0) | 2021.12.08 |
---|---|
2-1) 제 2 정규화 실습 (0) | 2021.12.05 |
2) 제 2 정규화 (0) | 2021.12.05 |
1-1) 1차 정규화 실습1 (0) | 2021.12.05 |
- Total
- Today
- Yesterday
- 자바 do while
- Switch Case
- 자바 연산자 우선순위
- 자바 프로그래밍이란
- 다운캐스팅
- if else if
- 자바 switch case
- java 기초
- 반복문 break continue
- java 프로그래밍이란
- 객체지향이란
- 스프링 로깅
- 자바 반복문
- 자바의 기초
- 데이터베이스 null
- 자바 조건문 if else if문
- java
- 중첩반복문
- 조건문
- Downcasting
- 스프링 로그
- 자바 조건문 if else
- 자바
- 자바 if if
- 스프링 logging
- if if
- 자바 반복문 for문
- java란
- 반복문
- 자바 if else if else
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | ||||
4 | 5 | 6 | 7 | 8 | 9 | 10 |
11 | 12 | 13 | 14 | 15 | 16 | 17 |
18 | 19 | 20 | 21 | 22 | 23 | 24 |
25 | 26 | 27 | 28 | 29 | 30 | 31 |