Having explored information system record concepts in Parts 2, 3, and 4 of this series, the objective of this article is to examine one particular type of field — the record business identifier. Its purpose is to uniquely identify an instance of a record. Users of an information system are expected to have knowledge of, or access to, this value. The value is used to start down, or stay on, the ‘happy path’ of any business process that deals with the specific record instance it identifies.
NOTE: This article is Part 5 of Information System Data Fundamentals For Business Analysts. See Part 1 – Series Introduction for links to other articles in the series, plus definitions of the terms Information System, Record, and Field within the context of this series.
NOTE: The concept of record business identifier is like, but not exactly the same, as the concept primary key. Every table in a relational database is expected to have a primary key. A primary key can, however, involve combining more than one column to achieve uniqueness. Also, every table in a relational database is expected to have a primary key, but only some tables represent hold data that is the starting point of a business process.
IDs and Numbers
Record business identifiers are all around us. Our wallets and mobile phones are filled with them — values that have been exposed by the organizations we deal with. If you see a field name that ends in “ID” or “Number” there’s a good chance that its values are intended to identify a specific instance either of that record, or some instance somewhere. The assumption is that we will have that value available when interacting with the organization that produced that value. These values are embossed on our credit and debit cards. They are printed on our membership cards, our discount cards, our driver’s license. Every phone number, email address, and app-specific contact we record is a record business identifier value. We use these values when we want to ‘reach’ a specific person or interact with the issuing organization.
From the perspective of an information system, there is no doubt that given sufficient fields, such as name, address, phone, etc., we can uniquely identify record instances representing a person or organization. Similarly, there are fields for a product, a sale, or a location that, taken in combination, will lead us to the instance we are seeking. The point of a record business identifier is that it’s a ‘one stop shop’ — a single value that, if known, will get a user to the specific instance they are looking for at a given point in time.
Multi-fact Identifiers
The simplest form of a record business identifier is one based on a numeric sequence (e.g. the last assigned number plus one). This form is often used where values only need to be unique within the organization, and there is no need for the identifier to be meaningful in any way. Records such as PURCHASE ORDER, STORE, and ASSET fall into this category for many organizations.
An example of an identifier that contains at least one fact is CREDIT CARD Number. It appears to cardholders to be just a number. But because that number needs to be unique across all organizations that issue similar cards, the first six digits of each value identifies the issuing organization. The digits that follow those six can be generated any way a given organization chooses. Typically, six or more of these digits are populated based on the ‘last assigned value plus one’ algorithm.
The field Stock Keeping Unit Number (SKU) is an example of an identifier that utilizes multiple facts to make up unique values of the record INVENTORY ITEM. A retail clothing business might create its unique SKUs based on the combination of an item’s brand, clothing type, style, size and color. For example, the SKU Number ‘LEV-JN-ST-34-BL’ representing the inventory item Levi jeans, straight leg, waist size 34 in blue.
When a record business identifier contains one or more facts, those facts should also be defined as separate fields in the same or some other record. This eliminates the need for business users to ‘pick apart’ an identifier to find a given fact. E.g. Obtain a list of all Jeans with a 34-inch waist.
NOTE: Any fact included in a record business identifier should ideally involve values that will not change over time. Having ‘exposed’ the identifier to the business, dealing with communicating a change is not productive for anyone. If you have ever changed your phone number or email address, and needed to notify family and friends, you will have some appreciation of the resulting effort and inconvenience.
Optimizing User Experience Accessing a Record Instance
Keeping the following four things in mind will help optimize the user experience when a business process needs to involve a specific record instance:
- Maximise identifier exposure
- Minimize identifier manual entry
- Avoid finding a wrong instance
- Offer backup ‘find’ options
Maximize identifier exposure — When a record includes a record business identifier field, that value should be ‘exposed’ where it will best serve the business processes that deal with single instances. An EMPLOYEE Number can be displayed on the employee ID badge and printed on employee payslips. An ASSET Id can be printed on a label attached to each physical asset. A retail product that has a PRODUCT Barcode value registered by the manufacturer should have that barcode plus its numeric characters printed on each instance of that product.
Minimize identifier manual entry — More and more these days, information systems are being ‘front-ended’ with data capture technology, web portals, and apps. Input devices can read a barcode, a magnetic stripe, an embedded chip, or a value broadcast via radio frequency (an RFID). The trend is also towards self-serve, where customers use web portals or apps to connect to an information system. A USER Logon Id is an example of a record business identifier — one that requires minimum data entry effort, thanks to web browsers or mobile devices offering to remember the logon ID value for a given site or app.
Avoid finding a wrong instance — In situations where technology is not able to provide the value needed and the user needs to resort to manually entering the value to access a specific instance, one of the most common data entry errors is transposing one or more digits. This can result in a valid record instance being found, but not the one wanted. E.g. wanting the instance with identifier value 12345 but accidentally entering the value 12354. A technique for avoiding this type of error is the inclusion of a check-digit when generating the identifier value. Credit card numbers are an example of check-digit inclusion to avoid wrong record instances being found.
Offer backup ‘find’ options — For every happy path there are any number of alternate or exception paths. At least one of these paths should involve a user interface capability that supports the user finding the desired record instance with the help of a ‘filtered’ list of records, displaying sufficient record fields that provide enough information to spot the desired instance.
Fields Included in a Record Business Identifier
An essential part of capturing business needs for a record is identifying one or more fields within that record that together constitute its record business identifier. If a single non-numeric field is intended to do the job that field needs be populated with business-friendly, meaningful name values. If multiple ‘business facts’ are intended to be used in combination to find an instance in ‘happy path’ business processes, each of those facts should be defined as a separate field, and ‘flagged’ for inclusion to make up that record’s business identifier.
Next Article – Part 6 - Name Fields
Author: Dan Tasker
Dan is the author of over 30 requirements-related articles and other resources. His 45+ year career in Information Technology has involved organizations in a variety of industry sectors in the United States, Canada, Australia, and New Zealand. His business analysis experience includes projects involving in-house software development, software vendor solution development, and COTS software acquisition and implementation. He continues to be passionate about quality requirements and helping business analysts produce them. He can be contacted at [email protected].