> The phrase "Carbon is a chemical element with symbol C and atomic number 6" specifies a "chemical element". Have you not just categorized Carbon as being a chemical element?

A fair point -- except it's a worldwide consortium of scientists that made that categorization, so it's not like I introduced it here. But you're right: the categorization "carbon is a chemical element" is not actually what I care about; I care about the fact that "Carbon is one of the things you might see in a Chemical Formula, where it will be represented by a C." It's possible that things that aren't chemical elements, like Amino Acids, could also have these same statements made about them. So as you see, I've not actually restricted members of my table to only Chemical Elements (with this minor change).

> Do you have a table with a single column that stores the string above? Do you have a table with 2 columns ...

Everything you listed is a possibility, except you need GUIDs or a similar scheme since the same entity is represented in multiple tables. In general it's just (key, statement) where "statement" is all the fields you need to exactly make your statement. I'd probably put the string "Carbon" in its own table, possibly with other text used to canonically identify the entity in English (or I'd explicitly store the language if I was going full internationalization). I also sometimes track singular vs. plural, although for chemical elements that's

I'd put atomic number and the chemical-formula abbreviation in the same table, possibly with other "periodic table" type information if it were important. I probably would stop there: I wouldn't actually say it's a solid, for instance -- that's just not an actually useful statement in the real world. This is just too simple an example to get much meat out of it. But that's OK - small tables are fine.

There are no foreign key constraints because there is no single table which is a canonical list of "chemical elements", by design. Foreign keys are secretly business rules that just happen to be easily representable in a database. Business rules go in the application layer.

> [statement] can mean many different things in a modeling sense

A statement (or component, spoiler that you got that right) is an immutable ("honorarily" immutable in the DB, but truly immutable in the application layer) ordered tuple of related data (read: struct) that can be associated with an entity. Of course to be stored in the DB it must be associated with an entity, but in the application layer it's useful that they don't have to be.

> What I'm getting from you now is you're envisioning something closer to a Entity Component System but for general data modeling.

Yes, that is the term I use for it: "Entity-Component Architecture". I've taken to calling them "statements" instead of "components" when introducing the topic because it's more obvious to people who don't know ECS, and people who do know ECS assume I'm just talking about games. The word "system" shows up a lot but does not have a specific meaning; it's more like "service". Basically systems are code elements that layer on successively more rules about what operations are or are not valid to perform on sets of these (key, statement) objects -- but that's just one of many useful words to describe such code elements.

> Or more accurately something like prolog style relations; with all entities, regardless of "type", tracked in a single table of entity ids, and having each relation between entities referred to as a statement, and tracked in their own table.

You don't actually need a master list of every entity, and there are even reasons to avoid it. But you could do it that way if you wanted; it has its pros and cons. I personally don't.

Keep in mind not all statements are "relations between entities". Some are; some are relations between 3+ entities. Some are just plain-old facts that you want to remember. But yes, each different kind of statement you want to make gets its own table.

> But it's still not clear to me until you give an example of how you would model it.

You have the right idea. Frankly the differences don't show up until a pretty reasonable level of complexity, and everything is dependent on the exact business cases you want to support. I really should just write a blog post on it.