Modelo de base de datos jerárquico es un enfoque para organizar datos en una estructura de árbol en la que las entidades se relacionan mediante asociaciones padre-hijo. En este modelo, cada registro (nodo) tiene a lo sumo un padre, mientras que un padre puede tener múltiples hijos; las relaciones típicamente representan un mapeo 1:N. Los atributos de cada registro se agrupan bajo su tipo de entidad, equivalente conceptual a una fila dentro de una tabla en otros modelos.

Historia y ejemplos

El modelo jerárquico fue de los primeros en utilizarse en sistemas de gestión de bases de datos comerciales. Entre las implementaciones históricas y aún relevantes se encuentran IMS —desarrollada por IBM— y el Registro de Windows (Windows Registry) —de Microsoft—. IMS ha continuado en uso intensivo en entornos de mainframe para aplicaciones transaccionales críticas; el Registro de Windows emplea una estructura jerárquica para almacenar configuraciones del sistema y de aplicaciones.

Características principales

  • Estructura en árbol: nodos organizados en niveles con relaciones padre-hijo claras.
  • Cardinalidad 1:N: cada relación conecta un único padre con cero o varios hijos.
  • Acceso por recorrido: las operaciones suelen requerir navegar la jerarquía desde un nodo raíz o desde puntos conocidos.
  • Integridad referencial implícita: la estructura fija reduce ciertas incertidumbres sobre pertenencia y jerarquía, pero limita la representación natural de relaciones muchos a muchos.
  • Optimización para jerarquías estáticas: eficiente cuando la estructura de datos es estable y las consultas siguen la jerarquía.

Ventajas

  • Rendimiento eficiente en consultas que explotan la jerarquía natural (p. ej., recorridos parent→child).
  • Modelo sencillo y fácil de entender para datos inherentemente jerárquicos (árboles de decisión, estructuras de organización).
  • Bajo coste de almacenamiento para relaciones 1:N bien definidas y predecibles.

Limitaciones

  • Poca flexibilidad para representar relaciones complejas, en particular relaciones muchos a muchos sin duplicación de datos o enlaces adicionales.
  • Operaciones que requieren acceso inverso (child→parent o entre ramas no relacionadas) pueden ser costosas si no hay índices o desnormalización.
  • Dificultad para evolucionar la estructura si cambian los requisitos; los cambios en la jerarquía pueden requerir modificaciones amplias.

Operaciones y consultas

Las consultas en bases de datos jerárquicas suelen realizarse recorriendo la estructura desde nodos raíz o mediante punteros directos entre padres e hijos. Muchas implementaciones ofrecen mecanismos para navegar hacia arriba y hacia abajo en la jerarquía, filtrado por atributos del nodo y operaciones de inserción/borrado que preservan la integridad de la estructura.

Comparación con otros modelos

  • Relacional: el modelo relacional ofrece mayor flexibilidad para representar relaciones arbitrarias mediante claves y joins; por el contrario, el jerárquico es más rígido pero puede ser más eficiente para casos 1:N bien definidos.
  • En red (network): el modelo en red permite relaciones más generales (múltiples padres), mientras que el jerárquico restringe a un único padre por nodo.
  • Documentos y grafos: los modelos de documento y de grafos son actualmente preferidos para datos con estructuras anidadas o relaciones complejas que cambian con frecuencia.

Usos actuales

Aunque hoy día muchas aplicaciones nuevas usan bases de datos relacionales, de documentos o grafos, las bases de datos jerárquicas siguen siendo comunes en sistemas heredados, en almacenamiento de configuraciones (por ejemplo, el Registro de Windows) y en aplicaciones donde la jerarquía es estable y predominante. En entornos industriales y bancarios, implementaciones como IMS continúan en operación por su fiabilidad y rendimiento en cargas transaccionales.

Consideraciones de diseño

Al diseñar una solución con modelo jerárquico conviene evaluar la estabilidad de la jerarquía, los requisitos de consulta (si predominan accesos jerárquicos) y el coste de mantener integridad cuando se necesita representar relaciones no jerárquicas. En muchos casos, una combinación de modelos o la capa de aplicación que gestione enlaces adicionales puede ser la opción práctica para superar las limitaciones inherentes.

En resumen, el modelo de base de datos jerárquico es apropiado para dominios con estructuras en árbol claramente definidas y requisitos de rendimiento favorables a recorridos jerárquicos, pero su rigidez lo hace menos adecuado cuando las relaciones entre datos son múltiples y cambiantes.