Databases

Databases Page 1 of 1
Getting Started with AVEVA E3D
Functions : Databases
Databases
The overall purpose of AVEVA E3D™ is the controlled creation of a complete three-dimensional project
design model using computer-simulation techniques. The Engineering and Diagrams products enable the
creation and control of 2D schematic and conventional engineering to support the 3D model. All information
which exists about a design project, whether administrative or technical, 3D or 2D is stored in a series of
hierarchical databases. Use of the various modules allows the user to create, modify and extract information
from these databases.
The Databases section describes:
• The purpose of each type of database
• How the detailed project information is held in each
• How the separate databases are related to each other.
1974 to current year. AVEVA Solutions Limited and its subsidiaries. All rights reserved.
http://help.aveva.com/AVEVA_Everything3D/2.1.0.3/GS/GS3.3.1.html 4/24/2019
Database Types Page 1 of 3
Functions : Databases : Database Types
Database Types
• PROJECT
• PADD (DRAW) Database
• ISOD (Spooler) Database
• SCHEMATIC Database
• ENGINEERING Database
• CATALOGUE Database
• LEXICON (Dictionary) Database
• PROPERTIES Database
• SYSTEM Database
• COMMS Database
• MISC Database
• TRANSACTION Database.
PROJECT
A project consists of the complete collection of information which relates to a single design. The project is
identified by a name, allocated by the project administrator when the project is first initiated. The project name
is used to identify the project to the system whenever the user wants to work in the project using AVEVA
E3D™ which allows access rights and use of system resources to be monitored and controlled. Refer to How
AVEVA E3D™ Data is Stored and Access Rights for further information on these functions.
There are different types of database which can go to make up a complete project:
DESIGN and DRAW Databases

• MODEL Database
• PADD (DRAW) Database
MODEL Database
The MODEL (design) databases contain all information needed to create a full-scale three-dimensional
representation of the project. For the compositions of the principal types of design element, refer Introduction
for further information.
You are normally allowed to modify the design databases which relate to their function in the design team,
and will often have permission to look at other design databases so that their work is compatible with that of
other designers.
Typical design functions, each of which may use a different design database, include:
• Equipment design (process vessels, storage vessels, pumps, heat exchangers and so on)
• Pipework design (the interconnecting pipes between the various equipment items)
• Structural design (the columns, beams, walls, stairways and so on which support and give access to the
operational equipment and pipework)
• Hangers and Supports (specialised pipe support structures).
PADD (DRAW) Database

The Production of Annotated and Dimensioned Drawings (PADD) database holds data about both the pictorial
content of drawings and about their annotation and dimensional information. It therefore holds a complete
specification of the contents of a drawing. Its use is specific to the interactive drawing module DRAW, refer to
Introduction for further information. The data in a model database will often reference data in other types of
database such as ISOD (Spooler) and 2D Design databases.
ISOD (Spooler) Database

The ISOD database holds pipework spool drawings generated by the SPOOL module, refer to Spooling for
further information.
2D Design Databases
• SCHEMATIC Database
• ENGINEERING Database
SCHEMATIC Database
The SCHEMATIC databases contain the data and connectivity information relating to the 2D schematic
model, together with cross-references to the schematic drawings related to this. The schematic data is
normally created and modified by direct graphical interaction with the related schematic drawings.
ENGINEERING Database
The ENGINEERING databases contain the conventional engineering data pertinent to the design.
Reference Databases:
The Reference databases contain all reference information needed for a design and/or project.
CATALOGUE Database
The CATALOGUE database contains a catalogue of the standard components which the user may select
when designing pipework, ducting, hangers and supports or structural steelwork. It includes:
• Dimensional details for each component
• Details of permissible connections between different components and of the bolts needed to assemble
flanged components
• Specifications of the components, which define the conditions of use for each type (maximum pressure,
temperature etc.)
• A CATALOGUE database may contain a single ‘universal’ catalogue, but it will more commonly contain a
general catalogue plus one or more specialised catalogues specific to particular design functions. Refer
to Work Area for further information.
LEXICON (Dictionary) Database

The DICTIONARY database holds the definitions of user defined attributes (UDA) and user defined element
types (UDET). User defined elements types allow objects in a database to be given a user defined name to
replace the generic name, for example an EQUI element can be called a :PUMP or :VESSEL. Additional
information can be stored in user defined attributes assigned to database elements and extracted into
drawings and reports.
PROPERTIES Database
PROPERTIES is available for storing data about material properties, which may be needed to supplement
Catalogue and Specification data for some design functions such as stress analysis. Its use is specialised and
will not be described further in this manual. Refer to Properties Constructor and XPRD databases for further
information.
Project Common Database

XPRD cross product databases contains comments available to all products.
Administration Databases
The Administration databases contain all admin information needed for a design and/or project.
SYSTEM Database
There is only one SYSTEM database in each project folder, it holds administrative information about the
composition and use of the project, including the following.
Each module requires access to one or more specific database types, and entry to the module may be
prevented if appropriate databases do not exist or if you do not have the appropriate access rights. New
databases can only be created by the Project Administrator.
• A list of databases of all categories which are usable in the project
• A list of all users, identified by name and password, who can legally access the databases, and the
operating team(s) to which they are assigned

• A list of AVEVA E3D™ modules available for use in the project
• Access control data, which defines those databases which are accessible to any specific user and
whether he may modify them or only look at them
COMMS Database
The COMMS database stores the information about who is using which module and which databases are
current. You have a separate area of the COMMS database, which can be accessed in write mode, and so
can record module changes etc. You have read access to the other users’ areas, and so can find out about
other users in the project.
MISC Database
The MISC database is used to store inter-user messages, and inter-database macros. The MISC database
can only be opened in write mode by one user at a time, but many users can read from it. All users need to be
able to write to this database, but only when they are sending messages or writing inter-database macros, or
deleting messages and macros. All users can read from the database at any time.
TRANSACTION Database
To enable the System Administrator to monitor the progress of Global commands, AVEVA E3D™. Global
stores details of issued commands in a TRANSACTION database. Transaction messages are generated in
the database each time the progress of the command changes.
• Transaction databases are only present when the installation incorporates the Global product.
How AVEVA E3D™ Data is Stored Page 1 of 1
Functions : How AVEVA E3D™ Data is Stored

How AVEVA E3D™ Data is Stored
Despite the huge power and potential of AVEVA E3D™, the database is structured in a very simple and
logical form. The database is hierarchical, a tree like structure, as illustrated below.
Note: The hierarchy below illustrates the (simplified) MODEL database hierarchy, but the SCHEMATIC,
ENGINEERING, CATALOGUE, PADD, ISOD, LEXICON and PROPERTIES databases also have a
hierarchical structure.
In this hierarchical structure all the database elements are owned by other elements, with the exception of
the WORLD. Elements that are owned by another element, for example a ZONE is owned by a SITE, are said
to be members of the owning element, for example the ZONE is a member of the SITE.
MODEL Database Element Types Page 1 of 4
Functions : How AVEVA E3D™ Data is Stored : MODEL Database Element Types
MODEL Database Element Types

• WORLD
• SITE
• ZONE
• EQUIPMENT (EQUI)
• SUB-EQUIPMENT (SUBE)
• PRIMITIVES
• STRUCTURES (STRU)
• FRAMEWORK (FRMW)
• SUB-FRAMEWORK (SBFR)
• STRUCTURAL COMPONENTS
• PIPE
• BRANCH (BRAN)
• PIPING COMPONENTS.
WORLD
When the database is first built, it is empty except for a single element named the WORLD, every database
has its own WORLD element as the first element in the hierarchy.
SITE
Below the WORLD element, the second level of the hierarchy is a SITE element. A SITE element may be
considered as a significant collection of project areas, whose size is not necessarily determined by physical
area, but by practical considerations. It may, for example be the whole project, or one part of a large project.
There can be as many SITE elements within a AVEVA E3D™ project as required for data organisation.
ZONE
The next level below a SITE element is a ZONE element. Again, a ZONE element is not necessarily used to
define a physical area, it is more likely to store similar types of item for easy reference, such as a piping
system in one ZONE element, related equipment in another, and so on. There can be as many ZONE
elements owned by a site element as required for data organisation.
Below ZONE level the hierarchy is discipline dependent, that is the elements depend on which discipline the
user is modelling.
EQUIPMENT (EQUI)
Equipment items are built up in AVEVA E3D™ using elements known as primitives. Each piece of
equipment can comprise any number of primitive shapes positioned to form the item. The primitives may be
owned directly by the EQUI element or by a Sub-Equipment element. An equipment item would typically be a
pump, or a vessel, the box, nozzles and cylinder primitives are clearly visible in the pump shown below.
SUB-EQUIPMENT (SUBE)
A SUBE is an optional element to further sub-divide an EQUI element, the SUBE element can also own
primitive elements.
PRIMITIVES
Primitives are the basic building blocks of AVEVA E3D™, they are used by other disciplines to create
catalogue components. There are many types of primitive, each with its own features, which when combined
with other primitives can represent complex shapes. Examples of primitives are nozzle (NOZZ), box (BOX),
cylinders (CYLI) and pyramids (PYRA).
STRUCTURES (STRU)
STRU elements are administrative elements, that is they exist to own FRAMEWORK elements, and allow the
project structures to be separated for ease of modelling and reporting.
FRAMEWORK (FRMW)
FRMW elements are used to store structural components in the model. A complex structure can be divided
into logical frameworks. Dividing the structure in this way allows structural modelling, and also reporting, to be
done more efficiently, for example by copying a complete FRMW. Structural components may also be owned
by a Sub-Framework element.
SUB-FRAMEWORK (SBFR)
A SBFR element is an optional element that can own structural components. Subframeworks are used to
further sub-divide complex projects or for modelling sub-assemblies within a framework.
STRUCTURAL COMPONENTS
Structural profiles are represented in AVEVA E3D™ by general section (GENSEC) elements. I-section profile
sizes are selected using a Section Specification that references standard catalogue data for section sizes
complying with various national standards. Plates are represented by panel (PANE) elements.
PIPE
PIPE elements are administrative elements, that is they exist to own BRANCH elements, and allow the project
structures to be separated for ease of modelling and reporting. Pipes may be considered like lines on a flow
sheet, they may run between several end connection points and are usually grouped by a common
specification and process.
BRANCH (BRAN)
Branch elements are sections of a pipe, which have known start and finish points. In AVEVA E3D™ the start
and finish points are called the Head and Tail. Heads and tails may be connected to nozzles, tees or other
Heads and tails, depending on the configuration of the pipe, or left open ended.
PIPING COMPONENTS
A BRAN element can own a wide variety of components such as gaskets (GASK), flanges (FLAN), tees
(TEE), valves (VALV), elbows (ELBO) and so on. These form the shape and geometry of the BRAN and
ultimately the pipeline itself.
Piping components are selected using Piping Specifications that reference standard catalogue data. For
example, each time the user wants to use a 100mm bore elbow, AVEVA E3D™ always accesses the data for
it from the component catalogue. The data for this remains constant no matter how many 100mm bore elbows
are used in the design.
Attributes Page 1 of 3
Functions : How AVEVA E3D™ Data is Stored : Attributes
Attributes
Every element in a project database has a fixed set of properties known as its attributes. Some attributes are
common throughout the range of elements while others differ according to the type of element involved. For
example, a cylinder (CYLI) has HEIGHT and DIAMETER attributes whilst the size of a box (BOX) is
determined by XLENGTH, YLENGTH and ZLENGTH attributes, as illustrated below:
When an element is created, a set of appropriate attributes are entered into the database. The attributes will
vary according to the type of element but essentially the process is the same. For example, a cylinder has the
following attributes:
Attribute Default Value
NAME Name if specified or hierarchy description
TYPE CYLI
LOCK false (the element is not locked)
OWNER the name of the owning element or its hierarchy description
POSITION N 0mm E 0mm U 0mm (relative to its owner)
ORIENTATION Y is N and Z is U (relative to its owner)
LEVEL 0 10 (this is a representation level setting)
OBSTRUCTION 2 (it is a solid hard element for clashing purposes)
DIAMETER 0 mm
HEIGHT 0 mm
NAME
Every element in project can be named, whether named or not every element will have a unique system-
generated reference number. If a name is not specified, then a hierarchy description will be displayed in the
Model Explorer, refer to Navigate to a Given Element for further information. Internally the reference number
is used as it cannot change. A table of names against reference numbers is maintained for this purpose.
All names begin with a forward slash character (/), which is considered to be part of the name. In order to
save you the effort of typing this, all of the forms you encounter will add the forward slash for them when you
press Enter after typing a name. The forward slash character is not shown in the Model Explorer. The
WORLD has a special name in AVEVA E3D™, /*.
Note: Names cannot contain spaces and are case sensitive. For example, /E1302A is a different name
from /E1302a or /e1302A. Elements in a project database are unique, that is they cannot have the
same name or reference number.
TYPE
The TYPE attribute refers to the specific type of element it is, for example: EQUI is an Equipment type.
LOCK
The LOCK attribute determines if an element may be changed or not. If an element is locked, its LOCK
attribute is set to the value TRUE, preventing it from being modified until unlocked. By default, LOCK is false.
OWNER
The different levels in the hierarchy are maintained by an Owner-Member relationship. An EQUI will have
ZONE as its owner, while a CYLI might well be one of the EQUI’s members. The owner is that element which
is directly related to the current element at the next level up in the hierarchy, as shown in the diagram below:
The element on the upper level is the owner of those elements directly below it, for example the equipment
(EQUI) element owns the primitive (CYLI). The lower level elements are Members of the owning element, for
example the EQUI element is a member of the ZONE element.
POSITION
Many items in a database have a POSITION attribute which is the position of the element in relation to its
owner. All primitives have a position attribute which relates to its point of origin. As each primitive has a
different Point of Origin changing the position attribute will have the effect of moving the cylinder to some
other position with its point of origin positioned on the new co-ordinates.
ORIENTATION
By default, a cylinder is created in a vertical direction; that is, with one of its ends facing up. The orientation
attribute allows this to be changed to any angle on any axis.
LEVEL
AVEVA E3D™ can produce different representations of an item, depending on how it has been modelled
and the representation levels used. The default level is 0 to 10 but levels can be set beyond this range if
needed.
For example, steelwork profiles can be represented by centreline (stick representation) only or by the full
detail of the section profile. By manipulating level settings it is, therefore, possible to have simple or complex
representation of elements for AVEVA E3D™ display or DRAW drawings.
OBSTRUCTION
The OBSTRUCTION attribute is used to declare whether an element is solid or not. Obstructions can be
declared as Hard, Soft or No Obstruction, depending on the value of the OBSTRUCTION attribute. The
default value of 2 results in a Hard obstruction, 1 results in a Soft obstruction (used for walkways,
maintenance access and so on) and 0 is for No Obstruction (used to save computing time when elements are
enclosed in another element which acts as an overall obstruction).
HEIGHT
The height of the cylinder.
DIAMETER
The diameter of the cylinder.
UDAs (User Defined Attributes) Page 1 of 1
Functions : How AVEVA E3D™ Data is Stored : UDAs (User Defined Attributes)
UDAs (User Defined Attributes)

A UDA type of attribute is defined and assigned to elements using the LEXICON module by the system or
project administrator. A UDA is just like any other attribute but may be specific to the company or the
particular project. The setting of the UDA is up to the user, although it may have been set to a default value.
Changing this is the same as with all other attributes. Their current values may be found by querying the items
attributes. A UDA can be recognised by the colon placed in front of it:
:COLOUR (User Defined Attribute)
:HEIGHT (Normal Attribute)
Pseudo-Attributes Page 1 of 1
Functions : How AVEVA E3D™ Data is Stored : Pseudo-Attributes
Pseudo-Attributes
These are attributes that are set by the system for a specific purpose, and cannot be changed by the user.
Attributes Window Page 1 of 1
Functions : How AVEVA E3D™ Data is Stored : Attributes Window
Attributes Window
The Attributes window displays the attributes that have been specified for the current selected element (CE),
dependent upon the users access rights, some attributes can be modified. Attributes can also be configured
so that they are not displayed in the Attributes window, refer to the system administrator or Attributes
Window for further information.

Databases

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Databases

Uploaded by

Copyright:

Available Formats

Databases Page 1 of 1

Getting Started with AVEVA E3D

Getting Started with AVEVA E3D

Functions : Databases : Database Types

DESIGN and DRAW Databases

PADD (DRAW) Database

ISOD (Spooler) Database

LEXICON (Dictionary) Database

Project Common Database

operating team(s) to which they are assigned

Getting Started with AVEVA E3D

Functions : How AVEVA E3D™ Data is Stored

Getting Started with AVEVA E3D

MODEL Database Element Types

Getting Started with AVEVA E3D

Functions : How AVEVA E3D™ Data is Stored : Attributes

Attribute Default Value

NAME Name if specified or hierarchy description

LOCK false (the element is not locked)

OWNER the name of the owning element or its hierarchy description

POSITION N 0mm E 0mm U 0mm (relative to its owner)

ORIENTATION Y is N and Z is U (relative to its owner)

LEVEL 0 10 (this is a representation level setting)

OBSTRUCTION 2 (it is a solid hard element for clashing purposes)

Getting Started with AVEVA E3D

UDAs (User Defined Attributes)

:COLOUR (User Defined Attribute)

:HEIGHT (Normal Attribute)

Getting Started with AVEVA E3D

Functions : How AVEVA E3D™ Data is Stored : Pseudo-Attributes

Getting Started with AVEVA E3D

Functions : How AVEVA E3D™ Data is Stored : Attributes Window

You might also like