Overview

What the course covers

CIS 4720 is about turning business rules into a database that holds up. We start with plain sentences from a store manager, draw the entities and relationships, decide connectivity and participation, and carry the design down through four levels of abstraction until it is running SQL against real tables.

Along the way students write queries, joins, and constraints; normalize schemas to remove redundancy; and work with transactions on live databases. The three pages below are the reference illustrations I use in lecture. Each one takes a single small model and reads every mark on the diagram.

SELECT c.last_name, COUNT(*) AS invoices, SUM(i.invoice_total) AS billed FROM customer c JOIN invoice i ON i.customer_id = c.customer_id GROUP BY c.customer_id, c.last_name ORDER BY billed DESC;
At a Glance
  • Course: CIS 4720, Database Management and SQL
  • Modeling: Entity relationship, Crow's Foot notation
  • Abstraction: External, conceptual, internal, physical
  • Language: SQL, joins, constraints, transactions
  • Text: Coronel & Morris, Database Systems, 14th ed.
Reference

Reference pages

Four short pages. Read them in order the first time; after that they stand on their own.

๐Ÿ“
Chapter 2 review Study guide
A one page summary of Coronel and Morris Chapter 2: relational terminology, DBMS versus RDBMS, DDL, business rules, the entity relationship building blocks, the object oriented model, and Big Data with Hadoop and MapReduce. Every term defined, with the deeper pages linked.
๐Ÿ”‘
Chapter 3 review Study guide
A one page summary of Coronel and Morris Chapter 3: keys from superkey to primary key, entity and referential integrity, the data dictionary and system catalog, composite and bridge entities, functional dependence, and the eight relational algebra operations behind SQL.
Vocabulary

Three ideas the pages keep coming back to

๐Ÿ”—
Connectivity vs participation

The maximums fix whether a relationship is 1:1, 1:M, or M:N. The minimums decide only whether a row is required. They are read separately.

๐ŸŒ‰
Why M:N needs a bridge

A many to many relationship describes the business fine but cannot be built directly. A bridge entity splits it into two 1:M relationships you can implement.

๐Ÿ“
A relation is a set

Formally a table is a set of tuples with no order and no duplicates. That is why rows come back unordered unless you ask for a sort.

Related

More from the course