Join Cris Ippolite for an in-depth discussion in this video Diagramming relationships (with ER diagrams), part of FileMaker Pro 11 Essential Training.
- View Offline
So far in this chapter we've learned about basic relationship types. We've reviewed those as the one-to-many and many-to-many being the most common and then sort of an obscure kind of rare one called one-to-one. In this movi,e we're going to expand on those concepts, and we're going to learn a general method for diagramming database systems. This method we're going to learn is called Creating an Entity Relationship Diagram, and I know that sounds like a lot of Computer Science and kind of a mouthful, but it's a common term if you're in database circles, or if you're going to be working with FileMaker Pro it's going to be something that you're going to run into quite a bit.
The good news is it's often referred to just simply as an ERD. So an entity relationship diagram, entities of course being tables. If you really break this down, it's a diagram that just shows what the relationships are between your tables. It's a simple process, and generally most useful for relational database systems. Of course, FileMaker's relational databases system, but any other database system requires data modeling and entity relationship diagrams as well. So the ERD modeling really breaks down into three phases.
First you're going to develop your list of tables, which we've done, because we want to evaluate what types of information we're going to be storing in our database and how they break up into individual groups. So we've already determined what our list is. Then you determine in diagram the relationships between those tables, which we're going to do here. And then you do sort of a rinse and repeat process by reviewing your diagram and you repeat steps in one only if you encounter either a many-to-many or a one-to-one relationship. And ultimately your goal is to resolve all of your relationships to one-to-many.
Now in this process, I advice you to use a piece of paper and a pencil, because whatever your first diagram is is almost never what the last diagram is, and it's an important part of the process to kind of go through this a couple of times before you've got your final set of relationships. In the database that we're going to be creating in this title, we've got a pretty standard invoicing solution. So if we start at step number one, and we determine what our list of tables might be, you'll remember that in the database that we're going to be creating in this title, we've determined that we've got three different tables already.
We've got one table that's going to store customers, one that's going to store invoices and one that's going to store products. Those are all three discretely different types of data, so we know that they all need their own table. So in the example, like the one we've got here, we can see what types of data we're going to be storing, pretty simple stuff. And what's important is that we've picked these unique and discrete bucks of data. So after we've determined what tables we need, so now that we've got our list, we want to move on to determine how these things are related to each other, and when you're doing this, it's another good idea to sketch this out on a piece of paper with a pencil, for example. And really what you're going to do is ask yourself a series of questions.
For example, consider the case of a system that tracks both customers and invoices, and asking some questions about the business rules that govern the customers and invoices within your organizations, or within the users that you have, you might find out the following: For example, consider the case of a system that tracks both customers and invoices, and asking some questions about the business rules governing customers and invoices at this particular organization, you find out the following: Each customer may potentially have many invoices in the system, and each invoice is associated with one, and only one customer.
So data modelers like yourself would call the relationship between customers and invoices a one-to-many relationship, meaning one customer can have many invoices. So if you ask in reverse about the relationship between invoices and customers, the answer could also be reversed, and you could call it many-to-one, meaning there could be many invoices to just one customer. So the questions that we're talking about here are, can one customer have many invoices? So if the answer is yes, then you want to create a relationship between those two tables.
Or if we determine by asking this question that there is no relationship between these tables, then we don't have to do anything here. We just note that accordingly. But in this example, we have in fact determined that one customer could have many invoices. We still have to evaluate the relationship between invoices and products. So let's ask the same questions. Does a product have a relationship with invoices, so, for example, can one product appear in many invoices? Yes. So we've got a one-to-many go in from products to invoices.
It appears that way. But can an invoice have more than one product appearing on it? Well, that answer is yes as well. So what we've got is a many-to-many relationship, and the key to resolving a many-to-many - because if you recall, we can't have many-to-many relationships. There were various different reasons. There were things that we can't do as far as storing the data properly. There are ways that that we can't find data properly. We can't report on it properly. And this is a good place to catch it, rather than after you spent hours and hours and hours developing a many-to-many relationship into your system, only to find out later that you can't do a bunch of things.
Now is the great place to do it, because you're just doing it on a piece of paper with pencil marks at this point. So the key to resolving that many-to- many, when you find one, is to think of it as two one-to-many relationships, and then you're going to add an additional table between these two tables that you're trying to relate. So, for example, so the key to resolving many-to-many relationships is to think of it as two one-to-many relationships, and then what you're going to do is add another table to be the child or the many part in these relationships.
So of course, here we've got invoices and products directly related to each other. Well, it's many-to-many, so how about if we add a third table? And let's call this invoice line items. Now we get rid of the relationship between invoices and products, and we can say, can one invoice have many different line items on it? Well sure, that can be the case. And can a product be represented by many different invoice line items? Yes, that's the case as well. So now we don't have to worry about a direct relationship between invoices and products, because now we've got two one- to-many relationships, one coming off of invoices - invoices being the parent, line items being the child - and another one coming off of products - product being the parent and line items being the child.
So why do we need a third table? Well, if I needed to just create a report of all the products ordered during a certain time period, like let's say the first quarter of any given year, which table would I search in? Would I search in products? I wouldn't actually, because there's only one record per product. It doesn't give me all the various products that were ordered. So would I search in invoices? Well no, I've only got one record per invoice, and it tells me very different items that appeared on that, but I can't necessarily isolate individual products on any given invoice. So what about if one product can be ordered at many different times? Where do we store that many different times? Do I create a field inside products for that? Do I create a field inside invoices? No, we don't do that.
You can only store one piece of information in any given field in a database. So this would require many different pieces of data in one field if didn't have a third table. So what we do here is we create a third table that can be the child to both products and invoices, and then we can have the many-to-many relationship between them, like we've discussed. So you see here in this sketch that I have this all cleaned up. We know that we need a fourth database in our entire database system. We've got customers, invoices, products, and now invoice line items. And also you see this is how we've drawn them all up inside the database.
So now we know that we need a fourth table in our database and we call this table anything we like, really. So let's call this one Invoice line item as we see here, and let's add it to our database. So back in our database, if we go to File > Manage > Database, we see that we've got three of the tables defined already. So let's go ahead and add the fourth one that we've determined we've needed through the data modeling process, and then just hit create. So now we've got all four tables defined inside of our database.
If you've got a really tiny project, it might not seem likely you need to sketch things out ahead of time, but I cannot emphasize enough how important it is to make these decisions on tables and relationships before you start working. Because the pitfall here could have been that we defined a bunch of fields and layouts and did a whole bunch of stuff before we even figured out we needed an invoice line item table, and now what's our overhead? We don't have to undo anything. We just simply add a table to the database. So after a little bit of what's called data modeling, we've determined what tables we need to build in FileMaker, and we've determined which tables have relationships with each other and what types of relationships they have.
So now we can move out of what we call the architecture stage and into FileMaker to define these table relationships accordingly. In the upcoming movies in this chapter, we're going to use the Relationship graph in FileMaker to establish and then maintain the table relationships in our FileMaker solution.
- Creating databases from templates
- Creating fields in spreadsheet format
- Creating tables and relationships
- Defining key fields
- Adding validation and auto-enter values to fields
- Managing records, including duplicating, locking, and deleting records
- Creating and managing layouts
- Formatting layout objects
- Finding and sorting data
- Creating calculation fields
- Building reports
- Printing and saving as PDF or Excel
- Writing and triggering scripts
- Using relationships throughout a database