Bim M3T1 01

TEORÍA DE LA INFORMACIÓN
INTRODUCCIÓN A LA TEORÍA DE LA
INFORMACIÓN. PARTE I
Teoría de la información
2
Introducción a la teoría de la información. Parte I
INDICE
INDICE........................................................................................................................................................................... 2
1. INTRODUCCIÓN ....................................................................................................................................................... 4
2. FLUJOS DE INFORMACIÓN EN EL SECTOR DE LA CONSTRUCCIÓN ............................................................... 5
3. FLUJOS DE INFORMACIÓN EN EL PASADO RECIENTE ..................................................................................... 6
4. FLUJOS DE INFORMACIÓN CON METODOLOGÍA BIM ..................................................................................... 11
4.1 Ejemplo práctico .................................................................................................................................................. 15
5. EL FUTURO: DATOS ENLAZADOS ...................................................................................................................... 16
5.2 Ejemplo práctico .................................................................................................................................................. 17
6. TIPOLOGÍAS DE BASES DE DATOS .................................................................................................................... 18
6.1 ¿Qué es una base de datos? .............................................................................................................................. 18

6.2 Bases de datos Relacionales y no Relacionales ................................................................................................. 20
6.3 Bases de datos utilizadas por los programas de diseño...................................................................................... 23
6.4 ¿Cómo se organiza la información dentro de ®Autodesk Revit? ........................................................................ 24
6.5 ¿Cómo podemos interactuar con ®Autodesk Revit utilizando bases de datos externas a la aplicación? ........... 27
7. SEMÁNTICA, ONTOLOGÍA Y TAXONOMÍA.......................................................................................................... 31
7.1 Definiciones y conceptos básicos ........................................................................................................................ 31

7.2 ISO 12006-2:2015: Cómo construir una clasificación siguiendo un estándar...................................................... 38
7.3 Ejemplos de clasificaciones en el mundo: UNICLASS, OMNICLASS, Sfb… ...................................................... 41
3
1. INTRODUCCIÓN
El sector de la construcción no es ajeno a la revolución tecnológica que lo rodea. Dada la
dinámica de los procesos de transmisión de información, se ha puesto al alcance de las
empresas un gran volumen de datos que en la mayoría de casos carecen de la estructura y
organización necesaria. Durante este bloque temático el alumno aprenderá los principios
teóricos básicos que deben regir la gestión de la información aplicada al sector de la
Construcción.
4
2. FLUJOS DE INFORMACIÓN EN EL SECTOR DE LA

CONSTRUCCIÓN
Durante los últimos años la tecnología ha ido abriéndose paso en nuestra industria de forma
constante y paulatina. Esto ha provocado grandes cambios en la forma en la que la información
fluye y se distribuye dentro del sector de la construcción. Aun así, nuestra industria está lejos
de los estándares existentes en otras mucho más tecnificadas y tecnológicamente avanzadas.
La metodología BIM (Building Information Management) ha significado una mejora y una

ruptura con la concepción anterior acerca de cómo abordar no solo el diseño, construcción o
explotación de un edificio o una infraestructura sino también acerca de cómo gestionar la
información generada durante todos esos procesos.
Ahora bien, ¿tenemos los ingenieros civiles, arquitectos, y restantes agentes implicados en los
proyectos de ingeniería y arquitectura los suficientes conocimientos acerca de gestión de la
información como para abordar esta nueva metodología de trabajo de una forma correcta?
En este bloque temático intentaremos dotar al alumnado de los conocimientos mínimos

necesarios para que no se encuentren desbordados, en este ámbito, cuando se enfrenten a
esta nueva metodología de trabajo.
Recordemos que lo esencial en la metodología BIM no es qué software utilizar para el

modelado de nuestro proyecto o saber programar en un determinado lenguaje, etc. Lo
fundamental de la metodología BIM es precisamente saber planificar y gestionar de forma
adecuada todos los flujos de información generada durante el proceso proyecto-construcción
para que esa información sea útil durante la explotación del producto construido.
A la finalización del bloque el alumno podrá ser capaz de planificar los flujos de información en
las distintas fases del proyecto, sabrá discernir sobre qué tipología de herramientas de software
son las adecuadas para gestionar la información necesaria, tendrá conocimientos básicos de
ingeniería ontológica, conocerá distintas clasificaciones de objetos utilizadas en todo el mundo
y podrá ser crítico con ellas. Por último también ofreceremos conocimientos mínimos de
seguridad en la transferencia de datos.
Es, a nuestro de modo de ver, este bloque temático un bloque clave en el posterior
desarrollo laboral que esa nueva figura conocida como BIM manager va a jugar en la
organización a la que represente, ya que estos conceptos básicos y su correcta
aplicación serán claves en la adecuada toma de decisiones.
5
3. FLUJOS DE INFORMACIÓN EN EL PASADO RECIENTE

Comencemos por definir algunos conceptos básicos de los que debemos tener nociones y han
de ser descritos adecuadamente basadas en las realizadas por Davenport y Prusak (1999):
 Dato: “Un dato es un conjunto discreto de factores objetivos sobre un hecho real.
Dentro de un contexto ingenieril, el concepto de dato es definido como un registro de
operaciones o cálculos. Un dato no dice nada sobre el porqué de las cosas, y por sí
mismo tiene poca o ninguna relevancia o propósito.”
 Información: “es un mensaje, o algún tipo de comunicación audible o visible y tiene

un emisor y un receptor. La información es capaz de cambiar la forma en que el
receptor percibe algo, es capaz de impactar sobre sus juicios de valor y
comportamientos.”
 Documento: Es el continente de la información.
Por tanto, en el mundo de la ingeniería y arquitectura, los datos deben ser más relevantes que
la información per se, ya que podemos asumir que nuestros interlocutores tienen la capacidad
de interpretar esa información que se supone objetiva y no ha sido tratada. Nada más lejos de
la realidad.
Toda comunicación que realizamos acerca del “producto” que estamos construyendo supone,
de una manera u otra, la transformación de esos datos en información. Cualquier correo
electrónico que mandamos, llamada de teléfono que efectuamos o documento del proyecto que
redactamos, supone la transformación de esos datos en información ya que estamos
contextualizando, modificando, realzando etc. aquellos bajo nuestra percepción individual e
interesada. Pero, como técnicos que somos, es obligado minimizar esa percepción individual al
máximo para, así, crear una atmósfera neutra en la que la información intente no ser más que
la visualización de esos datos.
Hasta ahora el objetivo marcado como meta en el párrafo anterior era muy complicado por no
decir casi imposible. La comunicación entre los distintos agentes implicados en el
proceso proyecto-construcción se realizaba en un entorno no colaborativo y excluyente,
en el cual los agentes implicados segregaban la información a partir de sus propios
datos. El producto constructivo era el resultado, en cuanto a teoría de la información se refiere,
de multitud de intercambios documentales en uno u otro formato y no siempre conexos entre sí.
6
No quiere decir esto que el producto constructivo final fuese inadecuado, ni mucho menos,
simplemente no nos parece lo más eficiente con la técnica y tecnología actuales.
En las siguientes figuras mostramos las distintas fases del proceso proyecto-construcción para
la tipología de contratos más clásicas. Imaginemos la cantidad de documentos, correos
electrónicos, faxes, llamadas de teléfono, etc. que pueden tener lugar ya no solo en la fase de
diseño y/o construcción, sino también durante la explotación del mismo.
7
Figura 1: Procedimiento Clásico –Simplificado. Apuntes de “Proyectos de Ingeniería civil” ETSICCP-UPV.
8
Figura 2: Procedimiento llave en mano (DBFM). Apuntes de “Proyectos de Ingeniería civil” ETSICCP-UPV.
9
En estas figuras hemos resaltado tan solo los eventos (en verde), toma de decisiones (en rojo),
actividades (en blanco), procesos y almacenamiento de datos (en azul) y documentación
estándar (en amarillo). La cantidad de datos e información generada durante el proceso
proyecto-construcción-explotación es ingente. ¿Es toda esa información relevante? ¿Sería
necesario que toda ella quedase registrada? Debemos ser críticos en la respuesta.
Imaginemos una reunión de coordinación durante la fase inicial de construcción de un proyecto.

Las directrices y decisiones tomadas en esa reunión posiblemente no serán relevantes al final
de ejecución del mismo (habrán pasado 3 años y la edificación o la infraestructura ha sido
ejecutada en tiempo y forma) pero sí lo serán, y mucho, para los siguientes 3 o 4 meses de la
misma, en los que todos los equipos comiencen a interactuar y se creen las debidas sinergias
entre ellos. ¿Dónde han quedado registradas esas directrices? ¿Cómo las hemos distribuido al
resto de asistentes a la reunión? ¿Sabemos si las directrices han sido claras?...
En el mundo analógico estas preguntas tenían respuesta en forma de papel, en el mundo

digital estas preguntas tienen respuesta dentro de servidores y bases de datos. Porque una
cosa tiene que quedar muy clara, la metodología BIM consiste en, de una vez por todas,
digitalizar la industria de la construcción.
10
4. FLUJOS DE INFORMACIÓN CON METODOLOGÍA BIM

Una de las muchas definiciones que podemos dar sobre BIM es que es una metodología en la
que los diferentes agentes implicados en el proceso proyecto-construcción trabajan de forma
conjunta en un entorno digitalizado, donde se realiza un intercambio eficiente de información
(datos y geometría) y donde se colabora para conseguir un proceso más eficiente en el que
cometer menos errores para, así, conseguir una construcción más ajustada al planeamiento
inicial. También se persigue con esta metodología producir construcciones más eficientes que
producen menos residuos y que deben ser más fáciles de operar. Con esta visión la clave no
es el modelado tridimensional en sí, sino la información desarrollada, administrada y
común en la que participan todos los actores implicados.
Ahora bien, ¿cómo diseñar en la práctica los flujos de información en ese entorno colaborativo
y adaptarlos a las diferentes legislaciones de cada país? y ¿cómo mantener como válidos los
esquemas del punto teórico anterior e implementar este nuevo paradigma dentro de nuestra
industria? Este es sin duda uno de los grandes retos a los que las administraciones públicas
deben dar respuesta.
La organización de los flujos de información, de forma muy simplificada y teniendo en cuenta

ese entorno colaborativo que mencionábamos, podría estar representada en la siguiente figura,
en la que se observa la existencia de un único punto central de información denominado, en
terminología anglosajona, “Common Data Environment”, que no es más que un espacio
digital accesible a todos los agentes implicados en el proceso donde se produce el “diálogo”
entre ellos.
11
Figura 3: Modelo Federado y CDE. ® 2014 New Zealand BIM Handbook.
Este “Common Data Environment” y los flujos de información relativos al mismo han sido
desarrollados de forma extensiva y minuciosa en la legislación de adopción de la metodología
BIM en el Reino Unido y se define como “una única fuente de información para un
determinado proyecto, que se utiliza para recoger, gestionar y difundir todos los
documentos del proyecto aprobados y relevantes para los equipos multidisciplinares
participantes en el mismo. Un CDE puede utilizar un servidor de proyecto, una extranet,
un sistema de extracción de documentos o cualquier conjunto de herramientas
adecuado.”
12
Figura 4: The common data environment (CDE). PAS 1192-2: 2013, ® 2013 The British
Standards Institution.
Esta figura se debe “leer” en el sentido contrario a las agujas del reloj y comenzando en la
parte superior derecha. Así, se observa como la información fluye, organiza y nutre el CDE
desde el momento en el que el “Brief” o programa queda registrado en el mismo.
Es muy importante resaltar que la información generada en el proceso proyecto-construcción y

hasta que la fase OPEX (Operational Expenditures o gastos asociados a las operaciones)
comienza, la citada información puede ser gráfica (modelo 3D), no gráfica y en forma de
documentos, los cuales son generados a partir de las 2 categorías anteriores. Como se puede
observar en el gráfico el volumen de información generada no deja de crecer durante la fase
“CAPEX” (Capital expenditures o inversiones en bienes de capitales).
Es por tanto el CDE un lugar accesible a todos los agentes, si bien tiene espacios de uso
privativo y en los que se garantiza confidencialidad. Hacer uso de este CDE no implica
compartir absolutamente toda la información, sino tener la posibilidad de seleccionar que
información compartir, en qué momento pero siempre de forma digital.
13
Figura 5: The common data environment (CDE) flow diagram. PAS 1192-2: 2013, ® 2013. The
British Standards Institution.
14
4.1 Ejemplo práctico
Una ingeniería española trabaja en el diseño de la nueva línea de ferrocarril de alta velocidad
que unirá Manchester con Londres en Reino Unido. La utilización del CDE por parte de la
ingeniería española no quiere decir que el organismo público inglés que lanzó el contrato al
mercado tenga acceso de forma constante a sus diseños. Sólo cuando la ingeniería española
“mueve” el modelo, datos y otros documentos a la zona común, una vez han sido aprobados de
forma interna (1 en la figura 5), su información es compartida con el resto de ingenierías del
equipo de diseño. Tras sucesivas “puertas de decisión” en las que la información se valida de
forma conjunta esta llegará filtrada al cliente (5) para que se autorice y comience la fase OPEX.
La clara ventaja de esta sistemática con respecto a metodologías anteriores es la

automatización del proceso y la digitalización del mismo. También aseguramos que una
mayor cantidad de información (en volumen) llegue a la fase de explotación del producto
construido, lo que debería servir para operar el mismo de una forma más eficiente.
Aun así, ¿es esta sistemática suficiente? Debemos tener en cuenta qué aunque hablemos de
la digitalización de los procesos, esta es una digitalización parcial, basada aún en el
intercambio consciente de información y mayoritariamente en forma de documentos y no en
datos. ¿Existe alguna tendencia hoy que intente aprovechar nuevas y más inteligentes
tecnologías y que pueda soportar estos procesos? La respuesta la podemos encontrar en el
siguiente punto de este bloque teórico.
15
5. EL FUTURO: DATOS ENLAZADOS

Seguramente todos estamos leyendo y escuchando cosas acerca de la denominada “cuarta
revolución industrial” o del término “industria 4.0”. Pues bien, uno de los pilares en los que se
basa ese término es precisamente el que, sucintamente, vamos a desarrollar en este último
apartado del primer punto de este bloque temático.
En 1989 el científico británico Tim Berners-Lee trabajaba en el CERN (Centro Europeo para la
Investigación Nuclear). A raíz de los problemas que este científico encontraba en su día a día,
en cuanto al correcto manejo y también pérdida de parte de la ingente cantidad de información
y toma de datos que tenían, decidió crear un sistema para enlazar distintas fuentes de
información de tal forma que se pudiera:
 Acceder a la información de forma remota.
 Acceder a la información de forma heterogénea sin importar el tipo de hardware con

el que accediésemos a ella.
 Descentralizar la información de tal forma que los sistemas no recreasen la

información ya existente en otros puntos del CERN. La información debía ser única.
 Permitir la automatización del análisis de los datos almacenados.
Aquel año Tim Berners-Lee creó internet.
Cuando nos referimos a “datos enlazados" nos estamos refiriendo a la siguiente evolución de
internet, aquella en la que se dota de semántica (significado) a las relaciones entre objetos de
tal forma que los datos pueden ser directamente interpretados por las computadoras. Se basa
por tanto en la creación formal de una ontología común a esas aplicaciones que amplía y
mejora la interoperabilidad entre todos esos sistemas informáticos.
Enlace recomendado:
https://www.ted.com/talks/tim_berners_lee_on_the_next_web?language=es
16
5.2 Ejemplo práctico
Un despacho de arquitectura está diseñando un nuevo edificio en la ciudad de Ámsterdam.

Para tal fin, la dirección general de vivienda en los Países Bajos (Rijksvastgoedbedrijf) ha
creado una plataforma tecnológica de datos enlazados. El fin último es que el diseño
galardonado soporte (esté enlazado) a esa plataforma de tal forma que los técnicos de la
administración pública puedan verificar de forma automática ciertos aspectos del diseño (área
de las habitaciones, número de habitaciones por habitación tipo, etc.)
Existen esfuerzos por parte de distintas organizaciones, países y entidades supranacionales

para la creación de este tipo de plataformas. Quizás el más claro y conocido de todos ellos sea
la creación del “Building Smart Data Dictionary” que intenta la creación de una ontología
estándar para el ámbito de la arquitectura (aún no para la ingeniería civil) y que se puede visitar
de forma gratuita en este enlace: http://bsdd.buildingsmart.org/
17
6. TIPOLOGÍAS DE BASES DE DATOS

Hemos introducido en el punto anterior los conceptos de datos e información, además de
referirnos a los procesos en los cuales esos datos e información se generan y utilizan en el
contexto que nos interesa. Y es que es muy difícil hoy en día, también en el sector AECO
(ingeniería, arquitectura, construcción y explotación o mantenimiento), vivir aislado al gran auge
de la ciencia o ingeniería de datos. ¿Quién no ha oído o leído acerca del famoso “Big Data”
durante los últimos años?, ¿Quién no sabe que el famoso “ingeniero o gestor de datos” es una
de las profesiones con más presente y futuro de entre todos esos nuevos roles que se están
creando a raíz de la revolución 4.0?
Nuestro desarrollo profesional en este ámbito y durante los últimos años nos dice que el “gestor
o ingeniero de datos” debe ser parte fundamental de esa gran disciplina que es BIM y que, en
muchas organizaciones, el “ingeniero de datos” no es otro que el “BIM manager”.
En esta segunda parte del primer punto de este bloque temático vamos pues a centrarnos en
las principales, básicas y más necesarias herramientas que existen para realizar la labor de
gestión de la información: las bases de datos. Definiremos qué son, las agruparemos en
función de sus características principales, para terminar hablando sobre las bases de datos
más utilizadas por los programas de modelado, centrándonos fundamentalmente en la base de
datos de ®Autodesk Revit, al ser este uno de los programas de diseño más utilizados en el
mercado y del que se han hecho muchas referencias y ejemplos prácticos a lo largo de este
máster.
Queremos hacer hincapié, una vez más, en que BIM es gestión de la información y que, por
tanto, es absolutamente necesario conocer los principios básicos de esta ciencia para que
desarrollemos la disciplina de la que es objeto este Máster de la forma más adecuada.
6.1 ¿Qué es una base de datos?
El almacenamiento y procesado de datos para su posterior análisis fue uno de los principales
motores que llevaron a crear las computadoras y que potenciaron su posterior desarrollo.
Prácticamente todos los programas de ordenador que utilizamos llevan una base de datos
asociada, además, es completamente habitual en nuestro sector que las empresas trabajen
con soluciones específicas que incluyan un sistema de gestión asociado a una base de datos.
¿Pero sabemos que es una base de datos y cómo funcionan en su forma más esquemática?
18
Una base de datos es una forma estructurada de almacenaje de datos (llamadas

normalmente instancias o entidades) que poseen ciertos atributos o propiedades y las
relaciones entre ellos. Las bases de datos están construidas a partir de un modelo o
esquema que dotan a esos datos de una cierta “lógica” y le confiere independencia
sobre los programas que la utilizan.
Volveremos a hablar sobre este modelo o esquema en una parte posterior del bloque temático
pero entendemos que es esencial la total comprensión de la definición anterior para los
posteriores desarrollos teóricos y prácticos de bloque.
Existen muchas formas de clasificar bases de datos y en el siguiente punto utilizaremos uno de
ellos, pero en este apartado es apropiado a nuestro entender realizar una de las clasificaciones
más sencillas y a su vez más descriptivas. Podemos dividir las bases de datos entre las
dinámicas (OLTP - “On Line Transaction Processing”-) y las estáticas (OLAP – “On Line
Analytical Processing”-). Las primeras son aquellas en la que los datos pueden ser creados,
modificados y suprimidos, mientras que las segundas son aquellas en la que los datos solo
pueden ser consultados.
Figura 6: Bases de datos dinámicas u OLTP ® IBM y Bases de datos estáticas u OLAP ®
IBM.
19
6.1.1. Ejemplo
Una empresa constructora que maneja gran volumen de información implementará una base
de datos tipo OLTP para uno de los proyectos en los que está involucrada. En este proyecto
específico la información será creada, modificada y eliminada (si fuese necesario) hasta la
finalización y entrega del mismo. Una vez finalizado, todos los datos generados en el proyecto
podrán ser “volcados” en una base de datos tipo OLAP en la que la información seguirá
estando disponible a los agentes interesados en la misma pero en la que ya no se podrán
añadir, modificar o eliminar datos.
Nótese que las bases de datos estáticas son aquellas asociadas a lo que ahora se denomina
“Business Intelligence” y que permiten analizar grandes cantidades de datos que posibilitan
mejorar la eficacia y eficiencia en posteriores procesos (nuevos proyectos) análogos a los que
han generado las anteriores.
6.2 Bases de datos Relacionales y no Relacionales
Otra de las clasificaciones más habituales para diferenciar bases de datos es la que tiene en
cuenta si son de tipo relacional o no. Esto es debido a que durante más de 30 años las bases
de datos han sido mayoritariamente de tipo relacional y sólo con la llegada del “Big Data” ese
reinado se ha visto amenazado por las bases de datos no relacionales. Definamos a
continuación y con más detalle estas 2 tipologías.
6.2.1. Bases de datos Relacionales
En 1970 el ingeniero E.F. Cood, del laboratorio de investigación de IBM, publicó “A relational
model of data for large shared data banks” que puede ser consultado en este enlace:
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.98.5286&rep=rep1&type=pdf
En ese artículo, de carácter científico, se asentaron los principios de las bases de datos de
Oracle, IBM o Microsoft y que han monopolizado el mercado durante los últimos tiempos. Por
ejemplo, y sin ir más lejos, ®Microsoft Access es una base de datos de carácter relacional. ¿Y
cuáles son las principales características de este tipo de bases de datos?
 Se componen de varias tablas que no pueden tener el mismo nombre entre sí.
20
 Las tablas tienen filas y columnas. A las filas también se les llama “registros”
(records) o “tuplas”.
 Las columnas se denominan “campos” o “atributos”.
 Las relaciones entre las tablas se realizan mediante la inserción de claves primarias y
ajenas (“key” and “foreign key”).
 Son escalables.
 Son descentralizadas.
 Utilizan el lenguaje SQL.
Una base de datos relacional es, para entendernos, una suerte de hoja de cálculo con la
añadidura que, debido a las relaciones que podemos crear entre las diferentes tablas, permiten
almacenar y efectuar la extracción de información de una manera muy eficiente.
6.2.2. Bases de datos no relacionales
Este tipo de bases de datos están muy ligadas al concepto de “Big Data”. De una forma más
clara, “Big Data” implica, normalmente, el uso de una base de datos no relacional o NoSQL. Lo
contrario no se cumple necesariamente.
Son, por tanto, este tipo de base de datos las que nos permiten utilizar y procesar ingentes
cantidades de información que pueden provenir de distintas fuentes.
Ejemplo
La preparación y construcción del acueducto de Millau duró, en total, alrededor de 17 años.

Imaginemos, a lo largo de esos 17 años, la cantidad de datos generados en los distintos
procesos, cálculos, etc. llevados a cabo. Una vez construido, el acueducto posee multitud de
sensores que continúan registrando datos en cuanto a, por ejemplo, esfuerzos soportados en
las pilas y tirantes, vibraciones, viento, etc. Estamos hablando, por tanto, de millones y millones
de registros que nos permiten gestionar la infraestructura de una forma más eficiente, prever
situaciones de riesgo para los usuarios y muchísimas aplicaciones más.
21
Figura 8: Acueducto de Millau.
Las principales características de estas bases de datos son:
 No utilizan lenguaje SQL
 Rompen la estructura relacional
Las bases de datos NoSQL tienen, en realidad, muy poco en común (técnicamente
hablando) entre ellas y, precisamente, tan sólo se parecen en que no son relacionales.
Existen 4 grandes grupos de bases de datos NoSQL: las orientadas a documentos, las de
clave-valor, las orientadas a columna y las orientadas a grafos. Invitamos a investigar sobre
ellas y sus diferencias para tener una noción algo más amplia que la que quiere dar esta
pequeña introducción teórica.
22
Las posibles aplicaciones de este tipo de bases de datos son:
 Análisis de pautas (por ejemplo de tráfico en un cierto tramo de carretera o de

movimiento de personas en un edificio bajo situaciones de evacuación).
 Realización de modelos predictivos (como por ejemplo el de “vida” de la

infraestructura).
 Almacenamiento de datos cuando, como en el ejemplo anterior, la cantidad de

información generada es muy elevada y coincidente con el ciclo de vida del producto
construido.
 Etc.
Una vez más nos gustaría recalcar la importancia que tiene para el futuro BIM manager de una
empresa o administración pública el tener nociones básicas sobre estos conceptos. Por nuestra
experiencia profesional durante los últimos años sabemos que el debate acerca del tipo de
tecnología que se va a utilizar en cada gran proyecto de arquitectura e ingeniería o la solución
que la empresa va adoptar en el ámbito de la gestión y almacenamiento de la información es
crucial y puede tener consecuencias catastróficas si no se usan las soluciones adecuadas. Y
este no es un debate ajeno al BIM manager; de hecho, estas decisiones forman parte del grupo
que nosotros consideramos decisivas dentro de este rol. En proyectos como “High speed 2” en
Reino Unido o “Fehmarn Belt Fixed Link” en Dinamarca estas decisiones forman parte del
principal cometido de los “BIM managers” y/o “Chief Technical Officers”.
6.3 Bases de datos utilizadas por los programas de diseño
Es importante, desde luego no esencial, conocer la estructura básica del programa que
estamos utilizando. De esta forma, utilizamos el software no como una caja negra en las que
no sabemos qué ocurre cuando introducimos y extraemos información sino como una
aplicación de la que conocemos sus límites y de la que por tanto podemos saber exactamente
qué esperar cuando la utilicemos.
Una vez llegados a este punto y para darle un enfoque más cercano y práctico al temario que
estamos desarrollando nos gustaría poner nuestra mirada sobre los programas de diseño y
modelado que se utilizan en el día a día de nuestra práctica: ¿cómo organizan la información
esos programas de diseño?, ¿qué relación pueden tener esos programas de diseño con bases
de datos externas a los mismos?, etc. Intentemos, pues, dar respuestas a estas preguntas.
23
Para ello y debido a la gran amplitud de software de diseño y modelado orientado a objetos y
paramétrico que existe en el mercado nos vamos a centrar en la solución más utilizada, a
saber, ®Autodesk Revit. Intentaremos, de forma sucinta, explicar primero como está
estructurada la información en este software de forma interna para, después, mostrar cómo
podemos interactuar a partir de él con otras bases de datos externas.
6.4 ¿Cómo se organiza la información dentro de ®Autodesk Revit?
Como se puede observar en la figura 9, existen dos grandes grupos de componentes dentro de
la base de datos de ®Autodesk Revit:
 Los componentes de proyecto, que son parte de él pero no son elementos

modelables por el usuario final de la aplicación. Así, por ejemplo, son parte de este
grupo: las vistas, todos los tipos de parámetros, colecciones de elementos, etc.
 Los componentes de modelado, que son todos aquellos elementos creados por el
usuario final de la aplicación. De estos, además, podemos hacer otra clasificación en
3 subgrupos: Los elementos modelados (suelos, paredes, etc.), los elementos de
vista (secciones, vistas 3D, etc.) y los elementos de anotación (niveles, líneas de
referencia, etc.)
24
Figura 9: Estructura base de datos de ®Autodesk Revit. ®Autodesk 2009.
25
Dentro de la misma figura, y sobre fondo gris-azulado, podemos observar ejemplos de la

jerarquización de objetos dentro de la base de datos de Revit. Es esta, según nuestra opinión,
una de las primeras nociones que se deberían adquirir al usar un software de modelado
orientado a objetos como es el caso.
Dentro de la base de datos existe un elemento que tiene unos atributos definidos (Categoría).
A partir de ese objeto-base se define otro, también genérico, que tiene más atributos que el
anterior y que por tanto está definido de forma más concreta –Familia-. A su vez, para esos
elementos llamados familias, se definen valores para sus atributos que son de carácter fijo, y
es así como creamos los tipos. El usuario final de la aplicación particulariza ese tipo creando lo
que en lenguaje informático se denomina instancia. Esas instancias creadas tienen por tanto:
un origen común en cuanto a elemento en la base de datos (por ser de la misma familia),
valores comunes en alguno de sus atributos (por ser del mismo tipo) y, si fuese el caso, valores
distintos en algunos atributos que son específicos de cada instancia.
La figura 9 puede consultarse en el siguiente enlace para una mejor visualización de la misma:
https://rcd.typepad.com/autodesk_revit_model_structure.png
Figura 10: Familias, tipos e instancias. ®The Dynamo Primer Project. Autodesk 2017.
26
La figura 10 ilustra la teoría que explicábamos anteriormente. En este caso la categoría

“Columnas”, está dividida en 2 familias: Columnas de sección cuadrada y columnas de sección
circular. A su vez forman parte de esas familias distintos tipos de columnas que en este caso
agrupamos por una dimensión que las define (el radio en las de sección circular y las
dimensiones de los lados en las de sección cuadrada). El usuarió final creará una o multiples
instancias de esos tipos en su modelo y esas instancias podrán tener atributos propios (por
ejemplo la asignación de un código a cada columna).
Recomendamos consultar el siguiente enlace que describe con exhaustividad todos los tipos
de objetos que existían para la versión 2010 de ®Autodesk Revit (y que básicamente está aún
vigente) y que ilustra todos los conceptos que estamos introduciendo en este último punto.
http://thebuildingcoder.typepad.com/files/revit-api-class-diagram.png
Pasemos ahora, tras describir como está estructurada la información dentro de ®Autodesk
Revit, a la segunda pregunta que proponíamos al inicio de este punto: la interacción de
®Autodesk Revit con bases de datos externas.
6.5 ¿Cómo podemos interactuar con ®Autodesk Revit utilizando bases de

datos externas a la aplicación?
®Autodesk Revit tiene, de forma nativa, una forma de conexión y protocolo ODBC (Open
Database Connectivity) que permite la importación y exportación de datos usando el lenguaje
SQL como estándar para acceder a la información. Por tanto, podemos deducir, atendiendo a
los conceptos de bases de datos que hemos dado en puntos anteriores de este mismo tema,
que es muy sencillo conectar de forma directa una base de datos relacional con ®Autodesk
Revit.
Queremos hacer en este punto un muy importante inciso. Observamos que es cada vez más
frecuente utilizar estos softwares de modelado paramétrico como contenedores de gran
cantidad de datos que son totalmente complementarios a la geometría de lo proyectado en sí.
No debiera ser nunca el propósito de un buen gestor de información el almacenamiento masivo
de datos/información en un software que no está diseñado para ese fin. Ya que ®Autodesk
Revit nos permite enlazar con bases de datos externas, ¡incluso de forma nativa!, hagamos uso
de esa funcionalidad.
27
Así la herramienta “DB Link” permite la extracción de datos en forma de tablas que el usuario
puede manipular en esa base de datos externa para su posterior reutilización e introducción en
el modelo geométrico BIM si ese fuese el caso.
“Revit DB Link” se distribuye de forma oficial por Autodesk y se puede instalar como un
complemento más. Una vez accedemos al mismo podemos configurar el enlace a nuestra base
de datos SQL de una forma relativamente sencilla. Es conveniente realizar, si fuese posible, y a
modo de práctica o ejercicio el enlace a ®Microsoft Access.
Figura 12: Acceso a Revit DB Link. ® Autodesk 2017.
Figura 11: Primer menú Revit DB Link. ® Autodesk 2017.
28
Recomiendo para este fin la ayuda oficial de ®Autodesk que se puede consultar en este
enlace:
http://goo.gl/9n1k3x
Así mismo se pueden conseguir enlaces con bases de datos externas de forma programática
usando complementos (plug-ins) ad-hoc o, también, mediante la herramienta de programación
visual “Dynamo”, que no deja de usar las mismas capacidades que las anteriores pero de una
forma más sencilla e intuitiva mediante distintos nodos (nodes) conectados por “alambres”
(wires).
Figura 12: Rutina de Dynamo para Revit. ®Autodesk 2017.
Utilizando esta sistemática recomiendo encarecidamente el siguiente post del blog “Revit
beyond BIM” de Dieter Vermeulen en el que explica de forma detallada cómo conseguir este
tipo de conexiones:
https://revitbeyondbim.wordpress.com/2015/09/09/driving-a-sql-database-with-dynamo/
29
Como vemos, existen diversas formas de poder conectar bases de datos externas con
®Autodesk Revit de tal forma que puedan ser configuradas por nosotros mismos. Pero también
existen aplicaciones comerciales que utilizan estas capacidades y que nos ofrecen altísimas
posibilidades pudiendo mejorar de forma considerable nuestros flujos de trabajo a nivel
organizativo. En este caso, y para alguna de esas aplicaciones, no sólo podemos conectar a
bases de datos relacionales o SQL sino también a bases de datos no relacionales preparadas
para el manejo de grandes volúmenes de información y que muchas veces servirán como
herramientas de gestión de información una vez el proyecto ejecutado entre en la fase de
explotación.
30
7. SEMÁNTICA, ONTOLOGÍA Y TAXONOMÍA

En los puntos anteriores de este bloque temático hemos conocido la importancia que tiene la
gestión de la información en nuestra industria, hemos asimilado las principales herramientas
que nos permiten realizar esa gestión de la información de una manera eficiente y hemos
empezado a entender cómo dichas herramientas -las bases de datos- están organizadas y
“construidas”. En este bloque temático ahondaremos en este último campo y lo relacionaremos
con la metodología BIM.
7.1 Definiciones y conceptos básicos
Una de las claves y principales características de la metodología BIM es que pretende

gestionar la información del proceso proyecto-construcción-explotación-demolición para el ciclo
de vida del producto construido. Para ese fin, y para que la información generada durante el
proceso proyecto-construcción tenga sentido durante la fase de explotación, debemos orientar
nuestros procesos, geometría del proyecto, etc. a objetos. Esa es, por tanto, otra de las
claves de la metodología BIM: el proceso proyecto-construcción se orienta a objetos
para que la información generada durante esa parte del ciclo de vida del producto a
construir sea útil durante la etapa de explotación.
Ejemplo: Durante la fase de diseño y construcción de un edificio que servirá como nueva sede
de un banco en Alicante toda la geometría del proyecto se realiza con herramientas 2D, no
orientada a objetos (®Autodesk AutoCAD) y sin apoyo de ninguna base de datos externa
conectada al programa de diseño. ¿Servirá ese modelo geométrico para, por ejemplo,
identificar y conocer la garantía de un aparato de aire acondicionado que, tras su puesta en
funcionamiento, deja de funcionar al cabo de 2 meses?, ¿Y para saber quién fue la persona
que realizó la instalación?
31
Figura 13: Aire acondicionado en edificio de oficinas.
Existen en el ejemplo anterior formas de responder de forma positiva a las preguntas

realizadas pero, si ese fuera el caso, la forma de realizar ese proceso no sería de una forma
limpia sino encontrando una forma alternativa y no nativa por parte del software que hemos
utilizado en la fase de proyecto.
Es, por tanto, esencial que nuestro proyecto contemple el uso de software de diseño orientado
a objetos y, de forma ideal, utilice bases de datos externas que relacionen la geometría con
todo tipo de información necesaria para una correcta explotación de lo construido.
La otra de las claves importantísimas para la metodología BIM es la interoperabilidad

entre los distintos paquetes de software utilizados en nuestra industria, la cual se debe
entender no solo cómo interoperabilidad en los formatos o sintáctica (ifc, json, xml, rdf,
etc.), sino también en el significado o semántica.
32
Figura 15: Algunos estándares abiertos relacionados con la Metodología BIM. ®The BIM Hub.
Para que se pueda aprehender la correcta implementación y compresión de las dos claves
citadas durante esta introducción y, que tienen tanto que ver con la primera parte de este
bloque temático, hablaremos en profundidad de los conceptos de semántica, ontología y
taxonomía.
7.1.1. Semántica
Como decíamos, existe una tremenda problemática en nuestra industria para la gestión de la
información a lo largo del ciclo de vida de la infraestructura o edificio que es objeto del proceso.
La metodología BIM intenta tener una visión holística de la información a lo largo de ese ciclo
de vida utilizando distinto software y/o bases de datos para ello. El problema que tenemos, no
obstante, es que a lo largo del ciclo de vida del producto construido tendremos que utilizar
distinto software de otras tantas compañías y que es muy complicado lograr que esas distintas
aplicaciones se “entiendan” entre sí.
33
Figura 16: Aplicaciones de software en la industria de la construcción. ®BUILTR LABS.
Nota: Recomendamos visitar el blog de los autores de la imagen anterior para un mayor detalle
de la imagen: BUILTR LABS
¡Y recordemos que éstas son tan sólo parte de las aplicaciones y que no todas ellas están
representadas en esta última imagen!
¿Cómo lograr que las distintas aplicaciones se entiendan entre sí para mejorar la eficiencia y
efectividad en la gestión de la información del proceso?
Una de las claves reside en el concepto de semántica. En el campo de tecnologías de la

Información entendemos por semántica a la disciplina que tiene por finalidad estudiar el
significado no sólo de los datos que estudiamos sino también de las relaciones que
existen entre los mismos. Así, podemos decir que distintos software que no tengan una
arquitectura común podrán “dialogar” entre ellos si tienen la capacidad (entre otros requisitos)
de interpretar al otro.
34
Ejemplo: ®Autodesk Revit y ®Tekla BIMsight son 2 aplicaciones de software de empresas

distintas pero que pueden tener un cierto grado de compatibilidad utilizando el tipo de archivo
adecuado (ifc en este caso). Esto es debido a que, Revit está preparado para traducir su
formato de proyecto nativo (rvt) a otro estándar (ifc) de tal forma que semánticamente existe la
capacidad por parte del software de interpretar los datos en formato rvt y traducirlos al formato
ifc. Hablamos en este caso de interoperabilidad limitada o de compatibilidad entre ambos.
Figura 17: Grados de interoperabilidad. ®AFUL interoperability working group.
Pero, debido a la complejidad de nuestra industria y los proyectos que realizamos,

deberíamos no conformarnos con este tipo de interoperabilidad limitada y abogar por
una transferencia de información no sólo sintáctica sino también de significado.
Estaríamos entonces utilizando lo que se conoce como un estándar abierto, en el que
todas las aplicaciones participantes en el proceso entienden a la perfección los datos y
sus relaciones con otras implicadas en el proyecto.
35
7.1.2. Ontología
Una ontología es un esquema conceptual que representa de manera formal un grupo de

conceptos o nodos que tienen ciertas propiedades o atributos y de las relaciones que tienen
entre sí esos conceptos.
Figura 17: ®The BIM ontology v3.1 (Neuron Model v0.4, Updated July 28, 2016) BIMe initiative. Succar, Sher, &
Aranda-Mena, 2007
Como expresamos en puntos anteriores de este bloque temático iniciativas como la del BSDD
(Building Smart Data Dictionary),de Building Smart, trata de definir una ontología formal para la
industria de la construcción y, en este caso, muy centrada en el de la edificación y arquitectura.
Existen otras iniciativas relacionadas también con puntos tratados anteriormente como la de
ifcOWL, que provee un lenguaje de marcado (web ontology language) para la representación
de IFC (archivo abierto de la metodología BIM para la industria de la construcción).
36
Es preciso que se entienda que un archivo ifc viene definido por una ontología y que,
debido a que esa ontología es conocida por distintas aplicaciones de software, ese
archivo podrá ser “entendido” y “leído” de forma unívoca.
7.1.3. Taxonomía
Una taxonomía no es otra cosa que una clasificación, normalmente jerárquica, que permite
categorizar objetos de acuerdo a ciertos criterios en cuanto a sus propiedades. Por ejemplo
Autodesk Revit incorpora por defecto para sus familias la clasificación OMNICLASS.
Figura 18: ®Autodesk Revit. Tabla 23 Omniclass.
37
Recomendamos encarecidamente a todos los usuarios de ®Autodesk Revit la instalación del

complemento “Classification Manager for Revit” que permitirá al usuario final de este software
de modelado la asignación de distintas clasificaciones a los objetos utilizados en el modelo.
Pueden consultar más información en este link: https://goo.gl/aoQUJj
7.2 ISO 12006-2:2015: Cómo construir una clasificación siguiendo un

estándar
Una vez que conocemos los conceptos de semántica, ontología y taxonomía podemos abordar
sin ninguna cortapisa o limitación la construcción de una clasificación de objetos.
Como dijimos anteriormente, la metodología BIM no se entiende si no podemos orientar

nuestros flujos de trabajo, geometría y datos en general precisamente a objetos o elementos.
Es este un requerimiento de la forma de trabajo en BIM que permite que, durante la fase de
mantenimiento, podamos utilizar todo el potencial de la información generada durante el
proceso proyecto-construcción.
Existen multitud de clasificaciones de objetos para la industria de la construcción que se

empezaron a desarrollar a mediados del siglo pasado. Analizaremos muchas de ellas en el
siguiente punto, pero en este lo que nos interesa es saber cómo se construyen para, así, poder
ser críticos con la que escoger posteriormente.
La metodología BIM y las nuevas formas de adquisición requieren de una manera de

categorizar estos productos de tal forma que la información creada alrededor de ellos
esté estandarizada y fomente la colaboración entre los distintos agentes implicados. Las
normas ISO 12006-2 y 12006-3 buscan fomentar esa estandarización.
No son normas que pretendan crear una única clasificación. Al contrario, son normas que crean
un marco de referencia común de tal forma que, aunque surjan distintas iniciativas en otros
tantos países o regiones, todas ellas se rigen por los mismos principios para establecer la
posibilidad de relacionar las clasificaciones de una forma directa y eficiente.
Es por ello que recomendamos a todos aquellos futuros BIM manager que estén realizando los
estudios en los que se engloban estos apuntes que sean incisivos al utilizar clasificaciones y se
aseguren que están basados en esta normativa estándar a nivel mundial. Hay que resaltar que
la clasificación de objetos elegida para un proyecto puede llegar incluso a condicionar la forma
en la que modelamos el edificio o la infraestructura.
38
Ejemplo: Para el proyecto de un rascacielos en la ciudad de Dubái un despacho de arquitectura

español recibe el encargo de comenzar a desarrollar el modelo con un nivel de detalle (LOD)
300 por parte de un contratista francés. El contratista exige utilizar la clasificación francesa XP
P07-150, pero la autoridad de Dubái debe recibir todos los modelos siguiendo la norma
UNICLASS inglesa. Si esas 2 normas no estuvieran realizadas dentro del mismo marco
resultaría muy difícil mapear ambas clasificaciones.
Existen dos relaciones fundamentales a tener en cuenta dentro de esta normativa y que dotan
de semántica a la jerarquía que obtengamos al realizar la clasificación:
1. Relación “es del tipo de” en la que un elemento contiene características de su

superior jerárquico y, además, alguna otra que lo diferencia de él. Utilizando esta
relación creamos una clasificación formal.
Figura 19: Jerarquía de clasificación.
2. Relación “es parte de”, en la que el elemento inferior en la jerarquía forma parte
(físicamente) de su elemento superior, pudiendo ser éste completamente distinto.
Utilizando esta relación creamos una composición formal.
39
Figura 20: Jerarquía de composición.
Las dos relaciones anteriores se pueden combinar dando lugar a una vista mixta que
podríamos definir como “clasificación-composición”
Figura 21: Jerarquía mixta (Clasificación – Composición).
40
Además, la norma identifica define a los agentes y actividades que pueden participar en el
proceso proyecto-construcción-explotación y también a los productos del proceso en sí.
También guía y aconseja en el tipo de tablas a utilizar.
Por tanto, la ISO 12006-2:2015 puede servir a las administraciones públicas y empresas
privadas para la realización de clasificaciones de objetos de forma que, sea cual sea el
resultado de su clasificación, estas entidades estén seguras que el producto de su
trabajo es acorde a los estándares internacionales más adecuados.
7.3 Ejemplos de clasificaciones en el mundo: UNICLASS, OMNICLASS, Sfb…
Existen en la actualidad diferentes clasificaciones (o taxonomías) en todo el mundo, estando

sólo alguna de ellas basadas en la norma ISO explicada anteriormente. También hay que
recalcar que, además de las clasificaciones que ya se están usando de forma activa, existen
muchas iniciativas en diferentes países para o bien adoptar alguna de las existentes, o bien
crear otras nuevas.
Es nuestra labor a partir de estos momentos determinar clasificaciones dentro del mismo marco
estándar para facilitar nuestra labor profesional y la de nuestros colegas.
7.3.1. UNICLASS 2015
Definida para la industria de construcción en el Reino Unido, esta clasificación está construida
a partir de la norma ISO 12006-2:2015. Está dividida en un conjunto de tablas jerárquicas que
pueden ser utilizadas como referencia para la identificación, estimación de costes, organización
CAD y un largo etcétera.
Las tablas están pensadas para cubrir la información más genérica (Complejo) hasta la más
detallada (Entidad)
41
Figura 22: Relaciones entre Actividades con el resto de elementos en Uniclass. ®NBS
Figura 23: Objetos en Uniclass. ®NBS
Recomendamos la visita al sitio web de la NBS para estudiar con más detalle esta clasificación
y sus tablas: https://toolkit.thenbs.com/articles/classification
42
7.3.2. OMNICLASS
El sistema de clasificación de construcción OmniClass (también OCCS) es un sistema de

clasificación para la industria de la construcción, utilizado eminentemente en América, útil para
muchas aplicaciones, desde la organización de materiales de una biblioteca o la información
del proyecto, hasta la provisión de una estructura de clasificación para bases de datos.
Dos detalles importantes para ser mencionados a la hora de hablar de esta clasificación:
 Incorpora otros sistemas existentes actualmente en uso como la base de muchas de

sus tablas: MasterFormat™, para resultados de trabajo; UniFormat, para elementos y
EPIC (Electronic Product Information Cooperation) para la estructuración de
productos.
 Algunos programas de modelado orientados a objetos la traen por defecto en sus

librerías.
Figura 24: número Omniclass en familia de Autodesk Revit
Recomiendo visitar el siguiente sitio web para obtener una idea más completa de esta
clasificación y de las distintas tablas de las que se compone: http://www.omniclass.org/
43
7.3.3. Sfb
Posiblemente esta clasificación de origen sueca fue la primera en intentar crear una taxonomía
standard en el sector de la ingeniería, arquitectura y construcción. Su nombre en sueco
“Samarbetskomittén för Byggnadsfrågor” quiere decir algo así como manual indexado para el
sector de la construcción. Fue creada en 1950, reutilizada prácticamente en toda Europa a
partir de los años 60 y es, básicamente, la clasificación a partir de la cual se ha desarrollado
otras mucho más recientes cómo las citadas anteriormente. Aun así esta clasificación de los
años 50/60 del siglo pasado tiene una peculiaridad: ha ido evolucionando en el tiempo y es,
aún, la clasificación de referencia en países del centro Europa como Bélgica y Holanda.
Consta de 5 tablas que agrupan los siguientes ítems:
 Tabla 0: Medio físico del proyecto
 Tabla 1: Elementos
 Tabla 2: Formas de construcción
 Tabla 3: Materiales
 Tabla 4: Actividades y requerimientos
Esta clasificación ,que fue un estándar de facto en muchos países del centro y norte de
Europa, ha ido siendo sustituida en su mayoría por otras más modernas que tienen en cuenta
las nuevas metodologías de trabajo. En los países en los que aún se mantiene como estándar
ha sufrido una adecuación para que pueda seguir siendo “compatible” con nuestra forma de
trabajo.
44
Figura 25: Sitio web de la NL/Sfb en Holanda.
7.3.4. OTRAS CLASIFICACIONES
Existen otras clasificaciones orientadas a objetos tales como UniFormat y MasterFormat y

multitud de iniciativas en otros tantos países para la creación de nuevas o adaptación de las
existentes a la realidad de sus respectivos mercados. En España por ejemplo tenemos la
iniciativa del Grupo de Usuarios BIM de Cataluña que han creado la denominada “GuBIMClass”
(http://gubimcat.blogspot.com.es/p/lobjectiu-ha-estat-obtenir-un-sistema_19.html#castellano) y
que ha sido promovida y adoptada por el gobierno autonómico.
45
Figura 26: Vista de la clasificación GuBIMClass. ®GuBIMCat
46

Bim M3T1 01

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Bim M3T1 01

Transféré par

Droits d'auteur :

Formats disponibles

TEORÍA DE LA INFORMACIÓN

2. FLUJOS DE INFORMACIÓN EN EL SECTOR DE LA CONSTRUCCIÓN ............................................................... 5

3. FLUJOS DE INFORMACIÓN EN EL PASADO RECIENTE ..................................................................................... 6

4. FLUJOS DE INFORMACIÓN CON METODOLOGÍA BIM ..................................................................................... 11

4.1 Ejemplo práctico .................................................................................................................................................. 15

5. EL FUTURO: DATOS ENLAZADOS ...................................................................................................................... 16

5.2 Ejemplo práctico .................................................................................................................................................. 17

6. TIPOLOGÍAS DE BASES DE DATOS .................................................................................................................... 18

6.1 ¿Qué es una base de datos? .............................................................................................................................. 18

7. SEMÁNTICA, ONTOLOGÍA Y TAXONOMÍA.......................................................................................................... 31

7.1 Definiciones y conceptos básicos ........................................................................................................................ 31

2. FLUJOS DE INFORMACIÓN EN EL SECTOR DE LA

La metodología BIM (Building Information Management) ha significado una mejora y una

En este bloque temático intentaremos dotar al alumnado de los conocimientos mínimos

Recordemos que lo esencial en la metodología BIM no es qué software utilizar para el

3. FLUJOS DE INFORMACIÓN EN EL PASADO RECIENTE

 Información: “es un mensaje, o algún tipo de comunicación audible o visible y tiene

 Documento: Es el continente de la información.

Figura 1: Procedimiento Clásico –Simplificado. Apuntes de “Proyectos de Ingeniería civil” ETSICCP-UPV.

Imaginemos una reunión de coordinación durante la fase inicial de construcción de un proyecto.

En el mundo analógico estas preguntas tenían respuesta en forma de papel, en el mundo

4. FLUJOS DE INFORMACIÓN CON METODOLOGÍA BIM

La organización de los flujos de información, de forma muy simplificada y teniendo en cuenta

Figura 3: Modelo Federado y CDE. ® 2014 New Zealand BIM Handbook.

Es muy importante resaltar que la información generada en el proceso proyecto-construcción y

4.1 Ejemplo práctico

La clara ventaja de esta sistemática con respecto a metodologías anteriores es la

5. EL FUTURO: DATOS ENLAZADOS

 Acceder a la información de forma remota.

 Acceder a la información de forma heterogénea sin importar el tipo de hardware con

 Descentralizar la información de tal forma que los sistemas no recreasen la

 Permitir la automatización del análisis de los datos almacenados.

Aquel año Tim Berners-Lee creó internet.

5.2 Ejemplo práctico

Un despacho de arquitectura está diseñando un nuevo edificio en la ciudad de Ámsterdam.

Existen esfuerzos por parte de distintas organizaciones, países y entidades supranacionales

6. TIPOLOGÍAS DE BASES DE DATOS

6.1 ¿Qué es una base de datos?

Una base de datos es una forma estructurada de almacenaje de datos (llamadas

6.2 Bases de datos Relacionales y no Relacionales

6.2.1. Bases de datos Relacionales

 Las columnas se denominan “campos” o “atributos”.

 Utilizan el lenguaje SQL.

6.2.2. Bases de datos no relacionales

La preparación y construcción del acueducto de Millau duró, en total, alrededor de 17 años.

Figura 8: Acueducto de Millau.

Las principales características de estas bases de datos son:

 No utilizan lenguaje SQL

 Rompen la estructura relacional

Las posibles aplicaciones de este tipo de bases de datos son:

 Análisis de pautas (por ejemplo de tráfico en un cierto tramo de carretera o de

 Realización de modelos predictivos (como por ejemplo el de “vida” de la

 Almacenamiento de datos cuando, como en el ejemplo anterior, la cantidad de

6.3 Bases de datos utilizadas por los programas de diseño

6.4 ¿Cómo se organiza la información dentro de ®Autodesk Revit?

 Los componentes de proyecto, que son parte de él pero no son elementos

Figura 9: Estructura base de datos de ®Autodesk Revit. ®Autodesk 2009.

Dentro de la misma figura, y sobre fondo gris-azulado, podemos observar ejemplos de la

La figura 10 ilustra la teoría que explicábamos anteriormente. En este caso la categoría

6.5 ¿Cómo podemos interactuar con ®Autodesk Revit utilizando bases de

Figura 12: Acceso a Revit DB Link. ® Autodesk 2017.

Figura 11: Primer menú Revit DB Link. ® Autodesk 2017.

Figura 12: Rutina de Dynamo para Revit. ®Autodesk 2017.