Facts and dimensions: dynamic dimensions [closed] - sql

Question

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
(Appreciate this post is perhaps too high level or philosophical for SO, I'm in the schema planning phase and seeking some guidance)
After some difficulty working with a clone of our production database for analytics, I am attempting to define a events fact table along with some dimensions tables in order to make analytics work simpler.
The block I've hit in my planning is this. We have different categories of event with different dimensions needed to describe them. E.g. suppose we have 'account settings' event category as well as 'Gallery' events.
In a fact table I might have a field eventCategory and eventName with example values from above such as:
'EventCategory': 'Account Settings'
'EventName': 'Update Card Billing Details'
Or:
'EventCategory': 'Gallery'
'EventName': 'Create New Gallery'
In each case I want to use a different collection of dimensions to describe them. E.g. for Gallery events we want to know 'template', 'count of images', 'gallery category e.g. fruits'. We have no need for these details with account settings events, which have their own distinct set of dimensions to describe them.
Via the textbook examples I find online, I would have a dimensions table for Gallery events and a dimensions table for Account Settings events.
The mental block I have is that these dimensions are dynamic not static. I want to record in the fact table the value of these dimensions at the time of the event not 'now'. For example, a user can either be in trial or a paid user. If I had a dimension table 'user' their status might currently be 'paid' but at the time of some previous gallery event they may have been in trial.
What is the 'right' way to handle this:
Multiple facts tables, one for Gallery events and one for Account Settings events?
Use json in a new field in the main facts table e.g. 'EventDetail' which contains what would otherwise go in a dimension table except by using json we know the values of the dimensions at the time of the event as opposed to whatever those values are now?
I could have a sparse facts table. I would include fields for each dimension across all categories and these would be null where not applicable
Given that the dimensions I use to describe an event are dynamic, what is the 'right' way to construct a fact table for analytics? The way I see it just now the dimensions tables would have to be facts themselves to capture the changing values of these attributes over time.

Answer 1

To add a dimension to any SQL table is always done the same way, by adding a column.
In any kind of history, there is no "now". Every status has a time period: a beginning and ending. I usually name those columns AsOf and Until, because begin/end show up a lot as SQL keywords, making the column names harder to scan for. Usually, only AsOf is needed, because you can self-join the table to find succeeding periods, and use NULL to represent 'now' (where "now" means, as of the time the query is executed).
'user' their status might currently be 'paid' but at the time of some previous gallery event they may have been in trial.
Right, so the user's status isn't just paid/trial. It's paid or trial starting AsOf some date, until a later AsOf date for the same user.
It's hard to be more helpful. There's a bit of jargon in your question, and it's couched in domain-specific terms. I hope by attaching a date/time to every status, you can see your way out of the forest.

Answer 2

(A) Managing temporal data in postgres
Temporal data is a quite usual need in many kinds of business applications, but it is not a "built-in" feature in postgres, nor in many other RDBMS.
As stated by #James K. Lowden, you can use some AsOf and Until columns of type timestamp with or without time zone, or you can use instead a single column of type tsrange or tstzrange, ie a range of timestamps, and which will offer you some nice built-in functions, see the manual.
In order to avoid overlaps between timestamp ranges associated to different events for the same data, you can implement a business logic with trigger functions.
For instance for the same user, you can implement the following trigger function so that the range r1 associated to the status 'in trial' and the range r2 associated to the status 'paid' are automatically set up when the corresponding rows are inserted in the user table, and the ranges of the existing rows for the same user are updated accordingly :
CREATE OR REPLACE FUNCTION before_insert_user ()
RETURNS trigger LANGUAGE plpgsql AS
$$
BEGIN
-- update all the existing rows (ie status) for the same user_id whose valid_ranges are valid as of now
UPDATE user
SET valid_range = tstzrange(lower(valid_range), Now())
WHERE user_id = NEW.user_id
AND valid_range #> Now() ;
-- set up the valid_range for the new row (ie the new status)
NEW.valid_range = tstzrange(Now(), NULL) ;
END ;
$$ ;
CREATE OR REPLACE TRIGGER before_insert_user BEFORE INSERT ON user
FOR EACH ROW EXECUTE FUNCTION before_insert_user () ;
(B) Managing different dimensions for different categpories
As already discussed, json can be a solution to store various dimensions in the same column.
An other solution could be the table inheritance with some interesting functionalities :
CREATE TABLE Event
( EventCategory varchar
, EventName varchar
, ValidityRange tstzrange
, primary key (EventCategory , EventName, ValidityRange )
) ;
CREATE TABLE user
( status varchar
) INHERITS Event ;
CREATE TABLE Gallery
( template varchar
, "count of images" integer
, "gallery category e.g. fruits" varchar
) INHERITS Event ;

Answer 3

A fact table needs to have its grain defined; if facts don’t match that grain they can’t be stored in that fact table => if you have facts with different sets if dimensions then you need to use different fact tables.
Regarding the values in a dimension changing, you need to read up on Slowly Changing Dimensions