Translating your problem into an application

Whenever your customers demand a new feature for their website, you need to think of how to put it in place. Most of the design process consists of understanding your client’s needs and being able to translate them into all the entities that conform to your web application.

Modeling applications into coding elements is a complex subject that involves lots of research. In this book, we will take a practical approach and make a visual and simplified architecture for our data.

In any case, you need to plan your extension properly, and for that, you need to translate your customer’s words into coding blocks.

Identifying your elements

In any problem you want to solve, you can identify different elements that form part of your problem:

• Entities: An entity is an element of your problem with which other elements can interact. For instance, it could be a company, a user, a task, or an invoice. Also, an entity implies data that needs to be stored in the database.
• Relationship: A relationship relates entities to one another with no action between them. For instance, a customer will have a company.

A real-world example

In this book, we will be solving a real-world problem. We need to develop a project management tool that allows us to do the following (these are also the requirements to solve the problem):

• Store customer data
• Generate invoices
• Create tasks for the project

Now, let’s begin by defining entities for this problem.

Defining your entities

Data entities are one of the most important parts of our project. They correspond to the data we need to store for our project. Data entities will be the tables in our database where we store our component information.

Some of these data entities are easy to recognize. For instance, if your project has users, then the user will correspond to a data entity.

Finding entities

In our project management tool project, we can see several entities at a glance:

Figure 1.1 – Entities we identify in our problem

In this figure, we can see the following entities:

• Customers: This represents our customers and will have enough information to identify them – Firstname, Lastname, Email, Company name, Company ID, Company Address, and Phone.
• Invoices: This involves the invoices we may send to our customers. Our invoicing system will be quite simple; it will just need the Customer data, Services provided, and Amount fields.
• Projects: Projects are entities in our problem as they represent the service our customer has requested. In our case, projects will just have a name, description, and deadline.
• Project category: We want to be able to differentiate several categories in our project, and an easy way of doing so is by adding categories to our projects. Our project categories will need just a name.
• Tasks: Tasks are the jobs we have to do for our project, so it makes sense to think of them as entities in our requirements. In our scenario, a task will have a name, a description, a state, and a deadline.

What actions can we find in our problem?

Not only do we need to define the entities that form our system, but we also need to identify the actions that can be applied to all of them. Actions are the tasks we can perform on our entities. In our extension, for instance, we can create new projects, or edit existing customers. So, Create and Edit are the actions of our component.

Some types of actions are common to all entities, and you should count on them every time:

• Create entity: This action allows us to add data to our database. Any time you create an entity, a row is added to its table in the database.
• Edit entity: This action allows us to modify the data we previously added to the database. When you edit an entity, no extra row is added to the database.
• Remove entity: This action removes data we previously added to the database. When you remove an entity, you remove at least one row from the database. Or move it to the trash first and remove it from the trash later.
• Show entity: This action allows you to show the data of your entity. No data is changed in your database when you use this action.

And, of course, every project will have its own needs and can have several actions not shown in this book. For our real-world project, we have identified the following actions for each of our entities:

• Customer: For our Customer entity, we can find the following actions:
  • Create customer
  • Edit customer
  • Archive customer
  • Remove customer
• Invoice: For the Invoice entity, we can define the following actions:
  • Create invoice
  • Edit invoice
  • Send invoice

  Please be aware that we have omitted the removed action from invoices. Most countries do not allow you to remove invoices, so it makes sense not to consider this action in our project. You need to find a solution for changing or deleting customer data. An invoice should always contain the original data.

• Project: For the Projects entity, we define the following actions:
  • Create project
  • Edit project
  • Archive project
  • Remove project
• Project category: For the Project category entity, these are the actions we can add:
  • Create a project category
  • Edit project category
  • Remove project category
• Task: For the Task entity, we find these actions:
  • Create task
  • Edit task
  • Archive task
  • Remove task

Defining relationships

Our entities are not isolated; they need to be connected to have some functionality. For instance, a task must belong to a project, and a customer might have several invoices.

It is important to define the relationships between all our entities to be able to devise the database tables.

In our example, we can find the following relationships:

• Customer:
  • Our customers can be in a project
  • Our customers might have multiple invoices (hopefully tons of them!)
• Invoice:
  • For any invoice, we must have just one customer
  • Any invoice is related to a service provided, so it must have at least one project, but it might have more
• Project:
  • Our projects will only be in one category
  • We will only have one customer per project
  • Any project is composed of multiple tasks
• Task:
  • Every task will be assigned just to one project

These relationships are illustrated in the following figure:

Figure 1.2 – Graphical representation of our relationships

The arrows in the figure show the entities’ relationships. When we create our database tables in the following sections, these arrows will represent a field that relates to two tables. For instance, in the Invoices table, we will have an id_customer field that shows the relationship between the customer and the invoice.

Once we have translated our problem into entities and their relationships, we can define the database structure for our component.