Normalization with Examples

Normalization with Examples

Normalization is the process of organizing data in a database.

This includes creating tables and establishing relationships between those tables according to rules designed both to protect

the data and to make the database more flexible by eliminating redundancy and inconsistent dependency.

Redundant data wastes disk space and creates maintenance problems.

If data that exists in more than one place must be changed, the data must be changed in exactly the same way in all locations. A customer address change is much easier to implement if that data is stored only in the Customers table and nowhere else in the database.

What is an "inconsistent dependency"? While it is intuitive for a user to look in the Customers table for the

address of a particular customer, it may not make sense to look there for the salary of the employee who calls on that customer.

The employee's salary is related to, or dependent on, the employee and thus should be moved to the Employees table.

Inconsistent dependencies can make data difficult to access because the path to find the data may be missing or broken.

First Normal Form

Eliminate repeating groups in individual tables.

Create a separate table for each set of related data.

Identify each set of related data with a primary key.

Do not use multiple fields in a single table to store similar data. For example, to track an inventory item that may come from two

possible sources, an inventory record may contain fields for Vendor Code 1 and Vendor Code 2.

What happens when you add a third vendor? Adding a field is not the answer; it requires program and table modifications and

does not smoothly accommodate a dynamic number of vendors. Instead, place all vendor information in a separate table called Vendors,

then link inventory to vendors with an item number key, or vendors to inventory with a vendor code key.

Second Normal Form

Create separate tables for sets of values that apply to multiple records.

Relate these tables with a foreign key.

Records should not depend on anything other than a table's primary key (a compound key, if necessary).

For example, consider a customer's address in an accounting system. The address is needed by the Customers table, but also by the Orders,

Shipping, Invoices, Accounts Receivable, and Collections tables. Instead of storing the customer's address as a separate entry in each

of these tables, store it in one place, either in the Customers table or in a separate Addresses table.

Third Normal Form

Eliminate fields that do not depend on the key.

Values in a record that are not part of that record's key do not belong in the table. In general, any time the contents of a group

of fields may apply to more than a single record in the table, consider placing those fields in a separate table.

For example, in an Employee Recruitment table, a candidate's university name and address may be included. But you need a complete list

of universities for group mailings. If university information is stored in the Candidates table, there is no way to list universities

with no current candidates. Create a separate Universities table and link it to the Candidates table with a university code key.

EXCEPTION: Adhering to the third normal form, while theoretically desirable, is not always practical.

If you have a Customers table and you want to eliminate all possible interfield dependencies,

you must create separate tables for cities, ZIP codes, sales representatives, customer classes, and any other factor that may be

duplicated in multiple records. In theory, normalization is worth pursing. However, many small tables may degrade performance or

exceed open file and memory capacities.

Other Normalization Forms

Fourth normal form, also called Boyce Codd Normal Form (BCNF), and fifth normal form do exist, but are rarely considered in practical

design. Disregarding these rules may result in less than perfect database design, but should not affect functionality.

For More Information Click

http://support.microsoft.com/kb/283878

Partial Class in C#

Partial Class in C#
It is possible to split the definition of a class or a struct, or an interface over two or more source files. Each source file contains a section of the class definition, and all parts are combined when the application is compiled. There are several situations when splitting a class definition is desirable:
When working on large projects, spreading a class over separate files allows multiple programmers to work on it simultaneously.
When working with automatically generated source, code can be added to the class without having to recreate the source file. Visual Studio uses this approach when creating Windows Forms, Web Service wrapper code, and so on. You can create code that uses these classes without having to edit the file created by Visual Studio.
Example for Partial Classpublic partial class Employee{ public void DoWork() { }}
public partial class Employee{ public void GoToLunch() { }}
At compile time, attributes of partial-type definitions are merged. For example, the following declarations:

Systems Development Life Cycle (SDLC), or Software Development Life Cycle

Systems Development Life Cycle (SDLC), or Software Development Life Cycle

Uses of SET XACT_ABORT in Sql Server

Uses of SET XACT_ABORT in Sql Server

When SET XACT_ABORT is ON, if a Transact-SQL statement raises a run-time error, the entire transaction is terminated and rolled back.

When SET XACT_ABORT is OFF, in some cases only the Transact-SQL statement that raised the error is rolled back and the transaction continues processing. Depending upon the severity of the error, the entire transaction may be rolled back even when SET XACT_ABORT is OFF. OFF is the default setting.

Compile errors, such as syntax errors, are not affected by SET XACT_ABORT.

other SET statement in Sql Server

Click here

SSMS Tools Pack Free Download Used in Sql Server 2008 and R2

SSMS Tools Pack MUST be installed with elevated admin privileges

Sql Server Tools

Go to link

Click here to Download tool

Collections in Dotnet Framework

Collections in Dotnet Framework

Why Use Collections in dotnet?


-Individual elements serve similar purposes and are of equal importance.
-The number of elements is unknown or is not fixed at compile time.
-You need to support iteration over all elements.
-You need to support sorting of the elements.
-You need to expose the elements from a library where a consumer will expect a collection type.

Collections can vary, depending on how the elements are stored, how they are sorted, how searches are performed, and how comparisons are made. The Queue class and the Queue generic class provide first-in-first-out lists, while the Stack class and the Stack generic class provide last-in-first-out lists. TheSortedList class and the SortedList generic class provide sorted versions of the Hashtable class and the Dictionary generic class. The elements of a Hashtable or a Dictionary are accessible only by the key of the element, but the elements of a SortedList or a KeyedCollection are accessible either by the key or by the index of the element. The indexes in all collections are zero-based, except Array, which allows arrays that are not zero-based.

Singleton Class in C# with Example

Singleton class in C#

What is Singleton class?
- A class that has only one instance, and you need to provide a global point of access to the instance.

How to achieve Singleton class?
Singleton provides a global, single instance by:
1. Making the class create a single instance of itself.
2. Allowing other objects to access this instance through a class method that returns a reference to the instance.A class method is globally accessible.

3. Declaring the class constructor as private so that no other object can create a new instance.

Uses of Singleton Class
1. The static initialization approach is possible because the .NET Framework explicitly defines how and when static variable initialization occurs.
2. The Double-Check Locking idiom described earlier in "Multithreaded Singleton" is implemented correctly in the common language runtime.

Demerits of Singleton Class
If your multithreaded application requires explicit initialization, you have to take precautions to avoid threading issues.

Singleton class vs. Static methods

1.Static classes don’t promote inheritance. If your class has some interface to derive from, static classes makes it impossible.
2.You cannot specify any creation logic with static methods.

When to User Singleton Class?
The below activities is common through out the application, Singleton increase the performance of the application

1. Logging
2. Database Access
3. Reading Configuration information.

Singleton provides a global, single instance by:

1. Making the class create a single instance of itself.
2. Allowing other objects to access this instance through a class method that returns a reference to the instance.
3. A class method is globally accessible.
4. Declaring the class constructor as private so that no other object can create a new instance.

The following implementation of the Singleton design pattern follows the solution presented in Design Patterns: Elements of Reusable Object-Oriented Software [Gamma95] but modifies it to take advantage of language features available in C#, such as properties:

The class is marked sealed to prevent derivation, which could add instances.

The instantiation is not performed until an object asks for an instance; this approach is referred to as lazy instantiation. Lazy instantiation avoids instantiating unnecessary singletons when the application starts.

Example :

using System;

public class Singleton
{
   private static Singleton instance;

   private Singleton() {}

   public static Singleton Instance
   {
      get
      {
         if (instance == null)
         {
            instance = new Singleton();
         }
         return instance;
      }
   }
}


Static Initialization of Singleton Class
One of the reasons Design Patterns [Gamma95] avoided static initialization is because the C++ specification left some ambiguity around the initialization order of static variables. Fortunately, the .NET Framework resolves this ambiguity through its handling of variable initialization:

Example:
public sealed class Singleton
{
   private static readonly Singleton instance = new Singleton();
 
   private Singleton(){}

   public static Singleton Instance
   {
      get
      {
         return instance;
      }
   }
}

The main disadvantage of this implementation, however, is that it is not safe for multithreaded environments. If separate threads of execution enter the Instance property method at the same time, more that one instance of the Singleton object may be created. Each thread could execute the following statement and decide that a new instance has to be created.

Multithreaded Singleton in C#

Static initialization is suitable for most situations. When your application must delay the instantiation, use a non-default constructor or perform other tasks before the instantiation, and work in a multithreaded environment, you need a different solution. Cases do exist, however, in which you cannot rely on the common language runtime to ensure thread safety, as in the Static Initialization example. In such cases, you must use specific language capabilities to ensure that only one instance of the object is created in the presence of multiple threads.

This double-check locking approach solves the thread concurrency problems while avoiding an exclusive lock in every call to the Instance property method. It also allows you to delay instantiation until the object is first accessed. In practice, an application rarely requires this type of implementation. In most cases, the static initialization approach is sufficient.

using System;
public sealed class Singleton
{
   private static volatile Singleton instance;
   private static object syncRoot = new Object();

   private Singleton() {}

   public static Singleton Instance
   {
      get
      {
         if (instance == null)
         {
            lock (syncRoot)
            {
               if (instance == null)
                  instance = new Singleton();
            }
         }

         return instance;
      }
   }
}

This approach ensures that only one instance is created and only when the instance is needed. Also, the variable is declared to be volatile to ensure that assignment to the instance variable completes before the instance variable can be accessed. Lastly, this approach uses a syncRoot instance to lock on, rather than locking on the type itself, to avoid deadlocks.

This double-check locking approach solves the thread concurrency problems while avoiding an exclusive lock in every call to the Instance property method. It also allows you to delay instantiation until the object is first accessed. In practice, an application rarely requires this type of implementation. In most cases, the static initialization approach is sufficient.