Home arrow Development Cycles arrow Evaluating a Database

Evaluating a Database

An important part of a software development cycle is anaylsing a database. Julie has written this article to assist a dba to evaluate their database so that it matches the organisation's needs.

Author Info:
By: Julie George
Rating: 3 stars3 stars3 stars3 stars3 stars / 5
June 05, 2003

print this article

An important part of a software development cycle is anaylsing a database. Julie has written this article to assist a dba to evaluate their database so that it matches the organisation's needs.Having worked with most of the databases available on the market today, I am not boasting that I am an expert on all of them, but I sincerely believe that every database can suit a particular organization's needs. An organization on the verge of making a decision for database or software should first do a thorough study of information needs. This article presents some guidelines for that study.

Information today is more important than ever. Smart information is precious. In this age of information overload, I have found it necessary to disregard any information which is not related to my needs, and I am sure that 99% of you do the same.

I want to write about Database Modeling and ER diagramming, but a layman might find that hard to understand. So let me try the simple ways...

To narrow down the requirements of "smart information," avoid the following:

  • Information that is not to the point
  • Duplicate information
  • Erroneous information
  • Abstract information
  • Subjective information

An organization's information can be viewed by the following types of people:

  • Customers (past, present, and future)
  • Evaluators of the organisation, auditors
  • Suppliers
  • miscellaneous creditors
  • miscellaneous debtors
  • Bankers
  • Employees (past, present, and future)
  • Management
  • Other general viewers (external or internal)

These people need to view information of different categories. In order for the organization to provide the requisite information, a systematic study of the information requirements is necessary. When considering information requirements, keep the following features in mind:

  1. Satisfying the related information seeker
  2. Satisfying the related information seeker
  3. Satisfying the related information seeker

If you follow these three magic points -- yes, they are all the same -- you will design the best database for the organization.

When designing databases, keep in mind the features of a good information system:

  1. Make a blueprint (flowchart) of your database flow structure.
  2. Divide the information of the organization into secured and unsecured layers.
  3. Divide the basic database structure to suit different types of information seeker.
  4. Keep a good backup system to avoid crashes
  5. Avoid duplicate data entry system
  6. Allow easy access to unsecured databases related especially to customers
  7. Keep the databases simple. That should be the mantra so that easy debugging of complicated problems is possible.
  8. Archive obsolete information to access it when required.
  9. Categorize your main information seekers

In short, you should have an information system which is robust, flexible, and can be managed even by a layman.

I have seen different types of companies and their needs are different.

  1. Companies which produce and sell the finished products themselves
  2. Companies which are third party merchants who buy and sell on behalf of them
  3. Companies which act as intermediaries between the buyer and sellers
  4. Companies which provide services (airlines, hospitals, etc.)

Influencing factors would be

  • Information size
  • Complexity of the flow of information
  • Security for the information database

If you want the best for your organization, do a thorough analysis of your information requirements and cross-reference these with all the database models available. The database which you think is best matched with your organization is your "investment". Do not compromise your investment because of cost. Best of luck, and happy hunting.

DISCLAIMER: The content provided in this article is not warranted or guaranteed by Developer Shed, Inc. The content provided is intended for entertainment and/or educational purposes in order to introduce to the reader key ideas, concepts, and/or product reviews. As such it is incumbent upon the reader to employ real-world tactics for security and implementation of best practices. We are not liable for any negative consequences that may result from implementing any information covered in our articles or tutorials. If this is a hardware review, it is not recommended to open and/or modify your hardware.

All Development Cycles Tutorials
More By Julie George

blog comments powered by Disqus

- Division of Large Numbers
- Branch and Bound Algorithm Technique
- Dynamic Programming Algorithm Technique
- Genetic Algorithm Techniques
- Greedy Strategy as an Algorithm Technique
- Divide and Conquer Algorithm Technique
- The Backtracking Algorithm Technique
- More Pattern Matching Algorithms: B-M
- Pattern Matching Algorithms Demystified: KMP
- Coding Standards
- A Peek into the Future: Transactional Memory
- Learning About the Graph Construct using Gam...
- Learning About the Graph Construct using Gam...
- Learning About the Graph Construct using Gam...
- How to Strike a Match

Watch our Tech Videos 
Dev Articles Forums 
 RSS  Articles
 RSS  Forums
 RSS  All Feeds
Write For Us 
Weekly Newsletter
Developer Updates  
Free Website Content 
Contact Us 
Site Map 
Privacy Policy 

Developer Shed Affiliates


© 2003-2019 by Developer Shed. All rights reserved. DS Cluster - Follow our Sitemap
Popular Web Development Topics
All Web Development Tutorials