Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Object-Oriented Databases (chapter 2/3) Course outlines Object Persistence - Introduction Persistent Programming Languages Specifying Object Persistence via Naming and Reachability Persistent Objects – Storage and Access issues Persistent C++ Systems Object Persistence – Using database The ODMG Standard for Object Databases OODBMS Features, OODB Evolution, Strategies for building OODBMS ODMG Object Database Standard, and Components An Architecture for OODBMS Object Model Object Definition Language (ODL) Mapping Class Diagrams into ODL Example - Reconsider the University schema… Annex - DB Evolution and History Object Persistence - Introduction One of the most critical tasks that applications have to perform is to save and restore data Persistence is the storage of data from working memory so that it can be restored when the application is run again In object-oriented systems, there are several ways in which objects can be made persistent Object Serialization - Simple persistence method which provides a program the ability to read or write a whole object to and from a stream of bytes Using Databases The choice of persistence method is an important part of the design of an application 2 Persistence of Objects Persistent Programming Languages The concepts of object orientation can be incorporated into a programming language that is used to manipulate the database. Object-relational systems – add complex types and object-orientation to relational language. Persistent programming languages – extend object-oriented programming language to deal with databases by adding concepts such as persistence and collections. Persistent Programming languages allow objects to be created and stored in a database, and used directly from a prog-language allow data to be manipulated directly from the programming language (no need to go through SQL). No need for explicit format (type) changes format changes are carried out transparently by system Without a persistent programming language, format changes becomes a burden on the programmer (more code to be written, more chance of bugs) allow objects to be manipulated in-memory - no need to explicitly load from or store to the database Drawbacks of persistent programming languages Due to power of most programming languages, it is easy to make programming errors that damage the database. Complexity of languages makes automatic high-level optimization more difficult. Do not support declarative querying as well as relational databases 3 Persistence of Objects Specifying Object Persistence Approaches to make transient via Naming and Reachability: objects persistent include establishing Naming Mechanism: Assign an object a unique persistent name through which it can be retrieved by this and other programs. Reachability Mechanism: Make the object reachable from some persistent object. Declare (root) persistent objects; objects are persistent if they are referred to (directly or indirectly) from a root object. An object B is said to be reachable from an object A if a sequence of references in the object graph lead from object A to object B. In traditional database models such as relational model, all objects are assumed to be persistent. Root In OO approach, a class declaration specifies only the type and operations for a class of objects. The user must separately define a persistent object of type set (StudentSet) or list (StudentList) whose value is the collection of references to all persistent STUDENT objects A B Object B is reachable from A and from Root 4 Persistence of Objects - How to find objects in the database? Persistent Objects – Storage and Access issues Object Identity and Pointers A persistent object is assigned a persistent object identifier. Permanence of identity – identity persists throughout program executions and structural reorganizations of data; required for object-oriented systems. In O-O languages such as C++, an object identifier is actually an in-memory pointer. Persistent pointer – persists beyond program execution; can be thought of as a pointer into the database Storage and Access of Persistent Objects Name objects (as you would name files) Cannot scale to large number of objects. Typically given only to class extents and other collections of objects, but not objects. Expose object identifiers or persistent pointers to the objects Can be stored externally. All objects have object identifiers. Store collections of objects, and allow programs to iterate over the collections to find required objects Model collections of objects as collection types Class extent - the collection of all objects belonging to the class; usually maintained for all classes that can have persistent objects. 5 Persistence of Objects Persistent C++ Systems C++ language allows support for persistence to be added without changing the language Declare a class called Persistent-Object with attributes and methods to support persistence Overloading – ability to redefine standard function names and operators (i.e., +, –, the pointer deference operator –>) when applied to new types Template classes help to build a type-safe type system supporting collections and persistent types. Providing persistence without extending the C++ language is relatively easy to implement but more difficult to use Persistent C++ systems that add features to the C++ language have been built, as also systems that avoid changing the language 6 Persistence of Objects Object Persistence – Using database Most Client-Server applications use a RDBMS as their data store while using an object-oriented programming language for development Objects must be mapped to tables in the database and vice versa Applications generally require the use of SQL statements embedded in another programming language Goal of object-oriented design is to model a process Goal of relational database design is normalisation The mapping from objects to tables can be difficult if the model contains complex class structures large unstructured objects object inheritance The resulting tables may store data inefficiently, or access to data may be inefficient Refer to the annex There are essentially three approaches which have been developed for the management of object storage in databases: the Object-Oriented Database Management System (OODBMS) the Object-Relational Database Management System (ORDBMS) Object Relational Mapping 7 The ODMG Standard for Object Databases Advanced Database Technologies Advanced Database Technologies OODBMS Features Object data model – object identifiers, type inheritance, methods, complex objects Integration with an OO programming language – transparent or semi-transparent retrieval and storage of objects Declarative query language – usually an SQL like syntax Advanced data sharing – long transactions; optimistic concurrency; multiple versions of data; private data check-out Client-server architecture 9 Advanced Database Technologies OODB Evolution Programming Languages Persistent Programming Languages DB Evolution and History Databases Extended Relational Systems e.g. UniSQL, Oracle,Illustra OODB OOPL add db facilities e.g. C++, Smalltalk -> ObjectStore, Gemstone,POET Model based systems add language facilities to a new data model. RDBMS Semantic Data Models e.g. ER, UML, FDM e.g O2, ODMG 10 Strategies for building OODBMS Extend OO programming languages to be persistent popular approach programming viewpoint rather than a database one no standard model; one programming language; ObjectStore, POET, Gemstone Use an object-oriented data model for the DBMS database management viewpoint need language bindings query languages, transaction management etc O2, lambda-DB Standardization of model and services ODMG 3 Standard; OMG (CORBA) 11 Object Database Management ODMG Object Database Standard Group, formed 1991 The Object Database Management Group is an industry consortium aimed at standardizing object-oriented databases, is intended to: provide a standard where previously there was none support portability between products standardize model, querying and programming issues Enables both designs and implementations to be ported between compliant systems Currently on version 3.0, and 3.0 (which is ODMG-2.0 plus extensions to Java) Vendors: Object Design,Objectivity, O2 Technology, POET, etc. URL: www.odmg.org 12 ODMG Object Database Standard ODMG Components An architecture for OODBMS. An object model. that will act as the logical model for all OODBMS and provide a level of interoperability. A data definition language (ODL). A concrete specification of the operations permitted over a schema defined in the data model. A query language (OQL). for posing ad-hoc queries but not for data definition or data manipulation. Language bindings to existing OOPL, (C++, Java, Smalltalk). the object manipulation languages are the integration of a PL with the ODMG model, so the OOPL’s get persistence and the OODB gets a flexible and standard DB programming language. 13 ODMG Components - Architecture An Architecture for OODBMS Declaration in ODL or PL ODL Application Source code in PL using ODMG language binding Declaration Pre-Processor PL Compiler ODBMS Runtime Application Binary Metadata Linker Database Data Access Running Application 14 ODMG Components – Object Model Object Model 1. Data Model state and structure of data 2. Behaviour model dynamics of the data operations on the data Object identity Complex objects Types and classes Inheritance hierarchies Encapsulation Late binding/overriding Extensibility Completeness 3. Persistence model the way the persistent and transient data is created & changes status 4. Naming model naming and accessing objects 15 ODMG Components – Object Model Object Model - Object Identity An object’s unique identifier maintained throughout the object’s lifetime Not user visible System generated An object has an existence independent of its value (identity vs equality) thus implying object sharing object updating supports referential integrity Objects can be cyclic A The composition graph is an object network D B C E 16 ODMG Components – Object Model ODMG Model supports databases... Built-in structured types which permit traditional database modelling to be used Objects and Literals (atomic and complex) Relationships and Attributes Transactions nested transactions, where transaction semantics only apply to persistent data Databases built-in object types for databases, schemas and sub-schemas Persistence lifetime of object specified when created Names handles by which persistent information can be accessed 17 ODMG Components – Object Model Objects, Literals and Mutability Objects Carole are addressed through an object identifier name address are instances of classes age are packaged structures can be shared house 21 will be stored separately—the oid will be street stored in the containing structure properties have different levels of visibility new operations can be user-defined for name Ian classes address mutable (components can be updated but it age remains as the same object) 47 can be arranged into hierarchies 3 Arcacia Ave 18 ODMG Components – Object Model Objects, Literals and Mutability Literals do not have an identity: are addressed by a physical address are instances of types are simple structures are not shared will be embedded in any containing structure properties are all public no methods can be defined against types immutable (the value is the identity, so if one of the components change its a different value) can’t be arranged into hierarchies name address age name address age Ian house 3 street Arcacia Ave 47 Carole house 3 street Arcacia Ave 21 19 ODMG Components – Object Model Complex Objects Atomic built-in literal types: long, short, unsigned long, unsigned short, float, double, string, boolean, char, any, octet The simplest objects are made up of these atomic types Complex objects are built from simple ones by applying type constructors which can be nested Type constructors collections record structures 20 ODMG Components – Object Model Collections (1/2) Supports both collection objects and collection literals set unordered, no duplicates bag unordered, duplicates list ordered, elements can be inserted array ordered, elements can be replaced dictionary maps keys to values enumerations (explicitly listed group of values, “Mr”, “Ms”) Collection objects Set<t>, Bag<t>, List<t>, Array<t>, Dictionary<t,v> Collection literals set<t>, bag<t>, list<t>, array<t>, dictionary<t,v> Subset containment relation defined only over sets Operations union, intersection and difference defined only over sets and bags No constraints over collections 21 ODMG Components – Object Model Collections (2/2) interface Collection : Object { exception InvalidCollectionType{}; Sets exception ElementNotFound{ Object element; }; class Set : Collection { boolean is_empty(); attribute set<t> value; Set create_union(in Set other_set); ... Set create_intersection(in Set other_set); boolean contains_element(in Object element); Set create_difference(in Set other_set); void insert_element(in Object element); boolean is_subset_of(in Set other_set); void removes_element(in Object element) boolean is_proper_subset_of(in Set raise (ElementNotFound); other_set); ... ... Iterator create_iterator(in boolean stable); }; ... boolean query(in String OQL_predicate, inout Collection result); }; Bags class Bag : Collection { attribute bag<t> value ; unsigned long occurrences_of(in Object element) ; Bag create_union(in Bag other_bag) ; Bag create_intersection(in Bag other_bag) ; Bag create_difference(in Bag other_bag) ; }; 22 ODMG – Object Model Attributes and Relationships Attributes Relationships Unidirectional Values could be literals and objects Single as well as multi-valued Resort name location beachType numberOfBeaches transferTime addFacility(F) showHotels(): set(H) Implicitly modelled as properties whose values are objects Frequently bidirectional Bidirectional relationships require inverses 1:many, 1:1, many:many 1 Hotel hotels * resort name address numberOfRooms isOverBooked addFacility(F) isChildFriendly(): B checkAvailability(S,R) 23 ODMG – Object Model Inheritance Classes are organized into inheritance hierarchies The properties and operations of an object type are inherited by its subclasses and so only need to be written once. Saves code through reuse Makes code simpler Provides a compact, well structured and easy to understand Two kinds of inheritance supported: Inheritance of Behaviour or ISA denoted by “:” interface Person {…}; class Student : Person {…}; Inheritance of Statedenoted by “extends” class Vehicle {…}; class Car extends Vehicle {…}; 24 ODMG Object Database Standard – ODL Object Definition Language (ODL) ODL is a specification language used to define the schema of an ODMG compliant database. ODL supports all semantic constructs of the ODMG object model. ODL is independent of any programming language, and hence provides means for the portability of database schema across complaint OODBMSs. The database schema may comprise of: an ODL module (i.e. a higher level construct for grouping ODL specifications), some generic object types using interface, some concrete object types using class, and some literal types using struct, etc. 25 ODMG Object Database Standard – ODL Mapping Class Diagrams into ODL In general, we are dealing with: classes, attributes, operations associations and inheritance. Mapping (general case) Each UML class becomes an ODL class. Multi-valued attributes are declared by sets, bags or lists constructors Composite attributes are mapped into tuple constructors Each attribute or method in a UML class becomes an attribute or operation of an ODL class with appropriate types. Specify a suitable extent name unless the class diagram explicitly indicates otherwise. Specify a unique key if one or more attributes of a UML class are shown in bold or tagged with {PK}. Specify inheritance relationships via extends clause Map weak entity types in the same way as regular entities … 26 ODMG - Mapping Class Diagrams into ODL Bi-Directional Associations in ODL … Implementing the to-one (1..1) relationship from Student to Course class. relationship Course enrolledOn inverse Course::students; Implementing the to-many (0..*) relationship from Course to Student class. relationship set<Student> students inverse Student::enrolledOn; 27 ODMG - Object Definition Language (ODL) Mapping/translating a schema into ODL class Person { attribute string name; attribute string address; attribute date birthDate; short age(); }; class Lecturer extends Person (extent Lecturers) { attribute short room; relationship set<Student> tutees inverse Student::tutor; }; … class Student extends Person (extent Students) { attribute string major; relationship Lecturer tutor inverse Lecturer::tutees; }; … 28 ODMG - Mapping/translating a schema into ODL Reconsider the University schema… Person name: string address: string birthDate: date age(): integer Student tutor tutees * 1 major: string register(C: Course): boolean takeUnit(U: Unit): boolean Lecturer room: string salary: float joinDate: date enrolledOn * Department worksFor * teachUnit(U: Unit): bollean takes * staff deptId: string name: string 1 getCourses(): Set(Course) offers takenBy * students Unit unitCode: string description: string getCourses(): Set(Course) Course 1 partOf * units * 1 courseCode: string name: string dept * getUnits(): Set(Unit) 29 ODMG - Mapping/translating a schema into ODL University schema in ODL Person name: string address: string birthDate: date age(): integer Student tutor tutees * 1 major: string register(C: Course): boolean takeUnit(U: Unit): boolean enrolledOn * takenBy * Unit unitCode: string description: string getCourses(): Set(Course) partOf * Department worksFor * teachUnit(U: Unit): bollean takes * class Department (extent Departments) class Person { attribute string name; { attribute string name; attribute string address; relationship set<Lecturer> staff attribute date birthDate; inverse Lecturer::worksFor; short age(); }; relationship set<Course> offers class Lecturer extends Person (extent Lecturers) inverse Course::offeredBy; }; { attribute short room; class Course (extent Courses) relationship set<Student> tutees { attribute string name; inverse Student::tutor; relationship Department offeredBy relationship Department worksFor inverse Department::offers; inverse Department::staff; relationship set<Student> hasStudents relationship set<Unit> teaches inverse Student::enrolledOn; inverse Unit::taughtBy; relationship set<Unit> hasUnits boolean teachUnit(in Unit U); }; inverse Unit::partOf; }; class Student extends Person (extent Students) class Unit (extent Units) { attribute string major; { attribute string name; relationship Lecturer tutor attribute string code; inverse Lecturer::tutees; relationship set<Student> takenBy relationship Course enrolledOn inverse Student::takes; inverse Course::hasStudents; relationship set<Lecturer> taughtBy relationship set<Unit> takes inverse Lecturer::teaches; inverse Unit::takenBy; relationship set<Course> partOf boolean register(in Course C); inverse Course::hasUnits; }; boolean takeUnit(in Unit U); }; Lecturer room: string salary: float joinDate: date staff deptId: string 1 name: string getCourses(): Set(Course) offers students Course 1 units * courseCode: string name: string dept * getUnits(): Set(Unit) 30 1 Data Models: An overview Annex DB Evolution and History Data Models: An overview Data Models: 1st Generation Hierarchical Data Model implemented primarily by IBM’s Information Management System (IMS) allows one-to-one or one-to-many relationships between entities an entity at a “many” end of a relationship can be related to only one entity at the “one” end this model is navigational – data access is through defined relationships, efficient if searches follow predefined relationships but performs poorly otherwise, e.g for adhoc queries. Network Data Model standard developed by the Committee on Data Systems Languages (CODASYL) allows one-to-one or one-to-many relationships between entities allows multiple parentage – a single entity can be at the “many” ends of multiple relationships navigational 32 Data Models: An overview Data Models: 2nd Generation Relational Data Model developed by Edgar Codd (1970) data represented by simple tabular structures (relations) relationships defined by primary keys and foreign keys data accessed using high-level non-procedural language (SQL) separates logical and physical representation of data highly commercially successful (Oracle, DB2, SQL Server, etc) SQL is not computationally complete does not have the full power of a programming language Applications generally require the use of SQL statements embedded in another programming language. 33 Data Models: An overview Data Models: 3rd Generation most programming languages are now objectoriented Object-Relational Model hybrid (or “post-relational”) model – objects can be stored within relational database tables proposed by Stonebraker (1990) no accepted standards, but ORDBMS features supported by major commercial RDBMSs such as Oracle Object Data Model offers persistence to objects, including their associations, attributes and operations requirements specified by Atkinson in 1989, standards proposed by Object Data Management Group (ODMG) navigational – a step backwards from the relational model in some ways 34 Data Models: An overview DB Evolution and History 35