* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Download REVISING JOE`S DATABASE
Survey
Document related concepts
Information privacy law wikipedia , lookup
Microsoft Access wikipedia , lookup
Open data in the United Kingdom wikipedia , lookup
Business intelligence wikipedia , lookup
Expense and cost recovery system (ECRS) wikipedia , lookup
Versant Object Database wikipedia , lookup
Concurrency control wikipedia , lookup
Entity–attribute–value model wikipedia , lookup
Data vault modeling wikipedia , lookup
Clusterpoint wikipedia , lookup
Extensible Storage Engine wikipedia , lookup
Transcript
Access 2002 Chapter 6 Getting Started `DEFINING TABLE RELATIONSHIPS REVIEW OF CONCEPTS AND WORK DONE PREVIOUSLY Throughout our efforts in developing Joes’s Fruit Stand database, we have had much emphasis on table relationships. As you remember, Joe had developed a database using just a single table. In this table he tried to do everything and soon ran into problems. You have divided this table, first into two parts and finally into three tables. You found that three tables were needed because the database involved many to many relationships. You saw that only two tables were necessary to represent the major topics of the database—Vendors and Fruit. However, since vendors could supply many types of fruit, and fruit could be supplied by many vendors, a third table was needed to connect the other two. This type of table is called a junction table. Junction tables have special properties. The primary key for a junction table consists of foreign keys to each of the parent. FruitID is a foreign key to the Fruit table and VendorID to the Vendor table. These two fields combine together to form the primary key of the Fruit-Vendor table. The major reason for changing Joe’s database from a one table database to a two table database and finally to three tables was to improve the integrity of the data. If data has integrity, it can be trusted to be correct or at least consistent. Joe’s original design failed because of redundant data. Redundant data works against data integrity because the same values are stored multiple times. Redundancy means that extra physical storage is required, and that effort is required to enter and maintain the data. More important, however, is the fact that the data may easily become unreliable. Keying errors may cause differing values to be entered in different records. When a data value changes the data entry process might miss some copy of the data. By storing data values in only one database Arthur R. Buss Access 2002 AC GS 6.1 <Au 1st draft> 5/13/2017 Access 2002 Chapter 6 Getting Started location, all of these problems can be eliminated. On the other hand, if the wrong value is entered in that one location all of the results are wrong. Even though the use of multiple tables can reduce data redundancy, it introduces a new potential problem—the lack of referential integrity. Referential integrity means that the tables are correctly linked to each other. We have seen that relationships rely on foreign keys to maintain links between the tables. Another way of saying this is that the foreign key refers to a specific record in another table. A database can be said to have referential integrity when we can be assured that each foreign key field refers to a record that actually exists in the database. Let’s see how this could be a problem. Suppose Joe has been getting his kumquats from a vendor called the Fruit Depot. Due to some dispute with the vendor, Joe decides no longer to deal with the Fruit Depot and deletes this Vendor record from the database. Later on Joe needs to order some more kumquats. Without referential integrity safeguards in place, Joe will find that the Fruit Depot is still listed as a vendor for kumquats. However, if Joe attempted to place an order the database would not be able to create the order since the Fruit Depot record has been deleted. You may have had a similar experience if you ever went to a library and looked up a book in the catalog, but when you went to the indicated location, the book wasn’t there. References that don’t point to anything are not of much use. Fortunately, Access provides ways to assure referential integrity. UNDERSTANDING THE USE OF JOINS IN THE CREATION OF QUERIES In this session you will be developing queries that involve the use of joins. One of the strengths of a relational database is its flexibility in creating queries. While relationships are very important in the design of a database, it is possible to combine data from multiple tables even if Arthur R. Buss Access 2002 AC GS 6.2 <Au 1st draft> 5/13/2017 Access 2002 Chapter 6 Getting Started relationships have not been established. This process is called a join. Joins can combine any two tables as long as they have a common field. The common field does not have to be a foreign key but can be any field that exists in both tables. In fact, tables can be combined even if there is no common field. A third table can serve as a link if it has a field that is common the first table and another field common to the second. What is the difference between a relationship and a join? Relationships represent the structure of the database. They are the way data will be processed most of the time. A join is the process of combining tables to produce a new result. Multi-table queries in Access involve some type of join whether we specify it or not. Another difference between joins and queries is the use of indexes. An index is much like the library catalog mentioned above. Indexes are special files maintained by the DBMS to allow it to quickly find particular records without having to search through an entire table. When a relationship is defined Access creates an index. Joins do not have indexes per se, but a join may take advantage of indexes that already exist. The basic join is called an inner join. An inner join requires that a field in one table equals a field in a second table. Inner joins are not the only way to specify the query, but when it is presented in the QBE (or design) grid, Access generally uses the inner join process. In addition to the inner join, Access may also do outer joins. Outer joins allow the user to see not only the records that are matched but those that are unmatched. The value of an outer join may not be immediately obvious, but you may be able to see that if you want to find any orphan records. That is, any records from one table that does not have a match in a related table. Orphan records can be a sign of data integrity problems. For example, Arthur R. Buss Access 2002 AC GS 6.3 <Au 1st draft> 5/13/2017 Access 2002 Chapter 6 Getting Started some records may have been deleted, links between records not established, or duplicate records with spelling differences in key fields were entered. EXERCISE Joe’s New Requirements Joe has realized that his database not only can be a way of keeping track of the fruit that he has on hand, but also can assist him in making decisions as to placing new orders. In other words, Joe doesn’t just need to know about the current inventory of fruit, he also wants to know when to place new orders and with whom to place them. In order for Joe to know when to reorder he needs to have some sort of trigger to tell him when he is getting low on inventory. Joe normally reorders on Mondays, after the heavy sales of the weekend. His suppliers generally take three days from when the order is placed to deliver the fruit. Three day delivery means that shipments should arrive on Thursday, just in time for the next weekend. Joe over the years has developed a good sense of the minimum amount he needs to have on hand for each type of fruit. When the amount on hand falls below this reorder point, he needs to order more fruit. Joe wants to incorporate this information into the database so that one of his employees can do the reordering and Joe can have an occasional Monday off and maybe even go on a vacation. The second part of the problem is for Joe, or his assistant, to determine which vendor to order from. In the real world, there are many factors that might go into this decision such as quality of fruit, time of delivery, and payment terms. At this point, we will look at only one—vendor price. The vendor price for the fruit is different from the cost of fruit in the Fruit-Vendor table. The data in the Fruit-Vendor table represents the fruit that is on hand and does not necessarily Arthur R. Buss Access 2002 AC GS 6.4 <Au 1st draft> 5/13/2017 Access 2002 Chapter 6 Getting Started represent what vendors are currently charging for the fruit. Joe needs to know which vendor will give the best price this week. Things to Think About Here we are going to let you think about how you might respond to these needs and the changes you might make to the database to solve Joe’s ordering needs. Think about the following questions? 1. Can the database meet these needs without modifying the current tables? In other words, can queries supply the necessary information from the data already in the database? 2. If the current data is not sufficient for the needs, what additional fields need to be added? 3. Can any additional data fields be added to the existing tables? If so, where? 4. If not, is an entirely new table(s) necessary? What is the primary key of any new table? 5. What relationships exist between any new table and the existing tables? These questions are important to the success of the database and it will take some serious thinking to determine the answer. We will have you work through a possible solution in the What We Have Learned Session. Arthur R. Buss Access 2002 AC GS 6.5 <Au 1st draft> 5/13/2017