 Learning about data organization In this video, you'll learn common database terms and begin to organize your data. There are four terms that are important to understand when planning your custom app. Table, field, record, and relationship. A table stores data about a given subject, like clients or visits. A table is made up of fields that will store attributes about a subject. For example, first name, last name, and email are common fields in a client table. A record in a table stores actual data about a given subject. For example, the first record in a client table might store information about a client like John Smith. A relationship connects two tables, allowing the tables to reference data from each other. For example, a visit table could show the name and email address of the related client from the client table. Each of these terms lines up well with spreadsheet terms. A spreadsheet can be considered a table. The columns are fields, and the rows are records. Tracking information manually in one or two spreadsheets can be made much simpler using tables. In the case of your clinic, you have your client and visit information entered into one spreadsheet. Every time John Smith visits your clinic, you create a new row and have to reenter his information, like first name, last name, and email. How do you want to send him a reminder email for an upcoming visit? You'd have to search your spreadsheet and locate the row that belongs to John Smith. There are three rows that have a record for John Smith, one for each visit. Each record has a different email address. This could be problematic, as you don't know which email to use in sending the appointment reminder. Let's take a look at this case if you were using tables. John Smith's client information would all reside in the client table, so if you were to change his email address, you would only need to update a single record. Organizing your data into tables eliminates a lot of duplicate data entry. In order to identify the necessary tables for your custom app, begin by reviewing your app's goal. Design a mobile app, four therapists, two record services delivered to clients during their visit. Look for any nouns in the statement and determine whether or not your clinic will store data about that noun. In this case, there are five nouns. You are building a mobile app, but it's not something you'll track data about. This term can be ignored. In a more complex app, you could track therapist information. In this case, assume that you only have a few therapists and it doesn't warrant storing information about them in your app. Services describe the one or more things that happen during a visit. Client information will allow you to track anyone who visits the clinic. And visits are central to your custom app. Providing information about who visited and when. For your clinic, you'll focus on client, visit, and service tables. Another way to figure out tables for your custom app is to review any spreadsheets used to currently manage your data. This is also a great way to start figuring out what fields you'll need to track in your custom app. Your spreadsheet may not have all the information you plan on tracking. Think about other fields that you may need to add to your custom app, like a photo of your client. In the time of a client's visit, and the duration of the services provided. In this video, you learned key data organization terms. And how to figure out the tables you'll need in your custom app. In the next video, you'll learn how to relate multiple tables and create an entity relationship diagram, otherwise known as an ERD, which is the foundation for building a custom app.