Tag: Oracle

Acceso a estructuras jerárquicas en Oracle (II)

En el post anterior explicábamos la forma en la que podíamos consultar información organizada de forma jerárquica en ORACLE a través de consultas jerárquicas mediante el uso de la cláusula CONNECT BY.

En este post propondremos una alternativa mediante el uso la cláusula WITH. Su uso recursivo fue incluido en la versión 11g release 2. Por tanto este mecanismo solo es válido para las versiones de ORACLE superiores a esta.

La cláusula WITH

La cláusula WITH (también conocida como cláusula de factorización de subconsultas) fue incluida como parte del estándar SQL-99 y se añadió a la sintaxis SQL de Oracle a partir de la versión 9.2.

Para los que no la conocen, esta cláusula nos permite declarar subconsultas que pueden ser utilizadas múltiples veces en nuestras SELECTs sin necesidad de repetir su código. Estas subconsultas podrán ser procesadas como vistas “inline†o como tablas temporales según nuestras necesidades de rendimiento.

Seguir leyendo…

Acceso a estructuras jerárquicas en Oracle (I)

Cuando trabajamos con Bases de Datos Relacionales como sistema persistente de los datos de nuestras aplicaciones, no es nada raro encontrarnos con información organizada de manera jerárquica. ¿Quién no ha trabajado alguna vez con departamentos, áreas o empleados en sus aplicaciones cuya información se encontraba persistida en una Base de Datos?

Este post pretende explicar la forma en la que podemos generar consultas SQL para obtener información que se encuentre estructurada de esta manera.

Nuestro punto de partida

Supongamos que tenemos la siguiente estructura jerárquica y queremos que esté almacenada en base de datos con la finalidad de poder consultarla posteriormente:

oracle1-cmp

Para ello podríamos crear una estructura similar a esta:


DROP TABLE Node PURGE;

CREATE TABLE Node (
  id        NUMBER,
  node_name VARCHAR2(20 BYTE),
  parent_id NUMBER,
  
  CONSTRAINT Node_pk PRIMARY KEY (id),
  CONSTRAINT Node_Node_fk FOREIGN KEY (parent_id) REFERENCES Node(id)
);

CREATE INDEX Node_parent_id_idx ON Node(parent_id);

INSERT INTO Node VALUES (1, 'Nodo 1', NULL);
INSERT INTO Node VALUES (2, 'Nodo 2', 1);
INSERT INTO Node VALUES (3, 'Nodo 3', 2);
INSERT INTO Node VALUES (4, 'Nodo 4', 2);
INSERT INTO Node VALUES (5, 'Nodo 5', 4);
INSERT INTO Node VALUES (6, 'Nodo 6', 4);
INSERT INTO Node VALUES (7, 'Nodo 7', 1);
INSERT INTO Node VALUES (8, 'Nodo 8', 1);
INSERT INTO Node VALUES (9, 'Nodo 9', 8);
INSERT INTO Node VALUES (10, 'Nodo 10', 8);
INSERT INTO Node VALUES (11, 'Nodo 11', 10);
COMMIT;
COMMIT;

Consultas jerárquicas

Para poder consultar este tipo de estructuras lo primero que debemos identificar es como se relacionan los elementos hijos con sus padres. En nuestro caso todos los nodos almacenados en nuestra tabla disponen de un campo clave llamado id, y de un campo parent_id que contiene la referencia al campo id de su elemento padre.

Seguir leyendo…

JPA: especificar el esquema de base de datos en tiempo de ejecución con EclipseLink

EclipseLinkDurante el ciclo de vida de una aplicación Java EE es común que se despliegue en diferentes entornos antes de llegar al entorno de producción. No sólo varían las máquinas en las que se despliega la aplicación, sino también los servidores de bases de datos.

Si nuestra aplicación web o enterprise usa el API JPA para el acceso a datos, es posible que en algunas circunstancias sea necesario especificar el catálogo o el esquema de base de datos en la anotación @Table de nuestras entidades.

¿La razón? En ciertas bases de datos, como por ejemplo Oracle, el usuario que utilizamos para la conexión no es el propietario del esquema. Por esta razón, al generar las consultas SQL es preciso especificar un «qualifier» para referirnos al catálogo o al esquema al que pertenecen las tablas.

Seguir leyendo…