Mô hình dữ liệu bữa tiệc dành cho trẻ em

Tổ chức tiệc cho trẻ em không phải là một công việc dễ dàng:mọi thứ phải được lên kế hoạch và bàn giao hoàn hảo. Nếu không, sự hỗn loạn sẽ xảy ra. Điều đó phụ thuộc vào người lớn - cụ thể hơn là những người lên kế hoạch cho bữa tiệc - đảm nhận mọi việc và thực hiện đúng cách.

Có cách nào tốt hơn để làm điều này ngoài việc sắp xếp mọi thứ trong cơ sở dữ liệu không? Chúng tôi không nghĩ vậy!

Các bữa tiệc của trẻ em khác nhau rất nhiều. Một số đơn giản, chẳng hạn như tiệc sinh nhật chỉ bao gồm lời mời, thức ăn (đồ ăn nhẹ, đồ uống và bánh ngọt) và có thể có chú hề hoặc ảo thuật gia để giải trí cho bọn trẻ. Các bên khác phức tạp hơn nhiều. Họ có thể yêu cầu một chuyến đi ra khỏi thị trấn, chỗ ngủ và nhiều hoạt động khác. Đảng càng phức tạp, càng ít chỗ cho sai lầm. Mặc dù một chú hề đến muộn 10 phút không phải là vấn đề lớn, nhưng không ai muốn cùng một nhóm trẻ buồn chán chờ một chuyến xe buýt trễ hai giờ!

Hãy xem mô hình dữ liệu có thể làm gì để giúp những người lập kế hoạch tổ chức tiệc luôn có tổ chức.

Chúng ta cần gì trong Mô hình dữ liệu của mình?

Giả sử chúng ta điều hành một doanh nghiệp lập kế hoạch tổ chức tiệc. Chúng tôi sẽ có một danh sách các dịch vụ mà chúng tôi cung cấp cho khách hàng. Những dịch vụ này có thể do chúng tôi cung cấp hoặc chúng tôi có thể sử dụng các đối tác (ví dụ:chúng tôi thuê chú hề).

Chúng tôi kết hợp các dịch vụ này và cung cấp cho khách hàng dưới dạng gói tiệc. Mỗi gói có điểm bắt đầu và điểm kết thúc, hoặc lịch trình. Điều này không chỉ bao gồm bản thân bữa tiệc mà còn cả việc sắp xếp bữa tiệc và dọn dẹp sau đó. Chúng tôi cũng có thể có nhiều địa điểm (ví dụ:một bữa tiệc bắt đầu với bánh pizza tại một nhà hàng, sau đó di chuyển đến bãi biển để bơi).

Chúng tôi cũng sẽ cần liên hệ các hoạt động với nhân viên, theo dõi tiến trình của các bên và tính phí cho các dịch vụ của chúng tôi. Hãy xem cách này được thực hiện như thế nào.

Mô hình dữ liệu của bữa tiệc trẻ em

Mô hình dữ liệu về bữa tiệc của trẻ em của chúng tôi bao gồm bốn lĩnh vực chủ đề:

• Countries & cities
• Partners & services
• Employees & roles
• Party

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:Quốc gia và Thành phố

Chủ đề này chỉ chứa hai bảng. Chúng không dành riêng cho mô hình này, nhưng chúng tôi sẽ sử dụng chúng trong các lĩnh vực chủ đề khác.

Chúng tôi có thể mong đợi hoạt động ở nhiều thành phố và thậm chí có thể ở một số quốc gia. Do đó, chúng tôi sẽ cần tham khảo các thành phố khác nhau. Điều này sẽ giúp chúng tôi theo dõi vị trí của các bên cũng như dịch vụ mà chúng tôi cung cấp tại mỗi địa điểm.

country từ điển chỉ chứa country_name DUY NHẤT giá trị. Đối với mỗi city , chúng tôi sẽ lưu trữ sự kết hợp DUY NHẤT của postal_code - city_name - country_id .

Phần 2:Đối tác và Dịch vụ

Tiếp theo, hãy trình bày chi tiết các dịch vụ mà chúng tôi sẽ cung cấp cho khách hàng của mình.

Danh sách tất cả các dịch vụ có thể có được lưu trữ trong service từ điển. Nó chỉ chứa service_name DUY NHẤT thuộc tính.

Trong mô hình dữ liệu này, tất cả các dịch vụ đều do các đối tác cung cấp. Ngay cả khi công ty của chúng tôi thực sự cung cấp dịch vụ, chúng tôi sẽ coi nó như một partner dịch vụ (và chúng tôi là đối tác). Từ điển đối tác sẽ lưu trữ tất cả các đối tác mà chúng tôi hợp tác, bao gồm cả chúng tôi. Đối với mỗi đối tác, chúng tôi sẽ lưu trữ một partner_name DUY NHẤT . details thuộc tính lưu trữ bất kỳ chi tiết bổ sung nào liên quan đến đối tác đó bằng cách sử dụng định dạng không có cấu trúc hoặc có cấu trúc (ví dụ:sử dụng các cặp tên-giá trị được phân tách bằng dấu phân tách xác định trước).

provides bảng là bảng cuối cùng và quan trọng nhất trong phần này. Đối với mỗi bản ghi, chúng tôi sẽ lưu trữ:

• partner_id - partner cung cấp một dịch vụ.
• service_id - service đối tác này cung cấp.
• city_id - Tham khảo city nơi dịch vụ này được cung cấp bởi đối tác đó.
• date_from - Ngày đối tác bắt đầu cung cấp dịch vụ đó.
• date_to - Ngày đối tác ngừng cung cấp dịch vụ đó. Giá trị này có thể là NULL nếu mối quan hệ dịch vụ - đối tác đó vẫn đang diễn ra.
• details - Tất cả các chi tiết bổ sung liên quan đến dịch vụ đó, chẳng hạn như mô tả dịch vụ, giá cả, v.v. Chúng tôi có thể mong đợi tất cả các chi tiết sẽ ở định dạng văn bản có cấu trúc, sử dụng các cặp khóa-giá trị.

Sự kết hợp của partner_id - service_id - city_id - date_from tạo thành khóa DUY NHẤT trong bảng này. Khi chúng tôi nhập một bản ghi mới, chúng tôi nên kiểm tra xem nó không trùng lặp với bất kỳ bản ghi hiện có nào.

Phần 3:Nhân viên và vai trò

Trước khi chuyển sang phần trung tâm và quan trọng nhất của mô hình, chúng ta cần xem xét các bảng liên quan đến nhân viên và vai trò của họ.

Bảng trung tâm trong lĩnh vực chủ đề này là employee bàn. Đối với mỗi nhân viên, chúng tôi sẽ lưu trữ first_name của họ , last_name , user_name và password . Họ sẽ sử dụng hai thuộc tính cuối cùng này để truy cập ứng dụng của chúng tôi.

Danh sách tất cả các vai trò có thể có được lưu trữ trong role từ điển. Mỗi vai trò được định nghĩa BẤT NGỜ bởi role_name của nó . Các vai trò liên quan đến các hành động mà mỗi nhân viên thực hiện trong một bữa tiệc. Do đó, chúng ta có thể mong đợi các giá trị như "quản lý bữa tiệc" hoặc "trợ lý" ở đây.

Có thể chỉ định vai trò cho nhân viên theo has_role bàn. employee_id - role_id cặp sẽ biểu thị vai trò tích cực mà mỗi nhân viên có tại thời điểm đó.

Phần 4:Bên

Party môn học là phần trung tâm của mô hình này. Chúng tôi sẽ sử dụng nó để liên kết các bảng từ các lĩnh vực chủ đề khác và chúng tôi cũng sẽ có một số thông tin mới ở đây.

Bảng trung tâm ở đây là party bàn. Đối với mỗi bên, chúng tôi sẽ lưu trữ:

• city_id - city nơi bữa tiệc sẽ diễn ra.
• client_id - client bữa tiệc này được tổ chức cho.
• details - Mô tả chi tiết bằng văn bản về bữa tiệc.
• start_time_planned và end_time_planned - Thời gian chúng tôi đã lên lịch cho bữa tiệc này, bao gồm cả thiết lập và dọn dẹp.
• start_time_actual và end_time_actual - Thời gian thực tế bữa tiệc (và các dịch vụ liên quan) diễn ra.
• price_offered - Giá chúng tôi báo để tổ chức bữa tiệc này cho khách hàng này.
• time_offered - Khi đề nghị được đưa ra.
• price_paid - Số tiền thực tế mà khách hàng đã trả cho bữa tiệc này.
• time_paid - Khi thanh toán được thực hiện.

Mỗi bên liên quan đến một khách hàng. Chúng tôi đã tham chiếu đến client nhưng bây giờ chúng ta sẽ thấy những gì được lưu trữ ở đó. Tôi chỉ sử dụng dữ liệu cơ bản:client_name , chi tiết liên hệ (address , email , phone , mobile ), và bất kỳ chi tiết bổ sung nào ở định dạng văn bản.

Mỗi bên cũng sẽ có một danh sách các dịch vụ được liên kết với nó. Danh sách đó được lưu trữ trong service_included bàn. Đối với mỗi bản ghi, chúng tôi sẽ cần:

• party_id - Tham khảo party .
• service_id - Tham khảo service bao gồm trong bữa tiệc.
• provides_id - Tham khảo provider của dịch vụ đó, cũng như của chính dịch vụ đó. Thuộc tính này có thể là NULL, vì chúng tôi sẽ cập nhật nó khi chúng tôi chọn nhà cung cấp cụ thể.
• details - Bất kỳ chi tiết văn bản bổ sung nào liên quan đến dịch vụ đó ở bên đó.
• start_time_planned và end_time_planned - Thời gian dự kiến ​​mà dịch vụ sẽ được cung cấp trong bữa tiệc.

Chúng tôi cũng sẽ cần theo dõi tiến trình của mỗi bên. Chúng tôi sẽ sử dụng hai bảng để làm điều này.

status bảng sẽ liệt kê tất cả các trạng thái có thể được chỉ định cho một bên. Đối với mỗi bản ghi, chúng tôi sẽ lưu trữ một status_name DUY NHẤT và ba cờ:

• successful - Mọi việc diễn ra tốt đẹp chứ? Hay có vấn đề với dịch vụ của chúng tôi?
• paid - Bữa tiệc đã được thanh toán chưa?
• final - Đây có phải là trạng thái cuối cùng của bữa tiệc này không?

Chúng tôi sẽ chỉ định trạng thái cho các dịch vụ bằng cách thêm các bản ghi mới vào party_status bàn. Đối với mỗi bản ghi, chúng tôi sẽ lưu trữ các tham chiếu đến party và service bảng và timestamp khi trạng thái này được chỉ định.

Bảng cuối cùng trong mô hình của chúng tôi là invoice bàn. Nó không dành riêng cho mô hình này, nhưng chúng tôi cần một cấu trúc cơ bản để lưu trữ hóa đơn. Đối với mỗi hóa đơn, chúng tôi sẽ ghi:

• client_name - Tên khách hàng tại thời điểm xuất hóa đơn.
• party_id - party liên quan đến hóa đơn này.
• client_id - ID của client được lập hóa đơn.
• invoice_amount , discount , vat_amount , total_amount - Chi tiết tài chính của hóa đơn.
• time_issued - Khi hóa đơn này được phát hành hoặc thêm vào cơ sở dữ liệu.
• time_paid - Khi hóa đơn này được thanh toán.

Bạn sẽ làm gì với Mô hình dữ liệu này?

Mô hình này khá đơn giản, nhưng tôi thấy một số cách chúng ta có thể cải thiện nó. Bạn sẽ đề xuất những thay đổi nào? Có điều gì đó chúng ta có thể tổ chức khác không? Có thể chúng ta cần thêm hoặc bớt một tính năng. Vui lòng cho chúng tôi biết trong phần bình luận.