Ir al contenido principal

Entradas

Mostrando entradas de octubre 18, 2013

Resumen

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, gene

RESUMEN

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

CREANDO y UTILIZANDO INDICES.

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

TIPOS DE OPCIONES DEL INDICE

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

INDICE BIPMAP

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 deter

B*TREE INDEXES

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 h

TIPOS DE INDICES

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

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 n

CREAR INDICES

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

Utilizando Secuencias

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 s