some advice on attribute relationships 1

[hoohay]

I am a bit confused on how to configure the mod_date attribute relationships of the following in MSTR 7.2.2.

these are the tables i have

t_function
---------
function_id
function_desc
mod_date


t_filter
-------
filter_id
filter_desc
filter_type_id
function_id
mod_date


t_filter_type
-----------
filter_type_id
filter_type_name
mod_date


should i create a function_mod_date attribute and have it as a child of function_id attribute, a filter_mod_date attribute and have it as a child of the filter_id attribute, etc.

any input would be appreciated.

 

[mstrNate]

I don't really know what your reporting requirement is, so here are a couple of suggestions.

Mod_Date looks like a typical field to track when that record was last updated. And it's generic enough that it looks like it would be used across lots of different dimensions. One thing you could do, is model it as a stand alone attribute with no parents or children. Then you could filter on it if you wanted to in your reports. And you have fewer attributes to look at.

If you wanted to associate it with the filters or functions, you could do what you suggested. In that case, I might name the field in the database table differently, either physically or thru a view. For example, function_mod_date, like you said, but at the database level in addition to what you suggested. That way MicroStrategy can distinguish between mod_dates on the different attributes when it generates sql. You could make it a parent or a child, depending on how the business wants to view the data.

Hope that helps somewhat.

Nate

 

[hoohay]

Thanks for your input mstrNate. I hope to reciprocate someday!

hoohay

 

[nlim]

try to think of attributes as things you will want to group-by, or filter on. the relationships determine the join path the sql will take.

MSTRNates' suggestion would work just fine.