I checked your Zen reference download. I am new to Universes and am looking for more formal definitions than seem available. Although your presentation is not very formalized, it provides a number of useful guidelines that illustrate many of the major concepts well. Thanks.

I have talked about chasm traps in some of my presentations that you can download. Try the “ZEN and the ART of Universe Design” as one example.

Have you posted your article on Chasm Traps?

A minor quibble (in the interest of clarity)…

Your use of arrows is opposite the convention used in Universe Designer, which uses a standard functional meaning where the arrow points from the table containing the many foreign keys to the table containing the single matching primary key. Why do you use the opposite convention? For example order points to lines whereas Universe Designer would show lines pointing to order.

I came across your blogs through the BoB forums and I’ve found them to be a good and helpfull read.

In the last part of the blog above you mentioned you we’re going to write more about how you can create a correct universe by knowing relations and about Chasm Traps. I know you’ve written this post a while ago but I’ve not been able to find this new blog you mentioned. Could you please tell where this blog can be found?

To answer the question, the term “Fact table” always seems to belong to a datamart or warehouse schema rather than a normalized schema, at least that’s how I differentiate it in my head. That’s probably because nobody used the term before those schemas were proposed back during the early days. Another definition that I’ve seen is any table with only keys and measures is a fact, but that also seems to be derived from how fact tables are used in a star schema as well.

Your definition of “outward joins” also works for the same reason.

In the schema I provided for this post, I don’t consider the items table a fact table primarily because I don’t use that term in a transactional model but that’s mostly habit rather than from any strict definition. The item table includes keys (item id, order id), measures (quantity sold), but also dimension (informational) values like price and (if partial shipments are allowed) ship date and so on.

After writing all of this, I checked to see what Wikipedia has, and their article also associates the term “fact table” with dimensional modeling. In fact (heh, pun) it echos quite a few of the comments I had already made before going to read it.

I love the many articles on your site. I was a little confused by something you said in this one though.
You say that there are no fact tables in this schema. I guess that depends on how you define fact table. I would have normally though of “lines” as a fact table and “prices” as a fact table.

In my mental model, whenever I see a table that has all outwardly-directed many-to-one relationships, then it’s a fact table.

(Those aren’t the only fact tables in my notion of what a fact table is, but “tables with all outwardly-directed many-to-one relationships” is a pretty big chunk of all fact tables. Occasionally I’ll see models where an individual table can play the role of a fact table or a dimension table, depending on how it’s used. Such dual-purpose tables usually have mostly outwardly-directed many-to-one relationships, but a small number of outwardly-directed one-to-many relationships.)

I’m curious to know what your definition of “fact table” is? I ask because, honestly, I don’t think I’ve ever come up with a satisfactory, rigorous definition of “fact table” myself, and I’m always on the lookout for better understanding.

This is an great example its really helpful to me

There is an RSS feed feature for the blog software I use. My signature on BOB is automatically updated when I post a new entry as well. So hopefully one (or both) of those options will prove to be useful to you.