Designing your data models

It is important that you identify the data models your app will need prior to writing any code. Consider your data models the foundation of your app as a whole. We don't have sufficient space in this chapter to cover all the various complexities a large data model design needs to address. Instead, we'll discuss some basic ideas and also explain our mindset while going through the design for Tasker.

Simply, a data model describes the kind of data your app will store as well as the relationships between the data elements. Having this in place makes it easy to understand the system and makes it easier to code the app.

Let's go through the data models for our app. First up, we have the PERSON model:

The preceding diagram tells us quite a bit about the data we're storing:

• The model stores information about people, including their name and administrator
• The model indicates the data types for the individual data elements
• The model also indicates the various actions that can be performed on the data

The preceding diagram doesn't tell us much about how the data elements relate to each other (or to other models). You can probably guess that an administrator ID points at another person's ID; however, it is always better to make this explicit. We could do this on the same diagram, or use another diagram to make this clear:

As you can tell, the PERSON data model forms a hierarchy of people who manage other people. We can also reverse this relationship to determine who manages any individual in the database. So we can ask "who is Bob's manager?" as well as "who does Sandy manage?" This is key for our permissions model (where individuals should only see tasks they own or are assigned to, and individuals can only assign tasks to those they manage).

Let's look at another data model: the TASK model. This model stores the data related to each task; information such as the title, the description, who created the task and who is assigned to it, and so on, as shown in the following diagram:

The preceding diagram should be reasonably self-explanatory; all the fields you would expect for simple task management are here. The OWNER and ASSIGNED_TO fields point to the PERSON records so we can track ownership and assignments.

Note

If we were building a fully extensible system, it's probable that one would actually create an additional model to store status types which would allow you to handle additional statuses instead of the four defined earlier.

The following diagram shows how a task is owned and assigned:

This is technically sufficient for simple task management, but it would be nice if there were a mechanism to track communication between the owner and assignee. For this feature, let's define a TASK_COMMENTS model:

This model allows us to store any number of comments per task. Later on, we'll use this model to enable the addition of push notifications to our mobile app.

The following diagram should make the relationship between tasks and comments easier to see:

As you can see in the preceding diagram, it's possible to have more than one comment per task.

Typically relationships are expressed in a data model diagram by connecting lines between the two models (and indicating if the relationship is one-to-one, one-to-many, many-to-many, and so on). In our case, compressing the entire diagram to fit on a page is hard to read, so we've left these connecting lines out in the preceding diagrams. The following is an example of what this looks like as a whole:

When creating data models, the following concepts might be useful:

• Models represent physical objects; for example, our PERSON model represents a real person. In the database, a model is often a table of data.
• Data elements represent attributes or properties of the model. A person has a name and an administrator, which are described in the model as individual fields. In the database, a data element is often a column within a table.
• Relationships can be one-to-one, one-to-many, and many-to-many. A person can have only one administrator, but an administrator can have many subordinates (one-to-many). On the other hand, a person has only one username (one-to-one). Furthermore, relationships can be optional or required; for example, a task must be owned by a person, but might not be assigned to another individual.

This is, of course, extremely condensed. If you want to learn more about designing data models, see the Designing the data models section in Appendix, Useful Resources.