See Last Minute Notes on all subjects here.
We will discuss the important key points useful for GATE exams in summarized form. For details you may refer this.
ER Diagram: The most common asked questions in ER diagram is minimum number of tables required for a given ER diagram. Generally, following criteria are used:
Cardinality  Minimum No. of tables 
1:1 cardinality with partial participation of both entities  2 
1:1 cardinality with total participation of atleast 1 entity  1 
1:n cardinality  2 
m:n cardinality  3 
Note: This is a general observation. Special cases need to be taken care. We may need extra table if attribute of a relationship can’t be moved to any entity side.
Keys of a relation: There are various types of keys in a relation which are:
 Candidate Key: The minimal set of attributes which can determine a tuple uniquely. There can be more than 1 candidate key of a relation and its proper subset can’t determine tuple uniquely and it can’t be NULL.
 Super Key: The set of attributes which can determine a tuple uniquely. A candidate key is always a super key but vice versa is not true.
 Primary Key and Alternate Key: Among various candidate keys, one key is taken primary key and others are alternate keys.
Normal Forms
 First Normal Form: A relation is in first normal form if it does not contain any multivalued or composite attribute.
 Second Normal Form: A relation is in second normal form if it does not contain any partial dependency. A dependency is called partial dependency if any proper subset of candidate key determines nonprime (which are not part of candidate key) attribute.
 Third Normal Form: A relation is in third normal form if it does not contain any transitive dependency. For a relation to be in Third Normal Form, either LHS of FD should be super key or RHS should be prime attribute.
 BoyceCodd Normal Form: A relation is in BoyceCodd Normal Form if LHS of every FD is super key. The relationship between Normal Forms can be represented as: 1NF⊃2NF⊃3NF⊃BCNF
Relational Algebra: Procedural language with basic and extended operators.
Basic Operator  Semantic 
σ (Selection)  Select rows based on given condition 
∏ (Projection)  Project some columns 
X (Cross Product)  Cross product of relations, returns m*n rows where m and n are number of rows in R1 and R2 respectively. 
U (Union)  Return those tuples which are either in R1 or in R2. Max no. of rows returned = m+n andMin no. of rows returned = max(m,n) 
– (Minus)  R1R2 returns those tuples which are in R1 but not in R2. Max no. of rows returned = m and Min no. of rows returned = mn 
ρ (Rename)  Renaming a relation to other relation. 
Extended Operator  Semantic 
∩ (Intersection)  Returns those tuples which are in both R1 and R2. Max no. of rows returned = min(m,n) and Min no. of rows returned = 0 
⋈c (Conditional Join) 
Selection from two or more tables based on some condition (Cross product followed by selection) 
⋈c(Equi Join) 
It is a special case of conditional join when only equality condition is applied between attributes. 
⋈(Natural Join) 
In natural join, equality condition on common attributes hold and duplicate attributes are removed by default. Note: Natural Join is equivalent to cross product if two relations have no attribute in common and natural join of a relation R with itself will return R only. 
/(Division Operator) 
Division operator A/B will return those tuples in A which is associated with every tuple of B.Note:Attributes of B should be proper subset of attributes of A. The attributes in A/B will be Attributes of A Attribute of B. 
SQL: As opposed to Relational Algebra, SQL is a nonprocedural language.
Operator  Meaning 
Select  Selects columns from a relation or set of relations.Note: As opposed to Relational Algebra, it may give duplicate tuples for repeated value of an attribute. 
From  From is used to give input as relation or set of relations from which data needs to be selected. 
where  Where is used to give condition to be used to filter tuples 
Group By  Group By is used to group the tuples based on some attribute or set of attributes like counting the no. of students group by department. 
Aggregate functions  Find the aggregated value of an attribute. Used mostly with group by. e.g.; count, sum, min max. select count(*) from student group by dept_idNote: we can select only those columns which are part of group by. 
Nested Queried  When one query is a part of other query. Solving nested queries questions can be learnt in http://quiz.geeksforgeeks.org/nestedqueriessql/ 
Conflict serializable and Conflict Equivalent: A schedule is conflict serializable if it is conflict equivalent to a serial schedule.
Checking for Conflict Serializability
To check whether a schedule is conflict serializable or not, find all conflicting operations pairs of a schedule and draw precedence graph ( For all conflicting operation pair, an edge from T_{i} to T_{j} if one operation of conflicting pair is from T_{i} and other from T_{j} and operation of T_{i} occurs before T_{j} in schedule). If graph does not contain cycle, the schedule is conflict serializable else it is not conflict serializable.
Schedules are said to be conflict equivalent if 1 schedule can be converted into another by swapping non conflicting operations.
Note: Two phase locking protocol produce conflict serializable schedule but may suffer from deadlock. On the other hand, TimeStamp based protocols are free from deadlock yet produce conflict serializable schedule.
View Serializable and View Equivalence: Two schedules S1 and S2 are said to be viewequivalent if all conditions are satisfied for all objects:

If the transaction T_{i} in S1 reads an initial value for object X, in S2 also, T_{i} must read the initial value of X.

If the transaction T_{i} in S1 reads the value written by transaction T_{j }in S1 for object X, same should be done in S2.

If the transaction T_{i} in S1 is the final transaction to write the value for an object X, in S2 also, T_{i} must write the final value of X.
A schedule is view serializable if it is view equivalent to any serial schedule.
Irrecoverable Schedules: For a transaction pair < T_{i}, T_{j} >, if T_{j} is reading the value updated by Ti and Tj is committed before commit of Ti, the schedule will be irrecoverable.
Recoverable Schedules: For a transaction pair < T_{i}, T_{j} >, if T_{j} is reading the value updated by Ti and Tj is committed after commit of Ti, the schedule will be recoverable.
Cascadeless Recoverable Schedules: For a transaction pair < T_{i}, T_{j} >, if value updated by Ti is read by Tj only after commit of T_{i}, the schedule will be cascadeless recoverable.
Strict Recoverable: For a transaction pair < T_{i}, T_{j} >, if value updated by Ti is read or written by Tj only after commit of T_{i}, the schedule will be strict recoverable. The relationship between them can be represented as:
Strict ⊂ Cascadeless Recoverable ⊂ recoverable ⊂ all schedules
This article has been contributed by Sonal Tuteja.
Please write comments if you find anything incorrect, or you want to share more information about the topic discussed above