of all database operations so that transactions can be undone or redone to guarantee database consistency.
• Optionally, a recovery manager, Karlsson [125], can be activated to ensure database persistency. The recovery manager is responsible for automatically maintaining persistency of a database that is exposed to transactions. Persistency and backup, with respect to secondary storage, is in AMOS accomplished by flushing the file to disk for each transaction and saving the database to disk periodically. By log-ging transactions to disk, the database can be recovered after a main-memory crash.
The architecture of AMOS permits extensions to be made on all levels that were de-scribed in Section 3.4 and the extensibility of AMOS will be further discussed in Sec-tion 4.4.
that have unique object identifiers. Surrogate objects represent physical or abstract and external or internal concepts, e.g. mechanical components and assemblies such as a skin panel or a wing in an aircraft design, finite elements, geometrical elements. System-spe-cific objects, e.g. types and functions, are also treated as surrogate objects.
Figure 15. The basic constructs and relations of the AMOS data model.
Types are used to structure objects according to their functional characteristics, in other words it is possible to structure objects into types. Types are in themselves related in a type hierarchy of subtypes and supertypes. Subtypes inherit functions from supertypes and can have multiple supertypes. In addition, functions can be overloaded on different subtypes (i.e. having different implementation for different types). The current type tax-onomy of AMOS is presented in Figure 16.
Functions are defined on types, and are used to represent attributes of, relationships among, and operations on objects. Examples of functions for these different categories might be diameter, distance, and move_point. It is possible to define functions as stored, derived, procedure or foreign. A stored function has its extension explicitly stored in the database, whereas a derived, procedure, or a foreign function has its exten-sion defined in an AMOSQL query, an AMOSQL procedure, or a function in an exter-nal language. Furthermore, functions can be defined as one- or many-valued and are
in-TYPES FUNCTIONS
OBJECTS
operate on
participate in
classify belong to
operate on participate in defined with
constrain
defined withconstrain
trigger monitor
RULES
vertible when possible. Stored and some derived functions can be explicitly updated us-ing update semantics but other functions need special treatment for updates. Advanced OO query-languages also provide object views [127] capabilities to support data inde-pendence. In AMOSQL, views are supported through derived functions. Functions pro-vide an associative access to objects and are uniformly invoked independently of whether they represent stored or derived data. This makes it possible to change the un-derlying physical object representation without altering the access queries. Since func-tions can be optimized they support a higher level of data independence than methods.
Figure 16. The current type taxonomy of AMOS with text-boxes indicating entities and arrows indicating is-a relationships.
Functions can further be overloaded, i.e. functions defined for different combinations of argument types can share the same name. This is also referred to as a special form of polymorphism. The selection of the correct implementation of an overloaded function is made at function invocation based on the actual argument types. A variant of an
over-Amos Type
Function
Rule
Object
User type
Relation
Literal User type obj.
Index
Cursor
Saga
Monitor Monitor inst. Monitor act.
Number
Charstring
Tuple
Multiset Boolean
Bag
Vector
List Relation
Boolean
Bag int.
Bag real
loaded function, i.e. a specific implementation, is called a resolvent. AMOS supports overloading for all four basic types of functions and automatically handles the selection of early binding (compile time) and late binding (run time) of functions. Overloading of functions on the result types is not currently supported.
In addition, AMOS supports multi-directional functions, i.e. a function can be applied for different binding patterns. A binding pattern defines which of the arguments and the results that are bound, and which that are unbound, in a function invocation. In this way, functions can be applied for several “directions”, or binding patterns, making the func-tion similar to a relafunc-tion. For stored, derived, and procedural funcfunc-tions, this multi-direc-tional capability is automatically supported where applicable. In the case of foreign functions, the user must explicitly define the applicable variants of the multi-directional function.
A thorough presentation of the AMOS treatment of overloading and multi-directional functions is given in [19] [86] [87].
4.3.2 AMOSQL data management
AMOSQL provides statement constructs for typical database tasks, including data def-inition, population, updates, querying, flow control, and session and transaction control.
Data schemas can be defined, modified, and deleted by means of AMOSQL statements.
The definition of types, functions, and objects is performed through a create state-ment. For example, types may be defined by a create type statement as:
create type named_object(name charstring);
create type fea_object subtype of named_object;
create type element subtype of fea_object;
create type node subtype of fea_object;
where a stored function, name, is defined as a character string within the parentheses of the named_object type. A new type becomes an immediate subtype of all supertypes provided in the subtype clause, or if no supertypes are specified, it becomes an imme-diate subtype of the system type UserTypeObject.
Functions can also be defined separately from the types by a create function state-ment, exemplified by the nodes function that relates elements to nodes:
create function nodes(element e1) -> bag of node n as stored;
A database is populated with objects with a create type statement with or without initialisation of functions, and where type stands for the specific type to be instantiated.
For example, some nodes and elements can be created by the following statements1:
create node (name) :n1 (“n1”), :n2 (“n2”), ...
:n16 (“n16”);
create element (name, nodes)
:e1 (“e1”, bag(:n1, :n2, :n6, :n5)), :e2 (“e2”, bag(:n2, :n3, :n7, :n6)), ...
:e9 (“e9”, bag(:n11, :n12, :n16, :n15));
Derived functions are defined in a similar manner as stored functions with a single AMOSQL-query as the function body. An example of a derived function is presented as the topology function below1:
create function topology(element e1) -> element e2 as select distinct e2
for each element e2
where nodes(e1) = nodes(e2) and e1 != e2;
The topology defines how elements are related to each other. When the topology func-tion is accessed, it derives the elements e2 that have some common node with element e1, i.e. the elements that are connected to a given element. An example shows the to-pology for elements 1 and 5, respectively2.
name(topology(:e1));
“e2” “e4” “e5”
name(topology(:e5));
“e1” “e2” “e4” “e6” “e8” “e9” “e7” “e3”
Querying a database for objects having specified properties is made using a select statement. For instance the nodes of :e1 in the example earlier can be retrieved by the following query:
select name(nodes(:e1));
“n1” “n6” “n5” “n2”
Functions are also invertible (not always) and it is therefore possible to use the nodes 1. Variables preceded by colon, such as :n1, are global interface variables used by
AMOSQL to hold query results temporarily during a session and to share values with foreign languages.
1. The “=” operator in this case compares each element in the bags.
2. Functions can be composed in accordance with the DAPLEX semantics [119]. This means that if the result of an inner function is multiple-valued, the subsequent outer function is applied to each value.
function in the opposite direction which can be expressed as:
select name(e) for each element e where nodes(e) = :n1;
“e1”
Deletion of types, functions, and objects is performed through a delete statement as:
delete type element;
delete function nodes;
delete :e1;
In addition to database population by object creation and attribute assignments it is pos-sible to use function update statements set, add, and remove, and type update state-ments add and remove. Examples of update statements for functions are:
set nodes(:e1) = bag(:n1, :n2, :n6);
add nodes(:e1) = :n5;
remove nodes(:e1) = :n2;
A more complete presentation of data management capabilities in AMOS and AMOSQL is presented in [9].