In the datamodel of AMUSE all data are stored in sets. The sets store objects and the values of attributes belonging to the objects. All objects in a set have the same attributes, but not same values for these attributes.
For every object in a set, the set will store the values of the attributes of the object. This model is like a relation database with Tables (sets in AMUSE), Records (an object in the set) , Columns (an attribute of an object) and Fields (the value of an attribute of an object).
Objects from a set do not store any values, instead they defer to the set to provide their attribute values. In a sense these objects are pointers to a location in the set. When comparing to the relational database model an object is like a cursor. It can be used to access the values of the attributes belonging to the object stored in the set.
When a user asks an object for its mass the object will query the set for the stored value and return the answer to the user.
The objects in a set can be identified with a unique key. All objects having the same key are seen as the same object by the AMUSE system. The same object can exist in multiple sets. In each set this object can have a different value of an attribute or different attributes. Or, in each set a different version of the object can exist.
The actual storage of attribute values in a set is provided by a storage model. The set provides the interface to the script writer, the storage model manages the data. Each storage model must decide how and where to store the data. All data can be stored in the memory area of the script or in the mememory area of the code or on a file or in a relational database.
The datamodel provides subsets to handle a selection of the objects in a set. When comparing to the relational database model an subset is like a view. The subset does not store any data, all the data is stored in the original set. When an attribute is updated in a subset, the attribute is also updated in the original data.