AIMS Database Scheme, Organisation and Security
Current as on 23rd December 2003
Document #02
The AIMS
database has two major branches, namely, the Asset database and the
Evolutionary Cycle database. Together they completely describe the AIMS database
structure. Both these databases are interdependent, structurally and
conceptually.
Additional Notes on the Evolutionary Cycle DB Structure
Each value is stored as a string, irrespective of how it is initially obtained (integer, real, string, etc.)
Each subprop has a subprop ID, name of the subprop in the form of a string, a description of the subprop, and the actual values associated with that subprop.
Each subprop can have one or more values associated with it.
Each property dataset has a property ID, name of the property in the form of a string, a description of the property, subprops associated with it, and a set of values associated with the property itself.
Note that each property can have a set of values, irrespective of any subprops present or otherwise.
Each evolutionary cycle has an ID, name of the cycle in the form of a string, a description of the cycle in the form of a string, and properties associated with that cycle.
An evolutionary cycle is a set of stages.
The Administrator can alter the chronological order of stages present in a lifecycle.
Any number of stages, properties, sub-properties or values can be added, any time after the initial creation of a lifecycle.
Additional Notes on Asset DB Structure
All IDs are strings. The AIMS software automatically assigns these IDs. These Ids need not be consecutive, or in any particular order. The software will use them more, than the User.
Signalname, Imagename, Audioname and Videoname are short string descriptions of the respective files.
Filename represents the full path file name in the form of a string.
Audio, Video and Image files are opened by the operating system, using their respective file viewers.
A note consists of a note ID, a short description of what the note is for, and the images, audios, signals and videos associated with it.
Each part has a part ID, name of the part in the form of a string, a short description of the part in the form of a string, lifecycle information (including different stages, properties/subprops of stages and their properties), and additional notes.
Each part can have several notes - a good example where this will be useful is when several experiments / tests are performed on a part resulting in images taken, signals acquired and videos filmed. Note that there is no limit on the number of such notes for a given part.
Each component has a component ID, name of the component in the form of a string, a short description of the component, its constituent parts, lifecycle information (including different stages, properties/subprops of stages and their properties), and notes.
Each component can have any number of parts, and any number of notes associated with it.
Similarly, a System can have any number of Components, and an Asset can have any number of Systems.
Both the System and the Asset has lifecycles associated with them. This arrangement gives maximum flexibility in characterising the asset with very fine granular information.
Only the filenames are stored in the database; image / audio / video contents are stored separately in Admin defined folders.
Any number of branches can be added, at any time, after the initial creation of the asset. Which means, any number of systems, components, parts or notes can be added at any time.
Relationship between Asset and Lifecycle Databases
One can develop an asset database and a lifecycle database, completely independent of each other. At any stage later, either of them can be related to one another.
However, for each asset / system / component / part, an individual lifecycle can be assigned. These individual lifecycle can either be populated with available data, or left blank for later use.
For example, if an asset has three systems, two components per system and two parts per component, the database would like something like this (probable IDs are shown in brackets):
Asset (A1) Lifecycle (A1) - lifecycle details of the asset
System (A1S1) Lifecycle (A1S1) - lifecycle details of the System 1
Component (A1S1C1) Lifecycle (A1S1C1) - lifecycle details of Comp. 1
Part 1 (A1S1C1P1) Lifecycle (A1S1C1P1) - Part 1 lifecycle
Part 2 (A1S1C1P2) Lifecycle (A1S1C1P2) - Part 2 lifecycle
and so on.
It is nor necessary for each lifecycle to be populated with data. Depending upon the case, they can be left empty. Also, each of these lifecycle details can be independent of each other, but they need to be consistent with each other.
Once a lifecycle (root) is assigned, all the branches of that root are automatically assigned too - irrespective of whether branches are filled with values or not - i.e., some or all the branches can be empty.
Once the lifecycle (root) or a lifecycle stage (root) is assigned, only the empty template is assigned - values need to be filled in separately. The data for any of the lifecycle stages / properties / subprops / values, can be filled at any time, asynchronously (i.e., in any order, even randomly).
If a lifecycle (root) or a lifecycle stage (root) is unassigned, i.e., deleted, all the data in the branches are completely deleted.
Security
OS defined security will be used throughout.
No
encryption for the moment.
Last Updated on