project design report

GROUP # 19

PROJECT DESIGN REPORT

CARGO BILKENT

CS352 – DATABASE MANAGEMENT SYSTEMS

GROUP MEMBERS

BERKAY AYDIN

CAN TUZLA

UMUT EKMEKÇİ

1

Contents 1. Database Design ............................................................................................................................. 2

1.1. Revised E/R Diagram ................................................................................................................ 2

2. Relations, Functional Dependencies and Normal Forms .................................................................. 3

2.1. Table Schemas ......................................................................................................................... 3

Entitiy Schemas ........................................................................................................................... 3

Relation Schemas ........................................................................................................................ 4

2.2. SQL Statements for Creating Tables .......................................................................................... 5

Entities ........................................................................................................................................ 5

Relationships............................................................................................................................... 7

3. Funtional Components .................................................................................................................... 9

3.1. Use Cases/Scenarios ................................................................................................................. 9

3.2 Data Structures and Algorithms ............................................................................................... 13

3.2.1 Data Structures................................................................................................................. 13

3.2.2 Algorithms ........................................................................................................................ 13

4. GUI Components and SQL Queries ................................................................................................ 14

5. Advanced SQL Queries .................................................................................................................. 31

5.1 Views ...................................................................................................................................... 31

5.2 Reports ................................................................................................................................... 32

2

1. Database Design

1.1. Revised E/R Diagram

Figure 1: Revised E/R Diagram

3

2. Relations, Functional Dependencies and Normal Forms

2.1. Table Schemas

Entitiy Schemas

Employee(e_id:integer, e_fname:string, e_lname:string, password:string, birthdate:date, gender:string, address:string, startdate:date, phone:string) Functional Dependencies: e_id ->ALL Candidate Keys: e_id Normal Forms: BCNF Domain Information: gender is defined to be a string with domain “Male” and “Female”. OfficeEmployee(e_id:integer, e_fname:string, e_lname:string, password:string, birthdate:date, gender:string, address:string, startdate:date, phone:string) Functional Dependencies: e_id ->ALL Candidate Keys: e_id Normal Forms: BCNF Domain Information: gender is defined to be a string with domain “Male” and “Female”. Manager(e_id:integer, e_fname:string, e_lname:string, password:string, birthdate:date, gender:string, address:string, startdate:date, phone:string) Functional Dependencies: e_id ->ALL Candidate Keys: e_id Normal Forms: BCNF Domain Information: gender is defined to be a string with domain “Male” and “Female”. Driver(e_id:integer, e_fname:string, e_lname:string, password:string, birthdate:date, gender:string, address:string, startdate:date, phone:string) Functional Dependencies: e_id ->ALL Candidate Keys: e_id Normal Forms: BCNF Domain Information: gender is defined to be a string with domain “Male” and “Female”. Vehicle(plate:string, capacity:integer, model:string, brand:string, startdate:date) Functional Dependencies: plate->ALL Candidate Keys: plate Normal Forms: BCNF Branch(b_id:integer, address:string, name:string, phone:string) Functional Dependencies: b_id->ALL, address->ALL Candidate Keys: b_id, address, phone Normal Forms: BCNF Cargo(c_id:integer, content:string, weight:integer, height:integer, volume:integer, fromC:string, toC:string, s_date:date, r_date:date,isReceived:boolean) Functional Dependencies: c_id->ALL Candidate Keys: c_id

4

Normal Forms: BCNF Domain Information: content is defined to be a string with domain ‘document’, ’liquid’,’fragile’, ‘regular’, ‘other’. Customer(cus_id:integer, c_fname:string, c_lname:string, address:string, phone:string) Functional Dependencies: cus_id->ALL Candidate Keys: cus_id Normal Forms: BCNF Bill(b_id:integer, price:integer, billing_address:string) Functional Dependencies:b_id->ALL Candidate Keys:b_id Normal Forms:BCNF

Relation Schemas

Collects(e_id:integer, c_id:integer) Functional Dependencies: {e_id, c_id} -> ALL Candidate Keys: {e_id, c_id} Normal Forms: BCNF Foreign Keys: e_id references to e_id in OfficeEmployee table. c_id references to c_id in Cargo table. Manages(e_id:integer, b_id:integer) Functional Dependencies: {e_id, b_id} -> ALL Candidate Keys: {e_id, b_id} Normal Forms: BCNF Foreign Keys: e_id references to e_id in OfficeEmployee table. b_id references to b_id in Branch table. WorksIn(e_id:integer, b_id:integer) Functional Dependencies: {e_id, b_id} -> ALL Candidate Keys: {e_id, b_id} Normal Forms: BCNF Foreign Keys: e_id references to e_id in Employee table. b_id references to b_id in Branch table.

Drives(e_id:integer, plate:string) Functional Dependencies: {e_id, plate} -> ALL Candidate Keys: {e_id, plate} Normal Forms: BCNF Foreign Keys: e_id references to e_id in Employee table. plate references to plate in Vehicle table. TransportedIn(c_id:integer, plate:string) Functional Dependencies: {c_id, plate} -> ALL

5

Candidate Keys: {c_id, plate} Normal Forms: BCNF Foreign Keys: c_id references to c_id in Cargo table. plate references to plate in Vehicle table. Sends(cus_id:integer, c_id:integer) Functional Dependencies: {cus_id, c_id} -> ALL Candidate Keys: { cus_id, c_id } Normal Forms: BCNF Foreign Keys: cus_id references to cus_id in Customer table. c_idreferences to c_id in Cargo table. Receives(cus_id:integer, c_id:integer) Functional Dependencies: {cus_id, c_id} -> ALL Candidate Keys: { cus_id, c_id } Normal Forms: BCNF Foreign Keys: cus_id references to cus_id in Customer table. c_idreferences to c_id in Cargo table. Has(c_id:integer, bill_id:integer) Functional Dependencies: {c_id, bill_id} -> ALL Candidate Keys: { c_id, bill_id } Normal Forms: BCNF Foreign Keys: c_id references to c_id in Cargo table. bill_idreferences to bill_id in Bill table.

2.2. SQL Statements for Creating Tables

Entities

CREATE_TABLE Employee(

e_id INTEGER AUTO_INCREMENT,

e_fname VARCHAR(50) NOT NULL,

e_lname VARCHAR(50) NOT NULL,

password VARCHAR(20) NOT NULL,

birthdate DATETIME NOT NULL,

gender gendertype NOT NULL,

address VARCHAR(250),

startdate DATETIME,

phone VARCHAR(15),

PRIMARY KEY(e_id)

)

CREATE_TABLE OfficeEmployee(








6

startdate DATETIME,

phone VARCHAR(15),

PRIMARY KEY(e_id)

)

CREATE_TABLE Manager(








startdate DATETIME,

phone VARCHAR(15),

PRIMARY KEY(e_id)

)

CREATE_TABLE Driver(








startdate DATETIME,

phone VARCHAR(15),

PRIMARY KEY(e_id)

)

CREATE_TABLE Vehicle (

plate VARCHAR(8) NOT NULL,

capacity INTEGER NOT NULL,

model VARCHAR(30) NOT NULL,

brand VARCHAR(30) NOT NULL,

startdate DATETIME NOT NULL,

PRIMARY KEY (plate)

)

CREATE_TABLE Branch (

b_id INTEGER AUTO_INCREMENT,

address VARCHAR(250) NOT NULL,

name VARCHAR(50) NOT NULL,

phone VARCHAR(15) NOT NULL,

PRIMARY KEY (b_id),

UNIQUE KEY (address),

UNIQUE KEY (phone)

)

CREATE_TABLE Cargo (

c_id INTEGER AUTO_INCREMENT,

content contenttype NOT NULL,

weight INTEGER NOT NULL,

height INTEGER NOT NULL,

7

volume INTEGER NOT NULL,

fromc VARCHAR(20) NOT NULL,

toc VARCHAR (20) NOT NULL,

s_date DATETIME NOT NULL,

r_date DATETIME,

is_received BOOLEAN NOT NULL,

PRIMARY KEY (c_id)

)

CREATE_TABLE Customer (

cus_id INTEGER AUTO_INCREMENT,

c_fname VARCHAR(50) NOT NULL,

c_lname VARCHAR(50) NOT NULL,

address VARCHAR(250) NOT NULL

PRIMARY KEY (cus_id)

)

CREATE_TABLE Bill (

bill_id INTEGER AUTO_INCREMENT,

price INTEGER NOT NULL,

billing_address VARCHAR(250) NOT NULL,

PRIMARY KEY (bill_id)

)

Relationships

CREATE_TABLE Collects(

e_id INTEGER,

c_id INTEGER,

PRIMARY KEY (e_id, c_id),

FOREIGN KEY (e_id) REFERENCES OfficeEmployee(e_id),

FOREIGN KEY (c_id) REFERENCES Cargo(c_id)

ON DELETE CASCADE

)

CREATE_TABLE Manages(

e_id INTEGER,

b_id INTEGER,

PRIMARY KEY (e_id, b_id),

FOREIGN KEY (e_id) REFERENCES Manager(e_id)

ON DELETE CASCADE,

FOREIGN KEY (b_id) REFERENCES Branch(b_id)

ON DELETE CASCADE

)

CREATE_TABLE WorksIn(

e_id INTEGER,

b_id INTEGER,

PRIMARY KEY (e_id, b_id),

FOREIGN KEY (e_id) REFERENCES Employee(e_id)

ON DELETE CASCADE,

FOREIGN KEY (b_id) REFERENCES Branch(b_id)

ON DELETE CASCADE

)

8

CREATE_TABLE Drives(

e_id INTEGER,

plate VARCHAR(8),

PRIMARY KEY (e_id, plate),

FOREIGN KEY (e_id) REFERENCES Driver(e_id)

ON DELETE CASCADE,

FOREIGN KEY (plate) REFERENCES Vehicle(plate)

ON DELETE CASCADE

)

CREATE_TABLE TransportedIn(

c_id INTEGER,

plate VARCHAR(8),

PRIMARY KEY (c_id, plate),


ON DELETE CASCADE,

FOREIGN KEY (plate) REFERENCES Vehicle(plate)

)

CREATE_TABLE Sends(

cus_id INTEGER,

c_id INTEGER,

PRIMARY KEY (cus_id, c_id),

FOREIGN KEY (cus_id) REFERENCES Customer(cus_id),


ON DELETE CASCADE

)

CREATE_TABLE Receives(

cus_id INTEGER,

c_id INTEGER,

PRIMARY KEY (cus_id, c_id),

FOREIGN KEY (cus_id) REFERENCES Customer(cus_id),


ON DELETE CASCADE

)

CREATE_TABLE Has(

c_id INTEGER,

bill_id INTEGER,

PRIMARY KEY (c_id, bill_id),


ON DELETE CASCADE,

FOREIGN KEY (bill_id) REFERENCES Bill(bill_id)

)

9

3. Funtional Components

3.1. Use Cases/Scenarios

Figure 2: Use Case Diagram

Collect Cargo

Preconditions: Office employee is authorized. The cargo that is being sent meets the cargo

transportation constraints and limitations.

Post conditions: New cargo is added to the database.

Actor: Office Employee

Main Scenario: Office employee wants to add a new cargo. She enters the content, weight,

height, and volume of the cargo to the system. She also specifies from where the cargo is

10

sent and to where it will arrive. The system automatically generates a sending date and a

unique cargo id.

Alternate Scenario: If the customer wants to cancel her cargo before it is transported, office

employee may delete cargo from the database.

Generate Bill

Preconditions: Office employee is authorized. She registers the cargo to the system including

all of its attributes.

Post conditions: Bill of the related cargo is added to the database.


Main Scenario: After office employee collects a new cargo and it is successfully registered to

the database, the system automatically generates a bill including a unique bill id and a price

calculated according to the distance between the source and the destination cities, weight,

height, and volume of the cargo.

Register Customer

Preconditions: Office employee is authorized. The cargo that is being sent meets the cargo

transportation constraints and limitations.

Post conditions: The customer who sends and the customer who receives the cargo are

added to the database.


Main Scenario: When office employee collects the cargo, she wants to add two new

customers to the system. One of them is sender and the other one is receiver. She registers

their names, addresses, and phone numbers to the system and the system assigns a unique

customer id for each customer automatically.

Alternate Scenario: When office employee collects the cargo, she wants to add two new

customers to the system. One of them is sender and the other one is receiver. However, one

of them or both of them may already be registered in the system. In this case, either office

employee registers only one of them or no customer is added to the system.

11

View Employees

Preconditions: Manager is authorized.

Post conditions: No change occurs in the employee list.

Actor: Manager

Main Scenario: Manager wants to see the employees of her branch. She reaches the

information of all employees including their names, addresses, genders, starting dates,

employee ids, and birthdates.

Alternate Scenario: Manager wants to see a specific employee of her branch. She reaches

the information of that employee including her name, address, gender, starting date,

employee id, and birthdate.

Add Employees


Post conditions: New employee is added to the database.

Actor: Manager

Main Scenario: Manager wants to add a new employee to her branch. She enters the

required information of the new employee including her name, address, gender, starting

date, employee id, and birthdate to the system. Manager also specifies the job status of the

new employee as “office employee”, “driver”, or “manager”.

Remove Employees


Post conditions: An employee is removed from the database.

Actor: Manager

Main Scenario: Manager wants to delete an employee of her branch from the database. She

specifies employee id for the deletion operation.

Update Employees


12

Post conditions: The personal information of an employee is updated in the database.

Actor: Manager

Main Scenario: Manager wants to update the information of an employee in her branch. She

specifies employee id for this update operation.

View Cargo Log


Post conditions: All cargo log of a branch is shown and no change occurs in the database.

Actor: Manager

Main Scenario: Manager wants to see the cargo log of her branch. She reaches the

information about all registered cargos including their senders, receivers, cargo ids,

sending/receiving dates, bills, start/end locations etc.

Alternate Scenario: Manager wants to see the cargo log of her branch within a specified time

period. After she enters desired time period, she reaches the information about all

registered cargos between that time period including their senders, receivers, cargo ids,

sending/receiving dates, bills, start/end locations etc.

Update Cargo Log

Preconditions: Driver is authorized.

Post conditions: The status of a registered cargo is updated in the database.

Actor: Driver

Main Scenario: Driver wants to update the status of a cargo that is being transported with its

cargo id. When the cargo reaches its destination, driver updates its status as “on delivery”.

After the cargo is delivered to the receiver, driver again updates the cargo status as

“delivered”.

View Cargo Address

Preconditions: Driver is authorized.

Post conditions: The address information of a registered cargo is shown and no change

occurs in the database.

13

Actor: Driver

Main Scenario: Driver wants to see the address of a cargo that is being transported. Driver

specifies the cargo id in order to get the address of the desired cargo.

3.2 Data Structures and Algorithms

3.2.1 Data Structures

For the attribute domains, basic data types offered by PostgreSQL are used. These are

INTEGER, VARCHAR, DATETIME, and BOOLEAN. In addition to these data types, gendertype is

used to define the gender attribute domain for Employee, OfficeEmployee, Manager, and

Driver tables. Moreover, contenttype is used to define the content attribute domain for

Cargo table. These are defined as:

CREATE DOMAIN gendertype CHAR(1) DEFAULT ‘?’

CHECK (VALUE IN (‘Y’,’N’,’?’))

CREATE DOMAIN contenttype VARCHAR DEFAULT ‘OTHER’

CHECK (VALUE IN ‘document’, ’liquid’,’fragile’, ‘regular’,

‘other’))

3.2.2 Algorithms

In Cargo Bilkent application many algorithms will be used in order to achieve the general processing

of data. These usually are going to be simple and robust for correctness of application. One of the

most notable algorithms that we will use is the price determination algorithm. This algorithms will

describe how the price of a given cargo is determined. It is as follows:

Generate Cargo (Cargo C)

base <- getBaseFor(C.content)

physicalBase <- base * C.weight * C.height * C.volume

distance <- getDistance(C.fromC, C.toC)

if (distance < 250)

price<- physicalBase

else

price <- physicalBase * distance/250

return price

Given algorithm generates a value (base) by considering the base price for each content firstly. This

value is used for computing physical base. Then algorithm checks whether distance is more than 250

kms and if it is more than 250 kilometers, it multiplies it with distance/250. Distance here is the

distance between two cities.

14

4. GUI Components and SQL Queries Login Screen

Figure 3: Login Screen

Short Explanation: This screen redirects user to the part of application in which she is

authorized according to her user type.

Input Field and Corresponding Variables:

uid : @uid

password : @password

Functional Components and Algorithms:

isAuthorizedManager(): This function checks whether the user is a manager or not.

if @password == SELECT M.password

FROM Manager M

WHERE M.e_id=@uid

return true;

else

return false;

15

isAuthorizedOfficeEmployee(): This function checks whether the user is an office

employee or not.

if @password == SELECT O.password

FROM OfficeEmployee O

WHERE O.e_id=@uid

return true;

else

return false;

isAuthorizedDriver(): This function checks whether the user is a driver or not.

if @password == SELECT D.password

FROM Driver D

WHERE D.e_id=@uid

return true;

else

return false;

isAuthorized(): This function is called when the user clicks the login button and

redirects user to her homepage if she has entered correct id and password.

if(isAuthorizedManager() )

redirect user to the manager homepage

else if(isAuthorizedOfficeEmployee() )

redirect user to the office employee homepage

else if(isAuthorizedDriver() )

redirect user to the driver homepage

else

warn the user that she has entered wrong user id or

password

16

Show Employee Screen (as Manager)

Figure 4: Show Employee Screen

Short Explanation: This screen is accessed by the manager in order to see all employees or a

specific employee in her branch. Manager can see the more detailed information of an

employee by clicking her row. After this step, she can also update that information or

remove the employee from the database. If the manager wants to add a new employee to

her branch, she can click “Add New Employee” button. To view the all employees, the

following query is used.

SELECT E.e_id, E.e_fname, E.e_lname, E.phone

FROM Employee E

17

Add New Employee Screen (as Manager)

Figure 5: Add Employee Screen

Short Explanation: This screen is accessed by the manager in order to add a new employee

to her branch. The employee id is generated by the system automatically. When the

manager clicks “Add New Employee” button, the following query is used.

INSERT INTO Employee(e_id, e_fname, e_lname, birthdate, gender,

address, startdate, phone)

VALUES(@uid, @fname, @lname, @birthdate, @gender, @address,

@today, @phone)

INSERT INTO OfficeEmployee(e_id, e_fname, e_lname, birthdate,

gender, address, startdate, phone)

VALUES(@uid, @fname, @lname, @birthdate, @gender, @address,

@today, @phone)

Note: @uid is generated by the system automatically.

18

Show/Update Employee Screen (as Manager)

Figure 6: Show/Update Employee Screen

Short Explanation: This screen is accessed by the manager in order to update the

information of an employee in her branch. When the manager clicks “Update” button, the


UPDATE Employee

SET phone=@phone, address=@address

WHERE e_id=@uid

UPDATE OfficeEmployee

SET phone=@phone, address=@address

WHERE e_id=@uid

When the manager clicks “Delete Employee” button, the following query is used.

DELETE

FROM Employee E

WHERE E.e_id=@uid

DELETE

FROM OfficeEmployee O

WHERE O.e_id=@uid

19

View Cargo Log (as Manager)

Figure 7: View Cargo Log Screen

Short Explanation: This screen is accessed by the manager so as to view the cargo log in her

branch. When the manager enters the employee id and clicks the “Search” button, the


SELECT C.c_id, O.e_fname, O.e_lname, C1.c_fname, C1.c_lname,

C2.c_fname, C2.c_lname, C.s_date)

FROM Cargo C, OfficeEmployee O, Customer C1, Customer C2,

Sends S, Receives R, Collects CL

WHERE O.e_id=@uid

AND CL.e_id=O.e_id

AND C.c_id=CL.c_id

AND S.c_id=CL.c_id

AND R.c_id=CL.c_id

AND C1.cus_id=S.cus_id

AND C2.cus_id=R.cus_id

20

Send Cargo Screen (as Office Employee)

Figure 8: Send Cargo Screen

Short Explanation: This screen is accessed by the office employee in order to register a new

cargo to the database. When the office employee enters the required information and clicks

the “Send Cargo” button, the following query is used.

INSERT INTO Cargo(c_id, content, weight, height, volume, fromC,

toC, s_date, r_date, isReceived)

VALUES(@c_id, @content, @weight, @height, @volume, @sAddress,

@rAddress, @today, null, false)

INSERT INTO Customer(cus_id, c_name, address, phone)

VALUES(@cus_id2, @sName, @sAddress, @sPhone)

INSERT INTO Customer(cus_id, c_name, address, phone)

VALUES(@cus_id1, @rName, @rAddress, @rPhone)

INSERT INTO Sends(cus_id, c_id)

VALUES(@cus_id2, @c_id)

INSERT INTO Receives(cus_id, c_id)

VALUES(@cus_id1, @c_id)

21

Update Cargo Screen - 1 (as Office Employee)

Figure 9: Update Cargo Screen

Short Explanation: This screen is accessed by the office employee in order to update the

information of a cargo which is registered in the database. When the office employee enters

the cargo id and clicks the “Search” button, the following query is used.

SELECT C.c_id, C1.name, C2.name, C.s_date

FROM Cargo C, Customer C1, Customer C2, Sends S, Receives R

WHERE C.c_id=@c_id

AND S.c_id=C.c_id

AND R.c_id=C.c_id



22

Update Cargo Screen - 2 (as Office Employee)

After search result is displayed and the office employee clicks the result row, the following

screen appears and the following query is executed.

Figure 10: Update Cargo Screen

UPDATE Customer

SET address=@newRaddress

WHERE cus_id=@cus_id

23

Search Cargo Screen - 1 (as Office Employee)

Figure 11: Search Cargo Screen 1

Short Explanation: This screen is accessed by the office employee in order to search a cargo

which is registered in the database. When the office employee enters the cargo id and clicks

the “Search” button, the following query is used.



WHERE C.c_id=@c_id

AND S.c_id=C.c_id

AND R.c_id=C.c_id



24



Short Explanation: This screen is accessed by the office employee. After the office employee

clicks the resulting row on previous screen, the following query is used.

SELECT *

FROM Cargo C

WHERE C.c_id=@c_id

SELECT *

FROM Customer C1, Receives R

WHERE R.c_id=@c_id AND C1.cus_id=R.cus_id

SELECT *

FROM Customer C2, Sends S

WHERE S.c_id=@c_id AND C2.cus_id=S.cus_id

25




clicks the “Show Vehicle/Driver” button on previous screen, the following query is used.

SELECT D.name, D.phone, V.plate, V.model, V.brand

FROM Driver D, Vehicle V, TransportedIn T, Drives D2

WHERE T.c_id=@c_id

AND D2.plate=T.plate

AND V.plate=T.plate

AND D.e_id=D2.e_id

26




clicks the “Show Employee” button on ‘search cargo screen – 2’, the following query is used.

SELECT O.name, O.phone, B.name, B.phone

FROM OfficeEmployee O, Branch B, WorksIn W, Collects C

WHERE C.c_id=@c_id

AND O.e_id=C.e_id

AND W.e_id=C.e_id

AND B.b_id=W.b_id

27

Delete Cargo Screen - 1 (as Office Employee)

Figure 14: Delete Cargo Screen 1

Short Explanation: This screen is accessed by the office employee in order to delete a cargo

which is registered in the database. When the office employee enters the cargo id and clicks

the “Search” button, the following query is used.



WHERE C.c_id=@c_id

AND S.c_id=C.c_id

AND R.c_id=C.c_id



28

Delete Cargo Screen - 2 (as Office Employee)

Figure 15: Delete Cargo Screen 2


clicks the resulting row on previous screen, the following queries are used.

SELECT *

FROM Cargo C

WHERE C.c_id=@c_id

SELECT *

FROM Customer C1, Receives R

WHERE R.c_id=@c_id AND C1.cus_id=R.cus_id

SELECT *

FROM Customer C2, Sends S

WHERE S.c_id=@c_id AND C2.cus_id=S.cus_id

After the office employee confirms the deletion, the following queries are executed.

DELETE FROM Cargo C WHERE C.c_id=@c_id

DELETE FROM Sends S WHERE S.c_id = @c_id

DELETE FROM Receives R WHERE R.c_id = @c_id

29

Update Receival Screen (as Driver)

Figure 16: Update Receival Information Screen

Short Explanation: This screen is accessed by the driver in order to update the delivery status

of a registered cargo. When the driver delivers the cargo, he can search the desired cargo

with its cargo id or employee id of the employee who registered the cargo as in previous

screens. If the driver wants to update the status of the cargo, he clicks the corresponding

row and confirms the status update. For this procedure, the following queries are used.



WHERE C.c_id=@c_id

AND S.c_id=C.c_id

AND R.c_id=C.c_id



UPDATE Cargo

SET isReceived=true

WHERE c_id=@c_id

30

View Cargo Address Screen (as Driver)

Figure 17: View Cargo Address Screen

Short Explanation: This screen is accessed by the driver in order to view the delivery address

of a registered cargo. Driver can search the desired cargo with its cargo id or employee id of

the employee who registered the cargo as in previous screens. If the driver wants to see the

address of the cargo, he clicks the corresponding row. For this procedure, the following

queries are used.



WHERE C.c_id=@c_id

AND S.c_id=C.c_id

AND R.c_id=C.c_id



SELECT C.address

FROM Customer C, Receives R

WHERE R.c_id=@c_id AND C.cus_id=R.cus_id

31

5. Advanced SQL Queries

5.1 Views

Not Received Cargo View

CREATE VIEW NotReceivedCargos AS

SELECT *

FROM Cargo C

WHERE C.isReceived = FALSE

Cargos That Are Collected Today

CREATE VIEW CargoToday AS

SELECT *

FROM Cargo C

WHERE s_date = GETDATE()

Employee Phone Book

CREATE VIEW EmployeePhoneBook AS

SELECT Employee.e_fname, Employee.e_lname Employee.phone

FROM Employee

Branch Phone Book

CREATE VIEW BranchPhoneBook AS

SELECT Branch.name, Branch.phone

FROM Branch

32

5.2 Reports

Yesterday’s Cargos Report

SELECT COUNT(*)

AS ‘Yesterday’s Cargo Report’

FROM Cargo C

WHERE C.s_date = (GETDATE() – interval 1 day)

Office Employee’s Cargo Report

SELECT O.e_fname, O.e_lname, COUNT(C.c_id)

AS ‘Office Employee Cargo Report’

FROM OfficeEmployee O, Collects C

WHERE O.e_id = C.e_id

GROUP BY C.e_id

Cargo Report of Branches

SELECT B.name COUNT(C.c_id)

AS ‘Branch Cargo Report’

FROM Branch B, WorksIn W, Employee E, Collects C

WHERE B.b_id = W.b_id

AND W.e_id = E.e_id

AND E.e_id = C.e_id

GROUP BY B.b_id

project design report

Documents