Re: Hospital ERD
Date: Thu, 5 Feb 2004 17:40:09 GMT
Message-ID: <HsMH2x.Dpz_at_news.boeing.com>
No, I wasn't confused by Bob's message; or his opinion, rather. And of
course I am not of the same opinion.
A diagram is merely a representation, and often serves to give the essence
of what one wants to convey while trying to avoid distracting details.
Nonetheless, there is a tendency for individuals to confuse the concept of
using a diagram to communicate or use as a point of reference with the
concept of models and modeling, which is unfortunate.
"Louis Davidson" <dr_dontspamme_sql_at_hotmail.com> wrote in message
news: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 - 18:40:09 CET