Lập mô hình cơ sở dữ liệu để ghi lại doanh số bán hàng. Phần 1

Lưu trữ dữ liệu bán hàng đúng cách và sau đó kết hợp nó có thể dẫn đến việc tạo ra một mô hình dự đoán với tỷ lệ chính xác cao. Trong phần này và một số bài viết tiếp theo, chúng tôi sẽ phân tích thiết kế cơ sở dữ liệu để ghi lại doanh số bán hàng.

Mọi người đều sống bằng cách bán thứ gì đó.

Robert Louis Stevenson

Trong thế giới ngày nay, bán sản phẩm là phổ biến. Và những nhân viên bán hàng có quyền truy cập vào các công cụ mạnh mẽ tận dụng dữ liệu lịch sử để phân tích xu hướng và cho phép doanh nghiệp điều chỉnh chiến lược kinh doanh cho phù hợp sẽ có lợi thế hơn so với đối thủ cạnh tranh của họ. Có rất nhiều thông số có thể ảnh hưởng đến kết quả của công ty:tình hình kinh tế toàn cầu hiện tại, vị trí của khách hàng, tuổi tác, tình trạng hôn nhân và vật chất cũng như lịch sử của các mối liên hệ trước đây hoặc bán hàng cho khách hàng.

Chúng ta sẽ bắt đầu với một ví dụ rất đơn giản:mô hình cơ sở dữ liệu về bán hàng trong quán cà phê . Trong các bài viết tiếp theo, chúng tôi sẽ mở rộng mô hình này sang việc bán sản phẩm ở các chi nhánh khác.

Mô hình bán hàng

Trong bài viết này, chúng tôi sẽ chỉ phân tích một phần của mô hình có chứa dữ liệu bán hàng với các phần khác bị thiếu.

Chúng tôi vẫn có kết nối với các bảng bị thiếu và chúng tôi sẽ xem mô hình như một hộp đen với giả định rằng điều sau đây là chính xác cho bảng sale :

• user_has_role_id tham chiếu đến id trong user_has_role (như đã trình bày trong bài viết trước của tôi trong phần “Đã thêm thành phần thời gian”) và lưu trữ thông tin về người dùng đã tạo hồ sơ bán hàng

Mô hình này cho phép chúng tôi tạo hồ sơ bán hàng với nhiều mặt hàng. Mỗi mục liên quan đến một sản phẩm từ danh mục của chúng tôi. Thời điểm khi chúng tôi tạo ra một đợt bán hàng có thể khác với thời điểm khi món hàng đó được thanh toán. Ví dụ, đối với một tách cà phê, những khoảnh khắc này sẽ khác nhau trong vài phút hoặc vài giờ. Nếu cửa hàng của chúng tôi bán thiết bị viễn thông, mức chênh lệch có thể là vài ngày, thậm chí có thể cả tháng.

Bảng

Hãy cùng xem định nghĩa bảng và giải thích mục đích cũng như cách sử dụng các thuộc tính.

Bảng quan trọng nhất trong mô hình là product . Nó được sử dụng để lưu trữ thông tin chi tiết về các sản phẩm mà chúng tôi sẽ cung cấp cho khách hàng của mình. Sản phẩm thường được giao cho khách hàng và thanh toán một lần, thường là vào thời điểm giao hàng. Ngoài ra, các sản phẩm thường là những vật thể vật chất như ô tô, điện thoại, gói đường hoặc tách cà phê.

Chúng ta sẽ nói về việc bán những thứ phi vật chất (dịch vụ) trong các bài viết tiếp theo.

Các thuộc tính trong product bảng là:

• name - tên của sản phẩm trong hệ thống
• price_per_unit - giá thành sản phẩm trên mỗi đơn vị (ví dụ:1 tách cà phê có giá 1,8 Euro, 1 ô tô có giá 17.500 Euro, 1 kg gạo có giá 2 Euro)
• basic_unit - đơn vị cơ sở khi chúng tôi đang bán một sản phẩm (ví dụ:mảnh, kg, lít)
• tax_percentage - phần trăm price_per_unit được tính dưới dạng thuế. Chúng tôi phải giả định rằng tỷ lệ phần trăm thuế sẽ không giống nhau cho tất cả các sản phẩm
• limited - trường này được đặt thành Đúng nếu chúng tôi có số lượng hạn chế trong kho và Sai nếu ngược lại (ví dụ:chúng tôi có thể đặt hàng bất kỳ số lượng nào chúng tôi cần cho cửa hàng của mình từ một nhà phân phối)
• in_stock - if limited =True thuộc tính này hiển thị số lượng chúng tôi có sẵn để bán
• active_for_sale - nếu thuộc tính này Sai thì chúng tôi hiện không cung cấp sản phẩm đó để bán, nếu không, chúng tôi có thể cung cấp sản phẩm đó cho khách hàng

Chúng tôi có thể nhận được danh sách các sản phẩm mà chúng tôi có thể cung cấp cho khách hàng với truy vấn sau:

 CHỌN product.id, product.price_per_unit, product.basic_unit, product.limited, product.in_stockFROM productWHERE product.active_for_sale =TrueAND (product.limited =False HOẶC (product.limited =Đúng và product.in_stock> 0)) 

Bảng sale_status chỉ là một từ điển đơn giản chứa tất cả các trạng thái mà một đợt bán hàng có thể có trong hệ thống (ví dụ:“biên lai đã phát hành”, “biên nhận đã thanh toán”).

Các thuộc tính trong bảng và ý nghĩa của chúng là:

• time_created - thời gian tạo hồ sơ bán hàng trong hệ thống (ví dụ:thời gian tự động tạo hồ sơ khi chúng tôi tạo một lượt bán cà phê tại quán cà phê của mình hoặc thời gian được thêm theo cách thủ công nếu chúng tôi muốn)
• time_paid - nói chung, chúng tôi có thể mong đợi rằng một số doanh số sẽ được thanh toán trong vài ngày hoặc thậm chí một tháng sau khi tạo (ví dụ:nếu chúng tôi cung cấp phần mềm và tạo biên nhận, chúng tôi có thể đợi đến 90 ngày để được thanh toán ở một số quốc gia, nếu mọi thứ trôi qua luật)
• sale_amount - số tiền ban đầu dự định thanh toán cho khách hàng
• sale_amount_paid - số tiền mà khách hàng đã thực trả. Nó có thể là trống vì tại thời điểm chúng tôi tạo biên nhận, chúng tôi không phải lúc nào cũng có thông tin này
• tax_amount - tổng tất cả các khoản thuế cho các mặt hàng trên biên lai đó
• sale_status_id - tham chiếu đến sale_status bảng
• user_has_role_id - tham chiếu đến người dùng và vai trò của họ tại thời điểm họ nhập biên nhận vào hệ thống

Chúng tôi có thể nhận được số tiền đã phát hành và đã thanh toán (theo time_create) trong một khoảng thời gian với truy vấn như sau:

 CHỌN SUM (sale.sale_amount) AS amount_issued, SUM (sale.sale_amount_pay 
 
 Để nhận được số tiền chính xác được thanh toán trong một khoảng thời gian, chúng ta phải sử dụng một truy vấn như sau:
 

 
 CHỌN SUM (sale.sale_amount_paid) NHƯ số tiền đã trả từ saleWHERE sale.time_paid> =@start_time VÀ sale.time_paid <=@end_time; 
 
 
 Truy vấn bên dưới sẽ tính toán số tiền đã phát hành và đã thanh toán trong một khoảng thời gian với ngày phát hành và ngày thanh toán được kiểm tra riêng biệt:
 

 
 CHỌN SUM (TRƯỜNG HỢP KHI sale.time_create> =@start_time VÀ sale.time_create <=@end_time THÌ sale.sale_amount END) AS amount_issued, SUM (TRƯỜNG HỢP KHI sale.time_paid> =@start_time VÀ sale.time_paid <=@ end_time THEN sale.sale_amount_paid END) NHƯ số lượng_trả tiền TỪ bán hàng 
 
 
 Trong tất cả các ví dụ @start_time và @end_time là các biến chứa thời gian bắt đầu và thời gian kết thúc của khoảng thời gian mà chúng tôi muốn kiểm tra SUM đã phát hành và thanh toán. 
 
  
 

 Bảng sale_item kết nối sản phẩm và bán hàng. Tất nhiên, chúng tôi phải giả định rằng chúng tôi sẽ có  nhiều mục  trên một biên nhận, vì vậy chúng ta cần bảng này có mối quan hệ nhiều-nhiều. 
 

 Các thuộc tính và ý nghĩa của chúng là:
 
 
 quantity_sold - số lượng sản phẩm đã được bán và được tính phí khi bán / nhận đó (ví dụ:3 cà phê) 
 
 price_per_unit - cùng giá trị với product.price_per_unit tại thời điểm giao dịch được tạo. Chúng tôi phải lưu nó vì price_per_unit trong product bảng có thể thay đổi theo thời gian 
 
 price - sản phẩm của quantity_sold và price_per_unit; một phần dư thừa nhỏ giúp chúng tôi tránh tính toán này trong các truy vấn. Nói chung, tổng giá của tất cả các mặt hàng thuộc cùng một đợt giảm giá phải bằng sale.sale_amount 
 
 tax_amount - số thuế cho mặt hàng đó khi nhận được 
 
 sale_id - id bán hàng thuộc về mặt hàng này 
 
 product_id - id sản phẩm liên quan đến mặt hàng này 
 
 

 Giờ đây, chúng tôi có thể dễ dàng lập một báo cáo đơn giản, chúng tôi đã bán được bao nhiêu sản phẩm / dịch vụ trong kỳ và ở mức giá nào. 
 

 
 CHỌN product.name, SUM (sale_item.quantity_sold) AS số lượng, SUM (sale_item.price) AS priceFROM giảm giá, sale_item, productWHERE sale.id =sale_item.sale_idAND sale_item.product_id =product.idAND sale.time_create> =@ start_time VÀ sale.time_create <=@end_timeGROUP BY product.id