Start learning with our library of video tutorials taught by experts. Get started
Viewers: in countries Watching now:
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.
Like many other databases, a FileMaker Pro database is presented to the developer as a collection of tables, as a collection of tables each containing a number of fields. If you have ever worked with any other database environments, you may be accustomed to terms like columns instead of fields. Either term is meaningful and acceptable here, but the FileMaker Pro interface and documentation use the term field; therefore, in this video, we'll follow that convention. A FileMaker Pro file, as we see here onscreen, can hold in almost limitless number of tables, each with an effectively limitless number of fields defined.
In this chapter, we're going to focus on fields and field types available within FileMaker Pro, and then how you create those fields. A field in FileMaker Pro may be viewed as a slot that can hold information specific to a single database record; for example, you see here in Products, this slot would contain information on the category for this particular product, number 47. The value that's stored in a field could be thought of as an attribute of the entity that's represented by the table, or in this case an attribute of the Products Table. For example, a database table in which a record represents a customer, like we have here, you might want fields for things like First Name, Last Name and maybe even a field to store a photo or something like that. And just like with anything else that we've discussed, you're going to want to spend some time looking at the data that you want to store in making preliminary lists of the possible attributes.
You can see that that's kind of a mantra here. First, you have to stop and sketch things out before you start defining them inside your database. It's an important process, as with anything that you construct. Every database is different, and it's your specific user's needs that will dictate what fields you need in your database. So, for example, if we open up the File > Manage > Database and choose the Products Table, you'll see that it already has fields defined from when we imported this table from another FileMaker database. So here we don't have to define any fields, but we can use this as an example of some of the types of attributes that we can design towards an entity of products.
So you see, for example, we've got Category, which is the category of the products, the Cost, Keywords, Location, some Notes, a Picture. We'll get into all these different field types that you see here in the middle in upcoming movies. But for now, we're going to concentrate on what an attribute is, and how it can describe the entity that's in the table. So a brief review of these fields shows that we've got a lot of different fields that describe a product. Also, each field is going to represent a value that will be different for each product stored in a Products Table, not necessarily different in every record, but if every single record in the entire database has the same value, it wouldn't necessarily be a standard field.
So we're looking for attributes that might change from record to record. Therefore, we want to make sure that we have a place to store each value independent from all the other values, so one for every product that's going to be stored in the database. Also, you should be aware that that fields don't always require a value, although we'll be talking about that in a later movie how we can make it so that users must enter values in the fields, but they don't necessarily need to have a value in them. Like, for example, every product doesn't have to have a cost, but maybe there is something that you need to have in every record. But just because you define a field, doesn't mean it must require a value.
So when you're doing your evaluation of what kind of fields you might need in your table, keep in mind that even if there's only a few records in the database that would need a value that describes it, or a field defined, you're still going to want to create that field. By looking at Products as an example, let's try to determine what fields we might want in our Customers Table. You see right now we don't have any fields defined in the Customers table. And remember, we need to determine which attributes of a customer may change from customer to customer, yet at the same time we want to make sure that we are only including fields that are going to be meaningful to our users.
So it's important that you bring your users of the database into this whole discussion to make sure that their needs are reflected in the final product. So let's say that after having appropriate discussions with all of our users and stakeholders, we determine the following fields will be needed in our Customer table. We've got things like Customer name, Street address, City, State, Zip and notice that we were breaking up our fields into the smallest pieces of data possible. Instead of having one big address field, we're breaking it up into Street address, City, State, and Zip. We'll see as we go on through this title how that's going to important. We've got different types of things, Tax rates, Company Web sites.
For example, a Company Web site, not every customer may have one, but you still want to define a field for those that do actually have one. And then we have discussions with our users and determine that these are going to be all the attributes that describe a single invoice within our system. So you see a lot of these have to do with the number values in an invoice, but these specifically define in Invoice. You'll see we've got things like the Date or totals and Shipping costs and Terms, and all that type of thing. To review, what we've actually done here is come up with a list of attributes that are specific, either to a customer or an invoice.
Notice, for example, that a Company name doesn't describe an invoice, but an Invoice date does. So in each case, we've asked what information describes the entity reflected by our tables, and then what information is specific only to that table. That's the important part. What information only describes an invoice? What information only describes a customer? We'll talk later in the title about how it's important that you can share this information between tables via the relationships that you have set up, but when you're defining a list of fields, you've to make sure that the fields are only specific to that table.
FileMaker databases allow developers to create a field to store information that describes values that are stored in tables. When you make decisions on what fields you need, make sure that you're getting your users input and then break down the data into the smallest parts before proceeding.
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.