ISIÓN GENERAL DE BASES DE DATOS:

Modelo Entidad-Relación y Modelo Relaciona I

INTRODUCCIÓN.

Una base de datos es en esencia una colección estructurada de datos relacionados entre
sí, de la cual los usuarios pueden extraer información.

Un objetivo importante de un sistema de base de datos es proporcionar a los usuarios

una visión abstracta de los datos, es decir, esconder ciertos detalles de cómo se
almacenan y mantienen los datos. Sin embargo para que el sistema sea manejable, los
datos se deben extraer eficientemente.

Los sistemas de base de datos se diseñan para manejar grandes cantidades de

información.

La manipulación de los datos involucra tanto la definición de estructuras para el

almacenamiento de la información como la provisión de mecanismos para el manejo de
la información.

Además un sistema de base de datos debe de tener implementados mecanismos de

seguridad que garanticen la integridad de la información, a pesar de caídas del sistema o

intentos de accesos no autorizados.

PARTES QUE COMPONEN UNA BASE DE DATOS.

• Hardware: equipo informático

• Software: El SGBD (Sistema Gestor de Bases de Datos) es la parte más importante

del software de un sistema de base de datos. Es una colección de numerosas rutinas de

software interrelacionadas, cada una de las cuales es responsable de alguna tarea
específica.

Por ejemplo, Access es un SGBD, que actúa como interfaz entre los datos y los usuarios
finales. Más adelante se detallarán aspectos relevantes de un SGBD.

• Usuarios: Podemos definir a los usuarios como toda persona que tenga todo tipo de
contacto con el sistema de base de datos, desde quién la diseña, elabora, termina, hasta
los usuarios finales.

OBJETIVOS DE LOS SISTEMAS DE BASES DE DATOS.

Los objetivos principales de un sistema de base de datos es:

1. Disminución de la redundancia y eliminación de la inconsistencia de datos.

Si no se controla detalladamente el almacenamiento, se pueda originar un duplicado de

información, es decir, que la misma información esté más de una vez en un dispositivo
de almacenamiento. Esto aumenta los costos de almacenamiento y acceso a los datos,
además de que puede originar la inconsistencia de los datos (diversas copias de un
mismo dato no concuerdan entre si).

SISTEMA GESTOR DE BASES DE DATOS.

El SGBD es la porción más importante del software de un sistema de base de datos.

El objetivo primordial de un SGBD es proporcionar un entorno que sea a la vez

conveniente y eficiente para ser utilizado al extraer, almacenar y manipular información
de la base de datos.

La figura muestra el SGBD como interfaz (intermediario) entre la base de datos física y
las peticiones del usuario.

El SGBD interpreta las peticiones de entrada/salida del usuario y las manda al sistema
operativo para la transferencia de datos entre la unidad de memoria secundaria (discos)
y la memoria principal.

En sí, un SGBD es el corazón de la base de datos ya que se encarga del control total de
los posibles aspectos que la puedan afectar.

Las funciones principales de un SGBD son:

1. Crear y organizar la Base de Datos.

2. Establecer y mantener las trayectorias de acceso a la base de datos de tal forma que
los datos puedan ser accedidos rápidamente.

3. Manejar los datos de acuerdo a las peticiones de los usuarios.

4. Registrar el uso de las bases de datos.

5. Responsable del verdadero almacenamiento de los datos.

6. Respaldo y recuperación. Consiste en contar con mecanismos implantados que

permitan la recuperación fácilmente de los datos en caso de ocurrir fallos en el sistema

de base de datos.

7. Control de concurrencia. Consiste en controlar la interacción entre los usuarios

concurrentes para no afectar la inconsistencia de los datos.

8. Seguridad e integridad. Consiste en contar con mecanismos que permitan el

control de la consistencia de los datos evitando que estos se vean perjudicados por
cambios no autorizados o previstos.

2. Minimizar la dificultad para tener acceso a los datos.

Un sistema de base de datos debe contemplar un entorno de datos que le facilite al

usuario el manejo de los mismos. Supóngase un banco, y que uno de los gerentes
necesita averiguar los nombres de todos los clientes que viven dentro del código postal
48733. El gerente pide al departamento de procesamiento de datos que genere la lista
correspondiente. Puesto que esta situación no fue prevista en el diseño del sistema, no
existe ninguna aplicación de consulta que permita este tipo de solicitud, y esto ocasiona
una deficiencia del sistema.

3. Evitar anomalías del acceso concurrente.

Para mejorar el funcionamiento global del sistema y obtener un tiempo de respuesta más
rápido, muchos sistemas permiten que múltiples usuarios actualicen los datos
simultáneamente. En un entorno así, la interacción de actualizaciones concurrentes
puede dar por resultado datos inconsistentes. Para prevenir esta posibilidad debe
mantenerse alguna forma de supervisión en el sistema.

4. Permitir restricciones de seguridad.

La información de toda empresa es importante, aunque unos datos lo son más que otros,
por tal motivo se debe considerar el control de acceso a los mismos, no todos los
usuarios pueden visualizar alguna información, por tal motivo para que un sistema de
base de datos sea confiable debe mantener un grado de seguridad que garantice la
autentificación y protección de los datos. En un banco por ejemplo, el personal de
nóminas sólo necesita ver la parte de la base de datos que tiene información acerca de
los distintos empleados del banco y no otro tipo de información.

5. Asegurar el mantenimiento de integridad.

Los valores de datos almacenados en la base de datos deben ser correctos. Pueden ser
incorrectos debido a:

• Errores en la entrada de datos (Prtugalete en vez de Portugalete)

• Errores en el programa de aplicación (Cálculo incorrecto del IVA soportado)

• Falsificación deliverada

(A nivel de programación, el uso de cuadros combinados y listas facilitan la integridad).

El nivel interno depende del SGBD elegido. Y será este el que implemente (realice) esta
tarea.

Cuando usamos Access, no sabemos cómo almacena físicamente los datos ni dónde.
Access es en el intermediario entre usuarios y el SO(Windows).
Los otros dos niveles (Conceptual y Externo) son tarea del Administrador de Bases de
Datos (ABD), que es la persona encargada y con el control total sobre el sistema de base
de datos.

Las funciones principales de un ABD son:

• Definición de esquema (diseño de la BD).

• Definición de la estructura de almacenamiento según el SGBD elegido

(En Access ^ Tablas y relaciones).

• Concesión de autorización para el acceso a los datos.

• Especificación de límites de integridad.

Aunque es un tarea de propia de usuarios informáticos, también puede encargarse de:

• Programación del interfaz de la BD con los usuarios finales

(Consultas, Formularios e Informes, Módulos de código, ...)

Para realizar el Nivel Conceptual, un ABD se servirá de un modelo de datos, que es una
representación de la realidad mediante una colección de herramientas conceptuales para
describir los datos, las relaciones que existen entre ellos, la semántica asociada a los
datos y las restricciones de consistencia.

En BD esta representación es gráfica y se denomina Esquema Conceptual.

Existen diferentes modelos de datos, pero el más utilizado por su sencillez y eficiencia
es el modelo Entidad-Relación que detallaré a continuación.

La realización de un modelo Entidad-Relación supone siempre el paso previo al futuro

diseño de una BD en cualquiera de los modelos existentes (Relaciona!, Jerárquico, en
Red,...)

MODELO ENTIDAD-RELACIÓN.

Denominado por sus siglas como E-R, este modelo representa la realidad a través de
una representación gráfica que incorpora información relativa a los datos y las
relaciones entre ellos.

Se utiliza como punto de partida en el diseño de una BD, para después transformarlo al
modelo elegido (en nuestro caso el Relacional).

Las características de un modelo E-R son:

1. Refleja tan sólo la existencia de datos, no lo que se hacen con ellos.

2. Se incluyen todos los datos del sistema en estudio, y por tanto, no está orientadoa
aplicaciones particulares.

3. Es independiente de la base de datos y del sistema operativo elegidos.

4. No se tienen en cuenta restricciones de espacio, almacenamiento ni tiempo de

ejecución.

5. Está abierto a la evolución del sistema.

El modelo E-R se basa en la percepción del mundo real, que consiste en un conjunto de
objetos básicos llamados Entidades así como de las Relaciones entre ellos.

ENTIDADES. OCURRENCIAS. ATRIBUTOS. CLAVES Y RELACIONES.

Una Entidad es una cosa u objeto concreto o abstracto que existe, que puede distinguirse
de otros y del que se desea almacenar información.

Los alumnos de una escuela forman la Entidad Alumnos.

Juan Alberdi, de Santurtzi y con DNI 11.635.326P, es una Ocurrencia de la Entidad

Alumnos, ya que identifica de forma única a una persona dentro de ese universo.

Las características de las Ocurrencias de las Entidades se llaman Atributos. Por ejemplo,
el Nombre, DNI y Ciudad son Atributos de Alumnos.

Los Atributos de una entidad pueden tomar un conjunto de valores permitidos al que se
le conoce como Dominio del atributo.

Una Clave es un conjunto de 1 o más atributos, que permiten identificar de forma única
a una ocurrencia dentro de una entidad.

además añadir que ese conjunto de atributos debe ser mínimo, es decir, que ningún
subconjunto de atributos pueda también funcionar como clave

Una Clave se especifica gráficamente en el modelo E-R con una línea debajo del
nombre del atributo.

Se denomina Clave Secundaria o Extranjera al conjunto de atributos de una entidad que

son Clave Primaria en otra.

Entidad Alumnos Ocurrencias

Juan Alberdi Santurtzi 11.635.326P •

Luis Alfageme Sestao 41.485.256H .

Rosa Ma Sanz Portugalete 15.123.563K .

Amparo Rivas Santurtzi 23.236.896N .

Roberto Pozas Sestao 15.365.452F1

Atributos

Una Relación es una asociación entre varias Entidades. Pueden contener también

Atributos, que representan características propias de dicha asociación.

REPRESENTACIÓN GRÁFICA DE UN MODELO E-R.

Para representar gráficamente un modelo E-R. Se emplean los siguientes símbolos:

Representa ENTIDADES

Representa RELACIONES

Representa ATRIBUTOS (de Entidades o de Relaciones)

Enlazan ATRIBUTOS con ENTIDADES o ATRIBUTOS con RELACIONES

Veamos un ejemplo:

Queremos diseñar el modelo E-R de las notas que sacan los alumnos de una escuela en
las diferentes asignaturas en las que están matriculados.

Un modelo E-R con estas especificaciones sería:

Nota: Cuando sea posible poner un nombre lógico a la relación, debe hacerse. No
siempre se podrá. En el ejemplo, la relación entre las entidades Alumnos y Asignaturas
puede llamarse Notas. Si no hubiésemos encontrado dicho nombre, la relación se podría
llamar AluAsig, por ejemplo.

Nótese que la relación tiene un atributo: Nota (este atributo no pertenece ni a Alumnos,
ni a Asignaturas)

ENTIDADES FUERTES Y DÉBILES.

En función de las claves, las entidades pueden clasificarse en:

• Entidades fuertes: Entidades con una clave primaria.

• Entidades débiles: Entidades que no poseen los atributos necesarios para definir una
clave primaria ya que dependen de una entidad fuerte. No obstante es necesario dotar a
la entidad de una clave primaria. Esta estará formada por la Clave Primaria de la entidad
fuerte más 1 o más atributos de la entidad débil (a dichos atributos de la entidad débil se
le llama Discriminador). A veces es posible crear una Clave primaria en la entidad débil
con un nuevo atributo más identificativo.

Nota: Esta es la definición que el modelo E-R hace de las entidades fuertes y débiles. En
el modelo relacional se ofrece otra que más adelante se detallará.
GRADO DE UNA RELACIÓN.

La cantidad de entidades que intervienen en una relación determina el Grado de la

relación.

Por ejemplo la relación NOTAS del ejemplo anterior es de grado 2, ya que intervienen
la entidad ALUMNOS y la entidad ASIGNATURAS.

Aunque el modelo E-R permite relaciones de cualquier grado, la mayoría de las

aplicaciones del modelo sólo consideran relaciones del grado 2. Cuando son de tal tipo,
se denominan Relaciones Binarias.

Un ejemplo de relación ternaria:

PADRES

MADRES

CARDINALIDAD DE LAS RELACIONES.

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:

1. Relación uno a uno.

Una ocurrencia de entidad del tipo A solo se puede relacionar con una ocurrencia
entidad del tipo B, y viceversa.

2. Relación uno a varios.

Significa que una ocurrencia de entidad del tipo A puede relacionarse con cualquier
cantidad de ocurrencias de entidad del tipo B, y que una ocurrencia de entidad del tipo
B solo puede estar relacionada con una ocurrencia de entidad del tipo A.

Nótese en este caso que el extremo punteado de la flecha de la relación de A y B, indica

una ocurrencia de entidad A conectada a varias ocurrencias de entidad B.

3. Relación varios a uno.

Significa que una ocurrencia de entidad del tipo B puede relacionarse con cualquier
cantidad de ocurrencias de entidad del tipo A, y una ocurrencia de entidad del tipo A
solo puede estar

relacionada con una ocurrencia de entidad del tipo B.

4. Relación varios a varios.

Significa que una ocurrencia de entidad del tipo A puede relacionarse con cualquier
cantidad de ocurrencias de entidad del tipo B, y viceversa.
Mencionar que la cardinalidad para cada conjunto de entidades depende del punto de
vista que se le dé al modelo en estudio sujetándose a la realidad.

PASO DEL MODELO E-R AL MODELO RELACIONAL

El modelo E-R es independiente del sistema de BD y del SO que se elija. Pero para
crear físicamente Una BD es necesario pasarlo a uno de estos tres modelos, que ya son
interpretables en un computador:

• Modelo relacional.

• Modelo jerárquico.

• Modelo en red.

Cuando elegimos el SGBD que vamos a utilizar, también estamos eligiendo el modelo
de BD.

El más utilizado sin duda es el relacional (Access, Oracle son SGBDs relaciónales)
debido a su sencillez y facilidad de comprensión.

Una BD relacional es un conjunto de relaciones (tablas) y a cada una de ellas se le

asigna un nombre único.

Cada relación de puede representar como una tabla formada por filas y columnas.

Veamos un ejemplo aclaratorio:

Como una relación (tabla) es un conjunto de tupias (registros), no puede haber 2

tupias iguales. Es una restricción del modelo relacional .

Se llama Dominio al rango de valores legales que puede tomar un atributo. En

lenguajes de programación corresponde al tipo de datos (numérico, texto, fecha/hora,

etc) que puede tomar una atributo.

En el modelo relacional las tablas del extremo "1" se llaman Fuertes y las del extremo
"varios" se les denomina Débiles.

A es la entidad fuerte y B la débil.

Las tablas del modelo relacional deben cumplir los siguientes requisitos:

• Cada fila debe ser única, es decir no pueden existir filas duplicadas.

• El valor de la columna que es clave primaria para cada fila debe ser único.

• No puede contener columnas duplicadas.

• Los valores de las columnas deben pertenecer al dominio de cada atributo.

• Debe tener un solo tipo de fila, cuyo formato está definido por el esquema de tabla o la
relación.

REDUCCIÓN DE DIAGRAMAS E-R A TABLAS.

Un diagrama E-R, puede ser representado también a través de una colección de tablas.
Veamos las reglas:

1. Relación uno a uno.

La entidad A se transfoma en una tabla A cuyos atributos serán los que tiene la entidad
A. La entidad B se transfoma en una tabla B cuyos atributos serán los que tiene la
entidad B.

2. Relación uno a varios.

La entidad A (fuerte) se transfoma en una tabla A cuyos atributos serán los que tiene la
entidad A.

La entidad B (débil) se transfoma en una tabla B cuyos atributos serán los que tiene la
entidad B más los de la clave primaria de la entidad A.

3. Relación varios a uno.

La entidad B (fuerte) se transfoma en una tabla B cuyos atributos serán los que tiene la
entidad B.

La entidad A (débil) se transfoma en una tabla A cuyos atributos serán los que tiene la
entidad A más los de la clave primaria de la entidad B.

4. Relación varios a varios.

Una relación de varios a varios debe ser descompuesta en 2 relaciones

De la relación R se obtiene una tercera entidad R, que tendrá como atributos la clave
primaria de la entidad A, la clave primaria de la entidad B y los atributos que tenía la
relación R.

De esta forma obtenemos 3 tablas al pasar al modelo relaciona!.

Los modelos de datos.

En el proceso de abstracción que conduce a la creación de una base de datos desempeña

una función prioritaria el modelo de datos. El modelo de datos, como abstracción del
universo de discurso, es el enfoque utilizado para la representación de las entidades y
sus características dentro de la base de datos, y puede ser dividido en tres grandes tipos
(KORTH y SILBERSCHATZ, 1993: 6-11):
1. Modelos lógicos basados en objetos: los dos más extendidos son el modelo entidad-
relación y el orientado a objetos. El modelo entidad-relación (E-R) se basa en una
percepción del mundo compuesta por objetos, llamados entidades, y relaciones entre
ellos. Las entidades se diferencian unas de otras a través de atributos. El orientado a
objetos también se basa en objetos, los cuales contienen valores y métodos, entendidos
como órdenes que actúan sobre los valores, en niveles de anidamiento. Los objetos se
agrupan en clases, relacionándose mediante el envío de mensajes. Algunos autores
definen estos modelos como "modelos semánticos".
2. Modelos lógicos basados en registros: el más extendido es el relacional, mientras que
los otros dos existentes, jerárquico y de red, se encuentran en retroceso. Estos modelos
se usan para especificar la estructura lógica global de la base de datos, estructurada en
registros de formato fijo de varios tipos. El modelo relacional representa los datos y sus
relaciones mediante tablas bidimensionales, que contienen datos tomados de los
dominios correspondientes. El modelo de red está formado por colecciones de registros,
relacionados mediante punteros o ligas en grafos arbitrarios. el modelo jerárquico es
similar al de red, pero los registros se organizan como colecciones de árboles. Algunos
autores definen estos modelos como "modelos de datos clásicos".
3. Modelos físicos de datos: muy poco usados, son el modelo unificador y el de
memoria de elementos. Algunos autores definen estos modelos como "modelos de datos
primitivos".

De lo anterior se deduce que el punto clave en la construcción de la base de datos será el

modelo de datos. Se denomina modelo:

"...al instrumento que se aplica a una parcela del mundo real (universo del discurso)
para obtener una estructura de datos a la que denominamos esquema. Esta distinción
entre el modelo (instrumento) y el esquema (resultado de aplicar el instrumento) es
importante... Es importante también distinguir entre mundo real y universo del discurso,
ya que este último es la visión que del mundo real tiene el diseñador... podemos definir
un modelo de datos como un conjunto de conceptos, reglas y convenciones que nos
permiten describir los datos del universo del discurso." (MIGUEL y PIATTINI, 1993:
162)

Los objetivos del modelo de datos son dos:

1. Formalización: definir formalmente las estructuras permitidas y las restricciones a fin

de representar los datos de un SI.
2. Diseño: el modelo resultante es un elemento básico para el desarrollo de la
metodología de diseño de la base de datos.

Los diferentes modelos de datos comparten, aunque con diferentes nombres y

notaciones, unos elementos comunes, componentes básicos de la representación de la
realidad que realizan. Estos componentes se identifican gracias a la clasificación, y
pueden identificarse conceptos estáticos y conceptos dinámicos. Los conceptos estáticos
corresponden a:

1. Objeto: cualquier entidad con existencia independiente sobre el que almacenan datos.
Puede ser simples o compuestos.
2. Relación: asociación entre objetos.
3. Restricción estática: propiedad estática del mundo real que no puede expresarse con
los anteriores, ya que sólo se da en la base de datos; suele corresponder a valores u
ocurrencias, y puede ser sobre atributos, entidades y relaciones.
4. Objeto compuesto: definidos como nuevos objetos dentro de la base de datos,
tomando como punto de partida otros existentes, mediante mecanismos de agregación y
asociación.
5. Generalización: se trata de relaciones de subclase entre objetos, es decir, parte de las
características de diferentes entidades pueden resultar comunes entre ellas.

Por su parte, los conceptos dinámicos responden a:

1. Operación: acción básica sobre objetos o relaciones (crear, modificar, eliminar...).

2. Transacción: conjunto de operaciones que deben ejecutarse en su conjunto
obligatoriamente.
3. Restricción dinámica: propiedades del mundo real que restringen la evolución en el
tiempo de la base de datos.

El modelo jerárquico. Estructura. Relaciones padre-hijo. Propiedades del esquema.

Arboles. Estructura de almacenamiento. Tipos de acceso. Integridad y seguridad del
modelo. Definición completa de una base de datos jerárquica.

El modelo de red. Estructura. Registros. Campos y datos. Tipos y ocurrencias de sets.

Limitantes de membresía (de inserción, retención y ordenamiento). Representaciones de
ocurrencias. Set singular. Set de miembros múltiples. Set recursivo.

El modelo relacional. Conceptos básicos. Dominios, atributos, tuplas, relaciones,

atributos llave, llaves foráneas. Algebra relacional. Operaciones. Cálculo relacional,
Vistas. Esquema de base de datos relacional. Regla de unicidad. Regla de integridad
referencial. Normalización.

Modelo entidad-relación. Atributos y entidades. Valores y dominios de los atributos.

Tipos de entidades. Atributos llave. Tipos de relación. Instancias de rela-ciones.
Restricciones estructurales. Entidad débil. Representación del modelo mediante
diagramas. Generalización y especialización. Agregación. Conversión de los diagramas
en tablas.

Diseño relacional. Requerimientos y análisis. Diseño conceptual. Esquema conceptual.

Diseño lógico. Diseño físico e implantación. Problemas de redundancia. Valores nulos.
Dependencias funcionales. Reglas de inferencia. Formas normales: primera, segunda,
tercera, interpretación de la tercera forma normal, forma normal de Boyce-Codd.
Proceso de normalización. Algoritmos de descomposición. Otros tipos de dependencias
y formas normales. Dependencias multivaluadas.

Modelos alternativos. Modelo orientado a objetos: tipos abstractos de datos, herencia,

identidad de objetos, modelado de datos y estrategias de diseño, persistencia, métodos
especiales de acceso, consideraciones de seguridad. Bases de datos heterogéneas:
tecnología para interoperabilidad, esquemas, renombramiento, consultas, resolución de
conflictos, optimización de consultas globales.

CONCEPTOS BASICOS
 Una base de datos jerárquica consiste en una colección de registros que se conectan
entre si por medio de ligas. Los registros y las ligas son similares a los del modelo de
red, pero en el modelo jerárquico se organiza en forma de árbol con raíz (donde la raíz
es nodo ficticio); de tal manera que una base de datos jerárquica es una colección de
arboles de este tipo, formando un bosque.

A cada árbol con raíz con raíz se le denomina árbol de base de datos.

En este modelo un registro puede tener que repetirse en varios sitios que puede
ocasionarlos siguientes problemas:

 Riesgos de la inconsistencia al llevar a cabo actualizaciones.

 Inevitable desperdicio de espacio en el medio de almacenamiento secundario.

DIAGRAMAS DE ESTRUCTURAS DE ÁRBOL

Un diagrama de estructura de árbol es el esquema de una base de datos jerárquica.

Tiene dos componentes básicos:

REGISTROS y LIGAS

Estos diagramas son similares a los de estructura de datos en el modelo de red. La

diferencia radica en que en el modelo de red los registros se organizan en forma de un
grafo arbitrario mientras que en el modelo jerárquico se organiza en forma de un árbol
con raíz.

1.-No hay ciclos

2.-De padre a hijos son

Las reglas para la formación del árbol son: validas las relaciones de uno a uno a uno a
muchos. El esquema de una base de datos jerárquica se representa como una colección
de diagramas de estructuras de árbol. Para cada diagrama existe una única instancia del
árbol de base de datos. La raíz de este árbol es un nodo ficticio. Los hijos de ese nodo
son instancias del tipo de registros adecuado.

Ejemplo:
CASOS PARTICULARES
 REGISTROS VIRTUALES.

Dado que en las relaciones muchos a muchos existe demasiada repetición de datos, se
maneja el concepto de registro virtual. Un registro virtual es aquel que no se escribe
físicamente en el medio, sino que es una referencia (liga) a un registro existente en
forma previa su representación es :

La razón de utilizar registros virtuales es evitar la repetición de los datos, lo cual

traería consigo los siguientes inconvenientes:

-Redundancia, en consecuencia desperdicio de espacio de almacenamiento.

-Alto riesgo de inconsistencia durante las actualizaciones.

Modelos de Datos De Red

Setentas a Ochentas a
Mediados de los
mediados de los principios de Futuro
Sesentas
ochentas los noventas
De red Semántico Fusión de los
Modelo de Relacional modelos de
 datos y la
representación
de
conocimientos.
Orientado a
datos Jerárquico Modelos
objetos
híbridos

Configuración
cliente-servidor

Computadores
Hardware de Configuración
Macrocomputadores Macrocomputadores personales más
bases de datos cliente-servidor
rápidos
Procesamiento
en paralelo

Memorias
Estaciones de
ópticas
trabajo
Minicomputadores
Máquinas de
bases de datos
Computadores Multimedia
Máquinas
Personales Lenguajes
Interfaz con el dorsales
Ninguna naturales
usuario
Lenguajes de
Gráficos
consulta Entrada de voz
Menús
Formas Texto a mano
libre
Consulta por
formas
Bases de datos
y lenguajes de
programación
integrados.
SQL Gestores de
Interfaz con Por procedimientos Lenguajes de estandarizado presentación
programas consulta generalizados
incorporados Lenguajes de
cuarta Procesamiento
generación de datos y
conocimientos
Programación distribuidos y
lógica heterogéneos,
con
Gráficos de información de
negocios multimedia
 Salida de
imágenes.
Procesamiento
de
transacciones
Procesamiento de Gestión de
Procesamiento de
Procesamiento información y bases de datos
datos Procesamiento
transacciones en paralelo
de
conocimientos

La tabla resume los pasos más destacados en la evolución de la tecnología de bases de

datos durante las últimas tres décadas, aproximadamente. Las tres primeras columnas de
la tabla corresponden aproximadamente a los tres periodos identificables. La última
columna lista los avances que se esperan para el futuro. Analizaremos esta tabla fila por
fila.

MODELOS DE DATOS

Los modelos de red y jerárquicos surgieron en la década de 1960. Desde su introducción

en 1970, el modelo relacional ha provocado un interés creciente debido a sus
propiedades deseables, como son su base formal, su homogeneidad, su conjunto bien
definido de operaciones algebraicas y sus lenguajes basados en el cálculo. Las
desventajas del modelo relacional en términos de su poder expresivo semántico hicieron
surgir el interés por los modelos semánticos. Este interés ha crecido desde finales de los
años setenta, sobre todo con la aparición de los modelos de entidad - relación (ER), de
jerarquía semántica y de datos semántico. El interés por los modelos semánticos
continuó en los años ochenta. Hoy día, cuando los horizontes de las aplicaciones de
bases de datos se encuentran en una clara fase de expansión.

Una de las principales tendencias en los próximos años será hacia los modelos de datos
orientados a objetos (BDOO) y los sistemas de gestión de bases de datos orientadas a
objetos (SGBDOO). Los modelos de datos BDOO poseen un poder de expresión similar
al de los modelos semánticos, pero los rebasan en el sentido de que modelan
explícitamente el comportamiento. Se asegura que son más fáciles de implementar y
usar cuando se trata de crear aplicaciones, debido a la modularidad integrada, el
encapsulamiento y la reutilización de código.

Se ha propuesto la lógica como modelo de datos fundamental para los esquemas de

representación relacionales y de otro tipo. El cálculo relacional se basa en una rama de
lógica denominada cálculo de predicados de primer orden, de modo que ya tiene tiempo
que la lógica se utiliza para caracterizar consultas relacionales. La base de datos lógica
ofrece un formalismo para los lenguajes de consulta, el modelado de integridad, a
evaluación de consultas, el tratamiento de valores nulos, el manejo de información
incompleta, etc. La lógica nos lleva también a un entendimiento formal de la deducción
en las bases de datos. Es probable que en el futuro proliferen más los SGBD orientados
a objetos, se utilice mas la lógica para las bases de datos deductivas y se combinen la
representación de conocimientos, los lenguajes de programación y los modelos de datos.

Otra tendencia clara en la creación de SGBD comerciales es la de producir sistemas

unificados con modelos de datos "híbridos". N ejemplo de ello es el sistema UniSQL
que maneja un modelo de datos completo orientado a objetos que es totalmente
compatible con el modelo relacional. Los proveedores de productos de SGBD
convencionales ya han comenzado a implementar una interfaz relacional basada en SQL
que permitirá la creación concurrente de aplicaciones relacionales.

El modelo CODASYL DBTG.

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.

Empleando el ejemplo de la relación Alumno-cursa-Materia.

Si la relación es uno a muchos sin atributos descriptivos, entonces el diagrama de

estructura
de datos apropiado es:

Si la relación tiene un atributo descriptivo, como el de calif, entonces el diagrama de

estructura de datos apropiado es:

Si la relación fuera de muchos a muchos el algoritmo de transformación seria como el

siguiente considerando que la relación no tiene atributos descriptivos, entonces:
1. Crear los registros correspondientes de las entidades involucradas (alumno,materia).
2. Crear un nuevo tipo de registro ficticio, renlace que puede no tener campos o tener
sólo uno que contenga un identificador único definido externamente.
3. Crear los enlaces correspondientes muchos a uno.

En el caso de las relaciones generales (es decir, no binarias), el algoritmo de

transformación es el mismo empleado para el estructurado de los diagramas de los
modelos de red donde intervienen más de 2 entidades.
Por ejemplo consideremos la agregación de la entidad maestro, entonces para este
caso resulta la estructura siguiente:

Conjuntos DBTG

Como se mencionó anteriormente en este modelo solo pueden utilizarse enlaces

muchos a uno y uno a uno, así una forma general de este modelo sería:
 En el modelo DBTG, esta estructura de denomina conjunto DBTG. El nombre que se
le asigna al conjunto generalmente es el mismo que el de la relación que une a las
entidades.

En todo conjunto DBTG de este tipo, el tipo de registro A se denomina dueño (o

padre) del conjunto, el tipo de registro B se le denomina miembro (o hijo) del
conjunto.Cada conjunto DBTG puede tener cualquier numero de ocurrencias del
conjunto. Puesto que no se permiten enlaces del tipo muchos a muchos, cada ocurrencia
del conjunto tiene exclusivamente un dueño y cero o más registros miembros. Además
ningún registro puede participar en más de una ocurrencia del conjunto en ningún
momento. Sin embargo, un registro miembro puede participar simultáneamente en
varias ocurrencias de diferentes conjuntos.

Podemos ejemplificar las ocurrencias que se pueden presentar, como:

Para ilustrarlo, considérese el diagrama de estructura siguiente:

Existen dos conjuntos DBTG:

AluCal, cuyo dueño es Alumno y cuyo miembro es reenlace.

MatCal, cuyo dueño es Materia y el miembro reenlace.

Declaración de conjuntos

El conjunto AluCal se define: y el conjunto MatCal:

Set name is AluCal Set name is MatCal

owner is Alumno owner is Materia
member is reenlace member is reenlace

Una instancia de la base de datos podría ser:

5.4 Recuperación de datos en DBTG

El lenguaje de manipulación de datos de la propuesta DBTG consiste en un número

de órdenes que se incorporan en un lenguaje principal.

La mayor parte de los comandos de manejo de datos en DBTG de CODASYL tienen

dos pasos. En primer lugar, se emite un comando FIND para identificar el registro sobre
el cual se va a actuar. El comando FIND no lee, procesa el registro indicado;sólo
identifica un registro para que lo localice el DBMS. Una vez identificado el registro, un
segundo comando DML puede emitirse para que se lleve a cabo una operación sobre él.
Patrones típicos son FIND, GET, o bien, FIND, MODIFY; o bien FIND, ERASE.

Cuando el programa emite un comando FIND, se localiza un registro y su identidad

permanece almacenada en una variable especial llamada indicador de posición.
Después, cuando se emite un comando GET, MODIFY, ERASE o bien otro, el DBMS
hace referencia al indicador de posición para determinar cuál es el registro sobre el que
ha de actuar. Los indicadores de posición también se utilizan como puntos de referencia
para los comandos del procesamiento secuencial como son FIND NEXT o FIND
PRIOR.
Las operaciones utilizadas para la recuperación de datos son :

Find: Que localiza a un registro en la base de datos y da valores a los punteros de

actualidad correspondientes

Get: Copia el registro al que apunta el actual de unidad de ejecución de la base de datos
ala plantilla adecuada en el área de trabajo de programa.

La orden FIND tiene varias formas, en este caso estudiaremos 2 ordenes find diferentes
para localizar los registro individuales de la base de datos; La orden más sencilla es de
la forma:

find any < tipo de registro > using < campo de registro >

Esta orden localiza un registro del tipo <tipo registro> cuyo valor de < campo de
registro> es el mismo que el del valor de <campo de registro> en la plantilla del <tipo
de registro> en el área de trabajo del programa. Una vez que se encuentra ese registro se
modifican los siguientes punteros para que apunten a ese registro:

El puntero actual de unidad de ejecución

El puntero de actualidad de tipo de registro que corresponde a <tipo de registro>

Para cada conjunto en el que participe ese registro, el puntero de actualidad de conjunto
apropiado.

Para ilustrar lo anterior, construyamos una consulta en DBTG que nos muestre el
número de control del alumno Luis A. (consideremos el modelo alumno-materia ).

Alumno.nombre:="Luis A.";
find any Alumno using NombreA;
get Alumno:
print("Alumno.control");

Pueden existir varios registros con el valor especificado. La orden find localiza el
primero de ellos en un orden previamente especificado. Para localizar otros registros de
la base de datos que pudieran tener el mismo campo <campo de registro, utilizamos la
orden

find duplicate <tipo de registro> using <campo de registro>

Que localiza al siguiente registro (según un orden que depende del sistema) que tiene
el valor de <campo registro>.ejemplo:

Alumno.NombreA:="Luis A.";
 find any Alumno using NombreA;
while DB-Status = 0 do
begin
get Alumno;
print (Alumno.control);
find duplicate Alumno using NombreA;
end;

Se ha encerrado parte de la consulta en un ciclo while ya que no sabemos por

adelantado cuántos nombres Luis A. pueden existir. Salimos del bucle cuando DB-
Status<>0, esto indica que la última operación find duplicate falló, lo que implica que
ya hemos agotado todos los registros con esos datos.

Actualización en DBTG.

Creación de nuevos registros.

La orden para crear un nuevo registro es:

Store <tipo de registro>

Esta técnica nos permite crear y añadir solamente un registro a la vez.

Para ejemplificar consideremos el caso siguiente:

Deseamos registrar a un nuevo alumno de nombre "Delia J. Siordia", la instrucción

para esto es:

Alumno.NombreA:="Delia J. Siordia";
Alumno.control:="94310128";
Alumno.Esp:="LAE";
Store Alumno;

Modificación de un registro existente.

Para realizar la modificación a los registro primero se debe encontrar ese registro en
la base de datos, pasarlo a la memoria principal y efectuar las modificaciones deseadas,
posteriormente actualizamos el puntero de actualidad hacia el registro a modificar y
ejecutamos la orden Modify.

Modify <tipo de registro>

Para que el sistema se entere que se va a realizar una modificación se emplea la orden
for update.

Ejemplo: Deseamos cambiar la Especialidad del alumno de nombre Delia J. Siordia,

por LI.
 Alumno.NombreA:="Delia J. Siordia";
find for update any Alumno using nombreA;

get Alumno.Esp :="LI";

modify Alumno;

Las líneas de código antes descritas, primero requieren del dato por el cual se
realizará la búsqueda del registro, la orden find for update any establecen el tipo de
registro que se usara, using indica el campo por el cual debe buscar la coincidencia para
la modificación, get se antepone la línea de modificaciones que se realizaran sobre el
registro y finalmente ya que el registro fue modificado se ejecuta la instrucción modify
para activar las actualizaciones ejecutadas.

Eliminación de registros.

Para efectuar la eliminación de los registros es necesario tener el puntero de

actualidad apuntando al registro que deseamos borrar, después se ejecuta al orden:

erase <tipo de registro>

Esta instrucción al igual que la orden modify, requiere de la declaración de las

instrucciones for update en la orden find.

Ejemplo:Consideremos que deseamos eliminar el alumno cuyo número de control es

94310166 que pertenece al alumno Luis A.

Fin:=false;
Alumno.NombreA:="Luis A.";
find any Alumno using NombreA;
while DB-Status=0 and not fin do
begin
get Alumno;
if Alumno.control=94310166 then
begin
erase Alumno;
fin:=true;
end
else
find for update next alumno with Alren1(*Registro reenlace*)
end;

Es posible eliminar toda una secuencia de conjunto encontrando al dueño del mismo,
para ello se ejecuta la orden:

erase all <tipo de registro>

Esto borrara al dueño del conjunto y a todos sus miembros, si un miembro de un

conjunto dueño de otro conjunto, también se eliminaran los miembros de ese conjunto,
esta operación es recursiva.
 Ejemplo: Consideremos que deseamos borrar al Alumno de nombre Luis A. y todas sus
registros de materias, entonces:

Alumno.NombreA :="Luis A.";

find for update any Alumno using NombreA;
erase all Alumno;

Diagramas de estructura de datos.

Un diagrama de estructura de datos es un esquema que representa el diseño de una

base de datos de red. Este modelo se basa en representaciones entre registros por medio
de ligas, existen relaciones en las que participan solo dos entidades(binarias ) y
relaciones en las que participan más de dos entidades (generales) ya sea con o sin
atributo descriptivo en la relación.

La forma de diagramado consta de dos componentes básicos:

Celdas: representan a los campos del registro.

Líneas: representan a los enlaces entre los registros.

Un diagrama de estructura de datos de red, especifica la estructura lógica global de la

base de datos; su representación gráfica se basa en el acomodo de los campos de un
registro en un conjunto de celdas que se ligan con otro(s) registro(s), ejemplificaremos
esto de la siguiente manera:

Consideremos la relación alumno-cursa-materia donde la relación cursa no tiene

atributos descriptivos :

Las estructuras de datos según la cardinalidad se representan en los siguientes casos:

Cuando el enlace no tiene atributos descriptivos

Caso 1. Cardinalidad Uno a Uno.

Caso 2. Cardinalidad Muchos a uno.

Caso 3. Cardinalidad Muchos a muchos.

Cuando el enlace tiene atributos descriptivos.

Consideremos que a la relación cursa le agregamos el atributo Cal (calificación),

nuestro modelo E-R quedaría de la siguiente manera:

La forma de convertir a diagramas de estructura de datos consiste en realizar lo

siguiente:

1. Realizar la representación de los campos del registro agrupándolos

en sus celdas correspondientes.
2. Crear nuevo registro, denominado Calif, para este caso, con un
solo campo, el de cal (calif).
3. Crear los enlaces indicando la cardinalidad de :

AluCal, del registro Calif al registro Alumno.

MatCal, del registro Calif al registro Materia.

AluCal y MatCal son solo los nombres que emplearemos para

identificar el enlace, pueden ser otros y no son empleados para
otra cosa.

Los diagramas de estructuras de datos según la cardinalidad

se transforman en:

Caso 1. Cardinalidad uno a uno.

Caso 2. Cardinalidad Uno a muchos.

Caso 3. Cardinalidad Muchos a muchos.

Diagramas de estructura de datos cuando intervienen
más de dos entidades y el enlace no tiene atributos descriptivos.

Consideremos que a la relación alumno-cursa-materia le agregamos la entidad maestro,

quien es el que imparte dicha materia.

Nuestro diagrama E-R quedaría de la siguiente manera:

La transformación a diagramas de estructura de datos se realiza mediante los

siguientes pasos:

1.Crear los respectivos registros para cada una de las entidades que intervienen en el
modelo.

2. Crear un nuevo tipo de registro que llamaremos Renlace, que puede no tener campos
o tener solo uno que contenga un identificador único, el identificador lo proporcionará
el sistema y no lo utiliza directamente el programa de aplicación, a este registro se le
denomina también como registro ficticio o de enlace o unión.
Siguiendo los pasos anteriores nuestra estructura finalmente es: (Considerando una
relación con cardinalidad Uno a Uno)
 Ahora si nuestro enlace tuviera atributos descriptivos, se crea el registro con los
campos respectivos y se liga indicando el tipo de cardinalidad de que se trate.

En este caso tomamos el ejemplo anterior con cardinalidad uno a uno y le agregamos
a la relación el atributo calif. (calificación).

Considerando el anterior diagrama de estructura de datos, una instancia de este seria:

La estructura quedaría:

Este diagrama nos indica que los alumnos Luis A. Laura M. y Leticia L. cursaron la
materia Base de datos 2 con La maestra Ing. Lourdes A. Campoy M obteniendo una
calificación de 100,80,95 respectivamente.