# Envisaging a European Digital Building Renovation Logbook: Proposal of a Data Model
## 3 Results
### Construction and Material Information  
This category is made up of eight entities and eleven tables, of which three are junction tables, which are necessary due to the presence of N:N relationships.  
The category is very relevant from the point of view of renovation. On the one hand, the data collected here allow the constructive characterisation of the building and the development of an accurate diagnosis of the building's needs, which is required to design a renovation roadmap. On the other hand, as in the previous case, this allows us to track the evolution of the building at a constructive level during the entire lifecycle, registering works such as the addition of insulation or the replacement of windows. In addition, this category provides useful information for carrying out the Life Cycle Assessment (LCA), which is the methodology to obtain a life-cycle Global Warming Potential (GWP) of the building. In fact, the assessment of GWP gains great relevance in the recast of the EPBD [1] as the initial step towards enhancing consideration of the whole life-cycle performance of buildings and fostering a circular economy.  
The entities in this category are organized following a tree scheme, from the most general entities to the most particular and detailed ones (Figure 9). Details on their attributes can be found in Appendix A.5.  
* \"Facade\", \"Roof\", and \"Floor\" collect the general information on each envelope element of the building, like identification, surface area, and U-value. These are related to \"Door\", \"Windows\", \"EnvelopeLayers\", and \"ThermalBridges\", which provide additional information on the envelope elements.
* \"Windows\", which is related to \"Facade\" and \"Roof\" entities through a 1:N relationship, stores all the information that allow the characterisation of all the openings of the envelope, including the dimensions, type, or U-value.
* Similarly, \"Doors\" is related to \"Facade\" through a 1:N relationship and stores information to characterise the rest of the openings of the envelope.
* \"ThermalBridges\" is related to \"Facade\", \"Roof\", and \"Floor\" entities by means of 1:N relationships, which indicates that in each facade, roof, or floor may exist more than one kind of thermal bridge. Here, each one is identified and characterised, and its U-value is stored.
* In \"EnvelopeLayers\", all the layers that make up the enclosures of the building are identified and characterised separately. Through 1:N relationships, this entity is connected to \"Facade\", \"Roof\", and \"Floor\", providing for each envelope element the identification, order, thickness, and U-value of each layer.
* The \"Materials\" entity works as the material inventory of the DBL. It is linked to \"EnvelopeLayers\" through a 1:N relationship, providing each envelope layer with all the details on its materials. This entity is designed to provide all the information about the life cycle and circularity of the building materials, including the reuse and recycling potential or the future Digital Product Passport (DPP).
* The rest of the tables, namely \"REL_BuildingUnit_Facade\", \"REL_BuildingUnit_Roof\", and \"REL_BuildingUnit_Floor\", are relational tables that enable the connection between the envelope elements' tables and the \"BuildingUnit\" table through N:N relationships.  
All the connections between the entities of this category and those of the \"core\" category are produced through the \"BuildingUnit\" entity instead of the \"Building\" one because it allows considering the particularities of each building unit easier. For this reason, common zones need to be considered as a building unit.  
The flexibility of the proposed model will allow to include new parameters in the future, such as maximum admissible values for some parameters like the U-value, allowing to assess the compliance of the building with regulations.