Martin Fowler wrote about doing that as a way to get around the "object-relational mismatch" issue[1]. Richard Fabian describes "data-oriented design" as having a lot of overlap with the relational model[2]. ECSes becoming very popular in game engines are basically in-memory relational databases where "components" are "tables"[3].
[1]: https://martinfowler.com/bliki/OrmHate.html
No, components are columns. Each entity is a row in a table and an archetype (the set of all entities with the same components) is a table.
In ECS it's usual to store components together, this corresponds to columnar storage in database terms (or equivalently, it's as if data were in sixth normal form [0]). However in some systems you can opt to store a more traditional row-based column.
[0] https://en.wikipedia.org/wiki/Database_normalization#Satisfy...
Conceptually I think you could equate components with relations. For example a "grid location" component could be imagined as a relation with "entity ID" and "coordinate" columns. I suppose that admits multiple component instances per entity ID though which is typically not what you want.
6th Normal Form? I was taught that 3NF should be enough for all intents and purposes, which now sounds like the quote about 640k memory.