Relational Algebra: Selection, Projection and Rename
The three unary operators. Selection picks rows, projection picks columns and removes duplicates, and rename makes an expression reusable. Together they cover most single relation queries.
-
DBMS Fundamentals
- Data, Information and Databases
- What a DBMS Is and Why It Exists
- File System versus DBMS
- Advantages and Limitations of a DBMS
- Database Users and the Role of the DBA
- Three Level Architecture and Data Abstraction
- Logical and Physical Data Independence
- Schema, Instance and Metadata
- Database Applications and the Database System Environment
- Database Architecture
- Data Models
-
ER Model
- Entities, Entity Sets and Entity Types
- Types of Attributes in the ER Model
- Keys in the ER Model
- Relationships, Relationship Sets and Degree
- Cardinality and Participation Constraints
- Strong and Weak Entities
- Drawing and Reading ER Diagrams
- Extended ER: Generalisation, Specialisation and Aggregation
- Converting an ER Diagram into Relational Tables
- ER Design Projects
- Relational Model
- Relational Algebra
- Functional Dependencies
-
Normalisation
- Why Normalisation Exists: Anomalies and Redundancy
- First Normal Form
- Second Normal Form and Partial Dependency
- Third Normal Form and Transitive Dependency
- BCNF and BCNF Decomposition
- 4NF, 5NF, Multivalued and Join Dependencies
- Lossless Decomposition and Dependency Preservation
- Complete Worked Normalisation: Unnormalised to BCNF
- Denormalisation and When to Use It
Concept
Relational algebra is a formal language of operators that take relations as input and produce relations as output. It is procedural — an expression describes a sequence of operations, not just a desired result.
It matters for two reasons: it is the foundation of query optimisation, because algebraic equivalences let an optimiser rewrite a query safely, and it is examined in almost every DBMS paper.
The closure property
relation(s) ---> [ operator ] ---> relation
Output is always a relation, so the output of one operator
can be the input of the next. That is CLOSURE, and it is
what allows expressions to be composed to any depth.The sample relations
Every example in this phase uses these three, so they are worth reading once carefully.
STUDENT COURSE
+---------+--------+------+ +--------+-----------+---------+
| roll_no | name | dept | | code | title | credits |
+---------+--------+------+ +--------+-----------+---------+
| 21 | Meera | CS | | CS201 | Databases | 4 |
| 22 | Ravi | CS | | CS202 | Networks | 3 |
| 23 | Anitha | EC | | EC101 | Circuits | 4 |
| 24 | Kumar | EC | +--------+-----------+---------+
| 25 | Divya | CS |
+---------+--------+------+ ENROL
+---------+--------+-------+
| roll_no | code | marks |
+---------+--------+-------+
| 21 | CS201 | 87 |
| 21 | CS202 | 74 |
| 22 | CS201 | 91 |
| 23 | EC101 | 65 |
| 25 | CS201 | 45 |
+---------+--------+-------+1. Selection — sigma
Selection picks the tuples that satisfy a condition. It is a horizontal operation: it never changes the columns.
NOTATION sigma <condition> ( R )
WRITTEN SELECT[condition](R)
SELECT[dept = CS](STUDENT)
+---------+-------+------+
| roll_no | name | dept |
+---------+-------+------+
| 21 | Meera | CS |
| 22 | Ravi | CS |
| 25 | Divya | CS |
+---------+-------+------+
degree unchanged (3), cardinality reduced (5 -> 3)Conditions may combine with AND, OR and NOT, and use the comparison operators. Selection is commutative: applying two selections in either order gives the same result, and two selections can always be merged into one with AND.
SELECT[dept = CS](SELECT[roll_no > 21](STUDENT))
= SELECT[roll_no > 21](SELECT[dept = CS](STUDENT))
= SELECT[dept = CS AND roll_no > 21](STUDENT)
All three are equivalent. An optimiser uses exactly this
freedom to reorder work.2. Projection — pi
Projection picks the attributes listed. It is a vertical operation, and it does one thing beginners forget: it removes duplicate tuples, because the result must be a relation and a relation is a set.
NOTATION pi <attribute list> ( R )
WRITTEN PROJECT[attributes](R)
PROJECT[dept](STUDENT)
+------+ NOT CS, CS, EC, EC, CS
| dept | Duplicates are removed, so five tuples
+------+ become two.
| CS |
| EC |
+------+
PROJECT[name, dept](STUDENT) -> 5 tuples, all distinct
degree reduced, cardinality may reduceDuplicate removal is the single most examined property of projection. Note that real query languages do not remove duplicates unless asked, which is one of the places where practice departs from the algebra.
Projection is not commutative with itself in a useful sense — the outer projection must use attributes the inner one kept:
PROJECT[name](PROJECT[name, dept](STUDENT)) valid
PROJECT[dept](PROJECT[name](STUDENT)) INVALID
dept no longer exists3. Rename — rho
Rename gives a relation, or its attributes, a new name. It exists so that an expression can refer to the same relation twice, which is what makes a self join possible.
NOTATION rho <new name> ( R )
rho <new name (a1, a2, ...)> ( R )
WRITTEN RENAME[S](STUDENT)
RENAME[S(r, n, d)](STUDENT)
Needed whenever one relation appears twice in an
expression, otherwise the attribute names are ambiguous:
RENAME[A](STUDENT) and RENAME[B](STUDENT)
then A.dept and B.dept are distinguishable.Combining the three
"The names of Computing students"
PROJECT[name]( SELECT[dept = CS](STUDENT) )
+-------+
| name |
+-------+
| Meera |
| Ravi |
| Divya |
+-------+
ORDER MATTERS. Select first, then project:
PROJECT[name](SELECT[dept = CS](STUDENT)) correct
SELECT[dept = CS](PROJECT[name](STUDENT)) INVALID
the projection already discarded dept, so the
selection has nothing to test.Why selection goes first — the optimisation rule
Selection reduces the number of tuples.
Projection reduces the number of attributes.
Doing selection EARLY means every later operator handles
fewer tuples. This is called PUSHING SELECTIONS DOWN, and
it is the first heuristic every optimiser applies.
Phase 14 returns to this. The point here is that the rule
is justified by algebra, not by guesswork.Common mistakes
- Forgetting projection removes duplicates. This is the most common lost mark in the whole phase.
- Projecting away an attribute a later selection needs. Select first.
- Thinking selection changes the columns. It never does.
- Omitting rename when a relation appears twice. The expression is then ambiguous.
- Writing conditions on attributes of another relation. Selection can only test attributes of its own input.
Exam and interview questions
- Define selection, projection and rename with notation and an example of each.
- Why does projection remove duplicates, and does a real query language do the same?
- Show that two selections can be merged into one, and state why an optimiser cares.
- Explain why selection should be applied before projection.
- When is the rename operator necessary?
Practice
Use the three sample relations above.
- Write the expression for the roll numbers of students scoring more than 70.
- Write the expression for the distinct departments that have at least one student.
- Explain why
SELECT[credits = 4](PROJECT[title](COURSE))is invalid. - Write an expression using rename that would let you compare two students from the same relation.
Conclusion
Selection filters rows, projection filters columns and removes duplicates, and rename makes reuse possible. Closure lets them compose, selection before projection is both correct and faster, and these three operators underpin every optimisation rule in Phase 14.