Re: Resource Ownership

From: Tobin Harris <comedyharris_at_hotmail.com>
Date: Sat, 18 May 2002 22:48:08 +0100
Message-ID: <ac6i2g$n2ghh$1_at_ID-135366.news.dfncis.de>


> - Any more suggestions ? Corrections ?
> - The application must also give the possibility to an initiator or
> resource owner to delegate his/her responsibilities to another employee
> in the Company. So he/she must be able to delegate his/ner role from a
> certain date to a certain date to somebody else. How must this fit into
> the datamodel ?

Hi Nonkel Sue,

I've just uploaded your latest model, and I must say it looks loads better. I like the following changes:

I'd like to throws a few suggestions in - but anyone feel free to correct me if I'm wrong. Please note that for starters I'm just looking at style, but will try to comment on other things later on. I'm making a few assumptions about your notation too, so forgive me if I've misunderstood something.

  1. No optional relationships I noticed that there are no optional relationships indicated on the ERD. An optional relationship might look like this ---o< . It may be that the notation you use doesn't include optional relationships? For example, I would have thought that an Employee could exist without a Request, however the diagram indicates that they must have one or more requests.
  2. Surrogate Keys I notice you've gone with the surrogate key approach - where every table has a surrogate key. For example, your Login table has L_ID, but you could have had a composite key with E_ID and L_ID, indicating that the login cannot exist without an Employee, if this is the case. This surrogate key approach is fine, but I would make sure this decision is documented for your lecturer..
  3. Naming Considerations You could consider the following naming updates. There's no real right/wrong here, but just some thoughts.

Ok, that's it for now. I'll see if I can look at some more later.

Tobin Harris

> Nonkel Sue - [nonkelsue_at_pandora.be]
> *****************************************************************
> "Be strict when sending and tolerant when receiving."
> RFC 1958 - Architectural Principles of the Internet - section 3.9
> *****************************************************************
Received on Sat May 18 2002 - 23:48:08 CEST

Original text of this message