i am new to dimension modeling and OLAP.
I am trying to create a dimension model for a shop.
"order" table is having columns:
'order_id(auto generated), total_order_cost, date, product_Set_Id'.
"Product_set" table (contains products ordered in each order i.e. multiple rows for each order, tables logically linked by 'product_set_id' column) has columns:
'product_set_id, product_name, quantity,Cost_per_quantity'.
In the ER model "product_set" table is kind of weak entity dependent on "order" table.
My doubt is in the fact table
case 1: i should add only 'order_id(fk)' and 'total_order_cost(as measure)'
==>in this case measures from "product_set" won't be there in fact table.
or case 2:i should add 'order_id(fk)','product_set_id(fk)' and 'cost_per_quantity(measure), quantity(measure), total_order_cost(measure)'
==>in this case there will be multiple rows for same 'order_id' and 'total_order_cost'
There are other some tables like "customer" etc but i have doubt in above mentioned.
Thanks in advance!
one suggestion always made is to create a surrogate key on the tables. My fact sales is such that it has the surrogate key which allows me to have the orderline data there and each orderline identified by a surrogate key (which I don't really use - but its not an issue) . That way you can follow case 2.
Does that answer the question?
Related
I am currently building a tabular cube in SSAS, however I'm having issues when creating relationships.
I have 3 tables
Master
Supplier
Customer
In the master table I have a list of unique IDs, these ID's appear in the other 2 tables (there can be duplicate records for the ID in the Supplier and Customer table).
What I'm tring to do is create a relationship between the Master table and the Supplier and Customer table. One to Many. But SSAS gives me an error The relationship cannot be created because each column contains duplicate values. Select at least one column that contains only unique values.
Any advise would be greatly appreciated
Based on the error message it seems to be there are some duplicate values in the master table within the column that is being selected for relationship.
The database has a table called "categories" with columns CATEGORY_ID(primary key) and CATEGORY_NAME.
I have subcategories for each category.
For better accessing which is the best method from the below methods.
Method 1: The "CATEGORY_ID" column in the "categories" table is a FOREIGN KEY in the "subcategories " table.
Method 2: Maintaining a separate table for each category representing the subcategories.
I prefer to use same table for category and sub category
like
Table Categories
[CATEGORY_ID, CATEGORY_NAME, PARENT_CATEGORY_ID]
In case you don't know how many sub categories are there.
This scenario is just an example, the scenario is as follows: We have a product table where all the records of products are stored. Same way we will have customer table where records of customers are stored. The daily sales keep the record of all the sales. This sales table will keep record of which product who has purchased. So linking is to be done from Sales table to product table and customer table.
The query to link the two tables is as follows:SELECT product_name, customer.name, date_of_sale FROM sales, product, customer WHERE product.product_id = sales.product_id and customer.customer_id >= sales.customer_id LIMIT 0, 30
It is better to go with Method 1 since it is more scalable.
Let me elaborate on this. If we go with method 1, we need to maintain 2 tables only that is Categories and Subcategories. In future if we have new categories or subcategories we can directly deal with this 2 tables.
If we consider same situation with Method2 then we need to create new tables every time, this may become maintenance overhead.
Let me be a bit more direct. You explain in a comment that Method 2 is a separate table for each category. If so, then Method 2 -- in general -- is just wrong.
There are two methods for storing this type of information. One is a Categories table with a (single) Subcategories table. The Subcategories table would have CategoryId, a foreign key reference back to Categories. This is the normalized data model.
The second method is to store everything in one table. Each row would be a category/subcategory combination. Information about a given category would be duplicated across multiple rows, so this is not a normalized approach. However, this is a typical approach when doing dimensional modeling for decision support systems.
If the subcategories are just names of things, there is a third approach, which would be to store a list of the subcategories within each Category row. The list would not be a delimited string. It would be JSON, a nested table, XML, array, or similar collection data type supported by the database you are using. I am mentioning this as a possibility, but not recommending it.
I am using MS-Access database.
I am trying to make relationship with two tables, Old Customer table having data and Newly added coupon table.
As my client want to introduce new concept of coupon, where customer come with coupon instead of giving cash.
I have inserted Coupon code in coupon table in bulk.
Now, I am confused about what kind of relationship I should create with these two tables ?
I have to consider the below things...
customer can give either cash or coupon.
IF customer show the coupon, there will be an entry in CouponID column
as well in cash column (to know the value of that coupon.)
The CouponID should be unique in the customer table, Coupon Code should
not be repeated.
I am confused whether it should be one-To-One or One-To-Many ?
This image will help you to understand the problem.
I would not include "CouponID" in the customer table at all (nor "Cash" for that matter). The customer table models a customer, the coupon table models a coupon.
You need another table to model the transaction:
[CustomerTransaction]
id
date
customer_id
coupon_id
etc...
Every type of independent "thing" should be modeled by a discrete table. and "things" should be related to each other by other tables that create the 1:N relationship.
The relationship of customer to coupon is an optional (ie nullable) one-to-one; your data model looks good.
Some other comments:
The table would be better named sale rather than customer, since if the same customer comes back again, there will be a new row (but with the same name)
You could create a unique index on couponID that ignores nulls
You could rename Cash to Amount; the amount is either "cash" or coupon - the couponID column tells you the type of the amount
To create a unique index that ignores nulls:
CREATE UNIQUE INDEX idx1 ON customer (couponID) WITH IGNORE NULL;
I have a table Page [Id, Name]. And table Element[Id, PageId, ViewId, ViewType, Order], where ViewType is name one of the tables: Portfolio, Fund, Position. And ViewId is id of element in relevant table: PortfolioView, FundView, PositionView.
View tables looks like: [Id, PortfolioId, ShowName, ShowYTD, ShowMTD and other]. When I create an item of Element it means that created item of one of the "view" tables.
So for me it looks like a antipattern.
In short, I wish create a model of Page, which contains a ordered Elements which represent a one of the Views (portfolio, fund or position). Which way is better to do it in sql?
The way I've seen this done is to update your Element table with a column for each of Portfolio, Fund, and Position. The columns need to be nullable, but they'll be legal foreign keys, so SQL will enforce foreign key correctness for you.
If you want to be as technically correct as possible, you could also do the following:
Page[Id, Name]
Element[Id, PageId, ViewId, ViewType, Order]
Element_Portfolio[ElementId, PortfolioId]
Element_Fund[ElementId, FundId]
Element_Position[ElementId, PositionId]
Portfolio[...]
Fund[...]
Position[...]
This avoid having nullable columns, but requires you to have more tables and therefore more joins when you do a query.
I'm dealing with this situation. I've got three tables in SQL SERVER called Movies, Series and Orders.
Orders has an ItemId where this could be a MovieId (Movies PK) or SerieId (Series PK). I mean, in Orders table could have records where are from movies of series.
I don't know how to maintain this relationship or which could be the best way to implement it. Until I know, I only can create 1 to 1 or 1 to many relationships between 2 tables, not for 3.
Thanks in advance.
In this case I think it would be better to store Movies and Series in the same table with the common attributes incl. a column which indicates the type (Movie or Serie) and then have the additional attributes in seperate tables (if you want to normalize) or even in the same table (in order to avoid joins).
You should learn about implement table inheritance in sql-server.
Do you have a product and this product may be a Movie or a Serie.
In linked sample a person may be a student or a teacher.
The best way is:
create a generic table for movies and series with the fields that both entities should share (like ItemId).
create a table for movies that references the table created on step 1, containing the fields that must be compiled only for movies. This new table will be in relation one-to-one with the previous one.
same thing for series.
create the orders table and set ItemId foreign key to point to the ItemId primary key of the table created on step 1.