DATABASE DESIGN PRIMER A BEGINNERS GUIDE TO CREATING A DATABASE doc

3.1 Create Tables Entities and Their Attributes New tables are created in Access by selecting the Tables option on the left of the database window and clicking the New toolbar button se

CEMML

Database Design Primer

A Beginners Guide

to Creating a Database

By William Sprouse

CEMML TPS 05-10

CENTER FOR ENVIRONMENTAL MANAGEMENT OF MILITARY LANDS

Colorado State University Fort Collins, CO 80523-1490

June 2005

Database Design Primer

A Beginners Guide to Creating a Database

By William Sprouse

Center for Environmental Management of Military Lands

Colorado State University

1490 Campus Delivery Fort Collins, CO 80523-1490 (970) 491-2748

This document was produced under the Land Condition Trend Analysis (LCTA) Technical Support for the U.S Army Environmental Center (AEC) contract; contract number DAAD13-00-D-5003-0041, task order number CS01-SC-03-016

Table of Contents

1 Introduction 1

2 Concepts of Creating a Database 1

2.1 Tables 1

2.2 Relationships 2

2.3 Attributes 2

3 Creating a Database in Microsoft Access 3

3.1 Create Tables (Entities) and Their Attributes 3

4 Defining Relationships in Microsoft Access 7

5 Conclusion 10

5.1 Introduction to Data Management 10

5.1.1 LCTA Data Management 11

5.2 Further Reading 12

6 References 13

1 Introduction

Creating a database is often looked upon as an intimidating process However, with a little knowledge and some thought this process can become manageable This document will attempt to provide the reader with the knowledge required to develop their own databases The next section will discuss the steps in creating the conceptual database, which will describe the database and its' components Section 3 will discuss creating the physical database in Microsoft Access

2 Concepts of Creating a Database

A database is a collection of information typically stored on a computer A database can be thought of as

an electronic filing system One type of database, and the type discussed here, is a relational database A relational database is a collection of tables with relationships

A database is designed to describe a situation A situation is a well-defined set of circumstances that can be described using a sufficiently complete natural language For example, Fort X is responsible for managing their natural resources Land Condition Trend Analysis (LCTA) is the component of the Integrated Training Area Management (ITAM) Program that provides for the collecting, inventorying, monitoring, managing, and analyzing of tabular and spatial data concerning land conditions on an installation These data are intended to provide information to effectively manage land use and natural resources and supply information for a variety of decision support and information management systems A database can be developed that is a collection of tables with relationships that represent the situation above and store LCTA data

A database will contain three major components; tables, also called entities, relations, and attributes Tables are the nouns of the situation They represent a person, place, or thing that can be uniquely

identified by type and occurrence Relations are the verbs of a situation and relate the nouns of a situation with one another Attributes are the modifiers of a situation They are qualifiers of an entity or a relation describing its character, quantity, or degree of extent

2.1 Tables

Tables can be described as either major or minor Major tables are the important, dynamic tables of a situation Addition and deletion of data from these tables are common Minor tables are small and static where additions and deletions are rare Domain tables, discussed later, are minor tables

The fist step in developing a relational database is discovering the entities or tables Ask yourself to name

a person, place or thing (a noun) that you'd like to keep track of Keep in mind that all entities are nouns but not all nouns are entities Plant name, for example, is an attribute of ground cover Tables are

characterized by attributes Do not confuse tables with instances of the table Ground cover is a valid table; litter, bare ground, and red oak are instances of that table

A table is a set or collection of like things called instances These instances correspond to rows of data in the table The key concept here is "like things" Consider the following example Using the original LCTA protocol, ground cover data is collected every meter along a 100 meter long plot, resulting in 100 rows of data for each plot in a given year Additional data that is required for each plot includes the training area, vegetation type, and the type of inventory (i.e initial inventory, long-term inventory, or short-term monitoring) One way of storing this data is to add all of the ground cover and plot information items

to one table This would not be a good choice because training area, vegetation type, and the type of inventory do not change for those 100 points It is true that plot number and recording date repeat for the

100 points, but these are used to identify the data A better design would be to store the plot information data in a separate table This is precisely what is done in the original LCTA database design Information about each plot for a given year is stored in the PlotSurv table The ground cover data is stored in the GndCover table

After discovering all of the major tables consider any domain tables that are needed These tables will provide a means of restricting data for a given data field to a set of valid values after relations have been defined They can also be a source of values for data entry forms in Microsoft Access

For each table determine a means for distinguishing each occurrence of the table from all other occurrences

of the table This will be known as the primary key of the table By definition a primary key can not contain nulls, duplicates, or can not change Make sure that the selected primary key always exits, is always unique, and the attributes that make up the primary key do not change over time It is possible to have more than one attribute defined as the primary key The combination of plot number and date, for example, are legitimate candidates for a primary key

2.2 Relationships

Once all of the tables have been defined the next step is to define the relationships Compare each of the tables, two at a time, and determine if they are related Only direct, not indirect, relationships are of interest here For example, employees, departments, and buildings are items of interest in a given situation

If it is true that each employee works in only one department, and that each department is located in only one building, the relation between employee and building is indirect If it is known that the Sales

department is located in building A, and that Smith works in Sales, it can be inferred that Smith works in building A

These relations will be defined in the database through the use of referential integrity constraints The process of defining these constraints in Access is discussed in Section 4

2.3 Attributes

The final step of developing a database is discovering attributes Attributes are characteristics of an entity that the user wishers to capture For each table that has been defined, ask yourself: "What other

characteristics of the entity are of interest?" Only real attributes, and not derived attributes, are of interest

A derived attribute can be calculated from values elsewhere in the database and should be avoided if at all possible The only time a derived attribute should be considered is when it will overcome a performance issue This is common when database code is written to perform calculations and temporary, or working, tables are created to store data during this process

After discovering an attribute determine the key of the attribute Does the value for the attribute in any row depend on the value of the primary key for that row? If the answer is no the attribute is either misplaced or there is a missing table For example, suppose a table has been defined with the name of Part and primary key of Part Number A possible attribute for this entity is Part Name The part name depends on the part number and thus is a valid attribute for this table Likewise the price of the part depends on the part

number and is also a valid attribute for this table Consider order number as an attribute for this table Each order placed by a customer is assigned a unique order number Although each order contains parts, order number does not depend on the value of the part number Order number is not a valid attribute for this table If order number is not valid for any of the defined tables this is probably an indication of a missing table

For each attribute discovered determine if it can contain null values Also determine if all values for that attribute must always be unique, no duplicates allowed

3 Creating a Database in Microsoft Access

Section 2 discussed the process of designing a conceptual database Once the tables, their attributes, and relations have been determined the physical database can be created This section will cover the processes

of creating a database specific to Microsoft Access

3.1 Create Tables (Entities) and Their Attributes

New tables are created in Access by selecting the Tables option on the left of the database window and

clicking the New toolbar button (see Figure 1)

Figure 1: Database Window

A new dialog will appear showing the new table options (Figure 2) Select the Design View option and click the OK button

Figure 2: New Table Options

The table design view will be displayed When creating a new table the view will be empty Figure 3 shows the design view for an existing table The design view is used to define the table attributes, also called fields For each field of a table certain properties must be defined Three of these properties are required for every data element and should be considered carefully during the design process These include data type, field size (applicable only for text and number fields), and requirement rule

Dates can be stored in the database as a text string or a date data type If a field is defined as a date then special Structured Query Language (SQL) functions can be used to extract the day, month, or year from the date If the date is stored as a text string it must first be converted to a date before built-in date functions can be used against it Also, the date data type will insure all dates entered in the database are valid dates

Numbers can also be stored as text or a type of number, which includes integer, long integer, and real numbers If any type of analyses will be done on this data define the data type as a number As discussed above, this will allow for the use of built-in number functions

Figure 3 shows the design view for the PlotSurv table The primary keys for this table are InstalID, PlotID, and RecDate, denoted by the key icon to the left of each field name

Figure 3: Design View of the PlotSurv Table

Primary keys are defined by selecting the field, or fields, and clicking the primary key button shown in Figure 4 To select a field name click the small box to the left of the field name To select multiple fields hold down the Ctrl button while selecting the fields

Figure 4: Primary Key Toolbar Button

Figure 5 and Figure 6 show the field properties for a text and number field respectively Notice there is a slight difference in these two Field size for the text field represents the maximum number of characters allowed; the field size for the number field represents the type of number

Figure 5: Field Properties of the InstalID field in the PlotSurv Table

Figure 6: Field Properties of the PlotID field in the PlotSurv Table

Avoid creating field names with spaces or dashes "-", use the underscore "_" instead Access allows the uses of spaces in field names but many databases do not When a field name containing spaces is used in a query, or referenced in code, the name must be surrounded by brackets "[]" Using the underscore

character avoids the use of these brackets and will help avoid problems in the future The same holds true for table names

Another good practice is to enter descriptions for all fields This will facilitate the use of the database by others less familiar with the design The descriptions are displayed in the lower left portion of the Access window, status bar, when a table is open in datasheet view and the cursor is resting in a data field Table descriptions are entered in the table property dialog box (Figure 7) To see this dialog single click a table name in the database window (Figure 1) then click the right mouse button while the cursor is over the table

name Select Properties from the menu To display these descriptions in the database window select View from the main menu and select the Details option

Figure 7: Table Properties

4 Defining Relationships in Microsoft Access

Defining relationships in Microsoft Access is relatively easy once tables have been created, primary keys defined, and relationships determined Access offers a graphical environment in which to define

relationships eliminating the need to learn the SQL syntax for these procedures

Relationships can be viewed in Microsoft Access by selecting Tools from the main menu then selecting

Relationships Once the relationships window is open the relationship toolbar should be visible To view

the relationship toolbar, if it is not visible, select View / Toolbars / Relationship from the main menu The most common buttons used in this toolbar are Show All Relationships (Figure 8), Clear Layout (Figure 9), and Show Table (Figure 10) The Show All Relationships button will add all tables to the window that have a defined relationship, The Clear Layout button will remove all items currently

displayed in the window and the Show Table button allows the user to add specific tables to the view

Figure 8: Show All Relationships Button

Figure 9: Clear Layout Button

Figure 10: Show Table Button

Tables in the relationship window are represented similar to that of Figure 11 This figure represents the PlotSurv table, also called an entity, and its' data fields, or attributes The bolded field names represent the primary key of the table

Figure 11: The PlotSurv Entity and its Attributes

Figure 12 illustrates the relationship window with three tables visible, PlotMast, PlotSurv, and GndCover The lines connecting the tables represent relationships For example, two lines are drawn between

PlotMast and PlotSurv representing a relationship which involves the InstalID and PlotID data fields These lines have a number 1 above the left side of the lines and an infinity symbol (∞) above the right side

of the lines These marks represent a 1-to-many relationship between PlotMast and PlotSurv In other words, for every unique combination of InstalID and PlotID in PlotMast there can be zero or more rows of data in PlotSurv having the same combination of InstalID and PlotID In this case PlotMast is the parent table, which contains the primary keys for the relationship, and PlotSurv is the child table, which contains the foreign keys

Not only does PlotSurv contain the foreign keys of the relationship with PlotMast, but it also has its' own primary key The primary key for the PlotSurv table is made up of the InstalID, PlotID, and RecDate fields