STUDENT COURSE I PROJECT
Chapter 3. Chapter 3. Data M odels
ULLNUMBER
I
INCIDENTs!i.!====;r=======-l...(S EVER I T 'Q
1
N OFFICERS
Figure 3.2 An
Entity-Relationship Diagram for part of a NavalDat
abase Description.
-52
•
•
Among the models where real life is described using entities, properties, values and relationhips, Chen's is the most general;
the only restriction is that relationships cannot themselves partake in relationships [Kershberg 1976]. It has however been criticised for not treating repeating attributes adequately and neglecting fWDs, and FDs between attributes [Shen 1978]. Whereas the concept of generalisation could be included, dynamics and integrity constraints are difficult to incorporate in a graphical model such as this. The concept of identifiers is also missing, but several authors such as Earnest [Earnest 1975] are of the
opinion that keys are neither necessary nor desirable.
An entity-attribute-relationship mode] which breaks with the idea of graphical representation is the TAXIS model [Mylopoulos 1980], which describes a database-state as a 7-tuple (T,C,M,DP,FP,->,=>).
T (Tokens) correspond to the values in the database such as
"Smith" or 6. C is a collection of classes (i.e. entity types), for example OFFICERS and SHIPS; while M stands for the collection of "Metaclasses" whose instances are classes - this corresponds to generalised classes. DP is the set of definition properties associated with a class or metaclass. The DP [OFFICERS, weight, Person-Weight] specifies that (meta)class OFFICERS has property
"weight" which maps it onto a Person-Weight value. FP is the collection of facts, such as ["Smith'', weight, 54]. -> is termed
"instance of'' and gives the association between a class and the generic concept of which it is an occurrence. Finally, => is the generalisation relation, eg. OILTANKERS => SHIPS. TAXIS has been extended to include dynamics. These take the form of "exceptions"
and "transactions", the latter allowing for the definition of variables, transaction preconditions, a transaction body and return values. An interesting aspect of this model is that
•
•
•
•
Chapter
3.
Data Models.-54
relationships are not directly represented as one of the seven criteria, but are included using definition properties. In this way they can be given role names and could include FD's and MVDs.
(It is not clear from the literature whether or not dependencies are part of TAXIS; since no reference to this has been found it is presumed that they are not treated) .
CSDL (a Conceptual Schema Definition Language) is actually a design tool for creating conceptual schemas [Roussopoulos 1979].
However, it incorporates a new type of
entity-attribute-relationship model that is of interest in its own right. This involves "concepts" (objects) and "frames"
(associations) that describe the characteristics and behaviour of an abstraction or situation. The semantic network model on which it is based consists of labelled, directed edges connecting nodes and subgraphs. Griffith [Griffith 1982] says "The existence of semantic networks is implied whenever information is conveyed in node-edge graphical form, where these nodes and edges are assigned meanings ... Often they are called entity/relationship diagrams".
In CSDL a label can be agent, object, source, destination, time, result, property of or argument of. An edge is labelled [all]
[nl
'
{n] or [n] to indicate how many concepts are involved in a mapping. Thus {n] means at most n, [nl at least n, etc.Generalisation can be applied to both concepts and frames, using operators such as union, intersection and set difference to create new concepts and conjunction, disjunction and negation to define new frames. Constants can be used in definitions, such as BASICCOURSE a particular type of COURSE where LANGUAGE is 'BASIC'.
Another important aspect of the CSDL model is that predicate calculus can be used instead of graphs, to define concepts and
•
frames. In this way a model designer can work in whichever manner he finds easiest, or use both methods. The non-mathematician would probably prefer the graphical version, but the problem there is that as the number of nodes grows, this becomes more awkward to use. A CSDL specification is shown in fig.3.3.
================================================================
concept MALESTU(X) derived
frame MALESEX [(X/STU, male/SEX.VALUE) SEX (property of: X,
value: male)]
frame ASSIGNMENT [(X/LECTURER~ [3} Y/COURSE, [all] Z/DEPTJ:
ASSIGN (agent:Z, object:LECTURER, destination: Y)]
frame ENROLLMENT= and (TEACH,RECEIVE.GRADE,<Z,Y>) Figure
3 ; 3
An example showing part of a CSDL model================================================================
This model can be seen to embody most of the features discussed earlier naming, role names (which can be applied to entities, attributes, or relationships), integrity assertions, semantic· relationships and generalisation. The latter is additionally powerful because it can be applied to associations as well.
Facilities that are not included are dependencies and dynamics, both of which are however of doubtful value because of their complexity and impermanence, respectively. It has been said that
"frames are not always a perfect fit to all instances of the pattern (assocation) involved. They cannot accomodate transient or unanticipated information and become obsolete if the actual patterns shift as time passes. Also, frames tend to be application oriented" [Griffith 1982]. Tsichritzis and Lochovsky claim that "Semantic networks are very rich data models in terms of concepts. This is a mixed blessing" becaus~ it complicates the
•
•
Chapter
3.
Data Models.model [Tsichritzis 1982].
Several other entity-attribute-relationship models have [Navathe
-56
been 1 978].
developed, such as that of Navathe and Schkolnik
This is an extension of Chen's model where a variety of associations are defined, each with special update characteristics to incorporate integrity constraints. Other examples are SDM, EDSM [King 1981, King 1982] and DIAL [Hammer 1978]. SDM incorporates generalisation and integrity assertions, as well as other concepts such as grouping entities. EDSM (the Event Database Specification Model) is an extension of SDM to include dynamics. This takes the form of "events" having "working subtypes" (input entities with conditions on their attributes) and an "action box" defining the operations that form the event. DIAL is also an extension of SDM and is similar to a program with two sections: a dat abase description ( in modified SDM) and a collection of procedures that op~rate on the database. SDM will be discussed in detail in the next chapter; hence its description is deferred until then .
3.2.3.
Binary relationship models.A binary relationship model is built on the concept of linking together two objects, which could be entities, attributes, relationships or values. Associations between more than two objects are spl it into several binary associations. Such a model is graphically represented with nodes for entities and attributes, connected by l inks representing relationships. A surprisingly large number of these models have recently been developed, probably because of the appealing simplicity of binary
•
•
relationships. Among the most well-known are those of Abrial, Grabowski and Eigner, Chang and Cheng, and Su and Lo [Abrial 1974, Grabowski 1979, Chang 1978, Su 1979].
In Abrial's model each connection is labelled functions" describing the asociation and its operator INV is used if the designer cannot find a
by "access inverse.
name for
The the inverse access function, thus somewhat reducing the difficulty of continually requiring names for all functions. An access function gives the minimum and maximum number of target elements e.g. SEX
=
(1 ,1), PERSONSOFSEX
=
(O,infinity), PARENTSLIVING=
(0,2) etc.Thus special relationships such as HAS-PARENTS can be explicitly stated to map to exactly two target entities, a facility not available in many other models. Although this model does not handle generalisation, FDs or MVDs, it does have the advantage that axioms and theorems have been developed to provide rules for
"well-defined" models. It does support semantic relations. Most of the constraints in the model are specified via operations which are similar to programming language constructs, using FOR loops,
• etc. This model has been criticised for not being sufficiently user-oriented [Tsichritzis 1982].
Grabowski and Eigner [Grabowski 1979] also base their model on binary relationships, which can be entity-entity,
entity-association or association-association. The these is to represent the meaning of an object relationship, the last to show access preference, relationship JOB before relationship JOBHISTORY.
second of within a eg. access
They are labelled 1:1,1 :n,n:n or n:1 and are also given a ''role" (either dependent - the t arget cannot exist unless linked to some source - or indpendent) and a set function. The latter governs the
•
Chapter 3. Data Models .
-58
compulsory This can ALL-ALL.
or optional nature of the association and its inverse.
be st ipulated as SOME-ALL, SOME-SOME, ALL-SOME or
Every entity must have at least one identifier.
which is given a definition range, can association. The model includes
refer to four types
An attribute, an entity or of integrity constraint and al so incorporates the concept
However, relationships are not named and
of generalisation.
neither are their inverses. Derived information is not catered for, and the model does not allow t he user much freedom of interpretation.
Database skeletons [Chang
1978]
are an extension of the directed graph model of Wang and Wedekind [Wang1975]
wher8 the links reperesent binary relationships. This model consists of two basic elements : attributes and relationships. These elements are described by contents rules (giving type, format and characteristic values) and semantic or functional relations, respectively. Associations can be attribute-attribute or attribute-relationship or relationship-relationship. Functional relations include key compatibility, full and functional dependencies, similarity (i.e. drawn from the same domain), subfile relation(i.e. one relationship can be decomposed into a collection of other relationships), set-type relation (essentially 1 ;many), hierarchical-type relation (basically many:many) and"leads to" (Ri l eads to Rj if a key of Ri belongs to Rj).
Semantic relations are analagous to "roles" in the
entity-relationship model : they give a meaningful name to a relationship. Propositional calculus is used to specify functional relations and contents rules. An example is given in fig.3.4. Except for dynamics and generalisations, this model
•
SHIP-INSPECTED
S.INSPCDATE
I. SNAME, I. IDATE
fd
SEVERITY O.COMMANDER
Figure 3.4 The database skeleton for part of a naval
database description.
Chapter 3. Data Models. -60
encompasses all the features described earlier. It is however not as easy to design database skeletons as it is to create other binary relationship models, chiefly because some of the functional relations are too complicated. The Semantic Association Model [Su 1979, Su 1981] involves networks of atomic concepts (character strings) and non-atomic concepts (associations between atomic concepts which can represent objects, relationships, types, subtypes, etc). This model also includes the specification of integrity assertions for each type of relationship. Several types of risemantic association" are supported, such as 'set relationship' which corresponds to generalisation, 'cause effect' to relate say VALID-CLAIM and INSURANCE-PAYMENT, 'action purpose' to associate say SALES-VIST and ADDING-CLIENT, etc. This model does not support FDs or MVDs, but is semantically rich in both its statics and dynamics.
The CAZ-graph introduced by Zaniolo and Melkanoff [Zaniolo 1982]
is also a binary relationship model. An example of a CAZ-graph is given in fig.3.5. CAZ-graphs comprise nodes representing attributes and edges representing relations. Relations of degree
N, N > 2,
attributes.
relation in
are represented by several arcs, each connecting two Each edge is labelled by a number indicating the which the attributes connected by that edge appear.
Edges have one arrow to indicate 1 :many, two arrows to indicate 1:1, and no arrows to indicate many:many relationships, respectively. To determine whether a relationship from an attribute A1 to A2 is 'to 1' or 'to many' in an N-ary relationship (N