Inline Code:
It’s an old style of coding model, where your business logic code appears in
< script runat=”server”> < /script > block in the .aspx page itself.
Example:
< %@ Page Language=”C#” % >
< script runat=”server”>
void Page_Load(object sender, eventArgs e)
{
Label1.Text=”Hello World”;
}
< /script>
< html >
< body >
< form id=”form1” runat=”server” >
< asp:Label ID=”Label1” Runat=”server” / >
< /form >
< /body >
< /html >
When first time this page loads,it is compiled into a class that resides in an assembly stored in a subfolder of the “C:\WINDOWS\Microsoft.NET\Framework\v2.x.xxxx\Temporary AST.NET files” folder. This compiled version of the page is good until the .aspx file changes or the application is restarted, at that time it will have to be recompiled.
Note- By default web page inherits from the System.Web.UI.Page class, so if you want your page inherits from some other class (which in turn must inherit from Page class), add “inherits” attribute to the Page directive.
Code-Behind: Non-Compiled
This coding style was used by the people, who wanted to change code on-the-fly without having to build their projects, or who wanted to separate code from HTML but didn’t have Visual Studio tool.
Example:
default.aspx file:
< %@ Page Language=”C#” Src=”default.aspx.cs” Inherits=”CodeBehindClass” % >
< html >
< body >
< form id=”form1” runat=”server” >
< asp:Label ID=”Label1” Runat=”server” / >
< /form >
< /body >
< /html >
Default.aspx.cs file:
using System;
using System.Web;
public class CodeBehindClass : System.Web.UI.Page
{
protected System.Web.UI.WebControls.Label Label1;
public void Page_Load(object sender, eventArgs e)
{
Label1.Text=”Hello World”;
}
}
In the above cod, the .aspx page looks just like the inline page, except the code has been moved to the code-behind file and two more attributes has been added to the Page directive. The Src attribute points to the physical file where the code behind class is located. The Inherits attributes tells us which class in that code-behind file the page should inherit because there technically could be any number of classed in that file.
The code-behind class must declare all the controls on the page as protected member of the class.
When the first time this page is requested, it will be compiled and cached only as the inline code version, using the code-behind file as the source for its base class. It will remain cached until the .aspx or code-behind file has been changed or the application is restated.
Code-Behind: Compiled
This coding style is same as the previous one for the coding point of view except in the Page directive “Src” attribute is replaced with “Codebehind”.
e.g.-
< %@ Page Language=”C#” Codebehind=”default.aspx.cs” Inherits=”CodeBehindClass” % >
Rest of the code will be same as shown in the Code-Behind Non-Compiled coding style.
By the way this coding style was used only by Visual Studio 2002 and 2003. Codebehind attribute was used to let the designer know where the code resides. Because no Src was specified, the class indicated in the Inherits attribute had to be compiled in an assembly located in the /bin folder. Actually when the project was built, all the .cs (or .vb) files in the project were compiled into one assembly. When the first time page was requested, it would be compiled in much the same way as the previous method, except that it would inherit from a class compiled in an assembly found in the /bin folder.
This style is obsolete and not supported in Visual Studio 2005 as it required constant synchronization between the page and code files that would generate lots of code. It also required a build every time page is tested.
Code-Beside:
This coding style uses the concept of partial class to separate the code files from the .aspx page.
Example:
default.aspx file:
< %@ Page Language=”C#” Codefile=”default.aspx.cs” Inherits=”Default_aspx” % >
< html >
< body >
< form id=”form1” runat=”server” >
< asp:Label ID=”Label1” Runat=”server” / >
< /form >
< /body >
< /html >
Default.aspx.cs file:
using System;
using System.Web;
public class Default_aspx: System.Web.UI.Page
{
protected System.Web.UI.WebControls.Label Label1;
public void Page_Load(object sender, eventArgs e)
{
Label1.Text=”Hello World”;
}
}
When a request for the page is made for the first time, the page combines itself with the partial class to become the functional equivalent of the inline code. This compiled page remains valid until one of the involved files is changed.
Database Normalization and Normal Forms
Database can be designed with following approaches:
1. Top-down approach
The Entity-Relationship (E/R) modelling technique is the top-down approach. It involves identifying entities, relationships and attributes, drawing E/R diagram and mapping the diagram to tables.
Generally tables derived from E/R diagram conforms to at least first normal form. This approach is the best for validation of existing designs.
2. Bottom-up approach
Normalizing the database is the bottom-up approach. Normalization is a step by step decomposition of complex tables into simple tables. It reduces redundancy using the principle of non-loss decomposition. Non-loss decomposition is a process of breaking large/complex tables into smaller/simple tables without loss of information.
Redundancy is the unnecessary repetition of data that can lead to inconsistencies in data and update anomalies.
Generally, normalization follows the process of drawing E/R diagrams.
Note: A fully normalized record consist set of attributes that describe the entity and a primary key that identifies the entity.
Functional Dependency
Normalization theory is based on the theory of functional dependency.
Functional dependency can be explained like –
Given a relation R, attribute A is functionally dependent on B if each value of A in R is associated with precisely one value of B.
OR
Given a relation R, attribute A is functionally dependent on B only if whenever two tuples of R agree on their B value, they must agree in their A value as well.
For Example –
There is an entity named CUSTOMER with following attributes: CODE, NAME, ADDRESS and PHONE_NO.
Given a particular value of CODE, there is precisely one corresponding value of NAME, ADDRESS and PHONE_NO. So, the attributes NAME, ADDRESS and PHONE_NO are functionally dependent on the attribute CODE.
Functional dependency does not require an attribute to be the key in order to functionally determine other attributes.
For Example-
In the SALES entity that has attributes: CUSTOMER_CODE, CITY, PRODUCT_CODE, and QUANTITY.
CUSTOMER_CODE functionally determines CITY because city to which the shipment is made is also where the customer is located.
Note: Functional dependency represents many-to-many relationships.
Normal Forms
Normalization results in the formation of tables that satisfied certain specified constraints, and represent certain normal forms. Normal forms are table structures with minimum redundancy.
Some of the most important and widely used normal forms are:
1.First Normal Form (1st NF)
2.Second Normal Form (2nd NF)
3.Third Normal Form (3rd NF)
4.Boyce-Codd Normal Form (BCNF)
Note: A relation that is in the first normal form may also be in second normal form or third formal form.
First Normal Form
A table is said to be in the first normal form (1 NF) when each cell of the table contains precisely one value. To put data in 1 NF, all repeating information has to be removed.
Second Normal Form
A table is said to be in 2 NF when it is in the 1 NF and every attribute in the record is functionally dependent upon the whole key, and not just part of the key.
Example- A table has following attributes: EMP_CODE, DEPT, PROJ_CODE, and HOURS.
The primary key here is composite(EMP_CODE+PROJ_CODE). But the attributes of this table depend upon only part of the primary key.
• EMP_CODE+PROJ_CODE functionally determines HOURS
• EMP_CODE functionally determines DEPT but it has no dependency on PROJ_CODE.
Solution: Break this table into 2 tables:
Table A with attributes EMP_CODE and DEPT
Table B with attributes EMP_CODE, PROJ_CODE and HOURS.
Third Normal Form
A table is said to be in 3 NF when it is in 2 NF and every non-key attribute is functionally dependent on just the primary key.
Example- A table has following attributes: EMP_CODE, DEPT and DEPT_HEAD_CODE
The primary key here is EMP_CODE. The attribute DEPT is dependent on EMP_CODE and the attribute DEPT_HEAD_CODE is dependent on DEPT. So there is an indirect dependency on primary key.
Solution: Break the table into 2 tables:
Table A with attributes EMP_CODE and DEPT
Table B with attributes DEPT and DEPT_HEAD_CODE
Now each non-key attribute depends on the key, the whole key and nothing but the key
Boyce-Codd Normal Form
A table is said to be in BCNF if every determinate is a candidate key.
The definition of 3 NF is inadequate for the tables with multiple candidate keys where they are composite keys or they are overlapped (has at least one attribute in common)
Example- Table A has following attributes: EMP_CODE, EMP_EMAIL, PROJ_CODE and HOURS
Table B, which is master for table A has following attributes: EMP_CODE, EMP_EMAIL, EMP_PHONE, EMP_FAX etc.
Observations:
• Table A has multiple candidate keys- attributes EMP_CODE and EMP_EMAIL are candidate keys.
• Table B has composite candidate keys- EMP_CODE and PROJ_CODE functionally determine HOURS.
• And EMP_EMAIL and PROJ_CODE functionally determine HOURS as well.
• Composite keys are overlapped – PROJ_CODE is common.
Solution: Break table into 2 tables:
Table B1 with attributes EMP_CODE and EMP_EMAIL
Table B2 with attributes EMP_CODE, PROJ_CODE and HOURS
1. Top-down approach
The Entity-Relationship (E/R) modelling technique is the top-down approach. It involves identifying entities, relationships and attributes, drawing E/R diagram and mapping the diagram to tables.
Generally tables derived from E/R diagram conforms to at least first normal form. This approach is the best for validation of existing designs.
2. Bottom-up approach
Normalizing the database is the bottom-up approach. Normalization is a step by step decomposition of complex tables into simple tables. It reduces redundancy using the principle of non-loss decomposition. Non-loss decomposition is a process of breaking large/complex tables into smaller/simple tables without loss of information.
Redundancy is the unnecessary repetition of data that can lead to inconsistencies in data and update anomalies.
Generally, normalization follows the process of drawing E/R diagrams.
Note: A fully normalized record consist set of attributes that describe the entity and a primary key that identifies the entity.
Functional Dependency
Normalization theory is based on the theory of functional dependency.
Functional dependency can be explained like –
Given a relation R, attribute A is functionally dependent on B if each value of A in R is associated with precisely one value of B.
OR
Given a relation R, attribute A is functionally dependent on B only if whenever two tuples of R agree on their B value, they must agree in their A value as well.
For Example –
There is an entity named CUSTOMER with following attributes: CODE, NAME, ADDRESS and PHONE_NO.
Given a particular value of CODE, there is precisely one corresponding value of NAME, ADDRESS and PHONE_NO. So, the attributes NAME, ADDRESS and PHONE_NO are functionally dependent on the attribute CODE.
Functional dependency does not require an attribute to be the key in order to functionally determine other attributes.
For Example-
In the SALES entity that has attributes: CUSTOMER_CODE, CITY, PRODUCT_CODE, and QUANTITY.
CUSTOMER_CODE functionally determines CITY because city to which the shipment is made is also where the customer is located.
Note: Functional dependency represents many-to-many relationships.
Normal Forms
Normalization results in the formation of tables that satisfied certain specified constraints, and represent certain normal forms. Normal forms are table structures with minimum redundancy.
Some of the most important and widely used normal forms are:
1.First Normal Form (1st NF)
2.Second Normal Form (2nd NF)
3.Third Normal Form (3rd NF)
4.Boyce-Codd Normal Form (BCNF)
Note: A relation that is in the first normal form may also be in second normal form or third formal form.
First Normal Form
A table is said to be in the first normal form (1 NF) when each cell of the table contains precisely one value. To put data in 1 NF, all repeating information has to be removed.
Second Normal Form
A table is said to be in 2 NF when it is in the 1 NF and every attribute in the record is functionally dependent upon the whole key, and not just part of the key.
Example- A table has following attributes: EMP_CODE, DEPT, PROJ_CODE, and HOURS.
The primary key here is composite(EMP_CODE+PROJ_CODE). But the attributes of this table depend upon only part of the primary key.
• EMP_CODE+PROJ_CODE functionally determines HOURS
• EMP_CODE functionally determines DEPT but it has no dependency on PROJ_CODE.
Solution: Break this table into 2 tables:
Table A with attributes EMP_CODE and DEPT
Table B with attributes EMP_CODE, PROJ_CODE and HOURS.
Third Normal Form
A table is said to be in 3 NF when it is in 2 NF and every non-key attribute is functionally dependent on just the primary key.
Example- A table has following attributes: EMP_CODE, DEPT and DEPT_HEAD_CODE
The primary key here is EMP_CODE. The attribute DEPT is dependent on EMP_CODE and the attribute DEPT_HEAD_CODE is dependent on DEPT. So there is an indirect dependency on primary key.
Solution: Break the table into 2 tables:
Table A with attributes EMP_CODE and DEPT
Table B with attributes DEPT and DEPT_HEAD_CODE
Now each non-key attribute depends on the key, the whole key and nothing but the key
Boyce-Codd Normal Form
A table is said to be in BCNF if every determinate is a candidate key.
The definition of 3 NF is inadequate for the tables with multiple candidate keys where they are composite keys or they are overlapped (has at least one attribute in common)
Example- Table A has following attributes: EMP_CODE, EMP_EMAIL, PROJ_CODE and HOURS
Table B, which is master for table A has following attributes: EMP_CODE, EMP_EMAIL, EMP_PHONE, EMP_FAX etc.
Observations:
• Table A has multiple candidate keys- attributes EMP_CODE and EMP_EMAIL are candidate keys.
• Table B has composite candidate keys- EMP_CODE and PROJ_CODE functionally determine HOURS.
• And EMP_EMAIL and PROJ_CODE functionally determine HOURS as well.
• Composite keys are overlapped – PROJ_CODE is common.
Solution: Break table into 2 tables:
Table B1 with attributes EMP_CODE and EMP_EMAIL
Table B2 with attributes EMP_CODE, PROJ_CODE and HOURS
