Entity들은 서로 연관관계를 갖는다.
음식 주문 앱을 만든다고 생각하면서 공부해보자.
[DB 연관관계]
고객 id | 고객 이름 |
1 | 태호 |
2 | 용석 |
음식 id | 음식 이름 | 음식 가격 |
1 | 양념치킨 | 18000 |
2 | 후라이드치킨 | 17000 |
3 | 감자피자 | 17000 |
4 | 비싼피자 | 25000 |
고객 데이터 베이스와 음식 데이터베이스가 있다.
이떄 고객과 음식은 서로 N대M의 관계를 갖고있다고 할 수 있다.
한명의 고객이 N개의 음식을 주문할 수 있고, 한개의 음식이 N명의 고객으로부터 주문을 당할 수 있기 때문.이를 우리는 N대M의 관계를 갖는다고 표현한다. 그렇다면 이를 DB에 반영하게 되면 어떻게 반영을 해야 할까?
고객인 태호가 후라이드 치킨, 양념 치킨을 주문 한다고 하면 주문 내역은 어디로 들어가면 좋을까?
고객 DB에 주문한 음식을 추가하게 된다면, 혹은 음식 DB에 주문한 고객을 추가하게 된다면 이런식으로 DB가 구성된다.
예) 태호가 양념치킨과 감자피자를 시키고, 용석이가 양념치킨, 후라이드 치킨과 비싼 피자를 시켰을 때
고객ID | 고객이름 | 음식ID |
1 | 태호 | 1 |
1 | 태호 | 3 |
2 | 용석 | 1 |
2 | 용석 | 2 |
2 | 용석 | 4 |
예)위의 주문을 음식 테이블로 매칭하면?
음식ID | 음식이름 | 음식 가격 | 주문한 고객ID |
1 | 양념치킨 | 18000 | 1 |
1 | 양념치킨 | 18000 | 1 |
2 | 후라이드치킨 | 17000 | 2 |
3 | 감자피자 | 17000 | 1 |
4 | 비싼피자 | 25000 | 2 |
이런식으로 구성된다. 고객 DB에 중복되는 데이터들이 너무 많아진다. 이렇게 되면 고객의 ID값들도 이상해진다.
고객DB에는 고객의 정보들만 존재하고, 음식의 DB에는 음식의 정보만 존재하는게 데이터 관리에는 좋을 것 같다.
그렇다면 주문 정보를 저장하고 싶다면 어떻게 해야 할까? 내가 선택한 방식은 주문 TABLE을 새로 만드는 것. 나는 주문 TABLE은 이렇게 구성했다. 주문 raw 한개당 주문한 고객과 주문한 음식을 1개씩 넣어주는 방식.
고객ID | 고객이름 | 주문한 음식 ID | 음식이름 | 음식 가격 |
그렇다면 주문 TABLE은 고객/음식 TABLE과 어떤 관계를 갖게 될까?
고객 한명은 N개의 주문을 할 수 있다. 하지만 주문 한개는 오직 한명의 고객으로부터 발생한다.
따라서 고객과 주문은 1대 N의 관계를 갖게 된다.
음식 한개는 N개의 주문을 받을 수 있다. 하지만 주문 한개는 오직 하나의 음식을 갖게 된다.
따라서 음식과 주문또한 1대 N의 관계를 갖게 된다.위의 태호와 용석이의 주문을 주문 TABLE로 다시 만들어보자.
고객ID | 고객이름 | 주문한 음식 ID | 음식 이름 | 음식 가격 |
1 | 태호 | 1 | 양념치킨 | 18000 |
1 | 태호 | 3 | 감자피자 | 17000 |
2 | 용석 | 1 | 양념치킨 | 18000 |
2 | 용석 | 2 | 후라이드 치킨 | 17000 |
2 | 용석 | 4 | 비싼 피자 | 25000 |
주문 TABLE에서는 음식을 주문한 고객정보를 토대로 정보를 검색할 수도 있으며, 주문된 음식을 토대로 정보를 검색 할 수 있다.
이렇게 N대N관계를 N:1, N:1 관계로 풀어서 TABLE을 설계한다면 데이터의 중복이 없이 DB를 관리하는 방식을 더 효율적으로 관리 할 수 있게 된다.
'공부 > 개념 정리' 카테고리의 다른 글
[Java] Optional을 쓰는 이유 (0) | 2023.11.13 |
---|---|
[Spring] Filter의 개념 (0) | 2023.11.13 |
[Spring] Authentication과 Authorization (0) | 2023.11.10 |
[Spring] Bean의 쓰임과 수동 등록에 대해 (0) | 2023.11.10 |
Java) Comparable과 Comparator의 차이에 대해 (1) | 2023.10.18 |