R ELATIONAL D ATABASES

Department of Client Services Information Technology Systems Division

What is a Database?, 2 When and Why to Set up a Database, 2 Relational Databases, 3

TOPICS COVERED
For assistance contact the Technology Assistance Center: 962-4357 E-mail: tac@uncw.edu Updated 11/05

The Data Model, 3 Entity Relational Diagrams, 4 One-to-One Relationships, 5 One-to-Many Relationships, 5 Many-to-Many Relationships, 6 Attributes, 6 Database Structure, 7 Tables, 7 Queries, 8 Forms, 8 Reports, 8 The Database Design Process, 9 Defining the System Parameters, 9 Defining the Work Processes, 9 Preparing the Database Schema, 9 Designing the User Interface, 9 Example Database Situations, 10 Example 1, 10 Example 2, 11 Example 3, 12 Questions or Problems, 13

RELATIONAL DATABASES

What is a Database?
A database is a collection of information related to a particular subject. A key role that databases play is the organization of information in a logical way, so that you can access and maintain the information easily. There are three types of databases: flat file, hierarchical, and relational. Flat File Database: contains all the information you store in one datasheet, or table. This type of database can be stored in an Excel spreadsheet much more effectively than with an Access database. Hierarchical Database: links records together like a family tree such that each record type has only one owner. Due to this restriction, this type of database often cannot be used to relate structures that exist in the real world. A common example is the Windows File System containing folders and their multiple subfolders. Relational Database: consists of many different tables linked together by common fields. This allows the data to be manipulated in many different ways, therefore easily producing results.

When and Why to Set up a Database There are many reasons one might choose to use a database to store their information. There are also many situations that do not call for a database. Look at the following example:

Description 1998 Toyota 4-Runner Alvarez Acoustic Guitar Dell Laptop

Value $15,000 $800 $600

In this example we have two sets of information, Description and Value, and three instances for each. For this situation an Excel spreadsheet is the simplest, easiest choice. Before you decide that you really need a database to store your information, it is highly recommended that you consider the time and effort involved in creating and maintaining a database.
Relational Databases Last Modified: 11/05 Department of Client Services Information Technology Systems Division, UNCW

RELATIONAL DATABASES

Relational Databases
The relational model is based on a collection on mathematical principles drawn primarily from set theory and predicate logic. These principles were first applied to the field of data modeling in the late 1960s by Dr. E.F. Codd, then a researcher at IBM, and first published in 1970. The relational model defines the way data can be represented (data structure), the way data can be protected (data integrity), and the operations that can be performed on data (data manipulation).

In general terms, relational database systems have the following characteristics:

All data is conceptually represented as an orderly arrangement of data

into rows and columns, called a relation.

All values are scalar. That is, at any given row/column position in the
relation there is one and only one value.

All operations are performed on an entire relation and result in an entire

relation, a concept known as closure.

The Data Model

The most abstract level of a database design is the data model, the conceptual description of a problem space. Data models are expressed in terms of entities, attributes, domains, and relationships.

Entities: Entities are anything that exists as a particular and discrete unit.
This is applied to databases in that ANYTHING that the system needs to store information about is considered an entity. Example: if you are making a database for your company, then you might consider the customers, products, employees, and suppliers as entities.

Attributes: Your database will need to keep track of certain facts about
each entity. These facts are referred to as the entitys attributes. Example: if your system includes a customer entity, then you would possibly have names, addresses, and phone numbers as that entitys attributes.
Relational Databases Last Modified: 11/05 Department of Client Services Information Technology Systems Division, UNCW

RELATIONAL DATABASES

Domains: When considering an entitys attributes, the domain is a set of all possible values that an attribute may validly contain. Example: If you have a database with an age attribute, then the domain could conservatively be between 1 year old, to 100 years old. Example: If you have a database of the United States with a state attribute, then the domain would be a maximum of 50. Relationships: At the conceptual level, relationships are simply associations between entities. Example: In a database, if a Customer entity buys product entities, then their relationship is determined by the buys operator. For this particular example, another operator may be sells.

Entity Relationship Diagrams

The Entity Relationship model, which describes data in terms of entities, attributes, and relationships, was introduced by Peter Pin Shan Chen in 1976. The great advantage of E/R diagrams is that theyre easy to draw and understand. It is generally the practice to diagram the attributes separately, since they exist at a different level of detail. In this example though I have added them to show the full Data Model.

Relational Databases Last Modified: 11/05

Department of Client Services Information Technology Systems Division, UNCW

RELATIONAL DATABASES

One-To-One Relationships
Perhaps the simplest type of relationship is the one-to-one relationship. If its true that any instance of entity X can be associated with only on instance of entity Y, then the relationship is one-to-one. When choosing a one-to-one relationship between entities, you need to be sure that the relationship is either true for all time or, if it does change, that you dont care about past values. For example, lets say youre modeling the office space in a building. Assuming that there is one person to an office, theres a one-toone relationship as shown below.

However, the relationship between an employee and an office is true only at a specific moment in time. Over time different employees will be assigned to the office. If you use the one-to-one relationship shown above, you will have a simple, clean model of your building, but with no way to determine the history of occupancy.

One-To-Many Relationships
The most common type of relationship between entities is one-to-many, wherein a single instance of one entity can be associated with zero, one, or many instances of another entity. One-to-many relationships present few problems once theyve been identified. However, its important to be careful in specifying the optionality (an attribute of the relationship) on each side of the relationship. Its commonly thought that only the many side of the relationship can be optional, but this isnt the case.

The relationship shown above between Client and CustomerServiceRep is optional in both directions. Basically this means that the CustomerServiceRep can have zero or more clients. A Clients CustomerServiceRep, if one has been assigned, must be present in the CustomerServiceRep relation, or otherwise there would be no relationship.

Relational Databases Last Modified: 11/05

Department of Client Services Information Technology Systems Division, UNCW

RELATIONAL DATABASES

Many-To-Many Relationships
Many-to-many relationships exist very often in the real world. Students take many courses; any given course is attended by many students. Customers shop in many stores; a store has many customers. Unfortunately though, many-tomany relationships cannot be implemented in a relational database. Instead, they are modeled using an intermediary relation that has a one-to-many relationship with each of the original participants. This is shown below.

This in turn is modeled like this:

Since we are now modeling the many-to-many relationship with an intermediary relation, we use what is called a Junction Table. Junction tables most often contain only the relation to each of its entities. In this example the Junction table contains relations with EntityOne and EntityTwo.

Attributes
Your system will need to keep track of certain facts about each entity. These facts are referred to as the entitys attributes. If your system includes Customer entities, for example, youll probably want to know the names and addresses of the customers and perhaps the businesses theyre in, as well as their phone number and e-mail address. If youre modeling an event such as a ServiceCall, youll probably want to know who the customer was, who made the call, when it was made, and whether the problem was resolved. Determining the attributes to be included in your model is a semantic process. You must make your decisions based on what the data means and how it will be used. Lets look at the following example: an address. Do you model the address as a single entity, or as a set of entities (HouseNumber, Street, City, State, ZipCode)? Most database designers tend to automatically break the address up into a set of attributes on the general principle that structured data is easier to manipulate. However that is not necessarily correct and certainly not straightforward. The point here is not so much that addresses are hard to model, although they can be, but rather that you cant make any assumptions about how you should model any specific kind of data. Each database is inherently different and therefore requiring different things. If you make logical choices concerning attributes at the beginning of the design process, you should have few problems once you begin implementing your database.

Relational Databases Last Modified: 11/05

Department of Client Services Information Technology Systems Division, UNCW

RELATIONAL DATABASES

Database Structure
In general, all database management programs have the same overall organization. Different types of objects perform specific tasks. Most database programs contain four main object types: tables, queries, forms, and reports. Microsoft Access 2003, as is covered in the Access 2003 workshop, also contains these objects: pages, macros, and modules. These will not be covered in this handout as they do not pertain to the understanding of Relational Databases. Tables A table is an object you define and use to store data. Designing your tables properly is the most important aspect to using a database management program (i.e. Access 2003). It is MUCH easier to change your database design before you fill the tables with data. Each table contains information about ONE subject, such as employees, customers, or orders. For example, one table might store customer names and addresses while another stores customer orders. Tables are made up of Fields and Records. Field: Each record (row) is made up of a series of fields (columns), which store individual bits of information. There are six fields in each record below. Record: A record is a collection of data about a person, place, an event or some other item. A record is a row in a datasheet view of a table, query, or form. There are four records in the table below.

LASTNAME Mitchell Paschal Brooks Grissom

FIRSTNAME Jon Michael David Brian

ADDRESS 123 Main St. 123 Market St. 123 Kerr Ave. 123 Gordon Rd.

CITY Wilmington Wilmington Wilmington Wilmington

STATE NC NC NC NC

ZIP 28403 28407 28405 28401

Relational Databases Last Modified: 11/05

Department of Client Services Information Technology Systems Division, UNCW

RELATIONAL DATABASES

Queries A query is an object that provides a custom view of data from one or more tables. Queries are a way of asking questions of the data stored in your tables. You can define queries to select, update, insert, or delete data. Queries are especially useful because they let you organize your data without editing the actual records themselves. You are able to use queries when you are creating reports as well, thus enabling you to create a report on data that you specify.

Forms A form is an object designed primarily for data entry and display. Forms allow you to look at one record at a time, but enable you to enter information into several tables at once. Forms can be customized to have different backgrounds and colors to make data entry easier.

Reports A report allows you to format, calculate, print and summarize selected data. Reports are designed to be printed rather than viewed on a computer screen, so they need to be carefully planned. Examples of everyday reports include invoices, receipts, sales summaries, and phone books.

Relational Databases Last Modified: 11/05

Department of Client Services Information Technology Systems Division, UNCW

RELATIONAL DATABASES

The Database Design Process

However you decide to design your database, it is recommended that you perform certain analysis and design activities. Whether you perform them sequentially or iteratively (repeating the same design activities more than once), whether the scope of your inquiry is the entire system or only a single component, whether your techniques are formal or informal, EVERY PROJECT SHOULD INCLUDE EACH OF THESE STEPS AT LEAST ONCE. Defining the System Parameters Ideally, every project should begin with a clear definition of what youre trying to achieve, why youre trying to achieve it, and how your success will be judged. Most projects wont have this definition prior to commencement, so this is what the first phase of the design process is about. The projects goal defines the why of the project. Based on this, you can define the what, the projects scope. Once you understand the goal and scope, you can begin to determine realistic design criteria, the how.

Defining the Work Process Although ostensibly involved in the storage and retrieval of data, the majority of database systems support one or more work processes. Your users arent storing data for the sake of storing data; they want to use it in some way. Understanding the work processes the data needs to support is crucial to understanding the semantics of the data model.

Preparing the Database Schema The database schema translates the conceptual data model into physical terms. It includes a description of the tables that will be implemented in the system and also the physical architecture of the data. This is a key step in developing solid tables, and is where you will make any changes that you see fit before filling the tables with data. If you find the need to edit your tables later in the process, it will become much more difficult.

Designing the User Interface No matter how impressive the technical performance of your system, if the user interface is clumsy, confusing, or patronizing, the project is unlikely to be successful. To most users the interface is the system.

Relational Databases Last Modified: 11/05

Department of Client Services Information Technology Systems Division, UNCW

RELATIONAL DATABASES

10

Example Database Situations

Example 1 Premise: You are in charge of the reservations for a conference room on campus. You need to keep track of who reserved the room, and for what days. DO YOU REALLY NEED A DATABASE? Defining the System Parameters Who is going to use this database? How are you going to access/update this database? Where are you going to store this database? What time span are you going to use this database for? Defining the Work Process Are you going to need simultaneous access for multiple users? If so, how many users? What permissions are the users going to need (read, write, etc)? Preparing the Database Schema What information are you going to store about the reservationists (attributes)? What information are you going to store about the room to be reserved (attributes)? How are you going to store the time/date information? In what format are you going to store these things? How many tables is this going to require? Designing the User Interface How do you want to allow users to access this database? Are you going to want it to be web-enabled? Are different permission levels going to allow access to only certain functions? How are you going to implement this? DO YOU REALLY NEED A DATABASE? Now that you have your Data Model, you are ready to move onto the actually implementation of your database. It is highly recommended that you take time when completing the previous steps since it is much more difficult to change your database once you have begun the implementation of such.

Relational Databases Last Modified: 11/05

Department of Client Services Information Technology Systems Division, UNCW

RELATIONAL DATABASES

11

Example 2 Premise: You are in charge of creating and maintaining an information database about 60 students workers that work for your department, including their wages. DO YOU REALLY NEED A DATABASE? Defining the System Parameters Who is going to use this database? How are you going to access/update this database? Where are you going to store this database? What time span are you going to use this database for? Defining the Work Process Are you going to need simultaneous access for multiple users? If so, how many users? What permissions are the users going to need (read, write, etc.)? Preparing the Database Schema What information are you going to store about the students (attributes)? Are you going to store their work hours? In what format are you going to store these things? How many tables is this going to require? Designing the User Interface How do you want to allow users to access this database? Are you going to want it to be web-enabled? Are different permission levels going to allow access to only certain functions? How are you going to implement this? DO YOU REALLY NEED A DATABASE? Now that you have your Data Model, you are ready to move onto the actually implementation of your database. It is highly recommended that you take time when completing the previous steps since it is much more difficult to change your database once you have begun the implementation of such.

Relational Databases Last Modified: 11/05

Department of Client Services Information Technology Systems Division, UNCW

RELATIONAL DATABASES

12

Example 3 Premise: You are responsible for maintaining a database of your departments assets. These include: all hardware (furniture, technology, telecommunications, office supplies), all software (licensed by campus, licensed by department, licensed by individuals), and all liquid assets (student wages, petty cash, purchasing cards). DO YOU REALLY NEED A DATABASE? Defining the System Parameters Who is going to use this database? How are you going to access/update this database? Where are you going to store this database? What time span are you going to use this database for? Defining the Work Process Are you going to need simultaneous access for multiple users? If so, how many users? What permissions are the users going to need (read, write, etc)? Preparing the Database Schema What information are you going to store about the hardware (attributes)? What information are you going to store about the software (attributes)? What information are you going to store about the liquid assets (attributes)? In what format are you going to store these things? How many tables is this going to require? Designing the User Interface How do you want to allow users to access this database? Are you going to want it to be web-enabled? Are different permission levels going to allow access to only certain functions? How are you going to implement this? DO YOU REALLY NEED A DATABASE? Now that you have your Data Model, you are ready to move onto the actually implementation of your database. It is highly recommended that you take time when completing the previous steps since it is much more difficult to change your database once you have begun the implementation of such.

Relational Databases Last Modified: 11/05

Department of Client Services Information Technology Systems Division, UNCW

RELATIONAL DATABASES

13

Questions or Problems? Contact the Technology Assistance Center (TAC) Location: Technology Support Center, room 131 Phone: 962-HELP (4357) E-mail: tac@uncw.edu. Normal hours of operation: 7:30 a.m. 6:30 p.m. Monday Thursday; 7:30 a.m. 5:00 p.m. Friday

Relational Databases Last Modified: 11/05

Department of Client Services Information Technology Systems Division, UNCW