 designing your data model. In this video you'll create the foundation for your clinic's custom app by learning about relationships. You'll also create an entity relationship diagram or an ERD. While planning your custom app you created the following goal statement design a mobile app for therapists to record services delivered to clients during their visit and based on that statement and the needs of your clinic you identified three tables of data client visit and service. The next step is to identify how these tables relate to one another. Start by looking at the client and visit tables. One client can have multiple visits over time but each visit belongs to only one client. This is called a one-to-many relationship. When creating your data model use a crow's foot to represent a one-to-many relationship. One client, many visits. In order to relate these two tables each visit needs to know which client it belongs to but using something like a name or a combination of fields can be problematic. What happens if there are two Jane Smith's in the client table? It becomes unclear which Jane Smith went in for the recorded visit or what of Jane Smith changes her name to Jane Doe. The visits would no longer match up since the visit record still shows Jane Smith as the client name and a misspelling in either table would also impact the matches instead using a unique value that always exists and never changes solves the problem. When a unique value is used it's called a primary key. This means that the client table will only have one record that identifies as client ID 101 who in this case is Jane Smith. The client ID will be unique and only assigned to Jane Smith. If that value was referenced in another table that's called a foreign key. Client ID 101 in the visit table is foreign because it did not originate from the visit table it was unique to the client table. You'll see that client ID 101 repeats in the visit table to track every instance the client visited the clinic. As a best practice it's a good idea to have a primary key in every table even if you don't expect to use the primary key in a relationship. This prepares your tables for potential relationships as your custom app grows. It can also be a great way to reference any specific record during development and when troubleshooting. Another best practice to help you identify when a foreign key is needed is when you see a crow's foot in your table relationship. This is a good indicator that you'll use a foreign key in that table. Similar logic can be applied to services. A service can be defined as the actions the therapists take during a specific visit. While services are tied to a client a client must come into the clinic for a visit in order to get the services. One visit can have multiple services but each service belongs to one visit. Just like client to visit the one side uses a primary key the visit and services table are related by the visit ID a unique identifier for each visit. A client can have multiple visits and a visit can have multiple services. By drawing out your data model using tables and branching lines you created an entity relationship diagram or an ERD. An ERD will become the foundation for building your custom app in FileMaker Pro. While writing out a plan helps describe the business problem drawing out an ERD helps to explain what tables are necessary and how those tables will relate to one another. In this video you learned about the one to many relationships between clients and visits and visits and services. You also learned to create primary keys and foreign keys in order to relate your data. In the next video you'll launch FileMaker Pro and use your ERD to begin creating your app's tables fields and relationships.