Base de Datos

C.T.S.
ÁREA DE INFORMÁTICA - BASE DE DATOS - 3E
BASE DE DATOS
1. INTRODUCCIÓN A LOS CONCEPTOS DE BASES DE DATOS

Todo buen curso necesita empezar con algunos conceptos básicos para el mejor entendimiento del mismo,
por lo tanto empezaremos con las definiciones que involucran a las bases de datos.
• Dato: Conjunto de caracteres con algún significado, pueden ser numéricos, alfabéticos, o
alfanuméricos.
• Información: Es un conjunto ordenado de datos los cuales son manejados según la necesidad del
usuario, para que un conjunto de datos pueda ser procesado eficientemente y pueda dar lugar a
información, primero se debe guardar lógicamente en archivos.
Conceptos básicos de archivos computacionales.
• Campo: Es la unidad más pequeña a la cual uno puede referirse en un programa. Desde el punto de
vista del programador representa una característica de un individuo u objeto.
• Registro: Colección de campos de iguales o de diferentes tipos.
• Archivo: Colección de registros almacenados siguiendo una estructura homogénea.
• Base de datos: Es una colección de archivos interrelacionados, son creados con un DBMS. El
contenido de una base de datos engloba a la información concerniente (almacenadas en archivos) de
una organización, de tal manera que los datos estén disponibles para los usuarios, una finalidad de la
base de datos es eliminar la redundancia o al menos minimizarla. Los tres componentes principales
de un sistema de base de datos son el hardware, el software DBMS y los datos a manejar, así como
el personal encargado del manejo del sistema.
1.1. SISTEMA MANEJADOR DE BASE DE DATOS. (DBMS)
Un DBMS es una colección de numerosas rutinas de software interrelacionadas, cada una de las cuales es
responsable de una tarea específica.
El objetivo primordial de un sistema manejador base de datos es proporcionar un contorno que sea a la vez
conveniente y eficiente para ser utilizado al extraer, almacenar y manipular información de la base de datos.
Todas las peticiones de acceso a la base, se manejan centralizadamente por medio del DBMS, por lo que este
paquete funciona como interface entre los usuarios y la base de datos.
Esquema de base de datos:
Es la estructura por la que está formada la base de datos, se especifica por medio de un conjunto de
definiciones que se expresa mediante un lenguaje especial llamado lenguaje de definición de datos. (DDL).
Administrador de base de datos (DBA):
Es la persona o equipo de personas profesionales responsables del control y manejo del sistema de base de
datos, generalmente tiene(n) experiencia en DBMS, diseño de bases de datos, Sistemas operativos,
comunicación de datos, hardware y programación.
Los sistemas de base de datos se diseñan para manejar grandes cantidades de información, la manipulación
de los datos involucra tanto la definición de estructuras para el almacenamiento de la información como la
provisión de mecanismos para la manipulación de la información, además un sistema de base de datos debe
de tener implementados mecanismos de seguridad que garanticen la integridad de la información, a pesar de
caídas del sistema o intentos de accesos no autorizados.
Pag. 1
C.T.S. ÁREA DE INFORMÁTICA - BASE DE DATOS - 3E
Un objetivo principal de un sistema de base de datos es proporcionar a los usuarios finales una visión
abstracta de los datos, esto se logra escondiendo ciertos detalles de cómo se almacenan y mantienen los
datos.
1.2. OBJETIVOS DE LOS SISTEMAS DE BASES DE DATOS.
Los objetivos principales de un sistema de base de datos es disminuir los siguientes aspectos:
Redundancia e inconsistencia de datos.
Puesto que los archivos que mantienen almacenada la información son creados por diferentes tipos de
programas de aplicación existe la posibilidad de que si no se controla detalladamente el almacenamiento, se
pueda originar un duplicado de información, es decir que la misma información sea más de una vez en un
dispositivo de almacenamiento. Esto aumenta los costos de almacenamiento y acceso a los datos, además de
que puede originar la inconsistencia de los datos - es decir diversas copias de un mismo dato no concuerdan
entre si -, por ejemplo: que se actualiza la dirección de un cliente en un archivo y que en otros archivos
permanezca la anterior.
Dificultad para tener acceso a los datos.

Un sistema de base de datos debe contemplar un entorno de datos que le facilite al usuario el manejo de los
mismos. Supóngase un banco, y que uno de los gerentes necesita averiguar los nombres de todos los clientes
que viven dentro del código postal 78733 de la ciudad. El gerente pide al departamento de procesamiento de
datos que genere la lista correspondiente. Puesto que esta situación no fue prevista en el diseño del sistema,
no existe ninguna aplicación de consulta que permita este tipo de solicitud, esto ocasiona una deficiencia del
sistema.
Aislamiento de los datos.

Puesto que los datos están repartidos en varios archivos, y estos no pueden tener diferentes formatos, es
difícil escribir nuevos programas de aplicación para obtener los datos apropiados.
Anomalías del acceso concurrente.

Para mejorar el funcionamiento global del sistema y obtener un tiempo de respuesta más rápido, muchos
sistemas permiten que múltiples usuarios actualicen los datos simultáneamente. En un entorno así la
interacción de actualizaciones concurrentes puede dar por resultado datos inconsistentes. Para prevenir esta
posibilidad debe mantenerse alguna forma de supervisión en el sistema.
Problemas de seguridad.
La información de toda empresa es importante, aunque unos datos lo son más que otros, por tal motivo se
debe considerar el control de acceso a los mismos, no todos los usuarios pueden visualizar alguna
información, por tal motivo para que un sistema de base de datos sea confiable debe mantener un grado de
seguridad que garantice la autentificación y protección de los datos. En un banco por ejemplo, el personal de
nóminas sólo necesita ver la parte de la base de datos que tiene información acerca de los distintos
empleados del banco y no a otro tipo de información.
Problemas de integridad.
Los valores de datos almacenados en la base de datos deben satisfacer cierto tipo de restricciones de
consistencia. Estas restricciones se hacen cumplir en el sistema añadiendo códigos apropiados en los diversos
programas de aplicación.
Pag. 2
2. MODELOS DE DATOS
Para introducirnos en este tema, empezaremos definiendo que es un modelo.
Modelo
Es una representación de la realidad que contiene las características generales de algo que se va a realizar. En
base de datos, esta representación la elaboramos de forma gráfica.
¿Qué es modelo de datos?

Es una colección de herramientas conceptuales para describir los datos, las relaciones que existen entre ellos,
semántica asociada a los datos y restricciones de consistencia.
• Los modelos de datos se dividen en tres grupos:

• Modelos lógicos basados en objetos.
• Modelos lógicos basados en registros.
• Modelos físicos de datos.
2.1. MODELOS LÓGICOS BASADOS EN OBJETOS.
Se usan para describir datos en los niveles conceptual y de visión, es decir, con este modelo representamos
los datos de tal forma como nosotros los captamos en el mundo real, tienen una capacidad de estructuración
bastante flexible y permiten especificar restricciones de datos explícitamente. Existen diferentes modelos de
este tipo, pero el más utilizado por su sencillez y eficiencia es el modelo Entidad-Relación.
2.1.1. MODELO ENTIDAD-RELACIÓN.
El modelo E-R se basa en una percepción del mundo real, la cual está formada por objetos básicos llamados
entidades y las relaciones entre estos objetos así como las características de estos objetos llamados atributos.
2.1.1.1. Entidades y conjunto de entidades
Una entidad es un objeto que existe y se distingue de otros objetos de acuerdo a sus características llamadas
atributos. Las entidades pueden ser concretas como una persona o abstractas como una fecha.
Un conjunto de entidades es un grupo de entidades del mismo tipo. Por ejemplo el conjunto de entidades
CUENTA, podría representar al conjunto de cuentas de un banco X, o ALUMNO representa a un conjunto
de entidades de todos los alumnos que existen en una institución.
Una entidad se caracteriza y distingue de otra por los atributos, en ocasiones llamadas propiedades, que
representan las características de una entidad. Los atributos de una entidad pueden tomar un conjunto de
valores permitidos al que se le conoce como dominio del atributo. Así cada entidad se describe por medio de
un conjunto de parejas formadas por el atributo y el valor de dato. Habrá una pareja para cada atributo del
conjunto de entidades.
Ejemplo:
Hacer una descripción en pareja para la entidad alumno con los atributos No_control, Nombre y
Especialidad.
Nombre_atributo Valor
No_control 96310418
Nombre Sánchez Osuna Ana
Esp LI
Pag. 3
O considerando el ejemplo del Vendedor cuyos atributos son: RFC, Nombre, Salario.
Nombre_atributo Valor
RFC COMD741101YHR
Nombre Daniel Colín Morales
Salario 3000
2.1.1.2. Relaciones y conjunto de relaciones.
Una relación es la asociación que existe entre dos a más entidades.
Un conjunto de relaciones es un grupo de relaciones del mismo tipo.
La cantidad de entidades en una relación determina el grado de la relación, por ejemplo la relación
ALUMNO-MATERIA es de grado 2, ya que intervienen la entidad ALUMNO y la entidad MATERIA, la
relación PADRES, puede ser de grado 3, ya que involucra las entidades PADRE, MADRE e HIJO.
Aunque el modelo E-R permite relaciones de cualquier grado, la mayoría de las aplicaciones del modelo sólo
consideran relaciones del grado 2. Cuando son de tal tipo, se denominan relaciones binarias.
La función que tiene una relación se llama papel, generalmente no se especifican los papeles o roles, a menos
que se quiera aclarar el significado de una relación.
Diagrama E-R (sin considerar los atributos, sólo las entidades) para los modelos ejemplificados:
Existen 4 tipos de relaciones que pueden establecerse entre entidades, las cuales establecen con cuantas
entidades de tipo B se pueden relacionar una entidad de tipo A:
Pag. 4
2.1.1.3. Tipos de relaciones:
a) Relación uno a uno.
Se presenta cuando existe una relación como su nombre lo indica uno a uno, denominado también relación
de matrimonio. Una entidad del tipo A solo se puede relacionar con una entidad del tipo B, y viceversa.
Por ejemplo: la relación asignación de automóvil que contiene a las entidades EMPLEADO, AUTO, es una
relación 1 a 1, ya que asocia a un empleado con un único automóvil por lo tanto ningún empleado posee más
de un automóvil asignado, y ningún vehículo se asigna a más de un trabajador.
Es representado gráficamente de la siguiente manera:
A: Representa a una entidad de cualquier tipo diferente a una entidad B.

R: en el diagrama representa a la relación que existe entre las entidades.
El extremo de la flecha que se encuentra punteada indica el uno de la relación, en este caso, una entidad A
ligada a una entidad B.
b) Relación uno a muchos.
Significa que una entidad del tipo A puede relacionarse con cualquier cantidad de entidades del tipo B, y una
entidad del tipo B solo puede estar relacionada con una entidad del tipo A.
Su representación gráfica es la siguiente:
Nótese en este caso que el extremo punteado de la flecha de la relación de A y B, indica una entidad A
conectada a muchas entidades B.
Pag. 5
c) Muchos a uno.
Indica que una entidad del tipo B puede relacionarse con cualquier cantidad de entidades del tipo A, mientras
que cada entidad del tipo A solo puede relacionarse con solo una entidad del tipo B.
d) Muchas a muchas.
Establece que cualquier cantidad de entidades del tipo A pueden estar relacionados con cualquier cantidad de
entidades del tipo B.
A los tipos de relaciones antes descritos, también se le conoce como cardinalidad.
La cardinalidad nos especifica los tipos de relaciones que existen entre las entidades en el modelo E-R y
establecer con esto las validaciones necesarias para conseguir que los datos de la instancia (valor único en un
momento dado de una base de datos) correspondan con la realidad.
Algunos ejemplos de cardinalidades de la vida común pueden ser:
Uno a uno.
La cédula de cada persona, El acta de nacimiento, ya que solo existe un solo documento de este tipo para
cada una de las diferentes personas.
Uno a muchos.
Cliente – Cuenta en un banco, Padre-Hijos, Camión-Pasajeros, zoológico- animales, árbol – hojas.
Muchos a muchos.
Arquitecto – proyectos, fiesta – personas, estudiante – materias.
NOTA: Cabe mencionar que la cardinalidad para cada conjunto de entidades depende del punto de vista
que se le dé al modelo en estudio, claro está, sujetándose a la realidad.
Pag. 6
Otra clase de limitantes lo constituye la dependencia de existencia.
Refiriéndonos a las mismas entidades A y B, decimos que si la entidad A depende de la existencia de la

entidad B, entonces A es dependiente de existencia por B, si eliminamos a B tendríamos que eliminar por
consecuente la entidad A, en este caso B es la entidad Dominante y A es la entidad subordinada.
2.1.1.4. Llaves primarias.
Como ya se ha mencionado anteriormente, la distinción de una entidad entre otra se debe a sus atributos, lo
cual lo hacen único. Una llave primaria es aquel atributo el cual consideramos clave para la identificación de
los demás atributos que describen a la entidad. Por ejemplo, si consideramos la entidad ALUMNO del
Instituto Tecnológico de La Paz, podríamos tener los siguientes atributos: Nombre, Semestre, Especialidad,
Dirección, Teléfono, Número de control, de todos estos atributos el que podremos designar como llave
primaria es el número de control, ya que es diferente para cada alumno y este nos identifica en la institución.
Claro que puede haber más de un atributo que pueda identificarse como llave primaria en este caso se
selecciona la que consideremos más importante, los demás atributos son denominados llaves secundarias.
Una clave o llave primaria es indicada gráficamente en el modelo E-R con una línea debajo del nombre del
atributo.
2.1.1.5. Diagrama Entidad-Relación
Denominado por sus siglas como: E-R; Este modelo representa a la realidad a través de un esquema gráfico
empleando los terminología de entidades, que son objetos que existen y son los elementos principales que se
identifican en el problema a resolver con el diagramado y se distinguen de otros por sus características
particulares denominadas atributos, el enlace que rige la unión de las entidades está representada por la
relación del modelo.
Recordemos que un rectángulo nos representa a las entidades; una elipse a los atributos de las
entidades, y una etiqueta dentro de un rombo nos indica la relación que existe entre las entidades,
destacando con líneas las uniones de estas y que la llave primaria de una entidad es aquel atributo que
se encuentra subrayado.
A continuación mostraremos algunos ejemplos de modelos E-R, considerando las cardinalidades que existen
entre ellos:
Relación Uno a Uno.
Problema:
Diseñar el modelo E-R, para la relación Registro de automóvil que consiste en obtener la tarjeta de
circulación de un automóvil con los siguientes datos:
Automóvil: Modelo, Placas, Color
Tarjeta de circulación: Propietario, No_serie, Tipo.
Pag. 7
Indicamos con este ejemplo que existe una relación de pertenencia de uno a uno, ya que existe una tarjeta de
circulación registrada por cada automóvil.
En este ejemplo, representamos que existe un solo presidente para cada país.
Relación uno a muchos.
El siguiente ejemplo indica que un cliente puede tener muchas cuentas, pero que una cuenta puede
llegar a pertenecer a un solo cliente (Decimos puede, ya que existen cuentas registradas a favor de más de
una persona).
2.1.1.6. Reducción de diagramas E-R a tablas
Un diagrama E-R, puede ser representado también a través de una colección de tablas. Para cada una de las
entidades y relaciones existe una tabla única a la que se le asigna como nombre el del conjunto de entidades
y de las relaciones respectivamente, cada tabla tiene un número de columnas que son definidas por la
cantidad de atributos y las cuales tienen el nombre del atributo.
La transformación de nuestro ejemplo Venta en la que intervienen las entidades de Vendedor con los
atributos RFC, nombre, puesto, salario y Artículo con los atributos Clave, descripción, costo.
Cuyo diagrama E-R es el siguiente:
Entonces las tablas resultantes siguiendo la descripción anterior son:

Pag. 8
Tabla Empleado
Nombre Puesto Salario RFC

Teófilo Vendedor 2000 TEAT701210XYZ
Cesar Auxiliar ventas 1200 COV741120ABC
Tabla artículo
Clave Descripción Costo

A100 Abanico 460
C260 Colcha matrimonial 1200
Tabla Venta
RFC Clave
TEAT701210XYZ C260
COV741120ABC A100
Nótese que en la tabla de relación - Venta -, contiene como atributos a las llaves primarias de las entidades
que intervienen en dicha relación, en caso de que exista un atributo en las relaciones, este atributo es anexado
como una fila más de la tabla;
Por ejemplo si anexamos el atributo fecha a la relación venta, la tabla que se originaría sería la siguiente:
RFC Clave Fecha

TEAT701210XYZ C260 10/12/96
COV741120ABC A100 11/12/96
2.1.1.7. Generalización y especialización, Agregación
a) Generalización.
Es el resultado de la unión de 2 o más conjuntos de entidades (de bajo nivel) para producir un conjunto de
entidades de más alto nivel. La generalización se usa para hacer resaltar los parecidos entre tipos de
entidades de nivel más bajo y ocultar sus diferencias.
La generalización consiste en identificar todos aquellos atributos iguales de un conjunto de entidades para
formar una entidad(es) global(es) con dichos atributos semejantes, dicha entidad(es) global(es) quedara a un
nivel más alto al de las entidades origen.
Pag. 9
Ejemplo:
Tomando el ejemplo del libro de fundamentos de base de datos de Henry F. Korth.
Donde:
Se tiene las entidades Cta_Ahorro y Cta_Cheques, ambas tienen los atributos semejantes de No_Cta y Saldo,
aunque además de estos dos atributos, Cta_Ahorro tiene el atributo Tasa_Interes y Cta_Cheques el atributo
Saldo_Deudor. De todos estos atributos podemos juntar (generalizar) No_Cta y Saldo que son iguales en
ambas entidades.
Entonces tenemos:
Podemos leer esta gráfica como: La entidad Cta_Ahorro hereda de la entidad CUENTA los atributos No_Cta
y saldo, además del atributo de TasaInteres, de forma semejante Cta_cheque tiene los atributos de No_Cta,
Saldo y SaldoDeudor.
Como podemos observar la Generalización trata de eliminar la redundancia (repetición) de atributos, al

englobar los atributos semejantes. La entidad(es) de bajo nivel cuentan (heredan) todos los atributos
correspondientes.
b) Especialización:
Es el resultado de tomar un subconjunto de entidades de alto nivel para formar un conjunto de entidades de
más bajo nivel.
• En la generalización cada entidad de alto nivel debe ser también una entidad de bajo nivel. La
especialización no tiene este limitante.
• Se representa por medio de un triángulo denominado con la etiqueta "ISA", se distingue de la
generalización por el grosor de las líneas que conectan al triángulo con las entidades.
• La especialización denota la diferencia entre los conjuntos de entidades de alto y bajo nivel.
Pag. 10
c) Agregación.
La agregación surge de la limitación que existe en el modelado de E-R, al no permitir expresar las relaciones
entre relaciones de un modelo E-R en el caso de que una relación X se quiera unir con una entidad cualquiera
para formar otra relación.
La Generalización consiste en agrupar por medio de un rectángulo a la relación (representada por un rombo)
junto con las entidades y atributos involucrados en ella, para formar un grupo que es considerado una entidad
y ahora sí podemos relacionarla con otra entidad.
Para ejemplificar lo anterior consideremos el ejemplo del libro de fundamentos de Base de Datos de Henry
F. Korth. En donde el problema consiste en que existen trabajando muchos empleados que trabajan en
diferentes proyectos, pero dependiendo del trabajo que realiza en pueden llegar a utilizar un equipo o
maquinaria; en este problema intervienen 3 entidades: Empleado, Proyecto y Maquinaria, el diagrama E-R
correspondiente es:
Como el modelo E-R no permite la unión entre dos o más relaciones, la relación trabajo es englobada
como si fuera una entidad más de la relación usa, gráficamente queda como:
Pag. 11
Ahora podemos decir que la entidad trabajo se relaciona con la entidad maquinaria a través de la relación
usar. Para indicarnos que un trabajo usa un determinado equipo o maquinaria según el tipo de trabajo que se
trate
2.2. MODELOS LÓGICOS BASADOS EN REGISTROS.
Se utilizan para describir datos en los niveles conceptual y físico.
Estos modelos utilizan registros e instancias para representar la realidad, así como las relaciones que existen
entre estos registros (ligas) o apuntadores. A diferencia de los modelos de datos basados en objetos, se usan
para especificar la estructura lógica global de la base de datos y para proporcionar una descripción a nivel
más alto de la implementación.
Los tres modelos de datos más ampliamente aceptados son:
• Modelo Relacional
• Modelo de Red
• Modelo Jerárquico
2.2.1. MODELO RELACIONAL
La ventaja del modelo relacional es que los datos se almacenan, al menos conceptualmente, de un modo en
que los usuarios entienden con mayor facilidad. Los datos se almacenan como tablas y las relaciones entre
las filas y las tablas son visibles en los datos. Este enfoque permite a los usuarios obtener información de la
base de datos sin asistencia de sistemas profesionales de administración de información.
Las características más importantes de los modelos relacionales son:
a. Es importante saber que las entradas en la tabla tienen un solo valor (son atómicos); no se admiten
valores múltiples, por lo tanto la intersección de un renglón con una columna tiene un solo valor,
nunca un conjunto de valores.
b. Todas las entradas de cualquier columna son de un solo tipo. Por ejemplo, una columna puede
contener nombres de clientes, y en otra puede tener fechas de nacimiento. Cada columna posee un
Pag. 12
nombre único, el orden de las comunas no es de importancia para la tabla, las columnas de una tabla
se conocen como atributos. Cada atributo tiene un dominio, que es una descripción física y lógica de
valores permitidos.
c. No existen 2 filas en la tabla que sean idénticas.
d. La información en las bases de datos son representados como datos explícitos, no existen
apuntadores o ligas entre las tablas.
En el enfoque relacional es sustancialmente distinto de otros enfoques en términos de sus estructuras lógicas
y del modo de las operaciones de entrada/salida. En el enfoque relacional, los datos se organizan en tablas
llamadas relaciones, cada una de las cuales se implanta como un archivo. En terminología relacional una fila
en una relación representa un registro o una entidad; Cada columna en una relación representa un campo o
un atributo.
Así, una relación se compone de una colección de entidades(o registros) cuyos propietarios están descritos
por cierto número de atributos predeterminados implantados como campos.
2.2.1.1. Estructura de las bases de datos relacionales
La arquitectura relacional se puede expresar en términos de tres niveles de abstracción: nivel interno,
conceptual y de visión.
La arquitectura relacional consta de los siguientes componentes:
1. Modelo relacional de datos:
En el nivel conceptual, el modelo relacional de datos está representado por una colección de
relaciones almacenadas. Cada registro de tipo conceptual en un modelo relacional de datos se
implanta como un archivo almacenado distinto.
2. Submodelo de datos:
Los esquemas externos de un sistema relacional se llaman submodelos relacionales de datos; cada
uno consta de uno a más escenarios (vistas) para describir los datos requeridos por una aplicación
dada. Un escenario puede incluir datos de una o más tablas de datos. Cada programa de aplicación
está provisto de un buffer ("Area de trabajo de usuario") donde el DBMS puede depositar los datos
recuperados de la base para su procesamiento, o puede guardar temporalmente sus salidas antes de
que el DBMS las escriba en la base de datos.
3. Esquema de almacenamiento:
En el nivel interno, cada tabla base se implanta como un archivo almacenado. Para las
recuperaciones sobre las claves principal o secundaria se pueden establecer uno o más índices para
accesar un archivo almacenado.
4. Sublenguaje de datos:
Es un lenguaje de manejo de datos para el sistema relacional, el álgebra relacional y cálculo

relacional, ambos lenguajes son "relacionalmente completos", esto es, cualquier relación que pueda
derivarse de una o más tablas de datos, también se puede derivar con u solo comando del
sublenguaje. Por tanto, el modo de operación de entrada/Salida en un sistema relacional se puede
procesar en la forma: una tabla a la vez en lugar de: un registro a la vez; en otras palabras, se puede
recuperar una tabla en vez de un solo registro con la ejecución de un comando del sublenguaje de
datos.
Pag. 13
3. NORMALIZACIÓN
3.1. Terminología relacional equivalente
En la figura anterior se muestra al tabla Trabajo (Código, Nombre, Posición, Salario), donde Código es la
Clave Primaria
• Relación = tabla o archivo

• Tupla = registro, fila o renglón
• Atributo = campo o columna
• Clave = llave o código de identificación
• Clave Candidata = superclave mínima
• Clave Primaria = clave candidata elegida
• Clave Ajena = clave externa o clave foránea
• Clave Alternativa = clave secundaria
• Dependencia Multivaluada = dependencia multivalor
• RDBMS = Del inglés Relational Data Base Manager System que significa, Sistema Gestor de Bases
de Datos Relacionales.
• 1FN = Significa, Primera Forma Normal o 1NF del inglés First Normal Form.
Los términos Relación, Tupla y Atributo derivan de las matemáticas relacionales, que constituyen la fuente
teórica del modelo de base de datos relacional.
Todo atributo en una tabla tiene un dominio, el cual representa el conjunto de valores que el mismo puede
tomar. Una instancia de una tabla puede verse entonces como un subconjunto del producto cartesiano entre
los dominios de los atributos. Sin embargo, suele haber algunas diferencias con la analogía matemática, dado
que algunos RDBMS permiten filas duplicadas, entre otras cosas. Finalmente, una tupla puede razonarse
matemáticamente como un elemento del producto cartesiano entre los dominios.
3.2. Dependencia
3.2.1. Dependencia funcional
B es funcionalmente dependiente de A.
Una dependencia funcional es una conexión entre uno o más atributos. Por ejemplo si conocemos el valor de
FechaDeNacimiento podemos conocer el valor de Edad.
Pag. 14
Las dependencias funcionales del sistema se escriben utilizando una flecha, de la siguiente manera:
FechaDeNacimiento Edad
Aquí a FechaDeNacimiento se le conoce como un determinante. Se puede leer de dos formas

FechaDeNacimiento determina a Edad o Edad es funcionalmente dependiente de FechaDeNacimiento. De la
normalización (lógica) a la implementación (física o real) puede ser sugerible tener éstas dependencias
funcionales para lograr mayor eficiencia en las tablas.
3.2.1.1. Propiedades de la Dependencia funcional
Existen 3 axiomas de Armstong:
a) Dependencia funcional Reflexiva
Si y está incluido en x entonces
Si la dirección o el nombre de una persona están incluidos en el dni, entonces con el dni podemos determinar
la dirección o su nombre.
b) Dependencia funcional Aumentativa
Entonces
dni nombre
dni, dirección nombre, dirección
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 o su dirección.
c) Dependencia funcional transitiva
Sean X, Y, Z tres atributos (o grupos de atributos) de la misma entidad. Si Y depende funcionalmente de X y Z

de Y, pero X no depende funcionalmente de Y, se dice que Z depende transitivamente de X. Simbólicamente
sería:
X ---> Y ---> Z entonces X ---> Z FechaDeNacimiento Edad
Edad Conducir
FechaDeNacimiento Edad Conducir
Entonces tenemos que FechaDeNacimiento determina a Edad y la Edad determina a Conducir,

indirectamente podemos saber a través de FechaDeNacimiento a Conducir (En muchos países, para una
persona poder conducir un automóvil la persona necesita ser mayor de cierta edad, por eso se utiliza este
ejemplo).
Pag. 15
3.2.1.2. Propiedades deducidas
a) Union
y entonces
b) Pseudo-transitiva
y entonces
c) Descomposición
y z está incluido en y entonces
3.3. Claves
Una clave primaria es aquella columna (pueden ser también dos columnas o más) que identifica únicamente
a esa fila. La clave primaria es un identificador que va a ser único para cada fila. Se acostumbra poner la
clave primaria como la primera columna de la tabla pero esto no tiene que ser necesario, si no es más una
conveniencia. Muchas veces la clave primaria es autonumérica.
En una tabla puede que tengamos más de una clave, en tal caso se puede escoger una para ser la clave
primaria, las demás claves son las claves candidatas, además es la posible clave primaria.
Una clave foránea es aquella columna que existiendo como dependiente en una tabla, es a su vez clave
primaria en otra tabla.
Una clave alternativa es aquella clave candidata que no ha sido seleccionada como clave primaria, pero que
también puede identificar de forma única a una fila dentro de una tabla. Ejemplo: Si en un tabla clientes
definimos id_cliente como clave primaria el número de documento o seguro social de ese cliente podría ser
una clave alternativa. En este caso no se usó como clave primaria porque es posible que no se conozca ese
dato en todos los clientes.
Una clave compuesta es una clave que está compuesta por más de una columna.
3.4. Formas Normales
Las formas normales son aplicadas a las tablas de una base de datos. Decir que una base de datos está en la
forma normal N es decir que todas sus tablas están en la forma normal N.
En general, las primeras tres formas normales son suficientes para cubrir las necesidades de la mayoría de las
bases de datos. El creador de estas 3 primeras formas normales (o reglas) fue Edgar F. Codd.
Pag. 16
3.4.1. Primera Forma Normal (1FN)
Una tabla está en Primera Forma Normal sólo si
• Todos los atributos son atómicos. Un atributo es atómico si los elementos del dominio son
indivisibles, mínimos.
• La tabla contiene una clave primaria
• La tabla no contiene atributos nulos
• Si no posee ciclos repetitivos
Una columna no puede tener múltiples valores. Los datos son atómicos. (Si a cada valor de X le pertenece un
valor de Y, entonces a cada valor de Y le pertenece un valor de X)....
La primera forma normal (1NF o forma mínima) es una forma normal usada en normalización de bases de
datos. Una tabla de base de datos relacional que se adhiere a la 1NF es una que satisface cierto conjunto
mínimo de criterios. Estos criterios se refieren básicamente a asegurarse que la tabla es una representación
fiel de una relación y está libre de "grupos repetitivos".
Sin embargo, el concepto de "grupo repetitivo", es entendido de diversas maneras por diferentes teóricos.
Como una consecuencia, no hay un acuerdo universal en cuanto a qué características descalificarían a una
tabla de estar en 1NF. Muy notablemente, la 1NF, tal y como es definida por algunos autores excluye
"atributos relación-valor" (tablas dentro de tablas) siguiendo el precedente establecido por E.F. Codd)
(algunos de esos autores son: Ramez Elmasri y Shamkant B. Navathe). Por otro lado, según lo definido por
otros autores, la 1NF sí los permite (por ejemplo como la define Chris Date).
3.4.1.1. Las tablas 1NF como representaciones de relaciones
Según la definición de Date de la 1NF, una tabla está en 1NF si y solo si es "isomorfa a alguna relación", lo
que significa, específicamente, que satisface las siguientes cinco condiciones:
• No hay orden de arriba-a-abajo en las filas.

• No hay orden de izquierda-a-derecha en las columnas.
• No hay filas duplicadas.
• Cada intersección de fila-y-columna contiene exactamente un valor del dominio aplicable (y nada
más).
• Todas las columnas son regulares [es decir, las filas no tienen componentes como IDs de fila, IDs de
objeto, o timestamps ocultos].
La violación de cualquiera de estas condiciones significaría que la tabla no es estrictamente relacional, y por
lo tanto no está en 1NF. Algunos ejemplos de tablas (o de vistas) que no satisface esta definición de 1NF
son:
• Una tabla que carece de una clave primaria. Esta tabla podría acomodar filas duplicadas, en violación
de la condición 3.
• Una vista cuya definición exige que los resultados sean retornados en un orden particular, de modo
que el orden de la fila sea un aspecto intrínseco y significativo de la vista. Esto viola la condición 1.
Las tuplas en relaciones verdaderas no están ordenadas una con respecto de la otra.
• Una tabla con por lo menos un atributo que pueda ser nulo. Un atributo que pueda ser nulo estaría en
violación de la condición 4, que requiere a cada campo contener exactamente un valor de su dominio
de columna. Sin embargo, debe ser observado que este aspecto de la condición 4 es controvertido.
Muchos autores consideran que una tabla está en 1FN si ninguna clave candidata puede contener
valores nulos, pero se aceptan éstos para atributos (campos) que no sean clave, según el modelo
original de Codd sobre el modelo relacional, el cual hizo disposición explícita para los nulos.
Pag. 17
3.4.1.2. Grupos repetidos
La cuarta condición de Date, que expresa "lo que la mayoría de la gente piensa como la característica que
define la 1NF", concierne a grupos repetidos. El siguiente ejemplo ilustra cómo un diseño de base de datos
puede incorporar la repetición de grupos, en violación de la 1NF.
Ejemplo 1: Dominios y valores
Suponga que un diseñador principiante desea guardar los nombres y los números telefónicos de los clientes.
Procede a definir una tabla de cliente como la que sigue:
Cliente
ID Cliente Nombre Apellido Teléfono
123 Rachel Ingram 555-861-2025
456 James Wright 555-403-1659
789 María Fernández 555-808-9633
En este punto, el diseñador se da cuenta de un requisito debe guardar múltiples números telefónicos para
algunos clientes. Razona que la manera más simple de hacer esto es permitir que el campo "Teléfono"
contenga más de un valor en cualquier registro dado:
Cliente
555-403-1659
456 James Wright
555-776-4100
Asumiendo, sin embargo, que la columna "Teléfono" está definida en algún tipo de dominio de número
telefónico (por ejemplo, el dominio de cadenas de 12 caracteres de longitud), la representación de arriba no
está en 1NF. La 1NF (y, para esa materia, el RDBMS) prohíbe a un campo contener más de un valor de su
dominio de columna.
Ejemplo 2: Grupos repetidos a través de columnas
El diseñador puede evitar esta restricción definiendo múltiples columnas del número telefónico:
Cliente
ID Cliente Nombre Apellido Teléfono 1 Teléfono 2 Teléfono 3
123 Osvaldo Ingram 555-861-2025
456 James Wright 555-403-1659 555-776-4100
789 Maria Fernandez 555-808-9633
Sin embargo, esta representación hace uso de columnas que permiten valores nulos, y por lo tanto no se
conforman con la definición de la 1NF de Date. Incluso si se contempla la posibilidad de columnas con
valores nulos, el diseño no está en armonía con el espíritu de 1NF. Teléfono 1, Teléfono 2, y Teléfono 3,
comparten exactamente el mismo dominio y exactamente el mismo significado; el dividir del número de
teléfono en tres encabezados es artificial y causa problemas lógicos. Estos problemas incluyen:
Pag. 18
• Dificultad en hacer consultas a la tabla. Es difícil contestar preguntas tales como "¿Qué clientes
tienen el teléfono X?" y "¿Qué pares de clientes comparten un número de teléfono?".
• La imposibilidad de hacer cumplir la unicidad los enlaces Cliente-a-Teléfono por medio del
RDBMS. Al cliente 789 se le puede dar equivocadamente un valor para el Teléfono 2 que es
exactamente igual que el valor de su Teléfono 1.
• La restricción de los números de teléfono por cliente a tres. Si viene un cliente con cuatro números
de teléfono, estamos obligados a guardar solamente tres y dejar el cuarto sin guardar. Esto significa
que el diseño de la base de datos está imponiendo restricciones al proceso del negocio, en vez de
(como idealmente debe ser el caso) al revés.
Ejemplo 3: Repetición de grupos dentro de columnas
El diseñador puede, alternativamente, conservar una sola columna de número de teléfono, pero alterando su
dominio, haciendo una cadena de suficiente longitud para acomodar múltiples números telefónicos:
Cliente
456 James Wright 555-403-1659, 555-776-4100
Éste es defendiblemente el peor diseño de todos, y otra vez no mantiene el espíritu de la 1NF. El encabezado
"Teléfono" llega a ser semánticamente difuso, ya que ahora puede representar, o un número de teléfono, o
una lista de números de teléfono, o de hecho cualquier cosa. Una consulta como "¿Qué pares de clientes
comparten un número telefónico?" es virtualmente imposible de formular, dada la necesidad de proveerse de
listas de números telefónicos así como números telefónicos individuales. Con este diseño en la RDBMS, son
también imposibles de definir significativas restricciones en números telefónicos.
Un diseño conforme con 1NF
Un diseño que está inequívocamente en 1NF hace uso de dos tablas: una tabla de cliente y una tabla de
teléfono del cliente.
Cliente
ID Cliente Nombre Apellido
123 Rachel Ingram
456 James Wright
789 María Fernández
Teléfono del cliente

ID Cliente Teléfono
123 555-861-2025
456 555-403-1659
456 555-776-4100
789 555-808-9633
En este diseño no ocurren grupos repetidos de números telefónicos. En lugar de eso, cada enlace Cliente-a-
Teléfono aparece en su propio registro.
Pag. 19
3.4.1.3. Atomicidad
Algunas definiciones de 1NF, más notablemente la de E.F. Codd, hacen referencia al concepto de
atomicidad. Codd indica que "se requiere que los valores sean atómicos con respecto al DBMS en los
dominios en los que cada relación es definida". Codd define un valor atómico como uno que "no puede ser
descompuesto en pedazos más pequeños por el DBMS (excepto ciertas funciones especiales)".
Hugh Darwen y Chris Date han sugerido que el concepto de Codd de un "valor atómico" es ambiguo, y que
esta ambigüedad ha conducido a una extensa confusión sobre cómo debe ser entendida la 1NF. En
particular, la noción de un "valor que no puede ser descompuesto" es problemática, pues parecería implicar
que pocos, si algún, tipos de datos son atómicos:
• Una cadena de caracteres parecería no ser atómica, ya que el RDBMS típicamente proporciona
operadores para descomponerla en subcadenas.
• Una fecha parecería no ser atómica, ya que el RDBMS proporciona típicamente operadores para
descomponerla los componentes de día, mes, y año.
• Un número de punto fijo parecería no ser atómico, ya que el RDBMS proporciona típicamente
operadores para descomponerlo en componentes de números enteros y fraccionarios.
Date sugiere que "la noción de atomicidad no tiene ningún significado absoluto": un valor puede ser
considerado atómico para algunos propósitos, pero puede ser considerado un ensamblaje de elementos más
básicos para otros propósitos. Si esta posición es aceptada, la 1NF no puede ser definida con referencia a la
atomicidad. Las columnas de cualquier tipo de datos concebible (desde tipos de cadenas y tipos numéricos
hasta tipos de arreglos y tipos de tabla) son entonces aceptables en una tabla 1NF - aunque quizás no siempre
deseable. Date discute que los atributos relación-valor, por medio de los cuales un campo dentro de una tabla
puede contener una tabla, son útiles en casos raros.
3.4.2. Segunda Forma Normal (2NF)
Dependencia Funcional. Una relación está en 2FN si está en 1FN y si los atributos que no forman parte de
ninguna clave dependen de forma completa de la clave principal. Es decir que no existen dependencias
parciales.
La segunda forma normal (2NF) es una forma normal usada en normalización de bases de datos. La 2NF
definida originalmente por E.F. Codd en 1971. Una tabla que está en la primera forma normal (1NF) debe
satisfacer criterios adicionales para calificar para la segunda forma normal. Específicamente: una tabla 1NF
está en 2NF si y solo si, dada cualquier clave candidata y cualquier atributo que no sea un constituyente de la
clave candidato, el atributo no clave depende de toda la clave candidata en vez de solo una parte de ella.
En términos levemente más formales: una tabla 1NF está en 2NF si y solo si ninguno de sus atributos no-
principales son funcionalmente dependientes en una parte (subconjunto apropiado) de una clave candidata.
(Un atributo no-principal de A es uno que no pertenece a ninguna clave candidata).
Observe que cuando una tabla 1NF no tiene ninguna clave candidata compuesta (claves candidata
consistiendo en más de un atributo), la tabla está automáticamente en 2NF.
Pag. 20
Ejemplo
Considere una tabla describiendo las habilidades de los empleados:
Habilidades de los empleados

Empleado Habilidad Lugar actual de trabajo
Jones Mecanografía 114 Main Street

Jones Taquigrafía 114 Main Street
Jones Tallado 114 Main Street
Roberts Limpieza ligera 73 Industrial Way
Ellis Alquimia 73 Industrial Way
Ellis Malabarismo 73 Industrial Way
Harrison Limpieza ligera 73 Industrial Way
La única clave candidata de la tabla es {Empleado, Habilidad}.
El atributo restante, Lugar actual de trabajo, es dependiente en solo parte de la clave candidata, llamada
Empleado. Por lo tanto la tabla no está en 2NF. Observe la redundancia de la manera en que son
representadas los Lugares actuales de trabajo: nos dicen tres veces que Jones trabaja en la 114 Main Street, y
dos veces que Ellis trabaja en 73 Industrial Way. Esta redundancia hace a la tabla vulnerable a anomalías de
actualización: por ejemplo, es posible actualizar el lugar del trabajo de Jones en sus registros "Mecanografía"
y "Taquigrafía" y no actualizar su registro "Tallado". Los datos resultantes implicarían respuestas
contradictorias a la pregunta "¿Cuál es el lugar actual de trabajo de Jones?".
Una alternativa 2NF a este diseño representaría la misma información en dos tablas:
Empleados
Empleado Lugar actual de trabajo
Jones 114 Main Street

Roberts 73 Industrial Way
Ellis 73 Industrial Way
Harrison 73 Industrial Way
Habilidades de los empleados

Empleado Habilidad
Jones Mecanografía
Jones Taquigrafía
Jones Tallado
Roberts Limpieza ligera
Ellis Alquimia
Ellis Malabarismo
Harrison Limpieza ligera
Las anomalías de actualización no pueden ocurrir en estas tablas, las cuales están en 2NF.
Sin embargo, no todas las tablas 2NF están libres de anomalías de actualización. Un ejemplo de una tabla
2NF que sufre de anomalías de actualización es:
Pag. 21
Ganadores del torneo

Torneo Año Ganador Fecha de nacimiento del ganador
Des Moines Masters 1998 Chip Masterson 14 de marzo de 1977

Indiana Invitational 1998 Al Fredrickson 21 de julio de 1975
Cleveland Open 1999 Bob Albertson 28 de septiembre de 1968
Des Moines Masters 1999 Al Fredrickson 21 de julio de 1975
Indiana Invitational 1999 Chip Masterson 14 de marzo de 1977
Aunque el Ganador y la Fecha de nacimiento del ganador están determinadas por una clave completa
{Torneo, Año} y no son partes de ella, particularmente las combinaciones Ganador / Fecha de nacimiento
del ganador son mostradas redundantemente en múltiples registros. Este problema es tratado por la tercera
forma normal (3NF).
3.4.2.1. 2NF y las claves candidatas
Una tabla para la cual no hay dependencias funcionales parciales en la clave primaria está típicamente, pero
no siempre, en 2NF. Además de la clave principal, la tabla puede contener otras claves candidatas; es
necesario establecer que ningún atributo no-principal tienen dependencias de clave parciales en cualesquiera
de estas claves candidata.
Las múltiples claves candidata ocurren en la siguiente tabla:
Modelos eléctricos de cepillos de dientes

Fabricante Modelo Nombre completo del modelo País del fabricante
Forte X-Prime Forte X-Prime Italia

Forte Ultraclean Forte Ultraclean Italia
Dent-o-Fresh EZBrush Dent-o-Fresh EZBrush USA
Kobayashi ST-60 Kobayashi ST-60 Japón
Hoch Toothmaster Hoch Toothmaster Alemania
Hoch Contender Hoch Contender Alemania
Aun si el diseñador ha especificado la clave principal como {Nombre completo del modelo}, la tabla no está
en 2NF. {fabricante, modelo} es también una clave candidato, y País del fabricante es dependiente en un
subconjunto apropiado de él: Fabricante.
3.4.3. Tercera Forma Normal (3FN)
La tabla se encuentra en 3FN si es 2FN y cada atributo que no forma parte de ninguna clave, depende
directamente y no transitivamente, de la clave primaria.
La tercera forma normal (3NF) es una forma normal usada en la normalización de bases de datos. La 3NF
fue definida originalmente por E.F. Codd en 1971. La definición de Codd indica que una tabla está en 3NF si
y solo si las dos condiciones siguientes se mantienen:
• La tabla está en la segunda forma normal (2NF)

• Ningún atributo no-primario de la tabla es dependiente transitivamente en una clave candidata
Pag. 22
Un atributo no-primario es un atributo que no pertenece a ninguna clave candidato. Una dependencia
transitiva es una dependencia funcional X → Z en la cual Z no es inmediatamente dependiente de X, pero sí
de un tercer conjunto de atributos Y, que a su vez depende de X.
Es decir, X → Z por virtud de X → Y y Y → Z.
Una formulación alternativa de la definición de Codd, dada por Carlo Zaniolo en 1982, es ésta: Una tabla
está en 3NF si y solo si, para cada una de sus dependencias funcionales X → A, por lo menos una de las
condiciones siguientes se mantiene:
• X contiene A, ó
• X es una superclave, ó
• A es un atributo primario (es decir, A está contenido dentro de una clave candidato)
La definición de Zaniolo tiene la ventaja de dar un claro sentido de la diferencia entre la 3NF y la más
rigurosa forma normal de Boyce-Codd (BCNF). La BCNF simplemente elimina la tercera alternativa ("A es
un atributo primario").
Ejemplo
Un ejemplo de una tabla 2NF que falla en satisfacer los requisitos de la 3NF es:

Torneo Año Ganador Fecha de nacimiento del ganador
Indiana Invitational 1998 Al Fredrickson 21 de julio de 1975

Cleveland Open 1999 Bob Albertson 28 de septiembre de 1968
Des Moines Masters 1999 Al Fredrickson 21 de julio de 1975
Indiana Invitational 1999 Chip Masterson 14 de marzo de 1977
La única clave candidato es {Torneo, Año}.
La violación de la 3NF ocurre porque el atributo no primario Fecha de nacimiento del ganador es
dependiente transitivamente de {Torneo, Año} vía el atributo no primario Ganador. El hecho de que la Fecha
de nacimiento del ganador es funcionalmente dependiente en el Ganador hace la tabla vulnerable a
inconsistencias lógicas, pues no hay nada que impida a la misma persona ser mostrada con diferentes fechas
de nacimiento en diversos registros.
Para expresar los mismos hechos sin violar la 3NF, es necesario dividir la tabla en dos:

Torneo Año Ganador
Indiana Invitational 1998 Al Fredrickson

Cleveland Open 1999 Bob Albertson
Des Moines Masters 1999 Al Fredrickson
Indiana Invitational 1999 Chip Masterson
Fecha de nacimiento del jugador

Jugador Fecha de nacimiento
Chip Masterson 14 de marzo de 1977

Al Fredrickson 21 julio de 1975
Bob Albertson 28 septiembre de 1968
Las anomalías de actualización no pueden ocurrir en estas tablas, las cuales están en 3NF.
Pag. 23
3.4.4. Forma Normal de Boyce-Codd (FNBC)
La tabla se encuentra en BCNF si cada determinante, atributo que determina completamente a otro, es clave
candidata.
La Forma Normal de Boyce-Codd (o FNBC) es una forma normal utilizada en la normalización de bases de
datos. Es una versión ligeramente más fuerte de la Tercera forma normal (3FN). La forma normal de Boyce-
Codd requiere que no existan dependencias funcionales no triviales de los atributos que no sean un conjunto
de la clave candidata. En una tabla en 3FN, todos los atributos dependen de una clave, de la clave completa y
de ninguna otra cosa excepto de la clave (excluyendo dependencias triviales, como). Se dice que una tabla
está en FNBC si y solo si está en 3FN y cada dependencia funcional no trivial tiene una clave candidata
como determinante. En términos menos formales, una tabla está en FNBC si está en 3FN y los únicos
determinantes son claves candidatas.
Ejemplo
Solamente en casos raros una tabla en 3NF no satisface los requerimientos de la BCNF. Un ejemplo de tal
tabla es (teniendo en cuenta que cada estudiante puede tener más de un tutor):
Referencia cruzada de tutor / estudiante

ID Tutor Número de seguro social del tutor ID Estudiante
1078 088-51-0074 31850
1078 088-51-0074 37921
1293 096-77-4146 46224
1480 072-21-2223 31850
El propósito de la tabla es mostrar qué tutores están asignados a qué estudiantes. Las claves candidatas de la
tabla son:
• {ID Tutor, ID Estudiante}

• {Número de seguro social del tutor, ID Estudiante}
Por lo tanto los tres atributos de la tabla son atributos primarios, es decir, los tres atributos pertenecen a las
claves candidatas.
Recuerde que la 2NF prohíbe dependencias funcionales parciales de atributos no-primarios en las claves
candidatas, y la 3NF prohíbe dependencias funcionales transitivas de atributos no-primarios en claves
candidatas. Dado que la tabla de arriba carece de cualquier atributo no-primario, está en 2NF y 3NF.
La FNBC es más rigurosa que la 3NF en que no permite ninguna dependencia funcional en la cual el
conjunto determinante de atributos no sea una clave candidato (o superconjunto de eso). La dependencia de
ID Tutor en Número de seguro social del tutor es ese tipo de dependencia. Por consiguiente, la tabla de arriba
no está en FNBC
Cualquier tabla que sea insuficiente en FNBC será vulnerable a inconsistencias lógicas. En la tabla de arriba
podía ser representada una combinación inconsistente de ID Tutor y Número de seguro social del tutor.
En este caso, corregir el problema sería una simple cuestión de usar solo un esquema de identificación para
los tutores: o el ID, o el número del seguro social, pero no ambos.
Pag. 24
3.4.5. Cuarta Forma Normal (4NF)
La cuarta forma normal (4NF) es una forma normal usada en la normalización de bases de datos. La 4NF se
asegura de que los hechos multivalores independientes estén correcta y eficientemente representados en un
diseño de base de datos. La 4NF es el siguiente nivel de normalización después de la forma normal de
Boyce-Codd (BCNF).
La definición de la 4NF confía en la noción de una dependencia multivalor. Una tabla con una dependencia
multivalor es una donde la existencia de dos o más relaciones independientes muchos a muchos causa
redundancia; y es esta redundancia la que es removida por la cuarta forma normal.
Considere el siguiente ejemplo:
Permutaciones de envío de
Restaurante Variedad de Pizza Área de envío
Vincenzo's Pizza Corteza gruesa Springfield

Vincenzo's Pizza Corteza gruesa Shelbyville
Vincenzo's Pizza Corteza fina Springfield
Vincenzo's Pizza Corteza fina Shelbyville
Elite Pizza Corteza fina Capital City
Elite Pizza Corteza rellena Capital City
A1 Pizza Corteza gruesa Springfield
A1 Pizza Corteza gruesa Shelbyville
A1 Pizza Corteza gruesa Capital City
A1 Pizza Corteza rellena Springfield
A1 Pizza Corteza rellena Shelbyville
A1 Pizza Corteza rellena Capital City
Cada fila indica que un restaurante dado puede entregar una variedad dada de pizza a un área dada.
Note que debido a que la tabla tiene una clave única y ningún atributo no-clave, no viola ninguna forma
normal hasta el BCNF. Pero debido a que las variedades de pizza que un restaurante ofrece son
independientes de las áreas a las cuales el restaurante envía, hay redundancia en la tabla: por ejemplo, nos
dicen tres veces que A1 Pizza ofrece la Corteza rellena, y si A1 Pizza comienza a producir pizzas de Corteza
de queso entonces necesitaremos agregar múltiples registros, uno para cada una de las Áreas de envío de A1
Pizza. En términos formales, esto se describe como que Variedad de pizza está teniendo una dependencia
multivalor en Restaurante.
Para satisfacer la 4NF, debemos poner los hechos sobre las variedades de pizza ofrecidas en una tabla
diferente de los hechos sobre áreas de envío:
Variedades por restaurante

Restaurante Variedad de pizza
Vincenzo's Pizza Corteza gruesa

Vincenzo's Pizza Corteza fina
Elite Pizza Corteza fina
Elite Pizza Corteza rellena
A1 Pizza Corteza gruesa
A1 Pizza Corteza rellena
Pag. 25
Áreas de envío por restaurante

Restaurante Área de envío
Vincenzo's Pizza Springfield

Vincenzo's Pizza Shelbyville
Elite Pizza Capital City
A1 Pizza Springfield
A1 Pizza Shelbyville
A1 Pizza Capital City
En contraste, si las variedades de pizza ofrecidas por un restaurante a veces variaran de una área de envío a
otra, la tabla original de la tres columnas satisfaría la 4NF.
Ronald Fagin demostró que es siempre posible alcanzar la 4NF (pero no siempre deseable). El teorema de
Rissanen es también aplicable en dependencias multivalor.
3.4.6. Quinta forma normal (5NF)
La quinta forma normal (5NF), también conocida como forma normal de proyección-unión (PJ/NF), es un
nivel de normalización de bases de datos designado para reducir redundancia en las bases de datos
relacionales que guardan hechos multi-valores aislando semánticamente relaciones múltiples relacionadas.
Una tabla se dice que está en 5NF si y solo si está en 4NF y cada dependencia de unión (join) en ella es
implicada por las claves candidatas.
Ejemplo
Considere el siguiente ejemplo:
Psiquiatra-para-asegurador-para-condición
Psiquiatra Asegurador Condición
Dr. James Healthco Ansiedad

Dr. James Healthco Depresión
Dr. Kendrick FriendlyCare OCD
Dr. Kendrick FriendlyCare Ansiedad
Dr. Kendrick FriendlyCare Depresión
Dr. Lowenstein FriendlyCare Esquizofrenia
Dr. Lowenstein Healthco Ansiedad
Dr. Lowenstein Healthco Demencia
Dr. Lowenstein Victorian Life Trastorno de conversión
El psiquiatra puede ofrecer tratamiento reembolsable a los pacientes que sufren de la condición dada y que
son asegurados por el asegurador dado. En ausencia de cualquier regla que restrinja las combinaciones
válidas posibles de psiquiatra, asegurador, y condición, la tabla de tres atributos Psiquiatra-para-Asegurador-
para-Condición es necesaria para modelar la situación correctamente.
Pag. 26
Sin embargo, suponga que la regla siguiente se aplica:
Cuando un psiquiatra es autorizado a ofrecer el tratamiento reembolsable a los pacientes asegurados por el
asegurador P, y el psiquiatra puede tratar la condición C, entonces - en caso que el asegurador P cubra la
condición C - debe ser cierto que el psiquiatra puede ofrecer el tratamiento reembolsable a los pacientes que
sufren de la condición C y están asegurados por el asegurador P.
Con estas restricciones es posible dividir la relación en tres partes.
Psiquiatra-para-condición
Psiquiatra Condición
Dr. James Ansiedad

Dr. James Depresión
Dr. Kendrick OCD
Dr. Kendrick Ansiedad
Dr. Kendrick Depresión
Dr. Kendrick Trastorno emocional
Dr. Lowenstein Esquisofrenia
Dr. Lowenstein Ansiedad
Dr. Lowenstein Demencia
Dr. Lowenstein Trastorno de conversión
Psiquiatra-para-asegurador
Psiquiatra Asegurador
Dr. James Healthco

Dr. Kendrick FriendlyCare
Dr. Lowenstein FriendlyCare
Dr. Lowenstein Healthco
Dr. Lowenstein Victorian Life
Asegurador-para-condición
Asegurador Condición
Healthco Ansiedad
Healthco Depresión
Healthco Demencia
FriendlyCare OCD
FriendlyCare Ansiedad
FriendlyCare Depresión
FriendlyCare Trastorno emocional
FriendlyCare Esquisofrenia
Victorian Life Trastorno de conversión
Note como esta disposición ayuda a quitar redundancia. Suponga que el Dr. James se convierte en un
proveedor de tratamientos para FriendlyCare. En la disposición anterior tendríamos que agregar dos nuevas
entradas puesto que el Dr. James puede tratar dos condiciones cubiertas por FriendlyCare: ansiedad y
depresión. Con la nueva disposición necesitamos agregar una sola entrada (en la tabla Psiquiatra-para-
Asegurador).
Pag. 27
3.4.6.1. Uso
Solamente en raras situaciones una tabla 4NF no se conforma con la 5NF. Éstas son situaciones en las cuales
un complejo constreñimiento del mundo real gobernando las combinaciones válidas de los valores de
atributos en la tabla 4NF no es implícito en la estructura de esa tabla. Si esa tabla no se normaliza a 5NF, la
carga de mantener la consistencia lógica de los datos dentro de la tabla debe ser llevada en parte por la
aplicación responsable de inserciones, borrados, y actualizaciones a ella; y hay un aumentado riesgo que los
datos dentro de la tabla se volverán inconsistentes. En contraste, el diseño 5NF excluye la posibilidad de
tales inconsistencias.
Pag. 28
4. LENGUAJE DE CONSULTAS SQL

El lenguaje de consulta estructurado (SQL) es un lenguaje de base de datos normalizado, utilizado
por los diferentes motores de bases de datos para realizar determinadas operaciones sobre los datos o
sobre la estructura de los mismos. Pero como sucede con cualquier sistema de normalización hay
excepciones para casi todo; de hecho, cada motor de bases de datos tiene sus peculiaridades y lo hace
diferente de otro motor, por lo tanto, el lenguaje SQL normalizado (ANSI) no nos servirá para resolver
todos los problemas, aunque si se puede asegurar que cualquier sentencia escrita en ANSI será
interpretable por cualquier motor de datos.
4.1. Breve Historia
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 (sustancialmente 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.
4.2. Componentes del SQL
SQL (Standar Query Lenguaje) es un lenguaje estandarizado de base de datos, el cual nos permite realizar
tablas y obtener datos de ella de manera muy sencilla. Para exponer más claramente los conceptos se
realizaran ejemplo sobre relaciones que se crearan aquí para entender mejor como funciona SQL.
Pag. 29
Cuando aquí nos refiramos a relación estamos hablando más concretamente a la tabla de datos en sí, y sus
atributos serán los campos de la tabla. Como ejemplo la siguiente relación (tabla) la llamaremos persona y
sus atributos (campos) son nombre, apellido Y DNI
PERSONA NOMBRE APELLIDO DNI

1 MARTIN MARQUESI 26125988
2 PABLO MARQUESI 25485699
3 ROBERTO SANCHEZ 20566401
4 ESTEFANIA GUISSINI 27128064
5 RUBEN ALEGRATO 24238975
6 SANDRA BRITTE 25483669
7 MELISA ARDUL 27456224
8 SOLEDAD MICHELLI 29889656
9 BETANIA MUSACHEGUI 27128765
10 JUAN SERRAT 28978845
SQL es un lenguaje que consta de varias partes

• Lenguaje de definición de datos ( DDL): Proporciona ordenes para definir esquemas de relación,
eliminar relaciones, crear índices y modificar esquemas de relación.
• Lenguaje de manipulación de datos interactivos (DML): incluye un leguaje de consultas que permite
rescatar datos de las relaciones. También incluye órdenes para insertar, suprimir y modificar tuplas.
• Lenguaje de manipulación de datos inmerso (DML): La forma inmersa de SQL está diseñada para
usar dentro de los lenguajes de programación de lenguaje general.
• Definición de vistas (DDL): incluye órdenes para definir vistas.
4.3. Estructura básica
La estructura básica de una expresión para consulta SQL consta de tres cláusulas:
• SELECT
• FROM
• WHERE
La cláusula SELECT se usa para listar los atributos que se desean en el resultado de una consulta.
La cláusula FROM lista las relaciones que se van a examinar en la evaluación de la expresión
La cláusula WHERE costa de un predicado que implica atributos de las relaciones que aparecen en la
cláusula FROM.
Una consulta básica en SQL tiene la forma:
SELECT A1,A2,...,An
FROM r1,r2,...,rn
WHERE P
Donde:
Ai = atributo (Campo de la tabla)
ri = relación (Tabla )
P = predicado (condición)
Pag. 30
Ejemplo: Seleccionar todos los nombres de las personas que tengan el apellido MARQUESI de la tabla
persona
SELECT nombre
FROM persona
WHERE apellido = “ MARQUESI”
NOMBRE
MARTIN
PABLO
El resultado de una consulta es por supuesto otra relación. Si se omite la cláusula WHERE, el predicado P es
verdadero. La lista A1, A2,..., An puede sustituirse por un asterisco (*) para seleccionar todos los atributos
de todas las relaciones que aparecen en la cláusula FROM, aunque no es conveniente elegir esta última
opción salvo que sea necesario pues desperdiciamos mucho tiempo en obtenerlo
4.4. Alias
Es posible renombrar los atributos y las relaciones, a veces por conveniencia y otras veces por ser necesario,
para esto usamos la clausula AS como en el siguiente ejemplo.
Ejemplo
SELECT P.nombre AS [PRIMER NOMBRE] FROM persona P

WHERE apellido = “MARQUESI”
PRIMER NOMBRE
MARTIN
PABLO
En este ejemplo cabe destacar un par de cosas. Cuando nos referimos a un atributo como es el caso de
nombre, podemos referirnos a este usando la relación ( o el alias en este ejemplo ) a la que pertenece el
atributo seguido de un punto seguido del atributo <P.nombre>, a veces esta notación será necesaria para
eliminar ambigüedades. Los corchetes los usamos cuando usamos espacios en blancos o el caratér (-) en el
nombre de atributo o alias.
Usar alias en los atributos nos permite cambiar el nombre de los atributos de la respuesta a la consulta.
Cuando asociamos un alias con una relación decimos que creamos una variable de tupla. Estas variables de
tuplas se definen en la cláusula FROM después del nombre de la relación.
En las consultas que contienen subconsultas, se aplica una regla de ámbito a las variables de tupla. En una
subconsulta está permitido usar solo variables de tupla definidas en la misma subconsulta o en cualquier
consulta que tenga la subconsulta.
4.5. Predicados y conectores
Los conectores lógicos en SQL son:

• AND
• OR
• NOT
La lógica de estos conectores es igual que en cualquier lenguaje de programación y sirven para unir
predicados.
Pag. 31
Las operaciones aritméticas en SQL son:

• + ( Suma )
• - ( Resta )
• * ( Multiplicación )
• / ( División )
También incluye el operador de comparación BETWEEN, que se utiliza para valores comprendidos.
Ejemplo: Encontrar todos los nombres y dni de las personas cuyos dni sea mayor que 26 millones y menor a
28 millones
NOMBRE DNI
MARTIN 26125988
ESTEFANIA 27128064
MELISA 27456224
BETANIA 27128765
Análogamente podemos usar el operador de comparación NOT BETWEEN.
SQL también incluye un operador de selección para comparaciones de cadena de caracteres. Los modelos se
describen usando los caracteres especiales:
• El carácter ( % ) es igual a cualquier subcadena

• El operador ( _ ) es igual a cualquier carácter
Estos modelos se expresan usando el operador de comparación LIKE. Un error muy frecuente es tratar de
utilizar los modelos mediante el operador de igualdad ( = ) lo cual es un error de sintaxis.
Ejemplo: encontrar los nombres que comiencen con la letra p o el nombre tenga exactamente 6 caracteres de
la relación persona
SELECT nombre
FROM persona
WHERE (nombre LIKE "P%") OR (nombre LIKE "_ _ _ _ _ _")
NOMBRE
MARTIN
PABLO
MELISA
SANDRA
Análogamente podemos buscar desigualdades usando el operador de comparación NOT LIKE.
4.6. Tuplas duplicadas
Los lenguajes de consulta formales se basan en la noción matemática de relación como un conjunto. Por ello
nunca aparecen tuplas duplicadas en las relaciones. En la práctica la eliminación de duplicados lleva bastante
tiempo. Por lo tanto SQL permite duplicados en las relaciones. Así pues en las consultas se listaran todas las
tuplas inclusive las repetidas.
En aquellos casos en los que queremos forzar la eliminación de duplicados insertamos la palabra clave
DISTINCT después de la cláusula SELECT
Pag. 32
Ejemplo: Listar todos los apellidos no repetidos de la relación persona
SELECT DISTINCT apellido

FROM persona
APELLIDO
MARQUESI
SANCHEZ
GUISSINI
ALEGRATO
BRITTE
ARDUL
MICHELLI
MUSACHEGUI
SERRAT
Si observamos la tabla original de la relación persona veremos que el apellido marquesi aparecía dos veces,
pero debido al uso de DISTINCT en la consulta la relación respuesta solo lista un solo marquesi.
4.7. Operaciones de conjunto.
SQL incluye las operaciones de conjuntos UNION, INTERSECT, MINUS, que operan sobre relaciones y
corresponden a las operaciones del álgebra unión, intersección y resta de conjuntos respectivamente. Para
realizar esta operación de conjuntos debemos tener sumo cuidado que las relaciones tengan las mismas
estructuras.
Incorporemos ahora una nueva relación, llamada jugadores que representa las personas que juegan al fútbol,
sus atributos serán DNI, puesto y nro_camiseta.
Supongamos que esta nueva tabla está conformada de la siguiente manera
JUGADORES DNI PUESTO NRO_CAMISETA

1 26125988 DELANTERO 9
2 25485699 MEDIO 5
3 28978845 ARQUERO 1
4 29789854 DEFENSOR 3
Ejemplo: Obtener todos los nombres de la relación persona cuyos apellidos sean Marquesi o Serrat
SELECT nombre
FROM PERSONA
WHERE apellido = "MARQUESI"
UNION
SELECT nombre
FROM PERSONA
WHERE apellido = "SERRAT"
PRIMER NOMBRE
MARTIN
PABLO
JUAN
Pag. 33
Ejemplo: Obtener todos los DNI de los que juegan al fútbol y, además, están en la lista de la relación persona
SELECT dni
FROM persona
INTERSECT
SELECT dni
FROM jugadores
DNI
26125988
25485699
28978845
Por omisión, la operación de unión elimina las tuplas duplicadas. Para retener duplicados se debe escribir
UNION ALL en lugar de UNION.
Pertenencia a un conjunto
El conector IN prueba si se es miembro de un conjunto, donde el conjunto es una colección de valores

producidos en lo general por una cláusula SELECT.
Análogamente el conector NOT IN prueba la no pertenencia al conjunto
Ejemplo: Encontrar los nombres de las personas que juegan al fútbol y, además, se encuentran en la relación
persona
SELECT nombre, apellido

FROM persona
WHERE dni IN
( SELECT dni
FROM jugadores )
NOMBRE APELLIDO
MARTIN MARQUESI
PABLO MARQUESI
JUAN SERRAT
Es posible probar la pertenencia de una relación arbitraria SQL usa la notación de elementos <v1,v2,...,vn>
para representar una tupla de elementos de n que contiene los valores v1,v2,...,vn.
Comparación de conjuntos
En conjuntos la frase << mayor que algún >> se representa en SQL por ( >SOME ), también podría
entenderse esto como << mayor que el menor de >>, su sintaxis es igual que la del conector IN. SQL
también permite las comparaciones ( >SOME ),( =SOME ) ( >=SOME ), ( <=SOME ) y ( <>SOME ).
También existe la construcción ( >ALL ), que corresponde a la frase << mayor que todos >>. Al igual que el
operador SOME, puede escribirse ( >ALL ),( =ALL ) ( >=ALL ), ( <=ALL ) y ( <>ALL ).
En ocasiones podríamos querer comparar conjuntos para determinar si un conjunto contiene los miembros de
algún otro conjunto. Tales comparaciones se hacen usando las construcciones CONTAINS y NOT
CONTAINS
Pag. 34
4.8. Pruebas para relaciones vacías
La construcción EXISTS devuelve el valor TRUE si la subconsulta del argumento no está vacía, y la
construcción NOT EXISTS devuelve TRUE si la consulta es vacía.
Ejemplo: encontrar todos los nombres y apellidos de la relación persona si es que en la relación jugadores
existe un jugador con el número de dni 27128055
SELECT nombre, apellido

FROM persona
WHERE EXISTS
( SELECT dni
FROM jugadores
WHERE dni = 27128055 )
Como el dni = 27128055 no existe en la relación jugadores, la condición es FALSE y por lo tanto la
respuesta es vacía.
4.9. Ordenación de la presentación de tuplas
SQL ofrece al usuario cierto control sobre el orden en el que se va a presentar las tuplas en una relación. La
cláusula ORDER BY hace que las tupla en el resultado dé una consulta en un orden específico.
Por omisión SQL lista los elementos en orden ascendente. Para especificar el tipo de ordenación, podemos
especificar DESC para orden descendente o ASC para orden ascendente.
También es posible ordenar los resultados por más de una atributo
Ejemplo: encontrar todos los nombres y apellido de la relación persona y ordenar los resultados por apellido
y nombre en forma descendente
SELECT apellido, nombre

FROM persona
ORDER BY apellido DESC, nombre DESC
APELLIDO NOMBRE
SERRAT JUAN
SANCHEZ ROBERTO
MUSACHEGUI BETANIA
MICHELLI SOLEDAD
MARQUESI PABLO
MARQUESI MARTIN
GUISSINI ESTEFANIA
BRITTE SANDRA
ARDUL MELISA
ALEGRATO RUBEN
Pag. 35
4.10. Funciones de agregación
SQL ofrece la posibilidad de calcular funciones en grupos de tuplas usando la cláusula GROUP BY, también
incluye funciones para calcular
• Promedios AVG
• Mínimo MIN
• Máximo MAX
• Total SUM
• Contar COUNT
Para los próximos ejemplos incorporamos una nueva relación llamada PRO que representara los jugadores
profesionales de fútbol, sus atributos serán dni, años_pro, club, valor_actual. Y los valores son los
siguientes:
PRO DNI AÑOS_PRO CLUB VALOR_ACTUAL

1 26125988 5 ALL BOY'S 1000
2 25485699 2 ALL BOY'S 2500
3 27126045 3 LANUS 12000
4 26958644 4 LANUS 6500
5 29120791 1 LANUS 450
Ejemplo: determinar el valor total en jugadores así como también la cantidad de jugadores de cada club en la
relación pro
SELECT club, SUM(valor_actual) AS VALOR_TOTAL,

COUNT(club) AS NRO_JUGADORES
FROM pro
GROUP BY CLUB
CLUB VALOR_TOTAL NRO_JUGADORES

ALL BOY'S 3.500,00 2
LANUS 18.950,00 3
Ejemplo: Determinar por cada club cual es el valor_actual del jugador más caro de la relación pro
SELECT club, MAX(valor_actual) AS JUG_MAS_CARO

FROM pro
GROUP BY CLUB
CLUB JUG_MAS_CARO
ALL BOY'S 2500
LANUS 12000
Hay ocasiones en la que los duplicados deben eliminarse antes de calcular una agregación. Cuando queremos
eliminar los duplicados del cálculo usamos la palabra clave DISTINCT antepuesto al atributo de agregación
que queremos calcular, como por ejemplo COUNT(DISTINCT club).
Hay ocasiones en las que es útil declara condiciones que se aplican a los grupos mas que a las tuplas. Para
esto usamos la cláusula HAVING de SQL.
Pag. 36
Ejemplo: Determinar por cada club cual es el valor_actual del jugador más caro, pero con la condición de
que este sea mayor a 10000 de la relación pro
SELECT club, MAX(valor_actual) AS JUG_MAS_CARO

FROM pro
GROUP BY CLUB
HAVING MAX(valor_actual) > 10000
CLUB JUG_MAS_CARO
LANUS 12000
Si en la misma consulta aparece una cláusula WHERE y una cláusula HAVING, primero se aplica el
predicado de la cláusula WHERE, las tupla que satisfacen el predicado WHERE son colocadas en grupos por
la cláusula GROUP BY. Después se aplica la cláusula HAVING a cada grupo.
4.11. Modificación de la base de datos
a) Eliminación
Una solicitud de eliminación se expresa casi de igual forma que una consulta. Podemos suprimir solamente
tuplas completas, no podemos suprimir valores solo de atributos.
DELETE FROM r
WHERE P
Donde P presenta un predicado y r representa una relación. Las tuplas t en r para las cuales P(t) es verdadero,
son eliminadas de r.
Si omitimos la cláusula WHERE se eliminan todas las tuplas de la relación r (un buen sistema debería buscar
confirmación del usuario antes de ejecutar una acción tan devastadora)
Ejemplo: Eliminar todas las tuplas de la relación persona en donde apellido sea igual a “BRITTE”
DELETE FROM persona

WHERE apellido = "BRITTE"
DELETED NOMBRE APELLIDO DNI

b) Inserción
Para insertar datos en una relación, especificamos una tupla que se va a insertar o escribimos una consulta
cuyo resultado es un conjunto de tuplas que se van a insertar. La inserción de tuplas la realizamos mediante
las sentencias
INSERT INTO r1
VALUES (v1,v2,...,v)
Pag. 37
Ejemplo: Insertar una tupla con los mismos valores de la tupla eliminada en el ejemplo anterior en la relación
persona.
INSERT INTO persona

VALUES ("SANDRA","BRITTE",25483669)
INSERTED NOMBRE APELLIDO DNI

En este ejemplo, los valores se especifican en el orden en que se listan los atributos correspondientes en el
esquema de relación. Para poder ingresar los datos en un orden diferente podríamos haber escrito
INSERT INTO persona(DNI, NOMBRE, APELLIDO)

VALUES (25483669,"SANDRA","BRITTE")
c) Actualizaciones
En ciertas ocasiones podemos desear cambiar los valores de una tupla sin cambiar todos los valores en dicha
tupla. Para este propósito usamos la sentencia
UPDATE r1
SET A1 = V1, A2 = V2,...,An = Vn
WHERE P
Donde r1 es la relación Ai el atributo a modificar Vi el valor que se le asignara a Ai y P es el predicado.
Ejemplo: En la relación jugadores actualizar la posición de los jugadores que posean la camiseta número 5 y
asignarles la camiseta número 7.
UPDATE jugadores
SET nro_camiseta = 7
WHERE nro_camiseta = 5
UPDATED DNI PUESTO NRO_CAMISETA

1 25485699 MEDIO 5
4.12. Valores nulos
Es posible que para las tuplas insertadas se den valores únicamente a algunos atributos del esquema. El resto
de los atributos son asignados a valores nulos representados por NULL. Para esto colocamos la palabra
reservada NULL como valor del atributo.
Ejemplo: Insertar en la relación jugadores un jugador con dni = 26356312, puesto = defensor, y al cual aun
no le han asignado un nro_camiseta.
INSERT INTO jugadores

VALUES(26356312,"DEFENSOR", NULL)
INSERTED DNI PUESTO NRO_CAMISETA

1 26356312 DEFENSOR
Pag. 38
4.13. Definición de datos
a) Creación
Una relación en SQL se define usando la orden CREATE TABLE r(A1 D1, A2 D3,...,An Dn)
Donde r es el nombre de la relación, cada Ai es el nombre de un atributo del esquema de la relación r y Di es
el tipo de dato de Ai. Una relación recién creada está vacía. La orden INSERT puede usarse para cargar la
relación
Ejemplo: crear la relación lesionado con los atributos nombre, apellido ambos de tipo char y tiempo_inhabilit
de tipo entero
CREATE TABLE "lesionado.db" (

NOMBRE CHAR(20),
APELLIDO CHAR(20),
TIEMPO_INHABILT INTEGER
)
b) Eliminación
Para eliminar una relación usamos la orden DROP TABLE r, esta orden elimina toda la información sobre la
relación sacada de la base de datos, esta orden es más fuerte que DELET FROM r ya que esta ultima elimina
todas las tuplas pero no destruye la relación, mientras que la primera sí.
Ejemplo: eliminar la relación persona
DROP TABLE persona
c) Actualización
La orden ALTER TABLE se usa para añadir atributos a una relación existente. A todas las tuplas en la
relación se les asigna NULL como valor de atributo. La sintaxis de ALTER TABLE es la siguiente:
ALTER TABLE r1 ADD A1 D1
Ejemplo: agregar los atributos de tipo char nombre y apellido a la relación jugadores
ALTER TABLE jugadores ADD NOMBRE CHAR(20)

ALTER TABLE jugadores ADD APELLIDO CHAR(20)
Pag. 39

Base de Datos

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Base de Datos

Uploaded by

Copyright:

Available Formats

C.T.S.

ÁREA DE INFORMÁTICA - BASE DE DATOS - 3E

1. INTRODUCCIÓN A LOS CONCEPTOS DE BASES DE DATOS

Conceptos básicos de archivos computacionales.

1.1. SISTEMA MANEJADOR DE BASE DE DATOS. (DBMS)

Esquema de base de datos:

Administrador de base de datos (DBA):

1.2. OBJETIVOS DE LOS SISTEMAS DE BASES DE DATOS.

Redundancia e inconsistencia de datos.

Dificultad para tener acceso a los datos.

Aislamiento de los datos.

Anomalías del acceso concurrente.

¿Qué es modelo de datos?

• Los modelos de datos se dividen en tres grupos:

2.1. MODELOS LÓGICOS BASADOS EN OBJETOS.

2.1.1. MODELO ENTIDAD-RELACIÓN.

2.1.1.1. Entidades y conjunto de entidades

2.1.1.2. Relaciones y conjunto de relaciones.

Una relación es la asociación que existe entre dos a más entidades.

Un conjunto de relaciones es un grupo de relaciones del mismo tipo.

2.1.1.3. Tipos de relaciones:

a) Relación uno a uno.

Es representado gráficamente de la siguiente manera:

A: Representa a una entidad de cualquier tipo diferente a una entidad B.

b) Relación uno a muchos.

Su representación gráfica es la siguiente:

A los tipos de relaciones antes descritos, también se le conoce como cardinalidad.

Algunos ejemplos de cardinalidades de la vida común pueden ser:

Cliente – Cuenta en un banco, Padre-Hijos, Camión-Pasajeros, zoológico- animales, árbol – hojas.

Arquitecto – proyectos, fiesta – personas, estudiante – materias.

Otra clase de limitantes lo constituye la dependencia de existencia.

Refiriéndonos a las mismas entidades A y B, decimos que si la entidad A depende de la existencia de la

2.1.1.4. Llaves primarias.

2.1.1.5. Diagrama Entidad-Relación

Relación Uno a Uno.

Automóvil: Modelo, Placas, Color

Tarjeta de circulación: Propietario, No_serie, Tipo.

Relación uno a muchos.

2.1.1.6. Reducción de diagramas E-R a tablas

Cuyo diagrama E-R es el siguiente:

Entonces las tablas resultantes siguiendo la descripción anterior son:

Nombre Puesto Salario RFC

Clave Descripción Costo

RFC Clave Fecha

2.1.1.7. Generalización y especialización, Agregación

Como podemos observar la Generalización trata de eliminar la redundancia (repetición) de atributos, al

2.2. MODELOS LÓGICOS BASADOS EN REGISTROS.

Se utilizan para describir datos en los niveles conceptual y físico.

Los tres modelos de datos más ampliamente aceptados son:

2.2.1. MODELO RELACIONAL

Las características más importantes de los modelos relacionales son:

2.2.1.1. Estructura de las bases de datos relacionales

La arquitectura relacional consta de los siguientes componentes:

1. Modelo relacional de datos:

Es un lenguaje de manejo de datos para el sistema relacional, el álgebra relacional y cálculo

• Relación = tabla o archivo

Aquí a FechaDeNacimiento se le conoce como un determinante. Se puede leer de dos formas

3.2.1.1. Propiedades de la Dependencia funcional

Existen 3 axiomas de Armstong:

a) Dependencia funcional Reflexiva

Si y está incluido en x entonces

b) Dependencia funcional Aumentativa

dni, dirección nombre, dirección

c) Dependencia funcional transitiva