Video: Determining which tables you will need

There are a couple of different methods that you could use to create a FileMaker Pro Database, first of which would be to use one of the templates or starter solutions that we discussed in the previous movie, that are prebuilt for you. In that way, you can just go ahead and make some modifications, add some data, and you're ready to roll. But another option, which is actually a lot more popular, is to create a database from scratch, or to build all of the components from the ground up. In order to build the database from scratch, you need to first make some decisions about what type of information, or data, is going to be stored within these databases.

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.

Determining which tables you will need

There are a couple of different methods that you could use to create aFileMaker Pro Database,first of which would be to use one of the templates or starter solutions that wediscussed in the previous movie, that are prebuilt for you.In that way, you can just go ahead and make some modifications, add some data,and you're ready to roll.But another option, which is actually a lot more popular, is to create adatabase from scratch, or to build all of the components from the ground up.In order to build the database from scratch, you need to first make somedecisions about what type of information, or data, is going to be storedwithin these databases.

So the first thing that you're going to have to determine is what types oftables you're going to have in your database.So let's back up for a second. What's a Table?A Table is a container within your database that stores data.If you remember, a database is like a big bucket of information that canstore all sorts of data.That's one of its key role is to store the data.But you can have different types of data within one database.So in that case, if you have multiple different types of data, each one of themneeds to have its own little mini bucket within the database.

These smaller storage areas are called Tables.A database can have multiple tables, each representing a different Entity.Now an Entity, it's kind of a database term.It's useful here when we we're discussing Tables.An Entity describes a single person, place, or thing, or basically anything forwhich we can store data, anything that we can describe, and anything that wecan store data for.So, for example, people or customers would be an Entity.That's certainly something that we could store inside of a database.

Now it's important that we remember that a database can consist of one or more tables.The database that we're going to be creating in this title, we're going to havemany different tables.So a database can have many different tables, and a table can havemany different records.A table can consist of records.Each record is made up of a number of fields.But focusing just on the tables, they are going to represent the groups ofinformation that we're going to store within the database system.For example, let's say you're going to create a database that tracks theenrollment of students in classes.

You can then create separate tables that contain details about teachers, andclasses, or even classrooms.They're all different types of data, but they're unique and discrete from each other.So they would deserve their own little mini storage area, or table within the database.When you have multiple tables in the database, those tables were going to haverelations to each other.We'll talk about those in an upcoming chapter, but in that case, this is what wecall a relational database.But a FileMaker Pro database, like any other database, is presented to thedatabase developer as a collection of these tables that we've been discussing.

But how do we determine which tables we're going to need?A very important note here is that when you sit down at a computer and you openup FileMaker Pro to start a new database, what you're actually doing there isconstructing something.Much like any other construction project that you embark on, like let's say ahome construction project,your database will proceed more smoothly if you first begin with some type of a plan.The very first part of any plan, when you're developing a database, is todetermine what types of information you're going to be storing inside of that database.

So the first thing that you really want to do, even before you open upFileMaker Pro, is to come up with a plan and what type of data you're going tobe managing your system,and therefore, what tables you're going to need.So, for example, if it's a very complex system, then it's going to have a lotmore parameters to it.You're going to have a very complex plan.But even if it's a very simple project, you still want to take a coupleof minutes ahead of time, and determine what kind of data you're going to be storing.A lot of people think that they don't have a very complex solution that they'retrying to build in a database, and they can skip the planning stage, but it'sjust as important as as it would be with something very complex.

So, first take a few minutes and look at the data.Literally sketch out what type of information you plan to manage in your database.For example, for this movie, and for the entire rest of the title, we're going tohave a basic database system where we need Customers, Invoices, and Products.It's really a standard invoicing system, where Customers are ordering Productsand creating invoice forms as a result.So in example like this one, we can see that we've got different types of data.So I've mentioned a couple of them already.First of all, as we're sitting down and sketching this,we realize that we're going to have to have customers stored inside of this database,so we jot that down.

We know that we're going to have Orders, or Invoices we'll call them in this case,so we jot down Invoices.And then finally we notice that we're going to have to have Products, becausethe Customers have got to be ordering something,so it seems to us that we can jot down Products as well in our list.So in an example like this one, we can see what types of data we're going to be storing.It's important for us to pick discrete and unique buckets of information,because after all, that's ultimately going to tell us what tables we need todefine in our system.So here we see we've determined that we're going to have different groups ofinformation in our one database: Customers, Invoices and Products.

What we've really done is created a list that tells us what tables we need tostore inside of our database.Later, we'll look at how these tables are going to relate to each other,but for now, we're going to use this table list we created to start workingwith our new database.So by doing this exercise, we've determine that we need a Customer table, and weneed an Invoice table and a Products table, because these are the discretebuckets of data that make up the database that we're trying to build.

Q: In the Chapter 16 tutorial, “Using Text Functions,” the instructor discusses how to calculate the First Name and Last Name from the Full Name. However, the method does not account for names ending with “Jr.” or “Sr.” or “III,” etc. How can I account for added suffixes in names?

A: For cases like this, you can create a third "Suffix" field. Then change the FullName calculation to:

NameFirst&" "&NameLast&" "&Suffix

This way, nothing will appear if the Suffix has no value, but if it does have a value the suffix will appear.

Q: What information is actually on the “Invoice Line Item” table in the examples, and how does it actually connect to the tables that it comes from?

A: The information in each line item is native to the "Invoice Line Item" table. The fields are defined in that table and each record represents "A Product appearing on an Invoice."
Each time a product is used on an invoice, a record in the line item table is created. Many of the fields, for example "Quantity," are native to that table because those values only exists when a Product is used in an Invoice, and not as attributes of a Product itself.

Sorry, there are no matches for your search "" —to search again, type in another word or phrase and click search.

Learn by watching, listening, and doing, Exercise files are the same files the author uses in the course, so you can download them and follow along Premium memberships include access to all exercise files in the library.

Already a member ?

Learn by watching, listening, and doing! Exercise files are the same files the author uses in the course, so you can download them and follow along. Exercise files are available with all Premium memberships.
Learn more

Upgrade to our Annual Premium Membership today and get even more value from your lynda.com subscription:

“In a way, I feel like you are rooting for me. Like you are really invested in my experience, and want me to get as much out of these courses as possible this is the best place to start on your journey to learning new material.”— Nadine H.

Thanks for signing up.

We’ll send you a confirmation email shortly.

Sign up and receive emails about lynda.com and our online training library:

new course releases

newsletter

general communications

special notices

Here’s our privacy policy with more details about how we handle your information.

Keep up with news, tips, and latest courses with emails from lynda.com.

Sign up and receive emails about lynda.com and our online training library:

new course releases

newsletter

general communications

special notices

Here’s our privacy policy with more details about how we handle your information.