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 Mar 20, 2002 91. 3913 R Mc. Fadyen 1
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 Mar 20, 2002 91. 3913 R Mc. Fadyen 2
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 Mar 20, 2002 91. 3913 R Mc. Fadyen 3
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 1 NF tables Class An object The 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 Mar 20, 2002 91. 3913 R Mc. Fadyen 4
<<Table>> stereotype We can indicate tables in UML using the stereotype: <<Table>> Mar 20, 2002 91. 3913 R Mc. Fadyen 5
OIDs Object Identifier Pattern assigns an OID to each record and object 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 Mar 20, 2002 91. 3913 R Mc. Fadyen 6
Façade Persistence subsystem will have a Façade that provides access to its services façade Requesting a Product. Specification with a specific OID Mar 20, 2002 91. 3913 R Mc. Fadyen 7
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 Store Mar 20, 2002 1 1 houses 91. 3913 Register R Mc. Fadyen 8
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 Product. Catalog Mar 20, 2002 1 1. . * contains 91. 3913 Product. Specification R Mc. Fadyen 9
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 Company Mar 20, 2002 * * employs 91. 3913 Person R Mc. Fadyen 10
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. . . Company * * employs Person Employment Mar 20, 2002 91. 3913 R Mc. Fadyen 11
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 Mar 20, 2002 Marriage * marries 91. 3913 R Mc. Fadyen 12
Representing Relationships in Tables Representing Object Associations as Tables pattern Aggregation and Composition. . . 1. . * Sale Programme Mar 20, 2002 contains * 1. . * contains 91. 3913 R Mc. Fadyen Sales. Line. Item Course 13
Representing Relationships in Tables Representing Object Associations as Tables pattern Superclass/Subclass. . . Payment Cash. Payment Mar 20, 2002 Credit. Payment 91. 3913 R Mc. Fadyen Cheque. Payment 14
Transactional States • Persistent objects can be inserted, updated, deleted • Transactions are committed or rolled back • Consider as states for a persistent object : New, Old. Clean, Old. Dirty, Old. Delete, 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 Mar 20, 2002 91. 3913 R Mc. Fadyen 15
Transactional States New an object is created in the application, but does not exist in the database yet Old. Clean 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) Old. Dirty 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) Mar 20, 2002 91. 3913 R Mc. Fadyen 16
Transactional States Old. Delete 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. Mar 20, 2002 91. 3913 R Mc. Fadyen 17
Transactional States - Fig 34. 12 modified This statechart diagram is a succinct representation of the states that an object may be in. Mar 20, 2002 91. 3913 R Mc. Fadyen 18
Скачать презентацию Persistent Objects Persistent objects are objects that continue
46773f6be1dbedacde6eca02a159a029.ppt