I've got a question about how to create one dimension in SSAS that contains a hierarchy built from two dimensions.
I have a fact-table:
sales
and a many-to-many relation between two dimensions:
customers
bridgecustomersTerritory
territory
And the Territorydimension is at the moment built as a ragged hierarchy containing a ID and a parentID.
This works fine if i use the Territory dimension and Customer dimension apart from eachother as dimensions.
But i would like to add the customer at the bottom of the territory hierarchy
Is this even possible with the setup that i've got right now?
If i change the Territory to a "normal" hierarchy with a solid number of levels, would that help?
//Kriss
You cannot have attributes from two dimensions in one hierarchy. And as you use a many-to-many relationship between customer and territory, I assume you need it as a customer can be located in several territories, and there is obviously more than one customer per territory.
But why do you want to have customers and territory in one hierarchy? You can have them in separate hierarchies, and still use them in one query. In MDX, and hence in most client tools accessing Analysis Services that I know, you can drag more than one hierarchy to the rows or columns.
UPDATE
To some extent, I can understand the requirement to combine things. In a client tool that I developed, we do not expose the dimensions to the user at all, we are just using the display folders of the attributes/hierarchies. In this way, we can show attributes/hierarchies close together even if they technically need to be in different dimensions due to the modeling requirements. But they are still separate attributes/hierarchies, and users work well with this.
Yes, if you would want one hierarchy, you would need to integrate the customers into your territory dimension, taking care that you break down a customers measures like sales correctly between the different territories. And if you can do that easily, maybe there is no need for a many-to-man relationship at all.
Related
We had an MS Access guru at our company who left for another position. Before she left she gave me a quick introduction on how to create queries from a sql server. I am really struggling with this and as I have no one to turn to at our company I was hoping you guys could help.
Hope you can help!
Thanks!
Well, keep in mind that when you build a query, it DOES NOT necessary mean that a enforced relationship exists here. (it might).
Further more, if you imported the tables, then again its doubtful that relations are defined in Access unless you use the relationships window to "enforce" such relationships.
However, when building a query? We will often join on two fields. When you build a query in the query builder, you are free to "make up" any kind of join you want.
Say I was given two different spreadsheets. One had some people, and another had a list of hotels.
Ok, so say we want to generate a list of all people in the same city as the hotels.
You might join between table "People" and say Hotels with city.
however, WHAT happens if there is more then one state with the same City name?
Well, then just join on City AND State!!!
So you get this:
So I not have some related tables here. I just feel like and want to, and need to join the two tables of data.
As such, we never cared or setup or "had" some relationship defined, but all we care about is creating and building a working query.
So, don't confuse the simple act of building some query with that of having setup a corrrect relatonships between tables.
For a working application? Yes, you most certainly will setup relatonships.
So, if you setup relatonships correctly, then you not be able to say add a customer "invoice" reocrd without FIRST having a customer record. You don't have to do this, but it is a very good idea for a working applicaton.
However, when dealing with imported data? You often may not have an pre-defined relationships.
Now, of course in "most" cases, a query that involves multiple tables will in near all cases "follow" what you defined as relationships in the relationships window but it not necessary a requirement at all.
As noted, when building a working application? Then yes, of course you want to setup the relatonships BEFORE you start adding data.
But for general data processing, and creating queries against say different tables of data you are slicing and dicing and working with?
You are free to cook up and draw lines between the tables in the query builder, and as such, often such quires will have zero to do with the relationships you defined, or in fact even when you don't have any relationships defined at all.
That above People and the list of hotels is a great example. I mean, it rather cool that I simple joined on both City and State, and did not have to write one line of data processing code for my desired results
(a list of people in cities that live in the same city as my hotel list).
So don't confuse what we call "referential integrity" and defined relationships. We define these relationships so it becomes impossible for you the developer to add a customer invoice without first having added the customer. And it also means that you, your code, or even a editing the tables directly will not allow this to occur.
However, when dealing with just reporting, or importing data to work on? Well, then often we will not have any relationships defined, but that sure does not stop us from firing up the query builder and drawing join lines between tables.
Between two given Tables you can have one relationship involving two (of more) fields or two (or more) relationships each involving one field. Both cases are possible and have different implications.
The first case, as the first commenter pointed out, is typically used when you have a compound key in the master Table of the relationship.
The second case is typically used when you have two candidate keys in the master table, each of which is used as a master field in each of the two independent relationships.
In Ms-access the case of two independent relationships may be identified because it implies two table-boxes for the same table in the relationships pane.
Being new to relational database design, I am trying to clarify one piece of information to properly design this database. Although I am using Filemaker as the platform, I believe this is a universal question.
Using the logic of ideally having all one to many relationships, and using separate tables or join tables to solve these.
I have a database with multiple products, made by multiple brands, in multiple product categories. I also want this to be as scale-able as possible when it comes to reporting, being able to slice and dice the data in as many ways as possible since the needs of the users are constantly changing.
So when I ask the question "Does each Brand have multiple products" I get a yes, and "Does each product have multiple brands" the answer is no. So this is a one to many relationship, but it also seems that a self-join table might give me everything that I need.
This methodology also seems to go down a rabbit hole for other "product related" information such as product category, each product is tied to one product category, but only one product category is related to a product.
So I see 2 possibilities, make three tables and join them with primary and foreign keys, one for Brand, one for Product Category, and one for Products.
Or the second possibility is to create one table that has the brand and product category and product info all in one table (since they are all product related) and simply do self-joins and other query based tables to give me the future reporting requirements that will be changing over time.
I am looking for input from experiences that might point me in the right direction.
Thanks in advance!
Could you ever want to store additional information about a brand (company URL, phone number, etc.) or about a product category (description, etc.)?
If the answer is yes, you definitely want to use three tables. If you don't, you'll be repeating all that information for every single item that belongs to the same brand or same category.
If the answer is no, there is still an advantage to using three tables - it will prevent typos or other spelling inconsistencies from getting into your database. For example, it would prevent you from writing a brand as "Coca Cola" for some items and as "Coca-Cola" for other items. These inconsistencies get harder and harder to find and correct as your database grows. By having each brand only listed once in it's own table, it will always be written the same way.
The disadvantage of multiple tables is the SQL for your queries is more complicated. There's definitely a tradeoff, but when in doubt, normalize into multiple tables. You'll learn when it's better to de-normalize with more experience.
I am not sure where do you see a room for a self-join here. It seems to me you are saying: I have a table of products; each product has one brand and one (?) category. If that's the case then you need either three tables:
Brands -< Products >- Categories
or - in Filemaker only - you can replace either or both the Brands and the Categories tables with a value list (assuming you won't be renaming brands/categories and at the expense of some reporting capabilities). So really it depends on what type of information you want to get out in the end.
If you truly want your solution to be scalable you need to parse and partition your data now. Otherwise you will be faced with the re-structuring of the solution down the road when the solution grows in size. You will also be faced with parsing and relocating the data to new tables. Since you've also included the SQL and MySQL tags if you plan on connecting Filemaker to an external data source then you will definitely need to up your game structurally.
Building everything in one table is essentially using Filemaker to do Excel work and it won't cut it if you are connecting to SQL, MySQL, etc.
Self join tables are a great tool. However, they should really only be used for calculating small data points and should not be used as pivot points or foundations for your reporting features. It can grow out of control as time goes on and you need to keep your backend clean.
Use summary and sub-summary reporting features to slice product based data.
For retail and general product management solutions, whether it's Filemaker/SQL/or whatever the "Brand" or "Vendor" is it's own table. Then you would have a "Products" table (the match key being the "Brand ID").
The "Product Category" field should be a field in the "Products" table. You can manage the category values by building a standard value list or building a value list based on a "Product Category" table. The second scenario is better for long term administration.
I've done a bit of research on how to order the database to deal with a hierarchy.
Here's what I'm doing.
There are Companies that work on communication technology. That is what I'll call a general Technology. There are different types of Comm Tech, lets say RF and Laser. So there is a category, and two subcategories.
Take another category - Welding. Specific Types of welding could be plasma, and laser. So now I've got laser twice, but it belongs to two different categories. This will happen over and over with various main categories and subcategories.
I can make my peace with the variety of different options on how to arrange the table relationships. I am having trouble figuring out how to present this to users with forms.
There are two main user forms that have to be made, one for adding General Tech, Specific Tech, and the relationships between them. The second is the Form that shows the Company, and lets the user select MULTIPLE general technologies, along with the specific tech that goes along with each of those.
What I'm stumped on is how to allow (on the form) for N general technologies that are tied specifically to this company. I looked on the NorthField database, and thought that maybe the order details was the way to go, but wasn't sure.
Is there an example out there, or a design pattern, or something that I should be following to make these forms?
Thanks
We are trying to set our BI team's reporting standards for Business Objects Universe Designer and Web Intelligence tools. We set some standars like below.
What are your ideas about these standards? Could you please share your standards documents?
Name the universe based on the application.
Give proper name universe objects (classes, dimensions, measures etc) according to
business terminology and being explicit in the definition. For
instance, an object called 'Sales' could be interpreted many
different ways. Is it Sales Revenue, Count of Sales Orders, Count of
Sales Order Lines, Average Sales Amount.
Company logo is put on the upperleft side of the report.
User prompts and last refresh time is put on the upper-right side of the report.
The title and report name describes the scope of the data (for example, university wide, unit specific, school/college level) and any conditions in the report (for example, term, fiscal year, department ID).
The columns of data are arranged in logical order.
When prompts are used, they model how the data should be entered. For example, “Enter the term (e.g. 1760)”
I think that this is a bit off topic for stackoverflow, and some of it is not clear or is commonsense anyway (eg. "columns of data arranged in logical order"), but I would suggest:
that every universe be associated with a three character code (eg. SAL, REV etc).
that every report be uniquely identifiable by a number, prefixed by the Universe code.
that non-trivial objects have as part of their definition a SQL-format comment giving their name and folder.
There two aspects :
Considering the technical aspect of the universe
Considering the end-user aspect of the universe
Technical aspects :
Layout of your tables should reflect your navigation
Version information/changes in either comment / hidden objects
try to use aliases as much as possible to show in what function your table is used.
try to refactor used constants in separate objects and use the #select to use them.
try to have a hierarchic naming convention so that the name will imply the navigation.
find a fitting naming convention for your connections.
User aspects :
DON'T DO THIS folder = table name , object = column name, it comes from dragging and dropping your tables.
object name is not literature, you are limited. It should be clear what the object is. Add comments always comments.
Limit number of folders, limit folder depth, limit number of objects in a folder.
Order the objects based on their use inside folder(most used on top).
First of all, this is very, very simple data warehouse that I made only to ask following, specific question.
Scenario:
I have one fact table FactSales, and 2 dimensions: DimShop and DimProduct, and they are both separated from each other and directly connected to the fact table. some shops can sell selected products and vice versa, some products can be selled in specific shops. This give us many to many relationship. The problem is when I try to slice my cube i get all combinations between shops and products.
Question:
How can I create hierarchy between two separated dimensions in SSAS with many to many relationship? i tried to use brigde table but i was unable to configure hierarchy in SSAS. Is it even possible?
If you're trying to report on "what can happen" rather than "what did happen", you need a separate fact table & cube to represent the relationship between products and the shops that can sell the products. It's not really a hierarchy since it's many to many.
A simple cross reference fact should be fine:
FACT_PRODUCT_SHOP
ProductID
ShopID
Then when doing reports that want to see what products are allowed to be sold in what stores, you can use this fact table. The sales fact only shows "what actually happens".
You can even modify this fact to be your Inventory fact table, just adding a date and "In Stock amount" and "On order amount" etc..
It is possible to implement such a design but it may not perform well.
Basically instead of product and shop key in the fact table, you need an alternative key.
This key will be the unique combination of products and shops. That needs to be prepared in the ETL.
In a new dimension named "Shops and Products", on top of this key, you can create 2 hierarchies Product and Shop in the same dimension.
Additionaly, you can also create an unnatural hierarchy as you requested. But since it is an unnatural hierarchy, it may not perform well.
So in addition to Product and Shop hierarchies, you can provide following unnatural hierarchies: Shop -> Product, Product -> Shop.