I have two Tablix/tables in Report Builder, one is a Profit & Loss (P&L) and the other is Key Ratios.
Both the P&L and ratios are separate datasets in Report Builder with their values being defined by DAX queries that reference Calculation Groups in my Model. The issue I have is that I want the P&L and Key Ratios grouped together by Area Manager (the report parameter) e.g.
If Area Manager 1 has 3 stores, Store A, B and C they would receive a report like this: -
Store A P & L
Store A Key ratios
Store B P & L
Store B Key ratios
Store C P &L
Store C key ratios
At the moment, the report reads like this: -
Store A P & L
Store B P & L
Store C P & L
Store A Key ratios
Store B Key ratios
Store C Key ratios
I’ve tried all sorts of ways to get round this: -
I’ve created a DAX query that unions two queries to have the two datasets consolidated into one and thus just one table/tablix. Line breaks are added between the two queries in DAX and then conditionally format the different data in Report Builder to give the appearance of two separate reports grouped by store. However, this is not ideal, and it seems to be interfering with the calculations being performed on the key metrics.
The other method I have tried is to use sub reports. I’ve tried a number of variations but the closest I can get to is a situation where I get the first P&L, followed by all key ratios, followed by the second P&L and all key metrics, etc: -
Store A P & L
Store A Key ratios
Store B Key ratios
Store C Key ratios
Store B P & L
Store A Key ratios
Store B Key ratios
Store C Key ratios
The problem here is that the first report receives the Area Manager Parameter displaying the first store, but the key ratios report receives the parameter and lists every single store key ratios underneath the first P&L.
I somehow need to group by Area Manager (the parameter in both reports), but then loop through each individual store for that Area Manager separately to pass to the second report (the sub-report) that relates to the first store in the first report, then the second store in the first report, etc.
Is that possible in SSRS/Paginated Reports? If it is, how would I go about creating this?
Many thanks for your help.
Related
How do I use Power Pivot to summarize data in groups which are defined in a separate, non-relatable table
I'm analyzing a database that has the following tables:
Sales
Store
Category
Units
Sales
Stores
Store
address
etc
StoreGroups
Store
Group
A store can be in multiple groups (i.e. store B762 is in NW group & control_group) hence the StoreGroup table - where the two fields together make the primary key. Therefore, I can't relate StoreGroups to my Sales table, because both have duplicate Store values.
Right now all stores are being reported in each group:
PivotTableScreenshot
to confirm, if a store is in two groups, its sales should get counted for BOTH groups i.e. control group and NWRegion.
I've tried to adapt this DAX example mentioned below but have not been successful:
http://www.daxpatterns.com/dynamic-segmentation/
You have a many-to-many relationship between stores and groups.
You should be able to create a relationship from the store in StoreGroups and the Store in Stores (StoreGroups is a bridge table).
If you can post a link to some sample data, that would be helpful.
After doing that, you can read start to read about writing DAX formulas for many-to-many scenarios here. Be sure to also read in the comments, especially the one from Marco Russo.
The question I have below is hypothetical, I'm using SSAS:
Let's say I have a dimension (dim_Product) representing products I sell in a store, I have another dimension (dim_Employee) representing the company's employees and I have a fact table (fact_EmployeeSalesPerMonth) showing how many products each employee has sold for this month.
Now, lets say that each product has a category, and I have a requirement from a client to display this category data in a report which pulls data from the warehouse. Let's say the question my client is trying to answer is "What employees are best at selling what categories of what products?".
The category of product from the source system is set by using a drop down list of predefined values. Let's say that the pre-defined values are electronics and hardware. This category text is stored on the dim_Product dimension as a text column.
Now let's say that we add a third category of products (children toys) in our source system, which at the moment, contains no products. My client would like the report to show this category. It's obvious that I'm not bringing through this category data, since there are no products linked to it.
My question is, if this is the requirement. How would I store this data in the warehouse? Where would I store it?
I've considered moving the category data to it's own dimension and then having a category key on the fact table pointing to the category dimension, but I'm not sure this is correct. This means that any fact table I create in the future, that is linked to dim_Product, would need to be linked to the product dimension as well as the product category dimension and have keys pointing to both.
You are addressing several things in your question, so let’s go it through step by step
Product Category Dimension
A product category is an example of a dimension hierarchy. The first thing I’d recommend is to store the product category in the product dimension table as an additional attribute, possible with other attributes such as subcategory, super-category. You may define so a product hierarchy with several levels.
The obvious consequence of this design is that if you want to introduce a new category you need at least one (e.g. dummy) product.
The fact table contains only the product ID.
Reporting of Product Category
If you report on a product level, i.e. with dimensions month, product, category you will need a “non existing” product to fill in the report, so the “dummy” product entry in the dimension table is justified.
To get the dimension entries without usage in the report you may either integrate it in the reporting query or made an additional query – “what was not used?”. Which is better depend on your mileage, in case that you considers product IDs in the fact table that are not defined in the dimension table too, you will end in a full outer join (which could affect the performance) so you could find the latter option (with extra query – product from the dimension table that does NOT EXISTS in the fact table) more flexible.
If you report often only on the category level (without a product), you may find useful to define a category table. Especially if the category has other attributes such as description it is more convenient to have it in a dedicated table that to recover it from the product dimension with a DISTINCT query.
Storing the category ID in the Fact Table
The driver for this decision is in the dynamic of you product hierarchy. If there are changes in the product categories over time this approach delivers out of the box history of the attribute. You are able after the re-assignment of the product category to report the “correct” category in which the product was sold. (But you may also report all sales with the new category, simple ignoring the entry from the fact table and taking the category from the product dimension). The point here is IMO not in the decision if there is a category dimension, but if it is required to maintain a history of the product attributed (here the catrogory).
So if you read my answer and summaries what I recommend, finding that for the topics
Extra category dimension table
Storing category key in fact table
Outer join or extra query to find not used dimensions
the answer is it depends – you got it!
I would make product category as an standalone dimension only if it is frequently used without a product list. If it is not frequently used or if it is mostly used with product list together, then it would make sense to make it an attribute instead.
Standalone dimensions are generally faster(I saw 50% reduction in query times when such attributes are used) but also cost more space/load time.
I saw about 7% size increase in a very big cube we had per such new dimension.
I would avoid them if they are not frequently used. It is about finding the correct balance. In my case, I had 50+ such attributes in one of the dimension and that would have made the cube a lot larger and it is already a large cube anyway.
By the way, by making it a part of Product dimension, a query bringing products corresponding to a category can be resolved by using autoexists instead of fact retrieves.
I've been using Access to create simple databases for a while with great success, but have run into a problem I can't find an answer to.
We ship individualized serialized units to various end-users, and occasionally to resellers that stock them for end-users. I must keep track of which serial numbers end up with each end-users.
The first database I created to handle this recorded company information in one table using their account number as primary key, order information in a second table using the order number as the primary key and linked via the company name, and unit information in a third table with the serial number as the primary key and linked via the order number.
This worked very well until I had to account for these stock orders with a reseller. As it was structured, every unit was linked to one company via the sales order. The issue is that I may ship 20 units on one order to Company A, who then sells 5 to Company B and 3 to Company C.
I realized I needed to link the company name directly to the units, not the orders and have fixed that.
My issue now is simplicity in entering information in the form. My previous database involved the employee in our shipping department merely entering the sales order, selecting the customer name from a drop down menu, then scanning the serial numbers in a subform. This was to ensure simplicity and try to eliminate human error. He had only three things to input, and most of the input was done by scanning barcodes.
As it is currently structured now, the employees out in shipping would have to populate the company name for every record in the subform with the serial number and that complicates things in a way that is unacceptable. At the point of shipping, the company name will always be the same for every unit in the subform.
So.
How would I go about creating a form where the company name is entered once in the form, and automatically populates itself for every record in the subform? The caveat here is that I must also be able to go back occasionally and change the company name of individual units in an order without necessarily affecting the rest of the order. I suppose it starts out as a one-to-many relationship that then must be able to change.
I hope that makes sense.
I have looked for answers using various approaches with auto-fill and relationships and not preserving data integrity, but I feel the answer is just beyond my reach.
The only solution I can think of is to create another field in the unit table for the end-user, and perhaps write a formula that sets this default value as the company name from the order that shipped it. This seems unnecessarily complicated and redundant, there has to be a better way.
I am designing a laboratory information system (LIS) and am confused on how to design the tables for the different laboratory tests. How should I deal with a table that has an attribute with multiple values and each of the multiple values of that attribute can also have multiple values as well?
Here's some of the data in my LIS design...
HEMATOLOGY <-------- Lab group
**************************************************************
CBC <-------- Sub group 1
RBC <-------- Component
WBC
Hemoglobin
Hematocrit
MCV
MCH
MCHC
Platelet count
Hemoglobin
Hematocrit
WBC differential
Neutrophils
Lymphocytes
Monocytes
Eosinophils
Basophils
Platelet count
Reticulocyte count
ESR
Bleeding time
Clotting time
Pro-time
Peripheral smear
Malarial smear
ABO
RH typing
CLINICAL MICROSCOPY <-------- Lab Group
**************************************************************
Routine urinalysis <-------- Sub group 1
Visual Examination <-------- Sub group 2
Color <-------- Component
Turbidity
Specific Gravity
Chemical Examination
pH
protein
glucose
ketones
RBC
Hbg
bilirubin
specific gravitiy
nitrite for bacteria
urobilinogen
leukocyte esterase
Microscopic Examination
Red Blood Cells (RBCs)
White Blood Cells (WBCs)
Epithelial Cells
Microorganisms (bacteria, trichomonads, yeast)
Trichomonads
Casts
Crystals
Occult Blood
Pregnancy Test
...This hierarchy of data also gets repeated in other lab groupings in my design (e.g. Blood chemistry, Serology, etc)...
Another question is, how am I gonna deal with a component (for example, RBC) which can be a member of one or more lab groups?
I already implemented a solution to my problem by making a separate tables, 1 for lab group, 1 for sub group 1, 1 for sub group 2 and 1 for component. And then created another table to consolidate all of them by placing a foreign key of each in this table...the only trade off is that some of the rows in this table may have null values. Im not satisfied with my design, so I'm hoping someone could give me advise on how to make it right; any help would be greatly appreciated.
Here are a couple options:
If it is just the hierarchy above you are modeling, and there is no other data involved, then you can do it in two tables:
One problem with this is that you do not enforce that, for example, a sub_group must be a child of a lab_group, or that a component must be child of either a sub_group_1 or a sub_group_2, but you could enforce these requirements in your application tier instead.
The plus side of this approach is that the schema is nice and simple. Even if the entities have more data associated with them, it might still be worth modeling the hierarchy like this and have some separate tables for the entities themselves.
If you want to enforce the correct relationships at the data level, then you are going to have to split it out into separate tables. Maybe something like this:
This assumes that each sub_group_1 is only related to a single lab_group. If this is not the case then add a link table between lab_group and sub_group_1. Likewise for the sub_group_1 -> sub_group_2 relationship.
There is a single link table between component and sub_group_1 and sub_group_2. This allows a single component to be related to several sub_group_1 and sub_group_2 entities. The fact it is a single table means that a lot of the sub_group_1_id and sub_group_2_id records will be null (like you mentioned in your question). You could prevent the nulls be having two separate link tables:
sub_group_1_component with a foreign key to sub_group_1 and a foreign key to component
sub_group_2_component with a foreign key to sub_group_2 and a foreign key to component
The reason I didn't put this in the diagram is that for me, having to query two tables rather than one to get all the component -> sub_group relationships is too much of a pain. For the sake of a little denormalisation (allowing a few nulls) it is much easier to query a single table. If you find yourself allowing a lot of nulls (like a single link table for the relationships between all the entities here) then that is probably denormalising too much.
Personally, I would create 3 tables using relationships for the values. It gives you the ability to create limitless arrays of values. Just try to make sure you give great column names, or your head will spin for days. :)
Also, null values aren't a problem look into all the different type of joins
Summary:
I have a table that has a uique primary key identifying each record. I also have three more fields that can identify a record:
Category
CategoryNumber
DuplicateNumber
When I add a new record and choose the Category, how can I get CategoryNumber to increment correctly based on whether it is a duplicate or not.
Note that this is one big table. This is merely an upgrade from excel to access.
tldr:
Yesterday I asked about how to deal with multiple keys in Access. May be I did not ask the right question because my problem is even more puzzling today.
Here is what I am trying to do and where I am getting stuck.
I am creating a database to keep track of my film photos taken on a variety of different films and formats with different cameras (a total of 18 different independent pieces of information for each photo) that span back almost 15 years. Years ago I kept the data in MS Excel and programed the input form to do what I am about to explain.
I wanted to keep track of the photos in two ways. The first was a master photo number that would let me know how many total photos I had in my files. It was a sequentail number that I never intended to ever delete something in that sequence. It would be a number that would uniquely identify each photo. I see this as my primary key for the whole database.
But I also wanted to file the slides, negatives, and transparencies according to general groups or categories so that I could quickly pull them if I needed to make a photo submission or I was looking for something specific. So I also added a category identifer (e.g. Landscapes had a 'LS' name attached as well or Sunsets as 'SS' etc). I also wanted to keep a running sequential number for each slide that was in each category. So e.g. one of my first photos in my data base has PhotoID = 3, its Category = LS and its CategoryID = 1. Further down I have PhotoID = 14, Category = LS and CategoryID = 2.
Now in addition to these, I further have another number that I need to keep track of and that was if I made duplicate exposures of the same scene. To work this I just added a DuplicateNumber to each photo. If it had no duplicates then DuplicatNumber was 0, if it had one dupe than DuplicateNumber was 1, 2 dupes, DuplicateNumber was 2 etc.
So I had two ways for finding any photo in my files. Either by the PhotoID which was sequential in the Database but not in my physical files, or by the combination of Category, CategoryID and DuplicateNumber, which are how I physically file the photos.
Now in Excel what I did was when I opened my form, I first had to choose what category to put the photo in via radio buttons on the form. I would then fill in all the pertinent data for the photo. When I executed the form, it would find the last number in the master sheet, increment it and add all the data to a new record. It would then activate the category sheet for the category I chose, determine the last number in that sheet, increment it and add in the new data there as well.
An important note is that DuplicateNumber is always 0 by defalut unless I made it 1, 2 etc. It was never computed, but I entered it.
When I created slide lables (the "report") I would include the main PhotoID, The CategoryName, CategoryID and DuplicateNumber in this format (1LS1.0, 14LS45.0, 15LS45.1) and in addtion the location and Date taken.
But now I don't want to use Excel anymore and have tried to migrate the database to MS Access. So I have one main table called PhotoDetails.
PhotoID is the primary key in this table. It has a PhotoCategory field that is a number that has a relation to another table called Category. Its Primary key is PhotoCategoryID and it is also a foreign key in PhotoDetails. PhotoCategoryID is a number that identifies each category. In the list of all my categories, LS is number 11. But here is where I get stuck.
I have CategoryNumber, which is the number identifying the photo in each category, and DuplicateNumber, identifying the number of duplicates, in the PhotoDetal table. What I can't figure out is when I add a new photo, how do I increment the CategoryNumber? The form I have right now allows me to enter in all the data, and when I click to enter the next it will autonubmer the PhotoID key, but what about CategoryNumber? I can't remember what the last number is for each Category so as for me to enter that number in myself. Unless I mimic what I did in Excel by having all the data stored twice, once in the PhotoDetails (aka Master Sheet in Excel) and again in multiple Category tables. I was hoping Access could provide me a workaround.
Currently the relationships I have are the Category table linked to PhotoDetails in a 1-M relation. I also have several other tables all linked in a 1-M relation (e.g. table Film stores the different films I have used and the 1-M relation lets me link what film to each slide, and most of the other data is stored in that way).
I have 31 different Categories. Each photo has a Category and a CategoryID number, as well as a Duplicate number. I will choose the Category on data entry and the DuplicateNumber, but I want the CategoryID number as well as PhotoID to be incremented automatically for me. What is the correct way to proceed with this where I only have to keep one PhotoDetail table that is not duplicated for each category as I did in Excel.
OK, so basically what you are looking to do is "normalize" your data
Typically you would have two tables
Photo
PhotoID (Data Type: Autonumber - not normally seen by the user - Primary Key)
PhotoRefID (DT: probably a Number or Text - referencing the physical number)
CategoryID (DT: Number - a Long Integer - key to the Category table)
Duplicate (DT: Number - probably long also - if this is just a count)
-- or --
DuplicateOf (DT: Number - Long Integer - to reference what it is a duplicate of)
Category
CategoryID (DT: AutoNumber - Primary Key)
Description (DT: Text)
You will use relationships (Tools->Relationships) to like the two Category IDs together.
You can then be able to use the tables to build the forms and queries that you are looking for.
Note: If you can have photos that fit into more than one category, then you will need a third intermediate table to join them up. Something like:
PhotoCategories
PhotoCategoryID (DT: Autonumber, Primary Key)
PhotoID (DT: Number Long Integer)
CategoryID (DT: Number Long Integer)
I'd look at doing it cheaply by adding code so that when you try to add a new record it does a search in the database for the highest number with the category/duplicate/etc and then you can increment it in code before you add the new record.
There's no easy way to get this functionality automatically in Access, unless you break your table out into more tables.
-Adam