YeaH you are right, its like we run into similar things :D
Any how I cannot answer your question, now I understand you and I dont
think there is a right answer, it looks fine for me actually now I get
it. It seems very ruby -like solution according to what I undestand to
be a star schema, yet I ask so much because I am not a Wareousing
expert may be some one with more Data Warehousing knowledge will
eventually read this hahaha and give his insight
Thanks again, I also find myself patching or customizing AW, but I am
never sure if what I do makes sense to anyone else or how to extend
the api because again my changes seem very custom, personally I would
like a more detailed roadmap and ROADMAP RECMENDATIONS from people in
the list.
Cheers
PAco
On Apr 1, 2009, at 8:08 PM, Andrew Kuklewicz wrote:
Hi Paco,
Not sure how else to explain it, if you haven't faced it maybe it
doesn't make sense.
I could leave it as a polymorphic relationship in the fact table I
guess, and adjust all queries to that, but I can't then use the AW
functionality to associate this info to dimensions, and can't then use
anything that depends on AW.
I don't think you will find any reference suggesting how AR does
polymorphic relationships as a good idea for how to model a fact
table's relationship to its dimensions.
As I understand it, the whole point of a star schema is very simple,
easily navigable relationships, as denormalized as you can get.
Ideally, you should simple fk references between a dimension and a
fact, and all other fields are aggregate data. The polymorphic style
of expressing relationships to dimensions does not do this.
more below....
On Wed, Apr 1, 2009 at 7:13 PM, Paco Viramontes <kidpo...@gmail.com>
wrote:
I have used polymorphic associations in AR but for tables with very
similar
attributes
I am happy to use in AR as well, the issue is how to do the same thing
in a fact table, and if the soltion that works so well in AR is a good
answer in a start schema db.
I get your point, but I cant understand whats the benefit for a AW
table
report. If you are generating some kind of custom report.
I'm not saying I can't work around it, and write reports if I have to,
more I am looking for a design that consistent with good star schema
and data warehousing design principles, and that plays well with the
existing AW code. For example, I don't think the dimension method in
a fact class handles polymorphic relationships. Same with using these
values to define a cube, not sure, but pretty cure it would make it
much more difficult if it could be made to work at all.
It is my uncertainty at how well AW supports polymorphic relationships
that lead me to write in, as I could be wrong, maybe it is well
supported and I missed it in the docs/code.
Or you are trying to use a fact class that can have only one
dimension but
of a different flavor.
There are about 7 different dimensions that a given fact row could be
related to, all of which is contained in the polymorphic relationship
as a single key and type column pair in AR, so this processor is a way
to have the fact show all those possible relationships in its
dimension columns.
What would then be a resulting report?
Well, imagine that I wanted a report of every time a user made another
user a contact.
After running the polymorphic processor, all I need to do is aggregate
using the action_object_user_id table for the user being contacted.
With the polymorphic relationship I need to know that the
action_object_type value is 'User', and have a where clause to include
only those rows, so I am always adding these kinds of conditions to my
queries and reports, and expecting people to know to do this.
thanks for ecplaining
Trying to explain, but I am mostly looking to see if there even is a
problem, or if I am imagining it.
Between this and the ActiveMessaging list, you and I are getting to be
real pen pals. :)
Cheers,
-Andrew
PAco
On Apr 1, 2009, at 3:43 PM, Andrew Kuklewicz wrote:
add new a column
value to a row based on the polymorphic values. Co
_______________________________________________
Activewarehouse-discuss mailing list
Activewarehouse-discuss@rubyforge.org
http://rubyforge.org/mailman/listinfo/activewarehouse-discuss
_______________________________________________
Activewarehouse-discuss mailing list
Activewarehouse-discuss@rubyforge.org
http://rubyforge.org/mailman/listinfo/activewarehouse-discuss
