Oracle Certificación Blog 1Z-051

BETWEEN

2017-04-07T03:37:00.001-07:00

Comparaciones de Rango mediante el operador BETWEEN. El operador BETWEEN prueba si el valor de una columna o expresión cae dentro de un rango de valores limites. El valor debe ser igual al límite inferior o al límite superior o caer dentro del rango de valor para que la condición sea verdadera.

El operador también los podemos utilizar con valores carácter, fecha y numéricos como ya se ha explicado. Una condición BETWEEN es equivalente a escribir dos condiciones de desigualdad.

Ejemplos:

-- BETWEEN CON VALORES NUMERICOS. PARA QUE LA CONDICION SEA VERDADERA EL VALOR DE LA COLUMNA DEBE SER IGUAL AL LIMITE INFERIOR,

-- O AL LIMITE SUPERIOR O CAER DENTRO DEL RANGO DE VALORES.

SELECT product_id, product_name, list_price

FROM product_information

WHERE list_price BETWEEN 100 AND 110;

SELECT order_id, order_mode, customer_id, order_total

FROM orders

WHERE order_total BETWEEN 20000 AND 25000;

-- PRIMERO DEBE IR EL LIMITE INFERIOR Y POR ULTIMO EL LIMITE SUPERIOR

SELECT order_id, order_mode, customer_id, order_total

FROM orders

WHERE order_total BETWEEN 25000 AND 20000;

-- EL BETWEEN ES EQUIVALENTE A UTILIZAR OPERADORES DE COMPARACION.

SELECT product_id, product_name, list_price

FROM product_information

WHERE list_price >= 100 AND list_price <=110;

SELECT order_id, order_mode, customer_id, order_total

FROM orders

WHERE order_total >= 20000 AND order_total <= 25000;

-- REGIONS LOCATIONS DEPARTMENTS JOBS EMPLOYEES JOB_HISTORY COUNTRIES

SELECT region_id, region_name FROM regions WHERE region_id BETWEEN 2 AND 3;

SELECT region_id, region_name FROM regions WHERE region_id >= 2 AND region_id <= 3;

-- PRIMERO SE DEBE ESPECIFICAR EL LIMITE INFERIOR Y POSTERIORMENTE EL LIMITE SUPERIOR.

-- PARA QUE LA CONDICION SEA VERDADERA EL VALOR DE LA COLUMNA DEBE SER IGUAL AL LIMITE INFERIOR

-- O IGUAL AL LIMITE SUPERIOR O CAER EN EL RANGO DE VALORES DEFINIDOS EN EL BETWEEN.

SELECT region_id, region_name FROM regions WHERE region_id BETWEEN 3 AND 2;

-- EJEMPLOS CON VALORES CARACTER

SELECT * FROM locations WHERE country_id BETWEEN 'AA' AND 'AZ';

SELECT * FROM locations WHERE country_id BETWEEN 'AA' AND 'BZ';

SELECT * FROM locations WHERE country_id BETWEEN 'AA' AND 'CH';

SELECT * FROM locations WHERE ('c' BETWEEN ('A' AND 'Z')) OR ('c' BETWEEN ('a' AND 'b'));

-- REGIONS LOCATIONS DEPARTMENTS JOBS EMPLOYEES JOB_HISTORY COUNTRIES

SELECT * FROM job_history WHERE start_date BETWEEN '17-09-1995' AND '28-10-2001';

El funcionamiento del operador BETWEEN es el mismo con valores carácter y fechas.

Definiendo una Función

2017-04-07T03:37:00.000-07:00

Una función es un programa escrito que opcionalmente acepta parámetros de entrada, desarrolla una operación y retorna un solo valor. una función retorna un solo valor por ejecución

Resumen

2013-10-18T22:42:00.001-07:00

Las Vistas son sentencias SELECT, almacenadas en el Diccionario de Datos. Pueden ser Consultados como si fueran tablas, y en algunos casos pueden ser objeto de sentencias DML. A simple vista son columnas de una tabla, sin agregaciones o funciones; una Vista compleja puede unir tablas, agregados, y usar funciones. Como regla general, es posible hacer DML'S a través de una vista sencilla pero no a través de una Vista Compleja, pero hay excepciones.

Los sinónimos son alias que se pueden utilizar para acceder a las vistas y tablas. Sinónimos pueden simplificar el código por lo que no es necesario especificar los calificadores de esquema o los nombres de enlace de base de datos: permite ejecutar código sin necesidad de saber sobre la propiedad de los datos o la ubicación. Las tablas, vistas y sinónimos comparten el mismo espacio de nombres: dentro de un esquema, todos ellos deben tener nombres diferentes y se pueden utilizar indistintamente.

Secuencias generar números únicos, general para su uso como valores de clave principal. Índices tienen un doble propósito: hacer cumplir las restricciones y aumentar el rendimiento. Si un índice está disponible cuando se define una restricción, Oracle lo usara, de lo contrario, se crea implícitamente un índice. Cuando creamos índices para rendimiento, considere en columnas que utilizan para unir tablas o en cláusulas WHERE y crear índices de árbol B * en columnas con alta cardinalidad y los índices de mapa de bits en las columnas con relativamente pocos valores distintos.

Una Vista Simple tiene solo una tabla detalle no utiliza funciones ni agregaciones.

Una Vista Compleja puede estar basada de cualquier consulta SELECT, no importando que tan compleja sea.

Las vistas son objetos de esquema.

Una vista se puede consultar exactamente como si fuera una tabla.

Las vistas se pueden unir a otras vistas o tablas, pueden ser agregados, y en algunos casos se pueden aceptar instrucciones DML.

Vistas existen sólo como construcciones en el diccionario de datos. Cuando se consulta una vista, se debe ejecutar la instrucción SELECT subyacente.

Un sinónimo es un nombre alternativo para una vista o una tabla.

Sinónimos privadas son objetos de esquema , existen sinónimos públicos fuera de los esquemas de usuario y se pueden utilizar sin especificar un nombre de esquema como calificador .

Sinónimos comparten el mismo espacio de nombres que vistas y tablas, por lo que se pueden utilizar indistintamente.

Una secuencia genera valores únicos - a menos que sea MAXVALUE o MINVALUE y el CYCLE se han especificado.

Incrementar una secuencia no tiene por qué ser Confirmada y no puede ser revertido.

Cualquier sesión puede incrementar la secuencia mediante la lectura de su valor siguiente. Es posible obtener el último valor publicado de la sesión, pero no el último valor publicado.

Índices son necesarios para hacer cumplir las restricciones de clave única y primaria. NULL no se incluyen en los índices de árbol B *, pero se incluyen en los índices de mapa de bits.

B * índices de árbol puede ser único o no único, que determina si pueden aceptar valores de clave duplicados.

B * Tree índices son adecuados para altas columnas de cardinalidad, índices de mapa de bits de las columnas bajas de cardinalidad.

Los índices compuestos tienen una clave que consiste en varias columnas, que pueden ser de diferentes tipos de datos.

RESUMEN

2013-10-18T21:16:00.001-07:00

Las tablas son estructuras de dos dimensiones que consta de filas de columnas con un tipo de dato definido para cada columna. La base de datos Oracle permite definir tipos de datos definidos por el usuario, pero en su mayor parte se van a utilizar los tipos de datos predefinidos.

Las tablas pueden ser creadas a partir de cero: la definición de cada columna y luego insertar filas. Como alternativa, las tablas pueden ser creadas usando la salida de una consulta. Esta última técnica se puede definir lla tabla e insertar las filas en un solo comando, pero hay limitaciones: será necesario añadir PRIMARY KEY y las CONSTRAINT UNQUE más tarde, mientras que se pueden definir en el momento de creación de la tabla utilizando la antigua técnica. Para ayudar en la aplicación de las reglas de negocio, los CONSTRAINT pueden ser definidos para las columnas. Estos mantendrán la integridad de los datos por lo que es absolutamente imposible insertar datos que rompan las reglas.

Algunos objetos contienen datos.
Objetos Programáticos tales como store procedure y funciones son código ejecutable.
Vistas y sinónimos son objetos que dan acceso a otros objetos.
Las tablas son estructuras de dos dimensiones que almacenan filas con columnas definidas.
Las tablas existen dentro de un esquema. El nombre del esquema con el nombre de la tabla hacen un identificador único.
Los tipos de dato mas comunes son: VARCHAR2, DATE e INTEGER.
Las tablas pueden ser creadas de nada o partir de una consulta.
Después de la creación de una tabla columnas pueden ser agregadas, eliminadas o modificadas.
La definición de una tabla puede incluir valores default para las columnas.
Los constraint pueden ser definidos en tiempo de creación de la tabla o posteriormente.
Un Constraint puede ser definido en la columna o después de todas las columnas.
Los Constraint definidos después de las columnas pueden ser definidos con mas complejidad.
Una tabla sólo puede tener una clave primaria, pero puede tener varias claves únicas.
Una clave principal es funcionalmente equivalente a la clave única ventaja pero esta ultima no acepta nulos.
Una Constraint UNIQUE permite la inserción de valores NULL.
Constraint Foreign Key definen las relaciones entre las tablas.

CREANDO y UTILIZANDO INDICES.

2013-10-18T14:22:00.002-07:00

Los índices son creados implícitamente cuando Constraints Primary Key y unique son definidos. Si un índice sobre la columna relevante no existe. La sintaxis básica para crear un índice explícitamente es.

CREATE [UNIQUE | BITMAP] INDEX [ schema.]indexname

ON [schema.]tablename (column [, column...] ) ;

El tipo por defecto de un índice es un non-unique, non-compressed, non-reverse key, índice B*TREE. No es posible crear un índice Bitmap Unique (y usted no le gustaría si pudiera-pensar la cuestión de cardinalidad). Los índices son objetos de esquema, y es posible crear un índice en un esquema sobre una tabla que está en otro esquema. Pero la mayoría de las personas encontrara esto como confuso. Un índice Composite es un índice sobre varias columnas. Índices Composite puede ser sobre columnas de diferentes tipos, y las columnas no tienes que ser adyacentes en la tabla.

EN EL TRABAJO

Muchos administradores de bases de datos no consideran buena práctica confiarse sobre la creación implícita de índices. Si el índice es creado explícitamente, el creador tiene control completo sobre las características del índice, que puede ser más fácil para el DBA su gestión posterior.

Considera este ejemplo de creación de tabla e índices, y luego la definición de Constraints:

create table dept(deptno number,dname varchar2(10));

create table emp(empno number, surname varchar2(10),

forename varchar2(10), dob date, deptno number);

create unique index dept_i1 on dept(deptno);

create unique index emp_i1 on emp(empno);

create index emp_i2 on emp(surname,forename);

create bitmap index emp_i3 on emp(deptno);

alter table dept add constraint dept_pk primary key (deptno);

alter table emp add constraint emp_pk primary key (empno);

alter table emp add constraint emp_fk

foreign key (deptno) references dept(deptno);

Los primeros índices creados están marcados como UNIQUE, esto significa que no será posible insertar valores duplicados. Esto no es definido como un Constraint en este punto pero es cierto, sin embargo. El tercer índice no está definió como UNIQUE y por lo tanto, aceptar valores duplicados; este es un índice Composite sobre dos columnas. El cuarto índice es definido como un Índice Bitmap, porque la cardinalidad de la columna es probable que sea baja en proporción a el numero de filas en la tabla.

Cuando los dos primero Constraints Primary Key son definidos, Oracle detectara los índices pre creados y los utilizaran para hacer cumplir las restricciones. Tenga en cuenta que el índice sobre DEPT.DEPTNO no tiene propósito para rendimiento porque la tabla con toda probabilidad sea tan pequeño que el índice nunca será utilizado para recuperar filas (una exploración será más rápida), pero es todavía esencial tener un índice para hacer cumplir el Constraints Primary key.

Una vez que se crean, el uso de índice es completamente transparente y automático. Antes de ejecutar una declaración SQL, el servidor Oracle evaluara todas las formas posibles de ejecutarlo. Algunas de estas formas pueden implicar el uso cualquiera que sea índices que están disponibles; otros no pueden. Oracle hará uso de la información recolectada sobre las tablas y el entorno para tomar la decisión acerca de los índices a usar.

EN EL TRABAJO

El servidor Oracle debe hacer la mejor decisión acerca del uso de índices, pero si está obteniendo errores, es posible para un programador embeber instrucciones, conocido como sugerencias de optimizador, en el código que obligara a utilizar de ciertos índices.

MODIFICANDO Y ELIMINADO INDICES.

Hay un comando ALTER INDEX…, pero no puede ser utilizados para cambiar cualquier de las características descritas en este capítulo: el Tipo (B*TREE o Bitmap) de índice, las columnas, o si es unique o non-unique. El comando ALTER INDEX se encuentra (miente) en el dominio de la administración de la Base de datos y por lo general se utiliza para ajustar las propiedades físicas del índice, no las propiedades lógicas que son de interés para los desarrolladores. Si es necesario cambiar alguna de estas propiedades, el índice debe ser eliminado y crearlo nuevamente. Continuando con el ejemplo en el sección anterior, para cambiar el índice EMP_12 para incluir los cumpleaños de los empleados,

drop index emp_i2;

create index emp_i2 on emp(surname,forename,dob);

Este Índice Composite (compuesto) ahora incluye columnas con diferentes tipos de datos. Las columnas pasaran a ser enumeradas en el mismo orden que son definidas en la tabla, pero esto es de ninguna manera necesaria.

Cuando una tabla es eliminada, todos los índices y Constraints definidos para la tabla se eliminan también. Si un índice fue creado implícitamente mediante la creación de un Constraints, entonces Eliminar el Constraints también eliminara el índice. Si el índice se había creado explícitamente y el Constraint creado posteriormente, entonces si el Constraint fuera eliminado el índice sobrevivirá.

EJERCICIO 9-3

CREAR INDICES.

En este ejercicio, agregara algunos índices a la tabla EX_EMPS, y modificar el índice creado cuando el Constraints Primary Key fue agregado.

1. Conectarse a su base de datos con SQL*PLUS como usuario HR.

2. Determine el nombre y algunas otras características del Índice Primary Key ejecutando esta cosulta:

select index_name,column_name,index_type,uniqueness

from user_indexes natural join user_ind_columns

where table_name='EX_EMPS';

3. Crear un indice compuesto B*TREE sobre el nombre de empleados:

create index ex_name_i on ex_emps (last_name,first_name);

4. Crear indices Bitmap en algunas columnas de baja cardinalidad:

create bitmap index ex_dept_i on ex_emps(department_id);

create bitmap index ex_mgr_i on ex_emps (manager_id);

5. Con el Database Control, mire los índices. La ruta de navegación desde la pagina principal del Database Control tome la ficha Esquema, y entonces dar clic en el link Índices sobre la sección Database Objects. Ingresar HR como el nombre del esquema y EX_EMPS como el nombre del objeto, y dar clic en Go. Los índices serán (cuatro, incluyendo los índices Primary Key creados automáticamente) mostrados.

TIPOS DE OPCIONES DEL INDICE

2013-10-18T14:21:00.002-07:00

Existen seis opciones utilizadas comúnmente que pueden ser aplicadas cuando creamos un índice.

• Unique o Non-Unique.

• Reserve Key.

• Compressed.

• Composite.

• Function Based.

• Ascending o Descending.

Todas estas seis variaciones aplican a los índices B*TREE, pero solo las últimas tres pueden ser aplicadas a los índices Bitmaps.

• Un Índice Unique no permitirá valores duplicados. Non-unique es el default. El atributo unique del índice opera independientemente de un Constraint Unique o Primary Key: la presencia de un Índice Unique no permitirá inserción de valores duplicados incluso si no hay tal Constraint definido. Un Constraint Unique o Primary Key puede utilizar índice Non-Unique; solo sucederá no tener valores duplicados. Esto es, de hecho un requerimiento para un Constraint que es Deferrable (impostergable), ya que puede haber un periodo (antes que las transacciones son confirmadas) cuando los valores duplicados existen.

• Un índice reverse key es construido sobre una versión de la columna llave con sus bytes invertidos: en lugar que indexé “John,” indexara “nhoj” cuando un SELECT es hecho. Oracle invertirá automáticamente el valor de la cadena de búsqueda. Esto es una técnica muy útil para evitar la contención de sistemas multiusuario. Por ejemplo, si muchos usuarios están insertando concurrentemente filas con llaves primarias basadas en un numero de incremento secuencial, todos sus índices insertados se concentraran en lo alto (final) del índice. Mediante las llaves invertidas, la llave índice consecutiva insertada tendera a extenderse a lo largo de todo el rango del índice. Incluso aunque “John” y “Jules” están muy juntas, “nhoj” and “seluj” serán muy muy distantes.

• Un índice compressed (comprimido) almacena valores llaves repetidos solo una vez. El valor por defecto es no compress, lo que significa que su un valor llave no es único, será almacenado una vez por cada ocurrencia, cada uno tiene un único puntero ROWID. Un índice Compressed almacenara la llave una vez, seguido por una cadena de todos los ROWID coincidentes.

• Un índice Composite (compuesto) está basado en la concatenación de dos o más columnas. No hay restricciones sobre los tipos de datos que se mezclan. Si un cadena de búsqueda no incluye todas las columnas, el índice puede todavía ser utilizado-pero si no incluye la extrema columna izquierda, oracle tendrá que utilizar un método skip-scanning que es mucho menos eficiente que si la columnas mas a la izquierda es incluida.

• Un índice function-based está basado sobre el resultado de una función aplicado a una o mas columnas, tales como UPPER (last_name) o to_char(startdate,’ccyy-m-dd’). Una consulta tendrá que aplicar la misma función a la cadena de búsqueda, o oracle no puede ser capaz de utilizar el índice.

Por defecto, un índice es ascending, significa que la llave es almacenada en orden de menor a mayor valor. Un índice descending invierte esto. De hecho, la diferencia no suele ser importante: las entradas en un índice son almacenadas como una lista doblemente ligada por lo que es posible ir de arriba abajo con igual rapidez, pero esto afectara el orden en el cual las filas son regresadas si son recuperadas con un rango de exploración de índice.

INDICE BIPMAP

2013-10-18T14:21:00.000-07:00

En muchas aplicaciones de negocio, la naturaleza de los datos y las consultas es tal que índices B*TREE no son de mucha utilidad. Considere la tabla de ventas para una cadena de supermercados. Almacena un año de datos históricos, que pueden ser analizados en varias dimensiones. La figura 9-6 muestra un simple diagrama entidad relación, que solo cuatro de las dimensiones.

Suponiendo una distribución uniforme de los datos, solo dos de las dimensiones (producto y fecha) tiene una selectividad que es mejor que el criterio de uso general de 2 por ciento a 4 por ciento, que hace un índice que vale la pena. Pero si consultas utilizan predicados de rango (tales como cantidad de ventas en el mes o de una clase de productos de diez o más), entonces ni siquiera estos se clasificaran. Esto es un simple hecho: los índices B*TREE a menudo son inútiles en una entorno Data Warehouse. Una consulta típica podría ser que desee comparar las ventas entre dos tiendas para atender a clientes de una determinada clase de producto en un mes. Podrían bien haber índices B*TREE en las columnas relevantes, pero Oracle ignora como insuficiente selectivo. Esto es que los índices Bitmap están diseñados para.

Un índice Bitmap almacena los ROWIDS asociado con cada valor llave como un Bitmap. El Bitmap para el índice CHANNEL podría tener este aspecto:

WALKIN 11010111000101011101011101.....

DELIVERY 00101000111010100010100010.....

Esto indica que las dos primeras filas fueron ventas a entrega a los clientes, la tercera venta era una entrega, la cuarta venta fue entrega, y asi sucesivamente.

Los Bitmaps para índices de SHOP podrían ser.

LONDON 11001001001001101001010000.....

OXFORD 00100010011000010001001000.....

READING 00010001000100000100100010.....

GLASGOW 00000100100010000010000101.....

Esto indica que las dos primeras ventas fueron en la Tienda de London, la tercera fue en Oxford, la cuarta en Reading, y así sucesivamente. Ahora si esta consulta es recibida;

select count(*) from sales where channel='WALKIN' and shop='OXFORD';

Oracle puede recuperar los dos Bitmaps pertinentes y agregarlas junto con una operación booleana AND:

WALKIN 11010111000101011101011101.....

OXFORD 00100010011000010001001100.....

WALKIN & OXFORD 00000010000000010000000000.....

El resultado de la operación AND muestra que solo el séptima y decima séptima filas califican para la selección. Esta combinación de Bitmaps es muy rápida y puede ser utilizada para implementar complejas operaciones Booleanas con muchas condiciones en muchas columnas utilizando cualquier combinación de operaciones AND, OR y NOT. Una ventaja especial que los índices Bitmaps tienen por arriba que los índices B*TREE es que incluyen valores NULL. En cuanto al índice Bitmap se refiere, NULL es solo otro valor distinto, que tendrá su propio Bitmaps.

En general, Índices Bitmaps deben ser utilizados si:

• La Cardinalidad (el numero de valores distintos) en la columna es baja.

• El numero de filas en la tabla es alto, y

• La columna es utilizada en operaciones de algebra Booleana.

EN EL TRABAJO

Si usted supiera por adelantado cual serian las consultas, entonces usted puede construir Índices B*TREE que trabajarían, tales como un índice compuesto en SHOP y CHANNEL. Pero por lo general no sabe, que es donde la combinación dinámica de Bitmaps da gran flexibilidad

B*TREE INDEXES

2013-10-18T14:19:00.000-07:00

Un índice B*TREE (la B significa “Balanceado”) es una estructura de árbol. El nodo raíz de del árbol punto de muchos nodos en el segundo nivel, que puede apuntar a muchos nodos en el tercer nivel y así sucesivamente. La profundidad necesaria del árbol será determinado en gran medida por el numero de filas en la tabla y la longitud de los valores de llaves del índice.

EN EL TRABAJO

La estructura B*TREE es muy eficiente. Si la profundidad es mayor a tres o cuatro, a continuación, o las llaves índices son muy largos o la tabla tiene billones de filas. Si ninguno de estos es el caso, entonces el índice está en la necesidad de una reconstrucción.

Las hojas nodo del árbol del índice almacenan las llaves de las filas, en orden, cada uno con un puntero que identifica la localización física del registro. Así para recuperar una fila con un índice de búsqueda, si la clausula WHERE se utiliza predicado de igualdad en la columna indexada, Oracle navega abajo del árbol al nodo de hoja que contiene el valor llave deseado, y después utiliza el apuntador para encontrar la fila. Si la clausula WHERE se utiliza un predicado noneequality (como cualquiera de los operadores LIKE, BETWEEN, >, o, <) entonces Oracle puede navegar abajo del árbol para encontrar la primera llave coincidente y luego navegar atraves de los nodos hojas del índice para encontrar el resto de valores que emparejan. Como lo hace, recuperara las filas de la tabla en orden.

El puntero a la fila es el ROWID. El ROWID es una pseudo-columna propiedad de Oracle, que cada fila en cada tabla tiene. Cifrada dentro de la dirección física de la fila. Como ROWID no es parte del estándar SQL, nunca son visibles a una declaración SQL, pero usted puede ver y usar si lo desea. Esto es una muestra en la figura 9-5.

Una fila ROWID es globalmente única. Cada fila en cada tabla en la base de datos completa tendrán ROWID diferentes. El cifrado ROWID da la dirección física de la fila. De ella, Oracle puede calcular que archivo del sistema operativo, y donde en el archivo esta la fila, e ir directamente a ella.

Los índices B*Tree son una forma muy eficiente de recuperar filas si el numero de filas necesarias es bajo en proporción al número total de filas en la tabla y si la tabla es grande. Considere esta declaración:

select count(*) from employees where last_name between 'A%' and 'Z%';

Esta clausula WHERE es lo suficientemente amplia que incluirá todas las filas en la tabla. Sería mucha más lenta para buscar en el índice para encontrar los ROWIDS y luego utilizar los ROWIDS para buscar las filas que explorar la tabla completa. Después de todo. Es la tabla entera que es necesaria. Otro ejemplo seria si la tabla fuera muy pequeña que una lectura de disco podría analizarla completamente; no habría punto en la lectura del primer índice.

Se dice a menudo que si la consulta va a recuperar más de 2 o 4 por ciento de las filas, entonces una exploración completa de tabla será más rápida. Una importante excepción a esto es si el valor especificado en la clausula WHERE es nulo. NULL no van en el índice B*TREE, asi que una consulta tal como esta:

select * from employees where last_name is null;

Siempre resultara una exploración complete de la tabla. Hay poco valor crear un índice B*TREE en una columna con pocos valores únicos, no será lo suficiente selectiva: la proporción de la tabla que será recuperada para cada llave distinta será demasiado alto. En general, índices B*TREE debe ser utilizados si:

• La cardinalidad (el numero de valores distintos) en la columna es alta.

• El numero de filas de la tabla es alta, y

TIPOS DE INDICES

2013-10-18T14:15:00.000-07:00

Oracle soporta varios tipos de índices, que tienen algunas variaciones. Los dos tipos de índices de interés aquí son el Índice B*Tree, que es el tipo de índice por defecto y el índice Bitmap. Como una regla general, los índices mejoran el rendimiento para la recuperación pero reduce el rendimiento de las operaciones DML. Esto se debe a que los índices deben ser mantenidos. Cada vez que una fila es insertada a la tabla, una nueva llave debe ser insertada en todos los índices sobre la tabla, que coloca una tensión adicional sobre la Base de Datos. Por esta razón, en los sistemas de procesamiento de transacciones se acostumbra a mantener el numero de índices lo más bajo posible (quizás nomas que esos necesarios para los Constraints) y en los sistemas de consultas intensivas tales como un Data Warehouse para crear tantos como podría ser útil.

Los Indices

2013-10-18T14:13:00.001-07:00

Los índices tienen dos funciones: hacer cumplir los Constraint Primary Key y Unique, y mejorar el rendimiento. Una estrategia de aplicación de indexación es crítica para el rendimiento. No hay delimitación clara de cuyo dominio de índices se encuentra dentro de administración de índices. Cuando los analistas de negocios especifican reglas de negocio que serán implementadas como restricciones, son en efecto especificaciones de índices. Los administradores de la Base de datos monitorearan la ejecución de código que corre en la Base de datos, y harán recomendación de índices. El desarrollador, que debe tener la mejor idea de lo que está pasando en el código y la naturaleza de los datos, también participará en el desarrollo de la estrategia de indexación

Un Constraint Unique también requiere un índice. La diferencia de un Constraint Primary Key es que la columna del Constraint Unique puede permitir nulos, tal vez en muchas filas. Esto no afecta a la creación y uso del índice: nulos no van en los índices B*Tree, como es descrito en la siguiente sección tipos de índices.

Constraint Foreign Key son forzados por medio de índices, pero el índice debe existir en la tabla padre, no necesariamente en la tabla para el cuela se define el Constraints. Un Constraint Foreign Key se refiere a una columna en la tabla hija con la llave principal o una Llave Unique en la tabla padre. Cuando una fila es insertado en la tabla hijo, oracle va ha hacer una búsqueda en el índice en la tabla padre para confirmar que hay una fila coincidente antes de permitir insertar. Sin embargo, usted debería siempre crear índices en las columnas Foreign Key en la tabla hijo por razones de rendimiento: un DELETE en la tabla padre será mucho más rápido si Oracle puede utilizar un índice para determinar si hay alguna referencia a las filas en la tabla hijo de la fila que está siendo eliminada.

Los índices son críticos para el rendimiento. Cuando ejecutamos cualquier sentencia SQL que incluye una clausula WHERE, Oracle tiene que identificar que filas de la tabla deben ser seleccionadas o modificadas. Si no hay un índice en la columna referenciada en la clausula WHERE, la única manera de hacer esto es con una exploración completa de la tabla. Una Exploración completa de tabla lee cada registro de la tabla, con el fin de encontrar las filas correspondientes. Si la tabla tiene billones de filas, esto puede tomar horas. Si hay un índice en la columna correspondiente, oracle puede buscar en el índice en su lugar. Un índice es una lista ordenada de valores claves, estructurada de una manera que hacer la búsqueda más eficiente. Con cada valor clave es un puntero a la fila en la tabla. La localización de filas relevantes por medio de un índice de búsqueda es mucho más rápido que usar exploración completa de tabla, si la tabla esta sobre cierto tamaño y la proporción de filas a ser recuperadas es por debajo de un cierto valor.

Para tablas pequeñas, o para una clausula WHERE que recuperara una gran fracción de las filas de la tabla, una exploración completa será más rápido: usted puede (generalmente) confiar en Oracle para tomar la decisión correcta con respecto a utilizar un índice, basada en la información que recolecta de la base de datos sobre las tablas y las filas dentro de ellas.

Una segunda circunstancia donde los índices pueden ser utilizados es para clasificación y ordenamiento. Una sentencia SELECT que incluye palabras como ORDER BY, GROUP BY o UNION (y algunos otros) debe ordenar las filas en orden, a menos que haya un índice, que puede devolver las filas en el orden correcto sin necesidad de ordenar primero.

Una tercera circunstancia cuando los índices pueden mejorar el rendimiento es cuando las tablas se unen (join), pero de nuevo Oracle tiene una opción: dependiendo del tamaño de las tablas y los recursos disponibles de memoria, puede ser más rápido escanear las tablas en memoria y unirlas ahí, en lugar del uso de índices. La técnica Nested Loop Join (Bluce Anidado) pasa atraves de una tabla utilizando un índice en la otra tabla para localizar las filas que coincidan: esto es usualmente una operación intensiva de disco. Un técnica hash join (unión de comprobación) lee toda la tabla en memoria, convierte esta en una tabla hash, y utiliza un algoritmo hasging para localizar filas coincidentes; esto es mas memoria y CPU intensivo. Un sort merge joins ordena las tablas sobre la columna JOIN y luego y luego las combina entre si: esto es a menudo en compromiso entre disco, memoria y recursos de CPU. Si no hay índices, a continuación, Oracle es muy limitada en la combinación de técnicas disponibles.

Los índices ayudaran a declaraciones SELECT, y también UPDATE, DELETE o MERGER que utilicen clausula WHERE, pero retrasaran a declaraciones INSERT.

CREAR INDICES

2013-10-18T14:07:00.001-07:00

Utilizando Secuencias

2013-10-18T14:04:00.001-07:00

Para utilizar una secuencia, una sesión puede seleccionar el siguiente valor de la columna con NEXTVAL, lo que obliga a la secuencia a incrementar, o el último valor emitido a la sesión con la pseudo columna CURRVAL. El NEXTVAL será único a nivel global: cada sesión que selecciona conseguirá un incremento, un valor para cada SELECT. El CURRVAL será constante durante una sesión hasta que se selecciona NEXTVAL de nuevo. No hay manera de saber cuál es el último valor publicado por una secuencia: siempre se puede obtener el siguiente valor incrementando con NEXTVAL, y siempre se puede recuperar el último valor emitido a su sesión con CURRVAL, pero no se puede encontrar el último valor emitido.

El CURRVAL de una secuencia es el último valor publicado para la sesión actual, no necesariamente el último valor publicado. No se puede seleccionar el CURRVAL hasta después de seleccionar el NEXTVAL.

Un uso típico de secuencias es para valores de clave primaria. En este ejemplo se utiliza una secuencia order_seq para generar números de referencia únicos y LINE_SEQ para generar números de líneas únicas para los elementos de línea de la orden. En primer lugar crear las secuencias, que es una operación excepcional:

create sequence order_seq start with 10;

create sequence line_seq start with 10;

insert into orders (order_number,order_date,customer_number)

values (order_seq.nextval,sysdate,'1000');

insert into order_lines (order_number,line_number,item_number,quantity)

values (order_seq.currval,line_seq.nextval,'A111',1);

insert into order_lines (order_number,line_number,item_number,quantity)

values (order_seq.currval,line_seq.nextval,'B111',1);

commit;

La primera instrucción INSERT genera un pedido con un número de referencia único extraído de la secuencia order_seq para el cliente 1000. La segunda y tercera instrucciones INSERT, utilizando el número de pedido emitido previamente order_seq como clave externa para conectar las líneas de la orden, y los siguientes valores de LINE_SEQ para generar un identificador único para cada línea. Por último, se confirma la transacción.

Una secuencia no está ligado a ninguna tabla. En el ejemplo anterior, no habría ninguna razón técnica para no utilizar una secuencia para generar valores para las claves primarias de la orden y de las líneas.

Un COMMIT no es necesario para hacer que el incremento de una secuencia permanente, es permanente y hecho visible para el resto del mundo el momento en que sucede. No se puede hacer Rollback. Por esta razón, siempre habrá lagunas en la serie. Las diferencias serán mayores si la base de datos se ha reiniciado y se ha utilizado la cláusula CACHE. Todos los números que se han generado y almacenado en caché y pendientes de emisión se perderán cuando la base de datos se cierra. En el siguiente reinicio, el valor actual de la secuencia será el último número generado, no será la última emisión. Así, con la caché por defecto de 20, cada inicio de apagado / perderá hasta 20 números.

Si los analistas de negocios han declarado que no debe haber lagunas en una secuencia, entonces se debe utilizar otro medio de generar números únicos. Para el ejemplo anterior de levantar pedidos, el número de pedido actual podría ser almacenada en esta tabla y se inicializa a 10:

create table current_on(order_number number);

insert into current_on values(10);

commit;

update current_on set order_number=order_number + 1;

insert into orders (order_number,order_date,customer_number)

values ((select order_number from current_on),sysdate,'1000');

commit;

Modificar una Secuencia

ALTER SEQUENCE sequencename

[INCREMENT BY number]

[START WITH number]

[MAXVALUE number | NOMAXVALUE]

[MINVALUE number | NOMINVALUE]

[CYCLE | NOCYCLE]

[CACHE number | NOCACHE]

[ORDER | NOORDER] ;

Este comando ALTER es el mismo que el comando CREATE, con una excepción: no hay manera de establecer el valor inicial. Si desea reiniciar la secuencia, la única manera es caer y volver a crearlo.

alter sequence order_seq cache 1000;

drop sequence order_seq;

Crear, Mantener y Utilizar Secuencias

2013-10-15T13:29:00.001-07:00

Una secuencia es una estructura para la generación de valores enteros únicos. Sólo una sesión puede leer el siguiente valor y así obligarla a incrementar. Este es un punto de la serialización, por lo que cada valor generado será único.

Las secuencias son una valiosa herramienta para la generación de Llaves Primarias. Muchas aplicaciones necesitan valores de Llave Primaria generadas automáticamente. El mecanismo de secuencia es independiente de las tablas, y el procesamiento de Commit y Rollback. Esto significa que una secuencia puede emitir miles de valores únicos de un minuto, mucho más rápido que cualquier otro método que implica la selección de una columna de una tabla, actualización, y confirmación de un cambio. El numero se incrementa consecutivamente en orden cada vez que una selección es realizada y el numero incrementa globalmente no solo dentro de una sesión.

Crear Secuencias

La sintaxis completa para crear una secuencia es la siguiente:

CREATE SEQUENCE [schema.]sequencename

[INCREMENT BY number]

[START WITH number]

[MAXVALUE number | NOMAXVALUE]

[MINVALUE number | NOMINVALUE]

[CYCLE | NOCYCLE]

[CACHE number | NOCACHE]

[ORDER | NOORDER] ;

Para crear una secuencia es muy simple:

Opciones de Sequence

INCREMENT BY	¿Cuánto mayor (o menor) que el último número emitido debe ser el siguiente número? El valor predeterminado es +1, pero puede ser cualquier número positivo (o número negativo para una secuencia descendente).
START WITH	El punto de inicio de la secuencia: el número emitido por la primera selección. El valor predeterminado es 1, pero puede ser cualquier otro.
MAX VALUE	El número más alto de una secuencia ascendente antes de generar un error o volver a su valor START WITH. El valor predeterminado es sin límite máximo.
MIN VALUE	El número más bajo de una secuencia descendente antes de generar un error o volver a su valor START WITH. El valor predeterminado es sin mínimo.
CYCLE	Controla el comportamiento al alcanzar a MAXVALUE o MINVALUE. El comportamiento predeterminado es dar un error, pero si se especifica CYCLO la secuencia volverá a su posición inicial y repetirse.
CACHE	Para rendimiento, Oracle puede pre emitir valores de la secuencia y cachearlos o guardarlos y luego emitir los valores a los usuarios. El comportamiento por defecto es generar 20 y guardarlos
ORDER	Relevante para una Base de Datos en Cluster: ORDER forza a las instancias para coordinar el incremente.

Ajustes apropiados para INCREMENT BY, START WITH, MAXVALUE o MINVALUE vendrán de los analistas de negocio. Es muy raro y vuelva a ser utilizada una secuencia, ya que permite la edición secuencia de valores duplicados. Si se está utilizando la secuencia para generar valores de clave principal, CYCLE sólo tiene sentido si hay una rutina en la base de datos que va a eliminar filas.

Almacenamiento en caché los valores de secuencia es vital para el rendimiento. Selección de una secuencia es un punto de serialización en el código de la aplicación: sólo una sesión puede hacer esto a la vez. El mecanismo es muy eficiente: es mucho más rápido que el bloqueo de una fila, la actualización de la fila, y luego abrir con un COMMIT. Pero aún así, la selección de una secuencia puede ser una causa de la discordia entre las sesiones. La palabra clave CACHE ordena a Oracle que Pregenere números de secuencia por lotes. Esto significa que se pueden emitir más rápido que si tuvieran que ser generada bajo demanda.

Crear Sinónimos Públicos y Privados

2013-10-15T12:54:00.001-07:00

Un sinónimo es un nombre alternativo para un objeto. Si existieran sinónimos para los objetos, entonces cualquier sentencia SQL puede dirigirse al objeto, ya sea por su nombre real, o su sinónimo. Esto puede parecer trivial. No lo es. El uso de sinónimos significa que una aplicación puede funcionar para cualquier usuario, independientemente del esquema propietario, las vistas y tablas o incluso en qué base de datos las tablas residen. Ejemplo:

select * from hr.employees@prod;

El usuario que emite la sentencia debe conocer que la tabla Employees pertence al esquema HR en la base de datos identificada por el Database Link. Si un sinónimo ha sido creado con esta sentencia:

create public synonym emp for hr.employees@prod;

Entonces todos los usuarios solo necesitan escribir lo siguiente:

select * from emp;

Esto da Independencia de datos y Transparencia en la localización. Tablas y Vistas pueden ser renombrados y reubicados si tener que cambiar nada de código. Solo los sinónimos tienen que ser reajustados.

Además de sentencias SELECT, instrucciones DML pueden dirigirse a los sinónimos como si se trataran de los objetos al que se refieren.

Sinónimos Privados son Objetos de Esquema. Estos deben estar en su propio esquema, o deben ser cualificados con su nombre de esquema. Sinónimos Públicos existen independientemente del Esquema.

Un sinónimo público puede ser referido por cualquier usuario al que se le ha concedido permiso para verlo sin la necesidad de cualificarlo con el nombre de esquema. Sinónimos Privados debe ser un nombre único dentro de su esquema. Sinónimos Públicos pueden tener el mismo nombre como un objeto de esquema. Cuando ejecutamos sentencias que van dirigidos a objetos sin cualificar un esquema, Oracle buscara al objeto en el esquema local, y solo si no es encontrado, lo buscara como un Sinónimo Publico.

La sintaxis para crear un Sinónimo es la siguiente:

CREATE [PUBLIC] SYNONYM synonym FOR object;

Un usuario necesitara tener asignado permisos para crear sinónimos privados y permisos para crear sinónimos públicos. Usualmente. Solo el administrador de bases de datos puede crear y eliminar sinónimos públicos. Esto es porque su presencia o ausencia afectara a todos los usuarios.

El “public” en “public synonym” significa que no es un objeto de esquema y no puede por lo tanto se cualificado con un nombre de esquema. Esto no significa que todo mundo tiene permisos para utilizarlo.

Para eliminar un sinónimo:

DROP [PUBLIC] SYNONYM synonym;

Si el objeto al cual el sinónimo se refiere es eliminado, el sinónimo continua existiendo. Cualquier intento de uso devuelve un error. En este aspecto, los sinónimos comparte el mismo compartimiento como las vistas. Si el objeto es nuevamente creado, el sinónimo debe ser recompilado para su uso. Esto sucederá automáticamente cuando se utilizado nuevamente o lo podemos realizar explícitamente:

ALTER SYNONYM synonym COMPILE;

CREATE VIEW, ALTER VIEW Y DROP VIEW

2013-10-14T11:34:00.001-07:00

La sintaxis es la siguiente:

CREATE [OR REPLACE] [FORCE | NO FORCE] VIEW

[esquema.]nombrevista [(alias) [,alias]…)]

AS subquery

[WITH CHECK OPTION [CONSTRAINT constraintname]]

[WITH READ ONLY [CONSTRAINT constraintname]] ;

Tenga en cuenta que las vistas son objetos de esquema. Las palabras claves opcionales son:

OR REPLACE. Si la vista ya existe. Primero será eliminada y luego será creada.

FORCE o NOFORCE. La palabra clave FORCE creara la vista incluso si la tabla detalle en el subquery no existe. NOFORCE es el comportamiento por defecto. Causara error si el detalle no existe.

WITH CHECK OPTION. Esto tiene que ver con DML. Si la subconsulta contiene una clausula WHERE, esta opción evitará la inserción de filas que no se pueden ver en la vista o cambios que harían que una fila de desaparece de la vista. De forma predeterminada, esta opción no está habilitada, lo que puede dar resultados desconcertantes.

WITH READ ONLY. Previene cualquier DML a través de la vista.

CONSTRAINT constraintname. Esto puede ser usado para nombrar las restricciones WITH CHECK OPTION y WITH READ ONLY para que los mensajes de error cuando las restricciones causan fallos, sean más comprensible.

Además, un conjunto de nombres de alias puede ser proporcionar por los nombres de las columnas de la vista. Si no se proporciona, las columnas se nombran después de las columnas de la tabla o alias especificados en la subconsulta

Ejemplos:

create view v1region as select * from regions where id=1

Esta Vista permite la inserción de filas que no pueden verse en la vista.

create view v1region as select * from regions where id=1 with check option;

Esta vista no permite insertar filas que no se vean en la vista.

El uso principal del comando ALTER VIEW es para compilar la vista. Una vista debe ser compilada exitosamente antes que pueda ser utilizada. Cuando una vista es creada, Oracle comprueba que las tablas detalle y las columnas necesarias sobre la cual la vista está basada exista. Si estas no existen, la compilación falla y la vista no será creada. A menos que se utilice la opción FORCE. En este caso, la vista será creada pero no será usable hasta que la tabla o columnas a la cual se refiere sean creadas y la vista sea compilada exitosamente. Cuando una vista inválida es consultada, Oracle intenta compilarla automáticamente. Si la compilación es exitosa porque el problema se ha solucionada, incluso si el usuario no conoce el problema. Excepto si la consulta tome un poco más de tiempo. En términos generales, se debe compilar manualmente la vista y que compile con éxito. Y no dejar que los usuarios descubran los errores.

No es posible ajustar las definiciones de columnas de una vista después de la creación en una Tabla la forma en que las columnas de una tabla se pueden cambiar. La vista debe quitarse y volver a crear. El comando DROP es el siguiente:

DROP VIEW [esquema.]viewname;

Mediante la palabra OR REPLACE con el comando CREATE VIEW, la vista será automáticamente eliminada y posteriormente creada.

Porque Utilizar Vistas

2013-10-14T10:11:00.001-07:00

Seguridad.

Simplificar SQL.

Prevenir errores.

Hacer más comprensible los datos.

Rendimiento.

Vistas para Reforzar la Seguridad

Puede ser que los usuarios sólo deben ver ciertas filas o columnas de una tabla. Hay varias maneras de hacer cumplir esto, una Vista a menudo es la más sencilla. Tenga en cuenta el uso de los calificadores de esquema para la tabla como la fuente de los datos y la vista: las Vistas son objetos de esquema y pueden sacar sus datos de las tablas en el mismo esquema o de otros esquemas. Si no se especifica el esquema, serán del esquema en el cual se encuentra actualmente. La vista se puede unir a otras vistas o tablas como si se tratara de una tabla.

Vistas para simplificar a los Usuarios SQL.

Será mucho más fácil para los usuarios consultar los datos, si el trabajo duro (tales como JOINS o Agregaciones) está hecho para ellos por el código que define la vista.

Vistas para Prevenir Errores

Es imposible evitar que los usuarios cometan errores, pero las vistas bien construidas pueden prevenir algunos errores derivados de la falta de comprensión de cómo se deben interpretar los datos. Una vista puede ayudar a presentar los datos de una manera que no es ambigua.

Vistas para hacer los Datos más Comprensibles.

Las estructuras de datos en una base de datos serán tablas normalizadas. No es razonable esperar que los usuarios comprendan las estructuras normalizadas. Como ejemplo de la Suite Oracle E-Business , un "Cliente " en el módulo de Cuentas por Cobrar es de hecho una Entidad que consiste en información distribuida a través de las Tablas HZ_PARTIES, HZ_PARTY_SITES, HZ_CUST_ACCTS_ALL, y muchas más. Todas estas tablas están vinculadas por relaciones Primary Ley- Foreign Key, pero estos no están definidos en cualesquiera identificadores visibles para los usuarios (por ejemplo, un número de cliente ) : se basan en las columnas de los usuarios nunca ven que tienen valores generados internamente a partir de secuencias . Las formas y los informes que se utilizan para recuperar información de los clientes no abordan estas tablas directamente, todo el trabajo a través de puntos de vista. Pero estos no están definidos en cualesquiera identificadores visibles para los usuarios: se basan en columnas de los usuarios que nunca ven, que tienen valores generados internamente a partir de Secuencias. Las formas y los Reportes que se utilizan para recuperar información de los clientes no abordan las tablas directamente, todo el trabajo es a través de Vistas.

Además de presentar los datos a los usuarios en una forma comprensible, el uso de Vistas para proporcionar una capa de abstracción entre los objetos vistos por los usuarios y los objetos almacenados dentro de la base de datos puede ser muy valioso para el trabajo de mantenimiento.

Vistas para mejorar el Rendimiento

La instrucción SELECT detrás de un punto de vista puede ser optimizada por los programadores, por lo que los usuarios no tienen que preocuparse por el código de tuning. Puede haber muchas posibilidades para conseguir el mismo resultado, pero algunas de las técnicas pueden ser mucho más lentas que otros.

Teóricamente, siempre se puede confiar en el optimizador de Oracle para encontrar la mejor forma de ejecutar una sentencia SQL, pero hay casos en los que se equivoca. Si los programadores saben qué técnica es mejor, se puede indicar al optimizador.

Vistas Simples y Complejas

Clasificación de Vistas Simples y Complejas, la clasificación está relacionada a que si pueden ser ejecutadas sentencias DML contra estas.

Vista Simple, se basa de una tabla, no utiliza funciones, y no hace agregaciones.

Vista Compleja, se basa de la unión de varias tabla, utiliza funciones y desarrolla agregaciones.

A menudo no es posible ejecutar INSERT, UPDATE o DELETE contra una vista compleja. El mapeo de las filas en la Vista a las filas de la tabla detalle (s) que no siempre es posible determinar en un uno-a-uno, que es necesaria para las operaciones de DML. Por lo general, es posible ejecutar DML contra una vista simple, pero no siempre. Por ejemplo, si la vista no incluye una columna que tiene una restricción NOT NULL en la tabla, entonces un INSERT a través de la vista puede no tener éxito (a menos que la columna tiene un valor por defecto). Esto puede producir un efecto desconcertante porque el mensaje de error referencia a una tabla y una columna que no se mencionan en la declaración.

Crear Vistas Simples y Complejas

2013-10-14T10:10:00.001-07:00

Vistas y Sinónimos no almacenan datos, sino que proporcionan una capa de abstracción entre los usuarios y los datos. Las Tablas, Vistas y Sinónimos comparten el mismo espacio de nombres.

Las secuencias son un mecanismo para generar números únicos. En muchas Bases de Datos, valores de la Llave Primaria se definen como un número único. Una secuencia puede emitir dichos números en demanda, sin que los programadores necesitan preocuparse acerca de si realmente son únicos.

Para el usuario, una Vista parece una Tabla: Una estructura bidimensional de filas con columnas, con las cuales el usuario puede ejecutar sentencias SELECT y DML. La vista es simplemente una declaración SELECT. Cualquier instrucción SELECT devuelve un conjunto bidimensional de filas. Si se guarda la instrucción SELECT en una vista, entonces, cada vez que el usuario consulta o actualiza las filas de la vista, la sentencia se ejecuta, y el resultado se presenta a los usuarios como si fuera una tabla. La instrucción SELECT en la que se basa una vista puede ser cualquier cosa. Puede ser JOINS, Agregaciones o hacer Ordenamientos; absolutamente cualquier cosa que es legal en el comando SELECT se puede utilizar. Sin embargo, si la vista es Compleja, sólo SELECT se pueden ejecutar contra ella. En una Vista Simple se pueden utilizar DML’s y SELECT. Como es de espera en una Vista Simple, son basadas sobre sentencias SELECT sumamente sencillas. Vistas complejas son basadas sobre sentencias más complejas.

Definición de restricciones

2013-10-12T06:06:00.000-07:00

Los Constraint pueden ser definidas al crear una tabla o agregan a la tabla posteriormente. Al definir las restricciones a la hora de creación de la tabla, la restricción puede ser definido de acuerdo con la columna a la que se refiere o al final de la definición de la tabla. Existe una mayor flexibilidad para el uso de la última técnica. Por ejemplo, es imposible definir un Constraint foreign key que hace referencia a dos columnas, o un constraint Check que hace referencia a cualquier columna distinta de verse limitados si la restricción se define de acuerdo, pero ambos son posibles si la restricción es definida en el final de la tabla.

Constraint CHECK

2013-10-12T06:02:00.003-07:00

Un Constraint CHECK puede ser utilizado para obligar simples reglas. tales como que el valor introducido en una columna debe estar dentro de un rango de valores. La regla debe ser una expresión que evaluará a TRUE o FALSE. Las reglas se refieren a los valores absolutos registrados como literales o para otras columnas de la misma fila y se puede hacer uso de algunas funciones. Los Constraint CHECK que desee se puede aplicar a una columna, pero no es posible utilizar una subconsulta para evaluar si un valor es permisible o utilizar funciones como SYSDATE .

Constraint FOREIGN KEY

2013-10-12T06:02:00.001-07:00

Un Constraint Foreign Key es definido en la Tabla Hijo o Tabla secundaria de una relacion Padre-Hijo.El Constraint nomina una columna en la tabla hijo que corresponda a la columna Llave Primaria de la tabla Padre. Las columnas no tienen que tener los mismos nombres, pero tienen que ser del mismo tipo de datos. Los Constraint Foreign Key definen la estructura relacional de la base de datos: las relaciones muchos-a-uno que conectan las tablas, en su tercera forma normal.

Si la tabla Padre tiene un Constraint UNIQUE en lugar de Constraint PRIMARY KEY, estas columnas pueden ser utilizadas como base de los Constraint FOREIGN KEY, aun que sean Nullable.

Solo un Constraint UNIQUE permite valores NULL en la columna restringida. Lo mismo ocurre con un Constraint FOREIGN KEY. Puede insertar filas en la tabla Hijo con Llave Externa NULL, incluso si no hay una filas de la tabla Padre con un valor NULL. Esto crea filas huérfanas y puede causar confusión terrible. Como regla general, todas las columnas de un Constraint UNIQUE y todas las columnas de un Constraint FOREIGN KEY se definen mejor con NOT NULL.

El intento de inserción de una fila de la tabla Hijo para la que no hay ninguna fila coincidente en la tabla padre le dará un error. Del mismo modo, eliminar una fila de la tabla padre le dará un error si ya hay filas que se refieren a él en la tabla hijo. Hay dos técnicas para cambiar este comportamiento. En primer lugar, el Constraint puede ser creado como ON DELETE CASCADE. Esto significa que si se elimina una fila de la tabla padre, Oracle buscará en la tabla hijo todas las filas coincidentes y eliminarlos también. Esto sucederá de forma automática. Una técnica menos drástica es la creación de la restricción como ON DELETE SET NULL . En este caso, si se elimina una fila de la tabla padre, Oracle buscará en la tabla hijo todas las filas coincidentes y establecer las columnas de clave externa en null. Esto significa que quedarán huérfanas las filas secundarias, pero seguirá existiendo. Si las columnas de la tabla hija también tienen un Constraint NOT NULL, entonces la eliminación de la tabla Padre producirá un error.

No es posible hacer un DROP o TRUNCATE a la tabla Padre en una relación de clave externa, incluso si no hay filas en la tabla hijo. Esto sigue siendo válido si el ON DELETE SET NULL u ON DELETE CASCADE cláusulas fueron utilizados. Una variante del Constraint foreign Key es la referencia a el mismo Constraint Foreign Key. Esto define una condición en la que existen los padres y las filas secundarias en la misma tabla.

Un constraint Foreign Key en una tabla hija debe referenciar las columnas de una tabla padre y estas deben tener Constraint UNIQUE o PRIMARY KEY.

Constraint PRIMARY KEY

2013-10-12T05:29:00.001-07:00

La Llave Primaria es el medio para localizar una fila en una tabla. El paradigma de la base de datos relacional incluye un requisito de que cada tabla debe tener una Llave Primaria una columna (o combinación de columnas) que se puede utilizar para distinguir cada fila. La base de datos Oracle se desvía del paradigma permitiendo tablas sin claves principales.

La aplicación de un Constraint PRIMARY KEY es, la unión de un Cnstraint UNIQUE y un Constrant NOT NULL. Las columnas de la Llave deben tener valores únicos, y no pueden ser nulo. Al igual que con Constraint UNIQUE un índice debe existir en la columna restringida (s). Si este no existe, se creará un índice cuando se define el Constraint. Una tabla sólo puede tener una Llave Primaria. Trate de crear un segundo, y obtendrá un error. Una tabla puede, sin embargo, cualquier número de Constraint UNIQUE y columnas NOT NULL, por lo que si hay varias columnas que los analistas de negocios han decidido debe ser único y pobladas, una de ellas se puede designar la Llave Principal y los otros UNIQUE y NOT NULL.

Un Constraint PRIMARY KEY es la unión de un Constraint UNIQUE y NOT NULL.

Constraint NOT NULL

2013-10-12T05:17:00.001-07:00

El Constraint NOT NULL obliga a que se ingresen valores a una columna determinada, esta columna no puede ser nullable. NOT NULL se definen por columna, si el requisito de negocio es que un grupo de columnas debe tener valores, no se puede definir un Constraint NOT NULL para todo el grupo, pero en su lugar debe definir un Constraint NOT NULL por columna. Cualquier intento de insertar una fila sin especificar valores para las columnas restringidas con Constraint NOT NULL en un error surgira.

Constraint UNIQUE

2013-10-11T15:56:00.003-07:00

Un Constraint UNIQUE nomina una columna o un conjunto de columnas para el cual el valor debe ser diferente para cada fila en la tabla. Si se basa sobre solo una columna, esta columna es conocida como llave(Key). Si el Constraint está compuesto por más de una columna (Constraint UNIQUE – Llave Compuesta Composite Key). Las columnas no han de ser del mismo tipo o estar adyacentes en la estructura de la tabla.

Una rareza del Constraint UNIQUE es que es posible ingresar valores NULL en las columnas key. De hecho es posible tener cualquier número de filas con valores nulos en sus columnas key. Este constraint garantiza que solo una fila tendrá un valor único a menos que se refiere a valores NULL que pueden ser varias filas las que lo tengan.

El Constraint UNIQUE es realizado por un Indice. Cuando se define un Constraint UNIQUE, Oracle buscará un índice en la columna Key, y si ésta no existe, se creará. Entonces cada vez que se inserta una fila, Oracle buscará el índice para ver si los valores de las columnas key ya existen: si ya existen, el registro se rechazara. La estructura de estos índices (conocido como B * Tree Index) no incluye valores NULL, por lo que se permite muchas filas con NULL, simplemente estas no estan en el índice.Mientras que el primer objetivo del índice es hacer cumplir el Constraint, tiene un efecto secundario: mejorar el rendimiento si las columnas de clave se utilizan en las cláusulas WHERE de SQL. Sin embargo, la selección WHERE key_column is null no utiliza el índice, ya que no incluye los valores Null y por lo tanto siempre resultará en una exploración de toda la tabla.

Tipos de Constraint

2013-10-11T15:55:00.003-07:00

Los tipos de Constraint que soporta la Base de Datos Oracle, son los siguientes:

UNIQUE

NOT NULL

PRIMARY KEY

FOREIGN KEY

CHECK

Los Constraint tienen nombres. Una Buena práctica sería especificarlos de acuerdo a la conversión de nombres, sino es especificado un nombre, Oracle genera uno automáticamente.

Constraint

2013-10-11T15:55:00.001-07:00

Los Constraint son una forma mediante la cual la Base de Datos puede imponer reglas de negocio. Y garantiza que los datos cumplen al modelo entidad - relación determinado por los analistas de negocios que definen las estructuras de datos de la aplicación. Cuando cualquier sentencia DML es ejecutado contra una tabla con Constraint, si el DML viola el Constraint, entonces la sentencia será revertida(Rollback) automáticamente. Recuerde que una sentencia DML que afecta muchas filas podría tener éxito parcialmente antes que llegue un problema con una fila. Si la sentencia es parte de una transacción multisentencia(muchas sentencias), entonces las sentencia que ya ha sido afectadas exitosamente permanecerán intactas pero sin confirmar.