A Relational Model of Data for Large Shared Data Banks
Programs should name data by what it is and never by where it is stored, so that the arrangement underneath can change without breaking a single one of them.
Read the original ↗Eleven pages, no query language, no implementation, and one demand that every database since has been defending: the way you ask for data must not depend on the way it is stored. What is remembered as 'the relational model' is mostly later; what is in the paper is smaller, odder, and in places a different thing.
Included with a plan
This discussion is included with a plan. The first three lessons of every track are free, with their boards and videos. A plan unlocks every lesson, board, video, lab and paper for one price.
Related on chalk
The same idea as a board, lab, video or lesson.
- BoardData Models and Query Languagesthe relational shape drawn beside document and graph, and the declarative-versus-imperative panel, which is this paper's demand in one line
- BoardThe Query PlannerSQL says what and never how: the planner is the obligation the promise of independence created and the paper left to someone else
- BoardB-Tree on Diskan index as it really is, pages and all; the paper asked that programs survive an index coming and going, and this is what is coming and going
- LabThe selectivity crossoverone query and one index, and the engine rather than the caller decides at what fraction of the table to stop using it; drag the fraction and the plan flips under an unchanged query
- LessonData Models and Query LanguagesUses the board Data Models and Query Languages
- LessonThe Query PlannerUses the board The Query Planner
- LessonThe sentence that says whatUses the board The Query Planner
- LessonThe plan, runningUses the board The Query Planner
- LessonBuild sort and aggregate with a memory limitUses the board The Query Planner
- LessonB-Tree on DiskUses the board B-Tree on Disk
- LessonWhich shortcut to buildUses the board B-Tree on Disk
- LessonBuild three ways to joinUses the board B-Tree on Disk
Further reading
Read the original for the full argument and its evidence.
- The paper (ACM, Communications of the ACM, June 1970) ↗Eleven pages, 377-387. Section 1.2 is the problem and the five-structure example; section 2.1.4 is the connection trap; section 2.3 is consistency. The text read for this discussion was the scan hosted at seas.upenn.edu/~zives/03f/cis550/codd.pdf.
- PostgreSQL: SELECT ↗Later work: where the default flips from a set to a bag, in the sentence about SELECT ALL and SELECT DISTINCT.
- PostgreSQL: comparison functions and operators ↗Later work: what a comparison yields when an input is null, which is the thing the 1970 calculus has no place for.