[회원]
| 회원번호 | 회원명 | 주소 | 연락처 |
| 1 | 지니 | 서울시 | 016-3253-3254 |
| 2 | 샘 | 인천시 | 016-2643-3254 |
| 3 | 쥬키 | 서울시 | 013-3224-3264 |
| 4 | 류 | 일본 | 016-3767-2638 |
FK(외래키)가 있는 테이블은 테이블 간의 관계에서 '다'의 관계,
FK가 없는 테이블은 테이블 간의 관계에서 '1'의 관계를 가진다고 생각하면 된다.
위의 사진에서는 주문 테이블들의 주문들이 구분이 안되기 때문에 주문번호(PK)가 필요하다.
상품 1개만 주문이 가능할 때의 상품과 주문의 관계는 1대다 관계이다.
하지만, 하나의 주문에 여러 상품을 담을 수 있을 때의 상품과 주문의 관계도 생각해보자!
1번이 실제로 구현되기 힘든 이유: 주문한 상품들이 많아지면 컬럼들이 지저분해져 분석하기 힘들다.
2번이 실제로 구현되기 힘든 이유: 주문번호가 겹쳐서 구분이 안된다.
==> 주문 테이블을 정규화해서 문제 해결을 해보자!
중복이 되서 문제가 발생하는 부분은 '주문 번호'와 '회원 번호'이다.
위의 표들은 주문 테이블을 2개의 테이블로 정규화한 모습이다.
문제가 되는 표들 기존의 주문 테이블에서 잘라냈다.
그럼 이젠 테이블 간의 관계를 생각해보자.
회원-주문의 관계 : 회원 번호로 관계 맵핑 (회원은 주문은 0개 이상 가능하다. 1대다 관계)
회원-상품의 관계 : 관계가 없다.
상품-주문의 관계 : 직접적인 관계는 없지만, 중간에 주문 내역 테이블을 중간에 두고 관계를 간접적으로 맺고 있다.
주문-주문내역의 관계 : 주문 번호로 관계가 맵핑되고 있다. 1대다 관계
상품-주문내역의 관계 : 상품번호로 관계가 맺어져 있다. 1대다 관계
회원-주문내역의 관계 : 관계가 없다.
주문내역은 양쪽(주문, 상품)에서 N을 받고 있다.
= 다대다 양방향 관계
DataBase 모델링을 해보자
DataBase 모델링 툴 추천 : DBDiagram
DataBase 모델링의 구조: '컬럼명'-자료형'
[상품]
상품번호 varchar
구매 제품 varchar
상품 설명 varchar
제조사 varchar
가격 int와 같은 구조로 만들면 된다.
모든 테이블들을 모델링 구조에 맞게 그려봤다.
테이블 간의 관계를 선으로 표현하면 DataBase 모델링 완성이다.
테이블 간의 관계가 없는 것들은 고려하지 않는다.
테이블 간의 관계선까지 그려, 완성된 DataBase 모델링은 위와 같다!
'패스트캠퍼스 데브캠프 : 남궁성의 백엔드 개발 3기' 카테고리의 다른 글
| AWS 서버 구축하기 (1) | 2025.02.24 |
|---|---|
| 비기너반 마무리 과제 : 내가 생각하는 객체 지향의 특징 (0) | 2025.02.13 |
| 비기너반 강의 복습 6 | 백엔드 계층 구조: Controller, Service, DAO | 보안(객체 분리): DTO(프론트)/Entity(DB) (0) | 2025.02.10 |
| 비기너반 강의 복습 5 | 객체 생성, 메서드 내부 객체 생성 문제, 데이터베이스 (2) | 2025.02.09 |
| 비기너반 강의 복습 4 | 클린코드(메소드, 긍정, 정의), 예외처리, 사용자 만족도, NPE (Null Pointer Exception)와 메모리 영역 구조 (2) | 2025.01.24 |