Modeling rules process in organization

types of business rules structure of Lecture

4
business rules, constraints, types of keys
Prepared by: Rabbia
(primary key, composite key, surrogate Basharat

key and foreign key)

 Modeling Rules Process in
an Organization
Definition:
Modeling rules in an organization means defining business rules that control how
processes, decisions, and data management should work. These rules help maintain
consistency, compliance, and efficiency in operations.
Example:
In a university, students must complete 120 credit hours to graduate.
In a bank, a customer cannot withdraw more money than available in their
account.
These rules must be enforced consistently across the organization's systems,
including databases, workflows, and business processes.
2. Scope of Business Rules
Business rules can be applied to different areas of an organization:

Scope Example

Employee working hours: 9 AM – 5

Operational Rules
PM

Regulatory Rules Taxes must be filed before April 15

Orders above $500 get a 10%

Decision-Making Rules
discount

Leave applications require

Process Rules
manager approval
3. Types of Business Rules
Organizations implement business rules in different ways :
Type Description Example
A student must be at
Constraint Rules Define limits
least 18 to register.
Ensure correct data Phone number must
Validation Rules
entry be 10 digits.
Trigger specific If stock < 5, reorder
Action Rules
actions automatically.
Total price = quantity
Derivation Rules Calculate values
× unit price.
Leave request must
Workflow Rules Control processes
be approved by HR.
4. Structure of Business Rules
Business rules can be represented in various formats:

Structure Example
If an order exceeds $1000, then
IF-THEN Statements
apply a 15% discount.
Table format with conditions and
Decision Tables
outcomes.
Rule Flow Diagrams Visual representation of rules.
"Employees must work 40 hours
Natural Language Statements
per week."
5. Business Rules and Database Constraints
.
Constraint Function Example
Ensures a field is not A customer must
NOT NULL
empty. have an email.
Ensures no Employee ID must be
UNIQUE
duplicates. unique.
Uniquely identifies a Order_ID in the
PRIMARY KEY
record. Orders table.
Order references a
FOREIGN KEY Links two tables.
Customer.
CHECK Restricts values. Age must be >= 18.
Assigns a default Default country =
DEFAULT
value. "USA".
6. Types of Database Keys
Keys help organize and secure data in a structured
way.
Key Type Function Example
Unique identifier for a Student_ID in
Primary Key
record. Students table.
Uses two or more Order_ID +
Composite Key fields as a unique Product_ID in
identifier. OrderDetails.
System-generated Auto-incremented
Surrogate Key
key. Employee_ID.
Establishes Customer_ID in
Foreign Key relationships Orders links to
between tables. Customers.
7. Real-World Example
E-commerce Business Rules
1.Customers must register before placing an order.
✅ Enforced using NOT NULL for email in the Customers table.
2.Products must be in stock before they can be purchased.
✅ Enforced using a CHECK (Stock > 0).
3.Each order must belong to a valid customer.
✅ Enforced using FOREIGN KEY (Customer_ID) REFERENCES
Customers(Customer_ID).
 DATABASE DEVELOPMENT
PROCESS
Daťabasc Dcvclopmcnť Proccss
o The database development process is a systematic approach to designing,
creating, and maintaining a database system to meet the data
management needs of an organization or application
o It involves several phases and activities to ensure that the database is
well-designed, efficient, secure, and reliable
o Below are the typical stages in the database development process:
1. Rcquircmcnťs Analysis:
 Identify and document the data requirements of the organization or
application
 Interview stakeholders to understand their data needs, constraints, and
objectives
 Define the scope of the database project, including the data to be
stored and the functionality required
 DATABASE DEVELOPMENT
2.PROCESS
Conccpťual
Dcsign:
 Create a high-level, abstract representation of the database
structure, known as the conceptual schema
 Identify entities, attributes, and relationships between data
elements
 Use
conceptual
techniques like Entity-Relationship
schema
Diagrams (ERDs) to model the
3. Įogical Dcsign:
Translate the conceptual schema into a more detailed logical
schema
 Specify the tables, fields, and data types for each entity
 Define primary keys, foreign keys, and constraints to ensure data
integrity
 Normalize the database to minimize data redundancy and
improve data consistency
 DATABASE DEVELOPMENT
4.PROCESS
Schcma Implcmcnťaťion:
 Write the Data Definition Language (DDL) statements to create
the database schema
 Define indexes, views, and other database objects as needed
 Set up data integrity rules and constraints
 Configure access control and security settings
5.Physical Dcsign:
 Determine how the data will be physically stored on storage
devices
 Consider factors like file organization, indexing methods,
partitioning, and clustering to optimize performance
 Choose appropriate hardware and storage technology
 DATABASE DEVELOPMENT
PROCESS
6.Implcmcnťaťion:
 Create the database and populate it with the
initial data from various sources
 This involves writing SQL scripts or using visual tools to create
tables, define relationships, and set up any necessary security
settings
 Verify data accuracy and consistency
7.Tcsťing and Qualiťy Assurancc:
 Perform thorough testing to ensure that the database functions
correctly and meets the specified requirements
 This includes testingdata integrity, data retrieval
and manipulation operations, and handling of concurrent
users
 DATABASE DEVELOPMENT
8.PROCESS
Dcploymcnť:
 Install the database in production environment, ensuring proper
configuration and integration with other systems or
applications
 This may involve data migration from an existing database or
system
9. Mainťcnancc and Opťimizaťion:
 Continuously monitor and tune the database performance,
address any issues or bugs, and incorporate changes or
enhancements based on user feedback or evolving
requirements
10.Documcnťaťion and Training:
 Create documentation for the database schema, data
dictionaries, and application interfaces
 Provide training to users and administrators on database
usage and maintenance
 DATABASE DEVELOPMENT
PROCESS
Backup and Rccovcry Planning:
11.
 Develop and implement backup and recovery strategies to
safeguard data in case of system failures or data loss
o It's important to note that the above steps are not always strictly
sequential and may overlap or iterate depending on the specific
project requirements and development methodology used
Difference Between Database Development Modeling and Business
Rules Modeling
Both Database Development Modeling and Business Rules Modeling are crucial for
designing robust systems, but they focus on different aspects of data management
and process control.

Concept Definition
The process of designing a
Database Development structured database that defines
Modeling tables, relationships, constraints,
and data integrity rules.
The process of defining the
policies, conditions, and logic that
Business Rules Modeling
govern an organization’s
operations and decision-making.
GRAPHICAL TOOLS
USED IN DATABASE Lecture
5
DEVELOPMENT Section-II
Prepared by: Rabbia
PROCESS Basharat
 GRAPHICAL TOOLS
o Tools are used for describing the design process in standard ways
o There are main two types of graphical tools used in database
development process
o These are Data Flow Diagram (DFD) and Entity Relationship Diagram
(ERD)
 GRAPHICAL TOOLS
Daťa Ilow Diagram (DID)
o DFD is a graphical representation of how data flows within a system
or process
o A DFD illustrates the movement of data between various entities,
processes, data stores, and external systems
o A DFD has the following main four components:
1. Proccss
 A process represents a specific action or operation that takes place
within the system
 data)
It transforms incoming data flow (input data) into outgoing data
1. 1.
flow (output
 Represented 0 O 0
Proces Proces
as s R s
 GRAPHICAL TOOLS
2. Daťa Ilow
 Data flows are arrows representing the movement of data
between various components of the system
 They show how data is input, stored, processed, and output within
the system
 Data flows can be labeled to describe the type of data being
transferred

3. Daťa Sťorc
 A data store represents a storage location where data is stored
within the system
 It can be a database, file, or any other form of persistent storage
 GRAPHICAL TOOLS
4. Exťcrnal Enťiťy
 An external entity represents an external system, user, or
organization that interacts with the system but is outside
the boundary of the system being modeled
 It represents source or destination of the data
 External entities are usually depicted as rectangles

5. Collccťor
 Several data flows combine here
 No processing occurs here
 GRAPHICAL TOOLS
6. Scparaťor
 Several data flows split from
here
 No processing

7. Ring-sum opcraťor
 Shows two possible data
flows
 Only one is followed

8. AND opcraťor
 Shows two data flows
 Both are followed
 GRAPHICAL TOOLS
Typcs of DID
o The following are main types of Data Flow Diagrams (DFDs)
commonly used in system analysis and design
1. Context diagram
2. Level 0 diagram
3. Detailed diagram
 GRAPHICAL TOOLS
Conťcxť Įcvcl DID (Conťcxť Diagram)
o A Context Level Data Flow Diagram (DFD) is a high-level
representation of a system or process that shows how it interacts
with external entities
o It provides an overview of the system's boundaries, major inputs,
outputs, and the interactions between the system and
external entities
o Context Level DFDs are typically used in the early stages of system
analysis and design to understand the scope and context of a
system before diving into more detailed DFDs
o It has no datastores
o Some writer has considered context level and level 0 DFD same
o Some considered the next level as Level-0 DFD
GRAPHICAL TOOLS
 GRAPHICAL TOOLS
Įcvcl-1 DID
o A Level-1 Data Flow Diagram (DFD) is the next level of
refinement after a Context Level DFD (Or Level-0 DFD)
o Level-1 DFD breaks down the system into more detailed processes
and data flows
o It's a useful tool for getting a deeper understanding of how the
system operates while still maintaining a high-level view
o Level-1 DFD can be further expanded into Level-2, Level-3, etc. DFDs
 GRAPHICAL TOOLS
Dcťail Įcvcl DID
o This Type of the Data flow diagrams are used when we have to
further explain the functionality of the processes that we showed
briefly in the previous Level Diagram
o The detailed DFD is an optional thing. You may need the detailed
DFD in some system or may not
o Mainly this type of DFD is needed in system that are very large
o It show processes in successive levels of detail
o It also shows major sub-processes
o Processes are numbered in each level of DFD as 1.1, 1.2, 1.1.2,
etc… shows internal details for each major sub-process
 GRAPHICAL TOOLS
Somc Rccommcndaťion
o Limit number of process to 7 to 9 per page/diagram
for clarity.
o All elements must be named
o All process have both inputs and outputs
o Outputs must differ from inputs
o Child diagrams and parent process must have same
input/output
THANK
YOU