Semantic Layer

Organizations typically set naming conventions for their databases. For example: all fields will be prefaced with the same three letter database name abbreviation, all key fields will have a suffix like FK or PK, or each field name will include its data type (like int, varchar or datetime). To keep field names short, abbreviations are common. Unfortunately, the end results can be confusing for users trying to understand their data.

Business intelligence solutions often use a semantic layer to assign relevant, familiar names to database tables and fields. For example, when an end user views a report that displays fields using a semantic layer, they will see Patient_first_enrolled_date instead of CRM-acct-frst-enrl-datetime. Similarly, an inventory-keeping software system would list items by product name, product category and other details, rather than just using the SKU number of the item. Instead of “Item#1049840928,” they would see “Rubbermaid Heavy Duty Rake.”

Going further, a customer browsing an online inventory system may need additional semantic layers added on in order for them to more fully understand what they are looking for. Instead of just “Rubbermaid Heavy Duty Rake,” they may see “Rubbermaid 40 in. Heavy Duty Rake for Professionals.” In this way, a shorthand term can be translated into something more descriptive and useful to the intended end user.

BI applications must have robust semantic layer capabilities that do not add to the latency for processing and manipulating data. While power users may have a good understanding of underlying data models and naming conventions, a semantic layer is an important component of self-service analytics. End users must be able to know what data they are looking at on a report or dashboard in order to answer business questions.