Relational Theory and Conceptual Data Modeling

Introduction

Business analytics depends on trustworthy data. Dashboards, forecasts, customer segmentation, and operational reports are only as reliable as the structures that store the underlying facts. Relational theory provides a disciplined way to represent data as related sets of values, while conceptual data modeling translates business requirements into entities, attributes, relationships, and rules before implementation in a database management system.

This chapter connects business language with database design. It explains how to identify the objects a business cares about, how to represent their characteristics, how to specify relationships and cardinality, and how to protect correctness through keys and integrity constraints. It also introduces relational algebra, the formal foundation of many SQL operations.

Learning Objectives

By the end of this chapter, you should be able to:

1. Explain the relational model and its principal components.
2. Distinguish entities, attributes, relationships, domains, tuples, and relations.
3. Construct an entity–relationship model from business requirements.
4. Apply cardinality, participation, keys, and integrity constraints.
5. Explain primary, candidate, alternate, composite, and foreign keys.
6. Use basic relational algebra operations to express data requests.
7. Evaluate conceptual models for ambiguity, redundancy, and business-rule completeness.
8. Recognize governance, privacy, and implementation issues in data modeling.

1. From Business Requirements to Data Structures

A business requirement usually describes activities rather than database structures. For example:

A retail company registers customers, records orders, assigns each order to a customer, and records the products included in each order.

A modeler must interpret this statement. Likely entities include Customer, Order, and Product. “Places” describes a relationship between Customer and Order. “Includes” describes a relationship between Order and Product. Because one order may contain several products and one product may occur in many orders, the latter is a many-to-many relationship that normally requires an associative entity such as OrderLine.

A conceptual model is technology-independent. It describes the meaning and structure of data without deciding whether the final system will use PostgreSQL, SQL Server, Oracle, or another platform. This separation is valuable because premature attention to tables and data types can hide unresolved business rules.

A useful modeling sequence is:

1. Identify business nouns and candidate entities.
2. Identify business verbs and candidate relationships.
3. Identify descriptive facts about each entity or relationship.
4. Determine uniqueness and identification requirements.
5. Determine cardinality and optionality.
6. State integrity rules explicitly.
7. Validate the model with business users and sample scenarios.
8. Transform the conceptual model into a logical relational design.

2. The Relational Model

The relational model represents data using relations. In everyday database terminology, a relation is commonly implemented as a table, a tuple as a row, and an attribute as a column. The formal terms are important because a relation has properties that an arbitrary spreadsheet table may not have.

A relation consists of:

• A relation name, such as Customer.
• A set of attributes, such as CustomerID, Name, and Email.
• A domain for each attribute, defining permitted values.
• A set of tuples, each representing one occurrence or fact pattern.

For a relation R with attributes A₁, A₂, …, Aₙ, its schema may be written as:

A tuple contains one value for each attribute, subject to the model’s rules. A relation is mathematically a set, so duplicate tuples are not meaningful in the pure relational model. SQL implementations may permit duplicate rows in intermediate results unless DISTINCT or a key constraint removes them; this is one reason formal relational theory and practical SQL must be distinguished.

Domains and Atomic Values

A domain is the set of valid values for an attribute. For example, OrderStatus might have the domain {Pending, Paid, Shipped, Cancelled}. A domain is more than a data type. The data type might be VARCHAR(20), while the domain also specifies allowable values and meaning.

The relational model traditionally expects attributes to be atomic: each field contains one indivisible value for the purposes of the model. A CustomerPhone column containing one phone number per row is more relationally manageable than a single field containing “020-1111-1111; 020-2222-2222.” Repeating values should generally be represented in a related relation, such as CustomerPhone(CustomerID, PhoneNumber).

Relation, Table, and View

A base relation is stored data. A view is a named, derived representation produced from one or more relations. A view may present only approved columns, simplify complex queries, or provide a stable interface for analysts. Views do not necessarily store independent copies of the underlying facts.

3. Entities, Attributes, and Relationships

Entities

An entity is a distinguishable object, event, or concept about which an organization needs to store information. Examples include Employee, Supplier, Invoice, Shipment, and Course. An entity type describes a class of similar objects; an entity instance is one particular member of that class.

Entities should be identified because the business needs to remember facts about them or connect them to other facts. “Blue” is not usually an entity in a sales system; it is more likely a value of a ProductColor attribute. “Shipment,” however, may be an entity because it has a tracking number, dispatch date, carrier, and delivery status.

Attributes

An attribute is a meaningful property of an entity or relationship. Customer may have CustomerID, LegalName, RegistrationDate, and CreditLimit. Attributes can be classified as follows:

The classification depends on requirements. An address may be treated as a single display value in one application but decomposed into components when delivery zones or postal analysis is required. Modeling is therefore an exercise in representing business meaning, not mechanically applying a universal list of rules.

Derived values deserve care. Storing OrderTotal can improve reporting performance, but it creates a risk of inconsistency if order lines change and the total is not updated. A model should identify the authoritative facts and specify how derived values are calculated.

Relationships

A relationship represents an association among entity instances. A customer places an order; a supplier supplies a product; an employee works in a department. Relationship attributes may describe the association itself. In an enrollment system, Enrollment may have EnrollmentDate and Grade. These facts belong to the association between Student and Course, not exclusively to either entity.

Relationship names should be expressed as meaningful verbs and should be readable in both directions. For example:

• A Customer places an Order.
• An Order is placed by a Customer.
• A Student enrolls in a Course.
• A Course has enrolled Students.

Good names reduce ambiguity during implementation and requirements validation.

4. Cardinality and Participation

Cardinality states how many instances of one entity may or must be associated with an instance of another. Common forms are one-to-one (1:1), one-to-many (1:M), and many-to-many (M:N).

Participation or optionality states whether participation is mandatory or optional. A notation such as 0..1 means zero or one; 1..1 means exactly one; 0.. means zero or many; and 1.. means one or many.

Consider a university requirement:

• Each department employs one or more lecturers.
• Each lecturer belongs to exactly one department.
• A lecturer may teach zero or more modules.
• A module may be taught by several lecturers.

The first relationship is Department 1.. Lecturer, while the second is Lecturer 0.. Module. The lecturer–module relationship is many-to-many and may require an associative entity such as TeachingAssignment, possibly with attributes AcademicYear and TeachingRole.

Cardinality must be derived from business rules, not guessed from current data. If every current customer has one address, that does not prove that a customer can never have several addresses. Model the permitted business situation, including future and exceptional cases.

Conceptual Relationship Illustration

Figure: A conceptual design resolves an order–product many-to-many relationship through OrderLine.

The diagram shows that an order contains one or more order lines, while a product may appear on zero or many order lines. OrderLine is an associative entity. It can hold relationship-specific attributes such as Quantity and SalePrice. The stated cardinalities are business assumptions and must be confirmed with stakeholders.

5. Keys and Identification

A key is an attribute or set of attributes used to identify tuples or connect relations.

• A superkey is any attribute set that uniquely identifies a tuple.
• A candidate key is a minimal superkey: removing any attribute would destroy uniqueness.
• A primary key is the candidate key selected as the principal identifier.
• An alternate key is a candidate key not selected as the primary key.
• A composite key contains more than one attribute.
• A foreign key is an attribute or attribute set whose values refer to a candidate or primary key in another relation.

Suppose Student has StudentNumber and NationalInsuranceNumber, both unique. Both are candidate keys; one may be selected as the primary key and the other enforced as an alternate key. A key should be stable, minimal, and sufficiently controlled. A generated surrogate key can be useful when natural identifiers are long, changeable, or unavailable, but it does not eliminate the need to enforce business uniqueness.

For OrderLine, (OrderID, ProductID) may be a composite primary key if a product can occur only once per order. If a product can appear on separate lines for different discounts, LineNumber may be preferable, with a separate rule governing product repetition.

6. Integrity Constraints

Integrity rules protect the validity of stored facts.

Entity Integrity

Entity integrity requires every row in a relation to have a unique, non-null primary key. Without it, rows cannot be reliably identified or referenced.

Referential Integrity

Referential integrity requires a non-null foreign-key value to match an existing referenced key, unless the relationship is optional and NULL is permitted. For example, every Order.CustomerID must refer to an existing Customer.CustomerID. Deleting a customer who has orders therefore requires an explicit policy: restrict deletion, retain the customer as inactive, or apply a carefully justified cascading action.

Domain Integrity

Domain integrity limits values by data type, range, format, and permitted set. Quantity may need to be a positive integer; OrderStatus may need to belong to a controlled vocabulary. A data type alone is often insufficient.

Business Rules

Business rules express organization-specific constraints, such as:

• An invoice total cannot be negative.
• A shipment cannot be delivered before it is dispatched.
• A discount cannot exceed an approved limit.
• An employee cannot approve their own expense claim.

Some rules can be enforced with database constraints; others require triggers, application logic, workflow controls, or periodic data-quality checks. Rules that exist only in undocumented application code are vulnerable to bypass through imports, integrations, or direct database access.

7. From ER Models to Relational Schemas

A common transformation process is:

1. Create a relation for each strong entity.
2. Select a primary key for each relation.
3. Represent simple attributes as columns.
4. Decompose composite attributes where analysis requires their components.
5. Represent a 1:M relationship by placing the primary key of the “one” side as a foreign key on the “many” side.
6. Represent an M:N relationship with an associative relation containing foreign keys to both entities.
7. Represent multivalued attributes in a separate relation.
8. Review optionality, uniqueness, and delete/update behavior.

For the example, a logical design might be:

CUSTOMER(CustomerID PK, Name, Email UNIQUE)
ORDER(OrderID PK, CustomerID FK, OrderDate, Status)
PRODUCT(ProductID PK, Description, CurrentPrice)
ORDER_LINE(OrderID PK/FK, ProductID PK/FK, Quantity, SalePrice)

The keyword ORDER may be reserved in some SQL systems, so an implementation might use SalesOrder instead. This illustrates why conceptual names and physical names need not be identical.

A 1:1 relationship requires additional decisions. If every employee has exactly one locker and every locker belongs to one employee, either table can carry the other’s key as a foreign key, with a UNIQUE constraint. If the relationship is optional on both sides, the placement should reflect access patterns and nullability, or a separate relation may be clearer.

8. Redundancy and Normalization

Poor structure can cause anomalies:

• Insertion anomaly: a new product cannot be recorded until an order exists.
• Update anomaly: a supplier address must be changed in many rows.
• Deletion anomaly: deleting the last order unintentionally deletes the only record of a product.

Normalization provides principles for reducing such problems. At an introductory level:

• First normal form (1NF): attributes contain atomic values and repeating groups are removed.
• Second normal form (2NF): in 1NF, every non-key attribute depends on the whole candidate key, not just part of a composite key.
• Third normal form (3NF): in 2NF, non-key attributes depend on the key, the whole key, and nothing but the key; transitive dependencies among non-key attributes are removed.

Consider:

ORDER_LINE(OrderID, ProductID, ProductDescription, Quantity)

If ProductDescription depends only on ProductID, it does not depend on the whole composite key. Moving it to PRODUCT removes a partial dependency. Similarly, if CustomerCity depends on CustomerID rather than OrderID in an Order relation, it should normally be stored with Customer.

Normalization is not a command to split data without judgment. Analytical warehouses may deliberately use denormalized structures to improve query performance and usability. Such decisions should be explicit, documented, and supported by controls that prevent conflicting copies of facts.

9. Relational Algebra

Relational algebra is a procedural formal language for manipulating relations. It provides a theoretical foundation for query languages, including SQL, although SQL has additional features and often uses bag semantics.

Let R and S be relations.

Selection

Selection chooses tuples satisfying a predicate:

For example, σ_{Status='Paid'}(Order) returns paid orders. Selection filters rows and does not normally change the attributes of R.

Projection

Projection chooses attributes:

For example, π_{CustomerID,Name}(Customer) returns customer identifiers and names. In pure relational algebra, duplicate tuples disappear because the result is a set; SQL may retain duplicates unless DISTINCT is specified.

Union, Difference, and Intersection

Union combines tuples from compatible relations:

R and S must be union-compatible: they must have corresponding attributes with compatible domains. Difference returns tuples in R but not S:

Intersection returns tuples common to both:

Cartesian Product

The Cartesian product pairs every tuple in R with every tuple in S:

It is conceptually useful but can produce a very large result and is usually constrained by a join condition in practical queries.

Join

A join combines related tuples. A theta join applies a condition:

An equijoin uses equality. A natural join matches same-named attributes, but it can be risky when names coincide unintentionally; explicit join conditions are generally clearer in SQL.

Division

Division supports “for all” questions. If R(X,Y) records suppliers and products and S(Y) lists required products, R ÷ S returns suppliers associated with every product in S. Division is less common in everyday SQL syntax but is conceptually important for requirements such as “customers who purchased every product in a campaign.”

#### Worked Relational Algebra Example

Assume:

CUSTOMER(CustomerID, Name)
ORDER(OrderID, CustomerID, Status)

To obtain the names of customers with paid orders:

The selection first limits Order to paid orders. The join connects those orders to customers. The projection returns only Name. In SQL, the equivalent might use SELECT, FROM, JOIN, and WHERE. If a customer has several paid orders, SQL may return repeated names unless DISTINCT is used; the formal projection treats the result as a set.

10. A Systematic Modeling Method

A professional modeling workshop should combine documentation, interviews, process observation, and sample data. The following method is effective:

Establish Scope

Define the business process, organizational boundary, time period, and intended uses. “Model sales” is too broad; “model online order capture and fulfillment” is more precise.

Extract Candidate Concepts

Highlight nouns, verbs, quantities, dates, status terms, and policy statements in requirements. Classify each candidate as an entity, attribute, relationship, rule, or vocabulary term.

Test Entity Status

Ask whether the concept has independent identity, multiple attributes, a life cycle, or relationships with other concepts. If not, it may be an attribute or a controlled value rather than an entity.

Define Grain

The grain states what one row represents. For Order, one row may represent one customer order. For OrderLine, one row may represent one product occurrence within one order. Unclear grain is a major cause of analytical errors.

Specify Keys and Rules

Document candidate identifiers, uniqueness, nullability, permitted values, and temporal requirements. Ask whether historical values must be retained. A current ProductPrice does not answer what price was charged on an order; SalePrice may need to be stored on OrderLine.

Validate with Scenarios

Test normal, boundary, and exceptional cases: a customer with no orders, an order with many lines, a cancelled order, a product discontinued after previous sales, and an attempted duplicate identifier. A model that handles only the common case is incomplete.

11. Illustrative Case: Northstar Outdoor Retail

Background

Northstar Outdoor Retail sells equipment through stores and an online channel. Management wants a unified sales database for inventory reporting, customer analysis, and fulfillment performance.

Problem

Initial spreadsheets contain one row per order line with customer name, product description, supplier name, quantity, price, and shipment status. The same customer and product details are repeated many times. Analysts find inconsistent spellings, changing prices, and difficulty identifying customers who have never ordered.

Analysis

The required concepts are Customer, SalesOrder, Product, Supplier, OrderLine, and Shipment. A supplier can supply many products, while a product may have several suppliers, so SupplierProduct is an associative entity. A SalesOrder contains one or more OrderLines. A customer may have zero or many orders. An order may have zero or many shipments because split fulfillment is possible.

Important facts have different grains:

Approach and Solution

The conceptual model separates stable entities from relationships. CustomerName is stored once in Customer. ProductDescription is stored in Product. SalePrice is stored in OrderLine because historical analysis requires the price charged at the time of sale, not merely today’s product price. ShipmentStatus is stored with Shipment because an order may have several shipments with different statuses.

A simplified logical schema is:

CUSTOMER(CustomerID PK, Name, Email UNIQUE)
PRODUCT(ProductID PK, Description, CurrentPrice)
SUPPLIER(SupplierID PK, Name)
SUPPLIER_PRODUCT(SupplierID PK/FK, ProductID PK/FK, LeadTimeDays)
SALES_ORDER(OrderID PK, CustomerID FK, OrderDate, Status)
ORDER_LINE(OrderID PK/FK, LineNumber PK, ProductID FK, Quantity, SalePrice)
SHIPMENT(ShipmentID PK, OrderID FK, DispatchDate, DeliveryDate, Status)

LineNumber is used rather than ProductID as part of the OrderLine key because the business may permit the same product to appear on separate lines—for example, with different discounts or fulfillment locations.

Outcome

The design supports customer-level and product-level reporting, preserves historical sale prices, represents split shipments, and reduces inconsistent repeated descriptions. Constraints can prevent an order line from referencing a nonexistent product and can require positive quantities. Governance documentation defines the meaning of “customer,” “order date,” and “delivered.”

Learning Points

1. Requirements must be translated into explicit entities and rules.
2. Row grain determines whether analysis is valid.
3. Relationship attributes belong with the relationship or associative entity.
4. Current descriptive values and historical transaction values may both be necessary.
5. A normalized conceptual model improves quality, but physical reporting structures may later be optimized separately.

12. Governance, Ethics, and Contemporary Practice

Data modeling is also a governance activity. A model decides what the organization records, how identities are represented, and which facts can be linked. Poor decisions can produce unfair classifications, privacy violations, or misleading performance measures.

Privacy and Minimization

Collect only data justified by a legitimate business purpose. Sensitive attributes should have clear access controls, retention periods, and lawful processing grounds. A Customer model should not automatically include every available demographic field merely because it could be useful someday.

Identity Resolution

Customer analytics often attempts to connect records from websites, stores, and mobile applications. Deterministic matching using verified identifiers is generally more defensible than relying solely on names or approximate similarity. Probabilistic matching should record confidence, preserve uncertainty, and provide correction processes. Incorrectly merging two people can expose private information and distort decisions.

Temporal and Audit Requirements

Many organizations need to know not only the current value but also what was true at a particular time. Effective dates, transaction timestamps, audit history, and slowly changing dimensions may be required. A model should distinguish event time, system-recording time, and business-effective time when those concepts differ.

AI-Assisted Modeling

AI tools can suggest entities, infer relationships from documents, generate sample SQL, or detect duplicate attributes. These capabilities can accelerate discovery but do not establish authoritative business meaning. Human review is essential because an AI system may infer cardinality from incomplete examples, expose confidential requirements, or reproduce biased assumptions. Approved terminology, lineage, testing, and access controls remain necessary.

Implementation Best Practices

• Define business terms in a data glossary.
• Record assumptions and unresolved questions.
• Assign data owners and stewards.
• Enforce keys, domains, and referential integrity in the database where feasible.
• Test with realistic edge cases rather than only clean examples.
• Separate conceptual, logical, and physical design decisions.
• Document lineage for important analytical measures.
• Review models when processes, regulations, or system integrations change.

13. Limitations and Design Trade-offs

No model captures every aspect of organizational reality. A highly normalized model may require many joins and be less convenient for analysts. A denormalized model may be faster or easier to query but can introduce duplicated facts. Surrogate keys simplify integration but may conceal meaningful business identity. NULL can represent unknown, not applicable, or not yet recorded, and these meanings should not be confused.

Relational databases are excellent for structured facts and transactional integrity. They may be less suitable alone for unstructured documents, high-volume event streams, or highly variable data. Even in hybrid architectures, relational concepts remain valuable: entities, identifiers, relationships, constraints, and clear grain are needed for reliable integration and analysis.

Chapter Summary

The relational model represents structured facts as relations composed of attributes and tuples governed by domains and constraints. Conceptual data modeling translates business requirements into entities, attributes, relationships, cardinalities, keys, and integrity rules before implementation. Entities represent objects or events; attributes describe them; relationships express associations; and cardinality and optionality state how those associations operate.

Primary and candidate keys support identification, while foreign keys support referential integrity. Domain, entity, and business-rule constraints protect data quality. Many-to-many relationships are normally resolved through associative entities, and relationship-specific facts should be stored with those associations. Normalization reduces insertion, update, and deletion anomalies, although deliberate denormalization may be appropriate for analytical performance.

Relational algebra provides formal operations such as selection, projection, union, difference, product, join, and division. These operations explain the conceptual basis of SQL queries. Effective modeling depends on defining scope and row grain, validating assumptions with stakeholders, representing historical needs, and addressing governance, privacy, identity resolution, and auditing. A strong model is not merely technically elegant; it faithfully represents the business and supports trustworthy analysis.

Key Terms

Entity: A distinguishable object, event, or concept about which data is stored.

Entity type: A class of similar entities, such as Customer.

Entity instance: One particular occurrence of an entity type.

Attribute: A property describing an entity or relationship.

Domain: The permitted set of values for an attribute.

Relation: A formal set of tuples described by a schema.

Tuple: A row or record in a relation.

Primary key: The selected candidate key used as the principal identifier.

Candidate key: A minimal attribute set that uniquely identifies a tuple.

Foreign key: An attribute set referencing a key in another relation.

Composite key: A key made up of more than one attribute.

Cardinality: The permitted number of related instances.

Participation: Whether relationship involvement is optional or mandatory.

Associative entity: An entity used to represent a many-to-many relationship.

Entity integrity: The requirement that primary keys be unique and non-null.

Referential integrity: The requirement that foreign-key references be valid.

Normalization: The structuring of relations to reduce redundancy and anomalies.

Relational algebra: A formal language for operations on relations.

Grain: The precise meaning represented by one row.

Data steward: A person responsible for the meaning, quality, and appropriate use of data.

Review Questions

Short Answer Questions

1. What is the difference between an entity and an attribute?
2. Define candidate key and foreign key.
3. What do cardinality and participation describe?
4. Why is an associative entity often needed for a many-to-many relationship?
5. State the purpose of referential integrity.

Long Answer Questions

1. Explain how a business requirement can be transformed into a conceptual entity–relationship model. Include the roles of nouns, verbs, attributes, keys, and business rules.
2. Compare primary, candidate, alternate, composite, and surrogate keys. Discuss advantages and risks of surrogate keys.
3. Explain first, second, and third normal forms and show how normalization can prevent common data anomalies.
4. Describe the principal relational algebra operations and explain how selection, projection, and join can be combined to answer a business question.
5. Discuss the governance and ethical issues that should be considered when modeling customer data for analytics.

Analytical / Application Questions

1. A company states: “Each employee may work on many projects, and each project may have many employees. The assignment records hours per week and assignment start date.” Design the conceptual solution, including entities, keys, cardinality, and relationship attributes.
2. A report stores OrderID, CustomerID, CustomerName, ProductID, ProductName, Quantity, and SalePrice in one relation. Identify likely dependencies and propose a normalized relational design. State the grain of each resulting relation.
3. Using relational algebra, express the request: “Return the names of customers who placed at least one order with status Shipped.” State any assumptions about relation names and join attributes.

Multiple Choice Questions with Answers

Question 1

Which concept specifies the permitted set of values for an attribute?

A. Domain

B. Tuple

C. Cardinality

D. Foreign key

Correct Answer: A. Domain

Question 2

A relationship in which one order can contain many products and one product can occur in many orders is best represented by which design?

A. A single composite attribute

B. An associative entity such as OrderLine

C. A one-to-one foreign key

D. A derived attribute

Correct Answer: B. An associative entity such as OrderLine

Question 3

Which constraint requires a foreign-key value to match an existing referenced key, when the value is not null?

A. Entity integrity

B. Domain integrity

C. Referential integrity

D. Semantic integrity

Correct Answer: C. Referential integrity

Question 4

Which relational algebra operation filters tuples according to a condition?

A. Projection

B. Selection

C. Union

D. Division

Correct Answer: B. Selection

Question 5

In the relation OrderLine(OrderID, ProductID, ProductDescription, Quantity), ProductDescription depends only on ProductID. What problem does this indicate when the key is (OrderID, ProductID)?

A. A partial dependency

B. A referential violation

C. A cardinality error

D. A missing domain

Correct Answer: A. A partial dependency

Question 6

Which statement about a candidate key is correct?

A. It may contain unnecessary attributes and still be minimal

B. It uniquely identifies tuples and is minimal

C. It must always be a foreign key

D. It can contain duplicate values

Correct Answer: B. It uniquely identifies tuples and is minimal

Question 7

A row in an OrderLine relation most appropriately represents which grain?

A. One customer account

B. One product catalog

C. One product occurrence within one order

D. One supplier organization

Correct Answer: C. One product occurrence within one order

Question 8

Which relational algebra expression returns selected attributes from Customer?

A. σ_{Name}(Customer)

B. π_{CustomerID,Name}(Customer)

C. Customer × Name

D. Customer − Name

Correct Answer: B. π_{CustomerID,Name}(Customer)

Question 9

Why might SalePrice be stored on OrderLine when Product has CurrentPrice?

A. To avoid using a primary key

B. To preserve the historical price charged at the time of sale

C. To make Product a weak entity

D. To enforce a many-to-many relationship automatically

Correct Answer: B. To preserve the historical price charged at the time of sale

Question 10

Which practice best supports responsible AI-assisted data modeling?

A. Accepting inferred relationships without review

B. Removing all business-user involvement

C. Treating generated suggestions as authoritative definitions

D. Reviewing suggestions against approved terminology and business rules

Correct Answer: D. Reviewing suggestions against approved terminology and business rules