Define Business Objects

Identifying an organization's business objects is typically the first order of business during Requirements Analysis. Before a designer can draw a single entity in an ER diagram or write a single CREATE TABLE statement, they must understand what the organization needs to store data about. Business objects are the answer to that question.

Business objects are things — both tangible and intangible — in a business environment that are related to each other and about which data is, or needs to be, stored. Employees, projects, customers, appointments, students, products, orders, and suppliers are all examples of business objects. Each one represents a distinct category of information that an organization tracks in order to conduct its operations. The goal of this lesson is to establish a clear definition of business objects, explain how to identify them during Requirements Analysis, and show how they eventually become the tables in a relational database.

What Makes Something a Business Object

Not every noun in a business description qualifies as a business object. A business object must satisfy two conditions. First, it must be something the organization needs to store data about — not just something that exists in the environment, but something for which the organization needs a persistent record. Second, it must be related to other things the organization stores data about. An isolated piece of information with no connection to anything else in the business is not a business object in the database design sense; it is simply a fact.

For Stories on CD, Inc., the business objects emerge clearly from the Requirements Analysis interviews and the examination of Ted's flat-file system. The company needs to store data about customers — the people who buy or might buy its products. It needs to store data about orders — the transactions that link customers to products. It needs to store data about products — the CD titles it sells, organized by age group. It needs to store data about distributors — the suppliers from whom it sources its inventory. And it needs to store data about brochures — the marketing materials it sends to customers and potential customers several times a year.

Each of these is a business object because the organization needs a persistent record of it, and because each one is related to at least one other. Customers are related to orders. Orders are related to products. Products are related to brochures. Distributors are related to products through the supply relationship. The connections between business objects are as important as the objects themselves, because those connections determine the foreign key relationships in the eventual database design.

Where to Look for Business Objects

Since most database design situations involve organizations that already have some form of data storage in place, the first place to look for business objects is in the existing system — whether that system is a legacy^[1] database, a paper-based^[2] filing system, or both. The existing system reflects the organization's current understanding of what it needs to track, even if that understanding is incomplete or the implementation is technically deficient.

For Stories on CD, Inc., Ted's flat-file system is the starting point. Examining that system reveals that the company is already tracking customers, orders, and products in some form — even if the flat-file structure creates problems with duplicate records, missing relationships, and the absence of a channel distinction between in-store and mail-order purchases. The flat-file examination tells the designer what business objects the organization recognizes and, equally important, what it is failing to track adequately. Distributor information is not in the system at all — Jane maintains it on Rolodex cards. Brochure records do not exist in any form. Both of these gaps become requirements for the new database.

Paper-based sources are equally valuable. Order forms, customer intake sheets, inventory lists, and marketing brochure templates all reveal business objects that the organization tracks manually. In many cases, a paper form that has been in use for years is a more accurate picture of the organization's data needs than any automated system built to replace it, because the form evolved organically to capture what people actually needed to record rather than what a system designer thought they would need.

Sorting Business Objects by Subject

During Requirements Analysis, business objects must be identified and sorted according to subject. This sorting step is essential because it determines how many databases the organization needs and what each database should contain.

A database should deal with one and only one subject category. A subject category is a coherent cluster of related business objects that together describe one domain of the organization's operations. Mixing subject categories in a single database produces a system that is difficult to query, difficult to maintain, and prone to the same kinds of data integrity problems that made the flat-file approach inadequate in the first place.

For Stories on CD, Inc., all of the identified business objects — customers, orders, products, distributors, and brochures — belong to a single subject category: the company's retail sales and marketing operations. There is no second subject category present, so a single database is appropriate. If the Martins had also wanted to track employee payroll or supplier contracts, those would represent distinct subject categories that would warrant separate databases.

Multiple Databases Within a Single RDBMS

Multiple databases can be managed by a single Relational Database Management System (RDBMS), and queries and user views — such as stored queries — can be created across databases within the same system. This means that organizing an organization's data into multiple focused databases does not prevent those databases from being used together. A report that draws on data from two different databases is straightforward to produce when both databases live in the same RDBMS.

The principle that each database should address one subject category is therefore not a constraint on what the organization can query — it is a constraint on how data is organized for maintenance and integrity purposes. Keeping subject categories separate means that changes to one area of the business do not inadvertently affect another, and that the integrity rules for each subject domain can be defined and enforced independently.

Every organization makes decisions about which business objects it will and will not store data about. For Stories on CD, Inc., Bob and Jane Martin — the company's owners — have decided that they do not want any data about themselves stored in the company database. Ted, their son, who built the original flat-file system, is similarly excluded. Owner and employee data falls outside the subject category that the database will address. This is a legitimate business decision, and the database designer's role is to document it as a boundary condition rather than to challenge it. The database will track customers, orders, products, distributors, and brochures — and will not track employees or owners.

Business Objects vs Entities

The term business object belongs to the vocabulary of Requirements Analysis. It describes what the organization needs to store data about, stated in business language that stakeholders can understand and verify. The term entity^[3] belongs to the vocabulary of logical design. It describes the same concept in the formal language of data modeling.

The distinction matters because the two stages of the design process serve different audiences. Requirements Analysis produces documentation for stakeholders — business owners, managers, and end users — who need to confirm that the designer has correctly understood what the organization needs. Using the term "Customer entity" in a requirements document risks confusing stakeholders who think of customers as people, not as formal data constructs. Using the term "Customer business object" communicates the same concept in language that is accessible to non-technical reviewers.

When Requirements Analysis is complete and the conceptual design stage begins, business objects are formally converted into entities. Each business object identified during Requirements Analysis becomes a candidate entity in the ER diagram. Some business objects will map directly to a single entity. Others — particularly those that involve many-to-many relationships — will result in the creation of additional entities during the normalization process. Lesson 4 of this module addresses the characteristics of business objects that determine how they are modeled as entities.

How Business Objects Become Database Tables

The progression from business object to database table follows the sequence of DBLC stages. During Requirements Analysis, business objects are identified in business language. During conceptual design, they are converted into entities in an ER diagram. During logical design, entities are translated into a normalized table structure. During physical implementation, that table structure is expressed in SQL^[4] — the industry-standard database programming language — and created on the target database platform.

For Stories on CD, Inc., the Customer business object identified during Requirements Analysis becomes the Customer entity in the ER diagram. The Customer entity becomes the CUSTOMER table in the logical design, with columns for Customer ID, first name, last name, address fields, phone number, and customer type. That table definition is then implemented in SQL as a CREATE TABLE statement on the chosen platform — Oracle Database, MySQL, PostgreSQL, or whichever system the Martins select for the production database.

The same progression applies to every business object identified during Requirements Analysis. Each one traces a path from a business concept articulated by a stakeholder through a formal data model and ultimately into a concrete database structure. Getting the business object identification right at the Requirements Analysis stage ensures that every subsequent stage builds on an accurate foundation. Missing a business object at this stage means missing a table in the final database — a gap that will surface as a limitation the system cannot address without structural changes.

Documenting Business Objects

As business objects are identified during Requirements Analysis, they are documented in a preliminary entity list — an informal catalog that records the name of each business object, a brief description of what it represents, and the initial set of attributes that stakeholders have mentioned. This list is not the final logical design; it is the working document that the designer maintains and refines as interviews, flat-file examination, and data flow analysis add new information.

For Stories on CD, Inc., the preliminary entity list at the close of Requirements Analysis includes five entries: Customer, Order, Product, Distributor, and Brochure. Each entry records the attributes identified so far, the business rules that apply to it, and any open questions that need to be resolved before the conceptual design stage begins. Open questions might include the exact definition of a "potential customer," the fields that need to be captured for each distributor, or whether brochure editions need to be tracked individually or can be aggregated. These questions drive the follow-up interviews that complete the requirements gathering process.

The next lesson describes the characteristics of business objects — the specific properties that define how a business object is structured and how it relates to other objects in the database.