Iniciación a Oracle

Desde el punto de vista de la organización lógica:

1. Jerárquicas. (Progress)
2. Relacionales. (Oracle, Access, Sybase…)

Desde el punto de vista de número de usuarios:

1. Monousuario (dBase, Access, Paradox…)
2. Multiusuario cliente/servidor (Oracle, Sybase…)

Oracle es una base de datos relacional para entornos cliente/servidor. Todo lo que hablemos a partir de ahora será aplicable sólo a bases de datos Relacionales cliente/servidor, y concretamente para bases de datos Oracle.

1. Permitir la introducción de datos por parte de los usuarios (o programadores).
2. Salida de datos.
3. Almacenamiento de datos.
4. Protección de datos; seguridad.
5. Elaboración de datos.

Básicamente, la comunicación del usuario-programador con la base de datos se hace a través de un lenguaje Denominado SQL: Structured Query Laguage (Lenguaje estructurado de consultas)

Conocimientos necesarios:

Para un programador de bases de datos el conocimiento mínimo debe ser de:

• Conocimiento básico de las estructuras internas de Oracle
• Lenguaje SQL
• Utilidades básicas: (SQL*Plus, Export, Import…)
• PL/SQL
• Tareas simples de administración
• Tunning básico de SQL.

Tareas más propias de un administrador de bases de datos pueden ser:

• Los conocimientos propios de un programador de bases de datos.
• Conocimiento profundo de estructuras internas de Oracle.
• Conocimiento profundo de los catálogos de sistema.
• Utilidades de administración (SQL*DBA, Enterprise Manager…)
• Tunning avanzado de SQL, red, memoria, discos, CPU…

Con lo que hemos dicho la estructura de una tabla es esta:

En este esquema se puede ver que cada fila almacena los datos de una factura (es decir, la entidad factura en sí), y cada columna almacena los datos de un mismo tipo (las descripciones, los clientes, etc).

De este modo se pude crear una tabla para cada tipo de entidad, y almacenar en ella los valores correspondientes.

Antes de ver qué es un índice tenemos que entender cómo se almacenan los datos. Los registros de una tabla se almacenan uno detrás de otro, respetando las longitudes de cada columna. Esto es una norma general pero en la actualidad no cumple en todas las bases de datos.

La tabla de FACTURA que hemos visto antes tiene la siguiente estructura:

La ocupación se incrementa en uno para incluir una marca de fin de columna, y en la última columna una marca de fin de registro.

La forma de almacenar en el disco duro los registros el ejemplo anterior sería la siguiente:

BOF||001|Tornillos sin rosca••••••••••••••••••••••••••••••|Pepe••••••••••••••••00000000 1000|010|0000000900||002|Tuercas•sin•agujero•••••••••••••••••••••••••••••••|Juancito•••• •••••••••000000005500|000|0000005500||003|Tuercas•de•segunda•mano••••••••••••••••••••••• ••••|Toñete••••••••••••••000000000500|001|0000000495|EOF

Podemos ver que al principio de la tabla hay una marca BOF (Begin Of File), y al final de la tabla una marca EOF (End Of File). Esto delimita el rango en el que están los datos de una determinada tabla.

Hay que darse cuenta que aunque la descripción de la factura no ocupe los 50 caracteres, es base de datos se están almacenando los restantes con el carácter “•”

Si a la base de datos le damos la siguiente orden:

 “Seleccióname la descripción de aquellas facturas cuyo cliente sea Toñete”

Lo que hará es recorrerse el fichero de datos desde la marca BOF hasta la marca EOF, “dando saltos” de N caracteres para leer sólo el campo cliente. Así dará saltos de 55 (3+1+50+1) bytes que es el espacio que hay entre el principio de registro y el principio de la columna “Cliente”. Una vez encontrada esta posición, sabemos que la descripción está 51 bytes anteriores al cliente, así que hay que posicionarse en ese byte, leer el valor y retornar el resultado.

El pseudocódigo que representa este algoritmo puede ser:

 Abrir fichero;
 Bucle mientras no se acabe el fichero
 Dar salto de 54 bytes en el fichero; Valor_campo = Leer 20 bytes de fichero;
 Si valor_campo = “Toñete” entonces
 Posicion_cliente = Posición actual del fichero;
 Dar salto de –posicion_cliente bytes;  // esto va al principio del fichero
 Dar salto de posicion_cliente – 51 bytes; Valor = Leer 50 bytes;
 Retornar valor;
 Fin-si; Fin-bucle;
 Retornar NO_ENCONTRADO;

En este pseudocódigo tenemos que tener en cuenta que la instrucción leer no consume casi tiempo, sin embargo la instrucción dar salto es la que más tiempo consume y cuando mayor sea el número de bytes de desplazamiento, peor. Este es debido a que la operación más lenta en los soportes de disco es la de posicionar las cabezas lectoras en el cilindro y sector adecuados, y una vez que el posicionamiento ya está hecho, la lectura es prácticamente instantánea. Así que en este algoritmo es muy lento porque hace demasiados saltos. A este tipo de lectura se le denomina lectura secuencial o FULL SCAN y es el caso más desfavorable en una consulta a base de datos. Además, cuando mayor sea el volumen de datos, se consiguen peores tiempos con un FULL SCAN.

Un índice es una tabla paralela a otra principal que tan sólo contienen la(s) columna(s) indicada(s) en la creación del índice. Estas columnas se las denomina columnas indexadas.

Podemos usar la analogía del índice de un libro. Cuando nosotros necesitamos buscar un tema en un libro, tenemos dos posibilidades:

• Recorrernos todas las páginas del libro buscando la primera hoja de cada tema y comprobando si es el que necesitamos. En esta búsqueda perderemos la mayoría del tiempo en pasar hojas (posicionar las cabezas lectoras) buscando el principio de cada tema, y una vez que lo hayamos encontrado, comprobar si el tema es

el deseado (leer el dato) no nos ocupará nada de tiempo.

• Podemos ir al índice en el que sólo están escritos los títulos de los temas y tan solo con pasar tres hojas

(posicionamiento de cabezas lectoras mínimo) ya hemos recorrido todo el temario. Después vamos a la página (puntero a una posición de disco) que nos indique el índice y consultamos lo que necesitemos.

Los índices en las tablas de BD son equivalentes a los índices de los libros. Siempre que exista índice, debe consultarse porque si no las búsquedas se dispararán en tiempo…

El análisis de un sistema de base de datos consta de varias fases. Entre ellas, las principales son:

Análisis conceptual (o lógico, o relacional): es un análisis abstracto de aquellas entidades que formarán la base de datos, así como las relaciones que establecen unas con otras y las restricciones que se aplican a cada una de ellas. El resultado de esta fase de análisis se ve reflejado en algo llamado Modelo Conceptual o lógico, que es una descripción de las entidades, atributos, relaciones y restricciones que compondrán la base de datos. Existen varios métodos para realizar este análisis: Entidad/Relación, Métrica, Merisse, UML, Yourdon, etc. El análisis conceptual es abstracto, por lo que no depende de la base de datos que vayamos a utilizar ni del sistema en que se vaya a implementar la base de datos.

Análisis físico consta de un análisis específico teniendo en cuenta que base de datos se va a utilizar (Oracle, Sybase…) y en qué arquitectura se va a implementar la base de datos (entornos multiusuario, plataformas NT…)

 Las  formas  normales  no  son  más  que  tres  reglas  que  se  deben  tener  un  cuenta  
 dentro  del  Análisis  conceptual,    utilizando concretamente Entidad/Relación.
 El proceso de aplicar las tres formas normales se llama normalización. 
 Un diseño de base de datos que no cumpla la primera forma   normal no será correcto. 
 Cuantas más formas normales cumpla el diseño de base de datos,  
 significará que la base de datos está más  correctamente analizada.

Primera forma normal: Identificar cada tabla con una clave primaria, y poner los datos en tablas separadas, de manera que los datos de cada tabla sean de un tipo similar (desde el punto de vista conceptual). Segunda forma normal: Sacar las columnas que sólo dependen de una parte de la clave primaria a otra tabla. Tercera forma normal: Incluir en cada tabla sólo datos que pertenezcan a la misma unidad lógica.

Estas tres normas las vamos a explicar con un ejemplo: Dado esta definición de la tabla FACTURA

Tenemos la necesidad de identificar cada uno de los registros de esta tabla inequívocamente. No podemos utilizar la descripción porque es posible que haya dos facturas con la misma descripción (dos ventas de tornillos), tampoco el cliente porque un cliente suele tener más de una factura. Ni tampoco el importe porque es normal tener varias facturas con el mismo importe.

Para ello tenemos que definir una nueva columna que nos identifique cada una de las facturas: Es posible (y bastante común) que no encontremos una columna que sea capaz de identificar a al registro completo, por ello se puede definir más de una columna dentro de la clave. En este caso es el conjunto de valores de las columna seleccionadas el que no se podrá repetir.

Esta columna (o conjunto de ellas) se denomina clave primaria (o primary key).

Las columnas marcadas con (*) son las que componen la clave primaria.

Ahora podemos estar seguros de que no habrá dos facturas con la misma referencia por lo que podemos consultar la factura con referencia = ‘FFR00123’ y estaremos seguros de que sólo habrá una.

El siguiente paso de la primera forma normal es poner los datos en tablas separadas, asegurándonos de que los datos de una tabla son datos correspondientes a aquello que almacena la tabla.

En este ejemplo podemos ver cómo en la tabla FACTURA se están guardando datos del cliente (dirección y teléfono). En caso de que un cliente tenga más de una factura, estaremos repitiendo la dirección y el teléfono para cada una de las facturas. Esto se denomina redundancia de datos y produce tres efectos negativos:

1. Mayor ocupación en disco de los datos: el mismo dato se repite N veces.
2. Posibles inconsistencias de datos: es posible que en una factura el teléfono sea 555-111111 y en otra 555- 111112 (¿cuál de las dos es la correcta?)
3. Problemas a la hora de cambiar datos repetidos: si un cliente cambia de dirección tenemos que modificar todas sus facturas para cambiarle el dato.

 Hay casos muy especiales en los que la redundancia de datos se recomienda por razones 
 de rendimiento, aunque esta es la excepción que confirma la regla.

La solución que da la primera forma normal a este problema es poner los datos en tablas separadas, dependiendo del origen de la información: la información perteneciente a factura irá en la tabla FACTURA y la información perteneciente a clientes irá en la tabla CLIENTE. Podemos encontrarnos con el problema que los clientes de países distintos tiene una codificación independiente, es decir, que pude existir el cliente 1 de España y el cliente 1 de Francia a la vez.

Un diseño que cumpla la primera forma normal podría ser:

 Tan sólo se almacena el código del cliente para cada una de sus facturas, 
 y cuando se tenga que modificar la dirección, se modificará para todas las facturas 
 de ese cliente. Con esto ya hemos hecho que se cumpla la 3ª forma normal.

Y para la tabla CLIENTE hemos tenido que añadir una nueva columna (Código) que sirva para identificar a cada cliente con un código. Dado que es posible que exista el mismo código de cliente varias veces (una vez por cada país), la columna País se ha tenido que incluir dentro de la clave primaria.

La segunda forma normal nos dice que hay que sacar las columnas descriptivas que pertenezcan a la clave a otra tabla. La primera forma normal no nos dice que la tabla CLIENTE está mal definida, ya que todos los campos son datos relacionados con el cliente. Pero vemos que el País se repetirá varias veces, volviendo a caer en el error de la redundancia. Para ello hay que crear una tabla aparte en la que se incluya el código y la descripción del país, así a la hora de almacenar el país en la tabla CLIENTE, sólo se almacenará un código y no su descripción completa que ocupa mucho más espacio. Además a la hora de modificar una descripción, sólo habrá que modificarla una vez.

El esquema en segunda forma normal quedaría así:

 En este punto, aunque sólo hayamos aplicado la primera y segunda forma normal,
 ya tenemos la base de datos normalizada, ya que la tercera forma normal, 
 se cumple en todas las tablas.

Una forma de abreviar las formas normales es aplicando directamente la tercera, ya que si un esquema de base de datos cumple la tercera forma normal, automáticamente está cumpliendo la primera y la segunda.

Se denomina relación a todo aquellos vínculos que establecen unas tablas con otras, debidos a la aplicación de las formas normales.

En el ejemplo anterior, hemos creado relaciones entre unas tablas y otras desde el momento en que se separan los datos en más de una tabla y se utiliza el código como enlace entre unas y otras. Una relación que hemos creado ha sido la que se establece entre la tabla CLIENTE y la tabla PAIS. Ambas tablas están “intercomunicadas” por una de sus columnas: Cód Pais para CLIENTE y Código para PAIS. Con esta relación sabemos que todo campo Cód País de la tabla CLIENTE, tiene un registro equivalente en la tabla PAIS.

La relación 1-1 se establece cuando un registro de la tabla A tiene un solo registro relacionado en la tabla B. Esta relación se podría establecer por ejemplo si creamos una tabla de Pagos de facturas. Suponiendo que una factura se paga de una sola vez, podemos definir la siguiente tabla para almacenar cuando se pagan las facturas:

Podemos ver que la clave de esta tabla sólo es la referencia de la factura. Esto es el dato relevante que nos dice que la relación establecida entre una tabla y otra es 1-1. En la tabla PAGOS_FACTURA sólo puede aparecer una vez cada referencia. Y el la tabla FACTURA sólo puede aparecer una vez cada referencia.

Desde el punto de vista conceptual, las relaciones 1-1 son necesarias y convenientes, para que se cumpla la tercera forma normal y que en cada tabla sólo aparezcan datos correspondientes a su nivel lógico. Sin embargo, desde el punto de vista productivo y práctico, una relación 1-1 se puede sustituir por más registros en la tabla principal. Ya que un registro de A solo puede tener un registro en B, entonces las columnas de B pueden entrar a formas parte de A.

En un análisis más práctico que exhaustivo podríamos haber definido facturas de la siguiente manera:

Una relación 1-N es más común que 1-1, ya que, tanto desde el punto de vista conceptual, como desde el práctico, es necesario hacerlas. Volviendo al caso de los pagos de las facturas, podemos permitir que una factura se pague fraccionada, por ejemplo a 30, 60 y 90 días. Para este caso necesitamos que una referencia aparezca más de una vez en la tabla de PAGOS, por lo que la clave primaria debe ser cambiada.

Si la definición de la tabla para una relación 1-N hubiese sido la siguiente:

Entonces una referencia puede aparecer N veces, una por fecha distinta introducida. Así podemos pagar una factura en las siguientes fracciones.

Si la clave se hubiese definido sólo como “Referencia”, no podríamos haber insertado más de una fecha para la misma referencia. Sin embargo al definirla como “Referencia, Fecha”, podemos introducir tantas parejas Referencia-Fecha como queramos. En nuestro ejemplo se ha pagado una factura fraccionada en tres pagos con un mes de diferencia entre ellos.

 Las relaciones 1-N también son llamadas normalmente maestro-detalle,  
 donde el maestro es la tabla A (el 1 en la relación) y el detalle es 
 la tabla B (el N en la relación).
 En nuestro ejemplo FACTURA es el maestro y PAGOS_FRACCIONADOS_FACTURA un detalle de FACTURA.

Como norma general (lógicamente tiene sus excepciones) podemos decir que las columnas de la clave primaria de una tabla detalle tienen que ser las mismas que su maestro, añadiendo una (o varias) columnas a la clave (que marcan la diferencia entre el maestro y el detalle).

Esta norma se cumple para nuestro ejemplo.

 Las relaciones 1-N pueden ser optativas u obligatorias en ambos sentidos. 
 Es decir, la tabla A puede estar obligada (o no) a tener registros  relacionados en 
 la tabla B, La tabla B puede estar obligada (o no) a tener registros relacionados en la tabla A.

Una relación típica maestro-detalle, es optativa en sentido A-B pero obligatoria en sentido B-A. Significa que un maestro puede tener o no tener detalles, pero el detalle tiene que tener maestro obligatoriamente.

El concepto de relación es muy común dentro de las bases de datos y está presente continuamente. Es preciso que se maneje con soltura a la hora de definir las claves primarias para cada una de las tablas.

 Una  vez  establecidas  las  relaciones  entre  las  tablas,  debemos  estar  seguros  
 de  que  éstas  se  cumplen siempre.  En nuestro ejemplo anterior debemos de 
 asegurarnos de que si hay un registro en PAGOS_FRACCIONADOS_FACTURA, debe existir 
 la correspondiente factura, y que si ésta es borrada, se haga lo mismo con sus pagos.

Las bases de datos nos ofrecen esta posibilidad a través de las claves foráneas, que no son más que un tipo de clave (como la primaria) que hace referencia a otras tablas.

Así la tabla PAGOS_FRACCIONADOS_FACTURA debe definir una clave que compruebe que siempre que se inserte un pago, exista la factura correspondiente (en la tabla FACTURA).

Además la base de datos se encarga de que si queremos borrar una factura (en la tabla FACTURA) no nos deje si existen pagos o bien borre todos los pagos correspondientes.

Las claves foráneas deben crearse sobre las tablas “hijo”, o las tablas B en cada relación, normalmente en los detalles. En nuestro ejemplo de las tablas FACTURA, CLIENTE y PAIS se deben aplicar las siguientes claves foráneas (restricciones).

CLIENTE: Comprobar que no se puede dar de alta un cliente a un país que no exista. Además no se podrá borrar un país siempre que existan clientes dados a ese país. Clave foránea en CLIENTE( cod_pais ) hace referencia sobre PAIS( codigo ) FACTURA: Comprobar que no se puede dar de alta una factura a un cliente (país, cliente) que no exista. También se comprobará que no se pueda borrar un cliente que tenga facturas. Clave foránea en FACTURA(cod_pais,cod_cliente) hace referencia sobre CLIENTE(cod_pais,cod_cliente)

Se puede ver como la tabla PAIS no tiene ninguna clave foránea, ya que es “padre” o tabla A en todas las relaciones establecidas.

Como norma general, cada relación debe tener una clave foránea, y debe crearse sobre la tabla B de la relación que representa.

A la hora de definir una tabla hay que tener en cuenta ciertos aspectos en la codificación:

 A la hora de codificar columnas alfanuméricas, hay que tener en cuenta el sistema de ordenación: 
 Dada la siguiente lista de valores (de distinto tipo de dato):

La lista ordenada será la siguiente:

El orden, como vemos, difiere mucho uno de otro.

Sin embargo, dada la siguiente lista de valores (de distinto tipo de dato):

La lista ordenada será la siguiente:

La diferencia está en que el método alfanumérico ordena por posiciones, no por valores absolutos.

 Las descripciones deben ser lo suficientemente largas como para almacenar el 
 caso más desfavorable para la columna, aunque tampoco se deben crear columnas demasiado largas.

Por ejemplo: para albergar nombre y apellidos nos valdrá un 2 nombres de 10 caracteres cada uno, más dos apellidos de 15 caracteres cada uno. Total 35 caracteres. Para darnos un margen de error podemos poner 40 caracteres. Más de esta estimación será una longitud exagerada para el campo.

En bases de datos antiguas había una práctica muy común que consistía en utilizar una sola columna con varios, significados. El significado de la columna dependía de las posiciones de los dígitos.

Por ejemplo, se podría definir la siguiente regla para almacenar las referencias de las facturas:

Dígitos 1-2	Día de emisión
Dígitos 3-4	Mes de emisión
Dígitos 5-8	Año de emisión
Dígitos 9-14	Código de cliente
Dígitos 14-20	Número de factura

Así la referencia de la factura número 1, emitida a 23/8/1999, para el cliente código 567 sería: 23081999000567000001

Esto no tiene ningún sentido, ya que queda mucho más claro separar cada valor a su columna correspondiente, y si es necesario, definir todas las columnas necesarias como clave.

Fecha	   Cliente	Número
  23/8/1999	567	1

El origen de esta práctica viene de la época de las bases de datos jerárquicas en las que la clave sólo podía estar formada por un campo. Entonces era la única manera de definir una clave compuesta.

Cuando un equipo de desarrollo da los primeros pasos en un proyecto informático (de bases de datos o de cualquier otro tipo), lo primero que se debe definir es qué estándar de nomenclatura de objetos se va a utilizar. El objetivo principal de esta tarea es que el esquema sea consistente y homogéneo, además de permitir una memorización más rápida de los objetos.

El estándar debe responder a las siguientes preguntas:

• ¿Los nombres de objetos van en mayúsculas o minúsculas?
• ¿Debo utilizar nombres lo más descriptivos posibles o sin embargo nombres muy cortos?
• ¿Puedo usar abreviaturas?
• ¿Los nombres deben ir en singular o en plural?

El estándar debe ser un documento que tengan presente en todo momento el equipo de desarrollo, y siempre debe aplicarse salvo contadas excepciones.

A continuación daremos ciertas normas, que aunque no pretenden ser un estándar, si que son de recomendado uso:

 Los nombres de objetos (tablas, índices, claves primarias, claves foráneas…) 
 deben ir en  mayúscula. Oracle interpreta por defecto todos los objetos en mayúscula 
 a no ser que se escriba su nombre entre comillas dobles:

 Los nombres de objetos deben ir en singular ya que el nombre representa a 
 la entidad que almacena, y no las entidades que almacena. 
 Una razón práctica es que con los nombres en minúscula se ahorra 
 1 ó 2 letras, lo cual no es despreciable.

 Los nombres a utilizar deben ser descriptivos, aunque no deben ser demasiado 
 largos. Oracle admite hasta un máximo de 30 caracteres para los identificadores, 
 aunque no es recomendable llegar hasta el límite.

 Es  recomendable  utilizar  abreviaturas,  sobre  todo  si  el  nombre  más  
 descriptivo  es  demasiado  largo.  Para nombres cortos no es necesario utilizar abreviaturas.

 A la hora de nombrar tablas relacionadas entre si, es recomendable que el nombre 
 empiece por el sufijo que representa la entidad principal.

 Se pueden establecer ciertas abreviaturas para los nombres de columnas:

 Los nombres de clave primaria deben ir precedidos del prefijo PK_ (Primary key), 
 los de índices por IND_, y los de clave foránea por FK_ (Foreing key).

El nombre restante será el de la propia tabla para las claves primarias, el de la tabla referenciada para las claves foráneas y para los índices una o dos palabras descriptivas que indiquen la razón por la que se crea ese índice (si es posible).

 Los tipos de datos soportados por Oracle se agrupan en los siguientes conjuntos.

Los valores alfanuméricos van encerrados entre comilla simple: 'Alfanumérico' Los valores numéricos son número simples: 123 Las fechas van encerradas entre comillas simples: '1/12/2000' Los valores binarios no pueden ser representados (son fotos, videos…)

Almacena cadenas de caracteres de longitud fija, desde 1 a 2.000 bytes de ocupación. El número de caracteres que se pueden almacenar se rige según la siguiente fórmula.

nº caracteres = bytes / character set

Para ASCII, el conjunto de caracteres ocupa un byte, por lo que coincide el número de caracteres máximos con la ocupación del tipo de dato. Si se introduce un valor de 10 caracteres en un campo de CHAR(100), se tendra que rellenar con 90 posiciones restantes.

Así la siguiente expresión es cierta: 'Hola pepe' = 'Hola pepe '

Si se intenta introducir un valor demasiado grande para el campo, se intentará eliminar los espacios finales, y si cabe sin espacios, se introduce. Si aún así no cabe, se retorna un error.

Almacena cadenas de caracteres de longitud variable. Si se define una columna de longitud 100 bytes, y se introduce en ella un valor de 10 bytes, la columna ocupará 10 y no 100 como hacía con el tipo de dato CHAR.

En Oracle es equivalente a VARCHAR2, en futuras versiones permitirá distintos criterios de comparación.

Almacena un valor alfanumérico de longitud fija con posibilidad de cambio de juego de caracteres. Puede almacenar tanto caracteres ASCII, EBCDIC, UNICODE…

Almacena un valor alfanumérico de longitud variable con posibilidad de cambio de juego de caracteres. Puede almacenar tanto caracteres ASCII, EBCDIC, UNICODE…

Almacena valores numéricos en punto flotante que pueden ir desde 1.0 x 10-130 hasta 9.9…(38 nueves)… 9 x 10125 . El almacenamiento interno de los valores numéricos en notación científica:

 Mantisa x 10exponente

La mantisa puede contener cualquier número, entero o decimal, positivo o negativo. El exponente podrá contener cualquier número entero, positivo o negativo. El parámetro p indica la precisión (número de dígitos contando los decimales) que contendrá el número como máximo. Oracle garantiza los datos con precisiones de 1 a 38. El parámetro s indica la escala, esto es, el máximo de dígitos decimales. Hay que tener en cuenta que una columna definida NUMBER(10,5), podrá contener como máximo cualquier número siempre y cuando el número de dígitos enteros más el número de dígitos decimales no supere 10 (y no 15). La escala puede ir de -84 a 127. Para definir número enteros, se puede omitir el parámetro s o bien poner un 0 en su lugar. Se puede especificar una escala negativa, esto lo que hace es redondear el número indicado a las posiciones indicadas en la escala. Por ejemplo un número definido como NUMBER(5,-2), redondeará siempre a centenas. Así si intentamos introducir el valor 1355, en realidad se almacenará 1400.

Almacena un número en punto decimal sin restricción de dígitos decimales.

El parámetro b indica la precisión binaria máxima que puede moverse en el rango 1 a 126. Si se omite el defecto será 126. Una columna FLOAT(126) es equivalente a una columna NUMBER(38), aunque la diferencia está en que la columna NUMBER no podrá contener decimales y la columna FLOAT si y con cualquier escala.

Almacena un valor de fecha y hora.

Para un tipo de dato DATE, Oracle almacena internamente los siguiente datos:

• Siglo
• Año
• Mes
• Día
• Hora
• Minuto
• Segundo

El formato por defecto de las fechas es: 'DD-MON-YYYY' Esto es:

Dos dígitos para el día Las tres primeras siglas del mes (depende del idioma instalado). Cuatro dígitos para el año.

Por ejemplo:

'1-JAN-2001' '2-DEC-1943'

Este formato puede ser alterado en cualquier momento.

Internamente una fecha se almacena como el número de días desde cierto punto de inicio (por ejemplo el año 0). Esto permite que las fechas puedan ser tratadas en operaciones aritméticas normales:

'1-JAN-2001' + 10 = '11-JAN-2001' '1-JAN-2000' - 1 = '31-DEC-1999' '10-MAY-2000' - '1-MAY-2000' = 9

Permiten almacenar información en formato “crudo”, valores binarios tal y como se almacenan en el disco duro o como residen en memoria. Estas columnas se pueden utilizar tanto para almacenar grandes cantidades de datos (hasta 4Gb.), como para almacenar directamente cualquier tipo de fichero (ejecutables, sonidos, videos, fotos, documentos Word, DLLs…) o para transportar datos de una base de datos a otra, ya que el formato binario es el único formato común entre cualquier sistema informático.

Almacena caracteres de longitud variable hasta 2 Gb. Este tipo de dato se soporta para compatibilidad con versiones anteriores. En Oracle y siguientes versiones se debe usar los tipos de datos CLOB y NLOB para almacenar grandes cantidades de datos alfanuméricos.

Representa una dirección de la base de datos, ocupada por una única fila. El ROWID de una fila es un identificador único para una fila dentro de una base de datos. No hay dos filas con el mismo ROWID. Este tipo de dato sirve para guardar punteros a filas concretas.

SQL es un conjunto de sentencias u órdenes que todos los programas y usuarios deben utilizar para acceder a bases de datos Oracle. No hay otra manera de comunicarse con Oracle si no es a través de SQL. Dado que SQL es un estándar, todas las bases de datos comerciales de la actualidad utilizan SQL como puente de comunicación entre la base de datos y el usuario.

SQL nació como a partir de una publicación de 1970 escrita por E.F. Cood, y titulada “A relational model of data for large shared data banks” (El modelo de datos relacionales para grandes bancos de datos compartidos). IBM utilizó el modelo planteado por Codd para desarrollar un lenguaje capaz de soportar el recién nacido modelo relacional y así apareció SEQUEL (Structured English QUEry Language). SEQUEL más tarde se convirtió en SQL (Structured Query Language) que continuó pronunciándose en inglés como su predecesor: SEQUEL. En 1979, una desconocida empresa llamada Relational Software, sacó por sorpresa al mercado la primera implementación comercial de SQL. Relational Software más tarde pasó a llamarse Oracle. Después de 20 años, SQL todavía es (y será) siendo el estándar en lenguajes de acceso a base de datos relacionales.

En 1992, ANSI e ISO (organizaciones que se encargan de establecer estándares de todo tipo), completaron la estandarización de SQL y se definió un conjunto de sentencias básicas que debía tener toda implementación para ser llamada estándar. Este SQL se le denominó ANSI-SQL o SQL92.

Hoy en día todas las bases de datos comerciales cumplen el estándar ANSI, aunque cada fabricante añade sus mejoras al lenguaje SQL.

En realidad SQL no es un lenguaje en si, como podría ser un lenguaje de programación de 3ª generación (C, Pascal…), sino que en un sublenguaje orientado a acceso y manipulación de base de datos relacionales. Con SQL como única herramienta sólo podemos acceder a las bases de datos, pero no tenemos las estructuras típicas de un lenguaje de programación. Una buena analogía podría ser un sistema operativo. El interfaz de comandos de un SO nos da todo lo que necesitamos para acceder al sistema de ficheros, pero sólo podemos hacer eso, acceder a ficheros. SQL actúa de la misma manera, nos da todo lo que necesitamos para acceder a bases de datos, pero no podemos hacer más.

 Se dice que SQL es estructurado porque trabaja con conjuntos de resultados (result set) 
 abstractos como unidades completas.

Un conjunto de resultados es el esquema básico de una tabla: N filas x N columnas. Este esquema se trata como un todo y es la idea principal de SQL. A la hora de recuperar un conjunto de resultados, éste se trata de la misma forma tenga el número de filas que tenga (0-N) y tenga el número de columnas que tenga (1-N). Además SQL es consistente, esto significa que los “estilos” de las distintas sentencias son uniformes, por lo que el aprendizaje es rápido.

Ya hemos visto anteriormente qué tipos de datos se pueden utilizar en Oracle. Y siempre que haya datos, habrá operaciones entre ellos, así que ahora se describirán qué operaciones y con qué operadores se realizan:

Los operadores se pueden dividir en dos conjuntos:

 Aritméticos: utilizan valores numéricos
 Lógicos (o booleanos o de comparación): utilizan valores booleanos o lógicos.
 Concatenación: para unir cadenas de caracteres.

Operadores aritméticos:

Retornan un valor numérico

Operadores lógicos:

Retornan un valor lógico (verdadero o falso)

Existen los siguientes comodines:

%: Conjunto de N caracteres (de 0 a ) _: Un solo carácter

Ejemplo:

Las siguientes condiciones retornan TRUE

'significado LIKE 's_gn%fi%d_'
'pepe' LIKE 'pep%'	(todos los que empiecen por 'pep')
'pepote' LIKE 'pep%'
'pepote' LIKE 'pe%te'	(todos los que empiecen por 'pe' y terminen por 'te')
'pedrote' LIKE 'pe%te'

Operador de concatenación:

Retornan una cadena de caracteres

Oracle puede hacer una conversión automática cuando se utilice este operador con valores numéricos:

10 || 20 = '1020'

Este proceso de denomina CASTING y se puede aplicar en todos aquellos casos en que se utiliza valores numéricos en puesto de valores alfanuméricos o incluso viceversa.

Todo valor (sea del tipo que sea) puede contener el valor NULL que no es más que la ausencia de valor. Así que cualquier columna (NUMBER, VARCHAR2, DATE…) puede estar a NULL. Una operación retorna NULL si cualquiera de los operandos es NULL. Para comprobar si una valor es NULL se utiliza el operador IS NULL o IS NOT NULL.

 El DML (Data Manipulation Language) es el conjunto de sentencias que está orientadas 
 a la consulta, y manejo de datos de los objetos creados.
 El DML es un subconjunto muy pequeño dentro de SQL, pero es el más importante, ya 
 que su conocimiento y manejo con soltura es imprescindible.

 Básicamente consta de cuatro sentencias: SELECT, INSERT, DELETE, UPDATE.

La sentencia SELECT es la encargada de la recuperación (selección) de datos, con cualquier tipo de condición, agrupación u ordenación. Una sentencia SELECT retorna un result set (conjunto de resultados), por lo que podrá ser aplicada en cualquier lugar donde se espere un result set.

La sintaxis básica es:

  SELECT columnas 
    FROM tablas 
   WHERE condición
GROUP BY agrupación
  HAVING condición agrupada
ORDER BY ordenación;

Todas las cláusulas son opcionales excepto SELECT y FROM.

A continuación vamos a hacer una descripción breve de cada cláusula:

SELECT: se deben indicar las columnas que se desean mostrar en el resultado. Las distintas columnas deben aparecer separadas por coma (”,”). Opcionalmente puede ser cualificadas con el nombre de su tabla utilizando la sintaxis:

TABLA.COLUMNA

Si se quieren introducir todas las columnas se podrá incluir el carácter *, o bien TABLA.* Existe la posibilidad de sustituir los nombres de columnas por constantes (1, 'pepe' o '1-may-2000'), expresiones, pseudocolumnas o funciones SQL.

A toda columna, constante, pseudocolumna o función SQL, se le puede cualificar con un nombre adicional:

COLUMNA NOMBRE
CONSTANTE NOMBRE 
PSEUDOCOLUMNA 
NOMBRE FUNCION SQL 
NOMBRE

Si se incluye la cláusula DISTINCT después de SELECT, se suprimirán aquellas filas del resultado que tenga igual valor que otras.

Así

SELECT C_CLIENTE FROM FACTURA; 

Puede retornar

1
3
5
5
1
7
3
2
9



Sin embargo:

SELECT DISTINCT C_CLIENTE FROM ACTURA; Retornará (suprimiendo las repeticiones)

1
3
5
7
2
9

Ejemplos:

SELECT REFERENCIA REF, DESCRIPCION SELECT FACTURA.REFERENCIA, DESCRIPCION SELECT *
SELECT FACTURA.*
SELECT 1 UN_NUMERO_CTE_CUALIFICADO, REFERENCIA SELECT 1+1-3*5/5.4 UNA_EXPRESION_SIN_CUALIFICADA
SELECT DESCRIPCION, ROWNUM UNA_PSEUDOCOLUMNA_CUALIFICADA
SELECT TRUNC( '1-JAN-2001'+1, 'MON' ) UNA_FUNCION_CUALIFICADA SELECT DISTINCT *
SELECT DISTINCT DESCRIPCION, IMPORTE SELECT REFERENCIA||DESCRIPCION

FROM: se indican el(los) result set(s) que interviene(n) en la consulta. Normalmente se utilizan tablas, pero se admite cualquier tipo result set (tabla, select, vista…). Si apareciese más de una tabla, deben ir separadas por coma. Las tablas deben existir y si no existiera alguna aparecería el siguiente error: ORA-00942: table or view does not exist Al igual que a las columnas, también se puede cualificar a las tablas TABLA NOMBRE Oracle tiene definida una tabla especial, llamada DUAL, que se utiliza para consultar valores que no dependen de ningún result set.

SELECT (1+1.1*3/5)-1-2 FROM DUAL;

Ejemplos:

FROM FACTURA FAC
FROM FACTURA FAC, CLIENTE CLI FROM DUAL
FROM ( SELECT C_CLIENTE FROM FACTURA ) CLIENTE_FAC

WHERE: indica qué condiciones debe cumplirse para que una fila entre dentro del result set retornado. Para construir las condiciones se podrán utilizar todos los operadores lógicos vistos anteriormente. Es posible construir condiciones complejas uniendo dos o más condiciones simples a través de los operadores lógicos AND y OR.

Ejemplos:

WHERE FACTURA.REFERENCIA = 'AA3455' 
WHERE FACTURA.C_CLIENTE IS NULL
WHERE C_CLIENTE BETWEEN '12' AND '20'
WHERE C_CLIENTE IS NULL AND REFERENCIA IN ('AA23344', 'BB23345')
WHERE C_CLIENTE != 55 OR REFERENCIA LIKE 'AA%5_'

GROUP BY: La expresión GROUP BY se utiliza para agrupar valores que es necesario procesar como un grupo. Por ejemplo, puede darse el caso de necesitar procesar todas las facturas de cada cliente para ver su total, o para contarlas, o para incrementarles un 10%… Para estos casos se haría un SELECT agrupando por C_CLIENTE. Un SELECT con GROUP BY es equivalente a un SELECT DISTINCT, siempre y cuando en el SELECT no aparezcan consultas sumarias (ver apartado Funciones SQL). Trataremos con más profundidad este tipo de consultas en el apartado “Consultas agrupadas”.

HAVING: Se utiliza para aplicar condiciones sobre agrupaciones. Sólo puede aparecer si se ha incluido la cláusula GROUP BY. Trataremos con más profundidad este tipo de consultas en el apartado “Consultas agrupadas”.

ORDER BY: Se utiliza para ordenar las filas del result set final.

Dentro de esta cláusula podrá aparecer cualquier expresión que pueda aparecer en el SELECT, es decir, pueden aparecer columnas, pseudocolumnas, constantes (no tiene sentido, aunque está permitido), expresiones y funciones SQL. Como característica adicional, se pueden incluir números en la ordenación, que serán sustituidos por la columna correspondiente del SELECT en el orden que indique el número.

La ordenación es el último paso en la ejecución de una consulta SQL, y para ello Oracle suele necesitar crear objetos temporales que son creados en el tablespace Temporal. Por eso es recomendable hacer las ordenaciones del lado de cliente (siempre que sea posible), ya que el servidor puede cargarse bastante si tiene que hacer, por ejemplo, 300 ordenaciones de tablas de 2 millones de registros.

Después de cada columna de ordenación se puede incluir una de las palabras reservadas ASC o DESC, para hacer ordenaciones ASCendentes o DESCendentes. Por defecto, si no se pone nada se hará ASC.

Ejemplos:

ORDER BY REFERENCIA ASC
ORDER BY REFERENCIA DESC, C_CLIENTE DES, IMPORTE ASC 
ORDER BY C_CLIENTE
ORDER BY 1, C_CLIENTE, 2
ORDER BY TRUNC( '1-JAN-2001'+1, 'MON' )
ORDER BY 1.1+3-5/44.3 -- no tiene sentido ordenar por una cte.

 Una consulta agrupada se utiliza para considerar los registros cuyos ciertos 
 campos tienen el mismo valor, y procesarlos de la misma manera, 
 para contarlos, sumarlos, hacer la media…

Las consultas típicas son para contar los registros de cierto tipos, sumar los importes de cierto cliente, etc. Por ejemplo, vamos a sacar el total del importe de las factura, por cliente:

SELECT C_CLIENTE, SUM(IMPORTE)
FROM	FACTURA
GROUP BY C_CLIENTE;

Esto nos sumará (la función SUM suma su parámetro) los registro agrupando por cliente. Internamente Oracle tiene que hacer una ordenación interna de los registros, según las columnas incluidas en el GROUP BY, así que todo lo dicho para el ORDER BY se puede aplicar para el GROUP BY (sobrecarga del servidor).

Cuando en la cláusula SELECT no se incluyen funciones SQL (para más información ver el apartado Funciones SQL), una consulta GROUP BY es equivalente a una consulta SELECT DISTINCT.

Un error muy común cuando se construyen consultas agrupadas, es el siguiente:

ORA-00979: not a GROUP BY expression

Esto es debido al modo que tiene Oracle de analizar las consultas agrupadas: Lo que hace es comprobar que todos las columnas incluidos en la cláusula SELECT fuera de funciones sumarias, estén dentro de la cláusula GROUP BY, aunque pueden estar en cualquier orden y en el GROUP BY pueden aparecer columnas que no estén en el SELECT. Si encuentra alguna columna en el SELECT (que no esté dentro de una función sumaria) que no aparezca en el GROUP BY, entonces nos retorna el error anterior. Si pensamos la situación, es lógico que nos retorne un error, porque no podemos agrupar por la columna C_CLIENTE, si luego queremos mostrar otras columnas que estén sin agrupar. O agrupamos por todo, o mostramos sin agrupar, pero ambas a la vez no es posible.

Ejemplos de consultas agrupadas:

SELECT C_CLIENTE, SUM( IMPORTE )
FROM FACTURA
GROUP BY C_CLIENTE;
 
SELECT C_PAIS, SUM( IMPORTE ) FROM FACTURA
GROUP BY C_PAIS;
 
SELECT C_CLIENTE, COUNT(*) FROM FACTURA
GROUP BY C_CLIENTE;
 
SELECT C_CLIENTE, SUM(1) FROM FACTURA
GROUP BY C_CLIENTE;
 
SELECT C_PAIS, AVG( IMPORTE ) FROM FACTURA
GROUP BY C_PAIS;
 
SELECT C_PAIS, COUNT(*) FROM	CLIENTE
GROUP BY C_PAIS,
 
SELECT C_CLIENTE + AVG( IMPORTE ) FROM	FACTURA;

 Es posible que para consultas sencillas, todos los datos que necesitemos estén en 
 una sola tabla. Pero… ¿y si están repartidos por una, dos o muchas tablas?

Es posible hacer consultas que incluyan más de una tabla (o result set) dentro de la cláusula FROM, como ya vimos anteriormente. Pero en estas consultas hay que tener en cuenta ciertos factores.

Vemos lo que hace Oracle para esta consulta:

SELECT F.REFERENCIA, F.C_CLIENTE, C.C_CLIENTE, C.D_CLIENTE
FROM  FACTURA F, CLIENTE C;

Suponiendo que tenemos los siguientes datos:

El select anterior nos retornará el siguiente result set

Podemos ver que el resultado es el producto cartesiano de una tabla por otra tabla, es decir, todas las combinaciones posibles de la tabla FACTURA con la tabla CLIENTE. Pero en realidad lo que a nosotros nos interesa es mostrar todas las facturas, pero con la descripción del cliente de cada factura, es decir, que cada factura seleccione sólo su registro correspondiente de la tabla CLIENTE. Los registros que a nosotros nos interesan están marcados en negrita en el esquema anterior, y en todos ellos se cumple que F.C_CLIENTE = C.C_CLIENTE. O dicho de otro modo, los campos que componen la relación igualados. Entonces del result set anterior, sólo nos interesan los registros marcados en negrita, y el select que nos retorna ese resultados es:

SELECT F.REFERENCIA, F.C_CLIENTE, C.C_CLIENTE, C.D_CLIENTE
FROM  FACTURA F, CLIENTE C
WHERE F.C_CLIENTE = C.C_CLIENTE;

El resultado final es:

Esto son con la descripción del cliente.

Como norma general se puede decir que para combinar dos o más tablas hay que poner como condición la igualdad entre las claves de una tabla y el enlace de la otra. Las condiciones dentro del WHERE que sirven para hacer el enlace entre tablas se denominan JOIN (unión, enlace).

Nota: en el ejemplo utilizado hemos omitido por simplicidad la columna C_PAIS que también forma parte de la clave, así que el join debería hacerse con las columnas C_PAIS y C_CLIENTE.

Existe un caso especial cuando se establece un “join” entre tablas: el outer-join. Este caso se da cuando los valores de los campos enlazados en alguna de las tablas, contiene el valor NULL.

Al realizar un join, si algún campo enlazado contiene el valor NULL, es registro quedará automáticamente excluído, ya que una condición en la que un operando sea NULL siempre se evalúa como falso.

Supongamos que las tablas utilizadas en el ejemplo anterior ahora tienen los siguientes datos:

Si realizamos la misma consulta (las facturas con la descripción de cliente), no aparecerán las facturas “A112” y “A114”, ya que su campo C_CLIENTE contiene un NULL, y al evaluar la condición de join (WHERE FACTURA.C_CLIENTE = CLIENTE.C_CLIENTE), no se evaluará como verdadero. Además, tampoco aparecerá la factura “A115”, porque el cliente “7” no existe en la tabla de clientes.

Sin embargo, puede ser que necesitemos mostrar todas las facturas de la base de datos, independientemente de si el cliente existe o si el campo está a NULL.

Para ello debemos utilizar un outer-join, que no es más que un JOIN con un modificador (+), indicando que queremos considerar aquellos registros que se descarten por existencia de nulos.

El select final sería así

SELECT F.REFERENCIA, F.C_CLIENTE, C.C_CLIENTE, C.D_CLIENTE
FROM  FACTURA F, CLIENTE C
WHERE F.C_CLIENTE = C.C_CLIENTE(+);

El resultado de ejecutar este select es:

Esta consulta podría leerse con el siguiente enunciado:

“Selecionar las facturas que tengan cliente (el join) y aquellas que no encuentren su referencia en la tabla cliente (en outer-join)”.

Es importante fijarse en la posición en que se ha colocado el modificador (+). Si se sitúa detrás del campo de la tabla cliente, significa que se recuperen las todas las facturas, aunque no encuentren referencia al cliente, sin embargo, si lo ponemos detrás del campo de la tabla factura:

SELECT F.REFERENCIA, F.C_CLIENTE, C.C_CLIENTE, C.D_CLIENTE
FROM  FACTURA F, CLIENTE C
WHERE F.C_CLIENTE(+) = C.C_CLIENTE;

Significaría que recupere todos los clientes, aunque no encuentre la referencia de la factura.

Sólo queda por comentar que si en join entre las tablas es de varios campos, debe indicarse el símbolo del outer (+) en todos los campos, y en la misma posición en todos ellos.

Una pseudocolumna es una columna válida para poner en cualquier cláusula SELECT, independientemente de las tablas incluidas en la clausula FROM.

Las pseudocolumnas válidas para Oracle son:

CURRVAL y NEXTVAL: sólo válidas si el objeto del FROM es una secuencia. Permiten recuperar el valor actual y siguiente (respectivamente) de una secuencia. Para más información sobre las secuencias ir a al apartado CREATE SEQUENCE.

LEVEL: Retorna el nivel para consultas jerárquicas. Las consultas jerárquicas se realizan utilizando las cláusulas START WITH y CONNECT BY de la sentencia SELECT. Para más información sobre consultas jerárquicas, dirigirse a la ayuda se la sentencia SELECT en el Oracle SQL Reference.

ROWID: Retorna una dirección de disco donde se encuentra la fila seleccionada. Es un valor único para cada fila de la base de datos.

ROWNUM: Es un valor consecutivo para cada fila retornada por una consulta. La primera fila tendrá un 1, la segunda un 2, etc. Se suele utilizar para restringir el tamaño del result set, por ejemplo, si queremos que sólo retorne las 5 primeras facturas:

SELECT *
FROM FACTURA
WHERE ROWNUM <= 5;

Hay que tener en cuenta que una consulta de este estilo:

SELECT *
FROM FACTURA
WHERE ROWNUM > 1;

Nunca retornará resultado, porque siempre habrá una fila que sea la primera. Después de que el WHERE elimine la primera fila, el ROWNUM de todas las filas restantes de recalculará y volverá a haber otra nueva primera fila. Así se seguirá aplicando la condición de filtro hasta que no queden filas. Por eso no retorna ninguna fila. El valor de ROWNUM se aplica antes de que se ordene el result set

SYSDATE: Nos retorna un tipo de dato DATE con la fecha y hora del sistema (según el reloj del servidor de base de datos).

USER, UID: Nos retorna el nombre e identificador de usuarios de la sesión activa.

La sentencia INSERT nos permite introducir nuevas filas en una tabla de base de datos. La sintaxis básica es:

INSERT INTO tabla{( campos )} VALUES( lista de valores );

Los nombres de los campos detrás del nombre de tabla son opcionales y si no se ponen se supondrá todos los campos de la tabla en su orden original. Si se ponen, se podrán indicar cualquier número de columnas en cualquier orden.

La lista de valores es el registro que se insertará en la tabla. Los tipos de datos deben coincidir con la definición dada en la cláusula INTO o con la definición de la tabla si omitimos dicha cláusula. Las columnas que no se incluyan en el INTO, de inicializarán con NULL, (si no se ha definido valor en el DEFAULT).

Existe otra sintaxis que se denomina INSERT masivo:

INSERT INTO tabla{( campos )} SELECT . . .

Este tipo de INSERT permite introducir un gran número de registros en una sola sentencia. Al igual que con el INSERT normal, los tipos de datos del SELECT deben coincidir con la definición de la cláusula INTO.

Ejemplos:

INSERT INTO FACTURA
VALUES( 'A111', 'Factura nueva', 1, 5, 50000 );
 
INSERT INTO FACTURA( C_PAIS, REFERENCIA, IMPORTE, C_CLIENTE, DESCRIPCIPCION ) 
VALUES( 1, 'A111', 50000, 5, 'Factura nueva' );
 
INSERT INTO FACTURA( REFERENCIA, IMPORTE ) VALUES( 'A111', 50000 );
 
INSERT INTO FACTURA( C_PAIS, C_CLIENTE ) SELECT C_PAIS, C_CLIENTE
FROM CLIENTE;

La sentencia DELETE nos permite eliminar filas en una tabla de base de datos conforme a una condición. Es equivalente al SELECT, pero en vez de mostrar las filas que cumplan la condición, las elimina.

Su sintaxis es:

DELETE {FROM} tabla {WHERE condición};

Si se omite la cláusula WHERE se borrarán todas las filas de la tabla. Las condiciones pueden ser las mismas que las aplicadas en una sentencia SELECT.

En la cláusula FROM no puede haber más de una tabla, por lo que no es posible hacer joins en un DELETE. Para hacer un “pseudojoin” hay que utilizar el operador IN comparando los campos clave de la tabla a borrar con el subselect de la tabla con la que se quiere hacer el join.

Ejemplos:

DELETE FROM FACTURA WHERE REFERENCIA = 'A111'; DELETE FACTURA;
 
DELETE FACTURA WHERE C_PAIS = 1 AND C_CLIENTE = 5;
 
DELETE FROM FACTURA WHERE REFERENCIA NOT IN ( SELECT REFERENCIA 
                                                FROM FACTURA
                     WHERE C_CLIENTE = 4 );
 
DELETE FROM FACTURA WHERE C_CLIENTE != 4;
 
DELETE FROM FACTURA WHERE (C_PAIS,C_CLIENTE) IN ( SELECT C_PAIS, C_CLIENTE 
                                                    FROM CLIENTE
         WHERE  D_CLIENTE LIKE '%Fernández%' );
 
 
DELETE FROM FACTURA
WHERE (C_PAIS,C_CLIENTE) IN ( SELECT C_PAIS, C_CLIENTE FROM CLIENTE
WHERE  CLIENTE.C_PAIS = FACTURA.C_PAIS 
  AND CLIENTE.C_CLIENTE = FACTURA.C_CLIENTE 
  AND D_CLIENTE LIKE '%Fernández%' );

La sentencia UPDATE se encarga de modificar registros ya existentes en una tabla. Es equivalente a la sentencia DELETE, pero en vez de borrar, actualiza las columnas indicadas que cumplan la condición impuesta.

Sintaxis:

UPDATE tabla
SET	campo = valor, campo = valor,
. . .
{WHERE condición};

El valor puede ser tanto un valor discreto (1, 'pepe', '1-jan-2000', etc), un valor dependiente de otra una columna (IMPORTE*10) o un subselect que retorne un result set de 1×1 (1 fila y 1 una columna). Si se utiliza un subselect se puede hacer join entre este subselect y la tabla del UPDATE.

Si se omite la cláusula WHERE, se actualizarán todas las filas de la tabla.

Ejemplos:

UPDATE FACTURA
SET	IMPORTE = 1000
WHERE	C_PAIS	= 1 
  AND  C_CLIENTE = 5;
 
UPDATE FACTURA
SET	IMPORTE = IMPORTE * 0.5
WHERE	C_PAIS	= 1 
  AND  C_CLIENTE = 5;
 
UPDATE FACTURA F1
SET	IMPORTE = ( SELECT AVG(IMPORTE) * 1.10
FROM  FACTURA F2
WHERE F1.C_PAIS	= F2.C_PAIS 
  AND F1.C_CLIENTE = F2.C_CLIENTE );
 
UPDATE FACTURA F1
SET    IMPORTE = ( SELECT AVG(F2.IMPORTE) + F1.IMPORTE FROM  FACTURA F2
WHERE F1.C_PAIS	= F2.C_PAIS 
  AND F1.C_CLIENTE = F2.C_CLIENTE );

El DDL (Data Definition Language) es el conjunto de sentencias que está orientadas a la creación, modificación y configuración de objetos en base de datos. El DDL es el subconjunto más extenso dentro de SQL así que sólo vamos a hacer una referencia rápida a algunas sentencias. Se puede encontrar una descripción detallada del todo el DDL dentro del Oracle SQL Reference.

Crea una tabla en base de datos. La sintaxis básica es:

CREATE TABLE nombre_tabla(
COLUMNA TIPO [NOT NULL],
COLUMNA TIPO [NOT NULL],
 
{CONSTRAINT nombre_clave_primaria PRIMARY KEY (columnas_clave)}
{CONSTRAINT nombre_clave_foránea
FOREIGN KEY(columnas_clave) REFERENCES tabla_detalle( columnas_clave )
{ON DELETE CASCADE} }  )
{TABLESPACE tablespace_de_creación}
{STORAGE( INITIAL XX{K|M} NEXT XX{K|M} )}

La creación de la tabla FACTURA definida en la página 6 sería la siguiente:

CREATE TABLE FACTURA(
REFERENCIA  NUMBER(30)	NOT NULL, DESCRIPCION VARCHAR2(50),
C_PAIS	NUMBER(3), C_CLIENTE	NUMBER(5), IMPORTE	NUMBER(12),
CONSTRAINT PK_FACTURA PRIMARY KEY( REFERENCIA )
CONSTRAINT FK_CLIENTE(C_PAIS,C_CLIENTE) REFERENCES CLIENTE( C_PAIS, C_CLIENTE) ON DELETE CASCADE
TABLESPACE tab_facturas
STORAGE( INITIAL 1M NEXT 500K );

Los campos que van a formar parte de la clave se tienen que definir como NOT NULL ya que no tiene sentido que éstas columnas carezcan de valor. Además se crea la clave primaria y la clave foránea que hace referencia a CLIENTE (como ya dijimos en el apartado de claves foráneas). Con la cláusula ON DELETE CASCADE hacemos que si se borra un cliente, se borren automáticamente todas sus facturas. Si no la incluyésemos, al borrar el cliente, nos daría el siguiente error:

ORA-02292: integrity constraint (FK_CLIENTE) violated - child record found

Hay que tener en cuenta que aunque la clave foránea se crea sobre la tabla FACTURA, también actúa cuando se hacen operaciones sobre CLIENTE.

Al intentar insertar una factura a un cliente inexistente nos dará el siguiente error:

ORA-02291: integrity constraint (FK_CLIENTE) violated - parent key not found

Se puede encontrar una descripción detallada de todos los errores en el Oracle Error Messages.

Crea un índice sobre una tabla de base de datos. La sintaxis básica es:

CREATE {UNIQUE} INDEX nombre_índice
ON tabla( columnas_indexadas )
{TABLESPACE tab_indices}
{STORAGE( INITIAL XX{K|M} NEXT XX{K|M} )}

La cláusula UNIQUE actúa como si los campos indexados fuesen clave primaria, es decir, no permite que el conjunto de campos indexados se repita en la tabla. Ya dijimos que un índice es como una tabla auxiliar que sólo contiene ciertas columnas de búsqueda. Por eso también es posible (y recomendable) indicar tanto el tablespace como las cláusula STORAGE para las características de almacenamiento de disco. Si no se incluyera, se utilizará el STORAGE indicado en la creación del tablespace sobre el que se crea el índice.

Así mismo Oracle recomienda que los índices residan en un tablespace separado al de las tablas. Esto es debido a la siguiente razón: Dos tablespaces distintos están soportados físicamente por al menos un datafile cada uno. Si nuestro servidor de base de datos tiene más de un disco duro (algo muy normal), es posible crear un tablespace con sus datafiles en un disco y otro tablespace con los datafiles en otro disco. Esto permite que se puedan hacer lecturas de disco simultáneamente sobre dos disco físicos, ya que cada disco tiene su propio bus de datos. Al meter los índices en un disco físico y los datos en otro, se facilita que se puedan hacer lecturas simultaneas. Este proceso (de poner los índices y datos en discos separados), se denomina balanceado.

Oracle crea automáticamente un índice cuando se define la clave primaria. Esto es porque la condición más habitual en una consulta a cualquier tabla es por los campos de su clave primaria. De esta forma se aceleran la gran mayoría de las consultas (recordar que un índice actúa del mismo modo que el de un libro).

Pero pueden darse casos en los que se hagan gran cantidad de consultas por campos distintos a los de la clave primaria. En este caso es necesario crear un índice por los campos por lo que se accede. Por ejemplo, puede ser que en nuestra tabla FACTURA sea muy común recuperar aquellas facturas de un cierto cliente. En este caso la consulta SELECT ha realizar sería la siguiente:

SELECT *
FROM FACTURA
WHERE C_PAIS = 1 AND C_CLIENTE = ‘A111’;

En este caso se está accediendo la tabla FACTURA por campos distintos a la clave primaria (que es Referencia). Si este tipo de consultas son muy habituales es necesario crear un índice por estos campos:

CREATE INDEX ind_factura_cliente
ON FACTURA( C_PAIS, C_CLIENTE ) TABLESPACE tab_factura_ind
STORAGE( INITIAL 500K NEXT 500K );

No podemos poner la cláusula UNIQUE porque si no, no podríamos insertar más de una factura por cliente.

Una vista (view) es una consulta SELECT almacenada en base de datos con un cierto nombre. Si tenemos la siguiente consulta:

SELECT C.D_CLIENTE, SUM( F.IMPORTE )
FROM	FACTURA F, CLIENTE C
WHERE  F.C_PAIS	= C.C_PAIS AND F.C_CLIENTE = C.C_CLIENTE
GROUP BY F.C_PAIS, F.C_CLIENTE, C.D_CLIENTE;

Si esta consulta es necesario ejecutarla muchas veces, entonces podemos guardar esta definición en base de datos con un nombre (crear una vista), y después hacer la consulta sobre la vista.

CREATE VIEW TOTAL_FACTURA_CLIENTE AS SELECT C.D_CLIENTE, SUM( F.IMPORTE ) FROM	FACTURA F, CLIENTE C
WHERE  F.C_PAIS	= C.C_PAIS AND F.C_CLIENTE = C.C_CLIENTE
GROUP BY F.C_PAIS, F.C_CLIENTE, C.D_CLIENTE;

Y después hacer la consulta sobre la vista:

SELECT *
FROM TOTAL_FACTURA_CLIENTE;

La sintaxis de creación de vista es:

CREATE {OR REPLACE} {FORCE} VIEW nombre_vista AS Subconsulta;

La cláusula OR REPLACE permite sobrescribir una definición existente con otra nueva definición. La cláusula FORCE permite crear una vista aunque las tablas de la subconsulta no existan.

Ejemplo:

CREATE OR REPLACE FORCE VIEW VISTA_INCORRECTA AS SELECT * FROM FACTURA_ADICIONAL;
 
CREATE OR REPLACE VIEW FACTURA_CLIENTE_A111 AS SELECT * FROM FACTURA
WHERE C_PAIS = 1 AND C_CLIENTE = ‘A111’;

Una secuencia (sequence) es un objeto de base de datos que genera números secuenciales. Se suele utilizar para asignar valores a campos autonuméricos.

En realidad una secuencia no es más que una tabla con una columna numérica en la que se almacena un valor. Cada vez que se consulta la secuencia se incrementa el número para la siguiente consulta.

Sintaxis:

CREATE SEQUENCE nombre_secuencia
{START WITH entero}
{INCREMENT BY entero}
{MAXVALUE entero | NOMAXVALUE}
{MINVALUE entero | NOMINVALUE }
{CYCLE | NOCYCLE};

• La cláusula START WITH define el valor desde el que empezará la generación de números. Si no se incluye, se empezará a partir de MINVALUE. • La cláusula INCREMENT BY indica la diferencia que habrá entre un número y el siguiente. Puede ser cualquier número entero (positivo o negativo) distinto de 0. • La cláusula MAXVALUE indica el valor máximo que podrá alcanzar la secuencia. Se podrá incluir la cláusula NOMAXVALUE para no definir máximo de 1027. • La cláusula MINVALUE indica el valor mínimo de la secuencia. Se podrá incluir la cláusula NOMINVALUE para definir un mínimo de –1026. La cláusula CYCLE permite que se empiece a contar en MINVALUE cuando se llegue a MAXVALUE. Por defecto las secuencias se crean NOCYCLE.

Ejemplos:

CREATE SEQUENCE REF_FACTURA START WITH 1
INCREMENT BY 1
MAXVALUE 999999
MINVALUE 1;
 
CREATE SEQUENCE COD_CLIENTE INCREMENT BY 10;
 
CREATE SEQUENCE COD_PAIS INCREMENT BY 10
CYCLE;

Acceso a secuencias:

Las secuencias al ser tablas se acceden a través de consultas SELECT. La única diferencia es que se utilizan pseudocolumnas para recuperar tanto el valor actual como el siguiente de la secuencia. Al ser pseudocolumnas se puede incluir en el FROM cualquier tabla o bien la tabla DUAL.

Nombre_secuencia.CURRVAL: retorna el valor actual de la secuencia. Nombre_secuencia.NEXTVAL: incrementa la secuencia y retorna el nuevo valor. Ejemplos:

CREATE SEQUENCE REF_FACTURA START WITH 1
INCREMENT BY 1
MAXVALUE 999999
MINVALUE 1;
 
CREATE SEQUENCE COD_CLIENTE INCREMENT BY 10;
 
CREATE SEQUENCE COD_PAIS INCREMENT BY 10
CYCLE;
 
 
SELECT REF_FACTURA.CURRVAL FROM DUAL;
 
SELECT COD_CLIENTE.NEXTVAL FROM DUAL;
 
SELECT COD_CLIENTE.NEXTVAL, D_CLIENTE FROM CLIENTE;
 
UPDATE CLIENTE
SET CODIGO = SECUENCIA_CLIENTE.NEXTVAL;
 
INSERT INTO CLIENTE
VALUES( SECUECIA_CLIENTE.NEXTVAL, ‘Juancito Pérez Pí’ );

Toda sentencia de creación CREATE tiene su equivalente para eliminar el objeto creado.

Todas estas sentencias tienen la misma sintaxis:

DROP tipo_objeto objeto_a_borrar.

Ejemplos:

DROP TABLE FACTURA;
 
DROP SEQUENCE COD_CLIENTE; 
DROP SYNONYM BILL;
DROP VIEW TOTAL_FACTURA_CLIENTE; DROP TABLESPACE tab_indices;

Ciertas sentencias DROP (como DROP TABLE o DROP TABLESPACE) tienen cláusulas adicionales para ciertas situaciones especiales. Para más información buscar la ayuda de la sentencia necesitada en el Oracle SQL Reference.

Al igual que existe una sentencia DROP para cada objeto creado, también existe una sentencia ALTER para cada objeto de base de datos. Con estos tres grupos de sentencias se hace la gestión completa de los objeto: creación, modificación y borrado.

La sintaxis básica de las sentencias ALTER es:

ALTER tipo_objeto nombre_objeto Cláusulas específicas de cada tipo de ALTER;

Las cláusulas propias de cada sentencia ALTER son muchas y variadas, por lo que aquí no se citarán más que ciertos ejemplos. Para más información dirigirse la ayuda de la sentencia necesitada en el Oracle SQL Reference.

Ejemplos:

ALTER TABLE FACTURA ADD(
NUEVA_COLUMNA  VARCHAR2(10) NOT NULL ); 
ALTER VIEW BILL COMPILE;
ALTER SEQUENCE NOCYCLE;

La sentencia TRUNCATE pertenece al conjunto de las sentencias DDL, y permite vaciar todos los registros de una tabla. Aparentemente es equivalente a hacer un DELETE sin condición, pero en realidad no es igual, ya que DELETE pertenece al subconjunto de DML y TRUNCATE al DDL.

La sintaxis básica es:

TRUNCATE nombre_tabla {DROP|REUSE STORAGE}

La cláusula DROP STORAGE eliminará todas las extents creadas durante la vida de la tabla.

Ejemplos:

TRUNCATE FACTURA DROP STORAGE; 
TRUNCATE CLIENTE;

Las funciones SQL permiten mostrar columnas calculadas dentro de sentencias DML (SELECT, INSERT, DELETE y UPDATE).

Función Descripción ADD_MONTHS( d, n ) Suma un número (positivo o negativo) de meses a una fecha. LAST_DAY( d ) Retorna el ultimo día de mes de la fecha pasada. MONTHS_BETWEEN( d1, d2 ) Retorna la diferencia en meses entre dos fechas. ROUND( d, s ) Redondea la fecha d según el formato indicado en s. (*) TRUNC( d, s ) Trunca la fecha d según el formato indicado en s. (*)

Formatos para ROUND y TRUNC para fechas:

Formato Descripción ‘MONTH’, ‘MON’, ‘MM’ Principio de mes ‘DAY’, ‘DY’, ‘D’ Principio de semana ‘YEAR’, ‘YYYY’, ‘Y’ Principio de año

Estas funciones actúan sobre un conjunto de valores, retornando sólo un registro.

Función Descripción SUM( valores ) Retorna la suma. AVG( valores ) Retorna la media aritmética MAX( valores ) Retorna el máximo. MIN( valores ) Retorna el mínimo COUNT(valores|* ) Retorna la cuenta. Todas estas funciones permite incluir el modificador DISTINCT delante de la lista de valores para que omita los repetidos.

Función Descripción CHARTOROWID( s ) Convierte una cadena en tipo de dato ROWID. ROWIDTOCHAR( rowid ) Convierte un tipo de dato ROWID en cadena de caracteres. TO_CHAR( *[, s] ) Convierte el tipo de dato * en cadena de caracteres. Si * es una fecha, se podrá utilizar la cadena s como formato de conversión. TO_DATE( s1[, s2] ) Convierte la cadena s1 en fecha, conforme al formato de convesión s2. TO_NUMBER( s ) Convierte una cadena de caracteres en valor numérico.

Función Descripción DUMP( columna ) Retorna información de almacenamiento para la columna indicada. GREATEST( expr1, expr2, … exprN ) Retorna la expresión mayor. LEAST( expr1, expr2, … exprN ) Retorna la expresión menor. NVL( expr1, expr2 ) Retorna expr2 si expr1 es NULL, sino retorna expr1. USEREVN( s ) Retorna opciones de entorno de la sesión activa: Los valores para s pueden ser: • ‘ISDBA’: Retorna ‘TRUE’ si el usuario activo tiene el rol DBA. • ‘LANGUAGE’: Idioma activo. • ‘TERMINAL’: Nombre de terminal donde se realiza la consulta. • ‘SESSIONID’: Número de sesión activa. DECODE( expr_ev, Caso_1, ret_1, Caso_2, ret_2, … Caso_N, ret_N, Caso_else ) Permite hace una evaluación de valores discretos. Es similar a la estructura switch de C/C++ o case of de Pascal. Ejemplo: DECODE( COLOR, ‘R’, ‘Rojo’, ‘V’, ‘Verde’, ‘A’, ‘Azul’, ‘Color desconocido’ )

Debido a que en las operaciones normales con la base de datos puede corromper la información, todas las bases de datos tiene un sistema de control de transacción.

Se denomina transacción al espacio de tiempo que hay desde que se hace la primera sentencia DML que no sea SELECT (INSERT, UPDATE, DELETE), hasta que damos por finalizada la transacción explícitamente (con las sentencias apropiadas) o implícitamente (terminando la sesión).

Durante la transacción, todas las modificaciones que hagamos sobre base de datos, no son definitivas, más concretamente, se realizan sobre un tablespace especial que se denomina tablespace de ROLLBACK, o RBS (RollBack Segment). Este tablespace tiene reservado un espacio para cada sesión activa en el servidor, y es en ese espacio donde se almacenan todas las modificaciones de cada transacción. Una vez que la transacción se ha finalizado, las modificaciones temporales almacenadas en el RBS, se vuelcan al tablespace original, donde está almacenada nuestra tabla. Esto permite que ciertas modificaciones que se realizan en varias sentencias, se puedan validar todas a la vez, o rechazar todas a la vez.

Las sentencias de finalización de transacción son:

COMMIT: la transacción termina correctamente, se vuelcan los datos al tablespace original 
        y se vacía el RBS. 
ROLLBACK: se rechaza la transacción y el vacía el RBS.

Ejemplo de transacción:

Histórico de sentencias:

SELECT;
SELECT; SELECT; UPDATE; SELECT; INSERT; UPDATE;
SELECT; UPDATE; COMMIT;	
Transacción

Si nuestro número de sentencias es tan grande que el RBS se llena, Oracle hará un ROLLBACK, por lo que perderemos todos los datos. Así que es recomendable hacer COMMIT cada vez que el estado de la base de datos sea consistente.

Si terminamos la sesión con una transacción pendiente, Oracle consultará el parámetro AUTOCOMMIT, y si éste está a TRUE, se hará COMMIT, si está FALSE se hará ROLLBACK;

Ya dijimos en los primeros capítulos que SQL es un lenguaje de comandos, no un lenguaje de programación con todas las estructuras de control típicas. Así, SQL sólo contempla instrucciones, más o menos simples, pero no tiene ningún tipo de instrucciones de control de flujo o de otro tipo más propias de los lenguajes de programación 3GL. Para subsanar esta carencia, Oracle definió un lenguaje de programación de tercera generación, que admitía sentencias SQL embebidas. Este lenguaje se llama PL/SQL (Programming Language/SQL)

La idea básica sobre la que se sustenta el PL/SQL es aplicar las estructuras típicas de un lenguaje de programación (bifurcaciones, bucles, funciones…) a las sentencias SQL típicas.

Así podemos tener el siguiente pseudocódigo:

Sentencia SELECT que recupera el total de sueldos

Si el total de sueldos > 1.000.000
   Sentencia UPDATE que incrementa un 10% los sueldos
Si no
    Sentencias UPDATE que incrementa un 5% los sueldos
Fin-si

Cuando se escribe código en PL/SQL, este debe estar agrupado en unidades denominadas “bloques de código”. Un bloque de código puede contener otros sub-bloques de código y así sucesivamente.

Un bloque de código queda delimitado por las palabras reservadas BEGIN y END. Por ejemplo:

BEGIN
  Sentencias . . . 
  Sentencias . . . 
  Sentencias . . .
BEGIN
  Sentencias . . . 
  Sentencias . . . 
   Sentencias . . .
END;
   Sentencias . . .
   Sentencias . . . 
   Sentencias
END;

En este ejemplo podemos ver que hay un bloque de código externo que contiene un bloque de código interno. Un bloque de código opcionalmente puede contar con las siguientes secciones:

DECLARE
 
   Declaración de VARIABLES
 
BEGIN
 
   Sentencias SQL y PL/SQL
 
EXCEPTION
 
   Manejadores de excepciones
 
END;

La única sección obligatoria es la contenida dentro de BEGIN y END;

Comentarios

Los comentarios pueden ser multilínea encerrados entre /* y */ o monolínea, que comienzan por –

Las variables deben declararse dentro de la sección DECLARE y deben seguir la siguiente sintaxis:

Nombre_de_variable {CONSTANT} TIPO {:= inicialización};

Los tipos posibles son todos aquellos válidos para SQL añadiendo algunos propios de PL/SQL. Para más información sobre los tipos propios de PL/SQL consultar el PL/SQL User’s Guide and Reference

Ejemplos:

Interes NUMBER(5,3); Descripcion VARCHAR2(50) := ‘inicial’; Fecha_max DATE; Contabilizado BOOLEAN := TRUE; PI CONSTANT REAL := 3.14159

Como PL/SQL es un lenguaje 3GL, cuenta con las estructuras típicas de control de flujo: bifurcaciones condicionales y bucles:

Bifurcaciones condicionales:

La sintaxis básica es:

IF condición_1 THEN
Se ejecuta si se cumple condicion_1
ELSIF condicion_2 THEN – la palabra reservada es ELSIF y no es ELSEIF 
Se ejecuta si no se cumple condicion_1 y se cumple condicion_2
ELSE
Se ejecuta si no se cumple condicion_1 ni condicion_2
END IF;

Como en cualquier lenguaje de programación, las estructuras IF se pueden anidar unas dentro de otras.

Bucles Existen varias variantes de la estructura bucle. La más sencilla es la siguiente:

LOOP
   sentencias
END LOOP;

Las sentencias de dentro del bucle se ejecutarán durante un número indefinido de vueltas, hasta que aparezca la instrucción EXIT; que finalizará el bucle. Este tipo de bucle se denomina bucle incondicional. Otra opción es incluir la estructura EXIT WHEN condición, se terminará el bucle cuando la condición se cumpla:

LOOP Sentencias
   EXIT WHEN condicion; 
      Sentencias
END LOOP;

El bucle anterior es equivalente al siguiente:

LOOP 
  Sentencias
   IF condicion THEN EXIT;
    END IF;

   Sentencias
END LOOP;	

Un tipo de bucle más común son los bucles condicionales:

WHILE condicion LOOP 
   Sentencias
END LOOP;

Y por último el bucle FOR:

FOR contador IN {REVERSE} limite_inferior..limite_superior LOOP
   sentencias
END LOOP;

Contador deberá ser una variable de tipo numérico que sea capaz de contener los valores comprendidos entre limite_inferior y limite_superior. Limite_inferior y limite_superior deberán ser expresiones numéricas, ya sean constantes (1,10…) o funciones (ROUND(max,0), ASCII(‘A’)…)

Si la variable contador no está definida, PL/SQL definirá una variable de tipo INTEGER al iniciar el bucle, y la liberará al finalizar el bucle.

Existen dos tipos de datos que no hemos mencionado anteriormente: los registros (o estructuras) y las tablas (o arrays o vectores).

Los dos tipos deben ser definidos en un como un nuevo tipo antes de declarar variables de ese nuevo tipo. El modo de definir nuevos tipos de variables en PL/SQL es a través de la palabra reservada TYPE:

TYPE nuevo_tipo IS tipo_original.

Una vez definido en nuevo tipo, ya se pueden definir variables de ese nuevo tipo:

Una_variable nuevo_tipo;

Registros:

Los registros no son más que agrupaciones de tipos de variables que se acceden con el mismo nombre.

La sintaxis de definición de registros es:

TYPE nombre_registro IS RECORD( Campo1  tipo,
Campo2  tipo, Campo3  tipo );

Por ejemplo:

TYPE alumno IS RECORD( n_alumno	VARCHAR2(5), nombre	VARCHAR2(25), 
apellido_1  VARCHAR2(25), apellido_2  VARCHAR2(25), tlf	VARCHAR2(15) );

Tablas:

Una tabla no es más que una colección de elementos identificados cada uno de ellos por un índice. En muchos lenguajes se les denomina arrays.

La sintaxis de definición de tablas es:

TYPE nombre_tabla IS TABLE OF tipo_de_elementos;

El tamaño de la tabla se define durante la declaración de la variable

Nombre_variable nombre_tabla := nombre_variable( lista de elementos );

Por ejemplo:

DECLARE
 
TYPE array_enteros IS TABLE OF INTEGER;
Un_array  array_enteros := array_enteros( 0, 0, 0, 0 );
 
BEGIN
END;

El ejemplo anterior define un tipo de array de enteros y después declara una variable de ese tipo, inicializándola a 4 elementos (todos con 0).

Anteriormente dijimos que un bloque de código puede contener una sección denominada EXCEPTION. Esta sección es la encargada de recoger todas las anomalías que se puedan producir dentro del bloque de código.

Una excepción es una situación especial dentro de la ejecución de un programa, que puede ser capturada para asignar un nuevo comportamiento. Una excepción puede ser un error de ejecución (una división entre 0) o cualquier otro tipo de suceso.

Las excepciones deben ser declaradas dentro de la sección DECLARE, como si de una variable se tratasen:

DECLARE
e_sin_alumnos  EXCEPTION;

Una vez que la excepción está definida, ésta debe ser lanzada, ya sea automáticamente por Oracle, o lanzada manualmente a través de la instrucción RAISE.

SELECT COUNT(*) INTO num_alumnos;
 
IF num_alumnos = 0 THEN RAISE e_sin_alumnos;
END IF;

Una vez que la excepción ha sido lanzada, la ejecución continua en la sección EXCEPTION, concretamente en el manejador apropiado (o el manejador WHEN OTHERS cuando no exista el específico).

Un manejador de excepciones es una sub-sección dentro de la sección EXCEPTION que se encarga de capturar una excepción concreta.

La sintaxis para escribir manejadores es:

EXCEPTION
WHEN <excepción> THEN
 
WHEN <otra_excepción> THEN WHEN OTHERS THEN
END;

Las líneas de código debajo del manejador específico se ejecutarán cuando esa excepción se produzca. Un ejemplo completo:

DECLARE
e_sin_alumnos  EXCEPTION;
 
num_alumnos	NUMBER(5); BEGIN
SELECT COUNT(*)
INTO num_alumnos;
 
 
IF num_alumnos = 0 THEN
RAISE e_sin_alumnos; END IF;
 
EXCEPTION
WHEN e_sin_alumno
INSERT INTO ERROR( FECHA, DESCRIPCION )
VALUES( SYSDATE, ‘No se han encontrado alumnos en la tabla ALUMNO.’);
 
WHEN OTHERS
Raise_application_error( -20000, ‘Error en bloque de codigo PL/SQL’ );
-- este error se transmite a la aplicación que llame a este bloque de código (PL/SQL,
-- Java, C/C++, etc.) 
 
END;

Anteriormente habíamos dicho que las excepciones puede lanzarse automáticamente o manualmente a través de la instrucción RAISE.

Algunas excepciones se lanzarán automáticamente cuando se produzcan ciertos tipos de errores en la ejecución del bloque de código. Cada excepción automática tiene asociado un código de error ORA-XXXX el cual si se produce, hará que se lance la excepción correspondiente.

A continuación se muestra una lista de las excepciones automáticas predefinidas por Oracle:

Cuando dentro de un intérprete SQL escribimos una consulta SELECT, el intérprete nos muestra las distintas filas de resultados para que podamos verlas. Sin embargo, dentro de un lenguaje de programación tenemos un problema, ya que lo más común no es mostrar el resultado, sino almacenarlo en variables para su posterior tratamiento.

Ahora tenemos que dividir el problema en dos partes, dependiendo del número de filas que nos retorna la consulta SELECT:

 Si retorna cero o una fila: El valor se podrá almacenar en tantas variables como columnas 
 consultadas. Es decir, si escribimos un SELECT de tres columnas, y sólo retorna una fila 
 (matriz 1x3), podremos almacenar el valor dentro de tres variables definidas para este uso.

El modo de hacer esto en PL/SQL es:

SELECT col1, col2, col3
INTO	var1, var2, var3
FROM	TABLA;

De este modo se almacenará en las variables var1, var2 y var3 los valores recuperados por la consulta SELECT o NULL si esta consulta no retorna ninguna fila.

 Si retorna más de una fila: En este caso no es posible almacenar directamente los 
 valores en variables. Para ello existen los cursores, que no son más que consultas 
 SELECT que se recuperar fila a fila y no todo su conjunto de resultados a la vez.

De las maneras que tiene PL/SQL para tratar el tema de los cursores, el más sencillo y seguro son los cursores implícitos, puesto que al no tener que declararlos son más sencillos, no se tiene que estar pendiente del cierre, del control de las excepciones, que pueden dejar los cursores abiertos, etc.

A continuación se describe la forma de utilizar un cursor implícito en PL/SQL:

FOR <contador> IN <SELECT….> LOOP
   Sentencias;
END LOOP;

Ejemplo:

DECLARE
vn_ID_ALUMNO	NUMBER(5); 
vv_NOMBRE        VARCHAR2(30);
BEGIN
 
FOR I IN (SELECT ID_ALUMNO, NOMBRE FROM ALUMNOS) LOOP
 
		vn_ID_ALUMNO := i.ID_ALUMNO;
       vv_NOMBRE :=i.NOMBRE;
       .
       . 
       .
 
END LOOP
 
EXCEPTION
WHEN OTHERS
 
END;

Una vez que tenemos escrito un bloque de código, podemos guardarlo en un fichero .SQL para su posterior uso, o bien guardarlo en base de datos para que pueda ser ejecutado por cualquier aplicación.

A la hora de guardar un bloque de código hay que tener en cuenta ciertas normas:

1.- Palabra reservada DECLARE desaparece

2.- Podremos crear procedimientos y funciones. Los procedimientos no podrán retornar ningún valor, mientras que las funciones deben retornar un valor de un tipo de dato básico.

Para crear un procedimiento (stored procedure: procedimiento almacenado) usaremos la siguiente sintaxis:

CREATE {OR REPLACE} PROCEDURE nombre_proc( tipo_dato param1, tipo dato_param2... ) IS
 
<Sección DECLARE> 
BEGIN
{EXCEPTION} 
END;

Para crear una función usaremos la siguiente sintaxis:

CREATE {OR REPLACE} FUNCTION nombre_func( tipo_dato param1, tipo dato_param2... ) RETURN tipo_dato IS

<Sección DECLARE> 
BEGIN
{EXCEPTION}
END;

Una vez que tenemos creados nuestros procedimientos y funciones podemos almacenarlos dentro de librerías de funciones. Estas librerías tienen el nombre de paquetes o packages.

Un paquete puede contener procedimientos, funciones, variables, tipos y subtipos, en general, cualquier objeto que se pueda declarar dentro de la sección DECLARE de un bloque de código.

La creación de un paquete pasa por dos fases:

1.- Crear la cabecera del paquete donde se definen que procedimientos, funciones, variables, etc. Contendrá el paquete.

2.- Crear el cuerpo del paquete, donde se definen los bloques de código de las funciones y procedimientos definidos en la cabecera del paquete.

Para crear la cabecera del paquete utilizaremos la siguiente instrucción:

CREATE {OR REPLACE} PACKAGE nombre_de_paquete IS < declaraciones > END;

Para crear el cuerpo del paquete utilizaremos la siguiente instrucción:

CREATE {OR REPLACE} PACKAGE BODY nombre_paquete IS

< Bloques de código> END;

Hay que tener en cuenta que toda declaración de función o procedimiento debe estar dentro del cuerpo del paquete, y que todo bloque de código contenido dentro del cuerpo debe estar declarado dentro de la cabecera de paquete.

Cuando se quiera acceder a las funciones, procedimientos y variables de un paquete se debe anteponer el nombre de este:

Nombre_paquete.función(x) Nombre_paquete.procedimiento(x) Nombre_paquete.variable

Oracle define los siguientes paquetes de funciones predefinidos:

DBMS_ALERT
DBMS_APPLICATION_INFO 
DBMS_AQ
DBMS_AQADM 
DBMS_DDL 
DBMS_DEFER 
DBMS_DEFER_QUERY 
DBMS_DEFER_SYS 
DBMS_DESCRIBE 
DBMS_JOB
DBMS_LOB 
DBMS_LOCK
DBMS_OUTPUT 
DBMS_PIPE 
DBMS_REFRESH 
DBMS_REPCAT 
DBMS_REPCAT_ADMIN 
DBMS_REPCAT_AUTH 
DBMS_ROWID 
DBMS_SESSION 
DBMS_SHARED_POOL 
DBMS_SNAPSHOT 
DBMS_SQL 
DBMS_UTILITY UTL_FILE

Para más información sobre PL/SQL consultar el Oracle PL/SQL User’s Guide and Reference

Los disparadores (o triggers) son bloques de código almacenados en base de datos y que se ejecutan automáticamente. Un disparador está asociado a una tabla y a una operación DML específica (INSERT, UPDATE o DELETE). En definitiva, los disparadores son eventos a nivel de tabla que se ejecutan automáticamente cuando se realizan ciertas operaciones sobre la tabla.

Para crear un disparador utilizaremos la siguiente instrucción:

CREATE {OR REPLACE} TRIGGER nombre_disp
[BEFORE|AFTER|INSTEAD OF] [DELETE|INSERT|UPDATE {OF columnas}] ON tabla
{DECLARE} 
BEGIN
{EXCEPTION}
 END;

Para más información sobre los disparadores consultar el Oracle SQL Reference

Los Jobs, son la forma que tiene Oracle de planificar trabajos. Están almacenados en la base de datos y se ejecutan automáticamente. Un Job es un objeto independiente, y puede ejecutar tanto una función o procedimiento almacenado como una sentencia SQL o un Bloque de PL/SQL.

Para crear un Job utilizaremos la siguiente instrucción:

 
DECLARE
  X NUMBER;
BEGIN
  SYS.DBMS_JOB.SUBMIT
    ( job       => X 
     ,what      => '<Sentancia(s) a Ejecutar>'
     ,next_date => TO_DATE('<Fecha y hora de la siguiente ejecución>','dd/mm/yyyy hh24:mi:ss')
     ,INTERVAL  => '<Intervalo de tiempo>'
     ,no_parse  => TRUE
     ,INSTANCE  => 1
     ,FORCE     => TRUE
    );
  SYS.DBMS_OUTPUT.PUT_LINE('Job Number is: ' || TO_CHAR(x));
END;
/
 
COMMIT;

Oracle cuenta con una serie de tablas y vistas que conforman una estructura denominada catálogo. La principal función del catálogo de Oracle es almacenar toda la información de la estructura lógica y física de la base de datos, desde los objetos existentes, la situación de los datafiles, la configuración de los usuarios, etc.

El catálogo sigue un estándar de nomenclatura para que su memorización sea más fácil:

Prefijos:

USER, ALL, DBA

Existe una tabla de catálogo para cada tipo de objeto posible. Su nombre aparecerá en plural

TABLES, VIEWS, SEQUENCES, TABLESPACES…

Sabiendo qué objetos existen, y qué prefijos podemos utilizar, ya podemos acceder a los objetos del catálogo de Oracle.

Ejemplos:

Los objetos de catálogo también guardan relaciones entre ellos. Por ejemplo, el objeto ALL_TABLES guarda una relación 1-N con el objeto ALL_TAB_COLUMNS: Una tabla tiene N columnas.

Existe un pseudo usuario llamado PUBLIC el cual tiene acceso a todas las tablas del catálogo público. Si se quiere que todos los usuarios tengan algún tipo de acceso a un objeto, debe darse ese privilegio a PUBLIC y todo el mundo dispondrá de los permisos correspondientes.

El catálogo público son aquellas tablas (USER_ y ALL_) que son accesibles por todos los usuarios. Normalmente dan información sobre los objetos creados en la base de datos.

El catálogo de sistema (DBA_ y V_$) es accesible sólo desde usuarios DBA y contiene tanto información de objetos en base de datos, como información específica de la base de datos en sí (versión, parámetros, procesos ejecutándose…)

Ciertos datos del catálogo de Oracle están continuamente actualizados, como por ejemplo las columnas de una tabla. Cuando se crea una columna nueva se añade la entrada correspondiente al catálogo. Sin embargo hay otros datos que no pueden actualizarse en tiempo real porque penalizarías mucho el rendimiento general de la base de datos, como por ejemplo el número de registros de una tabla, el tamaño de los objetos, etc. Para actualizar el catálogo de este tipo de datos es necesario ejecutar una sentencia especial que se encarga de volcar la información recopilada al catálogo:

ANALYZE [TABLE|INDEX] nombre
[COMPUTE|ESTIMATE|DELETE] STATISTICS;

La cláusula COMPUTE hace un cálculo exacto de la estadísticas (tarda más en realizarse en ANALYZE), la cláusula ESTIMATE hace una estimación partiendo del anterior valor calculado y de un posible factor de variación y la cláusula DELETE borra las anteriores estadísticas.

El catálogo público contiene ciertas tablas encargadas de almacenar información adicional sobre tablas, vistas y columnas. La información que se suele almacenar es información de análisis, valores posibles para las columnas y en general todo aquello que se haya concluido durante la etapa de análisis.

Las tablas existentes son:

La información se debe almacenar en base de datos según la siguiente sintaxis:

COMMENT ON TABLE [tabla|vista] IS ‘texto’;

COMMENT ON COLUMN [tabla|vista].columna IS ‘texto’;

Una vez que esta información está en base de datos, se puede escribir procedimientos o scripts SQL que muestren la información para sacar informes de documentación de base de datos.

Una de las tareas más importantes de las propias de un desarrollador de bases de datos es la de puesta a punto o tuning. Hay que tener en cuenta que las sentencias SQL pueden llegar a ser muy complejas y conforme el esquema de base de datos va creciendo las sentencias son más complejas y confusas. Por es difícil escribir la sentencia correcta a la primera. Por todo ello después de tener cada uno de los procesos escrito, hay que pasar por una etapa de tuning en la que se revisan todas las sentencias SQL para poder optimizarlas conforme a la experiencia adquirida.

Tanto por cantidad como por complejidad, la mayoría de las optimizaciones deben hacerse sobre sentencias SELECT, ya que son (por regla general) las responsables de la mayor pérdida de tiempos.

A continuación se dan unas normas básicas para escribir sentencias SELECT optimizadas.

• Las condiciones (tanto de filtro como de join) deben ir siempre en el orden en que esté definido el índice. Si no hubiese índice por las columnas utilizadas, se puede estudiar la posibilidad de añadirlo, ya que tener índices de más sólo penaliza los tiempos de inserción, actualización y borrado, pero no de consulta.
• Evitar la condiciones IN ( SELECT…) sustituyéndolas por joins.
• Colocar la tabla que devuelve menor número de registros en el último lugar del FROM
• Si en la cláusula WHERE se utilizan campos indexados como argumentos de funciones, el índice quedará desactivado.
• Una condición negada con el operador NOT desactiva los índices
• Una consulta cualificada con la cláusula DISTINCT debe ser ordenada por el servidor aunque no se incluya la cláusula ORDER BY.
• Para escribir una condición de existencia no se hace un SELECT COUNT(*), se hace un SELECT 1
• No se deben hacer SELECT *; SELECT a,b…
• Bind: Paso de parámetros por referencias

Toda consulta SELECT se ejecuta dentro del servidor en varios pasos. Para la misma consulta, pueden existir distintos caminos para conseguir el mismo resultado, por lo que el servidor es el responsable de decidir qué camino seguir para conseguir el mejor tiempo de respuesta. La parte de la base de datos que se encarga de estas decisiones se llama Optimizador. El camino seguido por el servidor para la ejecución de una consulta se denomina “Plan de ejecución” En Oracle existen dos optimizadores para la decisión del plan de ejecución:

1. Optimizador por reglas (RULE): se basa en ciertas reglas para realizar las consultas. Por ejemplo, si se filtra por un campo indexado, se utilizará el índice. Si la consulta contiene un ORDER BY, se utilizará un algoritmo Quick Sort, etc. No tiene en cuenta el estado actual de la base de datos, ni el número de usuarios conectados, ni la carga de datos de los objetos, etc. Es un sistema de optimización estático, no varía de un momento a otro. Es un tipo de optimización que puede considerarse obsoleto, puesto que en Oracle 10 se desaconseja su uso y en Oracle 11 desaparecerá.

1. Optimizador por costes (CHOOSE): se basa en las reglas básicas, pero teniendo en cuenta el estado actual de la base de datos. Es decir, tiene en cuenta el número de registros de las tablas, el número de usuarios accediendo a ellas, etc. Por ejemplo, si se hace una consulta utilizando un campo indexado, mirará primero el número de registros y si es suficientemente grande entonces merecerá la pena acceder por el índice, si no, accederá directamente a la tabla.

Para averiguar el estado actual de la base de datos se basa en los datos del catálogo público, por lo que es recomendable que esté lo más actualizado posible (a través de la sentencia ANALYZE), ya que de no ser así, se pueden tomar decisiones a partir de datos desfasados (la tabla tenía 10 registros hace un mes pero ahora tiene 10.000).

Plan de ejecución

Aunque en la mayoría de los casos no hace falta saber cómo ejecuta Oracle las consultas, existe una sentencia especial que nos permite ver esta información.

Básicamente se trata en rellenar una tabla especial (llamada PLAN_TABLE) con los un registro para cada paso en el plan de ejecución.

La tabla PLAN_TABLE debe tener la siguiente estructura (en Oracle)

CREATE TABLE PLAN_TABLE (
STATEMENT_ID		VARCHAR2 (30), 
TIMESTAMP		DATE,
REMARKS			VARCHAR2 (80), 
OPERATION		VARCHAR2 (30), 
OPTIONS			VARCHAR2(30), 
OBJECT_NODE		VARCHAR2(128), 
OBJECT_OWNER		VARCHAR2 (30), 
OBJECT_NAME		VARCHAR2 (30), 
OBJECT_INSTANCE		INTEGER, 
OBJECT_TYPE		VARCHAR2 (30), 
OPTIMIZER		VARCHAR2 (255), 
SEARCH_COLUMNS		INTEGER,
ID			INTEGER, 
PARENT_ID		INTEGER, 
POSITION			INTEGER, 
COST			INTEGER, 
CARDINALITY		INTEGER, 
BYTES			INTEGER,
OTHER_TAG		VARCHAR2 (255), 
OTHER			LONG);

Una vez que la tabla está creada en el usuario donde vamos a ejecutar la consulta, de debe ejecutar la siguiente sentencia:

EXPLAIN PLAN
SET STATEMENT_ID = ‘identificador de sentencia’ 
FOR <consulta SELECT a evaluar>;

El identificador de sentencia tiene que ser una cadena descriptiva para nuestra sentencia. Se utilizará más tarde para recuperar el plan entre todos los almacenados dentro de la consulta SELECT.

Esta sentencia lo que hará es almacenar en la tabla PLAN_TABLE un registro por cada paso en el plan de ejecución. El campos STATEMENT_ID de los pasos de nuestro plan de ejecución estará al valor indicado en ‘identificador de sentencia’.

Para mostrar el plan de ejecución se debe hacer un SELECT filtrando aquellos registros de nuestro plan de ejecución. Una sentencia típica que nos muestra el plan de ejecución formateado podría ser:

SELECT     ID, parent_id,
              LPAD (' ', 2 * (LEVEL - 1))
           || operation
           || ' '
           || options
           || ' '
           || object_name
           || ' '
           || DECODE(ID,0,'Cost = '|| POSITION) "Plan de consulta"
      FROM plan_table
START WITH ID = 0 AND STATEMENT_ID = 'identificador de sentencia'
CONNECT BY PRIOR ID = parent_id
           AND STATEMENT_ID = 'identificador de sentencia';

El modo de activar las trazas de ejecución es a través de SQL*Plus, con la instrucción Set auto trace ON/OFF

Una vez activada la auto-traza, toda sentencia ejecutada en SQL*Plus vendrá acompañada de su plan y estadísticas de ejecución.

Con la instrucción:

SET TIMING ON

Se activará el reloj interno de Oracle con el que se podrá cronometrar el tiempo de ejecución de cada consulta.

1. En un OLTP (Transaccional) no se deben crear índices bitmap, al haber gran volumen de transacciones, los índices bitmap no son óptimos.
2. No deben haber más de 5 índices por cada tabla.
3. Los índices deben ser discriminantes; Se dice que un índice es discriminante cuando una consulta por uno de sus valores no devuelve más de un 5% de los valores de la Tabla.
4. Ojo con las consultas con muchas Joins, no se deben cruzar muchas tablas. Por el mismo motivo se deben utilizar las vistas con mucho cuidado, puesto que provocan que se crucen muchas tablas inadvertidamente.
5. Al construir una Query se debe tener en cuenta el volumen de información que vamos a mover.
6. Con grandes volúmenes de información, la desnomalización no está prohibida, se debe estudiar con detenimiento la conveniencia de ella.
7. Índices en las claves foráneas:

• Al crear un Clave primaria ya crea un índice único automáticamente.
• Al crear un Clave foránea no lo crea.
• Si no tenemos índice, al hacer un delete en la tabla padre o un update de su PK, como la FK tiene que mantener la integridad referencial, se recorrerá la tabla, por lo que es recomendable que lo haga por índice.
• Si tenemos índice, los bloqueos los hará a nivel de registro y no de tabla.

Por Ejemplo en el siguiente esquema:

Si NO existieran los índices, en el momento que un usuario borrara un alumno o una asignatura, pararía lo siguiente:

• Oracle debe mantener la Integridad referencial, por lo que tiene que recorrerse entera la tabla Alumno_Asignaturas.
• Como no tiene índice, hace un Full Scan.
• El bloqueo será a nivel de tabla y no lo liberará hasta que termine la transacción.

Oracle 9i SQL Reference, PL/SQL User's Guide and Reference:

Documentación de Oracle:

http://tahiti.oracle.com/

Oracle Corporation:

http://www.oracle.com http://otn.oracle.com