1205 정규화&UML
UML
1개의 시나리오-유스케이스1개 -시퀀스1개
기획 단계
유스케이스 다이어그램
가장먼저 그려지는 다이어그램
세부사항까진 아니고 전반적인 구조를 그려냄
클래스 다이어그램/객체 다이어그램/상태 다이어그램..
이 부분에서 구체적으로 설계하기 시작.
=>구현단계에서도 계속해서 사용하게 됨
1.유스케이스 다이어그램
다른 시스템도 사람처럼 그림(sms시스템)
유스케이스 다이어그램
위의 예시로 유스케이스 다이어그램을 만들어보자.
일단은 사용자와 사용자가 할 수 있는 일을 간략하게 나타냄
사용자간의 관계와 할 수 있는 행위를 명확하게 구분함
회원가입,로그인은 일반사용자가
상품관리와 통계조회는 관리자가 할 수 있지만
회원정보 조회, 상픔목록조회 같은 것은 일반사용자와 관리자가 공통으로 할 수있음.
또한 결제 관련 행위는 sms시스템이 관여되어있음.
2차를 좀 더 보기 좋게/ 알기 쉽게 구분함.
시퀀스 다이어그램
회원가입/상품조회의 작업 절차를 가시화 해보자..
작업의 순서는 위에서 아래고, 화살표를 따라 순차적으로 진행된다.
view-controller-service-dao mvc 패턴을 기준으로 작업.(각 단이 맡은 역할이 명확해서 사용/관리 용이)
실선:message
점선:Reply Message(응답)
opt 옵션(해도 되고,안해도 됨)
아래 예제 같은 경우엔 회원이 상품 검색을 할 수도, 안할 수도 있어서 opt영역으로 감쌌다.
alt if~else
결과가 2개 이상인 경우.
아래 예제 같은 경우엔 상품조회 결과가 있을 수도 있고 없을 수도있기에 alt영역으로 감쌌다.
if(상품목록결과가있음)
else
상품목록결과가없음
+
2개가 아니라 2개이상!
if~else로만 끝나는게 아니라 그 이상의 조건이 붙을 수도있다.
정규화
1정규화
모든 컬럼의 데이터는 원자값으로 이루어져야 한다.
(원자값:더 이상 쪼개질 수 없는 상태 즉, csv 제거)
2정규화
복합 pk인 경우 부분 함수적 종속을 제거하여 완전 함수적 종속 상태
-부분 함수적 종속: 복합 pk에서 일부컬럼에 종속 된 경우
-완전 함수적 종속: 복합 pk에서 모든 컬럼에 종속 된 경우
부분 함수적:학생번호로 학생명을 알 수있음, 수강과목번호로 수강과목명을 알 수있음
완전 함수적:학생번호+수강과목번호로 학점을 알 수있음.
학점은 두개의 pk가 있어야 확인이 가능하다.
정처기 때 이거 헷갈렸는데 이제서야 확실히 이해함...
3정규화
이행적 함수 종속이 없는 경우
x->y->z
bcnf
4정규화
5정규화
오늘은 3정규화까지.
테이블 연관 관계
| 연관관계 | 특징 |
| 1:1 | 참조하는 컬럼값(fk)를 다시 pk로 사용하는 경우 해당하는 값을 한 번만 사용할 수 있음 식별관계 테이블을 나누지 않고, 합치는 것도 고려할 수 있음 (단, 데이터가 많지 않을때에 한해) |
| 1:N (부모자식 관계) | 참조하는 컬럼값을 복수의 레코드에서 사용하는 경우 해당값을 여러번 사용할 수있음 비 식별관계 ex) 한 회원의 배송지가 여러개인 경우 |
| N:M(다대다 관계) | 1:N / 1:M의 관계가 성립되는 경우 두 개의 테이블만으로는 표현이 불가하므로 연결테이블(브릿지테이블)이 존재해야 한다. ex) 하나의 게시글은 여러개의 해시태그를 사용할 수 있다. 하나의 해시태그는 여러 게시글에 사용 될 수 있다. |
예제
첫번째의 조잡한 테이블을 1,2,3정규형을 고려하여 총 5개의 테이블로 나누었다.
나같은 경우엔
tb_topping
tb_mainmenu
tb_order
매운맛정도를 포함할 tb_spicy까지는 잘 분리해냈는데
복합 pk를 어떻게 해야 하나 생각을 했다..
주문번호/주메뉴번호에 더불어 토핑도 주메뉴마다 다른터라 세개를 묶는 것이 맞는데,
마지막 오더에 카레라면엔 토핑이 빠져있어서 이걸 포함시켜야 고민함.
복합 pk 테이블에는 하나라도 널 값이 있으면 안된다 한다.
생각해보니 토핑메뉴도 pk인데 null값이라는 것 자체가 문제였음.