CONSULTAS AVANZADAS

La unión de tablas

Esta operación se utiliza cuando tenemos dos tablas con las mismas columnas y queremos obtener una nueva tabla con las filas de la primera y las filas de la segunda. En este caso la tabla resultante tiene las mismas columnas que la primera tabla (que son las mismas que las de la segunda tabla). Por ejemplo tenemos una tabla de libros nuevos y una tabla de libros antiguos y queremos una lista con todos los libros que tenemos. En este caso las dos tablas tienen las mismas columnas, lo único que varía son las filas, además queremos obtener una lista de libros (las columnas de una de las tablas) con las filas que están tanto en libros nuevos como las que están en libros antiguos, en este caso utilizaremos este tipo de operación. Cuando hablamos de tablas pueden ser tablas reales almacenadas en la base de datos o tablas lógicas (resultados de una consulta), esto nos permite utilizar la operación con más frecuencia ya que pocas veces tenemos en una base de datos tablas idénticas en cuanto a columnas. El resultado es siempre una tabla lógica. Por ejemplo queremos en un sólo listado los productos cuyas existencias sean iguales a cero y también los productos que aparecen en pedidos del año 90. En este caso tenemos unos productos en la tabla de productos y los otros en la tabla de pedidos, las tablas no tienen las mismas columnas no se puede hacer una union de ellas pero lo que interesa realmente es el identificador del producto (idfab,idproducto), luego por una parte sacamos los códigos de los productos con existencias cero (con una consulta), por otra parte los códigos de los productos que aparecen en pedidos del año 90 (con otra consulta), y luego unimos estas dos tablas lógicas. El operador que permite realizar esta operación es el operador UNION. Existen distintos tipos de composición, aprenderemos a utilizarlos todos y a elegir el tipo más apropiado a cada caso. Los tipos de composición de tablas son: . El producto cartesiano . El INNER JOIN . El LEFT / RIGHT JOIN El operador UNION sirve para obtener a partir de dos tablas con las mismas columnas, una nueva tabla con las filas de la primera y las filas de la segunda. La sintaxis es la siguiente: SELECT idfab,idproducto FROM productos WHERE existencias = 0 UNION ALL SELECT fab,producto FROM pedidos WHERE year(fechapedido) = 1990 ORDER BY idproducto  Se ha incluido la cláusula ALL porque no nos importa que salgan filas repetidas. Se ha incluido ORDER BY para que el resultado salga ordenado por idproducto, observar que hemos utilizado el nombre de la columna de la primera SELECT, también podíamos haber puesto ORDER BY 2 pero no ORDER BY producto (es el nombre de la columna de la segunda tabla). El producto cartesiano El producto cartesiano es un tipo de composición de tablas, aplicando el producto cartesiano a dos tablas se obtiene una tabla con las columnas de la primera tabla unidas a las columnas de la segunda tabla, y las filas de la tabla resultante son todas las posibles concatenaciones de filas de la primera tabla con filas de la segunda tabla.  El producto cartesiano se indica poniendo en la FROM las tablas que queremos componer separadas por comas, podemos obtener así el producto cartesiano de dos, tres, o más tablas.   Esta operación no es de las más utilizadas, normalmente cuando queremos componer dos tablas es para añadir a las filas de una tabla, una fila de la otra tabla, por ejemplo añadir a los pedidos los datos del cliente correspondiente, o los datos del representante, esto equivaldría a un producto cartesiano con una selección de filas: SELECT * FROM pedidos,clientes WHERE pedidos.clie=clientes.numclie Las columnas que aparecen en la cláusula WHERE de nuestra consulta anterior se denominan columnas de emparejamiento ya que permiten emparejar las filas de las dos tablas. Las columnas de emparejamiento no tienen por qué estar incluidas en la lista de selección. Normalmente emparejamos tablas que están relacionadas entre sí y una de las columnas de emparejamiento es clave principal, pues en este caso, cuando una de las columnas de emparejamiento tienen un índice definido es más eficiente utilizar otro tipo de composición, el INNER JOIN. El INNER JOIN El INNER JOIN es otro tipo de composición de tablas, permite emparejar filas de distintas tablas de forma más eficiente que con el producto cartesiano cuando una de las columnas de emparejamiento está indexada. Ya que en vez de hacer el producto cartesiano completo y luego seleccionar la filas que cumplen la condición de emparejamiento, para cada fila de una de las tablas busca directamente en la otra tabla las filas que cumplen la condición, con lo cual se emparejan sólo las filas que luego aparecen en el resultado. La sintaxis es la siguiente:  SELECT * FROM pedidos INNER JOIN clientes ON pedidos.clie= clientes.numclie Se pueden definir varias condiciones de emparejamiento unidas por los operadores AND y OR poniendo cada condición entre paréntesis. Ejemplo: SELECT * FROM pedidos INNER JOIN productos ON (pedidos.fab = productos.idfab) AND (pedidos.producto = productos.idproducto) Se pueden combinar más de dos tablas En este caso hay que sustituir en la sintaxis una tabla por un INNER JOIN completo. Por ejemplo: SELECT * FROM (pedidos INNER JOIN clientes ON pedidos.clie = clientes.numclie) INNER JOIN empleados ON pedidos.rep = empleados.numemp El LEFT JOIN y RIGHT JOIN El LEFT JOIN y RIGHT JOIN son otro tipo de composición de tablas, también denominada composición externa. Son una extensión del INNER JOIN. Las composiciones vistas hasta ahora (el producto cartesiano y el INNER JOIN) son composiciones internas ya que todos los valores de las filas del resultado son valores que están en las tablas que se combinan. Queremos combinar los empleados con las oficinas para saber la ciudad de la oficina donde trabaja cada empleado, si utilizamos un producto cartesiano tenemos: SELECT empleados.*,ciudad FROM empleados, oficinas WHERE empleados.oficina = oficinas.oficina Observar que hemos cualificado el nombre de columna oficina ya que ese nombre aparece en las dos tablas de la FROM. Con esta sentencia los empleados que no tienen una oficina asignada (un valor nulo en el campo oficina de la tabla empleados) no aparecen en el resultado ya que la condición empleados.oficina = oficinas.oficina será siempre nula para esos empleados. Si utilizamos el INNER JOIN: SELECT empleados.*, ciudad FROM empleados INNER JOIN oficinas ON empleados.oficina = oficinas.oficina Nos pasa lo mismo, el empleado 110 tiene un valor nulo en el campo oficina y no aparecerá en el resultado. Pues en los casos en que queremos que también aparezcan las filas que no tienen una fila coincidente en la otra tabla, utilizaremos el LEFT o RIGHT JOIN. La sintaxis del LEFT JOIN es la siguiente:   SELECT * FROM empleados LEFT JOIN oficinas ON empleados.oficina = oficinas.oficina Con el ejemplo anterior obtenemos una lista de los empleados con los datos de su oficina, y el empleado 110 que no tiene oficina aparece con sus datos normales y los datos de su oficina a nulos. La sintaxis es la misma que la del INNER JOIN  lo único que cambia es la palabra INNER por RIGHT  sta operación consiste en añadir al resultado del INNER JOIN las filas de la tabla de la derecha que no tienen correspondencia en la otra tabla, y rellenar en esas filas los campos de la tabla de la izquierda con valores nulos. Ejemplo: SELECT * FROM empleados RIGHT JOIN oficinas ON empleados.oficina = oficinas.oficina Una operación LEFT JOIN o RIGHT JOIN se puede anidar dentro de una operación INNER JOIN, pero una operación INNER JOIN no se puede anidar dentro de LEFT JOIN o RIGHT JOIN. Los anidamientos de JOIN de distinta naturaleza no funcionan siempre, a veces depende del orden en que colocamos las tablas, en estos casos lo mejor es probar y si no permite el anudamiento, cambiar el orden de las tablas ( y por tanto de los JOINs) dentro de la cláusula FROM. Por ejemplo podemos tener: SELECT * FROM clientes INNER JOIN (empleados LEFT JOIN oficinas ON empleados.oficina = oficinas.oficina) ON clientes.repclie = empleados.numclie

DICCIONARIOS DE DATOS

DICCIONARIO DE DATOS

Durante la creación de la base da datos, el oracle server crea estructuras de datos adicionales junto con los data file.

·                     Tabla de diccionario de datos.

·                     Tabla de funcionamientos.

EL DICCIONARIO DE DATOS

·                     El diccionario de datos es un conjunto de tablas de solo lectura y vistas que registran, verifican y proveen información. 

·                     El diccionario de datos describe la base de datos y sus objetos.

·                     El diccionario incluye 2 tipos de objetos: -Tabla de base de datos: es un almacén de la  descripción de la base vista del diccionario de datos.

CONTENIDO DEL DICCIONARIO DE DATOS

El diccionario de datos provee información acerca de lo siguiente:

·                     El nombre de los usuarios de Oracle.

·                     Privilegios.

·                     Roles.

·                     Defectos por valor de las columnas.

·                     Auditoría.

·                     Integridad de la información.

·                     La definición de todos los esquemas del objeto en la base de datos.

CATEGORÍAS DE LAS VISTAS DEL DICCIONARIO DE DATOS

El diccionario de datos consiste de 3 principales vistas estáticas:

1.               DBA: accede a todos los objetos de la base.

2.               ALL: objetos accesibles para usuarios comunes.

3.               USER: objetos propios para usuarios comunes.

Para obtener un listado de las vistas se usa la consulta SELECT  y FROM.

VISTAS DEL DICCIONARIO DE DATOS:

Para las vistas del diccionario de datos, que son vistas estáticas se debe contestar:

1.               ¿Fue el objeto alguna ves creado?

2.               ¿Que parte del objeto fue creada?

3.               ¿Quien es el dueño del objeto?

4.               ¿Que privilegios tienen los usuarios?

5.               ¿Que restricciones tienen los objetos?

Hay que recordar que a través de las vistas dinamias, el Oracle Server puede ser almacenar el flujo de actividad en la base de datos,  por tanto las vistas virtuales vienen a ser como un conjunto de tablas virtuales.

Este conjunto de tablas virtuales existen solo en memoria cuando la base de datos esta corriendo, y reflejan en tiempo real las condiciones de las operaciones de la base.

Estas tablas virtuales son el actual de la fuente de información en memoria y archivos.

Consultas al diccionario de datos y vistas dinámica. 

El diccionario de datos y las vistas dinámica pueden ser requeridas para información como:

·                     Listar las listas disponibles, que pueden ser recuperadas por consultas a la vista del diccionario.

·                     Listar las columnas y sus contenidos para que puedan ser accedidos usando el DESCRIBE y SELECT 

EJEMPLO DE DICCIONARIO DE DATOS:

Para obtener una vista general:

DICTIONARY, DICT_COLUMNS 

Para obtener un diagrama de objetos:

DBA_TABLES, DBA_INDEXES,

DBA_TAB_COLUMNS, DBA_CONSTRAINTS

DICCIONARIOS DE DATOS

El diccionario de datos no es mas que una tabla con el nombre de cada tabla de la base de datos, sus campos, el tipo de datos de cada campo y la descripcion de cada campo. Esta herramienta se los generar automaticamente ya que estarlo haciendo a mano es tedioso, especialmente si no se hizo al comienzo del desarrollo.
Un diccionario de datos es un conjunto de metadatos que contiene las características lógicas y puntuales de los datos que se van a utilizar en el sistema que se programa, incluyendo nombre, descripción, alias, contenido y organización.
Identifica los procesos donde se emplean los datos y los sitios donde se necesita el acceso inmediato a la información, se desarrolla durante el análisis de flujo de datos y auxilia a los analistas que participan en la determinación de los requerimientos del sistema, su contenido también se emplea durante el diseño.
En un diccionario de datos se encuentra la lista de todos los elementos que forman parte del flujo de datos de todo el sistema. Los elementos mas importantes son flujos de datos, almacenes de datos y procesos. El diccionario de datos guarda los detalles y descripción de todos estos elementos.

REFERENCIAS: Sistemas de bases de datos: diseño, implementación y administración
 Escrito por Peter Rob,Carlos Coronel

RESTRICCIONES

Se trata de unas condiciones de obligado cumplimiento por los datos de la baseDe datos. Las hay de varios tipos:
Inherentes: Son aquellas que no son determinadas por los usuarios, sino que son definidas por el hecho de que la base de datos sea relacional. Las más importantes son:
No puede haber dos tablas iguales.
El orden de las tablas no es significativo.
El orden de los atributos no es significativo.
Cada atributo sólo puede tomar un valor en el dominio en el que está inscrito.

Los componentes de una restricción son los siguientes:

La operación de actualización (inserción, borrado o eliminación) cuya ejecución ha de dar lugar a la comprobación del cumplimiento de la restricción.
La condición que debe cumplirse, la cual es en general una proposición lógica, definida sobre uno o varios elementos del esquema, que puede tomar uno de los valores de verdad (cierto o falso).
La acción que debe llevarse a cabo dependiendo del resultado de la condición.
En general, se puede decir que existen tres tipos de integridad:

RESTRICCIONES DE INTEGRIDAD: NO PERMITEN LA EXISTENCIA DE RELACIONES QUE NO REPRESENTAN UN ESTADO POSIBLE DEL MUNDO REAL QUE ESTÁN REPRESENTANDO.

• RESTRICCIÓN DE UNICIDAD: NO DEBE HABER EN LA RELACIÓN DOS TUPLAS QUE TENGAN EL MISMO VALOR EN TODOS LOS ATRIBUTOS DEL CONJUNTO K (2 VALORES IGUALES EN LA MISMA COLUMNA).

• RESTRICCIÓN DE VALOR NO NULO: NO DEBE HABER EN LA RELACIÓN UNA TUPLA QUE TENGA VALOR NULO EN ALGÚN ATRIBUTO DE K (NO DEBE HABER NINGUNA CASILLA DE LA COLUMNA VACIA).

• CLAVE PRIMARIA: CONJUNTO DE ATRIBUTOS DE SU ESQUEMA QUE SÓN ELEGIDOS PARA SERVIR DE IDENTIFICADOR UNÍVOCO DE SUS TUPLAS. REQUISITOS: MINIMAL (NECESSARIO), NO VALORES NULOS, UNICO PARA CADA TUPLA.

• CLAVE AJENA: EXPRESAN RELACIONES ENTRE LOS OBJETOS REPRESENTADOS, INCLUYENDO EN EL ESQUEMA DE UNA RELACIÓN ATRIBUTOS DE OTRA (UTILIZADA PARA RELACIONAR TABLAS).

 REFERENCIAS

Procesamiento de bases de datos: fundamentos, diseño e implementación

 Escrito por David M. Kroenke

Introducción a los sistemas de bases de datos

 Escrito por C. J. Date

MODELO RELACIONAL

Es el modelo más utilizado en la actualidad para modelar problemas reales y administrar datos dinámicamente. Tras ser postuladas sus bases en 1970 por Edgar Frank Codd, de los laboratorios IBM en San José (California), no tardó en consolidarse como un nuevo paradigma en los modelos de base de datos.

En este modelo todos los datos son almacenados en relaciones, y como cada relación es un conjunto de datos, el orden en el que éstos se almacenen no tiene relevancia (a diferencia de otros modelos como el jerárquico y el de red). Esto tiene la considerable ventaja de que es más fácil de entender y de utilizar por un usuario no experto. La información puede ser recuperada o almacenada por El modelo relacional para la gestión de una base de datos es un modelo de datos basado en la medio de consultas que ofrecen una amplia flexibilidad y poder para administrar la información.
Este modelo considera la base de datos como una colección de relaciones. De manera simple, una relación representa una tabla que no es más que un conjunto de filas, cada fila es un conjunto de campos y cada campo representa un valor que interpretado describe el mundo real. Cada fila también se puede denominar tupla o registro y a cada columna también se le puede llamar campo o atributo.

Introducción a las bases de datos: el modelo relacional

 Escrito por Olga Pons Capote