SQL Theory: Database Planning

The Database Planning Phase

Get The Database You Want
While Avoiding Costly Mistakes

The Database Planning Phase Is Mission Critical

The Planning Phase for a database project creates a foundation for the final database. The Planning Phase is similar to developing architectural plans for constructing a building and helps ensure that your database project goes smoothly, preventing scope issues and errors while saving you time and expense. The Planning Phase is offered as a separate service because it is absolutely vital to the success of your project. This is especially true for SQL Server with .NET projects or in situations where the requirement specifications are too general in nature to adequately quote an accurate project pricing.

Database Planning Phase: Communication

A successful Database Planning Phase is the result of positive communication between you, our client, and our database developers. We're going be quite blunt about this topic: Database programmers are typically not great communicators, so please bear with us. We will make every effort to communicate in non technical terms. If at any point during a discussion, you do not understand a phrase or term, please ask for a clarification. We will communicate with you either in person, via telephone, email, and shared desktop programs(like GoToMeeting)to get all the information necessary to plan your database project.

Planning Phase: Steps

Purpose For The Database

This determines the overall goals and nature of your database. At this point we find out what you want your database to do for you. This is a general statement; we are not defining individual features at this point. This activity is also referred to as the "Mission Statement" or "Goal Statement" for the database.

Assessing Your Current Database

Here we determine your your current database system, whether it is Microsoft Access, SQL Server, Microsoft Excel, other database applications, or paper forms. Also, we examine what versions of database software are you are currently using.

The Database User Requirements Or Expectations

This answers the question, "Who will be using the database?" and "How many people will be entering and retrieving data during the day?" and "How many people will be using the database simultaneously?" Large numbers of users and many concurrent users will be a determining factor in deciding the the best solution for the database. We also review the potential data volume for the database both in terms of storage size (megabytes or gigabytes?) and the number of records that will be stored (hundreds, thousands, millions?).

Other Planning Phase Topics

• What is the current network, operating system, and software being used, including software that will interface with the database?
• Will this be a stand-alone database,independent of other databases and software within your system?
• Are you planning on the database having Intranet or Internet capability?
• Do you plan to migrate existing data to the new database? If so, are there plans in place or will data migration be part of the overall project?
• What kind of security will be necessary for the database? This includes overall network security and end user rights and privileges.
• Will the database require a User Interface for data entry? A SQL Server database, for example, needs a separate User Interface requiring further development.
• Is database portability a factor; do you need data to interface across multiple operating systems or be available to other programs?
• Who will provide database maintenance? Do you need ongoing services to maintain and upgrade the database as necessary?

Technical Specifications

Solution Design And Architecture Development

Here's where the overall design begins and it ends with a Design Document that consist of system overview, design considerations, architecture strategies and detailed system design. This will be part of what is known as the Functional Specification.

Validating The Project Technology

Is the technology available to develop a solution based on functional requirements? This addresses the issues involved in choosing the right technology for the proposed database project. And example for the technology validation may be "Use Microsoft Access version 2010 User Interface with a SQL Server database data store."

Creating The Functional Specification

The functional specification describes the solution requirements, the database architecture, and the detailed database design for all the features. This could be as simple as listing the number of data entry forms and the number of output reports, along with the overall number of queries necessary for the project. It can also be very advanced, listing each form and the data entry controls, such as text boxes, drop down boxes, radio buttons, navigation buttons, and data entry validation. Reports specifications may also be quite intricate, listing the precise arrangement of output fields, plus any subtotals and totals for the report.

Finalizing The Planning Phase

At this point, the Planning participants will also determine a projected schedule for the development of the database project. This typically includes "milestones", like "Data entry form approval", or "Master report approval". Milestones are not usually set by calendar dates. This is due to the fact that communications between you and the developer may take a few days for discussion, review, approval, and and redesign necessary. The back and forth communications between you and the developer do require time, so we always attempt to plan accordingly. For example, the first review for a data entry form could be ten working days, however, the finalization may take another week, depending upon communications, redesign and preliminary testing.