Re: Hospital ERD
Date: Thu, 5 Feb 2004 13:16:58 -0500
Message-ID: <bvu1al$10a7fb$1_at_ID-114862.news.uni-berlin.de>
An ERD represents "business" relationships and constraints among the data. It rarely translates one-for-one into a relational schema (the tables in the database). The term "database diagram" is ambiguous. I take it you intend it to mean the relational schema rather than the ERD.
"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.
>
> --------------------------------------------------------------------------
--Received on Thu Feb 05 2004 - 19:16:58 CET
> -----------
> 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.
> > > >
> > >
> >
> >
>
>