Before digging deeper into the workings of relational database management systems (RDBMS's), it's a good idea to take a step back and look briefly at the history of the relational model and how it fits into the bigger picture of DBMS's in general. The relational model of data storage was originally proposed by an IBM employee named Edgar Codd in the early 1970s. Prior to that time, computerized data storage techniques followed a "navigational" model that was not well suited to searching. The ground-breaking aspect of Codd's model was the allocation of data to separate tables, all linked to one another by keys - values that uniquely identify particular records. The process of breaking data into multiple tables is referred to as normalization.
If you do much reading on the relational model, you're bound to come across the terms relation, attribute and tuple. While purists would probably disagree, for our purposes you can consider relation to be synonymous with table, attribute with the terms column and field, and tuple with the terms row and record.
SQL, which we started learning about in Lesson 1, was developed in response to Codd's relational model. Today, relational databases built around SQL dominate the data storage landscape. However, it is important to recognize that the relational model is not the only ballgame in town. Object-oriented databases arose in the 1980s in parallel with object-oriented programming languages. Some of the principles of object-oriented databases (such as classes and inheritance) have made their way into most of today's major RDBMS's so it is more accurate to describe them as object-relational hybrids.
More recently, a class of DBMS's that deviate significantly from the relational model has developed. These NoSQL databases seek to improve performance when dealing with large volumes of data (often in web-based applications). Essentially these systems sacrifice some of the less critical functions found in a RDBMS in exchange for gains in scalability and performance.