Relational Database Analogy

Relational databases let you use information in the same manner that you think about information.
For example, suppose you have an appointment with your attorney and you need to take a file to the office when you go to see the attorney. You probably will make a notation in your calendar that you have the appointment and that you need to take the file with you when you go. What you do not do is make a copy of the file, place it in your calendar, and then take that copy with you. What you are really doing is relating the appointment of the attorney with the file you need.

Imagine a relational database as a vast and meticulously organized library. Each book in this library represents a table within the database. Just as a book is divided into chapters and pages, each table is segmented into rows and columns. Rows are akin to the individual pages, each holding a unique piece of information, while columns are like the chapters, categorizing this information under specific headings. Now, envision the librarians as the database management system. They possess the knowledge and authority to retrieve, organize, and update the books (tables) efficiently. When a visitor requests a specific piece of information, the librarians navigate through the library, consulting various books, and even cross-referencing between them, just as a database management system performs queries across different tables.
The index cards in the library's catalog system can be compared to the indexes in a database. These cards provide a quick reference to locate the needed book and page, similar to how database indexes swiftly guide the system to the correct row and column. Moreover, the relationships between the books, where one might reference another for additional information, mirror the relationships in a relational database. For example, a book on world history might reference another on ancient civilizations for more detailed information. Similarly, in a database, one table can reference another, creating a network of interconnected data. In this vast library, every piece of information is stored with precision and purpose, accessible through a system of complex yet efficient connections, mirroring the structured and powerful nature of a relational database.

This is how relational databases work. When you retrieve the information from the database, you simply say, "I want this piece of information and those items that relate to it." For example, with the attorney appointment, your request would be: " Tell me what time the appointment is to meet with Ms. Smith, and give me the file(s) I will need for the matters we will be discussing." You just requested the related materials. That is the whole point behind SQL and relational databases. You ask for what you need and let the database do the work and go get it for you.

The relational data model was first introduced by Ted Codd of IBM Research in 1970 in a classic paper (Codd 1970), and it attracted immediate attention due to its simplicity and mathematical foundation. The model uses the concept of a mathematical relation, which looks somewhat like a table of values, as its basic building block, and has its theoretical basis in set theory and first-order predicate logic. In this module we discuss the basic characteristics of the model and its constraints. The first commercial implementations of the relational model became available in the early 1980s, such as the SQL/DS system on the MVS operating system by IBM and the Oracle DBMS. Since then, the model has been implemented in a large number of commercial systems. Current popular relational DBMSs (RDBMSs) include DB2 and Informix Dynamic Server (from IBM), Oracle and Rdb (from Oracle), Sybase DBMS (from Sybase) and SQLServer and Access (from Microsoft). In addition, several open source systems, such as MySQL and PostgreSQL make use of the relational model.