Just as a carpenter has a toolbox of various tools that are used for different purposes, the Business Analyst has a number of tools (or models) that can be used to identify and define business requirements from different aspects.
Entity-Relationship Model (ERM) Originator: Peter Chen
Purpose: To model the conceptual information and relationship based on business rules among the information
Relationship to other tools:
Event Model - identifies the event processes that ensure that the business rules are enforced Class Diagram - is a subset of the ERD and specifies the further breakdown of entities into types or classes (In the case where the relationships apply to only a subset of the entity types, the relationship specification should document this constraint) CRUD Diagram - maps the entities and events to show the intersection noting creation, replacement, updating and deletion of information
Logical Data Model is the transformation of the business information into the technically constrained model required to begin the database design activities, depending on the type of database structure to be utilized The Entity-Relationship Model, as the name implies, includes documentation regarding business entities and relationships. The model itself is composed of the Entity-Relationship Diagram, an Entity Specification, a Relationship Specification and an Attribute Specification. These documents together will fully define and specify the information requirements for a particular effort, either at a project level or as part of the Enterprise Architecture model at the overall-organization level.
By definition, an entity is a “person, place, organization, or thing that is of interest to the business.” The relationship, on the other hand, concentrates on how these entities relate to each other, and the rules that are defined to support those relationships. The following diagram is a very simple example of an Entity-Relationship Diagram: ER Diagram
In addition to a diagram depicting the entities and relationships, there is also the supporting information through the development of specification documents that more completely defines “what” the entity is and the business rules that define how relationships are created, maintained and deleted. These business rules need to be mapped to processes through Event Models to determine when and how these business rules are supported in the organization. This ERM has evolved over the years to be known as a Business Information Model, in order to distinguish it from the Data Model used to design files and databases (see additional information regarding data modeling and the work of CJ Codd). This Business Information Model also supports the three-scheme architecture, as the Conceptual Model of the information needs within a project. The emphasis of this tool should be the business information and not the technical data as the project moves into the design phase. As a result, there are a few additional components that are part of the Business Information Model. Once the high-level business entities and relationships/rules have been identified, the collection of attributes (or individual information that is required for each entity). For example, an entity such as Customer would include attributes of customer name, customer address, customer credit limit. The specific names and definitions of these attributes should be documented like a glossary so that all the team members are “speaking the same language”. Obviously in order to distinguish one customer from another a unique identifier is required. This unique identifier will later be converted to a “key” in the design of the data base (that conversion and decision is dependent on the actual technical requirements of the database software being used). Another database concept that is often referenced on these diagrams pertains to the cardinality (or number of occurrences of each entity in any relationship). This cardinality identifies a one-to-one, one-to-many or many-to-many relationship between the entities. These cardinalities are often identified as part of the definition of the business rules for the relationships but not necessarily shown on the diagram until it is converted into the technical Data Model version. If indeed this diagram is used to model the Business Information it must remain in a format that can be understood, reviewed and approved by the business community, not the technical staff performing data base design. The process of transforming this model to the Logical Data Model has been well-defined and practiced by data base analysts for years.
