If I was asked to query JOIN of more than three tables, what is the best way I go about understanding the relationship of the tables before I code. Should I use Database Diagram in SQL Server, or would I be given the necessary information? What would you recommend?
Thanks in advance for your time.
You could use the diagramming tools in SQL Server Management Studio to discover any Foreign Key relationships between those tables. It might be quicker than using the GUI to inspect each table in Design mode, and viewing its Relationships dialog.
Consider creating an ad-hoc View with those 3 tables. This will help you produce the SQL statement that you'd need. If any relationships exist on those 3 tables, you'll have the JOIN statement created for you by the tool.
Right click Views -> New View.
Pick the tables you need, click Add
all relationships are displayed in the Diagram Pane, and the SQL Pane will the SELECT statement with the required JOINS.
Depending on the convention they use for creating foreign keys, it shouldn't be to hard to find the relationships between tables.
The convention we use is
dbo.TableA(ID PK)
dbo.TableB(ID PK, TableAID FK)
dbo.TableC(ID PK, TableBID FK)
...
If they don't use any convention at all or didn't even create Foreign Key constraints, you can take that as an opportunity to educate them about the importance of conventions aka the lost time and money by not using them.
Related
Hi I am creating a ER diagram for my organization. How can i get the relationship between the tables in snowflake
Thanks
If you are trying to reverse engineer a current Snowflake database, you may have trouble. Foreign key constraints can be included in the table definition, however they are not enforced. If your developers included the constraints when they defined the tables, you can get the relationship from the table definitions. It is a good practice to include the constraints as many third party tools use them.
Do a deep study of all the relations of tables.
And try writing all the conditions on which two or more tables are connected
SELECT
`TABLE_NAME',
`COLUMN_NAME`,
FROM `YOUR_DATABASE`
WHERE 'PUT YOUR CONDITIONS '
This should solve your question
Click Here
This question is not limited to Power BI, but it will help me explain my problem.
If you have more than one table in Power BI, you can establish a relationship between them by dragging a column from one table to the other like this:
And you can edit that relationship by clicking the occuring line:
And by the way, here are the structures of the two tables:
# Table1
A,B
1,abc
2,def
3,ghi
4,jkl
# Table2
A,C
1,abc
1,def
2,ghi
3,ghit
This works fine since column A in Table1 consists of unique values and can work as a primary key. And now you can head over to the Report tab, set up two tables, and slice and dice at your hearts desire either by clicking directly under A in Table1, or by introducing a slicer:
But the thing is that you can do that without having established a relationship between the tables. Delete the relationshiop under Relationships and go back to Report and select Home > Manage Relationships to see what I mean:
As the dialog box says 'There are no relationships defined yet.' But you can still subset one table by making selections in the other just like before (EDIT: This statement has been proven wrong in the answer from RADO) . I do know that you can highlight the slicer and select Format > Edit Interactions and deselect the tables associated with the slicer. But I'm still puzzled by the whole thing.
So is there something happening under the hood here that I'm not aware of? Or is the relationship between tables really defined by the very contents of the tables - in the sence that the existence of related values accross tables with the existence of a potential primary key (be it natural or synthetic) makes it possible to query them using SQL, dplyr verbs or any other form of querying techniques. And that you really do not need an explicitly defined relationship?
Or put in another way, does the establishment of a Power BI table relationship have a SQL equivalent? Perhaps like the following:
CREATE TABLE Persons (
ID int NOT NULL,
LastName varchar(255) NOT NULL,
FirstName varchar(255),
Age int,
PRIMARY KEY (ID)
);
I'm sorry If I'm rambling a bit here, but I'm just very confused. And googling has so far only added to the confusion. So thank you for any insights!
Your statement "But you can still subset one table by making selections in the other just like before" is not correct. This is a key issue here.
Relations enable propagation of filter context in Power BI. That's a very loaded phrase, and you will have to learn what it means if you plan to use Power BI. It's the most important concept to understand.
To see what I mean, you will need to write DAX measures and try to manipulate them using your tables. You will immediately see the difference when you have or don't have relations.
How the whole system works (simplified):
PowerBI contains a language called "DAX". You will create measures in DAX, and PowerBI will then translate them into its internal language called xmSQL, which is a special flavor of SQL. In xmSQL, regular connection is translated into LEFT OUTER JOIN, like this:
SELECT SUM(Sales.Amount)
FROM Sales
LEFT OUTER JOIN Customer
ON Sales.Customer_Key = Customer.Customer_Key
By-directional relations are a bit more complex, but conceptually similar.
Overall, when you create relations between tables, you are telling PowerBI engine how to join the tables. The engine then also adds some optimizations to speed up the queries.
Every time you execute a DAX measure, click a slicer or a visual, PowerBI generates multiple xmSQL statements in the background, executes them, and then renders their results as visuals. You can see these SQL queries with some tools such as DAX Studio.
Note that it's not strictly necessary to establish relations between tables in PowerBI. You can imitate the same behavior using DAX (programmatically), but such "virtual" relations are more complex and can be substantially slower.
In the RM (relational model) & ERM (entity-relationship model) tables represent relation(ship)s/association. Hence, relational in "RM" & relationship in "ERM".
FKs (foreign keys) get erroneously called "relationships" in pseudo-ERM methods. A SQL FK constraint says subrows appear elsewhere as PK (primary key) or UNIQUE. A DBMS uses them to disallow invalid updates & to optimize queries.
Power BI "relationships" are not FKs. They are instructions on how to build queries.
When there is a FK we do often want to join on it. So we often want a Power BI relationship when there is a FK.
Create and manage relationships in Power BI Desktop
(See also its Download PDF link for Developer.)
PS We do not need constraints to hold or be declared or be known to query. The constraints (Including PKs, FKs, UNIQUE & cardinalities) are determined by the table meanings--(characteristic) predicates--& what business situations can arise. If constraints hold then we just sometimes get fewer rows than otherwise & some query pairs always return the same results when otherwise they wouldn't.
Foreign keys are not needed to join tables!
Is there any rule of thumb to construct SQL query from a human-readable description?
PS Cross join is inner join with a TRUE condition (or no condition in some DBMSs), period. Whether there is a "relationship" aka FK is irrelevant. If the condition is FK=PK or anything else other than TRUE then it's not a cross join; otherwise it is a cross join whether or not there is a FK between the tables. It's just that we frequently want PK=FK in a condition & tools can & do use the presence of a FK towards a default condition.
CROSS JOIN vs INNER JOIN in SQL Server 2008
You asked "What is happening under the hood?"
The simple answer is "Statements about relationships."
Many well meaning people draw ER diagrams and seem to either forget or be unaware of the fact that their ER diagrams are really "pictures of statements in language."
The problem is ambiguity.
Many well meaning people jump straight to ER diagrams without also expressing the logical statements on which their ER diagrams are based. In effect, this means that the person who draws the ER diagram seems to expect that the "reader" of the ER diagram will be able reconstruct the statements from which the ER diagram was drawn.
Here is an example to illustrate what I mean. My purpose is to show the linguistic basis of the "under the covers" relationship between Students and their Addresses.
So, what's under the covers is language!
A simple diagram
The statements from which the diagram is derived.
A more complex diagram
The statements from which the diagram is derived.
in a relational database, can we have a table without any relation with the other tables?
Yes. The way relations are expressed are with foreign keys. If a table you generate has no Foreign keys, and no foreign keys in other tables point to this table, it has no relationships.
It can still be given a relationship later though so don't worry about shooting yourself in the foot.
Of course. Even you can create a table without fields.
Yes you can. Tables do not have to have any relation to each other. Relations can always be added through the use of foreign keys if you want to add them later.
I'm creating a company management database and I have a "Company_Expenses" table that I just need for summery reports on the Company's revenues. I can't think of anything this table might need to be connected to so it's just on it's own for now.
Your question belies a larger problem with your understanding of databases.
A relation is a set of tuples (a relation can be thought of as a table).
A tuple can be thought of as a row.
Relationship in English means connectedness and has nothing to do with relation from relational databases.
Both relation and relationship share word roots, but in database theory, these words/concepts do not have anything to do with each other.
The root of the word relation in database theory comes from math (see function vs relation).
I'm working with a database with poor design. Most tables do have a PK, but FK's do not exist. This makes it difficult to visualize the relationships between the tables. This leads me to wonder, why does SQL let us join tables with no constraint? If I am going to join Table A on Table B with EmployeeId shouldn't the knee jerk reaction be to setup a FK?
Because constraints are optional.
I agree that not using constraints is usually a bad idea, but in general, one doesn't have to have constraints for a valid database design to be created.
Some applications require that no constraints are used say for a hard delete of a "current" record that still has an audit trail table (which some reports will join on).
In such a scenario, not being able to join would hamper flexibility and the ability to use the DB.
This of course leave aside the fact that many databases are created by people (business or developers) that don't know about or care about referential integrity.
In some cases u might join on dates etc where u dont want to set up Fk or it might be impossible. Its ur decision if u want to define fk or not
The philosophy of SQL is that the person writing the query just needs to know the tables and columns; they don't need to know any of the indexes or table relationships. The database is supposed to be smart enough to figure out how to perform the query efficiently.
For ad-hoc queries this is very nice.
Foreign key affects performance since each time you insert a record it needs to ensure that the constraint is not being violated. In high-performance systems, database would often have FK in development and QA environment but not in production to speed up the inserts. The difference in performance can be huge if a lot of inserts are being performed and the database tables are large.
This is only one of many reasons SQL allows you to join without constraints.
You may not join directly related tables
Numbers table
Cross joins
table to grandparent, bypassing parent table
...
GASP! You can even join on nothing!
It's been a long time since I have designed a DB as a Database Diagram but the higher ups want to see it. I have totally become confused because I am a coder, not a DBA.
I have a main table which contains user id, name, username, password, etc. This main table has the primary key of ID. Should sub tables (such as address, phone, etc) have a key point toward the id of the primary user table or should it be the other way around?
yes the yellow key will be at the primary key table...so if you have 3 foreign key tables then 3 yellow pk icons will be at the primary key table the fk tables will have icons that look like a number 8
example
The tip of the key points to the parent table (the one with the "ONE" in a one-to-many relationship) and the round end with the line goes to the child (many) table.
RE:
Its been a long time since I have
designed a DB as a Database Diagram
...
this GUI crap is messing with my style
You can generate a database diagram from an existing database so just design it however you normally would and add the appropriate FK constraints then generate the diagram afterwards.
SQL Server's Database Diagram tool is not very good. One of its many disadvantages is that it doesn't use any of the standard notations for database diagrams. The daft picture syntax it uses is unique to Microsoft. As well as being non-standard it's also particularly useless as a pictorial language because it hides so much useful information - for instance it doesn't identify foreign key columns or optionality or alternate keys. I would strongly recommend you invest in a better tool if you are serious about data modelling.