[Project] orderheader와 orderItem을 나누는 이유

📌 개인적인 공간으로 공부를 기록하고 복습하기 위해 사용하는 블로그입니다.
정확하지 않은 정보가 있을 수 있으니 참고바랍니다 :😸
[틀린 내용은 댓글로 남겨주시면 복받으실거에요]

---

ERP 시스템에서 주문 헤더와 주문 아이템을 나누는 이유

이번 ERP 프로젝트를 진행하면서, 팀원들과 함께 데이터베이스 설계를 하던 중
주문 헤더(t_order_headers)와 주문 아이템(t_order_items)을 왜 나누는지에 대한 궁금증이 생겼다.
이게 생소한 단어를 자꾸 사용하다 보니, 갑자기 아 이게 뭐였더라 하면서 자꾸 헷갈리게 되고
특히, 아이템은 마스터에서 이름만 참조하는 방식이기 때문에 더 헷갈렸을지도 모른다.
또 Order는 내가 구현하기로 했기 때문에 더더욱 정리를 잘하고 넘어가야 할 것 같아서
왜 이 두 테이블을 나누는지, 어떤 장점이 있는지에 대해 정리해봤다.

1. 주문 헤더(t_order_headers)란?

t_order_headers 테이블은 주문 전체에 대한 정보를 담고 있는 테이블이다. 주문 번호, 주문일, 주문을 요청한 사람, 그리고 주문 상태 등의 기본적인 정보가 여기에 저장된다.

• 주문 ID: 각 주문을 고유하게 식별할 수 있는 번호.
• 주문 날짜: 해당 주문이 언제 요청되었는지 기록.
• 구매자 정보: 누가 주문을 했는지.
• 주문 상태: 예를 들어, 생성 중, 출하 완료 등의 상태를 저장.

• 예시

  ORDERID	REQUESTDATE	EMPLOYEEID	BUYERCD	ORDERSTATUS	CREATEDAT
  1	2023-09-01	1001	B001	생성중	2023-09-01 10:00
  2	2023-09-02	1002	B002	출하완료	2023-09-02 14:00

이 테이블은 주문에 대한 전반적인 정보를 관리하며, 하나의 주문에 대해 하나의 헤더가 존재한다.

2. 주문 아이템(t_order_items)이란?

t_order_items 테이블은 주문에 포함된 개별 아이템에 대한 세부 정보를 담고 있다. 하나의 주문에 여러 개의 제품이 포함될 수 있기 때문에, 각 제품의 정보는 아이템 테이블에 저장된다.

• 아이템 코드: 주문한 아이템이 무엇인지 나타내는 코드.
• 수량: 해당 아이템이 몇 개 주문되었는지.
• 단가: 각 아이템의 가격.
• 시작/종료 날짜: 아이템에 대한 서비스나 제공 기간 등이 저장될 수 있다.

• 예시

  ORDERITEMID	ITEMCD	UNIT	UNITPRICE	QTY	ORDERID	STARTDATE	ENDDATE
  1	I001	EA	100.00	10	1	2023-09-01	2023-09-10
  2	I002	EA	200.00	5	1	2023-09-01	2023-09-10
  3	I003	EA	50.00	20	2	2023-09-02	2023-09-12

여기서 중요한 것은, 한 주문에 여러 개의 아이템이 있을 수 있다는 점이다. 예를 들어, ORDERID = 1의 주문에는 두 개의 아이템(ITEMCD = I001, ITEMCD = I002)이 포함되어 있다.

3. 주문 헤더와 아이템을 나누는 이유

1. 정규화와 데이터 중복 최소화

   데이터베이스 설계에서 중요한 원칙 중 하나는 정규화(Normalization)이다. 이를 통해 데이터의 중복을 최소화하고, 효율적인 저장 방식을 구현할 수 있다.

   • 만약 t_order_headers와 t_order_items 테이블을 하나로 합친다면, 하나의 주문에 여러 개의 아이템이 있을 때 헤더 정보가 반복적으로 저장된다. 이렇게 되면 주문 정보가 불필요하게 중복되고, 저장 공간이 낭비될 뿐만 아니라 데이터의 일관성 유지가 어려워진다.
   • 이를 해결하기 위해 헤더 정보와 아이템 정보를 분리하면, 헤더 정보는 한 번만 저장되고, 아이템 정보는 각각의 제품에 대해 별도로 관리할 수 있게 된다. 덕분에 데이터 중복을 피할 수 있고, 나중에 데이터를 수정하거나 유지보수할 때도 더 쉽다.

2. 유연성과 확장성

   각각의 주문은 여러 개의 아이템을 포함할 수 있기 때문에, 주문과 아이템 간에는 1 : N관계가 성립된다.

   주문 헤더와 아이템을 나눔으로써, 한 주문에 여러 개의 아이템을 동적으로 추가하거나 삭제할 수 있는 유연성을 확보할 수 있다.

   • 예를 들어, 하나의 주문에 10개의 아이템을 추가하는 상황에서, 이 구조는 데이터를 더욱 효율적으로 관리할 수 있게 도와준다. 주문의 기본 정보는 그대로 유지하면서, 필요에 따라 아이템을 추가하거나 수정할 수 있기 때문이다.
   • 또한, 이렇게 테이블을 나눠서 관리하면 데이터를 조회하거나 처리할 때도 더 빠르고 정확하다. 필요에 따라 헤더 정보만 조회하거나, 특정 주문에 대한 아이템 정보만 따로 확인할 수 있다.

4. 관계

• t_order_headers (1) ↔ t_order_items (N): 한 주문에 여러 아이템이 포함되기 때문에, 이 두 테이블은 1 : N 구조로 설계된다. 이를 통해 하나의 주문에서 여러 아이템을 손쉽게 관리할 수 있다.
• t_order_items 테이블의 ORDERID는 외래 키로, 어떤 주문에 속하는 아이템인지 구분하는 데 사용된다.

---

이번 프로젝트에서 주문 헤더와 주문 아이템을 분리한 이유를 이렇게 정리해봤다.
용어는 언제 익숙해질지 모르겠지만 여기서 사용하는 용어에 대해 익숙해질 필요가 있는 것 같다. 그리고 데이터를 효율적으로 관리하면서도, 유연한 확장성을 유지하는 것이 이 설계의 핵심이라는 걸 다시 한 번 느끼게 된다.
특히 여러 아이템을 관리해야 하는 상황에서는 이 방식이 훨씬 더 유리하다는 점에서 ERP 시스템 설계의 중요성을 실감했다.

Project 카테고리 내 다른 글 보러가기