You are on page 1of 6

Parte I.

- Modelado Base de Datos Relacional


Capitulo 2.- El modelo relacional de los datos.
Este capitulo presenta el modelo mas importante de los datos: la tabla bidimensional o relacion.
Comenzamos con una vision general de los modelos de datos. Le damos la terminologia basica de las
relaciones y mostrar como el modelo puede ser usado para representar las formas tipicas de los datos. A
continuacion presentamos una parte del lenguaje SQL esa parte se utilza para declarar las relaciones y
su estructura. El captulo se cierra con una introduccion al lgebra relacional. Vemos como esta
notacion sirve como un lenguaje de consulta el aspecto de un podelo de datos que nos permite hacer
preguntas acerca de los datos y como un lenguaje de restriccion el aspecto de un modelo de datos
que nos permite restringir los datos en la base de datos de diversas maneras.
Una vision general de los modelos de datos
La nocion de un modelo de datos es uno de los mas fundamentales en el estudio del sistema de base
de datos. En este breve resumen del concepto, se define la terminologia basica y mencionar los
modelos de datos mas importantes.
2.1.1 Que es un modelo de datos?
Un modelo de datos es la notacion para los datos o informaciones que describen. La descripcion
general conta de tres partes:
1. Estructura de los datos. Usted puede estar familiarizado con las herramientas en lenguajes de
programacion como C o Java para describir la estructura de los datos utilizados por un
programa: arreglos y estructuras (estructuras) u objetos por ejemplo. Las estructuras de datos
que se utilizan para aplicar los datos en el ordenador se refieren a veces, en las discusiones
sobre el sistema de base de datos, como un modelo de datos fisico, aunque en realidad estan
muy lejos de las puertas y los electrones que verdaderamente sirven de la implementacion fisica
de los datos. En el mundo de base de datos, los modelos de datos estan a un nivel algo superior
a las estructuras de datos, y se refiere a veces como un modelo conceptual para enfatizar la
diferencia de nivel. Veremos ejemplos en breve.
2. Las operaciones sobre los datos. En los lenguajes de programacion, las operaciones sobre los
datos son por lo general todo lo que se puede programar. En los modelos de datos de base de
datos, por lo general hay un conjunto limitado de operaciones que se pueden realizar. Se nos
permite generalmente para relaizar un conjunto limitado de consultas (operaciones que
recuperan informacion) y modificaciones (operaciones que cambian la base de datos). Esta
limitacion no es una debilidad, sino una fortaleza. Por operaciones de la limitacion, es posible
para los programadores describir las operciones de base de datos a un nivel muy alto, sin
embargo, que el sistema de gestion de base de datos de aplicacion de las operaciones de manera
eficiente. En comparacion, es generalmente imposible para optimizar programas en lenguajes
convencionales como C, en la medida en que un algoritmo ineficiente (por ejemplo, de burbuja)
se sustituye por uno mas eficiente (por ejemplo quicksort).
3. Las limitaciones de los datos. Los modelos de datos de base de datos por lo general tienen un
forma de describir las limitaciones en lo que pueden ser los datos. Estas limitaciones pueden ir
desde la simple (por ejemplo, un dia de la semana es un nmero entero entre 1 y 7 o una
pelicula tiene a lo mas un titulo) tienen algunas limitaciones muy complejos que vamos a
discutir en las secciones 7.4 y 7.5.
2.1.2 Importantes Modelos de Datos.
Hoy en dia, los dos modelos de datos de importacia preeminente para el sistema de base de datos son:
1. El modelo relacional, incluyendo las extenciones objeto-relacional.

2. El modelo de datos semiestructurados, incluyendo XML y estandares relacionados.


La primera, que est presente en todos los sistemas de gestion de base de datos comercial, es el tema de
este capitulo. El modelo semiestructurado, de las cuales XML es la manifestacion primaria, es una
caracteristica adicional de la mayoria de los DBMS relacionales, y aparece en una serie de otros
contextos tambien. Nos dirigimos a ese modelo de datos a partir del capitulo 11
2.1.3 El Modelo Relacional en Breve.
El modelo relacional se basa en tablas, de las cuales la fig. 2.1 es un ejemplo. Discutiremos este modelo
a partir de la seccion 2.2. Esta relacion, o tabla, describe las peliculas, su titulo, el ao en que se
hicieron, su duracion en minutos, y el genero de la pelicula. Mostramos tres peliculas particulares, pero
usted debe imaginar que hay muchas mas filas en esta tabla una fila por cada pelicula hecha, talvez.
La parte de la estructura del modelo relacional puede parecer parecerse a una gran variedad de
estructuras de C, donde los encabezados de columna son los nombres de los campos y cada una de las
filas representan los valores de una estructura de la matriz.

Sin embargo, hay que destacar que esta implementacion fisica es solo una forma posible de la tabla que
podra ser implementado en las estructuras de datos fisicos. De hecho, no es la forma habitual de
representar las relaciones y una gran parte del estudio de los sistemas de bases de datos se ocupa de la
forma correcta de aplicar dichas tablas. Gran parte de la distincion proviene de la escala de las
relaciones no se implementan normalmente como estructuras de memoria principal y su
implementacion fisica adecuada debe tener en cuenta la necesidad de acceder a las relaciones de
tamao muy grande que residen en el disco.
Las operaciones que normalmente se asocian con el modelo relacional forman el lgebra relacional,
que discutiremos a partir de la seccion 2.4. Dichas operaciones son tabla-orientadas. A modo de
ejemplo, podemos pedir todas las filas de una relacion que tienen un cierto valor en una determinada
columna. Por ejemplo, podemos pedir a la tabla en la fig. 2.1 para todas las filas en las que el genero es
comedia.
La porcion de limitacion del modelo de datos relacional se abordar brevemente en la seccion 2.5 y se
cubre con ms detalle en el capitulo 7. aSin embargo como una breve muestra de qu tipo de
restricciones se utilizan generalmente, podriamos decidir que existe una lista fija de generos de
peliculas y que la ultima columna de cada fila debe tener un valor que est en esta lista. O podemos
decidir que (incorrectamente resulta) que nunca podria haber dos peliculas on el mismo ttulo y
restringir la tabla para que no haya dos filas que puedan tener la misma cadena en primer componente.
2.1.4 El modelo semiestructurado en breve
Datos semiestructurados asemejan rboles o graficos, en lugar de tablas o matriz. La principal
manifestacion de este punto de vista hoy es XML una forma o presentar datos por parte de elementos
etiquetados jerarquicamente anidados. Las etiquetas, similar a los utilizados en HTML definir el papel
que desempean las diferentes piezas de datos tanto como los ttulos de las columnas hacen en el
modelo relacional. Por ejemplo, los mismos datos podran aparecer en un documento XML como la
fig. 2.2.

Las operaciones sobre los datos semiestructurados implican generalmente ssiguiendo trayectorias en el
arbol implicita de un elemento a uno o mas de sus subelementos anidados, a continuacion, a los
subelementos anidados dentro y asi sucesivamente. Por ejemplo, comenzando en el exterior <Movies>
elemento (el documento completo es la fig. 2.2), podriamos pasar a cada uno de sus anidados
<Pelicula> elementos, cada uno delimitado por la etiqueta <Movie> y a juego </Movie> etiqueta y de
cada <Pelicula> elemento a su anidado <Genre> elementos para ver que peliculas pertenecen al genero
de comedia.

Las restricciones en la estructura de los datos en este modelo a menudo implican el tipo de datos de los
valores asociados a una etiqueta. Por ejemplo, estan los valores asociados con los <Length> enteros
etiqueta o pueden ser cadenas de caracteres arbitrarios? Otras limitaciones determinan qu etiquetas
pueden aparecer anidado dentro del cual otras etiquetas. Por ejemplo, deber cada elemento tener una
<Length> elemento anidado dentro de l? Que otras etiquetas, ademas de los mostradosen la fig. 2.2
podrian utilizarse dentro de un <Movie> elemento? Puede haber mas de un genero de pelicula? Estas
y otras cuestiones se abordaran en la Seccion 11.2.
2.1.5 Otros Modelos de Datos
Hay muchos otros modelos que estan o han estado asociados con DBMS. Una tendencia moderna es
aadir caracteristicas orientadas a objetos al modelo relacional. Hay dos efectos de la orientacion a
objetos en las relaciones:
1. Los valores pueden tener una estructura en lugar de ser tipos elementales como nmero entero o
cadenas como lo fueron en la fig. 2.1.
2. Las relaciones pueden tener metodos asociados.
En cierto sentido, estas extensiones, llamado el modelo objeto-relacional son analogos a la forma en
estructuras en C se extendieron a los objetos C++. Vamos a presentar el modelo objeto relacional en la
seccio 10.3.

Incluso hay modelos de bases de datos de la clase puramente orientado a objetos. En stas la relacion
ya no es el principal concepto de datos-estructuracion pero se convierte en solo una opcion entre
muchas estructuras. Se discute un modelo de base de datos orientada a objetos en la Seccion 4.9,
Hay varios otros modelos que se utilizaron en algunas de las anteriores DBMS, pero que ahora han
caido en desuso. El modelo jerarquico era, al igual que los datos semiestructurados, un modelo
orientado al arbol. Su incoveniente es que a diferencia de los modelos mas modernos, lo que realmente
funciona a nivel fisico, lo que hizo imposible para los programadores escribir un codigo a un
convenientemente alto nivel. Otro de estos modelos fue el modelo de red, que era un grafico orientado,
modelo de nivel fisico. En verdad, tanto el modelo jerarquico y los modelos semiestructurados de hoy,
permiten estructuras graficas completas, y no nos limitan estrictamente a los arboles. Sin embargo, la
generalidad de los graficos fue construido directamente en el modelo de red, en lugar de favorecer a los
arboles como estos otros modelos lo hacen.
2.16 Comparacion de los metodos de modelizacion.
Incluso desde nuestro breve ejemplo, parece que los modelos semiestructurados tienen mas flexibilidad
que las relaciones. Esta diferencia se hace an ms evidente cuando se discute, como veremos, que tan
lleno de estructuras de graficos estan integrados en modelos semiestructurados en forma de arbol. Sin
embargo, el moelo relacional se seguia prefiriendo de DBMS y debemos entender por qu. El
argumento breve sigue.
Debido a que las bases de datos son grandes, la eficiencia de acceso a los datos y la eficiencia de las
modificaciones a que los datos son de gran importancia. Tambien es muy importante la facilidad de uso
la productividad de los programadores que utilizan los datos. Sorprendentemente, ambos objetivos
pueden lograrse con un modelo, en particular el modelo relacional, que:
1. Proporciona un enfoque simple, limitado a la estructuracion de los datos, sin embargo, es
bastante versatil, asi que cualquier cosa puede ser modelada.
2. Proporciona una limitada, pero util, coleccion de operaciones sobre los datos.
En conjunto, estas limitaciones se convierten en caracteristicas. Ellas nos permiten implementar
idiomas, tales como SQL, que permiten al programador expresar sus deseos en un nivel muy alto. Unas
pocas lineas de SQL pueden hacer el trabajo de miles de lineaas de C, o cientos de lineas de codigo que
tenia que ser escrito para acceder a los datos en virtud de los modelos anteriores, como la red o
jerarquica. Sin embargo, los programas de SQL cortos, debido a que utilizan unos conjuntos
fuertemente limitados de las operaciones, se pueden optimizar para correr tan rapido o mas rapido que
el codigo escrito en lenguajes alternativos.
2.2 Conceptos basicos del modelo relacional
El modelo relacional nos da una sola manera de representar los datos: como una tabla de dos
dimensiones llama una relacion. Figura 2.1, que copiamos aqui como figura 2.3, es un ejemplo de una
relacion, que llamaremos Movies. Las filas representan cada una pelicula, y las columnas representan
cada una propiedad de las peliculas. En esta seccion, vamos a introducir la terminologia mas
importante con respecto a las relaciones, e ilustrarlos con la relacion Movies.

2.2.1 Atributos.
Las columnas de una relacion son nombradas por atributos; en la fig. 2.3 los atributos son el title, year,
length, y genre. Los atributos aparecen en la parte superior de las columnas. Por lo general, un atributo
describe el significado de las entradas en la columna de abajo. Por ejemplo, la columna con length del
atributo contiene la longitud, en minutos, de cada pelicula.
2.2.2 Esquemas
El nombre de una relacion y el conjunto de atributos de una relacion se llama el esquema para esa
relacion. Mostramos el esquema de la relacion con el nombre de la relacion, seguido de una lista entre
parentesis de su atributo. Por lo tanto, el esquema de relaciones Movies de la fig. 2.3 es

Los atributos de un esquema de relacion son un conjunto, no una lista. Sin embargo, con el fin de
hablar sobre las relaciones a menudo debemos especificar un orden de estandar para los atributos. De
este modo, cada vez que se introduce en un esquema de relacion con una lista de atributos, como el
anterior, nos tomamos este ordenamiento a la orden estandar cada vez que mostramos la relacion o
cualquiera de sus filas.
En el modelo relacional, una base de datos consta de una o mas relaciones. El conjunto de esquemas
para las relaciones de una base de datos se denomina un esquema de base de datos relacional, o
simplemente un esquema de base de datos.
2.2.3 Las Tuplas
Las filas de una relacion, excepto la fila de encabezado que contiene los nombres de los atributos, se
llaman tuplas. Una tupla tiene un componente para cada atributo de la relacion. Por ejemplo, la primera
de las tres tuplas en la fig. 2.3 tiene los cuatro componentes Gone With the Wind, 1939, 231, y drama
de los atributos title, year, length, and genre, respectivamente. Cuando queremos escribir una tuple de

forma aislada, no como parte de una relacion, normalmente utilizamos comas para separar los
componentes, y usamos parentesis para rodear la tupla. Por ejemplo

es la primera tupla de la fig. 2.3. Tenga en cuenta que cuando uns tupla aparece de forma aislada, no
aparecen los atributos, por lo que alguna ondicacion de la relacion a la que pertenece se debe de dar la

tupla. Usaremos simpre el orden en que los atributos se enumeran en el esquema de la relacion.
2.2.4 Dominios.

You might also like