Welcome to Lesson 1 of Module 3 on the relational data model. I'm going to start with an important practical question that I want you to think about throughout this lesson. Why is the relational data model commercially dominant? Module 3 is a major change in the course. Module 2 was informational, providing background and context for other modules. Module 3 emphasizes concrete skills and knowledge about the relational data model in the SQL standard. You will apply your knowledge and skills and practice and graded problems using a SQL DBMS, either Oracle Cloud or PostgresSQL. This lesson provides your initial background on the relational data model, so the learning objectives are modest. I want you to identify components in sample tables using additional rows that you add. To become familiar discussing relational databases in several contexts, you should be able to list alternative terminology used for the basic concepts. Relational database systems were originally developed because of familiarity and simplicity. Because tables are used to communicate ideas in many fields, the terminology of tables, rows and columns is familiar to most users. A relational database consists of a collection of tables. Each table has a heading or definition part and a body or content part. The heading part consists of the table name and column names. For example, a student table may have columns for student number, name, street, address, city, state, zip, class, freshman software, etc. Major and cumulative grade point average, GPA. The body shows the rows of the table. Each row in a student table represents a student enrolled at a university. A student table for a major university, may have 30-50 columns and more than 30,000 rows, too many to view at one time. To understand a table is also useful to view some of its rows. A table listing or data sheet shows the column names in the first row and the body in the other rows. The sample student table contains three sample rows representing university students. To facilitate communication, the naming convention for column names uses a table abbreviation STD, followed by a descriptive name. Because column names are often used without identifying the associated tables, the abbreviation supports easy table association. Mixed case highlights the different parts of a column name. It is not enough to understand each table individually. To understand a relational database, connections or relationships among tables must also be understood. The rows in a table are usually related to rows in other tables. Matching those identical values indicate relationships between tables. Consider the sample enrollment table in which each row represents a student enrolled in an offering of a course. The values in the StdNo column of the enrollment table, that's StdNo values in the sample student table. For example, the first, third rows in enrollment table, have the same STD number value, 1, 2, 3, 4, 5, 6, 7, 8, 9 as the first row of the student table. Likewise, the values in the OfferNo column of the enrollment table match the OfferNo column in the offering table. This graphical depiction of matching values can clarify the concept of relationships among tables. In the table listings, matching values are difficult to identify. This graphical depiction only works on small sample tables as the arrows cross and become difficult to follow. In the graphical depiction, you should see that the first student row, 1, 2, 3, 4, 5, 6, 7, 8, 9, is related to the first and third enrollment rows. Likewise, the first offering row 1, 2, 3, 4, matches to the first two enrollment rows. The concept of matching values is crucial in relational databases. As you will see, relational databases typically contain many tables. Even a modest sized database can have 10-15 tables. Large databases can have hundreds of tables. To extract meaningful information, it is often necessary to combine multiple tables using matching values. By matching on Student.StdNo and Enrollment.StdNo, you can combine the student enrollment tables. Similarly by matching on Enrollment.OfferNo and Offering.OfferNo, you could combine the enrollment and offering tables. As you will see in Module 4, the operation of combining tables on matching values is known as a join. Understanding the connection between tables or columns on which tables can be combined is crucial for extracting useful information. You should be aware that other terminology is used besides table, row and column. The divergence in terminology is due to the different groups that use databases. The table-oriented terminology appeals to end-users. The set-oriented terminology appeals to academic researchers. In the record-oriented terminology appeals to information systems professionals. In practice, these terms may be mixed. For example, in the same sentence, you might hear both tables and fields. You should expect to see a mix of terminology in your career. Let's wrap up this lesson, giving you an initial background on the relational data model. Relational databases have been the dominant commercial standard in the database industry for more than 35 years. The relational data model is commercially dominant for several reasons. The idea of tables to organize data is simple and familiar. The relational data model has strong theoretical foundation from academic and commercial research. Many commercial, university and open source products have implemented the relational model over more than 40 years. There's an important commercial standard, SQL that has evolved over 35 years. I encourage you to use small sample tables to solidify your understanding of the relational model. You should try adding your own sample rows to the table shown in the notes, and identify the components, especially matching values among rows in different tables.
