We've a Tabular model which has 3 facts and few dimensions.
Out of the 3 facts 2 are about Account & Products.
Facts realated to acocunt of a customer. How many are active, how much is the current balance, how much was the balance at the start etc.
Product Fact is about different supplement products that a cstomer has. He/she may or may not have a supplement product. Now this has facts like how much the customer owes in different products, rebate amount etc.
Now they both have Dimension Account as common Dim.
Relation between Account & Product is 1-M. If an account has supplement product it can be 1, 2 and max 3. If it doesnt have, it is 1-0 :)
Problem we're having is that if we want to slice both fact by Account Dim attribute, we get only the accounts which have supplement product. Becuase I believe Tabular model works on INNER JOINS. In this case I want to have OUTER JOIN. Since I'd want to have all accounts come through in the query and where i've matching supplement product then the fact for that products.
Any help is appreciated.
Related
I’ve been asked create our analysis cube and have a design question.
We sell ‘widgets’ and ‘parts’ to go with those widgets. Each order has many widgets and sometimes a few parts.
What I’m stuck on is – to me, an order is a fact in a measure. But, what are the widgets? Are they a dimension and each fact in the measure will be an entry for every part and widget for the order.
So, if order 123 had widget 1 and widget 2 and part 5, then there will be 3 facts in the measure for the same order? Is that correct?
At its basic level you can consider most facts to be transactions or transaction line items. So, for example, you may have a 'sales' fact table in which each record represents one line item from that sale. Each fact record would have numeric columns representing metrics and other columns joining to dimension tables. The combination of those dimensions would describe that line item. So, in your case, you likely have something like:
1) A 'date' dimension detailing the date of the transaction
2) A 'widget' dimension detailing the widget sold on that transaction
3) A 'customer' dimension detailing the customer who bought that item (almost certainly the same customer would appear on every line item for this transaction)
4) ... determined by what information you have and what business problem you're trying to solve.
Now, the dimension tables contain further details. For example, your widget dimension table likely contains things like the name of the widget, the color, the manufacturer, etc. Every time your company sells one of these widgets, the record in the fact table links to that same dimension record for that name, color, manufacturer, etc. combination (i.e. you don't create a new dimension record every time you sell the same item - this is a one-to-many relationship - each dimension record may have many related fact records).
You other dimension tables would similarly describe their dimensions. For example, the customer dimension might give the customer's name, their address, ...
So, the short answer to your question is that widget likely is a dimension, items and widgets may (or may not) actually be the same dimension (in a school class I suspect that they are), and that you would have 3 fact records for that one transaction.
This is probably along the same lines as the prior answer but....
If you try and model "many widgets per order" you'll have issues because you end up with a many (order fact) to many (widgets) relationship. In a cube / star schema design, many to many relationship usually need to be moddeled out to be many to one in some way.
So what you do is try and identify what special thing identifies an "order" (as opposed to a bunch of widgets in an order). Usually that is simply stuff like order date, customer, order number, tax
An example way to model this is:
If you have a single order with five widgets, you model that as a fact table with five records that happens to have a repeating widget, customer, date etc. in it
Then you have to work out how you spread an order header tax amount over five records. The two obvious solutions are:
Create a widget that represents tax and add that as another record
Spread the tax over five records, either evenly or weighted by something
Modelling "parts" just takes these concepts further.
It is important to understand what the end user wants to see, why they want to see parts. What do they want to measure by parts, how do you assign higher level values (like tax) down to lower levels like parts.
I have a scenario where one sales guy is related to more than one departments, and I need to calculate the sales at sales rep level and department level. Please share the thoughts on how it can be modelled
My thought process is below
Option 1
I will be creating as 'Sales Rep' dimension and 'Department' dimension and connected it with a bridge table which has dept_id and sales rep_id
Here both the dimensions I prefer to have the history so it is SCD type 2
Option 2
I will be creating 'Sales Rep' dimension and 'Department' dimension and in department dimension, I will be adding the filed " sales rep id". which connects the Sales rep with Department.T he drawback I have observed here is Department details will be repeating in 'Department' table for each employee.
Here both the dimensions I prefer to have the history so it is SCD type 2
Please share your answer, the above options which one is better, or any other third best approach -
This answer is related to the business model more than to technological needs:
Options 2 makes the best sense if the sales person could belong to more than one department, keep the department at the "sales" fact table, and then no need to keep the department in the "sales person" dimension.
Option 1 makes the best sense if the sales person belongs only to one department at a time, but he might change departments, make this a Slowly Changing Dimension Type 2 in which you keep the history.
Slowly changing dimension means you don't need a bridge table, the department is part of the "sales person" table, and you can read more about it in the link provided.
In the odd case that a sales person can work in several departments and have people from various departments reporting to him, then all the hierarchical model should be in a different table. In SSAS a self-reflecting table doesn't work well, try to check ways in which to flatten those issues.
Please note that when you're designing a data warehouse the star schema means exactly that: data might repeat itself in different tables in order to make the reporting easier.
Those issues never have a clear cut solution and I advise you to read as much as you can on data warehouse design until your head spins in order to get your head around this.
I have a situation, where with time, the same logic has been scattered at different places (stored procedures) in the application. I am trying to bring it in one place and re-use it as required.
Scenario:
We sell products online, that are classified into categories and the business rules vary by category. When performing a search, it is possible that multiple products are returned from the same category.
Examples of business rules are:
Can the agent sell a product from this category (permission, licensing etc.)?
Can the category be sold in a particular state?
Is there a tax to be applied on the category?
What is the markup for this category?
Does this 'product' meet the customer's requirements?
Current Implementation:
Step 1 - Searching
We have a stored procedure that takes #agent_id, #state_id, #markup_amount, #category_id, #customer_id as inputs and returns all products from a specific category, that meet the customer's requirements. The customer's requirements are derived using customer_id. (SELECT 'product' stored procedure)
Step 2 - Quoting
When adding a particular product to the shopping cart, the above logic is again executed with an additional parameter #product_id, to make sure that the product being added to the shopping cart, satisfies the original requirements (INSERT 'cart' stored procedure)
Step 3 - Re-Validation
If the customer's requirements change, it is possible that products already in the shopping cart still qualify. The ones that do not qualify have to be removed from the UI (is_active_flag is set 0 on SQL). So we re-use the same logic to determine what the products still meet the customer's requirements. (UPDATE 'cart' stored procedure)
Step 4 - Sale
The customer can only buy one product from a particular category. When the customer is ready to buy, we re-run the same logic to see if that particular product still passes all business rules including meeting the customer's requirements (INSERT 'sale' stored procedure)
Consolidation:
What I am looking to do is consolidate this logic in one place and reference it in different stored procedures, as required. The only variable is #product_id. When the initial search is performed, we do not know what products will qualify. Once we have a finite list of product ids, we are drilling down that list at each step.
For Example: The search stored proc may return 500 products which forms the finite list and the customer may end up adding 3 products to the shopping cart, and in the end can buy only 1. The 3 products that were added and the 1 product that was ultimately sold are a part of the finite list of 500 qualifying products.
What is the most efficient way to achieve this? Thank you.
If your goal is create something readable, you can create a boolean sql function that evaluates each product in each scenario.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I wanted to ask your opinion on the following ERD diagram i made. Keep in mind that i haven't already represented the cardinality of the relations yet.
What i'm going for is:
A client goes in to buy a car;
The car can be upgraded with many extras which add up to the base price of the car;
The salesman can offer extras at no cost or offer a discount on the sale's total price in order to captivate clients;
What do you think of my diagram? Is it right? Do you see anything wrong?
[EDIT]
How do i go about representing the following scenario. A customer sells me a used car as a part of a purchase of a new car.
Whether your model is right or not depends on whether your model can capture all the business scenarios you described above - and IMHO, your model does that quite well (Congratulation!); barring few small anomalies such as, not having the Discount attribute in Order entity to capture overall discount on sales (which is a possible business scenario).
But when you create model like this, you should consider the final purpose of this model:
Is it for capturing transactional data (OLTP)?
Is it for storing data for reporting purpose (OLAP)
In your case, I believe your final goal is to capture business transactions by designing on Online Transaction Processing (OLTP) system. OLTP models are generally normalised in nature (due to the obvious benefits of normalisation such as reduced redundancy, update/ delete anomaly prevention etc.) Your model is mostly in 3NF form, except for few transitive dependencies. The column SalesTotal in entity Order appears to be a derivable column (based on Price and Discount which you have already stored in other entities) and, IMO, need not be separately maintained (read redundant).
Also based on your comment above,
extra's change price at any given point. Bu i should be ale to break
down the sale enough to see the original price of stuff at that date
I don't think you will be able to do it because your Extra entity is designed to store the current Price always. Your OrderDeatils contain the relationship between Car and Extra for any given point in time. If the prices of car and extra changes later, you will lose the old value as you will update the old price with new price. Hence, although you will be able to track the ID_Car and ID_Extra from OrderDetails, you won't know what were their historical prices during the time of order creation.
If you want to store historical prices, consider adding one more table each with Car and Extra to store past prices against dates.
client can act as a seller
In the situation when a client can act as a seller, the person will exist independently in both your Client and Salesman table... That's perfectly alright (Such design technique is called Vertical Separation).
Alternatively, if you really need a 3NF model, then you should create a new entity - Person containing attributes such as name, id etc. This Person entity will be used to store both your client and salesman details as technically both of them are some person, but their "role" is different. Once you have this Person entity, you can delete SalesMan and Client entities. Then in the Order entity, you already have a Clent ID and a Salesman ID attribute to define the relationship between two different persons (These Clent ID and Salesman ID will be Foreign Key to the Person ID in Person entity). Whether a person is playing the role of a salesman or a client can be known from Order entity.
Hope this helps
Pawnshop business model:
CLIENTES (customer table), LOTES (lot table), ARTICULOS (item table) and TRANSACCIONES (transaction table).
The reason I defined a lot table is because when customers pawn or sell items, the pawnshop groups all these items into one lot, calculates the total loan or purchase amount, stores these values under one transaction and prints the ticket with a description of all the items and total amount. So I want the ability to say, if customer defaults on interest payments or does not redeem pawn, then customer forfeits all items and pawnshop may choose to sell some items to gold refinery and/or transfer other non-gold items to inventory to sell to the public. In other words, I want the ability to do a break-out explosions of each item.
Would the above ER be adequate for this capability?
From the point of view of a logical model, you probably don't want store_id on the lot (as it comes from the customer) or the transactions or articles (as they get it through the lot and customer). At the physical level you might have those as attributes (called denormalisation), you have the risk of data showing, for example, LOT 1234 being on CUSTOMER C12 and at STORE S1, while the customer table has C12 being at store S2.
Of course it is possible that you allow Mr Smith to pawn an item at one store but make payments on it at another. Or perhaps an item might be pawned at one store but physically relocated to a different one for security or space reasons. If so, then it is appropriate to have distinct store ids on these entities.
However that doesn't sit comfortably with the 'store' being an attribute of the customer, since that implies they have a relationship with only one store.
Also consider what happens if MR P BROKER has three stores, but decides to close one and move the business to one of the others. You need to merge the stores but do you update the store id on all the transactions and articles and lots (including ones that are 'in progress' and those redeemed) or do you leave them with the original store id ?
Another common data modelling issue is identifying customers. Is Mr Smith one customer and Mrs Smith another, or can Mr and Mrs Smith be 'parts' of the same customer ? If Mr Smith pawns something, can Mrs Smith redeem it ? I'm thinking family squabbles, disputed heirlooms.... Perhaps she can't redeem it, but can make payments on it.
If an item (eg a watch) is included in one lot, then redeemed, then included in a different lot, does it get a different item_id ?
When a client buys an article offered to the general public, is that a transaction? Or does your database only track transactions about lots?
Can an item exist in your system without being part of any lot? You can't express that fact in the ER model you've presented.
Your ER model doesn't show any many to many relationships. That makes me suspicious. I've never worked in a pawnshop, so I can't say for sure. But every other enterprise database I've ever seen has at least one many-to-many relationship. Sometimes a relationship is treated as though it were an entity, and appears with a box of its own. But that box would be on the "infinity" end of more than one relationship, something I don't see in your diagram.
Buena suerte.