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
