Professional Documents
Culture Documents
Database Modeling in UML PDF
Database Modeling in UML PDF
+ getAge() : int
+ setAge(n)
+ getName() :
+ St i
setName(s)
A simple person class
with no state or Class operations:
behaviour shown the behaviour
A Person is composed of
a strict set of ID
0..n documents (having n
A Person may
reside at zero elements)
or more
addresses 0..1
Address Person ID Document
0..n 0..n
1 n
An Address may Three forms of the Aggregation relationship. The weak form is
have zero or depicted with an unfilled diamond head, the strong form
more Persons in (composition) with a filled head.
residence
Child
Grandchild
The Physical Model Grandparent
Parent
Person
UML also provides some mechanisms
for representing the overall physical
structure of the database, its contents
and deployed location. To represent a
physical database in UML, use a
stereotyped component as in the figure Mapping from the Class Model to
below: the Relational Model
Parent Child
PK_PersonID FK_PersonID
2 identifying 0..n
Parent tbl_Parent
A Parent class with unique ID (OID)
- OID: GUID and Name and Sex attributes maps to AddressOID: VARCHAR
# Name: String a relational table. Name: VARCHAR
# Sex: Gender PK OID: VARCHAR
Sex: VARCHAR
+ setName(String)
+ getName() : String
+ setSex(String) <<realises>>
+ getSex() : String
m_Address 0..n
The Address association from the logical model becomes
a foreign key relationship in the data model
1
Address
- OID: GUID
# City: String The Address class in the logical tbl_Address
# Phone: String model becomes a table in the City: VARCHAR
# State: String data model PK OID: VARCHAR
# Street: String Phone: VARCHAR
State: VARCHAR
+ getCity() : String Street: VARCHAR
+ getStreet() : String
+ setCity(String) <<realises>>
+ setStreet(String)
An OID always refers to the same More complex class attributes (ie.
entity - no matter what other those which represent other classes),
information changes. In the above are usually modelled as associations.
example, a customer may change name An association is a structural
or address and the related tables relationship between objects. For
require no change. example, a Person may live at an
Address. While this could be modelled
When mapping object models into as a Person has City, Street and Zip
relational tables, it is often more attributes, in both the object and the
convenient to implement absolute relational world we are inclined to
identity using OID's rather than structure this information as a separate
business related primary keys. The entity, an Address.
OID as primary and foreign key
approach will usually give better load In the object domain an address
and update times for objects and represents a unique physical object,
minimise maintenance effort. In possibly with a unique OID. In the
practice, a business related primary relational, an address may be a row in
key might be replaced with: an Address table, with other entities
having a foreign key to the Address
1. A uniqueness constraint or index primary key.
on the columns concerned;
2. Business rules embedded in the In both models then, there is the
class behaviour; tendency to move the address
3. A combination of 1 and 2. information into a separate entity. This
helps to avoid redundant data and
Again, the decision to use meaningful improves maintainability.
keys or OID's will depend on the exact
requirements of the system being So for each association in the class
developed. model, consider creating a foreign key
from the child to the parent table.
6. Map attributes to columns
Relationships are based on the PK- FK pair. This example relates a Salesperson to a
Customer by the appropriate primary and foreign keys. The assumption is that a
customer may only be associated with one salesperson.
In addition, you may specify additional In the real world, the bottom line may
constraints (eg. {Not NULL}) on the be scaling to 100's or 1000's of
role and cardinality constraints (eg. transactions per second, something
0..n). stored procedures and triggers are
purpose designed for.
10. Model behaviour
If purity of design, portability,
We now come to another difficult maintenance and flexibility are the
issue: whether to map some or all class main drivers, localise all behaviour in
behaviour to the functional capabilities the object methods.
provided by database vendors in the
form of triggers, stored procedures, If performance is an over-riding
concern, consider delegating some
behaviour to the more efficient DBMS In UML, the physical model describes
scripting languages. Be aware though how something will be deployed into
that the extra time taken to integrate the real world - the hardware platform,
the object model with the stored network connectivity, software,
procedures in a safe way, including operating system, dll's and other
issues with remote effects and components. You produce a physical
debugging, may cost more in model to complete the cycle - from an
development time than simply initial use case or domain model,
deploying to more capable hardware. through the class model and data
models and finally the deployment
As mentioned earlier, the UML Data model.
Profile provides the following
extensions (stereotyped operations) Typically for this model you will
with which you can model DBMS create one or more nodes that will host
behaviour: the database(s) and place DBMS
software components on them. If the
! Primary key constraint (PK); database is split over more than one
! Foreign key constraint (FK); DBMS instance, you can assign
! Index constraint (Index); packages (schema) of tables to a
! Trigger (Trigger); single DBMS component to indicate
! Uniqueness constraint (Unique); where the data will reside.
! Validity check (Check).
Conclusion
schema
System
MainServer sys_aliases
sys_procs
sys_queries
sys_tables
sys_users
Database
MainOraDB
schema
User
Child
Grandchild
Grandparent
Parent
Person
A Node is a physical piece of hardw are (such as a Unix server) on w hich components are deployed. The
database component in this example is also mapped to tw o logical schema, each of w hich contains a
number of tables.
References
3. Assume each persistent class in the model will map to one relational table
5. For each class add a unique ID (OID) or select a suitable primary key
7. For each class, map complex attributes (association, aggregation) to PK/ FK pairs. Take
special note of the strong and weak forms of aggregation.
8. For related classes, map PK, FK pairs naming the role ends according to selected key.
9. Label relationship roles with their appropriate cardinality and stereotype: <<identifying>>
or <<non-identifying>>
10. Add stereotyped operations for table behaviour (keys, indexes, uniqueness, checks, and
triggers)
12. Create a deployment model and link database components to physical nodes