Mô hình dữ liệu quản lý sự kiện

Tổ chức một sự kiện là rất nhiều công việc! Trong bài viết này, chúng tôi xem xét mô hình dữ liệu đằng sau một ứng dụng tổ chức sự kiện.

Nếu bạn đã từng cố gắng tổ chức một sự kiện cho hơn mười người (và không tính các bữa tiệc hoặc cuộc họp kinh doanh ở đây) thì bạn biết việc quản lý sự kiện có thể phức tạp như thế nào! Chúng ta đã mời tất cả mọi người chưa? Họ đã xác nhận xem họ có đến không? Địa điểm đã được đặt trước và chuẩn bị chưa? Ai sẽ tổ chức sự kiện? Ai sẽ tham gia vào các phần khác nhau? Có rất nhiều câu hỏi khác cần trả lời, và mọi thứ có thể dễ dàng xảy ra sai sót.

Bạn có thể thực hiện tất cả các kế hoạch của mình bằng giấy và bút, nhưng tại sao không sử dụng một ứng dụng? Nó thuận tiện hơn! Bất kỳ ứng dụng nào cũng sẽ cần một nơi để lưu trữ tất cả các thông tin sự kiện cần thiết. Đây là nơi mà mô hình dữ liệu quản lý sự kiện của chúng tôi đi vào câu chuyện này. Uống một tách cà phê, ngồi xuống chiếc ghế yêu thích của bạn và chúng ta sẽ xem xét những gì cần thiết để xây dựng mô hình dữ liệu quản lý sự kiện.

Câu hỏi thường gặp về quản lý sự kiện

Trước khi chúng tôi giải thích mô hình và mô tả cách chúng tôi sẽ lưu trữ dữ liệu, trước tiên chúng ta hãy xem xét một số khái niệm cơ bản về quản lý sự kiện:

1. Điều gì có thể được coi là một sự kiện?

   Trong bối cảnh này, một sự kiện là một dịp mà nhiều người, những người thường không quen biết nhau, tụ tập để tìm hiểu hoặc tham gia vào điều gì đó. Một số sự kiện phổ biến là lễ hội âm nhạc hoặc buổi hòa nhạc, hội nghị CNTT, sự kiện thể thao như trò chơi bóng đá, hội nghị về sức khỏe và y tế, v.v.

2. Điểm chung của tất cả các sự kiện là gì?

   Các ví dụ về sự kiện được đề cập trước đây rất khác nhau về nội dung, mục đích và đối tượng mục tiêu. Tuy nhiên, họ có nhiều điểm tương đồng, đặc biệt là trong tổ chức của họ.

   Trước tiên, hãy xem xét nội dung của sự kiện. Một số sự kiện (ví dụ:buổi hòa nhạc hoặc trận bóng đá) sẽ chỉ cung cấp một loại nội dung và sẽ được tổ chức ở một nơi. Các sự kiện khác bao gồm nhiều “sự kiện phụ” khác nhau nhưng có liên quan, có thể xảy ra ở nhiều nơi khác nhau.

   Lấy một hội nghị CNTT làm ví dụ về loại sự kiện thứ hai. Có các bài giảng, bài thuyết trình, hội thảo và cuộc thi. Những người tham dự có thể sẽ đi từ phòng này sang phòng khác hoặc thậm chí có thể đi giữa các tòa nhà khác nhau khi họ đến các sự kiện phụ khác nhau. Một số sự kiện phụ này sẽ chạy cùng lúc, nhưng mỗi sự kiện phụ vẫn liên quan đến CNTT và có một hoặc nhiều máy chủ.

3. Điều gì để làm cho một sự kiện thành công?

   Trước hết, có rất nhiều nhân viên địa điểm tổ chức sự kiện làm việc chăm chỉ trong nền tảng:kỹ thuật âm thanh và hình ảnh, người bán vé, người mở cửa, nhân viên vệ sinh và bảo trì, và nhân viên hành chính. Nhiều người ở nhiều vai trò khác nhau sẽ dành nhiều giờ làm việc chăm chỉ để chuẩn bị sân khấu cho các “ngôi sao” và những người tham gia khác, nhưng không ai trong số họ được công nhận nhiều.

   Rõ ràng, tất cả các sự kiện đều yêu cầu một số loại cơ sở hạ tầng. Nếu chúng tôi tổ chức hội nghị ở một địa điểm thực tế, chúng tôi sẽ nói về phòng và chỗ ngồi, hệ thống âm thanh, ánh sáng, có thể là video, v.v. Ngay cả một sự kiện trực tuyến, như hội thảo trên web, cũng phải có nơi để sản xuất nội dung và Cần thiết lập CNTT để kết nối với những người tham dự ảo.

   Các sự kiện thường có các nhà tài trợ và đối tác truyền thông giúp tổ chức và quảng bá chúng. Các nhà tài trợ này hầu hết là các công ty, hiệp hội liên quan đến chủ đề sự kiện; đôi khi họ là những công ty khác đang tìm kiếm một số quảng cáo tốt; và hiếm khi một cá nhân tư nhân sẽ đóng vai trò là nhà tài trợ hoặc đối tác.

4. Quản lý sự kiện là gì?

   Quản lý sự kiện là một quy trình được sử dụng để quản lý hiệu quả các sự kiện và mọi thứ liên quan đến chúng. Nó có thể được coi là một loại hình quản lý dự án. Chúng tôi đã thảo luận về một mô hình dữ liệu quản lý dự án trong bài viết này. Sử dụng biểu đồ Gantt để hiển thị tiến trình, trạng thái hiện tại và các hành động trong tương lai của sự kiện là một ý tưởng không tồi.

   Có thể chúng tôi sẽ muốn ứng dụng quản lý sự kiện của mình vừa với một màn hình, nếu có thể. Hầu hết các hành động - như tạo một chương trình mới, chỉ định nhân viên và nguồn lực cho một nhiệm vụ hoặc ước tính chi phí - phải được kéo và thả.

Mô hình dữ liệu

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

• Events and Partners
• Shows, Performers and Equipment
• Employees

Chúng tôi sẽ xem xét kỹ hơn từng lĩnh vực chủ đề theo thứ tự chúng được liệt kê.

Phần 1:Sự kiện và Đối tác

Events and Partners chủ đề là phần trung tâm của mô hình của chúng tôi. Trong năm bảng này, chúng tôi sẽ lưu trữ các chi tiết quan trọng nhất về các sự kiện của chúng tôi. Chúng tôi cũng sẽ liên hệ các sự kiện với các đối tác.

Hãy bắt đầu với event bàn. Phần này liệt kê mọi sự kiện chúng tôi đã tổ chức và mọi sự kiện chúng tôi định tổ chức. Các thuộc tính trong bảng này là:

• event_name - Tên của một sự kiện. Nó không phải là DUY NHẤT vì chúng ta có thể có hai hoặc nhiều sự kiện có cùng tên - ví dụ:một buổi hòa nhạc của cùng một ban nhạc sẽ có cùng tên sự kiện. Tuy nhiên, event_name - start_time cặp phải DUY NHẤT.
• event_type_id - Tham chiếu event_type từ điển.
• event_location - Mô tả địa điểm nơi sự kiện sẽ diễn ra. Sử dụng thuộc tính mô tả cho phép chúng tôi tránh xây dựng một mô hình phức tạp hơn với các bảng như “quốc gia” và “thành phố” và các thuộc tính như “địa chỉ” và “mô tả”.
• event_description - Mô tả chi tiết về sự kiện và tất cả các chương trình hoặc hoạt động liên quan đến sự kiện đó. Đối với một buổi hòa nhạc, đây là nơi chúng tôi lưu trữ thông tin về tiết mục mở màn, tiết mục chính, mọi nghệ sĩ giải trí bổ sung và thứ tự biểu diễn.
• start_time - Khi nào sự kiện sẽ bắt đầu. Đó là điều bắt buộc vì chúng ta nên biết điều này trong giai đoạn lập kế hoạch.
• end_time - Khi sự kiện kết thúc. Chúng tôi có thể sử dụng thuộc tính này để lưu trữ thời gian kết thúc sự kiện dự kiến ​​hoặc thực tế. Vì chúng tôi có thể không biết trước thời gian chính xác này (ví dụ:nếu một trận đấu thể thao diễn ra trong hiệp phụ) nên thuộc tính này là tùy chọn.

event_type từ điển phân loại các sự kiện mà chúng tôi xử lý. Chúng tôi sẽ lưu trữ tất cả các loại sự kiện có thể có theo thị trường ngách của chúng:buổi hòa nhạc, trận đấu bóng đá, trận bóng rổ, hội nghị CNTT, v.v. Mỗi loại sự kiện được xác định duy nhất bởi type_name của nó .

Như chúng tôi đã đề cập trước đây, các sự kiện thường có các đối tác. Hầu hết các sự kiện sẽ có ít nhất một đối tác truyền thông, trong khi một số sự kiện cũng sẽ có các nhà tài trợ và các đối tác khác. Cùng một đối tác có thể có nhiều “vai trò đối tác” khác nhau trên cùng một sự kiện. Ví dụ, một công ty phát sóng truyền hình có thể đồng thời là đối tác truyền thông và nhà tài trợ chung của sự kiện. Đây là lý do tại sao chúng tôi sẽ sử dụng ba bảng để liên hệ các sự kiện với các đối tác.

Điều quan trọng là có thể thêm đối tác trong giai đoạn lập kế hoạch để tất cả các bên liên quan đến sự kiện có thể truy cập kịp thời vào thông tin đó. Ngoài ra, chúng tôi có thể sử dụng dữ liệu trước đây khi lập kế hoạch cho các sự kiện mới - ví dụ:chúng tôi có thể liên hệ với cùng một đối tác khi chúng tôi đang tổ chức một sự kiện định kỳ hoặc một sự kiện mới cùng loại. Nếu một công ty là nhà tài trợ chung cho một hội nghị công nghệ vào năm ngoái, thì họ có thể quan tâm đến việc làm lại vào năm nay.

Bây giờ, chúng ta hãy xem xét ba bảng quan hệ đối tác. Đầu tiên là partner mục lục. Đối với mỗi đối tác, chúng tôi sẽ lưu trữ partner_name và địa chỉ, thông tin liên hệ và partner_details khác của họ . Lưu ý rằng partner_name thuộc tính không phải là duy nhất. Chúng tôi có thể có hai đối tác có cùng tên, chẳng hạn như hai cá nhân có cùng họ và tên hoặc hai công ty có cùng tên công ty. Trong trường hợp này, chúng tôi sẽ phân biệt giữa chúng bằng cách sử dụng thông tin được lưu trữ trong partner_details thuộc tính.

Bảng thứ hai là partner_role từ điển, liệt kê tất cả các vai trò khác nhau mà đối tác có thể có. role_name thuộc tính sẽ chỉ chứa các giá trị DUY NHẤT. Một số tên vai trò dự kiến ​​là “đối tác truyền thông”, “nhà tài trợ chung” và “nhà tài trợ”.

Bảng cuối cùng trong chủ đề này liên quan đến các đối tác với các sự kiện. is_partner bảng chỉ chứa các khóa ngoại liên quan đến các đối tác với các sự kiện và xác định vai trò hoặc loại quan hệ đối tác. Sự kết hợp của các khóa ngoại này tạo thành khóa DUY NHẤT của bảng. Nếu muốn, chúng tôi có thể thêm ngày bắt đầu và ngày kết thúc trong trường hợp một số đối tác chỉ thực hiện vai trò của họ trong một phần của sự kiện. Chúng tôi cũng có thể liên kết các đối tác với các sự kiện phụ đơn lẻ và thay vì toàn bộ sự kiện. Tuy nhiên, đây là những tình huống tương đối phổ biến, vì vậy chúng tôi sẽ giữ nguyên phần này của mô hình.

Phần 2:Buổi biểu diễn, Người biểu diễn và Thiết bị

Như đã đề cập trong phần giới thiệu, mỗi sự kiện có thể có một số sự kiện phụ. Trong mô hình này, tôi đã quyết định gọi các sự kiện phụ là “chương trình”. Một chương trình là một sự kiện phụ duy nhất, tập trung vào một chủ đề, có ít nhất một người biểu diễn, v.v. Trong sự kiện hội nghị CNTT, một buổi biểu diễn có thể là một bài giảng về các nguyên tắc quản lý dự án; một chương trình khác có thể là một cuộc thảo luận nhóm về các phương pháp hay nhất về kho dữ liệu. Cả hai đều có thể diễn ra cùng một lúc, ở các địa điểm khác nhau và được tổ chức bởi những người thuyết trình khác nhau. Chúng tôi cũng sẽ xác định mọi thứ cần thiết để chạy một chương trình, vì chương trình phải tiếp tục (trong mọi trường hợp ☺).

Bảng trung tâm của phần này là show bàn. Điều này sẽ lưu giữ bản ghi của bất kỳ chương trình nào liên quan đến các sự kiện trong quá khứ, hiện tại và tương lai. Khi lập kế hoạch cho một sự kiện, chúng tôi sẽ cần thêm các chương trình mới ngay sau khi người biểu diễn (tức là giảng viên, diễn giả, người thuyết trình, ngôi sao nhạc rock) đã đồng ý tham gia một sự kiện. Xem qua mô tả về các thuộc tính của bảng sẽ giúp chúng tôi hiểu cách hoạt động của bảng:

• show_name - Tên của chương trình.
• show_location - Mô tả nơi chương trình sẽ diễn ra.
• show_description - Mô tả chi tiết về chương trình đó.
• start_time - Thời gian bắt đầu dự kiến.
• end_time - Thời gian kết thúc dự kiến. Nó có thể là NULL vì chúng tôi có thể nhập thời gian kết thúc thực tế (sau khi chương trình kết thúc) thay vì thời gian kết thúc dự kiến.
• event_id - Chương trình là một phần của sự kiện nào.

Trong hầu hết các trường hợp, các buổi biểu diễn sẽ yêu cầu thiết bị và người biểu diễn. (Về mặt lý thuyết, chúng tôi có thể có một buổi biểu diễn mà không có nghệ sĩ biểu diễn, nhưng chúng tôi sẽ không bận tâm đến điều đó ở đây.) Bởi vì thiết bị có hạn, điều quan trọng là phải đặt trước tất cả những thứ cần thiết trong giai đoạn lập kế hoạch của sự kiện. Để thực hiện điều này đúng cách, chúng ta cần biết điều gì sẽ xảy ra vào thời điểm nào. Ví dụ:nếu chúng tôi có hai máy chiếu và hai chương trình yêu cầu máy chiếu được lên lịch cùng một lúc, chúng tôi không thể thêm buổi chiếu thứ ba yêu cầu máy chiếu cho thời gian đó trừ khi chúng tôi có thêm thiết bị. Đây là loại thông tin chúng ta phải có trong giai đoạn lập kế hoạch.

Tiếp tục, chúng ta có performer bàn. Đây là một danh mục đơn giản về mọi nghệ sĩ biểu diễn mà chúng tôi đã làm việc cùng hoặc sẽ làm việc cùng trong bất kỳ sự kiện nào. Đối với mỗi người biểu diễn, chúng tôi sẽ lưu trữ full_name của họ . Đó có thể là tên của một ban nhạc, một giảng viên, v.v. Thể loại genre thuộc tính ở đây để phân biệt giữa các loại người biểu diễn khác nhau - ví dụ:ban nhạc rock từ các nhà điêu khắc. Thuộc tính cuối cùng trong bảng này lưu trữ contact_details của người biểu diễn . Chúng tôi sẽ sử dụng loại dữ liệu văn bản để lưu trữ lô, nhưng chúng tôi cũng có thể chia chi tiết liên hệ thành một vài trường riêng biệt.

Chúng tôi sẽ liên hệ các chương trình và nghệ sĩ biểu diễn thông qua participate bàn. Các thuộc tính trong bảng này là:

• show_id và performer_id - Tài liệu tham khảo về chương trình liên quan và nghệ sĩ biểu diễn. Cặp này có thể là một khóa thay thế (duy nhất) của bảng nhưng tôi quyết định không sử dụng nó; chúng ta có thể để một người biểu diễn tham gia cùng một chương trình vào hai thời điểm khác nhau.
• start_time và end_time - Thời gian chính xác xác định thời điểm người biểu diễn tham gia chương trình đó.
• cost_planned và cost_actual - Chi phí / lệ phí mà chúng tôi dự kiến ​​sẽ trả cho một nghệ sĩ biểu diễn và số tiền chúng tôi thực sự đã trả cho họ.

Ba bảng còn lại được sử dụng để xác định tất cả các thiết bị cần thiết cho một buổi biểu diễn.

equipment_type từ điển phân loại thiết bị. Đối với một buổi hòa nhạc, các danh mục này có thể là “thiết bị chiếu sáng”, “nhạc cụ”, “kết cấu sân khấu”, v.v. type_name thuộc tính chỉ chứa các giá trị DUY NHẤT.

equipment bảng mô tả các hạng mục và số lượng thiết bị. name của nó thuộc tính xác định thiết bị cụ thể hơn equipment_type . type_name . Đối với một quả bóng disco, giá trị “device”. ”Name” của nó sẽ là “disco ball” nhưng “device_type”. ”Type_name” sẽ là “thiết bị chiếu sáng”. available thuộc tính xác định số lượng của mặt hàng có sẵn cho chúng tôi. Đó là số thập phân vì có thể chúng ta sẽ sử dụng một số "mặt hàng" không thể liệt kê được, chẳng hạn như nước và điện.

Bảng cuối cùng trong phần này liên quan đến thiết bị và chương trình. Điều này có thể giúp chúng tôi tổ chức thiết bị trong giai đoạn lập kế hoạch; nó cũng cho phép chúng tôi tạo báo cáo về chi phí thiết bị sau này. Khi chúng tôi lập kế hoạch cho việc sử dụng thiết bị và chi phí, thông tin này có thể rất hữu ích, đặc biệt là đối với các sự kiện lặp lại (hoặc rất tương tự). Các thuộc tính trong required bảng là:

• show_id và equipment_id - Đề cập đến chương trình và thiết bị liên quan. Cặp này tạo thành khóa DUY NHẤT của bảng.
• quantity - Số lượng thiết bị cần thiết.
• cost_planned và cost_actual - Số tiền chúng tôi mong muốn trả cho việc lắp đặt hoặc thuê thiết bị và số tiền chúng tôi thực sự trả.

Phần 3:Nhân viên

Chủ đề của mô hình này là về nhân viên và vai trò của họ. Tôi luôn muốn chỉ ra rằng con người và thời gian của họ là phần quan trọng nhất của bất kỳ dự án nào. Bất cứ thứ gì khác chỉ là một công cụ để thực hiện một công việc. (Và công cụ đó cũng được tạo ra bởi mọi người, sử dụng thời gian của họ. ☺)

Tôi sẽ không giải thích về employee , role và has_role bảng ở đây. Tôi đã làm điều đó nhiều lần trước đây, chẳng hạn như trong bài viết này. Nếu bạn cần, vui lòng xem lại.

Bảng cuối cùng trong mô hình của chúng tôi liên hệ các nhân viên và vai trò với các chương trình. Chúng tôi có thể mong đợi có một số lượng hạn chế nhân viên đủ năng lực và chúng tôi cần đảm bảo rằng họ sẽ sẵn sàng làm việc khi cần thiết. Rõ ràng, cùng một người không thể ở hai nơi khác nhau cùng một lúc. Các thuộc tính trong engaged bảng là:

• show_id và has_role_id - Tham khảo chương trình liên quan và vai trò của nhân viên.
• start_time - Khi chúng tôi mong đợi một nhân viên sẽ bắt đầu vai trò đó.
• end_time - Khi vai trò đó kết thúc. Điều này là vô hiệu vì trong hầu hết các trường hợp, chúng tôi sẽ chỉ định một giá trị sau khi nhân viên đã hoàn thành vai trò của họ. Tuy nhiên, chúng tôi có thể nhập thời gian kết thúc dự kiến ​​tại đây.
• cost_planned và cost_actual - Những gì chúng tôi mong đợi sẽ trả cho một nhân viên khi đảm nhận vai trò đó và những gì chúng tôi thực sự đã trả.

Một lần nữa, tôi sẽ chỉ ra rằng dữ liệu lịch sử này có thể rất hữu ích khi bạn tổ chức một sự kiện lặp lại hoặc một sự kiện tương tự như một sự kiện trong quá khứ.

Hôm nay chúng ta đã thảo luận về một mô hình dữ liệu khả thi cho cơ sở dữ liệu quản lý sự kiện. Chúng tôi đã đề cập đến những điều thực sự quan trọng, như mô tả sự kiện, lên lịch cho những người thực hiện cũng như chỉ định nhân viên và tài nguyên cho sự kiện. Việc xử lý chi phí trong mô hình này được đơn giản hóa, nhưng nó vẫn cung cấp cho chúng tôi khả năng tính toán chi phí theo kế hoạch và thực tế theo danh mục, sự kiện, chương trình hoặc loại thiết bị.

Tôi không phải là người quản lý sự kiện. Nếu là bạn, tôi hy vọng bạn thấy bài viết này rất hữu ích. Nhưng tôi muốn nghe phản hồi của bạn về những bổ sung hoặc thay đổi nào có thể hữu ích trong các tình huống thực tế.

Tất nhiên, mọi người đều có thể gửi đề xuất và ý tưởng của mình trong phần bình luận.