Search Postgresql Archives

Re: Messy data models (Re: Visualize database schema)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> -----Original Message-----
> From: pgsql-general-owner@xxxxxxxxxxxxxx [mailto:pgsql-general-
> owner@xxxxxxxxxxxxxx] On Behalf Of Wolfgang Keller
> Sent: Friday, August 17, 2012 9:08 AM
> To: pgsql-general@xxxxxxxxxxxxxx
> Subject: Messy data models (Re:  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.





-- 
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux