Scribd
Upload
10 views4 pages

Event Management System Report

The Event Management System – Smart Organizer aims to streamline event planning by integrating client requests, venue bookings, vendors, and attendee details into a single Oracle database. The system automates tasks such as event scheduling, payment tracking, and vendor management, enhancing efficiency and accuracy. It includes features like event creation, venue availability checking, and attendee registration, with potential future extensions for event feedback.

Uploaded by

s9010akhi
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
10 views4 pages

Event Management System Report

The Event Management System – Smart Organizer aims to streamline event planning by integrating client requests, venue bookings, vendors, and attendee details into a single Oracle database. The system automates tasks such as event scheduling, payment tracking, and vendor management, enhancing efficiency and accuracy. It includes features like event creation, venue availability checking, and attendee registration, with potential future extensions for event feedback.

Uploaded by

s9010akhi
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd

.

DBMS Mini Project Report: Event Management System – Smart Organizer

1. Title

Event Management System – Smart Organizer

2. Objective

To develop a database system that streamlines event planning by managing client requests, venue
bookings, vendors, and attendee details in a single integrated Oracle database.

3. uses

In real-world event management, handling multiple service providers, bookings, and payments
manually causes confusion and delays.
This system automates those tasks, ensuring:

• Accurate data handling

• Efficient event scheduling

• Real-time tracking of payments and bookings

4. Scope of the Project

The system provides:

• Event creation and management

• Venue booking and availability checking

• Vendor allocation and tracking

• Attendee registration

• Payment management

• Event feedback (optional future extension)

5. System Design

5.1 Entities and Attributes


Entity Attributes Description

Client Client_ID (PK), Name, Contact_No, Email Event requester

Event_ID (PK), Event_Name, Type, Date, Venue_ID (FK), Client_ID Each scheduled
Event
(FK), Status event

Venue Venue_ID (PK), Name, Location, Capacity, Availability_Status Event locations

Vendor Vendor_ID (PK), Name, Type, Contact Service providers

Links vendors to
Booking Booking_ID (PK), Event_ID (FK), Vendor_ID (FK), Payment_Status
events

Attendee Attendee_ID (PK), Event_ID (FK), Name, Email, Ticket_Type Registered attendees

Payment Payment_ID (PK), Event_ID (FK), Amount, Mode, Payment_Date Records all payments

6. Specialization / Generalization

Entity: Vendor

Vendors can be specialized into subtypes based on their service category.


This is a specialization hierarchy.

Specialization Diagram (Text Description):

Vendor

---------------------------------

| | |

Caterer Decorator Photographer

Each subtype inherits Vendor_ID, Name, and Contact, but may add attributes like:

• Caterer: Menu_Type

• Decorator: Theme_Specialty

• Photographer: Equipment_Type

This specialization helps in efficient vendor management.

7. ER Diagram (Conceptual Design)

Here’s a text-based representation (you’ll get the visual diagram in the file):
Relationships:

• Client ↔ Event → One-to-Many

• Event ↔ Venue → Many-to-One

• Event ↔ Vendor → Many-to-Many (through Booking)

• Event ↔ Attendee → One-to-Many

• Event ↔ Payment → One-to-Many

8. Relational Schema

Table Schema

Client (Client_ID, Name, Contact_No, Email)

Venue (Venue_ID, Name, Location, Capacity, Availability_Status)

Vendor (Vendor_ID, Name, Type, Contact)

Event (Event_ID, Event_Name, Type, Date, Venue_ID, Client_ID, Status)

Booking (Booking_ID, Event_ID, Vendor_ID, Payment_Status)


Table Schema

Attendee (Attendee_ID, Event_ID, Name, Email, Ticket_Type)

Payment (Payment_ID, Event_ID, Amount, Mode, Payment_Date)

Foreign Key References:

• Event.Client_ID → Client.Client_ID

• Event.Venue_ID → Venue.Venue_ID

• Booking.Event_ID → Event.Event_ID

• Booking.Vendor_ID → Vendor.Vendor_ID

• Attendee.Event_ID → Event.Event_ID

• Payment.Event_ID → Event.Event_ID

You might also like