P. 1
Sistemas Gestores de Bases de Datos

Sistemas Gestores de Bases de Datos

|Views: 1.764|Likes:
Publicado porcfgmesi9097

More info:

Published by: cfgmesi9097 on Nov 26, 2008
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

03/19/2013

pdf

text

original

Adm|n|strac|ón de 8|stemas |nformát|cos

8|stemas Cestores de ßases de 0atos









Profesor: Rafael Lozano Luján

lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
lrd|ce Pád|ra 2 de 20ê
INTRODUCCIÓN A LOS SISTEMAS DE INFORMACIÓN Y A LAS BASES DE DATOS . 7
Concepto de Información ................................................................................................. 7
Sistema de Información.................................................................................................... 7
E|ererlos de ur 3l .................................................................................................................................... 8
Esl(uclu(a de ur 3l..................................................................................................................................... 8
Aplicación de las TIC a los SI......................................................................................... 10
De los sistemas tradicionales de ficheros a las bases de datos.................................... 11
Introducción a las Bases de Datos................................................................................. 11
Ventajas e inconvenientes de las Bases de Datos frete a los ficheros clásicos............ 12
Características de las Bases de Datos .......................................................................... 13
Visiones de los datos en las bases de datos ................................................................. 15
Bases de datos y Sistemas de Gestión de bases de datos ........................................... 17
Principales funciones de un SGBD ................................................................................ 18
Furc|ór de del|r|c|ór o desc(|pc|ór......................................................................................................... 18
Furc|ór de rar|pu|ac|ór ......................................................................................................................... 18
Furc|ór de Corl(o| ................................................................................................................................... 18
Componentes de un SGBD............................................................................................ 19
REPRESENTACIÓN DE PROBLEMAS DEL MUNDO REAL. LOS MODELOS DE
DATOS ........................................................................................................................ 22
Los problemas del mundo real ....................................................................................... 22
La aosl(acc|ór.......................................................................................................................................... 23
Rep(eserlac|ór de |os p(oo|eras de| rurdo (ea| ................................................................................... 23
Ará||s|s de |os p(oo|eras......................................................................................................................... 21
Los Modelos de Datos.................................................................................................... 26
3uorode|os de ur V0............................................................................................................................. 28
Las (esl(|cc|ores de lrled(|dad er |os V0............................................................................................... 28
Los rode|os de dalos er e| d|sero de oases de dalos ........................................................................... 29
EL MODELO ENTIDAD - INTERRELACIÓN ....................................................... 30
Introducción .................................................................................................................... 30
Estática del Modelo Entidad – Interrelación................................................................... 30
Erl|dad..................................................................................................................................................... 31
lrle((e|ac|ór.............................................................................................................................................. 31
Resl(|cc|ores............................................................................................................................................ 31
Semántica de las interrelaciones.................................................................................... 34
Ca(d|ra||dades de ur l|po de erl|dad....................................................................................................... 31
0eperderc|a er ex|slerc|a v er |derl|l|cac|ór......................................................................................... 35
Generalización y Herencia ............................................................................................. 36
Las ca(d|ra||dades er |a je(a(cuia ........................................................................................................... 38
Interrelaciones Exclusivas.............................................................................................. 39
Representación de las Restricciones en el ME-R.......................................................... 40
Dinámica del Modelo Entidad – Interrelación................................................................. 40
EL MODELO RELACIONAL.............................................................................. 41
Estructura del Modelo Relacional................................................................................... 42
0or|r|o v Al(|oulo.................................................................................................................................... 13
0el|r|c|ór lo(ra| de (e|ac|ór.................................................................................................................... 11
C|ases de (e|ac|ór.................................................................................................................................... 15
C|aves ...................................................................................................................................................... 15
Restricciones .................................................................................................................. 46
Resl(|cc|ores |rre(erles.......................................................................................................................... 1ê
Resl(|cc|ores serárl|cas......................................................................................................................... 1ê
Los valores nulos en el modelo relacional ..................................................................... 48
Corceplo de va|o( ru|o ............................................................................................................................ 18
Normalización de Relaciones......................................................................................... 49
0eperderc|as lurc|ora|es ....................................................................................................................... 51
Red|as de ro(ra||zac|ór.......................................................................................................................... 53
Las 12 reglas de Codd para los sistemas relacionales.................................................. 58
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
lrd|ce Pád|ra 3 de 20ê
TRADUCCIÓN DEL MODELO ENTIDAD - INTERRELACIÓN AL MODELO
RELACIONAL.............................................................................................................. 60
Preparación de los esquemas conceptuales.................................................................. 60
E||r|rac|ór de al(|oulos ru|l|p|es............................................................................................................ ê0
E||r|rac|ór de al(|oulos corpueslos....................................................................................................... ê1
Transformación de los esquemas conceptuales............................................................ 62
T(arslo(rac|ór de |os l|pos de erl|dad ................................................................................................... ê2
T(arslo(rac|ór de l|pos de |rle((e|ac|ór uro a uro ................................................................................ ê3
T(arslo(rac|ór de |os l|pos de |rle((e|ac|ór uro a rucros. ................................................................... êê
T(arslo(rac|ór de l|pos de |rle((e|ac|ór rucros a rucros................................................................... êZ
T(arslo(rac|ores de l|pos de |rle((e|ac|ores r-a(|as.............................................................................. ê8
T(arslo(rac|ór de l|pos de |rle((e|ac|ór (el|ex|vas................................................................................. ê9
Eliminación de las relaciones jerárquicas ...................................................................... 70
Álgebra Relacional ......................................................................................................... 78
0pe(ado(es p(|r|l|vos .............................................................................................................................. 80
0pe(ado(es 0e(|vados ............................................................................................................................. 81
0pe(ado(es 0e(|vados ............................................................................................................................. 85
0pe(ado(es (e|ac|ora|es cor va|o(es ru|os ............................................................................................. 8ê
SQL................................................................................................................ 88
Lenguaje estructurado de consultas SQL ...................................................................... 88
l|slo(|a ..................................................................................................................................................... 88
30L coro |erduaje esl(uclu(ado............................................................................................................. 88
Tipos de datos (ORACLE).............................................................................................. 89
Tipos de datos (MySQL)................................................................................................. 91
Operadores SQL ............................................................................................................ 92
0pe(ado(es a(|lrél|cos............................................................................................................................ 92
0pe(ado(es |ód|cos .................................................................................................................................. 92
0pe(ado( de corcalerac|ór..................................................................................................................... 93
La auserc|a de va|o(: NuLL..................................................................................................................... 93
Consultas simples .......................................................................................................... 94
La serlerc|a 3ELECT.............................................................................................................................. 91
Corsu|las serc|||as................................................................................................................................... 95
Co|urras ca|cu|adas ............................................................................................................................... 95
3e|ecc|ór de lodas |as co|urras |3e|ecl ¯) ............................................................................................. 9ê
F||as dup||cadas........................................................................................................................................ 9ê
3e|ecc|ór de l||a. C|áusu|a wlERE......................................................................................................... 9Z
Tesl de corpa(ac|ór |=. <>. <. <=. >. >=) ............................................................................................... 9Z
Tesl de (ardo: 8ETwEEN ....................................................................................................................... 98
Tesl de pe(lererc|a a corjurlo |lN) ......................................................................................................... 98
Tesl de co((esporderc|a cor pal(ór. LlKE.............................................................................................. 99
Tesl de va|o( ru|o |l3 NuLL).................................................................................................................... 99
0(derac|ór de |os (esu|lados de ura corsu|la. C|áusu|a 0R0ER 8Y .................................................. 100
Consultas sumarias ...................................................................................................... 100
Cá|cu|o de| lola| de ura co|urra |3uV)................................................................................................ 101
Cá|cu|o de| p(ored|o de ura co|urra |A\0) ........................................................................................ 101
0ele(r|rac|ór de va|o(es exl(eros....................................................................................................... 101
Cuerla de va|o(es de dalos |C0uNT) ................................................................................................... 102
\a|o(es NuLL v lurc|ores de co|urra .................................................................................................. 102
E||r|rac|ór de l||as dup||cadas |0l3TlNCT) .......................................................................................... 103
Consultas agrupadas.................................................................................................... 103
Cord|c|ores de ouscueda de d(upos. C|áusu|a lA\lN0...................................................................... 105
Subconsultas ................................................................................................................ 106
Tesl de corpa(ac|ór de suocorsu|la |=. <>. <. <=. >. >=) .................................................................... 109
Tesl de pe(lererc|a a corjurlo |lN) ....................................................................................................... 109
Tesl de ex|slerc|a |EXl3T3) .................................................................................................................. 110
Tesl cuarl|l|cados |ANY v ALL) ............................................................................................................. 110
3uocorsu|las ar|dadas .......................................................................................................................... 111
3uocorsu|las er |a c|áusu|a lA\lN0.................................................................................................... 112
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
lrd|ce Pád|ra 1 de 20ê
Consultas multitabla ..................................................................................................... 113
Corsu|las ru|l|lao|a cor c(|le(|os de se|ecc|ór de l||a........................................................................... 111
Vu|l|p|es co|urras de erpa(ejar|erlo................................................................................................. 111
Corsu|las de l(es o rás lao|as.............................................................................................................. 115
Jo|r exle(ro............................................................................................................................................ 115
Actualizaciones de Datos ............................................................................................. 118
Arad|( l||as. 3erlerc|a lN3ERT ............................................................................................................. 118
3up(es|ór de dalos. 3erlerc|a 0ELETE ............................................................................................... 120
Vod|l|cac|ór de dalos. 3erlerc|a uP0ATE........................................................................................... 122
Lenguaje de definición de datos: DDL ......................................................................... 125
C(eac|ór de lao|as. 3erlerc|a C(eale Tao|e.......................................................................................... 125
C(eac|ór de ird|ces. 3erlerc|a C(eale lrdex........................................................................................ 12ê
C(eac|ór de v|slas. 3erlerc|a C(eale \|eW........................................................................................... 12Z
8o((ado de lao|as. ird|ces v v|slas......................................................................................................... 129
Vod|l|cac|ór de ura del|r|c|ór de lao|a. 3erlerc|a ALTER TA8LE ...................................................... 130
Seguridad SQL ............................................................................................................. 131
As|dra( p(|v||ed|os. 3erlerc|a 0RANT................................................................................................... 131
Revocac|ór de p(|v||ed|os. 3erlerc|a RE\0KE..................................................................................... 132
Funciones SQL en Oracle ............................................................................................ 133
Furc|ores de l(alar|erlo ruré(|co....................................................................................................... 133
Furc|ores de l(alar|erlo a|laruré(|co ................................................................................................. 133
Furc|ores de l(alar|erlo de lecras ...................................................................................................... 133
Fo(ralos pa(a R0uN0 v TRuNC pa(a lecras:..................................................................................... 133
Furc|ores de corve(s|ór ....................................................................................................................... 131
0l(as lurc|ores ...................................................................................................................................... 131
Funciones SQL en MySQL........................................................................................... 134
Furc|ores de cadera............................................................................................................................. 131
Furc|ores ruré(|cas ............................................................................................................................. 13ê
Furc|ores de lecra v ro(a..................................................................................................................... 13ê
Furc|ores de corpa(ac|ór .................................................................................................................... 13Z
V|sce|área de lurc|ores........................................................................................................................ 138
MYSQL ........................................................................................................ 139
Introducción .................................................................................................................. 139
Instalación de MySQL en Windows.............................................................................. 139
Corp(ooac|ór de |a |rsla|ac|ór ............................................................................................................. 110
lrle(laz er |irea de corardos............................................................................................................... 111
Instalación de MySQL en Linux.................................................................................... 142
lrsla|ac|ór de ura d|sl(|ouc|ór o|ra(|a ................................................................................................... 112
Corp(ooac|ór de |a |rsla|ac|ór er uNlX/L|rux..................................................................................... 113
Creación y uso de BD en MySQL................................................................................. 144
Creación de tablas........................................................................................................ 144
T|pos de lao|as er Vv30L..................................................................................................................... 11Z
Arad|( (ed|sl(os cor 30L d|(eclarerle er e| erlo(ro de Vv30L ......................................................... 152
lrco(po(a( dalos exle(ros a lao|as Vv30L cor L0A0 0ATA................................................................ 151
Optimize table, replace, set, lock tables y unlock tables.............................................. 155
Visualización de las tablas de una base de datos: show, describe y explain.............. 157
SQL PARA MYSQL. LENGUAJE DE MANIPULACIÓN DE DATOS. .................... 158
Introducción .................................................................................................................. 158
La sentencia SELECT .................................................................................................. 158
C|áusu|a 3ELECT .................................................................................................................................. 159
C|áusu|a lNT0........................................................................................................................................ 1ê0
C|áusu|a FR0V...................................................................................................................................... 1ê1
C|áusu|a wlERE................................................................................................................................... 1ê2
C|áusu|a 0R0uP 8Y ............................................................................................................................. 1ê3
C|áusu|a lA\lN0................................................................................................................................... 1ê3
C|áusu|a 0R0ER 8Y.............................................................................................................................. 1ê1
C|áusu|a LlVlT....................................................................................................................................... 1ê5
Reroro(a( co|urras. C|áusu|a A3....................................................................................................... 1êê
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
lrd|ce Pád|ra 5 de 20ê
Consultas con condiciones de búsqueda..................................................................... 166
Tesl de corpa(ac|ór.............................................................................................................................. 1êZ
Tesl de (ardo: C|áusu|a 8ETwEEN . AN0......................................................................................... 1êZ
Tesl de pe(lererc|a a corjurlo: C|áusu|a lN ......................................................................................... 1ê8
Tesl de co((esporderc|a cor pal(o: C|áusu|a LlKE............................................................................... 1ê8
Tesl de va|o( ru|o: C|áusu|a l3 NuLL .................................................................................................... 1ê9
Cord|c|ores corpueslas. 0pe(ado(es AN0. 0R v N0T....................................................................... 1ê9
Consultas Agrupadas ................................................................................................... 169
Furc|ores de ad(edado er |a ||sla de se|ecc|ór .................................................................................... 1Z0
Furc|ór C0uNT..................................................................................................................................... 1Z1
\a|o(es NuLL er |as lurc|ores de ad(edado......................................................................................... 1Z2
T(alar|erlo de l||as dup||cadas cor 0l3TlNCT ..................................................................................... 1Z2
Ad(upa( l||as cor 0R0uP 8Y ................................................................................................................ 1Z2
Subconsultas en MySQL.............................................................................................. 175
Tesl de corpa(ac|ór de suocorsu|la |=. <>. <. <=. <. >=) .................................................................... 1Z5
Tesl de pe(lererc|a a corjurlo. C|áusu|a lN ......................................................................................... 1Z5
Tesl de ex|slerc|a. C|áusu|a EXl3T3..................................................................................................... 1Zê
Tesl cuarl|l|cado ANY............................................................................................................................ 1Zê
3uocorsu|las ar|dadas .......................................................................................................................... 1ZZ
3uocorsu|las er c|áusu|a lA\lN0........................................................................................................ 1Z8
Consultas multitabla en MySQL................................................................................... 178
Jo|rs de dos lao|as................................................................................................................................. 1Z9
J0lN3 cor c(|le(|os de se|ecc|ór de l||as............................................................................................... 180
J0lN3 cor ru|l|p|es co|urras de erpa(ejar|erlo............................................................................... 180
J0lN3 de l(es o rás lao|as ................................................................................................................... 181
J0lN3 cor cord|c|ores de ouscueda s|r |dua|dad................................................................................ 182
J0lN3 |rle(ros v exle(ros ..................................................................................................................... 182
J0lN EXTERN0 corp|elo ..................................................................................................................... 183
J0lN EXTERN0 |zcu|e(do v de(ecro .................................................................................................... 181
J0lN cor ru|l|p|es co|urras de erpa(ejar|erlo................................................................................. 185
J0lN ar|dados........................................................................................................................................ 185
Actualizaciones de datos.............................................................................................. 186
lrl(oduc|( dalos. 3erlerc|a lN3ERT ...................................................................................................... 18ê
E||r|ra( l||as de dalos. 3erlerc|a 0ELETE........................................................................................... 188
Aclua||zac|ór de dalos. 3erlerc|a uP0ATE.......................................................................................... 188
ADMINISTRACIÓN DE MYSQL...................................................................... 190
Administración de tablas .............................................................................................. 190
Vod|l|cac|ór de lao|as cor ALTER TA8LE............................................................................................ 190
8o((ado de lao|as cor 0R0P TA8LE .................................................................................................... 192
8o((ado de oases de dalos cor 0R0P 0ATA8A3E.............................................................................. 193
Vistas............................................................................................................................ 193
Administración de cuentas de usuario ......................................................................... 193
3erlerc|a 0RANT.................................................................................................................................. 191
3erlerc|a RE\0KE ............................................................................................................................... 195
Corl(aseras red|arle 3ET PA33w0R0............................................................................................. 19ê
Copias de seguridad..................................................................................................... 196
Cop|a de sedu(|dad cor Vv30L0uVP |oac|ups) ................................................................................. 19Z
Recupe(ac|ór de ura oase de dalos...................................................................................................... 19Z
HERRAMIENTAS GRÁFICAS DE MYSQL........................................................ 198
MySQL Administrator ................................................................................................... 198
lrsla|ac|ór de| adr|r|sl(ado( de Vv30L................................................................................................ 198
lrlo(rac|ór de| 3e(v|do( ........................................................................................................................ 200
Corl(o| de| se(v|c|o................................................................................................................................. 200
\a(|ao|es de |r|c|o .................................................................................................................................. 200
Adr|r|sl(ac|ór de usua(|os .................................................................................................................... 200
Corex|ores de| se(v|do(......................................................................................................................... 201
lea|lr..................................................................................................................................................... 201
3e(ve( Lods............................................................................................................................................ 201
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
lrd|ce Pád|ra ê de 20ê
Eslado de |as (ép||cas ............................................................................................................................ 201
8ac|ups.................................................................................................................................................. 201
Reslo(e................................................................................................................................................... 202
Calá|odo................................................................................................................................................. 202
MySQL Query Browser................................................................................................. 202
lrsla|ac|ór de Vv30L 0ue(v 8(oWse( ................................................................................................... 202
MySQL Control Center ................................................................................................. 204


lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 1 - lrl(oducc|ór a |os 3|sleras de lrlo(rac|ór v a |as 8ases de 0alos Pád|ra Z de 20ê
1
|ntroducc|ón a |os 8|stemas de
|nformac|ón y a |as ßases de 0atos
CONCEFIO DE INFOkMACIÓN
Cuanto más grande y complejo es un sistema, más importante es la
comunicación de información entre sus componentes. Disponer de la información
adecuada permite poder tomas las decisiones apropiadas en cada situación. Hay
que diferenciar datos de información. Los datos son representaciones de hechos,
conceptos, etc. La información implica que los datos estén procesados de tal
manera que resulten útiles y tenga sentido para quien los recibe. Los datos por sí
solos no tienen significado. Estos datos necesitan un procesamiento para completar
su significado para que sean significativos, tengan sentido y ayuden a tomar
decisiones.
Llamamos calidad de la información al conjunto de cualidades que ayudan al
receptor a tomar la decisión más ventajosa. Estas propiedades son:
Es relevante para el problema considerado.
Es suficientemente precisa, exacta con la realidad, para confiar en ella.
Es lo suficientemente completa para el problema.
Se comunica a la persona adecuada para la toma de decisión
Se comunica a tiempo para que sea útil.
Llega en el nivel de detalle adecuado.
Es comprensible para el receptor
$I$IEMA DE INFOkMACIÓN
Toda organización, grande o pequeña, necesita una infraestructura para
poder desarrollar sus actividades. Esta estructura organizativa está basada en un
conjunto de funciones que hay que desarrollar y que, entre otras, incluye las
siguientes:
Controlar y gestionar los recursos financieros (dinero) a través de la
función contable y gestión económica.
Comercializar los productos o servicios en los que la empresa basa su
negocio: la actividad comercial y de ventas.
Fabricar productos o crear servicios que venden en el mercado:
departamento de producción.
Todas estas funciones tienen que coordinarse entre sí mediante la gestión y
la intercomunicación de información de calidad. Por ello, las organizaciones incluyen
una infraestructura para coordinar el flujo y registro de información necesarios para
desarrollar sus actividades de acuerdo a una estrategia de negocio. El sistema
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 1 - lrl(oducc|ór a |os 3|sleras de lrlo(rac|ór v a |as 8ases de 0alos Pád|ra 8 de 20ê
dedicado a este cometido es el que se denomina sistema de información (SI) de
la organización.
Los sistemas de información existen desde que existen las organizaciones
humanas. Cuando la Revolución Industrial del siglo XIX trajo la división
especialización del trabajo, las empresas tuvieron que organizar un sistema para
que los distintos departamentos se coordinaran entre sí mediante el intercambio de
información. Antes de la aparición de las Tecnologías de la Información y la
Comunicación, la gestión de la información se apoyaba en herramientas
elementales como papel, lápiz, archivadores y multitud de oficinistas o
administrativos que manejaban ingentes cantidades de impresos, fichas,
correspondencia, con la única ayuda de algunos medios manuales como máquinas
de escribir, calculadoras mecánicas, etc.
Una definición formal de Sistema de Información sería:
Un conjunto formal de procesos, que operando sobre una
colección de datos estructurada según las necesidades de la
empresa, recopilan, elaboran y distribuyen la información, o
parte de ella, necesaria para las operaciones de dicha empresa y
para las actividades de dirección y control correspondientes
(decisiones) para desempeñar su actividad de acuerdo a su
estrategia de negocio.
Elementos de un SI
Los procedimientos y las prácticas habituales del trabajo que se
siguen al ejecutar toda clase de actividades necesarias para el buen
funcionamiento de la empresa. Los directivos y técnicos de una empresa
suelen marcar unos procedimientos básicos para coordinar a los distintos
elementos de la organización. El SI da soporte a la gestión de la
información que hay que proporcionar en función de todas estas formas de
trabajar.
La información. Se debe adaptar a las personas que la manejan y al
equipo disponible, según los procedimientos de trabajo que la empresa ha
creado para que las actividades se realicen de forma eficaz.
Las personas o usuarios. Individuos o grupos de la organización que
introducen, manejan o usan la información para realizar sus actividades en
función de los procedimientos de trabajo establecido.
El equipo de soporte para la comunicación, el procesamiento y el
almacenamiento de información. Constituye la parte más visible del SI.
Puede incluir elementos de los más variados niveles tecnológicos: papel,
lápiz, máquina de escribir, archivadores, ordenadores, cintas magnéticas,
etc.
Estructura de un SI
Aunque la estructura de un SI depende totalmente de la empresa u
organización concreta a la que pertenezca, se puede identificar una base común
que es bastante típica en la mayoría de las empresas. La estructura de casi todas
las empresas se puede describir bastante bien mediante una pirámide en la que se
puede distinguir una jerarquía de diversos niveles de actuación y gestión:
Operaciones y transacciones. Este nivel incluye el procesamiento de las
actividades diarias o transacciones, los acontecimientos rutinarios que
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 1 - lrl(oducc|ór a |os 3|sleras de lrlo(rac|ór v a |as 8ases de 0alos Pád|ra 9 de 20ê
afectan a la organización: facturación, pagos, entrega de productos, etc.
Las transacciones constituyen la mayor parte de las actividades cotidianas
y suelen contar en todas las empresas con características similares:
o Los procedimientos de tratamiento se comprenden bien y se pueden
describir en detalle.
o Aparecen pocas excepciones a los procedimientos normales.
o Hay un gran volumen de transacciones.
o Existe una gran similitud entre transacciones.
Los procedimientos de procesamiento de transacciones se suelen
denominar procedimientos de operación estándar y describen tanto la
rutina de pasos a seguir normalmente como lo que hay que hacer en
caso de que ocurra algo excepcional.
El nivel operativo de dirección se preocupa del análisis de los resultados,
esencialmente respecto de los recursos (dinero, tiempo, personal, etc.)
consumidos en las transacciones, para tomar decisiones a corto plazo y de
consecuencias limitadas (reaprovisionamiento de materiales, ordenación de
la producción, etc.). Se suele trabajar con información procedente del
registro de transacciones cuyas características son:
o Es repetitiva (informes periódicos de ventas, pagos, etc.)
o Centrada en el pasado (resultados históricos)
o Con datos originados internamente.
o Los datos cuentan con un formato bien estructurado
o Los datos son detallados y precisos.
El nivel táctico de dirección se preocupa de al asignación efectiva de
recursos a medio plazo (un año) para mejorar el rendimiento de la
empresa. Generalmente se concentra en el análisis de informes de los tipos
siguientes:
o Resúmenes con medidas estadísticas (media de ventas por
departamento, total de horas extra, etc.)
o De excepciones: aquellos departamentos que han consumido más de la
media, centros con pérdidas, etc.
o Específicos, que no se habían pedido antes y que los directivos necesitan
con rapidez para resolver un problema muy concreto (que se suele
detectar gracias a algún informe de excepciones).
El manejo de información se centra en la información tanto periódica y
rutinaria como excepcional y de necesidad inmediata. Se trabaja con el propósito
de descubrir algo nuevo en los datos, no sólo lo evidente, siempre actuando
sobre información resumida (habitualmente estadísticas) y de naturaleza
comparativa más que descriptiva. Las fuentes de datos son tanto internas (de las
transacciones) como externas (por ejemplo, comparar resultados con los que
ocurren en otras compañías).
El nivel estratégico de dirección trabaja con plazos largos (3-5 años)
para acometer la tarea de decidir las líneas maestras que debe seguir la
empresa en el futuro. La información que se maneja debe aparecer en un
formato muy resumido, con el objetivo de predecir qué será lo mejor para
el éxito futuro de la compañía. Se incluye información en formatos muy
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 1 - lrl(oducc|ór a |os 3|sleras de lrlo(rac|ór v a |as 8ases de 0alos Pád|ra 10 de 20ê
variables e incluso de fuentes externas. Las decisiones que se deben tomar
en este nivel están poco formalizadas y tienen un fuerte componente
subjetivo.
Existen dos grupos principales de flujos de información en la empresa:
horizontales (para la coordinación) y verticales (basados en la jerarquía). Entonces
los tipos flujos que puede haber en una empresa son:
1. Flujos verticales ascendentes, de subordinado a superior. Suelen
consistir en informes sobre resultados de las actividades o de las gestiones
y avisos sobre incidencias. Tienen carácter histórico de orientación al
pasado.
2. Flujos verticales descendentes, de jefe a subordinado. Se tratan de
órdenes: decisiones, objetivos que hay que cumplir, planes que se vana
implantar, etc. También pueden consistir en solicitudes específicas de
información para tomar decisiones o controlar el funcionamiento.
3. Flujos horizontales, entre personas del mismo nivel de autoridad (o sin
relación jerárquica directa), bien entre compañeros del mismo grupo o bien
entre personas de departamentos distintos. Frecuentemente, el contenido
se suele denominar información de coordinación para poder manejar
responsabilidades compartidas. Estos flujos constituyen un medio esencial
para adaptarse mejor al mercado, por lo que actualmente se trata de
fomentar que existan canales horizontales de comunicación ágiles y
eficaces en las empresas. En las organizaciones muy jerárquicas y rígidas
la información no fluye horizontalmente con agilidad.
AFLICACIÓN DE LA$ IIC A LO$ $I
Las empresas han ido incorporando nuevas tecnologías a lo largo del siglo
XX para mejorar el rendimiento y la eficacia de los SI. Se comenzó con máquinas
de escribir, calculadoras mecánicas, teléfonos, cintas de papel perforado, etc. y se
ha llegado ya a utilizar tecnologías sofisticadas de tratamiento y comunicación
genéricamente TIC.
En general, la solución óptima consiste en un SI que cuenta con una mezcla
de actividades, con algunas partes o subsistemas automatizados y otras funciones
que se siguen realizando manualmente: Sistema de Información Automatizado
(SIA).
El SIA deberá contar con un soporte informático para poder funcionar. En
este sentido la informática constituye sólo una herramienta más o menos
sofisticada y completa para implementar lo que está incluido en el SIA.
La automatización de un SI, a efectos informáticos, debe contemplar la
elección del hardware y la configuración más adecuada de software de base, y por
supuesto, la consecución de las aplicaciones software que permitan cubrir las
necesidades de información que marca la estructura del SI. La obtención del
software adecuado constituye una gran parte del esfuerzo de automatización del
sistema, ya que, aunque cada vez existe una mayor cantidad de paquetes software
eficaces que se pueden comprar listos para instalar, la mayoría de las empresas
requieren la construcción de software a medida o, al menos, la adaptación de
aplicaciones existentes. Hablamos entonces de desarrollo de software para el SI.
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 1 - lrl(oducc|ór a |os 3|sleras de lrlo(rac|ór v a |as 8ases de 0alos Pád|ra 11 de 20ê
DE LO$ $I$IEMA$ IkADICIONALE$ DE FICHEkO$ A LA$ 8A$E$ DE
DAIO$
Si analizamos la situación pasada de algunos SI nos encontramos con
sistemas en los que existe una proliferación de ficheros, específicos cada uno de
ellos de una determinada aplicación. Los datos se recogen varias veces y se
encuentran repetidos en los distintos archivos. Esta redundancia, además de
malgastar recursos, origina a menudo divergencias en los resultados. Las
aplicaciones se analizan e implantan con independencia unas de otras, y los datos
no se suelen transferir entre ellas, sino que se duplican siempre que los
correspondientes trabajos los necesitan.
Este planteamiento produce, además de una ocupación inútil de memoria
secundaria, un aumento de los tiempos de proceso, al repetirse los mismos
controles y operaciones en los distintos ficheros. Pero más graves todavía son las
inconsistencias que a menudo se presentan en estos sistemas, debido a que la
actualización de los mismos datos, cuando se encuentran en más de un fichero, no
se suele realizar de forma simultánea en todos ellos.
Por otra parte, la dependencia de los datos respecto al soporte físico y a los
programas da lugar a una falta de flexibilidad y de adaptabilidad frente a los
cambios que repercute muy negativamente en el rendimiento de conjunto del
sistema informático.
Se deduce claramente la necesidad de una gestión más racional del conjunto
de datos, surgiendo así un nuevo enfoque que se apoya sobre una base de datos,
en la cual los datos son recogidos y almacenados una sola vez, con independencia
de los tratamientos. Por tanto, la solución de los problemas asociados al
tratamiento de los datos en los sistemas tradicionales lleva a un cambio radical en
el enfoque del SI, en el cual los datos se organizan y se mantienen en un conjunto
estructurado que no está diseñado para una aplicación concreta, sino que, por el
contrario, tiende a satisfacer las necesidades de información de toda la
organización; necesidades cuya diversidad se ve acentuada en el transcurso del
tiempo.
INIkODbCCIÓN A LA$ 8A$E$ DE DAIO$
A principio de los años sesenta, en los primitivos SI, la información estaba
representada por un conjunto de ficheros. Estos ficheros no estaban relacionados
entre sí, y los datos almacenados representaban las relaciones existentes en la
información mediante referencias simbólicas y/o físicas. Aunque a este primitivo
sistema se le denominó Base de Datos, aunque carecían de una serie de
características inherentes al término empleado.
Para que una Base de Datos pueda denominarse como tal, tiene que
acreditar una serie de propiedades, las cuales fueron incorporándose a estos
sistemas a medida que el software de administración de la información que se
desarrolló fue haciéndose más eficaz. No todas las bases de datos de hoy en día
cumplen estos requisitos ideales.
A medida que la tecnología avanzaba, los procedimientos y estructuras para
almacenar y mantener la información de un determinado dominio de un problema
han evolucionado. Inicialmente los dispositivos de almacenamiento sólo permitían
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 1 - lrl(oducc|ór a |os 3|sleras de lrlo(rac|ór v a |as 8ases de 0alos Pád|ra 12 de 20ê
un acceso serie a la información, por lo que las estructuras de datos debían ser
muy simples y los procedimientos de acceso a la información empleaban mucho
tiempo, además de una gran dependencia del hardware.
Al aparecer los dispositivos de almacenamiento que permitían un acceso
directo (aleatorio) las estructuras de datos se fueron haciendo más complejas. El
almacenamiento de la información, por esta época, era independiente del
hardware, pero la estructura de la información no era independiente de los
procedimientos de acceso a la información.
Con el tiempo se vio la necesidad de independizar la estructura de la
información de los procedimientos encargados de su tratamiento. Aquí surge el
concepto de Base de Datos. Si se desea que cualquier modificación en la cantidad,
contenido o estructura de la información no afecte a los procedimientos
desarrollados previamente para el mantenimiento de la misma, es necesario tener
en cuenta que existe una independencia de los datos respecto a los procedimientos.
Esta independencia tiene dos sentidos:
Independencia lógica de los datos, por la que al cambiar la
representación lógica del problema no afecta a los programas de aplicación
que los manipulan, siempre que esta modificación no elimine ningún ítem
de datos que estos programas requieran.
Independencia física de los datos, por la que la distribución en las
unidades de almacenamiento y la estructura física de la información
almacenada es independiente de los cambios en la estructura lógica
general, y por tanto, de los procedimientos que manejan las mismas.
VENIAJA$ E INCONVENIENIE$ DE LA$ 8A$E$ DE DAIO$ FkEIE A LO$
FICHEkO$ CLÁ$ICO$
Las bases de datos, surgidas como respuesta al nuevo planteamiento de los
sistemas orientados hacia los datos para mejorar la calidad de las prestaciones de
los sistemas informáticos y aumentar su rendimiento, presentan una multitud de
ventajas frente a los sistemas clásicos de ficheros, que son:
Independencia de los datos respecto a los tratamientos y
viceversa.- Un cambio en el tratamiento de los datos no imponen
rediseñar la base de datos. Por otra parte al cambiar en la Base de Datos la
estructura física, caminos de acceso, etc. no obliga a alterar los programas.
La independencia en la práctica nunca es absoluta, pero permite adaptar el
SI a la evolución de las organizaciones sin excesivas dificultades ni costes.
Coherencia de los resultados.- Como la información sólo se recoge y
almacena una vez, en los tratamientos se utilizan siempre los mismos
datos, por lo que los resultados son coherentes. Al desaparecer la
redundancia de los datos, desaparece el problema de las actualizaciones
redundantes.
Mejor disponibilidad de los datos para el conjunto de los usuarios.-
Cada usuario ya no es propietario de los datos, puesto que están
compartidos por el conjunto de aplicaciones.
Mayor valor informativo.- Además de representar los datos, en una base
de datos también se representan las relaciones entre los datos, con lo que
el conjunto de información es superior a la suma de los elementos
individuales que lo forman.
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 1 - lrl(oducc|ór a |os 3|sleras de lrlo(rac|ór v a |as 8ases de 0alos Pád|ra 13 de 20ê
Mejor documentación de la información.- En los ficheros clásicos los
datos están almacenados, pero su descripción se hacen en los programas.
Este problema se atenúa en las bases de datos ya que los datos y su
semántica están almacenados en la misma.
Mayor eficiencia en la recogida, validación e introducción de los
datos en el sistema.- Los datos sólo se recogen y validan una vez,
aumentando el rendimiento de todo el proceso previo al almacenamiento.
Reducción del espacio de almacenamiento.-Al desaparecer la
redundancia de los datos, se reduce la ocupación de almacenamiento
secundario, aunque la información referente a la estructura de los datos y
su semántica ocupan bastante espacio.
Entre los inconvenientes que presentan las bases de datos:
Instalación costosa.- La implantación de un sistema de bases de datos
lleva consigo un coste elevado, tanto en equipo físico, como en el software,
además del coste de adquisición y mantenimiento del SGBD.
Personal especializado.- Debido a que los conocimientos para una
correcta utilización y administración de la base de datos solo lo tienen el
personal especializado.
Implantación larga y difícil.- Debido a las causas anteriores, la
implantación de una base de datos es una tarea larga y laboriosa.
Falta de rentabilidad a corto plazo.- Debido al coste en personal y
equipos y al tiempo que tarda en estar operativa.
Escasa estandarización.- Un problema importante que se pone de
manifiesto en el momento de la creación de una base de datos es la falta
de estandarización que facilite a los usuarios el manejo de los sistemas de
bases de datos, aunque últimamente este problema se está resolviendo.
Desfase entre la teoría y la práctica.- En muchas ocasiones, los
usuarios, especialmente los directivos, se engañan respecto a las
prestaciones reales que pueden proporcionarles los SGBD actuales.
CAkACIEkÍ$IICA$ DE LA$ 8A$E$ DE DAIO$
Para que una Base de Datos se considere como tal, tiene que cumplir una
serie de características:
Versatilidad para la representación de la información.- La
organización de la información en la base de datos debe permitir que
diferentes procedimientos puedan construir diferentes registros a partir de
la información existente en la base de datos. Estos registros lógicos están
formados por ítems de datos derivados del conjunto de los ítems de datos
existentes en los registros físicos.
Desempeño.- Hay que asegurar un tiempo de respuesta adecuado,
permitiendo el acceso simultáneo al mismo o distinto conjunto de ítems de
datos por el mismo o distinto procedimiento.
Mínima redundancia.- La tecnología de Base de Datos surgió por
diversas razones, pero una de las principales fue evitar la redundancia de
información presente en sistemas de procesamiento que usaban archivos
planos. Las Bases de Datos no evitan totalmente la redundancia ya que es
necesario representar relaciones que existen entre las entidades que
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 1 - lrl(oducc|ór a |os 3|sleras de lrlo(rac|ór v a |as 8ases de 0alos Pád|ra 11 de 20ê
forman parte del dominio del problema. La existencia de redundancia
provoca problemas de inconsistencia de la información, necesidades de
almacenamiento mayores.
Capacidad de acceso.- Una base de datos debe ser capaz de responder,
en un tiempo aceptable, a cualquier consulta sobre la información que
mantiene, sin restricciones graves en cuanto a los ítems, relaciones,
formato, etc., solicitados en la misma, y respondiendo al usuario
rápidamente.
Simplicidad.- La base de datos representa el dominio de un problema que
se necesita tratar computacionalmente. La naturaleza del problema puede
ser variada y su complejidad de partida también. Las bases de datos deben
estar basadas en representaciones lógicas simples que permitan la
verificación en la representación del problema que representan, y la
modificación de los requerimientos no ocasione una complejidad excesiva.
Integridad.- Veracidad de los datos almacenados respecto a la
información existente en el dominio del problema que trata la base de
datos. Muchos usuarios manejan los datos haciendo uso de muchos
procedimientos que tratan los mismos datos de muchas formas, siendo
necesario garantizar que estos datos no sean modificados ni destruidos de
forma anómala.
Durante el procesamiento pueden producirse fallos de muy diversa
naturaleza: errores del sistema general, del hardware, software, etc. Así, los
procedimientos que manejan la información (inserción y actualización) deben
asegurar que el sistema pueda garantizar la integridad de la información a
pesar de los errores que se puedan producir, temporalmente, a causa de los
fallos con independencia de su naturaleza.
Pero además, la integridad debe garantizarse con respecto a la
veracidad de los ítems de datos y sus relaciones. En una base de datos deben
establecerse procedimientos que verifiquen que los valores de los datos se
ajustan a los requerimientos y restricciones extraídos del análisis del
problema.
Seguridad y Privacidad.- La seguridad consiste en la capacidad de una
base de datos para proteger los datos contra su pérdida total o parcial por
fallos del sistema o por accesos accidentales o intencionados a los mismos.
La privacidad de una base de datos hace referencia a la reserva de la
información a personas no autorizadas.
La información de una empresa es un bien muy valioso que hay
proteger por lo que una base de datos deberá satisfacer los siguientes
requisitos:
o Seguridad contra la destrucción de los datos causada por el entorno:
fuego, robo, inundaciones, etc.
o Seguridad contra la destrucción de los datos causada por fallos del
sistema (hardware o software) de forma que los datos puedan
reconstruirse.
o Seguridad contra accesos no autorizados a la base de datos.
o Seguridad contra accesos indebidos a los datos.
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 1 - lrl(oducc|ór a |os 3|sleras de lrlo(rac|ór v a |as 8ases de 0alos Pád|ra 15 de 20ê
En una base de datos existirán procedimientos de recuperación de la
información perdida total o parcialmente, por cualquier causa, como
procedimientos que supervisen el acceso a los datos por los usuarios de la
base de datos.
Afinación.- Flexibilidad para modificar la organización física de los datos
para asegurar un buen desempeño conforme el volumen de información
aumente y sin que por ello se vean afectados los procedimientos u otras
representaciones de datos.
Interfaz con el pasado y el futuro.- Una base de datos debe estar
abierta a reconocer información organizada físicamente por otro software
(base de datos o no) de distinta forma a la que utiliza en la base de datos.
Información existente antes de la implantación, por la empresa, de la base
de datos actual y que es valiosa para la organización. Además, el avance
tecnológico hará que la base de datos actual pueda ser cambiada con el
tiempo.
VI$IONE$ DE LO$ DAIO$ EN LA$ 8A$E$ DE DAIO$
El usuario no tiene que conocer cómo se organizan los datos físicamente en
la base de datos, sólo conoce las características del problema que representa la
base de datos. El usuario conoce la organización, la información que maneja, las
relaciones existentes entre esta información, cómo debe ser trata esta información
y en que momento.
Dependiendo de quien acceda o use la base de datos, ésta debe presentarle
una visión de los datos que sea capaz de reconocer, interpretar y manejar.
Existen, pues tres visiones de los datos en una base de datos:
Visión externa.- Es la visión de los datos que tienen los usuarios finales
de una base de datos. Un usuario trata sólo una visión parcial de la
información, sólo aquella que interviene en el dominio de su actividad. Este
usuario verá la información como un registro, con independencia de a qué
entidad pertenecen los ítems de datos, correspondientes a ese registro.
Otro usuario (del mismo o cualquier otro subsistema) verá también su
registro particular de información cuyos ítems de datos podrán ser comunes o
no al de otros registros particulares de otros usuarios.
Estas visiones particulares de los usuarios son proporcionadas por los
procedimientos o programas de aplicación que sólo manejan parte de la
información de la base de datos.
Visión conceptual.- Representación del problema tal y como se presenta
en el mundo real. Una base de datos representa la información de un
problema del mundo real. Se determinan los objetos y relaciones que
intervienen en el mismo, las propiedades o características de estas
entidades y las relaciones o dependencias que existen entre ellos.
La visión conceptual de una base de datos es una representación
abstracta del problema e independiente de cómo va a ser tratada esta
información, de qué visiones externas pueda tener y de cómo está
información pueda ser almacenada físicamente. Esta visión conceptual no
cambia a no ser que cambie la naturaleza del problema.
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 1 - lrl(oducc|ór a |os 3|sleras de lrlo(rac|ór v a |as 8ases de 0alos Pád|ra 1ê de 20ê
Visión física.- Representación de cómo la información es almacenada en
los dispositivos de almacenamiento. Esta visión describe las estructuras u
organizaciones físicas, dispositivos, ficheros, tipos de datos, etc.,
estructuras que representan el dominio del problema entendible para el
sistema informático.
Estas tres visiones, en realidad suponen tres representaciones del mismo
dominio del problema a diferentes niveles de abstracción. En cada nivel se
describen aquellos objetos que pueden ser entendidos por los usuarios de ese nivel
de la base de datos. El usuario final sólo entiende de registros o formas de
comunicación similares a los documentos externos que maneja la organización
(visión externa). El diseñador o analista de sistemas sólo entiende de tipos de
entidades o clases de objetos que intervienen en el dominio del problema que la
organización desea, de sus relaciones y los procedimientos que lleva a cabo la
organización para solucionar el problema (visión conceptual). El administrador de la
base de datos es el encargado de describir el nivel físico para determinar aquella
organización física que pueda garantizar el desempeño óptimo del sistema (visión
física).
Esta descripción de los datos a diferentes niveles de abstracción garantiza,
en principio, la independencia de los datos:
Que pueda ser modificada la organización física sin que haya cambiado la
descripción conceptual y sin que haya que modificar los programas de
aplicación que manipula esa información.
Que pueda ser modificada la representación conceptual del problema sin
que por ello tenga que ser modificada la estructura física de la información,
ni los programas de aplicación, siempre y cuando no se eliminen de la
representación conceptual objetos necesarios o requeridos en estos otros
niveles.
Que las visiones externas puedan cambiar conforme a nuevos
requerimientos funcionales sin que por ello se tenga que modificar ninguna
descripción de datos a ningún nivel de abstracción.
Estos tres niveles deben ser independientes, pero en la mayoría de las bases
de datos no es del todo cierto. Sin embargo, puede conseguirse una buena
independencia de los datos si:
Una misma representación conceptual de los datos puede representarse de
varias formas físicamente. La representación física de los datos vendrá
determinada por requerimientos funcionales o de desempeño.
El número de ítems y disposición de los mismos en una representación
externa debe ser independiente de cómo estos ítems han sido
representados en el nivel conceptual y de las relaciones que mantienen en
el mismo.
El nivel más importante es el nivel conceptual, ya que los otros dos niveles
se apoyan en este y en base a su calidad, se garantiza que la base de datos
solucione el problema de la organización.
Una descripción conceptual de la organización incluirá todas las entidades
que intervienen en el problema, sus atributos y propiedades, así como las
relaciones existentes entre ellas. Se describen los ítems de datos que intervienen
en el comportamiento del sistema y cuya información es necesario considerar.
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 1 - lrl(oducc|ór a |os 3|sleras de lrlo(rac|ór v a |as 8ases de 0alos Pád|ra 1Z de 20ê
Sin embargo, hay muchas formas, y con diversas técnicas, de representar
un sistema conceptualmente. Debido a esto se puede hablar de un cuarto nivel de
abstracción en la representación de la información en una base de datos, el nivel
lógico. Mientras que la descripción conceptual del problema es independiente de
las descripciones externa y física, la descripción lógica si lo es. La descripción lógica
deriva de la descripción conceptual en base a la aplicación de una serie de reglas y
restricciones que tienen en cuenta cómo la información representada puede ser
tratada por los procedimientos que van a manejar y definir la información en base a
las otras representaciones.
La inclusión de este nuevo nivel de representación del dominio del problema,
un nivel dependiente del software encargado de manipular la información, va a
garantizar la independencia de la información en una base de datos.
8A$E$ DE DAIO$ Y $I$IEMA$ DE GE$IIÓN DE 8A$E$ DE DAIO$
Una definición formal de Base de Datos sería:
Una Base de datos es una colección de archivos relacionados que
almacenan tanto una representación abstracta del dominio de un
problema del mundo real cuyo manejo resulta de interés para
una organización, como los datos correspondientes a la
información acerca del mismo. Tanto la representación como los
datos están sujetos a una serie de restricciones, las cuales
forman parte del dominio del problema y cuya descripción está
también almacenada en esos ficheros.
Es importante conocer la diferencia entre lo que es una base de datos y lo
que es un Sistema de Gestión de Base de Datos, términos que se confunden muy a
menudo cuando se está trabajando con la información haciendo uso de esta
tecnología. Cuando se habla de base de datos se habla de información almacenada
cumpliendo una serie de características y restricciones, pero para que la
información pueda ser almacenada y el acceso a la misma satisfaga las
características exigidas a una base de datos, es necesario que exista una serie de
procedimientos, un sistema software, que sea capaz de llevar a cabo tal labor. A
este sistema software es a lo que se le denomina Sistema de Gestión de Bases de
Datos (SGBD).
Un SGBD es una colección de programas de aplicación que proporcionan al
usuario de la base de datos los medios necesarios para realizar las siguientes
tareas:
Definición de los datos a los distintos niveles de abstracción (físico, lógico y
externo)
Manipulación de los datos en la base de datos. Es decir, la inserción,
modificación, borrado y acceso o consulta a los mismos.
Mantenimiento de la integridad de la base de datos. Integridad en cuanto a
los datos en sí, sus valores y las relaciones entre ellos.
Control de la privacidad y seguridad de los datos en la base de datos.
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 1 - lrl(oducc|ór a |os 3|sleras de lrlo(rac|ór v a |as 8ases de 0alos Pád|ra 18 de 20ê
FkINCIFALE$ FbNCIONE$ DE bN $G8D
Las funciones esenciales de un SGBD so las de descripción, manipulación y
control.
Función de definición o descripción
Debe permitir al diseñador de la base de datos especificar los elementos de
datos que la integran, su estructura y relaciones que existen entre ellos, las reglas
de integridad semántica, etc. así como las características de tipo físico y las vistas
lógicas de los usuarios.
Esta función la realiza el lenguaje de definición de datos (DDL) propio de
cada SGBD, debe de suministrar los medios para definir las tres estructuras de
datos (externa, lógica e interna), especificando las características de los datos a
cada uno de estos niveles.
Función de manipulación
Una vez se ha descrito los datos, es preciso cargar los datos en las
estructuras previamente creadas, con lo que la base de datos estará ya dispuesta
para su utilización. Los usuarios tendrán necesidad de recuperar la información o de
actualizarla. La consulta a la base de datos podrá ser de dos tipos:
Sobre la totalidad de los datos en la que se recuperan todos los datos de la
BD o todos los de un determinado tipo
Consulta selectiva, en la que se tendrán que localizar los registros que
cumplen una determinada condición (criterio de selección).
La actualización o puesta al día de una base de datos supondrá tres tipos de
operaciones distintas:
Inserción de nuevos elementos.
Borrado o eliminación de elementos.
Modificación de los datos de aquellos registros en los cuales se hayan
producido cambios.
La función de manipulación la realiza el lenguaje de manipulación de datos
(DML) que facilita los instrumentos para realizar estas tareas.
Función de Control
Debe integrar una serie de instrumentos para facilitar la tarea del
administrador. En la mayoría de los SGBD existen funciones de servicio, como
cambiar la capacidad de los ficheros, obtener estadísticas de utilización, etc. y
principalmente las relacionadas con la seguridad (copias de seguridad, rearranque
en caso de caída del sistema, etc.) y de protección frente a accesos no autorizados.
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 1 - lrl(oducc|ór a |os 3|sleras de lrlo(rac|ór v a |as 8ases de 0alos Pád|ra 19 de 20ê
COMFONENIE$ DE bN $G8D
Para realizar las funciones anteriores y algunas más es necesario que el
SGBD cuente con una serie de componentes cuya función es el desarrollo de las
mismas y satisfaga los requerimientos impuestos para estos sistemas.
El lenguaje de definición de datos (DDL).- Permite definir la
representación lógica de los datos
El lenguaje de definición de almacenamiento de los datos (DSDL).-
En la mayoría de los SGBD el mismo lenguaje DDL permite la definición de
los datos en el nivel de representación físico, si bien en otros es un
subcomponente de éste denominado lenguaje de definición del
almacenamiento de los datos. En cualquier caso se definen los datos
correspondientes al dominio de un problema a los dos niveles de
abstracción, denominada Esquema de la Base de Datos. En el esquema
estarán definidas:
o Las características del problema a nivel lógico: clases de objetos con sus
propiedades, relaciones entre objetos y sus propiedades, restricciones
tanto de las clases de objetos como de las relaciones.
o Las características del problema a nivel físico: unidades físicas en las
cuales los datos se almacenarán, volúmenes y archivos utilizados,
características físicas y lógicas de los medios de almacenamiento y
métodos de acceso a la información.
Además del DSDL, el DDL cuenta con un sublenguaje encargado
del control y seguridad de los datos. Este sublenguaje se denomina
lenguaje de control de datos (DCL) y permite el control de acceso a la
información almacenada en el diccionario de datos.
El lenguaje de manipulación de datos (DML).- Mediante este lenguaje
se realizan dos funciones en la gestión de los datos:
o La definición del nivel externo o de usuario de los datos.
o La manipulación de los datos; es decir, la inserción, borrado,
modificación y recuperación de los datos almacenados en la base de
datos.
Dependiendo del SGBD y del modelo de datos empleado hay dos
tipos de DML:
o Procedimentales.- Las sentencias requieren que en las sentencias del
lenguaje se especifique qué datos se van a manipular y qué operaciones
deben realizarse para ello.
o No procedimentales.- Solo requieren que en las sentencias se
especifique qué datos se van a manipular, siendo el propio DML el
encargado de determinar los procedimientos más efectivos para ello.
Estos últimos son los más fáciles para el usuario no experto, pero
puede requerir modificar el código que generan estos lenguajes para
asegurar un buen desempeño.
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 1 - lrl(oducc|ór a |os 3|sleras de lrlo(rac|ór v a |as 8ases de 0alos Pád|ra 20 de 20ê
También, el DML tiene la función de describir la visión externa de
los datos, mediante las vistas o visiones parciales que los usuarios
tienen del esquema de la base de datos definido mediante el DDL. Estas
vistas, también denominadas subesquemas pueden realizarse de dos
formas:
o Haciendo uso solamente del DML
o Haciendo uso de un lenguaje huésped como C, COBOL, etc. Mediante el
cual se realizan los programas de aplicación que permiten al usuario
manipular los datos de la base de datos. En el código fuente de estos
programas están presentes sentencias del DML.
El diccionario de datos.- Conjunto de archivos que contienen información
acerca de los datos que pueden ser almacenados en la base de datos. Se
almacenan todas las definiciones realizadas por el DDL sobre el problema y
algunas de las realizadas por el DML: el esquema lógico, físico y
subesquemas de la base de datos. Además, el diccionario de datos también
almacena:
o Restricciones de privacidad y acceso a los datos almacenados en la base
de datos.
o Reglas, normas o restricciones referentes a la seguridad de los datos.
o Información para garantizar la integridad de los datos almacenados en
la base de datos.
El gestor de la base de datos.- Es un componente software encargado
de garantizar el correcto, seguro, íntegro y eficiente acceso y
almacenamiento de los datos. Proporciona una interfaz entre los datos
almacenados y los programas de aplicación. Todas las operaciones
realizadas en la base de datos deben contar con su aprobación. El gestor
las interpreta y valida, devolviendo el resultado al usuario o programa de
aplicación que la solicitó, o bien la rechaza. Es el responsable de:
o Garantizar la privacidad de los datos, permitiendo sólo acceso a los
usuarios autorizados.
o Garantizar la seguridad de los datos, realizando procedimientos que
puedan recuperar datos después de un fallo que ocasione pérdida o
deterioro temporal de los mismos.
o Garantizar la integridad de los datos, gestionando que los datos que se
almacenan en la base de datos satisfacen las restricciones definidas en
el esquema de la misma.
o Garantizar el acceso concurrente a la base de datos de forma que varios
usuarios puedan acceder al mismo o distinto dato sin que se provoque
una pérdida de la integridad de los datos.
o Interaccionar con el sistema operativo, especialmente con el gestor de
archivos, para que los procedimientos DML puedan ser entendidos por el
sistema operativo para el correcto almacenamiento y recuperación de la
información. Para ello el gestor dispone del procesador de consultas.
El administrador de la base de datos (DBA).- Es un componente
humano con una serie de responsabilidades en cuanto a la definición,
administración, seguridad, privacidad e integridad de la información, así
como el desempeño del SGBD en el procesamiento de la misma. Entre sus
tareas está:
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 1 - lrl(oducc|ór a |os 3|sleras de lrlo(rac|ór v a |as 8ases de 0alos Pád|ra 21 de 20ê
o Definición del esquema lógico de la base de datos, mediante sentencias
DDL.
o Definición del esquema físico de la base de datos, especificando las
estructuras de almacenamiento y métodos de acceso a la información
almacenada en los dispositivos físicos.
o Definición de subesquemas o visiones externas del usuario.
o Control de la privacidad de los datos, mediante concesión de privilegios
a usuarios o grupos de éstos para el acceso a la información almacenada
en la base de datos.
o Mantenimiento de los esquemas, introduciendo modificaciones en el
esquema lógico, en la representación física de los datos o en los
subesquemas de los usuarios.
o Especificación de los procedimientos para mantenimiento de la
seguridad de los datos. Cuando y de que forma se realizan y definen los
procesos que garantizan que los datos puedan ser recuperados después
de una pérdida temporal de los mismos.
Los usuarios de la base de datos.- Los usuarios que interactúan con la
base de datos:
o Usuarios terminales.- Los que interaccionan con la base de datos a
través de programas de aplicación.
o Usuarios técnicos.- Aquellos que desarrollan programas de aplicación
que van a ser utilizados por usuarios terminales.
o Usuarios especializados.- Aquellos que utilizan el SGBD como una
herramienta para el desarrollo de otros sistemas más complejos.
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 2 - Rep(eserlac|ór de |os P(oo|eras de| Vurdo Rea|. Los Vode|os de 0alos Pád|ra 22 de 20ê
2
Representac|ón de prob|emas de|
mundo rea|. Los Hode|os de 0atos
Para describir un fenómeno, el ser humano utiliza la abstracción, capacidad
por la cual se simplifica el proceso de interpretación, simplificando o reduciendo el
número de parámetros y relaciones existentes en el fenómeno natural que se desea
interpretar. El proceso de interpretar un fenómeno consiste en caracterizarlo, es
decir, proponer las propiedades que lo caracterizan y estableciendo un modelo
inicial que intenta representarlo. En este modelo, se establece para cada propiedad
la forma en que se medirá, es decir el dominio en las que se definen estas
propiedades y por último las relaciones existentes entre todas las propiedades que
definen al fenómeno en cuestión.
Al conjunto de propiedades que caracterizan al fenómeno se le denomina
datos y al conjunto de valores que estas propiedades pueden representar para un
determinado fenómeno, junto con el conjunto de relaciones se le denomina
información. El contenido de la información es el conocimiento que aporta la
información que se tiene del fenómeno a través de los datos obtenidos del mismo.
Un modelo es una representación abstracta de un determinado fenómeno
natural. Esta representación informa qué sucesos deben ser medidos y de qué
forma para interpretarlo y obtener conocimiento acerca del mismo.
La medición de los valores correspondientes a los datos se hace usando el
principio de abstracción. Para ello se definen unos tipos o clases abstractas de
datos básicos (entero, real, booleano, etc.) los cuales toman un conjunto de valores
predefinido. Cualquier dato necesario para describir el fenómeno, natural o de
cualquier otro tipo, será definido en alguno de estos tipos básicos.
Si un fenómeno puede ser descrito por un conjunto de datos o propiedades,
estos datos toman un determinado valor en un instante dado del fenómeno y por
tanto, cuando se almacenan estos datos, se está almacenando ese instante.
Un Modelo de Datos (MD) es un conjunto de reglas de acuerdo a las cuales
puede describirse un fenómeno real o abstracto. Mediante el uso de un modelo de
datos se describen las propiedades que caracterizan el fenómeno, las relaciones
entre estas propiedades, y cómo las propiedades y las relaciones pueden
evolucionar con el tiempo.
LO$ FkO8LEMA$ DEL MbNDO kEAL
Mediante un MD se puede representar cualquier fenómeno real o abstracto,
es decir, cualquier problema sobre el que se desea obtener información para su
conocimiento y/o solución. En el mundo real se presentan multitud de diferentes
problemas a solucionar: crecimiento de las plantas, contabilidad de una empresa,
proceso de comunicación, etc.
El primer paso para representar un problema del mundo real es la
caracterización del mismo, es decir, determinar los límites del problema. En esta
fase se determinan que datos intervienen en el problema y cómo pueden ser
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 2 - Rep(eserlac|ór de |os P(oo|eras de| Vurdo Rea|. Los Vode|os de 0alos Pád|ra 23 de 20ê
medidos. De esta forma se establece la frontera del problema con respecto al resto
de los problemas existentes. En el problema intervienen una serie de propiedades
que pueden representar a uno o una colección de datos que deben ser medidos en
un determinado tipo de datos básico. Cada propiedad puede mantener un número
de interdependencias con el resto de las propiedades que forman parte del sistema
de trabajo. El término sistema es muy utilizado para identificar un conjunto de
elementos cuyas propiedades e interdependencias dan lugar al comportamiento de
ese conjunto. Para el estudio de un sistema es necesario simplificar el problema
que representa el mismo. Esta simplificación comienza delimitando el límite del
sistema. En este proceso se determinan las propiedades de interés, dejando otras
que pueden afectar o verse afectadas por el sistema como pertenecientes a otros
sistemas. Este proceso de simplificación está basado en la capacidad de
abstracción.
La abstracción
La abstracción es la capacidad mediante la cual una serie de objetos se
categorizar en un nuevo objeto mediante una función de pertenencia. Al nuevo
objeto se le denomina clase o tipo de objeto, y todos los elementos categorizados
en esta clase tienen propiedades comunes, las cuales caracterizan la clase. La
abstracción permite ocultar los detalles, simplificando la descripción de un problema
mediante la agrupación de elementos con propiedades comunes que intervienen en
el mismo. En la definición de los datos, la abstracción es utilizada de dos formas:
Generalización.- Es la abstracción por la cual un conjunto de clases de
objetos puede ser visto como una nueva clase de objetos más general.
Cada uno de las clases objetos generalizadas puede, a su vez, ser
generalizaciones de otras clases de objetos. Por último, las clases son a su
vez agrupaciones (generalizaciones) de objetos simples. La generalización
de objetos simples en una clase es denominada clasificación. Se
denomina especialización e instanciación a los procesos inversos a la
generalización y clasificación.
Agregación.- Es la capacidad de considerar un objeto en base a los
elementos que lo constituyen. Un objeto (o clase de objetos en la que se
generaliza) como la agregación de un conjunto de propiedades que lo
caracterizan. El proceso inverso a la agregación es el refinamiento
mediante el cual se puede representar a aquellos objetos simples o
propiedades que caracterizan a una clase de objetos.
La generalización puede asociarse al concepto ES_UN, ya que mediante esta
abstracción es posible representar a aquellos objetos o clases de objetos que
pertenecen o pueden ser considerados como de un tipo o clase de objetos más
general. La agregación puede asociarse con el concepto PARTE_DE., puesto que
mediante esta abstracción puede representarse que un objeto o clase de objetos
está formado por una serie de objetos o clases constituyentes que lo caracterizan
como objeto o clase.
Representación de los problemas del mundo real
La abstracción es una herramienta muy potente mediante la cual pueden ser
estudiados los problemas del mundo real gracias a la simplificación que permite
introducir en el proceso de representación de los mismos. La representación de un
problema puede hacerse usando la abstracción de forma ascendente o
descendente.
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 2 - Rep(eserlac|ór de |os P(oo|eras de| Vurdo Rea|. Los Vode|os de 0alos Pád|ra 21 de 20ê
En sentido ascendente, se determinan inicialmente aquellos objetos simples,
aquellos datos o propiedades simples que intervienen en el problema o sistema en
estudio, y para cada uno de estos datos se determina el tipo de datos básico
mediante el cual puede ser medido. A continuación, estos datos son agregados en
clases de objetos del sistema. Las clases de objetos estarán formadas por la
agregación de un conjunto de propiedades del sistema, cada una de ellas medible
en un tipo de dato básico y para los cuales se determinan los límites en el conjunto
de valores que pueden tomar para la clase de objeto de la que forman parte.
Una vez definidas las clases de objetos que intervienen en el problema y
haciendo uso de la abstracción, estas clases pueden ser generalizadas en clases de
objetos de mayor categoría y que agrupan a varias clases más simples. Este
proceso ascendente se repite hasta que la generalización es completa.
En sentido descendente, inicialmente se identifican las clases de objetos más
generales y se procede a un proceso de especificación e instanciación de las
mismas hasta alcanzar las propiedades o datos que intervienen en el problema.
Ambas técnicas es necesario utilizarlas en la representación de un problema.
Partiendo de un proceso ascendente o descendente se va saltando de uno a otro
conforme se va alcanzando más conocimiento respecto del problema a representar,
refinándose en cada paso la representación del mismo hasta alcanzar una
representación correcta y simplificada del sistema.
Además de las relaciones ES_UN y PARTE_DE consideradas entre las clases
de objetos que intervienen en un problema, en la mayor parte de los problemas
existen otro tipo de relaciones o dependencias entre los elementos del mismo. En la
descripción de un problema es necesario también representar interdependencias
entre los elementos del mismo. Esta representación debe consistir en la información
correspondiente al significado de la dependencia y la información correspondiente al
número de objetos de cada una de las clases que se ven implicados, así como la
forma, debido a esta dependencia.
Análisis de los problemas
La representación de problemas es un proceso complejo que requiere una
gran experiencia, capacidad y método por parte de la persona encargada de esta
labor. La representación de un sistema es la conclusión de un arduo y complejo
proceso de observación del mismo. Un proceso en el cual se determinan las
entidades del sistema, sus dependencias y, por tanto el comportamiento del
mismo.
A este proceso se le conoce como Análisis del Sistema, e
independientemente del problema a representar está basado en la Teoría General
de Sistemas, la cual se basa en la consideración de todas las partes del sistema
para el estudio de un problema.
De forma general, la representación de un problema requiere el seguimiento
de los siguientes pasos:
1. La definición del problema, mediante una descripción simple y concreta
del problema que se desea estudiar y de cuál es la función u objetivo que
el sistema intenta alcanzar. Si se trata de un sistema que puede ser
observado, esta definición estará basada en la observación del
comportamiento del mismo utilizando para ello un nivel de abstracción
elevado. En esta fase interesa describir cómo el sistema se comporta a
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 2 - Rep(eserlac|ór de |os P(oo|eras de| Vurdo Rea|. Los Vode|os de 0alos Pád|ra 25 de 20ê
grandes rasgos; es decir, cómo el sistema es observado desde los límites
del mismo. No interesa describir el comportamiento interno del sistema,
sino el comportamiento externo.
2. La definición de la arquitectura del problema, mediante una
descripción de las partes importantes del sistema. Basándonos en la
abstracción, un sistema puede ser visto como un conjunto de otros
sistemas o problemas de menor entidad que se interrelacionan entre sí. En
este paso se describirán estos subsistemas en el mismo nivel de
abstracción que en el paso anterior, prestando atención a cómo afecta cada
uno de los subsistemas o se ve afectado por los otros.
Se puede observar que en los dos primeros pasos se está definiendo
los límites del sistema y de cada uno de los subsistemas que lo componen
y, por tanto, se está diferenciando el problema, y sus correspondientes
subproblemas, de cualquier otro conjunto de problemas que se puedan
estudiar.
3. La definición de la estructura del problema, mediante la descripción de
los elementos del sistema. En esta fase se determinan qué objetos,
entidades, datos o variables son las que forman parte del problema en
estudio. Estos objetos pueden formar parte del problema como un todo, o
de alguno o varios de los subproblemas que se han determinado en el paso
anterior. Para cada uno de estos objetos se determina:
a. La definición del objeto, mediante una descripción de la función que
desempeña el objeto dentro del problema en estudio. Esta
descripción aporta una interpretación del objeto en el mundo real,
independientemente de la existencia del sistema.
b. La medida del objeto, mediante una descripción de los valores que
pueden ser medidos o puede tomar el objeto para el problema en
estudio. Para ello, a cada uno de los objetos se le asignará, mediante
una función de pertenencia, un tipo de datos básico en el cual puede
ser medido. Este paso se realiza mediante el uso de la
generalización, de forma que los objetos del problema son
generalizados mediante una relación ES_UN a una clase básica de un
conjunto predefinido de antemano y que es común para todos los
sistemas en estudio.
c. Las relaciones entre objetos, mediante una descripción de las
interdependencias entre los objetos que intervienen en el problema.
En este paso y, de nuevo haciendo uso de la abstracción, se
agregarán objetos particulares en objetos más generales cuyo
comportamiento está definido y limitado por el conjunto de estos
objetos particulares, y se agruparán objetos en otros más generales,
los cuales representan un comportamiento común a un conjunto de
objetos.
También, en este paso, se describirá cualquier otro tipo de
relaciones que están presentes en el problema entre los objetos
constituyentes del mismo. Todas las relaciones serán identificadas en
base a la función u objetivo que tienen las mismas para que el sistema
alcance su objetivo global, y se determinarán como participan los
objetos que intervienen en estas relaciones y en qué número.
d. Se definen las restricciones inherentes a los objetos para el problema
en estudio. Este paso se describe, ya a un nivel muy bajo de
abstracción, qué valores puede ser medidos para cada uno de los
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 2 - Rep(eserlac|ór de |os P(oo|eras de| Vurdo Rea|. Los Vode|os de 0alos Pád|ra 2ê de 20ê
objetos en base a sus propiedades y a las relaciones que mantienen
con el resto de los objetos del sistema.
4. En los pasos anteriores se ha realizado una definición del problema como
una plantilla, como un marco, formado por un conjunto de cuadrículas
(subproblemas), las cuales a su vez pueden estar formadas por otras
cuadrículas más pequeñas, en las cuales están presentes una serie de
zonas, marcas, ranuras o slots en los que aparecen datos que pueden
tomar un conjunto de valores a veces ilimitado. Es decir, se ha definido la
estática del problema, una descripción tal que nos permite representar el
estado del sistema independientemente del instante en que se observe.
El siguiente paso consiste en la definición de la dinámica del
problema; es decir, la descripción de la evolución que el problema va a
tener o tiene con el tiempo. Si se trata de un problema existente, en este
paso se realiza una interpretación de la evolución del mismo y se propone
un modelo mediante el cual pueden preverse futuros estados del sistema.
Si el sistema no existe, en este paso se propone, también mediante un
modelo, qué operaciones o qué acciones pueden realizarse o ser realizadas
sobre cada uno de los objetos del sistema; entendiendo por objetos a
cualquier elemento simple o complejo (un dato, propiedad, objeto simple o
clase de objeto a cualquier nivel de abstracción) que forme parte del
problema.
5. Una vez definidas las características estáticas y dinámicas del sistema, el
siguiente paso consiste en el estudio del comportamiento del modelo
propuesto. Si el sistema existe, se analiza la adecuación del modelo al
comportamiento real del sistema, y si el sistema no existe, se estudiará la
adecuación del modelo a los objetivos deseados por el sistema. Cualquier
desviación entre el comportamiento real y esperado dará lugar a una
revisión en los pasos anteriores y, por tanto, una modificación del modelo.
No existe una única representación de un problema. Distintas personas
pueden ver un mismo problema de distinta forma, y un mismo problema puede, a
su vez, verse desde distintos puntos de vista, dependiendo de los aspectos del
problema que se deseen representar y de la forma en que se representen. Por ello
se pueden presentar diferentes alternativas en la representación de un problema,
que deben ser estudiadas completamente, para al final tomar una en base a un
gran número de factores como: disponibilidad de medios, capacidad para su
representación, coste y esfuerzo necesario, etc.
LO$ MODELO$ DE DAIO$
El análisis de un problema tiene por objetivo proponer un modelo del
comportamiento y características del mismo. Este modelo está basado en una
representación de los elementos del problema, de las relaciones entre los mismos y
del comportamiento de estos elementos y sus relaciones en el tiempo. Los modelos
de datos son abstracciones mediante las cuales puede realizarse una
representación de los problemas en estudio, la estructura de una base de datos, a
la cual se denomina ESQUEMA. Están basados en el uso de la abstracción,
permitiendo una descripción del sistema y sus elementos como un todo sin que sea
necesario describir cada uno de los elementos particulares del sistema ni cada uno
de los estados de los elementos y del sistema a lo largo del tiempo. Un MD es una
abstracción mediante la cual pueden ser descritas las características estáticas y
dinámicas de un sistema.
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 2 - Rep(eserlac|ór de |os P(oo|eras de| Vurdo Rea|. Los Vode|os de 0alos Pád|ra 2Z de 20ê
Ningún MD puede describir al mismo tiempo la naturaleza estática y
dinámica de un sistema. Por ello, está formado por dos submodelos:
1. Un submodelo encargado de definir las propiedades estáticas del sistema,
es decir, aquellas características del sistema que son invariantes con el
tiempo y que identifican al sistema y a cada uno de los objetos
constituyentes.
2. Un submodelo encargado de describir las propiedades dinámicas del
sistema, es decir, qué acciones toma o puede tomar el sistema y cada uno
de los objetos constituyentes, acciones que dan lugar a que el sistema
evolucione y pase de un estado a otro.
De forma general todos los modelos presentan:
Un conjunto de reglas mediante las cuales puede ser representado
gráficamente el problema. Este conjunto de reglas está soportado por un
conjunto de símbolos mediante los cuales pueden ser representados cada
uno de los objetos del sistema a los diferentes niveles de abstracción y
cada una de las relaciones, entre los objetos del sistema, además de las
restricciones existentes en el problema para los objetos y sus relaciones.
Un pseudolenguaje, formado por un conjunto reducido de morfemas y una
sintaxis perfectamente establecida, mediante el cual pueden describirse las
propiedades estáticas y dinámicas del sistema.
Un conjunto de restricciones que limitan el ámbito en el cual el modelo
puede ser utilizado. Este conjunto marcan los límites de los sistemas a
representar y, por tanto, de las características de los sistemas que pueden
ser representados por un modelo.
Según el nivel de abstracción en la que se encuentre la estructura descrita
con un MD, el modelo puede ser:
Externo.- Nos permiten representar los datos que necesita cada usuario
en particular con las estructuras propias del lenguaje de programación que
va a emplear.
Global.- Ayudan a describir los datos desde el punto de vista del conjunto
de usuarios de la empresa.
Interno.- También llamado físico, está orientado a la máquina, siendo sus
elementos de descripción punteros, índices, etc.
De entre los distintos tipos de modelos, es en los globales en los nos vamos
a centrar, ya que los externos suelen utilizar los mismos conceptos que los
correspondientes globales y los internos no están estandarizados ni existen en
realidad como tales modelos. Los modelos globales se clasifican a su vez en:
Modelo conceptual.- También denominado de alto nivel, facilitan la
descripción global del conjunto de información de la empresa con
independencia de la máquina (hardware y SGBD concreto), por lo que sus
conceptos son más cercanos al mundo real (entidades, atributos,
interrelaciones, etc.). Son modelos de análisis, no de implementación.
Modelo Convencional.- Se encuentran soportados por los SGBD y están
orientados a describir los datos a nivel lógico para el SGBD, de ahí que
también reciban el nombre de modelos de bases de datos, por lo que sus
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 2 - Rep(eserlac|ór de |os P(oo|eras de| Vurdo Rea|. Los Vode|os de 0alos Pád|ra 28 de 20ê
conceptos son propios de cada SGBD (tablas o relaciones en el modelo
Relacional, redes en Codasyl, árboles en el Jerárquico, etc.).
Es preciso distinguir entre esquema, como descripción de la estructura de
la base de datos, y ocurrencia del esquema, que son los datos que se encuentran
almacenados en el esquema en un determinado momento. El esquema no varía
mientras no varíe el mundo real que éste describe; en tanto que una ocurrencia del
esquema, es decir, los datos contenidos en él, son distintos en el transcurso del
tiempo.
Submodelos de un MD
Las propiedades de un modelo de datos son de dos tipos:
Estáticas.- Invariantes con el tiempo y que representa la estructura del
sistema a representar. La estática de un MD está compuesta por:
Elementos permitidos: Objetos (entidades), asociaciones entre objetos
(interrelaciones), propiedades o características de los objetos o de las
asociaciones (atributos), dominios, conjuntos de valores sobre los que se
definen las propiedades.
La representación de estos elementos depende de cada modelo de
datos, pudiendo hacerse en forma de grafos, tablas, etc.
Restricciones: En el mundo real, no están permitidos todos los valores,
cambios de valor o estructuras. Existen unas limitaciones, unas impuestas
por el mismo modelo de datos y otras que impone la naturaleza del
problema que tratamos de representar, denominadas restricciones. Las que
impone el modelo de datos son las restricciones inherentes y las que
responden al deseo de que el sistema de información sea un reflejo lo más
fiel posible del mundo real son las restricciones de integridad o semánticas.
Dinámicas.- Los valores que toman los distintos objetos de un esquema en
un momento determinado reciben el nombre de ocurrencia del esquema o estado
de la base de datos en ese momento determinado, en otro momento la ocurrencia
del esquema será diferente, si entre el primero y el anterior ha ocurrido un cambio
en algún valor de la base de datos. Ambos estados de la base de datos son
ocurrencias válidas, es decir, deben cumplir las restricciones de integridad.
La componente dinámica del modelo consta de un conjunto de operadores
que se definen sobre la estructura del correspondiente modelo de datos, ya que no
todas las estructura admiten el mismo tipo de operaciones. La aplicación de una
operación a una ocurrencia de un esquema transforma a ésta en otra ocurrencia.
Una operación tiene dos componentes:
Localización.- También llamado selección. Consiste en localizar una
ocurrencia de un objeto.
Acción.- Que se realiza sobre la ocurrencia previamente localizada y puede
consistir en una recuperación o una actualización.
Las restricciones de Integridad en los MD
En el mundo real existen ciertas reglas que deben cumplir los elementos
existentes. Cuando diseñamos una BD, deseamos que ésta refleje lo más fielmente
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 2 - Rep(eserlac|ór de |os P(oo|eras de| Vurdo Rea|. Los Vode|os de 0alos Pád|ra 29 de 20ê
posible el problema que estamos tratando de recoger en nuestro sistema de
información, por lo que en el esquema de la base de datos, junto con los objetos,
las asociaciones y las propiedades de los mismos, deberíamos describir también
estas reglas, llamadas restricciones de integridad, las cuales pueden ser
definidas como condiciones que limitan el conjunto de ocurrencias válidas de un
esquema.
La semántica de los datos se encontraba en un principio en la mente del
usuario que era el que comprobaba manualmente si los datos cumplían o no las
reglas a ellos asociadas, posteriormente fue migrando a los programas, y desde
éstos a la base de datos. La semántica del problema tiene que estar centralizada en
la BD y para conseguir esto, los MD han de permitir representar las restricciones de
integridad, y los SGBD en los que están soportados los modelos tienen que
reconocer y gestionar estas restricciones.
Los modelos de datos en el diseño de bases de datos
Resulta conveniente en el diseño de bases de datos, distinguir la fase de
modelado conceptual, que es la descripción del mundo real de acuerdo con un
modelo altamente semántico e independiente del SGBD en el que posteriormente
se vaya a hacer la implementación de la BD, y la fase de diseño lógico, en la cual se
ha de obtener un esquema que responda a la estructura lógica específica del SGBD
que se aplique en cada caso, por lo que dicho esquema está sometido a las
restricciones que imponga el modelo del SGBD en concreto.
Para llegar desde la parcela del mundo real que se está analizando a la base
de datos física hay que seguir los siguientes pasos:
1. Con la ayuda de un modelo conceptual, se obtiene el esquema conceptual.
2. Aplicar al esquema conceptual las reglas del modelo de datos propio del
SGBD que se va a utilizar, se obtiene el esquema lógico (también llamada
esquema de la base de datos).
3. Del esquema lógico se pasa al esquema interno, donde el objetivo es
conseguir la máxima eficiencia de cara a la máquina y al problema
específico.
4. Por último se implementa la base de datos física en los soportes
secundarios.
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 3 - E| Vode|o Erl|dad - lrle((e|ac|ór Pád|ra 30 de 20ê
3
E| Hode|o Ent|dad - |nterre|ac|ón
Los modelos de datos soportados por los SGBD no suelen ofrecer, dado su
bajo nivel de abstracción, los mecanismos suficientes para captar la semántica del
mundo real, por lo que surgen modelos conceptuales, más ricos semánticamente,
que facilitan la labor del diseñador ayudándole en su comunicación con el usuario.
Entre estos modelos de datos semánticos, el modelo Entidad - Interrelación es
posiblemente el de mayor aceptación.
INIkODbCCIÓN
El Modelo Entidad - Interrelación (ME-R), propuesto por Peter P. Chen en
dos conocidos artículos en los que presenta el modelo como una vista unificada de
los datos, centrándose en la estructura lógica y abstracta de los datos, como
representación del mundo real, con independencia de consideraciones de tipo físico.
Posteriormente muchos investigadores han continuado los estudios sobre el ME-R,
haciendo importantes aportaciones al modelo original.
Como su nombre indica, el ME-R se basa en entidades 8cualquier objeto de
interés para el universo descrito) que se interrelacionan o asocian entre sí.
Como indicamos anteriormente, todo modelo de datos tienen básicamente
dos tipos de propiedades:
Estáticas.- Describen la estructura del problema y apenas varían en el
tiempo. Utilizamos el lenguaje de definición de datos (DDL) para
describirlas.
Dinámicas.- Permiten el paso de un estado a otro, ejecutando operaciones
sobre los datos almacenados en la estructura. Para expresar operaciones
se utiliza el Lenguaje de manipulación de datos (DML).
El ME-R, tal como fue propuesto por Chen, no consideraba la parte dinámica,
definiendo únicamente la parte estructural y semántica, así como la forma de
representación de los datos. Posteriormente, otros autores completan el modelo
proponiendo lenguajes de manipulación, capaces de recuperar y actualizar de forma
sencilla los datos almacenados en las estructuras.
De todas formas, al utilizar ME-R como instrumento de diseño de bases de
datos y no estar soportado por los SGBD actuales, la parte dinámica del mismo
carece de interés desde un punto de vista práctico.
E$IÁIICA DEL MODELO ENIIDAD - INIEkkELACIÓN
Se pueden distinguir como conceptos básicos de este modelo: las entidades
e interrelaciones (con sus atributos), además de los dominios que en este
modelo se denominan conjunto de valores.
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 3 - E| Vode|o Erl|dad - lrle((e|ac|ór Pád|ra 31 de 20ê
Entidad
Entidad es una persona, lugar, cosa, concepto o suceso, real o abstracto, de
interés en el dominio del problema. Es aquel objeto acerca del cual queremos
almacenar información en la base de datos.
Llamaremos tipo de entidad a la estructura genérica y ocurrencia de
entidad a cada una de las realizaciones concretas de ese tipo de entidad. Así, el
tipo de entidad AUTOR
1
se refiere a la estructura que nos describe las
características de los autores como una abstracción, mientras que una ocurrencia
de autor será cada uno de los autores en concreto.
La representación gráfica de un tipo de entidad es un rectángulo etiquetado
con el nombre del tipo de entidad, tal y como se indica a continuación.

Existen dos clases de entidades:
Regular.- Las ocurrencias de un tipo de entidad regular tienen existencia
propia, es decir, existen por si mismas.
Débiles.- La existencia de cada ocurrencia de un tipo de entidad débil
depende de la existencia de la ocurrencia del tipo de entidad regular del
cual aquella depende, es decir, si se elimina una ocurrencia del tipo de
entidad regular, desaparecen también con ella todas las ocurrencias de la
entidad débil dependientes de la misma. Un tipo de entidad débil se
representa con dos rectángulos concéntricos con su nombre en el interior.
Por ejemplo, si desaparece un libro, con él desaparecerán todos sus
ejemplares, ya que la existencia de un ejemplar de un cierto libro no tiene
sentido si no existe el correspondiente libro en la base de datos.

Interrelación
Definimos la interrelación como la asociación o correspondencia entre
entidades. Llamamos Tipo de interrelación a la estructura genérica del conjunto
de interrelaciones existentes entre dos o más tipos de entidad, mientras que la
ocurrencia de una interrelación será la vinculación existente entre las ocurrencias
concretas de cada uno de los tipos de entidad que intervienen en la interrelación.
Así, el tipo de entidad AUTOR se interrelaciona con el tipo de entidad LIBRO
mediante el tipo de interrelación A-L; una ocurrencia de esta interrelación es que
"Miguel de Cervantes¨ ha escrito el libro "Rinconete y Cortadillo¨.
Representamos el tipo de interrelación mediante un rombo etiquetado con el
nombre de la interrelación, unido mediante arcos a los tipos de entidad que asocia.

1
Los ejemplos que se indiquen se refieren al diseño de la base de datos de una biblioteca.
EJEMPLAR
AUTOR
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 3 - E| Vode|o Erl|dad - lrle((e|ac|ór Pád|ra 32 de 20ê
En cada arco se indicará el significado o la acción que realiza el tipo de entidad que
une.

Un tipo de interrelación se caracteriza por:
Nombre.- Por el que identificamos de forma única el tipo de interrelación
(etiqueta del rombo) y mediante el cual lo referenciamos.
Grado.- Número de tipos de entidad que participan en un tipo de
interrelación. Puede ser de grado 2 (binarias) cuando asociación dos tipos
de entidad; de grado 3 (ternarias) cuando asociación tres tipos de entidad;
o en general de grado n. La interrelación A-L de la figura es de grado 2.
Tipo de correspondencia.- Número máximo de ocurrencias de un tipo de
entidad que pueden intervenir por cada ocurrencia del otro tipo de entidad
asociado en la interrelación. El tipo de correspondencia es 1:1 cuando en la
interrelación sólo pueden aparecer, como máximo, una ocurrencia del tipo
de entidad por cada ocurrencia del otro; será 1:N si para uno de los tipos
de entidad puede haber un número indefinido (mayor que uno) de
ocurrencias, y será N:M si esto ocurre para ambos tipos de entidad. Para
representarlo gráficamente, se pone una etiqueta que lo indique al lado del
rombo que representa el tipo de interrelación.

Entre dos tipos de entidad puede existir más de un tipo de interrelación
Atributo.-Es cada una de las propiedades características que tiene un tipo
de entidad o de interrelación. Así, el tipo de entidad AUTOR tiene como
atributos Nombre, Nacionalidad, Fecha_Nac, etc.; y los atributos del tipo
de entidad LIBRO son, entre otros, Título, ISBN, etc. El tipo de interrelación
A-L entre AUTOR y LIBRO tiene como atributo Orden_de_Firma.
El conjunto de posibles valores que puede tomar un atributo recibe el
nombre de dominio. El dominio tiene un nombre y una existencia propia con
independencia de cualquier entidad o atributo. Por ejemplo, podemos definir
un dominio Nacionalidades, cuyos valores serán española, francesa, italiana,
norteamericana, etc. El atributo Nacionalidad de AUTOR estará definido sobre
este dominio y tomará de él sus valores; la existencia del atributo
Nacionalidad va unida a la existencia del tipo de entidad AUTOR, mientras que
el dominio Nacionalidades existe por sí mismo, definiéndose con
independencia de AUTOR o de cualquier otro tipo de entidad.
AUTOR LIBRO A-L
N:M
escribe escrito_por
AUTOR LIBRO A-L
escribe escrito_por
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 3 - E| Vode|o Erl|dad - lrle((e|ac|ór Pád|ra 33 de 20ê
El dominio se representa con un círculo u óvalo en cuyo interior
aparece su nombre, mientras que el nombre del atributo se escribe sobre el
arco que une el dominio con el tipo de entidad o de interrelación a la que
pertenece dicho atributo. Para simplificar la representación gráfica, en muchos
casos (siempre que coincida el nombre del dominio con el del atributo) será
suficiente con el nombre del atributo en el interior del círculo u óvalo,
eliminando el nombre del arco (nosotros pondremos el nombre del atributo al
lado del círculo en lugar de en el interior. En el esquema conceptual resultante
del modelado sólo especificaremos los atributos más significativos.

Entre todos los atributos de un tipo de entidad debemos elegir uno o
varios que identifiquen unívoca y mínimamente cada una de las ocurrencias de
ese tipo de entidad (atributo identificador personal principal -AIP-). Puede que
exista más de un atributo que cumpla esta condición (atributo identificador
candidato -AIC-), de los cuales se elige uno como principal y los otros son
alternativos (atributo identificador alternativo -AIA-).


Como en el caso de los tipos de entidad, los tipos de interrelación pueden
también tener atributos. Por ejemplo, en la siguiente figura aparecen los tipos de
LIBRO
L-S
1:N
SOCIO
dni
nombre
domicilio
Cod_Libro
título
idioma
Fecha_Préstamo
Fecha_Devolución
toma_prestado
es_prestado
dni
dni
LIBRO
LIBRO
Idiomas
idioma
idioma
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 3 - E| Vode|o Erl|dad - lrle((e|ac|ór Pád|ra 31 de 20ê
entidad EJEMPLAR LIBRO y SOCIO con alguno de sus atributos, así como los
atributos Fecha_Préstamo y Fecha_Devolución de la interrelación L-S.
Restricciones
Como se expuso en el capítulo anterior, las restricciones pueden limitar los
tipos de estructuras que es posible representar mediante un cierto modelo de datos
(restricciones inherentes), o bien permiten restringir los valores que pueden tomar
ciertos atributos o imponen limitaciones al tipo de correspondencia u otras
características de las interrelaciones (restricciones semánticas).
El ME-R es muy flexible porque se puede considerar que las únicas
restricciones inherentes que impone es la obligatoriedad del Atributo Identificador
Principal, además de que sólo permite definir tipos de interrelación entre tipos de
entidad (no se puede, por ejemplo, definir un tipo de interrelación entre un tipo de
entidad y un tipo de interrelación).
$EMÁNIICA DE LA$ INIEkkELACIONE$
El contenido semántico de las interrelaciones se ha completado con
conceptos tales como las cardinalidades mínima y máxima, las dependencias en
existencia y en identificación, y diversos mecanismos de abstracción (como la
generalización y la agregación).
Cardinalidades de un tipo de entidad
Definimos las cardinalidades máxima y mínima de los tipos de entidad
participantes en un tipo de interrelación como el número máximo y mínimo de
ocurrencias de un tipo de entidad que pueden estar interrelacionadas con una
ocurrencia del otro, u otros tipos de entidad que participan en el tipo de
interrelación. Su representación gráfica es una etiqueta del tipo (0,1), (1,1), (0,n) o
(1,n), según corresponda, que se pone en el arco que une el correspondiente tipo
de entidad con el rombo que representa la interrelación.
Así, por ejemplo, si se tienen las cardinalidades de la siguiente figura, la
etiqueta (1,n) en LIBRO significa que una ocurrencia de AUTOR pueda estar
vinculada con 1, 2,... ó n ocurrencias de LIBRO en el tipo de interrelación A-L; y la
etiqueta (0,n) en AUTOR significa que una ocurrencia de LIBRO pueda estar
vinculada con 0, 1, 2,... ó n ocurrencias de AUTOR, es decir, un autor escribe como
mínimo un (1) libro y como máximo muchos libros (n), y un libro puede ser escrito
por ningún autor (0) (si es anónimo) o por muchos (n).

Las cardinalidades de cada tipo de entidad se representan junto al tipo de
entidad al que afectan, indicando entre paréntesis el valor mínimo y máximo de la
cardinalidad. Se observa que el tipo de correspondencia coincide con la cardinalidad
máxima de los tipos de entidades que asocian en la interrelación.
AUTOR LIBRO A-L
N:M
(0,n) (1,n)
escrito_por escribe
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 3 - E| Vode|o Erl|dad - lrle((e|ac|ór Pád|ra 35 de 20ê
Dependencia en existencia y en identificación
Los tipos de interrelación se clasifican, según el tipo de entidades que
vinculan, en regulares si asocian tipos de entidad regulares y débiles si asocian
un tipo de entidad débil con un tipo de entidad regular. Un tipo de interrelación
débil exige siempre que las cardinalidades del tipo de entidad regular sean (1,1).
Dentro de los tipos de interrelación débil podemos distinguir:
Debilidad por existencia.- Se dice que hay una debilidad por existencia
cuando en una interrelación está vinculado un tipo de entidad regular con
uno débil, de forma que las ocurrencias del tipo de entidad dependiente
(tipo de entidad débil) no pueden existir sin la ocurrencia de la entidad
regular de la que dependen. Si desaparece una ocurrencia de un tipo de
entidad regular, todas las ocurrencias de la entidad débil que dependen en
existencia de la misma desaparecen con ella. Así, por ejemplo, se observa
que el tipo de interrelación CL-C que asocia el tipo de entidad regular
CLIENTE con el tipo de entidad débil CUENTA es una dependencia en
existencia, ya que los datos acerca de las cuentas de un cliente sólo
tendrán sentido si éste permanece en la base de datos. Se indica
añadiendo la etiqueta "E¨ al rombo que representa la interrelación débil con
debilidad por existencia.

Debilidad por identificación.- Hay una dependencia en identificación
cuando, además de la dependencia en existencia, las ocurrencias del tipo
de entidad débil no se pueden identificar sólo mediante sus propios
atributos, sino que se tiene que añadir la clave de la ocurrencia de la
entidad regular de la cual dependen. Así, por ejemplo, se observa que el
tipo de interrelación L-E, que asocia el tipo de entidad regular LIBRO con el
tipo de entidad EJEMPLAR, es dependiente en identificación, ya que un
ejemplar determinado, además de depender en existencia de un cierto
libro, está identificado con la clave del libro (Cod_Libro) del cual depende el
ejemplar, más un código propio (Num_Ejemplar). Se indica gráficamente
añadiendo la etiqueta "ID¨ al rombo que representa la interrelación.

El AIP de EJEMPLAR es Cod_Libro + Num_Ejemplar.
LIBRO L-E
1:N
EJEMPLAR
Num_Ejemplar
Cod_Libro
(1,1) (1,n)
ID
tiene
pertenece
CLIENTE
CUENTA
CL-C
1:N
(1,1) (1,n)
EX
pertenece tiene
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 3 - E| Vode|o Erl|dad - lrle((e|ac|ór Pád|ra 3ê de 20ê
GENEkALIIACIÓN Y HEkENCIA
El ME-R permite representar las relaciones jerárquicas existentes entre los
tipos de entidad de los problemas del mundo real. Como se ha descrito en las
secciones anteriores, la generalización es una abstracción que identifica una
relación jerárquica que representa un tipo de entidad ES_UN subtipo de otro tipo de
entidad representada a un nivel de abstracción mayor. Este tipo de relaciones entre
tipos de entidad implica la consideración de tipos de entidad (o supertipos) y de
subtipos de entidad (clases, superclases y subclases de objetos).
Un subtipo de entidad es un tipo de entidad que mantiene un tipo de
interrelación jerárquica con otro tipo de entidad, y que:
Representa a un conjunto de entidades cuyas propiedades y
comportamiento general es considerado por el tipo de entidad con la que
mantiene el tipo de interrelación.
Las propiedades y el comportamiento de los subtipos son heredados del
tipo de entidad con el cual mantienen un tipo de interrelación jerárquica.
La herencia es una abstracción incorporada al ME-R recientemente e
implica la consideración de que con una única definición de las propiedades
y comportamiento de un conjunto de entidades, esta definición es
automáticamente considerada para todos aquellos conjuntos con los que
exista una relación jerárquica (una especialización).
Bien las propiedades y/o bien el comportamiento de un subtipo puede y
deben cambiar con respecto a otros subtipos que intervengan en la misma
relación jerárquica n-aria entre todos estos subtipos y un mismo tipo de
entidad. Puesto que los subtipos son tipos de entidad a un nivel de
abstracción menor, éstos deben poder distinguirse sin ambigüedad del
resto de los tipos de entidad existentes en la representación del problema
y, por tanto, deben tener un conjunto de propiedades que permita esta
discriminación.
Para cada subtipo de entidad pueden ser redefinidas tanto las propiedades
como el comportamiento del tipo de entidad con la que mantienen un tipo
de interrelación jerárquica. Esta característica permite la existencia de
mecanismos para diferenciar a los diferentes subtipos de una misma clase
y, además, permite la cancelación condicionada de la herencia producida
por la relación jerárquica.
Un tipo de entidad puede ser un subtipo para más de un tipo de entidad
con las que puede mantener diferentes relaciones jerárquicas. Esta
característica, denominada herencia múltiple, permite que un tipo de
entidad herede propiedades y comportamiento de más de otro tipo de
entidad. La herencia múltiple pueda dar lugar, en ocasiones, a
inconsistencias en las propiedades y/o comportamiento que se hereda, lo
que se debe solucionar mediante la redefinición de las herencias.
Un tipo de interrelación jerárquica representa una especialización de un tipo
de entidad en un conjunto de otros tipos de entidad. Esta especialización puede ser
debida a:
1. Una diferencia en cuanto al número de propiedades que definen los
subtipos de entidad. De esta forma, diferentes subtipos que mantienen un
mismo tipo de interrelación jerárquica son definidos en base a la
agregación de un conjunto diferente de propiedades, si bien entre el
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 3 - E| Vode|o Erl|dad - lrle((e|ac|ór Pád|ra 3Z de 20ê
conjunto de subtipos puede existir un subconjunto de propiedades
comunes.
2. Diferentes valores que puede ser medidos para una propiedad que existe
en el conjunto de subtipos que mantienen un mismo tipo de interrelación
jerárquica.
3. A que se cumplan ambas condiciones
La especialización de un tipo de entidad en un conjunto de subtipos puede
ser exclusiva o inclusiva. Una especialización exclusiva, denominada
especialización sin solapamiento, representa el hecho de que una instancia del tipo
de entidad más general sólo puede pertenecer o estar asociada a una y sólo una
instancia de los subtipos de entidad especializados.
Una especialización inclusiva, denominada especialización con
solapamiento, representa el hecho de que una instancia del tipo de entidad más
general puede tener asociadas instancias de cualquiera de los subtipos.
Por otro lado, la especialización de un tipo de entidad en un conjunto de
subtipos puede ser total o parcial. Una especialización total representa el hecho de
que las entidades que son reconocidas en el problema que se está representando
son de alguno de los subtipos especializados, no existiendo entidades que no
pertenezcan a alguno, varios o todos estos subtipos de entidad, no existiendo
entidades que no pertenezcan a alguno, varios o todos estos subtipos de entidad.
Una especialización parcial representa el hecho de que pueden existir
entidades que pertenezcan al tipo de entidad y no a ninguno de los subtipos en los
cuales este tipo de entidad está especializado. Una especialización parcial describe
un refinamiento incompleto del problema que se representa, debido a un
conocimiento incompleto del mismo y/o a una simplificación de la representación
del mismo.
Por tanto, se pueden presentar cuatro tipos de interrelaciones jerárquicas
que pueden ser representadas mediante el ME-R: total sin solapamiento, parcial sin
solapamiento, total con solapamiento y parcial con solapamiento, como se muestra
en los ejemplos A,B,C y D de la figura.
Consideremos el tipo de entidad Persona, (Figura A) la cual puede ser
especializada en dos subtipos de entidad Hombre y Mujer de forma total y sin
solapamiento. Una entidad Persona podrá pertenecer al subtipo Hombre o al
subtipo Mujer necesariamente; es decir, no existirá una entidad Persona que no sea
alguno de estos dos subtipos y además de forma exclusiva, por lo que una entidad
pertenecerá a uno y sólo a uno de estos subtipos. Además, cada entidad de alguno
de estos subtipos vendrá caracterizada por algún atributo o conjunto de atributos
definidos para estos subtipos o heredados del tipo de entidad Persona, más el
atributo sexo, el cual tiene la función de clasificador de las entidades Persona en
alguno de estos subtipos.
En la figura B se muestra un ejemplo de especialización parcial exclusiva. En
este caso se ha considerado un tipo de entidad Enfermedad que puede ser
especializada en dos subtipos Vírica y Bacteriana. Este diagrama representa el
hecho de que en el problema se consideran un conjunto de entidades Enfermedad
las cuales pertenecerán bien a alguno de los subtipos considerados Vírica o
Bacteriana, pero que además existirán entidades Enfermedad las cuales no puedan
ser clasificadas en ninguno de estos subtipos debido, posiblemente, al
desconocimiento del valor del atributo tipo utilizado como discriminador.
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 3 - E| Vode|o Erl|dad - lrle((e|ac|ór Pád|ra 38 de 20ê

Por otro lado, el ejemplo de la figura C representa un refinamiento total con
solapamiento en el que un tipo de entidad Empresa se ha refinado en dos subtipos
Pública y Privada. Se está representando el hecho de que podrán existir en el
dominio del problema entidades que puedan ser consideradas tanto del tipo Pública
como Privada, o bien de ambos tipos al mismo tiempo y, además el hecho de que
no podrán existir entidades que no puedan ser especializadas en alguno de estos
dos subtipos.
El problema representado en la figura D es diferente. En este caso se ha
representado a un tipo de entidad Persona que puede ser refinado en dos subtipos
Trabajador y Estudiante de forma parcial con solapamiento. Este ejemplo
representa que una entidad Persona puede ser del tipo Trabajador y/o del tipo
Estudiante y que además pueden existir entidades Personas que no puedan
clasificarse en ninguno de estos dos subtipos.
Las cardinalidades en la jerarquía
Dependiendo del tipo de interrelación jerárquica que se represente, y por
tanto exista en el dominio del problema, los tipos de entidad que intervienen en el
mismo participan o pueden participar con un número determinado de ocurrencias.
PERSONA
ES_UN
HOMBRE MUJER
0,1 0,1
1,1
sexo
(A)
ENFERMEDAD
ES_UN
VÍRICA BACTERIANA
0,1 0,1
1,1
tipo
(B)
EMPRESA
ES_UN
PÚBLICA PRIVADA
0,1 0,1
1,1
clase
(C)
PERSONA
ES_UN
TRABAJADOR ESTUDIANTE
0,1 0,1
1,1
tipo
(D)
administración empresa nss matrícula
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 3 - E| Vode|o Erl|dad - lrle((e|ac|ór Pád|ra 39 de 20ê
Así, se tienen que tener en cuenta las siguientes consideraciones en la
representación de este tipo de interrelaciones:
El tipo de entidad más general o el supertipo de entidad que es
especializado participa siempre con la cardinalidad mínima 1 y con la
cardinalidad máxima 1, puesto que se está representando como una
entidad de este tipo puede especializarse en otros subtipos.
Para cualquier clase de este tipo de interrelaciones jerárquicas, la
cardinalidad máxima con la que participan los subtipos de entidad en el
tipo de interrelación es 1, puesto que se está representando para cada
entidad del supertipo una especialización o refinamiento de la misma.
Si el tipo de interrelación es total o parcial sin solapamiento, los subtipos
participan siempre con cardinalidad mínima 0, puesto que una entidad del
tipo no puede pertenecer al mismo tiempo a más de un subtipo.
Si el tipo de interrelación es total o parcial con solapamiento, los subtipos
pueden participar con cardinalidad mínima 0 ó 1, puesto que una entidad
del supertipo puede a su vez ser especializada en cualquiera de los
subtipos simultáneamente.
INIEkkELACIONE$ EXCLb$IVA$
En un problema del mundo real, un tipo de entidad puede mantener
relaciones con un conjunto de otros tipos de entidad, pero no siempre estas
relaciones son independientes. Consideremos el ejemplo que muestra la figura, en
el que se presentan tres tipos de entidad Artículo, Proveedor, Fabricante, y el
problema de los artículos suministrados por los proveedores o por los fabricantes,
pero un artículo nunca puede ser suministrado por un proveedor que no fabrica el
artículo, de forma que si el fabricante puede suministrarlo, en ningún momento
será solicitado ese artículo a ningún proveedor.
Para indicar la exclusividad entre dos tipos de interrelación que mantiene un
mismo tipo de entidad se procede a representar un segmento que corta a los dos
arcos que representan la relación del tipo de entidad con los tipos de interrelación
exclusivas.

ARTÍCULO
A-P
1:N
PROVEEDOR
suministra (0,1)
A-F
1:N
PROVEEDOR
(0,1)
suministra
(1,n)
(1,n)
son_servidos
son_servidos
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 3 - E| Vode|o Erl|dad - lrle((e|ac|ór Pád|ra 10 de 20ê
kEFkE$ENIACIÓN DE LA$ kE$IkICCIONE$ EN EL ME-k
El ME-R no cuenta con los mecanismos suficientes para la representación de
las restricciones que pueden estar presentes en los problemas del mundo real. Si
consideramos que una restricción es una condición que está presente para un
conjunto o subconjunto de objetos que están presentes en el dominio del problema,
las restricciones pueden aparecer en:
En los valores que pueden ser medidos para un atributo. Si bien el atributo
está definido en un determinado dominio, en el dominio del problema
puede ser necesario considerar restricciones en cuanto a este dominio. Por
ejemplo, un atributo edad definido en el dominio de los números enteros
de dos dígitos y para el cual sólo se debe considerar que tome los valores
comprendidos en el intervalo [18,65].
En los valores de las correspondencias entre conjuntos de objetos del
sistema que representan los tipos de interrelación entre los tipos de
entidad. Es decir, el valor de las cardinalidades máximas y mínimas.
En la existencia de entidades pertenecientes a un determinado tipo de
entidad, siempre y cuando no existan otras pertenecientes a otro(s) tipo(s)
de entidad (las entidades débiles o las que participan en un tipo de
interrelaciones jerárquicas).
La representación de las restricciones existentes en un problema del mundo
real está directamente ligado a la semántica del problema. La representación de la
semántica es extremadamente compleja si no se utiliza un lenguaje natural, puesto
que la semántica es dependiente del contexto en el que se encuentran los ítems de
información acerca del problema. Pocos modelos de datos son capaces de
representar de forma efectiva la semántica de un problema del mundo real, y
menos aún mediante una representación gráfica. En el ME-R es posible representar
gráficamente parte de las restricciones antes señaladas, aunque no así todas ellas,
como el límite o intervalo de valores que puede tomar un atributo, necesitándose
para ello una representación textual del problema del mundo real.
DINÁMICA DEL MODELO ENIIDAD - INIEkkELACIÓN
Chen, en su artículo donde presentaba el ME-R, no se ocupó de la parte
dinámica del mismo (tampoco propuso ninguna sintaxis para la componente
estática); lo que no resulta extraño si se tiene en cuenta que el modelo está más
orientado al diseño que a la implementación. Sin embargo, en varios trabajos
posteriores se han propuesto lenguajes basados en el ME-R. Estos lenguajes
permiten, además de definir la parte estática del modelo (entidades,
interrelaciones, etc.), formular consultas a la base de datos con sentencias que se
parecen al lenguaje natural y son sencillas de formular.
Entre estos lenguajes destacan CABLE (Chain Based Language), SHOSHANI
(1980) y el CLEAR (Conceptual language for Entibies And Relationship), POONEN
(1978).
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 1 - E| Vode|o Re|ac|ora| Pád|ra 11 de 20ê
4
E| Hode|o Re|ac|ona|
Codd, a finales de los años 60, presentó la teoría matemática de las
relaciones en el campo de las bases de datos, que supuso un sólido fundamento
teórico para el desarrollo, dentro de este enfoque relacional, de nuevos sistemas. El
documento de Codd propone un modelo de datos basado en la teoría de las
relaciones, donde los datos se estructuran lógicamente en forma de relaciones
(tablas), siendo un objetivo fundamental del modelo mantener la independencia de
esta estructura lógica respecto al modo de almacenamiento y a otras características
de tipo físico. Los objetivos que perseguía el trabajo de Codd se pueden resumir
en:
Independencia física.- El modo en que se almacenan los datos no debe
influir en su manipulación lógica y, por tanto, los usuarios que acceden a
esos datos no han de modificar sus programas por cambios en el
almacenamiento físico.
Independencia lógica.- Añadir, eliminar o modificar cualquier elemento
de la base de datos no debe repercutir en los programas y/o usuarios que
están accediendo a subconjuntos parciales de los mismos (vistas).
Flexibilidad.- En el sentido de poder ofrecer a cada usuario los datos de la
forma más adecuada a la correspondiente aplicación.
Uniformidad.- Las estructuras lógicas de los datos presentan un aspecto
uniforme (tablas), lo que facilita la concepción y manipulación de la base
de datos por parte de los usuarios.
Sencillez.- Las características anteriores, así como unos lenguajes de
usuario sencillos, producen como resultado que el modelo de datos
relacional sea fácil de comprender y de utilizar por parte del usuario final.
Para conseguir los objetivos citados, Codd introduce el concepto de relación
(tabla) como estructura básica del modelo. Todos los datos de una base de datos se
representan en forma de relaciones cuyo contenido varía en el tiempo. Una
relación, en terminología relacional, es un conjunto de filas (tuplas) con unas
determinadas características.
Con respecto a la dinámica del modelo, se propone un conjunto de
operadores que se aplican a las relaciones. Algunos de estos operadores son
clásicos de la teoría de conjuntos, no hay que olvidar que una relación se define
matemáticamente como un conjunto, mientras que otros fueron introducidos
específicamente APRA el modelo relacional. Todos ellos conforman el álgebra
relacional.
La teoría de normalización, cuyas tres primeras formas normales fueron
introducidas por Codd desde sus primeros trabajos, elimina dependencias entre
atributos que originan anomalías en la actualización de la base de datos y
proporciona una estructura más regular en la representación de relaciones,
constituyendo el soporte para el diseño de bases de datos relacionales.
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 1 - E| Vode|o Re|ac|ora| Pád|ra 12 de 20ê
E$IkbCIbkA DEL MODELO kELACIONAL
Como hemos señalado anteriormente, la relación es el elemento básico del
modelo relacional, y se puede representar como una tabla
Nombre de tabla
Atributo 1 Atributo 2 ... Atributo n
XXX XXX ... XXX tupla 1
XXX XXX ... XXX tupla 2
... ... ... ... ...
XXX XXX ... XXX tupla m
En ella podemos distinguir su nombre, un conjunto de columnas,
denominadas atributos, que representan las propiedades de la tabla y que
también están caracterizadas por su nombre, y un conjunto de filas llamadas
tuplas, que contienen los valores que toma cada uno de los atributos para cada
elemento de la relación. Por ejemplo, a continuación se representa la relación
AUTOR, donde aparece la estructura del modelo relacional. En ella podemos
observar que el nombre de la relación es AUTOR, los atributos (Nombre,
Nacionalidad e Institución); los dominios (de donde los atributos toman sus
valores; varios atributos pueden tomar valores del mismo dominio); las tuplas
(cada una de las cuales contiene los valores que toma el nombre, la nacionalidad y
la institución de un determinado autor); el grado (número de atributos); y la
cardinalidad (número de tuplas).

AUTOR
Nombre Nacionalidad Institución
Date, C.J. Norteamericana Relational Institute
Codd, D.F. Norteamericana Relational Institute
Ceri, S. Italiana Politécnico de Milán
Saltor, F. Española U.P.C.
Atributos
T
U
P Cardinalidad 4
L
A
S

Grado 3

En una tabla se puede distinguir una cabecera que define la estructura de la
tabla; des decir, sus atributos con los dominios subyacentes, y un cuerpo que está
formado por un conjunto de tuplas que varían con el tiempo.
Esta representación de la relación como una tabla ha sido el origen de que
los productos relacionales y los usuarios utilicen habitualmente el nombre de tabla
xxxxxxxxxx


25
Nombres
Española
Francesa
Italiana
Norteamericana
Nacionalidades
U.P.M
U.P.C.
Politécnico de Milán

Instituciones
DOMINIOS
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 1 - E| Vode|o Re|ac|ora| Pád|ra 13 de 20ê
(en principio ajeno a la teoría relacional) para denominar las relaciones y, como
consecuencia de ello, se llame filas a las tuplas y columnas a los atributos¸ si bien,
la terminología es irrelevante y un producto no es más o menos relacional por
utilizar una terminología u otra.
A continuación se compara la terminología relacional con la que corresponde
a las tablas y a los ficheros.
Relación Tabla Fichero
Tupla Fila Registro
Atributo Columna Campo
Grado Nº Columnas Nº Campos
Cardinalidad Nº Filas Nº Registros
Dominio y Atributo
Un dominio D es un conjunto finito de valores homogéneos y atómicos V
1
,
V
2
, ..., V
n
caracterizado por un nombre; decimos valores homogéneos porque son
todos del mismo tipo, y atómicos porque son indivisibles en lo que al modelo se
refiere, es decir, si se descompusiesen, perderían la semántica a ellos asociada.
Todo dominio ha de tener un nombre, por el cual nos podemos referir a él, y
un tipo de datos: así, el tipo de datos del dominio de nacionalidad es una tira de
caracteres de longitud diez. También se le puede asociar una unidad de medida,
como metros, kilos, etc. y ciertas restricciones.
Los dominios pueden definirse por intención o por extensión. Por ejemplo,
el dominio de las edades de las personas activas se puede definir por intención
como entero de longitud dos comprendido entre 18 y 65, mientras que la definición
del dominio por nacionalidades por intención sería muy pobre semánticamente, ya
que permitiría toda combinación de 10 letras aun cuando no constituyesen un
nombre válido de nacionalidad; por ello, sería preferible definir este dominio por
extensión con los nombres de las distintas nacionalidades que admitiésemos en
nuestra base de datos.
El universo del discurso de una base de datos relacional, representado por
U, está compuesto por un conjunto finito y no vacío de atributos A
1
, A
2
, ..., A
n
,
estructurados en relaciones; cada atributo toma sus valores de un único dominio
(dominio subyacente) y varios atributos pueden tener el mismo dominio
subyacente.
Es muy usual dar el mismo nombre al atributo y al dominio subyacente. En
el caso de que sean varios los atributos de una misma tabla definidos sobre el
mismo dominio, habrá que darles nombres distintos, ya que una tabla no puede
tener dos atributos con el mismo nombre.
Un dominio compuesto se puede definir como una combinación de
dominios simples a la que se pueden aplicar ciertas restricciones de integridad. Por
ejemplo, un usuario puede necesitar, además de los tres dominios Día, Mes y Año,
un dominio compuesto por ellos denominado Fecha, al que podríamos aplicar las
adecuadas restricciones de integridad a fin de que no aparecieran valores no
válidos para la fecha.
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 1 - E| Vode|o Re|ac|ora| Pád|ra 11 de 20ê
Al igual que es posible definir dominios compuestos, existen también
atributos compuestos; así, el atributo Fecha tomaría sus valores del dominio
compuesto de igual nombre.
Al igual que es posible definir dominios compuestos, existen también
atributos compuestos; así, el atributo Fecha tomaría sus valores del dominio
compuesto de igual nombre. Tanto los atributos compuestos como los dominios
compuestos pueden ser tratados, si así lo precisa el usuario, como "piezas únicas¨
de información, es decir, como valores atómicos.
Definición formal de relación
En la noción de relación se distinguen los siguientes elementos:
Nombre.- Las relaciones se identifican con un nombre.
Cabecera de relación.- Conjunto de n pares atributo-dominio subyacente
{(A
i
:D
i
)}
n
, donde n es el grado; se corresponde con la primera fila cuando
la relación se percibe como una tabla. El conjunto A de atributos sobre los
que se define la relación se llama contexto de la misma.
Cuerpo de la relación.- Conjunto de m tuplas {t
1
, t
2
, ..., t
m
}, donde cada
tupla es un conjunto de n pares atributo-valor {(A
i
:V
ij
)}, siendo V
ij
el valor
j del dominio D
i
asociado al atributo A
i
; el número de tuplas m es la
cardinalidad. Así como la cabecera de las relación es invariante, su cuerpo
varía en el transcurso del tiempo al igual que la cardinalidad.
El esquema de la relación estará formado por el nombre R, si existe, y la
cabecera, denotándose: R( {A
i
:D
i
}n ). El esquema de relación representa
la parte definitoria y estática y se denomina también intención. Se
corresponde con lo que hemos llamado tipo de entidad en el ME-R.
Estado de relación r®, al que denominaremos simplemente relación, está
constituido por el esquema y el cuerpo de la relación, siendo el cuerpo el
conjunto de tuplas que, en un instante dado, satisface el correspondiente
esquema de la relación.
Por ejemplo, tomando la relación anterior vamos a presentar el esquema de
la relación y el estado de la relación.
Esquema de la relación (Intención):
AUTOR(Nombre: Nombre, Nacionalidad: Nacionalidades, Institución:
Instituciones)
Relación (Extensión, Estado u Ocurrencia):
AUTOR
Nombre Nacionalidad Institución
Date, C.J. Norteamericana Relational Institute
Codd, D.F. Norteamericana Relational Institute
Ceri, S. Italiana Politécnico de Milán
Saltor, F. Española U.P.C.
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 1 - E| Vode|o Re|ac|ora| Pád|ra 15 de 20ê
Una base de datos relacional es una base de datos percibida por los usuarios
como una colección de relaciones que varían en el tiempo.
Clases de relación
Dividiremos las relaciones en nominadas y sin nombre. Las relaciones
nominadas, a su vez, pueden ser:
Persistentes.- Aquellas cuya definición (esquema de relación) permanece
en la base de datos, borrándose solamente mediante una acción explícita
del usuario. Las relaciones persistentes se dividen en:
o Relaciones base.- Existen por si mismas, no en función de otras
relaciones, y se crean especificando explícitamente su esquema de
relación (nombre y conjunto de pares: atributo-dominio). Sus
extensiones (ocurrencias de la relación), al igual que su definición,
también se encuentran almacenadas.
o Vistas.- Son relaciones derivadas que se definen dando un nombre a
una expresión de consulta. Se podría decir que son relaciones virtuales,
en el sentido de que no tienen datos almacenados, sino que lo único que
se almacena es su definición en términos de otras relaciones con
nombre, las cuales pueden ser relaciones base, otras vistas o
instantáneas.
o Instantáneas.-Son relaciones derivadas al igual que las vistas, es decir,
se definen en términos de otras relaciones nominadas, pero tienen datos
propios almacenados, los cuales son el resultado de ejecutar la consulta
especificada o de guardar una relación base. Las instantáneas no se
actualizan cuando cambian los datos de las relaciones sobre las que
están definidas, pero se "refrescan¨ (es decir, se renuevan sus datos),
cada cierto tiempo, de acuerdo con lo indicado por el usuario en el
momento de su creación. Son, por tanto, sólo de lectura, no pudiendo
ser actualizadas por el usuario, sino únicamente "refrescadas¨ por el
sistema.
Temporales.- A diferencia de las relaciones persistentes, una relación
temporal desaparece de la base de datos en un cierto momento sin
necesidad de una acción de borrado específica del usuario; por ejemplo, al
terminar una sesión o una transacción.
Las relaciones sin nombre son los resultados de las consultas que no se
materializan sino que se entregan al usuario que ha realizado la consulta, y pueden
ser tanto resultados intermedios como finales; en consecuencia, las relaciones no
nominadas son siempre temporales.
Claves
Una clave candidata de una relación es un conjunto de atributos que
identifican unívoca y mínimamente cada tupla de la relación. Por la propia definición
de relación siempre hay, al menos, una clave candidata, ya que al ser una relación
un conjunto no existen dos tuplas iguales y, por tanto, el conjunto de todos los
atributos siempre tiene que identificar unívocamente a cada tupla. Una relación
puede tener más de una clave candidata, entre las cuales se debe distinguir:
Clave primaria.- Es aquella clave candidata que el usuario escogerá, por
consideraciones ajenas al modelo relacional, para identificar las tuplas de la
relación.
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 1 - E| Vode|o Re|ac|ora| Pád|ra 1ê de 20ê
Claves alternativas.- Son aquellas claves candidatas que no han sido
escogidas como clave primaria.
Se denomina clave externa de una relación R2 a un conjunto no vacío de
atributos cuyos valores han de coincidir con los valores de la clave candidata de
una relación R1. La clave externa y la correspondiente clave primaria han de estar
definidas sobre el mismo dominio.
Los conceptos de clave primaria y clave externa son muy importantes en el
estudio de la integridad del modelo relacional, y volveremos a analizarlos en el
siguiente epígrafe.
kE$IkICCIONE$
En el modelo relacional, al igual que en otros modelos, existen restricciones,
es decir, estructuras u ocurrencias no permitidas, siendo preciso distinguir entre
restricciones inherentes y restricciones semánticas (de usuario). Los datos
almacenados en la base de datos han de adaptarse a las estructuras impuestas por
el modelo y han de cumplir las restricciones de usuario a fin de constituir una
ocurrencia válida del esquema.
Restricciones inherentes
Los modelos de datos tienen restricciones que impone el mismo modelo, el
cual no admite ciertas estructuras; son las restricciones inherentes, que no son
definidas por los usuarios, sino obligadas por el mismo modelo, lo que quita
flexibilidad a la hora de representar el mundo real. Estas son:
No hay dos tuplas iguales, por lo que se deduce la obligatoriedad de la
clave primaria.
El orden de las tuplas no es significativo.
El orden de los atributos no es significativo.
Cada atributo sólo puede tomar un único valor del dominio sobre el que
está definido, no admitiéndose por tanto los grupos repetitivos.
Restricciones semánticas
Dentro del contexto relacional, como en otros modelos de datos, existen
restricciones semánticas o de usuario, que son facilidades que el modelo ofrece a
los usuarios a fin de que éstos puedan reflejar en el esquema, lo más fielmente
posible, la semántica del mundo real.
Sin embargo, estas restricciones semánticas del modelo relacional, al igual
que ocurre con cualquier otro modelo, no son muchas veces suficientes para captar
toda la semántica del universos del discurso que se está tratando de modelar. Por
ello, algunos productos añaden ciertas facilidades que permiten programarlas o
bien podrán incluirse en un programa de aplicación con sentencias de manipulación.
Las principales restricciones semánticas del modelo relacional son:
Clave primaria.- Permite declarar un atributo o un conjunto de atributos
como clave primaria de una relación, por lo que sus valores no se podrán
repetir ni se admitirán nulos (integridad de la clave). La obligatoriedad de
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 1 - E| Vode|o Re|ac|ora| Pád|ra 1Z de 20ê
la clave primaria es una restricción inherente del modelo relacional; sin
embargo, la declaración de un atributo como clave primaria de una relación
es una restricción semántica que responde a la necesidad del usuario de
imponer que los valores del conjunto de atributos que constituyen la clave
primaria no se repitan en la relación ni tampoco tomen valores nulos.
Unicidad.- Mediante la cual se indica que los valores de un conjunto de
atributos (uno o más) no pueden repetirse en una relación. Esta restricción
permite la definición de claves alternativas.
Obligatoriedad.- De uno o más atributos, con lo que se indica que el
conjunto de atributos no admite valores nulos.
Integridad referencial.- Si una relación R2 (relación que referencia)
tiene un atributo que es una clave candidata de la relación R1 (relación
referenciada), todo valor de dicho atributo debe concordar con un valor de
la clave candidata referenciada de R1 o bien ser nulo. El atributo, es clave
externa de la relación R2. La clave externa puede ser también parte o total
de la clave primaria de R2.
La integridad referencial es una importante restricción semántica que viene
impuesta por el mundo real, siendo el usuario quien la define al describir el
esquema relacional, y el modelo la reconoce sin necesidad de que se programe ni
de que se tenga que escribir ningún procedimiento para obligar su cumplimiento.
Además de definir las claves ajenas, hay que determinar las consecuencias
que pueden tener ciertas operaciones (borrado y modificación) realizadas sobre
tuplas de la relación referenciada, pudiéndose distinguir las siguientes:
Operación restringida.- El borrado de tuplas de la relación que contiene
la clave referenciada (o la modificación de dicha clave) sólo se permite si
no existen tuplas con este valor en la relación que contiene la clave
externa. Esta es la opción válida por defecto.
Operación con transmisión en cascada.- El borrado de tuplas de la
relación que contiene la clave candidata referenciada (o la modificación de
dicha clave) lleva consigo el borrado (o modificación) en cascada de las
tuplas de la relación que contiene la clave externa.
Operación con puesta a nulos.- El borrado de tuplas de la relación que
contiene la clave candidata referenciada (o la modificación de dicha clave)
lleva consigo poner a nulos los valores de las claves externas de la relación
que referencia.
Operación con puesta a valor por defecto.- El borrado de tuplas de la
relación que contiene la clave candidata referenciada (o la modificación de
dicha clave) lleva consigo poner el valor por defecto a la clave externa de
la relación que referencia, valor por defecto que habría sido definido al
crear la tabla correspondiente.
Las opciones de borrado y modificación pueden ser distintas.
Además de las restricciones que acabamos de exponer, existen en el modelo
relacional otras restricciones que podríamos llamar de rechazo, en las que el
usuario formula una condición mediante un predicado definido sobre un conjunto de
atributos, de tuplas o dominios, el cual debe ser verificado por los correspondientes
objetos en toda operación de actualización para el nuevo estado constituya una
ocurrencia válida del esquema; en caso de que la operación intente violar la
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 1 - E| Vode|o Re|ac|ora| Pád|ra 18 de 20ê
condición se impide que la operación se lleve a cabo, es decir se rechaza la
operación.
En el modelo relacional se pueden distinguir dos restricciones de rechazo
distintas, según la condición afecte a un único elemento de la base de datos o a
más de uno:
Verificación.- Comprueba, en toda operación de actualización, si el
predicado es cierto o falso y, en el segundo caso, rechaza la operación. La
restricción de verificación se define sobre un único elemento (incluyéndose
en la definición de dicho elemento) y puede o no tener nombre.
Aserción.- Actúa de forma idéntica a la anterior, pero se diferencia de ella
en que puede afecta a varios elementos (por ejemplo a dos relaciones
distintas) y su definición; por tanto, no va unidad a la de un determinado
elemento, por lo que siempre ha de tener un nombre, ya que la aserción es
un elemento más del esquema que tiene vida por sí mismo.
También es posible definir restricciones de transición haciendo referencia en
el predicado a los valores anteriores a la operación de actualización y a los nuevos
valores.
También es importante en una restricción el momento en el que ésta se
verifica dentro de una transacción. Así, el modo de verificación es inmediato, la
restricción se verificará al finalizar cada sentencia, mientras que si es diferido se
verificará al finalizar la transacción.
LO$ VALOkE$ NbLO$ EN EL MODELO kELACIONAL
Concepto de valor nulo
Se puede definir el valor nulo como una señal utilizada para representar
información desconocida, inaplicable, inexistente, no válida, no proporcionada,
indefinida, etc.
La necesidad de los valores nulos en las bases de datos es evidente por
diversas razones:
Crear tuplas (filas) con ciertos atributos desconocidos en ese momento.
Añadir un nuevo atributo a una relación existente; atributo que, en el
momento de añadirse, no tendría ningún valor para las tuplas de la
relación.
Atributos inaplicables a ciertas tuplas.
El tratamiento de valores nulos en algún operando utilizado en las
operaciones exige definir:
Operaciones de comparación.- Se introducen los operadores ES_NULO,
que es cierto si el operando es nulo o falso en caso contrario, y el operador
SI_NULO, que se aplica a dos operandos y devuelve el valor del primero,
salvo que sea nulo, en cuyo caso devuelve el valor del segundo.
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 1 - E| Vode|o Re|ac|ora| Pád|ra 19 de 20ê
Operaciones aritméticas.- Se considera nulo el resultado de sumar,
restar, multiplicar o dividir cuando alguno de los operandos toma el valor
nulo.
NOkMALIIACIÓN DE kELACIONE$
El diseño de una base de datos relacional se puede realizar mediante la
metodología que acabamos de exponer, aplicando al mundo real, en una primera
fase, un modelo semántico como el ME-R, a fin de obtener un esquema conceptual;
en una segunda fase, se transforma dicho esquema al modelo relacional mediante
las correspondientes reglas de transformación
2
. Si bien es muy conveniente este
enfoque, existe otra posibilidad, nada aconsejable, que es plasmar directamente en
el modelo relacional nuestra percepción del mundo real, obteniendo el esquema
relacional sin realizar ese paso intermedio que es el esquema conceptual.
Aunque en general, la primera aproximación produce un esquema relacional
estructurado y con poca redundancia, por lo que no es imprescindible verificar la
"bondad¨ del esquema obtenido, siempre es conveniente aplicar un conjunto de
reglas, conocidas como teoría de la normalización, que nos permiten asegurar
que un esquema relacional cumple unas ciertas propiedades. En el segundo
enfoque, es decir, cuando no se ha aplicado la metodología de diseño
anteriormente expuesta (diseñar la BD a lo bruto), la teoría de normalización
resulta imprescindible.
Entre los problemas que puede presentar un esquema relacional cuando el
diseño es inadecuado cabe destacar:
Incapacidad para almacenar ciertos hechos.
Redundancias y, por tanto, posibilidad de inconsistencias.
Ambigüedades.
Pérdida de información.
Pérdida de ciertas restricciones de integridad que dan lugar a
interdependencias entre los datos (dependencias funcionales).
Aparición en la BD, como consecuencia de las redundancias, de estados
que no son válidos en el mundo real; es lo que se llama anomalías de
inserción, borrado y modificación.
El esquema relacional debe ser, por tanto, analizado para comprobar que no
presenta los problemas anteriormente citados, evitando así la pérdida de
información y la aparición de inconsistencias.
En el siguiente ejemplo, la relación ESCRIBE almacena datos sobre los libros
(Cod_Libro, Título, Editorial, Año) y sobre los autores que los han escrito (Autor y
Nacionalidad). Si observamos esta relación, vemos que presenta varios de los
problemas enumerados anteriormente.
ESCRIBE
AUTOR NACIONALIDAD COD_LIBRO TÍTULO EDITORIAL AÑO

2
Las reglas de transformación del esquema conceptual al relacional se verán en el siguiente capítulo
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 1 - E| Vode|o Re|ac|ora| Pád|ra 50 de 20ê
Date, C. Norteamericana 23433 Databases Addisson-W 1990
Date, C. Norteamericana 55654 SQL Standard Addisson-W 1986
Date, C. Norteamericana 53235 Guide to Ingres Addisson-W 1988
Codd, E. Norteamericana 97875 Relational M. Adisson-W 1990
Gardarin Francesa 32245 Base de Datos Paraninfo 1986
Gardarin Francesa 55366 Comparación BD Eyrolles 1984
Valduriez Francesa 86754 Comparación BD Eyrolles 1984
Kim, W. Norteamericana 32176 OO Databases ACM Press 1989
Lochovsky Canadiense 23456 OO Databases ACM Press 1989
Los principales problemas de esta relación se derivan de la gran cantidad de
redundancia que presenta. Por ejemplo, la nacionalidad del autor se repite por cada
libro que ha escrito; y algo análogo sucede, cuando un libro tiene más de un autor,
con la editorial y el año de publicación. Esta redundancia produce a su vez:
Anomalías de inserción, ya que dar de alta un libro obliga a insertar en la
base de datos tantas tuplas como autores tenga el libro.
Anomalías de modificación, ya que cambiar la editorial de un libro obliga a
modificar todas las tuplas que corresponden a ese libro.
Anomalías de borrado, ya que el borrado de un libro obliga a borrar varias
tuplas, tantas como autores tenga ese libro y, viceversa, el borrado de un
autor nos lleva a borrar tantas tuplas como libros ha escrito ese autor.
Vemos, por tanto, que la actualización (alta, baja o modificación) de un solo
libro o de un solo autor nos puede obligar a actualizar más de una tupla, dejándose
la integridad de la base de datos en manos del usuario. Al riesgo de la posible
pérdida de integridad hay que añadir la falta de eficiencia asociada a estas
múltiples actualizaciones.
Además de estas anomalías de inserción, borrado y modificación, existen
otros problemas adicionales, como la imposibilidad de almacenar ciertos hechos o la
desaparición de información que desearíamos mantener en la base de datos. Por
ejemplo, si se quisiera incluir información sobre un autor del que no existiera
ningún libro en la base de datos, no sería posible, ya que el atributo Cod_libro
forma parte de la clave primaria de la relación; ni tampoco podríamos introducir
obras anónimas (recuerde la regla de integridad de entidad que no permite los
nulos en ningún atributo que forme parte de la clave primaria). Por otro lado, al dar
de baja un libro, se pierden también los datos de sus autores (si éstos sólo tuviesen
ese libro en la base de datos) y, viceversa, si borramos un autor desaparecen de
nuestra base de datos los libros escritos por él (a no ser que el libro tuviera más de
un autor).
Esta relación presenta todos estos problemas debido a que atenta contra un
principio básico en todo diseño: Hechos distintos se deben almacenar en
objetos distintos, en este caso, en relaciones distintas, con lo que se habrían
evitado redundancias y, por tanto, los problemas que acabamos de escribir.
Si se hubiera llevado a cabo un diseño riguroso no se habría presentado una
relación de este tipo. El problema es que a menudo no se llega a comprender
completamente o a representar de forma precisa el problema, debido a una
excesiva premura al realizar el análisis o a carecer el analista de conocimientos
sobre metodologías de diseño de bases de datos o de experiencia para aplicarlas
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 1 - E| Vode|o Re|ac|ora| Pád|ra 51 de 20ê
adecuadamente. Si se siguiera la metodología de diseño propuesta, realizando un
buen diseño conceptual en el ME-R, seguido de una cuidadosa transformación al
modelo relacional, se evitarían en gran parte estas anomalías, obteniéndose en
general un esquema exento de errores. Sin embargo, ante las posibles dudas
respecto a si un determinado esquema relacional es o no correcto, será preferible
aplicar siempre a dicho esquema un método formal de análisis que determine lo
que pueda estar equivocado en el mismo y nos permita llegar a otro esquema en el
que se asegure el cumplimiento de ciertos requisitos; este método formal es la
teoría de la normalización.
Dependencias funcionales
La teoría de la normalización se basa en el concepto de dependencias, hasta
el punto de que también se la conoce como la teoría de las dependencias.
Una dependencia funcional consiste en: sea el esquema de relación R,
definido sobre el conjunto de atributos A y sean X e Y subconjuntos de A. Se dice
que Y dependen funcionalmente de X, o lo que es igual X determina Y, si y sólo si,
cada valor de X tiene asociado en todo momento un único valor de Y.
Representamos esta dependencia funcional de la siguiente forma:
X ---> Y
Se denomina determinante o implicante al descriptor que se encuentra a la
izquierda del símbolo de implicación, e implicado al descriptor que se encuentra a la
derecha.
Por ejemplo, sea la relación:
LIBRO(Cod_Libro, Título, Idioma, ... )
Podemos decir que el código de un libro determina el título del mismo
Cod_Libro ---> Título
El código del libro es el determinante y título es el implicado. Esta
dependencia nos dice que el título es una información acerca del libro.
El hecho de que el código del libro determina el título no quiere decir que
conocido el código de un libro podamos deducir, a partir de él, cuál es su título.
Solamente nos limitaremos a afirmar que para dos tuplas que tengan el mismo
código del libro, tienen que tener el mismo título.
Una herramienta muy útil a la hora de explicitar las dependencias
funcionales es el grafo o diagrama de dependencias funcionales, mediante el cual
se representa un conjunto de atributos y las dependencias funcionales existentes
entre ellos. En el grafo aparecen los nombres de los atributos unidos por flechas,
las cuales indican las dependencias funcionales y parten del implicante hacia el
implicado. Cuando el implicante de una dependencia no es un único atributo, es
decir, se trata de un implicante compuesto, los atributos que lo componen se
encierran en un recuadro y la flecha parte de éste, no de cada atributo.
En la siguiente figura se presenta un ejemplo de cómo se visualizan las
dependencias; podemos observar que Cod_Libro determina funcionalmente el Título
del libro y la Editorial, como indica la correspondiente flecha; de forma análoga,
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 1 - E| Vode|o Re|ac|ora| Pád|ra 52 de 20ê
Num_socio determina el Nombre, Domicilio y Teléfono del socio, mientras que
ambos atributos en conjunto Cod_Libro y Num_socio (lo que se indica haciendo que
la flecha parta del recuadro que los incluye) determinan Fecha_prestamo y
Fecha_dev.

Existen otros conceptos, como el de dependencia plena o completa y el de
dependencia transitiva, fundamentales en la teoría de la normalización, que
veremos a continuación.
Dependencia funcional plena o completa
Sea un descriptor compuesto X:
X(X1, X2)
Se dice que Y tiene dependencia funcional completa o plena de X si
dependen funcionalmente de X pero no depende de ningún subconjunto del mismo,
es decir, Y dependen de todos, y exclusivamente de todos, los atributos que
forman X. Se representa por X ==> Y.
Por ejemplo, supongamos la siguiente relación de la cual dibujamos el grafo
anterior:
PRESTAMO(Cod_Libro, Título, Editorial, Num_socio, Nombre, Domicilio,
Teléfono, Fecha_préstamo, Fecha_dev)
La dependencia funcional
Cod_Libro, Num_socio ----> Fecha_prestamo
indica que, dado un determinado código de libro y un número de socio,
existe una única fecha de préstamo. Ni código de libro, ni tampoco número de
socio, implican, por sí solos, la fecha del préstamo, ya que tanto un libro se puede
prestar en varias fechas como un socio puede recibir libros prestados en varias
fechas. Por tanto, la dependencia funcional anterior es completa, lo que se
representa:
Cod_Libro, Num_socio ===> Fecha_prestamo
Esto quiere decir que la fecha del préstamo constituye una información
sobre el conjunto de libro y socio, pero esta información no atañe a un libro o a un
socio por separado.
Por el contrario, la dependencia:

Cod_Libro Título, Editorial

Num_socio Nombre, Domicilio, Teléfono
Fecha_préstamo, Fecha_dev
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 1 - E| Vode|o Re|ac|ora| Pád|ra 53 de 20ê
Cod_Libro, Num_socio ----> Editorial
No es plena, ya que:
Cod_Libro ------> Editorial
Se dice entonces que, en esa dependencia, Num_socio es un atributo
redundante o ajeno a la dependencia (también llamado extraño).
Dependencia funcional transitiva
Sea la relación R(X,Y,Z) en la que existen las siguientes dependencias
funcionales:
X---->Y
Y---->Z
Y--/-->X
Se dice entonces que Z tiene una dependencia transitiva respecto de X a
través de Y, lo que se representa por:
X --- ---> Z
Por ejemplo, consideremos la siguiente relación:
LIBROS(Cod_libro, Editorial, País)
donde tenemos, para cada libro, su código, la editorial que lo publica y el
país de la editorial (suponemos que una editorial tiene su sede en un único país), se
tendrán las siguientes dependencias:
Cod_libro ---> Editorial
Editorial ---> País
Además, Editorial ---/---> Cod_libro, al depender País de Editorial y ésta de
Cod_libro, entonces País depende transitivamente de Cod_libro.
Cod_libro --- ---> País.
Reglas de normalización
La teoría de la normalización está basada en la aplicación de una serie de
reglas a las que se les denomina Reglas de normalización. Se dice que una relación
está en una determinada forma normal si satisface un cierto conjunto específico de
restricciones impuestas por la regla de normalización correspondiente. La aplicación
de una regla de normalización es una operación que toma una relación como
argumento de entrada y da como resultado dos o más relaciones, y:
La relación a la que se aplica la regla es desestimada en el nuevo esquema
relacional obtenido.
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 1 - E| Vode|o Re|ac|ora| Pád|ra 51 de 20ê
No se introducen nuevos atributos en el esquema relacional resultante de
la normalización.
Los atributos de la relación a la que se aplica la regla pasan a formar parte
de la intención de una o más de las relaciones resultantes.
En la aplicación de la regla de normalización se ha debido eliminar, al
menos, una dependencia existente entre los atributos de la relación a la
que se aplica la regla.
De esta forma, la sucesiva aplicación de las reglas de normalización va a dar
lugar a la generación de un número mayor de relaciones que formen parte del
esquema relacional y, desde un punto de vista sólo lógico, una redundancia de los
atributos considerados en el esquema.
La aplicación sucesiva de las reglas de normalización restringe, por tanto el
número de relaciones que las satisfacen. Por regla general, se dice que un esquema
relacional es consistente si las relaciones satisfacen al menos la forma normal de
Boyce-Codd
La primera forma normal FN1
Recordemos que para que una tabla pueda ser considerada una relación no
debe admitir grupos repetitivos, es decir, debe estar en primera forma normal.
Una relación R satisface la primera forma normal (FN1) si, y sólo si, todos
los atributos toma un único valor del dominio subyacente.
Por ejemplo observemos la siguiente tabla:
PEDIDO(Número, Fecha, NumProv, NomPro, DirPro, Ref, Descripción,
Cant, Precio)
Numero Fecha Num
Prov
NomPro DirPro Ref Descripción Cant Precio
00001 01/02/02 987 Pérez Luna, 2 0024 Clavos 20000 0.02
0025 Puntas 40000 0.03
0038 Tornillos 80000 0.01
00003 02/02/02 999 Márquez Goya, 23 1002 Cunas 100 60
1004 Camas 20 600
2001 Mesas 500 30
00005 04/02/02 555 López Sol, 10 5002 Lamparas 50 35
Se observa que para cada fila, existen varios valores para los atributos Ref,
Descripción, Cant y Precio; es decir, hay pedidos que tienen más de un artículo.
Para pasar esta tabla (no es relación porque no está en FN1) a FN1, habrá que
repetir el resto de atributos de la tupla para cada uno de los valores del grupo
repetitivo, tal y como aparece a continuación.
PEDIDO(Número, Fecha, NumProv, NomPro, DirPro, Ref, Descripción,
Cant, Precio)
Numero Fecha Num
Prov
NomPro DirPro Ref Descripción Cant Precio
00001 01/02/02 987 Pérez Luna, 2 0024 Clavos 20000 0.02
00001 01/02/02 987 Pérez Luna, 2 0025 Puntas 40000 0.03
00001 01/02/02 987 Pérez Luna, 2 0038 Tornillos 80000 0.01
00003 02/02/02 999 Márquez Goya, 23 1002 Cunas 100 60
00003 02/02/02 999 Márquez Goya, 2 1004 Camas 20 600
00003 04/02/02 999 Márquez Goya, 2 2001 Mesas 500 30
00005 04/02/02 555 López Sol, 10 5002 Lamparas 50 35
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 1 - E| Vode|o Re|ac|ora| Pád|ra 55 de 20ê
Segunda forma normal FN2
Una relación R satisface la segunda forma normal (FN2) si, y sólo si,
satisface la primera forma normal y cada atributo de la relación depende
funcionalmente de forma completa de la clave primaria de esa relación.
Por ejemplo, consideremos la siguiente relación:
PRESTAMO( Cod_libro, Num_socio, Nombre, Domicilio, Teléfono,
Fecha_préstamo, Fecha_dev)
En la que el conjunto de Cod_libro y Num_socio forman la clave principal de
la relación, y en la que existen las siguientes dependencias funcionales:
Num_socio ---> Nombre
Num_socio ---> Domicilio
Num_socio ---> Teléfono
Cod_libro, Num_socio ---> Fecha_préstamo
Cod_libro, Num_socio ---> Fecha_dev
Podemos observar que solo hay dos atributos que dependen de la clave
completa: Fecha_préstamo y Fecha_dev. El resto depende de parte de la clave. Los
atributos Nombre, Domicilio y Teléfono depende de Num_socio.
Por tanto esta relación no se encuentra en FN2 al haber atributos que sólo
dependen de parte de la clave y no de la clave completa. Esta relación presenta los
siguientes inconvenientes al no estar en FN2:
Inserción de tuplas.- No se pueden conocer los socios que hay en el
sistema hasta que no exista un préstamo, ya que si se introduce una tupla
sólo con los valores del socio, habría valores nulos en parte de la clave
(Cod_libro) con lo que se viola la regla de integridad de la clave.
Borrado de tuplas.- Si se eliminan las tuplas correspondientes a los libros
prestados a un socio, se pierde la información que representa ese socio.
Actualización de tuplas.- Si se cambia el número de teléfono de un socio,
hay que actualizar todas las tuplas donde aparezca ese número de socio.
Para eliminar todos estos inconvenientes es necesario realizar un proceso de
descomposición de la relación PRESTAMO en dos nuevas relaciones que satisfacen
la FN2. Estas relaciones quedarían de la siguiente manera:
PRESTAMO(Cod_libro, Num_socio, Fecha_préstamo, Fecha_dev)
SOCIO(Num_socio, Nombre, Domicilio, Teléfono)
Vemos que los atributos que dependían del atributo Num_socio se han
eliminado de la relación original, formando, junto con éste, una nueva relación,
SOCIO. En esta nueva relación el atributo del que dependían será clave primaria y
el atributo Num_socio de la relación PRESTAMO será definido como clave externa
con la relación SOCIO, para que sólo pueda tomar valores nulos o bien igual a
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 1 - E| Vode|o Re|ac|ora| Pád|ra 5ê de 20ê
valores existentes en alguna tupla de la relación SOCIO, de esta forma no habrá
pérdida de información.
Tercera forma normal FN3
Una relación R satisface la tercera forma normal (FN3) si, y sólo si, satisface
la segunda forma normal y cada atributo no principal de la relación no depende
transitivamente de la clave principal.
Por ejemplo, consideremos la siguiente relación:
MATRICULA(dni_alumno, asignatura, nota, aula, ubicación)
Esta relación representa la docencia que recibe un alumno de una asignatura
en un aula que se encuentra situada en una ubicación, por la cual será evaluado
con una nota. La clave principal son los atributos dni_alumno y asignatura. Se
observan las siguientes dependencias:
dni_alumno, asignatura ---> nota
dni_alumno, asignatura ---> aula
aula ---> ubicación
Como se puede apreciar, la relación está en FN2, ya que los atributos no
principales que dependen de la clave lo hacen de forma completa, pero el atributo
ubicación depende del atributo aula, y como el atributo aula depende de la clave
tenemos una dependencia transitiva de dni_alumno, asignatura --- ---> ubicación.
Es decir el atributo ubicación depende completamente de la clave a través del
atributo aula, que no forma parte de la clave.
La existencia de estas dependencias entre los atributos no principales
ocasiona problemas en la manipulación de la relación en:
Inserción de tuplas.- No se pueden conocer las aulas de cada ubicación
utilizadas para la docencia de asignaturas hasta que no haya algún alumno
matriculado en esa asignatura.
Borrado de tuplas.- Una vez borrados todos los alumnos matriculados en
una asignatura, se pierde la información correspondiente a las aulas de
cada ubicación utilizadas para la docencia.
Modificación de tuplas.- Existe una gran redundancia de información puesto
que se almacena la ubicación en el que se encuentra situada un aula para
cada uno de los alumnos que cursan una asignatura que se imparte en
dicha aula.
Para eliminar los problemas que ocasiona en la relación la existencia de esta
dependencia transitiva, hay que descomponerla en dos relaciones, quedando de la
siguiente manera:
MATRICULA(dni_alumno, asignatura, aula)
UBICACION(aula, ubicación)
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 1 - E| Vode|o Re|ac|ora| Pád|ra 5Z de 20ê
Donde se observa que la relación MATRICULA está en FN3, ya que todas las
dependencias que existen son completas entre atributos no principales y la clave de
la relación. Se ha generado una nueva relación, UBICACIÓN, para la cual el atributo
aula es clave, y tiene un único atributo no principal, ubicación, el cual depende
funcionalmente de la clave, por lo que también se encuentra en FN3. El atributo
aula de la relación MATRICULA deberá definirse como clave externa de la relación
UBICACIÓN, de forma que para cualquier tupla de la relación MATRICULA este
atributo sólo pueda tomar valores nulos o bien igual a valores existentes en alguna
tupla de la relación UBICACIÓN.
La forma normal de Boyce-Codd (FNBC)
Una relación R satisface la forma normal de Boyce-Codd (FNBC) si, y sólo si,
se encuentra en FN1, y cada determinante funcional es una clave candidata de la
relación R.
Observemos la siguiente relación
MATRICULA( dni, asignatura, apellidos, nombre, nota, aula)
Se observa que hay dos claves candidatas: dni, asignatura y asignatura,
apellidos, nombre. Vamos a suponer que no existen dos alumnos con el mismo
nombre. En esta relación hay un dependencia funcional mutua entre el atributo dni
y el agregado apellidos + nombre. Una dependencia funcional es mutua cuando
X ---> Y
Y ---> X
Y se representa por X <---> Y. En el ejemplo en cuestión nos encontramos
la dependencia funcional mutua:
dni <---> apellidos, nombre
Además, de la dependencia funcional mutua descrita, existen las siguientes
dependencias:
dni, asignatura ---> nota
dni, asignatura ---> aula
asignatura, apellidos, nombre ---> nota
asignatura, apellidos, nombre ---> aula
Vemos que los atributos no principales mantienen dependencia funcional
completa con las claves candidatas.
En las dos claves candidatas está presente un atributo común, el atributo
asignatura, el cual forma parte de los dos determinantes funcionales, por lo que
ambas claves se encuentran traslapadas. Dos claves candidatas se dice que están
traslapadas si cada una de ellas está formada por dos o más atributos y alguno de
ellos es común a ambas. La presencia de claves traslapadas pueden ocasionar
serios problemas en el mantenimiento de la información que hay que resolver. La
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 1 - E| Vode|o Re|ac|ora| Pád|ra 58 de 20ê
relación MATRICULA sería conveniente descomponerla en dos relaciones que
satisfagan la FNBC, quedando de la siguiente forma:
MATRICULA(dni, asignatura, nota, aula)
ALUMNO(dni, apellidos, nombre)
La descomposición realizada ha sido: se crea una nueva relación
(MATRICULA) que tendrá como clave principal una de las claves candidatas de la
relación original (dni, asignatura) y los atributos que no forman parte de ninguna
clave candidata (nota, aula). Con los atributos que mantienen dependencia
funcional mutua (dni <---> apellidos, nombre) se crea otra relación (ALUMNO), en
la que un determinante es clave principal (dni), y el otro es clave alterna (apellidos,
nombre), de esta forma sigue existiendo la dependencia funcional mutua que
mantenían. El atributo de esta relación (ALUMNO) elegido como clave principal
(dni), será, en la otra relación (MATRICULA) clave externa con esta.
Se observa que se ha definido el agregado apellidos, nombre como clave
alterna en la relación ALUMNO, de esta forma sigue existiendo la dependencia
funcional mutua entre dni y apellidos, nombre. El atributo dni de la relación
MATRICULA es clave externa con la relación ALUMNO.
LA$ 12 kEGLA$ DE CODD FAkA LO$ $I$IEMA$ kELACIONALE$
1. Representación de la información.- Toda información en una base de
datos relacional debe representarse explícitamente a nivel lógico, y de
manera única, por medio de valores en tablas. Podríamos decir que éste es
el principio básico del modelo relacional.
2. Acceso garantizado.- Todo dato debe ser accesible mediante una
combinación de un nombre de tabla, un valor de su clave y el nombre de
una columna.
3. Tratamiento sistemático de valores nulos.- Los valores nulos,
información desconocida o inaplicable, han de ser tratados
sistemáticamente por el sistema, el cual ha de ofrecer las facilidades
necesarias para su tratamiento.
4. Catálogo activo en línea basado en el modelo relacional.- La
representación de la metainformación (descripción de la base de datos)
debe ser igual a la de los otros datos, y su acceso debe poder realizarse
por medio del mismo lenguaje relacional que se utiliza para los demás
datos; es decir, el modelo de datos para la metainformación debe ser
también relacional.
5. Sublenguaje de datos completo.- Debe existir un lenguaje que permita
un completo manejo de la base de datos (definición de datos, definición de
vistas, manipulación de datos, restricciones de integridad, autorizaciones y
gestión de transacciones).
6. Actualización de vistas.- Toda vista teóricamente actualizable debe
poder ser actualizada por el sistema.
7. Inserciones, modificaciones y eliminaciones de algo nivel.- Todas las
operaciones de manipulación de datos (consulta, inserción, modificación y
borrado) debe operar sobre conjuntos de filas.
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 1 - E| Vode|o Re|ac|ora| Pád|ra 59 de 20ê
8. Independencia física de los datos.- El acceso lógico a los datos debe
mantenerse incluso cuando cambien los métodos de acceso o la forma de
almacenamiento.
9. Independencia lógica de los datos.- Los programas de aplicación no
deben verse afectados por cambios realizados en las tablas que estén
permitidos teóricamente y que preserven la información.
10. Independencia de la integridad.- Las reglas de integridad de una base
de datos deben ser definibles por medio del sublenguaje de datos
relacional y habrán de almacenarse en el catálogo de la base de datos
(metabase), no en los programas de aplicación.
11. Independencia de la distribución.- Debe existir un sublenguaje de
datos que pueda soportar bases de datos distribuidas sin alterar los
programas de aplicación cuando se distribuyan los datos por primera vez o
se redistribuyan éstos posteriormente.
12. Regla de la no subversión.- Si un SGBD soporta un lenguaje de bajo
nivel que permite el acceso fila a fila, éste no puede utilizarse para saltarse
las reglas de integridad expresadas por medio del lenguaje de más alto
nivel.
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 5 - T(aducc|ór de Escueras Corceplua|es a Re|ac|ora|es Pád|ra ê0 de 20ê
5
Traducc|ón de| Hode|o Ent|dad -
|nterre|ac|ón a| Hode|o Re|ac|ona|
Vamos a presentar una serie de reglas fáciles de entender y aplicar para el
proceso de traducción de los esquemas conceptuales realizados mediante el ME-R a
esquemas lógicos basados en el modelo relacional.
El proceso de traducción de esquemas conceptuales a lógicos consiste en la
aplicación, por pasos, de una serie de reglas que, aplicadas a los esquemas
conceptuales, transforman los objetos de estos esquemas en objetos
pertenecientes a los esquemas lógicos. En el caso que nos ocupa, la aplicación de
las reglas va a dar lugar a la transformación de los tipos de entidad y los tipos de
interrelación que forman parte de los esquemas conceptuales, en tablas o
relaciones, los únicos objetos que intervienen en los esquemas lógicos relacionales.
FkEFAkACIÓN DE LO$ E$QbEMA$ CONCEFIbALE$
Previo a la aplicación de las reglas de transformación de esquemas
conceptuales a esquemas relacionales, las cuales denominaremos abreviadamente
RTECAR, es conveniente la preparación de los esquemas conceptuales mediante la
aplicación de unas reglas preparatorias (PRTECAR) que faciliten y garanticen la
fiabilidad del proceso de transformación.
Las PRTECAR se basan en la aplicación de la primera forma normal a los
objetos que forman parte de los esquemas conceptuales. Si consideramos que
tanto los tipos de entidad como de interrelación pueden ser representados por
tablas bidimensionales (al igual que en el modelo relacional), el principio en el que
se basan estas reglas es el de eliminar de estos tipos de objetos las siguientes
anomalías:
1. Aquellos atributos correspondientes a los tipos de entidad e interrelación
que presenten valores múltiples.
2. Aquellos atributos correspondientes a los tipos de entidad e interrelación
que sean compuestos.
En el primer caso consiste en considerar que los atributos existentes en el
esquema conceptual sólo pueden tomar valores atómicos (al igual que propone la
FN1). Mientras que el segundo caso hace referencia a la eliminación de agregados
de datos o atributos formados por otros atributos más simples.
Eliminación de atributos múltiples
Consiste en aplicar la siguiente regla:
PRTECAR-1: Todos los atributos múltiples; es decir, los atributos que
pueden tomar más de un valor en el dominio en el cual están definidos, se
transformarán en un tipo de entidad débil por existencia, el cual mantendrá una
relación uno a muchos (1:N) con el tipo de entidad sobre el cual estaba definido o
los tipos de entidad que mantenían un tipo de interrelación si el atributo múltiple
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 5 - T(aducc|ór de Escueras Corceplua|es a Re|ac|ora|es Pád|ra ê1 de 20ê
estaba definido sobre el tipo de interrelación. Este tipo de entidad débil, creado por
la aplicación de esta regla, tendrá como propiedades el atributo múltiple por el cual
la regla se ha aplicado. Además, se deberá tener en cuenta que si el atributo del
tipo de entidad débil creado no pudiera identificar sin ambigüedad a las entidades
de este tipo, entonces se procederá de alguna de las dos formas siguientes:
1. El tipo de entidad débil creado se considera que es débil por identificación
con respecto al tipo d entidad con el que mantiene relación, heredando, por
tanto, sus atributos identificadores. Si el atributo múltiple estaba definido
sobre un tipo de interrelación, heredará los identificadores de los tipos de
entidad que participaban en este tipo de interrelación.
2. Se añadirá un nuevo atributo (externo, o no, al dominio del problema) que
permite identificar sin ambigüedad a las entidades de este tipo de entidad
débil.
En el siguiente diagrama se muestra el tipo de entidad LIBRO, en el cual
existe un atributo múltiple, el atributo autor, representando que un libro puede ser
escrito por más de un autor. Por aplicación de la regla PRTECAR-1, el atributo autor
se ha convertido en un tipo de entidad débil por existencia, con respecto al tipo de
entidad LIBRO, denominado AUTOR. El tipo de entidad AUTOR tiene como único
atributo autor, el cual pertenecía al tipo de entidad LIBRO antes de la aplicación de
esta regla.

Eliminación de atributos compuestos
El segundo proceso de preparación de los esquemas conceptuales para su
transformación en esquemas lógicos relacionales consiste en la descomposición de
todos los atributos compuestos en atributos simples, por aplicación de la siguiente
regla:
PRTECAR-2: Todos los atributos compuestos asociados con los tipos de
entidad y los tipos de interrelación deben ser descompuestos en los atributos

LIBRO
isbn
edición
editorial
páginas
fecha
autor #
PRTECAR-1
AUTOR
L-A
N:N
(1,n) (1,n)
EX
escribe es_escrito

LIBRO
isbn
edición
editorial
páginas
fecha
autor
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 5 - T(aducc|ór de Escueras Corceplua|es a Re|ac|ora|es Pád|ra ê2 de 20ê
simples que formen parte o intervengan en los atributos compuestos
correspondientes. En este proceso de descomposición, se eliminará el atributo
compuesto, quedando los atributos simples definidos en el mismo dominio, e
interviniendo de la misma forma en el tipo de entidad o interrelación.
En la siguiente figura se muestra un ejemplo de aplicación de esta regla al
tipo de entidad PERSONA. Este tipo de entidad tiene dos atributos (dirección y
nombre-completo, que son compuestos. El atributo dirección está compuesto por
los atributos calle, número, portal, planta, piso, cod-postal, localidad y provincia. El
atributo nombre-completo se define por la agregación de los atributos nombre y
apellidos, el cual a su vez es compuesto por los atributos apellido1 y apellido2.
Después de aplicar esta regla se han eliminado los atributos dirección, nombre-
completo y apellidos.

IkAN$FOkMACIÓN DE LO$ E$QbEMA$ CONCEFIbALE$
A continuación se van a aplicar una serie de reglas para la transformación de
los objetos presentes en los esquemas conceptuales a objetos válidos en los
esquemas lógicos relacionales. Estas reglas permiten la transformación de los
esquemas de uno a otro sin pérdida de información, y por tanto, conservando el
nivel de representación del problema. La aplicación de las reglas dependerá de:
1. El tipo de objeto del esquema conceptual que se debe transformar
2. La cardinalidad de las relaciones que los objetos mantienen con otros
objetos en el esquema conceptual.
Transformación de los tipos de entidad
RTECAR-1:Todos los tipos de entidad presentes en el esquema conceptual
se transformarán en tablas o relaciones en el esquema relacional manteniendo, el
número y tipo de atributos, así como la característica de identificador de estos
atributos.

PERSONA
dirección
calle
número
portal
planta
piso
localidad
provincia
cod-postal
dni
edad
nombre-completo
apellidos
nombre
apellido1
apellido2

PERSONA
localidad
provincia
cod-postal
dni
edad
nombre
apellidos1
apellido2
calle
número
portal
planta
piso
PRTECAR-2
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 5 - T(aducc|ór de Escueras Corceplua|es a Re|ac|ora|es Pád|ra ê3 de 20ê
Por ejemplo, en el tipo de entidad LIBRO de la figura anterior, se obtendría
el siguiente esquema:
LIBRO(isbn, edición, editorial, páginas, fecha)
AUTOR(autor)
Transformación de tipos de interrelación uno a uno
Dependiendo de la forma en que participa cada tipo de entidad en el tipo de
interrelación será necesario aplicar las siguientes reglas:
RTECAR2-1: Si en un tipo de interrelación binaria los dos tipos de entidad
participan de forma completa; es decir, ambos tipos de entidad participan con
cardinalidades mínima y máxima igual a uno, entonces:
Si los dos tipos de entidad tienen el mismo identificador:
1. Los dos tipos de entidad se transforman en una única tabla formada por
la agregación de los atributos de los dos tipos de entidad.
2. La clave de la tabla es el identificador de los tipos de entidad.
Si los tipos de entidad tienen diferente identificador, cada tipo de entidad
se transforma en una tabla y,
1. Cada tabla tendrá como clave principal el identificador de cada uno de
los tipos de entidad de los cuales se deriva.
2. Cada tabla tendrá como clave externa el identificador del otro tipo de
entidad con el cual está relacionado.
Si los dos tipos de entidad tienen la misma clave, pero uno de ellos es un
tipo de entidad débil, entonces se procede de alguna de las dos formas
expuestas anteriormente en función de los requerimientos funcionales.
Se presenta el siguiente ejemplo para el primer caso

El resultado sería:
ARTICULO(Ref, descripción, pvp, precio_costo)
DATOS_VENTAS(Ref, unidades, und_compra, und_venta, total_compra,
total_venta)
DATOS VENTAS
A-E
1:1
(1,1) (1,1)
ID
de_un tiene

ARTICULO
Ref.
descripción
pvp
precio_costo
Ref.
unidades
und_compra
und_venta
total_compra
total_venta
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 5 - T(aducc|ór de Escueras Corceplua|es a Re|ac|ora|es Pád|ra ê1 de 20ê
Aunque también se podría haber obtenido el siguiente esquema:
ARTICULO(Ref, descripción, pvp, precio_costo, unidades, und_compra,
und_venta, total_compra, total_venta)
Para el segundo caso se presenta el siguiente ejemplo:

El resultado sería:
CONDUCTOR(nif, nombre, dirección, matricula)
AUTOBUS(matrícula, asientos, marca, modelo, tipo_combustible, año, nif)
RTECAR2-2: Si un tipo de interrelación binaria alguno de los tipos de
entidad participan de forma parcial, entonces, cada tipo de entidad se transformar
en una tabla por aplicación de la regla RTECAR-1 y se procede de alguna de las dos
formas siguientes:
1. El identificador del tipo de entidad que participa totalmente pasa como
atributo de la tabla correspondiente a la transformación del otro tipo de
entidad. En este caso este atributo podrá tomar valores nulos para
diferentes tuplas de esta tabla, no generándose ninguna tabla para el
tipo de interrelación
2. Se construye una nueva tabla correspondiente al tipo de interrelación
formada por los atributos identificadores de los dos tipos de entidad. Se
considerará como clave de esta tabla al identificador del tipo de entidad
que participa de forma parcial en el tipo de interrelación. Los atributos
de esta tabla mantendrán referencias con las claves de las tablas
correspondientes a la transformación de los tipos de entidad.
Por ejemplo, consideremos el siguiente esquema conceptual
AUTOBUS C-A
1:1
(1,1) (1,1)
conducido_por conduce
CONDUCTOR
nif.
nombre
dirección
matrícula
asientos
marca
modelo
tipo_combustible
año
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 5 - T(aducc|ór de Escueras Corceplua|es a Re|ac|ora|es Pád|ra ê5 de 20ê

El esquema relacional puede quedar de la siguiente manera si se aplica el
primer caso:
EMPLEADO(nif, nombre, apellidos, ocupación)
MAQUINA(nº_serie, función, marca, modelo, nif)
En el segundo caso habría que construir una tabla para la interrelación:
EMPLEADO(nif, nombre, apellidos, ocupación)
MAQUINA(nº_serie, función, marca, modelo)
EMP-MAQ(nº_serie, nif)
RTECAR2-3: Si en un tipo de interrelación 1:1 ambos tipos de entidad
participan de forma parcial, entonces, por aplicación de la regla RTECAR1 cada uno
de ellos se transforma en una tabla y se procede de alguna de las dos formas
siguientes:
1. Los identificadores de cada uno de los tipos de entidad pasan a formar
parte como atributos de las tablas correspondientes al otro tipo de entidad.
Estos atributos actuarán como claves externas en estas tablas
2. Se construye una nueva tabla correspondiente al tipo de interrelación y
cuyos atributos serán los identificadores de los dos tipos de entidad. La
clave principal de la tabla generada será el identificador de uno de los tipos
de entidad y, necesariamente, se definirá como clave alterna al
identificador del otro tipo de entidad.

El esquema relacional puede quedar de la siguiente manera si se aplica el
primer caso:
MAQUINA E-M
1:1
(0,1) (0,1)
mantenida_por mantiene
EMPLEADO
nif.
nombre
apellidos
nº_serie
función
marca
modelo
última_fecha
MAQUINA E-M
1:1
(1,1) (0,1)
mantenida_por mantiene
EMPLEADO
nif.
nombre
apellidos
nº_serie
función
marca
modelo
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 5 - T(aducc|ór de Escueras Corceplua|es a Re|ac|ora|es Pád|ra êê de 20ê
EMPLEADO(nif, nombre, apellidos, ocupación, nº_serie)
MAQUINA(nº_serie, función, marca, modelo, nif, última_fecha)
En el segundo caso habría que construir una tabla para la interrelación:
EMPLEADO(nif, nombre, apellidos, ocupación)
MAQUINA(nº_serie, función, marca, modelo)
EMP-MAQ(nº_serie, nif, última_fecha)
Transformación de los tipos de interrelación uno a muchos.
En función de las cardinalidades mínimas con las cuales participa cada tipo
de entidad:
RTECAR-3-1: Si en un tipo de interrelación binaria 1:N ambos tipos de
entidad participan de forma total, o el tipo de entidad que interviene con
cardinalidad máxima muchos participa de forma parcial, entonces, cada tipo de
entidad se transforma en una tabla por aplicación de la regla RTECAR-1, y el
identificador del tipo de entidad que participa con cardinalidad máxima uno pasa a
formar parte de la tabla correspondiente al tipo de entidad que participa con
cardinalidad máxima muchos. Este atributo será definido como clave externa de
esta tabla manteniendo una referencia con la tabla correspondiente al tipo de
entidad que participa con cardinalidad máxima uno. Si el tipo de interrelación
tuviera atributos asociados, estos atributos pasan a formar parte de la tabla
correspondiente al tipo de entidad que participa con cardinalidad máxima muchos.
Consideremos el siguiente ejemplo:

El esquema relacional que se deriva es:
EDITORIAL(nombre, director, dirección, localidad)
REVISTA(título, periodo, precio, nombre-editorial, ejemplares)
RTECAR-3-2: Si en un tipo de interrelación binaria 1:N el tipo de entidad
que interviene con cardinalidad máxima uno participa de forma parcial, cada tipo de
entidad se transforma en una tabla por aplicación de la regla RTECAR-1 y se genera
una nueva tabla correspondiente al tipo de interrelación. Esta tabla estará formada
por los identificadores de los tipos de entidad que intervienen en el tipo de
interrelación y por todos los atributos asociados al tipo de interrelación. La clave
EDITORIAL E-M
1:1
({0\1},n) (1,1)
edita es_editada_por
REVISTA
título
periodo
precio
nombre
director
dirección
localidad
ejemplares
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 5 - T(aducc|ór de Escueras Corceplua|es a Re|ac|ora|es Pád|ra êZ de 20ê
principal de esta tabla será el atributo identificador correspondiente al tipo de
entidad que interviene con cardinalidad máxima muchos, y será necesario definir
como claves externas los atributos identificadores correspondientes a los dos tipos
de entidad.
Consideremos el siguiente ejemplo:

El esquema relacional que se deriva es:
FACTURA(número_factura, fecha, total_factura)
ALBARÁN(número_albarán, fecha_venta, total_albarán, medio_envío)
FACT-ALB(número_albarán, número_factura, descuento)
Transformación de tipos de interrelación muchos a muchos
Independientemente de la cardinalidad mínima de los tipos de entidad que
intervienen en el tipo de interrelación, siempre se aplica la siguiente regla:
RTECAR-4: En un tipo de interrelación binaria N:N cada tipo de entidad se
transforma en una tabla por aplicación de la regla RTECAR-1 y se genera una nueva
tabla para representar al tipo de interrelación. Esta tabla estará formada por los
identificadores de los tipos de entidad que intervienen en el tipo de interrelación y
por todos los atributos asociados al tipo de interrelación. La clave principal de esta
tabla será la agregación de los atributos identificadores correspondientes a los tipos
de entidad que intervienen en el tipo de interrelación.

El esquema relacional que se deriva es:
AUTOBUS C-A
N:M
(1,n) (1,n)
conducido_por conduce
CONDUCTOR
nif.
nombre
dirección
matrícula
asientos
marca
modelo
tipo_combustible
año
trayecto
ALBARÁN F-A
1:N
(0,1)
(0,n)
se_factura_en corresponde_a
FACTURA
número_factura
fecha
total
número_albarán
fecha_venta
total_albarán
medio_envío
descuento
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 5 - T(aducc|ór de Escueras Corceplua|es a Re|ac|ora|es Pád|ra ê8 de 20ê
CONDUCTOR(nif, nombre, dirección)
AUTOBÚS(matrícula, asientos, marca, modelo, tipo_combustible,
año)
CON-AUT(nif, matrícula, trayecto)
Transformaciones de tipos de interrelaciones n-arias
En el proceso de transformación de las relaciones en las que intervienen más
de dos tipos de entidad se debe aplicar la misma regla anterior (RTECAR-4), es
decir, cada tipo de entidad se transforma en una tabla y el tipo de interrelación se
transforma en una nueva tabla cuyos atributos son los atributos identificadores de
los tipos de entidad participante en el tipo de interrelación y los atributos asociados
al tipo de interrelación. La clave de esta tabla será la agregación de los atributos
identificadores de los tipos de entidad.
Si en el problema anterior sobre los autobuses y conductores se desean
representar los lugares que son recorridos por cada autobús conducido por cada
conductor y la fecha en que se visita ese lugar, se tiene entonces el siguiente
esquema conceptual:

De aquí se obtiene el siguiente esquema relacional:
CONDUCTOR(nif, nombre, dirección)
AUTOBÚS(matrícula, asientos, marca, modelo, tipo_combustible, año)
LUGAR(ciudad, sitio, provincia)
CON-AUT-LUG(nif, matrícula, ciudad, sitio, fecha)
Es necesario tener en cuenta que la regla RTECAR-4 debe aplicarse cuando
todos los tipos de entidad participan en el tipo de interrelación con cardinalidad
máxima muchos. En caso contrario, es decir, cuando algún tipo de entidad participa
AUTOBUS C-A-L
N:M:P
(1,n) (1,n)
conducido_por conduce
CONDUCTOR
nif.
nombre
dirección
matrícula
asientos
marca
modelo
tipo_combustible
año
fecha
(1,n)
LUGAR
ciudad
provincia
sitio
pasa_por
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 5 - T(aducc|ór de Escueras Corceplua|es a Re|ac|ora|es Pád|ra ê9 de 20ê
en el tipo de interrelación con cardinalidad máxima uno, entonces, como es lógico,
el identificador de este tipo de entidad no pasa a formar parte de la clave de la
tabla que se deriva del tipo de interrelación. Obsérvese que el que un tipo de
entidad participe con cardinalidad máxima uno, es igual que considerar que el tipo
de interrelación está cualificado por el atributo que identifica a este tipo de entidad
y, por tanto, es como un atributo más, como hay que considerar la participación de
este tipo de entidad en el tipo de interrelación.
Transformación de tipos de interrelación reflexivas
Los tipos de interrelación reflexivas, también denominadas recursivas,
representan aquellas relaciones que se establecen entre un mismo tipo de entidad
consigo misma. Es decir, son relaciones binarias en las que únicamente interviene
un tipo de entidad. Para esta clase de interrelaciones pueden presentarse dos
casos:
1. El tipo de entidad participa en uno de sus papeles con cardinalidad máxima
uno, y en el otro papel con cardinalidad máxima muchos, o bien ambos
participan con cardinalidad máxima uno.
2. El tipo de entidad participa, en sus dos papeles, con cardinalidad máxima
muchos.
En el segundo caso, este tipo de interrelación se trata igual que en el caso
de las relaciones binarias muchos a muchos. Es decir, se genera una tabla para el
tipo de entidad y otra tabla para el tipo de interrelación (regla RTECAR-4), siendo
los atributos de esta tabla:
Los atributos asociados al tipo de interrelación.
El identificador del tipo de entidad desempeñando uno de los papeles en el
tipo de interrelación.
El identificador del tipo de entidad desempeñando el otro papel
(desempeña dos papeles) en el tipo de interrelación.
La clave de esta tabla será el identificador del tipo de entidad (por
duplicado). La siguiente figura muestra un ejemplo de este caso:

Aplicando el proceso de transformación a este esquema se tendrá:
OBJETO(id, posición, color)
OBJ-OBJ(id_continente, id_contenido, capa)
O-O
N:M
(1,n)
(1,n)
está _formado
forma_parte_de
OBJETO
id.
posición
color
capa
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 5 - T(aducc|ór de Escueras Corceplua|es a Re|ac|ora|es Pád|ra Z0 de 20ê
Donde id_continente representa al identificador del objeto que contiene a
otros objetos, y id_contenido representa al identificador del objeto contenido que
forma parte de otros objetos.
Si para este mismo ejemplo, se considera que un objeto sólo puede formar
parte de otro objeto de mayor jerarquía (relación uno a muchos), como es el primer
caso que se consideró, entonces se procede de alguna de las dos formas siguientes:
1. Se genera una tabla para el tipo de entidad, y en esta tabla se añade como
clave externa el identificador del tipo de entidad para representar que un
objeto forma parte de un solo objeto. El esquema quedaría de la forma
(cuando la cardinalidad mínima es uno):
OBJETO(id_contenido, posición, color, id_continente, capa)
2. Se genera una tabla para el tipo de entidad y otra para el tipo de
interrelación formada por los atributos asociados al tipo de interrelación, el
identificador del tipo de entidad el cual será la calve de la tabla,
representando al objeto que forma parte de otros objetos, y de nuevo el
identificador del tipo de entidad representando al objeto del cual forman
parte otros objetos de menor categoría. En este caso el esquema relacional
queda de la forma (cuando la cardinalidad mínima es cero o uno):
OBJETO(id, posición, color)
OBJ-OBJ(id_continente, capa, id_contenido)
ELIMINACIÓN DE LA$ kELACIONE$ JEkÁkQbICA$
El modelo relacional no dispone de mecanismos que faciliten la
representación de relaciones jerárquicas y, por tanto, es conveniente y necesario
la eliminación de las relaciones jerárquicas como paso previo al proceso de
transformación de los esquemas conceptuales a relacionales. En el proceso de
eliminación de las relaciones jerárquicas se deberá aplicar alguna de las reglas que
se describirán a continuación y cuya elección va a depender de:
La magnitud de la especialización que los subtipos de entidad tienen con
respecto al supertipo o tipo de entidad más general. La especialización
supone que los subtipos de entidad tienen asociados diferentes atributos
que diferencian a un subtipo de entidad del resto de los subtipos que
mantienen un tipo de interrelación jerárquica con un mismo supertipo de
entidad.
El tipo de especialización que representa el tipo de interrelación jerárquica,
la cual puede ser alguna de las siguientes: total exclusiva, parcial
exclusiva, total inclusiva y parcial inclusiva.
Otros tipos de interrelación que mantengan tanto los subtipos como el
supertipo de entidad.
Criterios de procesamiento y, sobre todo, la forma en la que se va a
acceder a la información que representan tanto el supertipo y subtipos de
entidad como los tipos de interrelación que mantienen.
En la siguiente figura se representa un esquema conceptual que servirá para
presentar un ejemplo de aplicación de cada una de estas reglas. El ejemplo
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 5 - T(aducc|ór de Escueras Corceplua|es a Re|ac|ora|es Pád|ra Z1 de 20ê
representa una serie de cultivos agrícolas sobre los cuales se desea mantener la
información correspondiente al tipo de cultivo, y dependiendo de éste, las ayudas
que reciben de los organismos oficiales o el abastecimiento de agua que necesita.
Además, se representa el consumo de herbicidas de cada uno de los cultivos.

Teniendo en cuenta todos los puntos señalados, en el proceso de eliminación
de los tipos de interrelación jerárquicas se aplicará alguna de las siguientes reglas:
PRTECAR-3. Eliminación del supertipo de entidad: En un tipo de
interrelación jerárquica se desestimará el supertipo de entidad, transfiriendo todos
los atributos del supertipo a cada uno de los subtipos y cada uno de los tipos de
interrelación que mantuviera el supertipo de entidad serán considerados para cada
uno de los subtipos, manteniéndose, por supuesto, los tipos de interrelación en los
que intervengan cada uno de los subtipos de entidad. Si el tipo de interrelación
jerárquica es exclusiva, los subtipos intervendrán de forma parcial (cardinalidad
mínima cero) en los tipos de interrelación transferidos desde el supertipo.
Esta regla sólo puede ser aplicada a tipos de interrelación jerárquicas
totales, puesto que implica la eliminación del supertipo de entidad y, por tanto, del
conjunto de entidades no especializadas en los diferentes subtipos. Además, si el
tipo de interrelación jerárquica es inclusiva no es fácil de representar, a priori, esta
inclusividad en los nuevos tipos de interrelación que se generan con los subtipos
por la transferencia de los tipos de interrelación mantenidos por el supertipo de
entidad. Por o tanto, esta regla sólo es conveniente aplicarla cuando las
interrelaciones jerárquicas son totales y exclusivas.
Una transformación haciendo uso de esta regla introduce algunos
inconvenientes al nuevo esquema conceptual generado:
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 5 - T(aducc|ór de Escueras Corceplua|es a Re|ac|ora|es Pád|ra Z2 de 20ê
1. Como los atributos del supertipo de entidad se trasladan a cada uno de los
subtipos introduce una redundancia de información.
2. Al desaparecer el supertipo de entidad desaparece la relación semántica
existente entre los subtipos, la cual representaba el que todos ellos eran
tipos de entidad de un mismo supertipo.
3. El número de tipos de interrelación aumenta en cuanto que se deben
representar los tipos de interrelación que mantenía el supertipo de entidad
con cada uno de los subtipos.
4. Naturalmente, las operaciones generales de acceso a esta información (a la
información transferida desde el supertipo de entidad) requieren ahora el
manejo de varios tipos de entidad en lugar de sólo uno.
Esta regla sólo deberá aplicarse cuando se minimicen estos inconvenientes;
es decir, cuando el número de atributos transferidos sea pequeño y no existan
muchos tipos de interrelación en los que participe el supertipo de entidad.
El esquema ejemplo quedaría de la siguiente manera:

El esquema relacional que se deriva es:
HERBICIDA(nombre-herbicida, composición, precio)
SECANO(nombre_cultivo, lugar, htras, uso-comercial)
REGADIO(nombre_cultivo, lugar, htras, clase-regadio)
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 5 - T(aducc|ór de Escueras Corceplua|es a Re|ac|ora|es Pád|ra Z3 de 20ê
SUBVENCIONES(ayuda#, organismo, motivo, cantidad, nombre_cultivo,
lugar)
ABASTECIMIENTO(empresa, coste)
REGA_ABAS(nombre_cultivo, lugar, empresa, litros)
HERB_SECA(nombre-herbicida, nombre-cultivo, lugar, cantidad)
HERB_REGA(nombre-herbicida, nombre-cultivo, lugar, cantidad)
Si se analiza este esquema relacional detenidamente se puede observar lo
siguiente:
Las tablas SECANO y REGADIO tienen la misma clave, y por tanto, no
existe ningún condicionante que impida que un mismo cultivo pueda
aparecer como tuplas en ambas tablas, algo que va en contra de las
restricciones del problema en las que se indicaba que un cultivo es o bien
de secano o bien de regadío, pero no de los dos tipos al mismo tiempo. Así,
este control deberá ser llevado externamente por los usuarios y los
correspondientes programas de aplicación que manejen estas tablas.
Las tablas HERB_REGA y HERB_SECA son idénticas, por lo que se está
manteniendo dos tablas iguales. En principio, estas dos tablas se podrían
agrupar en una sola, de la forma:
HERB_CULT(nombre-herbicida, nombre-cultivo, lugar,
cantidad)
representando ahora la exclusividad que existe entre los tipos de
cultivos y su relación entre los herbicidas que son utilizados para su
tratamiento.
Ahora bien, en esta tabla se presenta el problema del control de la
integridad, puesto que sería necesario definir la clave de esta tabla como
clave externa de las tablas SECANO y REGADIO, y esto sería incorrecto. Para
poder considerar esta tabla sería también necesario unificar las tablas
SECANO y REGADIO en una única tabla que agrupara todos los atributos de
ambas tablas y esto sería también incorrecto por los diferentes tipos de
interrelación en que participan los tipos de entidad que han dado lugar a estas
tablas.
En ningún caso se puede aplicar para tipos de interrelación jerárquicas
parciales, pues al eliminarse el supertipo se eliminaría la representación de
las entidades que no pertenecen a ningún subtipo.
PRTECAR-4. Eliminación de los subtipos de entidad: En un tipo de
interrelación jerárquica se desestimarán los subtipos de entidad, transfiriéndose
todos los atributos de los subtipos al supertipo y cada uno de los tipos de
interrelación que mantuvieran los subtipos de entidad serán considerados para el
supertipo, manteniéndose, por supuesto, los tipos de interrelación en los que
intervenga el supertipo de entidad.
Si el tipo de interrelación jerárquica es exclusiva, el supertipo de entidad
participará de forma parcial (cardinalidad mínima cero) en aquellos tipos de
interrelación transferidos desde los subtipos de entidad. En caso contrario
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 5 - T(aducc|ór de Escueras Corceplua|es a Re|ac|ora|es Pád|ra Z1 de 20ê
(inclusiva) participará con las cardinalidades que participaba cada subtipo de
entidad en los tipos de interrelación transferidos por aplicación de esta regla.
El uso de esta regla va a dar lugar a un esquema mucho más simple pero en
el que se van a presentar muchos posibles valores nulos para aquellos atributos
transferidos desde los subtipos al supertipo de entidad. Así, el número de instancias
o entidades del supertipo va a ser elevado (todas las instancias o entidades de cada
uno de los subtipos) el número de valores nulos será muy elevado. Además, en los
procesos de acceso a la información se va a transferir, en muchos casos,
información no requerida por el interrogante, debido a que en el supertipo de
entidad se está manteniendo información particular de cada subtipo y en muchos
interrogantes sólo será necesaria información general o bien referente a alguno de
los subtipos.
En principio esta regla puede aplicarse a cualquiera de los cuatro tipos de
interrelaciones jerárquica, aunque no en todos los casos. El esquema conceptual del
ejemplo, entonces, quedaría así:

El esquema relacional que se deriva es:
HERBICIDA(nombre-herbicida, composición, precio)
CULTIVO(nombre_cultivo, lugar, tipo, htras, uso-comercial, clase-regadio)
SUBVENCIONES(ayuda#, organismo, motivo, cantidad, nombre_cultivo,
lugar)
ABASTECIMIENTO(empresa, coste)
ABAS_CULT(nombre_cultivo, lugar, empresa, litros)
HERB_CULT(nombre-herbicida, nombre-cultivo, lugar,
cantidad)
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 5 - T(aducc|ór de Escueras Corceplua|es a Re|ac|ora|es Pád|ra Z5 de 20ê
Si se analiza este esquema relacional detenidamente se puede observar lo
siguiente:
En la tabla SUBVENCIONES existe una clave externa (la pareja nombre-
cultivo, lugar) que representa que una subvención es asignada a un único
cultivo, pero es difícil restringir que ese cultivo debe ser un cultivo de
secano (sólo mediante programación y no en la representación del
esquema).
Para poder representar un tipo de interrelación jerárquica inclusiva, debe
considerarse que el atributo tipo forma parte de la clave de la tabla
CULTIVO, y además, se deberán modificar las tablas en las que se haga
referencia a la clave de la tabla CULTIVO.
PRTECAR-5. Eliminación de la jerarquía: El tipo de interrelación jerárquica
se transformará en tantos tipos de interrelación uno a uno como subtipos de
entidad estén presentes, manteniéndose los tipos de interrelación en los que
intervienen tanto los subtipos, como el supertipo de entidad. En los tipos de
interrelación generados por la transformación, los subtipos de entidad participarán:
1. Si el tipo de interrelación jerárquica es exclusiva, participarán con
cardinalidad mínima cero.
2. Si el tipo de interrelación jerárquica es inclusiva, participarán con
cardinalidad mínima cero o uno.
En estos tipos de interrelación el supertipo participa con cardinalidades
mínima y máxima igual a uno, pudiendo considerarse que los subtipos de entidad
actúan como tipos de entidad débiles por identificación con respecto al supertipo de
entidad si se traspasa a los subtipos el identificador del supertipo, y débiles por
existencia en caso contrario.
Esta regla es la más general de aplicación para la transformación de las
relaciones jerárquicas, pues tiene la ventaja de que el esquema resultante preserva
la representación de las relaciones existentes entre el supertipo y los subtipos de
entidad a través de los nuevos tipos de interrelación débiles creados, pudiendo ser
aplicada para cualquier tipo de interrelación jerárquica de los cuatro tipos posibles
Finalmente, el esquema de la figura quedaría así:
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 5 - T(aducc|ór de Escueras Corceplua|es a Re|ac|ora|es Pád|ra Zê de 20ê

El esquema relacional que se deriva es:
HERBICIDA(nombre-herbicida, composición, precio)
CULTIVO(nombre_cultivo, lugar, htras, tipo)
SECANO(nombre_cultivo, lugar, htras, uso-comercial)
REGADIO(nombre_cultivo, lugar, htras, clase-regadio)
SUBVENCIONES(ayuda#, organismo, motivo, cantidad, nombre_cultivo,
lugar)
ABASTECIMIENTO(empresa, coste)
ABAS_ REGA(nombre_cultivo, lugar, empresa, litros)
HERB_CULT(nombre-herbicida, nombre-cultivo, lugar, cantidad)
Si se analiza este esquema relacional detenidamente se puede observar lo
siguiente:
Se sigue representando la semántica de la relación jerárquica, y
dependiendo de si el atributo tipo es clave o no de la tabla CULTIVO se
pueden representar tipos de interrelación jerárquicas exclusivas e
inclusivas.
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 5 - T(aducc|ór de Escueras Corceplua|es a Re|ac|ora|es Pád|ra ZZ de 20ê
La tabla subvenciones mantendrá una referencia con la clave de la tabla
SECANO, por lo que ahora sí es fácil controlar que una subvención sólo se
adjudica a un cultivo de secano. Igual razonamiento se puede hacer con la
tabla ABAS_REGA.

lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera ê - 0|rár|ca de| Vode|o Re|ac|ora|. A|deo(a Re|ac|ora| Pád|ra Z8 de 20ê
ô
0|nám|ca de| Hode|o Re|ac|ona|.
A|gebra Re|ac|ona|
El modelo relacional, como todo modelo de datos, lleva asociado a su parte
estática(estructura y restricciones) una dinámica que permite la transformación
entre estados de la base de datos. Esta transformación de un estado origen a un
estado objetivo se realiza aplicando un conjunto de operadores, mediante los
cuales se llevan a cabo las siguientes operaciones:
Inserción de tuplas.
Borrado de tuplas.
Modificación de tuplas.
Consulta
Si O es un operador, el paso de un estado origen de la base de datos (Bdi) a
un estado objetivo (BDj) se puede expresar:
O(BDi) = BDj
Tanto el estado origen como el estado objetivo deben satisfacer las
restricciones de integridad estática, y la transformación ha de cumplir las
restricciones de integridad dinámica (entre estados).
La dinámica del modelo relacional actúa sobre conjuntos de tuplas y se
expresa (, mediante lenguajes de manipulación relacionales que asocian una
sintaxis concreta a las operaciones. Los lenguajes relacionales, por tanto, operan
también sobre conjuntos de tuplas, es decir, no son lenguajes de navegación sino
de especificación, y se dividen en dos tipos:
Algebraicos: se caracterizan porque los cambios de estado se especifican
mediante operaciones, cuyos operandos son relaciones y cuyo resultado es
otra relación. Genéricamente se conocen como álgebra relacional.
Predicativos: donde los cambios de estado se especifican mediante
predicados que definen el estado objetivo sin indicar las operaciones que hay que
realizar para llegar al mismo. Genéricamente se conocen como calculo relacional
y se dividen en dos tipos:
orientados a tuplas
orientados a dominios
ÁLGE8kA kELACIONAL
La dinámica del modelo relacional, en lo que al álgebra se refiere, la
constituye una colección de operadores de alto nivel que, aplicados a las
relaciones, dan como resultado nuevas relaciones. Sean R y R´ dos relaciones y O
un operador cualquiera del álgebra relacional. Una operación del álgebra
relacional consiste en aplicar O a la relación R, obteniéndose R´. Al ser el
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera ê - 0|rár|ca de| Vode|o Re|ac|ora|. A|deo(a Re|ac|ora| Pád|ra Z9 de 20ê
resultado de la operación otra relación, se cumple la propiedad de cierre,
es decir, si O1 ...... O
n
representan operadores, se cumple:
On ( ... (O1( R ) ) ) = R´
Los operandos del álgebra son siempre relaciones y los operadores se
aplican, por tanto, a relaciones a fin de formular consultas a la base de datos.
CODD (1972), y posteriormente otros autores, han demostrado que la potencia
expresiva del conjunto de operadores del álgebra relacional es la misma que la del
calculo relacional, el cual esta basado en la l6gica de predicados de primer
orden.
Los operadores que defini6 originariamente CODD, cuando propuso el
modelo relacional -CODD (1970)-, fueron completados en algunos trabajos
posteriores -como CODD (1972), LACROIX (1976), DATE (1986), etc.-. Codd
definió ocho operadores para el álgebra relacional, divididos en dos grupos de
cuatro:
Los operadores tradicionales de conjuntos: unión, intersección, diferencia
y producto cartesiano.
Los operadores relacionales especiales: restricción, proyección,
combinación y división.
Aparte de esta clasificación, los operadores se pueden dividir también en
operadores primitivos y operadores derivados:
Los operadores primitivos son los operadores esenciales que no
pueden obtenerse de otros (sin ellos, el álgebra relacional no seria un
lenguaje completo).
Los operadores derivados se pueden obtener aplicando varios de los
operadores primitivos. Podríamos prescindir de ellos, ya que no aportan
nada nuevo; sin embargo, son muy titiles y simplifican muchas
operaciones habituales.
Otra posible clasificación, atendiendo al número de operandos de cada
operador, los divide en:
Unarios, si el operador tiene una única relación como operando.
Binarios, si el operador tiene dos relaciones como operandos.
Es posible definir, y así se ha hecho como veremos posteriormente,
mas operadores aparte de los ocho originales, siempre que tengan una o dos
relaciones como operandos y una relación como resultado.
Aunque no vamos a introducir una gramática BNF para el álgebra
relacional (como, por ejemplo, DATE (1993)), utilizaremos una notación uniforme
en la definición de los operadores; en todos ellos explicaremos primero el
concepto para, a continuación, presentar la definición formal.
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera ê - 0|rár|ca de| Vode|o Re|ac|ora|. A|deo(a Re|ac|ora| Pád|ra 80 de 20ê
Operadores primitivos
UNARIOS
Los operadores unarios tienen como operando una única relación; para su
definición, utilizaremos la siguiente notación:
Sea R (A) un esquema de relación cuyo contexto es el conjunto de atributos
A definidos sobre el conjunto de dominios D:
R (A) = R ( A1 : D1, A2: D2, ..., An : Dn )

la relación r®, definida sobre el esquema R, de grado n y cardinalidad m
estará constituida por un conjunto de m tuplas:
r® = { ti )
n
1=1
donde
t
i
= < V
i1
, V
i2
V
in
> / V
ij
∈ D
j

Los operadores unarios son la restricción y la proyección.
Restricción (σ)
La restricción, también llamada selección, de una relación mediante una
expresión lógica (predicado de selección), da como resultado una relación formada
por el subconjunto de tuplas que satisface dicha expresión. La relación
resultante constituye un subconjunto horizontal de r ®. A continuación aparece la
relación resultante de aplicar el operador de restricción sobre el atributo
nacionalidad a la tabla AUTOR.
AUTOR
Nombre Nacionalidad Institución
Date, C.J. Norteamericana Relational Institute
Saltor, F. Española U.P.C.
Ceri, S Italiana Politécnico de Milán
Ramos, I. Española UPV
σ σσ σ
nacionalidad = "española"
(AUTOR)
Nombre Nacionalidad Institución
Saltor, F. Española U.P.C.
Ramos, I. Española UPV
Formalmente: Sea θ un operador de comparación (>, <, =, t>, >, #) y p
un predicado de selección, formado por una expresión lógica integrada por
cláusulas de la forma:
A
i
θ A
j
o A
i
θ constante
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera ê - 0|rár|ca de| Vode|o Re|ac|ora|. A|deo(a Re|ac|ora| Pád|ra 81 de 20ê
unidas por los operadores booleanos "Y¨ (AND), "0¨ (OR), "NO¨ (NOT).
El operador de selección (aplicado a la relación R con el predicado p se
denota:
σ
p
®
y produce una relación, cuyo esquema será el mismo (es decir, R) y cuya
extensión r´ será:
r´ ® = { t
i
∈ r ® / p(t
i
) = "cierto¨ }
el grado de la relación resultante será por tanto n, es decir, el mismo que
el de la relación R y su cardinalidad m´⇔ m.
La aplicación consecutiva del operador de selección a una relación:
σ
pn

pn-1 .....
σ
p1
®)
es igual a una única operación de restricción con todos los predicados p
1
, p
2

p
n
unidos por el operador booleano "Y¨
σ
p1

y p2 ... pn

Proyección (π)
La proyección de una relación sobre un subconjunto de sus atributos es una
relación definida sobre ellos, eliminando las tuplas duplicadas que hubieran
podido resultar; es, por tanto, un subconjunto vertical de la relación a la que se
aplica el operador.
π
nacionalidad
(AUTOR)
Nacionalidad
Norteamericana
Española
Italiana
Formalmente: Sea X un subconjunto estricto y no vacío de A:
X ⊂ A y X ≠ φ
la aplicación del operador de proyección π a R en el contexto de X, que se
denota por:
πx ®
será una relación r´ cuyo esquema es R´ (X) y cuya extensión es el
conjunto de tuplas de la relación original definidas sobre los atributos X,
eliminando las que resulten duplicadas, es decir,
r´(R´) = {t
i
(X) / X ⊂ A}
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera ê - 0|rár|ca de| Vode|o Re|ac|ora|. A|deo(a Re|ac|ora| Pád|ra 82 de 20ê
El grado n´ y la cardinalidad m´ de la relación resultante cumplen: n´ < n y
m´ < m, siendo n y m respectivamente, el grado y la cardinalidad de la relación
original.
Cuando entre los atributos X de la relación R sobre los que se hace la
proyección se encuentra una clave candidata de R, nunca se podrán producir
tuplas duplicadas; pero en el caso contrario, es decir, cuando entre los atributos
sobre los que se proyecta no se encuentra ninguna clave candidata, es muy
probable que se produzcan tuplas duplicadas que habrán de ser eliminadas
por el sistema (recuérdese que en una relación, por su misma definición, no
pueden existir tuplas iguales). Algunos autores obligan a que entre los atributos
sobre los que se proyecta se encuentre una clave primaria.
BINARIOS
Los operadores binarios se aplican a dos relaciones, y algunos de ellos
(unión, diferencia e intersección) exigen que las dos relaciones involucradas Sean
compatibles en sus esquemas. Se dice que dos esquemas de relación R1 (A1
i
:
D1
i
) y R2 (A2
i
: D2
i
), con cardinalidades m
1
y m
2
, son compatibles a efectos de
dichos operadores, cuando ambos están definidos sobre el mismo conjunto de
dominios, cumpliéndose:
∀ A1
i
∃ A2j /dom (A1
i
)= dom (A2
j
) ^ ∀ A2
j
∃ A1
i
/ dom (A2
j
) = dom (A1
i
)
es decir, R1 y R2 serán semánticamente equivalentes, lo que no quiere
decir que los nombres de los atributos sean los mismos (esto seria solo un
aspecto sintáctico, además de poco relevante muy restrictivo), sino que han de
estar definidos sobre los mismos dominios (aspecto semántico muy importante).
Observación: Se puede deducir de esta definición de compatibilidad otra
razón mas de la importancia de los dominios desde un punto de vista semántico.
Si los nombres de los atributos de las dos relaciones son distintos o
están en distinto orden, es decir, no hay correspondencia uno a uno entre los
nombres de los atributos de los esquemas R1 y R2, será precisa una operación de
renombrado de los atributos del esquema de la relación resultante.
Supongamos, por ejemplo, que tenemos las dos relaciones de la figura, que
son compatibles en sus esquemas al estar sus atributos definidos sobre los mismos
dominios; sin embargo, los nombres de los atributos no coinciden. Se puede
proceder a la siguiente operación de renombrado de EDITOR 1:
EDITOR (Nombre, Nacionalidad, Institución) EDITOR1
AUTOR
Nombre Nacionalidad Institución
Date, C.J. Norteamericana Relational Inst.
Saltor, F. Española U.P.C.
Ceri, S. Italiana Politec. Milán
EDITOR1
Nombre Nacionalidad Organización
Chen, P. Norteamericana ER Institute
Yao, L. Norteamericana U.N.Y.
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera ê - 0|rár|ca de| Vode|o Re|ac|ora|. A|deo(a Re|ac|ora| Pád|ra 83 de 20ê
Ceri, S. Italiana Politec. Milan
Union (U)
La unión de dos relaciones r
1
y r
2
con esquemas compatibles R1 y R2 es otra
relación definida sobre el mismo esquema de relación y cuya extensión estará
constituida por el conjunto de tuplas que pertenezcan a r
1
o a r
2
(se eliminaran
las tuplas duplicadas puesto que se trata de un conjunto).
A continuación se muestra un ejemplo de unión:
AUTOR EDITOR
Nombre Nacionalidad Institución Nombre Nacionalidad Institución
Date, C.F. Norteamericana Relational
Institute
Chen, P. Norteamericana ER Institute
Saltor, F. Española U.P.C. Yao, L Norteamericana U.N.Y.
Ceri, S. Italiana Politécnico
de Milán
Ceri, S. Italiana Politécnico de
Milán
AUTOR U EDITOR
Nombre Nacionalidad Institución
Date, C.F. Norteamericana Relational Institute
Saltor, F. Española U.P.C.
Ceri, S. Italiana Politécnico de Milán
Chen, P. Norteamericana ER Institute
Yao, L Norteamericana U.N.Y.

Formalmente: Sean dos relaciones r1 y r2 con esquemas R1 y R2
compatibles, la unión de ambas, denotada por:
R1 U R2
será una relación con esquema R (R es igual a R1 o a R2 ya que ambos son
equivalentes) y con extensión r:
r® = { t
i
/ t
i
∈ r
1
∨ t
i
∈ r
2
}
Diferencia ( - )
La diferencia de dos relaciones r1 y r2 con esquemas compatibles R1 y R2
es otra relación definida sobre el mismo esquema de relación y cuya
extensión estará constituida por el conjunto de tuplas que pertenezcan a r1
pero no a r2.
A continuación se muestra un ejemplo de diferencia entre las relaciones
AUTOR y EDITOR.
AUTOR EDITOR
Nombre Nacionalidad Institución Nombre Nacionalidad Institución
Date, C.F. Norteamericana Relational Institute Chen, P. Norteamericana ER Institute
Saltor, F. Española U.P.C. Yao, L Norteamericana U.N.Y.
Ceri, S. Italiana Politécnico de Milán Ceri, S. Italiana Politécnico de Milán

lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera ê - 0|rár|ca de| Vode|o Re|ac|ora|. A|deo(a Re|ac|ora| Pád|ra 81 de 20ê
AUTOR - EDITOR
Nombre Nacionalidad Institución
Date, C.F. Norteamericana Relational Institute
Saltor, F. Española U.P.C.
Formalmente: Sean dos relaciones compatibles, con esquemas R1 y R2, la
diferencia de ambas denotada por:
R1 - R2
será una relación con esquema R (R es igual a R1 o a R2 ya que ambos son
equivalentes) y con extensión r
r® = { t
i
/ t
i
∈ r
1
∧ t
i
∉ r
2
}
Producto cartesiano generalizado (x)
El producto cartesiano generalizado de dos relaciones de cardinalidades m
1
y
m
2
es una relación definida sobre la unión de los atributos de ambas relaciones y
cuya extensión estará constituida por las m
1
x m
2
tuplas formadas concatenando cada
tupla de la primera relación con cada una de las tuplas de la segunda
(obsérvese que aquí no se exige que las dos relaciones sean compatibles en sus
esquemas).
A continuación aparece un ejemplo de producto cartesiano generalizado
entre las relaciones SOCIO y LIBRO.
SOCIO LIBRO
Código Nombre Dirección Libro Autor Editorial
1 Elena Manrique Villovela, 25 DB System Date, C.J. Addison
2 Manuel García P.Vergara, 56 Basi di Dati Ceri, S. Clup
SQL Standard Date, C.J. Addison
SOCIO x LIBRO
Código Nombre Dirección Libro Autor Editorial
1 Elena Manrique Villovela, 25 DB System Date, C.J. Addison
1 Elena Manrique Villovela, 25 Basi di Dati Ceri, S. Clup
1 Elena Manrique Villovela, 25 SQL Standard Date, C.J. Addison
2 Manuel García P.Vergara, 56 DB System Date, C.J. Addison
2 Manuel García P.Vergara, 56 Basi di Dati Ceri, S. Clup
2 Manuel García P.Vergara, 56 SQL Standard Date, C.J. Addison
Formalmente: Sean las relaciones r
1
y r
2
con esquemas R1 y R2 el producto
de ambas denotado por R1 x R2 será una relación de grado n
1
+ n
2
cuyo esquema
R estará formado por los n
1
+ n
2
atributos: A1 U A2.
Operadores Derivados
Los operadores derivados se pueden expresar siempre en función de los
operadores primitivos, pero su introducción se hace a fin de simplificar las
consultas.
Formalmente: Sean las relaciones r
1
y r
2
con esquemas R1 y R2 el producto
de ambas denotado por R1 x R2 será una relación de grado n
1
+ n
2
cuyo esquema
R estará formado por los n
1
+ n
2
atributos: A1 U A2.
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera ê - 0|rár|ca de| Vode|o Re|ac|ora|. A|deo(a Re|ac|ora| Pád|ra 85 de 20ê
Operadores Derivados
Los operadores derivados se pueden expresar siempre en función de los
operadores primitivos, pero su introducción se hace a fin de simplificar las
consultas.
Combinación
La combinación, denotada por , de dos relaciones respecto a una cierta
condición de combinación, es otra relación constituida por todos los pares de tuplas
t
i
y t
j
concatenadas, tales que, en cada par, las correspondientes tuplas
satisfacen la condición especificada. La forma general de expresar la
combinación de dos relaciones
R1(A1
1
, A1
2
, ..., A1
nl
) y R2(A2
1
, A2
2
, ..., A2
n2
) es R1 R2
Condición
La condición de combinación, en el caso mas sencillo, esta referida a dos
atributos A1
i
y A2
j
, cada uno de los cuales pertenece a una de las dos relaciones
unidos por un operador de comparación θ.
A1
i
θ A2
j

En el caso mas general, un par de atributos puede ir unido a otro par de
atributos mediante el operador booleano "Y¨:
A1
i1
θ A2
j1
Y A1
i2
θ A2
j2
....
Para facilitar la notación, sin perder por ello generalidad, podemos suponer
que la condición de combinación se refiere a un par de columnas (k y l)

y la
expresamos: k θ l
Formalmente: La θ combinación de las dos relaciones de esquemas R1 (A1)
y R2 (A2) respecto de sus columnas k y l, denotada:
R
1
R
2
k θ 1
es otra relación de grado n
1
+ n
2
cuyo esquema R estará formado por los n
1

+ n
2
atributos:
Al U A2
y cuya extensión r® será de cardinalidad <= m
1
x m
2
.
La llamada combinación natural (denotada por *) es una combinación por
igualdad donde se ha eliminado, en la relación resultante, uno de los dos atributos
cuyos valores son idénticos. Es el caso más utilizado de combinación para
relaciones que tienen un atributo común. A continuación se muestra un ejemplo:
AUTOR LIBRO
Nombre Nacionalidad Institución Libro Autor Editorial
Date, C.J. Norteamericana Relational Inst. DB System Date, C.J. Addison
Saltor, F. Española U.P.C. Basi di Dati Ceri, S. Clup
Ceri, S. Italiana Politécnico de Milán SQL Date, C.J. Addison
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera ê - 0|rár|ca de| Vode|o Re|ac|ora|. A|deo(a Re|ac|ora| Pád|ra 8ê de 20ê
Standard
AUTOR * LIBRO
(AUTOR.nombre = LIBRO.autor)
Nombre Nacionalidad Institución Libro Editorial
Date, C.J. Norteamericana Relational Inst. DB System Addison
Date, C.J. Norteamericana Relational Inst. SQL Standard Addison
Ceri, S. Italiana Politécnico de Milán Basi di Dati Clup
Cuando el atributo común tiene el mismo nombre en ambas relaciones, se
suele omitir la condición de combinación.
Intersección (∩)
La intersección de dos relaciones R1 y R2 compatibles en su esquema es
otra relación definida sobre el mismo esquema de relación y cuya extensión estará
constituida por las tuplas que pertenezcan a ambas relaciones. A continuación se
muestra un ejemplo:
AUTOR EDITOR
Nombre Nacionalidad Institución Nombre Nacionalidad Institución
Date, C.F. Norteamericana Relational Institute Chen, P. Norteamericana ER Institute
Saltor, F. Española U.P.C. Yao, L Norteamericana U.N.Y.
Ceri, S. Italiana Politécnico de Milán Ceri, S. Italiana Politécnico de Milán
AUTOR ∩ ∩∩ ∩ EDITOR
Nombre Nacionalidad Institución
Ceri, S. Italiana Politécnico de Milán
Formalmente : Sean dos relaciones compatibles con esquemas R1 y R2, la
intersección de ambas, denotada por: R1 ∩ R2, será una relación r con esquema R
(igual a R1 o a R2 ya que ambos son equivalentes) y con extensión:
r® = { t
i
/ t
i
∈ r
1
^ t
i
∈ r
2
}
Operadores relacionales con valores nulos
Como señalamos en el capítulo anterior, los valores nulos obligan a definir
operaciones aritméticas, de comparación, algebraicas, etc. adicionales.
El producto cartesiano no se ve afectado por la presencia de valores nulos;
la restricción solo devuelve aquellas tuplas cuya condición se evalúa como cierta,
eliminando aquellas otras en las que el resultado de evaluar la condición es falso o
quizás, y la proyección debe eliminar tuplas duplicadas teniendo en cuenta los
nulos.
Veremos en este apartado, a modo de ejemplo, operadores especiales para
tratar los valores nulos.
Combinación externa
Entre los operadores especiales para el tratamiento de valores nulos,
destaca el de combinación externa (outer join), que impide que desaparezcan
tuplas cuando se aplica la combinación que hemos visto en el epígrafe
anterior, denominada combinación interna, así, por ejemplo, en ejemplo anterior
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera ê - 0|rár|ca de| Vode|o Re|ac|ora|. A|deo(a Re|ac|ora| Pád|ra 8Z de 20ê
visto para la combinación natural se combinan las tablas AUTOR y LIBRO; pero la
tupla <Saltor, Española, U.P.C.> de la relación AUTOR no aparece en la relación
resultante, al no combinarse con ninguna tupla de la relación LIBRO, es decir,
se pierde esta información.
Para evitar que las tuplas de una relación que no casan con ninguna tupla de
la otra desaparezcan en el resultado, podemos aplicar el operador de
combinación externa que concatena esas tuplas con tuplas cuyos atributos
tienen valores nulos, obteniéndose así, para el ejemplo anterior, el resultado
que aparece en la figura siguiente. En este caso basta con aplicar el operador de
combinación externa izquierda (left outer join), ya que se desean guardar todas las
tuplas de la tabla que esta a la izquierda, siendo en la segunda relación donde hay
que crear tuplas nulas (lo hemos representado con /*)
AUTOR LIBRO
Nombre Nacionalidad Institución Libro Autor Editorial
Date, C.J. Norteamericana Relational Inst. DB System Date, C.J. Addison
Saltor, F. Española U.P.C. Basi di Dati Ceri, S. Clup
Ceri, S. Italiana Politécnico de Milán SQL Standard Date, C.J. Addison
AUTOR * LIBRO
(AUTOR.nombre = LIBRO.autor)
Nombre Nacionalidad Institución Libro Editorial
Date, C.J. Norteamericana Relational Inst. DB System Addison
Date, C.J. Norteamericana Relational Inst. SQL Standard Addison
Saltor, F. Española U.P.C.
Ceri, S. Italiana Politécnico de Milán Basi di Dati Clup
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera Z - 30L Pád|ra 88 de 20ê
7
80L
LENGbAJE E$IkbCIbkADO DE CON$bLIA$ $QL
SQL es un conjunto de sentencias u órdenes que todos los programas y
usuarios deben utilizar para acceder a bases de datos. No hay otra manera de
comunicarse con una base de datos si no es a través de SQL. Dado que SQL es un
estándar, todas las bases de datos comerciales de la actualidad utilizan SQL como
puente de comunicación entre la base de datos y el usuario.
Historia
SQL nació como a partir de una publicación de 1970 escrita por E.F. Cood, y
titulada "A relational model of data for large shared data banks¨ (El modelo de
datos relacionales para grandes bancos de datos compartidos). IBM utilizó el
modelo planteado por Codd para desarrollar un lenguaje capaz de soportar el
recién nacido modelo relacional y así apareció SEQUEL (Structured English QUEry
Language). SEQUEL más tarde se convirtió en SQL (Structured Query Language)
que continuó pronunciándose en inglés como su predecesor: SEQUEL. En 1979, una
desconocida empresa llamada Relational Software, sacó por sorpresa al mercado la
primera implementación comercial de SQL. Relational Software más tarde pasó a
llamarse Oracle.
Después de 20 años, SQL todavía es (y será) siendo el estándar en
lenguajes de acceso a base de datos relacionales. En 1992, ANSI e ISO
(organizaciones que se encargan de establecer estándares de todo tipo),
completaron la estandarización de SQL y se definió un conjunto de sentencias
básicas que debía tener toda implementación para ser llamada estándar. Este SQL
se le denominó ANSI-SQL o SQL92. Hoy en día todas las bases de datos
comerciales cumplen el estándar ANSI, aunque cada fabricante añade sus mejoras
al lenguaje SQL.
SQL como lenguaje estructurado
En realidad SQL no es un lenguaje en si, como podría ser un lenguaje de
programación de 3ª generación (C, Pascal.), sino que en un sublenguaje orientado
a acceso y manipulación de base de datos relacionales. Con SQL como única
herramienta sólo podemos acceder a las bases de datos, pero no tenemos las
estructuras típicas de un lenguaje de programación.
Una buena analogía podría ser un sistema operativo. El interfaz de
comandos de un SO nos da todo lo que necesitamos para acceder al sistema de
ficheros, pero sólo podemos hacer eso, acceder a ficheros. SQL actúa de la misma
manera, nos da todo lo que necesitamos para acceder a bases de datos, pero no
podemos hacer más. Se dice que SQL es estructurado porque trabaja con conjuntos
de resultados (result set) abstractos como unidades completas. Un conjunto de
resultados es el esquema básico de una tabla: N filas x N columnas. Este esquema
se trata como un todo y es la idea principal de SQL.
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera Z - 30L Pád|ra 89 de 20ê
A la hora de recuperar un conjunto de resultados, éste se trata de la misma
forma tenga el número de filas que tenga (0-N) y tenga el número de columnas
que tenga (1-N). Además SQL es consistente, esto significa que los "estilos¨ de las
distintas sentencias son uniformes, por lo que el aprendizaje es rápido.
IIFO$ DE DAIO$ (OkACLE)
Los tipos de datos soportados por Oracle se agrupan en los siguientes
conjuntos.
Los valores alfanuméricos van encerrados entre comilla simple:
`Alfanumérico´
Los valores numéricos son número simples: 123
Las fechas van encerradas entre comillas simples: `d/mm/aaaa´
Los valores binarios no pueden ser representados (son fotos, videos.)
Cuando se crea una tabla se debe especificar el tipo de dato para cada una
de sus columnas. Estos tipos de datos definen un dominio de valores que cada
columna puede contener o cada argumento puede tener. La tabla siguiente muestra
las distintas categorías de tipos de datos de Oracle SQL
Clase Tipo Significado Rango
VARCHAR2(n)
Variable carácter de longitud máxima en
bytes la especificada en n. El máximo tamaño
es 4.000 bytes y el mínimo es 1. Se debe
especificar n.
1 b a 4000 b
NVARCHAR2(n)
Variable carácter de longitud máxima en
caracteres o bytes la especificada en n,
dependiendo de la elección de un conjunto de
caracteres nacionales. El máximo tamaño
está especificado por el número de
caracteres y bytes requerido para almacenar
cada carácter con un límite superior de 4.000
bytes. Se debe especificar n.
1 b a 4000 b
LONG
Carácter de longitud variable hasta 2 Gb
1 b a 2 Gb
CHAR(n)
Dato carácter de longitud fija en bytes,
especificada en n. El máximo tamaño es
2.000 bytes. El mínimo tamaño y por defecto
es 1.
1 b a 2000 b
NCHAR(n)
Dato carácter de longitud fija en caracteres o
bytes la especificada en n, dependiendo de si
se elige un conjunto de caracteres
nacionales. El máximo tamaño está
determinado por el número de bytes
requeridos para almacenar cada carácter con
un límite superior de 2.000 bytes. El mínimo
tamaño y por defecto es 1 carácter o 1 byte,
dependiendo del conjunto de caracteres.
1 b a 2000 b
CLOB
Un objeto carácter largo conteniendo
caracteres simples en bytes. Conjuntos de
caracteres de ancho fijo y ancho variables
son permisibles, ambos usando el conjunto
de caracteres de bases de datos CHAR. El
tamaño máximo es 4 Gb.
1 b a 4 Gb
Cadena
NCLOB
Un objeto carácter largo conteniendo
caracteres múltiples en bytes. Conjunto de
caracteres de ancho fijo y ancho variables
son permisibles, ambos usando el conjunto
1 b a 4 Gb
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera Z - 30L Pád|ra 90 de 20ê
de caracteres de base de datos NCHAR. El
tamaño máximo es 4 Gb. Almacena
conjuntos de datos de caracteres nacionales.
Numérico NUMBER(p,s)
Número con precisión p y escala s (número
de dígitos a la derecha del punto decimal). El
rango de p está entre 1 y 38. La escala s
puede variar desde -84 a 127

DATE
Fecha con rango válido desde January 1,
4712 BC hasta December 31, 9999 AD.

TIMESTAMP(fps)
Año, mes, día, minuto y segundo. Valores de
fecha y de hora, fsp es el número de dígitos
en la parte fraccionaria del campo fecha-hora
SECOND.

INTERVAL
YEAR(p) TO
MONTH
Periodo de tiempo en años y meses con
precisión p (puede variar de 0 a 9 y por
defecto es 2).

Fecha/Hora
INERVAL
DAY(p) TO
MONTH
Periodo de tiempo en días, horas, minutos y
segundos con precisión p (puede variar de 0
a 9 y por defecto es 2).

RAW(n)
Datos binarios brutos de longitud en bytes la
especificada en n. El tamaño máximo es
2.000 bytes.
1 b a 2000 b
LONG RAW
Datos binarios brutos de longitud en bytes
hasta 2 Gb.
1 b a 2 Gb.
BLOB
Un objeto binario largo. El tamaño máximo
es 4 Gb.
1 b a 4 Gb.
Binario
BFILE
Contiene un localizador de un fichero binario
largo almacenado fuera de la base de datos.
Posibilita byte stream I/O access externos
resiendo en la base de datos servidora. El
tamaño máximo es 4 Gb.
1 b a 4 Gb.
ROWID
Cadena hexadecimal representando la única
dirección de una fila en su tabla
Fila
UROWID[(n)]
Cadena hexadecimal representando la
dirección lógica de una fila en una tabla
organizada con índices. El tamaño máximo
por defecto (n) es 4.000 bytes.

Las instrucciones SQL en Oracle para crear tablas, pueden utilizar tipos de
datos ANSI-SQL. Oracle reconoce estos tipos de datos y los registra basándose en
las reglas de conversión especificadas en la tabla siguiente:
Tipo de dato ANSI-SQL Tipo de dato Oracle
CHARACTER(n)
CHAR(n)
CHAR(n)
CHARACTER VARYING(n)
CHAR VARYING(n)
VARCHAR(n)
NATIONAL CHARACTER(n)
NATIONAL CHAR(n)
NCHAR(n)
NCHAR(n)
NATIONAL CHARACTER VARYING(n)
NATIONAL CHAR VARYING(n)
NCHAR VARYING(n)
NVARCHAR2(n)
NUMERIC(p,s)
DECIMAL(p,s)
NUMBER(p,s)
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera Z - 30L Pád|ra 91 de 20ê
INTEGER
INT
SMALLINT
NUBER(38)
FLOAT(b)
DOUBLE PRECISION
REAL
NUMBER
IIFO$ DE DAIO$ (MY$QL)
Los tipos de datos soportados por MySQL se agrupan en los siguientes
conjuntos.
Los valores alfanuméricos van encerrados entre comilla simple:
`Alfanumérico´
Los valores numéricos son número simples: 123
Las fechas van encerradas entre comillas simples: "aaaa-mm-dd¨
Los valores binarios no pueden ser representados (son fotos, videos.)
A continuación se presenta una tabla con los tipos de datos admitidos en
SQL para MySQL. Para cada tipo se presenta su clase, significado, longitud, rango y
valor predeterminado. El parámetro m indica la máxima anchura de visualización
(suele estar entre 1 y 255), el parámetro p indica el número de dígitos que siguen
al punto decimal en tipos con parte fraccionaria y los corchetes indican información
opcional.
Clase Tipo Significado Rango
Valor
predet.
Numérico TINYINT[(m)] Entero muy pequeño -128 a 127 NULL o 0
SMALLINT[(m)] Entero pequeño -32768 a 32767 NULL o 0
MEDIUMINT[(m)] Entero medio -8388608 a 8388607 NULL o 0

INT[(m)] o
INTEGER[(m)]
Entero normal
-2147483648 a
2147483647
NULL o 0
BIGINT[(m)] Entero grande -2
63
a 2
63
- 1 NULL o 0
FLOAT[(m,d)]
Número en punto flotante
con precisión simple
[±1,1754943E-38,
±3,40282346E-38]
NULL o 0

DOUBLE[(m,d)] o
REAL[(m,d)]
Número grande en coma
flotante y doble precisión
[±2,225073E-308,
±1,7976931E-308]
NULL o 0

DECIMAL[(m,d)] o
NUMERIC[(m,d)]
Número en coma flotante
almacenado como cadena
[±2,225073E-308,
±1,7976931E-308]
NULL o 0
Cadena CHAR(m) Cadena de longitud fija 1 a 255 NULL o 0
VARCHAR(m)
Cadena de longitud
variable
0 a 255 NULL o 0
TINYBLOB Pequeño valor BLOB 0 a 255 NULL o 0
BLOB Valor BLOB normal 0 a 65535 NULL o 0
MEDIUMBLOB Valor BLOB medio 0 a 2
24
-1 NULL o 0
LONGBLOB Valor BLOB grande 0 a 2
32
-1 NULL o 0
TINYTEXT Pequeño valor TEXT 0 a 255 NULL o 0
TEXT Valor TEXT normal 0 a 65535 NULL o 0
MEDIUMTEXT Valor TEXT medio 0 a 2
24
-1 NULL o 0
LONGTEXT Valor TEXT grande 0 a 2
32
-1 NULL o 0
Fecha y
Hora
DATE
Fecha en formato AAAA-
MM-DD
1000-01-01 a 999-12-
31
NULL o
0000-00-00
TIME
Hora en formato
hh:mm:ss
-838:59:59 a
838:59:59

DATETIME
Fecha y hora en formato
AAAAMMDDhh:mm:ss
1000-01-01 00:00:00
a 9999-12-31
23:59:59
NULL o
0000-00-00
00:00:00
TIMESTAMP[(m)]
Fecha y hora en formato
AAAAMMDDhh:mm:ss
19700101000000 a
hora del año 2037
NULL
YEAR Año en formato AAAA 1900 a 2155 NULL o 0000
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera Z - 30L Pád|ra 92 de 20ê
OFEkADOkE$ $QL
Ya hemos visto anteriormente qué tipos de datos se pueden utilizar en
Oracle y MySQL. Y siempre que haya datos, habrá operaciones entre ellos, así que
ahora se describirán qué operaciones y con qué operadores se realizan.
Los operadores se pueden dividir en dos conjuntos:
Aritméticos: utilizan valores numéricos
Lógicos (o booleanos o de comparación): utilizan valores booleanos o
lógicos.
Concatenación: para unir cadenas de caracteres.
Operadores aritméticos
Retornan un valor numérico
Operador Significado Ejemplo
+ Operación suma 1 + 2
- Operación resta 1 - 2
* Operación multiplicación 1 * 2
/ Operador división 1 / 2
Operadores lógicos
Retornan un valor lógico (verdadero o falso)
Símbolo Significado Ejemplo
= Igualdad 1 = 2
!= <> ^= Desigualdad 1 != 2 1 <> 2 1 ^= 2
> Mayor que 1 > 2
< Menor que 1 < 2
>= Mayor o igual que 1 >= 2
<= Menor o igual que 1 <= 2
IN (RS) Igual a algún elemento del
result set.
1 IN (1,2) [TRUE]
<op.> ANY <op.> SOME
(sólo Oracle)
<op> a algún elemento
del result set (derecha).
Debe ser estar precedido
por =, !=, <, <=, >, >=
Hace un OR lógico entre
todos los elementos.
10 >= ANY (1,2,3,10)
[TRUE]
<op.> ALL <op> a todos los
elementos del result set
(derecha), Debe ser estar
precedido por =, !=, <,
<=, >, >= Hace un AND
lógico entre todos los
elementos.
10 <= ALL (1,2,3,10)
[TRUE]
BEETWEEN x AND y Operando de la izquierda
entre x e y. Equivalente a
op >= x AND op <= y
10 BETWEEN 1 AND 100
EXISTS <subconsulta>
(sólo Oracle)
Si la <subconsulta>
retorna al menos una fila
EXISTS( SELECT 1 FROM
DUAL)
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera Z - 30L Pád|ra 93 de 20ê
LIKE Es como `pepe´ LIKE `pe%´
IS NULL Si es nulo 1IS NULL
IS NOT NULL Si es No nulo 1 IS NOT NULL
NOT cond. Niega la condición
posterior
NOT EXISTS. NOT
BETWEEN NOT IN NOT =
Cond AND cond Hace un AND lógico entre
dos condiciones
1=1 AND 2 IS NULL
Cond OR cond Hace un OR lógico entre
dos condiciones
1=1 OR 2 IS NULL
El operador LIKE sirve para hacer igualdades con comodines, al estilo * y ?
de MS-DOS. Existen los siguientes comodines:
%: Conjunto de N caracteres (de 0 a ∞). En MySQL también funciona *
_: Un solo carácter
Ejemplo:
Las siguientes condiciones retornan TRUE
`significado LIKE `s_gn%fi%d_´
`pepe´ LIKE `pep%´ (todos los que empiecen por `pep´)
`pepote´ LIKE `pep%´
`pepote´ LIKE `pe%te´ (todos los que empiecen por `pe´ y terminen por `te´)
`pedrote´ LIKE `pe%te´
Operador de concatenación
Retornan una cadena de caracteres (sólo Oracle).
Símbolo Significado Ejemplo
|| Concatena una cadena a otra `juan´ || `cito´ [´Juancito´]
Oracle puede hacer una conversión automática cuando se utilice este
operador con valores numéricos:
10 || 20 = `1020´
Este proceso de denomina CASTING y se puede aplicar en todos aquellos
casos en que se utiliza valores numéricos en puesto de valores alfanuméricos o
incluso viceversa.
La ausencia de valor: NULL
Todo valor (sea del tipo que sea) puede contener el valor NULL que no es
más que la ausencia de valor. Así que cualquier columna (NUMBER, VARCHAR2,
DATE.) puede estar a NULL. Una operación retorna NULL si cualquiera de los
operandos es NULL. Para comprobar si una valor es NULL se utiliza el operador IS
NULL o IS NOT NULL.
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera Z - 30L Pád|ra 91 de 20ê
CON$bLIA$ $IMFLE$
El DML (Data Manipulation Language) es el conjunto de sentencias que está
orientadas a la consulta, y manejo de datos de los objetos creados. El DML es un
subconjunto muy pequeño dentro de SQL, pero es el más importante, ya que su
conocimiento y manejo con soltura es imprescindible. Básicamente consta de
cuatro sentencias: SELECT, INSERT, DELETE, UPDATE.
Para los ejemplos que van a ilustrar el uso de las diferentes sentencias
vamos a las siguientes tablas:
Tabla Factura
#Numero Dni Importe Fecha Dto.
A111 1 50 15/12/2003 0
A112 3 125 17/12/2003 0
A113 5 200 17/12/2003 0
A114 5 75 18/12/2003 1
A115 1 100 19/12/2003 2
A116 7 140 20/12/2003 1,5
A117 3 125 21/12/2003 0
A118 2 150 21/12/2003 3
A119 9 200 22/12/2003 0

Tabla Cliente
#Dni Nombre Apellidos Dirección Población CP
1 José Gómez López c/ Mayor, 1 Córdoba 14002
2 Juan Martínez Salazar Av. Pi, 10 Jaén 23003
3 Javier Alonso Nieto Pz. Moreal, 12 Sevilla 41002
5 Antonio Caracol Bueno c/ Farruco, 8 Cádiz 11004
7 Armando Bronca Segura Av. Juan XXIII, 2 Huelva 21004
9 Maria De la O Pz. Mosquito, 1 Granada 18007
La sentencia SELECT
La sentencia SELECT es la encargada de la recuperación (selección) de
datos, con cualquier tipo de condición, agrupación u ordenación. Una sentencia
SELECT retorna un result set (conjunto de resultados), por lo que podrá ser
aplicada en cualquier lugar donde se espere un result set.
La sintaxis básica es:
SELECT ítems de selección
FROM tablas
WHERE condición
GROUP BY agrupación
HAVING condición agrupada
ORDER BY ordenación;
Todas las cláusulas son opcionales excepto SELECT y FROM. A continuación
vamos a hacer una descripción breve de cada cláusula:
SELECT: se deben indicar los ítems de selección que se desean mostrar en
el resultado. Los distintos ítems de selección deben aparecer separados por coma
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera Z - 30L Pád|ra 95 de 20ê
(",¨). Cada ítem de selección genera una única columna de resultados e consulta,
en orden de izquierda a derecha. Un ítem de selección puede ser:
• Un nombre de columna, identificando una columna de la tabla
designada en la cláusula FROM. Cuando un nombre de columna
aparece como ítem de selección, SQL simplemente toma el valor de
esa columna de cada fila de la tabla de base de datos y lo coloca en
la fila correspondiente de los resultados de la consulta.
Opcionalmente puede ser cualificada con el nombre de su tabla
utilizando la sintaxis: TABLA.COLUMNA
• Una constante, especificando que el mismo valor constante va a
aparecer en todas las filas de los resultados de la consulta.
• Una expresión SQL, indicando que SQL debe calcular el valor a
colocar en los resultados. La expresión podrá estar compuesta de
constantes, nombres de columnas, funciones SQL.
FROM: seguida por los especificadores de tabla separados por comas. Cada
especificador de tabla identifica una tabla que contiene datos a recuperar por la
consulta. Estas tablas se denominan tablas fuente de la consulta, ya que
constituyen la fuente de todos los datos que aparecen en los resultados. Las tablas
deben existir y si no existiera alguna aparecería un error.
El resultado de una consulta SQL es siempre una tabla de datos, semejante
a las tablas de la base de datos. Si se escribe una sentencia SELECT utilizando SQL
interactivo, el gestor de la base de datos visualizará los resultados de la consulta
en forma tabular sobre la pantalla del computador. Si un programa envía una
consulta al gestor de la base de datos utilizando SQL programado, la tabla de
resultados de la consulta se devuelve al programa. En cualquier caso, los
resultados tienen siempre el mismo formato tabular de fila/columna que las tablas
efectivas de la bases de datos. Generalmente los resultados de la consulta
formarán una tabla con varias columnas y varias filas.
Consultas sencillas
Las consultas SQL más sencillas solicitan columnas de datos de una única
tabla en la base de datos. Por ejemplo
SELECT dni, nombre, dirección
FROM Cliente
Columnas calculadas
Como se indicó anteriormente, además de las columnas cuyos valores
provienen directamente de la base de datos, una consulta SQL puede incluir
columnas calculadas cuyos valores se calculan a partir de los valores de los datos
almacenados, constantes y/o funciones SQL. Para solicitar una columna calculada,
se especifica una expresión SQL en la lista de selección. Para construir las
expresiones SQL se pueden utilizar los operadores vistos anteriormente y funciones
que se verán posteriormente. Por ejemplo
SELECT numero, importe, importe – (importe * dto)
FROM Factura;
Recuperará el número de factura, su importe y el resultado de restar al
importe la aplicación del descuento. En el resultado, la tercera columna se calcula a
partir de los valores de datos de cada fila.
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera Z - 30L Pád|ra 9ê de 20ê
Por ejemplo, la siguiente consulta:
SELECT numero, MONTH(fecha), YEAR(fecha)
FROM Factura;
recuperaría para cada factura su número, el número del mes de su fecha y
el año.
Selección de todas las columnas (Select *)
A veces es conveniente visualizar el contenido de todas las columnas de una
tabla. SQL permite utilizar un asterisco (*) en lugar de la lista de selección como
abreviatura de todas las columnas. El resultado contendrá todas las columnas en el
mismo orden en que están definidas en la tabla. Por ejemplo, la consulta
SELECT * FROM Cliente;
recuperaría como resultado todas las columnas de la tabla cliente. También
si se desea el asterisco puede cualificarse con el nombre de la tabla.
SELECT Cliente.* FROM Cliente;
Además del asterisco, que recuperaría todas las columnas de la tabla, puede
añadirse más ítems de selección. Por ejemplo:
SELECT *, dni FROM Cliente;
recuperaría todas las columnas de la tabla cliente y la columna dni de la
misma tabla.
Filas duplicadas
Si una consulta incluye una clave primaria de una tabla en su lista de
selección, entonces cada fila de resultados será única. Si no se incluye la clave
primaria en los resultados pueden producirse filas duplicadas. Por ejemplo
SELECT dni FROM Factura;
Puede retornar
1
3
5
5
1
7
3
2
9
Aparecen filas duplicadas ya que un cliente tiene varias facturas. Se pueden
eliminar las filas duplicadas de los resultados de la consulta insertando la palabra
clave DISTINCT en la sentencia SELECT justo antes de la lista de selección. Así
SELECT DISTINCT dni FROM Factura;
Retornará (suprimiendo las repeticiones)
1
3
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera Z - 30L Pád|ra 9Z de 20ê
5
7
2
9
Si se utiliza la cláusula DISTINCT retorna filas únicas, es decir, no habrá dos
filas con los mismos valores en todos sus campos. Por ejemplo, si a la sentencia
anterior le añadimos la columna importe.
SELECT DISTINCT dni, importe FROM Factura;
El resultado será:
1 50
3 125
5 200
5 75
1 100
7 140
3 125
2 150
9 200
Como se puede observar, no hay dos filas iguales. También se puede
especificar la palabra clave ALL para indicar explícitamente que las filas duplicadas
se muestren, pero es innecesario ya que éste es el comportamiento por defecto.
Selección de fila. Cláusula WHERE
Generalmente se deseará seleccionar parte de las filas de una tabla, y sólo
se incluirán esas filas en los resultados. La cláusula WHERE se emplea para
especificar qué condiciones deben cumplirse para que una fila entre dentro del
resultado retornado. Para construir las condiciones se podrán utilizar todos los
operadores lógicos vistos anteriormente. Es posible construir condiciones complejas
uniendo dos o más condiciones simples a través de los operadores lógicos AND y
OR.
Por ejemplo, listar todos las facturas cuyo importe supere 100 C.
SELECT * FROM Factura
WHERE importe > 100;
Si una fila tiene una columna con valor NULL y esa columna forma parte de
una expresión condicional en la cláusula WHERE, el resultado siempre será falso y
esa fila no aparecerá en el conjunto de resultados.
SQL ofrece un amplio conjunto de condiciones de búsqueda que permiten
especificar muchos tipos diferentes de consultas, empleándolas en la cláusula
WHERE. A continuación se exponen las más básicas.
Test de comparación (=, <>, <, <=, >, >=)
La condición de búsqueda más común utilizada en una consulta SQL es el
test de comparación. En un test de comparación, SQL calcula y compara los valores
de dos expresiones SL por cada fila de datos. Las expresiones pueden ser tan
simples como un nombre de columna o una constante, o pueden ser expresiones
aritméticas complejas. Las comparaciones se harán con los operadores de
comparación típicos. Por ejemplo
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera Z - 30L Pád|ra 98 de 20ê
SELECT numero, dni
FROM Factura
WHERE importe > 100;
recuperará el número y el dni de las facturas con un importe superior a 100
C. Por otro lado si ejecutamos
SELECT *
FROM Factura
WHERE dto = 0 OR importe < 200;
recuperará las facturas cuyo descuento es 0 o su importe es inferior a 200.
Otro ejemplo, usando una función y una columna calculada.
SELECT numero, importe – (importe * dto), fecha,
MONTHNAME(fecha)
FROM Factura
WHERE importe – (importe * dto) < 150 AND MONTH(fecha) = 3;
Este último ejemplo, recupera el número, calcula el importe neto, la fecha y
el número del mes de la fecha de las facturas cuyo importe neto es inferior a 150 y
el mes de la fecha es 3. Como se puede observar, no es necesario que las
columnas que intervienen en los test de comparación aparezcan en la lista de
selección.
Test de rango: BETWEEN
SQL proporciona una forma diferente de condición de búsqueda con el test
de rango. Este comprueba si un valor de dato se encuentra entre dos valores
especificados. Implica el uso de tres expresiones SQL. La primera expresión define
el valor a comprobar, las expresiones segunda y tercera definen los extremos
superior e inferior del rango a comprobar. Los tipos de datos de las tres
expresiones deben ser comparables. Por ejemplo
SELECT numero, dni, importe, fecha
FROM Factura
WHERE fecha BETWEEN ‘01/01/2004’ AND ‘31/01/2004’;
La consulta anterior lista las facturas cuya fecha está entre el 1 de enero del
2004 y el 31 de enero del 2004, es decir, que la factura sea del mes de enero del
2004. La sentencia anterior sería similar a:
SELECT numero, dni, importe, fecha
FROM Factura
WHERE fecha >= ‘01/01/2004’ AND fecha <= ‘31/01/2004’;
Para que se devuelva una fila en el conjunto de resultados, es necesario que
la primera expresión antes del BETWEEN sea mayor igual que la expresión que
define el extremo inferior del rango y menor o igual que la expresión que define el
extremo superior del rango.
Test de pertenencia a conjunto (IN)
Otra condición habitual es el test de pertenencia a conjunto (IN). Examina si
un valor de dato coincide con uno de una lista de valores objetivo. Por ejemplo
SELECT * FROM Factura
WHERE dto IN (0, 1, 2);
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera Z - 30L Pád|ra 99 de 20ê
La sentencia anterior lista todas las facturas cuyo descuento es 0, 1 o 2.
Sería equivalente a
SELECT * FROM Factura
WHERE dto = 0 OR dto = 1 OR dto = 2;
También se puede comprobar que un valor de dato no coincida con ninguno
de la lista de valores objetivo anteponiendo la palabra clave NOT. Por ejemplo
SELECT * FROM Factura
WHERE dni NOT IN( 2, 3, 5 );
El ejemplo anterior visualizaría todas las facturas cuyos dni no son 2, 3 o
5.
Test de correspondencia con patrón. LIKE
Anteriormente se han visto algunos ejemplos del operador LIKE. Ahora lo
veremos en una sentencia SELECT. Se puede utilizar un test de comparación simple
para recuperar las filas en donde el contenido de una columna de texto se
corresponde parcialmente con un cierto texto particular. Para ello se construye un
patrón que es una cadena con uno o más caracteres comodín. Por ejemplo
SELECT * FROM Cliente
WHERE nombre LIKE ‘J%’;
devolvería todos los clientes cuyo nombre comienza por `J´, sin importar el
resto del nombre. En la siguiente sentencia
SELECT * FROM Cliente
WHERE poblacion LIKE ‘S%a’;
devolvería todos los clientes cuya población empieza por `S´ y acaba en `a´.
En una sección anterior se explican con detalle los dos caracteres comodín que
existen.
También, si lo que se desea es que la expresión de texto no se ajuste al
patrón, se puede anteponer la palabra NOT a LIKE. Por ejemplo
SELECT * FROM Cliente
WHERE nombre NOT LIKE ‘PE%’;
Listaría todos los clientes cuyo nombre no comiencen por `PE´.
Test de valor nulo (IS NULL)
A veces es útil comprobar explícitamente los valores NULL en una condición
de búsqueda y manejarlos directamente. SQL proporciona un test especial de valor
nulo. Esta consulta muestra todas las facturas cuyo descuento es nulo.
SELECT * FROM Factura
WHERE dto IS NULL;
La forma negada del test de valor nulo (IS NOT NULL) encuentra las filas qu
no contienen un valor NULL. Por ejemplo
SELECT * FROM Cliente
WHERE direccion IS NOT NULL;
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera Z - 30L Pád|ra 100 de 20ê
Ordenación de los resultados de una consulta. Cláusula ORDER BY
Al igual que las filas de una tabla en la base de datos las filas de los
resultados de una consulta no están dispuestas en ningún orden particular. Se
puede pedir a SQL que ordene los resultados de una consulta incluyendo la cláusula
ORDER BY en la sentencia SELECT. La cláusula ORDER BY seguida por una lista de
especificadores de ordenación separadas por comas. Por ejemplo
SELECT * FROM Cliente
ORDER BY apellidos, nombre;
Lista los clientes ordenados alfabéticamente por apellidos y nombre. La
primera especificación de ordenación (apellidos) es la clave de ordenación mayor,
las que le sigan (nombre) son progresivamente claves de ordenación menores,
utilizadas para desempatar cuando dos filas de resultados tienen los mismos
valores para las claves mayores. Utilizando la cláusula ORDER BY se puede solicitar
la ordenación en secuencia ascendente o descendente y se puede ordenar con
respecto a cualquier elemento, incluso si no aparece en la lista de selección.
Dentro de esta cláusula podrá aparecer cualquier expresión que pueda
aparecer en el SELECT, es decir, pueden aparecer columnas, constantes (no tiene
sentido, aunque está permitido), expresiones y funciones SQL. Como característica
adicional, se pueden incluir números en la ordenación, que serán sustituidos por la
columna correspondiente del SELECT en el orden que indique el número.
Después de cada columna de ordenación se puede incluir una de las
palabras reservadas ASC o DESC, para hacer ordenaciones ASCendentes o
DESCendentes. Por defecto, si no se pone nada se hará ASC. Por ejemplo
SELECT * FROM Factura
ORDER BY numero DESC, dni DESC, importe ASC
Lista las facturas ordenadas por número descendetemente, dni
descendentemente e importe ascendentemente.
SELECT * FROM Factura
ORDER BY 1, dni, 4;
Lista las facturas ordenadas por numero (columna 1 del resultado), el dni y
por fecha (columna 4 de la lista de resultados).
Si la columna de resultados de la columna utilizada para ordenación es una
columna calculada, no tiene nombre de columna que se pueda emplear en una
especificación de ordenación. En este caso, debe especificarse un número de
columna en lugar de un nombre, como en este ejemplo.
SELECT numero, fecha, importe – (importe * dto)
ORDER BY 3;
CON$bLIA$ $bMAkIA$
Una consulta agrupada se utiliza para considerar los registros cuyos ciertos
campos tienen el mismo valor, y procesarlos de la misma manera, para contarlos,
sumarlos, hacer la media. Las consultas típicas son para contar los registros de
cierto tipos, sumar los importes de cierto cliente, etc.
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera Z - 30L Pád|ra 101 de 20ê
Una función de columna SQL acepta una columna entera de datos como
argumento y produce un único dato que sumariza la columna. Por ejemplo, la
función AVG() acepta una columna de datos y calcula su promedio. he aquí una
consulta que utiliza la función de columna AVG() para calcular el valor promedio de
dos columnas de la tabla Factura.
SELECT AVG(importe), AVG(dto)
FROM Factura;
La primera función toma valores de la columna importe y calcula su
promedio. La segunda promedia los valores de la columna dto. La consulta produce
una única fila de resultados que sumarizan los datos de la tabla Factura. También
los valores de entrada puede ser una expresión
SELECT AVG(importe – importe * dto)
FROM Factura;
Las funciones de grupo que pueden usarse son:
Función Descripción
SUM( valores ) Retorna la suma.
AVG( valores ) Retorna la media aritmética
MAX( valores ) Retorna el máximo.
MIN( valores ) Retorna el mínimo
COUNT(valores|* ) Retorna la cuenta.
Todas estas funciones permite incluir el modificador DISTINCT delante de la
lista de valores para que omita los repetidos.
Cálculo del total de una columna (SUM)
La función SUM() calcula la suma de una columna de valores de datos. Los
datos de la columna deben ser de tipo numérico. El resultado es del mismo tipo que
el dato básico de los valores de la columna, pero el resultado puede tener una
precisión superior. Por ejemplo, vamos a sacar el total del importe de las facturas.
SELECT SUM(importe)
FROM Factura
Esto nos sumara todos los importes de la tabla factura y los ofrecerá en una
única fila.
Cálculo del promedio de una columna (AVG)
La función AVG() calcula el promedio de una columna de valores de datos.
Al igual que la función SUM(), los datos deben tener tipo numérico. Ya que la
función AVG() suma los valores de la columna y luego los divide por el número de
valores, su resultado puede tener un tipo de dato diferente al de los valores de la
columna.
Determinación de valores extremos
Las funciones de columna MIN() y MAX() determinan los valores mayor y
menor de una columna, respectivamente. Los datos de la columna pueden ser de
tipo numérico, cadena o fecha/hora. El resultado de la función tiene el mismo tipo
de dato que los datos de la columna. Por ejemplo, para listar la fecha más antigua
de las facturas.
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera Z - 30L Pád|ra 102 de 20ê
SELECT MIN(fecha) FROM Factura;
Para obtener el cliente con el número de código postal más alto.
SELECT MAX(cp) FROM Cliente;
Para obtener el importe máximo y el mínimo en todas las facturas.
SELECT MAX(importe), MIN(importe)
FROM Factura;
Cuenta de valores de datos (COUNT)
La función de columnas COUNT() cuenta el número de valores de datos que
hay en una columna. Los datos de la columna pueden ser de cualquier tipo. La
función COUNT() devuelve siempre un entero, independientemente del tipo de
datos de la columna. Por ejemplo
SELECT COUNT(dni)
FROM Cliente;
Dará como resultado 6, ya que hay 6 clientes en la tabla Cliente.
SELECT COUNT(importe)
FROM Factura
WHERE importe > 100;
El resultado será 6, ya que la tabla Factura hay 6 facturas con importe
superior a 100 C. Observe que la función COUNT() ignora los valores de los datos
en la columna, simplemente cuenta cuántos datos hay. En consecuencia no importa
realmente qué columna se especifica como argumento de la función COUNT(). El
último ejemplo podría haberse escrito igualmente así
SELECT COUNT(nfactura)
FROM Factura
WHERE importe > 100;
De hecho, es extraño pensar en la consulta como "contar cuántos importes
de factura¨ o "contar cuántos números de factura; es mucho más fácil imaginar que
se pide "contar cuántas facturas¨. Por esta razón, SQL soporta una función de
columna especial COUNT(*) QUE CUENTA FILAS EN LUGAR DE VALORES DE
DATOS. He aquí la misma consulta, reescrita una vez más para utilizar la función
COUNT(*).
SELECT COUNT(*)
FROM Factura
WHERE importe > 100;
Hay que pensar en la función COUNT() como una función que cuenta filas,
en lugar de valores, aunque a veces es necesario que cuente valores.
Valores NULL y funciones de columna
La funciones de columna SUM(), AVG(), MIN(), MAX() y COUNT() aceptan
cada una de ellas una columna de valores de datos como argumento y producen un
único valor como resultado. ¿Qué sucede si uno o más de los valorse de la columna
toma un valor NULL? El estándar SQL ANSI/ISO especifica que los valores NULL de
la columna sean ignorados por las funciones de columna, es decir, cuando haya que
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera Z - 30L Pád|ra 103 de 20ê
sumar, calcular la media, el mínimo, máximo o contar valores de columna, aquellas
que tengan valor NULL no entrarán en el resultado.
Eliminación de filas duplicadas (DISTINCT)
Recordemos que se puede especificar la palabra clave DISTINCT al comienzo
de la lista de selección para eliminar filas duplicadas de los resultados de la
consulta. También se puede pedir a SQL que elimine valores duplicados de una
columna antes de aplicarle una función de columna. Para eliminar valores
duplicados, la palabra clave DISTINCT se incluye delante del argumento de la
función de columna. Por ejemplo
SELECT COUNT( DISTINCT dni )
FROM Factura;
devolverá el valor 6, ya que hay seis clientes no repetidos en la tabla
Factura. El estándar permite usar DISTINCT en las funciones SUM() y AVG(), pero
no en MIN() y MAX(), ya que no tiene impacto sobre los resultados. En COUNT() se
puede utilizar siempre que se especifique una columna como argumento, no es
posible utilizarla en COUNT(*) ya que esta forma de la función cuenta las filas.
Además, la palabra clave DISTINCT sólo puede ser especificaa una vez en
una consulta. Si aparece en el argumento de una función de columna, no puede
aparecer en ninguna otra.
CON$bLIA$ AGkbFADA$
Las consultas sumarias descritas hasta ahora son como los totales al final de
un informe. Condensan todos los datos detallados del informe en una única fila
sumaria de datos. Al igual que los subtotales son útiles en informes impresos, con
frecuencia es conveniente sumarizar los resultados de la consulta a un nivel
"subtotal¨. La cláusula GROUP BY de la sentencia SELECT proporciona esta
capacidad. Por ejemplo
SELECT dni, SUM(importe)
FROM Factura
GROUP BY dni;
Esto nos sumará los importes de aquellos registros que tenga el mismo valor
de dni. Cuando en la cláusula SELECT no se incluyen funciones de grupo una
consulta GROUP BY es equivalente a una consulta SELECT DISTINCT.
SQL lo que ha hecho es lo siguiente:
1. SQL divide las facturas en grupos de facturas, un grupo por dni.
Dentro de cada grupo, todas las facturas tienen el mismo valor en la
columna dni.
2. Por cada grupo, SQL calcula el valor medio de la columna IMPORTE
para todas las filas del grupo, y genera una única fila sumario de
resultados. La fila contiene el valor de la columna dni y el total de los
importes.
El resultado ha sido como sigue:
dni sum(importe)
--- ------------
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera Z - 30L Pád|ra 101 de 20ê
1 150
2 150
3 250
5 275
7 140
9 200
Una consulta que incluya la cláusula GROUP BY se denomina consulta
agrupada, ya que agrupa los datos de las tablas fuente y produce una única fila
sumaria por cada grupo de filas. Las columnas indicadas en la cláusula GROUP BY
se denominan columnas de agrupación de la consulta, ya que ellas osn las que
determinan cómo se dividen las filas en grupo.
Ejemplos de consultas agrupadas:
SELECT fecha, COUNT(*)
FROM Factura
GROUP BY fecha;

SELECT dni, AVG( importe )
FROM Factura
GROUP BY dni;

SELECT dni, MIN( importe )
FROM Factura
GROUP BY dni;

SELECT dni, fecha, MAX( importe )
FROM Factura
WHERE fecha > ‘15/12/2003’
GROUP BY dni, fecha;
Hay una relación íntima entre las funciones de columna SQL y la cláusula
GROUP BY. Cuando la cláusula GROUP BY está presente, informa a SQL que debe
dividir los resultaos detallados en grupos y aplicar la función de columna
separadamente a cada grupo, produciendo un único resultado por cada grupo. Es
posible agrupar los resultados de la consulta en base a contenidos de dos o más
columnas, tal y como aparece en el último ejemplo. La consulta proporciona una
fila sumaria por cada combinación diferente de dni y fecha.
Las consultas agrupadas están sujetas a algunas limitaciones bastante
estrictas. Las columnas de agrupación deben ser columnas efectivas de las tablas
designadas en la cláusula FROM de la consulta. No se pueden agrupar las filas
basándose en el valor de una expresión calculada.
También hay restricciones sobre los elementos que pueden aparecer en la
lista de selección de una consulta agrupada. Todos los elementos de la lista de
selección deben tener un único valor por cada grupo de filas. Básicamente, esto
significa que un elemento de selección en una consulta agrupada puede ser:
• Una constante.
• Una función de columna, que produce un único valor sumarizando las
filas del grupo.
• Una columna de agrupación, que por definición tiene el mismo valor
en todas las filas del grupo.
• Una expresión que afecte a combinaciones de los anteriores.
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera Z - 30L Pád|ra 105 de 20ê
En la práctica, una consulta agrupada incluirá siempre una columna de
agrupación y una función de columna en su lista de selección. Si no aparece una
función de columna, la consulta puede expresarse más sencillamente utilizando
SELECT DISTINCT, sin GROUP BY.
Un valor NULL presenta un problema especial cuando aparece en una
columna de agrupación. Si el valor de la columna es desconocido, (en que grupo
debería colocarse la fila? En la cláusula WHERE, cuando se comparan dos valores
NULL diferentes, el resultado es NULL (no TRUE), es decir, los dos valores NULL no
se consideran iguales. Aplicando el mismo convenio a la cláusula NULL se forzaría a
SQL a colocar cada fila con una columna de agrupación NULL en un grupo aparte.
En lugar de ello, el estándar SQL ANSI/ISO considera que dos valores NULL
son iguales a efectos de la cláusula GROUP BY. Si dos filas tienen NULL en las
mismas columnas de agrupación y valores idénticos en las columnas de agrupación
no NULL, se agrupan dentro del mismo grupo de filas. Sin embargo, este
comportamiento estándar no está aplicado a todos los SGBD.
Condiciones de búsqueda de grupos. Cláusula HAVING
Al igual que la cláusula WHERE puede ser utilizada para seleccionar y
rechazar filas individuales que participan en una consulta, la cláusula HAVING
puede ser utilizada para seleccionar y rechazar grupos de filas. El formato de la
cláusula HAVING es análogo al de la cláusula WHERE, consistiendo en la palabra
clave HAVING seguida de una condición de búsqueda. La cláusula HAVING
especifica por tanto una condición de búsqueda para grupos. Por ejemplo
SELECT dni, AVG(importe)
FROM Factura
GROUP BY dni
HAVING SUM(importe) > 200;
En la consulta anterior, la cláusula HAVING elimina los grupos cuyo importe
total no supera 200 C. Finalmente, la cláusula SELECT calcula el importe medio
para cada uno de los grupos restantes y genera los resultados de la consulta.
Otro ejemplo sería:
SELECT dni, fecha, SUM(importe – importe * dto )
FROM Factura
GROUP BY dni, fecha
HAVING COUNT(*) >= 2;
La consulta anterior calcularía primero los grupos de dni y fecha que
superan las dos filas, y posteriormente para cada uno de esos grupos totaliza el
importe menos el descuento. Otro ejemplo
SELECT dni, MIN(importe)
FROM Factura
GROUP BY dni
HAVING MIN(importe) > 50;
En la consulta anterior, calcula los grupos de dni que tienen importe mínimo
superior a 50. Para todos ellos, genera resultados con el dni e importe mínimo.
La cláusula HAVING se utiliza para incluir o excluir grupos de filas de los
resultados de la consulta, por lo que la condición de búsqueda que especifica debe
ser aplicable al grupo en su totalidad en lugar de a filas individuales. Esto significa
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera Z - 30L Pád|ra 10ê de 20ê
que un elemento que aparezca dentro de la condición de búsqueda en una cláusula
HAVING puede ser:
• Una constante.
• Una función de columna, que produzca un único valor que sumarice
las filas del grupo.
• Una columna de agrupación, que por definición tiene el mismo valor
para todas las filas del grupo.
• Una expresión, que afecte a combinaciones de las anteriores.
En la práctica, la condición de búsqueda de la cláusula HAVING incluirá
siempre al menos una función de columna. Si no lo hiciera, la condición de
búsqueda podría expresarse con la cláusula WHERE y aplicarse a filas individuales.
El modo más fácil de imaginar si una condición de búsqueda pertenece a la cláusula
WHERE o la cláusula HAVING es recordar como se aplican ambas cláusulas:
• La cláusula WHERE se aplica a filas individuales, por lo que las
expresiones que contiene debe ser calculables para filas individuales.
• La cláusula HAVING se aplica a grupos de filas, por lo que las
expresiones que contengan deben ser calculables para un grupo de
filas.
La cláusula HAVING se utiliza casi siempre juntamente con la cláusula
GROUP BY, pero la sintaxis de la sentencia SELECT no lo precisa. Si una cláusula
HAVING aparece sin una cláusula GROUP BY, SQL considera el conjunto entero
de resultados detallados como unúnico grupo. En otras palaras, las funciones de
columna de la cláusula HAVING se aplican a un solo y único grupo para
determinar si el grupo está incluido o excluido de los resultados, y ese grupo
está formado por todas las filas. El uso de una cláusula HAVING sin una cláusula
corresponiente GROUP BY casi nunca se ve en la práctica.
$b8CON$bLIA$
La característica de subconsulta SQL permite utilizar los resultados de una
consulta como parte de otra. Una subconsulta es una consulta que aparece dentro
de la cláusula WHERE o HAVING de otra sentencia SQL. He aquí un ejemplo
Listar el dni, nombre, apellidos y dirección de los clientes
que tienen facturas con importe superior a 100 .
Inicialmente, la sentencia SELECT de la consulta anterior sería la
siguiente:
SELECT dni, nombre, apellidos, direccion
FROM Cliente
WHERE dni = ???;
Como se puede observar, se lista el dni, nombre, apellidos y dirección de los
clientes cuyo dni es igual a algo (???). Ese algo tiene que ser alguno de los dni de
los clientes que tengan facturas con importe superior a 100 C, que se pueden
obtener con la siguiente sentencia:
SELECT DISTINCT dni
FROM Factura
WHERE importe > 100;
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera Z - 30L Pád|ra 10Z de 20ê
Como se puede observar, con esta sentencia se obtendrían todos los dni de
los clientes con facturas cuyo importe fuera superior a 100 C. Este conjunto es al
que tiene que pertenecer el dni de la primera sentencia. Para ello, ambas se
pueden unir de la siguiente manera:
SELECT dni, nombre, apellidos, direccion
FROM Cliente
WHERE dni IN ( SELECT DISTINCT dni
FROM Factura
WHERE importe > 100
);
La subconsulta está encerrada siempre entre paréntesis, pero tiene el
formato similar a una sentencia SELECT, con una cláusula FROM y cláusulas
opcionales WHERE, GROUP BY y HAVING. El formato de estas cláusulas es idéntico
al que tienen en una sentencia SELECT, y efectúan sus funciones normales cuando
se utilizan dentro de una subconsulta. Sin embargo, hay unas cuantas diferencias
entre una subconsulta y una sentencia SELECT real.
• Una subconsulta debe producir una única columna de datos como
resultados. Esto significa que una subconsulta siempre tiene un único
elemento de selección en su cláusula SELECT.
• La cláusula ORDER BY no puede ser especificada en una subconsulta.
Los resultados de la subconsulta se utilizan internamente por parte
de la consulta principal y nunca son visibles al usuario, por lo que
tiene poco sentido ordenarlas de ningún modo.
• Una subconsulta no puede ser la UNION de varias sentencias SELECT
diferentes sólo se permite una única SELECT.
• Los nombres de columna que aparecen en una subconsulta pueden
referirse a columnas de tablas en la consulta principal. Estas
referencias externas se describen a continuación.
Dentro del cuerpo de una subconsulta, con frecuencia es necesario referirse
al valor de una columna en la fila "actual¨ de la consulta principal. Consideremos el
siguiente ejemplo.
Listar el dni de cliente, número de factura, fecha e importe
de las facturas cuyo importe supere el importe medio de las
facturas del cliente.

SELECT dni, numero, fecha, importe
FROM Factura AS F1
WHERE importe > ( SELECT AVG(importe)
FROM Factura AS F2
WHERE F2.dni = F1.dni );
El papel de la subconsulta es obtener el importe medio de las facturas de un
cliente en particular, específicamente, el cliente que está siendo examinado por la
cláusula WHERE de la consulta principal. Sin embargo, se observa que F1.dni de la
cláusula WHERE se refiere al de la fila actual en la consulta principal. Tanto en la
consulta principal como en la subconsulta ha sido necesario utilizar un alias (F1 y
F2) para distinguir cuando un dni pertenece a la fila actual en la consulta principal
(F1.dni) y cuando pertenece a la subconsulta (F2.dni). Esto es debido a que ambos
tienen el mismo nombre, pero si la subconsulta fuera sobre otra tabla diferente a
Factura, no sería necesario, aunque si habría que especializar el nombre de cada
columna con el nombre de tabla, salvo que las columnas con las que se establece la
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera Z - 30L Pád|ra 108 de 20ê
igualdad en la cláusula WHERE de la subconsulta no se llamaran de la misma
manera. Por ejemplo, supongamos las dos tablas siguientes:
Tabla Oficinas
#Oficina Región Ciudad Objetivo
11 Andalucia Córdoba 300000
22 Andalucia Sevilla 575000
33 Andalucia Cádiz 800000
44 Extremadura Badajoz 700000

Tabla Representante
#Dni Nombre Oficina_Rep Cuota Ventas
1 José 11 350000 367911
2 Juan 22 300000 392725
3 Javier 11 350000 474050
5 Antonio 33 275000 299912
7 Armando 22 200000 142594
9 Maria 33 300000 305673

Tabla Pedidos
#Numero Rep Cli Importe Fecha Dto.
A111 2 1 500 15/12/2003 0
A112 5 3 1250 17/12/2003 0
A113 7 5 2000 17/12/2003 0
A114 7 5 750 18/12/2003 1
A115 5 1 1000 19/12/2003 2
A116 5 7 1400 20/12/2003 1,5
A117 2 3 1250 21/12/2003 0
A118 3 2 1500 21/12/2003 3
A119 9 9 2000 22/12/2003 0

Sobre estas tablas se define la siguiente sentencia
Lista de las oficinas donde el objetivo de ventas de la
oficina supera a la suma de las cuotas de los vendedores
individuales

SELECT ciudad
FROM Oficinas
WHERE objetivo > ( SELECT SUM(cuota)
FROM Representante
WHERE oficina_rep = oficina );
Como se puede apreciar, en la subconsulta se calcula la cuota total de los
representantes de una oficina en particular, la que está siendo examinada por la
cláusula WHERE de la consulta principal. La subconsulta lo lleva a cabo explorando
en la tabla Representante. Pero en la cláusula WHERE de la subconsulta se hace
referencia a la columna oficina que no existe en la tabla Representante. Esta
columna es de la tabla Oficinas, que forma parte de la consulta principal. Conforme
SQL recorre cada fila de la tabla Oficinas, utiliza el valor de la columnas oficina de
la fila actual cuando lleva a cabo una subconsulta.
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera Z - 30L Pád|ra 109 de 20ê
Como la clave externa en la tabla Representante, oficina_rep tiene diferente
nombre que la clave primaria de la tabla Oficina, oficina, no es necesario utilizar
alias ni realizar especificación con el nombre de tabla de cada una.
Una subconsulta forma parte siempre de una condición de búsqueda en la
cláusula WHERE o HAVING. Anteriormente se describió las condiciones de búsqueda
simples que pueden ser utilizadas en estas cláusulas. Además, SQL ofrece estas
condiciones de búsqueda de subconsultas.
Test de comparación de subconsulta (=, <>, <, <=, >, >=)
El test de comparación subconsulta es una forma modificada del test de
comparación simple, tal como se muestra en el siguiente ejemplo. Compara el
valor de una expresión con el valor producido por una subconsulta, y devuelve un
resultado TRUE si la comparación es cierta. Este test se utiliza para comparar un
valor de la fila que está siendo examinada con un valor único producido por una
subconsulta.
Listar los representantes cuyas cuotas son iguales o
superiores al objetivo de la oficina de venta de Córdoba

SELECT *
FROM Representante
WHERE cuota >= ( SELECT objetivo
FROM Oficinas
WHERE ciudad = 'Córdoba');
La subconsulta recupera un solo valor, el objetivo de venta de la oficina de
Córdoba. El valor se utiliza entonces para seleccionar los vendedores cuyas cuotas
son superiores o iguales al objetivo.
El test de comparación subconsulta ofrece los mismos seis operadores de
comparación (=, <>, <, <=, >, >=) disponibles con el test de comparación simple.
La subconsulta especificada en este test debe producir una única fila de resultados.
Si la subconsulta produce múltiples filas, la comparación no tiene sentido, y SQL
informa de una condición de error. Si la subconsulta no produce filas o produce un
valor NULL, el test de comparación devuelve NULL.
Test de pertenencia a conjunto (IN)
El test de pertenencia a conjunto subconsulta (IN) es una forma modificada
del test de pertenencia a conjunto simple. Compara un único valor de datos con
una columna de valores producida por una subconsulta y devuelve un resultado
TRUE si el valor coincide con uno de los valores de la columna. Este test se utiliza
cuando se necesita comparar un valor de la fila que está siendo examinada con un
conjunto de valores producidos por una subconsulta, como se muestra en los
ejemplos.
Lista los vendedores que trabajan en oficinas que superan su
cuota

SELECT *
FROM Representante
WHERE Oficina_rep IN (SELECT Oficina
FROM Oficinas
WHERE ventas > cuota );

lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera Z - 30L Pád|ra 110 de 20ê
Lista los clientes que no tienen factura con importe superior
a 100 .

SELECT * FROM Cliente
WHERE dni NOT IN ( SELECT DISTINCT dni
FROM Factura
WHERE importe > 100 );
En cada uno de estos ejemplos, la subconsulta produce una columna de
valores, y la cláusula WHERE de la consulta principal comprueba si un valor de una
fila de la consulta principal coincide con uno de los valors de la columna. El formato
de la subconsulta en el test IN funciona por tanto exactamente igual al del test IN
simple, excepto que el conjunto de valores producido por una subconsulta en lugar
de ser explícitamente lista en la sentencia.
Test de existencia (EXISTS)
El test de existencia (EXISTS) comprueba si una subconsulta produce alguna
fila de resultados. No hay test de comparación simple que se asemeje al test de
existencia; solamente se utiliza con subconsultas. Por ejemplo
Listas los clientes que tienen al menos una factura con
importe superior a 100 .

SELECT *
FROM Cliente
WHERE EXIST ( SELECT *
FROM Factura
WHERE Factura.dni = Cliente.dni
AND importe > 100 );
Conceptualmente, SQL procesa esta consulta recorriendo la tabla Cliente y
efectuando la subconsulta para cada cliente. La subconsulta produce una columna
que contiene los datos de una factura de aquellas facturas del cliente actual con
importe superior a 100 C. Si hay alguna de tales facturas (es decir, la subconsulta
arrojó algún resultado), el test EXISTS devuelve TRUE. Si la subconsulta no
produce filas, el test EXISTS es FALSE. El test EXISTS no puede producir un valor
NULL.
Se puede invertir la lógica del test EXISTS utilizando la forma NOT EXISTS.
En este caso, el test es TRUE si la subconsulta no produce filas, y FALSE en caso
contrario. Observe que la condición de búsqueda EXISTS no utiliza realmente los
resultados de la subconsulta. Simplemente comprueba si la subconsulta produce
algún resultado.
Test cuantificados (ANY y ALL)
La versión subconsulta del test IN comprueba si un valor de dato es igual a
algún valor en columna de los resultados de una subconsulta. SQL proporciona dos
test cuantificados, ANY y ALL, que extienden esta noción a otros operadores de
comparación, tales como mayor que (>) y menor que (<). Ambos test comparan
un valor de dato con la columna de valores producidos por una subconsulta.
El test ANY se utiliza conjuntamente con uno de los seis operadores de
comparación SQL (=, <>, <, <=, >, >=) para comparar un único valor de test con
una columna de valores producidos por una subconsulta. Para efectuar el test, SQL
utiliza el operador de comparación especificado para comparar el valor de test con
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera Z - 30L Pád|ra 111 de 20ê
cada valor de datos en la columna, uno cada vez. Si alguna de las comparaciones
individuales producen un resultado TRUE, el test ANY, devuelve un resultado TRUE.
Por ejemplo
Lista los Representantes que han hecho algún pedido cuyo
importe supere el 10% de su cuota.

SELECT *
FROM Representante
WHERE ( cuota * 0.1 ) > ANY ( SELECT importe
FROM Pedidos
WHERE rep = dni );
La consulta principal examina cada fila de la tabla Represenante, una a una.
La subconsulta encuentra todos los pedidos hechos por el vendedor actual y
devuelve una columna que contiene el importe de esos pedidos. La cláusula WHERE
de la consulta principal calcula entonces el diez por ciento de la cuota del vendedor
actual y la utiliza como valor de test, comparándolo con todos los importes de
pedidos producidos por la subconsulta. Si hay algún importe que exceda al valor de
test calculado, el test < ANY devuelve TRUE y el vendedor queda incluido en los
resultados de la consulta.
La palabra clave SOME es una alternativa para ANY especificada por el
estándar SQL ANSI/ISO. Cualquiera de las dos palabras clave puede ser utilizada
generalmente, pero algunos SGBD no la soportan.
El test ALL también se utiliza conjuntamente con no de los seis operadores
de coparación SQL (=, <>, <, <=, >, >=) para comparar un único valor de test
con una columna de valores de datos producidos por una subconsulta. Para
efectuar el test, SQL utiliza el operador de comparación especificado para comparar
el valor de test con todos y cada uno de los valores de datos de la columna. Si
todas las comparaciones individuales producen un resultado TRUE, el test ALL
devuelve un resultado TRUE, en caso contrario devuelve FALSE. Por ejemplo
Listar las oficinas y sus objetivos donde todos los
vendedores tienen ventas que superan el 50% del objetivo de
la oficina

SELECT oficina, ciudad, objetivo
FROM Oficinas
WHERE (0.5 * objetivo) < ALL ( SELECT ventas
FROM Represenante
WHERE oficina_Rep = oficina )
Conceptualmente, la consulta principal examina cada fila de la tabla Oficinas
una a una. La subconsulta encuentra todos los vendedores que trabajan en la
oficina "actual" y devuelve una columna que contiene las ventas correspondientes a
cada vendedor. La cláusula WHERE de la consulta principal calcula entonces el 50%
del objetivo de la oficina y lo utiliza como valor de ventas producidos por la
subconsulta. Si todos los valores de ventas exceden el valor del test calculado, el
test < ALL devuelve TRUE y la oficina se incluye en los resultados de la consulta. Si
no, la oficina no se incluye en los resultados de la consulta.
Subconsultas anidadas
Todas las consultas descritas hasta ahora en este capítulo hansido consultas
de dos niveles, afectando a una consulta principal y una subconsulta. Del mismo
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera Z - 30L Pád|ra 112 de 20ê
modo ue se puede utilizar una subconsulta dentro de una consulta principal, se
puede utilizar una subconsulta dentro de otra subconsulta. Por ejemplo
Listar los pedidos cuyos representantes están asignados a
oficinas de la región de Andalucía
SELECT *
FROM Pedidos
WHERE rep IN ( SELECT dni
FROM Representante
WHERE oficina_rep IN ( SELECT oficina
FROM Oficinas
WHERE region = 'Andalucía'
)
);
En este ejemplo la subconsulta más interna produce una columna que
contiene los números de oficina de las oficinas en la región Andalucía. La
subconsulta siguiente produce una columna que contiene los dni de los vendedores
que trabajan en una de las oficinas seleccionadas. Finalmente, la consulta más
externa encuentra los clientes cuyos vendedores tienen uno de los números de
empleado seleccionados.
La misma técnica utilizada en esta consulta de tres niveles puede utilizarse
para construir consultas con cuatro o más niveles. El estándar SQL ANSI/ISO no
especifica un número máximo de niveles de anidación, pero en la práctica una
consulta consume mucho más tiempo cuando se incrementa el número de niveles.
La consulta también resulta mucho más difícil de leer, comprender y mantener
cuando contiene más de uno o dos niveles de subconsultas.
Subconsultas en la cláusula HAVING
Aunque las subconsultas suelen encontrarse sobre todo en la cláusula
WHERE, también pueden utilizarse en la cláusula HAVING de una consulta. Cuando
una subconsulta aparece en la cláusula HAVING, funciona como parte de la
selección de grupo de filas efectuada por la cláusula HAVING. Por ejemplo
Listar los representantes cuyo tamaño de pedido medio es
superior al tamaño de pedido medio global

SELECT rep, AVG(importe)
FROM Pedidos
GROUP BY rep
HAVING AVG(importe) > ( SELECT AVG(importe)
FROM Pedidos );
La subconsulta calcula el tamaño de pedido medio global, de todos los
pedidos. La consulta principal recorre la tabla Pedidos, hallando todos los pedidos
agrupándolos por representante. La cláusula HAVING comprueba entonces cada
grupo de filas para ver si el tamaño de pedido medio de ese grupo es superior al
promerio de todos los pedidos, calculado con antelación. Si es así, el grupo de filas
es retenido; si no, el grupo de filas es descartado. Finalmente la cláusula SELECT
produce una fila sumaria por cada grupo, mostrando el nombre del vendedor y el
tamaño medio de pedido para cada uno.
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera Z - 30L Pád|ra 113 de 20ê
CON$bLIA$ MbLIIIA8LA
El posible que para consultas sencillas, todos los datos que necesitemos
estén en una sola tabla. Pero. ¿y si están repartidos por una, dos o muchas
tablas? Es posible hacer consultas que incluyan más de una tabla dentro de la
cláusula FROM, pero en estas consultas hay que tener en cuenta ciertos factores.
Veamos la siguiente consulta.
SELECT numero, Factura.dni, Cliente.dni, nombre, importe FROM
Factura, Cliente;
Suponiendo que tenemos los siguientes datos:
Tabla Factura
#Numero Dni Importe Fecha Dto.
A111 1 50 15/12/2003 0
A112 2 125 17/12/2003 0
A113 5 200 17/12/2003 0
A114 5 75 18/12/2003 1
A115 1 100 19/12/2003 2

Tabla Cliente
#Dni Nombre Apellidos Dirección Población CP
1 José Gómez López c/ Mayor, 1 Córdoba 14002
2 Juan Martínez Salazar Av. Pi, 10 Jaén 23003
5 Antonio Caracol Bueno c/ Farruco, 8 Cádiz 11004
El select anterior nos retornará el siguiente result set
Numero Dni Dni Nombre Importe
A111 1 1 José 50
A111 1 2 Juan 50
A111 1 5 Antonio 50
A112 2 1 José 125
A112 2 2 Juan 125
A112 2 5 Antonio 125
A113 5 1 José 200
A113 5 2 Juan 200
A113 5 5 Antonio 200
A114 5 1 José 75
A114 5 2 Juan 75
A114 5 5 Antonio 75
A115 1 1 José 100
A115 1 2 Juan 100
A115 1 5 Antonio 100
Podemos ver que el resultado es el producto cartesiano de una tabla por
otra tabla, es decir, todas las combinaciones posibles de la tabla FACTURA con la
tabla CLIENTE. Pero en realidad lo que a nosotros nos interesa es mostrar todas las
facturas, pero con la descripción del cliente de cada factura, es decir, que cada
factura seleccione sólo su registro correspondiente de la tabla CLIENTE. Los
registros que a nosotros nos interesan están marcados en negrita en el esquema
anterior, y en todos ellos se cumple que Factura.dni = Cliente.dni, o dicho de otro
modo, los campos que componen la relación igualados.
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera Z - 30L Pád|ra 111 de 20ê
Entonces del resultado anterior, sólo nos interesan los registros marcados en
negrita, y la sentencia SELECT que nos retorna ese resultado es:
SELECT numero, Factura.dni, Cliente.dni, nombre, importe
FROM Factura, Cliente
WHERE Factura.dni = Cliente.dni;
Fíjese que cuando se listan columnas de diferentes tablas, pero que
tienen el mismo nombre, es necesario cualificarlas con el nombre de la tabla a la
que pertenecen. El resultado final es:
Numero Dni Dni Nombre Importe
A111 1 1 José 50
A112 2 2 Juan 125
A113 5 5 Antonio 200
A114 5 5 Antonio 75
A115 1 1 José 100
Como norma general se puede decir que para combinar dos o más tablas
hay que poner como condición la igualdad entre las claves de una tabla y la clave
externa de la otra. Las condiciones dentro del WHERE que sirven para hacer el
enlace entre tablas se denominan JOIN (unión, enlace).
Consultas multitabla con criterios de selección de fila
La condición de búsqueda que especifica las columnas de emparejamiento
en una consulta multitabla puede combinarse con otras condiciones de búsqueda
para restringir aún más los contenidos de los resultados. Supongamos que se desea
ejecutar la cosulta anterior, pero mostrando únicamente las facturas cuyo importe
superan los 100 C.
SELECT numero, Factura.dni, Cliente.dni, nombre, importe
FROM Factura, Cliente
WHERE Factura.dni = Cliente.dni
AND importe > 100;
Con la condición de búsqueda adicional, las filas que aparecen en los
resultados están aún más restringidas. El primer test (Factura.dni = Cliente.dni)
selecciona solamente los pares de filas Factura y Cliente que tienen la adecuada
relación padre/hijo; el segundo test selecciona adicionalmente sólo aquellos pares
de filas en donde la oficina está por encima del objetivo.
Múltiples columnas de emparejamiento
Supongamos dos tablas con la siguiente estructura
Tabla LineaPedido
#Pedido #Línea Referencia Unidades Precio Dto
Tabla LineaAlbarán
#Albarán #Línea Referencia Unidades Precio Dto Pedido LineaP
En la tabla Línea de Albarán hay una clave externa formada por dos
columnas (pedido, lineap) que referencia a Línea de Pedido. Para componer las
tablas basándose en esta relación, deben especificarse ambos pares de columnas
de emparejamiento, tal y como muestra este ejemplo:
Listar las líneas de albarán y las líneas de pedido para
aquellas líneas donde unidades pedidas son superiores a 10.
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera Z - 30L Pád|ra 115 de 20ê

SELECT LineaAlbaran.*, LineaPedido.*
FROM LineaAlbaran, LineaPedido
WHERE LineaAlbaran.pedido = LineaPedido.pedido
AND LineaAlbaran.nlineap = LineaPedido.nlinea
AND LineaPedido.unidades > 10;
La condición de búsqueda en la consulta dice a SQL que los pares de filas
relacionados en las tablas LineaAlbaran y LineaPedido son aquellas en las que
ambos pares de columnas coincidentes contienen los mismos valores.
Consultas de tres o más tablas
SQL puede combinar datos de tres o más tablas utilizando las mismas
técnicas básicas utilizadas para las consultas de dos tablas. Supongamos que
disponemos de las tres tablas siguientes:
Tabla LineaPedido
#Pedido #Línea Referencia Unidades Precio Dto
Tabla LineaAlbaran
#Albarán #Línea Referencia Unidades Precio Dto Pedido LineaP
Tabla Albaran
#Numero Fecha Cliente Forma_Pago
Fijémonos en la siguiente sentencia
Listar el número de albaran, fecha, forma de pago, línea de
albarán, referencia del artículo en el albarán, unidades
vendidas en el albarán y unidades pedidas.

SELECT numero, fecha, forma_pago, LineaAlbaran.linea,
LineaAlbaran.referencia, LineaAlbaran.unidades,
LineaPedido.unidades
FROM Albaran, LineaAlbaran, LineaPedido
WHERE Albaran.numero = LineaAlbaran.albaran
AND LineaAlbaran.pedido = LineaPedido.pedido
AND LineaAlbaran.lineap = LineaPedido.linea;
Esta consulta usa dos claves externas en la tabla LineaAlbaran. La columna
albaran es una clave externa para la tabla Albaran, que enlaza cada línea de
albarán con su correspondiente albarán. Las columnas pedido, lineap forman una
clave externa a la tabla LineaPedido, que enlaza cada linea de albarán con su
correspondiente línea de pedido.
Join externo
Existe un caso especial cuando se establece un join entre tablas: el outer
join. Este caso se da cuando los valores de los campos enlazados en alguna de las
tablas, contiene el valor NULL. Al realizar un join, si algún campo enlazado contiene
el valor NULL, ese registro quedará automáticamente excluido, ya que una
condición en la que un operando sea NULL siempre se evalúa como falso.
Supongamos que las tablas utilizadas en ejemplos anteriores ahora tienen
los siguientes datos:
Tabla Factura
#Numero Dni Importe Fecha Dto.
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera Z - 30L Pád|ra 11ê de 20ê
A111 1 50 15/12/2003 0
A112 Null 125 17/12/2003 0
A113 1 200 17/12/2003 0
A114 Null 75 18/12/2003 1
A115 7 100 19/12/2003 2

Tabla Cliente
#Dni Nombre Apellidos Dirección Población CP
1 José Gómez López c/ Mayor, 1 Córdoba 14002
2 Juan Martínez Salazar Av. Pi, 10 Jaén 23003
5 Antonio Caracol Bueno c/ Farruco, 8 Cádiz 11004
Si realizamos la misma consulta (las facturas con la descripción de cliente),
no aparecerán las facturas "A112¨ y "A114¨, ya que su campo dni contiene un
NULL, y al evaluar la condición de join (WHERE Factura.dni = Cliente.dni), no
se evaluará como verdadero.
Además, tampoco aparecerá la factura "A115¨, porque el cliente "7¨ no
existe en la tabla de clientes. Sin embargo, puedes ser que necesitemos mostrar
todas las facturas de la base de datos, independientemente de si el cliente existe o
si el campo está a NULL.
Para ello debemos utilizar un outer join (join externo), que es un JOIN pero
indicando que queremos considerar aquellos registros que se descartan por
existencia de nulos. Dependiendo de la procedencia de los datos que queremos
incluir en el resultado de la consulta existen tres tipos de join externo:
• Join externo completo.- OUTER JOIN. Se indica que el resultado debe
incluir tantas filas como se puedan combinar con las dos tablas (join
interno) más una fila por cada fila de la primera tabla que no se ha
podido emparejar con la segunda tabla y más una fila por cada fila de
la segunda tabla que no se ha podido emparejar con la primera tabla.
• Join externo izquierdo.- LEFT JOIN. Se indica que el resultado debe
incluir tantas filas como se puedan combinar con las dos tablas (join
interno) más una fila por cada fila de la primera tabla (a la izquierda)
que no se ha podido emparejar con la segunda tabla.
• Join externo derecho.- RIGTH JOIN. Se indica que el resultado debe
incluir tantas filas como se puedan combinar con las dos tablas (join
interno) más una fila por cada fila de la segunda tabla (a la derecha)
que no se ha podido emparejar con la primera tabla.
Veamos un ejemplo de cada caso. En el join externo completo la sentencia
anterior sería:
SELECT numero, Factura.dni, Cliente.dni, nombre
FROM Factura
OUTER JOIN Cliente
ON Factura.dni = Cliente.dni;
y el resultado sería:
Numero Dni Dni Nombre
A111 1 1 José
A113 1 1 José
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera Z - 30L Pád|ra 11Z de 20ê
A115 7 Null Null
A112 Null Null Null
A114 Null Null Null
Null Null 2 Juan
Null Null 5 Antonio
Como se puede observar, las dos primeras filas son resultado de combinar
las dos tablas. Sin embargo, las tres siguientes filas de la tabla Factura no se han
podido combinar con ninguna fila de la tabla Cliente, con lo que los valores de está
en el resultado son Null. Las dos últimas filas del resultado son filas de la segunda
tabla que no se han podido combinar con ninguna de la primera, y por tanto los
valores de las columnas pertenecientes a la primera son Null.
Si quisiéramos hacer un join externo por la izquierda, es decir, que el
resultado tenga todas las posibles combinaciones de las dos tablas y además las
filas de la tabla Factura que no han podido emparejarse. La sentencia select sería:
SELECT numero, Factura.dni, Cliente.dni, nombre
FROM Factura
LEFT JOIN Cliente
ON Factura.dni = Cliente.dni;
y el resultado sería:
Numero Dni Dni Nombre
A111 1 1 José
A113 1 1 José
A115 7 Null Null
A112 Null Null Null
A114 Null Null Null
El resultado es similar al anterior, excepto en que las dos ultimas filas no
aparecen al añadir solamente las filas de la tabla de la izquierda.
De forma análoga, si quisiéramos hacer un join externo por la derecha, es
decir, que el resultado tenga todas las posibles combinaciones de las dos tablas y
además las filas de la tabla Cliente que no han podido emparejarse, la sentencia
select sería:
SELECT numero, Factura.dni, Cliente.dni, nombre
FROM Factura
RIGHT JOIN Cliente
ON Factura.dni = Cliente.dni;
y el resultado sería:
Numero Dni Dni Nombre
A111 1 1 José
A113 1 1 José
Null Null 2 Juan
Null Null 5 Antonio
Como se puede observar, las dos primeras filas son resultado de combinar
las dos tablas y las dos últimas corresponden a filas de la tabla Cliente (derecha)
que no se han podido combinar con ninguna de la tabla Factura y por eso las
columnas de esta tabla aparecen con valores nulos.
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera Z - 30L Pád|ra 118 de 20ê
Por último, indicar que una consulta SQL con un join interno puede
realizarse utilizando una sintaxis similar a la del join externo. Consiste en quitar la
segunda tabla de la cláusula FROM y ponerla en una cláusula INNER JOIN. La
condición de enlace se elimina de la cláusula WHERE y se añadiría a una cláusula
ON.
La select del ejemplo anterior quedaría así:
SELECT numero, Factura.dni, Cliente.dni, nombre
FROM Factura
INNER JOIN Cliente
ON Factura.dni = Cliente.dni;
ACIbALIIACIONE$ DE DAIO$
SQL es un lenguaje completo de manipulación de datos que se utiliza no
solamente para consultas, sino también para modificar y actualizar los datos de la
base de datos. Comparadas con la complejidad de la sentencia SELECT, que
soporta las consultas en SQL, las sentencias SQL que modifican los contenidos de la
base de datos son extremadamente sencillas. Sin embargo, el SGBD debe proteger
la integridad de los datos almacenados durante los cambios, asegurándose que sólo
se introduzcan datos válidos y que la base de datos permanezca autoconsistente,
incluso en caso de fallos del sistema. El SGBD debe coordinar también las
actualizaciones simultáneas por parte de múltiples usuarios, asegurándose que los
usuarios y sus modificaciones no interfieran unos con otros. Para modificar los
contenidos de una base de datos hay tres sentencias:
• INSERT, que añade nuevas filas de datos a una tabla.
• DELETE, que elimina filas de datos de una tabla.
• UPDATE, que modifica datos existentes en la base de datos.
Añadir filas. Sentencia INSERT
La unidad de datos más pequeña que puede añadirse a una base de datos
es una fila completa de una tabla. En general, un SGBD basado en SQL proporciona
tres maneras de añadir nuevas filas de datos a una base de datos:
• Una sentencia INSERT de una fila añade una única nueva fila de
datos a una tabla. Se utiliza habitualmente en aplicaciones diarias,
por ejemplo, en programas de entrada de datos.
• Una sentencia INSERT multifila extrae filas de datos de otra parte
de la base y las añade a una tabla.
• Una utilidad de carga masiva añade datos a una tabla desde un
fichero externo a la base de datos. Se utiliza habitualmente para
cargar inicialmente la base de datos o para incorporar datos
transferidos desde otro sistema informático.
La sentencia INSERT de una fila añade una nueva fila a una tabla. La
cláusula INTO especifica la tabla que recibe la nueva fila (la tabla destino), y la
cláusula VALUE especifica los valores de datos que la nueva fila contendrá. La lista
de columnas indica qué valor va a qué columna de la nueva fila.
INSERT INTO tabla [( lista de columnas )]
VALUES( lista de valores );
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera Z - 30L Pád|ra 119 de 20ê
Los nombres de las columnas detrás del nombre de tabla son opcionales y si
no se ponen se supondrá todos los campos de la tabla en su orden original. Si se
ponen, se podrán indicar cualquier número de columnas en cualquier orden. La lista
de valores son los datos que se insertarán en la tabla. Los tipos de datos deben
coincidir con la definición dada en tabla.
Se puede utilizar la sentencia INSERT con SQL interactivo para añadir filas a
una tabla que crece muy raramente, como por ejemplo la tabla Oficinas. En la
práctica, sin embargo, los datos referentes a un nuevo cliente, un nuevo pedido o
un nuevo representante son casi siempre añadidos a una base de datos mediante
un programa de entrada orientado a formularios. Cuando la entrada de datos está
completa, el programa de aplicación inserta la nueva fila de datos utilizando SQL
interactivo o programado, sin embargo, la sentencia INSERT es la misma.
El propósito de la lista de columnas en la sentencia INSERT es hacer corres-
ponder los valores de datos en la cláusula VALUES con las columnas que van a
recibirlos. La lista de valores y la lista de columnas deben contener el mismo
número de elementos, y el tipo de dato de cada valor debe ser compatible con el
tipo de dato de la columna correspondiente, o en caso contrario se producirá un
error. El estándar ANSI/ISO exige nombres de columna sin cualificar en la lista de
columnas, pero muchas implementaciones permiten nombres cualificados.
Naturalmente no puede existir ambigüedad alguna en los nombres de columna, ya
que deben referenciar todas a columnas de la tabla destino. Por ejemplo
INSERT INTO Factura (numero, dni, importe, fecha )
VALUES( ‘A111’, 1, 155, ‘22/12/2003’ );
Las columnas que no se incluyan en el INTO, se inicializarán con NULL, (si
no se ha definido valor por defecto). Se puede hacer más explícita la asignación del
valor NULL incluyendo las columnas en la lista y especificando la palabra clave
NULL en los valores. Esta sentencia INSERT tiene exactamente el mismo efecto que
la anterior
INSERT INTO Factura (numero, dni, importe, fecha, dto )
VALUES( ‘A111’, 1, 155, ‘22/12/2003’, NULL );
La segunda forma de la sentencia INSERT añade múltiples filas de datos a
su tabla destino. En esta forma la sentencia INSERT, los valores de datos para
las nuevas filas no son especificados explícitamente dentro del texto de la
sentencia. En su lugar, la fuente de las nuevas filas es una consulta de base de
datos, especificada en la sentencia.
INSERT INTO tabla [( lista de columnas )]
SELECT . . .
La adición de filas cuyos valores provienen de la propia base de datos
puede parecer extraña al principio, pero es muy útil en algunas situaciones
especiales. Por ejemplo, supongamos que se quiere rellenar una tabla llamada
Facturas2004, con todas las facturas del año 2004. La sentencia que haría esto
es:
INSERT INTO Facturas2004
SELECT * FROM Facturas WHERE YEAR(fecha) = 2004;
El estándar SQL ANSI/ISO especifica varias restricciones sobre la consulta
que aparece dentro de la sentencia INSERT multifila:
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera Z - 30L Pád|ra 120 de 20ê
• La consulta no puede contener una cláusula ORDER BY. No es útil
ordenar los resultados de la consulta de ningún modo, ya que van a
ser insertados en una tabla que es, como todas las tablas,
desordenada.
• La consulta no puede ser la UNION de varias sentencias SELECT
diferentes. Sólo puede especificarse una única sentencia SELECT.
• La tabla destino de la sentencia INSERT no puede aparecer en la
cláusula FROM de la consulta o de ninguna subconsulta que ésta
contenga. Esto prohibe insertar parte de una tabla en sí misma.

Además, los resultados de la consulta deben contener el mismo número de
columnas que la lista de columnas de la sentencia INSERT (o de la tabla destino
entera, si se ha omitido la lista de columnas), y los tipos de datos deben ser
compatibles, columna a columna.
La tercera manera de añadir filas a las tablas de una base de datos es
mediante una utilidad de carga masiva. Los datos a insertar en una base de
datos son con frecuencia extraídos de otro sistema informático o recolectados de
otros lugares y almacenados en un archivo secuencial. Para cargar los datos en una
tabla, se podría escribir un programa con un bucle que leyera cada registro del
archivo y utilizara la sentencia INSERT de una fila para añadir la fila a la tabla. Sin
embargo, el recargo de hacer que el DBMS ejecute repetidamente sentencias
INSERT de una fila puede ser bastante alto. Si insertar una sola fila tarda medio
segundo para una carga de sistema típica, éste es un rendimiento probablemente
aceptable para un programa interactivo. Pero este rendimiento rápidamente pasa a
ser inaceptable cuando se aplica a la tarea de cargar 50.000 filas de datos de una
vez. En este caso, la carga de los datos requeriría más de seis horas.
Por esta razón, todos los productos DBMS comerciales incluyen una capaci-
dad de carga masiva que carga los datos desde un archivo a una tabla a alta
velocidad. El estándar SQL ANSI/ISO no considera esta función, y suele ser
suministrada como un programa de utilidad autónomo en lugar de formar parte del
lenguaje SQL. La utilidad que cada vendedor suministra dispone de un conjunto
ligeramente diferente de características, funciones y órdenes.
Supresión de datos. Sentencia DELETE
La unidad más pequeña de datos que puede ser supr da de una base de
datos relacional es una única fila. La sentencia DELETE elimina filas seleccionadas
de datos de una única tabla. La cláusula FROM especifica la tabla destino que
contiene las filas. La cláusula WHERE especifica la condición que cumplen las filas
de la tabla que van a ser suprimidas. Es equivalente al SELECT, pero en vez de
mostrar las filas que cumplan la condición, las elimina. Su sintaxis es:
DELETE [FROM] tabla
[WHERE condición];
Por ejemplo:
DELETE FROM Cliente
WHERE dni = 1;
La clásula WHERE de este ejemplo identifica una sola fila de la tabla Cliente,
que SQL elimina de la tabla. La cláusula WHERE tiene un aspecto familiar, es
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera Z - 30L Pád|ra 121 de 20ê
exactamente la misma cláusula WHERE que se especificaría en una sentencia
SELECT para recuperar la misma fila de la tabla. Las condiciones de búsqueda que
pueden especificarse en la cláusula WHERE de la sentencia DELETE son las mismas
disponibles en la cláusula WHERE de la sentencia SELECT, descrita en secciones
anteriores.
Recuerde que las condiciones de búsqueda en la cláusula WHERE de una
sentencia SELECT pueden especificar una sola fila o un conjunto entero de filas,
dependiendo de la condición de búsqueda específica. Lo mismo es aplicable a la
cláusula WHERE en una sentencia DELETE. Supongamos, por ejemplo, que se
quieren borrar todos los pedidos del cliente 1. He aquí la sentencia de supresión
que elimina los pedidos de la tabla Pedidos:
DELETE FROM Pedidos
WHERE cli = 1;
En este caso, la cláusula WHERE selecciona varias filas de la tabla Pedidos, y
SQL elimina todas las filas seleccionadas de la tabla. Conceptualmente, SQL aplica
la cláusula WHERE a cada una de las filas de la tabla Pedidos, suprimiendo aquéllas
para las cuales la condición de búsqueda produce un resultado TRUE y reteniendo
aquéllas para las cuales la condición de búsqueda produce un resultado FALSE o
NULL. Otro ejemplo
Eliminar todos los pedidos anteriores al 20/8/2004

DELETE FROM Pedidos
WHERE fecha < '20/8/2004';
Si se omite la cláusula WHERE se borrarán todas las filas de la tabla. Por
ejemplo:
DELETE FROM Pedidos;
Aunque esta sentencia DELETE produce una tabla vacía, no borra la tabla
Pedidos de la base de datos. La definición de la tabla Pedidos y sus columnas
siguen estando almacenadas en la base de datos. La tabla aún existe, y nuevas
filas pueden ser insertadas en la tabla Pedidos con la sentencia INSERT. Para
cancelar la definición de la tabla de la base de datos, debe utilizarse la sentencia
DROP TABLE (descrita posteriormente).
Debido al daño potencial que puede producir una sentencia DELETE tal como
ésta, es importante especificar siempre una condición de búsqueda y tener cuidado
de que se seleccionan realmente las filas que se desean. Cuando se utiliza SQL
interactivo, es buena idea utilizar primero la cláusula WHERE en una sentencia
SELECT para visualizar las filas seleccionadas, asegurarse de que son las que
realmente se desea suprimir, y sólo entonces utilizar la cáusula WHERE en una
sentencia DELETE.
Las sentencias DELETE con condiciones de búsqueda simples, como las de
los ejemplos anteriores, seleccionan las filas a suprimir basándose únicamente en
los propios contenidos de las filas. A veces, la selección de las filas debe efectuarse
en base a datos contenidos en otras tablas. Por ejemplo, supongamos que se desea
suprimir todos los pedidos del representante José. Sin saber su dni, no se pueden
determinar los pedidos consultando únicamente la tabla Pedidos. El modo de
manejar la petición es con una de las condiciones de búsqueda subconsulta. He
aquí una forma válida de la sentencia DELETE que realiza la petición:
DELETE FROM Pedidos
WHERE Rep = ( SELECT dni
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera Z - 30L Pád|ra 122 de 20ê
FROM Representante
WHERE nombre = 'José' );
La consulta halla el dni del representante José, y la cláusula WHERE
selecciona entonces los pedidos con un valor correspondiente. Como muestra este
ejemplo, las subconsultas pueden jugar un papel importante en la sentencia
DELETE, ya que permiten suprimir filas en base a información contenida en otras
tablas. He aquí otro ejemplo de sentencias DELETE que utiliza condición de
búsqueda subconsulta:
Borrar los pedidos de la oficina de Córdoba

DELETE FROM Pedidos
WHERE rep IN ( SELECT dni
FROM Representante
WHERE oficina_rep = ( SELECT oficina
FROM Oficinas
WHERE ciudad = 'Córdoba'
)
);
Las subconsultas en la cláusula WHERE pueden anidarse al igual que sucedía
en la cláusula WHERE de la sentencia SELECT. También pueden contener
referencias externas a la tabla destino de la sentencia DELETE. A este respecto, la
cláusula FROM de la sentencia DELETE funciona igual que la cláusula FROM de la
sentencia SELECT. He aquí un ejemplo de una petición de supresión que requiere
una subconsulta con una referencia externa:
Borrar los clientes que no han hecho pedido desde el 10 de
septiembre.

DELETE FROM Clientes
WHERE NOT EXISTS ( SELECT *
FROM Pedidos
WHERE dni = cli
AND fecha > '10/9/2004' );
Conceptualmente, esta sentencia DELETE opera recorriendo la tabla
Clientes, fila a fila, y comprobando la condición de búsqueda. Para cada cliente, la
subconsulta selecciona los pedidos hechos por ese cliente después de la fecha de
corte. La referencia a la columna dni en la subconsulta es una referencia externa al
dni de cliente en la fila de la tabla Clientes que actualmente está siendo
comprobada por la sentencia DELETE.
Modificación de datos. Sentencia UPDATE
La unidad más pequeña de datos que puede modificarse en una base de
datos es una única columna de una única fila. La sentencia UPDATE modifica los
valores de una o más columnas en las filas seleccionadas de una tabla única. Su
sintaxis es:
UPDATE tabla
SET campo = valor,
campo = valor,
. . .
[WHERE condición];
La tabla destino a actualizar se indica en la sentencia, y es necesario
disponer de permiso para actualizar la tabla además de cada una de las columnas
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera Z - 30L Pád|ra 123 de 20ê
individuales que serán modificadas. La cláusula WHERE selecciona las filas de la
tabla a modificar. La cláusula SET especifica qué columnas se van a actualizar y
calcula los nuevos valores. He aquí un ejemplo que modifica el importe y el
descuento de la factura del cliente con dni 1 y fecha 22/12/2003.
UPDATE Factura
SET importe = 1000,
dto = 1.5
WHERE dni = 1 AND
fecha = ‘22/12/2003’;

La cláusula WHERE es exactamente la misma que se utilizaría en una
sentencia DELETE o SELECT para identificar la fila. De hecho, las condiciones de
búsqueda que pueden aparecer en la cláusula WHERE de una sentencia UPDATE
son exactamente las mismas que las disponibles en las sentencias SELECT y
DELETE.
Al igual que la sentencia DELETE, la sentencia UPDATE puede actualizar
varias filas de una vez con la condición de búsqueda adecuada, como en este
ejemplo:
Aumentar en un 5% el descuento de los pedidos del
representante con dni 2

UPDATE Pedidos
SET dto = dto + 0.5
WHERE rep = 2;
En este caso, la cláusula WHERE selecciona varias filas de la tabla Pedidos, y
el valor de la columna dto se modifica en todas ellas. Conceptualmente, SQL
procesa la sentencia UPDATE al recorrer la tabla Pedidos fila a fila, actualizando
aquellas filas para las cuales la condición de búsqueda produce un resultado TRUE y
omitiendo aquéllas para las cuales la condición de búsqueda produce un resultado
FALSE o NULL.
La cláusula SET en la sentencia UPDATE es una lista de asignaciones
separadas por comas. Cada asignación identifica una columna destino a actualizar y
especifica cómo calcular el nuevo valor para la columna destino. Cada columna
destino debería aparecer solamente una vez en la lista; no debería haber dos
asignaciones para la misma columna destino. La especificación ANSI/ISO exige
nombres sin cualificar para las columnas destino, pero algunas implementaciones
SQL permiten la implementación de nombres de columna cualificados. No puede
existir ambigüedad alguna en los nombres de columna, ya que deben referirse a
columnas de la tabla destino.
La expresión en cada asignación puede ser cualquier expresión SQL que
genere un valor del tipo de dato apropiado para la columna destino. La expresión
debe ser calculable basada en los valores de la fila actualmente en actualización en
la tabla destino. No pueden incluirse funciones de columna ni subconsultas.
Si una expresión en la lista de asignación referencia a una de las consultas
de la tabla destino, el valor utilizado para calcular la expresión es el valor de esa
columna en la fila actual antes de que se aplique ninguna actualización. Lo mismo
es aplicable a las referencias de columna que se producen en la cláusula WHERE.
Por ejemplo, consideremos esta sentencia UPDATE
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera Z - 30L Pád|ra 121 de 20ê
UPDATE Representante
SET cuota = 400000, ventas = cuota
WHERE cuota < 400000;
Antes de la actualización, el represenante José tenía un valor de cuota de
350.000 C y un valor de ventas de 367.911 C. Después de la actualización, su fila
tiene un valor de ventas de 350.000 C, y no de 400.000 C. El orden de las
asignaciones en la cláusula SET no importa; las asignaciones pueden especificarse
en cualquier orden.
La cláusula WHERE en la sentencia UPDATE es opcional. Si se omite la
cláusula WHERE, entonces se actualizan todas las filas de la tabla destino, como en
este ejemplo
UPDATE Representante
SET cuota = cuota + 50000;
A diferencia de la sentencia DELETE, en donde la cláusula WHERE casi nunca
se omite, la sentencia UPDATE sin una cláusula WHERE realiza una función útil.
Básicamente efectúa una actualización masiva de toda la tabla, como demuestra el
ejemplo anterior.
Al igual que con la sentencia DELETE, las subconsultas pueden jugar un
papel importante en la sentencia UPDATE ya que permiten seleccionar filas a
actualizar en base a información contenida en otras tablas. He aquí varios ejemplos
de sentencias UPDATE que utilizan subconsultas:
Actualiza la tabla Representante añadiendo 50000 a su
cuota, para los representantes que han hecho pedidos en el
mes de septiembre

UPDATE Representante
SET cuota = cuota + 50000
WHERE dni IN ( SELECT rep
FROM Pedidos
WHERE MONTH(fecha) = 9 );

Aumentar en 10000 la cuota de los representantes si el total
de los pedidos de cada uno de ellos supera su cuota.

UPDATE Representante
SET cuota = cuota + 10000
WHERE cuota > ( SELECT SUM(importe)
FROM Pedidos
WHERE rep = dni );

Aumentar un 10% la cuota de los representantes que tengan más
de tres pedidos en los seis primeros meses del año

UPDATE Representante
SET objetivo = objetivo + objetivo * 0.1
WHERE 3 < ( SELECT COUNT(*)
FROM Pedidos
WHERE rep = dni );

Actualiza la tabla Representantes añadiendo a sus ventas los
importes de los pedidos

UPDATE Representantes
SET ventas = ( SELECT SUM(importe)
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera Z - 30L Pád|ra 125 de 20ê
FROM Pedidos
WHERE rep = dni );
Como en la sentencia SELECT, las subconsultas en la cláusula WHERE de la
sentencia UPDATE pueden anidarse a cualquier nivel, y pueden contener referen-
cias externas a la tabla destino de la sentencia UPDATE. La columna dni en la
subconsulta del ejemplo anterior es una referencia externa; se refiere a la columna
dni en la fila de la tabla Representantes actualmente comprobada por la sentencia
UPDATE.
La misma restricción que se aplicaba a la sentencia DELETE es aplicable
aquí: la tabla destino no puede aparecer en la cláusula FROM de ninguna
subconsulta a ningún nivel de anidación. Esto impide que las subconsultas
referencien la tabla destino (algunas de cuyas filas pueden ya haber sido
actualizadas). Cualesquiera referencias a la tabla destino en las subconsultas son
por tanto referencias externas a la fila de la tabla destino que actualmente está
siendo comprobada por la cláusula WHERE de la sentencia UPDATE.
LENGbAJE DE DEFINICIÓN DE DAIO$: DDL
El DDL (Data Definition Language) es el conjunto de sentencias que está
orientadas a la creación, modificación y configuración de objetos en base de datos.
El DDL es el subconjunto más extenso dentro de SQL así que sólo vamos a
hacer una referencia rápida a algunas sentencias.
Creación de tablas. Sentencia Create Table
Crea una tabla en base de datos. La sintaxis básica es:
CREATE TABLE nombre_tabla(
definición de columna1,
definición de columna2,

definición de columnaN
[definición de constraint1,]
[definición de constraint2,]

[definición de constraintM]
);
La cláusula definición de columna es:
nombre_columna tipo_datos
[NOT NULL|NULL]
[DEFAULT valor predeterminado]
[PRIMARY KEY]
[CHECK expresión lógica]

Cada columna lleva obligatoriamente su tipo de datos. Con NOT NULL se
evita que la columna tome valores núlos. Con DEFAULT valor predeterminado hace
que cada vez que se inserte una fila y no se indique un valor para la columna tome
el que se ha especificado. Con PRIMARY KEY se indica que la columna forma parte
de la clave primaria. Con CHECK expresión lógica se indica una condición que ha de
cumplir el valor de la columna para que sea válido.
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera Z - 30L Pád|ra 12ê de 20ê
La cláusula definición de constraint es:
[PRIMARY KEY (columnas clave primaria)]
[INDEX nombre índice (columnas índice)]
[UNIQUE [INDEX] nombre índice (columnas índice)]
[CONSTRAINT nombre FOREIGN KEY [nombre índice] (columnas
índice) [referencia]
La cláusula referencia es:
REFERENCES nombre tabla [ (columnas índice) ]
[ON DELETE {CASCADE | SET NULL | ... } ]
PRIMARY KEY es similar al anterior, sólo que la definición se hace a nivel de
tabla en lugar de a nivel de columna, pero la intención y los efectos son los
mismos. Con INDEX se crea un índice para la tabla con las columnas especificadas.
Con UNIQUE se crea una restricción para que la columna que no es clave primaria
tome valores únicos. Con la restricción FOREIGN KEY se crea una clave externa
para lo cual hay indicar que columnas de la tabla serán clave externa y a que tabla
están referenciando. Las opciones de clave externa ON DELETE indican las
operaciones que se realizan sobre la tabla referenciada cuando se realiza una
operación de borrado (DELETE) en la tabla. Existe otra opción, ON UPDATE, para lo
mismo, pero en operaciones de actualización (UPDATE). Esta opción, aunque está
contemplada en el estándar ANSI-SQL no la soporta ORACLE, pero sí MySQL.
La sintaxis anterior para CREATE TABLE es muy genérica, pero común a la
mayoría de los SGBD actuales. Cuando se vea en capítulos posteriores la
implementación de algunos de estos, se hará más específica.
La creación de la tabla FACTURA definida anteriormente sería la siguiente en
Oracle:
CREATE TABLE FACTURA(
numero VARCHAR2(10) NOT NULL PRIMARY KEY,
dni INTEGER,
importe NUMBER(9,2),
fecha DATE,
dto NUMBER(5,2),
CONSTRAINT FK_CLIENTE(dni) REFERENCES Cliente(dni)
ON DELETE CASCADE;
Los campos que van a formar parte de la clave se tienen que definir como
NOT NULL ya que no tiene sentido que éstas columnas carezcan de valor. Además
se crea la clave primaria y la clave externa que hace referencia a CLIENTE (como
ya dijimos en el apartado de claves foráneas). Con la cláusula ON DELETE
CASCADE hacemos que si se borra un cliente, se borren automáticamente todas
sus facturas. Hay que tener en cuenta que aunque la clave externa se crea sobre la
tabla FACTURA, también actúa cuando se hacen operaciones sobre CLIENTE.
Creación de índices. Sentencia Create Index
Crea un índice sobre una tabla de base de datos. La sintaxis básica es:
CREATE [UNIQUE] INDEX nombre_índice
ON tabla( columnas_indexadas )
La cláusula UNIQUE actúa como si los campos indexados fuesen clave
primaria, es decir, no permite que el conjunto de campos indexados se repita en la
tabla. Pero pueden darse casos en los que se hagan gran cantidad de consultas por
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera Z - 30L Pád|ra 12Z de 20ê
campos distintos a los de la clave primaria. En este caso es necesario crear un
índice por los campos por lo que se accede.
Por ejemplo, puede ser que en nuestra tabla FACTURA sea muy común
recuperar aquellas facturas de un cierto cliente.
En este caso la consulta SELECT ha realizar sería la siguiente:
SELECT *
FROM Factura
WHERE dni = 1 AND
numero = ‘A111’;
En este caso se está accediendo la tabla FACTURA por campos distintos a la
clave primaria (que es Referencia). Si este tipo de consultas son muy habituales es
necesario crear un índice por estos campos:
CREATE INDEX ind_factura_cliente
ON FACTURA( dni )
No podemos poner la cláusula UNIQUE porque si no, no podríamos insertar
más de una factura por cliente.
Creación de vistas. Sentencia Create View
Una vista (view) es una consulta SELECT almacenada en base de datos con
un cierto nombre. SQL permite acceder a los resultados de esta sentencia como si
fueran una tabla real en la base de datos. Es una tabla virtual cuyos contenidos
están definidos por una consulta. Si tenemos la siguiente consulta:
SELECT Factura.dni, nombre, SUM( importe )
FROM Factura, Cliente
WHERE Factura.dni = Cliente.dni
GROUP BY Factura.dni, nombre ;
Si esta consulta se repite es necesaria muchas veces, entonces podemos
guardar esta definición en base de datos con un nombre (crear una vista), y
después hacer la consulta sobre la vista.
CREATE VIEW TOTAL_FACTURA_CLIENTE AS
SELECT Factura.dni, nombre, SUM( importe )
FROM Factura, Cliente
WHERE Factura.dni = Cliente.dni;
Y después hacer la consulta sobre la vista:
SELECT * FROM TOTAL_FACTURA_CLIENTE;
La sintaxis de creación de vista es:
CREATE VIEW nombre_vista [(lista_columnas)] AS
Subconsulta;
La sentencia asigna un nombre a la vista y especifica la consulta que define
la vista. Para crear la vista con éxito, es preciso tener permiso para acceder a todas
las tablas referenciadas en la consulta.
La sentencia CREATE VIEW puede asignar opcionalmente un nombre a cada
columna en la vista recien creada. Si se especifica una lista de nombres de
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera Z - 30L Pád|ra 128 de 20ê
columnas, debe tener el mismo número de elementos que el número de columnas
producido por la consulta. Sólo hay que especificar los nombres de las columnas, el
tipo de datos, la longitud y las otras características de cada columna se deducen de
la definición de las columnas en las tablas fuente. Si la lista de nombres de
columnas se omite de la sentencia CREATE VIEW, cada columna de la vista adopta
el nombre de la columna correspondiente de la consulta. La lista de nombres de
columnas debe ser especificada si la consulta incluye columnas calculadas o si
produce dos columnas con nombres idénticos.
Si una vista incluye una sentencia que restringe el número de filas a las que
se pueden acceder, entonces es una vista horizontal. Por ejemplo, la siguiente vista
solo accede los clientes ordenados alfabéticamente por nombre.
CREATE VIEW Cli_Ord AS
SELECT * FROM Cliente
ORDER BY nombre;
Si la vista restringe el acceso a ciertas columnas de una tabla, entonces
se denomina vista vertical. Por ejemplo, la siguiente vista ofrece solo el dni y el
nombre de los clientes que tienen facturas y además les asigna nuevos nombres
a las columnas.
CREATE VIEW Cli_Fac AS
SELECT dni, nombre (nif, razon_social)
FROM Cliente WHERE dni IN ( SELECT DISTINCT dni
FROM Factura );
Si quisieramos hacer una SELECT de esta vista, tendríamos que especificar
como nombres de columnas las definidas en la lista, no en la tabla fuente.
SELECT nif, razon_social
FROM Cli_Fac;
Cuando la sentencia SELECT de la vista incluye una cláusula GROUP BY se
denomina vista agrupada. Por ejemplo, crear una vista con el dni del cliente,
nombre e importe total de sus facturas.
CREATE VIEW Cli_Fac AS (dni, nombre, total)
SELECT dni, nombre, SUM(importe)
FROM Cliente
INNER JOIN Factura ON Cliente.dni = Factura.dni
GROUP BY dni, nombre;
Cuando la vista incluye una sentencia SELECT con dos o más tablas, se
denomina vista compuesta.
Una vista puede ser actualizable, es decir, se pueden realizar operaciones
INSERT, UPDATE o DELETE. Para algunas vistas estas operaciones pueden ser
traducidas obviamente a operaciones equivalentes respecto a las tablas fuente de
la vista, pero si la vista tiene más de una tabla fuente o contiene una columna
calculada no es actualizable, es de sólo lectura. En los ejemplos anteriores, la vista
Cli_Ord solamente restringe filas y sólo tiene una tabla fuente, entonces podríamos
hacer un INSERT a la vista
INSERT INTO Cli_Ord
VALUES( 10, ‘Ernesto’, ‘Martínez Segura’, ‘c/ Mayor, 111’,
‘Madrid’, 28010);
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera Z - 30L Pád|ra 129 de 20ê
Sin embargo, la vista Cli_Fac contiene una columna agrupada, por tanto no
hay una correspondencia de un valor de la columna con un valor en la columna
origen de la tabla fuente como para poder hacer una actualización de datos.
Para que una vista también pueda ser actualizable es necesario que sus
datos provengan de una sola tabla, pero además las columnas que no incluyen de
esta tabla debe poder admitir valores NULL, ya que de lo contrario al hacer un
INSERT sobre la vista solamente podemos especifica datos sobre las columnas de la
vista (y consecuentemente, sobre las columnas subyacentes), pero no sobre
columnas de la tabla origen que no se hayan especificado en la definición de la
vista.
Además, si incluimos en la sentencia SELECT de la vista la cláusula WHERE
es posible que los datos nuevos introducidos no cumplan la condición, con lo que al
hacer una SELECT de la vista, estos datos nuevos no aparecerán. Por ejemplo,
supongamos una vista con los clientes de Córdoba.
CREATE VIEW Cli_Cor AS
SELECT *
FROM Cliente
WHERE población = ‘Córdoba’;
Si hacemos un INSERT con un cliente donde la columna población se le
asigne el valor 'Madrid´, la vista aceptará la operación e insertará en la tabla Cliente
el nuevo cliente, pero al hacer un SELECT sobre la vista, este nuevo cliente no
aparece porque no cumple la condición. Para evitar que una vista acepte datos que
no cumple la condición de su sentencia SELECT asociada se puede definir con la
cláusula WITH CHECK OPTION. La vista anterior se definiría así
CREATE VIEW Cli_Cor AS
SELECT *
FROM Cliente
WHERE población = ‘Córdoba’
WITH CHECK OPTION;
Si ahora tratamos de hacer una actualización sobre la vista y los datos
nuevos no cumplen la condición, SQL rechaza la operación.
Borrado de tablas, índices y vistas
Para borrar una tabla se utiliza la sentencia DROP TABLE. La sintaxis es
DROP TABLE nombre_tabla;
Cuando se suprime una tabla de la base de datos, su definición y todos sus
contenidos se pierden. No hay manera de recuperar los datos. Debido a sus serias
consecuencias, debe utilizarse con mucho cuidado.
Para borrar un índice se utiliza la sentencia DROP INDEX. Su sintaxis es
DROP INDEX nombre_indice;
El índice que se borra cuando se considera que ya no es necesario.
Para borrar la definición de una vista se emplea la sentencia DROP VIEW. Su
sintaxis es:
DROP VIEW nombre_vista;
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera Z - 30L Pád|ra 130 de 20ê
Recordemos que una vista es una sentencia SELECT con nombre, por lo
tanto lo que se pierde es la definición de la vista, no los datos subyacentes.
Naturalmente es necesario tener los permisos necesarios para poder borrar
estos tres objetos de una base de datos.
Modificación de una definición de tabla. Sentencia ALTER TABLE
Después que una tabla ha sido utilizada durante algún tiempo, los usuarios
suelen descubrir que desean almacenar información adicional con respecto a las
entidades representadas en la tabla.
Cada uno de estos cambios, y algunos otros, pueden ser realizados con la
sentencia ALTER TABLE. Con el permiso adecuado se puede alterar la definición de
la tabla. La sentencia ALTER TABLE puede:
• Añadir una definición de columna a una tabla.
• Definir una clave primaria para una tabla.
• Definir una nueva clave foránea para una tabla.
• Eliminar una clave primaria o foránea existente para una tabla.
Cada SGBD ofrece cláusulas propias que alteran otras características de las
tablas. La siguiente sintaxis cubre las más comunes.
ALTER TABLE tabla
| ADD [COLUMN] declaración_columna
| ADD INDEX nombre_índice (columnas índice)
| ADD PRIMARY KEY (columnas_índice)
| ADD UNIQUE nombre_índice (columnas_índice)
| DROP [COLUMN] nombre_columna
| DROP INDEX nombre_índice (lista_columnas)
| DROP PRIMARY KEY
| MODIFY [COLUMN] declaración_columna
| RENAME [AS] nombre
_
tabla_nueva
| ADD [CONSTRAINT [nombre_restricción]]
PRIMARY KEY (columnas_índice)
| ADD [CONSTRAINT [nombre_restricción]]
UNIQUE (columnas_indice)
| ADD [CONSTRAINT [nombre_restricción]]
FOREIGN KEY (columnas_indice)
[referencia]
El uso más común de la sentencia ALTER TABLE es añadir una columna a
una tabla existente. La cláusula de definición de columna en la sentencia ALTER
TABLE es virtualmente idéntica a la de la sentencia CREATE TABLE, y funciona del
mismo modo. La nueva columna se añade al final de las definiciones de columna de
la tabla, y aparece como la columna más a la derecha en consultas posteriores. Se
asume normalmente un valor NULL para la columna recién añadida en todas las
filas existentes de la tabla. Por ejemplo
ALTER TABLE Cliente
ADD COLUMN persona_contacto VARCHAR(50);
Si la columna se definió como NOT NULL, entonces es altamente
recomendable que se defina un valor por defecto ya que de lo contrario es posible
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera Z - 30L Pád|ra 131 de 20ê
que el SGBD concreto añada como valor de la nueva columna en todas las filas un
valor por defecto en función de su tipo de datos.
Si queremos añadir un índice a la tabla Cliente por la columnas nombre.
ALTER TABLE Cliente
ADD INDEX (nombre);
Para borrar la columna importe de la tabla Factura.
ALTER TABLE Factura
DROP COLUMN importe;
Si no tuviera creada una referencia entre la tabla Cliente y la tabla Factura
podría añadirla así
ALTER TABLE Factura
ADD CONSTRAINT fk_factura FOREIGN KEY (dni) REFERENCES
Cliente(dni) ON DELETE RESTRICT ON UPDATE CASCADE;
Si necesitara cambiar el nombre a la tabla Cliente
ALTER TABLE Cliente RENAME AS Cli;
$EGbkIDAD $QL
El esquema de seguridad en una base de datos se basa en tres conceptos
principales:
1. Los usuarios son actores de la base de datos. Cada vez que el SGBD
realiza una operación en la base de datos, lo hace a cuenta de un
usuario. El SGBD permitirá o prohibirá la operación dependiendo de qué
usuario esté efectuando la petición.
2. Los objetos de la base de datos son los elementos a los cuales se puede
aplicar la proteccion de seguridad SQL. La seguridad se aplica
generalmente a tablas y vistas. La mayoría de los usuarios tendrán
permiso para utilizar ciertos objetos de la base de datos, pero tendrán
prohibido el uso de otros.
3. Los privilegios son las acciones que un usuario tiene permitido efectuar
para un determinado objeto de la base de datos. Un usuario puede tener
permiso para SELECT o INSERT sobre filas en una tabla determinada,
por ejemplo, pero puede carecer de permiso para DELETE o UPDATE filas
de la tabla. Un usuario diferente puede tener un conjunto diferente de
privilegios.
Para establecer un esquema de seguridad en una base de datos, se utiliza la
sentencia GRANT para especificar qué usuarios tienen que privilegios sobre qué
objetos de la base de datos. Una vez concedidos privilegios pueden ser rescindidos
más arde con la sentencia REVOKE.
Asignar privilegios. Sentencia GRANT
La sentencia GRANT se utiliza para conceder privilegios de seguridad sobre
objetos de la base de datos a usuarios específicos. Su sintaxis es:
GRANT privilegio [(lista_col)] [, privilegio [(lista_col)]]…
ON tabla TO usuario [, usuario]…
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera Z - 30L Pád|ra 132 de 20ê
[WITH GRANT OPTION]
Como se indica en la sintaxis la sentencia GRANT incluye una lista de
privilegios separadas por comas sobre una tabla y a una lista de usuarios. Los
privilegios básicos establecidos por el estándar ANSI/ISO SQL son: SELECT,
INSERT, UPDATE y DELETE. Cada SGBD tiene sus propias listas de privilegios,
además de estas.
Por ejemplo, si se concede al usuario rafa los privilegios de SELECT y
UPDATE sobre la tabla Cliente, se escribiría una sentencia así
GRANT SELECT, UPDATE ON Cliente TO rafa;
Si se quiere conceder privilegio de borrado a los usuarios maria y rafa en la
tabla Facturas
GRANT DELETE ON Facturas TO maria, rafa
Si se utiliza la opción WITH GRANT OPTION da la posibilidad al usuario al
que se le concede el privilegio de concederlo a su vez a otros usuarios. Por
ejemplo, se concede el privilegio de INSERT al usuario rafa sobre la tabla Cliente y
que este usuario pueda a su vez, concederlo a otros usuarios.
GRANT INSERT ON Cliente TO rafa WITH GRANT OPTION;
Para la operación UPDATE, que puede realizarse a nivel de columna se
puede especificar privilegios de actualización para columnas específicas de una
tabla. Habría que encerrar entre paréntesis separadas por comas las columnas a las
cuales se concede privilegio de actualización. Por ejemplo, para conceder privilegio
UPDATE al usuario rafa sobre la tabla Facturas en la columna importe se escribiría
lo siguiente
GRANT UPDATE (importe) ON Facturas TO rafa;
Revocación de privilegios. Sentencia REVOKE
Los privilegios concedidos con la sentencia GRANT pueden ser retirados con
la sentencia REVOKE. Su sintaxis es:
REVOKE privilegio [, privilegio ]…
ON tabla FROM usuario [, usuario]…
Por ejemplo, para retirar los privilegios de selección y actualización sobre la
tabla Cliente al usuario rafa
REVOKE SELECT, UPDATE ON Cliente FROM rafa;
En el caso de que ser retiren privilegios que se han concedido con la opción
WITH GRANT OPTION, si el usuario al que se le concedió, los pasó a otro usuario, a
este también se les retiraría. Por ejemplo, si se retira el privilegio de inserción al
usuario rafa sobre la tabla Cliente y el usuario rafa concedió este privilegio al
usuario maria, con esta sentencia también se le retira el privilegio a maria.
REVOKE INSERT ON Cliente FROM rafa;
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera Z - 30L Pád|ra 133 de 20ê
FbNCIONE$ $QL EN OkACLE
Las funciones SQL permiten mostrar columnas calculadas dentro de
sentencias DML (SELECT, INSERT, DELETE y UPDATE).
Funciones de tratamiento numérico
Función Descripción
ABS( n ) Retorna el valor absoluto del parámetro.
CEIL( n ) Retorna el entero mayor del parámetro.
FLOOR( n ) Retorna el entero menor del parámetro.
MOD( m,n ) Retorna el resto de la división m/n
POWER( m,n ) Retorna mn
ROUND( m[,n] ) Retorna m, redondeado a n decimales. Si m se omite es 0.
SIGN( n ) Retorna 1 si n es positivo, -1 si negativo y 0 si es 0.
TRUNC( n[,m] ) Trunca un número a m decimales. Si m se omite es 0.
Funciones de tratamiento alfanumérico
Función Descripción
CHR( n ) Retorna el carácter equivalente al código n en la tabla de
conjunto de caracteres utilizado (ASCII, UNICODE...)
CONCAT( s1, s2 ) Concatena dos cadenas de caracteres. Equivalente al operador
||
INITCAP( s ) Pasa el mayúscula la primera letra de cada palabra
LOWER( s ) Pasa a minúsculas toda la cadena de caracteres
LPAD( s, n ) Retorna los n primeros caracteres de la cadena s.
RPAD( s, n ) Retorna los n últimos caracteres de la cadena s.
LTRIM( s1[, s2] ) Elimina todas las ocurrencias de s2 en s1 por la izquierda. Si se
omite s2, se eliminarán los espacios.
RTRIM( s1[, s2] ) Elimina todas las ocurrencias de s2 en s1 por la derecha. Si se
omite s2, se eliminarán los espacios.
REPLACE( s1, s2,
s3 )
Retorna s1 con cada ocurrencia de s2 reemplazada por s3.
SUBSTR( s, m, n ) Retorna los n caracteres de s desde la posición m.
UPPER( s ) Pasa a mayúsculas toda la cadena de caracteres
LENGTH( s ) Retorna la longitud (en caracteres) de la cadena pasada.
Funciones de tratamiento de fechas
Función Descripción
ADD_MONTHS( d, n ) Suma un número (positivo o negativo) de meses a
una fecha.
LAST_DAY( d ) Retorna el ultimo día de mes de la fecha pasada.
MONTHS_BETWEEN( d1, d2 ) Retorna la diferencia en meses entre dos fechas.
ROUND( d, s ) Redondea la fecha d según el formato indicado en s.
(*)
TRUNC( d, s ) Trunca la fecha d según el formato indicado en s.
(*)
Formatos para ROUND y TRUNC para fechas:
Formato Descripción
`MONTH´, `MON´, `MM´ Principio de mes
`DAY´, `DY´, `D´ Principio de semana
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera Z - 30L Pád|ra 131 de 20ê
`YEAR´, `YYYY´, `Y´ Principio de año
Funciones de conversión
Función Descripción
CHARTOROWID( s ) Convierte una cadena en tipo de dato ROWID.
ROWIDTOCHAR( rowid ) Convierte un tipo de dato ROWID en cadena de
caracteres.
TO_CHAR( *[, s] ) Convierte el tipo de dato * en cadena de caracteres. Si
* es una fecha, se podrá utilizar la cadena s como
formato de conversión.
TO_DATE( s1[, s2] ) Convierte la cadena s1 en fecha, conforme al formato
de convesión s2.
TO_NUMBER( s ) Convierte una cadena de caracteres en valor numérico.
Otras funciones
Función Descripción
DUMP( columna ) Retorna información de almacenamiento
para la columna indicada.
GREATEST( expr1, expr2, ... exprN ) Retorna la expresión mayor.
LEAST( expr1, expr2, ... exprN ) Retorna la expresión menor.
NVL( expr1, expr2 ) Retorna expr2 si expr1 es NULL, sino
retorna expr1.
USEREVN( s ) Retorna opciones de entorno de la sesión
activa. Los valores para s pueden ser:
`ISDBA´: Retorna `TRUE´ si el usuario
activo tiene el rol DBA.
`LANGUAGE´: Idioma activo.
`TERMINAL´: Nombre de terminal donde
se realiza la consulta.
`SESSIONID´: Número de sesión activa.

DECODE( expr_ev, Caso_1, ret_1,
Caso_2, ret_2, ... Caso_N, ret_N,
Caso_else )
Permite hace una evaluación de valores
discretos. Es similar a la estructura switch
de C/C++ o case of de Pascal.
Ejemplo:
DECODE( COLOR,
‘R’, ‘Rojo’,
‘V’, ‘Verde’,
‘A’, ‘Azul’,
‘Color desconocido’ )
FbNCIONE$ $QL EN MY$QL
Las funciones que dispone MySQL son las siguientes:
Funciones de cadena
Función Descripción
ASCII(cadena) Devuelve el código ASCII del carácter más a la izquierda
de la cadena.
CHAR(n) Devuelve el carácter cuyo código ASCII es n.
CHAR(n,m,.) Devuelve y concatena los caracteres de códigos ASCII
n, m, .
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera Z - 30L Pád|ra 135 de 20ê
BIN(n) Devuelve n en forma binaria.
COALESCE(exp1, exp2,
.)
Devuelve el primer elemento no nulo de una lista de
expresiones.
CONCAT(cad1, cad2,.) Concatena las cadenas dadas.
ELT(n, cad1, cad2, .) Devuelve la cadena enésima de la lista.
FIELD(cad, cad1, cad2,
.)
Busca la cadena cad en la lista de cadenas y devuelve la
posición de su primer elemento.
CONV(n, base1, base2) Convierte el número n de base1 a base2.
FORMAT(n,d) Formatea el número n en una cadena de d posiciones
decimales tipo nn,nnn.nnn.
HEX(n) Da el número n en hexadecimal.
OCT(n) Da el número n en octal.
INSERT(cadena, posición,
l, subcadena)
Se inserta cadena, a partir de la posición dada, los
primeros l caracteres de la subcadena.
LCASE(cadena) o
LOWER(cadena)
Convierte la cadena a minúsculas.
UCASE(cadena) o
UPPER(cadena)
Convierte la cadena a mayúsculas.
LEFT(cadena, n) Da los n caracteres más a la izquierda de la cadena.
RIGHT(cadena, n) Da los n caracteres más a la derecha de la cadena.
LOCATE(subcadena,
cadena, n)
Da la posición de la primera ocurrencia de la subcadena
en la cadena empezando a buscar a partir de la posición
n en la cadena. Si n no se especifica, se empieza a
buscar en la primera posición de la cadena.
LENGHT(cadena) Devuelve el número de caracteres de la cadena.
LPAD(cadena, l, cadena1) Añade cadena1 a la izquierda de cadena las veces que
sea necesario hasta que la cadena resultante tenga l
caracteres.
LTRIM(cadena) Devuelve la cadena después de quitar los espacios en
blanco de la izquierda.
MID(cadena, posición, n) Da la subcadena de la cadena que comienza en la
posición dada y que tiene una longitud de n caracteres.
POSITION(subcadena,
cadena)
Da la posición de la primera ocurrencia de la subcadena
en la cadena empezando a buscar a partir de la primera
posición de la cadena. Es equivalente a
LOCATE(subcadena,cadena).
REPEAT(cadena, n) Repite la cadena n veces.
REPLACE(cad1, cad2,
cad3)
Reemplaza por la tercera cadena todas las apariciones
de la segunda cadena en la primera cadena.
REVERSE(cadena) Devuelve la cadena invertida.
RPAD(cadena,l,cadena1) Añade cadena1 a la derecha de cadena las veces que
sea necesario hasta que la cadena resultante tenga l
caracteres.
RTRIM(cadena) Devuelve la cadena de caracteres después de truncar
todos los espacios en blanco a la derecha.
SOUNDEX(cadena) Devuelve la cadena tipo SOUNDEX relativa a la cadena
dada (busca palabras parecidas a la cadena).
SPACE(n) Devuelve una cadena de espacios en blanco repetidos n
veces.
SUBSTRING(cadena, n) Devuelve la parte de la cadena que va desde la posición
n hasta su final.
SUBTRING(cadena, n, m) Devuelve m caracteres de la cadena a partir del carácter
n.
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera Z - 30L Pád|ra 13ê de 20ê
Funciones numéricas
Función Descripción
ABS(a) Valor absoluto de a.
ASIN(a) Arco seno de a (en radianes).
ACOS(a) Arco coseno de a (en radianes).
ATAN(a) Arco tangente de a (en radianes).
ATAN2(a) Ángulo (en radianes) con tangente en el cuadrante dado
por a y b.
CEILING(a) Entero más pequeño mayor o igual que a.
COS(a) Coseno de a (en radianes).
COT(a) Cotangente de a (en radianes).
DEGREES(n) Pasa a grados n radianes.
EXP(a) Número e elevado al exponente a.
FLOOR(a) Mayor entero menor o igual que a.
LOG(a) Logaritmo neperiano de a.
LOG10(a) Logaritmo decimal de a.
PI() Valor del número π.
POWER(a,b) o POW(a,b) Halla a elevado a b.
RADIANS(n) Pasa a radianes n grados.
RAND() Devuelve un número aleatorio entre 0.0 y 1.
RAND(semilla) Devuelve un número aleatorio entre 0.0 y 1 con la
semilla dada.
ROUND(a) Redondea a al entero más próximo.
ROUND(a,b) Redondea a con precisión b (con b posiciones
decimales).
SIGN(a) Vale 1 si a es positivo o cero, y -1 si a es negativo.
SIN(a) Seno de a.
SQRT(a) Raíz cuadrada de a.
TAN(a) Tangente de a.
TRUNCATE(a,b) Devuelve a con su parte decimal truncada a b
posiciones decimales. Si b es cero, el resultado no tiene
parte fraccionaria. Si b es mayor que el número de
decimales en a, la parte fraccionaria se rellena con
ceros hasta la cantidad necesaria.
Funciones de fecha y hora
Función Descripción
DAYNAME(fecha) Devuelve una cadena con el día de la semana relativo a
la fecha.
DAYOFMONTH(fecha) Devuelve un número entre 1 y 31 relativo al día del mes
para la fecha.
DAYOFYEAR(fecha) Devuelve un número entre 1 y 366 relativo al día del
año para la fecha.
DAYOFWEEK(fecha) Devuelve un número entre 1 y 7 relativo al día de la
semana para la fecha.
HOUR(hora) Devuelve un entero entre 0 y 23 que representa la
parte entera de la hora especificada.
MINUTE(hora) Devuelve un entero entre 0 y 59 que representa los
minutos de la hora especificada.
SECOND(hora) Devuelve un entero entre 0 y 59 que representa los
segundos de la hora especificada.
MONTH(fecha) Devuelve un entero entre 1 y 12 que representa el mes
de la fecha dada.
MONTHNAME(fecha) Devuelve una cadena con el nombre del mes de la fecha
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera Z - 30L Pád|ra 13Z de 20ê
especificada.
QUARTER(fecha) Devuelve un entero entre 1 y 4 que representa el
trimestre de la fecha dada.
WEEK(fecha) Devuelve un entero entre 0 y 52 que representa la
semana de la fecha dada (las semanas empiezan en
domingo).
WEEK(fecha, n) Devuelve un entero entre 0 y 52 que representa la
semana de la fecha dada (las semanas empiezan en
domingo si n=0 y empiezan en lunes si n=1).
WEEKDAY(fecha) Devuelve un entero entre 0 (lunes) y 6 (domingo) que
representa el día de la semana de la fecha dada.
YEAR(fecha) Devuelve un entero entre 1000 y 9999 que representa
el año de la fecha dada.
TO_DAYS(fecha) Devuelve un entero que da el número de días entre el
año 0 y la fecha dada.
NOW() o SYSDATE() Da una cadena con la fecha y la hora actual en formato
AAAAMMDDhhmmss.
CURDATE() o
CURRENT_DATE()
Da una cadena con la fecha actual en formato AAAA-
MM-DD
CURTIME() o
CURRENT_TIME()
Devuelve una cadena con la hora actual en formato
hhmmss.
DATE_FORMAT(fecha,
formato)
Devuelve la fecha en el formato dado. Los formatos
posibles son %S, %s, %H, %h, %i, %I, %k, %l, %T,
%r, %p, %W, %a, %d, %D, %e, %w, %j, %U, %u,
%M, %m, %b, %c, %y, %Y, %%.
FROM_DAYS(n) Devuelve la fecha relativa al entero n (número de días
desde el año 0).
TO_DAY(fecha) Devuelve el entero n (número de días desde el año 0)
correspondiente a la fecha.
DATE_ADD(fecha,
INTERVAL n tiempo) o
ADDDATE(fecha,
INTERVAL n tiempo)
Añade n unidades de tiempo a la fecha dada. Los
posibles valores de tiempo son: SECOND, MINUTE,
HOUR, DAY, MONTH, YEAR, MINUTE_SECOND,
HOUR_MINUTE, HOUR_SECOND, DAY_HOUR,
DAY_MINUTE, DAY_SECOND, YEAR_MONTH.
DATE_SUB(fecha,
INTERVAL n tiempo) o
SUBDATE(fecha,
INTERVAL n tiempo)
Resta n unidades de tiempo a la fecha dada. Los
posibles valores de tiempo son los anteriores
EXTRACT(tiempo FROM
fechahora)
Da la parte de la fecha hora especificada en tiempo. Los
posibles valores de tiempo son los anteriores.
PERIOD_ADD(periodo, n) Añade n meses al valor periodo.
PERIOD_DIFF(periodo1,
periodo2)
Halla la diferencia de los dos periodos.
SEC_TO_TIME(segundos) Devuelve la hora relativa al número de segundos dado.
TIME_TO_SEC(hora) Devuelve el número de segundos relativo a la hora
dada.
TIME_FORMAT(hora,
formato)
Devuelve la hora en el formato dado. Los formatos
posibles son los mismos que para DATE_FORMAT.
Funciones de comparación
Función Descripción
GREATEST(exp1, exp2,
.)
Devuelve el argumento de mayor valor de la secuencia.
LEAST(exp1, exp2, . ) Devuelve el argumento menor de la secuencia.
IF(exp1, ex2, exp3) Devuelve exp2 si exp1 es verdadero y da exp3 si exp1
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera Z - 30L Pád|ra 138 de 20ê
es falso.
IFNULL(exp1, exp2) Devuelve exp2 si exp1 es NULL y da exp1 en caso
contrario.
INTERVAL(n, n1, n2, .) Da cero si n < n1, uno si n < n2 y así sucesivamente.
Da -1 si n es NULL.
ISNULL(exp) Devuelve 1 si exp es NULL y da 0 en caso contrario.
STRCMP(cadena1,
cadena2)
Devuelve 1 si cadena1 = cadena2, da 0 si son
diferentes y NULL si cualquier elemento es NULL.
Miscelánea de funciones
Función Descripción
BENCHMARK(n, exp) Evalúa exp recursivamente n veces. Aunque siempre da
0, lo interesante es la información que aparece en la
última línea de la salida indicando el tiempo de
ejecución de la consulta.
DATABASE() Da el nombre de la base de datos actual.
ENCODE(cad,
contraseña)
Codifica como la cadena cad la contraseña.
DECODE(cad,
contraseña)
Decodifica la cadena cad en que se ha codificado
previamente la contraseña.
ENCRIPT(cad) Encripta la cadena cad de modo irreversible.
GET_LOCK(cad, tiempo) Realiza un bloque con aviso de nombre la cadena cad y
con el tiempo de desconexión especificado.
REALEASE_LOCK(cad) Desbloquea el bloque con aviso de nombre la cadena
cad.
LAS_INSERT_ID() Da el valor AUTO_INCREMENT que se generó más
recientemente durante la sesión con el servidor actual.
LAST_INSERT_ID(exp) Utilizada con la sentencia UPDATE, sitúa exp como el
valor AUTO_INCREMENT más recientemente para la
sesión con el servidor actual.
LOAD_FILE(fichero) Lee el fichero especificado y devuelve su contenido
como una cadena.
Md5(cad) Calcula la suma de control de la cadena cad basada en
el algoritmo MD5 RSA. Devuelve una cadena de 32
dígitos hexadecimales.
PASSWORD(cad) Codifica la cadena cad según las tablas de privilegios de
MySQL de modo irreversible.
USER(),
SESSION_USER() o
SYSTEM_USER()
Da el nombre del usuario actual de la base de datos.
VERSION() Da la versión actual del servidor MySQL.

lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 8 -Vv30L Pád|ra 139 de 20ê
8
Hy80L
INIkODbCCIÓN
MySQL es un sistema gestor de bases de datos relacionales, que además
ofrece compatibilidad con PHP, Perl, C y HTML, y funciones avanzadas de
administración y optimización de bases de datos para facilitar las tareas habituales.
Implementa funcionalidades Web, permitiendo un acceso seguro y sencillo a los
datos a través de Internet. Este sistema gestor de base de datos incluye
capacidades de análisis integradas, servicios de transformación y duplicación
de datos y funciones de programación mejoradas.
Se puede decir que MySQL es un sistema cliente servidor de administración
de bases de datos relacionales diseñado para el trabajo tanto en los sistemas
operativos Windows como en los sistemas UNIX/LINUX. Además, determinadas
sentencias de MySQL pueden ser embebidas en código PHP y HTML para diseñar
aplicaciones Web dinámicas que incorporan la información de las tablas de MySQL a
páginas Web. Asimismo, MySQL es compatible con el software más potente de
diseño Web, como Dreamweaver MX.
En estos apuntes se presenta un análisis profundo de la base de datos
MySQL en su versión más actual. Se comienza viendo la instalación del programa,
la introducción del trabajo en los distintos entornos de MySQL y el desarrollo amplio
del modelo relacional a través de SQL, que se trata detalladamente. Se incide
especialmente en el uso de SQL para definición, consulta, creación, control y
modificación de bases de datos relacionales. Asimismo, se desarrollan de forma
exhaustiva todas las tareas relativas a la administración de la base de datos,
incluyendo la administración de servidores, la administración de la seguridad, la
duplicación y la importación de datos.
IN$IALACIÓN DE MY$QL EN WINDOW$
Para instalar el servidor de MySQL en una plataforma Windows NT/2000/XP
hay que seguir los siguientes pasos:
1. Descargar de la página web de MySQL la versión más actual de
MySQL cliente-servidor para Windows.
2. Desempaquetar el fichero .zip descargado.
3. Ejecutar el fichero setup.exe
4. Hacer clic sobre el botón Next para pasar las pantallas informativas
hasta llegar a la pantalla que elige el tipo de instalación.
5. Elegir la instalación Typical (típica) o Custom (personalizada), donde
podremos elegir las opciones de la instalación. Hacer clic en Next.
6. El proceso de instalación copiará los ficheros en el directorio
C:\mysql.
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 8 -Vv30L Pád|ra 110 de 20ê
Una vez se ha instalado, hay que construir el archivo my.ini en el directorio
C:\windows para lo cual se utilizará la herramienta WinMySQLAdmin.exe que se
encuentra en C:\mysql\bin. Al ejecutarla detecta que no existe un archivo
C:\windows\my.ini y aparece la siguiente pantalla:

Figura 1. Ventana de usuario para WinMySQLAdmin
Como se puede observar, hay que introducir el nombre de usuario y la
contraseña que se almacenarán como opciones de configuración en el archivo
my.ini. Este usuario deberá estar registrado en el servidor, ya que de lo contrario el
sistema utilizará el usuario ODBC que se crea automáticamente durante la
instalación y sin contraseña.
Además, esta herramienta va a crear automáticamente un servicio para que
al arrancar el ordenador, el servidor MySQL esté activo y esperando solicitudes.
Comprobación de la instalación
Podemos comprobar si la instalación ha sido correcta ejecutando el fichero
mysqlshow.exe que está en el directorio C:\mysql\bin. Al hacerlo tiene que
aparecer en pantalla las bases de datos actuales que hay en el sistema. MySQL por
defecto crea dos bases de datos: mysql y test.
Además, si observamos el cuadro de control, veremos el icono de la
herramienta WinMySQLAdmin. Si está el semáforo en verde, significa que todo está
correcto. Si el semáforo está en rojo significa que el servidor está parado o hay
algún tipo de problema.
El icono anterior, también sirve para parar el servidor, mostrar la
herramienta WinMySQLAdmin, parar el servicio, instalarlo, quitarlo, modificar el
archivo my.ini, etc.
Sin pinchamos en el icono aparece un pequeño menú con dos opciones:
1. Show me.- Muestra la herramienta.
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 8 -Vv30L Pád|ra 111 de 20ê
2. WinNt.- Con las opciones de parar el servicio, terminar la ejecución
de WinMySQLAdmin, quitar el servicio. Si el servicio no existe, está
última opción será instalar el servicio.
Si elegimos la opción Show me aparece una pantalla como la siguiente:

Figura 2. Ventana WinMySQLAdmin
Con esta herramienta podemos monitorizar el estado del servidor. Como se
puede observar aparece información relativa al mismo. Desde aquí existe la
posibilidad de editar el archivo my.ini, ver las estructuras de las bases de datos
existentes, comprobar el valor de las variables de entorno, etc.
Para poder tener siempre la herramienta en ejecución cuando se arranca el
ordenador, podemos indicar desde aquí que cree un acceso directo en el menú
inicio. Para ello pinchamos en la pestaña de my.ini Setup y luego en el botón
Create ShortCut on Star Menu.
Interfaz en línea de comandos
Aunque existen herramientas GUI para introducir comandos SQL y otros
comandos del servidor, la instalación de MySQL solamente suministra una
aplicación para gestionar las bases de datos que consiste en un intérprete de
mandatos (parecido al command.com de MS-DOS) donde el usuario puede
introducir comandos y presenta los resultados con una interfaz textual bastante
pobre.
Para ejecutar el interfaz en línea de comandos hay que abrir una ventana
MS-DOS, situarse en el directorio C:\mysql\bin y ejecutar mysql -u root. Con la
opción -u root le decimos que el usuario que se conecta es el root. Tiene que
aparecer una pantalla como la de la figura. Se puede observar que el prompt de la
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 8 -Vv30L Pád|ra 112 de 20ê
interfaz en línea es mysql> y está a la espera de sentencias SQL para manipular la
información de las bases de datos que gestiona el servidor.

Figura 3. Interfaz en línea de comandos SQL
Como se puede observar, la conexión al servidor por parte del usuario root
no ha necesitado contraseña. Esto es porque inicialmente el usuario se crea sin
contraseña para que el administrador del sistema ponga la que quiera.
Una vez instalado MySQL, la primera operación que hay que hacer es
establecer la contraseña del usuario root. Este usuario es el administrador del
sistema, tanto del servidor de base de datos como de las distintas bases de datos
que se crean y utilizan el resto de usuarios. Este usuario se crea automáticamente
al crearse la instancia del servidor y lo hace sin contraseña. Para establecer la
contraseña se teclea el siguiente comando:
set password = password('contraseña');
Naturalmente, hay que sustituir contraseña por la contraseña que
queramos poner. A partir de entonces cualquier conexión que se haga con el
usuario root tendrá que hacerse con la contraseña establecida. Si nos salimos de la
interfaz en línea de comandos, con el comando exit o quit, y volvemos a entrar,
tendremos que hacerlo con mysql -u root -p y después de introducir la
contraseña correcta estaremos en condiciones de trabajar con el servidor.
IN$IALACIÓN DE MY$QL EN LINbX
Instalación de una distribución binaria
Para UNIX/Linux existen dos opciones para instalar una distribución binaria.
Una es con un paquete rpm y la otra es con un archivo empaquetado. En el primer
caso el archivo a instalar sería MySQL-sever-VERSION.i386.rpm para el servidor y
MySQL-client-VERSION.i386.rpm para el cliente. En el segundo caso el archivo
único es mysql-version_plataforma.tar.gz.
En el primer caso se ejecutará la utilidad de instalación de paquetes rpm
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 8 -Vv30L Pád|ra 113 de 20ê
rpm –i nombre_paquete
Si el ordenador será el servidor de la base de datos se usará el primer
archivo y si es sólo cliente se utilizará el segundo. Los datos de las versiones RPM
se sitúan en /var/lib/mysql. También crean las entradas apropiadas en /etc/init.d,
para iniciar el servidor automáticamente.
El segundo tipo de instalación es algo más complejo, ya que se hace
manualmente. Los pasos a seguir son los siguientes:
1. Abrir una ventana de terminal como root y cambiar al directorio
/usr/local. Aquí será donde se instala MySQL.
2. Crear el grupo mysql con el comando groupadd mysql.
3. Crear el usuario mysql con el commando useradd -g mysql mysql
4. Copiar el fichero mysql-version_plataforma.tar.gz al directorio /usr/local
5. Desempaquetar el fichero con el commando gunzip < /usr/local/mysql-
version_plataforma.tar.gz | tar xvf -
6. Al desempaquetar se habrá creado un directorio con el mismo nombre
que el fichero pero sin la extensión tar.gz. Para hacer referencia a este
directorio es conveniente crear un enlace simbólico con el nombre mysql.
Para ello ejecutar el comando ln -s /usr/local/ mysql-version_plataforma
mysql
7. Cambiarse a este directorio con el commando cd mysql.
8. Ahora hay que ejecutar el script que crea las tables de transferencia.
Estas tablas contienen información sobre privilegios de usuarios. Ejecutar
el commando scripts/mysql_install_db --user=mysql.
9. Ahora cambiar el propietario de todos los archivos del directorio actual al
usuario root. Ejecutar el comando chown -R root.
10. Cambiar el propietario de todos los archivos del directorio de datos data
al usuario mysql. Ejecutar el comando chown -R mysql data
11. Cambiar el grupo de todo los archivos del directorio actual al usuario
mysql. Ejecutar el comando chgrp -R mysql.
12. Iniciar la instancia del servidor MySQL ejecutando el siguiente script
bin/mysqld_safe --user=mysql &
13. Para iniciar el servidor cuando el ordenador arranque copiar el archivo
support-files/mysql.server en /etc/init.d
14. Para establecer la contraseña del usuario root ./bin/mysqladmin -u root
password 'nueva_contraseña´.
Si todo ha ido bien, la instalación de MySQL ha terminado.
Comprobación de la instalación en UNIX/Linux
Si durante la instalación se ejecuta correctamente el script
scripts/mysql_instal_db no habrá fallado. Sin embargo, podemos realizar otras
opciones para asegurarnos de que el servidor MySQL está correctamente
ejecutándose en el ordenador.
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 8 -Vv30L Pád|ra 111 de 20ê
Utilizar bin/mysqladmin version o bin/mysqladmin variables para verificar
que el servidor está ejecutándose.
Después podemos apagar el servidor ejecutando bin/mysqladmin -u root
shutdown y posteriormente volverlo a poner en marcha con opción de registros de
archivo log ejecutando bin/safe_mysqld -log &. Después volvemos a realizar algún
testeo para verificar que el servidor está trabajando normalmente, como por
ejemplo bin/mysqlshow para ver las bases de datos que hay actualmente y
bin/mysqlshow mysql para ver las tablas de transferencia.
Si el resultado de todo ha sido satisfactorio tenemos la instalación de MySQL
completada.
CkEACIÓN Y b$O DE 8D EN MY$QL
Una vez la instalación de MySQL ha terminado, estamos en disposición de
trabajar con el sistema. La instancia del servidor puede gestionar un número
ilimitado de bases de datos (la única limitación son los recursos disponibles en el
ordenador). Antes de poder manipular información en una base de datos, hay que
crearla. Para ello se utiliza la sentencia SQL CREATE TABLE. La sintaxis es:
CREATE DATABASE nombre_BD;
Vamos a crear la base de datos que se empleará en los ejemplos de
capítulos posteriores. Se trata de una base de datos de Almacén y Facturación de
una empresa comercial. Para crearla, abrir un terminal MySQL como usuario root y
crear la base de datos con la sentencia
CREATE DATABASE Almacen;
Si el comando introducido ha sido correcto, entonces aparecerá un mensaje
Ok. Ahora se puede trabajar con la base de datos. Sin embargo, aunque la
instancia del servidor maneja múltiples bases de datos, un usuario solamente
trabaja con una a la vez, aunque puede cambiar de una base de datos a otra en
cualquier momento. Para indicar al servidor con que base de datos estamos
trabajando, hay que indicarlo con la orden USE Base de datos. Si queremos
trabajar con la base de datos anteriormente creada escribimos
USE Almacen;
CkEACIÓN DE IA8LA$
Las tablas son la estructura de datos básica en cualquier base de datos
relacional. Una tabla es una colección organizada de registros (filas), todas ellas
con los mismos atributos (columnas o campos). Las columnas de la tabla describen
la estructura de la misma y las restricciones de integridad de la tabla describen los
datos que son válidos dentro de la misma. La sentencia SQL para creación de
tablas en MySQL es CREATE TABLE, con la siguiente estructura básica:
CREATE [TEMPORARY] TABLE [IF NO EXISTS] nombre_tabla
( definición de columna 1,
definición de columna 2,

definición de columna N )
[opciones de tabla]
[[IGNORE | REPLACE] sentencia de selección]
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 8 -Vv30L Pád|ra 115 de 20ê
La parte de la sentencia definición de columna tiene la siguiente sintaxis:
nombre_columna tipo_de_datos
[NOT NULL | NULL] [DEFAULT valor predeterminado]
[AUTO_INCREMENT] [PRIMARY KEY] [referencia]
| PRIMARY KEY (columnas índice)
| KEY [nombre índice] (columnas índice)
| INDEX [nombre índice] (columnas índice)
| UNIQUE [INDEX] [nombre índice] (columnas índice)
| [CONSTRAINT nombre] FOREIGN KEY [nombre índice] (columnas
índice) [referencia]
| CHECK (expresión)
La parte de definición de columna que indica referencia tiene la siguiente
sintaxis:
REFERENCES nombre_tabla [(columnas indice)]
[ON DELETE {RESTRICT|CASCADE|SET NULL|NO ACTION|SET DEFAULT}]
[ON UPDATE {RESTRICT|CASCADE|SET NULL|NO ACTION|SET DEFAULT}]
[MATCH FULL | MATCH PARTIAL]
La parte de opciones de tabla en la sentencia CREATE TABLE tiene la
siguiente sintaxis:
TYPE = {BDB | HEAP | ISAM | InnoDB | MERGE | MRG_MYISAM |
MYISAM }
| AUTO_INCREMENT = número
| AVG_ROW_LENGTH = número
| CHECKSUM = {0 | 1}
| COMMENT = « cadena »
| MAX_ROWS = #
| MIN_ROWS = #
| PACK_KEYS = {0 | 1 | DEFAULT}
| PASSWORD = “contraseña”
| DELAY_KEY_WRITE = {0 | 1}
| ROW_FORMAT= { default | dynamic | fixed | compressed }
| RAID_TYPE= {1 | STRIPED | RAID0 } RAID_CHUNKS = número
RAID_CHUNKSIZE = número
| UNION = (table_name,[table_name...])
| INSERT_METHOD= {NO | FIRST | LAST }
| DATA DIRECTORY=”path absoluto al directorio”
| INDEX DIRECTORY=”path absoluto al directorio”
La parte correspondiente a sentencia de selección es:
[IGNORE | REPLACE] SELECT ... (Una sentencia SELECT)
Si se indica TEMPORARY, indica que la tabla que se crea es temporal,
solamente existirá en la base de datos para la sesión actual y cuando termine
dejará de existir.
IF NOT EXISTS puede usarse para evitar un error al crear una tabla que ya
existe. No puede haber dos tablas con igual nombre en la misma base de datos.
En las definiciones de columnas, si se indica NOT NULL la columna no podrá
tomar valor nulo. NULL no es preciso indicarlo, ya que es la opción por defecto e
indica que la columna puede tomar valores nulos.
DEFAULT se utiliza para indicar un valor por defecto cada vez que se inserte
un registro.
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 8 -Vv30L Pád|ra 11ê de 20ê
Con AUTO_INCREMENT la columna tiene que ser de tipo numérico y se
indica que los valores se rellenan secuencialmente comenzando por uno para el
primer registro.
Si se indica PRIMARY KEY la columna es clave. Solamente cuando la tabla
tiene una sola columna como clave.
Existen otras cláusulas a nivel de definición de columna que no se usan para
declarar una columna de la tabla, sino para establecer otras características. Estas
son:
PRIMARY KEY se similar al anterior, pero ahora pueden indicarse más de una
columna como índice.
KEY e INDEX son similares. Se utiliza para crear índices por las columnas
especificadas. UNIQUE es similar, pero el índice creado es de valor único.
Con FOREIGN KEY se declaran claves externas. Más adelante en los
ejemplos se especifica claramente como crear una clave externa.
Con CHECK condición se indica una restricción que tiene que cumplir los
registros de la tabla en operaciones de inserción y actualización para ser válidos.
Con TYPE = tipo se indica de que tipo es la tabla. Por defecto es MyISAM.
Con AUTO_INCREMENT = número indicamos por que número queremos que
empiecen las columnas de autoincremento.
Las tablas tienen un tamaño máximo de 4 Gb, si se desea tamaños mayores
hay que establecer AVG_ROW_LENGTH = número y MAX_ROWS = número, que
son un valor aproximado de la longitud media de cada fila y el número máximo de
filas. Sólo es necesario establecerlo para tablas grandes y con tamaño de registros
variable.
CHECKSUM establecido a 1 indica que para mantener una suma de
comprobación para todas las filas. Solamente en tablas MyISAM facilitando la
búsqueda de tablas corruptas.
Se establece PACK_KEYS a 1 para mantener índices más pequeños lo que
hace lecturas más pequeñas y actualizaciones más grandes. Solamente tiene
sentido para índices de columnas CHAR y VARCHAR.
Estableciendo una contraseña con PASSWORD se encripta la definición de la
tabla en la base de datos.
Con DELAY_KEY_WRITE a 1 se retrasan las actualizaciones de las claves de
tabla hasta que se cierra.
Si al final de la sentencia de creación de la tabla se utiliza una sentencia
SELECT el resultado de esta se utiliza para rellenar la tabla nueva creada.
Naturalmente, han de coincidir el número y tipo de las columnas de la tabla nueva
con los que aparecen en la sentencia SELECT. Si se usa IGNORE los registros
duplicados se ignoran y si se usa REPLACE al insertar un nuevo registro cuando
antes existe otro con igual valor de clave, se sustituye.
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 8 -Vv30L Pád|ra 11Z de 20ê
Tipos de tablas en MySQL
MySQL soporta diferentes tipos de tablas. Dependiendo del rendimiento y
restricciones que se quieran cumplir habrá que elegir de un tipo o de otro. Los tipos
que existen son:
• MyISAM.- Es la tabla por defecto si no se indica nada en su creación.
Utiliza ficheros con organización secuencial indexada, por lo que tiene
un fichero índice indexado por la clave primaria y otro para los datos.
No soporta restricciones de clave externa.
• MERGE.- Es una colección de tablas MyISAM idénticas que pueden
ser usadas como una para sentencias SELECT, DELETE y UPDATE,
entendiendo como tablas idénticas aquellas que tienen igual número
de columnas e información de clave. No soporta claves externas.
• ISAM.- Este tipo está desfasado, ya que es similar a MyISAM, pero
ésta última es una optimización.
• HEAP.- Mantiene el índice de la tabla en una archivo hash de
memoria. El inconveniente es que cuando falla MySQL, se pierden los
datos. La ventaja es que al estar el índice en memoria los accesos
son rapidísimos.
• InnoDB.- Este tipo es una incorporación reciente de MySQL para
soportar restricciones de clave externa y transacciones. Los datos se
almacenan en un archivo de 10 Mb iniciales que pueden extenderse
en bloques de 8 Mb cuando alcanza su tamaño máximo.
• BDB (Berkley DataBase).- También soporta restricciones de clave
externa y transacciones. Más resistentes a paradas violentas del
sistema.
Como se puede observar, si se quiere una autentica base de datos que sea
capaz de mantener por si sola las restricciones inherentes a las relaciones entre los
datos y posibilidad de recuperación en transacciones, es necesario utilizar tablas
que soporten ambas características. En este caso utilizaremos las tabla InnoDB
por ser las que ofrecen mejor rendimiento.
Por defecto, MySQL crea las tablas de tipo MyISAM. Si se desea cualquier
otro tipo hay que indicarlo con la opción de tabla TYPE = tipo. Para el caso que nos
ocupa, en las sentencias CREATE TABLE utilizaremos la opción TYPE = InnoDB para
indicar que cree tablas InnoDB.
En la figura siguiente aparece el esquema relacional de la base de datos que
utilizaremos en los ejemplos. Vamos a poner a continuación las sentencias para
crear la base de datos. Dejaremos para el final las tablas con claves externas, ya
que antes es necesario crear aquellas tablas con las que mantienen la referencia.
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 8 -Vv30L Pád|ra 118 de 20ê

Figura 4. Modelo Relacional de la base de datos Almacen
ALBARÁN
CLIENTE
nif
razón_social
dirección
población
provincia
telefono
PEDIDO
npedido
fecha
forma_envio
forma_pago
cliente
representante
L_PEDIDO
npedido
nlinea
referencia
unidades
precio
dto
und_pend
und_serv
nalbaran
fecha
forma_envio
forma_pago
cliente
total_albarán
REPRE8ENTANTE
nif
nombre
dirección
teléfono
PED-REP
npedido
L_ALBARÁN
nalbaran
nlinea
referencia
unidades
precio
dto
npedido
nlinea
ARTICULO
descripción
precio_venta
precio_compra
referencia
forma_pago
descripción
FORMA_PAGO
familia
descripción
FAMILIA
familia
FACTURA
nfactura
fecha
cliente
nalbaran
nfactura
ALBFAC
recibos
cadencia
dias_1
und_comprada
und_vendidas
existencias
ventas
ventas
observaciones
total_pedido
EFECTOS
nefecto
fecha
fecha_vto
nfactura
cc
entidad
sucursal
dc
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 8 -Vv30L Pád|ra 119 de 20ê
CREATE TABLE Cliente (
nif VARCHAR(10) BINARY NOT NULL PRIMARY KEY,
razon_social VARCHAR(40) NOT NULL,
direccion VARCHAR(40) BINARY,
poblacion VARCHAR(20) BINARY,
provincia VARCHAR(10) BINARY,
telefono INTEGER(9),
ventas DECIMAL(7,2) DEFAULT 0
)TYPE = InnoDB;
Como se puede observar las cadenas de caracteres se han declarado como
VARCHAR BINARY. Esto es debido a que por defecto, las comparaciones de cadenas
en MySQL no son sensibles a mayúsculas o minúsculas. El atributo de columna
BINARY fuerza a que la cadena de caracteres siga un orden ASCII donde se
diferencian las mayúsculas de las minúsculas. Además ha sido necesario crear la
tabla de tipo InnoDB ya que van a ser necesarias para poder crear claves externas.
Las tablas de representante y forma de pago se crearían con las siguiente
sentencias.
CREATE TABLE Representante (
dni VARCHAR(10) BINARY PRIMARY KEY,
nombre VARCHAR(40) BINARY NOT NULL,
direccion VARCHAR(40) BINARY,
telefono INTEGER(9),
ventas DECIMAL(7,2)
) TYPE = InnoDB;
CREATE TABLE Forma_Pago (
forma_pago INTEGER(2) NOT NULL PRIMARY KEY,
descripcion VARCHAR(40) BINARY NOT NULL,
recibos INTEGER(3) NOT NULL DEFAULT 1,
cadencia INTEGER(3) DEFAULT 0,
dias_1 INTEGER(3) DEFAULT 0
)TYPE = InnoDB;
En esta última se ha utilizado el atributo de columna DEFAULT para indicar
un valor por defecto cuando se inserta una fila y no se le ha indicado valor
explícitamente. La tabla de familias de artículos se crearía con la siguiente
sentencia.
CREATE TABLE Familia (
familia VARCHAR(5) BINARY PRIMARY KEY,
descripcion VARCHAR(50) BINARY
) TYPE = InnoDB;
A continuación se va a crear la tabla artículos. Esta tabla mantiene una clave
externa con familia.
CREATE TABLE Articulo (
referencia VARCHAR(15) BINARY PRIMARY KEY,
descripcion VARCHAR(50) BINARY NOT NULL,
precio_venta DECIMAL(6,2) NOT NULL,
precio_compra DECIMAL(6,2),
und_compradas DECIMAL(5,2),
und_vendidas DECIMAL(5,2),
existencias DECIMAL(5,2),
familia VARCHAR(5) BINARY,
INDEX art_fam(familia),
CHECK (precio_venta > precio_compra),
CONSTRAINT fk_familia FOREIGN KEY ( familia ) REFERENCES
Familia(familia) ON DELETE RESTRICT ON UPDATE CASCADE
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 8 -Vv30L Pád|ra 150 de 20ê
)TYPE = InnoDB;
Centrémonos en la definición de la clave externa. En MySQL, cuando una
columna de una tabla es clave externa, hay que indexarla. De ahí la cláusula INDEX
art_fam(familia) por la que se crea el índice art_fam con la columna familia.
Posteriormente se utiliza la cláusula CONSTRAINT para declarar la restricción de
clave externa. Después de la palabra clave FOREIGN KEY se indica la columna que
es clave externa y con REFERENCES la tabla a la que referencia. Entre paréntesis
se índica la columna a la que referencia, aunque si se llama igual que la clave
externa se puede omitir. ON DELETE indica que acción se realiza cuando se borra
(DELETE) en la tabla referenciada un registro y existen registros de la tabla actual
con los que mantiene relación. Las posibilidades son las siguientes:
• RESTRICT.- Opción por defecto. Indica que la operación de borrado
se abortará para evitar que registros en la tabla actual queden
huérfanos y se viole la integridad de la referencia.
• CASCADE.- Indica que al borrar un registro en la tabla referenciada,
todos los registros de la tabla actual cuyo valor de clave externa
coincida con el valor de clave primaria del registro borrado, se
borrarán. Se eliminaría el registro en la tabla referenciada y todos
los registros relacionados en la tabla actual.
• SET NULL.- Indica que al borrarse un registro en la tabla
referenciada, los valores de clave externa en la tabla actual se
establecen a valor NULL.
• SET DEFAULT.- Indica que al borrarse un registro en la tabla
referenciada, los valores de clave externa en la tabla actual se
establecen al valor por defecto si se hubiera definido al crear la
tabla.
• NO ACTION.- Indica que al borrarse un registro en la tabla
referenciada, no se tome ninguna acción sobre la tabla actual.
La opción a elegir dependerá de los requerimientos del problema. En la
mayoría de los casos se usa RESTRICT o CASCADE.
De forma análogo, ON UPDATE indica las acciones a tomar cuando en la
tabla referenciada un registro que mantiene relación con registros de la tabla actual
sufre una operación de actualización (UPDATE). Para este caso las opciones son las
mismas que para ON DELETE.
El resto de las tablas de la base de datos se crearían con las siguientes
sentencias.
CREATE TABLE Pedido (
npedido INTEGER (5) NOT NULL PRIMARY KEY,
cliente VARCHAR(10) BINARY NOT NULL,
fecha TIMESTAMP,
forma_envio VARCHAR(25) BINARY,
forma_pago INTEGER(2) NOT NULL,
observaciones TEXT,
total_pedido DECIMAL(7,2) DEFAULT 0,
INDEX ped_cli (cliente),
INDEX ped_fp(forma_pago),
CONSTRAINT fk_cli FOREIGN KEY (cliente) REFERENCES
Cliente(nif) ON DELETE CASCADE ON UPDATE CASCADE,
CONSTRAINT fk_fp FOREIGN KEY(forma_pago) REFERENCES
Forma_Pago(forma_pago) ON DELETE RESTRICT ON UPDATE CASCADE
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 8 -Vv30L Pád|ra 151 de 20ê
) TYPE = InnoDB;
CREATE TABLE LineaPedido (
npedido INTEGER(5) NOT NULL,
nlinea INTEGER(4) NOT NULL,
referencia VARCHAR(15) BINARY NOT NULL,
unidades DECIMAL(4,2) NOT NULL,
precio DECIMAL(4,2) NOT NULL,
dto DECIMAL(2,2),
und_pend DECIMAL(4,2),
und_serv DECIMAL(4,2) ,
PRIMARY KEY (npedido, nlinea),
INDEX ped_lpe( npedido ),
INDEX ped_art( referencia),
CHECK ( precio > 0 ),
CHECK ( dto BETWEEN 0 AND 1 ),
CONSTRAINT fk_ped FOREIGN KEY (npedido) REFERENCES
Pedido(npedido) ON DELETE CASCADE ON UPDATE CASCADE,
CONSTRAINT fk_art FOREIGN KEY (referencia) REFERENCES
Articulo(referencia) ON DELETE RESTRICT ON UPDATE CASCADE
) TYPE = InnoDB;
CREATE TABLE Ped_Rep (
npedido INTEGER(5) PRIMARY KEY,
dni VARCHAR(10) BINARY NOT NULL,
INDEX ped( npedido ),
INDEX rep_rep( dni ),
CONSTRAINT fk_pere FOREIGN KEY (npedido) REFERENCES
Pedido(npedido) ON DELETE CASCADE ON UPDATE CASCADE,
CONSTRAINT fk_rep FOREIGN KEY (dni) REFERENCES
Representante(dni) ON DELETE CASCADE ON UPDATE CASCADE
) TYPE = InnoDB;
CREATE TABLE Albaran (
nalbaran INTEGER(5) NOT NULL PRIMARY KEY,
cliente VARCHAR(10) BINARY NOT NULL,
fecha DATE NOT NULL,
forma_envio VARCHAR(25) BINARY,
forma_pago INTEGER(2),
total_albaran DECIMAL(7,2),
INDEX alb_cli (cliente),
INDEX alb_fp (forma_pago),
CONSTRAINT fk_clialb FOREIGN KEY (cliente) REFERENCES Cliente
(nif) ON DELETE RESTRICT ON UPDATE CASCADE,
CONSTRAINT fk_fpalb FOREIGN KEY (forma_pago) REFERENCES
Forma_pago (forma_pago) ON DELETE SET NULL ON UPDATE CASCADE
) TYPE = InnoDB;
CREATE TABLE LineaAlbaran (
nalbaran INTEGER(5) NOT NULL,
nlinea INTEGER(4) NOT NULL,
referencia VARCHAR(15) BINARY NOT NULL,
unidades DECIMAL(4,2) NOT NULL,
precio DECIMAL(4,2) NOT NULL,
dto DECIMAL(2,2),
npedido INTEGER(5),
nlineap INTEGER(4),
INDEX lin_alb(nalbaran),
INDEX alb_art(referencia),
INDEX lin_ped(npedido, nlineap),
PRIMARY KEY (nalbaran, nlinea),
CONSTRAINT fk_alb FOREIGN KEY (nalbaran) REFERENCES
Albaran(nalbaran) ON DELETE RESTRICT ON UPDATE CASCADE,
CONSTRAINT fk_artalb FOREIGN KEY (referencia) REFERENCES
Articulo(referencia) ON DELETE RESTRICT ON UPDATE CASCADE,
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 8 -Vv30L Pád|ra 152 de 20ê
CONSTRAINT fk_albped FOREIGN KEY (npedido, nlineap)
REFERENCES LineaPedido (npedido, nlinea) ON DELETE SET NULL
ON UPDATE CASCADE,
CHECK ( precio > 0 ),
CHECK ( dto BETWEEN 0 AND 1 )
) TYPE = InnoDB;

CREATE TABLE Factura (
nfactura INTEGER(5) NOT NULL PRIMARY KEY,
fecha DATE NOT NULL,
cliente VARCHAR(10) BINARY NOT NULL,
INDEX faccli (cliente),
CONSTRAINT fk_clifac FOREIGN KEY (cliente) REFERENCES
Cliente(nif) ON DELETE RESTRICT ON UPDATE CASCADE
) Type = InnoDB;
CREATE TABLE AlbFac (
nalbaran INTEGER(5) NOT NULL PRIMARY KEY,
nfactura INTEGER(5) NOT NULL,
INDEX alb (nalbaran),
INDEX fac (nfactura),
CONSTRAINT fk_albfac FOREIGN KEY (nalbaran) REFERENCES
Albaran (nalbaran) ON DELETE RESTRICT ON UPDATE CASCADE,
CONSTRAINT fk_fac FOREIGN KEY (nfactura) REFERENCES Factura
(nfactura) ON DELETE RESTRICT ON UPDATE CASCADE
) Type = InnoDB;
CREATE TABLE Efectos (
nfactura INTEGER(5) NOT NULL,
nefecto INTEGER(3) NOT NULL,
fecha DATE NOT NULL,
fecha_vto DATE NOT NULL,
entidad INTEGER(4),
sucursal INTEGER(4),
dc INTEGER(2),
cc INTEGER(10),
INDEX FacEfe (nfactura),
PRIMARY KEY (nfactura, nefecto),
CONSTRAINT fk_fact FOREIGN KEY (nfactura) REFERENCES
Factura(nfactura) ON DELETE CASCADE ON UPDATE RESTRICT,
CHECK( fecha_vto >= fecha )
) Type = InnoDB;
Añadir registros con SQL directamente en el entorno de MySQL
Con las tablas ya creadas, se pueden insertar registros en las mismas,
mediante la sentencia INSERT. Su sintaxis es:
INSERT [LOW_PRIORITY | DELAYED] [IGNORE][INTO] tabla
[(lista_columnas)] VALUES (valores_de_datos);
Con la opción LOW_PRIORITY se retrasa la inserción hasta que ningún
cliente esté leyendo de la tabla. DELAYED hace que las nuevas filas se sitúen en la
cola para insertarlas posteriormente. IGNORE evita que se dupliquen valores de
claves únicas sin error. Las columnas en lista de columnas están separadas por
comas y los valores en valores de datos también. Como ejemplo, introducimos los
siguientes registros.
INSERT INTO Cliente
VALUES (‘30000001ª’, ‘Supermercado María’, ‘San Jacinto, 3’,
‘Córdoba’, ‘Córdoba’, 957000000, null );
INSERT INTO Cliente
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 8 -Vv30L Pád|ra 153 de 20ê
VALUES (‘30000002ª’, ‘Comestibles Javier’, ‘San Juan, 2’,
‘Córdoba’, ‘Córdoba’, 957000001, null );
INSERT INTO Familia
VALUES (‘CONF’, ‘Confiteria’);

INSERT INTO Articulo
VALUES (‘CONF0001’, ‘Magdalenas la Bella Easo’, 1.5, 0.60,
300, 15, 500, ‘CONF’);
INSERT INTO Articulo
VALUES (‘CONF0002’, ‘Magdalenas con chocolate’, 2.5, 1.60,
300, 15, 500, ‘CONF’);
INSERT INTO Articulo
VALUES (‘CONF0003’, ‘Palmeritas con crema’, 1.25, 0.40, 300,
15, 500, ‘CONF’);
INSERT INTO Pedido ( cliente, fecha, forma_envio, forma_pago
)
VALUES ( ‘30000001ª’, ‘1-ENE-04’, ‘Agencia SEUR’, 1 );
INSERT INTO LineaPedido
VALUES (last_insert_id(), 1, ‘CONF0001’, 40, 1.15, 0.2, 40, 0
);
INSERT INTO LineaPedido
VALUES (last_insert_id(), 2, ‘CONF0002’, 10, 2.5, 0.2, 10, 0
);
INSERT INTO LineaPedido
VALUES (last_insert_id(), 3, ‘CONF0003’, 25, 1.25, 0.2, 25, 0
);
INSERT INTO LineaPedido
VALUES (last_insert_id(), 4, ‘CONF0004’, 21, 1.75, 0.2, 21, 0
);
INSERT INTO LineaPedido
VALUES (last_insert_id(), 5, ‘CONF0005’, 5, 2.75, 0.2, 5, 0
);
Como se puede observar, la introducción de registros de esta forma es muy
lenta y tediosa, sobre todo cuando el volumen de información a introducir es
grande. MySQL proporciona otros mecanismos para acelerar este proceso.
Uno de ellos consiste en introducir todas las sentencias SQL que se desean
ejecutar, en este caso INSERT, en un fichero de texto con extensión .sql, para
posteriormente ejecutar el entorno y que las sentencias las tome de este fichero.
Por ejemplo, si tenemos el fichero cliente.sql con sentencias insert para
introducir en la tabla cliente y queremos que el entorno las ejecute una detrás de
otra, hay que salir de la interfaz en línea de comando con el comando quit o exit.
Posteriormente, desde la ventana de comandos de MS-DOS escribir lo siguiente:
mysql -u root -p almacen < cliente.sql
Ejecutamos la interfaz en línea de comando con el usuario root, solicitando
contraseña y conectando directamente a la base de datos almacen. Después de
introducir la contraseña correcta tomará las sentencias SQL del archivo cliente.sql y
las ejecutará.
El mismo efecto se consigue si estando dentro del entorno de interfaz en
línea de comando se ejecuta el comando source cliente.sql.
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 8 -Vv30L Pád|ra 151 de 20ê
Incorporar datos externos a tablas MySQL con LOAD DATA
Existe otra forma de incorporar datos masivamente a las tablas de una base
de datos, muy utilizada en migraciones de grandes volúmenes de información.
Consiste en utilizar la sentencia SQL LOAD DATA, la cual lee los registros de un
archivo texto y los carga como un volumen en una tabla. Esta sentencia es más
rápida que INSERT. Su sintaxis general es la siguiente:
LOAD DATA [LOW_PRIORITY] [LOCAL] INFILE ‘nombre archivo’
[IGNORE | REPLACE]
INTO TABLE nombre_tabla
opciones de importación
[IGNORE n LINES]
[(lista_columnas)]
LOW_PRIORITY retrasa la sentencia hasta que ningún cliente esté leyendo
de la tabla. LOCAL hace que el cliente lea el archivo en el host del cliente y envíe su
contenido por la red al servidor. IGNORE provoca que las filas que duplican valores
en un índice único sean ignoradas, mientras que REPLACE provoca que sean
reemplazadas las existentes.
Las opciones de importación pueden tener la siguiente sintaxis:
[FIELDS
[TERMINATED BY ‘cadena’]
[OPTIONALLY] ENCLOSE BY ‘carácter’]
[ESCAPED BY ‘carácter’]]
[LINES TERMINATED BY ‘cadena’]
Si se usa FIELDS hay que especificar TERMINATED BY (describe el carácter o
caracteres que delimitan valores dentro de una fila), ENCLOSED BY (especifica un
carácter entrecomillado que se quita al final del campo de valores si se usa
OPTIONALLY) o ESCAPED BY (especifica el carácter de escape de los caracteres
especiales). FIELDS siempre debe preceder a LINES.
LINES TERMINATED BY especifica un carácter o caracteres que significan el
final de las líneas. Si no se especifican ni FIELDS ni LINES, los valores por defecto
quedarán como si se hubiesen especificado de la siguiente manera:
FIELDS
TERMINATED BY ‘\t’
ENCLOSED BY “
ESCAPED BY ‘\\’
LINES TERMINATED BY ‘\n’
La sintaxis anterior indica que por defecto los campos dentro de una línea
están delimitados por tabulaciones sin estar acotados, el carácter de escape es la
barra invertida y el carácter de final de línea es \n.
El conjunto de caracteres que se pueden utilizar es el siguiente:
Carácter Significado
\0 ASCII 0
\b Retroceso
\n Línea nueva
\r Retorno de carro
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 8 -Vv30L Pád|ra 155 de 20ê
\s Espacio
\t Tabulador
\´ Comilla simple
\¨ Comillas dobles
\\ Barra invertida
La sintaxis IGNORE n LINES indica que se descartan las primeras n líneas
del archivo de entrada de datos.
Si no se especifica lista_columnas, las líneas de entrada contendrán un valor
por columna de la tabla de datos. Si se especifica una lista de uno o más nombres
de columna separados por comas, las líneas de entrada deberían de contener un
valor por cada columna designada colocándose en sus valores predeterminados las
columnas no mencionadas en la lista.
Vamos a probar está sentencia para introducir registros masivamente en la
tabla de Albaran y Lineaalbaran. Para ello contamos con el fichero albaran.txt que
contiene registros tal que así:
‘30000001ª’,’2005-01-01’,’Agencia SEUR’,’1’,’0.00’
Los valores que aparecen separados por comas y encerrados entre comillas
corresponden a las columnas cliente, fecha, forma_envio, forma_pago y
total_albaran. La columna nalbaran es de tipo AUTO_INCREMENT, así que no hay
que especificarlo, MySQL lo rellena automáticamente. Si existiera alguna otra
columna cuyo valor no apareciese en el fichero se rellenaría con su valor por
defecto o con valor NULL.
Para introducir todos estos registros habría que escribir la siguiente
sentencia SQL:
LOAD DATA INFILE ‘albaran.txt’
INTO TABLE albaran
FIELDS TERMINATED BY ‘,’
OPTIONALLY ENCLOSE BY ‘\”
LINES TERMINATED BY ‘\r\n’
(cliente, fecha, forma_envio, forma_pago, total_albaran);
Posteriormente, para introducir los registros en la tabla lineaalbaran:
LOAD DATA INFILE ‘lineaalbaran.txt’
INTO TABLE lineaalbaran
FIELDS TERMINATED BY ‘,’
OPTIONALLY ENCLOSED BY ‘\”
LINES TERMINATED BY ‘\r\n’
OFIIMIIE IA8LE, kEFLACE, $EI, LOCK IA8LE$ Y bNLOCK IA8LE$
Existe un grupo de sentencias en MySQL que se utilizan para optimizar
tablas y especificar determinadas opciones para las mismas.
La sentencia OPTIMIZE TABLE optimiza el espacio asignado a una tabla
eliminando espacios no usados que reducen el tamaño que ocupa. Su sintaxis es la
siguiente:
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 8 -Vv30L Pád|ra 15ê de 20ê
OPTIMIZE TABLE nombre_tabla
La sentencia REPLACE funciona como INSERT, con la salvedad de que si se
inserta una fila que tiene un valor para un índice UNIQUE, el cual duplica el valor
en una fila ya presente en la tabla, el valor antiguo se borra antes de que el nuevo
se inserte (luego IGNORE no tiene sentido aquí). Su sintaxis completa es la
siguiente:
REPLACE [LOW_PRIORITY | DELAYED] [INTO] nombre_tabla
[(listas_columnas)] VALUES (valores_de_datos);
La sentencia hace que la lista valores_de_datos se inserte como una o más
filas en la tabla que se nombra. El argumento lista_columnas es una lista separada
por comas de los nombres de columnas que se pueden utilizar para especificar las
columnas para las que se suministran datos. Si no se especifica lista_columnas,
todas las columnas de la tabla o vista reciben datos. Cuando lista_columnas no
enumera todas las columnas de la tabla o vista, se inserta un valor de NULL (o el
valor predeterminado si se ha definido alguno para la columna) en aquellas
columnas que no se hayan enumerado en la lista. Todas las columnas no
especificadas en la lista de columnas deben permitir valores NULL o tener un valor
predeterminado asignado. Los valores_de_datos suministrados deben
corresponderse con la lista de columnas. El número de valores de datos debe ser el
mismo que el número de columnas y el tipo de datos, precisión y escala de cada
valor de datos debe coincidir con los de la columna correspondiente. Si no se citan
columnas, se tomarán todas las de la tabla.
Al igual que en la sentencia INSERT, suelen utilizarse a continuación de
REPLACE las opciones LOW_PRIORITY (provoca que la instrucción sea postergada
hasta que ningún cliente esté leyendo la tabla) o DELAYED (las filas se sitúan en la
cola para insertarlas posteriormente).
La sentencia SET se utiliza para especificar distintas opciones. Su sintaxis
es:
SET opciones;
Las opciones van separadas por comas. Algunas de las opciones son el
establecimiento de la contraseña del usuario
SET PASSWORD FOR usuario = PASSWORD(“contraseña”)
El número máximo de registros a devolver por una instrucción SELECT
SET SQL_BIG_TABLES = n
La sentencia LOCK TABLE (o LOCK TABLES) bloquea el acceso a las tablas
indicadas. Su sintaxis es la siguiente:
LOCK TABLES tabla1 [AS alias] {READ | [LOW_PRIORITY] WRITE},
tabla2 …
READ indica un bloqueo de sólo lectura para que otros clientes no puedan
escribir en la tabla pero sí leerla, WRITE indica un bloqueo de escritura para
impedir el acceso de lectura y escritura a los clientes y LOW_PRIORITY pide
permiso a otros lectores para leer la tabla cuando un usuario la está leyendo
actualmente.
La sentencia UNLOCK TABLE (o UNLOCK TABLES) libera una tabla
bloqueada. Su sintaxis es la siguiente:
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 8 -Vv30L Pád|ra 15Z de 20ê
UNLOCK TABLES tabla1, tabla2, …
VI$bALIIACIÓN DE LA$ IA8LA$ DE bNA 8A$E DE DAIO$: $HOW,
DE$CkI8E Y EXFLAIN
La sentencia SHOW posibilita varias formas que ofrecen información acerca
de las bases de datos, tablas, columnas e índices, así como sobre la iteración del
servidor. Algunas de estas formas llevan una cláusula opcional FROM nombre_bd
que permite especificar la base de datos de la que se desea obtener información (si
esta cláusula no está presente, se usará la base de datos predeterminada). La
cláusula LIKE patrón limita la salida a los valores que cumplen el patrón (cadena de
valores % o _). La sintaxis es:
SHOW COLUMNS FROM nombre_tbla [FROM nombre_bd] [LIKE patrón]
SHOW DATABASES [LIKE patrón]
SHOW GRANTS FOR nombre_usuario
SHOW INDEX FROM nombre_tabla [FROM nombre_bd]
SHOW PROCESSLIST
SHOW STATUS
SHOW TABLE STATUS [FROM nombre_bd] [LIKE patrón]
SHOW TABLES [FROM nombre_bd] [LIKE patrón]
SHOW VARIABLES [LIKE patrón]
Estas variantes de SHOW muestran respectivamente las columnas de una
tabla, las bases de datos en el host del servidor, el usuario con los privilegios
atribuidos por la sentencia GRANT, los índices de una tabla, los hilos que se
ejecutan en el servidor, las variables de estado del servidor y sus valores,
información descriptiva acerca de las tablas en una base de datos (nombre, tipo,
formato, número de filas, hora de creación, etc.), lista de tablas de una base de
datos (que puede ser la actual si no se especifica ninguna) y la lista de variables
del servidor y sus valores.
La sentencia DESCRIBE proporciona la misma información que SHOW
COLUMNS. Su sintaxis es la siguiente:
{DESCRIBE | DES} nombre_tabla {nombre_columna | patrón}
La sentencia EXPLAIN equivale a SHOW COLUMNS FROM. Su sintaxis es:
EXPLAIN nombre_tabla
A continuación, se muestran varias características de la base de datos
creada en el ejemplo.
SHOW TABLES;
SHOW COLUMNS FROM Cliente;
SHOW COLUMNS FROM Albaran;
SHOW INDEX FROM LineaAlbaran;
SHOW DATABASES;
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 9 - 30L pa(a Vv30L. Lerduaje de Var|pu|ac|ór de 0alos Pád|ra 158 de 20ê
9
80L para Hy80L. Lenguaje de
man|pu|ac|ón de datos.
INIkODbCCIÓN
Dentro del lenguaje SQL (Structured Query Language) que MySQL utiliza
para tratar la información, suelen distinguirse varias categorías de sentencias (o
comandos). El lenguaje de consulta de datos DQL (Data Query Lenguage) permite
básicamente obtener datos de tablas y especificar la forma en que se presentan.
La sentencia esencial es SELECT. Se trata de la más sencilla de estas categorías y
suele ser la primera en abordarse cuando se trata de aprender SQL.
Existen otras categorías de sentencias SQL como el Lenguaje de
Modificación de Datos DML (Data Modification Language) cuyas sentencias se usan
en la interrogación y manipulación de datos en esquemas de bases de datos ya
existentes. Como ejemplos característicos tenemos las sentencias INSERT,
UPDATE, DELETE y DROP.
Otras categorías de sentencias SQL son el Lenguaje de Definición de Datos
DDL (Data Definition Language) y Lenguaje de Control de Datos DCL (Data
Control lenguaje)Las sentencias del lenguaje de definición de datos se utilizan
para crear, alterar o borrar objetos de base de datos, tales como tablas, columnas
y secuencias. Como ejemplos característicos tenemos las sentencias CREATE, ALTER
y DROP. Las sentencias del lenguaje de control de datos se utilizan en el control
de acceso a datos en la base de datos. Como ejemplos característicos
tenemos los comandos GRANT y REVOKE. Estas últimas categorías de sentencias
o comandos suelen utilizarse en tareas típicas de administración de la base de datos.
En este capítulo se tratan las sentencias del lenguaje de modificación de
datos, y en capítulos posteriores se tratarán las restantes categorías.
LA $ENIENCIA $ELECI
En el capítulo 4 se introdujo una versión sencilla de la sintaxis de la
sentencta SELECT. Básicamente dicha sintaxis puede resumirse como sigue:
SELECT [DISTINCT | ALL | Otras opciones ] lista_selección
[INTO OUTFILE ‘nombre_ fichero’ opciones exportación]
[FROM tabla origen [,tabla_ origen] ... ]
[WHERE condición de búsqueda]
[LIMIT m, n]
[GROUP BY expresión_ de agrupamiento]
[HAVING condición de_ búsqueda]
[ORDER BY expresión_order_by [ASC|des]]
La sentencia SELECT recupera filas o columnas (las especificadas en lista
_

selección) de una o más tablas especificadas en la cláusula FROM que satisfagan
las condiciones de búsqueda especificadas en WHERE, agrupadas según la
expresión de agrupamiento de GROUP BY, cumpliendo las condiciones de búsqueda
de HAVING y ordenadas según lo especificado en ORDER BY. ALL significa que se
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 9 - 30L pa(a Vv30L. Lerduaje de Var|pu|ac|ór de 0alos Pád|ra 159 de 20ê
devolverán todas las filas que satisfagan las condiciones de WHERE (es el valor por
defecto) y DISTINCT significa que las filas duplicadas sólo se devolverán una vez.
DISTINCT es sinónimo de DISTINCTROW.
La sentencia SELECT obtiene filas de la base de datos y permite realizar la
selección de una o varias filas o columnas de una o varias tablas. La sintaxis
completa de la instrucción SELECT es compleja. Sus cláusulas principales se
analizarán en los párrafos siguientes.
Cláusula SELECT
La cláusula SELECT especifica las columnas que va a devolver la consulta,
En cuanto a las opciones de esta cláusula ya sabemos que ALL especifica que
pueden aparecer filas duplicadas en el conjunto de resultados (valor
predeterminado) y que DISTINCT especifica que sólo pueden aparecer filas
exclusivas en el conjunto de resultados. Los valores NULL se consideran iguales a
efectos de la palabra clave DISTINCT. Pueden usarse otras opciones menos
importantes como HIG
_
PRIORITY que da a la instrucción SELECT una mayor
prioridad sobre otras sentencias como INSERT o UPDATE que pueden estar siendo
utilizadas por algún otro cliente sobre las mismas tablas. Otra opción posible es
STRAIGHT_JOIN, que fuerza a las tablas seleccionadas a unirse en el orden citado
en la cláusula FROM. Otras dos opciones que suelen usarse son SQL_BIG_RESULT y
SQL_SMALL
_
RESULT que especifican que el resultado obtenido en la sentencia
SELECT se presentará de modo más extenso (con más información) o más
resumido, respectivamente.
En la cláusula SELECT, a continuación de las opciones, se sitúa la lista de
selección que incluye las columnas que se van a seleccionar para el conjunto de
resultados separadas por comas. De modo más general, la lista de selección puede
ser una serie de expresiones separadas por comas donde cada expresión puede ser
un nombre de columna, constante, función, o una combinación de nombres de
columnas, constantes y funciones conectados mediante operadores.
La lista de selección también puede ser la expresión , que especifica que
se deben devolver todas las columnas de todas las tablas de la cláusula
FROM. Las columnas se devuelven por tabla, tal como se especifique en la
cláusula FROM, en el orden en que se encuentran en la tabla. La lista de
selección también puede ser la expresión nombre
_
tabla., que limita el
alcance de * a la tabla especificada. Al especificar las columnas en la lista de
selección es conveniente situar los nombres de las tablas antes de los de las
columnas separadas por un punto (calificar) para evitar realizar una referencia
ambigua, como ocurre cuando dos tablas de la cláusula FROM tienen columnas de
idéntico nombre.
Por lo tanto, la lista de selección también puede contener los nombres de las
columnas expresadas como nombre tabla .nombre columna.
Detrás del nombre de cualquier columna de la lista de selección puede
situarse un alias para la columna mediante nombre columna AS alias columna. La
sintaxis alias columna es un nombre alternativo para reemplazar el nombre de la
columna en el conjunto de resultados de la consulta. Los alias también se utilizan
para especificar nombres para los resultados de expresiones. La sintaxis alias
columna puede utilizarse en una cláusula ORDER BY, GROUP BY o HAVING; sin
embargo, no puede utilizarse en una cláusula WHERE.
A continuación se exponen algunos ejemplos.
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 9 - 30L pa(a Vv30L. Lerduaje de Var|pu|ac|ór de 0alos Pád|ra 1ê0 de 20ê
Listar todos las columnas de la tabla Cliente

SELECT *
FROM Cliente;

SELECT Cliente.*
FROM Cliente;

Listar el dni de todos los clientes que han hecho pedido

SELECT DISTINCT cliente
FROM Pedido;

Listar el número de pedido, fecha y total

SELECT npedido, fecha, total_pedido
FROM Pedido;

Listar la referencia, descripción y precio venta de los
artículos

SELECT referencia, descripción, precio_venta
FROM Articulo;

Listar el número de factura y fecha de todas las facturas

SELECT nfactura, fecha
FROM Factura;
Cláusula INTO
La cláusula INTO OUTFILE permite escribir el resultado de la instrucción
SELECT en el archivo nombre fichero. Su sintaxis es:
El nombre del archivo (que no debe existir previamente) se interpreta
usando las mismas reglas que se aplican cuando se leen archivos con la sentencia
LOAD DATA vista en el capítulo anterior. El desarrollo de la sintaxis de la cláusula
opciones exportación es igual que para la cláusula opciones importación de la
sentencia LOAD DATA vista en el capítulo anterior.
En definitiva, la sentencia INTO OUTFILE permite recoger en ficheros, de
forma adecuada, los resultados de las consultas. Por ejemplo:
Listar la razón social, dirección, población y provincia de
los clientes y almacenarlo en un fichero, llamado
Clientes.txt.

SELECT razon_social, direccion, poblacion, provincia INTO
OUTFILE ‘Clientes.txt’ FROM Cliente;

Igual que antes, pero los campos separados por comas y sus
valores encerrados entre comillas dobles.

SELECT razon_social, direccion, poblacion, provincia
INTO OUTFILE ‘Clientes.txt’
FIELDS TERMINATED BY ‘,’
OPTIONALLY ENCLOSED BY ‘\”’
FROM Cliente;
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 9 - 30L pa(a Vv30L. Lerduaje de Var|pu|ac|ór de 0alos Pád|ra 1ê1 de 20ê
Cláusula FROM
Esta cláusula especifica las tablas de donde se van a obtener las filas. La
cláusula FROM es necesaria excepto cuando la lista de selección sólo contiene
constantes, variables, expresiones aritméticas (no nombres de columna) y
expresiones del tipo *.
Su sintaxis básica es la siguiente: [FROM lista tablas]
Lo habitual es que lista tablas sean varios nombres de tablas separados por
comas, en cuyo caso SELECT devuelve todas las combinaciones posibles de filas
desde dichas tablas.
Pero los elementos de lista
_
tablas pueden estar separados por cláusulas de
unión (en vez de por comas). Estas cláusulas pueden ser JOIN, CROSS JOIN,
INNER JOIN, STRAIGHT JOIN y LEFT JOIN. El argumento JOIN indica que las tablas
especificadas en FROM deben combinarse. También pueden aparecer mezcladas las
comas y las cláusulas de unión. Algunas sintaxis particulares más detalladas para
lista tablas podrían ser cualquiera de las siguientes:
nombre
_
tabla [CROSS] JOIN nombre
_
tabla
nombre
_
tabla INNER JOIN nombre
_
tabla
nombre
_
tabla STRAIGHT
_
JOIN nombre tabla
nombre tabla LEFT [OUTER]JOIN nombre tabla ON expresión
_

condicional
nombre tabla LEFT [OUTER]JOIN nombre tabla USIGN (lista
_

columnas)
nombre tabla NATURAL LEFT [OUTER]JOIN nombre
_
tabla
nombre tabla [CROSS] JOIN nombre tabla
LEFT JOIN recupera filas desde tablas unidas, pero obliga a generar una fila
por cada fila en la tabla izquierda, incluso si no hay equivalente en la tabla derecha.
Cuando no tiene pareja, las columnas de la tabla derecha se devuelven como
valores NULL. Las filas emparejadas pueden determinarse de acuerdo con la
condición especificada en las cláusulas ON expresión condicional o USIGN (lista
columnas). La expresión condicional es una expresión que se puede usar en la
cláusula WHERE y la lista de columnas contiene nombres de columnas separadas
por comas que deben aparecer en las dos tablas unidas.
LEFT OUTER JOIN equivale a LEFT JOIN, y NATURAL LEFT JOIN equivale a
LEFT JOIN USING (lista
_
columnas), donde los nombres de la lista de columnas son
comunes en ambas tablas.
CROSS JOIN especifica el producto resultante de dos tablas. Devuelve las
filas que se devolverían si las tablas que se combinan se indicaran en la cláusula
FROM, sin especificar ninguna cláusula WHERE.
INNER JOIN especifica que se devuelvan todos los pares de filas coincidentes
y descarta las filas no coincidentes de las dos tablas. Este es el valor preterminado
si no se especifica ningún tipo de combinación.
STRAIGHT JOIN fuerza al optimizador a unir las tablas en el orden en que se
citan.
En algunas versiones de SQL se usan LEFT, RIGHT y FULL para especificar
las uniones izquierda, derecha y completa de las tablas especificadas. LEFT
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 9 - 30L pa(a Vv30L. Lerduaje de Var|pu|ac|ór de 0alos Pád|ra 1ê2 de 20ê
[OUTER] especifica que todas las filas de la tabla de la izquierda que no cumplan la
condición especificada se incluyan en el conjunto de resultados, además de todas
las filas que devuelva la combinación interna. Las columnas de salida de la
izquierda se establecen a NULL. RIGHT [OUTER] especifica que todas las filas de la
tabla de la derecha que no cumplan la condición especificada se incluyan en el
conjunto de resultados, además de las que devuelva la combinación. Las columnas
de salida de la tabla de la derecha se establecen a NULL. FULL [OUTER] especifica
que si una fila de la tabla de la izquierda o de la derecha no coincide con los
criterios de selección, la fila se incluya en el conjunto de resultados y las columnas
de resultados que corresponden a la otra tabla se establezcan como NULL. Se trata
de una adición a todas las filas que normalmente devuelve la combinación interna.
En un capítulo posterior se tratará la unión de tablas de forma extensa y se
expondrán ejemplos.
Cláusula WHERE
Especifica una condición de búsqueda para restringir las filas que se van a
devolver. Su sintaxis es la siguiente:
[WHERE <condición_búsqueda> | <nombre_columna {*= | *= }
nombre_columna>]
El argumento condición de búsqueda limita las filas devueltas en el conjunto
de resultados mediante el uso de predicados. No hay límite en el número de os que
se pueden incluir en una condición de búsqueda. El argumento columna { *= | = * }
nombre
_
columna especifica una combinación externa con la sintaxis antigua
específica SQL Server y la cláusula WHERE. Se utiliza el operador = para
especificar una combinación externa izquierda y el operador = para
especificar una combinación externa derecha. El conjunto de resultados puede
estar limitado por HAVING y LIMIT.
A continuación se exponen algunos ejemplos.
Listar todos los clientes de la provincia de Córdoba

SELECT *
FROM Cliente
WHERE provincia = ‘Córdoba’;

Listar todos los albaranes de fecha 2 de enero del 2005

SELECT *
FROM Albaran
WHERE fecha = “2005-01-02”;

Listar todos los pedidos cuyo número sea superior a 5 y la
forma de pago inferior a 3

SELECT *
FROM Pedido
WHERE npedido > 5 AND forma_pago < 3;

Listar todos los artículos pedidos (sin duplicados) con
precio superior a 1 o tengan un descuento del 10%

SELECT DISTINCT referencia
FROM lineapedido
WHERE precio > 1 OR dto = 0.1;
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 9 - 30L pa(a Vv30L. Lerduaje de Var|pu|ac|ór de 0alos Pád|ra 1ê3 de 20ê

Listar todos la referencia, unidades precio, descuento e
importe de venta de los artículos vendidos con importe
superior a 5 o no tengan descuento.

SELECT referencia, unidades, precio, dto, unidades * (precio
- precio * dto) AS importe
FROM lineaalbaran
WHERE unidades * (precio - precio * dto) > 5 OR dto = 0;
Cláusula GROUP BY
Especifica las agrupaciones que se van a realizar en las filas de salida y, en
caso de incluir funciones de agregado como COUNT o MAX en la cláusula SELECT
lista _selección, calcula el valor de resumen de cada grupo. Cuando se especifica
GROUP BY, cada columna que no esté en una expresión de agregado de la lista de
selección se debe incluir en la lista de GROUP BY o la expresión GROUP BY debe
coincidir exactamente con la expresión de la lista de selección. Su sintaxis es:
[GROUP BY expresión de agrupamiento]
La expresión de agrupamiento especifica la expresión en la que se realiza el
agrupamiento o columna de agrupamiento y puede ser una columna o una
expresión diferente a una de agregado que hace referencia a una columna. No se
puede utilizar un alias de columna en la lista de selección para especificar una
columna de agrupamiento.
Si no se especifica la cláusula ORDER BY, los grupos devueltos con la
cláusula GROUP BY no estarán en un orden particular. Se recomienda que siempre
utilice la cláusula ORDER BY con GROUP BY para especificar un orden determinado
de los datos. A continuación vienen algunos ejemplos:
Listar la referencia y el total de unidades vendidas por
artículo

SELECT referencia, SUM(unidades)
FROM lineaalbaran
GROUP BY referencia;

Listar la referencia y el precio medio por artículo pedido.

SELECT referencia, AVG(precio)
FROM lineapedido
GROUP BY referencia;

Listar el precio máximo y el mínimo de un artículo por pedido

SELECT npedido, MAX(precio), MIN(precio)
FROM lineapedido
GROUP BY npedido;
Cláusula HAVING
Especifica una condición de búsqueda de un grupo o agregado y
normalmente se utiliza con la cláusula GROUP BY. Cuando no se utiliza GROUP BY,
HAVING se comporta como la cláusula WHERE. Su sintaxis es la siguiente:
[HAVING condición búsqueda]
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 9 - 30L pa(a Vv30L. Lerduaje de Var|pu|ac|ór de 0alos Pád|ra 1ê1 de 20ê
El argumento condición búsqueda especifica la condición de búsqueda del
grupo o del agregado que se debe cumplir.
HAVING especifica una expresión secundaria que se usa para limitar filas
después de que éstas hayan satisfecho las condiciones citadas en la cláusula
WHERE. Las filas que no satisfagan la condición HAVING serán rechazadas en el
resultado de la consulta.
HAVING suele usarse para expresiones que implican resúmenes de funciones
que no pueden ser examinadas por la cláusula WHERE. De todas formas, si una
condición de búsqueda es legal tanto en la cláusula WHERE como en la cláusula
HAVING, es preferible situarla en la primera, porque así estará sujeta a un posible
análisis por el optimizador.
Listar el número de pedido, importe total del pedido que
superen 700 .

SELECT npedido, SUM( unidades * (precio - precio * dto) )
AS importe
FROM lineapedido
GROUP BY npedido
HAVING importe > 700;

Listar el número de albaran, media de las unidades vendidas
por albarán que sean inferior a 30 unidades.

SELECT nalbaran, AVG(unidades) AS Unidad_Media
FROM lineaalbaran
GROUP BY nalbaran
HAVING Unidad_Media < 30;

Listar la referencia de artículo, unidades mínimas pedidas de
cada uno, si son superiores a 10;

SELECT referencia, MIN(unidades) AS Unidad_Minima
FROM lineapedido
GROUP BY referencia
HAVING Unidad_Minima > 10;

Listar la referencia de artículo, precio máximo vendido de
cada uno, si es igual a 1.5

SELECT referencia, MAX(precio) AS Precio_Maximo
FROM lineaalbaran
GROUP BY referencia
HAVING Precio_Maximo = 1.5;
Cláusula ORDER BY
Con esta cláusula se especifica el orden del conjunto de resultados. La
cláusula ORDER BY no es válida en vistas, funciones en línea, tablas derivadas ni
subconsultas, salvo que se especifique también TOP. Su sintaxis es la siguiente:
ORDER BY { expresion order by [ASC|DESC] }[ , ...n]
El argumento expresión order by especifica la columna según la que se
realiza la ordenación. Se puede especificar una columna de orden como un nombre
o alias de columna (que puede estar calificado con el nombre de una tabla), una
expresión y en algunas versiones de SQL un entero no negativo que representa la
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 9 - 30L pa(a Vv30L. Lerduaje de Var|pu|ac|ór de 0alos Pád|ra 1ê5 de 20ê
posición del nombre, alias o expresión en la lista de selección. También se pueden
especificar varias columnas de orden. La secuencia de columnas de orden en la
cláusula ORDER BY define la estructura del conjunto ordenado de resultados. La
cláusula ORDER BY puede incluir elementos que no aparecen en la lista de
selección. Sin embargo, si se especifica SELECT DISTINCT, o si la instrucción
SELECT contiene un operador UNION, las columnas ordenadas deben aparecer en
la lista de selección. Además, cuando la instrucción SELECT contiene un operador
UNION, los nombres o los alias de las columnas deben ser los especificados en la
primera lista de selección.
El argumento ASC indica que los valores de la columna especificada se
deben ordenar de manera ascendente (orden por defecto), desde el valor más bajo
al más alto. El argumento DESC indica que los valores de la columna especificada
se deben ordenar de manera descendente, desde el valor más alto al valor más
bajo. Los valores NULL se tratan como los valores más bajos posibles. No hay límite
para el número de elementos en una cláusula ORDER BY.
Listar los clientes ordenados por razón social

SELECT *
FROM Cliente
ORDER BY 2;

Listar las líneas de albaran ordenadas por número de albarán
y precio

SELECT *
FROM lineaalbaran
ORDER BY nalbaran, precio;

Listar las líneas de pedido ordenadas descendentemente por
número de pedido y ascendentemente por precio.
SELECT *
FROM lineapedido
ORDER BY npedido DESC, precio;
Listar los pedidos ordenados por fecha descendentemente

SELECT *
FROM Pedido
ORDER BY fecha DESC;
Cláusula LIMIT
La claúsula LIMIT se utiliza para seleccionar una sección de filas del conjunto
de resultados. Su sintaxis admite las dos opciones siguientes:
[LIMIT n]
[LIMIT m, n]
La primera opción de sintaxis devuelve las primeras n filas de la selección.
La segunda opción de sintaxis devuelve n las a partir de la fila m. Para LIMIT las
filas se numeran comenzando por la 0, no por la 1.
Listar los primeros 10 clientes

SELECT *
FROM Cliente
LIMIT 10;

Listar los 5 pedidos con importe más alto.
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 9 - 30L pa(a Vv30L. Lerduaje de Var|pu|ac|ór de 0alos Pád|ra 1êê de 20ê

SELECT npedido, SUM( unidades * (precio - precio * dto) ) AS
Importe
FROM lineapedido
GROUP BY npedido
ORDER BY Importe DESC
LIMIT 5

Listar los 20 artículos más baratos
SELECT *
FROM Articulo
ORDER BY precio_venta
LIMIT 20;

Listar los pedidos del décimo al trigésimo

SELECT *
FROM Pedido
ORDER BY npedido
LIMIT 10,20;
Renombrar columnas. Cláusula AS
SQL puede utilizar en la salida nombres de columnas distintos a los reales.
La cláusula AS se puede usar para cambiar el nombre de una columna del conjunto
de resultados o para asignar un nombre a una columna calculada. Cuando se define
una columna del conjunto de resultados mediante una referencia a la columna de
una tabla o vista, el nombre de la columna del conjunto de resultados es el mismo
que el nombre de la columna a la que se hace referencia, pero la cláusula AS se
puede usar para asignar un nombre distinto, o alias, a la columna del conjunto de
resultados. Esto se puede hacer para mejorar la comprensión. Por ejemplo, en la
consulta anterior se ha empleado el alias Importe para nombrar a una columna
calculada. Si se desea la cláusula AS puede omitirse, simplemente encerrando
entre comillas dobles el alias a continuación de la columna. Así, podemos reescribir
el ejemplo anterior de la siguiente manera
SELECT npedido, SUM( unidades * (precio - precio * dto) )
“Importe”
FROM lineapedido
GROUP BY npedido
ORDER BY 2 DESC
LIMIT 5
Aunque entonces no puede utilizarse el alias para especificar la columna de
ordenación, por eso se ha puesto el número de columna.
CON$bLIA$ CON CONDICIONE$ DE 8b$QbEDA
SQL permite realizar consultas que contienen condiciones de búsqueda de
modo que los resultados son precisamente los que cumplen las citadas condiciones.
La comprobación del cumplimiento de las condiciones es como un test o contraste.
De hecho, las condiciones de búsqueda suelen agruparse en contrastes de
comparación (comparan el valor de una expresión con el valor de otra), contrastes
de rango (examinan si el valor de una expresión cae dentro de un rango dado),
contrastes de pertenencia a un conjunto (comprueban si e valor de una expresión
pertenece a un conjunto dado), contrastes de correspondencia con patrón
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 9 - 30L pa(a Vv30L. Lerduaje de Var|pu|ac|ór de 0alos Pád|ra 1êZ de 20ê
(comprueban si los datos cumplen un patrón dado) y contrastes de valor nulo
(comprueban si existen valores nulos en las columnas).
Todas las condiciones de búsqueda hay que especificarlas dentro de la
cláusula WHERE de la sentencia SELECT.
Test de comparación
Mediante los test de comparación, SQL calcula y compara los valores de dos
expresiones SQL para cada fila de datos utilizando los operadores de comparación
de SQL (=, <>, <, <=, >, >=). Por ejemplo
Listar todas las facturas con fecha posterior al 1/1/2004

SELECT *
FROM Factura
WHERE fecha > "2004/1/1";

Listar la referencia, descripción y precio de venta de los
artículos cuyo precio de venta es inferior a los 2 .

SELECT referencia, descripcion, precio_venta
FROM Articulo
WHERE precio_venta < 2;

Listar los articulos que no sean de la familia ‘CONF’

SELECT *
FROM Articulo
WHERE familia <> ‘CONF’;

Listar los datos del cliente con nif 30000001A
SELECT *
FROM Cliente
WHERE nif = ‘30000001A'
Test de rango: Cláusula BETWEEN … AND
El contraste del rango comprueba si un valor se encuentra entre dos valores
dados. Por ejemplo
Listar la referencia, unidades, precio y dto de los artículos
pedidos que tienen las unidades entre 5 y 10

SELECT referencia, unidades, precio, dto
FROM LineaPedido
WHERE unidades BETWEEN 5 AND 10;

Listar la referencia y descripción de los articulos con
precio de venta entre 0.5 y 3

SELECT referencia, descripción
FROM Articulo
WHERE precio_venta BETWEEN 0.5 AND 3;

Listar los articulos cuya descripción comienza por la palabra
Bolsa

SELECT *
FROM Articulo
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 9 - 30L pa(a Vv30L. Lerduaje de Var|pu|ac|ór de 0alos Pád|ra 1ê8 de 20ê
WHERE descripcion BETWEEN ‘Bolsa’ AND ‘Bolsaz’;
Test de pertenencia a conjunto: Cláusula IN
Este tipo de consultas comprueba si un valor dado coincide con uno de una
lista de valores especificada. Por ejemplo
Listar el número de pedido, referencia y unidades de los
articulos que se han pedido con unidades 5, 10 o 15

SELECT npedido, referencia, unidades
FROM LineaPedido
WHERE unidades IN (5, 10, 15);

Listar la referencia, descripcion y precio de venta de los
articulos que pertenecen a la familia ‘CONF’ y ‘PESC’

SELECT referencia, descripcion, precio
FROM Articulo
WHERE familia IN (‘CONF’,’PESC’);

Listar el número y fecha de los albaranes con forma de pago
1, 2 o 3

SELECT nalbaran, fecha
FROM Albaran
WHERE forma_pago IN (1,2,3);

Listar los efectos de las facturas 1 y 5
SELECT *
FROM Efectos
WHERE nfactura IN (1,5);
Test de correspondencia con patro: Cláusula LIKE
Las consultas de correspondencia con patrón recuperan filas para las que el
contenido de una columna de texto se corresponde con un texto dado, es decir,
comprueban si el valor de una columna se ajusta a un patrón especificado. En este
tipo de consultas, el signo de porcentaje % se utiliza como comodín. Por
ejemplo
Listar la referencia, descripcion y precio_compra de los
artículos cuya descripción comience por ‘Zu’

SELECT referencia, descripcion, precio_compra
FROM Articulo
WHERE descripcion LIKE ‘Zu%’;

Dentro de la cláusula LIKE juega un papel importante el símbolo
subrayado bajo que representa exactamente una posición de carácter. La
diferencia entre el símbolo % y el símbolo subrayado bajo es significativa. En
primer lugar, el símbolo % permite cualquier número de caracteres, mientras que
el subrayado bajo permite sólo uno. En segundo lugar, el símbolo subrayado
siempre requiere que aparezca un carácter, mientras que en el símbolo % se
considera como una coincidencia la simple ausencia de carácter. Por ejemplo
Listar el nif, razón social y direccion de los clientes que
sean en cuya razón social aparece la letra ‘m’ en sexto lugar
y la letra ‘a’ en décimo lugar
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 9 - 30L pa(a Vv30L. Lerduaje de Var|pu|ac|ór de 0alos Pád|ra 1ê9 de 20ê

SELECT nif, razon_social, direccion
FROM Cliente
WHERE razon_social LIKE ‘_____m___a%’;
Test de valor nulo: Cláusula IS NULL
Suele ser muy útil comprobar los valores NULL existentes en una tabla y
manejarlos a nuestro antojo. Por ejemplo
Listar los efectos que tienen la cuenta corriente nula

SELECT *
FROM Efectos
WHERE cc IS NULL;

Listar la referencia, unidades, precio de venta y dto de los
artículos que se han vendido y proceden de un pedido.

SELECT referencia, unidades, precio, dto
FROM LineaAlbaran
WHERE npedido IS NOT NULL;
Condiciones compuestas. Operadores AND, OR y NOT
Muy a menudo suelen utilizarse condiciones de búsqueda compuestas que
envuelven los operadores AND, OR y NOT. Utilizando las reglas de la lógica se
pueden combinar condiciones de búsqueda SQL simples para formar condiciones
compuestas únicas.
Listar la referencia, descripción, precio de venta y precio
de compra de los artículos que no sean de la familia ‘BEBI’ y
su precio de venta está entre 1 y 2

SELECT referencia, descripcion, precio_venta, precio_compra
FROM Articulo
WHERE familia <> ‘BEBI’ AND precio_venta BETWEEN 1 AND 2;

Listar los clientes cuya razón social tenga ‘Supermercado’ o
sean de la población Córdoba

SELECT *
FROM Cliente
WHERE razon_social LIKE ‘%upermercado%’ OR población =
‘Córdoba’;

Listar el número, cliente, fecha y forma de pago de los
albaranes hechos el 4/1/2005 y la forma de pago no sea 4

SELECT nalbaran, cliente, fecha, forma_pago
FROM Albaran
WHERE fecha = “2005/1/4” AND NOT ( forma_pago = 5 );
CON$bLIA$ AGkbFADA$
SQL permite realizar consultas que permiten resumir los datos a través de
funciones de columna y mediante cláusulas GROUP BY, HAVING de la sentencia
SELECT. Las funciones de columna posibles ya se estudiaron en un capítulo
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 9 - 30L pa(a Vv30L. Lerduaje de Var|pu|ac|ór de 0alos Pád|ra 1Z0 de 20ê
anterior. Estas funciones aceptan una columna completa de datos como
argumentos y producen como salida un único dato que resume la columna. De ahí
que las consultas que contemplan funciones de este tipo se denominen consultas
resumen o consultas sumarias.
Funciones de agregado en la lista de selección
Las funciones de agregado (SUM, AVG, STD, COUNT, COUNT(*), MAX, MIN,
etc.) generan valores de resumen en los conjuntos de resultados de las consultas.
Una función de agregado procesa todos los valores seleccionados en una única
columna para generar un único resultado. Las funciones de agregado se pueden
aplicar a todas las filas de una tabla, a un subconjunto de la tabla especificado por
una cláusula WHERE o a uno o varios grupos de filas de la tabla. Cuando se aplica
una función de agregado, se genera un valor individual por cada conjunto de filas.
La palabra clave opcional DISTINCT se puede usar con SUM, AVG, STD y
COUNT para eliminar los valores duplicados antes de que se establezca la función
de agregado (el valor predeterminado es ALL). SUM, AVG y STD se pueden usar
sólo con columnas numéricas. MIN y MAX no se pueden usar con tipos de datos bit.
Por ejemplo
Listar las unidades máximas y mínimas de los artículos
pedidos en aquellos pedidos cuyo número está entre 1 al 10

SELECT MAX(unidades) AS Maximo, MIN(unidades) As Minimo
FROM LineaPedido
WHERE npedido BETWEEN 1 AND 10;

Listar el último cliente alfabético por la razón social

SELECT MAX(razon_social)
FROM Cliente;

Listar el importe medio de los artículos vendidos en los
albaranes que no preceden de un pedido.

SELECT AVG( unidades * ( precio – precio * dto ) ) AS ImpMed
FROM LineaAlbaran
WHERE npedido IS NULL;

Listar el precio de venta del artículo más caro de aquellos
que se hayan vendido más de 100 unidades

SELECT MAX(precio_venta)
FROM Articulo
WHERE und_vendidas > 100;

Listar el pedido con total más pequeño de aquellos pedidos
posteriores al 1 de enero del 2005

SELECT MIN( total_pedido)
FROM Pedido
WHERE fecha > “2005-01-01”;
El tipo de resultado que devuelve una función de agregado puede tener una
precisión mayor que las entradas, de modo que es lo suficientemente grande
como para contener el valor del resultado de agregado. Por ejemplo, las
funciones SUM o AVG devuelven un valor int cuando el tipo de datos de entrada es
smallint.
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 9 - 30L pa(a Vv30L. Lerduaje de Var|pu|ac|ór de 0alos Pád|ra 1Z1 de 20ê
Las funciones de agregado no se pueden usar en una cláusula WHERE. Sin
embargo, una instrucción SELECT con funciones de agregado en su lista de
selección incluye, a menudo, una cláusula WHERE que restringe las filas a las que
aplica la función de agregado.
Si una instrucción SELECT incluye una cláusula WHERE (aunque no una
cláusula GROUP BY), una función de agregado produce un valor individual para el
conjunto de filas especificado por la cláusula WHERE. Esto es cierto tanto si está
operando en todas las filas de una tabla como si opera sólo en un subconjunto de
filas definido por una cláusula WHERE. Una función de este tipo recibe el nombre de
agregado escalar.
Función COUNT
La función COUNT( ) devuelve el número de elementos de un grupo, por
ejemplo, el número de valores de datos de una columna. Su sintaxis es la
siguiente:
COUNT ( { [ ALL | DISTINCT expresión ] | * } )
El argumento ALL aplica la función de agregado a todos los valores. ALL es
el valor predeterminado. El argumento DISTINCT especifica que COUNT devuelva el
número de valores únicos (distintos) no NULL de la columna. El argumento
expresión es una expresión de cualquier tipo excepto funciones de agregado y
subconsultas. El argumento * especifica que se tienen que contar todas las filas
para devolver el número total de filas de una tabla. COUNT(*) no recibe
parámetros y no se puede utilizar con DISTINCT. COUNT(*) no requiere el
parámetro expresión porque, por definición, no utiliza información acerca de
ninguna columna concreta. COUNT(*) devuelve el número de filas de una tabla
especificada sin eliminar las duplicadas. Cuenta todas las filas, incluidas las que
contienen valores NULL.
En las consultas SQL se pueden utilizar agregados relativos a los elementos
diferentes de una determinada columna, por ejemplo AVG(DISTINCT columna),
COUNT(DISTINCT columna), STD(DISTINCT columna), SUM(DISTINCT columna)
etc.
COUNT(*) devuelve el número de elementos de un grupo incluidos los
valores NULL y duplicados. COUNT(ALL expresión) evalúa expresión en todas las
filas del grupo y devuelve el número de valores no NULL. COUNT(DISTINCT
expresión) evalúa expresión en todas las filas del grupo y devuelve el número de
valores únicos no NULL.
Listar el número de representantes que hay

SELECT COUNT(*)
FROM Representante;

Listar el número de clientes que han hecho pedido

SELECT COUNT( DISTINCT cliente )
FROM Pedido;

Listar el número de clientes que son supermercado

SELECT COUNT(*)
FROM Clientes
WHERE razon_social LIKE ‘%upermercado%’;
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 9 - 30L pa(a Vv30L. Lerduaje de Var|pu|ac|ór de 0alos Pád|ra 1Z2 de 20ê
Valores NULL en las funciones de agregado
Para trabajar con valores NULL en funciones de agregado sobre columnas,
es necesario tener presente que si alguno de los valores de la columna es NULL, se
ignora para calcular el valor de la función de agregado relativa a la columna.
Además, si todos los valores de la columna son NULL, las funciones de
columna SUM, AVG, STD, MIN y MAX devuelven un valor NULL y la función COUNT
devuelve un valor de cero. Si la columna no tiene datos, las funciones de agregado
devolverán el valor cero.
Tratamiento de filas duplicadas con DISTINCT
La palabra clave DISTINCT es opcional con SUM, AVG, STD y COUNT.
Cuando se usa DISTINCT, los valores duplicados se eliminan antes de que se
calcule la suma, el promedio, la desviación típica o el recuento. Si se usa
DISTINCT, la expresión sólo debe constar del nombre de una columna y no puede
incluir una expresión aritmética.
DISTINCT sólo puede ser especificada una vez en una consulta. Si aparece
en el argumento de una función de columna no puede aparecer en ninguna otra. Si
se especifica delante de la lista de selección no puede aparecer en ninguna función
de columna. DISTINCT sólo puede ser especificada por segunda vez dentro de una
subconsulta. Veamos la diferencia en un ejemplo
Listar cuantas formas de envio se han utilizado en los
albaranes

SELECT COUNT( forma_envio )
FROM Albaran;

Listar cuantas formas de envio diferentes se han utilizado en
los albaranes.

SELECT COUNT( DISTINCT forma_envio )
FROM Albaran;
Agrupar filas con GROUP BY
La cláusula GROUP BY se usa para producir valores de agregado para cada
fila del conjunto de resultados. Cuando se usan sin una cláusula GROUP BY, las
funciones de agregado sólo devuelven un valor de agregado para la instrucción
SELECT.
Listar el número de pedido y su importe total

SELECT npedido, SUM( unidades * (precio – precio * dto ) )
FROM LineaPedido
GROUP BY npedido;

Listar la media de las unidades de los artículos vendidos que
proceden de Pedidos

SELECT referencia, AVG(unidades)
FROM LineaAlbaran
WHERE npedido IS NOT NULL
GROUP BY referencia;

lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 9 - 30L pa(a Vv30L. Lerduaje de Var|pu|ac|ór de 0alos Pád|ra 1Z3 de 20ê
Listar la media de total de pedido por cliente de los pedidos
con fecha del 1 al 4 de enero del 2005.

SELECT cliente, AVG(total_pedido)
FROM Pedido
WHERE fecha BETWEEN “2005-01-01” AND “2005-01-04”
GROUP BY cliente;
A continuación de las palabras clave GROUP BY, se coloca una lista de
columnas, conocidas como las columnas de agrupamiento. La cláusula GROUP BY
restringe las filas del conjunto de resultados; sólo hay una fila por cada valor
distinto de la columna o columnas de agrupamiento. Cada fila del conjunto de
resultados contiene los datos de resumen relacionados con el valor específico de
sus columnas de agrupamiento.
Hay restricciones en los elementos que se pueden especificar en la lista de
selección cuando una instrucción SELECT contiene una cláusula GROUP BY. Los
elementos permitidos en la lista de selección son las columnas de agrupamiento y
las expresiones que devuelven un solo valor por cada valor de las columnas de
agrupamiento, como, por ejemplo, las funciones de agregado que tienen un
nombre de columna como uno de sus parámetros. Éstas se conocen como
agregados vectoriales.
SQL permite realizar consultas agrupando resultados en base a múltiples
columnas de agrupamiento. Por ejemplo
Listar los unidades totales vendidas agrupadas por pedido y
articulo

SELECT npedido, referencia, SUM( unidades )
FROM LineaPedido
GROUP BY npedido, referencia;
Si además de agrupar los datos, se necesita ordenarlos, es posible utilizar la
cláusula ORDER BY y la cláusula GROUP BY, simultáneamente.
La cláusula GROUP BY contiene los siguientes componentes:
• Una o más expresiones sin agregados. Normalmente, suelen ser
referencias a las columnas de agrupación.
• Opcionalmente, la palabra clave ALL, que especifica que se devuelvan
todos los grupos generados por la cláusula GROUP BY, incluso si
alguno de los grupos no tiene filas que cumplan las condiciones de
búsqueda.
• Normalmente, la cláusula HAVING se usa junto con la cláusula
GROUP BY, aunque también se puede especificar sin ella.
Puede agrupar por una expresión siempre que no incluya funciones de
agregado. En una cláusula GROUP BY, debe especificar el nombre de una columna
de tabla o vista, no el nombre de una columna del conjunto de resultados asignada
con una cláusula AS.
Puede usar una cláusula WHERE en una consulta que contenga una
cláusula GROUP BY. Las filas que no cumplan las condiciones de la cláusula
WHERE son eliminadas antes de que se realice el agrupamiento.
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 9 - 30L pa(a Vv30L. Lerduaje de Var|pu|ac|ór de 0alos Pád|ra 1Z1 de 20ê
Si la columna de agrupamiento contiene un valor NULL, esa fila se
convierte en un grupo en los resultados. Si la columna de agrupamiento contiene
varios valores NULL, éstos se colocan en un grupo individual.
Si se usa ALL, los resultados de la consulta incluyen todos los grupos
generados por la cláusula GROUP BY, incluso si alguno de los grupos no tiene filas
que cumplan las condiciones. Sin ALL, una instrucción SELECT que incluye GROUP
BY no muestra los grupos cuyas filas no cumplen los criterios de selección.
La cláusula HAVING establece las condiciones de la cláusula GROUP
BY de la misma forma que WHERE interactúa con SELECT. Mientras que las
condiciones de búsqueda de WHERE se aplican antes de que se produzca la
operación de agrupamiento, las condiciones de búsqueda de HAVING se aplican
después. La sintaxis de la cláusula HAVING es similar a la de la cláusula WHERE,
con la diferencia de que HAVING puede contener funciones de agregado. Las
cláusulas HAVING pueden hacer referencia a cualquiera de los elementos que
aparecen en la lista de selección.
Listar el dni del cliente y el importe total de sus pedidos
si superan 15000

SELECT cliente, SUM(total_pedido)
FROM Pedido
GROUP BY cliente
HAVING SUM(total_pedido) > 15000;
La comprensión de la secuencia correcta en la que se aplican las cláusulas
WHERE, GROUP BY y HAVING ayuda a codificar consultas que sean eficientes:
• La cláusula WHERE se utiliza para filtrar las filas que resultan de las
operaciones especificadas en la cláusula FROM.
• La cláusula GROUP BY se usa para agrupar el resultado de la cláusula
WHERE.
• La cláusula HAVING se usa para filtrar las filas del resultado
agrupado.
Es más eficiente especificar en la cláusula WHERE las condiciones de
búsqueda que se pueden establecer antes o después de la operación de
agrupamiento. Esto reduce el número de filas que tienen que agruparse.
Las únicas condiciones de búsqueda que se deben especificar en la cláusula
HAVING son aquellas que se deben aplicar una vez que se hayan realizado las
operaciones de agrupamiento. Cuando en HAVING se incluyen varias condiciones,
se combinan mediante AND, OR o NOT. Por ejemplo
Listar las formas de pago, su importe medio y su importe
total en los albaranes para cada una de ellas, si el importe
medio supera los 150 y el importe total es inferior a 500

SELECT forma_pago, AVG(total_albaran), SUM(total_albaran)
FROM Albaran
GROUP BY forma_pago
HAVING AVG(total_albaran) > 150 AND SUM(total_albaran) < 500;
También es posible establecer en una cláusula HAVING una condición que
implique a una función de agregado que no aparece en la lista de selección, como
en el siguiente ejemplo.
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 9 - 30L pa(a Vv30L. Lerduaje de Var|pu|ac|ór de 0alos Pád|ra 1Z5 de 20ê
Listar la referencia del artículo y unidades totales vendidas
para cada uno, siempre que tengan más de 5 líneas de albarán.

SELECT referencia, SUM(unidades)
FROM LineaAlbaran
GROUP BY referencia
HAVING COUNT(*) > 5;
$b8CON$bLIA$ EN MY$QL
Hasta la versión 4.1, MySQL no soportaba las consultas. Esto era una
limitación bastante importante y la decisión de incorporarla fue debido a la solicitud
masiva por parte de los usuarios de MySQL, ya que limitaba bastante la gestión de
una base de datos. Tal y como se vio en el capítulo anterior, una subconsulta es
una consulta que aparece dentro de una cláusula WHERE o HAVING. Vamos a ver
las subconsultas usando con las cláusulas utilizadas habitualmente con ellas.
Test de comparación de subconsulta (=, <>, <, <=, <, >=)
Se compara el valor de una expresión SQL con el valor que devuelve una
subconsulta. Es obligatorio que la subconsulta produzca una único valor, ya que de
lo contrario se produciría un error. Vamos a ver algunos ejemplos
Listar la referencia, descripción y precio de venta de los
artículos cuyo precio de venta es igual o superior al precio
medio de venta de los artículos pedidos con más de 4
unidades.

SELECT referencia, descripcion, precio_venta
FROM Articulo
WHERE precio_venta > (SELECT AVG(precio)
FROM LineaPedido
WHERE unidades > 4 );

Listar la referencia, unidades y precio de venta de los
artículos pedidos cuyas unidades sean superiores o iguales a
las unidades mínimas vendidas de ese mismo artículo

SELECT referencia, unidades, precio_venta
FROM LineaPedido
WHERE unidades >= (SELECT MIN(unidades)
FROM LineaAlbaran LA
WHERE LA.referencia = LP.referencia );
Test de pertenencia a conjunto. Cláusula IN
El test de pertenencia a conjunto en una subconsulta compara un único
valor con una columna de valores resultado de una subconsulta. Si el valor coincide
con uno de los valores de la subconsulta devuelve TRUE. Por ejemplo
Listar el nif, razón social y teléfono de los clientes que
han hecho pedido en el mes de enero del 2004

SELECT nif, razon_social, telefono
FROM Cliente
WHERE nif IN ( SELECT cliente
FROM Pedido
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 9 - 30L pa(a Vv30L. Lerduaje de Var|pu|ac|ór de 0alos Pád|ra 1Zê de 20ê
WHERE fecha BETWEEN “2005/1/1” AND
“2005/1/31”);

Listar la forma de pago y su descripción de aquellas formas
de pago que no se han utilizado en los albaranes.

SELECT forma_pago, descripcion
FROM Forma_Pago
WHERE forma_pago NOT IN (SELECT DISTINCT forma_pago
FROM Albaran);

Test de existencia. Cláusula EXISTS
El test de existencia comprueba si una subconsulta produce algún resultado.
Este operador solamente puede usarse con subconsultas. Por ejemplo
Listar los clientes que tienen al menos un albaran con forma
de pago 3.

SELECT *
FROM Cliente
WHERE EXISTS ( SELECT *
FROM Albaran
WHERE cliente = nif
AND forma_pago = 3 );

Listar el nif y nombre del representante que haya hecho
pedidos

SELECT nif, nombre, apellidos
FROM Representante
WHERE EXIST( SELECT *
FROM Ped-Rep
WHERE representante = nif );

Listar listar los clientes que tienen por lo menos 3 pedidos.

SELECT *
FROM Cliente
WHERE EXISTS( SELECT COUNT(*) AS Pedidos
FROM Pedido
WHERE cliente = nif
HAVING Pedidos > 3 );
Test cuantificado ANY
El test de pertenencia a conjunto se puede extender con el test cuantificado
ANY que permite saber si un dato cumple un test de comparación con alguno de un
conjunto de valores producidos por una subconsulta. Por ejemplo
Lista la referencia y la descripción de los artículos cuyo
precio de venta sea diferente a alguno de los precios a los
que se ha vendido ese artículo

SELECT referencia, descripcion
FROM Articulo AS A
WHERE precio_venta <> ANY (SELECT DISTINCT precio_venta
FROM LineaAlbaran AS LA
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 9 - 30L pa(a Vv30L. Lerduaje de Var|pu|ac|ór de 0alos Pád|ra 1ZZ de 20ê
WHERE LA.referencia =
A.referencia);

Listar las facturas cuya fecha sea inferior a alguna de las
fechas de vencimiento de sus efectos.

SELECT * FROM Facturas AS F
WHERE fecha < ANY (SELECT fecha_vto
FROM Efectos AS E
WHERE E.nfactura = F.nfactura);
Podemos ver que existe una cierta similitud entre la cláusula IN, el
operador = con la cláusula ANY y la cláusula EXISTS. A continuación se pone un
ejemplo donde se puede ver como con una sentencia SELECT puede obtenerse el
mismo resultado con las tres diferentes formas diferentes.
Listar los clientes que han hecho pedido el día 3/1/2005

SELECT *
FROM Cliente
WHERE nif IN ( SELECT DISTINCT cliente
FROM Pedido
WHERE DATE(fecha) = “2005-01-03”);

SELECT *
FROM Cliente
WHERE EXISTS ( SELECT *
FROM Pedido
WHERE cliente = nif
AND DATE(fecha) = “2005-01-03”);

SELECT *
FROM Cliente
WHERE nif = ANY ( SELECT DISTINCT cliente
FROM Pedido
WHERE DATE(fecha) = “2005-01-03”);
Subconsultas anidadas
MySQL admite anidar subconsultas, es decir una subconsulta es consulta
principal de otra subconsulta. No existe límite de anidamiento, pero a partir del
cuarto, la sentencia se vuelve complicada y difícil de entender. A continuación se
pone un ejemplo con una consulta principal y dos anidadas.
Listar el nif y el nombre de los representantes que tienen
pedidos hechos el 3 de enero del 2005.

SELECT dni, nombre
FROM Representante
WHERE dni IN (SELECT dni
FROM Ped-Rep
WHERE npedido IN (SELECT npedido
FROM Pedido
WHERE Date(fecha) = “2005-
01-03”) );
Como se puede ver en el ejemplo, el sangrado de las sentencias SELECT es
muy útil para aumentar la legibilidad y comprensión de la sentencia. La dificultad
de una sentencia con más de dos subconsultas puede atenuarse cuando dos o más
subconsultas están al mismo nivel de anidamiento. Por ejemplo
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 9 - 30L pa(a Vv30L. Lerduaje de Var|pu|ac|ór de 0alos Pád|ra 1Z8 de 20ê
Listar los clientes que han pedido más de 5 unidades de
artículos y la forma de pago es ‘Giro 30 días’

SELECT nif, razon_social
FROM Cliente
WHERE nif IN (SELECT cliente
FROM Pedido
WHERE npedido IN (SELECT npedido
FROM LineaPedido
WHERE unidades > 5 )
AND forma_pago = (SELECT forma_pago
FROM Forma_Pago
WHERE descripcion = ‘Giro 30
días’) );
Subconsultas en cláusula HAVING
A continuación se expone un ejemplo de subconsulta empleada en la
cláusula HAVING. Recordemos que en esta cláusula se ponen condiciones que
afectan a grupos, seleccionando aquellos que cumplen la condición.
Listar la referencia y el precio medio de aquellos artículos
vendidos cuyo precio medio supere el precio medio de todos
los artículos pedidos.

SELECT referencia, AVG(precio) AS precio_medio
FROM LineaAlbaran
GROUP BY referencia
HAVING precio_medio > (SELECT AVG (precio)
FROM LineaPedido );

Listar el número de albarán e importe total del albarán para
aquellos albaranes que superen a alguno de los importes
totales de los pedidos.

SELECT nalbaran, SUM( unidades * ( precio – precio * dto ) )
AS Importe
FROM LineaAlbaran
GROUP BY nalbaran
HAVING Importe > ANY ( SELECT SUM( unidades * ( precio –
precio * dto) )
FROM LineaPedido
GROUP BY npedido );
CON$bLIA$ MbLIIIA8LA EN MY$QL
Las consultas multitabla o JOINS, también denominadas combinaciones o
composiciones, permiten recuperar datos de dos tablas o más según las relaciones
lógicas entre ellas. Las combinaciones indican cómo debería utilizar SQL Server los
datos de una tabla para seleccionar las filas de otra tabla.
Una condición de combinación (o composición) define la forma en la que dos
tablas se relacionan en una consulta al:
Especificar la columna de cada tabla que debe usarse para la combinación.
Una condición de combinación típica especifica una clave externa de una tabla y su
clave primaria asociada en otra tabla.
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 9 - 30L pa(a Vv30L. Lerduaje de Var|pu|ac|ór de 0alos Pád|ra 1Z9 de 20ê
Especificar un operador relacional (=, <>, etc.) para usarlo en los valores de
comparación de las columnas. Por ejemplo
Listar el número de pedido, fecha, cliente, razón social y
total pedido

SELECT npedido, fecha, nif, razon_social, total_pedido
FROM Pedido, Cliente
WHERE nif = cliente;
En la consulta anterior combina las tablas Pedidos y Clientes (que se
separan por comas en la cláusula FROM) mostrando el número de pedido, fecha y
su total y el nif de cliente y su razón social, utilizando para la combinación la
columna cliente de la tabla Pedidos y la columna cliente de la tabla Clientes
mediante el operador relacional =.
Cuando en una consulta simple se hace referencia a múltiples tablas,
ninguna de las referencias a las columnas debe ser ambigua. Cualquier nombre de
columna que esté duplicado en varias tablas a las que se hace referencia en la
consulta debe estar precedido del nombre de la tabla y de un punto. Por ejemplo,
el campo npedido de la tabla Pedido se referenciará como Pedido.npedido.
Cuando el nombre de una columna no está duplicado en varias de las tablas
usadas en la consulta, las referencias al mismo no tienen que calificarse con el
nombre de la tabla. Algunas veces, una instrucción SELECT es dificil de entender
porque no hay nada que indique qué tabla ha suministrado cada columna. Se
puede mejorar la comprensión de la consulta si todas las columnas se califican con
sus nombres de tabla. La comprensión puede aumentarse más si se usan alias de
tabla.
Joins de dos tablas
Un JOIN de dos tablas es una composición entre las mismas basada en la
coincidencia exacta (u otro tipo de comparación) de dos columnas, una de cada
tabla. El JOIN forma parejas de filas haciendo coincidir los contenidos de las
columnas relacionadas. Por ejemplo
Listar el número de albarán, fecha, referencia de artículo,
unidades, precio y dto.

SELECT A.nalbaran, A.fecha, LA.referencia, LA.unidades,
LA.precio, LA.dto
FROM Albaran A, LineaAlbaran LA
WHERE A.nalbaran = LA.nalbaran;

Listar la referencia de artículo, descrición, unidades y
precio de los artículos pedidos

SELECT A.referencia, A.descripcion, LP.unidades, LP.precio
FROM Articulo A, LineaPedido LP
WHERE A.referencia = LP.referencia;

Listar el número de factura, fecha de factura, número de
efecto, fecha de vencimiento de todos los efectos

SELECT F.nfactura, F.fecha, E.nefecto, E.fecha_vto
FROM Factura F, Efectos E
WHERE F.nfactura = E.nfactura;
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 9 - 30L pa(a Vv30L. Lerduaje de Var|pu|ac|ór de 0alos Pád|ra 180 de 20ê
La consulta de un JOIN de dos tablas tiene el mismo aspecto que cualquier
consulta realizada con SELECT, pero presenta dos características novedosas. En
primer lugar, la cláusula FROM presenta dos tablas separadas por una coma. En
segundo lugar la condición de búsqueda compara columnas de dos tablas
diferentes. Además, como toda condición de búsqueda, restringe las filas que
aparecen en el resultado de la consulta. Dado que se trata de una consulta que
afecta a dos tablas, la condición de búsqueda restringe las parejas de filas que
generan los resultados.
Podríamos decir que la consulta anterior genera resultados sólo para los
pares de filas en los que el nif de cliente (cliente) en la tabla Pedidos coincide el nif
de cliente (nif) en la tabla Clientes.
Las consultas multitabla más comunes implican a dos tablas que tienen una
relación natural padre/hijo. En la consulta anterior, cada pedido (hijo) tiene un
cliente asociado (padre), y cada cliente (padre) puede tener muchos pedidos
asociados (hijos). Los pares de filas que generan los resultados de la consulta son
combinaciones de fila padre/hijo. En términos de clave primaria/clave foránea, la
tabla que contiene la clave foránea es el hijo en la relación y la tabla que contiene
la clave primaria es el padre. En la consulta debe especificarse una condición de
búsqueda que compare la clave foránea y la clave primaria.
JOINS con criterios de selección de filas
La condición de búsqueda de un JOIN no tiene por qué ser la única condición
de búsqueda presente en una consulta multitabla, ya que puede combinarse con
otras condiciones de búsqueda que restrinjan aún más las filas devueltas en el
resultado. Por ejemplo
Listar la referencia, descripcion, unidades, precio y
descuento de los artículos vendidos que no tienen pedido

SELECT A.referencia, A.descripcion, LA.unidades, LA.precio,
LA.dto
FROM Articulo A, LineaAlbaran LA
WHERE A.referencia = LA.referencia AND LA.npedido IS NULL;

Listar el número de pedido, fecha, cliente, razón social de
aquellos pedidos con forma de pago 2, 3 o 5

SELECT P.npedido, P.fecha, P.cliente, C.razon_social
FROM Pedido P, Cliente C
WHERE P.cliente = C.nif AND P.forma_pago IN( 2, 3, 5 );

Listar el número de factura, fecha de factura, número de
efecto y fecha de vencimiento de aquellos efectos que tengan
el vencimiento a más de 30 días con respecto a la fecha de
factura

SELECT F.nfactura, F.fecha, E.nefecto, E.fecha_vto
FROM Factura F, Efectos E
WHERE F.nfactura = E.nfactura
AND DATEDIFF(E.fecha_vto, F.fecha) > 30;
JOINS con múltiples columnas de emparejamiento
Cuando dos tablas están relacionadas por varias relaciones clave
foránea/clave primaria, pueden especificarse ambos pares de columnas de
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 9 - 30L pa(a Vv30L. Lerduaje de Var|pu|ac|ór de 0alos Pád|ra 181 de 20ê
emparejamiento en la condición de búsqueda del JOIN. Por ejemplo, las columnas
npedido y nlineap de la tabla LineaAlbaran forman ambas una clave foránea para la
tabla LineaPedido emparejadas con las columnas npedido e nlinea (ambas forman
la clave primaria de la tabla LineaPedido). De esta forma, la consulta siguiente
realiza un Join con múltiples columnas de emparejamiento.
Listar la referencia, unidades vendidas, precio de venta,
unidades pedidas, precio de venta pedido de las líneas de
albarán que proceden de un pedido

SELECT LA.referencia, LA.unidades, LA.precio, LP.unidades,
LP.precio
FROM LineaAlbaran LA, LineaPedido LP
WHERE LA.npedido = LP.npedido
AND LA.nlineap = LP.nlinea;
JOINS de tres o más tablas
Un JOIN de tres o más tablas es una composición entre las mismas basada
en la coincidencia exacta (u otro tipo de comparación) de tres o más columnas, una
de cada tabla. El JOIN forma filas haciendo coincidir los contenidos de las columnas
relacionadas. Como ejemplo, en la consulta siguiente relacionaremos las tablas
Pedido, Clientes y LineaPedido para obtener la lista de los pedidos superiores a 1.000
C incluyendo el nombre del cliente que hizó el pedido y los artículos que el cliente pidió.
Listar el número de pedido, fecha, cliente, razón social,
referencia, unidades, precio y dto de los pedidos con total
superor a 1000

SELECT P.npedido, P.fecha, P.cliente, C.razon_social,
LP.referencia, LP.unidades, LP.precio, LP.dto
FROM Pedido P, Cliente C, LineaPedido LP
WHERE P.cliente = C.nif
AND P.npedido = LP.npedido
AND P.total_pedido > 1000;
La consulta se ha basado en que la columna cliente es clave foránea
para la tabla Clientes que enlaza cada pedido con el cliente que lo remitió. Por otra
parte, la columna npedido es una clave foránea para la tabla LineaPedido
que liga cada pedido con sus líneas.
La consulta siguiente relaciona la tabla Pedidos con la tabla Ped_Rep y con
la tabla Representante para producir una lista con los pedidos y el representante
que tomo cada uno de ellos.
Listar el número de pedido, fecha y nombre del representante
que tomó el pedido

SELECT P.npedido, P.fecha, R.nombre
FROM Pedido P, Ped_Rep PR, Representante R
WHERE P.npedido = PR.npedido
AND PR.dni = R.dni;
A continuación, se presenta una consulta que involucra a cuatro tablas (JOIN
cuádruple) para obtener los pedidos del día 3/1/2005 mostrando el nombre del
cliente que los ordenó, el vendedor que lo tomó y los artículos del pedido.
Listar el número de pedido, fecha, nombre del cliente que
hizo el pedido y nombre del representante para los pedidos
con fecha 3/1/2005
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 9 - 30L pa(a Vv30L. Lerduaje de Var|pu|ac|ór de 0alos Pád|ra 182 de 20ê

SELECT P.npedido, P.fecha, C.razon_social, R.nombre
FROM Pedido P, Cliente C, Representante R, Ped_Rep PR
WHERE P.cliente = Cliente.nif
AND P.npedido = PR.npedido
AND PR.dni = R.dni
AND P.fecha = “2005-01-03”;
Hasta aquí hemos visto ejemplos de consultas con JOINS puros
embargo, SQL no exige que las columnas de emparejamiento tengan relación
primaria/clave foránea. De hecho, dos columnas cualesquiera de dos tablas
pueden utilizarse como columnas de emparejamiento siempre y cuando los
subtipos de datos sean comparables, aunque no suele ser habitual ya que
denotan relaciones entre los datos más bien casuales que reales.
Listar el número de pedido, cliente, fecha de pedido, número
de albaran, cliente del albarán y fecha de albarán para
aquellos pedidos hechos el mismo día que los albaranes

SELECT P.npedido, P.cliente, P.fecha, A.nalbaran, A.cliente,
A.fecha
FROM Pedido P, Albaran A
WHERE P.fecha = A.fecha;
JOINS con condiciones de búsqueda sin igualdad
Sabemos que un JOIN de dos tablas es una composición entre las mismas
basada en la coincidencia exacta (u otro tipo de comparación) de dos columnas
(una de cada tabla) reflejada en la condición de búsqueda del JOIN.
Hasta aquí sólo hemos utilizado JOINS en los que en la condición de
búsqueda sólo aparece la igualdad; sin embargo, en la condición de búsqueda del
JOIN puede especificarse un operador lógico cualquiera (=, <>, etc.) para usarlo
en los valores de comparación de las columnas. El JOIN forma parejas de filas
haciendo cumplirse las condiciones del JOIN en los contenidos de las columnas
relacionadas.
Este tipo de combinaciones no es frecuente ya que en muchos casos
resultarían casí una multiplicación de tablas.
JOINS internos y externos
El concepto que conocemos hasta ahora de JOIN corresponde a lo que se
conoce como JOIN INTERNO u operación de composición que combina información
procedente de dos tablas mediante la formación de pares de filas relacionadas en
las dos tablas según la condición de búsqueda del JOIN. Los pares de filas que
forman la tabla compuesta son los de las columnas correspondientes en cada una
de las dos tablas que tienen el mismo valor. Por ejemplo
Listar los artículos con su referencia, descripción, familia
y descripción de la familia

SELECT A.referencia, A.descripcion, A.familia, F.descripcion
FROM Articulo A, Familia F
WHERE A.familia = F.familia;
En la consulta anterior, la cláusula FROM genera todas las combinaciones
posibles de filas de la tabla Artículos y de la tabla Familias produciendo la
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 9 - 30L pa(a Vv30L. Lerduaje de Var|pu|ac|ór de 0alos Pád|ra 183 de 20ê
tabla producto de las dos, cuyo número de filas es el producto de las filas de las
dos tablas. La cláusula WHERE introduce una restricción seleccionando únicamente
las filas de la tabla producto para las que la familia de la tabla Articulos coincide
con la familia de la tabla Familias. El Join Interno tiene una sintaxis propia. El
ejemplo anterior también se puede reescribir de la siguiente manera
Listar los artículos con su referencia, descripción, familia
y descripción de la familia

SELECT A.referencia, A.descripcion, A.familia, F.descripcion
FROM Articulo A INNER JOIN Familia ON A.familia = F.familia;
Cuando la clave externa de una tabla y la clave primaria de la otra tienen el
mismo nombre, puede emplearse la cláusula USING para realizar la combinación.
La consulta anterior quedaría así
Listar los artículos con su referencia, descripción, familia
y descripción de la familia

SELECT A.referencia, A.descripcion, A.familia, F.descripcion
FROM Articulo A INNER JOIN Familia USING( familia );
Si la clave externa que relaciona una tabla con la otra tuviera más de una
columna y se usará la cláusula USING, se pondrían entre paréntesis las columnas
separadas por comas.
Pero al comprobar esta última coincidencia (o emparejamiento) el JOIN
INTERNO es muy estricto y elimina del resultado las filas que provoquen el más
mínimo problema de emparejamiento (por ejemplo, los valores NULL de cualquiera
de los campos).
En nuestro ejemplo, hay varias formas de pago que no aparecen en
ningún pedido, por lo que estos registros no aparecerán en el resultado del
JOIN al no existir un emparejamiento estricto. Además, hay algunos pedidos
cuya forma de pago aparece con valor NULL.
Si queremos que este tipo de resultados, para los que no hay un
emparejamiento estricto entre las filas de la condición de búsqueda del JOIN,
aparezca en el resultado del JOIN, tenemos que acudir al concepto de JOIN
EXTERNO o composición externa. Por lo tanto, la composición externa relaja las
condiciones de la composición interna y aporta más información al resultado.
JOIN EXTERNO completo
Un JOIN EXTERNO completo es una ampliación de un JOIN INTERNO
simplemente JOIN) que contiene la siguiente información:
• El JOIN INTERNO (o JOIN) de las dos tablas.
• Por cada fila de la primera tabla que no haya correspondido a
ninguna fila la segunda tabla, se añade una fila a los resultados,
utilizando los valores las columnas de la primera tabla y suponiendo
un valor NULL para todas las columnas de la segunda tabla
correspondientes en el emparejamiento.
• Por cada fila de la segunda tabla que no haya correspondido a
ninguna fila de la primera tabla, se añade una fila a los resultados,
utilizando los valores de las columnas de la segunda tabla y suponiendo
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 9 - 30L pa(a Vv30L. Lerduaje de Var|pu|ac|ór de 0alos Pád|ra 181 de 20ê
un valor NULL para todas las columnas de la primera tabla
correspondientes en el emparejamiento.
En cuanto a notación, el Join Externo completo utiliza la sintaxis OUTER
JOIN en la cláusula FROM de la consulta y la sintaxis ON en lugar de la cláusula
WHERE que precede la condición de búsqueda del JOIN. Sin embargo, en las
actuales versiones de MySQL no está soportado el Join Externo.
JOIN EXTERNO izquierdo y derecho
En el apartado anterior hemos visto el JOIN EXTERNO completo, pero
también puede considerarse el JOIN EXTERNO IZQUIERDO, que se produce entre
dos tablas ofreciendo la siguiente información:
• El JOIN INTERNO (o JOIN) de las dos tablas.
• Por cada fila de la primera tabla que no haya correspondido a ninguna
fila de la segunda tabla, se añade una fila a los resultados, utilizando los
valores de las columnas de la primera tabla y suponiendo un valor NULL
para todas las columnas de la segunda tabla correspondientes en el
emparejamiento.
En cuanto a notación, el JOIN EXTERNO IZQUIERDO utiliza la sintaxis
LEFT JOIN en la cláusula FROM de la consulta y la sintaxis ON en lugar de la
cláusula WHERE que precede la condición de búsqueda del JOIN. También se puede
usar la cláusula USING cuando las columnas de combinación en ambas tablas tienen el
mismo nombre.
Listar el número de pedido, fecha, forma de pago y la
descripcion de la forma de pago de todos pedidos, aunque no
tengan la forma de pago NULL

SELECT P.npedido, P.fecha, P.forma_pago, FP.descripcion
FROM Pedido
LEFT JOIN FormaPago FP ON P.forma_pago = FP.forma_pago;
En el ejemplo anterior, la columna de combinación que relaciona las dos
tablas es forma_pago y se llama igual en las dos tablas. Cuando esto ocurre, se
puede utilizar la cláusula USING, tal y como vimos anteriormente, en lugar de ON
para indicar entre paréntesis que columna en ambas tablas es la que tienen que
coincidir sus valores. El ejemplo anterior quedaría de la siguiente manera
Listar el número de pedido, fecha, forma de pago y la
descripcion de la forma de pago de todos pedidos, aunque no
tengan la forma de pago NULL

SELECT P.npedido, P.fecha, P.forma_pago, FP.descripcion
FROM Pedido
LEFT JOIN FormaPago FP USING(forma_pago);
Simétricamente, el JOIN EXTERNO DERECHO se produce entre dos tablas
ofreciendo la siguiente información:
• El JOIN INTERNO (o JOIN) de las dos tablas.
• Por cada fila de la segunda tabla que no haya correspondido a ninguna
fila de la primera tabla, se añade una fila a los resultados, utilizando los
valores de las columnas de la segunda tabla y suponiendo un valor NULL
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 9 - 30L pa(a Vv30L. Lerduaje de Var|pu|ac|ór de 0alos Pád|ra 185 de 20ê
para todas las columnas de la primera tabla correspondientes en el
emparejamiento.
Listar el número de pedido, fecha, forma de pago y la
descripcion de la forma de pago de todas las formas de pago,
aunque no tengan pedidos

SELECT P.npedido, P.fecha, P.forma_pago, FP.descripcion
FROM Pedido
RIGHT JOIN FormaPago FP ON P.forma_pago = FP.forma_pago;
No olvidemos que los tipos de JOIN ya fueron citados y definidos en el apartado
relativo a la cláusula FROM de la sentencia SELECT en una sección anterior.
JOIN con múltiples columnas de emparejamiento
En el caso de que el par de claves externa/primaria que se utilizan para
hacer el emparejamiento estuvieran compuestas por dos o más columnas, se
pueden utilizar los operadores lógicos AND y OR para realizar la combinación, como
en el siguiente ejemplo
Listar el número de albaran, número de línea, referencia,
unidades de la línea del albarán, unidades de la línea del
pedido y su diferencia de todos artículos vendidos

SELECT LA.nalbaran, LA.nlinea, LA.referencia, LA.unidades,
LP.unidades
FROM LineaAlbaran LA INNER JOIN LineaPedido LP
ON LA.npedido = LP.npedido AND LA.nlineap = LP.nlinea;
JOIN anidados
Cuando la consulta implica a tres o más tablas, entonces es posible utilizar
unos Joins dentro de otros, anidar los Joins. Veamos un ejemplo
Listar el número de albarán, fecha, cliente, razón social del
cliente, número de línea, referencia, descripción del
artículo, unidades y precio de los albaranes hechos en la
fecha 4/1/2004

SELECT A.nalbaran, A.fecha, LA.nlinea, LA.referencia,
AR.descripcion, LA.unidades, LA.precio
FROM Albaran A
INNER JOIN LineaAlbaran LA
INNER JOIN Articulo AR
ON LA.referencia = AR.referencia
ON A.nalbaran = LA.nalbaran;
Como se puede ver en el ejemplo, las cláusulas ON se van poniendo en
orden inverso a las cláusulas INNER JOIN. Es decir, primero se ha enlazado la tabla
Albaran con la tabla LineaAlbaran en la primera cláusula INNER JOIN. En la
segunda, se ha enlazado la tabla LineaAlbaran con la tabla Articulo. Las cláusulas
ON se han puesto en orden inverso, primero la correspondiente a la del último JOIN
y al final aparece la del primer JOIN. Este mismo ejemplo usando la cláusula USING
queda más legible, al poner cada cláusula INNER JOIN con su cláusula USING
correspondiente.
Listar el número de albarán, fecha, cliente, razón social del
cliente, número de línea, referencia, descripción del
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 9 - 30L pa(a Vv30L. Lerduaje de Var|pu|ac|ór de 0alos Pád|ra 18ê de 20ê
artículo, unidades y precio de los albaranes hechos en la
fecha 4/1/2004

SELECT A.nalbaran, A.fecha, LA.nlinea, LA.referencia,
AR.descripcion, LA.unidades, LA.precio
FROM Albaran A
INNER JOIN LineaAlbaran LA
USING(nalbaran)
INNER JOIN Articulo AR
USING(referencia)
En consultas multitabla con tres o más tablas pueden anidarse Join internos
con Joins externos y viceversa. Teniendo en cuenta que dentro de un Join interno
se pueden anidar Joins externos por la izquierda y por la derecha, pero no al revés.
No puede anidarse un Join interno dentro de un Join externo, ya sea por la derecha
o por la izquierda.
ACIbALIIACIONE$ DE DAIO$
Introducir datos. Sentencia INSERT
La sintaxis básica de la sentencia INSERT ya la hemos vistos en el capítulo
anterior.
INSERT [LOW_PRIORITY | DELAYED | IGNORE] [INTO] tabla
[(lista_columnas)]
(valores_de_datos)
La sentencia hace que valores_de_datos se inserte como una o más filas en
la tabla que se nombra. El argumento lista_columnas es una lista separada por
comas de los nombres de tablas que se pueden utilizar para especificar las
columnas para que se suministran datos. Si no se especifica lista_columnas, todas
las columnas de la tabla recibirán datos.
Cuando una lista_columnas no enumera todas las columnas de la tabla, se
inserta un valor NULL (o el valor predeterminado si se ha definido alguno para la
columna) en aquellas columnas que no se hayan enumerado en la lista. Todas las
columnas no especificadas en la lista de columnas deben permitir valores NULL o
tener un valor predeterminado.
Los valores_de_datos suministrados deben corresponderse con la lista de
columnas. El número de valores de datos debe ser el mismo que el número de
columnas y el tipo de datos, precisión y escala de cada valor de datos deben
coincidir con los de la columna correspondiente. Hay tres maneras de especificar
los valores de datos:
• Utilizar con INSERT una consulta SELECT para especificar los valores de
datos para una o más filas.
• Utilizar con INSERT una cláusula SET para insertar filas situando en las
columnas especificadas los valores dados.
• Utilizar la palabra clave VALUES y los datos encerrados entre paréntesis,
separados por comas.
Con la primera opción se insertarían múltiples filas de datos en la tabla. Su
sintaxis es:
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 9 - 30L pa(a Vv30L. Lerduaje de Var|pu|ac|ór de 0alos Pád|ra 18Z de 20ê
INSERT [LOW_PRIORITY | DELAYED | IGNORE] [INTO] tabla
[(lista_columnas)]
SELECT …
La sentencia SELECT puede ser cualquier sentencia de consulta vista hasta
el momento. Veamos el siguiente ejemplo
Crear una tabla, llamada Clientes con las columnas nif, razón
social y teléfono

CREATE TABLE Clientes (
nif VARCHAR(10) BINARY NOT NULL PRIMARY KEY,
razon_social VARCHAR(40) BINARY NOT NULL,
telefono INTEGER(9),
);

Insertar en la tabla anterior los clientes de la tabla
Cliente que tengan teléfono
INSERT INTO Clientes
SELECT nif, razon_social, telefono
FROM Cliente
WHERE telefono IS NOT NULL;
Con la segunda opción se insertaría una fila de datos única, donde las
columnas que se indicaran con la cláusula SET tomarían los valores indicados. Su
sintaxis es:
INSERT [LOW_PRIORITY | DELAYED | IGNORE] [INTO] tabla
SET columna = exp | DEFAULT, columna = exp | DEFAULT, …
Cada columna tendrá el valor de exp que puede ser una expresión MySQL
válida. Si se usa la palabra clave DEFAULT se asignaría el valor por defecto definido
en la tabla. Las columnas se separán por comas. Las que no se indiquen tomarán
valores NULL o valores por defecto. Por ejemplo
Introducir en la tabla Albarán un albarán con fecha actual,
cliente con nif 30000002A, forma de envío es ‘Transporte
propio’, forma de pago 4

INSERT INTO Albaran
SET cliente = ‘30000002A', fecha = Current_Date(),
forma_envio = ‘Trasporte propio’, forma_pago = 4;
Con la última opción se emplea la palabra clave VALUES para indicar una
lista de valores a asignar a la lista de columnas. Su sintaxis es:
INSERT [LOW_PRIORITY | DELAYED | IGNORE] [INTO] tabla
[(lista_columnas)]
VALUES (valores_de_datos)
Los valores de datos se indican separados por comas. El número y tipo debe
coincidir con las columnas indicadas en lista_columnas. Por ejemplo
Introducir en la tabla Cliente un cliente con nif
‘30000100A', razón social ‘Supermercado Mandarín’ y teléfono
957774477

INSERT INTO Cliente (nif, razon_social, telefono)
VALUES (‘30000100A',’Supermercado Mandarín’, 957774477;
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 9 - 30L pa(a Vv30L. Lerduaje de Var|pu|ac|ór de 0alos Pád|ra 188 de 20ê
Hay unas opciones que son comunes a las tres formas de insertar datos.
Con la opción LOW_PRIORITY la ejecución de la sentencia INSERT se retrasa hasta
que no haya ningún cliente leyendo de la tabla.
Con la opción DELAYED el servidor retiene las filas a insertar en un buffer.
Cuando la tabla está libre se van insertando y a cada fila insertada el servidor
comprueba si hay peticiones de lectura para la tabla. Si las hay, las atiende y
retiene las filas restantes a insertar a que la tabla vuelva a estar libre.
Con la opción IGNORE se ignoran las filas que provocan errores por
duplicidad de claves únicas. Si no se utiliza esta opción, cuando se inserte una fila
que duplique una clave única, se abortará todo el proceso.
Eliminar filas de datos. Sentencia DELETE
La sentencia DELETE elimina una o varias filas de una tabla. Su sintaxis es:
DELETE [LOW_PRIORITY] [IGNORE] FROM tabla
[WHERE condición]
[ORDER BY ...]
[LIMIT n]
El argumento tabla nombra la tabla de la que se van a eliminar las filas. Se
eliminan todas las filas de tabla que cumplan la condición de búsqueda de la
cláusula WHERE.
Si no se especifica una cláusula WHERE, se eliminarán todas las filas de la
tabla (similar a la sentencia TRUNCATE TABLE). Con la opción LOW_PRIORITY se
indica que no se ejecuta el borrado hasta que ningún cliente esté leyendo la tabla y
LIMIT n establece en n el número máximo de filas que se pueden borrar.
Si se indica una cláusula ORDER BY, las filas se borrarán en ese orden. Esto
solamente es útil cuando también se especifica una cláusula LIMIT n.
Borrar todos los clientes que no han hecho pedido durante el
més de enero

DELETE FROM Cliente
WHERE NOT EXISTS( SELECT *
FROM Pedido
WHERE nif = cliente );
Actualización de datos. Sentencia UPDATE
La instrucción UPDATE puede cambiar los valores de filas individuales,
grupos de filas o todas las filas de una tabla o vista. Una instrucción UPDATE que
haga referencia a una tabla o vista puede cambiar los datos de una tabla a la vez.
Su sintaxis es:
UPDATE [LOW_PRIORITY | IGNORE] tabla
SET columna = expresión [, columna = expresión] …
[WHERE condicion]
[ORDER BY exp]
[LIMIT n]
SET contiene una lista separada por comas de las columnas que deben
actualizarse y el nuevo valor de cada columna, con el formato columna =
expresión. El valor suministrador por las expresiones incluye elementos tales como
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 9 - 30L pa(a Vv30L. Lerduaje de Var|pu|ac|ór de 0alos Pád|ra 189 de 20ê
constantes, valores seleccionados de una columna de otra tabla o valores
calculados por una expresión compleja. Las columnas que se igualen a expresiones
deben preceder a las columnas entre paréntesis que se igualen a subconsultas,
todo dentro de una única sentencia UPDATE.
Con WHERE se especifica la condición de búsqueda han de cumplir las filas
para que se actualicen.
Con LOW_PRIORITY indica que no se ejecute la actualización hasta que
ningún cliente esté leyendo la tabla.
Con IGNORE y se produce una actualización que provoque claves únicas
duplicadas no ocurrirá un error, pero las filas que duplicaran claves únicas no se
actualizarán.
Con LIMIT n se establece el número máximo de filas que se pueden
actualizar.
Con ORDER BY exp se ordenan las filas para su actualización. Solo es útil
cuando se especifica la cláusula LIMIT n.
Actualizar las formas de pago de todos los albaranes a ‘Giro
90 días’ cuando el valor de estas sean NULL.

UPDATE Albaran
SET forma_pago = ( SELECT forma_pago
FROM Forma_pago
WHERE descripcion = ‘Giro 90 dias’ )
WHERE forma_pago IS NULL;

Actualizar el total albarán de todos los albaranes a la suma
de los importes de sus correspondientes líneas de albarán

UPDATE Albaran A
SET total_albaran = ( SELECT SUM( unidades * ( precio –
precio * dto)
FROM LineaAlbaran LA
WHERE A.nalbaran = LA.nalbaran );
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 10 - Adr|r|sl(ac|ór de Vv30L Pád|ra 190 de 20ê
10
Adm|n|strac|ón de Hy80L
ADMINI$IkACIÓN DE IA8LA$
Dentro del lenguaje SQL (Structured Query Language) que MySQL utiliza
para tratar la información, se encuentra la categoría de sentencias (o comandos)
denominada lenguaje de modificación de datos DML (Data Modification Language).
Las sentencias del lenguaje de modificación de datos se utilizan para
manipular, alterar o borrar objetos de base de datos, tales como tablas, columnas e
índices. Como ejemplos característicos más relevantes tenemos las sentencias
ALTER y DROP.
La modificación y administración de tablas de una base de datos se realizan
básicamente a partir de las sentencias CREATE TABLE (ya vista en un capítulo
anterior), ALTER TABLE y DROP TABLE.
Modificación de tablas con ALTER TABLE
Después de crear una tabla, es posible cambiar muchas de las opciones que
fueron definidas cuando se creó originalmente; por ejemplo, es posible:
• Agregar, modificar o eliminar columnas. Así, se puede cambiar el
nombre, la longitud, el tipo de datos, la precisión, la escala y la
aceptación de valores NULL de la columna, aunque hay algunas
restricciones.
• Agregar o eliminar restricciones PRIMARY KEY y FOREIGN KEY.
• Agregar o eliminar restricciones UNIQUE y CHECK, así como definiciones
(y objetos) DEFAULT.
• Registrar una tabla y las columnas seleccionadas de una tabla para la
indización de texto.
Inicialmente la sintaxis de ALTER TABLE podría ser la siguiente:
ALTER TABLE tabla
[CHANGE nombre_columna nombre_columna_nuevo
nuevo
_
tipo_datos [ ( precisión [ , escala ] ) ]
[NULL | NOT NULL]]
| ADD [COLUMN] declaración_columna [FIRST | AFTER nombre
columna]
| ADD INDEX nombre_índice (columnas índice)
| ADD PRIMARY KEY (columnas_índice)
| ADD UNIQUE nombre_índice (columnas_índice)
| CHANGE [COLUMN] nombre_columna declaración_columna
| ALTER [COLUMN] nombre_columna [SET DEFAULT valor | DROP
DEFAULT]
| DROP [COLUMN] nombre_columna
| DROP INDEX nombre_índice (lista_columnas)
| DROP PRIMARY KEY
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 10 - Adr|r|sl(ac|ór de Vv30L Pád|ra 191 de 20ê
| MODIFY [COLUMN] declaración_columna
| RENAME [AS] nombre
_
tabla_nueva
| ADD [CONSTRAINT [nombre_restricción]]
PRIMARY KEY [tipo_índice] (columnas_índice)
| ADD [CONSTRAINT [nombre_restricción]]
UNIQUE [nombre_índice] [tipo_indice] (columnas_indice)
| ADD [CONSTRAINT [nombre_restricción]]
FOREIGN KEY [nombre_indice] (columnas_indice)
[referencia]
El argumento tabla es el nombre de la tabla que se va a modificar. Si la
tabla no se encuentra en la base de datos actual, la base de datos podrá
especificarse explícitamente. CHANGE especifica que la columna dada va a
cambiarse de nombre
_
columna a nombre columna nuevo o a modificarse al
nuevo tipo de datos (nombre columna y nombre columna nuevo coinciden). En
la columna alterada no puede usarse una restricción PRIMARY KEY o [FOREIGN
KEY] REFERENCES ni en una restricción CHECK o UNIQUE, excepto si se permite
alterar la longitud de una columna de longitud variable empleada en una
restricción CHECK o UNIQUE. FIRST indica que la columna se coloca la primera en
la tabla y AFTER indica que la columna se coloca detrás de nombre columna.
El argumento nombre
_
columna es el nombre de la columna que se va a
alterar, agregar o quitar. NULL | NOT NULL especifica si la columna puede aceptar
valores NULL.
ADD especifica que se agregan a la tabla una o más definiciones de
columna, definiciones de columnas calculadas, índices (sobre las columnas
especificadas en lista columnas) o restricciones de tabla (PRIMARY KEY o UNIQUE).
DROP especifica que la restricción (PRIMARY KEY o UNIQUE), el índice o la
columna se eliminarán de la tabla.
MODIFY [COLUMN] cambia la declaración de una columna. CHANGE
[COLUMN] cambia e l nombre y la definición de una columna. RENAME renombra
una tabla.
En la sintaxis de ALTER TABLE ya hemos visto que CHANGE, MODIFY,
RENAME y ADD son cláusulas cuya finalidad es modificar propiedades de las
columnas de las tablas, renombrar las tablas y añadir elementos a las mismas
como columnas, índices y restricciones de integridad.
Las cláusulas CHANGE y MODIFY se utilizan para cambiar el tipo de las
columnas de una tabla, pero CHANGE puede además renombrar columnas. La
cláusula RENAME permite renombrar tablas. Por su parte, la cláusula ADD
permite añadir columnas, índices y restricciones de integridad a las tablas.
Cambiar la definición de la columna ventas en la tabla
Cliente. A partir de ahora se llamará total_vendido, será de
tipo decimal(9,2) y eliminar su valor por defecto

ALTER TABLE Cliente
CHANGE COLUMN ventas total_vendido DECIMAL(9,2);

ALTER TABLE Cliente
ALTER COLUMN total_vendido DROP DEFAULT;

lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 10 - Adr|r|sl(ac|ór de Vv30L Pád|ra 192 de 20ê
Añadir a la tabla Efectos una columna llamada importe con
tipo de datos decimal(7,2). Por defecto tendrá el valor 0 y
no admitirá valores nulos

ALTER TABLE Efectos
ADD COLUMN importe DECIMAL(7,2) NOT NULL DEFAULT 0;

Añadir un índice a la tabla Cliente por la columna
razon_social

ALTER TABLE Cliente
ADD INDEX Razon_Social (razon_social);

Añadir a la tabla Cliente una columna llamada cp, que
almacenará el codigo postal y ponerla después de la columna
provincia

ALTER TABLE Cliente
ADD COLUMN cp INTEGER(5) AFTER poblacion

Cambiar la tabla Clientes y eliminar la columna telefono
ALTER TABLE Clientes
DROP COLUMN telefono;

Cambiar el nombre de la tabla Efectos a Recibo

ALTER TABLE Efectos RENAME Recibo;

Borrar el índice Razon_Social de la tabla Cliente
ALTER TABLE Cliente
DROP INDEX Razon_Social;
Borrado de tablas con DROP TABLE
La sentencia DROP TABLE permite borrar tablas completas de la base de
datos. Esta sentencia suprime las tablas que se especifican en su sintaxis y valida
los cambios pendientes en la base de datos. Únicamente un administrador de la
base de datos (DBA) puede suprimir tablas de otros usuarios.
Al suprimir una tabla también se suprimen los índices y las concesiones
asociadas a ella. Los sinónimos construidos sobre tablas suprimidas se marcan
como inválidas y dejan de funcionar.
La sintaxis de DROP TABLE es la siguiente:
DROP TABLE [IF EXISTS] tablal [, tabla2]...;
No se puede utilizar DROP TABLE para quitar una tabla a la que se haga
referencia con una restricción FOREIGN KEY, ya que primero se debe quitar la
restricción FOREIGN KEY o la tabla de referencia.
Cuando se quita la tabla, las reglas o valores predeterminados de la misma
pierden sus enlaces y se quitan automáticamente las restricciones o
desencadenadores asociados con ella. Si vuelve a crear una tabla, deberá volver a
enlazar las reglas y valores predeterminados apropiados, volver a crear los
desencadenadores y agregar todas las restricciones necesarias.
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 10 - Adr|r|sl(ac|ór de Vv30L Pád|ra 193 de 20ê
Tampoco se puede utilizar la instrucción DROP TABLE sobre las tablas del
sistema. Si elimina todas las filas de una tabla (DELETE tabla), la tabla existe hasta
que se quite. Los permisos para utilizar DROP TABLE pertenecen de manera
predeterminada al propietario de la tabla y no se pueden transferir.
Si se intenta eliminar una tabla que no existe, MySQL ofrece un mensaje de
error, pero si se especifica la cláusula IF EXISTS en DROP TABLE, la eliminación de
tablas que no existan no se reconoce como un error.
Borrar la tabla Clientes

DROP TABLE IF EXISTS Clientes;
Borrado de bases de datos con DROP DATABASE
En MySQL es muy sencillo borrar una base de datos completa con todos sus
objetos mediante la sentencia DROP DATABASE, cuya sintaxis es la siguiente:
DROP DATABASE [IF EXISTS] nombre_BD;
Si se intenta eliminar una base de datos que no existe, MySQL ofrece un
mensaje de error, pero si se especifica la cláusula IF EXISTS en DROP DATABASE,
la eliminación de una base de datos que no exista no se reconoce como un error.
Después de eliminar una base de datos es necesario tener precaución. Ya
sabemos que la sentencia falla si no existe la base de datos que se quiere borrar
(salvo que se especifique la cláusula IF EXISTS), pero también falla en caso de no
disponer de los permisos necesarios.
VI$IA$
Como se vio en capítulos anteriores, una vista es una sentencia SQL con
nombre que se almacena en la base de datos. En MySQL las vistas estaba previsto
que estuvieran soportadas en la versión 5.0, pero no lo han sido, así que aún no se
puede trabajar con vistas en MySQL.
ADMINI$IkACIÓN DE CbENIA$ DE b$bAkIO
El administrador de la base de datos es el encargado de establecer las
cuentas de usuario de MySQL, definiendo qué usuarios se pueden conectar al
servidor, desde donde pueden conectarse y qué tareas pueden hacer cuando están
conectados.
Existe en SQL de MySQL dos sentencias vitales que regulan la
administración de cuentas de usuario. La sentencia GRANT crea usuarios y regula
sus privilegios, y la sentencia REVOKE elimina los privilegios. Las sentencias GRANT
y REVOKE afectan a cuatro tablas de privilegios, denominadas tablas de
transferencia, cuyos nombres son: user (contiene los usuarios que pueden conectar
con el servidor con cualquier privilegio que tengan), db (contiene los privilegios de
nivel de base de datos), tables_priv (contiene los privilegios de nivel de tabla) y
columns_priv (contiene los privilegios de nivel de columna). Hay otra tabla de
transferencia llamada host, pero que no es afectada por GRANT ni REVOKE. Cuando
se usan GRANT para un usuario, se crea una entrada para ese usuario en la tabla
user, y si la sentencia especifica cualquier privilegio global (administrativo o
aplicable a todas las bases de datos) también se registran en user. Si se especifica
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 10 - Adr|r|sl(ac|ór de Vv30L Pád|ra 191 de 20ê
una base de datos, tabla o privilegios de columna, se registran en las tablas db,
tables_priv y columns_priv.
Sentencia GRANT
La sentencia GRANT concede privilegios de acceso a uno o más usuarios de
MySQL que se crean. Su sintaxis es la siguiente:
GRANT tipo_priv [(lista_col)] [, tipo_priv [(lista_col)]…
ON {*.* | * | nombre_bd.* | nombre_bd.nombre_tabla |
nombre_tabla }
TO usuario IDENTIFIED BY ‘contraseña’
[, usuario IDENTIFIED BY ‘contraseña’] …
[WITH GRANT OPTION]
El argumento tipo_priv especifica los privilegios que se concederán y
lista_col especifica las columnas (separadas por comas) a las que se concederán
estos privilegios en su caso. La tabla siguiente resume los tipos de privilegios que
se aplican a bases de datos, tablas y columnas.
Privilegio Operación permitida por el privilegio
ALTER Asigna permisos para alterar tablas e índices
CREATE Asigna permisos para crear bases de datos y tablas
DELETE Asigna permisos para borrar registros de tablas
DROP Asigna permisos para eliminar bases de datos y tablas
INDEX Asigna permisos para crear o eliminar índices
INSERT Asigna permisos para insertar valores en tablas
SELECT Asigna permisos para ver la información de las tablas
UPDATE Asigna permisos para actualizar tablas
La tabla siguiente resume los tipos de privilegios administrativos
Privilegio Operación permitida por el privilegio
FILE Asigna permisos para leer y escribir archivos
PROCESS Asigna permisos para revisar información sobre los hilos
ejecutados o eliminados en el servidor
RELOAD Asigna permisos para recargar las tablas cedidas o vaciar los
registros, la caché host o la caché de tablas
SHUTDOWN Asigna permisos para cerrar el servidor
ALL (ALL
PRIVILEGES)
Asigna todos los permisos
USAGE Privilegio especial "sin privilegios¨
La cláusula ON especifica el nivel (amplitud) a que se aplican los privilegios.
Los privilegios pueden ser globales aplicables a todas las bases de datos y a todas
las tablas, específicos de una base de datos o específicos de tabla. La siguiente
tabla especifica los posibles niveles a que se aplican los privilegios.
Nivel Significado
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 10 - Adr|r|sl(ac|ór de Vv30L Pád|ra 195 de 20ê
*.* Privilegios globales (todas las BD´s y tablas)
* Privilegios globales (sin BD en uso)
nombre_BD.* Privilegios a nivel de la base de datos para todas las
tablas nombradas en la base de datos
nombre_BD.nombre_tabla Privilegios a nivel de tabla: todas las columnas que se
nombran en la tabla
nombre_tabla Privilegios a nivel de tabla: todas las columnas que se
nombran en la tabla en la base de datos
Cuando en una tabla se utiliza la cláusula ON, los privilegios se pueden
hacer por columna específica nombrando una o más columnas separadas por
comas en la cláusula lista_col.
La cláusula TO especifica el usuario para quien son los privilegios. Cada
usuario consiste en un nombre de usuario y un nombre de host mediante la
especificación nombre_usuario@nombre_host y opcionalmente una cláusula
IDENTIFIED BY que asigna una contraseña al usuario y que debe especificarse en
texto plano. Si no se indica el nombre del host, se hace referencia a todos los
hosts.
Tanto para especificar el host como para especificar el nombre de usuario
pueden usarse caracteres comodín _ y %, ya conocidos por ser los utilizados en las
sentencias de selección que tienen condiciones con test de correspondencia de
patrón LIKE. Cuando se usen caracteres comodin para referenciar a grupos de
usuarios o de host, resulta conveniente encerrar ambas partes entre comillas
simples (‘nombre_usuario’@’nombre_host’).

Crear el usuario rafa, que puede acceder a todas las tablas
en la base de datos almacen de cualquier host con la
contraseña secreto.

GRANT ALL ON almacen.* to rafa IDENTIFIED BY “secreto”;

Crear un usuario de nombre maria con privilegios de sólo
lectura para las tablas en la base de datos almacen pudiendo
conectarse en el host localhost

GRANT SELECT ON almacen.* TO maria@localhost;

Crear el usuario pepe
GRANT USAGE ON *.* TO pepe;

Sentencia REVOKE
La sentencia REVOKE se utiliza para revocar privilegios y eliminar usuarios.
Su sintaxis es la siguiente:
REVOKE tipo_priv [(lista_col)] [, tipo_priv [(lista_col)]]…
ON { *.* | * | nombre_bd.* | nombre_bd.nombre_tabla |
nombre_tabla }
FROM usuario [, usuario]
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 10 - Adr|r|sl(ac|ór de Vv30L Pád|ra 19ê de 20ê
Los argumentos son idénticos a los de la sentencia GRANT. REVOKE no
elimina al usuario de la tabla, por lo que éste puede seguir conectada a MySQL.
Para eliminar totalmente al usuario hay que usar la sentencia DROP USER o
eliminar manualmente sus entradas en las tablas de transferencia.
Revocar todos los privilegios para el usuario rafa en el host
local

REVOKE ALL ON *.* FROM rafa@localhost;

Revocar los derechos de inserción, borrado y actualización a
todos los usuarios del host local en la tabla Cliente de la
base de datos Almacen

REVOKE INSERT, DELETE, UPDATE ON Almacen.Cliente FROM
‘%’@localhost;

Revocar el derecho de actualización a la columna referencia
de la tabla Artículo en la base de datos Almacen para el
usuario pepe en cualquier host

REVOKE UPDATE (referencia) ON Almacen.Articulo FROM pepe@’%’;
Para ver la lista de privilegios actuales de un usuario se puede utilizar la
siguiente sentencia:
SHOW GRANTS FOR usuario;
Contraseñas mediante SET PASSWORD
Ya hemos visto que cuando se crea un usuario con GRANT se puede indicar
una contraseña de usuario. La sentencia SET mediante la opción PASSWORD
permite establecer contraseñas para usuarios dados. Su sintaxis es:
SET PASSWORD [FOR usuario] = PASSWORD(“contraseña”);
Si no se especifica la cláusula FOR, la contraseña se establece para el
usuario actual.
COFIA$ DE $EGbkIDAD
En todo momento debemos disponer de una copia de seguridad de las bases
de datos MySQL. Pueden existir colapsos del sistema u operaciones administrativas
poco prudentes como DROP DATABASE o DROP TABLE que accidentalmente
eliminen o dañen una base de datos. Es necesario estar preparados para este tipo
de contingencias habilitando copias de seguridad que permitan la recuperación de
la información si es necesario.
En MySQL hay dos métodos para hacer copias de seguridad de las bases de
datos. La más conveniente es usar la utilidad mysqldump. La otra opción es realizar
una copia directa de los archivos de la base de datos mediante las órdenes de copia
del sistema operativo copy, cp, tar o cpio.
La sentencia mysqldump es más lenta que la copia directa, pero es mucho
más segura porque opera en cooperación con el servidor MySQL evitando los
problemas de realización de copias mientras se está produciendo una operación en
la base de datos. Además, genera archivos de texto transportables a otras
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 10 - Adr|r|sl(ac|ór de Vv30L Pád|ra 19Z de 20ê
máquinas que harán posible la recuperación de la información en otro sistema
distinto del nuesto.
Copia de seguridad con MySQLDUMP (backups)
La utilidad mysqldump escribe el contenido de las tablas de la base de datos
en ficheros de texto que puedan usarse para copias de seguridad de bases de
datos, para mover bases de datos a otro servidor o para crear una base de datos
de pruebas basada en una ya existente. Su sintaxis es la siguiente
mysqldump [opciones] nombre_BD [nombre_tabla]…
Cuando no se especifica el nombre de tabla o tablas, el proceso afecta a
todas las tablas de la base de datos. La sintaxis más habitual para volcar la base de
datos completa en un fichero de backup es la siguiente
mysqldump nombre_BD > fichero_backup
No obstante, suele utilizarse la opción --opt que permite afinar la copia
mediante el uso de instrucciones DROP TABLE, LOCK TABLE y otras previstas a la
copia para que ésta se más segura. Su sintaxis es
mysqldump –-opt nombre_BD > fichero_backup
Las opciones más habituales es indicar el usuario y que pida contraseña
para iniciar la copia, por ejemplo, si el administrador es el que realiza la copia se
escribiría
mysqldump –u root –p almacen > almacen.bak
El archivo de copia que genera es un archivo de texto con las sentencias
SQL necesarias para crear la base de datos y posteriormente insertarle los datos
con sentencias INSERT.
Recuperación de una base de datos
Para restaurar las tablas se pueden utilizar los archivos de backup
generados por mysqldump como entrada para mysql mediante la sintaxis
mysql nombre_BD < fichero_backup
Si la copia de seguridad de la base de datos se ha realizado con órdenes de
sistema operativo como copy, cp o tar, se realizará la recuperación copiando los
ficheros a los directorios adecuados. En este caso es necesario conocer muy bien la
estructura de directorios de las bases de datos MySQL para volver a situar cada
fichero en su sitio. Además, el servidor ha de desconectarse antes de iniciar la
copia y reiniciarlo al finalizar la tarea de copia.

lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 11 - le((ar|erlas d(ál|cas de Vv30L Pád|ra 198 de 20ê
11
herram|entas gráf|cas de Hy80L
En el sitio web de MySQL (www.mysql.com) existen a disposición de los
usuarios de esta base de datos una serie de herramientas para facilitar el trabajo
tanto del administrador de base de datos como de los usuarios. Las herramientas
que existen son:
• MySQL Administrator.- Herramienta para la administración tanto de
la instancia del servidor como de las bases de datos que se
mantienen en el servidor.
• MySQL Query Browser.- Herramienta para que los usuarios puedan
trabajar con la base de datos. Es una interfaz SQL para ejecutar
consultas y mostrar los resultados.
• MySQL Control Center.- Esta herramienta combina funciones de
usuario (consultas SQL) con funciones de administrador (gestión de
usuarios, conexiones con bases de datos, etc.). MySQL ha decidido
no desarrollar más versionas, ya que las dos herramientas anteriores
sirven para los propósitos para los que se creo esta.
Vamos a ver con más detalle cada una de ellas a continuación.
MY$QL ADMINI$IkAIOk
Instalación del administrador de MySQL
MySQL dispone de una herramienta para realizar la administración de las
bases de datos: MySQL Administrator. Es una aplicación que realiza operaciones
de administración, tales como configurar el servidor MySQL, monitorizar su estado,
iniciar/parar el servidor, gestionar usuarios y conexiones, realizar copias de
seguridad y otras tareas administrativas. Solo trabaja con versiones de MySQL 4.0
o superior.
La mayoría de las tareas pueden realizarse utilizando la interfaz en línea de
comandos o con la herramienta WinMySQLAdmin, pero esta herramienta
suministra las siguientes ventajas:
• GUI para facilitar su uso.
• Facilita el establecimiento de opciones de rendimiento y seguridad en
el servidor MySQL.
Para instalarla hay que seguir los siguientes pasos:
1. Descargar la herramienta de la página web de MySQL.
2. Descomprimir el archivo .zip.
3. Ejecutar el archivo setup.exe.
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 11 - le((ar|erlas d(ál|cas de Vv30L Pád|ra 199 de 20ê
4. Seguir los pasos de la instalación.
Una vez instalada, se crea un acceso directo en el escritorio que permite
ejecutarla. Al hacerlo, lo primero que pide son los datos de una conexión a un
servidor de base de datos MySQL. Para ello aparece la siguiente pantalla:

Figura 5. Cuadro de conexión al servidor
Como se observa, los datos para la conexión son:
1. Conexión.- Podemos crear tantas conexiones como queramos y
posteriormente realizar una conexión rápida eligiendo una de ellas en
esta lista. Para gestionar las conexiones, pinchar el botón con puntos
suspensivos que aparece a continuación.
2. Username.- Nombre de usuario. Si se ha elegido una conexión, se
rellena automáticamente.
3. Password.- Contraseña de acceso válida para el usuario anterior. Si
se crea una conexión conviene dejar en blanco este campo para que
cada vez que el usuario se conecte tenga que introducirla.
4. Hostname- Dirección IP o nombre de pc en la red donde se encuentra
la instancia del servidor en ejecución.
5. Port.- Puerto por donde la instancia del servidor está a la escucha.
Por defecto es el 3306 y conviene no cambiarlo.
Lo primero que hay que hacer es establecer la contraseña para el usuario
root, que es el administrador del servidor y todas las bases de datos. Para ello,
inicialmente nos conectaremos como root sin contraseña en el hostname
localhost. Debe de aparecer una pantalla donde se distribuyen las tareas de
administración por pantallas. La primera pantalla que aparece es la de información
del estado del servidor. A la izquierda aparecen las tareas de administración
clasificadas por secciones. Cada vez que se elige una sección en la parte izquierda,
cambia el panel de la derecha.
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 11 - le((ar|erlas d(ál|cas de Vv30L Pád|ra 200 de 20ê

Figura 6. MySQL Administrator
Información del Servidor
En la primera sección aparece información de la conexión a la instancia del
servidor, información del servidor y del cliente. Esta pantalla es meramente
informátiva y no hay que establecer ningún valor.
Control del servicio
En la pestaña de control de servicio se puede configurar el archivo con los
valores iniciales de configuración del servicio, que generalmente es el archivo
c:\windows\my.ini. También puede pararse y reanudarse el servicio y otras
características adicionales.
Variables de inicio
En esta sección se pueden establecer valores predeterminados en las
variables de inicio, que posteriormente se guardarán en el archivo my.ini. Estos
valores se refieren a parámetros de configuración para tablas MyISAM, InnoDB,
configuración de la red, parámetros de seguridad, etc.
Administración de usuarios
Desde aquí se pueden gestionar los usuarios de las bases de datos y los
privilegios de usuario. Para establecer la contraseña del usuario root hay que
pinchar en el panel izquierdo en la sección User Administration. En la parte
inferior se elige el usuario root y cuando aparezcan sus datos en el panel derecho
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 11 - le((ar|erlas d(ál|cas de Vv30L Pád|ra 201 de 20ê
se introduce la contraseña que hayamos elegido en los cuadros Password y Confirm
Password. En la próxima conexión, está contraseña será efectiva y habrá que
usarla.
Al elegir esta sección, en la parte inferior izquierda aparecerán los usuarios
actualmente dados de alta en el sistema. Podrán eliminarse, crearse nuevos
usuarios y en la pestaña Schema Privileges asignarle o quitarle privilegios a los
usuarios en las distintas bases de datos.
Conexiones del servidor
En este apartado se pueden ver las conexiones actuales al servidor. Si
solamente tenemos la nuestra veremos dos conexiónes. Una es la del usuario
ODBC que estará utilizando la herramienta WinMySQLAdmin y otra será la del
usuario root, que es la nuestra. Por cada conexión aparecerá el host y el número de
puerto que se está usando, además de su estado. En cualquier momento se puede
cortar una conexión pinchando con el botón derecho del ratón sobre una de ellas y
eligiendo en el menú contextual la opción Kill thread.
Health
Esta pantalla se utiliza para ver las estadísticas del servidor. Aquí, se pueden
ver el número de conexiones totales, mínimas, máximas y medias desde que se
inicio el servicio.
También las estadísticas referentes a las consultas SQL que se han hecho
hasta el momento y el tráfico que se está generando.
Server Logs
En esta sección se pueden ver los mensajes logs que emite el servidor. Los
archivos log se configuran en la sección variables de inicio. Generalmente, los
mensajes del servidor se dividen por temas. Existen mensajes del servidor cuando
se produce un error cualquiera (una mala conexión, pérdida de la conexión con un
usuario, una consulta SQL mal escrita, etc.). También hay mensajes de estado del
servidor (inicio del servicio, parada del servicio, conexión nueva abierta, etc.).
Esta sección es útil para consultar los mensajes de error en tareas de
depuración.
Estado de las réplicas
Si se ha instalado una base de datos distribuida, existirán repartidas por los
servidores de la red copias parciales de los datos de las bases de datos. Estas
copias deben de sincronizarse para ofrecer a los usuarios una base de datos en
estado consistente. En esta sección se puede comprobar el estado de las réplicas y
en que ordenadores se encuentran.
Backups
Esta sección se utiliza para realizar copias de seguridad de los datos.
Permite crear proyectos backups que monitorizan la realización de copias de
seguridad. Para cada proyecto hay que especificar que datos se van a copiar,
pudiendo especificar hasta tablas individuales y el directorio donde se copiarán.
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 11 - le((ar|erlas d(ál|cas de Vv30L Pád|ra 202 de 20ê
Luego hay que especificar el modo de copia de los datos. Generalmente son
sentencias SQL que incluyen las de creación de la base de datos y sentencias
INSERT con los datos. Posteriormente, se puede especificar que la copia se realice
de modo periódico, pudiendo ser diariamente, semanalmente y mensualmente en
un día determinado y a una hora.
Restore
En esta sección se pueden recuperar los datos almacenados en las copias de
seguridad. Para ello, se indican el archivo de copia de seguridad que se desea
restaurar y pinchar en el botón de comienzo de la recuperación. Como el archivo de
copia de seguridad es un archivo con sentencias SQL, entonces estas sentencias se
ejecutarán.
Catálogo
En esta sección se puede construir y mantener el catalogo de bases de
datos. Se podrá crear tablas, mediante la especificacion de su nombre, sus
columnas y los tipos de datos de las columnas. También se pueden crear índices,
claves primarias, claves externas, etc. Posteriormente a la creación, las tablas
podrán editarse para cambiar definiciones
MY$QL QbEkY 8kOW$Ek
Instalación de MySQL Query Browser
Esta herramienta permite trabajar con una base de datos mediante
consultas SQL. Su manejo es muy simple, ofrece una interfaz gráfica para
introducir consultas SQL. Estas son enviadas al servidor para su ejecución y cuando
éste le devuelve los resultados, los presenta en una tabla.
Para su instalación hay que seguir los siguientes pasos:
1. Descargar la herramienta de la página web de MySQL.
2. Descomprimir el archivo .zip.
3. Ejecutar el archivo setup.exe.
4. Seguir los pasos de la instalación.
Una vez ha terminado, creará un acceso directo en el escritorio con el que
podremos ejecutar la herramienta.
Al entrar pedirá los datos de la conexión y la pantalla de introducción de
estos datos es la misma que para MySQL Administrator. Si la conexión ha sido
correcta, entonces presenta una pantalla dividida en diferentes partes.
En la parte superior aparece un recuadro blanco ocupando casi la anchura
de la ventana. En este recuadro se introduce la sentencia SQL que se desea
ejecutar, posteriormente se pulsaría en el botón de ejecución. Los resultados los
presentará en la zona central, en una ficha.
Pueden ejecutarse tantas sentencias SQL como se desee. Cada nueva
ejecución provocará una nueva tabla de resultados. Si la sentencia SQL está mal
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 11 - le((ar|erlas d(ál|cas de Vv30L Pád|ra 203 de 20ê
escrita y ocurre un error, el mensaje de error aparecerá en la parte inferior de la
pantalla.
Si se desea se puede ejecutar varias sentencias SQL, cada una de ellas con
su tabla de resultados. Simplemente en el menú File se puede elegir la opción New
Query Tab y se abrirá una nueva ficha para ejecutar otra sentencia.
En la parte derecha aparece el catálogo de la base de datos estructurado de
forma jerárquica con las tablas y dentro de estas sus columnas. La base de datos
que aparece es la que se eligió en la conexión. Se se pincha con doble click sobre
una tabla cualquier aparecerá una sentencia SELECT en el recuadro para
ejecutarse. Justo debajo del cuadro de sentencia existen una serie de botones con
diversas cláusulas de la sentencia SELECT para escribir la sentencia sin necesidad
de teclear. Solamente se escoge el botón adecuado y se pincha en la tabla o
columna correspondiente para añadir la cláusula con la tabla o columna elegida.

Figura 7. MySQL Query Browser
Además, se guarda un histórico de sentencias ejecutadas. Con los botones
Go back y Next se puede navegar por este histórico. Con el botón Refresh se
vuelve a ejecutar la sentencia.
Esta herramienta cuenta con un sistema de ayuda en línea muy potente. En
la parte inferior derecha aparece clasificada por sintaxis, funciones y parámetros.
La sintaxis se refiere a las diferentes sentencias SQL. Aquí podemos consultar las
múltiples opciones que MySQL ofrece al usuario para consultar una base de datos.
Si se desea se pueden realizar cambios en los datos directamente en la tabla
de resultados. Cuando el resultado de una consulta puede ser actualizable, se
puede pinchar en el botón inferior Edit el cual permite editar celdas de datos
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 11 - le((ar|erlas d(ál|cas de Vv30L Pád|ra 201 de 20ê
individuales de la tabla. Haciendo doble click sobre una celda, se puede editar su
valor para cambiarlo por otro. Todos los cambios realizados son temporales hasta
que pincha en el botón Apply Changes, momento en el cual se actualizan en la base
de datos. Con el botón Discard Changes, se deshacen los cambios.
MY$QL CONIkOL CENIEk
Esta herramienta ha dejado de desarrollarse, debido a que sus funciones
están totalmente cubiertas por las dos anteriores. Además, las tareas de
administración que permite realizar son muy limitadas, si bien tiene una buena
gestión de conexiones a la base de datos y de consultas SQL a estas.
Para su instalación se seguirán los siguientes pasos:
1. Descargar la herramienta de la página web de MySQL.
2. Descomprimir el archivo .zip.
3. Ejecutar el archivo setup.exe.
4. Seguir los pasos de la instalación.
Una vez instalada, se dispone de un acceso directo en el escritori que
permitirá acceder a ella. La primera vez que se acceda, la herramienta no tendrá
registrada ninguna conexión, y automáticamente creará una. Aparecerá una
pantalla como la siguiente

Figura 8. Pantalla de creación de una conexión al servidor
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 11 - le((ar|erlas d(ál|cas de Vv30L Pád|ra 205 de 20ê
En la misma hay que introducir unos datos que son necesarios. Se
introducirá el nombre de la conexión, nombre o dirección IP del servidor donde está
instalado MySQL y usuario con el que se realiza la conexión. Si se desea se puede
introducir la contraseña, pero no es recomendable y si activar la casilla Preguntar
contraseña para que cada vez que se use está conexión pida la contraseña
previaente.
A partir de ahora, cada vez que se ejecute la herramienta, se utilizará la
conexión. Se podrán crear tantas conexiones como se necesiten, una será
establecida por defecto, y será esta la que utilice cada vez que se ejecuta la
herramienta.
Al ejecutar MySQLCC y después de realizar la autenticación, se presenta la
siguiente pantalla

Figura 9. Pantalla principal de MySQL Control Center
En la parte izquierda aparece el árbol de servidores a los que se puede
conectar. La barra de herramientas dispone de botones pare realizar operaciones
habituales, pero el conjunto de botones que ofrece dependerá del elemento elegido
en el árbol de servidores MySQL. Desde aquí se pueden gestionar cuantas
conexiones se deseen.
En tareas de administración solamente se puede editar el esquema de la
base de datos, administración de usuarios y del servidor, aunque este último
solamente ofrece la información, pero no puede editarse.
En la barra de herramientas está el botón SQL que es común a todos los
elementos del árbol de directorios. Si se pincha en este botón aparece una pantalla
para introducir consultas SQL que al ejecutarse ofrecerán los resultados en la
lE3 F(arc|sco de |os Rios 3|sleras 0eslo(es de 8ases de 0alos
Tera 11 - le((ar|erlas d(ál|cas de Vv30L Pád|ra 20ê de 20ê
misma pantalla. Se podrá guardar en disco tanto los resultados de la consulta como
la consulta. Además los resultados son editables, para modificación, inserción o
borrado de filas.
Como se puede ver, esta herramienta no añade nada nuevo a lo visto hasta
ahora, se puede realizar las mismas tareas con las dos anteriores, que al ser más
recientes se recomienda su uso, además de separar claramente las tareas del
administrador de la base de datos de las tareas de un usuario, son herramientas
que seguiran en desarrollo, mientras que MySLQCC ha sido abandonada.

You're Reading a Free Preview

Descarga
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->