The process of creating an OO database application using an OODBMS is meant to be a natural extension of application development in an OO programming environment. As discussed previously, there are language bindings specified in the ODMG standard for C++, Java, and Smalltalk, as well as other language bindings. The difference between using objects in programs written in these languages and database objects is the persistence of the database objects. Vendors that support the ODMG standard provide facilities to make program objects persist and to provide access to database objects for manipulation within programs.
Current OODBMS products include systems such as InterSystems Iris, Objectivity/DB, Matisse, GemStone/S, ObjectStore, Actian NoSQL, Perst, ZODB, ObjectDB, and ObjectDatabase++. The specific characteristics and functionality of each system vary, but these systems generally support the object data model together with access from a multitude of programming languages, such as C++, C#, Java, Smalltalk, and Python. Application development is typically supported from various integrated data environments with capabilities for querying data through an OQL-like or SQL-like query language. In this section, we highlight the application development capabilities of InterSystems Iris as an example of an OODBMS and also revisit the University schema within the Iris object data model.
FIGURE 9.7 provides a high-level overview of the InterSystems Iris Data Platform. Iris is a multimodel system, supporting the ODMG object model as well as relational tables, document data, and key-value pair data. Iris has been designed to support interoperability among these different data representations in addition to support for the object data model. Our focus is on Iris support for objects.
FIGURE 9.7 The InterSystems Iris Data Platform
As shown in Figure 9.7, application development with Iris can be performed with tools such as Visual Studio Code and Docker. These tools provide environments for creating object schemas and developing software applications that access Iris OO data with extensions that support ObjectScript, an embedded programming language for objects developed by InterSystems. Iris Studio provides wizards for assistance in creating ODL class declarations that include inheritance specifications together with attribute, relationship, and method definitions. InterSystems also provides an Open Exchange repository for developers, where developers can share tools for working with Iris data. One such tool is RAD (Rapid Application Development) Studio, providing a way to quickly create forms for inserting and manipulating Iris objects. Other notable tools in the Open Exchange are Class Explorer, providing a UML-like view of Iris class definitions, and Web Terminal, providing a web-based terminal for access to Iris data. The Iris Terminal is a command-line interface that can be operated in two different modes. In its basic mode, objects can be created, stored, and retrieved using ObjectScript. The Iris Terminal can also be operated in the SQL Query Shell mode, where SQL can be used to query object classes viewed as relational tables. As in OQL, SQL within InterSystems Iris supports an implicit join feature for traversing object relationships. The Iris Management Portal also supports an SQL query capability in addition to general systems administration capabilities for managing user access to the data platform. The query capabilities in the Iris Terminal and the Management Portal can be used for ad-hoc queries or to test query access for further use in application development.
Figure 9.7 also illustrates that InterSystems supports Application Programming Interfaces (APIs) that use ODBC and JDBC drivers. Languages supported include Java and Python, as well as development environments such as .NET and Node.js. The InterSystems APIs include a JDBC driver API for access to relational tables or to object classes when viewed as relational tables, the XEP (Express Event Persistence) API for inserting and accessing object data, and a Native API for direct access to data such as NoSQL key-value pair data (a data format described in Chapter 14), or data stored in XML or JSON format (data formats described in Chapter 13). There are many other features of the Iris Data Platform that are beyond the scope of this chapter. Readers are encouraged to explore the InterSystems website to learn more about Iris support for objects and interoperability with other data representations.
FIGURE 9.8 shows the class definitions for the revised University schema that corresponds to the UML diagram in Figure 9.5, created using Iris Studio. The first class, Address, describes a serial object, which is an object that can be embedded in other classes. For example, Address is used as the type of the addr attribute in the Person class that follows. This is similar to the definition of Addr as Struct in the ODL definition of the University schema in Figure 9.6.
FIGURE 9.8 The University Schema Using Iris
Iris Studio allows designers to create classes whose objects are persistent simply by adding Extends (%Persistent) after the class name. The class Person is defined as persistent, which means that objects of type Person are stored in the database. Person also has an index on pId together with the Unique specification, which defines pId to be a key for the class. The Index and Unique specifications are used to define keys for several other classes. Notice that the keys for Department and Evaluation are composite keys.
Recall in the UML diagram of Figure 9.5 that Faculty and Student are subclasses of Person. In Iris, this subclass relationship is indicated by the phrase Extends University.Person on the class definition line. Because Person is defined to be a persistent class, Faculty and Student are also persistent. The same is true for Undergraduate and Graduate, which are defined as Extends University.Student and TeachingAssistant, which is defined as Extends University.Graduate.
Note that rank in Faculty has a list of possible values, and in Student there is an initial value for credits and a range for gpa. In general, Iris provides several features for enhancing the definition of attributes, such as length specifications for String types as shown in the Address class, as well as formatting for values like phone numbers and social security numbers.
When creating a persistent class in Iris, the term property is used to refer to both attributes and relationships. The resulting class definition, however, makes a distinction between properties as attributes and properties as relationships, as in the ODL of the ODMG model. Relationships can be one-to-many or parent-to-child. The advises relationship in Faculty provides an example of a one-to-many relationship, where advises is composed of many objects from the Student class. The inverse is the hasAdvisor relationship in the Student class. As defined in the Student class, hasAdvisor points to only one Faculty object and specifies that the inverse is the advises relationship in the Faculty class.
Parent-to-child relationships are one-to-many specifications indicating that dependencies exist. For example, the hasSection relationship of Course defines the cardinality as children, meaning that a course has many sections and the sections are existence dependent on the course. Likewise, the isSectionOf relationship in ClassSection is defined with a cardinality of parent, meaning that a class section is related to one course and is existence dependent on the course. This definition is consistent with the UML relationship definition between Course and ClassSection in Figure 9.5.
In Iris, one-to-one relationships are not explicitly represented using inverse relationship definitions. Instead, a one-to-one relationship is defined as a property, where one class points to objects of a second class as the property value. To enforce the one-to-one semantics, a unique index can be defined on the property. A foreign key definition can also be used to maintain referential integrity. As an example, the UML diagram in Figure 9.5 defines a one-to-one relationship between Department and Faculty with respect to the chair of the department: a department has one chair and a faculty member can only chair one department. In the Iris class definition of Department in Figure 9.8, hasChair is defined as a property with a value of type Faculty. The Faculty class has no such inverse property definition. The Department class, however, defines a Unique index on the hasChair property to create the intended one-to-one semantics
The Unique index will prevent a faculty object from being assigned as a chair to more than one department. A foreign key is also defined to ensure referential integrity with respect to faculty objects
The hasChairFK foreign key definition in Iris provides the same functionality as it does in the relational model, indicating that a faculty object cannot be deleted if it is also referenced as the chair of a department.
When mapping one-to-one relationships from a UML diagram to an Iris schema, it is a design decision as to which side of the relationship to use to define the property. In general, the property should be placed on the side where the most queries will occur about the relationship. In the one-to-one relationship between Department and Faculty, a department always has a chair. In the opposite direction, most faculty members do not serve as department chairs. As a result, it is a better design decision to define the property in the Department class. The name of the department chair can easily be retrieved with SQL in Iris using an implicit join of the relationship, which is the same as dot notation in OQL, with the dot replaced by an arrow notation. As an example, the following query retrieves the department name and the first and last name of the chair of the computer science department
The other one-to-one relationship in the UML diagram of Figure 9.5 is the relationship between ClassSection and TeachingAssistant. In this case, ClassSection defines hasTA as a property with a type of TeachingAssistant, including the appropriate unique index and foreign key definitions.
Iris does not directly support many-to-many relationships, such as the many-to-many hasPrerequisite/isPreReqOf relationships of the Course class in Figure 9.5. To represent this many-to-many relationship, the Prereqs association class is defined. A Course then represents its prerequisites through a one-to-many hasPreReq relationship to instances of the Prereqs class. Each instance of the Prereqs class has the many-to-one relationship isPreReq, which then points back to the class instance that is the prerequisite. From the Course class, the relationships can be traced backwards to identify the courses for which a course is a prerequisite. For example, from Course, hasPreReq finds the Prereqs instances, which then point to courses through the isPreReqOf relationship. Notice that the PreReqs class creates a composite key (isPreReqOf, isPreReq) for objects in the class through the definition of a unique index. In a similar manner, the Enrollment association class is used in Figure 9.8 to represent the many-to-many relationship between students and the class sections in which they enroll. The Mark class is also created to record the grade that each student earns in the classes that they complete. This relationship was represented in the UML diagram in Figure 9.5 as a many-to-many relationship between Student and ClassSection, with grade as an attribute of the relationship.
3.144.230.172