Anyone knows any tutorials on th use of ERWin ?there should be one with the install-cd.
jobi
"Alan" <NOSPAMalanpltse@.yahoo.com.au> wrote in message
news:OEVoAfcoDHA.3256@.tk2msftngp13.phx.gbl...
> Anyone knows any tutorials on th use of ERWin ?
>|||erwin has some serious problems with matching indexes and foreign keys
between the model and the sql2000 db. it sort of works, but it sort of
doesn't. get ready to be aggravated.
the best advice i can give you on the use of erwin is to always
carefully read the script generated by complete compare so that you know
exactly what it's going to do to the db.
even though erwin has some serious glitches in it, i haven't found a
better tool for migrating schema changes from one db to another.
jobi wrote:
> there should be one with the install-cd.
> jobi
> "Alan" <NOSPAMalanpltse@.yahoo.com.au> wrote in message
> news:OEVoAfcoDHA.3256@.tk2msftngp13.phx.gbl...
> > Anyone knows any tutorials on th use of ERWin ?|||As always, you have to use these tools only after you know their soft spots.
Have them script their changes, check that thoroughly.
Evaluate the software before you buy it.
jobi
"chxxx" <chxxx@.dontemailme.com> wrote in message
news:3FA7B3A4.3DD2910@.dontemailme.com...
> erwin has some serious problems with matching indexes and foreign keys
> between the model and the sql2000 db. it sort of works, but it sort of
> doesn't. get ready to be aggravated.
> the best advice i can give you on the use of erwin is to always
> carefully read the script generated by complete compare so that you know
> exactly what it's going to do to the db.
> even though erwin has some serious glitches in it, i haven't found a
> better tool for migrating schema changes from one db to another.
> jobi wrote:
> > there should be one with the install-cd.
> >
> > jobi
> > "Alan" <NOSPAMalanpltse@.yahoo.com.au> wrote in message
> > news:OEVoAfcoDHA.3256@.tk2msftngp13.phx.gbl...
> > > Anyone knows any tutorials on th use of ERWin ?
>
Showing posts with label modelling. Show all posts
Showing posts with label modelling. Show all posts
Wednesday, March 28, 2012
Modelling Tool Help
Hello,
For management that doesn't have the software I do, I've been using a PDF postscript utility to print the model and give it to them. However, I have to fit the model for the specific page (which is really small, and you have to zoom in), or you have to view it on multiple pages. Well multiple pages can be a pain, because the table you are looking at is on page 1, but the relationships are on page 12, 22, or 50, for example. So I was looking for a tool that is cheap enough to implement that we could look at the entire model on one "surface" (not necessary to print), that the model could be viewed in.
Thanks,
BrianHow about visio?|||Yes, we have that too, and I did find the Meta Information Model Bridge that converts to different formats, but we are looking for a general viewer without the data modelling need. It may just have to be Visio.
Thanks,
Briansql
Modelling Time Span with OLAP tools
This is more of a design question. I am trying to create a fact table for ti
me spans. For example an order might go through the following status of Crea
ted, In-Progress, Delivered. The time span between any 2 states could range
from minutes to days to mon
ths. I want to be able to see the current status and also the status as of l
ast month, or last quarter or some other previous date.
Some of the recommendations by extert sites are to have a date in your fact
table for each status accompained by a field
for storing a value 1. So the order fact by look like
Order Id
Order Create Date
Order Created Value
Order In-Progress Date
Order In-Progress Value
Order Delivered Date
Order Delivered Value
Also I am creating my own time dimension. The above approach will work very
well when you use SQLs to access your star schema, but I am not so sure this
approach will work for olap tools like MSAS.
Is there an alternative?
ThanksWhat you have here looks like an accumulating snapshot fact table. These
are best employed IMHO where you have a business process/relatively short
with milestones which you want to track.
It means that you have less rows in your fact table but that you will
revisit the row to perform UPDATEs, something not typically done.
This type of fact table is good for measuring time lags between business
processes i.e.
Time from Order -> Sale
Time from Sale -> Ship
The way I do this is to create a view over the top of the fact table which
calculates these figures for me. This way i can then use it as a measure
just like any other. I usually do it to difference in hours.
--
Allan Mitchell MCSE,MCDBA, (Microsoft SQL Server MVP)
www.SQLDTS.com - The site for all your DTS needs.
I support PASS - the definitive, global community
for SQL Server professionals - http://www.sqlpass.org
"Break It" <anonymous@.discussions.microsoft.com> wrote in message
news:13CB4DFA-500D-4268-B850-5EE207F917CD@.microsoft.com...
> This is more of a design question. I am trying to create a fact table for
time spans. For example an order might go through the following status of
Created, In-Progress, Delivered. The time span between any 2 states could
range from minutes to days to months. I want to be able to see the current
status and also the status as of last month, or last quarter or some other
previous date.
> Some of the recommendations by extert sites are to have a date in your
fact table for each status accompained by a field
> for storing a value 1. So the order fact by look like
> Order Id
> Order Create Date
> Order Created Value
> Order In-Progress Date
> Order In-Progress Value
> Order Delivered Date
> Order Delivered Value
> Also I am creating my own time dimension. The above approach will work
very well when you use SQLs to access your star schema, but I am not so sure
this approach will work for olap tools like MSAS.
> Is there an alternative?
> Thanks
me spans. For example an order might go through the following status of Crea
ted, In-Progress, Delivered. The time span between any 2 states could range
from minutes to days to mon
ths. I want to be able to see the current status and also the status as of l
ast month, or last quarter or some other previous date.
Some of the recommendations by extert sites are to have a date in your fact
table for each status accompained by a field
for storing a value 1. So the order fact by look like
Order Id
Order Create Date
Order Created Value
Order In-Progress Date
Order In-Progress Value
Order Delivered Date
Order Delivered Value
Also I am creating my own time dimension. The above approach will work very
well when you use SQLs to access your star schema, but I am not so sure this
approach will work for olap tools like MSAS.
Is there an alternative?
ThanksWhat you have here looks like an accumulating snapshot fact table. These
are best employed IMHO where you have a business process/relatively short
with milestones which you want to track.
It means that you have less rows in your fact table but that you will
revisit the row to perform UPDATEs, something not typically done.
This type of fact table is good for measuring time lags between business
processes i.e.
Time from Order -> Sale
Time from Sale -> Ship
The way I do this is to create a view over the top of the fact table which
calculates these figures for me. This way i can then use it as a measure
just like any other. I usually do it to difference in hours.
--
Allan Mitchell MCSE,MCDBA, (Microsoft SQL Server MVP)
www.SQLDTS.com - The site for all your DTS needs.
I support PASS - the definitive, global community
for SQL Server professionals - http://www.sqlpass.org
"Break It" <anonymous@.discussions.microsoft.com> wrote in message
news:13CB4DFA-500D-4268-B850-5EE207F917CD@.microsoft.com...
> This is more of a design question. I am trying to create a fact table for
time spans. For example an order might go through the following status of
Created, In-Progress, Delivered. The time span between any 2 states could
range from minutes to days to months. I want to be able to see the current
status and also the status as of last month, or last quarter or some other
previous date.
> Some of the recommendations by extert sites are to have a date in your
fact table for each status accompained by a field
> for storing a value 1. So the order fact by look like
> Order Id
> Order Create Date
> Order Created Value
> Order In-Progress Date
> Order In-Progress Value
> Order Delivered Date
> Order Delivered Value
> Also I am creating my own time dimension. The above approach will work
very well when you use SQLs to access your star schema, but I am not so sure
this approach will work for olap tools like MSAS.
> Is there an alternative?
> Thanks
Modelling Active Directory Data
Hello,
I am not sure if this is the right forum, but here goes.
I need to document the members of about 1000 Active Directory Group in a SQL
database. The groups are all in the same OU. I also need to document the
nested members (both groups and users). Putting the root groups in a table i
s
no problem. I am having trouble with maintaining the relationships between
the root groups\nested groups\nested members. A typical example would be:
Root group
Nested Group 1
Nested User 1
Nested User 2
Nested Group 2
Nested User 1
Nested User 2
Thanks in advance for any suggestions.Hi
You may want to check previous ADSI threads and the ADSI newsgroup such as
http://tinyurl.com/e7vtb
John
"bxr222" wrote:
> Hello,
> I am not sure if this is the right forum, but here goes.
> I need to document the members of about 1000 Active Directory Group in a S
QL
> database. The groups are all in the same OU. I also need to document the
> nested members (both groups and users). Putting the root groups in a table
is
> no problem. I am having trouble with maintaining the relationships between
> the root groups\nested groups\nested members. A typical example would be:
> Root group
> Nested Group 1
> Nested User 1
> Nested User 2
> Nested Group 2
> Nested User 1
> Nested User 2
> Thanks in advance for any suggestions.
>|||John,
Thanks for responding. I have seen similar info before but do not think this
suits my needs. Particularily, no info exists on getting the members of
groups. I can do this easily using VBScript, but need a table structure to
input it into. Additionally, I need to be able to track changes to these
groups on a quarterly basis. I may be overlooking something here though.
"John Bell" wrote:
[vbcol=seagreen]
> Hi
> You may want to check previous ADSI threads and the ADSI newsgroup such as
> http://tinyurl.com/e7vtb
> John
> "bxr222" wrote:
>|||Hi
The recursion is best handled in the script example, you can then decide on
what you wish to store in the database.
John
"bxr222" wrote:
[vbcol=seagreen]
> John,
> Thanks for responding. I have seen similar info before but do not think th
is
> suits my needs. Particularily, no info exists on getting the members of
> groups. I can do this easily using VBScript, but need a table structure to
> input it into. Additionally, I need to be able to track changes to these
> groups on a quarterly basis. I may be overlooking something here though.
> "John Bell" wrote:
>
I am not sure if this is the right forum, but here goes.
I need to document the members of about 1000 Active Directory Group in a SQL
database. The groups are all in the same OU. I also need to document the
nested members (both groups and users). Putting the root groups in a table i
s
no problem. I am having trouble with maintaining the relationships between
the root groups\nested groups\nested members. A typical example would be:
Root group
Nested Group 1
Nested User 1
Nested User 2
Nested Group 2
Nested User 1
Nested User 2
Thanks in advance for any suggestions.Hi
You may want to check previous ADSI threads and the ADSI newsgroup such as
http://tinyurl.com/e7vtb
John
"bxr222" wrote:
> Hello,
> I am not sure if this is the right forum, but here goes.
> I need to document the members of about 1000 Active Directory Group in a S
QL
> database. The groups are all in the same OU. I also need to document the
> nested members (both groups and users). Putting the root groups in a table
is
> no problem. I am having trouble with maintaining the relationships between
> the root groups\nested groups\nested members. A typical example would be:
> Root group
> Nested Group 1
> Nested User 1
> Nested User 2
> Nested Group 2
> Nested User 1
> Nested User 2
> Thanks in advance for any suggestions.
>|||John,
Thanks for responding. I have seen similar info before but do not think this
suits my needs. Particularily, no info exists on getting the members of
groups. I can do this easily using VBScript, but need a table structure to
input it into. Additionally, I need to be able to track changes to these
groups on a quarterly basis. I may be overlooking something here though.
"John Bell" wrote:
[vbcol=seagreen]
> Hi
> You may want to check previous ADSI threads and the ADSI newsgroup such as
> http://tinyurl.com/e7vtb
> John
> "bxr222" wrote:
>|||Hi
The recursion is best handled in the script example, you can then decide on
what you wish to store in the database.
John
"bxr222" wrote:
[vbcol=seagreen]
> John,
> Thanks for responding. I have seen similar info before but do not think th
is
> suits my needs. Particularily, no info exists on getting the members of
> groups. I can do this easily using VBScript, but need a table structure to
> input it into. Additionally, I need to be able to track changes to these
> groups on a quarterly basis. I may be overlooking something here though.
> "John Bell" wrote:
>
Modelling Active Directory Data
Hello,
I am not sure if this is the right forum, but here goes.
I need to document the members of about 1000 Active Directory Group in a SQL
database. The groups are all in the same OU. I also need to document the
nested members (both groups and users). Putting the root groups in a table is
no problem. I am having trouble with maintaining the relationships between
the root groups\nested groups\nested members. A typical example would be:
Root group
Nested Group 1
Nested User 1
Nested User 2
Nested Group 2
Nested User 1
Nested User 2
Thanks in advance for any suggestions.Hi
You may want to check previous ADSI threads and the ADSI newsgroup such as
http://tinyurl.com/e7vtb
John
"bxr222" wrote:
> Hello,
> I am not sure if this is the right forum, but here goes.
> I need to document the members of about 1000 Active Directory Group in a SQL
> database. The groups are all in the same OU. I also need to document the
> nested members (both groups and users). Putting the root groups in a table is
> no problem. I am having trouble with maintaining the relationships between
> the root groups\nested groups\nested members. A typical example would be:
> Root group
> Nested Group 1
> Nested User 1
> Nested User 2
> Nested Group 2
> Nested User 1
> Nested User 2
> Thanks in advance for any suggestions.
>|||John,
Thanks for responding. I have seen similar info before but do not think this
suits my needs. Particularily, no info exists on getting the members of
groups. I can do this easily using VBScript, but need a table structure to
input it into. Additionally, I need to be able to track changes to these
groups on a quarterly basis. I may be overlooking something here though.
"John Bell" wrote:
> Hi
> You may want to check previous ADSI threads and the ADSI newsgroup such as
> http://tinyurl.com/e7vtb
> John
> "bxr222" wrote:
> > Hello,
> >
> > I am not sure if this is the right forum, but here goes.
> >
> > I need to document the members of about 1000 Active Directory Group in a SQL
> > database. The groups are all in the same OU. I also need to document the
> > nested members (both groups and users). Putting the root groups in a table is
> > no problem. I am having trouble with maintaining the relationships between
> > the root groups\nested groups\nested members. A typical example would be:
> >
> > Root group
> > Nested Group 1
> > Nested User 1
> > Nested User 2
> > Nested Group 2
> > Nested User 1
> > Nested User 2
> >
> > Thanks in advance for any suggestions.
> >|||Hi
The recursion is best handled in the script example, you can then decide on
what you wish to store in the database.
John
"bxr222" wrote:
> John,
> Thanks for responding. I have seen similar info before but do not think this
> suits my needs. Particularily, no info exists on getting the members of
> groups. I can do this easily using VBScript, but need a table structure to
> input it into. Additionally, I need to be able to track changes to these
> groups on a quarterly basis. I may be overlooking something here though.
> "John Bell" wrote:
> > Hi
> >
> > You may want to check previous ADSI threads and the ADSI newsgroup such as
> > http://tinyurl.com/e7vtb
> >
> > John
> >
> > "bxr222" wrote:
> >
> > > Hello,
> > >
> > > I am not sure if this is the right forum, but here goes.
> > >
> > > I need to document the members of about 1000 Active Directory Group in a SQL
> > > database. The groups are all in the same OU. I also need to document the
> > > nested members (both groups and users). Putting the root groups in a table is
> > > no problem. I am having trouble with maintaining the relationships between
> > > the root groups\nested groups\nested members. A typical example would be:
> > >
> > > Root group
> > > Nested Group 1
> > > Nested User 1
> > > Nested User 2
> > > Nested Group 2
> > > Nested User 1
> > > Nested User 2
> > >
> > > Thanks in advance for any suggestions.
> > >
I am not sure if this is the right forum, but here goes.
I need to document the members of about 1000 Active Directory Group in a SQL
database. The groups are all in the same OU. I also need to document the
nested members (both groups and users). Putting the root groups in a table is
no problem. I am having trouble with maintaining the relationships between
the root groups\nested groups\nested members. A typical example would be:
Root group
Nested Group 1
Nested User 1
Nested User 2
Nested Group 2
Nested User 1
Nested User 2
Thanks in advance for any suggestions.Hi
You may want to check previous ADSI threads and the ADSI newsgroup such as
http://tinyurl.com/e7vtb
John
"bxr222" wrote:
> Hello,
> I am not sure if this is the right forum, but here goes.
> I need to document the members of about 1000 Active Directory Group in a SQL
> database. The groups are all in the same OU. I also need to document the
> nested members (both groups and users). Putting the root groups in a table is
> no problem. I am having trouble with maintaining the relationships between
> the root groups\nested groups\nested members. A typical example would be:
> Root group
> Nested Group 1
> Nested User 1
> Nested User 2
> Nested Group 2
> Nested User 1
> Nested User 2
> Thanks in advance for any suggestions.
>|||John,
Thanks for responding. I have seen similar info before but do not think this
suits my needs. Particularily, no info exists on getting the members of
groups. I can do this easily using VBScript, but need a table structure to
input it into. Additionally, I need to be able to track changes to these
groups on a quarterly basis. I may be overlooking something here though.
"John Bell" wrote:
> Hi
> You may want to check previous ADSI threads and the ADSI newsgroup such as
> http://tinyurl.com/e7vtb
> John
> "bxr222" wrote:
> > Hello,
> >
> > I am not sure if this is the right forum, but here goes.
> >
> > I need to document the members of about 1000 Active Directory Group in a SQL
> > database. The groups are all in the same OU. I also need to document the
> > nested members (both groups and users). Putting the root groups in a table is
> > no problem. I am having trouble with maintaining the relationships between
> > the root groups\nested groups\nested members. A typical example would be:
> >
> > Root group
> > Nested Group 1
> > Nested User 1
> > Nested User 2
> > Nested Group 2
> > Nested User 1
> > Nested User 2
> >
> > Thanks in advance for any suggestions.
> >|||Hi
The recursion is best handled in the script example, you can then decide on
what you wish to store in the database.
John
"bxr222" wrote:
> John,
> Thanks for responding. I have seen similar info before but do not think this
> suits my needs. Particularily, no info exists on getting the members of
> groups. I can do this easily using VBScript, but need a table structure to
> input it into. Additionally, I need to be able to track changes to these
> groups on a quarterly basis. I may be overlooking something here though.
> "John Bell" wrote:
> > Hi
> >
> > You may want to check previous ADSI threads and the ADSI newsgroup such as
> > http://tinyurl.com/e7vtb
> >
> > John
> >
> > "bxr222" wrote:
> >
> > > Hello,
> > >
> > > I am not sure if this is the right forum, but here goes.
> > >
> > > I need to document the members of about 1000 Active Directory Group in a SQL
> > > database. The groups are all in the same OU. I also need to document the
> > > nested members (both groups and users). Putting the root groups in a table is
> > > no problem. I am having trouble with maintaining the relationships between
> > > the root groups\nested groups\nested members. A typical example would be:
> > >
> > > Root group
> > > Nested Group 1
> > > Nested User 1
> > > Nested User 2
> > > Nested Group 2
> > > Nested User 1
> > > Nested User 2
> > >
> > > Thanks in advance for any suggestions.
> > >
Modelling a Time dimension with date & time & time zone info
Hello,
Suppose you have original table having columns:
GMTDate (KeyColumn)
GMTMinute (calculated column from GMTDate or populated by algorithm)
GMTHour (calculated column from GMTDate or populated by algorithm)
GMTDay (...)
GMTMonth (...)
GMTYear (...)
That original table is probably populated by some time generation code you have. So we can extend that code to generate more columns or create calculated columns on DSV:
GMTPlus1Minute
GMTPlus1Hour
GMTPlus1Day
GMTPlus1Month
GMTPlus1Year
We can create this way other sets of columns. Note that we do not need columns like GMTPlus1Minute, GMTPlus2Minute ,... We can have just Minute column. But i suppose later we can not have shared Minute attribute.
When we create time dimension we would have key attribute bound to GMTDate. The fact tables would also contain GMTDate and we will use those in the relationships. Other columns would be used for attributes used in different hierarchies.
USA Time Hierarchy
"Year" level <- GMTPlus5Year attribute
"Month" level <- GMTPlus5Month attribute
"Day" level <- GMTPlus5Day attribute
"Hour" level <- GMTPlus5Hour attribute
"Minute" level <- GMTPlus5Minute attribute
It really depends what user interface you have and how efficient it can hide different things (is it easier to hide dimensions than hierarchies or it does not matter).
|||
How would you model a time dimension such that data in transactional source can be viewed from different time zones?
Basically I need not only the date but also the time (minute granularity is enough).
for instance, if we have a datetime like
1st jan 2005 at 01:45 AM in GMT stored in the db,
a user from US would see it as 31 Dec 2004 at 08:45 PM in GMT-5 time zone and someone in Asia would see the same transaction at 1st Jan 2005 6:45 AM in GMT+5 timezone.
This way the aggregates would change according to where the data is viewed from, but that is what my users want...
I considered having several time dimensions (one per time zone), but I already have time playing 8 different roles in my cube, so 8*24 time dimensions seems a bit akward...
Thanks
Were you able to find out anything on this?
|||Not sure if this is even more awkward.Suppose you have original table having columns:
GMTDate (KeyColumn)
GMTMinute (calculated column from GMTDate or populated by algorithm)
GMTHour (calculated column from GMTDate or populated by algorithm)
GMTDay (...)
GMTMonth (...)
GMTYear (...)
That original table is probably populated by some time generation code you have. So we can extend that code to generate more columns or create calculated columns on DSV:
GMTPlus1Minute
GMTPlus1Hour
GMTPlus1Day
GMTPlus1Month
GMTPlus1Year
We can create this way other sets of columns. Note that we do not need columns like GMTPlus1Minute, GMTPlus2Minute ,... We can have just Minute column. But i suppose later we can not have shared Minute attribute.
When we create time dimension we would have key attribute bound to GMTDate. The fact tables would also contain GMTDate and we will use those in the relationships. Other columns would be used for attributes used in different hierarchies.
USA Time Hierarchy
"Year" level <- GMTPlus5Year attribute
"Month" level <- GMTPlus5Month attribute
"Day" level <- GMTPlus5Day attribute
"Hour" level <- GMTPlus5Hour attribute
"Minute" level <- GMTPlus5Minute attribute
It really depends what user interface you have and how efficient it can hide different things (is it easier to hide dimensions than hierarchies or it does not matter).
|||
You might be interested to read this entry on my blog, where I discuss this problem:
http://spaces.msn.com/cwebbbi/blog/cns!7B84B0F2C239489A!367.entry
|||I think the adding additional columns to you time table and treating them as translations of the time member names would a solution worth looking at. This gives you the benifit of also being able to give formats that are cultur specific. On the downside, your timezone is based on your UI culture which doesn't work for timezones within the same country.
For populating the localized time columns you could write some managed code that uses .Net to convert to the date/time to the appropriate timezone and then format in the desired culture.
Modelling a Time dimension with date & time & time zone info
Hello,
Suppose you have original table having columns:
GMTDate (KeyColumn)
GMTMinute (calculated column from GMTDate or populated by algorithm)
GMTHour (calculated column from GMTDate or populated by algorithm)
GMTDay (...)
GMTMonth (...)
GMTYear (...)
That original table is probably populated by some time generation code you have. So we can extend that code to generate more columns or create calculated columns on DSV:
GMTPlus1Minute
GMTPlus1Hour
GMTPlus1Day
GMTPlus1Month
GMTPlus1Year
We can create this way other sets of columns. Note that we do not need columns like GMTPlus1Minute, GMTPlus2Minute ,... We can have just Minute column. But i suppose later we can not have shared Minute attribute.
When we create time dimension we would have key attribute bound to GMTDate. The fact tables would also contain GMTDate and we will use those in the relationships. Other columns would be used for attributes used in different hierarchies.
USA Time Hierarchy
"Year" level <- GMTPlus5Year attribute
"Month" level <- GMTPlus5Month attribute
"Day" level <- GMTPlus5Day attribute
"Hour" level <- GMTPlus5Hour attribute
"Minute" level <- GMTPlus5Minute attribute
It really depends what user interface you have and how efficient it can hide different things (is it easier to hide dimensions than hierarchies or it does not matter).
|||
How would you model a time dimension such that data in transactional source can be viewed from different time zones?
Basically I need not only the date but also the time (minute granularity is enough).
for instance, if we have a datetime like
1st jan 2005 at 01:45 AM in GMT stored in the db,
a user from US would see it as 31 Dec 2004 at 08:45 PM in GMT-5 time zone and someone in Asia would see the same transaction at 1st Jan 2005 6:45 AM in GMT+5 timezone.
This way the aggregates would change according to where the data is viewed from, but that is what my users want...
I considered having several time dimensions (one per time zone), but I already have time playing 8 different roles in my cube, so 8*24 time dimensions seems a bit akward...
Thanks
Were you able to find out anything on this?
|||Not sure if this is even more awkward.Suppose you have original table having columns:
GMTDate (KeyColumn)
GMTMinute (calculated column from GMTDate or populated by algorithm)
GMTHour (calculated column from GMTDate or populated by algorithm)
GMTDay (...)
GMTMonth (...)
GMTYear (...)
That original table is probably populated by some time generation code you have. So we can extend that code to generate more columns or create calculated columns on DSV:
GMTPlus1Minute
GMTPlus1Hour
GMTPlus1Day
GMTPlus1Month
GMTPlus1Year
We can create this way other sets of columns. Note that we do not need columns like GMTPlus1Minute, GMTPlus2Minute ,... We can have just Minute column. But i suppose later we can not have shared Minute attribute.
When we create time dimension we would have key attribute bound to GMTDate. The fact tables would also contain GMTDate and we will use those in the relationships. Other columns would be used for attributes used in different hierarchies.
USA Time Hierarchy
"Year" level <- GMTPlus5Year attribute
"Month" level <- GMTPlus5Month attribute
"Day" level <- GMTPlus5Day attribute
"Hour" level <- GMTPlus5Hour attribute
"Minute" level <- GMTPlus5Minute attribute
It really depends what user interface you have and how efficient it can hide different things (is it easier to hide dimensions than hierarchies or it does not matter).
|||
You might be interested to read this entry on my blog, where I discuss this problem:
http://spaces.msn.com/cwebbbi/blog/cns!7B84B0F2C239489A!367.entry
|||I think the adding additional columns to you time table and treating them as translations of the time member names would a solution worth looking at. This gives you the benifit of also being able to give formats that are cultur specific. On the downside, your timezone is based on your UI culture which doesn't work for timezones within the same country.
For populating the localized time columns you could write some managed code that uses .Net to convert to the date/time to the appropriate timezone and then format in the desired culture.
sql
Subscribe to:
Posts (Atom)