Best practices in naming entities and fields
May 26, 2014
The DBA has users. The marketing team has leads. The sales team has customers. The product team has members. Is a user a member? Is a customer a user? These are typical questions that can result from combining disparate data sources into a consolidated data warehouse. Renaming each base table and column name for consistency can be resource-intensive and often more trouble than it’s worth, as it can also involve updating every reference made to that structure (e.g., ETL jobs or existing reports and scripts). Looker provides an easy way to redefine entity names and maintain consistency across your data warehouse for front-end users.
The power of Looker is in data discovery: the ability for a business user or analyst to start with a blank canvas and ask any question of the data. With a library of available attributes and measures, it’s important for the user to know what each object is and what type of data to expect—just by seeing the name of the dimension or measure. This can be facilitated by maintaining a consistent naming convention across the data model, one that applies to all views and fields.
A few tips
Data types. The user should be able to identify the data type of each attribute before viewing the underlying data. Avoid ambiguous names and be explicit in communicating the data type. For example, if a field holds a monetary value, the name of the field should contain ‘amount’ (e.g., billed_amount).
Entities. Maintain entity names across your model. If ‘user,’ ‘customer,’ and ‘member’ all refer to the same entity, choose one and use it across the model. For example, member_name, member_address, and member_billed_amount.
Naming patterns. Be consistent in naming patterns for your attributes and measures. For example, if you have named a Boolean field ‘is_paid,’ all Boolean fields should maintain the same pattern (e.g., ‘is_cancelled,’ or ‘is_returned’).
Formatting. Formatting should be constant across similar data types. For example, if an attribute named ‘billed_amount’ represents a monetary value, the value should be formatted to display a currency symbol. For consistency, the same formatting should be applied to all ‘amount’ (e.g., paid_amount, sales_tax_amount) fields.
Some of these tips may seem trivial, but they are key to building a model that will be used accurately and easily by all users, regardless of their familiarity with the underlying data structures. In Looker, the names and formats of the underlying data can be easily redefined to create a concise and consistent data model.
Look how easy it is
When generating a new model, Looker automatically creates a view based on the name of the underlying base table. This name may not always be intuitive to the front-end user. If a table named ‘address’ stores address information for all members, naming the view ‘member_address’ would avoid any confusion on the user’s part as to who the address belongs to. The example below shows how to display a table named ‘address’ as ‘Member Address’ in the UI: