Republic of Iraq

Ministry of Higher Education

and Scientific Research

University of Baghdad

College of science

Department of Computer Science

Design a Home Tech Repair Database

A Project

Submitted to the Department of Computer Science, College of science, University

of Baghdad in a Partial Fulfillment of the Requirements for the Degree of B. Sc.

in Computer Science

By

Sarah emad taki

Esraa hasen shuker

Supervised By

Dr. Mehdi G. Duaimi

2012 AD

خ آن ر لق ٱم ل *ع من لرح ٱ *سان ن لإٱق ل *

*ان حسب ب ر م لق ٱو مس لش ٱ*ان ي لب ٱه م ل ع

اه فع ر ء آم س لٱ*و انإد سج ي ر ج لش ٱو جم لن ٱو

*ان يز لمإٱعض و و

لؼظيناصذق هللا (7-1سورة الرحمن اآلية )

وزرع في الثقة والطمىح تهمه أحاطىي برػاي

والدي ... حفظه هللا

ضاوها طفال وغمرتىي حمه رأيت الىىر واوا في ا

بالحب والحىان

والدتي ... الغالية أطال هللا ػمرها

.....أشقائيسىدي وػىوي

أهدي ثمرة جهدي المتىاضغ

Abstract

In this project, a home tech repair database is presented. It has a very

large potential market of employees and customers. An OLTP database

model structure is, therefore, desirable. The project involves the design

and implementation of an online auction house system. The analysis stage

is performed first for the case study. What does a database model need?

What is in it? The following stages involve an examination of company

objectives, company operations, and business rules for an OLTP

database. The case study introduces concepts, such as analysis and design

of relational database model for an online auction house company.

Project begins by analyzing and presenting the OLTP database model for

the home tech repair database. Besides, the intention to establish what

goes on operationally within this house. What pieces of information make

up the database model (static data), and what pieces of information are

moving through the database model (transactional data)?

Oracle database system is used in the implementation part of the project.

تأييد المشرف

اؤيذ اى الوشروع الووسوم قذ اػذ جحث اشرافي في قسن ػلوم

الحاسبات / كلية الؼلوم/ جاهؼة بغذاد كجزء هي هحطلبات الحصول

يؼلي درجة البكالوريوس في ػلوم الحاسبات.

اسن الوشرف:

الحوقيغ :

الحاريخ :

تأييد لجىة المىاقشة

إيذ اا اطلؼا ػلي الوشروع الووسوم كأػضاء لجة الواقشة وقذ جن

وػليه وصي اخحبار الطالب ....................... في هححوى الحقرير

بقبول الوشروع كبحث للحخرج للحصول ػلي درجة البكالوريوس في

ػلوم الحاسبات.

االسن والحوقيغ االسن والحوقيغ االسن والحوقيغ

االسن والحوقيغ

Content

No.

1- Introduction To Database Systems

1-1 Overview

1-2 Advantages Of A Dbms

1-3 Structure Of A Dbms

2- Introduction To Schema Refinement

2-1 Examples Motivating Schema Refinement

2-2 Identifying Attributes Of Entities

2-3 Determine The Goals Of The Database

2-4 Distribute The Data Among The Tables

3- You Can Relate Tables

3-1 Three Different Ways

3-2 Determine The Goals Of The Database

3-3 Distribute The Data Among The Tables

3-4complete The Database

4- Choose A Primary Key

4-1 Set A Single-Field Primary Key

4-2 Set A Multiple-Field Primary Key

4-3 Create Other Indexes

4-4 Add A Single-Field Index

4-5 Create A Multiple-Field Index

4-6 Save The Table Design

4-7 Delete The Primary Key

Design a home tech repair database

5- INTRODUCTION TO DATABASE SYSTEMS

A database is a collection of data, typically describing the activities of

one or more related organizations. For example,

university database might contain information about the following:

Entities such as students, faculty, courses, and classrooms.

Relationships between entities, such students' enrollment in

courses, faculty teaching courses, and the use of rooms for courses.

A database management system, or DBMS, is software designed to

assist in maintaining and utilizing large collections of data, and the need

for such systems, as well as their use, is growing rapidly. The alternative

to using a DBMS is to use adhoc approaches that do not carry over from

one application to another; for example,

To store the data in files and write application-specific code to manage it.

1-1 OVERVIEW

Many kinds of database management systems are in use, but this book

concentrates on

relational systems, which are by far the dominant type of DBMS today.

The following

questions are addressed in the core chapters of this book:

1. Database Design: How can a user describe a real-world enterprise

(e.g., a university)

in terms of the data stored in a DBMS? What factors must be considered

in deciding how to organize the stored data?

2. Data Analysis: How can a user answer questions about the enterprise

by posing

queries over the data in the DBMS?

3. Concurrency and Robustness: How does a DBMS allow many users

to access

data concurrently, and how does it protect the data in the event of system

failures?

4. E_ciency and Scalability: How does a DBMS store large datasets and

answer

questions against this data e_ciently?

1-2 ADVANTAGES OF A DBMS Using a DBMS to manage data has many advantages:

Data independence: Application programs should be as independent as

possible from details of data representation and storage.The DBMS can

provide an abstract view of the data to insulate application code from

such details.

Efficient data access: A DBMS utilizes a variety of sophisticated

techniques to store and retrieve data efficiently.This feature is especially

important if the data is stored on external storage devices.

Data integrity and security: If data is always accessed through the

DBMS, the DBMS can enforce integrity constraints on the data. For

example, before inserting salary information for an employee, the DBMS

can check that the department budget is not exceeded. Also, the DBMS

can enforce access controls that govern what data is visible to different

classes of users.

Data administration: When several users share the data, centralizing the

administration of data can offer significant improvements. Experienced

professionals who understand the nature of the data being managed, and

how different groups

of users use it, can be responsible for organizing the data representation

to minimize redundancy and for fine-tuning the storage of the data to

make retrieval efficient.

Concurrent access and crash recovery: A DBMS schedules concurrent

ac- cesses to the data in such a manner that users can think of the data as

being accessed by only one user at a time. Further, the DBMS protects

users from the e_ects of system failures.

Reduced application development time: Clearly, the DBMS supports

many important functions that are common to many applications

accessing data stored in the DBMS. This, in conjunction with the high-

level interface to the data, facil- itates quick development of applications.

Such applications are also likely to be more robust than applications

developed from scratch because many important tasks are handled by the

DBMS instead of being implemented by the application.

1-3 STRUCTURE OF A DBMS

The structure (with some simpli_cation) of a typical DBMS based on

the relational data model.

Figure 1.1 Architecture of a DBMS

6- INTRODUCTION TO SCHEMA REFINEMENT

2-1 EXAMPLES MOTIVATING SCHEMA REFINEMENT

It is natural to ask whether we need to decompose relations produced

by translating an ER diagram. Shouldn't a good ER design lead to a

collection of good relations?

Unfortunately, ER design can generate some schemas with redundancy

problems, because it is a complex, subjective process, and certain

constraints are not expressible

in terms of ER diagrams. The examples in this section are intended to

illustrate why decomposition of relations produced through ER design

might be necessary.

2-2 Identifying Attributes of Entities This example illustrates how a careful examination of FDs can lead to a

better understanding of the entities and relationships underlying the

relational tables; in particular, it shows that attributes can easily be

associated with the `wrong' entity set during ER design. The ER diagram

in shows a relationship set called Works In that is similar to the

Works_In relationship set of Chapter 2, but with an additional key

constraint indicating that an employee can work in at most one

department. (Observe the arrow connecting Employees to Works_In.)

Using the key constraint, we can translate this ER diagram into two

relations: Workers(ssn, name, lot, did, since)

2-3 Determine the Goals of the Database A poorly designed database is of less than no value. The more time spent

on task and data

analysis, the better the results will be. To begin the database design, start

at the end point. Find

out what the end user expects of the database, then go about structuring

the design to provide

these requirements.

To do so, answer the following questions:

■ What do the users want to get from the database?

■ What kinds of reports are needed (how do users want the information

arranged and

summarized)?

Then follow these directions:

■ If adequate data collection forms already exist, use them as patterns for

the Access forms.

■ Look at other databases that address similar information management

situations and see

whether they can provide any guidance with the design of your own.

■ Once the tasks have been defined, develop a list of the required data

items.

2-4 Distribute the Data Among the Tables Distributing data is the cornerstone of relational databases. The efficiency

and effectiveness of such a database relies on the proper distribution of

data among the tables that make up the database.

This is not as easy as it sounds, but here are some guidelines to follow:

■ The information in a table should be limited to a single subject. This

allows you to

maintain data about each subject independently of the others.

■ Tables should not contain duplicate information among its records.

With only one

copy of each data item, you need to update it in only one place

7- You Can Relate Tables

3-1 Three Different Ways One-to-Many

This is the most common relationship between tables. One record in one

table can have many matching records in another table. The table on the

―one‖ side often is called the parent table and the other is the child table.

For example, the Customers table would have one record for each

customer, whereas the Workorders table might have more than one work

order for the same customer. Both tables would include a field with a

value that represents that specific customer and links the two tables.

One-to-One This relationship is more like a lookup tool in which each record in one of

the tables has a matching record in the other table. Both tables have the

same standing and neither table is designated as the parent. The key fields

in both tables are the primary keys. One good use for this type of

relationship is to store in the first table additional, seldom-referenced

information about an item, such as an abstract of a book or the details of a

work order.

Many-to-Many The many-to-many relationship is not exactly permitted as such in a

relational database.

Many records in one table have the same values in the key field as many

records in the second table. If you relate tables in this way using Access,

you must create a third table, called a junction table, to place between the

first two, then relate the two original tables to the junction using two one-

to-many relationships. For example, the relationship between the

Employees and the Customers tables is many-to-many, and the

Workorders tables could serve as a junction table between them.

3-2 Determine the Goals of the Database A poorly designed database is of less than no value. The more time spent

on task and data analysis, the better the results will be. To begin the

database design, start at the end point. Find out what the end user expects

of the database, then go about structuring the design to provide these

requirements.

To do so, answer the following questions:

■ What do the users want to get from the database?

■ What kinds of reports are needed (how do users want the information

arranged and summarized)?

Then follow these directions:

■ If adequate data collection forms already exist, use them as patterns for

the Access forms.

■ Look at other databases that address similar information management

situations and see whether they can provide any guidance with the design

of your own.

■ Once the tasks have been defined, develop a list of the required data

items.

3-3 Distribute the Data Among the Tables Distributing data is the cornerstone of relational databases. The efficiency

and effectiveness of such a database relies on the proper distribution of

data among the tables that make up the database.

This is not as easy as it sounds, but here are some guidelines to follow:

■ The information in a table should be limited to a single subject. This

allows you to maintain data about each subject independently of the

others.

■ Tables should not contain duplicate information among its records.

With only one copy of each data item, you need to update it in only one

place.

In the Home Tech Repair case, employee and customer information is

repeated on several manually prepared work order sheets. To reduce the

redundancy, pull out both sets of information and put them in separate

tables. Keeping payments in a separate table will add flexibility,

especially if the work is paid for in installments, such as a deposit at the

start of the contract and the remainder while the work is being completed.

3-4Complete the Database

1. Enter just enough data to test the application. You can complete the

tables later.

2. Create the forms, reports, and queries. If the database is for

inexperienced users, you

can add a switchboard and other custom tools to make their jobs easier.

3. Carefully test the entire system. Time spent refining and verifying the

design can save time revising the database after it has been populated

with data.

After the design is established, Access gives you three ways to create

a new database:

■ Starting with the Database Wizard

■ Starting from scratch with a blank database

■ Starting from Windows

8- Choose a Primary Key

In a relational database system, it is important to be able to gather and

retrieve related information from separate tables in the database. To do

so, each record in one table must be unique in some way. The field or

fields that contain the unique value is the primary key. Access does not

permit duplicate values in the primary key nor does it permit blanks.

There must be a valid, unique value in the primary key in every record.

4-1 Set a Single-Field Primary Key You saw how the Table Wizard picked a primary key; now it’s your turn.

If your table has a field that you are sure will not contain any duplicate

values, you can use that field as the primary key.

The AutoNumber field type is an Access tool that can guarantee unique

records in a table.

Designating an AutoNumber field as the primary key for a table probably

is the simplest way to set the key. You don’t have to worry about

inadvertently entering duplicate values because Access uses unique

numbers to identify each record. Once the number is generated, it can’t be

changed or deleted.

In the table Design view, click in the field row that you want to use as the

primary key, then click the Primary Key toolbar button or choose Edit |

Primary Key. To remove the primary key designation, repeat the step.

4-2 Set a Multiple-Field Primary Key If you can’t guarantee that the values in a single field will be unique

throughout the table, you

can combine two or more fields as the primary key. For example, a list of

customers might

include several with the same last name (or even some with the same first

and last names); this

field cannot be used as a primary key, but you can combine first and last

names with date of birth

4-3 Create Other Indexes Indexes help Access find and sort records faster just as an index helps

you find topics in a reference book: an index contains a pointer to the

location of the data rather than the data itself. The primary key in a table

is automatically indexed, so the indexes that you can create are secondary

indexes created with other fields. An index can include a single field or

multiple fields.

To help you decide which fields to use as indexes, look at the fields you

expect to search frequently or by which you will want to sort. Also, if you

expect to use a field to create a relationship with another table, you might

want to create an index on the field to improve performance.

4-4 Add a Single-Field Index To set a single-field index, simply change its Indexed property to Yes

and decide whether to permit duplicate values.

To take a look at the indexes that have been specified for a table, click the

Indexes toolbar button or choose View | Indexes. The Customers table

includes two currently defined indexes.

The primary key, Customer ID, is listed with the key icon as the first

index and a single-field

4-5 Create a Multiple-Field Index Often, you might want to search or sort records based on more than one

field at once. Creating a multiple-field index allows you to do just that.

When you sort records using a multiple-field index, the records are sorted

initially by the first field in the index. If Access finds duplicate values in

the first field, it sorts by the next field, and so on. For example, you want

to see records for customers in particular areas of the city. To do this, you

can create an index using both the City and ZIP code fields.

To create a multiple-field index, follow these steps:

1. With the Customers table open in Design view, click the Indexes

toolbar button.

2. Click in the first empty row in the Indexes window.

3. Enter a name for the new index, such as City Region, then press TAB

to move to the Field Name column.

4. Click the down arrow and select City from the list of available fields.

5. Accept Ascending as the sort order for the City field and click in the

Field Name in the next row (leaving the Index Name blank because both

fields will be used in the same index).

6. Choose ZIP from the field list and change the sort order, if necessary.

7. If the index is intended to be the primary key, set the Primary property

to Yes. (You will have to click the first row of the index containing the

index name to display the Index Properties pane.) If you want the index to

contain unique values for each record,

4-6 Save the Table Design

The table design does not have to be complete before you save it. In fact,

it is a good idea to

occasionally save the design during the design process to guard against

catastrophes. But Access

does require you to save the design before you can switch to Datasheet

view to enter data. To

save the table design, click the Save button or choose File | Save. The

first time you save a new

table, Access prompts you for a name

4-7 Delete the Primary Key You might find that the primary key does not always have a unique

value after all and decide to use a different field or create a primary key

with two or more fields.

To change the primary key, select the row you want as the primary key

and click the Primary Key button. The key icon is removed from the old

key field and appears in the new one.

To add another field to the existing primary key, select both the old

and new key fields, then click the Primary Key button. The key icon

appears in the row selector of both rows.

There might be times when you want to temporarily disable the

primary key—for example, when importing records from another table,

some of which might contain values that duplicate your original table.

You must remove any duplicates in the new data before restoring the

primary key. This has no effect on the data stored in the field designated

as the key; it just removes the key field feature temporarily.

To remove the primary key designation effectively, select the primary

key field and click the Primary Key button. If the key is used in a

relationship, you must delete the relationship before you can remove the

key.

Fig: (1) The relational Database model (Tables)

Fig: (2) Work orders form

Fig: (3) Employee table

Fig: (4) Work – Order table constraints

Fig: (4) Work – Order table constraints

Fig: (5) Work – Order table

Fig: (6) Bid- data table constraints

Fig: (7) Esra user roles

Fig: (8) Bid- data Form

Fig: (9) Customer form

Fig: (10) Employee form

Fig: (11) Customer to customer bidding master detail relationship

Fig: (12) Customer to work – order master detail relationship

Fig: (13) Emloyee to work –order master detail relationship

Fig: (14) work- order form

Conclusion and Future Work

Conclusion

The best database models are produced by paying attention to detail in the

analysis stage. It is important to understand exactly what is needed before

jumping in and ―just getting to it.‖

making changes to a database model used in a production system can be

extremely problematic

This is because applications are usually dependent on the database model.

The reason is that the database model forms the basis of all database-driven

applications, quite often for an entire company

Business rules—This is the heart of the analysis stage, describing what has

been analyzed and what needs to be created to design the database model. What

tables are needed and what are the basic relationships between those tables?

Excessive application of normalization removes potential for error in data

(referential integrity violations).

Future Work

Also, it is valuable to a home tech repair database (and perhaps many of

databases systems) to understand trends. Trends and forecasting can be

established using forecasts and projects into archived data sets. Archived data

can be stored conveniently and efficiently using a specialized data warehouse

database.

Denormalization in the design stage (the sooner the better).

Alternate and extra indexing in addition to that of referential

integrity, primary and foreign keys; however, alternate

indexing is more advanced (detailed) design.

Advanced database structures, such as materialized views, and

some specialized types of indexing. Similar to alternate

indexing, this is also more advanced (detailed) design.

References:

1. S. Sumathi, S. Esakkirajan, "Fundamentals of Relational Database

Management Systems", Springer, 2007.

2. Ramez Elmasri, Shamkant B. Navathe, "Fundamentals of Database

Systems", 4th Edition, Addison Wesley, 2003.

3. C. J. Date, "An Introduction to Database Systems", 8th Edition, Addison

Wesley, 2004.

4. Raghu Ramakrishnan , Johannes Gehrke, "Database Management Systems",

3rd Edition, McGraw Hill, 2003.