Re: Hospital ERD
Date: Thu, 5 Feb 2004 10:23:59 -0600
Message-ID: <HvSdnWAwotam87_d4p2dnA_at_comcast.com>
Was anyone else confused by this message? Am I the only one who consideres himself (or herself) a thinking person who uses a database diagram as a way to visualize a database model? Not to mention that they do most of the work of turning it from a model into a physical reality.
Louis Davidson (drsql_at_hotmail.com)
Compass Technology Management
Pro SQL Server 2000 Database Design
http://www.apress.com/book/bookDisplay.html?bID=266
Note: Please reply to the newsgroups only unless you are interested in consulting services. All other replies will be ignored :)
"Bob Badour" <bbadour_at_golden.net> wrote in message
news:_-udnQxXtoWwuLzdRVn-vA_at_golden.net...
> Thinking people typically do not rely on diagrams.
>
> "Portroe" <fb_at_oooi.com> wrote in message
> news:bvqi77$sea$05$1_at_news.t-online.com...
> > Charge Nurse, Medical Director, personnel officer, Doctor etc of course
> > all have differing functions, and differing interactions with the other
> > attributes
> >
> > the Charge nurse will have hundreds of connected records over a month,
> > ie. medication ordered, The Medical director significantly less etc
> >
> > is there a source for Sample ERDs where I can see how people typically
> > cope with multiple subclasses 'diagramatically' ?
> >
> > thanks
> >
> > Louis Davidson wrote:
> > > Well, what are your requirements for each of the staff? What will you
> need
> > > to do with each of the different types of staff members? And how much
> data
> > > do you plan to store on each.
> > >
> > > My initial reaction is to say use a subtype construct. Have a Staff,
or
> > > person table that models common things you know about a staff member
> > > (employee Id, badge number, physical attributes, etc) and then a
> separate
> > > table for specialized attributes about each type of staff member. I
> would
> > > expect it to be an incomplete subclass, in that some types of staff
> members
> > > might not have specialized attributes (janitors, possibly) while
nurses,
> > > doctors, etc might have specialties, etc.
> > >
> > > It is flexible, and most of all, it allows you to treat a person as
> special
> > > when needed, and as common when needed. If you have one table per
staff
> > > member type, then you might need a bunch of relationships to model
that
> they
> > > all get ID cards, or whatever.
> > >
> >
>
>
Received on Thu Feb 05 2004 - 17:23:59 CET