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.
Related
I have two tables, tblRecipes and tblChemicals, that are linked in a many to many relationship using a junction table tblRecipesChemicalsLink. I have a bunch of variables for calculations that differ between the same ingredient used in a different recipe. There are also a differing number of those variables between the same ingredients for different recipes:
recipe A: Water: coefficient A = 0,2648; coefficient B = 0,589,
coefficient D =0,1
recipe B: Water: coefficient E = 0,569;
coefficient C = 0,987
I want the database to be flexible in the number of variables that can be associated with the unique combination of recipe and chemical, so I wanted to create a 1-m relationship from the junction table tblRecipesChemicalsLink to a table holding my variables with fields like Value,Name,Description,ID etc. I have not figured out a way to do this succesfully. The junction table in access only lists the individual keys for tblRecipes and tblChemicals, but I would need to link the variable table to the unique combination of those keys. Adding a new ID field to the junction table and adding an ID field as primary key for the Variable table and then linking those only allowed for a many-one relationship between junction and variable table. I would need it to be the other way around. Is there some way to do this in Access? Do I have to somehow write a new custom key and construct it from the primary key values of the tables that are linked by the junction table manually?
I am using ms Access. I am looking for a table with a different coefficient in every ROW linked to the junction table, not different COLUMNS for every class (like in inheritance). The coefficients cannot be assigned to meaningful subtypes in my case.
Do some research on Ternary Relationships. These are relationships of degree three.
Your existing junction table implements a M-M binary relationship. You are going to want an M-M-M relationship. This means that your junction table will consist of not two but three foreign keys. The first two will identify a recipe and a chemical, as they do now. Your new table, (let's call it coefficients) has an ID field, as you have pointed out in your question. A foreign key that references coefficient.id is what you need to add to the junction table.
This means that every Recipe-Chemical pair would need one or more rows in the junction table, one for each coefficient that participates in the recipe for the chemical.
There are more design issues. Your coefficient table is going to have to handle some abstract form of typing unless every coefficient can be specified as a floating point number.
This is really one step towards a star schema design. I have never attempted a start schema design in MS Access, and I don't know what pitfalls you are getting near.
My database tables:
1.jobs table having fields id,name
2.locations table having fields id,name
Jobs can have more than one location and locations can have more than one jobs.So i added a table job_locations having id,job_id,location_id.
But my doubt is that if i create a table like this, will it effect normalization ?If i need to connect more tables to locations table then DB will have more tables.
(Example : if users table have more than one location and vice versa, i need to create a table as job_users too..)
I have another solution, that is to add location_id in jobs table. So jobs table fields will look like this: id,name,location_id. Then i will store all location ids as array in location_id as string.(But eloquent method will not work here).
which method is better and why?? OR Is there any other solutions?
No it will not affect normalization.
such bridge tables(weak entities) are used to produce 2NF
See for example https://geekyisawesome.blogspot.com/2011/03/database-normalization-1-2-3-nf.html
A Bridge table must be used for such m:n relationship to conform with normalization, as else you would have multiple identical values in a table.
I have a table called 'notes', on this table I need to track who made that note, but the problem is that the creator of the note can be a user stored in one of three possible tables:
users
leads
managers
I have though of simply create three fields on 'notes' to represent the three possible relations: note.user, note.lead, note.manager
With this approach I would be forced to create three table joins when requesting the notes to gather the creators information, and I don't think that is the way to go, so I would like to hear your ideas or comments and what would be the best approach on this.
For me personally this smells like a design problem on a totally different part of the schema: Are manageers not users? Do leads carry person information?
With any approach that creates a relation between one column and one of three others, you will need three joins for the select. If you can't rectify the underlying problem, I recommend you use
note_type ENUM('users','leads','managers')
as an additional field and
SELECT
...
IFNULL(users.name(IFNULL(managers.name,leads.name))) AS name
..
FROM notes
LEFT JOIN users ON notes.note_type='users' AND users.id=notes.note_source
LEFT JOIN managers ON notes.note_type='managers' AND managers.id=notes.note_source
LEFT JOIN leads ON notes.note_type='leads' AND leads.id=notes.note_source
...
for the query
I think you need to abstract out the concept of a user id, so that it does not depend on their role. The author of a note could then be specified by the user id.
Users could be assigned roles, and maybe more than one.
The correct way to structure this would be to pull all common data out of users, leads, and managers. Unify this data into a "contact" table. Then if you want to get all notes for a given manager:
managers->contacts->notes
for a lead:
leads->contacts->notes
Notice your original post: "the problem is that the creator of the note can be a user stored in one of three possible tables"
From the structure of your sentence you even admit that all these entities have something in common; they are all users. Why not make the DB reflect this?
you have to model a parent table for the three tables you already have. Define a table that depicts generally user, leads and manager tables. Something like "Person". So you have all of the ids of the three tables and any common attributes on the Person table. And when you must define the relationship you put the foreign id "Person_ID" on the note table. And when you model user, leads and manager tables you also put the primary key as a foreign key to the Person table.
So you would have something like this:
Table users:
Users(
person_id primary key
...(attributes of Users)
foreign key person_id references Person.person_id
)
This model i depict is common to any relational model you have to model using parents and childs
I have a parent table called 'Website' which holds records about websites. I have a child table called 'SupportSystem' which holds records about different types of support systems such as email, phone, ticketing, live chat etc. There is an intermediate table 'Website_SupportSystem' which joins these tables in a many-many relationship.
If the SupportSystem for a Website is ticketing, I also want to record the software platform .e.g. WHMCS. My instinct is to create a new lookup table called SupportPlatform and relate this to the existing join table 'Website_SupportSystem' and store the data there. However, then there is no relationship between the SupportSystem and SupportPlatform. If I relate those then I end up with a circular reference.
Can you see what I am doing wrong? What would be the best way to model this data?
You could use super-type/subtype relationship, as shown in the diagram.
SupportSystem table contains columns common to all support systems.
Email, Ticketing, Phone and LiveChat tables have columns specific to each one.
Primary key in the subtype table is also a foreign key to the super-type table.
I would add a new column 'SupportPlatformId" to the "SupportSystem" table which lookup to the table "SupportPlatform", because "SupportSystem" to "SupportPlatform" is probably one-to-one or many-to-one.
Hence: Website -> (via Website_SupportSystem) SupportSystem -> SupportPlatform
Data about a Support Platform should be stored in the SupportPlatform table.
You can add a third foreign key, namely SupportPlatfromID, to the Website_SupportSystem table. If you do this, your intermediate table now records a ternary relationship, of the kind many-to-many-to-many. If this reflects the reality, then so be it.
If you want to relate SupportSystems and SupportPlatforms, just use the intermediate table as an intermediate table in the joins. You can even do a three way join to join all three entities via the intermediate table.
An alternative would be to create another intermediate table, SupportPlatform_SupportSystem, with a pair of foreign keys, namely SupportSystemID and SupportPlatformID. If this reflects the reality better, so be it. Then you can join it all together with a five table join, if needs be.
I'm designing a small database for a personal project, and one of the tables, call it table C, needs to have a foreign key to one of two tables, call them A and B, differing by entry. What's the best way to implement this?
Ideas so far:
Create the table with two nullable foreign key fields connecting to the two tables.
Possibly with a trigger to reject inserts and updates that would result 0 or 2 of them being null.
Two separate tables with identical data
This breaks the rule about duplicating data.
What's a more elegant way of solving this problem?
You're describing a design called Polymorphic Associations. This often gets people into trouble.
What I usually recommend:
A --> D <-- B
^
|
C
In this design, you create a common parent table D that both A and B reference. This is analogous to a common supertype in OO design. Now your child table C can reference the super-table and from there you can get to the respective sub-table.
Through constraints and compound keys you can make sure a given row in D can be referenced only by A or B but not both.
If you're sure that C will only ever be referring to one of two tables (and not one of N), then your first choice is a sensible approach (and is one I've used before). But if you think the number of foreign key columns is going to keep increasing, this suggests there's some similarity or overlap that could be incorporated, and you might want to reconsider.