1. Mar 20, 200291.3913 R McFadyen1 Persistent Objects Persistent objects are objects that continue to exist after the application program terminates Persistence is provided by a DBMS ACID property “D” Two main categories OODBMS RDBMS Sections Intro, 34.1, 2, 4, 5, 6,7 8, 9, 16, 19

2. Mar 20, 200291.3913 R McFadyen2 Persistent Objects To use an RDBMS, we require an object to relational mapping service persistence service is a subsystem within the Technical Services Layer mismatch between record-oriented and object-oriented representations of data recommendation is to buy, not to build provides functions such as store, retrieve, modify, commit, rollback

3. Mar 20, 200291.3913 R McFadyen3 Key Ideas Mapping There are two schemas: object and relational. We need a mapping that translates from one to the other. Object Identity Records and objects have a unique identifier Materialization/Dematerialization need to be able to translate the non-object representation to an object representation, and vice versa Lazy Materialization Some objects are not materialized all-at-once; part of the object may be done first, and other parts later on

4. Mar 20, 200291.3913 R McFadyen4 Each class becomes a table Representing Objects as Tables pattern define a table for each persistent object class Some mappings are straight forward We require 1NF tables ClassAn objectThe table Many of these patterns mentioned come from a paper “Crossing Chasms: A Pattern Language for Object-RDBMS” published in 1996 in Pattern Languages of Program Design

5. Mar 20, 200291.3913 R McFadyen5 > stereotype We can indicate tables in UML using the stereotype: >

6. Mar 20, 200291.3913 R McFadyen6 OIDs Objects have an OID that is used as the PK in a relational table. Each object is uniquely mapped to a row in the table Object Identifier Pattern assigns an OID to each record and object

7. Mar 20, 200291.3913 R McFadyen7 Façade Persistence subsystem will have a Façade that provides access to its services façade Requesting a ProductSpecification with a specific OID

8. Mar 20, 200291.3913 R McFadyen8 Representing Relationships in Tables Representing Object Associations as Tables pattern one-to-one place an OID FK in one or both tables representing the objects in the association or, create an associative table that records the OIDs of each object in the association Consider StoreRegister houses 11

9. Mar 20, 200291.3913 R McFadyen9 Representing Relationships in Tables Representing Object Associations as Tables pattern one-to-many create an associative table that records the OIDs of each object in relationship Consider ProductCatalogProductSpecification contains 11..*

10. Mar 20, 200291.3913 R McFadyen10 Representing Relationships in Tables Representing Object Associations as Tables pattern many-to-many create an associative table that records the OIDs of each object in relationship CompanyPerson employs **

11. Mar 20, 200291.3913 R McFadyen11 Representing Relationships in Tables Representing Object Associations as Tables pattern many-to-many AND with an Association Class create an associative table that records the OIDs of each object in relationship... CompanyPerson employs ** Employment

12. Mar 20, 200291.3913 R McFadyen12 Representing Relationships in Tables Representing Object Associations as Tables pattern many-to-many AND with an Association Class create an associative table that records the OIDs of each object in relationship... Person marries * * Marriage

13. Mar 20, 200291.3913 R McFadyen13 Representing Relationships in Tables Representing Object Associations as Tables pattern Aggregation and Composition... SaleSalesLineItem contains 1..* ProgrammeCourse contains 1..* *

14. Mar 20, 200291.3913 R McFadyen14 Representing Relationships in Tables Representing Object Associations as Tables pattern Superclass/Subclass... Payment CreditPaymentCashPaymentChequePayment

15. Mar 20, 200291.3913 R McFadyen15 Transactional States Persistent objects can be inserted, updated, deleted Transactions are committed or rolled back Consider as states for a persistent object : New, OldClean, OldDirty, OldDelete, and Deleted Figure 34.12 helps us understand how and when a persistent object can be in a certain persistent state. This is useful if you need to design/code this capability, or perhaps to help you evaluate a package providing this service

16. Mar 20, 200291.3913 R McFadyen16 Transactional States New an object is created in the application, but does not exist in the database yet OldClean When a new object is committed, or when an object is first materialized from the database it is old and it is clean (hasn’t been altered by an application) OldDirty When an object that is represented in the database is modified by an application, it is considered dirty (it has values that are not the same as those in the database copy)

17. Mar 20, 200291.3913 R McFadyen17 Transactional States OldDelete When an object that is represented in the database is deleted by an application it is considered deleted, but this is not permanent yet (the transaction has not committed) Deleted An object is considered deleted when the application that deleted it is committed.

18. Mar 20, 200291.3913 R McFadyen18 Transactional States - Fig 34.12 modified This statechart diagram is a succinct representation of the states that an object may be in.