The right methodology of designing a database is based on the foundations of data normalization, according to which we should first define database’s key elements – entities. Afterwards the attributes of entities and relations between them are determined. Let us learn in this blog post how to work with database diagrams.
There is a strong opinion that the process of database designing should start with a pencil and a blank sheet of paper. This might look old-fashioned nowadays, because SQL Server provides a much wider functionality for designing databases – Database Diagrams.
When using SSMS for working with Database Diagrams I realized two things – on the one hand, visualization of a scheme allows designing a database more efficient; on the other – when it came to creating a big scheme, some difficulties occurred when designing with SSMS.
The alternatives haven’t taken long to wait and dbForge Studio for SQL Server is one of them. Its functions offer more advantages for working with Database Diagrams.
For example, unlike SSMS, dbForge Studio supports an opportunity to drag-and-drop several tables at once from the Database Explorer. This is my opinion, but personally I find this option very useful.
Another great thing is that a diagram can be saved as both a graphic file and a special XML file, which in case of identical environment can be easily opened on the other server for continuing the work.
During working with dbForge Studio it turned out that it offers a wide set of elements to operate with on the diagram.
Noteworthy among such elements are containers which allow aggregating diagram objects into thematic groups.
Moreover, you can even place an image directly on the diagram if the scheme design is based on a standard template.
Each of the development environments has a different approach to storing a diagram.
Reference: Pinal Dave (https://blog.sqlauthority.com)