Create a Database for a security swipe key system
all the PDFs carefully to identify potential entities. Some attributes and entities may not be obvious (for example, there are levels of master keys which open more than one door). There also may be entities or attributes that do not appear on these forms but are essential to tracking keys (for example, what is the current status of a key request or lock change request?). You design must be able to answer the following questions through SQL queries:
- List all people who have keys.
- List all people who have keys to a particular room.
- List all people who have keys to a particular building.
- List all people who have keys to a particular door (lockset).
- List all people who have master or submaster keys.
- List all people who have a particular master or submaster key.
- List all keys and the doors they open.
- List all types of keys.
- List all categories of keys.
- List all keys for a particular door (lockset).
- List all keys for a particular room (a room can have multiple doors and a door can have multiple keys).
- List all keys for a particular building.
- List all keys a person has, along with their building, room and door.
- List all lost keys.
- List all master keys.
- List all submaster keys.
- List all locksets a master key works on.
- List all key requests still pending.
- List status of a particular key request.
- List all keys requests made between two dates.
- List all keys issued between two dates.
- List all lock repair requests still pending.
- List all lock repair requests made between two dates.
- List all lock repair request finished between two dates.
- List that status of a particular repair request.
Implement this DB under your
Create a view named securityDesk for security personnelso they can do the following things (and only the following things!):
- take a key request
- issue a key
- change the status of a key
- take a lock repair request
- close a lock repair request
- change the status of a lock
- make any of the above queries (and other similar queries)
Create a view named keyManager for the person who manages the key control system so he can do the following things (and only the following things):
- everything the securityDesk can do
- add new keys
- add new locksets
- add new buildings
- add new rooms
Create the following MySQL users:
- a security desk employee named secdesk
- a key manager named keyman
- a DB administrator named admin.
For all three make the password
You should also apply appropriate security to the DB – grant these users appropriate permission (for the first two, it would be on their associated views, and for the admin it should be all permission for everything in the DB).
If you have any questions about how this key control system works, ask me for clarification.
The final project should include the following:
- A complete ER diagram of the final design. Please use a drawing tool to create this diagram (no hand-drawn diagrams!). There is an OpenOffice drawing program that will work nicely, and you may save the file in its native format. If you use another drawing tool (like Visio), please save the diagram as a JPEG. Or you can use Workbench and export as a JPEG, SVG or PDF. The name of the file should be both your myseneca IDs, separated by a hyphen (and don’t forget the correct file extension!). For example, jsmith-tjones.jpg.
- A dump of the schema fully implemented in MySQL as a SQL script – the dump should include everything necessary to recreate all the tables and views in btd210 (I will create the database) and load them with data. It should also recreate your users and grant them permission to the views as stated above. I will be loading this schema and testing it. The name of the file should be both your myseneca IDs, separated by a hyphen (and don’t forget the correct file extension!). For example, jsmith-tjones.sql. Note that this file requires the student honesty statement as a comment.