QUALITY SYSTEM DOCUMENTATION

Database Design Checklist

September 2006

Document Name Database Design Checklist Version.Rev 1.00

Authorized by Rajesh Sharma Date Sep 25th, 2006

Organization Wide Ver. Rev. 1.00 1

QSD/REF/CHECKLIST/ENGG/LC/DB DESIGN CHECKLIST
 COPYRIGHT NOTICE

This Quality System Documentation is the property of Kalinga Software Private Limited (Kalingasoft). All
ideas and information contained within these documents are the intellectual property rights of Kalingasoft.
These documents are not for general distribution and are meant for use only for the person they are specifically
issued to. These documents shall not be loaned to anyone, within or outside Kalingasoft, including its
customers. Copying or unauthorized distribution of these documents, in any form or means including electronic,
mechanical, photocopying or otherwise is illegal.

Kalinga Software Private Limited

Regd. Office: 466, Sree Vihar, Patia, Bhubaneswar, Orissa, India -751031
Telephone: +91-674-3201556
Fax: +91-674-2741689
Website: http://www.kalingasoft.com
Mail to: kalingasoft@kalingasoft.com

Organization Wide Ver. Rev. 1.00 2

QSD/REF/CHECKLIST/ENGG/LC/DB DESIGN CHECKLIST
 REVISION HISTORY

Ver. Date Author Reviewed Date Description

by
0.00a Sep 21, 2006 Rajesh Original Document
1.00 Sep 25, 2006 Rajesh

Organization Wide Ver. Rev. 1.00 3

QSD/REF/CHECKLIST/ENGG/LC/DB DESIGN CHECKLIST
1. PROCESS CHECKLIST

Description Y/N Remarks

Have you understood this document in its entirety to the
minutest details?
If you have not understood, ask questions and clarify each
and everything.
Define/adapt Detailed design standards (This checklist is the
standard)
Understand the functionality and URS
Identify entities and relationships
Draw logical E-R Diagram (Erwin/SQL Server diagram)
Do normalization upto 3rd level (Section-2)
Translate entities and relationships into tables/record types
Draw Physical E-R Diagram (Erwin/SQL Server diagram)
Study the impact of the chosen physical database on the
database design
Perform controlled denormalization (Only where required)
Create a Physical database-URS cross-reference (in HLD)
Determine indexes
Perform database sizing(Tables and Indexes. Refer section-4
)
Document Physical database architecture
Document the business significance of Tables and columns
in the Physical database (HLD / Erwin)
Review Physical database architecture document internally
Log any defects found (either during internal review or
testing)

2. DESIGN CHECKLIST

Description Y/N Remarks

Do the entities and relationship reflect the real life scenario
for the project?
Has the flexibility and maintainability been considered
while selecting the entities and relationships?
Is there no table without a primary key?
Do all columns have datatypes, length and precision as per

Organization Wide Ver. Rev. 1.00 4

QSD/REF/CHECKLIST/ENGG/LC/DB DESIGN CHECKLIST
Description Y/N Remarks
the context reality and future maintainability and flexibility?
Is the selection of primary keys of every table correct?.
If an identity column is defined as primary key of a master
table then a unique not null constraint should also be
defined on the column that is the unique identification of the
entity in the real-world context. Is it followed?
In any transaction table’s identity key can’t be a primary
key. Is it followed?
If any transaction table’s identity key is Primary Key then it
need a unique key (not null) constraints as composite
primary key. (may/may not be composite depending upon
the situation). Is it followed?
Are all interrelated table related with the right Foreign Key
that depicts their relationship as per real life scenario of the
context of the project?
Is the E-R Diagram upto 3rd level of normalization?
A field is a fact about a particular subject (the field contain
one piece of data)?

Fields in a database should be fully functionally dependent

on the primary key.

All non-key fields should be mutually independent. For

example, a calculated field should not be stored. (Note:
sometimes this rule must be violated for performance
reasons. But try avoiding it)

There should be separate tablespaces (for oracle only) for

user data corresponding to different schemas. Is it followed?
Table should not be created in system table space (for oracle
only). Is it followed?
There should be separate tablespaces (for oracle only) for
user data corresponding to different schemas. Is it followed?
There should be separate tablespaces (for oracle only) for
indexes corresponding to tables in different schemas. Is it
followed?
Index should be created on frequently used fields. Care must
be take it should not be many. Is it followed?
Indexes should be placed in separate tablespace from the
tablespace for tables (for oracle only)
Control files should be placed in different hard drives. (for
oracle only)
Is every information required coming from the database?
Default value is used whereever it applicable.?

Organization Wide Ver. Rev. 1.00 5

QSD/REF/CHECKLIST/ENGG/LC/DB DESIGN CHECKLIST
Description Y/N Remarks
Not null constraints are put wherever applicable?
Check constraints wherever applicable?
Do check constraints reflect the domain integrity of the
data?
TABLE NAMING STANDARDS
The table name clearly identifies the one type of data the
table contains?
Are Table names plural (usually)?
Are all table names prefixed with T_
Are all indexes prefixed wit I_<Table name short
form>_<column name1 short form>_<column name2 short
form>…
Functional table names (for many-to-many relationships)
should be a combination of the two tables referenced. For
example, T_Subprojects_T_Documents indexes the many-
to-many relationship between Subprojects and Documents.
Is it followed?
COLUMN NAMING STANDARDS
Column names should be descriptive and clearly
understandable by someone who looks
at them for the first time. Is it followed?
Column names should contain letter, number, and
underscore characters (“_”) only. Is it followed?
The primary key column should always end with “ID”
(Usually).

All relationships to a primary key must not have referential

intergrity with cascade update/delete. Is it followed?
A column referencing a primary key field in another table
should have exactly the same
name and datatype as the field it is referencing. Is it
followed?
If multiple columns in a table reference the same primary
key in another table, the column names should be followed
by a suffix. (Example: BankID_from BankID_to). Is it
followed?
Abbreviations for column names should be avoided. An
exception is when the table name contains or more words,
the initials of each word may be used, for any column
except the Primary Key field, and the description field. For
example, if the table name is “T_FacilitatingPartners”, a
field may be named “FP_Name”. The Primary Key
would be “Facilitating_Partner_ID”. Is it followed?
Composite keys should preferably not be used. If necessary,

Organization Wide Ver. Rev. 1.00 6

QSD/REF/CHECKLIST/ENGG/LC/DB DESIGN CHECKLIST
Description Y/N Remarks
use a composite index instead. Is it followed?
Field names should be unique throughout the database.
PHYSICAL SIZING
Refer section 4. Is the procedure followed and
implemented?
DATABASE OBJECT NAMING
Refer section 3. Are the naming conventions followed?

3. DATABASE OBJECT NAMING CONVENTIONS

Object Name Convention

Table Should be meaningful
Should Start with a “T_”
Column name should be in Hungarian notations.
Column name should start with three letters of data type.
Fields which is not taking part in calculation should be varchar
data type
View Should be meaningful
Should Start with a “V_”
Trigger Should be meaningful
Should Start with a “Tr_”
Stored Procedure Should be meaningful
Should Start with a “Sp_”
Functions Should be meaningful
Should Start with a “Fn_”
Packages Should be meaningful
Should Start with a “Pk_”

4. TABLE AND INDEX SIZING

™ Calculate the size of one record.

™ Minimum number of records, to be stored initially.
™ Percentage of growth in one year.
™ Maximum size of table and indexes (considering a 10 year time period)
™ Determine physical table and size calculations
o Specific to Oracle Points
ƒ Define initial extent, next extent, pctincrease, pctfree etc.
ƒ All the above definitions should be a integral multiples of
DB_BLOCK_SIZE

Organization Wide Ver. Rev. 1.00 7

QSD/REF/CHECKLIST/ENGG/LC/DB DESIGN CHECKLIST