In this chapter, you learn the concepts and terminology of databases and

Transcription

1 A Itroductio to Database Developmet I this chapter, you lear the cocepts ad termiology of databases ad how to desig the tables that your forms ad reports will use. Fially, you build the actual tables used by this book s Access Auto Auctios example database. The fudametal cocept uderlyig Access databases is that data is stored i tables. Tables are comprised of rows ad colums of data, much like a Excel worksheet. Each table represets a sigle etity, such as a perso or product. As you work with Access, you ll sped cosiderable time desigig ad refiig the tables i your Access applicatios. Table desig ad implemetatio are two characteristics that distiguish database developmet from most other activities you may pursue. After you uderstad the basic cocepts ad termiology, the ext importat lesso to lear is good database desig. Without a good desig, you costatly rework your tables, ad you may ot be able to extract the iformatio you wat from your database. Throughout this book, you lear how to use the basic compoets of Access applicatios, icludig queries, forms, ad reports. You also lear how to desig ad implemet each of these objects. The Access Auto Auctios case study provides iveted examples, but the cocepts are ot fictitious. COPYRIGHTED MATERIAL This chapter is ot easy to uderstad; some of its cocepts are complex. If your goal is to get right ito Access, you may wat to skip to Chapter 2 ad read about the process of buildig tables. If you re fairly familiar with Access but ew to desigig ad creatig tables, you may wat to read this chapter before startig to create tables. IN THIS CHAPTER Uderstadig what a database is Examiig the differeces betwee databases, tables, records, fields, ad values Learig why multiple tables are used i a database Lookig at database objects Learig a five-step desig method Creatig the overall desig of a database system Desigig database tables ad relatioships Desigig iput forms Desigig meus 3

2 Part I Access Buildig Blocks CROSS-REF To jump right ito usig Access, skip to Chapter 2. The Database Termiology of Access Before examiig the actual table examples i this book, it s a good idea to have a firm uderstadig of the termiology that is used whe workig with databases especially Access databases. Microsoft Access follows traditioal database termiology. The terms database, table, record, field, ad value idicate a hierarchy from largest to smallest. Databases Geerally, the word database is a computer term for a collectio of iformatio cocerig a certai topic or busiess applicatio. Databases help you orgaize this related iformatio i a logical fashio for easy access ad retrieval. Databases are t oly for computers. There are also maual databases; we simply refer to these as maual filig systems or maual database systems. These filig systems usually cosist of people, papers, folders, ad filig cabiets paper is the key to a maual database system. I a real maual database system, you probably have i/out baskets ad some type of formal filig method. You access iformatio maually by opeig a file cabiet, takig out a file folder, ad fidig the correct piece of paper. You use paper forms for iput, perhaps by usig a typewriter. You fid iformatio by maually sortig the papers or by copyig iformatio from may papers to aother piece of paper (or eve ito a Excel spreadsheet). You may use a spreadsheet or calculator to aalyze the data or display it i ew ad iterestig ways. A Access database is othig more tha a automated versio of the filig ad retrieval fuctios of a paper filig system. Access databases store iformatio i a carefully defied structure. Access tables store data i a variety of forms, from simple lies of text (such as ame ad address) to complex data such as pictures, souds, or video images. Storig data i a precise, kow format eables a database maagemet system (DBMS) like Access to tur data ito useful iformatio. Tables serve as the primary data repository i a Access database. Queries, forms, ad reports provide access to the data, eablig a user to add or extract data, ad presetig the data i useful ways. Most developers add macros or Visual Basic for Applicatios (VBA) code to forms ad reports to make their applicatios easier to use. A relatioal database maagemet system (RDBMS), such as Access, stores data i related tables. For istace, a table cotaiig employee data (ames ad addresses) may be related to a table cotaiig payroll data (pay date, pay amout, ad check umber). Queries allow the user to ask complex questios (such as What is the sum of all paychecks issued to Jae Doe i 2007? ) from these related tables, with the aswers displayed as o-scree forms ad prited reports. 4

3 A Itroductio to Database Developmet 1 I Access, a database is the overall cotaier for the data ad associated objects. It is more tha the collectio of tables, however a database icludes may types of objects, icludig queries, forms, reports, macros, ad code modules. Access works a sigle database at a time. As you ope Access, a sigle database is preseted for you to use. You may ope several copies of Access at the same time ad simultaeously work with more tha oe database. May Access databases cotai hudreds, or eve thousads, of tables, forms, queries, reports, macros, ad modules. With a few exceptios, all of the objects i a Access 2007 database reside withi a sigle file with a extesio of accdb,.accde, or.adp. The.adp file format is a special database format used by Access to act as a frot ed to work with SQL Server data. Tables A table is just a cotaier for raw iformatio (called data), similar to a folder i a maual filig system. Each table i a Access database cotais iformatio about a sigle etity, such as a perso or product, ad the data is orgaized ito rows ad colums. I the sectio titled A Five-Step Desig Method later i this chapter, you lear a successful techique for plaig Access tables. I Chapters 2 ad 3, you lear the very importat rules goverig relatioal table desig ad how to icorporate those rules ito your Access databases. These rules ad guidelies esure your applicatios perform with the very best performace while protectig the itegrity of the data cotaied withi your tables. I fact, it is very importat that you begi to thik of the objects maaged by your applicatios i abstract terms. Because each Access table defies a etity, you must lear to thik of the table as the etity. As you desig ad build Access databases, or eve whe workig with a existig applicatio, you must thik of how the tables ad other database objects represet the physical etities maaged by your database. After you create a table, you view the table i a spreadsheet-like form, called a datasheet, comprisig rows ad colums (kow as records ad fields, respectively see the followig sectio, Records ad fields ). Figure 1-1 shows the datasheet view of the Cotacts table i the Access Auto Auctio applicatio. The Cotacts table represets people who work with the Auto Auctio. Notice how the table is divided ito horizotal (left-to-right) rows, ad vertical (top-to-bottom) colums of data. Each row (or record) defies a sigle cotact, while each colum (or field) represets oe type of iformatio kow about a cotact etity. 5

4 Part I Access Buildig Blocks FIGURE 1-1 A table displayed as a datasheet For istace, the top row i tblcotacts cotais data describig Joh Joes, icludig his first ame ad last ame, his address, ad the compay he works for. Each bit of iformatio describig Mr. Joes is a field (FirstName, LastName, Address, Compay, ad so o). Fields are combied to form a record, ad records are grouped to build the table. Each field i a Access table icludes may properties that specify the type of data cotaied withi the field, ad how Access should hadle the field s data. These properties iclude the ame of the field (LastName) ad the type of data i the field (Text). A field may iclude other properties as well. For istace, the Size property tells Access how may characters to allow for a perso s last ame. (You lear much more about fields ad field properties i Chapter 2.) Records ad fields As Figure 1-1 shows, the datasheet is divided ito rows (called records) ad colums (called fields), with the first row (the headig o top of each colum) cotaiig the ames of the fields i the database. Each row is a sigle record cotaiig fields that are related to that record. I a maual system, the rows are idividual forms (sheets of paper), ad the fields are equivalet to the blak areas o a prited form that you fill i. Values At the itersectio of a row (record) ad a colum (field) is a value the actual data elemet. For example, Joh, the ame i the first record, represets oe data value. You may have a couple questios, such as: What makes this row differet from other rows i the table? Is it possible to 6

5 A Itroductio to Database Developmet 1 have aother Joh Joes i the same table? If there is more tha oe Joh Joes, how does the database tell them apart? Relatioal Databases Microsoft Access is a relatioal database developmet system. Access data is stored i related tables, where data i oe table (such as customers) is related to data i aother table (such as orders). Access maitais the relatioships betwee related tables, makig it easy to extract a customer ad all of the customer s orders, without losig ay data or pullig order records ot owed by the customer. Workig with multiple tables Multiple tables simplify data etry ad reportig by decreasig the iput of redudat data. By defiig two tables for a applicatio that uses customer iformatio, for example, you do t eed to store the customer s ame ad address every time the customer purchases a item. After you ve created the tables, they eed to be related to each other. For example, if you have a Cotacts table ad a Sales table, you must relate the Cotacts table to the Sales table i order to see all the sales records for a Cotact. If you had oly oe table, you would have to repeat the Cotact ame ad address for each sale record. Two tables let you look up iformatio i the Cotact table for each sale by usig the related fields Cotact ID (i Cotacts) ad Buyer ID (i Sales). This way, whe a customer chages address, for example, the address chages oly i oe record i the Cotact table; whe the Sales iformatio is o-scree, the correct cotact address is always visible. Separatig data ito multiple tables withi a database makes the system easier to maitai because all records of a give type are withi the same table. By takig the time to segmet data properly ito multiple tables, you experiece a sigificat reductio i desig ad work time. This process is kow as ormalizatio. (You ca read about ormalizatio i Chapter 2.) Later i this chapter i the sectio titled A Five-Step Desig Method, you have the opportuity to work through a case study for the Access Auto Auctios that cosists of five tables. Kowig why you should create multiple tables The prospect of creatig multiple tables always itimidates begiig database users. Most ofte, they wat to create oe huge table that cotais all of the iformatio they eed i this case, a Customer table with all the sales performed by the customer ad all the items sold or bought for each customer. So, they create a sigle table cotaiig a lot of fields, icludig fields for customer iformatio (cotact), sales iformatio (date of sale, salesperso, amout paid, discouts, ad so o), ad the product iformatio (quatity sold, product descriptio, idividual prices, ad so o) for each sale. Such a table quickly grows to a umaageable umber of fields ad cotiues growig as ew items are added. 7

6 Part I Access Buildig Blocks As you ca see, the table desig begis to take o a life of its ow. After you ve created the sigle table, it becomes eve more difficult to maitai. You begi to realize that you have to iput the customer iformatio for every sale a customer makes (repeatig the iformatio over ad over). The same is true for the items purchased for each sale, which is multiple items for each sale (thus, duplicatig iformatio agai). This makes the system more iefficiet ad proe to data-etry mistakes. The iformatio stored i the table becomes iefficietly maitaied may fields may ot be appropriate for each record, ad the table eds up with a lot of empty fields. It s importat to create tables that hold the miimum of iformatio while still makig the system easy to use ad flexible eough to grow. To accomplish this, you eed to cosider makig more tha oe table, with each table cotaiig records with fields that are related oly to the focus of that table. The, after you create the tables, you lik them so that you re able to glea useful iformatio from them. Although this process souds extremely complex, the actual implemetatio is relatively easy. Agai, this process of creatig multiple tables from a sigle table is kow as ormalizatio (or ormalizig your tables). Access Database Objects ad Views If you re ew to databases (or eve if you re a experieced database user), you eed to uderstad some key cocepts before startig to build Access databases. The Access database cotais seve types of top-level objects, which cosist of the data ad tools that you eed to use Access: Table: Holds the actual data Query: Searches for, sorts, ad retrieves specific data Form: Lets you eter ad display data i a customized format Report: Displays ad prits formatted data Pages: Publishes data to a corporate itraet Macro: Automates tasks without programmig Module: Cotais programs writte i the Visual Basic for Applicatios (VBA) programmig laguage Datasheets Datasheets are oe of the may ways by which you ca view data i Access. Although ot a database object, a datasheet displays a list of records from a table i a format similar to a accoutig spreadsheet or Excel worksheet. A datasheet displays data as a series of rows ad colums (comparable to a Excel spreadsheet). A datasheet displays a table s iformatio i its raw form. The datasheet view is the default mode for displayig all fields for all records. You scroll through the datasheet usig the directioal keys o your keyboard. You ca also display related records i other tables while i a datasheet. I additio, you ca make chages to the displayed data. 8

7 A Itroductio to Database Developmet 1 Use cautio whe makig chages or allowig a user to modify data i datasheet format. Whe a datasheet record is updated, the data i the uderlyig table is permaetly chaged. CAUTION Queries Queries extract iformatio from a database. A query selects ad defies a group of records that fulfill a certai coditio. May forms ad most reports are based o queries that pre-filter data before it is displayed. Queries are ofte called from VBA procedures to chage, add, or delete database records. A example of a query is whe a perso at the Auto Sales office tells the database, Show me all customers, i alphabetical order by ame, who live i Massachusetts ad bought somethig over the past six moths, ad display them sorted by Customer ame, or Show me all customers who bought cars for a value of $35,000 or more for the past six moths ad display them sorted by customer ame ad the by value of the car. Istead of askig the questio i Eglish words, the perso uses the query by example (QBE) method. Whe you eter istructios ito the QBE Desig widow, the query traslates the istructios ito Structured Query Laguage (SQL) ad retrieves the desired data. Chapter 4 discusses the QBE Desig widow ad buildig queries. I the first example, the query first combies data from both the Sales ad Cotact tables, usig the related field Cotact ID (the commo lik betwee the tables). Next, it retrieves the first ame, last ame, ad ay other data you wat to see. Access the filters the records, selectig oly those i which the value of the sales date is withi six moths of the curret date. The query sorts the resultig records first by cotact s last ad first ames. Fially, the records appear o-scree i a datasheet. A similar actio takes place for the secod example usig sales, cotacts, ivoice items, ad products ad the criteria applied to the search is where the Descriptio field has a car bought whose value i the Price field is greater tha or equal to $35,000. After you ru a query, the resultig set of records may be used i a form that is displayed o-scree or prited o a report. I this way, user access is limited to the data that meets the criteria i the retured records. Data-etry ad display forms Data-etry forms help users get iformatio ito a database table quickly, easily, ad accurately. Data-etry ad display forms provide a more structured view of the data tha what a datasheet provides. From this structured view, database records ca be viewed, added, chaged, or deleted. Eterig data through the data-etry forms is the most commo way to get the data ito the database table. 9

8 Part I Access Buildig Blocks Data-etry forms restrict access to certai fields withi the table. Forms also check the validity of your data before it is added to the database table. Most users prefer to eter iformatio ito data-etry forms rather tha datasheet views of tables. Data-etry forms ofte resemble familiar paper documets ad ca aid the user with data-etry tasks. Forms make data etry self-explaatory by guidig the user through the fields of the table beig updated. Display-oly screes ad forms are solely for iquiry purposes. These forms allow for the selective display of certai fields withi a give table. Displayig some fields ad ot others meas that you ca limit a user s access to sesitive data while allowig iquiry ito other fields. Reports Reports preset your data i prited format. Access supports several differet types of reports. A report may list all records i a give table (such as a customer table) or may list oly the records meetig a certai criterio, such as all customers livig i the State of Washigto. You do this by basig the report o a query that selects oly the records eeded by the report. Your reports ca combie multiple tables to preset complex relatioships amog differet sets of data. A example is pritig a ivoice. You access the customer table to obtai the customer s ame ad address (ad other relevat data) ad related records i the sales table to prit the idividual lie-item iformatio for the products ordered. You the istruct Access to calculate the totals ad prit them i a specific format o the form. Additioally, you ca have Access output records ito a ivoice report, a prited documet that summarizes the ivoice. TIP Whe you desig your database tables, keep i mid all the types of iformatio that you wat to prit. Doig so esures that the iformatio you require i your various reports is available from withi your database tables. Desigig the system s objects To create database objects, such as tables, forms, ad reports, you first complete a series of tasks kow as desig. The better your desig is, the better your applicatio will be. The more you thik through your desig, the faster you ca complete ay system. The desig process is ot some ecessary evil, or is its itet to produce volumious amouts of documetatio. The sole itet of desigig a object is to produce a clear-cut path to follow as you implemet it. A Five-Step Desig Method Figure 1-2 is a versio of the desig method that is modified especially for use with Access. This is a top-dow approach, startig with the overall system desig ad edig with the forms desig, ad it cosists of five steps. 10

9 A Itroductio to Database Developmet 1 FIGURE 1-2 The five-step desig flowchart. This desig methodology is particularly well-suited for Access databases. Overall System Desig Report Desig (Output) Basic Data Desig Table Desig User Iterface Desig These five desig steps, alog with the database system illustrated by the examples i this book, teach a great deal about Access ad provide a great foudatio for creatig database applicatios icludig tables, queries, forms, data pages, reports, macros, ad simple VBA (Visual Basic for Applicatios) modules. The time you sped o each step depeds etirely o the circumstaces of the database you re buildig. For example, sometimes the users give you a example of a report they wat prited from their Access database, ad the sources of data o the report are so obvious that desigig the report takes a few miutes. Other times, particularly whe the users requiremets are complex, or the busiess processes supported by the applicatio require a great deal of research, you may sped may days o Step 1. As you read through each step of the desig process, always look at the desig i terms of outputs ad iputs. Although you see actual compoets of the system (cars, buyers, sellers, ad trasactios), remember that the focus of this chapter is how to desig each step. As you watch the Access Auto Auctios system beig desiged, pay attetio to the desig process, ot the actual system. Step 1: The overall desig from cocept to reality All software developers face similar problems, the first of which is determiig how to meet the eeds of the ed user. It s importat to uderstad the overall requiremets before zeroig i o the details. 11

10 Part I Access Buildig Blocks The five-step desig method show i Figure 1-2 helps you to create the system that you eed, at a affordable price (measured i time or dollars). The Access Auto Auctios database, for example, allows the cliet to sell items (vehicles ad parts) to customers. The Access Auto Auctios database automates the followig tasks: Eterig ad maitaiig cotact iformatio for customers ad sellers (ame, address, ad fiacial history) Eterig ad maitaiig sales iformatio (sales date; paymet method; total amout, icludig tax; buyer ID; ad other fields) Eterig ad maitaiig sales lie item iformatio (details of items actually purchased) Viewig iformatio from all the tables (sales, cotacts, sales lie items purchased, ad paymet iformatio) Askig all types of questios about the iformatio i the database Producig a curret cotacts directory Producig a mothly ivoice report Producig a customer sales history Producig mailig labels ad mail-merge reports These ie tasks that the Access Auto Auctios automates have bee expressed by the cliet. You may eed to cosider other tasks as you start the desig process. Most of the iformatio that is ecessary to build the system comes from the evetual users. This meas that you eed to sit dow with them ad lear how the existig process works. To accomplish this you eed to do a thorough eeds aalysis of the existig system ad how you might automate it. Oe way to accomplish this is to prepare a series of questios that give isight to the cliet s busiess ad how the cliet uses his data. For example, whe cosiderig automatig a auto auctio busiess, you may cosider askig these questios: What reports ad forms are curretly used? How are sales, customer, cotacts, ad other records curretly stored? How are billigs processed? As you ask these questios ad others, the cliet will probably remember other thigs about his busiess that you should kow. A walkthrough of the existig process is also ecessary to get a feel for the busiess. Most likely, you ll have to go back several times to observe the existig process ad how the employees work. Whe you prepare to follow the remaiig steps, keep the cliet ivolved let him kow what you re doig ad ask for his iput as to what you wat to accomplish, makig sure it is withi the scope of his eeds. 12

11 A Itroductio to Database Developmet 1 Step 2: Report desig Although it may seem odd to start with reports, i may cases users are more iterested i the prited output from a database tha they are i ay other aspect of the applicatio. Reports ofte iclude virtually every bit of data maaged by a applicatio. Because reports ted to be comprehesive, reports are ofte the best way to gather importat iformatio about a database s requiremets. I the case of the Access Auto Auctios database, the prited reports cotai detailed ad summarized versios of most all the data i the database. After you ve defied the Access Auto Auctios overall systems i terms of what must be accomplished, you ca begi report desig. Whe you see the reports that you will create i this sectio, you may woder, Which comes first the chicke or the egg? Does the report layout come first, or do you first determie the data items ad text that make up the report? Actually, these items are cosidered at the same time. It is t importat how you lay out the fields i a report. The more time you take ow, however, the easier it will be to costruct the report. Some people go so far as to place gridlies o the report so that they will kow the exact locatio they wat each bit of data to occupy. I this example, you ca just do it visually. The reports i Figures 1-3 ad 1-4 were created with two differet purposes. The report i Figure 1-3 displays iformatio about a idividual cotact (buyer, seller, or both). I cotrast, the report i Figure 1-4 is a ivoice with billig ad customer iformatio. Both of these reports were based o the type of iformatio they use. The desig ad layout of each report is drive by the report s purpose ad the data it cotais. FIGURE 1-3 A cotact iformatio report 13

12 Part I Access Buildig Blocks FIGURE 1-4 A sales ivoice report cotaiig sales iformatio CROSS-REF You ca read more about the reports for the Access Auto Auctios system i Chapters 9 ad 20. Step 3: Data desig: What fields are required? The ext step i the desig phase is to take a ivetory of all the iformatio or data fields that are eeded by the reports. Oe of the best methods is to list the data items i each report. As you do so, take careful ote of items that are icluded i more tha oe report. Make sure that you keep the same ame for a data item that is i more tha oe report because the data item is really the same item. Aother method is to see whether you ca separate the data items ito some logical arragemet. Later, these data items are grouped ito table structures ad the mapped oto data-etry screes (forms). You should eter customer data (buyers ad sellers), for example, as part of a cotact table process, ot as part of a sales etry. Determiig cotact iformatio First, look at each report you have reviewed or attempted to make for the Access Auto Auctios system. For this system, start with the customer data ad list the data items, as show i Table

13 A Itroductio to Database Developmet 1 TABLE 1-1 Cotacts Report Customer-Related Data Items Foud i the Reports Ivoice Report Customer Name Street City State ZIP Code Phoe Numbers Type of Customer Address Web Site Iformatio Cotact Log Iformatio (four fields) Discout Rate Customer Sice Last Sales Date Sales Tax Rate Credit Iformatio (four fields) Customer Name Street City State ZIP Code Phoe Number As you ca see by comparig the type of cotact (customer) iformatio eeded for each report, there are may commo fields. Most of the data fields pertaiig to the customer are foud i both reports. Table 1-1 shows oly some of the fields that are used i each report those related to customer iformatio. Fields appearig o both reports appear o the same rows i the table, which allows you to see more easily which items are i which reports. You ca look across a row istead of lookig for the same ames i both reports. Because the related row ad the field ames are the same, you ca easily make sure that you have all the data items. Although locatig items easily is ot critical for this small database, it becomes very importat whe you have to deal with large tables cotaiig may fields. Determiig sales iformatio After extractig the customer data, you ca move o to the sales data. I this case, you eed to aalyze oly the Ivoice report for data items that are specific to the sales. Table 1-2 lists the fields i the report that cotai iformatio about the sales. 15

14 Part I Access Buildig Blocks TABLE 1-2 Idividual Ivoice Report Sales Data Items Foud i the Reports Lie Item Data Ivoice Number Sales Date Ivoice Date Paymet Method Paymet Salesperso Discout (overall for sale) Tax Locatio Tax Rate Product Purchased (multiple lies) Quatity Purchased (multiple lies) Descriptio of Item Purchased (multiple lies) Price of Item (multiple lies) Discout for each item (multiple lies) Taxable? (multiple lies) Paymet Type (multiple lies) Paymet Date (multiple lies) Paymet Amout (multiple lies) Credit Card Number (multiple lies) Expiratio Date (multiple lies) Product Purchased Quatity Purchased Descriptio of Item Purchased Price of Item Discout for Each Item Taxable? As you ca see whe you examie the type of sales iformatio eeded for the report, a couple of items (fields) are repeatig (for example, the Product Purchased, Number of Items Purchased, ad Price of Item fields). Each ivoice ca have multiple items, ad each of these items eeds the same type of iformatio umber ordered ad price per item. Each sales ivoice will probably have more tha oe item that is sold ad beig ivoiced. Also, each ivoice may iclude partial paymets, ad it is possible that this paymet iformatio will have multiple lies of paymet iformatio, so these repeatig items ca be put ito their ow groupig. Determiig lie item iformatio You ca take all the idividual items that you foud i the sales iformatio group i the precedig sectio ad extract them to their ow group for the ivoice report. Table 1-2 shows the iformatio related to each lie item. 16

15 A Itroductio to Database Developmet 1 Lookig back at the report i Figure 1-4, you ca see that the data from Table 1-2 does t list the calculated field amout, but you ca re-create it easily i the report. TIP Uless a umeric field eeds to be specifically stored i a table, simply recalculate it whe you ru the report (or form). You should avoid creatig fields i your tables that ca be created based o other fields these calculatio fields ca be easily created ad displayed i a form or report. As you ll read i Chapter 2, storig calculated values i database tables leads to data maiteace problems. Step 4: Table desig Now for the difficult part: You must determie what fields are eeded for the tables that make up the reports. Whe you examie the multitude of fields ad calculatios that make up the may documets you have, you begi to see which fields belog to the various tables i the database. (You already did much of the prelimiary work by arragig the fields ito logical groups.) For ow, iclude every field you extracted. You will eed to add others later (for various reasos), although certai fields wo t appear i ay table. It is importat to uderstad that it is t ecessary to add every little bit of data ito the database s tables. For istace, users may express a desire to add vacatio ad other out-of-office days to the database to make it easy to kow which employees are available o a particular day. However, it is very easy to burde a applicatio s iitial desig by icorporatig too may ideas durig the iitial developmet phases. Because Access tables are so easy to modify later o, it is probably best to put aside ocritical items util the iitial desig is complete. Geerally speakig, it s ot difficult to accommodate user requests after the database developmet project is uder way. After you ve used each report to display all the data, it s time to cosolidate the data by purpose (for example, grouped ito logical groups) ad the compare the data across those fuctios. To do this step, first you look at the cotact iformatio ad combie all of its differet fields to create oe set of data items. The you do the same thig for the sales iformatio ad the lie item iformatio. Table 1-3 compares data items from these three groups of iformatio. TABLE 1-3 Comparig the Data Items from the Cotact Iformatio, Sales Iformatio, ad Lie Item Iformatio Cotacts Data Ivoice Data Lie Items Customer Name Ivoice Number Product Purchased Street Sales Date Quatity Purchased City Ivoice Date Descriptio of Item Purchased State Paymet Method Price of Item cotiued 17

16 Part I Access Buildig Blocks TABLE 1-3 (cotiued) Cotacts Data Ivoice Data Lie Items ZIP Code Paymet Salesperso Discout for Each Item Phoe Numbers (two fields) Discout (overall for this sale) Taxable? Type of Customer Tax Locatio Address Tax Rate Web Site Iformatio Paymet Type (multiple lies) Cotact Log Iformatio (four fields) Paymet Date (multiple lies) Discout Rate Paymet Amout (multiple lies) Customer Sice Credit Card Number (multiple lies) Last Sales Date Expiratio Date (multiple lies) Sales Tax Rate Credit Iformatio (four fields) Cosolidatig ad comparig data is a good way to start creatig the idividual table defiitios for Access Auto Auctios, but you have much more to do. As you lear more about how to perform a data desig, you also lear that the cotacts data must be split ito two groups. Some of these items are used oly oce for a cotact while other items may have multiple etries. A example is the Cotact Log iformatio. Each cotact may have multiple log items recorded i the database. This is also true for the Sales colum the paymet iformatio ca have multiple lies of iformatio. It is ecessary to further break these types of iformatio ito their ow colums, thus separatig all related types of items ito their ow colums a example of the ormalizatio part of the desig process. For example, oe customer ca have multiple cotacts with the compay. Oe customer may make multiple paymets toward a sigle sale. Of course, we ve already broke the data ito three categories above: cotacts, ivoices, ad sales lie items. Keep i mid that oe customer may have multiple ivoices, ad each ivoice may have multiple lie items o it. The cotact category represets customer (buyer or seller) iformatio, the ivoice category cotais iformatio about idividual sales, ad the lie items category cotais iformatio about each ivoice. Notice that these three colums are all related; for example, oe customer ca have multiple ivoices ad each ivoice may require multiple detail lies (lie items). The relatioships betwee tables ca be differet. For example, each sales ivoice has oe ad oly oe customer, while each customer may have multiple sales. A similar relatioship exists betwee the sales ivoice ad the lie items of the ivoice. 18

17 A Itroductio to Database Developmet 1 CROSS-REF We cover creatig ad uderstadig relatioships ad the ormalizatio process i Chapter 2. Assumig that the three groupigs represet the mai three tables of your system, less additioal fields, you eed to lik tables together. This step, of course, meas addig table relatioships to the database desig. Database table relatioships require a uique field i both tables ivolved i a relatioship. Without a uique idetifier i each table, the database egie is uable to properly joi ad extract related data. Noe of the tables i our desig has a uique idetifier, which meas that you eed to add at least oe more field to each table to serve as the achor for a relatioship to other tables. For example, you could add a CotactID field to the Cotacts table, the add the same field to the Ivoice table, ad establish a relatioship betwee the tables through the CotactID field i each table. (Creatig relatioships is explaied i Chapter 3.) The database egie uses the relatioship betwee the Cotacts ad Ivoices table to lik customers with their ivoices. Likig tables is doe through special fields, kow as key fields. With a uderstadig of the eed for likig oe group of fields to aother group, you ca add the required key fields to each group. Table 1-4 shows two ew groups ad lik fields created for each group of fields. These likig fields, kow as primary keys ad foreig keys, are used to lik these tables together. The field that uiquely idetifies each row i a table is called the primary key. The correspodig field i a related table is called the foreig key. I our example, the CotactID field i the Cotacts table is a primary key, while the CotactID field i the Ivoices table is a foreig key. Let s assume a certai record i the Cotacts table has 12 i its CotactID field. Ay records i the Ivoices table with 12 i its CotactID field is owed by cotact umber 12. As you ll see i Chapters 2 ad 3, special rules apply to choosig ad maagig primary ad foreig keys. The otio of primary ad foreig keys is the sigle most importat cocept behid relatioal databases. You ca read much more about this importat cocept i Chapters 2 ad 3. TABLE 1-4 Mai Tables with Keys Cotacts Data Ivoice Data Lie Items Data Cotact Log Data Sales Paymet Data CotactID IvoiceID IvoiceID CotactLogID IvoiceID Customer Name CotactID Lie Number CotactID Paymet Type Street Ivoice Number Product Purchased Cotact Date Paymet Date City Sales Date Quatity Purchased Cotact Notes Paymet Amout cotiued 19

18 Part I Access Buildig Blocks TABLE 1-4 (cotiued) Cotacts Data Ivoice Data Lie Items Data Cotact Log Data Sales Paymet Data State Ivoice Date Descriptio of Item Credit Card Purchased Follow Up? Number ZIP Code Paymet Price of Item Follow-Up Date Expiratio Date Method Phoe Numbers Paymet Discout for (two fields) Salesperso Each Item Type of Customer Discout Taxable? (overall for this sale) Address Web Site Iformatio Discout Rate Customer Sice Last Sales Date Sales Tax Rate Tax Locatio Tax Rate With the key fields added to each table, you ca ow fid a field i each table that liks it to other tables i the database. For example, Table 1-4 shows a CotactID field i both the Cotacts table (where it is the table s primary key) ad the Ivoice table (where it is a foreig key). You have idetified the core of the three primary tables for your system, as reflected by the first three colums i Table 1-4. This is the geeral, or first, cut toward the fial table desigs. You have also created two additioal tables (colums) from fields show i Table 1-3. Takig time to properly desig your database ad the tables cotaied withi it is arguably the most importat step i developig a database-orieted applicatio. By desigig your database efficietly, you maitai cotrol of the data elimiatig costly data-etry mistakes ad limitig your data etry to essetial fields. Although this book is ot geared toward teachig database theory ad all of its uaces, this is a good poit to briefly describe the art of database ormalizatio. You ll read the details of ormalizatio i Chapter 3, but i the meatime you should kow that ormalizatio is the process of breakig data dow ito costituet tables. Earlier i this chapter you read about how may Access developers add dissimilar iformatio, such as cotacts, ivoice data, ad ivoice lie items, ito oe large table. A large table cotaiig dissimilar data quickly becomes uwieldy ad hard to keep updated. Because a cotact s phoe umber appears i every row cotaiig that customer s data, multiple updates must be made whe the cotact s phoe umber chages. 20

19 A Itroductio to Database Developmet 1 Normalizatio is the process of breakig data ito smaller, more maageable tables. Each table defies oe ad oly oe etity, such as a cotact or a ivoice, but ot both. The cotact ad ivoice tables are related through a primary key (CotactID i the customers table) ad a foreig key (also amed CotactID) i the ivoices table. There is much more ivolved i the ormalizatio process, but, i the meatime, we ll leave that for Chapter 3. Step 5: Form desig: Iput After you ve created the data ad established table relatioships, it s time to desig your forms. Forms are made up of the fields that ca be etered or viewed i Edit mode. If at all possible, your screes should look much like the forms that you use i a maual system. This setup makes for the most user-friedly system. Whe you re desigig forms, you eed to place three types of objects o-scree: Labels ad text box data-etry fields (the fields o Access forms ad reports are usually called cotrols) Special cotrols (multiple-lie text boxes, optio buttos, list boxes, check boxes, busiess graphs, ad pictures) Graphical objects to visually ehace them (colors, lies, rectagles, ad threedimesioal effects) Whe desigig a form, place your fields (text boxes, check boxes, list boxes, ad radio buttos) just where you wat them o the form. Ideally, if the form is beig developed from a existig prited form, the Access data-etry form should resemble the prited form. The fields should be i the same relative place o the scree as they are i the prited couterpart. Labels display messages, titles, or captios. Text boxes provide a area where you ca type or display text or umbers that are cotaied i your database. Check boxes idicate a coditio ad are either uchecked or checked (selected). Other types of cotrols available with Access iclude list boxes, combo boxes, optio buttos, toggle buttos, ad optio groups. CROSS-REF Chapter 7 covers the various types of cotrols available i Access. I this book, you create several basic data-etry forms: Cotact Log: A simple data-etry form Cotacts: A slightly more complex data-etry form, cotaiig several differet types of cotrols Sales: Combies data from multiple tables Products: Data-etry form for addig products to the Access Auto Auctio database. 21

20 Part I Access Buildig Blocks You ll ecouter each of these forms as you read through the followig chapters. Although the Access Auto Auctio is but oe type of database applicatio built with Microsoft Access, the priciples you lear buildig the Access Auto Auctio tables, queries, forms, reports, ad other database objects are applicable to virtually ay other Access project. Summary This chapter itroduces the cocepts ad cosideratios drivig database developmet. There is o questio that data is importat to users. Most compaies simply caot operate without their customer ad product lists, accouts receivable ad accouts payable, ad payroll iformatio. Eve very small compaies must efficietly maage their busiess data. Good database desig meas much more tha sittig dow ad kockig together a few tables. Very ofte, poor database desig habits come back to haut developers ad users i the form of missig or erroeous iformatio o screes ad prited reports. Users quickly tire of re-eterig the same iformatio over ad over agai, ad busiess maagers ad owers expect database applicatios to save time ad moey, ot cotribute to a busiess s overhead. 22