A Semantic Object-Oriented Data Access System
Salvatore T. March
Information and Decision ScienceCarlson School of Management
University of Minnesota271 19th Avenue SouthMinneapolis, MN 55455
Sangkyu Rho*
College of Business AdministrationSeoul National University
Seoul 151-742KOREA
February 4, 1997
* Prof. Rho was partially supported by the Institute of Management Research,Seoul National University.
A Semantic Object-Oriented Data Access System
Abstract
Lack of support for Entity-Relationship (E-R) semantics and the disconnect between object-
oriented programming language (OOPLs) and database languages remain key roadblocks to the
effective use of object-orientation in information system development. We have defined
SOODAS (Semantic Object-Oriented Data Access System), a purely object oriented language
that supports E-R semantics and set level querying, and provides related development tools.
SOODAS is implemented by extending the OOPL Smalltalk with five meta-classes. EntityObject
and Relationship provide the necessary capabilities to define entities, attributes, relationships,
external identifiers, and constraints. Together with QueryNode, EntityObject provides an object-
oriented, multi-entity querying capability. Queries can be arbitrarily complex and can include
cycles. Persistence is provided by PermanentObject, of which EntityObject and Relationship are
subclasses. EntityInterface provides a standard, re-usable interface screen definition for
displaying and maintaining instances of any entity. Since SOODAS is purely object-oriented, it
can be seamlessly integrated with any Smalltalk application.
1
1. Introduction
Object-oriented (OO) systems development is gaining widespread popularity [Guttman and
Matthews, 1995; Dewitz, 1996]. Object representations are claimed to be more natural than
traditional data and process models since they provide a uniform description of system
capabilities. Furthermore, object-oriented development is claimed to be more efficient than
traditional development methods because developers can re-use components of the design and
implementation [Coad, 1995; Yourdon, 1994; Rumbaugh, et. al., 1991].
In practice, much work is necessary to transform a conceptual object model into an information
system implementation. This is due, in large part, to the lack of Entity-Relationship (E-R)
semantics in Object Oriented Programming Languages (OOPLs) [Ling and Teo, 1993; Bertino,
et. al., 1992; Kilian, 1991] and the disconnect between OOPLs and Object Oriented Database
Management Systems (OODBMSs).
Object models [Rumbaugh, et. al., 1991] express extended E-R semantics1, but OOPLs do not
directly support them. Entities are typically implemented as classes with no shared data or
operations aside from those explicitly defined by subtyping. Relationships are typically
implemented using embedded objects (i.e., pointers [Yourdon, et. al., 1995; Narasimhan, et. al.,
1994; Elmasri et al., 1993]). There are several disadvantages of such implementations
[Rumbaugh, 1987]. First, meta-data cannot be easily queried, thus it is difficult for users to see
the underlying object structure. Second, methods must be written specifically for each Entity
class to support standard constraints such as entity integrity and referential integrity. Third,
queries that are simple to specify in E-R or relational query languages are extremely difficult to
specify in OOPLs since they navigate at the object (instance) level.
ODMG compliant OODBMSs [Cattell, 1995; O. Deux et al., 1991] resolve some of these
problems but their languages use a functional rather than object oriented paradigm. This results in
an impedance mismatch between the database language and the programming language in which
1We use the term E-R model to represent the structural component of an object model.
2
the application is developed [Copeland and Maier, 1984]. Hence, there are significant challenges
in binding OODBMS implementations to pure OOPLs such as Smalltalk [Goldberg and Robson,
1989].
To address these problems we have defined a Semantic Object-Oriented Data Access System
(SOODAS). SOODAS is a purely object oriented language that supports E-R semantics and set
level querying. It is implemented in five meta-classes, EntityObject, Relationship, QueryNode,
PermanentObject, and EntityInterface. These support the definition and maintenance of an E-R
model and its data, including entity integrity constraints and relationship cardinality constraints.
Queries involving any number of entities can be easily specified and seamlessly integrated into the
methods of any object in the application.
The remainder of this paper is organized as follows. The next section overviews the basic E-R
semantics and discusses prior efforts to support them in object systems. The following section
presents our object model, detailing the capabilities needed to support structural E-R semantics.
The next section describes the object definition and manipulation methods. It also presents a brief
example application. The next section discusses the SOODAS query language and provides
examples illustrating its power. The final section presents limitations of our current system and
directions for future research.
2. Basic Entity-Relationship Semantics and Their Support in Object Systems
Entity-Relationship semantics have been presented by numerous authors [Elmasri and Navathe,
1994; Teorey, 1994]. We overview them briefly here and describe their implementation as meta-
classes in the next section.
Four basic constructs are common among to E-R semantics: entity, attribute, relationship, and
identifier. An entity (or entity type) is a category or grouping of things (people, companies,
events) or roles (e.g., employee, customer, assignment). All instances of an entity share a
common set of attributes and relationships. An attribute is a characteristic of an entity-instance.
3
A relationship is an association among entities. Each entity in a relationship has a minimum and
maximum cardinality i.e., the minimum and maximum number of relationship instances in which
one entity instance must / may participate. In this research we consider only binary relationships
without attributes. Higher order relationships and relationships with attributes must be
represented by entities. Each entity has at least one set of attributes and / or relationships, termed
its (external) identifier, whose values uniquely distinguish its instances. Entity integrity demands
that, given the value of an identifier, there is at most one corresponding instance of that entity.
Supertype/subtype or ISA relationships were introduced to increase the fidelity of data models to
the real world [Smith and Smith, 1977]. These allow the specification of subsets of an entity’s
instances (subtypes), having specialized attributes and / or relationships in addition to those of the
entity (supertype). This concept, central to the OO paradigm, includes the notion of inheritance.
A subtype inherits all attributes and relationships (and behaviors) from its supertype(s).
A system that supports E-R semantics must have a mechanism to define and maintain entities,
their attributes, relationships, identifiers, and constraints. It should support access to the
definitions as well as to the data. An entity must be able to answer the names of its attributes and
relationships as well as selected subsets of its instances. An entity instance must be able to answer
values for each of its attributes and instances for each of its relationships. Furthermore, to be
effective, set level operations equivalent to relational operations must be supported [Markowitz
and Shoshani, 1993; Norrie, 1994].
Seven basic concepts are common to the object paradigm [Rumbaugh, et. al., 1991]: object,
behavior, method, message, class, inheritance, and polymorphism. An object is an instance.
Behavior is what an object can do, i.e., its capabilities. These are implemented in the methods of
the object. An object performs its methods (exhibit its behavior) when sent a message. The
signature of a message is defined in its associated method. Objects with the same methods (i.e.,
behaviors) are organized into classes. A class represents a template for a set of objects.
Frequently sets of objects share some, but not all methods. Inheritance is the mechanism whereby
classes share methods. Methods can be defined in a class (termed a superclass) and inherited by
4
other classes (termed subclasses). Polymorphism refers to the use of the same method name in
different classes enabling objects in different classes to respond to the same message in different
ways.
Support for entities and attributes is provided through the class concept. An entity can be
represented as a class with its attributes as instance variables. No direct support is provided for
identifiers in the E-R sense. Each instance is given a unique object identifier or OID; however,
there is no way to specify that a set of variables must contain a unique value within the set of
instances of the class. Aside from the class hierarchy (exclusive subtypes that do not necessarily
cover their supertype), relationships are supported only by embedded objects [Rumbaugh, 1987].
Thus, instance-at-a-time navigation of related objects is supported; however, set level queries are
not.
All constraint checking must be done by each class. Constraint specification and enforcement
must be implemented in the methods of each class representing an entity. Each must have a
method to check entity integrity. Each must have methods to check relationship constraints for
each relationship in which it participates. Binary relationships can be represented in one or both
classes (i.e., one or both directions); hence, the designer must decide where the relationship is to
be represented and develop methods in the appropriate classes to enforce the appropriate
constraints.
There have been several prior attempts to directly support E-R semantics using object concepts.
Rumbaugh [1987] and Shah, et. al. [1989] implemented an object-relationship modeling language
in C that supports relationships and enforces relationship constraints. However, their approach is
functional rather than purely object oriented, they do not include meta-data management and they
do not include a query language.
Diaz and Paton [1994] propose using meta-classes to extend the OODBMS Adam. They
introduce the meta-classes Entity_Concept and Relationship_Concept. However, they do not
5
address entity or relationship integrity constraints at the meta class level, nor do they propose an
object-oriented query language.
The Object Data Management Group (ODMG) has addressed a number of these issues by
proposing a standard (ODMG-93) for Object Database Management Systems (ODBMSs)
[Cattell, 1995]. However, ODMG-93 does not address issues of metadata management,
conceptualizes relationships as embedded objects, and fails to fully represent relationship
constraints. Its query language (OQL) is functional, rather than object oriented, adhering
primarily to the SQL 92 standard [SQL 92]. Hence, ODMG-93 compliant OODBMSs support
some E-R semantics but there are significant challenges in binding OODBMS implementations to
pure object concepts and languages (such as Smalltalk). In a pure object environment, there is a
single conceptual representation: objects interacting through messages. Functional query
languages do not fit the message passing paradigm characteristic of pure object environments.
This presents conceptual difficulties to developers who must switch between object and functional
paradigms during the development process.
GemStone [Butterworth et al., 1991] provides a seamless integration between its database
language OPAL and OOPL Smalltalk. However, its object model lacks E-R semantics and it does
not support set-level multi-entity querying.
Recognizing that the basic operations to support E-R semantics are the same across all entities
and relationships, parameterized for identifier and relationship constraints, we create classes to
perform these operations and allow entities to inherit E-R operations from or delegate E-R
operations to them. Not only does this reduce the development effort by re-using methods, it also
provides for the management of meta-data which can also be queried by users as necessary
[Elmasri, et. al., 1993; March and Rho, 1996].
3. A Class Structure for E-R Semantics
6
Support for E-R semantics is provided via five meta-classes: EntityObject, Relationship,
QueryNode, PermanentObject, and EntityInterface. These have been implemented as
extensions to ParcPlace VisualWorks Smalltalk [VisualWorks, 1994; Lewis, 1995]. This
implementation can easily be ported to object-oriented database languages based on Smalltalk
such as GemStone’s OPAL [Butterworth et al., 1991]. Their definitions, including class and
instance variables and methods, and position in the Smalltalk class hierarchy are shown in Figure
1. Object, Model and ApplicationModel are system supplied classes. Object is the root of the
class hierarchy, supplying such capabilities as instance creation and OIDs. Model and
ApplicationModel provide the engine behind the Model-View-Controller (MVC) architecture
used to manage user interfaces.
EntityObject and Relationship provide structural E-R semantics. When sent the appropriate
object definition language (ODL) message, EntityObject defines an entity as a subclass of itself
and generates instance variables and methods for all attributes. Each entity inherits the variables
(e.g., Identifier, Partition) and capabilities from EntityObject needed to manage its own data and
meta-data, including the ability to define and enforce entity integrity constraints (external
identifiers), subtypes and subtype constraints (exclusive or partition).
Similarly, when sent an appropriate ODL message, Relationship defines a relationship as an
instance of itself. Relationship manages all relationship data and enforces all relationship
constraints. Each relationship is described by its name (name), the related entities (e1 and e2),
their cardinality definitions (min1, min2, max1 and max2), access names (access1 and access2)
and the related pairs of instances (instances1 and instances2). Thus relationships are not
represented by embedded objects as often done in Object implementations, rather each
Relationship instance holds the related pairs of objects for the relationship it represents.
Each Relationship instance inherits the capability to add and remove entity instance pairs
(provided no integrity constraints are violated by doing so) and to answer the related instances for
either entity instance in the relationship. For convenience, methods are generated in each entity of
7
a relationship to request these services (see Section 4.1). A relationship can be recursive. For
recursive relationships additional methods are generated to access the transitive closure.
Queries are represented as graphs of interconnected QueryNode instances. They are formed by
sending object manipulation language (OML) messages to entities and to the QueryNode
instances they create. Each entity inherits methods from EntityObject to create a QueryNode
instance containing the projection (project), selection (select), and ordering criteria (orderBy) for
that entity in a query. Each QueryNode instance inherits methods to appropriately connect itself
with another QueryNode instance which specifies another entity in the query and to materialize a
query result (Section 5 describes in detail the way in which query graphs are constructed). Thus
the query language provides a natural traversal of the E-R model at the entity level.
EntityObject and Relationship inherit persistence from PermanentObject. In an Object-Oriented
OODBMS such as GemStone, persistence would be provided by the OODBMS itself and
PermanentObject could be eliminated. In the current implementation PermanentObject holds all
data in instances of the Smalltalk class Dictionary. Dictionaries are maintained in virtual memory
and can grow to be many megabytes. The memory manager is responsible for paging virtual
memory to and from secondary storage. While there are some efficiency concerns, this
implementation demonstrates the feasibility of our approach. Its scalability is currently under
investigation.
EntityInterface provides a standard, re-usable interface for displaying and maintaining instances.
EntityInterface is a subclass of ApplicationModel [VisualWorks, 1994], from which it inherits
methods to open windows and interact with the user. EntityInterface can create subclasses of
itself to define entity maintenance screens for any entity. Model and ApplicationModel provide
the engine behind the Model-View-Controller (MVC) architecture used to manage user interfaces.
The next section describes the object definition and manipulation methods of SOODAS and
shows how an E-R model is defined and maintained. The following section describes the
SOODAS query language.
8
4. SOODAS Object Definition and Manipulation
4.1 Object Definition Language (ODL)
Object definition methods enable the creation of entities, subtypes, attributes, relationships,
external identifiers, and constraints. These are defined as class methods of EntityObject and
Relationship. Following are the signatures of the corresponding object definition messages. An
example illustrating their use is presented below.
CreateEntity: eName attributes: attrList under: appName (sent to EntityObject) creates an
entity named eName as a subclass of EntityObject, having the instance variables named in attrList
under the category appName. Categories provide a means of organizing entities into applications.
Accessor and assignment methods are automatically generated for each instance variable.
CreateSubtype: subtypeName attributes: attrList (sent to an entity) creates a subtype (subclass)
of the receiver2 entity named subtypeName, having the instance variables named in attrList. The
subtype inherits all variables and methods from its superclass and is placed in the same category as
its superclass. Partition: boolean (sent to an entity) specifies if the subclasses of the receiver
form a partition (boolean is true) or not (boolean is false). An entity with partitioned subclasses is
an abstract class. That is, it has no instances. All instances are in one of its subclass.
new: e1 and: e2 withMin: min1 andMin: min2 withMax: max1 andMax: max2 named:
rName accessBy: access1 inverselyBy: access2 (sent to Relationship) creates a new
relationship, named rName, between entities e1 and e2 (e1 and e2 can be the same entity) with the
specified minimum and maximum cardinalities. For convenience it also creates instance methods
in each entity, named for access1 in e1 and access2 in e2, which enable them to easily request
access and maintenance services from Relationship. For recursive relationships these include
methods that support transitive closure queries.
Identifier: idList (sent to an entity) defines a primary (external) identifier for the entity as the set
of attribute and/or relationship methods in idList. This identifier is used to enforce entity
2 Consistent with the Smalltalk notation, receiver denotes the object to which a message is sent.
9
integrity. It also generates an instance method of the entity called id which answers the identifier
of the instance to which it is sent.
To illustrate these language constructs, we define the E-R model illustrated in Figure 2. What
follows is an executable transcript in Smalltalk. Comments are enclosed in double quotes. Many
has been declared as a Global variable. An interactive screen (Figure 3) has been developed to
send these same messages.
“ Define the entities. “EntityObject CreateEntity: #Employee attributes: ‘eno ename ssn exemptions ytdGross ytdFit ytdFICA
ytdSit’ under: ‘Payroll’.EntityObject CreateEntity: #Department attributes: ‘dno dname dbudget’ under: ‘Payroll’.EntityObject CreateEntity: #PayCheck attributes: ‘checkNo checkDate gross fit sit fica’ under: ‘Payroll’.EntityObject CreateEntity: #TaxState attributes: ‘stateAbbr taxRate’ under: ‘Payroll’.
“ Define subtypes which Partition Employee i.e., all Employees must be one of the subtypes. “Employee CreateSubtype: #HourlyEmployee attributes: ‘hourlyRate currentHours’.Employee CreateSubtype: #SalariedEmployee attributes: ‘salary’.Employee CreateSubtype: #SalesPerson attributes: ‘commissionRate’.Employee Partition: true.
“ Define the relationships. “Relationship new: Employee and: Department withMin: 0 andMin: 1 withMax: Many andMax: 1 named:
‘Report’ accessBy: ‘ReportsTo’ inverselyBy: ‘Employs’.Relationship new: Employee and: Department withMin: 0 andMin: 0 withMax: 1 andMax: 1 named:
‘Manage’ accessBy: ‘Manages’ inverselyBy: ‘ManagedBy’.Relationship new: Employee and: PayCheck withMin: 1 andMin: 0 withMax: 1 andMax: Many named:
‘Payroll’ accessBy: ‘PaidBy’ inverselyBy: ‘Pays’.Relationship new: Employee and: TaxState withMin: 0 andMin: 0 withMax: Many andMax: 1 named:
‘PayrollTax’ accessBy: ‘LivesIn’ inverselyBy: ‘HomeTo’.Relationship new: Department and: Department withMin: 0 andMin: 0 withMax: Many andMax: 1 named:
‘OrgStructure’ accessBy: ‘ParentUnit’ inverselyBy: ‘ChildUnit’.
“ Define the external identifiers. “Employee Identifier: ‘eno’.Department Identifier: ‘dno’.PayCheck Identifier: ‘checkNo’.TaxState Identifier: ‘stateAbbr’.
As a result of sending these messages, a database schema is defined. A class is created for each
entity and subtype with appropriate instance variables. For example, TaxState is a class having
two instance variables, stateAbbr and taxRate with appropriately named accessor and assignment
methods (the assignment methods have a colon specifying that they take a parameter). It is a
subclass of EntityObject, thus inheriting object access and maintenance methods from it. It has
an instance method named id that answers the value of stateAbbr, its identifier.
10
A Relationship instance is created for each relationship. Each entity has methods for each
relationship in which it participates. For example, five relationship methods are generated in
TaxState for its relationship, PayrollTax, with Employee. They are named according to its access
name, HomeTo. These request appropriate services from Relationship (see Section 4.2 below)
to access or assign appropriate Employee instance(s). HomeTo answers a related Employee
instance. HomeTo: anEmployee establishes a relationship between the receiver TaxState instance
and anEmployee (an instance of Employee). HomeToID answers the identifier of a related
Employee instance (i.e., its eno). HomeToID: anEno establishes a relationship between the
receiver TaxState instance and the Employee instance identified by anEno. HomeToC answers
the collection of Employee instances related to the receiver TaxState instance.
For example, the generated HomeToC is:
HomeToC^Relationship RelatedTo: self using: ‘PayrollTax’.
It answers the result of sending the message RelatedTo:using: to the class Relationship with
parameters self (i.e., the TaxState instance receiving the message) and the relationship name
PayrollTax (alternately the access names ‘HomeTo’ or ‘LivesIn’ could be used as the second
parameter).
OrgStructure is a recursive relationship of Department. Five relationship methods are generated
for each access name (ParentUnit and ChildUnit). Two additional methods, AllParentUnitC and
AllChildUnitC are also generated to access all ancestor and all descendent departments,
respectively. These methods can be used for transitive closure queries.
4.2 Object Manipulation Language (Meta-OML and OML)
In SOODAS data and meta-data are equally accessible. Entity meta-data is accessed using the
meta-OML methods inherited from EntityObject (Figure 1). Attributes answers a string
containing the names of all of the entity’s attributes. Relationships answers the set of
relationships of the entity. Identifier answers the external identifier of the entity. subclasses
answers its direct subtypes. superclass answers the supertype of the entity.
11
Relationship meta-data is accessed using the meta-OML methods of Relationship (Figure 1).
entities answers a collection containing the two entities participating in the relationship. max: e
using: accessName (min: e using: accessName) answers the maximum (minimum) number of
instances of the other entity in the relationship that can (must) be related to one instance of entity
e using access accessName. Use of these methods is illustrated in Figure 4.
PermanentObject (Figure 1) provides four basic OML methods: Instances, FindInstance:,
AddInstance: and DeleteInstance:. These are inherited by EntityObject and Relationship.
EntityObject redefines AddInstance: and DeleteInstance: and provides four transaction
management methods: UndoAdd:, StartUpdate:, UpdateInstance:, and UndoUpdate:.
Instances answers the collection of instances of the receiver3 including its descendant subtypes, if
any. Since this method answers a collection, Smalltalk collection methods such as do:, select:,
collect: and detect: are available to process the results. FindInstance: anID answers the
instance of the receiver having the identifier value anID, nil if none. For example, the following
Smalltalk code produces a collection of employees who report to department ‘001’.
Employee Instances select: [:e | e ReportsTo = Department FindInstance: ‘001’].
AddInstance: anInstance permanently adds anInstance to the receiver. When sent to an entity it
also checks entity integrity and relationship cardinality constraints. If any are violated, a warning
message is displayed and the operation is canceled using UndoAdd: anInstance. DeleteInstance:
anInstance permanently deletes anInstance, provided it exists. When sent to an entity it also
checks entity integrity and relationship cardinality constraints. If any would be violated, a
warning message is displayed and the operation is canceled.
StartUpdate: anInstance locks anInstance and initializes a log for the cancellation of the update.
UpdateInstance: anInstance permanently updates anInstance, provided entity integrity and
relationship cardinality constraints are not violated, otherwise a warning message is displayed and
the operation is canceled using UndoUpdate: anInstance. These messages are used in instance
3 The receiver of these messages may be any descendent class of PermanentObject.
12
methods of the class EntityInterface, which, as discussed below (Section 4.3), generates user
interface classes as subclasses of itself. Thus, for simple data maintenance activities, the user does
not need to even be aware of them.
Compared to the instance creation methods of OQL [Cattell, 1995], SOODAS is object oriented,
while OQL is functionally oriented. A new Department instance can be created and made
persistent in SOODAS as follows:
d := Department new.d dno: ‘005’; dname: ‘Marketing’; dbudget: 100000; ParentUnitID: ‘001’; ManagedByID: ‘1020’.Department AddInstance: d.
That is, a new instance of Department is created by sending the message new (inherited from the
class Object) to the Department class. The messages dno:, dname:, dbudget:, ParentUnitID:,
and ManagedByID: are sent to this instance with appropriate parameters (these methods were
generated when the Department class was created). It is made persistent by sending the message
AddInstance: to the Department class. The instance is a Smalltalk object and can be sent any
message valid for Department instances. Alternately, this can be accomplished using a generic
new: method:
Department new: #(dno: ‘005’ dname: ‘Marketing’ dbudget: 100000 ParentUnitID: ‘001’ManagedByID: ‘1020’)
OQL takes a functional approach, using type constructors as follows:
Department(dno: ‘001’, dname: ‘Marketing’, dbudget: 100000).
The Department instance must then be bound to a Smalltalk object and accessed via a query. We
do not argue that the object oriented approach is better than the functional approach. We simply
point out that OQL has taken a functional approach similar to the hybrid language C++ while
SOODAS has taken an object approach based on the OOPL Smalltalk. This difference also
appears in the query language as discussed below.
Relationship has three OML methods for maintaining relationship-instances (in the E-R sense):
Connect:and:using:, Disconnect:and:using: and ReConnect:from:to:using:. It has three
OML methods for accessing relationship-instances: RelatedTo:using:, FirstFor:using: and
AllRelatedTo:using:. In all cases the using: parameter is the relationship name or access name;
all other parameters are entity-instances. Users can maintain related instances by using the
13
generated relationship methods (e.g., HomeTo: and HomeToID:). They will typically not use
the relationship maintenance methods directly. However, since the generated relationship
methods use them, they are briefly described below.
Connect: i1 and: i2 using: rName establishes relationship rName between entity instances i1 and
i2, provided that each is of the appropriate entity and that relationship cardinality constraints are
not violated. In case of recursive relationships, rName must be an access name (i.e., access1 or
access2). DisConnect: i1 and: i2 using: rName removes the relationship rName between entity
instances i1 and i2, provided it exists and that relationship cardinality constraints are not violated
by its removal. ReConnect: i1 from: i2 to: i3 using: rName removes the relationship rName
between entity instances i1 and i2, if it exists, and creates one between entity instances i1 and i3,
insuring that each instance is of the appropriate entity and that relationship cardinality constraints
are not violated at the end of the update. ReConnect:from:to:using: is needed because
minimum cardinality constraints may be violated during the update process.
Similarly, users can obtain related instances by using the generated relationship methods (e.g.,
HomeTo, HomeToID, and HomeToC). They will typically not use the relationship accessing
methods directly. Again, however, since the generated relationship methods use them, they are
briefly described below.
RelatedTo: i1 using: rName answers a collection containing the instances related to instance i1
in the relationship rName. FirstFor: i1 using: rName answers the first instance related to i1 in
the relationship rName (“first” is arbitrarily defined since pairs of related instances are not
sequenced). AllRelatedTo: i1 using: aName answers the transitive closure of instances related
to i1 in the relationship represented by the access name aName. If the relationship represented by
aName is not recursive, then AllRelatedTo:using: and RelatedTo:using: answer identical
collections.
4.3 Creating User Interfaces.
The SOODAS class EntityInterface provides the basic functionality needed to maintain instances.
It has one method: CreateInterfaceFor: anEntity. When sent to EntityInterface this method
14
generates a display screen containing a scrollable list of instances of anEntity in a default format
and buttons to add, delete, edit, and find instances. It also generates a default data entry screen
which is displayed when the add or edit buttons are selected. The data entry screen contains an
input field for each attribute and a combo box for each one-to-many relationship for which
anEntity is on the many side (i.e., the screen supports the maintenance of one-to-many
relationships in what appears to the user as the familiar “foreign key” format).
Figure 5 illustrates the screens generated when the following message is sent.
EntityInterface CreateInterfaceFor: Department.
A column in the display screen and a combo box in the data entry screen are generated for the
relationships, Manage and OrgStructure. The default labels are ManagedBy and ParentUnit, the
access names. User supplied labels could easily be added to the interface generation process.
Additional interface classes have been developed to support common update patterns such as
parent-child relationships and many to many relationships.
5. SOODAS Query Language
In addition to the processing capabilities of Smalltalk SOODAS supports an object-oriented query
language via its meta-classes EntityObject and QueryNode. As discussed above, data may be
processed by, for example, sending the message Instances to an entity and using the standard
Smalltalk collection methods (e.g., do:, select:, collect:, detect:) to manipulate the resultant
collection. As opposed to the OQL which is a “functional language” [Cattell, 1995, pg. 53],
SOODAS is strictly object oriented (see Appendix 1 for an informal BNF). OQL extends the
SQL2 syntax with object concepts, but, strictly speaking, is not itself object oriented in that it
does not conform to the message passing paradigm. It specifies queries functionally using
functional concepts.
EntityObject has four class methods to support projection, selection, and ordering. SOODAS
uses the keyword Project for projection criteria, select for selection criteria, and orderBy for
ordering criteria. As commonly done in OO implementations, the first three methods add
15
“syntactic sugar” to the language. They each use the last method, with an empty code block and/
or an empty string for the unused capabilities.
Project: aProjectStringProject: aProjectString select: aSelectBlockProject: aProjectString orderBy: anOrderbyStringProject: aProjectString select: aSelectBlock orderBy: anOrderByString
When sent to an entity these messages answer an instance of QueryNode (see below) defining the
entity’s part in the query. Every query has a set of values (objects) to include (project) in the
output. These are specified as instance methods of the receiver of the message, separated by
blank spaces in the string, aProjectString. Any instance method of the receiver class may be used
in aProjectString. This includes the method self which answers the instance itself as well as
methods that answer multiple values, perform aggregate functions, or even answer other
instances.
For example, assuming that avgYTDGross is an instance method of Department which calculates
the average year-to-date gross pay of employees in the department, the following query produces
a report of departments with their budgets, average year-to-date gross pay, and a list of their
employees.
Department Project: ‘dno dname dbudget avgYTDGross EmploysC’.
The message Project: with the string ‘dno dname dbudget avgYTDGross EmploysC’ as its
parameter, is sent to the class Department which answers a QueryNode instance that, when
materialized, answers the values answered by sending those messages to each of its instances. In
OQL [Cattell, 1995] this same query would be stated as:
select struct(d: x.dno, n: x.dname, b: x.dbudget, g: x.avgYTDGross,emps: (select y from x.Employs as y))
from Department x.
From the user’s perspective, the messages dno, dname, dbudget, avgYTDGross, and Employs are
sent to x, a representative of Department, however, there is no object to which the query itself is
sent. In this sense OQL is functional and not object oriented. SOODAS is strictly object oriented
in that the only means to produce a result is to send a message to an object.
16
Queries may optionally have selection criteria and sorting criteria. Selection criteria are specified
as a code block (the select: parameter). A code block is an object containing an executable set of
Smalltalk statements (objects and messages sent to objects) enclosed in brackets. A selection
code block must evaluate to true or false. Sorting criteria are specified as a string (the orderBy:
parameter) containing the message sequence defining the ascending or descending collating
sequence.
A code block to specify a selection criterion has the following form:
[:example | example messageSequence].
example is an iterator variable or an example not unlike the use of examples in Query By
Example. It is defined within the scope of the code block. It references each instance of the
entity to which the query message is sent. Hence, the sequence of messages in messageSequence
is sent to each instance of the entity. Since the answer to a message is an object,
messageSequence can use relationship methods to reference instances in any entity to which the
receiver class is related by any sequence of relationships. If the answer from a message is a
collection (e.g., EmploysC), existential methods such as all: and any: can be used to process it.
Comparison operators such as =, >, >=, <, <=, ~= can be included in messageSequence as they
are simply messages in Samlltalk. For example, when sent as the select: parameter of a
Project:select: message sent to Employee, the following code block selects employees who have
an employee number exceeding ‘5000’:
[:e | e eno > ‘5000’].
As mentioned above, selection conditions can be specified on related entities. This is
accomplished using a message sequence that includes relationship methods. For example, the
following code block selects employees who live in states whose tax rate exceeds 5%:
[:e | e LivesIn taxRate > .05].
When sent the message LivesIn, e (an employee) answers its related TaxState instance. When
sent the message taxRate, this TaxState instance answers its taxRate.
As mentioned above, SOODAS also includes methods for set selection including any and all. For
example, the following (nested) code block, when sent as the select: parameter of a
17
Project:select: message sent to Department selects departments where all employees in the
department have ytdGross in excess of $100,000:
[:d | d EmploysC all: [:e | e ytdGross > 100000]].
d iterates over all departments. When sent the message EmploysC, d (the current department)
answers the collection of its employees. This collection is sent the message all: with the code
block [:e | e ytdGross > 100000] as its parameter. For each collection of employees to which it is
sent, e iterates over those employees answering true if all employees in the collection answer a
value greater than 100000 when sent the message ytdGross.
Furthermore, iterator variables can be referenced inside nested code blocks to select instances
based on values in related instances. For example, the following code block selects departments
where any employee who reports to the department has a ytdGross that exceeds that department’s
budget:
[:d | d EmploysC any: [:e | e ytdGross > d dbudget]].
A string that specifies a sorting criteria contains a message sequence defining the collating
sequence optionally followed by the keyword ASC for ascending or DESC for descending. If
neither keyword appears, ASC is assumed. For example, assuming the receiver is Employee, the
orderByString ‘eno ASC’ sorts employees by employee number (increasing). ‘eno DESC’ sorts in
decreasing employee number order. Objects of any type can be used for sorting provided they
have appropriately defined comparison methods. For example, assuming the receiver is
Department, the orderByString ‘EmploysC size DESC’ sorts departments in decreasing order of the
number of employees reporting to them.
The ability to join entities along relationships is a key capability of any query language. SOODAS
supports joins using QueryNode and its instance method, Join: aQueryNode using:
aRelationshipName. When sent to a QueryNode instance, this method links the QueryNode
instance aQueryNode to the query definition graph of the receiver provided it contains an entity
participating in the relationship, aRelationshipName. It answers the receiver to which another
Join:using: message can be sent. Hence, queries involving multiple joins can be easily and
naturally stated.
18
To illustrate the way in which a query graph is constructed, consider the query illustrated in
Figure 6. This query lists tax states (showing the state abbreviation and tax rate) of employees
(showing the number, name, social security number and year to date gross pay) whose year to
date gross pay exceeds $100,000, including the department to which the employee reports (name
and budget), and the department manager (name and social security number), organized by tax
state, alphabetically by employee name within decreasing order of state tax rate. It involves three
entities, TaxState, Employee, and Department. Employee plays two different roles (worker and
manager), via two different relationships (Report and Manage).
The query graph for this query is constructed as follows (see Figure 6). When sent the message
Project: ‘stateAbbr taxRate’ orderBy: ‘taxRate DESC’, TaxState creates an instance of
QueryNode (say qn1) containing the definition of this part of the query including the class to
which is to sent (e2 is set to TaxState), the projectString (project is set to ‘stateAbbr taxRate’)
and the orderByString (orderBy is set to ‘taxRate DESC’). This part of the query has no select:
clause (where is set to [], a null code block). Employee similarly creates a QueryNode instance
(say qn2) when sent the message Project: ‘eno ename ssn ytdGross’ select: [:e | e ytdGross >
100000] orderBy: ‘ename’). When sent the message Join: qn2 using: ‘PayrollTax’, qn1
connects itself and qn2 using a two way linked list (next in j1 is set to j2 and prior in j2 is set to
j1), stores the relationship (rel is set to PayrollTax in j2) and answers itself4. Department and
Employee similarly create additional QueryNode instances (say qn3 and qn4) that store the
parameters of the subsequent Join:using: messages and are appropriately interconnected to
represent the query.
A query graph specifies the logical definition of a query. How it is materialized depends on the
query optimization strategy. The current SOODAS query processor does not optimize execution,
4 brother is used if the same entity in the same role is used in multiple entity sequences, e.g., a query that joinedEmployee with PayCheck on Payroll, with TaxState on PayrollTax and with Department on Reports would usebrother in the PayCheck JoinClass instance to connect to the TaxState JoinClass instance and in the TaxStateJoinClass instance to connect to the Department JoinClass instance (each would have the Employee JoinClassinstance as their prior and nil as their next).
19
it simply materializes the query in hierarchic order as specified. Query optimization in an object
environment is an area of further research.
A QueryNode instance materializes the query result as an ordered collection of objects when sent
the message asOrderedCollection. This result can then be sent any Smalltalk message valid for
an ordered collection, including printString, which will convert it into printable form.
For example, the query:
(Employee Project: ‘eno ename ‘) asOrderedCollection printString
is executed as follows. The message Project: is sent to the Employee class with the parameter
‘eno ename’. Employee creates and answers an appropriately defined QueryNode instance. The
message asOrderedCollection is sent to this QueryNode instance which answers a collection
containing the employee number and name of each employee, including all subclass instances.
The message printString is sent to this collection which converts it into printable form. This
object could be stored in a variable, sent to the system printer or saved in a file.
Having the ability to use referents and methods in projection and selection criteria, SOODAS
provides an extremely powerful, flexible, and easy to use query language. Furthermore, by
directly implementing E-R semantics and providing entity-based data maintenance capabilities,
SOODAS provides an extremely powerful system development environment. Appendix 2
presents a number of queries that illustrate the power of its query language.
6. Summary and Directions for Future Research
SOODAS demonstrates the feasibility of directly supporting Entity-Relationship semantics using a
purely Object-Oriented paradigm. Three meta-classes, EntityObject, Relationship, and
QueryNode provide the structure and operations necessary to define, maintain, and access data
using E-R semantics. These are supported by the class PermanentObject which provides
persistence and data access capabilities and the class EntityInterface which provides support for
developing maintenance screens.
20
SOODAS includes purely object-oriented object definition (ODL) and manipulation (OML)
languages that directly support Entity-Relationship semantics. These are implemented as methods
of our meta-classes. Hence, their use can be seamlessly integrated into any Smalltalk application.
This overcomes difficulties that may be caused by the impedance mismatch between object
programming languages and functional database languages.
The SOODAS query language is extremely powerful. It supports set-oriented queries in a
straightforward and natural way. It is extensible in the sense that methods needed for complex
projection or selection criteria can be added to the appropriate entities as needed. SOODAS
queries can be seamlessly integrated into Smalltalk applications.
The current version of SOODAS can be used as a rapid prototyping tool since it enables
application developers to directly implement a conceptual object model into a working system
with minimal effort. Through EntityInterface it provides the ability to quickly generate object
maintenance screens.
SOODAS is, however, limited in several respects, each of which is the subject of further research
efforts. Currently SOODAS relies on the VisualWorks [1994] memory manager for moving data
(and methods) to and from permanent storage. Given the trend toward integrating operating
system and data management functions into objects that provide system capabilities this
architecture appears to have promise. A significant amount of research is needed to address the
efficiency issues associated with such an architecture. In particular, caching, data clustering,
indexing, and paging algorithms will need to be investigated. Alternately, SOODAS could be
ported to an OODBMS such as GemStone which directly supports Smalltalk.
Related to the memory management and data organization issues is query optimization. Query
optimization in a paged, virtual memory storage environment has received very little attention.
This problem will be even more significant in a distributed object environment where objects may
21
“live” in different geographic locations yet must still participate in query and update operations
[Guttman and Matthews, 1995].
Results of SOODAS queries are currently produced as a collection of (possible nested collections
of) objects (values and instances). Future research will address formatting issues by creating
Report as a subclass of PermanentObject with instance variables such as reportName to identify
the report, reportSpecifications containing its formatting specifications and query containing a
QueryNode instance by which to access its query. It will have instance methods such as
produceReportOn: where the parameter is the output object such as a printer or file.
Of smaller scope, but still areas requiring further research include a number of SOODAS design
issues. First, if any constraint is violated by an update operation, the operation is canceled.
Future research will be directed at the specification of alternate constraint violation actions.
Actions such as cascade delete must be supported, however, additional, user specified, actions
must also be supported. For example, if the user specifies the identifier of a non-existent entity
for a relationship, the designer may wish to allow the user to add a new instance of the related
entity. Similarly, future research will address the specification and enforcement of mutual
dependency constraints (i.e., relationships where both minimum cardinalities are greater than 0).
Second, since the Smalltalk class hierarchy is directly used to implement entities, only
generalization hierarchies with mutually exclusive subtypes are supported. SOODAS provides a
mechanism to support partition but not cover constraints. Future research will address the
specification of multiple overlapping subtypes with a full set of subtype constraints [Gottlob et al.,
1996]. Beyond this, future research will address the specification of a generalization lattice with
multiple inheritance and supertype constraints.
Finally, the current implementation does not support aggregation relationships. An aggregation is
a collection of (aggregation) entities that constitute the “parts” of another (aggregate) entity.
Such structures must include constraints specifying that instances of each of the aggregation
entities must exist for each instance of the aggregate entity.
22
From a practical perspective, SOODAS must be evaluated empirically. One of the claimed
advantages of Object Orientation is development efficiency and code re-usability. A key concern,
and one for empirical research, is the impact of a tool like SOODAS on system development
effort, query formulation, code re-use, and maintainability. Preliminary evidence is currently
being gathered by using SOODAS as the implementation environment for teaching OO
development.
7. References
Bertino, E., Negri, M., Pelagatti, G., and Sbattella, L., “Object-Oriented Query Languages: TheNotion and the Issues,” IEEE Transactions on Knowledge and Data Engineering, vol 4, no3, June 1992, pp. 223-237.
Butterworth, P., Otis, A., and Stein, J., “The Gemstone Object Database Management System,”Communications of the ACM, Vol. 34, No. 10, October 1991, pp. 65-77.
Cattell, R. G. G., The Object Database Standard: ODMG-93, Release 1.2, Morgan KaufmannPublishers, San Francisco, 1995
Coad, P., Object Models: Strategies, Patterns, and Applications, Yourdon Press Prentice Hall,Englewood Cliffs, NJ, 1995.
Copeland, G. and Maier, D., “Making Smalltalk a Database System,” Proceedings of SIGMODConference, 1984, pp. 316-325.
Dewitz, S. D., Systems Analysis and Design and the Transition to Objects, McGraw-HillCompanies, New York, 1996.
Diaz, O. and Paton, N. W., “Extending ODBMSs Using Metaclasses,” IEEE Software, May1994, pp. 40-47.
Elmasri, R., Larson, J., and Kouramajian, V., “Automatic Class and Method Generation forObject-Oriented Databases,” Proceedings Third International Conference on Deductiveand Object-Oriented Databases, December 6-8, 1993, Springer-Verlag, Berlin, 1993, pp.395-414.
Elmasri, R. and Navathe, S. B., Fundamentals of Database Systems (2nd edition), Addison-Wesley/Benjamin/Cummings, Redwood City, CA, 1994.
23
Goldberg, A. and Robson, D., Smalltalk-80, Addison-Wesley, Reading, MA, 1989.
Gottlob, G., Schrefl, M., and Rock, B., “Extending Object-Oriented Systems With Roles,” ACMTransactions on Information Systems, Vol. 14, No. 3, July 1996, pp. 268-296.
Guttman, M. and Matthews, J., The Object Technology Revolution, John Wiley & Sons, Inc.,New York, 1995.
Kilian, M. F., “Bridging the Gap Between OO and ER,” Proceedings of the 10th InternationalConference on Entity-Relationship Approach, University of Michigan Press, Ann Arbor, October 23-25, 1991, pp. 445-458.
Lewis, S., The Art and Science of Smalltalk, Prentice Hall, London, 1995.
Ling, T. W. and Teo, P. K., “Toward Resolving Inadequacies in Object-Oriented Data Models,”Information and Software Technology, (35, 5), May 1993, pp. 267-276.
March, S. T. and Rho, S., “Object Support for Entity-Relationship Semantics,” Proceedings ofWorkshop on Information Technologies and Systems, Cleveland, December 14-15, 1996,pp. 1-10.
Markowitz, V. and Shoshani, A, “Object Queries Over Relational Databases: Language,Implementation, and Applications,” Proceedings of the 9th International Conference onData Engineering, IEEE Computer Society Press, Los Altimos, CA, 1993, pp. 71-80.
Narasimhan, B., Navathe, S. B., and Jayayaman, S., “On Mapping ER and Relational Models intoOO Schemas,” Proceedings of the 12th International Conference on Entity-RelationshipApproach, Springer-Verlag, Berlin, 1994, pp. 402-413.
Norrie, M. C., “An Extended Entity-Relationship Approach to Data Management in Object-Oriented Systems,” Proceedings of the 12th International Conference on Entity-Relationship Approach, Springer-Verlag, Berlin, 1994, pp. 390-401.
O. Deux et al., “The O2 System,” Communications of the ACM, Vol. 34, No. 10, October 1991,pp.34-48.
Rumbaugh, J., Blaha, M., Premerlani, W., and Lorensen, W., Object-Oriented Modeling andDesign, Prentice Hall, Englewood Cliffs, NJ, 1991.
Rumbaugh, J., “Relations as Semantic Constructs in an Object-Oriented Language,” Proceedingsof OOPSLA Conference, October 4-8, 1987, pp. 466-481.
Shah, A., Rumbaugh, J., Hamel, J., and Borsari, R., “DSM: An Object-relationship ModelingLanguage,” Proceedings of OOPSLA Conference, November 1989, pp. 191-202.
24
Smith, J.M. and Smith, D. C. P., “Database Abstractions and Aggregations,” Communications ofthe ACM, June 1977, pp 405-413.
SQL 92, Structured Query Language 92 Standard, ANSI, 1992.
Teorey, T. J., Database Modeling and Design (2nd edition), Morgan Kaufmann, San Francisco,CA, 1994.
VisualWorks, User’s Guide, ParcPlace Systems, Inc., 1994.
Yourdon, E., Object-Oriented Systems Design, Yourdon Press-Prentice Hall, Englewood Cliffs,NJ, 1994.
Yourdon, E., Whitehead, K., Thomann, T., Oppel, K., and Nevermann, P., Mainstream Objects,Yourdon Press Prentice Hall, Saddle River, NJ, 1995.
Model
ApplicationModel
EntityInterface
Object
PermanentObject
OMLInstancesFindInstance:AddInstance:DeleteInstance:
File
JoinClass
QLJoin:using:asOrderedCollection
priorSeqprojectselectorderBye1e2relpriornextbrother
Relationship
ODLnew:and:...
Meta-OMLentitiesmax:using:min:using
OMLConnect:and:using:DisConnect:and:usingReConnect:from:to:using:RelatedTo:usingFirstFor:using:AllRelatedTo:using:
UpdatedInstanceUpdateLog
nameaccess1access2e1e2min1min2max1max2instances1instances2 Class (Instance) Variables
Class Name
Notation
Class Methods
Instance Methods
Instance Variables
EntityObject
ODLCreateEntity:...CreateSubtype:...
Identifier:Meta-OMLAttributesRelationshipssubclassessuperclassOMLAddInstance:UndoAdd:DeleteInstance:StartUpdate:UpdateInstance:UndoUpdate:QLProject:Project:select:Project:orderBy:Project:select:orderBy:
IdentifierPartitionCopyCopyID
Partition:
Figure 1. SOODAS Meta-Class Hierarchy
Employee
enoenamessnexemptionsytdGrossytdFitytdFICAytdSit
Department
dnodnamedbudget
PayCheck
checkNocheckDategrossfitsitfica
HourlyEmployee
hourlyRatecurrentHours
SalariedEmployee
salary
SalesPerson
commissionRate
TaxState
stateAbbrtaxRate
Report Payroll
sub2
sub3sub1
PayrollTax
Manage
OrgStructure
Figure 2. Example Data Model
Figure 3. An E-R Maintenance Screen
Request: Employee AttributesResponse: ‘eno ename ssn exemptions ytdGross ytdFit ytdFICA ytdSit ‘
Request: Employee RelationshipsResponse: OrderedCollection (Payroll PayrollTax Manage Report )
Request: Employee subclassesResponse: #(HourlyEmployee SalariedEmployee SalesPerson)
Request: SalesPerson superclassResponse: Employee
Request: (Relationship FindInstance: ‘Report’) entitiesResponse: OrderedCollection (Employee Department)
Request: (Relationship FindInstance: ‘OrgStructure’) max: Department using: ‘ParentUnit’Response: 1
Figure 4. Examples of Meta-data Access
Figure 5. Generated Data Maintenance Screens(ManagedBy and ParentUnit represent the relationships.
They are combo boxes in the detail screen)
(((TaxState Project: ‘stateAbbr taxRate’orderBy: ‘taxRate DESC’)
Join:(Employee Project: ‘eno ename ssn ytdGross’
select: [:e | e ytdGross > 100000]orderBy: ‘ename’)
using: ‘PayrollTax’)Join:(Department Project: ‘dname dbudget’)using: ‘Report’)Join:(Employee Project: ‘eno ssn’)using: ‘Manage’
a. Example query.
qn1 qn2select: ‘stateAbbr taxRate’ ‘eno ename ssn ytdGross’where: [] [:e | e ytdGross > 100000]orderBy: ‘taxRate DESC’ ‘ename’e1: nil TaxStatee2: TaxState Employeerel: nil ‘PayrollTax’prior: nil qn1next: qn2 qn3brother: nil nil
qn3 qn4select: ‘dname dbudget’ ‘eno ename ssn ytdGross’where: [] []orderBy: [] []e1: Employee Departmente2: Department Employeerel: ‘Report’ ‘Manage’prior: qn2 qn3next: qn4 nilbrother: nil nil
b. QueryNode instances and variables for example query.
Figure 6. The Query Graph of QueryNode Instances
Appendix 1. An Informal BNF for the SOODAS Query Language
The SOODAS query language is purely Object Oriented. A query specification is held in a graphof QueryNode instances and materialized as an ordered collection by sending any QueryNodeinstance in the graph the message asOrderedCollection. The QueryNode instances are createdby sending a query message to each EntityObject subclasses in the query. A simple query isrepresented by a single QueryNode instance. It materializes to objects that can be answered bythe instances of a single EntityObject subclass. For a complex query the QueryNode instancegraph is constructed by sending the message Join:using: to the appropriate QueryNode instancewith the appropriate QueryNode instance as the first parameter and the appropriate relationshipname as the second parameter.
query ::= aQueryNode \ (query) Join: (aQueryNode) using: aRelationshipName
aQueryNode ::= anEntity query-message
aRelationshipName ::= a relationship or access name
anEntity ::= an EntityObject subclass
query-message ::= Project: aProjectString \Project: aProjectString select: aSelectBlock \Project: aProjectString orderBy: anOrderByString \Project: aProjectString select: aSelectBlock orderBy: anOrderByString
aProjectString ::= ‘instanceMethod{ instanceMethod}’
instanceMethod ::= an instance method of the receiver of the query message
aSelectBlock ::= [:example | example messageSequence]
example ::= any legal Smalltalk variable name
messageSequence ::= method \ method messageSequence
anOrderByString ::= ‘messageSequence [ASC \ DESC]’
operator ::= any legal comparison method
Notation: { symbol } is a sequence of 0 or n symbol(s).symbol1 \ symbol2 is either symbol1 or symbol2[ ] is optional
Appendix 2. Example Queries
CategoryRequirement SOODAS Query* Comparable OQL Query
Selection, projection, and ordering criteria can include any instance method of the receiver class includingrelationship methods and aggregation methods:
List employee number,name, and departmentidentifier for allemployees.
EmployeeProject: ‘eno ename ReportsToID’.
select struct(no:e.eno, name:e.ename,dno:e.ReportsTo.dno)
from Employees e
List the departmentnumber, name, budget,the average of employeesalaries and allemployees in thedepartment, in order byaverage salary.
DepartmentProject: ‘dno dname dbudget avgSalary
EmploysC’orderBy: ‘avgSalary’.
select struct(no:d.dno, name:d.dname,budget:d.dbudget,avgSalary:d.avgSalary,emps: (select e from
d.Employs e))from Departments dorder by d.avgSalary
Selection criteria can include and, or and not operators, set membership, and reference to any entity towhich the receiver is related by any sequence of relationships.
List salaried employeeswho report to departmentA or to department Bwho are not managers.
SalariedEmployeeProject: ‘self’select: [:e | ((e ReportsToID = ‘A’) or: [e
ReportsToID = ‘B’])and: [e Manages isNil]].
select efrom SalariedEmployees ewhere (e.ReportsTo.dno = ‘A’ or
e.ReportsTo.dno = ‘B’)and e.Manages = nil
List all departmentshaving no employeesreporting to them.
DepartmentProject: ‘self’select: [:d | d EmploysC isEmpty].
select dfrom Department dwhere count(d.Employs) = 0
List all employees wholive in the same state asthe employee who hasthe maximum salary.
EmployeeProject: ‘self’select [:e | e LivesIn = (Employee
WithMax: ‘salary’**) LivesIn].
select efrom Employees ewhere e.LivesIn =
(select tfrom Employees e2, e2.LivesIn twhere e2.salary = max(select
salary from Employees)List employees who havehigher year to date grosspay than the manager oftheir department.
EmployeeProject: ‘eno ename ytdGross’select: [:e | e ytdGross > e ReportsTo
Manages ytdGross].
select struct(no:e.eno, name:e.ename,ytd:e.ytdGross)
from Employee ewhere e.ytdGross >
e.ReportsTo.Manages.ytdGrossSelection criteria can include nested set selection with operators such as any and all.
List all states that havesalespeople living inthem.
TaxStateProject: ‘self’select: [:s | s HomeToC any: [:e | e
class = SalesPerson]].
select tfrom TaxState t, t.HomeTo ewhere exists (select e from e where e in
SalesPeople)List departments whereall Employees have ayear to date gross paythat is less than theirdepartment budget.
DepartmentProject: ‘self’select: [:d | d ReportsC all: [:e | e
ytdGross < d dbudget]]
select dfrom Department d, d.Employs ewhere all (select e from e where
e.ytdGross < d.dbudget)
* Queries each illustrate capabilities of the SOODAS query language. They are defined on the example E-Rschema in Figure 2.** WithMax: aMethod is a class method of EntityObject that answers the instance of the receiver class with themaximum value of a method named aMethod. This illustrates the fact that any methods can be seamlesslyincorporated into SOODAS queries.
Recursive relationships can be traversed in projection criteria as well as in selection criteria .List departments whosebudget exceeds that oftheir parentorganizational unit.
DepartmentProject: ‘self’select: [:d | (d ParentUnit notNil) and: [d
dbudget > d ParentUnitdbudget]].
select dfrom Department d, d.ParentUnitwhere d.dbudget >
d.ParentUnit.dbudget
List all descendantorganizational units ofthe Marketingdepartment (i.e., itstransitive closure).
DepartmentProject: ‘AllChildUnitC’***select: [:d | d dname = ‘Marketing’]].
Transitive queries are not directlysupported in OQL.****
Join queries traverse relationships and can involve many entities and subclasses; a single entity can beincluded multiple times in different roles (i.e., cyclic queries are supported).
For all departments thatdo not have child units,list the departmentnumber and name inalphabetical order withall employees (numberand name) inalphabetical order withindepartment.
(DepartmentProject: ‘dno dname’select: [:d | d ChildUnitC
isEmpty]orderBy: ‘dname’)
Join: (EmployeeProject: ‘eno ename’orderBy: ‘eno’)
using: ‘Employs’.
select struct(no:d.dno,name:d.dname, eno:e.eno,ename:e.ename)
from Department d, d.Employs ewhere not exists (e)order by d.dname, e.eno
List all descendantorganizational units ofthe Marketingdepartment (i.e., itstransitive closure) withtheir salaried employees(name and salary
(DepartmentProject: ‘dno dname’select: [:d d AllParentUnitC***
any: [ :p | p dname =‘Marketing’ ]])
Join: (SalariedEmployeeProject: ‘ename salary’)
using: ‘Employs’.
Transitive queries are not directlysupported in OQL.****
List states of employeeswhose year to date grosspay exceeds $100,000,including the stateabbreviation, tax rate,the employee’s number,name, social securitynumber and year to dategross pay, thedepartment to which theemployee reports (nameand budget), and thedepartment manager’sname and social securitynumber, organized by taxstate, in decreasing orderof state tax rate.
(((TaxStateProject: ‘stateAbbr taxRate’orderBy: ‘taxRate DESC’)
Join: (EmployeeProject: ‘eno ename ssn
ytdGross’select: [:e | e ytdGross >
100000])using: ‘LivesIn’)Join: (Department
Project: ‘dname dbudget’)using: ‘ReportsTo’)Join: (Employee
Project: ‘eno ssn’)using: ‘ManagedBy’.
select struct(abbr:t.stateAbbr,rate:t.taxRate, no:e.eno,name:e.ename, ssn:e.ssn,dname:d.dname,budget:d.dbudget,meno:m.eno, mssn:m.ssn)
from TaxState t, t.LivesIn e,e.ReportsTo d,d.ManagedBy m
where e.ytdGross > 100000order by t.taxRate
*** AllChildUnitC and AllParentUnitC are instance methods of Department that are generated when therecursive relationship OrgStructure is defined. They answer the collections of all ancestors and descendants of thereceiver department, respectively.**** Transitive queries may be implemented in programming languages.