Mapa mental
3.0 CONCEPTUAL DESIGN
Contenido del mapa
3.0 CONCEPTUAL DESIGN
3.1 ER Modelling
- Business Rules
- Definition
- A business rules is a brief, precise, and unambiguous description of a policy, procedure, or principle within a specific organization
- Business rules derived from a detailed description of an organizations operations help to create and enforce actions within that organizations environment
- Properly written business rules are used to define entities, attributes, relationships, and constraints
- Any time you see relationship statements such as "an agent can serve many customers and each customer can be served by only one agent,"business rules at a work
- Business rules must be easy to understand and widely disseminated to ensure that every person in the organization shares a common interpretation of the rules
- Business rules describe, in simple language, the main and distinguishing characteristics of the data as viewed by the company
- Example
- A customer may generate many invoices
- An invoice is generated by only one customer
- A training session cannot be scheduled for fewer than 10 employees or for more than 30 employees
- Why Business Rules?
- It helps to standardize the company's view of data
- It can be a communication tool between users and designers
- It allows the designer to understand the nature, role, and scope of the data
- It allows the designer to understand business processes
- It allows the designer to develop appropriate relationship participation rules and constraints and to create an accurate data model
- Translating Business Rules into Data Model Components
- As a general rule, a noun in business rule will translate into an entity in the model, and a verb(active or passive) that associates the nouns will translate into a relationship among the entities
- For example, the business rule" a customer may generate many issues" contains two nouns (customer and invoices) and a verb (generate) that associates the nouns
- From this business rule, you could deduce the following:
- Customer and invoice are objects of interest for the environment and should be represented by their respective entites
- There is generate relationship between customer and invoice
- To properly identify the type of relationship, you should consider that relationships are bidirectional that is they go both ways
- For example, the business rule " a customer may generate many invoices" is complemented by the business rule "an invoice is generated by only one customer"
- In that case, the relationship is one-to-many (1:M)
- Customer is the "I" side, and invoice is the "many" side
- Generally, to properly identify the relationship type you should ask two questions
- How many instances of B are related to one instances of A?
- How many instances of A are related to one instances of B?
- Example 1
- You access the relationship between student and class by asking two questions:
- In how many classes can one student enroll?
- many classes
- How many students can enroll in one class?
- many students
- In how many classes can one student enroll?
- You access the relationship between student and class by asking two questions:
- Example 2
- You can access the relationship between employee and company for by asking two questions
- How many company cars can one company car be assigned?
- one company car
- How many employees can be one company car be assigned to?
- one employee
- The relational between employee and company car is one-to-one(1:1)
- How many company cars can one company car be assigned?
- You can access the relationship between employee and company for by asking two questions
- Summary
- Business rules can be translated into data model components based on the following rules:
- Nouns translate into entites
- Verbs translate into relationships among entities
- relationships are bidirectional
- Business rules can be translated into data model components based on the following rules:
- Definition
- Relationship and Connectivity
- Definition
- Association between entities that always operate in both directions
- Participation
- Entities that participate in relationship
- The relationship name is in active or passive verb
- Connectivity
- Describe the relationship classification
- Classification includes 1:1, 1:M, and M:N
- Describe the relationship classification
- Cardinality
- In the ERD, cardinality is indicated by placing the appropriate numbers beside the entities, using the format (x,y)
- definition
- Express the minimum and maximum number of entity occurences associated with one occurence of related entity
- The first value (x) represent the minimum number of associated entities
- The second (y) represent the maximum number of associated entities
- Relationship Participation
- Participation in an entity relationship is either optional or mandatory
- Optional participation
- Definition
- One entity occurence does not require a corresponding entity occurence in a particular relationship (verb: may, can)
- Definition
- Mandatory participation
- Definition
- one entity occurence must have a corresponding occurence in another entity (verb: must)
- Definition
- Associative (omposite) Entities
- Used to represent an M:N relationship between two or more entities
- It is also called a composite or bridge entity and is a 1:M relationship with the parent entities
- It is composed of the primary key attributes of each parent entity
- The composite entity may also contain additional attributes that play no role in connective process
- Developing an ER diagram
- Steps to develop ERD
- Identify the business rules based on the description of operations
- List all the entities based on given scenario
- List all the attributes for each entity
- Assign Primary Key (PK) for each entity
- Draw line to show relationship between all entities
- Specify connectivity between entities
- Steps to develop ERD
- Definition
- Business Rules
Información
- Descripción
- Mapa Mental sobre 3.0 CONCEPTUAL DESIGN, creado por amir supaniba el 18/09/2025.
- Creado por
- amir supaniba · sep 2025
- Actualizado
- 18 sep 2025
- Visitas
- 1
- Valoración