Data Warehouse Library

Naming Convention

Arnoud — Sat, 24 Sep 2011 21:37:29 +0000

A system needs to find and address different objects efficiently and accurately while remaining easy to understand, develop and keep up.

You need a scheme that allows you to uniquely reference each object in a way that is both machine and human readable. The scheme describes each object within the business domain the system supports.

Come up with a naming convention that names objects for their content, and possibly their role, within the business domain. Avoid naming based on internal workings of the object, such as SLS_ORDR_VW, CRC32_CHKSUM, or intPersonWeight. Namespaces — database, schema, table, etc. — provide context to underlying objects, do not cram that context into an object’s name. Unit of measure is not an internal aspect of an object as it changes the meaning of the content the object represents.

Decide on a name syntax for objects; it describes how to form names. While different object types can have different name syntaxes, keep the number of syntaxes small, strive for three or less. You also choose an abbreviation scheme as necessary. Finally, and most important, apply your naming convention consistently everywhere.

Names are primarily a handle for people, as systems do not value the difference between OBJ1234 and CUST_NM. So, good names instantly convey meaning that otherwise is only available through tacit knowledge or locked away in a document somewhere.

A naming convention that changes names when implementation changes demands that everyone referring to it dances to its tune. It creates unnecessary coupling and makes the object name a “kitchen sink” of different meanings. This includes less obvious values like _DIM and _FACT suffixes as Jeff Kanel commented in the TDWI BI and DW Discussion group on LinkedIn. For example: Customer is hardly a fact, as Sales Order is hardly a dimension. Sales Order Status? Clearly a dimension.

If _KEY means surrogate key, that indicates content; if _KEY means primary key, that indicates function. A surrogate key has as its sole purpose to substitute a primary key, hence content follows function and the separation becomes difficult to see.

If namespaces do not give enough context to properly name the object, it might become necessary to add the role to the name, not the function. Imagine an employee table with an EMPLOYEE_KEY and you need to have a self-referencing foreign key to document the organizational structure. Name it MANAGER_EMPLOYEE_KEY to show its role, not EMPLOYEE_FKEY to show its function nor MANAGER_KEY where the manager role replaces the employee meaning.

As a last comment, consistency and good naming patterns allow logic that can make decisions based on the object name. Your solutions can become more flexible at the cost of a more disciplined naming convention.

Principle Trade-offs
Extend your understanding	<	Know your limits
Stay relevant	<	Build enduring
Do right	=	Share

Period

Arnoud — Thu, 15 Sep 2011 04:25:23 +0000

A business needs to track periods of time. This is a special case of the Range pattern, where the data values are date and time related.

A period can be constructed with a single boundary and an interval. As most actions with periods rely on testing its boundaries, this approach would need continuous calculation of the opposite boundary. Conversely, the interval can always be calculated from the two period boundaries and is used less often.

Range pattern

A business needs to bucket sets of consecutive, ordinal, data for aggregation purposes like age group, salary band, period, life cycle phase, and so on. This is different from grouping non-consecutive, nominal, data into buckets, such as hierarchies.

You need to store a complete definition of all buckets and the values they contain, while allowing for minimum and maximum values and gaps between buckets. Bucket boundaries can change regularly, while the precision and scale of boundaries changes at a slower rate.

Create a range with an inclusive lower boundary and an exclusive upper boundary, also known as [closed-open). Two boundaries allow you to handle extremities and gaps between ranges. System maximums for the extremities can cause overflow errors when used in calculations. Negative and positive infinities need special values; check if your chosen infinity values need three-valued logic; i.e. NULLs.

Modify each boundary name to show the inclusive or exclusive state, e.g. since/until for periods and from/up to for numbers. Boundaries hold real data values or the data's sorting values: e.g. January through December are ordinal if you use numbers 1 through 12 to sort them. Identify the correct data type, and its precision and scale, or grain.

Enforce uniqueness if overlap between ranges cannot be tolerated; this is not easy.

The exclusive upper boundary removes +/-1 calculations, except for ranges the size of a single data point; the grain. This allows data types to change to a finer grain — DECIMAL(6,2) becomes DECIMAL(8,4) — without having to update code or values, because the niggling +/-1 is obsolete ^[1].

The Range pattern cannot use the ANSI-SQL BETWEEN operator, which would be used to compare a single data point against a [closed-closed] range. You can write out the greater-than-or-equal-to and less-than logic and most RDBMS allow overloaded, deterministic functions as an alternative. Three-valued logic, if needed, would invalidate BETWEEN as well.

As a final consequence, joins between consecutive ranges are straight equi-joins without calculations, so both sides of the join can benefit from indexes. And you can query a continuous chain of ranges with a recursive CTE.^[2]

Principle Trade-offs
Extend your understanding	>	Know your limits
Stay relevant	<	Build enduring
Do right	=	Share

Footnotes (↑ returns to text)

If you like a paper copy better…↑
See also Common Table Expressions and Hierarchical Query ↑

Range

Arnoud — Sun, 04 Sep 2011 23:27:49 +0000

Enforce uniqueness if overlap between ranges cannot be tolerated; this is not easy.

Principle Trade-offs
Extend your understanding	>	Know your limits
Stay relevant	<	Build enduring
Do right	=	Share

Footnotes (↑ returns to text)

If you like a paper copy better…↑
See also Common Table Expressions and Hierarchical Query ↑