Mô hình dữ liệu tổ chức đám cưới

Đám cưới thường đi kèm với vui mừng và ăn mừng, với rất nhiều khách mời, đồ ăn, thức uống, âm nhạc và khiêu vũ. Nhưng tất cả những điều này không thể xảy ra nếu không có sự chuẩn bị và phối hợp thích hợp. Hãy cùng xem xét kỹ hơn cách lập mô hình dữ liệu có thể giúp chúng tôi tổ chức đám cưới tốt hơn để mọi thứ diễn ra suôn sẻ.

Cơ sở sơ bộ

Mặc dù hầu hết chúng ta đều biết về một lễ cưới thông thường trông như thế nào, nhưng không có gì khó khăn khi xem xét ngắn gọn một số khía cạnh có thể ảnh hưởng đến mô hình dữ liệu của chúng tôi.

Đối tác đám cưới

Mặc dù hầu hết các nền văn hóa truyền thống sẽ có nghi lễ giữa nam và nữ, hôn nhân đồng giới cũng diễn ra ở các xã hội khác. Mô hình dữ liệu của chúng tôi phải được thiết kế theo cách có thể đáp ứng được tất cả các khả năng.

Quy mô và độ phức tạp

Các lễ cưới khác nhau rất nhiều về quy mô, thời lượng và độ phức tạp của chúng. Một số là những dịp nhỏ, khiêm tốn, nhưng một số khác là những dịp kỷ niệm lớn. Ví dụ, ở Croatia, bạn có thể tổ chức một lễ cưới đơn giản, nơi một cặp đôi kết hôn tại tòa thị chính, trao nhẫn và lời thề trước khách mời của họ và tham dự bữa tối sau nghi lễ hoặc về nhà. Ở các quốc gia khác, đám cưới có thể khá phức tạp:chúng có thể liên quan đến tiệc độc thân / cử nhân, đàm phán, ăn tối, nhiều nghi lễ, v.v. Trong một số trường hợp, những buổi lễ này có thể kéo dài nhiều ngày và diễn ra ở một vài địa điểm khác nhau! Một lần nữa, mô hình dữ liệu của chúng tôi nên được chuẩn bị để xử lý những tình huống này.

Kết quả cuối cùng và chi phí

Trong hầu hết các trường hợp, cặp đôi kết hôn sau lễ kỷ niệm và nhận được hóa đơn cho tất cả các chi phí (tiền thuê nhà, thực phẩm và đồ uống, ban nhạc, v.v.). Họ có thể quyết định thuê một cơ quan để lo tất cả các chi phí này cho họ, hoặc họ có thể chọn tự mình xử lý tất cả. Dù bằng cách nào, chúng ta cũng nên tính đến những tình huống này.

Mô hình dữ liệu:Tổng quan

Mô hình dữ liệu của chúng tôi cho bài viết này bao gồm năm phần:

1. Vị trí
2. Đối tác, Sản phẩm và Dịch vụ
3. Đám cưới
4. Người tham gia
5. Hoá đơn

Chúng tôi sẽ thảo luận kỹ lưỡng từng lĩnh vực này theo thứ tự được liệt kê ở trên. Khi chúng tôi làm việc để phát triển mô hình dữ liệu của mình, chúng tôi sẽ đảm nhận vai trò của cơ quan tổ chức đám cưới.

Phần 1:Vị trí

Locations phần này có các bảng phổ quát có thể được sử dụng trong nhiều mô hình dữ liệu khác. Như chúng tôi đã lưu ý trước đó, toàn bộ lễ cưới có thể chỉ diễn ra ở một địa điểm duy nhất hoặc có thể kéo dài nhiều địa điểm. Hãy thảo luận chi tiết hơn về các bảng của phần này.

country bảng lưu trữ thông tin về quốc gia mà đám cưới diễn ra. Trong hầu hết các trường hợp, quốc gia này sẽ khớp với vị trí của đại lý của chúng tôi, nhưng điều đó có thể không đúng nếu chúng tôi hoạt động trên phạm vi quốc tế. Mỗi quốc gia trong bảng này được xác định duy nhất bởi country_name của quốc gia đó .

Tiếp theo, chúng ta cần lưu trữ danh sách tất cả các thị trấn và / hoặc làng nơi đám cưới sẽ được tổ chức. Thông tin này sẽ được lưu trữ tại city bàn. Đối với mỗi thành phố, chúng tôi sẽ lưu trữ tên và mã bưu chính của thành phố, cũng như quốc gia của thành phố đó.

Bảng cuối cùng trong chủ đề này là location . Vị trí cụ thể hơn, chẳng hạn như tòa thị chính, nhà thờ, công viên, v.v. Đối với mỗi vị trí, chúng tôi sẽ lưu trữ tên của vị trí đó và tham chiếu đến ID của thành phố mà vị trí đó tọa lạc. Sự kết hợp của hai thuộc tính này tạo thành khóa duy nhất cho bảng này.

Đối với các địa điểm, hãy lưu ý rằng chúng tôi đã thực hiện một cách tiếp cận thận trọng ở đây để tránh bao gồm các trường hợp bất thường mà buổi lễ diễn ra, chẳng hạn như tàu hỏa hoặc máy bay (trong trường hợp đó, “địa điểm” có thể liên quan đến nhiều thành phố). Nếu chúng tôi muốn đề cập đến những trường hợp này, chúng tôi cần thực hiện một số thay đổi đối với mô hình của mình.

Phần 2:Đối tác, Sản phẩm và Dịch vụ

Trước khi chuyển sang phần trung tâm của mô hình dữ liệu, chúng tôi cần lưu trữ danh sách tất cả các đối tác mà chúng tôi làm việc cùng, cũng như các sản phẩm và dịch vụ mà họ cung cấp. Để đạt được điều này, chúng tôi sẽ sử dụng năm bảng.

Trước hết, danh sách tất cả các đối tác mà chúng tôi hợp tác được lưu trữ trong partner từ điển. Đối với mỗi đối tác, chúng tôi sẽ lưu trữ partner_code duy nhất của họ và partner_name .

Tất nhiên, các đối tác của chúng tôi sẽ cung cấp các dịch vụ liên quan đến đám cưới, có thể bao gồm phục vụ ăn uống, tổ chức ban nhạc, thiết lập thiết bị âm thanh và video, hỗ trợ tiền thuê nhà, v.v. Về cơ bản, bất cứ điều gì bạn có thể nghĩ đến đều có thể liên quan đến một đám cưới theo một cách nào đó. Chúng tôi sẽ lưu trữ danh sách các dịch vụ này trong service từ điển. Đối với mỗi dịch vụ, chúng tôi sẽ lưu trữ:

• service_code - giá trị mà chúng tôi sẽ sử dụng nội bộ để biểu thị duy nhất một dịch vụ cụ thể.
• service_name - tên của dịch vụ. Lưu ý rằng các dịch vụ khác nhau có thể dùng chung một tên. Điều này sẽ xảy ra nếu hai đối tác của chúng tôi tình cờ cung cấp cùng một dịch vụ, điều này rất có thể xảy ra. Thậm chí sẽ rất đáng mong đợi nếu họ sử dụng cùng một tên cho cùng một loại dịch vụ vì điều đó sẽ giúp việc so sánh giá cho các dịch vụ giống nhau dễ dàng hơn nhiều.
• description - mô tả bằng văn bản tùy chọn về dịch vụ.
• picture - liên kết đến vị trí lưu trữ hình ảnh dịch vụ liên quan.
• price - giá hiện tại cho dịch vụ này. Nó có thể chứa giá trị NULL nếu không thể xác định được giá mà không đánh giá trước các yếu tố khác nhau, chẳng hạn như số lượng người dự định tham dự buổi lễ.

provides_service bảng liên quan đến các đối tác với danh sách các dịch vụ mà họ cung cấp. Đối với mỗi kết hợp duy nhất của partner_id và service_id , chúng tôi sẽ lưu trữ mô tả chi tiết bằng văn bản về bản chất của dịch vụ do đối tác cung cấp và liệu dịch vụ hiện có khả dụng hay không.

Chúng ta cũng cần các bảng để lưu trữ thông tin về sản phẩm và mối quan hệ của chúng với các đối tác. product bảng tuân theo logic tương tự như service , ngoại trừ, như tên cho thấy, nó dành riêng cho các sản phẩm. Trong bảng này, chúng tôi sẽ lưu trữ tất cả các sản phẩm có thể cần thiết cho hầu hết các lễ cưới, chẳng hạn như nhẫn, trang phục, đồ trang trí, hoa, đồ nội thất, v.v.

Bảng cuối cùng trong phần này là provides_product bàn. Nó hoạt động giống như provides_service , ngoại trừ nó dành riêng cho các sản phẩm chứ không phải dịch vụ. Nó chỉ định đối tác nào của chúng tôi cung cấp sản phẩm được đề cập.

Phần 3:Đám cưới

Cuối cùng thì chúng tôi cũng đã đến được trung tâm của mô hình dữ liệu của mình — Weddings tiết diện. Nó chứa năm bảng mới tham chiếu đến các bảng của các phần khác. Lưu ý rằng các bảng riêng của phần này cũng sẽ được tham chiếu trong các phần sắp tới của mô hình của chúng tôi.

Trong wedding , chúng tôi sẽ lưu trữ danh sách đầy đủ tất cả các đám cưới mà chúng tôi đã / đang tham gia tổ chức. Mỗi đám cưới sẽ được ấn định wedding_code duy nhất của riêng mình . Chúng tôi cũng sẽ lưu trữ thời gian bắt đầu và kết thúc dự kiến ​​cho toàn bộ buổi lễ, đồng thời chúng tôi sẽ cập nhật thời gian bắt đầu và kết thúc thực tế bất cứ khi nào có thông tin này. Ngoài ra, chúng tôi sẽ lưu trữ budget_planned giá trị để chúng tôi ít nhất có một ước tính về tất cả điều này sẽ có giá bao nhiêu. Tất cả các chi tiết khác liên quan đến đám cưới được lưu trữ trong các khu vực khác của mô hình dữ liệu, vì vậy đây là tất cả những gì chúng tôi thực sự cần lúc này.

Ý tưởng ở đây là coi mỗi đám cưới như một chuỗi các sự kiện. Các sự kiện lần lượt sẽ liên quan đến các đề nghị cho sản phẩm / dịch vụ mong muốn, các đề nghị bị từ chối và chấp nhận, và các chi tiết liên quan khác. Để bạn hiểu rõ hơn về cách hoạt động của tất cả những điều này, chúng tôi có thể chia toàn bộ đám cưới thành các sự kiện sau:giai đoạn lập kế hoạch, tiệc độc thân / cử nhân, buổi lễ và sau bữa tiệc / bữa tối. Tất nhiên, đây chỉ là một số sự kiện đám cưới phổ biến nhất. Tất cả các sự kiện đám cưới được lưu trữ trong bảng sự kiện. Một event sẽ có một id duy nhất.

Mỗi sự kiện được liên kết với một đám cưới duy nhất và nó sẽ liên quan đến một địa điểm hoặc không có. Trường hợp thứ hai phát sinh nếu sự kiện mang tính chất khái niệm , chẳng hạn như giai đoạn lập kế hoạch (vì không có địa điểm duy nhất mà nó phải diễn ra). Như với chính lễ cưới thực tế, một sự kiện sẽ có kế hoạch và thời gian bắt đầu / kết thúc thực sự, cũng như ngân sách dự kiến. Lưu ý rằng chúng tôi đã giữ mọi thứ đơn giản ở đây liên quan đến vị trí. Nếu các sự kiện liên quan đến nhiều địa điểm, chúng tôi sẽ cần điều chỉnh mô hình dữ liệu của mình.

Tiếp tục, chúng tôi muốn lưu trữ tất cả các dịch vụ và sản phẩm có liên quan đến một sự kiện. Để làm như vậy, chúng tôi sẽ sử dụng ba bảng:status , product_included và service_included .

status table là một từ điển theo dõi tất cả các trạng thái liên quan đến sản phẩm và dịch vụ cho một sự kiện cụ thể. Nó bao gồm các biến cờ biểu thị liệu một sản phẩm / dịch vụ đã được cung cấp, chấp nhận hay bị từ chối. Đối với mỗi bản ghi trong bảng này, chúng tôi sẽ lưu trữ một status_name duy nhất .

Hai bảng còn lại trong phần này, có tiêu đề product_included và service_included , giống nhau về cấu trúc và khái niệm. Đối với mỗi sự kiện, chúng tôi sẽ lưu trữ danh sách các sản phẩm và dịch vụ đã được cung cấp và thay đổi trạng thái của chúng nếu chúng được chấp nhận hoặc bị từ chối. Đối với mỗi bản ghi trong hai bảng này, chúng tôi sẽ lưu trữ các thuộc tính chung sau:

• event_id - tham chiếu đến sự kiện liên quan.
• provides_product_id / provides_service_id - tham chiếu đến các bảng với các sản phẩm / dịch vụ mà đối tác của chúng tôi cung cấp.
• price - giá đề xuất cho sản phẩm / dịch vụ. Giá này có thể khác với giá tiêu chuẩn mà chúng tôi có trong hồ sơ nếu chúng tôi đề xuất một ưu đãi đặc biệt.
• current_status_id - tham chiếu đến status từ điển cho biết liệu bản ghi này đã được cung cấp, chấp nhận hay bị từ chối.

Phần 4:Người tham gia

Nếu bạn đang tổ chức một đám cưới lớn, rất có thể bạn đã quen với hầu hết các khách mời dự định tham dự. Tất nhiên, những khách bạn mời — họ là bạn bè hoặc người thân của bạn — có khả năng sẽ mang theo những người khác mà bạn không biết, chẳng hạn như bạn bè hoặc đồng nghiệp của họ. Trong phần này, chúng tôi sẽ lưu trữ danh sách đầy đủ các khách đã được mời tham dự đám cưới, cũng như vai trò của họ.

person bảng chứa danh sách tất cả các cá nhân tham gia lễ cưới. Đối với mỗi cá nhân, chúng tôi sẽ lưu trữ person_code duy nhất của họ và họ và tên. Tất nhiên, chúng tôi có thể bổ sung thêm chi tiết nếu chúng tôi muốn.

Tiếp theo, chúng tôi sẽ xác định tất cả các vai trò có thể có mà một người có thể đảm nhận trong đám cưới. Những vai trò này bao gồm “khách mời”, “phù rể”, “phù rể”, “phù dâu”, “cô dâu”, “chú rể”, v.v. Đối với mỗi vai trò, chúng tôi sẽ chỉ lưu trữ role_name duy nhất trong bảng này. Một người chỉ có thể đảm nhận một vai trò trong một đám cưới cụ thể.

Tiếp theo, chúng tôi sẽ liên hệ đám cưới với những người tham gia của họ. Lưu ý rằng participate bảng chỉ chứa các tham chiếu đến các bảng wedding , person và role . Sự kết hợp của wedding_id và person_id đóng vai trò là khóa thay thế cho bảng này.

Đám cưới sẽ bao gồm một số sự kiện, nhưng không phải tất cả những người tham gia sẽ tham gia vào những sự kiện này. Do đó, chúng ta cần lưu trữ thông tin này một cách riêng biệt. Trong in_event bảng, chúng tôi sẽ lưu trữ các cặp khóa ngoại duy nhất tham chiếu đến các bảng event và participate . Tất cả thông tin bổ sung sẽ được lưu trữ trong details văn bản được phân bổ.

Phần 5:Hóa đơn

Chúng tôi sắp hoàn thành! Phần cuối cùng của mô hình dữ liệu của chúng tôi cho phép chúng tôi theo dõi các chi phí liên quan đến đám cưới. Thật thú vị, phải không?

Chúng tôi thường sẽ tạo một invoice mỗi đám cưới, nhưng chúng tôi cũng có thể tạo ra nhiều hơn nếu chúng tôi cần. Hy vọng rằng tổng số tiền chúng tôi lập hóa đơn cho cặp đôi sẽ khớp đúng với ngân sách dự kiến ​​của chúng tôi, nhưng điều đó có thể không phải lúc nào cũng đúng. Đối với mỗi hóa đơn, chúng tôi sẽ lưu trữ các thông tin sau:

• wedding_id - liên quan đến đám cưới mà hóa đơn được phát hành.
• time_created - dấu thời gian cho thời điểm tạo hóa đơn.
• due_date - ngày hóa đơn phải được thanh toán.
• invoice_amount - tổng số tiền phải thanh toán.
• payment_time - dấu thời gian về thời điểm thanh toán thực sự được phát hành. Tất nhiên, thuộc tính này sẽ chứa giá trị NULL cho đến khi thanh toán được thực hiện.
• paid - một cờ biểu thị liệu hóa đơn đã được thanh toán hay chưa. Thuộc tính này sẽ được đặt thành “Đúng” ngay sau payment_time được cập nhật.

Bảng cuối cùng trong mô hình của chúng tôi liên quan đến chính các mặt hàng được lập hóa đơn. Chúng tôi sẽ lưu trữ những thứ này trong invoice_item bàn. Đối với mỗi bản ghi, chúng tôi sẽ lưu trữ các chi tiết sau:

• item_name - tên chúng tôi đã chọn cho mặt hàng cụ thể.
• item_price - giá liên quan đến mặt hàng cụ thể đó.
• invoice_id - id của hóa đơn liên quan.
• service_included_id - id của dịch vụ mà mục hóa đơn có liên quan. Thuộc tính này có thể được đặt thành NULL nếu mặt hàng được đề cập thực sự không liên quan đến bất kỳ dịch vụ nào hoặc nếu nó chỉ là một khoản phí bổ sung mà chúng tôi đã áp dụng cho hóa đơn.
• product_included_id - id của sản phẩm có liên quan đến mục hóa đơn. Thuộc tính này có thể được đặt thành NULL nếu mặt hàng được đề cập thực sự không liên quan đến bất kỳ sản phẩm nào hoặc nếu nó chỉ là một khoản phụ phí mà chúng tôi đã áp dụng cho hóa đơn.

Tóm tắt

Đó là tổng kết cho mô hình dữ liệu này! Một lần nữa, chúng ta thấy việc lập mô hình dữ liệu hữu ích như thế nào trong việc tổ chức thông tin của một công ty.

Như chúng tôi đã lưu ý, có nhiều thứ mà chúng tôi đã bỏ qua khỏi mô hình dữ liệu của mình vì mục đích đơn giản. Ví dụ:mô hình của chúng tôi nên theo dõi lý tưởng lịch sử phiếu mua hàng, chi tiết tài chính và hơn thế nữa.

Hãy cho chúng tôi biết bên dưới nếu bạn có bất kỳ đề xuất nào. Chúng tôi rất muốn nghe những suy nghĩ của bạn!