<p>It seems to me that you're thinking about this backwards.</p>
<p>The driving question I use when devising curriculum is, &quot;What can I give my students of lasting value <em>that they can't easily pick up on their own?&quot;</em></p>
<p>The goal of an academic course shouldn't be vocational skills.  Vocational skills have high value, and we include them when we can, but including them should be a secondary consideration when considering the heart of a good course.</p>
<p>This is because, in a good course of study, we're ideally doing something deeper.  Our goal is to help students build neural structures that will help them flexibly deal with the world as it changes <em>in directions that we cannot predict at the present</em>.  Since we don't know what's coming around the corner, more abstract ideas are also more valuable ones, as they enable both flexibility and strongly categorical thinking.</p>
<p>Imagine if, in 10 years, relational databases take a back seat to some absolutely fantastic, easy to use, AI-driven iteration of nosql databases.  What, then, would they carry away from a 400-level course of study focused squarely on the concrete?  Not much.</p>
<p>Relational algebra isn’t just a &quot;tool for databases&quot;; teaching it is meant to create a conceptual bridge to larger ideas that build a student's ability to reason formally about data, queries, and computational structures.</p>
<p>When you provide these formalisms, you provide cognitive frameworks that extend beyond databases and equip students to think about abstraction, optimization, logic, and more advanced computational problems. By teaching it, you're giving students a long-lasting intellectual toolkit that will serve them in many other areas of computer science.  (This topic touches on distributed systems, data sciences, algorithmic development, and other fields that don't yet exist.)</p>
<p>All of this will help to nurture deeper understanding and flexible, computational thought.</p>
<p>And to put this one more way, by your own description, <em>you can pick up the concrete stuff on the job</em>, but you're much less likely to gain the abstract underlying system of thought -- the thing that can be applied to other areas of computation and development! -- without a push and without help. That's something meaningful you can provide in an academic course that they are unlikely to pick up on their own.</p>

CC BY-SA 4.0
2024-10-23T22:08:46.067Z
Thanks Ben, I really appreciate this perspective. I've been thinking about them as related concept that support each other instead of distinct subjects with their own benefits.

Do you have any thoughts on the best organization to teach them? My first year I focused heavily on conceptual data modeling and RA in the first half, then applied them to relational databases in the latter portion. The 2nd year, I opted to teach them side by side to illustrate how one translates to the other. It seems like both ways had some pros and cons, but I'm curious what those with more experience think.
Alecg_O
CC BY-SA 4.0
2024-10-23T23:28:01.540Z
@Alecg_O I've never actually taught relational algebra, but my bias tends towards concrete before abstract, or side by side.  This is because we build up abstractions more easily from concrete examples. Since these two support each other and mix well, I'd bet you could make a pretty powerful experience out of a side by side approach with a bit of tinkering over a few runs of the course.
Ben I.
CC BY-SA 4.0
2024-10-22T16:57:21.297Z
2024-10-23T19:42:16.580Z
2024-10-23T19:42:16.580Z
Ben I.
<blockquote>
<p>I didn't take a DBs course in school, and I hadn't even heard of relational algebra until I started prepping my course for the first time. Despite that, the concepts were very familiar due to my SQL experience. Yet in my 5 years writing queries and managing DBs, I've never seen or needed to use relational algebra explicitly.</p>
</blockquote>
<p>It does seem surprising that you haven't <em>heard</em> of RA before - I suppose it suggests that you're learning as much from the prepared course you've been given to teach, as your students are.</p>
<p>It can however be a very muddled subject to talk about and to teach.</p>
<p>A main confounding factor is that SQL - as a language that controls real-world SQL engines - is based on EF Codd's RA, but SQL has never been completely faithful to Codd's description of RA.</p>
<p>One notable discrepancy off the top of my head, SQL has always dealt in what mathematicians call &quot;multisets&quot; or &quot;bags&quot; of records (that is, sets that allow duplicates) and a &quot;set&quot; when spoken of by an SQL practitioner is synonymous with a &quot;multiset&quot; (or a &quot;table&quot; in everyday terms). Whereas Codd talks about &quot;sets&quot; in connection with RA and he actually <em>means</em> sets in the mathematical sense.</p>
<p>These kinds of little details are rarely remarked upon, and can lead to considerable confusion between the understandings which advanced practitioners of SQL have, and the understandings and terminology which academics and students acquire.</p>
<blockquote>
<p>Does relational algebra still provide enough value to warrant spending significant time on it in class? Or could it be made more of a historical footnote, enabling more time for hands-on practice and an expanded focus on non-relational DB types?</p>
</blockquote>
<p>The main question would be, what value you're trying to provide?</p>
<p>In my view, the syntax originally associated with RA is unnecessary to learn and inferior to SQL. The terminology of RA is also quite unhelpful - with tables called &quot;relations&quot;, rows/records called &quot;tuples&quot;, and so on. The only reason for learning these details is if you wanted to be able to read historical documents, or to interact with theoretical materials steeped in this jargon.</p>
<p>There is however a basic conceptual framework associated with RA that would be very useful to teach explicitly, including the fact that it is a relatively rigorous system of algebra in which tables (not &quot;scalars&quot;) are the primary thing of focus along with a system of &quot;relational&quot; (i.e. table) operators which accept tables as arguments and produce tables as results. The fact that these relational operators can manipulate the shape of tables structurally as well as manipulating the individual values within the tables, is a conceptual aspect of RA and SQL which is (or for a long time, was) unique amongst the mainstream programming languages.</p>
<p>My overall advice though would be to brush up on the things you've been given to teach, especially before attempting to radically innovate the priorities of the existing curriculum.</p>

CC BY-SA 4.0
2024-10-28T17:32:15.470Z
Thanks Steve. I did take a deep dive into RA ahead of my first year teaching this course, and I actually enjoy doing it as an intellectual exercise. Like I said in the background, at this point I've taught RA successfully for multiple semesters, and am only now considering some modifications. I would never just toss course units in and out without understanding their value, which is why I'm here.
Alecg_O
CC BY-SA 4.0
2024-10-28T22:15:53.273Z
@Alecg_O, are you in a position now then, as an educator with some experience, to understand what role RA is playing in your understanding of the topic, or what usefulness your students are deriving from that aspect of your teaching? Curriculums are designed around these concerns, in that the educator has to explicitly articulate all the information necessary to reproduce their own understanding (or so much a part of it as is relevant to the particular course) in the minds of the students.
Steve
CC BY-SA 4.0
2024-10-25T15:02:19.617Z
2024-10-25T15:02:19.617Z
Steve
<p>Relational algebra is part of the most recent ACM/IEEE/AAAI curricular guidelines for a CS undergraduate degree. See: <a href="https://www.acm.org/articles/bulletins/2024/june/cs2023-curricular-guidelines" rel="nofollow noreferrer">Computer Science Curricula 2023</a>.</p>
<p>You can see this in the Data Management section, DM-Querying: Query Construction (document p. 118). The first three items in that list are:</p>
<ol>
<li>SQL Query Formation (CS Core)</li>
<li>Relational Algebra (KA Core)</li>
<li>SQL (KA Core)</li>
</ol>
<p>(and 5 more Non-core items)</p>
<p>Note that CS (Computer Science) Core are topics every CS graduate <em>must</em> know, the KA (Knowledge Area) Core are topics every student <em>should</em> know, and the Non-core items are electives they <em>might</em> know.</p>
<p>So the relational algebra topic is something that the top professional computing organizations agree every CS graduate should know, and there would be a gap in your students' qualifications (assuming they're CS degree students) if they didn't get that.</p>

CC BY-SA 4.0
2024-12-09T03:50:29.250Z
2024-12-10T14:44:39.780Z
2024-12-10T14:44:39.780Z
Daniel R. Collins
<p>Background: I'm a professional data engineer and also teach as an adjunct. I'm prepping to teach a 400-level databases course for the 3rd time. Previously I stuck close to the previous instructor's course outline, which devoted a section to learning relational algebra.</p>
<p>I didn't take a DBs course in school, and I hadn't even heard of relational algebra until I started prepping my course for the first time. Despite that, the concepts were very familiar due to my SQL experience. Yet in my 5 years writing queries and managing DBs, I've never seen or needed to use relational algebra explicitly.</p>
<p>I can see where it could still have value to students though. Some may find it easier to learn and translate the concepts than to learn SQL directly. Additionally, having the notation is handy later in the course when we get to functional dependencies and schema normalization.</p>
<p>Does relational algebra still provide enough value to warrant spending significant time on it in class? Or could it be made more of a historical footnote, enabling more time for hands-on practice and an expanded focus on non-relational DB types?</p>

<curriculum-design><databases>
How important is relational algebra in 2024?
# How important is relational algebra in 2024?

(Asked by: username_0 on 2024-10-22)

Background: I'm a professional data engineer and also teach as an adjunct. I'm prepping to teach a 400-level databases course for the 3rd time. Previously I stuck close to the previous instructor's course outline, which devoted a section to learning relational algebra.

I didn't take a DBs course in school, and I hadn't even heard of relational algebra until I started prepping my course for the first time. Despite that, the concepts were very familiar due to my SQL experience. Yet in my 5 years writing queries and managing DBs, I've never seen or needed to use relational algebra explicitly.

I can see where it could still have value to students though. Some may find it easier to learn and translate the concepts than to learn SQL directly. Additionally, having the notation is handy later in the course when we get to functional dependencies and schema normalization.

Does relational algebra still provide enough value to warrant spending significant time on it in class? Or could it be made more of a historical footnote, enabling more time for hands-on practice and an expanded focus on non-relational DB types?

**Tags:** curriculum-design, databases


---

## 3 answers

### Answer by username_1 on 2024-10-22. Score: 8 | Accepted answer

It seems to me that you're thinking about this backwards.

The driving question I use when devising curriculum is, "What can I give my students of lasting value *that they can't easily pick up on their own?"*

The goal of an academic course shouldn't be vocational skills. Vocational skills have high value, and we include them when we can, but including them should be a secondary consideration when considering the heart of a good course.

This is because, in a good course of study, we're ideally doing something deeper. Our goal is to help students build neural structures that will help them flexibly deal with the world as it changes *in directions that we cannot predict at the present*. Since we don't know what's coming around the corner, more abstract ideas are also more valuable ones, as they enable both flexibility and strongly categorical thinking.

Imagine if, in 10 years, relational databases take a back seat to some absolutely fantastic, easy to use, AI-driven iteration of nosql databases. What, then, would they carry away from a 400-level course of study focused squarely on the concrete? Not much.

Relational algebra isn’t just a "tool for databases"; teaching it is meant to create a conceptual bridge to larger ideas that build a student's ability to reason formally about data, queries, and computational structures.

When you provide these formalisms, you provide cognitive frameworks that extend beyond databases and equip students to think about abstraction, optimization, logic, and more advanced computational problems. By teaching it, you're giving students a long-lasting intellectual toolkit that will serve them in many other areas of computer science. (This topic touches on distributed systems, data sciences, algorithmic development, and other fields that don't yet exist.)

All of this will help to nurture deeper understanding and flexible, computational thought.

And to put this one more way, by your own description, *you can pick up the concrete stuff on the job*, but you're much less likely to gain the abstract underlying system of thought -- the thing that can be applied to other areas of computation and development! -- without a push and without help. That's something meaningful you can provide in an academic course that they are unlikely to pick up on their own.

> **Comments:**
> **username_0**: Thanks Ben, I really appreciate this perspective. I've been thinking about them as related concept that support each other instead of distinct subjects with their own benefits.  Do you have any thoughts on the best organization to teach them? My first year I focused heavily on conceptual data modeling and RA in the first half, then applied them to relational databases in the latter portion. The 2nd year, I opted to teach them side by side to illustrate how one translates to the other. It seems like both ways had some pros and cons, but I'm curious what those with more experience think.  
> **username_1**: @username_0 I've never actually taught relational algebra, but my bias tends towards concrete before abstract, or side by side.  This is because we build up abstractions more easily from concrete examples. Since these two support each other and mix well, I'd bet you could make a pretty powerful experience out of a side by side approach with a bit of tinkering over a few runs of the course.  

---

### Answer by username_2 on 2024-10-25. Score: 2

> I didn't take a DBs course in school, and I hadn't even heard of relational algebra until I started prepping my course for the first time. Despite that, the concepts were very familiar due to my SQL experience. Yet in my 5 years writing queries and managing DBs, I've never seen or needed to use relational algebra explicitly.

It does seem surprising that you haven't *heard* of RA before - I suppose it suggests that you're learning as much from the prepared course you've been given to teach, as your students are.

It can however be a very muddled subject to talk about and to teach.

A main confounding factor is that SQL - as a language that controls real-world SQL engines - is based on EF Codd's RA, but SQL has never been completely faithful to Codd's description of RA.

One notable discrepancy off the top of my head, SQL has always dealt in what mathematicians call "multisets" or "bags" of records (that is, sets that allow duplicates) and a "set" when spoken of by an SQL practitioner is synonymous with a "multiset" (or a "table" in everyday terms). Whereas Codd talks about "sets" in connection with RA and he actually *means* sets in the mathematical sense.

These kinds of little details are rarely remarked upon, and can lead to considerable confusion between the understandings which advanced practitioners of SQL have, and the understandings and terminology which academics and students acquire.

> Does relational algebra still provide enough value to warrant spending significant time on it in class? Or could it be made more of a historical footnote, enabling more time for hands-on practice and an expanded focus on non-relational DB types?

The main question would be, what value you're trying to provide?

In my view, the syntax originally associated with RA is unnecessary to learn and inferior to SQL. The terminology of RA is also quite unhelpful - with tables called "relations", rows/records called "tuples", and so on. The only reason for learning these details is if you wanted to be able to read historical documents, or to interact with theoretical materials steeped in this jargon.

There is however a basic conceptual framework associated with RA that would be very useful to teach explicitly, including the fact that it is a relatively rigorous system of algebra in which tables (not "scalars") are the primary thing of focus along with a system of "relational" (i.e. table) operators which accept tables as arguments and produce tables as results. The fact that these relational operators can manipulate the shape of tables structurally as well as manipulating the individual values within the tables, is a conceptual aspect of RA and SQL which is (or for a long time, was) unique amongst the mainstream programming languages.

My overall advice though would be to brush up on the things you've been given to teach, especially before attempting to radically innovate the priorities of the existing curriculum.

> **Comments:**
> **username_0**: Thanks username_2. I did take a deep dive into RA ahead of my first year teaching this course, and I actually enjoy doing it as an intellectual exercise. Like I said in the background, at this point I've taught RA successfully for multiple semesters, and am only now considering some modifications. I would never just toss course units in and out without understanding their value, which is why I'm here.  
> **username_2**: @username_0, are you in a position now then, as an educator with some experience, to understand what role RA is playing in your understanding of the topic, or what usefulness your students are deriving from that aspect of your teaching? Curriculums are designed around these concerns, in that the educator has to explicitly articulate all the information necessary to reproduce their own understanding (or so much a part of it as is relevant to the particular course) in the minds of the students.  

---

### Answer by username_3 on 2024-12-09. Score: 2

Relational algebra is part of the most recent ACM/IEEE/AAAI curricular guidelines for a CS undergraduate degree. See: [Computer Science Curricula 2023](https://www.acm.org/articles/bulletins/2024/june/cs2023-curricular-guidelines).

You can see this in the Data Management section, DM-Querying: Query Construction (document p. 118). The first three items in that list are:

1. SQL Query Formation (CS Core)
2. Relational Algebra (KA Core)
3. SQL (KA Core)

(and 5 more Non-core items)

Note that CS (Computer Science) Core are topics every CS graduate *must* know, the KA (Knowledge Area) Core are topics every student *should* know, and the Non-core items are electives they *might* know.

So the relational algebra topic is something that the top professional computing organizations agree every CS graduate should know, and there would be a gap in your students' qualifications (assuming they're CS degree students) if they didn't get that.


---

