Contingut

ProInf.net, SCPwww.proinf.net127

Lenguaje SQL y Bases de Datos Relacionales

por Claudio Casares

Tabla de contenidos

41.Generalidades

41.1.Arquitecturas

51.2.Cursores y Buffers

82.Modelo de datos

82.1.Introduccin

92.2.Los Usuarios

102.3.Ciclo de vida de una base de datos

122.4.Criterios de calidad

152.5.Indicadores de calidad

162.6.El modelo lgico

172.7.Restricciones de integridad

213.Modelo Relacional

213.1.Introduccin

243.2.Proceso de normalizacin

293.3.Las interrelaciones

323.4.Algebra relacional

363.5.Clculo relacional

384.Lenguaje SQL

384.1.Introduccin

414.2.Consultas de Seleccin

464.3.Consultas de Accin

504.4.Consultas de Unin Internas

584.5.Consultas de Unin Externas

604.6.Consultas de Referencias Cruzadas

644.7.Criterios de Seleccin

714.8.Agrupamiento de Registros

764.9.Tipos de Datos

784.10.Subconsultas

844.11.Estructuras de las Tablas

894.12.Problemas resueltos: Registros duplicados

904.13.Problemas resueltos: Registros no relacionados

904.14.Cursores

944.15.FREETEXT y CONTAINS (FULLTEXT SQL-SERVER)

1184.16.Access: Bases externas

1204.17.Access: Parmetros

1204.18.Access: Omitir permisos

1214.19.Access: Clusula PROCEDURE

1224.20.Optimizar Sentencias

1255.APNDICES

1255.1.Las 12 reglas de Codd que determinan la fidelidad de un sistema relacional al modelo relacional

1. Generalidades

1.1. Arquitecturas

En muchas ocasiones, despus de haber realizado un gran estudio detallado del SGBD y haber revisado su diseo, nos podemos encontrar que ha implementado sobre un equipo con insuficientes recursos o no se ha seleccionado la arquitectura adecuada para su explotacin. Entre otras arquitecturas, caben destacar las siguientes:

1.1.1. Cliente / Servidor

Esta arquitectura consta de un cliente inteligente que puede solicitar servicios de un servidor en red. En el lado del cliente de esta arquitectura encontramos una aplicacin frontal bastante sencilla ejecutndose en un ordenador personal. A una aplicacin cliente / servidor se le puede pedir que realice validaciones o que muestre listas de opciones vlidas, pero la mayor parte de las reglas de integridad de los datos y de negocio se imponen en la propia base de datos: relaciones, ndices, valores predeterminados, rangos, disparadores, procedimientos almacenados, etc. En el lado del servidor encontramos un motor de servidor de bases de datos inteligente. El servidor est diseado para aceptar consultas SQL desde la aplicacin frontal, generalmente en forma de llamadas a procedimientos almacenados que devuelven conjunto de resultados claramente definidos y de mbito limitado.

Generalmente, la aplicacin cliente es responsable, al menos, de la administracin de la conexin, la captura de los datos, la presentacin de datos y la administracin de los errores.

El servidor es el responsable de la administracin inteligente de los recursos, la administracin de la seguridad, la administracin de los datos, de las consultas y sobre todo de la integridad de los datos.

1.1.2. Motor Distribuido

En este caso, cada uno de los clientes posee el motor necesario para acceder a la base de datos y acceden de forma independiente del resto de los usuarios. Esta arquitectura tiene la ventaja del aprovechamiento de los recursos del cliente pero la desventaja del control de versiones.

1.1.3. Componentes Distribuidos

Esta arquitectura aade un tercer elemento al sistema de acceso a la base de datos, se trata de los objetos de lgica de negocio, encargados de procesar las peticiones de los clientes y hacrselas llegar al servidor. Estos objetos pueden estar instalados en mquinas diferentes a la del cliente y del servidor. La principal ventaja radica en el aprovechamiento de los servicios cliente / servidor y en asegurar el control de las versiones del motor de acceso a datos. La aplicacin frontal realiza peticiones a los objetos de lgica de negocio que son trasmitidas al servidor, la respuestas del mismo llegan a los objetos y stos las devuelven al cliente.

1.2. Cursores y Buffers

Bsicamente, un cursor es un conjunto de punteros a las filas devueltas por una consulta, la mayora, son como un conjunto de resultados, excepto por que los datos reales generalmente permanecen en el servidor.

Un buffer es un depsito RAM en el lado del cliente donde se guardan los datos del conjunto de resultados de manera temporal hasta que pueden llevarse a otro lugar para su almacenamiento.

Las columnas de datos de una o varias filas se dice que son miembros del cursor si la clusula WHERE de la consulta las incluye. Esta columnas, combinadas en filas lgicas se convierten en filas miembro del conjunto de resultados.

Por ejemplo:

SELECTNombre, Genero

FROMAnimales

WHEREEdad < 10

Cuando se ejecuta esta consulta, el motor cliente empieza inmediatamente a seleccionar miembros para el conjunto de resultados. En este caso son todos los animales menores de diez aos.

Si no es necesaria una ordenador, el SGDB pasa las primeras filas de este conjunto de resultados de vuelta a la estacin de trabajo nada ms capturarlas y despus detiene el procesamiento hasta que la estacin recupera las filas capturadas, una vez recuperadas el gestor de datos pasa ms filas y as sucesivamente. Debido a este proceso, si otros usuarios estn actualizando la base de datos, hay posibilidades que se aada otra fila que cumpla las condiciones del conjunto de resultados; en este caso la fila aadida pasa a ser miembro del conjunto y es recuperada por la estacin de trabajo. Tambin existe la posibilidad de la eliminacin o modificacin de una fila, en estos casos, si la fila no ha sido enviada a la estacin de trabajo o no se enva o se enva modificada; pero siempre cabe la posibilidad de que la estacin de trabajo haya ledo una fila que ya no existe o que haya sido modificada por otro usuario. Estas actualizaciones no se incluirn en el conjunto de resultados si la estacin de trabajo ha comenzado a procesar los resultados.

El proceso de relleno del cursor finaliza cuando el gestor de datos ha determinado cual es la ltima fila del conjunto de resultados y se considera completamente relleno cuando la estacin de trabajo ha capturado la ltima fila, en este momento cuando se conoce el nmero de filas que componen el cursor. Por este motivo los mtodos o propiedades que informan del nmero de filas devueltas o afectadas no son reales hasta que el cursor no se rellenado completamente.

1.2.1. Ubicacin de los cursores

Como ya se ha comentado un cursor es un conjunto de punteros a un conjunto de resultados. Estos punteros pueden estar ubicados en el servidor o en la estacin de trabajo, originando dos tipos de cursores, los cursores del lado del cliente y los cursores del lado del servidor. Pero no todos los gestores de datos permiten crear cursores en el lado del servidor, slo se pueden crear con aquellos gestores que tengan comportamiento cliente / servidor.

Las ventajas e inconvenientes de cada tipo de cursor es muy variable y depende siempre de la explotacin que se desee hacer de los datos, de la topologa de la red y de los equipos empleados. En general los cursores en el lado del servidor reducen los tiempos de acceso a los datos y mejoran el desplazamiento por el conjunto de resultados, si embargo consumen ms cantidad de recursos de servidor y de red.

1.2.2. Tipos de cursores

Conjuntos de resultados sin cursor

Con un conjunto de resultados sin cursor las filas de datos pasan al frontal para su procesamiento. Este el sistema ms rpido para llevar los datos desde el servidor al cliente, pero no ofrece los beneficios del cursor, por que, si bien algunos son actualizables, a menudo no lo son y hay que controlar el proceso desde el frontal para controlar las modificaciones.

Cursores desplazables

Uno de los aspectos ms costosos de la administracin de los cursores es dar soporte a la capacidad de desplazamiento. Esta capacidad significa que, una vez ejecutada una consulta, un cursor desplazable permite la colocacin en cualquier fila del conjunto de resultados. Estos mtodos de reubicacin son costosos en el sentido que consumen recursos del sistema. Para aumentar el rendimiento se aconseja limitar los cursores y seleccionar los no desplazables.

Cursores de slo avance

Este tipo de cursor slo permite utilizar los mtodos para desplazarse avanzando por las filas del conjunto de resultados, no permiten el retroceso por las mismas. En este caso el gestor de datos enviar las filas del conjunto de resultados tan rpido como le sea posible.

Cursores estticos

Un cursor esttico proporciona la capacidad de direccionamiento por todo el conjunto de resultados generando una copia en la estacin de trabajo de las filas devueltas, todos los trabajos realizados sobre este conjunto de resultados afectar nicamente a la copia local. Por su naturaleza este cursor necesita de un espacio de almacenamiento en el cliente. Este cursor no es la mejor opcin para datos que cambian constantemente, pero para tablas de bsqueda cuyos valores no es probable que cambien, este cursor tiene mucho sentido.

Cursores de conjunto de claves

Un cursor de conjunto de claves, u hoja de respuesta dinmica, almacena un conjunto de claves, bsicamente un conjunto de punteros, y permite volver a capturar una fila seleccionada de acuerdo con la informacin especfica de la fila almacenada en dichas claves. Estos cursores necesitan espacio de almacenamiento independiente para los datos de cada una de las claves que lo componen. Cualquier cambio o modificacin sobre una fila del conjunto de resultados por parte de cualquier usuario es reflejado en cualquier estacin de trabajo al leer la informacin de dicha fila.

Cursores dinmicos

Al igual que en los dos casos anteriores, un cursor dinmico almacena un bloque de claves. Sin embargo, con este tipo de cursor, la consulta que se ha utilizado para generar el conjunto de resultados se vuelve a ejecutar constantemente siempre que se hace referencia al cursor. Debido a esta actividad repetida, los cursores dinmicos consumen gran cantidad de recursos, pero poseen la gran ventaja que jams cierran la pertenencia o no pertenencia de las filas al conjunto de resultados. En los dos casos anteriores una vez rellenado el cursor no se admite la inclusin o exclusin de filas.

Cursores de slo lectura

Todos los tipos de cursores citados admiten la posibilidad de slo lectura, en este caso ninguna de las filas del conjunto de resultados pueden ser modificadas por la estacin de trabajo. Este cursor es muy til para la generacin de consultas o informes en donde se sabe que ningn dato ser modificado. Poseen la ventaja y el inconveniente de no generar bloqueos sobre las filas consultadas, de tal forma que cualquier usuario puede editar las filas contenidas en este cursor.

1.2.3. Tipos de buffers

Buffers de una nica fila

Un buffer de una nica fila no es en realidad un cursor, aunque aqu se apliquen las mismas reglas de pertenencia que se aplican a un cursor de conjunto de claves de slo avance. Con un buffer de una nica fila slo es posible examinar los datos de la fila del conjunto de resultados. Las filas anteriores no estn disponibles y la fila actual no estar accesible despus de pasar a la siguiente fila del conjunto de resultados.

Buffers de n filas

Un buffer de n filas ampla el mbito y la capacidad de desplazamiento del buffer de una nica fila. En este caso, a la estacin de trabajo se le expone un nmero determinado de filas del conjunto de resultados y a la aplicacin se le permite que se desplace libremente por esas filas.

2. Modelo de datos

2.1. Introduccin

Desde tiempos remotos, los datos han sido registrados por el hombre en algn tipo de soporte (piedra, papel, madera, etc.) a fin de que quedara constancia de una fenmeno o idea. Los datos han de ser interpretados para que se conviertan en informacin til, esta interpretacin supone un fenmeno de agrupacin y clasificacin.

En la era actual y con el auge de los medios informticos aparece el almacenamiento en soporte electromagntico, ofreciendo mayores posibilidades de almacenaje, ocupando menos espacio y ahorrando un tiempo considerable en la bsqueda y tratamiento de los datos. Es en este momento donde surge el concepto de bases de datos y con ellas las diferentes metodologas de diseo y tratamiento.

El objetivo bsico de toda base de datos es el almacenamiento de smbolos, nmeros y letras carentes de un significado en s, que con un tratamiento adecuado se convierten en informacin til. Un ejemplo podra ser el siguiente dato: 19941224, con el tratamiento correcto podra convertirse en la siguiente informacin: "Fecha de nacimiento: 24 de diciembre de 1994".

Segn van evolucionando los tiempos, las necesidades de almacenamiento de datos van creciendo y con ellas las necesidades de transformar los mismos datos en informacin de muy diversa naturaleza. Esta informacin es utilizada diariamente como herramientas de trabajo y como soporte para la toma de decisiones por un gran colectivo de profesionales que toman dicha informacin como base de su negocio. Por este motivo el trabajo del diseador de bases de datos es cada vez ms delicado, un error en el diseo o en la interpretacin de datos puede dar lugar a informacin incorrecta y conducir al usuario a la toma de decisiones equivocadas. Se hace necesario la creacin de un sistema que ayude al diseador a crear estructuras correctas y fiables, minimizando los tiempos de diseo y explotando todos los datos, nace as la metodologa de diseo de bases de datos.

La metodologa de diseo de datos divide cada modelo en tres esquemas:

A) Modelo Global: se trata de una representacin grfica legible por el usuario y que nos aporta el flujo de informacin dentro de una organizacin. No existen reglas para su construccin y se debe realizar siempre el esquema ms sencillo posible para la comprensin por parte del usuario de la base de datos. Por ejemplo:

B) Modelo Lgico: se trata de una representacin grfica, mediante smbolos y signos normalizados, de la base de datos. Su objetivo es representar la estructura de los datos y las dependencias de los mismos, garantizando la consistencia y evitando la duplicidad. Este modelo de datos se estudiar con profundidad en los captulos siguientes.

C) Modelo Fsico: se trata del almacn de los datos, es la base de datos en s misma, el soporte donde se almacenan los datos y de donde se extraen para convertir los datos en informacin. En funcin del gestor de bases de datos empleado las reglas de almacenamiento varan.

2.2. Los Usuarios

En todo sistema de base de datos cabe diferenciar tres tipos diferentes de usuarios, entre todos comparten la informacin pero acceden a ella de una forma diferente, siempre en funcin de sus necesidades.

El primer grupo de usuarios es el PED (Procesamiento Electrnico de Datos), normalmente compuestos por los operarios de la organizacin. Las necesidades bsicas de este grupo de usuarios son:

1. El foco operativo fundamental se centra en el almacenamiento de los datos, el procesamiento de los mismos y el flujo de datos;

2. Generan informes de tipo listados;

3. Poseen acceso restringido a la informacin.

El segundo grupo de usuarios es el SIM (Sistemas de Informacin de Gestin) y suele estar formado por los mandos medios de la organizacin. Las necesidades bsicas de este grupo de usuarios son:

El foco operativo se fundamenta en la toma de decisiones, tomando como partida los datos del grupo PED e introduciendo un volumen pequeo de informacin;

No poseen acceso medianamente restringido a la informacin;

Generan informes de resmenes de datos del grupo PED y listados de la informacin que introducen.

El tercer ltimo grupo de usuarios lo forman el STD (Sistema de apoyo a Toma de Decisiones), este grupo se centra en el nivel ms alto de la organizacin y poseen las caractersticas siguientes:

El foco operativo se centra en la decisin, con una entrada mnima de datos;

No tienen acceso restringido;

Generan informes globales que les sirven como apoyo a las tomas de decisiones del negocio, estos son los informes ms importantes y suelen ir acompaados de resmenes, grficas y sobre todo centrados en la evolucin y comparacin de la informacin.

Cabe destacar la figura de un cuarto grupo de usuarios, en este caso usuarios avanzados, que est compuesto por los administradores del sistema, cuya opinin es fundamental para seleccionar el soporte de los datos, evitar la duplicacin de informacin ya existente en otros sistemas y sobre todo puede aportar el conocimiento de sus usuarios, sus necesidades y los problemas ya resueltos.

En general, podemos decir que los objetivos de una base de datos son los siguientes:

Ayudar en la toma de decisiones;

Compartir de forma controlada y restringida los datos y el acceso a la informacin;

Integrar los datos de una forma lgica, evitando la duplicidad;

Asegurar un rpido acceso a la informacin y los datos.

2.3. Ciclo de vida de una base de datos

2.3.1. Anlisis de las necesidades

En reunin con el cliente se deben documentar los tres grupos de usuarios definidos en la introduccin, las necesidades de informacin de cada uno de ellos, as como los informes que cada uno necesita para su actividad y el contenido de los mismos. Cuanta ms precisin exista en estos requisitos iniciales ms preciso ser el desarrollo de la base de datos.

En esta reunin tambin debe quedar documentados los niveles de seguridad de los grupos de usuarios, los derechos de cada uno de ellos sobre los datos, los requisitos de los sistemas informticos del cliente (sistema operativo, tipo de red, servidores, etc.) y la ubicacin de los usuarios.

No hay que olvidar que normalmente en las empresas existen ya sistemas de almacenamiento de datos, por tanto es conveniente analizar los datos ya existentes y analizar las posibles relaciones con la base de datos a desarrollar.

Un cuestionario muy sencillo pero muy til para el administrador es el siguiente (a rellenar por todos los usuarios):

Nombre

Cargo

Area de Responsabilidad

Obligaciones principales que requieren informacin de la base datos

De qu aplicaciones recibe informacin?

Con cunta frecuencia recibe informacin?

Qu hace con esta informacin?

Qu precauciones de seguridad debe tomar con respecto a la informacin?

Para que aplicacin proporciona datos?

Estn contemplados cambios para alguna de sus actividades actuales que involucren alguna de las informaciones anteriores?

2.3.2. Estudio de viabilidad

Un estudio de viabilidad implica la preparacin de un informe con las caractersticas siguientes:

Viabilidad tecnolgica. Hay tecnologa suficiente para el desarrollo?

Viabilidad operacional. Existen suficientes recursos humanos, presupuesto, experiencia y formacin para el desarrollo?

Viabilidad econmica. Se pueden identificar los beneficios? Los beneficios costearan el desarrollo del sistema? Se pueden medir los costes y los beneficios?

2.3.3. Definicin de requisitos

Los requisitos de desarrollo involucran el software y hardware necesario para la implementacin, los recursos humanos necesarios (tanto internos como externos), la formacin al personal.

Aunque un poco al margen del tema es conveniente parar en este momento y planificar las acciones a realizar elaborando un cronograma del proyecto y un organigrama con las responsabilidades de cada miembro del equipo. Conviene sealar quienes van a ser los interlocutores y fijar un calendario de reuniones de seguimiento del proyecto.

Hay que definir la figura del validador, esta persona ser la encargada de velar en cada momento que no se est rebasando el alcance del proyecto, as como asegurar que la implementacin est encaminada a subsanar las necesidades del cliente.

2.3.4. Diseo

En esta etapa se crea un esquema conceptual de la base de datos. Se desarrollan las especificaciones hasta el punto en que puede comenzar la implementacin. Durante esta etapa se crean modelos detallados de las vistas de usuario y sobre todo las relaciones entre cada elemento del sistema, documentando los derechos de uso y manipulacin de los diferentes grupos de usuarios.

Si parte de la informacin necesaria para crear algn elemento establecido ya se encuentra implementado en otro sistema de almacenamiento hay que documentar que relacin existir entre uno y otro y detallar los sistemas que eviten la duplicidad o incoherencia de los datos.

El diseo consta, como se vio anteriormente, de tres fases: el diseo global o conceptual, el diseo lgico y el modelo fsico.

2.3.5. Implementacin

Una vez totalmente detallado el modelo conceptual se comienza con la implementacin fsica del modelo de datos, a medida que se va avanzando en el modelo el administrador del sistema va asegurando la correccin del modelo y el validador la utilidad del mismo.

La implementacin consiste en el desarrollo de las tablas, los ndices de los mismos, las condiciones de validacin de los datos, la relacin entre las diferentes tablas. Por otro lado, la definicin de las consultas y los parmetros a utilizar por cada una de ellas.

Una vez finalizada la implementacin fsica, se asignan las correspondientes medidas de seguridad y se ubica la base de datos en el lugar correspondiente.

2.3.6. Evaluaccin y Perfeccionamiento

En esta ltima etapa todos los usuarios del sistema acceden a la base de datos y deben asegurarse el correcto funcionamiento de la misma, que sus derechos son los adecuados, teniendo a su disposicin cuanta informacin necesiten. Tambin debern asegurarse que el acceso a los datos es cmodo, prctico, seguro y que se han eliminado, en la medida de lo posible, las posibilidades de error.

El administrador se asegura que todos los derechos y todas las restricciones han sido implementadas correctamente y que se ha seguido en manual de estilo en la totalidad de la implementacin.

El validador se asegurar que todas las necesidades del cliente han sido satisfechas.

2.4. Criterios de calidad

Legibilidad

El diseo de una base de datos ha de estar redactado con la suficiente claridad para que pueda ser entendido rpidamente. El lenguaje utilizado debe ser lo suficientemente claro, conciso y detallado para que explique con total claridad el diseo del modelo, sus objetivos, sus restricciones, en general todo aquello que afecte al sistema de forma directa o indirecta. En este punto conviene aplicar el principio que una imagen vale ms que mil palabras, pero en ocasiones son necesarias esas mil palabras y obviar la imagen.

Fiabilidad

Se trata de realizar un sistema de bases de datos lo suficientemente robusto para que sea capaz de recuperarse frente a errores o usos inadecuados. Se deben utilizar gestores con las herramientas necesarias para la reparacin de los posibles errores que las bases de datos pueden sufrir, por ejemplo tras un corte inesperado de luz.

Portabilidad

El diseo deber permitir la implementacin del modelo fsico en diferentes gestores de bases de datos.

Modificabilidad

Ningn sistema informtico es esttico, las necesidades de los usuarios varan con el tiempo y por lo tanto las bases de datos se deben adaptar a las nuevas necesidades, por lo que se precisa que un buen diseo facilite el mantenimiento, esto es, las modificaciones y actualizaciones necesarias para adaptarlo a una nueva situacin.

Eficiencia

Se deben aprovechar al mximo los recursos de la computadora, minimizando la memoria utilizada y el tiempo de proceso o ejecucin, siempre que no sea a costa de los requisitos anteriores. En este punto se debe tener en cuenta los gestores cliente / servidor de bases de datos. En muchas ocasiones es ms rentable cargar de trabajo al servidor y liberar recursos de los clientes, pero no todos los gestores permiten este tipo de trabajo, por lo tanto se ha de tener en cuenta estas dos circunstancias en el diseo de la base de datos.

Auto descripcin

En la documentacin generada debe estar todo el detalle del diseo, evitando referencias a otros documentos que no estn incluidos dentro de la documentacin de la base de datos.

Trivialidad

Tanto el diseo como la implantacin se deben realizar utilizando los estndares fijados a priori, estos estndares debern quedar reflejados al inicio del documento.

Claridad

Todos los documentos deben estar redactados de forma clara y fcil de entender, los nombre utilizados para las tablas, los campos, ndices, etc. deben ser autodescriptivos y estar perfectamente documentados.

Coherencia

Las anotaciones y terminologa utilizada deben ser uniformes, para ello se debe seguir algn tipo de metodologa estndar, indicado cual se ha empleado, en los casos en que se utilice alguna metodologa no estndar se debe adjuntar a la documentacin.

Completo

Todos los elementos constitutivos de la base de datos existen, no se han dejado partes incompletas, sin documentar o sin implementar.

Concisin

No existen elementos intiles ni repetitivos. En este apartado hay que hacer un especial hincapi en la repeticin de datos en diferentes tablas, hay que evitar a toda costa que el mismo dato se repita en varias tablas para conseguir as una optimizacin del tamao de la base de datos.

Facilidad de Aprendizaje

La documentacin de la base de datos se puede utilizar sin necesidad de otros conocimientos informticos fuera del alcance del diseo e implementacin de la base de datos.

Facilidad de Uso

Los datos deben ser fciles de elaborar y los resultados fciles de entender.

Generalidad

La base de datos debe ser capaz de adaptarse a cualquier tipo de empresa y a cualquier casustica.

Independencia de Usuario

La base de datos no debe estar ligada a la utilizacin en una nica instalacin, hay que tener en cuenta que, aunque se trate de un desarrollo a medida, en un futuro se podra realizar la instalacin en un cliente diferente al inicial.

Independencia de Sistema

Las prestaciones y diseo de la base de datos no estn vinculadas al entorno.

Independencia de Instalacin

La base de datos se puede transportar fcilmente de una instalacin a otra.

Modularidad

La base de datos puede ser descompuesta en elementos independientes. Si se trata de un diseo grande, en donde hay un gran nmero de tablas, conviene realizar agrupaciones entre ella, creando mdulos funcionales que permitan la mejor compresin del diseo y de la implantacin.

Observable

La base de datos debe permitir observar los accesos a los datos. Siempre que se pueda hay que dejar un rastro de la utilizacin de los datos por parte de los usuarios, esta informacin ayuda al redimensionado de la base de datos y a conocer el nmero de accesos a los datos.

Precisin

Los clculos efectuados se deben realizar con la precisin requerida.

Proteccin

La base de datos debe permitir la proteccin de los datos frente a usos no debidos, para ello hay que elaborar un sistema de accesos definiendo diferentes usuarios con diferentes claves y especificar que autorizaciones tendr cada usuario sobre los diferentes datos.

Trazabilidad

Tomando como punto de partida la versin actual se puede remontar su diseo hasta las especificaciones iniciales

2.5. Indicadores de calidad

Al finalizar el diseo de una base de datos podemos utilizar la siguiente tabla para comprobar el grado de calidad del trabajo.

12345678910

Legibilidad____________________

Fiabilidad____________________

Portabilidad____________________

Modificabilidad____________________

Eficiencia____________________

Auto Descripcin____________________

Trivialidad____________________

Claridad____________________

Coherencia____________________

Completo____________________

Conciso____________________

Facilidad de Aprendizaje____________________

Facilidad de Uso____________________

Generalidad____________________

Independencia de Usuario____________________

Independencia del Sistema____________________

Independencia de Instalacin____________________

Modularidad____________________

Observable____________________

Precision____________________

Proteccin____________________

Trazable____________________

Legibilidad____________________

TOTAL____________________

PUNTUACIN FINAL__

2.6. El modelo lgico

Anteriormente se expuso el ciclo de vida del desarrollo de una base de datos. Este captulo se centrar en el diseo del modelo lgico de los datos, por tanto antes de comenzar esta modelacin es necesario tener documentado las necesidades, viabilidad y definicin de los requisitos, as como tener elaborado el modelo global o conceptual del diseo.

El paso del modelo global o conceptual de datos al modelo lgico supone una abstraccin, un mecanismo para la conversin del mundo real a un mundo formado por datos, a su agrupacin y clasificacin. El proceso de abstraccin consiste en identificar los elementos conceptos empleados en el modelo global y transformarlo en lo que denominamos entidades en el modelo lgico. La abstraccin se puede realizar de las siguientes formas:

Clasificacin

Consiste en generar una nica entidad conceptos con caractersticas comunes, todos ellos tendrn las mismas caractersticas y se diferencian unos de otros por los valores que toman dichas caractersticas. Por ejemplo: los conceptos cursos de ingls, cursos de espaol y cursos de francs se pueden agrupar en una nica entidad denominada "CURSOS" que englobe y diferencie cada uno de los diferentes cursos que se imparten.

Agregacin

Consiste en separar cada una de las partes de un concepto para generar distintas entidades, por ejemplo el concepto coche lo podemos definir utilizando las entidades rueda, motor y chasis.

Generalizacin

Consiste en ir generado entidades de diferentes niveles de tal forma que cada entidad de nivel superior agrupe las de nivel inferior.

Asociacin

Consiste en la generalizacin de entidades a partir de entidades ya existentes.

2.7. Restricciones de integridad

En el mundo real existen ciertas restricciones que deben cumplir los elementos en l existentes; por ejemplo, una persona slo puede tener un nmero de DNI y una nica direccin oficial. Cuando se disea una base de datos se debe reflejar fielmente el universo del discurso que estamos tratando, lo que es los mismo, reflejar las restricciones existentes en el mundo real.

Los componentes de una restriccin son los siguientes:

La operacin de actualizacin (insercin, borrado o eliminacin) cuya ejecucin ha de dar lugar a la comprobacin del cumplimiento de la restriccin.

La condicin que debe cumplirse, la cual es en general una proposicin lgica, definida sobre uno o varios elementos del esquema, que puede tomar uno de los valores de verdad (cierto o falso).

La accin que debe llevarse a cabo dependiendo del resultado de la condicin.

En general, se puede decir que existen tres tipos de integridad:

Integridad de dominio: restringimos los valores que puede tomar un atributo respecto a su dominio, por ejemplo EDAD >= 18 - 65.

Integridad de entidad: la clave primaria de una entidad no puede tener valores nulos y siempre deber ser nica, por ejemplo DNI.

Integridad referencial: las claves ajenas de una tabla hija se tienen que corresponder con la clave primaria de la tabla padre con la que se relaciona. Por ejemplo, en la tabla familiares de los empleados necesitaremos el DNI de empleado, que es la clave ajena de la tabla.

Las restricciones se clasifican en:

A. Inherentes

Estn impuestas por el modelo,

No tiene que ser definidas por el usuario, ya que se encuentran en el propio modelo,

Se activan en el momento de la definicin del esquema cuando se produce un intento de violacin,

Se rechaza todo esquema que no cumple estas restricciones,

Introducen rigideces en el modelo.

B. Semnticas

Impuestas por el universo del discurso,

Tienen que ser definidas por los diseadores,

Se activan en el momento de la actualizacin de la base de datos,

Se rechaza todo ejemplar que no cumpla estas restricciones (o se ponen en marcha otros medios a fin de que no se produzca un estado de inconsistencia),

Ayudan a capturar la semntica de los datos y a conseguir su consistencia.

1. Ajenas

Se especifican en los programas de aplicacin,

No estn almacenadas en el esquema de la base de datos,

Pueden ser violadas por actualizaciones en las que no se haya programado la restriccin,

El sistema de bases de datos no puede comprobar si son consistentes en s mismas.

El optimizador no puede tomarlas en consideracin,

Proporcionan el mximo de flexibilidad,

Pueden ser programadas en un lenguaje de propsito general o en algn lenguaje propio del sistema de bases de datos,

Suponen una importante carga de programacin y mantenimiento.

2. Propias

Se identifican en el esquema,

Estn almacenadas en el esquema de la base de datos,

No pueden ser violadas por ninguna actualizacin.

a. Accin General

Es obligatorio especificar la condicin y la accin,

Son procedimentales (al menos en parte, ya que la accin se especifica siempre mediante un procedimiento),

Suponen carga de programacin,

Es muy difcil (prcticamente imposible en la mayor parte de los casos) que el sistema de bases de datos pueda comprobar su consistencia,

El optimizador no puede tomarlas en consideracin,

Hasta ahora no estn estandarizadas,

Estn muy ligadas a los productos,

Son muy flexibles,

Tienen nombre y existencia propia dentro del programa.

i. Procedimientos almacenados

Es obligatorio especificar la condicin (adems de la accin),

Son totalmente procedimentales,

Pueden ser tan complejas como imponga la semntica del mundo real (tanto en la condicin como en la accin),

Son las ms flexibles dentro de las restricciones propias.

ii. Disparadores

Combinan los enfoques declarativo (en la condicin) y procedimental (en la accin),

Pueden ser tan complejas como imponga la semntica del mundo real en cuanto a la accin, y bastantes complejas en la condicin (todo lo que permite la proposicin lgica mediante la que se expresa la condicin),

El cumplimiento de la condicin dispara la accin,

Son ms flexibles que las restricciones de accin especfica.

b. Accin Especfica

La accin est implcita en la misma restriccin, por lo que no hay que definirla,

Son declarativas, puesto que no especifica la accin y la condicin, si se define, es declarativa,

El no cumplimiento de la condicin lleva a aplicar la accin,

Podran ser definidas mediante un lenguaje de tipo general,

El sistema de bases de datos puede comprobar si son consistentes en s mismas,

El optimizador puede tomarlas en consideracin,

No suponen carga de programacin, slo de definicin.

i. Condicin General

No se especifica la accin, que es siempre de rechazo (el no cumplimiento de la condicin lleva consigo el rechazo de la actualizacin),

Es obligatorio declarar la condicin mediante una proposicin lgica que permite condiciones de complejidad arbitraria,

Adems de la condicin, se puede especificar algn otro componente,

Son ms flexibles que las de condicin especfica,

Es ms difcil optimizar su ejecucin que en el caso de las de condicin especfica.

I. Verificacin

No tienen existencia en s mismas,

Su definicin forma parte de la definicin del elemento afectado por la restriccin,

Se aplican a un nico elemento y aunque pueden afectar a otros, en este caso se complica su definicin,

Pueden no tener nombre.

II. Asercin

Tienen existencia por s mismas,

Se definen con independencia de cualquier elemento del esquema,

Pueden afectar a ms de un elemento,

Tienen nombre.

ii. Condicin Especfica

Son opciones proporcionadas por el propio modelo,

No se especifica ninguno de los componentes relativos a una restriccin (ni la operacin, ni la condicin, ni la accin),

Son poco flexibles,

El optimizador puede tomarlas en consideracin,

Su ejecucin puede ser ms fcilmente optimizada que las de condicin general.

3. Modelo Relacional

3.1. Introduccin

Las bases de datos relacionales son el tipo de bases de datos actualmente ms difundido. Los motivos de este xito son fundamentalmente dos:

1. ofrecen sistemas simples y eficaces para representar y manipular los datos

2. se basan en un modelo, el relacional, con slidas bases tericas

El modelo relacional fue propuesto originariamente por E.F. Codd en un ya famoso artculo de 1970. Gracias a su coherencia y facilidad de uso, el modelo se ha convertido en los aos 80 en el ms usado para la produccin de DBMS.

La estructura fundamental del modelo relacional es precisamente esa, "relacin", es decir una tabla bidimensional constituida por lneas (tuple) y columnas (atributos). Las relaciones representan las entidades que se consideran interesantes en la base de datos. Cada instancia de la entidad encontrar sitio en una tupla de la relacin, mientras que los atributos de la relacin representarn las propiedades de la entidad. Por ejemplo, si en la base de datos se tienen que representar personas, se podr definir una relacin llamada "Personas", cuyos atributos describen las caractersticas de las personas (tabla siguiente). Cada tupla de la relacin "Personas" representar una persona concreta.

Persona

NombreApellidoNacimientoSexoEstado Civil

JuanLoza15/06/1971HSoltero

IsabelGalvez23/12/1969MCasada

MicaelaRuiz02/10/1985MSoltera

En realidad, siendo rigurosos, una relacin es slo la definicin de la estructura de la tabla, es decir su nombre y la lista de los atributos que la componen. Cuando se puebla con las tuplas, se habla de "instancia de relacin". Por eso, la tabla anterior representa una instancia de la relacin persona. Una representacin de la definiticn de esa relacin podra ser la siguiente:

Personas (nombre, apellido, fecha_nacimiento, sexo, estado_civil)

A continuacin, se indicarn ambas (relacin e instancia de relacin) con el trmino "relacin", a no ser que no quede claro por el contexto a qu acepcin se refiere.

Las tuplas en una relacin son un conjunto en el sentido matemtico del trmino, es decir una coleccin no ordenada de elementos diferentes. Para distinguir una tupla de otra, se recurre al concepto de "clave primaria", o sea a un conjunto de atributos que permiten identificar unvocamente una tupla en una relacin. Naturalmente, en una relacin puede haber ms combinaciones de atributos que permitan identificar unvocamente una tupla ("claves candidatas"), pero entre stas se elegir una sola para utilizar como clave primaria. Los atributos de la clave primaria no pueden asumir el valor nulo (que significa un valor no determinado), en tanto que ya no permitiran identificar una tupla concreta en una relacin. Esta propiedad de las relaciones y de sus claves primarias est bajo el nombre de integridad de las entidades (entity integrity).

A menudo, para obtener una clave primaria "econmica", es decir compuesta de pocos atributos fcilmente manipulables, se introducen uno o ms atributos ficticios, con cdigos identificativos unvocos para cada tupla de la relacin.

Cada atributo de una relacin se caracteriza por un nombre y por un dominio. El dominio indica qu valores pueden ser asumidos por una columna de la relacin. A menudo un dominio se define a travs de la declaracin de un tipo para el atributo (por ejemplo diciendo que es una cadena de diez caracteres), pero tambin es posible definir dominios ms complejos y precisos. Por ejemplo, para el atributo "sexo" de nuestra relacin "Personas" podemos definir un dominio por el cual los nicos valores vlidos son 'M' y 'F'; o bien por el atributo "fecha_nacimiento" podremos definir un dominio por el que se consideren vlidas slo las fechas de nacimiento despus del uno de enero de 1960, si en nuestra base de datos no est previsto que haya personas con fecha de nacimiento anterior a esa. El motor de datos se ocupar de controlar que en los atributos de las relaciones se incluyan slo los valores permitidos por sus dominios. Caracterstica fundamental de los dominios de una base de datos relacional es que sean "atmicos", es decir que los valores contenidos en las columnas no se puedan separar en valores de dominios ms simples. Ms formalmente se dice que no es posible tener atributos multivalor (multivalued). Por ejemplo, si una caracterstica de las personas en nuestra base de datos fuese la de tener uno o ms hijos, no sera posible escribir la relacin Personas de la siguiente manera:

Personas (nombre, apellido, fecha_nacimiento, sexo, estado_civil, hijos)

En efecto, el atributo hijos es un atributo no-atmico, bien porque una persona puede tener ms de un hijo o porque cada hijo tendr diferentes caractersticas que lo describen. Para representar estas entidades en una base de datos relacional hay que definir dos relaciones:

Personas (*nmero_persona, nombre, apellido, fecha_nacimiento, sexo, estado_civil)

Hijos(*nmero_persona, *nombre_apellido, edad, sexo)

En las relaciones precedentes, los asteriscos (*) indican los atributos que componen sus claves primarias. Ntese la introduccin en la relacin Personas del atributo nmero_persona, a travs del cual se asigna a cada persona un identificativo numrico unvoco que se usa como llave primaria. Estas relaciones contienen slo atributos atmicos. Si una persona tiene ms de un hijo, stos se representarn en tuplas diferentes de la relacin Hijos. Las diferentes caractersticas de los hijos las representan los atributos de la relacin Hijos. La unin entre las dos relaciones est constituida por los atributos nmero_persona que aparecen en ambas relaciones y que permiten que se asigne cada tupla de la relacin hijos a una tupla concreta de la relacin Personas. Ms formalmente se dice que el atributo nmero_persona de la relacin Hijos es una clave externa (foreign key) hacia la relacin Personas. Una clave externa es una combinacin de atributos de una relacin que son, a su vez, una clave primaria para otra relacin. Una caracterstica fundamental de los valores presentes en una clave externa es que, a no ser que no sean null, tienen que corresponder a valores existentes en la clave primaria de la relacin a la que se refieren. En nuestro ejemplo, esto significa que no puede existir en la relacin Hijos una tupla con un valor del atributo nmero_persona sin que tambin en la relacin Personas exista una tupla con el mismo valor para su llave primaria. Esta propiedad va bajo el nombre de integridad referencial (referential integrity).

Una de las grandes ventajas del modelo relacional es que define tambin un lgebra, llamada "lgebra relacional". Todas las manipulaciones posibles sobre las relaciones se obtienen gracias a la combinacin de tan slo cinco operadores: RESTRICT, PROJECT, TIMES, UNION y MINUS. Por comodidad, se han definido tambin tres operadores adicionales que de todos modos se pueden obtener aplicando los cinco fundamentales: JOIN, INTERSECT y DIVIDE. Los operadores relacionales reciben como argumento una relacin o un conjunto de relaciones y restituyen una nica relacin como resultado.

Veamos brevemente estos ocho operadores:

RESTRICT: restituye una relacin que contiene un subconjunto de las tuplas de la relacin a la que se aplica. Los atributos se quedan como estaban.

PROJECT: restituye una relacin con un subconjunto de los atributos de la relacin a la que viene aplicado. Las tuplas de la relacin resultado se componen de las tuplas de la relacion original, de manera que siguen siendo un conjunto en sentido matemtico.

TIME: se aplica a dos relaciones y efecta el producto cartesiano de las tuplas. Cada tupla de la primera relacin est concatenada con cada tupla de la segunda.

JOIN: se concatenan las tuplas de dos relaciones de acuerdo con el valor de un conjunto de sus atributos.

UNION: aplicando este operador a dos relaciones compatibles, se obtiene una que contiene las tuplas de ambas relaciones. Dos relaciones son compatibles si tienen el mismo nmero de atributos y los atributos correspondientes en las dos relaciones tienen el mismo dominio.

MINUS: aplicado a dos relaciones compatibles restituye una tercera que contiene las tuplas que se encuentran slo en la primera relacin.

INTERSECT: aplicado a dos relaciones compatibles restituye una relacin que contiene las tuplas que existen en ambas.

DIVIDE: aplicado a dos relaciones que tengan atributos comunes, restituye una tercera que contiene todas las tuplas de la primera relacin que se puede hacer que correspondan con todos los valores de la segunda relacin.

En las siguientes tablas, a ttulo de ejemplo, se representan los resultados de la aplicacin de algunos operadores relacionales a las relaciones Personas e Hijos. Como nombres para las relaciones resultado se han utilizado las expresiones que las producen.

Personas

nmero_personanombreapellidofecha_nacimientosexoestado_civil

2MarioRossi29/03/1965MCasado

1GiuseppeRusso15/11/1972MSoltero

3AlessandraMondella13/06/1970 FSoltera

Hijos

nmero_personanombre_apellidoedadsexo

2Maria Rossi3F

2Gianni Rossi5M

RESTRICT (Personas)sexo='M'

nmero_personanombreapellidofecha_nacimientosexoestado_civil

2MarioRossi29/03/1965MCasado

1GiuseppeRusso15/11/1972MSoltero

Las bases de datos relacionales efectan todas las operaciones en las tablas usando el lgebra relacional, aunque normalmente no le permiten al usuario usarla. El usuario interacciona con la base de datos a travs de una interfaz diferente el lenguaje SQL, un lenguaje declarativo que permite escribir conjuntos de datos. Las instrucciones SQL vienen descompuestas por el motor de datos en una serie de operaciones relacionales.

3.2. Proceso de normalizacin

El proceso de normalizacin es un estndar que consiste, bsicamente, en un proceso de conversin de las relaciones entre las entidades, evitando:

La redundancia de los datos: repeticin de datos en un sistema. Anomalas de actualizacin: inconsistencias de los datos como resultado de datos redundantes y actualizaciones parciales.

Anomalas de borrado: prdidas no intencionadas de datos debido a que se han borrado otros datos.

Anomalas de insercin: imposibilidad de adicionar datos en la base de datos debido a la ausencia de otros datos.

Tomando como referencia la tabla siguiente:

AUTORES Y LIBROS

NOMBRENACIONCODLIBROTITULOEDITOR

DateUSA999IBDAW

Ad.Mig.ESP888CyDRM

Ma.Piat.ITA777CyDRM

DateUSA666BdDAW

Se plantean una serie de problemas:

Redundancia: cuando un autor tiene varios libros, se repite la nacionalidad.

Anomalas de modificacin: Si Ad.Mig. y Ma.Piat. desean cambiar de editor, se modifica en los 2 lugares. A priori no podemos saber cuntos autores tiene un libro. Los errores son frecuentes al olvidar la modificacin de un autor. Se pretende modificar en un slo sitio.

Anomalas de insercin: Se desea dar de alta un autor sin libros, en un principio. NOMBRE y CODLIBRO son campos clave, una clave no puede tomar valores nulos.

Asegurando:

Integridad entre los datos: consistencia de la informacin.

El proceso de normalizacin nos conduce hasta el modelo fsico de datos y consta de varias fases denominadas formas normales, estas formas se detallan a continuacin.

3.2.1. Definicin de la clave

Antes de proceder a la normalizacin de la tabla lo primero que debemos de definir es una clave, esta clave deber contener un valor nico para cada registro (no podrn existir dos valores iguales en toda la tabla) y podr estar formado por un nico campo o por un grupo de campos.

En la tabla de alumnos de un centro de estudios no podemos definir como campo clave el nombre del alumno ya que pueden existir varios alumnos con el mismo nombre. Podramos considerar la posibilidad de definir como clave los campos nombre y apellidos, pero estamos en la misma situacin: podra darse el caso de alumnos que tuvieran los mismo apellidos y el mismo nombre (Juan Fernndez Martn).

La solucin en este caso es asignar un cdigo de alumno a cada uno, un nmero que identifique al alumno y que estemos seguros que es nico.

Una vez definida la clave podremos pasar a estudiar la primera forma normal.

3.2.2. Primera forma normal (1NF)

Se dice que una tabla se encuentra en primera forma normal (1NF) si y solo si cada uno de los campos contiene un nico valor para un registro determinado. Supongamos que deseamos realizar una tabla para guardar los cursos que estn realizando los alumnos de un determinado centro de estudios, podramos considerar el siguiente diseo:

CdigoNombreCursos

1MarcosIngls

2LucasContabilidad, Informtica

3MartaIngls, Contabilidad

Podemos observar que el registro de cdigo 1 si cumple la primera forma normal, cada campo del registro contiene un nico dato, pero no ocurre as con los registros 2 y 3 ya que en el campo cursos contiene ms de un dato cada uno. La solucin en este caso es crear dos tablas del siguiente modo:

TABLA ATABLA B

CdigoNombreCdigoCurso

1Marcos1Ingls

2Lucas2Contabilidad

3Marta2Informtica

3Ingls

3Informtica

Como se puede comprobar ahora todos los registros de ambas tablas contienen valores nicos en sus campos, por lo tanto ambas tablas cumplen la primera forma normal.

Una vez normalizada la tabla en 1NF, podemos pasar a la segunda forma normal.

3.2.3. Segunda forma normal (2NF)

La segunda forma normal compara todos y cada uno de los campos de la tabla con la clave definida. Si todos los campos dependen directamente de la clave se dice que la tabla est es segunda forma normal (2NF).

Supongamos que construimos una tabla con los aos que cada empleado ha estado trabajando en cada departamento de una empresa:

Cdigo EmpleadoCdigo Dpto.NombreDepartamentoAos

16JuanContabilidad6

23PedroSistemas3

32SoniaI+D1

43VernicaSistemas10

26PedroContabilidad5

Tomando como punto de partida que la clave de esta tabla est formada por los campos cdigo de empleado y cdigo de departamento, podemos decir que la tabla se encuentra en primera forma normal, por tanto vamos a estudiar la segunda:

1. El campo nombre no depende funcionalmente de toda la clave, slo depende del cdigo del empleado.

2. El campo departamento no depende funcionalmente de toda la clave, slo del cdigo del departamento.

3. El campo aos si que depende funcionalmente de la clave ya que depende del cdigo del empleado y del cdigo del departamento (representa el nmero de aos que cada empleado ha trabajado en cada departamento)

Por tanto, al no depender todos los campos de la totalidad de la clave la tabla no est en segunda forma normal, la solucin es la siguiente:

Tabla ATabla BTabla C

Cdigo EmpleadoNombreCdigo DepartamentoDpto.Cdigo EmpleadoCdigo DepartamentoAos

1Juan2I+D166

2Pedro3Sistemas233

3Sonia6Contabilidad321

4Vernica4310

265

Podemos observar que ahora si se encuentras las tres tabla en segunda forma normal, considerando que la tabla A tiene como ndice el campo Cdigo Empleado, la tabla B Cdigo Departamento y la tabla C una clave compuesta por los campos Cdigo Empleado y Cdigo Departamento.

3.2.4. Tercera forma normal (3NF)

Se dice que una tabla est en tercera forma normal si y solo si los campos de la tabla dependen nicamente de la clave, dicho en otras palabras los campos de las tablas no dependen unos de otros. Tomando como referencia el ejemplo anterior, supongamos que cada alumno slo puede realizar un nico curso a la vez y que deseamos guardar en que aula se imparte el curso. A voz de pronto podemos plantear la siguiente estructura:

CdigoNombreCursoAula

1MarcosInformticaAula A

2LucasInglsAula B

3MartaContabilidadAula C

Estudiemos la dependencia de cada campo con respecto a la clave cdigo:

Nombre depende directamente del cdigo del alumno.

Curso depende de igual modo del cdigo del alumno.

El aula, aunque en parte tambin depende del alumno, est mas ligado al curso que el alumno est realizando.

Por esta ltima razn se dice que la tabla no est en 3NF. La solucin sera la siguiente:

Tabla ATabla B

CdigoNombreCursoCursoAula

1MarcosInformticaInformticaAula A

2LucasInglsInglsAula B

3MartaContabilidadContabilidadAula C

Una vez conseguida la segunda forma normal, se puede estudiar la cuarta forma normal.

3.2.5. Cuarta forma normal (4NF)

Una tabla est en cuarta forma normal si y slo si para cualquier combinacin clave - campo no existen valores duplicados. Vemoslo con un ejemplo:

Geometra

FiguraColorTamao

CuadradoRojoGrande

CuadradoAzulGrande

CuadradoAzulMediano

CrculoBlancoMediano

CrculoAzulPequeo

CrculoAzulMediano

Comparemos ahora la clave (Figura) con el atributo Tamao, podemos observar que Cuadrado Grande est repetido; igual pasa con Crculo Azul, entre otras. Estas repeticiones son las que se deben evitar para tener una tabla en 4NF.

La solucin en este caso sera la siguiente:

TamaoColor

FiguraTamaoFiguraColor

CuadradoGrandeCuadradoRojo

CuadradoPequeoCuadradoAzul

CrculoMedianoCrculoBlanco

CrculoPequeoCrculoAzul

3.2.6. Otras formas normales

Existen otras dos formas normales, la llamada quinta forma normal (5FN) que no detallo por su dudoso valor prctico ya que conduce a una gran divisin de tablas y la forma normal dominio / clave (FNDLL) de la que no existe mtodo alguno para su implantacin.

3.3. Las interrelaciones

Las interrelaciones son las relaciones que existen entre varias tablas del sistema (Clientes y Pedidos, por ejemplo). Existen tres formas de interrelaciones dependiendo de la cardinalidad con la que se combinan los elementos de ambas tablas.

3.3.1. Interrelaciones uno a uno

Una interrelacin es de uno a uno entre la tabla A y la tabla B cuando a cada elemento de la clave de A se le asigna un nico elemento de la tabla B y para cada elemento de la clave de la tabla B contiene un nico elemento en la tabla A. Un ejemplo de interrelacin de este tipo es la formada por las tablas Datos Generales de Clientes y Datos Contables de Clientes. En esta relacin cada cliente tiene una nica direccin y una direccin en cada una de las tablas. Representamos la relacin como A 1: 1 B.

Ante la presencia de este tipo de relacin nos podemos plantear el caso de unificar todos los datos en nica tabla pues no es necesario mantener ambas tablas a la misma vez.

Este tipo de relacin se genera cuando aparecen tablas muy grandes, con gran cantidad de campos, disgregando la tabla principal en dos para evitar tener una tabla muy grande. Tambin surge cuando los diferentes grupos de usuario cumplimentan una informacin diferente para un mismo registros; en este caso se crean tantas tablas como registros, evitando as tener que acceder a informacin que el usuario del grupo actual no necesita.

3.3.2. Interrelaciones uno a varios

Una interrelacin es de uno a varios entre las tablas A y B cuando una clave de la tabla A posee varios elementos relacionados en la tabla B y cuando una clave de la tabla B posee un nico elemento relacionado en la tabla A.

Estudiemos la relacin entre la tabla de clientes y la tabla de pedidos. Un cliente puede realizar varios pedidos pero un pedido pertenece a un nico cliente, por tanto se trata de una relacin uno a varios y la representamos A 1: n B.

Estas relaciones suelen surgir de aplicar la 1NF a una tabla.

3.3.3. Interrelaciones varios a varios

Una interrelacin es de varios a varios entre las tablas A y B cuando una clave de la tabla A posee varios elementos relacionados en la tabla B y cuando una clave de la tabla B posee varios elementos relacionados en la tabla A.

Un caso muy caracterstico de esta interrelacin es la que surge entre las tablas de Puestos de Trabajo y Empleados de una empresa. Un Empleado puede desempear realizar varias funciones dentro de una empresa (desempear varios puestos de trabajo), y un puesto de trabajo puede estar ocupado por varios empleados a la misma vez. Esta interrelacin la representamos como A n: n B.

No se deben definir relaciones de este tipo en un sistema de bases de datos, debido a su complejidad a la hora de su mantenimiento, por este motivo se debe transformar este tipo de relacin es dos interrelaciones de tipo 1: n, empleando para ello una tabla que denominaremos puente y que estar formada por las claves de ambas tablas. Esta tabla puente debe contener una nica clave compuesta formada por los campos clave de las tablas primeras.

EmpleadosPuestos

Cdigo EmpleadoEmpleadoCdigo PuestoPuesto

103Juan52Comercial

105Luisa73Administrativo

251Martn

736Ana Mara

Tabla Puente

Cdigo EmpleadoCdigo Puesto

10352

10373

10573

25152

73652

73673

Ahora existe una relacin 1: n entre Empleados y Tabla Puente y otra relacin 1: n entre Puestos y Tabla Puente ya que un empleado posee varios cdigos de empleado en la tabla puente pero cada elemento de la tabla puente pertenece a un nico empleado.

Por otro la un puesto de trabajo posee varios elementos relacionados en la tabla puente, pero cada elemento de la tabla puente est relacionado con un nico elemento de la tabla puestos.

3.3.4. Problemas con las interrelaciones

A la hora de establecer las interrelaciones existentes en un sistema de bases de datos nos podemos encontrar dos problemas:

1. Interrelaciones recursivas: un elemento se relaciona consigo mismo directamente.

2. Interrelaciones circulares o cclicas: A se relaciona con B, B se relaciona con C y C se relaciona con A.

Ambos casos pueden suponer un grave problema si definimos una relacin con integridad referencial y decimos eliminar en cascada (al eliminar una clave de la tabla A se eliminan los elementos relacionados en la tabla B). Supongamos la relacin recursiva existen en la relacin Empleado y Supervisor (ambos son empleados de la empresa). Est claro que un empleado est supervisado por otro empleado. Veamos la forma de solucionarlo:

Empleados

CdigoNombreSupervisor

102JuanNO

105LuisSI

821MaraNO

956MartnSI

Para solucionar la relacin debemos crear una tabla formada por dos campos. Ambos campos deben ser el cdigo del empleado pero como no podemos tener dos campos con el mismo nombre a uno de ellos le llamaremos cdigo supervisor.

Tabla Puente

Cdigo EmpleadoCdigo Supervisor

102105

105956

821105

956105

Para terminar de resolver la interrelacin recursiva basta con definir dos interrelaciones entre la tabla empleados y la tabla puente de tipo 1: n. La primera relacin se crea utilizando las claves Empleados[Cdigo] y Tabla Puente[Cdigo Empleado]. La segunda entre Empleados[Cdigo] y Tabla Puente [Cdigo Supervisor].

Las interrelaciones cclicas o circulares no son muy frecuentes y no existe una metodologa estndar para su eliminacin, normalmente son debidas a errores de diseo en la base de datos, principalmente en el diseo conceptual del sistema de datos. Por tanto si llegamos a este punto hay que volver a replantearse todo el diseo de la base de datos.

3.3.5. Atributos de las interrelaciones

En la mayora de las interrelaciones definidas ser conveniente exigir integridad relacional entre las claves. Exigiendo la integridad referencial se consigue que en una relacin de tipo 1: n o de tipo 1: 1, no se puede aadir ningn valor en la tabla destino si no existe en la tabla origen. Dicho con un ejemplo: en la relacin Clientes y Pedidos la tabla Pedidos contiene un campo que se corresponde con el cdigo del Cliente, si se exige la integridad referencial no se podr escribir un cdigo de cliente en la tabla Pedidos que no exista en la tabla Clientes; de no exigir la integridad referencial se podrn crear pedidos con cdigos de clientes que no existen, generando incongruencia de datos en la base de datos.

Definida la integridad referencial (siempre necesaria) podemos exigir la actualizacin en cascada (siempre necesaria); esta actualizacin implica que si cambiamos el cdigo a un cliente, debemos actualizar dicho cdigo en la tabla de pedidos, de no ser as, al cambiar el cdigo a un cliente, perderemos los pedidos que tena realizados.

Para concluir debemos hablar de la eliminacin en cascada (NO siempre necesaria), la eliminacin en cascada consiste en eliminar todos los datos dependientes de una clave. En nuestro ejemplo implica que al borrar un cliente hay que eliminar todos los pedidos que ha realizado. En muchas ocasiones no interesa realizar esta operacin de eliminacin en cascada por motivos diversos. Si en el caso de clientes y pedidos no se exige eliminacin en cascada no se podr borrar ningn cliente en tanto en cuanto tenga realizado algn pedido (de lo contrario tendramos incongruencia de datos).

3.4. Algebra relacional

Las operaciones de lgebra relacional manipulan relaciones. Esto significa que estas operaciones usan uno o dos relaciones existentes para crear una nueva relacin. Esta nueva relacin puede entonces usarse como entrada para una nueva operacin. Este poderoso concepto - la creacin de una nueva relacin a partir de relaciones existentes hace considerablemente ms fcil la solucin de las consultas, debido a que se puede experimentar con soluciones parciales hasta encontrar la proposicin con la que se trabajar.

El lgebra relacional consta de nueve operaciones:

1. Unin

2. Interseccin

3. Diferencia

4. Producto

5. Seleccin

6. Proyeccin

7. Reunin

8. Divisin

9. Asignacin

Las cuatro primeras se toman de la teora de conjunto de las matemticas; las cuatro siguientes son operaciones propias del lgebra relacional y la ltima es la operacin estndar de dar un valor a un elemento.

3.4.1. Unin

La operacin de unin permite combinar datos de varias relaciones. Supongamos que una determinada empresa internacional posee una tabla de empleados para cada uno de los pases en los que opera. Para conseguir un listado completo de todos los empleados de la empresa tenemos que realizar una unin de todas las tablas de empleados de todos los pases.

No siempre es posible realizar consultas de unin entre varias tablas, para poder realizar esta operacin es necesario e imprescindible que las tablas a unir tengan las mismas estructuras, que sus campos sean iguales.

3.4.2. Interseccin

La operacin de interseccin permite identificar filas que son comunes en dos relaciones. Supongamos que tenemos una tabla de empleados y otra tabla con los asistentes que han realizado un curso de ingls (los asistentes pueden ser empleados o gente de la calle). Queremos crear una figura virtual en la tabla denominada "Empleados que hablan Ingls", esta figura podemos crearla realizando una interseccin de empleados y curso de ingls, los elementos que existan en ambas tablas sern aquellos empleados que han asistido al curso.

3.4.3. Diferencia

La operacin diferencia permite identificar filas que estn en una relacin y no en otra. Tomando como referencia el caso anterior, deberamos aplicar una diferencia entre la tabla empleados y la tabla asistentes al curso para saber aquellos asistentes externos a la organizacin que han asistido al curso.

3.4.4. Producto

La operacin producto consiste en la realizacin de un producto cartesiano entre dos tablas dando como resultado todas las posibles combinaciones entre los registros de la primera y los registros de la segunda. Esta operacin se entiende mejor con el siguiente ejemplo:

Tabla ATabla B

XYWZ

10223354

11253798

42100

El producto de A * B dara como resultado la siguiente tabla:

Tabla A * Tabla B

XYWZ

10223354

10223798

102242100

11253354

11253798

112542100

3.4.5. Seleccin

La operacin seleccin consiste en recuperar un conjunto de registros de una tabla o de una relacin indicando las condiciones que deben cumplir los registros recuperados, de tal forma que los registros devueltos por la seleccin han de satisfacer todas las condiciones que se hayan establecido. Esta operacin es la que normalmente se conoce como consulta.

Podemos emplearla para saber que empleados son mayores de 45 aos, o cuales viven en Madrid, incluso podemos averiguar los que son mayores de 45 aos y residen en Madrid, los que son mayores de 45 aos y no viven en Madrid, etc..

En este tipo de consulta se emplean los diferentes operadores de comparacin (=,>, =, 1000

Si no se indica lo contrario, no se devuelven registros duplicados cuando se utiliza la operacin UNION, no obstante puede incluir el predicado ALL para asegurar que se devuelven todos los registros. Esto hace que la consulta se ejecute ms rpidamente. Todas las consultas en una operacin UNION deben pedir el mismo nmero de campos, no obstante los campos no tienen porqu tener el mismo tamao o el mismo tipo de datos.

Se puede utilizar una clusula GROUP BY y/o HAVING en cada argumento consulta para agrupar los datos devueltos. Puede utilizar una clusula ORDER BY al final del ltimo argumento consulta para visualizar los datos devueltos en un orden especfico.

SELECT

NombreCompania, Ciudad

FROM

Proveedores

WHERE

Pais = 'Brasil'

UNION

SELECT NombreCompania, Ciudad

FROM Clientes

WHERE Pais = 'Brasil'

(Recupera los nombres y las ciudades de todos proveedores y clientes de Brasil)

SELECT

NombreCompania, Ciudad

FROM

Proveedores

WHERE

Pais = 'Brasil'

UNION

SELECT NombreCompania, Ciudad

FROM Clientes

WHERE Pais = 'Brasil'

ORDER BY Ciudad

(Recupera los nombres y las ciudades de todos proveedores y clientes radicados en Brasil, ordenados por el nombre de la ciudad)

SELECT

NombreCompania, Ciudad

FROM

Proveedores

WHERE

Pais = 'Brasil'

UNION

SELECT NombreCompania, Ciudad

FROM Clientes

WHERE Pais = 'Brasil'

UNION

SELECT Apellidos, Ciudad

FROM Empleados

WHERE Region = 'Amrica del Sur'

(Recupera los nombres y las ciudades de todos los proveedores y clientes de brasil y los apellidos y las ciudades de todos los empleados de Amrica del Sur)

TABLE

Lista_Clientes

UNION TABLE

ListaProveedores

(Recupera los nombres y cdigos de todos los proveedores y clientes)

4.6. Consultas de Referencias Cruzadas

4.6.1. ACCESS

Una consulta de referencias cruzadas es aquella que nos permite visualizar los datos en filas y en columnas, estilo tabla, por ejemplo:

Producto / Ao19961997

Pantalones1.2503.000

Camisas8.5601.253

Zapatos4.3692.563

Si tenemos una tabla de productos y otra tabla de pedidos, podemos visualizar en total de productos pedidos por ao para un artculo determinado, tal y como se visualiza en la tabla anterior. La sintaxis para este tipo de consulta es la siguiente:

TRANSFORM funcin agregada instruccin select PIVOT campo pivot

[IN (valor1[, valor2[, ...]])]

En donde:

funcin agregadaEs una funcin SQL agregada que opera sobre los datos seleccionados.

instruccin selectEs una instruccin SELECT.

campo pivotEs el campo o expresin que desea utilizar para crear las cabeceras de la columna en el resultado de la consulta.

valor1, valor2Son valores fijos utilizados para crear las cabeceras de la columna.

Para resumir datos utilizando una consulta de referencia cruzada, se seleccionan los valores de los campos o expresiones especificadas como cabeceras de columnas de tal forma que pueden verse los datos en un formato ms compacto que con una consulta de seleccin.

TRANSFORM es opcional pero si se incluye es la primera instruccin de una cadena SQL. Precede a la instruccin SELECT que especifica los campos utilizados como encabezados de fila y una clusula GROUP BY que especifica el agrupamiento de las filas. Opcionalmente puede incluir otras clusulas como por ejemplo WHERE, que especifica una seleccin adicional o un criterio de ordenacin.

Los valores devueltos en campo pivot se utilizan como encabezados de columna en el resultado de la consulta. Por ejemplo, al utilizar las cifras de ventas en el mes de la venta como pivot en una consulta de referencia cruzada se crearan 12 columnas. Puede restringir el campo pivot para crear encabezados a partir de los valores fijos (valor1, valor2) listados en la clusula opcional IN.

Tambin puede incluir valores fijos, para los que no existen datos, para crear columnas adicionales.

Ejemplos

TRANSFORM

Sum(Cantidad) AS Ventas

SELECT

Producto, Cantidad

FROM

Pedidos

WHERE

Fecha Between #01-01-1998# And #12-31-1998#

GROUP BY

Producto

ORDER BY

Producto

PIVOT

DatePart("m", Fecha)

(Crea una consulta de tabla de referencias cruzadas que muestra las ventas de productos por mes para un ao especfico. Los meses aparecen de izquierda a derecha como columnas y los nombres de los productos aparecen de arriba hacia abajo como filas.)

TRANSFORM

Sum(Cantidad) AS Ventas

SELECT

Compania

FROM

Pedidos

WHERE

Fecha Between #01-01-1998# And #12-31-1998#

GROUP BY

Compania

ORDER BY

Compania

PIVOT

"Trimestre " &

DatePart("q", Fecha)

In ('Trimestre1', 'Trimestre2', 'Trimestre 3', 'Trimestre 4')

(Crea una consulta de tabla de referencias cruzadas que muestra las ventas de productos por trimestre de cada proveedor en el ao indicado. Los trimestres aparecen de izquierda a derecha como columnas y los nombres de los proveedores aparecen de arriba hacia abajo como filas.)

Un caso prctico:

Se trata de resolver el siguiente problema: tenemos una tabla de productos con dos campos, el cdigo y el nombre del producto, tenemos otra tabla de pedidos en la que anotamos el cdigo del producto, la fecha del pedido y la cantidad pedida. Deseamos consultar los totales de producto por ao, calculando la media anual de ventas.

Estructura y datos de las tablas:

ARTICULOSPEDIDOS

IDNombreIDFechaCantidad

1Zapatos111/11/1996250

2Pantalones211/11/1996125

3Blusas311/11/1996520

112/10/199650

204/10/1996250

305/08/1996100

101/01/199740

202/08/199760

305/10/199770

112/12/19978

215/12/1997520

317/10/19971.250

Para resolver la consulta planteamos la siguiente consulta:

TRANSFORM

Sum(Pedidos.Cantidad) AS Resultado

SELECT

Nombre AS Producto, Pedidos.Id AS Cdigo,

Sum(Pedidos.Cantidad) AS TOTAL,

Avg(Pedidos.Cantidad) AS Media

FROM

Pedidos, Artculos

WHERE

Pedidos.Id = Artculos.Id

GROUP BY

Pedidos.Id, Artculos.Nombre

PIVOT

Year(Fecha)

Y obtenemos el siguiente resultado:

ProductoCdigoTotalMedia19961997

Zapatos13488730048

Pantalones2955238,75375580

Blusas319404856201320

Comentarios a la consulta:

La clusula TRANSFORM indica el valor que deseamos visualizar en las columnas que realmente pertenecen a la consulta, en este caso 1996 y 1997, puesto que las dems columnas son opcionales. SELECT especifica el nombre de las columnas opcionales que deseamos visualizar, en este caso Producto, Cdigo, Total y Media, indicando el nombre del campo que deseamos mostrar en cada columna o el valor de la misma. Si incluimos una funcin de clculo el resultado se har basndose en los datos de la fila actual y no al total de los datos.

FROM especifica el origen de los datos. La primera tabla que debe figurar es aquella de donde deseamos extraer los datos, esta tabla debe contener al menos tres campos, uno para los ttulos de la fila, otros para los ttulos de la columna y otro para calcular el valor de las celdas.

En este caso en concreto se deseaba visualizar el nombre del producto, como en la tabla de pedidos slo figuraba el cdigo del mismo se aadi una nueva columna en la clusula select llamada Producto que se corresponda con el campo Nombre de la tabla de artculos. Para vincular el cdigo del artculo de la tabla de pedidos con el nombre del mismo de la tabla artculos se insert la clusula INNER JOIN.

La clusula GROUP BY especifica el agrupamiento de los registros, contrariamente a los manuales de instruccin esta clusula no es opcional ya que debe figurar siempre y debemos agrupar los registros por el campo del cual extraemos la informacin. En este caso existen dos campos de los que extraemos la informacin: pedidos.cantidad y artculos.nombre, por ello agrupamos por los campos.

Para finalizar la clusula PIVOT indica el nombre de las columnas no opcionales, en este caso 1996 y 1997 y como vamos a el dato que aparecer en las columnas, en este caso empleamos el ao en que se produjo el pedido, extrayndolo del campo pedidos.fecha.

Otras posibilidades de fecha de la clusula pivot son las siguientes:

1. Para agrupamiento por Trimestres:PIVOT "Tri " & DatePart("q",[Fecha]);

2. Para agrupamiento por meses (sin tener en cuenta el ao) PIVOT Format([Fecha],"mmm") In ("Ene", "Feb", "Mar", "Abr", "May", "Jun", "Jul", "Ago", "Sep", "Oct", "Nov", "Dic");

3. Para agrupar por dasPIVOT Format([Fecha],"Short Date");

4.7. Criterios de Seleccin

En el apartado anterior se vio la forma de recuperar los registros de las tablas, las formas empleadas devolvan todos los registros de la mencionada tabla. A lo largo de este apartado se estudiarn las posibilidades de filtrar los registros con el fin de recuperar solamente aquellos que cumplan unas condiciones preestablecidas.

Antes de comenzar el desarrollo de este apartado hay que recalcar tres detalles de vital importancia. El primero de ellos es que cada vez que se desee establecer una condicin referida a un campo de texto la condicin de bsqueda debe ir encerrada entre comillas simples; la segunda es que no es posible establecer condiciones de bsqueda en los campos memo y; la tercera y ltima hace referencia a las fechas. A da de hoy no he sido capaz de encontrar una sintaxis que funcione en todos los sistemas, por lo que se hace necesario particularizarlas segn el banco de datos:

Banco de DatosSintaxis

SQL-SERVERFecha = #mm-dd-aaaa#

ORACLEFecha = to_date('YYYYDDMM','aaaammdd',)

ACCESSFecha = #mm-dd-aaaa#

Ejemplo

Banco de DatosEjemplo (para grabar la fecha 18 de mayo de 1969)

SQL-SERVERFecha = #05-18-1969# Fecha = 19690518

ORACLEFecha = to_date('YYYYDDMM', '19690518')

ACCESSFecha = #05-18-1969#

Referente a los valores lgicos True o False cabe destacar que no son reconocidos en ORACLE, ni en este sistema de bases de datos ni en SQL-SERVER existen los campos de tipo "SI/NO" de ACCESS; en estos sistemas se utilizan los campos BIT que permiten almacenar valores de 0 1. Internamente, ACCESS, almacena en estos campos valores de 0 -1, as que todo se complica bastante, pero aprovechando la coincidencia del 0 para los valores FALSE, se puede utilizar la sintaxis siguiente que funciona en todos los casos: si se desea saber si el campo es falso "... CAMPO = 0" y para saber los verdaderos "CAMPO 0".

4.7.1. Operadores Lgicos

Los operadores lgicos soportados por SQL son: AND, OR, XOR, Eqv, Imp, Is y Not. A excepcin de los dos ltimos todos poseen la siguiente sintaxis:

operador

En donde expresin1 y expresin2 son las condiciones a evaluar, el resultado de la operacin vara en funcin del operador lgico. La tabla adjunta muestra los diferentes posibles resultados:

OperadorResultado

VerdadANDFalsoFalso

VerdadANDVerdadVerdad

FalsoANDVerdadFalso

FalsoANDFalsoFalso

VerdadORFalsoVerdad

VerdadORVerdadVerdad

FalsoORVerdadVerdad

FalsoORFalsoFalso

VerdadXORVerdadFalso

VerdadXORFalsoVerdad

FalsoXORVerdadVerdad

FalsoXORFalsoFalso

VerdadEqvVerdadVerdad

VerdadEqvFalsoFalso

FalsoEqvVerdadFalso

FalsoEqvFalsoVerdad

VerdadImpVerdadVerdad

VerdadImpFalsoFalso

VerdadImpNullNull

FalsoImpVerdadVerdad

FalsoImpFalsoVerdad

FalsoImpNullVerdad

NullImpVerdadVerdad

NullImpFalsoNull

NullImpNullNull

Si a cualquiera de las anteriores condiciones le anteponemos el operador NOT el resultado de la operacin ser el contrario al devuelto sin el operador NOT.

El ltimo operador denominado Is se emplea para comparar dos variables de tipo objeto Is . este operador devuelve verdad si los dos objetos son iguales.

SELECT *

FROM

Empleados

WHERE

Edad > 25 AND Edad < 50

SELECT *

FROM

Empleados

WHERE

(Edad > 25 AND Edad < 50)

OR

Sueldo = 100

SELECT *

FROM

Empleados

WHERE

NOT Estado = 'Soltero'

SELECT *

FROM

Empleados

WHERE

(Sueldo > 100 AND Sueldo < 500)

OR

(Provincia = 'Madrid' AND Estado = 'Casado')

4.7.2. Valores Nulos

En muchas ocasiones es necesario emplear como criterio de seleccion valores nulos en los campos. Podemos emplear el operacion IS NULL para realizar esta operacin. Por ejemplo:

SELECT *

FROM

Empleados

WHERE

DNI IS NULL

Este operador no est reconocido en ACCESS y por ello hay que utilizar la siguiente sintaxis:

SELECT *

FROM

Empleados

WHERE

IsNull(DNI)=True

4.7.3. Intervalos de Valores

Para indicar que deseamos recuperar los registros segn el intervalo de valores de un campo emplearemos el operador Between cuya sintaxis es:

campo [Not] Between valor1 And valor2 (la condicin Not es opcional)

En este caso la consulta devolvera los registros que contengan en "campo" un valor incluido en el intervalo valor1, valor2 (ambos inclusive). Si anteponemos la condicin Not devolver aquellos valores no incluidos en el intervalo.

SELECT *

FROM

Pedidos

WHERE

CodPostal Between 28000 And 28999

(Devuelve los pedidos realizados en la provincia de Madrid)

4.7.4. El Operador Like

Se utiliza para comparar una expresin de cadena con un modelo en una expresin SQL. Su sintaxis es:

expresin Like modelo

En donde expresin es una cadena modelo o campo contra el que se compara expresin. Se puede utilizar el operador Like para encontrar valores en los campos que coincidan con el modelo especificado. Por modelo puede especificar un valor completo (Ana Mara), o se puede utilizar una cadena de caracteres comodn como los reconocidos por el sistema operativo para encontrar un rango de valores (Like An*).

El operador Like se puede utilizar en una expresin para comparar un valor de un campo con una expresin de cadena. Por ejemplo, si introduce Like C* en una consulta SQL, la consulta devuelve todos los valores de campo que comiencen por la letra C. En una consulta con parmetros, puede hacer que el usuario escriba el modelo que se va a utilizar.

El ejemplo siguiente devuelve los datos que comienzan con la letra P seguido de cualquier letra entre A y F y de tres dgitos:

Like 'P[A-F]###'

Este ejemplo devuelve los campos cuyo contenido empiece con una letra de la A a la D seguidas de cualquier cadena.

Like '[A-D]*'

En la tabla siguiente se muestra cmo utilizar el operador Like para comprobar expresiones con diferentes modelos.

ACCESS

Tipo de coincidenciaModelo PlanteadoCoincideNo coincide

Varios caracteres'a*a''aa', 'aBa', 'aBBBa''aBC'

Carcter especial'a[*]a''a*a''aaa'

Varios caracteres'ab*''abcdefg', 'abc''cab', 'aab'

Un solo carcter'a?a''aaa', 'a3a', 'aBa''aBBBa'

Un solo dgito'a#a''a0a', 'a1a', 'a2a''aaa', 'a10a'

Rango de caracteres'[a-z]''f', 'p', 'j''2', '&'

Fuera de un rango'[!a-z]''9', '&', '%''b', 'a'

Distinto de un dgito'[!0-9]''A', 'a', '&', '~''0', '1', '9'

Combinada'a[!b-m]#''An9', 'az0', 'a99''abc', 'aj0'

SQL-SERVER

EjemploDescripcin

LIKE 'A%'Todo lo que comience por A

LIKE '_NG'Todo lo que comience por cualquier carcter y luego siga NG

LIKE '[AF]%'Todo lo que comience por A F

LIKE '[A-F]%'Todo lo que comience por cualquier letra comprendida entre la A y la F

LIKE '[A^B]%'Todo lo que comience por A y la segunda letra no sea una B

En determinado motores de bases de datos, esta clusula, no reconoce el asterisco como carcter comodn y hay que sustituirlo por el carcter tanto por ciento (%).

4.7.5. El Operador In

Este operador devuelve aquellos registros cuyo campo indicado coincide con alguno de los en una lista. Su sintaxis es:

expresin [Not] In(valor1, valor2, . . .)

SELECT *

FROM

Pedidos

WHERE

Provincia In ('Madrid', 'Barcelona', 'Sevilla')

4.7.6. La clusula WHERE

La clusula WHERE puede usarse para determinar qu registros de las tablas enumeradas en la clusula FROM aparecern en los resultados de la instruccin SELECT. Despus de escribir esta clusula se deben especificar las condiciones expuestas en los apartados anteriores. Si no se emplea esta clusula, la consulta devolver todas las filas de la tabla. WHERE es opcional, pero cuando aparece debe ir a continuacin de FROM.

SELECT

Apellidos, Salario

FROM

Empleados

WHERE

Salario = 21000

SELECT

IdProducto, Existencias

FROM

Productos

WHERE

Existencias 100

AND

NombreProducto Like BOS*

4.8.2. AVG

Calcula la media aritmtica de un conjunto de valores contenidos en un campo especificado de una consulta. Su sintaxis es la siguiente

Avg(expr)

En donde expr representa el campo que contiene los datos numricos para los que se desea calcular la media o una expresin que realiza un clculo utilizando los datos de dicho campo. La media calculada por Avg es la media aritmtica (la suma de los valores dividido por el nmero de valores). La funcin Avg no incluye ningn campo Null en el clculo.

SELECT

Avg(Gastos) AS Promedio

FROM

Pedidos

WHERE

Gastos > 100

4.8.3. Count

Calcula el nmero de registros devueltos por una consulta. Su sintaxis es la siguiente

Count(expr)

En donde expr contiene el nombre del campo que desea contar. Los operandos de expr pueden incluir el nombre de un campo de una tabla, una constante o una funcin (la cual puede ser intrnseca o definida por el usuario pero no otras de las funciones agregadas de SQL). Puede contar cualquier tipo de datos incluso texto.

Aunque expr puede realizar un clculo sobre un campo, Count simplemente cuenta el nmero de registros sin tener en cuenta qu valores se almacenan en los registros. La funcin Count no cuenta los registros que tienen campos null a menos que expr sea el carcter comodn asterisco (*). Si utiliza un asterisco, Count calcula el nmero total de registros, incluyendo aquellos que contienen campos null. Count(*) es considerablemente ms rpida que Count(Campo). No se debe poner el asterisco entre dobles comillas ('*').

SELECT

Count(*) AS Total

FROM

Pedidos

Si expr identifica a mltiples campos, la funcin Count cuenta un registro slo si al menos uno de los campos no es Null. Si todos los campos especificados son Null, no se cuenta el registro. Hay que separar los nombres de los campos con ampersand (&).

SELECT

Count(FechaEnvo & Transporte) AS Total

FROM

Pedidos

Podemos hacer que el gestor cuente los datos diferentes de un determinado campo

SELECT

Count(DISTINCT Localidad) AS Total

FROM

Pedidos

4.8.4. Max, Min

Devuelven el mnimo o el mximo de un conjunto de valores contenidos en un campo especifico de una consulta. Su sintaxis es:

Min(expr)

Max(expr)

En donde expr es el campo sobre el que se desea realizar el clculo. Expr pueden incluir el nombre de un campo de una tabla, una constante o una funcin (la cual puede ser intrnseca o definida por el usuario pero no otras de las funciones agregadas de SQL).

SELECT

Min(Gastos) AS ElMin

FROM

Pedidos

WHERE

Pais = 'Espaa'

SELECT

Max(Gastos) AS ElMax

FROM

Pedidos

WHERE

Pais = 'Espaa'

4.8.5. StDev, StDevP

Devuelve estimaciones de la desviacin estndar para la poblacin (el total de los registros de la tabla) o una muestra de la poblacin representada (muestra aleatoria). Su sintaxis es:

StDev(expr)

StDevP(expr)

En donde expr representa el nombre del campo que contiene los datos que desean evaluarse o una expresin que realiza un clculo utilizando los datos de dichos campos. Los operandos de expr pueden incluir el nombre de un campo de una tabla, una constante o una funcin (la cual puede ser intrnseca o definida por el usuario pero no otras de las funciones agregadas de SQL).

StDevP evala una poblacin, y StDev evala una muestra de la poblacin. Si la consulta contiene menos de dos registros (o ningn registro para StDevP), estas funciones devuelven un valor Null (el cual indica que la desviacin estndar no puede calcularse).

SELECT

StDev(Gastos) AS Desviacin

FROM

Pedidos

WHERE

Pas = 'Espaa'

SELECT

StDevP(Gastos) AS Desviacin

FROM

Pedidos

WHERE

Pas = 'Espaa'

4.8.6. Sum

Devuelve la suma del conjunto de valores contenido en un campo especifico de una consulta. Su sintaxis es:

Sum(expr)

En donde expr representa el nombre del campo que contiene los datos que desean sumarse o una expresin que realiza un clculo utilizando los datos de dichos campos. Los operandos de expr pueden incluir el nombre de un campo de una tabla, una constante o una funcin (la cual puede ser intrnseca o definida por el usuario pero no otras de las funciones agregadas de SQL).

SELECT

Sum(PrecioUnidad * Cantidad) AS Total

FROM

DetallePedido

4.8.7. Var, VarP

Devuelve una estimacin de la varianza de una poblacin (sobre el total de los registros) o una muestra de la poblacin (muestra aleatoria de registros) sobre los valores de un campo. Su sintaxis es:

Var(expr)

VarP(expr)

VarP evala una poblacin, y Var evala una muestra de la poblacin. Expr el nombre del campo que contiene los datos que desean evaluarse o una expresin que realiza un clculo utilizando los datos de dichos campos. Los operandos de expr pueden incluir el nombre de un campo de una tabla, una constante o una funcin (la cual puede ser intrnseca o definida por el usuario pero no otras de las funciones agregadas de SQL)

Si la consulta contiene menos de dos registros, Var y VarP devuelven Null (esto indica que la varianza no puede calcularse). Puede utilizar Var y VarP en una expresin de consulta o en una Instruccin SQL.

SELECT

Var(Gastos) AS Varianza

FROM

Pedidos

WHERE

Pas = 'Espaa'

SELECT

VarP(Gastos) AS Varianza

FROM

Pedidos

WHERE

Pas = 'Espaa'

4.8.8. COMPUTE de SQL-SERVER

Esta clusula aade una fila en el conjunto de datos que se est recuperando, se utiliza para realizar clculos en campos numricos. COMPUTE acta siempre sobre un campo o expresin del conjunto de resultados y esta expresin debe figurar exactamente igual en la clusula SELECT y siempre se debe ordenar el resultado por la misma o al memos agrupar el resultado. Esta expresin no puede utiliz