Business Object Characteristics

Every business object has characteristics that describe it. Characteristics are the observable properties of a business object — the pieces of information that distinguish one instance of that object from another and that the organization needs to record. Customers have names, addresses, and phone numbers. Products have names, prices, and descriptions. Orders have dates, quantities, and status values. Appointments have times, dates, and durations.

Understanding what characteristics a business object has is a core task of Requirements Analysis. The characteristics identified during requirements gathering become the attributes of entities in the logical design stage, and those attributes ultimately become the columns of database tables. Getting the characteristics right at the requirements stage means the database will be able to store exactly what the organization needs — no more, no less. Missing a characteristic at this stage means a missing column in the final table, which requires a structural change to the database after implementation.

The Two-Characteristic Rule

If you cannot identify two or more characteristics of a business object, there is a strong possibility it is not a business object at all. This rule serves as a practical filter during Requirements Analysis. A business object without at least two characteristics cannot form a meaningful database table — a table with a single column carries no useful information beyond the fact that something exists.

Consider the Stories on CD, Inc. case study. When the database designer examines the business objects identified in Lesson 3 — customers, orders, products, distributors, and brochures — each one passes the two-characteristic test immediately. A customer has at minimum a name and a contact detail. A product has at minimum a title and a price. An order has at minimum a date and a customer reference. A distributor has at minimum a company name and a phone number. A brochure has at minimum a mailing date and a list of featured products.

The two-characteristic rule also helps the designer identify candidate business objects that stakeholders mention but that may not need their own table. If a stakeholder mentions "shipping carriers" during an interview, the designer asks: what characteristics does the organization need to record about a shipping carrier? If the answer is only the carrier name — because the organization does not track carrier contacts, performance metrics, or contract details — then shipping carrier may not warrant its own table. It might be better represented as an attribute of the Order table rather than as a separate entity. The two-characteristic rule focuses the designer's attention on this distinction.

Sample Business Objects and Their Characteristics

The image below shows six sample business objects and the characteristics associated with each, drawn from a range of different database contexts. Each business object is represented as a preliminary table showing the kind of data an organization might need to store about that object.

Each of the six business objects shown — Customers, Employees, Products, Vendors, Raw Materials, and Jazz Concerts — satisfies the two-characteristic rule by a wide margin. The Customers object has first name, last name, address, city, state, ZIP, and phone. The Products object has product name, description, unit price, and units in stock. Jazz Concerts illustrates that business objects are not limited to commercial or industrial contexts — any organization that needs to track concerts, including venues, performers, and dates, would identify Jazz Concert as a business object during Requirements Analysis.

For Stories on CD, Inc., the five business objects identified in Lesson 3 each carry the following preliminary characteristics at the close of Requirements Analysis. The Customer object carries: Customer ID, first name, last name, street address, city, state, ZIP, phone number, and customer type (actual or potential). The Order object carries: Order ID, Customer ID, order date, order type (in-store or mail-order), and shipping status. The Product object carries: CD ID, title, age group, retail price, and description. The Distributor object carries: Distributor ID, company name, contact phone, street address, city, state, and ZIP. The Brochure object carries: Brochure ID, mailing date, and a reference to the featured products included in that edition.

Characteristics Become Attributes

The characteristics identified during Requirements Analysis are converted into the attributes^[1] of entities in the logical design stage. This conversion is largely direct — a characteristic named in a stakeholder interview becomes an attribute with a formal name, data type, and constraint definition in the logical design. Attributes, in turn, are translated into table columns expressed in SQL during physical implementation.

The progression for the Stories on CD, Inc. Customer object follows this path. During Requirements Analysis, the designer records that a customer has a first name, a last name, an address, a phone number, and a customer type. In the logical design stage, these characteristics become formally defined attributes of the Customer entity: customer_id (primary key, integer), first_name (varchar), last_name (varchar), street (varchar), city (varchar), state (char, 2), zip (char, 5), phone (varchar), customer_type (char — 'A' for actual, 'P' for potential). In the physical implementation stage, these attributes become columns in a CREATE TABLE statement:

CREATE TABLE customer (
    customer_id    INTEGER      NOT NULL,
    first_name     VARCHAR(30)  NOT NULL,
    last_name      VARCHAR(30)  NOT NULL,
    street         VARCHAR(50),
    city           VARCHAR(30),
    state          CHAR(2),
    zip            CHAR(5),
    phone          VARCHAR(15),
    customer_type  CHAR(1)      NOT NULL,
    CONSTRAINT pk_customer PRIMARY KEY (customer_id)
);

The chain from Requirements Analysis characteristic to logical design attribute to physical table column is direct and traceable. Every column in the final table corresponds to a characteristic that a stakeholder identified as something the organization needs to store. If a column cannot be traced back to a stakeholder-identified characteristic, it raises the question of why that column exists. Maintaining this traceability is one reason why thorough documentation during Requirements Analysis pays dividends throughout the DBLC.

Preliminary Relationships Between Business Objects

Business objects relate to each other in some form or fashion. Customers place orders. Orders include products. Products come from distributors. Brochures feature products. These relationships are not incidental — they are structural properties of the business that the database must represent through foreign key connections between tables.

Establishing relationships at the Requirements Analysis stage is preliminary by design. The designer notes which objects appear to be connected without yet determining the precise cardinality of each relationship — whether it is one-to-one, one-to-many, or many-to-many. That determination belongs to the conceptual design stage, where the ER diagram formalizes the relationships. During Requirements Analysis, the goal is simply to record that a relationship exists and to note its general character.

For Stories on CD, Inc., the preliminary relationship map is as follows. The Customer and Order objects are related — a customer can place one or more orders, and each order belongs to one customer. The Order and Product objects are related — an order can include one or more products, and a product can appear on one or more orders. This last relationship is likely many-to-many, which will require a resolution entity (an Order Line or Order Detail object) in the logical design stage. The Product and Distributor objects are related — products are sourced from distributors, and a distributor may supply multiple products. The Product and Brochure objects are related — brochures feature products, and a product may appear in multiple brochures across different mailing cycles.

These preliminary relationships are noted in the requirements documentation alongside the business object characteristics. They do not need to be fully resolved during Requirements Analysis — the important thing is that no significant relationship is overlooked, because an unrecorded relationship at this stage becomes a missing foreign key in the final database.

It is important to note what objects are generally related in the existing database or data storage system. Ted's flat-file system for Stories on CD, Inc. implicitly links customers and orders through shared fields, but does so without enforcing referential integrity. Identifying that this relationship exists and documenting it formally is one of the ways that Requirements Analysis improves on the implicit structure of the legacy system.

Documenting Characteristics During Requirements Analysis

As part of Requirements Analysis, database designers list and document the business objects stored in the client's existing database, along with their characteristics and a preliminary idea of how they are related. This documentation takes the form of a preliminary entity list — an informal catalog that the designer maintains and updates throughout the requirements gathering process.

Many database designers use diagramming tools to capture business objects and their characteristics directly during interviews and database examinations. A tool that can generate a draft ER diagram from an object and attribute list allows the designer to present a visual representation of the emerging model to stakeholders in near-real time. Stakeholders who might struggle to evaluate a textual requirements document can often quickly identify errors or omissions when they see a diagram of the entities and their connections. The diagram is a communication tool as much as a design artifact at this stage.

The documentation produced during Requirements Analysis — business object lists, preliminary attribute definitions, relationship notes, and draft ER diagrams — forms the input to the conceptual design stage. The quality of that input determines the quality of the design that follows. A requirements document that captures all business objects, their characteristics, and their relationships accurately will produce a logical design that needs few corrections. A requirements document with gaps will produce a logical design that requires backtracking to fill them.

The next lesson describes business rules — the constraints and policies that govern how data in the database is created, modified, and interpreted.

Identify Business Objects — Exercise

Identify Business Objects - Exercise