I am working on a project that involves modeling a complex database schema & I am looking for advice on how to best represent intricate relationships using DB Diagram. The database I am designing has several many to many relationships, as well as multiple hierarchical structures that I am struggling to visualize effectively.
What the best way to model these in DB Diagram to ensure clarity without overcrowding the diagram? Are there any tips for using junction tables effectively in the diagram?
I have parent child relationships between several Businesses. How can I best structure these to make the diagram intuitive and easy to understand?
Are there strategies for keeping large diagrams manageable and readable?? Also I am thinking about exporting the diagram to Nextcloud for team collaboration or possibly integrating with google cloud has anyone tried either of these?
I would greatly appreciate any advice, examples or resources you can share.
What the best way to model these in DB Diagram to ensure clarity without overcrowding the diagram?
You can switch between detail levels, for example, Keys Only, when presenting your diagram to make sure the diagram is not overcrowding.
Are there any tips for using junction tables effectively in the diagram?
You can present a many-to-many relationship with our native ‘<>’ relationship type or use two alternative one-to-many relationships with a junction table, depending on whether you want to communicate the junction tables. We also have a tutorial on this topic.
I have parent child relationships between several Businesses. How can I best structure these to make the diagram intuitive and easy to understand?
I’m not sure about this, can you share more about this?
Are there strategies for keeping large diagrams manageable and readable??
You can put tables into table groups and collapse/expand them to make the diagram easier to manage and read.
This would be a very good enhancement.(adding the name onto the diagram itself). Particularly in dimensional modelling - its common to have a conformed dimension join to many facts across multiple subject areas
I am referring to Data Warehouse design - top down using dimensional modelling techniques. Part of dimensional modelling is to identify “dimensions” or tables which hold information about facts(typically events).
For ease of use and to ensure one consistency, these tables are re-used often across entities. For example a business may use a “user” dimension to store staff or customer details which could then be used across operational, sales, hr subject areas. This would mean say if user information is in multiple source systems, it would be conformed into the one table for consistency.
I found removing all dimensions from your table groups helped with presentation(as i only wanted the one table group in the table group view on dbdocs), but really naming relationships on the diagram would be even more helpful - particularly for the large wiki view. This is a feature of some other mature modelling tools.
Another dimension that is joined virtually everywhere is a calendar dimension - used for simplifying queries to gather data for specific date periods.
I’m Patrick - the Product Manager here at dbdiagram. I understood that you’re mentioning Kimball Dimensional Modeling, which I found interesting.
I definitely want to learn more about your case, I’d love see the data models that your team is currently building - you know, to get a sense of the complexity, and how dbdiagram could help with that.
You can send me the example diagram via my email phat.nt@holistics.io so I can take a look
Perhaps setting a quick call with me via this link is a great option if you prefer video calls. You can book a chat here with this link.
I work in an insurer and have a similar use case on the need to have conformed dimensions across multiple fact tables.
If you get the book The Data Warehouse Toolkit and refer to Chapter 16 you will see the insurance use case. You will see the need to have common Policy and Claim dimensions referred to across multiple facts. Even using Date as a common dimension results in a messy render.
It would be great to be able to have a primary fact used to model the dimension and then alias it using a collapsed view for other facts. That way you can illustrate the relationships but not cause lots of lines being drawn across the diagrams.
What would also be helpful is to have additional column tags added other than just ‘note’ such as ‘label’ which could be used to add detail about what the semantic layer column title should be for the PowerBI team. We are currently creating a syntax for the note description column which is a bit crude (Column Title\n\nDescription text). I recognise this last paragraph would be a different feature request and therefore a separate topic.
We’ve noted your request to visualize conformed dimensions using a primary fact table with a collapsed view for aliased dimensions.
This is an excellent idea to simplify diagrams and reduce clutter, especially for cases like the insurance use case you mentioned with shared dimensions (e.g., Policy, Claim, Date) across multiple fact tables.
In the mean time, I believe you can use Table Groups to host all your related fact tables to declutter the visualization.
Regarding your suggestion for a ‘label’ tag to enrich column metadata, we’d love to get more details to ensure we tailor it to your needs. Here’s what we’re curious about:
Content Examples: What kind of information would you include? For instance, would it be a simple title like “Policy Number,” or something more descriptive like “Policy Number – Unique identifier for insurance policies”? Would you also want to add details like data types or brief descriptions?
Display Preferences: How would you like this ‘label’ presented in the diagram? Options could include:
Next to the column name (e.g., Policy Number [label]).
As a tooltip that appears on hover.
In a separate reference section.
Current Workflow: Could you share an example of how you’re currently formatting note descriptions? For example, do you use something like “Column Title\n\nDescription text”? This will help us design a solution that aligns with your existing process.
Your input is invaluable as we work to improve dbdiagram for data warehousing scenarios like yours. Thanks again for your detailed suggestions—we’re excited to hear more!
If you consider CDM → LDM → PDM. dbdiagrams is focusing on the PDM.
What would be nice is to toggle between a functional name of the column i.e. its “title”. So similar to your Show drop down list, have the ability to toggle between the physical columns and functional columns would be a great feature. The Title would most likely be the same column title you would expect to see in a Power BI semantic layer. Having the ability to toggle between the physical column name and functional column name makes reviewing the model with business stakeholders easier and less technical. Legacy databases do not always have great column titles.
These tags could also be something you allow us as users to define too i.e. not being limited to concepts such as title or labels allows us to add metadata to the columns that we might wish to use to report upon. For example, understanding where a column is used from the source layer to target layer is useful information so if we could define lineage tags that would be really helpful information. This supports the Databricks Bronze → Silver → Gold concept.
In the tooltip that hovers to the right of the column if you could create a section that lists each tag and what its been set to, that would be helpful. That removes the need to use the \n\n method in the description.
We are also at the moment wanting to quickly visualise what columns from the source system are in the target data warehouse. We are putting green ticks at the front of the column names so we can quickly gap assess what’s currently in vs what is currently not. We are also wanting to short list what goes into our next release so we are going to use a different symbol (not a green tick) to illustrate that its in scope of the next release. Once we deliver it, we will make it a green tick.
We are adding the ticks into the column names at the moment which makes the ref joins messy. We have to use " " around the column names as the tick is in the field name. Having an ability to add a status icon to the front of the column name would be really helpful as we could then track its status of being delivered.
Really appreciate you taking the time to share these insights! You’ve brought up some great points, and it’s super helpful to hear how you’re using dbdiagram in real-world scenarios.
Right now, we do support some of these workflows, but we know it’s not as smooth or flexible as it could be—especially when it comes to toggling column names, adding metadata, and tracking statuses visually.
We’ve taken note of all your suggestions, and if we decide to roll them out, we’ll be sure to keep you in the loop.
Thanks again for your thoughtful feedback—it really helps shape the future of dbdiagram!
