ACE Student Final Project

Final Project
PSP Rooms Controls Database Design

Table of Contents
Section Contents Page

I Database Requirements 3
II Pharmaceutical Plant Organizational Chart 5
III PSP Room Control Database Universal Schema and Functional 6

Dependencies
IV PSP Room Control Database Normalization, Dependencies and 11

Entity Analysis
V PSP Room Controls Database Conceptual Schema 18
VI Entity Relational Diagram (ERD) 27
VII Implementation of Relational Schema – Creation of Tables by 28

Using Access SQL Data Definition Queries
VIII Population of Tables 37
IX Queries and Reports 38
Page 2 of 48
I- Database Requirements
1) Background
The pharmaceutical manufacturing company uses different type of solvents (alcohols) for
the preparation of polymer solutions or suspensions, which are then sprayed into the solid
dosage form (i.e. pellets, powders) for the proper coating. These solvents are dispensed
from a central tank farm to a number of different PSP (polymer solution preparation)
rooms throughout the company. Within those rooms, there are tanks that receive the
solvents and where the solution is then prepared according to a manufacturing recipe.
The existing PSP rooms have an obsolete control platform and the solvent dispensing
data and records are not electronically stored. Also, the solution preparation process is
manually driven, as all required process parameter setpoint are manually entered. A
project is currently underway to upgrade and network the control systems for the PSP
Rooms. The scope of this project is to design the central database that will store and
maintain the relevant PSP Room information under the new controls architecture.
2) Business Rules and Partitioning by Homogeneous Groups
1. Users: Users of the system can perform functions within the control
application depending on their assigned access role. These roles are;
operator, mechanic, supervisor, engineer, administrator. Every user belongs
to a specific department. Information to be kept and maintained for users
includes the userid, name, role, department information. It is also important
to maintain the Status of the user account as Active (meaning the user can
access or use the system) or Inactive which could mean that the employee
has lost access or is no longer with the company.
2. Room: It is important to keep track of which rooms can be used for solution
preparation and the capabilities of each room. For these purposes, the
database should store the room identification, type of solvent dispensing
capabilities within each room and building location. Many of the rooms with
fixed tanks have two tanks that are controlled by the system.
3. Tanks: A tank can be fixed in a particular room or can be portable and used
in different rooms. It is important to keep track of the tank identification, size
and the room at which the tank is located (if the tank is fixed).
4. Solvent: It is important to keep track of all possible solvents needed for the
manufacturing operations (e.g. ethanol, isopropyl alcohol) and the cost per
unit of each solvent. A tank can be installed with the capacity to use more
than one solvent. However, only one solvent can be used for processing at
the same time.
Page 3 of 48
5. Recipes: In order to further automate and improve the process productivity,
the database is to store process preparation recipe setpoints to be then loaded
and used by the room equipment control system. Once the recipe is selected
and started by the operator, the equipment will be controlled automatically to
the recipe setpoints. Each recipe should uniquely identified and the stored
information should include, the recipe identification, description, date
created, user that created it, version, rooms in which the recipe can be used,
and recipe setpoints. Some of these setpoints can include; solvent type,
solvent quantity, mixer speed, mixing time, and tank purging pressure.
6. Alarms: A number of equipment alarms or events can occur during the

processing of a PSP Room batch. For troubleshooting and equipment
improvement trending purposes, it is important to keep track of alarms
information. Important information to be captured and stored for each alarm
includes; alarm description, control device tag name identification, time/date
of occurrence, room and tank identification, and batch number identification.
Each alarm must correspond to one tank, one room and one control device.
7. Recipe Audit Trail: For regulatory compliance and troubleshooting purposes,

it is important to keep track of changes made to equipment control recipes.
For these purposes, the database should keep an audit trail of changes made
to equipment recipes, Audit trail entries should include the recipe
identification, user who made the change, date/time stamps, identification of
parameter changed, value before and value after the change. Each recipe can
undergo many changes.
8. Solvent Usage History: For reconciliation, compliance and reporting

purposes, it is very important to maintain the historical records of usage for
all solvents. Every time that a solvent is dispensed to one of the PSP Rooms,
a record should be kept of the solvent type used, quantity dispensed, operator
identification, room identification, date and time, and batch number.
Page 4 of 48
II- Pharmaceutical Plant Organizational Chart
Plant General Manager
Technical
Manufacturing Engineering
Services HR Manager Quality Manager
Manager Manager
Manager
Tech Services Tech Services Dry Dosage Area

Engineers Quality
Supervisor 1 Supervisor 2 Manager HR Supervisors
Representatives
Technical Technical
Equipment
Services Services
Supervisor
Scientists Scientists Supervisor I
Quality Engineers
Production
Operators Equipment
Mechanics/ Calibration
Technicians Technicians
Quality Auditors
Supervisor II
Facilities
Supervisor
Production
Operators
Facilities
Fluid Bed Area Mechanics/
Manager Technicians
Production
Operators
Page 5 of 48
III- PSP Room Control Database Universal Schema and Functional Dependencies
1) User Relation
USER(USER_ID, FIRST_NAME, LAST_NAME, ACCESS_ROLE, DEPT_ID, DEPT_NAME, STATUS)
USER_ID FIRST_NAME LAST_NAME ACCESS_ROLE DEPT_ID DEPT NAME STATUS
Transitive Dependency
Transitive dependency (Dept_ID → Dept_Name)
Thus, the relation is in 2NF
Page 6 of 48
2) Solvent Relation
SOLVENT(SOLVENT_ID, DESCRIPTION, COST)
SOLVENT_ID DESCRIPTION COST
No transitional or partial dependencies, 3NF
3) Room Relation
ROOM(ROOM_ID, LOCATION, SOLVENT_USED)
ROOM_ID LOCATION SOLVENT_USED

However, the Solvent_Used attribute is a multivalued attribute which can have more than one value. For better data integrity and
consistency, this design will include a referencial integrity to the SOLVENT relation Solvent_ID attribute. This, in turns, results in a
M:N many-to-many potential relationship between the ROOM and SOLVENT relations. This will be analyzed further and resolved in
the next section.
Page 7 of 48
4) Tank Relation
TANK(TANK_ID, TANK_SIZE, TYPE,ROOM_ID)
TANK_ID TANK_SIZE TYPE ROOM_ID
5) Recipe Relation
RECIPE( RECIPE_ID,DESCRIPTION, DATE_CREATED,USER_REFERENCE,CURRENT_VERSION,

ROOM_USED, SOLVENT_ID,QUANTITY, MIXER_SPEED, MIX_TIME, PURGE_PRESS)
RECIPE_ID DESCRIPTION DATE_CREATED USER_REFERENCE CURR_VERSION ROOM_USED SOLVENT_ID
QUANTITY MIXER_SPEED MIX_TIME PURGE_PRESS
Page 8 of 48
Even though there does not appears to be partial or transitive dependencies, the Room_Used attribute is a multivalued attribute which
can have more than one value since the same recipe can be enabled or distributed to be used in multiple rooms. For better data
integrity and consistency, this design will include a referencial integrity to the ROOM relation Room_ID attribute. This, in turns,
results in a M:N many-to-many potential relationship between the ROOM and RECIPE relations. This will be analyzed further and
resolved in the next section.
6) Alarm Relation
ALARM(ALARM_ID, DESCRIPTION, DEVICE_ID, ALARM_TIME, ROOM_ID, TANK_ID, BATCH_INFO)
ALARM_ID DESCRIPTION DEVICE_ID ALARM_TIME ROOM_ID TANK_ID BATCH_INFO
No partial or transitive dependencies, 3NF
Page 9 of 48
7) Audit (Recipe Changes) Relation
AUDIT(AUDIT_ID, RECIPE_ID, USER_ID, CHANGE_DATE, PARAMETER, VALUE_BEFORE, VALUE_AFTER)
AUDIT_ID RECIPE_ID USER_ID CHANGE_DATE PARAMETER VALUE_BEFORE VALUE_AFTER
No partial or transitive dependencies, 3NF
8) Solvent Usage (History) Relation
HISTORY(USAGE_ID, SOLVENT_ID, QUANTITY, USER_ID, ROOM_ID, USE_DATE, BATCH_INFO, USE_COST)
USAGE_ID SOLVENT_ID QUANTITY USER_ID ROOM_ID USE_DATE BATCH_INFO USE_COST
Page 10 of 48
IV- PSP Room Control Database Normalization, Dependencies and Entity Analysis
1 User Identification • User identifications are assigned by

First Name the system administrator when the
Last Name accounts are created. This is a
Access Role candidate key.
Department ID • It is desired to keep track of which
Department Name department the user belongs to.
Status However, we can see that there is a
transitive dependency between the
Department ID and Department
Name attributes
• For better flexibility, the access role
is independent to the department the
user belongs to. This attribute is
assigned by the system
administrator when the user account
is created. This text entry will
always be one of several entries (i.e.
operator, supervisor, engineer) that
will be selected by the administrator
from a drop-down menu and then
saved in the corresponding table
attribute. Thus, there should be
minimal risk of introducing data
inconsistencies or anomalies, and
there should be no need of creating
another Role relation.
Functional Dependencies Analysis:

The transitive dependency between Department ID and Department Name is resolved
by creating another relation called DEPARTMENT to contain the Department ID and
Department Name data. The Department ID attribute is left in the USER relation as a
foreign key to the DEPARTMENT relation. After transitive dependency is removed,
the functional dependencies are;
User Identification → First Name, Last Name, Access Role, Department ID, Status
Department ID → Department Name
USER(user identification, first name, last name, access role, department ID, status)
DEPARTMENT(department ID, department name)
Page 11 of 48
Relation Primary Key Foreign Key
User User Identification Department ID
Department Department ID
2 Solvent Identification An entity set or table is needed to keep

Solvent Description track of all the possible types of solvents
Cost Per Kilogram and their current costs. Not more than 10
different types of solvents are ever
expected, so the Solvent Identification field
could be a text type with length of 2.
There are no partial or transitive dependencies.
Solvent Identification → Solvent Description, Cost Per Kilogram
SOLVENT (Solvent ID, Solvent Description, Cost Per Kilogram)

Solvent Solvent ID N/A
3 Room Identification • Not all solvents are piped or

Building Location programmed to work at every room.
Solvent Used For planning and optimization
purposes, it is necessary to keep track
of what solvents can be used on which
rooms (Solvent Used attribute)
• This points to a M:N or many-to-many
relationship between the Solvent and
Room relation. In order to address this,
a composite entity called
Room_Solvent is planned
The new composite Room_Solvent and Room relation schemas are as follows;
Room Identification → Building Location
Page 12 of 48
ROOM(Room Identification, Building Location)
ROOM_SOLVENT (Room Identification, Solvent ID)

Room Room ID
Room_Solvent Room ID, Solvent ID Room ID, Solvent ID
4 Tank ID • If the tank type is fixed, its room

Tank Size location needs to be stored and
Type maintained
Room Location • In rooms with fixed tanks, there are
usually two tanks per room.
• Room Location should be a foreign
key pointing to the Room relation

Tank ID → Tank Size, Type, Room Location
TANK(Tank ID, Tank Size, Type, Room Location)

Tank Tank ID Room Location
Page 13 of 48
5 Recipe ID • The recipe ID can be a unique three
Recipe Description character field to uniquely identify the
Date Created recipe
Creation User ID • In order to assure that only valid users
Version can create recipe for existing solvent
Rooms Where Can be Used types, Creation User ID and Solvent
Solvent Type Type attribute should be foreign key
Solvent Quantity relationships to the corresponding entity
Mixer Speed sets User and Solvent
Mixing Time • The attribute Rooms Where Can Be Used
Purging Pressure was originally planned to maintain the
information about which rooms each
recipe is validated or approved to be
used on (to be enforced or maintained by
the application). This results in a M:N or
many-to-many relationship to the Room
table. In order to resolve this, a
composite Recipe_Room relation will be
created to link the recipes and the rooms
and remove the M:N relationship
• The Version attribute will be
automatically increased by the
application whenever changes to the
recipes are saved by the user
Recipe ID → Recipe Description, Date Created, Creation User ID, Version,

Solvent Type, Solvent Quantity, Mixer Speed, Mixing Time,
Purge Pressure
RECIPE(Recipe ID, Recipe Description, Date Created, Creation User ID, Version,
Solvent Type, Solvent Quantity, Mixer Speed, Mixing Time,
Purge Pressure)
RECIPE_ROOM(Recipe ID, Room ID)

Recipe Recipe ID Creation User ID
Solvent Type
Recipe_Room Room ID, Recipe ID Room ID, Recipe ID
Page 14 of 48
6 Audit Trail ID • An alarm log ID attribute was added
Alarm Description here as a candidate key in order to
Control Device Identification uniquely identify all relation records.
Time/Date Stamp This could be a surrogate key
Room Identification automatically generated by the internal
Tank Identification model
Batch ID • The alarm description and control device
identification information are to be
generated by the application software
and store in the relation as alarms are
triggered
• The Batch ID information is to be
entered by the user before the solvent
dispensing process begins
• In order to assure data integrity and
prevent anomalies, Room Identification
and Tank Identification attributes should
be foreign keys pointing to the related
records on the corresponding relations
Alarm Log ID → Alarm Description, Control Device Identification, Time/Date

Stamp, Room Identification, Tank Identification, Batch ID
ALARM(Alarm Log ID, Alarm Description, Control Device Identification,

Time/Date Stamp, Room Identification, Tank Identification, Batch ID)

Alarm Alarm Log ID Room Identification
Tank Identification
Page 15 of 48
7 Audit Trail ID • An audit trail ID attribute is a candidate
Recipe ID key in order to uniquely identify all
User ID records related to recipe changes. This
Date/Time Change could be a surrogate key automatically
Parameter Changed generated by the internal model
Value Before • This relation or entity set is needed in
Value After order to save and keep an audit trail of
all recipe changes
• Recipe ID and User ID attributes should
be implemented as foreign keys in order
to assure that only valid recipe and user
IDs are entered into the relation
• The Parameter Changed, Value Before
and Value After attribute values will be
loaded by the application based on the
user entries and after recipe changes are
saved from the application
Audit Trail ID → Recipe ID, User ID, Time/Date Change, Parameter Changed,
Value Before, Value After
AUDIT(Audit Trail ID, Recipe ID, User ID, Time/Date Change, Parameter Changed,
Value Before, Value After)

Audit Audit ID Recipe ID
User ID
Page 16 of 48
8 Solvent Usage Record ID • A solvent usage record ID attribute is a
Solvent ID candidate key in order to uniquely
Quantity Dispensed identify all records related to dispensed
Operator ID solvent usage history. This could be a
Room ID surrogate key automatically generated by
Date and Time Stamp the internal model
Batch ID • This relation or entity set is needed in
Cost order to save and keep a record of all
solvents dispensed in all rooms and
generate costs information. For naming
convenience, the relation will be named
HISTORY.
• Solvent ID, Operator ID and Room ID
attributes should be implemented as
foreign keys in order to assure that only
valid solvents rooms and user IDs are
entered into the relation
• The Cost attribute values will be
calculated by the application at the time
that the dispensing is done based on the
quantity of solvent that was dispensed
and the current cost per unit (Solvent
relation) at that particular time. It is
recommended to calculate and store the
cost in order to preserve historical
accuracy since the solvent cost could
change over time and only the current
prices will be kept in the Solvent
relation.
Solvent Usage ID → Solvent ID, Quantity Dispensed, Operator ID, Room ID,
Date/Time Stamp, Batch Id, Cost
HISTORY(Solvent Usage ID, Solvent ID, Quantity Dispensed, Operator ID, Room
ID, Date/Time Stamp, Batch Id, Cost)

History Solvent Usage ID Room ID
Operator ID
Solvent ID
Page 17 of 48
V – PSP Room Controls Database Conceptual Schema
1) DEPARTMENT Entity
Attribute Type Format/Example Required Primary Key Referenced Comments

(PK) OR Table
Foreign Key
(FK)
Dept_ID Char(3) 001 Y PK Department ID
Dept_Name Varchar(25) Engineering Y Department Name
2) USER Entity

(PK) OR Table
Foreign Key
(FK)
User_ID Varchar(15) cbruzos Y PK User Identification
User_Fname Varchar(25) Carlos Y User First Name
User_Lname Varchar(25) Bruzos Y User Last Name
User_Role Varchar(15) Administrator Y User Role
Possible values are;
operator, mechanic,
supervisor, engineer
and administrator
User_DeptID Char(3) 001 Y FY DEPARTMENT
User_Status Varchar(8) Inactive Y User current access
status. Possible values
are Active or Inactive
Page 18 of 48
Relationship/Entities Connectivity Attributes
USER belongs to DEPARTMENT M:1 User_DeptID, Dept_ID
3) SOLVENT Entity

(PK) OR Table
Foreign Key
(FK)
Sol_ID Char(2) 02 Y PK Solvent Identification
Sol_Desc Varchar(25) Isopropyl Alcohol Y Solvent Description
Sol_Cost Number $20.50 Y Current Cost of
Solvent per Kilogram
4) ROOM Entity

(PK) OR Table
Foreign Key
(FK)
Room_ID Varchar(7) M-101 Y PK Room Identification
Room_Bldg Varchar(15) Marina West Y Building Location
Page 19 of 48
4) ROOM_SOLVENT (Composite) Entity

(PK) OR Table
Foreign Key
(FK)
RS_RID Varchar(7) M-101 Y PK,FK ROOM Room Reference
RS_SolID Char(2) 02 Y PK,FK SOLVENT Solvent Reference

ROOM shows on ROOM_SOLVENT 1:M Room_ID, RS_RID
SOLVENT is used on ROOM_SOLVENT 1:M Sol_ID, RS_SolID
5) TANK Entity

(PK) OR Table
Foreign Key
(FK)
Tank_ID Varchar(7) V-105 Y PK Tank Identification
Tank_Size Integer 100 Y Tank Capacity in
Gallons
Tank_Type Varchar(8) fixed Y “portable” or “fixed”
Tank_RID Varchar(7) M-101 FK ROOM
Page 20 of 48
ROOM contains TANK 1:M Room_ID, Tank_RID
6) RECIPE Entity

(PK) OR Table
Foreign Key
(FK)
Recipe_ID Char(3) 105 Y PK Recipe Identification
Recipe_Desc Varchar(25) Claritin 200 mg Y Recipe Description
Recipe_Date Date 08/23/2007 Y Date when recipe was first
created
Recipe_User Varchar(15) cbruzos Y FK USER ID of user who created the
recipe
Recipe_Ver Integer 5 Y Current recipe version
Recipe_Sol Char(2) 01 Y FK SOLVENT Solvent ID reference
Recipe_Qty Integer 150 Y Quantity (in Kilograms) of
solvent to use in the tank
Recipe_Speed Integer 60 Y Tank mixer speed in
revolutions per minute
Recipe_Time Integer 20 Y Number of minutes to mix
Recipe_Press Integer 35 Y Tank purging pressure
during mixing
Page 21 of 48
USER creates RECIPE 1:M User_ID, Recipe_RID
SOLVENT is used in RECIPE 1:M Sol_ID, Recipe_ID
7) RECIPE_ROOM (Composite) Entity

(PK) OR Table
Foreign Key
(FK)
RR_RecID Char(3) 105 Y PK,FK RECIPE Recipe Reference
RR_RoomID Varchar(7) M-101 Y PK,FK ROOM Room Reference
RR_Count Integer 10 Y Attribute was added to
keep count of how
many times a
particular recipe has
been run in each room

RECIPE is used in RECIPE_ROOM 1:M Recipe_ID, RR_RecID
ROOM can run RECIPE_ROOM 1:M Room_ID, RR_RoomID
Page 22 of 48
8) ALARM Entity

(PK) OR Table
Foreign Key
(FK)
Alarm_ID Integer 20 Y PK Alarm Identification
(Autonumber) Value
Alarm_Desc Varchar(40) Bottom Tank Y Alarm Description
Valve Failed to
Close
Alarm_Device Varchar(10) XY-125 Y Control device or
component identification
as found in drawings
Alarm_Date Date 09/12/2008 Y Date and time when alarm
08:30:07 AM occurred
Alarm_Room Varchar(7) M-101 Y FK ROOM Room where the alarm
occurred
Alarm_Tank Varchar(7) V-105 Y FK TANK Tank being used when the
alarm occurred
Alarm_Batch Varchar(10) 564GRN Y Batch identification as
entered by the operator

ROOM is listed in ALARM 1:M Room_ID, Alarm_Room
TANK is tracked in ALARM 1:M Tank_ID, Alarm_Tank
Page 23 of 48
9) AUDIT (Recipe Changes History) Entity

(PK) OR Table
Foreign Key
(FK)
Audit_ID Integer 20 Y PK Audit Entry Identification
(Autonumber)
Audit_RecID Char(3) 105 Y FK RECIPE Recipe Identification for
Audit entry
Audit_User Varchar(15) cbruzos Y FK USER Identification of user who
made changes to the
recipe
Audit_Date Date 09/12/2008 Y Date and time when
08:30:07 AM change to recipe occurred
Audit_Param Varchar(20) Mixer speed Y Identification of recipe
parameter that changed
Audit_Bef Varchar(5) 120 Y Value of parameter before
the change
Audit_After Varchar(5) 150 Y Value of parameter after
the change

RECIPE recorded in AUDIT 1:M Recipe_ID, Audit_RecID
USER listed in AUDIT 1:M User_ID, Audit_User
Page 24 of 48
10) HISTORY Entity

(PK) OR Table
Foreign Key
(FK)
His_ID Integr 127 Y PK Solvent usage entry
(Autonumber) identification. To be an
Autonumber generated by
the database in order to
prevent duplicate entry of
primary keys
His_SolID Char(2) 02 Y FK SOLVENT Solvent type identification
reference
His_Qty Number 250 Y Quantity of solvent
dispensed
His_User Varchar(15) cbruzos Y FK USER Identification of user
His_Room Varchar(7) M-101 Y FK ROOM Room where the solvent
was used
His_Date Date 09/12/2008 Y Date and time when the
08:30:07 AM dispensing occurred
His_Batch Varchar(10) 564GRN Y Batch number as entered
by the user
His_Cost Number $2,500 Y Calculation of operation
cost based on current price
per unit at the time of
dispensing times the
quantity of solvent
dispensed
Page 25 of 48
USER generates HISTORY 1:M User_ID, His_User
ROOM appears in HISTORY 1:M Room_ID, His_Room
SOLVENT was used in HISTORY 1:M Sol_ID, His_SolID
Page 26 of 48
VI- Entity Relational Diagram
DEPARTMENT
SOLVENT
PK Dept_ID
PK Sol_ID
u:R
d:R Dept_Name
Sol_Desc RECIPE
is used in
Sol_Cost
PK Recipe_ID
Recipe_Desc contains
Recipe_Date u:R
is used d:R
u:R Recipe_Ver
d:R FK1 Recipe_Sol
USER
Recipe_Qty
ROOM_SOLVENT Recipe_Speed PK User_ID
Recipe_Time creates
PK,FK2 RS_RID u:R
Recipe_Press User_Fname
PK,FK1 RS_SolID d:R
FK2 Recipe_User User_Lname
User_Role
FK1 User_DeptID
User_Status
u:R is used in
d:R u:R
was used ind:R
recorded in listed in
shows on RECIPE_ROOM u:R
d:R
PK,FK1 RR_RecID
PK,FK2 RR_RoomID AUDIT
u:R
d:R generates
RR_Count PK Audit_ID
ROOM can run u:R
d:R FK1 Audit_User
PK Room_ID
Audit_Date
appears in Audit_Param
Room_Bldg
Audit_Bef
Audit_After
u:R FK2 Audit_RecID
is listed in d:R u:R
d:R u:R
contains u:R d:R
d:R
u:R ALARM
d:R
PK Alarm_ID
HISTORY
TANK
u:R Alarm_Desc PK His_ID
PK Tank_ID d:R Alarm_Device
is tracked in Alarm_Date His_Qty
Tank_Size FK1 Alarm_Room FK1 His_User
Tank_Type FK2 Alarm_Tank FK2 His_Room
FK1 Tank_RID Alarm_Batch His_Date
His_Batch
His_Cost
FK3 His_SolID
Page 27 of 48
VII- Implementation of Relational Schema – Creation of Tables by
Using Access SQL Data Definition Queries
1) DEPARTMENT Table
DDL Query Name: qry_dept_table

CREATE TABLE DEPARTMENT(
Dept_ID Char(3) NOT NULL UNIQUE,
Dept_Name Varchar(25) NOT NULL,
PRIMARY KEY(Dept_ID));
2) USER Table
DDL Query Name: qry_user_table

CREATE TABLE USER(
User_ID Varchar(15) NOT NULL UNIQUE,
User_Fname Varchar(25) NOT NULL,
User_Lname Varchar(25) NOT NULL,
User_Role Varchar(15) NOT NULL,
User_DeptID Char(3) NOT NULL,
User_Status Varchar(8) NOT NULL,
PRIMARY KEY (User_ID),
FOREIGN KEY (User_DeptID) REFERENCES
DEPARTMENT);
Page 28 of 48
3) SOLVENT table
DDL Query Name: qry_solvent_table

CREATE TABLE SOLVENT(
Sol_ID Char(2) NOT NULL UNIQUE,
Sol_Desc Varchar(25) NOT NULL,
Sol_Cost Number NOT NULL,
PRIMARY KEY (Sol_ID));
Page 29 of 48
4) ROOM Table
DDL Query Name: qry_room_table

CREATE TABLE ROOM(
Room_ID Varchar(7) NOT NULL UNIQUE,
Room_Bldg Varchar(15) NOT NULL,
PRIMARY KEY (Room_ID));
5) ROOM_SOLVENT Table
DDL Query Name: qry_room_solvent_table

CREATE TABLE ROOM_SOLVENT(
RS_RID Varchar(7) NOT NULL,
RS_SolID Char(2) NOT NULL,
PRIMARY KEY (RS_RID,RS_SolID),
FOREIGN KEY (RS_RID) REFERENCES ROOM,
FOREIGN KEY (RS_SolID) REFERENCES SOLVENT);
Page 30 of 48
6) TANK Table
DDL Query Name: qry_tank_table

CREATE TABLE TANK(
Tank_ID Varchar(7) NOT NULL UNIQUE,
Tank_Size Integer NOT NULL,
Tank_Type Varchar(8) NOT NULL,
Tank_RID Varchar(7),
PRIMARY KEY (Tank_ID),
FOREIGN KEY (Tank_RID) REFERENCES ROOM);
Page 31 of 48
7) RECIPE Table
DDL Query Name: qry_recipe_table

CREATE TABLE RECIPE(
Recipe_ID Char(3) NOT NULL UNIQUE,
Recipe_Desc Varchar(25) NOT NULL,
Recipe_Date Date NOT NULL,
Recipe_User Varchar(15) NOT NULL,
Recipe_Ver Integer NOT NULL,
Recipe_Sol Char(2) NOT NULL,
Recipe_Qty Integer NOT NULL,
Recipe_Speed Integer NOT NULL,
Recipe_Time Integer NOT NULL,
Recipe_Press Integer NOT NULL,
PRIMARY KEY (Recipe_ID),
FOREIGN KEY (Recipe_User) REFERENCES USER,
FOREIGN KEY (Recipe_Sol) REFERENCES SOLVENT);
Page 32 of 48
8) RECIPE_ROOM Table
DDL Query Name: qry_recipe_room_table

CREATE TABLE RECIPE_ROOM(
RR_RecID Char(3) NOT NULL,
RR_RoomID Varchar(7) NOT NULL,
RR_Count Integer NOT NULL,
PRIMARY KEY (RR_RecID,RR_RoomID),
FOREIGN KEY (RR_RecID) REFERENCES RECIPE,
FOREIGN KEY (RR_RoomID) REFERENCES ROOM);
Page 33 of 48
9) ALARM Table
DDL Query Name: qry_alarm_table

CREATE TABLE ALARM(
Alarm_ID Number UNIQUE,
Alarm_Desc Varchar(40) NOT NULL,
Alarm_Device Varchar(10) NOT NULL,
Alarm_Date Date NOT NULL,
Alarm_Room Varchar(7) NOT NULL,
Alarm_Tank Varchar(7) NOT NULL,
Alarm_Batch Varchar(10) NOT NULL,
PRIMARY KEY (Alarm_ID),
FOREIGN KEY (Alarm_Room) REFERENCES ROOM,
FOREIGN KEY (Alarm_Tank) REFERENCES TANK);
Page 34 of 48
10) AUDIT Table
DDL Query Name: qry_audit_table

CREATE TABLE AUDIT(
Audit_ID Number UNIQUE,
Audit_RecID Char(3) NOT NULL,
Audit_User Varchar(15) NOT NULL,
Audit_Date Date NOT NULL,
Audit_Param Varchar(20) NOT NULL,
Audit_Bef Varchar(5) NOT NULL,
Audit_After Varchar(5) NOT NULL,
PRIMARY KEY (Audit_ID),
FOREIGN KEY (Audit_RecID) REFERENCES RECIPE,
FOREIGN KEY (Audit_User) REFERENCES USER);
Page 35 of 48
11) HISTORY Table
DDL Query Name: qry_history_table

CREATE TABLE HISTORY(
His_ID Number UNIQUE,
His_SolID Char(2) NOT NULL,
His_Qty Number NOT NULL,
His_User Varchar(15) NOT NULL,
His_Date Date NOT NULL,
His_Room Varchar(7) NOT NULL,
His_Batch Varchar(10) NOT NULL,
His_Cost Number NOT NULL,
PRIMARY KEY (His_ID),
FOREIGN KEY (His_User) REFERENCES USER,
FOREIGN KEY (His_SolID) REFERENCES SOLVENT,
FOREIGN KEY (His_Room) REFERENCES ROOM);
Page 36 of 48
VIII- Population of Tables
In order to populate the tables with a base set of records for query purposes, an Access
form was created and edited for each table. Within the forms, drop-down box fields were
generally created for data entry of foreign key fields. This was done to enhance the
records entry productivity and to assure that referencial integrity data entry errors at the
form level were prevented. Here are print screen examples of a few of these forms. For
more details, please open and review the Carlos_Bruzos_Final_Project Access database.
Page 37 of 48
IX- Queries and Reports
1) List all PSP Equipment users information (including department name) only for active
users
Query SQL Command:
SELECT [User_ID], [User_Fname], [User_Lname], [User_Role], [Dept_Name],

[User_Status]
FROM DEPARTMENT, [USER]
WHERE [DEPARTMENT].[Dept_ID]=[USER].[User_DeptID]
And [USER].[User_Status]='Active';
Access Query Results:
Access Report Output:
Page 38 of 48
2) List room and building information for room that can be used with Acetone
Query SQL Command:
SELECT [Room_ID], [Room_Bldg]

FROM ROOM, SOLVENT, ROOM_SOLVENT
WHERE ROOM.Room_ID=ROOM_SOLVENT.RS_RID AND
SOLVENT.Sol_ID=ROOM_SOLVENT.RS_SolID
AND Room_ID IN (SELECT RS_RID FROM ROOM_SOLVENT WHERE
SOLVENT.Sol_Desc='Acetone');
Page 39 of 48
3) List all solvents which current cost per Kilogram is greater than $20
Query SQL Command:
SELECT [Sol_ID], [Sol_Desc], [Sol_Cost]

FROM SOLVENT
WHERE Sol_Cost>20;
Page 40 of 48
4) List all recipe changes made by user ID ‘cbruzos’ between July 1st 2008 and today
Query SQL Command:
SELECT [Audit_RecID], [Recipe_Desc], [Audit_User], [User_Fname],

[User_Lname], [Audit_Date], [Audit_Param], [Audit_Bef], [Audit_After]
FROM AUDIT, RECIPE, [USER]
WHERE [AUDIT].[Audit_RecID]=[RECIPE].[Recipe_ID]
And [AUDIT].[Audit_User]=[USER].[User_ID]
And [Audit_User]='cbruzos' And ([Audit_Date] Between #7/1/2008# And
DATE());
Page 41 of 48
5) List all existing recipe names that can be used for Aspirin and the rooms in which they
can be run
Query SQL Command:
SELECT Recipe_ID, Recipe_Desc, RR_RoomID

FROM RECIPE, RECIPE_ROOM
WHERE RECIPE.Recipe_ID=RECIPE_ROOM.RR_RecID
AND Recipe_Desc LIKE 'Aspirin*';
Page 42 of 48
6) Provide a summary listing showing the number of alarms by room that occurred
between May 1st, 2008 and today. Show listing in descending order with the room having
the greatest number of alarms first.
Query SQL Command:
SELECT [Alarm_Room], COUNT([Alarm_Room])

FROM ALARM
WHERE (Alarm_Date BETWEEN #05/01/2008# AND DATE())
GROUP BY [Alarm_Room]
ORDER BY COUNT([Alarm_Room]) DESC;
Page 43 of 48
7) List solvents for which an investment of more than $5,000 has been used since June 1st
2008
Query SQL Command:
SELECT [Sol_ID], [Sol_Desc], SUM([His_Cost]) AS TOTCOST

FROM SOLVENT, HISTORY
WHERE [SOLVENT].[Sol_ID]=[HISTORY].[His_SolID] And
([His_Date] Between #6/1/2008# And DATE())
GROUP BY [Sol_ID], [Sol_Desc]
HAVING SUM(His_Cost) > 5000;
Page 44 of 48
8) Show listing of alarms (ordered by the room) for rooms that have more than three
alarms within 2008
Query SQL Command:
SELECT [Alarm_Room], [Alarm_Desc], [Alarm_Device],

[Alarm_Date], [Alarm_Tank], [Alarm_Batch]
FROM ALARM
WHERE Alarm_Date BETWEEN #01/01/2008# AND #12/31/2008#
AND Alarm_Room IN (SELECT Alarm_Room FROM ALARM
GROUP BY Alarm_Room HAVING COUNT(Alarm_Room) >=3)
ORDER BY [Alarm_Room];
Page 45 of 48
9) SQL Update Query- Increase solvent prices by 10% for all solvents which current cost
is less than $20
Query SQL Command:
UPDATE SOLVENT
SET Sol_Cost=(Sol_Cost*1.10)
WHERE Sol_Cost<20;
Page 46 of 48
10) SQL Delete Query- Delete portable tanks from the Tank table since the user
requested not to track the use of these type of tanks
Query SQL Command:
DELETE FROM TANK

WHERE Tank_Type='portable';
Page 47 of 48
11) SQL Modify Query- As part of maintenance, it was requested to increase the length
of the Alarm Description (Alarm_Desc) field so that more descriptive and complete
alarm information can be saved.
Query SQL Command:
ALTER TABLE ALARM

ALTER COLUMN Alarm_Desc Varchar(45);
Page 48 of 48

ACE Student Final Project

Transféré par

Informations du document

Description originale:

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

ACE Student Final Project

Transféré par

Droits d'auteur :

Formats disponibles

Final Project

PSP Rooms Controls Database Design

Section Contents Page

II Pharmaceutical Plant Organizational Chart 5

III PSP Room Control Database Universal Schema and Functional 6

IV PSP Room Control Database Normalization, Dependencies and 11

V PSP Room Controls Database Conceptual Schema 18

VI Entity Relational Diagram (ERD) 27

VII Implementation of Relational Schema – Creation of Tables by 28

VIII Population of Tables 37

IX Queries and Reports 38

2) Business Rules and Partitioning by Homogeneous Groups

6. Alarms: A number of equipment alarms or events can occur during the

7. Recipe Audit Trail: For regulatory compliance and troubleshooting purposes,

8. Solvent Usage History: For reconciliation, compliance and reporting

Plant General Manager

Tech Services Tech Services Dry Dosage Area

USER(USER_ID, FIRST_NAME, LAST_NAME, ACCESS_ROLE, DEPT_ID, DEPT_NAME, STATUS)

USER_ID FIRST_NAME LAST_NAME ACCESS_ROLE DEPT_ID DEPT NAME STATUS

Thus, the relation is in 2NF

SOLVENT(SOLVENT_ID, DESCRIPTION, COST)

SOLVENT_ID DESCRIPTION COST

No transitional or partial dependencies, 3NF

ROOM(ROOM_ID, LOCATION, SOLVENT_USED)

ROOM_ID LOCATION SOLVENT_USED

No transitional or partial dependencies, 3NF

TANK(TANK_ID, TANK_SIZE, TYPE,ROOM_ID)

TANK_ID TANK_SIZE TYPE ROOM_ID

No transitional or partial dependencies, 3NF

RECIPE( RECIPE_ID,DESCRIPTION, DATE_CREATED,USER_REFERENCE,CURRENT_VERSION,

RECIPE_ID DESCRIPTION DATE_CREATED USER_REFERENCE CURR_VERSION ROOM_USED SOLVENT_ID

QUANTITY MIXER_SPEED MIX_TIME PURGE_PRESS

ALARM(ALARM_ID, DESCRIPTION, DEVICE_ID, ALARM_TIME, ROOM_ID, TANK_ID, BATCH_INFO)

ALARM_ID DESCRIPTION DEVICE_ID ALARM_TIME ROOM_ID TANK_ID BATCH_INFO

No partial or transitive dependencies, 3NF

AUDIT(AUDIT_ID, RECIPE_ID, USER_ID, CHANGE_DATE, PARAMETER, VALUE_BEFORE, VALUE_AFTER)

AUDIT_ID RECIPE_ID USER_ID CHANGE_DATE PARAMETER VALUE_BEFORE VALUE_AFTER

No partial or transitive dependencies, 3NF

8) Solvent Usage (History) Relation

HISTORY(USAGE_ID, SOLVENT_ID, QUANTITY, USER_ID, ROOM_ID, USE_DATE, BATCH_INFO, USE_COST)

USAGE_ID SOLVENT_ID QUANTITY USER_ID ROOM_ID USE_DATE BATCH_INFO USE_COST

1 User Identification • User identifications are assigned by

Functional Dependencies Analysis:

Department ID → Department Name

DEPARTMENT(department ID, department name)

2 Solvent Identification An entity set or table is needed to keep

Functional Dependencies Analysis:

There are no partial or transitive dependencies.

Solvent Identification → Solvent Description, Cost Per Kilogram

SOLVENT (Solvent ID, Solvent Description, Cost Per Kilogram)

Relation Primary Key Foreign Key

3 Room Identification • Not all solvents are piped or

Functional Dependencies Analysis:

Room Identification → Building Location

ROOM_SOLVENT (Room Identification, Solvent ID)

Relation Primary Key Foreign Key

4 Tank ID • If the tank type is fixed, its room

Functional Dependencies Analysis:

TANK(Tank ID, Tank Size, Type, Room Location)

Relation Primary Key Foreign Key

Functional Dependencies Analysis:

Recipe ID → Recipe Description, Date Created, Creation User ID, Version,

RECIPE_ROOM(Recipe ID, Room ID)