Unidad I. Introducción.

1.1.  Definiciones y Conceptos de Base de Datos.

Una base de datos es una colección organizada de información. Ésta contiene una
colección de registros que puede buscar, ordenar y analizar rápidamente.

1.2.  Sistemas de Base de Datos vs. Sistemas de procesamiento de archivos.

Una manera de mantener información en un computador es hacerlo mediante un sistema
de procesamiento de archivos típico o tradicional, que permitirá tener a los archivos
estructurados y organizados, y poder realizar operaciones con ellos. Este sistema de
archivos se mantiene mediante un sistema operativo convencional. Antes de la llegada de
los sistemas de gestión de bases de datos (SGBD), las organizaciones normalmente han
almacenado la información usando estos sistemas, pero mantener la información en estos
sistemas de archivos tiene una serie de inconvenientes importantes:
 Redundancia e inconsistencia de datos. Existen datos que pueden repetirse en
diferentes lugares o archivos, esto provoca que, teniendo esa duplicidad de datos,
el almacenamiento y el costo (en recursos del sistema) de acceso sean más altos.
Inconsistencia de datos se presentará porque las copias de los mismos datos en
diferentes archivos pueden no coincidir, pues si en un archivo se hicieron cambios
de los datos, en los otros archivos donde estaban los mismos datos no son
modificados estomáticamente.
 Dificultad en el acceso a los datos. Cuando se requiere de ciertos datos diferentes
de archivos diferentes, la obtención, consulta y modificación de los datos no puede
hacerse dirtectamente de forma práctica y eficiente. Tendrían que desarrollarse
sistemas de recuperación de datos para realizar esa operación específica, o
desarrollar un sistema de recuperación de datos para uso general y ajustarlo
de acuerdo a las necesidades.
 Aislamiento de datos. Debido a que los datos están dispersos en varios archivos, y
los archivos pueden estar en diferentes formatos, es difícil escribir nuevos
programas de aplicación para recuperar los datos apropiados.
 Problemas de integridad. Los valores de los datos almacenados en la BD deben
satisfacer ciertas restricciones de consistencias. Los desarrolladores hacen cumplir
estas restricciones en el sistema añadiendo código apropiado en las diversas
aplicaciones. Sin embargo, cuando se añaden nuevas restricciones es difícil
 cambiar los programas para hacer que se cumplan. Esto se complica cuando las
restricciones implican diferentes elementos de datos de diferentes archivos.
 Problemas de atomicidad. En muchas aplicaciones es crucial asegurar que, cuando
ocurra un fallo y sea detectado, se restauren los datos a un estado de consistencia
que existía antes del fallo. Es difícil asegurar esta propiedad en un sistema de
archivos tradicional.
 Anomalías en el acceso concurrente. en estos sistemas un entorno en el que
permita a múltiples usuarios actualizar los datos de un mismo archivo
simultáneamente puede dar lugar a datos inconsistentes o un estado incorrecto.
 Problemas de seguridad. No todos los usuarios de un sistema de bases de datos
deberían poder acceder a todos los datos. En estos sistemas es difícil garantizar
tales restricciones de seguridad.
Estas dificultades, entre otras, han motivado el desarrollo de los sistemas de bases de
datos para resolver estos problemas.

1.3.  Personas que se relacionan con una base de datos y tipos de usuarios de una Base
de Datos, DBA y funciones de una DBA.
 Administrador de base de datos (DBA): Define los esquemas de la base de datos;
estructuras y esquemas de los 3 niveles. Más que una persona suele ser un grupo
de personas. 
 Programador de aplicaciones: Utilizando un lenguaje de alto nivel y llamadas
en DML crean programas para usar la base de datos.
 Usuarios casuales: Son usuarios que tienen conocimientos de los DL, hacen uso de
los DML de modo interactivo (es decir a través del procesador de consultas).
 Usuarios ingenuos: Emplean el SBD sin conocimientos de informática, es decir
usan los programas de aplicación.
 Administrador de Base de Datos: Denominado por sus siglas como: DBA, Database
Administrador. Es la persona encargada y que tiene el control total sobre el
sistema de base de datos, sus funciones principales son:
 Definición de esquema: Es el esquema original de la base de datos se crea
escribiendo un conjunto de definiciones que son traducidas por el compilador de
DDL a un conjunto de tablas que son almacenadas permanentemente en el
diccionario de datos.
 Definición de la estructura de almacenamiento del método de acceso: Estructuras
de almacenamiento y de acceso adecuados se crean escribiendo un conjunto de
definiciones que son traducidas por e compilador del lenguaje de almacenamiento
y definición de datos.
  Concesión de autorización para el acceso a los datos: Permite al administrador de
la base de datos regular las partes de las bases de datos que van a ser accedidas
por varios usuarios.
 Especificación de limitantes de integridad: Es una serie de restricciones que se
encuentran almacenados en una estructura especial del sistema que es consultada
por el gestor de base de datos cada vez que se realice una actualización al sistema.

1.4.  Niveles de Abstracción, método general para realizar la abstracción del mundo real.
Uno de los objetivos principales de una base de datos es proporcionar a los usuarios una
visión abstracta de los datos. Es decir, el sistema oculta ciertos detalles relativos a la forma
en que se almacenan y mantienen los datos. Esto se logra definiendo tres niveles de
abstracción en los que puede considerarse la base de datos: físico, conceptual y de visión.
 En el nivel físico se describe cómo se almacenan los datos en cuanto a detalles de
estructuras de datos complejas del nivel más bajo.
 En el nivel conceptual, que es el siguiente nivel más alto de abstracción, se
describe cuáles son los datos reales que están almacenados en la base de datos y
qué relaciones existen entre los datos.
 El nivel de visión es más alto, en el cual se describe solo una parte de la base de
datos y se presentan vistas diferentes de la misma base de datos a los usuarios.

1.5.  Instancias y Esquemas.

 Instancia.
Es el estado que presenta una base de datos en un tiempo dado. Veámoslo como
una fotografía que tomamos de la base de datos en un tiempo t, después de que
transcurre el tiempo t la base de datos ya no es la misma.
 Esquema.
Es la descripción lógica de la base de datos, proporciona los nombres de las
entidades y sus atributos especificando las relaciones que existen entre ellos. Es un
banco en el que se inscriben los valores que irán formando cada uno de los
atributos. El esquema no cambia los que varían son los datos y con esto tenemos
una nueva instancia.

1.6.  Independencias lógica y física de datos.

 Independencia lógica: se puede cambiar la estructura de datos almacenados, sin
afectarlos. Además de cambiarse los programas aplicativos que acceden a las bases
de datos sin que esto altere a la base de datos.
  Independencia física: las aplicaciones permanecen inalteradas sin importar los
cambios efectuados en el almacenamiento o en los métodos de acceso.

1.7.  Modelos de Base de Datos.

Existen fundamentalmente tres alternativas disponibles para diseñar las bases de datos:
el modelo jerárquico, el modelo de red y el modelo relacional.

a). El modelo jerárquico

La forma de esquematizar la información se realiza a través de representaciones
jerárquicas o relaciones de padre/hijo, de manera similar a la estructura de un árbol. Así,
el modelo jerárquico puede representar dos tipos de relaciones entre los datos: relaciones
de uno a uno y relaciones de uno a muchos.
En el primer tipo se dice que existe una relación de uno a uno si el padre de la estructura
de información tiene un solo hijo y viceversa, si el hijo tiene solamente un padre. En el
segundo tipo se dice que la relación es de uno a muchos si el padre tiene más de un hijo,
aunque cada hijo tenga un solo padre.
Inconveniente del modelo jerárquico:
Relación maestro-alumno, donde un maestro tiene varios alumnos, pero un alumno
también tiene varios maestros, uno para cada clase. En este caso, si la información
estuviera representada en forma jerárquica donde el padre es el maestro y el alumno es el
hijo, la información del alumno tendrá que duplicarse para cada uno de los maestros.
Otra dificultad que presenta el modelo jerárquico de representación de datos es respecto
a las bajas. En este caso, si se desea dar de baja a un padre, esto necesariamente implicará
dar de baja a todos y cada uno de los hijos que dependen de este padre.
b). El modelo de red
El modelo de red evita esta redundancia en la información, a través de la incorporación de
un tipo de registro denominado el conector, que en este caso pueden ser las calificaciones
que obtuvieron los alumnos de cada profesor.
La dificultad surge al manejar las conexiones o ligas entre los registros y sus
correspondientes registros conectores.

c). El modelo relacional

Se está empleando con más frecuencia en la práctica, debido el rápido entendimiento por
parte de los usuarios que no tienen conocimientos profundos sobre Sistemas de Bases de
Datos y a las ventajas que ofrece sobre los dos modelos anteriores.
En este modelo toda la información se representa a través de arreglos bidimensionales o
tablas. Estas operaciones básicas son:
 Seleccionar renglones de alguna tabla (SELECT)
 Seleccionar columnas de alguna tabla (PROJECT)
 Unir o juntar información de varias tablas (JOIN)

Unidad II. DBMS

2.1.  Definición y objetivos de un DBMS
El software que controla la organización, almacenamiento, recuperación, seguridad e
integridad de los datos en una base de datos. Acepta solicitudes de la aplicación e indica al
sistema operativo para transferir los datos apropiados. Los principales proveedores de
DBMS son Oracle, IBM, Microsoft y Sybase. 
Los principales objetivos de un DBMS son los siguientes:
1. Independencia lógica y física de los datos: se refiere a la capacidad de modificar
una definición de esquema en un nivel de la arquitectura sin que esta modificación afecte
al nivel inmediatamente superior. Para ello un registro externo en un esquema externo no
tiene por qué ser igual a su registro correspondiente en el esquema conceptual. 6
2. Redundancia mínima: se trata de usar la base de datos como repositorio común
de datos para distintas aplicaciones.
3. Acceso concurrente por parte de múltiples usuarios: control de concurrencia
mediante técnicas de bloqueo o cerrado de datos accedidos.
4. Distribución espacial de los datos: la independencia lógica y física facilita la
posibilidad de sistemas de bases de datos distribuidas. Los datos pueden encontrarse en
otra habitación, otro edificio e incluso otro país. El usuario no tiene por qué preocuparse
de la localización espacial de los datos a los que accede.
5. Integridad de los datos: se refiere a las medidas de seguridad que impiden que se
introduzcan datos erróneos. Esto puede suceder tanto por motivos físicos (defectos de
hardware, actualización incompleta debido a causas externas), como de operación
(introducción de datos incoherentes).
6. Consultas complejas optimizadas: la optimización de consultas permite la rápida
ejecución de las mismas.
7. Seguridad de acceso y auditoría: se refiere al derecho de acceso a los datos
contenidos en la base de datos por parte de personas y organismos. El sistema de
auditoría mantiene el control de acceso a la base de datos, con el objeto de saber qué o
quién realizó una determinada modificación y en qué momento.
8. Respaldo y recuperación: se refiere a la capacidad de un sistema de base de datos
de recuperar su estado en un momento previo a la pérdida de datos.
9. Acceso a través de lenguajes de programación estándar: se refiere a la posibilidad
ya mencionada de acceder a los datos de una base de datos mediante lenguajes de
programación ajenos al sistema de base de datos propiamente dicho.

2.2.  Funciones de un DBMS

1.− Definición de Datos: Debe ser capaz de aceptar definiciones de datos (esquema
externo, conceptual Interno y todas las correspondencias asociadas. en versión Fuente) y
convertirla en una versión de objeto apropiada. Debe incluir componentes de
procesadores de lenguajes para cada uno de los diversos lenguajes de definición de datos,
además debe tener las definiciones en DBL (Lenguaje Definición de datos) para poder
interpretar y resolver las solicitudes.
2.− Manipulación de Datos: Debe atender las solicitudes del usuario tales como
eliminación, modificación, extracción etc., es decir, debe incluir un componente
procesador de lenguajes de manipulación de datos(DML). En general las solicitudes en
DML pueden ser planificadas y no planificadas.
3.− SEGURIDAD E INTEGRIDAD DE LOS DATOS: El DBMS debe supervisar las solicitudes de
los usuarios y rechazar los intentos de violar las necesidades de seguridad e integridad de
los datos definidos para el DBA.
4.− RECUPERACIÓN Y CONCURRENCIA DE LOS DATOS: El DBMS debe cuidar el
cumplimiento de ciertos controles de recuperación y concurrencia. El Administrador de
transacciones actúa en caso de que el DBMS no funciones.
5.− DICCIONARIO DE DATOS: El DBMS debiera incluir una función de diccionarios de datos
(Meta _datos), se puede decir que es una base de Datos del sistema y no del usuario cuyo
contenido pueden considerarse como Datos acerca de los Datos que en el fondo son
definiciones de objetos de datos y otros objetos del sistema.
6.− DESEMPEÑO: El DBMS debiera ejecutar todas las funciones anteriores en la forma más
eficiente.
7.− ADMINISTRADOR DE COMUNICACIONES DE DATOS: Las solicitudes de un usuario final
son dirigidas a la Base de datos donde son transmitidas en forma de mensajes de
comunicación o a la inversa las respuestas al usuario son tomados como mensajes del
mismo tipo, todas las transmisiones se efectúan bajo el control de otros grupos de
programas llamados administrador de comunicación de datos el cual no forma parte del
DBMS, sino que es un programa autónomo pero debe trabajar en forma conjunta con el
DBMS para poder satisfacer los requerimientos de los usuarios.

2.3.  Partes que conforman un DBMS

 Data definition language (DDL): Define elementos de los datos en la base de datos
 Data manipulation language (DML): Manipula datos para aplicaciones 
 Data dictionary: Definiciones de todas las variables en la base

2.4.  Lenguajes de un DBMS (DDL, DML)

En la estructura básica de un Sistema Manejador de Base de Datos se enuncian dos
lenguajes que permiten trabajar sobre la base de datos.  Estos lenguajes estándar son: 
 DDL (Data Definition language):  Lenguaje de Definición de Datos.  Por medio de
este el DBMS identifica las descripciones de los elementos de los esquemas y
almacena la descripción del esquema en el catálogo del DBMS.
Por medio de este el DBMS especifica el esquema conceptual e interno (Base de
datos Almacenada). 
 SDL (Store Definition language): Lenguaje de definición de almacenamiento.  Es
utilizado por el DBMS para especificar el esquema interno que corresponde a la
Base de Datos Almacenada.
 VDL (View Definition language): Lenguaje de Definición de Vistas.  Es utilizado por
el DBMS para especificar las vistas del usuario y sus correspondencias con el
esquema conceptual.
En las Bases de Datos Relacionales, el SQL, representa una combinación de los anteriores.
  DML (Data Manipulation language): Lenguaje de Manipulación de Datos.  Permite
la manipulación de las operaciones de Inserción, Eliminación y Modificación.
 Tipos de DML's:
 De alto Nivel o No por procedimientos: SQL.
 De bajo Nivel o por procedimientos.

2.5.  Introducción al lenguaje de consulta SQL (historia, comandos básicos)

La historia de SQL (que se pronuncia deletreando en inglés las letras que lo componen, es
decir "ese-cu-ele" y no "siquel" como se oye a menudo) empieza en 1974 con la
definición, por parte de Donald Chamberlin y de otras personas que trabajaban en los
laboratorios de investigación de IBM, de un lenguaje para la especificación de las
características de las bases de datos que adoptaban el modelo relacional. Este lenguaje se
llamaba SEQUEL (Structured English Query Language) y se implementó en un prototipo
llamado SEQUEL-XRM entre 1974 y 1975. Las experimentaciones con ese prototipo
condujeron, entre 1976 y 1977, a una revisión del lenguaje (SEQUEL/2), que a partir de ese
momento cambió de nombre por motivos legales, convirtiéndose en SQL. El prototipo
(System R), basado en este lenguaje, se adoptó y utilizó internamente en IBM y lo
adoptaron algunos de sus clientes elegidos. Gracias al éxito de este sistema, que no estaba
todavía comercializado, también otras compañías empezaron a desarrollar sus productos
relacionales basados en SQL. A partir de 1981, IBM comenzó a entregar sus productos
relacionales y en 1983 empezó a vender DB2. En el curso de los años ochenta, numerosas
compañías (por ejemplo Oracle y Sybase, sólo por citar algunos) comercializaron
productos basados en SQL, que se convierte en el estándar industrial de hecho por lo que
respecta a las bases de datos relacionales.
En 1986, el ANSI adoptó SQL (substancialmente adoptó el dialecto SQL de IBM) como
estándar para los lenguajes relacionales y en 1987 se transformó en estándar ISO. Esta
versión del estándar va con el nombre de SQL/86. En los años siguientes, éste ha sufrido
diversas revisiones que han conducido primero a la versión SQL/89 y, posteriormente, a la
actual SQL/92.
El hecho de tener un estándar definido por un lenguaje para bases de datos relacionales
abre potencialmente el camino a la intercomunicabilidad entre todos los productos que se
basan en él. Desde el punto de vista práctico, por desgracia las cosas fueron de otro
modo. Efectivamente, en general cada productor adopta e implementa en la propia base
de datos sólo el corazón del lenguaje SQL (el así llamado Entry level o al máximo el
Intermediate level), extendiéndolo de manera individual según la propia visión que cada
cual tenga del mundo de las bases de datos.
Actualmente, está en marcha un proceso de revisión del lenguaje por parte de los comités
ANSI e ISO, que debería terminar en la definición de lo que en este momento se conoce
como SQL3. Las características principales de esta nueva encarnación de SQL deberían ser
su transformación en un lenguaje stand-alone (mientras ahora se usa como lenguaje
hospedado en otros lenguajes) y la introducción de nuevos tipos de datos más complejos
que permitan, por ejemplo, el tratamiento de datos multimediales.

Comandos
Existen dos tipos de comandos SQL:
 DLL que permiten crear y definir nuevas bases de datos, campos e índices.
 DML que permiten generar consultas para ordenar, filtrar y extraer datos de la
base de datos.
Comandos DLL
Comando Descripción
CREATE Utilizado para crear nuevas tablas, campos e índices
DROP Empleado para eliminar tablas e índices
Utilizado para modificar las tablas agregando campos o cambiando la definición
ALTER
de los campos.
Comandos DML
Comando Descripción
Utilizado para consultar registros de la base de datos que satisfagan un criterio
SELECT
determinado
INSERT Utilizado para cargar lotes de datos en la base de datos en una única operación.
UPDATE Utilizado para modificar los valores de los campos y registros   especificados
DELETE Utilizado para eliminar registros de una tabla de una base   de datos
Cláusulas
Las cláusulas son condiciones de modificación utilizadas para definir los datos que desea
seleccionar o manipular.
Cláusula Descripción
Utilizada para especificar la tabla de la cual se van a seleccionar los
FROM
registros
Utilizada para especificar las condiciones que deben reunir los registros
WHERE
que se van a seleccionar
GROUP BY Utilizada para separar los registros seleccionados en grupos específicos
HAVING Utilizada para expresar la condición que debe satisfacer cada grupo
Utilizada para ordenar los registros seleccionados de acuerdo con un
ORDER BY
orden específico
Operadores Lógicos
Operador Uso
Es el "y" lógico. Evalúa dos condiciones y devuelve un valor de verdad sólo si
AND
ambas son ciertas.
 Es el "o" lógico. Evalúa dos condiciones y devuelve un valor de verdad si alguna de
OR
las dos es cierta.
NOT Negación lógica. Devuelve el valor contrario de la expresión.
Operadores de Comparación
Operador Uso
<  Menor que
>  Mayor que
<>  Distinto de
<= Menor o igual que
>= Mayor o igual que
= Igual que
BETWEEN Utilizado para especificar un intervalo de valores.
LIKE Utilizado en la comparación de un modelo
In Utilizado para especificar registros de una base de datos
Funciones de Agregado
Las funciones de agregado se usan dentro de una cláusula SELECT en grupos de registros
para devolver un único valor que se aplica a un grupo de registros.
Funciónn Descripción
AVG Utilizada para calcular el promedio de los valores de un campo   determinado
COUNT Utilizada para devolver el número de registros de la selección
SUM Utilizada para devolver la suma de todos los valores de un campo determinado
MAX Utilizada para devolver el valor más alto de un campo especificado
MIN Utilizada para devolver el valor más bajo de un campo especificado
Orden de ejecución de los comandos
Dada una sentencia SQL de selección que incluye todas las posibles cláusulas, el orden de
ejecución de las mismas es el siguiente:
1. Cláusula FROM
2. Cláusula WHERE
3. Cláusula GROUP BY
4. Cláusula HAVING
5. Cláusula SELECT
6. Cláusula ORDER BY
Unidad III.  Modelado Relacional
3.1.  Modulación de una Base de Datos
Los modelos de datos aportan la base conceptual para diseñar aplicaciones que hacen un
uso intensivo de datos, así como la base formal para las herramientas y técnicas
empleadas en el desarrollo y uso de sistemas de información. Con respecto al diseño de
bases de datos, el modelado de datos puede ser descrito así (Brodie 1984:20): "dados los
requerimientos de información y proceso de una aplicación de uso intensivo de datos (por
ejemplo, un sistema de información), construir una representación de la aplicación que
capture las propiedades estáticas y dinámicas requeridas para dar soporte a los procesos
deseados (por ejemplo, transacciones y consultas). Además de capturar las necesidades
dadas en el momento de la etapa de diseño, la representación debe ser capaz de dar
cabida a eventuales futuros requerimientos".

3.1.1.  Modelo Entidad-Relación

Cuando se utiliza una base de datos para gestionar información, se está plasmando una
parte del mundo real en una serie de tablas, registros y campos ubicados en un
ordenador; creándose un modelo parcial de la realidad. Antes de crear físicamente estas
tablas en el ordenador se debe realizar un modelo de datos.
Se suele cometer el error de ir creando nuevas tablas a medida que se van necesitando,
haciendo así el modelo de datos y laconstrucción física de las tablas simultáneamente. El
resultado de esto acaba siendo un sistema de información parcheado, con datos dispersos
que terminan por no cumplir adecuadamente los requisitos necesarios.

Entidades y Relaciones
El modelo de datos más extendido es el denominado ENTIDAD/RELACIÓN (E/R) En el
modelo E/R se parte de una situación real a partir de la cual se
definen entidades y relaciones entre dichas entidades:
 Entidad.- Objeto del mundo real sobre el que queremos almacenar información
(Ej: una persona). Las entidades están compuestas de atributos que son los datos
que definen el objeto (para la entidad persona serían DNI, nombre, apellidos,
dirección,...). De entre los atributos habrá uno o un conjunto de ellos que no se
repite; a este atributo o conjunto de atributos se le llama clave de la entidad, (para
la entidad persona una clave seria DNI). En toda entidad siempre hay al menos una
clave que en el peor de los casos estará formada por todos los atributos de la
tabla. Ya que pueden haber varias claves y necesitamos elegir una, lo haremos
atendiendo a estas normas:
 Que sea única.
 Que se tenga pleno conocimiento de ella.- ¿Por qué en las empresas se asigna a
cada cliente un número de cliente?.
 Que sea mínima, ya que será muy utilizada por el gestor de base de datos.
  Relación.- Asociación entre entidades, sin existencia propia en el mundo real que
estamos modelando, pero necesaria para reflejar las interacciones existentes entre
entidades. Las relaciones pueden ser de tres tipos:
 Relaciones 1-1.- Las entidades que intervienen en la relación se asocian una a una
(Ej: la entidad HOMBRE, la entidad MUJER y entre ellos la relación MATRIMONIO).
 Relaciones 1-n.- Una ocurrencia de una entidad está asociada con muchas (n) de
otra (Ej: la entidad EMPRESA, la entidad TRABAJADOR y entre ellos la relación
TRABAJAR-EN).
 Relaciones n-n.-Cada ocurrencia, en cualquiera de las dos entidades de la relación,
puede estar asociada con muchas (n) de la otra y viceversa (Ej: la entidad
ALUMNO, la entidad EMPRESA y entre ellos la relación MATRÍCULA).
 Representación gráfica de Entidades y Relaciones
 Para asimilar fácilmente un diseño de datos cuando se emplea el modelo E/R se
utilizan los siguientes elementos gráficos:

La utilización de estos elementos dará como resultado lo que se denomina

el esquema entidad-relación de la base de datos. Los ejemplos que se incluyen en el
apartado anterior, gráficamente quedarían como sigue:

3.1.2.  Definición de dato, entidad y conjunto de entidades, atributos y sus dominios

 Dato: El dato es una representación simbólica (numérica, alfabética, algorítmica,
entre otros.), un atributo o característica de una entidad. Los datos describen
hechos empíricos, sucesos y entidades.
 Conjunto de Entidades: es un contenedor lógico para las instancias de un tipo de
entidad y las instancias de cualquier tipo que se deriven de ese tipo de entidad. 
  Atributos: Los atributos representan las propiedades pertinentes o características
de una entidad. En el modelo físico, se representan atributos como columnas de
una tabla. Hay dos tipos de atributos, la tabla debajo de describe estos tipos:
Atributo Descripción

identificadores Un atributo que ayuda a identificar a una entidad son los atributos de la
llave primaria.

Descriptor Un atributo no-llave. Siguiendo las reglas de normalización, si un atributo

no es parte de la llave primaria, entonces su único propósito es describir
las características de la entidad.

 Dominio: Un dominio describe un conjunto de posibles valores para cierto

atributo. Como un dominio restringe los valores del atributo, puede ser
considerado como una restricción. Matemáticamente, atribuir un dominio a un
atributo significa "todos los valores de este atributo deben de ser elementos del
conjunto especificado".
Distintos tipos de dominios son: enteros, cadenas de texto, fecha, no procedurales, etc.

3.1.3.  Definición de relación y conjunto de relaciones, relaciones binarias, ternarias

(aridad)  
*Relación: una relación o vínculo entre dos o más entidades describe alguna interacción
entre las mismas. Por ejemplo, una relación entre una entidad "Empleado" y una entidad
"Sector" podría ser "trabaja_en", porque el empleado trabaja en un sector determinado.
*Conjunto de relaciones: es un grupo de relaciones del mismo tipo. 
*Relaciones Binarias: Las relaciones binarias se utilizan en muchos ramas de las
matemáticas para modelar conceptos como "es mayor que", "es igual a", y "se divide"
adentro aritmética, "a "adentro geometría, "está adyacente" a adentro teoría de gráfico, y
muchos más. El concepto todo-importante de función se define como clase especial de
relación binaria. Las relaciones binarias son también muy usadas adentro informática,
especialmente dentro de modelo emparentado para bases de datos. Una relación binaria
es el caso especial n = 2 de n- ary relación, es decir, un sistema de n-tuples donde jth
componente de cada uno n- el tuple se toma de jth dominio Xj de la relación. n- la relación
ary entre elementos de un solo sistema reputa. 
*Ternarias(aridad): Una relación ternaria relaciona tres tipos y es principalmente teórica

.
*Aridad: El número de columnas es llamado aridad o grado.

3.1.4. Cardinalidad de mapeo

Es aquella mediante la cual puede especificarse la cantidad de entidades que podrán
asociarse mediante una relación.
La CARDINALIDAD del mapeo se aplica generalmente sobre dos conjuntos de entidades.
Las cardinalidades existente para dos conjuntos de entidades A y B y conjunto de
relaciones R pueden ser:
1. UNA A UNA: Una entidad de A puede asociarse únicamente con una entidad de B.
2. UNA A MUCHAS: Una entidad de a puede asociarse con cualquier cantidad de
entidades de B.
3. MUCHAS A UNA: Cualquier cantidad de entidades de A puede asociarse con una
entidad de B.
4. MUCHAS A MUCHAS: Cualquier cantidad de entidades de a puede asociarse con
cualquier cantidad de entidades en B.
Ejemplo: 
UNA A UNA UNA A MUCHAS MUCHAS A UNA MUCHAS A MUCHAS
Alumnos Tesis Carreras Alumnos Alumnos Carreras Alumnos Materias

 3.1.5.  Dependencia por existencia

Nos permiten definir que un conjunto de entidades esta condicionado a la existencia de
otro un ejemplo de este condicionamiento se da entre una entidad alumno y la entidad
calificación.
A esta limitante se le denomina dependencia por existencia. Si una entidad Y requiere de
una entidad X para existir se dice que Y es dependiente por existencia de X; esto implica
que si eliminamos a la entidad X; deberá eliminarse la entidad Y.
Para el caso anterior, se nombrara a X como la entidad dominante, y a Y como entidad
subordinada.

3.1.6.  Llaves de acceso y tipos

Entendemos como una llave al medio que nos permite identificar en forma unívoca (única
e inequívoca) a una entidad dentro de un conjunto de entidades.
Existen diversas categorías que permiten clasificar los tipos de llaves a utilizara:
a) SUPER -LLAVE .- Es un conjunto de atributos mediante los cuales es posible reconocer a
una entidad. Este tipo de llaves contiene comúnmente atributos ajenos; es decir; atributos
que no son indispensables para llevar a cabo el reconocimiento del registro.
b) LLAVE CANDIDATO.- Son aquellas super llaves que no contienen atributos ajenos; es
decir, aquellos conjuntos de atributos que no tienen un subconjunto menor que pueda
considerarse como super llave.
c) LLAVE PRIMARIA.- Es aquella llave que el diseñador de la base de datos selecciona
entra las llaves candidatos encontradas.

3.1.7.  Diagrama E-R y su simbología

Son esquemas que nos permitan representar conjunto de entidades y sus relaciones
mediante la siguiente simbología.
 Conjunto de entidades o relación con sus atributos 
 Conjunto entidades con relaciones 
 Cada elemento debe etiquetarse con su nombre.

3.2.  Reglas de integridad y restricciones de asignación

Reglas de Integridad: La integridad en una base de datos se refiere a la corrección y
exactitud de la información contenida.
Hay  tres reglas de integridad muy importantes que son restricciones que se deben
cumplir en todas las bases de datos relacionales y en todos sus estados o instancias (las
reglas se deben cumplir todo el tiempo). Estas reglas son la de integridad de
entidades, restricciones de dominio y la de integridad referencial.
Reglas de Integridad Dominio
Un Dominio de valores posibles puede estar asociado a cada atributo. Los límites de
Dominio son la forma más elemental de restricciones de Integridad. Son fáciles de probar
en el sistema siempre que se introduce un nuevo dato en el sistema.
Una definición bien adecuada de restricciones de dominio no sólo nos permite probar
valores insertados en la base de datos. También nos permite probar consultas para
asegurarnos de que las comparaciones que se hacen tienen sentido.
Reglas de Integridad Relación
Las reglas de Integridad de relación son restricciones que se deben cumplir en todas las
bases de datos relacionales y en todos sus estados o instancias, es decir, se deben cumplir
todo el tiempo.
Existen básicamente dos reglas de Integridad asociadas con el modelo relacional:
la Integridad de Entidad y la Integridad Referencial. Estas dos reglas son generales y tienen
relación con las llaves primarias y foráneas.
Integridad de Entidad
Las restricciones de entidades aseguran la integridad de las entidades que son modeladas
por el sistema. En el nivel más simple, la existencia de una clave principal es una
restricción de entidad que impone la regla "cada entidad debe estar identificada de forma
única".
En esta no está permitido que algún componente de la clave primaria acepte valores
nulos.
Las razones de esta regla son: 
 Las tuplas en las relaciones base representan entidades en la realidad.
 Las entidades en la realidad son identificables por definición.
 Sus contrapartes en la base de datos también deben ser identificables.
 Los valores de la clave primaria sirven como identificadores en la base de datos.
 Los valores de clave primaria no pueden ser nulos.
Restriccion de asignación: 
Una restricción es una condición que obliga el cumplimiento de ciertas condiciones en la
base de datos. Algunas no son determinadas por los usuarios, sino que son
inherentemente definidas por el simple hecho de que la base de datos sea relacional.
Algunas otras restricciones las puede definir el usuario, por ejemplo, usar un campo con
valores enteros entre 1 y 10.
Las restricciones proveen un método de implementar reglas en la base de datos. Las
restricciones restringen los datos que pueden ser almacenados en las tablas. Usualmente
se definen usando expresiones que dan como resultado un valor booleano, indicando si
los datos satisfacen la restricción o no.
Las restricciones no son parte formal del modelo relacional, pero son incluidas porque
juegan el rol de organizar mejor los datos. Las restricciones son muy discutidas junto con
los conceptos relacionales.

Unidad IV. Normalización

Normalización en Base de Datos Relacionales

Consiste en aplicar una serie de reglas a las relaciones obtenidas tras el paso del modelo
entidad-relación al modelo relacional.

Las bases de datos relacionales se normalizan para:

 Evitar la redundancia de los datos.

 Evitar problemas de actualización de los datos en las tablas.
 Proteger la integridad de los datos.
En el modelo relacional es frecuente llamar tabla a una relación, aunque para que una
tabla sea considerada como una relación tiene que cumplir con algunas restricciones:
 Cada tabla debe tener su nombre único.
 No puede haber dos filas iguales. No se permiten los duplicados.
 Todos los datos en una columna deben ser del mismo tipo.
Normalizar es ordenar las relaciones que existen entre objetos, elementos de un grupo,
datos de una base de datos en función de unas determinadas características que cada uno
de ellos tiene en común.

La normalización de bases de datos relacional consiste en definir las reglas que

determinan las dependencias entre los datos de una base de datos relacional (BDR). Si
definimos esta relación o dependencia entre los elementos de una determinada base de
datos de la manera más sencilla posible, conseguiremos que la cantidad de espacio
necesario para guardar los datos sea el menor posible y la facilidad para actualizar la
relación sea la mayor posible. Es decir, optimizaremos su funcionamiento.

Dependencias Funcionales

Una dependencia funcional, denotada por X -> Y, entre dos conjuntos de atributos X y Y
que son subconjuntos de R (R ={A1, A2,...,A3}) especifica una restricción sobre las posibles
tuplas que podrían formar un ejemplar de relación r de R.  La restricción dice que, para 
cualesquier dos tuplas t1 y t2 de r tales que t1[X] = t2[X], debemos tener también t1[Y] =
t2[Y].  Esto significa que los valores componentes de Y de una tupla de r dependen de los
valores del componente X, o están determinados por ellos; o bien, que los valores del
componente X de una tupla determinan de manera única (o funcionalmente) los valores
del componente Y.  También decimos que hay una dependencia funcional de X a Y o que Y
depende funcionalmente de X. 

Sean a y b atributos de una misma tabla o relación T. Se dice que b es funcionalmente

dependiente de a y se denota T.a -> T.b o bien simplemente a -> b si todo posible valor de
a tiene asociado un único valor de b, o lo que es lo mismo, en todas las tuplas de T en las
que el atributo a toma el mismo valor v1, el atributo b toma también un mismo valor v2. 
Claramente a -> b no implica b -> a. Pueden repetirse los valores del atributo b para
distintos valores de a. Un mismo 

atributo puede determinar funcionalmente a varios atributos lo cual se denota a -> (b1,
b2, ...). Puede darse una  dependencia funcional mutua: a -> b y b -> a o lo que es lo
mismo a <-> b. Nóse que el concepto de dependencia funcional no depende de la
extensión concreta (contenido) que en un momento determinado tenga la tabla sino de
cualquier posible extensión que pudiera tener.

Los atributos a y b pueden ser simples o compuestos (formados por la agregación de

varios atributos). Los atributos funcionalmente dependientes pueden o no formar parte
de la clave primaria de la tabla, de una clave altenativa o de una clave ajena de otra tabla.

El atributo b es funcionalmente dependiente de forma completa de a si a -> b y b no

depende funcionalmente de ningún subconjunto de atributos de a. Si a es un atributo
simple y a -> b entonces la dependencia funcional es con seguridad completa.

Las dependencias funcionales verifican una serie de propiedades denominadas axiomas de

Armstrong:

Reflexividad. A partir de cualquier atributo o conjunto de atributos siempre puede

deducirse él mismo. Dependencia trivial: x -> x.

Aumentatividad. Si x -> y entonces x+z -> y. Así se puede aumentar trivialmente el

antecedente de una dependencia. Ejemplo: si con el dni se determina el nombre de una
persona, entonces con el dni más la dirección también se determina el nombre.

Proyectividad. Si x -> y+z entonces x -> y. Ejemplo: si a partir del dni es posible deducir el
nombre y la dirección de una persona, entonces con el dni es posible determinar el
nombre.

Aditividad. Si x -> y y z -> w entonces x+z -> y+w. Ejemplo: si con el dni se determina el
nombre y con la dirección el teléfono de una persona, entonces con el dni y la dirección
podrá determinarse el nombre y el teléfono.
Transitividad o enlace de dependencias funcionales. Si x -> y e y -> z entonces x -> z.
Ejemplo: si con el dni puede determinarse el código de la provincia de residencia de una
persona y con éste código puede determinarse el nombre de la provincia, entonces con el
dni puede determinarse el nombre de la provincia. Éste es el mecanismo básico de
funcionamiento del enlace entre tablas a partir de claves ajenas. 

Reglas de normalización

El punto de partida del proceso de normalización es un conjunto de tablas con sus

atributos, el denominado esquema relacional. Se pretende mejorar dicho esquema de
datos. Se dice que una tabla están en una determinada forma normal si satisface un cierto
número de restricciones impuestas por la correspondiente regla de normalización. La
aplicación de una de estas reglas a un esquema relacional produce un nuevo esquema
relacional en el que no se ha introducido ningún nuevo atributo.

Un esquema relacional se compone de una serie de ternas T(A,D) donde T es el nombre de

una tabla, A el conjunto de los atributos de esa tabla y D el conjunto de dependencias
funcionales que existen entre esos atributos.

Si una tabla no satisface una determinada regla de normalización, se procede a

descomponerla en otras dos nuevas que sí las satisfagan. Esto usualmente requiere decidir
qué atributos de la tabla original van a residir en una u otra de las nuevas  tablas. La
descomposición tiene que conservar dos propiedades fundamentales:

1. No pérdida de información.

Sea T(A,D) que se divide en T1(A1,D1) y T2(A2,D2). A partir de los atributos comunes en
ambos esquemas es posible determinar los atributos de T1 no presentes en T2 (es decir, el
conjunto A1 - A2) o bien los atributos de T2 no presentes en T1 (el conjunto diferencia A2
- A1). Desde cualquier esquema se consigue recuperar los datos del otro mediante un
mecanismo de clave ajena que permite reconstituir el esquema original de partida.
Expresado mediante dependencias funcionales, la intersección de los conjuntos de
atributos A1 y A2 debe determinar funcionalmente la diferencia de los conjuntos de
atributos A1 - A2 o bien A2 - A1.

2. No pérdida de dependencias funcionales.

La normalización consiste pues en descomponer los esquemas relacionales (tablas) en

otros equivalentes (puede obtenerse el original a partir de los otros) de manera que se
verifiquen unas determinadas reglas de normalización. Evidentemente las reglas de
normalización imponen una serie de restricciones en lo relativo a la existencia de
determinados esquemas relacionales. Según se avance en el cumplimiento de reglas y
restricciones se alcanzará una mayor forma normal. Existen cinco formas normales hacia
las cuales puede conducir el proceso de normalización de forma incremental más una
forma normal independiente de las otras.

Un esquema relacional que satisface todas las restricciones impuestas por la tercera
forma normal se considera de buena calidad aunque es mejor que satisfaga una
interesante propiedad. La verificación de una forma normal implica el cumplimiento de
todas las formas normales anteriores. La primera forma normal es de cumplimiento
obligatorio para que exista siquiera un esquema relacional propiamente formado

FN1. Se pretende garantizar la no existencia de grupos repetitivos. Un grupo repetitivo es

un conjunto de atributos de igual semántica en el problema y dominio, que toman valores
distintos para la misma clave. Cualquier esquema que tenga claves correctas está seguro
en FN1.

FN2. Si FN1 y cada atributo de la tabla que no forma parte de la clave depende
funcionalmente de forma completa de la clave primaria. Es decir, depende de toda la clave
y no de ningún subconjunto de ella. Se pretende garantizar una correcta elección de
claves y eliminar redundancias. Si la clave están formada por un único atributo entonces
ese esquema estará seguro en segunda forma normal.

FN3. Si FN2 y cada atributo no primo de la tabla no depende funcionalmente de forma

transitiva de la clave primaria.FNBC (Forma Normal de Boyce-Codd). Se basa en el
concepto de determinante funcional: uno o varios atributos de una tabla de los cuales
dependen funcionalmente de forma completa algún otro atributo de la misma tabla. Una
relación está en FNBC si FN1 y cada determinante funcional es una clave candidata de la
tabla. Así se garantiza que se han elegido bien las claves al no existir dependencias
funcionales entre atributos que no son clave. Cada vez que se verifica una dependencia
funcional a -> b entonces a es clave primaria o alterna con seguridad. Todas
las dependencias funcionales cumplen que en su parte izquierda solo aparecen atributos
que son parte de una clave candidata. Esta forma normal es más restrictiva que la tercera
y tiene la interesante propiedad de que su cumplimiento implica la satisfacción de FN3 o
sea que FNBC -> FN3. 

Forma norma de boyce-cood(FNCB)

Es una de las formas normales mas deseables que se pueden obtener. Es un esquema de
relación R esta en FNBC respecto a un conjunto de dependencias funcionales F si , para
todas las dependencias funcionales de F+ de la forma α → ß, donde α → R y B→ R, se
cumple al menos una de las siguientes condiciones:

α → es una dependencia funcional trivial α es una superclave del esquema R

Un diseño de base de datos esta en FNBC si cada miembro del conjunto de esquemas de
relación que constituye el diseño esta en FNBC.

Tutoriales. Unidad IV

El proceso de normalización de bases de datos relacionales

La normalización de bases de datos relacionales toma un esquema relacional y le aplica un
conjunto de técnicas para producir un nuevo esquema que representa la misma
información pero contiene menos redundancias y evita posibles anomalías en las
inserciones, actualizaciones y borrados.

Breve recordatorio del modelo (formal) relacional

El modelo relacional de bases de datos se basa en un modelo formal especificado de
acuerdo a la teoría de conjuntos. Una base de datos relacional puede considerarse como
un conjunto de relaciones o tablas de la forma R(A1, ..., An), donde R es el nombre de la
relación, que se define por una serie de atributos Ai.

Sobre las tablas relacionales se pueden definir diferentes restricciones. La integridad de

entidad es una restricción que nos indica que cada entidad representada por una tupla
tiene que ser diferente de las demás en su relación, es decir, debe haber algunos atributos
cuyos valores identifiquen unívocamente las tuplas. La integridad referencial indica que
una clave ajena solo debe contener valores que o bien sean nulos, o bien existan en la
relación referenciada por la clave ajena.

El proceso de normalización
El proceso de normalización consiste en comprobar en secuencia si el esquema original
está en 1FN, 2FN y 3FN, analizando las dependencias funcionales en cada paso.

Un ejemplo completo
Tenemos una empresa pública donde los puestos de trabajo están regulados por el
Estado, de modo que las condiciones salariales están determinadas por el puesto. Se ha
creado el siguiente esquema relacional

EMPLEADOS (nss, nombre, puesto, salario, emails) con nss como clave primaria.

nss nombre puesto salarioemails

111Juan Pérez Jefe de Área 3000 juanp@ecn.es; jefe2@ecn.es

222José SánchezAdministrativo1500 jsanchez@ecn.es

adiaz@ecn.es;
333Ana Díaz Administrativo1500
ana32@gmail.com

... ... ... ... ...

 TABLE 1

Primera forma normal (1FN)

Una tabla está en 1FN si sus atributos contienen valores atómicos. En el ejemplo,
podemos ver que el atributo emails puede contener más de un valor, por lo que viola 1FN.

En general, tenemos una relación R con clave primaria K. Si un atributo M viola la

condición de 1FN, tenemos dos opciones.

Solución 1: duplicar los registros con valores repetidos

En general, esta solución pasa por sustituir R por una nueva relación modificada R', en la
cual:

El atributo M que violaba 1FN se elimina.

Se incluye un nuevo atributo M' que solo puede contener valores simples, de

modo que si R'[M'] es uno de los valores que teníamos en R[M], entonces R'[K] =
R[K]. En otras palabras, para una tupla con n valores duplicados en M, en la nueva
relación habrá n tuplas, que sólo varían en que cada una de ellas guarda uno de los
valores que había en M.

La clave primaria de R' es (K, M'), dado que podrá haber valores de K repetidos,
para los valores multivaluados en M.
Siguiendo el ejemplo, tendríamos el siguiente esquema para la nueva
tabla EMPLEADOS'(a) con clave primaria (nss, email):
nss nombre puesto salarioemail

111 Juan Pérez Jefe de Área 3000 juanp@ecn.es

111 Juan Pérez Jefe de Área 3000 jefe2@ecn.es

222 José SánchezAdministrativo1500 jsanchez@ecn.es

333 Ana Díaz Administrativo1500 adiaz@ecn.es

333 Ana Díaz Administrativo1500 ana32@gmail.com

... ... ... ... ...

TABLE 2

Solución 2: separar el atributo que viola 1FN en una tabla

En general, esta solución pasa por:
sustituir R por una nueva relación modificada R' que no contiene el atributo M.

Crear una nueva relación N(K, M'), es decir, una relación con una clave
ajena K referenciando R', junto al atributo M', que es la variante mono-valuada del
atributo M.

La nueva relación N tiene como clave (K, M').

Siguiendo el ejemplo, tendríamos el siguiente esquema para la nueva

tabla EMPLEADOS'(b)

nss nombre puesto salario

111 Juan Pérez Jefe de Área 3000

222 José SánchezAdministrativo1500

333 Ana Díaz Administrativo1500

... ... ... ...

TABLE 3

Y además tendríamos una nueva tabla EMAILS con clave primaria (nss, email):

nss email

111 juanp@ecn.es

111 jefe2@ecn.es

222 jsanchez@ecn.es

333 adiaz@ecn.es

333 ana32@gmail.com

... ...

TABLE 4

Segunda forma normal (2FN)

Un esquema está en 2FN si:

Está en 1FN.

Todos sus atributos que no son de la clave principal tienen dependencia funcional
completa respecto de todas las claves existentes en el esquema. En otras palabras, para
determinar cada atributo no clave se necesita la clave primaria completa, no vale con una
subclave.

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. Por tanto, de las soluciones anteriores, la
tabla EMPLEADOS'(b) está en 1FN (y la tabla EMAILS no tiene atributos no clave), por lo
que el esquema está en 2FN. Sin embargo, tenemos que examinar las dependencias
funcionales de los atributos no clave de EMPLEADOS'(a). Las dependencias funcionales
que tenemos son las siguientes:

nss->nombre, salario, email

puesto->salario

Como la clave es (nss, email), las dependencias de nombre, salario y email

son incompletas, por lo que la relación no está en 2FN.

En general, tendremos que observar los atributos no clave que dependan de parte de la
clave.

Para solucionar este problema, tenemos que hacer lo siguiente para los gupos de
atributos con dependencia incompleta M:

Eliminar de R el atributo M.

Crear una nueva relación N con el atributo M y la parte de la clave primaria K de la que

depende, que llamaremos K'.

La clave primaria de la nueva relación será K'.

Siguiendo el ejemplo anterior, crearíamos una nueva relación con los atributos que tienen
dependencia incompleta:

nss nombre puesto salario

11
Juan Pérez Jefe de Área 3000
1

22
José SánchezAdministrativo1500
2

33
Ana Díaz Administrativo1500
3

... ... ... ...

TABLE 5
Y al eliminar de la tabla original estos atributos nos quedaría:

nss email

11
juanp@ecn.es
1

11
jefe2@ecn.es
1

22
jsanchez@ecn.es
2

33
adiaz@ecn.es
3

33
ana32@gmail.com
3

... ...

TABLE 6

Como vemos, la solución a la que llegamos es la misma que en la otra opción de solución
para el problema de 1FN.

Tercera forma normal (3FN)

Una relación está en tercera forma normal si, y sólo si:

está en 2FN

y, además, cada atributo que no está incluido en la clave primaria no depende

transitivamente de la clave primaria.

Por lo tanto, a partir de un esquema en 2FN, tenemos que buscar dependencias

funcionales entre atributos que no estén en la clave.

En general, tenemos que buscar dependencias transitivas de la clave, es decir, secuencias

de dependencias como la siguiente: K->A y A->B, donde A y B no pertenecen a la clave. La
solución a este tipo de dependencias está en separar en una tabla adicional N el/los
atributos B, y poner como clave primaria de N el atributo que define la transitividad A.

Siguiendo el ejemplo anterior, podemos detectar la siguiente transitividad:

nss->puesto

puesto->salario
Por lo tanto la descomposición sería la siguiente:

nss nombre puesto

11
Juan Pérez Jefe de Área
1

22
José SánchezAdministrativo
2

33
Ana Díaz Administrativo
3

... ... ...

TABLE 7

En la nueva tabla PUESTOS, la clave sería el puesto, que también queda como clave ajena
referenciando la tabla EMPLEADOS. El resto de las tablas quedan como estaban.