I'm working on a scenario where I have a bridge fact table joining two dimensions, but the bridge table also has data that I would like to be able to use as an attribute in my query. I believe essentially what needs to happen is for the bridge table to act as both a fact table (for the many-to-many join) and a dimension (to allow the attribute to be used in the query). The situation is set up like this:
Cube Setup
Using the fields in the many to many join, the results are what I would expect when looking at the total transaction amount by expertise. When I add in the field from the bridge table, however, it does not appear to be linked in any way to the other fields and results in all possible combinations:
Results
My guess is that there should be some kind of relationship established between the bridge table and the fact table, but I'm not sure how or what that relationship should be. Any help would be appreciated. Thanks!
As noted above, I needed to set the relationship between my bridge and the fact table as a 'many to many' relationship using the bridge as the link. Making the connection that way allows me to query based on the bridge table field and the results are as expected.
Related
I am learning MS Access and am looking at the Northwind DB. There I find in the relationships an arrow at the "one-end" of some one-to-many relationships and I wonder what that means or what consequences it has. I could not find anything about it asking google (maybe used the wrong search term??)
screenshot of one-to-many relationship
I tried to replicate the relationship but did not succeed.
Besides the usual (compared to other databases) attributes related to relationships between tables and referential integrity, in Access you can also specify a Join Type. This does not affect the relationship between the tables as such but will have an influence on the query designer. When you add the tables to the query designer, this will automatically either create an INNER JOIN (with no arrow) where only matching records on both sides will be returned or an OUTER JOIN where all records of one table will be returned but only matching records of the other table (returning the corresponding columns as NULL). The arrow points to the table which might have missing records.
But you can change the join type afterwards in the query designer. So, the informational value of this arrow is very limited.
I'm no MySQL expert and I have to design a rather complex db for my level.
The problem I'm facing now consist in having a supplier-customer relationship within the same table (macro categories of companies):
Macro table
id name mega_id macro_customer_id
------------------------------------------
1 Furniture 2 2,4,5,35
I want to represent the fact that macro entry with id 1 has other macro companies (which are their customers) described within the same table.
Which is the best way to represent this?
Thanks!
It depends: We all used to use the normalization forms (as #1000111 indicated), however depending on the use of the data, you can choose to look different at certain parts of this normalization discussion:
The normal model for this would be:
Table userData(id,name)
- 1:N table linkTable(id,macro_customer_id)
- N:1 table metaData(macro_customer_id,value)
Or:
Table userData(id,name)
- 1:N table linkTable(macro_customer_id,id)
The big question is however in how the data is used. If data is just for this user and not queried in any other way (no where, or group by), then storing it as a serialized String is a completely valid approach.
The relationship between entities in an RDBMS should be stored in a relational way. Ask yourself if you care about this relationship in your database - will you need to write queries that will link macro.id to table/rows represented by IDs in macro.macro_customer_id? If yes, then you must store this relationship in a (one-to-many or many-to-many) separate table.
Is it possible to do a many-to-many relation without a bridge table in SSAS ?
I have one fact table with SubjectId and another fact table with FK_SubjectId and many others keys (related to others dimensions).
In my view datasource the two fact table are connected to each other, but I can't chose the many-to-many relationship in the dimension tab ?
I'm I missing something maybe ?
Thanks a lot.
You would at least have to define an intermediate dimension. This can be defined based on the first of the fact tables, and can have the SubjectId as its only attribute. And this could be invisible to users. But Analysis Services requires an intermediate dimension for many-to-many relationships.
You can create a common table. this mean; For example you have two fact table create a table which includes only facts primary keys. Like this;
Select id as fact1ID , id as fact2ID from FactTable1 As F1
inner join FactTable2 As F2 ON F1.FK_ID = F2.ID
And create your measures in this hidden table. When you write your measure formula, dont use COUNT ,use DISTINCTCOUNT. Then create your relations from this common table to your fact tables. Now your fact table will works like dimension table. With this way you can take reports from all other dimension tables between eachother.
I just started to take data base managements and I want to know something. Can I make a connection between 2 relations? I mean there wont be any entities or atributes between them. Is it correct If I do this?
In-order to make a connection between two relations (tables) each table must have one or more columns which can somehow relate to the other table.
From the following example we are able to make a relation based on the knowledge we know about animals, even though the two tables have no attributes or entities between them that are the same.
i drew this layout scheme, but now i need to convert for a "mysql layout". So the generalization must use two junction tables, correct? (one for student and other for worker)
An about the multiplicity, users can be workers or students, but one user only can be one worker and one worker only can be an user? this does not make much sense...?
basically, how i can convert this generalization for something that can be executable for mysql code.
thanks
There are 3 ways ORM's do it
First way is give them each a separate table and join the tables. (3tables)
Second way only works if your users class is abstract, then then you take 2 tables for your sub-classes.
And the last and my favorite way.
you stuff everything in one table, and introduce a discriminator column.
basically make a table containing all the fields of users, student and worker.
add an extra column for the type and fill em up accordingly.
You can select all students / workers easily using the discriminator column, and you don 't have to spam joins. The downside is it takes up extra space.
One way to handle this is to define three tables: users, workers, and students. The workers and students tables each has a user_id field that is a foreign key tied to the same field in the users table.