Let's talk 339.200.9090hello@delewis.com

Building Sections in Symphony CMS Using Normalization

Structuring content in Symphony CMS can seem daunting at first, but that is the trade-off for the flexibility that we gain. I'd like to introduce you to the method that I've used which has helped me countless times with both simple and complex projects. This concept isn't new among veteran users and I feel it is a great approach when building with Symphony CMS.

Understanding and Visualizing Sections

Building Sections in Symphony CMS Using NormalizationSections in Symphony CMS are one of the core features at the heart of the system. The trick to understanding sections is to visualize them as a database table. Good practices when building the structure of a database can also be applied to building sections in Symphony. Just like a table is made up of columns, a section is made up of fields in Symphony. We can take it a further step in that you can have different field types in Symphony just like you can in a database table's column.

Data is organized into sections and sections are made up of fields. You might be asking yourself why Symphony doesn’t make it easier by defining the sections and fields. This is where Symphony CMS stands out and it is a departure from many popular content management systems. The benefit here is flexibility. Symphony CMS does not define sections and fields because it makes no assumptions about the data that it will manage.

Think of Symphony as a CMS framework.

Applying Database Design Best Practices in Symphony

Here are a couple guidelines that we can borrow from best practices when creating databases that you should be using when you create sections in Symphony.

  1. Planning
  2. Normalization

Planning Your Website

Every successful Symphony CMS project starts with a complete understanding of what is required by the client. Skipping this step often means you’ll spend more time later on patching what you had not planned for.

It's important to emphasize the need to understand the data, what it is, and how the different pieces connect to one another. Points to consider include:

  • What data will be gathered by website visitors?
  • What data will be entered by website administrators/authors?
  • What are the relationships between the different pieces of data?

Understanding the different sources data will be collected from helps you understand the workflow. It’s important to keep the workflow in mind so that your sections do not become overly complicated for the user to input data.

Determining Sections

It is not necessary to understand the detailed theory behind normalization, but for those interested we are going to approach the design of our sections with third normal form (3NF). Each normal form has rules and these rules build upon the previous normal form. To get to third normal form, we must also implement first and second normal forms.

Imagine we have a client who would like to sell products online. After talking with the client it is clear that we need to accomplish a few goals:

  • Provided an interface for the client to add products
  • Record orders so that the client knows what to ship

First Normal Form (1NF)

  • Each field must only contain a single piece of data
  • Must not contain any repeating fields

The best way to show you how to follow the first rule is by showing you what not to do. Imagine you have a section called Orders with the following fields: orderid, date, total, customer, address, city, state, zip-code, product1, quantity1, product2, and quantity2. The problem we have here is that an order can have more than one product related to it. What happens if a customer places an order with three products?

product1 and product2 represent a subset of data. Following the first rule of the first normal form, we need to create a separate section called Ordered Products. This section might look like: productid, name, description, price, and quantity.

At this point, it’s necessary to introduce two definitions you may or may not be familiar with.

  • Primary key is a uniquely identifying field or combination of field that identifies a single entry.
  • Foreign key is a field that identifies a specific entry in another section.

If you are following along, we now have two sections. How do we relate the sections appropriately to one another? Symphony CMS’s Select Box Link field allows us to make relationships between sections. Using the Select Box Link field we can add an additional field to the Ordered Products section which will act as a foreign key: orderid, productid, name, description, price, and quantity.

In the Select Box Link field’s configuration under options, it’s important that we choose the primary key of the Orders section so that each entry can be uniquely identified. In our case, the primary key of the Orders section is orderid.

Second Normal Form (2NF)

  • Meet First Normal Form
  • All non-primary key fields are dependent on primary key.

The Ordered Products section does not meet second normal form. The primary key for the Ordered Products section is a combination of two fields, orderID and productid. Neither field alone can uniquely identify an entry in the section.

While name, description and price are dependent upon productid, they are not dependent upon orderid. This means these fields are not fully dependent upon the primary key and therefore must be removed to their own section.

The new Products section should look something like this: productid, name, description, and price. In this section, productid acts as both the primary key and foreign key (to Ordered Products). To create the link between the Ordered Products section and the Products section, the productid field in the Order Products section must be replaced with a Select Box Link field using productid of Products under options.

Third Normal Form (3NF)

  • Meet Second Normal Form
  • No non-primary key fields are dependent on another non-primary key field

The Orders section breaks the third normal form because customer is directly related to orderid but address, city, state, and zip-code are all directly related to customer. The primary key in the Order section is orderid and the additional customer details are not directly related to it.

To bring our section design into third normal form we must create an additional section for customers. The new Customers section will contain customerid, name, address, city, state, and zip-code.It’s possible that two people of the same name could live at the same address so it’s a good idea here to use an arbitrary customerid field to act as both the primary key and foreign key (to Orders).

The Orders section will need to have the customer field replaced with a Select Box Link field using customerid of Customers under options.

Benefits and Pitfalls

The concepts of database normalization can be applied to the design of sections in Symphony CMS to help design complex websites. Like anything, there are pros and cons to this approach and knowing them will help you determine if this is the right approach for your next project.

Normalization Benefits

There are several benefits that come from normalization. Here are the ones that I feel are most important.

  • Flexibility
  • Data integrity
  • Simpler backend forms

Flexibility has to be the single biggest benefit of normalization. In our case above, it's the flexibility to add unlimited products to an order. However, imagine the client turned around and told you that they wanted to be able to add prospective customers who had not yet ordered. The original design didn't allow for such a change. Normalized to the third normal form, the client can easily add a customer to the Customers section without any changes.

Normalization also provides better data integrity. One of the goals of normalization is to eliminate redundant data. That way when a piece of data needs to be changed, it only needs to be changed in one place. Referring back to our example above, it would be a tedious task to change a product name if it was part of the Ordered Products section. It's likely that mistakes will occur. However, in the second normal form we removed item details to their own section which makes it so product information needs to be only changed in one place.

Lastly, normalization in Symphony CMS leads to simpler forms in the backend. The client is no longer faced with an onslaught of fields to fill out, but rather a user-friendly interface.

Normalization Pitfalls

Normalizing sections and Symphony CMS is not always the correct approach. Normalizing comes at a cost.

  • Additional data sources and events
  • Awkward user workflow

Creating more sections and relationships in Symphony CMS can increase overhead to output XML on the frontend. Most of the time this isn't a problem, but it might become an issue if you have limited server resources. It also creates the need to have multiple data sources. While I don't see this as a downside directly related to the design, it definitely increases time to develop.

Most importantly, and perhaps the biggest pitfall with normalization, it can create some unfriendly user experiences. Unlike a database’s design, the design of sections in Symphony also represent the form layout in the admin. The separation of content in some situations can actually be a hindrance to data entry. It's important to consider a user's workflow and pinpoint areas of concern. It's usually a matter of changing field type

Posted on August 01, 2012 by Mark Lewis on and filed under Symphony CMS


Make geek like comment

© 2010–2017 All rights reserved. delewis