Start learning with our library of video tutorials taught by experts. Get started
Viewed by members. in countries. members currently watching.
In FileMaker Pro 11 Essential Training, Cris Ippolite demonstrates the principal features and functions of this popular database software, including creating tables and relationships, managing fields and records, and working with layouts. The course shows FileMaker developers how to find, sort, and share data as well as how to create reports, calculations, and scripts. It also covers brand new features in FileMaker Pro 11 such as the Inspector tool, charting, and portal filtering. Exercise files accompany the course.
Once you've completed your data modeling exercise, you will have determined what tables you are going to need in your FileMaker database, as well as what relationships you are going to need between these tables. Since we've already gone into our FileMaker database, and we've defined the tables that we need - we've talked about four tables that we need to define - we need to now create relationships between them. Now what we need in order to create relationships is something that could hook these two tables together. So each table has got to have a little hook in there that allows it to connect itself to another table that it's related to.
In relational databases, you're going to connect two related tables together using special fields that are called Keys. A key field is just like any other field you are defining in your database, but key fields come in two different types: There is a Primary Key and a Foreign Key; two more pieces of vocabulary for you to wrap your head around. The Primary Key is a field that gets defined in the Parent. Remember that there is always a Parent in a relationship and always a Child. Because it's going to be one to many, the Parent is the one; the Child is the many.
So in our case, we need to define a Primary Key field in every Parent table and define a Foreign Key field in every Child. Now let's talk about what these mean a little bit more before we go ahead and define these. First, a Primary Key field: A Primary Key field is defined in each Parent table, and its main role is to ensure the uniqueness of each record in this table. So they must contain a unique serialized value inside of every record. So these records must never be duplicated within a single table, and each Parent must have one Primary Key defined.
The plain English version of this is just it's a simple way for you to uniquely identify every record in your database, and that way there will be no confusion. Here is record number one versus record number two, and since there will only ever be one record number one, you can never confuse it with any other records in your database. The next type of key field is called a Foreign Key field. This is going to be used to link a related Child record, or a record in a Child table, back to its Parent record in the Parent table. So in the case, for example, of having a customer having multiple invoices, we can have a Primary Key field that's defined, that's called the Customer ID. And every customer is given their own ID, but then in every invoice that's related to that customer, we need to put the Customer ID into a field that's called a Foreign Key field.
This is how we will actually link, or know those two are related to each other. I'd like to use the example of the last name. How do you know that you are the child of your parent? Because you share one thing in common, or something that links you two together. So on paper if you see two people's names, you can make an estimate as to whether or not they might be related if they have something in common. In that case we would be they have the same last name, and in a database that thing that you have in common is the same value showing up in a Primary Key field in a Foreign Key field on each side of a relationship.
Now each Child table is going to have a Foreign Key field defined in it; however, these values do not need to be unique, because since any one customer could have let's say five different invoices in the Invoice table, that means that there's going to be five invoice records that all have the same Customer ID in the Foreign Key field. So they won't be unique. And each type of key field is just a field that gets defined in every table. So let's take a look at the tables that we've got and determine what types of keys we would need. So if you use the simple fact that every Child table needs to have a Foreign Key field, which one of these tables is going to be a Child table? Well, let's look at our relationships.
You'll see that the lines that we are using have a single hash on the Parent side or on the one side and a double hash on the many side. So if we look at Customers and Invoices, we see there is a relationship between them. Which one of them is the Parent? It's the Customer. So we know that a Parent needs to have a Primary Key field, so we're going to have a Primary Key field defined inside of Parent, and then Invoices are acting as the Child in the Customer relationship, so that's going to get a Foreign Key because every Child gets a Foreign Key.
But also their table acts as a Parent in the relationship between Invoices and Invoice line items. So in that case, Invoices plays two roles: Child in the Customer relationship, but Parent in the Invoice line items relationship. Now Products only plays one role. It's a Parent in the Parent Invoice line item relationship; therefore, it serves as a Parent. It's going to get a Primary Key. The Invoice line items table that we created to resolve the many-to-many relationship plays Child in both the Products and Invoices relationship, which is common in those tables that you create to resolve a many-to-many.
So in that case, this means that the customer is going to have a Primary Key, Invoice will have a Foreign Key and a Primary Key, Products are going to have a Primary Key and Invoice line items will have two Foreign Keys, because we remember each Parent gets a Primary; each Child gets a Foreign Key. Determining which keys you need in your database tables is an important part of setting up relationships with a new database. Once you've determined which tables perform which roles, that'll help you to determine which tables need to have a Primary Key defined and which need to have a Foreign Key defined.
Find answers to the most frequently asked questions about FileMaker Pro 11 Essential Training.
Here are the FAQs that matched your search "":
Sorry, there are no matches for your search ""—to search again, type in another word or phrase and click search.
Access exercise files from a button right under the course name.
Search within course videos and transcripts, and jump right to the results.
Remove icons showing you already watched videos if you want to start over.
Make the video wide, narrow, full-screen, or pop the player out of the page into its own window.
Click on text in the transcript to jump to that spot in the video. As the video plays, the relevant spot in the transcript will be highlighted.