| I use a combination of the gnome-based diagraming application Dia (http://www.gnome.org/projects/dia/) and the tedia2sql diagram-to-DDL SQL translation script, which is written in Perl (http://tedia2sql.tigris.org/). It's a bit awkward, but: 1) Dia is a wonderful, open source diagramming tool I can run on Windows, Mac OS X (via Fink) or Linux - nearly all of the commercial tools have traditionally been Windows only, though this is slowly changing; 2) Dia comes with a set of UML diagram objects which work quite well for laying out a detailed data model. There are also ERD diagram objects, they don't seem to be of much use; 3) tedia2sql does a very good job translating most standard SQL-92 (and some additional SQL-99 extensions) from UML objects to SQL objects; 4) Dia saves its diagrams in XML format which makes it relatively straight-forward to add to the SQL translations being performed (see the many tedia2sql like translators on the Dia links page - http://www.gnome.org/projects/dia/links.html). Some of the PostgreSQL specific features such as Inheritance and Rules can be diagramed using the UML formalism and one can write extensions in Perl to tedia2sql to turn that in DDL SQL; There are other SQL to Dia diagram translators (e.g., PostgreSQL AutoDoc [http://www.rbt.ca/autodoc/]) which allow for reverse-engineering a data model diagram from an existing PostgreSQL DDL SQL schema. There are also other Dia-to-SQL tools (see the Dia links page), some of them even more specifically tailored to PostgreSQL than tedia2SQL is. I came to using tedia2sql over these because I found it supported more of the general SQL entities and relations I needed and it was relatively easy to use. I should add this approach of sticking with open source tools that are relatively straight-forward to modify and extend is not for the faint of heart. You absolutely must have a solid grasp on what a database Entity-Relation Diagram (ERD) is. Understanding the translation process (XML Dia diagram objects to DDL SQL code generation) can be quite helpful in making best use of tedia2sql, though it is not necessary to getting started turning DDL SQL out from your Dia data models. A thorough understanding of this process and knowledge of XML document parsing IS required to extend the translator. This more "home grown" solution doesn't do as good a job separating logical data models (implementable in any RDBMS) from physical data models (version of the logical model designed for a specific RDBMS). I've found to easiest and quickest to simply create the physical model diagram and focus on how to get that translate properly in PostgreSQL DDL SQL. The Dia data model diagrams I create aren't easily re-usuable in other RDBMSs, but then again, I don't intend to stop using PostgreSQL, unless I'm driven from it for some applications-specific reason. I'm working on a port of tedia2sql to Ruby (my scripting language of choice of late), mainly because I've got Object-Relational mapping libraries there which will make it easier to create a complete, "round trip" ERD system - i.e., be able to both generate Dia diagrams form existing PostgreSQL DDL SQL schemas and turn Dia diagrams in to DDL SQL that can be used to directly instantiate the schema in PostgreSQL (via DBI code). Cheers, Bill On Jul 31, 2005, at 1:54 AM, Jeffrey Melloy wrote:
|
