Database Design   «Prev  Next»

Lesson 4 Business Objects represented as tables
Objective Describe the characteristics of Business Objects

The Relationship Between Characteristics of Business Objects and Attributes of Entities in an ERD Model: A Technical Perspective

Entity-Relationship Diagrams (ERD) are a widely used modeling technique for representing the structure and organization of data within an information system. They provide a visual representation of the relationships between entities, their attributes, and the cardinalities that define the connections between them. This technical analysis will explore the relationship between the characteristics of business objects and the attributes of entities in an ERD model.
  • Business Objects and Their Characteristics: A business object represents a real-world entity or concept that plays a significant role in an organization's operations and processes. These objects can be tangible or intangible and may include customers, products, services, employees, or locations, among others. The characteristics of business objects refer to the properties, qualities, or features that describe and define these objects within the context of the organization.
  • Entities and Attributes in an ERD Model: In an ERD model, an entity represents a real-world object or concept, similar to a business object. Entities have attributes, which are the properties or characteristics that describe and define them within the context of the information system. Attributes can be simple or composite, and may be derived from other attributes or relationships. Examples of attributes include customer names, product IDs, employee numbers, and transaction dates.

Relationship between Characteristics of Business Objects and Attributes of Entities in an ERD Model

The characteristics of business objects and the attributes of entities in an ERD model are closely related, as both describe the properties and features of the entities in their respective contexts. The primary relationship between them is as follows:
  1. Mapping Characteristics to Attributes: The characteristics of business objects can be mapped directly to the attributes of corresponding entities in an ERD model. This mapping process translates the real-world properties and features of business objects into a structured representation suitable for use in an information system. For example, a customer's name, address, and contact information are characteristics of the customer business object, which can be mapped to the corresponding attributes of the customer entity in the ERD model.
  2. Consistency and Completeness: The attributes of entities in an ERD model should accurately represent the relevant characteristics of the corresponding business objects to ensure the consistency and completeness of the information system. This requires a thorough analysis of the organization's objectives, processes, and data requirements to identify the key business objects, their characteristics, and the relationships between them.
  3. Normalization and Abstraction: The process of mapping characteristics to attributes may involve normalization and abstraction to optimize the structure and organization of the ERD model. Normalization refers to the process of organizing attributes and relationships in a manner that minimizes redundancy and improves the integrity of the data. Abstraction, on the other hand, refers to the process of simplifying complex characteristics into a more manageable and general representation within the ERD model.

In summary, the relationship between the characteristics of business objects and the attributes of entities in an ERD model is one of direct correspondence and mapping. The characteristics of business objects are used to define and describe the attributes of entities in the ERD model, ensuring the consistency, completeness, and accuracy of the information system. This relationship is essential for the effective design, development, and management of information systems that support an organization's operations, processes, and decision-making.
Database Systems

Business Object Characeristics

Every business object has characteristics that describe it. Customers, employees, students, and suppliers, for example, will have names, addresses, phone numbers, and so on. Products will have names, prices, descriptions, and so on. Appointments will have times, dates, and so on. In fact, 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. Below is a list of sample business objects and their characteristics, appropriate to a wide range of databases.
Business Objects consisting of 6 tables 1) Customers, 2) Employees, 3) Products, 4) Vendors, 5)Raw Materials, 6) Jazz Concerts
Business Objects consisting of 6 tables 1) Customers, 2) Employees, 3) Products, 4) Vendors, 5)Raw Materials, 6) Jazz Concerts

The characteristics of business objects are converted into the attributes[1] of entities in the logical design stage. Attributes, in turn, are ultimately translated into table fields with SQL.

Relationships between Business Objects
Business objects relate to each other in some form or fashion. Customers place orders, employees take orders, orders are for products, products come from suppliers. Relationships between objects can be complex, so establishing relationships at this point in the design process is quite preliminary. It is important to note, however, what objects are generally related, especially in the existing database(s).
As part of Requirements Analysis, database designers list and document the business objects stored in the client’s existing database(s), along with their characteristics and a preliminary idea of how they are related. The next lesson describes business rules.

Documenting Findings of Requirements Analysis

Computer-Aided Software Engineering (CASE) tools are software applications designed to aid in various stages of the software development process, including requirements analysis. By utilizing CASE tools, an analyst can effectively document, manage, and communicate the findings of the requirements analysis phase, ensuring a comprehensive and consistent understanding of the system requirements among stakeholders. The following steps outline how an analyst can use CASE tools to document requirements analysis and findings:
  1. Requirements elicitation: CASE tools can support analysts in gathering and organizing information from various sources such as interviews, workshops, and questionnaires. These tools offer features for capturing and storing raw data, as well as functionalities to prioritize, categorize, and track the requirements.
  2. Requirements modeling: CASE tools provide graphical modeling capabilities to create visual representations of the requirements, such as Data Flow Diagrams (DFDs), Entity-Relationship Diagrams (ERDs), and Unified Modeling Language (UML) diagrams. These models help stakeholders gain a clear understanding of the system's structure, data flows, and relationships, facilitating communication and reducing the risk of misunderstandings.
  3. Requirements documentation: CASE tools often include built-in templates and document generation features to create a Requirements Specification Document, which outlines the functional and non-functional requirements, data requirements, business rules, and use cases. The tool ensures a consistent format and structure, improving the overall quality and readability of the document.
  4. Requirements traceability: With the help of CASE tools, analysts can establish and maintain a Requirements Traceability Matrix (RTM), which maps requirements to their corresponding design, development, and testing artifacts. The RTM enables analysts to track the progress of requirements throughout the project, manage changes, and assess the impact of modifications.
  5. Collaboration and communication: CASE tools often include features that facilitate collaboration among stakeholders, such as version control, change tracking, and commenting. These tools can integrate with project management and communication platforms, allowing team members to share and discuss requirements, models, and documents in a centralized location.
  6. Validation and verification: Analysts can use CASE tools to validate and verify the completeness, consistency, and accuracy of requirements. The tools may offer automated checks for syntax, semantics, and compliance with industry standards or best practices. Additionally, they can support the review and approval process by providing workflows and electronic signatures.

CASE tools play an essential role in supporting analysts during the requirements analysis phase. They enable efficient documentation, modeling, management, and communication of the findings, ensuring that the requirements are well-defined, accurate, and consistent. By leveraging the capabilities of CASE tools, analysts can improve the overall quality of the requirements analysis process and increase the likelihood of successful system development.

Notebook Computers with CASE tools

Question: Are you a database designer that carries a laptop computer with CASE tools installed to your assignments?
Many database designers have notebook computers with CASE tools installed, which they carry with them to assignments. This enables them, for example, to enter business objects, their relationships, and their characteristics directly into the CASE tool while analyzing the existing database(s). The tool then generates a draft entity-relationship (ER) diagram which is easily modified as more information is gleaned. The triangle of truth is a simple way to look at the important architectural constructs that make up a service oriented architecture. When you consider what is needed to build a service oriented architecture, the triad that makes up the triangle of truth quickly emerges. Specifically, there must be a way to represent the data that is exchanged between services, a mechanism for invoking services, and a way to compose services into a larger integrated business application.
  • (GIS) Geographic Information Systems
    1. Requirements analysis specifies what the the system is required to do based on user/stakeholder input
    2. Design specifies how the system will address the requirements
    3. Implementation translates design specifications into a working system
    Requirements analysis is critical to the success of a project.
    Requirements analysis can be applied at several different levels
    1. Overall system design
    2. Database design
    3. GIS application design
    Determines data, information, system components, data processing and analysis functions required by an organization, enterprise, individual user.

Identify Business Objects - Exercise

Before moving on to the next lesson, click the exercise link below to test your skills in identifying business objects and their characteristics. Identify Business Objects - Exercise
[1]attribute: A characteristic of an entity; data that identifies or describes an entity. Usually represented as a column in a table, attributes store data values.

SEMrush Software