Information Systems

IS 251 Introductory MS Access Exercises We will start by getting used to some of the intricacies of the Access software. Some of the problems that we will encounter initially are identical to what we would find if using Oracle or any other database tool. Lets start by creating a simple table in Access to support an excel file of credit card transaction data. The content of the excel file is as follows:

We need to export the data as a tab delimited text file in preparation for loading it into Access. The data fields in Access are for transaction number, credit card number, transaction date, vendor ID, vendor name, and transaction amount. We need to set up the Access database to accommodate these entries. We have to make a few judgment calls at this point and it pays to think ahead. This is like pouring the foundation for a house. If you dont get it right, the house will be wrong and you cant easily retrofit the foundations.

What we have to do first is to figure out a spec for the fields (also called attributes). Were not going to worry just yet about normalization that can come later. First lets try to get the data into Access. Once we have it in Access, we can start to manipulate the data. The first thing we need to do is to add a field at the end its easier said than done. In excel, it would be a breeze. Not so in Access. The goal of this field is to pick up from the credit card number whether it is Visa, Mastercard, etc. As a practical guide, all Visa cards begin with 4, all Mastercard cards with 3, all Discover cards with 6. Lets assume for the moment that we do not have any Amex cards as this would throw off our field designs Amex has 15 numbers, all others have 16. Amex begins with 3. So how might we adjust for this? Add a zero at the end! To add a field in Access, we create a query and then turn the query into a table. Lets add a field called Recipient:

This shows how we build a new field that goes at the end of the existing structure. We then click on make table and run having entered a new table name (TempTable) into the space provided.

And now we get the following table with a recipient field added at the end:

Now we can start to do other things with the table. We can begin by deciding what amount of interchange fees to deduct from the transaction amount. So for example, a customer using a Discover card in Target is billed for $121.09 (the third transaction down the list) but Target does not get this amount. Lets say that the deal is to deduct 2.2% for that vendor number (121211) when using Discover but then there are lesser fees for other cards. We need to bring in another table of interchange fees.

So we need to again create a new table where the first column is an agreement number, constructed from the VendorNumber and the Recipient. As before we dump the data out of excel into a tab delimited file, create a blank table in Access and then import the data. As before, we can expect some hiccups as we go about importing the data probably because of formatting issues.

Notice that the data in the interchange% field has been set to zero. How can we correct this? After all, it is meant to be a percentage field.

Before we start to work on any relationships, we need to go back to the original credit card transaction file and do some more work. We had earlier added a recipient field. What we can do instead is to get rid of the recipient field and use the data in this transaction file to figure out what the agreement ID is. Its the (vendor number * 10) + the recipient: its a compound constructed field. Heres what we end up with.

Now we can begin to form relationships between the files. First, lets try to work on the many-to-many (M2M) relationship idea. This is the start of what are called entity relationship diagrams.

Why is this relationship showing a many to one link? Now when we do this, we can take another look into Table2 to find the following:

What it has done is to combine the files in a way that allows us to see the transactions recorded under each agreement. Some agreements have nothing under them. Others have two. Now we can think about computing some numbers like how much we can expect to withhold in interchange fees. First, lets run a report.

There are 20 transactions above. We should probably try to get a running total of some sort for each agreement. We only use 18 agreements since there are two transactions under two different agreements.

We add a textbox here

and we set its properties so that the control source is a formula.

This gives us:

There is a snag, however. Since amount due is a constructed field for the purposes of this report, we cannot group by agreements in order to see what the total amount due might be by agreement. How can we do this?