15-From Class Relationships To Relational Tables

Converting class relationships
into relational tables, Using UML

V3.0
November 2015
Ferreiras.
Ferreiras 1
Introduction
• All approach exposed in this work is from the Object-Oriented paradigm; So, the
reader must have some basic knowledge of OOT ( Object-Oriented Technology), UML
notation, and, also, of Relational SQL;
• I will be working with the following approach:
• A Conceptual Model, which represents the UML Class Diagram obtained from the
domain of the problem statement given, is used as starting point;
• A Logic Model, as an UML Class Diagram, is used as a bridge towards the

Relational Model; This Logical Model must have resolved all the class relationships
Much-to-Much , the inheritance , aggregation, composition, and recursive
relationships, which are shown in the Conceptual Model and also must show the ID
chosen to be used for identify uniquely the objects of each class;
• A UML Relational Model is used for each class in the Logical Model;
• The CREATE TABLE SQL statement will be written for implementing each table in
the Relational Model.
Ferreiras 2
Introduction
• The class relationships converted to relational model in this work are:
• 1-1 Relationship
• 1-M Relationship
• M-M Relationship
• Inheritance
• Aggregation
• Composition
• Recursive
• Implementation tends to vary based on the SQL statements of the target RDBMS; I will be using
Derby.
• In the simplest model a class from the logical model maps to a relational table, either in whole or
in part. The logical extension of this is that a single object (or instance of a class) maps to a single
table row.
• In the UML Data Profile, a table is a class with the <<table>> stereotype. I will be using this UML
notation.
Ferreiras 3
Introduction
• The Conceptual UML Class Diagram for a given problem statement should capture the
information requirements correctly;
• After we represent the class in the UML Logical Model as a set of tables and Primary
and Foreign Keys ( the UML Relational Model) we must look at each table and see
whether it is normalized (at least until the 3NF);
• The data model is great for the big picture, and normalization is great for the finer
details; Both tools must be used to ensure that the best structure of the database is
gutted.
Ferreiras 4
Introduction
Problem statement given:
A local sports club wants to keep the information of its members

and the equipment in which they are currently playing (Senior B,
Junior A, Veterans, etc.); Not all members of the club are in a
team; In addition, the club wants to keep records of the name of
each team and its corresponding captain; The captain must be a
member of the club; A team can not have more than one captain.
Ferreiras 5
1-1 Relationship
• For the problem statement given, consider the UML Logical Model which shown
below.
Member Team
- memberID : long <<ID>> 1..1 0..1 - teamID : long <<ID>>
- memberFirstName: String - teamName : String
is captain of
- memberLastName: String teamCaptainFirstName : String
teamCaptainLastName : String
{UML Class }
{UML Class }
Ferreiras 6
1-1 Relationship
• The UML Relational Model for each class in the Logical Model will be as shown below.
Members Teams
<<table>> <<table>>
memberID : BIGINT <<PK>> teamID : BIGINT <<PK>>
memberFirstName: VARCHAR(15) teamName : VARCHAR(20)
memberLastName: VARCHAR(15) teamCaptainFirstName : VARCHAR(15)
{UML Relational Model } teamCaptainLastName : VARCHAR(15)
memberID : BIGINT <<FK>>
{UML Relational Model }
Ferreiras 7
1-1 Relationship
• The corresponding CREATE TABLE SQL statements will be as shown below:
CREATE TABLE Members
(
memberID BIGINT NOT NULL,
memberFirstName VARCHAR(15) NOT NULL,
memberLastName VARCHAR(15) NOT NULL,
PRIMARY KEY(memberID)
);
CREATE TABLE Teams
(
teamID BIGINT,
teamName VARCHAR(20),
teamCaptainFirstName VARCHAR(15),
teamCaptainLastName VARCHAR(15),
memberID BIGINT,
PRIMARY KEY(teamID),
FOREIGN KEY(memberID) REFERENCES Members(memberID),
CONSTRAINT UNIQUE_CAPTAIN UNIQUE(memberID)
); Ferreiras 8
1-1 Relationship
• We see, referring to the 1-1 relationship, that:
• Use a foreign key to the referenced table.

• These relationships do not arise very often.
• Each class becomes a table.
• The selection and location (on which end of the relationship) of a foreign key to
link the two tables should be made based on the information that needs to be
extracted from the tables, and the reality that represents the relationship; As is
shown in the before example, an UNIQUE constraint must be used to maintain
uniqueness for the field chosen as primary key.
• ...
Ferreiras 9
1-1 Relationship
• We see, referring to the 1-1 relationship, that:
• Is implemented taking the primary key field of one end of the relationship and
using it as a foreign key in at the other end.
• Sometimes either ends of the relationship can be used to link to the other class;
At other times you have to use UNIQUE in the table to clarify the relationship.
• Unique constraints are also a way to enforce 1-1 relationship between tables.
• Unique constraints enforce a 1-1 relationship by maintaining uniqueness for the

field chosen as primary key.
Ferreiras 10
1-M Relationship
• For the problem statement given, consider the UML Logical Model which shown
below.
Member Team
- memberID : long <<ID>> 1..N 0..1 - teamID : long <<ID>>
- memberFirstName: String - teamName : String
plays for
- memberLastName: String teamCaptainFirstName : String
teamCaptainLastName : String
{UML Class }
{UML Class }
Ferreiras 11
1-M Relationship
Members Teams
<<table>> <<table>>
memberID : BIGINT <<PK>> teamID : BIGINT <<PK>>
memberFirstName: VARCHAR(15) teamName : VARCHAR(20)
memberLastName: VARCHAR(15) teamCaptainFirstName : VARCHAR(15)
teamID : BIGINT <<FK>> teamCaptainLastName : VARCHAR(15)
{UML Relational Model } {UML Relational Model }
Ferreiras 12
1-M Relationship
CREATE TABLE Members
(
memberID BIGINT NOT NULL,
memberFirstName VARCHAR(15) NOT NULL,
memberLastName VARCHAR(15) NOT NULL,
teamID BIGINT,
PRIMARY KEY(memberID),
FOREIGN KEY(teamID) REFERENCES Teams(teamID)
);
CREATE TABLE Teams

(
teamID BIGINT,
teamName VARCHAR(20),
teamCaptainFirstName VARCHAR(15),
teamCaptainLastName VARCHAR(15),
PRIMARY KEY(teamID)
);
Ferreiras 13
1- M Relationship
• We see, referring to the 1-M relationship, that:
• Use a foreign key on the many side of the relationship linking back to the "one"
side.
• For a 1-Many relationship, the key field from the class at the 1 end is added as a
Foreign Key in the class at the Many end.
• Some time the UNIQUE constraint could be used for ensure the uniqueness in the
relationship.
• The relationship is implemented implicitly by copying the primary key from the
one-side of the relationship (Teams) into the table on the many side (Members).
• If the primary key of the one-side is a composite key, then all columns that
comprise the composite key are copied to the many side to become the foreign key.
• ...
Ferreiras 14
Many-Many relationship
• A Many-Many relationship can be converted replacing the M-M relationship by a new
class and two a-Many relationship;
• The many ends of the new relationships are always attached to the new intermediate
class .
• So, given :
ClassA ClassB
codeA   codeB
{UML Class } {UML Class }
Ferreiras 15
• In the Logical Data Model the relationship is converted as:
ClassA NewClass ClassB

codeA <<ID>> 1..1  codeA <<ID>>  1..1 codeB <<ID>>
codeB <<ID>>
{UML Class }
• The NewClass contain at least the codeA <<ID>> and the codeB<<ID>> as UID,
which serves as connector; Additional attributes may be added as needed.
• The intermediate class is required to store information about the problem which
has been initially overlooked.
Ferreiras 16
• When mapped to the Relational Model, the UID(codeA, codeB) in the NewClass will be
a compound PK in the which codeA and codeB will be FK referenced to table A and table
B, respectively.

<<table>> <<table>> <<table>>
codeA <<PK>> codeA <<PK>> << FK>> codeB <<PK>>
codeB <<PK>> << FK>>
{UML {UML
Relational {UML Relational Relational
Model } Model } Model }
•...
Ferreiras 17
• For example, a specific case:

<<table>> <<table>> <<table>>
codeA <<PK>> codeA <<PK>> <<FK>> codeB <<PK>>
codeB <<PK>> <<FK>>
{UML {UML
Relational {UML Relational Relational
Model } Model } Model }
•...
Ferreiras 18
• Example, consider the UML Conceptual Model which shown below.
Order Product
- orderNumber: long - productNumber : long
- orderDate : Date - productDescription : String
 
- orderAmount : int - productPrice : double
- deliveryDate : Date
- productQtyInStock: int
{UML Class }
{UML Class }
Ferreiras 19
• The UML Logical Model will be as shown below.
Order OrderLine Product

- orderNumber: long - orderNumber : long <<ID>> - productNumber : long
- orderDate : Date 1..1  - productNumber : long <<ID>>  1..1 - productDescription : String
- orderAmount : int
- productPrice : double - productPrice : double
- deliveryDate : Date
- productQuantity : int - productQtyInStock: int
{UML Class }
Ferreiras 20
M-M Relationship
Orders Products
<<table>> <<table>>
orderNumber : BIGINT <<PK>> productNumber : BIGINT <<PK>>
orderDate : DATE productDescription : VARCHAR(20)
orderAmount : INTEGER, productPrice : DECIMAL( 10, 2)
deliveryDate : DATE, productQtyInStock : INTEGER

Ferreiras 21
M-M Relationship
OrderLines
<<table>>
orderNumber : BIGINT <<PK>> <<FK>>
productNumber : BIGINT <<PK>> <<FK>>
productPrice : DECIMAL( 10, 2)
productQuantity : INTEGER
{For a better explication:}
PRIMARY KEY( orderNumber, productNumber),
FOREIGN KEY(orderNumber) REFERENCES Orders(orderNumber),
FOREIGN KEY(productNumber) REFERENCES Products(productNumber)
Ferreiras 22
M-M Relationship
CREATE TABLE Orders

(
orderNumber BIGINT,
orderDate DATE,
orderAmount INTEGER,
deliveryDate DATE,
PRIMARY KEY(orderNumber)
);
Ferreiras 23
M-M Relationship
CREATE TABLE Products

(
productNumber BIGINT,
productDescription VARCHAR(20),
productPrice DECIMAL( 10, 2),
productQtyInStock INTEGER,
PRIMARY KEY(productNumber)
);
Ferreiras 24
M-M Relationship
CREATE TABLE OrderLines

(
orderNumber BIGINT,
productNumber BIGINT,
productPrice DECIMAL( 10, 2),
productQuantity INTEGER,
PRIMARY KEY( orderNumber, productNumber),
FOREIGN KEY(orderNumber) REFERENCES Orders(orderNumber),
FOREIGN KEY(productNumber) REFERENCES Products(productNumber)
);
Ferreiras 25
M-M Relationship
• We see, referring to the M-M relationship, that:
• Primary keys are identified for each class.
• Use a junction table.
• By converting a M-M relationship the Cyclical reference is prevented.
• By convention, the name of this join table is usually, not necessarily, just the
combination of the two tables of the many-to-many relationship. which implies that
this is a join table since it’s using the name of two existing tables joined by an
underscore.
• This join table only contains the primary keys from the Orders and Products
tables. Since this join table is referring to primary keys that don’t actually belong to
the join table, they are actually referred to as foreign keys; Sometimes it’s useful to
assign a primary key column to a join table
• Relationship data are stored in the intersection table.

Ferreiras 26
M-M Relationship
• We see, referring to the M-M relationship, that: ...
• The relationship is implemented by creating a table (OrderLines) to represent the

relationship symbol. This is known as a linking table or intersection table.
• A primary composite key for the intersection table is composed of the primary
key from both entities that participate in the relationship.
• ...
Ferreiras 27
M-M Relationship
• Because the OrderLine class link two classes, Order and Product, it is also calle a
linking class.
• The relational table OrderLines (also called linking table) is the implementation of
a composite class.
• In addition to the linking attributes, the linking class can also contain such
relevant attributes as the productPrice and the productQuantity. In fact, a
composite class (table) can contain any number of attributes that the designer
wants to track. Keep in mind that the composite class, although implemnted as an
actual table, is conceptually a logical class that was created as a means to an end:
To eliminate the potential for multiple redundancies in the original M-M
relationship.
Ferreiras 28
M-M Relationship
• Additional attributes may be assigned as needed in the linking class. In this case,
productPrice and the productQuantity is selected to satisfy a reporting
requirement.
• Also note that the OrderLines table´s primary key consists of the PK of Order and
Product respectively because both of them are needed to define a particular
Product in a Order.
• The linking class must contain at least the primary keys of the class Order and
Product ( orderNumber and productNumber ), for which it serves as a connector.
Ferreiras 29
M-M Relationship
• The linking table (OrderLines) contains multiple occurrences of the FK values, but
those controlled redundancies are incapable of producing anomalies as long as
referential integrity is enforced.
• You can increase the amount of available information even as you control the
database´s redundancies.
• While controlling redundancies we make sure that all of the data common to
each Product is kept in the Order table.
Ferreiras 30
Inheritance relationship
• Example, consider the UML Conceptual Model which shown below.
Person
- personID : long
- personLastName : String
- personFirstName : String
{UML Class }
Professor Student
- profesorSalary - studentDegree
Ferreiras 31
Inheritance relationship
Person
- personID : long <<ID>>
- personLastName : String
- personFirstName : String
{UML Class }
is a 1..1 1..1 is a
0..1 0..1
Professor Student
- profesorSalary - studentDegree
Ferreiras 32
Inheritance Relationship
Persons
<<table>>
personID: BIGINT <<PK>>
personLastName : VARCHAR(20)
personFirstName : VARCHAR(20)
Ferreiras 33
Professors Students
<<table>> <<table>>
personID : BIGINT <<PK>> <<FK>> personID : BIGINT <<PK>> <<FK>>
profesorSalary : DECIMAL(6,2) studentDegree : DECIMAL( 4, 2)
Notice how personID is used as the PK for both tables. For the Profesors
and Students tables personID is both a PK and FK. Here FK it is used to
maintain the relationship to the Person table. This is indicated by
application of two stereotypes, <<PK>> and <<FK>>. I
Ferreiras 34
CREATE TABLE Persons

(
personID BIGINT,
personLastName VARCHAR(20),
personFirstName VARCHAR(20),
PRIMARY KEY(personID)
);
Ferreiras 35
CREATE TABLE Professors

(
personID BIGINT,
profesorSalary DECIMAL(6,2),
PRIMARY KEY(PersonID),
FOREIGN KEY(PersonID) REFERENCES Persons(PersonID)
);
Ferreiras 36
CREATE TABLE Students

(
personID BIGINT,
studentDegree DECIMAL( 4, 2),
PRIMARY KEY(PersonID),
FOREIGN KEY(PersonID) REFERENCES Persons(PersonID)
);
Ferreiras 37
• We see, referring to the Inheritance Relationship, that:
• Each class in the hierarchy was mapped to its own table.
• Base class gets a table, and then child classes get their own tables with just the
additional fields they introduce, plus foreign key references to the base table.
• The data for the Professor class is stored in two tables, Professors and Persons,
therefore to retrieve this data you would need to join the two tables (or do two
separate reads, one to each table).
• The data for the Student class is stored in two tables, Students and Persons,
therefore to retrieve this data you would need to join the two tables (or do two
separate reads, one to each table).
Ferreiras 38
• We see, referring to the Inheritance Relationship, that: ...
• The application of keys is interesting. Notice how personID is used as the

primary key for all of the tables. For the Professors and Students tables the
personID is both a Primary Key and a Foreign Key. That is so used to maintain the
relationship with the Persons table. This is indicated by application of two
stereotypes, <<PK>> and <<FK>>.
• Inheritance provides the class model with a means of factoring out common
behavior into generalized classes that then act as the ancestors of many variations
on a common theme.
• Inheritance is a means of managing both re-use and complexity.
• the relational model has no direct counterpart of inheritance, which creates a

dilemma for the data modeler mapping an object model onto a relational
framework.
Ferreiras 39
• We see, referring to the Inheritance Relationship, that: ...
• Relational database do not have the concept of inheritance built into them;
However, it is possible to approximate the idea of inheritance.
• For inheritance (as an approximation), use a 1-1 “is a” relationship between the
Base and Derivate class.
• Note that with this approach we can capture multiple inheritance. For example,
a student who is a professor (Ferreiras is Professor of computer science and a
student of the School of Languages).
Ferreiras 40
Aggregation relationship
• Consider the UML Conceptual Model which shown below.
Order OrderItem
1..
orderID : long orderItemID : long
Ferreiras 41
Order OrderItem
1..
orderID : long <<ID>> orderItemID : long <<ID>>
Ferreiras 42
Orders OrderItems
<<table>> <<table>>
orderID: BIGINT <<PK>> orderItemID : BIGINT <<PK>>
orderID: BIGINT <<FK>>
Ferreiras 43
Composition relationship
• Composition is not the same as aggregation. While aggregation is identified as a
relationship in which a composite object (“whole”) consists of other component
objects (“parts”), composition has two additional constraints:
• Non-shareable. This is the case when objects of one class can only be
the part of one and only one object of other class.
• Treating this type as aggregation enables other classes to own the

“part” class and thus, violate the conceptual semantic.
• Existence-dependent. This is the case when objects of one class can

only exist with the existence of a object of another class.
• Treating this as aggregation will enable a “part” class to remain in

existence even though the “whole” class has been removed
Ferreiras 44
• The most common practice of implementing composition relationship is by
separating the “part” component in another table with composite PKs. This
practice only uses object-oriented paradigm for conceptual modeling. The
implementation is purely relational.
• Mapping method can be defined as a formal process of transforming a schema

level (such as conceptual schema) to another schema level (such as logical
schema) in a database system.
• A mapping method works effectively if the schema result is complied

with the requests. If the result schema does not preserve all semantics of
the requests, the mapping method is not effective .
• If the composition is implemented as separate tables, then the cascade of

deletes (ON DELETE CASCADE) must be addressed and implemented in the
physical DBMS.
Ferreiras 45
Faculty
University facultyID : long
1..1 1..
universityID : long facultyName : String
universityName : String
Please note that two separate tables are necessary because a Faculty could
be owned by a different University. That is, a given Faculty must always be
owned by exactly one University.
Ferreiras 46
UniversityFaculty
University facultyID : long <<ID>>
1..1 1..
universityID : long <<ID>> universityID : long <<ID>>
universityName : String {UML Class }
{UML Class }
1..
Please note that we are using 1..1

here a new class,
UniversityFaculty; Such class Faculty
contains the universityID and facultyID : long <<ID>>
attributes from University class
facultyName : String
and facultyID from Faculty class;
This is for resolving the {UML Class }
composition relationship;
Ferreiras 47
• The UML Relational Model is as shown below.
Universities Faculties
<<table>> <<table>>
universityID : BIGINT <<PK>> facultyID : BIGINT <<PK>>
universityName : VARCHAR(60) facultyName : VARCHAR(60)
Ferreiras 48
• The UML Relational Model is as shown below.
Two PK !! ?? , Not, that means that

there are two attributes which must UniversityFaculty
form a composite PK.
<<table>>
universityID : long <<PK>> <<FK>>
facultyID : long <<PK>> <<FK>> During implementation in a RDBMS,
Referential Actions (See page 77,
refderby ) for ON DELETE, delete rule
{For a better explication:} will must be CASCADE; Also,
NOT NULL will must be used.
PRIMARY KEY( universityID, facultyID)
FOREIGN KEY(universityID) REFERENCES University(universityID) ON DELETE CASCADE
FOREIGN KEY(facultyID) REFERENCES Faculty(facultyID)
{UML Class }
Ferreiras 49
• ...
UniversityFaculty
universityID (FK) , facultyID (FK), Because
... an university
... ... must...
NOT NULL, ON NOT NULL have at least a faculty.
DELETE CASCADE
1000 350
1000 450
1000 500
3000 350 ERROR!! Because
5000 500 unicersityID and facultyID
5000 350 combination must be unique;
1000 450 They form a composite PK.
Ferreiras 50
Recursive relationships
works for
1..1
manages
manager
Employee
employeeID : long 1..
employee
{UML class}
Ferreiras 51
works for
1..1
manages
manager
Employee
employeeID : long <<ID>> 1..
employee
{UML class}
Ferreiras 52
Employees
<<table>>
employeeID : BIGINT <<PK>>
managerEmployeeID : BIGINT <<FK>>
{For a better explication:}
FOREIGN KEY(managerEmployeeID ) REFERENCES Employees( employeeID),
Ferreiras 53
References
• Fundamentals of Object Databases: Object-Oriented and Object-Relational Design
(Synthesis Lectures on Data Management); Suzanne W. Dietrich,Susan D. Urban;
Morgan & Claypool Publishers, 2011.
• Beginning Database Design; Clare Churcher; Apress, 2007.
• Mapping Objects To Relational Databases; Scott W. Ambler,

http://www.agiledata.org/essays/mappingObjects.html
• Object-oriented database systems: Concepts and perspectives; Rainer Unland,

Gunter Schlageter; Springer, 2005.
• Mapping objects to relational databases, PDF, Scott W. Ambler

http://www.ibm.com/developerworks/library/ws-mapping-to-rdb/ws-mapping-to-
rdb-pdf.pdf
• ...
Ferreiras 54

15-From Class Relationships To Relational Tables

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

15-From Class Relationships To Relational Tables

Hochgeladen von

Copyright:

Verfügbare Formate

Converting class relationships

into relational tables, Using UML

• I will be working with the following approach:

• A Logic Model, as an UML Class Diagram, is used as a bridge towards the

A local sports club wants to keep the information of its members

• Use a foreign key to the referenced table.

• Unique constraints enforce a 1-1 relationship by maintaining uniqueness for the

CREATE TABLE Teams

{UML Class } {UML Class }

ClassA NewClass ClassB

ClassA NewClass ClassB

ClassA NewClass ClassB

Order OrderLine Product

{UML Relational Model }

{UML Relational Model }

CREATE TABLE Orders

CREATE TABLE Products

CREATE TABLE OrderLines

• Primary keys are identified for each class.

• Use a junction table.

• By converting a M-M relationship the Cyclical reference is prevented.

• Relationship data are stored in the intersection table.

• The relationship is implemented by creating a table (OrderLines) to represent the

{UML Class } {UML Class }

{UML Class } {UML Class }

{UML Relational Model }

CREATE TABLE Persons

CREATE TABLE Professors

CREATE TABLE Students

• Each class in the hierarchy was mapped to its own table.

• The application of keys is interesting. Notice how personID is used as the

• Inheritance is a means of managing both re-use and complexity.

• the relational model has no direct counterpart of inheritance, which creates a

{UML Class } {UML Class }

{UML Class } {UML Class }

• Treating this type as aggregation enables other classes to own the

• Existence-dependent. This is the case when objects of one class can

• Treating this as aggregation will enable a “part” class to remain in

• Mapping method can be defined as a formal process of transforming a schema

• A mapping method works effectively if the schema result is complied

• If the composition is implemented as separate tables, then the cascade of

Please note that we are using 1..1

Two PK !! ?? , Not, that means that

{UML Relational Model }

• Beginning Database Design; Clare Churcher; Apress, 2007.

• Mapping Objects To Relational Databases; Scott W. Ambler,

• Object-oriented database systems: Concepts and perspectives; Rainer Unland,

• Mapping objects to relational databases, PDF, Scott W. Ambler

Das könnte Ihnen auch gefallen