Archive for the ‘Training’ Category

Elements of a Database

Friday, April 22nd, 2011

Over the years in my consulting business, perhaps the most common way I find individuals handling information for their jobs is in Excel spreadsheets. Almost every one in every position needs to keep some type of information that is specific to their job. And Excel is a great place to do it. It is fairly easy to use, you can sort by columns and you can even share the information with Word to create form letters and address labels. But sooner or later most of us get to the place where we need a better way to use and manage our data, especially if we want to use our data in many different places or summarize and report on it.

In a later article, we will explore some of the ways FileMaker Pro and Excel can work together. Here I bring it up because if you are familiar with storing data in Excel, you will understand some of the basic elements on a database.

 

The Table

Data is stored in tables. An Excel worksheet is a table. A table is a collection of data about a specific thing, such as people or companies or products. My wife has a spreadsheet on which she checks off what groceries she needs this week. This is a table about groceries, not people invited to my daughter’s birthday party next month. This is important to understand: a table should only contain information about a specific thing, subject, or entity. Here is a table of people:

 

Rows and Columns

A table is made up of rows and columns. Each row represents one person in our sample table. Steve Linder is the Support Representative for Carp Corp. Ideally, no other row should contain Steve Linder’s name or information. On my wife’s grocery list each line contains one grocery item. So, a row represents one specific, unique person in our table above.

Each column represents an attribute of that person. Steve Linder’s position is “Support Representative.” His company is “Carp Corp.” Attributes may be the same for different people: Betty Brown also works for Carp Corp. Someone’s first and last names are attributes of that unique person, even though many people may have the same name. (This presents a problem when storing data about people, but we will talk about how to solve it later.)

In FileMaker Pro, a row is called a “record.” Each person in our database will have his or her own record. The attributes describing that person are “fields.” If our table were in FileMaker Pro, the columns are fields and the column headers at the top of our table are the field names. Here is what our table may look like in FileMaker Pro 8.5:

 

Files

In FileMaker Pro, a file can contain many tables. Prior to FileMaker Pro 7, each file could contain only one table. Because of this, it was common for FileMaker developers to use the words “file” and “table” interchangeably. This has changed since FileMaker Pro 7, but you may still run across this in articles about FileMaker database design.

 

What is a database?

Friday, April 22nd, 2011

Let’s just start at the very beginning: What is a database?

In essence, a database is a collection of information. You may be surprised to learn that a database doesn’t have to be on a computer. It can be a cigar box full of business cards or an envelope full of coupons. But when your box starts filling up or your envelope bulges with coupons, it becomes difficult to find the right card or coupon. So you may one day organize your cards in a Rolodex or your coupons in an expanding file pouch with letter tabs. Now your information is stored in a “database system”.

“A database system is a set of procedures, devices, and rules for managing the information in a database.” (from ”Learning FileMaker Pro 8.5″ by Jonathan Stars Wordware Publishing; Palno, TX) So, a Rolodex is a “database system” because it takes your cigar box full of business cards, puts them on the Rolodex spindle and organizes them alphabetically.

Let’s say you spend a few hours one Saturday organizing your cards in your new Rolodex by last name. You proudly take your full spindle into the office. You enjoy looking up people’s phone numbers so quickly. One day you remember a saleswoman named “Sandra” you promised to call, but you can’t remember her last name. You think, “She worked for some office machine company, but I don’t remember which.” You could flip through your Rolodex and pull all the cards from office machine companies, or every card with a first name “Sandra”. You can see that this is not very efficient.

Most of us think of computers when we hear the word “database” because they are excellent devices for storing, retrieving, finding and reporting on data. If you had your cards entered into a computer-based database system you could search for every person with the first name “Sandra”. Chances are, in a second or two you would end up with fewer than a dozen names and one would probably stand out or jog your memory as the one you had promised to call. FileMaker Pro is one of many computer-based database products available for computers running Macintosh or Windows.

Next, we will look at the basic elements of a database, then we will focus on how these work in FileMaker Pro.

 

The Join Table

Tuesday, February 15th, 2011

In my coaching of FileMaker developers two topics seem to come up most often. For newer developers it is summary reports and how to build them. The other issue that comes up often—even with experienced developers—is the “Join Table” used to create Many-to-Many relationships.

There are three basic relationships between entities or tables:

  1. One-to-one
  2. One-to-many
  3. Many-to-many

This article assumes that you are familiar with basic relationships and key fields.

One-to-One Relationship: Though the simplest relationship, it is probably the least used. In this relationship a record in one table is related to one and only one record in another table and visa versa.

Each department in a company has only one manager and each manager only runs one department at a time. The Marketing department’s record in the company database will have its Manager’s unique People ID. In the People table this is the “Primary key” but when this value is stored in the Department record it is a “Foreign key.” It links the department with only one person record. (In my figures the blue text are fields that store attributes about each entity.)

One-to-Many Relationship: This is the most common relationship. A record in one table can be related to many records in another table. For example, in a FileMaker Pro file with a People table and a Companies table. One Person can be related to no company, one company or many companies. John Doe is an accountant with ACME Corp. so his People record is linked to ACME’s Company record. His wife, Jane, is an engineer at ACME so her People record is also linked to ACME’s Company record. If you look at ACME’s company record you would see both John and Jane listed as employees. To link John and Jane to ACME, their People record would have a field to store the unique Company ID number for ACME. Every company in the Company table has a unique Company ID which is that company’s “Primary Key”. Here is a simple diagram that illustrates the relationship between People and Companies:

Many-to-Many Relationship: Now, what if John takes a night job with BucksBack Tax Preparation Service to make extra money during tax season? With the structure above John can only be related to one company at a time.  We could add a field called “Company 2 Key” so John can be linked to BucksBack. But what if John takes a new job with Lexicality, LLC, and we want to capture his job history? Create “Company 3 Key”! You see how this can get out of hand. Also notice that the Job Title and Hire Date fields in John’s record will have to change with each job change.

Think about the relationship between John and each company. John was an accountant for ACME, is a part-time tax preparer for BucksBack and now is the Comptroller for Lexicality. These job titles define the nature of John’s affiliation with each company. This affiliation is an entity in itself deserving its own table and would look like this in our diagram:

“Affiliation” joins a person with a company by storing the People ID and the Company ID in one record. John will have three Affiliation records: one joining him to ACME as a former accountant, one joining him to BucksBack as a tax preparer and one joining him to Lexicality as its Comptroller. The Affiliation table is a “Join Table” because its records join two tables’ records. Notice that we moved the Job Title and Hire Date to the join table because these fields tell us something unique about each the Affiliation.

Many-to-Many relationships are not difficult to create and manage in FileMaker Pro and they can add powerful functionality to your software. They also allow you to properly represent the connections between your data.

I hope this has helped you “get your head around” the concept of the “Join Table.”