UNIVERSIDAD DE ORIENTE

NÚCLEO ANZOÁTEGUI
ESCUELA DE INGENIERÍA Y CIENCIAS APLICADAS
DEPARTAMENTO DE COMPUTACIÓN Y SISTEMAS

Modelo Relacional
Autor: Raad, Mickeal CI: 23707805

Barcelona, 28 de abril 2022

 1. Reseña Histórica del modelo de datos relacional
A mediados del siglo XX, los desarrollos en las ciencias de la computación dieron lugar a máquinas
con mayor capacidad de procesamiento y almacenamiento, tanto local como externo. Estos
avances hicieron que los especialistas en ciencias de la computación comenzaran a reconocer el
potencial que tenían estas máquinas para almacenar y administrar cantidades de datos cada vez
más grandes.

Sin embargo, no había teorías sobre cómo las computadoras podían organizar datos de manera
significativa y lógica. Una cosa es almacenar datos no ordenados en una máquina, pero es mucho
más complicado diseñar sistemas que permitan agregar, recuperar, clasificar y administrar esos
datos de forma sistemática y práctica. La necesidad de contar con un marco de trabajo lógico para
almacenar y organizar datos dio lugar a varias propuestas sobre cómo utilizar las computadoras
para administrar datos.

El modelo jerárquico se implementó ampliamente en los primeros sistemas de administración de

bases de datos, pero resultaba poco flexible. En este modelo, a pesar de que los registros
individuales pueden tener varios “elementos secundarios”, cada uno puede tener un solo
“elemento primario” en la jerarquía. Es por eso que estas primeras bases de datos jerárquicas se
limitaban a representar relaciones “uno a uno” y “uno a varios”. Esta carencia de relaciones
“varios a varios” podía provocar problemas al trabajar con puntos de datos que se deseaba asociar
a más de un elemento primario.

A fines de los años 60, Edgar F. Codd, un especialista en ciencias de la computación que trabajaba
en IBM, diseñó el modelo relacional de administración de bases de datos. El modelo relacional de
Codd permitía que los registros individuales se relacionaran con más de una tabla y, de esta
manera, posibilitaba las relaciones “varios a varios” entre los puntos de datos además de las
relaciones “uno a varios”. Esto proporcionó más flexibilidad que los demás modelos existentes a la
hora de diseñar estructuras de base de datos y permitió que los sistemas de gestión de bases de
datos relacionales (RDBMS) pudieran satisfacer una gama mucho más amplia de necesidades
empresariales.

Codd propuso un lenguaje para la administración de datos relacionales, conocido como Alfa, que
influyó en el desarrollo de los lenguajes de bases de datos posteriores. Dos colegas de Codd en
IBM, Donald Chamberlin y Raymond Boyce, crearon un lenguaje similar inspirado en Alpha. Lo
llamaron SEQUEL, abreviatura de Structured English Query Language (Lenguaje de consulta
estructurado en inglés), pero debido a una marca comercial existente, lo abreviaron a SQL
(conocido formalmente como* Lenguaje de consulta estructurado*).

Debido a las limitaciones de hardware, las primeras bases de datos relacionales eran
prohibitivamente lentas y el uso de la tecnología tardó un tiempo en generalizarse. Pero a
mediados de los años ochenta, el modelo relacional de Codd se había implementado en varios
productos comerciales de administración de bases de datos, tanto de IBM como de sus
competidores. Estos proveedores también siguieron el liderazgo de IBM al desarrollar e
implementar sus propios dialectos de SQL. Para 1987, tanto el Instituto Nacional Estadounidense
de Estándares (American National Standards Institute) como la Organización Internacional de
Normalización (International Organization for Standardization) habían ratificado y publicado
normas para SQL, lo que consolidó su estado como el lenguaje aceptado para la administración de
RDBMS.

Gracias al uso extendido del modelo relacional en varias industrias, se lo comenzó a reconocer
como el modelo estándar para la administración de datos. Incluso con el surgimiento de varias
bases de datos NoSQL en los últimos años, las bases de datos relacionales siguen siendo las
herramientas predominantes para almacenar y organizar datos.

2. Concepto de Modelo Relacional

El modelo relacional, para el modelado y la gestión de bases de datos, es un modelo de datos
basado en la lógica de predicados y en la teoría de conjuntos. Su idea fundamental es el uso de
relaciones. Estas relaciones podrían considerarse en forma lógica como conjuntos de datos
llamados tuplas. Pese a que esta es la teoría de las bases de datos relacionales creadas por Codd,
la mayoría de las veces se conceptualiza de una manera más fácil de imaginar, pensando en cada
relación como si fuese una tabla que está compuesta por registros (cada fila de la tabla sería un
registro o “tupla”) y columnas (también llamadas “campos”).

3. ¿Qué es una relación y de un ejemplo?

Son tabla bidimensional para la representación de datos. Ejemplo: Estudiantes.

4. ¿Qué es una fila o tupla?

Filas de una relación que contiene valores para cada uno de los atributos (equivale a los
registros). Ejemplo: 34563, José, Martinez, 19, Masculino. Representa un objeto único de datos
implícitamente estructurados en una tabla. Un registro es un conjunto de campos que
contienen los datos que pertenecen a una misma entidad.

5. ¿Qué es cuerpo?
Una relación es una definición de estructura de tabla (un conjunto de definiciones de columna)
junto con los datos que aparecen en esa estructura. La definición de la estructura es
el encabezado y los datos que aparecen en él son el cuerpo, un conjunto de filas. (Conjunto de m
tuplas)

6. ¿Qué es columna o atributo?

Columnas de una relación y describe las características particulares de cada campo.
Ejemplo: id estudiante
7. ¿Qué es dato?
Representación de una variable que puede ser cuantitativa o cualitativa que indica un
valor que se le asigna las cosas y se representa a través de una secuencia de símbolos,
números o letras.
 8. ¿Qué es grado?
Son los números de atributos (n).
9. ¿Qué es cardinalidad y cuáles son sus tipos?
Es Simplemente la forma en que se relacionan las Entidades, o expresa cuantas
entidades se relacionan con otras entidades. Hay varias maneras de mostrar las
cardinalidades:
Poner etiquetas en las líneas que unen las relaciones con las entidades, consiste en un
mínimo y máximo que contiene un cero (varios a varios) y lo usual es poner una “M” en
un
Existen 4 tipos de relaciones que pueden establecerse entre entidades, las cuales
establecen con cuantas ocurrencias de entidad de tipo B se puede relacionar una
ocurrencia de entidad de tipo A:
4. Relación uno a uno.
5. Relación uno a varios (n).
3. Relación varios (n) a uno.
4. Relación varios a varios (n)- (n)

10. ¿Qué es dominio?

Para cada atributo hay un conjunto de valores permitidos, denominado dominio de ese
atributo. Para el atributo nombre sucursal, por ejemplo, el dominio es el conjunto de
todos los nombres de sucursal.
11. ¿Cuáles son las reglas de CODD y cual es aplicación?
Codd se percató de que existían bases de datos en el mercado las cuales decían ser
relacionales, pero lo único que hacían era guardar la información en tablas, sin estar
estas tablas literalmente normalizadas; entonces publicó 13 reglas que un verdadero
sistema relacional debería cumplir, aunque en la práctica algunas de ellas son difíciles
de realizar. Un sistema podrá considerarse «más relacional» cuanto más siga estas
reglas.

 Regla 0: Regla de fundación. Cualquier sistema que se proclame como relacional,

debe ser capaz de gestionar sus bases de datos enteramente mediante sus
capacidades relacionales.
 Regla 1: Regla de la información. Toda la información en la base de datos es
representada unidireccionalmente por valores en posiciones de las columnas
dentro de filas de tablas. Toda la información en una base de datos relacional se
representa explícitamente en el nivel lógico exactamente de una manera: con
valores en tablas.
 Regla 2: Regla del acceso garantizado. Todos los datos deben ser accesibles sin
ambigüedad. Esta regla es esencialmente una nueva exposición del requisito
fundamental para las claves primarias. Dice que cada valor escalar individual en
la base de datos debe ser lógicamente direccionable especificando el nombre de
la tabla, la columna que lo contiene y la clave primaria.
 Regla 3: Regla del tratamiento sistemático de valores nulos. El sistema de
gestión de base de datos debe permitir que haya campos nulos. Debe tener una
representación de la «información que falta y de la información inaplicable» que
sea sistemática y distinta de todos los valores regulares.
 Regla 4: Catálogo dinámico en línea basado en el modelo relacional. El sistema
debe soportar un catálogo en línea, el catálogo relacional, que da acceso a la
estructura de la base de datos y que debe ser accesible a los usuarios
autorizados.
 Regla 5: Regla comprensiva del sublenguaje de los datos. El sistema debe
soportar por lo menos un lenguaje relacional que:
o Tenga una sintaxis lineal.
o Puede ser utilizado de manera interactiva.
o Tenga soporte de operaciones de definición de datos, operaciones de
manipulación de datos (actualización, así como la recuperación), de
control de la seguridad e integridad y operaciones de administración de
transacciones.

 Regla 6: Regla de actualización de vistas. Todas las vistas que son teóricamente
actualizables deben poder ser actualizadas por el sistema.
 Regla 7: Alto nivel de inserción, actualización y borrado. El sistema debe permitir
la manipulación de alto nivel en los datos, es decir, sobre conjuntos de tuplas.
Esto significa que los datos no solo se pueden recuperar de una base de datos
relacional a partir de filas múltiples y/o de tablas múltiples, sino que también
pueden realizarse inserciones, actualizaciones y borrados sobre varias tuplas y/o
tablas al mismo tiempo y no solo sobre registros individuales.
 Regla 8: Independencia física de los datos. Los programas de aplicación y
actividades del terminal permanecen inalterados a nivel lógico, aunque se
realicen cambios en las representaciones de almacenamiento o métodos de
acceso.
  Regla 9: Independencia lógica de los datos. Los programas de aplicación y
actividades del terminal permanecen inalterados a nivel lógico, aunque se
realicen cambios a las tablas base que preserven la información. La
independencia de datos lógica es más difícil de lograr que la independencia
física de datos.
 Regla 10: Independencia de la integridad. Las restricciones de integridad se
deben especificar por separado de los programas de aplicación y almacenarse en
la base de datos. Debe ser posible cambiar esas restricciones sin afectar
innecesariamente a las aplicaciones existentes.
 Regla 11: Independencia de la distribución. La distribución de porciones de base
de datos en distintas localizaciones debe ser transparente para los usuarios de la
base de datos. Los usos existentes deben continuar funcionando con éxito:
o cuando una versión distribuida del SGBD se carga por primera vez
o cuando los datos existentes se redistribuyen en el sistema.
 Regla 12: La regla de la no subversión. Si el sistema proporciona una interfaz de
bajo nivel de registro, aparte de una interfaz relacional, esa interfaz de bajo
nivel no debe permitir su utilización para subvertir el sistema. Por ejemplo, para
sortear las reglas de seguridad relacional o las restricciones de integridad. Esto
es debido a que a algunos sistemas no relacionales previamente existentes se les
añadió una interfaz relacional, pero, al mantener la interfaz nativa, seguía
existiendo la posibilidad de trabajar no relacionalmente.

12. ¿Qué es una clave candidata?

Conjunto de atributos que permiten identificar en forma única cada tupla de la relación.
Es decir, columnas cuyos valores no se repiten para esa tabla. Los atributos candidatos
para una tabla de individuos (clientes, pacientes, etc.) es el ‘rut’, un número de seguro
social, un ‘id’ de cliente (numérico o de caracter).
13. ¿Para una clave candidata que es la condición de la minimalidad?
No pueden existir dos registros con el mismo valor en los atributos que forman la llave
candidata.
14. ¿Para una clave candidata que es la condición de la Unicidad?
No existe ningún otro subconjunto de la llave que cumpla la regla de unicidad.
15. ¿Qué es una clave primaria?
Clave candidata que se escoge como identificador de las tuplas. Se elige como primaria
la candidata que identifique mejor a cada tupla en el contexto de la base de datos. Por
ejemplo, un atributo con el RUT sería clave candidata de una tabla de clientes, aunque
si en esa relación existe un atributo de código de cliente, este sería mejor candidato
para clave principal, porque es mejor identificador para ese contexto.
16. ¿Qué es una clave Foránea?
Atributo cuyos valores coinciden con una clave candidata (normalmente primaria) de
otra tabla.
17. ¿Qué es la regla de integridad de las entidades?
La regla de integridad de entidad de la clave primaria establece que, si el conjunto de
atributos CP es la clave primaria de una relación R, la extensión de R no puede tener
ninguna tupla con algún valor nulo para alguno de los atributos de CP.
18. ¿Qué es la regla de entidad referencial?
La regla de integridad referencial establece que si el conjunto de atributos CF es una
clave foránea de una relación R que referencia una relación S (no necesariamente
diferente de R), que tiene por clave primaria CP, entonces, para toda tupla t de la
extensión de R, los valores para el conjunto de atributos CF de t son valores nulos, o
bien valores que coinciden con los valores para CP de alguna tupla s de S.
En el caso de que una tupla t de la extensión de R tenga valores para CF que coincidan
con los valores para CP de una tupla s de S, decimos que t es una tupla que referencia s
y que s es una tupla que tiene una clave primaria referenciada por t.
19. ¿Qué son las reglas de negocio o comerciales?
Existen varias definiciones de reglas de negocio, algunas sencillas y compactas, otras
más amplias y detalladas. Una regla de negocio según Ronald G. Ross (Ross, 2010) es
simplemente una regla que está bajo jurisdicción del negocio, lo cual significa que estas
pueden ser creadas, revisadas y eliminadas cuando el negocio lo estime conveniente.
Tony Morgan (Morgan, 2002) por otra parte las define como una declaración compacta
sobre un aspecto del negocio, usando un lenguaje simple, inequívoco, accesible a todas
las partes interesadas: el dueño del negocio, el analista, el arquitecto técnico, y así
sucesivamente.
 20. Para esta relación identifique todas sus propiedades, además indique cual es la
clave primaria

Clave primaria Atributos

Cardinalidad Tuplas

Grado
 Bibliografía
SILBERSCHATZ A. (2005). Sistema Operativo: Aspectos internos y principios de
diseño. Madrid, España. McGRAW-HILL/INTERAMERICANA DE ESPAÑA, S.A.U.

https://www.digitalocean.com/community/tutorials/understanding-relational-databases-es

https://es.wikipedia.org/wiki/12_reglas_de_Codd

https://bookdown.org/paranedagarcia/database/el-modelo-relacional.html

https://www.researchgate.net/publication/
303859206_Reglas_de_negocio_en_bases_de_datos_relacionales