Data Modeling in JourneyApps

The JourneyApps platform offers a one stop shop to build an entire application, including

• User interface
• Application logic
• Data

Relational Data

The heart of any application is the data it contains. Stated another way, an application’s main use case is to interact with, store, manage, and control important data. Data crucial to a specific use case, business process, and all the way up to organizational data. In all the designs I’ve been doing over the years, the one section that appears in every one of them, is a ‘Data Model’ section. This details out all the data elements that are included in the application and referenced in other locations within the design.

Data design/modeling can be very simple to very complex, but at its heart it is really all the relational data included in the application. I use the term relational data as all contemporary data management systems are relational in nature where the tables implement a one-to-one, one-to-many, and many-to-many relationships.

Relational data design allows most/all data elements to only be stored once, where supporting data is stored multiple times as needed. A very simple example of this is a customer and the address. The customer may have multiple addresses associated with it. It would not do to restore the customer each time in order to capture each address. A simple design is to implement relational data, such as the following

• Customer table
  • Customer ID, Name, contact method, etc.
• Customer address
  • Customer ID – serves as a link to the customer table
  • Address information
  • Address type

The simple design above denotes a one-to-many relationship in the data, where the customer can have many addresses, but each address has only one customer. This is a very common data scenario in applications and data modeling.

Relational Data in JourneyApps

In addition to the user interface and application logic components included in Oxide – the JourneyApps development platform – complete data modeling functionality exists. The developer can create tables (models) and populate these with the appropriate elements. In addition to creating a model, JourneyApps allows the developer to easily implement the data relationships among tables by adding one of the following

• belongs-to
  • Denotes that this is the child in a one-to-many relationship
  • In our example above the customer address model would belong to the customer model
• has-many
  • Denotes that the target model contains one to many rows related to this object
  • Essentially the reverse of belongs to
  • To further our example, the customer ‘has-many’ customer addresses

These out of the box elements added to the models (tables) in the data model in JourneyApps implements the relationship at the data level, similar to foreign keys in other traditional database setups.

Summary

Overall, data design and modeling in JourneyApps is made very easy, allowing applications to be built to effectively manage data. Creation relationships, a foundational data design element, is made very easy and is implemented out of the box. Lastly, a good clean data design makes reporting easier as well.