INCONSISTENT VALUE PROBLEM The inconsistent values

 INCONSISTENT VALUE PROBLEM
The inconsistent values problem occurs when different users or data sources use slightly different forms
of the same data value. One example is where automobiles are specified as "Ford, 2-door, Red" in one
cell and "Red Ford 2-door" in another.
 BINARY & TERNARY RELATIONSHIP
The binary relation is used when two entities have relation directly with each other, here directly is
mean a key on child relation should refer to a value which is available on parent table identity/unique
key. something like this.
Mapping cardinality comes in binary relationship
The Ternary, when three or (n) relations have relationship between themselves, and providing all
relationship between them makes the database complex, so here the relationships will turned into a
relation which has one-to-many/one-to-one with base relations.
example: consider an event in OS, an event would associate with application which registered the
event, the device which caused the event, and the component(textbox, button, window,...) which
triggered the event.
Generalization&specialization comes in ternary relationship.
 DIFFERENCE BETWEEN ENTITY,ENTITY INSTANCE & ENTITY CLASS
An entity is a person, place, event, or thing about which data is collected...An instance is an occurence of
an entity." - Systems Analysis & Design (4th) - Dennis
An example of this would be STUDENT as the entity while JACK SMITH is an instance of that entity.
If an entity is an individual "person, place, event, or thing about which data is collected", then an entity
is an instance. Linguistically, entity is just another word for a single thing ("The existence of a thing as
contrasted with its attributes.", Merriam-Webster's On-line Dictionary). Entities that have the same
attributes are grouped in what are best called entity classes (it doesn't make sense to refer to a
collection of entities as an entity). Entity and entity class are data modeling terms. The corresponding
object modeling terms are object and class, albeit that a class typically has operations, which are foreign
to an entity class.
 TOTAL & PARTIAL PATICIPATION
 CASCADE UPDATE & DELETE
Cascading referential integrity constraints allow you to define the actions Microsoft® SQL
Server™ 2000 takes when a user attempts to delete or update a key to which existing foreign
keys point.
The REFERENCES clauses of the CREATE TABLE and ALTER TABLE statements support
ON DELETE and ON UPDATE clauses:

[ ON DELETE { CASCADE | NO ACTION } ]

[ ON UPDATE { CASCADE | NO ACTION } ]
NO ACTION is the default if ON DELETE or ON UPDATE is not specified. NO ACTION
specifies the same behavior that occurs in earlier versions of SQL Server.
ON DELETE NO ACTION
Specifies that if an attempt is made to delete a row with a key referenced by foreign keys in
existing rows in other tables, an error is raised and the DELETE is rolled back.
ON UPDATE NO ACTION
Specifies that if an attempt is made to update a key value in a row whose key is referenced by
foreign keys in existing rows in other tables, an error is raised and the UPDATE is rolled back.
CASCADE allows deletions or updates of key values to cascade through the tables defined to
have foreign key relationships that can be traced back to the table on which the modification is
performed. CASCADE cannot be specified for any foreign keys or primary keys that have a
timestamp column.
ON DELETE CASCADE
Specifies that if an attempt is made to delete a row with a key referenced by foreign keys in
existing rows in other tables, all rows containing those foreign keys are also deleted. If cascading
referential actions have also been defined on the target tables, the specified cascading actions are
also taken for the rows deleted from those tables.
ON UPDATE CASCADE
Specifies that if an attempt is made to update a key value in a row, where the key value is
referenced by foreign keys in existing rows in other tables, all of the foreign key values are also
updated to the new value specified for the key. If cascading referential actions have also been
defined on the target tables, the specified cascading actions are also taken for the key values
updated in those tables.
Examples of cascading referential actions can be based on the FK_Products_Suppliers
constraint on the Products table in Northwind. This constraint establishes a foreign key
relationship from the SupplierID column in the Products table to the SupplierID primary key
column in the Suppliers table. If ON DELETE CASCADE is specified for the constraint,
deleting the row in Suppliers where SupplierID equals 1 also deletes the three rows in
Products where SupplierID equals 1. If ON UPDATE CASCADE is specified for the
constraint, updating the SupplierID value in the Suppliers table from 1 through 55 also updates
the SupplierID values in the three rows in Products whose SupplierID values currently equal
1.
Cascading actions cannot be specified for a table that has an INSTEAD OF UPDATE or
INSTEAD OF DELETE trigger. After a cascading action has been defined for a table, an
INSTEAD OF UPDATE or INSTEAD OF DELETE trigger cannot be added to it.
 STRONG & WEAK ENTITY SET
The entity set which does not have sufficient attributes to form a primary key is called as
Weak entity set. An entity set that has a primary key is called as Strong entity set.
Consider an entity set Payment which has three attributes: payment_number,
payment_date and payment_amount. Although each payment entity is distinct but
payment for different loans may share the same payment number. Thus, this entity set
does not have a primary key and it is an entity set. Each weak set must be a part of oneto-many relationship set.
A member of a strong entity set is called dominant entity and member of weak entity set
is called as subordinate entity. A weak entity set does not have a primary key but we
need a means of distinguishing among all those entries in the entity set that depend on
one particular strong entity set. The discriminator of a weak entity set is a set of
attributes that allows this distinction be made. For example, payment_number acts as
discriminator for payment entity set. It is also called as the Partial key of the entity set.
The primary key of a weak entity set is formed by the primary key of the strong entity set
on which the weak entity set is existence dependent plus the weak entity sets
discriminator. In the above example {loan_number, payment_number} acts as primary
key for payment entity set.
The relationship between weak entity and strong entity set is called as Identifying
Relationship. In example, loan-payment is the identifying relationship for payment
entity. A weak entity set is represented by doubly outlined box .and corresponding
identifying relation by a doubly outlined diamond as shown in figure. Here double lines
indicate total participation of weak entity in strong entity set it means that every
payment must be related via loan-payment to some account. The arrow from loanpayment to loan indicates that each payment is for a single loan. The discriminator of a
weak entity set is underlined with dashed lines rather than solid line.
Let us consider another scenario, where we want to store the information of employees
and their dependents. The every employee may have zero to n number of dependents.
Every dependent has an id number and name.
Now let us consider the following data base:
There are three employees having E# as 1, 2, and 3 respectively.
Employee having E# 1, has two dependents as 1, Rahat and 2, Chahat.
Employee having E# 2, has no dependents.
Employee having E# 3, has three dependents as 1, Raju; 2, Ruhi; 3 Raja.
Now, in case of Dependent entity id cannot act as primary key because it is not unique.
Thus, Dependent is a weak entity set having id as a discriminator. It has a total
participation with the relationship "has" because no dependent can exist without the
employees (the company is concerned with employees). The E-R diagram for the
employee-dependent database is shown.
There are two tables need to created above e-r diagram. These are Employee having E#
as single column which acts as primary key. The other table will be of Dependent having
E#, id and name columns where primary key is the combination of (E# and id).