Relational Database Course Resources

This course offers a number of resources to help you understand key concepts such as:

1. Relational Database Management Systems
2. Primary key
3. Secondary key
4. Normalization
5. Third normal form

Additional resources related to relational database design can be found throughout the site as you tour it, including links to the course's own modules and other helpful material.

None of these resources are required reading in the sense of homework; they exist to be used when you need them, a term you half-remember from an earlier lesson, a concept you want to see explained a second way, a module you want to revisit before moving on. Knowing what is available, and where to find it, is worth five minutes now so you are not searching for it later in the middle of an exercise.

Throughout this course, definitions of key terms can be reviewed in the Relational Database Design Glossary. These terms appear as italicized words in this lesson and the pages that follow, often with a corresponding footnote definition. To search for a specific term, enter it into the text box located at the top of each page.
The glossary is organized alphabetically rather than by module, which makes it well suited to the kind of lookup you will actually need: you will rarely want to browse it start to finish, but you will frequently want to check one specific term, entity, candidate key, referential integrity, against its precise definition while you are in the middle of an exercise. Bookmarking the glossary page itself, rather than relying on the italicized links inside each lesson, is the fastest way to get back to it.

Students who do the best in this course have generally made a small investment in a good reference text. Database Design for Mere Mortals: A Hands-On Guide to Relational Database Design, by Michael J. Hernandez, is the one recommended here.

Separate from the question of which book to buy, it is worth understanding why a database management system is worth using at all rather than, say, a collection of flat files. The advantages are substantial:

• Data independence and efficient access. Database application programs stay independent of the details of data representation and storage. The conceptual and external schemas provide independence from physical storage decisions and logical design decisions respectively. A DBMS also provides efficient storage and retrieval mechanisms, including support for very large files, index structures, and query optimization.
• Reduced application development time. Since the DBMS already provides functions such as concurrency control and crash recovery, along with high-level query facilities, only application-specific code needs to be written. Vendor-supplied application development tools make this easier still.
• Data integrity and security. The view mechanism and the authorization facilities of a DBMS provide a powerful access control mechanism. Updates that violate the semantics of the data can be detected and rejected automatically, provided the appropriate integrity constraints have been specified.
• Data administration. By providing a common umbrella for data shared across many users, a DBMS facilitates maintenance and administration. A good database administrator can shield end users from the chores of fine-tuning data representation, periodic backups, and similar tasks.
• Concurrent access and crash recovery. A DBMS supports the notion of a transaction, conceptually a single user's sequential program, letting users write transactions as though they were running in isolation against the database. The DBMS interleaves transactions for performance while ensuring conflicting operations are not allowed to proceed concurrently, and it maintains a continuous log of changes so that, after a crash, the database can be restored to a transaction-consistent state: incomplete transactions are undone, so the recovered state reflects only completed work.

These five advantages are the reason relational database design, the subject of this course, matters in the first place. A well-designed database only delivers on data independence, integrity, and reliable recovery if the entities, keys, and relationships underneath it were modeled correctly to begin with; a DBMS can enforce a constraint, but it cannot invent one that a flawed design never anticipated.

This course is organized into seven modules, each building on the last:

• Database Design (this module)
• Database Structure
• Database Life Cycle
• Requirements Analysis
• Attributes and Entities
• ER Diagrams
• Diagram Conventions

Each link jumps to that module's own introduction, so you can preview what is ahead or jump back to review a module you have already completed. Taken together with the glossary and the recommended reading above, these module introductions are the quickest way to reorient yourself if you ever lose track of where a particular concept fits in the overall course.

A reasonable way to think about the resources covered in this lesson is by when you will actually reach for each one. The glossary is for the moment you hit a term mid-exercise and need a precise definition rather than a vague recollection. The recommended book is for when you want more depth or a second explanation of a concept than a single lesson can provide. The module list is for when you want to see where you are in the overall course, or jump back to refresh a concept from an earlier module before building on it in a later one. None of them substitute for working through the lessons and exercises themselves; they exist to support that work, not replace it.

After completing some exercises, you will be required to type or paste your answer into a text submission box. Copying and pasting is generally easy to accomplish, and there is no particular formatting expected beyond a clear, legible answer to whatever the exercise asked for.

The next lesson discusses the Relational Database Design learning environment.