1 / 30

ODB – Object DataBases

ODB – Object DataBases. Object-Oriented – Fundamental Concepts UML and EE/R OO and Relational Databases Introduction to ODB. Chap. 20. Object-Orientation. Aims: To develop modifiable software which is robust in relation to: Changes in physical data representation (”the Y2K-problem”)

kaida
Download Presentation

ODB – Object DataBases

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. ODB – Object DataBases Object-Oriented – Fundamental Concepts UML and EE/R OO and Relational Databases Introduction to ODB Chap. 20 NOEA/IT - Databases/ODB

  2. Object-Orientation Aims: To develop modifiable software which is robust in relation to: • Changes in physical data representation (”the Y2K-problem”) • Changes in functional requirements Means: • Modularity bases on logical data structure: • data at some appropriate conceptual level is much more stable over time than functionality. • Data abstraction: • data are described as classes – that is in term of the logical behaviour of their operations, and not by their internal representation NOEA/IT - Databases/ODB

  3. Means (cont…) • Inheritance and polymorphism: • Classes may be defined as extensions/specialisations of existing classes (reuse) • New features may be added in the subclass • Inherited features may be redefined in the subclass • Dynamic binding (run-time) determines which specialised version of a given feature is to be applied (which class does the object actually belongs to) NOEA/IT - Databases/ODB

  4. Example – RecallMiniBank • The company MiniBank stores information about clients and accounts • About a client name, address, cprno (unique) and status (A= special clients, B= standard clients or C= problem clients) are stored. • About accounts accountno (unique), balance and interest rate are stored. • An account is always associated with exactly one client, a client may be associated with none or more accounts. NOEA/IT - Databases/ODB

  5. MiniBank – the OO-way Minibank: Find classes: Problem specific classes Client Account Library classes: Address CPRClass AccNoClass List<Type> NOEA/IT - Databases/ODB

  6. MiniBank – the OO-way Library classes – designed, implemented and tested once and for all: (In #C/Java++ something) class CPRClass { private: <<internal representation>> public: setCpr(-)//checking modulus 11 string getCprAsString(); int getAge(); ---- //and many more operations on CPR numbers } Similar for Address and AccNoClass. List<Type> is a generic Collection from the standard library of the programming language. NOEA/IT - Databases/ODB

  7. 0..n 1..1 Client Account MiniBank – the OO-way Find structure: As an alternative to the status attribute in Client, it may be specialised using inheritance NOEA/IT - Databases/ODB

  8. MiniBank – the OO-way Define problem specific classes: class Account{ private: float balance; float inRate; public: float getAvailable(){return balance;} void addInterestRate(){balance = balance + foo();} //other operations } NOEA/IT - Databases/ODB

  9. MiniBank – the OO-way class Client{ private: CPRClass cpr; //other attributtes list<Account> clientAccounts; //clients holds a //list of his accounts public: setClient(CPRClass clCpr,,,) {.. cpr.setCpr(clCpr);..} float getEngagement(){ float sum=0; for(int i=0;i<clientAccounts.len();i++) sum=sum+clientAccount[i].getAvailable(); return sum; } //other operations } NOEA/IT - Databases/ODB

  10. MiniBank – the OO-way • Now MiniBank wants to offer a new type of account to its clients: A BudgetAccount which as an agreed limit • This class may be defined as a specialisation of the existing Account using inheritance: • A new attribute lendingRate is added (the interest rate when the balance is negative) • Also an attribute limit is added (the limit that is agreed) • The operations addInterestRate redefined so interest rates are added according to the balance of the accaount • The operation getAvailable is redefined so balance+limit is returned • Polymorphism allows objects of type BudgetAccount to be stored in the clientAccounts-list of a Client-object NOEA/IT - Databases/ODB

  11. 0..n 1..1 Client Account Budget Account MiniBank – the OO-way NOEA/IT - Databases/ODB

  12. MiniBank – the OO-way class BudgetAccount: Account{ private: float lendIR; float limi; public: float getAvailable(){return balance + limit;} void addInterestRate(){ balance= balance + fooNew();} //other operations } Note: No changes in Client!!! NOEA/IT - Databases/ODB

  13. MiniBank – the OO-way class Client{ private: CPRClass cpr; //other attributtes list<Account> clientAccounts; //clients holds a //list of his accounts public: setClient(CPRClass clCpr,,,) {.. cpr.setCpr(clCpr);..} float getEngagement(){ float sum=0; for(int i=0;i<clientAccounts.len();i++) sum=sum+clientAccount[i].getAvailable(); return sum; } //other operations } Due to polymorphism subtypes of Account may be stored here Dynamic binding assures that the right version of getAvailable() is called NOEA/IT - Databases/ODB

  14. UML: Unified Modelling Language • Fig 3-15 ER model: Many similarities with UML Class Diagrams NOEA/IT - Databases/ODB

  15. Fig 3-16 UML Class Diagram: Many similarities with ER models NOEA/IT - Databases/ODB

  16. Specialisation in EER NOEA/IT - Databases/ODB

  17. Specialisation in UML • Fig 4-10 NOEA/IT - Databases/ODB

  18. Comparing: OO and RDB - a conflict? • OO: • data is described abstractly and represented as encapsulated objects • a model of arbitrary complex data structures are created – structure may be composite and repeating and may change dynamically • Changes in functional requirements are met by inheritance and polymorphism • OO-code is a good model of the domain • RDB: • data is describes as simple atomic values in rows in tables • no encapsulation, data abstraction, inheritance or polymorphism • normalisation leads spreading related data over many different tables and hence a more poor model of the domain NOEA/IT - Databases/ODB

  19. Transformation is needed when using RDBMS NOEA/IT - Databases/ODB

  20. Or in a picture… NOEA/IT - Databases/ODB

  21. Two trends • Object Databases (“pure ODBs”) • ObjectStore • O2 • FastObjects (Versant FastObjects .NET ) • ORDB: Extensions to SQL and RDBMSs in order to support OO-concepts: • SQL3 (SQL-99) • Oracle8 (and higher) • Informix Universal Server (now IBM) • IBM DB2 Universal Database NOEA/IT - Databases/ODB

  22. Object-oriented DBMSs • Extensions or APIs (libraries) to OOPLs • Still immature • Mostly used in applications with relatively few instances of large complex objects (as CAD/CAM, case tools, IDEs etc.) NOEA/IT - Databases/ODB

  23. Object-oriented DBMSs • OO systems are characterised by objects interacting in doing the job. • This includes: • Object identity (every object has a unique identity) • Object state (attribute values) • Features (functions/methods that can be applied to the object – the class) • Structure • Specialisation/Generalisation (inheritance). • Aggregation (objects may be composed of other objects – have attributes that refer to other objects including collections of other objects) • Association (objects refers to each other dynamically. OODBMS Must store all above. NOEA/IT - Databases/ODB

  24. OODB – object identity (OID) • OO systems are based upon object references (conceptual pointers, memory locations) • Object identity (OID): • OIDs are persistent pointers • OIDs are assigned to objects on creation • OIDs are immutable, that is are never changed and are not reused • OIDs are transparent to the user and managed by the DBMS • OIDs are not primary keys! • Primary keys may be found in the domain and • Primary keys may have semantics • Primary keys are local to a table (class/relation) – OIDs are global to the system • OIDs are simple, atomic values, primary keys may be composite NOEA/IT - Databases/ODB

  25. Object Structure • Any object may be represented by a triple: • (i, c, v), where • i is the OID of the object • c is the type constructor of the object • v is the state (or the current value) of the object NOEA/IT - Databases/ODB

  26. Type Constructors • atom • simple value (primitive data type) • tuple • <a1:i1, a2:i2,…,an:in>, where each a is an attribute name and each i is an OID • collection type • Some collection of OIDs • Collections may be: • set • list • bag • array NOEA/IT - Databases/ODB

  27. Example • Fig 20-2 NOEA/IT - Databases/ODB

  28. Features (operations) NOEA/IT - Databases/ODB

  29. Persistent Objects NOEA/IT - Databases/ODB

  30. Inheritance • In OOPL: type perspective • In ODB: inheritance are also to be viewed as an constraint on the extension of a class: • Any object belonging to the extension of subtype must also belong to the extension of the super type • Multiple and selective inheritance Extension of class. What is that? NOEA/IT - Databases/ODB

More Related