CSCC40 / Analysis and Design of Information Systems
University of Toronto at Scarborough / library example

The following information is available when a client lends a publication

client name / this may not be unique, so we also need a client id
client id / a unique number is assigned to each client
client address / this is the same for every publication the client lends
client status / one of active or blocked; this will affect the lending transaction/function
publication name / not unique, all issues/volumes have the same name (e.g. "ACM Communications")
publication date / one of January, February, etc.
copy number / the library has several copies, so we need to know which copy is being loaned
publication status / available or on hold: this will affect the lending transaction
lending date / the date the client lends the publication
due date / this is calculated as lend date + 3 weeks

Because .....

Client name, id, address and status are already in place before the client tries to lend this publication. That means that these data elements (attributes if you are talking UML) are not part of the lending transaction/function.

Publication name, date, copy number and status are already in place before the client tries to lend this publication. That means that these data elements (attributes if you are talking UML) are not part of the lending transaction/function.

The due date can be calculated at any time, because the library rule for this publication is lend date + 3 weeks, no matter who loans this publication.

This publication is uniquely identified by publication name + date + copy number. The client id uniquely identifies the client. Because the client may lend the same publication more than once, the lending date is needed to uniquely identify the lending transaction.

The client status and/or the publication status may prevent the client from lending this publication. If so, no lending transaction takes place.

we have these tables

CLIENT / LEND TRANSACTION
client id / client id
client name / publication name
client address / publication date
client status / copy number
lending date
PUBLICATION
publication name
publication date
copy number
publication status

Please review the normalization rules to see if the above tables are normalized!

Each of these tables is a data store in the DFDs. (They don't show up in the context diagram if they are internal to the system.)

In the entity relationship diagram (ERD) the three tables look like this.

A client may lend a publication zero, one or more times.

A publication can be loaned to zero, one or more clients.

The lend transaction is an associative entity.