Bases De Datos I-97.doc

1

BASES DE DATOS I UNIDAD I. INTRODUCCION A LOS CONCEPTOS DE BASE DE DATOS DEFINICION DE BASES DE DATOS Una base de datos es un conjunto autodescriptivo de registros integrados. Una base de datos es autodescriptiva: porque además de los datos fuente del usuario contiene también una descripción de su propia estructura. Tal descripción es conocida como diccionario de datos (o directorio de datos o metadatos). La autodescripción de una base de datos es importante porque promueve la independencia entre el programa y los datos, ya que hace posible determinar la estructura y el contenido de la base de datos examinando la misma. Si cambia la estructura de los datos en la base de datos (por ejemplo agregar un campo), solo se introduce el cambio al diccionario de datos. JERARQUIA DE LOS DATOS La jerarquía normal de los datos es: los bits conforman bytes o caracteres; los caracteres constituyen campos; los campos integran registros y los registros componen archivos. Una base de datos incluye archivos de datos del usuario y más. Como se menciona una base de datos contiene una descripción de sí misma en los metadatos. Una base de datos incluye índices que se usan para representar las relaciones entre los datos y para mejorar el desempeño de la base de datos. La base de datos contiene a veces la información de las aplicaciones que las utilizan. La ultima categoría de los datos se denomina metadatos de aplicación. Bits Bytes o caracteres Campos Registros Archivos. Una base de datos contiene los siguientes tipos de datos:

a) b) c) d)

Archivos de datos del usuario. Metadatos Índices Metadatos de aplicación

Archivos + Metadatos + Índices + Metadatos de aplicación

Base de Datos

1.2. OBJETIVOS DE LOS SISTEMAS DE BASES DE DATOS De los sistemas tradicionales de Archivos a las Bases de Datos. Los sistemas informáticos tradicionales han sido llamados sistemas orientados hacia proceso, debido a que en ellos se pone énfasis en los tratamientos que reciben los datos, los cuales se almacenan en archivos diseñados para una determinada aplicación. Las aplicaciones se analizan e implantan con entera independencia unas de otras, y los datos no se suelen transferir entre ellas, sino que se duplican siempre que los trabajos correspondientes los necesitan. Por lo cual, además de ocupación inútil de memoria secundaria, un aumento de los tiempos de proceso, al repetirse los mismos controles y operaciones en los distintos archivos. Pero más grave son las inconsistencias que a

2 menudo se presentan en estos sistemas, debido a que la actualización de los mismos datos, cuando se encuentran en mas de un archivo, no se suele realizar de forma simultanea en todos los archivos. Por otra parte, la dependencia de los datos respecto al soporte físico y a los programas de lugar a una falta de flexibilidad y de adaptabilidad frente a los cambios que repercute muy negativamente en el rendimiento de conjunto del sistema informático. De esto, se puede deducir claramente la necesidad de una gestión más racional del conjunto de datos, surgiendo así un nuevo enfoque que se apoya sobre una base de datos en la cual los datos son recogidos y almacenados una sola vez, con independencia de los tratamientos. Por lo tanto, se ve la solución de los problemas asociados al tratamiento de los datos en los sistemas tradicionales lleva a un cambio en el enfoque del sistema de información, en el cual los datos se organizan y mantienen en un conjunto estructurado que no esta diseñado para una aplicación concreta, sino que, por el contrario, tiende a satisfacer las necesidades de información de toda la organización. Estos sistemas orientados hacia los datos van sustituyendo a los sistemas orientados al proceso, que por poca fiabilidad, falta de adecuación a la realidad y mal asegurada confidencialidad han ido perdiendo la confianza de los usuarios.

a)

Ventajas de las Bases de Datos Frente a los Archivos Clásicos.

Las bases de datos, surgidas como respuesta al nuevo planteamiento de los sistemas orientados hacia los datos, para mejorar la calidad de las prestaciones de los sistemas informáticos y aumentar su rendimiento, presentan una multitud de ventajas frente a los sistemas clásicos de archivos. Las ventajas son:

b)

Independencia de los datos respecto a los tratamientos y viceversa.

La mutua independencia de los datos y tratamiento lleva a que un cambio de estos últimos no imponga un nuevo diseño lógico y/o físico de la base de datos. Por otra parte, la inclusión de nuevas informaciones, desaparición de otras, cambios en la estructura física o en los cambios de acceso, no deben obligar a alterar los programas. Esta independencia de los tratamientos frente a la estructura de la base de datos, supone una considerable ventaja, al evitar esfuerzo que origina la reprogramación de las aplicaciones cuando se producen cambios en los datos. La flexibilidad que proporciona la independencia de los datos y programas es muy importante para conseguir sin excesivos costos la continua adaptación del sistema de información a la evolución de las organizaciones.

c)

Coherencia de los Resultados

Debido a que 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 comparable. Además, al no existir la redundancia en los datos, desaparece el problema que se presentaba en el enfoque clásico, de que el cambio de un dato obligaba a actualizar una serie de archivos. De esta forma se elimina también el inconveniente de las divergencias en los resultados debidas a actualizaciones no simultáneas en todos los archivos.

d)

Mejor disponibilidad de los datos para el conjunto de los usuarios.

Cuando se aplica la metodología de base de datos, cada usuario ya no es propietario de los datos, puesto que estos 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 a la información existente, que todos los datos que se encuentran en la base de datos se deben relacionar en un catalogo o diccionario, que puede ser ampliamente difundido y accedido por medios informáticos.

3

e) Mayor Valor Informativo Puesto que la base de datos en un sistema reflejo del mundo real, donde los distintos elementos están interrelacionados, el valor informativo de su conjunto es superior a la suma del valor informativo de los elementos individuales que los constituyen. f)

Mejor y más normalizada documentación de la información, la cual esta integrada con los

datos. En el enfoque clásico los datos se encuentran separados de su contenido semántico, los primeros se almacenan en los archivos y su descripción se hace mediante un lenguaje de programación. La documentación de los datos, realizada por el analista o programador, es en general insuficiente y a veces incluso inexistente.

g)

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

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

h)

Reducción del espacio de almacenamiento

La desaparición de las redundancias, así como la aplicación de técnicas de comparación, lleva en los sistemas de base de datos a una menor ocupación de almacenamiento secundario. Mantener información de la organización en un sistema de procesamiento de archivos tiene una serie de inconvenientes. Los propósitos de los sistemas de bases de datos son eliminar los siguientes inconvenientes:  Redundancia e inconsistencia de datos.- Debido a que los archivos de aplicación son creados por diferentes programadores en un largo periodo de tiempo, los diversos archivos tienen probablemente diferentes formatos y los programas pueden estar escritos en diferentes lenguajes. Mas aun la información puede estar duplicada en diferentes archivos.



Dificultad en el acceso a los datos.- Supóngase que uno de los empleados de un banco necesita averiguar los nombres de todos los clientes que viven en el distrito postal 28733 de la ciudad. El empleado pide al departamento del procesamiento de datos que genere dicha lista. Debido a que esta petición no fue prevista cuando el sistema original fue diseñado, no hay un programa de aplicación a mano para satisfacerla. Hay, sin embargo, un programa de aplicación que genera la lista de todos los clientes. El empleado del banco tiene 2 opciones: bien obtener la lista de todos los clientes y obtener la información que necesita manualmente, o bien pedir al departamento de procesamiento de datos que haga que un programador de sistemas escriba el programa de aplicación necesario.



Aislamiento de datos.- Debido a que los datos están dispersos en varios archivos, y los archivos pueden estar en diferentes formatos, es difícil escribir nuevos programas de aplicación para recuperar los datos apropiados.



Problemas de integridad.- Los valores de los datos almacenados en la base de datos deben satisfacer ciertos tipos de ligaduras de consistencia. Por ejemplo, el saldo de una cuenta bancario no debe ser menor de cierta cantidad. Los desarrolladores hacen cumplir esas ligaduras en el sistema añadiendo el código apropiado en los diversos programas de aplicación. Sin embargo, cuando añaden nuevas ligaduras, es difícil cambiar los programas para hacer que se cumplan. El problema es complicado cuando las ligaduras implican diferentes elementos de datos de diferentes archivos.



Problemas de Atomicidad.- Un sistema de una computadora, como cualquier otro dispositivo mecánico o eléctrico, esta sujeto a fallo. En muchas aplicaciones es crucial asegurar que una vez que un fallo ha ocurrido y se ha detectado, los datos se restauran al estado de consistencia que existía antes del fallo.

4



Anomalías en el acceso concurrente.- Conforme se han ido mejorando el conjunto de ejecución de los sistemas y ha sido posible una respuesta en tiempo más rápida, muchos sistemas han ido permitiendo a múltiples usuarios actualizar los datos simultáneamente. En tales sistemas un entorno de interacción de actualizaciones concurrentes puede dar lugar a datos inconsistentes.  Problemas de seguridad.- No todos los usuarios de un sistema de base de datos deberían poder acceder a todos los datos. Por ejemplo en un sistema bancario, el personal de nomina a necesita ver solo esa parte de la base de datos que tiene información acerca de varios empleados del banco. No necesitan acceder a la información acerca de las cuentas de los clientes.

1.3 . ABSTRACCION DE LA INFORMACION Para que un sistema sea útil, debe recuperar los datos eficientemente. Esto ha conducido al diseño de estructura de datos complejas para la representación de los datos en la base de datos. Como muchos usuarios de base de datos no están familiarizados con computadoras, los desarrolladores esconden la complejidad a los usuarios a través de varios niveles de abstracción para simplificar la interacción de los usuarios con el sistema: Nivel Físico.- El nivel mas bajo de abstracción describe como se almacenan realmente los datos. El nivel físico se describen en detalle las estructuras de datos complejas de bajo nivel. Nivel Lógico.- El siguiente nivel mas alto de abstracción describe que datos se almacenan en la base de datos y que relaciones existen entre esos datos. La base de datos completa se describe así en términos de numero pequeño de estructuras relativamente simples. Aunque la implementación de estructuras simples en el nivel lógico puede involucrar estructuras complejas del nivel físico, los usuarios del nivel lógico no necesitan preocuparse de esta complejidad. Los administradores de base de datos, que deben decidir la información que se mantiene en la base de datos, usan el nivel lógico de abstracción. Nivel de Vistas.- El nivel mas alto de abstracción describe solo parte de la base de datos completa. A pesar del uso de estructuras más simples en el nivel lógico, queda algo de complejidad, debido al gran tamaño de la base de datos. A muchos usuarios del sistema de base de datos nos les preocupará toda esa información. En su lugar solo necesitan acceder solo una parte de la base de datos. Para que su interacción con el sistema se simplifique, se define la abstracción del nivel de vistas. Dicho sistema puede proporcionar muchas vistas para la misma base de datos. Niveles de Abstracción

Vista 1

Vista 2

...

Vista n

Nivel Lógico

Nivel Físico

1.4 MODELOS DE DATOS La parte esencial de la estructura de base de datos es el modelo de datos. Una colección de herramientas conceptuales para describir los datos, las relaciones de datos, la semántica de los datos y las ligaduras de consistencia.

5

El modelado de datos es el proceso que implica crear una representación de la visión que tienen los usuarios de los datos. Es la tarea más importante en el desarrollo de eficaces aplicaciones de base de datos. Si el modelo de datos representa en forma incorrecta la visión que poseen los usuarios de los datos, encontraran las aplicaciones difíciles de usar, incompletas y por supuesto frustrantes. Los diferentes modelos de datos que se han propuesto se clasifican tres grupos diferentes: modelos lógicos basados en objetos, modelos lógicos basados en registros y modelos físicos. MODELOS LOGICOS BASADOS EN OBJETOS Los modelos lógicos basados en objetos se usan para describir datos en los niveles lógico y de vistas. Se caracterizan por el hecho de que proporcionan capacidades estructurales muy flexibles y permiten que las ligaduras de datos sean especificadas explícitamente. Varios de los mas ampliamente conocidos son:

a) b) c) d)

Modelo Entidad-Relación. Modelo Orientado a Objetos. Modelo de datos semántico Modelo de datos funcional.

MODELOS LOGICOS BASADOS EN REGISTROS Estos modelos se usan para describir datos en los niveles lógico y de vistas. En contraste con los modelos de datos basados en objetos, se usan tanto para especificar la estructura lógica completa de la base de datos como para proporcionar una descripción de alto nivel de la implementación. Los modelos basados en registros se llaman así debido a que la base de datos se estructura en registros de formato fijo de diferentes tipos. En cada tipo de registro se define un numero fijo de campos o atributos, y cada campo tiene normalmente una longitud física. Los tres modelos basados en registros mas ampliamente conocidos son:

a) Modelo Relacional b) Modelo de Red c) Modelo Jerárquico Diferencia entre los modelos El modelo relacional se diferencia de los modelos de redes y jerárquico en que no usa punteros o enlaces. En su lugar, el modelo relacional relaciona registros mediante los valores que ellos contienen. Esta liberación del uso de punteros permite que se defina mediante un fundamento matemático formal. MODELO DE DATOS FISICO Este modelo se usa para describir datos en un nivel mas bajo. En contraste con el modelo de datos lógico, hay pocos modelos de datos físicos en uso. Dos de los mas conocidos son el modelo de unificación y el modelo de memoria por marcos.

1.5 INSTANCIA Y ESQUEMAS Las bases de datos van combinando a lo largo del tiempo conforme la información se inserta y borra. La colección de información almacenada en la base de datos en un momento particular se llama una instancia de la base de datos. El diseño completo de la base de datos se llama esquema de la base de datos. Los esquemas son raramente modificados. Un esquema de base de datos corresponde a una definición de tipo en un lenguaje de programación. Una variable de un tipo dado tiene un valor particular en un instante de tiempo. Así el valor de una variable en lenguajes de programación corresponde a una instancia de un esquema de la base de datos.

6 Los sistemas de bases de datos tienen varios esquemas divididos, de acuerdo al nivel de abstracción. En el nivel mas bajo esta el esquema físico; en el nivel intermedio esta el esquema lógico, y el nivel más alto es el subesquema.

1.6 INDEPENDENCIA DE LOS DATOS La capacidad para modificar una definición de esquema en un nivel sin que afecte a una definición de esquema en el siguiente nivel mas alto se llama independencia de datos. Hay dos niveles de independencia de datos: 1. Independencia física de datos.- Es la capacidad para modificar el esquema físico sin provocar que los programas de aplicación tengan que rescribirse. Las modificaciones en el nivel físico son ocasionalmente necesarias para mejorar el funcionamiento.

2.

Independencia lógica de datos.- Es la capacidad para modificar el esquema lógico sin causar que los programas de aplicación tengan que rescribirse. Las modificaciones en el nivel lógico son necesarias siempre que la estructura lógica de la base de datos se altere. La independencia de datos lógica es más difícil de proporcionar que la independencia física, ya que los programas de aplicación son frecuentemente dependientes de la estructura lógica de los datos a los que ellos acceden. El concepto de independencia de datos es similar en muchos aspectos al concepto de tipos abstractos de datos en los lenguajes de programación modernos. Ambos esconden los detalles de implementación a los usuarios para permitirles concentrarse en la estructura general, mas que en los detalles de implementación de nivel mas bajo. LENGUAJES DE BASES DE DATOS Un sistema de base de datos proporciona dos tipos de lenguajes diferentes: uno para especificar el esquema de base de datos y el otro para expresar las consultas y actualizaciones de la base de datos. 1.7 LENGUAJE DE DEFINICION DE DATOS Un esquema de base de datos se especifica mediante un conjunto de definiciones expresadas mediante un lenguaje especial llamado lenguaje de definición de datos (LDD). El resultado de la compilación de las estructuras del LDD es un conjunto de tablas que se almacenan en un archivo especial llamado diccionario de datos o directorio de datos. Este archivo se consulta antes de leer o modificar los datos reales del sistema de base de datos. La estructura de almacenamiento y los métodos de acceso usados por el sistema de base de datos se especifican mediante un conjunto de definiciones en un tipo especial de LDD llamado un lenguaje de almacenamiento y definición de datos. El resultado de la compilación de estas definiciones es un conjunto de instrucciones para especificar los detalles de implementación de los esquemas de la base de datos. 1.8 LENGUAJES DE MANIPULACION DE DATOS Por manipulación de datos se quiere decir:

   

La recuperación de información almacenada en la base de datos. La inserción de información nueva en la base de datos. El borrado de información. La modificación de información almacenada en la base de datos. En el nivel físico se deben definir algoritmos que permitan un acceso eficiente a los datos. En los niveles mas altos de abstracción se enfatiza la facilidad de uso. Un Lenguaje de Manipulación de datos (LMD) es un lenguaje que permite a los usuarios acceder a manipular los datos organizados mediante el modelo de datos apropiado. Existen dos tipos de LMD:



LMD Procedimentales.- Requieren que el usuario especifique que datos se necesitan y como obtener esos datos.



LMD NO Procedimentales.- Requieren que el usuario especifique qué datos se necesitan, sin especificar como obtener esos datos.

7 Los LMD no procedimentales son más fáciles de aprender y usar que los LMD procedimentales. Sin embargo, como el usuario no especifica como conseguir esos datos, estos lenguajes pueden generar código que no sea tan eficiente como el que generan los lenguajes procedimentales. 1.9 MANEJADOR DE BASE DE DATOS Evolución de los Sistemas Manejadores de Base de Datos A principio de la década de los sesentas, el punto más importante fue la introducción por parte de CODASYL (Conference on Data Systems Languages) del compilador COBOL, acompañado por la evolución de unidades de almacenamiento en cinta y la aparición subsecuente de los dispositivos de almacenamiento de acceso directo. Al surgir las necesidades de aplicaciones más complejas se observo la necesidad de agregar al compilador de COBOL paquetes que facilitaran el ordenamiento y clasificación de datos así como la generación de reportes surgiendo también las organizaciones lógicas de alto nivel para los datos y las aplicaciones comenzaron a interrelacionarse entre sí para ponerse a disposición de un mayor numero de usuarios. Como productos comerciales surgieron los sistemas Generalizados para Manejo de Archivos (GFMS), Sistemas Generalizados para la Administración de Base de Datos (GDBMS) y Sistemas de Bases de Datos. Se puede definir el Manejador de Base de Datos (DBMS Data Base Management System) como un conjunto coordinado de programas, procedimientos, lenguajes, que suministra, tanto a los usuarios no informáticos como a los analistas, programadores o al administrador, los medios necesarios para describir, recuperar y manipular los datos almacenados en la base, manteniendo su integridad, confidencialidad y seguridad. Si se tiene en cuenta a los diferentes usuarios de las bases de datos con diferentes necesidades y variables a lo largo del tiempo que son susceptibles de trabajar simultáneamente con subconjuntos de esta colección de datos, se pone de manifiesto que es imprescindible dotar al sistema de la adecuada flexibilidad para que pueda atender las exigencias de todos los usuarios y para que sea capaz de responder a los cambios. Las operaciones típicas que debe realizar un DBMS pueden resumirse en aquellas que afecten la totalidad de los datos o a todos los registros de un determinado tipo y las que tienen lugar sobre registros concretos. Las funciones esenciales de un DBMS son las de descripción, manipulación y utilización.

A)

Función de descripción o definición

Esta función debe permitir al administrador de la base de datos especifican los elementos de datos que la integran, su estructura y las relaciones que existen entre ellos, las reglas de integridad semántica, los controles a afectar antes de autorizar el acceso a la base, así como las características de tipo físico y las vistas lógicas de los usuarios. Esta función, realizada por el lenguaje de descripción o definición de datos (LDD) propio de cada DBMS debe suministrar los medios para definir las tres estructuras de datos(externa, lógica global e interna), especificando las características de los datos a cada uno de estos niveles. A nivel interno, se ha de indicar el espacio (volúmenes, cilindros y pistas) reservado para la base, la longitud de los campos o elementos de datos, su modo de representación (binario, decimal, alfanumérico, punto fijo o flotante). Además, se debe poder definir caminos de acceso, como punteros, índices, etc. Para las estructuras externa y lógica global, la función de descripción ha de proporcionar los instrumentos para la definición de las entidades y su identificación, atributos de las mismas, interrelaciones entre ellas, autorizaciones de acceso, restricciones de integridad.

B)

Función de Manipulación.

La función de manipulación permite a los usuarios de la base de datos, informáticos, o n o, buscar, añadir, suprimir o modificar los datos de la misma, siempre de acuerdo con las especificaciones y las normas de seguridad dictadas por el administrador. La función de manipulación se llevara a cabo por medio de un lenguaje de manipulación de datos (LMD) que facilita los instrumentos necesarios para la realización de estas tareas.

8

C)

Función de Utilización

La función de utilización reúne todas las interfaces que necesitan los diferentes usuarios para comunicarse con la base y proporciona un conjunto de procedimientos para el administrador. Las exigencias respecto a la forma de utilizar la base de datos son muy diferentes, según los tipos de procesos y según los usuarios, siendo preciso que la función de utilización responda a todas ellas. En la mayoría de los Sistemas Manejadores de Base de Datos existen funciones de servicio, como cambiar la capacidad de los ficheros, obtener estadísticas de utilización, cargar archivos y principalmente las relacionadas con la seguridad física y de protección frente a acceso no autorizados. Objetivos de los Sistemas Manejadores de Bases de Datos.



Control de concurrencia Múltiples usuarios pueden acceder a la misma información al mismo tiempo, sin que con ello se tengan problemas con los datos.



Proteger los datos contra fallas del Sistema Es la capacidad de restaurar la integridad y consistencia después de una falla del sistema.



El Diccionario de Datos Es la capacidad que da el manejador de la base de datos de poder tener la descripción de los datos que están almacenados en la base de datos.



Interfaz de alto nivel con los programadores El manejo de un lenguaje, como lo es SQL.

Un Manejador de Base de Datos debe incluir lo siguiente:

          

Independencia de los programas respecto a los cambios en la estructura de los datos. Programas de utilería para la administración de la base de datos. Mecanismos de seguridad para imponer limites de acceso. Recuperación de caso de fallas. Facilidades para afinación de la base de datos. Un lenguaje de consulta propio Capacidad para proceso de transacciones en Línea. Diccionario de datos. Control de concurrencia. Facilidad de acceso. Protección de los datos.

1.10. ADMINISTRADOR DE LA BASE DE DATOS Una de las principales razones para usar un Sistema de Gestión de Base de Datos es tener un control centralizado tanto de los datos como de los programas que acceden a esos datos. La persona que tiene este control central sobre el sistema se llama Administrador de la base de datos (ABD). Las funciones del ABD son:



Definición del Esquema.- El Administrador de la Base de Datos crea el esquema original de la base de datos escribiendo un conjunto de definiciones que el compilador del Lenguaje de definición de datos (LDD) traduce a un conjunto de tablas que son almacenadas permanentemente en el diccionario de datos.  Estructura de Almacenamiento y Definición del Método de Acceso.- Los Administradores de la Base de Datos crean las estructuras de almacenamiento apropiadas y los métodos de acceso escribiendo un conjunto de definiciones, que son traducidas por el compilador del Lenguaje de Definición y Almacenamiento de datos.



Esquema y Modificación de la Organización Física.Los programadores llevan a cabo las modificaciones sobre el esquema de base de datos o la descripción de la organización de almacenamiento físico escribiendo un conjunto de definiciones que son usadas por el compilador de LDD o por el compilador del

9 lenguaje de definición y almacenamiento de datos para generar las modificaciones en las tablas correspondientes del sistema interno.



Concesión de la Autorización para el acceso a los datos.- La concesión de diferentes tipos de autorización permite al administrador de la base de datos determinar que parte de la base de datos pueden acceder los diferentes usuarios. La información de autorización se mantiene en una estructura del sistema especial que el sistema de la base de datos consulta cuando se intenta el acceso a los datos en el sistema.



Especificación de la Ligaduras de Integridad.- Los valores de los datos almacenados en la base de datos deben satisfacer ciertas ligaduras de integridad. Por ejemplo, quizás él numero de horas que un empleado puede trabajar en una semana no debe exceder de un limite especificado (por ejemplo, 80 horas). Tales ligaduras deben ser especificadas explícitamente por el Administrador de la Base de Datos. Las ligaduras de integridad se mantienen en una estructura del sistema especial que el sistema de base de datos consulta cuando tiene lugar una actualización en el sistema. 1.11 USUARIOS DE BASE DE DATOS Un primer objetivo de un sistema de base de datos es proporcionar un entorno para la recuperación de la información y el almacenamiento de nueva información en la base de datos. Hay cuatro tipos de diferentes de usuarios de un sistema de base de datos, diferenciados por la forma en que ellos esperan interactuar con el sistema.



Programadores de Aplicaciones.- Son profesionales informáticos que interactúan con el sistema a través de llamadas del Lenguaje de Manipulación de Datos(LMD), que están incluidas en un programa escrito en un lenguaje anfitrión (por ejemplo, Cobol, PL/I, Pascal, C ).Estos programas comúnmente se llaman programas de aplicación. Por ejemplo un sistema bancario, incluye programas que generan cheques de nominas, cargan cuentas, abonan cuestas o transfieren fondos entre cuentas. Debido a que la sintaxis de los LMD es habitualmente muy diferente de la sintaxis del lenguaje anfitrión, las llamadas del LMD están normalmente precedidas de un carácter especial para que se puede generar código apropiado. Un preprocesador especial, llamado precompilador del LMD, convierte las instrucciones del LMD en llamadas a procedimientos normales en el lenguaje anfitrión. El programa resultante se compila a continuación mediante el compilador del lenguaje anfitrión, que genera el código objeto apropiado. Hay tipos de lenguajes de programación de programación especiales que combinan estructuras de control de lenguajes tipo Pascal con estructuras de control para la manipulación de objetos de una base de datos (por ejemplo, relaciones). Estos lenguajes, llamados lenguajes de cuarta generación, a menudo incluyen características especiales para facilitar la generación de formularios y la presentación de datos en pantalla. La mayoría de los sistemas de bases de datos comerciales incluyen un lenguaje de cuarta generación.



Usuarios Sofisticados.- Interactúan con el sistema sin programas escritos. En su lugar, ellos forman sus consultas en un lenguaje de consulta de base de datos. Cada una de estas consultas se envía al procesador de consultas, cuya función es transformar instrucciones LMD a instrucciones que el gestor de almacenamiento entienda. Los analistas que envían las consultas para explorar los datos en la base de datos entran en esta categoría.



Usuarios Especializados.- Son usuarios que escriben aplicaciones de bases de datos especializadas que no son adecuadas en el marco de procesamiento de datos tradicional. Entre estas aplicaciones están los sistemas de diseño asistido por computadora, sistemas de bases de conocimientos y expertos, sistema que almacenan los datos con los tipos de datos completos (por ejemplo, datos gráficos y datos de audio).



Usuarios Normales o Finales.- Son usuarios que interactúan con el sistema mediante la invocación de alguno de los programas de aplicación permanentes que se han escrito previamente. 1.12 ESTRUCTURA GENERAL DEL SISTEMA Un sistema de base de datos se divide en módulos que se encargan de cada una de las responsabilidades del sistema completo. Algunas de estas funciones del sistema de base de datos las puede proporcionar el sistema operativo de la computadora.

10 Los componentes funcionales de un sistema de base de datos se puede dividir en componentes de procesamiento de consultas y componentes de gestión de almacenamiento. Los componentes de procesamiento de consultas incluyen:



Compilador del LMD.- Traduce las instrucciones del LMD en lenguaje de consultas a instrucciones a bajo nivel que entiende el motor de evaluación de consultas. Además, el compilador de LMD intenta transformar las peticiones del usuario en otras equivalentes pero más eficientes, encontrando así una buena estrategia para ejecutar la consulta.



Precompilador de LMD incorporado.- Convierte las instrucciones del LMD incorporadas en un programa de aplicación en llamadas a procedimientos normales en el lenguaje anfitrión. El precompilador debe interactuar con el compilador del LMD para generar el código apropiado.



Interprete del LDD.- Interpreta las instrucciones del LDD y las registra en un conjunto de tablas que contiene metadatos.  Motor de Evaluación de Consultas.- Ejecuta las instrucciones a bajo nivel generadas por el compilador del LMD. Los componentes de gestión de almacenamiento proporcionan la interfaz entre los datos de bajo nivel almacenados en la base de datos y los programas de aplicación y envío de consultas al sistema. Dicho gestor incluye:

11

ESTRUCTURA GENERAL DEL SISTEMA

Usuarios normales (cajeros, agentes, etc)

Programadores de aplicaciones

interfaces de aplicaciones

programas de aplicación

consulta

precompilador del LMD incorporado

compilador de LMD

código objeto de los programas de aplicación

Usuarios Sofisticados

Administrador de base de datos

usuarios

esquema de base de datos

intérprete del LDD procesador de consultas

motor de evaluación de consultas

sistena de gestión de base s dedatos

gestor de memoria intermedia

gestor de transacciones

gestor de almacenamiento

gestor de archivos

índices

datos estadísticos almacenamiento en disco

archivos de datos

diccionario de datos



Gestor de autorización e integridad.- Comprueba que se satisfagan las ligaduras de integridad y la autorización de los usuarios para acceder a los datos.



Gestor de transacciones.- Asegura que la base de datos quede en un estado consistente (correcto) a pesar de los fallos del sistema, y que las ejecuciones de transacciones concurrentes ocurran sin conflictos.



Gestor de Archivos.- Gestión la reserva de espacio de almacenamiento de disco y las estructuras de datos usadas para representar la información almacenada en disco.

12 

Gestor de memoria intermedia.- Es responsable de traer los datos del disco de almacenamiento a memoria principal y decidir que datos tratar en la memoria cache.



Archivos de datos.- Almacenan la base de datos en sí.



Diccionario de datos.- Almacena metadatos acerca de la estructura de la base de datos.



Índices.- Proporcionan acceso rápido a elementos de datos que tienen valores particulares.



Datos Estadísticos.- Almacén información estadística sobre los datos en la base de datos. El procesador de consultas usa esta información para seleccionar las formas eficientes para ejecutar una consulta.

UNIDAD II. MODELO ENTIDAD-RELACION El modelo entidad-relación (E-R) esta basado en una percepción del mundo real que consta de un conjunto de objetos básicos llamados entidades y de relaciones entre objetos. Se desarrollo para facilitar el diseño de base de datos permitiendo la especificación de un esquema de la empresa que representa la estructura lógica completa de una base de datos.

2.1.

ENTIDADES Y CONJUNTO DE ENTIDADES

Una entidad es un <> en el mundo real que es distinguible de todos los demás objetos. Por ejemplo, cada persona es una entidad. Una entidad tiene un conjunto de propiedades, y los valores para algún conjunto de propiedades pueden identificar una entidad. Una entidad tiene un conjunto de propiedades, y los valores para algún conjunto de propiedades pueden identificar una entidad de forma unívoca. Por ejemplo del CURP identifica a una persona particular. Un conjunto de entidades es la totalidad de las entidades del mismo tipo que comparten las mismas propiedades o atributos. El conjunto de todas las personas que son clientes de un banco, por ejemplo, se pueden definir como el conjunto de entidades cliente. De la misma manera, el conjunto de entidades préstamo-bancario podría representar el conjunto de todos los prestamos concedidos por un banco particular. Las entidades individuales que constituyen un conjunto se llaman la extensión del conjunto de entidades. Así, todos los clientes de un banco son la extensión del conjunto de entidades cliente. Los conjuntos de entidades no son necesariamente disjuntos. Por ejemplo, es posible definir el conjunto de entidades de todos los empleados de un banco (empleado) y el conjunto de entidades de todos los clientes de banco. Una entidad persona puede ser una entidad empleado, una entidad cliente o ambas. Una entidad se representa mediante un conjunto de atributos. Los atributos describen propiedades que posee cada miembro de un conjunto de entidades. La designación de un atributo para un conjunto de entidades expresa que la base de datos almacena información similar concerniente a cada entidad del conjunto de entidades; sin embargo cada entidad puede tener su propio valor para cada atributo. Posibles atributos del conjunto de entidad cliente son: nombre-cliente,dni, calle-cliente y ciudad-cliente. Posibles atributos del conjunto de entidades préstamo-bancario son: numero-prestamos e importe. Para cada atributo hay un conjunto de atributos permitidos, llamados el dominio o el conjunto de valores, de ese atributo. El dominio del atributo nombre-cliente puede ser el conjunto de todas las cadenas de texto de una cierta longitud. Análogamente, el dominio del atributo numero-préstamo podría ser el conjunto de todos los enteros positivos. Una base de datos incluye así una colección de conjunto de entidades, cada una de las cuales, cada una de las cuales contiene un numero de entidades del mismo tipo. A continuación se muestra una parte de una base de datos de un banco que consta de dos conjuntos de entidades, cliente y préstamo-bancario. Conjuntos de entidades cliente y préstamo-bancario

13 Santos Gómez López Sotoca Pérez Valdivieso Fernández

32112312 19283746 67789901 12345678 55555555 96396396 33557799

Mayor Carretas Mayor Real Carretas Goya Jazmín

Peguerinos Cerceda Peguerinos Cádiz Cerceda Vigo León

P-17 P-23 P-15 P-14 P-93 P-11 P-16

200,000.00 400,000.00 300,000.00 300,000.00 100,000.00 180,000.00 260,000.00

Formalmente, un atributo de un conjunto de entidades es una función que asigna al conjunto de entidades el dominio. Como un conjunto de entidades puede tener diferentes atributos, cada entidad se puede describir como un conjunto de pares (atributo, valor), un par para cada atributo del conjunto de entidades. Por ejemplo una entidad concreta cliente se puede describir mediante el conjunto {(nombre, López), (DNI, 677789901), (nombre-calle, Mayor), (ciudad-cliente, Peguerinos)}, queriendo decir que la entidad describe una persona llamada López que tiene un DNI 67789901 y reside en la calle Mayor en Peguerinos. Los valores de los atributos que describen una entidad constituirían una porción significante de los datos almacenados en la base de datos. Un atributo en el modelo E-R se puede clasificar en los siguientes tipos:  Atributos Simples y Compuestos.- En los conjuntos de entidades anteriores los atributos que se usaron son simples; por que no están divididos en subpartes. En cambio, los atributos compuestos, se pueden dividir en subpartes, es decir, se pueden dividir en otros atributos. Por ejemplo nombre-cliente podría estar estructurado como un atributo compuesto consistente en nombre, primer-apellido y segundo apellido. Usar atributos compuestos en un esquema de diseño es una buena elección si el usuario desea referirse a un atributo entero en algunas ocasiones y a algún componente del atributo en otras. Se podrían haber sustituido los atributos del conjunto de entidades cliente, calle-cliente, y ciudad-cliente, por el atributo compuesto dirección-cliente, con los atributos calle, ciudad, provincia y código-postal. Los atributos compuestos ayudan a agrupar los atributos relacionados, haciendo los modelos más claros. Un atributo compuesto puede aparecer como una jerarquía. Viendo el ejemplo de atributo compuesto dirección-cliente, su componente calle, puede ser a su vez dividido en numero-calle, nombre-calle, y piso. Atributos compuestos nombre-cliente y dirección-cliente.



Atributos univalorados y multivalorados.- Los atributos que se han especificados en el ejemplo anterior todos tienen un valor solo para una entidad concreta. Por ejemplo el atributo numero-préstamo para una entidad préstamo especifico, referencia a un único numero de préstamo bancario. Tales atributos se llaman univalorados. Puede haber ocasiones en las que un atributo tiene un conjunto de valores para una entidad especifica. Considerando un conjunto de entidades empleado con un atributo nombre-subordinado. Cualquier empleado puede tener cero, uno o más subordinados; por lo tanto, diferentes entidades empleado dentro del conjunto de entidades tendrán diferentes números de valores para el atributo nombre-subordinado. Este tipo de atributo se llama multivalorado. En ellos se pueden colocar apropiadamente limites inferior y superior en el numero de valores en el atributo multivalorado. Por ejemplo, un banco puede limitar el numero de direcciones almacenadas para un único cliente a dos. Colocando limites en este caso, se expresa que el atributo dirección-cliente del conjunto de entidades cliente puede tener entre cero y dos valores.  Atributos Nulos.- Un valor nulo se usa cuando una entidad no tiene un valor para un atributo, Por ejemplo, si un empleado en particular no tiene subordinados, el valor nombre-subordinado para ese empleado será nulo. Nulo puede también designar que el valor de un atributo es desconocido.



Atributo derivado.- El valor de este atributo se puede derivar de los valores de otros atributos o entidades. Por ejemplo, si se tiene el conjunto de entidades cliente que tiene un atributo prestamos que representa cuantos prestamos tiene un cliente en el banco. Este atributo se puede derivar contando el numero de entidades préstamo asociadas con ese cliente. 2.2 RELACIONES Y CONJUNTOS DE RELACIONES Una relación es una asociación entre diferentes entidades. Considerando las dos entidades cliente y préstamo. Se define un conjunto de relaciones prestatario denotarla asociación entre clientes y prestamos bancarios que los clientes tengan. Conjunto de relaciones prestatario

14

Santos

32112312

Mayor

Peguerinos

P-17

200,000.00

Gómez

19283746

Carretas

Cerceda

P-23

400,000.00

López

67789901

Mayor

Peguerinos

P-15

300,000.00

Sotoca

12345678

Real

Cádiz

P-14

300,000.00

Pérez

55555555

Carretas

Cerceda

P-93

100,000.00

Valdivieso

96396396

Goya

Vigo

P-11

180,000.00

Fernández

33557799

Jazmín

León

P-16

260,000.00

Un conjunto de relaciones es un conjunto de relaciones del mismo tipo. Formalmente es una relación matemática con n 2 de conjuntos de entidades. Si E1, E2, ..., En son conjuntos de entidades, entonces un conjunto de relaciones R es un subconjunto de {(e1, e2,..., en) | e1 E1, e2 E2,..., en En } donde (e1, e2,..., en) es una relación. Considerando los dos conjuntos de entidades préstamo y sucursal. Se puede definir un conjunto de relaciones sucursal-préstamo para denotar la asociación entre un préstamo bancario y la sucursal en que se mantiene ese préstamo. La asociación entre conjunto de entidades se referencia como participación; es decir, los conjuntos de entidades E1, E2,...,En participan en el conjunto de relaciones R. La función que desempeña una entidad en una relación se llama papel de la entidad. Debido a que los conjuntos de entidades que participan en un conjunto de relaciones son generalmente distintos, los papeles están implícitos y no se especifican normalmente. Sin embargo son útiles cuando el significado de una relación necesita aclaración. Una relación puede también tener atributos descriptivos. Considerando un conjunto de relaciones impositor con conjuntos de entidades cliente y cuenta. Se podría asociar el atributo fecha-acceso a esta relación para especificar la fecha mas reciente en que un cliente accedió una cuenta. El conjunto de relaciones prestatario y sucursal-préstamo proporcionan un ejemplo de un conjunto de relaciones binario. La mayoría de los conjuntos de relaciones en un sistema de base de datos son binarios. Ocasionalmente, los conjuntos de relaciones implican mas de dos conjuntos de entidades. Por ejemplo, se podrían combinar los conjuntos de entidades prestatario y sucursal-préstamo para formar un conjunto de relaciones ternario CPS entre los conjuntos de entidades cliente(C), préstamo (P) y sucursal (S). Él numero de conjunto de entidades que participan en un conjunto de relaciones es también el grado del conjunto de relaciones. Un conjunto de relaciones binario tiene grado 2; un conjunto de relaciones ternario tiene grado 3. 2.3 LIMITANTES DE MAPEO Un esquema de desarrollo E-R puede definir ciertas restricciones a las que los contenidos de la base de datos se deben adaptar. Una restricción importante es la de las cardinalidades de asignación, que expresan el numero de entidades a las que la otra entidad puede estar asociada mediante un conjunto de relaciones.

15 La correspondencia de cardinalidades es la mas útil describiendo conjunto de relaciones binaria, aunque ocasionalmente contribuyen a la descripción de conjuntos de relaciones que implican mas de dos conjuntos de entidades. Para un conjunto de relaciones binarias R entre los conjuntos de entidades A y B, la correspondencia de cardinalidades debe ser: Uno a Uno.- Una entidad en A se asocia con a lo sumo una entidad en B, y una entidad en B se asocia con a lo sumo una entidad en A.

A

B

a1

b1

a2

b2

a3

b3

a4

b4

Relación Uno a Uno Uno a Varios.- Una entidad en A se asocia con cualquier numero de entidades en B. Una entidad en B, sin embargo, se puede asociar con a lo sumo una entidad en A.

A

B b1

a1

b2

a2

b3

a3

b4 b4

Relación Uno a Varios

Varios a Uno.- Una entidad en A se asocia con a lo sumo una entidad en B. Una entidad en B, sin embargo, se puede asociar con cualquier numero de entidades en A.

16

A

B

a1 a2

b1

a3

b2

a4

b3

a5

Relación Varios a Uno Varios a Varios.- Una entidad en A se asocia con cualquier numero de entidades en B, y una entidad en B, se asocia con cualquier numero de entidades en A.

A

B

a1

b1

a2

b2

a3

b3

a4

b4

Relación Varios a Varios La correspondencia de cardinalidades para un conjunto de relaciones particular es obviamente dependiente de la situación del mundo real que el conjunto de relaciones modela. La razón de cardinalidad de una relación puede afectar a la situación de los atributos de la relación. Los atributos de los conjuntos de las relaciones uno a uno o uno a varios pueden estar asociados con uno de los dos conjuntos de entidades participantes, además de con el conjunto de relaciones. 2.4 LLAVES PRIMARIAS Es importante ser capaz de especificar como las entidades dentro de un conjunto de entidades dado y las relaciones dentro de un conjunto de relaciones dado son distinguibles. Las entidades y relaciones individuales son distintas; desde una perspectiva de base de datos, sin embargo, la diferencia entre ellas se debe expresar en términos de sus atributos. El concepto de clave permite hacer tales distinciones. Una superclave es un conjunto de uno o más atributos que, tomados colectivamente, permiten identificar de forma única una entidad en el conjunto de entidades. Por ejemplo, el atributo dni del conjunto de entidades cliente es suficiente para distinguir una entidad cliente de las otras. Así dni, superclave. Análogamente, la combinación de

17 nombre-cliente y dni es una superclave del conjunto de entidades cliente. El atributo nombre-cliente de la entidad cliente no es una superclave, porque varias personas podrían tener el mismo nombre. Si K es una superclave, entonces también lo es cualquier superconjunto de K. Los subconjuntos propios de las superclaves no son superclaves. Tales superclaves mínimas se llaman claves candidatas. Es posible que conjuntos distintos de atributos pudieran servir como clave candidata. Suponiendo que una combinación de nombre-cliente y calle-cliente es suficiente para distinguir entre los miembros del conjunto de entidades cliente. Entonces, los conjuntos {dni} y {nombre-cliente, calle-cliente} son claves candidatas. Aunque los atributos dni, y nombre cliente juntos puedan distinguir entidades cliente, su combinación no forma una clave candidata, ya que el atributo dni por si solo es una clave candidata. Las claves candidatas se deben designar con cuidado. El termino clave primaria se usa para denotar una clave candidata que es elegida por el diseñador de la base de datos como elemento principal para identificar las entidades dentro del conjunto de entidades. Una clave(primaria, candidata y superclave) es una propiedad del conjunto de entidades, mas que de las entidades individuales. La clave primaria de un conjunto de entidades permite distinguir entre las diferentes entidades del conjunto. Se necesita un mecanismo similar para distinguir entre las diferentes relaciones de un conjunto de relaciones. Sea R un conjunto de relaciones que implica los conjuntos de entidades E 1, E2,...,En. Sea clave-primaria (Ei) el conjunto de atributos que forma la clave primaria para el conjunto de entidades E i. Asúmase, que los nombres de los atributos de todas las clave primarias sin únicos. La composición de la clave primaria para un conjunto de relaciones depende de la estructura de los atributos asociados al conjunto de relaciones R. Si el conjunto de relaciones R no tiene atributos asociados, entonces el conjunto de atributos Clave-primaria(E1) U clave-primaria(E2) U...U clave-primaria(En) Describe una relación individual en el conjunto R. Si el conjunto de relaciones R tiene atributos a1,a2,...,an asociados a él, entonces del conjunto de atributos. Clave-primaria(E1) U clave-primaria(E2) U...U clave-primaria (En) U {a1,a2,...,am}. Describe una relación individual en el conjunto R. En ambos casos, el conjunto de atributos Clave-primaria(E1) U clave-primaria(E2) U...U clave-primaria (En) Forma una superclave para el conjunto de relaciones. La estructura de la clave primaria para un conjunto de relaciones depende de la cardinalidad asociada al conjunto de relaciones. Como ejemplo, considérese el conjunto de entidades cliente y empleado, y un conjunto de relaciones banquero-cliente que representa una asociación entre un cliente y su banquero (una entidad empleado). Supóngase que el conjunto de relaciones es varios a varios, y también supóngase que el conjunto de relaciones tiene el atributo tipo asociado a él, representando la relación (por ejemplo, responsables de prestamos o banquero personal). Entonces la clave primaria de banquero-empleado consiste en la unión de las claves primarias de cliente y empleado. Sin embargo, si un cliente puede tener un solo banquero, es decir, si la relación banquerocliente es varios a uno, entonces la clave primaria de banquero-empleado es simplemente la clave primaria de cliente. Para relaciones uno a uno se puede usar cualquier clave primaria. 2.5 DIAGRAMA ENTIDAD-RELACION La estructura lógica global de una base de datos se puede expresar gráficamente mediante un diagrama E-R. La simplicidad relativa y la claridad de esta técnica de diagrama puede ser en gran parte la causa del uso ampliamente extendido del modelo E-R. Tal diagrama consta de los siguientes componentes: Rectángulos.- Representan los conjuntos de entidades. Elipses.- Representan los atributos. Rombos.- Representan las relaciones. Líneas.- Unen los atributos a conjuntos de entidades y conjunto de entidades a conjunto de relaciones. Elipses dobles.- Representan atributos multivalorados. Elipses discontinuas.- Denotan atributos derivados. Líneas dobles.- Indican la participación total de una entidad en un conjunto de relaciones.

18 Considere el diagrama entidad-relación de la siguiente figura, que consta de dos conjuntos de entidades, cliente y préstamo, relacionadas a través de un conjunto de relaciones binarias prestatario. Los atributos asociados con cliente son: nombre-cliente, dni, callecliente y ciudad-cliente. Los atributos asociados con son numero-préstamo e importe. Las llaves o claves primarias se subrayan.

dni

calle-cliente

nombre-cliente

numero-préstamo

importe

ciudad-cliente

cliente

prestatario

préstamo

El conjunto de relaciones prestatario pueden ser varios a varios, uno a varios, varios a uno, o no a uno. Para distinguir entre estos tipos, se dibuja una línea dirigida () o una línea no dirigida entre el conjunto de relaciones y el conjunto de entidades.

dni

calle-cliente

nombre-cliente

numero-préstamo

importe

ciudad-cliente

cliente

prestatario

Diagrama E-R. Uno a Varios

préstamo

19

dni

calle-cliente

nombre-cliente

numero-préstamo

importe

ciudad-cliente

cliente

prestatario

préstamo

Diagrama E-R. Uno a Uno Si un conjunto de relaciones tiene también algunos atributos asociados a él, entonces se unen esos atributos a ese conjunto de relaciones. Por ejemplo del siguiente diagrama:

fecha-acceso dni

calle-cliente

nombre-cliente

importe

numero-préstamo

ciudad-cliente

cliente

impositor

préstamo

Diagrama E-R. con un atributo unido a un conjunto de relaciones se tiene el atributo descriptivo fecha-acceso unido al conjunto de relaciones impositor para especificar la fecha mas reciente en que un cliente accedió a esa cuenta. En los diagramas E-R se indican papeles mediante etiquetas en las líneas que unen a rombos con rectángulos. En el siguiente ejemplo se muestra el papel indicando director y trabajador entre el conjunto de entidades empleado y el conjunto de relaciones trabaja-para.

20

nombre-empleado número-teléfono

dni-e

director

empleado

trabaja-para

trabaja-para Diagrama E-R con indicadores de papel

Los conjuntos de relaciones no binarias se pueden especificar fácilmente mediante un diagrama E-R. El siguiente ejemplo consta de tres conjuntos de entidades cliente, préstamo y sucursal, relacionados a través del conjunto de relaciones CPS. Este diagrama especifica que un cliente puede tener varios prestamos, y esos prestamos pueden pertenecer a varios clientes. La flecha que apunta a sucursal indica que cada par préstamocliente esta asociado con una sucursal bancaria especifica.

ciudad-sucursal nombre-sucursal

activos

sucursal dni

calle-cliente

nombre-cliente cliente

ENTIDADES DEBILES

número-préstamo

ciudad-cliente CPS

importe

préstamo

21 Un conjunto de entidades puede no tener suficientes atributos para formar una clave primaria. Tal conjunto de entidades se denomina conjunto de entidades débil. Un conjunto de entidades que tiene una clave primaria se denomina conjunto de entidades fuerte. Considerando un conjunto de entidades pago, que tiene los atributos: numero-pago, fecha-pago, e importepago. Aunque cada entidad pago es distinta, los pagos para diferentes prestamos pueden compartir el mismo numero de pago. Así, este conjunto de entidades no tiene una clave primaria; es un conjunto de entidades débil. Para que un conjunto de entidades débil tenga sentido, debe formar parte de un conjunto de relaciones uno a varios. Aunque un conjunto de entidades débil no tiene clave primaria, solamente se necesita conocer la distinción entre todas aquellas entidades del conjunto de entidades que dependen de una entidad particular fuerte. El descriminante de un conjunto de entidades débil es un conjunto de atributos que permite que esta distinción se haga. Por ejemplo, el discriminante del conjunto de entidades débil pago es el atributo numero-pago ya que para cada préstamo un numero de pago identifica de forma única un pago simple de ese préstamo.

La clave primaria de un conjunto de entidades débil se forma mediante la clave primaria del conjunto de entidades fuerte de cuya existencia depende el conjunto de entidades débil, mas el descriminante del conjunto de entidades débil. En el caso del conjunto de entidades pago, su clave primaria es {numero-préstamo, numero-pago}, donde numero-préstamo identifica la entidad dominante de un pago y numero-pago distingue las entidades pago dentro del mismo préstamo. El conjunto de entidades dominante identificador se llama propietario del conjunto de entidades débil que identifica. La relación que asocia el conjunto de entidades débil con un propietario se llama relación de identificación. En el ejemplo anterior, préstamo-pago es la relación de identificación para pago. Un conjunto de entidades débil se indica en los diagramas E-R mediante un rectángulo dibujado con una línea doble y la correspondiente relación de identificación mediante un rombo dibujado con linera doble.

fecha-pago número-pago

número-préstamo

importe-pago

importe

préstamo

préstamopago

pago

Diagrama E-R con un conjunto de entidades débil

El diagrama anterior, el conjunto de entidades débil pago es dependiente del conjunto de entidades fuerte préstamo a través del conjunto de relaciones préstamo-pago. También se muestra el uso de líneas dobles para indicar la participación total del conjunto de entidades pago en la relación préstamo-pago, significando que cada pago debe estar relacionado a través de préstamo-pago con alguna cuenta. Un conjunto de entidades débil puede participar como propietario en una relación de identificación con otro conjunto de entidades débil. Incluso aunque la existencia de un conjunto de entidades débil dependa siempre de una

22 entidad dominante, una dependencia no debe existir necesariamente en un conjunto de entidades débil; es decir, el conjunto de entidades subordinado puede tener una clave primaria. 2.6 REDUCCION DE LOS DIAGRAMAS E-R A TABLAS Una base de datos que se constituye es un esquema de base de datos E-R se puede representar por una colección de tablas. Para cada conjunto de entidades de la base de datos y para cada conjunto de relaciones hay una única tabla a la que se le asigna el nombre de conjunto de entidades o del conjunto de relaciones correspondientes. Ambos modelos, el modelo E-R y el modelo de bases de datos relacional, son representación abstractas y lógicas del desarrollo del mundo real. Debido a que los dos modelos emplean principios de diseño similares, se puede convertir un diseño E-R en un diseño relacional. Sea E un conjunto de entidades fuertes con los atributos descriptivos a1, a2, ..., a n. Esta entidad se representa mediante una tabla llamada E con n columnas distintas, cada una de las cuales corresponde a uno de los atributos de E. Cada fila de la tabla corresponde a una entidad del conjunto de entidades E. Considerando el conjunto de entidades préstamo con sus atributos número-préstamo e importe. Se representa este conjunto de entidades mediante una tabla llamada préstamo, con dos columnas. Como se muestra a continuación: Tabla Préstamo Número-préstamo P-17 P-23 P-25 P-14 P-93 P-11 P-16

Importe 200,000 400,000 300,000 300,000 100,000 180,000 260,000

La fila (P-17, 200,000) significa que el numero de préstamo P-17 tiene un importe de préstamo de 200,000. Se puede añadir una nueva entidad a la base de datos insertando una fila en la tabla. También se pueden borrar o modificar las filas. Considerando el conjunto de entidades cliente con los atributos: nombre-cliente, dni, calle-cliente y ciudadcliente. La tabla correspondiente a cliente tiene cuatro columnas.

dni

calle-cliente

nombre-cliente

ciudad-cliente

cliente

Diagrama E-R para el conjunto de entidades

Tabla de equivalencia

cliente

23

Nombre-cliente Santos Gómez López Pérez Rupérez Abril Valdivieso Fernández González

Dni 32112312 19283746 67789901 55555555 24466880 96396396 96396396 33557799 19283746

Calle-cliente Mayor Carretas Mayor Carretas Ramblas Preciados Goya Jazmín Arenal

Ciudad-cliente Peguerinos Cerceda Peguerinos Cerceda León Valsaín Vigo León La Granja

Representación tabular de los conjuntos de entidades débiles Sea A un conjunto de entidades débil con los atributos a1, a2,...,am. Sea B el conjunto de entidades fuerte del que A depende. Sea la clave primaria el conjunto de atributos b1,b2,...,bn. Se representa el conjunto de entidades A mediante una tabla llamada A con una columna por cada uno de sus atributos del conjunto: {a1,a2,...,am} U {b1,b2,...,bn} Considerando al conjunto de entidades pago con sus atributos: numero-pago, fecha-pago e importe-pago,. La clave primaria del conjunto de entidades préstamo, de la que depende, es número-préstamo.

fecha-pago número-pago

número-préstamo

importe-pago

importe

préstamopago

préstamo

pago

Diagrama E-R con un conjunto de entidades débil Tabla de equivalencia Tabla pago Número-préstamo P-17 P-23 P-15 P-14 P-93 P-17 P-11 P-93 P-17

Número-pago 5 11 22 69 103 6 53 104 7

Fecha-pago 10 mayo 2000 17 mayo 2000 23 mayo 2000 28 mayo 2000 3 junio 2000 7 junio 2000 7 junio 2000 13 junio 2000 17 junio 2000

Importe-pago 10,000 15,000 60,000 100,000 180,000 10,000 25,000 40,000 20,000

24 P-16

58

18 junio 2000

27,000

Representación tabular del conjunto de relaciones Sea R un conjunto de relaciones, sean a1, a2 ,..., am, el conjunto de atributos formados por la unión de las claves primaria de cada uno de los conjuntos de entidades que participan en R, y sean b1, b2,..., bn los atributos descriptivos de R. El conjunto de relaciones se representa mediante una tabla llamada R con una columna por cada uno de los atributos del conjunto. Considerando el siguiente diagrama, el conjunto de relaciones prestatario implica los dos siguientes conjuntos de entidades. Cliente. Con la clave primaria dni. Préstamo. Con la clave primaria número-préstamo. Debido a que el conjunto de relaciones no tiene atributos, la tabla prestatario tiene 2 columnas etiquetadas dni y numero-préstamo.

dni

calle-cliente

nombre-cliente

numero-préstamo

importe

ciudad-cliente

cliente

prestatario

préstamo

Diagrama E-R. Uno a Uno Tabla prestatario Dni 32112312 19283746 67789901 55555555 24466880 19283746 93696396 33557799

Numeropréstamo P-17 P-23 P-15 P-14 P-93 P-11 P-17 P-16

Redundancia de tablas El caso de un conjunto de relaciones unido a un conjunto de entidades débil con el correspondiente conjunto de entidades fuerte es especial. Estas relaciones son varios a uno y no tienen atributos descriptivos. Además la clave primaria de un conjunto de entidades débil incluye la clave primaria del conjunto de entidades fuerte. Del diagrama E-R con el conjunto de entidades débil pago, éste depende del conjunto de entidades fuerte préstamo a través del conjunto de relaciones préstamo-pago. La clave primaria de pago es {numero-préstamo, numero-pago} y la clave primaria de préstamo es {numero-préstamo}. Como préstamo-pago no tiene atributos descriptivos, la tabla para préstamo-pago tendría dos columnas, numero-préstamo y numero-pago. La tabla pago tiene cuatro columnas, numero-préstamo, numero-pago, fecha-pago, e importe-pago. Así, la tabla préstamo-pago es redundante, la tabla para el conjunto de relaciones que une a un conjunto de entidades débil con su correspondiente

25 conjunto de entidades fuerte es redundante y no necesita ser representada en una representación tabular de un diagrama E-R. Combinación de tablas Considerando un conjunto AB de relaciones varios a uno del conjunto de entidades A al conjunto de entidades B. Usando el esquema de construcción de tablas se construyen tres tablas: A, B, y AB. Sin embargo, si hay una dependencia de existencia de A a B (esto es, para cada entidad a en A, la existencia de a depende de la existencia de alguna entidad b en B), entonces se pueden combinar las tablas A y AB para formar una única tabla consiste en la unión de las columnas de ambas tablas. Ejemplo, considerando el siguiente diagrama:

ciudad-sucursal número-cuenta

nombre-sucursal

saldo

cuenta

cuenta-sucursal

activos

sucursal

El conjunto de relaciones cuenta-sucursal es varios a uno desde cuenta a sucursal. Además, la sobre línea indica que la participación de cuenta en cuenta-sucursal es total. Además una cuenta no puede existir sin estar asociada con una sucursal en particular. Por lo tanto se necesitan las dos siguientes tablas: cuenta.- con los atributos: numero-cuenta, saldo, nombre-sucursal. Sucursal.- con los atributos: nombre-sucursal, ciudad-sucursal y activos. 2.7 GENERALIZACION Y ESPECIALIZACION ESPECIALIZACION Un conjunto de entidades puede incluir subgrupos de entidades que se diferencian de alguna forma de las otras entidades del conjunto. Por ejemplo, un subconjunto de entidades en un conjunto de entidades puede tener atributos que no son compartidos por todas las entidades. El modelo E-R proporciona una forma de representación de estos grupos de entidades distintos. Considérese el conjunto de entidades cuenta con atributos numero-cuenta y saldo. Una cuenta se puede clasificar como una de las siguientes: 1. cuenta-ahorro. 2. Cuenta-corriente Cada uno de estos tipos de cuentas se describen mediante un conjunto de atributos que incluyen los atributos del conjunto de entidades cuenta más otros atributos adicionales. Por ejemplo, las entidades cuenta-ahorro se describen además mediante el atributo tipo-interés, mientras que las entidades cuenta-corriente se describen además mediante el atributo descubierto. El proceso de designación de subgrupos dentro de un conjunto de entidades es la especialización. La especialización de cuenta permite distinguir entre las cuentas basándose en el tipo de cuenta. Un conjunto de entidades se puede especializar mediante mas de una característica distintiva. En este ejemplo, la característica distintiva es el tipo de cuenta. En términos de un diagrama E-R, la especialización se representa por medio de un componente triangular etiquetado ISA, como se muestra a continuación. La etiqueta ISA significa << is a >> (ES) y representa, por ejemplo, que una cuenta de ahorro es una cuenta.

26

número-cuenta

saldo

cuenta

ISA

tipo-in te rés

descubierto

cuentacorriente

cuenta-ahorro

ISA

normal

númeromovimiento s

oro

pago-interés

senio r

sald o-mínimo

fecha-nacimie nto

GENERALIZACION El refinamiento desde un conjunto de entidades inicial en sucesivos niveles de subgrupos en entidades representa un proceso de diseño descendente (top-down) en el que las distinciones se hacen explícitas. El proceso de diseño puede ser también de forma ascendente (bottom-up) en que los múltiples conjuntos de entidades se sintetizan en un conjunto de entidades de nivel mas alto basado en características comunes. El diseñador de la base de datos puede haber identificado primero el conjunto de entidades cuenta-corriente con los atributos numero-cuenta, saldo y descubierto, y el conjunto de entidades cuenta-ahorro con los atributos numero-cuenta, saldo y tipo interés. Hay similitudes entre el conjunto de entidades cuenta-corriente y el conjunto de entidades cuenta-ahorro en el sentido de que tienen varios atributos en común. Esta similitud se puede expresar mediante generalización, que es una relación contenida que existe entre el conjunto de entidades de nivel mas alto y uno o más conjuntos de entidades de nivel mas bajo. En el ejemplo, cuenta es el conjunto de entidades del nivel mas alto, y los conjuntos de entidades cuentaahorro y cuenta-corriente son del nivel mas bajo. 2.8 AGREGACION Una limitación del modelo E-R es que no es posible expresar relaciones entre relaciones. Para ilustrar la necesidad de tales construcciones, considérese una base de datos que describe información acerca de clientes y prestamos. Supóngase que cada par cliente-préstamo puede tener un empleado del banco que es el responsable de prestamos para ese par particular. Usando las construcciones del modelo E-R básico, se obtiene el siguiente diagrama:

27

dni

calle-cliente número-préstamo

nombre-cliente

importe

ciudad-cliente

cliente

prestatario

préstamo

responsableprestamo

empleado

dni-e

número-teléfono nombre-empleado

En el que se observa los conjuntos de relaciones prestatario y responsable-préstamo se pueden combinar en un conjunto de relaciones simple. De otro modo no se podría combinar, ya que haciéndolo, se oscurece la estructura lógica del esquema. Por ejemplo, si se combinan los conjuntos de relaciones prestatario y responsable-préstamo, esta combinación especifica que un responsable de prestamos debe estar asignado a cada par cliente-préstamo, lo cual no es cierto. La separación en dos conjuntos de relaciones diferentes resuelve este problema. Sin embargo, hay información redundante, en el diagrama, ya que cada par cliente-préstamo en responsablepréstamo esta también prestatario. Si el responsable de prestamos fuera un valor en lugar de una entidad empleado, se podría en su lugar hacer referencia a un atributo multivalorado responsable-préstamo en la relación prestatario. Pero esto implica, que es más difícil, encontrar, por ejemplo, los pares cliente-préstamo de los que un empleado es responsable. La mejor forma de modelar esta situación como esta es usar agregación. La agregación es una abstracción a través de la cual las relaciones se tratan como entidades de nivel mas alto. Para el ejemplo, se considera el conjunto de relaciones prestatario y los conjuntos de relaciones cliente y préstamo como un conjunto de entidades llamado prestatario. Tal conjunto de entidades se trata de la misma forma que cualquier otro conjunto de entidades. El diagrama utilizando agregación quedaría de la siguiente manera:

28

dni

calle-cliente número-préstamo

nombre-cliente

importe

ciudad-cliente

cliente

prestatario

préstamo

responsableprestamo

empleado

dni-e

número-teléfono nombre-empleado

29 UNIDAD III. MODELO RELACIONAL 3.1.

ESTRUCTURA DE LAS BASES DE DATOS RELACIONALES

Una base de datos relaciones consiste en un conjunto de tablas, a cada una de las cuales se le asigna un nombre exclusivo. Cada fila de la tabla representa una relación entre un conjunto de valores. Considerando la siguiente tabla:

Nombre-sucursal Centro Becerril Navacerrada Collado Mediano Galapagar Moralzarzal Galapagar

Número-cuenta C-101 C-215 C-102 C-305 C-201 C-222 C-217

saldo 100,000 140,000 80,000 70,000 180,000 140,000 150,000

Tiene tres cabeceras de columna: nombre-sucursal, numero-cuenta y saldo. Se puede hacer referencia a estas cabeceras como atributos. Para cada atributo hay un conjunto de valores permitidos denominado dominio de ese atributo. Para el atributo nombre-sucursal, por ejemplo el dominio es el conjunto de los nombres de las sucursales. Suponiendo que D1 denota este conjunto, D2 el conjunto de los numero de cuenta y D3 el conjunto de los saldos. Todas la filas de cuenta deben coincidir en una tupla (v1,v2,v3) donde v1 es un nombre de sucursal (v1 esta en el dominio de D1), v2 es un numero de cuenta (v2 esta en el dominio D2) y v3 es un saldo. En general cuenta solo tendrá un subconjunto del conjunto de todas las filas posibles. Por lo tanto cuenta es un subconjunto de: D1 X D 2 X D 3 En general, una tabla de n atributos debe ser un subconjunto de: D1 X D2 X...XDn-1 X Dn Como las tablas son esencialmente relaciones, se utilizan los términos matemáticos relación y tupla en lugar de tabla y fila. ALGEBRA RELACIONAL El álgebra relacional es un lenguaje de consulta procedimental. Consta de un conjunto de operaciones que toman como entrada una o dos relaciones y producen como resultado una nueva relación. El álgebra relacional esta divido en dos grupos:

1.

Operadores tradicionales de conjuntos.- Unión, Intersección, diferencia y producto cartesiano.

2.

Operadores relacionales especiales.- Selección, proyección, reunión natural y división.

Tomando como base las siguientes relaciones para ejemplificar cada uno de los operadores. RELACION A S# S1 S4 RELACION B

NOMBRE SALAZAR CORDOVA

CIUDAD LONDRES LONDRES

STATUS 20 20

30 S# S1 S2

NOMBRE SALAZAR JAIMES

CIUDAD LONDRES PARIS

STATUS 20 10

Además se debe respetar que el operador unión, intersección y diferencias sean compatibles con la unión. Es decir, que las tablas a operar deben ser del mismo grado y los j-ésimos atributos de las relaciones (j = rango de 1 a n) deben tener el mismo dominio (no es necesario que tengan el mismo nombre) UNION.- La unión de dos relaciones A y B compatibles con la unión, denotado por A unión B, es una relación cuya cabecera es idéntica a la de A o de B y cuyo cuerpo son las tuplas t pertenecientes ya sea a A o B o ambas. AUB= S#

NOMBRE CIUDAD STATUS S1 SALAZAR LONDRES 20 S4 CORDOVA LONDRES 20 S2 JAIMES PARIS 10 INTERSECCION.- La intersección de dos relaciones A y B compatibles con la unión, denotado por A intersección B, es una relación cuya cabecera es idéntica a la de A o de B y cuyo cuerpo son las tuplas t pertenecientes tanto a A como B o ambos. S# S1

NOMBRE SALAZAR

CIUDAD LONDRES

STATUS 20

DIFERENCIA.- La diferencia entre dos relaciones compatibles a la unión A y B, denotado por A minus B, es una relación cuya cabecera es idéntica a la de A o B y cuyo cuerpo esta formado por todas las tuplas t pertenecientes a A pero no a B. A–B= S# S4

NOMBRE CORDOVA

CIUDAD LONDRES

STATUS 20

PRODUCTO CARTESIANO.- El producto cartesiano de las tablas A y B, denotado por A times B se define como una relación cuya cabecera es la combinación de las cabeceras A y B, y cuyo cuerpo esta formado por el conjunto de todas las tuplas t de tal modo que t sea una combinación de una tupla A perteneciente a la relación A y una tupla b perteneciente a la relación B. Por ejemplo.- Suponiendo las relaciones Ay B. Definidas de la siguiente manera: sea la relación A el conjunto de todos los números de proveedor y B el conjunto de todos los números de partes. Entonces A times B es el conjunto de todos los pares posibles numero de proveedor/numero de parte. A

B S# S1 S2 S3

OPERADORES RELACIONALES ESPECIALES

A Times B P# P1 P2

S# S1 S1 S2 S2 S3 S3

P# P1 P2 P1 P2 P1 P2

31 Operador selección ().-El operador algebraico de selección produce un conjunto horizontal de una relación especifica, es decir, el conjunto de las tuplas de la relación para el cual se cumple un predicado especifico. Sea theta cualquiera de los siguientes operadores =, <, >, <=, >=, <>, entonces quedaría: SELECT A WHERE X THETA Y Es una relación con la misma cabecera de A y con un cuerpo formado por el conjunto de tuplas t de la relación A siempre y cuando la evaluación de comparación “X THETA Y” resulte verdadera. La expresión condicional puede estar compuesta por expresiones boleanas unidad por AND, OR y NOT. Ejemplos:

4. 4. 4.

S WHERE CIUDAD =’LONDRES’ P WHERE PESO < 14 SP WHERE S# =’S1’ AND P#=’P1’

Proyección ( ).- El operador de proyección produce un subconjunto vertical de una relación dada, es decir, el subconjunto obtenido al seleccionar los atributos que se indican en un orden de izquierda a derecha y eliminando las tuplas duplicadas. La proyección de una relación A según los atributos x, y, z. A[x, y, z] es una relación con (x, y, z) como cabecera y cuyo cuerpo esta formado por el conjunto de tuplas (A-x, A-y, A-z), es decir, se selecciona de la tabla, las columnas x, y, z. Por ejemplo: S[CIUDAD] CIUDAD LONDRES PARIS ATENAS

REUNION NATURAL (JOIN).- Sean las cabeceras de las relaciones A y B respectivamente: (X1, X2,..., Xm, Y1, Y2,..., Yn) (Y1, Y2,..., Yn, Z1, Z2,..., Zn) es decir, los atributos Y1, Y2,..., Yn son los únicos comunes a las dos relaciones y además están definidos bajo el mismo dominio. Considerando las siguientes relaciones: RELACION S S# S1 S2 S3 S4

NOMBRE JOSE JAVIER CARLOS MARIO

CIUDAD JOJUTLA TLAQUI MEXICO JOJUTLA

RELACION SP S#

P#

CANT

STATUS 20 30 10 20

32 S1 S1 S1 S2 S2 S3 S4

P1 P2 P5 P1 P2 P3 P4

100 200 100 200 400 100 200

S JOIN SP S# S1 S1 S1 S2 S2 S3 S4

NOMBRE JOSE JOSE JOSE JAVIER JAVIER CARLOS MARIO

CIUDAD JOJUTLA JOJUTLA JOJUTLA TLAQUI TLAQUI MEXICO JOJUTLA

STATUS 20 20 20 30 30 10 20

P# P1 P4 P5 P1 P2 P3 P4

CANT 100 200 100 200 400 100 200

DIVISION.- Sean las cabeceras de las relaciones A y B (X1,X2,...,Xm, Y1,Y2,...,Yn) y (Y1,Y2,...,Yn), es decir los atributos (Y1,Y2,...,Yn) son comunes a las 2 relaciones donde A representa al dividendo y B al divisor. Para ello, tanto los atributos (Y1, Y2,...,Yn) de A como B deben estar definidos bajo el mismo dominio.

DIVIDENDO S# S1 S1 S1 S1 S1 S1 S2 S2 S3 S4 S4 S4

3.2

P# P1 P2 P3 P4 P5 P6 P1 P3 P2 P2 P4 P5

DIVISOR

DIVIDENDO BY DIVISOR

P# P1

S# S1 S2

P# P2 P4

S# S1 S4

P# P1 P2 P3 P4 P5 P6

S# S1

LENGUAJES DE CONSULTA FORMALES

Un lenguaje de consulta es un lenguaje en el que el usuario solicita información de la base de datos. Estos lenguajes suelen ser de un nivel superior que el de los lenguajes de programación habituales. Los lenguajes de consulta pueden clasificarse como procedimentales o no procedimentales. En los lenguajes procedimentales, el usuario instruye al sistema para que lleve a cabo una serie de operaciones en la base de datos para calcular el resultado deseado. En los lenguajes no procedimentales, el usuario describe la información deseada sin dar un procedimiento concreto para obtener esa información. La mayor parte de los sistemas comerciales de base de datos relacionales ofrecen un lenguaje de consulta que incluye elementos de los enfoque procedimental y no procedimental.

33

3.4.

MODIFICACION DE LA BASE DE DATOS

Las modificaciones de la base de datos se expresan utilizando la operación asignación. Las tablas mostradas a continuación se utilizarán para mostrar ejemplos de las diferentes modificaciones que se puedan tener. Estos ejemplos serán por medio de SQL de ORACLE. SQL (Structured Query Language) es un Lenguaje Estructurado de Consulta Comercial que nos permite interactuar con la base de datos. SQL contiene otras características además de la consulta en bases de datos. Incluye características para definir la estructura de los datos, para la modificación de los datos en la base de datos y para la especificación de ligaduras de seguridad. SQL contiene comandos que se utilizan para crear, almacenar, cambiar, recuperar y mantener la información en una base de Datos. Un comando de SQL se guarda en una parte de la memoria llamada SQL Buffer, en donde se queda hasta que un nuevo comando es introducido. TABLAS Tabla EMP. Descripción de sus Campos o Atributos EMPNO ENAME JOB MGR HIREDATE SAL COMM DEPTNO

NOT NULL NUMBER(4) CHAR(10) CHAR(10) NUMBER(4) DATE NUMBER(7,2) NUMBER(7,2) NUMBER(2)

EMPNO ENAME JOB 7369 SMITH CLERK 7499 ALLEN SALESMAN 7521 WARD SALESMAN 7566 JONES MANAGER 7654 MARTIN SALESMAN 7698 BLAKE MANAGER 7782 CLARK MANAGER 7788 SCOTT ANALYST 7839 KING PRESIDENT 7844 TURNER SALESMAN 7876 ADAMS CLERK 7900 JAMES CLERK 7902 FORD ANALYST 7934 MILLER CLERK Tabla DEPT. Descripción de sus Campos. DEPTNO DNAME LOC

MGR 7902 7698 7698 7839 7698 7839 7839 7566 7698 7788 7698 7566 7782

HIREDATE 17-DEC-80 20-FEB-81 22-FEB-81 02-APR-81 28-SEP-81 01-MAY-81 09-JUN-81 07-JUN-81 17-NOV-81 08-SEP-81 11-JUL-87 03-DEC-81 03-DEC-81 23-JAN-82

SAL 800 1600 1250 2975 1250 2850 2450 3000 5000 1500 1100 950 3000 1300

COMM 300 500 1400

0

DEPTNO 20 30 30 20 30 30 10 20 10 30 20 30 20 10

NUMBER(2) CHAR(14) LOC () DEPTNO 10 20 30 40

DNAME ACCOUNTING RESEARCH SALES OPERATIONS

LOC NEW YORK DALLAS CHICAGO BOSTON

Borrado.- Las solicitudes de borrado se expresan básicamente igual que las consultas. Sin embargo en lugar de mostrar las tuplas al usuario. Solo se eliminan de la base de datos las tuplas seleccionadas. Solo se pueden borrar

34 tuplas enteras; no se pueden borra valores de atributos concretos. En el álgebra relacional los borrados se expresan mediante: rr–E Donde r es una relación y E es una consulta de álgebra relacional. Por ejemplo:

4.

Borrar todas las cuentas de Gómez

Cuenta cuenta - nombre-cliente=<>(cuenta)

4.

Borrar todos los prestamos con importes entro 0 y 800

Préstamo préstamo - importe >= 0 and importe =< 8000 (préstamo) Tomando en cuenta las tablas anteriores. Mediante SQL se tendría Los borrados DELETE.

utilizando el Comando

Al realizar borrados se debe tomar en cuenta lo siguiente:

  

No se pueden borrar renglones parciales. Si se quiere hacer esto, actualice la columna por NULL. La cláusula WHERE determina los renglones a borrar de la tabla. Si omitimos la cláusula WHERE, se borrarían TODOS los renglones de la tabla.

Ejemplo: Martín renuncio. Se debe remover de la BASE DE DATOS. SQL> DELETE FROM EMP WHERE EMPNO=7654; EMPNO 7369 7499 7521 7566 7654 7698 7782 . . .

ENAME SMITH ALLEN WARD JONES MARTIN BLAKE CLARK

JOB CLERK SALESMAN SALESMAN MANAGER SALESMAN MANAGER MANAGER

MGR 7902 7698 7698 7839 7698 7839 7839

HIREDATE 17-DEC-80 20-FEB-81 22-FEB-81 2-APR-81 28-SEP-81 1-MAY-81 9-JUN-81

Inserción.- Para insertar datos en una relación hay que especificar la tupla que se va a insertar o escribir una consulta cuyo resultado sea un conjunto de tuplas que vayan a insertarse. Evidentemente, el valor de los atributos de las tuplas insertadas deben ser miembros del dominio de cada atributo. De manera parecida las tuplas insertadas deben ser de la aridad correcta. En el álgebra relacional las inserciones se expresan mediante: r rUE

35 Donde r es una relajación y E es una expresión de la álgebra relacional. La inserción de una sola tupla se expresa haciendo que E sea una relación constante que contiene una tupla. * Supóngase que desea insertar el hecho de que Gómez tiene 200,000.00 en la cuenta C-973 en la sucursal Navacerrada. Hay que escribir: cuenta cuenta U {(<>, C-973,240,000.00)} Tomando en cuenta las tablas anteriores. Mediante SQL se tendría las inserciones de la siguiente manera: SQL> INSERT INTO DEPT VALUES (10,’ACCOUNTING’,’NEW YORK’) TABLA DEPT DEPTNO 10

DNAME ACCOUNTING

LOC NEW YORK

DONDE:

    

La tabla debe crearse antes de insertar datos. Los valores se separan con comas. Utilice el comando DESCRIBE para mostrar el orden y tipo de las columnas de la tabla. Los valores deben coincidir con el tipo de dato de la columna a la que se insertan. Los datos tipo CHAR y DATE deben ponerse entre apóstrofes.

Otra forma de insertar es: SQL> INSERT INTO DEPT (DNAME,EPTNO) VALUES (’ACCOUNTING’,10) TABLA DEPT DEPTNO 10

DNAME ACCOUNTING

LOC

DONDE:

 

Se listan los nombres de las columnas en el INSERT para: Insertar datos solamente en algunas columnas de la tabla. Introducir datos en alguna secuencia especifica. Los valores de deben dar en el orden especificado en la cláusula INSERT.

Insertando renglones de otra tabla



Se puede utilizar el comando INSERT con un query para seleccionar renglones de una tabla e insertarlos en otra.



El query sustituye la cláusula VALUES.

SQL> INSERT INTO EMP(EMPNO,ENAME,DEPTNO) SELECT ID,NAME,DEPARTMENT FROM OLD_EMP

36 WHERE DEPARTMENT IN (10,20,30,40); Utilizando Parámetros en el Comando INSERT Un comando INSERT puede contener parámetros representando valores que van a ser provistos por el usuario al momento de correr el comando. Cada parámetro consiste de un & seguido por el nombre de la columna. SQL> INSERT INTO DEPT VALUES (&DEPTNO, &DNAME, &LOC); La ejecución de este comando hace que se pida al usuario los valores para cada uno de los parámetros. No es necesario poner apóstrofes en datos tipo CHAR y DATE si se pone el parámetro. Insertando Valores Nulos. Si no se inserta una columna en cláusula INSERT, el valor de esa columna queda como NULO por default. Se puede especificar NULL en la cláusula VALUES (a menos que NOT NULL esté especificado para esa columna). SQL> INSERT INTO DEPT VALUES (50,’EDUCATION’,NULL) Insertando valores tipo DATE Formato default para introducir fechas (valores tipo DATE): ‘DD-MON-YY’ Introducir a un nuevo empleado ‘STONE’ SQL> INSERT INTO EMP (EMPNO,ENAME,HIREDATE) VALUES (7963,’STONE’,’07-APR-87’); Para introducir automáticamente la fecha y la hora actual: SYSDATE Introducir a un nuevo empleado ‘KOHN’ que fue contratado hoy SQL> INSERT INTO EMP (EMPNO,ENAME,HIREDATE) VALUES (7600,’KOHN’,SYSDATE) Actualización.- Puede que en algunas ocasiones que desee modificar un valor de una tupla sin modificar todos los valores de la tupla. Se puede utilizar el operador proyección generalizada para realizar esta tarea: r F1,F2,...,Fn (r) Donde cada Fi es el i-ésimo atributo de r, si el i-ésimo atributo no esta actualizado, o si hay que actualizar el atributo, Fi es solo una expresión que solo implica constantes y los atributos de r, que da el nuevo valor del atributo. Si se desea seleccionar varias tuplas de r y solo actualizar esas mismas tuplas, se puede utilizar la expresión siguiente: R F1, F2,..., Fn ( P(r)) U (r - P (P)) Para ilustrar el uso de la operación actualización, supóngase que se realiza el pago de los intereses y que hay que aumentar todos los saldos en un 5%. Hay que escribir. Cuenta nombre-sucursal, numero-cuenta, saldo saldo *1.05 (cuenta)

37 Tomando en cuenta las tablas anteriores. Mediante SQL se tendría las Actualizaciones utilizando el Comando UPDATE. Ejemplo: Promover a Martin a MANAGER (gerente) SQL> UPDATE EMP SET JOB=’MANAGER’ WHERE ENAME=’MARTIN’; Tabla EMP Original

Tabla EMP Actualizada

EMPNO ENAME JOB EMPNO ENAME JOB 7369 SMITH CLERK 7369 SMITH CLERK 7499 ALLEN SALESMAN 7499 ALLEN SALESMAN 7521 WARD SALESMAN 7521 WARD SALESMAN 7566 JONES MANAGER 7566 JONES MANAGER 7654 MARTIN SALESMAN 7654 MARTIN MANAGER 7698 BLAKE MANAGER 7698 BLAKE MANAGER 7782 CLARK MANAGER 7782 CLARK MANAGER 7788 SCOTT ANALYST 7788 SCOTT ANALYST 7839 KING PRESIDENT 7839 KING PRESIDENT 7844 TURNER SALESMAN 7844 TURNER SALESMAN 7876 ADAMD CLERK 7876 ADAMD CLERK 7900 JAMES CLERK 7900 JAMES CLERK 7902 FORD ANALYST 7902 FORD ANALYST 7934 MILLER CLERK 7934 MILLER CLERK Si omitimos la cláusula WHERE, todos los valores en la columna cambiarían al valor en la cláusula SET.

Actualizando Múltiples Renglones: Cambiar los puestos de todos los vendedores (SALESMAN) por ‘MARKET REP’ SQL> UPDATE EMP SET JOB=’MARKET REP’ WHERE JOB=’SALESMAN’; Tabla EMP Original EMPNO 7369 7499 7521 7566 7654 7698 7782 7788 7839 7844 7876 7900 7902 7934

ENAME SMITH ALLEN WARD JONES MARTIN BLAKE CLARK SCOTT KING TURNER ADAMD JAMES FORD MILLER

Tabla EMP Actualizada JOB CLERK SALESMAN SALESMAN MANAGER SALESMAN MANAGER MANAGER ANALYST PRESIDENT SALESMAN CLERK CLERK ANALYST CLERK

EMPNO 7369 7499 7521 7566 7654 7698 7782 7788 7839 7844 7876 7900 7902 7934

ENAME SMITH ALLEN WARD JONES MARTIN BLAKE CLARK SCOTT KING TURNER ADAMD JAMES FORD MILLER

JOB CLERK MARKET REP MARKET REP MANAGER MARKET REP MANAGER MANAGER ANALYST PRESIDENT MARKET REP CLERK CLERK ANALYST CLERK

38

Controlando cuando tiene efecto las MODIFICACIONES A LA BASE DE DATOS



Inserciones (altas), borrados (bajas) y actualizaciones (cambios) a tablas no se hacen permanentes hasta que el trabajo es salvado en la base de datos con COMMIT.



Hasta que el trabajo es salvado, únicamente el usuario que hizo los cambios los puede ver, todos los demás usuarios ven los datos como estaban al momento del ultimo COMMIT.



Un COMMIT puede ser explicito, implícito o automático:

COMMIT Explicito.- Se debe dar el commit de SQL COMMIT para que los cambios se hagan permanentes. SQL> COMMIT; COMMIT Implícito.- Los siguientes comandos de SQL causan un COMMIT implícito: ALTER, AUDIT, COMMENT, CONNECT, CREATE, DISCONNECT, DROP, EXIT, GRANT, NOAUDIT, QUIT, REVOKE y RENAME. COMMIT Automático.- Los cambios tienen efecto inmediatamente después de un INSERT, UPDATE o DELETE si el AUTOCOMMIT se encuentra habilitado. Para esto se utiliza el comando SET DE SQL *PLUS SQL> SET AUTOCOMMIT ON El comando ROLLBACK cancela todos los cambios pendientes regresando al estado información al momento del ultimo COMMIT.

en que estaba la

3.5 VISTAS No es deseable que todos los usuarios puedan ver la totalidad del modelo lógico. Las consideraciones sobre la seguridad pueden exigir que algunos datos queden ocultos para los usuarios. Considérese una persona que desea saber el numero de préstamo de un cliente pero que no necesita ver el importe del préstamo. Esta persona debería ver una relación descrita, en el álgebra relacional, mediante: nombre-cliente, numero-préstamo (prestatario x préstamo) A parte de las consideraciones sobre la seguridad, puede que se desee crear un conjunto personalizado de relaciones que se adapte mejor que el modelo lógico a la intuición de un usuario concreto. Definición de Vistas. Las vistas se definen utilizando la instrucción create view. Para definir una vista hay que darle un nombre e indicar la consulta que la va a calcular. La forma de la instrucción view es: Create view v como <expresión de consulta> Donde <expresión de consulta> es cualquier expresión de consulta del álgebra relacional. El nombre de la vista se representa mediante v. Como ejemplo, considérese la vista consistente en las sucursales y sus clientes. Supóngase que se desea que esta vista se denomine todos-los-clientes. Esta vista se define de la siguiente manera. Create view todos-los-clientes as nombre-sucursal, nombre-cliente (impositor x cuenta) U nombre-sucursal, nombre-cliente (prestatario x préstamo).

39

Una vez que se ha definido una vista, se puede utilizar el nombre de la vista para hacer referencia a la relación virtual que genera la vista. Utilizando la vista todos-los-clientes se puede averiguar el nombre de todos los clientes de la sucursal de Navacerrada, escribiendo: Los nombres de las vistas pueden aparecer en cualquier lugar en el que pueda aparecer el nombre de una relación, siempre y cuando no se ejecuten sobre las vistas operaciones de actualización. Si una relación de vistas se calcula y se guarda, puede quedar desfasada si las relaciones utilizadas para definirla se modifican. En vez de eso, las vistas suelen implementarse de la manera siguiente. Cuando se define una vista, el sistema de base de datos guarda la definición de la propia vista, en vez, del resultado de la evaluación de la expresión del álgebra relacional que la define. Siempre que se utiliza una relación de vistas en una consulta, se sustituye por la expresión de consulta guardada. Por tanto, la relación de vistas vuelve a calcularse siempre que se evalúa la consulta. Algunos sistemas de base de datos permiten que se guarden las relaciones de vistas, pero se aseguran que si las relaciones reales utilizadas en la definición de la vista cambian, la vista se mantenga actualizada. Estas vistas se denominan vistas materializadas. Las aplicaciones en la que se utiliza frecuentemente una vista se benefician del uso de vistas materializadas, igual que las aplicaciones en las que el tiempo de respuesta a ciertas consultas basadas en vistas es de suprema importancia. Aunque las vistas son una herramienta útil para las consultas, plantean problemas significativos si con ellas se expresan las actualizaciones, las inserciones o los borrados. La dificultad radica en que las modificaciones de la base de datos expresadas en términos de vistas deben traducirse en modificaciones de las relaciones reales en el modelo lógico de la base de datos.

Tomando en cuenta las tablas anteriores. Mediante SQL se tiene la creación de vistas de la siguiente manera. Una Tabla, con Múltiples vistas



Se puede tener muchas vistas de la misma tabla. EMPNO 7369 7499 7521 7566 7654 7698 7782 7768 7839 7844 7876 7900 7902 7934

Vista de “CLERKS”

ENAME SMITH ALLEN WARD JONES MARTIN BLAKE CLARK SCOTT KING TURNER ADAMS JAMES FORD MILLER

JOB CLERK SALESMAN SALESMAN MANAGER SALESMAN MANAGER MANAGER ANALYST PRESIDENT SALESMAN CLERK CLERK ANALYST CLERK

MGR 7902 7698 7698 7839 7698 7839 7839 7566 7698 7788 7698 7566 7782

HIREDATE 17-DEC-80 20-FEB-81 22-FEB-81 2-APR-81 28-SEP-81 1-MAY-81 9-JUN-81 9-NOV-81 17-NOV-81 8-SEP-81 23-SEP-81 3-DEC-81 3-DEC-81 23-JAN-82

SAL 800 1,600 1,250 2,975 1,250 2,850 2,450 3,000 5,000 1,500 1,100 950 3,000 1,300

Vista de “MANAGERS”

COMM 300 500 1,400

0

DEPTNO 20 30 30 20 30 30 10 20 10 30 20 30 20 10

40

ENAME SMITH ADAMS JAIMES MILLER

JOB CLERK CLERK CLERK CLERK

ENAME JONES BLAKE CLARK

JOB MANAGER MANAGER MANAGER

SAL 2,975 2,850 2,450

Como crear, Nombrar y Consultar Vistas SQL> CREATE VIEW SELECT FROM WHERE

MANAGERS AS ENAME,JOB,SAL EMP JOB=’MANAGER’;

Se puede utilizar cualquier SELECT que con contenga un ORDER BY cuando crea una vista. Para consultar una vista, se hace un SELECT como si la vista fuera una tabla. SQL> SELECT FROM ENAME JONES BLAKE CLARK

* MANAGERS; JOB MANAGER MANAGER MANAGER

SAL 2,975 2,850 2,450

Creando VISTAS con ALIAS de nombres de columnas A menos que se especifique lo contrario, la vista hereda los nombres de las columnas de la tabla de la que se deriva. Para dar a la vista nombres de columnas diferentes a los de la tabla base, se utiliza la siguiente sintaxis: CREATE VIEW nombre_vista (alias, alias,...) AS query SQL> CREATE VIEW MYDEPT (PERSON,TITLE,SALARY) AS SELECT ENAME,JOB,SAL FROM EMP WHERE DEPTNO=10;

Mas acerca de las vistas con WITH CHECK OPTION WITH CHECK OPTION .- Especifica que la inserciones y actualizaciones hechas a la base de datos a partir de la vista, no pueden manipular datos que la vista no puede seleccionar. SQL> CREATE VIEW SELECT FROM WHERE

DEPT20 AS ENAME,JOB, SAL, DEPTNO EMP DEPTNO=20

41 WITH CHECK OPTION

El siguiente commando de actualización generaría un error: SQL> UPDATE DEPT20 SET DEPTNO= 30 WHERE ENAME=’WARD’ Copiando Tablas y Vistas



Razones para copiar tablas y vistas: Respaldar tablas y vistas originales. Dar una copia a alguien mas. Hacer cambios tentativos. Archivarlas antes de borrarlas.



Para copiar una Tabla: Utilice el commando CREATE TABLE con la cláusula AS seguida por un subquery. Cuando la tabla es copiada, la copia incluye la definición de las columnas y los datos.

Borrado de Tablas y Vistas.



Para borrar TABLAS El comando de SQL es DROP TABLE nombre_tabla. Si la tabla tiene datos, estos van a ser borrados permanentemente. Una vez que la tabla se borra no se puede recuperar.



Para borrar vistas. El comando de SQL es DROP VIEW nombre_vista. Las tablas en las que se basa la vista no se altera.

UNIDAD IV. DISEÑO DE BASES DE DATOS RELACIONALES 4.1 PELIGRO 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:

1.

El sistema de base de datos no sufra de anomalías de almacenamiento.

2.

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 aun 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.

42 La normalizació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:

1.

Descomponer todos los grupos de datos en registros bidimensionales.

2.

Eliminar todas las relaciones en la que los datos no dependan completamente de la llave primaria del registro.

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.

4.2.

PRIMERA Y SEGUNDA FORMA NORMAL

Una afinidad es una tabla de dos dimensiones. Cada hilera en la tabla tiene datos que pertenecen a alguna cosa o una parte de alguna cosa. Cada columna de la tabla contiene datos referentes a un atributo. Las hileras de denominan tuplas y las columnas atributos. PRIMERA FORMA NORMAL. Cualquier tabla de datos que cumpla con la definición de una afinidad, se dice que esta en la primera forma normal. Para que una tabla sea una afinidad, debe cumplirse lo siguiente: la celda de la tabla debe poseer valores simples y no se permiten grupos ni arreglos repetidos como valores. Todos los ingresos en cualquier columna (atributo), deben ser del mismo tipo. Cada columna debe tener un nombre único, el orden las columnas en la tabla no es importante Dos hileras en una tabla no deben ser idénticas. La siguiente afinidad esta en primera forma normal SID 100 150 175 200

ACTIVIDAD ESQUI NATACION SQUASH NATACION

CUOTA 200 50 50 50

SEGUNDA FORMA NORMAL.- Para entender la segunda forma normal, consideramos la figura anterior. Tal afinidad posee anomalías de modificación. Si se elimina la tupla para estudiante 175, se perderá el hecho de que SQUASH

43 cuesta $50. Tampoco se puede ingresar una actividad hasta que se inscriba un estudiante. La afinidad esta expuesta a anomalías de eliminación y de inserción. El problema con tal afinidad es que posee una dependencia que involucra solo parte de la clave. La clave es la combinación (Clave, actividad), la afinidad contiene una dependencia, Actividad Cuota. El determinante de esta dependencia (Actividad) es la parte de la clave (SID, Actividad). Se dice que cuota es parcialmente dependiente de la clave de la tabla. No habría anomalías de modificación si cuota dependiera por completo de la clave. Para eliminar las anomalías se debe separar la afinidad en dos afinidades. Esta situación conduce a la definición de segunda forma normal: Una afinidad esta en segunda forma normal si todos sus atributos que no son claves dependen por completo de la clave. De acuerdo con esta definición, cada afinidad que tiene un atributo único como clave, esta en segunda forma normal. La clave es solo un atributo, en forma predeterminada, cada atributo que no es clave depende por completo de la clave; no puede haber dependencias parciales. La segunda forma normal solo hace referencia a afinidades con claves compuestas. La afinidad ACTIVIDADES una vez aplicada la segunda forma normal quedaría: AFINIDAD ESTU-ACT CLAVE: SID SID 100 150 175 200

ACTIVIDAD ESQUI NATACION SQUASH NATACION

ACT-COST CLAVE:ACTIVIDAD ACTIVIDAD ESQUI NATACION SQUASH

CUOTA 200 50 50

4.3 TERCERA Y FORMAL NORMAL DE BOYCE-CODD TERCERA FORMA NORMAL.- Las afinidades en la segunda forma normal también tienen anomalías. Considerando la afinidad VIVIENDA de la siguiente figura. La clave es SID y las dependencias funcionales son SID Edificio y Edificio Cuota. Estas dependencias surgen porque cada estudiante vive en un edificio y cada edificio tiene una cuota. Cada estudiante que vive en Randolph Hall paga $1200 por trimestre. SID EDIFICIO CUOTA 100 RANDOLPH 1200 150 INGERSOLL 1100 200 RANDOLPH 1200 250 PITKIN 1100 300 RANDOLPH 1200 Debido a que SID determina Edificio y Edificio determina cuota. Indirectamente SID Cuota. Un arreglo de dependencias funcionales como este se denomina una dependencia transitiva, ya que SID determina Cuota por medio del atributo Edificio. Por esta dependencia transitiva, SID es la clave y la afinidad esta en segunda forma normal. A pesar de esto vivienda tiene anomalías. Para eliminar las anomalías de una afinidad en segunda forma normal, debe quitarse la dependencia transitiva, lo que conduce a la definición de una tercera forma normal: Una afinidad está en tercera forma normal si está en segunda forma normal y no tiene dependencias transitivas. La afinidad vivienda puede dividirse en dos afinidades en tercera forma normal. SID 100 150 200 250 300

EDIFICIO RANDOLPH INGERSOLL RANDOLPH PITKIN RANDOLPH

EDIFICIO RANDOLPH INGERSOLL PITKIN

CUOTA 1200 1100 1100

44

FORMA NORMAL DE BOYCE-CODD Incluso las afinidades en tercera forma normal pueden tener anomalías. Considere la siguiente afinidad ASESOR. Suponga que los requerimientos que sustentan esta afinidad son que un estudiante (SID), pueda tener una ó más especialidades, una especialidad puede tener varios miembros de la facultad (nombreF) como consejeros, y un miembro de la facultad (nombreF), sólo imparte asesoría en una área de especialidad.

SID 100 150 200 250 300 300

ESPECIALIDAD MATEMATICAS PSICOLOGIA MATEMATICAS MATEMATICAS PSICOLOGIA MATEMATICAS

NOMBREF CAUCHY JUNG RIEMANN CAUCHY PERLS RIEMANN

Puesto que los estudiantes pueden tener varias especialidades, SID, no determina la especialidad. Como los estudiantes pueden tener varios asesores, SID tampoco determina nombre F. SID por si mismo no puede ser una clave. La combinación (SID, especialidad) determina nombre F y la combinación (SID, nombre F), determina especialidad. Cualquiera de las combinaciones puede ser una clave. Dos ó mas atributos o conjuntos de atributos que puedan ser una clave, se denominan claves candidatas. Cualquiera de las candidatas que se seleccione para ser la clave se denomina clave primaria. ASESOR está en primera forma normal. También está en segunda forma normal, pues cualquier atributo que no es clave depende de toda la clave (sin importar cual clave candidata se seleccione). También está en tercera forma normal porque no tiene dependencias transitivas. A pesar de todo esto tiene anomalías por modificación. Suponga que estudiante 300 deja la escuela, si quita la tupla de estudiante 300 se perderá el hecho de que Perls imparte asesoría en psicología. Ésta es una anomalía de eliminación. En forma similar ¿Cómo se almacena el hecho de que Keynes asesor en economía? No es posible, hasta que un estudiante se inscribe en tal materia. Esta es una anomalía de inserción. Situaciones como la anterior conducen a la definición de la forma normal de Boyce-Codd (BCNF): Una afinidad está en BCNF si cada determinante es una clave candidata. ASESOR no está en BCNF puesto que tiene un determinante, nombre F, que no es una clave candidata. ASESOR puede descomponerse en dos afinidades que no tengan anomalías. ESTU-ASE (SID, NOMBREF) SID 100 150 200 250 300 300

NOMBREF CAUCHY JUNG RIEMANN CAUCHY PERLS RIEMANN

ASE-MATERIA (NOMBREF,MATERIA) NOMBREF CAUCHY JUNG RIEMANN PERLS

MATERIA MATEMATICAS PSICOLOGIA MATEMATICAS PSICOLOGIA

4.4 CUARTA Y QUINTA FORMA NORMAL CUARTA FORMA NORMAL Considere usted la afinidad ESTUDIANTE que muestra la relación entre estudiantes, especialidades y actividades. Suponga que los estudiantes pueden inscribirse en varias especialidades y participar en diversas actividades. La única clave es la combinación de los atributos (SID, Especialidad, Actividad). La estudiante 100 tiene su especialidad

45 en Música y Contabilidad y también participa en Natación y Tenis. El estudiante 150 sólo tiene especialidad en Matemáticas y participa en Carrera. ESTUDIANTE(SID, ESPECIALIDAD, ACTIVIDAD) SID 100 100 100 100 150

ESPECIALIDAD MUSICA CONTABILIDAD MUSICA CONTABILIDAD MATEMATICAS

ACTIVIDAD NATACION NATACION TENIS TENIS CARRERA

¿Cuál es la relación entre SID y especialidad? No es una dependencia funcional porque los estudiantes pueden tener distintas especialidades. Un valor único de SID puede poseer muchos valores de Especialidad. Esto también se aplica a la relación entre SID y Actividad. Tal dependencia por atributos de denomina dependencia de valores múltiples. Las dependencias de valores múltiples conducen a anomalías de modificación. Observe la redundancia en datos de la figura. La estudiante 100 tiene cuatros registros, cada uno de los cuales muestra una de sus especialidades junto con una de sus actividades. Si los datos se almacenaran con menos hileras: si hubiera sólo dos tuplas, uno para música y natación y uno para contaduría y tenis, las implicaciones serían engañosas. Parecería que la Estudiante 100 sólo nadó cuando tenía música como especialidad y jugó tenis sólo cuando tenía contaduría como especialidad. Esa interpretación no es lógica. Sus especialidades y sus actividades son independientes entre sí. Para prevenir tales engañosas conclusiones se almacenan todas las combinaciones de especialidades y actividades. Suponga que, debido a que la Estudiante 100 decide apuntarse en Esquí, se debe agregar la tupla (100, MÚSICA, ESQUÍ), como en la figura. La afinidad en este punto indica que la Estudiante 100 esquía cuando estudia música, pero no cuando tiene contaduría como especialidad. A fin de mantener la consistencia en los datos, se debe agregar una hilera para cada uno de una de sus actividades ligadas con Esquí. También se debe agregar la hilera) (100, CONTABILIDAD, ESQUÍ), como en la figura. Ésta es una anomalía de actualización: hay que hacer demasiadas actualizaciones para realizar un cambio en los datos. ESTUDIANTE(SID, ESPECIALIDAD, ACTIVIDAD) SID ESPECIALIDAD ACTIVIDAD 100 MUSICA ESQUI 100 CONTABILIDAD ESQUI 100 MUSICA NATACION 100 CONTABILIDAD NATACION 100 MUSICA TENIS 100 CONTABILIDAD TENIS 150 MATEMATICAS CARRERA Existe una dependencia de valores múltiples cuando una afinidad tiene al menos tres atributos, dos de los cuales poseen valores múltiples y sus valores dependen sólo del tercer atributo. En otras palabras en la afinidad 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 especialidad, y SID determina valores múltiples de Actividad, pero Especialidad y Actividad son independientes entre sí. Observe otra vez la figura. Vea cómo están escritas las dependencias de valores múltiples: SID Especialidad y SID Actividad. Esto se lee "SID multidetermina Especialidad, y SID multidermina Actividad". Esta afinidad está en BCNF (2NF porque todo es clave; 3NF porque no tiene dependencias transitivas; y BCNF porque no tiene determinantes que no son claves). Hemos visto que posee anomalías: si un estudiante toma otra especialidad, se debe ingresar un tuple para la nueva especialidad, y juntarlo con cada una de las actividades del estudiante. Sucede lo mismo si un estudiante se inscribe en una nueva actividad. Si un estudiante deja una especialidad se deben eliminar cada uno de los registros que contienen tal materia. Si participa en cuatro actividades, habrá cutro tuples que contengan la especilidad que ha dejado y deberá borrarse cada uno. Para evitar tales anomalías, se deben las dependencias de valores múltiples. Esto se hace construyendo dos afinidades, donde cada una almacena datos para solamente uno de los atributos de valores múltiples. La afinidades resultantes no tienen anomalías. Ellas son ESTU-ESPECIALIDAD (SID, Especialidad) y ESTU-ACT (SID, Actividad).

46 A partir de estas observaciones, se define la cuarta forma normal: Una afinidad está en cuarta forma normal si está en BCNF y no tiene dependencias de valores múltiples. Quedaria de la siguiente manera: ESTU-ESPECIALIDAD (SID, ESPECIALIDAD) SID ESPECIALIDAD 100 MUSICA 100 CONTABILIDAD 150 MATEMATICAS

ESTU-ACT (SID, ACTIVIDAD) SID 100 100 100 150

ACTIVIDAD ESQUI NATACION TENIS CARRERA

QUINTA FORMA NORMAL La quinta forma normal se refiere a dependencias que son extrañas. Tiene que ver con afinidades que pueden dividirse en subafinidades (como se ha venido haciendo), pero que no pueden reconstruirse. La condición bajo la cual surge esta situación, no tiene significado intuitivo preciso. No se sabe cuáles son las consecuencias de tales dependencias, incluso si tienen consecuencias prácticas. Para más información acerca de la quinta forma normal, consulte la investigación de Date citada antes en este capítulo. Cada una de las formas normales que se han analizado, fueron identificadas por investigadores que encontraron anomalías de modificación con afinidades en la segunda forma normal condujeron a la definición de la tercera forma normal. Aunque cada forma normal resolvía algunos de los problemas identificados con la forma normal anterior, nadie podía saber cuáles problemas todavía no habías sido identificados. Cada paso, se avanzaba a una definición estructurada de las bases de datos, nadie podía garantizar que no se encontarían más anomalías. En la siguiente sección se estudia una forma normal que garantiza que no habrá anomalías de ningún tipo. Cuando se ponen las afinidades en esa forma, se sabe que no pueden ocurrir ni siquiera las extrañas anomalías asociadas con la quinta forma normal. 4.5 OTROS ENFOQUES HACIA EL DISEÑO DE BASES DE DATOS Considerando la base de datos de la siguiente figura, se muestra una relación info-préstamo descompuesta en FNRP. En dicha base de representa una situación en la cual aún no se ha determinado el importe del préstamo P-58. pero se quiere grabar el resto de los datos del préstamo. Si ejecutamos la reunión natural de estas relaciones, todas la tuplas que se refieren al préstamo P-58 desaparecen. En otras palabras. No hay una relación info-préstamo que se corresponda con las relaciones de la figura. Las tuplas que desaparecen cuando se ejecuta la reunión natural son tuplas colgantes. Formalmente, sean r1 (R1) , r2 (R2) ,..., rn(Rn) un conjunto de relaciones. Una tupla t de la relación ri es una tupla colgante si t no está en la relación. La forma normal de reunión por proyección (FNRP) se define de la forma similar a la FNBC y 4FN, salvo que se usan las dependencias de reunión. Un esquema de relación R esta en FNRP respecto a un conjunto D dependencias funcionales, multivaloradas y de reunión si para toda dependencia de reunión perteneciente a D de la forma * (R1, R2,...,RN), donde casa R1 R y R = R1 U R2 ... U Rn, se cumple al menos una de las siguientes condiciones:

 

* (R1, R2,...,RN) es una dependencia de reunión. Cada Ri es una superclave de R.

Un diseño de base de datos está en FNRP si cada miembro del conjunto de esquemas de relación que constituye el diseño está en FNRP. Alguno autores denominan también quinta forma normal (5FN) a la FNRP. Descomposición en FNRP.

47 NOMBRE-SUCURSAL COLLADO MEDIANO

NUMERO-PRÉSTAMO P-58

NUMERO-PRESTAMO

IMPORTE

NUMERO-PRESTAMO P-58

NOMBRE-CLIENTE GONZALEZ

Las tuplas colgantes se pueden dar en aplicaciones prácticas de bases de datos. Representan información incompleta, como se vio en el ejemplo, donde se quiere almacenar datos sobre un préstamo que aún esta en proceso de negociación. A la relación r1 reunión natural con r2 se le llama relación universal, ya que involucra todos los atributos del universo definido por R1 U R2 U...U Rn. El único modo de que se puede escribir una relación universal para el ejemplo anterior, es incluir valores nulos en la relación universal. Debido a la dificultad para manejar valores nulos, puede ser mejor considerar las relaciones del diseño descompuesto como representantes de la base de datos, en vez de la relación universal cuyo esquema se descompone durante el proceso de normalización. Nótese que se puede introducir toda la información incompleta en la base de datos. Sin recurrir al uso de valores nulos. Por ejemplo, no se puede introducir un número de préstamo a menos que no se sepa algo de lo siguiente:

  

El nombre del cliente. El nombre de la sucursal. El importe del préstamo.

Por tanto, una descomposición particular define una forma restringida de la información incompleta que es aceptable en la base de datos. Las formas normales que se definieron generan buenos diseños de bases de datos desde el punto de vista de la representación de información incompleta. Si se permiten tuplas colgantes en la base de datos, puede ser preferible tomar una vista alternativa del proceso de diseño de bases de datos. Un lugar de descomponer una relación universal, se puede sintetizar una serie de esquemas en forma normal a partir de un conjunto de atributos dados. Otra consecuencia de este enfoque de diseño de bases de datos es que los nombres de los atributos deben ser únicos en la relación universal. No se puede usar nombre para referirse a nombre-cliente y nombre-sucursal. Sin embargo, en un lenguaje como SQL no hay operaciones de reunión natural, por lo que en una consulta que incluya a préstamo-sucursal y préstamo-cliente se debe eliminar la ambigüedad en las referencias a nombre poniendo como prefijo el nombre de la relación. En estos entornos, los diversos significados de nombre son menos problemáticos y se pueden usar fácilmente. El uso del supuesto de papel único es generalmente preferible a reutilizar el mismo nombre para varios atributos. Cuando no se cumple el supuesto del papel único, el diseñador de la base de datos debe tener un cuidado especial al construir un diseño normalizado de la base de datos relacional.

UNIDAD V. MODELO DE DATOS DE RED 5.1 CONCEPTOS BÁSICOS.

48 Una base de datos de red como su nombre lo índica, esta formado por una colección de registros, los cuales están conectados entre sí por medio de enlaces. El registro es similar a una entidad como las empleadas en el modelo entidad-relación. Un registro es una colección de campos (atributos), cada uno de los cuales contiene solamente almacenado un solo valor, el enlace es la asociación entre dos registros exclusivamente, así que podemos verla como una relación estrictamente binaria. Para mostrar la estructura de los registros en una base de datos de red, consideremos la base de datos alumnomateria, los registros en lenguaje Pascal entonces quedarían como sigue: type alumno=record NombreA:string[30]; Control:string[8]; Esp: string[3]; end;

type materia = record Clave:string[7]; NombreM:string[25]; Cred=string[2]; end;

5.2 DIAGRAMAS DE ESTRUCTURA DE DATOS.

Un diagrama de estructura de datos es un esquema que representa el diseño de una base de datos de red. Este modelo se basa en representaciones entre registros por medio de ligas, existen relaciones en las que participan solo dos entidades(binarias) y relaciones en las que participan más de dos entidades (generales) ya sea con o sin atributo descriptivo en la relación. Los diagramas constan de dos componentes básicos: Rectángulos: representan a los campos del registro. Líneas: representan a los enlaces entre los registros. Un diagrama de estructura de datos de red, especifica la estructura lógica global de la base de datos; su representación gráfica se basa en el acomodo de los campos de un registro en un conjunto de celdas que se ligan con otro(s) registro(s), ejemplificaremos esto de la siguiente manera: Consideremos la relación alumno-cursa-materia donde la relación cursa no tiene atributos descriptivos:

49

Nombre

NomM

Control

Clave

Esp

Alumno

Creditos

Cursa

Materia

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

Cuando el enlace no tiene atributos descriptivos Caso 1. Cardinalidad Uno a Uno.

Registro Alumno Control

NombreA

Registro Materia Esp

Enlace

Clave

NombreM

Cred

Diagrama de estructura de datos Caso 2. Cardinalidad Muchos a uno.

Registro Alumno Control

NombreA

Registro Materia Esp

Clave Enlace

Diagrama de estructura de datos Caso 3. Cardinalidad Muchos a muchos.

NombreM

Cred

50

Registro Alumno Control

Registro Materia

NombreA

Esp

Clave

NombreM

Cred

Enlace Diagrama de estructura de datos Cuando el enlace tiene atributos descriptivos. Consideremos que a la relación cursa le agregamos el atributo Cal (calificación), nuestro modelo E-R quedaría de la siguiente manera:

Nombre

NomM

Cal Control

Clave

Esp

Alumno

Creditos

Cursa

Materia

La forma de convertir a diagramas de estructura de datos consiste en realizar lo siguiente: 1. Realizar la representación de los campos del registro agrupándolos en sus celdas correspondientes. 2. Crear nuevo registro, denominado Calif, para este caso, con un solo campo, el de cal (calif). 3. Crear los enlaces indicando la cardinalidad de : AluCal, del registro Calif al registro Alumno. MatCal, del registro Calif al registro Materia. AluCal y MatCal son solo los nombres que emplearemos para identificar el enlace, pueden ser otros y no son empleados para otra cosa. Los diagramas se transforman en: Caso 1. Cardinalidad uno a uno.

de

estructuras

de

datos

según

la

cardinalidad

51

Registro Alumno Control

NombreA

Registro Materia Esp

Clave

AluCal

NombreM

Cred

MatCal Cal Registro Calif

Diagrama de estructura de datos

Caso 2. Cardinalidad Uno a muchos.

Registro Alumno Control

NombreA

Registro Materia Esp

Clave

NombreM

Cred

MatCal

AluCal Cal Registro Calif Diagrama de estructura de datos

Caso 3. Cardinalidad Muchos a muchos.

Registro Alumno Control

NombreA

Registro Materia Esp

Clave

AluCal

NombreM

MatCal Cal Registro Calif

Diagrama de estructura de datos

DIAGRAMAS DE ESTRUCTURA DE DATOS CUANDO INTERVIENEN MÁS DE DOS ENTIDADES Y EL ENLACE NO TIENE ATRIBUTOS DESCRIPTIVOS.

Cred

52 Consideremos que a la relación alumno-cursa-materia le agregamos la entidad maestro, quien es el que imparte dicha materia. Nuestro diagrama E-R quedaría de la siguiente manera:

Nombre

NomM

Control

Clave

Esp

Alumno

Creditos

Cursa

Materia

Maestro RFC

NoEmp Nombre

Plaza

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

1.Crear

los

respectivos registros

para

cada

una de

las

entidades

que intervienen

en

el

modelo.

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

Registro Alumno NombreA

Control

Registro Maestro Esp

NoEmp

Nombre

Registro Materia Plaza

RFC

NombreA

MaRenl MRenl

ARenl Renlace Diagrama de estructura de datos

Clave

Cred

53 Ahora si nuestro enlace tuviera atributos descriptivos, se crea el registro con los campos respectivos y se liga indicando el tipo de cardinalidad de que se trate. En este caso tomamos el ejemplo anterior con cardinalidad uno a uno y le agregamos a la relación el atributo calif. (calificación).

Registro Alumno NombreA

Control

Registro Maestro Esp

NoEmp

Nombre

Registro Materia Plaza

RFC

NombreA

Clave

Cred

MaeCur ACur

Calif

MatCur

Diagrama de estructura de datos

5.3

EL MODELO CODASYL DBTG.

Este modelo fue desarrollado en 1971 por un grupo conocido como CODASYL: Conference on Data System Languages, Data Base Task Group, de ahí el nombre; este comité es mejor conocido por haber sido el grupo que desarrolló los estándares para COBOL.El modelo CODASYL ha evolucionado durante los últimos años y existen diversos productos DBMS orientados a transacciones que se basan sobre el, sin embargo hoy día, estos productos están en declinación, ya que este modelo es complejo y no cohesivo; los diseñadores y programadores deben de tener mucho cuidado al elaborar bases de datos y aplicaciones DBTG, además este modelo tiene mucho enfoque de COBOL, gran parte a las deficiencias detectadas en la actualidad se le atribuye a que este modelo fue desarrollado muy pronto antes de que se establecieran correctamente los conceptos esenciales de la tecnología de bases de datos. La historia del modelo CODASYL es compleja. Se desarrollaron tres versiones distintas y, aunque el modelo de datos fue sometido dos veces a la consideración del American Nartional Standards Institute (ANSI) como una norma nacional, jamás fue aceptado. En su lugar, en agosto de 1986, se reconoció como el estándar nacional de base de datos el modelo relacional SQL. Las funciones y características básicas de las tres versiones del modelo CODASYL son iguales. La mayor parte de los productos DBMS comerciales basados en este modelo se basan en la primera, desarrollada en 1971. Los modelos posteriores de 1978 y 1981 modificaron parte del lenguaje y la sintaxis, agregaron características de soporte para la definición de restricciones e incluyeron otras modificaciones. En el modelo DBTG solamente pueden emplearse enlaces uno a uno y uno a muchos. En este modelo existen dos elementos principales que son el dueño y el miembro, donde solo puede existir un dueño y varios miembros, donde cada miembro depende solamente de un dueño. Para mejor entendimiento de este modelo ilustremos el siguiente: Empleando el ejemplo de la relación Alumno-cursa-Materia. Si la relación es uno a muchos sin atributos descriptivos, entonces el diagrama de estructura de datos apropiado es:

54

Registro Alumno Control

NombreA

Registro Materia Esp

Clave

NombreM

Cred

Enlace Diagrama de estructura de datos

Si la relación tiene un atributo descriptivo, como el de calif, entonces el diagrama de estructura de datos apropiado es:

Registro Alumno Control

NombreA

Registro Materia Esp

Clave

AluCal

NombreM

Cred

MatCal Cal Registro Calif

Diagrama de estructura de datos

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

Registro Alumno Control

NombreA

Registro Materia Esp

Clave

AluCal

MatCal Reenlace

Diagrama de estructura de datos

NombreM

Cred

55 En el caso de las relaciones generales (es decir, no binarias), el algoritmo de transformación es el mismo empleado para el estructurado de los diagramas de los modelos de red donde intervienen más de 2 entidades.

Por ejemplo consideremos la agregación de la entidad siguiente:

Registro Alumno NombreA

Control

maestro, entonces para este caso resulta la estructura

Registro Maestro Esp

NoEmp

Nombre

Registro Materia Plaza

RFC

NombreA

Clave

Cred

MaRenl MRenl

ARenl Renlace Diagrama de estructura de datos

Conjuntos DBTG Como se mencionó anteriormente en este modelo solo pueden utilizarse enlaces muchos a uno y uno a uno, así un diagrama de estructura de datos en forma general de este modelo sería:

A

B Conjunto DBTG En el modelo DBTG, esta estructura de denomina conjunto DBTG. El nombre que se le asigna al conjunto generalmente es el mismo que el de la relación que une a las entidades. En todo conjunto DBTG de este tipo, el tipo de registro A se denomina dueño (o padre) del conjunto, el tipo de registro B se le denomina miembro (o hijo) del conjunto. Cada conjunto DBTG puede tener cualquier numero de ocurrencias del conjunto. Puesto que no se permiten enlaces del tipo muchos a muchos, cada ocurrencia del conjunto tiene exclusivamente un dueño y cero o más registros miembros. Además ningún registro puede participar en más de una ocurrencia del conjunto en ningún momento. Sin embargo, un registro miembro puede participar simultáneamente en varias ocurrencias de diferentes conjuntos DBTG. Podemos ejemplificar las ocurrencias que se pueden presentar, como:

56

a1

b1

a2

b2

b3

b4

a3

b5

b6

Tres apariciones de un conjunto

5.4 RECUPERACIÓN DE DATOS EN DBTG El lenguaje de manipulación de datos de la propuesta DBTG consiste en un número de órdenes que se incorporan en un lenguaje principal. La mayor parte de los comandos de manejo de datos en DBTG de CODASYL tienen dos pasos. En primer lugar, se emite un comando FIND para identificar el registro sobre el cual se va a actuar. El comando FIND no lee, procesa el registro indicado; sólo identifica un registro para que lo localice el DBMS. Una vez identificado el registro, un segundo comando DML puede emitirse para que se lleve a cabo una operación sobre él. Patrones típicos son FIND, GET, o bien, FIND, MODIFY; o bien FIND, ERASE. Cuando el programa emite un comando FIND, se localiza un registro y su identidad permanece almacenada en una variable especial llamada indicador de posición. Después, cuando se emite un comando GET, MODIFY, ERASE o bien otro, el DBMS hace referencia al indicador de posición para determinar cuál es el registro sobre el que ha de actuar. Los indicadores de posición también se utilizan como puntos de referencia para los comandos del procesamiento secuencial como son FIND NEXT o FIND PRIOR. Las operaciones utilizadas para la recuperación de datos son: FIND: Que localiza a un registro en la base de datos y da valores a los punteros de actualidad correspondientes GET: Copia el registro al que apunta el actual de unidad de ejecución de la base de datos ala plantilla adecuada en el área de trabajo de programa.

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

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



El puntero actual de unidad de ejecución



El puntero de actualidad de tipo de registro que corresponde a .



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

57

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

alumno.nombre:="Juan Pérez"; find any alumno using nombrea; get alumno; print("alumno.control");

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

Que localiza al siguiente registro (según un orden que depende del sistema) que tiene el valor de .ejemplo: Alumno.NombreA:="Juan Pérez"; find any Alumno using NombreA; while DB-Status = 0 do begin get Alumno; print (Alumno.control); find duplicate Alumno using NombreA; end;

Se ha encerrado parte de la consulta en un ciclo while ya que no sabemos por adelantado cuántos nombres Juan Pérez pueden existir. Salimos del bucle cuando DB-Status<>0, esto indica que la última operación find duplicate falló, lo que implica que ya hemos agotado todos los registros con esos datos.

5.5 ACTUALIZACIÓN EN DBTG.

Creación de nuevos registros. La orden para crear un nuevo registro es:

58 Store Esta técnica nos permite crear y añadir solamente un registro a la vez. Para ejemplificar consideremos el caso siguiente: Deseamos registrar a un nuevo alumno de nombre "Rocío Veleta", la instrucción para esto es: Alumno.NombreA:="Rocío Veleta"; Alumno.control:="93551028"; Alumno.Esp:="LAE"; Store Alumno;

Modificación de un registro existente. Para realizar la modificación a los registros, primero se debe encontrar ese registro en la base de datos, pasarlo a la memoria principal y efectuar las modificaciones deseadas, posteriormente actualizamos el puntero de actualidad hacia el registro a modificar y ejecutamos la orden Modify. Modify Para que el sistema se entere que se va a realizar una modificación se emplea la orden for update. Ejemplo: Deseamos cambiar la Especialidad del alumno de nombre Rocío Veleta, por LI. Aumno.NombreA:="Rocío Veleta"; find for update any Alumno using nombreA; get Alumno.Esp :="LI"; modify Alumno; Las líneas de código antes descritas, primero requieren del dato por el cual se realizará la búsqueda del registro, la orden find for update any establecen el tipo de registro que se usara, using indica el campo por el cual debe buscar la coincidencia para la modificación, get se antepone la línea de modificaciones que se realizaran sobre el registro y finalmente ya que el registro fue modificado se ejecuta la instrucción modify para activar las actualizaciones ejecutadas.

Eliminación de registros. Para efectuar la eliminación de los registros es necesario tener el puntero de actualidad apuntando al registro que deseamos borrar, después se ejecuta al orden: erase

59 Esta instrucción al igual que la orden modify, requiere de la declaración de las instrucciones for update en la orden find. Ejemplo:Consideremos que deseamos eliminar el alumno cuyo número de control es 93551029 que pertenece al alumno Juan Pérez. Fin:=false; Alumno.NombreA:="Juan Pérez"; find any Alumno using NombreA; while DB-Status=0 and not fin do begin get Alumno; if Alumno.control=93551029 then begin erase Alumno;

fin:=true;

end

else find for update next Alumno with Alren1(*Registro reenlace*) end;

Es posible eliminar toda una secuencia de conjunto encontrando al dueño del mismo, para ello se ejecuta la orden: erase all Esto borrara al dueño del conjunto y a todos sus miembros, si un miembro de un conjunto dueño de otro conjunto, también se eliminaran los miembros de ese conjunto, esta operación es recursiva. Ejemplo: Consideremos que deseamos borrar al Alumno de nombre Juan Pérez. y todas sus registros de materias, entonces: Alumno.NombreA :="Juan Pérez"; find for update any Alumno using NombreA;

erase all Alumno;

5.6 PROCESAMIENTO DE CONJUNTOS EN DBTG.

* La sentencia de conexión (connect) Esta sentencia permite la inserción de un registro en un conjunto.

60 La sintaxis es: Connect tp La inserción de un registro nuevo se realiza creando el nuevo registro buscar el dueño(propietario) del conjunto en donde el puntero de actualidad apuntara a el lugar adecuado donde debe insertarse el nuevo registro y posteriormente insertamos el registro ejecutando la sentencia Connect. Ejemplo: Considérese la consulta DBTG para el modelo alumno-materia para crear el registro de un nuevo alumno en la materia Base de Datos.

Alumno.Control:=96552121; Alumno.NombreA:=’Armando Sánchez’; Alumno.Esp:=’ISC’; Store Alumno; Materia.Clave:=’SCB9333’; find any Materia using Clave; connect Alumno to AlRen1; (*Conectar el registro al reenlace *);

* Sentencia de desconexión Disconnect Esta sentencia se utiliza para "desconectar" a un registro de un conjunto, es necesario que los punteros de actualidad tanto del registro como del conjunto y del registro apunten a los elementos adecuados. posteriormente se elimina el registro deseado aplicando la sentencia Disconect. Sintaxis: Disconnect <Tipo registro> From <Tipo de conjunto> Esta operación solamente desconecta al registro no lo elimina de la base de datos para eliminarlo totalmente se utiliza la orden Erase. Sintaxis: Erase Sentencia de reconexión reconnect. La función permite mover un registro de un conjunto hacia oro conjunto, para ello se requiere encontrar el registro y el dueño apropiado. Sintaxis: reconnect to * Inserción y retención en conjuntos. Cuando se define un nuevo conjunto, debemos especificar cómo se van a insertar los registros miembros. Además de especificarse las condiciones bajo las cuales debe retenerse a un registro.

61 * Inserción en conjuntos. Un registro recién creado, del tipo registro de un tipo de conjunto puede añadirse a una ocurrencia de un conjunto manual o automáticamente. El modo se específica al definir el conjunto mediante la orden: Insertion is <modo de inserción> donde modo de inserción puede tomar los valores Manual y Automática mediante las siguientes ordenes: connect tp y store <Tipo registro> respectivamente. En ambos casos el puntero de actualidad del conjunto debe apuntar al conjunto sobre el cual se va a realizar la inserción. * Retención en conjuntos. Para que se logre la retención de miembros en un conjunto se realiza a través de una serie de restricciones que se especifican en el momento de definir el conjunto. Sintaxis: retention is <modo de retención> Donde modo de retención puede ser de tres formas: - Fija: Una vez insertado un registro miembro en un conjunto no podrá sacarse del conjunto. En caso de querer cambiar dicho registro primero se tendrá que eliminar el registro y volver a crearlo e insertarlo en el conjunto deseado. - Obligatoria: Permite la reconexión de registros miembros solo en conjuntos del mismo tipo. - Opcional: No tiene limitaciones. UNIDAD VI. MODELO DE DATOS JERÁRQUICO 6.1 CONCEPTOS BÁSICOS. Una base de datos jerárquica consiste en una colección de registros que se conectan entre sí por medio de enlaces. Los registros son similares a los expuestos en el modelo de red. Cada registro es una colección de campos (atributos), que contienen un solo valor cada uno de ellos. Un enlace es una asociación o unión entre dos registros exclusivamente. Por tanto, este concepto es similar al de enlace para modelos de red. A diferencia del enfoque de red, cuyas guías están impuestas por el comité CODASYL, el enfoque jerárquico no tiene normativa en la industria El punto a favor de los sistemas jerárquicos es que fueron los primeros que aparecieron totalmente desarrollados en el mercado. Los sistemas Information Management System (IMS) de IBM, es el DBMS jerárquico más conocido, es uno de los sistemas disponibles más grandes y complejos. Consideremos la base de datos, nuevamente, que contiene la relación alumno - materia de un sistema escolar. Existen dos tipos de registros en este sistema, alumno y materia. El registro alumno consta de tres campos: NombreA, Control y Esp; El registro Materia esta compuesto de tres campos: Clave, NombreM y Cred. En este tipo de modelos la organización se establece en forma de árbol, donde la raíz es un nodo ficticio. Así tenemos que, una base de datos jerárquica es una colección de árboles de este tipo. El contenido de un registro específico puede repetirse en varios sitios(en el mismo árbol o en varios árboles).

6.2 DIAGRAMAS DE ESTRUCTURA DE ÁRBOL

62 Los diagramas de estructura de árbol es la representación de un esquema de la base de datos jerárquica, de ahí el nombre, ya que un árbol esta desarrollado precisamente en orden descendente formando una estructura jerárquica. Este tipo de diagrama está formado por dos componentes básicos:



Rectángulos: que representan a los de registros.



Líneas: que representan a los enlaces o ligas entre los registros.

Un diagrama de árbol tiene el propósito de especificar la estructura global de la base de datos. Un diagrama de estructura de árbol es similar a un diagrama de estructura de datos en el modelo de red. La principal diferencia es que en el modelo de red los registros se organizan en forma de un grafo arbitrario, mientras que en modelo de estructura de árbol los registros se organizan en forma de un árbol con raíz. Características de las estructuras de árbol:



El árbol no puede contener ciclos.



Las relaciones que existen en la estructura deben ser de tal forma que solo existan relaciones muchos a uno o uno a uno entre un padre y un hijo.

NombreA

Control

Esp

Alumno

NombreM

Clave

Cred

Materia

Diagrama de estructura de datos En este diagrama podemos observar que las flechas están apuntando de padres a hijos. Un padre (origen de una rama) puede tener una flecha apuntando a un hijo, pero un hijo siempre puede tener una flecha apuntando a su padre. El esquema de una base de datos se representa como una colección de diagramas de estructura de árbol. Para cada diagrama existe una única instancia de árbol de base de datos. La raíz de este árbol es un nodo ficticio. Los hijos de ese nodo son instancias de los registros de la base de datos. Cada una de las instancias que son hijos pueden tener a su vez, varias instancias de varios registros. Las representaciones según las cardinalidades son: Consideremos la relación alumno-materia sin atributo descriptivo.

63

Nombre

NomM

Control

Clave

Esp

Alumno

Cursa

Materia

La transformación según las cardinalidades seria:



Cuando la relación es uno a uno.

NombreA

Control

Esp

Alumno

NombreM

Clave

Cred

Materia

Diagrama de estructura de datos 

Cuando la relación es uno a muchos.

NombreA

Control

Esp

Alumno

NombreM

Clave

Cred

Materia

Diagrama de estructura de datos 

Cuando la relación es muchos a uno.

Creditos

64

NombreM

Clave

Cred

Materia

NombreA

Control

Esp

Alumno

Diagrama de estructura de datos



Cuando la relación es muchos a muchos.

NombreM

Clave

Cred

Materia

NombreA

Control

Esp

Alumno

NombreA

Control

Esp

Alumno

NombreM

Clave

Cred

Materia

Diagrama de estructura de datos

Cuando la relación tiene atributos descriptivos, la transformación de un diagrama E-R a estructura de árbol se lleva a cabo cubriendo los siguientes pasos:

1.

Crear un nuevo tipo de registro.

2.

Crear los enlaces correspondientes.

Consideremos que a la relación Alumno-Materia añadimos el atributo Cal a la relación que existe entre ambas, entonces nuestro modelo E-R resulta: Añadir el diagrama E-R

Nombre

NomM

Cal Control

Clave

Esp

Alumno

Cursa

Creditos

Materia

65 Según las cardinalidades los diagramas de estructura de árbol pueden quedar de la siguiente manera:



Cuando la relación es uno a uno.

NombreA

Control

Esp

Alumno

Cred

Materia

Esp

Alumno

Cred

Materia

Cred

Materia

Esp

Alumno

Cal

NombreM

Clave

Diagrama de estructura de datos



Cuando la relación es uno a muchos.

NombreA

Control

Cal

NombreM

Clave

Diagrama de estructura de datos 

Cuando la relación es Muchos a uno.

NombreM

Clave

Cal

NombreA

Control

Diagrama de estructura de datos 

Cuando la relación es Muchos a Muchos.

66 Si la relación es muchos a muchos entonces la transformación a diagramas de árbol es un poco más compleja debido a que el modelo jerárquico solo se pueden representar las relaciones uno a uno o uno a muchos. Existen varias formas distintas de transformar este tipo de relaciones a estructura de árbol, sin embargo todas las formas constituyen la repetición de algunos registros. La decisión de qué método de transformación debe utilizarse depende de muchos factores, entre los que se incluyen:



El tipo de consultas esperadas en la base de datos.



El grado al que el esquema global de base de datos que se está modelando se ajusta al diagrama E-R dado. A continuación se describe la forma de transformar un diagrama E-R a estructura de árbol con relaciones muchos a muchos. Suponemos el ejemplo de la relación alumno-materia.

1.

Crear dos diagramas de estructura de árbol distintos T1 y T2, cada uno de los cuales incluye los tipos de registro alumno y materia, en el árbol T1 la raíz es alumno y en T2 la raíz es materia.

2.

Crear los siguientes enlaces:



Un enlace muchos a uno del registro cuenta al registro Alumno, en T1



Un enlace muchos a uno del tipo de registro cliente al tipo de registro materia en T2.

Como se muestra en el siguiente diagrama:

NombreA

Control

Esp

Alumno

NombreM

Cal

NombreM

Clave

Clave

Cred

Materia

Esp

Alumno

Cal

Cred

Materia

NombreA

Control

Diagrama de estructura de datos

6.3 RECUPERACIÓN DE DATOS Para manipular la información de una base de datos jerárquico, es necesario emplear un lenguaje de manipulación de datos, el lenguaje consta de varias órdenes que están incorporadas en un lenguaje principal, Pascal.

67 La orden Get: La recuperación de datos se realiza mediante esta orden, se realizan las siguientes acciones:



Localiza un registro en la base de datos y actualiza a un puntero que es el que mantiene la dirección del último registro accesado.



Copia los datos solicitados a un tipo de registro apropiado para la consulta.

La orden Get debe especificar en cual de los árboles de la base de datos se va a buscar. Para revisar todos los registros de forma consistente, se debe imponer un orden en los registros. El que normalmente se usa es el preorden, el cuál consiste en iniciar la búsqueda por la raíz y continua buscando por los subárboles de izquierda a derecha recursivamente. Así pues, empezamos por la raíz, visitamos el hijo más a la izquierda, y así sucesivamente, hasta que alcancemos un nodo hoja (sin hijos). A continuación movemos hacia atrás al padre de la hoja y visitamos el hijo más a la izquierda no visitado. Continuamos de esta forma hasta que se visite todo el árbol. Existen dos ordenes Get diferentes para localizar registros en un árbol de base de datos. La orden más simple tiene la forma: get first <Tipo de registro> where La cláusula where es opcional. La que se adjunta es un predicado que puede implicar a cualquier tipo de registro que sea un antecesor de o el <Tipo de registro> mismo. La orden get localiza el primer registro (en preorden) del tipo <Tipo registro> en la base de datos que satisfaga la de la cláusula where. Si se omite la cláusula where, entonces se localiza el primer registro del tipo <Tipo registro>. Una vez que se encuentra ese registro, se hace que el puntero que tiene la dirección del último registro accesado apunte a ese registro y se copia el contenido del registro en un registro apto para la consulta. Para ilustrar lo anterior veamos los ejemplos: Realicemos una consulta que imprima El nombre del alumno llamado Juan Pérez (consideremos la relación Alumno-Materia que hemos estado manejando.) get first Alumno where Alumno.NombreA="Juan Pérez"; print (Alumno.Control) Ahora consideremos que deseamos la consulta de los nombres de las materias en donde el alumno de nombre Juan Pérez a obtenido una calificación igual a 100 (si es que existe) get first Alumno where Alumno.NombreA="Juan Perez" and Cursa.cal= 100; if DB-Status=0 then print (Materia.NombreM); La condición involucra a la variable DB-Status, la cual nos indica si se encontró o no el registro. La orden get first, solo nos muestra el primer registro encontrado que satisfaga la orden de consulta, sin embargo puede haber más de ellos, para localizar a los demás registros empleamos la orden Get next.

68 Cuyo formato es: get next <Tipo de registro> where La cual localiza el siguiente registro en preorden que satisface la condición. Si se omite la cláusula where, entonces se localiza el siguiente registro del tipo <Tipo registro>.

6.4 ACTUALIZACIÓN DE DATOS. Creación de nuevos registros. La orden utilizada para la inserción de registros es:

insert where donde: tipo registro contiene los datos de los campos del registro a insertar. Sí se incluye la cláusula where, el sistema busca en el árbol de la base de datos (en preorden) un registro que satisfaga la condición dada, una vez encontrado, el registro creado se inserta en el árbol como un hijo más a la izquierda. Si se omite la cláusula where, el registro nuevo es insertado en la primera posición (en preorden) en el árbol de la base de datos donde se pueda insertar un registro del mismo tipo que el nuevo. Ejemplos: Consideremos que queremos añadir una nueva alumna cuyo nombre es Rocío Veleta con número de control 93551028 de la carrera de LI; entonces la inserción del nuevo registro seria de la siguiente manera: Aumno.NombreA:=Rocío Veleta"; Alumno.Control:="93551028"; Alumno.Esp:="ISC"; insert Alumno; Consideremos que deseamos crear la alta de la materia de matemáticas 1 a la alumna con número de control 99550168.

Materia.NombreM:="Matemáticas I"; Materia.Clave:="SCB9334"; Materia.Cred:=8; insert Materia; where Alumno.Control="99550168";

69 Modificación de registros existentes. La instrucción para efectuar cambios a los registros es: Replace Esta instrucción no requiere los datos del registro a modificar como argumento, el registro que se afectará será aquel al que este apuntando el puntero de actualidad, que debe ser el registro que se desea modificar. Ejemplo: Consideremos que deseamos reemplazar la carrera de la alumna con número de control 99550168.

Get hold first Alumno where Alumno.Control="99550168"; Alumno.Esp:="LI"; replace;

Se agrega la palabra hold para que el sistema se entere que se va a modificar un registro. Eliminación de un registro Para eliminar un registro se debe apuntar al puntero de actualidad hacia ese registro, después se ejecuta la orden delete, al igual que en la orden replace, se debe poner la orden Hold. Ejemplo: Consideremos que deseamos borrar al alumno con número de control 99550168.

Get hold first Alumno; Where Alumno.Control=’99550168’; delete;

También se puede borrar un registro(raíz), lo cuál eliminaría todas sus derivaciones (hijos). Ejemplo: Consideremos que deseamos eliminar al alumno con número de control 99550168 y todas sus materias, entonces la instrucción quedaría:

get hold first Alumno

70 where Alumno.Control="99550168"; delete;

6.5 REGISTROS VIRTUALES. En las relaciones muchos a muchos se requería la repetición de datos para conservar la organización de la estructura del árbol de la base de datos. La repetición de la información genera 2 grandes problemas:



La actualización puede generar inconsistencia de los datos.



Se genera un desperdicio considerable de espacio.

Para solventar estos problemas se introdujo el concepto de registro virtual, el cual no contiene datos almacenados, si no un puntero lógico a un registro físico determinado. Cuando se va a repetir un registro en varios árboles de la base de datos, se mantiene una sola copia de ese registro en uno de los árboles y empleamos en los otros registros la utilización de un registro virtual que contiene la dirección del registro físico original.

UNIDAD VII. BASE DE DATOS ORIENTADOS A OBJETOS. 7.1 CONCEPTOS DE ORIENTACION A OBJETOS La orientación a objetos puede describirse como el conjunto de disciplinas que desarrollan y modelizan software que facilitan la construcción de sistemas complejos a partir de componentes. El atractivo intuitivo de la orientación a objetos es que proporciona conceptos y herramientas con las que se modela y representa el mundo real tan fielmente como sea posible. Las ventajas de orientación a objetos son muchas en programación y modelación de datos. Las aplicaciones de las bases de datos en áreas como el diseño asistido por computadora, la ingeniería de software y el procesamiento de documentos no se ajustan al conjunto de suposiciones que se hacen para aplicaciones del estilo de procesamiento de datos. El modelo de datos orientado a objetos se ha propuesto para tratar algunos de estos nuevos tipos de aplicaciones. El modelo de bases de datos orientado a objetos es una adaptación a los sistemas de bases de datos. Se basa en el concepto de encapsulamiento de datos y código que opera sobre estos en un objeto. Los objetos estructurados se agrupan en clases. El conjunto de clases esta estructurado en sub y superclases basado en una extensión del concepto ISA del modelo Entidad - Relación. Puesto que el valor de un dato en un objeto también es un objeto, es posible representar el contenido del objeto dando como resultado un objeto compuesto. El propósito de los sistemas de bases de datos es la gestión de grandes cantidades de información. Las primeras bases de datos surgieron del desarrollo de los sistemas de gestión de archivos. Estos sistemas primero evolucionaron en bases de datos de red o en bases de datos jerárquicas y, más tarde, en bases de datos relaciónales.

71 Objetos El modelo orientado a objetos se basa en encapsular código y datos en una única unidad, llamada objeto. El interfaz entre un objeto y el resto del sistema se define mediante un conjunto de mensajes. Un objeto tiene asociado:



un conjunto de variables que contienen los datos del objeto. El valor de cada variable es un objeto. También llamados atributos.



Un conjunto de mensajes a los que el objeto responde cuando dicho mensajes son invocados.



Un método, que es un trozo de código para implementar cada mensaje. Un método devuelve un valor como respuesta al mensaje. El término mensaje en un contexto orientado a objetos, no implica el uso de un mensaje físico en una red de computadoras, si no que se refiere al paso de solicitudes entre objetos sin tener en cuenta detalles específicos de implementación. La capacidad de modificar la definición de un objeto sin afectar al resto del sistema está considerada como una de las mayores ventajas del modelo de programación orientado a objetos. Clases La clase es la construcción del lenguaje utilizada más frecuentemente para definir los tipos abstractos de datos en lenguajes de programación orientada a objetos. Generalmente, una clase se puede definir como una descripción abstracta de un grupo de objetos, cada uno de los cuales se diferencia por el estado específico y es capaz de realizar una serie de operaciones. En una base de datos existen objetos que responden a los mismos mensajes, utilizan los mismos métodos y tienen variables del mismo nombre y tipo. Sería inútil definir cada uno de estos objetos por separado por lo tanto se agrupan los objetos similares para que formen una clase, a cada uno de estos objetos se le llama instancia de su clase. Todos los objetos de su clase comparten una definición común, aunque difieran en los valores asignados a las variables. Así que básicamente las bases de datos orientados a objetos tienen la finalidad de agrupar aquellos elementos que sean semejantes en las entidades para formar un clase, dejando por separado aquellas que no lo son en otra clase. La orientación a objetos trata de cumplir las necesidades de los usuarios finales, así como las propias de los desarrolladores de productos de software. Estas tareas se realizan mediante la modelización del mundo real. El soporte fundamental es el modelo objeto. Los cuatro elementos más importantes de este modelo son:



Abstracción.



Encapsulación.



Modularidad



Jerarquía

Abstracción

72

La abstracción es uno de los medios más importantes mediante el cual nos enfrentamos con la complejidad inherente al software. La abstracción es la propiedad que permite representar las características esenciales de un objeto, sin preocuparse de las restantes. Una abstracción se centra en la vista externa de un objeto, de modo que sirva para separar el comportamiento esencial de un objeto de su implementación. Definir una abstracción significa describir una entidad del mundo real, no importa lo compleja que pueda ser. Encapsulación La encapsulación o encapsulamiento es la propiedad que permite asegurar que el contenido de la información de un objeto está oculta al mundo exterior, el objeto A no conoce lo que hace el objeto B y viceversa. La encapsulación, en esencia, es el proceso de ocultar todos los secretos de un objeto que no contribuyen a sus características esenciales. Modularidad La modularidad es la propiedad que permite subdividir una aplicación en partes más pequeñas llamadas módulos, cada una de las cuales debe ser tan independiente como sea posible de la aplicación en sí y de las partes restantes. Jerarquía La jerarquía es una propiedad que permite una ordenación de las abstracciones. Las dos jerarquías más importantes de un sistema complejo son: estructura de clases y estructura de objetos. Las clases en un sistema orientado a objetos se representan en forma jerárquica como en el diagrama anterior, así que las propiedades o características del elemento persona las contendrán (heredaran) los elementos alumno y maestro. Decimos que tanto la entidad Alumno y maestro son subclases de la clase persona este concepto es similar al utilizado en la de especialización (la relación ISA) del modelo E-R. Se pueden crear muchas agrupaciones (clases) para simplificar un modelo así que una jerarquía (en forma gráfica) puede quedar muy extensa, en estos casos tenemos que tener bien delimitados los elementos que intervienen en una clase y aquellos objetos que las heredan. Por ejemplo: Retomemos la relación alumno-cursa-materia agregándole la entidad maestro; donde los atributos considerados para cada uno son alumno: Nombre, Dirección, Teléfono, Especialidad, Semestre, Grupo; Maestro: Nombre, Dirección, Teléfono, Número económico, Plaza, RFC; Materia: Nombre, Créditos, Clave. Los atributos de nombre, dirección y teléfono se repiten en la entidad alumno y maestro, así que podemos agrupar estos elementos para formar la clase Persona con dichos campos. Quedando por separado en alumno: Especialidad, semestre, Grupo. Y en maestro: Número económico, Plaza y RFC; la materia no entra en la agrupación (Clase persona) ya que la clase específica los datos de solo personas, así que queda como clase materia.

7.2 MANEJO DE PERSISTENCIA, POLIFORMISMO Polimorfismo La quinta propiedad significativa de los lenguajes de programación orientados a objetos es el polimorfismo. Esta propiedad no suele ser considerada como fundamental en los diferentes modelos de objetos propuestos, pero, dada su importancia, no tiene sentido considerar un objeto modelo que no soporte esta propiedad. Polimorfismo es la propiedad que indica, literalmente, la posibilidad de que una entidad tome mucha formas. En términos prácticos, el polimorfismo permite referirse a objetos de clases diferentes mediante el mismo elemento

73 de programa y realizar la misma operación de diferentes formas, según sea el objeto que se referencia en ese momento. Persistencia Los objetos deber poder ser persistentes, es decir, que los objetos puede permanecer después de la ejecución del programa. La persistencia es una propiedad que determina cuando un objeto esta activo; esto quiere decir cuando esta vigente en memoria para ser utilizado. Cuando un objeto no esta en memoria deja de ser activo.

Consultas orientadas a objetos: Los lenguajes de programación orientados a objetos requieren que toda la interacción con objetos se realiza mediante el envío de mensajes. Consideremos el ejemplo de alumno-cursa-materia deseamos realizar la consulta de los alumnos que cursan la materia de Base de Datos 1, para realizar esta consulta se tendría que enviar un mensaje a cada instancia alumno Así un lenguaje de consultas para un sistema de bases de datos orientado a objetos debe incluir tanto el modelo de pasar el mensaje de objeto a objeto como el modelo de pasar el mensaje de conjunto en conjunto. Complejidad de Modificación. En base de datos orientados a objetos pueden existir los siguientes cambios:



Adición de una nueva clase: Para realizar este proceso, la nueva clase debe colocarse en la jerarquía de clase o subclase cuidando las variables o métodos de herencia correspondientes.



Eliminación de una clase: Se requiere la realización de varias operaciones, se debe de cuidar los elementos que se han heredado de esa clase a otras y reestructurar la jerarquía. En sí la estructuración de modelos orientados a objetos simplifica una estructura evitando elementos o variables repetidas en diversas entidades, sin embargo el precio de esto es dedicarle un minucioso cuidado a las relaciones entre las clases cuando en modelo es complejo, la dificultad del manejo de objetos radica en la complejidad de las modificaciones y eliminaciones de clases, ya que de tener variables que heredan otros objetos se tiene que realizar una reestructuración que involucra una serie de pasos complejos.

74

VIII. BIBLIOGRAFIA



Fundamentos de Bases de Datos Tercera Edición. Autores: Abraham Silberschatz, Henry F. Korth, S. SudarShan. Editorial Mc Graw Hill.



Procesamiento de Bases de Datos. Fundamentos, Diseño e Implementación. Quinta Edición. Autor: David M. Kroenke. Editorial: Prentice Hall.



Concepción y Diseño de Bases de Datos. Del Modelo E/R al Modelo Relacional Autores: Miguel Castaño, Mario Piattini. Editorial: Addison-Wesley Iberoamerica.



Sistemas de Bases de Datos. Administración y Uso. Autor: Alice Y. H. Tsai. Editorial: Prentice Hall



Programación Orientada a Objetos. Conceptos, modelado, diseño y codificación en C++. Autor: Luis Joyanes Aguilar Editorial: Mc Graw Hill.

75