Comment by ModernMech

The point is if you're doing relational algebra you want to work with relations. The key reason why set semantics are nice is because the operations are guaranteed to return relations, so you don't have to check or make accountings of which return values are sets and which are bags, or worry about machinery to convert between the two.

It's like how you can store numbers internally as floating points or rationals and trivially convert between the two. But if all you ever do is floating point math, you might prefer to store the numbers as floating points rather than rationals and then convert to floating point.

A result in SQL can contain duplicate items unless you tell it explicitly to deduplicate, so uses multiset/bag semantics. The relational model is built on set semantics, where every item is unique. Just because it can express those operations doesn't mean the idea is baked into the language semantics. e.g. the difference between Haskell and Python + first class functions; you can do functional programming in Python but it's not a functional language.

What they're saying is: The relational data model and algebra are based on set semantics. Relations (equivalent of SQL's "tables") are sets of sets (tuples), not bags of "rows". There's no such thing or possibility as duplicate tuples ("rows" of "columns").

This has a number of elegant properties (and also improves the kinds of optimizations a query planner / execution stage can apply.)

A similar divergence is that the relational model has no concept of nulls. Presence/absence is expressed through "item not in set" in various ways, and by properly normalizing the data.

SQL also isn't properly expression oriented or composable at all. A relational algebraic language absolutely can be, and can lend itself to much more elegant data handling.

In many ways SQL is to "relational" like Java or C++ are to "object oriented" -- it got in very early to market, got mainstream success, and dominated the field, and in so doing it mangled people's perceptions of what a database is, and also made people either define "relational" as "SQL" (sigh), and even worse because they misunderstand what relational is while also hating SQL, they try to throw the baby out with the bathwater with their successors.