Databases Reference
In-Depth Information
Participant
Name
Address (number, street,
city, country)
Phone(s)
{disjoint}
Lecturer
PhDs
Rank
Student
RNumber
Degree
University
PhDProgram
Name
Departments
(MilanoD,
RJCD)
1..*
0..*
{ordered}
0..*
1..1
Topic
Name
KWords
PHours
THours
Credits
University
1..1
1..1
Essay
Name
KWords
Credits
FCourse
TCredits
SCourse
TCredits
DDelivery
1..*
1..*
Figure 7.4
Conceptual schema in UML notation.
Class
Participant (
extent
participants)
{
attribute
string (30) name;
Participant
attribute
struct
address {char (3) number,
char (20) street, char (15) city,
char (15) country};
Name
Address (number,
street, city, country)
Phone(s)
attribute
set
participant
drop
string (10)
phone;
<
>
void
(); //constructor
void
(); //destructor };
Figure 7.5
Class definition in ODL.
database schema, we assume that all classes are persistent classes. Each UML
interface is translated into an ODL interface.
Each attribute is translated as an attribute. If it is a multivalued attrib-
ute, such as phone, it will be translated as a collection type (a list if the order is
relevant). If it is a composed attribute, such as the address, it will be translated
as a structure. Section 7.6.2.5 gives some recommendations about when to
use each collection type or when to use the structure type.
The
database
constraints
(UNIQUE,
NOT
NULL,
CHECK,
ASSERTION,
and
TRIGGER
in
SQL)
are
represented
in
UML
as
