BASES DE DATOS

INTALENTIA, Bases de Datos

2

INDICE TEMA 1. INTRODUCCIÓN A LAS BASES DE DATOS

1. Cualidades de la información 2. Sistemas de información 2.1. Componentes de un sistema de información 3. Niveles de gestión de una organización. . 4. Evolución: de los sistemas tradicionales de

ficheros a las bases de datos 4.1. Inconvenientes de los sistemas tradicionales de

ficheros 5. Concepto de base de dato s 5.1. Niveles de abstracción 5.2. Independencia de los datos: 5.3. Usuarios de un sistema de base de datos. La

función de administración. 5.4. El sistema de gestión de la base de datos 5.5. Ventajas del uso de bases de datos 5.5.1. Reducción de la redundancia 5.5.2. Puede evitarse la inconsistencia 5.5.3. Los datos pueden compartirse 5.5.4. Pueden hacerse cumplir las normas

establecidas 5.5.5. Restricciones de seguridad 5.6. Inconvenientes de las bases de datos


3

TEMA 2: ENFOQUE METODOLÓGICO 1 3. Conceptos y técnicas del modelado 3.1. Concepto de modelo 3.2. Modelos del análisis 3.2.1. Modelo a nivel del dominio 3.2.2. Modelo funcional 3.2.3. Modelo dinámico 3.2.4. Relaciones entre los modelos. 4. El nivel del dominio: modelos de datos. 4.1. Definición formal de modelo de datos 4.1.1. Componente estática 4.1.2. Componente dinámica 5. Antecedentes históricos 6. El modelo en red codasyl 6.1. Correspondencia del modelo en red con la

arquitectura de tres niveles de Ansi / x 3 / s p a r c 6.2. Componente estática. Registros y conjuntos. 6.3. Restricciones inherentes al modelo codasyl 6.4. Dinámica del modelo codasyl 7. El modelo jerárquico 7.1. Características de la estructura j e r á r q u i c a 7.2. Restricciones i n h e r e n t e s al modelo

jerárquico 7.3. Correspondencia del modelo j e r á r q u i c o d e i

m s con la arquitectura De tres niveles de ansi / x3 / sparc 7.4. La manipulación de los datos 8. Los modelos en red y el modelo relacional 8.1. Representación de los datos. 8.2. Lenguaje de manipulación de datos. 8.3. Restricciones de integridad 17 8.4. Implementación


4

TEMA 3: DISEÑO CONCEPTUAL: MODELO ENTIDAD/INTERRELACIÓN 1

1. Presentación e historia del modelo 2. Elementos del modelo entidad/interrelación 2.1. Entidades 2.2. Atributos 2.3. Interrelaciones 2.4. Representación gráfica 2.5. Representación de restricciones de diseño 2.6. Tipo de correspondencia 2.7. Entidades débiles 2.7.1. Dependencia en existencia y dependencia en

identificación. 2.8. Papel (‘rol’) de la entidad 2.9. Atributos multiocurrentes y compuestos 2.10. Atributos derivados 3. Modelo entidad/interrelación extendido 3.1. Cardinalidad 3.2. Jerarquía subconjunto 3.3. Características 3.4. Tipos de generalización 3.4.1. Jerarquía total de subtipos disjuntos 3.4.2. Jerarquía disjunta y parcial 3.4.3. Jerarquía total con solapamiento 3.4.4. Jerarquía parcial de subtipos solapados 3.5. Tipos de relaciones 3.5.1. Relaciones reflexivas 3.5.2. Relaciones exclusivas 3.5.3. Entre dos tipos de entidad puede existir más de

un tipo de interrelación 3.6. D i m e n s i o n temporal en el modelo e /r 3.7. Restricciones 3.8. Control de r e d u n d a n c i a Bibliografía


5

TEMA 1: Introducción a las bases de datos Las bases de datos constituyen una parte fundamental de los sistemas de información en los que están integrados. El estado actual de la tecnología de bases de datos es el resultado de la evolución que a lo largo de décadas ha tenido lugar en el procesamiento de los datos y en la gestión de la información. La tecnología de gestión de datos se ha desarrollado desde los métodos primitivos de los años cincuenta hasta los potentes sistemas de hoy en día, empujada por un lado por la demanda y las necesidades de la gestión de la información y restringida por otro por las limitaciones de la tecnología. Las necesidades de administración crecen paralelamente a la evolución de la tecnología. Los primeros sistemas de procesamiento de datos resolvían tareas administrativas para reducir el papeleo. Estos sistemas han ido evolucionando hacia la gestión y la producción de información, que se ha convertido en un recurso vital para las compañías. En la actualidad, la función más importante de los sistemas de bases de datos es servir de fundamento a los sistemas de información para la gestión corporativa.

1. Cualidades de la información

[Adaptado de DEMIG97] La creciente necesidad de información y la mayor disponibilidad de ésta puede conducir a un deterioro de la calidad de la misma si no se toman las medidas necesarias para evitarlo. Si pierde sus cualidades, la información, lejos de cumplir sus objetivos, es decir, aportar un conocimiento, puede perder su valor informativo siendo incluso perjudicial para los destinatarios de la misma. Las cualidades que hacen de la información un recurso fundamental para las organizaciones y los usuarios individuales son, básicamente:

Precisión: Porcentaje de información correcta sobre el tota l de información

almacenada en el sistema. Oportunidad: Tiempo transcurrido desde que se produjo el hecho que originó el

dato hasta el momento en el que la información se pone a disposición del usuario. También se mide según el tiempo transcurrido desde que el dato tendría


6

que estar disponible o por el desfase que produce su procesamiento por ordenador. Dependiente de la finalidad de los datos. Por ejemplo, para la elaboración de un censo de población de, por ejemplo, varios millones de datos de carácter bastante estable, un tiempo de proceso de meses no le resta oportunidad a la información. En cambio, esta demora en otro tipo de valores como, por ejemplo, las cotizaciones en bolsa, sería inadmisible, despojando a los datos de su valor informativo. Aunque en general el valor informativo de los datos pierde valor con el transcurso del tiempo, en los sistemas de soporte a la toma de decisiones es al contrario.

Compleción: Ha de ser completa para cumplir los fines para los que se gestiona. Por ejemplo, si se mantiene un sistema de información como sistema de apoyo a la toma de decisiones, la información proporcionada por éste ha de contener todos los elementos informativos necesarios para dar apoyo a la toma de decisiones.

Significado: El contenido semántico de los datos ha de ser máximo. Al diseñar un sistema de información debemos adecuar el volumen de información suministrada por el sistema a los objetivos propuestos. Más información no significa mejor información, ocurriendo que un volumen excesivo de información dificulta su asimilación por parte del usuario.

Coherencia: La información contenida en el sistema debe ser coherente en sí misma, además de consistente con las restricciones semánticas del mundo al que ha de representar lo más fielmente posible. La literatura sobre bases de datos suele referirse a esta cualidad como integridad.

Seguridad: Debe prestarse especial atención a la protección de la información tanto frente a su deterioro físico o lógico como a los accesos no autorizados. El problema de la seguridad abarca la confidencialidad, la disponibilidad y la integridad.

2. Sistemas de Información

Toda organización necesita para su funcionamiento un conjunto de informaciones que han de transmitirse entre sus diferentes elementos, así como desde y hacia el exterior de la propia organización. Un sistema de información se diseña con el fi n de satisfacer las necesidades de información de una organización, en la que está inmerso. El sistema de información toma datos del entorno (tanto de la organización como de fuentes


7

externas) y los resultados de las operaciones sobre esos datos serán la información que dicha organización necesita para su gestión y toma de decisiones.

2.1. Componentes de un sistema de información

En todo sistema de información encontramos los siguientes componentes: Contenido (Datos: hechos conocidos con significado implícito, que pueden ser almacenados) es el centro del sistema de información. Los datos contenidos en un sistema de información pueden ser de tipo referencial o de tipo factual. Datos de tipo referencial son aquellos que contienen información acerca de dónde se encuentra la información buscada. Los datos de tipo factual son aquellos que contienen la información en sí. A su vez pueden ser estructurados o no estructurados. Los primeros son aquellos con una estructura definida. Los no estructurados son aquellos que, por sus características, no tienen una estructura definida (sonido, vídeo, etc.). Equipo físico. Ordenadores y periféricos. Soporte lógico. Incluye todo el software necesario para la implantación del sistema de información (Sistema Operativo, sistema de base de datos, software de comunicaciones y otros programas para tratamientos específicos). Administrador. Los datos y las informaciones manejadas por nuestro sistema de información han de ser gestionadas por las personas adecuadas. Tendremos, por un lado los responsables de tomarlas decisiones estratégicas y de política con respecto a la información de la empresa y por otro los responsables de dar apoyo técnico para poner en práctica esas decisiones. Usuarios. Los datos han de ser puestos a disposición de los usuarios del sistema. Podemos clasificarlos en usuarios informáticos, aquellos que realizan las aplicaciones que manejarán los datos almacenados en el sistema y usuarios no informáticos, los cuales se ocuparán de realizar las tareas administrativas con los datos y/ o serán los destinatarios de las informaciones extraídas del sistema.


8

3. Niveles de gestión de una organización. Sistemas de información para la gestión y sistemas de información para la ayuda a la decisión.

En toda organización suelen distinguirse tres niveles de gestión (operacional, táctico y estratégico) por lo que el sistema de información ha de ser diseñado para satisfacer las necesidades y proporcionar las informaciones adecuadas a cada uno de los niveles.

En el plano operacional, los usuarios manejan datos puntuales o elementales que describen los sucesos que caracterizan las actividades de la organización. Esta información, compuesta por datos totalmente desagregados (microdatos) es necesaria para los procesos comúnmente denominados administrativos (tareas diarias y de rutina) y el volumen de datos manejado será muy grande.

Los niveles tácticos y estratégico, cuyos usuarios tienen necesidades de información muy distintas, obtendrán del anterior, mediante procesos de elaboración adecuados (generalmente de agregación) junto con datos provenientes del exterior las informaciones necesarias para ayuda a la decisión, que exige prestaciones muy diferentes en la que los datos están agregados (macrodatos) y cuya elaboración es mucho más compleja.

Como ya se ha apuntado, la aplicación de los ordenadores en las organizaciones comenzó con el tratamiento administrativo de sus datos operacionales (nóminas, contabilidad, etc.) La creciente potencia de los ordenadores los hizo aptos para intervenir en otros niveles de la empresa, ayudando a la sistematización de las funciones de dirección y constituyendo un elemento activo en el proceso de toma de decisiones. Los sistemas de soporte a la toma de decisiones (DSS, Decision Support Systems o EIS, Executive Information Systems) tienen como componente principal una base de datos. Del mismo modo, los datos provenientes del plano operacional almacenados en bases de datos así como en otros soportes, organizados en almacenes de datos (Data Warehouses) sirven de base para la extracción y el descubrimiento de conocimiento en bases de datos (KDD, Knowledge Discovering in Databases) y para la minería de datos (Data Mining).


9

4. Evolución: De los sistemas tradicionales de ficheros a las bases de datos

4.1. Inconvenientes de los sistemas tradicionales de ficheros

Sistemas tradicionales de ficheros: Sistemas orientados hacia el proceso (se pone énfasis en el tratamiento que reciben los datos, los cuales se almacenan en archivos diseñados para una aplicación.) Las aplicaciones se diseñan e implantan independientemente unas de otras y los datos se duplican si las diferentes aplicaciones los necesitan, en lugar de transferirse entre ellas.


10

Redundancia: Duplicidad innecesaria de información. Mal aprovechamiento del equipo de almacenamiento, como consecuencia inmediata de la redundancia. Aumento de los tiempos de proceso. Se repiten los mismos controles y operaciones en los distintos ficheros, con lo que se consume más de tiempo de CPU del necesario. En el caso de modificar un campo hay que hacerlo en todos los registros de todos los ficheros que lo contengan. Inconsistencia de la información por la alta redundancia. Si se deja de actualizar un dato en uno de los archivos donde aparece, la información proporcionada por ese dato se vuelve inconsistente. Aislamiento de los datos. Cada archivo pertenece a un programa y no es posible que éstos sean usados por nuevos programas. Un nuevo programa necesitará su(s) propio(s) archivo(s) de datos que habrán de crearse aunque parte de los datos ya existan en otros archivos de otros programas, contribuyendo a aumentar la redundancia y las consecuencias de ésta.

Imposibilidad de responder a demandas inesperadas de información. Los sistemas tradicionales de archivos son inoperantes para conseguir un sistema de información orientado a la toma de decisiones. Dependencia total entre los programas y la estructura física de los datos. No es posible modificar las características físicas (estructura y métodos de acceso) de los archivos sin afectar a los programas que los usan. Conseguir la independencia entre datos y aplicaciones va a ser uno de los principales objetivos de los sistemas de bases de datos. Surge la necesidad de una gestión más racional del conjunto de los datos que no presente los inconvenientes anteriormente descritos. Surge así un nuevo enfoque que se apoya sobre una base de datos en la que éstos son recogidos y almacenados una sola vez con independencia de los tratamientos que se van a aplicar sobre ellos.

De esta forma, la información contenida en una base de datos está integrada y compartida. Integrada porque puede considerarse como una unificación de varios archivos de datos de los que hemos eliminado la redundancia y compartida porque los programas que antes accedían a los archivos individuales acceden ahora al depósito


11

común de datos, por lo que cada usuario o aplicación tendrá acceso a un subconjunto de los datos y como consecuencia diferentes usuarios verán de formas muy diferentes la misma base de datos. Es importante tener en cuenta que los subconjuntos de datos a los que acceden las diferentes aplicaciones o usuarios no tienen por qué ser disjuntos por lo que usuarios o aplicaciones distintas pueden acceder a la misma parte de la base de datos para utilizarla con propósitos diferentes.

Estructura con un sistema de base de datos:

5. Concepto de Base de Datos

Existen numerosas definiciones de base de datos. Algunas de ellas: · Colección de datos interrelacionados. Elmarsi, R, Navathe, S.B. 1989 · Colección no redundante de datos que son compartidos por diferentes programas de aplicación. Howe, 1983 · Conjunto de datos de la empresa memorizado en un ordenador, que es utilizado por numerosas personas y cuya organización está regida por un modelo de datos. Flory, 1982 · “Una Base de Datos es un conjunto de información almacenada en memoria auxiliar que permite acceso directo , y un conjunto de programas que manipulan esos datos.” · “Una Base de Datos es un conjunto exhaustivo, no redundante de datos estructurados, organizados independientemente de su utilización y su implementación


12

en máquina, accesibles en tiempo real y compartibles por usuarios concurrentes que tienen necesidad de información diferent e y no predecible en el tiempo.” · “Colección o depósito de datos integrados, con redundancia controlada y con una estructura que reflej e las interrelaciones y restricciones existentes en el mundo real ; los datos, que han de ser compartidos por diferentes usuarios y aplicaciones, deben mantenerse independientes a éstas, y su definición y descripción, únicas para cada tipo de dato, han de estar almacenados junto con los mismos. Los procedimientos de actualización y recuperación, comunes y bien determinados, habrán de ser capaces de conservar la integridad, seguridad y confidencialidad del conjunto de los datos.”

5.1. Niveles de abstracción

La mayoría de las aplicaciones son dependientes de los datos; la organización del almacenamiento y los modos de acceso dependen de los requerimientos de la aplicación y el conocimiento de la organización física de los datos y las técnicas de acceso forman parte de la lógica de la aplicación. La aplicación es dependiente de los datos, porque no se puede modificar la estructura de almacenamiento o los modos de acceso sin afecta r a la aplicación. Como hemos visto, los sistemas de bases de datos se plantean los siguientes objetivos: Independencia de la base de datos de los programas para su utilización. Proporcionar a los usuarios una visión abstracta de los datos. El sistema esconde los detalles de almacenamiento físico (cómo se almacenan y se mantienen los datos) pero éstos deben extraerse eficientemente.

5.2. Independencia de los datos:

ANSI: “La independencia de los datos es la capacidad de un sistema para permitir que las referencias a los datos almacenados, especialmente en los programas y en sus descriptores de los datos, estén aislados de los cambios y de los diferentes usos en el entorno de los datos, como pueden ser la forma de almacenar dichos datos, el modo de compartirlos con otros programas y como se reorganizan para mejorar el rendimiento del sistema de Bases de Datos.” Para conseguir esta independencia entre los datos y las aplicaciones es necesario separar la representación física y lógica de los datos, distinción que fu e reconocida oficialmente en 1978, cuando el comité ANSI/X3/SPARC propuso un esqueleto


13

generalizado para sistemas de bases de datos. Este esqueleto propone una arquitectura de tres niveles, los tres niveles de abstracción bajo los que podría verse una base de datos: el nivel interno, el nivel conceptual y el nivel externo.

· NIVEL INTERNO: En él se define la estructura física de la base de datos: dispositivos de almacenamiento físico, direcciones físicas, estrategias de acceso, relaciones, índices, apuntadores, etc. Es responsabilidad de los diseñadores de la base de datos física. Ningún usuario, en calidad de tal , tiene conocimiento de este nivel.

· NIVEL CONCEPTUAL: Contiene el diseño conceptual de la base de datos, que implica el análisis de las necesidades de información de los usuarios y las clases de datos necesarias para satisfacer dichas necesidades. El resultado del diseño conceptual contiene la descripción de todos los datos y las interrelaciones entre ellos, así como las restricciones de integridad y de confidencialidad. · NIVEL EXTERNO: Visión que de la base de datos tiene un usuario o aplicación en particular. Habrá tantas vistas de la base de datos como exijan las diferentes aplicaciones. Las vistas se derivan directamente del esquema conceptual, o de otras vistas, y contienen una descripción de los elementos de datos y sus interrelaciones orientadas al usuario o aplicación y de las que se compone la vista. Una misma vista puede ser utilizada por varias aplicaciones.


14

Esta arquitectura de tres niveles nos proporciona la deseada independencia, que definiremos como capacidad para cambiar el esquema en un nivel sin tener que cambiarlo en ningún otro nivel. Distinguimos entre independencia física y lógica:

· Independencia lógica de los datos: Cambio del esquema conceptual sin cambiar las vistas externas o las aplicaciones. · Independencia física de los datos: Cambio del esquema interno sin necesidad de cambiar el esquema conceptual o los esquemas externos.

5.3. Usuarios de un sistema de Base de Datos. La función de administración

Podemos clasificar en tres clases amplias los usuarios de un sistema de base de datos:

· Por un lado los programadores de aplicaciones, que escriben los programas que utilizan los datos almacenados en la base de datos.

· Por otro los usuarios finales, que interactúan con el sistema a través de las utilidades que éste proporciona para ello.

· En tercer lugar, el administrador del sistema. Es el responsable del control general del sistema desde el punto de vista técnico. Entre sus funciones cabe destacar:

· Definir el esquema conceptual.

· Definir el esquema interno.

· Establecer las restricciones de seguridad, integridad y confidencialidad.

· Definir los procedimientos de copia de seguridad y recuperación.

· Supervisar el rendimiento del sistema y responder a los cambios en los requerimientos.

5.4. El Sistema de Gestión de la Base de Datos

En un sistema de bases de datos, debe existir una capa intermedia entre los datos almacenados en la base de datos, las aplicaciones y los usuarios del mismo. Se trata del Sistema de Gestión de la Base de Datos (SGBD). Actúa de intermediario entre los usuarios y aplicaciones y los datos proporcionando medios para describir, almacenar y manipular los datos, y proporciona herramientas al administrador para gestionar el sistema, entre ellas las herramientas de desarrollo de aplicaciones, generadores de


15

informes, lenguajes específicos de acceso a los datos, como SQL (Structured Query Language) o QBE (Query By Example) (en bases de datos relacionales).

Sistema de Gestión de Base de Datos: Se puede definir como un conjunto coordinado de programas, procedimientos, lenguajes, etc. que suministra, tanto a los usuarios no informáticos como a los analistas, programadores o el administrador, los medios necesarios para describir, recuperar y manipular los datos almacenados en la base, manteniendo su integridad, confidencialidad y seguridad.

Entre sus funciones están:

Definición y control centralizado de los datos. Definición de todos los elementos de datos en la base de datos en los tres niveles de abstracción definidos anteriormente (interno, conceptual y externo). Descripción de los datos (campos, grupos, registros, tablas), interrelaciones entre las diferentes estructuras de datos. Es una parte de la base de datos. La base de datos es autodescriptiva: contiene información que describe su estructura (metadatos), los cuales están disponibles para su consulta. A estos metadatos se les llama Catálogo o Diccionario de datos. Manipulación de los datos: el SGBD debe ser capaz de atender las solicitudes del usuario para extraer, modificar o añadir datos a la base de datos. Seguridad e integridad: Proporciona los medios para definir y gestionar las autorizaciones de acceso, ya sea mediante claves de acceso al sistema, o mediante la definición de vistas externas de usuario. Proporciona así mismo los medios para garantizar la integridad y la consistencia de los datos definiendo (en el diccionario de datos) restricciones sobre los valores que pueden tomar y proporcionando capacidades de recuperación ante fallos y de copia de seguridad.

Garantiza la disponibilidad de la información asegurando el acceso concurrente a varios usuarios simultáneos.

5.5. Ventajas del uso de bases de datos

5.5.1. Reducción de la redundancia

En los sistemas tradicionales de ficheros cada aplicación tiene sus datos privados, lo que provoca una alta redundancia y desaprovechamiento del espacio en disco.


16

La redundancia debe minimizarse y controlarse. Aunque se mantenga cierto grado de redundancia por motivos de rendimiento u otros, el sistema proporciona mecanismos para garantizar la consistencia.

5.5.2. Puede evitarse la inconsistencia

Se controla la redundancia garantizando que los datos redundantes se actualicen de forma automática.

5.5.3. Los datos pueden compartirse

Las necesidades de datos de nuevas aplicaciones pueden atenderse con los ya existentes sin tener que almacenar nuevos datos.

5.5.4. Pueden hacerse cumplir las normas establecidas

Al tener un control centralizado de la base de datos, el administrador (a instancias del responsable de la información de la organización) puede garantizar que se observen las normas de la empresa aplicables a la representación de los datos.

5.5.5. Restricciones de seguridad

El administrador puede asegurar que el único modo de acceso sea a través de los canales establecidos, y en consecuencia definir controles de autorización que pueden afectar a cada modo de acceso (modificación, inserción, borrado o lectura).

Sin estos controles de seguridad, es mucho más sensible una BD que los archivos.

5. 6. Inconvenientes de las Bases de batos

Instalación costosa Necesidad de personal especializado


17

Implantación larga y difícil Falta de rentabilidad a corto plazo Escasa estandarización Desfase entre teoría y práctica


18

TEMA 2: Modelos de datos

1. Introducción

El objetivo de cualquier método de construcción de sistemas software debe ser construir sistemas robustos, fiables, portables y fáciles de mantener. Estos criterios coinciden completamente con lo que se considera una buena práctica de ingeniería. Por tanto, la producción de software debe ser vista como una disciplina de ingeniería en sí misma. En cualquier disciplina de ingeniería se establecen los principios teóricos que derivan en métodos estructurales de análisis, diseño e implementación. Las características genéricas de estas metodologías se han llevado al desarrollo de software mediante la introducción de un conjunto sistemático de procedimientos que van desde la concepción de un sistema mediante el análisis, pasando por su especificación, diseño, implementación, operación y mantenimiento. Dentro de las metodologías convencionales de desarrollo de software, la noción de cómo evoluciona un sistema se representa por el concepto de modelo de ciclo de vida (MCV). El MCV indica el orden en el que las actividades de desarrollo deben ser realizadas. Las fases son, típicamente, especificación de requerimientos, diseño estructural, diseño detallado, implementación, integración y prueba. Cada fase se define en términos de las salidas que produce, las cuales (desde el punto de vista de la dirección) constituyen el criterio objetivo de progreso del desarrollo.

2. Enfoque metodológico

Construir un sistema de software de tipo medio o grande es una tarea que requiere planificación, organización y control. Requiere, además, usar técnicas formalizadas y estructuradas que guíen la realización. Requiere, en tercer lugar, aproximarse al desarrollo de software considerando el proceso completo de producción desde un punto de vista de ingeniería, estructurando el proceso en un conjunto de fases. Requiere, en definitiva, utilizar una metodología que aporte sistemática al propio proceso de construcción. Una metodología añade estructura al proceso de desarrollo mediante tres componentes: 1. Modelo de ciclo de vida (MCV). Un MCV es una abstracción de cómo discurren el desarrollo general de un proyecto así como, internamente, cada una de las fases típicas en que este se divide.


19

2. Métodos y técnicas. Una metodología debe aportar soluciones para afrontar cada fase del ciclo de vida. Estas soluciones consistirán en técnicas y métodos de análisis, de diseño y programación. Si la metodología se basa en el uso de modelos, aportará primitivas para su construcción así como normas y guías de buena modelización. 3. Criterios de progreso. Toda metodología debe aportar criterios objetivos y tangibles de avance del proyecto estableciendo hitos claros de control, especificando los resultados que se deben obtener en cada fase en forma de documentos y/o productos software. Al más alto nivel, todo ciclo de vida de desarrollo engloba actividades de análisis, diseño, implementación, instalación, utilización y mantenimiento, que modernamente se suelen recorrer mediante aproximación iterativa. Las actividades de análisis son, quizá, las más importantes. El objetivo principal del análisis es construir un modelo correcto y preciso de esa parcela del mundo real que se pretende llevar al computador. Ese modelo debe dejar muy claro: a) Cómo es el mudo que se modela; es decir, de qué cosas entenderá el sistema (plantas, animales, empresas, coches, etc.). b) Qué cosas ocurren (o se desea que ocurran) en el mundo; es decir, qué funciones sabrá hacer el sistema (confeccionar pedidos, resolver ecuaciones, diagnosticar enfermedades, etc.). c) Cuándo ocurren las cosas y a quién le ocurren; es decir, cómo se realizan las funciones en el tiempo y bajo qué condiciones, quién las pone en marcha y quiénes se ven afectados por su realización. Las facetas anteriores toman forma mediante sus correspondientes modelos. Respectivamente, modelo de datos, modelo funcional y modelo dinámico.

3. Conceptos y técnicas del modelado

A través de la fase de análisis, el usuario del futuro sistema y el que desarrolla acuerdan de forma precisa lo que el sistema debe saber hacer. ¿Cómo se hace el análisis? Se practica un tipo de análisis denominado "guiado por modelos". Esto significa que para hacer correctamente el análisis han de construirse una serie de modelos, cada uno de ellos capturando una parte del problema que se pretende resolver.


20

3.1. Concepto de modelo

La realidad del mundo que nos rodea es demasiado rica y compleja para la limitada capacidad de percepción y entendimiento del hombre. Ante esta situación, el hombre viene acercándose a la verdad objetiva (la realidad) por vía de simplificarla, eliminando todo lo que en un momento dado pueda considerarse superfluo y capturando lo esencial para sus propósitos. Estamos muy acostumbrados a escuchar frases como: "En condiciones ideales de presión y temperatura..." "En ausencia de rozamiento..." "Asumiendo ausencia de monopolios en el mercado..." Por ejemplo, si se evalúa la solvencia de una persona para concederle un crédito, interesará saber su nivel de ingresos, su patrimonio, etc. pero, con toda probabilidad, no se considerará relevante el tamaño o color de sus ojos (salvo excepciones), ni si su nariz es aguileña o respingona. Ese esfuerzo en capturar lo relevante y eliminar los detalles no significativos para nuestros objetivos, es lo que se conoce como abstracción. El conjunto de abstracciones que conforman una visión parcial, pero útil, de una parte del mundo es lo que se conoce como modelo. Se puede decir, por consiguiente, que el hombre se acerca a la realidad del mundo circundante a base de construir modelos que representan aspectos parciales de la misma. Esto también es aplicable para los productos que el hombre fabrica. Así, antes de la fabricación real de un automóvil, el ingeniero industrial diseñó multitud de modelos del mismo. Otro tanto podría decirse del arquitecto que construye casas, el ingeniero naval que construye barcos y, por supuesto, el ingeniero de software que construye sistemas de información. Todo ingeniero, cuando construye un modelo, utiliza un lenguaje (vocabulario) determinado y unas reglas de construcción de las que no puede salirse. Los elementos que pueden verse en un modelo, junto con las reglas de construcción, constituyen las primitivas de modelización (u ontología). El conjunto de primitivas que uno defina para construir modelos puede ser en cierta forma arbitraria, en todo caso conviene que sea reducido. Al fin y al cabo, sea cual fuere la ontología que se defina, los modelos que a partir de ella se construyan serán siempre incompletos e imprecisos. Lo importante es que sean adecuados y útiles a nuestros objetivos.


21

3.2. Modelos del análisis.

El ingeniero puede llegar a construir tres modelos alineados en tres niveles. Estos modelos, evidentemente, no son independientes ya que representan enfoques distintos de una misma realidad. La siguiente figura muestra la estructura de niveles y modelos. Cada nivel se ocupa de un tipo de conocimiento entre los que se necesitan para responder a las grandes preguntas del análisis: ¿Qué hay en el mundo (dominio)?, ¿Qué ocurre en el mundo (funcional)?, ¿Cuándo cambia el mundo (control)?

3.2.1. Modelo a nivel del dominio

El nivel del dominio busca modelar el conocimiento de tipo estático identificando, en el mundo del que va a entender el sistema, verdades de tipo universal (axiomas) referentes a los objetos presentes en el dominio, sus características relevantes y las relaciones y dependencias entre ellas. En el siguiente apartado se estudiará la forma de modelar a nivel del dominio. Baste, por ahora, con algunos ejemplos de afirmaciones típicas en diferentes dominios, expresados en lenguaje natural:


22

· "(en el dominio de la empresa) hay empleados, funciones y departamentos. Todo empleado tiene asignada alguna función y pertenece a un departamento. Toda función ha de ser desempeñada por alguien. A veces, incluso, por más de un empleado. Hay distintas categorías de empleado y todo empleado tiene derecho a percibir una remuneración acorde con su categoría..." · "(en el dominio de las casas distribuidoras de vehículos) hay vehículos, de distintas marcas, modelos y niveles de equipamiento. Cada vehículo, según los parámetros anteriores, tiene asociado un precio base, que puede variar según la fórmula de pago elegida por el cliente y la estrategia comercial -descuentos, ofertas, etc.- del distribuidor. No toda fórmula de pago es admisible para cualquier cliente, pues ello depende de si es un cliente antiguo, su capacidad económica, etc." · "(en el dominio de la física dinámica) hay cuerpos en movimiento. Un cuerpo se caracteriza por tener masa y velocidad y ocupar una posición en el espacio. La cantidad de movimiento de un cuerpo es proporcional a su masa y su velocidad, y es constante siempre que el movimiento sea no acelerado..." · "(en el dominio de la banca) hay clientes que solicitan créditos. Conceder un crédito es una operación con riesgo, que requiere estudio antes de su aprobación. Esto depende en gran medida de la cuantía de la operación y de ciertas características del cliente. Hay muchos perfiles de cliente, unos más adecuados que otros de cara a asumir riesgos. En todo caso, no es fácil decidir cuál es el perfil de un cliente, ya que este puede poseer características de varios de los perfiles considerados..." · "(en el dominio de una cuenca hidrológica) hay zonas de lluvia, que son superficies donde se asume comportamiento meteorológico uniforme. Asimismo, hay áreas receptoras de lluvia, que son superficies con un único punto de drenaje a una red de transporte de aguas. Las redes de transporte se componen de cauces de muchos tipos pero, básicamente, los hay de régimen rápido y régimen lento. Los primeros tienen pendientes altas y alta velocidad de transporte del agua; los segundos tienen bajas pendientes y baja velocidad de transporte, se sitúan en los tramos finales de las cuencas y, ante un caudal importante, tienen mayor riesgo de desbordamientos..."


23

3.2.2. Modelo funcional

El modelo funcional describe aquellos aspectos del sistema relativos a las transformaciones que puede sufrir la información contenida en el dominio. Se trata de capturar lo que el sistema ha de hacer, sin considerar cuándo o cómo lo hará.

3.2.3. Modelo dinámico

El modelo dinámico describe los aspectos del sistema relativos al tiempo, capturando el control del sistema: cuándo ocurren los cambios en el sistema, sin especificar en qué consisten esos cambios (aspecto funcional) ni cómo son implementados.

3.2.4. Relaciones entre los modelos.

De todos los niveles del análisis, el nivel del dominio es el que recoge el conocimiento más profundo sobre un tema. Si nos propusiéramos realizar un análisis de todo el saber humano, una gran parte del conocimiento científico se recogería a este nivel. El resto de los niveles buscan sacar partido del modelo del dominio, de manera que nos sea útil (o sea, responder a la pregunta ¿qué hacemos con el conocimiento del dominio para resolver nuestro problema?). Lo que aquí nos interesa es la forma de representar los datos en el modelo del dominio y concretamente qué modelos de datos disponemos para representar esos datos en un sistema de base de datos.

4. El nivel del dominio: Modelos de datos.

· Modelo. Def. (Diccionario de la Lengua Española) Esquema teórico, generalmente en forma matemática, de un de un sistema o de una realidad compleja (por ejemplo, la evolución económica de un país), que se elabora para facilitar su comprensión y el estudio de su comportamiento. · Vigésima Edición, 1984. · “Modelar” consiste en definir un mundo abstracto y teórico tal que las conclusiones que se puedan sacar de él coinciden con las manifestaciones aparentes del mundo real.


24

· “Modelo”: conjunto de conceptos que permiten construir una representación organizacional de la empresa. · “Modelo de datos” es un dispositivo de abstracción que nos permite ver el bosque (la información contenida en los datos) en oposición a los árboles (valores individuales de los datos). Modelo: Instrumento que se aplica a una parcela del mundo real (Universo del Discurso) para obtener una estructura de datos a la que denominamos esquema.

MODELO à Instrumento ESQUEMA à Resultado de aplicar el instrumento

El primer paso en el diseño de una Base de Datos es definir el Universo del Discurso fijando una serie de objetivos sobre el mundo real.

Definición de Modelo de Datos: Conjunto de conceptos, reglas y convenciones que nos permiten describir los datos del universo del discurso, constituyendo una herramienta que facilita su interpretación y su representación en forma de datos en nuestro sistema de información. Los Modelos de Datos son la base para los lenguajes de datos. El nivel de abstracción de los lenguajes de datos es menor, ya que son el modelo más una sintaxis:

L.D. = M.D. + Sintaxis El lenguaje puede venir tanto del modelo como de la sintaxis:

SQL = Modelo Relacional + Sintaxis DL/I = Modelo Jerárquico + Sintaxis

Objetivos de todo modelo de datos: a) FORMALIZACIÓN: Permite definir formalmente las estructuras permitidas y sus restricciones a fin de representar los datos, y también porque establece las bases para un lenguaje de datos.


25

b) DISEÑO: El modelo de datos es uno de los elementos básicos en el diseño de una Base de Datos. Propiedades del Universo del Discurso: · Estáticas (estructuras) · Dinámicas (datos o valores que se almacenan en las estructuras) Componentes de todo Modelo de Datos: Estática Objetos permitidos Restricciones

Inherentes De usuario

Dinámica Selección <condición>

Navegacional Especificación

Acción <Objetivo> Recuperación (previa selección) Actualización Modificación Inserción Borrado

4.1. Definición formal de modelo de datos

Propiedades del Universo del Discurso: · Invariantes en el tiempo (ESTÁTICAS) à Estructuras. · Varían en el tiempo (DINÁMICAS). Datos o valores que se almacenan en esas estructuras.

MD = <S,O>

S = Conjunto de reglas de generación que permiten representar la componente estática, es decir las estructuras del Universo del Discurso. Se corresponde con el Lenguaje de Definición de Datos. O = Conjunto de operaciones autorizadas sobre la estructura que permite representar la componente dinámica. Se corresponde con el Lenguaje de manipulación de datos.


26

4.1.1. Componente estática

Está compuesta por: I. - Objetos permitidos. I I. - Restricciones.

I. - Varían mucho de unos modelos a otros. En general son:

Entidades Atributos Dominios sobre los que se definen los atributos Interrelaciones (asociaciones entre los objetos)

I I. - No todas las estructuras están permitidas. Existen restricciones que invalidan ciertos objetos o asociaciones entre ellos.

· Inherentes: Impuestas por la misma naturaleza del modelo que no admite ciertos objetos o asociaciones. Introduce rigideces a la hora de modelar.

· De usuario: Permiten captar la semántica del Universo del Discurso que se quiere modelar. Facilitan la labor del diseñador.

La aplicación de la parte estática de un modelo a un UD. da como resultado un ESQUEMA o estructura de datos que representa dicho UD. en el correspondiente modelo.

4.1.2. Componente dinámica

Los valores que toman los distintos objetos de un esquema en un momento determinado ti se llaman OCURRENCIA del esquema o Base de datos en ti (BDi). En otro momento tj la ocurrencia será, en general, distinta. Se puede haber modificado la Base de Datos. La componente dinámica del modelo consta de un conjunto de operaciones que se definen sobre la estructura del correspondiente modelo de datos (no todas las estructuras admiten las mismas operaciones). La aplicación de una operación a una ocurrencia de un esquema transforma a ésta en una ocurrencia distinta:

O(BDi) = BDj


27

Tipos de operaciones:

SELECCIÓN ACCIÓN

SELECCIÓN: Localizar una ocurrencia indicando un camino (sistema NAVEGACIONAL) o un conjunto de ocurrencias especificando una condición (ESPECIFICACIÓN). ACCIÓN: sobre las ocurrencias previamente localizadas. Puede consistir en: Recuperación o Actualización. Se puede expresar:

SELECCIÓN <CONDICIÓN> ACCIÓN <OBJETIVO>

La distinción SELECCIÓN - ACCIÓN es de tipo formal, aunque algunos lenguajes, como D L / I, tienen verbos distintos para cada operación. SQL reúne ambas operaciones en una única sentencia. Modelos

Conceptual (Lógico) ME/R

Convencional (Físico) Red Jerárquico Relacional

El presente apartado pretende dar una visión general de los modelos en red y jerárquico, los cuales, si bien están hoy ampliamente superados por el modelo relacional, han gozado de gran popularidad durante muchos años y han sido de gran importancia para el desarrollo de la tecnología de bases de datos.

5. Antecedentes históricos.

Las redes constituyen una manera natural de representar las interrelaciones entre diferentes objetos. Se utilizan ampliamente en las matemáticas, la investigación operativa, la física, la química y otros campos. Como los objetos y sus interrelaciones constituyen maneras útiles de modelar muchos de los fenómenos que nos conciernen en los negocios, no es sorprendente que el modelo de datos en red se aplique también a la organización de bases de datos.


28

De manera general, las redes pueden representarse mediante una estructura matemática denominada grafo orientado. Estos grafos orientados tienen una estructura simple: se construyen mediante nodos conectados por arcos orientados o aristas. En el contexto de los modelos de datos, los nodos pueden considerarse como tipos de registros de datos y las aristas pueden considerarse como las interrelaciones entre ellos. La estructura de grafo facilita la representación simple de todo tipo de interrelaciones entre los datos (jerárquicas, de pertenencia, etc.). Esta representación, que no impone en principio ninguna restricción ni al tipo ni al número de los arcos, permite el modelado de estructuras de datos tan complejas como se desee. Además, una vez que se ha establecido una relación entre dos objetos, la recuperación y la manipulación de los datos asociados puede realizarse eficientemente. El modelo en red general es muy flexible debido a la inexistencia de restricciones inherentes, pero por esa misma razón su implementación e instrumentación en el nivel físico resulta difícil y poco eficiente. Debido a esto, al llevar a la práctica modelos basados en red se introducen restricciones para facilitar su implementación que se hacen más restrictivas en el modelo jerárquico. Como se verá más adelante, una jerarquía es un caso particular de una red. En consecuencia, el modelo de datos jerárquico es un caso particular del modelo en red. Aunque el modelo de datos jerárquico precede cronológicamente al modelo en red, nos parece adecuado discutir éste en primer lugar por ser más general. La organización no oficial Conference on Data Systems Languages (CODASYL), formada por representantes de fabricantes de hardware, fabricantes de software y los principales usuarios (entre los que se encontraban miembros de varios departamentos del gobierno de Estados Unidos), inicialmente desarrolló y normalizó el lenguaje COBOL (Common Business Oriented Language) a principios de la década de los 60. En 1965 se crea dentro de CODASYL el List Processing Task Force, dedicado a estudiar las capacidades del proceso de listas para el lenguaje COBOL. Dos años más tarde, este grupo cambió su nombre por Data Base Task Group (DBTG) haciendo notar el creciente interés que despertó hacia mediados y finales de los años sesenta el desarrollo de normas y estándares para los sistemas de bases de datos. Este subgrupo estaba fuertemente influido por la arquitectura utilizada para el primero de los Sistemas de Gestión de Bases de Datos (SGBD): el Integrated Data Store (IDS) construido por uno de sus integrantes, C.W. Bachman, para la compañía General Electric. Bachman propuso la estructura de datos propia del modelo CODASYL y los diagramas que llevan su nombre. Esta influencia se aprecia en las recomendaciones para un modelo en red que aparecen publicadas en un informe preliminar en 1969. El informe recogía la especificación de la sintaxis y semántica de un lenguaje de definición de datos (LDD) que permitía la descripción de una base de datos y un


29

lenguaje de manipulación de datos (LMD) que se configuró como extensión de un lenguaje anfitrión para el manejo (recuperación y actualización) de los datos almacenados en la base de datos. Este lenguaje de manipulación se proponía dar respuesta a las necesidades de gestión de datos para cualquier tipo de lenguaje anfitrión (en teoría) pero en la práctica, su orientación a COBOL era evidente. En las propuestas de este informe, se definía una arquitectura de base de datos a dos niveles (esquema y subesquemas), lo que dificultaba conseguir la independencia física/lógica deseable en un sistema de base de datos. Este aspecto, junto con la orientación al COBOL, fueron los más criticados. Este primer informe dio lugar a numerosas sugerencias para su perfeccionamiento y se publicó un informe oficial revisado en 19713 que se sometió a la consideración del American National Standards Institute (ANSI) para su posible adopción como norma nacional para los SGBDs. La organización ANSI no realizó acción alguna al respecto pues estaba desarrollando su propia recomendación, y los informes modificados publicados en 1978 y 1981 sucedieron al informe de 1971. El informe de 1978 propone una nueva arquitectura a tres niveles que consigue una mayor independencia física/lógica, coincidiendo con la publicación de los resultados de los trabajos del comité ANSI para bases de datos que proponían la conocida arquitectura a tres niveles. A pesar de su carácter no oficial, los informes y normas de CODASYL obtuvieron una amplia difusión y respaldo debido en gran medida al apoyo que obtuvieron por parte del Departamento de Defensa de los Estados Unidos. El grupo CODASYL se disolvió en el año 1983 debido a que la organización oficial ANSI estaba trabajando sobre una propuesta de lenguaje de datos para modelos en red, culminando éstos con su recomendación NDL/ANS de un lenguaje normalizado de datos en red. La existencia de varias versiones de los lenguajes CODASYL ha ocasionado que las diferencias entre ellas se vieran reflejadas en los diferentes productos que, en general, se desviaban en mayor o menor medida de las recomendaciones, así como en la bibliografía al respecto, que no coincide al presentar la sintaxis de los lenguajes CODASYL. Sin embargo, el documento de 1971 permanece como la proposición fundamental del modelo en red, que se convirtió en el modelo CODASYL, de DBTG y que ha servido de base para el desarrollo de los SGBD en red de diferentes fabricantes, entre los que destacan el IDS (Honeywell) y el IDMS (Computer Associates) como dos de las implementaciones comerciales más conocidas. Si bien es verdad que en la actualidad los SGBD basados en los modelos de tipo red ya no dominan el mercado como ocurría hace unos años, también es cierto que todavía hay bastantes instalaciones con sistemas jerárquicos y CODASYL que están respondiendo con eficiencia a las necesidades de los usuarios [DEMIG97].


30

6. El modelo en red CODASYL

Como en todo modelo de datos, distinguiremos sus componentes estática y dinámica. En el esquema se describen los aspectos estáticos, es decir, la parte estructural de los datos (tipos de entidades, tipos de interrelaciones, etc.), representadas, como ya se ha indicado, en forma de grafo. En cuanto a la dinámica, los modelos en red se caracterizan por ser navegacionales, es decir, la recuperación y la actualización de la base de datos se lleva a cabo registro a registro, y procedimentales, es decir, asumen el conocimiento de la estructura interna de la base de datos por parte del programador.

6.1. Correspondencia del modelo en red con la arquitectura de tres niveles de ANSI/X3/SPARC

La correspondencia de la arquitectura de tres niveles del grupo ANSI/X3/SPARC con el modelo en red de CODASYL es como se indica a continuación: · El nivel conceptual se denomina esquema. · El nivel externo se denomina subesquema. · El nivel interno está implícito en la implementación.

6.2. COMPONENTE ESTÁTICA. REGISTROS Y CONJUNTOS.

Hay dos estructuras de datos fundamentales en el modelo en red: los tipos de registros y los conjuntos. Los tipos de registros se definen habitualmente como colecciones de elementos de los datos lógicamente relacionados. Por ejemplo, el tipo de registro de un cliente podría incluir los elementos de datos siguientes: Identificador del cliente, Nombre del cliente, Dirección. El registro está a su vez compuesto de campos o elementos de datos que es la unidad de datos más pequeña a la que se puede hacer referencia en el modelo CODASYL. Un tipo especial de campo es el agregado de datos, que consiste en un vector con un número f i jo de elementos, como por ejemplo la fecha, compuesta de día, mes y año. Un conjunto expresa una interrelación uno a muchos, o uno a uno entre dos tipos de registros. En el modelo CODASYL, el conjunto constituye el elemento básico para la representación de las interrelaciones. Por medio de los conjuntos se establecen asociaciones 1:N (las asociaciones 1:1 son un caso particular de las 1:N) a dos niveles, en las que el nodo raíz se denomina propietario y los nodos dependientes se denominan miembros.


31

PROPIETARIO

MIEMBRO

Puede definirse un tipo de conjunto especial denominado conjunto singular en el que el propietario sería ficticio (el sistema) y el miembro el tipo de registro cuyas ocurrencias se quieren encadenar. De esta forma, tendríamos las ocurrencias de un registro como si se trataran de un fichero tradicional con estructura de lista circular. Las características generales del modelo en red CODASYL pueden resumirse en las siguientes: · Un conjunto es una colección nominada de dos o más tipos de registros que representa una interrelación 1:N (recuérdese que las interrelaciones 1:1 son un caso particular de las 1:N) · Cada conjunto debe tener obligatoriamente un tipo de registro propietario y uno o más registros miembros. · Pueden existir conjuntos singulares en los que el propietario es el sistema. · No existe ninguna limitación en cuanto al número de conjuntos que pueden definirse en el esquema. · Cualquier registro puede ser declarado propietario de uno o varios conjuntos. · Cualquier registro puede ser declarado miembro de uno o varios conjuntos. · Cualquier registro puede ser declarado propietario en un conjunto y miembro en otro conjunto distinto. · Aunque un tipo de registro se haya declarado miembro de un conjunto, existe la posibilidad de no encadenar en el conjunto ciertas ocurrencias del mismo, las cuales no pertenecerán a ningún propietario, es decir, quedarán sueltas respecto a ese conjunto. En la siguiente figura se muestra el diagrama de Bachman de una base de datos en la que se recoge información acerca de vendedores, clientes, albaranes y artículos:


32

Una ocurrencia de la base de datos anterior podría ser la que se muestra en la siguiente figura:

6.3. RESTRICCIONES INHERENTES AL MODELO CODASYL

Están vinculadas al concepto de conjunto y son las siguientes: · Sólo se admiten tipos de interrelaciones jerárquicas a dos niveles: nivel propietario y nivel miembro. Las jerarquías multinivel y las estructuras en red se consiguen combinando varios conjuntos. · En el nivel propietario de un conjunto sólo se permite un tipo de registro. · Una misma ocurrencia de un registro miembro no puede pertenecer en un conjunto a más de un propietario.


33

6.4. DINÁMICA DEL MODELO CODASYL

La componente dinámica de un modelo de datos es el conjunto de operaciones que, aplicadas a un estado de la base de datos, la transforman en otro estado distinto. El lenguaje de manipulación de datos de CODASYL es de tipo navegacional (opera registro a registro), procedimental (requiere el conocimiento de la estructura física de la base de datos por parte del programador) y tiene que estar embebido en un lenguaje de programación anfitrión. Como característica importante, destacar que en él se distingue la localización o selección de la acción (recuperación o actualización). La navegación por la base de datos se lleva a cabo apoyándose en los indicadores de registro activo, concepto fundamental en la componente dinámica del modelo CODASYL. Puede encontrarse una descripción muy completa de los lenguajes CODASYL en [DEMIG93] y en [DATE93].

7. EL MODELO JERÁRQUICO

Veremos ahora el modelo jerárquico como un caso particular del modelo en red. Aunque los productos basados en este modelo han perdido cuota de mercado y se consideran altamente superados por la tecnología relacional, aún persisten muchas aplicaciones basadas en este modelo [DEMIG97], [HANSEN97]. Al igual que los modelos en red, los modelos jerárquicos se encuentran entre los primeros modelos utilizados en SGBD comerciales, desarrollados a principios de la década de los 60. Las estructuras en árbol, muy extendidas en la informática para representar estructuras de datos, tienen como característica su poca flexibilidad, lo que origina la falta de adaptación a muchas situaciones reales. Aunque nunca se ha llegado a una formalización matemática del modelo ni de sus lenguajes, como ocurre con el modelo relacional, ni tampoco se ha pretendido su estandarización como sucedió con CODASYL, los productos basados en el modelo jerárquico alcanzaron altas cuotas de mercado y aunque actualmente están superados por la tecnología relacional, persisten importantes aplicaciones soportadas en estos productos trabajando muy eficientemente en grandes sistemas de transacciones dirigidas que requieren respuestas rápidas, siempre que las aplicaciones desarrolladas sobre ellos se mantengan sin apenas cambios. Una razón complementaria para la persistencia de los sistemas basados en el modelo jerárquico es que muchas estructuras son inherentemente jerárquicas. Por ejemplo, una universidad puede


34

tener departamentos (primer nivel) los departamentos tienen profesores (segundo nivel) y los profesores imparten asignaturas (tercer nivel). Aunque la anterior estructura de datos podría representarse mediante un modelo en red, más robusto en cuanto a la capacidad de representación, la complejidad del sistema sería muy superior a la necesaria. Esta fue una de las razones que movió al desarrollo del modelo jerárquico, como se describe más adelante. Debido a la inexistencia de formalización y estándares, su estudio requiere el examen de los SGBD empleados en la práctica. Afortunadamente, las implementaciones de sistemas de bases de datos jerárquicas están dominadas por un sistema: el IMS (Information Management System) de IBM, con su lenguaje de datos DL/I (Data Language/One). De hecho, es el único que ha sobrevivido hasta nuestros días [DEMIG97] y [DATE93]. Sin embargo se han usado (y según [HANSEN97] aún se usan) otros sistemas jerárquicos, incluyendo TDMS (Time-Shared Data Management System, de System Development Corporation), MARK IV (Multi-Access Retrieval System, de Control Data Corporation) y System 2000 (SAS Corporation). El sistema IMS se desarrolló como fruto de un esfuerzo conjunto entre IBM y North American Aviation (posteriormente convertida en Rockwell) para desarrollar un SGBD para dar soporte al proyecto Apolo (uno de los mayores proyectos de ingeniería acometidos en aquellos tiempos). Un factor clave en el desarrollo de IMS fue la necesidad de manipular millones de piezas que se relacionaban unas con otras según una estructura jerárquica: las piezas más pequeñas se usaban para construir montajes más grandes que a su vez se empleaban como componentes de módulos más grandes y así sucesivamente. A su vez, esta estructura jerárquica permitía conocer con exactitud y rapidez la estructura de una pieza. En la bibliografía, las exposiciones sobre el modelo jerárquico invariablemente incorporan la terminología y las convenciones propias de IMS, de modo que nosotros no nos alejaremos de esta tendencia. La implementación física del modelo jerárquico se basa en apuntadores. La estructura física (organización y tipo de punteros) varía de un producto a otro, incluso un mismo producto (IMS) proporciona diferentes organizaciones físicas con el fin de que el diseñador pueda obtener la mayor eficiencia en el diseño físico de la base de datos.

7.1. Características de la estructura jerárquica

En el modelo jerárquico, el esquema es una estructura en forma de árbol compuesta por nodos, que representan las entidades, conectados por arcos, que representan las


35

interrelaciones entre esas entidades. En terminología IMS, los nodos se llaman segmentos. Como ya se ha apuntado, la estructura de datos jerárquica es un caso particular de la del modelo en red, con importantes restricciones adicionales derivadas del hecho de que las asociaciones en el modelo jerárquico deben formar un árbol ordenado, es decir, un árbol en el que el orden de los nodos es importante. La siguiente figura muestra un ejemplo de este tipo de organización: A B E G C D F H IJ Una estructura jerárquica tiene las siguientes características: · El árbol se organiza en un conjunto de niveles. · El más alto de la jerarquía es el nodo raíz. · Los arcos que unen los nodos representan las asociaciones jerárquicas entre dos entidades y no tienen nombre (a diferencia del modelo en red CODASYL). No es necesario, ya que entre dos conjuntos de datos sólo puede existir un tipo de interrelación. · Un nodo de nivel superior (nodo padre) puede tener un número ilimitado de nodos hijos, pero un nodo hijo sólo puede tener un único nodo padre. · Todo nodo, a excepción del raíz, ha de tener obligatoriamente un padre. · Llamamos hojas a los nodos que no tienen descendientes. · Al número de niveles de la estructura jerárquica se le llama altura del árbol. · Al número de nodos del árbol se le llama momento. · Sólo están permitidas las estructuras de tipo 1:N (las de tipo 1:1 son un caso particular de las 1:N). · Cada nodo no terminal y sus descendientes forman un subárbol, de modo que un árbol es una estructura recursiva. En el modelo jerárquico el árbol se recorre en preorden: primero el subárbol izquierdo y después el subárbol derecho.


36

7.2. Restricciones inherentes al modelo jerárquico

Las restricciones en el modelo jerárquico son más severas que en el modelo en red por tratarse de un caso particular de éste: · No pueden representarse directamente relaciones N:M ni reflexivas. · No se admite más de una relación entre dos segmentos. · No puede existir un segmento hijo con más de un padre. · El árbol debe recorrerse siempre en preorden. · Cualquier acceso a la base de datos debe comenzar necesariamente en el segmento raíz.

7.3. Correspondencia del modelo jerárquico de ims con la Arquitectura de tres niveles de ansi/x3/sparc

La correspondencia de la arquitectura de tres niveles del grupo ANSI/X3/SPARC con el modelo jerárquico de IMS es como se indica a continuación: · El nivel conceptual se compone de un conjunto de árboles definidos mediante una estructura denominada Data Base Description (DBD). · El nivel externo se compone de subconjuntos de los árboles definidos en el nivel conceptual. · El nivel interno está implícito en la implementación. IMS gestiona un conjunto de árboles, cada uno de ellos definido mediante una DBD. El conjunto de todas las DBDs definidas en una base de datos constituye el nivel conceptual. Las diferentes aplicaciones accederán a una parte de la base de datos. Cada uno de los subesquemas del nivel externo en IMS se llama base de datos lógica. Cada una de ellas estará compuesta por determinados segmentos de uno o varios árboles. La parte de la base de datos lógica que afecta a cada uno de los árboles se define mediante una estructura denominada. Program Control Block (PCB). El agrupamiento de los PBCs para formar una base de datos lógica forma un Program Specification Block (PSB). De esta forma, dentro de un PSB para definir una base de datos lógica habrá tantos PCBs como árboles del nivel físico participen en esa “vista” del nivel externo.


37

7.4. La manipulación de los datos

El acceso a los datos en IMS se realiza a través de su LMD, D L / I. A igual que ocurre con el sistema en red, es un lenguaje navegacional (un solo registro cada vez), procedimental (implica el conocimiento de la estructura jerárquica por parte del programador) y de tipo huésped (se embebe dentro de un lenguaje anfitrión). Puede encontrarse un análisis muy completo de DL/I en [DEMIG93] y en [DATE93].

8. Los modelos en red y el modelo relacional

Analizaremos, para finalizar, las principales diferencias entre los modelos en red y el modelo relacional, empezando por su origen. Los modelos no relacionales no se desarrollaron con base en ningún modelo abstracto de datos predefinido. Por el contrario, los modelos que existen se definieron a posteriori por un proceso de abstracción o inducción a partir de las implementaciones ya existentes. El modelo relacional fue el primer ejemplo de modelo de datos definido antes de cualquier implementación. Los sistemas relacionales fueron los primeros que se construyeron de acuerdo con los preceptos de un modelo de datos predefinido. El modelo en red fue el fruto del intento de establecer estándares detallados para sistemas de bases de datos. El modelo jerárquico surgió de la necesidad de resolver un problema concreto.

8.1. Representación de los datos.

Una diferencia importante entre el modelo de datos en red y el relacional es la manera en que se representan las interrelaciones. En el modelo relacional, los enlaces entre dos relaciones se establecen incluyendo un atributo definido sobre el mismo dominio en ambas relaciones. Las filas que están lógicamente relacionadas tendrán en cada relación los mismos valores para ese atributo. En el modelo en red CODASYL la cardinalidad 1: N entre dos tipos de registros se establece mediante la definición explícita del tipo de conjunto. Es entonces cuando el SGBD conecta los registros en cada tipo de conjunto mediante punteros físicos. Esto significa que los registros se conectan físicamente cuando participan en la misma ocurrencia de un conjunto. Esta representación explícita de los tipos de conjunto se ha considerado como una ventaja del modelo en red. Un argumento a tener en cuenta es


38

que el modelo en red utiliza dos elementos de modelado: el tipo de registro y el tipo de conjunto, mientras que el modelo relacional utiliza un único concepto: la relación.

8.2. Lenguaje de manipulación de datos.

Los sistemas no relacionales están en un nivel de abstracción mucho más bajo que los relacionales. Las operaciones de navegación y de recuperación del LMD (Lenguaje de Manipulación de Datos) de los modelos en red se efectúan sobre registros individuales (lenguaje de tipo navegacional), en contraste con las operaciones del modelo relacional que se efectúan sobre relaciones completas (lenguaje de especificación). Estas operaciones deben estar inmersas en un lenguaje de programación anfitrión, es decir es un lenguaje de tipo huésped. Los LMD relacionales pueden utilizarse directamente o pueden estar embebidos en un lenguaje anfitrión. Como las operaciones de manipulación orientadas a los registros se basan en las operaciones tradicionales de procesamiento de archivos, el programador debe estar íntimamente familiarizado con las características de almacenamiento y los modos de acceso (es un lenguaje muy procedimental). Los modelos de datos de los sistemas no relacionales pueden verse como abstracciones de algunas de las estructuras de almacenamiento subyacentes y sus operadores asociados, por lo que son, en general, sistemas de programación; el usuario primario es un programador que utiliza un lenguaje tipo COBOL y necesita navegar de manera manual en la base de datos. Cualquier optimización la debe realizar el programador, no el sistema [DATE93]. En el modelo relacional el LMD es muy poco procedimental, es decir, el usuario nada tiene que saber acerca de la organización interna de los datos ni de los modos de acceso. Esta ventaja del modelo relacional sobre el modelo en red se confirma por la adición al IDMS de un interfaz de usuario de tipo relacional, convirtiéndolo en IDMS/R. Esto dio lugar a la popularización de los interfaces de usuario relacionales en sistemas no relacionales lo que a su vez provocó la publicación de las doce reglas de Codd.

8.3. Restricciones de integridad

El modelo en red CODASYL proporciona un conjunto básico de restricciones de integridad, en particular para proteger la integridad de los conjuntos, que permiten al diseñador determinar cómo se deben comportar los registros propietarios respecto a


39

los miembros y viceversa. Otros tipos de restricciones semánticas sólo pueden implementarse en el programa de aplicación, lo que dificulta gravemente el mantenimiento de dichas restricciones semánticas. En un sistema relacional, la mayoría de las restricciones semánticas pueden ser recogidas por el SGBD, asegurando su cumplimiento por cualquier programa de aplicación.

8.4. Implementación

Los sistemas en red son especialmente convenientes para sistemas de bases de datos en los que se requieran características como: · Gran tamaño. · Consultas repetitivas bien definidas. · Transacciones bien definidas. · Aplicaciones bien definidas. Si concurren todos estos factores, un sistema en red es una buena solución. Por el contrario, las futuras necesidades de información que requieran consultas no definidas a la base de datos pueden requerir una reorganización de la base de datos con un alto grado de dificultad. Los sistemas relacionales tienen clara ventaja en este aspecto, pues las demandas inesperadas de información pueden satisfacerse sin modificación alguna en la estructura interna de la base de datos, simplemente definiendo un nuevo subesquema en el nivel externo.


40

TEMA 3: Diseño Conceptual: Modelo Entidad/Interrelación

1. Presentación e historia del modelo

El modelo Entidad/Interrelación fue desarrollado por Peter Chen en el año 1976 ([CHEN76] y [CHEN77]) y, a pesar del tiempo transcurrido desde su presentación, es un modelo de datos de plena actualidad en el ámbito de la ingeniería en informática y, más concretamente, en el campo del diseño de bases de datos. ¿Cuál es entonces la clave de su éxito? Inicialmente podría esgrimirse como argumento el hecho de que este nuevo modelo de datos intenta aglutinar las ventajas de cada uno de los modelos de datos anteriores: modelo en red, modelo jerárquico y modelo relacional. Sin embargo, el argumento anterior no justifica totalmente la utilidad del Modelo Entidad/Interrelación que lo ha convertido, por ejemplo, en un modelo valido para el diseño de Bases de Datos Orientadas a Objetos, ámbito éste tan moderno que no era previsible que un modelo de datos con veinte años de antigüedad pudiera ser utilizado, pese a sus evoluciones, en este nuevo campo de aplicación de los sistemas de información. Para completar la respuesta a la pregunta anterior debemos argumentar que su potencia para representar prácticamente todas las restricciones posibles del diseño de datos, junto con su flexibilidad para admitir la evolución en el tiempo del sistema de información diseñado, son un combinado ideal para justificar tal éxito. Una segunda pregunta a resolver sería: ¿Por qué es necesario un nuevo modelo de datos? En este caso, la respuesta hay que buscarla en el cambio sufrido en el proceso de desarrollo de los sistemas de información a finales de los años 60, principios de los 70. Inicialmente, el proceso de desarrollo de sistemas de información estaba centrado en el análisis y diseño de los tratamientos a realizar, dejando en un segundo plano el análisis y diseño de los datos. El cambio fue la respuesta a la constatación de una realidad que se daba en todos los sistemas de información desarrollados: Los datos como estructura son más duraderos que los tratamientos. Expresado en otros términos, el sistema de información de una determinada organización permanece casi invariable en lo que a sus datos de interés se refiere, mientras que es cambiante en el tratamiento dado a los datos.


41

Por tanto, podemos asegurar que el Modelo Entidad/Interrelación es la consecuencia de la necesidad de aportar soluciones al problema anteriormente mencionado. Para ello el Modelo Entidad/Interrelación percibe el mundo real como una serie de objetos relacionados entre sí y pretende representarlos gráficamente, mediante un determinado mecanismo de abstracción. Este mecanismo de abstracción está basado en una serie de símbolos, reglas y métodos que nos permitirán representar gráficamente los datos de interés del mundo real. Es decir, el Modelo Entidad/Interrelación fue creado como una metodología gráfica para diseño de bases de datos. Ahora bien, podría considerarse que el modelo E/R es un modelo intuitivo por el hecho de basarse en la representación gráfica de los objetos y asociaciones del mundo real. Sin embargo no debemos olvidar que este modelo nació como una generalización de los tres modelos de datos existentes en ese momento, intentando dar una visión más uniforme de los datos y mantener las ventajas de cada uno de dichos modelos. De hecho, el modelo E/R permite una visión más natural de los datos, separando los objetos de sus asociaciones (al igual que el Modelo en Red), mantiene un alto grado de independencia de los datos respecto a los tratamientos (al igual que el modelo Relacional), y establece un cierto nivel de dependencia o jerarquía entre los distintos elementos componentes del Modelo (al igual que el Modelo Jerárquico). Además, el Modelo E/R aporta un mayor contenido semántico sobre el universo objeto de estudio que cualquiera de los otros tres modelos de datos mencionados. Por último, conviene destacar otra característica del modelo E/R derivada de su orientación al diseño de datos del sistema de información de una organización: vamos a realizar el diseño lógico de la base de datos ignorando consideraciones de almacenamiento físico de los datos y de eficiencia de los tratamientos. Es decir, el diseño que vamos a realizar mediante el Modelo E/R es desde todo punto de vista asimilable al esquema conceptual definido para la arquitectura ANSI/X3/SPARC. La diferencia radica en su función: El diseño obtenido no es el nexo de unión entre el mundo del usuario (esquema externo), y el mundo del computador (esquema interno), aunque a partir del mismo se puedan definir ambos. Solamente es una representación de las propiedades lógicas de los datos del universo objeto de estudio y, por tanto, dicha representación no es accesible directamente por el SGBD. Es un método de representación abstracta del mundo real centrado en las restricciones o propiedades lógicas de una base de datos. Por tanto, no es directamente implantable en un SGBD, sino que necesita una transformación a las estructuras de datos del modelo de datos propio de dicho SGBD.


42

En un principio, el Modelo E/R sólo contemplaba los conceptos de “entidad”, “interrelación” y “atributo”. En la siguiente revisión del modelo ya se contemplaban otros conceptos como atributo multiocurrente y generalización.

2. Elementos del Modelo Entidad/Interrelación

El Modelo Entidad/Interrelación, como cualquier modelo de datos, tiene sus estructuras propias que son conocidas como Diagramas Entidad/Interrelación. De hecho, para describir el esquema conceptual de la base de datos del mundo objeto de estudio se construye su Diagrama Entidad/Interrelación. Los elementos componentes del Modelo Entidad/Interrelación son los siguientes: · Entidades. · Atributos. · Interrelaciones. Cada uno de estos elementos tiene asociado un modo gráfico de representación o símbolo específico, que lo distingue del resto de elementos. En los apartados siguientes describiremos cada uno de estos elementos, sus características y simbología.

2. 1. Entidades

Una entidad es un objeto real o abstracto de interés en una organización y acerca del cual se puede y se quiere obtener una determinada información; personas, cosas, lugares, etc., son ejemplos de entidades. La entidad se representa gráficamente por medio de un rectángulo y en el interior del mismo se escribe el identificador de la entidad. Asociado al concepto de entidad surge el concepto de ocurrencia de entidad. Una ocurrencia de entidad no es otra cosa que una realización concreta de una entidad. Por ejemplo, si tenemos la entidad FRUTAS, una ocurrencia de la misma será NARANJA Según ANSI (1977): “Una persona, lugar, cosa, concepto o suceso, real o abstracto, de interés para la empresa”. La representación gráfica de este objeto es un rectángulo etiquetado. LIBRO AUTOR


43

Reglas que debe cumplir una entidad: · Tiene que tener existencia propia. · Cada ocurrencia de un tipo de entidad debe poder distinguirse de las demás. · Todas las ocurrencias de un tipo de entidad deben tener los mismos tipos de características (atributos).

2.2. Atributos

Un atributo es una propiedad o característica asociada a una determinada entidad y, por tanto, común a todas las ocurrencias de esa entidad; nombre, cantidad, categoría profesional, edad, cargo, etc., son ejemplos de atributos. El atributo se representa gráficamente por medio de una elipse y en el interior de la misma se escribe el identificador del atributo. Asociado al concepto de atributo surge el concepto de dominio. Un dominio es el conjunto de valores permitidos para un atributo. Por ejemplo, si tenemos el atributo COLOR el dominio sobre el que se define podría ser: (NARANJA, BLANCO, AZUL y NEGRO). De acuerdo con lo dicho anteriormente podríamos dar la siguiente definición formal de atributo: Función que a una entidad le asigna un dominio.

A: E -» F (V) Dónde:

A: Atributo E: Tipo de entidad V: Conjunto de valores (Dominio) F: Función

En función de sus características respecto de la entidad que definen se distinguen dos tipos de atributos : • Atributo Identificador Principal (AIP): Distingue unívocamente una ocurrencia de entidad del resto de ocurrencias. • Atributo Descriptor: Caracteriza una ocurrencia pero no la distingue del resto de ocurrencias de entidad. De entre todos los atributos de un tipo de entidad debemos elegir uno o varios que identifiquen unívocamente cada una de las ocurrencias de ese tipo de entidad. Este


44

atributo o conjunto de atributos se denomina ATRIBUTO IDENTIFICADOR PRINCIPAL (AIP), y los atributos que lo componen deben ser mínimos en el sentido de que la eliminación de cualquiera de ellos le hará a perder su carácter identificador. Puede ocurrir que exista más de un conjunto de atributos que verifiquen la condición de ser identificador unívoco y mínimo de cada ocurrencia del tipo de entidad, por lo que denominaremos a cada uno de ellos ATRIBUTO IDENTIFICADOR CANDIDATO (AIC). Elegiremos uno como AIP y el resto serán ATRIBUTOS IDENTIFICADORES ALTERNATIVOS (AIA) Representación gráfica de atributos: AIP______________________0 AIA (Alternativo)___________Q Atributo _________________O Otro tipo de representación:

2.3. Interrelaciones

Una interrelación es básicamente una asociación entre entidades y se caracterizará por unas determinadas restricciones que determinarán las entidades que pueden o no participar de dicha interrelación: PROVEEDOR suministra PRODUCTO, PERSONA ha nacido en PAÍS, EMPLEADO trabaja en DEPARTAMENTO, etc., son ejemplos de interrelación. La interrelación se representa gráficamente por medio de un rombo y en el interior del mismo se escribe la etiqueta que identifica la interrelación.


45

Asociado al concepto de interrelación surge el concepto de ocurrencia de interrelación. Una ocurrencia de interrelación es la asociación concreta de ocurrencias de entidad de diferentes entidades. Por ejemplo, si tenemos las entidades EMPLEADO y DEPARTAMENTO, y la interrelación trabaja en, una ocurrencia de interrelación será: MARTA GARCÍA trabaja en el DEPARTAMENTO DE DIRECCIÓN. Una interrelación queda caracterizada por tres propiedades: · Nombre: Como todo objeto en el modelo E /R las interrelaciones deben tener un nombre que las identifique unívocamente. · Grado: número de tipos de entidad sobre las que se realiza la asociación. La interrelación del ejemplo anterior será binaria, es decir, su grado seria dos. · Tipo de Correspondencia: Número máximo de ocurrencias de cada tipo de entidad que pueden intervenir en una ocurrencia del tipo de interrelación. Las relaciones pueden tener atributos propios. En el ejemplo que venimos manejando, si interesase conocer desde qué fecha trabaja un empleado en un determinado departamento, dicho atributo fecha sería una propiedad de la interrelación “Trabaja en”.

2.4. Representación Gráfica

El Modelo E / R, como ya sabemos, permite representar gráficamente el esquema conceptual de la base de datos que en cada momento estemos definiendo mediante lo que hemos denominado Diagrama Entidad/Interrelación (DE/R). De hecho, ya conocemos cómo se representan cada uno de los elementos del modelo.

Sin embargo, para poder realizar el Diagrama E/R todavía debemos definir una serie de aspectos:


46

· Para representar la pertenencia de un atributo a una entidad o interrelación se une el símbolo del atributo correspondiente mediante un arco. · Para reflejar la asociación existente entre dos o más entidades mediante una interrelación se unen los símbolos de dichas entidades al símbolo de la interrelación correspondiente mediante arcos. Ahora estamos en condiciones de representar mediante un diagrama E/R el esquema conceptual de una base de datos.

2. 5. Representación de restricciones de diseño

La mayoría de las restricciones de diseño conceptual de bases de datos, como ya hemos visto, quedan reflejadas en el DE/R. Sin embargo, hay una serie importante de restricciones que deben ser reflejadas en el diagrama E/R para un correcto modelado y que desarrollamos en los apartados siguientes.

2.6. Tipo de Correspondencia

El concepto de Tipo de Correspondencia, como ya dijimos anteriormente, está asociado directamente al de interrelación. Podemos definir la cardinalidad como el número de ocurrencias de una entidad asociadas a una ocurrencia de otra o la misma entidad a través de una interrelación. Para una interrelación binaria (grado=2), entre las entidades A y B, existen tres posibles tipos de correspondencia: 1:1: Una ocurrencia de la entidad A se asocia como máximo con una única ocurrencia de la entidad B y viceversa; tal y como se puede apreciar en la figura siguiente:


47

Entidad A Entidad B Ejemplo de Correspondencia 1:1 entre dos entidades. Un ejemplo de este tipo de correspondencia sería el siguiente: Un cliente tiene una única cuenta bancaria en una sucursal determinada y una cuenta determinada de una sucursal pertenece a un único cliente. 1:N: Una ocurrencia de la entidad A se asocia con un número indeterminado de ocurrencias de la entidad B, pero una ocurrencia de la entidad B se asocia como máximo con una ocurrencia de A; tal y como se puede apreciar en la siguiente figura.

Entidad A Entidad B Ejemplo de Correspondencia 1:N entre dos entidades Un ejemplo de este tipo de correspondencia sería el siguiente: Una persona vive en una ciudad y en una ciudad viven muchas personas.


48

M:N: Una ocurrencia de la entidad A se asocia un número indeterminado de ocurrencias de la entidad B y viceversa; tal y como se puede apreciar en la siguiente figura.

Entidad A Entidad B Ejemplo de Correspondencia M:N entre dos entidades Un ejemplo de este tipo de correspondencia sería el siguiente: Un proveedor suministra varios productos y un mismo producto puede ser suministrado por varios proveedores. En el diagrama E/R el tipo de correspondencia se representa etiquetando los tipos de interrelación. Llegados a este punto, es conveniente resaltar el hecho de que los dominios asociados a los atributos no son representables gráficamente en el Modelo E/R.

2. 7. Entidades Débiles

El concepto de entidad débil está directamente relacionado con las restricciones de tipo semántico del modelo E/R y, más concretamente, con la denominada restricción de existencia. Esta restricción establece el hecho de que la existencia de una entidad no tiene sentido sin la existencia de otra, es decir, una entidad tiene dependencia de existencia de otra cuando sin la primera la segunda carecería de sentido.

FUERTE DÉBIL La pregunta correcta para saber si una entidad tiene dependencia de existencia respecto a otra sería la siguiente: ¿Se debe borrar alguna ocurrencia de la entidad A si se borra una ocurrencia de la entidad B? Si la respuesta es afirmativa la entidad tiene dependencia de existencia, por el contrario si la respuesta fuese negativa no existiría dicha dependencia. Por tanto, a


49

este tipo de entidades que tienen dependencia de existencia se las denomina entidades débiles, por contraposición a las entidades que no presentan esta característica y que se denominan entidades fuertes o regulares.

2. 7. 1. Dependencia en existencia y dependencia en identificación

Además, en el Modelo E/R se define un tipo especial de entidad débil denominada entidad con dependencia en identificación, y que está relacionada con el concepto de Atributo Identificador Principal que definíamos en apartados precedentes. Este tipo especial de entidad surge como solución al problema de la existencia de entidades que no tiene suficientes atributos para formar su AIP, es decir, la restricción de existencia con dependencia en identificación se produce cuando una entidad no es identificable por el valor de sus atributos, pero sí por su interrelación con otra entidad; por tanto, son un caso particular de las anteriores. Normalmente, la entidad débil con restricción de existencia suele tener un AIP propio que permite establecer de forma independiente la asociación de la ocurrencia de la entidad débil a través de la interrelación establecida entre ambas. Convienen resaltar aquí que la interrelación mencionada tendrá carnalidad 1:N. Es evidente que si desaparece un empleado de la base de datos la existencia de sus familiares carece de sentido, es decir, la entidad FAMILIAR tiene dependencia de existencia respecto de la entidad EMPLEADO. Sin embargo, cada una de las ocurrencias de la entidad familiar puede identificarse por sí misma.


50

Por el contrario, una entidad débil con restricción de existencia con dependencia en identificación no tiene AIP, sino tan sólo un descriptor discriminador y, por tanto, necesita obligatoriamente el AIP de la entidad fuerte para poder identificar de manera única sus ocurrencias de entidad. En este caso, el AIP de la entidad débil se forma por unión del AIP de la entidad fuerte con el mencionado descriptor discriminador. En la figura siguiente puede apreciarse un ejemplo de este tipo de entidades. En este caso, el atributo Num_Ejemplar por sí solo no permite distinguir cada una de las ocurrencias de la entidad EJEMPLAR (porque sus valores se repitan para ejemplares de libros distintos), es decir, Num_Ejemplar no es el AIP de la entidad EJEMPLAR. Será Cod_Libro como AIP de la entidad fuerte LIBRO más Num_Ejemplar como discriminador de la entidad EJEMPLAR.

En el Modelo E/R, también es necesario especificar qué entidades son débiles. Tal circunstancia se representa por medio de un rectángulo de lados dobles, como puede apreciarse en las figuras. Como conclusión al concepto de entidad débil conviene resaltar las circunstancias siguientes: 1. La dependencia en existencia no implica una dependencia en identificación, hecho que si sucede en el caso inverso pues una entidad que depende de otra por su AIP no tendrá sentido sin la existencia de esta última.


51

2. En una interrelación con cardinalidad N:M nunca habrá entidades débiles. La razón es que la supuesta ocurrencia de la entidad débil que se tuviera que borrar podría estar asociada a más de una ocurrencia de la supuesta entidad fuerte, lo que implicaría la imposibilidad de su borrado, hecho éste en clara contraposición con la definición de entidad débil.

2. 8. Papel (‘Rol’) de la entidad

La función que una determinada entidad juega en una interrelación concreta se denomina papel o ‘rol’. Por tanto, es importante establecer el papel de cada entidad a través de las diferentes relaciones en las que participa. Este papel suele ir implícito en el identificador de cada entidad, de ahí la importancia de elegir identificadores adecuados para las relaciones. Sin embargo, determinar los papeles de las entidades es especialmente importante cuando el significado de la interrelación es lo suficientemente claro. Esto tiene si cabe más importancia en el caso de relaciones reflexivas. La razón está en que estamos asociando entre sí ocurrencias de una misma entidad de forma que cada una de ellas tiene un significado diferente. En el ejemplo anterior, una ocurrencia de EMPLEADO hará papel de ‘jefe’ y la otra ocurrencia hará papel de ‘subordinado’. Así mismo, como pude apreciarse en el ejemplo primero, las ocurrencias de entidades asociadas son del mismo tipo, PERSONAS, pero una hará papel de ‘padre’ y la otra papel de ‘hijo’. En el diagrama E/R, también es necesario especificar los papeles de las entidades. Al igual que la cardinalidad, tal circunstancia se representa etiquetando los arcos que unen el rectángulo de la entidad con el rombo de la interrelación, como puede apreciarse en los ejemplos anteriores.

2.9. Atributos multiocurrentes y compuestos

Un último tipo de restricciones que se deben tener en cuenta a la hora de realizar el diseño conceptual de una base de datos con el Modelo E/R son las que afectan a la tipología de los diferentes atributos. Desde este punto de vista podemos definir dos tipos diferentes de atributos respecto a los manejados hasta el momento, que son los siguientes: 1. Atributos multiocurrentes o multivaluados. Son aquellos atributos que para una misma ocurrencia de la entidad toman más de un valor. Por, ejemplo si cada cliente


52

puede tener más de un teléfono y es de interés guardar todos sus posibles valores, el atributo teléfono seria multiocurrente. 2. Atributos Compuestos. Son aquellos que agrupan en sí mismos, por afinidad o por forma de uso, más de un atributo. Por ejemplo: · Por su forma habitual de utilización, el atributo “dirección” engloba los atributos calle, numero, ciudad, provincia y código postal. · Por su significado, el atributo “nombre” de una entidad PERSONAS engloba nombre de pila, primer apellido y segundo apellido. De acuerdo con esta clasificación, en el Diagrama E/R estos dos conceptos se reflejan como sigue: · Si un atributo es multiocurrente o multivaluado se etiquetara su arco con un valor de cardinalidad N. · Si un atributo es compuesto, se especificarán sus atributos componentes rodeando al mismo y enlazándolos al símbolo del atributo compuesto mediante arcos. En la siguiente figura pueden apreciarse la representación gráfica de los ejemplos utilizados para aclarar los conceptos de atributo multiocurrente y atributo compuesto.

2.10. Atributos derivados

Son aquellos que pueden calcularse a partir de otros. Por ejemplo, si tenemos la entidad PERSONA con los atributos DNI, Nombre, Fecha_Nacimiento y Edad, el último atributo (Edad) puede obtenerse a partir de otro atributo (la fecha de nacimiento) y es, por lo tanto, redundante. Este tipo de atributos deben eliminarse del esquema.


53

3. Modelo Entidad/Interrelación Extendido

El Modelo E/R con el paso del tiempo ha sufrido una serie de modificaciones tanto en su simbolismo gráfico, como en la ampliación de sus elementos.

3. 1. Cardinalidad

Este primer concepto en cierto modo estaba tratado de forma implícita en el Modelo E/R original. Sin embargo, ha sido posteriormente cuando se le ha dado cierta relevancia e incluso una forma de representación (aspecto este no previsto en la propuesta del modelo original). El concepto cardinalidad, también denominado “clase de pertenencia”, permite especificar si todas las ocurrencias de una entidad participan o no en la interrelación establecida con otra(s) entidad(es): · Si toda ocurrencia de la entidad A debe estar asociada con al menos una ocurrencia de la entidad B a la que está asociada por una determinada interrelación, se dice que la clase de pertenencia es obligatoria, es decir, la cardinalidad mínima es 1. · Por el contrario, si no toda ocurrencia de la entidad A necesita estar asociada con alguna ocurrencia de la entidad B asociada, se dice que la clase de pertenencia es opcional, es decir, la cardinalidad mínima es 0. Podemos definir la Cardinalidad de un tipo de Entidad como el número mínimo y máximo de ocurrencias de un tipo de entidad que pueden estar relacionadas con una ocurrencia del otro, u otros tipos de entidad que participan en el tipo de interrelación. Su representación gráfica es una etiqueta del tipo (0,1), (1,1), (0,n) ó (1,n) según corresponda. Ejemplo: ‘Un libro puede estar escrito por ninguno, uno o varios autores. Un autor escribe al menos un libro y puede escribir varios.’

3.2. Jerarquía Subconjunto

Este segundo concepto, junto con el que describiremos en el apartado siguiente, son propios del Modelo E/RE y a veces son estudiados de forma conjunta bajo el concepto genérico de entidades subtipo.


54

La descomposición de tipos de entidad en varios subtipos es una necesidad muy habitual en el modelado conceptual. En el mundo real se pueden identificar varias jerarquías de entidades. La interrelación que se establece entre un supertipo y sus subtipos corresponde a la noción de “ES-UN” ( IS-A) o más exactamente “es un tipo de”. Proponemos para su representación utilizar un triángulo invertido, con la base paralela al rectángulo que representa el supertipo. El concepto jerarquía Subconjunto establece que una entidad A es un subconjunto de otra entidad B cuando toda ocurrencia de la primera también es una ocurrencia de la segunda, y lo contrario no tiene por qué ser cierto. Por tanto, tendremos una jerarquía subconjunto cuando cada ocurrencia de una entidad genérica pueda ser también una ocurrencia de otras entidades que, potencialmente, son subconjuntos solapados. Un aspecto importante es que la entidad subconjunto, además de los atributos de la entidad genérica, puede tener atributos adicionales.

3.3. Características

· Toda ocurrencia de un subtipo es una ocurrencia del supertipo, las cardinalidades serán siempre (1,1) en el supertipo y (0,1) o (1,1) en los subtipos. · Todo atributo del supertipo pasa a ser un atributo de los subtipos. Así, en el ejemplo, podemos establecer una asociación entre la entidad EMPLEADO y las entidades DOCENTE y NO DOCENTE en el sentido de que tanto los docentes como los no docentes son tipos de empleados, por lo que heredaran todas las características de la entidad EMPLEADO (código, nombre, dirección, sueldo, etc.). En este tipo de abstracción, los atributos comunes a todos los subtipos se asignan al supertipo, mientras que los atributos específicos se asocian al subtipo correspondiente. Las relaciones que afectan a todos los subtipos se asocian al supertipo, dejándose para los subtipos las relaciones específicas en las que el correspondiente subtipo participa.

3.4. Tipos de Generalización

Se pueden distinguir cuatro tipos de generalización, atendiendo a si los subtipos se solapan o son disjuntos, y a si la unión de los subtipos recubre o no el supertipo.


55

3. 4. 1. Jerarquía total de subtipos disjuntos

· Tanto un docente como un no docente son empleados. · Un mismo empleado no puede ser a la vez docente y no docente. · Todo empleado tiene que ser obligatoriamente un docente o un no docente

3. 4. 2. JERARQUÍA DISJUNTA Y PARCIAL

· Tanto un artículo como un libro son documentos. · Un mismo documento no puede ser a la vez un artículo y un libro. · Puede haber documentos que no sean ni artículos ni libros.


56

3. 4. 3. Jerarquía total con solapamiento

· .Tanto un empleado como un estudiante son personas. · Una misma persona puede ser estudiante a la vez que empleado · Toda persona en nuestra BD tiene que ser obligatoriamente un estudiante y/o empleado.

3. 4. 4. Jerarquía parcial de subtipos solapados

· Tanto un docente como un investigador son empleados. · Un mismo empleado puede ser, y en general lo es, docente a la vez que investigador.


57

3 . 5 . Tipos de relaciones

3 . 5 . 1 . Relaciones reflexivas

Son relaciones unarias y, por tanto, del tipo de interrelación sólo participa un único tipo de entidad. Ejemplo: Un trabajador puede ser jefe de ningún trabajador o puede serlo de varios trabajadores, mientras que un trabajador sólo es dirigido por ninguno o un trabajador.

3. 5. 2. Relaciones exclusivas

Decimos que dos o más tipos de interrelación son exclusivos cuando cada ocurrencia de un tipo de entidad sólo puede pertenecer a un tipo de interrelación. ‘Las relaciones “publica” y “aparece” son exclusivas, ya que se ha recogido en el esquema que en una determinada biblioteca los artículos están publicados en revistas o recogidos en recopilaciones, pero no en ambos.’


58

3. 5. 3. Entre dos tipos de entidad puede existir más de un

Tipo de interrelación

Ejemplo: Dos tipos de entidad entre los que existen dos tipos de interrelación.

Ejemplo de interrelación de grado superior a 2:

3.6. Dimensión temporal en el modelo e/r

Otra de las extensiones que se proponen para el modelo E/R es la inclusión de la dimensión temporal en el mismo. Es indudable la necesidad de establecer un método semántico y gráfico que recoja de alguna forma en el esquema conceptual el transcurso del tiempo y su influencia en la variación de los datos. La aproximación más simple la constituyen atributos de tipo fecha que aparecen asociados a algunas entidades.


59

En este caso la fecha de nacimiento de un autor o la fecha en la que se editó un libro son datos temporales recogidos en el esquema, pero se trata de atributos que han de recibir un tratamiento especial en cuanto a las operaciones, y no se puede considerar realmente una aproximación semántica a la dimensión temporal. Por otro lado, podemos analizar si los datos que se pretenden almacenar van a constituir una base de datos histórica o si, por el contrario, sólo nos interesa el estado actual de los datos. Ejemplo: El tipo de interrelación ‘prestar’ entre los tipos de entidad EJEMPLAR y SOCIO, posee los atributos “F_pres” y “F_dev” que especifican el periodo de tiempo en el cual un socio tiene un libro. (a) Recoge todos los préstamos que se han realizado en una biblioteca, recogiendo además el periodo de tiempo que duraron.

(b) Recoge sólo los prestamos actuales y, una vez finalizado el préstamo, la correspondiente información desaparece de la base de datos; es decir, no existe fichero histórico.


60

En el caso de tratarse de datos históricos, los tipos de entidad o de interrelación correspondientes tendrán asociados siempre atributos de tipo ”fecha”. Para sucesos puntuales, es decir, sin duración, bastara con un solo a tributo de este tipo, mientras que para poder almacenar hechos que transcurren en un periodo de tiempo determinado necesitaremos una "fecha_inicio” y una "fecha_fin".

3.7. Restricciones

El modelo E/R no tiene en principio restricciones inherentes. Por lo que respecta a las restricciones de usuario, el modelo E/R permite definir: • Restricciones sobre valores (mediante la definición de dominios). · Restricciones sobre el número de ocurrencias (delimitar el número de tipos de entidad que participan en la interrelación). LAS RESTRICCIONES DINAMICAS NO PUEDEN EXPRESARSE EN ESTE MODELO

3.8. Control de redundancia

Además de la existencia de atributos redundantes, como los atributos derivados, que deben eliminarse del esquema E/R, hay que estudiar detenidamente los ciclos, ya que pueden existir interrelaciones redundantes.


61


62

BIBLIOGRAFÍA

[ D A T E 8 6 ] C. J. DATE . Introducción a los sistemas de bases de datos. Tercera edición.

Addison-Wesley Iberoamericana, 1986

[ D A T E 9 3 ] C. J. DATE . Introducción a los sistemas de bases de datos. Vol. 1 Quinta edición.

Addison-Wesley Iberoamericana, 1993

[DE MI G9 3 ] ADORACIÓN DE MIGUE L Y MARI O PIATTINI . Concepción y Diseño de bases de datos.

Ed. Ra-Ma. 1993.

[DE MI G9 7 ] ADORACIÓN DE MIGUE L Y MARI O PIATTINI . Fundamentos y modelos de bases de datos. Ed. Ra-Ma. 1997.

[H A NS E N9 7 ] HANSE N G W , HANSE N J V . Diseño y Administración de Bases de Datos. 2 ª

Edición. Prentice Hall, Madrid , 1997 [DATE86] C. J. DATE. Introducción a los sistemas de bases de datos. Tercera edición. Addison-Wesley Iberoamericana, 1986 [DATE93] C. J. DATE. Introducción a los sistemas de bases de datos. Vol. 1 Quinta edición. Addison-Wesley Iberoamericana, 1993 [DEMIG93] ADORACIÓN DE MIGUEL Y MARIO PIATTINI. Concepción y Diseño de bases de datos. Ed. Ra-Ma. 1993. [DEMIG97] ADORACIÓN DE MIGUEL Y MARIO PIATTINI. Fundamentos y modelos de bases de datos. Ed. Ra-Ma. 1997. [HANSEN97] HANSEN GW, HANSEN J V . Diseño y Administración de Bases de Datos. 2ª Edición. Prentice Hall, Madrid, 1997 [CHEN76] The Entity/Relationship Model: Toward a unified view of data. CACM, 1,1. 1976 [CHEN77] The Entity/Relationship Model: A basis for the enterprise view of data. AFIPS Conference Proceedings, Vol 46. 1977


63

BASES DE DATOS - Intalentia

Documents

Transcript of BASES DE DATOS - Intalentia