Thursday, January 10, 2008

Quick note on IDispatch, Dual & DispInterface

IDispatch Interface
The IDispatch interface was initially designed to support Automation. It provides a late-binding mechanism to access and retrieve information about an object's methods and properties(often useful in scripting languages such as VBScript, JavaScript etc).

IDispatch is designed in such a way that it can call virtually any other COM interface. Developers not working on C or C++ often cannot call COM interfaces through direct OLE VTable binding. However, when their development language supports IDispatch( e.g. as Visual Basic does) and when the object they want to call supports IDispatch, they can call its COM interfaces indirectly through IDispatch::Invoke method.

DispInterface is a pure IDispatch Interface which can not use vtable based interface. Hence DUAL attribute cant be used on dispInterface.

Dual Interfaces
OLE Automation enables an object to expose a set of methods in two ways: via the IDispatch interface, and through direct OLE VTable binding. Dual Interface supports both.

The first seven entries of the VTBL for a dual interface are the seven members of IDispatch(i.e. 4 of IDispatch and 3 of IUnknown), and the remaining entries are COM entries for direct access to members of the dual interface.


Wednesday, January 9, 2008

Database Normalization

Different Normal Forms in a Relational Database

1NF says:
*Eliminate duplicate columns from the table.
*No attribute should contain multiple values(e.g. 2 or more phone numbers separated by coma under column 'Contacts').
In such case Create separate tables for each group of related data.
*User should be able to identify each row with a unique column or set of columns (the primary key).

2NF says:
*Table Should be in 1st NF
*all the non-prime attributes must have Full functional dependency on all candidate keys.
i.e. non-prime attributes depends on complete candidate keys and not on its subset.
*Place any such data to new tables and link them with the help of foreign keys.

3NF Says:
*Table Should be in 2nd NF
*It prohibits transitive functional dependencies of non-prime attributes on candidate keys.

BCNF says:
*Table should be in 3NF
*If X -> Y i.e. If Y depends on X, then X shoud be a super key (i.e. X is either a candidate key or a superset of candidate key).

4NF says
*Table should be in 3NF
*A relation is in 4NF if it has no multi-valued dependencies.

- Normalization on
- Normalization on