Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Time is almost always a dimension in a star schema.</p> <p>"In effect" suggests that there is a start and end date for a Promotion.</p> <p>So a Promotion might itself be a fact that has a start and end date reference to the Time dimension.</p> <p>Maybe with a model like this you could have a JOIN table to relate Sale to Promotion in a many-to-many fashion between facts.</p> <p>"Many, many" Promotions - yes, but how large is that? One per day means 365 records per year. I'll assume that Promotions are associated somehow with Products or Categories. A Sale would have a timestamp and multiple Products. </p> <p>You have to store them somewhere, sometime or your model falls apart. Why the reluctance to model Promotion that way? </p> <p>My advice would be to not worry about the size of the data and concentrate on modeling the problem as best you can. Get the logical model right first, then worry about the physical model and the data sizes.</p>
    singulars
    1. This table or related slice is empty.
    1. POStar schema [fact 1:n dimension]...how?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. This table or related slice is empty.
    1. USduffymo
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COThis i a fictitious example, but the reason I couldn't use time as a join would be that a particular product is under a promotion during a time period when not all products are under the same promotion. Think of coupons, these are promotions which can apply to specific products, but they can also apply to more than one product at a time. I know I have to store promotions somewhere, but having a dimension for every promotion would not work. I know enough at this point to know that I don't want a fact table with 3000 columns, most of them pointing to a "Not under this promotion" record.
      singulars
      1. PO
      1. USMike Gates
    2. COEverything I read about star schema says that time is the FIRST dimension you include. And I don't think it would be 3000 columns point to promotion, which would obviously break first normal form for any relational model. It would be a single key to the promotion at hand for that sale. How many apply to a single sale?
      singulars
      1. PO
      1. USduffymo
    3. COI hoped it wouldn't get to this. This was a fictitious example so of course logical holes would develop. How about...each POS entry can be a member of 1 or more named groups. There can be any number of these groups and are assigned by a grouping table out in the normal relational world. I want to be able to query the cube (built from the star schema) to find out what POS entries fall into groups: "Group 1", "Group 2" and "Group 3". And again, there can be any number of groups out there as they are custom created by managers or something like that.
      singulars
      1. PO
      1. USMike Gates
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload