• Author / Uploaded
• Maximiliano Céspedes

• Categories
• Bases de datos
• Lenguaje de programación
• Archivo de computadora
• Software
• Base de datos relacional

Citation preview

INSTITUCIÓN CERVANTES

Área Informática Base de Datos I

Fundamentación El diseño de bases de datos es el proceso por el cual se determina la forma de organizar los datos, incluidos su estructura, contenido y las aplicaciones por desarrollar. Durante mucho tiempo, el diseño de bases de datos fue considerado una tarea para expertos; más un arte que una ciencia. Sin embargo, se ha progresado mucho en el diseño de bases de datos, y este se considera ahora una disciplina estable, con técnicas y métodos propios. Debido a la creciente aceptación de las bases de datos por parte de la industria y el gobierno en el plano comercial, y una variedad de aplicaciones científicas y técnicas, el diseño de bases de datos desempeña un papel central en el empleo de los recursos de información de la mayoría de las organizaciones. El diseño de bases de datos ha pasado a constituir parte de la formación general de los profesionales informáticos, en el mismo nivel que la capacidad de construir algoritmos usando un lenguaje de programación convencional. Si consideramos que la información hoy en día, es el componente más importante y más valioso dentro de una empresa, el diseño de bases de datos como parte integrante del ciclo de vida de un sistema de información, tomó vital importancia. Es la base de datos la proveedora de información para el resto de los procesos que el sistema requiera, sobre todo, será fundamental en aquellos procesos que brinden información gerencial o necesaria para la toma de decisiones.

Objetivos Generales
Reconocer y valorar la importancia del diseño de bases de datos dentro del ciclo de













vida de un sistema de información. Conocer y comprender las distintas etapas para el diseño de una base de datos obteniendo así la posibilidad de analizar bases de datos existentes o crear una. Manipular las herramientas necesarias para el correcto diseño de una base de datos. Adquirir conocimientos acerca de las componentes del modelo relacional de datos. Describir, analizar y corregir estructuras de datos con anomalías de diseño. Adquirir la capacidad de diseñar y construir un modelo de datos relacional. Reconocer la importancia del modelado conceptual dentro de una metodología de diseño de bases de datos, utilizando modelos que ofrezcan la suficiente semántica y que sean independientes de las instrumentaciones. Adquirir principios metodológicos que ayuden al diseñador a realizar un buen esquema conceptual que permita su transformación a esquema lógico con la mínima pérdida de semántica. Adquirir una sólida base teórica, como es la teoría de la normalización, al diseño lógico de bases de datos, permitiendo de esta forma aplicar procedimientos algorítmicos a dicho diseño.

Institución Cervantes

1

INSTITUCIÓN CERVANTES

Mapa Conceptual

2

INSTITUCIÓN CERVANTES

INSTITUCIÓN CERVANTES

Área Informática Base de Datos I

Programa Unidad I: Diseño de Bases de Datos Introducción al diseño de bases de datos: Fases del diseño de Bases de datos. Ciclo de vida de un sistema de información. Independencia de datos. Diseño conceptual. Esquema y modelo conceptual. Diseño lógico. Esquema y modelo lógico. Diseño físico. Esquema y modelo físico. Ventajas de bases de datos contra ficheros o archivos tradicionales o convencionales. Datos: Definición. Concepto. Medidas de los datos. Modelos de datos. Bases de Datos: Definición. Unidad II: Modelo de datos Modelado de datos: Procesos de abstracción en el diseño conceptual o modelamiento de Bases de Datos. Abstracción de clasificación, de agregación y de generalización. Propiedades de las correspondencias entre clases. Agregación binaria. Agregación n-aria. Cardinalidad mínima y máxima. Generalizaciones: propiedades de cobertura. Modelos de datos: Modelo conceptual de datos. Modelos lógicos. El modelo de entidadesinterrelacionadas: Elementos básicos. Cualidades. Unidad III: Arquitectura de la base de datos Estructuras de Bases de Datos: Archivos planos: Lista secuencial, lista vinculada, lista invertida. Bases de datos jerárquicas. Bases de datos en red. Bases de datos relacionales. Arquitectura: Nivel interno, nivel externo y nivel conceptual. Nivel Interno: Acceso a la Base de datos: El manejador de disco (Disk Manager - DM). El manejador de archivos (File Manager - FM). Agrupamiento. Indexación. Arboles B (B-Trees). Nivel Físico de la base de datos: El administrador de la Base de datos (DBA). Funciones. El sistema de administración de la base de datos (DBMS). Funciones. El administrador de comunicación de datos (DC). Procesamiento Distribuido: Sistemas de teleprocesamiento. Sistemas Cliente/Servidor. Sistemas distribuidos. Bases de datos distribuidas. Unidad IV: El Modelo Relacional Estructura del modelo relacional: Dominio. Relaciones. Tablas. Propiedades y restricciones de integridad en los esquemas relacionales de bases de datos. Integridad de datos: Clave candidata. Clave primaria. Integridad de Entidad. Clave secundaria o alternativa. Clave foránea o ajena. Integridad referencial. Diseño lógico en el modelo relacional. Transformación de esquema conceptual a esquema lógico. Eliminación de jerarquías de generalización. Interrelaciones: de uno a uno, de uno a muchos, de muchos a muchos.

Institución Cervantes

3

INSTITUCIÓN CERVANTES

Unidad V: Descomposición y Normalización Dependencia funcional: Definición. Tipos de dependencias. Normalización. Definición. Diferentes formas normales. Aplicaciones prácticas.

Bibliografía y materiales de consulta













BATINI, Carlo, CERI, Stafano, y NAVATHE, Shamkant B., Diseño Conceptual de Bases de Datos. Un enfoque de entidades interrelaciones, Addison-Wesley/Diaz de Santos. DATE, C. J., Introducción a los sistemas de bases de datos, volumen 1, Addison Wesley, Iberoamericana, MA, quinta edición. MIGUEL, Adoración de y PITTINI, Mario. Concepción y Diseño de Bases de Datos. Del modelo E/R al Modelo Relacional. Paradigma, RA-MA, Madrid, España. KROENKE D.M. “Procesamiento de Base de Datos: Fundamentos, Diseño e Instrumentación” Quinta Edición Ed. Hispanoamericana 1996. KORTH H. “Fundamentos de Bases de Datos” Ed. Mc. Graw-Hill. http://asia.microsoft.com/latam/technet/articulos/200002/art16/ http://www.itlp.edu.mx/publica/tutoriales/basedat2/unidad1.htm http://epsilon.facpya.uanl.mx/class/parte1.htm http://kiyen.face.ubiobio.cl/~cvidal/base_datos/relacional/index.htm http://redii.cic.ipn.mx/librospro/dbdd/default.html

Orientaciones Metodológicas Se desarrollarán clases teóricas para la presentación de cada unidad, con la ayuda de medios audiovisuales (televisores, computadoras, etc.). En la medida que se avance con los conceptos teóricos, se irán realizando prácticas promoviendo la participación de los alumnos en grupos de investigación y trabajos prácticos.

Evaluación 1 parcial teórico / práctico (en aula) aprobado con 4 o más de 4 (equivale al 60% del parcial aprobado). 1 trabajo práctico. Será indispensable tenerlo aprobado para regularizar la materia. En el mismo se aplicarán todos los conocimientos adquiridos, interrelacionando los conceptos vistos hasta el momento. El alumno deberá construir una base de datos desde el comienzo. El mismo deberá tener la siguiente estructura:

4

INSTITUCIÓN CERVANTES

INSTITUCIÓN CERVANTES

Área Informática Base de Datos I

1) Introducción (Objetivos generales, fundamentación, herramientas utilizadas, descripción del problema planteado). 2) Desarrollo. a. Esquema conceptual. (Objetivos particulares, diagrama, conclusión) b. Esquema lógico. (Objetivos particulares, diagrama, conclusión) c. Esquema físico. (Objetivos particulares, diagrama, conclusión) 3) Conclusiones. (si se consiguió cumplir con los objetivos generales planteados en la introducción y de los resultados obtenidos) Cabe aclarar, que toda consulta y tarea deberá contar con la bibliografía y las direcciones electrónicas utilizadas.

Institución Cervantes

5

INSTITUCIÓN CERVANTES

Evaluación Diagnóstico 1. Defina la diferencia entre dato e información. ........................................................................................ ........................................................................................ 2. ¿Qué entiende por manipulación de datos? ........................................................................................ ........................................................................................ 3. ¿De qué maneras puede almacenar un dato para manipularlo dentro de un programa? ........................................................................................ ........................................................................................ 4. Enumere y defina los diferentes tipos de datos que conozca. (por ej.: numérico) ........................................................................................ ........................................................................................ 5. Qué entiende por almacenamiento físico. ........................................................................................ ........................................................................................ 6. Describa brevemente que entiende por fichero o archivo. ........................................................................................ ........................................................................................ 7. Defina lo que entiende por registro y campo. ........................................................................................ ........................................................................................ 8. Describa brevemente que entiende por Base de Datos. ........................................................................................ ........................................................................................ 9. Enumere y defina los distintos tipos de archivos que reconozca. (por ejemplo: BAT, EXE, DOC, etc.) ........................................................................................ ........................................................................................ 6

INSTITUCIÓN CERVANTES

Área Informática Base de Datos I

INSTITUCIÓN CERVANTES




Unidad I

Introducción al Diseño de Bases de Datos Objetivos
Comprender la importancia del diseño de la base de datos dentro de un sistema de





información. Conocer la historia y evolución de los distintos tipos de almacenamientos de datos. Valorar la importancia de las bases de datos dentro de una organización como soporte para la toma de decisiones. Reconocer las distintas etapas para diseñar una base de datos. Identificar ventajas y desventajas de este modelo.

Institución Cervantes

7

INSTITUCIÓN CERVANTES

Introducción El diseñar una base de datos es un proceso que suele ser complejo pero a veces divertido. Cuando me ha tocado diseñar una base de datos, siempre me imagino parado en la cima de una montaña de la cual puedo contemplar el terreno a mis pies. En él se pueden apreciar todas las especies arbóreas que habitan el bosque, las cuales se encuentran todas entremezcladas. Imaginen si ustedes fueran los encargados de la tarea de ordenar y agrupar cada especie. El proceso de diseñar y administrar una base de datos es una tarea algo parecida. Deberán interpretar los requerimientos de los usuarios, los cuales plantearan un inmenso bosque lleno de hierbas y árboles, todo enmarañado. Además, los usuarios van a requerir, según sus necesidades, diferente información de esas especies. Algunos les interesará conocer si la humedad es la suficiente, a otros solo la antigüedad de determinada especie y asi sucesivamente. Ustedes tendrán que resolver esos problemas. Administrar la información de manera tal que a cada usuario le llegue sólo lo que le interesa, es decir, no todo el bosque, solo la porción que quieren conocer. Solo ustedes tendrán la visión general del bosque desde la loma. Los demas solo verán lo que ustedes le muestren. Cómo lo harán? Esa es la misión de este curso. Que aprendan a utilizar las herramientas necesarias para lograr ese objetivo.

Introducción al Diseño de Bases de datos En la historia de la informática, siempre se distinguieron etapas. En lo que a hardware se refiere, cada una se distinguió de la anterior por los cambios producidos en los componentes físicos de las computadoras. En el software, ocurrió algo parecido dentro de los lenguajes de programación. Estas etapas, se marcaron por cambios producidos en los mismos. Hoy en día los 4GL (lenguajes de cuarta generación) son los que están más vigentes. En cuanto a los almacenamientos físicos de datos, si bien no se destacan etapas, estos acompañaron a los cambios producidos en los lenguajes que manipulan esos datos almacenados. Los primeros lenguajes de programación (COBOL por ejemplo), manipulan archivos de datos, donde la característica de estos lenguajes, era orientada a los procesos o programas más que a los datos. Más adelante retomaremos el tema para su total comprensión. A raíz de las dificultades que presentaba este modelo, comenzó todo un análisis y estudio de nuevas tecnologías capaces de producir otro tipo de almacenamiento de datos. Aparece el concepto de Base de Datos, el cual apoya su estructura en los datos más que en los procesos, es decir revierte el criterio hasta entonces conocido. La expresión base de datos aparece a comienzos de los años sesenta. En 1963 tuvo lugar en Santa Mónica (USA) un simposio donde aparece por prim era vez el término Data Base. Una base de datos es un conjunto, colección o depósito de datos almacenados en un soporte informático de acceso directo. Los datos deben estar relacionados y estructurados de acuerdo con un modelo capaz de recoger el máximo contenido semántico (Introducción a las Bases de Datos, Jesús Vegas) 8

t63

INSTITUCIÓN CERVANTES

INSTITUCIÓN CERVANTES

Área Informática Base de Datos I

Dada la importancia que tienen en el mundo real las relaciones entre los datos (por ejemplo la relación existente entre un alumno y las materias que cursa), es imprescindible que la base de datos sea capaz de almacenar estas interrelaciones, al igual que hace con otros elementos (como las entidades y atributos), siendo ésta una diferencia esencial respecto de los ficheros donde no se almacenan las relaciones. En las bases de datos no debe existir redundancia lógica, aunque sí se admite cierta redundancia física por motivos de eficiencia. Desde el punto de vista de usuario, los datos están almacenados sólo una vez, aunque el sistema los duplique para facilitar el acceso. Por tanto, un dato se actualizará lógicamente por el usuario de forma única, el sistema se preocupará de cambiar físicamente todos aquellos campos en los que el dato estuviese repetido (actualización en cascada), en caso de existir redundancia física. Por ejemplo: a un alumno se lo reconoce y se lo identifica por su número de legajo. El mismo se encuentra almacenado en el Legajo, en las notas, en la asistencia, etc. Si ese número cambiara por cualquier motivo, el sistema actualiza automáticamente en todas las relaciones el número viejo por el nuevo y el usuario no se entera de lo que ha pasado. Las bases de datos han de atender a múltiples usuarios y a diferentes aplicaciones. Otro aspecto importante de las bases de datos es la independencia, tanto física como lógica, entre datos y procesos. Esta independencia, objeto fundamental, es una característica esencial que distingue a esta de los ficheros tradicionales y que ha tenido enorme influencia en la arquitectura de los DBMS o SMBD (DATA BASE MANAGER SYSTEM o SISTEMAS MANEJADORES DE BASES DE DATOS), como se verá más adelante. La definición y la descripción del conjunto de datos contenidos en la base deben ser únicas y estar integradas con los mismos datos. En los sistemas basados en ficheros, los datos se encuentran almacenados en soporte magnético, mientras su descripción está separada de los mismos formando parte de los programas, la estructura de los ficheros tienen total dependencia con los programas que los administran, para cualquier modificación que se quiera realizar en la estructura de algún fichero, indefectiblemente deberá modificarse el programa. En las bases de datos, la descripción y, en algunos casos, también una definición y documentación completa (metadatos t113 se almacenan junto con los datos, de modo que estos estén autodocumentados, y cualquier cambio que se produzca en dicha documentación se ha de reflejar y quedará recogido en el sistema, con todas las ventajas que de este hecho se derivan. Se dice a partir de este concepto que las bases de datos son autodescriptivas, ya que en la misma base se almacenan datos y definición de los mismos. La actualización y recuperación en las bases de datos deben realizarse mediante procesos bien determinados, estos procesos deben estar diseñados de modo que mantengan la integridad, seguridad y confidencialidad de la base de datos. El concepto de base de datos ha ido cambiando y configurándose a lo largo del tiempo. En la actualidad, y de acuerdo con estas características que acabamos de analizar, podemos definir a la base de datos como sigue: Institución Cervantes

9

INSTITUCIÓN CERVANTES

Colección o depósito de datos integrados, con redundancia controlada y con una estructura que refleje las relaciones y restricciones existentes en el mundo real; los datos, que han de ser compartidos por diferentes usuarios y aplicaciones, deben mantenerse independientes de éstas, y su definición y descripción, únicas para cada tipo de datos, han de estar almacenadas 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 datos. (Introducción a las Bases de Datos, Jesús Vegas)

Ciclo de vida de un sistema de información Dentro del diseño de un sistema de información, dijimos que el diseño de la base de datos es uno de los componentes del mismo. Es por ello que necesitamos conocer donde estamos parados para reconocer la importancia del proceso de diseño y construcción de la misma. Definimos un sistema de información como la reunión de todos los recursos dentro de la organización que colaboran en la recolección, administración, uso y diseminación de la información. En un sistema computarizado, esto es, el SGBD o DBMS, el hardware de la computadora, los medios de almacenamiento, el personal que lo usa y maneja los datos y el software de aplicación que tiene acceso y actualiza los datos. El ciclo de vida del sistema de información e incluye las siguientes etapas o fases: Fase del Ciclo de Vida Justificación Analiza áreas de aplicación, relación costo – beneficio y Análisis de factibilidad todas las prioridades. Período de obtención de requerimientos detallados Recolección y análisis de los interactuando con los posibles usuarios requerimientos Comprende el diseño de la base de datos y de los Diseño sistemas de aplicación Se implementan el sistema de información, la base de Implementación datos y sus transacciones. El sistema es validado en cuanto a la satisfacción de los Validación y prueba de requerimientos de los usuarios y los criterios de aceptación rendimiento. Es aquí cuando todas las funciones del sistema están Operación disponibles y validadas. La supervisión y el mantenimiento del sistema serán actividades importantes. Supervisión y mantenimiento El sistema se vigila y mantiene constantemente.

10

INSTITUCIÓN CERVANTES

INSTITUCIÓN CERVANTES

Área Informática Base de Datos I

Ventajas de las bases de datos frente a los ficheros clásicos Las bases de datos, presentan una multitud de ventajas frente a los sistemas clásicos de ficheros. Cabe señalar que las bases de datos no son la panacea universal que solucionará todos los problemas que la información plantea, es un instrumento, y su éxito o fracaso estará condicionado por el uso que de ellas sepamos hacer tanto usuarios, técnicos, y los responsables de los sistemas de base de datos. Las ventajas de los sistemas de bases de datos son, entre otras, las siguientes:
Independencia de los datos respecto de los tratamientos y viceversa.

La mutua independencia de datos y tratamientos lleva a que un cambio de estos últimos no imponga un nuevo diseño lógico y/o físico de las bases de datos. Por otra parte, la inclusión de nuevas informaciones, desaparición de otras, cambios en la estructura física o en los caminos de acceso, etc., no deben obligar a alterar los programas de aplicación.
Coherencia de los datos

Debido a que la información de la base de datos se recoge y almacena una sola vez, en todos los tratamientos se utilizan los mismos datos, por lo que los resultados de todos ellos son coherentes y perfectamente comparables.
Mejor disponibilidad de los datos para el conjunto de los usuarios

Cuando se aplica la metodología de base de datos, cada aplicación / usuario ya no es propietario de los datos, puesto que éstos se comparten entre el conjunto de aplicaciones, existiendo una mejor disponibilidad de los datos para todos los que tienen necesidad de ellos, siempre que estén autorizados para su acceso. Hay también una mayor transparencia respecto de la información existente, ya que todos los datos se encuentran en la base se deben relacionar en un catálogo o diccionario de datos, que puede ser ampliamente difundido y accedido por medios informáticos.
Mayor valor informativo

Puesto que la base de datos es un sistema reflejo del mundo real, donde los distintos elementos están relacionados, el valor informativo de sus conjuntos es superior de la suma del valor informativo de los elementos individuales que lo constituyen.
Mejor y más normalizada documentación de la información, la cual está integrada

con los datos.


Mayor eficiencia en la recolección, validación y entrada de los datos al sistema.

Al no existir redundancias, los datos se recogen y validan una sola vez, aumentando así el rendimiento de todo el proceso previo al almacenamiento.
Reducción del espacio de almacenamiento

La desaparición (o disminución) de las redundancias, así como la aplicación de técnicas de compactación, lleva en los sistemas de bases de datos a una menor Institución Cervantes

11

INSTITUCIÓN CERVANTES

ocupación de almacenamiento secundario. Se ha de tener presente, sin embargo, que los elementos del sistema (diccionarios, referencias, punteros, ficheros invertidos, etc.) ocupan bastante espacio. Imaginemos la siguiente situación: En una empresa dedicada a la comercialización de XXX producto, dividida en áreas y cada área maneja información para la toma de decisiones o para la comercialización del producto. Todos los sectores de la organización, accederían a la base de datos a solicitar la información requerida. Si no fuera así y cada área tuviera los datos que necesita en forma independiente, en cada sector se generaría el cliente que el área necesita sin controlar que las otras áreas ya lo hubieran creado. Esto genera duplicación de la información. No habría relación entre las distintas áreas de trabajo. Cada sector debería realizar mantenimiento de los datos, etc.

Independencia de los datos Esta se refiere a la libertad que pueda existir para modificar algunos de los esquemas sin que exista la necesidad de rescribir los programas de aplicación. Existen básicamente dos tipos de independencia: a. INDEPENDENCIA FISICA.- Esta se presenta cuando es posible la modificación del esquema físico sin afectar a los esquemas restantes. Las principales razones para llevar a cabo una modificación del esquema físico serán un ajuste en el hardware de almacenamiento o una redistribución de los datos en él. b. INDEPENDENCIA LOGICA.- Ocurre cuando se modifica el esquema conceptual sin afectar al resto de los esquemas. Básicamente se modifica el esquema conceptual cuando cambian las características de los datos a almacenar. Es relativamente más sencillo y probable lograr la independencia física puesto que una modificación del esquema conceptual, (estructuras, ligas y demás) inevitablemente requerirá de modificaciones el código para su manipulación.

Fases del Diseño de Bases de Datos El diseño de una base de datos es un proceso complejo que abarca varias decisiones a muy distintos niveles. La complejidad se controla mejor si se descompone el problema en subproblemas y se resuelve cada uno de éstos independientemente, usando métodos y técnicas específicas. El diseño de base de datos se descompone en el diseño conceptual, diseño lógico y diseño físico, como lo muestra la siguiente figura:

12

INSTITUCIÓN CERVANTES

Área Informática Base de Datos I

INSTITUCIÓN CERVANTES

El diseño de bases de datos representa un enfoque orientado a los datos para el desarrollo de los sistemas de información: la atención completa del proceso de diseño se centra en los datos y sus propiedades. Con este enfoque, primero se diseña la base de datos luego las aplicaciones que la usan. Este método se desarrolló en la década de 1970, con el establecimiento de la tecnología de bases de datos.


Diseño conceptual

El diseño conceptual parte de la especificación de requerimientos y su resultado es el esquema conceptual de la base de datos. Un esquema conceptual es una descripción de alto nivel de la estructura de la base de datos, independiente del software de DBMS que use para manipularla. Un modelo conceptual es un lenguaje que se usa para describir esquemas conceptuales. El propósito del diseño conceptual es describir el contenido de información de la base de datos, más que las estructuras de almacenamiento que se necesitarán para manejar esta información. En realidad, el diseño conceptual debe hacerse aún cuando la implantación no use un DBMS, sino archivos convencionales y lenguajes de programación. Modelos Conceptuales: MER (modelo entidad relación), Modelos OO (orientado a objetos), etc. En este curso se estudiara el MER el cual explicaremos en profundidad más adelante.

Institución Cervantes

13

INSTITUCIÓN CERVANTES




Diseño lógico

El diseño lógico parte del esquema conceptual y da como resultado un esquema lógico. Un esquema lógico es una descripción de la estructura de la base de datos que puede procesar el software de DBMS. Un modelo lógico es un lenguaje utilizado para especificar esquemas lógicos; los modelos lógicos más usados pertenecen a tres clases: relacional, de redes y jerárquico. El diseño lógico depende de la clase de modelo de datos usado por el DBMS, no del DBMS utilizado (en otras palabras, el diseño lógico se efectúa de la misma forma para todos los DBMS relacionales porque todos utilizan el modelo relacional). Modelos Lógicos: Relacional, de Redes, Jerárquico, Modelos OO.




Diseño físico

El diseño físico parte del esquema lógico y da como resultado un esquema físico. Un esquema físico es una descripción de la implantación de una base de datos en la memoria secundaria; describe las estructuras de almacenamiento y los métodos usados para tener acceso efectivo a los datos. Por esta razón, el diseño físico se adapta a un sistema DBMS específico. Hay una retroalimentación entre diseño físico y el lógico, porque las decisiones tomadas durante el diseño físico para mejorar el rendimiento pueden afectar la estructura del esquema lógico. Modelos Físicos: Visual Basic, COBOL, FOX, etc. Una vez completado el diseño físico de una base de datos, los esquemas lógico y físico se expresan haciendo uso del lenguaje de definición de datos (DDL) del DBMS objetivo; la base de datos se crea y se carga, y puede ser probada. Más que eso, las aplicaciones que usan las bases de datos pueden especificarse, implantarse y probarse completamente. De este modo la base de datos se vuelve paulatinamente operacional. La siguiente figura resume la dependencia de los diseños conceptual, lógico y físico de la clase o tipo de DBMS y del DBMS específico. Dependencia del:

El tipo de dbms

Un dbms específico

Diseño conceptual

No

No

Diseño lógico

Sí

No

Diseño físico

Sí

Sí

14

INSTITUCIÓN CERVANTES

INSTITUCIÓN CERVANTES

Área Informática Base de Datos I

Concepto de Dato y Modelo de Dato El significado de dato La percepción del mundo puede ser descrita como una sucesión de fenómenos. Desde el comienzo de los tiempos el hombre ha tratado de descubrirlos, ya sea que los entienda completamente o no. La descripción de estos fenómenos es llamada DATO. t13 Usualmente el dato y su significado son registrados juntos, ya que el lenguaje natural es lo suficientemente poderoso para hacerlo. Por ejemplo "el kilo de pan cuesta $ 1,60 se registra el valor (1,60) y su significado o semántica (valor del kilo de pan en pesos). En ciertos casos los datos están separados de su semántica. Por ejemplo, una planilla de notas es una tabla de datos. Su interpretación está implícita y se supone que quien la lee conoce su significado. El uso de la computadora para procesar datos, ha traído consigo una mayor separación entre los datos y su interpretación. Mucha de la interpretación de los datos está explícita. Consideremos por ejemplo un programa que calcula integrales definidas. Este programa recibe valores de entrada y genera valores como salida. Sin embargo, el programa en si no tiene conocimiento si el problema resuelto es de termodinámica o electromagnetismo. Han habido dos razones para separar los datos de su significado: las computadoras no manejan (bien) el lenguaje natural, que es la mejor forma de dar interpretación y significado a un dato.
el almacenamiento del significado de los datos ocupa espacio, e inicialmente este era escaso y costoso.


Así, tradicionalmente la interpretación de los datos se deja al usuario y al sistema manual externo al computador. En muchos sistemas la interpretación de datos se encuentra en los programas que hacen uso de ellos, de modo que los datos pasan a ser una simple colección de valores. Por otra parte, supongamos que algo de la semántica de los datos se codifica junto con ellos. Así los datos no son solo valores, sino que también tienen una semántica, y los datos están más cerca de la interpretación del mundo. Ellos forman una "vista" del mundo, la que no es exacta ni concreta, sino que usualmente es bastante abstracta. Los datos no son estáticos, y corresponden a un mundo que está en constante cambio. La flexibilidad en la interpretación de los datos permite capturar los aspectos dinámicos del mundo y al mismo tiempo, proveer una estructura estable para los datos. Esta flexibilidad se puede tener de dos formas: Institución Cervantes

15

INSTITUCIÓN CERVANTES


El sistema puede permitir que los mismos datos sean vistos de diferente forma. Por

ejemplo, diferentes aplicaciones puedan usar los mismos datos y dar su propia semántica.
Diferentes datos pueden ser vistos de la misma forma. Por ejemplo, se quiere ver a los gerentes, secretarias y empleados sólo como trabajadores de una organización, no importando su cargo. Aquí la interpretación debe ser lo suficientemente abstracta para que diferentes vistas del mundo se vean de la misma forma.

Modelamiento de Datos La interpretación del mundo real es necesaria, ya que de este ambiente tomaremos las bases para crear nuestro modelo. Además, debe ser suficientemente abstracta para que no sea afectada por la dinámica del mundo (al utilizar elementos del mundo real, suelen producirse pequeños cambios en él que pueden afectar nuestro modelo), y debe ser suficientemente robusta para poder representar cómo los datos y el mundo real se relacionan. Una herramienta como esta es llamada modelo de datos, el cual permite representar en forma más o menos razonable alguna realidad. El modelo de datos permite realizar abstracciones del mundo, permitiendo centrarse en los aspectos macros, sin preocuparse de las particularidades; así nuestra preocupación se centra en generar un esquema de representación, y no en los valores de los datos. En la unidad siguiente, retomaremos el tema de abstracciones con mayor profundidad. Los modelos de datos nos permiten capturar parcialmente el mundo, ya que es improbable generar un modelo que lo capture totalmente. Sin embargo, se puede tener un conocimiento relativamente completo de la parte del mundo que nos interesa. Así, un modelo captura la cantidad de conocimiento tal que cumpla con los requerimientos que nos hemos impuesto previamente.




DATO: la siguiente tupla:

Esta definición es correcta, ya que cada vez que se describe un fenómeno, éste se refiere a un objeto (nombre del objeto) y ciertas características (propiedades del objeto) el cual tiene un valor en un momento determinado (tiempo). El precio del pan es $1,60. D Ejemplo nombre: precio del pan propiedades: valor: tiempo:

(unidad, $), entero no negativo. 1,60 hoy

En general, el modelar un objeto no se considera el tiempo, sino que éste se considera implícito en la semántica de él.

16

INSTITUCIÓN CERVANTES

Área Informática Base de Datos I

INSTITUCIÓN CERVANTES

Consideremos el caso de una matriz: D Ejemplo nombre: matriz_coeficiente propiedades: valor:




+, –, *, a[i,j] * R [1 2] [3 4]

Esquema Para una aplicación particular de un modelo de datos, el modelamiento de la realidad se llama esquema.

Un esquema es una definición genérica que identifica categorías (ejemplo: libro, autor, etc.), sus propiedades (nombre, título) y sus relaciones (escrito). Por ejemplo, un modelo de datos simple es una archivo (tabla). Aplicando este modelo a una situación particular se puede tener el siguiente esquema: Persona (Nombre, Edad, Dirección), donde Persona es el nombre genérico de una entidad, y Nombre, Edad y Dirección son nombres genéricos para los atributos.

Modelo de Datos: Introducción Un modelo de datos define las reglas por las cuales los datos son estructurados. Esta estructuración, sin embargo, no da una interpretación completa acerca del significado de los datos y la forma en que serán usados. Las operaciones que se permiten efectuar a los datos deben ser definidos.

D Ejemplo Una lista puede ser tratada como pila o fila, dependiendo de las operaciones que se permitan sobre ella.

Generalmente las operaciones están relacionadas con la estructura de los datos y tienen validez en el contexto en que fueron definidos. Todo modelo de datos debe poder capturar las propiedades estáticas y dinámicas de una realidad. Las propiedades estáticas corresponden a lo que es relativamente invariante en el tiempo, son siempre verdadero y no cambia en el tiempo.

D Ejemplo: Que los precios se midan en $ es relativamente invariante. Las propiedades dinámicas corresponden a la naturaleza evolutiva del mundo. Por esto, para todo modelo debe ser posible capturar los dos tipos de propiedades. Institución Cervantes

17

INSTITUCIÓN CERVANTES




Modelo de Datos Se define el modelo de datos M consistente de dos partes: G: un conjunto de reglas que lo generan. O: un conjunto de operaciones.

El conjunto de reglas G expresan las propiedades estáticas de un modelo de datos y corresponden a lo que se denomina generalmente Data Definition Language (DDL). Este define las estructuras permitidas para el modelo de datos M. El conjunto G se puede dividir en dos:
Gs: las estructuras permitidas.
Gc: las restricciones del modelo. Así, Gs genera las categorías y estructuras para un modelo, y Gc las restricciones. Utilizando esta última notación, un esquema S consiste de dos partes: una estructura Ss y restricciones Sc t23 deben ser violadas.

t33, donde Sc es una lista explícita de restricciones que no

Por ejemplo, en la definición de la entidad persona, un atributo particular CI (Cédula de Identidad) puede ser declarado como clave, esto es, en un instante dado no puede haber dos personas con el mismo valor para CI. Ss no prohíbe dos ocurrencias, pero Sc sí. Las propiedades dinámicas de un modelo de datos son expresadas por un conjunto de operaciones O, las que generalmente son llamadas Data Manipulation Language (DML). Estas propiedades definen las acciones permitidas para una base de datos, tal que transforme la ocurrencia Di en la ocurrencia Dj. t43 No todas las operaciones definidas en O causan cambios en la base de datos, pero si causan un cambio en el estado de ella. El estado de una base de datos no es un objeto de ella, pero está asociado a la base de datos, y cambia como resultado de una operación. Ejemplo. Consideremos el modelo de datos tipo Tabla; este modelo tiene como una de sus operaciones la operación "read", que permite recorrer la tabla en forma secuencial. Esta operación no cambia el contenido de la Base, pero si su estado (cambia el registro actual, que ahora es el siguiente).

18

INSTITUCIÓN CERVANTES

INSTITUCIÓN CERVANTES

Área Informática Base de Datos I

Autoevaluación 1. Describa brevemente que es un modelo de datos: ........................................................................................ ........................................................................................ 2. ¿Cuáles son las ventajas de trabajar con Bases de Datos y no con archivos? ........................................................................................ ........................................................................................ 3. ¿Qué diferencia existe entre esquema y modelo? ........................................................................................ ........................................................................................ 4. ¿Cuáles son los pasos necesarios para el diseño de una Base de Datos? ........................................................................................ ........................................................................................ 5. Explique dentro del diseño de un sistema de información, que función cumple el diseño de una Base de Datos. ........................................................................................ ........................................................................................ 6. ¿Cuál es la diferencia entre una Base de Datos y un sistema de archivos tradicional? ........................................................................................ ........................................................................................ 7. ¿Por qué se dice que las bases de datos son autodescriptivas? ........................................................................................ ........................................................................................ 8. Defina ahora, que entiende por Base de Datos y comente si el concepto que tenía al iniciar el curso cambió o no. ........................................................................................ ........................................................................................ 9. Defina el término METADATO. ........................................................................................ ........................................................................................

Institución Cervantes

19

INSTITUCIÓN CERVANTES

20

INSTITUCIÓN CERVANTES

Área Informática Base de Datos I

INSTITUCIÓN CERVANTES




Unidad II

Modelado de Datos Objetivos
Conocer los distintos mecanismos de abstracción.
Adquirir los conceptos para realizar la construcción de esquemas conceptuales.
Comprender y reconocer las distintas etapas para el diseño de una base de datos.

Institución Cervantes

21

INSTITUCIÓN CERVANTES

En la unidad anterior, describimos que era modelar datos y que era el modelamiento. Hablamos de que era necesario utilizar métodos abstractos para la descripción de la realidad en cuestión. Recordemos el siguiente concepto: Los modelos de datos son vehículos utilizados para describir la realidad. Los programadores usan los modelos de datos para construir esquemas, los cuales son representaciones gráficas de la realidad. La calidad de los esquemas resultantes depende no sólo de la habilidad de los programadores, sino también de las características del modelo de datos seleccionado. El bloque de construcción común a todos los modelos de datos es una pequeña colección de mecanismos de abstracción primitivos: Clasificación, agregación y generalización. Las abstracciones ayudan al programador a entender, clasificar y modelar la realidad.

Procesos de Abstracción en el modelamiento de Datos La abstracción es un proceso mental que se aplica al seleccionar algunas características y propiedades de un conjunto de objetos y excluir otras no pertinentes. En otras palabras, se hace una abstracción al fijar la atención en las propiedades consideradas esenciales de un conjunto de cosas y desechar sus diferencias. En el modelamiento de datos, se usan tres tipos de abstracciones: clasificación, agregación y generalización. 1. Abstracción de clasificación: se usa para definir un concepto como una clase de objetos de la realidad caracterizados por propiedades comunes. Por ejemplo, tenemos que el concepto NOMBRE DE ALUMNO es la clase cuyos miembros son todos NOMBRES (Juan, José, Luis, etc.). Se representa gráficamente la clasificación como un árbol de un nivel, que tiene como raíz la clase y como hojas los elementos de la clase; las ramas del árbol se representan por líneas discontinuas. Cada rama del árbol indica que un nodo hoja es un miembro de la clase que representa la raíz. Se pueden obtener clases con diferentes elementos, y cada elemento puede pertenecer a varias clases.

Nombre de Alumno Juan

José

...

Luis

Este mecanismo, es por lo general el primero que intuitivamente se utiliza, ya que todas las personas somos capaces de reconocer a los objetos de la realidad por su nombre y dirán ese es Juan, alumno del Instituto. O sea que Juan es intuitivamente una propiedad del objeto reconocida. Este mecanismo es muy utilizado por los programadores inexpertos o aquellos que están haciendo sus primeros trabajos como profesionales de la informática. 22

INSTITUCIÓN CERVANTES

Área Informática Base de Datos I

INSTITUCIÓN CERVANTES

2. Abstracción de agregación: Define una nueva clase a partir de un conjunto de otras clases que representan sus partes componentes. Se representa por un árbol de un nivel en el cual todos los nodos son clases; la raíz representa la clase creada por agregación de las clases representadas en las hojas. Cada rama del árbol indica que una clase hoja es una parte de (ES_PARTE_DE) la clase representada por la raíz. Para distinguirla de la agregación de clasificación, las ramas dirigidas están representadas por líneas dobles que van de los componentes a los objetos agregados.

Persona

DNI

nombre

dirección teléfono

La clasificación y la agregación son las dos abstracciones básicas utilizadas para construir estructuras de datos dentro de la base de datos y dentro de los lenguajes convencionales de programación. La clasificación es el procedimiento utilizado cuando, partiendo de elementos individuales de información, se identifican tipos de campos o atributos. La agregación es el procedimiento mediante el cual se reúnen tipos de campos relacionados en grupos como por ejemplo tipos de registros. 3. Abstracción de Generalización: Define una relación de subconjunto entre elementos de dos o más clases. Cada generalización se representa con un árbol de un nivel, en el que todos los nodos son clases, con la clase genérica como raíz y las clases subconjunto como hojas; cada rama del árbol expresa que una clase hoja es un (ES_UN) subconjunto de la clase raíz. Para distinguir la generalización de otras abstracciones, se usa una flecha sencilla apuntando hacia la raíz. Esta abstracción, a pesar de ser muy común e intuitiva, no se usa en muchos modelos de datos. Sin embargo es muy útil por su cualidad fundamental de herencia: en una generalización, todas las abstracciones definidas para la clase genérica son heredadas por las clases subconjunto.

Persona

Negro

Blanco

Los tres mecanismos son independientes: ninguno de ellos puede describirse en función de los otros, y cada uno proporciona un mecanismo diferenciado en el proceso de estructuración de la información. La independencia de las tres interrelaciones de conceptos establecidas por las abstracciones: la clasificación corresponde a la membresía (interrelación de pertenencia) (ES_PARTE_DE); y la generalización, a la inclusión (interrelación de subconjunto) en conjuntos (ES_UN).

Institución Cervantes

23

INSTITUCIÓN CERVANTES

Propiedades de las correspondencias entre las clases Las abstracciones de agregación y generalización establecen correspondencias entre clases. En los puntos subsiguientes veremos las características de estas correspondencias. Primero se consideran las agregaciones binarias, que son agregaciones entre dos clases; después se consideran las agregaciones n-arias o agregaciones entre n o más clases. Por último, se consideran las generalizaciones. 1. Agregación Binaria: es una correspondencia o vínculo que se establece entre dos clases. Se puede representar una correspondencia binaria entre dos clases como sigue: se describe a las dos clases como conjuntos y se traza una línea desde un elemento de un conjunto a un elemento del otro conjunto, cada vez que los dos elementos estén agregados.

a1 a2 a3 a4 a5

p1 p2 p3

Automóviles Personas Al observar la figura, se puede decir que la persona p1 posee los autos a1 y a2, la persona p2 posee los autos a2, a4 y a5, mientras que la persona p3 no posee autos. De esto último se puede observar que no es obligatorio que todas las personas posean autos, pero al parecer todos los autos deben tener un dueño. Esta última característica es propia de cada agregación, y se refieren a la cardinalidad de correspondencia entre las clases. a) Cardinalidad mínima (card-min): considérese una agregación entre las clases C1 y C2. La cardinalidad mínima de C1 en A, denotada por card-mín (C1, A), es el menor número de correspondencias en las que cada elemento de C1 puede tomar parte. Asimismo, la cardinalidad mínima de C2 en A, representada como card-min (C2, A), en el mismo número de correspondencias en las que cada elemento de C2 puede participar. Si consideramos las agregaciones USA y POSEE entre PERSONA Y EDIFICIO:
Si se supone que cada persona usa al menos un edificio, entonces, card-min (PERSONA, USA)=1.
Si se supone que algunos edificios no están habitados, entonces, card-min (EDIFICO, USA)=0.
Si se supone que algunas personas no poseen un edificio, entonces, card-min (PERSONA, POSEE)=0.
Si se supone que cada uno de los edificios debe pertenecer a una persona entonces, card-min (EDIFICIO, POSEE)=1. 24

INSTITUCIÓN CERVANTES

Área Informática Base de Datos I

INSTITUCIÓN CERVANTES

Estos ejemplos muestran que los valores importantes de card-min (C1, A) son 0 y 1 respectivamente. La cardinalidad mínima raras veces toma valores diferentes. Si card-mín (C1, A)=0, se dice que la clase C1, tiene una participación opcional en la agregación, porque algunos elementos de la clase C1 pueden no tener correspondencia en la agregación A con elementos de la case C2. Si card-mín (C1, A) >0, se dice que la clase C1 tiene una participación obligatoria en la agregación, ya que cada elemento de la clase C1 debe corresponder, al menos a un elemento de la clase C2. b) Cardinalidad máxima (card-máx): Considérese la agregación A entre las clases C1 y C2. La cardinalidad máxima de C1 en A, que se representa como card-máx (C1, A), es el mayor número de correspondencias en las que cada elemento de C1 puede participar. Asimismo, la cardinalidad máxima de C2 en A, denotada por card-máx (C2, A), es el mayor número de correspondencias en las que puede participar cada elemento de C2. a)

b) c1 c2 c3 c4

d1

c1 c2

d2

c3

d3

c)

c4

d1 d2 d3

d) c1 c2 c3 c4

d1 d2 d3

c1 c2 c3 c4

d1 d2 d3

a) Agregación Uno a Uno. Card(C,A)=(x,1) y Card(D,A)=(x,1), con x en {0,1}. b) Agregación Uno a Muchos. Card(C,A)=(x,n) y Card(D,A)=(y,1), con x en {0,1,...,n} e y en {0,1}. c) Agregación Muchos a Uno. Card(C,A)=(x,1) y Card(D,A)=(y,n), con x en {0,1} e y en {0,1,...,n}. d) Agregación Muchos a Muchos. Card(C,A)=(x,n) y Card(D,A)=(y,m), con x e y en {0,1,...,n), n y m valores indefinidos mayores que uno. Consideremos de nuevo las agregaciones USA y POSEE entre PERSONA y EDIFICIO:
Si se supone que cada persona usa varios edificios, card-máx (PERSONA, USA) = n. Tutor-5
Si se supone que cada EDIFICIO puede tener varios habitantes, entonces, card-máx (EDIFICIO, USA)=n. Institución Cervantes

25

INSTITUCIÓN CERVANTES

Si se supone que cada persona puede poseer varios edificios, entonces, cardmáx (PERSONA, POSEE)=n.
Si se supone que cada edificio pertenece sólo a una persona, entonces, cardmín (EDIFICIO, POSEE)=1 y card-máx (EDIFICIO, POSEE).


Estos ejemplos muestran que los valores importantes para card-máx (C1, A) son 1 y n; n representa cualquier número e indica que cada elemento de C1 puede pertenecer a un número arbitrariamente grande de correspondencias. Card-máx pocas veces adopta un valor fijo. Si card-máx (C1, A)=1 y card-máx (C2, A)=1, se dice que la agregación es de uno a uno. Si card-máx (C1, A)=n y card-máx (C2, A)=1, la agregación de C2 a C1 es de uno a muchos. Si card-máx (C1, A)=1 y card-máx (C2, A)=n, la agregación de C2 a C1 es de muchos a uno; por último, si card-máx (C1, A)=m y card-máx (C2, A)=n (donde m y n representa valores superiores a 1), la agregación de C2 a C1 es de muchos a muchos. 2. Agregación n-aria: Es una correspondencia establecida entre tres o más clases. Se mantienen las definiciones de cardinalidades máxima y mínima. Cardinalidad Mínima. Consideremos una agregación A entre las clases C1,C2,..., Cn. La cardinalidad mínima de Ci en A, denotada por card-min(Ci,A), es el menor número de correspondencias en las que cada elemento de Ci puede tomar parte. Cardinalidad Máxima. Consideremos una agregación A entre las clases C1,C2,..., Cn. La cardinalidad máxima de Ci en A, denotada por card-max(Ci,A), es el mayor número de correspondencias en las que cada elemento de Ci puede tomar parte.

Jerarquías de Generalización Una abstracción de generalización establece una correspondencia entre la clase genérica (raíz) y las clases subconjunto. Tomemos la clase PERSONA como una generalización de las clases HOMBRE y MUJER; cada elemento de éstas corresponde exactamente a un elemento de la clase PERSONA. En esta generalización, cada persona corresponde también a un elemento de la clase HOMBRE o un elemento de la clase MUJER; sin embargo, esto no ocurre en todas las generalizaciones. Estas observaciones se refieren a las propiedades de cobertura de la generalización, que se describen formalmente a continuación: 1. Cobertura Total o Parcial. La cobertura de una generalización es total (t), si cada elemento de la clase genérica corresponde al menos a un elemento de las clases subconjuntos; es parcial (p), si existe algún elemento de la clase genérica que no corresponde a ningún elemento de las clases subconjunto. 2. Cobertura exclusiva o superpuesta. La cobertura de una generalización es exclusiva (e), si cada elemento de la clase genérica corresponde, a lo máximo, a un elemento de las clases subconjunto; es superpuesta (s) si, al contrario, existe algún 26

INSTITUCIÓN CERVANTES

Área Informática Base de Datos I

INSTITUCIÓN CERVANTES

elemento de la clase genérica que corresponde a elementos de dos o más clases subconjunto diferentes. Ejemplos

Persona Hombre

Mujer

a) total, exclusiva. Todas las personas son Hombres o Mujeres, pero no ambos.

Empleado Administrativo

Docente

b) total, superpuesta. Todos los empleados son Administrativos o Docentes, pudiendo haber empleados desempeñando ambas funciones.

Estudiante Egresado

Títulado

c) parcial, exclusivo. Algunos estudiantes son egresados, mientras que otros están titulados, pero no hay ningún estudiante en ambas situaciones.

Estudiante Ingeniería Postgrado d) parcial, superpuesta. Algunos estudiantes son de Ingeniería y otros son de postgrado, y hay algunos estudiantes que son de ingeniería y también participan en postgrado.

Modelos de Datos En la unidad anterior, hemos visto algunos conceptos que creo conveniente enunciar para que los tengamos en cuenta: Dato, modelo, esquema y modelo de datos. Si estos conceptos no se recuerdan en esta instancia, creo conveniente recomendarles que los repasen a fin de poder continuar con los conceptos que a continuación analizaremos. Si están presentes, pues adelante.

Institución Cervantes

27

INSTITUCIÓN CERVANTES

Un modelo de datos es una serie de conceptos que pueden utilizarse para describir un conjunto de datos y operaciones para manipular los mismos. Cuando un modelo de datos describe un conjunto de conceptos de una realidad determinada, se llama modelo conceptual de datos. Los conceptos de un modelo de datos se construyen por lo regular usando mecanismos de abstracción y se describen mediante representaciones lingüísticas y gráficas. Hay dos tipos de modelos de datos: modelos conceptuales, usados en el diseño de bases de datos, y modelos lógicos, apoyados por los sistemas de gestión de base de datos (DBMS), que son grandes paquetes de software que crean, modifican y mantienen base de datos. Modelos Conceptuales: Son instrumentos para representar la realidad a un nivel alto de abstracción. Utilizando los modelos conceptuales, podemos construir una descripción de la realidad, fácil de entender e interpretar. Modelos Lógicos: Estos apoyan descripciones de datos procesables por un computador; incluyen el modelo jerárquico, el modelo codasyl (o de redes) y el modelo relacional. Estos modelos tienen una correspondencia sencilla con la estructura física de la base de datos. Más adelante se volverá a hacer referencia a estos modelos, mostrando con un ejemplo como funcionan. En el diseño de bases de datos se usan primero los modelos conceptuales para lograr una descripción de alto nivel de la realidad; después se transforma el esquema conceptual en un esquema lógico. La razón de este enfoque radica en la dificultad de abstraer la estructura de bases de datos complejas. Un esquema es una representación de una parte específica de la realidad, creada utilizando un determinado modelo de datos. Dicho con mayor propiedad, un esquema es un conjunto estático de representaciones lingüísticas o gráficas, invariables en el tiempo, que describen la estructura de los datos de interés, como por ejemplo los de una organización.

El modelo de entidades-interrelacionadas (ER) Este es el modelo de datos más ampliamente usado para el diseño conceptual de bases de datos. El modelo fue introducido por Peter Chen en 1976, y se ha hecho cada vez más popular. Originalmente el modelo ER incluía sólo los conceptos de entidad, interrelación y atributos; más tarde, otros conceptos, como los atributos compuestos y las jerarquías de generalización, se agregaron como componentes de modelo ER mejorado.

Elementos básicos del modelo Entidad Relación En 1976, Peter Chen publicó el modelo entidad relación, el cual tuvo gran aceptación principalmente por su expresividad gráfica. Sobre esta primera versión han trabajado numerosos autores, generando distintas extensiones de mayor o menor utilidad y de aceptación variable en el medio académico y profesional. Muchas de estas extensiones 28

INSTITUCIÓN CERVANTES

Área Informática Base de Datos I

INSTITUCIÓN CERVANTES

son muy útiles, pero poco difundidas debido principalmente a la ausencia de herramientas automatizadas que apoyen su uso. A continuación se definen los elementos del modelo entidad relación básico. Los conceptos básicos provistos por el modelo ER son atributos, identificadores, interrelaciones y entidades. Entidades: las entidades representan clases de objetos de la realidad. Es un objeto que existe y puede ser distinguido de otro objeto. Persona, hombre, mujer, empleado, ciudad son ejemplos de entidades para una base de datos de personal. Las entidades se representan gráficamente por medio de rectángulos, como se muestra a continuación. Una entidad se distingue de otra porque posee ciertas características que la hacen única. A estas características se les conoce como atributo. Tipo de Entidad Atributos: Los atributos representan las propiedades básicas de las entidades o interrelaciones. Toda la información extensiva es portada por los atributos. Por ejemplo los atributos de una entidad persona pueden ser: , , . Los atributos de una entidad ciudad pueden ser: nombre, altitud, númerodehabitantes. El único atributo de es , con la fecha en que la persona se mudó a la ciudad. El único atributo de es . La forma de representar a los atributos es: Nombre Atributo Un atributo en el modelo E-R se puede clasificar entre los siguientes tipos:
Simples y Compuestos. Un atributo simple no está dividido en subpartes y un atributo compuestos se pueden dividir es subpartes. Ej: nombre-cliente se puede dividir en apellido-cliente y nombre-cliente, la fecha-nacimiento se puede dividir en día, mes y año de nacimiento.
Univaluados y multivaluados. Los atributos que tienen un único valor para una entidad concreta. Si consideramos un conjunto de entidades empleado con el atributo nombre-subordinado, cualquier empleado puede tener 0, 1 o varios subordinados, por lo tanto diferentes entidades empleado dentro del conjunto de entidades tendrán diferentes números de valores para el atributo nombresubordinado. Este atributo se llama multivaluado.
Atributos nulos: se usa cuando una entidad no tiene un valor para el atributo. Por ejemplo si un empleado no tiene subordinados, el valor nombre-subordinado para ese empleado será nulo.
Atributos derivados: son valores que se pueden derivar de otros atributos o entidades. Por ejemplo: la entidad empleado que posee los atributos de fechaingreso y antigüedad. El valor de antigüedad se puede derivar del valor de fechaingreso y de fecha-actual. En este caso el atributo fecha-ingreso se puede referenciar como atributo base. Institución Cervantes

29

INSTITUCIÓN CERVANTES

Identificador de un tipo de entidad: Un atributo, posiblemente compuesto, de un tipo de entidad TE, es un Identificador de TE si y sólo si satisface las siguientes 2 propiedades independientes del tiempo. a. Unicidad. En cualquier momento dado, no existen dos elementos en TE con el mismo valor de I. b. Minimalidad. Si I es compuesto, no será posible eliminar ningún atributo componente de I sin destruir la propiedad de unicidad.

Tipo de Entidad

Atributo identificador

Interrelaciones o Relaciones: Los Tipos de interrelación representan agregaciones de dos o más entidades (interrelaciones binarias o narias) no necesariamente diferentes (como son las interrelaciones recursivas). El Identificador de un Tipo de Interrelación, se forma a partir de los identificadores de los tipos de entidad que relaciona. Las interrelaciones se representan gráficamente con rombos como se representa en la figura anterior. Las interrelaciones n-arias conectan más de dos entidades.

Tipo de Entidad 1

Tipo de Interrelación

Atributo 1 ... Atributo n

Tipo de Entidad 2

D Ejemplo La relación dueño-de puede ser interpretada como un tipo de interrelación entre dos tipos de entidades Persona y Auto.

Los anillos son interrelaciones binarias que conectan una entidad consigo misma. Se conocen también como interrelaciones recursivas. Por ejemplo la interrelación dirige de la figura siguiente conecta los directores con sus subordinados, ambos representados por la entidad empleado. Para distinguir entre los dos papeles de la entidad de la interrelación, se asocian dos rótulos con la entidad; en la figura siguiente los dos rótulos son y . Cardinalidad de tipo de entidad con respecto a un tipo de interrelación: Para los tipos de interrelación la cardinalidad máxima (mínima) establece el mayor (menor) número de correspondencias en cada una de los tipos de entidad involucradas en la interrelación. Se define la Cardinalidad del Tipo de Entidad TE con respecto al tipo de interrelación R como: Card(TE,R) = (mínimo, máximo), con mínimo, máximo ∈ {0,...,n} y mínimo ≤ máximo. 30

INSTITUCIÓN CERVANTES

Área Informática Base de Datos I

INSTITUCIÓN CERVANTES

donde toda ocurrencia de TE debe participar al menos mínimo veces, y a lo más máximo veces en R.

(mínimo, máximo) TE

R

Los Mecanismos de abstracción en el modelo ER (Entidad-Relación) Abstracción de clasificación: Los tres conceptos básicos del modelo ER, se desarrollan como aplicaciones de la abstracción de clasificación: 1. Una entidad es una clase de objetos del mundo real con propiedades comunes. 2. Una interrelación es una clase de hechos atómicos (elementales) que relacionan dos o más entidades. 3. Un atributo es una clase de valores que representan propiedades atómicas de las entidades o interrelaciones. Abstracción de agregación: Tres tipos de agregaciones caracterizan al modelo ER: 1. Una entidad es una agregación de atributos. 2. Una interrelación es una agregación de entidades y atributos. 3. Un atributo compuesto es una agregación de atributos. Abstracción de generalización: La abstracción de la generalización las encarnan las jerarquías de generalización y los subconjuntos. Usualmente sólo se aplica a entidades, aunque algunas ampliaciones del modo ER aplican la abstracción de generalización también a interrelaciones o atributos.

Cualidades del modelo ER Es cierto que el modelo ER no es muy sencillo. En particular, las propiedades de cardinalidad e identificación son difíciles de entender y usar. Sin embargo, estos rasgos son muy útiles para entender las propiedades estructurales de los esquemas de bases de datos. A pesar de las apariencias, el modelo ER es mínimo. Ningún concepto puede sustituirse por otra combinación de conceptos, con la única excepción de los atributos compuestos. El modelo ER está definido formalmente, como se ha mostrado en esta unidad. También es gráficamente completo: cada uno de los conceptos presentados en este apartado puede representarse en un esquema.

Institución Cervantes

31

INSTITUCIÓN CERVANTES

Los diagramas del modelo ER son fáciles de leer, especialmente si uno observa sólo los símbolos gráficos centrales (rectángulos para las entidades, círculos para los atributos, rombos para las interrelaciones, flechas dobles para las jerarquías de generalización, óvalos para los atributos compuestos). La legibilidad decrece si se incluye la cardinalidad de las interrelaciones, la cobertura de las generalizaciones, los identificadores. El esquema obtenido con este modelo, (el diagrama ER), es por lo general estático en el tiempo, debido a que un correcto análisis del problema y a un planteo exacto de la solución del mismo, evitará que el esquema deba sufrir retoques en el futuro. Una vez obtenido el esquema, es muy difícil que varíe su estructura. Recordemos las distintas etapas del diseño de una Base de datos: Conceptual, lógico y físico. De estas etapas, la única estática es la conceptual, ya que como dijimos, no sufrirá alteraciones si se realizó un buen trabajo de análisis. Las otras etapas, variarán según el modelo de implementación utilizado, como se ve reflejado en el cuadro de la página 15 de este módulo. Por último, el modelo ER representa un buen término medio entre el poder de expresión, la simplicidad y la minimalidad. Muchas Críticas al modelo, pueden deberse a una presentación pobre de sus cualidades.

D Ejemplo
Tipos de entidades y

Auto: Persona:

atributos Patente (identificador) Año Fabricación Color DNI (identificador) Nombre


Tipos de Interrelaciones

Dueño_de:

Fecha


Diagrama MER

Persona

(1,n) Dueño de

(1,1)

Auto @ Patente

@ Dni Fecha Nombre

Color

(1,n): Una persona puede tener uno o más autos (1,1): Un auto puede tener sólo un dueño.

D Ejercicio resuelto Modelar un sistema de biblioteca que permita saber:
autor de un libro 32

INSTITUCIÓN CERVANTES

INSTITUCIÓN CERVANTES

Área Informática Base de Datos I

libros de un autor
préstamos de un alumno.
materia de un libro
editorial de un libro


Desarrollo
Tipos de entidad




Autor @ Código Autor Nombre Fecha Nacimiento (fecha) Nacionalidad Libro @ Código Libro Título Año Publicación Alumno @ Matrícula Nombre Ejemplar @ Código Ejemplar Materia @ Código Materia Materia Carrera @ Código Carrera Editorial @ Código Editorial Editorial
Tipos de Interrelaciones

Autor_de: @ Código Libro @ Código Autor Estudia: @ Matrícula @ Código Carrera Préstamo: @ Código Ejemplar Institución Cervantes

33

INSTITUCIÓN CERVANTES

@ Matrícula Fecha_préstamo Fecha_devolución Editado_por: @ Código Editorial @ Código Libro Ejemplar_de: @ Código Ejemplar @ Código Libro Es_de: @ Código libro @ Código Materia
Diagrama MER

(1,n) Carrera

(1,1)

(0,3)

Estudia

Préstamo

Alumno

(0,1)

Autor Materia

Ejemplar

(1,n)

(1,1) Autor_de

(1,n)

(1,n)

Es_de

(1,n)

Libro

Ejemplar_de

(1,n)

(1,1)

Editado_por

(1,n)

Editorial

Lectura de las cardinalidades:
Un Alumno estudia una y sólo una Carrera.
Una Carrera es estudiada por uno o muchos Alumnos. 34

INSTITUCIÓN CERVANTES

INSTITUCIÓN CERVANTES













Área Informática Base de Datos I

Un Alumno puede tener en préstamo ninguno o a lo más tres Ejemplares. Un Ejemplar puede no estar en préstamo o estar en Préstamo a lo más una vez. Un Ejemplar corresponde a uno y sólo un Libro. Un Libro tiene uno o muchos Ejemplares. Un Autor es autor de uno o muchos Libros. Un Libro fue escrito por uno o muchos Autores. Un Libro es acerca de una o muchas Materias. Una Materia es abordada por uno o muchos Libros. Una Libro es editado por una y sólo una Editorial. Una Editorial ha editado uno o muchos Libros.

Se puede apreciar en este ejercicio que las interrelaciones cumplen un rol muy importante dentro del esquema construido. En alguna de ellas, aparecen atributos que ya se encuentran en las entidades que se vinculan generando redundancia de datos física, la cual no es perjudicial ya que la función de esta duplicación es la de mantener las relaciones entre las entidades participantes. Este tipo de redundancia, es la que habíamos hablado en la unidad anterior (introducción) que podía aparecer y que estaba permitida. Este resultado (que estudiaremos más adelante como conseguirlo) se obtiene mediante la transformación de esquemas, es decir el paso del esquema conceptual al esquema lógico.

Cómo Modelar en MER Para modelar en MER se sigue generalmente el siguiente orden: a. b. c. d. e.

Identificar los tipos de entidades. Identificar los tipos de interrelaciones. Encontrar las cardinalidades. Identificar los atributos de cada tipo de entidad. Identificar las claves de cada tipo de entidad.

La regla básica es distinguir tipos de entidades e interrelaciones de atributos. Así, los atributos deben ser atómicos y característicos del tipo de entidad o interrelación que describan. También los atributos deben pertenecer al tipo de entidad o interrelación que describen y no a otro tipo. Otra diferencia entre tipo de entidad y atributo es que, por ejemplo, se puede tener el tipo de entidad Empleado, que tiene como atributo el departamento al que pertenece. En forma alternativa se pueden tener los tipos de entidades Empleado y Departamento, y el tipo de interrelación Trabaja_en, que relaciona un empleado con el departamento donde trabaja. Esta segunda alternativa es mejor desde el punto de vista del modelamiento conceptual y presenta una clara diferencia entre atributo y tipos de entidad. Institución Cervantes

35

INSTITUCIÓN CERVANTES

Autoevaluación 1. Defina los mecanismos de abstracción. Para que se utilizan. ........................................................................................ ........................................................................................ 2. Qué entiende por el concepto de cardinalidad. Ejemplifique cada una. ........................................................................................ ........................................................................................ 3. Describa el proceso de modelar datos utilizando el modelo ER. ........................................................................................ ........................................................................................ 4. Explique las propiedades de la agregación y de la generalización entre clases. ........................................................................................ ........................................................................................ 5. Cuáles son los elementos básicos del modelo ER. ........................................................................................ ........................................................................................ 6. Qué cualidades del modelo ER cree conveniente destacar. ........................................................................................ ........................................................................................ 7. Señalar en una narración, entidades, los atributos y las relaciones entre las mismas de un problema planteado por usted. ........................................................................................ ........................................................................................ 8. A partir de un diagrama ER que usted deberá crear, hacer la narración del mismo proponiendo el problema. ........................................................................................ ........................................................................................

36

INSTITUCIÓN CERVANTES

Área Informática Base de Datos I

INSTITUCIÓN CERVANTES




Unidad III

Arquitectura de las bases de datos Objetivos
Reconocer las diferentes funciones de los actores en la administración física de una

base de datos.
Comprender el funcionamiento de los diferentes tipos de estructuras de datos.
Distinguir los diferentes tipos de estructuras de bases de datos.
Distinguir las diferentes capas de la arquitectura de una base de datos.

Institución Cervantes

37

INSTITUCIÓN CERVANTES

Estructuras de Bases de Datos Todos los sistemas operativos proporcionan servicios de administración de datos. Sin embargo, no son suficientes para las necesidades especializadas de un DBMS. Para mejorar el rendimiento, los productos DBMS construyen y mantienen estructuras especializadas de datos. Este mantenimiento de los datos, lo realiza el mismo MOTOR o DBMS de la base de datos. Los procesos que veremos y estudiaremos a continuación, son realizados por este componente, integrante fundamental de todo sistema de base de datos.

Archivos Planos Las estructuras de datos que manejan los DBMS, se conocen como archivos planos. Un archivo plano es un archivo que no posee grupos repetidos. En la siguiente figura aparece un archivo plano (A) y en (B) aparece un archivo que no es plano en razón del campo que se repite, Ítem. Un archivo plano puede ser almacenado con cualquier organización común de archivos como secuencial, secuencial indexada, o directa. Los archivos planos han sido utilizados a lo largo de muchos años en el procesamiento de datos comerciales. Son procesados en un orden predeterminado, en secuencia ascendente sobre un campo clave o no. Archivo Plano Registro de inscripción (A) NumEstudiante Datos de muestra (A) 200 100 300 200 300 100

Archivo NO Plano Registro de Facturas (B)

NumClase

Semestre

70 30 20 30 70 20

88S 89F 89F

NumFactura

Artículo(s)

Datos de Muestra (B) 1000 10 20 1010 50 1020 10 20 1030 50 90

30

20

30

88S 88S

Como se interpreta esto: lo primero que debemos tener en cuenta y recordar son las definiciones de archivo, registro y campo. Una vez que lo hayan recordado, tomaremos el ejemplo de Inscripción que llamaremos A y el de Facturas, que llamaremos B. El registro A es una estructura PLANA, debido a que en cada uno de sus registros la cantidad de campos o columnas que lo integran, está siempre dentro del mismo rango, es decir que a lo largo de todo el archivo, la cantidad de campos o columnas es siempre la misma. Puede ser que el valor para alguna intersección (fila, columna) no este disponible en ese momento, pero el lugar está reservado para recibir un valor en cualquier instante. Observen la fila cuyos valores son (200, 30, blanco). El componente o valor del semestre aun no ha sido ingresado, pero la estructura sigue manteniendo su capacidad de recibir el dato, y además esa intersección ocupa un lugar en la estructura. Es decir, no está el valor pero se conserva el espacio reservado. En el caso de la estructura B (Facturas), los espacios no se conservan ni se reservan. Aparecen lo que se conoce como grupos repetidos. Los grupos repetidos son aquellos 38

INSTITUCIÓN CERVANTES

Área Informática Base de Datos I

INSTITUCIÓN CERVANTES

componentes de la estructura que pueden aparecer más de una vez en el mismo registro, como por ejemplo el Artículo. En una factura pueden existir varios artículos facturados. En este tipo de estructura, en un mismo registro, pueden guardarse varios artículos, pero no en cada registro siempre se encontrará la misma cantidad de artículos ingresados. Observen el caso B y verán la diferencia entre la cantidad de artículos del primer registro y de los posteriores. Los grupos repetidos son pues, los artículos, ya que en una misma factura puede haber varios de ellos que son los que formarán el grupo.

Procesamiento de Archivos Planos Lista Secuencial En ocasiones, los usuarios desean procesar los archivos de distintas maneras y necesitan obtener de los datos, información ordenada de distintas maneras. Considere los registros de INSCRIPCIÓN de la figura anterior. Para generar el listado de horarios de estudiantes, deben procesarse según la secuencia u ordenamiento de NumEstudiante. Para producir listados de clases, los registros deben ser procesados y ordenados según la secuencia NumClase, no en ambos a la vez, ya que esto no es posible. La solución tradicional al problema de procesar registros en órdenes distintos. Es clasificarlos primero por estudiante y procesar o generar los horarios, a continuación poner los registros en el orden de clases y producir las listas de clases. Para algunas aplicaciones, como en un sistema de procesamiento por lotes (donde cada registro se procesa uno a continuación del otro sin saltearse ninguno), esta solución aunque torpe es eficaz. Suponga que ambos ordenamientos necesitan existir en forma simultánea, porque dos usuarios necesitan manejar el mismo archivo pero en dos listas distintas en los registros INSCRIPCION. Una solución es crear dos copias del archivo INSCRIPCION y ordenarlas como se muestra en la siguiente figura. Para generar cada una de estas copias del archivo, deberán crearse sendos programas que permitan ejecutar el proceso necesario. Num Estudiante 100 100 200 200 300 300

Num Clase 30 20 70 30 20 70 (A)

Semestre 88F 88S 88S 88S 89F 88S

Num Estudiante 300 100 100 200 200 300

Num Clase 20 20 30 30 70 70 (B)

Semestre 89F 88S 89F 88S 88S 88S

En vista de que los datos quedan listados en orden secuencial, tal estructura de datos a veces se conoce como lista secuencial. Las listas secuenciales se pueden almacenar en archivos secuenciales. Sin embargo, no se hace en productos DBMS, porque la lectura Institución Cervantes

39

INSTITUCIÓN CERVANTES

secuencial de un archivo es un proceso lento, debido a que para poder recorrer el archivo debo ir registro por registro hasta llegar al final del mismo. Los archivos secuenciales no se pueden actualizar en la parte intermedia, sin escribir la totalidad del archivo. Si lo que queremos es agregar un registro y que quede ordenado, primero se agrega el registro (el cual es ingresado en la última posición) y luego se corren los procesos para reordenar las listas. Esto deberá ejecutarse cada vez que se agregue, modifique o elimine algún registro. El mantenimiento de varios órdenes conservando varias copias de la lista secuencial es por lo regular poco eficaz porque las listas secuenciales duplicadas pueden crear problemas de integridad de los datos, duplicación de datos y de espacio de almacenamiento en disco. Otras estructuras de datos nos permiten procesar registros en órdenes distintos y no requieren la duplicación de los datos. Estos casos veremos a continuación.

Mantener un orden con listas vinculadas Las listas vinculadas pueden ser utilizadas para mantener en orden lógico registros que no están en orden físico. Para crear una lista vinculada, agregamos un campo a cada registro de datos. El campo vínculo contiene la dirección del siguiente registro en secuencia lógica. La siguiente figura muestra los registros INSCRIPCION que se han expandido a fin de incluir la lista vinculada; tal lista mantiene los registros en el orden NumEstudiante. Observe que el vínculo para el último estudiante numérico en la lista es cero. Num Nº de Estudiante registro relativo 1 200 2 100 3 300 4 250 5 350 6 150 Inicio de la lista de estudiantes = 2 Inicio de lista de clases = 6

Num Clase 70 30 20 30 70 20

Semestre

Vinculo de Estudiante 4 6 5 3 0 1

88S 89F 89F 88S 88S 88S

Vínculo de Clase 5 1 4 2 0 3

La figura anterior muestra los registros INSCRIPCION con dos listas vinculadas: una de ellas mantiene el orden NumEstudiante y la otra el orden NumClase. Se han agregado dos campos de vinculación a los registros, uno por cada lista. Voy a tratar de explicar como funciona esto: 1. La estructura original es:

40

Num Estudiante

Num Clase

200 100 300 250 350 150

70 30 20 30 70 20

Semestre

88S 89F 89F 88S 88S 88S

INSTITUCIÓN CERVANTES

Área Informática Base de Datos I

INSTITUCIÓN CERVANTES

2. Cada registro (fila) tiene asociado un número que indica la posición de registro relativa (observen la primera columna).

Nº de registro relativo

1 2 3 4 5 6

Num Estudiante

Num Clase

200 100 300 250 350 150

70 30 20 30 70 20

Semestre

88S 89F 89F 88S 88S 88S

3. Luego se establece el menor valor o el valor inicial en la secuencia de Num.Estudiante. Inicio de la lista de estudiantes = 2 ya que en la posición relativa de registro (PRR) 2 se encuentra el valor más bajo de la columna. Una vez establecido el inicio de la secuencia, se busca el valor siguiente que en el caso de NumEstudiante sería el registro de posición relativa 6. En este punto se indica al puntero de lectura que el siguiente registro en la secuencia es el que se encuentra en la posición relativa 6. Cuál será el siguiente? Num Nº de Estudiante registro relativo 1 200 2 100 3 300 4 250 5 350 6 150 Inicio de la lista de estudiantes = 2

Num Clase 70 30 20 30 70 20

Semestre

Vinculo de Estudiante

88S 89F 89F 88S 88S 88S

6

4. Volvamos a observar el cuadro. El siguiente valor en orden es el 200 que se encuentra en la PRR 1. Por lo tanto el puntero se encamina hacia allí. Num Nº de Estudiante registro relativo 1 200 2 100 3 300 4 250 5 350 6 150 Inicio de la lista de estudiantes = 2

Institución Cervantes

Num Clase 70 30 20 30 70 20

Semestre 88S 89F 89F 88S 88S 88S

Vinculo de Estudiante 6

1

41

INSTITUCIÓN CERVANTES

5. Los pasos sucesivos, se realizan de igual manera hasta completar el ordenamiento deseado. El resultado final sería el indicado en el primer cuadro de este tema. El último vínculo, apunta a la posición cero, esto quiere decir que el último registro apunta al final del archivo. Este valor cero, indica que se ha llegado al final del archivo. Indica EOF por ustedes visto en lenguajes de programación. Como ejercitación o práctica, les propongo que traten de armar la misma lista para el otro ordenamiento (vínculo clase). Cuando se efectúan inserciones y supresiones, las listas vinculadas tienen una gran ventaja sobre las listas secuenciales. Por ejemplo, para insertar un registro INSCRIPCION, éste se agrega al extremo físico de la lista o sea al final, y sólo los valores de los campos de vinculación necesitarían ser modificados para colocar el nuevo registro en la secuencia correcta. Cuando se suprime un registro en la lista secuencial, se crea un espacio vacío. En una lista vinculada, se puede suprimir un registro modificando los valores del vínculo, o de los campos del apuntador. Existen muchas variaciones de las listas vinculadas. Podemos convertir la lista en una lista circular, es decir en un anillo, modificando el vínculo del último registro de cero hacia la dirección del primer registro de la lista. Ahora podemos llegar a todos los elementos de la lista empezando por cualquiera de los elementos de la misma. La siguiente figura muestra una lista circular para el orden NumEstudiante. Nº de registro relativo 1 2 3 4 5 6

Num Estudiante

Num Clase

Semestre

Vínculo NumEstudiante

200 100 300 250 350 150

70 30 20 30 70 20

88S 89F 89F 89S 88S 88S

4 6 5 3 2 1

Inicio de Lista = 2

Lista vinculada circular (a)

Una lista vinculada de dos direcciones posee vínculos en ambos sentidos (ascendentes y descendente). En la figura siguiente se ha creado una lista vinculada en dos direcciones para órdenes de Estudiante tanto ascendentes como descendentes. Nº de registro Num relativo Estudiante 1 200 2 100 3 300 4 250 5 350 6 150

Num Clase 70 30 20 30 70 20

Semestre 88S 89F 89F 89S 88S 88S

Vínculo Vínculo Ascendente Descendente 4 6 6 0 5 4 3 1 0 3 1 2

Inicio de Lista Ascendente= 2 Lista vinculada en dos direcciones (b) Inicio de Lista Descendente = 5

42

INSTITUCIÓN CERVANTES

Área Informática Base de Datos I

INSTITUCIÓN CERVANTES

Los registros ordenados utilizando listas vinculadas no pueden almacenarse en un archivo secuencial porque se necesita de algún tipo de organización de archivo de acceso directo a fin de utilizar los valores de enlace o de vínculo. Se requiere de una organización secuencial indexada o de una organización de archivo directo para el procesamiento de listas vinculadas.

Mantener un orden con índices Un orden de registro lógico también puede ser mantenido utilizando índices o, también conocidos como Listas Invertidas. Un índice es sólo una tabla que hace una referencia cruzada con las direcciones de registro (PRR) de otro valor de campo. La figura siguiente (A) muestra los registros INSCRIPCION almacenados sin ningún orden en particular, y (B) muestra un índice sobre NumEstudiante. En este índice los NumEstudiante se encuentran organizados en secuencia, con cada entrada de la lista apuntando a un registro correspondiente de los datos originales. Como se puede observar, el índice no es nada más que una lista ordenada de NumEstudiante. Para procesar en secuencia INSCRIPCION en NumEstudiante, procesamos el índice de esa manera, obteniendo los datos INSCRIPCION y leyendo los registros indicados por los apuntadores. La figura (C) muestra otro índice para INSCRIPCION, éste manteniendo un orden NumClase. Nº de registro relativo 1 2 3 4 5 6

Num Estudiante

Num Clase

Semestre

Num Estudi ante

Nº de registro relativo

Num Clase

Nº de registro relativo

200 100 300 250 350 150

70 30 20 30 70 20

88S 89F 89F 88S 88S 88S

100 150 200 250 300 350

2 6 1 4 3 5

20 20 30 30 70 70

3 6 2 4 1 5

(A)

(B)

(C)

Al utilizar un índice, los datos a ordenarse (aquí, INSCRIPCION) deben residir en un archivo secuencial o directo indexado, aunque los índices pueden residir en cualquier otro tipo de archivo. En la práctica, todos los productos DBMS conservan tanto los datos como los índices en archivos directos. Si se compara la lista vinculada con el índice, notará la diferencia esencial entre ambos. En una lista vinculada, los apuntadores se encuentran almacenados junto con los datos. Cada registro contiene un campo de vinculación, con un apuntador a la dirección del siguiente registro relacionado. En el caso de un índice, los apuntadores se almacenan en índices separados de los datos. Entonces los registros de datos mismos no contienen apuntadores. Se utilizan ambas técnicas en los productos comerciales.

Institución Cervantes

43

INSTITUCIÓN CERVANTES

Bases de Datos Jerárquicas El modelo jerárquico tiene dos conceptos básicos de estructuración: los tipos de registros y los tipos de interrelaciones padre-hijo. Un tipo de registros es la definición de un grupo de registros que almacenan información del mismo tipo. Un tipo de registros tiene muchas ocurrencias, denominadas registros. Cada tipo de registros contiene una colección de tipos de campos, que son elementos de datos con nombre. Cada tipo de campos está definido como un número entero, real, cadena de caracteres, etc. dependiendo de los tipos primitivos que trate el sistema. Un tipo de interrelaciones padre-hijo (tipo IPH) es una interrelación de uno a muchos entre un tipo de registros padre y un tipo de registros hijo. Una ocurrencia de un tipo de interrelaciones padre-hijo consiste en un registro del tipo de registros padre y muchas (cero o más) ocurrencias del tipo de registros hijos. En adelante, se usará la palabra registro para designar el tipo o la ocurrencia, dependiendo del contexto, lo mismo se aplica a las interrelaciones padre-hijo, solamente cuando haya ambigüedad se usará específicamente el término tipo de registros, o tipo de interrelaciones padre-hijo. Un esquema de base de datos jerárquica contiene varias jerarquías; cada una (o el esquema jerárquico completo) consiste en varios tipos de registros y tipos de IPH colocados de manera que formen un árbol Curso NumCurso Req NumReq

Profesor NumEmp

Título Ofrecimiento NumOfr

Nombre

Fecha

Estudiante NumEmp

Lugar

Nombre

Calificacion

En el modelo jerárquico de la figura muestra un tipo de conjuntos y su ocurrencia en el modelo de redes. En el modelo jerárquico, Curso y Ofrecimiento serán dos tipos de registros, pero la interrelación padre-hijo con curso como padre y ofrecimiento como hijo no tendrá nombre. La siguiente figura muestra un esquema jerárquico con cuatro tipos de registros y tres tipos de IPH.

44

INSTITUCIÓN CERVANTES

Área Informática Base de Datos I

INSTITUCIÓN CERVANTES

Podemos referirnos a los tipos de IPH como el par (tipo de registros padre, tipo de registros hijo). Los tres tipos de IPH de la figura anterior son: Departamento, Empleado
Departamento, Proyecto


Departamento Num_Dep ....

Empleado ID_Empl

....

Proyecto Num_Proy ....

Equipo ID_Equipo ....


Proyecto, Equipo

Aunque los IPH no tienen nombre, tienen asociado un significado; por ejemplo, en la figura anterior, una ocurrencia del tipo IPH (Departamento, Proyecto) relaciona el registro padre de un departamento a los registros de los proyectos que controla. A diferencia de los modelos de redes, el modelo jerárquico sólo puede tener una interrelación entre un par de tipos de registros; ésta es la razón por la que se puede dejar sin nombre.

Propiedades de los esquemas jerárquicos Primero se definen dos términos: los tipos de registros raíz y los tipos de registros hoja en un esquema jerárquico. La raíz de la jerarquía es el registro más alto de la misma; no participa como tipo de registros hijo en ningún tipo de IPH. Un tipo de registros que no participa como IPH como padre en ningún tipo de IPH se denomina hoja de la jerarquía. Un esquema jerárquico de tipos de registros y tipos de IPH debe tener las siguientes propiedades: 1. Todo tipo de registros, excepto la raíz, participa como tipo de registros hijo en un sólo tipo de IPH. 2. Un tipo de registros puede participar como registro padre en cualquier número (cero o más) de tipos de IPH. Institución Cervantes

45

INSTITUCIÓN CERVANTES

3. Si un tipo de registros participa como padre en más de un tipo de IPH, sus tipos de registros hijos están ordenados. El orden se muestra, por convenio, de izquierda a derecha en un diagrama de esquema jerárquico. Estas propiedades de un esquema jerárquico significan que cada tipo de registros excepto la raíz tienen exactamente un tipo de registros padre. Sin embargo, un tipo de registros puede tener varios tipos de registros hijos, que se ordenan de izquierda a derecha. 13 SOFTWARE

21

Adam

10

Barnes

78

Grant

. . . . . 15 Compilador

18

Ventanas

En el primer ejemplo empleado es el primer hijo de departamento y proyecto es el segundo hijo. Estas propiedades limitan el tipo de interrelaciones que pueden estar representadas en un esquema jerárquico. En particular, las interrelaciones de muchos a muchos entre los tipos de registros no se pueden representar directamente, porque las interrelaciones padre-hijo son interrelaciones de uno a muchos y un tipo de registros no puede participar como hijo en dos o más interrelaciones distintas padre-hijo. Estas limitaciones causan problemas cuando se intenta definir el esquema jerárquico de una base de datos que contiene dichas relaciones no jerárquicas.

El Modelo de Redes El modelo de datos de red representa de inmediato relaciones uno a muchos y, por lo tanto, puede ser utilizado para representar todo tipo de objetos excepto objetos compuestos muchos a muchos, tales objetos deben ser transformados a relaciones uno a muchos. El modelo de datos de red de mayor importancia es el DBTG CODASYL (Conference on Data System languajes, Data Basa Task Group). Hay dos conceptos básicos de estructuras en el modelo de redes: tipos de registros y tipos de conjuntos. Cada tipo de registros describe la estructura de un grupo de registros que almacenan el mismo tipo de registros. Un tipo de conjuntos es una interrelación de uno a muchos entre dos tipos de registros; cada registro representa alguna información del mundo real de un grupo de elementos, denominados elementos de datos o atributos de ese registro. Para un tipo de conjuntos dado, una ocurrencia del conjunto es una colección de registros que contiene un registro del tipo de registros propietario, y muchos registros del tipo de registro miembro. La siguiente figura muestra dos tipos de registros, estudiante y curso, con el tipo de conjuntos Se-Matricula entre ellos, con Estudiante como el tipo de registros propietario y Curso como el tipo de registros miembro.

46

INSTITUCIÓN CERVANTES

Área Informática Base de Datos I

INSTITUCIÓN CERVANTES

La figura anterior muestra dos tipos de registros Estudiante y Curso, con el tipo de conjuntos Se_Matricula entre ellos, con Estudiante como el tipo de registros propietario y Curso como el tipo de registros miembro. La representación diagramática en la que la flecha va del registro propietario al registro miembro se denomina diagrama Bachman, John Smith

CS347

Ceri

19

Varón

Batini

CS311

CS144

Navathe

(b) Una ocurrencia del tipo de conjuntos Se_Matricula por Charles Bachman, que fue el primero en introducirla. Una base de datos puede tener muchas ocurrencias del tipo de conjuntos , una por estudiante. Para distinguir un elemento de datos con valores múltiples, se encierra entre paréntesis. El tipo de registros conductor incluye un grupo de repetición denominado Coches, que es un tipo compuesto de los elementos de datos Num-Matrícula, Marca, Año y Color. Puede haber varios coches dentro de un caso del registro Conductor, cada uno con valores para los cuatro elementos de datos. La noción de conjunto (o caso de conjunto) en el modelo de redes difiere de la noción matemática de conjunto en dos aspectos importantes: 1. El caso de un conjunto tiene un elemento distinguido (el registro propietario), mientras que en un conjunto matemático no hay distinción entre los miembros de un conjunto. 2. Los registros miembros dentro de una ocurrencia de conjunto están ordenados en el modelo de redes, mientras que el orden es indiferente en un conjunto matemático. Por estas razones a veces se llama al conjunto del modelo de redes conjunto acoplado al propietario o co-conjunto. Calificaciones_Exámenes Nombre_Estud.

Num_Curso Estudiante Nombre

Edad

(Califc.) Sexo

Se_Matricula Curso Num_Curs

Nombre_Instructor

(a) Un tipo de conjuntos (Se_Matricula)

(a) Tipo de registros Calificaciones_Exámenes, con el elemento de datos vector Conductor NSS

Num_Lic_Conduc.

Nº Matric (b) Tipos de registros Conductor, con grupo de repetición Coches Institución Cervantes

(Coches) Marca

Año

Colo r 47

INSTITUCIÓN CERVANTES

Los tres niveles de la arquitectura de una base de datos La arquitectura ANSI/SPARC se divide en tres niveles, denominados niveles interno, conceptual y externo. Nivel Externo (Vistas individuales de los usuarios)

Nivel Conceptual (vista comunitaria de los usuarios)

Nivel Interno (vista del almacenamiento)

El nivel externo Este nivel es el del usuario individual. Los usuarios pueden ser programadores de aplicaciones o usuarios de terminales en línea, es decir, usuarios finales con cantidad de variables de conocimientos de informática. El DBA (Administrador de la Base de Datos) es un caso especialmente importante (pero, a diferencia de los usuarios ordinarios, el DBA deberá interesarse también en los niveles conceptual e interno). Más adelante hablaremos de cuáles son las características y funciones del DBA.
En el caso del programador de aplicaciones, dicho lenguaje será o bien uno de los

lenguajes de programación convencionales, o bien un lenguaje propio específico para el sistema en cuestión.
Para el usuario final será o bien un lenguaje de consulta, o algún lenguaje de aplicación especial, quizá manejado mediante formularios o menús, adaptado a los requerimientos de ese usuario y apoyado por algún programa de aplicación en línea. En lo que toca a este análisis, el aspecto importante de todos esos lenguajes es que deben incluir un sublenguaje de datos, es decir, un subconjunto del lenguaje total que se ocupe de manera específica de los objetos y operaciones de la base de datos (abreviado DSL, data sublanguaje), está embebido (o inmerso) dentro del lenguaje anfitrión correspondiente. Este último se encarga de varios aspectos no relacionados con la base de datos, como por ejemplo variables locales (temporales), operaciones de cálculo, lógica condicional, etc. Un sistema dado puede permitir el empleo de varios lenguajes anfitriones y varios sublenguajes de datos.

48

INSTITUCIÓN CERVANTES

INSTITUCIÓN CERVANTES

Área Informática Base de Datos I

Nota: Un sublenguaje de datos en particular cuyo uso es posible en casi todos los sistemas relacionales actuales es el lenguaje SQL. En casi todos estos sistemas SQL puede utilizarse ya sea de manera interactiva como lenguaje de consulta interactiva o embebido en otros lenguajes (Visual Basic, por ejemplo). Toda vista externa se define mediante un esquema externo, que consiste básicamente en definiciones de cada uno de los diversos tipos de registros externos en esa vista externa.

El nivel conceptual La vista conceptual es una representación de toda la información contenida en la base de datos, también (como el caso de la vista externa) en forma un tanto abstracta si se compara con el almacenamiento físico de los datos. Además puede ser muy diferente de la forma como percibe los datos cualquier usuario individual. A grandes rasgos, la vista conceptual debe ser un panorama de los datos “tal como son”, y no como por fuerza los perciben los usuarios debido a las limitaciones del lenguaje o el equipo específico utilizado, por ejemplo. La vista conceptual se define mediante un esquema conceptual (tema visto en la unidad), el cual incluye definiciones de cada uno de los tipos de registro conceptual. El esquema conceptual se escribe utilizando otro lenguaje de definición de datos, el DDL conceptual. Si ha de lograrse la independencia de los datos, esas definiciones en DDL conceptual no deberán implicar consideraciones de estructura de almacenamiento o técnica de acceso. Deben ser sólo definiciones de contenido de información. Por tanto, en el esquema conceptual no debe aludirse a representaciones de campos almacenados, secuencia de registros almacenados, indexación, direccionamiento por dispersión, apuntadores o cualquier otro detalle de almacenamiento y acceso. Si el esquema conceptual se hace en verdad independiente de los datos de esta manera, entonces los esquemas externos, definidos en términos de esquema conceptual, serán por fuerza también independiente de los datos. Así pues, la vista conceptual es una vista del contenido total de la base de datos, y el esquema conceptual es una definición de esa vista. No obstante, sería engañoso sugerir que el esquema conceptual es sólo un conjunto de definiciones similar a las sencillas definiciones de registros encontradas hoy día (por ejemplo, en un programa en Cobol).

El nivel interno El tercer nivel de la arquitectura es el nivel interno. La vista interna es una representación de bajo nivel de toda la base de datos; se compone de varias ocurrencias de varios tipos de registro interno. La vista interna, por tanto, está a un paso del nivel físico, ya que no maneja registros físicos (llamados también páginas o bloques), ni otras consideraciones específicas de los dispositivos como son los tamaños de cilindros o de pistas. En esencia, la vista interna supone un espacio lineal infinito de direccionamiento. Los detalles de correspondencia entre ese espacio de direccionamiento y el espacio físico dependen en alto grado del equipo utilizado y se omiten en forma deliberada de la arquitectura general. Institución Cervantes

49

INSTITUCIÓN CERVANTES

La vista interna se define mediante el esquema interno, el cual no solo define los diversos tipos de registros almacenados, sino también especifica qué índices hay, cómo se representan los registros almacenados, etc. El esquema interno se escribe con otro lenguaje más de definición de datos, el DDL interno.

Nivel Interno: Acceso a la Base de Datos Antes de utilizar las estructuras de almacenamiento mismas, examinaremos de manera breve los factores implicados en el proceso general de acceso a bases de datos. Localizar un elemento de información específico en la base de datos y presentarlo al usuario en varios niveles de programas para acceso a datos. Por supuesto, los detalles de estos niveles varían en forma apreciable en los distintos sistemas, y lo mismo sucede con la terminología, pero los principios son bastante generales y pueden explicarse a grandes rasgos de la siguiente manera. 1. En primer término, el DBMS decide qué registro almacenado se necesita, y pide al manejador de archivos que extraiga ese registro. 2. A su vez, el manejador de archivos (Disk Manager) decide qué página contiene el registro deseado, y pide al manejador de disco que lea esa página. La página es la unidad de E/S, es decir, la cantidad de datos transferidos entre el disco y la memoria principal en un solo acceso a disco. Los tamaños usuales de las páginas son de 1K, 2K o 4K bytes. 3. Por último, el manejador de disco (File Manager) determina la localización física de la página deseada en el disco, y realiza la operación de E/S necesaria. DBMS Solicita Registro almacenado

Devuelve Registro almacenado Disk Manager

Solicita Página almacenada

Devuelve página almacenada File Manager Datos Leídos del disco

Operación de E/S en disco Base de datos Almacenada

50

INSTITUCIÓN CERVANTES

Área Informática Base de Datos I

INSTITUCIÓN CERVANTES

Manejador de disco (Disk Manager) El manejador de disco es un componente del sistema operativo. Es el encargado de todas las operaciones físicas de E/S. Como tal, es evidente que necesita conocer las direcciones físicas en el disco. Todo disco está dividido en sectores y pistas. La dirección física de cada archivo, está localizada en la FAT (tabla de asignación de archivos) de cada disco. El manejador de disco, utiliza la FAT para poder localizar físicamente el archivo solicitado. Es también el encargado de colocarle a cada página del disco un número único, que no se vuelve a repetir en ese disco. Es como si armara el índice del libro que queremos leer. En cada página tiene una información determinada y a su vez a esa página le coloca un número. Luego arma el índice (FAT) y en el almacena los datos necesarios para localizar la información sin tener que leer todo el disco. O sea, voy al índice, busco el tema en cuestión, veo en que página está, y abro el libro. Por otro lado, el usuario del manejador de disco o sea, el manejador de archivos, no necesita conocer esa información. Para el manejador de archivos, el disco es tan sólo una colección lógica de conjuntos de páginas, cada uno de los cuales se compone de un grupo de páginas de tamaño fijo.

Manejador de archivos (File Manager) El manejador de archivos utiliza los recursos recién descriptos del manejador de disco de manera tal que su usuario (el DBMS) puede percibir el disco como un conjunto de archivos almacenados. Cada conjunto de páginas contendrá uno o más archivos almacenados, esto es, que en una misma página pueden haber diferentes archivos almacenados, tal como si fuera un libro; en una misma página de ese libro pueden haber varios temas. El DBMS sí necesita saber que existen conjuntos de páginas, aunque no se encarga de manejarlos en detalles. En particular, el DBMS necesita saber cuándo dos archivos almacenados comparten el mismo conjunto de páginas o cuándo dos registros almacenados comparten la misma página. Cada archivo almacenado se identifica mediante un nombre de archivo o identificador de archivo, único por lo menos dentro del conjunto de páginas que lo contiene, y cada registro almacenado, a su vez, se identifica mediante un número de registro único al menos dentro del archivo almacenado que lo contiene. Traten de pensar en el disco como si fuera un libro: está lleno de páginas en las cuales se guarda información. Cada página es única dentro del libro, tiene un índice para acceder más rápido, en una misma página puede haber más de un tema, cada tema es un archivo. Para más información, remitirse a la página 60 del libro de C.J.Date)

Agrupamiento o Clustering La idea básica del agrupamiento es procurar almacenar juntos físicamente los registros que tienen una relación lógica entre sí, o sea que pertenecen al mismo archivo. Las páginas del disco tienen una cierta capacidad de almacenamiento, o sea que pueden Institución Cervantes

51

INSTITUCIÓN CERVANTES

almacenar hasta cierta cantidad de información por página. Cuando la página se llena y el archivo sigue creciendo, o sea que el archivo no entra en una sola página, la información se debe seguir almacenando. Lo que el Sistema Operativo hace es buscar la página más cercana y continúa con la actualización del archivo. Puede que esa nueva página ya contenga información de otro archivo. Esta despaginación obliga al S.O. a almacenar dos direcciones de página para el mismo archivo, que pueden o no ser continuas. La FAT, tiene designada (como ustedes deben conocer) un cierto espacio de almacenamiento. Si los archivos están muy fragmentados, el espacio utilizado en la FAT, va creciendo. Además, para poder leer un archivo, el File Manager necesita realizar operaciones de E/S por cada proceso. Al tener la información fragmentada, las operaciones de E/S se incrementan, provocando un aumento en los tiempos de búsqueda, desgaste mecánico y físico de los componentes, etc. Por lo tanto el agrupamiento o defragmentación (tan conocidos en entornos Windows) lo que hacen es tratar de agrupar la información respecto al mismo archivo, en la cantidad menor de páginas posibles. El agrupamiento físico de los datos es un factor de importancia extrema para el desempeño y el rendimiento de las bases de datos. Desde luego, un archivo (o conjunto de archivos) determinado puede agruparse físicamente en una y sólo una forma a la vez. El DBMS puede hacer posible el agrupamiento, tanto dentro de un archivo como entre varios archivos, si almacena los registros que tienen una relación lógica entre sí en la misma página cuando sea posible y en las páginas adyacentes cuando no lo sea. Cuando el DBMS crea un nuevo registro almacenado, el manejador de archivos debe permitirle especificar el almacenamiento del registro “cerca” de algún registro ya existente. El manejador de archivos, a su vez, hará lo posible por lograr que dos páginas adyacentes lógicamente estén contiguas físicamente en el disco. Por supuesto el DBMS sólo puede saber cuál agrupamiento se requiere si el administrador de la base de datos es capaz de indicárselo. Un buen DBMS deberá permitir al DBA especificar diferentes clases de agrupamiento para distintos archivos. También deberá permitir la modificación del agrupamiento de un archivo determinado en caso de cambiar los requerimientos de desempeño. Desde luego, si ha de lograrse la independencia de los datos, ninguno de estos cambios en el agrupamiento físico deberá requerir cambios correspondientes en los programas de aplicación.

Indexación El objetivo principal de los índices es la agilización en la búsqueda y ordenación de datos. Sin embargo, existe una desventaja, hacen más lenta la actualización de archivos. Por ejemplo, cuando se añade un registro almacenado nuevo al archivo indexado, es preciso agregar también una entrada al índice. En términos generales, la pregunta que se debe responder cuando se estudia la posible indexación, según el campo dado, será: ¿Qué es más importante, una eficiente recuperación de datos con base en los valores del campo en cuestión, o el trabajo adicional de actualización requerido para lograr esa eficiencia?. En esencia, los índices se pueden utilizar de dos maneras distintas. En primer término, pueden servir para tener acceso secuencial al archivo indexado, (Tutor-7). Acceder secuencialmente a un archivo indexado quiere decir: llegar a un valor de forma directa y 52

INSTITUCIÓN CERVANTES

INSTITUCIÓN CERVANTES

Área Informática Base de Datos I

a partir de allí recorrer el resto de forma secuencial. Por ejemplo: acceder al apellido Pérez y desde ahí recorrer uno por uno los Pérez hasta encontrar el buscado. En segundo término, los índices pueden servir también para tener acceso directo a los registros individuales del archivo indexado con base en un valor dado del campo indexado. Ingresar directamente el valor del Legajo del Pérez que busco. De hecho, las dos formas básicas recién delineadas de utilizar índices se pueden generalizar un poco: Acceso secuencial: El índice puede ser útil en consultas de intervalos, por ejemplo, “hallar los proveedores cuya ciudad quede dentro de un cierto intervalo alfabético” (digamos, que comience con una letra en el intervalo L-R).
Acceso directo: el índice puede ser útil también en consultas por listas, por ejemplo, “hallar todos los proveedores cuya ciudad está en alguna lista especificada”.


Hay ciertas consultas –casi todas pruebas de existencia- que se pueden responder empleando sólo el índice, sin leer en absoluto el archivo indexado. Como por ejemplo, considérese la consulta “¿Hay proveedores en Atenas?” la respuesta a esa pregunta es afirmativa si y sólo si existe una entrada para Atenas en el índice ciudad.

Un archivo almacenado puede tener muchos índices. Por ejemplo el archivo almacenado de proveedores podría tener un índice ciudad además un índice situación. Estos índices podrían utilizarse para lograr un acceso eficiente a los registros de proveedor con base en cualquiera de los campos ciudad o situación o ambos.

Indexación densa y no densa Como ya hemos mencionado anteriormente, el objetivo fundamental de los índices es acelerar las búsquedas para la obtención de datos. Dicho de otra manera, reducir las operaciones de E/S de disco necesarias para obtener el registro almacenado solicitado. En lo básico, esto se logra por medio de apuntadores, y hasta ahora hemos supuesto que estos apuntadores apuntan a registros. El mismo objetivo podría alcanzarse, si estos apuntadores apuntaran a páginas de registros (es decir, a un número de página).

Institución Cervantes

53

INSTITUCIÓN CERVANTES

Se dice que un índice como el de la figura es no denso porque no contiene una entrada para cada registro almacenado del archivo indexado. En cambio, todos los índices estudiados hasta aquí han sido densos (apuntan a un registro almacenado). Una ventaja de los índices no densos, es el reducido espacio de almacenamiento requerido en comparación con un índice denso.

Arboles B (B-Trees) Una clase de índices muy importante y de uso muy frecuente es el árbol B. Si bien es cierto que no hay una estructura de almacenamiento óptima para todas las aplicaciones, los árboles B ofrecen, al parecer, el mejor desempeño general. Por esta razón la mayor parte de los sistemas relacionales incluyen árboles B como su forma principal de estructura de almacenamiento, y en varios casos es la única. Antes de explicar qué es un árbol B, será preciso presentar otra idea preliminar, el concepto de índice multinivel o de estructura de árbol. La razón para crear un índice, en primer lugar es obviar la necesidad de una revisión física secuencial del archivo indexado. Sin embargo, sigue siendo necesaria una revisión física secuencial del índice (recorrer el índice de forma secuencial). Si el archivo indexado es de gran tamaño, el índice puede llegar a ser muy grande, y por tanto su revisión secuencial, en sí, puede llegar a requerir bastante tiempo. La solución a este problema es la misma de antes: tratar al índice como un archivo almacenado normal, y crear un índice para él (un índice del índice). Esta idea puede llevarse a tantos niveles como se desee (lo acostumbrado en la práctica son tres niveles; un archivo tendría que ser enorme para requerir más de tres niveles de indexación). Ahora podemos hablar de los árboles B. Un árbol B es un tipo especial de índice con estructura de árbol. Los árboles B, como tales, fueron descriptos, por primera vez, en un artículo de Baller y MacCreight en 1972. Desde entonces Baller y muchos otros investigadores han propuesto gran cantidad de variaciones de la noción básica. Como ya se mencionó, los árboles B de un tipo u otro son, hoy día, quizá, la estructura de almacenamiento más común en los sistemas modernos de bases de datos. Aquí describiremos la variación propuesta por Knuth. En la variación Knuth, el índice tiene dos partes, el conjunto secuencia y el conjunto índice. 54

INSTITUCIÓN CERVANTES

Área Informática Base de Datos I

INSTITUCIÓN CERVANTES


El conjunto secuencia consta de un índice de un solo nivel de datos reales; es un

índice que contiene una entrada por cada uno de los registros en el archivo. En circunstancias normales, este índice es denso, pero podría ser no denso, si el archivo indexado está agrupado según el campo indexado. Las entradas del índice están agrupadas en páginas, y las páginas están encadenadas entre sí, de manera que el orden lógico representado por el índice se obtiene siguiendo las entradas en orden físico de la primera página de la cadena, seguidas de las entradas de orden físico de la segunda página de la cadena, y así sucesivamente. De esta manera, el conjunto secuencial permite un acceso secuencial rápido a los datos indexados.
El conjunto índice, a su vez, hace posible un acceso directo rápido al conjunto secuencia (y por tanto también a los datos). Apunta a grupos de entradas dentro del índice del conjunto de secuencia. El conjunto índice es en realidad un índice con estructura de árbol del conjunto secuencia; de hecho, el conjunto índice es, en términos estrictos, el árbol B. La combinación del conjunto índice y el conjunto secuencia se denomina, en ocasiones, árbol “B más” (árbol B +) el nivel superior del conjunto índice se compone de un solo nodo(es decir, una sola página, pero desde luego con varias entradas de índice, como todos los demás nodos). Este nodo superior recibe el nombre de raíz. Un ejemplo de árbol B aparece en la figura de abajo. Observe que la hilera inferior de la figura, el conjunto de secuencia es simplemente un índice. Contiene una entrada por cada uno de los registros del archivo. Un problema de las estructuras de árbol en general es que las inserciones y las eliminaciones pueden desequilibrar el árbol. Un árbol está desequilibrado si los nodos hoja no están todos en el mismo nivel, es decir, si diferentes nodos hojas están a diferentes distancias del nodo raíz. Como una búsqueda en el árbol requiere un acceso a disco por cada nodo visitado, los tiempos de búsqueda pueden hacerse muy poco predecibles en un árbol desequilibrado. La ventaja de los árboles B es que el algoritmo de inserción / eliminación garantiza en todo momento el equilibrio del árbol (por esta razón se asegura, a veces, que la “B” del nombre significa “Balanceado”). 70

140

72

130

1 10

2

5

9

11

70

15 47

51

58

68

135 136 139

141

250

142 180 249

2 Institución Cervantes

55

251 256 270

INSTITUCIÓN CERVANTES

1) Conjunto de Indices 2) Conjunto de Secuencias (Lista invertida apuntando a registros de datos) Examinemos el ejemplo: la entrada superior contiene dos valores 70 y 140. Siguiendo la vinculación más a la izquierda, podemos tener acceso a todos los registros cuyos valores de campo clave son menores o iguales a 70; si seguimos el apuntador hacia el medio, podemos tener acceso a todos los registros cuyos valores de campo clave sean mayores a 70 e iguales o menores a 140. Si seguimos el apuntador más a la derecha, podemos tener acceso a todos los registros cuyos valores de campo clave sean mayores a 140. De forma similar, en el siguiente nivel existen dos valores y tres apuntadores en cada entrada de índice. Cada vez que bajamos otro nivel, reducimos el ámbito de búsqueda para un registro particular. Este método nos arrima al registro buscado por aproximación. En el conjunto de secuencias, tendremos ya definida una entrada por cada registro almacenado.

El Administrador de Bases de Datos (DBA) El administrador de datos es una persona que toma las decisiones estratégicas y políticas con respecto a la información de la empresa, y el administrador de bases de datos (DBA) es quien proporciona el apoyo técnico necesario para poner en práctica esas decisiones. Por tanto, el DBA está encargado del control general del sistema en el nivel técnico.

Funciones del DBA Definir el esquema conceptual: Es tarea del administrador de datos decidir con exactitud cuál es la información que debe mantenerse en la base de datos, es decir, identificar las entidades que interesan a la empresa y a la información que debe registrarse acerca de esas entidades. Este proceso, por lo regular, se denomina diseño lógico – a veces conceptual – de bases de datos.
Definir el esquema interno: El DBA debe decidir también cómo se representará la información en la base de datos almacenada. A este proceso suele llamárselo diseño físico de la base de datos. Una vez echo esto, el DBA deberá crear la definición de estructura de almacenamiento correspondiente (es decir, el esquema interno) valiéndose de DDL interno. Además deberá definir la correspondencia pertinente entre los esquemas interno y conceptual. En la práctica, ya sea el DDL conceptual o bien el DDL interno incluirán seguramente los medios para definir dicha correspondencia, pero las dos funciones (crear el esquema, definir la correspondencia) deberán poder separarse con nitidez. Al igual que el esquema conceptual, el esquema interno y la correspondencia asociada existirán tanto en la versión fuente como en la versión objeto.
Vincularse con los objetos: El DBA debe encargarse de la comunicación con los usuarios, garantizar la disponibilidad de los datos que requieren y escribir – o ayudar a los usuarios a escribir – los esquemas externos necesarios, empleando el


56

INSTITUCIÓN CERVANTES

INSTITUCIÓN CERVANTES

Área Informática Base de Datos I

DDL externo aplicable. Además será preciso definir la correspondencia entre cualquier esquema externo y el esquema conceptual. En la práctica, el DDL externo incluirá con toda probabilidad los medios para especificar dicha correspondencia, pero en este caso también el esquema y la correspondencia deberá poder separarse con claridad. Cada esquema externo y la correspondencia asociada existirán en ambas versiones, fuente y objeto. Otros aspectos de la función de enlace con los usuarios incluyen las consultas sobre diseño de aplicaciones, la impartición de instrucción técnica, la ayuda de localización y resolución de problemas, y otros servicios profesionales relacionados con el sistema.
Definir las verificaciones de seguridad e integridad: Las verificaciones de seguridad y de integridad pueden considerarse parte del esquema conceptual. El DDL conceptual incluirá (o debería incluir) los medios para especificar dichas verificaciones.
Definir procedimientos de respaldo y recuperación: Cuando una empresa se decide a utilizar un sistema de bases de datos, se vuelve dependiente en grado sumo del funcionamiento correcto de ese sistema. En caso de que sufra daño cualquier porción de la base de datos, resulta esencial poder reparar los datos implicados con un mínimo de retraso y afectando lo menos posible al resto del sistema. En teoría, por ejemplo, la disponibilidad de datos no dañados no debería verse afectada. El DBA debe definir y poner en práctica un plan de recuperación adecuado que incluya, por ejemplo, una descarga o “vaciado” periódico de la base de datos en un medio de almacenamiento de respaldo, y procedimientos para cargar otra vez la base de datos a partir del respaldo más reciente cuando sea necesario.
Supervisar el desempeño y responder a cambios en los requerimientos: Es responsabilidad del DBA organizar el sistema de modo que se obtenga el desempeño que sea “mejor para la empresa”, y realizar los ajustes apropiados cuando cambien los requerimientos. Por ejemplo, podría ser necesario reorganizar la base de datos (es decir, descargarla y volverla a cargar) en forma periódica con el fin de garantizar que los niveles de desempeño sigan siendo aceptables ya, que cualquier modificación del nivel de almacenamiento físico (interno) del sistema debe ir acompañado por el cambio respectivo en la definición de correspondencia con el nivel conceptual, pues sólo así podrá permanecer constante el esquema conceptual.

El sistema de administración de bases de datos (DBMS o SMBD) El sistema de administración de base de datos (DBMS) es por supuesto el conjunto de programas que maneja todo acceso a la base de datos. Conceptualmente, lo que sucede es lo siguiente: 1. El usuario solicita acceso, empleando algún sublenguaje de datos determinado (por ej. SQL). 2. El DBMS interpreta esa solicitud y la analiza. 3. El DBMS inspecciona, en orden, el esquema externo de ese usuario, la correspondencia externa/conceptual asociada, el esquema conceptual, la Institución Cervantes

57

INSTITUCIÓN CERVANTES

correspondencia conceptual/interna, la definición de la estructura de almacenamiento. 4. El DBMS ejecuta las operaciones necesarias sobre la base de datos almacenada.

Funciones del DBMS
Definición de datos: El DBMS debe ser capaz de aceptar definiciones de datos
















(esquemas externos, el esquema conceptual, el esquema interno, y todas las correspondencias asociadas) en versión fuente y convertirlas en la versión objeto apropiada. Dicho de otro modo el DBMS debe incluir componentes procesadores de lenguajes para cada uno de los diversos lenguajes de definición de datos (DDL). Manipulación de datos: el DBMS debe ser capaz de atender las solicitudes del usuario para extraer, y quizá poner al día, datos que ya existen en la base de datos, o para agregar en ella datos nuevos. Dicho de otro modo, el DBMS debe incluir un componente procesador de lenguaje de manipulación de datos (DML). En general las solicitudes en DML pueden ser “planeadas” o “no planeadas”:
Una solicitud planeada es aquella cuya necesidad se previó mucho tiempo antes de que tuviera que ejecutarse por primera vez. El DBA habrá afinado con toda probabilidad el diseño físico de la base de datos a fin de garantizar un buen desempeño para estas solicitudes.
Una solicitud no planeada, en cambio, es una consulta ad hoc, es decir, una solicitud cuya necesidad no se previó, sino que surgió de improviso. El diseño de la base de datos puede ser o no ideal para la solicitud específica de que se trate. En general, el logro del mejor desempeño posible con solicitud en no planeadas representa un reto considerable para el DBMS. Seguridad e integridad de datos: El DBMS debe supervisar las solicitudes de los usuarios y rechazar los intentos de violar las medidas de seguridad e integridad definidas para el DBA. Recuperación y concurrencia de datos: El DBMS – o en su defecto algún componente de software relacionado con él, al que por lo regular se lo denomina administrador de transacciones – debe cuidar del cumplimiento de ciertos controles de recuperación y concurrencia. Diccionario de datos: El DBMS debe incluir una función de diccionario de datos. Puede decirse que el diccionario de datos es una base de datos por derecho propio (pero del sistema, no del usuario). El contenido del diccionario puede considerarse como “datos acerca de los datos” (los cuales reciben en ocasiones el nombre de “metadatos”), es decir, definiciones de otros objetos en el sistema. Desempeño: Por último el DBMS deberá ejecutar todas las funciones recién identificadas en la forma más reciente posible.

En resumen, constituye la interfaz entre el usuario y el sistema de base de datos. La interfaz del usuario puede definirse como una frontera del sistema, mas allá de la cual todo resulta invisible para el usuario. Por definición, entonces, la interfaz del usuario está en el nivel externo.

58

INSTITUCIÓN CERVANTES

Área Informática Base de Datos I

INSTITUCIÓN CERVANTES

El administrador de comunicación de datos La solicitud de un usuario final dirigida a la base de datos, se transmite en la práctica en forma de mensajes de comunicación. De manera similar, las respuestas al usuario, (desde del DBMS y la aplicación en línea, de vuelta a la terminal del usuario) también se transmite como mensajes de este tipo. Todas estas transmisiones se efectúan bajo el control de otros sistemas de programas, el administrador de comunicación de datos (administrador DC). El administrador DC no es un componente del DBMS, sino un sistema autónomo. No obstante, como es evidente que el manejador DC y el DBMS deben trabajar juntos y en forma armónica, se los considera como socios equitativos en una empresa corporativa de mayor nivel denominada Sistema de Base de Datos/Comunicación de Datos (sistema DB/DC), en la cual el DBMS se encarga de la base de datos y el administrador DC, de todos los mensajes que llegan a la base de datos y salen de ella.

Procesamiento Distribuido Procesamiento distribuido significa que varias máquinas pueden conectarse entre sí, para formar una red de comunicación, de manera que una sola tarea de procesamiento de datos puede abarcar varias máquinas de la red (a veces se utiliza el término “Procesamiento en Paralelo” con un significado idéntico). La comunicación entre las diversas máquinas corre a cargo de algún tipo de programas de administración de redes, quizá una extensión del administrador DC. La siguiente figura es un ejemplo de lo que se ha llegado a llamar un sistema “Cliente/Servidor” (la sección frontal es el cliente y la posterior es el servidor). Existen muchos argumentos a favor de un sistema Cliente/Servidor. El primero no es en esencia el argumento a favor del procesamiento en paralelo, a saber: cómo se aplican varios procesadores a la tarea general, el procesamiento de la sección posterior (base de datos) y de la sección frontal (aplicación) se realizan en paralelo. El tiempo de respuesta y el rendimiento deberán mejorar en consecuencia.
Por añadidura, la máquina despachadora (sección posterior) podría estar construida a propósito para una función DBMS (“una máquina de base de datos”) y el DBMS podría así tener un mejor desempeño.
De manera similar, la máquina cliente (sección frontal) podría ser una estación de trabajo personal, adaptada a las necesidades del usuario final y, por lo tanto capaz de proporcionar a éste mejores interfases, alta disponibilidad, respuestas más rápidas, y en general facilidad de uso.
Varias máquinas clientes diferentes podrían ser capaces (de hecho, probablemente serán capaces) de acceder a la misma máquina servidora. Así, una sola base de datos podría compartirse entre varios sistemas de sección frontal diferentes (y quizá muy diferentes).


Institución Cervantes

59

INSTITUCIÓN CERVANTES

Además de los argumentos anteriores, puede mencionarse también que el arreglo cliente/servidor concuerda con la forma real de operar de muchas empresas: es frecuente que una sola empresa (un banco, por ejemplo) maneje muchas máquinas, de modos que los datos de una parte de la empresa se almacenan en una sola máquina y los de otra parte se almacenen en otra máquina. También sucede a menudo que los usuarios de una máquina requieren acceso por lo menos ocasional a los datos de almacenamiento de otra. Obsérvese, por tanto, que la máquina de sección frontal podría tener datos propios de sección posterior, y la máquina de sección posterior podría tener también aplicaciones propias de sección frontal. Así, en general, cada máquina funcionará como servidor para algunos usuarios y como cliente para otros; dicho de otro modo, cada máquina incluirá un sistema completo de base de datos (siguiente figura).

60

INSTITUCIÓN CERVANTES

INSTITUCIÓN CERVANTES

Área Informática Base de Datos I

Por último, dejamos sentado que una sola máquina cliente podría ser capaz de acceder a varias máquinas servidoras diferentes (lo opuesto del caso ilustrado en la figura anterior). Esta posibilidad es conveniente porque las empresas, en general, tienden a operar de tal manera, que el conjunto total de sus datos no está almacenado en una sola máquina, sino más bien disperso entre varias máquinas diferentes, y las aplicaciones necesitarán a veces poder acceder a datos de más de una máquina. Existen dos formas básicas de permitir este acceso: 1. Una cierta aplicación de sección frontal podría tener acceso a cualquier cantidad de sistemas por sección posterior, pero sólo a uno a la vez (es decir, cada solicitud individual a la base de datos deberá ir dirigida a sólo una de las secciones posteriores). No es posible, dentro de una misma solicitud, combinar datos de dos o más secciones posteriores diferentes. Además, el usuario de un sistema así deberá saber cual sección posterior contiene cuáles elementos de información. 2. La aplicación de sección frontal podría tener acceso a cualquier cantidad de sistemas de sección posterior en forma simultánea (es decir, una sola solicitud a la base de datos podría ser capaz de combinar datos de varias secciones posteriores). En este caso, la sección frontal percibe a las distintas secciones posteriores como si fueran en realidad un solo sistema (desde un punto de vista lógico), y el usuario no necesita saber cuáles secciones posteriores contienen cuáles elementos de información. El segundo caso es un ejemplo de lo que suele llamarse sistema de bases de datos distribuidas. Llevando a una conclusión lógica, un apoyo completo para las bases de datos distribuidas implica que una sola aplicación deberá ser capaz de trabajar en forma Institución Cervantes

61

INSTITUCIÓN CERVANTES

“transparente” con datos dispersos en varias bases de datos diferentes, administradas por varios DBMS distintos, ejecutadas en varias máquinas diferentes, apoyadas por diversos sistemas operativos y conectadas entre sí mediante varias redes de comunicación distintas. El término “transparente” significa aquí que la aplicación trabajaría, desde un punto de vista lógico, como si un solo DBMS, ejecutado en una sola máquina, administrara todos los datos.

Sistemas de Teleprocesamiento El método clásico de soportar un sistema de base de datos multiusuario es el teleprocesamiento, que utiliza una computadora y una CPU. Todo el procesamiento es efectuado por esta única computadora.

En la figura se muestra un sistema de teleprocesamiento típico. Los usuarios operan terminales no Inteligentes (bobas); microcomputadoras que transmiten a la macrocomputadora mensajes de transacciones y de datos. La porción de control de las comunicaciones del sistema operativo recibe los mensajes y los datos y los envía al programa de aplicación (AP) apropiado. El programa llama al DBMS solicitando servicios, y el DBMS utiliza la porción de administración de datos del sistema operativo y procesa la base de datos. Terminada la transacción, los resultados son devueltos a los usuarios en las terminales, vía la porción de controles de comunicaciones del sistema operativo. La figura muestra n usuarios sometiendo transacciones procesadas por tres distintos programas de aplicación. Dado que existe poca inteligencia en el extremo usuario ya que las terminales son no inteligentes, todos los comandos para formato de la pantalla, deben ser generados por la CPU y transmitidos por las líneas de comunicación. En estos sistemas, por lo general, la interfaz de usuario está orientada a caracteres y es primitiva. Cabe recordar que Teleprocesamiento proviene de: tele = distancia, o sea que teleprocesamiento significa procesamiento a distancia. Un ejemplo típico de este tipo de procesamiento, es el de los cajeros automáticos. En estas terminales la posibilidad de procesamiento es limitada.

62

INSTITUCIÓN CERVANTES

INSTITUCIÓN CERVANTES

Área Informática Base de Datos I

Los sistemas de teleprocesamiento han sido la alternativa más común para sistemas de base de datos multiusuario. Conforme se ha ido reduciendo la afinidad preciorendimiento de las computadoras y con el advenimiento de las microcomptadoras, han empezado a ser utilizadas otras alternativas que requieren varias computadoras.

Sistemas Cliente / Servidor

En la figura aparece un esquema que muestra un sistema Cliente/Servidor. A diferencia del teleprocesamiento que utiliza una sola computadora, los sistemas cliente/servidor involucran varias computadoras conectadas en una red. Algunas computadoras procesan programas de aplicación y se conocen como clientes. Otra computadora procesa la base de datos y es designada como servidor. Los clientes y el servidor están conectados utilizando una red de área local (LAN). En este sistema, cada uno de los usuarios tiene su propia computadora de procesamiento de aplicaciones. Cada usuario procesa los programas que le hacen falta a él.

Institución Cervantes

63

INSTITUCIÓN CERVANTES

En esta figura se resumen los roles del cliente y del servidor. La computadora cliente administra la interfaz de usuario, acepta datos del usuario, procesa la lógica de la aplicación y genera solicitudes de servicios de la base de datos. Los clientes transmiten esas solicitudes al servidor y reciben resultados, a los cuales se les da formato para el usuario. El servidor acepta las solicitudes de los clientes, las procesa, y devuelve una respuesta. El servidor también lleva a cabo la verificación de integridad de la base de datos, mantiene los datos generales de la base de datos, y proporciona control de acceso concurrente. Un sistema cliente/servidor coloca el procesamiento de la aplicación más cerca del usuario. Además permite utilizar entornos gráficos en los clientes dado que estas ya tienen posibilidad de procesamiento propio.

64

INSTITUCIÓN CERVANTES

INSTITUCIÓN CERVANTES

Área Informática Base de Datos I

Autoevaluación 1. Describa cómo funcionan los distintos tipos de estructuras de datos (Lista invertida, vinculada). Cuáles son las diferencias entre unas y otras. ........................................................................................ ........................................................................................ 2. Describa los distintos niveles en la arquitectura de una base de datos. En cuál de las capas interactúa el DBA. En cuál de las capas se encuentra el usuario de aplicaciones. ........................................................................................ ........................................................................................ 3. Qué función cumple el File Manager y Disk Manager. ........................................................................................ ........................................................................................ 4. Cuál es el objetivo del agrupamiento. ........................................................................................ ........................................................................................ 5. Cuáles son las funciones del DBA. ........................................................................................ ........................................................................................ 6. Cuáles son las funciones del DBMS. ........................................................................................ ........................................................................................ 7. Qué rol cumple el Comunicador de datos. ........................................................................................ ........................................................................................ 8. Qué tipos de sistemas de bases de datos distribuidos conoce. Describa cada uno de ellos. ........................................................................................ ........................................................................................ 9. Mencione algunas de las ventajas del modelo Cliente/Servidor. ........................................................................................ ........................................................................................ Institución Cervantes

65

INSTITUCIÓN CERVANTES

66

INSTITUCIÓN CERVANTES

Área Informática Base de Datos I

INSTITUCIÓN CERVANTES




Unidad IV

El Modelo de datos Relacional Objetivos
Reconocer los diferentes componentes del modelo relacional de datos.
Reconocer la importancia del modelo para la construcción de estructuras de datos.
Comprender los principios para selección de claves.
Interpretar el rol que cumple cada componente del modelo dentro del mismo.

Institución Cervantes

67

INSTITUCIÓN CERVANTES

El modelo Relacional El modelo relacional fue propuesto en 1970 por Codd, y la popularidad de este modelo ha ido creciendo lenta pero firmemente, de manera que el término relacional ha llegado a ser común entre los profesionales informáticos. El modelo relacional de datos es un modelo simple, potente y formal para representar la realidad. También ofrece una base firme para enfocar y analizar formalmente muchos problemas relacionados con la gestión de base de datos, como el diseño de la base de datos, la redundancia, la distribución, etc. El formalismo y una base matemática son las piedras angulares en el desarrollo de la teoría de las bases de datos. La sencillez del modelo ha facilitado la construcción de lenguajes de consultas e interfases para usuarios finales de fácil utilización, y ha resultado en una productividad más alta de los programadores de base de datos. La gestión de bases de datos relacionales será una tecnología muy útil durante varios años. Vamos a dividir el estudio del modelo relacional en tres partes, las cuales se ocupan de la estructura, la integridad y la manipulación de los datos, respectivamente. Cada una de las partes tiene sus términos especiales. Los términos en cuestión son relación, tupla, cardinalidad, atributo, grado, dominio y claves, los cuales veremos en la primera etapa cuando hablemos de la estructura relacional. En esta materia, tocaremos solamente lo referido a la estructura y a la integridad, la manipulación, es tema de otra asignatura.

Estructura de datos Relacional Los DBMS relacionales, son los sistemas de bases de datos más populares actualmente en minis y microcomputadoras. Una lista de productos comerciales de DBMS relacionales incluiría INGRES, ORACLE, SYBASE, INFORMIX, SQL Server, PROGRESS, etc. Estos DBMS relacionales, están disponibles en una amplia gama de equipos y, alguno de ellos, bajo varios sistemas operativos o plataformas. En este apartado, trataremos todo lo referente a la estructura relacional propiamente dicha. Partiremos con un gráfico que nos representa las partes componentes del modelo. Legajo 125 126 150 

Relación




Nombre Provincia Salazar Cordoba Jaime Santa Fe Almada Cordoba   Atributos Grado

Ciudad Cordoba Rosario Cordoba 



Tupla



Una relación corresponde a lo que hasta ahora hemos llamado en general tabla.
Una tupla, corresponde a una fila de esa tabla.
Un atributo, corresponde a una columna de esta misma tabla.
Las claves son identificadores, es decir una columna o combinación de columnas

que permitan hacer un determinado ordenamiento o acceso a los datos.

68

INSTITUCIÓN CERVANTES

C A R D I N A L I D A D

INSTITUCIÓN CERVANTES

Área Informática Base de Datos I


Dominio es una colección de valores, de los cuales uno o más atributos (columnas)

obtienen sus valores.

Término relacional formal Relación Tupla Cardinalidad Atributo Grado Dominio

Equivalentes informales Tabla o archivo Fila o registro Número de filas Columna o campo Número de columnas Valores permitidos

El elemento básico del modelo es la relación, y un esquema de base de datos relacional es una colección de definiciones de relaciones. El esquema de cada relación es una agregación de atributos (recordemos el concepto de agregación visto en la unidad de abstracción); el conjunto de todos los valores que puede adoptar un atributo en particular se denomina dominio de ese atributo. Este es el punto de partida para el estudio de nuestro modelo ya que es la menor unidad de información, la cual suponemos es el valor de un dato individual (como número de legajo individual o el peso de una pieza, etc.). Estos valores escalares, son la menor unidad debido a que estos son valores atómicos; no poseen estructura interna (es decir no se pueden descomponer en unidades más pequeñas) desde el punto de vista del modelo. Podemos decir entonces, que “Dominio es un conjunto de valores escalares, todos del mismo tipo”. Por ejemplo: el dominio de números de legajo es el conjunto de todos los números de legajo posibles, el dominio de cantidades de envío es el conjunto de todos los números enteros mayores que cero y menores que 10000, el dominio del campo tipo de documento serán todos los valores permitidos (DNI, LE, CI, PAS, LC). Todo atributo debe estar definido sobre un dominio. A partir de este concepto de dominio, podemos definir el término de Relación: “Una relación sobre un conjunto de dominios D1, D2,...., Dn (no necesariamente todos distintos), se compone de dos partes, una cabecera y un cuerpo”.
La cabecera está formada por un conjunto fijo de atributos.
El cuerpo está formado por un conjunto de tuplas o filas, el cual varía con el tiempo.

A partir de esto, podemos interpretar que la cabecera de una relación es estática en el tiempo, mientras que el cuerpo varía según se modifique el contenido de la relación. Un caso de relación (llamado también extensión de la relación) es una tabla con filas y columnas. Las columnas de las relaciones corresponden a los atributos o campos; las filas, o tuplas, son colecciones de valores tomados de cada atributo, y desempeñan la misma función que los casos individuales de entidades en el modelo ER. El grado de una relación es el número de columnas que cada relación tenga; la cardinalidad de una relación es el número de tuplas o filas que en un determinado instante tiene la relación. Institución Cervantes

69

INSTITUCIÓN CERVANTES

La cardinalidad, a partir de la definición de relación, varía con el tiempo, pero el grado no.

Propiedades de las relaciones 1. No existen tuplas repetidas. Esta propiedad es consecuencia del hecho de que el cuerpo de la relación es un conjunto matemático (es decir, un conjunto de tuplas), y en matemáticas los conjuntos por definición no incluyen elementos repetidos. Consideremos a la relación como un conjunto de individuos y llamemos individuo a cualquier elemento (personas, máquinas, autos, etc.) perteneciente a un conjunto de estos. Cada individuo es único dentro del mundo real, por lo tanto, si consideramos que lo que tenemos en una relación son tuplas (filas o registros), y cada registro hace referencia a un único individuo, por lo tanto cada individuo no puede estar repetido en una relación. Expresado de otra manera, en una relación no pueden haber individuos repetidos. 2. Las tuplas no están ordenadas (de arriba hacia abajo). Esta propiedad también se desprende de que el cuerpo de una relación es un conjunto matemático. Los conjuntos matemáticos no son ordenados. Legajo 125 100 255 180 240

Nombre Juan Pedro Jose Luis Carlos

Telefono 4551825 4612533 4331528 4516799 4221525

En la tabla, por ejemplo, las tuplas (filas) de la relación podrían haberse presentado en la secuencia inversa, sería de todos modos la misma relación. Por tanto, no puede hablarse de la quinta tupla, la tupla 97 o la primera tupla de una relación, y tampoco existe la siguiente tupla; no existe el direccionamiento por posición. Si lo viéramos como un conjunto matemático:

A

B

C

C

A B

Observen ambos conjuntos: Son iguales a pesar de que lo único que los diferencia es la ubicación dentro del círculo. 3. Los atributos no están ordenados (de izquierda a derecha). 70

INSTITUCIÓN CERVANTES

Área Informática Base de Datos I

INSTITUCIÓN CERVANTES

Esta propiedad se desprende del hecho de que la cabecera de una relación se define también como un conjunto (es decir, un conjunto de atributos). Por la misma razón que la propiedad anterior, si consideramos a la cabecera como un conjunto, el orden no tiene importancia ya que siempre sería el mismo conjunto pero en distinto orden. 4. Todos los valores de los atributos son atómicos. Una forma más precisa de expresar esta propiedad es: “todos los valores de los atributos simples son atómicos”. Esta propiedad, es una consecuencia del hecho de que todos los dominios son a su vez simples; es decir, sólo contienen valores atómicos.

Tipos de relaciones Existen diferentes tipos de relaciones en un sistema relacional: 1. Relaciones base: (relaciones reales) Son aquellas relaciones cuya importancia es tal que el diseñador de la base de datos ha decidido darle un nombre y hacerlas parte directa de la base de datos en sí, a diferencia con otras relaciones cuya naturaleza es más efímera, como por ejemplo el resultado de una consulta. Por ejemplo la relación ALUMNO en la base de datos de la universidad sería un caso de relación base. 2. Vistas: (relaciones virtuales) una vista es una relación derivada, con nombre, representada dentro del sistema exclusivamente mediante su definición en términos de otras relaciones con nombre; no posee datos almacenados propios. Un ejemplo sería la presentación en pantalla de datos obtenidos de varias relaciones. En este caso tenemos dos relaciones base: Clientes y Localidades. Al usuario solo le interesa el nombre y la Localidad. Lo que se hace es una vista obtenida de los datos almacenados físicamente en CLIENTES Y LOCALIDAD. La vista no se almacena físicamente, solo se ejecuta una secuencia de instrucciones y se crea en memoria RAM. NCli 11 44 55

Relación Clientes Nombre Luis Ana José

Vista

Institución Cervantes

Relación Localidades Localidad CP Málaga 5000 Gijón 4000 Valencia 3500 Salamanca 4500

CP 5000 4000 3500

Nombre Luis Ana

Localidad Málaga Valencia

71

INSTITUCIÓN CERVANTES

Integridad en el modelo relacional Restricciones de integridad en los esquemas relacionales Comencemos con un poco de filosofía. Cualquier base de datos se compone de alguna configuración de valores de los datos, y desde luego suponemos que esa configuración de valores refleja la realidad (suponemos que el modelo es una representación de algún fragmento del mundo real). Ahora, algunos valores no tienen sentido en ese mundo real, no representan a ningún valor posible dentro de la realidad. Por ejemplo, es imposible que si hablamos de peso de una pieza, el valor sea negativo. Debido a estos motivos, es necesario establecer ciertas reglas de integridad, cuyo propósito es informar al DBMS de ciertas restricciones en el mundo real (como el caso de que los pesos no pueden ser negativos). La mayor parte de las bases de datos estarán sujetas a gran número de tales reglas de integridad. Por ejemplo: supongamos la relación PIEZAS(Nro, Nombre, Tipo, Color, Peso)
Los número de piezas deben tener el formato numérico 9999 (donde 9999

representa cuatro dígitos numéricos).
Los tipos de piezas deben provenir de cierta lista tipos.
Los colores de las piezas deben provenir de cierta lista colores.
Los pesos de las piezas deben ser mayores que cero.

Como pueden observar, la mayor parte de las reglas de integridad son específicas, en cuanto a que se aplican a una base de datos específica. O sea, las que acabamos de enumerar hacen referencia a la base de datos donde se encuentra PIEZAS. Sin embargo, el modelo relacional incluye dos reglas generales de integridad: generales en el sentido de que se aplican no sólo a una base de datos, sino más bien a todas las bases de datos. Estas dos reglas se refieren a las claves primarias y a las claves ajenas.

Claves Primarias En el modelo relacional, el concepto de clave está definido de una manera muy similar al concepto de identificador en el modelo ER; una clave de una relación es un atributo o conjunto de atributos de la relación que identifica de manera única cada tupla de cada extensión de esa relación. Así, la única diferencia entre nuestro uso de identificadores y claves en el modelo relacional sólo se acepta la identificación interna. En general, una relación puede tener más de una clave o identificador único, y cada clave se denomina clave candidata. Podemos decir, que una relación puede tener varias claves candidatas (a ser primarias). Nosotros escogeremos una de esas claves candidatas como clave primaria o principal y a las demás las llamaremos entonces claves alternativas o secundarias. Podemos definir entonces el término clave candidata: 72

INSTITUCIÓN CERVANTES

INSTITUCIÓN CERVANTES

Área Informática Base de Datos I

“El atributo K (posiblemente compuesto o no Tutor-10) de la relación R es una clave candidata de R si y solo si satisface: 1. Unicidad: en cualquier momento dado, no existen dos tuplas en R con el mismo valor de K. 2. Minimalidad: si K es compuesto, no será posible eliminar ningún componente de K sin destruir la propiedad de unicidad. Toda relación tiene por lo menos una clave candidata, ya que como hemos mencionado, las relaciones no contienen tuplas repetidas. En el caso de las PIEZAS, podemos tener piezas con el mismo nombre, tipo, color y peso, a lo mejor porque son provista por distintos proveedores, pero nunca tendrán el mismo número. Por ejemplo: en una agencia de autos, los modelos son siempre los mismos y los autos que haya en stock tendrán los mismos modelos, pero el numero de chasis de cada uno, distinguirá uno del otro. Ahora bien, del conjunto de claves candidatas se elige una y solo una como clave primaria de esa relación, las demás, como dijimos, si existen serán claves alternativas. Así, una clave candidata que no es clave primaria se convierte en clave alternativa. A partir de lo que hemos visto, podemos expresar: 1. Toda relación tiene por lo menos una clave candidata y por fuerza, toda relación una clave primaria SIN EXCEPCION. 2. El razonamiento para elegir la clave primaria en los casos donde hay varias claves candidatas, queda fuera del alcance del modelo relacional en sí. 3. La clave primaria es la que tiene verdadera importancia; las claves candidatas y alternativas son sólo conceptos surgidos en el proceso de definición de clave primaria. Entonces, ¿por qué son tan importantes las claves primarias? La respuesta a esta pregunta es que es un requisito para el manejo de claves ajenas, concepto que veremos un poco más adelante. Además, como hemos dicho anteriormente, las tuplas son únicas dentro de la relación y cada tupla hace referencia a un individuo, y este individuo pertenece al mundo real, por lo tanto cada individuo (de una misma especie) debe tener como mínimo un valor de atributo que lo diferencia del resto y que lo haga único. A este concepto de clave primaria única se conoce como principio de unicidad de la clave primaria. Ahora bien, ya vimos el concepto de clave primaria y ahora veremos las restricciones de integridad que pueden ser especificadas en un esquema relacional. Se espera que tales restricciones, una vez especificadas, se cumplan para cada caso de base de datos de ese esquema. Sin embargo, en los productos comerciales de DBMS actuales no siempre pueden ser especificadas todas esas restricciones. Además, aún especificadas, no obliga automáticamente el cumplimiento de todas ellas. Se consideran tres tipos de restricciones como parte del modelo relacional: restricciones de clave, de integridad de entidades y de integridad referencial. Las restricciones de clave especifican las claves candidatas de cada esquema de relación; los valores de las claves candidatas deben ser únicos para cada tupla en cualquier caso de ese esquema de relación. Institución Cervantes

73

INSTITUCIÓN CERVANTES

Las restricciones de integridad de entidades establecen que “ningún valor de la clave primaria puede ser nulo”. Esto es porque el valor de la clave primaria se usa para identificar las tuplas individuales de una relación; permitir valores nulos para la clave primaria implica que no se puedan identificar algunas tuplas. Por ejemplo: si en nuestra relación la clave primaria fuera LEGAJO no podría existir ningún alumno con valor de legajo nulo ya que si ese alumno no tuviera asignado un legajo no sería alumno del colegio. Nulo, debemos interpretar como que por alguna razón el valor de la información falta. De este concepto surge que “en una base de datos relacional, nunca registraremos información acerca de algo que no podamos identificar”. Por ejemplo, si dos o más tuplas tuvieran un valor nulo como clave primaria, no podríamos distinguirlas.
Debemos tener en cuenta además, que en el caso de que la clave primaria fuera

compuesta (estuviera formada por más de un atributo), cada valor individual de la clave primaria debe ser no nulo en su totalidad.
La regla de integridad de entidades se aplica solo para claves primarias, las claves alternativas podrían contener valores nulos.

Claves Ajenas Supongamos las siguientes relaciones: ALUMNOS(Matricula, Nombre, Direcion, Codigo Postal) CIUDAD(Codigo Postal, Nombre Ciudad, Cantidad Habitantes) Los atributos Codigo Postal, tienen que estar, definidos para el mismo dominio en ambas relaciones. En donde Matricula es la clave primaria de ALUMNOS y Codigo Postal lo es de CIUDAD. Ambos atributos, no permiten valores nulos debido a la regla de integridad de entidades. Además, si observamos el ejemplo, veremos que existe una relación entre ALUMNOS y CIUDAD del tipo agregación binaria donde un alumno vive en una ciudad. Este tipo de relación es la que me permite mantener cohesión en los datos de la base de datos y me permite evitar redundancias. En el ejemplo se ha aplicado la tercera forma normal, concepto que veremos en la próxima unidad. Para que entiendan en definitiva el concepto de clave ajena o foránea, necesitamos de un ejemplo como este. Al atributo Codigo Postal de la relación ALUMNOS, se lo conoce como clave ajena. Definimos entonces como clave ajena o foránea “como un atributo (quizá compuesto) de una relación, cuyos valores deben coincidir o concordar con los valores de la clave primaria de alguno otra relación”. Podemos decir, que lo inverso no se requiere: es decir, la clave primaria correspondiente a una clave ajena dada podría contener un valor que no aparezca de momento como clave ajena. En nuestro ejemplo, podría existir alguna ciudad donde no viviera ningún alumno de la escuela.

74

INSTITUCIÓN CERVANTES

INSTITUCIÓN CERVANTES

Área Informática Base de Datos I

Un valor de clave ajena, representa una referencia a la tupla donde se encuentra el valor correspondiente de la clave primaria. Por lo tanto, el problema de garantizar que la base de datos no incluya valores no válidos de clave ajena se conoce como el problema de la integridad referencial. Las restricciones de clave y de entidad se especifican en relaciones individuales. La restricción de integridad referencial, en cambio, se especifica entre dos relaciones, y se usa para mantener la congruencia entre las tuplas de dos relaciones. Informalmente la restricción de integridad referencial establece que una tupla de una relación, que haga referencia a otra relación, debe referirse a una tupla existente en esa relación. En una base de datos de muchas relaciones, habrá normalmente muchas restricciones de integridad referencial que correspondan a las interrelaciones de las entidades representadas por las relaciones.

Reglas para claves ajenas Es importante darse cuenta de que la regla de integridad referencial tal como se presentó, se formula solo en términos de estados de la base de datos. Cualquier estado de la base de datos que no satisfaga la regla será incorrecto por definición; pero ¿cómo pueden evitarse tales estado incorrectos? La regla en sí no lo dice con exactitud. Una posibilidad es que el sistema rechazara cualquier operación que en caso de ejecutarse, produciría un estado ilegal. Pero en muchos casos una alternativa preferible sería que el sistema aceptara la operación pero realizara ciertas operaciones de compensación para garantizar un estado legal como resultado final. Por ejemplo, si el usuario solicita eliminar una ciudad, debería ser posible hacer que el sistema elimine también los alumnos sin necesidad de acciones adicionales por parte del usuario. Esto se debe a que si no elimino los alumnos, estos quedarían sin correspondencia en la relación ciudades. En consecuencia, para cualquier base de datos, el usuario (diseñador de la base de datos), deberá poder especificar cuáles operaciones han de rechazarse y cuáles han de aceptarse. La idea es la siguiente: para cada clave ajena es necesario responder: 1. Puede aceptar nulos una clave ajena? Es necesario conocer la ciudad en la que alumno vive? La respuesta en este caso es SI, pero podría suceder que la respuesta fuera diferente. La respuesta a la pregunta no depende del capricho del diseñador de la base de datos, sino más bien de las políticas vigentes en la porción del mundo real supuestamente representada por la base de datos. 2. Qué deberá suceder si hay un intento de eliminar el objetivo de una referencia de clave ajena? Por ejemplo, un intento de eliminar una ciudad del cual provienen varios alumnos. Para dar una respuesta, veamos que operaciones son permitidas:
RESTRINGIDA. La operación de eliminación está restringida al caso en el cual no existen alumnos de esa ciudad, en caso contrario se rechaza.
SE PROPAGA. La operación de eliminación se propaga en cascada eliminando también todos los alumnos. Institución Cervantes

75

INSTITUCIÓN CERVANTES




ANULA. Se asignan valores nulos a la clave ajena en todos los alumnos correspondientes a esa ciudad y enseguida se elimina la ciudad.

3. Qué sucederá si hay un intento de modificar la clave primaria del objetivo de referencia de clave ajena? por ejemplo se intenta modificar el código postal de una ciudad. Consideremos como en el caso anterior:
RESTRINGIDA. La operación de modificación está restringida al caso en el cual no existen alumnos de esa ciudad, en caso contrario se rechaza.
SE PROPAGA. La operación de modificación se propaga en cascada modificando también todos los alumnos.
ANULA. Se asignan valores nulos a la clave ajena en todos los alumnos correspondientes a esa ciudad y enseguida se modifica la ciudad.

Diseño lógico en el modelo relacional El objetivo del diseño lógico es convertir el esquema conceptual de datos en un esquema lógico ajustado específicamente al sistema de gestión de base de datos (DBMS) que se tenga a disposición. El objetivo de esta etapa es obtener una representación que use de la manera más eficiente posible los recursos para estructurar datos y modelar restricciones disponibles en el modelo lógico. En este apartado, presentaremos una metodología para el diseño lógico que tiene como objetivo el modelo relacional. Suponemos que el punto de partida es un esquema ER similar a los vistos hasta aquí. Este, consiste en un conjunto de definiciones de relaciones, en el cual cada relación tiene una clave primaria. Las relaciones producidas por la transformación de esquemas, corresponden a entidades o bien a relaciones y mantienen la misma forma normal. El concepto de forma normal será tratado en la próxima unidad con mayor profundidad. La metodología propuesta, convierte un esquema ER en un conjunto de entidades e interrelaciones, tales que su correspondencia con el modelo relacional sea sencilla. Para esto, deberán aplicarse los siguientes pasos: 1) Transformación de cada entidad del esquema en una relación. 2) Transformación de cada interrelación: las interrelaciones de muchos a muchos requieren una relación individual, mientras que las relaciones de uno a uno o de uno a muchos pueden ser modeladas añadiendo atributos a las relaciones existentes.

Transformación de Entidades Este paso es bastante simple: se transforma cada entidad del esquema en una relación. Los atributos y la clave primaria de la entidad, se convierten en los atributos y la clave primaria de la relación. Por ejemplo: Legajo EMPLEADO Nombre Telefono EMPLEADO( Legajo, Nombre, Telefono) 76

INSTITUCIÓN CERVANTES

Área Informática Base de Datos I

INSTITUCIÓN CERVANTES

Transformaciones de Interrelaciones de Uno a Uno Ahora, debemos tratar las interrelaciones. Se empieza por considerar las interrelaciones binarias de una manera general. Se verán las interrelaciones de uno a uno, de uno a muchos y de muchos a muchos de manera individual. El proceso de transformación es también influenciado por las cardinalidades mínimas de las dos entidades que participan en la interrelación. En principio las dos entidades E1 y E2 que participan en la interrelación, producen relaciones individuales; de otro modo se habrían fusionado durante el diseño lógico independiente del modelo. Respecto a la interrelación, hay que distinguir si las dos relaciones E1 y E2 tienen una participación total en la interrelación, o si una o ambas tienen una participación parcial en la misma. Así, tenemos los siguientes casos: Integración de una relación. Esta opción tiene sentido cuando la participación de las entidades en la interrelación es total. Hay dos posibilidades: Caso 1: Las dos entidades tienen las mismas claves primarias. Supóngase que tanto Clientes como Info-Envio tienen la misma clave primaria NUM_CLIENTE. En este caso, las dos relaciones correspondientes se integran en una relación combinando todos los atributos e incluyendo la clave primaria sólo una vez. (1,

Cliente Num_Cliente

Nombre_Cliente

Con

(1,

Num_Cliente

Info-Envio Direcci on_

Envio_Cliente (Num_Cliente, Nombre_Cliente, Direccion_Envio) Caso 2: Las dos entidades tienen claves primarias diferentes: Supóngase que Cliente e Info_Envio tienen diferentes claves primarias, digamos Num_Cliente, y (Codigo_Postal, Calle, Num_Casa), respectivamente. En este caso también se integran en una relación combinando todos los atributos e incluyendo las claves primarias de ambas. Una de las dos claves primarias será la clave primaria de la relación resultante; por ejemplo, en la relación que sigue se escoge Num_Cliente. Envio_Cliente (Num_Cliente, Nombre_Cliente, Num_Casa, Calle, Codigo_Postal). Definición de una relación aparte. Esta opción se usa cuando una o las dos entidades tienen una participación parcial. A continuación se muestra un caso de cada una: Caso 1: Una entidad con participación parcial. Esto se refiere, por ejemplo, a los clientes de un banco, a los cuales el banco emite cero o una tarjetas de crédito. En la figura anterior cada tarjeta de crédito debe pertenecer a un cliente, pero un cliente puede no tener tarjeta de crédito. En este caso, las dos relaciones, Cliente y Tarjeta de crédito, ya han sido creadas. Se define una relación adicional Posee_Tarjeta (Num_Cliente, Tipo_Tarjeta, Num_Tarjeta) usando la clave primaria de las dos relaciones. Tanto Institución Cervantes

77

INSTITUCIÓN CERVANTES

Num_Cliente como (Tipo_Tarjeta, Num_Tarjeta) son claves candidatas de Posee_Tarjeta, y por consiguiente pueden ser declaradas como clave primaria. Obsérvese que se puede usar la primera opción en este caso y representar todo en una sola relación (0,

Cliente Num_Cliente

Posee

(1,

Tarjeta_Cred Tipo_Tarjeta

Nombre_Cliente

Lim ite_

Num_Tarjeta

integrada. En ese caso se debe escoger Num_Cliente como clave primaria de la relación integrada; aquellos clientes que no posean tarjeta de crédito tendrán valores nulos de los atributos Tipo_Tarjeta, Num_Tarjeta. No se puede seleccionar (Tipo_Tarjeta, y Num_Tarjeta) como clave primaria de la relación integrada, porque en ese caso los clientes sin tarjeta de crédito no podrían ser representados. Cliente(Num_Cliente, Nombre_Cliente) Tarjeta_Credito(Tipo_Tarjeta, Num_Tarjeta, Limite_Credito) Posee_Tarjeta (Tipo_Tarjeta, Num_Tarjeta, Num_Cliente) Caso 2: Las dos entidades con participación parcial. Considérese la interrelación Matrimonio entre las entidades Varón y Mujer. En este caso ambas tienen una participación parcial en la interrelación Matrimonio. Para evitar valores nulos y representar tanto las entidades como la interrelación, se crea la relación Matrimonio (Nss_Varon, Nss_Mujer, Fecha, Duración) además de las relaciones Varon y Mujer. Fecha

Duración

(0,1) Varon

(0,1) MatrimonioPosee

Mujer

Nss_Mu Nombr Varon (Nss_Varon, Nombre) Mujer (Nss_Mujer, Nombre) Matrimonio (Nss_Varon, Nss_Mujer, Fecha, Duracion)

Transformación de Interrelaciones uno a muchos Considérese la interrelación R entre dos entidades, E1 y E2; supongamos que R es una interrelación uno a muchos. En este caso, se dará cuenta de la interrelación incluyendo la clave primaria de E1 en la relación correspondiente a E2 como uno o más atributos simples. Obsérvese que ya se ha dado cuenta de los identificadores externos. Por consiguiente, esta transferencia de la clave no tiene propósitos de identificación. Los posibles atributos de la interrelación tienen que ser trasladados a la relación que modela la entidad E2. Otra vez son posible dos casos:

78

INSTITUCIÓN CERVANTES

Área Informática Base de Datos I

INSTITUCIÓN CERVANTES

Caso 1: La entidad en el lado de ”muchos” tiene una participación obligatoria. En este ejemplo, el lado de muchos sería: un estado muchas ciudades; o sea que el lado de muchos es ciudades, ya que son muchas las ciudades que participan en la relación. En la figura siguiente se ejemplifica, donde hay una interrelación de uno a muchos entre Estado y Ciudad, Ciudad tiene una participación total en la interrelación; por tanto, la clave primaria Nombre_Estado de Estado se incluye en la relación Ciudad. Nombres

Ciudad

Habitantes

(1, Participación Total

Pertenece_a

(1, Nombre Gobernador Habitantes

Estado

Ciudad (Nombre_Ciudad, Nombre_Estado, Habitantes) Estado (Nombre_Estado, Gobernador, Habitantes) Caso 2: La entidad en el lado de “muchos” tiene una participación parcial. En la figura siguiente hay una interrelación entre Vendedor y Pedido. Supóngase que los pedidos pueden hacerse por medio de los vendedores, en cuyo caso se aplica una tasa de descuento, y también directamente sin vendedores, sin aplicar la tasa de descuento. Así pues, existe la posibilidad de valores nulos de Nombre_ Vendedor y Tasa_Descuento en la relación Pedido si se usan las siguientes correspondencias: Vendedor (Nombre, Num_telefono) Pedido (Num_Pedido, Nombre_Vendedor, Tasa_Descuento) Si el número de esos pedidos es grande, y no puede admitir valores nulos, una mejor alternativa sería establecer tres relaciones (lo cual es el caso más general): Nombre

Vendedor

Num_Telefono

(1,n Tasa_Descuento

Nombre

Participación Parcial

(0,1 Pedido

Num_Pedido Fecha

Vendedor (Nombre, Num_telefono) Pedido (Num_Pedido, Fecha) Pedido_Ventas (Num_Pedido, Nombre_Vendedor, Tasa_Descuento) Institución Cervantes

79

INSTITUCIÓN CERVANTES

Obsérvese que las dos relaciones, Pedido y Pedidos_Ventas contiene un sub conjunto de todos los pedidos, aquellos hechos a través de vendedores. Así se tiene la restricción adicional de que el conjunto de números de pedidos en Pedido_Ventas está siempre incluído en el conjunto de números de pedidos de la relación Pedido. Esta interrelación se denomina dependencia de inclusión de Num_Pedido en Pedido_Ventas respecto a Num_Pedido en Pedido en el momento relacional.

Transformación de Interrelaciones de muchos a muchos En el caso de interrelaciones de muchos a muchos, la solución no depende de la cardinalidad mínima de la interrelación. Supongamos que R es una interrelación de muchos a muchos entre E1 y E2. Se crea una relación nueva que tiene como clave primaria la combinación de atributos que constituyen las claves primarias, tanto de E1 como de E2, y que incluye como atributos los atributos de R. En el ejemplo de la figura, una relación de muchos a muchos Matriculado_En entre Estudiante y Curso se modela como una nueva relación Matriculado_En, que tiene como clave primaria el par (Numero Estudiante, Numero_Curso), con Semestre y Nota como atributos. Obsérvese que Numero_Estudiante y Numero_Curso son claves ajenas y tienen restricciones referenciales respecto a las claves primarias correspondientes. Numero_Estudiante Estudiante (1,n) Matric_En

Apellido Indice_Promedio

Semestre Nota

(1,n) Curso

Numero_Curso Nombre_Curso

Estudiante (Numero_Estudiante, Apellido, Indice_Promedio) Curso (Numero_Curso, Nombre_Curso) Matriculado_En (Numero_Estudiante, Numero_Curso, Semestre, Nota)

80

INSTITUCIÓN CERVANTES

INSTITUCIÓN CERVANTES

Área Informática Base de Datos I

Autoevaluación 1. Mencione los distintos componentes de la estructura del modelo relacional de datos. ........................................................................................ ........................................................................................ ........................................................................................ ........................................................................................ 2. ¿Cuál es la relación entre los términos formales y los términos relacionales? ........................................................................................ ........................................................................................ ........................................................................................ ........................................................................................ 3. ¿Qué tipos de claves maneja el modelo relacional? Defina y ejemplifique cada una. ........................................................................................ ........................................................................................ ........................................................................................ ........................................................................................ 4. ¿Qué reglas de integridad conoce? Defina y ejemplifique. ........................................................................................ ........................................................................................ ........................................................................................ ........................................................................................ 5. ¿Cuáles son los propiedades de las relaciones? Explique. ........................................................................................ ........................................................................................ ........................................................................................ ........................................................................................ 6. ¿Cómo transformaría de un diagrama ER una relación de uno a uno? Ejemplifique. ........................................................................................ ........................................................................................ ........................................................................................ ........................................................................................ Institución Cervantes

81

INSTITUCIÓN CERVANTES

7. ¿Cómo transformaría de un diagrama ER una relación de uno a muchos? Ejemplifique. ........................................................................................ ........................................................................................ ........................................................................................ ........................................................................................ 8. ¿Cómo transformaría de un diagrama ER una relación de muchos a muchos? Ejemplifique. ........................................................................................ ........................................................................................ ........................................................................................ ........................................................................................ 9. ¿Cuál es el objetivo del diseño lógico? ........................................................................................ ........................................................................................ ........................................................................................ ........................................................................................ 10. En caso de definir una clave ajena, ¿qué consideraciones debemos tener en cuenta al definirla? ¿por qué? ........................................................................................ ........................................................................................ ........................................................................................ ........................................................................................

82

INSTITUCIÓN CERVANTES

Área Informática Base de Datos I

INSTITUCIÓN CERVANTES




Unidad V

Descomposición y Normalización Objetivos
Adquirir una sólida base teórica y práctica en la teoría de la normalización.
Reconocer los distintos tipos de dependencias funcionales.
Obtener la capacidad de resolver problemas de anomalías de diseño en la estructuras

de datos.
Comprender el proceso de normalización de datos.

Institución Cervantes

83

INSTITUCIÓN CERVANTES

Normalización: Introducción Los sistemas de bases de datos son propensos a volverse problemáticos a la hora de diseñarlos. Las relaciones lógicas tienden a multiplicarse a medida que se agregan nuevas aplicaciones y que los usuarios exigen que el sistema este capacitado para responder a nuevas formas de interrogación utilizando los datos que almacena. El grado de complejidad de muchas bases de datos parece crecer sin limites previsibles, a menos que los diseñadores tengan un concepto muy claro de lo que está ocurriendo, esos sistemas se transformaran en una maraña de datos e interrelaciones. Es posible evitar el enmarañamiento a que dan lugar las estructuras ramificadas y plexo recurriendo a una técnica que se llama normalización. Las técnicas de normalización han sido ideas y recomendadas por E.F. Codd. “Se entiende por normalización la descomposición o subdivisión de una relación en dos o más relaciones para evitar la redundancia” (dividir una tabla en una o más tablas); en definitiva, que “cada hecho este en su lugar”. (C.J.Date) El proceso de normalización generalmente se utiliza en el enfoque relacional; sin embargo, un modelo relacional se puede modificar para su implantación en un DBMS jerárquico o de red. Una de las maneras más naturales de representar datos para el usuario es el que se basa en tablas bidimensionales (modelo relacional Unidad IV). El usuario esta familiarizado con tal estilo de representación y lo comprende, visualiza y recuerda con facilidad ya que lo hemos estudiado con anterioridad. Las tablas o relaciones en cuestión, son matrices rectangulares que pueden ser descritas matemáticamente. Las relaciones o tablas poseen algunas propiedades que creo sería conveniente resaltar: 1. Cada entrada de la tabla represente un ítem de datos; no hay grupos repetitivos (recordar que los valores de una entrado fila/columna son atómicos). 2. Son homogéneas por columnas, es decir los ítems de una columna son de la misma clase. Si la columna almacena fechas, todos los ingresos validos serán fechas. 3. Cada columna tiene nombre propio, el cual no se repite dentro de la misma tabla. 4. Todas las filas son diferentes, no se admiten filas duplicadas. 5. Tanto las filas como las columnas pueden ser consideradas en cualquier secuencia y en cualquier momento, sin afectar por ello ni el contenido de la información ni la semántica de cualquier función que utilice la tabla. La base de datos construida por medio de relaciones, es una base de datos relacional (como vimos en la unidad anterior).

84

INSTITUCIÓN CERVANTES

INSTITUCIÓN CERVANTES

Área Informática Base de Datos I

Requerimientos del usuario - Relación NO Normalizada Eliminar grupos repetidos 1° Forma Normal (1FN) Eliminar Dependencias Parciales 2° Forma Normal (2FN) Eliminar Dependencias Transitivas 3° Forma Normal (3FN) Este proceso se conoce como Normalización debido a que todos los pasos deben cumplir ciertas normas establecidas para lograr un buen diseño. Estos pasos deben cumplirse uno a continuación de otro sin saltear ninguno, y los principios que cada uno de ellos dictamina, deben cumplirse por cada etapa para poder pasar a la siguiente. Esto quiere decir por ejemplo, si debo bajar del colectivo, primero debo saber cual es la parada en la que lo haré. A continuación, tocaré el timbre y esperare a que el colectivo se detenga. Una vez que todo esto paso, me bajo. Nunca podría bajarme si el colectivo se encuentra aun en marcha, por ejemplo. Utilizando el esquema, resumiremos el proceso genérico de normalización: El proceso comienza con los requerimientos del usuario, los cuales nos llegan como una maraña de información en una relación no normalizada. Toda la información mezclada. Nuestra tarea, será la de encontrar la forma más óptima de almacenar los datos; esto quiere decir: sin redundancias innecesarias. La primera etapa es la de eliminación de grupos repetidos. Una vez eliminados los grupos repetidos, las relaciones (tablas) se encuentran en primera forma normal (1FN). Cuando todas las relaciones se encuentran en 1FN, se procede a la eliminación de las dependencias parciales. Cuando ya se eliminaron estas, las relaciones se encuentran en 2FN. Cuando ya no existen más dependencias parciales, se eliminan las dependencias transitivas y aquí ya se encuentran las relaciones en 3FN. Esta tarea, debe realizarse cada vez que nos enfrentemos con una base de datos nueva. Los pasos deben seguirse siempre y no puede faltar ninguno de ellos. Piensen en el concepto de Normas (leyes); estas están dictadas para ser cumplidas siempre. Si no se cumplen algo pasa, por ejemplo si la ley dice que no hay que robar y robaste, el castigo será ir preso. Si las anomalías no se corrigen, o sea que por ejemplo queda alguna dependencia transitiva sin corregir, el castigo será que la estructura de datos que estemos Institución Cervantes

85

INSTITUCIÓN CERVANTES

creando provoque redundancia en los datos almacenados, entonces deberemos atenernos a las consecuencias. Empecemos por entender el concepto de dependencia funcional:

Dependencia Funcional Las dependencias funcionales son una restricción al conjunto de relaciones legales. Nos permiten expresar hechos acerca de lo que estamos modelando con la base de datos. Existe una dependencia funcional (DF) entre dos atributos monovalentes, A1 y A2, de una entidad E o de una interrelación R, si cada valor de A1 corresponde exactamente a un valor de A2. Estudiaremos esta propiedad con un ejemplo: Sean A1, A2 dos atributos de una entidad E; supóngase que existe un caso de entidad E1 de E que tiene los valores a1 y a2 para A2:

La dependencia funcional entre A1 y A2 implica que si existe otro caso de entidad, e2, en el que A1 adopta el valor a1, entonces A2 debe adoptar el valor a2:

En este punto podemos decir que en un esquema correcto, todos los identificadores internos de las entidades, determinan funcionalmente a los otros atributos monovalentes. El ejemplo de la figura muestra la entidad persona con dos identificadores internos, Num-seg-soc y el par (Nombre, Fecha-de-Nacimiento). Otros atributos son Dirección, Ciudad, Provincia y Codigo-Postal. Por tanto, tenemos las siguientes DF: NUM-SEG-SOC
NOMBRE, FECHA-DE-NACIMIENTO, DIRECCIÓN, CIUDAD, PROVINCIA, CODIGO-POSTAL

Nombre

Persona

Fecha-deNacimiento Num-Seg-Soc

NOMBRE, FECHA-DE-NACIMIENTO
DIRECCION, CIUDAD, NUM-SEG-SOC, PROVINCIA, CODIGO-POSTAL

Decimos que A1 determina funcionalmente a A2, lo cual se denota también como A1
A2; el Ciudad atributo a la izquierda de la DF se llama el Provincia determinante. Las DF se establecen de forma Codigo-Postal similar entre conjuntos de atributos; por ejemplo, A1, A2
A3 (el par de atributos [A1, A2] es, en este caso, el determinante) o A1
A2,A3. Cuando el lado derecho de una DF es un conjunto S de n atributos, la DF original es equivalente a n dependencias funcionales individuales, cada una con un atributo sencillo de S como lado derecho. Por ejemplo la dependencia A1
A2,A3 es equivalente a las dos DF A1
A2 y A1
A3 por separado. Las DF se establecen, asimismo, entre atributos de interrelaciones, exactamente con la misma interpretación. 86

Dirección

INSTITUCIÓN CERVANTES

Área Informática Base de Datos I

INSTITUCIÓN CERVANTES

Estas dependencias dicen que si se asigna el valor de los atributos determinantes, se encontrará, en la base de datos, un valor de los atributos determinados. Esto es una consecuencia trivial del hecho de que los identificadores son también determinantes. Asimismo, se tiene una DF adicional, CODIGO-POSTAL
CIUDAD, PROVINCIA que expresa la propiedad de que las personas con el mismo CODIGO-POSTAL viven en la misma CIUDAD y PROVINCIA. Num-de-Ped Nombre-de-Pieza Costo

Pedido

Cantidad Fecha

Las dependencias funcionales nos permiten expresar restricciones que no pueden expresarse por medio de superclaves. Considérese el esquema siguiente: Num-de-Ped Nombre-de-Pieza Costo

Pedido

Cantidad Fecha

Esquema (préstamo) = nombre-sucursal, numero-préstamo, nombre-cliente, cantidad. Ejemplo: si un préstamo se hace a más de un cliente en este caso a marido/mujer, entonces no esperaríamos que el atributo numero-préstamo fuera una superclave.

Anomalías de Actualización Si bien las dependencias funcionales que corresponden a identificadores no causan problemas, otras dependencias que pueden existir en una entidad pueden causar las llamadas anomalías de actualización. El ejemplo de la figura, que describe pedido en términos de números de pedidos, piezas pedidas, fecha de pedido, costo de cada pieza, y cantidad pedida de cada pieza. El identificador de la entidad está dado por el par (Num-Ped, Nombre-de-Pieza); de aquí, se deduce la siguiente dependencia: Num-Ped, Nombre-de-Pieza
Costo, Cantidad, Fecha La entidad Pedido 01 1518 Bolígrafo 02 1518 Lapicero 03 1521 Lapicero 04 1407 Bolígrafo 05 1407 Borrador 06 1407 Pizarra 07 1407 Borrador 08 1729 Disquete 09 1729 Lapicero Institución Cervantes

1.0 0.5 0.5 1.0 0.2 5.0 0.2 2.0 0.5

12 15 18 15 28 3 1 10 15

03/08/99 03/08/99 02/09/99 02/06/99 02/06/99 02/06/99 03/01/99 03/01/00 03/01/00 87

INSTITUCIÓN CERVANTES

Casos de la entidad pedido Sin embargo, el costo de una pieza está determinado de manera única, por su número de pieza; esto se afirma mediante la siguiente dependencia funcional: Nombre-de-Pieza
Costo Esta es la causa de la redundancia mostrada en los casos de la entidad; por ejemplo, el costo de los lápices se repite tres veces. Más aún se reconocen las siguientes anomalías: 1. Anomalía de Inserción: No se puede indicar el costo de una pieza, a menos que tenga algunos pedidos pendientes. 2. Anomalía de Eliminación: Cuando se borra el último pedido pendiente para una pieza, también se borra la información para su costo. 3. Anomalía de Actualización: Si cambia el costo de algunas piezas, todos los pedidos referentes a esas piezas cambian también; la operación de actualización se propaga a varios casos de la entidad. Todas estas anomalías se relacionan con la presencia de una dependencia funcional indeseable, a saber, Nombre-de-pieza
Costo. Una anomalía semejante se debe a la dependencia Num-Ped
Fecha. El proceso de normalización es una progresiva detección y eliminación de esas dependencias no deseadas.

Normalización de Bases de Datos Peligros en el diseño de bases de datos relacionales Uno de los retos en el diseño de la base de datos es el de obtener una estructura estable y lógica tal que: El sistema de base de datos no sufra de anomalías de almacenamiento.
El modelo lógico pueda modificarse fácilmente para admitir nuevos requerimientos.


Una base de datos implantada sobre un modelo bien diseñado tiene mayor esperanza de vida, aún en un ambiente dinámico, que una base de datos con un diseño pobre. En promedio, una base de datos experimenta una reorganización general cada seis años, dependiendo de lo dinámico de los requerimientos de los usuarios. Una base de datos bien diseñada tendrá un buen desempeño, aunque aumente su tamaño, y será lo suficientemente flexible para incorporar nuevos requerimientos o características adicionales. Existen diversos riesgos en el diseño de las bases de datos relacionales que afecten la funcionalidad de la misma, los riesgos generalmente son la redundancia de información y la inconsistencia de datos. 88

INSTITUCIÓN CERVANTES

INSTITUCIÓN CERVANTES

Área Informática Base de Datos I

La normalización o descomposición, es el proceso de simplificar la relación entre los campos de un registro. Por medio de la normalización un conjunto de datos en un registro se reemplaza por varios registros que son más simples y predecibles y, por lo tanto, más manejables. La normalización se lleva a cabo por cuatro razones: 1. Estructurar los datos de forma que se puedan representar las relaciones pertinentes entre los datos. 2. Permitir la recuperación sencilla de los datos en respuesta a las solicitudes de consultas y reportes. 3. Simplificar el mantenimiento de los datos actualizándolos, insertándolos y borrándolos. 4. Reducir la necesidad de reestructurar o reorganizar los datos, cuando surjan nuevas aplicaciones. En términos más sencillos la normalización trata de simplificar el diseño de una base de datos, esto a través de la búsqueda de la mejor estructuración que pueda utilizarse con las entidades involucradas en ella.

Pasos de la normalización Como vimos al comienzo de esta unidad, los pasos de la normalización son: 1. Descomponer todos los grupos de datos en registros bidimensionales. (Eliminar grupos repetidos) 2. Eliminar todas las relaciones en la que los datos no dependan completamente de la llave primaria del registro. (Eliminar dependencias parciales) 3. Eliminar todas las relaciones que contengan dependencias transitivas. La teoría de normalización tiene como fundamento el concepto de formas normales; se dice que una relación está en una determinada forma normal si satisface un conjunto de restricciones.

Formas Normales Es el conjunto de normas que nos ayudan a diseñar una estructura de Bases de Datos óptima para su implementación, gestión y explotación desde distintas aplicaciones, consiguiendo independencia de ellas (de las aplicaciones Tutor-12). El creador de estas normas fue E.F.Codd, quién formulo las 3 primeras formas normales (1FN, 2FN y 3FN) a las que siguieron otras (FNBC, 4FN y 5FN). La razón de ser de las formas normales consiste en la estandarización de los conceptos relacionados al diseño eficiente de las estructuras y esquemas de una base de datos.

Institución Cervantes

89

INSTITUCIÓN CERVANTES

Durante mucho tiempo se ha dependido en extremo de la experiencia y capacidad de los analistas y diseñadores de bases de datos. Como es obvio, existirán discrepancias entre los métodos que estos aplican para obtener un modelo eficiente. Las formas normales permitirán la aplicación de un estándar de eficiencia en niveles ascendentes mediante la aplicación de las mencionadas formas normales. Se dice que una relación (tabla) está en una Forma Normal determinada si satisface cierto conjunto especifico de restricciones.

Universo de Relaciones

Para avanzar de una Forma Normal a otra, deben verificarse las restricciones de la actual y la nueva Forma Normal. Una de las herramientas más utilizadas para alcanzar una nueva forma normal es la DESCOMPOSICIÓN. Esto proceso consiste en tomar la relación NO normalizada entregada por el usuario y descomponerla (desarmarla) en relaciones más pequeñas, las cuales, al ser más pequeñas, son más estables y más fáciles de manejar. Esta debe presentar las siguientes características:
Debe realizarse sin perdida de datos
Deben mantenerse las dependencias funcionales
Se debe evitar o reducir hasta donde sea posible la redundancia.

Primera forma normal Definición formal: “Una relación R esta en primera forma normal (1FN) y si y solo si todos los dominios subyacentes solo contienen valores atómicos”. Un dominio es atómico si los elementos del dominio se consideran unidades invisibles (a cada valor de campo solo se le asigna un único valor). Por ejemplo: El campo Edad para el alumno Juan, será 25 y solo 25; puede ir variando con el tiempo, pero ese campo siempre tendrá un solo valor asignado cada vez.

90

INSTITUCIÓN CERVANTES

INSTITUCIÓN CERVANTES

Área Informática Base de Datos I

Una relación R se encuentra en 1FN, si y solo si, cada intersección fila/columna contiene valores atómicos. Abreviada como 1FN, se considera que una relación se encuentra en la primera forma normal cuando cumple lo siguiente:
Las celdas de las tablas poseen valores simples y no se permiten grupos ni arreglos

repetidos como valores, es decir, contienen un solo valor por cada celda.
Todos los ingresos en cualquier columna(atributo) deben ser del mismo tipo.
Cada columna debe tener un nombre único, el orden de las columnas en la tabla no es importante.
Dos filas o renglones de una misma tabla no deben ser idénticas, aunque el orden de las filas no es importante. Por lo general la mayoría de las relaciones cumplen con estas características, así que podemos decir que la mayoría de las relaciones se encuentran en la 1FN. Para ejemplificar cómo se representan gráficamente las relaciones en primera forma normal, consideremos la relación alumno cursa materia, cuyo diagrama E-R es el siguiente:

Como esta relación maneja valores atómicos, es decir un solo valor por cada uno de los campos que conforman a los atributos de las entidades, ya se encuentra en primera forma normal, gráficamente así representamos a las relaciones en 1FN.

Segunda forma normal Para definir formalmente la segunda forma normal (2FN), requerimos recordar el concepto de dependencia funcional: Consiste en identificar qué atributos dependen de otro(s) atributo(s). Atributos Dependientes

Atributo que determinante

Definición formal: “Una relación R está en 2FN, si y solo si, está en 1FN y los atributos no primos dependen funcionalmente o completamente de la clave primaria”. Tutor-8 Institución Cervantes

91

INSTITUCIÓN CERVANTES

Una relación se encuentra en 2FN, cuando cumple con las reglas de la 1FN y todos sus atributos que no son claves llaves) dependen por completo de la clave. De acuerdo con esta definición, cada tabla o relación que tiene una clave primaria formada por un solo atributo, ya está en 2FN. La 2FN es transgredida cuando un campo no clave es un dato sobre un subconjunto de una clave primaria (compuesta) o depende parcialmente de una parte de la clave primaria. t93

D Ejemplo Consideremos el siguiente esquema propuesto para un registro de inventario. ARTÍCULO

BODEGA

CANTIDAD

DIRECCIÓN-BODEGA

Aquí, la clave está formada por (ARTÍCULO, BODEGA), o sea es una clave compuesta. Se puede observar fácilmente que DIRECCIÓN-BODEGA es un dato acerca de BODEGA y no de ARTICULO, por lo que no se estaría cumpliendo con la 2FN. Los problemas básicos de diseño son:
La dirección de la bodega se repite para cada artículo que se almacena en esa bodega

(redundancia).
Si la dirección de bodega cambia, cada registro que se refiera a un artículo almacenado en esa bodega debe ser actualizado. Debido a la redundancia, los datos pueden llegar a ser inconsistentes, con diferentes registros indicando diferentes direcciones para la misma bodega (integridad).
Si en algún momento no hubiera partes almacenadas en alguna bodega, no habría un registro para anotar la dirección de la bodega (anomalía). Para satisfacer la segunda forma normal, el esquema anterior debe ser reemplazado por el siguiente: ARTÍCULO BODEGA

BODEGA

CANTIDAD

DIRECCIÓN

A partir del ejemplo, podemos decir, que si una relación o tabla tiene una clave primaria simple (o sea formada por un solo atributo o campo) la relación ya se encuentra en 2FN. La segunda forma normal se representa por dependencias funcionales como: 92

INSTITUCIÓN CERVANTES

Área Informática Base de Datos I

INSTITUCIÓN CERVANTES Nombre Control

Nom_M Clave

Esp.

Creditos

Nótese que las llaves primarias están representadas con doble cuadro, las flechas nos indican que de estos atributos se puede referenciar a los otros atributos que dependen funcionalmente de la llave primaria.

Tercera Forma Normal Para definir formalmente la 3FN necesitamos definir dependencia transitiva: En una afinidad (tabla bidimensional) que tiene por lo menos 3 atributos (A, B, C), en donde A determina a B, B determina a C, pero no determina a A.

Definición formal: “Una relación R está en 3FN, si y solo si, está en 2FN y todos sus atributos no primos dependen no transitivamente de la clave primaria”. Consiste en eliminar la dependencias transitivas que queda en una 2FN, en pocas palabras, una relación está en tercera forma normal si está en segunda forma normal y no existen dependencias transitivas entre los atributos. Nos referimos a dependencias transitivas cuando existe más de una forma de llegar a referencias a un atributo de una relación. Por ejemplo, consideremos el siguiente caso:

Tenemos la relación alumno-cursa-materia utilizada anteriormente, pero ahora consideramos al elemento maestro, gráficamente lo podemos representar de la siguiente manera: Institución Cervantes

93

INSTITUCIÓN CERVANTES

Podemos darnos cuenta de que se encuentra graficado en 2FN, es decir que todos los atributos llave están indicados en doble cuadro indicando los atributos que dependen de dichas llaves, sin embargo en la llave Necono tiene como dependientes a 3 atributos, en el cual el nombre puede Nombre ser referenciado por dos Control Clave atributos: Necono y RFC (Existe dependencia Esp. transitiva), podemos solucionar esto aplicando la tercera Nombre forma normal que consiste en eliminar Necono estas dependencias separando los atributos, Plaza entonces tenemos:

Necono

Plaza

Otro ejemplo: Nombr e Cont rol

Nom M Clav e

Esp.

Credito s

Nombr e Neco no

RFC Plaza

NCLI 11 44 55 Relación CLIENTES NCLI 11 44 55

94

NOMBRE CP Luis 5000 Ana 4000 José 3500

NOMBRE Luis Ana José

LOCALIDAD Málaga Gijón Valencia

CP 5000 4000 3500 Relación LOCALIDADES LOCALIDAD Málaga Gijón Valencia Salamanca

CP 5000 4000 3500 4500

INSTITUCIÓN CERVANTES

Nom M

Creditos

Área Informática Base de Datos I

INSTITUCIÓN CERVANTES

Forma Normal de Boyce Codd Incluso las relaciones en 3FN, pueden tener anomalías. Considera la tabla ASESOR de la figura. Suponga que los requerimientos de esta relación son que un estudiante (LEG) pueda tener una o más especialidades, una especialidad pueda tener varios miembros de la facultad (NomFac) como consejeros, y un miembro de la facultad (NomFac) sólo imparte asesoría en un área de especialidad. Puesto que los estudiantes pueden tener varias especialidades, LEG no determina funcionalmente Especialidad (recuerden el concepto de dependencia funcional). Como los estudiantes pueden tener varios asesores, LEG tampoco determina NomFac. LEG por si mismo no puede ser una clave. La combinación (LEG, Especialidad) determina NomFac y la combinación (LEG, NomFac) determina Especialidad. Cualquiera de las combinaciones puede ser una clave. De lo que vimos en la unidad anterior, deducimos que ambas combinaciones son claves candidatas, esto es, que cualquiera de las dos puede ser clave primaria. Además de las claves candidatas, hay otra dependencia funcional: NomFac determina a Especialidad (cualquier miembro de la facultad asesora en sólo una especialidad, por lo tanto si conozco NomFac se puede determinar Especialidad). ASESOR está en 1FN. También está en 2FN pues cualquier atributo que no es clave depende de toda la clave, sin importar cual clave candidata se seleccione. También está en 3FN porque no tiene dependencias transitivas. A pesar de esto, existen anomalías de actualización. Suponga que el estudiante 300 deja la facultad. Si se quita la fila de estudiante 300 se perderá el hecho de que Romero imparte asesoría de Matemáticas. Esta es una anomalía de eliminación. En forma similar, cómo se almacena el hecho de que Toledo asesora en Programación? No es posible hasta que un estudiante se inscribe en esa materia. Esta es una anomalía de inserción. ASESOR(LEG, Especialidad, NomFac) Clave Primaria: (LEG, Especialidad) Clave Candidata: (LEG, NomFac) Dependencias Funcionales: NomFac LEG 100 200 300 250 300

Institución Cervantes

Especialidad Matemáticas Programación Matemáticas Programación Matemáticas

Especialidad NomFac Rios Yudi Rios Costa Romero

95

INSTITUCIÓN CERVANTES

NomFac Rios Yudi Costa Romero

Especialidad Matemáticas Programación Programación Matemáticas

LEG 100 200 300 250 300

NomFac Rios Yudi Rios Costa Riomer

Situaciones como esta, conducen a la definición de la Forma Normal de Boyce-Codd (BNCF): “Una relación R esta en FNBC (Forma Normal de Boyce Codd), si y solo si, cada determinante es una clave candidata”. La solución a esta anomalía es descomponer la relación ASESOR en dos relaciones nuevas que no tengan anomalías. Por ejemplo, las relaciones ESTU-ASE(LEG, NomFac), clave: LEG,NomFac; y ASE-MATERIA(NomFac, Especialidad), clave: NomFac, Especialidad. DEPENDENCIAS DE VALORES MULTIPLES (DVM). El concepto de dependencia funcional nos ha llevado a descomponer las relaciones en la 3FN y la forma de BOYCE-CODD, con lo que concluye el proceso de normalización. A veces estas formas son insuficientes para eliminar la redundancia y las anomalías de actualización si una relación contiene dependencias de valores múltiples, lo cual conlleva una normalización adicional: la cuarta forma normal (4FN). En la dependencia de valores múltiples (DVM), un valor atributo, A, determina un conjunto de valores múltiples, B. Se expresa con doble flecha: A

B

Consideramos la relación ESTUDIANTE (NUM, CURSO, DEPORTE) que indica su número, el curso donde está matriculado y los deportes que practica, como se muestra en la siguiente figura: NUM

CURSO

DEPORTE

10 10 20 20

Base de datos Base de datos Base de datos Física Física

Baloncesto Natación Tenis Baloncesto Esgrima

Relación en la tercera forma con redundancia. Los atributos CURSO y DEPORTE son dependientes multivalores de NUM, es decir, cualquier valor de NUM determina una serie de valores de los atributos CURSO y DEPORTE. Se puede expresar: 96

INSTITUCIÓN CERVANTES

Área Informática Base de Datos I

INSTITUCIÓN CERVANTES

NUM NUM

CURSO DEPORTE

o

NUM

CURSO DEPORTE Existe una dependencia de valores múltiples cuando una relación tiene por lo menos tres atributos, dos de los cuales poseen valores múltiples y sus valores dependen solo del tercer atributo, en otras palabras, en la relación R (A, B, C) existe una dependencia de valores múltiples, si A determina valores múltiples de B, A determina valores múltiples de C, y B y C son independientes entre sí.

Cuarta Forma Normal Definición formal: “Una relación se encuentra en 4FN si está en BCFN y no tiene dependencias de valores múltiples (DMV)”. Para entender mejor esto, consideremos una afinidad (tabla) llamada estudiante que contiene los siguientes atributos: Clave, Especialidad, Curso tal y como se demuestra en la siguiente figura: Clave S01 S01 S01 B01 C03

Especialidad Sistemas Bioquímica Sistemas Bioquímica Civil

Curso Natación Danza Natación Guitarra Natación

Suponemos que los estudiantes pueden inscribirse en varias especialidades y en diversos cursos. El estudiante con clave S01 tiene su especialidad en Sistemas y Bioquímica y toma los cursos de natación y danza, el estudiante B01 tiene la especialidad en Bioquímica y toma el curso de guitarra, el estudiante con clave C03 tiene la especialidad de Civil y toma el curso de natación. En esta tabla o relación no existe dependencia funcional, porque los estudiantes pueden tener distintas especialidades, un valor único de clave puede poseer muchos valores de especialidades al igual que de valores de cursos. Por lo tanto, existe dependencia de valores múltiples. Este tipo de dependencias produce redundancia de datos, como se puede apreciar en la tabla anterior, en donde la clave S01 tiene tres registros para mantener la serie de datos, en forma independiente, lo cual ocasiona que al realizarse una actualización se requiera de demasiadas operaciones para tal fin. En la tabla anterior, Clave determina valores múltiples de especialidad y Clave determina valores múltiples de curso, pero especialidad y curso son independientes entre sí. Las dependencias de valores múltiples se definen de la siguiente manera: Institución Cervantes

97

INSTITUCIÓN CERVANTES

Clave
Especialidad y Clave
Curso; Esto se lee “Clave multidetermina a Especialidad, y clave multidetermina a Curso” Para eliminar la redundancia de los datos, se deben eliminar las dependencias de valores múltiples. Esto se logra construyendo dos tablas, donde cada una almacena datos para solamente uno de los atributos de valores múltiples. Para nuestro ejemplo, las tablas correspondientes son: Tabla Especialidad Clave S01 B01 C03

Especialidad Sistemas Bioquímica Civil

Tabla Curso Clave S01 S01 B01 C03

8

Curso Natación Danza Guitarra Natación

Nota Si una relación esta en 4FN, esta también en FNBC, la relación no es reciproca

Desnormalización Debemos tener en cuenta, que la Normalización no es la panacea. Hay casos en que se hace necesario realizar todo lo contrario. Un ejemplo de la desnormalización, la encontramos en los sistemas DataWareHousing o Almacenes de Datos que se están utilizando cada vez en mayor medida. Estos grandes almacenes de datos, se utilizan para brindar a los usuarios (sobre todo a los niveles gerenciales) información para la toma de decisiones. Los sistemas basados en tecnologías 4GL (lenguajes de cuarta generación) como PROGRESS, INFORMIX u ORACLE, son grandes motores de bases de datos los cuales cuentan entre sus herramientas con la posibilidad de crear este tipo de almacenamiento. Otro tema interesante es la minería de datos, que sería productivo que buscaran más información en Internet. La minería de datos es la herramienta que permite localizar los datos buscados o solicitados por los usuarios a partir de un requerimiento dentro del almacén de datos. Estos temas son muy interesantes y es la tecnología que ya está aterrizando en los sistemas de información y de bases de datos. Para que comprendan un poco el concepto de Almacén de Datos, les cuento más o menos que son: es juntar toda la información en una gran bolsa; tomar todas las bases de datos de la empresa y juntarlas en una sola. El hecho de juntar todas las bases de datos genera un montón de redundancia, que como vimos, es perjudicial para los sistemas de bases de datos relacionales. En estos motores de búsqueda, cuanto mayor redundancia, mejor van a ser los resultados de las búsquedas. Las búsquedas en esta montaña de información, se realizan utilizando herramientas propias de estos 4GL; a este proceso se 98

INSTITUCIÓN CERVANTES

Área Informática Base de Datos I

INSTITUCIÓN CERVANTES

lo conoce como Minería de Datos (escarbar en la montaña para lograr encontrar la pepita de oro). Las relaciones normalizadas, evitan anomalías de modificación y se prefieren a las relaciones no normalizadas. Valorada bajo otros criterios, algunas veces la normalización no vale la pena. Consideremos esta relación: CLIENTE(NroCli, NomCli, Ciudad, Provincia, CodPos) Donde NroCli es la clave. Esta relación no está normalizada porque contiene la dependencia funcional CodPos

(Ciudad, Provincia)

la cual no está implícita en la clave NroCli. Por lo tanto, existe una restricción que no está implícita por la definición de clave. Esta relación puede transformarse en: CLIENTE(NroCli, NomCli, CodPos) donde la clave es NroCli CODIGOS(CopPos, Ciudad, Provincia) donde la clave es CodPos Estas dos relaciones están en la forma normal correcta, pero es muy probable que no representen el mejor diseño. Tal vez sea mejor la tabla no normalizada, será más fácil de procesar y no son muy importantes las desventajas de duplicar los datos de Ciudad y Estado. En resumen, algunas veces las relaciones se dejan a propósito no normalizadas o están normalizadas y después desnormalizadas. Esto se hace para mejorar el funcionamiento. Siempre que los datos deben combinarse de dos tablas separadas, el DBMS debe efectuar un trabajo adicional. En la mayoría de los casos, se requieren cuando menos dos lecturas, en vez de una.

Institución Cervantes

99

INSTITUCIÓN CERVANTES

Autoevaluación 1. Defina dependencia Funcional. 2. Defina Dependencia Parcial. 3. Defina Dependencia Transitiva. 4. Defina Dependencias de valores múltiples. 5. Qué es una anomalía de inserción. 6. Qué es una anomalía de eliminación. 7. Que es una anomalía de actualización. 8. Defina la 1FN. Proporcione un ejemplo de una relación en 1FN y no en 2FN. 9. Defina la 2FN. Proporcione un ejemplo de una relación en 2FN y no en 3FN. 10. Defina la 3FN. Proporcione un ejemplo de una relación en 3FN y no en BCFN. 11. Defina el término NORMALIZACION.

100

INSTITUCIÓN CERVANTES

INSTITUCIÓN CERVANTES

Área Informática Base de Datos I

Tutores t1


Dato Los datos corresponden al registro discreto (no continuo) de hechos acerca de un fenómeno, con lo cual ganamos información (incremento del conocimiento que puede ser inferido de los datos) acerca del mundo que nos rodea.

t2


Restricciones Estáticas Reglas que restringen el conjunto de valores que la base de datos (estructura) puede tomar. Por ejemplo, si el campo es numérico, sólo admitirá números. Hacen referencia al DDL del modelo.

t3


Restricciones Dinámicas Reglas que restringen las transiciones entre valores válidos de la base de datos (estructura). Hacen referencia al DML del modelo.

t4


Manipulación de los datos Definición de los procedimientos por los cuales la base de datos (estructura) cambia de un valor (estado) a otro. Alta de un registro, baja de un registro, modificación de datos, etc.

t5


Por n se entiende “infinito” o “ilimitado”. El número estará en realidad limitado al número de ocurrencias de la clase EDIFICIO en la base de datos.

t6


Semántica Los lenguajes son herramientas creadas por el hombre (u otros seres) con el fin de comunicarse. Son imprescindibles para poder concebir modelos, pues uno expresa a lo más lo que el lenguaje le permite. Además, los lenguajes son los que permiten comunicar los modelos a otros (que comprenden dichos lenguajes), validarlos, discutirlos y ampliar la percepción del otro sobre un mismo fenómeno. Para efectos de este curso, consideraremos los siguientes componentes de los lenguajes. 1. La sintaxis. Es el conjunto de símbolos permitidos en el lenguaje. (por ejemplo las letras del abecedario o todas las palabras del idioma español) 2. Una gramática. Son las reglas generadoras del lenguaje. (por ejemplo la gramática del español) 3. La semántica. Es el significado asociado al lenguaje (por ejemplo, el significado de las palabras y su interpretación dentro de un contexto dado. Por ejemplo "el kilo de pan cuesta $ 460 se registra el valor (460) y su significado o semántica (valor del kilo de pan en pesos).

t7


Secuencial Acceso secuencial significa recorrer el archivo desde el principio y uno por uno los registros sin saltear ninguno hasta llegar al registro deseado. En forma de secuencia, uno a continuación de otro.

Institución Cervantes

101

INSTITUCIÓN CERVANTES

t8


Un atributo es no primo si no participa en la clave primaria.

t9


“Dependencia parcial: dependencia funcional con una determinante que es PARTE de la clave (tabla con clave primaria compuesta: todos los atributos que no forman parte de una clave primaria NO dependen de la totalidad de la clave primaria)”

t10


Claves Compuestas Las claves pueden ser simples o compuestas. Son simples cuando la clave está formada por un solo atributo. Son compuestas cuando la clave está formada por más de una atributo. Por ejemplo: NOTAS(LEG, CODMAT, NOTA) la clave será compuesta LEG,CODMAT, ambas y son indivisibles. ALUMNOS(LEG, NOM, TE) la clave es simple ya que está formada por LEG solamente.

t11


Metadatos Son datos acerca de los datos presentes en la base de datos. Describen el nombre que se les da, el tipo y la longitud asignada a cada dato elemental.

t12


Independencia Recuerden el principio de independencia de los datos respecto de las aplicaciones visto en la unidad I.

102

INSTITUCIÓN CERVANTES

INSTITUCIÓN CERVANTES

Área Informática Base de Datos I

Indice Fundamentación ..................................................................... 1 Objetivos Generales ............................................................... 1 Mapa Conceptual ................................................................... 2 Programa ............................................................................... 3 Bibliografía y materiales de consulta ...................................... 4 Orientaciones Metodológicas .................................................. 4 Evaluación .............................................................................................................. 4 Evaluación Diagnóstico ........................................................... 6

U NIDAD I Introducción al Diseño de Bases de Datos ............................... 7 Objetivos ............................................................................................................... 7 Introducción .......................................................................................................... 8 Introducción al Diseño de Bases de datos............................................................. 8 Ciclo de vida de un sistema de información........................................................ 10 Ventajas de las bases de datos frente a los ficheros clásicos ............................... 11 Independencia de los datos...................................................................................................12

Fases del Diseño de Bases de Datos ................................................................... 12 Concepto de Dato y Modelo de Dato .................................... 15 El significado de dato ........................................................................................... 15 Modelamiento de Datos...................................................................................... 16 Modelo de Datos: Introducción .......................................................................... 17 Autoevaluación .................................................................................................... 19

U NIDAD II Modelado de Datos .............................................................. 21 Objetivos ............................................................................................................. 21 Procesos de Abstracción en el modelamiento de Datos .................................... 22 Propiedades de las correspondencias entre las clases ........................................ 24 Jerarquías de Generalización ...............................................................................................26

Modelos de Datos ............................................................................................... 27 El modelo de entidades-interrelacionadas (ER) .................................................. 28

Elementos básicos del modelo Entidad Relación ...............................................................28 Los Mecanismos de abstracción en el modelo ER (Entidad-Relación) ............................31

Cualidades del modelo ER................................................................................... 31 Cómo Modelar en MER....................................................................................... 35 Autoevaluación .................................................................................................... 36

U NIDAD III

Arquitectura de las bases de datos ....................................... 37 Objetivos ............................................................................................................. 37 Estructuras de Bases de Datos ............................................................................ 38 Archivos Planos.................................................................................................... 38 Procesamiento de Archivos Planos ..................................................................... 39 Lista Secuencial.....................................................................................................................39

Institución Cervantes

103

INSTITUCIÓN CERVANTES

Mantener un orden con listas vinculadas............................................................................ 40 Mantener un orden con índices ........................................................................................... 43

Bases de Datos Jerárquicas.................................................................................. 44 Propiedades de los esquemas jerárquicos........................................................... 45 El Modelo de Redes ............................................................................................. 46 Los tres niveles de la arquitectura de una base de datos .................................... 48 El nivel externo ..................................................................................................................... 48 El nivel conceptual................................................................................................................ 49 El nivel interno...................................................................................................................... 49 Nivel Interno: Acceso a la Base de Datos............................................................................ 50

Manejador de disco (Disk Manager).................................................................... 51 Manejador de archivos (File Manager)................................................................. 51 Agrupamiento o Clustering.................................................................................................. 51 Indexación ............................................................................................................................. 52 Indexación densa y no densa................................................................................................ 53

Arboles B (B-Trees)............................................................................................. 54 El Administrador de Bases de Datos (DBA) ........................................................ 56 Funciones del DBA .............................................................................................................. 56 El sistema de administración de bases de datos (DBMS o SMBD).................................. 57 Funciones del DBMS ........................................................................................................... 58

El administrador de comunicación de datos........................................................ 59 Procesamiento Distribuido................................................................................................... 59 Sistemas de Teleprocesamiento ........................................................................................... 62 Sistemas Cliente / Servidor .................................................................................................. 63

Autoevaluación .................................................................................................... 65

U NIDAD IV El Modelo de datos Relacional ............................................... 67 Objetivos.............................................................................................................. 67 El modelo Relacional............................................................................................ 68 Estructura de datos Relacional............................................................................. 68 Propiedades de las relaciones.............................................................................. 70 Tipos de relaciones.............................................................................................. 71 Integridad en el modelo relacional ...................................................................... 72 Restricciones de integridad en los esquemas relacionales.................................................. 72

Claves Primarias................................................................................................... 72 Claves Ajenas ....................................................................................................... 74 Reglas para claves ajenas ...................................................................................................... 75

Diseño lógico en el modelo relacional................................................................. 76

Transformación de Entidades.............................................................................................. 76 Transformaciones de Interrelaciones de Uno a Uno ......................................................... 77 Transformación de Interrelaciones uno a muchos............................................................. 78 Transformación de Interrelaciones de muchos a muchos ................................................. 80

Autoevaluación .................................................................................................... 81

U NIDAD V Descomposición y Normalización .......................................... 83 Objetivos.............................................................................................................. 83 Normalización: Introducción ............................................................................... 84 Dependencia Funcional........................................................................................ 86 Anomalías de Actualización ................................................................................. 87 104

INSTITUCIÓN CERVANTES

INSTITUCIÓN CERVANTES

Área Informática Base de Datos I

Normalización de Bases de Datos....................................................................... 88 Peligros en el diseño de bases de datos relacionales............................................................88 Pasos de la normalización.....................................................................................................89

Formas Normales................................................................................................ 89 Universo de Relaciones ......................................................................................................... 90 Primera forma normal........................................................................................................... 90 Segunda forma normal .........................................................................................................91 Tercera Forma Normal.........................................................................................................93 Forma Normal de Boyce Codd ............................................................................................95 Cuarta Forma Normal..........................................................................................................97 Desnormalización .................................................................................................................98

Autoevaluación .................................................................................................. 100 Tutores ............................................................................... 101

Material elaborado por Prof. Néstor Berasategui

Institución Cervantes


2003 – AML  27/05/2009 19:05:00 

105

INSTITUCIÓN CERVANTES

Área Informática Base de Datos I – Actividades

Guía de Actividades Actividad I – Unidad 1 1. Elabore un resumen de lo que entiende por Base de Datos. 2. Realice un análisis de los sistemas de almacenamiento tradicionales frente a las bases de datos indicando las ventajas y desventajas de ambos. 3. Enumere las principales funciones realizadas por el DBMS. 4. La gerencia de la empresa Alas del Sur S.A., ha detectado falencias en la información que está manejando la empresa. Ante esta situación, se lo ha contratado para realizar la tarea de construcción y diseño de la base de datos necesaria para resolver los problemas planteados. Para lograr este objetivo, usted deberá crear un bosquejo de las etapas que deberá emprender para lograr tal fin y presentarle el mismo al gerente para hacerle comprender los pasos que usted deberá seguir para poder construir la base de datos. 5. Realice un cuadro comparativo entre las distintas etapas del diseño de una base de datos.

Actividad II – Unidad 2 1. Cite al menos cinco ejemplos de cada uno de los mecanismos de abstracción. 2. Elija un tipo de objeto cualquiera (alumno, computadora, auto) y muestre cómo se puede representar usando cada uno de los mecanismos de abstracción. 3. Reconocer entidades y relaciones, considerando cardinalidades. a) Una factura se envía a un cliente y puede haber muchas facturas enviadas a un mismo cliente. b) Una persona trabaja en un departamento y hay muchas personas trabajando en un departamento. c) Un vehículo es posdo por una persona y una persona puede o no poseer muchos vehículos. d) Los estudiante cursan asignaturas. Cada asignatura puede ser cursada por muchos estudiantes. e) Un operador puede trabajar en muchas máquinas y cada máquina tiene muchos operadores. Cada máquina pertenece a un departamento, pero un departamento puede tener muchas máquinas. 4. La universidad de Salamanca, ha considerado la posibilidad de crear una base de datos para la programación de aulas para los exámenes finales de cada una de las carreras. A usted se le plantean dos soluciones posibles: a) La base de datos podría ser modelada como un conjunto de entidades único: examen, con atributos nombre-curso, numero-seccion, numero-aula y hora. Institución Cervantes

1

INSTITUCIÓN CERVANTES

b) Alternativamente podrían definirse uno o más conjuntos de entidades adicionales, junto con los conjuntos de relaciones para sustituir algunos de los atributos del conjunto de entidades examen, como: i) Curso con atributos nombre, departamento y numero-c. ii) Sección con atributos numero-s, y matrícula, y depende de curso como un conjunto de entidades débiles. iii) Aula con atributos numero-a, capacidad y edificio. Para estas dos alternativas de diseño: c) Qué instrumentos utilizaría para crear la base de datos? d) Justifique su elección de un modelo respecto al otro. Explicar que características de la aplicación influirían en la decisión de incluir o no uno o más de los conjuntos de entidades adicionales.

Actividad III Diseñar el diagrama ER para las siguientes situaciones, completándolos, si considera necesario, con las hipótesis adicionales que se crean razonables. 1. Queremos diseñar una base de datos para almacenar información sobre nuestros Clientes y sus Pedidos. Los artículos comercializados por nuestra organización tienen un código que los identifica unívocamente y una descripción. Algunos son fabricados en factorías propias y otros han de adquirirlos en proveedores externos. Cada cliente dispone de un crédito con un límite, un descuento por compras masivas y un saldo, cuyo importe va variando conforme va pagando los pedidos entregados. Los pedidos se entregan en una dirección de entre varias disponibles para cada cliente. Son las direcciones de entrega del cliente. Además, un pedido puede servirse en varias entregas, por lo que habrá que llevar un control de lo que queda pendiente de entregar en cada momento. Los pedidos se componen en dos partes: una cabecera de pedido y varias líneas de detalle. Se desea llevar, también, un control de las necesidades de fabricación. Para ello, por cada fábrica propia se guarda la cantidad disponible de cada artículo en el almacén de la fábrica y el nivel mínimo de existencias a partir del cual hay riesgo de quedarse sin existencias. 2. El centro de estudiantes de la carrera de Ingeniería de Sistemas junto con la jefatura de carrera, desean realizar una encuesta (de carácter anónima) de intereses a los alumnos de la carrera para la planificación de actividades de la futura semana de la Facultad. Para ello se han definido los siguientes datos básicos necesarios de cada alumno: Año de ingreso a la carrera, edad, sexo (determinado por el encuestador), comuna en que vive, ciudad, si vive con los padres, estado civil, deporte(s) que practica, hobbies, temas de interés. Se le pide al curso de Diseño de Bases de Datos I que determine los archivos a utilizar para el almacenamiento de estos datos que no transgredan las formas normales. ¿Qué tipo de requerimiento de información puede resolver esta encuesta?. 3. Una agencia de colocaciones dedicada a la búsqueda de directivos para empresas desea diseñar una base de datos que incorpore datos de las personas de las que tiene información, así como de los trabajos que oferta. De cada persona se desea poder relacionarla con la ciudad en la que vive y con todas las ciudades en las que estar a 2

INSTITUCIÓN CERVANTES

INSTITUCIÓN CERVANTES

Área Informática Base de Datos I – Actividades

dispuesta a vivir, dándoles un orden de preferencia. Además, cada persona debe estar relacionada con aquellas experiencias (tanto académicas como profesionales) que posee, indicando los años durante los cuales las ha adquirido. Deben incluirse, también, las empresas (tanto las que ofertan trabajo, como aquellas a las que pertenecen o han pertenecido las personas de las que se tiene información) y deberá relacionarse cada persona con su empresa actual y con todas aquellas en las que ha trabajado, indicando, en este caso, la fecha de entrada, salida, motivo de la salida y último puesto ocupado. Cada trabajo ofertado requiere de una o varias experiencias y es para una sola empresa y en una única ciudad. Por último, al comenzar el proceso de selección para un trabajo, se establece una relación entre el trabajo y las personas que optan por él, de forma que en cada selección aparecen varias personas y una persona puede estar implicada en varias selecciones a la vez. 4. El hotel BD tiene 400 habitaciones. Los tipos de habitaciones que tiene son individuales, dobles y suites; algunas habitaciones tienen teléfono, televisión y/o aire acondicionado. El hotel, a menudo, reserva habitaciones con un año de anticipación. El precio de la habitación depende del tipo de huésped y se considera que hay tres categorías de huésped: normal, comercial y gobierno. Cuando un cliente hace una reserva para una fecha determinada, el conserje le pide los siguientes datos: fecha de inicio de la estancia, nombre y dirección, tipo de la habitación deseada, duración de la estancia, tarifa a la que se puede acoger. Si se confirma la reserva, se abre una factura donde se anotan todos los servicios que el huésped utiliza durante su estancia y que tendrá que abonar junto con su habitación. Cada servicio tiene una única tarifa y queda claramente consignado en la factura. El hotel quiere instalar un sistema que maneje las reservas de las habitaciones y que contemple las siguientes facilidades:
Control del inventario de las habitaciones.

El hotel debe conocer en cada momento qué habitaciones están reservadas y cuáles están disponibles.
Mantenimiento y control de facturas. Se debe poder controlar todos los gastos originados por el cliente y facturárselos debidamente.
Control de los clientes habituales. El hotel desea mejorar el trato dado a ese tipo de clientes. 5. Se desea crear una base de datos para almacenar los menús de un hospital.
Cada menú tiene un único nombre y fue creado en una fecha determinada por









un dietista. Cada menú puede estar formado por cualquier número de platos, cada uno de ellos con un único nombre. El orden de consumo del plato varía para cada menú. Se debe mantener una descripción del plato para cada plato almacenado. Cada plato está hecho con cualquier cantidad de cualquier número de alimentos (por ejemplo, el plato PLATO1 está hecho con 10 gr. de ternera, 20 gr. de papas y 5 gr. de tomates). Cada alimento está perfectamente identificado y descrito en la base de datos. Para poder obtener el valor nutricional de cada menú, los valores nutrientes se asocian con cada alimento como sigue: Cada nutriente se identifica con una clave, almacenándose la descripción del nutriente y la unidad de medida.

Institución Cervantes

3

INSTITUCIÓN CERVANTES


Se conoce el contenido de nutriente en una cantidad estándar de alimento, para

cada nutriente en cada alimento (por ejemplo, 100 UI de Vitamina A en un litro de leche).
A cada paciente del hospital se le asigna un menú cada día de su estancia en el mismo. Sólo se asigna un menú a cada paciente por día, pero un paciente puede tomar diferentes menús en diferentes días. Cada paciente está identificado y se guarda cierta información sobre él.

6. Modificar el esquema obtenido en el apartado anterior para: a) permitir que los platos puedan servirse directamente al paciente, llevando

cuenta del número de veces que un paciente toma un determinado plato y el día en que lo hace. b) permitir que los alimentos puedan servirse directamente al paciente, llevando cuenta del número de cantidades estándar que toma del alimento y el día en que lo hace.

Actividad IV – Unidad 3 1. Realice un cuadro comparativo entre los distintos tipos de estructura de archivos planos. 2. Realice un cuadro comparativo entre los distintos tipos de bases de datos. 3. Realice un cuadro comparativo entre los distintos sistemas distribuidos de bases de datos que conozca. 4. Cree un esquema que me permita seguir un índice utilizando el método de árbol B. Describa cada una de las etapas. 5. Realice un esquema comparativo de cada uno de los niveles de la arquitectura de una base de datos.

Actividad V – Unidad 4 Realizar un diagrama ER indicando cuáles son las claves y su tipo, las características de cada una de las relaciones (uno a uno, uno a muchos, muchos a muchos) y, en caso de existir integridad referencial, describir y justificar cada una de ellas para las siguientes situaciones: 1. El gerente de personal de la empresa en la cual nos desempeñamos como ABD (DBA), nos indica que la base de datos de personal de la compañía debe contener información sobre las divisiones, departamentos y empleados de la misma. Cada empleado trabaja en un departamento; cada departamento forma parte de una división. Debemos proponer algunos datos de muestra que esbocen algunas posibles estructuras de almacenamiento para ellos. En donde sea posible, debemos explicarle, las ventajas relativas de cada una de esas estructuras, es decir, analizar la forma como se manejarían, en cada caso, opciones representativas de recuperación y actualización de datos. 4

INSTITUCIÓN CERVANTES

INSTITUCIÓN CERVANTES

Área Informática Base de Datos I – Actividades

2. Al realizar el relevamiento de la empresa ALA2, se ha obtenido la siguiente descripción del problema: La compañía trata con pasajeros que son registrados en diferentes vuelos en una clase y en un asiento determinado. De los pasajeros interesa el nombre, la dirección y el numero de teléfono. De los vuelos es necesario almacenar el numero de vuelo, la fecha, el origen, el destino, la hora de salida y la hora de llegada. La compañía dispone de un conjunto de empleados de los cuales almacena información referente al numero de emplead, el nombre, dirección y el salario que recibe cada uno. Una parte de estos empleados son pilotos y solo ellos pueden piloteas aparatos. La compañía dispone también de aviones de diferentes tipos. Para cada tipo de aparato necesita registrar el constructor, el numero de modelo, el numero de asientos que posee y la velocidad de crucero que alcanza. A los aviones se les asigna un número de serie e interesa conocer el número de horas de vuelo que han cumplido cada uno. Cada vuelo tiene asignado un avión concreto y varios empleados. 3. La AFA, necesita contar con la información acerca de los jugadores de fútbol, los equipos para los que han jugado, su promedio de goles por temporada y las posiciones en que han jugado durante su carrera deportiva. Las entidades son:
Jugadores con atributos nombre, lugar de nacimiento y fecha de nacimiento y

equipo.
Posiciones con atributos nombre, numero
Promedio de goles, conjunto de promedio de goles. Esta entidad tiene un único atributo numérico.
Equipos, nombre, técnico, promedio para el descenso.

Con la información suministrada, debemos construir un esquema tal que permita resolver el problema y nos brinde la posibilidad de crear la base de datos. Proponga e identifique relaciones, atributos, identificadores, etc. Todo lo que considere necesario. 4. El dueño del almacén Don Chicho, nos ha solicitado que le hagamos un sistema que sea capas de brindarle información acerca de los datos según el siguiente informe surgido de un relevamiento previo:
Cada empleado está representado. Los datos a considerar de un empleado son

su número de empleado, nombre, dirección y el departamento para el que trabaja.
Cada departamento está representado. Los datos a considerar de los departamentos son su nombre, empleados, director, y productos que tiene asignados.
Cada producto con que se trabaja está representado. Los datos a considerar de los productos son nombre, fabricante, precio, número de modelo asignado por el fabricante y el número de producto interno asignado por el almacén.
Cada fabricante se representa. Los datos son su nombre, dirección, productos que suministra al almacén y su precio.

t23 Institución Cervantes

5

INSTITUCIÓN CERVANTES

5. La biblioteca de la Institución, necesita información acerca de los libros departamentales y nos han solicitado que a partir de los requerimientos planteados construyamos la base de datos:
Cada departamento puede adquirir anualmente y a un cierto precio cierto número de ejemplares de un libro que pasan a ser de su propiedad y a los que inmediatamente se les asigna un numero de registro general de biblioteca. De cada libro interesa su titulo, autor, materia, editorial y año de publicación, así como su número de código (ISBN) que lo identifica unívocamente.
Los ejemplares pueden ser tomados en calidad de préstamo (con fecha limite de devolución) por los profesores del centro pertenezcan o no al centro 6. Realizar las transformaciones de esquema conceptual a esquema lógico de todas las actividades planteadas hasta este punto donde usted crea que se pueden realizar.

Actividad VI – Unidad 5 Siendo usted el encargado del centro de cómputos del Hospital y responsable del mantenimiento y administración de las bases de datos del mismo, deberá diseñar una base de datos que contenga información referente a la planificación de las operaciones de los cirujanos del hospital.
El hospital comprende un cierto número de servicios (con un código y un nombre) a









los que están adscritos los cirujanos. Cada servicio dispone de habitaciones para la hospitalización de los enfermos. Estas habitaciones, que tienen un número único sobre el conjunto del hospital, pueden contener de uno a cuatro camas, según el caso. Cada cama está numerada de uno a cuatro en la habitación. Los informes concernientes a la hospitalización de los enfermos (número de enfermo, nombre, fecha de nacimiento, fecha de hospitalización) se archivan durante su estancia. Cada cirujano tiene una especialidad, pero varios de ellos pueden tener la misma. Las especialidades están codificadas y tiene un nombre. Puede suceder que un enfermo deba sufrir varias operaciones durante una misma hospitalización, en diferentes fechas y realizadas por cirujanos que pueden pertenecer a un servicio diferente a aquel en el que están hospitalizados.

Con la información que se ofrece, realizar las tareas necesarias para la construcción de la base de datos. Verifique si las relaciones obtenidas se encuentran en la forma normal correcta. Justifique su respuesta explicando el proceso utilizado.

Actividad VII Dada la siguiente descripción de un sistema de información (Aeropuerto Internacional), obtenga el esquema conceptual del mismo utilizando el modelo E/R y su correspondiente transformación a esquema lógico. Realice un control de la base de datos 6

INSTITUCIÓN CERVANTES

Área Informática Base de Datos I – Actividades

INSTITUCIÓN CERVANTES

obtenida aplicando los mecanismos de normalización y justifique el porque considera que las relaciones están en la forma normal óptima. a) Control de cada avión registrado en el aeropuerto (Nº Registro, matrícula,

antigüedad, fecha registro,...). Cada avión es de un tipo determinado, recogiéndose de cada tipo su modelo, capacidad y peso. b) Control de los hangares (Código hangar, capacidad y localización) donde se

estacionan aviones. Cada avión tiene designado un hangar. c) Control de los propietarios de aviones (código, nombre, dirección, teléfono).

Relación N:M. Se registrará la fecha de compra de cada avión. d) Control de pilotos (Num-licencia). Están cualificados para pilotar determinados

tipos de aviones (no todos los pilotos pueden pilotear todos los aviones, solamente aviones de algún tipo) e) Control de empleados de mantenimiento (salario). Cualificados para trabajar en

determinados tipos de aviones (ídem que los pilotos). Mantienen aviones específicos (para cada acción de mantenimiento se registrará: fecha, horas, código de trabajo). f) Se registrará el Número de Documento, nombre, dirección, teléfono de todas las

personas (mecánicos, pilotos) de la BD.

Actividad VIII 1. La figura siguiente es una representación jerárquica (no normalizada) del conjunto de datos que se va a grabar en una base de datos de personal de una empresa. Departamento

Empleado Trabajo

Proyecto

Oficina Teléfono

Historia de Salarios La figura se debe leer así:
La empresa tiene un conjunto de departamentos.
Cada departamento tiene un conjunto de empleados, un conjunto de proyectos, y un conjunto de oficinas.
Cada empleado tiene una historia de empleos (conjunto de trabajos que ha tenido el empleado). Para cada empleo, también el empleado tiene una historia de salario (conjunto de salarios recibidos mientras tenía ese empleo).
Cada oficina tiene un conjunto de teléfonos. Institución Cervantes

7

INSTITUCIÓN CERVANTES

La base de datos debe contener la siguiente información.
Para cada departamento: número de departamento (único), presupuesto, y el número de empleado del gerente del departamento (único).
Para cada empleado: número de empleado (único), número de proyecto actual, número de oficina y número telefónico; además, el título de cada trabajo que ha tenido el empleado, junto con la fecha y el salario para cada salario distinto recibido en ese trabajo.
Para cada proyecto: número de proyecto (único) y presupuesto.
Para cada oficina: número de oficina (único), área en metros cuadrados, y números de todos los teléfonos (único). Diseñar un conjunto apropiado de relaciones normalizadas para representar esta información. Indicar cualquier suposición hecha acerca de las dependencias existentes.

Actividad IX 1. Una base de datos empleada en un sistema de recepción de pedidos debe contener información acerca de clientes, artículos y órdenes. Debe incluirse la siguiente información.
Para cada cliente: Número de cliente (único) Direcciones de envío (varias por cliente) Saldo Límite de crédito Descuento
Para cada pedido: Información de cabecera: número de cliente, dirección de envío, fecha del pedido. Renglones del detalle (varios por pedido): número de artículo, cantidad ordenada.
Para cada artículo: Número de artículo (único) Plantas manufactureras Cantidad existente en cada planta Punto de reorden para cada planta Descripción del artículo Por razones de procesamiento interno, se asocia un valor de “cantidad pendiente” a cada renglón de detalle de cada pedido. Este valor es, en un principio, igual a la cantidad ordenada del artículo y se reduce (de manera progresiva) a cero conforme se hacen las entregas parciales. Diseñar una base de datos para esta información. Indicar cualquier suposición hecha acerca de las dependencias. 8

INSTITUCIÓN CERVANTES

INSTITUCIÓN CERVANTES

Área Informática Base de Datos I – Actividades

2. Supongamos que en el ejercicio anterior, sólo un número muy reducido de clientes, digamos el uno por ciento o menos, tienen más de una dirección de envío (esto concuerda con las situaciones de la vida real, en las que muchas veces unas cuantas excepciones -–casi siempre bastante importantes- no se ajustan a cierto patrón en general.) ¿Puede detectar alguna deficiencia en la solución al ejercicio anterior? ¿Puede elaborar alguna mejora?

Actividad X Dado el siguiente esquema realizar la normalización teniendo en cuenta las pautas establecidas más abajo:

Planteo: Se ha presentado para el Ministerio de Educación de la Provincia, la posibilidad de crear una base de datos que le permita el control de los establecimientos educativos de la provincia, los cuales presentan al inicio del ciclo lectivo los planes de estudio y los alumnos que asistirán a cada curso. Se le encomendó al departamento Desarrollo de Sistemas la tarea de crear el esquema correspondiente a la base de datos a implementar. En una primera instancia, se ha conseguido el esquema que se muestra a continuación: Pautas
Una escuela puede tener más de un plan de estudio aprobado.
Un plan de estudio consta de varias materias por división o año.
Un mismo plan de estudio puede dictarse en varios turnos.
Un alumno puede o no cursar materias.
Un cursante de materias puede asistir a más de una materia.
Se desea almacenar todas las notas de las materias (parciales, finales, etc) por cursante. Institución Cervantes

9

INSTITUCIÓN CERVANTES


Se desea mantener el legajo del alumno con la condición frente a la escuela y el

registro de todas las solicitudes de documentación.
Se desea controlar, también las fechas de inscripción a los exámenes finales.

Actividad XI A pedido de la empresa constructora BRONSON, se realizó un relevamiento de la información que necesita para el seguimiento de Obras. Cada obra está diferenciada por un código de obra único. Tiene una fecha de inicio de obra, un costo y un cliente que es el que encargó la obra. Cada cliente puede encargar más de una obra. Cada obra es dirigida por un arquitecto quien es el encargado de ejecutar el proyecto. A su vez, existe un inspector de obra quien es el responsable de controlar el seguimiento de la misma. Las obras están determinadas o agrupadas por tareas que deben ser realizadas en un tiempo establecido (fecha de inicio y de finalización de la tarea). Cada tarea tiene un responsable o encargado de ejecutarla (por ejemplo: pisos tiene como responsable a Pedro). A raíz de este relevamiento, se obtuvo la siguiente relación no normalizada: CODIGO DE OBRA CODIGO ARQUITECTO DE LA OBRA NOMBRE DEL ARQUITECTO MATRICULA ARQUITECTO COSTO DE LA OBRA FECHA INICIO DE OBRA SUPERFICIE DE OBRA CLIENTE NOMBRE DEL CLIENTE DIRECCION DEL CLIENTE TELEFONO DEL CLIENTE INSPECTOR NOMBRE DEL INSPECTOR CODIGO DE TAREA DETALLE TAREA TIEMPO DE LA TAREA FECHA INICIO DE LA TAREA FECHA FINALIZACION DE LA TAREA CODIGO ENCARGADO DE LA TAREA NOMBRE DEL ENCARGADO Construir la base de datos normalizada utilizando las herramientas que considere necesarias.

10

INSTITUCIÓN CERVANTES

Área Informática Base de Datos I – Actividades

INSTITUCIÓN CERVANTES

Actividad XII La librería NN, nos ha entregado un listado del resumen de ventas por vendedores que trabajan para la misma. A pedido de la misma, es nuestra tarea construir la base de datos a partir de estos datos para la administración de las ventas de la librería.

NFAC

NOMVEN

NOMCLI LOCALIDAD

1 1 1

PEDRO PEDRO PEDRO

Luis Luis Luis

3 3

PEDRO PEDRO

Ana Ana

NFAC

NOMVEN

2 2

JUAN JUAN

CP

NART

ARTICULO

CANT

PU

Málaga Málaga Málaga

5000 5000 5000

A1 A3 A9

Papel Cinta Disco

100 50 25

5 500 200

FECHA FACTURA 3/5/02 3/5/02 3/5/02

Cordoba Cordoba

5500 5500

A4 A3

Ojalillos Cinta

100 50

5 500

10/5/02 10/5/02

CP

NART

ARTICULO

CANT

PU

FECHA FACTURA

5000 5000

A1 A5

Papel Grapas

100 30

5 20

13/5/02 13/5/02

NOMCLI LOCALIDAD Luis Luis

Málaga Málaga

Actividad XIII Investigar y documentar: Para cada uno de los siguientes problemas deberá crear un modelo de datos conceptual consistente de conjunto de entidades, interrelaciones, atributos y otros, que puedan usarse para responder preguntas similares a las preguntas dadas. Indique las cardinalidades. Este modelo es para un entorno universitario
¿Cuántos alumnos del primer semestre del Instituto han sido asignado en cada uno







de los grupos formados para ellos? ¿Cómo se llaman los grupos? ¿Cómo se llaman los alumnos? ¿Quién es su docente de computación? ¿Quién es su docente de informática? ¿Cuántos de estos estudiantes son repetidores? ¿Cuántas materias cursa cada alumno?

Institución Cervantes

11

INSTITUCIÓN CERVANTES

Actividad XIV Investigar y documentar: Exponga un conjunto de argumentos para convencer a un directivo de una empresa, no técnico en informática, de la conveniencia de que su empresa, que utiliza desde hace años un sistema clásico orientado a archivos, cambie su enfoque hacia una base de datos (haga la hipótesis que desee sobre el tipo de aplicaciones de la empresa) ¿Cuáles pueden ser las causas de que fracase un poyecto de creación de una base de datos? Entreviste a un DBA de una empresa local, determine si utiliza un sistema de diccionario de datos. ¿Está integrado con el DBMS? De ser así ¿cuáles son sus ventajas y desventajas? De lo contrario, por qué la empresa eligió ese tipo de diccionario de datos. Entreviste a una persona que use una aplicación de base de datos. ¿Cuáles funciones del negocio son atendidas? ¿Qué información se produce? ¿Qué objetos están involucrados? ¿Es esta una aplicación personal, de grupos de trabajo o de una organización?

Tutores

t1


Sugerencia: Las limitantes “cada empleado trabaja en un departamento” y “cada departamento forma parte de una división” son ejemplos de interrelaciones de uno a muchos”.

t2


Nótese que alguna información puede ser representada por atributos y otra por relaciones.

Material elaborado por Prof. Néstor Berasategui

12


2003 – AML  27/05/2009 19:06:00  INSTITUCIÓN CERVANTES