Scribd
Upload
75 views2 pages

Relational DB Checklist

The document outlines the steps for developing a relational database, including understanding user needs, translating those needs into data models, extracting business rules through two optimization phases involving normalization, and other considerations like architecture, documentation, and testing. The goal is to design a database that meets user requirements while following best practices for structure, naming, and performance.

Uploaded by

GabrielHolandini
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
75 views2 pages

Relational DB Checklist

The document outlines the steps for developing a relational database, including understanding user needs, translating those needs into data models, extracting business rules through two optimization phases involving normalization, and other considerations like architecture, documentation, and testing. The goal is to design a database that meets user requirements while following best practices for structure, naming, and performance.

Uploaded by

GabrielHolandini
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 2

Relational DB Checklist

 Understanding User Needs


 Bring a List of Questions (Record Meetings)
 Identify Key Players and their positions in the company
 Identify Data Integrity and Security Priorities
 Walk a Mile in User’s Shoes
 Brainstorm (Rough Sketches, Relations, Ideas)
 Verify Understanding and Make Use Cases
 Compile List of Required Tools, Infrastructure and Costs Associated
 Establish Rough Timeline and Checkpoints

 Translate User Needs to Data Models


 Design High Level User Interface (What data must be displayed in what form)
 Design Semantic Object Model (Constantly Check with Team)
 Build Entity-Relationship diagrams
 Study Entities Involved in the Problem
 Examine Interactions among Entities
 Convert Semantic Object Models and Entity-Relationship Diagrams into Relational Models
 Build Entity-Relationship diagrams, to study the entities that are involved in the problem

 Optimization Phase I: Extract Business Rules


 Write Down All Business Rules
 Extract Key Business Rules
 Identify required fields and other field-level constraints that are unlikely to change
 Identify sanity checks that are unlikely to change
 Identify rules that are more complicated or likely to change in the future
 Re-design the ER diagram with updated changes

 Optimization Phase II: Normalization and Refinement


 Verify First Normal Form (1NF)
 Each Column Must Have Unique Name
 The Order of Rows and Columns Does not Matter
 Each Column Must Have a Single Data Type
 No Two Rows Can Contain Identical Values
 Each Column Must Contain a Single Value
 Columns Cannot Contain Repeating Groups
 Verify Second Normal Form (2NF)
 It is in 1NF
 All of the Non-Key Fields Depend on All of the Key Fields
 Verify Third Normal Form (3NF)
Page 2

 It is in 2NF
 It Contains no Transitive Dependencies
 Check Boyce-Codd Normal Form (BCNF)*
 It is in 3NF
 Every Determinant is a Candidate Key
 Fourth Normal Form (4NF)*
 It is in BCNF
 It Does Not Contain Unrelated Multi-Valued Dependency
 Fifth Normal Form (5NF)*
 It is in 4NF
 It Contains no Related Multi-Valued Dependencies
 Domain / Key Normal Form (DKNF)* Optional
 The Table Contains no Constraints except Domain Constraints and Key Constraints

 Other Things To Consider


 Consider Multi-Tier Architecture
 Keep Tables Focused
 Check Naming Conventions With Development Team
 Maintain Proper Documentation for Any Change Associated
 Review Common Design Patterns For:
 Many-to-Many Associations
 Multiple Object Associations
 Repeated Attribute Associations
 One to One Reflexive Associations
 One to Many Reflexive Associations
 Hierarchical Data
 Network Data
 Temporal Data

 Beware Of:
 Poor Documentation
 Poor Naming Standards
 Lack of Planning for Changing Features
 Too Much / Too Little Normalization
 Testing (Try To Find All Bottlenecks and bugs)
 Lack of Planning for Changing Features
 Too Much / Too Little Normalization
 Testing (Try To Find All Bottlenecks and bugs)
 Lack of Proper Constraints
 Not Defining Natural Keys
 ID Obsession

You might also like