Friday, 13 June 2014

MS Access Vinyl Database 2 - Creating Tables

This series will take a little time to build as I decided I should start from scratch for the blog. My advantage is I can copy from what I've already done and import data, but starting from scratch will allow me to avoid some of the inconsistencies that exist in my current database.

In this article we will create the database for our music collection and then create the vital tables - the "storage jars" for the data about our music.

Microsoft Access is the database tool that comes with Microsoft Office. If you don't have this then this series of articles is going to be a touch difficult to follow...

Open Access and then create a new database based on the Blank Database option as shown - simply double-click this icon.

Give your project a name - I've called mine "music" and I'm storing it in a sub-folder called "ACCESS".

The first thing to do is to create our first table. Click on Create and then on the Table icon to the left.

The new table will open in Datasheet View. This looks a little bit like an Excel spreadsheet (Access can be thought of as basically a series of linked spreadsheets).

This method of creating a table is a little dangerous and we are not going to enter any data yet until we have defined the fields of the table. If you had a table for cars, for instance, the fields would hold the make, model, colour etc.

So straight away click the View icon as shown. This will be currently showing the icon for the Design view and this is the one we want. You could also click the little triangle (down arrowhead) below the word View and then click the option for Design View.

A small window will open asking you to give a name to the new table. We are going to create the main table first - the one that will hold details of all the music tracks you have in your collection. Probably the most important table that the database will contain. By the time we finish we will have tables, forms, queries and possibly reports. You might want to name them all along similar lines but that carries a risk of confusion. If we simply called this table "music" and then also called the form (the window for entering data into the table) "music" and then called a query the same name as well, then it's possible we may be faced with a list of database objects where there are three objects called "music" and we don't know which is which.

This may sound a bit complicated at this stage and I'm sorry if it does, but to get round this problem I'm going to name every single table with a "t" and then an underscore before the more meaningful bit of the table name. So instead of "music" we'll name this table "t_music" and when we get to creating the forms and queries they will be "f_name" and "q_name" and then in any list we can tell which is the table and which is something else. Just take my word for it at this stage. You could be glad you did at some point in the future!

By the way, I'm old-fashioned - I know you could have spaces in your table name instead of using underscores, but again there's a risk somewhere that you mix up a table name with the following word or cut one short leaving out a word, so using underscores is a safe approach.

Ok, I've made you read all that when all you needed to do was type t_music and click the Ok button! Moving on...

A few things to say here. All of the text you see in the two columns labelled Field Name and Data Type needs to be either typed in or defaults into the right hand column as you add the field name and will need amending in some cases to match the diagram above.

Every table will have a main ID field at the top and for this field (and for this field only) it needs to be designated the Primary Key. By default the top field will be named ID and will be the primary key. This means it will hold an automated number and each record will always have that number and if a record is ever deleted then that number will never be allocated to a new record. Think of it this way: in a table of four records if record number 3 gets deleted then what was record number 4 becomes the third record. But the primary key will not change either for the old record 3 or old record 4. If you listed the records in the order they were entered, the ID field would read 1,2,4. A safety feature. Very necessary as that field will be the link between tables.

Rather than have to type "Parlophone" in the label field for every record released by that company, we will be able to store just the number that refers to the label Parlophone. It saves space. And if you have a large record collection of thousands of tracks it will also save you a lot of time. And no... you won't have to remember, or ever see, the numerical ID.

Whilst all ID fields can be numerical, you may want at some time to specify your own codes for something. I've done that for the Media ID. The media field will hold details of whether the music is on a 7 inch 45 rpm vinyl, a music cassette, an album or is a digital file on your PC, laptop, iPad, phone or whatever. So against the music_media_id you can see that this is a text field, not a number. At the bottom of the window, where the default for a text field would be 255 characters, I have made it 2 characters. This will appear in "Field Size", the top row in the bottom part of the window.

Last point to make here: I've labelled every single field with the prefix word "music" and an underscore. Other tables may have a similar fieldname - the Artist table will have a field called artist_ID and to avoid confusion we don't want there to be two tables having fields with the same name. So the prefix makes it music_artist_ID and it will save us heartache in the future.

We've created the first table - click the Save icon in the top left corner of the screen next to the Windows icon. Not necessary, but again it's good practice: close the table by clicking the X on the right of the window just to the left of the words "Property Sheet".

I've covered a lot here, but to make it worthwhile for you, let's create some of the other tables now to finish off this article. We'll start with the media table. Once again go to Create > Table, then click the Design View icon and name the new table t_media.

This is the table mentioned earlier where you need to change the primary key from AutoNumber to Text. Then change the field size from "255" to "2". Make sure that the Primary Key icon is lit up as shown and against "Indexed" in the left column of the lower window it should read "Yes (No Duplicates)" in the right hand column.

Click the Save icon in the top left corner of the screen next to the Windows icon and close the table by clicking the X on the right of the window just to the left of the words "Property Sheet".

Now for a table to hold details of record labels. Again, only two fields are needed: the code and the name. Name this table "t_label". Make sure you save it once you have defined it. Refer to instructions above if you need help remembering how to create the table.

Last table for now. This is called "t_artist" and will hold details of artists, both individual singers and groups/bands. All the fields we need for now are the ones shown. A code, the name of the artist and the name as it would be used in an alphabetical sort.

Just to give an example here. An artist with the name "Elvis Presley" would have the text "presley elvis" stored in the field artist_alpha. We will use this field to sort records so Elvis Presley appears correctly with other surnames beginning with P rather than just after Elvis Costello! In the same way "The Beatles" would simply have "beatles" in the artist_alpha field so that they appear under B in the alphabetical list.

Click the Save icon in the top left corner of the screen next to the Windows icon and close the table by clicking the X on the right of the window just to the left of the words "Property Sheet".

Ok, I know you must be dying to start entering data into these tables but there is a risk in just entering data straight into a table. It's easy to add an extra field by mistake or delete a table instead of deleting a single record (row). If you really must do this now, I suggest you do it only in the t_media table.

Open the table by double-clicking it in the list of tables on the left of the screen. Add whatever records you need to enter. Some will wonder what a 78 rpm record is (read my other blog...) Others may have a collection of even older wax cylinders. You may want to catalogue video files...

In the next article we'll create the first form based on one of the simpler tables and also create a special form that will be used as a menu screen. This menu form will be used to open all the other forms and to select report output. We'll also build buttons onto it to close the database down so that when using the database you won't need to be an expert in Access. In fact you'll be able to let people use it who have no idea what Access is!

3 comments:

Anonymous said...

This Access lesson is very useful, thank you very much for your effort.

Unknown said...

Thanks for getting us started... where or when may we find the next article to continue? Also, I'd like to be able to capture the position a particular song reached on the various record charts (Adult Contemporary, Easy Listening,R&B, Soul, etc.) and often a particular song may have become a crossover and obtains postions on multiple charts... any thoughts on the best way to structure this data?

John Burke said...

Hi "Unknown" (must be shy...?) I'm afraid I retired, thinking I'd have tons of time to do stuff like this - foolish thought... It's not a dead project just yet, but it is having a good nap. I hope to return to it sometime. In regards to your query - as each song may have multiple chart entries (even if you had only one chart) you'll need a table to store the charts (at least Chart ID and Title/Name) and then one to hold the chart ID, song ID, date of entry, weeks on chart and highest position.