database sistems_10_conceptual

1n ConceptuaDl atabase

I lJ DesignMethodology-

WorkedExample

ChapterObjectives

In this chapteryou will learn:

I How to use the conceptualdatabasedesign methodology,describedin Chapter 7.
r How to use this methodology to createa conceptualdatabasedesign for theDreamHome

casestudy,describedin Section1.7.

305

306 ConceptuaDl atabaseDesignMethodolog-y WorkedExample

In this chapter,we illustrate by example the conceptualdatabasedesignmethodo-

logy describedin Chapter7. We use this methodologyto createa conceptualdata-

basedesignfor the DreamHome casestudy, describedin Section 1.7. To illustrate
this methodology,we examine the casestudy from the perspectiveof a particular

user's view of DreamHome,namely the Supervisor's.In this chapter,we describe

the developmentof a local conceptualdata model for the Supervisor'sview of

DreamHome. the readability of this chapter, the terms 'entity' and 'relation-
To improve
ship' areusedin place of 'entity typet and 'relationshiptype' where the meaningis
obvious; 'type' is generallyonly addedto avoid ambiguity.

L0.1 The Supervisor's RequirementsSpecification

The requirementscollection and analysisphaseof the databasedevelopmentlifecycle

was carried out at a DreamHome branch office and involved interviewing members

of staff with the job title of Supervisor and reviewing any documentation usedor

generatedin their day-to-daywork. This phaseresultedin the production of a require-

ments specificationfor the Supervisor'sview of the company,which describesthe

information to be held in the DreamHome databaseand the transactionsrequiredby

the Supervisor. term 'Supervisor'sview', we refer to the view as
Note that when we usethe staff with the job title of 'Supervisor'.

generallydefinedby membersof

L0.L.L Data Requirements

(1) Each branch of DreamHome has staff who are dedicated to the manage-
ment of property for rent. The staff work in groups that are supervisedby a
Supervisorand supportedby a Secretary.

(2) The information storedon eachbranch office includes a unique branchnum-
ber, address(street,area,city, postcode),telephonenumber,and fax number.

(3) The information held on all membersof staff includesa staff number,name
(first and last name), address,telephonenumber, sex, date of birth (DOB),
job title, and the number and addressof the branch office at which they
work. Additional information held on staff with the job title of Secretaryis
their typing speed.The staff number is unique acrossall branchesof the
DreamHome comparry.

(4) Each Supervisorsupervisesthe day-to-day work of a group of staff (min-
imum 5 to a maximum of 10 membersof staff, at any one time).

(5) A portfolio of property for rent is available at each DreamHome branch.
Each property for rent is managedby a particular member of staff. A mem-
ber of staff may manage a maximum of 10 properties for rent at any one
time. The information stored on each property for rent includes: the prop-
erty number, address(street, area,crty, postcode),tyP€, number of rooms,
monthly rent, and the name and addressof the property owner. The monthly

10.1 TheSupervisor'Rs equirementSspecificationgOT

rent for a property is reviewed annually. Most of the properties rented out
by DreamHome are flats. Each property is owned by a single owner.

(6) The details of owners of property are also stored.There are two main types
of property owner: private owners and business owners. The information
stored on private owners includes: the owner number, name (flrst and last
name), address,and telephonenumber. The information storedon business
ownersincludes:the owner number,nameof businessb, usinesstype,address,
telephonenumber, and contactname.Each owner owns at leastoneproperty.

(7) The staff responsiblefor the managementof property for rent must undertake
the following activities:

(a) To ensurethat property is rented out continuously.

This may require placing an advert describing a property for rent in an
appropriate newspaper.The information stored on each advert includes the
advert number, the date the advert was placed in the newspaper,the name of
the newspaper,the cost, and some details of the property including the
property number, type, and address.The advert number is unique acrossall
DreamHome branches.The information stored on each newspaperincludes
the newspapername, address,telephonenumber, fax number, and contact
name. Properties are only advertised in the newspapersif they prove diffi-
cult to rent out.

lul ro set up interviews with clients interestedin renting property.
The information storedas a result of eachinterview includesthe daie of the
interview and any general comments about the client. During the interview,
the detailsof clients are also collected.However, someclients do not attend
an interview and simply provide their details by telephone or on their first
visit to a DreamHome branch office. The information stored on clients
includesthe client number,name (first and last name),current address,tele-
phone number, and some information on the desiredproperty, including the
preferredtype of accommodation,and the maximum rent the client is prepared
to pay. The client number is unique acrossalrDreamHomebranches.

(c) To encourageclients to view propertiesfor rent.

The information stored includes the client's number, name, and telephone
number, the property number and address,the date the client viewed the
property, and any comments made by the client regarding the suitability, or
otherwise,of the property. A client may view the sameproperty only once
on a given date.

(d) To organize the lease agreementbetween a client and a property.
Once a client agreesto rent a property, a leaseagreementis organized,bya
member of staff. The information on the lease includes the lease number.
the client number, and name, the property number, address,type and number
of rooms, the monthly rent, method of payment,deposit(calculatedas twice
the monthly rent), whether the deposit is paid, the date the rent period starts
and finishes,and the durationof the lease.The leasenumberis uniqueacross
aIl DreamHomebranches.A client may hold a leaseagreementassociatedwith
a given property for a minimum of three months to a maximum of 1 year.

(e) To carry out inspectionsof property on a regular basis to ensurethat
the property is correctly maintained.

308 ConceptuaDl atabaseDesignMethodolog-y WorkedExample

Each property is inspectedat least once over a six month period. However,
DreamHome staff only carry out inspections of property that is currently
being rented or is available for rent. The information stored on the inspec-
tion includes the property number, and address,date of the inspection,the
name of the member of staff who carried out the inspection, and any com-
mentson the condition of the property.

10.1.2 Transaction Requirements

The main transactionsrequired by Supervisorsinclude:

(a) Producea list of staff supervisedby a Supervisor.
(b) Producea list of staff supportedby a Secretary.
(c) Producea list of Supervisorsat eachbranch'
(d) Create and maintain records recording the details of property for rent and

the owners at eachbranch.
(e) Producea report listing the detailsof property (including the rental deposit)

at eachbranch.
(f) Producea list of propertiesmanagedby a specific member of staff.
(g) Createand maintain recordsdescribingthe detailsof clients at eachbranch.
(h) Producea list of clients registeredat eachbranch.
(i) Searchfor propertiesthat satisfy various criteria.
U) Create and maintain records holding the details of viewings of properties

madeby clients.
(k) Producea report listing the commentsof clientsconcerninga specificproperty.
(l) Create and maintain records detailing the adverts placed in newspapersfor

properties.
(m) Producea list of al1advertsfor a specificproperty.
(n) Producea list of all advertsplacedin a speciflcnewspaper.
(o) Create and maintain records describing the details of lease agreements

betweena client and a ProPertY.
(p) List the details of the leaseagreementfor a specificproperty.
(q) Createand maintain recordsdescribingthe detailsof inspectionsof properties.
(r) Producea list of all inspectionsof a specific property.

10.2 Using the Conceptual Database Design Methodology

Step 1 Build Local ConceptualData Model of the
Supervisor'sView

To begin building the local conceptualdatamodel for the Supervisor'sview of the
DreamHome casestudy, we must first identify the various component parts of the

10.2 Usingthe conceptuaDl atabaseDesignMethodology309

model describedin the requirementsspecification.The componentsof the data
model include:

. Entity types.
o Relationshiptypes.
. Attributes.
. Attribute domains.
o Candidatekeys.
. Primary keys.

Step1.1 ldentifu entity types

We begin by identifying the main entity types in the requirementsspecification
(Section10.1.1).Entities are normally presentas noun or noun expressionsF. rom
the requirementsspecification,the major entities identified include:

Branch Advert
Staff Newspaper

Supervisor Interview

Secretary Client
Property_for_Rent Lease_Agreement

Private_Owner Inspection

Business_Owner

Document entity types

We documentthe details of theseentity types by providing a fuller descriptionof
tehaechenetnittyityt,yipnediscuactihngasw'hEeathcherparloiapseertsyahreaus saeds,inagnlde
describing the occurrenceof
provided as Appendix 10.1 of this chapter. owner'. This information is

Step1.2 ldentifu relationshipepes

We next identify the major relationshiptypes that exist betweenthe entities.Relation-
shipsarenonnally presentasverb or verb expressionsW. e look againat the require-
ments specificationto identify potential relationshipsbetween entities. The main
relationshipsidentifled in the requirementsspecificationare shown in Table 10.1.

If we examinethe relationshipslisted in Table 10.1we can, in somecases,
identify relationshipsthat are obviously the same.For example,the two relation-
ship types Staff Su-Pervy;edBSyupervisorand SupervisorSupirvises Staff represent
the samerelationship.This relationshipis listed twice in Table 10.1as the r^equire-
mentsspecificationdetailedthis relationshipfrom both the Staff andthe Supervisor's
viewpoint.

It is important that we closely examinethe Supervisor'srequirementsspeci-
fication to ensurethat we have identified all the relationshipsthaiwe wanr ro rep-
resentin the Supervisor'slocal conceptualmodel. If there is uny ambiguity in the
specificationregarding a relationship,we must clarify the situation with the user.

3 1 0 Conc ept ualDa tab a s eD e s i g n Me th o d o l o g y- W orked E xampl e

Table 10.1 The major relationshipsidentifiedin the Supervisor'srequirementsspecification.

Entity type Relationshiptype Entity type

Branch Has staff
Staff
Manages Property_for_Rent
Supervisor SupervisedBy Supervisor
Property_for_Rent SupportedBy Secretary
SetsUp Interview
Private_Owner Organizes Lease_Agreement
Business_Owner CarryOut Inspection
Advert
Interview Supervises staff
Client
IsAvailableAt Branch
Lease_Agreement ManagedBy Staff
Inspection OwnedBy Owner

Owns Property_for_Rent

Owns Property_for_Rent

Describes Property_for_Rent
Placedln Newspaper

With Client
Views Property_for_Rent
Rents Property_for_Rent
Holds Lease_Agreement

AssociatedWith Property_for_Rent

MadeOf Property_for_Rent

Determine the cardinality and participation constraints of relationship types
We next determinethe cardinality and participation constraintsfor each relation-

ship type identifiedin Table 10.1.
The cardinality constrainton a relationshipis specifiedas being either one-

to-one(1:1),one-to-many(1:M) or many-to-many(M:N). If known, specificvalues
for the cardinality, or evenupperor lower limits, shouldbe noted.We alsoidentify
the participationof eachentity in a relationshipaseithertotal or partial. Most of the
information that describesthe cardinality and participation of each relationshipis
detailedin the requirementsspecificationshown in Section 10.1.1.However, if
theseconstraintscannotbe unequivocallydeterminedfrom the Supervisor'srequire-
ments specification,we must approachthe user for clarification of the situation.

Listed below are some examplesof how we may determinethe cardinality
and participation constraintsfor the relationshipslisted in Table 10.1.

Branch Flas Staff In the requirementsspeciflcation,this relationshipis described
as 'Each branchof DreamHomehas staff ...'.In other words,a singlebranchhas
many staff, and thereforethe cardinality of this relationshipis 1:M. As everybranch
has staff, the participation of Branch in the Has telationshipis total.

To fully understanda relationship,we also examine theHas relationship from
the direction of Staff WorksAt Branch direction. The requirementsspecification

10.2 Usingthe ConceptuaDl atabaseDesignMethodology311

Figure10.1 The
Branch Has Staff
relationship.

doesnot explicitly describethe WorksAlrelationship,and we thereforeask the user
the following question:

Question: Doeseachmemberof staffwork at only onebranch?

Answer: Yes.

The answerto this questionindicatesthat a singlememberof staff WorksAta single
branchand thereforethis relationshiphas a 1:1 cardinality ratio. As all membersof
staff are allocatedto a branch,the participation of the Staff entity in the WorksAt
relationshipis total.

We may refer to the relationshipbetweenthe Staff and Branch entities as
eitherBranch Has Staff or Staff WorksAtBranch. However, when we representthis
relationshipin an Entity-Relationship (ER) model, we display only the higher ratio,
that is 1:M. It is thereforemore appropriateto name this relationship in the l:M
direction, namely, Branch Flas Staff. The cardinality and participation constraints
on the Branch Flas Staff relationshipare shownin Figure f O.f. fo improve a user's
comprehensionof an ER model, it is important that we adopt a consistentapproach
to naming entities and relationships.

Property- for-Rent ManagedBy Staff In the requirementsspecification,this rela-
tionship is describedas 'Each property for rent is managedby a particular member

of staff'. This indicates that the cardinality of the Property_for_RentManagedBy

Staffrelationshipis 1:1.

We must also considerthe Property_for_RentManagedByStaff relationship

from the direction of Staff ManagesProperty-for_Rent.Although the requir"-"trtt

specificationdoes identify the Manages relationship,we are still uncertain about

certain characteristicsof the relationshipbetweenthe Staff and Property_for_Rent

entities,and we are required to ask the user the following questions:

Question(a): Do all membersof staffmanageproperty?

Answer (a): No. Not all membersof staff areresponsiblefor the management
oI property.

Question(b): How manypropertiesareassociatewdith thosestaffresponsiblfeor
themanagemenotf property?

Answer (b): A memberof staffmaymanageup to a maximumof 10properties,
at any one tlme.

Question (c): Are propertiesassociatedwith a member of staff, at all times?
Answer (c):
No. There are occasionswhen a property is not specificallyallocated
to a member of staff, such as when the property is first registered
with the company or when a property is not availablefor rent.

This information has clarified the precise relationship between the Staff and
Property-for-Rent entities. The cardinality ratio for the Staff Manages Property_for_
Rent relationship is 1:M, as a single member of staff manages many properties.
Furthermore, we also know that the upper limit for the 'Many' side of this relationship

3 1 2 Conc ept ualData b a s eD e s i g n M e th o d o l o g y- W orked E xampl e

Figure10.2 The
Staft Manages
Property_for_Rent
relationship.

Figure10.3 The
Property_for_Rent
DescribedlnAdveft
relationship.

is set at 10. In other words, a single member of staff can manageup to a max-
imum of 10 propertiesat any one time. Although this information can be displayed
on an ER diagram, suchdetail may over-complicate a diagram. We thereforesimply
record this maximum value in the data dictionary.

Basedon the answersto Questions(a) and (c), we know that both the Staff
and Property_for_Rententities partially participate in the Manages relationship.
This is determinedfrom the facts that not all membersof staff areresponsiblefor the
managementof property, and not all propertiesare allocatedto a member of staff.

The cardinality and participationconstraintsfor the relationshipbetweenthe
Staff and Property_for_Rent entities are shown in Figure I0.2. The Staff Manages
Property_for_Rentrelationshipdisplaysthe higher cardinality 1:M and is giventhe
name that is appropriatein the 1:M direction.

Advert DescribesProperty_for_Rent In the requirementsspeciflcation,this rela-
tionship is describedas '. . . placing an advert describinga property for rent in an
appropriatenewspaper'.As a single advert describesa single property, the cardinality
of the Describesrelationshipis 1:1. If we considerthe Describesrelationshipfrom
the direction of Property_for_Rent,we note that the Property_for_RentDescribedln
Adverl is not explicitly specifiedin the Supervisor's requirementsspecification.
However, after consultationwith the user,we learn that a single property may be
associatedwith many adverts, and therefore the cardinality of the Describedln
relationshipis 1:M. Following the naming convention,we identify the relationship
as Property_for-Rent D escrib edln Adveft.

The participationof the Advert entity in the Describedlnrelationshipis total,
as the pu{poseof an advert is to describea property. However, Property-for-Rent
only partially participatesin this relationship, as the Supervisor's requirements
specification statesthat properties are advertisedonly if they prove difficult to
rent out. The cardinality and participation constraints for the Property-for-Rent
Describedln Advert relationshipare shown in Figure 10.3.

Client ViewsProperty_ for_Rent In the requirementsspecification,this relationship
is describedas '. . . clientsto view propertiesforrent. . .'. We clarify the character-
istics of this relationshipwith the users,and learn that a single client Viewsmany
properties(1:M) and a single property is ViewedBymany clients (1:M). Therefore,
the cardinality of the Viewsrelationshipis M:N. We shouldnote that the ViewedBy
relationship is not explicitly describedin the Supervisor'srequirementsspecifica-
tion. In a M:N relationship,we may selecteither the Views or ViewedByrelation-
ship name. We selectto use the simpler of the two names,that is Client Views
Property_for_Rent. To determine the participation of Client and Property-for-Rent
in the Views relationship,we must ask the usersthe following questions:

10.2 Usingthe ConceptuaDl atabaseDesignMethodology319

Figure 10.4 The
Client Views
Property_for_Rent
relationship.

Question (a): Does every client view property?

Answer (a): No. Some clients only registeran interestwith the company but do
not go on to view property.

Question (b): Is every property viewed by clients?
Answer (b): No' some properties are registered with the company but are not

viewed by clients.

Basedon the answersto thesequestions,we determinethat the participationof both
Client and Property-for-Rent in the Views relationship is pariial. Tire cardinality
and participation constraints for the Client Views Property_for_Rent relationship
are shown in Figure 10.4.

Use Entity-Relationship modeling

49 we attempt to understandhow the entities relate to one another through their
relationships,it is often easierto visualize the situation as an Entity-Relatlonship
(ER) diagram.We thereforepresenta sketchof an ER model to repiesentthe main
entities and relationshipsdescribedin the Supervisor'srequire*entr specification,
as shownin Figure 10.5.However,it is assumedthat throughoutthe conceptualdata-
basedesignprocess,the designeris constantlyusing ER diagrams,when required.
Note that all the 1:M relationships display names that are u-pepiaromppriluet,ein
the 1:M direction. In some cases,the relationshipsare renamed.For
the
InspectionOf Property-for-Rent (M:1) relationshipis renamedProperty_for_Rent

UndergoesInspection(1:M), and Property-for_RentIsAvailableAtBranch (M:1) is
renamed Branch Offers Property_for_Rent (1:M).

Document relationship types
We documentthe detailsof the relationshipsshownin Figure 10.5,andthis informa-
tion is provided as Appendix I0.2 of this chaprer.

step 1.3 ldentify and associate attributes with entity or
relationship epes

We now identify attributesthat may be presentas nouns (or their expressions)in
the Supervisor'srequirementsspeciflcation.An attributemay describesomeaspect
of an entity or relationship.In carrying out this step we must be aware of cases
where attributesappearto be associatedwith more than one entity or relationship
type as this may indicate the following.

(1) We have identified several similar entities. For example, the Supervisor
and Secretary entities sharethe sameattributes as the Staff entity, with the
exception of the Typing-Speed attribute,which is associatedonly with the
Secretaryentity. At this stage,we simply note that theseentitieshave com-
mon attributes.

314 ConceptuaDl atabaseDesignMethodolog-y WorkedExample

Figure 10.5 Sketchof (2) We have identified relationshipsbetweenentity types.In this case,we must
the Supervisor'slocal associatethe attribute(s)with only the parent entities, and ensurethat the
conceptuadl ata model relationshipswere previously identifled in Step t.2. It this is not the case,
of the DreamHome the documentation should be updated with details of the newly identifled
case study. relationships. For example, the property number and property addressattri-
butes are describedin the Supervisor'srequirementsspecificationin associ-
ation with the Property, Advert, Lease-Agreement and Inspection entities
and the Viewsrelationship.At this stage,we simply associatethe attributes

10.2 U s i n g the C onceptualD atabaseD esi gn Methodol ogy gl S

with the parent entity, namely Property and ensurethat relationshipshave
been identified betweenProperty and the other entities and relationshipin
T a b l e1 0 . 1 .

The ilttributesare associatedwith their respectiveentity or relationship,as shownin
Tables10.2(a)and ft).

Document attributes

We documentthe details of the attributeslisted in Tables IA.2@)and (b). For each
attributewe provide a description,datatype and length,constraintsd, efaultvalues
(if any), aliases(if any), whetherthe attributeis composite,derivedor multi-valued,
and whether nulls are allowed. A part of this documentationis provided as Appen-
dix 10.3of this chapter.

Step 1.4 Determine attribute domains

In this step,we determinethe domains for the attributesin the Supervisor'slocal

conceptualdata model of the DreamHome company.A domain is a pool of values

from which one or more attributesdraw their values.For example,the Branch_No

attribute of the Branch entity has a domain that includes a three-characterstring,

with valuesranging from B1 to B99. Also, the Sex attribute of the Staff entity is a
sing l ec h a r a c t e rc o n s i s t i n go f ei ther' M' or 'F' .

An exampleof a domain that is sharedby many attributesis the domain that

holdsvaluesfor addressesT.he Addressattributesof the Staff,Client,Private_Owner,

Business-owner,and Newspaperentitiessharethe samedomain.

Documentattribute domains

Some of the domainsfor the attributesof the Supervisor'slocal conceptualdata
model are describedin Appendix 10.4of this chapter.

step 1.5 Determine candidate and primary key attributes

Identify candidate keys and choosea primary key
We now examineTable 10.2(a),andidentify ali possiblecandidatekeysfor eachentity
in the Supervisor'slocal conceptualdatamodel.From thecandidatekeys,we selectthe
most appropriateprimary key fbr eachentity. For example,the Lease_Agreement
entity hastwo candidatekeys,Lease-No and (Property_No,Rent_Start).The candid-
atekey with the minimal setof attributes,namely,Lease_No,is selectedasthe prim-
ary key for the Lease-Agreemententity. The other candidatekey, namely (Property_
No, Rent-Start), is referredto as the alternatekey for the Lease_Agreemenet ntity.

For eachentity, we identify the primary key andwhereavailableany altern-
atekeys,as shownin Table 10.3.

In this step,we cannot assignprimary keys for weak entities as their exist-
ence is dependenton their owner (parent) entities. Therefore, primary keys for
weak entities are identified in Step 2.2 as part of the processof deriving relations
from the ER model to represententities and their relationships.

For example, the Interview and Inspection entities do not have primary
keys, and are therefore weak entities. The primary keys of theseentities can be
identified only when we map the weak entity and its relationshipwith the owner
entity to a relation, through the placementof a foreign key in that relation.

3 1 6 Conc ept ualDa tab a s eD e s i g n Me th o d o l o g y- W orked E xampl e

Table 10.2(a) Attributes associatedwith entities.

Entity type Attribute

Branch Branch_No
Staff Address (Street,Area, City, Postcode)
Tel_No
Supervisor Fax_No
Secretary
Property_for_Rent Sraff_No
Name (FName and LName)
Private_Owner Address
Business_Owner Tel_No
Sex
Advert DOB
Newspaper Job_Title

Interview (Sameattributesas the Staff entity)
Client
(Sameattributesas the Staff entity)
Typing_Speed

Property_No
Address (Street,Area, City, Postcode)
Type
Rooms
Rent

Owner_No
Name (FName and LName)
Address
Tel_No

Owner_No
BName
BType
Address
Tel_No
Contact_Name

Advert_No
Date_Advert
Newspaper_Name
Cost

Newspaper_Name
Address
Tel_No
Fax_No
Contact_Name

Interview_Date
Comments

Client_No
Name (FName and LName)
Address



318 ConceptuaDl atabaseDesignMethodolog-yWorkedExample

Document keys
We document the attribute(s) that representthe primary and alternatekeys for each
entity in Appendix 10.3 of this chapter.

Step 1.6 Specialize/generalize entity types (optional step)

In this step, we have the option to enhancethe ER model using the processof
specializationor generchzationon the entities(identifiedin Step 1.1).If we takethe
specializationapproach,we attempt to highlight differencesbetween entities.On
the other hand, if we take the generulization approach, we attempt to identify
common featuresbetweenentities.

For example, in Figure 10.5, Supervisor and Secretaryare representedas
distinct entities. The decision is whether we want to generalizetheseentitiesinto
subclassesof a Staff superclassor leave them as separateentities.

As shown in Table I0.2(a), all the attributesincluding the primary key of
the Staff entity are representedin the Supervisor and Secretary entities. Further-
more, the Supervisorentity does not have any additional attributes.The Secretary
entity has only one additional attribute,namely Typing_Speed.However, both the
Supervisorand Secretaryentities are associatedwith distinct relationships:Super-
visor SupervisesStaff and the SecretarySupportsStaff. Basedon this information,
we chooseto generahzethe Supervisorand Secretaryentities.We representthese
entitiesassubclasseosf the Staff superclassT. he relationshipthat the Staff superclass
has with its subclassesis partial and disjoint, as a memberof staff cannotbe botha
Supervisorand a Secretary,and also somemembersof staff do not hold the position
of Supervisoror Secretary.This representationis particularly useful for displaying
the sharedattributesassociatedwith Supervisor,Secretaryand Staff, as shownin
Figure 10.6.

An additional example to consider is the relationship between ownersof
property for rent. The Supervisor'srequirementsspecificationdescribestwo types
of owner: Private_Ownerand Business_Owner.Basedon the information given in
Tables10.1and 10.2(a),we notethat theseentitiessharesomeattributes(Owner_No,
Address, and Tel_No) and have the samerelationshrp(Owns Property_for_Rent),
as shown in Figure 10.5. However, there are also attributesthat are speciflcto
Private_Owner (FName and LName) and Business_Owner(BName, BType, and
Contact_Name).Therefore,the entities representdifferent types of owners.

We chooseto generahzethe Private_Ownerand Business_Ownerentities
based on the commonality of attributes and the shared Owns relationship.We
thereforerepresentthe Private_Ownerand Business_Ownerentitiesas distinct sub-
classesof a superclasscalled Owner. The relationship that the Owner superclass
has with its subclassesis total and disjoint, as an owner must be either a private
owner or a businessowner, but cannot be both. This representationis particularly
useful for displaying the sharedattributesassociatedwith the Private_Ownerand
Business_Ownerand the sharedOwns relationship,as shown in Figure 10.7.

Although the examplesgiven in this sectionare relatively straightforward,
we shouldnote that the processof generalizationcan be takenfurther. For example,
Staff, Supervisor,Secretary,Private_Ownerand Client are personswith common
attributes(FName,LName, Address,andTel_No). Although thereareno strict guide-
lines concerningthe speciahzattonlgeneralizationprocess,it is important to represent

Usingthe ConceptuaDl atabaseDesignMethodology319

Figure 10.6 The Staff
superclassand the
Supervisoar nd
Secretarysubclasses.

Figure10.7 The
O w n e rs u p e r c l a s sw i t h
the Private_Ownear nd
Business_Owner
subclasses.

320 ConceptuaDl atabaseDesignMethodolog-y WorkedExample

Figure10.8 The the important entities and relationships as clearly as possible in a data model.
S u p e r v i s o r ' sl o c a l Therefore, the degreeof specializationlgenerahzationdisplayed in a diagram should
conceptuadl ata model be guided by the readability of the diagram and the clarity with which it models
of the DreamHome important entitiesand relationshipsfound in the 'real world'. With this in mind, we
case study. do not representa Personsuperclassin the ER model.

Exercises 321

Step 1.7 Draw Entity-Relationship diagram

To help visualize the main entities and relationshipsdescribedin the Supervisor's
requirementsspecification,we redraw the ER diagram (Figure 10.5), as shown in
Figure 10.8.This ER diagram and the documentationcreatedin Step 1 is referredto
as the Supervisor'slocal conceptualdata model of the DreamHome casestudy.

Note that, although we use the concept of generalization/specializationof
entities,which is associatedwith EnhancedEntity-Relationship(EER) modeling,we
continue to refer to the models presentedin this chapterand chapters11 and 12 as
ER models for simplicity.

Step I.B Review local conceptual data model with user

Before completing Step 1, we must review the local conceptualdatamodel with the

user(s). If any errors are discovered,we must make the appropriatechangesby
astsebpesi.Wngeare'ptreuaet'thriespprreosceenstsautinotnilotfhtehuesSeruispeprrveipsaorre'sdvtoiew'sigonf
returningto previous
off ' the data model

DreamHome.

The secondphaseof the methodologythat describeslogical databasedesign
for the relationalmodel is illustratedby examplein Chapter11.The conceptualdata-
basedesignfor the Supervisor'sview and the Manager's view of theDreamHome

casestudy createdin this chapterand Chapter5, respectively,areusedasthe starting
point for Chapter11.

EXERCISES

Tlne Wellmeadows Hospital case study
10.1 Identify user views for the Medical Director and Charge Nurse in the

WellmeadowsHospital casestudy, describedin Appendix A.

10.2 List users' requirementsspeciflcationfor each of theseviews.

10.3 Createlocal conceptualdata models for each of the user views. State any
assumptionsnecessaryto support your design.

322 ConceptuaDl atabaseDesignMethodolog-yWorkedExample

Appendix 1.0.1 DocumentEntity T}pes for the Supervisor's
View of the DreamHomeCaseStudy

Entity name Description Aliases Occurrence

Branch Place of work Offlce and One or more DreamHome branchesare
Branch located in main cities throuehout the UK
Office

Staff General term describing all staff Each member of staff works at a particular
employedby DreamHome branch

Supervisor Supervisesthe work of staff Each branchhas severalSupervisors.
responsiblefor the management Each Supervisorsupervisesa specific
of property for rent group of staff (min 5 and max 10
members of staff, at any one time)

Secretary Responsiblefor providing Each branch has several secretaries.
secretarial support to staff Each secretaryprovides support to a
specific group of staff

Property_for_Rent Generalterm describins all Each property has a single owner.
property for rent Each property is available at a specific
branch, where the property is managed
by a member of staff. Each property is
rented by a single client, at any one
time. Each property is viewed by clients
and inspectedby staff

Private Owner Private owner of property for rent Owner Each private owner owns one or more
properties for rent

Business_Owner Businessowner of property for Owner Each businessowner owns one or more
rent properties for rent

Advert Describesa property for rent A single advert describinga single
property is placedin a newspaper

Newspaper Contains advertsdescribins Propert es are describedin adverts,
property for rent placed n local and national newspapers

Interview A meeting to assessthe suitability Staff interview clients wishing to rent
of potential clients to rent property. Not all clients are interviewed
property. Also to note the
property requirementsof client

Client Generalterm describingall clients A single client may rent one or more
interestedin viewing and renting properties at any given time
property

Lease Asreement Containsdetails of the lease Lease Each leaseagreementis held by a single
agreementbetween a client and client for a single property
a pfoperty

Inspection Contains details of property Property Each inspectionis carried out by a singie
inspectioncarried out by staff
Inspection member of staff on a single property

A p p e n d i x' 1 0 . 2 DocumenRt elationshiTpypesfor the supervisor,Vs iew g2g

Appendix 10.2 Document Relationship Tlpes for the Supervisor's
View of the DreamHome CaseStudv

Entity type Relationship type Entity type Cardinality ratio Participationl
Branch
Has Sraff 1:M T:T
Staff Offers T:T
Property_for_Rent 1 : M
Supervisor P:P
Secretary Manages Property_for_Rent 1:M P:T
Property_for_Rent SetsUp Interview 1:M P:T
CarryOut Inspection 1:M P:T
Private_Owner Organizes Lease_Agreement 1:M
Business_Owner T:P
Newspaper Supervises Staff 1:M
Interview T:P
Client Supports Staff 1:M
P:T
Property_for_Rent Describedln Advert 1:M P:T
Undergoes Inspection 1:M P:T
AssociatedWith Lease_Agreement 1:M
T:T
Owns Property_for_Rent 1 : M
T:T
Owns Property_for_Rent 1 : M
T:T
Lists Advert 1:M
T:P
With Client 1:1 P:P
Views Property_for_Rent M:N P:P
Rents Property_for_Rent M:N P:T
Holds Lease_Agreement 1:M
P:T
Undergoes lnspection 1:M

I P representspartial participation and r representstotal participation.

324 ConceptuaDl atabaseDesignMethodolog-y WorkedExample

Appendix 10.3 Document Attributes for the Supervisor's View of the
DreamHome CaseStudvt

Entity Namesof attributes Description Data type and length

Branch Branch_No Uniquely identifies branch office 3 variable character
Address Address (composedof Street,Area,
City, and Postcode attributes) 25 variable character
Street Streetof branch address 15 variable character
Area Area of branch address 15 variable character
City City of branch address
Postcode Postcodeof branch address 8 variable character
Tel_No Telephone number of branch 13 fixed character
Fax_No Fax number of branch 13 fixed character

staff Staff_No Uniquely identifies a member of staff 5 variable character
Name Staff name (composedof FName
and LName attributes) 15 variable character
FName First name of staff 15 variable character
LName Last name of staff 50 variable character
Address Full home addressof member of staff 13 fixed character
Tel_No Home telephonenumber of staff
Sex Genderof staff 1 fixed character
DOB Date of birth of staff Date
Job_Title Job title of staff 20 variable character

Supervisor Sameas the Staff Identifies a member of staff with the (Sameas Staff entity)
entity type job title 'Supervisor'
(Sameas Staff entity)
Secretary SameAS the Staff Identifies a member of staff with the
entity type and job title 'Secretary' Integer
Typing_Speed Typing speedin words per minute
5 variable characters
Property_for_Rent Property_No Uniquely identifies eachproperty
Address Address (composedof Street,Area, 25 variable characters
City, and Postcodeattributes) 15 variable character
Street Street of property address 15 variable character
Area Area of property address
City City of property address 8 variable character
Postcode Postcodeof property address I character
Type Type of property Integer
Rooms The number of rooms in a property
(excluding bathroom) Currency
Rent The monthly rent

T Only part of the data dictionary for the Supervisor'sview is shown.

A p p e n d i x1 0 . 3 DocumenAt ttributesfor the Supervisor,Vsiew g2S

Constraint Default value Alias Null value (Yesor No?) Derived?
Primarykey No No

Alternate key No No
Alternate key No No
Primarykey No No
Yes No
(Sameas Staff entity) No No
(Sameas Staff entity) No No

No No

No No
No No
No No
Yes No
No No
Yes No
Yes No

(Sameas Staff entity) (Sameas Staff entity)

(Sameas Staff entity) (Sameas Staff entity)

Primary key No No

F (for flat) No No
4 Yes No
600.00 No No
Yes No
No No
Yes No

Yes No

3 2 6 Conc ept uaiDa tab a s eD e s i g n Me th o d o l o g y- W orked E xampl e

Appendix 10.4 Document Attribute Domains for the Supervisor's
View of the DreamHome Company (examples)

I)ttniuitt ttttttte D onnin characte ri stic.c Examplesof allowable values

P t - ( - r prft \ r _ N o 5-charactervariablelength string P A 1 4 ,P L 9 4 , P G 4
S1i'cct 25-charactevr ariablelength string 2 ManorRd, 5 NovarDr
j'ei_No and Fax*No l3-charactervariableiength string 0| 4l -339-4439,01224-61| | 1
Sex 1-charactesrtring('M' or 'F') M,F
Rotlit-r-s Integervaiue (range1 to 15) 5 , 8 ,1 2