Re: Messy data models (Re: Visualize database schema) - Mailing list pgsql-general

From David Johnston
Subject Re: Messy data models (Re: Visualize database schema)
Date
Msg-id 008301cd7c96$0d605c90$282115b0$@yahoo.com
Whole thread Raw
In response to Messy data models (Re: Visualize database schema)  (Wolfgang Keller <feliphil@gmx.net>)
Responses Re: Messy data models (Re: Visualize database schema)  (Wolfgang Keller <feliphil@gmx.net>)
Re: Messy data models (Re: Visualize database schema)  (Gavin Flower <GavinFlower@archidevsys.co.nz>)
List pgsql-general
> -----Original Message-----
> From: pgsql-general-owner@postgresql.org [mailto:pgsql-general-
> owner@postgresql.org] On Behalf Of Wolfgang Keller
> Sent: Friday, August 17, 2012 9:08 AM
> To: pgsql-general@postgresql.org
> Subject: Messy data models (Re: [GENERAL] Visualize database schema)
>
> > Concerning auto-layout, most if not all tools I have used up to now
> > make a mess for anything that is not dead simple.
>
> If a data model can not be reasonably "untangled" by an auto-layout
> algorithm (such as e.g. Graphviz) for display as a human-readable graph,
> wouldn't that mean that this model is a mess from the modeling point of
> view?

No

>
> In fact, shouldn't reasonably well-designed data models at least mostly
> follow SER principles? In that case, they could be displayed essentially
as a
> tree.

No - and what the heck are "SER principles"?

>
> Could the "messy-ness" (or not) of the display of a data model (given a
> standard alorithm such as Graphviz) be used as a criterion to judge
whether
> the model is actually well-structured?

No

>
> Sincerely,
>
> Wolfgang
>

I speak with little actual experience but:

The issue with layout algorithms is that it is difficult to incorporate
semantic knowledge of the model into the layout and they generally will not
duplicate nodes in order to improve the layout.

If you help the algorithm out by designing meaningful schemas (i.e.,
namespaces) and require that the algorithm "import a copy" of any relations
located in other schemas that would be a start.  You'd then have one view of
inter-schema relations and another of intra-schema relations with external
relations noted but minimized to the bare necessities.

Also, in some models, there are relations that are so prevalent that
including all them just adds noise to the layout when a top-level
description would be just as clear and remove the extra lines from the
graph.  How to code a pure layout algorithm to be able to identify those
situations (with our without a standard naming scheme to help it) and create
meaningful "text summaries" while removing the corresponding paths I do not
know but it would also go a long way toward visually simplifying complex
models.

David J.





pgsql-general by date:

Previous
From: Matthew Vernon
Date:
Subject: Replication with infrequent large updates
Next
From: Sébastien Lorion
Date:
Subject: Re: Messy data models (Re: Visualize database schema)