The entities in the work processes described by the HCT Athletics department include the following; Event requests, Event plans, Event plan lines, Students, Facilities, Employees, Locations and Resources.
For each entity there’s a specific primary key and these are all unique as shown below; For Event requests the primary key is the unique event number, For Event plans the primary key is the unique plan number, For Event plan lines the primary key is the unique plan line number, For Students the primary key is the unique student number, For Facilities the primary key is the unique facility number, For Employees the primary key is the unique employee number, For Locations the primary key is the unique location number within the facility and for Resources the primary key is the unique resource number.
Each entity has specific attributes. For Event requests the attributes include; unique event number, date that event is held, the date requested, the date authorized, the status, the estimated cost, the estimated audience and the student number.
For Event plans, the attributes include; the plan number, the notes about the plan, the work date, the activity and the event number. For Event plan lines, the attributes are; the plan line number within a specific plan, the plan number, the starting time, the ending time, the resource number and the quantity of resources.
In the case of student entities, the attributes are; the student number, the name, the address, the contact name, phone number, e-mail and list of events requested by the student. Facilities have the following attributes; the facility number, name and list of events in which the facility has been requested. Employees have attributes that include; employee number, name, department number, e-mail address, phone number and list of event plans supervised.
The location entity has the following attributes; the location number, the location name and the list of event plan lines in which the location is used. Lastly, the resource entity had the following attributes; the resource number, the name, its rental rate and the list of event plan lines in which the resource is used.
As shown in the attachment, the entities had inter-relationships and these will be described below. Relationship 1 is between the event request and the facility. The cardinality is many-to-one between the request and the facility. This is a mandatory relationship since all events must be held in facilities and it is strong because both entities have uniquely identifying attributes. Relationship 2 is between the event request and the student. The cardinality is many-to-many between the request and the student. This is a mandatory relationship since all events can only be requested by students and it is strong because both entities have uniquely identifying attributes.
Relationship 3 is between the event plan and the student. The cardinality is many-to-one between the plan and the student because a student can give rise to many events. This is a mandatory relationship since only students can give rise to plans and it is strong because both entities have uniquely identifying attributes. Relationship 4 is between the event request and the event plan. The cardinality is one-to-one because each request generates only one plan. This is a mandatory relationship because each event can only succeed if there’s a plan. It is also strong because both entities have uniquely identifying attributes.
Relationship 5 is between the event plan line and the resource. The cardinality is many-to-many between the plan line and the resource since many resources can be used in many different plan lines. This is a mandatory relationship because plan lines cannot proceed without resources and it is strong because both entities have uniquely identifying attributes. Relationship 6 is between the event plan line and the location. The cardinality is one-to-one because each plan line is allocated a specific location. It is a mandatory relationship because each plan line must be fulfilled at a location. It is also strong because both entities have uniquely identifying attributes.
Relationship 7 is between the event request and the employee. The cardinality is many-to-one because each employee can handle many events. It is a mandatory relationship because each event can only be processed by an employee. It is also strong because both entities have uniquely identifying attributes. Relationship 8 is between the facility and the location. The cardinality is one-to-many because each facility can contain many locations. It is a mandatory relationship because each location can only be found within a facility and is strong because both entities have uniquely identifying attributes.
Relationship 9 is between the location and the plan line. The cardinality is one-to-many because each location can host many plan lines. It is a mandatory relationship because each event plan line must be allocated a location and is strong because both entities have uniquely identifying attributes. Relationship 10 is between the event plan and the plan line. The cardinality is one-to-many because each event plan can have several plan lines within it and is mandatory because each plan line can only be found within an event plan. It is also strong because both entities have uniquely identifying attributes.