The relational database model is all about tables. All of the data is stored in a tabular format, and relationships between tables are expressed through data shared among those tables. Tables in relational databases are just like tables in HTML. They consist of rows and columns. Each row represents a record in the database, and each column represents one field in each of the records.
A group of tables is generally referred to as a schema, which conceptually isn't all that different from an XML schema. In a schema, some or all of the tables are generally related to one another. Let's look at how those relationships work. Ordinarily, every table contains a column (or group of columns) that contains data that uniquely identifies that row in the table. In most cases, this is an ID field that simply contains a number that sets that row apart from the others in the table. This value is referred to as the primary key. In relational database design, the primary key is extremely important because it is the root of relationships between tables.
Here's a simple example. Let's say you have a table called
students table contains, among other bits of data, a column called
id_students. The table might also include the student's name, address, and phone number. You might also have a second table, called
majors. This table contains the major and minor for all of the students, under the assumption that no student has more than one major or minor.
This is what is referred to as a one-to-one relationship. Each record in the
students table can have one corresponding row in the
majors table. There are two other types of relationships between tablesone-to-many and many-to-many. The students table contains a column called
id_students, which serves as its primary key. The
majors table should contain a column that contains student IDs. This is referred to as a foreign key, because it's a reference to a primary key in another table. The foreign key is used to implement the one-to-one relationship between the records in the two tables.
In a one-to-many relationship, a record in one table can have a reference to many records in a second table, but each record in the second table can have a reference to only one record in the first table. Here's an example: Let's say I create a table called
grades, which contains a column for student IDs as well as columns for class names and the grades themselves. Because a student can take multiple classes, but each grade applies to only one student, the relationship between
grades is a one-to-many relationship. In this case,
id_students in the
grades table is a foreign key relating to the
An example of a many-to-many relationship is the relationship between students and classes. Each student is usually enrolled in several classes, and each class usually contains multiple students. In a relational database, such a relationship is expressed using what is sometimes referred to as a joining tablea table that exists solely to express the relationship between two pieces of data. The schema contains two tables,
classes. You already know about the
students table; the
classes table contains information about the classes offeredthe name of the professor, the room where the class is held, and the time at which the class is scheduled.
Before you can deal with integrating databases and XML, you need to understand both databases and XML. You've been learning about XML for a while now, so consider this a crash course in database theory.
classes, you need a third table, called
classes_students (or a similarly descriptive name). At a bare minimum, this table must include two columns,
id_classes, both of which are foreign keys pointing to the
classes tables, respectively. These two columns are used to express the many-to-many relationship. In other words, both of the other two tables have one-to-many relationships with this table. Using this table, each student can be associated with several classes, and each class can be associated with any number of students. It may also contain properties that are specific to the relationship, rather than to either a student or a class specifically. For example, a student's grade or her attendance record for the class might be stored in this table. This table structure is illustrated in Figure 19.1.