Fundamentos de Base de Dato Ing 1

Fundamentos de base de datos
UNIDAD I CONCEPTOS DE BASE DE DATOS

1.1 Definicin de base de datos Antes del surgimiento de las computadoras, las organizaciones, desde sus inicios, han trabajado con bases de datos, rudimentarias quiz en cuanto a su almacenaje o acceso y que les servan para un mejor funcionamiento. Para entender mejor el concepto de base de datos, debemos empezar definiendo algunos trminos que se le relacionan: Dato. Caracterstica o atributo de un objeto, persona o cosa que por si solo no tiene ningn significado. Informacin. Conjunto de datos relacionados y organizados, pertenecientes a un objeto, persona o casa, tiles para quien los recibe. Informacin
Dato Dato Dato Dato Dato
Figura 1.1 Datos e Informacin Ejemplo Datos: O+ 345 Hepatitis 13/12/2007 Informacin: El paciente de la cama 345, hospitalizado el 13 de diciembre del 2007, tiene sangre tipo O+
Por lo tanto, dato informacin, mas bien puede decirse que un dato es la materia prima de la informacin. 1
Un sistema gestor o un sistema de gestin de base de datos, consiste en una coleccin de datos interrelacionados y un conjunto de programas para acceder a esos datos. La coleccin de datos interrelacionados es normalmente denominada base de datos. 1.2 Objetivos de las bases de datos El objetivo primordial de un sistema de bases de datos es proporcionar un entorno que sea a la vez conveniente y eficiente para ser utilizado al extraer y almacenar informacin de la base de datos de una manera prctica. Adems de esto, se pretende con estos sistemas resolver problemas de: Redundancia e inconsistencia de los datos.
La redundancia o repeticin excesiva de datos, aumenta los costos de almacenamiento y acceso. La inconsistencia consiste en que las diversas copias de los mismos datos no concuerdan entre s. Estos problemas se presentan debido a que los programas de aplicacin y archivos los crean diferentes programadores en el transcurso de un largo perodo de tiempo, es probable que los diversos archivos tengan estructuras diferentes y que los programas estn escritos en varios lenguajes de programacin diferentes. Dificultad para tener acceso a los datos.
Los entornos de procesamiento de archivos convencionales no permiten recuperar los datos necesarios de una forma prctica y eficiente. Imaginemos a la recepcionista del consultorio mdico buscando el expediente del paciente entre cientos de ellos y ms an, imaginemos al mdico leyendo cada una de sus anotaciones de aos anteriores hechas a dicho expediente. Esto puede complicarse todava mas, imagnate si el mdico encarga a su recepcionista obtener una lista de los pacientes que han padecido gripa en los ltimos 5 aos!. Deben desarrollarse por tanto, sistemas de recuperacin de datos ms adecuados para el uso general. Aislamiento de datos.
Los datos deben ser independientes de los programas de aplicacin necesarios para accederlos, as, si el programa se estropea los datos no sufren dao. Si un cajero automtico est fuera de servicio (programa de aplicacin), no significa que el dinero o saldo de una cuenta (datos) tambin est inaccesible.
Problemas de integridad.
Los valores de los datos deben cumplir con ciertos tipos de restricciones de consistencia. Por ejemplo, la cantidad de artculos vendidos no puede ser negativa. Los desarrolladores deben generar el cdigo necesario en los programas de aplicacin para evitar problemas de integridad en la base de datos. Problemas de atomicidad.
En las aplicaciones es crucial asegurar que si se produce algn fallo, los datos deben restaurarse al estado consistente que exista antes del fallo. Atmico significa que las transacciones de datos deben ocurrir en su totalidad o no ocurrir en absoluto. Si ocurre un apagn en medio de una transaccin sta no debe quedar a medias. Anomalas en el acceso concurrente.
Muchos sistemas permiten que mltiples usuarios no solo acceden sino que adems actualicen los datos simultneamente. Hoy en da , con el uso de internet, los principales sitios de comercio electrnico pueden tener millones de accesos diarios de compradores a sus datos. Esto puede dar lugar a datos inconsistentes. Para prevenir esta posibilidad, debe mantenerse alguna forma de supervisin en el sistema. Puesto que se puede acceder a los datos por medio de diversos programas de aplicacin diferentes que no han sido previamente coordinados, esta supervisin es muy difcil de proporcionar. Problemas de seguridad.
No todos los usuarios del sistema de base de datos deben poder acceder a todos los datos. Existe informacin que puede y debe ocultarse dependiendo del tipo de usuario de la base de datos. Estos, entre otros, son los problemas que intenta resolver un sistema de base de datos y por tanto forman parte de sus objetivos.
1.3 Usos y aplicaciones de las bases de datos Son mltiples y muy variadas las aplicaciones que puede tener un sistema de base de datos, sin importar el tamao de la empresa u organizacin. Algunas de las aplicaciones ms representativas pueden ser: Comercio electrnico: Para mantener existencias, precios de venta y compra, fletes y datos de sus clientes. Universidades: Para informacin acerca de sus estudiantes, historial acadmico y cursos. Banca: Para informacin de los clientes, cuentas, prstamos y transacciones bancarias. Bur de crdito: Muestra un informe detallado del historial crediticio de una persona fsica o moral. Telecomunicaciones: Para guardar un registro de las llamadas realizadas, generar facturas de servicios, mantener el saldo, almacenar informacin sobre las redes de comunicaciones. Produccin: Para la gestin de cadenas de proveedores, precios y para el seguimiento en la produccin de artculos, almacenes y pedidos. Recursos humanos: Para almacenar la informacin de los empleados, salarios, impuestos, retenciones, prestaciones sociales y generacin de nminas. Internet: Para almacenar sitios y ligas. Durante las ltimas cuatro dcadas del siglo XX, el uso de las bases de datos creci en todas las empresas, sobre todo los sistemas informticos basados en medios electrnicos de almacenamiento. Aunque en un principio muy pocas personas interactuaban directamente con los sistemas de bases de datos, hoy da la revolucin que ha trado consigo Internet, aument significativamente el acceso directo del usuario a las bases de datos. Las organizaciones convirtieron muchas de sus interfases telefnicas a las bases de datos en interfaces Web, y dejaron disponibles en lnea muchos servicios tales como las transferencias de saldos entre cuentas. As, aunque las interfaces de usuario ocultan los detalles del acceso a las bases de datos (como en un cajero automtico), y la mayora de la gente ni siquiera es consciente de que estn interactuando con una base de datos, el acceso a las bases de datos forma actualmente una parte esencial de la vida de casi todas las personas.
1.4 Arquitectura de base de datos

Programas de aplicacin que accesan a la base de datos
Programa 1
Programa 2
Programa n
Base de datos
Figura 1.2 Arquitectura general de una base de datos Instancias y Esquemas Instancia. Coleccin de informacin almacenada en la base de datos en un determinado momento en el tiempo. Esquema. Diseo global de la base de datos. Los esquemas se cambian muy raras veces o nunca.
El concepto de esquema de base de datos corresponde a la nocin de definicin de tipo en el lenguaje de programacin. Una variable de un tipo dado tiene un valor determinado en un instante de tiempo dado. As, el concepto del valor de una variable en los lenguajes de programacin corresponde al concepto de una instancia de un esquema de la base de datos. O puede asemejarse tambin con un archivero y los expedientes en l almacenados, el esquema o estructura, sera el archivero fsicamente y la instancia los expedientes ah contenidos, que pueden entrar o salir y cambiar la informacin almacenada en cierto momento. Los sistemas de bases de datos tienen varios esquemas, de acuerdo con los niveles de abstraccin, en el nivel ms bajo est el esquema fsico, en el intermedio el esquema conceptual y en el nivel ms alto el subesquema. Lenguajes de bases de datos Los sistemas de bases de datos proporcionan un lenguaje de definicin de datos para especificar el esquema de la base de datos y un lenguaje de manipulacin de datos para expresar las consultas y las modificaciones de la base de datos. En la prctica, los lenguajes de definicin y manipulacin de datos no son dos lenguajes diferentes; en cambio, simplemente forman parte de un nico lenguaje de bases de datos, como puede ser el muy usado SQL.
Lenguaje de definicin de datos (DDL o LDD). Un esquema de base de datos se especifica por medio de un conjunto de definiciones que se expresan mediante un lenguaje especial llamado lenguaje de definicin de datos. El resultado de la compilacin de sentencias de LDD es un conjunto de tablas las cuales se almacenan en un archivo especial llamado diccionario de datos o directorio. Un directorio de datos es un archivo que contiene metadatos, es decir, datos acerca de los datos. Este archivo se consulta antes de leer o modificar los datos reales en el sistema de bases de datos. La estructura de almacenamiento y los mtodos de acceso usados por los sistemas de bases de datos se especifican por medio de un conjunto de definiciones en un tipo especial de LDD llamado lenguaje de almacenamiento y definicin de datos. El resultado de la compilacin de estas definiciones es un conjunto de instrucciones que especifican los detalles de implementacin de los esquemas de bases de datos que normalmente se esconden a los usuarios. Lenguaje de manipulacin de datos (DML o LMD) Por manipulacin de datos debemos entender: o La recuperacin de informacin almacenada. o La insercin de informacin nueva en la base de datos. o La supresin o eliminacin de informacin de la base de datos. o La modificacin de datos almacenados en la base de datos. Un lenguaje de manipulacin de datos es un lenguaje que capacita a los usuarios a acceder o manipular datos segn estn organizados por el modelo de datos adecuado. Hay dos tipos: o Procedimentales, necesitan que el usuario especifique qu datos se necesitan y cmo obtener esos datos. o No procedimentales o declarativos, requieren que el usuario especifique qu datos se necesitan sin que haga falta que especifique cmo obtener esos datos. Los LMD no procedimentales o declarativos son mas sencillos de aprender y usar que los procedimentales. Sin embrago, como el usuario no tiene que especificar cmo conseguir los datos, el sistema de bases de datos tiene que determinar un medio eficiente de acceso a los datos.
Lenguaje de consultas Una consulta es una instruccin que solicita que se recupere informacin de la base de datos. La parte de un LMD que se encarga de la recuperacin de informacin se denomina lenguaje de consultas. Aunque tcnicamente sea incorrecto, resulta habitual usar las expresiones lenguaje de consultas y lenguaje de manipulacin de datos como sinnimas.
El procesador de consultas del sistema de bases de datos traduce las consultas LMD en secuencias de acciones en el nivel fsico del sistema de bases de datos.
1.4.1 Niveles de abstraccin de una base de datos Un objetivo importante de un sistema de base de datos es proporcionar a los usuarios una visin abstracta de los datos. Es decir, el sistema esconde ciertos detalles de cmo se almacenan y mantienen los datos. Sin embargo, para que el sistema sea manejable, los datos de deben extraer eficientemente. Este requerimiento ha llevado al diseo de estructuras de datos complejas para la representacin de datos en la base de datos. Puesto que muchos usuarios del sistema de base de datos no tienen experiencia en computadoras, se les esconde la complejidad a travs de diversos niveles de abstraccin para simplificar su interaccin con el sistema. Nivel fsico Es el nivel ms bajo de abstraccin, describe cmo se almacenan realmente los datos. En este nivel se describen a detalle las estructuras de datos complejas del nivel bajo. Nivel lgico Describe qu datos son realmente almacenados en la base de datos y las relaciones que existen entre los datos. Aqu se describe la base de datos completa en trminos de un nmero pequeo de estructuras relativamente sencillas. Aunque la implementacin de estas estructuras simples en el nivel lgico puede involucrar estructuras complejas del nivel fsico, los usuarios del nivel lgico no necesitan preocuparse de esta complejidad. Los administradores de la base de datos son quienes deben decidir la informacin que se guarda en la base de datos. Nivel de visin o vistas Describe solo parte de la base de datos completa. Muchos usuarios del sistema de base de datos no se interesarn por toda la informacin y menos por su estructura como en los niveles anteriores, quiz slo necesiten una parte de la base de datos. El nivel de abstraccin de vistas existe para simplificar su interaccin con el sistema. El sistema puede proporcionar muchas vistas para la misma base de datos.
vista 1
vista 2
vista n
Nivel lgico Nivel fsico
Figura 1.3 Los tres niveles de abstraccin
1.4.2 Independencia lgica y fsica de datos Luego de analizar los tres niveles de abstraccin en los que puede verse la base de datos, se dice que la capacidad de modificar una definicin de un esquema en un nivel sin afectar la definicin de un esquema en el nivel superior siguiente se llama independencia de datos. Existen dos niveles de independencia de datos: Independencia fsica de datos Es la capacidad de modificar el esquema fsico sin provocar que se vuelvan a escribir los programas de aplicacin. En algunas ocasiones son necesarias las modificaciones en el nivel fsico para mejorar el funcionamiento del sistema. Independencia lgica de datos Es la capacidad de modificar el esquema conceptual sin provocar que se vuelvan a escribir los programas de aplicacin. Las modificaciones en el nivel conceptual son necesarias siempre que se altera la estructura lgica de la base de datos. La independencia lgica de datos es ms difcil de lograr que la independencia fsica de datos, ya que los programas de aplicacin son fuertemente dependientes de la estructura lgica de los datos a los que acceden.
1.5 Estructura general de un sistema de base de datos 1.5.1 El gestor de la base de datos El gestor o manejador de la base de datos es un mdulo de programa que proporciona la interfaz necesaria entre los datos de bajo nivel almacenados en la base de datos y los programas de aplicacin y consultas hechos al sistema. El objetivo de un sistema de base de datos es simplificar y facilitar el acceso a los datos. Las vistas de alto nivel ayudan a lograrlo. No se debera cargar innecesariamente a los usuarios del sistema con los detalles fsicos de la implementacin del sistema. Un factor importante para la satisfaccin o insatisfaccin del usuario con un sistema de base de datos es su funcionamiento. Si el tiempo de respuesta para una solicitud es demasiado largo, el valor del sistema se reduce. El gestor de la base de datos es el responsable de las siguientes tareas: Interaccin con el gestor de archivos El gestor traduce las distintas sentencias DML a comandos del sistema de archivos de bajo nivel. El gestor de archivos es el verdadero responsable de la asignacin de espacio de almacenamiento de disco y las estructuras de datos usadas para representar la informacin almacenada en el disco. Implantacin de la integridad Los valores de los datos que se almacenan en la base de datos deben ser comprobados para que satisfagan las restricciones de consistencia e integridad. El gestor puede determinar si las actualizaciones a la base de datos dan como resultado la violacin de la restriccin; si es as, debe tomar la accin apropiada. Implantacin de la seguridad No todos los usuarios de la base de datos necesitan tener acceso a todo su contenido. El trabajo del gestor de la base de datos es hacer que se cumplan estos requisitos de seguridad. Copia de seguridad y recuperacin Como cualquier otro sistema mecnico o elctrico, un sistema informtico puede fallar (problemas de suministro de energa, ruptura de un disco, virus, errores de software). Esto puede ocasionar la prdida de informacin referente a la base de datos. Es responsabilidad del gestor de la base de datos detectar tales fallos y restaurar la base de datos al estado que exista antes de ocurrir el fallo. Control de concurrencia Es una tarea del gestor de la base de datos controlar la interaccin entre los usuarios concurrentes, ya que cuando varios usuarios actualizan la base de datos concurrentemente, es posible que no se conserve la consistencia de los datos.
1.5.2 Los usuarios de la base de datos Hay cuatro tipos diferentes de usuarios de los sistemas de bases de datos, diferenciados por la forma en que esperan interactuar con el sistema Programadores de aplicaciones Se les llama as a los profesionales informticos que interactan con el sistema escribiendo programas de aplicacin, sin importar entre las muchas herramientas para desarrollar las interfases del usuario que pueda utilizar. Usuarios sofisticados Interactan con el sistema sin escribir programas. En su lugar, formulan sus consultas en un lenguaje de consultas de base de datos. Cada una de estas consultas se remite al procesador de consultas, cuya funcin es tomar cada una de las sentencias escritas en DML o LMD en instrucciones que entienda el gestor de la base de datos. Usuarios especializados Son usuarios sofisticados que escriben aplicaciones de bases de datos especializadas que no encajan en el marco tradicional del procesamiento de datos (por ejemplo sistemas de diseo asistido por computadora, sistemas de bases de conocimientos o expertos, sistemas que almacenan datos con tipos complejos de datos como grficos o audio). Usuarios ingenuos o normales Interactan con el sistema invocando alguno de los programas de aplicacin que se han escrito previamente. Por ejemplo, un usuario que desea averiguar su saldo de su cuenta bancaria por Internet. Ese usuario puede acceder a un formulario en el que introduce su nmero de cuenta. Un programa de aplicacin en el servidor Web recupera entonces el saldo de la cuenta, usando el nmero de cuneta proporcionado, y devuelve la informacin al usuario. La interfaz de usuario habitual para los usuarios normales es una interfaz de formularios, donde el usuario puede rellenar los campos correspondientes del formulario. Los usuarios normales tambin pueden limitarse a leer informes generados por la base de datos. 1.5.3 El administrador de la base de datos (DBA o ABD) El administrador de la base de datos es la persona que tiene el control central sobre el sistema (sus datos y los programas que acceden a ellos). Sus funciones incluyen: Definicin del esquema Crea el esquema original de la base de datos mediante la escritura de un conjunto de definiciones que son traducidas por el compilador de DDL a un conjunto de tablas que son almacenadas permanentemente en el diccionario de datos.
10
Definicin de le estructura de almacenamiento y mtodo de acceso Cmo estn conformados cada uno de los archivos y cmo van a ser accedidos. Modificacin del esquema y de la organizacin fsica Realiza modificaciones en el esquema y en la organizacin fsica para reflejar las necesidades cambiantes de la organizacin, o para alterar la organizacin fsica a fin de mejorar el rendimiento. Concesin de autorizacin para el acceso a los datos El administrador puede y debe regular las partes de la base de datos a las que puede tener acceso cada usuario. Normalmente se generan niveles de acceso, sobre todo cuando hay grupos de usuarios con los mismos usos de la base de datos. La informacin de autorizacin se guarda en una estructura especial del sistema que el sistema gestor de la base de datos consulta siempre que alguien intenta tener acceso a los datos del sistema. Especificacin de las restricciones de integridad Las restricciones de integridad se mantienen en una estructura especial del sistema que consulta el gestor de la base de datos cada vez que tiene lugar una actualizacin en el sistema. Mantenimiento rutinario o Copia de seguridad peridica de la base de datos, ya sea sobre cinta o servidores remotos, con la finalidad de evitar la prdida de datos en caso de desastres o fallos. o Asegurarse de que se dispone de suficiente espacio libre en disco para las operaciones normales y aumentar el espacio en disco segn sea necesario. o Supervisar los trabajos que se ejecuten en la base de datos y asegurarse de que el rendimiento no se degrade debido a que algn usuario haya remitido tareas muy costosas.
11
1.5.4 El sistema de comunicacin entre los distintos componentes (APIs, midlewares, etc.) Una visin de de los diversos componentes de los sistemas de bases de datos y de las conexiones existentes entre ellos quedara as:
Usuarios normales (cajeros, agentes, usuarios Web) usa Interfaces de aplicaciones
Programadores de aplicaciones escribe Programas de aplicacin
Usuarios Sofisticados (analistas) usa Herramientas de consulta
Administrador de Bases de datos usa Herramientas de administracin
Compilador y enlazador Cdigo objeto de los programas de aplicacin Motor de evaluacin de consultas
Consultas LMD
Intrprete del LDD
Compilador del LMD y organizador Procesador de consultas
Gestor de memoria intermedia
Gestor de archivos
Gestor de autorizacin e integridad
Gestor de transacciones
Gestor de almacenamiento
datos
ndices Datos estadsticos
Diccionario de datos Almacenamiento en disco
Figura 1.4 Estructura de un sistema de bases de datos La arquitectura de los sistemas de bases de datos se ve muy influida por el sistema informtico subyacente sobre el que se ejecuta el sistema de bases de datos. Los sistemas de bases de datos pueden estar centralizados o ser del tipo cliente-servidor.
12
1.6 Arquitectura cliente/servidor Los sistemas de bases de datos de este tipo se llaman as porque una mquina servidora ejecuta el trabajo en nombre de multitud de mquinas cliente. Hoy en da la mayor parte de los usuarios de los sistemas de bases de datos no est presente en el lugar fsico en que se encuentra el sistema de bases de datos, sino que se conectan a l a travs de una red. Por tanto, se puede identificar entre los sistemas clientes, en los que trabajan los usuarios remotos de la base de datos y los sistemas servidores, en los que se ejecutan los sistemas de bases de datos. 1.6.1 Componentes de aplicaciones Las aplicaciones de bases de datos suelen dividirse en dos o tres partes:
usuario cliente aplicacin Cliente de aplicaciones usuario
red
red
Servidor de aplicaciones Sistema de bases de datos servidor Sistema de bases de datos
Arquitectura de dos capas
Arquitectura de tres capas
Figura 1.5 Arquitecturas de dos y tres capas 1.6.2 Funciones de componentes En una arquitectura de dos capas, la aplicacin se divide en un componente que reside en la mquina cliente, que llama a la funcionalidad del sistema de bases de datos en la mquina servidora mediante instrucciones del lenguaje de consultas. Los estndares de interfaces de programas de aplicacin como ODBC y JDBC se usan para la interaccin entre el cliente y el servidor. En cambio, en una arquitectura de tres capas, la mquina cliente acta simplemente como una parte visible al usuario y no contiene ninguna llamada directa a la base de datos. En vez de eso, el extremo cliente se comunica con un servidor de aplicaciones, generalmente mediante una interfaz de formularios. El
13
servidor de aplicaciones, a su vez, se comunica con el sistema de bases de datos para tener acceso a los datos. La lgica de negocio de la aplicacin, que establece las acciones que se deben realizar segn las condiciones reinantes, se incorpora en el servidor de aplicaciones, en lugar de estar distribuida entre mltiples clientes. Las aplicaciones de tres capas resultan ms adecuadas para aplicaciones de gran tamao y para las aplicaciones que se ejecutan en World Wide Web.
1.7 Componentes de un gestor de base de datos El gestor o manejador de la base de datos es un mdulo de programa que proporciona la interfaz entre los datos de bajo nivel almacenados en la base de datos y los programas de aplicacin y consultas hechas al sistema. En otras palabras, el gestor es el traductor, intrprete o intermediario entre el usuario y la base de datos. 1.7.1 Estructura general
Usuario
Usuario
Usuario
Gestor
Base de datos
Figura 1.6 Estructura general
14
1.7.2 Funciones Los sistemas de bases de datos estn divididos en mdulos que tratan con cada una de las responsabilidades del sistema general. Los componentes funcionales de los sistemas de bases de datos pueden dividirse en general en los componentes gestor de almacenamiento y procesador de consultas. Gestor de almacenamiento Es un mdulo de programa que proporciona la interfaz entre los datos de bajo nivel almacenados en la base de datos y los programas de aplicacin y las consultas remitidas al sistema. Es el responsable de la interaccin con el gestor de archivos. Los datos en bruto se almacenan en el disco mediante el sistema de archivos que suele proporcionar un sistema operativo convencional. El gestor de almacenamiento traduce las diferentes instrucciones LMD a comandos de bajo nivel del sistema de archivos. As, el gestor de almacenamiento es responsable del almacenamiento, la recuperacin y la actualizacin de los datos de la base de datos. Los componentes del gestor de almacenamiento son: Gestor de autorizaciones e integridad. Comprueba que se satisfagan las restricciones de integridad y la autorizacin de los usuarios para tener acceso a los datos. Gestor de transacciones. Garantiza que la base de datos quede en un estado correcto a pesar de los fallos del sistema, y que la ejecucin concurrente de transacciones transcurra sin conflictos. Gestor de archivos. Gestiona la asignacin de espacio de almacenamiento de disco y las estructuras de datos usadas para representar la informacin almacenada en el disco. Gestor de la memoria intermedia. Es responsable de traer los datos desde el disco de almacenamiento a la memoria principal y decidir los datos a guardar en la memoria cach. El gestor de la memoria intermedia es una parte fundamental de los sistemas de bases de datos, ya que permite que la base de datos maneje tamaos de datos que son mucho mayores que el tamao de la memoria principal.
El gestor de almacenamiento implementa varias estructuras de datos como parte de la implementacin fsica del sistema: Archivos de datos. Almacenan la base de datos en s misma. Diccionario de datos. Almacena metadatos, es decir datos acerca de la estructura de la base de datos. ndices. Proporcionan un acceso rpido a los elementos de datos. Facilitan punteros a los elementos de datos que tienen un valor concreto.
15
El procesador de consultas
Entre los componentes del procesador de consultas se encuentran: Intrprete del LDD. Interpreta las instrucciones del LDD y registra las definiciones en el diccionario de datos. Compilador del LMD. Traduce las instrucciones del LMD en un lenguaje de consultas a un plan de evaluacin que consiste en instrucciones de bajo nivel que entienda el motor de evaluacin de consultas. Las consultas se suelen poder traducir en varios planes de ejecucin alternativos, todos los cuales proporcionan el mismo resultado. El compilador del LMD tambin realiza optimizacin de consultas, es decir, elige el plan de evaluacin de menor costo entre todas las opciones posibles. Motor de evaluacin de consultas. Ejecuta las instrucciones de bajo nivel generadas por el compilador del LMD.
16
EJERCICIOS 1.1 Explicar la diferencia entre independencia fsica e independencia lgica de los datos. 1.2 Listar las responsabilidades del gestor de la base de datos. Para cada una de stas explique los problemas que surgiran si no se cumple con esta responsabilidad. 1.3 Cules son las funciones principales de un administrador de base de datos? 1.4 Cul es la diferencia entre instancia y esquema? 1.5 Menciona y explica tres problemas que intenta resolver un sistema de base de datos 1.6 Qu es una base de datos? 1.7 Menciona y explica los tipos de lenguajes de manipulacin de datos 1.8 Qu es un diccionario de datos? 1.9 Cmo funciona el gestor de almacenamiento? 1.10 Cules son los tipos de usuarios de una base de datos y que realiza cada uno? 1.11 1.12 1.13 1.14 Explica la diferencia entre dato e informacin Menciona y explica tres objetivos de las bases de datos Investiga tres casos en los que se utilice una base de datos Qu es la arquitectura cliente / servidor?
17
UNIDAD II MODELOS DE DATOS

2.1 Definicin de modelo de datos Para hacer ms entendible una base de datos, se utilizan modelos de datos, los cuales son una coleccin de herramientas conceptuales para describir los datos, sus relaciones, su semntica y las restricciones de consistencia. Los modelos de datos permiten un modo de describir el diseo o estructura de las bases de datos en los niveles fsico, lgico y conceptual o de vistas. Dentro de los modelos de datos ms comnmente usados estn: Modelo entidad relacin (E-R). Modelo relacional Modelo de datos orientado a objetos Modelo de datos semiestructurados
Para aplicaciones pequeas puede resultar factible para un diseador de bases de datos que comprenda los requisitos de la aplicacin decidir directamente sobre las relaciones que hay que crear, sus atributos y las restricciones sobre las relaciones. Sin embargo, un proceso de diseo tan directo resulta difcil para las aplicaciones reales, ya que a menudo son muy complejas. Frecuentemente no existe una sola persona que comprenda todas las necesidades de datos de la aplicacin. El diseador de la base de datos debe interactuar con los usuarios para comprender las necesidades de la aplicacin, realizar una representacin de alto nivel de esas necesidades que pueda ser comprendida por los usuarios y luego traducir esos requisitos a niveles inferiores de diseo. La fase inicial del diseo de las bases de datos es la caracterizacin completa de las necesidades de datos de los posibles usuarios de la base de datos. El diseador de la base de datos debe interactuar intensamente con los expertos y los usuarios del dominio para realizar esta tarea. El resultado de esta fase es una especificacin de requisitos del usuario. Luego el diseador elige el modelo de datos y, aplicando los conceptos de ste, traduce los requisitos en un esquema conceptual de la base de datos. El esquema desarrollado en esta fase de diseo conceptual proporciona una visin detallada de la empresa. Se suele emplear el modelo entidad relacin pare representar este diseo. El diseador revisa el esquema para confirmar que realmente se satisfacen todos los requisitos y que no entran en conflicto entre s. Tambin puede revisar el diseo para eliminar caractersticas redundantes. Su atencin en este momento se centra en describir los datos y sus relaciones ms que en especificar los detalles del almacenamiento fsico. En la siguiente etapa, que es la especificacin de requisitos funcionales, los usuarios definan los tipos de operaciones o transacciones que se llevarn a
18
cabo sobre los datos. En esta fase el diseador puede revisar el esquema para asegurarse de que satisface los requisitos funcionales. El proceso de paso desde el modelo abstracto de datos a la implementacin de la base de datos se divide en dos fases de diseo finales: 1. El diseo lgico en el que el diseador traduce el esquema conceptual de alto nivel al modelo de datos de la implementacin del sistema de bases de datos que se va a usar. El modelo de la implementacin de los datos suele ser el modelo relacional, y este paso suele consistir en la traduccin del esquema conceptual definido mediante el modelo entidad relacin en un esquema de relacin. 2. Finalmente, el diseador usa el esquema de base de datos resultante en la siguiente fase de diseo fsico, en la que se especifican las caractersticas fsicas de la base de datos, como la organizacin de los archivos y las estructuras de almacenamiento interno.
19
2.2 Modelo entidad relacin El modelo entidad relacin, comnmente conocido como E-R se basa en una percepcin del mundo real que consiste en una coleccin de objetos bsicos, denominados entidades, y las relaciones entre ellos. Una entidad es cualquier cosa u objeto del mundo real que es distinguible de otros objetos por sus atributos o caractersticas particulares. Este modelo suele utilizarse como un primer paso en el diseo de los esquemas de las bases de datos ya que facilita la especificacin de un esquema de la empresa que representa la estructura lgica global de la base de datos. El modelo E-R resulta muy til para relacionar los significados e interacciones de lasa empresas reales con el esquema conceptual. Este modelo emplea tres conceptos bsicos: Los conjuntos de entidades, los conjuntos de relaciones y los atributos stos componentes los expresa con figuras que forman lo que se conoce como diagrama E-R. 2.2.1 Entidades, atributos y relaciones
atributo s 124 7 132 4 115 6 123 4 854 6 Mar a Jua n Javie r Mar a Mnic a 4/09/197 2 8/08/197 1 17/09/197 4 18/03/197 5 3/05/197 0 alumno Informtic a Industria l Sistema s Industria l Sistema s atributo s 9 5 8 5 4 6 5 6 10 0
I I I I I
calificacin
Figura 2.1 Conjuntos de entidades alumno y calificacin Entidad. Una entidad es una cosa u objeto del mundo real que es distinguible de todos los dems objetos, ejemplo cada uno de los empleados de una empresa puede ser una entidad. Una entidad tiene un conjunto de propiedades o caractersticas y los valores de algn conjunto de estas propiedades pueden identificar de forma nica a una entidad de otra. Por ejemplo el nmero de empleado 1247 identifica de forma nica a un alumno de otro en una escuela.
20
Las entidades pueden ser concretas, como una persona o un auto, o abstractas como los prstamos o las vacaciones. Un conjunto de entidades es un conjunto de entidades del mismo tipo que comparten las mismas propiedades, atributos o caractersticas. El conjunto de todos los alumnos asignados a una materia, su fecha de nacimiento y carrera, por ejemplo, se puede definir como el conjunto de entidades alumno y el conjunto de entidades calificacin, puede resultar el conjunto de todas las calificaciones asignados a los alumnos. Cada una de las entidades que constituyen un conjunto se denomina extensin de ese conjunto de entidades. Por tanto, todos los alumnos del grupo son la extensin del conjunto de entidades grupo. Atributos. Cada entidad se representa mediante un conjunto de atributos. Los atributos son propiedades descriptivas que posee cada miembro de un conjunto de entidades. La designacin de un atributo para un conjunto de entidades expresa que la base de datos almacena informacin parecida relativa a cada entidad del conjunto de entidades; sin embrago, cada entidad puede tener su propio valor para cada atributo, lo que hace que una entidad se distinga de otra dentro del conjunto de entidades. Para cada atributo existe un rango de valores permitidos llamado dominio. Por tanto, las bases de datos incluyen una serie de conjuntos de entidades, cada una de las cuales contiene cierto nmero de entidades del mismo tipo. Relaciones. Una relacin es una asociacin entre varias entidades. Por ejemplo, se puede definir una relacin que asocie al alumno 1247 con la calificacin del periodo I. Un conjunto de relaciones del mismo tipo se le llama conjunto de relaciones. Este modelo, adems de entidades y relaciones, representa ciertas restricciones de asignacin a las que deben ajustarse los contenidos de una base de datos. Una restriccin importante se la cardinalidad de asignacin. 2.2.2 Llaves o claves Conceptualmente, las entidades individuales y las relaciones son distintas, pero, desde la perspectiva de una base de datos, la diferencia entre ellas debe expresarse en trminos de sus atributos. Es necesario tener una forma de especificar la manera de distinguir las entidades pertenecientes a un conjunto de entidades dado.
21
Los valores de una entidad deben ser tales que permitan identificar de forma nica a una entidad de otra. No se permite que ningn par de entidades de un conjunto de entidades tengan exactamente el mismo valor en todos sus atributos. Las claves permiten identificar de forma nica un conjunto de atributos que resulta suficiente para distinguir las entidades entre s. Superclave. Es un conjunto de uno o ms atributos, que, considerados conjuntamente, nos permiten identificar de forma nica a una entidad en el conjunto de entidades. Por ejemplo, al atributo nmero_de_control, del conjunto de entidades alumno, es suficiente para distinguir una entidad alumno de otra. Entonces nmero_de_control es una superclave. Anlogamente, la combinacin de nmero_de_control y nombre_de_alumno es una superclave para el conjunto de entidades alumno. El atributo nombre_del_alumno no es una superclave, ya que varias personas pueden tener el mismo nombre. El concepto de superclave no es suficiente para lo que aqu se propone, ya que, como se ha visto, las superclaves pueden tener atributos innecesarios. Si K es una superclave, entonces tambin lo es cualquier superconjunto de K. Claves candidatas. A menudo interesan las superclaves para las que ningn subconjunto propio es superclave. Estas superclaves mnimas se denominan claves candidatas. Es posible que conjuntos distintos de atributos puedan servir como clave candidata. Supngase que una combinacin de nombre de alumno y fecha de nacimiento sea suficiente para distinguir entre los alumnos del conjunto de entidades alumno. Entonces, tanto numero_de_control como nombre_de_alumno y fecha_de_nacimiento son claves candidatas. Aunque los atributos numero_de_control y nombre_de_alumno juntos puedan diferenciar las entidades alumno, su combinacin no forma una clave candidata, ya que el atributo numero_de_control por s solo es una clave candidata. Clave primaria. Es una clave candidata que elige el diseador de la base de datos como el medio principal de identificar entidades dentro de un conjunto de entidades.
22
2.2.3 Cardinalidad de las entidades en una relacin Expresa el nmero de entidades a las que otra entidad se puede asociar mediante un conjunto de relaciones. Para un conjunto binario de relaciones R entre los conjuntos de entidades A y B, la cardinalidad de asignacin debe ser una de las siguientes: Una a una. Una entidad en A est asociada a una sola entidad en B, y una entidad en B est asociada slo a una entidad en A.
a1 a2 a3 a4
b1 b2 b3 b4
Figura 2.2 Relacin una a una
Una a muchas. Una entidad en A est asociada con un nmero cualquiera de entidades en B. Una entidad en B, sin embargo, puede estar asociada slo con una entidad en A.
a1 a2
b1 b2 b3
a3 b4 b5
Figura 2.3 Relacin una a muchas
23
24
Muchas a una. Una entidad en A est asociada solo con una entidad en B. Sin embargo, una entidad en B, puede estar asociada con un nmero cualquiera de entidades en A.
a1 a2 a3 a4 a5 b1 b2 b3
Figura 2.4 Relacin muchas a una Muchas a muchas. Una entidad en A est asociada con un nmero cualquiera de entidades en B, y una entidad en B est asociada con un nmero cualquiera de entidades en A.
a1 a2 a3 a4
b1 b2 b3 b4
Figura 2.5 Relacin muchas a muchas La cardinalidad de asignacin adecuada depende del mundo real que el conjunto de relaciones est modelando
25
2.2.4 Dependencia de existencia y de identificacin Diagrama entidad-relacin La estructura lgica global de una base de datos puede representarse grficamente por medio de un diagrama E-R. Este diagrama consta de: Rectngulos, que representan conjuntos de entidades. Elipses, que representan atributos. Rombos, que representan conjuntos de relaciones. Lneas, que enlazan atributos a conjuntos de entidades y conjuntos de entidades a conjuntos de relaciones.
Sexo Nombr e N_contr ol Fecha_nac Periodo Hora Aula
Alumno
AlGr u
Grupo
Figura 2.6 Diagrama E-R Considrese este diagrama, consta de dos conjuntos de entidades, Alumno y Grupo, relacionados mediante un conjunto binario de relaciones AlGru (el nombre de una relacin no necesariamente debe ser una contraccin de las entidades que relaciona, solo se usa como ejemplo). Los atributos de Alumno son n_control, nombre, sexo y fecha_nac. Los atributos asociados a la entidad Grupo son hora y aula. El conjunto de relaciones AlGru, tiene tambin un atributo, periodo y adems este conjunto de relaciones puede ser una a una, una a muchas, muchas a una o muchas a muchas, para diferenciar el tipo de relacin se usa una flecha () como sigue: Una a una () Las cabezas de flechas apuntan a cada una de las entidades Una a muchas () Muchas a una () Muchas a muchas (--)
26
Note que la abertura de la flecha indica muchos, por el contrario, el vrtice indica uno. En el caso de la relacin muchos a muchos las cabezas de flecha se omiten. En la figura 2.6 vemos que el conjunto de relaciones AlGru es muchas a muchas. Si el conjunto de relaciones AlGru fuera una a muchas, entonces la lnea de AlGru a Alumno tendra direccin, con una flecha apuntando al conjunto de entidades Alumno
Sexo Nombr e N_contr ol Fecha_nac Periodo Hora Aula
Alumno
AlGr u
Grupo
Figura 2.7 Relacin una a muchas De manera similar, si el conjunto de relaciones AlGru fuera muchas a una de Alumno a Grupo, entonces la lnea de AlGru a Grupo tendra una flecha apuntando al conjunto de entidades Grupo. Finalmente, si el conjunto de relaciones AlGru fuera una a una, entonces las dos lneas de AlGru tendran flechas, una apuntando al conjunto de entidades Alumno y otra apuntando al conjunto de entidades Grupo. Conjunto de entidades dbil. Cuando una entidad no tiene los suficientes atributos para formar una clave primaria, se le llama entidad o conjunto de entidades dbil. Un conjunto de entidades de este tipo se indica en los diagramas E-R por medio de un rectngulo de doble contorno. Los conjuntos de entidades que tienen una clave primaria se denominan conjuntos de entidades fuertes
27
Sexo Nombr e N_contr ol Alumno Fecha _nac AlCal Promedi o Periodo Materi a
Calificacin
. Figura 2.8 Diagrama E-R con un conjunto de entidades dbil Aunque un conjunto de entidades dbil no tiene una clave primaria, sin embrago debe haber un medio de distinguir entre todas aquellas entidades en el conjunto de entidades que dependen de una entidad fuerte determinada. El discriminador de un conjunto de entidades dbil es un conjunto de atributos que permite que se haga esta distincin. Los conjuntos de relaciones no binarias pueden especificarse fcilmente en un diagrama E-R.
Nombre Identificador
Sexo Maestro Nombre N_con trol Fecha_na c Hora Aula
Alumno
AlGru M
Grupo
Figura 2.9 Diagrama E-R con una relacin ternaria
28
2.2.5 Generalizacin y especializacin Generalizacin. La generalizacin se usa para hacer resaltar los parecidos entre tipos de entidades de nivel ms bajo y ocultar sus diferencias. La distincin se hace a travs de un proceso llamado herencia de atributos. Los atributos de los conjuntos de entidades de nivel ms alto se dice que son heredados por los conjuntos de entidades de nivel ms bajo. En un diagrama E-R, la generalizacin se representa por medio de un tringulo que contiene la leyenda IS A (o ES).
Sexo Nombre N_contro l Fecha_nac
Alumno
ES
Regular
Irregular
Semestre
Fecha_ingres o
Figura 2.10 Generalizacin Especializacin. Los conjuntos de entidades pueden incluir subgrupos de entidades que se diferencian de alguna forma de las dems entidades del conjunto. Por ejemplo, un subconjunto de entidades de un conjunto de entidades puede tener atributos que no sean compartidos por todas las entidades del conjunto de entidades. El modelo E-R ofrece un medio de representar estos grupos de entidades diferentes. Por ejemplo, considrese el conjunto de entidades persona, con los atributos identificador, nombre, sexo y fecha_nac. Cada persona puede clasificarse adems en una de las categoras siguientes: o Alumno o Maestro
29
Cada uno de estos tipos de persona se describen mediante un conjunto de atributos que incluye todos los atributos del conjunto de entidades persona mas otros posibles atributos adicionales. Por ejemplo, las entidades alumno se pueden describir adems mediante el atributo carrera, mientras que las entidades maestro se pueden describir adems mediante el atributo sueldo. El proceso de establecimiento de subgrupos dentro del conjunto de entidades se denomina especializacin. La especializacin de persona permite distinguir entre las personas basndonos en si son alumnos o maestros: en general, cada persona puede ser alumno, maestro, las dos cosas o ninguna de ellas. En un diagrama E-R, la especializacin se representa mediante un elemento triangular etiquetado IS A (o ES), tal y como sucede con la generalizacin.
Sexo Nombre Identificador Fecha_nac
Persona
ES
Alumno
Maestro
Carrera
Sueldo
Figura 2.11 Especializacin
30
2.2.6 Agregacin Una limitacin del modelo E-R es que no es posible expresar relaciones entre relaciones.
Sexo Horas Nombre N_control Fecha_nac Ubicacin Fecha_ini
Alumno
Trabaj o
Proyecto
Asign a
Maestro
Identific
Figura 2.12 Diagrama E-R con relaciones redundantes La solucin es utilizar agregacin que es una abstraccin a travs de la cual las relaciones se tratan como entidades de nivel ms alto.
31
Trabajo Sexo Horas Nombre N_contr ol Alumno Fecha_n ac Trabaj o Ubicacin Fecha_i ni
Proyecto
Asign a
Maestro
Identific
Figura 2.13 Diagrama E-R con agregacin
2.2.7 Entidades recursivas La funcin que tiene una entidad en una relacin se denomina papel. Los papeles pueden ser implcitos y por lo general no se especifican. Sin embrago, son tiles si se necesita aclarar el significado de una relacin. Tal es el caso cuando los conjuntos de entidades de una relacin no son distintos (lo que algunas veces se denomina entidades recursivas). Reduccin de los diagramas E-R a tablas Un diagrama dice ms que mil palabras, el diagrama E-R es muy til para el diseador de la base de datos ya que permite plasmar la situacin actual de la empresa, los datos que se utilizan y cmo se relacionan. Sin embargo, el diagrama no se introduce a la computadora y la estructura se crea como por arte de magia, es necesario primero transformar el diagrama E-R a tablas de acuerdo a las siguientes reglas generales: 1. Cada tabla debe tener un nombre que no debe repetirse en el conjunto de tablas.
32
2. A cada uno de los conjuntos de entidades le corresponde una tabla, cada uno de los atributos asociados a esta entidad representar una columna de la tabla. En una tabla, las columnas deben tener nombres nicos. 3. Cada una de las relaciones muchos a muchos se representa mediante una tabla. Dicha tabla tiene una columna para cada uno de los atributos que a ella estn asociados y adems una columna para cada uno de los atributos claves o llave de las entidades que relaciona. 4. Para relaciones uno a muchos no es necesario crear una nueva tabla, basta con introducir un atributo extranjero en la tabla correspondiente al conjunto de entidades muchos que haga referencia a la tabla correspondiente al conjunto de entidad uno (por lo general, la llave). 5. Para un conjunto de entidad dbil se tiene el mismo caso de una relacin uno a muchos, es decir, basta con introducir un atributo extranjero (la llave) de cada una de las entidades fuertes de las cuales depende. 6. Existen dos mtodos diferentes para transformar un diagrama E-R que incluye la generalizacin en una forma tabular: a. Crear una tabla para el conjunto de entidades de nivel ms alto, para cada conjunto de entidades de nivel ms bajo, crear una tabla que incluya una columna para cada uno de los atributos de ese conjunto de entidades mas una columna para cada atributo de la clave primaria del conjunto de entidades del nivel ms alto. Tomando como ejemplo la figura 2.10 tendremos como resultado tres tablas: Alumno, con atributos n_control, nombre, sexo y fecha_nac Regular, con atributos n_control y semestre Irregular, con atributos n_control y fecha_ingreso b. No crear una tabla para el conjunto de entidades de nivel ms alto. En cambio, para cada conjunto de entidades de nivel ms bajo, crear una tabla que incluya una columna para cada uno de los atributos de ese conjunto de entidades ms una columna para cada atributo del conjunto de entidades de nivel ms alto. Entonces, para la figura 2.10 tenemos dos tablas: Regular, con atributos n_control, nombre, sexo, fecha_nac y semestre Irregular, con atributos n_control, nombre, sexo, fecha_nac y fecha_ingreso 7. La transformacin de un diagrama E-R que incluya agregacin a una forma tabular es directa. Para el diagrama de la figura 2.13, usando el mismo procedimiento que antes, creamos las tablas siguientes:
33
Alumno Trabajo Proyecto Asigna Maestro La tabla para el conjunto de relaciones asigna incluye una columna para cada atributo en la clave primaria del conjunto de entidades maestro y del conjunto de relaciones trabajo. Tambin incluye una columna para el atributo del conjunto de relaciones asigna. 8. De acuerdo a las reglas anteriores, podemos deducir que la relacin que exista entre un conjunto de entidades dbil y uno fuerte, no se debe representar en una tabla, ya que esta incluira la llave de las entidades a las cuales relaciona, pero una entidad dbil carece de llave por definicin, por lo tanto los atributos de la entidad dbil, mas la llave de la entidad o entidades fuerte de las cuales depende ya estn plasmados en la tabla correspondiente a la entidad dbil.
34
Para ejemplificar todo lo anterior, tomemos el siguiente diagrama y veamos su reduccin a tablas:
No mbr e Dir ecc Fecha Clav e N oa r Ob ser Ar pr o Desc Nom bre Ciud ad Proveedor
RFC
Cliente
Cli no
Nota
Articulo
Cant ES
Precio
Num ero
Local
Foraneo Folio
Fech a Folio
C o m
Zona
Ciudad Factura Importe
Compra Importe
Figura 2.14 Ejemplo de diagrama E-R Reduccin a tablas Forma 1. Cliente *RFC Nombre Direcc Local *RFC Zona Foraneo *RFC Ciudad Factura *Folio Importe Nota Clave Folio RFC Cant Obs Fecha Compra *Folio Importe
Articulo *Clave Desc Precio * Llave
Arp *Clave *Folio
Proveedor *Numero Ciudad Nombre
Co *Folio *Clave *Numero Fecha
Nota. La tabla de las relaciones CLI y NO se eliminan por relacionar a una entidad dbil.
35
Forma 2. Local *RFC Zona Nombre Direcc Foraneo *RFC Ciudad Nombre Direcc Factura *Folio Importe Nota Clave Folio RFC Cant Obs Fecha Co *Folio *Clave *Numero Fecha Compra *Folio Importe
Articulo *Clave Desc Precio
Arp *Clave *Folio
Proveedor *Numero Ciudad Nombre
36
2.3 Modelo relacional Las bases de datos relacionales usan un conjunto de tablas para representar tanto los datos como las relaciones entre ellos, a cada una de estas tablas se les asigna un nombre nico. Tambin incluyen un LMD y un LDD. La mayor parte de los sistemas de bases de datos relacionales comerciales emplean el lenguaje SQL. El modelo relacional es un ejemplo de modelo basado en registros. Los modelos basados en registros se denominan as porque la base de datos se estructura en registros de formato fijo de varios tipos. Cada tabla contiene registros de un tipo dado. Cada tipo de registro define un nmero fijo de campos, o atributos. Las columnas de la tabla se corresponden con los atributos del tipo de registro. Este modelo es el ms ampliamente utilizado, y la gran mayora de sistemas de bases de datos actuales se basan en l. 2.3.1 Estructura del modelo relacional (atributo, dominio, tupla) En el modelo relacional los datos estn almacenados en tablas llamadas relaciones, a los renglones se les llaman tuplas o tuplos y a las columnas se les llama atributos.
Atributo s
NUM
NOMBRE SALAZAR GUTIERREZ BERNAL
STATUS 20 10 30
CIUDAD MEOQUI CHIHUAHUA PARRAL
Tupla
S1 S2 S3
PROVEEDORES
Atributo. Cada una de las caractersticas de una relacin Dominio. Es el conjunto de todos los posibles valores que puede tomar un atributo. 2.3.2 Definicin de relacin Una fila de una tabla representa una relacin entre un conjunto de valores. Puesto que una tabla es una coleccin de dichas relaciones, hay una estrecha correspondencia entre el concepto de tabla y el concepto matemtico de relacin, del cual toma su nombre el modelo de datos relacional.
37
Los matemticos definen una relacin como el producto cartesiano de una lista de dominios. Esto corresponde casi exactamente con nuestra definicin de tabla. La nica diferencia es que aqu se asignan nombres a los atributos, mientras que los matemticos se basan en nombres numricos, usando el entero 1 para indicar el atributo cuyo dominio aparece primero en la lista de dominios; 2 para indicar el atributo cuyo dominio aparece segundo, y as sucesivamente. Puesto que las tablas son esencialmente relaciones, usaremos los trminos matemticos relacin y tupla o tuplo, en lugar de los trminos tabla y fila. Es necesario que, para todas las relaciones r, los dominios de todos los atributos de r sean atmicos. Un dominio es atmico si los elementos del dominio se consideran indivisibles. Por ejemplo, el nombre de una persona puede contener apellido paterno, apellido materno y nombre, este sera un dominio NO atmico, debe dividirse en cada uno de sus componentes para que entonces se cumpla la condicin. 2.3.3 Propiedades de una relacin (grado, cardinalidad) Grado de la relacin. Es el nmero de columnas o atributos que tiene una relacin. Cardinalidad de la relacin. Nmero de tuplas de una relacin Para el siguiente ejemplo, los valores de grado y cardinalidad de la relacin son: Grado = 4 Cardinalidad = 3
NUM S1 S2 S3
NOMBRE SALAZAR GUTIERREZ BERNAL
STATUS 20 10 30
CIUDAD MEOQUI CHIHUAHUA PARRAL
PROVEEDORES
NOTA. En un contexto de base de datos el orden de las columnas no importa.
38
Llaves Llave primaria. Atributo o atributos cuyos valores son nicos dentro de la relacin y por lo tanto identifican de forma nica a un tuplo dentro de la misma. Las llaves primarias pueden ser de dos tipos: o Simple. Formada por un solo atributo. o Compuesta. Formada por dos o ms atributos. Llave alterna. Es otro atributo diferente de la llave primaria que tambin nos identifica de forma nica a una tupla. Proveedores
NumPr S1 S2 S3 S4 S5 Nombre SALAZAR GUTIERREZ BERNAL SANTANA CASTRO Ciudad MEOQUI CHIHUAHUA PARRAL PARRAL MEOQUI Status 20 10 30 30 20
Llave alterna Llave primaria simple
Atributo heredado y extranjero. Es aquel atributo que fue heredado de una relacin padre a una relacin hijo, con la finalidad de relacionarlas. Proveedores Partes
CIUDAD MEOQUI CHIHUAHUA PARRAL PARRAL MEOQUI STATUS 20 10 30 30 20 NUMPA P1 P2 P3 P4 P5 DESCRIPCIN TUERCA TORNILLO RONDANA PINZAS MARTILLO COLOR GRIS GRIS NEGRO GRIS CAFE PESO 20 20 10 30 30 NOMBRE SALAZAR GUTIERREZ BERNAL SANTANA CASTRO
NUMPR S1 S2 S3 S4 S5
39
Pedidos
Atributo heredado de Atributo heredado de Partes Proveedores
NUMPR S1 S1 S1 S2 S2 S3 S4
NUMPA P1 P4 P5 P1 P2 P3 P4
CANT 100 200 100 200 400 100 200
Llave compuesta (NUMPR + NUMPA)
NUM S1 NUM S2 S1 S1 S3 S2 S3 S2 S3
NOMBRE NOMBRE SALAZAR NOMBRE SALAZAR GUTIERREZ SALAZAR GUTIERREZ BERNAL GUTIERREZ BERNAL
STATUS STATUS 20 STATUS 10 20 20 30 10 30 10 30
CIUDAD CIUDAD MEOQUI CIUDAD MEOQUI CHIHUAHUA MEOQUI CHIHUAHUA PARRAL CHIHUAHUA PARRAL PARRAL
BERNAL PROVEEDORES PROVEEDORES PROVEEDORES
40
Reglas de integridad del modelo relacional Regla de integridad No. 1 (Integridad de la entidad). Ningn componente de la llave primaria puede tener un valor nulo. Regla de integridad No. 2 (Integridad referencial). Sea D un dominio primario y sea R una relacin con atributo A, que se define sobre D. Entonces, en cualquier instante dado, cada valor de A en R1 puede ser o bien: o NULO o IGUAL A (V) Donde (V) es el valor de la llave primaria de alguna tupla de una relacin R2 (R1 y R2 no son necesariamente distintos) con llave primaria definida sobre D. Dicho de otra forma no puede existir una tupla hijo si no existe su correspondiente tupla padre.
Extensin y comprensin La extensin de una relacin especfica es el conjunto de tuplas que aparecen en una relacin en cualquier instante dado (es decir, cardinalidad o bien instancia). La comprensin es la parte permanente de la relacin y es la combinacin de dos cosas: Estructura nominadora (nombre de la relacin, atributos, ndices). Restricciones de integridad. Extensin = Cardinalidad o Instancia Estructura nominadora = Esquema
41
EJERCICIOS 2.1 Representa con un diagrama E-R lo siguiente: Entidad MESERO con atributos NUMERO, NOMBRE, DIRECCION, TELEFONO, relacionado con la entidad PLATILLO, con atributos CODIGO, PRECIO, estas dos entidades estn relacionadas con la entidad dbil CUENTA con atributos NUMERO DE MESA, FECHA. 2.2 Menciona cul es la diferencia entre generalizacin y agregacin y para qu se usa cada una en el modelo entidad relacin. 2.3 Reduce a tablas el diagrama del ejercicio 2.1 e indica en cada una de ellas la clave. 2.4 Qu es la cardinalidad de asignacin? 2.5 Cul es la diferencia entre atributo y dominio? 2.6 Qu es una tupla? 2.7 Menciona y explica las reglas de integridad del modelo relacional 2.8 Cmo se define un atributo heredado o extranjero? 2.9 Cmo se establece la relacin entre tablas en el modelo relacional?
42
UNIDAD III DISEO DE BASES DE DATOS RELACIONALES

El modelo relacional es el principal modelo de datos para las aplicaciones comerciales de procesamiento de datos. Esto debido a su simplicidad, lo que facilita el trabajo del programador. 3.1 Consideraciones de diseo El modelo Entidad-Relacin, estudiado anteriormente, es un buen punto de partida en el diseo de bases de datos relacionales. A partir de un buen diagrama Entidad-Relacin, es posible llegar a un buen diseo de esquemas de relacin o tablas, que son la base del modelo Relacional. El modelo relacional pretende disear una base de datos generando un conjunto de esquemas de relacin que permita almacenar la informacin sin redundancias innecesarias, pero que tambin permita su recuperacin de manera fcil. Como vimos en la unidad anterior, las bases de datos relacionales deben seguir ciertas consideraciones: 1. En un contexto de base de datos, el orden de las columnas no importa, pero desde el punto de vista matemtico si importa. 2. En un contexto de base de datos el orden de los tuplos es adecuado, pero desde el punto de vista matemtico no importa el orden. 3. En una Base de Datos Relacional se requiere que todas las relaciones satisfagan la condicin siguiente: Todo valor en la relacin debe ser atmico Es decir, en cada interseccin de un rengln y una columna siempre debe existir nicamente un valor, nunca un conjunto de valores. Cuando se cumple esta condicin se dice que la relacin est normalizada. 3.2 Normalizacin Normalizacin puede definirse como el proceso mediante el cual, cierta tabla va cumpliendo los requisitos de las formas normales con el fin de tener tablas bien diseadas y por consiguiente un buen diseo del modelo conceptual de una base de datos
43
3.2.1 Dependencias funcionales Una Dependencia Funcional (DF) se explica como sigue: Dada una relacin R, el atributo Y de R es funcionalmente dependiente del atributo X de R, denotado por: R.X R.Y Si y solo si cada valor de X en R tiene asociado a l exactamente un valor de Y en R en cualquier instante dado. Tanto X como Y pueden ser compuestos. Dicho de otra forma, Y depende de X, si dado el valor de X, podemos saber el valor del atributo Y. Por ejemplo, para la tabla de Proveedores tenemos las siguientes DFs: Proveedores
Proveedores.NumPr Proveedores.Nombre Proveedores.NumPr Proveedores.Ciudad Proveedores.NumPr Proveedores.Status Para la tabla pedidos: Pedidos
NUMPR S1 S1 S1 S2 S2 S3 S4 NUMPA P1 P4 P5 P1 P2 P3 P4 CANT 100 200 100 200 400 100 200
Llave compuesta (NUMPR + NUMPA)
Pedidos.(NUMPR,NUMPA) Pedidos.Cant Debe hacerse notar que las llaves primarias o llaves candidatas son atributos X, pero para ser atributo X no es necesario que sea llave primaria o candidata.
44
Es posible representar las dependencias funcionales por medio de un Diagrama de Dependencias Funcionales. En estos diagramas se representan a los atributos por medio de rectngulos, las dependencias funcionales se representan por medio de arcos dirigidos del atributo X hacia el atributo Y. Los atributos compuestos pueden agruparse por medio de un rectngulo mayor. Por ejemplo, para las relaciones anteriores, su Diagrama de Dependencias Funcionales sera: Diagrama DFs de Proveedores
Nombre
NumPr
Status
Ciudad
Diagrama DFs para Pedidos
NumPr Cant NumPa
45
Dependencia Funcional Completa. El atributo Y es funcionalmente dependiente en forma completa del atributo X, si Y es funcionalmente dependiente de X y no depende funcionalmente de ningn subconjunto de X Ejemplo: Suponga la siguiente tabla: Para esta tabla se puede dar la DF: Proveedores
Proveedores.NumPr Proveedores.Nombre Proveedores.NumPr Proveedores.Ciudad Proveedores.NumPr Proveedores.Status Sin embrago, no es una DF completa, ya que tenemos la siguiente DF: Proveedores.Ciudad Proveedores.Status Es decir, Status tambin depende de Ciudad, el cual es un subconjunto de (NumPr). Definiciones: Atributos mutuamente independientes. Son aquellos donde ninguno es funcionalmente dependiente de otro. Un atributo es No Primo si no participa en la llave primaria. Proveedores
Atributos mutuamente independientes: Ciudad y Nombre Atributos no primos: Nombre, Ciudad y Status 46
En conclusin, las Dependencias Funcionales es solo un tratamiento semntico de los datos; dependiendo de la situacin del mundo reales como se definirn las dependencias funcionales.
3.2.2 Primeras formas normales Un Forma Normal (NF o FN) se puede definir como un conjunto de restricciones que debe cumplir cierta relacin. Existen bsicamente cinco formas normales abreviadas como 1FN, 2FN, 3FN, 4FN, 5FN aunque adicionalmente han surgido ms. En la siguiente figura se muestra como todas las relaciones estn en 1FN; algunas de esas relaciones adems de estar en 1FN tambin estn en 2FN; otras cumplen 2FN pero adems cumplen 3FN y as sucesivamente.
R en 1FN R en 2FN R en 3FN R en 4FN
R en 5FN
47
3.2.2.1 1FN Con el fin de analizar el proceso de normalizacin, supondremos la siguiente base de datos: NumPr S1 S1 S1 S2 S2 S3 S4 S5 Primera Nombre Ciudad Status SALAZAR MEOQUI 20 SALAZAR MEOQUI 20 SALAZAR MEOQUI 20 GUTIERREZ CHIHUAHUA 10 GUTIERREZ CHIHUAHUA 10 SANTANA PARRAL 30 BERNAL PARRAL 30 CASTRO MEOQUI 20 NumPa P1 P2 P3 P1 P3 P2 P2 P1 DescPa TUERCA TORNILLO RONDANA TUERCA RONDANA TORNILLO TORNILLO TUERCA Cant 10 20 10 5 15 20 15 20
Llave (NumPr, NumPa) Adems considere la condicin de que Status depende de Ciudad. Tomando en cuenta lo anterior, las DFs de la tabla Primera se veran de la siguiente forma:
Nombre
NumPr Cant
Status
Ciudad
NumPa DescPa
Una Relacion R est en primera forma normal (1FN) si y solo si, todos los dominios de esta relacin solo contienen valores atmicos. La tabla Primera cumple con la primera forma normal (1FN), pero tiene los siguientes problemas en cada una de las operaciones bsicas: 1. Insertar. No se puede insertar nicamente los datos de un proveedor hasta que se suministre alguna parte, ya que de hacerlo se rompera la regla de integridad No. 1 (NumPa tendra valor nulo)
48
2. Borrar. Si borramos un embarque que hace referencia a un proveedor que aparece en la tabla nicamente en ese tuplo borrado, no solamente habremos borrado el embarque sino tambin la nica informacin del proveedor en cuestin. Por ejemplo, si se borra el embarque S3-P2, se borra tambin la nica informacin referente al proveedor S3. 3. Modificar. Como existe redundancia de informacin, si se desea actualizar informacin referente a un proveedor, tendr que actualizarse en todas las ocurrencias de ese proveedor. Por ejemplo, si desea actualizar el nombre de S1, tendremos que realizar la actualizacin en los tres tuplos donde ocurre S1. La solucin a este problema es dividir la tabla en dos nuevas tablas, las cuales quedaran de la siguiente forma con su respectivo DFs:
NumPr S1 S1 S1 S2 S2 S3 S4 S5
Segunda Nombre Ciudad SALAZAR MEOQUI SALAZAR MEOQUI SALAZAR MEOQUI GUTIERREZ CHIHUAHUA GUTIERREZ CHIHUAHUA SANTANA PARRAL BERNAL PARRAL CASTRO MEOQUI Llave primaria NumPr
Status 20 20 20 10 10 30 30 20
Nombre
NumPr
Status
Ciudad
49
Embarques NumPa DescPa P1 TUERCA P2 TORNILLO P3 RONDANA P1 TUERCA P3 RONDANA P2 TORNILLO P2 TORNILLO P1 TUERCA
Cant 10 20 10 5 15 20 15 20
Llave primaria (NumPr,NumPa)
NumPr Cant NumPa DescPa
50
3.2.2.2 2FN Una relacin R est en Segunda Forma Normal (2FN) si y solo si, est en 1FN y cada atributo no primo es totalmente dependiente de la llave primaria. Las tablas Segunda, Embarques y Partes cumplen con la 2FN (ver DFs) pero an la tabla Segunda presenta una serie de caractersticas indeseables en las operaciones bsicas: 1. Insertar. No se puede insertar una nueva ciudad con su respectivo status si no existe un proveedor que exista en dicha ciudad. Por ejemplo, no podramos insertar la ciudad Julimes con un status de 5. 2. Borrar. Si se borra a un proveedor que est localizado en una ciudad que ocurre una sola vez en la tabla, habremos borrado no nicamente al proveedor sino tambin la nica ocurrencia de dicha ciudad. Por ejemplo, si se borra al proveedor S3, adems se borra que la ciudad Parral tiene un status 30. 3. Modificar. Si desea actualizar el status de cierta ciudad, se debe de hacer en cada ocurrencia de dicha ciudad (recordemos que status depende de ciudad). Por ejemplo, si actualizamos el status de la ciudad Parral, debemos hacerlo en dos tuplos donde aparece dicha ciudad. La solucin a estos problemas es que Segunda se divida en dos nuevas tablas. Sus DFs se muestran tambin. NumPr S1 S1 S1 S2 S2 S3 S4 S5 Proveedor Nombre Ciudad SALAZAR MEOQUI SALAZAR MEOQUI SALAZAR MEOQUI GUTIERREZ CHIHUAHUA GUTIERREZ CHIHUAHUA SANTANA PARRAL BERNAL PARRAL CASTRO MEOQUI Llave (NumPr)
51
Nombre
NumPr
Ciudad
Ciudad Ciudad Status MEOQUI 20 MEOQUI 20 MEOQUI 20 CHIHUAHUA 10 CHIHUAHUA 10 PARRAL 30 PARRAL 30 MEOQUI 20 Llave (Ciudad)
Status
Ciudad
52
3.2.2.3 3FN y FNBC (forma normal Boyce-Cood) Una relacin R est en Tercera Forma Normal (3FN) si y solo si, est en 2FN y todo atributo no primo es dependiente no transitivamente de la llave primaria. No transitividad significa que los atributos son mutuamente independientes. La tabla Embarques cumple con la 2FN, sin embargo, la columna DescPa depende no solo de la llave compuesta (NumPr, NumPa) sino adems de un subconjunto de sta (NumPa) por lo que hay que dividir nuevamente la tabla Embarques para que se cumpla con la 3FN, quedando de la siguiente forma: NumPr S1 S1 S1 S2 S2 S3 S4 S5 Embarques NumPa P1 P2 P3 P1 P3 P2 P2 P1 Cant 10 20 10 5 15 20 15 20
NumPr Cant NumPa
53
Partes NumPa DescPa P1 TUERCA P2 TORNILLO P3 RONDANA P1 TUERCA P3 RONDANA P2 TORNILLO P2 TORNILLO P1 TUERCA Llave primaria (NumPa)
DescPa NumPa
Las tablas Proveedor, Partes, Embarques y Ciudad cumplen ahora si con la Tercera Forma Normal 3FN. Generalmente una base de datos est bien diseada cuando sus tablas cumplen 3FN, as que el diseo final queda de la siguiente manera: NumPr S1 S2 S3 S4 S5 Proveedor Nombre Ciudad SALAZAR MEOQUI GUTIERREZ CHIHUAHUA SANTANA PARRAL BERNAL PARRAL CASTRO MEOQUI Llave (NumPr)
Ciudad Ciudad Status MEOQUI 20 CHIHUAHUA 10 PARRAL 30 MEOQUI 20 Llave (Ciudad)
54
Partes NumPa DescPa P1 TUERCA P2 TORNILLO P3 RONDANA Llave primaria (NumPa) Embarques NumPa P1 P2 P3 P1 P3 P2 P2 P1
Cant 10 20 10 5 15 20 15 20
Claramente la falta de redundancia que presenta la descomposiciones deseable. Note que cada una de las tablas solo repite entre si, la columna necesaria para relacionarlas. Las distintas formas normales representan los grados de eliminacin de redundancia que pueden lograrse.
55
Forma normal Boyce-Codd (FNBC) Una de las formas normales ms deseables que se pueden obtener es la forma normal de Boyce-Codd. Elimina todas las redundancias que se pueden descubrir a partir de las dependencias funcionales aunque, puede que queden otros tipos de redundancia. Un esquema de relaciones R est en FNBC con respecto a un conjunto F de dependencias funcionales si para todas las dependencias funcionales de F+ de la forma , donde c R y c R, por lo menos se cumple una de las siguientes condiciones: es una dependencia funcional trivial (es decir, c ). es una superclave del esquema R
Los diseos de bases de datos estn en FNBC si cada miembro del conjunto de esquemas de relacin que constituye el diseo se halla en la FNBC. Tomemos como ejemplo la tabla o esquema Embarques, descrita en la seccin anterior. El esquema Embarques no est en FNBC. En primero lugar, obsrvese que la clave (NumPr, NumPa) no es una superclave de Embarques puesto que podramos tener un par de tuplos representando diferentes embarques hechos al mismo proveedor y de la misma parte: (S1, P1, 10) (S1, P1, 20) Como no se listaron las dependencias funcionales que excluyen el caso anterior, NumPr,NumPa no es una clave candidata. Sin embargo la dependencia funcional (NumPr,NumPa) Cant no es trivial. Por lo tanto Embarques no satisface la definicin de FNBC. Decimos que el esquema Embarques no est en una forma deseable, ya que padece del problema de repeticin de informacin. Podemos eliminar la redundancia rediseando la base de datos de forma que todos los esquemas estn en FNBC. Considere la descomposicin del esquema Embarques en dos esquemas: Embarques-detalle (Folio, NumPr, NumPa) Embarques-cantidad (Folio, Cant) Agregando la columna Folio como un dato extra requerido podemos diferenciar entre un embarque y otro evitando la redundancia de informacin.
56
Muchas veces el programador debe crear este tipo de atributos, es por eso indispensable analizar necesidades, limitaciones y requerimientos en cada caso. 3FN tiene la ventaja de que sabemos que siempre es posible obtener un diseo 3FN sin agregar atributos inexistentes, sin la prdida o conservacin de las dependencias. No obstante, 3FN tiene una desventaja. Si no eliminamos todas las dependencias transitivas, puede ser necesario utilizar valores vacos para representar algunas de las posibles relaciones significativas entre los datos y est tambin el problema de la repeticin de la informacin. Si nos vemos obligados a elegir entre FNBC y la conservacin de las dependencias con 3FN, generalmente es preferible optar por 3FN. Si no podemos probar la conservacin de las dependencias eficientemente, pagamos un alto precio en el rendimiento del sistema o un riesgo en la integridad de los datos de la base de datos. Ninguna de estas alternativas resulta atractiva. Con tales alternativas, la cantidad limitada de redundancia impuesta por las dependencias transitivas permitida en 3FN es la menos mala. As pues, normalmente elegimos asegurar la conservacin de las dependencias y sacrificar FNBC.
57
3.2.3 Normalizacin adicional 3.2.3.1 Dependencia multivaluada y 4FN Hay esquemas de relaciones que estn en FNBC, las cuales no parecen estar suficientemente normalizadas en el sentido de que todava padecen el problema de la repeticin de la informacin. Considrese el siguiente ejemplo: Esquema-Cliente = (Numero-compra, Nombre-cliente, Calle, Ciudad-cliente) Este es un esquema no FNBC debido a las dependencias funcionales: Nombre-cliente Calle Nombre-cliente Ciudad-cliente Y al hecho de que nombre-cliente no es una clave de Esquema-cliente. Sin embrago, supongamos que la ferretera cuenta con clientes con varias direcciones (por ejemplo una casa de invierno y otra de verano). Entonces, no queremos hacer que se cumplan las dependencias funcionales: Nombre-cliente Calle Nombre-cliente Ciudad-cliente Si eliminamos estas dependencias funcionales, encontramos que Esquema-cliente esta en FNBC con respecto al conjunto modificado de dependencias funcionales. A pesar de el hecho de que ahora Esquema-cliente est ahora en FNBC, todava tenemos el problema de la repeticin de la informacin que tenamos anteriormente. Para tratar esto, debemos definir una nueva forma de restriccin, llamada dependencia multivaluada. Ahora se usarn dependencias multivaluadas para definir una forma normal de esquemas de relaciones. Esta forma normal, llamada cuarta forma normal (4FN), es ms restrictiva que FNBC. Las dependencias funcionales excluyen el que ciertas tuplas estn en una relacin. Si A B, entonces no podemos tener dos tuplas con el mismo valor de A y distintos valores de B. Las dependencias multivaluadas no excluyen la existencia de ciertas tuplas. En cambio exigen que otras tuplas de una forma determinada estn presentes en la relacin. Por esta razn las dependencias funcionales se conocen en ocasiones como dependencias generadoras de igualdad y las dependencias multivaluadas como dependencias generadoras de tuplas.
58
Para ilustrar esta diferencia, considrese nuevamente el Esquema-cliente: Numero-compra 01 01 02 Nombre-cliente JUAN JUAN MARGARITA Calle PANAMERICANA VILLA MADERO Ciudad-cliente CHIHUAUHA MEOQUI PARRAL
Se debe repetir el nmero de compra por cada una de las direcciones que tiene el cliente, y debemos repetir la direccin por cada una de las compras que tiene el cliente. Esta repeticin no es necesaria, ya que la relacin entre un cliente y su direccin es independiente de la relacin entre ese cliente y una compra. Si un cliente, por ejemplo JUAN, tiene una compra, por ejemplo la nmero 01, queremos que esa compra est asociada con todas las direcciones de JUAN. As, la relacin del Esquema-cliente presentada arriba es ilegal. Para hacer que esta relacin sea legal, necesitamos aadir las tuplas (01, JUAN, PANAMERICANA, CHIHUAHUA) y (02, JUAN, VILLA, MEOQUI) a este esquema con el fin de evitar la repeticin del Numero-compra, queremos que la dependencias multivaluadas: Nombre-Cliente Calle Nombre-Cliente Ciudad-cliente Se cumplan. Cuarta forma normal 4FN Volviendo al ejemplo Esquema-cliente, en el que se cumplen las dependencias multivaluadas Nombre-Cliente Calle y Nombre-Cliente Ciudad-cliente, no se cumplen las dependencias funcionales no triviales. Aunque este esquema est en FNBC, no es un diseo ideal, puesto que debemos repetir la informacin de la direccin de un cliente para cada compra. Podemos usar la dependencia multivaluada dada para una descomposicin de cuarta forma normal (4FN). Sustituimos entonces Esquema-cliente por dos esquemas: Esquema-compra-cliente = (Nombre-cliente, Numero-compra) Esquema-cliente = (Nombre-cliente, Calle, Ciudad-cliente) Este par de esquemas que estn en 4FN elimina el problema de la redundancia.
59
3.2.3.2 Dependencia de juntura y 5FN Como en el caso de otros tipos de dependencias, las dependencias de interseccin o juntura llevan a otra forma normal de proyecto-producto (FNPP). As como una dependencia multivaluada es una forma de expresar la independencia de un par de relaciones, una dependencia de producto es una forma de expresar que todas las relaciones de un conjunto son independientes. Esta nocin de independencia de relaciones es una consecuencia natural de la forma en la que generalmente definimos una relacin. Considere el siguiente ejemplo: Esquema-pedido = (NumeroPa, Numero-pedido, Nombre-cliente, Cantidad) De la Ferretera. Podemos definir una relacin Pedido (Esquema-pedido) como el conjunto de todas las tuplas de esquema-pedido tales que: El pedido representado por Numero-pedido lo haga por la parte nmero NumeroPa. El pedido representado por Numero-pedido lo haga el cliente llamado Nombre-cliente. El pedido representado por Numero-pedido sea por la cantidad dada por Cantidad. Esta definicin de la relacin Pedido es una conjuncin de tres predicados: uno en Numero-pedido y Numerosa, otro en Numero-pedido y Nombre-cliente y otro en Numero-pedido y Cantidad. Para poner Esquema-pedido en FNPP o quinta forma normal (5FN como lo mencionan algunos textos), debemos descomponerla en las tres planificaciones especificadas por la dependencia de producto: (Numero-pedido, NumeroPa), (Numero-pedido, Nombre-cliente) y (Numero-pedido, Cantidad).
60
3.3 Integridad de bases de datos 3.3.1 Concepto Se debe asegurar que los cambios que se hacen en la base de datos por usuarios autorizados no resultan en una prdida de consistencia de los datos. Es por eso que las restricciones de integridad protegen la base de datos contra daos accidentales. 3.3.2 Restricciones bsicas (not null, llave primaria, orden, verificacin y asercin) Como se mencion en el captulo anterior, las bases de datos relacionales deben cumplir con ciertas restricciones como las siguientes: Not null
La insercin de tuplas incompletas puede introducir valores vacos en la base de datos. Para determinados datos los valores nulos pueden ser inapropiados. Por ejemplo, considere una tupla en la relacin Proveedor en la que el atributo Nombre es un valor vaco. Una tupla de este tipo da una ciudad y un nmero de proveedor para un proveedor annimo y, por tanto, no contiene informacin til. En casos como este debieran restringirse los valores nulos. No siempre es posible eliminar los valores nulos. Supngase por ejemplo que en el esquema Proveedor incluimos el atributo NumeroTelefonico. Puede ser que un Proveedor no tenga nmero de telfono. Entonces tendramos que recurrir a los valores nulos para indicar que el valor no existe. Llave primaria
Es importante definir en cada esquema una llave primaria que permita el rpido acceso a la informacin de una tupla determinada. Es posible que no se tengan atributos suficientes para formar una clave primaria (como en el caso de entidades dbiles). Sin embrago, debe haber un medio de distinguir entre una tupla y otra en un esquema. Un discriminador es un conjunto de atributos que permite que se haga esta distincin. Orden
Aunque el orden de los atributos en un esquema o tabla no importan, es necesario revisar cada vez que la informacin es extrada o almacenada, que sta
61
corresponde efectivamente a lo solicitado, de lo contrario, si esto no se verifica pudiera pasar que un nmero de cdigo postal se confundiera con un nmero de cuenta bancaria o el nombre de un cliente se confunda con el nombre de la calle donde vive el cliente. Verificacin
Los datos que van a insertarse en la base de datos deben ser verificados para determinar si cumplen con las restricciones de tipo, valores permitidos, entre otros, ya que la integridad de la base de datos puede verse comprometida y generar informacin errnea. Asercin
Un aserto es un predicado que expresa una condicin que la base de datos debe cumplir siempre. Las resticciones de dominio y de integridad referencial son formas especiales de los asertos. Estos tipos de asertos pueden verificarse con facilidad, sin embargo, hay muchas restricciones que no se pueden expresar utilizando nicamente estas formas especiales. Por ejemplo: La suma de las cantidades embarcadas por cada proveedor debe ser menor que 100.0 Cada embarque debe ser por lo menor por una cantidad mayor a 3.
3.3.3 Integridad de entidad Ningn componente de la llave primaria puede tener un valor nulo. Si la llave primaria es el medio por el cual se accede a los valores de un tuplo, esta no puede tener un valor nulo pues de esta forma la entidad o tuplo no existe. 3.3.4 Integridad referencial Sea D un dominio primario y sea R una relacin con atributo A, que se define sobre D. Entonces, en cualquier instante dado, cada valor de A en R1 puede ser o bien: o NULO o IGUAL A (V)
62
Donde (V) es el valor de la llave primaria de alguna tupla de una relacin R2 (R1 y R2 no son necesariamente distintos) con llave primaria definida sobre D. Dicho de otra forma no puede existir una tupla hijo si no existe su correspondiente tupla padre. 3.3.5 Reglas de relacin Despus de haber examinado aspectos detallados de las formas normales y de la normalizacin, hay que buscar el modo de encajar la normalizacin en el proceso global de diseo de las bases de datos y tomando en cuenta que sta, forma parte de una organizacin que tiene reglas, polticas y formas de operar que deben considerarse. 3.3.6 Reglas de base de datos Teniendo un esquema de relacin R al cual se procede a normalizar, hay varias formas de obtener ese esquema R: o R puede haberse generado al convertir un diagrama E-R en un conjunto de esquemas de relacin o R puede haber sido una sola relacin que contena todos los atributos que resultaban de inters. El proceso de normalizacin divide a R en relaciones ms pequeas. o R puede haber sido el resultado de algn diseo ad hoc de las relaciones, que hay que comprobar para asegurarse de que satisface la forma normal deseada. Una caracterstica deseable del diseo de bases de datos es la asuncin de un rol nico, lo que significa que cada nombre de atributo tiene un significado nico en toda la base de datos. Esto evita que se utilice el mismo atributo para indicar cosas diferentes en esquemas diferentes. Es importante adems, que tanto los nombres de atributos como tablas o relaciones, sean mnemnicos, es decir, su nombre tenga que ver con lo que la tabla almacena o el atributo implica, no utilice nombres propios, diminutivos, por ejemplo, gatito, amor, mio, si estos no tienen que ver con lo que se almacena. Tampoco utilice signos de puntuacin, acentos, comas o puntos, solo el guin bajo. Aunque, tcnicamente, el orden de los nombres de los tributos en los esquemas no tiene ninguna importancia, es costumbre relacionar en primer 63
lugar los atributos de la clave primaria. Esto facilitar la lectura de resultados al hacer consultas. Una regla bsica que debe seguirse en el diseo de bases de datos es no almacenar atributos que pueden ser calculados o que son cambiantes de manera constante debido al contenido de otros, por ejemplo, no debe almacenarse la edad de una persona, almacenando su fecha de nacimiento, podemos hacer una diferencia entre la fecha actual y sta para obtener su edad; el total de una factura puede calcularse haciendo un acumulativo de la multiplicacin del precio de cada producto por la cantidad vendida. Como regla: SI PUEDE CALCULARSE, NO DEBE GUARDARSE. Asegrese de no tener tablas con un solo atributo, revise paso a paso su normalizacin y determine en que tabla debe ser asignado este atributo para no dejarlo solo.
3.3.7 Reglas de negocios Las organizaciones pueden tener diferentes reglas para la nomenclatura de tablas y/o atributos. Por ejemplo una tabla puede denominarse Parte o Partes. Es aceptable tanto el empleo del singular como el del plural, siempre y cuando la convencin se utilice de manera consistente en todos los casos. Es importante que el administrador de la base de datos dedique tiempo a generar este tipo de reglas o consideraciones que deben tomar en cuenta los desarrolladores es decir utilizar estndares. A veces, los diseadores de bases de datos escogen un esquema que tiene informacin redundante; es decir, que no est normalizado. Utilizan la redundancia para mejorar el rendimiento de aplicaciones concretas. La penalizacin sufrida por no emplear un esquema normalizado es el trabajo adicional, de mantener consistentes los datos redundantes. Es decir, no es una regla normalizar, sin embargo puede ahorrarnos muchos dolores de cabeza y tiempo.
64
3.4 Seguridad de bases de datos 3.4.1 Concepto de seguridad Hemos mencionado ya que la informacin es uno de los recursos ms valiosos dentro de la organizacin y como tal, debemos protegerla. El grado de seguridad empleado en cada caso depender de cun importantes sean los datos almacenados, no se emplea la misma seguridad para proteger los datos del directorio telefnico de la empresa que la utilizada para proteger sus estados financieros. Mientras se transmiten los datos o protegerlos de los intrusos que logran superar la seguridad del sistema operativo pueden ser algunos casos, a continuacin se mencionan algunos aspectos a considerar. 3.4.2 Autenticacin y autorizacin Autenticacin Es la tarea de comprobar la identidad de las personas o del software que se conectan a la base de datos. La forma ms sencilla consta de una contrasea secreta que se debe presentar cuando se abre una conexin con la base de datos (el administrador de la base de datos debe definir a los usuarios y sus contraseas). La autenticacin basada en contraseas la usan mucho los sistemas operativos y las bases de datos. Sin embrago, el uso de contraseas tiene algunos inconvenientes, especialmente cuando se utilizan redes. Si un espa es capaz de oler los datos que se envan por la red, puede ser capaz de averiguar la contrasea cuando se enve por la red. Una vez que el husmeador tiene un usuario y una contrasea, se pueden conectar a la base de datos fingiendo que es el usuario legtimo. Es por eso que cada da surgen formas mas sofisticadas de comprobacin como: Tarjetas inteligentes que guardan la clave en un chip incorporado Firmas digitales Respuestas a preguntas personales y cambiantes
Autorizacin Se pueden asignar a los usuarios varios tipos de autorizacin para diferentes partes de la base de datos. Ejemplo La autorizacin de lectura
65
La autorizacin de insercin La autorizacin de actualizacin La autorizacin de borrado
Cada uno de estos tipos de autorizaciones se denomina privilegio y dependern del perfil de cada usuario, es decir, cual es su actividad.
3.4.3 Rol y privilegios de usuarios Se puede conceder a cada usuario todos los tipos de privilegios (poder leer, insertar, actualizar o borrar datos o esquemas de la base de datos), ninguno de ellos o una combinacin de los mismos sobre partes concretas de la base de datos. Considere un banco que tiene muchos cajeros. Cada cajero debe tener el mismo tipo de autorizacin para el mismo conjunto de relaciones. Cada vez que se contrata a un cajero nuevo hay que concederle todas esas autorizaciones una a una.
3.4.4 Vistas y seguridad Hasta este punto hemos supuesto que la coleccin de relaciones que se nos dan son las relaciones reales almacenadas en la base de datos. Sin embrago, no es conveniente que todos los usuarios vean el modelo conceptual completo. Las consideraciones de seguridad pueden requerir que se escondan ciertos datos a los usuarios. Por ejemplo un empleado bancario quiz necesite saber el numero de prstamo de un cliente, mas no el monto. Cualquier relacin que no es parte del modelo conceptual, pero se hace visible al usuario como una relacin ficticia o virtual se llama vista. Es posible tener un gran nmero de vistas sobre cualquier conjunto de relaciones reales dado. Las relaciones reales del modelo conceptual pueden modificarse mientras que generalmente no es posible almacenar una relacin correspondiente a una vista. Una vista debe volverse a calcular para cada consulta que se refiere a ella. Cuando se define una vista, el sistema de base de datos debe almacenar la definicin de la vista. As, la definicin de vista no es una expresin del lgebra relacional. Ms bien, una definicin de vista hace que se guarde una expresin que se va a sustituir en consultas usando la vista.
66
3.5 Recuperacin de bases de datos A menudo, desde el punto de vista del usuario de una base de datos, se considera a un conjunto de varias operaciones sobre una base de datos como una nica operacin. Por ejemplo, una transferencia de fondos de una cuenta a otra es una operacin simple desde el punto de vista del cliente; sin embrago, en el sistema de base de datos, est compuesta internamente por varias operaciones. Es necesario que todas estas operaciones se realicen o que en caso de fallo, ninguna de ellas se produzca. Sera inaceptable efectuar el retiro de una cuenta sin abonarlo en la otra. 3.5.1 Transacciones Una transaccin es una coleccin de operaciones que forman una nica unidad lgica de trabajo. Un sistema de base de datos debe asegurar que la ejecucin de las transacciones se realice adecuadamente a pesar de la existencia de fallos (o se ejecuta la transaccin completa o no se ejecuta). Debe adems de gestionar la ejecucin concurrente de las transacciones evitando introducir inconsistencias. Imagine por ejemplo los cajeros automticos conectados en red, todos los usuarios deben ser capaces de efectuar transacciones al mismo tiempo y quiz hasta halla casos en los que se afecte una misma cuenta. 3.5.1.1 Definicin de transaccin Una transaccin es una unidad de la ejecucin de un programa que accede y posiblemente actualiza varios elementos de datos dentro de una base de datos. Una transaccin se inicia por la ejecucin de un programa (se dice llamada) de usuario escrito en un lenguaje de manipulacin de datos de alto nivel o en un lenguaje de programacin (por ejemplo SQL), y est delimitado por instrucciones (o llamadas a funcin) Inicio y Fin. La transaccin consiste en todas las operaciones que se ejecutan entre el inicio (begin) y fin (end) de la transaccin. 3.5.1.2 Propiedad de atomicidad, consistencia, asilamiento y durabilidad (ACID) Para asegurar la integridad de los datos se necesita que el sistema de base de datos mantenga las siguientes propiedades de las transacciones: Atomicidad. O bien todas las operaciones de la transaccin se realizan adecuadamente en la base de datos o ninguna de ellas.
67
Consistencia. La ejecucin aislada de la transaccin (es decir, sin otra transaccin que se ejecute concurrentemente) conserva la consistencia de la base de datos. Aislamiento. Aunque se ejecuten varias transacciones concurrentemente, el sistema garantiza que para cada par de transacciones T1 y T2, se cumple que para los efectos de T1, o bien T2 ha terminado su ejecucin antes de que comience T1, o bien, que T2ha comenzado su ejecucin despus de que T1 termine. De este modo, cada transaccin ignora el resto de las transacciones que se ejecuten concurrentemente en el sistema. Por ejemplo, pareciera que muchos clientes pueden realizar transacciones en un cajero automtico al mismo tiempo, sin embrago, solo una transaccin se realiza en un tiempo, muy corto, por cierto, sin que el cliente lo note. Durabilidad. Tras la finalizacin con xito de una transaccin, los cambios realizados en la base de datos permanecen, incluso si hay fallos en el sistema.
Estas propiedades reciben el nombre de ACID (del ingls: Atomicity, Consistency, Isolation y Durability). 3.5.1.3 Estados de las transacciones Una transaccin debe estar en uno de los estados siguientes: Activa. El estado inicial; la transaccin permanece en este estado durante su ejecucin. Parcialmente comprometida. Despus de ejecutarse la ltima instruccin. Fallida. Tras descubrir que no puede continuar la ejecucin normal. Abortada. Despus del retroceso de la transaccin y de haber restablecido la base de datos a su estado anterior el comienzo de la transaccin. Comprometida. Tras completarse con xito.
68
Activa
Parcialmente comprometida
Fallida
Comprometida
Abortada
En ausencia de fallos, todas las transacciones se completan con xito. Sin embrago, no siempre ocurre as, una transaccin puede que no siempre termine su ejecucin con xito. Una transaccin de este tipo se denomina abortada. Si se pretende asegurar la propiedad de atomicidad, una transaccin abortada no debe tener efecto sobre el estado de la base de datos. As, cualquier cambio que haya hecho la transaccin abortada sobre la base de datos debe deshacerse. Una vez que se han deshecho los cambios efectuados por la transaccin abortada, se dice que la transaccin est retrocedida. Parte de la responsabilidad del esquema de recuperaciones es gestionar las transacciones abortadas. Una transaccin que termina con xito se dice que est comprometida. Una transaccin comprometida que haya hecho modificaciones, transforma la base de datos llevndola a un nuevo estado consistente, que permanece incluso si hay un fallo en el sistema. Cuando una transaccin se ha comprometido no se pueden deshacer sus efectos abortndola. La nica forma de deshacer los cambios de una transaccin comprometida es ejecutando otra transaccin a la cual se le llama compensadora. 3.5.2 Bitcora Una estructura ampliamente utilizada para guardar las modificaciones de una base de datos es el registro histrico o bitcora. La bitcora es una secuencia de registros que almacena todas las actividades de actualizacin de la base de datos. Para que los registros de la bitcora sean tiles para recuperarse frente a errores de disco o del sistema, la bitcora debe residir en almacenamiento estable. Como aqu es donde se tiene constancia de todas las actividades de la base de datos, el tamao de los datos almacenados en la bitcora puede llegar a ser extremadamente grande. 3.5.2.1 Tipos de bitcora
69
Registro de actualizacin del registro histrico o bitcora. Describe una nica escritura en la base de datos y tiene los siguientes campos: Identificador de la transaccin. Es un identificador nico de la transaccin que realiza la operacin escribir. Identificador del elemento de datos. Es un identificador nico del elemento de datos que se escribe. Normalmente suele coincidir con la ubicacin del elemento de datos en el disco. Valor anterior. Es el valor que tena el elemento de datos antes de la escritura. Valor nuevo. Es el valor que tendr el elemento de datos despus de la escritura.
Existen otros registros del registro histrico o bitcora especiales para registrar sucesos significativos durante el procesamiento de una transaccin, tales como el comienzo de una transaccin y el xito o aborto de la misma. Cuando una transaccin realiza una escritura es fundamental que se cree el registro de la bitcora correspondiente a esa escritura antes de modificar la base de datos. Una vez que el registro de la bitcora existe, se puede realizar la salida de la modificacin a la base de datos si se desea. Adems, es posible deshacer una modificacin que ya haya salido a la base de datos. Se deshar utilizando el campo valor anterior de los registros de la bitcora. 3.6 Diccionario de datos 3.6.1 Concepto Hasta ahora slo hemos considerado la representacin de las relaciones mismas. Un sistema de base de datos relacional necesita mantener datos acerca de las relaciones. Esta informacin se denomina Diccionario de datos o Catlogo de sistema. 3.6.2 Contenido y funcin Los tipos de informacin que el sistema debe almacenar son: Nombres de las relaciones Nombres de los atributos de cada relacin Dominios de los atributos Nombres de las vistas definidas en la base de datos y la definicin de esas vistas. 70
Restricciones de integridad de cada relacin.
Adems de esto, muchos sistemas conservan los siguientes datos de los usuarios del sistema como por ejemplo: Nombres de los usuarios autorizados. Informacin contable acerca de los usuarios. Bitcoras de acceso.
En los sistemas que utilizan estructuras altamente sofisticadas para almacenar relaciones, pueden conservarse adems datos estadsticos y descriptivos acerca de las relaciones: Nmero de tuplos en cada relacin. Mtodo de almacenamiento utilizado para cada relacin.
Puede tambin contener: Nombre de ndices. Nombre de la relacin que se indexa. Atributos sobre los que est el ndice. Tipo de ndice.
3.6.3 Tipos Algunos sistemas de base de datos almacenan esta informacin empleando estructuras de datos y cdigo de propsito especial. Es preferible almacenar los datos acerca de la base de datasen la propia base de datos. Si se utiliza la base de datos para almacenar datos del sistema. Simplificamos la estructura global del sistema y permitimos aprovechar toda la capacidad de aqulla para agilizar el acceso a los datos del sistema.
71
EJERCICIOS 1. Normalice hasta la tercera forma normal (3FN) los siguientes casos: a. Taller automotriz S.A. de C.V. desea dar un mejor servicio a sus clientes por lo que ha decidido generar una base de datos donde almacenar informacin referente a sus clientes y el servicio ofrecido a ellos. Estos son los datos que se quieren guardar: placa_auto color_auto modelo_auto marca_auto clave_dueo nombre telefono clave_paquete_reparacion descripcin_paquete costo_paquete fecha_recepcion_auto fecha_entrega observaciones_reparacion clave_mecanico nombre_mecanico numero_factura rfc_dueo_auto fecha_factura clave_material descripcion_material descuento costo_material NOTAS: El taller ofrece paquetes de reparacin. Cada dueo puede tener ms de un auto. A un auto pueden hacerse ms de un paquete a la vez. Los descuentos pueden ser aplicados a los clientes en el total de su factura y este es un porcentaje que no es fijo. Las observaciones son utilizadas solo en el caso de que el mecnico quiera hacer alguna.
72
b. El invernadero PaPas, S.A. de C.V. ha decidido automatizar su sistema. Un grupo de analistas realiz un estudio minucioso en la empresa y como resultado de ello se obtuvieron los datos que deben ser almacenados en la base de datos: DATO Numero_parcela Hectreas_parcela Cod_cultivo Desc_cultivo Id_lider Nombre_lider Fecha_cosecha Fecha_siembra Cantidad_parcela Cantidad_real Tipo_cultivo Clasificacin_cultivo Especialidad_lider DESCRIPCION Nmero de la parcela asignada a un lider de parcela en particular Nmero de hectreas que ocupa la parcela Cdigo del cultivo Descripcin del cultivo Cdigo del lder o encargado de la parcela Nombre del lider Fecha en que se cosecha la parcela Fecha en que se siembra la parcela Cantidad en kg que se espera cosechar por parcela Cantidad en kg que se cosech realmente de una parcela Tipo de cultivo (temporal o de riego) La clasificacin puede ser hortaliza o en mata Carrera que curs el lider
NOTAS: Cada lder puede estar asignado a una o ms parcelas. Cada parcela puede ser sembrada ms de una vez por ao y con cultivos diferentes.
73
c. La escuela primaria Benito Jurez 2107, desea controlar los datos de sus alumnos por lo que decidi automatizar su sistema de calificaciones encontrando que los datos que deben guardar son los siguientes: Num_alumno Nombre_alumno Direccion_alumno Telefono Fecha_nac_alumno Nivel Calif_nivel Maestro Clave_materia Desc_materia Promedio_nivel Nmero con el que se identifica de forma nica a un alumno Nombre del alumno Direccin del alumno Telfono del alumno Fecha de nacimiento del alumno Nivel que cursa el alumno Calificacin obtenida en el nivel Nombre del maestro Clave de la materia Descripcin de la materia Promedio obtenido por nivel
Se proporciona adems el DFs para este caso:
MATERIA
MAESTRO
NIVEL
ALUMNO
74
2. Representaciones Artsticas, una compaa creada para apoyar eventos de lanzamiento de nuevos productos con personas dedicadas al modelaje, ha decidido tener un mejor control acerca de los datos de todos sus empleados, eventos y clientes. Luego de un anlisis, se acord que se deben guardar los siguientes datos que produzcan la informacin necesaria: Nombre del modelo Direccin del modelo Telfono celular del modelo Nombre del evento Duracin del evento Pago por hora Nombre del evento Clave del cliente Nombre del cliente Direccin del cliente Direccin del evento Fecha del evento Hora inicio del evento Hora fin del evento Percepcin por evento por modelo NOTAS: Cada evento tiene un costo diferente, es decir, cada modelo no percibe siempre lo mismo, depende del evento y el nmero de horas de este. Cada modelo puede estar en ms de un evento en la misma fecha. Cada cliente puede tener ms de un evento. La percepcin que recibe el empleado es el resultado del pago por hora, por el nmero de horas.
75
UNIDAD IV INGENIERA DE REQUERIMIENTOS

4.1 Concepto y clasificacin de lenguajes Un lenguaje de consulta es un lenguaje en el que un usuario solicita informacin de la base de datos. Estos lenguajes son normalmente de ms alto nivel que los lenguajes estndar de programacin. Los lenguajes de consulta pueden clasificarse en: Lenguajes procedimentales. En el que el usuario da instrucciones al sistema para que realice una secuencia de operaciones en la base de datos para calcular el resultado deseado. Lenguajes no procedimentales. En el que el usuario solo describe la informacin deseada sin dar un procedimiento especfico para obtener esa informacin.
4.2 Lenguajes formales 4.2.1 lgebra relacional El lgebra relacional es un lenguaje de consulta procedimental. Consta de un conjunto de operaciones que toman una o dos relaciones como entrada y producen una nueva relacin como resultado. Este lenguaje es tomado como la base para el uso de lenguajes de consulta comerciales. Las operaciones bsicas en el lgebra relacional son: Seleccionar Proyectar Producto cartesiano Operacin seleccionar Selecciona tuplas que satisfacen un predicado dado. Se usa la letra griega minscula () para indicar la seleccin. El predicado se escribe como subndice de . Por ejemplo, para seleccionar las tuplas de la relacin proveedor en las que la ciudad sea PARRAL, escribimos: CIUDAD = PARRAL (Proveedor)
76
Si la relacin Proveedor es como la figura 4.1, entonces la relacin que resulta de la operacin seleccionar es como la que se muestra en la figura 4.2 NumPr S1 S2 S3 S4 S5 Proveedor Nombre Ciudad SALAZAR MEOQUI GUTIERREZ CHIHUAHUA SANTANA PARRAL BERNAL PARRAL CASTRO MEOQUI Llave (NumPr) Fig. 4.1 Nombre SANTANA BERNAL Fig. 4.2 Ciudad PARRAL PARRAL
NumPr S3 S4
En la operacin seleccionar pueden usarse las comparaciones mediante los smbolos matemticos =, , <, >, , , en el predicado de la seleccin. Adems, pueden combinarse varios predicados en un predicado ms complejo usando los conectores y ( ) y o (V). Por ejemplo, tomando como base le relacin de la fig. 4.1, mostrar todas las tuplas en las que la ciudad sea diferente de MEOQUI y diferente adems a PARRAL, la consulta se escribira: CIUDAD MEOQUI CIUDAD PARRAL (Proveedor) como resultado obtendramos la relacin: NumPr S2 Nombre Ciudad GUTIERREZ CHIHUAHUA Fig. 4.3
77
Operacin proyectar Es una operacin unitaria que devuelve su relacin argumento con ciertas columnas omitidas. Puesto que una relacin es un conjunto, se eliminan todas las filas duplicadas. La operacin proyectar que indica por la letra griega pi (). Se indican los atributos que queremos que aparezcan en el resultado como subndice de . Por ejemplo, supngase que queremos listar el nombre de todos los proveedores de la relacin Proveedor. Escribimos: NOMBRE (Proveedor) El resultado de esta operacin sera: Nombre SALAZAR GUTIERREZ SANTANA BERNAL CASTRO Fig. 4.4
Operacin producto cartesiano Hasta ahora hemos visto operaciones que nos permiten extraer informacin nicamente de una relacin a la vez. Para combinar la informacin de varias relaciones usamos el producto cartesiano, representada por una cruz (x). Esta es una operacin binaria, es decir, solo podemos hacer combinaciones de dos en dos; si se necesitan ms relaciones para combinar la informacin, primero se debe hacer una operacin binaria, y el resultado con otra relacin para generar otra combinacin binaria y as sucesivamente. Por ejemplo, supngase que queremos encontrar todas las partes que nos ha embarcado el proveedor SALAZAR, as como la cantidad de stas. La figura 4.5 muestra la relacin r = Embarques x Proveedor Embraques. NumPr S1 S1 S1 S2 S2 S3 S4 NumPa P1 P2 P3 P1 P3 P2 P2 Cant 10 20 10 5 15 20 15 Proveedor. NumPr S1 S1 S1 S1 S1 S1 S1 Nombre SALAZAR SALAZAR SALAZAR SALAZAR SALAZAR SALAZAR SALAZAR Ciudad MEOQUI MEOQUI MEOQUI MEOQUI MEOQUI MEOQUI MEOQUI 78
S5 S1 S1 S1 S2 S2 S3 S4 S5 S1 S1 S1 S2 S2 S3 S4 S5 S1 S1 S1 S2 S2 S3 S4 S5 S1 S1 S1 S2 S2 S3 S4 S5
P1 P1 P2 P3 P1 P3 P2 P2 P1 P1 P2 P3 P1 P3 P2 P2 P1 P1 P2 P3 P1 P3 P2 P2 P1 P1 P2 P3 P1 P3 P2 P2 P1
S1 SALAZAR S2 GUTIERREZ S2 GUTIERREZ S2 GUTIERREZ S2 GUTIERREZ S2 GUTIERREZ S2 GUTIERREZ S2 GUTIERREZ S2 GUTIERREZ S3 SANTANA S3 SANTANA S3 SANTANA S3 SANTANA S3 SANTANA S3 SANTANA S3 SANTANA S3 SANTANA S4 BERNAL S4 BERNAL S4 BERNAL S4 BERNAL S4 BERNAL S4 BERNAL S4 BERNAL S4 BERNAL S5 CASTRO S5 CASTRO S5 CASTRO S5 CASTRO S5 CASTRO S5 CASTRO S5 CASTRO S5 CASTRO Fig. 4.5 Resultado de Embarques x Proveedor
20 10 20 10 5 15 20 15 20 10 20 10 5 15 20 15 20 10 20 10 5 15 20 15 20 10 20 10 5 15 20 15 20
MEOQUI CHIHUAHUA CHIHUAHUA CHIHUAHUA CHIHUAHUA CHIHUAHUA CHIHUAHUA CHIHUAHUA CHIHUAHUA PARRAL PARRAL PARRAL PARRAL PARRAL PARRAL PARRAL PARRAL PARRAL PARRAL PARRAL PARRAL PARRAL PARRAL PARRAL PARRAL MEOQUI MEOQUI MEOQUI MEOQUI MEOQUI MEOQUI MEOQUI MEOQUI
El esquema de relaciones sera: (Embarques. NumPr, Embarques. NumPa, Embarques. Cant, Proveedor. NumPr, Proveedor. Nombre, Proveedor. Ciudad) Es decir, simplemente se listan los atributos de las dos relaciones y adjuntamos el nombre de la relacin de la que el atributo procede originalmente. Se recomienda utilizar el nombre de la relacin y no solo el del atributo por si ocurriera que dos atributos coincidan con el mismo nombre.
79
El resultado es una relacin bastante grande, dada por: n1 tuplas en Embarques y n2 en Proveedor, entonces existen n1 n2 formas de elegir un par de tuplas. En general, si tenemos una relacin r1 con cardinalidad a, y una relacin r2 con cardinalidad b, la cardinalidad (numero de tuplas de la relacin) debe ser igual a: a x b. Para el ejemplo anterior, la cardinalidad de la relacin Embarques es 8 y la relacin Proveedor es 5, entonces el nmero de tuplas (o cardinalidad) de la relacin Embarques x Proveedor ser 40. Volviendo a la pregunta inicial encontrar todas las partes que nos ha embarcado el proveedor SALAZAR, as como la cantidad de stas, tendramos: Embarques.NumPa, Embarques.Cant, Proveedor.Nombre ( Proveedor.Nombre = SALAZAR (Embarques x Proveedor)) Entonces el resultado de esta operacin sera: NumPa P1 P2 P3 P1 P3 P2 P2 P1 Cant 10 20 10 5 15 20 15 20 Fig. 4.6 Nombre SALAZAR SALAZAR SALAZAR SALAZAR SALAZAR SALAZAR SALAZAR SALAZAR
Sin embrago, la columna NumPa puede contener partes que no hayan sido embarcadas por el proveedor SALAZAR, ya que el producto cartesiano toma todos los pares posibles de una tupla de Embarques con una tupla de Proveedor). Solo algunas tuplas cumples con las partes que realmente nos embarc el proveedor SALAZAR. Entonces escribimos: Embarques.NumPa, Embarques.Cant, Proveedor.Nombre ( Proveedor.Nombre = SALAZAR Embarques.NumPr (Embarques x Proveedor)) Lo cual dara como resultado: NumPa P1 P2 P3 Cant Nombre 10 SALAZAR 20 SALAZAR 10 SALAZAR Fig. 4.7
Proveedor.NumPr =
80
4.2.2 Clculo relacional El clculo relacional es un lenguaje de consultas no procedimental. Describe la informacin deseada sin dar un procedimiento especfico para obtener esa informacin. Una consulta en el clculo relacional de tuplas se expresa como: { t | P(t)} es decir, el conjunto de todas las tuplas t, tal que el predicado P, es verdadero para t. Siguiendo
4.2.3 Optimizacin de consultas Tanto el lgebra como el clculo relacional, son de gran utilidad para entender los lenguajes de consulta, sin embargo, son meramente didcticos, no pueden ser introducidos en un procesador y esperar un resultado, son nicamente la base para entender con mayor facilidad lenguajes como SQL, que veremos luego con mayor detalle.
81
4.3 SQL Los lenguajes formales descritos en la seccin anterior, proporcionan una notacin concisa para representar consultas. Sin embrago, los sistemas comerciales de base de datos requieren un lenguaje de consultas ms amigable para el usuario. Aunque nos referimos a SQL como lenguajes de consulta, contienen, muchas otras capacidades adems de consultar la base de datos. Estas incluyen caractersticas para definir la estructura de los datos, caractersticas para modificar los datos de la base de datos y caractersticas para especificar las restricciones de seguridad. Existen numerosas versiones de SQL. La versin original fue desarrollada en el San Jos Research Laboratory de IBM. Este lenguaje originalmente llamado Sequel, fue implementado como parte del proyecto del Sistema R en los primero aos de la dcada de los setenta. El lenguaje Sequel ha evolucionado desde entonces, y su nombre ha cambiado a SQL (Structured Query Language) que significa Lenguaje Estructurado de Consultas. Ahora numerosos productos soportan el lenguaje SQL. Aunque las versiones del producto de SQL difieren en varios detalles de los lenguajes, las diferencias son, para la mayora, sin importancia. SQL se ha establecido claramente como EL lenguaje de base de datos relacional estndar. Este lenguaje consta de varias partes: Lenguaje de definicin de datos (DDL) Lenguaje de manipulacin de datos (DML) Lenguaje de control de datos
Otras partes de SQL incluyen: Definicin de vista. El SQL DDL incluye rdenes para definir vistas Autorizacin. El SQL incluye rdenes para especificar derechos de acceso a relaciones y vistas. Integridad. El lenguaje Sequel del Sistema R original incluye rdenes para especificar restricciones de integridad complejas. Versiones recientes de SQL, incluyendo el ANSI estndar, proporcionan nicamente una forma limitada de comprobacin de integridad.
82
4.3.1 Lenguaje de definicin de datos El SQL DDL proporciona rdenes para definir esquemas de relacin, eliminar relaciones, crear ndices y modificar esquemas de relacin. Algunos comandos soportados por el DDL son los siguientes: Creacin de tablas. Utilizar el siguiente comando: CREATE TABLE <nombre_tabla> (<definicin_columna> [,<definicin_columna>] [,<definicin_llave_primaria>] [,<definicin_atributo_extranjero> [,<definicin_atributo_extranjero>] ] );
Donde: <definicin_columna> ::= nombre_columna tipo [NOT NULL] <definicin_llave_primaria> ::= PRIMARY KEY (<nombres_columnas>) <definicin_atributo_extranjero>::= FOREING KEY (<nombre_columna>) REFERENCES <nombre_tabla> Ejemplos: 1. Crear la tabla Proveedor CREATE TABLE Proveedor (NumPr CHAR (2) NOT NULL, Nombre CHAR (10) NOT NULL, Ciudad CHAR (12), PRIMARY KEY (NumPr) ); 2. Crear la tabla Embarques CREATE TABLE Embarques (NumPr CHAR (2) NOT NULL, NumPa CHAR (2) NOT NULL, Cant INTEGER, PRIMARY KEY (NumPr, NumPa), FOREING KEY (NumPr) REFERENCES Proveedor, FOREING KEY (NumPa) REFERENCES Partes );
83
Alterar una tabla. Utilizaremos el siguiente comando: ALTER TABLE <nombre_tabla> ADD <nombre_columna> <tipo>;
Ejemplo: 1. Agregar el atributo telefono a la tabla Proveedor ALTER TABLE Proveedor ADD telefono; Borrar una tabla. Se utiliza el comando: DROP TABLE <nombre_tabla>; Crear ndices. Mediante el comando: CREATE [UNIQUE] INDEX <nombre_indice> ON <nombre_tabla> (<nombre_columna> [A/D] [,<nombre_columna> [A/D]...] ); Ejemplos: 1. CREATE UNIQUE INDEX NumPrntx ON Proveedor (NumPr); Crea el ndice NumPrntx en la tabla Proveedor a partir de la columna NumPr 2. CREATE UNIQUE INDEX NPrNPantx ON Embarques (NumPr,NumPa); Crea el ndice NumPrntx en la tabla Proveedor a partir de la columna NumPr Borrar un ndice. Se utiliza la instruccin: DROP INDEX <nombre_indice>;
84
4.3.2 Lenguaje de manipulacin de datos El DML nos permite realizar consultas y dar mantenimiento a la base de datos (altas, bajas y cambios). En realidad es el DML en donde SQL es ms poderoso. Para los ejemplos que se mostrarn, utilizaremos las siguientes tablas: NumPr S1 S2 S3 S4 S5 Proveedor Nombre Ciudad SALAZAR MEOQUI GUTIERREZ CHIHUAHUA SANTANA PARRAL BERNAL PARRAL CASTRO MEOQUI Llave (NumPr)
Ciudad Ciudad Status MEOQUI 20 CHIHUAHUA 10 PARRAL 30 MEOQUI 20 Llave (Ciudad) Partes NumPa DescPa Color P1 TUERCA ROJO P2 TORNILLO AZUL P3 RONDANA ROJO Llave primaria (NumPa) Embarques NumPr NumPa Cant S1 P1 10 S1 P2 20 S1 P3 10 S2 P1 5 S2 P3 15 S3 P2 20 S4 P2 15 S5 P1 20 Llave primaria (NumPr,NumPa)
85
Operaciones de consulta
La operacin bsica de consulta en SQL, es el operador SELECT, el cual tiene la siguiente estructura bsica: SELECT <atributo(s)> FROM <tabla(s)> [WHERE <condicin(es)>]; Ejemplos: 1. Obtenga todos los datos de todos los proveedores SELECT NumPr, Nombre, Ciudad FROM Proveedor; Esta consulta tambin puede escribirse: SELECT * FROM Proveedor; El asterisco (*) despus del SELECT sustituye todos los atributos de la tabla Note que todas las instrucciones del SQL terminan con un punto y coma (;) 2. Obtenga los nmeros de parte de todas las partes embarcadas SELECT DISTINCT NumPa FROM Embarques; El operador DISTINCT permite mostrar el resultado de la consulta sin repetir aquellos atributos que aparezcan mas de una vez, en este ejemplo el resultado sera: P1 P2 P3 3. Obtenga los nmeros de proveedores que vivan en PARRAL SELECT NumPr FROM Proveedor WHERE Ciudad = PARRAL;
86
4. Obtenga nombre y ciudad de proveedor que vivan en MEOQUI y en orden descendente por nmero SELECT FROM WHERE ORDER BY Nombre, Ciudad Proveedor (Ciudad = MEOQUI) NumPr DESC;
El operador ORDER BY permite mostrar el resultado de la consulta ordenado, ya sea de forma descendente (DESC) o ascendente (ASC). 5. Para cada parte embarcada, obtenga el nmero y nombre de la parte SELECT DISTINCT Embarques.NumPa, Partes.Nombre FROM Embarques, Partes WHERE Embarques.NumPa = Partes.NumPa; Esta consulta involucra dos tablas por lo que es importante que al nombrar los atributos, se utilice el nombre de la tabla punto (.) nombre del atributo, pues es importante diferenciarlos. 6. Obtenga los nombres de los proveedores que hayan embarcado la parte P2 SELECT DISTINCT Proveedor.Nombre FROM Proveedor, Embarques WHERE Embarques.NumPa = P2 AND Proveedor.NumPr = Embarques.NumPr; Cuando en una consulta se involucra mas de una tabla, una de las condiciones debe ser el atributo que comparten o mediante el cual se relacionan, en este caso NumPr. Otra solucin a este ejemplo podra ser utilizando el operador ANY que funciona de la siguiente manera: El operador: f <operador-relacional> ANY (SELECT) Es verdadero si y solo si el valor de f cumple el <operador relacional> (>, <, <>, >=, <=, =) en al menos un valor de los regresados por el SELECT. Ejemplo: SELECT Proveedor.Nombre FROM Proveedor WHERE Proveedor.Num.Pr = ANY (SELECT Embarques.Num.Pr FROM Embarques WHERE NumPa = P2); 87
7. Obtenga los nombres de proveedor que hayan embarcado al menos una parte de color rojo SELECT Nombre FROM Proveedor WHERE NumPr IN (SELECT DISTINCT NumPr FROM Embarques WHERE NumPa IN (SELECT NumPa FROM Partes WHERE Color = ROJO)); El operador = ANY e IN tienen la misma funcin 8. Resuelva el ejemplo 6 utilizando el operador IN SELECT Nombre FROM Proveedor WHERE P2 IN (SELECT NumPa FROM Embarques WHERE Proveedor.NumPr = Embarques.NumPr); 9. Obtenga todas las parejas de nmeros de proveedor tal que los dos proveedores estn localizados en la misma ciudad SELECT Primera.NumPr, Segunda.NumPr FROM Proveedor Primera, Proveedor Segunda WHERE (Primera.Ciudad = Segunda.Ciudad) AND (Primera.NumPr < Segunda.NumPr); Pare este ejemplo, utilizamos Primera y Segunda como tablas auxiliares idnticas a Proveedor para poder hacer comparaciones en una misma tabla. 10. Obtener el nombre de los proveedores que no hayan embarcado la parte P2 SELECT FROM WHERE AND DISTINCT Proveedor.Nombre Proveedor, Embarques (Embarques.NumPa <> P2) (Embarques.NumPr = Proveedor.NumPr);
Este mismo ejemplo puede resolverse utilizando el operador ALL. El operador *ALL (donde * es cualquiera de los operadores <, >, <>, >=, <=, =) se define con la condicin: f * ALL (SELECT )
88
Toma el valor de verdadero si y solo si f cumple el operador relacional *, en todos los valores regresados por el SELECT Ejemplo: SELECT Nombre FROM Proveedor WHERE P2 <> ALL (SELECT NumPa FROM Embarques WHERE NumPr = Proveedor.NumPr);
Funciones integradas en SQL
SQL proporciona el siguiente conjunto de funciones integradas: COUNT. Cuenta el nmero de registros de una tabla. SUM. Suma los valores de una columna. AVG. Calcula el promedio de los valores de una columna. MAX. Obtiene el valor ms grande de una columna. MIN. Obtiene el valor ms pequeo de una columna.
Ejemplos: 1. Obtenga el nmero total de proveedores SELECT COUNT (*) FROM Proveedores; 2. Obtenga el nmero total de proveedores que han hecho embarques SELECT COUNT (DISTINCT NumPr) FROM Embarques; 3. Obtenga la cantidad total de la parte P2 que ha sido embarcada SELECT SUM (Cant) FROM Embarques WHERE NumPa = P2; 4. Obtenga el nmero mximo de proveedor SELECT MAX (NumPr) FROM Proveedor;
89
5. Obtener la cantidad total embarcada por cada una de las partes SELECT NumPa, SUM (Cant) FROM Embarques GROUP BY NumPa; En este Query o consulta se est haciendo uso de la funcin GROUP BY. Esta opcin permite a SQL agrupar la informacin respecto a los campos indicados. Cuando se tiene un agrupamiento, los campos seleccionados en el SELECT se aplican a nivel de grupo, no a nivel de registro. Para este ejemplo, se desplegar el nmero de parte, NumPa y la suma de sus cantidades (el SUM funciona ahora por cada grupo). 6. Obtener el promedio de partes P2 que han sido embarcadas SELECT AVG (Cant) FROM Embarques WHERE NumPa = P2; Utilice el operador AVG solo con columnas de valor numrico
4.3.3 Lenguaje de control de datos El DML de SQL incluye tres operaciones de actualizacin a una tabla: UPDATE (Modificacin) INSERT (Insertar) DELETE (Borrar) Ejemplos: 1. Cambie el color de la parte P2 a amarillo UPDATE Partes SET Color = AMARILLO WHERE NumPa = P2; 2. Ponga la cantidad de productos embarcados en cero para todos los proveedores de MEOQUI UPDATE Embarques SET Cant = 0 WHERE MEOQUI = (SELECT Ciudad FROM Proveedor WHERE Proveedor.NumPr = Embarques.NumPr); 3. Inserte la parte P4 de nombre MARTILLO, color GRIS INSERT INTO Partes < P4, MARTILLO, GRIS >;
90
4. Borre al proveedor S1 DELETE Proveedor WHERE NumPr = S1;
4.4 Otros lenguajes Existen muchos lenguajes de consulta, algunos solo emulan un manejador de base de datos como Fox Pro, estos lenguajes presentan algunas diferencias en la sintaxis de los comandos, sin embrago, la base es SQL. Query-by-Example (QBE) es el nombre de otro lenguaje de manipulacin de datos y del sistema de base de datos que incluye este lenguaje.
91
EJERCICIOS 1. A partir de las siguientes tablas, elabore las siguientes consultas utilizando lgebra relacional. PELICULA Nombre Clasificacin Tipo Sntesis Precio Actor_principal Num_proveedor Compaa_productora NOTA_RENTA Folio Fecha Clave_socio Clave_pelicula SOCIO Clave Nombre Direccion Telefono Fecha_suscripcion PROVEEDOR Numero Nombre Direccion Telefono Ciudad a. Mostrar el nombre de las pelculas cuyo tipo sea DRAMA b. Mostrar el nombre de las pelculas que ha protagonizado JULIA ROBERTS
92
2. Con base en esas mismas tablas, utilice SQL para generar las siguientes consultas: a. Mostrar quien ha actuado pelculas del mismo tipo que la actriz PAOLA ORTEGA b. Mostrar las pelculas que rent el 27 de Julio del 2008 ANTONIO DIAZ c. Mostrar que proveedores han surtido las pelculas clasificacin A d. Mostrar quienes se han suscrito al videoclub en la misma fecha de CARLOS MURILLO e. Mostrar la direccin de los socios que han rentado pelculas clasificacin B f. Mostrar quines han rentado la misma pelcula clasificacin C que rento el 10 de Enero MARIA TORRES g. Mostrar un listado de pelculas tipo COMEDIA, clasificacin A que contenga clave, nombre y actor principal h. En que fechas se suscribieron al videoclub los socios que han rentado pelculas este mes
93
3. Utilizando las siguientes tablas, realice lo que se pide en SQL CLIENTE Cdigo Nombre Direccion Telefono Ciudad RFC ARTICULO Clave Descripcin Precio_unitario Color Clave_proveedor PROVEEDOR Clave_proveedor Nombre Direccion Telefono Ciudad VENTA Folio Fecha Clave_articulo Cantidad RFC_cliente NOTA: Las fechas tienen el formato AAAAMMDD
a. Crear todas las tablas b. Insertar un valor en cada tabla c. Mostrar los artculos vendidos a JOSE PEREZ d. Mostrar el artculo ms caro e. Mostrar el promedio de precio de los artculos f. Mostrar el proveedor de los artculos vendidos el 1 DE ENERO DEL 2000
94
g. Mostrar una lista de clientes con sus datos en orden alfabtico h. Mostrar los artculos color ROJO vendidos el mes de marzo del 2001 i. Mostrar el nombre de los clientes a los que se les vendi el ao 2002 j. Mostrar el nombre del artculo que se ha vendido en una mayor cantidad en una sola venta k. Borrar los artculos que provee JUAN VALDEZ l. Modificar la direccin del proveedor LUCIA GOMEZ a RAMON VELARDE 5 en la misma ciudad. m. Mostrar cuantos cuntos artculos diferentes existen
95

Fundamentos de Base de Dato Ing 1

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Fundamentos de Base de Dato Ing 1

Загружено:

Авторское право:

Доступные форматы

Fundamentos de base de datos

UNIDAD I CONCEPTOS DE BASE DE DATOS

Dato Dato Dato Dato Dato

Fundamentos de base de datos

Fundamentos de base de datos

Fundamentos de base de datos

Fundamentos de base de datos

1.4 Arquitectura de base de datos

Fundamentos de base de datos

Fundamentos de base de datos

Fundamentos de base de datos

Nivel lgico Nivel fsico

Figura 1.3 Los tres niveles de abstraccin

Fundamentos de base de datos

Fundamentos de base de datos

Fundamentos de base de datos

Fundamentos de base de datos

Programadores de aplicaciones escribe Programas de aplicacin

Usuarios Sofisticados (analistas) usa Herramientas de consulta

Administrador de Bases de datos usa Herramientas de administracin

Intrprete del LDD

Compilador del LMD y organizador Procesador de consultas

Gestor de memoria intermedia

Gestor de autorizacin e integridad

ndices Datos estadsticos

Diccionario de datos Almacenamiento en disco

Fundamentos de base de datos

Servidor de aplicaciones Sistema de bases de datos servidor Sistema de bases de datos

Arquitectura de dos capas

Arquitectura de tres capas

Fundamentos de base de datos

Figura 1.6 Estructura general

Fundamentos de base de datos

Fundamentos de base de datos

Fundamentos de base de datos

Fundamentos de base de datos

UNIDAD II MODELOS DE DATOS

Fundamentos de base de datos

Fundamentos de base de datos

Fundamentos de base de datos

Fundamentos de base de datos

Fundamentos de base de datos

Figura 2.2 Relacin una a una

Figura 2.3 Relacin una a muchas

Fundamentos de base de datos

Fundamentos de base de datos

Fundamentos de base de datos

Fundamentos de base de datos

Fundamentos de base de datos

Sexo Maestro Nombre N_con trol Fecha_na c Hora Aula

Figura 2.9 Diagrama E-R con una relacin ternaria

Fundamentos de base de datos

Fundamentos de base de datos

Figura 2.11 Especializacin

Fundamentos de base de datos

Fundamentos de base de datos

Figura 2.13 Diagrama E-R con agregacin

Fundamentos de base de datos

Fundamentos de base de datos

Fundamentos de base de datos

Ciudad Factura Importe

Articulo *Clave Desc Precio * Llave

Arp *Clave *Folio

Proveedor *Numero Ciudad Nombre

Articulo Clave Desc Precio Llave

Arp Clave Folio

Co Folio Clave *Numero Fecha

Arp Clave Folio