Jump to: navigation, search

Difference between revisions of "Entity Data Model"

(→‎Relating objects)
 
(74 intermediate revisions by the same user not shown)
Line 1: Line 1:
 +
Get to know about the relational data- and object model used in {{UBIK}} beginning from a rather figurative and abstract point of view. We will introduce the essential parts of the object model and show how these items are connected to a real system.
 
==Introduction==
 
==Introduction==
 
===Objectives===
 
===Objectives===
Line 39: Line 40:
 
<strong>
 
<strong>
 
* Design a descriptive model including all required blocks and properties of the system
 
* Design a descriptive model including all required blocks and properties of the system
−
* An object in this model specifies possible properties for a certain part of the real system
+
* Specify the possible properties for the parts of the real system
 
</strong>
 
</strong>
  
Line 52: Line 53:
  
 
<strong>
 
<strong>
−
{{Checked}} Theoretical blocks representing the parts of the system
+
{{check_mark}} Theoretical blocks representing the parts of the system
  
−
{{Checked}} Necessary properties of these blocks
+
{{check_mark}} Necessary properties of these blocks
 
</strong>
 
</strong>
  
−
An important aspect of the datamodel has not been discussed yet, namely <b>how are the blocks (=MetaClasses) related to each other?</b>
+
An important aspect of the datamodel has not been discussed yet, namely <b>how are the blocks (=[[MetaClass|MetaClasses]]) related to each other?</b>
  
 
== Relating objects ==
 
== Relating objects ==
 
[[File:IL_DOM_004.png|thumb|220px|alt=Relations of plant parts|Possible relations between parts of plant]]
 
[[File:IL_DOM_004.png|thumb|220px|alt=Relations of plant parts|Possible relations between parts of plant]]
−
Assuming that all three pumps are clearly parts of the plant „UBIK1“, the descriptive model has to be extended in order to include this information as well. In our "table" view we account for this by adding a property to the „Pump“ block refering to the plant. This additional property represents the link information between the pumps #1 - #3 and the plant „UBIK1“.
+
Assuming that all three pumps are clearly parts of the plant „UBIK1“, the descriptive model has to be extended in order to include this information as well. In our "table" view we account for this by adding a property to the ''PUMP'' block refering to the plant. This additional property represents the link information between the pumps #1 - #3 and the plant „UBIK1“.
  
 
<table>
 
<table>
Line 86: Line 87:
  
  
−
Now we introduce two armatures with the properties from the descriptive model above. Assume that, due to the piping, pumps #1 and #2 are controlled by both armatures, whereas A200 regulates pump #3 only. This situation is depicted below already indicating, that the implementation of the relation requires a more complex structure. We find three pumps on the left side and two armatures on the right side of the relation, respectively. Managing this control relation in the MetaModel requires to introduce a relation block „CONTROL“ with two MetaProperties „Armature#“ and „Pump#“
+
Now we introduce two armatures with the properties from the descriptive model above. Assume that, due to the piping, pumps #1 and #2 are controlled by both armatures, whereas A200 regulates pump #3 only. This situation is depicted below already indicating, that the implementation of the relation requires a more complex structure. We find three pumps on the left side and two armatures on the right side of the relation, respectively. Managing this control relation in the Metamodel requires to introduce a relation block ''CONTROL'' with two MetaProperties „Armature#“ and „Pump#“
  
 
<table>
 
<table>
 
<tr>
 
<tr>
−
<td>[[File:UDOM_Relating2.png|400 px]]</td>
+
<td>[[File:IL_DOM_006.png|400 px]]</td>
 
<td>[[File:IC_ArrowGreenRight.png|20 px]]</td>
 
<td>[[File:IC_ArrowGreenRight.png|20 px]]</td>
 
<td>
 
<td>
Line 114: Line 115:
  
  
−
{{UMM|Managing the control relation in the MetaModel requires to introduce a relation block „CONTROL“ with two MetaProperties „Armature#“ and „Pump#“.}}
+
{{UMM|Managing the control relation in the Metamodel requires to introduce a relation block „CONTROL“ with two MetaProperties „Armature#“ and „Pump#“.}}
  
  
Line 171: Line 172:
  
 
===Entity Relationship Model (ER model)===
 
===Entity Relationship Model (ER model)===
−
[[File:UDOM_Relating4.png|thumb|220 px|alt=ER-model|Entitiy-Relationship-Model]]
+
[[File:IL_DOM_007.png|thumb|220 px|alt=ER-model|Entitiy-Relationship-Model]]
−
In software engineering, such an abstract descriptive model is called Entity–Relationship model (ER model) and describes the entities (={{UBIK}} MetaClasses) and relationships between them. Usually this information is depicted in an entity-relationship-diagram (ERD), which draws the corresponding data objects and relations as rectangles and lines between them, respectively. The MetaClass ''„CONTROL“'' can be drawn as diamond, signalling the additional block between these two MetaClasses, which is always needed for each relation of cardinality n : n.
+
In software engineering, such an abstract descriptive model is called Entity–Relationship model (ER model) and describes the entities (={{UBIK}} MetaClasses) and relationships between them. Usually this information is depicted in an entity-relationship-diagram (ERD), which draws the corresponding data objects and relations as rectangles and lines between them, respectively. The MetaClass ''CONTROL'' can be drawn as diamond, signalling the additional block between these two MetaClasses, which is always needed for each relation of cardinality n : n.
−
 
+
−
 
+
−
 
+
−
 
+
−
 
+
  
 
===About References and Relations===
 
===About References and Relations===
−
[[File:UDOM_Relating5_RefRel.png|thumb|220 px|alt=References and Relations|{{UBIK}} References and Relations]]
+
[[File:IL_DOM_009.png|thumb|220 px|alt=References and Relations|{{UBIK}} References and Relations]]
−
Concluding and summarizing the above discussion we finally depict the two possible types of relation in the {{UBIK}} MetaModel.
+
Concluding and summarizing the above discussion we finally depict the two possible types of relation in the {{UBIK}} Metamodel.
  
 
{{UMM|
 
{{UMM|
Line 191: Line 187:
 
Congratulations, we integrated another important issue in our data- and object model:
 
Congratulations, we integrated another important issue in our data- and object model:
  
−
{{Checked}} <b>Relationships between blocks (MetaClasses)</b>
+
{{check_mark}} <b>Relationships between blocks (MetaClasses)</b>
 +
 
 +
==MetaClasses and Instances==
 +
So far MetaClasses define the structure of and possible relations between the objects in our data model. In the next step it will be shown how to create actual objects of these blueprints and how to deal with it.
 +
=== Instances ===
 +
[[File:IL_DOM_008.png|thumb|220 px|alt=UBIK Instance model|{{UBIK}} Instance Model]]
 +
Populating our data modell with real data from a plant means, that we create objects as defined by the MetaClasses. These objects are called instances, and leads us to the next definition.
 +
{{UMM|
 +
An '''instance''' is the actual „existing“ occurrence of the described object (within the metamodel). The instances can be differentiated by their property values.
 +
}}
 +
=== MetaClass & MetaProperties ===
 +
[[File:IL_DOM_012.png|thumb|220 px|alt=Relation MetaClass / MetaProperty|Relation MetaClass / MetaProperty]]
 +
[[File:IL_DOM_010.png|thumb|220 px|alt=Usage MetaClass / MetaProperty|Usage MetaClass / MetaProperty]]
 +
In the similar way as MetaClasses are related to each other, MetaProperties are related to MetaClasses. Hence, we obviously find that
 +
* a MetaProperty can be related to multiple MetaClasses
 +
* be used multiple times for defining a MetaClass' structure
 +
{{UMM|MetaProperties are assigned to a MetaClasses via relations}}
 +
 
 +
=== MetaClass & Inheritance ===
 +
[[File:IL_DOM_013.png|thumb|220 px|alt=Inheritance MetaClass|Inheritance MetaClass]]
 +
We can build up a hierarchical tree of MetaClasses, where MetaClasses inherit properties.
 +
<table>
 +
<tr>
 +
<td>
 +
</td>
 +
<td>
 +
</td>
 +
<td align="center"  valign="top">
 +
{| class="wikitable"
 +
|-
 +
! Pump !! TAG !! Vendor !! Power !! Maintenance !! Plant
 +
|- align="center"
 +
| #1 || style="width: 80px;" | P0815 || style="width: 100px;" | Andritz || style="width: 50px;" align="right" | 2 kW || Yearly || style="width: 80px; background-color: #C3D69B" | UBIK1
 +
|- align="center"
 +
| #2 || P0816 || Andritz || align="right" | 5 kW || Monthly || style="background-color: #C3D69B" | UBIK1
 +
|- align="center"
 +
| #3 || P0817 || Sulzer || align="right" | 4 kW || Yearly || style="background-color: #C3D69B" | UBIK1
 +
|}
 +
</td>
 +
</tr>
 +
<tr>
 +
<td></td>
 +
<td></td>
 +
<td align="center">[[File:IC_ArrowGreenDown.png|40 px]]</td>
 +
</tr>
 +
<tr>
 +
<td align="center"  valign="top">
 +
{| class="wikitable"
 +
|-
 +
! Piston pump !! Stroke freq.
 +
|- align="center"
 +
| #1 || style="width: 80px; background-color: #C3D69B" | 1 / s
 +
|- align="center"
 +
| #2 || style="width: 80px; background-color: #C3D69B" | 0,1 / s
 +
|}
 +
</td>
 +
<td align="center">[[File:IC_ArrowGreenRight.png|40 px]]</td>
 +
<td align="center"  valign="top">
 +
{| class="wikitable"
 +
|-
 +
! Pump !! TAG !! Vendor !! Power !! Maintenance !! Plant!! Stroke freq.
 +
|- align="center"
 +
| #1 || style="width: 80px;" | P0815 || style="width: 100px;" | Andritz || style="width: 50px;" align="right" | 2 kW || Yearly || UBIK1|| style="width: 80px; background-color: #C3D69B" | 1 / s
 +
|- align="center"
 +
| #2 || P0816 || Andritz || align="right" | 5 kW || Monthly || UBIK1 || style="width: 80px; background-color: #C3D69B" | 0,1 / s
 +
|}
 +
</td>
 +
</tr>
 +
</table>
 +
{{UMM|MetaClasses pass on MetaProperties to child-MetaClasses („Inheritance“)}}
 +
 
 +
=== MetaClass & Classification ===
 +
[[File:IL_DOM_011.png|thumb|220 px|alt=Classification|Classification]]
 +
MetaClasses can specify features and properties of other MetaClasses by using a "Classification" technique. The result can be described by
 +
* "A piston pump is a pump and an element of the fluid technology." [gen]
 +
* "Piston pump" is a child MetaClass of „Pump“ and classified as "Fluid technology" object. [techn.]
 +
{{UMM|MetaClasses can specify features of other MetaClasses ("Classification")}}
 +
 
 +
=== MetaProperties ===
 +
Each MetaProperty can be specified by its own attributes which are well-known from other systems.
 +
<table>
 +
<tr>
 +
<td>
 +
{| class="wikitable"
 +
|-
 +
! MetaProperty
 +
|- align="center"
 +
| "Name"
 +
|- align="center"
 +
| "Year"
 +
|- align="center"
 +
| "Location"
 +
|- align="center"
 +
| "TAG"
 +
|- align="center"
 +
| "Plant"
 +
|- align="center"
 +
| "Power"
 +
|}
 +
</td>
 +
<td>
 +
{| class="wikitable"
 +
|-
 +
! Name !! Description !! Data type !! Unit !! Format !! Length !! ...
 +
|- align="center"
 +
| "Name"|| Name of object || String || - || - || 20 || ...
 +
|- align="center"
 +
| "Year" || Year of construction || Numeric || - || #### || - || ...
 +
|- align="center"
 +
| "Location" || Plant location || String || - || - || 200 || ...
 +
|- align="center"
 +
| "TAG" || TAG number || String || - || - || - || ...
 +
|- align="center"
 +
| "Plant" || Reference to plant || Reference || - || - || - || ...
 +
|- align="center"
 +
| "Power" || Power || Numeric || kW || ###.## || - || ...
 +
|}
 +
</td>
 +
</tr>
 +
</table>
 +
{{UMM|MetaProperties have specific attributes, closely related to the intended property value}}
  
 
==Conclusion==
 
==Conclusion==
 +
* The descriptive model consists of '''MetaClasses''' and '''MetaProperties''' and relations between these objects.
 +
* Each MetaClass is defined by
 +
** a collection of MetaProperties
 +
** the line of inheritance
 +
** classification information
 +
 +
* A MetaProperty implements different features and settings.
 +
* In this MetaModel we explicitely distinguish between the description (structure, relations,…) and '''instances''' (actual occurences) of data objects
 +
* The MetaClasses might be on an equal hierarchy level from the descriptive point of view, whereas the instances are then related using '''references''' and '''relations'''
 +
 +
[[Category:UBIK|Entity Data Model]]

Latest revision as of 13:14, 30 July 2015

Get to know about the relational data- and object model used in UBIK® beginning from a rather figurative and abstract point of view. We will introduce the essential parts of the object model and show how these items are connected to a real system.

Introduction

Objectives

In an industrial environment we quite often need to

  • describe an industrial plant consisting of a bunch of different parts, each having a certain purpose and set of properties, and which are related in various ways
  • manage process or maintenance data of the plant and its features
  • do a high-performance cost-benefit analysis and create key performance indicators

Therefore we need to

→ „Dissemble“ the system into theoretical blocks representing the real as well as intangible parts of the system.

→ Identify the necessary properties of the blocks.

→ Think about how blocks are possibly related to each other.

→ Think about the functions and features of blocks.

Plant picture

Parts of a plant
Example plant and parts

Lets start with a simple picture and assume that our plant consists of a pump and an armature. Both equipments exhibit certain technical or other properties, which our datamodel must contain in some form. Additionally the datamodel has to provide mechanism to indicate the circumstances that both equipments are parts of the plant and maybe even be related to each other.

In this first exemplary plant, we take account of a pump and armature and find definitions as shown in the picture on the right. Looking closer at the PUMP block reveals its properties and property values, this information is explicitely depicted as

PUMP block details

Of course, a real plant consists of multiple pumps, each described with the same set of properties (TAG, vendor, power, maintenance data). The real pumps in the plant are distinguished by different property values as given in the table.

Pump TAG Vendor Power Maintenance
#1 P0815 Andritz 2 kW Yearly
#2 P0816 Andritz 5 kW Monthly
#3 P0817 Sulzer 4 kW Yearly

We can redefine or extend our objectives by

  • Design a descriptive model including all required blocks and properties of the system
  • Specify the possible properties for the parts of the real system

From the plant picture to UBIK®

Transition

Transition plant picture
Transition from plant picture into data model

The transition from the plant picture into an object- / data - model logically happens via an intermediate layer and finally leads to our first definition


UBIK® MetaModel
A descriptive model, where objects provide information about the aspects of the data, is also called “Metamodel”.


So far we have identified

IC Check Mark.png Theoretical blocks representing the parts of the system

IC Check Mark.png Necessary properties of these blocks

An important aspect of the datamodel has not been discussed yet, namely how are the blocks (=MetaClasses) related to each other?

Relating objects

Relations of plant parts
Possible relations between parts of plant

Assuming that all three pumps are clearly parts of the plant „UBIK1“, the descriptive model has to be extended in order to include this information as well. In our "table" view we account for this by adding a property to the PUMP block refering to the plant. This additional property represents the link information between the pumps #1 - #3 and the plant „UBIK1“.

"Relation pump and plant"    IC ArrowGreenRight.png   
Pump TAG Vendor Power Maintenance Plant
#1 P0815 Andritz 2 kW Yearly UBIK1
#2 P0816 Andritz 5 kW Monthly UBIK1
#3 P0817 Sulzer 4 kW Yearly UBIK1



UBIK® MetaModel
Add a metaproperty „Plant“ to the MetaClass „Pump“, where the values of the MetaProperty refer to the plant „UBIK1“.



Now we introduce two armatures with the properties from the descriptive model above. Assume that, due to the piping, pumps #1 and #2 are controlled by both armatures, whereas A200 regulates pump #3 only. This situation is depicted below already indicating, that the implementation of the relation requires a more complex structure. We find three pumps on the left side and two armatures on the right side of the relation, respectively. Managing this control relation in the Metamodel requires to introduce a relation block CONTROL with two MetaProperties „Armature#“ and „Pump#“

IL DOM 006.png IC ArrowGreenRight.png
Armature# Pump#
A100 P0815
A100 P0816
A200 P0815
A200 P0816
A200 P0817
IC ArrowGreenRight.png UDOM Relating3.png



UBIK® MetaModel
Managing the control relation in the Metamodel requires to introduce a relation block „CONTROL“ with two MetaProperties „Armature#“ and „Pump#“.



Lets have a closer look at the characteristics of the two methods relating objects:

Pump TAG Vendor Power Maintenance Plant
#1 P0815 Andritz 2 kW Yearly UBIK1
#2 P0816 Andritz 5 kW Monthly UBIK1
#3 P0817 Sulzer 4 kW Yearly UBIK1
Armature# Pump#
A100 P0815
A100 P0816
A200 P0815
A200 P0816
A200 P0817
IC ArrowGreenDown.png IC ArrowGreenDown.png
each pump refers exactely to the one plant two pumps are controlled by two armatures
one pump is controlled by one armature
IC ArrowGreenDown.png IC ArrowGreenDown.png
Cardinality 1 : n Cardinality n : n



UBIK® MetaModel
Data model built and described by MetaClasses and MetaProperties related to each other, either by 1 : n or n : n cardinality.


Entity Relationship Model (ER model)

ER-model
Entitiy-Relationship-Model

In software engineering, such an abstract descriptive model is called Entity–Relationship model (ER model) and describes the entities (=UBIK® MetaClasses) and relationships between them. Usually this information is depicted in an entity-relationship-diagram (ERD), which draws the corresponding data objects and relations as rectangles and lines between them, respectively. The MetaClass CONTROL can be drawn as diamond, signalling the additional block between these two MetaClasses, which is always needed for each relation of cardinality n : n.

About References and Relations

References and Relations
UBIK® References and Relations

Concluding and summarizing the above discussion we finally depict the two possible types of relation in the UBIK® Metamodel.


UBIK® MetaModel
  • 1 : n relationships are called “References” (one pump refers to exactly one plant)
  • n : n relationships are called “Relations” (two pumps are controlled by two armatures, one pump is controlled by one armature)



Congratulations, we integrated another important issue in our data- and object model:

IC Check Mark.png Relationships between blocks (MetaClasses)

MetaClasses and Instances

So far MetaClasses define the structure of and possible relations between the objects in our data model. In the next step it will be shown how to create actual objects of these blueprints and how to deal with it.

Instances

UBIK Instance model
UBIK® Instance Model

Populating our data modell with real data from a plant means, that we create objects as defined by the MetaClasses. These objects are called instances, and leads us to the next definition.

UBIK® MetaModel

An instance is the actual „existing“ occurrence of the described object (within the metamodel). The instances can be differentiated by their property values.


MetaClass & MetaProperties

Relation MetaClass / MetaProperty
Relation MetaClass / MetaProperty
Usage MetaClass / MetaProperty
Usage MetaClass / MetaProperty

In the similar way as MetaClasses are related to each other, MetaProperties are related to MetaClasses. Hence, we obviously find that

  • a MetaProperty can be related to multiple MetaClasses
  • be used multiple times for defining a MetaClass' structure


UBIK® MetaModel
MetaProperties are assigned to a MetaClasses via relations


MetaClass & Inheritance

Inheritance MetaClass
Inheritance MetaClass

We can build up a hierarchical tree of MetaClasses, where MetaClasses inherit properties.

Pump TAG Vendor Power Maintenance Plant
#1 P0815 Andritz 2 kW Yearly UBIK1
#2 P0816 Andritz 5 kW Monthly UBIK1
#3 P0817 Sulzer 4 kW Yearly UBIK1
IC ArrowGreenDown.png
Piston pump Stroke freq.
#1 1 / s
#2 0,1 / s
IC ArrowGreenRight.png
Pump TAG Vendor Power Maintenance Plant Stroke freq.
#1 P0815 Andritz 2 kW Yearly UBIK1 1 / s
#2 P0816 Andritz 5 kW Monthly UBIK1 0,1 / s


UBIK® MetaModel
MetaClasses pass on MetaProperties to child-MetaClasses („Inheritance“)


MetaClass & Classification

Classification
Classification

MetaClasses can specify features and properties of other MetaClasses by using a "Classification" technique. The result can be described by

  • "A piston pump is a pump and an element of the fluid technology." [gen]
  • "Piston pump" is a child MetaClass of „Pump“ and classified as "Fluid technology" object. [techn.]


UBIK® MetaModel
MetaClasses can specify features of other MetaClasses ("Classification")


MetaProperties

Each MetaProperty can be specified by its own attributes which are well-known from other systems.

MetaProperty
"Name"
"Year"
"Location"
"TAG"
"Plant"
"Power"
Name Description Data type Unit Format Length ...
"Name" Name of object String - - 20 ...
"Year" Year of construction Numeric - #### - ...
"Location" Plant location String - - 200 ...
"TAG" TAG number String - - - ...
"Plant" Reference to plant Reference - - - ...
"Power" Power Numeric kW ###.## - ...


UBIK® MetaModel
MetaProperties have specific attributes, closely related to the intended property value


Conclusion

  • The descriptive model consists of MetaClasses and MetaProperties and relations between these objects.
  • Each MetaClass is defined by
    • a collection of MetaProperties
    • the line of inheritance
    • classification information
  • A MetaProperty implements different features and settings.
  • In this MetaModel we explicitely distinguish between the description (structure, relations,…) and instances (actual occurences) of data objects
  • The MetaClasses might be on an equal hierarchy level from the descriptive point of view, whereas the instances are then related using references and relations
Retrieved from "https://wiki.augmensys.com/index.php?title=Entity_Data_Model&oldid=16971"