Relational Database Course Requirements

Before you start the course project, it helps to know exactly what you need to have on hand, and what you do not. This lesson covers both: the platform and software requirements for taking the course itself, and the downloadable materials the course project is built around.

This course can be taken on Windows, Mac, or Linux platforms. Nothing in the course depends on a specific operating system; the concepts and diagrams you will work with are the same regardless of which computer you use to follow along. That platform independence is itself worth noticing: it is a direct consequence of the conceptual and logical design stages you are about to learn, which stay deliberately separate from any one operating system or database product. The design methodology works the same way whether you eventually implement it on Oracle, SQL Server, PostgreSQL, or anything else, which is exactly the point.

This course does not require any specific database software. The methodology you are learning is about how to think through a design, not about operating any particular tool, and every diagram in this course can be sketched perfectly well on paper. To read the downloadable case study the course project is based on, you will want a word-processing application capable of opening a Word document, such as Microsoft Word.

If you would rather build your diagrams digitally as you go, a handful of free or low-cost tools are worth knowing about, though none of them are required: Oracle Data Modeler is a free, downloadable desktop application; dbdiagram.io and DrawSQL are both browser-based tools with free tiers that let you sketch an entity-relationship diagram without installing anything at all. Any of these, or a pencil and paper, will work equally well for the exercises in this course.

Three items are available for download below:

1. The case study the course project is based on. This outlines the characteristics and data-retrieval needs of Stories on CD, Inc., a fictional mail-order company selling audiobooks.
2. A copy of the database design diagram that represents the culmination of the course project.
3. A table comparing database terminology across the different phases of the design and creation process, since equivalent ideas often go by different names at different stages.

The case study is worth reading closely before the first exercise, rather than skimming it as background. Later lessons will ask you to pull specific requirements out of it, the kinds of orders Stories on CD processes, what information it needs to track about each customer, how its inventory works, and a design built on a careless first read tends to need rework later. The terminology comparison table is worth keeping close by throughout the course as well; a term introduced as "entity" in the conceptual stage may reappear as "table" once physical implementation is discussed, and the table exists specifically to keep that mapping straight as you move between stages.

The following book can be purchased from the book store:
Relational Database Design

The skills this course teaches, entities, attributes, keys, relationships, normalization, and ER diagrams, are the foundation of relational database design, not its full extent. As you grow past this fundamentals course, the broader field of data modeling and analysis extends into areas such as data warehousing and ETL pipelines, NoSQL and big-data platforms, business intelligence and reporting tools, cloud-hosted databases, and data governance and compliance.

None of that is required for this course, and none of it will be tested here; it is mentioned only so you know the fundamentals you are about to learn are a starting point, not a ceiling. A data modeler who has mastered the material in this course, entities, keys, relationships, and normalization, already has the conceptual vocabulary needed to pick up any of those more advanced areas later; a data warehouse's star schema is still built from entities and relationships, and a well-governed dataset still depends on the same referential integrity this course teaches from the beginning.

It is worth being honest about why this course starts where it does rather than somewhere more advanced. Every one of the areas mentioned above, data warehousing, cloud architecture, machine learning pipelines, assumes a working knowledge of exactly what this course teaches: how to identify entities, model relationships correctly, and normalize a design so it does not carry hidden redundancy. Skipping ahead to the advanced material without that foundation tends to produce designs that work in a demo and fail under real use, the same missing, incorrect, and mismatched data problems introduced in the first lesson, just dressed up in more sophisticated tooling.

Logical database schema design is concerned with organizing data into a logical form, independent of any specific database product, before physical implementation decisions are made. This is a distinct stage from the conceptual model covered in the previous lesson: a conceptual model describes what the business needs in plain language, while a logical model adds the detail of entities, attributes, and keys to that conceptual picture, still without committing to a particular database system's data types or storage mechanics.

A few things make logical design a genuinely difficult, careful process:

1. Identifying and selecting the set of attributes that actually belong to each entity, no more, no fewer. It is tempting to add an attribute "just in case" it turns out to be useful later, but every attribute that does not clearly belong to the entity it sits on is a future source of redundancy or confusion. The discipline here is asking, for each proposed attribute, whether it describes the entity itself or something else entirely.
2. Deciding how relations connect to one another in a way that supports the navigation the business will actually need. A relationship that looks correct in isolation can still fail to support a real business question if it was modeled in the wrong direction or at the wrong cardinality; this is why requirements analysis, covered later in this course, has to come before the relationships are finalized, not after.
3. Anticipating, in general terms, how the design will eventually need to perform once it is implemented, even though the specific indexing and storage decisions that affect performance belong to the later, physical design stage. A logical design does not need to know which columns will eventually be indexed, but it does need to produce entities and relationships that a physical design can actually index efficiently once that stage arrives.

A good relational schema contains a set of relevant attributes for each entity, where every attribute relates, directly or indirectly, to the others in that same relation. A well-designed relation requires minimal storage space and carries minimal data redundancy, properties achieved through the normalization principles introduced in the previous lesson.

Applied to Stories on CD, Inc., this is the stage where a vague idea like "we need to track what customers order" turns into a decision about exactly which attributes belong on the Customer entity (name, address, phone number) versus the Order entity (order date, status, the customer who placed it). Attaching an attribute to the wrong entity at this stage, for example, treating "order date" as a property of the customer rather than the order, is a mistake that becomes harder to untangle the longer it goes unnoticed; getting the attribute assignment right at the logical stage is what the normalization principles from the previous lesson build on.

Keeping logical design properly separated from physical design is not just a matter of vocabulary. A logical model that stays independent of any one database product can move to a different database engine later with little rework, since the entities, attributes, and relationships do not change just because the underlying storage engine does. A design that mixes physical decisions, specific data types, indexing choices, storage parameters, into the logical stage loses that flexibility, and often has to be substantially reworked the moment circumstances change, a migration to a new platform, a vendor change, or simply outgrowing the original engine's capabilities.

A short checklist for this lesson:

• Confirm you can work on Windows, Mac, or Linux, whichever you already have; no specific platform is required.
• Have a word processor available to read the Stories on CD, Inc. case study, and optionally a diagramming tool such as Oracle Data Modeler, dbdiagram.io, or DrawSQL if you would rather build diagrams digitally than by hand.
• Download the case study, the sample design diagram, and the terminology comparison table before starting the exercises.
• Keep the conceptual, logical, and physical design stages distinct in your own thinking as you move through the rest of the course; this lesson's discussion of logical schema design builds directly on that separation.

With the platform, software, and downloadable materials for this course now in hand, and the logical design stage placed correctly between the conceptual model and physical implementation, the next lesson turns to the learning resources available through this website to support you as you work through the rest of the course.