Re: How to represent different types of people

From: Kev <kevin.porter_at_fastsearch.com>
Date: Thu, 07 Dec 2000 13:45:24 +0000
Message-ID: <3A2F9474.CA1B1DB6_at_fastsearch.com>


I can assure you that it is not an exam question - I'm a programmer on a football site (http://www.fa-premier.com) and this is defeinitely a real-world problem!

My solution so far is to have a Person class, which is subtyped to Player and Manager. I can represent this
on an ERM diagram easily enough using an arc (or a circle with a 'd' in). In implementation I guess I would
have to have a 'type' field in the Person table, and then add a 'where person.type = player' clause (or
something to that effect). Is this an acceptable way of implementing it, or is there some other 'standard' way
I should be aware of?

thanks,

Alan wrote:

> Sounds a lot like a question on a take-home final. So, to not give you the
> final answer, think about the cardinality of the relationships, and don't
> get too hung up on what you call things. They are only nouns and verbs.
> "Plays_for" could be named anything, like "performs_job_of", or
> "whose_job_title_is". But that's not the big problem with what you are
> doing...
>
> "Kev" <kevin.porter_at_fastsearch.com> wrote in message
> news:3A2E3E70.9480788_at_fastsearch.com...
> > Hi,
> >
> > I have a design question I hope someone can help me with...
> >
> > I'm designing a database relating to sportt, a part of which needs to
> > represent different
> > types of people, 'different types of people'
> > meaning 'people with different jobs'. So, I have made a 'Job' entity on
> > my ERM and a 'Person' entity. I have
> > a third entity called 'Person_Job' which represents an instance of a
> > person's employment. Person_Job stores
> > a start and end date too.
> >
> > The problem I'm having is that different types of people need to have
> > different relationships with other
> > entities in the system. For example, I cannot simply add a relationship
> > labelled 'Plays for' between
> > Person_Job and the Team entity, because although that would be correct
> > for a player it would not be
> > correct for a manager, and there are other relationships which are true
> > for a manager but not for a player.
> >
> > What is the correct way of dealing with this situation on an ERM? And,
> > what is the correct way of
> > implementing it?
> >
> > thanks,
> >
> > - Kev
> >
  Received on Thu Dec 07 2000 - 14:45:24 CET

Original text of this message