In SSRS I am trying to create a table or matrix using two datasets that have a one-to-many relationship. The table/matrix needs to be tied to the one relationship and join to the many.
I initially tried to do a lookup function, but that is a one-to-one relationship and just returned one value. I'm looking to return all values and each one on a separate row. Here is an example of two datasets, I want to join on the CustomerID column and return the CountriesOfBusiness column. Is there a different function in SSRS that will do this?
Try this expression in table/matrix: (set Dataset name to be: DataSet1)
=Join(LookupSet(Fields!CustomerID.Value, Fields!CustomerID.Value, Fields!Countries.Value, "DataSet2"), VbCrlf)
Related
I have two table Country and City (country_id is PK in Country table and country_id is FK in City table).
Which component use to create relation between two query for fast report.
Which structure should be:
Query 2. Client Data set .... 3. ? 4.?
This is usually called a Master-Detail relationship between the datasets involved.
In Delphi, you set one up by connecting the Detail dataset to a TDataSource whose dataset is the connected to the Master dataset. You can do this on the server side (i.e between the two queries, using the DataSource property of the Detail or between two clientdatasets using the MasterSource property of the.Detail. When doing it on the server side, you write the SQL for the query as a parameterised query, with the parameter being one whose value matches the Master's PK as in
Select * from mydetailtable where masterid = :masterid
Once a Master-Detail relationship has been set up between two datasets, it should work with virtually any report generator, FastReports included.
See e.g. http://docwiki.embarcadero.com/RADStudio/Rio/en/Setting_Up_Master-Detail_Linked_Relationships which talks about this in terms of DBExpress components, but the principle is applicable to other Delphi dataset components.
In my incomplete view of BI tables, a Fact table represents action and a dimension an entity.
I have a FactOrder table that contains order information (including OrderId and CustomerId). There is a separate dimension for people who are actually connected to the order but are not customers. So they are saved in a separate table called DimServiceUser. A linking table connects an Order to a ServiceUser. Should this intermediate OrderServeruser table be defined as a Dimension, a Fact or another type?
It really is more of a bridge table. Here's what is going on.
Your FactOrder table is a fact table, but it also contains a degenerate dimension. A degenerate dimension acts as a dimension key in the fact table, however does not join to a corresponding dimension table because all its interesting attributes have already been placed in other analytic dimensions. So you have an implied DimOrder in there that didn't require a separate table.
A bridge table can connect a set of values to a single fact table row, or it can connect two dimensions (such as customers and bank accounts). It is a way of handling legitimate many-to-many relationships. A bridge table is like a factless fact table. But in dimensional modeling we do not join fact tables together, whereas it is acceptable to join bridge tables and fact tables together. If you must force your bridge table into being a fact or dimension, it is closer to a fact table. But doing so may make it easier to implement bad modeling habits in the future. If you can call it a bridge instead, I would just go with that. (Make sure you read that third link on "like a factless fact table". It was written by the author of Star Schema: The Complete Reference. That is a pretty well accepted source.)
As OrderService does not contain any facts/measurements therefore you cannot call it a fact table.
Dimension table:
A dimension table contains dimensions of a fact.
They are joined to fact table via a foreign key.
Dimension tables are de-normalized tables.
The Dimension Attributes are the various columns in a dimension table
Dimensions offers descriptive characteristics of the facts with the help of their attributes
No set limit set for given for number of dimensions
The dimension can also contain one or more hierarchical relationships
Based on the above definition of dimension table, I believe you table should be referred as dimension table.
OrderServeruser table should be prefix with "bridge".
I am new to Neo4j and I am trying to convert a relational model to a graph model. In this model, I have two labels X and Y which there is a relationship between them. This relationship has property P. The problem is that this P should get its values from an external table (list of possible values for P). How should I relate this property values to be obtained from this external table.
I can't say I'm completely following, but at the most basic level, if you already have x and y nodes modeled and populated (with unique constraints on the primary keys), and if you have a join table with x and y primary keys and a value that should be on the relationship, then it's a matter of reading in the import file of the join table, matching to the corresponding x and y nodes via the primary keys, then merging the appropriate relationship between them, adding any additional properties on the relationship as needed.
However, it's always a good idea to check if this is the best way to model what you want in a graph db. So far you've only been describing tables and how they relate, but getting a better description of the big picture of what this data represents and logically how it relates to each other might provide insights for modeling the data in a way that makes more sense for a graph db. Could you provide in your description a more verbal description of what exactly you're trying to model, how it relates to each other, and the kind of questions you want to ask of your data?
In order to join one of my tables to other tables, I had to use Calculated Fields to make the field format same as others. However, when I want to join the tables, the new field name created by Calculated Fields does not appear.
I know that I can export modified data, and import it again to solve the problem, but I'm interested to know if there is a simpler way to do so in Tableau.
Unfortunately you can not join in the data model using calculated field. If your data is not too large, you can make the join in Tableau by using data blending. Alternatively, create a view or views with the calculated field in the source SQL database.
I need a little help with ClientDatasets in Delphi.
What I want to achieve is a grid showing customers, where one of the columns shows the number of orders for each customer.
I put a ClientDataset on a form and load Customers.xml from Delphi demo-data.
Another ClienDataset is loaded with orders.xml.
Relatively simple, I can define an aggregate on the orders CDS showing the total amount per customer (or the count). (See Cary Jensens article on this: http://edn.embarcadero.com/article/29272)
The problem is getting this aggregate result from orders dataset into the customer dataset.
It is kind of an reverse lookup, since there is a 1-n relationship between customers and orders, not an n-1 as normally in lookup scenarios.
Any ideas ?
Søren
Maybe you could define a calculated field in the customers dataset which would simply take the value of the aggregated field in the orders dataset.
Have you tried to do a Master (Customers) - Detail (Orders) relation?
It's not a lookup situation.