Data Management Design

DBMS and Designing for RDBMS

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

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

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

Conceptual Schema

Internal Schema

The view on data used by application programs

The logical model of data that is separated fromHow it is used

The physical storage of data in files and indexes

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

DBMS Features (2)

• Concurrency– 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

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

Integrating Application and Database Modelling

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

Types of DBMS – RDBMS (2)

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

• 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

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

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

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

Example: InternationalCampaign Objects

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

1NF Table for InternationalCampaign Objects

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

2NF Table for InternationalCampaign Objects

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)

3NF Table for InternationalCampaign Objects

Entity-Relationship Diagram

Class Diagram for InternationalCampaign

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

Mapping Entity Classes to Relational Tables

Mapping Associations (1)

Mapping Associations (2)

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

Mapping Aggregations (1)

Mapping Aggregations (2)

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

Mapping Generalisations (1)

Implement all Classes as Separate Tables

Implement the Superclass as a Table

Implement each Concrete Subclass as a Table

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

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