Creating a relation diagram from database with no constraints - sql

Consider there is a huge SQL database that works fine but no constraints made during database conception. I need to make a relation diagram of database tables. Is there any tool I can use to do at least part of it for me?

Related

PostgreSQL: If I define 1-to-1 views for each of my tables and query only from my view layer, will the indexes of the underlying tables be used?

I am using PostgreSQL and I want to create a layer of views on top of all the tables in my database schema. I will implement a 1-to-1 mapping of view to table, so these views will not have joins in them. The purpose is to provide a read-only abstraction so that I can change the underlying table structure of the database over time but control what is exposed through the views.
The question I have is when I start querying (SELECT statements only) using the views, including some complex joins and other complex query dynamics like aggregation/grouping, will PostgreSQL make use of the indexes on the underlying tables as if I was querying them directly?
I am starting with a PoC of this now. I don't have any results yet, but wanted to hear from other people's knowledge, experiences and opinions.
Yes, the engine will use available indexes and optimize the code. It will basically replace the view with its definition and build the plan.
Here you can fine some example and test it further.

SQL server management studio Relationships connection

In databases you can define relationships between tables. But what exactly is the use, besides documentation, of making these relationships explicit in a diagram (for example by connecting the keys in SQL server management studio)?
Does it give you any advantage in writing SQL statements? Computation time? Memory usage? Usually you "repeat" the relationship in the join statement. I have the feeling I'm missing something trivial.
Thanks
From the fine manual
You can use Object Explorer to create new database diagrams. Database diagrams graphically show the structure of the database. Using database diagrams you can create and modify tables, columns, relationships, and keys. Additionally, you can modify indexes and constraints.
You asked:
Does it give you any advantage in writing SQL statements?
They can tell you how the datase is structured. That's usually pretty key to understanding it, and reading all the FKs into your head and remembering which table relates to what can be quite the puzzle and even then not actually relate to how the data is used and related in-application
Computation time?
Not quite sure what this means, but the presence or absence of a database diagram won't impact the amount of time your SQL Server spends planning or executing queries
Memory usage?
Not really
Usually you "repeat" the relationship in the join statement
Sometimes; there are ways of joining data without using joins, and presence or absence of FKs or database diagrams have nothing to do with SQLS ability to join data
It might be best to think of DB Diagrams as a visual design aid and tool

How To Update Table Relationships in TABULAR SSAS

I've Imported multiple tables in my tabular model in SQL Server Analysis Services, after importing, I changed my tables structure and defined foreign keys. now my tabular model doesn't understand my changes and not showing me my relationships.
Does any body has any idea how to update my table relationships without recreating project?
Thanks.
I Opened my project in Data Tools AND Viewed it as Code. In View Code Mode, I Changed My Relationships And Added New Columns, Renamed My Columns And pretty much, Changed Everything.
It is more complicated than Design View but I think Its more powerful.
I was looking for this for a long long time, thought it may happen to you too, so I posted in here. :)

Automatic/Tool Visualize Database Schema

It's recently fallen upon the shoulders of another developer and I to pull information from a database spanning some 669 tables with no useful documentation or accessible experts/DBAs of the database. We're not even exactly sure what all information is locked away in the tables that we can pull from to create our--effectively--reports.
Is there any tool or method of generating a diagram (or any other way) to visualize the information to speed up the process?
I was thinking about a generic SQL tool, but the specific database technology is Sybase.
I have been using Sybase Powerdesigner for reverse-engineering database schemas some years ago. I used it to generate a database diagram of the tables with foreign keys to show the relation between the tables. It supports other databases than Sybase too.

Normalization of an existing SQL database

I have a single-table database I inherited and migrated to SQL Server, and then I normalized it by creating, linking, and filling a whole bunch of lookup-type tables that represented items in the main table. I now want to replace those items in the original table with their foreign keys. Am I stuck writing a bunch of queries or UDF's and then a giant INSERT statement to accomplish this, or is there a tool I can use to point at the various fields and have it handle the grunt work for me?
Redgate SQL Refactor comes with a 14 day evaluation period and has a "Split Table" refactoring which sounds like it might do what you need?
The feature is described thus:
Split Table splits a table into two
tables, and automatically rewrites the
referencing stored procedures, views,
and so on. You can also use this
refactoring to introduce referential
integrity tables. You can select this
feature from the context menu in
Management Studio’s Object Explorer.
I have had similar experiences. I once inherited a fairly large database that required serious overhaul to the schema before I would look at it without scorn.
Because the upgrade was fairly significant, I designed an SSIS package to migrate data from the old schema to the new. Lookup activities were helpful to map old text values to the new keys. I kept a script of my old schema and data handy and would repeatedly restore the database in a sandbox and re-migrate until I could satisfy the powers-that-be that the migration was reliable.
I found there was only a moderate learning curve to getting started with SSIS. If the tool is available to you, I recommend giving it a try.