1. Data Management Design
DBMS and Designing for RDBMS

2. Persistence
Persistent data is data that must be stored in a data storage system
it is data that must be stored after the program that creates or amends it has stopped running
it should usually be available to other users
Transient data is data that is created or used while the system is running but is not required after the system stops running

3. Storage of Persistent Data or Objects
Persistent data or objects may be stored in
– files
for storing data which is transferred to or from other systems configuration information
– database management systems (DBMS)
relational DBMS – hold tables of data
object DBMS – hold objects and links
the choice of DBMS will have an impact on the amount of work required of the system designers

4. Database Management Systems (DBMS)
In order to resolve data storage problems
analyse the storage requirements of all applications
use a database management system to organise and manage the data required by the different applications
The Three-schema architecture
External Schema
The view on data used by application programs
Conceptual Schema
The logical model of data that is separated from
How it is used
Internal Schema
The physical storage of data in files and indexes

5. DBMS Features (1) Data definition Language (DDL)
used to specify the data held in a DBMS and the structures that are used to hold it
Data manipulation language (DML)
used to specify updates and retrievals of data
Integrity constraints
Transaction management
if any of the component updates in a transaction do not succeed, the transaction is rolled back

6. DBMS Features (2) Concurrency Security Tuning of storage
many users may use the database simultaneously
Security
access to the database can be controlled
Tuning of storage
tools can be used to monitor the way that data is accessed and to improve the structures to make access more efficient

7. Advantages and Disadvantages of DBMS
+ Eliminates unnecessary duplication of data
+ Enforces data integrity through the use of constraints and transaction management techniques
+ Changes to the conceptual schema should not affect the application programs and changes to the internal schema should have no impact on the conceptual schema
+ Tools are available for tuning the performance of the database
– DBMS packages are costly
– Running costs involve paying staff to manage the DBMS
– Processing overhead in converting data from the database to the format required by application programs

8. Integrating Application and Database Modelling

9. Types of DBMS – RDBMS (1)
Relational database management systems (RDBMS)
eliminate redundancy (or duplication) from data
represent data in two-dimensional tables (or relations)
consist of rows of data organised in columns
each column contains data values of the same attribute type
the data in each row must be distinct
each attribute value must be atomic
all data structures must be decomposed into two-dimensional tables

10. Types of DBMS – RDBMS (2)

11. Types of DBMS – RDBMS (3)
Referential integrity constraints are used to model and maintainnrelationships between tables
by comparing primary key values in one table with foreign key values in another
a foreign key is a set of columns whose values are either NULL or match the values of the primary key in another (or same) table

12. Weaknesses of relational databases
objects in OO systems do not fit easily into this model
objects must be broken down into tables
this incurs a processing overhead
references to other objects must be maintained/restored
RDBMS are widely used
Access, Oracle, SQL Server, Informix, Ingres, MySQL

13. Types of DBMS (5) Object database management systems (ODBMS)
have been developed to handle complex, nested objects
multimedia applications
computer-aided design packages
Object-relational databases
combine the efficiency of relational databases with the ability of object databases to store complex objects

15. Designing for Relational Database Management Systems
If an RDBMS is used to provide storage for an OO system, it is necessary to flatten the classes into tables
complex objects must be taken apart and the parts stored in different tables
when the system requires an object, the data must be retrieved from the tables which hold parts of that object so that it can be reconstructed
Two approaches can be used to convert classes to tables
normalisation
a series of rules of thumb

16. Normalisation
Normalisation is based on the idea of functional dependency
for two attributes A and B, A is functionally dependent on B if for every value of B there is exactly one value of A associated with it at any given time: B →A
There are five normal forms of normalised data
the data is free of redundancy in fifth normal form
for practical purposes it is usually adequate to normalise data into third normal

17. Example: InternationalCampaign Objects

18. Table for InternationalCampaign Objects
Convert to first normal form (1NF)
a table is in first normal form (1NF) if and only if all row/column intersections contain atomic values
Multiple values are known as repeating groups

19. 1NF Table for InternationalCampaign Objects

20. Second Normal Form (2NF)
A candidate primary key in the previous table may be formed from the attributes campaignCode and locationCode
Convert the data in the previous table into second normal form (2NF)
a table/relation is in 2NF if and only if it is in 1NF and every nonkey attribute is fully dependent on the primary key
part-key dependencies
campaignTitle is dependent on campaignCode
locationName is dependent on locationCode

21. 2NF Table for InternationalCampaign Objects

22. Third Normal Form (3NF)
A relation is in third normal form (3NF) if and only if it is in 2NF and every attribute is dependent on the primary key and not on any other non-key attribute
in InternationalCampaign-2, locationMgrTel is dependent on locationMgr and not on the primary key (campaignCode and locationCode)

23. 3NF Table for InternationalCampaign Objects

24. Entity-Relationship Diagram

25. Class Diagram for InternationalCampaign

26. Rules for Mapping Classes to Tables (1)
The second approach involves using a series of rules of thumb to map classes and their relationships to tables in a RDBMS
Mapping entity classes
classes with a simple data structure become tables and their object identifiers become primary keys
Mapping associations
one-to-one or one-to-many associations are implemented by inserting a foreign key in one table to match the primary key of the other table
many-to-many associations are implemented using two separate tables for each object, as well as an intersection table
each row in the intersection table contains a pair of object identifiers, one from each object involved in the association

27. Mapping Entity Classes to Relational Tables

28. Mapping Associations (1)

29. Mapping Associations (2)

30. Rules for Mapping Classes to Tables (2)
Mapping aggregations
one-to-one composition
combine the subset and superset entity classes in a single table
one-to-one aggregation and one-to-many aggregation (and composition)
create two separate tables – one for the subset class and one for the superset class
the subset table should contain a foreign key which is equal to the primary

31. Mapping Aggregations (1)

32. Mapping Aggregations (2)

33. Rules for Mapping Classes to Tables (3)
There are three ways to map a generalisation hierarchy to relational database tables
implement all classes as separate tables
to retrieve data for a subclass both its own table and its superclass table must be accessed
implement the superclass as a table
attributes of subclasses become attributes of the superclass table
implement the concrete subclasses as tables
attributes of the superclass are held in the subclass tables
this only works if the superclass is abstract

34. Mapping Generalisations (1)

35. Implement all Classes as Separate Tables

36. Implement the Superclass as a Table

37. Implement each Concrete Subclass as a Table

38. Object Database Management Systems (1)
Object DBMS can store complex objects directly
The standard for object databases has been set by the Object Data Management Group (ODMG)
defines ODL (Object Definition Language) and OML (Object Manipulation Language)
not all ODBMS conform to the standard
Object DBMS are closely linked to the programming languages with ways of navigating through the database

39. Object Database Management Systems (2)
Object databases transparently materialise objects from the database into memory
Only minimal changes to the structure of the class diagram are required
ODBMS do not support the storage of operations in the database
except simple operations like inserting values or simple arithmetic