Re: Resource Ownership

From: Tobin Harris <>
Date: Sun, 19 May 2002 12:09:26 +0100
Message-ID: <ac810u$nfhrt$>

> > I like the following changes:
> >
> > - Consistant naming of entities (no mixing of spaces/no spaces)
> > - Consistant naming of columns
> > - Connector lines not overlapping
> Can you be more specific on this issue ? I can't see any of these in the
> last model I made.

Yeah - things look tidier. For example, your first model might have had one entity called "Resource Right", and another called "GroupResourceRight". Here, you're mixing tables named with spaces in with ones that haven't. Your latest model is more consistant. You could say that you are now using a naming convention.

When I get to see a database that hasn't got any consistant naming convention, it instanly makes me worry about the quality in the rest of the design. Keeping the naming is important in that that it can help keep the schema maintainable. IMHO, it also helps show people that you pretty much know what you're doing (lecturers included!).

The same goes for your column names, which are also tidier now than in V1.0.

> So you mean that the relationship between Employee and Request should be
> drawn like this [(0,n) instead of (1,n) ?] :

I think you need to ask the question "Can an employee exist in the system, even if they haven't made a Request?". I imagine that the answer to this would be "yes". For example, when the administrator adds employees, he doesn't instantly have to add requests for them. So, an employee will have 0 or more requests (0:n). 0 when they are set up, and more when they start requesting Resource Rights.

This may be the same for many other relationships. Have a think about it. Conversly, an Application Role Right could definately be 1:n, because there's no way the administrtor can set up an Application Role Right without entering at least one Application Role already there.

> Entity ---O|----< Request

Yeah, here's some examples from the way I learned.

Employee -|----------O< Login

Employee >O----------< Group

Entity -|O-------------< Request (I think)

Before getting bogged down with this, make sure it is something covered in your lectures. It's unlikely that you'll be expected to put it in if it hasn't been mentioned on the course. However, IMHO optionality is a fairly important aspect of relational modelling.

> > - Rename "Right" to "Resource Privilege". Similarly, "Applicatoin Role
> > Right" would become "Application Role Privilege". Bit of a biggy this
> > becasue you'd have to rename other entities also, so don't worry about
> > too much.
> This will have a too big implication on all other things I wrote up till
> now. In the document I'm writing, I'm talking about Rights on Resources,
> so changing Rights to Privileges would mean that I have to review the
> complete document and all other stuff I wrote up till now. I'd rather
> like to keep it like it is now...

The way you've done it is fine.

> In the mean time, I also got more information from Doug. I already made
> a new, simplified model out of the information he gave me. But it's not
> yet a model that could replace the latest upload. I'm still missing a
> few things; I'm waiting to receive an answer on the question I send to
> him on this.
> Anyone more suggestions ?

A bit off topic, but might be helpful...Looking back to my Uni days ( not that long ago!), it was always very important that you document any assumptions you make when building the model. I imageine you've made a few here, so I'd advise that you get these down in your write up unless told otherwise. If you haven't addressed this already, an assumption might be something like "Is is assumed that the system does not need to record login history, so this has not been catered for in the design". You'll know best what assuptions you've made, and those that are most important.

Another thing, just looking at your relationship names. Have you considered being slightly more verbose, or is that not you're lecturers preferred style. Some examples:

Resource - is requested in - Request
Request - is made for - Resource
Application Role - is assigned to - Login Login - has - Application Role

Again, not the most important aspect, but may squeeze you a mark of two!? My reasoning for this is that labelling the associations well can add value to the model, and help understanding.

I'll wait for your next version before making any more suggestions!

HTH Tobin

> --
> br,
> Nonkel Sue - []
> *****************************************************************
> "Be strict when sending and tolerant when receiving."
> RFC 1958 - Architectural Principles of the Internet - section 3.9
> *****************************************************************
Received on Sun May 19 2002 - 13:09:26 CEST

Original text of this message