Did we say that in RDBMS the data is maintained in "special tables" called Relations? But nevertheless there are tables. "Table" is an obvious way of storing the data as even known to most non-technical of us.
(Dr. Codd does not seem to have done much new at this stage! Right? But then who did? - Newton or Archemedes also only theorised obvious experiences of the common people through ages. Dude, Scientists just don't see, they observe the same things as we do and think about them differently.)So we create a table here for our example of students studying different languages in a computer institute -
- How do you identify each row uniquely (different from all others)?
- Is there any problem you think faced with update (change) of any values?
- Is there any problem you think faced with deletion of any row from the table?
- Can you identify any problem with inserting a row in this table with this given structure?
If there is a problem associated with any operation then that is identified as an anomaly of the same type as the operation. So those quetions above are aimed at if you can locate some anomalies in the above table with respect to the four operations of - select, update, insert and delete. (and you don't have to consider these operations being done using a computer or any particular computer language as the theory of database is not related to any computerization; remember the databases have always been around there, computers existed or not.)
I am sure you have identified the answers to those questions by now -
- You require to consider student id and Subject (in combination) to identify each row uniquely.
- If you want to update the fees of subject Oracle then it has to be updated at number of places as the number of students opting for the subject Oracle. (Same is the case with if student id 2 changes his phone number). [update anomaly]
- If the student id 1 wants to leave the class then if I delete this row I loose the information about the subject C that its cost is 300. [delete anomaly]
- Why we can't see the subject VB and its fees? Since there is no student joining for this subject VB. [insert anomaly]
- What is the reason behind all those anomalies?
- Whether a student joins because a subject is taught or a subject is taught because a student joins for it? Which fact comes first - Institute teaches a particular subject or a student joins for a particular subject?
- What is the solution / how to reorganize / structure the table so that it will eliminate those anomalies?
- What is the basis for the restructuring of the table?