Dependency: A dependency occurs in a database when information stored in the same database table uniquely determines other information

stored in the same table. You can also describe this as a relationship where knowing the value of one attribute (or a set of attributes) is enough to tell you the value of another attribute (or set of attributes) in the same table. Saying that there is a dependency between attributes in a table is the same as saying that there is a functional dependency between those attributes. If there is a dependency in a database such that attribute B is dependent upon attribute A, you would write this as A -> B. For example, In a table listing employee characteristics including Social Security Number (SSN) and name, it can be said that name is dependent upon SSN (or SSN -> name) because an employee's name can be uniquely determined from their SSN. However, the reverse statement (name -> SSN) is not true because more than one employee can have the same name but different SSNs. Functional Dependency: Dependency means that the one entity dependents on another entity. This is also applicable for the Function also. Given a Relation R(A,B,C,D) , Functional Dependencies ABCD , BCD ABCD means A functionally determines BCD. BCD means BC functionally determines D. Full Functional Dependency: Given a relation R and Functional Dependency XY Y is fully functionally dependent on X and there should not be any ZY, Where Z is a proper subset of X. Partial Dependency: If any proper subsets of the key determine any of the non-key attributes then there exist a partial dependency. Example: Given A relation R(A,B,C,D,E) , Functional Dependency : ABCDE , Primary key(key) is AB. Then AC : is a Partial Dependency AD : is a Partial Dependency AE : is a Partial Dependency BC : is a Partial Dependency BD : is a Partial Dependency BE : is a Partial Dependency Transitive Dependency: A transitive dependency is a functional dependency which holds by virtue of transitivity. A transitive dependency can occur only in a relation that has three or more

attributes. Let A, B, and C designate three distinct attributes (or distinct collections of attributes) in the relation. Suppose all three of the following conditions hold: 1. A B 2. It is not the case that B A 3. B C Then the functional dependency A C (which follows from 1 and 3 by the axiom of transitivity) is a transitive dependency. The functional dependency {Book} {Author Nationality} applies; that is, if we know the book, we know the author's nationality. Furthermore: {Book} {Author} {Author} does not {Book} {Author} {Author Nationality} Therefore {Book} {Author Nationality} is a transitive dependency. Transitive dependency occurred because a non-key attribute (Author) was determining another non-key attribute (Author Nationality). Trival Dependency: A trivial functional dependency is a functional dependency of an attribute on a superset of itself. {Employee ID, Employee Address} {Employee Address} is trivial, as is {Employee Address} {Employee Address}. A join dependency is a constraint on the set of legal relations over a database scheme. A table T is subject to a join dependency if T can always be recreated by joining multiple tables each having a subset of the attributes of T. If one of the tables in the join has all the attributes of the table T, the join dependency is called trivial. Multivalued Dependencies: Multivalued dependencies occur when the presence of one or more rows in a table implies the presence of one or more other rows in that same table. For example, imagine a car company that manufactures many models of car, but always makes both red and blue colors of each model. If you have a table that contains the model name, color and year of each car the company manufactures, there is a multivalued dependency in that table. If there is a row for a certain model name and year in blue, there must also be a similar row corresponding to the red version of that same car. Multivalue Attribute: A multivalue attribute is the practice of maintaining more than a single value in a database column. Lets say for example you want to know the hobbies for a client. The proper way to handle this is to maintain the data in a one - to - many child table. Another way is a multivalue field. This in effect is a text field (varchar, etc) that will contain one or more values, separated by a comma (as an example). This of course is NOT the way to go and will cause performance problems in parsing the

information and make many reports and logical use of the data very difficult (but possible). Tuple-Generating Dependencies Synonyms Equality-generating dependency (egd) Definition Tuple-generating dependencies, or tgds, are one of the two major types of database dependencies (the other major type consists of equality-generating dependencies, or egds). To define tgds, the notion of an atomic formula is first needed, which is a formula of the form P(x 1,...,x k ), where P is a k-ary relational symbol, and x 1,...,x k are variables, not necessarily distinct. Then tgds are formulas of the form x((x) y (x, y)), where 1. (x) is a conjunction of atomic formulas, all with variables among the variables in x. 2. every variable in x appears in (x) (but not necessarily in (x, y)). 3. (x, y) is a conjunction of atomic formulas, all with variables among the variables in x and y. If y is empty, so that there are no existentially-quantified variables, then the tgd is called full. Conditions (1) and (2) together are sometimes replaced by the weaker condition ... Join Dependency Multivalued Dependencies are helps to lossless decomposition and form relation R based on trivial multivalued dependencies. An instance, a relation R(A B C) is decomposed into relation R1(A B) and R2(A C) based on trivial A B multivalued functional dependencies. Join Dependency is helps to lossless decomposition and form relation R based on nontrivial multivalued dependencies. An instance, a relation R(A B C) is decomposed into relation R1(A B), R2(B C) and R3(A C) based on nontrivial multivalued functional dependencies. Let R = {R1, R2, ..., Rn} be a set of relation schemes over union, the relation r(R) satisfies the join dependency * [R1, R2, ..., Rn] if r decomposes lossless onto R1, R2, ... Rn. That is, r = pR1(r) pR2(r) ..., pRn(r). A join dependency * [R1, R2, ..., Rn] over R is trivial if it is satisfied by every relation r(R).

Dependency Preservation Given a relation R and a set of FDs F, dependency preservation states that the closure of the union of the projection of F on each decomposed relation Ri is equal to the closure of F. i.e., ((?R1(F)) U U (?Rn(F)))+ = F+ if decomposition is not dependency preserving, then some dependency is lost in the decomposition. Trivial functional dependency A trivial functional dependency occurs when you describe a functional dependency of an attribute on a collection of attributes that includes the original attribute. This type of functional dependency is called trivial because it can be derived from common sense. It is obvious that if you already know the value of B, then the value of B can be uniquely determined by that knowledge. Transitive functional dependency A functional dependency X->Y is transitive in R, if there exists an attribute Z in R, such that X-> Z, Z-> Y . Simple Key A simple key consists of a single attribute to uniquely identify an entity occurrence, for example, a student number, which uniquely identifies a particular student. No two students would have the same student number. Primary Key A primary key is a field in a table which uniquely identifies the each rows/records in a database table. Primary keys must contain unique values. A primary key column cannot have NULL values. Composite Key A table can have only one primary key which may consist of single or multiple fields. When multiple fields are used as a primary key, they are called a composite key. Unique Key A unique key must uniquely identify all possible rows that exist in a table and not only the currently existing rows. It can either be a normal attribute that is guaranteed to be unique (such as Social Security Number in a table with no more than one record per person) Candidate Key A Candidate Key can be any column or a combination of columns that can qualify as unique key in database. There can be multiple Candidate Keys in one table. Each Candidate Key can qualify as Primary Key. Super key:

A superkey is defined as a set of attributes of a relation for which it holds that in all relations assigned to that variable there are no two distinct tuples (rows) that have the same values for the attributes in this set. Foreign Key A FOREIGN KEY in one table points to a PRIMARY KEY in another table (or) A foreign key is a field (or fields) that points to the primary key of another table. The purpose of the foreign key is to ensure referential integrity of the data. In other words, only values that are supposed to appear in the database are permitted EX: In EMP table Deptno field is the foreign key because it pointing to the Deptno in DEPT table Reference key A Reference key is a field (or fields) that points to the primary key of the same table EX: In EMP table Mgr field is the Reference key because it pointing to the Empno field in the same table Foreign key is the key i.e. attribute which refers to another table primary key. Reference key is the primary key of table referred by another table. Constraints Constraints within a database are rules which control values allowed in columns and also enforce the integrity between columns and tables. Integrity constraints The term integrity means to correctness and completeness of the data in data base. A relational data base is collection of related table. Table contains various information. Tables are connected by the foreign key relationship. When the contains with the certain command, insert, delete, update. The integrity of the data can be loss in many different ways. Schema Refinement Schema refinement is correcting a program schematic to make the program usable. Decomposition Decomposition means replacing a relation with a collection of smaller relations. Normalization Normalization is the process of decomposing a relation(table) based on functional dependency and primary key. Un-Normalized Form First Normal Form (1 NF)

Second Normal Form (2 NF) Third Normal Form (3 NF) Boyce Codd Normal Form (BCNF) Fourth Normal From (4 NF) Fifth Normal Form (5 NF)

De-Normalization Denormalisation basically is the process of finding the balance between avoiding data duplication and ensuring database performance. denormalization is an approach to speeding up read performance (data retrieval) in which the administrator selectively adds back specific instances of redundant data after the data structure has been normalized. A denormalized database should not be confused with a database that has never been normalized. Un-Normalized Form Un-Normalized relation contain non atomic values.Each row may contain multiple set of values for some of the columns.These multiple values in a single row are called non atomic value. First Normal Form A Relation is said to be in 1NF if the values in the domain of each attribute of relation are atomic.Each cell of the table must have single value.No two rows in a table may be identical. Second Normal Form A relation R is said to be in 2NF if it is in 1NF and there should not be any partial dependency. Here all the non key attributes are dependent on the key alone. No attribute is depend upon a part of the key. Any relation having a key with single attribute is in 2NF. Third Normal Form A relation R is in 3NF if it is in 2NF and has no transitive dependency.Here all the nonkey attributes are depend on the key alone.There should not be any dependency among the non-key attributes. Boyce Codd Normal Form BCNF A relation R is in BCNF if every determinant is a candidate key. Problem with BCNF: Given a relation R , Functional Dependency F, BCNF may or may not preserve all given functional dependencies. Fourth Normal From A Relation is in 4NF if it is in BCNF and has no multi valued dependency. Fifth Normal Form It deals with join dependency. A relation R is in 5NF if it has no join dependency.

Loss less Join Dependency : When we join the decomposed relation then we must get the original relation without any loss. Partial Functional In database terminology, a partial functional dependency occurs when the value in a nonkey attribute of a table is dependent on the value of some part of the table's primary key (but not all of it). Atomic Values Atomic values in a relational database mean that they cannot be further divided, according to domain rules defining that attribute. Attribute: In DBMS a table contains one or more columns there columns are the attribute in DBMS EXAMPLE "employee information" table have the following columns ID,NAME,ADDRESS THEN id ,name address are the attributes of employee Schema overall design of the database. namespace within database, identical to user account Entity An entity is an object that exists and is distinguishable from other objects. For instance, John Harris with S.I.N. 890-12-3456 is an entity, as he can be uniquely identified as one particular person in the universe. An entity may be concrete or abstract. An entity is represented by a set of attributes. Entity Set An entity set is a set of entities of the same type (e.g., all persons having an account at a bank). Entity sets need not be disjoint. For example, the entity set employee (all employees of a bank) and the entity set customer (all customers of the bank) may have members in common. Relation "relation" in "relational" databases does not refer to the foreign key relationship of one table to another. "A relation is a data structure which consists of a heading and an unordered set of tuples which share the same type," In SQL RDBMSes (such as MS SQL Server and Oracle] tables are permently stored relations, where the column names defined in the data dictionary form the "heading" and the rows are the "tuples" of the relation. Relationship is purely a construct of the er data model. Relation is a structure of the relational data model.

Relation Instance The meaning of relation instance in a data base management system is the construction of data consist of heading and unordered set of data that can be shared by the same type.

Difference Between Relational Calculus And Relational Algebra Relational calculus is a declarative way to specify the queries, whereas relational algebra is a procedural way to specify the queries. relational algebra is procedural lenguage while Relational calculus. is non-procedural lenguage. What is the Diff. Between Relational Algebra & Calculas? Point of Comparison Is it Query Language? Relation Query R.Algebra YES Describe step-by-step proceduar for computing the desired answer ,depend on the order in which operator are applies in query Procedural R.Calculus YES Describe the set of answer without being excplicit about how they should be computed Non- Procedural

Type