Download Entities

[12] Web Site Design
In this project, I will design a database schema for a company to assist in
addressing some business issues such as employee management, customer
management, account management, and customer support management.
The database has tables for each of the above. The company sells Internet
access to its customers and needs to provide adequate support model to
customer’s users and bill the customer accordingly. I have used constraint
relationships to design a model for bill calculation and employee
compensation. The diagram below shows the interaction between the various
entities of the database.
1– Entities and attributes .
A - Departments
did
name
D001
salesops
D002
Operations
D003
Sales
D004
Management
B – Managers
dsize
title
d
t
d
t
d
t
dsize(no of employees)
10
15
20
5
0<=d <=5, t = ‘V.P’
5< d<=15, t = ‘Manager’
d >15, t = ‘dept Head’
C – Cust_dept.
Custid
did
C001
D002
C002
D001
C003
D003
C004
D003
C005
D003
D –Customer
Custid
name
C001
Fry’s Electronic
C002
AOL
C003
ATT
C004
Fiberlink
C005
GRIC
E- User_cust
uid
Cust_id
U001
C001
U002
C001
U101
C002
U201
C003
U301
C004
U401
C005
address
San Jose
Michigan
Gilroy
Mountain view
Milpitas
F - Employees
ssn
111-222-3333
222-333-444
333-444-555
444-555-6666
555-666-7777
Name
Anselm
Tim
John
Mary
Richard
email
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
G- Emp_schedules
ssn
hours
111-222-3333 20
222-333-4444 50
333-444-5555 10
444-555-6666 80
555-666-7777 35
H- Emp_Type
hours
h
h
type
t
t
I – Account
Custid
C001
C002
C003
C004
C005
Mntly usage(minutes)
1000
5000
10000
30000
40000
0<=h<=40, t = ‘Part Time’
h> 40, t = ‘Full Time’
J- Cust_Users
uid
name
U001
Oliver
U002
Betty
U003
Wanda
M – User-Traffic
uid
userusage (minutes)
U001
10
U002
150
U003
520
O – Emp_dept
ssn
did
111-222-3333 D002
login
Amoliv1
Bet123
Wan876
222-333-4444
333-444-5555
444-555-6666
555-666-7777
D001
D003
D003
D003
P- Case_owners
Caseid
C001
C002
C003
C004
C005
ssn
111-222-3333
222-333-4444
333-444-5555
444-555-6666
555-666-7777
Q – Cases
Caseid
C001
C002
C003
C004
C005
title
Cannot connect to pop in Paris
Pop in Michigan is busy on all attempts
No dial tone on connection
Got a voice mail while dialing pop in mexico city
PPP connection timed out waiting for response
Cust_id
C001
C001
C002
C003
C004
Age - hrs
20
50
20
10
56
-------------------------------------------------------------------[13] ONLINE COMPUTER PURCHASING DATABASE
A computer manufacturer offers possibility of purchasing computers via the Internet. The
customer can select a computer on the manufacturer’s web page. The list items that are
available are keyboards, wireless routers, laser printers, desktops, mini book PCs, servers,
memory, monitor, modem, etc.
The customer may choose to order the computer online or may request that the
salesperson contact him/her to explain order details, negotiate the price, etc. before the
order is actually placed. To place an order the customer must fill out the payment
information. Acceptable payments methods are credit cards and check. After customer’s
order has been entered into the system, the salesperson checks the order and prints the
invoice. Then the invoice is sent to the warehouse with details of the item. Once the order
has been entered, the system sends a confirmation, email message to the customer with
details of the order. While waiting for the arrival of the computer customer can check the
order status online at any time.
Customer can check advertisements online to know more about the latest discounts or
he/she can also contact Salesperson.
Entities and Attributes
Entity Name
Customer
Item
SelectedItem
OrderPlaced
Payment
Salesperson
Invoice
Advertisement
Warranty
Attributes
customerID, customerName, street, city, state, zip, phone, emailID,
creditNumber.
itemID, itemName, description, price, itemInstock
cID, iID, wID, warrantyStartDate, warrantyEndDate
orderID, cID, orderDate , shippingCharge, sID.
cID, paymentMethod, paymentDate
salespersonID, salespersonName, taxTerm, phone, emailID
invoiceID, sID, cID, oID, invoiceDate
advertisementID, iID, discount, startDate, endDate.
warrantyID, iID, type, warrantyAmt, noOfMonths.
Description of Entities
1) Customer:
Details of the customer are specified in this entity, which includes customerID
(which is unique for each customer), name, street, city, state, zip, phone, emailID, and
credit card number.
2) Item:
Details of the items are specified in this entity, which includes itemID (which is
unique for each item), item name, price, description and items available in stock.
3) SelectedItem:
Details about the item selected by the customer, which includes computer
items that belong to each computer, is specified. It includes itemID customerID,
warrantyID, Start and End date of the warranty
4) OrderPlaced:
Details about the customer order will be given by this entity. It includes orderID
(which is unique for each order), customerID (to keep track which customer placed which
order), date of the order, shipping charge, and salespersonID who checks the order (and if
customer wishes to contact a salesperson then he/she can contact this salesperson to know
about the order details before he/she places an order)
5) Payment:
Details about the mode of payment are specified in this entity. It includes
customerID, payment method (credit card or check) selected by the customer, date of
payment, amount received from the customer.
6) Salesperson:
Details of the salesperson are specified in this entity, which includes
salespersonID (which is unique for each salesperson), their name, tax term, phone, and
emailID.
7) Invoice:
Details about the invoice created by the salesperson are specified. It includes
invoiceID (which is unique for each order), customerID, orderID, salespersonID who
prints the invoice, date of the invoice send by the salesperson to the warehouse.
8) Advertisement:
Details about the advertisements are specified in this entity. It includes
advertisementID (each advertisement is given an unique id), itemID that gets discount,
discount amount and start and end date of each advertisement.
9) Warranty:
Details about the warranty are specified in this entity. It includes warrantyID,
itemID that gets warranty, type (it can be normal warranty or extended warranty),
warranty amount, and warranty period which is given as number of months
-------------------------------------------------------------------[14] Banking System
This project is based on a Banking System. Our system is composed of various relational
tables that integrate a working banking database. Our relational data model describes the
database as a set of tables. The relation names described below together with their
schemes compose the banking database scheme.
2. Description
The bank system is composed of the relations, branch, customer, employee, account,
depositor, loan, borrower, credit card, and cc_cust.
The bank system is organized into branches. Each branch has its own unique name, and
it is located in a particular city. The bank monitors the assets of each branch.
Bank customers are identified by their customer-identification values. The bank stores
each customer’s identification, name, street, and city they live in. A customer may have
accounts, take out loans, and apply for a credit card. A customer can deposit and
withdraw money from the specified account. They can also make payments for any loans
they have taken out from a particular branch and also make credit card payments. A
customer may be associated with a particular banker, who may act as a loan officer or
personal banker for that customer.
Bank employees are identified by their employee-identification values. The bank stores
information related to an employee. The employee’s name, the employee’s phone, and
employment start date.
The bank offers different types of services such as customers’ accounts. A customer can
have more than one account. The bank stores information related to the customer’s
account. Each account has a unique account number, branch, and balance.
The bank also offers loans. A loan is given by a particular branch and can be held by one
or more customers. The bank stores information related to the loan. A loan is identified
by a unique loan id, loan amount, and the branch name from where the loan was taken
out. For each loan, the bank keeps track of the loan payments and the date of when the
payments are paid.
The bank also offers credit cards. A credit card is given by a particular branch and can
be held by one or more customers. The bank stores information related to a credit card. A
unique credit card number identifies a credit card and the credit card amount.
Customers can make payments for their loans and credit cards. The bank stores
information related to all the payments. Each payment has a payment number. The bank
also stores the date, when the payment was made, and the amount paid. It provides the
associated loan number and credit card number for which the payment was made in their
respective tables.
The bank has depositor information. The bank stores information pertaining to a
depositor. It contains the information as to which account is associated with which
customer. It stores the customer’s unique identification number and the customer’s
unique account identification number.
The bank also has borrower information. The bank stores information pertaining to a
borrower. It contains the information as to which loan is associated with which customer.
It stores the customer’s unique identification number and the customer’s loan
identification number.
The bank also has information regarding a customer that has a credit card. The bank
stores information pertaining to a credit card customer. It contains the information as to
which credit card is associated with which customer. It stores the customer’s unique
identification number and the customer’s credit card identification number.
3. Input Database
Each table has a name and each table defines a relation. The relations all contain
different attributes and arity. The following are the Banking System’s relational tables.
branch(name, city, assets)
This relation lists for different branches for a particular bank, their name, city, and the
assets of that particular branch. This relation has arity 3. The relation scheme for this
relation is (name, city, assets). The primary key is the name of the branch.
customer(custid, name, street, city )
This relation lists for a set of customers their identification (id), name, street, and city
they live in. There are 20 customers. This relation has arity 4. The relation scheme for
this relation is (custid, name, street, city). The primary key is the custid.
employee(empid, name, phone, start_date, emp_len)
This relation lists for a set of employees their identification (empid), name, phone
number, start date and the employment length. This relation has arity 5 and the relation
scheme is (empid, name, phone, start_date, emp_len). The primary key is empid.
account(accnum, branch, balance)
This relation lists for a set of accounts the account number, the account’s branch name,
and balance. This relation has arity 3 and the relation scheme is (acctnum, branch,
balance). The primary key is the accnum.
loan(loanid, branch, amount)
This relation lists for a set of loans their identification (loanid), branch of where the loan
was taken out from, and the amount. This relation has arity 3 and the relation scheme is
(loanid, branch, amount). The primary key is loanid and branch references branch
relation.
creditcard(ccnum, ccbalance, cclimit)
This relation lists for a set of credit cards their credit card number and credit card balance
This relation has arity 3 and the relation scheme is (ccnum, ccbalance, cclimit). The
primary key is ccnum.
depositor(custid, accnum)
This relation lists for a set of customers the customer identification and the customer’s
account identification. It contains the information as to which account is associated with
which customer. This relation has arity 2 and the relation scheme is (custid, accnum). The
primary key is custid and accnum. custid references the customer relation and accnum
references account relation.
borrower(custid, loanid)
This relation lists for a set of customers the customer identification and the customer’s
loan identification. It contains the information as to which loan is associated with which
customer. This relation has arity 2 and the relation scheme is (custid, loanid). The
primary key is custid and loanid. The custid references the customer relation and the
loanid references the loan relation.
cc_cust(custid, ccnum)
This relation lists for a set of customers the customer identification and the customer’s
credit card identification. It contains the information as to which credit card is associated
with which customer. This relation has arity 2 and the relation scheme is (custid, ccnum).
The primary keys are custid and ccnum. The custid references the customer relation and
ccnum references the credit_card relation.
loanpayment( pymt_num, pymt_amt, pymt_date, loanid)
This relation lists for a set of customers their payments made towards a loan. It contains
the payment number, payment amount, the date of the payment, and the loan id. This
relation has arity 4 and the relation scheme is (pymt_num, pynt_amnt, pymt_date,
loanid). The primary key is pymt_num and loanid.
ccpayment( pymt_num, pymt_amt, pymt_date, ccnum)
This relation lists for a set of customers their payments made towards a credit card. It
contains the payment number, payment amount, the date of the payment, and the credit
card number. This relation has arity 4 and the relation scheme is (pymt_num, pynt_amnt,
pymt_date, ccnum). The primary key is pymt_num and ccnum.
-------------------------------------------------------------------[15] VIRTUAL INTERACTIVE CAMPUS MAP (DATABASE)
This project can be viewed as a record of two parts processes: One was the
review of all the relations defined in MLPQ , the elimination of unnecessary
attributes, and the addition of more relations in the new Database to be
created in MySQL. The Second one was the development of two simple
application using JAVA. These applications’ main purposes were: 1- To
generate a Database in MySQL, add to this Database the required Tables of
our Campus Map, and populate those tables with certain data. 2- To query
those tables in order to retrieve information that would be available for any
user. For the latter one we developed a Simple GUI using SWING. This
simple application shows a as first window all the already defined statements
of our queries in our DataBase. The user needs to select any of those
queries and then click on the Show Results button to see a second Window
with actual information producted of the selected query. See figures in
Section 5.
For the creation of Database’s tables we reviewed all the relations from our
previous project and we defined them in a better way, so they can actually
embody useful information for any potential user who wants to use it. Here
are the modified Relations:
BUILDING: BUILDINGID NOT NULL PRIMARY KEY ,
LOWERCORNERX INTEGER,
LOWERCORNERY INTEGER,
UPPERCORNERX INTEGER,
BUILDINGNAME VARCHAR(15),
AREAID INTEGER
SCHOOLID INTEGER.
PERSON: PERSONID INTEGER NUT NULL PRIMARY KEY,
LOWERCORNERX INTEGER,
LOWERCORNERY INTEGER,
UPPERCORNERX INTEGER,
UPPERCORNERY INTEGER,
GENDER VARCHAR(12),
PERSONCATEGORY VARCHAR(15).
UNIVERSITY: UNIVERSITYID INTEGER NOT NULL PRIMARY KEY,
UNIVERSITYNAME VARCHAR(15),
YEARFOUNDED DATE.
SCHOOL: SCHOOLID INTEGER NOT NULL PRIMARY KEY,
SCHOOLNAME VARCHAR(15).
CAMPUSAREA: AREAID INTEGER NOT NULL PRIMARY KEY,
AREALOCATIONNAME VARCHAR(15),
CAMPUSID INTEGER.
CAMPUS: CAMPUSID INTEGER NOT NULL PRIMARY KEY,
NAMEOFCAMPUS VARCHAR(15),
UNIVERSITYID INTEGER.
ATTENDANCE : PERSONID INTEGER,
UNIVERSITYID INTEGER,
PURPOSEOFATTENDANCE VARCHAR(15).
OBSTACLE: OBSTACLEID INTEGER NOT NULL PRIMARY KEY,
LOWERCORNERX INTEGER,
LOWERCORNERY INTEGER,
UPPERCORNERX INTEGER,
UPPERCORNERY INTEGER,
TYPEOFOBSTACLE VARCHAR(15),
AREAID INTEGER.
PARK: PARKID INTEGER NOT NULL PRIMARY KEY,
LOWERCORNERX INTEGER,
LOWERCORNERY INTEGER,
UPPERCORNERX INTEGER,
UPPERCORNERY INTEGER,
PARKNAME VARCHAR(15),
AREAID INTEGER.
PATH: PATHID INTEGER NOT NULL PRIMARY KEY,
LOWERCORNERX INTEGER,
LOWERCORNERY INTEGER,
UPPERCORNERX INTEGER,
UPPERCORNERY INTEGER,
PATHNAME VARCHAR(15).
BENCH: BENCHID INTEGER NOT NULL PRIMARY KEY,
LOWERCORNERX INTEGER,
LOWERCORNERY INTEGER,
UPPERCORNERX INTEGER,
UPPERCORNERY INTEGER.
For the design of the query statements, many constraints were taken into
consideration. We were limited to few types of queries due to the inability of
MySQL to handle certain aggregation operators, such as Area, and set
operators, such as UNION, INTERSECT. Also, MySQL is unabled to handle
nested queries, so it held us back to retrieve more specific results from our
Database.
-------------------------------------------------------------------[16] PeterPan Farmers Market of California
The project implements a database representing various PeterPan Farmers-markets
located in different cities across California. The database uses the MLPQ system.
The goal of this project is to create a database with all possible information about
Farmers market. Users can query this database to
 Obtain information about vendors and their products.
 Obtain information about seasonal produce and their prices.
 Obtain information about locations of various farmers market.
1.1 Description
The project database consists of constraint and relational tables. The constraint tables
displays a map of California and various cities where Farmers market are located. It also
shows some major highways of California and market locations on these highways.
The database contains the tables in the following order:
1. California (id, x, y)
This table consists of constraint tuples to implement the map of California.
2. Highway (Hwy_id, x, y)
This table shows 3 major highways (101, 5,80) across California.
3. Market_Locations (Hwy_id, market_id, x, y)
This table locates the markets on a particular highway.
4. Crop_calender (season, seasonal_product, seasonal_ price)
Some of the produce are available during its season and also are available
at cheaper cost. This table informs the user the seasonal produce for a particular
season and its price during that season.
5. Product (Vname, pname, price)
The product table relates the product and its price to the Vendor table.
6. Schedule (market_id, from_month, to_month, day, start_time, end_time)
This table shows the year-around schedule of the farmers market. It also
displays the time of operation during the schedule. The schedule table is related to
the market table.
7. Vendor (vendor_id, vname, market_id, phno, type, boothnum)
This table represents the vendor details such as vendor_id, vendor
name, contact number; type of product the vendor is selling at the market and
allotted booth number in the market. The vendor table is also related to the
market table.
8. Market (market_id, mname, city, town, address)
This table provides market details such as market name, its address
and the city where the market is located.
The database also contains an intermediate table, market_Hwy (hwy_id, cityname, cnum)
that relates the highway and the market table.
-------------------------------------------------------------------[17] USA Travel
In this project, we propose to build a database to help user retrieve useful information
regarding some tourist attractions in any of the three States of California, Nevada or
Florida. We have chosen these three states because of their popularity in travel business.
It will allow user to enter the name of a city and retrieve information regarding it e.g.
existing hotels, tourist attractions in a specific category, highway information, existing
car-rentals, their prices and rating, and weather conditions.
Entities Defined:
State_name (sid, sname)
This table stores a unique id for each State and the State name. There are three different
States with id’s 1 through 3
sid -> State id (primary key)
sname -> State name
State (sid, x, y)
This table is used to store the maps of the States.
The attribute sid refers to State id in the table “State_name”.
The attributes “x”, “y” represents the location of the States in the form of constraint
tuples. These maps are close approximations of the actual maps.
State_city (sid, cid, cname)
This table contains information on State id and the cities located in each State.
Each city has a unique city id (cid) and the name (cname).
sid -> State id (primary key)
cid -> City id (primary key)
cname -> City name
City (cid, x, y)
This table is used to represent the maps of all cities.
The attribute cid refers to the City id in table “State_city “.
The attributes “x”, “y” are used to represent the locations of the cities in the form of
constraint tuples.
Route (rid_hwyNo, x, y)
This table stores information on the highways connecting all the cities in the States.
The attribute “rid_hwyNo” is used to represent the Highway Nos. such as 10,41, 441 etc.
The attribute “x” and “y” are used to represent the extent and the maps of these highways
in the form of linear approximations of the actual maps.
Hotel_id (cid, hid, hname)
This table is used to store information on various hotels in each city.
The attribute “hid” is unique for each hotel and “hname” stands for the hotel name.
cid -> Cityid (primary key)
hid -> Hotel id (primary key)
hname -> Hotel name
Hotel (hid, x, y)
This table represents the location of the hotels with their ids.
The attribute “hid” refers to the hotel id of the table “Hotel_id”.
The attributes “x”, “y” are the locations approximates by constraint tuples.
Tourist_Attraction_id (cid, tid, category, tname, contactNo)
This table is used to store names of tourist attractions and their contact nos. for each city
and in various categories.
cid -> City id (primary key)
tid -> Tourist Attraction id (primary key)
category -> Category in which it falls.
tname -> Tourist Attraction name
contactNo -> Contact No
Tourist_Attraction (tid, x, y)
This table is used to locate the tourist attractions with their ids.
The attribute “tid” is tourist attraction id, which refers to the table “Tourist_Attractio_id”.
The location is represented by the attributes “x”, “y”.
Car_rating (comp_id, cname, rating, start_price)
This table is used to store information on various car-rentals companies including their
names, ratings and start price.
comp_id -> company id (primary key)
cname -> car-rental company name
rating -> Rating for the company. Value can range from 1 to 5.
Start_price -> The minimum price of car-rental for that company.
Car_Rentals_id (crid, cid, comp_id)
This table contains the city ids and the different car-rental companies in each city. Each
car-rental company located in the city will have unique id (crid).
crid -> car-rental id (primary key)
cid -> City id
comp_id -> Company id
Car_rentals (crid, x, y)
This table is used to locate the car-rentals with their ids.
The attribute “crid” is car-rental id, which refers to the table “Car_Rentals_id”.
The location is represented by the attributes “x”, “y”.
Weather (cid, date, day_t, night_t)
This table provides the traveler some information on the forthcoming weather of a city.
cid -> City id
date -> represents the next 6 days of weather.
day_t -> Daytime temperature
night_t -> Nighttime temperature
Distance_Between_Cities (cid1, cid2, miles, hours)
This table contains information on the distances between cities and time that would be
taken to go from one city to another.
The attributes “cid1” and “cid2” represent the two cities between which the distances are
given.
The attribute “miles” represent the distance.
The attribute “hours” represent the time.
-------------------------------------------------------------------[18] Healthcare system
The cost of healthcare insurance has increased dramatically since the events of 911. Many companies are facing incredible challenges to stay profitable in today’s
downward economic environment. In order to reduce operation costs, ABC Company is
seeking a way to save on healthcare cost. The company will work together with
healthcare vendors to provide a healthcare plan that benefits both the company and its
employees.
The company will reserve some cash for employees to spend on healthcare. The
reserved cash is used to pay off patient’s medical and prescription bills. After the
reserved cash is exhausted, the patient is required to pay medical and prescription costs
based on his or her chosen plan coverage. The healthcare vendor will cover 100% of the
healthcare cost until the maximum out of pocket amount is reached. The new healthcare
plan will help ABC Company to save money when patients use their reserved cash
wisely.
The objective for this project is to build a database model on the MLPQ system to
simulate the real world healthcare application. In order to successfully accomplish this
objective, we need to understand how the healthcare application is developed and used
today. We chose United Healthcare [1] to learn more about healthcare systems and
terminologies used. After gathering the information, we came up with a requirements list
for the healthcare data model. We implemented it on MLPQ and then exercised project
requirement queries on our healthcare database model. We found there are some
difficulties implementing the constraint database on MLPQ because it contains many
unknown defects. After spending many hours learning about MLPQ, we discovered some
tricks to find workarounds to the problems.
In this report, we applied the concepts of constraint databases and normalization
techniques that we learned from class. You will find our database model requirements,
implementation, database schema, dummy data, class diagram, and the result of iconic
queries and SQL queries on MLPQ in this document.
2.
Requirement
The following cases are the requirement gathered from patients, vendors,
companies, and doctors’ opinions. These requirements are mandatory.
Requirement 1: Patients can find the lowest service fee charged by doctors.
Requirement 2: Patients can find out the day which offices are open based on the
specified doctor.
Requirement 3: Patients can visually see the doctor’s office location on a map and the
day which the office is open.
Requirement 4: Patients can calculate how much money he or she has spent on medical
and pharmacy costs.
Requirement 5: Patients can see doctor’s rating.
Requirement 6: Patients can choose their medical plan from a number of choices.
Requirement 7: Patients can provide customer survey feedback to evaluate doctor service
quality, and the feedback in reflected in doctor rating.
Requirement 8: Doctors can find out the proximity of where a patient lives relative to
their office. Doctors can advertise his or her service to those patients.
Requirement 9: Patients can choose medicine from a range of choices in their medical
plan.
Requirement 10: Patients can find the cheapest medicine among the choices.
-------------------------------------------------------------------[19] Rental Apartments
This project is aimed at implementing a database representing the Rental
apartments in a city, based on the MLPQ system. We provide the locations of
apartments along with parks, schools and local transit facilities stops close to
those apartments. It will allow user to retrieve information about any apartment
located in the city e.g. school, transit stops and parks near the apartment, their
price range, type, number and agency owning it. The user will also be able to
search for apartments with some search criteria like apartment with school at a
distance of a mile, apartments in the range of $100 to $1500, apartments owned
by some particular agency, etc.
The database depicts the map of a city. The map tries to approximate the actual
map of the city under consideration.
Entities
 City(id, x, y, name)
This table stores a unique id for the city.
The attributes x, y represent the area of the city in the form of constraint
tuples. The map is close approximation of the actual map.
The attribute name defines the name of the city.
‘id’ is the primary key.
 Freeway(id, x, y)
This table stores a unique id for each freeway.
The attributes x, y represent freeway crossing the city. The map is close
approximation of the actual map in the form of linear approximations.
‘id’ is the primary key.
 Street(id, x, y)
This table stores a unique id for each street.
The attributes x, y represent streets in a city. The map is close
approximation of the actual map in the form of linear approximations.
‘id’ is the primary key.
 Apartment(id, x, y)
This table stores a unique id for each apartment.
The attributes x, y represent the locations of the apartments in a city. The
map is close approximation of the actual map.
‘id’ is the primary key.
 School(id, x, y)
This table stores a unique id for each apartment.
The attributes x, y represent the locations of the schools in a city. The map
is close approximation of the actual map.
‘id’ is the primary key.
 Park(id, x, y)
This table stores a unique id for each apartment.
The attributes x, y represent the locations of the parks in a city. The map
is close approximation of the actual map.
‘id’ is the primary key.
 Transit(id, x, y)
This table stores a unique id for each apartment.
The attributes x, y represent the locations of the transit stops in a city. The
map is close approximation of the actual map.
‘id’ is the primary key.
 Property_info(agid, lowp,highp,typeid,num, sid,pid,
d_sch,d_park,aptid,name,addr_num,s_addr, ph)
This table is used to store the information related to each and every apartment.
The aptid is the id of the apartment that refers to the Apartment relation.
‘name gives the name of the apartment.
‘agid’ is the id of the agency owning that apartment.
‘lowp’ and ‘highp’ are the range of rent for those apartments
‘typeid’ refers to the type of apartments available and refers to the
Apartment_type table
‘num’ gives the number of apartments in that apartment complex
‘addr_num’ and ‘s_addr’ provide the address for that apartment complex
‘ph’ gives the contact number for the leasing office for those apartments
’sid’ and ‘pid’ depict the school and park closest to that apartment
’d_sch’ gives the distance to the closest school
‘aptid’ is the primary key.
 Park_info(id,name,address,s_addr)
This table is used to store the information related to each and every park.
The ‘id’ is the id of the park that refers to the Park relation.
‘name gives the name of the park.
‘address’ and ‘s_addr’ provide the address for that apartment complex
‘id’ is the primary key.
 Transit_info(id,type)
This table is used to store the information regarding the type of transit facility
available on each transit stop
The id is the id of the transit that refers to the Transit relation.
‘type’ gives the type of transit facility available on that stop.
‘id’ and ‘type’ is the primary key.
 Agency(id,name)
This table is used to store the information regarding the agencies owning
apartments in the city.
‘name’ gives the name of the agency.
‘id’ is the primary key.
 Street_info(id,name)
This table is used to store the information regarding the streets in the city.
The ‘id’ is the id of the street, which refers to the Street relation.
‘name’ gives the name of the street.
‘id’ is the primary key.
 Apartment_type(typeid,details)
This table is used as a reference to store information regarding the type of
apartments available.
The ‘typeid’ is the category of the type of apartments.
‘details’ describes this category.
‘typeid’ is the primary key.
-------------------------------------------------------------------[20] Components Pricing Guide
This project is design and implements the constraint database for the computer
components by using MLPQ system. The purpose of this project is to query the data that
provide useful information for the computer industry in order to design a new computer
in the future. By using this constraint database, the company can query and analyze the
cost of each components or the total cost for each computer.
Since the prices of computer component change constantly, we represent the prices of
components in the form of an equation. Also we represented different rating of each
component during different times to represent the advancement of the computer
technology.
Constraint Database
Harddrive (HdId, x, y) – Represent a hard drive. Attribute x is the time after release.
Attribute y is the price of the component.
Memory (MemId, x, y) – Represent a memory. Attribute x is the time after release.
Attribute y is the price of the component.
CPU (CPUId, x, y) – Represent a CPU. Attribute x is the time after release. Attribute y
is the price of the component.
Printer (pId, x, y) – Represent a Printer. Attribute x is the time after release. Attribute y
is the price of the component.
Monitor (mId, x, y) – Represent a Monitor. Attribute x is the time after release.
Attribute y is the price of the component.
Powersupply (pwId, x, y) – Represent a Monitor. Attribute x is the time after release.
Attribute y is the price of the component.
HDStorageCapacity (HDStorageId, HdId, x, rating, size) – Represent the rating of a hard
drive. HdId refers to the table Harddrive, x is the time after release, rating is the opinion
of users and size is the size of the hard drive.
MemStorageCapacity (MemStorageId, MemId, x, rating, size) - Represent the rating of a
memory. MemId refers to the table Memory, x is the time after release, rating is the
opinion of users and size is the size of the memory.
Process_rating (ProcessRatingId, CPUId, x, rating, speed) – Represent the rating of a
CPU. CPUId refers to the table CPU, x is the time after release, rating is the opinion of
users and speed is the Mhz rating of a CPU.
Demand (demandid, MemStoraHPId, HDStoraHPId) – Represent the demand for this
type of componet during different times.
--------------------------------------------------------------------