본문 바로가기
Career/Project

[2019-1] 데이터베이스 설계

by 5ole 2021. 1. 31.
Oracle Database
(2019-1) SQL 프로그래밍 프로젝트의 테이블 설계 부분만 기록

 

 

1. 테이블 설계 과정 설명

 

주제를 ‘배달음식’으로 잡았고 기본적으로 배달 어플리케이션을 운영하는 곳에 기록되는 정보라고 생각하였다.

(1) 과거 배달 기록에 대한 정보, (2) 손님에 관련된 정보, (3) 가게에 대한 정보를 토대로 테이블을 만들었다.

 


(1) 과거 배달 기록

 

테이블에 들어가는 컬럼은

주문 날짜, 손님 전화번호, 가게 전화번호, 시도, 시군구, 도로명 주소, 세부 주소, 주문한 음식, 주문 개수로 설정했다.

 

주문 주소는 손님 테이블에 추가할 계획이었으나 배달은 손님이 정해진 하나의 주소로만 주문하는 것이 아니라

현재 자신이 있는 곳에서 주위에 있는 가게로 주문할 수 있다.

그래서 데이터 삽입 과정에서 같은 사람이 집에서도 주문하고, 한강에서도 주문하는 예시를 추가하였다.

주소를 입력하는 형식은 처음에 구역별로 기준이 숫자로 나눠져 있는 우편번호로 하려했다.

하지만 같은 구, 같은 길이라도 숫자가 확연히 다르게 나타나서 길지만 도로명 주소로 입력받는 형식을 선택하였다.

 

 

 

또한 주문한 음식의 경우에는 food1, food2, food3 와 같은 방법으로 데이터를 삽입하는 방식으로 생성하였으나

같은 메뉴가 food1에 들어있을 수도 있고, food3에 있을 수도 있어 검색이 어렵다는 단점이 있었다.

그래서 이를 분리하지 않고 food 라는 컬럼으로 설정하여 데이터를 동일하게 하고 메뉴만 다르게 받는 방식으로 테이블을 설계했다.

이렇게 했을 때 같은 메뉴를 두 개 이상 시키는 예시를 생각했을 때 같은 내용으로 두 번을 입력하면

데이터가 중복돼 삽입되지 않기 때문에 주문 개수 컬럼을 추가하여 설계했다. 주문 개수는 기본 값을 1로 둔다.

 

primary key로는 날짜, 손님 전화번호, 가게 전화번호, 주문한 음식으로 설정했다.

처음에는 외부 키인 손님의 전화번호와 가게 전화번호로만 설정했으나

손님이 한 가게의 단골일 때 날마다 주문할 수 있기 때문에 날짜를 추가하였고,

주문한 음식을 추가한 이유는 같은 날 같은 집에서 다양한 메뉴를 주문할 수 있기 때문에 primary key로 설정하였다.

주소를 키로 하는 방법도 고민해보았지만 한 집에 한 명 이상의 사람이 살 수 있고

같은 주소를 가졌지만 다른 사람이 주문할 수 있고 복잡한 키가 될 것 같아 설정하지 않았다.

이를 참고하여 데이터 삽입 과정에서 주소가 같지만 번호가 다른 예시를 추가하였다.

 


(2) 가게에 관련된 정보

 

가게테이블에 들어가는 컬럼은

가게 전화번호, 가게명, 점포, 시도, 시군구, 도로명 주소, 메뉴 1, 메뉴 2, 메뉴 3, 메뉴 4, 메뉴 5로 만들었다.

실제 가게들을 참고하여 만들었으며 체인점의 경우를 고려하여 헷갈리지 않게 점포를 입력할 수 있는 컬럼을 만들었다.

주문을 할 때 손님이 주문하는 곳과 가게의 위치에 따라 주문이 제한적이므로 가게 주소를 추가하였다.

또한 각 가게의 메뉴를 5개씩 설정하여 각각 받았는데 실제 데이터로는 메뉴 개수가 더 많을 것이고

가게마다 메뉴 개수가 다르기 때문에 이 방법은 좋은 방법이 아니라고 생각한다.

이 방법보다는 메뉴 테이블을 따로 만들어 한 번호마다 메뉴를 입력하는 이러한 방식을 선택하는 것이 좋을 것이다.

 

가게 테이블을 만들면서 또 아쉬웠던 점은 체인점의 경우 메뉴 종류가 같다는 것을 간과했다는 점이다.

같은 메뉴를 여러 번 추가할 필요가 없었을 것이고, 체인점 본사에서 메뉴를 추가하거나 삭제한다면

가게 테이블에서 일일이 찾아 수정해야 한다는 문제가 생겼다.

체인점을 입력한다면 따로 체인점 테이블을 만들어 메뉴를 가져오는 방식을 선택하는 것이 좋다.


(3) 손님에 대한 정보

 

손님 테이블은 손님 전화번호와 이름, 성별, 나이를 컬럼으로 설계하였다.

손님 전화번호를 primary key로 설정하였고 과거 주문 테이블과는 foreign key로 연결한다.

손님 이름이 같을 수도 있기 때문에 손님 이름은 키로 설정하지 않았고 손님의 주소는 유동적이므로 테이블에 넣지 않았다.

아쉬운 점은 나이를 매번 갱신해야하므로 생년월일을 입력받고 현재 날짜와 비교하여 나이를 계산하는 방법을 써야한다.


2. 테이블 출력 결과

 

 

(1) select * from pastorder;

 

 

(2) select * from CUSTOMER;

 

 

(3) select * from STORE;

 

 


 

3. Review

 

 

프로젝트를 하면서 어려웠던 점은 실제 데이터처럼 만드는 작업이었다.

실제로 어떤 데이터가 필요할 것이고, 어떻게 수집할 수 있을까를 상상하는 것이 어려웠다.

 

예로 들어 주소를 입력하는 방식을 좀 더 간편하게 우편번호로 주소를 입력하는 방식을 해보았지만

입력 단계에서는 쉬울 수 있지만 직관적이지 않아 한번 더 해석 과정을 거쳐야했고

뚜렷하게 기준이 분리되어있는 것도 아니어서 도로명 주소를 사용하는 방식으로 수정했다.

 

또한 실제 데이터처럼 생각하다보니 처음엔 서울특별시뿐만 아니라

경상남도, 대구광역시 등 다양한 도시를 추가했지만

주문테이블에 들어가는 범위가 너무 커져서 데이터를 만들어내는데 어려움이 많아 서울로만 축소하였다.

 

그리고 배달 주소를 손님의 집주소로만 생각해서 손님 테이블에 주소를 입력하였다가

휴대폰 어플이다보니 주문자가 정해진 장소에만 있는 것이 아니라

다양한 곳에 존재할 수 있다는 점, 가게와 주문자의 위치가 비슷해야 주문이 가능하다는 점 등

고려해야할 부분들이 많았다. 그래서 직접 어플로 지역을 설정해 그 주위에 배달이 가능한 곳 등을

알아보는 작업들을 거쳤고 과거 주문 테이블로 컬럼을 변경하였다.

 

그리고 주문 데이터를 만드는 과정에서 한 사람이 하루에 여러 가게에 주문할 수 있는 점을

처음에 간과해 주문메뉴를 입력하는 방식에서 다소 헷갈리기도 했으며

날짜를 삽입하는 컬럼을 만들어 처음에는 1년 치의 데이터를 삽입하였으나

테이블의 범위가 또한 너무 커져서 6월 한 달의 데이터로 축소하였다.

 

손님이 같은 음식을 여러 개 시킬 수 있다는 사실 또한 처음에 간과하였고,

food1, food2 방식으로 데이터를 입력받는 형식으로 구성했다가

검색 단계에서 이상현상이 있다는 것을 후에 알게 되어 하나의 컬럼으로 다시 수정하였다.

 

결과적으로 primary key로 날짜, 손님번호, 가게번호, 메뉴 명을 설정하였는데 무엇을 설정해야하는지,

이렇게 많은 컬럼이 키로 설정되어도 되는 것인지 등 primary key 설정 과정이 어려웠다.

 

pastorder 테이블 생성은 주소가 들어가며 컬럼이 많아지고 손님들이 여러 번 주문하는 것을 고려하다보니

길어져서 엑셀 파일로 입력하고 수정하는 방법을 선택했다.

이 방법은 실제 데이터를 관리할 때 이런 방식 또한 사용할 것 같아 인터넷을 검색하여 알게 되었다.

 

이 부분에서 어려웠던 점은 데이터를 임포트할 때 앞에 30개 정도의 데이터만을 참고하여

자동으로 변수 범위를 설정하여 오라클에서 읽어오는데 뒤에 더 긴 변수가 있다면

임포트가 실패하고 다시 범위를 스스로 정해 수정해야한다.

엄청 큰 데이터를 임포트할 때 다시 수정하는 과정이 매우 귀찮았다.

또한 컬럼에 음식 및 음식 개수 등 뒤늦게 생각해서 엑셀 파일에 컬럼을 추가하며

수정하는 과정을 거칠 때 테이블을 drop하고 다시 오라클에 임포트하는 과정이 번거로웠다.

 

새롭게 알게 된 사실은 전화번호 입력방식이다.

처음에 전화번호 입력할 때 01000000000과 같이 입력하였는데

임포트를 하고보니 1000000000으로 입력이 되어있었다.

인터넷을 검색해보니 이를 숫자로 인식하기 때문에 010-0000-0000 문자 형태로 입력해야한다는 것이었다.

‘-’를 사용하여 전화번호를 입력하는 방식은 알아보기 쉽도록 사용하는 것으로 알았는데 새로운 사실을 알게 되었다.

 

일주일동안 프로젝트를 진행하여 아쉬운 부분과 수정해야할 부분이 많이 있지만

테이블을 직접 설계하고 SQL을 다루며 재미를 느꼈고,

자바나 다른 언어들보다 비교적 쉬워 단기로 많은 것을 배울 수 있었다.

 

댓글