rdbms

Bases de datos relacionalesBiografía

Edgar Frank Codd(23 de agosto de 1923 - 18 de abril de 2003)

Nació en Portland Bill, un remoto pueblo de Dorset, Inglaterra, hijo de un curtidor y una profesora, siendo el menor de siete hermanos. Estudió becado matemáticas y química en Oxford.

Aunque podría haber evitado participar en la segunda guerra mundial por ser estudiante, se alistó en la Real Fuerza Aérea. A los 25 años viajó a los Estados Unidos y consiguió trabajo en IBM como programador matemático usando un prototipo de computador que ocupaba dos pisos completos de un edificio de oficinas en Manhattan.

Biografía

En 1953 emigró a Ottawa, Canadá, frustrado por la política McCarthy de persecución a los comunistas.

Unos años más tarde volvió a Estados Unidos y obtuvo la ciudadanía. En 1965 terminó un doctorado en computación en la Universidad de Michigan en Ann Arbor.

El 18 de abril del 2003 falleció el Dr. Edgar Frank Codd, a la edad de 79 años víctima de un ataque al corazón

Bases de datos relacionales

Historia de las bases de datos relacionalesEn las décadas de los sesenta y los setenta trabajó en sus teorías sobre modelado de datos, publicando su trabajo "Un modelo relacional de datos para grandes bancos de datos compartidos" ("A Relational Model of Data for Large Shared Data Banks") en 1970, donde definió lo siguiente.

Los sistemas de bases de datos deberían presentarse a lo usuarios con una visión de los datos organizados en estructuras llamadas relaciones, definidas por conjuntos de filas (tuplas), en la cual puede haber cualquier estructura de datos compleja que permita una respuesta rápida a una variedad de consultas.

El usuario de un sistema relacional solo debía preocuparse por el qué consultar y no el como de las estructuras de almacenamiento.

“El contenido entero de una base de datos relacional se presenta por una y solo una forma a saber: como valores de atributos en tuplas dentro de relaciones” Edgar Frank Codd.


Bases de datos relacionalesAnteriormente el único modelo teórico estandarizado era el Codasyl que se utilizó masivamente en los años 70. Codd introduce el término relación (en inglés relationship, a veces traducido como interrelación) que es el que aglutina los datos deforma independiente a lo que será su almacenamiento físico.

Lo que Codd intenta precisamente es que este modelo oculte completamente conceptos y términos de la computadora en sí, es decir se abstrae más que los modelos anteriores.Trabajó para IBM , empresa que tardó un poco en implementar sus bases. De hecho fueron otras empresas las que implementaron sus teorías (Larry Ellison diseño la Base de datos de Oracle) .

Pocos años después el modelo se empezó a utilizar cada vez más, hasta finalmente ser el modelo de bases de datos más popular. Hoy en día casi todas las bases de datos siguen este modelo.

Bases de datos relacionalesObjetivos:

Codd propone, a finales de los años sesenta, un modelo de datos basado en la teoría de las relaciones, en donde los datos se estructuran en forma de relaciones (tablas).El trabajo publicado por Codd presentaba un nuevo modelo de datos que perseguía una serie de objetivos, que se pueden resumir en los siguientes:Independencia Física: es decir, que el modo en el que se almacenan los datos no influya en su manipulación lógica y, por tanto, los usuarios que accedan a esos datos no tengan que modificar sus programas por cambios en el almacenamiento físico.Independencia Lógica: esto es, que el añadir, eliminar o modificar objetos de la base de datos no repercuta en los programas y/o usuarios que están accediendo a subconjuntos parciales de los mismos (vistas).Flexibilidad: en el sentido de poder presentar a cada usuario los datos de la forma en que éste prefiera (distintas vistas).Sencillez: las características anteriores, así como unos lenguajes de usuario muy sencillos, producen como resultado que el modelo de datos relacional sea fácil de comprender y de utilizar por parte del usuario final.

Bases de datos relacionalesLA ESTRUCTURA DE LAS BASES DE DATOS RELACIONALES

Según el modelo relacional (desde que Codd lo enunció) el elemento fundamental es lo que se conoce como relación, aunque más habitualmente se le llama tabla (o también array o matriz). Codd definió las relaciones utilizando un lenguaje matemático, pero se pueden asociar a la idea de tabla (de filas y columnas) ya que es más fácil de entender.

Bases de datos relacionalesLA ESTRUCTURA DE LAS BASES DE DATOS RELACIONALES

Las relaciones constan de: Atributos: Referido a cada dato que se almacena en la relación

(nombre, dni,…).

Tuplas: Referido a cada elemento de la relación. Por ejemplo si una relación almacena personas, una tupla representaría a una persona en concreto.

Puesto que una relación se representa como una tabla; podemos entender que las columnas de la tabla son los atributos; y las filas, las tuplas.

Bases de datos relacionalesTerminología del modelo relacionalRelación: es un conjunto de datos referentes a un conjunto de entidades y organizados en forma tabular, (array o matriz) que se compone de filas y columnas, (tuplas y atributos), en la que cada intersección de fila y columna contiene un valor. Codd definió las relaciones utilizando un lenguaje matemático, en el cual se puede asociar la idea de tabla.

Tupla: A menudo se le llama también registro o fila, físicamente es cada una de las líneas de la relación. Equivale al concepto de entidad del modelo E-R, y define un objeto real, ya sea abstracto, concretos o imaginario.

Atributo: También denominado campo o columna, corresponde con las divisiones verticales de la relación. Corresponde al concepto de atributo del modelo ER y contiene cada una de las características que definen una entidad u objeto.

Nulo (NULL): Hay ciertos atributos, para determinadas entidades, que carecen de valor. El modelo relacional distingue entre valores vacíos y valores nulos. Un valor vacío se considera un valor tanto como cualquiera no vacío, sin embargo, un nulo NULL indica la ausencia de valor.

Ejemplos del atributo NullPor ejemplo: Si tenemos una relación de vehículos en la que podemos guardar tanto motocicletas como automóviles, un atributo que indique a qué lado está el volante (para distinguir vehículos con el volante a la izquierda de los que lo tienen a la derecha), carece de sentido en motocicletas. En ese caso, ese atributo para entidades de tipo motocicleta será NULL.

Esto es muy interesante, ya que el dominio de este atributo es (derecha,izquierda), de modo que si queremos asignar un valor del dominio no hay otra opción. El valor nulo nos dice que ese atributo no tiene ninguno de los valores posibles del dominio. Así que, en cierto modo amplia la información.

Otro ejemplo:, en una relación de personas tenemos un atributo para la fecha de nacimiento. Todas las personas de la relación han nacido, pero en un determinado momento puede ser necesario insertar una para la que desconocemos ese dato. Cualquier valor del dominio será, en principio, incorrecto. Pero tampoco será posible distinguirlo de los valores correctos, ya que será una fecha. Podemos usar el valor NULL para indicar que la fecha de nacimiento es desconocida.


Bases de datos relacionalesTerminología del modelo relacionalDominio: Un dominio contiene todos los posibles valores que puede tomar un determinado atributo por ejemplo: Dirección 50 caracteres, Nacionalidad mex.

Un dominio en realidad es un conjunto finito de valores del mismo tipo. A los dominios se les asigna un nombre y así podemos referirnos a ese nombre en más de un atributo.

La forma de indicar el contenido de un dominio se puede hacer utilizando dos posibles técnicas: Intensión: (mediante una propiedad que recoja el recorrido de sus valores admisibles)

o cuando se definen los posibles valores que este puede permitir. Por ejemplo, el dominio de edades de los trabajadores de una empresa “números enteros entre el 16 y el 65” (un trabajador sólo podría tener una edad entre 16 y 65 años).

Extensión: (enumeración de sus elementos) o Cuando se indican los valores y se sobreentiende el resto gracias a que se autodefinen con los anteriores. Por ejemplo el dominio alumnos de una escuela se podría definir por extensión así: Juan, Carlos, Jorge,…


Terminología del modelo relacional

Cardinalidad: Número de tuplas que contiene una relación o numero de filas de una tabla.

La cadinalidad puede cambiar, y de hecho lo hace frecuentemente, a lo largo del tiempo: siempre se pueden añadir y eliminar tuplas.

Grado: Número de atributos de cada tupla.

El grado de una relación es un valor constante. Esto no quiere decir que no se puedan agregar o eliminar atributos de una relación; lo que significa es que si se hace, la relación cambia. Cambiar el grado, generalmente, implicará modificaciones en las aplicaciones que hagan uso de la base de datos, ya que cambiarán conceptos como claves e interrelaciones, de hecho, puede cambiar toda la estructura de la base de datos.

Bases de datos relacionalesSinónimos del modelo relacional

Archivo

Bases de datos relacionalesDefinición formal de relación

Nombre: Identifica la relación. Cabecera de relación: conjunto de todos los pares atributo- relación de la

relación.

donde n es el grado.

Cuerpo de la relación: representa el conjunto de m tuplas {t1,t2,…tn} que forman la relación. Cada tupla es un conjunto de n pares atributo-valor

donde Vij es el valor del dominio Dj asociado al atributo Ai.

Esquema de la relación: Se forma con el nombre R y la cabecera. Es decir:

Estado de la relación: lo forman es esquema y el cuerpo.

Bases de datos relacionalesEjemplo:


Propiedades de las tablas (relaciones)

Cada tabla tiene un nombre distinto. Todo atributo de una tabla toma un solo valor en cada

tupla. Cada atributo tiene un nombre distinto en cada tabla

(aunque puede coincidir en tablas distintas. Cada tupla es única (no hay tuplas duplicadas). El orden de los atributos no importa. El orden de las tuplas no importa.

Tipos de Lenguajes Relacionales

El modelo relacional, como todo modelo de datos, lleva asociado a su parte estática (estructura y restricciones) una dinámica que permite la transformación entre estados de la base de datos.

Esta transformación de un estado origen a un estado objetivo se realiza aplicando un conjunto de operadores, mediante los cuales se llevan a cabo los siguientes tipos de operaciones:

Inserción de tuplas Borrado de tuplas Modificación de tuplas Consultas

Lenguajes de Bases de datos Relacionales


Tipos de tablas

Si O es un operador, el paso de un estado origen de la base de datos (BDi) a un estado objetivo (BDj) se pueden expresar como:

O(BDi) = BDj

ambos estados deben satisfacer las restricciones de integridad estáticas, y la transformación ha de cumplir las restricciones de integridad dinámicas (entre estados).


Lenguajes de Bases de datos RelacionalesTipos de Lenguajes Relacionales

Los lenguajes relacionales (LR) operan sobre conjuntos de tuplas, es decir, no son lenguajes navegacionales (que manipulan registros, como Pascal, Basic, Cobol, XBase, ...) sino de especificación.

• Se dividen en dos tipos:

Algebraicos: los cambios de estado se especifican mediante operaciones, cuyos operandos son relaciones y cuyo resultado es otra relación. Genéricamente se conocen como álgebra relacional.

Predicativos: los cambios de estado se especifican mediante predicados que definen el estado objetivo sin indicar las operaciones que hay que realizar para llegar al mismo. Genéricamente se conocen como cálculo relacional. Se dividen en dos subtipos:

Orientados a tuplas. Orientados a dominios.

Los lenguajes comerciales (SQL, MySQL, ORACLE, QBE, etc.) están basados en los anteriores pero con sintaxis más amigable.


Bases de datos relacionalesCODASYL

Fue un consorcio de industrias informáticas (fabricantes de computadoras, empresas privadas y el departamento de defensa de los Estados Unidos) formado en 1959 con el objeto de regular el desarrollo de un lenguaje de programación estándar que pudiera ser utilizado en multitud de computadoras. Su principal meta era promover un análisis, diseño e implementación de los sistemas de datos más efectivos. La organización trabajó en varios lenguajes a lo largo del tiempo pero nunca llegaron a establecer estándar alguno, proceso que dejaron en manos de (ANSI) American Nartional Standards Institute.

Bases de datos relacionalesEL MODELO CODASYL DBTGEste modelo fue desarrollado en 1971 por un grupo conocido como CODASYL: Conference on Data System Languages, Data Base Task Group, de ahí el nombre; este comité , entre otras cosas, desarrolló el lenguaje de programación COBOL y un Modelo de Base de Datos en Red con su mismo nombre.

El modelo CODASYL ha evolucionado durante los últimos años y existen diversos productos DBMS orientados a transacciones que se basan sobre el, sin embargo hoy día, estos productos están en declinación, ya que este modelo es complejo y no cohesivo, además este modelo tiene mucho enfoque de COBOL, gran parte a las deficiencias detectadas en la actualidad se le atribuye a que este modelo fue desarrollado muy pronto antes de que se establecieran correctamente los conceptos esenciales de la tecnología de bases de datos.

Bases de datos relacionalesEL MODELO CODASYL DBTG

La historia del modelo CODASYL es compleja. Se desarrollaron tres versiones distintas y, aunque el modelo de datos fue sometido dos veces a la consideración del (ANSI) como una norma nacional, jamás fue aceptado. En su lugar, en agosto de 1986, se reconoció como el estándar nacional de base de datos el modelo relacional SQL.

Las funciones y características básicas de las tres versiones del modelo CODASYL son iguales. La mayor parte de los productos DBMS comerciales basados en este modelo se basan en la primera, desarrollada en 1971. Los modelos posteriores de 1978 y 1981 modificaron parte del lenguaje y la sintaxis, agregaron características de soporte para la definición de restricciones e incluyeron otras modificaciones.


En el modelo DBTG solamente pueden emplearse enlaces uno a uno y uno a muchos. En este modelo existen dos elementos principales que son el dueño y el miembro, donde solo puede existir un dueño y varios miembros, donde cada miembro depende solamente de un dueño.

El modelo Codasyl definió una serie de elementos básicos que definían su estructura de datos. Son los siguientes:

1. Elemento de datos: Unidad de datos más pequeña que se puede referenciar. Puede ser de distintos tipos, y puede definirse como dependiente de valores de otros elementos (datos derivados).

2. Agregado de datos: Se asemeja a los campos de un fichero o a los atributos de otros modelos.

Bases de datos relacionalesEL MODELO CODASYL DBTG3. Registro: Colección nominada de elementos de datos. Unidad básica

de acceso y manipulación. Se asemeja a los registros en ficheros y a las entidades en el modelo E/R.

4. Conjunto (SET): Colección nominada de dos o más tipos de registros que establece una vinculación entre ellos. Origen de muchas restricciones. Las interrelaciones 1:N se representan aquí mediante SET.

5. Área: Subdivisión nominada del espacio direccionable de la base de datos que contiene ocurrencias de registros.

6. Clave de base de datos: Identificador interno único para cada ocurrencia de registro.Proporciona su dirección en la base de datos. Es un obstáculo para conseguir la independencia lógica/física. Suponía problemas el reutilizar una clave cuando se reorganizaba la base de datos.

CODASYL: CONJUNTOS (SET)

El conjunto es uno de los más importantes elementos del modelo Codasyl, pues constituye el elemento básico para la representación de interrelaciones. Mediante SET se establecen relaciones jerárquicas (1:N) a dos niveles. El nodo raíz es el propietario y los nodos descendientes (pueden ser de varios tipos) son los miembros.



RESTRICCIONES INHERENTES DEL MODELO CODASYL

Cuando hablábamos del modelo en red general, decíamos que era un modelo muy flexible a coste de no tener restricciones inherentes. Esta ausencia de restricciones hace que sea muy difícil de implementar, y a la larga suele reportar escaso rendimiento, por lo que como también decíamos no pasa de ser un modelo teórico.

El modelo Codasyl está basado en el modelo en red general, pero a diferencia de este, es un modelo utilizado. Esto es debido a que Codasyl ha incluido restricciones inherentes que hacen que sea posible su implementación y que se obtenga un alto rendimiento del sistema.

EL MODELO CODASYL DBTG

Las restricciones son las siguientes:

1. Solo se admiten tipos de interrelaciones jerárquicas de dos niveles (propietario y miembro). Si se admite la combinación de varios SET para generar jerarquías multinivel.

2. En el nivel propietario solo se permite un tipo de registro.3. En el mismo SET no se permite que a un registro ser a la vez

propietario y miembro, no está admitida la reflexividad. Aunque esta restricción se eliminó con el tiempo, los productos basados en Codasyl la siguen utilizando.

4. Una misma ocurrencia de miembro no puede pertenecer en un mismo tipo de SET a más de un propietario. Esto hace que se simplifique la implementación física de los SET, ya que sus ocurrencias se pueden organizar como una cadena.


rdbms

Documents