![]() |
![]() |
![]() |
|
| 3.2 Service Complex: Object Management | |||
| SOM01 - Creating, Storing, Administration of Data Structures and Data of the SDE |
LOBV01 - Datenstrukturen und Daten der SEU erstellen, speichern, verwalten
1 Allocation to V-Model and Methods Allocation
2 Brief Characteristics
3 Requirements
3.1 Requirements for Interfaces
| SOM01.I.1 | Data and message interfaces |
It is possible to exchange data and messages without further transformation with other tools via disclosed and documented interfaces. Without further transformation means that the data and message exchange between individual tools is realized via standardized sections from the schema definition of SOM01 (e. g. data for data flow modeling via a standardized meta-structure to data flow diagrams). |
| SOM01.I.2 | Interface to SSEC03 - Access Control | All access trials to objects that are subject to the object management are first subjected to the access control. |
3.2 Requirements for the Methods Support
3.3 Requirements for Functions
| SOM01.F.1 | Central data management | |
| SOM01.F.1.1 | Repository |
A logic central data management (repository) exists where the description and administration of all metadata of the SDE and the corresponding interconnections will be realized. It is not necessary that the storage of the data management is physically contiguous. |
| SOM01.F.1.2 | Storage of graphics |
It is possible to store graphics together with the information they are based on in a central database. Based on this information the graphics can be automatically reproduced. The (sub-) information which is the basis for the graphics can be linked with other information in the central database. |
| SOM01.F.1.3 | Modification of graphics | After the modifications of a graphic picture the information that graphics are based on is automatically updated as well in the central database-and vice versa. |
| SOM01.F.1.4 | Predefined submodels | There are predefined meta-models where all meta-objects of a minimum SDE equipment have been described. |
| SOM01.F.1.5 | Links |
It is possible to link all objects with each other and also to dissolve these links. It must be possible for the user to initiate setting up or dissolving links. E. g. during the data flow modeling it must be possible for the user to allocate E/R submodels to data stores, data flows, and processes of a certain data flow diagram. This allocation can also be dissolved by the user. |
| SOM01.F.2 | Schema definition | |
| SOM01.F.2.1 | Data Description Language | A data description language exists to formulate the data schema including the metadata schema. |
| SOM01.F.2.2 | Object types | It is possible to define object types. |
| SOM01.F.2.3 | Association | It is possible to define associative object types. |
| SOM01.F.2.4 | Subtypes | It is possible to define subtypes. |
| SOM01.F.2.5 | Binary relationship types | It is possible to define binary relationship types between object types. |
| SOM01.F.2.6 | Cardinalities | It is possible to print out cardinalities for relationship types. |
| SOM01.F.2.7 | Attributes | It is possible to define attributes for object types. |
| SOM01.F.2.8 | Unstructured attributes | It is possible to define unstructured attributes of optional lengths (long fields). |
| SOM01.F.2.9 | Domains | It is possible to define domains and to allocate them to objects. |
| SOM01.F.2.10 | Structure nesting | It is possible to structure complex object types. |
| SOM01.F.3 | Databases | |
| SOM01.F.3.1 | Views | It is possible to define views for database. |
| SOM01.F.3.2 | User allocation | It is possible to allocate databases to users. |
| SOM01.F.3.3 | Private | It is possible to set up both public and private databases. |
| SOM01.F.3.4 | Project-specific | It is possible to set up project-specific databases. |
| SOM01.F.4 | Keys | |
| SOM01.F.4.1 | Primary keys | It is possible to define a primary key for each object type. |
| SOM01.F.4.2 | Secondary keys | It is possible to define secondary keys. |
| SOM01.F.5 | Access | Generally it is possible to read, write, modify, and delete every object. |
| SOM01.F.6 | Persistence | All objects (including meta-objects) are permanently stored between two accesses. |
| SOM01.F.7 | Schema modifications | |
| SOM01.F.7.1 | Meta-objects | It must be possible to read, write, modify, and delete it each meta-object of the schema (object types, relationship types, views, etc.). |
| SOM01.F.7.2 | Schema modification | It is possible to modify the schema. |
| SOM01.F.7.3 | Data acceptance | In case of schema modifications it is possible to transfer the previously stored data to the new schema. |
| SOM01.F.8 | Attributes | It must be possible to read the attributes of every object; it must also be possible to modify all of them with the exception of the key attributes. |
| SOM01.F.9 | Multi-user processing | It is possible for all operations to be executed by several users simultaneously. |
| SOM01.F.10 | Transactions | |
| SOM01.F.10.1 | Transactions | It is possible to realize transactions. |
| SOM01.F.10.2 | Rollback | After canceling a transaction, it is possible to automatically reset to the state prior to the begin of the transaction. |
| SOM01.F.10.3 | Forced rollback | It is possible to reset a transaction. (rollback) explicitly. |
| SOM01.F.10.4 | Nesting | It is possible to nest transactions. |
| SOM01.F.11 | Structured objects (complex objects) | |
| SOM01.F.11.1 | Structured objects | It is possible to define and administer structured objects. |
| SOM01.F.11.2 | Unit | There are operators to generate, process and delete handling the structured objects as a unit. |
| SOM01.F.12 | Operating modes | |
| SOM01.F.12.1 | On-line | On-line data access is possible. |
| SOM01.F.12.2 | Batch | Data access in background mode (batch) is possible. |
3.4 Other Requirements
![]() |
![]() |
GDPA Online
Last Updated 01.Jan.2002
Updated by Webmaster
Last Revised 01.Jan.2002
Revised by Webmaster
![]() |