Temas Específicos para La Preparación de La Oposición Al Cuerpo Superior de Sistemas y Tecnologías de La Información de La Administración Del Estado

Asociación Profesional del Cuerpo Superior
de Sistemas y Tecnologías de la Información

de la Administración del Estado
Temas Específicos para la preparación de la Oposición al Cuerpo

Superior de Sistemas y Tecnologías de la Información de la
Administración del Estado.
TEMAS ESPECÍFICOS II: Tecnología Básica
Tema 58. El modelo relacional. El lenguaje SQL. Normas y

estándares para la interoperabilidad entre gestores de bases
de datos relacionales.
AUTOR: Leonor Torres, Carmen García y Juan Cantador.
Fecha: 2007
II. Tecnología Básica.
058. El modelo relacional. El lenguaje SQL. Normas y

estándares para la interoperabilidad entre gestores de
bases de datos relacionales.
Autores: Leonor Torres, Carmen García y Juan Cantador.
1. Introducción. Bases de Datos Relacionales ................................................................................. 3

2. Modelo Relacional .................................................................................................................... 3
2.1. Características................................................................................................................. 3
2.2. Componentes .................................................................................................................. 5
2.3. 12+1 Reglas de CODD ..................................................................................................... 5
2.4. Normalización ................................................................................................................. 8
2.5. Álgebra relacional ...........................................................................................................10
2.5.1. Operadores ...........................................................................................................10
3. El lenguaje SQL ......................................................................................................................14
3.1. Generalidades ................................................................................................................14
3.1.1. Normalización........................................................................................................15
3.2. El lenguaje SQL ..............................................................................................................17
3.2.1. CONCEPTOS SQL ...................................................................................................17
3.2.2. DDL Descripción de objetos ....................................................................................17
3.2.3. DML Manipulación de los datos ...............................................................................22
3.3. Traducción del Modelo conceptual al físico ........................................................................29
3.3.1. Modelo Conceptual de Datos mediante la técnica del Modelo E/R Extendido ................ 29
3.3.2. Transformación del Modelo Conceptual a un Modelo Lógico Relacional Normalizado. Para
su representación se utilizará la notación del Diagrama de Estructura de Datos. ........................... 30
3.4. SQL avanzado ................................................................................................................33
4. Normas y estándares para la interoperabilidad entre gestores de bases de datos relacionales ........ 35
4.1. ODBC. Open Database Conectivity ...................................................................................35
4.2. OLE-DB. Object Linking and Embedding for Databases ......................................................35
4.3. ADO. ActiveX Data Objects ..............................................................................................36
4.4. ADO.NET .......................................................................................................................36
4.5. JDBC Java Database Connectivity ....................................................................................37
4.6. Soluciones ORM: Object-Relational Mapping .....................................................................38
5. Comparación entre Sistemas Gestores de Bases de Datos Relacionales ........................................ 38
5.1. Bases de Datos objeto de la Comparación ........................................................................38
5.1.1. Oracle ..................................................................................................................38
5.1.2. DB2 ......................................................................................................................39
5.1.3. SQLServer .............................................................................................................39
5.1.4. PostgreSQL ...........................................................................................................39
5.1.5. MySQL ..................................................................................................................39
5.2. Comparación..................................................................................................................40
058. El modelo relacional. El lenguaje SQL. Normas y estándares para la interoperabilidad entre gestores
de bases de datos. 1
5.2.1. Disponible en qué Sistema Operativo .......................................................................40

5.2.2. Características fundamentales .................................................................................40
5.2.3. Límites .................................................................................................................40
5.2.4. Tablas y vistas.......................................................................................................41
5.2.5. Capacidades ..........................................................................................................41
1. INTRODUCCIÓN. BASES DE DATOS RELACIONALES
El modelo de datos relacional fue presentado por Codd en 1970, en un artículo de ACM titulado “ Un
modelo de datos relacional para grandes bancos de datos compartidos”, constituyó un hito en la historia
de las bases de datos. En la actualidad los sistemas de base de datos relacionales dominan el mercado.
Por esa razón las metodologías de desarrollo de bases de datos en el diseño lógico se centran en el
modelo relacional.
Cuando el DR E.F. Codd propone un nuevo modelo de datos, los SGBD dominantes en el mercado, tipo
Codasyl y Jerárquico, no habían logrado superar la dependencia de las aplicaciones con respecto de los
datos.
A diferencia de estos modelos basados en punteros físicos por los que tenía que navegar el programador.
El modelo relacional propone como objetivo principal aislar al usuario de las estructuras físicas de los
datos, consiguiendo la independencia de las aplicaciones respeto de los datos.
Una Base de Datos Relacional es un conjunto de informaciones relacionadas que sustentan a la
información de una organización y se caracterizan por:
- Sencillez y uniformidad: los usuarios ven la base de datos relacional como una colección de
tablas, y al ser la tabla la estructura fundamental del modelo, este goza de gran uniformidad, lo
que unido a unos lenguajes no navegacionales y orientados al usuario final da como resultado la
sencillez que los sistemas relacionales.
- Sólida fundamentación teórica: Al estar definido con rigor matemático, el diseño y la evaluación
del mismo pueden realizarse por métodos sistemáticos basados en abstracciones.
- Independencia de la interfaz de usuario: Los lenguajes relacionales, al manipular conjuntos de
registros, proporciona una gran independencia respecto a la forma en que los datos están
almacenados.
- Exhaustivas: aporta la cantidad y calidad de información exigible.
- No redundantes: es equivalente en BDR a una redundancia controlada (debido al intercambio de
claves tenemos algún tipo de redundancia).
- Estructuradas  en tablas o relaciones. Cualidades:
o No pueden tener atributos multievaluados.
o El orden de filas o columnas es intrascendente.
2. MODELO RELACIONAL
2.1. Características
El documento elaborado por Codd presenta de un modelo de datos basado en la teoría de las relaciones,
donde los datos se estructuran lógicamente en forma de relaciones o tablas, se apoya sobre el Álgebra y
Cálculo Relacional. El objetivo fundamental del modelo es mantener la independencia de esta estructura
lógica respecto al modo de almacenamiento y a otras características de tipo físico.
Codd definió 13 reglas que definen el modelo relacional.
La estructura básica y única del modelo relacional es la relación también llamada tabla, que sirve para
presentar tanto las entidades como las relaciones entre ellas.
Las tablas están formadas por:
o Columnas: atributos de la entidad, son las propiedades de las relaciones, y se definen sobre
dominios.
o Filas: diferentes valores de esos atributos de entidad.
o Dominio: Conjunto nominado, finito y homogéneo de valores atómicos que puede tomar una
columna. Cada dominio puede especificarse por extensión o por enumeración. Tiene existencia
propia con independencia de las relaciones.
o Universo de una tabla: Universo descrito definido por la unión de los dominios de las columnas.
o Grado: Número de atributos.

o Cardinalidad: número de tuplas de la relación.
Restricciones
• Inherentes
Son las derivadas de la misma estructura del modelo, que no tienen que ser definidas por el
usuarios e imponen limitaciones a la hora de modelar el mundo real.
El modelo impone limitaciones debidas a la existencia de la relación como único constructor.
Otras restricciones provienen de la definición matemática de relación al ser un conjunto no se
permite la existencia de tuplas duplicadas. Y de hay la obligatoriedad de clave primaria o
identificador, conjunto mínimo de atributos que identifican de forma univoca las tuplas de una
relación
Integridad de la Entidad: Es una relación inherente, debido a la necesidad de que todas las
tuplas sena distintas, lo que establece que “Ningún atributo de la tabla puede tomar valores
nulos”.
• Semánticas
Son facilidades proporcionadas por el modelo a fin de poder recoger en el esquema de la
relación la semántica del universo de discurso que estamos modelando. Son restricciones que
tiene que definir el diseñador a fin de que el esquema sea un reflejo lo mas fiel posible del
mundo real; de ahí la importancia de las restricciones en el diseño de la base de datos.
Un SGBDR debe incluir facilidades que permitan:
o En la fase de definición
 Describir las relaciones con precisión y sencillez.
 Indicar las acciones ante una posible violación de una restricción.
 Verificar la consistencia de las restricciones entre sí mismas.
o En la fase de manipulación:
 Comprobar que las actualizaciones cumplen las restricciones de integridad.
 Ponen en marcha las acciones indicadas en el caso de que las restricciones no
se cumplan.
La restricciones semánticas se pueden clasificar en:

 Clave candidatas: de una relación es un conjunto no vacío de atributos
(descriptor) que identifican univoca y mínimamente cada tupla e una relación.
Una relación pude tener mas de una clave candidata, entre las que podemos
distinguir:
o Clave primaria: Clave candidata que elige el usuarios por
consideraciones ajenas al modelo relacional, para identificar las tuplas
de la relación. Los atributos que forman pare de la clave primaria no
pude tomar valores a nulos.
o Claves alternativas: Aquellas claves que no han sido elegidas como
claves primarias de la relación.
 Clave ajena : conjunto de atributos que forman parte de una tabla y que
figura como clave primaria de otra tabla, es decir, una clave ajena de una
relación R2 es un conjunto no vacío de atributos cuyos valores han de coincidir
con los valores de la clave primaria de una relación R1 (R2 y R1 pueden ser la
misma relación). Se dice que R2 de la referencia mientras que R1 es la
referenciada.
Integridad referencial: Si una relación R2 tiene como descriptor CA que es clave ajena que
referencia la Clave primaria CP de una relación R1 tome valor de CA debe coincidir con el valor
CP o se nulo:
R2.CA=R2.CP
Col1 Col2 … Col n

Fila 1
Extensión
Fila 2 de la tabla
(nº de filas)
…
Fila n
Grado: nº de columnas
2.2. Com ponentes

Toda BDR se compone de los siguientes componentes:
- Catálogo, Diccionario o Metadatos: Estructuras de datos que almacenan la información
necesaria para explicar la existencia de cualquier elemento existente en la BD.
La mantiene actualizada el propio gestor. En ciertas excepciones la puede manipular el DBA (para
optimizaciones).
- Objetos de la Base: Tablas o relaciones y sobre ellas se pueden construir otros elementos
derivados:
o Vistas.
o Indices (optimización de accesos).
o Secuencias (para generar claves primarias).
o Assertions (rangos o dominios para columnas).
o Instanciaciones de clases (objetos persistentes).
- Reglas de Integridad
o Integridad de la Entidad: cualquier atributo que forme parte de una clave primaria
nunca puede tomar ni valores nulos, ni valores repetidos. Constraint PK (Primary Key)
o Integridad Referencial: aquellos atributos que formen parte de una FK unicamente
podrán tomar valores de los que existen en las PK de las tablas en las que se basan, o
excepcionalmente tomar valor nulo.
- NULL. En cualquier BD el valor nulo tiene un tratamiento especial. (ausencia de valor).
2.3. 12+1 Reglas de CODD

Las 12 reglas de Codd que determinan la fidelidad de un sistema relacional al modelo relacional. En la
década de los 80 comenzaron a aparecer numerosos SGBD que se anunciaban como "relacionales". Sin
embargo estos sistemas carecían de muchas características que se consideran importantes en un sistema
relacional, perdiendo muchas ventajas del modelo relacional. Como ejemplo extremo de esto "sistemas
relacionales" eran simplemente sistemas que utilizaban tablas para almacenar la información, no
disponiendo de elementos como claves primarias, etc.
En 1984 Codd publicó las reglas que un verdadero sistema relacional debería de cumplir. En la práctica
algunas de ellas son difíciles de realizar. Un sistema podrá considerarse "más relacional" cuanto más siga
estas reglas. Para que un gestor pueda considerarse un Gestor Relacional tiene que cumplir 6 reglas al
menos:
REGLA 0
Para que un sistema se denomine sistema de gestión de bases de datos relacionales, este sistema debe
usar (exclusivamente) sus capacidades relacionales para gestionar la base de datos.
REGLA 1: REGLA DE LA INFORMACIÓN

Toda la información en una base de datos relacional se representa explícitamente en el nivel lógico
exactamente de una manera: con valores en tablas.
Por tanto los metadatos (diccionario, catálogo) se representan exactamente igual que los datos de
usuario.
Y puede usarse el mismo lenguaje (ej. SQL) para acceder a los datos y a los metadatos (regla 4).
Un valor posible es el valor nulo, con sus dos interpretaciones:
- Valor desconocido (ej. dirección desconocida).
- Valor no aplicable (ej. empleado soltero no tiene esposa).
REGLA 2: REGLA DEL ACCESO GARANTIZADO

Para todos y cada uno de los datos (valores atómicos) de una BDR se garantiza que son accesibles a nivel
lógico utilizando una combinación de nombre de tabla, valor de clave primaria y nombre de columna.
Cualquier dato almacenado en una BDR tiene que poder ser direccionado unívocamente. Para ello hay que
indicar en qué tabla está, cuál es la columna y cuál es la fila (mediante la clave primaria).
Por tanto se necesita el concepto de clave primaria, que no es soportado en muchas implementaciones. En
estos casos, para lograr un efecto similar se puede hacer lo siguiente:
Hacer que los atributos clave primaria no puedan ser nulos (NOT NULL).
- Crear un índice único sobre la clave primaria.
- No eliminar nunca el índice.
REGLA 3: TRATAMIENTO SISTEMÁTICO DE VALORES NULOS

Los valores nulos (que son distintos de la cadena vacía, blancos, 0, ...) se soportan en los SGBD
totalmente relacionales para representar información desconocida o no aplicable de manera sistemática,
independientemente del tipo de datos.
Se reconoce la necesidad de la existencia de valores nulos, para un tratamiento sistemático de los mismos.
Hay problemas para soportar los valores nulos en las operaciones relacionales, especialmente en las
operaciones lógicas.
Lógica trivaluada. Es una posible solución. Existen tres (no dos) valores de verdad: Verdadero, Falso y
Desconocido (null). Se crean tablas de verdad para las operaciones lógicas:
- null Y null = null
- Verdadero Y null = null
- Falso Y null = Falso
- Verdadero O null = Verdadero
- etc.
Un inconveniente es que de cara al usuario el manejo de los lenguajes relacionales se complica pues es
más difícil de entender.
REGLA 4: CATÁLOGO DINÁMICO EN LÍNEA BASADO EN EL MODELO RELACIONAL

La descripción de la base de datos se representa a nivel lógico de la misma manera que los datos
normales, de modo que los usuarios autorizados pueden aplicar el mismo lenguaje relacional a su
consulta, igual que lo aplican a los datos normales.
- Es una consecuencia de la regla 1 que se destaca por su importancia. Los metadatos se
almacenan usando el modelo relacional, con todas las consecuencias.
REGLA 5: REGLA DEL SUBLENGUAJE DE DATOS COMPLETO

Un sistema relacional debe soportar varios lenguajes y varios modos de uso de terminal (ej: rellenar
formularios, etc.). Sin embargo, debe existir al menos un lenguaje cuyas sentencias sean expresables,
mediante una sintaxis bien definida, como cadenas de caracteres y que sea completo, soportando:
- Definición de datos
- Definición de vistas
- Manipulación de datos (interactiva y por programa)
- Limitantes de integridad
- Limitantes de transacción (iniciar, realizar, deshacer) (Begin, commit, rollback).
Además de poder tener interfaces más amigables para hacer consultas, etc. Siempre debe de haber una
manera de hacerlo todo de manera textual, que es tanto como decir que pueda ser incorporada en un
programa tradicional.
Un lenguaje que cumple esto en gran medida es SQL.
REGLA 6: REGLA DE ACTUALIZACIÓN DE VISTAS

Todas las vistas que son teóricamente actualizables se pueden actualizar por el sistema.
El problema es determinar cuáles son las vistas teóricamente actualizables, ya que no está muy claro.
Cada sistema puede hacer unas suposiciones particulares sobre las vistas que son actualizables.
REGLA 7: INSERCIÓN, ACTUALIZACIÓN Y BORRADO DE ALTO NIVEL

La capacidad de manejar una relación base o derivada como un solo operando se aplica no sólo a la
recuperación de los datos (consultas), si no también a la inserción, actualización y borrado de datos.
Esto es, el lenguaje de manejo de datos también debe ser de alto nivel (de conjuntos).
Algunas bases de datos inicialmente sólo podían modificar las tuplas de la base de datos de una en una
(un registro de cada vez).
REGLA 8: INDEPENDENCIA FÍSICA DE DATOS

Los programas de aplicación y actividades del terminal permanecen inalterados a nivel lógico cuando
quiera que se realicen cambios en las representaciones de almacenamiento o métodos de acceso.
El modelo relacional es un modelo lógico de datos, y oculta las características de su representación física.
REGLA 9: INDEPENDENCIA LÓGICA DE DATOS

Los programas de aplicación y actividades del terminal permanecen inalterados a nivel lógico cuando
quiera que se realicen cambios a las tablas base que preserven la información.
Cuando se modifica el esquema lógico preservando información (no valdría p.ej. eliminar un atributo) no
es necesario modificar nada en niveles superiores.
Ejemplos de cambios que preservan la información:
Añadir un atributo a una tabla base.
Sustituir dos tablas base por la unión de las mismas. Usando vistas de la unión puedo recrear las tablas
anteriores...
REGLA 10: INDEPENDENCIA DE INTEGRIDAD

Los limitantes de integridad específicos para una determinada base de datos relacional deben poder ser
definidos en el sublenguaje de datos relacional, y almacenables en el catálogo, no en los programas de
aplicación.
El objetivo de las bases de datos no es sólo almacenar los datos, si no también sus relaciones y evitar que
estas (limitantes) se codifiquen en los programas. Por tanto en una BDR se deben poder definir limitantes
de integridad.
Cada vez se van ampliando más los tipos de limitantes de integridad que se pueden utilizar en los SGBDR,
aunque hasta hace poco eran muy escasos.
Como parte de los limitantes inherentes al modelo relacional (forman parte de su definición) están:
- Una BDR tiene integridad de entidad. Es decir, toda tabla debe tener una clave primaria.
- Una BDR tiene integridad referencial. Es decir, toda clave externa no nula debe existir en la
relación donde es primaria.
REGLA 11: INDEPENDENCIA DE DISTRIBUCIÓN

Una BDR tiene independencia de distribución.
Las mismas órdenes y programas se ejecutan igual en una BD centralizada que en una distribuida.
Las BDR son fácilmente distribuibles:
- Se parten las tablas en fragmentos que se distribuyen.
- Cuando se necesitan las tablas completas se recombinan usando operaciones relacionales con los
fragmentos.
- Sin embargo se complica más la gestión interna de la integridad, etc.
Esta regla es responsable de tres tipos de transparencia de distribución:
- Transparencia de localización. El usuario tiene la impresión de que trabaja con una BD local.
(aspecto de la regla de independencia física)
- Transparencia de fragmentación. El usuario no se da cuenta de que la relación con que trabaja
está fragmentada. (aspecto de la regla de independencia lógica de datos).
- Transparencia de replicación. El usuario no se da cuenta de que pueden existir copias (réplicas)
de una misma relación en diferentes lugares.
REGLA 12: REGLA DE LA NO SUBVERSIÓN

Si un sistema relacional tiene un lenguaje de bajo nivel (un registro de cada vez), ese bajo nivel no puede
ser usado para saltarse (subvertir) las reglas de integridad y los limitantes expresados en los lenguajes
relacionales de más alto nivel (una relación (conjunto de registros) de cada vez).
- Algunos problemas no se pueden solucionar directamente con el lenguaje de alto nivel.
- Normalmente se usa SQL inmerso en un lenguaje anfitrión para solucionar estos problemas. Se utiliza el
concepto de cursor para tratar individualmente las tuplas de una relación. En cualquier caso no debe ser
posible saltarse los limitantes de integridad impuestos al tratar las tuplas a ese nivel.
2.4. N orm alización
La normalización es una técnica para diseñar la estructura lógica de los datos de un sistema de
información en el modelo relacional, desarrollada por E. F. Codd en 1972. Es una estrategia de diseño de
abajo a arriba: se parte de los atributos y éstos se van agrupando en relaciones (tablas) según su
afinidad. Aquí no se utilizará la normalización como una técnica de diseño de bases de datos, sino como
una etapa posterior a la correspondencia entre el esquema conceptual y el esquema lógico, que elimine
las dependencias entre atributos no deseadas. Las ventajas de la normalización son las siguientes:
• Evita anomalías en inserciones, modificaciones y borrados.

• Mejora la independencia de datos.
• No establece restricciones artificiales en la estructura de los datos.
Uno de los conceptos fundamentales en la normalización es el de dependencia funcional. Una dependencia

funcional es una relación entre atributos de una misma relación (tabla). Si X e Y son atributos de la
relación R , se dice que Y es funcionalmente dependiente de X(se denota por X -> Y) si cada valor de
tiene asociado un solo valor de Y(X e Y pueden constar de uno o varios atributos). A X se le denomina
determinante, ya que X determina el valor de Y. Se dice que el atributo Y es completamente dependiente
de X si depende funcionalmente de X y no depende de ningún subconjunto de X .
La dependencia funcional es una noción semántica. Si hay o no dependencias funcionales entre atributos
no lo determina una serie abstracta de reglas, sino, más bien, los modelos mentales del usuario y las
reglas de negocio de la organización o empresa para la que se desarrolla el sistema de información. Cada
dependencia funcional es una clase especial de regla de integridad y representa una relación de uno a
muchos.
En el proceso de normalización se debe ir comprobando que cada relación (tabla) cumple una serie de
reglas que se basan en la clave primaria y las dependencias funcionales. Cada regla que se cumple
aumenta el grado de normalización. Si una regla no se cumple, la relación se debe descomponer en varias
relaciones que sí la cumplan.
La normalización se lleva a cabo en una serie pasos. Cada paso corresponde a una forma normal que tiene
unas propiedades. Conforme se va avanzando en la normalización, las relaciones tienen un formato más
estricto (más fuerte) y, por lo tanto, son menos vulnerables a las anomalías de actualización. El modelo
relacional sólo requiere un conjunto de relaciones en primera forma normal. Las restantes formas
normales son opcionales. Sin embargo, para evitar las anomalías de actualización, es recomendable llegar
al menos a la tercera forma normal.
Para que una solución sea relacional tiene que cumplir la teoría de normalización.
La metodología METRICA 3considera suficiente que se cumplan con las 3 primeras formas normales.
(1FN, 2FN, 3FN).
Vamos a continuación a definir las formas normales, las tres primeras y la de Boyce y Codd, son las que se
apoyan en las dependencias funcionales.
2.4.1.1 Primera Forma Normal(1FN)

Para que una tabla pueda ser considerada una relación no se deben admitir grupos repetitivos, esto es
debe estar en primera forma normal. En otras palabras una tabla están en 1FN cuando todas sus entradas
son simples. (un solo valor para cada atributo en una tupla).
Por ejemplo tenemos una tabla de empleados en los que hay un grupo repetitivo teléfono, mas de un
teléfono para cada empleado, para pasarla a 1FN habrá que repetir todos los atributos de una tupla para
cada una do de los Calores del grupo repetitivo.
- EMP (CodEmp, Nombre, Dir, Tel)
- EMP (A, B, C, D)
o A  B ; A  C ; A / D (puede tener distintos nºs de teléfono).
Una relación está en primera forma normal si, y sólo si, todos los dominios de la misma contienen valores
atómicos, es decir, no hay grupos repetitivos. Si se ve la relación gráficamente como una tabla, estará en
1FN si tiene un solo valor en la intersección de cada fila con cada columna.
Si una relación no está en 1FN, hay que eliminar de ella los grupos repetitivos. Un grupo repetitivo será el
atributo o grupo de atributos que tiene múltiples valores para cada tupla de la relación. Hay dos formas de
eliminar los grupos repetitivos. En la primera, se repiten los atributos con un solo valor para cada valor del
grupo repetitivo. De este modo, se introducen redundancias ya que se duplican valores, pero estas
redundancias se eliminarán después mediante las restantes formas normales. La segunda forma de
eliminar los grupos repetitivos consiste en poner cada uno de ellos en una relación aparte, heredando la
clave primaria de la relación en la que se encontraban.
2.4.1.2 Segunda Forma Normal(2FN)

Se dice que una relación está en 2FN si:
- Está en 1FN.
- Cada atributo no principal tiene dependencia funcional completa respecto de cada una de las
claves.
Ningún atributo no principal (que no sea clave) depende parcialmente de ninguna clave.
La 2FN se aplica a las relaciones que tienen claves primarias compuestas por dos o más atributos. Si una
relación está en 1FN y su clave primaria es simple (tiene un solo atributo), entonces también está en 2FN.
Las relaciones que no están en 2FN pueden sufrir anomalías cuando se realizan actualizaciones.
Para pasar una relación en 1FN a 2FN hay que eliminar las dependencias parciales de la clave primaria.
Para ello, se eliminan los atributos que son funcionalmente dependientes y se ponen en una nueva
relación con una copia de su determinante (los atributos de la clave primaria de los que dependen).
2.4.1.3 Tercera Forma Normal (3FN)

Se dice que una relación está en 3FN si:
- Está es 2FN.
- No existe ningún atributo no principal que dependa transitivamente de alguna de las claves de la
relación.
Ningún atributo no principal puede depender transitivamente de ninguna clave. La dependencia X-> Z es
transitiva si existen las dependencias X->Y, Y->Z , siendo X, Y, atributos o conjuntos de atributos de una
misma relación.
Aunque las relaciones en 2FN tienen menos redundancias que las relaciones en 1FN, todavía pueden sufrir
anomalías frente a las actualizaciones. Para pasar una relación de 2FN a 3FN hay que eliminar las
dependencias transitivas. Para ello, se eliminan los atributos que dependen transitivamente y se ponen en
una nueva relación con una copia de su determinante (el atributo o atributos no clave de los que
dependen).
2.4.1.4 Forma normal de Boyce-Codd (BCFN)

Las tres formas normales que acabamos de ver fueron propuestas originariamente por CODD, pero con el
paso del tiempo se mostraron insuficientes para afrontar ciertos problemas en relaciones que presentaban
varias claves candidatas compuestas que se solapaban Por ello en 1974, Boyce y Codd definieron la
llamada forma normal que lleva su nombre (FNBC), ya descrita por Heath aunque con ligeras diferencias
en 1971. SE trata de una redefinición mas estricta de la 3FN.
Una relación está en la forma normal de Boyce-Codd si, y sólo si, todo determinante es una clave
candidata.
La 2FN y la 3FN eliminan las dependencias parciales y las dependencias transitivas de la clave primaria.
Pero este tipo de dependencias todavía pueden existir sobre otras claves candidatas, si éstas existen. La
BCFN es más fuerte que la 3FN, por lo tanto, toda relación en BCFN está en 3FN.
La violación de la BCFN es poco frecuente ya que se da bajo ciertas condiciones que raramente se
presentan. Se debe comprobar si una relación viola la BCFN si tiene dos o más claves candidatas
compuestas que tienen al menos un atributo en común. No siempre es posible llegar a la FNBC sin perdida
de dependencias funcionales
2.4.1.5 FORMAS NORMALES AVANZADAS

Existen otro tipo de dependencias entre datos, distintas a las funcionales, que también hay que tener en
cuenta en el momento del diseño de una base de datos relacional. Aparecen nuevos tipos de
dependencias como las multivaluadas y las de combinación.
2.4.1.5.1 Dependencias m ultivaluadas:

Son una generalización de las dependencias funcionales, y así como en estas últimas el valor de un
desciptor (implicante) determina un sólo valor de otro descriptor (implicado), en las multivaluadas aparece
un conjunto de valores del implicado en lugar de uno sólo.
Se trata de una sentencia X->->Y que leeremos X “multidetermina” a Y, donde X e Y son descriptores
tales que un cierto valor de C implica un conjunto bien definido de valores de Y, con independencia del
resto de los atributos de la relación
2.4.1.5.2 Cuarta Form a N orm al (4FN)

Diremos que una relación se encuentra en 4FN si y sólo si, las únicas dependencias multivaluadas no
triviales son aquellas en las cuales una clave multidetermina un atributo, es decir, toda dependencia
multivaluada viene determinada por una clave candidata.
2.4.1.5.3 Dependencias de Com binación

Son anomalías que se ponen de manifiesto cuando se actualiza la base de datos. Por ejemplo no se puede
borrar una tupla sin eliminar otras tuplas, Tiene que ver con tablas que pueden dividirse en subtablas,
pero que no pueden reconstruirse. Se trata de relaciones que no pueden descomponerse en proyecciones
sin pérdida de información.
Las dependencias de combinación son, al igual que las otras dependencias, una restricción sobre la
relación y constituyen una generalización de las anteriores, de forma que una dependencia funcional es
siempre también multivaluada y de combinación, y una multivaluada es también de combinación , pero la
afirmación inversa no es cierta.
2.4.1.5.4 Quinta Form a N orm al (5FN)
Decimos que una relación estás en 5FN si, y sólo si, está en todas las anteriores formas normales y toda
dependencia de combinación está implicada por la clave candidata. Un esquema de relaciones R está en
5FN con respecto a un conjunto D de dependencias funcionales, de valores múltiples y de producto, si
para todas las dependencias de productos en D se cumple por lo menos una de estas condiciones:
• (R1, R2, R3, ... Rn) es una dependencia de producto trivial.

• Toda Ri es una clave candidata de R.
Otra definición mas sencilla es que una relación está en 5FN si y solo si toda dependencia funcional
multivaluada o de combinación no trivial es consecuencia de las claves candidatas.
2.5. Álgebra relacional

El álgebra relacional es un lenguaje de consulta procedimental. Consta de un conjunto de operaciones que
toman como entrada una o dos relaciones y producen como resultado una nueva relación.
Los operandos del álgebra relacional son siempre relaciones y los operadores se aplican por tanto a loas
relaciones con el fin de formular consultas a las bases de datos.
2.5.1. Operadores
Operadores básicos: Son operacionalmente completos ,permiten expresar cualquier consulta a una BDR
y son los siguientes:
• UNION: R U S
La unión de dos relaciones R y S, es otra relación que contiene las tuplas que están en R, o en
S, o en ambas, eliminándose las tuplas duplicadas. R y S deben ser unión-compatible, es decir,
definidas sobre el mismo conjunto de atributos
de bases de datos.
10
• DIFERENCIA: R - S
La diferencia de dos relaciones R y S, es otra relación que contiene las tuplas que están en la
relación R, pero no están en S.
R y S deben ser unión-compatible
• PRODUCTO CARTESIANO.: R x S
El producto cartesiano (RxS) es una relación de grado m+n constituida por todas las tuplas, en
las que los m primeros elementos son una tupla de R y los n últimos una de S.
• PROYECCIÓN: ∏ col1, . . . , coln(R)

Es un operador unario.
La proyección de una relación sobre un conjunto de atributos X de T es una relación formada por
las mismas tuplas de R, pero sólo con los valores de los atributos de X.
de bases de datos.
11
• SELECCIÓN. δpredicado (R)

Es un operador unario. La selección de una relación R con una fórmula F es una relación
formada por el conjunto de las tuplas de R tales que cumplen el valor de verdad de la fórmula F.
Operadores derivados:
• INTERSECCIÓN. R ∩ S
Define una relación que contiene el conjunto de todas las filas que están tanto en la
relación R como
en S.
 R y S deben ser unión-compatible
 Equivalencia con operadores básicos
R ∩ S = R – (R – S)
• DIVISIÓN.R / S
Define una relación sobre el conjunto de atributos C, incluido en larelación R, y que contiene el
conjunto de valores de C, que en las tuplas de R están combinadas con cada una de las tuplas de
S. Condiciones:
 grado(R) > grado (S)
 conjunto atributos de S Ì conjunto de atributos de R
Equivalencia con operadores básicos

X1 = PC(R); X2 = PC((S X X1) – R); X = X1 – X2
de bases de datos.
12
• ASOCIACIÓN. R * F S
Define una relación que contiene las tuplas que satisfacen el predicado F en el producto
cartesiano de R y S.
El predicado F es de la forma R.ai θ S.bi donde q representa un operador de comparación
(<, £, >, ³, =, ¹)
El predicado no tiene por que definirse sobre atributos comunes.
Equivalencia con operadores básicos
R F S = σ F(R C S)
Equijoin
Si el predicado F contiene únicamente el operador de igualdad
o Se define la asociación como el conjunto de tuplas pertenecintes al producto cartesiano
de R1 y R2, que cumplen la condición de que la columna i-ésima de R1 está relacionada
con la columna j-esima de R2, según el operador teta.
o JOIN. R * S
El resultado es una relación con los atributos de ambas relaciones y se obtiene combinando
las tuplas de ambas relaciones que tengan el mismo valor en los atributos comunes.
Normalmente la operación de join se realiza entre los atributos comunes de dos tablas que
corresponden a la clave primaria de una tabla y la clave foránea correspondiente de la otra
tabla.
Método
o Se realiza el producto cartesiano R x S
o Se seleccionan aquellas filas del producto cartesiano para las que los atributos
comunes tengan el mismo valor.
o Se elimina del resultado una ocurrencia (columna) de cada uno de los atributos
comunes
o Equivalencia con operadores básicos
de bases de datos.
13
o R* F S = sF(R X S)
Outer Join
Es una variante del Join en la que se intenta mantener toda la información de los
operandos, incluso para aquellas filas que no participan en el Join.
Se “rellenan con nulos” las tuplas que no tienen correspondencia en el Join.
Tres variantes
 Left: se tienen en cuenta todas las filas del primer operando
 Right: se tienen en cuenta todas las filas del segundo operando
 Full:se tienen en cuenta todas las filas de ambos operandos
3. EL LENGUAJE SQL
3.1. Generalidades
SQL (STRUCTURES QUERY LANGUAJE, lenguaje estructurado de consultas) es un lenguaje de consulta
utilizado para manipular bases de datos relacionales. De los distintos lenguajes que presentaban los
primeros SGBDR (Sistemas de Gestión de Bases de Datos Relacionales), ha acabado imponiéndose como
estándar, tanto de iure como de facto, el SQL, lenguaje que actualmente ofrecen, aunque con variaciones,
la mayor parte de los productos comerciales y que viene siendo objeto, desde hace varios años, de un
intenso proceso de normalización.
Fue desarrollado a mediado de los años 70 por IBM. Por esos años se llamaba SEQUEL (Structured English
QUEry Language) y servía como interfaz para un sistema experimental de base de datos llamado SYSTEM
R. Fue introducido por Oracle por primera vez en una base de datos comercial en el año 1979.
El lenguaje se utiliza para definir, consultar y actualizar la base de datos, y es el más popular de su estilo.
La estructura básica para consultas en SQL es el SELECT-FROM-WERE.
Conceptualmente, SQL es un lenguaje de definición de datos (LDD), un lenguaje de definiciones de vistas
(LDV) y un lenguaje de manipulación de datos (LMD), que posee también capacidad para especificar
restricciones y evolución de esquemas.
de bases de datos.
14
3.1.1. Normalización
Debido a la importancia de los lenguajes de bases de datos, existen numerosos organismos que se ocupan
de su estandarización.
En el comité conjunto JTC1, establecido por los organismos ISO e IEC para las Tecnologías de la
Información, existe el subcomité 21 que engloba al WG3 que se dedica a las bases de datos.
En Estados Unidos, además del grupo H2 de ANSI, también el NIST (National Institute of Standards and
Technology) se ocupa de la estandarización del SQL.
Por otra parte, hay que destacar el denominado SQL Access Group, un consorcio formado por varias
decenas de fabricantes de productos con el fin de “definir especificaciones técnicas que permitan a
distintos SGBDR y herramientas de aplicación trabajar conjuntamente"; para ello se propone acelerar los
esfuerzos de estandarización del lenguaje SQL aportando propuestas a los grupos RDA y SQL.
La Unión Europea, siguiendo las recomendaciones del proyecto EWOS (European Workshop on Open
Systems), ha creado en abril de 1991 el EG DBE (Expert Group on Database Enquiry), en el que también
desempeña un papel muy relevante el SQL.
Además existen otras asociaciones como X/OPEN, la OSF (Open Software Foundation) o la Asociación
Europea de Fabricantes de Ordenadores, que han adoptado extensiones del lenguaje.
Por último, cabe destacar que existen distintos vendedores que han definido sus propios estándares
basándose en los aprobados por ANSI e ISO.
2. EVOLUCIÓN DEL LENGUAJE SQL
El modelo relacional surge a finales de los años sesenta como resultado de las investigaciones de E.F.
Codd en los laboratorios de IBM en San José (California); los trabajos de Codd dieron lugar a una serie de
estudios teóricos y prototipos que se extienden a partir de 1970.
El lenguaje SQL surge originariamente con el nombre de SEQUEL (Structured English QUEry Language)
implementado en un prototipo de IBM, el SEQUEL-XRM, durante los años 1974-75. Este prototipo
evolucionó durante los años 1976-77, pasándose a denominar su lenguaje SEQUEL/2, y cambiando
posteriormente este nombre por SQL, debido a motivos legales. Poco después, el SISTEMA R de IBM
implementó un subconjunto de este lenguaje.
En 1979 aparece el primer SGBDR comercial basado en SQL -ORACLE, posteriormente van surgiendo otros
productos basados en SQL como son el SQL/DS, DB2, DG/SQL, SYBASE, INTERBASE, INFORMIX, UNIFY,
etc. E incluso otros productos que no poseían el SQL como lenguaje base. INGRES, DATACOM, ADABAS,
SUPRA, IDMS/R- ofrecen interfaces SQL; por lo que este lenguaje se convierte en un estándar de facto,
aunque con múltiples variantes según los distintos fabricantes.
En 1982 el Comité de bases de datos X3H2 de ANSI presenta un lenguaje relacional estándar basado
principalmente en el SQL propio de los productos IBM; en 1986 este organismo aprueba el lenguaje como
norma pasando a denominarse SQL/ANS,(SQL-86 o SQL1)que también es aprobado, al año siguiente,
como norma ISO -ISO (l987). En esta norma se especifican dos niveles (I y II) a cumplir, siendo el nivel I
un subconjunto de las funcionalidades proporcionadas por el nivel II. Este estándar ha recibido numerosas
críticas, ya que resulta ser "una intersección de las instrumentaciones existentes", concebido
primordialmente para proteger los intereses de los fabricantes. Así, por ejemplo, en Codd(1985) se afirma
que ".. desafortunadamente el SQUANS es muy débil, fallando en el soporte de numerosas características
que los usuarios realmente necesitan si quieren aprovechar todas las ventajas del enfoque relacional... El
SQUANS es incluso menos fiel al modelo relacional que el SQL de algunos suministradores...”.
En 1989 se revisa la versión 1 del estándar -ISO(1989)-, revisión conocida como Addendum, que añade
cierta integridad referencial, que se denomina integridad referencial básica, ya que sólo permite definir la
opción de modificación y borrado restringidos y no proporciona cambios en cascada. Por otra parte, ya
que la norma ISO de 1989 no estandariza las definiciones para SQL embebido en lenguajes de
programación -que sólo figuraban en apéndices recomendados-, ANSI define, ese mismo año, un estándar
para el lenguaje SQL embebido -ANS1(1989)-. En este mismo año Apple Computer libera el Data Access
Language (DAL) para sus ordenadores, (DAL es un dialecto del SQL que soporta varios gestores de bases
de datos).
de bases de datos.
15
En junio de 1990, IBM anuncia su estándar DRDA (Distributed Relational Database Access) como parte de
su arquitectura SAA (System Application Architecture).
En abril de 1991 el SAG (SQL Access Group) completa la 1ª Fase de especificaciones técnicas, que define
un estándar para intercambiar mensajes SQL sobre una red OSI, basado en la especialización SQL del RDA
de ISO. En junio de 1991 este grupo realizó una demostración -que constituyó todo un éxito- con más de
veinte SGBDR que se intercambiaban datos y consultas. En el mes de noviembre de este mismo año
Microsoft anunció ODBC (Open Database Connectivity) basado en el estándar del SAG.
En 1992 este grupo completó su segunda fase, que especificaba un IPA (Interfaz para la Programación de
Aplicaciones) CLI (Call Level Interface) y que ampliaba el estándar a más instalaciones cliente/servidor, en
la que además de las especificaciones OSI se incluye otros protocolos de red como, por ejemplo, TCP/IP.
En noviembre de ese año Borland relanzó el estándar ODAPI (Open Database Application Programming
Interface) como IDAPI (Integrated Database Application Programming Interface), con el patrocinio de
IBM, Novell y WordPerfect.
En 1992 también se aprueba como norma internacional una nueva versión del SQL, conocida como SQL2
o SQL-92 -ISO(1992)-, en la que se incrementa substancialmente la capacidad semántica del esquema
relacional, se añaden nuevos operadores, se mejora el tratamiento de errores y se incluyen normas para
el SQL embebido. En esta nueva norma se definen tres niveles de conformidad distintos:
Entry SQL, Intermediate SQL y Full SQL, siendo este último -como su nombre indica- el que ofrece
mayores funcionalidades, mientras que el primer nivel es un subconjunto del segundo y éste, a su vez, del
tercero.
Este estándar ha sido complementado recientemente con dos nuevas partes que abordan la interfaz de
nivel de llamadas (Call-Level Interface), ISO (1995) y la definición de módulos almacenados persistentes
(Persistent Stored Modules) ISO (1996). Esta última norma internacional convierte al SQL en un lenguaje
computacionalmente completo añadiéndole estructuras de control, manejo de excepciones, etc.
En 1999 aparecen nuevas propuestas para extender el SQL, dotándolo de una mayor capacidad
semántica, de ciertos principios del paradigma de la orientación al objeto es el llamado SQL3 con la
publicación en Noviembre de 1999 de ISO/IEC 9075-1:1999 SQL3 Framework. Actualmente existen hasta
13 partes de la norma: la última ISO/IEC 9075-13:2002: Rutinas y Tipos SQL usando lenguaje de
programación Java. De hecho la importancia que tiene hoy en día el OQL del ODMG (Object Database
Management Group es un grupo de fabricantes, proveedores, desarrolladores y usuarios que elaboran
estándares para los Sistemas Gestores de Bases de Datos Orientados a Objetos) ya no tiene tanta fuerza
debido a que SQL3 incluye bases para el trabajo con estructuras orientadas a objetos.
Se trabaja también sobre una extensión del SQL3 para soportar bases de datos multimedia, conocida
como SQL/MM, SQL Multimediay paquetes aplicación (incluyendo extensiones a SQL para minería de
datos. Parte 1 de la norma: ISO/IEC 13249-1:2002 SQL/MM Framework 2nd Edition).
Debido al tamaño que posee el SQL3 se comienza el SQL4, en el que se incluyen aquellas características
del lenguaje que no se encuentran todavía definidas completamente o que necesitan una mayor
profundización. Se trata del primer estandar SQL/XML (2003), se publicó por la International Organization
for Standardization (ISO) como la parte 14 del estándar SQL: ISO/IEC 9075-14:2003. SQL/XML es un
estandard ANSI, ISO que incorpora XML dentro del lenguaje SQL de bases de datos objeto-relacionales.
SQL:2003 es el estándar para acceder y manejar datos de bases de datos objeto-relacionales. Las
empresas y los usuarios necesitan integrar sus datos XML en sus bases de datos objeto-relacionales,
aprovechando las ventajosas facilidades de SQL.
SQL/XML permite almacenar sus documentos XML en sus bases de datos objeto-relacionales, para
consultar dichos documentosmediante “Xpath” y “Xquery” y para “ publicar” sus datos SQL en un formato
de documentos XML.
Debido a esta normalización la mayor parte de los creadores de sistemas de bases de datos relacionales
integran SQL en sus productos :DB2, ORACLE, SQLSERVER....
de bases de datos.
16
Los datos, consultas y aplicaciones pueden por tanto portarse fácilmente de una base de datos a otra.
Año Nombre Alias Comentarios
1986 SQL-86 Sql-87 Pimera publicación hecha por ANSI confirmada por ISO en
1987
1989 SQL-89 Revisión menor
1992 SQL-92 SQL2 Revisión mayor
1999 SQL:1999 SQL2000 Se agregaron expresiones regulares, consultas recursivas
(para relaciones jerárquicas), triggers y algunas características
orientadas a objetos.
2003 Sql:2003 Introduce algunas características de XML, cambios en las
funciones, estandarización del objeto sequence y de las
columnas autonumericas
2006 SQL:2006 ISO/IEC 9075-14:2006 Define las maneras en las cuales el
SQL se puede utilizar conjuntamente con XML. Define maneras
importar y guardar datos XML en una base de datos SQL,
manipulándolos dentro de la base de datos y publicando el
XML y los datos SQL convencionales en forma XML. Además,
proporciona facilidades que permiten a las aplicaciones
integrar dentro de su código SQL el uso de XQuery, lenguaje
de consulta XML publicado por el W3C (World Wide Web
Consortium) para acceso concurrente a datos ordinarios SQL y
documentos XML
3.2. El lenguaje SQL
3.2.1. CONCEPTOS SQL

Aunque el lenguaje SQL se basa en el modelo relacional, incorpora algunos elementos adicionales que
facilitan la gestión de datos. En este sentido se introduce el concepto de catálogo, entendido como un
conjunto de esquemas, que proporciona un mecanismo adicional para calificar nombres de elementos
(catálogo.esquerna.elemento), facilitando así la gestión del espacio de nombres.
Un entorno SQL puede contener cero o varios catálogos y, a su vez, un catálogo uno o varios esquemas.
En cada catálogo existe un DEFINITION_SCHEMA que contiene las tablas base sobre las que se define un
conjunto de vistas denominado INFORMATION_SCHEMA, esquemas que son autodescriptivos. Las tablas
base definidas en el estándar son las siguientes:
• USERS, SCHEMATA, DATA_TYPE_DESCRIPTOR, DOMAINS, DOMAINS_CONSTRAINTS, TABLES,

VIEWS, COLUMNS, VIEW_TABLE_USAGE, VIEW_COLUMN_USAGE, TABLE_CONSTRAINTS,
KEY_COLUMN_USAGE,
• REFERENTIAL_CONSTRAINTS, CHECK_CONSTRAINTS, CHECK_TABLE_USAGE,
CHECK_COLUMN_USAGE, ASSERTIONS, TABLE_PRIVILEGES,
• COLUMN_PRIVILEGES, USAGE_PRIVILEGES, CHARACTER_SETS, COLLATIONS, TRANSLATIONS,
SQL_LANGUAGES.
Los nombres de estas tablas son autoexplicativos y se parecen a las presentes en los catálogos de los
productos existentes.
El lenguaje introduce también el concepto de agrupamiento (cluster), que sirve para referenciar el
conjunto de catálogos a los que se puede acceder en un momento dado.
Por otra parte, merece la pena destacar que en el esquema SQL se puede encontrar, además de tablas,
dominios, aserciones, vistas o la concesión y revocación de privilegios, la definición de conjuntos de
caracteres (Character Set), así como, secuencias de ordenación (Collation) y traducción (Translation) para
estos conjuntos de caracteres. Esto permite soportar lenguajes como el japonés, coreano o chino, que
superan los 256 caracteres y que pueden obtenerse con una extensión de 8 bits del código ASCII.
3.2.2. DDL Descripción de objetos

Permite la especificación de un conjunto de relaciones y además de información sobre cada una de las
relaciones, incluyendo:
• El esquema de cada relación.

• El dominio de los datos asociados a cada atributo.
de bases de datos.
17
• Restricciones de integridad.
• El conjunto de índices que se debe mantener para cada relación.
• Información de seguridad y autorización para cada relación.
• La estructura de almacenamiento físico de cada relación en disco.
Sentencias de definición:
• Utilizaremos una extensión de la Forma Normal de Backus (BNF) para
• especificar las cláusulas del lenguaje donde:
• < > representa los símbolos no terminales del lenguaje
• ::= es el operador de definición
• [] indica elementos opcionales
• {} agrupa elementos en una fórmula
• | indica una alternativa
• ... indica repetición
De los distintos elementos que puede contener un esquema relacional en SQL2, estudiaremos los
dominios, aserciones y tablas; tenemos que advertir que presentaremos las opciones y posibilidades que
resultan, a nuestro juicio, más interesantes, remitiendo al lector a las referencias bibliográficas para un
estudio más exhaustivo de los distintos elementos del lenguaje.
3.2.2.1 Esquemas
La creación de esquemas se lleva a cabo mediante la sentencia:
<definición de esquemas>::=
CREATE SCHEMA <cláusula de nombre del esquema>
[<especificación del conjunto de caracteres del esquema>]
[<elemento de esquema> ... ]
<cláusula de nombre del esquema>::= <nombre del esquema>
| AUTHORIZATION <id. autorización del esquema>
| <nombre del esquema> AUTHORIZATION <id. autorización del
esquema>
3.2.2.1.1 Dom inios
La definición de dominios es de la siguiente manera:
<definición de dominio> ::=

CREATE DOMAIN <nombre de dominio> [ AS ] <tipo de datos1>
DEFAULT <opción por defecto> ]
<restricción de dominio> ]
donde la opción por defecto puede ser un literal, una función de valor tiempo o
fecha, o bien USER, SYSTEM USER o NULL; mientras que se define
<restricción de dominio> ::=

[ <definición de nombre de restricción> ]
< definición de restricción de verificación>
[ <atributos de restricción> ]
en la cual se puede, opcionalmente, dar un nombre a la restricción de dominio de

la siguiente forma:
<definición de nombre de restricción> ::=

CONSTRAINT <nombre de restricción>
El único elemento obligatorio de la restricción de dominio es la:
<definición de restricción de verificación> ::=

CHECK <parent. izq.> <condición> <parent. dcho.>
de bases de datos.
18
Así, por ejemplo, se podría definir el siguiente dominio, en el que se quiere especificar, por intensión, que
los tipos de documentos válidos en una biblioteca son artículos o libros:
CREATE DOMAIN Tipos_Doc CHAR(1)

CONSTRAINT Artículos_o_Libros
CHECK (VALUE IN (‘A’,’ L’));
Por lo que respecta a los atributos de restricción, sirven para indicar si la restricción es diferida o
inmediata:
<atributos de restricción> ::=

<tiempo de verificación de restricción> [ [NOT] DEFERRABLE]
| [ [NOT] DEFERRABLE] <tiempo de verificación de restricción>
<tiempo de verificación de restricción>
INITIALLY DEFERRED
| INITIALLY INMEDIATE
Así, si 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.
3.2.2.1.2 Tablas
Hay que recordar que existe una diferencia fundamental entre una tabla en SQL y una relación del modelo
relacional, ya que mientras que ésta se define como un conjunto de tuplas, una tabla es en realidad un
multiconjunto de filas, por lo que admite filas repetidas.
En el SQL92 se pueden definir tablas persistentes -que, como su nombre indica, se almacenan en memoria
secundaria y permanecen allí cuando termina la sesión en la que fueron creadas- o tablas temporales -que
sólo se materializan y tienen existencia en tanto dura la sesión-, tal como indica la definición siguiente:
<definición de tabla> ::=

CREATE [ TEMPORARY ] TABLE <nombre de tabla>
<paréntesis izq.> <elemento de tabla>
[{<coma> <elemento de tabla>} ... ] <paréntesis dcho.>
Los elementos de tabla pueden ser tanto definiciones de columnas como definiciones de restricciones de
tabla. Una columna debe definirse sobre un dominio o bien directamente con un tipo de datos, pudiendo
presentar además valores por defecto y restricciones de columna:
<definición de columna> ::=

<nombre de columna> { <tipo de datos> | <nombre de dominio>}
<claúsula de valor por defecto> ]
<definición de restricción de columna> ]
Las definiciones de restricción, tanto de columnas como de tablas, presentan, al igual que en el caso de
los dominios, la posibilidad de nominar dichas restricciones y de indicar si son inmediatas o diferidas
mediante los atributos de restricción:
<definición de restricción de columna> ::=

[ <definición de nombre de restricción> ]
<restricción de columna>
[ <atributos de restricción>
<definición de restricción de tabla> ::=
[ <definición de nombre de restricción>
<restricción de tabla>
[ <atributos de restricción> ]
Las restricciones de columna pueden indicar la obligatoriedad de un valor -escribiendo NOT NULL-, si una
columna es clave primaria de la tabla –mediante PRIMARY KEY-, si es clave alternativa, esto es, que sus
valores no pueden repetirse en toda la tabla -especificando UNIQUE-, o cualquier otra condición. En caso
de que la clave primaria o las claves alternativas estuviesen compuestas por varios atributos, habría que
establecer restricciones de tabla de forma análoga a las de columna anteriormente descritas. En general,
podemos considerar las restricciones de columnas como un caso especial de restricciones de tablas, con lo
que, por ejemplo, la definición de clave primaria -cuando está compuesta sólo por un atributo- puede
realizarse tanto al lado de la columna correspondiente como al finalizar la descripción de atributos.
de bases de datos.
19
Un ejemplo de tabla puede ser el siguiente, en la que se definen las editoriales, con una serie de
atributos:
CREATE TABLE Editorial
(Código_E Códigos,
Nombre_E Nombres NOT NULL,
Dirección Dirs NOT NULL,
Ciudad Lugares NOT NULL,
PRIMARY KEY (Código_E),
UNIQUE (Nombre_E));
3.2.2.1.3 Restricciones y reglas de integridad
Como hemos comentado, en el lenguaje SQL-92 no se cumple la restricción inherente al modelo relacional
teórico -CODD (1970)- de que en una tabla no existan dos filas iguales, ya que es opcional la definición de
clave primaria, debido a motivos de compatibilidad con versiones anteriores; esta característica es causa
de numerosas críticas [véase, por ejemplo, CODD (1990)].
Por otro lado, el SQL92 sí soporta la regla de integridad de entidad, ya que se asume la definición NOT
NULL para las columnas que forman parte de la clave primaria. En cuanto a la integridad referencial, el
SQL92 permite definir claves ajenas, especificando, ya sea a nivel de columna o de tabla, la siguiente
restricción:
<definición de restricción referencial> ::=

FOREIGN KEY <parent.izq.> <columnas que ref.> <parent.dcho.>
REFERENCES <columnas y tabla referenciadas>
[ MATCH <tipo de correspondencia>
[ <acción referencial disparada>
donde
<columnas y tabla referenciadas> ::=
<nombre de tabla> [ <parent.izq.> <lista de columnas de
referencia> <parent. dcho.> ]
Es importante destacar que si se especifica sólo el nombre de la tabla referenciada, las columnas
referenciadas serán aquellas que componen la clave primaria de dicha tabla -que en este caso tiene,
obligatoriamente, que tener definida una clave primaria-. Pero es interesante observar que el SQL92
permite referenciar una columna o grupo de columnas, sin que sean necesariamente la clave primaria, y
sólo se exige que estén definidas como UNIQUE. De esta forma se pueden definir dependencias de
inclusión más amplias que las recogidas por la integridad referencial, tal como la propone Codd al
presentar el modelo relacional.
La cláusula MATCH permite precisar si se admiten valores nulos en la clave ajena cuando ya existen otros
valores no nulos en dicha clave.
Por lo que respecta a la acción a tomar en caso de borrado o modificación de los valores de las columnas
referenciadas, el SQL92 admite cuatro posibilidades: operación restringida (en caso de no especificar la
acción referencial disparada o poner NOACTION), operación con transmisión en cascada (CASCADE),
operación con puesta a nulos (SET NULL), operación con puesta a valor por defecto (SET DEFAULT), tal
como se indica a continuación:
<acción referencial disparada> ::=

<regla de modificación> [ <regla de borrado> ]
| <regla de borrado> [ <regla de modificación> ]
<regla de modificación> ::= ON UPDATE <acción referencial>
<regla de borrado> ::= ON DELETE <acción referencial>
<acción referencial>
CASCADE
| SET NULL
| SET DEFAULT
| NO ACTION
de bases de datos.
20
En la siguiente tabla, Documento, se ha definido, además de la clave primaria compuesta (Tipo,

Cod_Doc), una clave alternativa (ISBN), dos restricciones de integridad (la de columna sobre año, y la de
tabla, que afecta a los atributos Tipo, ISBN y Nombre_E2) y una clave ajena que referencia a la tabla
Editorial:
CREATE TABLE Documento

(Tipo Tipos_Doc, Cod_Doc CHAR(4), Titulo CHAR(25) NOT NULL, Idioma Idiomas,
Nombre_E Nombres, Año INTEGER(4) CHECK (Año > 1950),
Isbn INTEGER(10), PRIMARY KEY (Tipo, Cod_Doc),
UNIQUE (Isbn),CHECK ((Tipo = ‘A’ AND Isbn IS NULL AND
Nombre_E IS NULL) OR
( Tipo = ‘L’ AND Isbn IS NOT NULL AND Nombre_E IS NOT NULL)),
FOREIGN KEY (Nombre_E) REFERENCES TO Editorial
ON UPDATE CASCADE
ON DELETE NO ACTION));
Otra posibilidad para definir restricciones que afecten a varias tablas la constituyen las aserciones:
<definición de aserción> ::=

CREATE ASSERTION <nombre de restricción>
<verificación de aserción> [<atributos de restricción>]
<verificación de aserción> ::=
CHECK <parent. izq.> <condición> <parent. dcho.>
Por ejemplo, si suponemos que no puede haber editoriales cuya sede se encuentre en Madrid que editen
libros en francés o en alemán, deberíamos construir la siguiente aserción:
CREATE ASSERTION Idiomas_No_Usados_Por_Editoriales_En_Madrid

CHECK (NOT EXISTS (SELECT * FROM Documento NATURAL JOIN Editorial
WHERE Idioma IN ('F', 'A') AND Ciudad = 'Madrid'));
3.2.2.1.4 Actualización de esquem as

La actualización de esquemas se lleva a cabo mediante las sentencias ALTER (que permiten la
modificación de dominios o de tablas) y las sentencias DROP (para borrar esquemas, tablas, dominios o
vistas). Algunos ejemplos de sentencias de este estilo son:
DROP SCHEMA biblioteca;
que borraría todo el esquema (y sus elementos).
DROP DOMAIN Tipos_Doc;
que elimina el dominio.
ALTER DOMAIN Tipos_Doc

DROP CONSTRAINT Articulos_o_Libros
que permite eliminar una restricción del dominio (lo que también es aplicable a tablas).
DROP TABLE Editorial;
que eliminaría la tabla del esquema (evidentemente, junto con todas las filas que tuviera).
ALTER TABLE EDITORIAL
ADD COLUMN Director VARCHAR (30);
que añadiría una columna a la tabla Editorial que permite especificar quién es su director.
ALTER TABLE Editorial
ALTER COLUMN Ciudad SET DEFAULT 'Madrid';
que fija un valor por defecto para la columna Ciudad.
ALTER TABLE Editorial
DROP COLUMN Dir;
que borra la columna Dir.
de bases de datos.
21
3.2.2.1.5 Vistas
Como ya hemos señalado, una vista consta de una expresión de consulta sobre otras vistas y/o tablas:
<definición de vista>::=
CREATE VIEW <nombre de tabla> [<parent. izq.>
<lista de columna> <parent. dcho.>]
AS <expresión de consulta>
[WITH CHECK OPTION]
Así podríamos definir sobre la tabla Documento una vista que sólo contuviese los libros de la siguiente
manera:
CREATE VIEW Libro

AS SELECT *
FROM Documento
WHERE Tipo = ‘L’;
La cláusula WITH CHECK OPTION permite controlar que sólo se admiten operaciones de inserción y
modificación que no atenten contra la expresión de consulta que define la vista. Así, por ejemplo, si en el
caso anterior hubiésemos utilizado esta cláusula, no se permitiría cambiar el valor del atributo tipo. Otro
aspecto a tener en cuenta es que, en la actualidad, sólo son actualizables las vistas que proceden de una
única tabla (en cuya definición no aparezcan las cláusulas GROUP BY o HAVING).
3.2.3. DML Manipulación de los datos
Existen tres maneras de manipular bases de datos SQL:
o Interactivamente, esto es, invocando directamente las sentencias SQL.

o Por medio de SQL embebido, en el que se insertan sentencias SQL como huéspedes de un
lenguaje anfitrión.
o Por módulos, agrupando sentencias SQL en módulos, que son llamados desde lenguajes
anfitriones. ANSI denomina esta forma de manipulación como llamadas explícitas a
procedimientos.
En este apartado presentaremos las principales sentencias de manipulación que permiten actuar de forma
interactiva, mientras que en el siguiente resumiremos las características del SQL embebido. En cuanto a la
aproximación por módulos, que se proponía ya en el estándar de 1986, no ha tenido mucha repercusión
en el mercado, siendo muy pocos los fabricantes que la soportan.
3.2.3.1 Recuperación de datos: Sentencia SELECT
3.2.3.1.1 PARTES BÁSI CAS
Para llevar a cabo consultas sobre una base de datos relacional, el lenguaje SQL propone la sentencia
SELECT, que consta de las siguientes cláusulas:
<especificación de consulta>::=
SELECT [<cuantificador de conjunto>] <lista de selección>
<expresión de tabla>
El cuantificador de conjunto permite determinar si en el resultado de la consulta se mantienen filas

repetidas (la opción por defecto, ALL) o si se eliminan los duplicados (DISTINCT):
<cuantificador de conjunto>::=DISTINCT | ALL
En cuanto a la lista de selección:
<lista de selección> ::=

<asterisco>
|<sublista de selección> [ {<coma> <sublista de selección>} ...]
<sublista de selección> ::=
<columna derivada>
de bases de datos.
22
| <calificador><punto><asterisco>
<columna derivada> ::=
<expresión de valor> [<cláusula as>]
<cláusula as> ::= [AS]<nombre de columna>
Una expresión de valor en SQL se refiere a expresiones de valor numéricas, de tira de caracteres, de
fecha/tiempo o de intervalo. En todas ellas se pueden combinar referencias a columnas con distintos
operadores y funciones que ofrece el lenguaje. Se pueden seleccionar, por tanto, todas las columnas
(mediante el asterisco) o alguna de ellas, o bien derivar nuevas columnas a partir de las existentes
aplicando diversas funciones u operadores (por ejemplo, sumando el valor de dos columnas).
Por otra parte, las cláusulas fundamentales de la sentencia SELECT se encuentran en la expresión de
tabla:
<expresión de tabla> ::=

<cláusula from>
[<cláusula where>]
[<cláusula group by>]
[<cláusula having>1
la primera permite especificar de dónde se obtienen los datos:
<cláusula from> ::=

FROM <referencia de tabla>
[{<coma><referencia de tabla>}...]
<referencia de tabla> ::=
<nombre de tabla> [ [AS] <nombre de correlación>
[<parent.izq.> <lista de columnas derivadas>
<parent.dcho.>]]
| <tabla derivada> [AS] <nombre de correlación>
[<parent.izq.> <lista de columnas derivadas> <parent.dcho.>]]
| <tabla combinada>
Así, en el caso más sencillo podríamos recuperar todas las filas de la tabla Documento con la siguiente
sentencia:
SELECT * FROM Documento;
El caso de una tabla derivada se trata de una subconsulta, que puede ser:
<subconsulta> ::=
<parent.izq.><expresión de consulta><parent. dcho.>
<expresión de consulta> ::=
<expresión de consulta de no combinación>
| <expresión de consulta de combinación>
Las consultas que no son combinaciones de tablas incluyen, además de tablas simples, la unión (UNION),
intersección (INTERSECT) y diferencia (EXCEPT) de tablas. Así, por ejemplo, podríamos consultar por
aquellas editoriales que no son librerías mediante la sentencia siguiente:
SELECT * FROM Editorial

EXCEPT SELECT FROM Librería;
Como indicamos en el capítulo anterior, este tipo de operaciones requiere que las tablas sean compatibles
en dominio. En caso de que sólo algunas columnas de las tablas coincidan en dominio, se puede aplicar
una:
<especificación de correspondencia> ::=

CORRESPONDING [BY <parent.izq.><lista de columnas de
correspondencia><parent.dcho.> ]
En caso de tener una tabla Proyectos se podría unir con la tabla documento mediante la siguiente
sentencia:
SELECT *
de bases de datos.
23
FROM Proyecto
UNION CORRESPONDING (titulo, idioma, año)
SELECT *
FROM Documento;
3.2.3.1.2 COM BI N ACI ÓN DE TABLAS
Por lo que respecta a la combinación de tablas, el lenguaje SQL permite todas las opciones que hemos
discutido en el capítulo anterior; así, se define:
<tabla combinada> ::=

<combinación cruzada>
| <combinación calificada>
| <parent. izq.><tabla combinada><parent. dcho.>
donde
<combinación cruzada> ::=

<referencia a tabla> CROSS JOIN <referencia a tabla>
que corresponde al producto cartesiano.
SELECT * FROM Documento CROSS JOIN Editorial;
lo que sería equivalente a realizar (como en el SQL-89) la siguiente consulta:
SELECT Documento.*, Editorial.* FROM Documento, Editorial;
Otro tipo de combinación es la siguiente:
<combinación calificada> ::=

<referencia a tabla> [NATURAL] [<tipo de combinación>] JOIN
<referencia a tabla> [<especificación de combinación>]
Donde
<tipo de combinación> ::=

INNER
| <tipo de combinación externa> [OUTER]
| UNION
<tipo de combinación externa> ::=
LEFT
| RIGHT
| FULL
<especificación de combinación> ::=
<condición de combinación
| <combinación de columnas nominadas>
<condición de combinación> ::=
ON <condición de búsqueda>
<combinación de columnas nominadas>::=
USING <parent.izq.><lista de columnas de combinación>
<parent.dcho.>
Así, por ejemplo, podemos realizar la combinación natural de las tablas Documento y Editorial de la
siguiente manera:
SELECT *
FROM Documento NATURAL JOIN Editorial
ON Documento.Nombre_E = Editorial. Nombre;
de bases de datos.
24
Cabe destacar que si las dos columnas que representan nombre de editorial (Documento.Nombre_E y
Editorial.Nombre) se llamaran igual, podríamos haber usado la siguiente sentencia:
SELECT * FROM Documento NATURAL JOIN Editorial;
Cuando se emplea NATURAL JOIN sin la cláusula ON, se combinan las tablas igualando todas las columnas
que tienen el mismo nombre en las tablas; si sólo se quiere utilizar algunas de ellas se emplea la cláusula
USING.
3.2.3.2 SOL EMBEBIDO

Como ya hemos señalado, el lenguaje SQL permite actuar tanto como lenguaje interactivo como lenguaje
embebido, por lo que se dice que tiene la propiedad dual.
Las sentencias SQL se van intercalando con las sentencias del lenguaje anfitrión, precedidas normalmente
de la partícula EXEC SQL para que puedan ser distinguidas por los precompiladores. La declaración de
variables se introduce en una sección que empieza con la sentencia EXEC SQL BEGIN DECLARE SECTION
y finaliza con otra sentencia EXEC SQL END DECLARE SECTION.
Las sentencias de manipulación, como se observa en la figura, sufren algunas variaciones, ya que pueden
referenciar a variables anfitrión, como podría ser el caso de:
EXEC SQL SELECT Año

INTO :Año
FROM Documento
WHERE Isim = :Isbn;
que rellenaría la variable :Año con el valor del año que figure en la base de datos para el documento cuyo
ISBN fuera igual al de la variable anfitrión.
Las variables anfitrión deben tener un tipo adecuado al de la base de datos, y en el estándar se definen
las correspondencias para distintos lenguajes. También se introduce la función CAST que permite la
conversión explícita de tipos de datos, facilitando la correspondencia entre los tipos del lenguaje SQL y los
de lenguajes de programación en los que el SQL pueda actuar de forma huésped.
También es importante destacar que las sentencias SQL deberían ser seguidas por una comprobación de
que han devuelto un valor correcto, para lo que se puede utilizar la variable SQLCODE, que se introdujo
en el SQL de 1986 y puede tomar los valores siguientes:
• 0 si la operación ha tenido éxito

• 100 si no devuelve datos,
• un valor negativo para indicar que se ha producido algún error.
Sin embargo, como podemos observar, esta variable no es demasiado precisa en la indicación de los
errores, lo que ha llevado a que cada fabricante defina sus propios códigos de error adicionales, lo que
dificulta enormemente la portabilidad de las aplicaciones. En el SQL-92 se define un nuevo parámetro
denominado SQLSTATE que consta de 5 caracteres -los dos primeros indican la clase de error y los 3
últimos la subclase-, existiendo una tabla de códigos que contemplan los distintos tipos de errores que
pueden producirse. También se facilita una nueva sentencia GET DIAGNOSTICS que permite a las
aplicaciones recuperar información adicional sobre los errores.
También es importante contemplar el tratamiento de excepciones, lo que se lleva a cabo mediante la

sentencia WHENEVER:
<declaración de excepciones embebida> ::=

WHENEVER <condición> <acción>
donde
<condición> ::=
SQLERROR
| NOT FOUND
<acción> ::=
CONTINUE
| GOTO <objetivo>
de bases de datos.
25
donde el objetivo es la etiqueta (o un entero) desde donde se reanuda el programa.
Por otro lado, hay que tener en cuenta que si bien hay sentencias SQL que implican una sola fila (por
ejemplo, una selección por la clave primaria o una inserción), la mayor parte de las sentencias SQL
manejará un conjunto de filas, mientras que el lenguaje anfitrión sólo podrá manejarlas de una en una.
Para resolver esta discordancia (denominada impedance mismatch), el SQL soporta el mecanism de
cursores, ofreciendo mandatos para declararlos (DECLARE CURSOR FOR), abrirlos (OPEN), cerrarlos
(CLOSE) y leer los (FETCH).
Por motivos de espacio no podemos analizar todas estas sentencias, a modo de ejemplo presentamos la
definición de un cursor, que se lleva a cabo utilizando la sentencia:
<declaración de cursor>::=
DECLARE <nombre del cursor> [INSENSITIVE][SCROLL] CURSOR
FOR <sentencia>
Por ejemplo, si quisiéramos declarar un cursor para recorrer la tabla Editorial:
DECLARE cursor_e CURSOR FOR

SELECT Código, Nombre, Dir, Ciudad
FROM Editorial
ORDER BY Ciudad DESC;
La cláusula ORDER BY (que también puede utilizarse en el SQL interactivo) permite ordenar los valores
ascendentemente (por defecto) o descendentemente.
Si el cursor se declara insensible (INSENSITIVE) no podrá ver los efectos de otras sentencias en la misma
transacción mientras permanezca abierto, en caso contrario no queda determinado cuál sería el efecto. Se
introducen también cursores de desplazamiento (scroll cursors), que permiten realizar un FETCH de
diversas formas: NEXT, PRIOR, FIRST, LAST, ABSOLUTE n o RELATIVE n, siendo “n” el resultado de
evaluar una expresión escalar.
3.2.3.3 SQL DINÁMICO
Otro avance del SQL92 lo constituye la posibilidad de utilizar sentencias SQL dinámicas, esto es, de
ejecutar sentencias SQL cuyo contenido se conoce sólo en tiempo de ejecución, como por ejemplo:
SELECT Nombre, Dirección

FROM Editorial
WHERE Ciudad = ?;
donde mediante el símbolo “?” se indica el parámetro que habrá de pasarse a la sentencia durante su
ejecución.
Esta opción resulta muy útil cuando no se conocen todos los elementos de una sentencia SQL en el
momento de escribirla, por ejemplo, cuando el usuario va a introducir algunos datos, o en caso de que se
esté utilizando alguna facilidad de usuario (hoja de cálculo) que genera sentencias SQL.
3.2.3.4 SENTENCIAS DE CONTROL: SEGURIDAD EN SQL
3.2.3.4.1 Confidencialidad
En el modelo de confidencialidad del SQL el creador de un objeto es siempre el propietario del mismo, y
tiene todos los privilegios sobre el objeto (salvo que sea una vista, en cuyo caso se limitan los privilegios
sobre la vista a los que tenía sobre las tablas subyacentes). A la hora de crear un esquema SQL se puede
asignar un identificador de autorización por medio de la cláusula de nombre del esquema. Para conceder
privilegios se emplea la:
<sentencia de concesión>::=
GRANT <privilegios> ON <nombre de objeto>
TO <concedido> [<coma><concedido> ... ]
[WITH GRANT OPTION]
de bases de datos.
26
en la que
<privilegios>::-
ALL PRIVILEGES
| <lista de acción>
los privilegios pueden ser para consultar o actualizar (borrar, insertar y modificar) tablas, así como para
referenciarlas (utilizado en restricciones como la integridad referencial), o para "usar" dominios (Domain),
conjuntos de caracteres (Character-Set), ordenaciones (Collation) y traducciones (Translation). Por lo que:
<lista de acción>::=
SELECT
| DELETE
| INSERT [<parent. izq.><lista de columnas><parent. dcho.>]
| UPDATE [<parent. izq.><lista de columnas><parent. dcho.>]
| REFERENCES [<parent. izq.><lista de columnas><parent. dcho.>]
| USAGE
Un ejemplo de esta sentencia sería la concesión del privilegio de borrar filas de la tabla Empleados al
usuario Juan:
GRANT DELETE
ON Empleados
TO Juan;
En lugar de conceder privilegios a determinados identificadores de usuario, se pueden conceder privilegios

a todos mediante la utilización de 'TUBLIC".Como podemos observar en la definición de la sentencia de
concesión, se puede conceder también la posibilidad de conceder privilegios (WITH GRANT OPTION).
Por otra parte, para revocar privilegios se emplea:
<sentencia de revocación> ::=

REVOKE [GRANT OPTION FOR]
<privilegios>
ON <nombre de objeto>
FROM <concedido> [{<coma><concedido> ... }]<comportamiento de
borrado>
<comportamiento de borrado> ::=
CASCADE
| RESTRICT
en la que si usamos el comportamiento restringido (RESTRICT) no dejará revocar privilegios que hayan
sido concedidos a otros usuarios, mientras que si empleamos la
opción en cascada, se borrarán todos los privilegios. Un ejemplo de sentencia de revocación sería:
REVOKE INSERT, UPDATE (Salario)

ON Empleado FROM Ana, Pedro CASCADE;
Hay que tener cuidado, ya que a pesar de revocar los privilegios a un usuario, éste puede mantenerlos a
través de otro usuario (que les haya concedido los mismos privilegios).
Por otro lado, cualquier borrado de un objeto (tabla, dominio, vista, etc.) causa, como es lógico, la
revocación de todos los privilegios sobre el objeto a todos los usuarios.
Otro mecanismo que representa un papel muy importante en la confidencialidad del SQL lo constituyen las
vistas, que permiten ocultar información a los usuarios; y, así, conceder privilegios sólo sobre
subconjuntos de las tablas.
3.2.3.5 Disponibilidad
El SQL soporta las transacciones clásicas mediante las sentencias COMMIT y ROLLBACK. Las transacciones
se inician al empezar los programas, o bien al ejecutar sentencias de definición o manipulación.
En el próximo apartado examinaremos algunas características de las transacciones, que afectan más a la
integridad (control de concurrencia) que a la disponibilidad.
de bases de datos.
27
3.2.3.6 Integridad
3.2.3.6.1 SEM ÁN TI CA
Además de la clave primaria, unicidad, no nulos e integridad referencial, las restricciones de verificación
(CHECK), los dominios9 (CREATE DOMAIN) y las aserciones (CREATE ASSERTION); sentencias que se
incluyen en la definición de los elementos del esquema.
Las restricciones en SQL 92 presentan otra característica que afecta en gran medida a la integridad
semántica: la posibilidad de ser diferidas, esto es, de verificarse al final de la transacción en lugar de
hacerlo después de la ejecución de cada sentencia de manipulación, como hemos visto para el caso de la
integridad referencial. Si la transacción se ha definido como diferible se puede cambiar dinámicamente el
momento de su comprobación mediante la sentencia:
SET CONSTRAINTS <lista de nombres de restricciones> {DEFERRED

INMEDIATE}
<lista de restricciones> ::=
ALL <nombre de restricción> [{<coma> <nombre de restricción>}... ]
Esto permite definir restricciones que los anteriores estándares no soportaban. Por
ejemplo, si se definen dos tablas Empleados y Departamentos, como las siguientes:
Departamentos (N_DEPT, LOCALIDAD, ..., JEFE)

Empleados (CODEMP, NOMBRE, ..., N_DEPT)
en las que JEFE es una clave ajena que referencia a Empleados y se define como no nula, y N_DEPT es
una clave ajena que referencia a Departamentos y también se considera no nula. Supongamos que se
quiere insertar un nuevo departamento con su jefe correspondiente en un SGBDR con SQL-89. Si se
intenta introducir el nuevo departamento, el sistema no lo permitirá al no existir el empleado (que es el
jefe) al que referencia; lo mismo sucederá si se quiere ontroducir en primer lugar el jefe, ya que no existe
el departamento correspondiente. Este problema (la “pescadilla que se muerde la cola”) se resuelve
definiendo las restricciones como diferidas, e incluyendo las dos inserciones dentro de una misma
transacción; ya que se comprobará la consistencia al final de la transacción permitiéndose ambas
inserciones, ya que son (en conjunto) semánticamente consistentes. Sin embargo, como señala DATE
(1992c), la posibilidad de desactivar dinámicamente las restricciones, limita seriamente el potencial de
optimización semántica.
6.3.2. OPERACIONAL
El estándar SQL no proporciona, a diferencia de los productos relacionales, ninguna sentencia para
bloquear datos, sino que deja este aspecto a los implementadores (se podría implementar incluso un
sistema que soportara completamente el SQL 92 y que utilizara un mecanismo diferente al de los
bloqueos).
Los cuatro niveles de aislamiento son:

• lectura sin grabar
• lectura grabada
• lectura repetible
• serializable
siendo la opción por defecto esta última (en la que se obliga a la serialidad de las transacciones). Estos
niveles de aislamiento se definen en base a tres problemas de concurrencia:
• Lectura "sucia": consiste en que una transacción lleva a cabo una actualización sobre un dato, que es
leído entonces por otra transacción. Si la primera transacción se deshace, la segunda ha leído un valor que
nunca debería haber existido.
• Lectura no reproducible: una transacción que quiere leer un dato dos veces se encuentra con que
ese dato varía (si en medio de las dos lecturas otra transacción ha actualizado ese dato), sin que en la
primera transacción se hubiera realizado ninguna actualización.
• Lectura "fantasma": si una transacción recupera todos los datos que satisfacen una condición y
después otra transacción incorpora nuevos datos que satisfacen dicha condición, si la primera transacción
repite su consulta aparecen nuevos datos ('Tantasinas").
de bases de datos.
28
Hay que advertir, sin embargo, de acuerdo con BERENSON et al. (1995), que los problemas que define el
estándar son ambiguos e incompletos, pudiendo dar lugar a muchas anomalías. Estos expertos proponen
que se considere obligatorio para todos los niveles evitar el fenómeno de:
Escritura "sucia": si una transacción modifica un dato y otra transacción modifica también ese mismo dato
antes de que la primera se grabe o deshaga, si cualquiera de las dos se deshace no queda claro cuál es el
valor correcto.
Se pueden mejorar los niveles de aislamiento del estándar (introduciendo, por ejemplo, el nivel de
estabilidad para cursores, que extiende el de lectura grabada para cursores SQL) en función de otros
fenómenos como el de actualización perdida.
Mediante la sentencia:
<sentencia para determinar transacciones> ::=

SET TRANSACTION <modo de transacción> [ {<coma><modo de
transacción>} ...
<modo de transacción> ::=
<nivel de aislamiento>
| <modo de acceso de la transacción>
| <tamaño del área de diagnóstico>
<nivel de aislamiento> ::=
ISOLATION LEVEL <nivel>
<nivel> ::=
READ UNCOMMITTED
| READ COMMITTED
| REPEATABLE READ
| SERIALIZABLE
<modo de acceso de la transacción> ::=
READ ONLY
| READ WRITE
<tamaño del área de diagnóstico> ::=
DIAGNOSTICS SIZE <especificación de valor simple>
los administradores pueden fijar, como podemos observar, las características de las transacciones. Por
defecto, éstas puede ejecutar tanto operaciones de lectura como de escritura, se aíslan lo más posible de
otras (nivel serializable) y utilizan un área de diagnóstico de un tamaño por defecto. El tamaño de esta
área indica el número de condiciones que se almacena para cada sentencia SQL que se ejecuta.
Un ejemplo de esta sentencia sería:
SET TRANSACTION
READ ONLY
ISOLATION LEVEL READ UNCOMMITTED
DIAGNOSTICS SIZE 4;
3.3. Traducción del M odelo conceptual al físico
3.3.1. Obtención del Modelo Conceptual de Datos mediante la técnica del Modelo E/R
Extendido
El Modelo Conceptual permite establecer una visión global de los datos de una organización o de un
sistema de información en un nivel de abstracción próximo al usuario pero aislando la representación de la
información de los requerimientos de las exigencias de cada usuario particular e independiente de las
características del equipos donde después se vaya a instrumentar el sistema, es único para cada SI y se
representará mediante el Modelo E/R de Chen.
de bases de datos.
29
3.3.2. Transformación del Modelo Conceptual a un Modelo Lógico Relacional Normalizado. Para
su representación se utilizará la notación del Diagrama de Estructura de Datos.
En el diseño lógico, se transforma el esquema conceptual en un esquema lógico que utilizará las
estructuras de datos del modelo de base de datos en el que se basa el SGBD que se vaya a utilizar, como
puede ser el modelo relacional, el modelo de red, el modelo jerárquico o el modelo orientado a objetos.
El diseño lógico depende del tipo de SGBD que se vaya a utilizar, no depende del producto concreto.
Se obtendrá mediante una transformación del esquema conceptual aplicando las reglas y convenciones
propias del modelo lógico convencional que estemos considerando (Jerárquico, Relacional o en Red). El
esquema lógico corresponderá al nivel lógico global o externo de A.N.S.I. dando lugar a los esquemas
externos que fueran necesarios en función de las vistas parciales de la base de datos que se muestren a
los usuarios.
Tanto el diseño conceptual, como el diseño lógico, son procesos iterativos, tienen un punto de inicio y se
van refinando continuamente. Ambos se deben ver como un proceso de aprendizaje en el que el
diseñador va comprendiendo el funcionamiento de la empresa y el significado de los datos que maneja. El
diseño conceptual y el diseño lógico son etapas clave para conseguir un sistema que funcione
correctamente. Si el esquema no es una representación fiel de la empresa, será difícil, sino imposible,
definir todas las vistas de usuario (esquemas externos), o mantener la integridad de la base de datos.
También puede ser difícil definir la implementación física o el mantener unas prestaciones aceptables del
sistema. Además, hay que tener en cuenta que la capacidad de ajustarse a futuros cambios es un sello
que identifica a los buenos diseños de bases de datos. Por todo esto, es fundamental dedicar el tiempo y
las energías necesarias para producir el mejor esquema que sea posible.
Reglas de transformación del Modelo Conceptual al Modelo Relacional
- Toda entidad representada en el Modelo E/R se convierte en una tabla o relación que toma el nombre
de la entidad. Los atributos de la entidad son las columnas de la tabla y el atributo identificador
principal es la clave primaria. Cada uno de los identificadores de la entidad será una clave candidata.
De entre las claves candidatas hay que escoger la clave primaria; el resto serán claves alternativas.
Para escoger la clave primaria entre las claves candidatas se pueden seguir estas indicaciones:
• Escoger la clave candidata que tenga menos atributos.
• Escoger la clave candidata cuyos valores no tengan probabilidad de cambiar en el futuro.
• Escoger la clave candidata cuyos valores no tengan probabilidad de perder la unicidad
en el futuro.
• Escoger la clave candidata con el mínimo número de caracteres (si es de tipo texto).
Clave candidata: conjunto no vacío de atributos que identifica univoca y mínimamente a cada
tupla de una tabla. Clave primaria: clave candidata que elige el usuario
- Entidades débiles. Crear una relación para cada entidad débil incluyendo todos sus atributos
simples. De los atributos compuestos incluir sólo sus componentes. Para ello, se incluye la clave
primaria de la relación que representa a la entidad padre en la nueva relación creada para la
entidad débil. A continuación, determinar la clave primaria de la nueva relación. Ejemplo:
1:1
TIENE
DISCOS PELÍCULAS
Es-un
BANDA SONORA
de bases de datos.
30
- Eliminar las relaciones de muchos a muchos, sustituyendo cada una de ellas por una nueva entidad
intermedia y dos relaciones de uno a muchos de esta nueva entidad con las entidades originales. La
nueva entidad será débil, ya que sus ocurrencias dependen de la existencia de ocurrencias en las
entidades originales. Las interrelaciones M.N del Modelo E/R se transforman en una tabla cuya clave
primaria estará compuesta por las claves de las entidades que asocia.
DISCOS
N:N
CANTAN
INTÉRPRETES
- Eliminar las relaciones entre tres o más entidades, sustituyendo cada una de ellas por una nueva
entidad (débil) intermedia que se relaciona con cada una de las entidades originales. La cardinalidad
(nº de ocurrencias de una relación) de estas nuevas relaciones binarias dependerá de su
significado.
- Eliminar las relaciones con atributos, sustituyendo cada una de ellas por una nueva entidad (débil) y
las relaciones binarias correspondientes de esta nueva entidad con las entidades originales. La
cardinalidad de estas relaciones dependerá del tipo de la relación original y de su significado.
Nº EJEMPLARES DISCOS
PEDIDOS
N:N
CONTIENE
- Eliminar los atributos multievaluados, sustituyendo cada uno de ellos por una nueva entidad (débil)
y una relación binaria de uno a muchos con la entidad original.
El tratamiento que reciben los atributos multievaluados (no contemplados en la técnica del
Modelo E/R descrita en Métrica v.3) es consecuencia directa de las restricciones inherentes al
Modelo Relacional, que forman parte integral de la estructura del modelo (la tabla es plana, en el
cruce de un atributo con una tupla, o lo que es lo mismo, en el de una columna con una fila, sólo
puede haber un valor que además debe estar dentro de la columna correspondiente). Las ciudades
donde se rueda una película podría ser un atributo multievaluado.
de bases de datos.
31
- Eliminar las relaciones redundantes. Una relación es redundante cuando se puede obtener la misma
información que ella aporta mediante otras relaciones. El hecho de que haya dos caminos diferentes
entre dos entidades no implica que uno de los caminos corresponda a una relación redundante, eso
dependerá del significado de cada relación.
- Relaciones binarias de uno a uno: se transforman propagando la clave y los demás atributos en uno
de los dos sentidos. El identificador de la entidad con mayor cardinalidad mínima pasa a ser atributo
de la otra. Otra posibilidad para transformar las interrelaciones 1:1 consiste en crear una nueva
tabla que recoja los identificadores de las entidades participantes más los propios de la relación si
las tuviera. Esta solución se adopta cuando ambas entidades participan por igual en la interrelación
Un empleado dirige 0:1 proyectos y un 1 proyecto es dirigido por 1:1 empleados. Se pasa DNI del
empleado a la tabla de proyectos.
- Relaciones binarias de uno a muchos: las interrelaciones 1:N del Modelo E/R se transforman
propagando el atributo identificador principal de la entidad que tiene cardinalidad máxima1 (entidad
maestra) a la que tienen cardinalidad máxima N (entidad de detalle). El atributo propagado es una
clave ajena que referencia a la tabla con cardinalidad máxima 1. Si la participación de una entidad
es 0:1 entonces se crea una nueva tabla que recoge los identificadores de ambas entidades
participantes más los propios de la relación si los tuviera.
Un empleado utiliza 1:N vehículos y un vehículo es utilizado por 0:1 empleados. Atributo de la relación
“utiliza”: fecha. Se crea una tabla intermedia (entidad débil) con campos: DNI, MATRÍCULA Y FECHA.
Transformación de la herencia
A) Consiste en crear una tabla para el supertipo que tenga de clave primaria el identificador y una tabla
para cada uno de los subtipo que tenga el identificador del supertipo como clave ajena. Esta solución es
apropiada cuando los subtipos tienen muchos atributos distintos y se quieren conservar los atributos
comunes en una tabla. También se deben implantar las restricciones y aserciones adecuadas. Es la
solución que mejor conserva la semántica.
B)Se crea una tabla para cada subtipo, los atributos de comunes aparecen en todos los subtipos y la
clave primaria para cada tabla es el identificador del supertipo.
Esta opción mejora la eficiencia en los accesos a todos los atributos de un subtipo, sean los comunes al
supertipo o los específicos.
C) Agrupar en una tabla todos los atributos de la entidad supertipo y de los subtipos. La clave primaria
de esta tabla es el identificador d e la entidad. Se añade el atributo que indique a qué subtipo pertenece
cada ocurrencia (el atributo discriminante de la jerarquía). Esta solución puede aplicarse cuando los
subtipos se diferencian en pocos atributos y las relaciones entre los subtipos y otras entidades sean las
mismas. Para el caso de que la jerarquía sea total, el atributo discriminante no podrá tomar valor nulo
(ya que toda ocurrencia pertenece a alguna de las entidades subtipo)
3.3.2.1 Obtención del Modelo Físico
El diseño físico parte del esquema lógico y da como resultado un esquema físico. Un esquema físico es
una descripción de la implementación de una base de datos en memoria secundaria: las estructuras de
almacenamiento y los métodos utilizados para tener un acceso eficiente a los datos. Por ello, el diseño
físico depende del SGBD concreto y el esquema físico se expresa mediante su lenguaje de definición de
datos. Para llevar a cabo esta etapa, se debe haber decidido cuál es el SGBD que se va a utilizar, ya que el
esquema físico se adapta a él. Entre el diseño físico y el diseño lógico hay una realimentación, ya que
algunas de las decisiones que se tomen durante el diseño físico para mejorar las prestaciones, pueden
afectar a la estructura del esquema lógico.
3.3.2.2 Optimización del Modelo Físico (monitorizar y afinar el sistema)
Una vez implementado el esquema físico de la base de datos, se debe poner en marcha para observar sus
prestaciones. Si éstas no son las deseadas, el esquema deberá cambiar para intentar satisfacerlas. Una
vez afinado el esquema, no permanecerá estático, ya que tendrá que ir cambiando conforme lo requieran
los nuevos requisitos de los usuarios. Los SGBD proporcionan herramientas para monitorizar el sistema
mientras está en funcionamiento.
de bases de datos.
32
3.4. SQL avanzado
El capítulo anterior se ha centrado en las sentencias de la versión SQL92, Mas tarde aparece el nuevo
estánar SQL3 , que fue adquierndo un volumen considerable y se descompone en variasp parteas para
facilitar su aprobación y su implemetanción en productos comerciales. El estándar ha quedado
estructurado en las siguientes partes:
1. Marco de referencia (SQL/Fram ew ork ), que es una descripción no técnica de cómo se

estructura el nuevo estándar.
2. Fundamentos y Facilidades de Propósito General (SQL/Foundation ), que constituye el núcleo
del estándar SQL3, incluidos los aspectos de orientación al objeto.
3. Interfaz de nivel de llamada (SQL/CLI, Call Level Interface).
4. Módulos SQL Persistentes (SQL/PSM, Persistent Storage Module)10, en los que se especifican
los procedimientos almacenados y la compleción computacional.
5. Vinculaciones a Lenguajes Anfitrión (SQL/Bindings), en las que se especifican las
vinculaciones para SQL embebido y SQL dinámico.
6. Especialización XA (SQL/Transaction), que se propone como especialización de la interfaz XA
de X/Open.
7. Temporal (SQL/Temporal), en el que se incluyen los principales aspectos del lenguaje TSQL2.
8. Objetos extendidos (SQL/Objects), que abarca los Tipos Abstractos de Datos “Objetos”.
9. Tablas virtuales (SQL/Virtual Table), que permitirá acceder a ficherosutilizando SQL.
Las características más significativas del SQL3 son las siguientes:
• Nuevos tipos de datos (booleano, “objetos grandes”...)

• Reglas activas (disparadores).
• Tipos abstractos de datos, definidos con la sentencia CREATE TYPE, que permite especificar los
atributos y operaciones que representan la estructura y el comportamiento de tipos abstractos de
datos definidos por el usuario.
• Operador de unión recursiva para expresiones de consulta.
• Cursores sensitivos, que estando abiertos permiten "ver" incluso cambios en los datos no
producidos a través de ellos.
• Jerarquía de generalización de tablas (subtablas y supertablas).
• Papeles (roles) de usuario.
Debido a obvias limitaciones de espacio sólo presentaremos dos aspectos que destacan por su interés, al
encontrarse presentes en la mayor parte de los productos relacionales: los papeles o roles y los
disparadores (triggers).
Roles en SOL3
Entre los aspectos más destacables en cuanto a la confidencialidad, se encuentra la inclusión de los
papeles o "roles" de seguridad, ya presentes en muchos productos, que se definen de la siguiente
manera:
<definición de rol> ::= CREATE ROLE <nombre de rol>
asignando los usuarios a los roles mediante la:
<sentencia de concesión de rol> ::=
GRANT <rol concedido> [ { <coma><rol concedido>
TO <concedido> [ { <coma>< concedido>
para eliminar a un usuario de un rol se utiliza la:
<sentencia de revocación de rol> ::=
REVOKE <rol concedido> [ { <coma><rol concedido>
TO <concedido> [ { <coma>< concedido>
mientras que para eliminar un rol, empleamos:
<sentencia de borrado de rol> ::=
DROP ROLE <nombre de rol>
de bases de datos.
33
Disparadores en SQL3
El lenguaje SQL3 estandariza los disparadores de la siguiente forma:
<definición disparador> ::=

[ CREATE ] TRIGGER [ <nombre disparador> ]
<tiempo acción disparador> <evento disparador> ON <nombre tabla>
[ REFERENCING <lista de alias para valores antiguos o nuevos> ]
<acción disparada> ...
donde el nombre del disparador es un nombre cualificado, y
<tiempo de acción>
AFTER
| BEFORE
| INSTEAD OF11
el evento puede ser:
<evento disparador>
INSERT
| DELETE
| UPDATE [ OF <lista columnas disparador> ]
La lista de alias para los valores antiguos y nuevos es una lista formada por:
<alias valores antiguos o nuevos> ::=

OLD [ AS ] <nombre correlación valores antiguos>
| NEW [ AS ] < nombre correlación valores nuevos>
| OLD_TABLE [ AS ] <alias de tabla de valores viejos>
| NEW_TABLE [ AS ] <alias de tabla de valores viejos>
donde los nombres de correlación son identificadores.
La acción disparada consta de:
<acción disparada>
[ FOR EACH { ROW | STATEMENT } ]
[ WHEN <p.izdo> <condición búsqueda> <p. dcho> ]
<sentencia SQL disparada>
<sentencia SQL disparada> ::=
<sentencia de procedimiento SQL>
| BEGIN ATOMIC
<sentencia de procedimiento SQL><pto y coma> ..
END
La sentencia SQL disparada es una sentencia de procedimiento SQL que puede ser de borrado (DELETE),
modificación (UPDATE) o inserción (INSERT), de control o de diagnóstico.
Por otra parte, el INFORMATION_SCHEMA del SQL3 define las siguientes vistas que describen los
disparadores:
• TRIGGERS, identifica los disparadores de un usuario.
• TRIGGERED_ACTIONS, identifica las acciones disparadas en un catálogo que posee un usuario.
• TRIGGERED_COLUMNS, por cada esquema de un usuario, identifica las vistas que
dependen de columnas que se describen en un disparador.
SQL:2003
de bases de datos.
34
SQL:2003 hace una revisión del SQL:1999(SQL3) hace mejora importantes en áreas claves:
 En las características orientadas a objetos
 En características de Bussiness Intelligent.
 En características de SQL/XML.
En concreto añade una nueva parte, es la parte Parte 14: SQL/XML (especificaciones relativas al XML). Se
reorganizan otras partes como crear una parte especifica para le Esquema de datos (parte 11) y se
elimina la parte 5 SQL/Bindings, que se une con SQL/foundacion. Incluye:
• Nuevos tipos de datos.
• Extensiones de la sentencia Create Table.
• Nuevas sentencia Merce,
• nuevo esquema de objetos
• etc
SQL:2003 contiene todos los tipos de datos qu existían en sQL:1999. a excencip de BIT y BIT VARYING.
Que se elimina por no tener soporte en los motores de la bases de datos SQL.
Se introducen nuevos tipos como: BIGINT, MULTISET y XML.
4. NORMAS Y ESTÁNDARES PARA LA INTEROPERABILIDAD ENTRE GESTORES DE BASES DE DATOS RELACIONALES
4.1. ODBC. Open Database Conectivity

ODBC es un estándar abierto que define un interfaz de programación de acceso a bases de datos.
Mediante el uso de las sentencias ODBC en un programa se pueden consultar una gran variedad de bases
de datos, incluyendo los SGDBR más conocidos del mercado, como DB2, ORACLE, SQLSERVER, INFORMEX
y SYBASE, así como a bases de datos locales, como Access, dBase, Paradox, Foxpro, incluso permite
consultas a hojas de cálculo como Lotus 1-2-3 y Excel. Además del software ODBC, se requiere de un
modulo separado o controlador específico para cada base de datos. Es Microsoft el que principalmente el
soporte de desarrollo de ODBC.
ODBC se basa en el estándar de SQL-CLI del Open Grop. Éste permite el uso de peticiones SQL para el
acceso a bases de datos sin que haga falta conocer los interfaces propietarios de acceso a los distintos
Sistemas Gestores de Bases de Datos.
ODBC recibe la petición SQL y la convierte en una petición que pueda interpretar el SGBD.
Originalmente ODBC fue desarrollado por el SQL Access Group y la primera versión data de Septiembre de
1992. Sin embargo Microsoft fue el primero en proveer un producto ODBC en el sistema operativo
Windows. También existen versiones ODBC para otras plataformas, como UNIX, OS/2 y Macintosh.
4.2. OLE-DB. Object Linking and Em bedding for Databases

OLE-DB es una tecnología desarrollada por Microsoft usada para tener acceso a diferentes fuentes de
información, bases de datos, de manera uniforme, que intenta resolver las limitaciones de ODBC en
cuanto a que éste está diseñado para programas escritos en C, y no proporciona acceso a todo tipo de
datos.
OLE DB permite separar los datos de la aplicación que los requiere. Esto se hizo así ya que diferentes
aplicaciones requieren acceso a diferentes tipos y almacenes de datos, y no necesariamente desean
conocer cómo tener acceso a cierta funcionalidad con métodos de tecnologías específicas. OLE DB está
conceptualmente dividido en consumidores y proveedores; el consumidor es la aplicación que requiere
acceso a los datos y el proveedor es el componente de software que expone una interfaz OLE DB a través
del uso del Component Object Model (COM).
de bases de datos.
35
4.2.1.1 Comparación OLE-DB – ODBC
Atributo ODBC OLE-DB
Interfase de programación API a nivel C API basada en COM
Formato de datos Datos basados en SQL Todos los datos tabulados
Método de consulta Estándar basado en SQL Estándar basado en COM
Proveedores Proveedores nativos Arquitectura de componentes
4.3. ADO. ActiveX Data Objects

ADO ActiveX Data Objects es un interfaz de programación de Microsoft para permitir el acceso a sistemas
de gestión de bases de datos relacionales y no relacionales. Internamente es un conjunto de objetos COM
para el acceso a orígenes de datos. Por medio de ADO.
Éste provee de una capa intermedia entre los lenguajes de programación y OLDE DB, que permite escribir
programas con acceso a datos, sin que sea necesario el conocimiento de cómo está la base de datos
implementada. Solo sería necesario conocer la base de datos a efectos de la conexión. Ni siquiera es
necesario conocimiento de SQL para el acceso a los datos, aunque ADO si permita la ejecución de
sentencias SQL.
Los componentes ADO se suelen utilizar en lenguajes de alto nivel como VBScript o Visual Basic. Incluso
en lenguajes como Delphi o C++ Builder, con entornos de desarrollo que compiten con los de Microsoft,
también permite el uso de ADO para el acceso a datos.
4.4. ADO.N ET
En el framework de programación .NET de Microsoft está presente una versión evolucionada de ADO
denominada ADO.NET. A pesar de la semejanza en el nombre y finalidad, su estructura de objetos es
bastante diferente a la de ADO, de hecho se podría considerar como un producto totalmente nuevo.
ADO.NET se puede dividir en dos grandes bloques:

- Data provider: que contiene las clases necesarias para acceder a un origen de datos, como una
base de datos SQLServer o Oracle.
- Data sets: que contiene las clases necesarias para poder describir una base de datos relacional
(p.e. DataTable, DataView, DataColumn, DataRow, DataRelation…)
de bases de datos.
36
4.5. JDBC Java Database Connectivity

Es un API de programación Java que permite la ejecución de sentencias SQL sobre bases de datos.
Además JDBC de igual forma que ODBC está basado en la X/Open SQL Call Level Interface.
JDBC se incluye en la Plataforma Java Estándar Edition, junto con un driver ODBC que permite conexiones
con cualquier SGBDR que soporte ODBC.
JDBC soporta cuatro tipos de drivers:

1. Tipo 1. Puente JDBC-ODBC: traduce llamadas genéricas JDBC a llamadas ODBC, proporciona
acceso a Bd a través de uno o más drivers de ODBC.
Las llamadas realizadas a la base de datos tienen que pasar por múltiples capas. Además la
funcionalidad del código JDBC está limitada a lo que pueda soportar el driver ODBC.
Puente
Puente
Driver
Driver ODBC
ODBC
JDBC-ODBC
JDBC-ODBC
Código
Código JAVA
JAVA
API
API ODBC
ODBC
Base de Datos
2. Tipo 2: Driver escrito parte en Java que hace llamadas a la API nativa del SGBDR. Al estar
escritos solo parcialmente en Java comparten los problemas de portabilidad e instalación del
puente JDBC/ODBC.
Es un driver que usa
protocolos de acceso a
datos optimizados por el
fabricante
Protocolo específico
del Proveedor
Driver
Driver
Código
Código JAVA
JAVA
JDBC
JDBC
Base de Datos Código Java y Nativo
3. Tipo 3: En realidad no es un driver, es un front-end para acceso a servidores de BD:

 El programa envía una invocación JDBC a través del ´proxy´ driver, quien lo envía a la capa
intermedia o middleware, sin traducción
 El middelware completa el requerimiento usando otro driver JDBC
 El middleware habla con la BD a través de un driver Tipo 1 o 2.
Utilizando este tipo de drivers no será necesario configurar la máquina donde corra la aplicación,
solamente el servidor.
Front-End que accede al
middleware.
Driver
Driver JDBC
JDBC Driver
Driver
Tipo
Tipo 11 óó 22 (Java
(Java puro)
puro)
Código
Código JAVA
JAVA
Servidor
Servidor de
de
Base de Datos Acceso
Acceso aa DB
DB
4. Tipo 4: Driver nativo escrito completamente en Java, específico de cada SGBD. Están escritos
totalmente en Java, y convierten todas las llamadas JDBC a llamadas nativas del gestor de base
de datos correspondiente. Java puro, el más efciente, No requiere de ninguna librería adicional
ni de la instalación de un middleware, con lo cual es de deployment más simple, La mayoría de
los fabricantes de BD proveen drivers JDBC de tipo 4 para sus BD.
de bases de datos.
37
Protocolo específico
del Proveedor DriverJDBC
Código
Código JAVA
JAVA
(Java Puro)
Base de Datos
4.6. Soluciones ORM : Object-Relational M apping

Actualmente están muy de moda soluciones de Mapeo Objeto-Relacional, que proporcionan un framework
para mapear objetos del modelo orientado a objetos a los elementos tradicionales de una base de datos
relacional. Por ejemplo, se mapeará la tabla empleados a la clase empleados, de forma que desde el
código se utilizará directamente la clase empleados. Para crear un nuevo empleado, en lugar de realizar
un INSERT en la base de datos, lo que se deberá de hacer es crear un objeto nuevo de la clase
empleados.
El objetivo de este tipo de frameworks es simplificar al desarrollador el acceso a datos, ya que trabajará
directamente con objetos, con lo que se consigue evitar al desarrollador de la realización de una gran
cantidad de tareas de programación de acceso a datos.
Dentro del mundo Java, las soluciones más populares son Hibernate e IBATIS.
5. COMPARACIÓN ENTRE SISTEMAS GESTORES DE BASES DE DATOS RELACIONALES
5.1. Bases de Datos objeto de la Com paración

Mantenedor Primera versión Última version estable Licencia
DB2 IBM 1982 9 Propietaria

SQL Server Microsoft 1989 9.00.3042 (2005 SP2) Propietaria
MySQL MySQL AB 1996 5.0.45 GPL o
propietaria
Oracle Oracle Corporation 1979 11g Release 1 (September Propietaria
2007)
PostgreSQL PostgreSQL Global 1989 8.2.5 BSD
Development Group
5.1.1. Oracle
Oracle es el sistema de gestión de bases de datos relacionados más conocido del mercado y es el principal
dominador del mercado dentro del mundo empresarial, a pesar de su alto precio.
Es considerado como uno de los sistemas de bases de datos más completos, destacando su:
• Soporte de transacciones
• Estabilidad
• Escalabilidad
• Es multiplataforma
La primera versión de Oracle, conocida como Relational Database, data de finales de 1979, y la última
versión que están comercializando es Oracle 11g de Septiembre de 2007.
Con sus distintas versiones, Oracle ha sido pionera en la introducción de nuevas tecnologías: desde la
primera base de datos en ofrecer arquitectura cliente-servidor, PL/SQL, soporte de arquitectura de 64 bits,
soporte XML, hasta capacidades Enterprise Grid Computing, etc
de bases de datos.
38
Además Oracle distribuye desde el año 2005 una versión reducida y gratuita de su SGBD orientada a
desarrolladores, distribuidores, dba’s, instituciones y estudiantes denominada Oracle XE -Express Edition-.
5.1.2. DB2
El sistema de gestión de bases de datos relacionales que comercializa IBM se conoce como DB2. Al igual
que Oracle, el origen de la misma es bastante antiguo, de hecho fue el primer gestor de bases de datos
en utilizar el lenguaje SQL. En 1983 para MVS Versión 1 nació DB2. Se utilizó este nombre para indicar el
cambio de las bases de datos jerárquicas hacia las bases de datos relacionales. El desarrollo de DB2
continúo tanto en plataforma mainframe como en plataformas distribuidas.
La última versión, DB2 versión 9, se basa un motor de base de datos relacional que integra XML de
manera nativa, lo que IBM ha llamado pureXML, que permite almacenar documentos completos dentro del
tipo de datos xml para realizar operaciones y búsquedas de manera jerárquica dentro de éste, e integrarlo
con búsquedas relacionales.
Además DB2 tiene una versión gratuita denominada Express-C, orientada a pequeñas y medianas
empresas que no necesiten de sus funcionalidades avanzadas.
5.1.3. SQLServer
SQLServer pretende ser la alternativa de Microsoft a Oracle y DB2 en el mercado de los sistemas gestores
de bases de datos relacionales. La primera versión, en comparación con sus rivales llegó casi 10 años más
tarde, en 1988, y fue una versión desarrollada para OS/2 junto a Sybase. A partir de ahí, Microsoft se
centró en su desarrollo en arquitectura NT, de la que es totalmente dependiente. Una particularidad de
este SGBDR es que utiliza una variación del lenguaje SQL denominado Transact SQL una implementación
de SQL-92 (el estándar ISO para SQL certificado en 1992) con bastantes extensiones. Proporciona sintaxis
adicional en procedimientos almacenados, y además también afecta a la sintaxis de la funcionalidad
transaccional.
La última versión, SQL Server 2005, proporciona funcionalidad para el Framework .NET, pudiéndose por
ejemplo utilizar cualquiera de los lenguajes de .NET para escribir procedimientos almacenados.
También Microsoft proporciona una versión gratuita con funcionalidad limitada de su SGBD denominada
SQL Server 2005 Express.
5.1.4. PostgreSQL
PostgreSQL es un Sistema Gestor de Base de Datos Relacional-Orientada a Objetos open-source. Se
distribuye bajo licencia BSD y su desarrollo no es manejado por una sola compañía, sino que es dirigido
por una comunidad de desarrolladores y organizaciones comerciales las cuales trabajan en su desarrollo,
denominada PGDG, PostgreSQL Global Development Group)
El origen de su desarrollo fue la realización de un nuevo proyecto en la Universidad de Berkley sobre la
experiencia del desarrollo de un Sistema Gestor de Bases de Datos Relacional denominado Ingres. El
mismo se denominó Post-Ingres o Postgres.
Después del que el proyecto terminara, dos graduados de la misma universidad Andrew Yu and Jolly
Chen, y debido a que Postgres estaba licenciado bajo licencia BSD, comenzaron a trabajar sobre su código
para añadirle soporte al lenguaje SQL, dado que antes contaba con su propio lenguaje de consultas. De
ahí nació Postgres 95, el cuál en el año 96 se pasó a denominar PostgreSQL.
Con cerca de una década de desarrollo tras ella, PostgreSQL es la base de datos de código abierto más
avanzada hoy día disponible, ofreciendo control de concurrencia multi-versión, soporta casi toda la sintaxis
SQL (incluyendo subconsultas, transacciones, y tipos y funciones definidas por el usuario), contando
también con un amplio conjunto de enlaces con lenguajes de programación (incluyendo C, C++, Java,
perl, tcl y python).
5.1.5. MySQL
MSQL es el gestor de bases de datos relacionales, probablemente, más usado en el mundo del software
libre, debido a su gran rapidez y facilidad de uso. Se distribuye bajo licencia GPL de GNU de la compañía
sueca MySQL AB, que mantiene el copyright del código fuente del servidor SQL, así como también de la
marca. Aunque MySQL es software libre, la compañía también distribuye una versión comercial de MySQL,
que no se diferencia de la versión libre más que en el soporte técnico que se ofrece, y la posibilidad de
integrar este gestor en un software propietario, ya que de no ser así, se vulneraría la licencia GPL.
de bases de datos.
39
MySQL surgió como un intento de conectar el gestor mSQL (mini SQL, cliente/servidor lígero de bases de
datos) a las tablas propias de MySQL AB, usando sus propias rutinas a bajo nivel. Tras unas primeras
pruebas, vieron que mSQL no era lo bastante flexible para lo que necesitaban, por lo que tuvieron que
desarrollar nuevas funciones. Esto resultó en una interfaz SQL a su base de datos, con una interfaz
totalmente compatible a mSQL.
5.2. Com paración
5.2.1. Disponible en qué Sistema Operativo

Wind Mac OS Linux BSD UNIX z/OS 1
ows X
DB2 Si No Si No Si Si
SQL Server Si No No No No No
MySQL Si Si Si Si Si Quizás
Oracle Si Si Si No Si Si
PostgreSQL Si Si Si Si Si No
5.2.2. Características fundamentales

ACID* Integridad referencial Transacciones Unicode
DB2 Si Si Si Si
SQL Server Si Si Si Si
MySQL Si Si Si Si
Oracle Si Si Si Si
PostgreSQL Si Si Si Si
*ACID: Atomicity, Consistency, Isolation, Durability o en castellano atomicidad, consistencia, aislamiento y

durabilidad; son una serie de propiedades que garantizan que las transacciones se ejecutan de forma
fiable.
5.2.3. Límites
De BD De Tabla De Fila De De De De
columnas Blob/Clob CHAR NUMBER
por fila
DB2 512TB 512TB 32,677 1012 2GB 32KB 64 bits

bytes
SQL Server 524,258 524,258TB 8060 1024 2GB 8000 64 bits
TB bytes bytes
MySQL Unlimite 2GB (Win32 64KB 3398 4GB 64KB 64 bits
d FAT32) to (longtext, (text)
16TB longblob)
(Solaris)
Oracle Unlimite 4GB * block Unlimited 1000 4GB (or 4000 126 bits
d (4GB size (with max bytes
* block BIGFILE datafile
size per tablespace) size for
tablespa platform)
ce)
PostgreSQL Unlimite 32TB 1.6TB 250-1600 1GB (text, 1GB 64 bits
d depending bytea) -
stored
de bases de datos.
40
on type inline
5.2.4. Tablas y vistas

Tabla temporal Vista materializada
DB2 Si Si
SQL Server Si Si
MySQL Si No
Oracle Si Si
PostgreSQL Si No
5.2.5. Capacidades
R-/R+ Hash Expressio Partial Reverse Bitmap GiST GIN
tree n
DB2 No No No Si Si No No
SQL Server Non/Clus Si Si Si No No No
ter & fill
factor
MySQL MyISA MEMORY No No No No No No
M , Cluster
tables (NDB),
only InnoDB,1
7 tables
only
Oracle EE Cluster Si Si Si Si No No
editio Tables
n only
PostgreSQL Si Si Si Si Si Si Si Si
de bases de datos.
41

Temas Específicos para La Preparación de La Oposición Al Cuerpo Superior de Sistemas y Tecnologías de La Información de La Administración Del Estado

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Temas Específicos para La Preparación de La Oposición Al Cuerpo Superior de Sistemas y Tecnologías de La Información de La Administración Del Estado

Cargado por

Copyright:

Formatos disponibles

Asociación Profesional del Cuerpo Superior

de Sistemas y Tecnologías de la Información

Temas Específicos para la preparación de la Oposición al Cuerpo

TEMAS ESPECÍFICOS II: Tecnología Básica

Tema 58. El modelo relacional. El lenguaje SQL. Normas y

AUTOR: Leonor Torres, Carmen García y Juan Cantador.

058. El modelo relacional. El lenguaje SQL. Normas y

1. Introducción. Bases de Datos Relacionales ................................................................................. 3

5.2.1. Disponible en qué Sistema Operativo .......................................................................40

1. INTRODUCCIÓN. BASES DE DATOS RELACIONALES

o Grado: Número de atributos.

La restricciones semánticas se pueden clasificar en:

Col1 Col2 … Col n

2.2. Com ponentes

2.3. 12+1 Reglas de CODD

REGLA 1: REGLA DE LA INFORMACIÓN

REGLA 2: REGLA DEL ACCESO GARANTIZADO

REGLA 3: TRATAMIENTO SISTEMÁTICO DE VALORES NULOS

REGLA 4: CATÁLOGO DINÁMICO EN LÍNEA BASADO EN EL MODELO RELACIONAL

REGLA 5: REGLA DEL SUBLENGUAJE DE DATOS COMPLETO

REGLA 6: REGLA DE ACTUALIZACIÓN DE VISTAS

REGLA 7: INSERCIÓN, ACTUALIZACIÓN Y BORRADO DE ALTO NIVEL

REGLA 8: INDEPENDENCIA FÍSICA DE DATOS

REGLA 9: INDEPENDENCIA LÓGICA DE DATOS

REGLA 10: INDEPENDENCIA DE INTEGRIDAD

REGLA 11: INDEPENDENCIA DE DISTRIBUCIÓN

REGLA 12: REGLA DE LA NO SUBVERSIÓN

2.4. N orm alización

• Evita anomalías en inserciones, modificaciones y borrados.

Uno de los conceptos fundamentales en la normalización es el de dependencia funcional. Una dependencia

2.4.1.1 Primera Forma Normal(1FN)

2.4.1.2 Segunda Forma Normal(2FN)

2.4.1.3 Tercera Forma Normal (3FN)

2.4.1.4 Forma normal de Boyce-Codd (BCFN)

2.4.1.5 FORMAS NORMALES AVANZADAS

2.4.1.5.1 Dependencias m ultivaluadas:

2.4.1.5.2 Cuarta Form a N orm al (4FN)

2.4.1.5.3 Dependencias de Com binación

2.4.1.5.4 Quinta Form a N orm al (5FN)

• (R1, R2, R3, ... Rn) es una dependencia de producto trivial.

2.5. Álgebra relacional

• PROYECCIÓN: ∏ col1, . . . , coln(R)

• SELECCIÓN. δpredicado (R)

Equivalencia con operadores básicos

2. EVOLUCIÓN DEL LENGUAJE SQL

3.2. El lenguaje SQL

3.2.1. CONCEPTOS SQL

• USERS, SCHEMATA, DATA_TYPE_DESCRIPTOR, DOMAINS, DOMAINS_CONSTRAINTS, TABLES,

3.2.2. DDL Descripción de objetos

• El esquema de cada relación.

La creación de esquemas se lleva a cabo mediante la sentencia:

3.2.2.1.1 Dom inios

La definición de dominios es de la siguiente manera:

<definición de dominio> ::=

<restricción de dominio> ::=

en la cual se puede, opcionalmente, dar un nombre a la restricción de dominio de

<definición de nombre de restricción> ::=

El único elemento obligatorio de la restricción de dominio es la:

<definición de restricción de verificación> ::=

CREATE DOMAIN Tipos_Doc CHAR(1)

<atributos de restricción> ::=

<definición de tabla> ::=

<definición de columna> ::=

SELECT Documento., Editorial. FROM Documento, Editorial;