Re: Hospital ERD

Yeah, that was what I was wondering.

A lot of times the term data model and data diagram are used interchangably, and I have been guilty of this in the past (though I was careful to keep it right in my post :)

It is a good point to note that not everything is displayed on a data diagram that is part of the data model.

Thanks,

Louis

"D Guntermann" <guntermann_at_hotmail.com> wrote in message news: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.
>
> - Dan
>
> "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 Fri Feb 06 2004 - 17:53:08 CET