A holistic microclimate model

You are here: Technical Model Webpage » filereference » The ENVI-met Database System

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
Next revisionBoth sides next revision
filereference:dbssystem [2015/03/29 22:32] – [The Database Manager] enviadminfilereference:dbssystem [2021/07/26 21:06] – enviadmin
Line 6: Line 6:
  
 To link the information stored in the Area input files with the different database information, ENVI-met uses a [[wp> relational database]]:   To link the information stored in the Area input files with the different database information, ENVI-met uses a [[wp> relational database]]:  
-Each database entry is defined by a unique key, which has to be a **two-sign alphanumerical ID** in ENVI-met (e.g. "''a0''"). Any reference to a database entry, may it be in an Area Input file or some other table of the database  is given by using this ID. For example, if you have defined a plant "''a0''" in your plant database, you can place it on a grid by setting the ID "''a0''" to this grid point. +Each database entry is defined by a unique key, which has to be a **six-sign alphanumerical ID** in ENVI-met. Any reference to a database entry, may it be in an Area Input file or some other table of the database  is given by using this ID. For example, if you have defined a plant "''0000a0''" in your plant database, you can place it on a grid by setting the ID "''0000a0''" to this grid point. 
  
 The ENVI-met database system is a global system which is used for each simulation and all ENVI-met applications.  The ENVI-met database system is a global system which is used for each simulation and all ENVI-met applications. 
Line 14: Line 14:
 ===== Database Design ===== ===== Database Design =====
  
-[{{ :filereference:dbdesign_small.png?nolink 600 |Design of the ENVI-met database system in V4}}]+[{{ :filereference:dbdesign_small.png?nolink 600 |Design of the ENVI-met database system}}]
  
 Each ENVI-met database, System or User/Project, holds the following tables:  Each ENVI-met database, System or User/Project, holds the following tables: 
Line 35: Line 35:
 If they all use different IDs, the resulting set will be simply the sum of the items in both databases with all items available. However, if you use the same ID for items in both the System DB and the User/Project DB, the user content in the User/Project DB will overwriten the System DB item.  If they all use different IDs, the resulting set will be simply the sum of the items in both databases with all items available. However, if you use the same ID for items in both the System DB and the User/Project DB, the user content in the User/Project DB will overwriten the System DB item. 
  
-In the example below, the System DB introduces 3 elements: ''AA'', ''BB'' and ''CC''. In the User DB, the elements ''BB'' and ''DD'' are defined (here in red to mark their orign).  The final result of elements will be ''AA'', ''BB'', ''CC'' and ''DD'' in which ''BB'' and ''DD'' are the items defined in the User DB. The item ''BB'' in the System DB will be overwritten and is not available until the item of the same ID will be removed from the User DB.+In the example below, the System DB introduces 3 elements: ''0000AA'', ''0000BB'' and ''0000CC'' (Let's skip the first four signs for readability). In the User DB, the elements ''BB'' and ''DD'' are defined (here in red to mark their orign).  The final result of elements will be ''AA'', ''BB'', ''CC'' and ''DD'' in which ''BB'' and ''DD'' are the items defined in the User DB. The item ''BB'' in the System DB will be overwritten and is not available until the item of the same ID will be removed from the User DB.
  
-[{{ :filereference:dblogic_small.png?nolink 500 |Logic of merging database items}}] +{{ :filereference:dblogic_small.png?nolink 500 |Logic of merging database items}}
  
  
Line 51: Line 51:
 However, if you have a lot of different projects or very specific projects, it might not be the best idea to store all the user-defined items in one big database. Especially if you want to adjust certian properties of items, e.g. soil materials, for certain simulations or projects, it might be undesirable that these material changes will effect all other simulations as well - which will be the case if edited in the global User Database. However, if you have a lot of different projects or very specific projects, it might not be the best idea to store all the user-defined items in one big database. Especially if you want to adjust certian properties of items, e.g. soil materials, for certain simulations or projects, it might be undesirable that these material changes will effect all other simulations as well - which will be the case if edited in the global User Database.
  
-For an easier handling of data, ENVI-met gives the option to specify an individual **//Project Database//** for each project. This Project database is structured in the same way as the User Database (and the System Database), but it will only be used in simulations within the assigned project. The usage of a Project Database is optional. If no Project Database is specified, the global User Database will be used. :!: Not implemented in the Preview Versions so far+For an easier handling of data, ENVI-met gives the option to specify an individual **//Project Database//** for each project. This Project database is structured in the same way as the User Database (and the System Database), but it will only be used in simulations within the assigned project. The usage of a Project Database is optional. If no Project Database is specified, the global User Database will be used.