Está en la página 1de 45

Universidad Tecnológica Nacional

Facultad Regional Resistencia

Diseño de Sistemas
Profesor: A.U.S. Gustavo Marcelo Torossi
Diseño del Modelo de Datos Universidad Tecnol ógica Nacional - F.R.R.

Tabla de Contenidos
TABLA DE CONTENIDOS ......................................................................................................................2

FUENTES BIBLIOGRÁFICAS ................................................................................................................3

UNIDAD 13: INTRODUCCIÓN AL DISEÑO DE DATOS ...................................................................4


13.1 OBJETIVOS DE DISEÑO DE ALMACENAMIENTOS...............................................................................4
13.2 CONCEPTOS BÁSICOS DE DATOS ......................................................................................................4
13.2.1 Realidad, datos y metadatos ....................................................................................................4
13.2.2 Revisión de la empresa y su sistema informático.....................................................................5
Movimientos de Actualización....................................................................................................................... 6
Datos primarios y datos secundarios .............................................................................................................. 7
13.3 ARCHIVOS CONVENCIONALES Y BASES DE DATOS...........................................................................8
13.3.1 Los archivos convencionales .................................................................................................10
13.3.2 Los Sistemas de Base de Datos ..............................................................................................12
Resumen ............................................................................................................................................14
Sistemas de Almacenamiento de Datos........................................................................................................ 14
Bases de Datos ............................................................................................................................................. 14
UNIDAD 14: ORGANIZACIÓN DE ARCHIVOS Y BASES DE DATOS..........................................15
14.1 ORGANIZACIÓN DE ARCHIVOS CONVENCIONALES ..........................................................................15
14.1.1 Tipos de archivos ...................................................................................................................15
14.1.2 Organizaciones de Archivos ..................................................................................................16
Organización Secuencial .............................................................................................................................. 16
Organización de Listas de Enlace ................................................................................................................ 17
Organización de Archivos Dispersos o Atomizados .................................................................................... 17
Organización Indexada................................................................................................................................. 18
Organización de Indices Secuenciales.......................................................................................................... 19
14.2 ORGANIZACIÓN DE SISTEMAS DE BASE DE DATOS ..........................................................................20
14.2.1 Abstracción de Datos .............................................................................................................20
14.2.2 Modelos De Datos..................................................................................................................22
Modelos lógicos basados en objetos ............................................................................................................ 22
Modelos lógicos basados en registros .......................................................................................................... 23
Modelos físicos de datos .............................................................................................................................. 24
14.2.3 Instancias y Esquemas ...........................................................................................................24
14.2.4 Independencia De Datos........................................................................................................24
UNIDAD 15: EL MODELO ENTIDAD-RELACIÓN (MER)..............................................................26
15.1 ENTIDADES Y CONJUNTOS DE ENTIDADES ......................................................................................26
15.2 RELACIONES Y CONJUNTOS DE RELACIONES ..................................................................................26
15.3 ATRIBUTOS .....................................................................................................................................27
15.4 RESTRICCIONES ..............................................................................................................................28
15.4.1 Cardinalidad en Atributos .....................................................................................................28
15.4.2 Cardinalidad en Relaciones...................................................................................................29
15.4.3 Dependencias.........................................................................................................................30
15.5 CLAVES...........................................................................................................................................30
15.6 DIAGRAMA ENTIDAD-RELACIÓN .....................................................................................................32
Representación de la cardinalidad................................................................................................................ 32
Indicación de Roles...................................................................................................................................... 34
Entidades Débiles......................................................................................................................................... 34
Relaciones no binarias ................................................................................................................................. 34
15.7 REDUCCIÓN DE UN DER A UN CONJUNTO DE TABLAS .....................................................................35
15.7.1. Representación de conjuntos de entidades fuertes................................................................36
15.7.2. Representación de conjuntos de entidades débiles ...............................................................36
15.7.2 Representación de conjuntos de relaciones ...........................................................................37
Relaciones ternarias ..................................................................................................................................... 37

Prof. A.U.S. Gustavo Torossi P ágina 2 de 45


Diseño del Modelo de Datos Universidad Tecnol ógica Nacional - F.R.R.

Relaciones de entidades débiles ................................................................................................................... 38


Casos especiales ........................................................................................................................................... 38
15.8 EXTENSIONES AL MER ...................................................................................................................39
15.8.1 Generalización .......................................................................................................................39
15.8.2 Agregación.............................................................................................................................40
UNIDAD 15 B: DISEÑO FÍSICO DE BASE DE DATOS ....................................................................41
INTRODUCCIÓN .......................................................................................................................................41
PASO 1: ESPECIFICAR UN ARCHIVO O TABLA FÍSICA PARA CADA CONJUNTO ENTIDADES/RELACIONES .....42
PASO 2: ESPECIFICAR IMPLEMENTACIÓN PARA CLAVES PRIMARIAS, CANDIDATAS, Y FORÁNEAS ...........42
PASO 3: ESPECIFICAR IMPLEMENTACIÓN DE DOMINIOS ...........................................................................42
PASO 4: ESPECIFICAR IMPLEMENTACIÓN DE OTRAS REGLAS DE INTEGRIDAD ..........................................42
PASO 5: ESPECIFICAR IMPLEMENTACIÓN DE VISTAS ................................................................................43
PASO 6: ESPECIFICAR IMPLEMENTACIÓN DE SEGURIDAD ........................................................................43
PASO 7: ESPECIFICAR INDICES ADICIONALES POR PERFORMANCE ..........................................................43
PASO 8: INTRODUCIR REDUNDANCIA CONTROLADA...............................................................................44
PASO 9: COMBINAR TABLAS BASES ........................................................................................................44
PASO 10: AJUSTAR EL DISEÑO DE LA BASE DE DATOS PARA ANTICIPAR CAMBIOS .................................45

Fuentes Bibliográficas
- Fundamentes de Bases de Datos. Henry F. Korth – Abraham Silberschatz
- Lógica de la Construcción de un Conjunto de Datos. Jaques Warnier.
- Apuntes de Modelamiento de Datos. Marcela Varas – Universidad de Concepción
(Chile)

Prof. A.U.S. Gustavo Torossi P ágina 3 de 45


Diseño del Modelo de Datos Universidad Tecnol ógica Nacional - F.R.R.

Unidad 13: Introducción al Diseño de Datos

13.1 Objetivos De Diseño De Almacenamientos


Algunas personas consideran el almacenamiento de los datos como la esencia del
sistema de información. El impacto de la estructura de datos sobre la estructura de
programa y la complejidad procedimental, hace que el diseño de datos tenga una gran
influencia en la calidad del software.
Independientemente de las técnicas de diseño usadas, los datos bien diseñados pueden
conducir a una mejor estructura de programa, a una modularidad efectiva y a una
complejidad procedimental reducida.
Los objetivos generales del diseño de la organización de almacenamientos son:
1) Disponibilidad de datos: Los datos deben estar disponibles para cuando el usuario
desee usarlos. Sólo se debe negar el acceso a datos reservados por razones legales.
2) Accesibilidad: deben ser fáciles de acceder por los usuarios. Si no se puede acceder
fácilmente, no serán utilizados (y eventualmente pueden ser “inventados”). No
deben reflejar las necesidades de un sector particular, o serán difíciles de acceder
para los otros.
3) Integridad de datos: Los datos deben ser precisos (cada valor almacenado debe
estar dentro de un rango aceptable respecto del valor real) y consistentes (no deben
reflejar realidades distintas ya en el tiempo (las Cuentas a Pagar no cierran contra las
Facturas Pendientes) como en los datos relacionados (un Gerente de Area no puede
ser un empleado de categoría mínima). El conjunto de datos debe representar
fielmente a la organización.
4) Almacenamiento eficiente.
5) Actualización y recuperación eficiente.
6) Recuperación dirigida de la información: la información obtenida de los datos
almacenados debe contar con un formato útil que facilite la administración, la
planeación, y el control o la toma de decisiones.

13.2 Conceptos Básicos De Datos

13.2.1 Realidad, datos y metadatos


Solamente el mundo real en sí puede ser mencionado como “la realidad”. Aquellos
datos que se obtienen de las personas, de lugares o de eventos de la realidad,
eventualmente serán almacenados en archivos o en bases de datos. Con el fin de
comprender la forma y la estructura de los datos, se requiere de información acerca de
los datos mismos. Aquella información descriptiva de la estructura y semántica los datos
se le denomina como metadato. En la figura 13.0 se plantea de manera esquemática, la
relación existente entre la realidad, los datos y los metadatos. Dentro del contexto de la
realidad se tienen entidades y atributos; dentro del contexto de los datos reales, se tienen
registros de eventos y datos de los eventos; dentro del contexto de los metadatos, hay
definiciones de registros y definiciones de los datos.

Prof. A.U.S. Gustavo Torossi P ágina 4 de 45


Diseño del Modelo de Datos Universidad Tecnol ógica Nacional - F.R.R.

Entidades Atributos
REALIDAD

Registro de Datos de
DATOS ocurrencias ocurrencias

METADATOS Definición de Definición de


registros los datos

FIGURA 13.0 Los metadatos contienen la descripción de lo que cada


dato aparenta.

13.2.2 Revisión de la empresa y su sistema informático


Los hombres encargados de dirigir deben tomar decisiones. Para ello deben tener
información. Se disponen de dos categorías de fuentes de información:
• la percepción directa del mundo que les rodea.
• la percepción indirecta por lectura de datos.

La empresa es considerada como un sistema compuesto de dos subsistemas en


interacción: el subsistema de decisión y el subsistema de operación o transformación
(T), que asegura las acciones de transformación operadas sobre las entradas, para
obtener las salidas a partir de medios humanos, materiales y financieros.

EMPRESA
Fuente de
Informaciones
D
A
A
B

Entradas Salidas
T

El subsistema de decisión (D) actua sobre el subsistema de transformación (T) por


medio de decisiones o de procedimientos (flecha B).
Las fuentes de informaciones, flecha A, constituyen las entradas del sistema de decisión.

Prof. A.U.S. Gustavo Torossi P ágina 5 de 45


Diseño del Modelo de Datos Universidad Tecnol ógica Nacional - F.R.R.

Los datos provienen del exterior de la empresa o del interior (datos sobre el estado del
sistema y resultados de decisiones anteriores).

Movimientos de Actualización
Proponemos ahora un esquema más completo donde figura el sistema de información de
la empresa.

Otras fuentes de
informaciones EMPRESA
externas
Sistema ME
Datos Informático
Externos DS
D
A
B
Entradas Salidas

En el esquema anterior se destaca la introducción del sistema informático. Los datos de


entrada de este sistema, llamados movimientos externos, son seleccionados por decisión.
Están indicados por la flecha ME.

La acción del sistema de información tiene como efecto proveer al sistema de decisión
de los datos que reclame, en el momento, forma y lugar deseados (flecha DS).

A continuación podemos presentar el esquema del sistema informático, la estructura de


este sistema es análoga a la de la empresa.

SISTEMA
INFORMÁTICO
DATOS
D
M
P

ME DS

Prof. A.U.S. Gustavo Torossi P ágina 6 de 45


Diseño del Modelo de Datos Universidad Tecnol ógica Nacional - F.R.R.

Los datos comprenden los datos pasivos, es decir, los datos a tratar para obtener las
salidas, y los datos tratantes o programas.

La actuación de los programas provoca la transformación de los datos tratados (flecha


P).

Los movimientos externos son captados (ME), controlados, y dirigidos hacia las bases
de datos a fin de ponerlas al día. Lo más frecuente es que sea necesario emplear datos
(D) para efectuar los controles y la puesta al día.

La flecha M (movimientos) indica la entrada de los datos nuevos en las bases.


Estos nuevos datos pueden tener dos orígenes:

• a partir de los movimientos externos (ME), se pone al día el conjunto de datos,


• a partir de los datos (D) se efectúan cálculos, se obtienen movimientos internos, que
son utilizados así mismo para la puesta al día.

Los datos de salida DS, destinados a los usuarios, son obtenidos exclusivamente a partir
de los datos de la empresa.

En resumen, se llama movimientos a los datos destinados a redefinir las bases. Se


distinguen dos categorías de movimientos:

• los movimientos externos que provienen del exterior del sistema


• los movimientos internos que son calculados a partir de los datos de la empresa.

Datos primarios y datos secundarios


Los datos puestos al día por movimientos externos toman el nombre de datos
primarios. Los datos puestos al día por movimientos internos se llaman datos
secundarios.

Dato Primario: Un dato primario es un dato obtenido y actualizado a partir de


movimientos externos.

Dato Secundario: Un dato secundario es un dato obtenido y actualizado a partir de


movimientos internos.

Teóricamente los datos secundarios son inútiles y todas las salidas solicitadas pueden
ser obtenidas a partir de los datos primarios. En consecuencia, es esencial salvaguardar
prioritariamente todos los datos primarios.

En la práctica, es indispensable crear datos secundarios con el fin de optimizar y de


repartir la ejecución de los tratamientos.

Prof. A.U.S. Gustavo Torossi P ágina 7 de 45


Diseño del Modelo de Datos Universidad Tecnol ógica Nacional - F.R.R.

Si un conjunto de datos secundarios se ha destruido, siempre es posible reconstruirlo


cuando se ha conservado los datos primarios.

Las observaciones que acabamos de hacer, nos muestran que existe dos categorías de
tratamientos:

• las puestas al día de los conjuntos de datos de la empresa.


• la obtención de los datos de salida.

En resumen, los datos de las bases constituyen los resultados de los tratamientos de
puestas al día y las entradas de los tratamientos de obtención de salidas solicitadas por el
usuario.
La definición de las salidas solicitadas y de los movimientos de entrada del sistema
informático, es una labor esencial, realizada durante la etapa de análisis.

13.3 Archivos Convencionales y Bases de Datos


En un sistema de información basado en computadora se cuenta con dos enfoques para
el almacenamiento de los datos. El primer método consiste en almacenar los datos en
archivos individuales, exclusivos para una aplicación en particular. La figura 13.1 ilustra
una organización con diversos sistemas de información que utilizan archivos
convencionales independientes. Existen tres archivos individuales ARCHIVO-
VENTAS, el cual contiene la información de los datos históricos, ACTIVIDADES-
ACTUALES, las cuales se actualizan con frecuencia y ARCHIVO-PERSONAL, que
contiene las direcciones, los títulos y datos similares. Observe que NUM y NOMBRE
existen en ambos archivos. Además del esfuerzo adicional requerido para introducir el
NOMBRE hasta tres veces, el cambio de nombre (por ejemplo, por un cambio en el
estado civil) requeriría de la actualización de tres archivos individuales.

ARCHIVO-VENTAS ACTIVIDAD-ACTUAL
NUM. NOMBRE 86 87 88 NUM. NOMBRE AREA 88

ARCHIVO-PERSONAL
NUM. DEPTO. NOMBRE DIRECCION TELEF. CONT. SALARIO TIT

FIGURA 13.1 El uso de archivos separados con frecuencia implica que los mismos datos
se almacenen en más de un lugar

El segundo enfoque para el almacenamiento de datos en un sistema basado en


computadora, involucra la elaboración de una base de datos. Una base de datos es un
almacenamiento de datos formalmente definido, controlado centralmente para intentar

Prof. A.U.S. Gustavo Torossi P ágina 8 de 45


Diseño del Modelo de Datos Universidad Tecnol ógica Nacional - F.R.R.

servir a múltiples y diferentes aplicaciones. La figura 13.2 muestra cómo los diferente
usuarios de distintos departamentos dentro de una organización comparten la misma
base de datos. Un usuario puede seleccionar una parte de la base de datos, como se
muestra en el conjunto de datos uno, o ciertos renglones en el conjunto de datos dos. El
conjunto de datos tres contiene columnas selectas y el conjunto de datos cuatro utiliza
ciertos renglones para calcular los totales. Estos conjuntos de datos se superponen
indicando que si existieran datos que fueran redundantes en archivos convencionales,
solamente se almacenarían una sola vez en la base de datos.

Grupo de Datos 1

Base de Datos

Grupo de Datos 2

Grupo de Datos 3

FIGURA 13.2 El enfoque de base de datos permite que diferentes usuarios compartan
la misma base de datos, teniendo acceso a diferentes grupos de datos.

Prof. A.U.S. Gustavo Torossi P ágina 9 de 45


Diseño del Modelo de Datos Universidad Tecnol ógica Nacional - F.R.R.

13.3.1 Los archivos convencionales


Los archivos convencionales, sin duda alguna, permanecen como una manera práctica
de almacenar los datos de ciertas aplicaciones. Un archivo convencional se puede
diseñar y elaborar de manera rápida, reduciendo los problemas de disponibilidad de
datos y de seguridad. Cuando el diseño de los archivos se realiza de manera cuidadosa,
toda la información necesaria queda incluida y se reduce el riesgo de omitir datos de
manera accidental.
En muy raras ocasiones, un analista se enfrentará a una situación en la cual no existan
aplicaciones. Existe la probabilidad de que se encuentren actualmente en servicio
archivos separados. Si el tiempo de desarrollo es una consideración importante, el
analista de sistemas no puede involucrarse en el problema de rehacer el almacenamiento
de los datos, sólo con el fin de lograr un enfoque de base de datos. La solución obvia en
función de las restricciones de tiempo consiste en limitar el alcance del proyecto,
diseñando otro archivo separado para la nueva aplicación.
La velocidad de procesamiento es otra ventaja para el uso de archivos. Hay posibilidad
de elegir una técnica óptima para el procesamiento de los archivos de una sencilla
aplicación, pero llega a ser imposible alcanzar un diseño óptimo para tareas muy
variadas. En consecuencia, si el analista de sistemas se enfrenta al diseño de un sistema
para una aplicación específica, cuando la eficiencia del procesamiento es de gran
relevancia, el mejor enfoque puede ser el diseño de un archivo individual para tal
propósito.

El uso de archivos individuales tiene diversas consecuencias. Veamos el siguiente


ejemplo para ilustralo:
Considérese parte de una empresa bancaria de ahorros que guarda la información sobre
todos los clientes y sus cuentas de ahorro. El sistema tiene diversos programas de
aplicación que permiten al usuario manejar los archivos, incluyendo:

- Un programa para hacer cargos o abonos a una cuenta.


- Un programa para añadir una nueva cuenta.
- Un programa para obtener el saldo de un cuenta.
- Un programa para generar estados mensuales.

Estos programas de aplicación los han escrito programadores de sistemas en respuesta a


las necesidades de la organización bancaria. Según surge la necesidad, se añaden nuevos
programas de aplicación al sistema. Por ejemplo, supóngase que una nueva ley del
Gobierno permite al banco de ahorros ofrecer cuentas de cheques. Como resultado, se
crean nuevos archivos permanentes que contienen información acerca de todas las
cuentas de cheques que mantiene el banco, y puede que sea necesario escribir nuevos
programas de aplicación. Así, según pasa el tiempo, se añaden más archivos y
programas de aplicación al sistema.
El típico sistema de procesamiento de archivos descrito arriba está apoyado por un
sistema operativo convencional. Los registros permanentes se almacenan en varios
archivos, y se escribe un número de diferentes programas de aplicación para extraer
registros de y añadir registros a archivos apropiados. Este enfoque tiene un número de
desventajas importante:

• Falta de potencial para evolucionar: con frecuencia, los archivos se diseñan con
base en las necesidades inmediatas. Cuando llega a ser importante la consulta del

Prof. A.U.S. Gustavo Torossi P ágina 10 de 45


Diseño del Modelo de Datos Universidad Tecnol ógica Nacional - F.R.R.

sistema mediante una combinación de ciertos atributos, tales atributos pudieran


encontrarse en archivos separados, o simplemente no existir. El rediseño de
archivos, implica a menudo que los programas que los accesan, deban escribirse
nuevamente de manera acorde. Esto implica un incremento en el tiempo de
programación para el archivo, para el desarrollo y mantenimiento de programas.

• Redundancia e inconsistencia de los datos. Puesto que los archivos y los


programas de aplicación son creados por distintos programadores durante un periodo
largo de tiempo, es probable que los archivos tengan diferentes formatos y los datos
pueden estar duplicados en varios sitios (archivos). Por ejemplo, la dirección y el
número de teléfono de un cliente determinado pueden aparecer en un archivo que
consta de registros de cuentas de ahorros y en un archivo que consta de registros de
cuentas de cheques. Esta redundancia aumenta los costes de almacenamiento y
acceso. Además, puede llevar a inconsistencias de los datos – esto es, las diversas
copias de los mismos datos no concuerdan entre sí. Por ejemplo, una dirección
cambiada de un cliente puede estar reflejada en los registros de cuentas de ahorros
pero en ningún sitio más del sistema. Resultados de inconsistencia de los datos.

• Dificultad para tener acceso a los datos. Supóngase que uno de los gerentes del
banco necesita averiguar los hombres de todos los clientes que viven dentro del
código postal de la ciudad 78733. El gerente pide al departamento de procesamiento
de datos que genere la lista correspondiente. Puesta que esta solicitud no fue prevista
cuando se diseño el sistema original, no hay ningún programa de aplicación a mano
que la satisfaga. Existe, sin embargo, un programa de aplicación para generar la lista
de todos los clientes. El gerente tiene ahora dos elecciones: O bien tomar la lista de
clientes y extraer la información necesaria manualmente, o pedir al departamento de
procesamiento de datos que ponga a un programador de aplicaciones a escribir el
programa de aplicación necesario. Obviamente, ninguna de las dos alternativas es
satisfactoria. Supóngase que se escribe un programa semejante y que, varios días
después, el mismo gerente necesita arreglar esa lista para incluir solo aquellos
clientes con un saldo de 10000 dólares o más. Como se esperaba, no existe un
programa que genere esa lista. De nuevo, el gerente tiene las dos opciones
anteriores, ninguna de las cuales es satisfactoria. Lo que se trata de probar aquí es
que esos entornos convencionales de procesamiento de archivos no permiten
recuperar los datos necesarios de una forma conveniente y eficiente, Deben
desarrollarse sistemas de recuperación de datos para uso general.

• Aislamiento de los datos: Puesto que los datos están repartidos en varios archivos,
y éstos pueden tener diferentes formatos, es difícil escribir nuevos programas de
aplicación para obtener los datos apropiados.

• 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. Considérese una cuenta bancaria A, con 500 dólares. Si dos clientes
retiran fondos (digamos 50 y 100 dólares, respectivamente) de la cuenta A casi al
mismo tiempo, el resultado de las ejecuciones concurrentes puede dejar la cuenta en

Prof. A.U.S. Gustavo Torossi P ágina 11 de 45


Diseño del Modelo de Datos Universidad Tecnol ógica Nacional - F.R.R.

un estado incorrecto (o inconsistente). En particular, la cuenta puede contener 450 o


400 dólares, en vez de 350 dólares Para prevenir esta posibilidad, debe mantenerse
alguna forma de supervisión en el sistema. Puesto que se puede acceder a tos datos
por medio de diversos programas de aplicación diferentes que no han sido
previamente coordinados, esta supervisión es muy difícil de proporcionar.

• Problemas de seguridad: No todos los usuarios del sistema de base de datos deben
poder acceder a todos los datos. Por ejemplo, en un sistema bancario, el personal de
las nóminas solo necesita ver la parte de la base de datos que tiene información
acerca de los distintos empleados del banco. No necesitan acceder a información
sobre las cuentas de los clientes. Puesto que los programas de aplicación se añaden
al sistema de una forma precisa, es difícil implantar tales restricciones de seguridad.

• Problemas de integridad: la integración de los datos llega a convertirse en una


causa de preocupación, ya que los cambios en un archivo, requerirán también la
modificación de ciertos datos en otros archivos. Aquellos archivos utilizados
esporádicamente bien pueden quedar ignorados durante la fase de la actualización.
Por otra parte, los valores de datos almacenados en la base de datos deben satisfacer
ciertos tipos de restricciones de consistencia. Por ejemplo, el saldo de una cuenta
bancaria nunca debe caer por debajo de una cantidad prescrita (digamos, 25 dólares).
Estas restricciones se hacen cumplir en el sistema añadiendo códigos apropiados en
los diversos programas de aplicación. Sin embargo, cuando se añaden restricciones
nuevas, es difícil cambiar los programas para hacerlos cumplir. El problema se
complica aún más cuando las restricciones implican varios elementos de
información de distintos archivos.

Estas dificultades, entre otras, han fomentado el desarrollo de sistemas de gestión de


bases de datos.

13.3.2 Los Sistemas de Base de Datos


Las bases de datos no son meramente una colección de archivos. Más bien, una base de
datos es una fuente central de datos significativos, los cuales son compartidos por
numerosos usuarios para diversas aplicaciones. La esencia de una base de datos es el
Sistema Administrador de la Base de Datos (DBMS: Database Management System), el
cual permite la creación, modificación y actualización de la base de datos, la
recuperación de los datos y la emisión de reportes. A la persona responsable de asegurar
que la base de datos satisfaga los objetivos programados se le denomina administrador
de la base de datos. Los objetivos de eficiencia de la base de datos son:

1) Asegurar que los datos puedan ser compartidos por los usuarios, para una variedad
de aplicaciones.

2) Que el mantenimiento de los datos sea preciso y consistente.

3) Asegurar que todos los datos requeridos para las aplicaciones presentes y futuras se
encuentren siempre disponibles.

Prof. A.U.S. Gustavo Torossi P ágina 12 de 45


Diseño del Modelo de Datos Universidad Tecnol ógica Nacional - F.R.R.

4) Permitir que la base de datos evolucione y se adapte a las necesidades crecientes de


los usuarios.

5) Permitir que los usuarios desarrollen su propia visión de los datos, sin preocuparse
por la manera en que los datos se encuentren almacenados físicamente.

La anterior lista de objetivos nos advierte las ventajas y desventajas del enfoque de la
base de datos. Primero, al compartir los datos, significa que éstos deben almacenarse por
lo menos una sola vez. Esto a su vez apoya que se mantenga la integridad de los datos,
ya que el cambio de los datos se realizará de manera más sencilla y confiable si éstos
aparecen una vez y no en varios archivos. Cuando un usuario necesite un dato particular,
una base de datos con un buen diseño se debería anticipar tal necesidad (y quizás ya
hayan sido utilizados en otra aplicación). En consecuencia, los datos tendrán mayor
probabilidad de encontrarse disponibles en una base de datos más que en un sistema de
archivos convencionales. Una base de datos con un buen diseño también llega a ser más
flexible que dos archivos separados, esto significa que una base de datos llega a
evolucionar conforme se modifican las necesidades de los usuarios y de sus
aplicaciones. Finalmente, el enfoque de base de datos, tiene la ventaja de permitir que
los usuarios expongan sus puntos de vista sobre los datos, sin necesidad de preocuparse
de la estructura presente de la base de datos o de su ubicación física.
La primera desventaja del enfoque de base de datos es que todos los datos se almacenan
en un solo lugar; y en consecuencia, los datos son más vulnerables a accidentes y
requerirán de un respaldo completo. Esto en la actualidad ha sido mejorado con técnicas
avanzadas de bases de datos (Bases de datos replicadas y distribuidas). Existe el riesgo
de que quien administra la base de datos se convierta en el único privilegiado o
habilitado para estar cerca de los datos. Y los procedimientos burocráticos requeridos
para modificar o para actualizar la base de datos pueden llegar a ser insuperables. Otras
desventajas para la administración de los datos como recurso se presenta al intentar
satisfacer dos objetivos de eficiencia:

1) Reducción del tiempo requerido para insertar, actualizar, eliminar y recuperar los
datos en tiempos tolerables.

2) Mantenimiento del costo del almacenamiento de datos en una cantidad razonable.

Es necesario recordar que una base de datos no puede optimizar la recuperación de los
datos para una aplicación en especial, ya que deberá compartirse con numerosos
usuarios y con varias aplicaciones. Además, se puede llegar a requerir de cierto software
adicional para la DBMS y, ocasionalmente, también se necesitará una computadora de
mayor capacidad. El enfoque de la base de datos es un concepto que se vuelve cada vez
más relevante. El uso de base de datos de relacionales mediante microcomputadoras
indica el grado de difusión que este concepto ha alcanzado entre los usuarios. Con este
enfoque, los usuarios toman una parte de la base de datos central y cargan sus
computadoras personales. Luego estas pequeñas bases de datos se utilizan para emitir
reportes o contestar consultas específicas del usuario final.

Prof. A.U.S. Gustavo Torossi P ágina 13 de 45


Diseño del Modelo de Datos Universidad Tecnol ógica Nacional - F.R.R.

Resumen
Sistemas de Almacenamiento de Datos

Archivos Convencionales
Inconvenientes
Falta de potencial para evolucionar
Redundancia e inconsistencia de datos
Dificultades de Acceso
Problemas de Concurrencia
Aislamiento de los datos
Seguridad
Integridad
Casos en que conviene
Aplicaciones ya existentes
Cuestiones de Performance
Bases de Datos
Objetivos
Compartir información
Múltiples usuarios
Múltiples aplicaciones
Mantenimiento de datos preciso y consistente
Disponibilidad de los datos
Flexibilidad para evolucionar según las necesidades
Independencia del almacenamiento físico
Inconvenientes
Almacenamiento centralizado (tradicionalmente)
Dependencia burocrática del DBA
Tiempo de actualización
No se optimiza el acceso para una aplicación especial

Prof. A.U.S. Gustavo Torossi P ágina 14 de 45


Diseño del Modelo de Datos Universidad Tecnol ógica Nacional - F.R.R.

Unidad 14: Organización de Archivos y Bases de


Datos

14.1 Organización de Archivos Convencionales


Un archivo contiene grupos de registros que se utilizan para proporcionar información
para operaciones, planeación, administración y tomas de decisiones. Se discutirán
primero los tipos utilizados de archivos, seguido de la descripción de cómo organizar
los archivos convencionales.

14.1.1 Tipos de archivos


Los archivos pueden utilizarse para almacenar datos por un período indefinido de
tiempo o bien, pueden utilizarse como almacenes temporales para un propósito
particular. Los archivos maestros y los archivos de tablas se utilizan para almacenar
datos para periodos más largos. Generalmente, los archivos temporales pueden ser
archivos de transacción, archivos de trabajo, o archivos de impresión.

Archivos maestros: Los archivos maestros contienen registros para un grupo de


entidades. Los atributos pueden actualizarse frecuentemente, pero los registros en sí, se
mantienen permanentes. Dentro de los ejemplos de archivos maestros tenemos al
registro de pacientes, un archivo personal o un archivo de refacciones en inventario.

Archivos de tablas: Un archivo de tablas contiene datos que se utilizan para calcular
otros datos o más parámetros de desempeño. Un ejemplo es una tabla de las tarifas
postales que determinan el costo del envío de un paquete. Otro ejemplo es una tabla de
impuestos. Los archivos de tablas generalmente se leen exclusivamente por un
programa.
Existe otro tipo de archivos de tablas, llamadas comúnmente tablas de búsqueda, que
contienen datos relativos a campos codificados, comúnmente una descripción. Ejemplo
de esto puede ser una tabla de localidades, tabla de calles, tabla de tipos de usuario, etc.

Archivos de transacción: Un archivo de transacciones se utiliza al introducir cambios


para la actualización del archivo maestro. Suponga que un archivo maestro de los
suscriptores de un periódico requiere actualizarse; el archivo de transacción contendría
el número del suscriptor y el código de la transacción, tal como una E para extender la
suscripción, C para cancelar la suscripción y una D para cambio de dirección. De tal
forma, que sólo se introduce la información relevante que se necesita para la
actualización; esto es, la duración de la renovación si fuera E, la dirección si fuera D,
etc. Si la suscripción se cancela no se proporciona información adicional. El resto de la
información, de hecho, ya existe en el archivo maestro. Una vez que se actualiza un
archivo maestro, puede descartarse el archivo de transacción.
Otro ejemplo son los archivos de pagos grabados en cajas descentralizadas, los cuales se
reenvían a un centro de cómputos para realizar la imputación de dichos pagos a las
deudas correspondientes de los clientes.

Prof. A.U.S. Gustavo Torossi P ágina 15 de 45


Diseño del Modelo de Datos Universidad Tecnol ógica Nacional - F.R.R.

Archivos de trabajo: En ocasiones, un programa puede correr eficientemente si utiliza


un archivo de trabajo. Un ejemplo común de un archivo de trabajo es aquel que reordena
de forma particular a los registros con el fin de accesarlos de manera más rápida.

Archivos para impresión: Cuando es necesario correr un programa, pero se carece de


una impresora en línea (o la impresora se encuentra ocupada imprimiendo otros
reportes), se utiliza un archivo de impresión. El envío de la salida a un archivo, en lugar
de una impresora se le llama ”spooling”. Luego, cuando el periférico se encuentra
disponible, el documento puede imprimirse. Los archivos de impresión son muy útiles
porque los usuarios pueden tomarlos para llevarlos a otros sistemas de cómputo e
imprimirlos en dispositivos especiales, tales como graficadores, impresoras láser,
unidades de microfilmación y máquinas computarizadas de edición.

14.1.2 Organizaciones de Archivos

Organización Secuencial
Cuando los registros se encuentran ordenados físicamente en un archivo, se dice que tal
archivo es un archivo secuencial. Cuando se actualiza un archivo de este tipo, es
necesario accesarlo de manera completa. Ya que los registros no pueden insertarse en la
parte intermedia del archivo, un archivo secuencial generalmente se copia durante el
proceso de la actualización. La figura 14.1 ilustra un archivo de órdenes de compra para
una compañía de ventas por correo que ofrece discos compactos y álbumes de discos. El
archivo contiene doce registros y se almacena de manera secuencial con base en el
#ORDEN . Si deseamos acceder al registro 13432, comenzaríamos desde el principio y
leeríamos todo el archivo hasta llegar a la orden 13432. Los archivos secuenciales se
utilizan cuando lo requiere el hardware (recuerde que una cinta magnética es un
dispositivo secuencial) o cuando el acceso normal requiere que se accese la mayoría de
los registros. En otras palabras, cuando necesitemos leer o actualizar sólo unos cuantos
registros, será ineficiente utilizar un archivo secuencial, pero cuando se necesiten leer o
modificar numerosos registros, tendría mayor sentido una organización secuencial.

#ORDEN APELLIDO I DOMICILIO CIUDAD EDO TARJETA-CRED.


1 10784 MacRae G 2314 Curly Circle Lincoln NE 45-4654-76
2 10796 Jones S 34 Dream Lane Oklahoma OK 45-9876-74
3 11821 Preston R 1008 Madison Av. River IA 34-7642-64
4 11845 Channing C 454 Harmonia St. New York NY 34-0876-87
5 11872 Kiley R 765 Dulcinea St. La Mancha CA 65-8798-87
6 11976 Verdon G 7564 K. Street Chicago IL 67-8453-18
7 11998 Rivera C 4342 West Street Chicago IL 12-2312-54
8 12765 Orbach J 1345 Michigan Av Chicago IL 23-4545-65
9 12769 Steele T 3498 Burton Lane Finnian NJ 65-7687-09
10 12965 Crawford M 1986 Barnum Cir London NH 23-0098-23
11 13432 Cullum J 354 River road Shenandoa VT 45-8734-33
12 13542 Mostel Z 65 Fiddler St. Anatevka ND 34-6723-98

FIGURA 14.1 Archivo ordenado por el #ORDEN.

Prof. A.U.S. Gustavo Torossi P ágina 16 de 45


Diseño del Modelo de Datos Universidad Tecnol ógica Nacional - F.R.R.

Organización de Listas de Enlace


Cuando los archivos se almacenan en dispositivos de acceso directo, tales como un
disco flexible o uno fijo, las opciones son mayores. Los registros pueden ordenarse de
manera lógica, en lugar de física, utilizando listas de enlace. Las listas de enlace se
consultan para utilizar un conjunto de apuntadores que dirigen al siguiente registro
lógico localizado en cualquier parte en el archivo. La figura 14.2 muestra el archivo de
las órdenes de discos compactos con un atributo adicional utilizado para almacenar el
apuntador. Ya que el archivo se encuentra almacenado en un orden consecutivo con
base en el #ORDEN el señalador se utiliza para indicar el orden lógico (alfabético) de
los registros por APELLIDO. Este ejemplo muestra una ventaja obvia al utilizar listas
de enlace. Los archivos pueden ordenarse de manera lógica de múltiples formas, al
utilizar una variedad de apuntadores.

INICIO = 4

#ORDEN APELLIDO I DOMICILIO CIUDAD EDO TARJ-CRED APUNT


1 10784 MacRae G 2314 Curly Circle Lincoln NE 45-4654- 12
76
2 10796 Jones S 34 Dream Lane Oklahoma OK 45-9876- 5
74
3 11821 Preston R 1008 Madison Av. River IA 34-7642- 7
64
4 11845 Channing C 454 Harmonia St. New York NY 34-0876- 10
87
5 11872 Kiley R 765 Dulcinea St. La Mancha CA 65-8798- 1
87
6 11976 Verdon G 7564 K. Street Chicago IL 67-8453- END
18
7 11998 Rivera C 4342 West Street Chicago IL 12-2312- 9
54
8 FIGURA
12765 14.2 J que
Lista enlazada
Orbach 1345 Michigan
utiliza Av Chicago
apuntadores IL
para designar 23-4545- 3
el orden lógico
de los registros. (ordenado por nombre) 65
9 12769 Steele T 3498 Burton Lane Finnian NJ 65-7687- 6
09
10 12965 Crawford M 1986 Barnum Cir London NH 23-0098- 11
23
11 13432 Cullum J 354 River road Shenandoa VT 45-8734- 2
Organización de Archivos Dispersos o Atomizados 33
Los 12 13542 de
dispositivos Mostel
acceso directoZ también
65 Fiddler St.
permiten el Anatevka
acceso a un ND 34-6723-
registro 8
determinado
98
al dirigirnos a su dirección. Ya que no es factible reservar una dirección física para cada
registro posible, se utiliza un método denominado disperso o atomizado. La dispersión
es el proceso de cálculo de una dirección para un registro llave. Suponga que hubiera
500 empleados en una organización y deseáramos utilizar como criterio el número del
Seguro Social. No sería eficiente observar 999,999,999 direcciones, donde cada una
corresponde a un Número del Seguro Social. En consecuencia, tomaríamos el Número
del Seguro Social y lo utilizaríamos para derivar la ubicación del registro. Existen
muchas técnicas de dispersión. Una común es dividir el número original entre un
número primo que se aproxime a los sitios de almacenamiento y luego utilizar el resto
como dirección. Como podemos ver a continuación: comience con el Número del
Seguro Social 053-4689-42, luego divida entre 509 para obtener 105047. Observe que
105047 al multiplicarlo por 509 no es igual al número original, sino igual a 53468942 la
diferencia entre el número original 53468942 y 53468923 es el residuo, el cual es de 19.

Prof. A.U.S. Gustavo Torossi P ágina 17 de 45


Diseño del Modelo de Datos Universidad Tecnol ógica Nacional - F.R.R.

La ubicación del sitio de registro de un empleado cuyo Número del Seguro Social es
053-4689-42 sería entonces 19. Sin embargo, se presenta un problema cuando una
persona con un número diferente del Seguro Social (digamos, 472-3840-SC) tiene el
mismo residuo. Cuando esto ocurre, el registro de la segunda persona tiene que ubicarse
en un área de sobreflujo.

Organización Indexada
Un índice es diferente a un apuntador, en el sentido de que se almacena en un archivo
independiente del archivo de datos. La figura 14.3 muestra cuatro archivos de índices
separados y generados sobre el ARCHIVO ORDENES para discos compactos.
Los numerosos archivos índice tienen aplicaciones prácticas. Si deseamos listar los
detalles del pedido de ”Cullum”, podremos observar a ”Cullum” en el archivo INDICE
APELLIDO e ir directamente al registro once. El INDICE CIUDAD puede utilizarse
para una lista de correo, el INDICE STATUS puede utilizarse para escribir avisos a
personas con artículos devueltos y así sucesivamente. Cuando se incrementa el número
de archivos índice, es posible utilizar archivos índice para almacenar muchos de los

Indice por Apellido Indice por Ciudad Indice por Tarj-Crédito


Channing 4 Anatevka 12 12-2312-54 7
Crawford 10 Chicago 6 7 8 23-0098-23 10
Cullum 11 Finnian 9 23-4545-65 8
Jones 2 La Mancha 5 34-0876-87 4
Kiley 5
MacRae 1 Lincoln 1 34-6723-98 12
London 10 34-7642-64 3
Mostel 12
Orbach 8 New York 4 45-4654-76 1
Preston 3 Oklahoma 2 45-8734-33 11
Rivera 7 River 3 45-9876-74 2
Steele 9 Shenandoah 11 65-7687-09 9
Verdon 6 65-8798-87 5
67-8453-18 6

ARCHIVO DE ORDENES
#ORDEN APELLIDO I DOMICILIO CIUDAD EDO TARJ-CRED APUNT
1 10784 MacRae G 2314 Curly Circle Lincoln NE
45-4654- 12
76
2 10796 Jones S 34 Dream Lane Oklahoma OK 45-9876- 5
74
3 11821 Preston R 1008 Madison Av. River IA 34-7642- 7
64
4 11845 Channing C 454 Harmonia St. New York NY 34-0876- 10
87
5 11872 Kiley R 765 Dulcinea St. La Mancha CA 65-8798- 1
87
6 11976 Verdon G 7564 K. Street Chicago IL 67-8453- END
18
7 11998 Rivera C 4342 West Street Chicago IL 12-2312- 9
54
8 12765 Orbach J 1345 Michigan Av Chicago IL 23-4545- 3
FIGURA 14.3 Las listas invertidas pueden tener varios índices. 65
9 12769 Steele T 3498 Burton Lane Finnian NJ 65-7687- 6
datos. La cantidad de información en los archivos índice puede llegar 09 a ser bastante
10 12965
grande. En este Crawford M 1986
caso, a la estructura se leBarnum
denominaCir lista
London NHLas23-0098-
invertida. 11
listas invertidas
23
son11 más apropiadas
13432 Cullum cuando J se 354 utilizan para localizar
River road
información
Shenandoa VT
sobre 2 una
45-8734-
33
12 13542 Mostel Z 65 Fiddler St. Anatevka ND 34-6723- 8
98
Prof. A.U.S. Gustavo Torossi P ágina 18 de 45
Diseño del Modelo de Datos Universidad Tecnol ógica Nacional - F.R.R.

combinación específica de criterios. Por ejemplo, una consulta sobre ”Quién tiene un
pedido devuelto en Chicago” sería contestada de manera muy eficiente. Sin embargo, las
listas invertidas son difíciles de mantener, ya que las listas invertidas son apropiadas
para archivos que no tienen actualización muy frecuente.

Organización de Indices Secuenciales


Un método ampliamente utilizado para la organización de archivos es el denominado
organización de índices secuenciales, o método de acceso secuencial indexado (ISAM;
indexed secuential access method). En un archivo ISAM, los registros se ordenan en
bloque. Los registros dentro de los bloques se almacenan en un orden físico, pero los
bloques o registros pueden presentarse en cualquier orden. Además, se necesita un
índice para localizar el bloque de registro.

Prof. A.U.S. Gustavo Torossi P ágina 19 de 45


Diseño del Modelo de Datos Universidad Tecnol ógica Nacional - F.R.R.

14.2 Organización de Sistemas de Base de Datos


Una base de datos, a diferencia de un archivo, la comparten muchos usuarios. Y
naturalmente cada usuario verá los datos de manera diferente. Nos referimos a la forma
en que un usuario concibe y describe los datos desde una presentación de usuario. Sin
embargo, el problema es que usuarios diferentes tienen enfoques diferentes. Estas
presentaciones se examinan en el modelo lógico global de la base de datos, que
eventualmente deberá desarrollarse. Finalmente, el modelo lógico de la base de datos
debe transformarse en el correspondiente diseño físico de la base de datos. El diseño
físico considera la forma del almacenamiento de los datos y de sus interrelaciones, así
como la mecánica del acceso.

Un sistema de gestión de base de datos (DBMS) consiste en una colección de datos


interrelacionados y un conjunto de programas para acceder a esos datos. La colección de
datos, normalmente denominada base de datos, contiene información acerca de una
empresa determinada. El objetivo primordial de un DBMS es proporcionar un entorno
que sea a la vez conveniente y eficiente para ser utilizado al extraer y almacenar
información de la base de datos.
Los sistemas de bases de datos están diseñados para gestionar grandes bloques de
información. La gestión de datos implica tanto la definición de estructuras para el
almacenamiento de información como la provisión de mecanismos para la gestión de la
información. Además, los sistemas de bases de datos deben mantener la seguridad de la
información almacenada, pese a caídas del sistema o intentos de accesos no autorizados.
Si los datos van a ser compartidos por varios usuarios, el sistema debe evitar posibles
resultados anómalos.
La importancia de la información en la mayoría de las organizaciones, y por tanto el
valor de la base de datos, ha llevado al desarrollo de una gran cantidad de conceptos y
técnicas para la gestión eficiente de los datos. En este capitulo presentamos una breve
introducción a los principios de los sistemas de bases de datos.

14.2.1 Abstracción de Datos


Un objetivo importante de un sistema de bases de datos es proporcionar a los usuarios
una visión abstracta de los datos. Es decir, el sistema esconde 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. Este requerimiento ha llevado al diseño de
estructuras de datos complejas para la representación de datos en la base de datos.
Puesto que muchos usuarios de sistemas de bases de datos no tienen experiencia en
computadores, se les esconde la complejidad a través de diversos niveles de abstracción
para simplificar su interacción con el sistema.

Nivel Físico: El nivel más bajo de abstracción describe como se almacenan realmente
los datos. En el nivel físico, se describen en detalle las estructuras de datos complejas de
bajo nivel.
Nivel Conceptual: El siguientes nivel de abstracción describe qué datos son realmente
almacenados en la base de datos y las relaciones que existen entre los datos. Aquí se
describe la base de datos completa en términos de un número pequeño de estructuras

Prof. A.U.S. Gustavo Torossi P ágina 20 de 45


Diseño del Modelo de Datos Universidad Tecnol ógica Nacional - F.R.R.

relativamente sencillas las que pueden implicar estructuras complejas en el nivel físico.
El nivel conceptual lo usan los administradores de base de datos, quienes deben decidir
qué información se va a guardar en la base de datos.
Nivel de Visión: El nivel más alto de abstracción describe sólo partes de la base de
datos completa. Muchos usuarios de la base de datos, no necesitan conocer toda la
información. En cambio, dichos usuarios sólo necesitan conocer una parte de la base de
datos. El sistema puede proporcionar múltiples visiones para la misma base de datos.

Visión 1 Visión 1 Visión n

Nivel
Conceptual

Nivel
Físico

Una analogía con el concepto de tipos de datos en los lenguajes de programación puede
clarificar la distinción entre niveles de abstracción. La mayoría de los lenguajes de
programación de alto nivel soportan la noción de un tipo registro. Por ejemplo, en un
lenguaje como Pascal podemos declarar un registro como sigue:

type cliente = record


nombre : string;
calle : string;
ciudad : string;
end;

Esto define un registro nuevo llamado cliente con tres campos. Cada campo tiene un
nombre y un tipo asociado a él. En una empresa bancaria puede haber varios tipos de
registro como este, incluyendo:

• cuenta, con los campos números y saldo.


• empleado, con los campos nombre y salario.

En el nivel físico, un registro de cliente, cuenta o empleado puede describirse como un


bloque de posiciones de memoria consecutivas (por ejemplo, palabras o bytes). En el
nivel conceptual, cada uno de estos registros se describe por medio de una definición del
tipo, ilustrada arriba, y se define la interrelacion entre estos tipos de registro.
Finalmente, en el nivel de visión, se definen varias visiones de la base de datos. Por
ejemplo, los cajeros de un banco sólo ven aquella parte de la base de datos que tiene

Prof. A.U.S. Gustavo Torossi P ágina 21 de 45


Diseño del Modelo de Datos Universidad Tecnol ógica Nacional - F.R.R.

información sobre las cuentas de los clientes. No pueden acceder a la información


referente a los salarios de los empleados.

14.2.2 Modelos De Datos


Para describir la estructura de una base de datos es necesario definir el concepto de
modelo de datos.

Un modelo de datos es una colección de herramientas conceptuales para describir datos,


relaciones entre ellos, semántica asociada a los datos y restricciones de consistencia.

Los diversos modelos de datos que se han propuesto se dividen en tres grupos: modelos
lógicos basados en objetos, modelos lógicos basados en registros y modelos físicos de
datos.

Modelos lógicos basados en objetos


Los modelos lógicos basados en objetos se usan para describir datos en los niveles
conceptual y de visión. Se caracterizan por el hecho de que proporcionan capacidad de
estructuración bastante flexible y permiten especificar restricciones de datos
explícitamente. Hay modelos diferentes, y es probable que aparezcan más. Algunos de
los más extensamente conocidos son:

• El modelo entidad-relación.
• El modelo orientado a objetos.
• El modelo binario.
• El modelo semántico de datos.
• El modelo infológico.
• El modelo funcional de datos.

El modelo entidad-relación (MER)


El modelo de datos entidad-relación (E-R) se basa en una percepción de un mundo real
que consiste en una colección de objetos básicos llamados entidades, y relaciones entre
estos objetos. Una entidad es un objeto que es distinguible de otros objetos por medio de
un conjunto específico de atributos. Por ejemplo, los atributos número y saldo describen
una cuenta particular de un banco. Una relación es una asociación entre varias
entidades. Por ejemplo, una relación CliCta asocia a un cliente con cada una de las
cuentas que tiene. El conjunto de todas las entidades del mismo tipo y relaciones del
mismo tipo se denomina conjunto de entidades y conjunto de relaciones,
respectivamente. Además de entidades y relaciones, el modelo E-R representa ciertas
restricciones a las que deben ajustarse los contenidos de una base de datos. Una
restricción importante es la de cardinalidad de asignación, que expresa el número de
entidades a las que puede asociarse otra entidad mediante un conjunto de relación.
Para el diseño del MER se utiliza una herramienta los diagramas E-R (DER), que se
estudian en la siguiente unidad.

Prof. A.U.S. Gustavo Torossi P ágina 22 de 45


Diseño del Modelo de Datos Universidad Tecnol ógica Nacional - F.R.R.

Modelos lógicos basados en registros


Los modelos lógicos basados en registros se utilizan para describir datos en los modelos
conceptual y físico. A diferencia de los modelos de datos basados en objetos, se usan
para especificar la estructura lógica global de la base de datos y para proporcionar una
descripción a nivel más alto de la implementación.
Los modelos basados en registros se llaman así porque la base de datos está estructurada
en registros de formato fijo de varios tipos. Cada tipo de registro define un número fijo
de campos, o atributos, y cada campo normalmente es de longitud fija. Esto contrasta
con muchos de los modelos orientados a objetos en los que los objetos pueden contener
otros objetos a un nivel de anidamiento de profundidad arbitraria. La estructura más rica
de estas bases de datos a menudo lleva a registros de longitud variable en el nivel físico.
Los modelos de datos basados en registros tradicionalmente no incluyen un mecanismo
para la representación directa de código en la base de datos. En cambio, hay lenguajes
separados que se asocian con el modelo para expresar consultas y actualizaciones de la
base de datos. Algunos modelos basados en objetos (incluyendo el modelo orientado a
objetos) incluyen código ejecutable como una parte integrante del mismo modelo de
datos.
Los tres modelos de datos más ampliamente aceptados son los modelos relacional, de
red y jerárquico.
El modelo relacional, que ha ganado aceptación por encima de los otros dos en años
recientes. Los modelos de red y jerárquico, son todavía usados en un gran número de
bases de datos más antiguas, pero están cayendo rápidamente en desuso. Debajo
presentamos una breve visión de cada modelo.

Modelo relacional
El modelo relacional representa los datos y las relaciones entre los datos mediante una
colección de tablas, cada una de las cuales tiene un número de columnas con nombres
únicos.

Modelo de red
Los datos en el modelo de red se representan mediante colecciones de registros (en el
sentido de la palabra en Pascal o PL/1) y las relaciones entre los datos se representan
mediante enlaces, los cuales pueden verse como punteros. Los registros en la base de
datos se organizan como colecciones de grafos arbitrarios.

Modelo jerárquico
El modelo jerárquico es similar al modelo de red en el sentido de que los datos y las
relaciones entre los datos se representan mediante registros y enlaces, respectivamente.
Se diferencia del modelo de red en que los registros están organizados como colecciones
de árboles en vez de grafos arbitrarios.

Diferencias entre los modelos


Los modelos relacionales se diferencian de los modelos de red y jerárquico en que no
usan punteros o enlaces. En cambio, el modelo relacional conecta registros mediante los
valores que éstos contienen. Esta libertad del uso de punteros permite que se defina una
base, matemática formal.

Prof. A.U.S. Gustavo Torossi P ágina 23 de 45


Diseño del Modelo de Datos Universidad Tecnol ógica Nacional - F.R.R.

Modelos físicos de datos


Los modelos físicos de datos se usan para describir datos en el nivel más bajo. A
diferencia de los modelos lógicos de datos, hay muy pocos modelos físicos de datos en
uso. Dos de los más ampliamente conocidos son:

• Modelo unificador.
• Memoria de elementos.

Los modelos físicos de datos capturan aspectos de la implementación de sistemas de


bases de datos que no están cubiertos en este libro.

14.2.3 Instancias y Esquemas


Las bases de datos cambian a lo largo del tiempo según se añade y se suprime
información. La colección de información almacenada en la base de datos, en un
determinado momento en el tiempo, se llama una instancia de la base de datos. El
diseño global de la base de datos se llama esquema de la base de datos. Los esquemas se
cambian muy raras veces, o nunca.
Aquí resulta útil una analogía con los conceptos de tipos de datos, variables y valores en
los lenguajes de programación. Volviendo a la definición del tipo de registro cliente en
la sección anterior, obsérvese que al declarar el tipo cliente no hemos declarado ninguna
variable. Para declarar tales variables en un lenguaje como Pascal, escribimos:

Var cliente1: cliente;

La variable cliente1 corresponde ahora a un área de almacenamiento que contiene un


registro de tipo cliente.

El concepto de esquema de base de datos corresponde a la noción de definición de tipo


en el lenguaje de programación. Una variable de un tipo dado tiene un valor
determinado en un instante de tiempo dado.
Así, el concepto del valor de una variable en los lenguajes de programación corresponde
al concepto de una instancia de un esquema de la base de datos.
Los sistemas de bases de datos tienen varios esquemas, divididos de acuerdo con los
niveles de abstracción tratados en la sección 1.2. En el nivel más bajo está el esquema
físico, en el nivel intermedio el esquema conceptual, en el nivel más alto, un
subesquema. En general, los sistemas de bases de datos soportan un esquema físico, un
esquema conceptual, y varios subesquemas.

14.2.4 Independencia De Datos


Anteriormente definimos tres niveles de abstracción en los que puede verse la base de
datos. La capacidad de modificar una definición de un esquema en un nivel sin afectar la
definición de un esquema en el nivel superior siguiente se llama independencia de
datos. Hay dos niveles de independencia de datos:

Prof. A.U.S. Gustavo Torossi P ágina 24 de 45


Diseño del Modelo de Datos Universidad Tecnol ógica Nacional - F.R.R.

• Independencia física de datos: es la capacidad de modificar el esquema físico sin


provocar que se vuelvan a escribir los programas de aplicación. En algunas
ocasiones son necesarias las modificaciones en el nivel físico para mejorar el
funcionamiento.
• Independencia lógica de datos: es la capacidad de modificar el esquema
conceptual sin provocar que se vuelvan a escribir los programas de aplicación. Las
modificaciones en el nivel conceptual son necesarias siempre que se altera la
estructura lógica de la base de datos.

La independencia lógica de datos es más difícil de lograr que la independencia física de


datos, ya que los programas de aplicación son fuertemente dependientes de la estructura
lógica de los datos a los que acceden.
El concepto de independencia de datos es similar en muchos aspectos al concepto de
tipos abstractos de datos en los lenguajes de programación modernos. Ambos ocultan
detalles de implementación a los usuarios. Esto permite a los usuarios que se concentren
en la estructura general en vez de los detalles de implementación de bajo nivel.

Prof. A.U.S. Gustavo Torossi P ágina 25 de 45


Diseño del Modelo de Datos Universidad Tecnol ógica Nacional - F.R.R.

Unidad 15: El Modelo Entidad-Relación (MER)


El modelo de datos entidad-relación (E-R) se basa en la percepción de un mundo real
que consiste en un conjunto de objetos básicos llamados entidades y relaciones. Se
desarrolló para facilitar el diseño de bases de datos permitiendo la especificación de un
esquema empresarial. Este esquema representa la estructura lógica global de la base de
datos.
El modelo entidad-relación fue propuesto inicialmente por Chen en 1976 y ha sido
estudiado por varios autores. El MER se ve principalmente como una herramienta de
diseño.

15.1 Entidades y Conjuntos De Entidades


Una entidad es un objeto que existe y es distinguible de otros objetos por su sola
existencia.
Por ejemplo, Juan Pérez con el DNI 20.175.145 es una entidad, ya que identifica
unívocamente a una persona específica del universo.
Una entidad puede ser concreta, tal como una persona o un libro, o puede ser abstracta,
como un día festivo o un concepto.

Un conjunto de entidades es un conjunto de entidades del mismo tipo.


Por ejemplo, el conjunto de todas las personas que tienen una cuenta en un banco,
pueden definirse como el conjunto de entidades cliente.
Los conjuntos de entidades no necesitan ser disyuntos. Por ejemplo, es posible definir el
conjunto de entidades de todos los empleados de un banco (empleado) y el conjunto de
entidades de todos los clientes del banco (cliente). Una entidad persona puede ser una
entidad empleado, una entidad cliente, o ambas, o ninguna de las dos.

Una entidad está representada por un conjunto de atributos. Para cada atributo hay un
conjunto de valores permitidos llamados dominio de ese atributo.
Formalmente, un atributo es una función que asigna un conjunto de entidades a un
dominio. Así, cada entidad se describe por medio de un conjunto de pares (atributo,
valor del dato), un par para cada atributo del conjunto de entidades.

El concepto de un conjunto de entidades corresponde a la noción de definición de tipo


en un lenguaje de programación. Una variable de un tipo dado tiene un valor
determinado en un instante de tiempo dado. Así, una variable en los lenguajes de
programación corresponde al concepto de una entidad en el modelo E-R.

15.2 Relaciones y Conjuntos De Relaciones


Una relación es una asociación entre varias entidades. Por ejemplo, podemos definir
una relación que asocia al cliente Pérez con la cuenta 401.

Prof. A.U.S. Gustavo Torossi P ágina 26 de 45


Diseño del Modelo de Datos Universidad Tecnol ógica Nacional - F.R.R.

Un conjunto de relaciones es un conjunto de relaciones del mismo tipo. Formalmente es


una relación matemática de n ≥ 2 conjuntos de entidades (posiblemente no distintos). Si
E1, E2, E3,..., En, son conjuntos de entidades, entonces un conjunto de relaciones R es un
subconjunto de

{ (e1, e2,..., en)  e1 ∈ E1, e2 ∈ E2, ... , en ∈ En }

donde (e1, e2,..., en) es una relación.

La mayoría de las relaciones en un modelo entidad-relación son binarias.


Ocasionalmente, sin embargo, hay conjuntos de relaciones que implican más de dos
conjuntos de entidades. Como ejemplo, considérese la relación ternaria que existe entre
un cliente, su cuenta, y una sucursal a la que pertenece.
Siempre es posible sustituir un conjunto de relaciones no binario por conjuntos de
relaciones binarios distintos. Así, conceptualmente, podemos restringir el modelo E-R
para incluir solo conjuntos de relaciones binarias.

La función que juega una entidad en una relación se llama papel o rol. Los papeles,
normalmente son implícitos y no se suelen especificar. Sin embargo, son útiles cuando
el significado de una relación necesita ser clarificado. Tal es el caso cuando los
conjuntos de entidades de un conjunto de relaciones no son distintos. Por ejemplo, el
conjunto de relaciones trabaja-para podría modelarse por pares ordenados de entidades
empleado. El primer empleado de un par toma el papel de Jefe, mientras el segundo
toma el papel de Subordinado.

Una relación también puede tener atributos descriptivos.

15.3 Atributos
Una entidad está representada por un conjunto de atributos. Los atributos son datos que
describen una entidad dada. La elección de los atributos de una entidad es el resultado
de un proceso de abstracción.
Para cada atributo hay un conjunto de valores permitidos llamados dominio de ese
atributo.
Formalmente, un atributo es una función que asigna un conjunto de entidades a un
dominio. Así, cada entidad se describe por medio de un conjunto de pares (atributo,
valor del dato), un par para cada atributo del conjunto de entidades.

Existen situaciones en las que un atributo puede modelarse como una entidad distinta.
Considérese el conjunto de entidades empleado con atributos nombre-empleado y
número-teléfono. Se puede argumentar fácilmente que un teléfono es una entidad en sí
misma con atributos número-teléfono y situación (la oficina donde está colocado el
teléfono). Si tomamos este punto de vista, el conjunto de entidades empleado debe
definirse como sigue:

- El conjunto de entidades empleado con atributo nombre-empleado.


- El conjunto de entidades teléfono con atributo número-teléfono y situación.

Prof. A.U.S. Gustavo Torossi P ágina 27 de 45


Diseño del Modelo de Datos Universidad Tecnol ógica Nacional - F.R.R.

- El conjunto de relaciones EmplTelef, que indica la asociación entre los empleados y


los teléfonos que tienen.

Surge entonces una pregunta natural: ¿Qué constituye un atributo, y que constituye un
conjunto de entidades? Desafortunadamente, no hay una respuesta sencilla. La
distinción depende principalmente de la estructura del dominio de problema que se está
modelando y de la semántica asociada con el atributo en cuestión.

15.4 Restricciones
Una modelo E-R de una empresa puede definir ciertas restricciones a las cuales debe
ajustarse.
Una restricción importante es la de las cardinalidades de asignación. Analizaremos en
este sentido dos tipos distintos de cardinalidad de asignación: cardinalidad en atributos
y cardinalidad en relaciones.

15.4.1 Cardinalidad en Atributos


En general puede considerarse que cada entidad de un conjunto, tiene asociada
exactamente un valor de cada atributo. Sin embargo esto no es obligatorio.
Pueden especificarse cantidad mínima y máxima de valores de un atributo asociados a
una entidad.
La cardinalidad mínima indica el número mínimo de valores para el atributo:
- Si la card-min = 0 indica que el atributo es opcional y puede no estar especificado en
algunos casos.
- Si la card-min = 1 indica que el atributo es obligatorio y al menos un valor debe
especificarse para cada instancia de la entidad.

Ej.: card-min (PERSONA, Nombre) = 1, card-min (PERSONA, Teléfono) = 0

La cardinalidad máxima indica el número máximo de valores para el atributo.


- Si la card-max = 1 indica que el atributo es monovalente.
- Si la card-max > 1 indica que el atributo es polivalente.

Ej.: card-min (PERSONA, DNI) = 1, card-min (PERSONA, Teléfono) = n

Podemos expresar la cardinalidad de atributos como el par (card-min, card-max).

Ej.: card (PERSONA, Nombre) = (1,1), card (PERSONA, Teléfono) = (0,n)

Como disciplina de modelado, es aconsejable iniciar el proceso restringiéndose a


atributos con exactamente un valor (1,1) por los siguientes motivos:
- Los atributos multi-valorados (card-max n) son difíciles de implementar en SGBD
relacionales, obligando a procesos de normalización.
- Los atributos opcionales (card-min 0) generalmente indican clases especiales de
entidades.

Prof. A.U.S. Gustavo Torossi P ágina 28 de 45


Diseño del Modelo de Datos Universidad Tecnol ógica Nacional - F.R.R.

15.4.2 Cardinalidad en Relaciones


Expresan el número de entidades con las que puede asociarse otra entidad mediante un
conjunto de relaciones.
En esta sección nos concentraremos sólo en conjuntos binarios de relaciones. Más
adelante trataremos con conjuntos de relaciones n-arios (n > 2).
Para un conjunto binario de relaciones R entre los conjuntos de entidades A y B, la
cardinalidad de asignación debe ser una de las siguientes:

• Una a Una (1,1): Una entidad en A está asociada a lo sumo con una entidad de B, y
una entidad en B está asociada a lo sumo con una entidad en A.
• Una a Muchas (1,n): Una entidad en A está asociada con un número cualquiera de
entidades en B. Una entidad en B, sin embargo puede estar asociada a lo sumo con
una entidad en A.
• Muchas a Una (n,1): Una entidad en A está asociada a lo sumo con una entidad en
B. Una entidad en B, sin embargo, puede estar asociada con un número cualquiera
de entidades en A.
• Muchas a muchas (n,n): Una entidad en A está asociada con un número cualquiera
de entidades en B, y una entidad en B está asociada con un número cualquiera de
entidades en A.

La cardinalidad de asignación adecuada para un conjunto de relaciones determinado


obviamente es dependiente del dominio de problema que el conjunto de relaciones está
modelando.
Se hace la distinción entre cardinalidad máxima y cardinalidad mínima.

La cardinalidad máxima es utilizada para especificar cuantas veces una entidad está
asociada, como máximo, a través de un conjunto de relaciones. Se consideran dos
cardinalidades máximas:
- 1: indica que una entidad está asociada como máximo a una entidad a través de la
relación.
- n: indica que una entidad puede estar asociada a muchas entidades a través de la
relación.

La cardinalidad mínima es utilizada para especificar cuantas veces una entidad está
asociada, como mínimo, a través de un conjunto de relaciones. Se consideran dos
cardinalidades mínimas:
- 0: indica que una entidad no está obligatoriamente asociada a través de la relación
(participación opcional).
- 1: indica que una entidad debe estar asociada al menos una vez a través de la
relación (participación obligatoria).

Prof. A.U.S. Gustavo Torossi P ágina 29 de 45


Diseño del Modelo de Datos Universidad Tecnol ógica Nacional - F.R.R.

15.4.3 Dependencias
Las dependencias de existencias constituyen otra clase importante de restricciones.
Específicamente, si la existencia de la entidad A depende de la existencia de la entidad
B, entonces se dice que A es dependiente por existencia de B. La entidad B se dice que
es una entidad dominante y A se dice que es una entidad subordinada.

15.5 Claves
Es importante poder especificar cómo se distinguen las entidades y las relaciones.
Conceptualmente, las entidades y las relaciones son distintas, pero desde la perspectiva
de una base de datos, la diferencia entre ellas debe expresarse en términos de sus
atributos. El concepto de superclave nos permite hacer tales distinciones.

Una superclave es el conjunto de uno o más atributos que, considerados conjuntamente,


nos permiten identificar de forma única a una entidad en el conjunto de entidades.
Por ejemplo, el atributo seguridad-social, del conjunto de entidades cliente, es
suficiente para distinguir una entidad cliente de otra. Así, seguridad-social es una
superclave para el conjunto de entidades cliente. El atributo nombre-cliente de cliente,
no es una superclave, ya que varias personas podrían tener el mismo nombre.

El concepto de superclave no es suficiente para nuestros propósitos, ya que, como vimos


arriba, una superclave puede contener atributos ajenos. Si K es una superclave, entonces
también lo será cualquier superconjunto de K. A menudo estamos interesados en
superclaves para las cuales ningún subconjunto propio es superclave. Dichas
superclaves mínimas se llaman claves candidatas.

Usaremos el término clave primaria para denotar una clave candidata que elige el
diseñador como el medio principal de identificar entidades dentro de un conjunto de
entidades.

Es posible que un conjunto de entidades no tenga atributos suficientes para formar una
clave primaria. Un conjunto de entidades de este tipo se denomina conjunto de
entidades débiles. Un conjunto de entidades que tiene una clave primaria se denomina
conjunto de entidades fuerte. Para ilustrarlo, considérese el conjunto de entidades
transacción, que tiene tres atributos: nro-transacción, fecha, y cantidad. Aunque cada
entidad transacción es distinta, las transacciones en diferentes cuentas pueden compartir
el mismo número de transacción. Así, este conjunto no tiene clave primaria, y por lo
tanto es un conjunto de entidades débil.
Para que un conjunto de entidades débil sea significativo, debe ser parte de un conjunto
de relaciones una a muchas. Este conjunto de relaciones no debe tener atributos
descriptivos, ya que cualquier atributo que se necesite puede estar asociado con el
conjunto de entidades débil.
Los conceptos de conjuntos de entidades débiles y fuertes están relacionados con las
dependencias por existencia introducidas en la sección anterior. Un miembro de un
conjunto de entidades fuerte es por definición una entidad dominante, mientras que un
miembro de un conjunto de entidades débil es una entidad subordinada.

Prof. A.U.S. Gustavo Torossi P ágina 30 de 45


Diseño del Modelo de Datos Universidad Tecnol ógica Nacional - F.R.R.

Aunque un conjunto de entidades débil no tiene una clave primaria, sin embargo debe
haber un medio de distinguir entre todas aquellas entidades en el conjunto de entidades
que dependen de una entidad fuerte determinada.
El discriminador de un conjunto de entidades débil es un conjunto de atributos que
permite que se haga esta distinción. Por ejemplo, el discriminador del conjunto de
entidades débil transacción es el atributo número-transacción.
La clave primaria de un conjunto de entidades débil está formada por la clave primaria
del conjunto de entidades fuerte de la que depende su existencia, y su discriminador. En
el caso del conjunto de entidade transacción, su clave primaria es {número-cuenta,
número transacción}, donde número-cuenta identifica la entidad dominante de una
transacción, y número-transacción distingue entidades transacción dentro de la misma
cuenta.

La clave primaria de un conjunto de entidades nos permite distinguir entre las diversas
entidades del conjunto. Necesitamos un mecanismo parecido para distinguir entre las
diversas relaciones de un conjunto de relaciones. Para hacer esto, debemos explicar
primero cómo se describen las relaciones individuales. Una vez conseguido, podemos
explicar cómo se define una clave primaria para el conjunto de relaciones.
Sea R un conjunto de relaciones que implica a los conjuntos de entidades E1, E2, ... , En.
Sea (Ei) la clave primaria que denota el conjunto de atributos que forma la clave
primaria para el conjunto de entidades Ei. Supóngase que los nombres de atributos de
todas las claves primarias son únicos. Supóngase que R no tiene atributos. Entonces los
atributos que describen las relaciones individuales del conjunto R, denotadas por el
atributo (R), son

clave-primaria(E1) ∪ clave-primaria(E2) ∪ ... ∪ clave-primaria(En)

En el caso de que R tenga atributos descriptivos, digamos { a1, a2, ... ,am }, entonces el
conjunto atributo (R) consta de:

clave-primaria(E1) ∪ ... ∪ clave-primaria(En) ∪ { a1, a2, ... ,am }

Para ilustrar lo anterior, considerese el conjunto de relaciones CtaCli que implica los
siguientes conjuntos de entidades
- cliente, con la clave primaria seguridad-social
- cuenta, con la clave primaria número-cuenta
Puesto que el conjunto de relaciones tiene el atributo fecha, el cunjunto atributo(CtaCli)
se compone de los tres atributos: seguridad-social, número-cuenta, y fecha.

Ahora estamos en condiciones de explicar como se constituye la clave primaria de un


conjunto de relaciones R. La composición de la clave primaria depende de la
cardinalidad de la asignación y de la estructura de los atributos asociados con el
conjunto de relaciones R.
Si el conjunto de relaciones R no tiene atributos asociados, entonces el conjunto
atributo (R) forma una superclave. Esta superclave es una clave primaria si la
cardinalidad de asignación es muchas a muchas.
Considérese otra vez el cunjunto de relaciones CtaCli. Si el conjunto de relaciones es
muchas a muchas, entonces su clave primaria es {seguridad-social, número-cuenta}. Si
el conjunto de relaciones es muchas a una de cliente a cuenta, entonces su clave

Prof. A.U.S. Gustavo Torossi P ágina 31 de 45


Diseño del Modelo de Datos Universidad Tecnol ógica Nacional - F.R.R.

primaria es {seguridad-social}, ya que varias personas pueden tener una misma cuenta
asociada, pero solo existirá una instancia de CliCta por Cliente.

Si el conjunto de relaciones R tiene varios atributos asociados con él, entonces una
superclave está formada como antes, con la posible adición de uno o más de estos
atributos. La estructura de la clave primaria depende tanto de la cardinalidad de
asignación como de las semánticas de conjunto de relaciones.

15.6 Diagrama Entidad-Relación


Para modelar gráficamente los modelos E-R se utiliza como herramienta los diagramas
de Entidad-Relación. Existen diversas notaciones para este tipo de diagramas. La que
veremos corresponde a su creador Chen.
Estos diagramas poseen los siguientes básicos:

• Rectángulos, que representan conjuntos de entidades.


• Elipses, que representan atributos.
• Rombos, que representan relaciones entre conjuntos de entidades.
• Líneas, que conectan atributos a conjuntos de entidades y conjuntos de entidades a
relaciones.

El siguiente ejemplo consta de dos conjuntos de entidades, cliente y cuenta,


relacionados mediante un conjunto binario de relaciones CtaCli. Los atributos asociados
con cliente son nombre-cliente, seguridad-social, calle, y ciudad. Los atributos
asociados con cuenta son número-cuenta y saldo.

Calle

Seguridad-
Ciudad
Social Número-
Cuenta
Saldo
Fecha
Nombre-
Cliente

Cliente CtaCli Cuenta

Representación de la cardinalidad
La cardinalidad de las relaciones se representa mediante una flecha en los extremos de
las líneas de relación. Un extremo sin flecha, indica que muchas de dichas entidades se

Prof. A.U.S. Gustavo Torossi P ágina 32 de 45


Diseño del Modelo de Datos Universidad Tecnol ógica Nacional - F.R.R.

relacionan con la otra. Un extremo con flecha, indica que solo una de dichas entidades
se relacionan con la otra.
También se suelen utilizar un par de números entre paréntesis separados por comas o “:”
del tipo (x,y) para indicando cardinalidad mínima (x) y cardinalidad máxima (y).

Ejemplos de representación de cardinalidades

Una a Una (1,1): Un Cliente tiene una cuenta, y una cuenta pertenece a lo sumo a un
cliente.

Cliente CliCta Cuenta

Una a Muchas (1,n): Un Cliente tiene una o más cuentas, y una cuenta pertenece a lo
sumo a un cliente.

Cliente CliCta Cuenta

Muchas a Una (n,1): Un Cliente tiene una cuenta, y una cuenta pertenece a uno o más
clientes.

Cliente CliCta Cuenta

Muchas a muchas (n,n): Un Cliente tiene una o más cuenta, y una cuenta pertenece a
uno o más cliente.

Cliente CliCta Cuenta

Prof. A.U.S. Gustavo Torossi P ágina 33 de 45


Diseño del Modelo de Datos Universidad Tecnol ógica Nacional - F.R.R.

Utilización de cardinalidades máximas y mínimas: Un cliente puede tener cero o


varias cuentas (opcional), y una cuenta debe pertenecer a un cliente y solo a uno
(mandatorio)

(1,1) (0,n)
Cliente CliCta Cuenta

Indicación de Roles
Los papeles o roles que juegan las entidades se indican en los diagramas E-R
etiquetando las líneas que conectan los rombos a los rectángulos.

Director

Trabaja-
Empleado para
Trabajador

Entidades Débiles
Un conjunto de entidades débil se indica en los diagramas E-R por medio de un
rectángulo de doble contorno.

Número- Fecha
cuenta
saldo
Cantidad
Número-
transacción

(1,1) (0,n)
Cuenta Transacción

Relaciones no binarias
Los conjuntos de relaciones no binarias pueden especificarse fácilmente en un diagrama
ER. En la siguiente figura se observa un diagrama ER que consta de tres conjuntos de
entidades: cliente, cuenta, y sucursal, relacionados por medio de un conjunto de

Prof. A.U.S. Gustavo Torossi P ágina 34 de 45


Diseño del Modelo de Datos Universidad Tecnol ógica Nacional - F.R.R.

relaciones CAB. Este diagrama especifica que un cliente puede tener varias cuentas,
cada una situada en una sucursal específica del banco, y que una cuenta puede
pertenecer a varios clientes distintos.

Ciudad-
sucursal

Nombre-
Activo
sucursal

Calle
Sucursal

Seguridad-
Ciudad
Social Número-
Cuenta
Saldo
Nombre-
Cliente

Cliente CAB Cuenta

15.7 Reducción de un DER a un conjunto de Tablas


Una base de datos que se ajusta a un diagrama E-R puede representarse por medio de
una colección de tablas. Para cada conjunto de entidades, y para cada conjunto de
relaciones en la base de datos, existe una tabla única a la que se le asigna el nombre del
conjunto de entidades o del conjunto de relaciones correspondiente. Cada tabla tiene un
número de columnas que, a su vez, tiene nombres únicos. Presentaremos estos
conceptos considerando una representación tabular del diagrama E-R de la figura 2.13.

Prof. A.U.S. Gustavo Torossi P ágina 35 de 45


Diseño del Modelo de Datos Universidad Tecnol ógica Nacional - F.R.R.

Seguridad-
Social

Fecha
Saldo
Ciudad
Cantidad

Calle Número- Número-


Cuenta transacción

Cliente CtaCli Cuenta Bitacora Transacción

Nombre-
Fecha
Cliente

15.7.1. Representación de conjuntos de entidades fuertes


Sea E un conjunto de entidades fuerte con los atributos descriptivos a1,a2,...,an .
Representamos esta entidad por medio de una tabla llamada E con n columnas distintas
cada una de las cuales corresponde a uno de los atributos de E. Cada fila de esta tabla
corresponde a una entidad del conjunto (instancia).
Las tablas correspondientes a los conjuntos de entidades cliente y cuenta serán:

CLIENTE CUENTA
Nombre- Seguridad- Calle Ciudad Número-cuenta Saldo
cliente social

15.7.2. Representación de conjuntos de entidades débiles


Sea A un conjunto de entidades débiles con atributos descriptivos a1,a2,...,an . Sea B el
conjunto de entidades fuerte del que depende A. La clave primaria de B consta de los
atributos b1, b2,..., bn. Representamos el conjunto de entidades A con una columna para
cada atributo del conjunto:

{a1,a2,...,an} ∪ {b1,b2,...,bn}

Para ilustrarlo consideremos el conjunto de entidades transacción. Este conjunto tiene


tres atributos: número-transacción, fecha, y cantidad. La clave primaria del conjunto de
entidades cuenta de la que transacción es dependiente, es número-cuenta. Así,

Prof. A.U.S. Gustavo Torossi P ágina 36 de 45


Diseño del Modelo de Datos Universidad Tecnol ógica Nacional - F.R.R.

transacción se representa mediante una tabla con cuatro columnas etiquetadas número-
cuenta, número-transacción, fecha, y cantidad.

TRANSACCION
Número- Número- Fecha Cantidad
cuenta transacción

15.7.2 Representación de conjuntos de relaciones


Sea R un conjunto de relaciones que implica a los conjuntos de entidades E1, E2, ..., En.
Supongamos que atributo(R) consta de n atributos. Representamos este conjunto de
relaciones mediante una tabla llamada R con n columnas distintas, cada una de las
cuales corresponde a uno de los atributos de atributo(R).
Para ilustrarlo, consideremos el conjunto de relaciones CtaCli. Este conjunto de
relaciones implica a los conjuntos de entidades cliente, cuya clave primaria es
seguridad-social, y cuenta, cuya clave primaria es número-cuenta.
Puesto que el conjunto de relaciones tiene el atributo fecha, la tabla CtaCli tiene tres
columnas etiquetadas seguridad-social, número-cuenta, y fecha.

CLICTA
Seguridad-social Número-cuenta Fecha

Relaciones ternarias
Considérese el conjunto ternario de relaciones CAB visto anteriormente. Esta relación
implica a los tres conjuntos de entidades siguientes:
- cliente, con la clave primaria seguridad-social
- cuenta, con la clave primaria número-cuenta
- sucursal, con la clave primaria nombre-sucursal
En este caso, la relación se representa por la tabla CAB que tiene tres columnas
- seguridad-social
- número-cuenta
- nombre-sucursal

Prof. A.U.S. Gustavo Torossi P ágina 37 de 45


Diseño del Modelo de Datos Universidad Tecnol ógica Nacional - F.R.R.

Relaciones de entidades débiles


El caso de conjuntos de relaciones que conectan un conjunto de entidades débil con su
correspondiente conjunto de entidades fuerte es especial. Como se dijo anteriormente,
estas relaciones tiene cardinalidad muchas a una y no tienen atributos descriptivos.
Además, la clave primaria del conjunto de entidades débil incluye la clave primaria del
conjunto de entidades fuerte. En el ejemplo previo, el conjunto de entidades débiles
transacción es dependiente del conjunto de entidades fuerte cuenta a través del conjunto
de relaciones bitácora. La clave primaria de transacciones es {número-cuenta, número-
transacción}, y la clave primaria de cuenta es {número-cuenta}. Puesto que bitácora no
tiene atributos descriptivos, la tabla correspondiente tendría dos columnas, número-
cuenta y número-transaccion. La tabla para el conjunto de entidades transacción tiene
cuatro columnas, número-cuenta, número-transacción, fecha, y cantidad. De esta forma,
la tabla bitácora es redundante.
En general, la tabla para el conjunto de relaciones que conecta un conjunto de entidades
débil con su correspondiente conjunto de entidades fuerte es redundante y no necesita
presentarse en una representación tabular.

Casos especiales
Relaciones 1 a N : Las relaciones 1:N, se representarían con una tabla cuya clave
primaria coincide con la clave primaria de la entidad que participa con cardinalidad N
en la relación. En tales casos, al tener ambas tablas la misma clave primaria, pueden
combinarse en una sola tabla. Esto puede hacerse agregando a la tabla correspondiente a
cardinalidad N, columnas para los atributos descriptivos de la relación. En este caso la
columna correspondiente a la clave primaria de la entidad de cardinalidad 1, agregada en
la tabla de cardinalidad N, se denomina clave foránea.
Para ilustrarlo consideremos el siguiente ejemplo. Supongamos en el caso anterior la
restricción 1,N de Cliente a Cuenta (un cliente puede tener N cuentas, pero una cuenta
pertenece a un único cliente). Esta relación puede representarse agregando las columnas
seguridad-social y fecha a la tabla Cuenta. En este caso, Seguridad-social es una clave
foránea.

CUENTA
Número-cuenta Saldo Seguridad-social Fecha

Observación: cuando las dos entidades participantes de la relación son fuertes, la clave
foránea no participa en la clave primaria de la entidad de cardinalidad N. Si dicha
entidad es débil, entonces la clave foránea forma parte de su clave primaria.

Prof. A.U.S. Gustavo Torossi P ágina 38 de 45


Diseño del Modelo de Datos Universidad Tecnol ógica Nacional - F.R.R.

Relaciones 1 a 1 : Se pueden resolver de manera similar a las 1,N e inclusive combinar


ambas entidades en una única tabla.

15.8 Extensiones al MER

15.8.1 Generalización
Un conjunto de entidades E es una generalización de un grupo de conjuntos E1,E2,...En,
si todo atributo perteneciente a E, también pertenece a todos los demás conjuntos. Es
una relación de inclusión.
La generalización aplica la relación es un. La generalización permite que las entidades
de nivel más bajo hereden los atributos de la entidad generalizadora de más alto nivel.
Gráficamente, en el diagrama ER se representa mediante un triángulo con la etiqueta ES
UN.
En este ejemplo vemos cuenta es una generalización de cuenta-ahorro y cuenta-cheque.

Número-
Saldo
cuenta

Cuenta

Es un

Cuenta-ahorro Cuenta-cheque

Tasa- Saldo-
Interés deudor

Existen dos métodos diferentes para transformar una generalización en una forma
tabular.
1) Crear una tabla para el conjunto de entidades de nivel más alto. Para cada conjunto
de entidades de nivel más bajo se crea una tabla que incluya una columna para cada
uno de los atributos de ese conjunto de entidades más una columna para cada
atributo de la clave primaria del conjunto de entidades de nivel más alto.
2) Crear para cada conjunto de entidades de nivel más bajo una tabla que incluya una
columna para cada uno de los atributos de el conjunto de entidades más una
columna para cada atributo del conjunto de entidades de nivel más alto.

Prof. A.U.S. Gustavo Torossi P ágina 39 de 45


Diseño del Modelo de Datos Universidad Tecnol ógica Nacional - F.R.R.

15.8.2 Agregación
La agregación es una abstracción a través de la cual las relaciones se tratan como
entidades de nivel más alto.
En el siguiente ejemplo, la relación trabajo que vincula las entidades empleado y
proyecto se trata como una entidad de orden superior con el mismo nombre.

Trabajo

Empleado Entity
Trabajo
name Proyecto

Usa

Maquinaria

La transformación de un diagrama ER que incluya agregación a una forma tabular es


directa. Para el ejemplo anterior creamos las siguientes tablas:
- Empleado
- Proyecto
- Trabajo
- Maquinaria
- Usa
La tabla para el conjunto de relaciones usa incluye una columna para cada atributo de la
clave primaria del conjunto de entidades maquinaria y del conjunto de relaciones
trabajo.

Prof. A.U.S. Gustavo Torossi P ágina 40 de 45


Diseño del Modelo de Datos Universidad Tecnol ógica Nacional - F.R.R.

Unidad 15 b: Diseño Físico de Base de Datos


El diseño físico de bases de datos provee el puente entre el modelado lógico de datos y
la implementación física de los almacenes de datos. Esta actividad sirve de base para
determinar los requerimientos de hardware y software necesarios para implementar
eficientemente un conjunto de archivos o tablas.

Introducción
Si los sistemas de administración de bases de datos (DBMS) proveyeran soporte directo
para cada concepto utilizado en el modelado lógico de datos, y el hardware y el software
del DBMS soportaran capacidad de almacenamiento y velocidad infinita, podríamos
utilizar el modelo lógico de datos como el modelo terminado.
Sin embargo, como los DBMS no soportan todos los conceptos del modelado lógico, y
como existen restricciones de performance tanto del Hw como del Sw, deben tenerse en
consideración dichas cuestiones a la hora de implementar físicamente el modelo de
datos.
Las restricciones de facilidades disponibles para implementar un modelo de datos
implican dos de las mayores cuestiones en el diseño físico de bases de datos:
• Como implementar un concepto del modelo lógico de datos para el cual el DBMS
no provee soporte directo? Por ejemplo, como implementar control de integridad de
dominio para un DBMS que no soporta dominios.
• Como implementar un concepto del modelo lógico de datos que puede significar un
cuello de botella en la performance si se implementa en forma directa? Por ejemplo
implementar una visión particular con un orden de acceso específico para una tabla
base con gran cantidad de registros, puede implicar la necesidad de incorporar un
índice particular según el ordenamiento de acceso requerido.

El diseño físico de bases de datos se basa en los siguientes elementos:


• El modelo lógico de datos y el modelo de procesos, que definen que es lo que debe
implementarse.
• Los volúmenes de datos y patrones de acceso esperados.
• Las características funcionales del DBMS a utilizar (p.e. capacidad para soportar
datos de formato fecha, soporte de dominios, etc.).
• Las características de performance del sistema de HW y SW (p.e. el costo relativo
de recuperar un registro dado por clave versus acceso secuencial).

A continuación se brinda una lista de 10 pasos a seguir para implementar físicamente un


modelo de datos:
• Paso 1: Especificar un Archivo / Tabla física para Cada Conjunto Entidades /
Relaciones
• Paso 2: Especificar Implementación para Claves Primarias, Candidatas, y Foráneas
• Paso 3: Especificar Implementación de Dominios
• Paso 4: Especificar Implementación de Otras Reglas de Integridad
• Paso 5: Especificar Implementación de Vistas
• Paso 6: Especificar Implementación de Seguridad

Prof. A.U.S. Gustavo Torossi P ágina 41 de 45


Diseño del Modelo de Datos Universidad Tecnol ógica Nacional - F.R.R.

• Paso 7: Especificar Indices Adicionales por Performance


• Paso 8: Introducir Redundancia Controlada
• Paso 9: Combinar Tablas Bases
• Paso 10: Ajustar el Diseño de la Base de Datos para Anticipar Cambios

Paso 1: Especificar un archivo o tabla física para cada


conjunto entidades/relaciones
Este paso es relativamente automático. Luego de haberse trasladado el MER a un
conjunto de tablas, según lo indicado en la unidad anterior, se debe realizar un proceso
de normalización de dichas tablas si fuera necesario, llegando por lo menos a 3FN.
Para cada tabla lógica asi obtenida, se especificará un archivo o tabla física. Estó es
altamente dependiente del entorno de implementación. Cada columna deberá ser
definida utilizando los tipos de datos específicos soportados por el DBMS que más se
adecuen.

Paso 2: Especificar implementación para claves Primarias,


Candidatas, y Foráneas
Deben implementarse físicamente los mecanismos de acceso para cada tabla. Las claves
primarias y candidatas son los mecanismos de identificación unívocos. Deberá
implementarse obligatoriamente la clave primaria y el diseñador decidirá que claves
candidatas alternativas se requerirán implementar según las necesidades de acceso a los
datos que se hayan establecido según los procesos.
Independientemente del DBMS utilizado, cada implementación de una clave implica un
costo en espacio de almacenamiento y performance en los accesos de actualización. Por
lo cual debe considerarse cada incorporación de una clave candidata.
Las claves foráneas deben implementarse para facilitar la localización de los registros
relacionados en una relación de cardinalidad 1 a N.

Paso 3: Especificar implementación de dominios


Muchos de los DBMS nos soportan facilidades para especificar en forma directa
dominios estableciendo tipos de datos con sus correspondientes estructuras y
restricciones.
En tales casos pueden realizarse controles específicos aplicando alguno de los métodos
especificados en el paso 4.

Paso 4: Especificar implementación de otras reglas de


integridad
Métodos para implementar reglas de integridad:
• Programas disparadores (triggers) soportados por el DBMS
• Rutinas de acceso a archivo
• Controles internos en los programas

Prof. A.U.S. Gustavo Torossi P ágina 42 de 45


Diseño del Modelo de Datos Universidad Tecnol ógica Nacional - F.R.R.

Los triggers son rutinas de validación que se almacenan directamente en el DBMS y son
ejecutadas por el mismo cada vez que se realiza una operación de actualización sobre un
archivo.
Las rutinas de acceso a archivo, son módulos especiales que centralizan el acceso al
archivo. En dichos módulos el diseñador implementa todas las reglas de validación de
integridad para los datos que lo requieran. Cada vez que se desea realizar un acceso al
archivo debe realizarse via este módulo. El mayor inconveniente que presenta este
método es que siempre puede saltearse el uso de este módulo por negligencia o
intencionadamente, y no puede restringir el acceso por herramientas fuera del sistema.
Finalmente, el enfoque mas antiguo es agregar controles internos en los programas que
acceden a los archivos. Esto lleva a una alta redundancia en el código y a la posibilidad
de que no se apliquen siempre todas las reglas.
En cualquiera de los casos deberá verificarse que la implementación de reglas no
conlleve una degradación de la performance inaceptable.

Paso 5: Especificar implementación de vistas


Una visión es una tabla ‘virtual’ especificada a partir de una o más tablas físicas reales.
Es una funcionalidad ofrecida por la mayoria de los DBMS relacionales. A partir de una
operación de proyección, selección, o de junta pueden combinarse campos de diversas
tablas en una sola, seleccionar un determinado subconjunto de columas o registros, para
de esta forma limitar el acceso a los datos por los usuarios finales, como asi tambien
especificar un determinado criterio de acceso.

Paso 6: Especificar Implementación de Seguridad


Los distintos niveles de seguridad de acceso a los datos deben especificarse para cada
tabla, e incluso para determinados atributos de las mismas.
Para cada usuario del sistema debe especificarse que tablas pueden ser accedidas por el
mismo y que operaciones puede realizar (read, write, upd, dlt).
La mayoría de los motores de bases de datos proveen mecanismos para implementar
seguridad en estos niveles.
En el caso en que el DBMS no implemente determinado nivel de seguridad, el mismo
deberá ser implementado via rutinas de acceso a archivos o controles internos en los
programas. Estos mecanismos no son utiles para restringir el acceso a los datos por
herramientas externas al sistema.

Paso 7: Especificar Indices Adicionales por Performance


Un índice provee un medio eficiente para acceder a un registro específico por valor de
clave o para procesar todo o parte de un archivo en una secuencia específica.
El diseño de la B.D. debe incluir al menos un índice para la clave primaria, y
potencialmente otros para claves candidatas seleccionadas por el diseñador y para claves
foráneas.
La principal razón para incorporar índices adicionales es para recuperar grupos de
registros en una secuencia particular y como un medio eficiente para seleccionar
subconjuntos de registros.

Prof. A.U.S. Gustavo Torossi P ágina 43 de 45


Diseño del Modelo de Datos Universidad Tecnol ógica Nacional - F.R.R.

Los índices sin embargo generan una sobrecarga en las operaciones de actualización,
por lo cual debe considerarse muy bien la conveniencia de su incorporación.
Deben incorporarse índices adicionales cuando los tiempos de respuesta requerido son
breves. El caso más típico es para los accesos interactivos, como consultas por pantallas,
donde los tiempos de respuesta son restrictivos.
Para los procesos batch, debe analizarse la posibilidad de utilizar herramientas de
ordenamiento de archivos, antes de llegar a la implementación de un índice.

Paso 8: Introducir Redundancia Controlada


Las principales razones para introducir redundancia controlada en el modelo de datos
son:
• Almacenamiento de datos secundarios (derivados) cuya obtención representa un
costo considerable de procesamiento.
• Para algunos DBMS combinar datos provenientes de distintas tablas (JOINs) pueden
representar un costo en performance considerable.
• Datos replicados.
En todos los casos, la introducción de redundancia controlada es una decisión de
compromiso que sigue los siguientes principios generales:
• La redundacia controlada hace más rápidos y simples los accesos de lectura.
• La redundacia controlada hace más lentos y complejos los accesos de actualización.
Una técnica para mejorar la consistencia de datos redundantes es utilizar programas
disparadores (triggers) para propagar automáticamente los cambios en las demás tablas.

Paso 9: Combinar Tablas Bases


Otra alternativa de diseño relacionada con la performance es el combinar dos o más
tablas bases del modelo lógico en un único archivo físico.
Los casos más típicos son :
• Atributos polivalentes.
• Subtipos de entidad.
Es el caso típico de los atributos polivalentes, que luego de un proceso de normalización
se transforman en otras tablas. Por ejemplo el caso de una persona que tuviera varios
teléfonos. El modelo lógico consistiría en una tabla para los datos de la persona y otra
tabla para los teléfonos. Para acceder a los datos completos de una persona deben
accederse a cada registro de ambas tablas.
Si puede acotarse la cantidad máxima de ocurrencias del atributo polivalente, puede
utilizarse una sola tabla donde se incorpore un campo para cada ocurrencia. Esta
solución sin embargo puede ser poco óptima en el caso de que el promedio de
ocupación del atributo esté muy por debajo de máximo esperado.
Otro caso potencial de combinación de tablas bases es en el caso de subtipos de entidad.
Una alternativa es combinar todas las tablas base de la generalización y las
especializaciones en un único archivo físico. En este caso, hay atributos que serán
válidos para el caso de una especialización y no válidos para otros. Debe agregarse un
campo para discriminar el tipo de entidad que se almacena en el registro.

Prof. A.U.S. Gustavo Torossi P ágina 44 de 45


Diseño del Modelo de Datos Universidad Tecnol ógica Nacional - F.R.R.

Paso 10: Ajustar el Diseño de la Base de Datos para Anticipar


Cambios

Prof. A.U.S. Gustavo Torossi P ágina 45 de 45

También podría gustarte