I am creating a tabular and parameterised report, which should get data from two different data sets.
This report gives learner description by faculty, grouped further by gender, ethnicity and disability.
I have got group summary for faculty and gender
e.g.:
faculty gender learner
BIT 856
second one should be like:
faculty gender ethnicity dis ability learner
bit M 400
bit F 456
the problem I have is I'm using different dataset for summary and I have no problems while summarising it by faculty but the problem is while summarising it by gender.
As there are multiple enrolments in each faculty I'm facing problem including subtotal on the basis of gender (I am looking for unique)
as the summary fields are from dataset 2, it only allows me to include them in aggregate fields.
I have learned when working with Reporting Services that only very basic queries should be handled directly from Reporting Services. If the query is just mildly difficult it is much easier to generate the data from a stored procedure that just returns the output based on the parameters you parse. Another thing is to construct a cube in Analysis Services, however, that is a totally different thing :-)
HTH,
Christian
Related
I am currently studying databases, and I have a question.
The professor told us to create 2 different databases, and then move all the data to a star schema data model.
Here is the diagram for the first database, I have already filled the tables with data.
This is the diagram for the second database, also with data
This is my star schema model
The problem I am facing is i that i do not know how to start doing the mapping when adding my origin OLE DB and destination OLE DB.
I have already searched through the web, but I only find examples where they have to move just one database to the star schema data model.
The task you have is to consolidate two transactional/OLTP systems into a data warehouse. The reason you find only examples of moving/mapping one system into a data warehouse is that you simply repeat the process for each additional source that feeds into the DW.
In your example, you are integrating two sales systems to produce a unified sales business process report.
My approach would be to copy all the tables as is into your DW and put them into a staging schema (stage_d1, stage_d2). This way, you have all the data locally and it's likely consistent with the start of your data extract i.e. as of 9:30 this morning.
Now that you have the data locally, you need to transform and enrich the data to populate your dimensions and then your fact table.
Let's analyze Dim_Customer. This table is probably a little light in terms of providing value but the methodology is what you should focus on. System 1 supplies a first and last name and a city, state and zipcode. System 2 gives us a Company name, contact name, city, state, postal code and phone.
Given the usage of postal code and zip code, that would have me wondering whether we're dealing with international addresses versus a US centric (zip code) data. I'd also notice that we don't have an actual address line for this data so the point is, analyse your data so you know that you're modeling something that solves the problem (report on sales across all systems).
The next question I'd wonder about is how we populate the Customer dimension. If a Mario Almaguer had a purchase in both system 1 and system 2, are they the "same" person? Does it matter for this business process? If we sold to a person in TX and that name also exists in ME, does it matter if the name is in there twice?
I'll assume we only care about unique customer names. If it's a bad assumption, we go back and model it differently.
In my source, I'll write a query.
SELECT DISTINCT CONCAT(C.FirstName, ' ', C.LastName) AS CustomerName FROM stage_d1.Customer AS C;
Run that, see that it returns the data I want. I'll then use an OLE DB Source in an SSIS data flow and use the third drop down option of Source query.
If I run the package, we'll get all the unique customer names from the source system. But we only want the names we don't have so that means we need to use something to check our reference table for existing matches. That's the Lookup Component
The source for the Lookup will be the DW's Dim_Customer table. You'll match based on CustomerName. The lookup component will tell us whether an incoming row matched and we can get two output streams: Match and no-match. We're only interested in the no-match path because that's new data. Andy Leonard has an excellent Stairway to Integration Services and in particular, we're talking about an Incremental Load.
From the Lookup, we'll drag the no-match branch to an OLE DB Destination where we point at Dim_Customer table.
You run that and Dim_Customer is populated. Run it again, and no new rows should be added as we're looking for new data only.
Now we need to solve getting the second staged customer data integrated. Fortunately, it's the same steps except this time our query is easier.
SELECT DISTINCT C.ContactName AS CustomerName FROM stage_d2.Customers AS C;
Lather, rinse repeat for all of your other dimensions.
You could also skipped the data flows and simply executed a query to do the same.
INSERT INTO dbo.Dim_Customer(CustomerName)
SELECT DISTINCT CONCAT(C.FirstName, ' ', C.LastName) AS CustomerName
FROM stage_d1.Customer AS C
WHERE NOT EXISTS (SELECT * FROM dbo.Dim_Customer AS DC WHERE DC.CustomerName = CONCAT(C.FirstName, ' ', C.LastName));
Lather, rinse, repeat for the remaining dimensions.
Loading the fact is similar except we will use the Lookup components to find matches (as we need to translate our data to their dimension ids). Here I'll show how we'd populate a simplified version of your fact table
SELECT O.Price AS UnitPrice, BO.OrderDate AS [Date], 1 AS Quantity, 0 AS Discount, CONCAT(C.FirstName, ' ', C.LastName) AS CustomerName
FROM stage_d1.Ordering as O
INNER JOIN stage_d1.Book_Order AS BO
ON BO.OrderID = O.OrderID
INNER JOIN stage_d1.Customer AS C
ON C.CustomerID = BO.Cus_CustomerID;
That's my source query. The customer lookup will continue to match on Dim_Customer's CustomerName but this time we'll retrieve the CustomerID from the lookup component.
The destination then uses the UnitPrice, Date (depends on how you do it), Quantity and Discount directly from our source. The rest of the dimension keys, we populate through our lookup.
the standard approach would be to do the following:
Copy your source data into staging tables in your target database
Write the queries, necessary to populate the star schema, against the staging tables
You populate all your dimension tables first and then all your fact tables.
I am new to SSAS trying and need help designing this reporting requirements:
Filter for Customers based on dimensions (regular and fact) in various tables related by many-to-many relationships
With this list of Customers, retrieve their contact details (address, email, etc)
My plan is to use SSAS (multidimensional) with either Excel 2007/SSRS reports for the user front end. My queries are:
Should the customer contact details be a dimension or fact? (One
customer has only one contact detail and presently resides in the
same table)
Once the customers have been filtered, how then to generate the
customer’s contact details from the filter results?
Will my choice of tools work for my requirements?
Many thanks in advance.
Best regards,
CT
Contact details, such as address should be dimension attributes, not facts
If you have properties that you do not need to slice by, but you want to report on them, you can ustilies Member Properties as described Defining Member Properties for an Attribute in SSAS 2008
. For your solution, maybe a Drill Through action Defining and Using a Drillthrough Action
gooing to a SSRS report would be more suitable
If you are going to tie your original statement up with your comments and utilise Total Sales, Purchased Products etc then the solution starts to make sense and should give you what you want. Without the metric part, SSAS is an overkill and straight table queries would suffice
From your description, you do not have a many-to-many relationship, however if you end up with them take a look at http://www.sqlbi.com/articles/many2many#2
I recently ran into a problem in our SQL Server 2008 Analysis Services Cube. Imagine you have a simple sales data warehouse with orders and products. Each order can be associated with several products, and each product can be contained in several orders. So the data warehouse consists out of at least 3 tables: One for the Products, one for the Orders and one for the reference table, modelling the n:n relationship between both.
The question I want our cube to answer is: How many orders are there which contain both product x and product y?
In SQL, this is easy:
select orderid from dbo.OrderRefProduct
where ProductID = 1
intersect
select orderid from dbo.OrderRefProduct
where ProductID = 3
Since I am fairly proficient in SQL, but a newbie in MDX, I have been unable to implement that in MDX. I have tried using distinct count measures, the MDX-functions intersect and nonempty and subcubes. I also tried duplicating the dimensions logically (by adding the dimension to the cube twice) as well as physically (by duplicating the data source table and the dimension).
On http://www.zeitz.net/thts/intersection.zip, you can download a zip file of 25kB size which contains an SQL script with some test data and the Analysis Services Solution using the tables.
We are using SQL Server 2008 R2 and its Analysis Services counterpart. Performance considerations are not that important, as the data volume is rather low (millions of rows) compared to the other measure groups included in that cube (billions of rows).
The ultimate goal would be to be able to use the desired functionality in standard OLAP (custom calculated measures are ok), since Excel is our primary frontend, and our customers would like to choose their Products from the dimension list and get the correct result in the cube measures. But even a working standalone MDX-Query would greatly help.
Thank you!
Edit March 12th
Did I miss something or can't this be solved somehow?
If it helps to build the mdx, here is another way to get the results in sql, using subquerys. It can be further nested.
select distinct b.orderid from
(
select distinct orderid from dbo.OrderRefProduct
where ProductID = 1
) a
join dbo.OrderRefProduct b on (a.orderid = b.orderid)
where ProductID = 3
I tried something like this with subcubes in mdx, but didn't manage to succeed.
I've had a go - you can download my solution from here:
http://sdrv.ms/YWtMod
I've added a copy of your Fact table as a "Cross Reference", Aliased the Product1 dimension as a "Cross Reference", set the Dimension references to Product independently from your existing relationships, and specified the Many-to-Many relationships.
It is returning the right answer in Excel (sample attached).
You could extend that pattern as many times as you need.
Good luck!
Mike
an other way to deal with this in SQL (I know it works, but I didn't test this query) is to use double negation
select distinct orderid
from X
where TK NOT in (
select TK
from X x_alias
where productid NOT in (id1,id2)
)
I'm pretty sure you can do the same in MDX.
My question is more of trying to understand what and how I can get something done. Here's the thing:
I got a job to build this application for a school to manage student bio data, work-out and handle student information and basic finance management.
Based on requirements I got from meets with my client, I have an ERD of a proposed MySQL Database with 23 different tables. The one part I would like to understand quickly is displaying data based on school terms. There are 3 terms in a year, each with its own summaries at the end of each term. At the end of 3 terms, a year has gone by and a student is promoted or demoted.
So my question is, how can I render my data to show 3 different terms and also to create a new year working out how to either promote a student or make the student repeat the class its in?
23 different tables? I'd like to see that model.
I don't think you should have one table per term. You'll have to keep adding tables every term, every year.
Sounds like a transcript table should have term and year columns that are incremented or decremented as a student progresses through. It should also have a foreign key relationship with its student: it's a 1:1 between a student and their transcript.
I would have a separate transcript table because I'd prefer keeping it separate from basic personal information about a student. A transcript would refer to the courses taken each term, the grade received for each, and calculate overall progress. If I queried for the transcript for an individual student, I should be able to see every year, every term, every course, every grade in reverse chronological order.
I'm having an issue with a certain requirement to one of my Homework Assignments. I am required to take a list of students and print out all of the students with credit hours of 12 or more. The Credit hours are stored in a separate table, and referenced through a third table
basically, a students table, a classes table with hours, and an enrolled table matching student id to Course id
I used a SUM aggregate grouped by First name from the tables and that all works great, but I don't quite understand how to filter out the people with less than 12 hours, since the SQL doesn't know how many hours each person is taking until it's done with the query.
my string looks like this
'SELECT Students.Fname, SUM(Classes.Crhrs) AS Credits
FROM Students, Classes, Enrolled
WHERE Students.ID = Enrolled.StudentID AND Classes.ID = Enrolled.CourseID
GROUP BY Students.Fname;'
It works fine and shows the grid in the Delphi Project, but I don't know where to go from here to filter the results, since each query run deletes the previous.
Since it's a homework exercise, I'm going to give a very short answer: look up the documentation for HAVING.
Beside getting the desired result directly from SQL as Martijn suggested, Delphi datasets have ways to filter data on the "client side" also. Check the Filter property and the OnFilter record.
Anyway, remember it is usually better to apply the best "filter" on the database side using the proper SQL, and then use client side "filters" only to allow for different views on an already obtained data set, without re-querying the same data, thus saving some database resources and bandwidth (as long as the data on the server didn't change meanwhile...)