# Glossary of Terms and Definitions
There are some fundamental concepts that are used in and referred to throughout the DDB platform and documentation.
# Environments
DDB has three different environments with different purposes.
| Environment | URL | Description | When to use |
|---|---|---|---|
| Development | dev.ddb.arup.com | The first is our DDB Development Site, used primarily by the Development Team to test new features. This server is wiped regularly without warning, so don't store any live project data there. The DDB Team is not responsible for data loss stored in this environment. | Use this environment when exploring your data model. It is okay to break things. |
| Sandbox | sandbox.ddb.arup.com | The second is our DDB Sandbox Site, used by early adopters and workshop participants to test out features and get familiar with the user interface. Data will not be wiped at random here, but you should not use this site for storing live project data | Use this environment when the data model of your App has been established. Use this environment when developing your App. Use when entering test data, which should not be erased. |
| Production | ddb.arup.com | Finally, we have the DDB Production Site. This server hosts live project data and is secure. Feature updates made to this site are only implemented after thorough testing on the Dev and Sandbox servers. | Use this environment when the data model and the App flow has been well tested and established. |
# Project
A Project is a collection of information linked to a Job Number. Each Project on DDB has its own page.
# How is this information stored?
The project is broken down into assets and parameters.
# Asset
Assets are physical things such as a site or a system within a project. These are all things that will be physically present and will have parameters assigned to them.
# Asset Hierarchy
The Asset Hierarchy is the way in which the assets are organised. An asset can have a parent asset and child assets i.e. a site (parent) contains one or more buildings (children of site), and each building contains one or more systems (children of Building). These relationships are predefined in DDB.
The asset hierarchy is required to be set up from top to bottom. Therefore even if you are trying to tackle data at very bottom of the tree hierarchy, you will need to create the top level asset instances. To read more about asset tree hierarchies and parent/child relationships refer here.
# Parameter
Parameters are characteristics of assets. These are the values that are typically used in calculations and reports. Each parameter can be tagged to allow for effective organisation of parametric information. Parameters can be client name, density, temperature, embodied carbon and many more.
There are several components to a parameter, such as type, unit and value. e.g.
| Parameter | Example |
|---|---|
| Parameter Type | Length |
| Unit | m |
| Value | 7 |
| Parent Asset | Test Room |
# DDB Types
DDB Data is defined in terms of types and instances, much in the same way Revit data is structured into Families and instances. These types provide structure to the data and outline what data should be included in the instance itself. For example, an Asset Instance will be defined by an Asset Type and a Parameter Instance will be defined by a Parameter Type.
"Building" is an Asset Type and the building on your project called "Building A" is an Asset instance. "Temperature" is a Parameter Type and the temperature of "Building A" is an Parameter instance.
Another way to think about it is that Types can exist in multiple places (such as having multiple buildings on a project), but instances can only exist in one place and contain specific data needed for your project.
For more information about DDB Types, see the Data Structure section.
# ID/GUID
A GUID ('Globally Unique Identifier') is a 128-bit text string that represents an identification (ID). DDB uses GUIDs to identify Types, Instances and projects.
For example, your project can be identified by the job number or by the unique ID that can be found in the URL such as 55c434c8-3817-4cc1-b7ec-f8e25e79ad67.
# Tag
Tags provide contextual information, allowing you to label parameters in ways that might be more project specific. Tags are available in many categories, allowing you to sort your parameters based on the discipline that uses them, the calculation they are used in, or even the report that requires them. Tags provide valuable metadata associated with your data.
An example might be to tag all parameters associated with thermal comfort.
# Data Types
Within DDB, project data is stored in a variety of data types. These dictate the type of values that each parameter can hold and define the operations that can be performed on the data.
The data types used in DDB are:
- String - a combination of characters such as letters, numbers, and symbols. These are often used to store names or words. E.g. "England"
- Integer - this data type is used to store whole numbers, typically used for quantities of assets. E.g. 12
- Float - this is used to store fractional numeric values, used to store the majority of technical parameters. E.g. 5.24
- Boolean - this can either be a 'true' or 'false' value, usually used to mark whether something is required or not. E.g. true
- Date - this is a particular date, usually used to mark things such as project start or end dates.
# Information Sources
Within DDB, the source of all our information is identified. These sources have types, sources, and references (where applicable) assigned to them. Some examples of source types and sources include:
- Automatically Populated - For parameters that have a process that automatically fills them, such as ADS information that is generated when the project is added to DDB.
- Client brief - For values that are required by the client.
- Legislation - For limitations required by governing bodies.
- Derived value - For values that have been generated by a calculation, such as via DesignCheck or another process such as a model simulation.
Other source types include project documentation, assumptions, industry guidance, academic journals, surveys, or official publications.
# Data Quality
For every parameter in our project, we can see the version history of the data, the source of the information, and can clearly see the level of quality assurance for each entry.
The levels of quality assurance are Unanswered, Answered, Checked, and Approved. At any point, it can be rejected and will go back to the start of the QA process:
- Unanswered - this is an empty field; no data has been input yet.
- Answered - data has been entered, and we can see this with full traceability.
- Checked - the previously input data has been checked in line with project procedures.
- Approved - the information has been approved in line with project procedures.
- Rejected - the information has been rejected and marked for change.
# User Permissions
DDB has defined user permissions to control access to sensitive information. User permissions are role-based, which means DDB users can be assigned varying levels of access based on defined roles.
There are five roles - reader, editor, checker, approver, and admin.
See the user permissions guide for more infomation.