5월 14일 작업로그
- ERD 및 논리적 설계 수정
- 함수 종속성 다이어그램
- 정규화
1. ERD 및 논리적 설계 수정
- 장바구니 상품에 가격 속성이 있었는데 없애는게 나아 그 부분을 수정하여 논리적 설계도 그거에 맞춰 수정하였다. ⇒ 주문 시에는 주문 시점의 가격을 따로 기록할 필요가 있는데 장바구니는 상품의 가격이 변할 때마다 그거에 맞춰 변하는거니까 가격을 기록하지 않고 그냥 가져와서 보여주는게 좋을 듯 했다.
2. 함수 종속성 다이어그램
- 이상현상: 기본키가 아니면서 결정자인 속성(비후보키 결정자 속성)이 릴레이션에 존재할 때 발생 ⇒ 릴레이션을 결정자인 속성이 기본키가 되도록 분해해 이상현상 제거
상품
- 다른 부분에서 기본키 이외에 결정자인 속성이 존재하지 않는 것으로 보인다.
- 상품-옵션 조합 릴레이션 같은 경우는 상품별 옵션이 뭐가 있는지 살펴보는 용도라 상품상세ID로 옵션을 하나 결정할 수 없고, 옵션으로도 하나를 결정할 수 없는 관계라 이게 괜찮은 건지..? 잘 모르겠다.
장바구니
- 이걸 그리면서 계속 또 고민인건 장바구니가 진짜 필요할지…? 속성도 하나만 갖는데 그게 회원ID라 필요가 없는거 아닌가?하는 생각이 계속든다.
3. 정규화
제1정규형
- 릴레이션의 모든 속성이 더 이상 분해되지 않는 원자값만 가질 때
제2정규형
- 릴레이션이 제1정규형에 속할 것
- 기본키가 아닌 모든 속성이 기본키에 완전 함수 종속될 것
+) 완전 함수 종속: A → B 종속성이 성립할 때, B가 A의 속성 전체에 함수 종속하고, 부분집합 속성에 함수 종속하지 않을 경우.
+) 부분 함수 종속(불완전 함수 종속): A의 속성 일부를 제거해도 종속성이 성립하는 경우.
제3정규형
- 릴레이션이 제2정규형에 속할 것
- 기본키가 아닌 모든 속성이 기본키에 비이행적 함수 종속
+) 이행적 함수 종속: 릴레이션을 구성하는 3개의 속성 집합 X, Y, Z에 대해 X→ Y, Y→Z가 존재하면 X→Z가 성립
+) 비이행적 함수 종속: 속성이 기본키에 직접적으로만 종속되고, 다른 속성을 거쳐 종속되지 않은 경우
BCNF 정규형
- 릴레이션의 함수종속성 X→Y가 성립할 때, 모든 결정자 X가 후보키
- 상품관련 정규화: 상품 정규화 노션
- 장바구니 관련 정규화: 장바구니 정규화 노션
위에서 정리한 체크리스트? 기반으로 일단 각각 정규화를 진행했다.
정규화를 하면서 깨달은건 장바구니의 함수 종속성 다이어그램을 잘못 그렸었다.
위처럼 수정했는데, 일전에 논리적 설계할 때 (회원ID, 상품상세ID)를 UNIQUE로 설정했었는데 이거를 까먹고 있어서 수정하고 정규화를 체크했다.
4. 물리적 설계 (테스트)
(1) 옵션 관련 문제
- 정규화 확인하기 힘들거 같아서 그냥 한 번 테이블 예시를 써봤는데? 옵션 종류와 옵션 상세를 이렇게 나누는게 좋은지 안좋은지 잘 모르겠다.
-
과한 거 같기도한데…? 또 막상 합치자니 옵션종류ID로 옵션값 결정이 안될 것 같고
- (옵션상세ID, 옵션종류ID) → 이렇게 해야 결정이 되고?
-
그렇다고 완전 하나의 거대한 테이블로 만들면 중복 데이터가 많아질 것 같다.
- 하나의 테이블에 합치면 거기에 S-연청 이런식의 데이터가 여러 개의 상품마다 계속 중복으로 들어갈 것 같아서 또 분리해야하는 거 같아지는…?⇒ 우선은 분리해서 가져가는게 나아 보여서 그렇게 하기로 했다.
-
(2) 상품옵션조합 테이블 문제
- 상품마다의 옵션을 연결하는걸 위에 릴레이션으로 만들어서 그때그때 사용해서 조인하려고 했다. 상품상세하고 옵션상세가 다대다 관계니까 일단 릴레이션으로 빼긴 빼야할 것 같았다.
- 그런데? 러프하게 데이터 넣고 보니까, 상품 하나에 S 빨강, S 파랑, M 빨강, M 파랑 이렇게 한 종류의 옵션이 아니라 여러 옵션이 들어갈 수 있었다.
- 잘못된 줄 알았는데 또 막상 실제 상품명이랑 옵션명을 적어놓고 보니까 괜찮게 돌아갈 것 같았다.
⇒ 좀 완전하게 하고 DDL 작성하고 하려고 했는데 이런걸 확인하려면 일단 작성하고 직접 쿼리 써서 테스트해보는게 나을 것 같아서 계획을 바꾸는게 좋을 것 같다…
이불 밖은 위험해.