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 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

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 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

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