아래 그림은 마트의 푸드코드에서 음식을 주문하고 받은 영수증입니다. 영수증을 보고 데이터베이스를 설계하세요.
영수증 그림만으로 데이터베이스 설계를 하라니, 매우 불친절한 요구사항입니다. 하지만 자신의 지식과 상상력을 동원해 더 자유롭게 설계해 볼 수 있는 기회도 제공합니다.
데이터베이스 설계를 위해, 영수증 그림에 표시된 내용을 정리해보면 다음과 같습니다.
•
re-MART라는 마트의 푸드 코트에서 만들어진 영수증입니다.
•
주문 일자와 시간에 대한 정보가 포함되어 있습니다.
•
주문 목록에는 다음과 같은 내용이 있습니다.
◦
상품명, 단가, 수량, 금액
◦
이를 통해 하나의 주문 영수증에 여러 상품이 주문 될 수 있다는 것을 알 수 있습니다.
•
영수증에는 과세물품금액과 부가세 금액이 별도로 표시되어 있습니다.
◦
부가세가 합(SUM)으로 구해져 있는데, 부가세는 모든 상품에 무조건 10%일까요?
◦
GPT로 검색해보니, 우리나라에서는 대부분의 공산품은 10%의 부가세가 일률적으로 붙는 것으로 보입니다.
•
아래쪽에는 카드결제에 대한 정보가 담겨져 있습니다.
◦
0010아마도 KB국민 카드의 카드사 코드쯤 되는 것으로 생각됩니다.
◦
5409로 시작하는 카드번호가 있고, 그 뒤에는 30112340이란 번호가 있습니다.
▪
아마도 30112340은 카드사에서 승인한 결제 번호 또는 승인 번호가 아닐까 생각됩니다.
◦
카드결제가 아닌 현금결제나 각종 페이 앱을 통한 결제도 고려해볼 필요가 있습니다.
•
가장 아래에는 주문번호가 있습니다. 푸드코트에서는 주문번호를 통해 고객에게 음식을 전달합니다.
위 내용들을 토대로 개념 설계를 먼저 진행해봅니다. 개념설계를 위해서는 엔터티를 선별해야 합니다. 엔터티를 선별해 정리해 보면 다음과 같습니다.
•
마트: 마트의 사업자번호나 명칭 위치(주소)등의 기본 정보를 관리할 수 있는 엔터티가 필요합니다.
◦
경우에 따라서 마트내 푸드코트는 사업자가 분리되어 있을 수 있습니다. 이 부분은 무시하고 설계를 진행해 봅니다.
•
주문: 주문일시와 주문번호를 관리하는 엔터티가 필요합니다.
•
주문상세 또는 주문별상품
◦
하나의 주문에 여러 상품을 주문할 수 있으므로 주문별 상품을 관리하는 별도 엔터티를 추가합니다.
•
결제정보: 결제 정보를 관리해야 합니다.
위 내용을 요약해 간단히 개념설계해 보면 다음과 같습니다.
위 내용의 문제점이나 개선안을 생각해 보면서 개념 모델을 좀 더 발전시켜 봅니다. 자신만의 상상력으로 더 다양한 구조를 고민해 볼 수 있을겁니다.
•
주문에 대해 다양한 방법의 여러 번 지불을 고려하고 싶습니다.
◦
위 내용을 고려해 지불 테이블을 추가합니다. 이에 따라, 주문 테이블에 있던 지불에 대한 정보 컬럼은 제거합니다.
◦
여기서는 지불방법코드에 따라 사용할 신용카드 정보 또는 페이 관련 정보 컬럼을 각각 구성했습니다. 컬럼을 통합하는 방법도 고려해볼 수 있습니다. 다만, 지불방법코드에 따라 로직이 구현되어야 하므로 개발쪽에서는 좀 더 귀찮을 수도 있습니다.
◦
카드사나, 페이사와의 결제 처리 과정에 따라 추가되는 속성들이 있을 것이라 예측됩니다.
•
이번에는 상품의 가격을 처리하는 테이블을 추가해봅니다. 상품의 가격은 언제나 변할 수 있습니다. 그러므로 가격 변화를 관리하는 테이블을 구현해야 합니다.
◦
아래와 같이 상품가격을 관리하면 현재 적용되는 가격이나 특정 시점의 가격을 가져오는 과정이 제법 번잡할 수 있습니다.
◦
그러므로 상품가격테이블에 ‘최종가격여부’ 컬럼이나 ‘가격종료일자’ 추가를 고려할 수 있습니다.
오늘의 설명은 여기까지입니다. ERD는 dbdiagram을 사용했습니다. 전문적인 모델을 하기에는 기능이 부족할 수 있겠지만, 나쁘진 않네요.
