Presentation is loading. Please wait.

Presentation is loading. Please wait.

Designing Databases In database design, you determine the fields, tables, and relationships between tables that are needed to satisfy the users’ requirements.

Similar presentations


Presentation on theme: "Designing Databases In database design, you determine the fields, tables, and relationships between tables that are needed to satisfy the users’ requirements."— Presentation transcript:

1 Designing Databases In database design, you determine the fields, tables, and relationships between tables that are needed to satisfy the users’ requirements. When you design a database, you should follow these guidelines: 1. Identify all fields 2. Group related fields into tables 3. Determine each table’s primary key 4. Include a common field in related tables 5. Avoid data redundancy 6. Determine the properties of each field

2 For example, the account execs said that they needed to track data about clients and contracts. All the fields they identified are listed below. Client# Contract# Client Name Street City State Zip Code Phone First Name Last Name Position Contract Date Budget Amt End Date Status 1. Identify all Fields

3 The fields relating to clients are grouped into the Client table. The other fields are grouped logically into the Contract table, which you will create. Client table Client# First Name Client Name Last Name Street Position City State Zip Code Phone Contract table Contract# Contract Date Budget Amt End Date Status 2. Group Related Fields Into Tables

4 3. Determine Each Table’s Primary Key—1 of 2 Recall that a primary key uniquely identifies each record in a table. For some tables, one of the fields, such as a Social Security number or credit card number, naturally serves the function of a primary key. For other tables, two or more fields might be needed to function as the primary key. In these cases, the primary key is referred to as a composite key. For example, a school grade table would use a combination of student number and course code to serve as the primary key.

5 3. Determine Each Table’s Primary Key—2 of 2 For a third category of tables, no single field or combination of fields can uniquely identify a record in a table. In these cases, you need to add a field whose sole purpose is to serve as the primary key. For the current database, Client# is the primary key for the Client table, and Contract# will be the primary key for the Contract table.

6 4. Include a Common Field in Related Tables—1 of 3 You use a common field, which appears in two tables, to connect one table logically with another table. In the first table the common field is the primary key. In the second table you include that same field to form the relationship between the two tables; in the second table this field is called a foreign key. For the current database, we’ll add Client#, which is the primary key for the Client table, to the Contract table, where it will serve as a foreign key.

7 Client table Client# First Name Client Name Last Name Street Position City State Zip Code Phone Contract table Contract# Contract Date Budget Amt End Date Status Client# The Client# field has been added as a foreign key to the Contract table. 4. Include a Common Field in Related Tables—2 of 3

8 4. Include a Common Field in Related Tables—3 of 3 With this common Client# field, the AdZ staff can find all contracts signed by a particular client—they can search the Contract table for all contracts with that Client# value. Likewise, they can determine which client signed a particular contract by searching the Client table to find the one record with the same Client# value as the one in that Contract table record.

9 5. Avoid Data Redundancy—1 of 2 Data redundancy occurs when you store the same data in more than one place. With the exception of common fields to connect tables, you should avoid data redundancy because it wastes storage space and can cause inconsistencies if, for instance, you type a field value one way in one table and a different way in the same table or in a second table.

10 5. Avoid Data Redundancy—2 of 2 Below is an example of incorrect database design that illustrates data redundancy in the Contract table; the Client Name field is redundant, and one client name was entered incorrectly, or at least in three different ways. Contract#Contract DateClient # Client NameStatus H8820301/01/2002378Bellevue Humane SocietyClosed H8901401/01/2002142Furniture ShowroomClosed H8924704/01/2002142Furniture ShowcaseClosed H9003207/01/2002221Dome World RecreationClosed H9010307/01/2002142Future ShowcaseClosed J0018007/01/2002442Carpets of DistinctionOngoing

11 6. Determine the Properties of Each Field You need to identify the properties, or characteristics, of each field so that you can tell Access how to store, display, and process its field values. These properties include the field’s name, maximum number of characters or digits, descriptions, valid values, and other field characteristics. You’ll learn more about field properties later.


Download ppt "Designing Databases In database design, you determine the fields, tables, and relationships between tables that are needed to satisfy the users’ requirements."

Similar presentations


Ads by Google