Issue joining Jira Sprints and BoardCharts tables in Tableau - jira

Using the Tableau Connector Jira plugin, I am attempting to join the Sprints and BoardCharts tables in Tableau.
I have created a Data Source in Jira with the Sprints table:
...and the Board Charts table:
But when I come to create the relationship in the Tableau data connection:
...it complains of type mismatch between the two Sprint Id fields:
Casting or converting one or the other value in the relationship will slow things down too much. What am I missing? Why are they different data types?

Related

PowerBI - Join DirectQuery and Imported tables in DAX

I have a DirectQuery table (Weather) which is sourced from an Azure SQL server. I would like to join this with an Imported table (Buckles) from an Excel sheet sourced from SharePoint Online.
Both tables have a UID field that is made up of a concatenation between a SiteID and timestamp. The UID field is named differently for each table.
I have created a One-To-Many relationship between the two tables.
I have tried to create a new DAX table using a NATURALINNERJOIN on Weather and Buckles but I get this error:
"No common join columns detected. The join function 'NATURALINNERJOIN' requires at-least one common join column."
I am confident it is not a problem with the underlying data because I've created a new imported Excel table (Test) with a selection of the data from Weather and I'm able to successfully create the join on Test and Buckles.
Is the joining of DirectQuery and Imported tables supported? I feel like this may be a type casting issue, but as far as I can see, both UID fields are set as Text.
The UID field is named differently for each table.
I suspect this may be the issue. NATURALINNERJOIN looks for matching column names
and if the two tables have no common column names, an error is returned.
Note that if you create a calculated DAX table using a DirectQuery source, I don't think that table will still act like DirectQuery. If I understand correctly, it will materialize the calculated table into your model and DAX that references that calculated table no longer points back to the SQL server (and consequently will only update when the calculated table gets rebuilt).

OData $expand with different DB context

I have requirement like I need to expand the table of different database.
For example we have two model product and department. Both are in different database.
product table is in database1 and department table is in database2.
How can I expand database2..department under database1..product with odata $expand.
I am using C#,.netcore and EFCore. Please help me how can I do it with odata?

Is a table (from source system) that contains only relationships and current status of a row from another table a fact table in Data Warehouse?

I am developing a BI system for our company, from scratch, and currently, I am designing a data warehouse. I am completely new to this so there are many things that I don't really understand, so I need to hear some more insights into this.
My problems are:
1) In our source system, there are tables called "Booking" and "BookingAccess". Booking table holds the data of a booking, such as check-in time and check-out time, booking date, booking number, gross amount of that booking.
Whereas in BookingAccess, it holds foreign keys related to the booking, such as bookerID, customerID, processID, hotelID, paymentproviderID and a current status of that booking. Booking and BookingAccess has a 1:1 relation ship.
Our source system is about checking the validity of those bookings, these bookings are not ours. We receive these booking information from other sources, outsource the above process for them. The gross amount is just an information of that booking that we need to validate, their are not parts of our business. The current status of a booking which is hold in the BookingAccess table is the current status of that booking in our system, which can be "Processing" or "Finshed".
From what I read from Ralph Kimball, in this situation, the "Booking" is the Dimension table, and the BookingAccess should be the fact. I feel that the BookingAccess is some what a [Accumulating Snapshot table], in which I should track the time when a booking is "Processing", and when a booking is "Finshed".
Do I get it right?
2) In "Booking" table, there is also a foreign key called "ImportID". This key links to a table called "Import". This "Import" table hold history records of files (these file contain bookings which will be written to the "Booking" table) which were imported to our system, including attributes such as file name, imported date, total booking imported...
From my point of view, this is clearly a fact table.
But the problem is that, the "Import" table and the "Booking" table has a relationship of one to many (1 ImportID in "Import" table can have 1, 2 or more records which have a same ImportID in "Booking" table). This is against the idea of fact tables which insists that the relationship between Fact and Dimension must be many-to-one, which fact is always in the many side.
So what approach should I use to solve this case? I'm thinking of using bridge tables to solve this problem. But I don't know if this is a good practice, as there are a lot of record in the "Import" table, so I will have to create a big bridge table just to covers all of this.
3) Should I separate a table (from source system) which contains a mix of relationships and information to a fact table containing only relationships, and dimension table containing only information? (For example, a table called "Customer" in source system. This table contains some things like customer name, customer address and customertype id, customer parentID....)
I am asking this because I feel that if I use BI tools to analyze things (for example, analyzing the number of customers which has customertypeid = 1), I feel it's some what weird if there are no fact tables involved in.
Or should I treat it as a mere dimension table and use snowflake-schema? But this will lead to a mix of Star-Schema and snowflake-schema in our Data Warehouse. Is this normal? I have read some official sources (most likely Oracle) stating that one should try to avoid using and mixing snowflake-schema as much as possible. But some sources like Microsoft say that this is very normal. Even the Advanture Work Data Warehouse sample database uses this kind of approach.
Or should I de-normalize every relation in that "Customer" table? But I don't think this is a good approach as it will make the Customer contain a lot of columns, and it will be very hard to track the history of every row in the "DIM_Customer" table. For example, if any change occur in any relation of "Customer" table, the whole "DIM_Customer" table will need to be updated.
I still have a lot of question regarding to Data Warehouse. I am working with it nearly alone, without any help or consultant. So pardon me if I made any kind of inconveniences or mistakes.

Create relationship between two query delphi

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.

ActiveRecord Associations should i be using 3 join tables?

i currently have 3 tables and 3 join tables
Users
Projects
Materials
a User has many Projects and Materials
a Project has many Users and Materials
a Material has many Projects and Users
each of them have their respective join tables to one another
say a Material has a column "name" and "amount". How can i form the associations so that for the same instance of materials, it has a different amount for a Project and a User?
I am currently storing "amount" in their join tables so a UserMaterial and a ProjectMaterial has different "amounts". The issue with that is when i query the materials from a User, I would have to make 2 separate queries. One to get an array of the Material names from the Materials table,
user.materials
and another to get an array of the amounts from the UserMaterial.
user.usermaterials
Is there an issue/improvement with my associations? or is there a query method to combine those 2 arrays, attaching the correct name and amount to the correct id?
Any assistance is appreciated. Thank you
If you query on user.materials, that will have to join through user_materials. If you use includes, it can get both in one query.
user_materials = #user.user_materials.includes(:material)
Then, when you loop through, the user_material.material association will already be loaded and ready for you.
user_materials.each do |um|
name = um.material.name # material is already loaded
end

Resources