Datawarehouse framework implementation

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Datawarehouse framework implementation

Jacopo Cappellato
Hi all,

my design effort for the implementation of a PoC of data model, and
supporting ETL services for datawarehouse is slowly progressing (in my
free time) and hopefully soon I will be able to commit some stuff for an
early review from the community.

In the meantime I need some advices for the naming conventions for the
new entities:

1) how should we name the "dimension" entities (products, dates, times,
stores)? Ideally, it'would be nice to use the "<EntityName>Dimension"
(e.g. "ProductDimension") syntax... but unfortunately it would lead to
table names that are too long. Other options are: "<EntityName>Dim"
(e.g. "ProductDim"), "<EntityName>s" (e.g. "Products")

2) same question for the "facts" entities: "<EntityName>Fact" (e.g.
"InvoiceItemFact")?

3) same question for the name of the view entity that implement the star
schema (one fact associated to many dimensions):
"<EntityName>StarSchema" (e.g. "InvoiceItemStarSchema")

4) about the naming conventions for the entity package names, is it ok
to use the following ones?
org.ofbiz.olap.<ComponentName>.dimensions.<DimensionEntityName>
org.ofbiz.olap.<ComponentName>.facts.<FactsEntityName>
org.ofbiz.olap.<ComponentName>.starschemas.<StarSchemaViewName>

Thanks

Jacopo

Reply | Threaded
Open this post in threaded view
|

Re: Datawarehouse framework implementation

David E Jones

In general with these questions I think we're just going to have to  
try it out and see if we like it or not.

For 1 and 2, yeah we do have length limits and we may want to use  
abbreviated suffixes. The good part is that most of the entities  
we'll want to have facts and dimensions for are "primary" entities  
that intentionally have shorter names to accommodate suffixes for  
related entities.

For #3 we can make them nice and long as the length of view-entity  
names isn't restricted so much.

The pattern in #4 is interesting, though I think another level below  
ComponentName might be helpful, kind of like we currently have,  
because we may eventually have an awful lot of this sort of entity.

-David


On Feb 27, 2007, at 12:29 AM, Jacopo Cappellato wrote:

> Hi all,
>
> my design effort for the implementation of a PoC of data model, and  
> supporting ETL services for datawarehouse is slowly progressing (in  
> my free time) and hopefully soon I will be able to commit some  
> stuff for an early review from the community.
>
> In the meantime I need some advices for the naming conventions for  
> the new entities:
>
> 1) how should we name the "dimension" entities (products, dates,  
> times, stores)? Ideally, it'would be nice to use the  
> "<EntityName>Dimension" (e.g. "ProductDimension") syntax... but  
> unfortunately it would lead to table names that are too long. Other  
> options are: "<EntityName>Dim" (e.g. "ProductDim"),  
> "<EntityName>s" (e.g. "Products")
>
> 2) same question for the "facts" entities: "<EntityName>Fact" (e.g.  
> "InvoiceItemFact")?
>
> 3) same question for the name of the view entity that implement the  
> star schema (one fact associated to many dimensions):  
> "<EntityName>StarSchema" (e.g. "InvoiceItemStarSchema")
>
> 4) about the naming conventions for the entity package names, is it  
> ok to use the following ones?
> org.ofbiz.olap.<ComponentName>.dimensions.<DimensionEntityName>
> org.ofbiz.olap.<ComponentName>.facts.<FactsEntityName>
> org.ofbiz.olap.<ComponentName>.starschemas.<StarSchemaViewName>
>
> Thanks
>
> Jacopo
>


smime.p7s (3K) Download Attachment