Bases de Datos Unidad 3

UNIVERSIDAD NACIONAL AUTÓNOMA DE
MÉXICO
FACULTAD DE CONTADURÍA Y ADMINISTRACIÓN
Licenciatura En Informática
Bases de
Datos
Autor: L.I. María de Lourdes Isabel
Ponce Vásquez
AGOSTO - DICIEMBRE 2008

Contenido
UNIDAD 3. MODELO RELACIONAL....................................................................................................................4
Objetivos Específicos.......................................................................................................................4
3.1. Introducción..............................................................................................................................4
3.1.1. Modelos Prerelacionales....................................................................................................5
3.1.1.1. Modelo Jerárquico........................................................................................................5
3.1.1.2. Modelo de Red.............................................................................................................6
3.1.2. Modelo Relacional..............................................................................................................7
3.1.3. Modelos Postrelacionales..................................................................................................8
3.1.1.3. Modelo Orientado a objetos.........................................................................................8
3.1.1.4. Modelo Objeto-Relacional............................................................................................9
3.1.1.5. Modelo de Datos Semiestructurados............................................................................9
3.1.1.6. Data warehouses y minería de datos...........................................................................9
3.2. Definición de Relación............................................................................................................10
3.2.1. Partes...............................................................................................................................11
3.1.1.7. Grado y Cardinalidad..................................................................................................11
3.1.1.8. Llaves de la Relación.................................................................................................12
3.3. Propiedades de una Relación.................................................................................................12
3.4. Restricciones..........................................................................................................................13
3.4.1. Restricciones de Integridad..............................................................................................13
3.4.2. Restricciones de Usuario.................................................................................................13
3.1.1.9. En base a consecuencias de operaciones de Borrado y Modificación.......................13
3.1.1.10. En base a las relaciones entre atributos...................................................................14
3.1.1.11. En base a las relaciones entre elementos................................................................14
3.5. Lenguajes Relacionales de Manipulación de Datos................................................................14
3.5.1. Álgebra Relacional...........................................................................................................15
3.1.1.12. Proyección................................................................................................................16
3.1.1.13. Selección..................................................................................................................16
3.1.1.14. Unión........................................................................................................................17
3.1.1.15. Intersección..............................................................................................................18
3.1.1.16. Diferencia.................................................................................................................18
3.1.1.17. División.....................................................................................................................19
3.1.1.18. Producto Cartesiano.................................................................................................19
3.1.1.19. Producto Theta (Reunión o Join)..............................................................................20
3.5.2. Cálculo Relacional...........................................................................................................21
3.1.1.20. Cálculo Relacional Orientado a Tuplas.....................................................................22
3.1.1.21. Cálculo Relacional Orientado a Dominios................................................................23
3.5.3. Lenguajes Orientados a la Transformación......................................................................23
3.5.4. Consulta por Ejemplo (QBE – Query By Example)...........................................................24
3.6. Normalización.........................................................................................................................24
3.6.1. Anomalías de datos..........................................................................................................24
3.6.2. Tipos de Dependencias....................................................................................................25
3.1.1.22. Dependencia Funcional............................................................................................25
3.1.1.23. Dependencia Transitiva............................................................................................26
3.1.1.24. Dependencia Multivaluada.......................................................................................26
3.1.1.25. Dependencia de reunión..........................................................................................28
Unidad 2. Modelo Relacional Página 2

3.6.3. Formas Normales.............................................................................................................29
3.1.1.26. Primera Forma Normal.............................................................................................29
3.1.1.27. Segunda Forma Normal...........................................................................................30
3.1.1.28. Tercera Forma Normal.............................................................................................31
3.1.1.29. Forma Normal Boyce-Codd......................................................................................32
3.1.1.30. Cuarta Forma Normal ..............................................................................................33
3.1.1.31. Quinta Forma Normal ..............................................................................................34
3.6.4. Proceso de Descomposición sin Pérdida.........................................................................34
3.1.1.32. Preservación de atributos.........................................................................................35
3.1.1.33. Preservación de la dependencia..............................................................................35
3.1.1.34. Descomposición sin Pérdida....................................................................................35
3.7. Reglas de Codd......................................................................................................................37
3.7.1. Regla Cero.......................................................................................................................37
3.7.2. Regla 1. Representación de la Información......................................................................37
3.7.3. Regla 2. Acceso Garantizado...........................................................................................37
3.7.4. Regla 3. Información Faltante..........................................................................................37
3.7.5. Regla 4. Diccionario de Datos Dinámico basado en el modelo relacional........................37
3.7.6. Regla 5. Lenguaje de datos Comprensible.......................................................................37
3.7.7. Regla 6. Actualización de Vistas......................................................................................38
3.7.8. Regla 7. Operaciones de Conjuntos (Insert, Delete y Update).........................................38
3.7.9. Regla 8. Independencia Física de los Datos....................................................................38
3.7.10. Regla 9. Independencia Lógica de los Datos.................................................................38
3.7.11. Regla 10. Independencia de Integridad..........................................................................38
3.7.12. Regla 11. Independencia de Distribución.......................................................................38
3.7.13. Regla 12. No Subversión...............................................................................................38
3.8. Estándar SQL.........................................................................................................................39
3.8.1. Antecedentes...................................................................................................................39
3.8.2. Versiones.........................................................................................................................40
3.8.3. Estructura de instrucciones..............................................................................................41
3.9. Transformación del Modelo E/R al Modelo Relacional............................................................44

UNIDAD 3. MODELO RELACIONAL
Objetivos Específicos
 Conocer los modelos de datos anteriores y posteriores al modelo relacional
 Describir los elementos del modelo
 Conocer y aplicar las bases del modelo relacional mediante el uso del álgebra y cálculo
relacionales
 Identificar las anomalías de inserción, actualización y borrado
 Aplicar las formas normales al diseño de un modelo relacional
 Comprender los tipos de dependencias entre atributos.
 Describir las reglas de Codd para modelos relacionales
3.1. Introducción
El modelo relacional fue propuesto originalmente por E. F. Codd en 1970, en un documento llamado
“Un Modelo Relacional de Datos para Grandes Bancos de Datos Compartidos”. Fue el primer modelo
basado en nociones teóricas de matemáticas, las cuales proporcionaban una sólida base teórica. Las
investigaciones de este modelo fueron hechas por Codd y otros en los Laboratorios de Investigación
de IBM en San José, California. El primer prototipo de RDBMS fue el System R, desarrollado por
investigadores de IBM finales de los 70s. El RDBMS de IBM actual DB2 está basado en el System
R. SQL, es un lenguaje desarrollado para el System R que se convirtió en el lenguaje estándar para
BD relacionales, con los estándares aprobados por ANSI y publicados en 1986, 1989, 1992 y 199.
Otros proyectos de investigación sobre el modelo relacional fueron el Peterlee Relational Test
Vehicle, desarrollado en los Laboratorios Científicos de IBM en Inglaterra e INGRES, desarrollado en
la Universidad de California en Berkeley. Estas investigaciones obtuvieron una versión universitaria
de INGRES y una versión comercial. ORACLE fue desarrollado y comercializado usando mucho de
los resultados del System R. La aparición de las microcomputadoras en los 80s, logró desarrollos de
RDBMSs para PC, entre ellos dBase, R:Base, Foxpro, Paradox y Access, que es el RDBMS más
usado en microcomputadoras. Los RDBMS más populares a nivel empresarial son Oracle, DB2,
Informix, SyBase y SQL Server, aunque empiezan a ganar terreno Postgres y My SQL.
El modelo relacional usa simples tablas para organizar los datos. En 1976, P.P. Chen desarrolló un
nuevo tipo de modelo, el modelo entidad/relación. Este es un ejemplo de modelo semántico, ya
que intenta capturar el significado de los datos que representa, a diferencia del modelo relacional que
sólo indica cómo están organizados. El modelo entidad/relación ha sido extendido varias veces para
hacerlo semánticamente más rico. También existen otros modelos semánticos.
El modelo relacional es un ejemplo de un modelo basado en registros. Los modelos basados en

registros se usan para describir la BD externa, lógica y para algunos extiende sus niveles internos.
Estos modelos permiten al diseñador desarrollar y especificar la estructura lógica y proporcionan
algunas opciones para la implementación del diseño. Se implementan usando una variedad de
DBMSs. Sin embargo, no proporcionan mucha información semántica como categorización de
objetos, relaciones, abstracciones o restricciones de datos. Este modelo el actualmente muy usado
debido a su simplicidad desde el punto de vista del usuario y por su poder.
El mismo tipo de teoría matemática que usa se completa con notación formal, definiciones, teoremas
y prueba que las matemáticas pueden aplicarse a este modelo. El resultado de este desarrollo
teórico es entonces aplicado a consideraciones prácticas de implementación. En el modelo

relacional, las entidades se representan como relaciones, las cuales son físicamente representadas
como tablas o arreglos de dos dimensiones, y los atributos como columnas de estas tablas. Las
interrelaciones pueden representarse como tablas, ya que este modelo ve las interrelaciones como
un tipo especial de entidad. Los renglones en las tablas representan los datos almacenados.
3.1.1. Modelos Prerelacionales

Antes de que surgiera el modelo relacional, existieron otros modelos de datos que fueron
desarrollados durante los años 60s, estos modelos son los de red y jerárquicos. Estos modelos
también son modelos basados en registros y su interés es meramente histórico, ya que no se usan
para nuevos desarrollos de BD, aunque aún existen algunas BD basadas en estos modelos.
3.1.1.1. Modelo Jerárquico
El modelo jerárquico de BD fue desarrollado como una solución a las necesidades

inmediatas de de aplicaciones reales a mediados de los 60s. El sistema más antiguo e
importante de BD jerárquico es IMS de IBM y fue desarrollado para organizar y
almacenar información necesaria para el proyecto de alunizaje del Apolo. IBM y la
Aviación Norteamericana trabajaron juntos para producir la primera versión de IMS en
1968. Las versiones posteriores de IMS fueron diseñadas para usarse con dispositivos de cintas
magnéticas, pero los posteriores discos magnéticos se convirtieron en el estándar. IMS rápidamente
se convirtió en el DBS jerárquico dominante en el mercado y fue por muchos años el DBMS más
ampliamente usado, hasta que fue remplazado por los sistemas relacionales. Muchas mejoras fueron
hechas a IMS después del 68, resultando en nuevas versiones que obtenían ventajas de las mejoras
en hardware y software, proporcionando nuevas características como comunicación de datos y
máximo desempeño. IMS era capaz de procesar grandes cantidades de datos de modo eficiente.
Usaba una estructura de árbol familiar para los programadores acostumbrados a trabajar con
archivos.
La estructura lógica en la que se sustenta es el árbol, el cual se compone de un nodo raíz y varios
nodos sucesores, ordenados jerárquicamente. Cada nodo representa una entidad (tipo de registro) y
las relaciones entre entidades son las conexiones entre los nodos. El nodo superior es el nodo padre
y los inferiores son los nodos hijos. Las conexiones entre archivos no dependen de la información
contenida en ellos, se definen al inicio y son fijos (apuntadores). Las interrelaciones entre registros
permiten que un padre tenga muchos hijos, pero un hijo sólo puede tener un padre.
Los datos se representan como estructuras de árbol y el árbol representa la jerarquía de registros de
datos. La navegación es top-down.
PADRE
HIJO HIJO/PADRE HIJO
HIJO HIJO
Relaciones: 1 Padre, Múltiples Hijos (1 : M)

Por ejemplo, si se tiene dos entidades: cuentahabiente consiste de 3 atributos: nombre, calle y
ciudad. La entidad cuenta tiene 2 campos: número y saldo, el modelo jerárquico se puede
representar como:
LUIS AV. LEÓN LEÓN PEDRO AV. 2 D.F. JUAN HIDALGO HIDALGO
200 55 256 100000 347 667 347 667 301 10346
Desventajas:
 No modela sencillamente las relaciones Muchos a Muchos.

 Genera anomalías de inserción.
 Genera anomalías de borrado.
 Genera anomalías de actualización.
 Se pueden dar consultas inconsistentes.
3.1.1.2. Modelo de Red
Uno de los DBMS más antiguos fue IDS (Integrated Data Store) que fue desarrollado en
General Electric por Charles Bachean a principios de los 60s usando el modelo de red.
Este DBMS tuvo gran influencia en el desarrollo de BD durante muchos años. Se formó
CODASYL (Conference on Data Systems Languages – Conferencia sobre Lenguajes de
Sistemas de Datos), una organización que representaba a la mayoría de los vendedores de
hardware y software y usuarios, para tratar de estandarizar muchos aspectos del procesamiento de
datos. Tuvo éxito escribiendo estándares para el lenguaje COBOL. A finales de los 60s, formó un
subgrupo llamado DBTG (Database Task Group – Grupo de Trabajo para BD) para definir
estándares para DBMSs. Publicó un reporte en 1969 que generó muchas sugerencias y
modificaciones por parte de los lectores. DBTG consideró las propuestas y publicó su primer reporte
oficial en 1971. Este documento fue enviado a la ANSI (American National Standards Institute –
Instituto Estadounidense de Estándares Nacionales) con la esperanza de que sus especificaciones
se aceptaran como estándar para DBMSs, sin embargo, ANSI se lo rechazó. Al reporte de 1971 le
siguieron varias versiones en 1973, 1978, 1978, 1981 y 1984, pero se mantuvo la documentación
principal que describía un modelo basado en red generalmente referido como el modelo CODASYL o
el modelo DBGT, y varios DBMS populares se basaron en él. Además de esto, proporcionó el
vocabulario y un marco de trabajo para discusiones de temas de BD, estableciendo por primera vez
la noción de capaz en la arquitectura de BD y terminología común. El DBTG evolucionó en 1972 en
un comité permanente, el DDLC (Data Description Language Committee – Comité para el Lenguaje
de Descripción de Datos), que continuó operando y publicando sus hallazgos periódicamente en su
Journals of Development hasta 1984, cuando su función fue tomada por el comité ANSI X3H2 para la
estandarización. A pesar de que el DBGT u DDLC continuaron haciendo cambios al modelo
CODASYL, la propuesta de 1971 fue usada por la mayoría de los vendedores como la base de sus
DBMS. El más usado de estos sistemas basados en red fue IDMS de Cullinet. Otros incluyendo
PRIME DBMS de PRIME Computer, IDS II de Honeywell, DMS 170 de Control Data Corporation, DC,
DMSII y DMS1100 de UNISYS, y DBMS 10 y DBMS 11 de Digital Equipment Corporation.
Los datos se representan como registros ligados formando un conjunto de datos intersectados. A
diferencia de las jerárquicas, permiten cualquier conexión entre entidades, es decir, se pueden

representar relaciones de muchos a muchos. Un hijo puede tener varios padres y varios hijos a la
vez. La conexión entre los registros también es mediante apuntadores.
La representación de los datos es similar al modelo jerárquico, con relaciones de un hijo a muchos
padres y un padre a muchos hijos.
PADRE PADRE
PADRE/ HIJO PADRE/ HIJO PADRE/ HIJO
HIJO HIJO
Relaciones: 1 Padre a Múltiples Hijos, 1 Hijo a Múltiples Padres (M:M)
Tomando nuevamente el ejemplo anterior, con dos entidades: cuentahabiente con: nombre, calle y
ciudad., y cuenta con: número y saldo, el modelo de red se puede representar como:
200 55
LUIS AV. LEÓN LEÓN
256 100000
PEDRO AV. 2 D.F.
347 667
JUAN HIDALGO HIDALGO
301 10346
Desventajas:
 Resulta difícil definir nuevas relaciones.

 Es complicado darle mantenimiento, ya que cualquier cambio en la estructura requiere una
descarga de los datos.
 Representa desperdicio de recursos.
 Genera anomalías de inserción.
 Genera anomalías de borrado.
Aunque los modelos jerárquico y de red eran poderosos y eficientes, eran complejos, requerían que
los usuarios comprendieran las estructuras de datos y accedieran rutas de datos. Fueron diseñados
para usar con programas y no para acceso interactivo de los usuarios, por lo que las consultas
específicas no se soportaban. No se basaban en fundamentos teóricos sólidos, sino eran soluciones
construidas encima sistemas de archivos existentes.
3.1.2. Modelo Relacional

La estructura lógica de una BD relacional está basada en la representación de entidades
mediante tablas, las cuales constan de columnas (campos) y renglones (registros).

Las relaciones entre tablas se realizan a través de un conjunto de columnas en común, logrando una
conexión dinámica entre un número ilimitado de ellas mediante el contenido de esas columnas.
Su ventaja es poder modificar la información sin preocuparse por especificar las combinaciones entre
registros. La representación de los datos es en forma de tablas con renglones y columnas. Las
relaciones se modelan mediante columnas en común.
COLUMNA1 COLUMNA2
RENGLÓN 1
RENGLÓN 2
RENGLÓN 3
Relaciones: 1:1, 1:M, M:M
Usando el ejemplo anterior, con dos entidades: cuentahabiente con: nombre, calle y ciudad., y
cuenta con: número y saldo, donde un cuentahabiente puede tener muchas cuentas y una cuenta
puede pertenecer a varios cuentahabientes, el modelo relacional se puede representar como:
CUENTAHABIENTE CUENTA/CUENTAHABIENTE
NOMBRE CALLE CIUDAD CUENTA CUENTAHABIENTE
LUIS LEON LEÓN 200 LUIS
PEDRO AV. 2 D.F. 256 PEDRO
JUAN HIDALGO HIDALGO 347 PEDRO
347 JUAN
CUENTA 301 JUAN
NO.CUENTA SALDO
200 55
256 100000
247 667
301 10346
3.1.3. Modelos Postrelacionales

La necesidad de almacenar y manipular datos complejos que no son fáciles de modelar usando las
simples tablas del modelo relacional, así como el desarrollo de lenguajes de programación
orientados a objetos, permitieron el desarrollo de otros modelos de datos.
3.1.1.3. Modelo Orientado a objetos
El modelo orientado a objetos fue desarrollado en los 90s para manejar los datos requeridos para
aplicaciones avanzadas como sistemas de información geográfica (GIS), multimedia, diseño asistido
por computadora y manufactura asistida por computadora (CAD/CAM), y otros ambientes complejos.
El modelo orientado a objetos es un modelo semántico similar al modelo entidad/relación. Éste

extiende los conceptos del E/R agregando encapsulación, que implica incorporar tanto datos como
funciones en una unidad donde son protegidos de modificaciones del exterior. A diferencia del E/R
con entidades y atributos, este modelo usa objetos que tienen estado y comportamiento. El estado
de un objeto se determina por los valores de sus atributos (variables de instancias). El
comportamiento es el conjunto de métodos (funciones) definidas para el objeto. Para crear una BD
orientada a objetos, El diseñador comienza definiendo clases, las cuales especifican los atributos y

métodos para un conjunto de objetos. Cada objeto es entonces creado instanciando la clase, usando
uno de sus propios métodos llamados constructores. La estructura de los objetos puede ser muy
compleja. Cada objeto en una BD debe tener un identificador único que funciona como una llave
primaria permanente, pero que no toma valores de ninguno de los atributos del objeto. Las clases
que se relacionan con otras se agrupan para formar jerarquías de clases. Una diferencia importante
entre los objetos de programa y los objetos de la BD es la persistencia, ya que los objetos de
programa existen sólo mientras el programa está en ejecución, mientras que un objeto de BD
permanece en existencia después de que la ejecución del programa se completa.
3.1.1.4. Modelo Objeto-Relacional
Algunos RDBMSs como Oracle, agregaron algunas capacidades orientadas a objetos a sus
productos, resultando en bases de datos híbrida objeto-relacionales.
El modelo objeto-relacional extiende al modelo relacional agregando algunos tipos de datos

complejos y métodos. En vez de atomicidad y valores simples en los atributos que requiere el modelo
relacional, este modelo permite atributos estructurados y tienen conjuntos de arreglos de valores.
También permite métodos y herencia. El lenguaje SQL fue extendido en 1999 para crear y manipular
los tipos de datos más complejos que soporta este modelo. Sin embargo, el lenguaje usado para
manejar BD objeto-relacionales es más cercano al tipo de lenguaje para BD relacionales que el que
se usa para BD estrictamente orientadas a objetos.
3.1.1.5. Modelo de Datos Semiestructurados
El amplio uso de Internet ha tenido gran impacto en el desarrollo de BD. Internet conecta a los
usuarios a una amplia red de BDs en constante expansión, proporcionando acceso a bibliotecas
digitales, recursos multimedia, recursos educativos y mucho más. Los sitios de comercio electrónico
permiten acceso a BDs de información sobre productos y servicios a los clientes a través de mundo.
Los dispositivos de cómputo inalámbrico y los clientes pequeños como PDAs son otros desarrollos
que permiten a los usuarios conectarse a recursos de BDs en formas nuevas y flexibles.
La mayoría de los modelos requiere que los tipos de entidades (u objetos o registros, dependiendo
del modelo) tengan la misma estructura. La estructura se define en el esquema y permanece sin
modificaciones a menos que el DBA cambie el esquema. En contraste, el modelo semi-estructurado
permite una colección de nodos, cada uno conteniendo datos, posiblemente con diferentes
esquemas. El nodo contiene información sobre la estructura de su contenido. Las BD semi-
estructuradas son especialmente útiles cuando existen BD que tienen diferentes esquemas
integrados. Las BD individuales pueden verse como documentos y pueden agregarse etiquetas XML
(Extensible Markup Language) a cada documento para describir su contenido. XML es un lenguaje
similar a HTML (Hipertext Markup Language), pero es usado como un estándar para intercambio de
datos en vez de presentación de datos. Las etiquetas XML se usan para identificar elementos, sub-
elementos y atributos que almacenan datos. El esquema puede especificarse usando DTD
(Document Type Definition) o por un esquema XML que identifica los elementos, sus atributos y sus
relaciones con otros.
3.1.1.6. Data warehouses y minería de datos
Los data warehouses se desarrollaron en los 90s para proporcionar un método de captura de datos
consolidando de muchas bases de datos. Un data warehouse generalmente almacena datos

históricos de una organización, con el propósito de hacer minería de datos, que es un proceso de
análisis de datos estadísticos para permitir a las organizaciones analizar sus propios registros.
3.2. Definición de Relación

La estructura básica del modelo relacional es simple y fácil de entender a nivel intuitivo. Permite
separar los niveles conceptual y físico, de modo que el diseño conceptual puede ser desarrollado sin
considerar las estructuras de almacenamiento. Usuarios y diseñadores encuentran que el modelo
permite expresar nociones conceptuales de los datos de un modo fácil de entender. Las operaciones
de los datos también son fáciles de expresar y no requieren que el usuario se familiarice con las
estructuras de almacenamiento usadas. El modelo usa unos cuantos comandos muy poderosos que
permiten manipular los datos de forma simple o compleja. Por estas razones, el modelo relacional se
ha convertido en el modelo de datos más popular.
El modelo relacional se basa en el concepto de relación, que se representa físicamente como una
tabla o un arreglo de dos dimensiones (matriz). En este modelo, las tablas se usan para contener la
información de los objetos a representarse en la BD. Tanto entidades como interrelaciones se
representan usando tablas.
El modelo relacional se basa en la noción matemática de relación. Codd y otros investigadores

extendieron la noción para aplicarla al diseño de BD. De este modo, es posible sacar ventaja del
poder de abstracción matemático y la expresividad de la notación matemática para desarrollar una
estructura de BD simple pero poderosa.
Para comprender el significado estricto de relación, se requieren algunas nociones matemáticas.

Suponiendo dos conjunto D1 y D2, con D1 = {1,3} y D2 = {a,b,c}. Se puede obtener el producto
Cartesiano de estos dos conjuntos, escrito D1 x D2, que es el conjunto de todos los pares ordenados
donde el primer elemento es un miembro de D1 y el segundo elemento es un miembro de D2. Otra
forma de verlo es como una combinación de elementos donde el primero corresponde a D 1 y el
segundo a D2. Por lo tanto:
D1 x D2 = { {1, a}, {1, b}, {1, c}, {3, a}, {3, b}, {3, c} }
Una relación es simplemente un subconjunto de este producto Cartesiano. Por ejemplo:
R = { {1, a}, {3, a} }
es una relación. Generalmente se especifica que pares ordenados corresponden a la relación

indicando alguna regla para la selección. Por ejemplo, R incluye todos los pares ordenados en los
que el segundo elemento es a, esto se puede expresar:
R = { (x, y) | x ∈ D1 y y ∈ D2, y y = a}
Usando el mismo conjunto, se puede crear otra relación, S, En la que el primer elemento es siempre
3:
S = { (x, y) | x ∈ D1 y y ∈ D2, y x = 3} ∴ S = { {3, a}, {3, b}, {3, c} }
La noción de relación se puede extender a tres conjuntos de forma natural, incluso se puede ir más
allá u definir una relación general en el dominio n. Suponiendo que D1, D2, . . ., Dn son n conjuntos.
Su producto Cartesiano se define como:

D1 x D2 x . . . x Dn = { (d1, d2, . . ., dn) | d1 ∈ D1, d2 ∈ D2, . . . , dn ∈ Dn}
El producto Cartesiano generalmente se expresa como:

∏ ni=1 D1
Una relación en los n conjuntos es cualquiera n-tuplas elegidas de este producto Cartesiano. Nótese
que en la definición de las relaciones se ha especificado el dominio o conjunto desde el cual se
eligen los valores.
Aplicando estos conceptos a BD, suponiendo que A1, A2, . . ., An son atributos con los dominios D1,
D2, . . ., Dn. El esquema relacional R es un conjunto de atributos con su correspondientes dominios; o
sea, el conjunto {A1, A2, . . ., An} con sus correspondientes dominios {D1, D2, . . ., Dn} es un esquema
relacional. Una relación r en un esquema relacional R es un conjunto de los nombres de atributos
con sus correspondientes dominios, o sea que la relación r es un conjunto de n-tuplas (A1:d1, A2:d2,
…, An:dn) tales que d1 ∈ D1, d2 ∈ D2, …, dn ∈ Dn. Cada elemento en una de estas n-tuplas consiste
de un atributo y un valor de ese atributo. Normalmente, cuando se escribe una relación como una
tabla, se listan los nombres de los atributos como encabezados de columnas y las tuplas usando
valores del dominio apropiado, por lo que las tuplas tienen la forma (d1, d2, . . ., dn). De esta forma,
una relación en el modelo relacional es cualquier subconjunto del producto Cartesiano de los
dominios de los atributos. Una tabla es simplemente una representación de esa relación.
3.2.1. Partes
Una relación se representa como una tabla bidimensional en la que los renglones corresponden a
registros individuales, llamados tuplas (o tuples) y las columnas corresponden a los atributos.
El dominio de un atributo es el conjunto permitido de valores para ese atributo y pueden ser distintos
o dos o más atributos pueden tener el mismo dominio.
La tabla, con todos sus renglones descritos, es una instancia o extensión de la relación. La
estructura de la tabla, junto con una especificación del dominio y otras restricciones sobre los
posibles valores, muestran la intensión de la relación, también llamada esquema de la BD.
Estrictamente hablando, el esquema también incluye dominios, vistas, conjuntos de caracteres,
restricciones, procedimientos almacenados, disparadores, autorizaciones y otra información
relacionada. El esquema de la relación se puede representar usando el nombre de cada relación,
seguido de los nombres de atributos entre paréntesis:
Cliente (idCliente, nombre, domicilio, límiteCredito)
El atributo idCliente está subrayado porque se acostumbra subrayar la llave primaria en el esquema
de la relación.
3.1.1.7. Grado y Cardinalidad
El número de columnas en una tabla es llamado grado de la relación. Esto significa que cada
renglón de la tabla debe contener tantos valores como indique el grado. Una relación que tiene sólo
una columna tiene grado uno y se llama relación unaria. Una relación con dos columnas es binaria,
una de tres ternaria, y después de eso generalmente se usa el término n-aria. El grado de la
relación es parte de la intensión de la relación y nunca cambia.

En contraste, el número de renglones en una tabla, se llama cardinalidad de la relación, cambia
cuando se agregan nuevas tuplas o se borrar. La cardinalidad es una propiedad de la extensión de la
extensión de la relación, la instancia particular de la relación en un momento dado.
3.1.1.8. Llaves de la Relación
Ya que una relación es un conjunto y un conjunto no duplica elementos, siempre es posible hablar
por separado de los elementos. En una relación de BD, las tuplas son conjuntos de elementos, así
que siempre debe ser posible separar cada tupla. Esto significa que siempre debe haber un atributo,
o alguna combinación de atributos, que distingue a las tuplas. Una llave es el conjunto mínimo de
atributos que identifica unívocamente cada tupla en una relación. Una llave formada por más de un
atributo es llamada llave compuesta. En una relación siempre habrá una llave primaria, que es la
llave candidata elegida como llave de la relación, y esto implica que siempre habrá una llave
candidata, una llave candidata es cualquier conjunto de atributos que puede ser elegido como una
clave en una relación. Las llaves no elegidas como llave primaria son llaves alternas. En el peor de
los casos, todos los atributos se requerirán para identificar a cada tupla, sin embargo, generalmente,
sólo se requiere un pequeño conjunto de atributos para distinguir entre tuplas. Hay que notar que una
instancia de la tabla no puede usarse para probar que un atributo o combinación de atributos es una
llave candidata, el hecho de que no existan duplicados par los valores que aparecen en un momento
dado no garantizan que los duplicados no son posibles. Sin embargo, la presencia de duplicados en
una instancia puede comprobar que alguna combinación de atributos no es una llave candidata. La
identificación de llaves candidatas requiere que se considere el significado de los atributos
involucrados de modo que se pueda tomar una decisión acerca de los valores que pueden duplicarse
en el minimundo. Sólo al usar la información semántica e identificando las suposiciones para el
modelo se puede asegurar que una combinación de atributos es una llave candidata.
Una llave foránea (ajena o externa) es un atributo o combinación de atributos de una relación que
no es la llave primaria de la relación pero que es llave primaria en alguna relación, generalmente
diferente. Las llaves foráneas son muy importantes en el modelo relacional porque se usan para
representar la conexión lógica entre relaciones; si la llave hace referencia a su propia relación se dice
que es una llave foránea recursiva.
3.3. Propiedades de una Relación

Una tabla que representa una relación tiene las siguientes características:
 Cada celda de la tabla contiene sólo un valor.

 Cada columna tiene distinto nombre, que es el nombre de los atributos representados.
 Los valores en una columna tienen el mismo dominio, ya que todos los valores corresponden
a valores del atributo.
 Cada tupla es distinta, no existen tuplas duplicadas.
 El orden de las tuplas no es importante.
La mayoría de las características especificadas para las tablas resultan de las propiedades de las
relaciones. Ya que una relación es un conjunto, el orden de los elementos no cuenta, por lo tanto, en
una tabla el orden de los renglones no es importante. En un conjunto, los elementos no se repiten,
similarmente, en una tabla, no existen renglones duplicados. Cuando se obtiene el producto
Cartesiano de valores simples, por ejemplo, enteros, cada elemento en cada tupla es un valor
simple, similarmente, cada celda de una tabla contiene sólo un valor. En una relación, el valor posible
para una posición dada está determinado por el conjunto o dominio en el cual se define la posición,

en una tabla, los valores en cada columna deben corresponder con el dominio del atributo. En una
relación matemática, el orden de los elementos en una tupla es importante, por ejemplo, es par
ordenado (1, 2) es diferente que el par ordenado (2, 1), como se pude ver al localizar un punto en un
plano usando coordenadas Cartesianas. Sin embargo, en las tablas, el orden de las columnas no es
importante, la razón es que el encabezado de las columnas indica a que atributo pertenece el valor,
sin embargo, una vez que la estructura de la tabla se elige, el orden de los elementos con los
renglones de la extensión debe corresponder al orden de los nombres de las columnas.
3.4. Restricciones
Una restricción (constraint) es una regla que limita los valores en la BD. Un estado legal de la BD
es aquel que obedece a todas las restricciones. Parte del trabajo de un DBMS es obligar a cumplir
esas restricciones, para asegurar que cualquier dato ingresado genere una instancia legal de la BD.
Existen diversos tipos de restricciones:
3.4.1. Restricciones de Integridad

Es importante preservar la integridad, esto significa que los datos son correctos e internamente
consistentes en la BD, esto se logra evitando que los usuarios ingresen datos incorrectos. El modelo
relacional permite definir restricciones de integridad, que son reglas o restricciones que aplican a
todas las instancias de la BD y son definidas por el modelo relacional.
Una restricción de llave primaria, llamada integridad en la entidad, define que en una relación
ningún atributo de la llave primaria puede ser valor nulo. Un valor nulo es el valor dado a un atributo
en una tupla si el atributo es inaplicable o su valor desconocido. Los valores nulos no son lo mismo
que el valor cero ó el carácter de espacio en blanco.
Por definición, una llave primaria es el identificador mínimo que se usa para identificar de manera
única a las tuplas, esto implica que ningún subconjunto de la llave primaria es suficiente para
proporcionar identificación única de tuplas. Si se permiten valores nulos para una parte de la llave
primaria, se estaría demostrando que no se requieren todos los atributos para distinguir entre tuplas,
lo cual contradice la definición. Todas las llaves de la relación, tanto primarias como candidatas,
deben tener valores únicos. En SQL, se puede identificar la llave primaria usando una restricción de
llave primaria cuando se crea la tabla. El sistema forzará entonces las restricciones de no valores
nulos y llaves únicas automáticamente. Para las llaves candidatas, la mayoría de los sistemas
permiten especificar restricciones de valores únicos y no nulos.
La regla de integridad llamada integridad referencial aplica a llaves foráneas. La integridad

referencial indica que, si existe una llave foránea, entonces su valor de llave foránea debe
corresponder al valor de alguna tupla en la llave primaria en la relación a la que pertenece, o el valor
de la llave foránea debe ser totalmente nulo. SQL permite especificar restricciones de llave foránea
cuando se crea una tabla.
3.4.2. Restricciones de Usuario
3.1.1.9. En base a consecuencias de operaciones de Borrado y Modificación.

 Operación Restringida (RESTRICT). El borrado o modificación de las tuplas de la relación
que contiene la clave primaria referenciada sólo se permite si no existen tuplas con dicha
clave en la relación que contiene la clave externa.
 Operación con transmisión en cascada (CASCADE). El borrado o modificación de las
tuplas de la relación que contiene la clave primaria referenciada lleva consigo el borrado o
modificación en cascada de las tuplas en la relación que contiene la clave externa
 Operación con puesta a nulos (SET NULL). El borrado o modificación de las tuplas de la
relación que contiene la clave primaria referenciada lleva consigo poner a nulos los valores de
las claves externas de las tuplas en la relación que contiene la clave externa.
 Operación con puesta a valor por omisión (SET DEFAULT). El borrado o modificación de
las tuplas de la relación que contiene la clave primaria referenciada lleva consigo poner el
valor por omisión a las claves externas de las tuplas en la relación que contiene la clave
externa.
 Operación que desencadena un procedimiento del usuario. El borrado o modificación de
las tuplas de la relación que contiene la clave primaria referenciada pone en marcha o ejecuta
un procedimiento definido por el usuario (Trigger).
3.1.1.10. En base a las relaciones entre atributos
 Restricción de intrarelación sobre atributos. El valor válido de un atributo en una tupla

depende de los valores de otros atributos de la misma tupla dentro de la relación.
 Restricción de intrarelación sobre tuplas. El valor válido de un atributo en una tupla
depende de los valores de otros atributos en otras tuplas dentro de la relación
3.1.1.11. En base a las relaciones entre elementos
 Restricción de interrelación. El valor válido de un atributo depende de los valores de otros

atributos contenidos dentro otra relación.
 Restricción sobre dominios. El valor válido de un atributo depende de un conjunto de
dominios. Ya que cada atributo tiene un dominio asociado, existen restricciones el conjunto
de valores que se permiten para los atributos de las relaciones. Esto es llamado restricciones
de dominio y pueden forzarse en SQL definiendo el dominio para cada atributo cuando se
crea una tabla. Una alternativa es usar tipos de datos predefinidos y agregar una restricción
llamada opción check, que permite especificar que el valor de un atributo debe corresponder
al conjunto de valores especificado, o que debe obedecer una condición que se especifica
usando lógica de predicados.
Existen otros tipos de restricciones, referidas como restricciones generales, las cuales pueden ser
restricciones de tablas, que definen reglas sobre los valores permitidos en una tabla, o aserciones
que especifican un predicado dado debe ser cierto para todos los estados de la BD. Las restricciones
generales se fuerzan por el DBMS cuando se hacen cambios a la BD. El sistema verifica que los
cambios no violen las restricciones antes de permitir que se realicen permanentemente.
3.5. Lenguajes Relacionales de Manipulación de

Datos

Existe gran variedad de lenguajes usados para RDBMs. Algunos son procedurales, donde el
usuario indica exactamente cómo manipular los datos. El álgebra relacional es un ejemplo de
lenguaje procedural. Otros son no procedurales o declarativos, que permiten que el usuario indique
qué datos necesita pero no exactamente cómo localizarlos. El cálculo relacional y SQL son
lenguajes no procedurales. Algunos lenguajes son gráficos, y permiten que el usuario de un
ejemplo o ilustración de los datos a encontrar. QBE (Quero By Example) es un lenguaje gráfico que
permite proporcionar ejemplos de datos que se desean extraer. Otra categoría es lenguajes de
cuarta generación (4GL), que permiten crear una aplicación completa usando unos cuantos
comandos en un ambiente amigable, generalmente manejado con menús. Algunos sistemas aceptan
una variedad de lenguaje natural, algunas veces llamado lenguaje de quinta generación, que es
una versión restringida del inglés.
Tanto el álgebra relacional como el cálculo relacional son lenguajes formales, no amigables al
usuario. No se implementan en su forma nativa en los DBMSs, pero se usan como base para otros
lenguajes de manipulación de datos de BD relacionales de alto nivel. Estos lenguajes son
interesantes porque ilustran la operación básica requerida de cualquier lenguaje de manipulación de
datos, y porque sirven como estándar de comparación de otros lenguajes relacionales.
Al diseñar una BD se realiza una abstracción general. Para crear aplicaciones se necesitan
lenguajes claros y precisos para expresar la lógica del proceso. Existen cuatro estrategias para
manipulación de datos:
 Algebra Relacional
 Cálculo Relacional
 Lenguajes Orientados a la Transformación
 Consulta por Ejemplo (QBE)
3.5.1. Álgebra Relacional
El álgebra relacional es un lenguaje teórico con operadores que se aplican sobre una o dos
relaciones para producir otra relación, de modo que los operandos y el resultado son tablas. Date
originalmente propuso ocho operaciones, pero se han desarrollado otros. Las operaciones más
básicas, Selección, Proyección y Reunión (Join), permiten desarrollar la mayoría de las operaciones
de extracción de datos importantes. Existen diversas variantes de las sintaxis de los comandos de
álgebra relacional.
El Álgebra Relacional define operadores que aplican sobre tablas, creando una nueva tabla, donde
se requiere saber qué se desea y cómo.
El Álgebra Relacional tiene cinco operaciones fundamentales con las cuales se puede realizar
cualquier consulta:
 Proyección
 Selección
 Unión
 Diferencia
 Producto Cartesiano
Además de las operaciones básicas se pueden realizar tres operaciones adicionales:
 Intersección
 Producto Theta (Join)

 División
3.1.1.12. Proyección
El operador Proyección tiene como entrada una relación y produce como resultado un subconjunto
vertical de la relación con sólo aquellos atributos especificados por el usuario, eliminando duplicados.
El orden en el cual aparecen los atributos, es el que se indica cuando se hace la proyección. El
número de atributos que se pueden proyectar es como máximo el mismo número de atributos de la
relación origen y como mínimo un solo atributo.
Sintaxis: ∏ A1 ,..., An (r)
Donde A1 ,..., An es la lista de atributos y "r" la relación sobre la que se actúa.
Empleado
Número de Nombre del Salario Código
Empleado Empleado Depto.
1 Pedro 12,000 VE
2 Luís NO
3 Francisco 36,000
4 Lorena 24,000
5 Gabriela 24,000 NO
La Proyección de los atributos Nombre y Número de empleado, es:
∏ Nombre del Empleado, Número de empleado (Empleado)
RESULTADO
Nombre del Número de
Empleado Empleado
1 Pedro
2 Luís
3 Francisco
4 Lorena
5 Gabriela
3.1.1.13. Selección
El operador Selección acepta una sola relación como entrada y produce como resultado un
subconjunto horizontal de todos los atributos de la relación origen y las tuplas que sean
especificadas por el usuario en el predicado. El predicado admite varios grados de complejidad y
puede incluir operadores lógicos (AND, OR y NOT). Para indicar precedencia de operadores se usan
paréntesis.
Las comparaciones pueden realizarse con valores literales, valores contenidos en los atributos, o
expresiones matemáticas que involucren valores literales de los atributos.
Sintaxis: σ P (r)

Donde r es la relación sobre la que se actúa y P es el predicado que debe cumplirse
Empleado
1 Pedro 12,000 VE
2 Luís NO
3 Francisco 36,000
4 Lorena 24,000
La Selección de todos los empleados del departamento de nómina, es:
σ Cod.Depto=‘NO’ (Empleado)
RESULTADO
2 Luís NO
Los operadores que pueden usarse para el predicado son los lógicos y relacionales:
<, >, >=, <=, =, ≠, ∧(and), ∨(or), ¬ (not)
3.1.1.14. Unión
Ya que las relaciones son básicamente conjuntos de n tuplas, el álgebra relacional incluye una
versión de los operadores de conjuntos, unión, intersección y diferencia.
El operador Unión acepta como entrada dos relaciones con el mismo grado, los mismos atributos
(los dominios de los i-ésimos atributos deben coincidir) en el mismo orden y produce como resultado
todos los atributos y todas las tuplas de ambas relaciones.
Si existe alguna tupla con la misma información en ambas relaciones, esta tupla sólo aparece una
vez en el resultado.
Sintaxis: r 1 U r2
Donde r1 y r2 son las relaciones sobre las que se actúa.
Empleados Antiguos Empleados Nuevos

Número de Nombre del Salario Número de Nombre del Salario
Empleado Empleado Empleado Empleado
1 Pedro 12,000 3 Francisco 36,000
2 Luís 4 Lorena 24,000
3 Francisco 36,000 5 Gabriela 24,000
La UNIÓN de las relaciones anteriores, es:
Empleados Antiguos U Empleados Nuevos

RESULTADO
Número de Nombre del Salario
Empleado Empleado
1 Pedro 12,000
2 Luís
3 Francisco 36,000
4 Lorena 24,000
5 Gabriela 24,000
3.1.1.15. Intersección
El operador Intersección acepta como entrada dos relaciones y obtiene como resultado la todas las
tuplas que tengan exactamente la misma información en todos los atributos.
Sintaxis: (r1 ∩ r2) ó r1 - (r1 - r2)
Donde r1 y r2 son las relaciones sobre las que se actúa
Empleados Antiguos Empleados Nuevos

Número de Nombre del Salario Número de Nombre del Salario
Empleado Empleado Empleado Empleado
1 Pedro 12,000 3 Francisco 36,000
2 Luís 4 Lorena 24,000
3 Francisco 36,000 5 Gabriela 24,000
La INTERSECCIÓN de las relaciones anteriores, es:
Empleados Antiguos ∩ Empleados Nuevos
RESULTADO
Número de Nombre del Salario
Empleado Empleado
3 Francisco 36,000
3.1.1.16. Diferencia
El operador Diferencia acepta como entrada dos relaciones que tengan al menos un atributo en
común, en donde el resultado tendrá todos los atributos de la primera relación y las tuplas que no
aparezcan en la segunda relación.
Sintaxis: (r1 - r2)

Departamento Empleado
Cod. Nombre del Número de Nombre del Salario Cod.
Depto. Depto. Empleado Empleado Depto.
VE Ventas 1 Pedro 12,000 VE
NO Nómina 2 Luís NO
IN Investigación 3 Francisco 36,000
ME Mercadotecnia 4 Lorena 24,000
RE Resultados 5 Gabriela 24,000 NO
La DIFERENCIA de las relaciones anteriores, es:
(Departamento – Empleado)
RESULTADO
Cod. Nombre del
Depto. Depto.
IN Investigación
ME Mercadotecnia
RE Resultados
3.1.1.17. División
La División es una operación binaria donde la estructura completa de una relación (el divisor) es una
porción de la estructura de la otra (el dividendo). El resultado es el conjunto de valores en los
atributos que aparecen sólo en el dividendo coinciden con todas las tuplas del divisor.
Sintaxis: (r1 ÷ r2)
Departamentos Ciudades
Cod. Nombre del Cód. Nombre Cód. Nombre
Depto. Depto. Ciudad Ciudad Ciudad Ciudad
VE Ventas DF D.F. DF D.F.
VE Ventas GD Guadalajara GD Guadalajara
NO Nómina DF D.F.
NO Nómina GD Guadalajara
IN Investigación DF D.F
La DIVISIÓN de las relaciones anteriores, es:
(Departamentos ÷ Ciudades)
RESULTADO
Cod. Nombre del
Depto. Depto.
IN Investigación
3.1.1.18. Producto Cartesiano
El operador Producto Cartesiano acepta como entrada dos relaciones y obtiene como resultado la
combinación de cada tupla de la primera relación con todas las de la segunda relación. Las columnas
resultantes son las columnas de r1 seguidas de las columnas de r2.
Si el número de tuplas de r1 es n1 y el de r2 es n2, el resultado será n1 x n2
Sintaxis: (r1 X r2)

El PRODUCTO CARTESIANO de las relaciones anteriores, es:
(Departamento X Empleado)
RESULTADO
Cod. Nombre del Número de Nombre de Salario Cod.
VE Ventas 2 Luís NO
VE Ventas 3 Francisco 36,000
VE Ventas 4 Lorena 24,000
VE Ventas 5 Gabriela 24,000 NO
NO Nómina 1 Pedro 12,000 VE
NO Nómina 3 Francisco 36,000
… …
3.1.1.19. Producto Theta (Reunión o Join)
Existen diversas operaciones que se pueden definir basadas en el producto cartesiano de relaciones,
la más general es la operación producto theta ó join. El operador Join acepta como entrada dos o
mas relaciones teniendo cada una al menos un atributo en común con las otras relaciones, y produce
como resultado a todos los atributos de las relaciones origen, y las tuplas se concatenan con
aquellas tuplas cuyos valores en las relaciones origen cumplen con la condición que se indica para
hacer la reunión. El resultado de esta operación se define ejecutando una operación de selección
sobre el producto.
Cuando el predicado es de igualdad sobre las columnas en común, se dice que es un Equijoin de
tablas. Un Join Natural es un equijoin en el que las columnas repetidas se eliminan y es el join más
común por lo que generalmente sólo se le dice join. Otra variación es el Semijoin, que puede ser
izquierdo o derecho y donde los resultados corresponderán a las tuplas de la relación izquierda o
derecha que participan en el join. Otro tipo es el Join Externo, donde las tuplas de las tablas
originales que no tienen coincidencias no se muestran en el resultado. Existen también dos
variaciones del Join Externo, el Join Externo Izquierdo y Join Externo Derecho, en los que sólo se
muestran las tuplas sin coincidencia de la tabla izquierda o derecha.
Las columnas en común sólo se muestran una vez.
Sintaxis: (r1 θP r2) ó σP (r1 x r2)

Donde r1 y r2 son las relaciones sobre las que se actúa y P representa el predicado de la selección.
El JOIN con la columna en común del código del departamento en las relaciones anteriores, es:
(Departamento θ Departamento.codDepto= Empleado.codDepto Empleado)

RESULTADO
Cod. Nombre del Número de Nombre de Salario
Depto. Depto. Empleado Empleado
VE Ventas 1 Pedro 12,000
NO Nómina 2 Luís
NO Nómina 5 Gabriela 24,000
Existen muchas extensiones del álgebra relacional, se han agregado métodos para manejar valores
nulos de modo sistemático y varios investigadores han agregado funciones como SUM, AVG, MAX,
MIN y COUNT.
3.5.2. Cálculo Relacional

El Cálculo Relacional es un lenguaje de manipulación de datos formal y no procedural o declarativo
en el cual el usuario simplemente especifica qué datos deben extraerse. El cálculo relacional no está
relacionado a la familia de cálculo diferencial e integral en matemáticas, pero usa una rama de la
lógica simbólica llamada cálculo de predicado. Cuando se aplica a las BD, puede ser en dos
formas: cálculo relacional orientado a tuplas y cálculo relacional orientado a dominios. Ambos usan
conceptos de lógica simbólica.
En lógica, un predicado es una sentencia declarativa que puede ser falsa o verdadera. Por ejemplo,
“Juan es un cliente”. Si un predicado contiene una variable, por ejemplo “X es un cliente”, debe existir
un conjunto o rango asociado para remplazar a X. Cuando algunos valores del rango se substituyen
para x, el predicado puede ser verdadero o falso.
Si se usa P para referirse a un predicado, entonces { x | P (x) } indica el conjunto de todos los
valores x de modo que P sea verdadero. Los predicados se pueden conectar con conectivos
lógicos ∧ (and), ∨ (or) y ¬ (not) para formar predicados compuestos:
P(x) ∧Q(x) P(x) ∨Q(x) P(x) ¬ Q(x)
Donde P y Q son predicados.
Una conjunción consiste de predicados conectados por AND, una disyunción consiste de
predicados conectados por OR y una negación es un predicado precedido por un NOT.

En lógica existen dos cuantificadores usados con los predicados para indicar cuántas instancias
aplican al predicado. El cuantificador existencial, EXISTS, indica “Existe”. Es usado en aserciones,
o declaraciones que deben ser verdaderas para al menos una instancia, su símbolo es ∃, como:
∃ x (P (x))
El cuantificador universal, FORALL, indica “Para todos”, su símbolo es ∀. Se usa en aserciones

para cada instancia, como:
∀ s (P (s))
que indica que P(s) es verdadero para todos los valores s, en el rango. Una variable sin un calificador
(∃ o ∀) es llamada variable libre, y una con un calificador es llamada una variable limitada.
3.1.1.20. Cálculo Relacional Orientado a Tuplas
En este lenguaje, expresamos variables que representan tuplas. Si por ejemplo existe una tupla t
contenida en una relación r escribiremos t ∈ r. Si queremos expresar el valor que toma el atributo A
para la tupla t, lo haremos de la siguiente forma: t[A].
Como dijimos, el cálculo relacional es declarativo (no tiene procedimientos), por tanto cuando
deseamos obtener un conjunto de tuplas (una relación) a partir de otras tenemos que expresarlo
usando los medios que el cálculo relacional nos ofrece, si por ejemplo, queremos obtener una
relación con el conjunto de tuplas que cumplen el predicado P, tendremos que expresarlo de esta
manera: {t | P(t)}. Por ejemplo: "Queremos tener una lista completa de todos aquellos clientes que
tienen un préstamo cuyo importe sea más de un millón" (selección).
{t | t ∈ Préstamo ∧t[importe] > 1,000,000}
El cuantificador ∃ sirve para realizar proyecciones. "Queremos saber los nombres de los clientes
que poseen un préstamo de más de un millón".
{t | ∃
 s ∈ préstamo ∧s[importe] > 1.000.000 ∧t[nombre_cliente] = s[nombre_cliente] }
Con la anterior operación definimos una nueva relación que consta de un sólo atributo
(nombre_cliente).
Hasta ahora hemos usado el conectivo ∧, pero también podremos usar ∨ y ¬. Con estos conectivos
podemos realizar la unión, diferencia e intersección de conjuntos. "Queremos obtener una relación
con los nombres de los clientes que o bien tienen una cuenta, o bien un préstamo, o ambas cosas en
la sucursal 10" (unión).
{ t | ∃ s (s ∈ préstamo ∧t[nombre_cliente] = s[nombre_cliente] ∧s[nombre_sucursal] = "10" ) ∨

 ∃ u (u ∈ deposito ∧t[nombre_cliente] = u[nombre_cliente] ∧u[nombre_sucursal] = "10") }
El conectivo ∨ actúa aquí como unión, haciendo incluso que los clientes que tengan depósito y
préstamo, aparezcan solamente una vez.
Si queremos realizar una intersección de conjuntos, por ejemplo obtener una relación de todos los
clientes que tienen depósito y préstamo en la sucursal 10, bastaría cambiar el ∨anterior por un ∧. Por

último para hacer una diferencia, habrá que cambiar el ∨ por un ∧ ¬, con lo que obtendremos los
nombres de los clientes que tienen préstamo en la 10 pero no tienen depósito en dicha sucursal.
Por último, para realizar un producto cartesiano, por ejemplo, "Queremos obtener el nombre de los
clientes con préstamo en la sucursal principal, y las ciudades en las que viven".
{t | ∃ s (s ∈ préstamo ∧ t[nombre_cliente] = s[nombre_cliente] ∧ s[nombre_sucursal] = "Principal" ∧

 ∃ u (u ∈ cliente ∧ u[nombre_cliente] = s[nombre_cliente] ∧ t[ciudad] = u[ciudad] ))}
3.1.1.21. Cálculo Relacional Orientado a Dominios
Los datos que se guardan en variables correspondientes a atributos. Las variables se refieren a
atributos, lo que en cálculo relacional orientado a tuplas era t[A] es ahora A1, por tanto para referirse
a una tupla se deben nombrar todas las variables correspondientes a los atributos de esa tupla. (< x 1,
x2, ....., xn >). Por ejemplo, una tupla de préstamo se expresaría: < p, s, c, i > con: p = num_prestamo;
s = nombre_sucursal; c = nombre_cliente; i = importe.
En el cálculo relacional orientado a dominios, la expresión general tendrá la forma: { < x 1, x2, ....., xn >
| P(< x1, x2, ....., xn >) }
Las distintas operaciones en este lenguaje serían:
Selección: Queremos los nombres de los clientes, número de sucursal, número de préstamo e
importe de todos aquellos préstamos cuyo importe sea superior a un millón de pesos:
{ < p, s, c, i > | < p, s, c, i > ∈ prestamo ∧i > 1,000,000 }
Proyección: Utilizaremos la cláusula ∃ . Por ejemplo sólo queremos los nombres de los clientes con
préstamo superior a un millón.
{ < c > | ∃  < p, s, c, i > ∈ prestamo ∧i > 1,000,000 }
Unión: Nombre de clientes que tengan préstamo, depósito o ambas cosas en la sucursal principal.
{ < c > | ∃  < p, s, c, i > ∈ prestamo ∧s = "Principal" ∨∃ < s, cu, c, sa > ∈ deposito ∧s = "Principal" }
Para la intersección y la diferencia, al igual que en el cálculo relacional orientado a tuplas basta
sustituir el ∨por un ∧o un ∧¬ respectivamente.
Al igual que el álgebra relacional, el cálculo relacional tampoco es amigable para el usuario, por esta
razón se han desarrollado lenguajes comerciales orientados al usuario, y que se basan en alguno de
los lenguajes formales.
3.5.3. Lenguajes Orientados a la Transformación

Estos lenguajes no están orientados a procedimientos. Transforman los datos de entrada expresados
como relaciones, en resultados expresados en una sola relación. Proporcionan estructuras fáciles de
usar. SQUARE, SEQUEL y su descendiente SQL, son ejemplos de estos lenguajes. Incorporan entre
otras funciones:

 Definición de esquemas de datos
 Restricciones de integridad y seguridad
 Control de transacciones
3.5.4. Consulta por Ejemplo (QBE – Query By Example)
Ofrecen al usuario una imagen de la estructura de la tabla. Ejemplo: Access y Paradox.
El usuario llena alguna forma con los datos que requiere y el sistema responde con datos reales en
el formato especificado
3.6. Normalización
El objetivo básico del modelado lógico es desarrollar una buena descripción de los datos, sus
interrelaciones y sus restricciones. Para el modelo relacional, esto significa que se debe identificar un
conjunto correcto de relaciones. Sin embargo, la tarea de elegir las relaciones en ocasiones es difícil
porque existen muchas opciones que debe considerar el diseñador. Las técnicas presentadas a
continuación se basan en un gran conjunto de investigaciones sobre el proceso de diseño lógico
generalmente llamado normalización.
La normalización es el proceso que sirve para crear relaciones bien estructuradas que cubren el
modelo de las operaciones de una empresa, siguiendo un conjunto de principios bien definidos y
mediante el cual se dividen relaciones en múltiples relaciones para eliminar las anomalías y
manteniendo la integridad de los datos.
Siguiendo los principios de normalización, se obtiene un diseño que es altamente flexible,

permitiendo que es modelo sea extendido cuando se necesitan nuevos atributos, entidades e
interrelaciones. El diseño de la BD creado de esta forma refuerza cierto tipo de restricciones de
integridad y reduce la redundancia, ahorrando espacio y evitando inconsistencias de datos. La
esencia de la Normalización es que cuando una relación tiene anomalías, estas se eliminan
dividiendo la relación en dos o más, donde cada una contendrá un solo tema.
3.6.1. Anomalías de datos

Las anomalías son estados de la BD inconsistentes, incompletos o contradictorios. Cuando se
presentan estas anomalías, no es posible representar alguna información, se puede perder
información cuando se realizan algunas actualizaciones y se corre el riesgo de tener inconsistencias.
 Anomalía de Actualización. Inconsistencia de los datos como resultado de datos

redundantes y actualizaciones parciales.
 Anomalía de Borrado. Pérdida no intencionada de datos debido a que se han borrado otros
datos.
 Anomalías de Inserción. Imposibilidad de adicionar datos en la base de datos debido a la
ausencia de otros datos.
El estudio de estas anomalías fue realizado originalmente por Codd, quien identificó las causas y
definió las tres primeras “formas normales”. Una relación se encuentra en una formal normal
específica si satisface el conjunto de requerimientos o restricciones para esa forma. Investigaciones
posteriores realizadas por Boyce y Codd refinaron la tercera forma normal. Las investigaciones
independientes de Fagin, Zaniolo y Delobel generaron la definición de tres nuevas formas. Todas las
formas normales están anidadas, de modo que cada una satisface las restricciones de la anterior,
pero es una mejor forma ya que elimina faltas encontradas en la forma anterior. El objetivo del diseño

debería ser generar un esquema en la forma normal más alta que sea práctica y apropiada para los
datos en la BD. La normalización requiere que se tengan claras las características semánticas del
modelo.
3.6.2. Tipos de Dependencias

En el intento de eliminar las causas de las anomalías, las investigaciones han identificado cuatro
clases de dependencias:
 Dependencia funcionales
 Dependencia transitivas
 Dependencia multivaluadas
 Dependencia de reunión
3.1.1.22. Dependencia Funcional
Una dependencia funcional (DF) es un tipo de relación entre atributos donde un atributo determina
el valor de los otros.
Definición: Si R es el esquema de una relación y A y B son conjuntos no vacíos de atributos en R,

se dice que B es dependiente funcionalmente de A si, y sólo si, cada valor de A en R está
asociado con exactamente un valor de B en R.
Se escribe:
AàB lo que se lee: “A determina funcionalmente a B”.
Para cada valor de A sólo hay un valor de B. Donde A es la determinante y B es el implicado (o

dependiente). B es una información acerca de A. La definición dice que si dos tuplas en una
extensión de R tienen el mismo valor para A, deben tener también el mismo valor para B. Esta regla
no significa que A causa a B o que el valor de B se calcula a partir del valor de A por una fórmula.
Simplemente significa que si se conoce el valor de A y se examina la tabla de la relación R, se
encontrará sólo un valor de B en todos los renglones que tengan el valor dado de A en cualquier
momento. Sin embargo, para un valor B dado, puede haber varios valores diferentes de A. Una
dependencia funcional es pues una interrelación muchos a uno entre los atributos A y B. Nótese
que A o B pueden ser conjuntos que consistan de un solo atributo.
Ejemplo:
Estudiante
IdEstudiante Apellido Carrera Nivel Créditos CURP
1000 Pérez Historia Avanzado 90 AAAA111111
1001 Ramírez Matemáticas Avanzado 95 BBBB222222
1002 López Computación Básico 15 CCCC333333
1003 Bravo Arte Intermedio 63 DDDD444444
1004 Ramírez Computación Básico 25 EEEE555555
Se puede decir que:
{idEstudiante} à {apellido, carrera, nivel, créditos, CURP}

{CURP} à {idEstudiante, apellido, carrera, nivel, créditos}

{Créditos} à {nivel}
Pero no se puede decir que
{Apellido} à {idEstudiante, carrera, créditos, nivel, CURP}

{Créditos} à {idEstudiante, apellido, carrera, CURP}
Ya que el apellido se puede repetir, igual que la carrera o los créditos, pero los créditos determinan
funcionalmente el nivel del estudiante, aunque el valor de créditos no sea único, lo cual indica que
una determinante no necesariamente única.
Algunas dependencias funcionales son llamadas triviales porque siempre se satisfacen en cada
relación. En las dependencias funcionales triviales, el implicado es un subconjunto de la
determinante. Si todos los atributos en el conjunto de la derecha se incluyen en el lado izquierdo de
la dependencia, o si los dos lados son iguales, la DF es trivial, ejemplo:
{A, B} à A
{A, B} à B
{A, B} à {A,B}
3.1.1.23. Dependencia Transitiva
Una dependencia transitiva es un tipo de relación entre mínimo 3 atributos donde Aà B, B à C

pero B no à A.
Definición: Si A, B y C son atributos de la relación R, tales que Aà B, y B à C, entonces C es

transitivamente dependiente de A.
Por ejemplo, en la relación anterior Estudiante, idEstudiante à créditos y créditos à nivel, por lo
tanto idEstudiante à nivel.
Las dependencias transitivas causan anomalías, por lo que es recomendable la eliminación de

ciertos tipos. Por ejemplo, en la tabla Estudiante, no se puede insertar la información de que
cualquier estudiante con 30 créditos sea de nivel Básico hasta que exista ese estudiante, porque eso
requeriría insertar un registro sin idEstudiante, lo que no estaría permitido. Si se borra una tupla de
un estudiante con un cierto número de créditos asociados, se perderá la información del nivel
asociado con esos créditos. Si existen varias tuplas con los mismos créditos y se cambia el nivel
asociado, se puede accidentalmente omitir la actualización de todas las tuplas, dejando la BD en un
estado inconsistente.
3.1.1.24. Dependencia Multivaluada
Fagin identificó otro tipo de dependencia que puede causar problemas diseño, las dependencias
multivaluadas. Una dependencia multivaluada es un tipo de relación entre atributos donde un
atributo multidetermina a otros pero entre los otros no hay una relación. Aàà B, Aàà C pero B no
tiene relación con C.
Ejemplo:

En la siguiente tabla se asume que un profesor puede pertenecer a más de un departamento, por
ejemplo al departamento de Computación y de Matemáticas. Un profesor puede pertenecer a varios
comités, cada uno identificado por el nombre del comité, pero no existe interrelación entre
departamento y comité.
Profesor/Departamento/Comité
idProfesor departamento comité
101 Computación Exámenes
101 Matemáticas Exámenes
101 Computación Titulación
101 Matemáticas Titulación
221 Biología Biblioteca
330 Inglés Exámenes
330 Inglés Admisión
De modo que esto obliga a escribir todas las combinaciones de los valores de departamento con los
valores de comité para cada profesor, o de otra forma, parecería que existe una interrelación entre
departamento y comité. Nótese que la llave de la relación debe ser {idProfesor, departamento,
comité}. Si se desea actualizar un comité al que pertenece el profesor 101, se debe hacer en dos
lugares, si se desea insertar la tupla de un profesor que no pertenece a algún comité no se puede, ya
que comité es parte de la llave y no permite valores nulos. Similarmente, si se borra la membresía
del profesor 221 al comité de Biblioteca, se pierde el resto de la información almacenada sobre él, ya
que no se permiten valores nulos en la llave.
Ya que un profesor no está asociado con un solo departamento, sino con un conjunto de
departamentos y está asociado con un comité específico en un momento dado, el conjunto de
departamentos para un idProfesor particular es independiente del conjunto de comités para el
profesor. Esta independencia es la causa de los problemas.
Definición: Sea R una relación teniendo atributos o conjuntos de atributos A, B y C. Existe una
dependencia multivaluada del atributo B sobre el atributo A si y sólo si el conjunto de valores de B
asociados con un valor de A es independiente de los valores de C.
Se escribe:
Aàà B, y se lee: “A multidetermina a B”.
Si R tiene al menos tres atributos A, B y C, entonces en R(A, B, C), si Aàà B, entonces Aàà C
también. A diferencia de las dependencias funcionales, que hacían ciertas tuplas ilegales en las
relaciones, las dependencias multivaluadas hacen ciertas tuplas esenciales en la relación. En el
ejemplo anterior, es obligatorio incluir ciertas tuplas porque se han incluido otras. Por ejemplo,
cuando se escribe la combinación 101 con los valores de departamento Computación y Matemáticas,
se tienen que escribir dos tuplas para cada valor de comité, Exámenes y Titulación, y colocar cada
valor de departamento en una tupla con cada valor de comité.
Definición alterna de Dependencia Multivaluada:
Más generalmente, si R es una relación con dependencias multivaluadas,

A àà B
entonces en cualquier tabla para R, si dos tuplas t1 y t2, tienen el mismo valor A, entonces deben
existir dos tuplas t3 y t4 que siguen las siguientes reglas:

1. t3 y t4 tienen el mismo valor A que t1 y t2
2. t3 tiene el mismo valor B que t1
3. t4 tiene el mismo valor B que t2
4. si R-B representa los atributos de R que no están en B, entonces t2 y t3 tienen los mismos
valores para R-B y
5. t1 y t4 tienen los mismos valores para R-B
La dependencia Aàà B es llamada dependencia trivial multivaluada si B es un subconjunto de A

o A U B es todo de R.
3.1.1.25. Dependencia de reunión
Dependencia de Reunión es cuando la existencia de una relación depende de la reunión de todas

las combinaciones de otras relaciones. Una dependencia de reunión existe cuando para una relación
R con subconjuntos de sus atributos A, B, …, Z, R es igual a la reunión de sus proyecciones en A, B,
…, Z.
Como se verá más adelante, no todas las descomposiciones son sin pérdida, ya que existen
proyecciones cuyas reuniones no generan la relación original. Por ejemplo, en la relación:
Empleado/Proyecto/Función
nombre Función nombre proyecto
empleado
López diseñador Nueva España
López programador Emprendedor
López diseñador Emprendedor
Pérez diseñador Emprendedor
La tabla muestra qué función realizan los empleados en cada proyecto. Se puede descomponer la
tabla por proyección en dos tablas:
Tabla1 Tabla2
nombre empleado Función función nombre proyecto
López diseñador diseñador Nueva España
López programador programador Emprendedor
Pérez diseñador diseñador Emprendedor
Sin embargo, cuando se reúnen las dos tablas, se obtienen tuplas adicionales que no aparecían en
la tabla original, perdiendo información.
Resultado de Reunión de Tabla1 y Tabla2

nombre función nombre proyecto
empleado
Pérez diseñador Nueva España tupla espúrea
La tabla original puede ser recreada sólo reuniendo una tercera tabla:

Tabla3
nombre nombre proyecto
empleado
López Nueva España
López Emprendedor
Pérez Emprendedor
La recreación depende de esta la reunión de las tres tablas:
Resultado de Reunión de Tabla1, Tabla2 y Tabla3

nombre Función nombre proyecto
empleado
López Diseñador Nueva España
López Programador Emprendedor
3.6.3. Formas Normales

En la práctica, los diseñadores de BD generalmente desarrollan un modelo lógico inicial para la BD
relacional transformando un DER u otro modelo conceptual en un conjunto de relaciones. Se
identifica la PK y las posibles DFs durante el proceso del diseño conceptual. Transformando el DER
el diseñador crea un modelo relacional que está casi totalmente normalizado. Para completar el
proceso de diseño relacional, el diseñador verifica cada relación, identifica un conjunto de DFs para
ella y cualquier otra existente que involucre la PK, normalizando si es necesario. Para guiar el
proceso de normalización sobre PKs se usa un buen conjunto de reglas llamadas formas normales.
3.1.1.26. Primera Forma Normal
Definición. “Una relación está en primera forma normal (1FN) si, y sólo si, todos los valores en la
relación son atómicos para cada atributo en la relación”.
Esto significa que cada atributo en cada renglón, o celda de la tabla, contiene sólo un valor, no puede
contener conjuntos, listas, campos repetidos o grupos en el dominio. Los valores en el dominio
deben ser valores simples que no pueden separarse en otros datos.
Estudiante
Matemáticas
1003 Bravo Arte Inglés Intermedio 63 DDDD444444
En el ejemplo se puede permitir un estudiante realice más de una carrera; se podría intentar
almacenar todas las carreras en una sola columna para cada estudiante. Esto violaría la 1FN. Es
importante mantener las relaciones en 1FN de modo que los operadores relacionales, como se han

definido, funcionen correctamente. En este caso, si se realiza una búsqueda para los alumnos
inscritos en la carrera de Matemáticas “Select idEstudiante From Estudiante where carrera =
“Matemáticas”, ¿se deberían incluir aquellos que también tengan otra carrera? Para evitar las
ambigüedades, cada relación debe tener valores atómicos en sus atributos.
Otra forma de tratar de normalizar podría ser cuando se conoce el número máximo de repeticiones
que un atributo puede tener y se agregan nuevas columnas para los atributos. Por ejemplo, si se
sabe que los estudiantes pueden estudiar máximo dos carreras, se podría intentar poner Carrera1 y
Carrera2 como atributos. Las desventajas de esta aproximación son que se debe saber el número
máximo de repeticiones, y si esto cambia, se deberá modificar el esquema y las aplicaciones que
accedan esos datos; también, las consultas se vuelven más complejas y además se pueden tener
demasiados espacios vacíos (nulos) en la tabla.
Otra alternativa sería hacer los atributos multivaluados parte de la llave. Usando este método, la
nueva tabla contendría múltiples tuplas para cada estudiante con múltiples carreras. Esta solución
dificultará tener la relación en una forma normal de nivel más alto ya que se tendrán muchos valores
duplicados con las consecuentes anomalías de datos.
Pasos para lograr la 1FN:

1. Crear una nueva relación con los atributos que se repiten.
2. Borrar los atributos de la relación original.
3. Formar la llave primaria con la llave primaria de la tabla original y un atributo que
determine funcionalmente el conjunto de valores repetidos.
Estudiante Estudiante/Carrera
IdEstudiant Apellid Nivel Crédito CURP IdEstudiant Carrera
e o s e
1000 Pérez Avanzado 90 AAAA111111 1000 Historia
1001 Ramírez Avanzado 95 BBBB222222 1001 Matemáticas
1002 López Básico 15 CCCC333333 1002 Computación
1003 Bravo Intermedio 63 DDDD444444 1002 Matemáticas
1004 Ramírez Básico 25 EEEE555555 1003 Arte
1003 Inglés
1004 Computación
3.1.1.27. Segunda Forma Normal
Definición. “Una relación está en segunda forma normal (2FN) si, y sólo si, se encuentra en 1FN y
todos los atributos que no son claves dependen por completo de la clave”. Aà B
Un atributo B de una relación R es totalmente dependiente funcionalmente de un atributo o conjunto

de atributos A de R si B es funcionalmente dependiente de A pero no funcionalmente dependiente de
cualquier subconjunto de A.
Suponiendo la tabla:
Estudiante
idMateria idEstudiant nombre estudiante idFacultad salón grado
e
art103a 1001 Pérez 101 H221 A
art103a 1010 Ramírez 101 H221
art103a 1006 López 101 H221 B

cmp201a 1003 Rodríguez 105 M110 A
cmp201a 1006 López 105 M110 C
his205a 1001 Pérez 202 H221
La llave de la relación sería {idMateria, idEstudiante}, por lo que existen atributos que son
dependientes funcionalmente de la combinación de la PK, pero hay otros que son dependientes
funcionalmente de un subconjunto de esa combinación, por ejemplo, aunque nombre estudiante es
funcionalmente dependiente de la combinación {idMateria, idEstudiante}, también es dependiente
funcionalmente de una parte de la PK (idEstudiante).
Claramente, si la relación está en 1FN y la PK consiste de un solo atributo, la relación está

automáticamente en 2FN. Sólo hay que preocuparse de la 2FN cuando la llave es compuesta.
La transformación a 2FN se hace realizando proyecciones sobre la relación original de modo que sea
posible obtener nuevamente la tabla original mediante la reunión de las proyecciones obtenidas. Aún
si no existen atributos que dependan funcionalmente de la PK de la relación original, es importante
mantener la relación (aún sólo con la PK) para poder reconstruir la relación original mediante la
reunión. Esta “relación de conexión” muestra cómo se relacionan las proyecciones.

1. Crear una nueva relación usando los atributos que dependan parcialmente de la clave.
2. Borrar los atributos anteriores de la relación original.
3. Tomar la parte de la clave de que dependan los atributos eliminados (determinante) como
clave primaria de la nueva relación.
Estudiante/Materia Estudiante Materia/Facultad

idMateri idEstudiant grad idEstudiant nombre idMateri idFaculta saló
a e o e estudiante a d n
art103a 1001 A 1001 Pérez art103a 101 H221
art103a 1010 1010 Ramírez cmp201a 105 M110
art103a 1006 B 1006 López his205a 202 H221
cmp201a 1003 A 1003 Rodríguez
cmp201a 1006 C
his205a 1001
3.1.1.28. Tercera Forma Normal
Definición. “Una relación está en tercera forma normal (3FN) si, y sólo si, está en 2FN y todos los
atributos no clave dependen funcionalmente de la clave y sólo de la clave ó son miembros de alguna
llave candidata”. No hay Dependencias Transitivas.
Aún cuando las relaciones en 2FN son mejores que las que sólo están en la 1FN, aún pueden tener
anomalías de datos. La 3FN indica que los atributos no clave deben depender de la clave, sólo de la
clave y nada más de la clave. Ejemplo:
Estudiante
1003 Bravo Arte Intermedio 63 DDDD444444
En esta relación idEstudiante à créditos y créditos à nivel, por lo tanto idEstudiante à nivel.
1. Crear una nueva relación usando los atributos que dependan de otro atributo no clave.
3. Tomar el atributo del cual dependan los atributos eliminados como clave primaria de la nueva
relación.
Estudiante Créditos/Nivel
IdEstudiant Apellid Carrera Crédito CURP Crédito Nivel
e o s s
1000 Pérez Historia 90 AAAA111111 15 Básico
1001 Ramírez Matemáticas 95 BBBB222222 25 Básico
1002 López Computación 15 CCCC333333 63 Intermedio
1003 Bravo Arte 63 DDDD444444 90 Avanzado
1004 Ramírez Computación 25 EEEE555555 95 Avanzado
3.1.1.29. Forma Normal Boyce-Codd
Definición. “Una relación está en forma normal Boyce-Codd (BCFN) si cada determinante es una
clave candidata”.
La definición de la 3FN es la original desarrollada por Codd y es suficiente para relaciones que tienen
una sola llave candidata, pero es deficiente cuando hay múltiples llaves candidatas que son
compuestas o traslapadas. Por ello fue formulada, una nueva definición de la 3FN, nombrada por sus
creadores Boyce y Codd, para tomar en cuenta todos los casos. Ejemplo:
Profesor
nombreProfeso departamento oficina nivel fechaContratació
r n
Álvarez Arte A101 Académico 1975
Bravo Matemáticas M201 Asistente 2000
Dorantes Arte A101 Asociado 1992
García Matemáticas M201 Académico 2001
Hernández Matemáticas M203 Asociado 1990
Salamanca Computación C101 Académico 1980
Salamanca Historia H102 Asociado 2001
Trujillo Computación C101 Instructor 1995
Vega Computación C105 Asociado 2000
En esta tabla se puede asumir que, aunque los nombres no son únicos, no hay dos profesores con el
mismo nombre en el mismo departamento, cada profesor tiene sólo una oficina, un departamento
puede tener varias oficinas y los profesores en el mismo departamento pueden compartir oficinas. A
partir de esas suposiciones, se obtienen las siguientes DFs:
oficina à departamento
nombreProfesor, departamento à oficina, nivel, fechaContratación

nombreProfesor, oficina à departamento, nivel, fechaContratación
En este caso existen llaves candidatas traslapadas (nombreProfesor, departamento) y

(nombreProfesor, oficina). Si se elige (nombreProfesor, departamento) como PK, se obtiene una
determinante que no es PK. Esto viola la FNBC. Nótese que la relación está en 3FN ya que oficina
es parte de una llave candidata.
Pasos para lograr la BCFN:

1. Crear una nueva relación con los atributos que estén determinados funcionalmente
por un determinante que no sea clave candidata.
3. Tomar los atributos determinantes como llave primaria de la nueva relación.
Profesor Oficina/Departamento
nombreProfeso oficina nivel fechaContratació oficin departamento
r n a
Álvarez A101 Académico 1975 A101 Arte
Bravo M201 Asistente 2000 C101 Computación
Dorantes A101 Asociado 1992 C105 Computación
García M201 Académico 2001 H102 Historia
Hernández M203 Asociado 1990 M201 Matemáticas
Salamanca C101 Académico 1980 M203 Matemáticas
Salamanca H102 Asociado 2001
Trujillo C101 Instructor 1995
Vega C105 Asociado 2000
La llave de Oficina/Departamento es oficina, ya que un departamento puede tener varias oficinas,

pero cada oficina pertenece sólo a un departamento. Este esquema está en FNBC ya que la única
determinante es llave. La llave de la segunda es {nombreProfesor, oficina} y también está en FNBC,
ya que su única determinante es la llave. Sin embargo, este esquema no preserva la dependencia
funcional nombreProfesor, departamento à oficina, nivel, fechaContratación, ya que estos atributos
no permanecen en la misma relación, haciendo imposible expresar que estos determinan a los otros
atributos.
En ocasiones, puede no ser deseable transformar una relación en FNBC. En particular, si existen
dependencias funcionales que no se preservan cuando se realiza la descomposición y se vuelve
difícil forzar la dependencia funcional en la BD ya que dos o más tablas deben ser reunidas para
lograrla o se pierde una restricción importante. En ese caso, es preferible mantener la 3FN, que
siempre permite mantener las dependencias.
3.1.1.30. Cuarta Forma Normal
Definición. “Una relación está en cuarta forma normal (4FN) si está en FNBC y no tiene
dependencias de valores múltiples no triviales”. Ninguna relación puede contener dos o más
relaciones 1:n ó n:m. AààB y Aàà C
Aunque la FNBC es suficiente para remover cualquier anomalía relacionada con dependencias
funcionales, las investigaciones de Fagin identificaron la dependencia multivaluada que también
causa problemas de diseño. Ejemplo:
Profesor/Departamento/Comité
idProfesor departamento comité
101 Computación Exámenes
101 Matemáticas Exámenes
101 Computación Titulación
101 Matemáticas Titulación
221 Biología Biblioteca
330 Inglés Exámenes
330 Inglés Admisión
Esta tabla no está en 4FN porque idProfesor àà departamento y idProfesor àà comité.

1. Crear una nueva relación tomando uno de los atributos con dependencia de valores
múltiples.
3. Tomar el atributo que multidetermina a los demás atributos y el atributo
multideterminado como llave primaria de la nueva relación
Profesor/Departamento Profesor/Comité
idProfesor departamento idProfesor comité
101 Computación 101 Exámenes
101 Matemáticas 101 Titulación
221 Biología 221 Biblioteca
330 Inglés 330 Exámenes
330 Admisión
3.1.1.31. Quinta Forma Normal
Definición. “Una relación está en quinta forma normal (5FN) si está en 4FN y además no tiene
dependencias de reunión (Join)”.
Esencialmente, esto significa que las únicas descomposiciones válidas son aquellas que involucran
llaves candidatas. Las dependencias de reunión están relacionadas con dependencias de valores
múltiples, pero pueden ser muy difíciles de identificar porque son sutiles. Si un diseño consiste de
relaciones que están en 5FN, éstas están en su forma más simple, de modo que no se gana nada
descomponiéndolas más, ya que ocasionarían pérdida de información. Desafortunadamente, no
existe una forma simple de verificar la 5FN. Las dependencias de reunión son generalmente raras,
de modo que los diseñadores terminan el proceso de normalización en 4FN, FNBC o 3FN para
preservar las dependencias funcionales.
Si para dos relaciones con una interrelación M:M se puede obtener esta interrelación como resultado
del producto cartesiano de ambas, se deben mantener separadas y no crear una tercera relación que
defina la interrelación de ambas.
Como se mostró en ejemplo de la dependencia de reunión, si el producto cartesiano genera tuplas

espúreas, se debe crear una tabla adicional que defina como se interrelacionan las otras dos.
3.6.4. Proceso de Descomposición sin Pérdida

Aunque la normalización puede realizarse usando la aproximación heurística basada en llaves
primarias y fue demostrado en las secciones anteriores, una aproximación más formal al diseño de

BDs relacionales está basada estrictamente en dependencias funcionales y otros tipos de
restricciones. Estas aproximaciones usan algoritmos de normalización para crear esquemas de
relaciones. Para empezar, todos los atributos en la BD se colocan en una sola gran relación llamada
la relación universal. Usando dependencias funcionales y otras restricciones, la relación universal
es descompuesta en pequeños esquemas relacionales hasta que el proceso llega a un punto donde
no se desean más descomposiciones. Es deseable que cada esquema de relación esté en BCNF o
al menos en 3FN. Otras propiedades importantes incluyen la preservación de atributos, la
preservación de dependencias y reuniones sin pérdida.
3.1.1.32. Preservación de atributos
Cuando la relación universal se construye contiene, por definición cada atributo en la BD. En el
proceso de descomposición de la relación universal en pequeñas relaciones y moviendo los atributos
a ellas, se desea asegurar que cada atributo aparezca en al menos una de las relaciones, de modo
que ningún dato se pierda. Como se ha visto, el esquema de la BD generalmente contiene algunos
atributos repetidos para representar las interrelaciones entre tablas. Sin embargo, los atributos tienen
que ser colocados en las relaciones de modo que preserven toda la información, no sólo todos los
atributos.
3.1.1.33. Preservación de la dependencia
Una dependencia funcional representa una restricción que debe ser forzada en la BD. Cada vez que
se realiza una actualización, el DBMS debe verificar que la restricción no se viola. Es más fácil
verificar restricciones sobre una tabla que verificar una que involucra múltiples tablas, lo que puede
requerir hacer primero una reunión. Para evitar que tener que hacer esas reuniones, sería preferible
que en una descomposición las dependencias funcionales involucren atributos que están en la
misma tabla, si es posible. Dada una descomposición de una relación R, con un conjunto de
dependencias funcionales en ella, sobre un conjunto individual de relaciones {R1, R2, …, Rn}, para
cada dependencia funcional A à B es deseable para cada atributo en A U B que aparezcan en la
misma relación Ri. Esta propiedad es llamada preservación de dependencia. Siempre es posible
encontrar descomposición preservando la dependencia que está en 3FN, pero no siempre es posible
encontrar una que está en FNBC.
3.1.1.34. Descomposición sin Pérdida

En las relaciones separadas, se tiene especial cuidado en usar proyecciones que pueden
deshacerse reuniendo las tablas resultantes, de modo que la tabla original puede volver a obtenerse.
Por tabla original se entiende no solo la estructura de la tabla, que son los nombres de columnas,
sino también las tuplas. De modo que una descomposición es llamada descomposición sin
pérdida, porque preserva toda la información en la relación original. Se ha usado la palabra
descomposición, y su definición formal es:
Definición: Una descomposición de una relación R es un conjunto de relaciones {R1, R2, …, Rn}
tales que cada Ri es un subconjunto de R y la unión de todas las Ri es R.
Ahora se puede definir descomposición sin pérdida:
Definición: Una descomposición {R1, R2, …, Rn} de una relación R es llamada descomposición
sin pérdida para R si la reunión natural de R1, R2,… Rn produce exactamente la relación R.

No todas las descomposiciones son sin pérdida, porque existen proyecciones cuya reunión no dan
exactamente la relación original. Por ejemplo:
Empleado/Proyecto/Rol
empleado
La tabla muestra qué función realizan los empleados en cada proyecto. Se puede descomponer la
tabla por proyección en dos tablas:
Tabla1 Tabla2
nombre empleado función función nombre proyecto
López diseñador diseñador Nueva España
López programador programado Emprendedor
r
Pérez diseñador diseñador Emprendedor
Sin embargo, cuando se reúnen las dos tablas, se obtienen tuplas adicionales que no aparecían en
la tabla original.
Resultado de Reunión
empleado
Pérez diseñador Nueva España tupla espúrea
Estas son tuplas espúreas (falsas), creadas por los procesos de proyección y reunión. Ya que sin la
tabla original, no hay forma de identificar cuáles tuplas son genuinas y cuáles espúreas, se puede
perder información (aún cuando se tienen más tuplas) si se sustituyen las proyecciones para la
relación original.
Se puede garantizar descomposición sin pérdida asegurándose que, para cada par de relaciones
que se reúnen, el conjunto de atributos comunes es una llave de una de las relaciones. Esto puede
hacerse colocando atributos funcionalmente dependientes en una relación con sus determinantes y
manteniendo las determinantes por sí mismas en la relación original.
De modo más formal, para una descomposición binaria, si R es descompuesta en dos relaciones
{R1, R2} entonces la reunión es sin pérdida si, y sólo si, alguno de los conjuntos de DFs para R, o es
implicado por las DFs en R:
R1 ∩ R2 à R1 – R2
ó
R1 ∩ R2 à R2 – R1

En el ejemplo, función no era una determinante para nombre de proyecto o nombre de empleado, de
modo que la intersección de las dos proyecciones, función, no determina funcionalmente ninguna
proyección. Existen muchos ejemplos de proyección sin pérdida cuando se normalizan relaciones.
3.7. Reglas de Codd

En dos artículos de 1985 (“Is Your DBMS Really Relational?” y “Does Your DBMS Aun by i.e.
Rules?”), Codd publicó las reglas o principios que un RDBMS deben cumplir para ser considerados
“totalmente relacionales”. Codd quería mantener la integridad del modelo relacional y para hacerlo
claro identificó 12 reglas, junto con la Regla Cero. Las reglas proporcionan un conjunto estándares
para juzgar si un RDBMS es totalmente relacional.
3.7.1. Regla Cero

Un DBMS debe almacenar los datos usando sólo sus capacidades relacionales. Este es el principio
fundamental y por tanto, el DBMS debe cumplir todas las siguientes reglas.
3.7.2. Regla 1. Representación de la Información

Toda la información en una base de datos relacional debe ser representada explícitamente, a nivel
lógico, en exactamente una manera, por valores en tablas.
3.7.3. Regla 2. Acceso Garantizado

Todos y cada uno de los datos en una base de datos relacional deben ser accesibles lógicamente
mediante una combinación del nombre de tabla, nombre de columna y valor de la llave primaria.
3.7.4. Regla 3. Información Faltante

La falta de información y la información no aplicable se soportan en las bases de datos relacionales
de modo sistemático e independiente del tipo de dato mediante los valores nulos. Los nulos deben
ser distintos de cero o cualquier otro número, y de cadenas vacías.
3.7.5. Regla 4. Diccionario de Datos Dinámico basado en el

modelo relacional
La descripción de la base de datos se representa dinámicamente, a nivel lógico, como datos
ordinarios, de modo que los usuarios autorizados puedan aplicar el mismo lenguaje relacional para
consultarla.
3.7.6. Regla 5. Lenguaje de datos Comprensible

No importa cuántos lenguajes y modos interactivos se soporten, por lo menos un lenguaje debe
soportarse, con una sintaxis bien definida, que soporte interactivamente y por programa lo siguiente:
1. Definición de datos
2. Reglas de integridad
3. Manipulación de datos
4. Vistas

5. Control de Transacciones (comienzo, cumplimiento y vuelta atrás)
6. Reglas de autorización
3.7.7. Regla 6. Actualización de Vistas
Para cada vista el DBMS debe tener una forma de determinar, en el momento de la definición de la
vista, si la vista puede ser utilizada para insertar renglones, borrar renglones, actualizar columnas
sobre las tablas en las que está basada, y guardar los resultados de esta decisión en el catálogo del
sistema.
3.7.8. Regla 7. Operaciones de Conjuntos (Insert, Delete y

Update)
La capacidad de operar en tablas completas no sólo se aplica a la consulta, sino también a la
inserción, modificación y borrado de datos. Las operaciones de conjuntos, independientes de la
estructura física de los datos, se logra gracias a un proceso llamado optimización que es único para
las bases de datos relacionales.
3.7.9. Regla 8. Independencia Física de los Datos

Esto se refiere a una separación, hecha por el DBMS, de los aspectos físicos y lógicos de la base de
datos. Las operaciones interactivas y los programas de aplicación no deben ser modificados cuando
cambian las estructuras internas de almacenamiento y los métodos de acceso a la base de datos.
3.7.10. Regla 9. Independencia Lógica de los Datos

Las operaciones interactivas y los programas de aplicación no deben ser modificados cuando se
realizan cambios sobre las estructuras de las tablas de la base de datos que no involucren pérdida
de información, como descomposición de tablas o combinación de tablas.
3.7.11. Regla 10. Independencia de Integridad

Las operaciones interactivas y los programas de aplicación no deben ser modificados cuando se
realizan cambios sobre las reglas de integridad definidas y almacenadas en el catálogo de la base de
datos. Las restricciones de integridad como la integridad en la entidad y la integridad referencial
deben ser especificadas en el sublenguaje de datos y almacenadas en el catálogo. Los programas
de aplicación y las operaciones interactivas no deben ser usados para expresar estas restricciones.
3.7.12. Regla 11. Independencia de Distribución

Esta regla se refiere a DBMSs distribuidos. El concepto de independencia de distribución es similar a
las reglas de independencia física, lógica y de integridad anteriores, pero aplicadas a distribución a
través de computadoras.
Esta regla implica que todas las características y reglas requeridas por el modelo deben extenderse
a todo el sistema distribuido.
3.7.13. Regla 12. No Subversión

Si un DBMS se maneja con un lenguaje de bajo nivel (procedural), esto no debe representar el omitir
las reglas de integridad y de seguridad que se contemplan con el uso de un lenguaje de alto nivel, y
que son almacenadas en el diccionario de la base de datos.
3.8. Estándar SQL

Los lenguajes comerciales permiten definir las estructuras, los limitantes de integridad y los limitantes
de seguridad. Los sistemas manejadores de bases de datos relacionales (RDBMS) comerciales
requieren un lenguaje de consulta amigable con el usuario; durante varios años, se han
implementaciones varios lenguajes de este tipo entre los que se encuentran SQL (Structured Query
Language). Aunque es un lenguaje llamado de consulta (Query), contienen muchas otras
capacidades además de consultar una base de datos, entre las que se incluyen: definición de la
estructura de los datos, actualización de datos y especificación de restricciones de seguridad.
SQL es un lenguaje estándar usado para comunicarse con sistemas manejadores de bases de datos
relacionales (RDBMS). El estándar SQL ha sido definido por la Organización Internacional de
Estándares (ISO – International Standards Organization) y el Instituto Nacional Americano para la
Estandarización (ANSI – American National Standars Institute). El nombre oficial del lenguaje es
Lenguaje Estándar Internacional de Bases de Datos SQL (International Standar Database
Language SQL) dado en 1992. De los distintos lenguajes que se usaban en los primeros RDBMSs,
SQL se impuso como estándar en los RDBMSs actuales y aunque existen algunas variaciones, se
sigue intentando su normalización.
Está basado sobre todo en el álgebra relacional. Tiene también facilidades del cálculo relacional, de
manera que ciertas tareas pueden ser hechas de varias formas. Es por tanto un lenguaje
procedimental y aprocedimental al mismo tiempo.
3.8.1. Antecedentes
Como sabemos, el modelo relacional surgió a finales de los 60s como resultado de las
investigaciones de E.F. Codd en los laboratorios de IBM en San José de California; los trabajos de
Codd, provocaron una serie de estudios teóricos y prototipos que se extienden a partir de 1970.
El lenguaje SQL inicialmente fue definido durante los 70s, y se llamaba SEQUEL, diminutivo de
Structured English Query Language (Lenguaje Inglés Estructurado de Consulta). SEQUEL fue
implementado originalmente como parte del Sistema R, un prototipo de RDBMS llamado SEQUEL-
XRM, durante los años 74 y 75. Este prototipo evolucionó durante el 76 y 77, pasando a ser
SEQUEL/2, en esta versión se empezaron a soportar consultas multitabla y acceso multiusuario. La
palabra English eventualmente se eliminó del nombre original y la abreviatura cambió a SQL por
motivos legales. Poco después, el Sistema R de IBM implementó un subconjunto de este lenguaje.
Oracle Corporation, formalmente Relational Software Inc., produjo la primera implementación

comercial del lenguaje en 1979, Oracle se adelantó por dos años comercialmente a IBM y se
ejecutaba en minicomputadoras VAX y Digital que eran menos caros que las maxicomputadoras de
IBM, posteriormente van creándose otros productos basados en SQL como SQL/DS, DB2, DG/SQL,
SYBASE, INTERBASE, INFORMIX, UNIFY, incluso otros productos que no tenían SQL como
lenguaje base (INGRES, ADABAS, etc.) ofrecen interfaces SQL por lo que se convierte en estándar.
Aunque la mayoría de los vendedores de bases de datos relacionales soportan SQL/92, el

cumplimiento del estándar no es al 100%. Actualmente, existen diferentes tipos de SQL en el
mercado, ya que cada vendedor de RDBMS intenta extender el estándar para incrementar la

comercialización de su producto. Aunque el curso se centra particularmente en el estándar SQL/92,
la implementación en cada plataforma tiene diferencias o capacidades particulares propias de cada
versión propietaria del lenguaje.
3.8.2. Versiones
En 1982 el Comité de bases de datos X3H2 de ANSI, presentó un lenguaje relacional estándar
basado principalmente en el SQL propio de los productos IBM; en 1886 este organismo aprueba el
lenguaje como norma pasando a denominarse SQL/ANSI, que también es aprobado el siguiente año
como norma ISO (ISO 1987). En esta norma se especifican dos niveles (I y II) a cumplir, siendo el
nivel I un subconjunto de las funcionalidades proporcionadas por el nivel II. Este estándar recibió
muchas críticas ya que es una intersección de las instrumentaciones existentes, concebido
primordialmente para proteger los intereses de los fabricantes; debido a esto, Codd afirma que el
SQL/ANSI es muy débil, fallando en el soporte de muchas características que los usuarios realmente
necesitan si quieren aprovechar todas las ventajas del enfoque relacional. El SQL/ANSI es incluso
menos fiel al modelo relacional que las versiones comerciales.
En 1989 se revisa la versión 1 del estándar conocida como Addendum, que agrega cierta integridad
referencial, que se denomina integridad referencial básica, ya que sólo permite definir la opción
restringir modificación y borrado y no proporciona cambios en cascada. Por otro lado, ya que la
norma ISO 89 no estandariza las definiciones para SQL embebido en lenguajes de programación,
ANSI define ese mismo año un estándar para SQL embebido (ANSI 1989). Ese mismo año, Apple
Computer presenta el Data Access Language (DAL) para sus computadoras, el cual es un dialecto
del SQL que soporta varios RDBMSs.
En junio de 1990, IBM anuncia su estándar DRDA (Distributed Relational Database Access) como
parte de la arquitectura SAA (System Application Architecture).
En abril del 91 el SAG (SQL Access Group) completa la Fase I de especificaciones técnicas, que
define un estándar para intercambiar mensajes SQL sobre una red OSI, basado en la
especialización SQL del RDA de ISO. En junio del 91 este grupo realizó una demostración con más
de veinte RDBMSs que se intercambiaban datos y consultas. En el mes de noviembre de ese mismo
año, Microsoft anunció ODBC (Open Database Connectivity) basado en es estándar del SAG.
En 1992 este grupo completó su segunda fase, que especificaba una API (Application Programming
Interface) y CLI (Call Level Interface) y que ampliaba el estándar a más instalaciones cliente/servidor,
en la que además de las especificaciones OSI se incluyen otros protocolos de red como TCP/IP. En
noviembre de ese año Borland relanzó el estándar ODAPI (Open Database Application Programming
Interface) como IDAPI (Integrated Database Application Programming Interface), con el patrocinio de
IBM, Novell y WordPerfect.
También en el 92 se aprueba como norma internacional una nueva versión conocida como SQL2 o
SQL-92 (ISO 1992), en la que se incrementa sustancialmente la capacidad semántica del esquema
relacional, se agregan nuevos operadores, se mejora el tratamiento de errores y se incluyen normas
para el SQL embebido. En esta nueva norma se definen tres niveles de conformidad distintos: Entry
SQL, Intermediate SQL y Full SQL, Siendo este último el que ofrece mayores funcionalidades,
mientras que el primer nivel es un subconjunto del segundo y este, del tercero.
Este estándar fue complementado con dos nuevas partes que abordan la interfaz a nivel de llamadas
(Call Level Interface), ISO 1995 y la definición de módulos almacenados persistentes (Persistent
Store Modules) ISO 1996. Esta versión de la norma internacional convierte a SQL en un lenguaje
computacionalmente completo agregando estructuras de control, manejo de excepciones, etc.

Durante la segunda mitad de los 90s, se hizo un gran esfuerzo para ampliar el SQL para que
soportara la orientación a objetos. El resultado fue un estándar tan voluminoso que fue dividido en
nueve partes. Esta versión, conocida en un principio como SQL3 y finalmente como SQL:1999 (ISO
1999) incluyó nuevas características como nuevos tipos de datos básicos (very large objects), tipos
definidos por el usuario, disparadores, operadores de consulta recursivos, cursores sensitivos,
generalización de tablas y roles de usuario.
Recientemente, se ha publicado una nueva versión del estándar, el SQL:2003 (ISO/IEC 9075, 2003)
que revisa todas las partes del estándar anterior. En esta nueva versión se incluyen, entre otras
características el SQL/XML (especificaciones relacionadas con XML) y otras características como
nuevos tipos de datos básicos (es decir, bigint, multiset y XML), mejoras de las rutinas SQL
equivocadas, extensiones de la sentencia CREATE TABLE, una nueva sentencia MERGE, un nuevo
objeto de esquema (el generador de secuencias o valores secuenciales) y dos nuevas clases de
columnas: identidad, que son aquellas que funcionan como contadores y generadas, aquellas que se
obtienen por la combinación de otras columnas.
3.8.3. Estructura de instrucciones

Una de las principales características de SQL es que es declarativo o no procedural. Desde el
punto de vista de los programadores, esto implica que el programador no necesita especificar paro a
paso todas las operaciones que la computadora tiene que hacer para obtener un resultado particular.
En vez de eso, el programador indica al RDBMS lo que necesita obtener y el sistema decide por si
mismo cómo obtener el resultado deseado.
SQL es un lenguaje muy completo que incluye:
 Lenguaje de de definición de datos (DDL). El SQL DDL proporciona órdenes para definir la
estructura y organización de los datos almacenados y sus relaciones, permitiendo especificar
diversos objetos, eliminar los objetos existentes y modificarlos.
 Recuperación de datos. SQL permite recuperar los datos almacenado de la base de datos
para mostrarlos directamente o usarlos en alguna aplicación; para ello incluye un lenguaje de
consulta basado en álgebra relacional y el cálculo relacional de tuplas.
 Lenguaje de manipulación de datos (DML). El SQL DML También incluye instrucciones
para insertar, suprimir y modificar tuplas de la base de datos.
 Definición de Vistas. El SQL DDL incluye instrucciones para definir vistas que facilitan las
consultas a los usuarios finales.
 Autorización (DCL). El SQL DCL incluye instrucciones para especificar derechos de acceso
a tablas y vistas; de este modo restringe la capacidad de los usuarios de recuperar, agregar,
eliminar o modificar datos, protegiendo así los datos de accesos no autorizados.
 Integridad. El SQL DDL proporciona también medios para definir varias especificaciones de
integridad que mantienen los datos consistentes y la protege contra corrupciones debidas a
actualizaciones inconsistentes o a fallos del sistema.
 Control de transacciones. SQL incluye instrucciones para especificar el inicio y fin de
transacciones, permitiendo el bloqueo de datos para controlar la concurrencia. SQL se
emplea para coordinar la capacidad de compartir datos por parte de usuarios concurrentes,
asegurando que no interfieren unos con otros.
Las instrucciones o comando que componen el lenguaje SQL son generalmente divididas en tres
principales categorías o sublenguajes. Cada sublenguaje se especializa en un aspecto particular del
lenguaje. Uno de estos sublenguajes es el DDL o Data Definition Language (Lenguaje de Definición

de Datos), también se le conoce como Schema Definition Language de acuerdo con ANSI; este
lenguaje incluye instrucciones que soportan la definición o creación de los objetos de la Base de
Datos como tablas, índices, secuencias y vistas. Algunas de las instrucciones más comunes usadas
en instrucciones DDL son las diferentes formas de los comandos CREATE, ALTER y DROP. Otro
sublenguaje principal, el DML o Data Manipulation Language (Lenguaje de Manipulación de Datos),
incluye instrucciones que permiten el procesamiento o manipulación de los objetos de la base de
datos. Algunas de las instrucciones DML más comunes son las diferentes modalidades de los
comandos SELECT, INSERT, UPDATE y DELETE. El último Data Control Language o DCL
(Lenguaje de Control de Datos) es utilizado en el control de acceso a datos en la base de datos,
ejemplo GRANT y REVOKE. Es importante observar que todos los objetos creados en una base de
datos se almacenan en el diccionario de datos o catálogo de sistema.
SQL puede ser usado interactivamente o en su forma embebida. El SQL Interactivo o por comandos
permite al usuario indicar comandos de modo interactivo directamente al DBMS y recibir los
resultados tan pronto como se producen. Cuando se usa SQL Embebido, las instrucciones SQL se
incluyen como parte de programas escritos en un lenguaje de propósito general como C, C++, Java o
COBOL. En este caso, nos referimos al lenguaje de propósito general como Lenguaje anfitrión. La
razón principal para usar SQL embebido es usar características adicionales del lenguaje de
programación que no son soportadas generalmente por SQL.
Cuando se usa SQL embebido, el usuario no observa directamente la salida de las diversas
instrucciones, en vez de ello, el resultado se retorna en variables o parámetros de procedimientos.
Como regla general, cualquier instrucción SQL que puede ser usada interactivamente, puede ser
usada como parte de un programa de aplicación. Sin embargo, el usuario necesita tener en cuenta
que pueden haber diferencias sintácticas en las instrucciones cuando se usan interactivamente o
cuando se usan en modo embebido dentro de programas.
Ya que SQL es exclusivamente usado con RDBMSs, es necesario conocer los conceptos básicos de
este tipo de base de datos para comprender mejor las características del lenguaje.
Aunque SQL se basa en el modelo relacional, incorpora algunos elementos adicionales que facilitan
la gestión de datos. En este sentido se introduce el concepto de catálogo. Un RDBMS puede tener
uno o varios catálogos y a su vez, una o varias bases de datos. En cada catálogo existe una
definición que contiene las tablas base sobre las que se define un conjunto de vistas o esquemas
que son autodescriptivos.
En el catálogo se puede encontrar además de tablas, dominios, aserciones (restricciones que

afectan a varias tablas), vistas, privilegios, conjuntos de caracteres (Character Set), secuencias de
ordenación (Collation) y traducción (Translation) para esos conjuntos de caracteres. Esto permite
soportar idiomas como el japonés, coreano o chino, se superan los 256 caracteres que pueden
obtenerse con unan extensión de 8 bits del código ASCII.
El estándar SQL es enorme, por lo que sólo se revisarán los aspectos comunes más significativos.
SQL tiene varios elementos de sintaxis que son utilizados en la mayor parte de las instrucciones,
entre ellos:
 Identificadores. Nombres de los objetos como tablas, vistas columnas, bases de datos, etc.
 Operadores. Los operadores periten realizar operaciones aritméticas, lógicos, relacionales,
asignaciones o concatenaciones de valores. Se usan para cambiar datos (permanente o
temporalmente), para buscar tuplas o atributos que cumplan con determinada condición.

 Comentarios. Fragmentos de texto en instrucciones para explicar instrucciones. Es texto no
ejecutable usados para documentar código, deshabilitar temporalmente instrucciones y lotes
de instrucciones SQL. (Por ejemplo en MySQL # y /* …*/).
 Palabras reservadas. Todas las que utiliza SQL y no deben emplearse como identificadores.
Cada SQL tiene su propio conjunto.
 Tipos de datos. Definen el conjunto de valores que pueden contener los objetos como
columnas, variables y parámetros.
 Funciones. Que pueden tomar valores como parámetros y retornan un valor escalar o un
conjunto en forma de tabla.
Para especificar las cláusulas del lenguaje se usará una extensión de la Forma Normal Backus
(BNF), donde:
<> representa símbolos no terminales del lenguaje

::= es el operador de definición
[] indica elementos opcionales
{} agrupa elementos opcionales
| indica una alternativa
* indica repetición, en general las repeticiones se separan con coma.
Cualquier instrucción SQL o comando es una combinación de una o más cláusulas. Las cláusulas
son, en general, introducidas por palabras reservadas. Un ejemplo de una instrucción es:
SELECT <expresión>*
[FROM <nombreDeTabla>*
WHERE <condición>*
ORDER BY <expresión>*]
En esta instrucción, se pueden distinguir cuatro palabras reservadas y cuatro cláusulas. Una palabra
reservada es una palabra que tiene un significado específico dentro del lenguaje. El uso de palabras
reservadas fuera de su contexto generará errores. Cada cláusula inicia con una palabra reservada.
Algunas de las cláusulas dentro de la sintaxis de las instrucciones son opcionales y otras
obligatorias, las cláusulas encerradas entre corchetes son opcionales.
Las instrucciones SQL se asemejan a frases en inglés, completadas con palabras de relleno que no
agregan nada al significado de la frase pero que hace que se lea más naturalmente.
Al escribir instrucciones o comandos de SQL es útil seguir ciertas reglas y guías para mejorar la
lectura de las instrucciones y facilitar su edición en caso necesario. Algunas de estas reglas son:
 Las instrucciones SQL no son sensibles a mayúsculas y minúsculas. Sin embargo, en

ocasiones las palabras reservadas generalmente se escriben en mayúsculas para mejorar la
facilidad de lectura de las instrucciones.
 Las instrucciones SQL pueden escribirse en una o varias líneas. Es costumbre escribir cada
cláusula en su propia línea.
 Las palabras reservadas no se pueden separar en diferentes líneas y a excepción de unas
cuantas instrucciones, no se pueden abreviar.
 En la mayoría de los RDBMS, las instrucciones SQL terminan siempre con un punto y coma
(;).

3.9. Transformación del Modelo E/R al Modelo
Relacional
Un DER puede convertirse a un modelo relacional fácilmente. Para convertirlo:
 Las entidades fuertes representadas por rectángulos se convierten en relaciones

representadas por tablas. El nombre de la tabla es el mismo que el nombre de la entidad, que
es el nombre escrito dentro del rectángulo.
 Para entidades fuertes, los atributos simples, no compuestos, representados por elipses,
se convierten en atributos de la relación, o encabezados de columnas.
 Para atributos compuestos, el modelo relacional puro no permite representar directamente
estos atributos, en ese caso se puede usar una columna para cada atributo simple que forma
el atributo compuesto o se puede elegir dejar el atributo compuesto como un solo atributo.
 Los atributos multivaluados tampoco se pueden representar directamente en un modelo
relacional, ya que violarían la 1FN. La solución general es removerlos de la tabla y crear una
relación separada que tenga la PK de la entidad junto con el atributo multivaluado. La llave de
esta nueva tabla es la combinación de la llave de la tabla original y el atributo multivaluado. Si
existen varios atributos multivaluados en la tabla original, se debe crea una nueva tabla para
cada uno. Estas nuevas tablas son tratadas como entidades débiles, con la tabla original
actuando como la entidad padre. Es conveniente nombrar las nuevas tablas usando la forma
plural del atributo multivaluado.
 Las entidades débiles también se representan como tablas, pero requieren atributos
adicionales. Se debe recordar que una entidad débil es dependiente de otra entidad y no
tiene llaves candidatas consistentes sólo de sus atributos propios. Por tanto, la PK de la
entidad padre se usa para mostrar de qué instancia de la entidad padre depende la entidad
débil. Para representar la entidad débil, se usa una tabla cuyos atributos incluyen todos los
atributos de la entidad débil más la llave primaria de la entidad padre. La entidad débil debe
tener un discriminador, algún atributo que junto con la PK de la entidad padre permita
identificar cada tupla. Se usa la combinación de la PK del padre y el discriminador como llave.
 Las interrelaciones también pueden transformarse directamente en tablas. Una interrelación
pude representarse por una tabla teniendo las llaves primarias de las entidades asociadas
como atributos, Si la interrelación no tiene atributos descriptivos, se puede construir la tabla
de interrelación correspondiente simplemente creando encabezados de columnas
consistentes de las llaves primarias de las entidades asociadas. Si la interrelación tiene
atributos descriptivos, estos también se convierten en atributos de la relación, se modo que
se tienen columnas para ellas y para la PK de las entidades asociadas.
o Para interrelaciones binarias 1:1 ó 1:M se puede elegir no representar las
interrelaciones en tablas separadas. Siempre que la interrelación sea uno a uno o uno
a muchos, es posible usar llaves foráneas para mostrar las interrelaciones.
o Si A:B es uno a muchos, se puede colocar la llave de A (el lado de uno) en la tabla B
(el lado de muchos), donde se convierte en una llave foránea.
o Para entidades débiles, la interrelación con su padre ya está representada, porque la
PK de la entidad padre ya está en la tabla de la entidad débil, de modo que no se
requiere usar otra tabla para representar su conexión.
o Todas las entidades que tengan una relación uno a uno deben examinarse
cuidadosamente para determinar si son la misma entidad. Si es así, deben
combinarse en una sola entidad. Si A y B son verdaderamente dos entidades
separadas teniendo una interrelación uno a uno, entonces se puede poder la llave de
cualquier relación en la otra tabla para mostrar la conexión. Sólo se debe trata de
llevar la llave foránea a la tabla que cause menor cantidad de valores nulos.

o Para una relación binaria, el único caso donde es imposible crear la interrelación sin
otra tabla es en el caso muchos a muchos. Aquí, la única forma de mostrar la
conexión es mediante otra tabla. Es importante mencionar que esta tabla se requerirá
aún se no existen atributos descriptivos para la interrelación.
o Cuando se tienen interrelaciones ternarias ó n-arias involucrando tres o más
entidades, se debe construir una tabla de interrelación, en la cual se colocan las PKs
de las entidades asociadas. Si la interrelación ternaria o n-aria tiene atributos
descriptivos, éstos se agregan a la nueva relación.
o Cuando se tiene una interrelación recursiva, su representación depende de la
cardinalidad. Siempre se puede representar esta interrelación con una tabla separada,
cuidando la cardinalidad. Si la cardinalidad es muchos a muchos, siempre se debe
crear la tabla de interrelación. Si es uno a uno o uno a muchos, se puede usar el
mecanismo de llave foránea.
o Las interrelaciones de generalización/especialización requieren que la llave
primaria del supertipo sea pasada como llave primaria al subtipo como llave primaria y
foránea.
Elegir crear o no una tabla adicional en los casos de las interrelaciones uno a uno y uno a muchos
depende de la aplicación que se esté diseñando. Tener las interrelaciones en tablas separadas
proporciona mayor flexibilidad, permitiendo cambiar las asociaciones fácilmente. Sin embargo, esto
requiere realizar reuniones siempre que se use la interrelación, lo cual produce un bajo desempeño
si muchas aplicaciones requieren las reuniones. El diseñador debe elegir entre flexibilidad y
eficiencia, dependiendo del criterio para la aplicación.
Además de representar las entidades, atributos e interrelaciones mediante tablas y columnas, el

modelo puede incluir las siguientes restricciones en cada columna:
Para llaves primarias:

 PK – que indica que es una llave primaria y automáticamente es no nula, no duplicada y no
cambiable.
 AS – que indica que la llave primaria es generada por sistema como un número secuencial.
 AU – que indica que la llave primaria es determinada por el usuario.
Para el resto de los atributos:

 FK – que indica que el atributo es una llave foránea.
 NN – que indica que el atributo es obligatorio, no puede tener valores nulos.
 ND – que indica que el atributo no puede duplicarse, no puede haber dos tupla con el mismo
valor en esa columna, su valor es único.
 NC – que indica que el valor de la columna no se puede modificar, si se desea cambiar, se
deberá borrar la tupla y crear una nueva con el nuevo valor.
En los casos de FK y ND, cuando estas restricciones se refieren a conjuntos de columnas que deben
cumplir la restricción, se pueden numerar (FK1, FK2, …, FKn) para indicar que es una restricción
compuesta por varios atributos.
Tarea.
a. Leer al menos 2 fuentes adicionales sobre los temas vistos en esta unidad y hacer un resumen
de la unidad (máximo 1 cuartilla). No olvidar conclusiones y bibliografía.
b. Explicar cuáles son las diferencias entre el modelo de Red, Jerárquico y Relacional, entre el
modelo orientado a objetos y objeto relacional, entre la intensión y la extensión de la BD.

Bases de Datos Unidad 3

Cargado por

Copyright:

Formatos disponibles

Bases de Datos Unidad 3

Cargado por

Información del documento

Descripción original:

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Bases de Datos Unidad 3

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD NACIONAL AUTÓNOMA DE

FACULTAD DE CONTADURÍA Y ADMINISTRACIÓN

AGOSTO - DICIEMBRE 2008

Unidad 2. Modelo Relacional Página 2

Unidad 2. Modelo Relacional Página 3

El modelo relacional es un ejemplo de un modelo basado en registros. Los modelos basados en

Unidad 2. Modelo Relacional Página 4

3.1.1. Modelos Prerelacionales

3.1.1.1. Modelo Jerárquico

El modelo jerárquico de BD fue desarrollado como una solución a las necesidades

HIJO HIJO/PADRE HIJO

Relaciones: 1 Padre, Múltiples Hijos (1 : M)

Unidad 2. Modelo Relacional Página 5

200 55 256 100000 347 667 347 667 301 10346

 No modela sencillamente las relaciones Muchos a Muchos.

3.1.1.2. Modelo de Red

Unidad 2. Modelo Relacional Página 6

PADRE/ HIJO PADRE/ HIJO PADRE/ HIJO

Relaciones: 1 Padre a Múltiples Hijos, 1 Hijo a Múltiples Padres (M:M)

 Resulta difícil definir nuevas relaciones.

3.1.2. Modelo Relacional

Unidad 2. Modelo Relacional Página 7

Relaciones: 1:1, 1:M, M:M

3.1.3. Modelos Postrelacionales

3.1.1.3. Modelo Orientado a objetos

El modelo orientado a objetos es un modelo semántico similar al modelo entidad/relación. Éste

Unidad 2. Modelo Relacional Página 8

3.1.1.4. Modelo Objeto-Relacional

El modelo objeto-relacional extiende al modelo relacional agregando algunos tipos de datos

3.1.1.5. Modelo de Datos Semiestructurados

3.1.1.6. Data warehouses y minería de datos

Unidad 2. Modelo Relacional Página 9

3.2. Definición de Relación

El modelo relacional se basa en la noción matemática de relación. Codd y otros investigadores

Para comprender el significado estricto de relación, se requieren algunas nociones matemáticas.

Una relación es simplemente un subconjunto de este producto Cartesiano. Por ejemplo:

R = { {1, a}, {3, a} }

es una relación. Generalmente se especifica que pares ordenados corresponden a la relación

S = { (x, y) | x ∈ D1 y y ∈ D2, y x = 3} ∴ S = { {3, a}, {3, b}, {3, c} }

Unidad 2. Modelo Relacional Página 10

El producto Cartesiano generalmente se expresa como:

Cliente (idCliente, nombre, domicilio, límiteCredito)

3.1.1.7. Grado y Cardinalidad

Unidad 2. Modelo Relacional Página 11

3.1.1.8. Llaves de la Relación

3.3. Propiedades de una Relación

 Cada celda de la tabla contiene sólo un valor.

Unidad 2. Modelo Relacional Página 12

3.4.1. Restricciones de Integridad

La regla de integridad llamada integridad referencial aplica a llaves foráneas. La integridad

3.4.2. Restricciones de Usuario

3.1.1.9. En base a consecuencias de operaciones de Borrado y Modificación.

Unidad 2. Modelo Relacional Página 13

3.1.1.10. En base a las relaciones entre atributos

 Restricción de intrarelación sobre atributos. El valor válido de un atributo en una tupla

3.1.1.11. En base a las relaciones entre elementos

 Restricción de interrelación. El valor válido de un atributo depende de los valores de otros

3.5. Lenguajes Relacionales de Manipulación de

Unidad 2. Modelo Relacional Página 14