UNIVERSIDAD AUTÓNOMA DE SANTO DOMINGO

UASD-RECINTO-SANTIAGO
FACULTAD DE CIENCIAS

Maestría en Auditoría y Seguridad Informática

Herramientas Tecnológicas para Auditoría y Monitoreo Contínuo

El Modelo Relacional y los lenguajes relacionales

Maestrantes:
Dharitza Mena
Jhordy Rosario
José Aníbal Rosa
Lourdes Fernández
Ylvin Pérez

Facilitador:
Franklin Inoa Bidó

18 de Octubre, 2017
Indice
Introducción 2

Modelo relacional 3
Dominios y atributos 3
Conceptos de relación 3
Nomenclatura 4
Ventajas 5
Desventajas 5
Normalización 5
Primera Forma Normal (1FN) 6
Segunda Forma Normal (2FN) 7
Tercera Forma Normal (3FN) 8
Forma normal de Boyce-Codd (FNBC) 9
Cuarta Forma Normal (4FN) 10
Quinta Forma Normal (5FN) 10
Diseño 10
Diseño conceptual 11
Diseño lógico 13
Diseño físico 14

Lenguajes Relacionales 16
Lenguajes teóricos de referencia 16
Álgebra Relacional 16
Operadores Relacionales 16
Unión 16
Intersección 17
Diferencia 17
Producto cartesiano 18
Renombrado 18
Proyección 19
Selección 20
División 20
Concatenación 21
Cálculo Relacional 22
Cálculo Relacional Orientado a Tuplas 22

1
 Cálculo Relacional Orientado a Dominios 23
Lenguajes comerciales 24

Bibliografía 25

2
Introducción
Desde la implementación de la primera computadora electrónica la forma de almacenar los
datos digitales han ido cambiando a través de los tiempos, todo ha pasado por un arduo
proceso de evolución, desde la utilización de tarjetas perforadas hasta las modernas bases
de datos relacionales que son tan utilizadas hoy en día. Para poder crear e implementar
correctamente una Base de Datos Relacional debemos conocer profundamente que significa
el Modelo Relacional. En este texto presentamos el resultado de una ligera investigación que
nos muestra las informaciones más relevantes respecto a este fascinante tema,
presentamos también los detalles de a tomar en cuenta a la hora de utilizar esta robusta
forma de representar y tratar los datos.

3
Modelo relacional

El modelo relacional es una forma de representar objetos y/o estructuras de una base de
datos permitiendo definirla especificando diferentes reglas. Propone una representación de
la información representando la información de los objetos y las relaciones, y que además
sea fácilmente entendida por usuarios, siendo posible ampliar el esquema de la Base de
Datos sin modificar la estructura lógica.

En Bases de Datos, un modelo es un formalismo que nos permite representar la realidad y,

más concretamente, aquella parte de la realidad que nos interesa (una Empresa, una
universidad, una biblioteca).

Las partes fundamentales de un Modelo, son:

● Estructura de datos

● Restricciones

● Operadores asociados

Las principales características de las relaciones son las siguientes:

● No admiten filas duplicadas. La principal herramientas de la que disponemos es la

clave principal

● Las columnas no tienen por qué estar ordenadas, es decir que no tienen que seguir
un orden específico.

● La tabla es plana, esto es, cada intersección de filas y columnas ofrece un dato
único, no un conjunto.

Dominios y atributos

El dominio es un conjunto de valores del mismo tipo e indivisibles. Los dominios se dividen
en:

● Dominios generales: Son aquellos cuyos valores se comprenden entre un máximo y

un mínimo. Por ejemplo el código postal son 5 cifras.

● Dominios restringidos: Son aquellos que pertenecen a un conjunto de valores

específicos. Por ejemplo sexo: M y H.

Un atributo es el papel que desempeña un dominio en una relación. El atributo aporta un

significado semántico al dominio.

Conceptos de relación

● Tabla o Entidad.

4
 ● Columna o Atributo: elemento susceptible de tomar valores (cada una de las
columnas de la tabla).

● Fila o Tupla: Cada uno de los elementos que contiene una instancia de la relación
(filas).

Imagen 1.1

Imagen 1.2

Nomenclatura

NOMBRETABLA(Columna1, Columna2, Columna3, …)

Ejemplos:

● USUARIO (Nombre de usuario, Nombre, Apellido, Email, …)

● LIBRO (ISBN, Titulo, Autor, Editorial, País)

5
Ventajas

● Provee herramientas que garantizan evitar la duplicidad de registros.

● Garantiza la integridad referencial, así, al eliminar un registro elimina todos los

registros relacionados dependientes.

● Favorece la normalización por ser más comprensible y aplicable.

Desventajas

● Presentan deficiencias con datos gráficos, multimedia, CAD y sistemas de

información geográfica.

● No se manipulan de forma eficiente los bloques de texto como tipo de dato.

● Las bases de datos orientadas a objetos (BDOO) se propusieron con el objetivo de

satisfacer las necesidades de las aplicaciones anteriores y así, complementar pero no
sustituir a las bases de datos relacionales.

Normalización

La normalización de bases de datos es un proceso que consiste en asignar y aplicar una

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

Las tablas hay que verificarlas y revisar si aún se puede reducir u optimizar de alguna
manera.

Los problemas tales como la redundancia que ocurren cuando se abarrotan demasiados
datos en una sola relación son llamados anomalías. Los principales tipos son:

● Redundancia: Cuando la información se repite innecesariamente en muchas tuplas.

● Anomalías de actualización: cuando al cambiar la información en una tupla se

descuida el actualizarla en otra.
●
● Anomalías de eliminación: si un conjunto de valores llegan a estar vacíos y se llega a
perder información relacionada como un efecto de la eliminación.

Por lo que, las bases de datos relacionales se normalizan para:

● Evitar la redundancia de los datos.

● Disminuir problemas de actualización de los datos en las tablas

● Proteger la integridad de datos.

Las formas normales son aplicadas a las tablas de una base de datos. Decir que una base de
datos está en la forma normal N es decir que todas sus tablas están en la forma normal N.

6
 Diagrama de inclusión de todas las formas normales.

En general, las primeras tres formas normales son suficientes para cubrir las necesidades de
la mayoría de las bases de datos. El creador de estas 3 primeras formas normales (o reglas)
fue Edgar F. Codd.

Primera Forma Normal (1FN)

Una tabla se encuentra en Primera Forma Normal si:

● Todos los atributos son atómicos. Un atributo es atómico si los elementos del
dominio son indivisibles.

● La clave primaria no contiene atributos nulos.

● La tabla contiene una clave primaria única.

● No debe existir variación en el número de columnas.

● Dependencia Funcional: Los Campos no clave deben identificarse por la clave

● Debe Existir una independencia del orden tanto de las filas como de las columnas, es
decir, si los datos cambian de orden no deben cambiar sus significados.

La primera forma normal elimina los valores repetidos dentro de una BD. Ejemplo:

La tabla Cliente está conformada por los siguientes campos con sus respectivos registros.

Cliente
ID Cliente Nombre Apellido Teléfono 1 Teléfono 2 Teléfono 3
123 Rachel Ingram 555-861-2025
456 James Wright 555-403-1659 555-776-4100
789 Cesar Dure 555-808-9633

Esta representación hace uso de columnas que permiten valores nulos, y por lo tanto no se
conforman con la definición de la 1FN. Incluso si se contempla la posibilidad de columnas
con valores nulos, el diseño no está en armonía con la regla de 1NF. Teléfono 1, Teléfono 2,
y Teléfono 3, comparten exactamente el mismo dominio y exactamente el mismo

7
significado, dividir los números de teléfono en tres encabezados es artificial y causa
problemas lógicos.
Por lo que:
Dificulta la facilidad de realizar consultas a la tabla.

Imposibilita la manera de hacer cumplir la unicidad los enlaces Cliente-a-Teléfono por medio
del RDBMS. Al cliente 789 se le puede dar equivocadamente un valor para el Teléfono 2 que
es exactamente igual que el valor de su Teléfono 1.

La restricción de los números de teléfono por cliente a tres. Si viene un cliente con cuatro
números de teléfono, se estaría obligado a guardar solamente tres y dejar el cuarto sin
guardar.

Un diseño con 1FN

Un diseño que está completamente basada en 1FN hace uso de dos tablas: una tabla de
cliente y una tabla de teléfonos por cliente.

Cliente
ID Cliente Nombre Apellido
123 Rachel Ingram
456 James Wright
789 Cesar Dure

Teléfonos por cliente

ID Cliente Teléfono
123 555-861-2025
456 555-403-1659
456 555-776-4100
789 555-808-9633

En este diseño no ocurren grupos repetidos de números telefónicos.

Segunda Forma Normal (2FN)

Una relación está en 2FN si está en 1FN y si los atributos que no forman parte de ninguna
clave dependen de forma completa de la clave principal. Es decir que no existen
dependencias parciales. (Todos los atributos que no son clave principal deben depender
únicamente de la clave principal).
En otras palabras podríamos decir que la segunda forma normal está basada en el concepto
de dependencia completamente funcional. Una dependencia funcional es completamente
funcional si al eliminar los atributos A de X significa que la dependencia no es mantenida.

Ejemplo:

La tabla “habilidades de los empleados” tiene como objetivo describir las habilidades de los
empleados:

8
 Habilidades de los empleados
Empleado Habilidad Lugar actual de trabajo
Jones Mecanografía 114 Main Street
Jones Taquigrafía 114 Main Street
Jones Tallado 114 Main Street
Bravo Limpieza ligera 73 Industrial Way
Ellis Alquimia 73 Industrial Way
Ellis Malabarismo 73 Industrial Way
Harrison Limpieza ligera 73 Industrial Way

La única clave combinada de la tabla es {Empleado, Habilidad}.

El atributo restante, Lugar actual de trabajo, es dependiente sólo en parte de la clave
combinada, llamada Empleado. Por lo tanto la tabla no se encuentra en 2NF. 
Una alternativa 2NF a este diseño representaría la misma información en dos tablas:

Empleados
Empleado Lugar actual de trabajo
Jones 114 Main Street
Bravo 73 Industrial Way
Ellis 73 Industrial Way
Harrison 73 Industrial Way

Habilidades de los empleados

Empleado Habilidad
Jones Mecanografía
Jones Taquigrafía
Jones Tallado
Bravo Limpieza ligera
Ellis Alquimia
Ellis Malabarismo
Harrison Limpieza ligera

Las anomalías de actualización no pueden ocurrir en estas tablas

Tercera Forma Normal (3FN)

La tabla se encuentra en 3FN si es 2FN y si no existe ninguna dependencia funcional

transitiva en los atributos que no son clave.

9
La 3NF fue definida originalmente por E.F. Codd en 1971. La definición de Codd indica que
una tabla está en 3NF si y sólo si las tres condiciones siguientes se cumplen:

La tabla está en la segunda forma normal (2NF)

Ningún atributo no-primario de la tabla es dependiente transitivamente de una clave
primaria
Es una relación que no incluye ningún atributo clave.

Un atributo no-primario es un atributo que no pertenece a ninguna clave candidata. Una

dependencia transitiva es una dependencia funcional X → Z en la cual Z no es inmediatamente
dependiente de X, pero sí de un tercer conjunto de atributos Y, que a su vez depende de X. Es decir, X → Z por
virtud de X → Y e Y → Z.
Un ejemplo de una tabla 2NF que falla en satisfacer los requerimientos de la 3NF es:

Torneo Año Ganador Fecha de nacimiento del ganador

Indiana Invitational 1998 Al Fredrickson 21 de julio de 1975
Cleveland Open 1999 Bob Albertson 28 de septiembre de 1968
Des Moines Masters 1999 Al Fredrickson 21 de julio de 1975
Indiana Invitational 1999 Chip Masterson 14 de marzo de 1977

La violación de la 3NF ocurre porque el atributo no primario Fecha de nacimiento del

ganador es dependiente transitivamente de {Torneo, Año} vía el atributo no primario
Ganador. El hecho de que la Fecha de nacimiento del ganador es funcionalmente
dependiente en el Ganador hace la tabla vulnerable a inconsistencias lógicas.

Para expresar los mismos hechos sin violar la 3NF, es necesario dividir la tabla en dos:

Torneo Año Ganador

Indiana Invitational 199 Al Fredrickson
8
Cleveland Open 199 Bob Albertson
9
Des Moines Masters 199 Al Fredrickson
9
Indiana Invitational 199 Chip Masterson
9

Ganador Fecha de nacimiento

Chip Masterson 14 de marzo de 1977

Al Fredrickson 21 de julio de 1975
Bob Albertson 28 de septiembre de 1968

Forma normal de Boyce-Codd (FNBC)

La tabla se encuentra en FNBC si cada determinante, atributo que determina

completamente a otro, es clave candidata. Es una versión ligeramente más fuerte de la

10
Tercera forma normal (3FN). La forma normal de Boyce-Codd requiere que no existan
dependencias funcionales no triviales de los atributos que no sean un conjunto de la clave
candidata.

Una forma sencilla de comprobar si una relación se encuentra en FNBC consiste en

comprobar, además de que esté en 3FN, lo siguiente:

(1) Si no existen claves candidatas compuestas (con varios atributos), está en FNBC.

(2) Si existen varias claves candidatas compuestas y éstas tienen un elemento común,
puede no estar en FNBC. Sólo si, para cada dependencia funcional en la relación, el
determinante es una clave candidata, estará en FNBC.

Cuarta Forma Normal (4FN)

La 4NF se asegura de que las dependencias multivaluadas independientes estén correctas y

eficientemente representadas en un diseño de base de datos. La 4NF es el siguiente nivel de
normalización después de la forma normal de Boyce-Codd (BCNF).

Una tabla está en 4NF si y sólo si está en Tercera forma normal o en BCNF (Cualquiera de
ambas) y no posee dependencias multivaluadas no triviales. La definición de la 4NF confía
en la noción de una dependencia multivaluada. Una tabla con una dependencia multivaluada
es una donde la existencia de dos o más relaciones independientes muchos a muchos causa
redundancia; y es esta redundancia la que es suprimida por la cuarta forma normal.

Quinta Forma Normal (5FN)

La Quinta Forma Normal también conocida como forma normal de proyección-unión (PJ/NF),
es un nivel de normalización de bases de datos diseñado para reducir redundancia en las
bases de datos relacionales que guardan hechos multi-valores aislando semánticamente
relaciones múltiples relacionadas.

Una tabla se encuentra en 5FN si:

La tabla está en 4FN

No existen relaciones de dependencias de reunión (join) no triviales que no se generen

desde las claves. Una tabla que se encuentra en la 4FN se dice que está en la 5FN si, y sólo
si, cada relación de dependencia de reunión (join) se encuentra definida por claves
candidatas. Por lo que si se aplicara una consulta entre al menos tres relaciones
independientes entre sí dentro de la 4FN y se obtuvieran tuplas espurias, entonces no
estaría dentro de la 5FN.

Diseño

El diseño de una base de datos consiste en definir la estructura de los datos que debe tener
un sistema de información determinado. Para realizar este diseño se deben seguir por regla
general ciertas fases, definiendo para ello el modelo conceptual, el lógico y el físico.

● En el diseño conceptual: Se hace una descripción de alto nivel de la estructura de

la base de datos, independientemente del SGBD (Sistema Gestor de Bases de Datos)
que se vaya a utilizar para manipularla. Su objetivo es describir el contenido de

11
 información de la base de datos y no las estructuras de almacenamiento que se
necesitarán para manejar dicha información.

● El diseño lógico: parte del resultado del diseño conceptual y da como resultado una
descripción de la estructura de la base de datos en términos de las estructuras de
datos que puede procesar un tipo de SGBD. El diseño lógico depende del tipo de
SGBD que se vaya a utilizar, se adapta a la tecnología que se debe emplear, pero no
depende del producto concreto. En el caso de bases de datos convencionales
relacionales (basadas en SQL para entendernos), el diseño lógico consiste en definir
las tablas que existirán, las relaciones entre ellas, normalizarlas, etc…

● El diseño físico: parte del lógico y da como resultado una descripción de la

implementación de una base de datos en memoria secundaria: las estructuras de
almacenamiento y los métodos utilizados para tener un acceso eficiente a los datos.
Aquí el objetivo es conseguir una mayor eficiencia, y se tienen en cuenta aspectos
concretos del SGBD sobre el que se vaya a implementar. Por regla general esto es
transparente para el usuario, aunque conocer cómo se implementa ayuda a
optimizar el rendimiento y la escalabilidad del sistema.

Las capas de diseño conceptual y lógico son similares. Generalmente se implementan

mediante diagramas de Entidad/Relación (modelo conceptual) y tablas y relaciones entre
éstas (modelo lógico). Este es el modelo utilizado por los sistemas gestores de datos más
habituales (SQL Server, Oracle, MySQL...).

El modelo relacional de bases de datos se rige por algunas normas sencillas:

● Todos los datos se representan en forma de tablas (también llamadas “relaciones”,

ver nota anterior). Incluso los resultados de consultar otras tablas. La tabla es
además la unidad de almacenamiento principal.

● Las tablas están compuestas por filas (o registros) y columnas (o campos) que
almacenan cada uno de los registros(la información sobre una entidad concreta,
considerados una unidad).

● Las filas y las columnas, en principio, carecen de orden a la hora de ser

almacenadas. Aunque en la implementación del diseño físico de cada SGBD esto no
suele ser así. Por ejemplo, en SQL Server si añadimos una clave de tipo "Clustered"
a una tabla haremos que los datos se ordenen físicamente por el campo
correspondiente.

● El orden de las columnas lo determina cada consulta (que se realizan usando SQL).

● Cada tabla debe poseer una clave primaria, esto es, un identificador único de cada
registro compuesto por una o más columnas.

● Para establecer una relación entre dos tablas es necesario incluir, en forma de
columna, en una de ellas la clave primaria de la otra. A esta columna se le llama
clave externa. Ambos conceptos de clave son extremadamente importantes en el
diseño de bases de datos.

● Basándose en estos principios se diseñan las diferentes bases de datos relacionales,

definiendo un diseño conceptual y un diseño lógico, que luego se implementa en el

12
 diseño físico usando para ello el gestor de bases de datos de nuestra elección (por
ejemplo SQL Server).

Diseño conceptual

El diseño conceptual de la base de datos para manejar toda esta información se puede ver
en la siguiente figura, denominada diagrama Entidad/Relación o simplemente diagrama E-R:

Como vemos existen tablas para representar cada una de estas entidades del mundo real:

Proveedores (Suppliers), Productos, Categorías de productos, Empleados, Clientes,

Transportistas (Shippers), y Pedidos (Orders) con sus correspondientes líneas de detalle
(Order Details).

Además están relacionadas entre ellas de modo que, por ejemplo, un producto pertenece a
una determinada categoría (se relacionan por el campo CategoryID) y un proveedor
(SupplierID), y lo mismo con las demás tablas.

Cada tabla posee una serie de campos que representan valores que queremos almacenar
para cada entidad. Por ejemplo, un producto posee los siguientes atributos que se traducen
en los campos correspondientes para almacenar su información: Nombre (ProductName),
Proveedor (SupplierID, que identifica al proveedor), Categoría a la que pertenece
(CategoryID), Cantidad de producto por cada unidad a la venta (QuantityPerUnit), Precio
unitario (UnitPrice), Unidades que quedan en stock (UnitsInStock), Unidades de ese
producto que están actualmente en pedidos (UnitsOnOrder), qué cantidad debe haber para

13
que se vuelva a solicitar más producto al proveedor (ReorderLevel) y si está descatalogado
o no (Discontinued).

Los campos marcados con "PK" indican aquellos que son claves primarias, es decir, que
identifican de manera única a cada entidad. Por ejemplo, ProductID es el identificador único
del producto, que será por regla general un número entero que se va incrementando cada
vez que introducimos un nuevo producto (1, 2, 3, etc..).
Los campos marcados como "FK" son claves foráneas o claves externas. Indican campos
que van a almacenar claves primarias de otras tablas de modo que se puedan relacionar
con la tabla actual. Por ejemplo, en la tabla de productos el campo CategoryID está
marcado como "FK" porque en él se guardará el identificador único de la categoría asociada
al producto actual. En otras palabras: ese campo almacenará el valor de la clave primaria
(PK) de la tabla de categorías que identifica a la categoría en la que está ese producto.

Los campos marcados con indicadores que empiezan por "I" (ej: "I1") se refieren a índices.
Los índices generan información adicional para facilitar la localización más rápida de
registros basándose en esos campos. Por ejemplo, en la tabla de empleados (Employees)
existe un índice "I1" del que forman parte los campos Nombre y Apellidos (en negrita
además porque serán también valores únicos) y que indica que se va a facilitar la locación
de los clientes mediante esos datos. También tiene otro índice "I2" en el campo del código
postal para localizar más rápidamente a todos los clientes de una determinada zona.

Los campos marcados con indicadores que empiezan con "U" (por ejemplo U1) se refieren a
campo que deben ser únicos. Por ejemplo, en la tabla de categorías el nombre de ésta
(CategoryName) debe ser único, es decir, no puede haber -lógicamente- dos categorías con
el mismo nombre.

Como vemos, un diseño conceptual no es más que una representación formal y acotada de
entidades que existen en el mundo real, así como de sus restricciones, y que están
relacionadas con el dominio del problema que queremos resolver.

Diseño lógico

Una vez tenemos claro el modelo E-R debemos traducirlo a un modelo lógico directamente
en el propio sistema gestor de bases de datos (Oracle, MySQL, SQL Server...). Si hemos
utilizado alguna herramienta profesional para crear el diagrama E-R, seguramente
podremos generar automáticamente las instrucciones necesarias para crear la base de
datos.

La mayoría de los generadores de diagramas E-R (por ejemplo Microsoft Visio) ofrecen la
capacidad de exportar el modelo directamente a los SGBD más populares.

Entonces, todo este modelo conceptual se traduce en un modelo lógico que trasladaremos a
la base de datos concreta que estemos utilizando y que generalmente será muy parecido.
Por ejemplo, este es el mismo modelo anterior, mostrado ya como tablas en un diagrama
de SQL Server:

14
En este caso hemos creado cada tabla, una a una, siguiendo lo identificado en el diagrama
E-R y estableciendo índices y demás elementos según las indicaciones de cada uno de los
campos. Además hemos decidido el mejor tipo de datos que podemos aplicar a cada campo
(texto, números, fechas... que se almacenan para cada registro).

Su representación gráfica en la base de datos es muy similar, sin embargo el modelo físico
(cómo se almacena esto físicamente), puede variar mucho de un SGBD a otro y según la
configuración que le demos.

Diseño físico

El diseño físico de la base de datos optimiza el rendimiento a la vez que asegura la

integridad de los datos al evitar repeticiones innecesarias de datos. Durante el diseño físico,
se transforman las entidades en tablas, las instancias en filas y los atributos en columnas.
Una vez completado el diseño lógico de la base de datos, se pasa al diseño físico. El
personal que realiza el diseño debe tomar decisiones que afectan al diseño físico, algunas de
las cuales se listan a continuación.

● ¿Cómo convertir entidades en tablas físicas?

● ¿Qué atributos utilizar para las columnas de las tablas físicas?
● ¿Qué columnas de las tablas deben definirse como claves?
● ¿Qué índices deben definirse en las tablas?
● ¿Qué vistas deben definirse en las tablas?
● ¿Cómo desnormalizar las tablas?
● ¿Cómo resolver relaciones de mucho a mucho?
● ¿Qué diseños pueden beneficiarse del acceso hash?

15
La tarea de crear el diseño físico es un trabajo que realmente no acaba nunca. Es necesario
supervisar continuamente las características de rendimiento e integridad de los datos de la
base de datos a medida que pasa el tiempo. Muchos factores necesitan mejoras periódicas
en el diseño físico. Por ejemplo, suponga que diseña una tabla particionada de modo que
almacena datos para 36 meses. Más adelante descubre que necesita ampliar el diseño a
datos para 84 meses. Puede añadir o rotar particiones para los 36 meses actuales a fin de
acomodar el nuevo diseño.

Según Thomas H. Grayson, un buen diseño de base de datos debe poseer siempre las
siguientes cualidades, aunque algunas puede llegar a ser contradictorias entre sí:
Reflejar la estructura del problema en el mundo real.

● Ser capaz de representar todos los datos esperados, incluso con el paso del tiempo.
● Evitar el almacenamiento de información redundante.
● Proporcionar un acceso eficaz a los datos.
● Mantener la integridad de los datos a lo largo del tiempo.
● Ser claro, coherente y de fácil comprensión.
● Como hemos visto el diseño de una base de datos parte de un problema real que
queremos resolver y se traduce en una serie de modelos, conceptual, lógico y físico,
que debemos implementar.

El primero, el diseño conceptual, es el que más tiempo nos va a llevar pues debemos pensar
muy bien cómo vamos a representar las entidades del mundo real que queremos
representar, qué datos almacenaremos, cómo los relacionaremos entre sí, etc...
El diseño lógico es mucho más sencillo puesto que no es más que pasar el diseño anterior a
una base de datos concreta. De hecho muchas herramientas profesionales nos ofrecen la
generación automática del modelo, por lo que suele ser muy rápido.

El diseño físico por regla general recae en la propia base de datos, a partir del diseño lógico,
aunque si dominamos bien esa parte elegiremos cuidadosamente índices, restricciones o
particiones así como configuraciones para determinar cómo se almacenará físicamente esa
información, en qué orden, cómo se repartirá físicamente en el almacenamiento, etc...
Lenguajes Relacionales

Los lenguajes relacionales tienen como objetivo escribir consultas para modificar o
seleccionar datos de una base de datos. Los lenguajes relacionales más importantes son el
cálculo, el álgebra relacional y el SQL. Los dos primeros han precedido históricamente al
SQL. Una de las ventajas del álgebra y cálculo relacionales es que se basan en la lógica y
las matemáticas con lo cual cuando se obtiene una soltura sobre los mismos, la escritura de
consultas puede llegar a ser igual o incluso más rápido que en SQL. Otra de las
características de estos lenguajes relacionales es su equivalencia. Una consulta escrita con
un lenguaje se puede reescribir en otro obteniendo por tanto el mismo resultado.

16
Lenguajes Relacionales

Lenguajes teóricos de referencia

E.F.Codd, en 1972, extiende el modelo relacional básico (RM/B) dotándolo de

comportamiento dinámico mediante la propuesta de dos lenguajes teóricos de referencia:

● Álgebra Relacional (AR)

● Cálculo Relacional (CR)

Codd pretende dar respuesta a la especificación de consultas sobre una base de datos
relacional, proponiendo un salto cualitativo sobre los lenguajes de datos existentes en la
época, de carácter eminentemente procedural . Tanto el AR como el CR son lenguajes de
especificación que se apoyan en la base matemática formal del RM/B (una relación es un
conjunto) para definir consultas a la base de datos como la declaración de conjuntos
mediante su definición por intensión (la propiedad que cumplen los conjuntos). El álgebra
relacional se apoya en la teoría de conjuntos y en la aplicación de operadores tales que
transforman relaciones de la base de datos en relaciones derivadas. Sobre una relación
derivada puede, a su vez, aplicarse una transformación u operador algebraico cuyo
resultado es una nueva relación derivada.

Álgebra Relacional

Proporciona un conjunto de operadores que, combinados, permiten obtener una relación a

partir de otras básicas. En esta se definen 3 tipos de operadores algebraicos:

1. Operadores conjuntistas
a. Unión
b. Intersección
c. Diferencia
d. Producto cartesiano

2. Operadores propiamente relacionales

a. Renombrado
b. Proyección
c. Selección
d. División
e. Concatenación

Operadores Relacionales

Unión
Ejecuta una unión binaria entre dos relaciones que agrupa dos tablas o relaciones en una nueva
relación.

● Operador: ∪

17
 ● Forma: R ∪ S = { t | t ∈ R ∨ t ∈ S}

El resultado será una nueva tabla con los datos de las dos anteriores.

Intersección
La intersección de dos relaciones da como resultado una nueva relación en la que
aparecerán solamente los elementos que estén en ambas relaciones

● Operador: ∩

● Forma: R ∩ S = { t | t ∈ R ∧ t ∈ S}

El único equipo que pertenece a ambas relaciones es el Mazorcos de Madrid.

Diferencia
Genera como resultado todas las tuplas de la relación R que no estén en la relación S

● Operador: −¿

● Forma: R −¿ S

18
Producto cartesiano
El producto cartesiano es una operación binaria y consiste en todas las tuplas de la relación
R combinadas con todas y cada una de las tuplas de la relación S mostrándose los atributos
de R seguidos de los atributos de S.

● Operador: ×

● Forma: R × S = { q t | q ∈ R ∧ t ∈ S}

Renombrado
El resultado de la expresión E es salvado con el nombre de x.

19
 ● Operador: ρ

● Forma: ρ x (E)

Proyección
Una proyección de una relación consiste en seleccionar un número determinado de
columnas o atributos de la misma

● Operador: Π

● Forma: ∏A1, A2, An (r)

20
Selección
La operación de selección permite seleccionar todas aquellas tuplas de una tabla o relación
(r) siempre y cuando cumplan una condición (p).

● Operador: σ

● Forma: σp(r)

División
Imaginemos que existen dos relaciones R(a,b) y S(b), donde a y b son columnas de dichas
relaciones. La división devolverá de la relación R todos los valores de a para los cuales
existe un valor de b que a su vez estará en la columna b de la relación S.

● Operador: /

● Forma: R / S

21
Concatenación
La operación de concatenación o unión natural es una de las más utilizadas cuando se va a
seleccionar datos de más de una tabla. La unión natural permite reconstruir los datos de las
tablas previos a la normalización. Equivale a realizar un producto cartesiano y una selección.

● Operador: θ

● Forma: R θS

22
Cálculo Relacional

El cálculo relacional facilita una notación destinada a definir una nueva relación a través de
las especificaciones de un predicado que deben cumplir las tuplas implicadas. A diferencia
del AR, indica cuál es el problema pero no cómo resolverlo. Está basado en la lógica o
cálculo de predicados de primer orden.

Existen dos tipos de cálculo relacional dependiendo del tipo de variables manejadas:

Cálculo Relacional Orientado a Tuplas (CROT).

Cálculo relacional Orientado a Dominios (CROD).

Cálculo Relacional Orientado a Tuplas

Forma: {t|F(t)}

Donde t es una tupla y F(t) es una fórmula sobre la variable tupla t.

Ejemplo de unión

Tenemos las dos relaciones anteriores y se quiere obtener la unión o el nombre y localidad
de los equipos registrados en cualquiera de las dos tablas (Equipos1 U Equipos2).

{ t | Equipos1(t) ∨ Equipos2(t) }

Ejemplo de selección

23
Si necesitamos conocer aquellos equipos madrileños registrados en la tabla Equipos1.
{ t | Equipos1(t) ∧ t.Localidad=’Madrid’ }

Cálculo Relacional Orientado a Dominios

En el cálculo relacional de dominios el funcionamiento es similar salvo que ahora se utilizan

variables dominio. Las variables no representan una tupla entera sino que toman valores en
el dominio de los atributos de una relación.

Forma: { a1, a2, …, ak | F(a1, a2, …, ak) }

Ejemplo de unión
Tenemos las dos relaciones anteriores y se quiere obtener la unión o el nombre y localidad
de los equipos registrados en cualquiera de las dos tablas (Equipos1 U Equipos2).

{ Nombre,Localidad | Equipos1(Nombre,Localidad) ∨ Equipos2(Nombre,Localidad) }

Ejemplo selección
Si necesitamos conocer aquellos equipos madrileños registrados en la tabla Equipos1.

{ Nombre,Localidad | Equipos1(Nombre,Localidad) ∧ Localidad=’Madrid’ }

Lenguajes comerciales

Los lenguajes teóricos son la base de lenguajes comerciales universalmente extendidos en

el mercado de los sistemas de gestión de bases de datos relacionales; así:

SQL (Structured Query Language) es el lenguaje más extendido para la definición y

manipulación de bases de datos relacionales. Es ISO desde 1986; actualmente existe el

24
nivel ISO SQL3 de 1999; los SGBDs comerciales utilizan generalmente el nivel SQL2 o SQL
ISO de 1992. SQL es un lenguaje con interface de comando, basado en el cálculo relacional
de tuplas.

QBE (Query by Example) es el interface más extendido para la especificación de consultas

en herramientas de usuario o para profesionales de la programación. Se basa en un
interface de especificación visual que interacciona con el esquema de la base de datos,
permitiendo elegir objetos del esquema y especificar condiciones sobre los mismos, así
como validar la consulta y ejecutarla sobre una interface hombre-máquina o bien catalogar
la consulta. QBE se base en el cálculo relacional de dominios.

25
Bibliografía
- http://www.roma1.infn.it/people/barone/metinf/relational-databases-
sandbox-handout.pdf
- http://www.alegsa.com.ar/Dic/dise
%C3%B1o_fisico_de_bases_de_datos.php
- https://www.campusmvp.es/recursos/post/Disenando-una-base-de-datos-
en-el-modelo-relacional.aspx
- http://www.lsi.us.es/docencia/get.php?id=839
- http://myfpschool.com/tema-6-lenguajes-relacionales/
- https://www.tutorialspoint.com/dbms/relational_algebra.htm
- https://en.wikipedia.org/wiki/Relational_algebra
- http://elvex.ugr.es/idbis/db/docs/intro/D%20Modelo%20relacional.pdf
- http://dryvalleycomputer.com/index.php/bases-de-datos/el-modelo-
relacional/62-resumen-del-modelo-relacional
- https://es.wikipedia.org/wiki/Modelo_relacional

26