Database Normalisation #made easy

You might learn databases in your academics, you heard and read the term normalization but probably we might not apply normalization in practical. Please go thru my practical approach on Database Normalization. This article is not yet completed completely but here is some of the stuff to you…………

 

What is Normalization?

Normalization is a process of efficiently organizing the data in a database. In another way normalization is a rule to be applied on the Database and get more benefits.

Normalization is “designing the Database in a structural format.”

 

Goals of Normalization:

The primary goals of the normalization is

1.       Eliminating redundant Data

2.       Make sure that the database dependencies make sense ( Relation between database are viable)

 

Benefits of achieving the Primary goals of Database Normalization

 

There are so many benefits once you have applied normalization on Database. More precisely you come to know the actual benefits only you have practical experience on the Normalized and De Normalized Database. But I can explain you the maximum number of benefits during my entire article on Database Normalization.

Some of the benefits are

 

1.       Reduce the amount of space that the Database consumes

1.       Make the Database design easy

2.       Make the Database easier to maintain

3.       Make sure the Database is in structural way

4.       Prevents the Database from various update anomalies which can occur in un  normalized Databases

5.       Preventing the need to restructure existing tables to accommodate new data

6.       Enable record processing by simple operators

7.       Less null values and less redundant data, making your database more compact.

8.       Triggers execute more quickly if you are not maintaining redundant data

9.       Increased speed and flexibility of queries, sorts, and summaries.

 

 

    [I will back with more stuff (Stay Tuned….)]

My coming articles...

Hi Guys,

I want to educate the new software engineers by giving valuable stuff in my blog. Please leave your comments after reading any of the articles, so that I will try to give more valuable stuff.

My Coming Articles are

• ·         Database Normalization #made easy
  
• ·         Software Development Phases #made easy
  
• ·         Software Development Models #made easy
  
• ·         Object Oriented Approach and Modeling #made easy
  
• ·         Three tier architecture #made easy
  
• ·         Software Project Development #made easy
  

   (Stay Tuned...........)

 

SQL Server Date is very simple

Hi Guys,
Working with DateTime in SQL Server is very simple here is the the tip
Insert Date In SQL Server Table:

Create Table DateTable( DateColumn varchar(8)) go
/* Inserting the test value into the table */
insert into DateTable select '19780129'
insert into DateTable values ('January 1, 2000')
insert into DateTable values (getdate()) – getdate() means current date

To Enter Dates in different styles Microsoft Has provided some style codes
(Stay Tuned)

The basic SDLC Documents

Definitions

SDD : Software Design Document. Contains the design description and the list of design entities required for a project.

FSD : Functional Specification Document. Lists the detailed specifications of the project.
Purpose of the Documents:
This Design Methodology is used to guide the design team into producing a viable and accurate Software Design Document (SDD) while, at the same time, describing the process to be used by the design team and defining the required contents of the SDD. The main purpose of the SDD is to ensure that the final product the customer receives fulfils the entire customer requirements defined in the FSD. The development team leader, who will be required to make sure the project is completed according to the FSD, SDD and software development plan, will need to have a method of keeping track and documenting project development information.This document will also define the contents of a Development Workbook. The Development Workbook will define the information that the team leader will be required to keep track of and the order that information is presented.
Software Design Document: The main purpose of the SDD is to ensure that the final product the customer receives fulfils the entire customer requirements defined in the FSD. The SDD also sets a guideline of required information that will help ensure that the project is a success. Depending on the size and scope of the project, not all sections of the SDD will be required. However, if the section is not applicable to the given project, then the section heading must be included with a NOT APPLICABLE requirement. Some of the areas that an SDD will consist of are itemized below;
Definition of the project
High Level System Design
Relationship to other Projects
Project Responsibility
Project Phases
Project Environment
Design Entities
Development Phases
Analysis of Potential Problems
Detailed Design
Requirements Traceability Matrix
Team Structure and Responsibility
Development Project Plan
Decomposition of FSD
The objective of the FSD decomposition is to review the FSD and based on the information provided, divide the system into separate components that can be considered, developed, changed and tested with a minimal effect or dependency on the other components. These components are called entities. The entities may be an entire system, a sub system, a module, a program, a set of programs, user interfaces or data-stores depending on the complexity and the programming environment. The design team will determine which of the requirements to group as an entity.
SDD Design Process
The first step in creating an SDD is to take the FSD and break out the objectives, requirements and entities that the customer needs and then look for informal requirements, preconceived solutions and any specific hardware or software requirements. After this is completed, the design team needs to consider if there are any design issues that need be addressed specifically by the design team. If not the design of the first level entities will be assigned to the individual programmers. In many cases the actual design of the entity will be assigned to the programmers. The SDD would address specific program design issues is only when it effects the system architecture or is required to address a specific customer requirement or performance issue.

Informal Requirements
Determine what requirements are implied but not formally listed. The FSD may refer to a particular module, service or entity, but there may be supporting entities required that are not listed.If any informal requirements are detected, they will be added to the SDD as entities and noted that this is an informal entity.Determine Preconceived Solutions
Determine if any requirements are actually solutions and not requirements. Review the SDD to make sure the design has not been preconceived and verify with the project manager if this was intentional and part of the actual FSD or not. The design may be the correct one to use, but you want to be sure of what is actually a requirement and what is not.
Design Review Process
Design reviews are performed during the design stage, but may take place during the development, verification and validation of the software if the team leader or management determines that one is needed. Design Review
The design review will consist of an informal review of the design by the design team (or appointed representative) and may include other members of the software development group.The members of the design review need to identify the following:
What kind of review is it. Is this a design document review, a code walkthrough review, a post project design review?
Who is present at the review
Decisions made at the design review meeting
Follow up required from the design review meeting
Status of pass or fail on the design review meeting
The development team leader or appointed scribe will record the activities to be done and the decision made in the meeting. These records are retained as part of the project in the product development binder, but are not quality records.Critical Design Review
A critical design review (CDR) will take place some time after the design review. The CDR will be conducted by the Design Review Team, which will consist of the development team leader (or appointed representative), a representative from Sales and Marketing, a representative from Professional Services and any specialist that may be required. The CDR will discuss:
Decisions made at the CDR meeting
Follow up required from the CDR meeting
Status of pass or fail on the design review meeting
The conclusions and directives of the CDR will be recorded and retained as quality records.