Starting over, a journey into learning and cleaning up some ugly code

Who is online?  0 guests and 0 members
Home  »  Blogs  »  SQLKohai  »  Starting over, a journey into learning and cleaning up some ugly code
 
0
/5
Avg: 0/5: (0 votes)

Comments (4)

Daniel
Daniel said:
This is really a forum post, more than a blog, but I will take a stab at it. Regarding your first question, I would always lean toward a single key over a composite key in a fact - dimension relationship. However, you haven't clearly explained the relationship between a resident and entity, so it is tough to say. I am going to make an assumption that this is a health care facility of some sort, probably rehab or nursing home. If that is the case I would have to ask, does the resident have an absolute relationship with the entity? Wouldn't it be possible for a resident to be in one entity for a while, get out, and then some time later become tied to another entity? You might want to have a relationship between your resident and entity, but not in your fact table. Your second question is partially answered above, but...any dimension can have multiple hierarchies defined. So, there should be no problem setting up another hierarchy based on resident.
2/13/2012
 · 
 
by
SQLKohai
SQLKohai said:
Daniel, I agree, it probably should be in the forum, but I kind of wanted to start a blog series of posts on how do go from zero to working model. I should probably start with a bunch of forum posts to gather the info and then blog about it later. As for your assumption, yes, it's a group of nursing homes that we run the operations for. And yes, a resident can be in one facility and be discharged and go to one of our other facilities. Depending on which department you talk to, some would care about seeing the patients whole history, while some would only care about the segment they are currently in. I guess my hierarchy question is more how would I set it up? Entity, or building, is easy - Organization, Region, State, Entity. Resident would be Entity, then resident? I think the hardest part is trying to start over because we have a lot of stuff in place and I'm not positive that the consulting company steered us in the right direction in every case :) I think I'm having to unlearn a bit. What I'm attempting is a simple model of Entity, Date, Resident, and Aging of Receivables(fact). The Fact table has a key to entity and resident and date, but as you assumed correctly, the resident can be from more than one facility, but (and I just checked this), if they do go to a different facility, there is a new entry in the resident table.
2/13/2012
 · 
 
by
Daniel
Daniel said:
If you have a relationship between your entity and resident dimension on the entity, then yes a Entity > Resident hierarchy seems to work. Regarding the different facility. Is there anything that would tie a resident that migrated facilities together, social security or other natural key? If yes, then a new entry in the resident dimension makes sense, you simply end up with a Type 2 Slowly Changing Dimension where you track the resident via the natural key, and their relationships to various entities (including the current one) via the relationship to the fact and the entity dimension.
2/13/2012
 · 
 
by
SQLKohai
SQLKohai said:
Here's the trippy part. When I try to just let SSAS generate itself, the Dim Entity gets split into two dimensions instead of just Dim Entity - FK Entity, and Resident - FK Entity. That in and of itself isn't a problem, but I am creating roles for each Entity. The manager of building 1 shouldn't be able to see anything in building 2. So I went into the role and in the dimension data tab, picked the Dim Entity dimension, deselected all members, and picked just the one building. It comes out on the advanced tab as {[Dim Entity].[Entity Short Name].&[Building 1]}, but when I try to browse as that role, I get an error The Entity Short Name attribute in the FK Entity domension has a generated dimension security expression that is not valid. The dimension [Dim Entity] was not found in the cube when the string [Dim Entity].[Entity Short Name].[Building 1] was parsed. I have a feeling it's because the dimensions in the cube are FK Entity and Resident-FK Entity, but why would the MDX parse fine?
2/13/2012
 · 
 
by
Blogs RSS Feed

SQLKohai's latest blog posts

Blogs RSS Feed

Latest community blog posts