RE: Data Modeling?

> >I totally agree with the pencil and paper route. But with pencil and paper you then have to write the DDL and you lack the ability to reverse engineer it. Also you have to store it somewhere and its not always available.... >One comment on tools doing more than just the basics.....checkout IBM's >Rational Data Architect. I saw a demo and it's cool. Seriously...... >for example, reverse engineer and existing database, pull the physical >layout (DBA) into a logical layout (non-DBA), modify either logical or >physical... and then you can compare the 2.... like doing a "diff" on >unix files. Then the comparison will allow you to push changes one way >or the other, or generate script to do it when you want/incorporate into >whatever else you got going on. >Also the "diff" functionality is useful for comparing the physical >layout stored in the tool with the actual DB layout on the server.... >and thereby allowing you to generate alter statements to adjust the DB >on the server (you know the DB we as DBAs actually work with ;))..... >So you can keep the managers and other people who care about tracking >data models and stuff happy, and still get your job done ;) > >Don't know the cost.... > >Lord help me, I've been drinking the blue Kool-aid..... better blue than >red ;p > Thats like saying Vodka is better than Gin, or that small batch burbons are better than single malts. (Its all what your palet prefers. ;-) >Norma Jean Sebastian >ERP Support Administration >GIS- Enterprise Technical Services > > > >-----Original Message----- >From: informix-list-bounces@iiug.org >[mailto:informix-list-bounces@iiug.org] On Behalf Of Double Echo >Sent: Friday, December 08, 2006 7:36 AM >To: informix-list@iiug.org >Subject: Re: Data Modeling? > >Urich Ann wrote: > > Is it a 'norm' that DBA's use a data model (both logical and physical) > > to design a database? > > or > > Are data models mostly used as a 'post-design' afterthought, to >document > > what is physically already implemented? > > > > In most shops that I have worked, we never used a model. And if they >did > > have a data model, it was never up-to-date. > > The model was an after-thought for documentation purposes... It was >done > > after the table was implemented in Production. > > > > Is there a good modeling tool for Informix 10? > > Is there any one 'data modeling' design class that is better then > > others? > > > > > >I think you should look at Data Modeling from two perspectives. One view >is for new work, the second for existing systems. On new work, I think >the best Data Modeling tool is still pencil and paper, or a white board. >This is a fun time, where you can actually design the data without any >restrictions other than what the business people throw into it to screw >it up. > >On existing systems, probably best to reverse engineer the schema with >some kind of software tool, but even the best I've never used to go and >make changes to the database with it. PowerDesigner does a good job, >even Visio is adequate for that. But I've yet to see some kind of >software >product actually go beyond just linking primary and foreign keys. You >can >write your own column cross-reference tool to see column relationships, >which is basically what visual tools are going to do, unless you can >link >some kind of documentation in the metadata describing what each table is >and how it relates to the other tables. Good luck if you find something >that doesn't cost a fortune, and actually does more than just draw lines >connecting primary-keys and foreign-keys together. The evaluation of >current products will be interesting, you should produce a white paper >of comparison products, it might be quite beneficial for the rest of >us. > > >_______________________________________________ >Informix-list mailing list >Informix-list@iiug.org >http://www.iiug.org/mailman/listinfo/informix-list >============================================================ >The information contained in this message may be privileged >and confidential and protected from disclosure. If the reader >of this message is not the intended recipient, or an employee >or agent responsible for delivering this message to the >intended recipient, you are hereby notified that any reproduction, >dissemination or distribution of this communication is strictly >prohibited. If you have received this communication in error, >please notify us immediately by replying to the message and >deleting it from your computer. Thank you. Tellabs >============================================================ >_______________________________________________ >Informix-list mailing list >Informix-list@iiug.org >http://www.iiug.org/mailman/listinfo/informix-list _________________________________________________________________ Get the latest Windows Live Messenger 8.1 Beta version.'Join now. http://ideas.live.com

Ian Michael Gumby wrote: > >> >> I totally agree with the pencil and paper route. > > But with pencil and paper you then have to write the DDL and you lack > the ability to reverse engineer it. Also you have to store it somewhere > and its not always available.... > I should have been a bit more clear for folks like you who would nit pick over what I said. Also note this is for new work, not existing work which I thought I made clear. Obviously I've failed you. The pencil and paper phase would not really include DDL unless you were that ambitious--at least not the way I've been doing it. It's really more about drawing boxes, and identifying primary keys, and creating new boxes when you find columns that might have more than one-to-many. For example, and I'm not going to debate this ad infinitum so please don't pick it to death: I am a person with a name. box 1 -- person table I own several automobiles. Well that's a "many", I need a new table. box 2 -- draw line from person table to new box called cars. Note a primary key, and draw a line from the person to the cars table. Keep going, build your straw man data model on paper and white board. When it comes to the details and more and more, then you can go into some kind of drawing/data-model software. The discovery process of data modeling should accomplish two things: 1. basic normalization of your tables that appear at a simple high level with maybe some details as needed. 2. your business model gets shaken out with glaring bugs After the initial exploration you can go back and refine it. It is actually a lot of fun if you do this as a group with a DBA and business people in the same room, hashing it out. As a DBA you learn about the business, as a business person you learn about the data. Great exercise for teams on both the business side and the tech side. Can actually build bridges or contempt depending on the people, either way it can be fun. :-) -DE-