Mô hình dữ liệu phân phối hàng tạp hóa

Nếu có một cách để đặt hàng tạp hóa trực tuyến, tại sao không sử dụng nó? Bài viết này kiểm tra mô hình dữ liệu đằng sau hệ thống giao hàng của một cửa hàng tạp hóa.

Chúng tôi vẫn có cảm giác đặc biệt khi hái một thứ gì đó trong vườn và sau đó chuẩn bị ngay - nhưng đó không phải là điều chúng tôi có thể làm thường xuyên. Tốc độ nhanh ngày nay không cho phép điều đó. Trên thực tế, đôi khi nó thậm chí không cho phép chúng tôi đến cửa hàng để “chọn” hàng tạp hóa của mình. Vì vậy, việc tiết kiệm thời gian và sử dụng một ứng dụng để đặt hàng những thứ chúng ta cần là rất hợp lý. Đơn đặt hàng của chúng tôi sẽ chỉ hiển thị tại nhà của chúng tôi. Có thể chúng tôi sẽ không có được cảm giác đặc biệt như mới hái, nhưng sẽ có thức ăn trên bàn của chúng tôi.

Mô hình dữ liệu đằng sau một ứng dụng như vậy là chủ đề của bài viết hôm nay.

Chúng ta cần gì cho Mô hình dữ liệu phân phối hàng tạp hóa?

Ý tưởng của mô hình này là một ứng dụng (web, thiết bị di động hoặc cả hai) sẽ cho phép khách hàng đã đăng ký tạo đơn đặt hàng (bao gồm các sản phẩm từ cửa hàng của chúng tôi). Sau đó đơn hàng này sẽ được giao cho khách hàng. Rõ ràng là chúng tôi sẽ lưu trữ dữ liệu khách hàng và danh sách tất cả các sản phẩm có sẵn để hỗ trợ việc này.

Khách hàng có thể đặt nhiều đơn hàng bao gồm các mặt hàng khác nhau với số lượng khác nhau. Khi nhận được đơn đặt hàng của khách, nhân viên cửa hàng sẽ được thông báo để họ có thể tìm và đóng gói các mặt hàng cần thiết. (Điều này có thể yêu cầu một hoặc nhiều thùng chứa.) Cuối cùng, các thùng chứa sẽ được phân phối cùng nhau hoặc riêng biệt.

Trong chính ứng dụng, khách hàng và nhân viên có thể chèn ghi chú và xếp hạng cho bên kia sau khi việc giao hàng đã được thực hiện.

Mô hình dữ liệu

Mô hình dữ liệu bao gồm ba lĩnh vực chủ đề:

• Items & units
• Customers & employees
• Orders

Chúng tôi sẽ trình bày từng lĩnh vực chủ đề theo thứ tự được liệt kê.

Phần 1:Các hạng mục và đơn vị

Chúng ta sẽ bắt đầu với Items & units môn học. Mặc dù đây là một phần nhỏ trong mô hình của chúng tôi, nhưng nó chứa hai bảng rất quan trọng.

unit bảng lưu trữ thông tin về các đơn vị chúng tôi sẽ chỉ định cho bất kỳ mặt hàng nào trong khoảng không quảng cáo của chúng tôi. Đối với mỗi giá trị trong bảng này, chúng tôi sẽ lưu trữ hai giá trị DUY NHẤT:unit_name (ví dụ:“kilogram”) và unit_short (ví dụ:“kg”). Lưu ý rằng unit_short là chữ viết tắt của unit_name .

Bảng thứ hai trong chủ đề này là item . Nó liệt kê tất cả các mặt hàng chúng tôi có trong kho. Đối với mỗi mặt hàng, chúng tôi sẽ lưu trữ:

• item_name - Tên DUY NHẤT mà chúng tôi sẽ sử dụng cho mặt hàng đó.
• price - Giá hiện tại của mặt hàng đó.
• item_photo - Một liên kết đến ảnh của mặt hàng này.
• description - Mô tả văn bản bổ sung của mặt hàng.
• unit_id - Tham chiếu unit từ điển và biểu thị đơn vị được sử dụng để đo lường mục đó.

Xin lưu ý rằng tôi đã bỏ qua một số điều ở đây. Điều quan trọng nhất là cờ biểu thị nếu một mặt hàng tồn kho hiện đang được chào bán. Tại sao chúng ta không có cái này? Nó sẽ yêu cầu ít nhất một trường bổ sung (cờ) cũng như một bảng khác (để lưu trữ các thay đổi lịch sử cho mỗi mục). Để đơn giản hóa mọi thứ, tôi đã giả định rằng tất cả các mặt hàng chúng tôi có trong kho cũng có thể bán được.

Điều quan trọng thứ hai tôi đã bỏ qua là theo dõi tình trạng kho hàng. Giả định của tôi là chúng tôi vận chuyển mọi thứ từ một kho trung tâm và chúng tôi sẽ luôn có sẵn các mặt hàng. Nếu chúng tôi không có mặt hàng, chúng tôi sẽ chỉ thông báo cho khách hàng và cung cấp cho họ một mặt hàng tương tự để thay thế.

Phần 2:Khách hàng và Nhân viên

Customers & employees vùng chủ đề chứa tất cả các bảng cần thiết để lưu trữ dữ liệu khách hàng và nhân viên. Chúng tôi sẽ sử dụng thông tin này trong phần trung tâm của mô hình của chúng tôi.

employee bảng chứa danh sách tất cả các nhân viên có liên quan (ví dụ:người đóng gói hàng tạp hóa và người giao hàng). Đối với mỗi nhân viên, chúng tôi sẽ lưu trữ first_name của họ và last_name và một employee_code DUY NHẤT giá trị. Mặc dù cột id cũng là DUY NHẤT (và khóa chính của bảng này), nhưng tốt hơn nên sử dụng một giá trị thực khác, trong thế giới thực (ví dụ:số VAT) làm mã định danh nhân viên. Do đó, chúng ta có employee_code trường.

Lưu ý rằng tôi chưa bao gồm chi tiết đăng nhập của nhân viên, vai trò của nhân viên và cách theo dõi lịch sử vai trò. Có thể dễ dàng thêm chúng vào, như được mô tả trong bài viết này.

Bây giờ chúng tôi sẽ thêm khách hàng vào mô hình của mình. Điều này sẽ cần thêm hai bảng.

Khách hàng sẽ được phân đoạn theo địa lý, vì vậy chúng tôi sẽ cần một city từ điển. Đối với mỗi thành phố mà chúng tôi cung cấp dịch vụ giao hàng tạp hóa, chúng tôi sẽ lưu trữ city_name và postal_code . Cùng với nhau, chúng tạo thành khóa thay thế của bảng này.

Khách hàng chắc chắn là phần quan trọng nhất của mô hình này; họ là những người khởi xướng toàn bộ quá trình. Chúng tôi sẽ lưu trữ danh sách đầy đủ các khách hàng của mình trong customer bàn. Đối với mỗi khách hàng, chúng tôi sẽ lưu trữ những điều sau:

• first_name - Tên đầu tiên của khách hàng.
• last_name - Họ của khách hàng.
• user_name - Tên người dùng mà khách hàng đã chọn khi thiết lập tài khoản của họ.
• password - Mật khẩu mà khách hàng đã chọn khi thiết lập tài khoản của họ.
• time_inserted - Thời điểm bản ghi này được chèn vào cơ sở dữ liệu.
• confirmation_code - Một mã được tạo ra trong quá trình đăng ký mã. Mã này sẽ được sử dụng để xác minh địa chỉ email của họ.
• time_confirmed - Khi xác nhận email xảy ra.
• contact_email - Địa chỉ email của khách hàng, địa chỉ này cũng được sử dụng làm email xác nhận.
• contact_phone - Số điện thoại của khách hàng.
• city_id - ID của city nơi khách hàng cư trú.
• address - Địa chỉ nhà riêng của khách hàng.
• delivery_city_id - ID của city nơi mà đơn đặt hàng của khách hàng sẽ được giao.
• delivery_address - Địa chỉ giao hàng ưu tiên. Xin lưu ý rằng địa chỉ này có thể (nhưng không nhất thiết phải giống) với địa chỉ nhà riêng của khách hàng.

Phần 3:Đơn hàng

Phần trung tâm và quan trọng nhất của mô hình này là Orders môn học. Tại đây, chúng tôi sẽ tìm thấy tất cả các bảng cần thiết để đặt hàng và theo dõi các mặt hàng cho đến khi chúng được giao cho khách hàng.

Toàn bộ quy trình bắt đầu khi khách hàng đặt hàng. Danh sách mọi đơn hàng đã từng được đặt nằm trong placed_order bàn. Tôi đã cố ý sử dụng tên này chứ không phải "order" vì order là một từ khóa dành riêng cho SQL. Đối với mỗi đơn đặt hàng, chúng tôi sẽ lưu trữ:

• customer_id - ID của customer đã đặt hàng này.
• time_placed - Dấu thời gian khi đơn đặt hàng này được đặt.
• details - Tất cả các chi tiết liên quan đến đơn đặt hàng đó, ở định dạng văn bản không có cấu trúc.
• delivery_city_id - Tham chiếu đến city nơi mà đơn đặt hàng này sẽ được giao.
• delivery_address - Địa chỉ nơi đơn đặt hàng này sẽ được giao.
• grade_customer &grade_employee - Điểm do nhân viên và khách hàng đưa ra sau khi đơn hàng được hoàn thành. Cho đến thời điểm đó, thuộc tính này chứa giá trị NULL. Điểm của khách hàng cho biết mức độ hài lòng của họ với dịch vụ của chúng tôi; cấp độ của nhân viên cung cấp cho chúng tôi thông tin về những điều sẽ xảy ra vào lần tiếp theo khi khách hàng đặt hàng.

Trong quá trình đặt hàng, khách hàng sẽ chọn một hoặc nhiều mặt hàng. Đối với mỗi mặt hàng, họ sẽ xác định số lượng mong muốn. Danh sách tất cả các mục liên quan đến từng đơn đặt hàng được lưu trữ trong order_item bàn. Đối với mỗi bản ghi trong bảng này, chúng tôi sẽ lưu trữ các ID cho đơn hàng có liên quan (placed_order_id ), item (item_id ), số lượng mong muốn và price khi đơn đặt hàng này được đặt.

Ngoài cái gì họ muốn được giao, khách hàng cũng sẽ xác định thời gian giao hàng mong muốn của họ . Đối với mỗi đơn đặt hàng, chúng tôi sẽ tạo một bản ghi trong delivery bàn. Điều này sẽ ghi lại delivery_time_planned và chèn các ghi chú văn bản bổ sung. placed_order_id thuộc tính cũng sẽ được xác định khi bản ghi này được chèn vào. Hai thuộc tính còn lại sẽ được xác định khi chúng tôi chỉ định giao hàng đó cho một nhân viên (employee_id ) và khi đơn đặt hàng được giao (delivery_time_actual ).

Mặc dù có vẻ như chúng tôi sẽ chỉ giao một lần cho mỗi đơn đặt hàng, nhưng điều đó có thể không phải lúc nào cũng đúng như vậy. Chúng tôi có thể cần thực hiện hai hoặc nhiều lần giao hàng cho mỗi đơn hàng và đó là lý do chính tại sao tôi chọn đặt dữ liệu giao hàng vào một bảng mới.

Khi chúng tôi bắt đầu xử lý một đơn đặt hàng, nhân viên sẽ đóng gói các mặt hàng trong một hoặc nhiều hộp. Mỗi box sẽ được định nghĩa BẤT NGỜ bởi box_code của nó và sẽ được chỉ định cho một lần giao hàng (delivery_id ). Chúng tôi cũng sẽ lưu trữ ID của nhân viên đã chuẩn bị hộp đó.

Mỗi hộp sẽ chứa một hoặc nhiều mục. Do đó, trong item_in_box bảng, chúng tôi sẽ cần lưu trữ các tham chiếu đến box bảng (box_id ) và item bảng (item_id ), cũng như số lượng được đặt trong hộp đó. Thuộc tính cuối cùng, is_replacement , biểu thị nếu một mặt hàng là vật thay thế cho một mặt hàng khác. Chúng ta có thể mong đợi rằng một nhân viên sẽ liên hệ với khách hàng trước khi cho một mặt hàng thay thế vào hộp. Một kết quả của hành động đó có thể là khách hàng đồng ý với mặt hàng thay thế; khác có thể là hủy toàn bộ đơn đặt hàng.

Ba bảng còn lại trong mô hình có liên quan chặt chẽ đến trạng thái và nhận xét.

Đầu tiên, chúng tôi sẽ lưu trữ tất cả các trạng thái có thể có trong status_catalog . Mỗi trạng thái được xác định BẤT NGỜ bởi status_name của nó . Chúng ta có thể mong đợi các trạng thái như “đơn hàng đã tạo”, “đơn hàng đã đặt”, “hàng đã đóng gói”, “đang vận chuyển” và “đã giao”.

Các trạng thái sẽ được chỉ định cho các đơn đặt hàng tự động (sau khi một số phần của quy trình được hoàn thành) hoặc trong một số trường hợp, theo cách thủ công (ví dụ:nếu có vấn đề với đơn đặt hàng). Tất cả các trạng thái đơn đặt hàng có sẵn được lưu trữ trong order_status bàn. Bên cạnh các khóa ngoại từ hai bảng (status_catalog và placed_order ), chúng tôi sẽ lưu trữ dấu thời gian thực khi trạng thái này được chỉ định (status_time ) và mọi details bổ sung ở dạng văn bản.

Bảng cuối cùng trong mô hình này là notes bàn. Ý tưởng đằng sau bảng này là chèn tất cả các nhận xét bổ sung liên quan đến một đơn hàng nhất định (placed_order_id ). Nhận xét có thể được chèn bởi nhân viên hoặc khách hàng. Đối với mỗi bản ghi, chỉ một trong số employee_id hoặc customer_id các trường sẽ chứa một giá trị; cái kia sẽ là NULL. Chúng tôi sẽ lưu trữ thời điểm khi ghi chú này được đưa vào hệ thống (note_time ) và note_text .

Bạn sẽ thực hiện những thay đổi nào đối với Mô hình dữ liệu phân phối hàng tạp hóa?

Hôm nay, chúng ta đã thảo luận về một mô hình dữ liệu có thể hỗ trợ các ứng dụng giao hàng tạp hóa trên web và di động - cả từ phía khách hàng và từ quan điểm của nhân viên. Như đã đề cập trong bài viết này, có rất nhiều cách để cải thiện mô hình này. Cảm thấy tự do để thêm các đề xuất của bạn. Hãy cho chúng tôi biết bạn sẽ thêm gì vào mô hình này hoặc xóa khỏi nó. Hoặc có thể bạn sẽ tổ chức cấu trúc này hoàn toàn khác. Hãy cho chúng tôi biết trong phần bình luận!