I create a data model that would replace two cut down tables. With these two table I placed a Many to One relationships.
When I create reports that just uses a single table (This is the Destination table, within Data source views relationship) its missing records that should be displayed. The records that do not display are records that do no have a linked record in the other table.
Help
You probably need to create a query or a view that includes an outer join. Search your docs for OUTER JOIN. That should take you where you need to be. Topics should include LEFT, RIGHT, and FULL outer joins.
Related
I want to define the relationship between a table I am joining, and the table I am joining it too.
The table I am joining on is a synonym of another database's table. I am doing it this way because the other database is a data warehouse of some sort, while the database that its the synonym for is more detailed data that I can access with id's and such off of the synonym.
However, in metabase, the synonym just doesn't show up. I can query off of them but I cannot configure them in the admin menu.
I am current trying it like so:
FROM dwBdgtAdmnstrtn AS relation
LEFT JOIN rdLctn ON rdLctn.id = relation.lctn
LEFT JOIN crmRltnGrp ON crmRltnGrp.id = relation.rltnGrp
relation is the synonym I am joining on to, and location and relationgroup are the 2 tables I want to define relationship to the synonym with so that I can use linked filters.
The query is functioning correctly, but without a relationship closely defined the linked filters don't work.
I'm new to Pentaho.
This is the transformation I'm trying to do:
Import Transactions and Merchant and merge these two tables using MERCH_KEY
However, this isn't working, see below:
This is table Transactions:
And this is table Merchant:
And this is the Merge join:
This all seems good, but it's not working and I have no idea why.
From the preview, I can see the two tables are being imported, so how can I merge them?
Remove all fields except "MERCH_KEY" from the right-side list.
The Merge join step is a little misleading with its behavior, as it only allows you to click Get Fields and get ALL fields, but doesn't let you pick a single field in a dropdown.
As the name suggest, these are the key fields that will be compared in the join, so fields need to be in the correct order. In your case, you only need the one. The other input fields (from both tables) will be automatically added to the output stream, with fields from the second table getting renamed if duplicated.
I'm using SQL Server 2012. I want to join two tables without columns that I can join them, how can I find all the tables to reach to this two tables?
For example: I need to join the Table A to table D and to do that I need to connect A to B and then to C and at the end to D.
My question is: can I find the tables B and C among thousands of tables in the database without searching table by table?
Thanks a lot,
Ohad
Assuming that:
You want to automate this process
You have FOREIGN KEY constraints that you can rely on
You should proceed as follows:
Query sys.foreign_keys and create a directed graph structure that will contain the links between tables.
Then implement a graph search algorithm that will start from table A and try to find a path to table D and from D to A.
Once you have found the path, it will be easy to construct dynamic SQL containing the join of all tables on the path. You will need to query sys.foreign_key_columns as well to be able to construct the ON clauses of the JOIN's.
Let me know if you need help with more detail.
There's a couple of things you can do to help your cause, but for the most part, there's no direct way and you would need to know how your database is structured and the purposes of the tables. Furthermore, based on the database's design, it might be very difficult for you to intuitively find your answer and you might need just need to get guidance from someone who is knowledgeable with the database design. Regardless:
Fields in your tables A & D:
you can look at primary fields or unique fields in the tables to determine what other tables may link to those table. Usually they are named in a way that match those other tables and you can tell what table they're coming from.
Information_Schema Views
You can use information_schema.tables and information_schema.column views to easily search for names of tables and columns across the entire database and narrow your search to less tables.
When I create a view I can base it on multiple columns from different tables.
When I want to create a lookup table I need information from one table, for example the foreign key of an order table, to get customer details from another table. I can create a view having parameters to make sure it will get all data that I need. I could also - from what I have been reading - make a lookup table. What is the difference in this case and when should I choose for a lookup table?? I hope this ain't a bad question, I'm not very into db's yet ;).
Creating a view gives you a "live" representation of the data as it is at the time of querying. This comes at the cost of higher load on the server, because it has to determine the values for every query.
This can be expensive, depending on table sizes, database implementations and the complexity of the view definition.
A lookup table on the other hand is usually filled "manually", i. e. not every query against it will cause an expensive operation to fetch values from multiple tables. Instead your program has to take care of updating the lookup table should the underlying data change.
Usually lookup tables lend themselves to things that change seldomly, but are read often. Views on the other hand - while more expensive to execute - are more current.
I think your usage of "Lookup Table" is slightly awry. In normal parlance a lookup table is a code or reference data table. It might consist of a CODE and a DESCRIPTION or a code expansion. The purpose of such tables is to provide a lsit of permitted values for restricted columns, things like CUSTOMER_TYPE or PRIORITY_CODE. This category of table is often referred to as "standing data" because it changes very rarely if at all. The value of defining this data in Lookup tables is that they can be used in foreign keys and to populate Dropdowns and Lists Of Values.
What you are describing is a slightly different scenario:
I need information from one table, for
example the foreign key of an order
table, to get customer details from
another table
Both these tables are application data tables. Customer and Order records are dynamic. Now it is obviously valid to retrieve additional data from the Customer table to display along side the Order data, and in that sense Customer is a "lookup table". More pertinently it is the parent table of Order, because it has the primary key referenced by the foreign key on Order.
By all means build a view to capture the joining logic between Order and Customer. Such views can be quite helpful when building an application that uses the same joined tables in several places.
Here's an example of a lookup table. We have a system that tracks Jurors, one of the tables is JurorStatus. This table contains all the valid StatusCodes for Jurors:
Code: Value
WS : Will Serve
PP : Postponed
EM : Excuse Military
IF : Ineligible Felon
This is a lookup table for the valid codes.
A view is like a query.
Read this tutorial and you may find helpful info when a lookup table is needed:
SQL: Creating a Lookup Table
Just learn to write sql queries to get exactly what you need. No need to create a view! Views are not good to use in many instances, especially if you start to base them on other views, when they will kill performance. Do not use views just as a shorthand for query writing.
I have a table that contains a few columns and then 2 final (nullable) columns which are varbinary (actually, they are SQL 2008 geography types, but I want to keep this post database agnostic).
I've hit around 500mb with around 200K rows. The varbinary is the problem - and I need the data.
So, I was wondering if it's bad if I do the following:-
Create a separate FILEGROUP: SpatialData.mdf
Create a new table, assigned to that new filegroup.
Move all the spatial data (read: last two fields) out of the original table and into the new table. The new table has a foreign key against the original table.
Create a view representing both tables.
Now, the view will be a left outer join because the relationship is: the new table has a zero or one row relationship to the original table.
EG.
Original Table
FooId INT PK NOT NULL IDENTITY
Blah VARCHAR(..) NOT NULL
Boo WHATEVER NOT NULL
New Table
FooID PK FK NOT NULL
Spatial_A VARBINARY(MAX)/GEOGRAPHY
Spatial_B VARBINARY(MAX)/GEOGRAPHY
The reason why I want to know if this is bad is because of the view and how the view is doing a join on the spatial table. I'll be using the view a lot. Currently, I'm just doing queries against the original table (because the new table doesn't exist just yet). By adding this join and the PK/FK relationship, will this impact performance?
Why split the data? I need to download the live DB to our dev servers now and then. We don't really care too much about those two spatial fields, so not having them is fine. Therefor, the size of the database to download will be much smaller.
Thoughts?
Instead of creating a second table, joining, and creating a view, a better solution that is possible with SQL Server 2005/2008 is to use table partitioning. To my recollection, you can vertically partition a table, and place some columns (i.e. your geospatial columns) in one file group, while putting the rest in another file group. SQL Server will handle the rest for you, you don't need to bother with a join, and you don't need a view.
The method that you've described is actually fairly common in my experience. Technically, if you were to normalize your database to the fullest extent you would have a lot of tables like that since one of the (usually not used) steps in normalization includes making sure that no columns have NULL values.
In practice it isn't usually carried out to that extent, but for a column (or columns) that is sparsely populated it's not a bad idea to separate it out. As long as the tables share the same primary key (which will of course be indexed), performance shouldn't be a problem.