Universidad Central de Venezuela Facultad de Ciencias Escuela de Computacin

Lecturas en Ciencias de la Computacin ISSN 1316-6239

SISTEMAS DE BASES DE DATOS

Concettina Di Vasta y Rossana Daz

ND 2001- 02

Centro de Investigacin en Sistemas de Informacin CISI. Caracas Abril 2001

ND 2001- 02 Lecturas en Ciencias de la Computacin ISSN 1316-6239

SISTEMAS DE BASES DE DATOS

Concettina Di Vasta* y Rossana Daz*
Abril, 2001

Resumen Este trabajo presenta una visin general acerca de las bases de datos, permitiendo inicialmente comparar el procesamiento de base de datos con el procesamiento de archivos para destacar las ventajas y desventajas de cada uno de estos enfoques. Posteriormente se exponen los aspectos esenciales en cuanto a su definicin y caractersticas. En el captulo 1 se describen los conceptos bsicos de base de datos, as como las caractersticas de una Base de Datos, los usuarios de la misma y las operaciones que se pueden realizar sobre una base de datos. Luego se define el Sistema Manejador de Base de Datos (SMBD), destacndose sus ventajas y limitaciones y las funciones del Administrador de Base de Datos. El captulo 2 se centra en los mtodos de Organizacin de Base de Datos. Entre estos mtodos se estudiarn los Modelos Lgicos basados en Registros: Modelo Relacional, Modelo de Red y Modelo Jerrquico; los Modelos Lgicos basados en Objetos, enfocndose principalmente en el Modelo Entidad/Relacin y por ltimo, los Modelos Fsicos de Datos. El captulo 3 presenta cmo realizar el Diseo Conceptual de una Base de Datos, especificando el diseo ascendente: Normalizacin y el diseo descendente: Modelo Entidad/Relacin. Palabras claves: Base de Datos, Sistema Manejador de Base de datos (SMBD), Administrador de Base de Datos, Modelo, Normalizacin, Modelo Entidad/Relacin.

* Centro de Investigacin en Sistemas de Informacin, CISI. Escuela de Computacin, Facultad de Ciencias, Universidad Central de Venezuela. Los Chaguaramos, Apartado 47002, Caracas, 1041-A. Venezuela. e-mail: tdivasta@kuaimare.ciens.ucv.ve rdiaz@kuaimare.ciens.ucv.ve

INDICE

INTRODUCCIN CAPTULO I. BASE DE DATOS 1.1. Procesamiento de Archivos Vs. Procesamiento de Base de Datos 1.2. Qu es una Base de Datos? 1.3. Caractersticas de una Base de Datos 1.4. Desventajas de una Base de Datos 1.5. Lenguajes de Bases de Datos. 1.6. Qu es un Sistema de Base de Datos? 1.7. Arquitectura para Sistemas de Bases de Datos 1.8. Sistema Manejador de Base de Datos (SMBD) 1.9. Administrador de BD (DBA: Database Administrator) CAPTULO II. MTODOS DE ORGANIZACIN DE BD. 2.1. Modelos Lgicos basados en Registros. 2.1.1. Modelo Relacional. 2.1.2. Modelo de Red. 2.1.3. Modelo de Jerrquico. 2.2. Modelos Lgicos basados en Objetos. 2.2.1. Modelo Entidad/Relacin. 2.3. Modelos Fsicos de Datos. CAPTULO III. DISEO CONCEPTUAL DE BASE DE DATOS. 3.1.- Diseo ascendente/descendente. 3.2.- Enfoque descendente 3.2.1. Modelo Entidad-Relacin. 3.2.2. Modelo Entidad-Relacin Extendido. 3.3.- Enfoque Ascendente. 3.3.1. Normalizacin como mtodo de diseo ascendente. 3.3.2 Dependencia funcional. 3.3.3. Primera Forma Normal (1FN) 3.3.4. Segunda Forma Normal (2FN) 3.3.5. Tercera Forma Normal (3FN) 3.3.6. Forma normal Boyce/Codd 3.3.7. Cuarta forma normal. 3.3.8. Quinta forma normal. CONCLUSIONES BIBLIOGRAFA

4 5 5 8 8 8 8 9 13 15 19 21 21 21 22 22 23 23

24
25 26 27 29 39 41 42 42 43 45 45 46 47 47 49 50

INTRODUCCIN

Toda empresa u organizacin necesita tener un control centralizado de sus datos, y las computadoras operan sobre datos que han sido organizados dentro de agrupamientos lgicos. Normalmente, los datos que las computadoras manejan estn organizados en agrupamientos lgicos, para que los procesos sean efectivos y los resultados obtenidos sean tiles. Este documento se ha estructurado en un primer captulo en el cual se define Base de Datos, se estudiar en detalle las caractersticas de las bases de datos, los distintos usuarios y operaciones sobre las bases de datos, adems se estudiar los sistemas manejadores de base de datos, sealando sus ventajas y limitaciones, as como las funciones del administrador de Base de Datos. En el siguiente captulo se hace una revisin ms detallada de los distintos mtodos que permiten la organizacin de una base de datos, con el fin de escoger el modelo que ms se ajuste a los requerimientos de informacin. Por ltimo se destaca como se lleva a cabo el diseo conceptual de una base de datos, estudiando el diseo descendente, para lo cual se analiza el Modelo Entidad/Relacin, con sus caractersticas y estructura; y el diseo ascendente, estudiando la normalizacin y las dependencias funcionales, el cual permite dado un esquema inicial encontrar un equivalente que evite los problemas de redundancia y anomalas de insercin, de eliminacin y de actualizacin.

CAPITULO I. BASE DE DATOS 1.1. Procesamiento de Archivos Vs. Procesamiento de Base de Datos Para realizar el procesamiento de la data con el objeto de obtener informacin utilizando tecnologa computacional se puede ver dos enfoques: 1.- Sistemas de Procesamiento de Archivos. 2.- Sistemas de Procesamiento de Base de Datos. Sistemas de Procesamiento de Archivos. Los Sistemas de Procesamiento de Archivos almacenan grupos de registros en archivos separados, los cuales se procesan por separado, de forma independiente, como se muestra en la Figura # 1.

Programa de aplicacin para clientes

Archivo clientes

Servicio de Clientes

Programa de aplicacin para ordenes

Archivo ordenes

Entrada de Ordenes
Figura # 1. Sistema de Procesamiento de Archivos

En este enfoque, cada aplicacin o rea tiene su propio conjunto de archivos maestros y de transacciones, que se usan para almacenar, procesar y recuperar datos. Los archivos y programas para cada aplicacin se disean especficamente para esa aplicacin. Cada rea funcional de una organizacin tiene su propio conjunto de archivos y programas para manipular esos datos. Este enfoque se centra alrededor de transacciones y archivos maestros independientes para cada aplicacin. La manera segn la cual se almacenan los datos (estructura de registros) no puede ser alterada fcilmente.

Problemas de los Sistemas de Procesamiento de Archivos:

1.- Redundancia de Datos: consiste en el almacenamiento de informacin idntica en mltiples archivos. Los mismos datos han sido registrados para ms de una aplicacin. Almacenar y mantener los mismos datos en 2 archivos en vez de uno, es ms costoso ya que requiere doble espacio de almacenamiento y doble cantidad de trabajo. Esto puede llevar a inconsistencia de los datos, es decir, las diversas copias de los mismos datos no concuerdan entre s. Ejemplo: Registro de Cuentas de Ahorro y de Cuentas Corrientes, informacin de direccin, telfono, etc.. 2.- Falta de integridad de los datos: Los valores de datos almacenados en la BD deben satisfacer ciertos tipos de restricciones de consistencia, ya que una coleccin de datos tiene integridad si es lgicamente consistente, esto significa que la data duplicada debe ser consistente entre s, y para lograr esto, cada vez que se actualice un elemento de dato debe actualizarse en todos los sitios donde se encuentra. Si existe mucha redundancia el hecho de garantizar integridad conlleva a un procesamiento excesivo. Por lo cual, podemos decir, que la redundancia de datos puede llevar a inconsistencia de los datos, las diversas copias de los mismos datos no concuerdan entre s. Es obvio que una base de datos en estado inconsistente puede proporcionar informacin incorrecta o contradictoria a sus usuarios. 3.- Dificultad en el acceso a los datos: Los entornos de procesamiento de archivos convencionales no permiten recuperar los datos necesarios de una forma prctica y eficiente. Hacen falta sistemas de recuperacin de datos ms adecuados para el uso general. 4.- Carencia de flexibilidad: Cambiar algunas caractersticas de un archivo frecuentemente resulta extremadamente difcil, pues cualquier programa u otros archivos que accedan al primero tambin deben ser cambiadas. Esto reduce la flexibilidad, posibilidad de hacer un cambio rpidamente. Como los datos estn dispersos en varios archivos, y los archivos pueden estar en diferentes formatos, es difcil escribir nuevos programas de aplicacin para recuperar los datos correspondientes. 5.- Interdependencia del Programa y archivos de datos: Cambiar las caractersticas de los campos en un archivo determinado suele ser difcil o imposible. Si un campo se ha de agregar, borrar o cambiar debe ser creado primero un nuevo archivo que refleje el cambio; y luego debe crearse un programa que lea un registro del archivo anterior y lo copie en su nuevo formato al nuevo archivo. Si se ha agregado un nuevo campo al registro, la informacin debe ser introducida manualmente para cada registro. 6.- Problemas de atomicidad: En muchas aplicaciones es crucial asegurar que, si se produce algn fallo, los datos se restauren al estado consistente que exista antes de la falla. Hay transaccin como por ejemplo, la transferencia de fondos que debe ser atmica, es decir, debe ocurrir en su totalidad o no ocurrir en lo absoluto. Resulta difcil agregar la atomicidad en los sistemas convencionales de procesamiento de archivos.

7.- Anomalas en el acceso concurrente. Para aumentar el rendimiento global del sistema y obtener una respuesta ms rpida, muchos sistemas permiten que varios usuarios actualicen los datos simultneamente. Es posible que la interaccin de actualizaciones concurrentes que puedan dar lugar a datos inconsistentes, es por ello que el sistema debe mantener alguna forma de supervisin. Pero en el caso de sistemas convencionales de archivos es difcil ofrecer supervisin, ya que muchos programas de aplicacin diferentes que no se han coordinado con anterioridad pueden tener acceso a los datos. 8.- Problemas de seguridad: No todos los usuarios deben poder acceder a todos los datos. Ejemplo: Sistema bancario, el personal de las nminas necesita ver informacin acerca de los distintos empleados del banco, no ver informacin sobre las cuentas. Sistemas de Procesamiento de Base de Datos. La tecnologa de base de datos fue desarrollada para superar las limitaciones y problemas de los sistemas de procesamiento de archivos. En los sistemas de procesamiento de base de datos se aade un nuevo componente (Figura # 2), el Sistema Manejador de Base de Datos (SMBD), que es un conjunto de programas o tambin hardware que superan las desventajas del procesamiento de archivos.
Programa de aplicacin para clientes Servicio de Clientes Clientes Ordenes

SMBD Programa de aplicacin para ordenes

Entrada de Ordenes

Figura # 2. Sistema de Procesamiento de Base de Datos Ventajas de los Sistemas de Procesamiento de Base de Datos. * Es posible disminuir la redundancia. En los sistemas sin base de datos cada aplicacin tiene sus propios archivos privados. Esto puede provocar considerable redundancia en los datos almacenados, con el consecuente desperdicio de espacio de almacenamiento. Como los archivos pueden integrarse y disminuir la redundancia. No se pretende que toda la redundancia pueda o deba necesariamente ser eliminada. En ocasiones hay razones slidas, tcticas o del negocio, para mantener varias copias distintas de los mismos datos. Se sugiere que cualquier redundancia debe ser controlada cuidadosamente; es decir, el SMBD debe estar al tanto de ella, si es que existe y debe asumir la responsabilidad de propagar las actualizaciones. * Es posible mantener la integridad, evitando la inconsistencia.

En un sistema de base de datos, toda la data est almacenada en un slo sitio llamado Base de Datos (BD). Un programa de aplicacin puede preguntar al SMBD para acceder cualquier tipo de data. El problema de integridad radica en asegurar que la informacin de la base de datos sea correcta. Ejemplo: la inconsistencia entre dos entradas que supuestamente representan el mismo hecho es un ejemplo de falta de integridad. * Es posible compartir los datos. El compartir datos implica no slo que las aplicaciones ya existentes pueden compartir la informacin de la base de datos, sino tambin que se pueden desarrollar aplicaciones nuevas para trabajar con los mismos datos almacenados. * Es posible hacer cumplir las normas. Al tener un control centralizado de la base de datos, el Administrador de la Base de Datos (DBA) puede garantizar la observancia de todas las normas aplicables para la representacin de los datos. * Es posible aplicar restricciones de seguridad. Al tener jurisdiccin completa sobre la base de datos, el DBA a) puede asegurar que el acceso a la base de datos sea slo a travs de los canales apropiados y, por tanto, b) puede definir las verificaciones de seguridad a realizar cuando se intente acceder a informacin delicada.

1.2. Qu es una Base de Datos? Repositorio centralizado de datos que permite almacenar y organizar hechos eventos y restituirlos a demanda del usuario para producir informacin. Coleccin de registros o archivos relacionados lgicamente. Una BD consolida muchos registros almacenados previamente en archivos independientes, de modo que un cmulo (pool) comn de registros sirvan como una sola central para muchas aplicaciones de procesos que necesitan este tipo de datos. formada Base de Datos Archivos Registros Campos

Una base de datos est constituida por cierto conjunto de datos persistentes utilizado por los sistemas de aplicaciones de una empresa determinada. [1] 1.3. Caractersticas de una Base de Datos

1.- Control centralizado de los datos. 2.- Integridad de los datos. 3.- Minimizacin de la redundancia.

4.- Independencia de los datos y las aplicaciones. 5.- Acceso concurrente a los datos. 6.- Costo mnimo de almacenamiento y mantenimiento. 7.- Versatilidad para la representacin de relaciones. 8.- Establecimiento de medidas de seguridad. 9.- Facilidad para el cambio de hardware o software. 1.4. Desventajas de una Base de Datos

1.- Son costosas. 2.- Representan un consumo de recursos elevados. 3.- Se necesita contratar personal capacitado. 4.- La recuperacin de una base de datos despus de una falla puede requerir bastante tiempo. 1.5. Lenguajes de Bases de Datos [2] Un sistema de base de datos proporciona dos tipos de lenguajes diferentes: uno para especificar el esquema de base de datos y el otro para expresar las consultas y actualizaciones de la base de datos. Lenguaje de Definicin de Datos (DDL: Data Definition Language): Un esquema de base de datos se especifica mediante un conjunto de definiciones expresadas mediante un lenguaje especial llamado Lenguaje de Definicin de Datos. Este lenguaje permite definir la estructura lgica (o esquema) de la BD. El esquema define las caractersticas de los registros dentro de un archivo: los campos de cada registro, sus nombres, el tipo de dato y la extensin. Un subesquema es la manera en la cual a un programa de aplicacin o a un usuario especfico se les permite acceder los datos de un archivo. Esto puede limitar el acceso a los campos definir los derechos de acceso (slo leer, leer y escribir). El resultado de la compilacin de las instrucciones en DDL es un conjunto de tablas que se almacenan en un archivo especial llamado Diccionario de Datos o Directorio de Datos. Un diccionario 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 del sistema de base de datos. La estructura de almacenamiento y los mtodos de acceso usados por el sistema de base de datos se especifican mediante un conjunto de definiciones en un tipo especial del DDL llamado un lenguaje de almacenamiento y definicin de datos. El resultado de la compilacin de estas definiciones es un conjunto de instrucciones para especificar los detalles de implementacin de los esquemas de la base de datos - los detalles normalmente se ocultan a los usuarios. Lenguaje de Manipulacin de Datos (DML: Data Manipulation Language): Por manipulacin de datos se quiere decir:

- La recuperacin de informacin almacenada en la base de datos. - La insercin de informacin nueva en la base de datos. - El borrado de informacin de la base de datos. - La modificacin de informacin almacenada en la base de datos. Un lenguaje de manipulacin de datos es un lenguaje que permite a los usuarios acceder o manipular los datos organizados mediante el modelo de datos apropiado. Incluye todos los comandos que permiten al usuario almacenar, recuperar, cambiar, borrar u ordenar los datos o registros dentro de la BD. Hay dos tipos bsicamente: DML procedimentales: Requieren que el usuario especifique qu datos se necesitan y cmo obtener esos datos. DML no procedimentales: Requieren que el usuario especifique qu datos se necesitan, sin especificar cmo obtener esos datos. Una consulta es una instruccin de solicitud para recuperar informacin. La parte de un DML que implica recuperacin de informacin se llama lenguaje de consultas. 1.6. Qu es un Sistema de Base de Datos? Sistema de Informacin diseado para manejar grandes cantidades de datos y producir informacin. Un sistema de bases de datos es bsicamente un sistema para archivar en el computador; es decir, es un sistema computarizado cuyo propsito general es mantener informacin y hacer que ste disponible cuando se solicite. La informacin en cuestin puede ser cualquier cosa que se considere importante para el individuo o la organizacin a la cual debe servir el sistema; dicho de otro modo, cualquier cosa necesaria para apoyar el proceso general de atender los asuntos de un individuo u organizacin [1]. En la Figura # 3 se muestra la forma como se integran los cuatro componentes principales de un sistema de base de datos: datos, hardware, software y los usuarios [1].

10

Base de datos

Programas de aplicacin

Usuarios finales

Figura # 3. Esquema simplificado de un sistema de base de datos. Datos.. En general, los datos de la base de datos sern tanto integrados como compartidos. Integrados significa que la base de datos puede considerarse como una unificacin de varios archivos de datos, por lo dems distintos, con una redundancia entre ellos eliminada al menos parcialmente. Por ejemplo, cierta base de datos podra tener un archivo de EMPLEADOS, con datos de nombre, domicilio, departamento, salario, etc., y tambin un archivo de INSCRIPCIN, que representara la inscripcin de empleados en cursos de capacitacin. Supngase que para llevar a cabo el proceso de administracin de los cursos de capacitacin es preciso conocer el departamento de cada estudiante inscrito. En este caso es evidente que no hace falta incluir esa informacin, de manera redundante, en el archivo INSCRIPCIN, porque siempre podr obtenerse mediante una consulta al archivo EMPLEADOS. Compartidos significa que los elementos individuales de datos en la base de datos pueden compartirse entre varios usuarios distintos, en el sentido de que todos ellos pueden tener acceso al mismo elemento de datos (y diferentes usuarios pueden utilizarlo para propsitos diferentes). Esta capacidad de compartir (en forma simultnea o no) se desprende en parte de la integracin de la base de datos. En el ejemplo de EMPLEADOS/INSCRIPCIN, los datos de departamento del archivo EMPLEADOS seguramente sern compartidos por los usuarios del Departamento de Personal y los Departamentos de Educacin, estos departamentos utilizaran la informacin con diferentes propsitos. Hardware..
11

Los componentes de hardware del sistema son: * Los volmenes de almacenamiento secundario - por lo regular discos magnticos donde se conservan los datos almacenados , junto con los dispositivos de E/S asociados (unidades de disco, etc..), controladores de dispositivos, canales de E/S, entre otros. * El procesador o procesadores y la memoria principal asociada que hacen posible la ejecucin de los programas del sistema de bases de datos. Software. Entre la base de datos fsica misma es decir, los datos como estn almacenados fsicamente- y los usuarios del sistema existe un nivel de programas, el manejador de base de datos o, ms comnmente conocido como, el sistema de administracin de base de datos (SMBD, database management system). Una funcin general que ofrece el SMBD consiste en ocultar a los usuarios de la BD los detalles a nivel de hardware. Usuarios. Hay 4 tipos diferentes de usuarios, diferenciados por la forma en que esperan interactuar con el sistema. * Programadores de aplicaciones: Los profesionales en computacin interaccionan con el sistema por medio de llamadas en DML, las cuales estn incorporadas en un programa escrito en un lenguaje principal. Estos son programas de aplicacin. Los programadores de aplicaciones pueden elegir entre muchas herramientas para desarrollar las interfaces de usuarios. Las herramientas de desarrollo rpido de aplicaciones (DRA) son herramientas que permiten al programador de aplicaciones crear formularios e informes con un mnimo esfuerzo de programacin. * Usuarios sofisticados: Interaccionan con el sistema sin escribir programas. Escriben sus preguntas en un lenguaje de consultas de BD. Cada consulta se somete a un procesador de consultas cuya funcin es tomar una sentencia en DML y descomponerla en instrucciones que entienda el gestor de almacenamiento. Ejemplo: Analistas que remiten las consultas para explorar los datos de la base de datos. * Usuarios especializados: Usuarios sofisticados que escriben aplicaciones de BD que no encajan en el marco tradicional de procesamiento de datos; sistemas de diseo ayudados por computadoras, sistemas expertos y basados en conocimiento, etc... * Usuarios ingenuos: Usuarios no sofisticados interactan con el sistema invocando a uno de los programas de aplicacin. Ejemplo: Transferencia (cajero de un banco).

1.7. Arquitectura para Sistemas de Bases de Datos [1]

12

La arquitectura ANSI/PARC se divide en tres niveles (Figura # 4), denominados niveles interno, conceptual y externo. En trminos generales:

Nivel Externo (vistas individuales de los usuarios) Nivel Conceptual (vistas comunitaria de los usuarios) Nivel Interno (vistas del almacenamiento)
Figura # 4. Los tres niveles de la arquitectura. (a) Nivel de Vistas (Visin Externa): Es el nivel ms alto de abstraccin, en l se escriben slo vistas o subconjuntos de la BD completa, esto con el fin de mostrar a los usuarios slo las partes que necesitan. Es el nivel ms cercano a los usuarios, es decir, es el que se ocupa de la forma como los usuarios individuales perciben los datos. (b) Nivel Conceptual (Visin Conceptual): Es el siguiente nivel que se define, describe que datos son realmente almacenados en la BD, as como las relaciones que existen entre estos. Se describe la BD a travs de un nmero pequeo de estructuras. Es un nivel de mediacin entre los otros dos. (c) Nivel Fsico (Visin Interna): Es el nivel ms bajo, el ms cercano al almacenamiento fsico, es decir, es el que se ocupa de la forma como se almacenan fsicamente los datos y describe cmo se almacenan realmente los datos. Se describe en detalle las estructuras complejas de datos utilizadas. Esta arquitectura permite implementar el concepto de Independencia de Datos, definida como la capacidad de modificar la definicin del esquema en el primer nivel sin afectar el nivel intermedio. Existen 2 niveles de independencia: Independencia Fsica: Se define entre el nivel fsico y el nivel conceptual. Capacidad de modificar el esquema fsico sin alterar la estructura lgica de la BD, es decir, el nivel conceptual. Independencia Lgica: Se define entre el nivel externo y el nivel conceptual. Capacidad de modificar la estructura lgica de la BD sin obligar a reescribir los programas de aplicacin.

13

Usuario A1
Lenguaje Anfitrin + DSL

Uusario A2
Lenguaje Anfitrin + DSL Lenguaje Anfitrin + DSL

Usuario B1
Lenguaje Anfitrin + DSL

Usuario B2
Lenguaje Anfitrin + DSL

Usuario B3

*Esquema externo A
Esquemas y correspondencias construidas y mantenidas por el administrador de base de datos (DBA)

Vista externa A

*Esquema externo B

Vista externa B

Correspondencia Correspondencia externa - conceptual A externa - conceptual B

Sistema de administracin de base de datos (DBMS)

Vista conceptual

Correspondencia conceptual - interna

Definicin de estructura de almacenamiento (esquema interno)

* Interfaz con el usuario

Base de datos almacenada (Vista interna)

Figura # 5. Arquitectura detallada del sistema Operaciones sobre una BD. * Consultas de BD: Solicitar a la BD la informacin especfica. Una consulta puede ser una bsqueda simple de un registro especfico o una solicitud de seleccionar todos los registros que satisfagan un conjunto de criterios. Una vez hecha la seleccin, se puede producir un listado. * Ordenamiento de los datos: Para poder usar los datas en la forma ms eficiente. Es posible acomodar los registros en orden alfabtico o numrico con base en los valores de uno o ms campos. * Impresin de informes, etiquetas y formatos de cartas: Salidas impresas, informes: lista ordenada de los campos y registros seleccionados en un formato fcil de leer. Producir etiquetas para envos por correo y formatos de cartas personalizados. * Consultas complejas. Ejemplo: Escoger todos las personas de sexo masculino y cuya edad sea mayor a 25 aos.

14

1.8.

Sistema Manejador de Base de Datos (SMBD)

Es el conjunto de programas que maneja todo acceso a la base de datos. Un SMBD consiste de un conjunto de datos relacionados entre s y un conjunto de herramientas de software (y/o hardware) para tener acceso a esos datos. Un SMBD consiste de un conjunto de programas que son usados para definir, procesar y administrar la BD y sus aplicaciones. Conjunto de equipos y programas que organiza los datos y proporciona los mecanismos utilizados para crear un archivo computarizado de BD; aadir, borrar o cambiar datos dentro del archivo; cambiar el modo en que estn almacenados los datos dentro de los archivos de una BD, buscar en la BD aquellos datos que cumplen ciertos criterios, etc.. El SMBD para organizaciones grandes requiere de un gran nmero de personas y altos gastos de equipos, programas y capacitacin personal. Conceptualmente, lo que sucede es lo siguiente: 1.- Un usuario emite una solicitud de acceso utilizando algn lenguaje de manipulacin de datos especfico (DML: Data Manipulation Language). 2.- El SMBD intercepta la solicitud y la interpreta. 3.-El SMBD inspecciona en orden a) el esquema externo, b) la correspondencia externa / conceptual, c) el esquema conceptual, d) la correspondencia conceptual/interna y e) la definicin de la estructura de almacenamiento. 4.- El SMBD realiza las operaciones necesarias sobre la base de datos almacenada. Se requieren programas de computadora para almacenar y consultar el contenido de una BD. Un SMBD puede organizar, procesar y presentar los datos seleccionados de una BD. Esta capacidad permite a quienes toman decisiones rastrear, probar y consultar el contenido de la BD para extraer las respuestas a las preguntas no recurrentes y no previstas en informes regulares. Los SMBD administrarn los datos almacenados y reunirn las partes necesarias de la BD comn para responder a las preguntas de quienes no sean programadores. El Objetivo primordial de un SMBD es proporcionar un entorno para recuperar informacin y almacenar nueva informacin en la BD, para lo cual debe proporcionar a los usuarios una visin abstracta de los datos. Es decir, los detalles de cmo se almacenan y se mantienen los datos, son transparentes para los usuarios. Esto se debe a que muchos de ellos, no tienen experiencia en computadores, por ello se les esconde la complejidad a travs de diversos niveles de abstraccin, para simplificar la interaccin con el sistema. Las Funciones del SMBD son: * Definicin de datos: El SMBD debe ser capaz de aceptar definiciones de datos (esquema externo, el esquema conceptual, el esquema interno y todas las correspondencias asociadas) en versin fuente y convertirlas en la versin objeto apropiada. Dicho de otro modo, el SMBD debe incluir componentes procesadores de lenguajes para cada uno de los diversos lenguajes de definicin de datos (DDL).

15

* Manipulacin de datos: El SMBD debe ser capaz de atender las solicitudes del usuario para extraer, poner al da, datos que ya existen en la base de datos o para agregar en ella datos nuevos. Dicho de otro modo, el SMBD debe incluir componentes procesadores de lenguajes para cada uno de los diversos lenguajes de manipulacin de datos (DML). * Seguridad e integridad de los datos: El SMBD debe supervisar las solicitudes de los usuarios y rechazar los intentos de violar las medidas de control y seguridad definidas por el DBA. * Recuperacin y concurrencia de los datos: El SMBD debe cuidar del cumplimiento de ciertos controles de recuperacin y concurrencia. * Diccionario de Datos: El SMBD debe incluir una funcin de diccionario de datos. * Desempeo: El SMBD debe ejecutar todas las funciones recin identificadas en la forma ms eficiente posible. El poder de los SMBD, integra muchos conjuntos de datos anteriormente separados y proporcionan un conjunto completo de programas que sirven como interfaz entre uno o varios usuarios y sus diversas aplicaciones. En un SMBD, los datos se pueden crear, borrar o cambiar en una BD integrada. El trmino integrada se refiere a la capacidad del SMBD de relacionar lgicamente un registro con otro. El usuario tiene acceso directo mediante instrucciones en el teclado. Un SMBD permite entonces: 1.- Independencia de los Datos: La independencia de los datos es un objetivo primordial de los sistemas de bases de datos. Esta independencia puede definirse como la inmunidad de las aplicaciones ante los cambios en la estructura de almacenamiento y en la tcnica de acceso, lo cual implica que las aplicaciones en cuestin no dependen de una estructura de almacenamiento o una tcnica de acceso. Todos los datos necesarios pueden ser almacenados en una base general. Si hay que hacer cualquier cambio a los datos pueden efectuarse sin necesidad de cambiar los programas que accedan datos. Esto es posible porque el SMBD proporciona dos aspectos de los datos. La visin fsica de una BD, se relaciona con la localizacin actual de los datos en el dispositivo de almacenamiento. La visin lgica representa los registros. 2.- Eliminacin de la redundancia e incremento de la integridad de los datos: Todos los datos relacionados se almacenan en un lugar, si un elemento de los datos debe ser cambiado slo tiene que hacerse en un lugar. 3.- Datos integrados, a partir de otros archivos: Un usuario puede recabar datos de cierto nmero de archivos de una base de datos y aplicar esos datos combinados, a reportes u otras aplicaciones, creando relaciones entre los registros. Realza la flexibilidad.

16

4.- Mayor seguridad, a travs del manejo de acceso de datos: La capacidad para negar el acceso a usuarios no autorizados, a datos restringidos, mejora enormemente la seguridad de los datos y pone a salvo la integridad. 5.- Normalizacin de reportes y consultas: Un SMBD permite a un usuario que realizar reportes normalizados. Esto permite que el usuario formule preguntas breves. Componentes Funcionales del Sistema Manejador de Base de Datos[2 Los componentes funcionales se pueden dividir a grandes rasgos en componentes de procesamiento de consultas y componentes de gestin de almacenamiento.
Usuarios Usuarios Interfaces de Aplicaci Programadores de Aplicaciones Programas Aplicaci Usuarios Sofisticados Herramientas de de la Herramientas de

usa
Procesador de Consultas

escribe

usa

usa

S M B D

Compilador y Motor de Evaluacin de Consulta

Consulta DML Compilador del DML

Intrprete del DDL

Cdigo Objeto de Prog de

Gestor de transacciones Gestor de Archivos

Gestor de memoria intermedi

Gestor de autorizacin e integridad

Gestor de almacenamiento

Archivos de Datos

ndice

Datos estadsticos

Diccionario de Datos

Almacenamiento en

Figura # 6. Componentes Funcionales del Sistema Manejador de Base de Datos.

17

El procesador de consultas es importante porque ayuda al sistema de base de datos a simplificar y facilitar el acceso a los datos. Los componentes de gestin de almacenamiento proporcionan 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. El gestor de almacenamiento 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 DML 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. El gestor de almacenamiento incluye: Gestor de Transacciones: Asegura que la base de datos quede en un estado consistente (correcto) a pesar de los fallos del sistema, y que las ejecuciones de transacciones concurrentes ocurran sin conflictos. Gestor de 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 Archivos: Gestiona la asignacin de espacio de almacenamiento de disco y las estructuras de datos utilizadas para representar la informacin almacenada en disco. Gestor de Memoria Intermedia: Responsable de traer los datos del disco de almacenamiento a memoria principal y decidir qu datos guardar en la memoria cach. Permite que la base de datos maneje tamao de datos que son mucho mayores que el tamao de la memoria principal. Los componentes del procesador de consultas son: Compilador DML: Traduce las instrucciones del DML a instrucciones de bajo nivel que entiende el Motor de Evaluacin de Consultas. Las consultas se suelen poder traducir en varios planes de ejecucin alternativos, los cuales proporcionan el mismo resultado. Adems, intenta transformar las peticiones del usuario en otras equivalentes pero ms eficientes, encontrando as una buena estrategia para ejecutar la consulta. El compilador del DML tambin realizada optimizacin de consultas, es decir elige el plan de evaluacin de menor coste de entre todas las opciones posibles. Compilador y enlazador: Convierte sentencias en DML incorporadas en un programa de aplicacin en llamadas a procedimientos normales. El compilador debe interactuar con el compilador DML para generar el cdigo objeto apropiado. Intrprete DDL: Interpreta las instrucciones del DDL y registra las definiciones en el diccionario de datos que son un conjunto de tablas que contiene metadatos. Motor de Evaluacin de Consultas: Ejecuta las instrucciones a bajo nivel generadas por el compilador del DML. Adems, se necesitan varias estructuras de datos como parte de la implementacin fsica del sistema: Archivos de Datos: Almacenan la BD. Diccionario de Datos: Almacena metadatos (datos acerca de los datos). ndices: Proporcionan acceso rpido a elementos de datos que tienen valores particulares.

18

Datos estadsticos: Almacenan informacin estadstica sobre los datos en la base de datos. El procesador de consultas utiliza esta informacin para seleccionar las formas eficientes para ejecutar una consulta. Ventajas y Limitaciones de los Sistemas Manejadores de Base de Datos: VENTAJAS * Mejor integracin y menos duplicidad de los datos que se originan en los diferentes puntos. * Menos errores cuando varios registros pueden actualizarse en forma simultnea. * Facilitan el almacenamiento de grandes cantidades de informacin. LIMITACIONES * Se necesitan hardware y software ms complejos y caros. * Fallas del hardware o del software pueden ocasionar la destruccin de informacin vital de la BD. * Pueden requerirse un largo perodo de conversin, elevados gastos de capacitacin y habilidades mayores en quienes son responsables del Sistema de BD.

* Facilitan la organizacin y reorganizacin de la informacin. * Facilitan la recuperacin rpida y flexible de la informacin. * Ahorrar en el costo de desarrollo de nuevas aplicaciones, as como en los costos de entrada de los datos y su almacenamiento. 1.9. Administrador de BD (DBA: DATABASE ADMINISTRATOR) Es designado usualmente por la direccin de una compaa y provisto de un personal que trabaje con los usuarios para crear, mantener y salvaguardar los datos en la BD. Para un SMBD basado en micro, recae en el individuo, el DBA. Es conveniente definir el administrador de datos y el administrador de base de datos. Administrador de Datos: Es la persona que toma las decisiones estratgicas y de polticas con respecto a la informacin de la empresa. Administrador de BD (DBA: database administrator): es la persona que proporciona el apoyo tcnico necesario para poner en prctica las decisiones tomadas por el administrador de datos.

Funciones del DBA: 1.- Definicin del esquema de la BD.

19

Desarrollo y mantenimiento de un diccionario de datos (DD). EL DD define el significado de cada elemento de datos (cada campo) en la BD; esto incluye los nombres de los datos (nombres de los campos), tipos de datos, tamao del campo y cualquier interrelacin entre elementos de datos. 2.- Modificacin del esquema y de la organizacin fsica de la BD. 3.- Definicin de la estructura de almacenamiento y del mtodo de acceso. 4.- Mantenimiento de un control de transacciones: Un control de transacciones contiene una auditoria completa de toda la actividad de una BD en un tiempo. El control ayuda al respaldo, en el caso de que un dato quedar inutilizado o destruido, el control lleva un registro de todos los cambios, que sirve para restaurar la BD a su condicin original. 5.- Definicin de las verificaciones de seguridad e integridad : esto puede considerarse parte del esquema conceptual. Concesin de autorizacin para el acceso a los datos: La seguridad incluir decidir que acceso se permite a un campo o archivo. Incluye proporcionar medios para la recuperacin eficiente si ocurre un desastre y se pierde la informacin en la BD. 6.- Definicin de los procedimientos de respaldo y recuperacin. El DBA debe definir y poner en prctica un plan de recuperacin adecuado que incluya, por ejemplo, el realizar backups peridicos de la base de datos como respaldos y procedimientos para cargar la base de datos a partir del respaldo ms reciente que se tenga. El DBA asegura que se ejecute el respaldo apropiado de la BD. El respaldo se refiere a las copias y al registro de todos los cambios que han sido hechos a la BD. Si sucede algo que dae o destruya la BD; esta puede ser reconstruida (recuperada) usando el respaldo. 7.- Supervisin del desempeo y respuesta a los cambios en los requerimientos. Podra ser necesario reorganizar la base de datos en forma peridica con el fin de garantizar que los niveles de desempeo sigan siendo aceptables. Realizar cambios a nivel fsico y actualizar la correspondencia interna - conceptual. 8.- Especificacin de las restricciones de integridad, cada vez que hay actualizacin en el sistema.

20

CAPITULO II. MTODOS DE ORGANIZACIN DE BD. Una caracterstica fundamental del enfoque de bases de datos es que proporciona cierto nivel de abstraccin de los datos al ocultar detalles de almacenamiento que la mayora de los usuarios no necesitan conocer. Los modelos de datos son el principal instrumento para ofrecer dicha abstraccin. Un modelo de datos es un conjunto de conceptos que pueden servir para describir la estructura de la base de datos. Es decir, un Modelo de Datos no es mas que una coleccin de herramientas conceptuales que se utilizan para describir los datos, las relaciones existentes entre ellos, la semntica asociada a los mismos y las restricciones de consistencia. Los modelos de datos se dividen en 3 grupos: Modelos Lgicos basados en Registros Modelos Lgicos basados en Objetos Modelos Fsicos de Datos

2.1. Modelos Lgicos basados en Registros Se utilizan para especificar la estructura lgica global de la BD y para proporcionar una descripcin de alto nivel de la implementacin. El nombre asociado a este modelo se debe a que la BD est estructurada en registros de formato fijo de diferentes tipos. En cada tipo de registro se define un nmero fijo de campos o atributos, y cada campo tiene normalmente una longitud fija. Este modelo permite describir los datos en los niveles conceptual y de vista. Una subdivisin de este modelo se presenta a continuacin: 2.1.1. Modelo Relacional: representa los datos y las relaciones existentes entre los datos mediante una coleccin de tablas, cada una de las cuales tiene un nmero de columnas con nombres nicos. Cada fila de la tabla representa una coleccin de valores de datos relacionados entre s. Dichos valores se pueden interpretar como hechos que describen una entidad o un vnculo (relacin) entre entidades del mundo real. Los nombres de las columnas ayudan a interpretar el significado de los valores que estn en cada fila de la tabla. A continuacin se presenta un ejemplo de una base de datos relacional, la cual consiste de dos tablas: una tabla muestra los clientes de un banco y la otra tabla muestra las cuentas que pertenecen a esos clientes [2]: Nombre Pedro Luis Alexis Nmero 657 801 900 Calle Codazzi lamo Real Ciudad Caracas Caracas Barquisimeto Saldo 55000 1500 20000 Nmero 900 657 657

21

2.2.2. Modelo de Red: los datos se representan mediante colecciones de registros y las relaciones entre los datos se representan mediante enlaces, los cuales pueden verse como punteros. Los registros en la BD se organizan como colecciones de grafos dirigidos. Los datos se almacenan en registros; cada registro consiste en un grupo de valores de datos relacionados entre s. A continuacin se presenta un ejemplo de una base de datos en red, la cual utiliza la misma informacin que la base de datos relacional: Luis lamo Caracas 657 55000

Estructura de Red o Grafo Alexis Real Barquisimeto

Pedro

Codazzi

Caracas

900

20000

2.2.3. Modelo de Jerrquico: Similar al modelo de red en sentido de que los datos y las relaciones entre los datos se representan mediante registros y enlaces, respectivamente. Se diferencia del modelo de red en que los registros estn organizados como colecciones de rboles en lugar de grafos dirigidos. A continuacin se presenta un ejemplo de una base de datos jerrquica con la misma informacin presentada en los ejemplos anteriores: RAIZ

Luis

lamo

Caracas

Pedro

Codazzi

Caracas

657

55000

900

20000

Alexis Estructura de rbol

Real

Barquisimeto

657

55000
22

2.2. Modelos Lgicos basados en Objetos Se caracterizan por el hecho de proporcionar capacidad de estructuracin bastante flexible y permiten especificar restricciones de datos explcitamente. Se usan para describir datos en los niveles conceptuales y de vistas.

Dentro de este tipo de modelo, podemos encontrar: Modelo Entidad/ Relacin. Modelo orientado a objetos. Modelo binario, etc. A continuacin, se presenta una descripcin del modelo Entidad/Relacin, por ser uno de los modelos mas utilizados: 2.2.1. Modelo Entidad/Relacin: se basa en una percepcin del mundo real que consta de una coleccin de objetos bsicos llamados entidades, y de relaciones entre estos objetos. Una entidad es una cosa u objeto en el mundo real distinguible de otros objetos. Por ejemplo, cada Persona es una entidad y las Cuentas Bancarias pueden ser consideradas entidades. Es decir, Entidad: es un Objeto que existe y es distinguible de otros Objetos. Ejemplo: Pedro Prez con C.I: 10.503.806, es una entidad ya que identifica nicamente a una persona especfica. Igualmente, el Nmero de Cuenta 900 del Banco Venezuela con monto de 20.000 es una entidad. Con base al concepto anterior, se presente la siguiente definicin: Un conjunto de entidades es un conjunto de entidades del mismo tipo. As, por ejemplo: Conjunto de todas las personas que tienen una cuenta en un Banco Cliente. Conjunto de todas las cuentas de un Banco Cuenta. Una entidad est representada por un conjunto de atributos (propiedades o caractersticas de las entidades). Por ejemplo: Nombre del Cliente, Cdula de Identidad, calle (Cliente) y Nmero de Cuenta y Saldo (Cuenta). Para cada atributo hay un conjunto de valores permitidos, llamado dominio del atributo. Ejemplo: Nombre del Cliente: conjunto de cadenas de caracteres de una longitud determinada; Nmero de Cuenta: conformada solamente por nmeros enteros positivos, etc. Una relacin es una asociacin entre entidades. Por ejemplo, una relacin IMPOSITOR asocia un Cliente con cada Cuenta que tiene. Ahora bien, adems de las entidades y relaciones, el modelo Entidad/Relacin representa ciertas ligaduras (restricciones) que los contenidos de la base de datos deben cumplir. Una ligadura importante es la correspondencia de cardinalidades, que expresa, como se explicar posteriormente, el nmero de entidades con las que otra entidad se puede asociar a travs de un conjunto de relaciones. Diagrama Entidad-Relacin:

23

La totalidad de estructuras lgicas de una base de datos se puede expresar grficamente mediante el diagrama Entidad/Relacin, el cual consta de los siguientes componentes: Rectngulos: Representan conjuntos de entidades. Elipses: Representan atributos. Rombos: Representan relaciones entre conjuntos de entidades. Lneas: Enlazan atributos de los conjuntos de entidades y los conjuntos de entidades con las relaciones.

nombre-ctah

saldo fecha
CtaHab-Cta

calle M CuentaHab ciudad-ctah

numero-cta N Cuenta

cdula

2.3. Modelos Fsicos de Datos Se usan para describir datos en el nivel ms bajo. En contraste con el modelo de datos lgico, existen pocos modelos de datos fsicos en uso. Dos de los mas conocidos con el Modelo de Unificacin y el Modelo de Memoria de Marcos. El modelo fsico de datos captura aspectos de la implementacin del sistema de bases de datos que no se abordan en esta gua.

24

CAPITULO III. DISEO CONCEPTUAL DE BASE DE DATOS.

El estudio del diseo de base de datos se puede dividir en dos enfoques: Enfoque ascendente y descendente. La fase de diseo se refiere a la formulacin de especificaciones para un nuevo sistema de manera que satisfaga los requerimientos determinados durante la fase de anlisis. Se puede decir entonces que el diseo de sistemas refleja una presentacin detallada del informe final del anlisis del sistema. El diseo, es por lo tanto, el acto de delinear, planear, bosquejar o disponer de elementos separados de tal manera que estos elementos relacionados formen un todo. 3.1. Diseo Ascendente/Descendente El diseo de sistemas de BD se puede realizar como se mencion anteriormente segn el enfoque ascendente y descendente, para cada uno de estos existen dos criterios que se pueden aplicar. Criterio 1: Enfoque Ascendente Un grupo de esquemas de usuarios se integran en un esquema conceptual, es decir: Modelacin de visiones externas. Integracin de visiones externas en un esquema conceptual. Grficamente tenemos:

esquema conceptual

esquema usuario1

esquema usuario2

esquema usuario3

Enfoque Descendente. A partir del esquema conceptual se obtienen los diferentes esquemas de usuarios, es decir, Diseo conceptual. Derivacin de esquemas de usuarios.

25

Grficamente tenemos:

esquema conceptual

esquema usuario1

esquema usuario2

esquema usuario3

Criterio 2: Enfoque Ascendente. Se parte de objetos atmicos no descomponibles y a continuacin se obtienen abstracciones u objetos de mayor nivel de abstraccin que forman el esquema. Grficamente tenemos:

esquema final

objetos atmicos no descomponibles

Enfoque Descendente. Se parte de objetos muy abstractos, que se refinan paso a paso hasta llegar al esquema final.

26

Grficamente tenemos:

esquema muy abstracto paso de refinacin esquema menos abstracto

esquema final
3.2. Enfoque Descendente El alcance de la fase de diseo bajo este enfoque consistir en la definicin del problema y la identificacin de los requerimientos de datos para la empresa. Las acciones a delinear, planear, bosquejar en esta fase van a consistir de muchos elementos separados que al relacionarse formarn un todo; esta fase consistir entonces en ir refinando los datos de la organizacin que estn envueltos en la situacin a modelar, el producto resultante ser un modelo de datos que haga analogas generalmente bajo conceptos de generalizaciones y agregaciones. Un modelo de datos consiste de un conjunto de herramientas conceptuales que se utilizan para describir datos, sus relaciones, su semntica y sus limitaciones. Los modelos de datos se describen a travs de esquemas y pueden ser de dos tipos: - Modelo de datos infolgicos: Donde el diseador debe presentar un modelo enfocado al usuario para que este pueda ser discutido y fcilmente entendido. - Modelo de datos datolgico: Donde se presenta el modelo de datos enfocado a su uso en el computador. Para entender mejor estas transiciones ver la siguiente figura:

Situacin a modelar

Modelo de datos infolgico

Modelo de datos datolgico

Existen ventajas del diseo de sistemas de BD bajo en el enfoque infolgico como se enumera a continuacin:

27

1.- La divisin de funciones y labores en estas 2 fases hacen el proceso de diseo de BD simple y organizado. 2.- El modelo infolgico es relativamente ms fcil de disear que un modelo datolgico (directamente) , debido a que el modelo infolgico no est restringido por las capacidades del SMBD y adems es independiente de las consideraciones de almacenamiento. 3.- Un modelo infolgico es ms estable que un modelo datolgico. Por lo tanto en este punto el problema que se tiene que resolver es la eleccin de un modelo de datos infolgico que satisfaga las siguientes caractersticas: - Modelo fcil de comprender por el usuario, que le permita a ste poder conversar con el diseador. - Que posea poca cantidad de reglas de estructuracin. Entre los modelos infolgicos ms conocidos se tienen: - El modelo entidad - relacin. - El modelo binario. - El modelo semntico de datos. Existen varias razones para escoger de los modelos antes mencionados, el Modelo Entidad - Relacin. Es el modelo ms representativo de la clase y es un modelo con bastante aceptacin como modelo de datos apropiado para el diseo de BD, satisface las caractersticas antes mencionadas y adems se utiliza ampliamente en la prctica. Vale la pena destacar que para el desarrollo de una metodologa de diseo descendente de BD se tienen las siguientes fases. Fase 1: Conversin de la situacin a modelar al modelo infolgico de Entidad - Relacin.

Situacin a modelar

Modelo Entidad Relacin

Fase 2: Conversin del Modelo Entidad - Relacin a un modelo de datos datolgico : relacional, jerrquico o de redes.

Modelo Relacional Situacin a modelar Modelo Jerrquico

Modelo Redes

28

3.2.1. Modelo Entidad-Relacin El modelo Entidad-Relacin es un modelo de tablas y grafos, propuesto por Peter Chen (1976). Este modelo es til en el diseo de esquemas de base de datos debido a que es una generalizacin de los modelos de datos relacionales, jerrquico y redes. La generalizacin es usualmente en trminos de permitir la representacin de restricciones y de tipos de asociaciones muchos a muchos directamente en el modelo de datos. El modelo E-R facilita el diseo de BD permitiendo la especificacin de un esquema empresarial. Un esquema empresarial representa una visin de todos los datos de la empresa y es independiente de las consideraciones de almacenamiento, luego este esquema empresarial es transformado en esquema apropiado de BD, el cual podr ser ejecutado sobre algn SMBD. Otra ventaja a considerar en el modelo E-R es su estabilidad ante cambios en los modelos datolgicos y en los sistemas manejadores de BD. Se puede decir entonces que un esquema empresarial en el modelo E-R es una documentacin lgica de las propiedades de una BD. Estructura a) Entidades y conjuntos de entidades. Entidad se puede definir como una cosa u objeto que existe ya que puede ser identificada unvocamente en una situacin a modelar (Ej. Pedro Prez, Compaa AA, etc..) . As una entidad corresponde a una categorizacin de objetos de la situacin a modelar. Tambin un tipo entidad puede ser vista como una agregacin de atributos. Ejemplos: Tipo Entidad Objetos (Entidad) Estudiante El estudiante Pedro El estudiante Juan Categorizacin de Objetos

Tipo Entidad Objetos (Entidad) # CI

Estudiante Agregacin Nombre Edad

Tipo Entidad Tipo Entidad

Estudiante Generalizacin Estudiante de Fsica Estudiante de Computacin

Conjunto de entidades: Es un grupo de entidades del mismo tipo. Ejemplo: Conjunto de estudiantes define el conjunto de entidades estudiantes.

29

En un conjunto de entidades sus miembros son determinados por un predicado, as las propiedades de una instancia en particular de un conjunto entidad pueden ser probadas para determinar si la entidad pertenece al conjunto entidad. Ejemplo, si se sabe que una entidad est en el conjunto de entidades de empleados, entonces tiene propiedades comunes a los otros componentes (entidades) de ese conjunto de entidades. En el modelo E-R no es necesario que las entidades pertenezcan a un slo conjunto. b) Relaciones y conjuntos de relaciones. Una relacin es una asociacin entre varias entidades. En trminos de abstraccin un tipo de relacin corresponde a una agregacin de uno o ms tipos de entidades. Las relaciones no tienen existencia propia, ya que dependen de entidades. Ejemplo: Padre-hijo, es una relacin entre dos entidades Personas, la asociacin padre-hijo no puede existir si no existe persona. Un conjunto de relaciones es un grupo de relaciones del mismo tipo. Formalmente es una relacin matemtica de n 2 (posiblemente idnticos) conjuntos de entidades. Si E1, E2 ,......... En son conjuntos de entidades, entonces un conjunto de relaciones R es un subconjunto de { (e1,e2,.......,en)/ e1 E1, e2 E2 ,.......,en En } donde (e1, e2,.......,en) es una relacin y ei es una entidad (ei Ei , 1 i n). Se puede decir entonces que es posible tener ms de un conjunto relacin entre dos conjuntos entidades. Un conjunto asociacin puede ser n-ario, es s decir, entre n conjuntos entidades. c) Atributo, valor y conjunto de valores. La informacin acerca de una entidad o una relacin se obtiene por al observacin o medida, y es expresada por un conjunto de pares atributo-valor Ej = { 3, rojo, Pedro} son valores. Los valores se clasifican en conjunto de valores diferentes, tales como color, primer nombre. Hay un predicado asociado con cada conjunto de valores, para probar si el valor pertenece al conjunto. Un valor en un conjunto de valores puede ser equivalente a otro valor en otro conjunto, por ejemplo: 12 en el conjunto Pulgadas es equivalente a 1 en el conjunto Pie. Un atributo puede ser definido formalmente como una funcin que transforma un conjunto de entidades o relaciones. Se puede decir que los atributos son interpretaciones de conjunto de valores en un contexto de conjunto entidad-relacin. Un atributo se puede definir matemticamente as: F: EI RI VI V1 x V2 x ............xVn (1 I n) donde VI son conjuntos de valores, EI son conjuntos de entidades, RI son conjuntos de relaciones. Por lo tanto una entidad relacin puede ser representada por un conjunto de atributos. Limitantes de Mapeo.

30

Un esquema ER empresarial puede definir ciertas limitantes con las que deben cumplir los datos contenidos en la BD. Una limitante importante es la cardinalidad de mapeo que expresa el nmero de entidades con las que puede asociarse otra entidad mediante una relacin. La cardinalidad de asignacin expresan el nmero de entidades a las que puede asociarse otra entidad a travs de un conjunto de relaciones. Para un conjunto binario de relaciones R entre los conjuntos de entidades A y B, la cardinalidad de mapeo puede ser de las siguientes formas: Una a una (1:1): Una entidad en A est relacionada con una entidad en B, y una entidad en B est relacionada con una entidad en A.

a1 * a2 *

* b1 * b2

Por ejemplo, si se asume que cada persona casada tiene slo una esposa, la cardinalidad de la relacin ESTA_CASADO_CON es 1 en cada direccin. Es una relacin 1: 1 (uno a uno). Una a muchas (1:N): Una entidad en A est relacionada con cualquier nmero de entidades en B, pero una entidad en B puede asociarse nicamente con una entidad en A. a1 * a2 * A * b1 * b2 * b3 * b4 B

Por ejemplo, en la relacin DORMITORIO-OCUPANTE, una ocurrencia nica de Dormitorio se relaciona con muchas ocurrencias de Estudiantes. Si la relacin es 1: M (uno a muchos), en un dormitorio hay muchos estudiantes, pero un estudiante slo tiene un dormitorio. Muchas a muchas (M:N): Una entidad en A est relacionada con cualquier nmero de entidades en B, y una entidad en B est relacionada con cualquier nmero de entidades en A.

a1 *

* b1

31

a2 *

* b3

Por ejemplo, en la relacin ESTUDIANTE-CLUB, donde se relaciona las ocurrencias de Estudiante con las ocurrencias de Club. Un estudiante puede inscribirse en ms de un club, y en un club puede haber como miembros muchos estudiantes. Esta es una relacin N: M (muchos a muchos). Diagramas Entidad-Relacin (ER). La estructura lgica general de una BD puede expresarse en forma grfica por medio de un diagrama E-R, que se integra con las siguientes componentes:

Rectngulos: Representan conjuntos de entidades.

Elipses: Representan atributos.

Rombos: Representan conjuntos de relaciones.

Lneas: Enlazan atributos a entidades y entidades a relaciones. Ejemplo: Sea la siguiente BD formada por los conjuntos de entidades: Sucursal CtaHabiente Cuenta Transaccin Atributos (nombre-sucurs, ciudad-sucur, activo) Atributos (nombre-ctahab, cdula, calle, ciudad-ctahab) Atributos (nmero -cta, saldo) Atributos (nmero-transac, fecha, importe)

32

nombre-ctah calle M CuentaHab ciudad-ctah 1 Sucursal Activo fecha

saldo numero-cta N Cuenta

cdula

ciudad-sucur nombre-sucur

Un cliente puede tener varias cuentas. Una cuenta puede pertenecer a varios clientes. Un cliente puede tener varias cuentas, cada una situada en una sucursal especifica del banco y una cuenta puede pertenecer a varios clientes. La relacin entre un cliente y una cuenta puede representarse nicamente si hay una sucursal correspondiente. En otro caso, podra estar una cuenta relacionada con una sucursal sin el cliente correspondiente, o con un cliente sin la sucursal correspondiente. Claves primarias, entidades dbiles. Para identificar de manera nica a una entidad dentro de un conjunto de entidades se debe especificar una clave de entidad. Una clave es un grupo de atributos tal que su asociacin de la entidad al conjunto de valores e uno a uno (1:1). Es posible que un conjunto de entidades no tenga suficientes atributos para formar una clave primaria. Por ejemplo, el conjunto de entidades transaccin tiene tres atributos: nmero-transac, fecha e importe. Cuando un conjunto entidad no cuenta con una clave primaria para identificarla, se denomina entidad dbil. As una entidad que cuenta con una clave primaria se denomina entidad fuerte regular. El concepto de entidades dbiles y fuertes est relacionado con la dependencia de existencia. Dependencia por existencia: Si la existencia de la entidad X depende de la existencia de la entidad Y entonces X es dependiente por existencia de Y y entonces si se elimina la entidad Y se elimina tambin la entidad X. Se dice entonces que X es una entidad dominante y Y es una entidad subordinada. Esta restriccin de dependencia por existencia especifica que la existencia de una entidad transaccin, depende de la existencia de una relacin cuenta/transaccin . As si las

33

entidades cuentas son eliminadas, sus asociaciones transacciones tambin lo sern. Este tipo de entidades en un diagrama E-R se representa mediante un rectngulo doble etiquetado. Dependencias por identificacin: Si una entidad no se puede identificar unvocamente por sus atributos propios y tiene que ser identificada a travs de sus relaciones con otras entidades, dicha entidad es dependiente por identificacin. Las dependencias por identificacin estn asociadas con las dependencias por existencia, sin embargo la dependencia por existencia no implica dependencia por identificacin. Cuando un conjunto de entidades dbiles no cuenta con una clave para identificarla, es necesario tener una forma de distinguirla. El discriminador de un conjunto de entidades dbiles es un conjunto de atributos que permiten hacer esta distincin. El discriminador es un conjunto de atributos que permiten distinguir las entidades dbiles entre s. Ejemplo, el discriminador del conjunto de entidades dbiles transacciones es el atributo nmero-transac, ya que para cada cuenta estos nmeros identifican en forma nica cada una de las transacciones. La clave primaria de un conjunto de entidades dbiles est formada por la clave primaria de la entidad fuerte de la que depende su existencia y su discriminador. Para el ejemplo del conjunto de entidades transacciones, la clave primaria es (nmero-cuenta, nmero-transac). Los conjuntos de relaciones tambin tienen claves primarias. Estas claves se forman tomando todos los atributos que constituyen las claves primarias de los conjuntos entidades que definen al conjunto de relaciones. Ejemplo, la clave de la relacin ctahab es CI + nmero-cuenta. En el siguiente grfico se completa el Diagrama E-R del ejemplo anterior, adicionando el conjunto de entidades dbiles Transaccin depende del conjunto de entidades fuertes Cuenta, a travs del conjunto de relaciones bitcora.

fecha nombre-ctah calle M CuentaHab ciudad-ctah fecha

ctah-cta

numero-cta N

saldo

numero-transac N
bitcora

importe

M Cuenta

Transaccin

cdula

1 Sucursal

Activo

ciudad-sucur

nombre-sucurs

34

Mtodo de Chen. A continuacin se muestra un mtodo de diseo descendente basado en el modelo ER de Chen. Este mtodo est constituido por los siguientes pasos: 1.- Identificacin de objetos de inters. Entidades , tipos de entidades Relaciones, tipos de relaciones Atributos, conjunto de valores Roles, conjunto de entidades, conjunto de relaciones. 2.- Dibujo del Diagrama E-R. (Esquema empresarial): 3.- Identificacin de las claves para los conjuntos de entidades y para los conjuntos relaciones. 4.- Convertir el Diagrama E-R en un diagrama de estructura de datos (llevar el modelo infolgico a un modelo datolgico).

Reduccin de un ER a tablas. Una base de datos que se ajuste a un DER puede presentarse mediante una agrupacin de tablas. Para cada conjunto de entidades y para cada conjunto de relaciones en la BD, existe una tabla nica a la que se le asigna el nombre del conjunto de entidades o relaciones correspondientes. Cada tabla tiene un nmero de columnas que, a su vez, tienen nombres nicos y corresponden a los valores de un conjunto de valores de un atributo. Cada fila de la tabla corresponde a una ocurrencia del conjunto entidad o del conjunto relacin. Representacin del conjunto de entidades fuertes. Se representa por medio de una tabla con n columnas diferentes, cada una de las cuales corresponde a los atributos del conjunto entidad. Cada fila es una entidad.

Ejemplo:

Conjunto Entidad Cuenta Nmero de Cta 3133 4144 5155 Saldo 1000 2000 3000

Representacin del conjunto de entidades dbiles. Sea A un conjunto de entidades dbiles con los atributos descriptivos a1, a2,....an . Sea B el conjunto de entidades fuertes del cual depende A. La clave primaria de B incluye los atributos b1, b2,....bn . El conjunto de entidades A se representa mediante una tabla llamada A con una columna por cada atributo del conjunto. {a1, a2,....an } {b1, b2,....bn }

35

Ejemplo de la representacin de la entidad dbil Transaccin mediante la tabla transaccin. Nmerocuenta 3133 4144 Nmero-transaccin 356 067 fecha 3/2/90 4/5/90 importe 1000 -200

Representacin del conjunto relaciones. Las relaciones se transforman de tres formas diferentes dependiendo de la cardinalidad de las mismas. Relacin Uno-Uno: Supongamos un ejemplo, la relacin ctah-cta,, es uno-uno. Esto quiere decir que un cliente tiene a lo sumo una cuenta y la cuenta se asigna a un slo cliente. Para mostrar la conexin entre las dos relaciones, se puede adicionar Cdula a Cuenta o numero-cta a CuentaHab. La relacin elegida se determina por la necesidad de la propia aplicacin. En muchos casos, cualquier relacin puede elegirse. Ejemplo de la tabla correspondiente a CuentaHab. cdula 3133313 4144414 nombre-ctah Pedro Albert ciudad-ctah Caracas Maracaibo calle Calle Sur Calle Norte nmero-cta 356 067 fecha 3/2/90 4/5/90

Ejemplo de la tabla correspondiente a Cuenta. nmero-cta 356 067 Ejemplo de la tabla correspondiente a CuentaHab. cdula 3133313 4144414 nombre-ctah Pedro Albert ciudad-ctah Caracas Maracaibo calle Calle Sur Calle Norte saldo 10.000 500.000

Ejemplo de la tabla correspondiente a Cuenta. nmero-cta 356 067 saldo 10.000 500.000 cdula 3133313 4144414 fecha 3/2/90 4/5/90

36

El esquema relacional quedara as: CuentaHab (cdula, nombre-ctah, ciudad-ctah, calle, nmero-cta, fecha) Clave fornea: nmero-cta Cuenta (nmero-cta, saldo) CuentaHab (cdula, nombre-ctah, ciudad-ctah, calle) Cuenta (nmero-cta, saldo, fecha, cdula) Clave fornea: cdula Relacin Uno-muchos: Suponga que la relacin ctah-cta, tiene mucha cardinalidad en la parte de Cuenta. Esto quiere decir que un cliente puede tener muchas cuentas, pero una cuenta se asigna a un slo cliente. En este caso, la propia cardinalidad uno-muchos determina que la estructura de la relacin deba ser como sigue: Ejemplo de la tabla correspondiente a CuentaHab. cdula 3133313 4144414 nombre-ctah Pedro Albert ciudad-ctah Caracas Maracaibo calle Calle Sur Calle Norte nmero-cta 356 067 fecha 3/2/90 4/5/90

Ejemplo de la tabla correspondiente a Cuenta. nmero-cta 356 067 saldo 10.000 500.000

As, en una relacin uno-muchos, al relacin que describe el objeto en la parte mucha de la relacin recibe la columna clave externa que indica al otro objeto. En el ejemplo, Cuenta es la relacin correspondiente al conjunto de objetos de la parte mucha de la relacin y por esta razn Cuenta recibe la columna clave externa cdula. El esquema relacional quedara as: CuentaHab (cdula, nombre-ctah, ciudad-ctah, calle) Cuenta (nmero-cta, saldo, fecha, cdula) Clave fornea: cdula Relacin muchos-muchos: Suponga que la relacin ctah-cta, se muestra como una relacin muchos-muchos. En este contexto se asume que un cliente puede tener muchas cuentas y que una cuenta puede asignarse a mltiples clientes. Para transformar la relacin muchos-muchos, se crea una relacin de interseccin. En este caso, se necesitan tres relaciones: una para cada conjunto de objetos y otra para la relacin ctah-cta.

37

Ejemplo de la tabla correspondiente a CuentaHab. cdula 3133313 4144414 nombre-ctah Pedro Albert ciudad-ctah calle Caracas Calle Sur Maracaibo Calle Norte

Ejemplo de la tabla correspondiente a Cuenta. nmero-cta 356 067 saldo 10.000 500.000

Ejemplo de la tabla correspondiente a ctah-cta. nmero-cta 356 067 cdula 10.000 500.000 fecha 3/2/90 4/5/90

La relacin ctah-cta contiene los dtaos que identifican qu clientes estn asociados con qu cuentas. Adems, la relacin ctah- cta tiene atributos adicionales no claves que se aplican slo a ella. El esquema relacional quedara as: CuentaHab (cdula, nombre-ctah, ciudad-ctah, calle) Cuenta (nmero-cta, saldo) ctah-cta (cdula, nmero-cta, fecha) 3.2.2. Modelo Entidad/Relacin Extendido [3] Terminologa Entidades Sub-tipo: Algunos tipos entidades no son homogneos y consisten en la unin de subgrupos de entidades que tienen datos adicionales que van a ser almacenados dependiendo del grupo. Suponga que un Cliente, puede ser una persona, una sociedad o bien una empresa y que deben almacenar datos adicionales dependiendo del tipo. Estos datos adicionales son: Cliente-Persona: Direccin, NmerodeSeguroSocial Cliente-Sociedad: NombredelSocioAdministrador, Direccin, NmerodeIdentificadorFiscal Cliente-Empresa: PersonaContactoEmpresa, Telfono, NmerodelIdentificadorFiscal Una posibilidad es asignar tales atributos a la entidad Cliente (ver Figura # 7 (a)). En este caso, algunos de los atributos no son aplicables, NombredelSocioAdministrador no significa nada para un cliente, persona o empresa y, por lo tanto, no puede poseer un valor.

38

Cliente Contiene NmeroDeCliente NombreDeCliente CantidadAdeudada Direccin NmerodeSeguroSocial NombredelSocioAdministrador NmerodeIdentificadorFiscal PersonaContactoEmpresa Telfono Figura # 7 (a) Cliente sin entidades subtipo. En lugar de eso, un modelo ms preciso definira tres entidades subtipo, tal como se muestra en la Figura # 7 (b). Aqu las entidades Cliente-Persona, Cliente-Sociedad y Cliente-Empresa se muestran como subtipos de Cliente. A su vez, Cliente es un supertipo de las entidades Cliente-Persona, Cliente-Sociedad y Cliente-Empresa. La junto a las lneas de relacin indica que Cliente-Persona, Cliente-Sociedad y Cliente-Empresa son subtipos de Cliente. Cada entidad subtipo debe pertenecer al supertipo Cliente. La lnea curva con un uno junto a ella indica que una entidad Cliente debe pertenecer a un y slo un subtipo. Eso quiere decir que los subtipos son excluyentes y que se requiere uno de ellos.

39

CLIENTE 1 CLIENTEPERSONA
Cliente Contiene NmeroDeCliente NombreDeCliente CantidadAdeudada Cliente-Sociedad Contiene NombredelSocioAdministrador Direccin NmerodeIdentificadorFiscal

CLIENTESOCIEDAD

CLIENTEEMPRESA

Cliente-Persona Contiene Direccin NmerodeSeguroSocial

Cliente-Empresa Contiene PersonaContactoEmpresa Telfono NmerodeIdentificadorFiscal

Figura # 7 (b). Cliente con entidades subtipo. Sin embargo, los subtipos no son siempre mutuamente excluyentes, ni se requieren siempre. La Figura # 7 (c) muestra los subtipos Cliente-que-usa dentro de Cliente. La M indica que Cliente puede pertenecer de cero a mltiples subtipos que usan Cliente. Tales estructuras se denominan jerarquas de generalizacin, porque Cliente es una generalizacin de los tres subtipos. En ocasiones este tipo de relacin se denomina Relacin ES-UN, por lo tanto, Cliente-Persona es un Cliente, al igual que Cliente-Sociedad y Cliente-Empresa.

40

CLIENTE m CLIENTE QUE EMPLEA PC CLIENTE QUE EMPLEA MINI CLIENTE QUE EMPLEA MINICOMPUTADORA

Figura # 7 (c) Subtipos no excluyentes con supertipo opcional. Las jerarquas de generalizacin tienen una caracterstica especial llamada herencia, lo cual quiere decir que las entidades en los subtipos heredan atributos de la clase de entidad supertipo. Por ejemplo, Cliente-Sociedad hereda un NombreDeCliente y una CantidadAdeudada de Cliente. Para que esta herencia sea apropiada, las dos clases de entidad deben tener el mismo identificador. 3.3. Enfoque Ascendente Bajo el enfoque de diseo descendente se debe realizar una fase de anlisis en la cual se debe obtener una comprensin del problema dentro de la organizacin y un estudio de la semntica de los datos involucrados con la organizacin, seguidamente se pasa a la fase de diseo cuyo objetivo es obtener una descripcin de la BD, es decir, aquella informacin que represente una abstraccin de la situacin a modelar. Dado que es posible establecer un objetivo muy formal y preciso en la fase de diseo se requiere que este estudio se haga formalmente, para esto se escoge el mbito de los modelos relacionales, haciendo la salvedad de que el producto del diseo ascendente sea de uso exclusivo de este tipo de modelo de datos. Una vez finalizada la fase de anlisis se puede obtener un esquema universal, formado por todos los atributos y las dependencias de los datos encontrados. En este punto cabe preguntar si el esquema inicial que se ha obtenido constituye una buena BD. Por lo general, la respuesta es no porque esa relacin o esquema universal no permite realizar una adecuada dinmica de la situacin a modelar, dicho de otra manera, cuando se realizan operaciones sobre un esquema inicial se tienen los siguientes problemas: - Redundancia - Anomalas de insercin, eliminacin y actualizacin. Sea el siguiente ejemplo RSUP (#S, #P, Cantidad, Ciudad, Status) presenta problemas en cuanto a: Redundancia: Repeticin de datos en una Base de Datos. Ejemplo: La ciudad est repetida tantas veces como aparece un envo en la relacin.

41

Anomalas de actualizacin: Inconsistencia de los datos como resultado de datos redundantes y actualizaciones parciales. Ejemplo: Si un suplidor cambia de ciudad hay que modificar tantas tuplas como envos de este suplidor tenga en RSUP. Anomalas de insercin: Imposibilidad de adicionar datos en la Base de Datos debido a la ausencia de otros datos. Ejemplo: No se puede incluir un suplidor que no haya entregado ninguna parte. Anomalas de eliminacin: Prdida no intencionada de datos debido a que se han borrado otros datos. Ejemplo: Si se elimina el envo de un suplidor, se estara eliminando a este tambin. 3.3.1. Normalizacin como mtodo de diseo ascendente El problema del diseo ascendente de un esquema se puede resumir en, dado un esquema inicial encontrar un equivalente que evite los problemas enumerados (redundancia, anomalas). Desde un punto de vista semntico sera la transformacin de una informacin molecular en una agrupacin de informaciones equivalentes y que interrelacionadas formen un todo. En este punto se puede decir que las reglas de normalizacin estn destinadas a prevenir anomalas e inconsistencias de los datos. Las reglas de normalizacin fueron definidas por Cood (1970). El punto fundamental en el proceso es que dada una relacin que posee ciertas propiedades indeseables, las reglas de normalizacin permiten reconocer tales casos y muestran como esa relacin puede ser descompuesta en una forma ms deseable . La Normalizacin se define cmo un mtodo de diseo ascendente basado en el concepto de formas normales, as se dice que una relacin est en una forma normal particular si cumple con un conjunto de restricciones. A medida que se incrementan las formas normales se incrementa el nmero de restricciones que debe cumplir esa relacin. 3.3.2. Dependencia funcional Definicin: Dada una relacin R, el atributo Y de R depende funcionalmente del atributo X de R - en smbolos R.X R.Y (lase R. X determina funcionalmente a R.Y) - si y slo si un solo valor y en R est asociado a cada valor X en R (en cualquier momento dado). Los atributos X y Y pueden ser compuestos. En la base de datos de proveedores y partes, por ejemplo, los atributos SNOMBRE, SITUACIN y CIUDAD de la relacin S son todos funcionalmente dependientes del atributo S# de la relacin S, porque, dado un valor especfico de S.S#, existe slo un valor correspondiente de S.SNOMBRE, de S.SITUACIN y de S.CIUDAD. En smbolos, S . S# S . SNOMBRE S . S# S . SITUACIN S . S# S . CIUDAD o, en forma ms concisa, S . S# S . (SNOMBRE, SITUACIN, CIUDAD)

42

Si el atributo X es una clave candidata de la relacin R - en particular, si es la clave primaria - entonces todos los atributos Y de la relacin R deben por fuerza depender funcionalmente de X (esto se desprende de la definicin de clave candidata). Los ejemplos anteriores con la relacin S ilustran este punto. De manera, similar, en las relaciones P y SP tenemos: P . P# P . PNOMBRE P . P# P . COLOR P . P# P . PESO P . P# P . CIUDAD SP . (S#, P#) P . PESO Sin embargo, es necesario recordar, que la definicin de dependencia funcional (DF) no requiere que X sea una clave candidata de R; en otras palabras, no es obligatorio que un valor de X dado aparezca en una sola tupla de R. Dependencia funcional completa. Se dice que el atributo Y de la relacin R es por completo dependiente funcionalmente del atributo X de la relacin R si depende funcionalmente de X y no depende funcionalmente de ningn subconjunto propio de X (es decir, no existe un subconjunto propio Z de los atributos componentes de X tales que Y sea funcionalmente dependiente de Z). Por ejemplo, en la relacin SP, no hay duda de que el atributo CIUDAD depende funcionalmente del atributo compuesto (S#, P#): SP. (S# ,P#) SP . CIUDAD

3.3.3. Primera Forma Normal (1FN) Una relacin est en 1NF si y slo si todos los dominios de sus atributos son atmicos, es decir, que no se pueden descomponer en varios atributos. Ejemplo: Nombre Juan Prez Pedro Gmez Luis Gonzlez Telfono 5615555,5614444 6052170,6052132 6052131, 6052272

Esta relacin no est en 1FN ya que uno de sus atributos (telfono) no es atmico, para pasarla a 1FN se procede de la siguiente manera:

43

Ejemplo: Nombre Juan Prez Juan Prez Pedro Gmez Pedro Gmez Luis Gonzlez Luis Gonzlez Telfono 5615555 5614444 6052170 6052132 6052131 6052272

Ejemplo: Sea la relacin R (cdigo, cantidad, ciudad, status) donde cdigo = (S#, P#), entonces R no est en 1FN ya que el atributo cdigo no es atmico, para que est en 1FN se debe hacer lo siguiente: R1 (S#, P#, cdigo, cantidad, ciudad, status) Ahora est en 1FN. R1 an cuando est en 1FN, presenta algunos problemas de anomalas y redundancia. El diagrama de dependencias funcionales de la relacin R1 se muestra a continuacin.

S# Cantidad P#

Status

Ciudad

Aqu los atributos tienen los significados usuales, slo se introduce la restriccin que status es funcionalmente dependiente de la ciudad. (El significado de esta restriccin es que el status de un proveedor se determina por la localizacin correspondiente. La clave primaria de R1 es (S#, P#)). 3.3.4. Segunda Forma Normal (2FN) Los problemas de la relacin R1 se pueden expresar formalmente como : Existen dependencias funcionales no completas. Esto nos lleva la existencia de una clave, es decir, a un conjunto de atributos que determinan a todos los dems y adems ningn elemento puede ser extrado del conjunto sin que se pierda la propiedad de que todos los dems atributos dependan funcionalmente de la clave; como se ve el concepto de clave divide los atributos en atributos claves y atributos no claves. Ahora el problema es descomponer la relacin en un conjunto de relaciones equivalentes pero sin los problemas producidos por la existencia de dependencias no completas. La idea es entonces eliminar las dependencias funcionales no completas. Esto se puede ver en el diagrama de dependencias funcionales.

44

R2 (S# , P# , Cantidad) S# Cantidad P#

R2 (S# , Status, Ciudad) S# Status

Ciudad

Ahora se puede definir la 2FN como: Una relacin R est en 2NF si y slo si est en 1FN y cada atributo no clave de la relacin es completamente dependiente de la clave primaria, es decir, existe dependencia funcional completa de los atributos no claves con respecto a la clave. As las relaciones R2 y R2 estn en 2FN. Una relacin que est en 1FN y no en 2FN se puede reducir siempre a un conjunto equivalente de relaciones 2FN. (Una relacin en 1NF que no est en 2FN debe tener una clave primaria compuesta). La reduccin consiste en reemplazar las relaciones por proyecciones adecuadas, el conjunto de estas proyecciones es equivalente a la relacin original, en el sentido de que la relacin original se puede recuperar siempre tomando la reunin natural (join) de estas proyecciones, de manera que ninguna informacin se pierda en el proceso. En el ejemplo R2 y R2 son proyecciones de R1 y R1 es la reunin (join) natural de R2 y R2 sobre S#. Sin embargo la estructura de R2 todava presenta problemas de anomalas. 3.3.5. Tercera Forma Normal (3FN) Los problemas de R2 son producto de la dependencias entre los atributos no claves, este problema puede ser enunciado formalmente como sigue. Existen dependencias funcionales entre atributos no claves, es decir, dada una relacin R donde R (x, y, z,.....w) siendo x la clave primaria y el resto atributos no claves, entonces si existe un atributo diferente de X, un Y (por ejemplo) tal que ese atributo depende funcionalmente de un atributo no clave z w entonces existe transitividad. Ahora el problema es descomponer por proyecciones la relacin, de tal manera, que al reunir las proyecciones se obtenga la relacin inicial y que las proyecciones sean independientes. Una relacin est en 3NF si y slo si est en 2FN y no existe dependencia transitiva de los atributos no claves con respecto a la clave, es decir, todos los atributos no clave dependen de manera no transitiva de la clave primaria. La dependencia transitiva aparece cuando un atributo no clave es funcionalmente dependiente de uno o ms atributos no claves. R2 (S#, status, ciudad) Se hace proyeccin sobre S# y ciudad y se obtiene R3 (S#, ciudad)

45

Se hace proyeccin sobre ciudad y status y se obtiene R3 (ciudad, status)

Los diagramas de dependencias funcionales son:

R3 S# Ciudad

R3 Ciudad Status

3.3.6. Forma normal Boyce/Codd La definicin de Codd de 3FN acusa ciertas insuficiencias tales como que sta no maneja satisfactoriamente el caso de relaciones que posean dos o ms claves candidatas compuestas y solapadas. Una definicin revisada (debida a Boyce y a Codd) ms fuerte se dio, con la finalidad de solventar estos problemas. Esta revisin se denomin Forma normal Boyce/Codd (FNBC). Esta es conceptualmente ms sencilla que la 3FN en el sentido que no hace referencia explcitas de las 1FN y 2FN, as como tampoco a conceptos de dependencia transitiva o completa. FNBC: Una relacin R est en Forma normal Boyce/Codd si y slo si cada determinante es una clave candidata. Donde un determinante se define como un atributo tal vez compuesto, del cual depende funcionalmente en forma completa algn atributo. Ejemplos: Sea R1 (S#, P#, cantidad, ciudad, status) Determinantes de R1: S#, ciudad, (S#, P#) R1 no est en FNBC ya que S# y ciudad no son candidatos a clave. R2 (S#, P#, cantidad) Determinante: (S#, P#) R2 est en FNBC ya que el determinante es la clave primaria. R2 (S#, status, ciudad) Determinante: S#, ciudad R2 no est en FNBC ya que ciudad no es candidato a clave primaria. Consideremos ahora un ejemplo donde las claves candidatas solapan. Dos clave candidatas se solapan si comprenden dos o ms atributos cada una y si tienen algn atributo en comn. Sea la relacin SSP en 3FN SSP (S#, NOMS, P#, cantidad)

claves (S#, P#) (NOMS, P#) Determinantes de SSP S#, NOMS, (P#, S#), (NOMS, P#)

SSP no est en FNBC ya que dos de sus determinantes S# y NOMS no son claves candidatas (S# determina a NOMS y viceversa).
46

La solucin del problema consiste en descomponer la relacin SSP en dos proyecciones SS(S#, NOMS) SP(S#, P#, cantidad) SS y SP estn en FNBC.

3.3.7. Cuarta forma normal (4FN) En una situacin a modelar existen casos en que un valor de un conjunto de atributos determina un conjunto de valores de otro conjunto de atributos de una relacin R. As surge un nuevo tipo de dependencia, la DMV (Dependencia Multivaluada), la cual es una generalizacin de las DF. Cuando las relaciones presentan varias DMV presentan informacin molecular la cual debe ser descompuesta. En la formulacin de todas estas ideas en el proceso de normalizacin se define la 4FN. Una relacin R est en 4FN si y slo si, siempre que exista una DMV en R, B y entonces todos los dems atributos de R dependen slo funcionalmente de X, para todos los atributos X de R). Por lo tanto la relacin en 4FN est en FNBC. Ejemplo: Sea la siguiente relacin R. Profesor Prez Prez Prado Prado Gmez Gonzlez Gonzlez Texto Mecnica Bs ptica Mecnica Bs ptica Mecnica Bs Algebra Geometra
CTX est en FNBC, ya que toda la relacin es clave. El problema de CTX es que los profesores y los textos son independientes entre s: La DMV en CTX son: Curso Profesor Curso Texto

A A (A

CTX Curso Fsica Fsica Fsica Fsica Fsica Matemtica Matemtica

Para solucionar los problemas de redundancia de CTX se puede aplicar el teorema demostrado por Fagin que dice: La relacin R con atributos A, B y C se pueden descomponer sin prdidas en sus dos proyecciones R1(A, B) y R2 (A, C) si y slo si la DMV A B/C se cumple en R. Por lo tanto se descompone por proyecciones CTX (curso, profesor, texto) en CTX (curso, profesor) y CTX (curso, texto) CTX y CTX estn en 4FN. Se puede concluir entonces: - Toda relacin en 4FN est en FNBC. - Cualquier relacin puede descomponerse en un conjunto de relaciones equivalentes en 4FN.

47

3.3.8. Quinta forma normal (5FN) Al analizar las relaciones y sus dependencias se observa que existen relaciones que no se pueden descomponer en dos relaciones pero si en tres o ms. Luego entonces tienen informacin molecular. Para solucionar este problema se defini la 5FN de las siguiente manera : Una relacin R est en 5FN si y slo si no puede ser proyectable en proyecciones que concatenadas den la relacin inicial (las proyecciones deben tener claves diferentes) . Ejemplo: Sea la relacin SPJ (S#, P#, J#) con el siguiente significado de c/tupla < s, p, j > el suplidor s suministra la parte p para el proyecto j. Esta relacin SPJ no est en 5FN porque sus proyecciones SP(S#, P#) , PJ(J#, P#) , SJ(S#, J#) concatenadas dan la relacin original; luego SP, PJ y SJ estn en 5FN. Existen razones prcticas para no aplicar el proceso de normalizacin hasta 5FN siendo conveniente slo aplicarlo hasta 3FN. Los motivos principales son los conflictos en las actualizaciones y las consultas.

CONCLUSIONES Una base de datos es una coleccin de registros o archivos relacionados lgicamente. Una BD consolida muchos registros almacenados previamente en archivos independientes, de modo que un cmulo (pool) comn de registros sirvan como una sola central para muchas aplicaciones de procesos que necesitan este tipo de datos. El Objetivo primordial de un SMBD es proporcionar un entorno para recuperar informacin y almacenar nueva informacin en la BD, para lo cual debe proporcionar a los usuarios una visin abstracta de los datos. Hay 4 tipos diferentes de usuarios, diferenciados por la forma en que esperan interactuar con el sistema: Programadores de aplicaciones, Usuarios sofisticados, Usuarios especializados y Usuarios ingenuos. Entre las operaciones sobre una BD, se tienen consultas de BD, ordenamiento de los datos, impresin de informes, etiquetas y formatos de cartas, adems de consultas complejas. Existen dos lenguajes diferentes: uno para definir el esquema de la BD, Lenguaje de Definicin de Datos (DDL), y otro para expresar las consultas y actualizaciones de la BD, Lenguaje de Manipulacin de Datos (DML).

48

La arquitectura ANSI/PARC se divide en tres niveles denominados niveles interno, conceptual y externo. Un modelo de datos es un conjunto de conceptos que pueden servir para describir la estructura de la base de datos. Es decir, un Modelo de Datos no es mas que una coleccin de herramientas conceptuales que se utilizan para describir los datos, las relaciones existentes entre ellos, la semntica asociada a los mismos y las restricciones de consistencia. Los modelos de datos se dividen en 3 grupos: Modelos Lgicos basados en Registros, Modelos Lgicos basados en Objetos y Modelos Fsicos de Datos. El diseo de sistemas de BD se puede realizar bajo dos enfoques: el enfoque descendente (modelo Entidad/Relacin) y el enfoque ascendente (Normalizacin).

49

BIBLIOGRAFA [1] DATE, C.J. Introduccin a los Sistemas de Bases de Datos. Vol I. Quinta Edicin. Addison-Wesley Iberoamericana. 2000. [2] KORTH H., SILBERSCHATZ A. Fundamentos de bases de datos. Segunda Edicin. McGraw-Hill. 1998. [3] HANSEN & HANSEN. Diseo y Administracin de Base de Datos. 2da. Edicin. 1997. CHEN, Peter. The Entity-Relationship approach to logical database design. Information Sciences, Data Base Monograph Series Number 6 (1977) QED

KROENKE, David M. Database Processing: Fundamentals, Design and Implementation. Fourth Edition. Macmillan Publishing Company, 1992. ELMASRI / NAVATHE. Sistemas de Bases de Datos. Addison Wisley. Segunda Edicin 1997 TSICHRITZIS D., LOCHOVSKY F. 1982. Data Models. Conceptos fundamentales.

Prentice Hall Software Series.

50