Manual Inacap Base Datos I.pdf - Adobe Reader, Versión - Firma1, Firmado Por DAI, 2002.04.26 13 - 24 - 43 - 04'00'

INACAP
Direccin rea de Informtica
MANUAL Bases de Datos I

MARZO DEL 2002
Programa de Estudios: INGENIERA EN GESTIN INFORMTICA ANALISTA PROGRAMADOR
Versin 3.0
-0-
Bases de Datos I
INACAP
Direccin rea Informtica
INDICE Tema
1. Enfoques de Bases de Datos 1.1 Enfoque tradicional de procesamientos de datos Enfoque por agregacin Sistemas de procesamiento de archivos Desventajas Redundancia no controlada Inconsistencia de Datos Inflexibilidad Escasa posibilidad de compartir datos Pobre estandarizacin Baja productividad del programador Excesiva Mantencion 1.2 Enfoque de bases de datos Elementos del enfoque de banco de datos Implementacin del enfoque de banco de datos Beneficios y riesgos de usar banco de datos 1.3 Tipos de sistemas de informacin Operacionales Administrativos De apoyo a la toma de decisiones Concepto Data-Warehouse 1.4 Metodologas de Desarrollo 1.5 Administracin del recurso informacin 2. Caractersticas y representacin de datos 2.1 Tipos de bases de datos Jerrquicas De red Relacional Orientada al objeto 2.2 Naturaleza del dato 2.3 Representacin del dato 2.4 Entidades 2.5 Atributos 2.6 Tipos de relaciones Uno a uno Uno a muchos Muchos a muchos Recursivas 3. Modelos de datos 3.1 Niveles de abstraccin Versin 3.0 1
Pgina
4 4 7 7 7 7 7 7 7 7 7 7 9 9 9 15
15
17 17 18 17 19 20 21 22 23 23 23 23 23 23 23 24 24 Bases de Datos I
INACAP 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 3.10
Direccin rea Informtica 26 26 26
Semntica de los datos Cardinalidad Grado Dependencia Tiempo Unicidad Clase Agregacin Modelos de datos dependientes de la tecnologa Jerrquico De red Relacional 3.11 Modelos de datos independientes de la tecnologa Orientada a objeto Entidad Relacin 3.12 Normalizacin de los modelos Primera forma normal Segunda forma normal Tercera forma normal
27 27 27 28 31 31 32 32 33 35 38 41 43 44 44 44 44 44 45 46 47
4. Metodologa de diseo de una base de datos 4.1 Enfoque metodolgico Planificacin Top Down Diseo Bottom Up 4.2 Planificacin de base de datos Anlisis Organizacional Funciones Procesos Actividades Matrices que relacionan los componentes de una organizacin 4.3 Obtencin del modelo corporativo 4.4 Obtencin de las bases de datos requeridas por la organizacin 4.5 Proceso de diseo de bases de datos Etapa 1: Formulacin y anlisis de Requerimientos Paso1:Identificacin del mbito de la base de datos Paso2:Establecer estndares de recoleccin de datos Paso 3: Identificacin de las vistas de usuarios Paso 4: Construccin del Diccionario de Datos Paso5:Establecer requerimientos de procesamiento Etapa 2: Diseo Conceptual Paso 1: Normalizacin Paso 2: Integracin de vistas Paso3: Generacin del modelo conceptual de datos
49 52 53 54
60
Versin 3.0
Bases de Datos I
INACAP Paso 4: Revisin del diseo Etapa 3: Diseo de la implementacin Paso 1: Distribucin de datos Paso 2: Organizacin de archivos Paso 3: Indexacin Paso 4: Restricciones de integridad Paso 5: Mapeo o modelo interno Paso 6: Diseo de programas 5. Lenguaje de consulta estndar (SQL) 5.1 Instrucciones de definicin de los datos Create Alter Drop 5.2 Instrucciones de manipulacin de los datos Select Insert Delete Update 5.3 Funciones Especiales De nmero De cadena De fecha 5.4 Operadores de comparacin 5.5 Operadores Lgicos 5.6 Consulta sobre mltiples tablas 5.7 Formato de salidas
64
66 66 66 66 66 67 67 67 67 67
67 68 69 69
Versin 3.0
Bases de Datos I
INACAP
Unidad 1: Enfoques de Bases de Datos.

1.1 Enfoque tradicional de procesamiento de datos Las organizaciones al incorporar sistemas de informacin administrativa, lo hacen con el fin de resolver problemas puntuales que apoyen la toma de decisiones. La planificacin de un SIA utiliza dos enfoques tradicionales denominados enfoque por agregacin y enfoque de base de datos. Para iniciar el tema es necesario que demos una mirada introductoria a algunos conceptos elementales de anlisis de sistemas tradicionales que son la base para una adecuada comprensin del enfoque por agregacin y del enfoque de base de datos. Las Empresas e Instituciones, organizan su estructura interna en pos de la eficiencia tecnolgica, econmica y administrativa para alcanzar los objetivos y metas que justifican su existencia como tal. Esto determina la bsqueda de herramientas tcnicas y metodolgicas que faciliten el proceso de toma de decisiones. Los sistemas de informacin administrativos, SIA, son las herramientas que apoyan la toma de decisiones. Qu es un Sistema de Informacin Administrativo? Se entiende por SIA, las personas, estructura organizacional, mquinas manuales y computarizadas, procedimientos administrativos, recursos logsticos, que en su conjunto tienen como finalidad la recoleccin, clasificacin, preparacin, almacenamiento, modificacin, actualizacin, recuperacin y transmisin de datos que apoyan la toma de decisiones en la organizacin. Recursos logsticos: Los recursos logsticos son los que permiten cumplir la transformacin de los datos. En general estos recursos son de tipo humano, fsicos, equipos computacionales, software, datos histricos, algoritmos y procedimientos, que posibilitan guiar la secuencia y la forma de diferentes acciones que determinan la forma en que se transforman los datos Procesos de transformacin: Se nutren de datos de entrada y recursos logsticos que logren la transformacin de los datos.
Versin 3.0
Bases de Datos I
INACAP Datos de entrada:
Los datos de entrada se obtienen de tres vertientes, datos primarios o los provenientes de procesos internos, de datos obtenidos de cmo se tomaron las decisiones pasadas y desde los resultados de las acciones llevadas a buen termino por la organizacin. Objetivos y Metas: Toda empresa debe cumplir sus metas y objetivos, de lo contrario no se justifica, por tanto debe cautelar que los resultados de la gestin de cada uno de los niveles administrativos de la organizacin sea lo ms eficiente y efectiva posible. Las metas y objetivos son el resultado de acciones generadas por decisiones tomadas por los diferentes niveles de la estructura de toma de decisiones. Toma de decisiones: Las decisiones que se adoptan a travs del proceso de toma de decisiones son apoyadas y los problemas que surgen son enfrentados con informacin ( relevante y oportuna). Procedimientos administrativos: Para llevar a buen fin las actividades administrativas mencionadas la organizacin implementa un conjunto de procedimientos administrativos. Toma de decisiones y Sias La toma de decisiones en un SIA se establece en tres niveles, las estructuradas o programables, las semi-estructuradas, las no estructuradas o no programables. En al marco de la toma de decisiones estructuradas se desarrollan modelos reglados que establecen la forma de tomar las decisiones. Respecto de la toma de decisiones no estructuradas, son aquellas que se toman por expertos y no es posible desarrollar un algoritmo que automatice tal proceso heurstico. Niveles de decisin: Los Sias proporcionan informacin para la toma de decisiones a tres niveles de decisin, nivel de planeamiento estratgico, niveles de control de gestin y operativo.
Versin 3.0
Bases de Datos I
INACAP Nivel de planeamiento estratgico:
Los informes que proporcionan los Sias a este nivel contienen en general: informacin actualizada de la base de datos, estimaciones a futuro, basada en la informacin actualizada de la base de datos e informacin que pone el nfasis en situaciones excepcionales. Nivel de control de gestin: Se relaciona con la informacin necesaria para el uso eficiente y efectivo de los recursos que permitan cumplir los objetivos y metas de la organizacin. Los informes emanados por los Sias para este nivel son aquellos que contengan informacin para: analizar y efectuar acciones correctivas sobre la operacin y estado de las funciones correspondientes adems de informacin que refleje estados de transacciones pasadas. Nivel de control operacional: Esta relacionado con la implementacin de las diversas actividades que componen la operacin de la organizacin para lograr los objetivos aplicando los recursos de acuerdo a las polticas establecidas. Los informes que apoyan la toma de decisiones a nivel de control operacional se caracterizan por incluir: transacciones rutinarias, datos utilizados en tareas simples y repetitivas cuyo origen esta establecido claramente. Tipos de SIAS en el enfoque tradicional de datos SIA puntual, se caracteriza por apoyar la toma de decisiones en una funcin especifica dentro de la organizacin. Por ejemplo: Sias para la gestin de existencias. SIA integral, se caracteriza por cubrir todas las actividades de la organizacin, pudiendo incluir los denominados SIAS puntuales. En general y a grosso modo un SIA debe contemplar los siguientes elementos: Explicitacin de metas y objetivos de la organizacin o funcin administrativa. 1. Determinacin de medidas de eficiencia y efectividad para evaluar el log objetivos y metas. 2. Estructuracin del proceso de toma de decisiones que ser utilizado. 3. Identificacin y caracterizacin de la informacin relevante provista por el SIA. 4. Determinacin de datos de salida, entrada, procesos de transformacin, tipos y cantidad de recursos a emplear, talque satisfagan los requerimientos de informacin relevante.
Versin 3.0
Bases de Datos I
INACAP
5. El SIA provee todos los procedimientos administrativos y documentacin necesaria que hacen posible operar las diferentes actividades del SIA. Enfoque por agregacin Cuando la organizacin implementa los SIAS por primera vez lo hacen para resolver problemas puntuales que apoyan la toma de decisiones y controlar el logro de sus metas y objetivos. Ahora la planificacin para el desarrollo de un SIA que aplica el enfoque por agregacin, se caracteriza por implementar SIAS puntuales independientes uno de otros con una interaccin mnima entre ellos y que apenas comparten recursos. Estos SIAS puntuales se desarrollan uno sobre el otro a medida que se van necesitando, originando problemas como la conocida duplicidad de informacin. La expansin de las organizaciones produce naturalmente la evolucin progresiva de los SIAS, implicando problemas puntuales de procesamiento de informacin ( cuellos de botella), al desarrollar estas soluciones bajo el enfoque por agregacin se han producido los siguientes inconvenientes: 1. Los SIAS se desarrollan en forma independiente entre s, sin compartir recursos ni interaccin. 2. Se produce consecuentemente duplicidad de informacin, un dato se encuentra en varios archivos. 3. Se produce como corolario de lo anterior problemas con la consistencia de la informacin ya que los datos duplicados no sern actualizados al mismo tiempo. 4. Adems la responsabilidad de la actualizacin de estos datos recae en muchas personas. Otras consecuencias relativas al contexto de los datos: 1. Los datos satisfacen SIAS que responden a necesidades especificas del rea, departamento o funcin de la organizacin. 2. Pueden existir datos con la misma denominacin pero con valores distintos por provenir de fuentes distintas, ser interpretados en forma distinta, poseer procesos de actualizacin que obedezcan a acontecimientos distintos. 3. Los mismos datos pueden derivar en resultados diferentes dependiendo del SIA y sus procesos. Respecto del diseo de los SIAS aplicando el enfoque por agregacin, surgen las siguientes consecuencias:
Versin 3.0
Bases de Datos I
INACAP Sobre el diseo lgico:
1. Al disear un SIA bajo este enfoque resulta compleja la delimitacin del mismo, dado que las funciones administrativas estn interrelacionadas entre s. 2. Los datos se encuentran distribuidos en diversos SIAS, lo que implica dificultades al momento de establecer las fuentes de informacin u origen de datos para el sistema. 3. Aumenta la necesidad de relacionar los datos para satisfacer nuevos requerimientos. 4. La identificacin y caracterizacin de datos se vuelve inorgnico. 5. S complejiza el diseo de procedimientos administrativos. Respecto del diseo fsico: 1. Implica la creacin de nuevos archivos con datos ya existentes en otros, as como nuevos datos. 2. El uso de diferentes lenguajes de programacin produce incompatibilidad en los formatos de almacenaje. 3. Al modificar programas de aplicacin generalmente es necesario modificar tambin sus archivos de datos influyendo a otros programas que usan los mismos archivos. Sistema de procesamiento de archivos En la dcada del 60 el tratamiento de la informacin se caracteriz por la aplicacin de programas denominados BALANCE LINE, que se caracterizan por operar con dos tipos de archivos clsicos de la poca, denominados archivos maestros y de transacciones. La lgica de operacin de este tipo de programa conocidos hoy como pareo de archivos se basa en la actualizacin de uno o ms archivos maestros a partir de uno o ms archivo de transacciones. Es el caso de una cuenta corriente y sus movimientos respectivamente. Otro programa de esta era de los sistemas de procesamiento de archivos es el conocido corte de control, aplicado para producir informes de acuerdo a un criterio de agrupamiento de datos. Es el caso de la cartola mensual de una cuenta corriente, all las transacciones u operaciones son ordenadas por fecha. Desventajas del enfoque tradicional de datos 1. 2. 3. 4. 5. 6. 7. Redundancia no controlada Inconsistencia de datos Inflexibilidad Escasa posibilidad de compartir datos Pobre estandarizacin Baja productividad del programador Excesiva Mantencin
Versin 3.0
Bases de Datos I
INACAP 1.2 Enfoque de bases de datos Elementos del enfoque de Banco de Datos:
La administracin, control y uso de los datos en la organizacin basado al enfoque de base de datos se rige de acuerdo a los siguientes consideraciones: Los datos de la organizacin son contemplados como un recurso fundamental de esta, del mismo modo que el capital, los recursos humanos y otros. Por lo tanto se le da un manejo, control y uso eficiente y efectivo. En consecuencia se requiere un nivel de decisiones dentro de la organizacin cuya responsabilidad sea administrar el recurso informacin. Todos los datos de la informacin se encuentran almacenados en archivos centralizados, que permiten el acceso de las aplicaciones que las necesitan. Los archivos centralizados son accesibles por las aplicaciones y los usuarios segn sus necesidades. Contempla un sistema de identificacin, descripcin y definicin de los datos de la organizacin. Incluye dispositivos de acceso directo y pantallas que facilitan la interrogacin por parte del usuario. Permite establecer distintos tipos de usuarios con distintos tipos de accesos centralizados. Incluye software que facilita la interrogacin de la base de datos para los distintos niveles de usuarios. Implementa condiciones de seguridad e integridad de los datos y procedimientos de recuperacin de datos en caso de error. Comprende un almacn centralizado que incluye toda la informacin necesaria de los datos de la base de datos con el fin de evitar problemas en su administracin a programadores, analistas de sistemas y otros especialistas. Implementacin del enfoque de Banco de Datos: Antes de contemplar los elementos del enfoque de base de datos es necesario examinar las funciones que deben incluirse en la implementacin de este enfoque. Para la implementacin del enfoque de base de datos se debe distinguir las siguientes funciones:
Versin 3.0
Bases de Datos I
INACAP 1. Administracin de la informacin:
Encargada de caracterizar, identificar y estandarizar los datos contemplados para la base de datos 2. Almacenamiento de datos: Centraliza los datos de la base de datos en archivos integrados, que genricamente se denominan base de datos. 3. Supervisin del almacenamiento y recuperacin de los datos: Proporciona las facilidades necesarias para definir, acceder, manejar, recuperar y controlar los datos que se encuentran en la base de datos. Esta funcin es apoyada por el denominado SABD sigla de sistema administrador de base de datos, este software interacta fuertemente con el sistema operativo. 4. Administracin de la implementacin computacional de la base de datos: Identifica, caracteriza, estructura y estandariza computacionalmente aquellos datos que nutren la base de datos y que estarn bajo el control del SABD, por lo cual se llama ASABD, es decir administrador el SABD. Esta funcin adems se encarga de administrar el hardware y software asociado que permite operar al SABD, as como aquellos archivos que este origina. 5. Demanda: Debe agrupar todos los usuarios de la base de datos, que aprovechan las facilidades provistas por el SABD. Se entiende por usuarios a los que toman decisiones, los sistemas de informacin administrativos, los programadores, analistas de sistemas y otros. Elementos del enfoque: A. Administrador de la Informacin (AI): El administrador de la informacin debe identificar, caracterizar y controlar los datos incluidos en la base de datos, tal que los usuarios finales encuentren en ella los datos necesarios para la toma de decisiones y los SIAS encuentren los datos para opera. El AI centraliza los datos evitando la duplicidad descontrolada, ambigedad e inconsistencias de la informacin.
Versin 3.0
10
Bases de Datos I
INACAP Las actividades del AI:
1. Determinar y estructurar los requerimientos de informacin de los usuarios. 2. Especificar los requerimientos de Informacin. 3. Disear los procedimientos administrativos para que los usuarios puedan utilizar los datos de la base de datos y del diccionario de datos. ( que contiene identificacin, caracterizacin y estructura de los datos de la base de datos) En la determinacin de requerimientos de informacin el AI tiene en cuenta que la creacin y Mantencin de la base de datos debe ser segura, confiable y fiable. Entre las actividades del AI para identificar la informacin a incluir en la base de datos estn: 1. 2. 3. 4. Determinacin de las necesidades de informacin de cada usuario. Establecimiento de estndares o medidas de los datos de la base de datos. Determinacin, anlisis y filtrado de los datos a incluir en la base de datos. Producir un inventario de los datos incluidos en la base de datos.
En la especificacin de requerimientos el AI, en conjunto con usuarios y el ASABD, identifica y caracteriza los datos que irn en la BD, documentndolos de manera unvoca mediante el diccionario de datos, el cual se transforma en la fuente de informacin que tiene la organizacin, en cuanto a la disponibilidad de datos. La especificacin de requerimientos de informacin se realiza a travs del diccionario de datos, cuya Mantencin y uso es responsabilidad del AI. El diseo de procedimientos administrativos realizado por el AI esta dirigido a: 1. Definicin y control de estndares para la identificacin y caracterizacin de los datos a incluir en la base de datos 2. Modificacin de la estructura de la base de datos. 3. Procedimientos para el manejo y acceso de los datos. 4. Determinacin de responsabilidades sobre ciertos datos, de manera de asegurar la confiabilidad de los valores asignados a cada dato. 5. Determinacin de procedimientos que regulen el acceso, lectura, insercin, modificacin y eliminacin de datos de la BD. 6. Determinacin de procedimientos que permitan al AI conocer el uso dado a los datos de la base de datos. 7. Analizar las alternativas costo / beneficio para la organizacin acerca de tener una base de datos que satisfaga los requerimientos de todos los usuarios. 8. Analizar los errores encontrados por los usuarios, con el fin de colaborar en futuras reestructuraciones de la base de datos.
Versin 3.0
11
Bases de Datos I
INACAP Elementos de una Base de Datos:
Los elementos de una base de datos son los archivos integrados y l catlogo. Se entiende por archivos integrados aquellos archivos que han sido modelados y estructurados de tal forma que se encuentran relacionados entre s permitiendo su interrogacin. Los SABD proporcionan las herramientas necesaria para la produccin de este tipo de archivos, denominadas lenguajes de definicin de datos ( LDD), adems de lenguajes de manipulacin de datos ( LMD) para interrogar la base de datos. El catlogo es un archivo creado y mantenido por el SABD, en el que se mantienen las caractersticas fsicas de los datos de la base de datos. Estas caractersticas son usadas por el SABD en la traduccin y ejecucin de aplicaciones computacionales. l catlogo es producido por un conjunto de rutinas del SABD mediante las descripciones proporcionadas por el ASABD. Para ser accesado por otro conjunto de rutinas para efectos de su mantencin y lectura. En general la descripcin de los datos almacenados en l catlogo incluye: nombre del dato, tipo, largo, nivel de seguridad, fecha de origen, archivo de residencia, modo de acceso y almacenamiento.
B. Administrador de SABD La persona encargada de esta funcin tiene la responsabilidad de la implementacin y operacin del SABD. El ASABD administra el producto de software denominado SABD, realiza la creacin fsica y Mantencin de la base de datos. 1. Las principales responsabilidades del ASABD son las siguientes: 2. Desarrollo, estructuracin y crecimiento de la base de datos de acuerdo a las facilidades del SABD y la situacin de la organizacin. 3. Habilitacin de facilidades que originen una optima implementacin del SABD, como interfaz de usuarios, mecanismos de seguridad, integridad, privacidad, validacin, verificacin entre otros. 4. Supervisin del uso dado por el usuario de las facilidades otorgadas por el SABD. 5. Preparacin y difusin de procedimientos para la operacin del SABD. 6. Asistencia tcnica a los usuarios del SABD 7. Medicin peridica del desempeo del SABD. El ASABD, en conjunto con el AI deben determinar como traducir y satisfacer los requerimientos de informacin de los usuarios. Para ello, previo a la implementacin del SABD, tanto el ASABD como el AI tienen las siguientes responsabilidades: 1. Producir el inventario de datos de la organizacin. 2. Coordinar el manejo y seguridad de los datos.
Versin 3.0
12
Bases de Datos I
INACAP
3. Crear y mantener un diccionario de datos 4. Coordinar los procesos de codificacin y estandarizacin de datos. 5. Prepara normas y procedimientos para verter archivos tradicionales a la base de datos. 6. Experimentar y difundir en forma piloto las funciones del AI y el ASABD. El diseo fsico de la base de datos es labor del ASABD, realizando las siguientes actividades: 1. Coordinacin y apoyo en el desarrollo de SIAS para que estos aprovechen facilidades del SABD y la BD. 2. Mantener el contacto con los proveedores del SABD y de otros SABD 3. Mantener informacin para los usuarios respecto de la organizacin de la BD. 4. Mantener un control total sobre el DDL 5. Definir las caractersticas e identificacin de los datos 6. Analizar el contenido de la BD. 7. Mantener el software de apoyo al diccionario de datos. 8. Preparacin y Mantencin del catlogo de la base de datos. 9. Determinar la estructura fsica de la base de datos 10. Especificacin de la estructura de la BD. 11. Controlar el acceso a los datos de la BD. 12. Coordinacin entre las el SABD y el sistema operativo empleado 13. Definicin de procedimientos de proteccin contra destruccin o accesos autorizados. 14. Definicin de niveles de seguridad para el acceso a la BD. 15. Establecer procedimientos para la seguridad y proteccin fsica de los datos. 16. Participacin en la s pruebas de programas de aplicacin. 17. Establecer procedimientos de respaldo para la BD. 18. Analizar y controlar el seguimiento de trazas y errores. 19. Mantencin actualizada de los procedimientos de recuperacin de la BD. 20. Determinar procedimientos que permitan detectar violaciones a las reglas seguridad e integridad, buscando la identificacin del causante e informando a niveles que corresponda. B. Diccionario de datos ( DD) Este elemento del enfoque de base de datos es el conjunto centralizado de atributos lgicos que especifican la identificacin y caracterizacin de los datos que se manejan en la BD. La BD contiene el valor de los datos, el DD contiene meta datos, es decir los atributos lgicos de dichos datos. las
no
de los
Versin 3.0
13
Bases de Datos I
INACAP Entre las ventajas del DD se tiene:
1. Es un medio centralizado de tener informacin sobre los atributos lgicos de los datos de la BD. 2. Es un medio de estandarizacin en el manejo y uso de los datos 3. Es un medio expedito de almacenamiento y recuperacin de proposiciones de atributos lgicos originados por analistas de sistemas en el diseo de un SIA. 4. Representa una ayuda para analistas y programadores en el momento de desarrollo de un SIA. 5. Permite introducir procedimientos estandarizados en le manejo de datos, informes y documentacin de procesos y aplicaciones. Los usuarios del DD son: el AI, el SABD, usuarios finales, Analistas de Sistemas y programadores entre otros. El diccionario de datos contiene para cada dato los siguientes atributos lgicos o meta datos: Informacin respecto de: identificacin, control administrativo, seguridad, validacin y sobre relaciones lgicas y fsicas. Atributos de identificacin comprende el nombre completo del dato, nombre abreviado, sinnimos, identificador o clave, fecha de ltima actualizacin. Atributos de informacin para control administrativo incluye: unidad de origen del dato, nombre del programa o transformacin que lo origina, nombre del documento que lo contiene por primera vez en la organizacin, las unidades organizacionales y programas de aplicacin que lo usan, Cardinalidad del dato. Atributos de seguridad identificacin de las personas autorizadas para cambiar las caractersticas del dato, accesarlo o actualizarlo, fecha de ltima actualizacin e identificacin del usuario que efectu esta actualizacin. Atributos de validacin contienen lista o rango de valores permitidos, nombre de los programas validadores que actan sobre l. Atributos de relaciones lgicas algoritmos de derivacin, identifica la forma de generacin del dato, estructuras lgicas, grupos y jerarquas donde el dato es miembro. Atributos de relacin fsica: largo, tipo, nombre para programacin, reglas de edicin, unidad de medida del dato, precisin.
Versin 3.0
14
Bases de Datos I
INACAP Beneficios y riesgos de usar Banco de Datos.
Un banco de datos esta constituido por todos los datos formales, relevantes para la toma de decisiones. Los datos del banco de datos se encuentran dispersos en la organizacin soportados en diversos medios, como, archivadores, formularios, documentos, dispositivos de almacenamiento digital y otros. La base de datos se constituye por todos los datos del banco de datos, almacenados en archivos centralizados altamente disciplinados, de tal forma que puedan ser requeridos de diversas maneras lgicas, con el fin de satisfacer las consultas de los distintos usuarios de la base de datos. Los beneficios del banco de datos son amplios y casi innumerables, el banco de datos como se sealo en l prrafos anteriores representa toda la informacin relevante y formalizada de la organizacin, entindase por datos de la constitucin de la empresa hasta los relativos al pago de patentes pasando por datos de acreedores y deudores. El riesgo del banco de datos es que el volumen de informacin va aumentando paulatinamente y se hace inmanejable si no es vertida a un sistema de base de datos. 1.3 Concepto Data Warehouse La traduccin literal es almacenamiento de datos. Como es sabido existen muchos lugares donde podemos buscar datos, pero ha surgido la idea que exista un mayorista al interior de la empresa que acumule toda la informacin, bodega de datos inteligente. Existen muchas definiciones de DW, pero la ms completa es la de Bill Inmn, la cual dice: Data Warehouse es una tecnologa orientada a temas especficos, integrada, variante con el tiempo y es una coleccin no voltil que soporta la administracin del proceso de toma de decisiones dentro de las organizaciones Cundo y porqu nace? Da a da van surgiendo nuevos problemas en una organizacin y junto a ello nuevas formas de solucionarlos, la idea de DW data de hace mucho tiempo pero la razn de que hoy da sea un tema de actualidad es que hoy existen tecnologas de HW y SW suficientemente poderosas para depurar esta informacin. l porque se asocia a la necesidad de mejorar la informacin analtica a travs de un medio computacional, la mayora de la informacin til en una empresa
Versin 3.0
15
Bases de Datos I
INACAP
est encerrada en viejas aplicaciones y los usuarios crean que bastaba con crear nuevas formas de acceso pero no es as porque adems tienen las siguientes caractersticas, complejidad en la estructura de los sistemas, diseo de sistemas orientados al rendimiento ptimo, informacin dependiente, informacin a menudo dispersa en mltiples o diversos sistemas, definicin inconsistente y la solucin fue crear un almacn de datos, en el cual los datos fueran transformados, integrados y cargados a un dispositivo en donde tuvieran sentido para aquellas personas que lo necesiten como soporte a la toma de decisiones. Su creacin se ha estimulado gracias a la necesidad de sistemas de informacin que apoyen la toma de decisiones de una organizacin.
Versin 3.0
16
Bases de Datos I
INACAP
UNIDAD 2: Caractersticas y representacin de Datos.

2.1 Tipos de Bases de Datos Base de Datos Red: Una base de datos de red como su nombre lo indica, esta formado por una coleccin de registros, los cuales estn conectados entre s por medio de enlaces. El registro es similar al de una entidad como las empleadas en el modelo entidad relacin. Un registro es una coleccin de campos (atributos), cada uno de los cuales contiene solamente almacenado un solo valor, el enlace es la asociacin entre dos registros exclusivamente, as que podemos verla como una relacin estrictamente binaria. Una estructura de datos de red, llamada algunas veces estructura de plex, abarca ms que la estructura de rbol porque un nodo hijo en la estructura red puede tener ms de un padre. En otras palabras, las restriccin de que un rbol jerrquico cada hijo pude tener un solo padre, se hace menos severa. As, la estructura de rbol se puede considerar como un caso especial de la estructura de red tal como lo muestra la siguiente figura. Para ilustrar las estructura de los registros en una base de datos red, consideramos la base de datos alumno materia, los registros en lenguaje pascal entonces quedara como: type alumno = record nombreA: string[30]; control: string[8] ; esp: string[3] end; type material= record clave: string[7] nombreM: string[25] cred= string[2]; end;
Versin 3.0
17
Bases de Datos I
INACAP Ejemplo de una base de datos en red:

11234 lvarez Rosa
Cois 5100
6 21344 Rivera Juan 7 23456 Ros Mara 8
Cois 5100
Cois 5120
Cois 5130
Base de Datos Jerrquicas: En este tipo de bases de datos la informacin se distribuye en distintos niveles segn su importancia estructural: por ejemplo de la entidad automvil, depende la entidad motor, de esta depende block y de sta, depende camisa de cilindro. Un diagrama de estructura de rbol es el esquema de una base de datos. Tiene dos componentes bsicos, Registros y Ligas. Estos diagramas son similares a los de estructuras de datos en el modelo en red. La diferencia radica en que el modelo de red los registros se organizan en forma de un grafo arbitrario, mientras que el modelo jerrquico en forma de un rbol con raz. Las reglas para la formacin de rbol son: 1. No hay ciclos 2. De padre a hijos son vlidas las relaciones de uno a uno a uno a muchos El esquema de una base de datos jerrquica se presenta como una coleccin de diagramas de estructuras de rbol. Para cada diagrama existe una nica instancia de rbol base de datos. La raz de este rbol es un nodo ficticio. Los hijos de ese nodo son instancias del tipo de registros adecuados:
Versin 3.0
18
Bases de Datos I
INACAP Ejemplo de una base de datos jerrquica:
11234
lvarez
Rosa
23456
Ros
Mara
21344
Rivera
Juan
Cois 5100
Cois 5120
Cois 5100
Cois 5120
Cois 5130
Base de Datos Relacional: Base de datos en la cual la informacin est almacenada en forma de tablas, y que permite establecer relaciones entre distintas entidades por medio de campos en comn; por ejemplo, cdigo de cliente en factura y en archivo de clientes. Ejemplo de una base de datos relacional:
Seccin 1 6 7 8
Curso Cois 5100 Cois 5100 Cois 5120 Cois 5130
Versin 3.0
19
Bases de Datos I
INACAP N Est. 11234 21344 21344 23456 23456 Apellido lvarez Rivera Rivera Ros Ros Nombre Seccin Rosa 1 Juan 6 Juan 7 Mara 7 Mara 8
Diferencia entre modelos relacional, red y jerrquico: Los modelos relacionales se diferencian de los modelos de red y jerrquico en que no usan puntaros o enlaces. En Cambio el modelo relacional conecta los registros mediante valores que stos contienen.
Bases de datos orientadas a objeto: Modelo orientado a objeto: Al igual que el modelo entidad relacin se basa en una coleccin de objetos. Un objeto contiene valores almacenados en instancias dentro del objeto. Estos valores son objetos por si mismo, esto es, los objetos contienen objetos a un nivel de anidamiento de profundidad arbitraria. Un objeto tambin contiene partes de un cdigo que operan sobre el objeto, estas partes se llaman mtodos. Los objetos que contienen los mismos tipos de valores y los mismos mtodos se agrupan en clases. Una clase puede verse como definicin de tipo para objetos. En este modelo hay dos niveles de abstraccin de datos, una que es visible externamente, que ocurre en la interfase de llamada de los mtodos de un objeto y otro nivel que ocurre en la parte interna del objeto y el cdigo del mtodo. El interfase externo del objeto permanece sin cambios. La diferencia de las entidades en el modelo entidad relacin, cada objeto tiene su propia identidad nica independiente de los valores que contiene. As, dos objetos que contienen los mismos valores son, sin embargo, distintos. La distincin entre objetos individuales se mantiene en el nivel fsico por medio de identificadores de objeto.
Versin 3.0
20
Bases de Datos I
INACAP 2.2 Naturaleza del dato
La percepcin del mundo puede ser descrita como una sucesin de fenmenos. Desde el comienzo de los tiempos el hombre ha tratado de descubrirlos, ya sea que los entienda completamente o no. La descripcin de estos fenmenos es llamado Dato. Los datos corresponden al registro discreto (no continuo) de hechos acerca de un fenmeno, con lo cual ganamos informacin acerca del mundo que nos rodea (Informacin: Incremento del conocimiento que puede ser inferido de los datos). Usualmente el dato y su significado son registrados juntos, ya que el lenguaje natural es lo suficientemente poderoso para hacerlo. Por ejemplo, el Kilo de pan cuesta $460 registra el valor 460 y su significado o semntica (valor del kilo de pan en pesos). En ciertos casos los datos estn separados de su semntica. Por ejemplo, una planilla de notas es una tabla de datos. Su interpretacin implcita y se supone que quien la lee conoce su significado. El uso del computador para procesar datos ha trado consigo una mayor separacin entre lo datos y su interpretacin. Mucha de la interpretacin de los datos est explcita. Consideremos por ejemplo un programa que calcula integrales definidas, este programa recibe valores de entrada y genera valores como salida. Sin embargo el programa en s no tiene conocimiento si el problema resuelto es de termodinmica o electromagnetismo.
2.3 Representacin del dato Ha habido razones para separar los datos de su significado: Los computadores no manejan (bien) el lenguaje natural, que es la mejor forma de dar interpretacin y su significado a un dato. El almacenamiento de los datos ocupa espacio, e inicialmente este era escaso y costoso. As, tradicionalmente la interpretacin de los datos se deja al usuario y al sistema manual externo al computador. En muchos sistema la interpretacin de datos se encuentra en los programas que hacen usos de ellos, de modo que los datos pasan a ser una simple coleccin de valores. Por otra parte, supongamos que algo de la semntica de los datos se codifica junto con ellos. As los datos no slo son valores, si no que tambin tienen una semntica y lo datos estn ms cerca de la interpretacin del mundo. Ellos forman
Versin 3.0
21
Bases de Datos I
INACAP
una vista del mundo, la que no es exacta ni concreta, si no que usualmente es bastante abstracta. Los datos no son estticos, y corresponden a un mundo que esta en constante cambio. La flexibilidad en la interpretacin de los datos permite capturar los aspectos dinmicos del mundo y al mismo tiempo, proveer una estructura estable para los datos. Esta flexibilidad se puede tener de dos formas: El sistema puede permitir que los mismos datos sean vistos de diferente forma. Por ejemplo, diferentes aplicaciones pueden usar los mismos datos y dar su propia semntica. Diferentes datos pueden ser vistos de la misma forma. Por ejemplo, se quiere ver a los gerentes, secretarias y empleados slo como trabajadores de una organizacin, no importando su cargo. Aqu la interpretacin debe ser lo suficientemente abstracta para que diferentes vistas del mundo se vean de la misma forma 2.4 Entidades Consideremos un nmero de conjuntos cada uno orientado a un tipo particular de objetos. Estos conjuntos estn relacionados con Dominios (conjunto de valores de un mismo tipo. Se define como un conjunto, ya sea por extensin o comprensin). Si consideramos la relacin dada por el producto cartesiano de estos dominios, una interpretacin que se les da a cada una de estas tuplas es que cada una corresponde a una entidad particular. Ejemplo: (Juan , 70, 80, (Pedro , 90, 50, 50) 70)
Qu es una entidad? Cualquier cosa de relevancia para el negocio acerca de la cual debe mantenerse informacin. Algo con existencia real o conceptual Algo a lo que se le da nombre Cualquier cosa que se puede identificar claramente Un objeto que existe y es distinguible entre otros objetos
Versin 3.0
22
Bases de Datos I
INACAP Cmo se identifican Entidades?
A partir de la descripcin del negocio, buscando sustantivos de usos comn en el negocio, buscando sinnimos, que representen conceptos generalizables.
2.5 Atributos Elemento de un dominio. Aporta mediante su rtulo, la semntica de los valores del dominio al que est asociado.
Dominio
ATRIBUTO
2.6
Tipos de relaciones. Uno a Uno: Relaciones uno a uno (1:1). Una entidad A est asociada a lo ms con una entidad B, y una entidad B a lo ms con una entidad A. Ejemplo: Ser jefe de es una relacin uno a uno entre las entidades empleado y departamento. Uno a Muchos: Relaciones Uno a Muchos (1 : n). Una entidad A est asociada con una o varias entidades B. Una entidad B, sin embargo, puede estar a lo ms asociada con una entidad A. Ejemplo: Ser profesor es una relacin 1: n entre profesor y curso, suponiendo que un curso slo lo dicta un profesor. Muchos a muchos Relaciones Muchos a Muchos (n : m). Una entidad A est asociada con una o varias entidades B, y una entidad B est asociada con una o varias entidades B, y una entidad B est asociada con una o varias entidades A. Ejemplo: Estar inscrito es una relacin n : m entre las entidades alumno y curso
Versin 3.0
23
Bases de Datos I
INACAP
Unidad 3: Modelos de Datos.

Es aparente que una representacin del mundo es necesaria, la que debe ser suficientemente abstracta para que no sea afectada por la dinmica del mundo (los pequeos cambios), y debe ser suficientemente robusta para poder representar como los datos y el mundo se relacionan. Una herramienta como esta es llamada Modelo de Datos, el cual permite representar en forma ms o menos razonable alguna realidad. El modelo de datos permite realizar abstracciones del mundo, permitiendo centrarse en los aspectos macros, sin preocuparse de las particularidades; as nuestra preocupacin se centra en generar un esquema de representacin, y no en los valores de los datos. Los modelos de datos nos permiten capturar parcialmente el mundo, ya que es improbable generar un modelo que lo capture totalmente. Sin embargo se puede tener un conocimiento relativamente completo de la parte del mundo que nos interesa. As un modelo captura la cantidad de conocimiento tal que cumpla con los requerimientos que nos hemos impuesto previamente. Un Modelo de Datos define las reglas por las cuales los datos son estructurados. Esta estructuracin sin embargo, no da a una interpretacin completa acerca de los significados de los datos y la forma en que sern usados. Las operaciones que se permiten efectuar a los datos deben ser definidos.. 3.1 Niveles de Abstraccin de los datos La mayora de las aplicaciones son dependientes de los datos; la organizacin del almacenamiento y los modos de acceso dependen de los requerimientos de la aplicacin y el conocimiento de la organizacin fsica de los datos y las tcnicas de acceso forman parte de la lgica de la aplicacin. La aplicacin es dependiente de los datos, porque no se puede mejorar la estructura de almacenamiento o los modos de acceso sin afectar la aplicacin. En los sistemas de bases de datos se plantean los siguientes objetivos: 1. Independencia de la base de datos de los programas para su utilizacin. 2. Proporcionar a los usuarios una visin abstracta de los datos. El sistema esconde los detalles de almacenamiento fsico (como se almacenan y se mantienen los datos) pero estos deben extraerse eficientemente. Independencia de los datos: La independencia de los datos es la capacidad de un sistema para permitir que las referencias a los datos almacenados, especialmente en los programas y en sus descriptores de los datos, estn aislados de los cambios y de los diferentes usos en el entorno de los datos, como pueden ser la forma de almacenar dichos
Versin 3.0
24
Bases de Datos I
INACAP
datos, el modo de compartirlos con otros programas y como se reorganizan para mejorar el rendimiento del sistema de bases de datos. Para conseguir esta independencia entre los datos y las aplicaciones es necesario separar la representacin fsica y lgica de los datos, distincin que fue reconocida oficialmente en 1978, cuando el comit ANSI/X3/SPARC propuso un esqueleto generalizado para sistemas de bases de datos. Este esqueleto propone una arquitectura de tres niveles, los tres niveles de abstraccin bajo los que podra verse una base de datos: el nivel interno, el nivel conceptual y el nivel externo.
NE 1 NE 2 NE 3 N IV E L E X T E R N O
N IV E L CO NCEPTUAL
N IV E L IN T E R N O
Los tres niveles de la arquitectura ANSI/X3/SPARC Los tres niveles de la arquitectura ANSI/X3/SPARC
Nivel Interno: En el se define la estructura fsica de la base de datos: dispositivos de almacenamiento fsico, direcciones fsicas, estrategias de acceso, relaciones, ndices, apuntadores, etc. Es responsabilidad de los diseadores de la base de datos fsica. Ningn usuario, en calidad de tal, tiene conocimiento de este nivel. Nivel Conceptual: Contiene el nivel conceptual de la base de datos, que implica el anlisis de las necesidades de informacin de los usuarios y las clases de datos necesarias para satisfacer dichas necesidades. El resultado del diseo conceptual contiene la descripcin de todos los datos y las interrelaciones entre ellos, as como las restricciones de integridad y de confidencialidad.
Versin 3.0
25
Bases de Datos I
INACAP
Nivel Externo: Visin que de la base de datos tiene un usuario o aplicacin en particular. Habr tantas vistas de la base de datos como exijan las diferentes aplicaciones. La vistas se derivan directamente del esquema conceptual, o de otras vistas, y con tienen una descripcin de los elementos de datos y sus interrelaciones orientadas al usuario o aplicacin y de las que se compone la vista. Una misma vista puede ser utilizada por varias aplicaciones.
Esta arquitectura de tres niveles nos proporciona la deseada independencia, que definiremos como capacidad para cambiar el esquema en un nivel sin tener que cambiarlo en ningn otro nivel. Distinguimos entre independencia fsica y lgica: Independencia lgica de los datos: Cambio del esquema conceptual sin cambiar las vistas externas o las aplicaciones. Independencia fsica de los datos: Cambio del esquema interno sin necesidad de cambiar el esquema conceptual o los esquemas externos.
3.2 Semntica de los datos. La semntica de los datos es el significado asociado al lenguaje (por ejemplo, el significado de las palabras y su interpretacin dentro de un contexto dado). 3.3 Cardinalidad La Cardinalidad de un objeto o entidad es el nmero de ocurrencias del objeto, entendindose por ocurrencia de una entidad o instancia de un objeto, al producto de asociar valores a los atributos de la entidad u objeto. 3.4 Grado Se denomina grado, a la cantidad de atributos que se consideran para una entidad u objeto. 3.5 Dependencia Igual que para los tipos de entidad, los tipos de interrelacin pueden ser regulares o fuertes y dbiles, segn se asocien dos entidades fuertes o una fuerte y una dbil, respectivamente. En los tipos de interrelacin dbil no pueden existir si desaparecen en existencia y la dependencia en identificacin.
Versin 3.0
26
Bases de Datos I
INACAP
Dependencia en existencia: Cuando la ocurrencia en un tipo de entidad dbil no puede existir si desaparece la ocurrencia de la entidad fuerte de la que depende. Dependencia en Identificacin: Cuando, adems de ser una dependencia en existencia las ocurrencias de la entidad dbil no pueden identificarse nicamente mediante los atributos propios de la misma. 3.8 Clase Una clase es un objeto que permite instanciar objetos. 3.9 Agregacin Es una correspondencia que se establece entre dos clases. 3.10 Modelos de Datos dependientes de la tecnologa. La forma o vista externa con que se presentan los datos al usuario en la mayora de los sistemas actuales es idntica o muy semejante a la vista conceptual. La estructura lgica, a nivel contextual o externo, es la base para la clasificacin de los DBMS en las tres categoras siguientes: Jerrquica , Red y Relacional. Cualquier categora del DBMS debe permitir un acceso aleatorio a los datos requeridos, utilizando para tal fin una de las siguientes estructuras lgicas para almacenar los datos: redes, rboles, tablas o listas enlazadas. Cada DBMS esta diseado para manejar un tipo determinado de estructura lgica. Los programas que se ejecutan bajo un DBMS no se pueden procesar en otro DBMS. Los DBMS ms conocidos, disponibles en el Mercado en funcin de su categora, son: Enfoque Jerrquico: El IMS de IBM y el SYSTEM 2000 de Intel. Enfoque de Red: Los ejemplos ms importantes los proporciona las especificaciones del grupo de trabajo de base de datos (DBTG) de CODASYL. Enfoque Relacional: System R y QBE de IBM, MAGNUM de Tymshare, ORACLE y otros.
Versin 3.0
27
Bases de Datos I
INACAP Enfoque Jerrquico
Un DBMS de enfoque jerrquico utiliza RBOLES para la representacin lgica de los datos.
A los archivos que entre sus registros guardan una relacin tipo rbol se les llama Archivos Jerrquicos.
La figura siguiente muestra una estructura en rbol con 4 tipos de registros: SUCURSAL AUTOMOVIL EMPLEADOS FECHA-MANTENIMIENTO Que representan las sucursales filiales de una empresa, los automviles asignados a cada una de ellas, los empleados que deben conducir un determinado coche y la fecha de mantenimiento. El registro SUCURSAL contiene los campos NUMERO-SUCURSAL, NOMBRE-SUCURSAL, NOMBRECIUDAD, etc.; el registro AUTOMOVIL incluye los datos de los coches; el registro EMPLEADO, los datos personales del mismo: NUMERO, NONBRE, etc. y, por ltimo el registro FECHA-MANTENIMIENTO contiene los campos FECHA, OPERACIN. Ver figura Anexa.
Versin 3.0
28
Bases de Datos I
INACAP SUCURSAL
AUTOMOVIL
EMPLEADO a) Estructura lgica con cuatro tipos de registros
FECHA - MANTENIMIENTO
SUCURSAL
AUTO 1
AUTO 2
AUTO 3
AUTO 4
EMPLEADO 1
EMPLEADO 2
EMPLEADO 4
EMPLEADO 2
EMPLEADO 3
b) Ejemplo de la base de datos jerrquica de la estructura a
Archivo jerrquico con cuatro tipos de registros
Versin 3.0
29
Bases de Datos I
INACAP Terminologa para describir los rboles
El anexo siguiente muestra un rbol compuesto por una jerarqua de elementos llamados nodos. Los rboles se dibujan con la raz arriba y las hojas abajo
Nivel 1: Raz
A
Nivel 2
B C D
Nivel 3
E F G
Estructura de un rbol
La terminologa para describir los nodos de un rbol es la siguiente: Raz : es el nodo ms alto de la jerarqua ( nodo A) Padre : Es el nodo al que se haya vinculado otros de nivel inferior. EL padre de B es A. Gemelos : Nodos con el mismo padre Ej: B, C y D. Hijos : Son los nodos vinculados con otros del nivel superior los hijos de B son E, F, G. Hojas : Reciben este nombre los nodos que no tienen hijos. (C, H )
Versin 3.0
30
Bases de Datos I
INACAP El Enfoque de Red
Una estructura de datos en RED, tambin llamada estructura PLEX, se caracteriza porque cada nodo hijo puede tener ms de un padre, a diferencia de la estructura en rbol en la que un hijo slo poda tener un padre.
D E G H I
Estructura de red
El nodo C tiene dos padres A y B. Lo mismo sucede con en nodo H cuyos padres son D Y E
Versin 3.0
31
Bases de Datos I
INACAP
3.11 Modelos de Datos Independientes de la tecnologa. Objetivos del diseo En los temas anteriores se han estudiado las arquitecturas de los distintos DBMS, as como los lenguajes para el manejo de los datos. Pero todava no se ha considerado un aspecto fundamental de las bases de datos, como es su diseo. Por diseo se entiende el generar un conjunto de esquemas de relaciones que permitan almacenar la informacin con un mnimo de redundancia pero al mismo tiempo faciliten su recuperacin. Entre los distintos objetivos en el diseo de una base de datos se pueden considerar: 1. La base de datos resultante tiene que ser capaz de almacenar toda la informacin necesaria. El primer paso ser determinar los atributos que van a formar parte de la base de datos y reunirlos en una relacin universal. Hasta que se hayan concretado los campos necesarios no podr el diseador establecer las relaciones entre ellos. 2. Eliminacin de la informacin redundante siempre que sea posible. 3. Mantener el nmero de relaciones al mnimo entre los componentes de la base de datos con el fin de facilitar su programacin o uso por parte del usuario. 4. Las relaciones obtenidas deben estar normalizadas con el fin de minimizar los problemas de actualizacin y borrado. Orientado a Objeto El Modelo Orientado a Objetos se basa en el paradigma de programacin orientada a objetos. Este paradigma ha tenido gran aceptacin debido a que es de gran naturalidad buscar objetos en la realidad a modelar. Estructura de objetos. El Modelo orientado a objetos se basa en encapsular cdigo y datos en una nica unidad llamada objeto. La Interfaz entre un objeto y el resto del sistema se define mediante un conjunto de mensajes. El motivo de este enfoque puede ilustrase considerando una base de datos de documentos en la que los documentos se preparan usando uno entre varios paquetes software con formateador de texto. Para imprimir un documento debe ejecutarse el formateador correcto en el documento. Bajo un enfoque orientado a objetos cada documento es un objeto que contiene el texto de un documento y el cdigo que opera sobre el objeto.
Versin 3.0
32
Bases de Datos I
INACAP
Todos los objetos del tipo documento responden al mensaje imprimir, pero lo hacen de forma diferente. Cada documento responde ejecutando el cdigo formateador adecuado. Encapsulando dentro del objeto documento la informacin acerca de cmo imprimirlo, podemos tener todos los documentos con la misma interfaz externa al usuario ( aplicacin). En General un objeto tiene asociado: Un conjunto de atributos que contienen datos acerca del objeto. A su vez, cada valor de un atributo es un objeto. Un conjunto de mensajes a los que responde. Un conjunto (puede ser unitario) de mtodos, que es un procedimiento o trozo de cdigo para implementar la respuesta a cada mensaje. Un mtodo devuelve el valor (otro objeto) como respuesta al mensaje.
Puesto que la nica interfaz externa de un objeto es el conjunto de mensajes al que responde, es posible modificar la definicin de mtodos y atributos sin afectar a otros objetos. Tambin es posible sustituir un atributo por un mtodo que calcule un valor. Ejemplo: Un objeto documento puede contener un atributo de tamao que contenga el nmero bytes de texto en el documento, o bien un mtodo de tamao que calcule el tamao del documento leyndolo y contando el nmero de bytes. La capacidad de modificar la definicin de un objeto sin afectar al resto del sistema est considerada como una de las mayores ventajas del modelo de programacin orientada a objetos. Entidad - Relacin En 1976, Peter Chen public el modelo entidad relacin, el cual tuvo gran aceptacin principalmente por su expresividad grfica. Sobre esta primera versin han trabajado numerosos autores, generando distintas extensiones de mayor a menor utilidad y de aceptacin variable en el medio acadmico y profesional. Muchas de estas extensiones son muy tiles, pero poco difundidas debido principalmente ala ausencia de herramientas automatizadas que apoyen su uso. Cmo modelar en MER (Modelo Entidad Relacin)? Para modelar en MER se sigue generalmente el siguiente orden: 1. Identificar los tipos de entidades 2. Identificar los tipos de Interrelaciones 3. Encontrar las cardinalidades
Versin 3.0
33
Bases de Datos I
INACAP
4. Identificar los atributos de cada entidad 5. Identificar las claves de cada tipo de entidad La regla bsica es distinguir tipos de entidades e interrelaciones de atributos. As, los atributos deben ser atmicos y caractersticos del tipo entidad o interrelacin que describan. Tambin los atributos deben pertenecer al tipo de entidad o interrelacin describen y no a otro tipo. que
Otra diferencia entre tipo entidad y atributo es que, por ejemplo, se puede tener el tipo de entidad empleado, que tiene como atributo el departamento al que pertenece. En Forma alternativa se pueden tener los tipos de entidades Empleado y Departamento, y el tipo de interrelacin trabaja_en, que relaciona a un empleado con el departamento en donde trabaja. Esta segunda alternativa es mejor desde el punto de vista del modelamiento conceptual y presenta una clara diferencia entre atributo y tipos de entidad. Reglas para elegir identificadores 1. No deben existir dos entidades con el mismo valor del identificador (en los tipos de entidad). 2. En los tipos de interrelacin, la clave es la composicin de las claves de los tipos de entidad involucrados, en caso que no se pueda utilizar la clave de un subconjunto de ellos. Ejercicios Propuestos: 1. Construir un esquema MER para una secretaria de universidad. La secretaria mantiene datos sobre cada asignatura, incluyendo el profesor, lista de alumnos y la hora y el lugar de las clases. Para cada par estudiante asignatura se registra su nota. 2. Construir un esquema MER para una compaa de seguros de autos con un conjunto de clientes, cada uno de los cuales es propietario de un nmero de autos. Cada auto tiene asociado el nmero de accidentes asociados. 3. Construir un esquema MER para modelar la documentacin requerida para un esquema conceptual E R.
Versin 3.0
34
Bases de Datos I
INACAP 3.12 Normalizacin
Se entiende por normalizacin la descomposicin o subdivisin de una relacin en dos o ms relaciones para evitar la redundancia; en definitiva, que cada hecho est en su lugar. El proceso de normalizacin generalmente se utiliza en el enfoque relacional; sin embargo, un modelo relacional se puede modificar para su implantacin en un DBMS jerrquico o de red. La relacin universal Supongamos que se desea implantar en una base de datos las ventas de una determinada empresa a sus clientes por la relacin ORDENES-VENTA (NCLI, NOMBRE, LOCALIDAD, CT, NART, ARTICULO, CANT, PVP, FECHA), donde NCLI es el nmero del cliente, CT es el costo de transporte y NART el nmero de artculo. La implantacin, tal como indica la Figura 1, no se puede realizar debido a la gran cantidad de informacin redundante y los problemas que surgen a la hora de las actualizaciones. Relacin ORDENES-VENTA NCLI 11 11 11 44 55 NOMBRE Luis Luis Luis Ana Jos LOCALIDAD Mlaga Mlaga Mlaga Gijn Valencia CT 0.8 0.8 0.8 1.1 1.4 NART A1 A3 A9 A1 A4 ARTICULO Papel Cinta Disco Papel Grapas CANT 100 50 25 100 30 PVP 5 500 200 5 50 FECHA 3/5 5/5 7/5 10/5 3/5
Figura 1. Informacin deseada para las ORDENES-VENTA DEPENDENCIA FUNCIONAL: DF La normalizacin se basa en la dependencia funcional. El concepto de dependencia funcional se tom de las matemticas. [Y = f(X)], Y es funcin de X si el valor de Y est siempre determinado por el valor de X. La dependencia funcional (DF) se define: Dados dos atributos A y B de una relacin R se dice que B es funcionalmente dependiente del atributo A si para cada valor de A existe un valor de B, y slo uno, asociado con l. En otros trminos: si en cualquier instante, conocido el valor de A, podemos conocer el valor de B. Se simboliza por: A Versin 3.0 35 B Bases de Datos I
INACAP
Tanto A como B pueden ser un conjunto de atributos en lugar de atributos simples. La dependencia funcional establece condiciones entre atributos pertenecientes a la misma relacin. No permite establecer condiciones entre atributos pertenecientes a la misma relacin. No permite establecer condiciones entre atributos de diferentes relaciones. Las DF se determinan al estudiar las propiedades de todos los atributos de la relacin y deducir cmo estn relacionados los atributos entre s. La dependencia funcional est ntimamente ligada con el concepto de clave. Para el diseo, las claves aparecen subrayadas. Se pueden distinguir los siguientes tipos de claves: Clave candidata: Conjunto de uno o ms atributos que podra ser utilizado como clave principal de una relacin. Superclave: Conjunto de uno o ms atributos que, juntos, permiten identificar de forma nica a una entidad dentro de una relacin. Clave principal: Es una clave candidata en la que ningn componente puede tomar el valor nulo. Para encontrar la clave candidata es preciso estudiar las dependencias funcionales y, a partir de ellas, obtener el mnimo conjunto posible de atributos tales que, una vez conocidos sus valores en la tupla, los dems queden definidos Consideremos la relacin CLIENTES: NCLI, NOMBRE, LOCALIDAD, donde NCLI es el nmero del cliente. Los campos NOMBRE y LOCALIDAD son funcionalmente dependientes de NCLI: Para un valor de NCLI existe un nico valor de NOMBRE y LOCALIDAD. Se expresa: NCLI NCLI En forma abreviada: NCLI NOMBRE LOCALIDAD (NOMBRE, LOCALIDAD)
La proposicin NCLI NOMBRE se lee: el atributo NOMBRE es funcionalmente dependiente del atributo NCLI, o tambin: el atributo NCLI determina funcionalmente al atributo NOMBRE. La proposicin NCLI (NOMBRE, LOCALIDAD) se puede leer: el atributo compuesto formado por NOMBRE y LOCALIDAD es funcionalmente dependiente de NCLI. El atributo NCLI es un determinante de los atributos NOMBRE y LOCALIDAD. Dicho de otra forma: por cada NCLI slo puede haber un NOMBRE y una
Versin 3.0
36
Bases de Datos I
INACAP
LOCALIDAD asociados a l. NCLI es una superclave. Sin embargo, el NOMBRE no es un determinante de la LOCALIDAD, ya que puede haber varias personas con igual nombre en ciudades diferentes o en la misma ciudad. Determinante: Si A B es una DF y B no es funcionalmente dependiente de A
se dice que A es el determinante de B.

Un determinante son todos los atributos situados en el lado izquierdo de una DF.
Es conveniente representar las DF de una relacin en un diagrama de dependencia funcional; en el ejemplo anterior: NOMBRE NOMBRE o LOCALIDAD LOCALIDAD
NCLI
NCLI
El diagrama de dependencia funcional para la relacin ORDENES-VENTA se muestra en la Figura 2. Se aprecia que el atributo CANT es totalmente dependiente de los atributos NCLI, NART y FECHA, lo que da lugar a la aparicin de un nuevo concepto: dependencia funcional total. Dependencia funcional total: En una relacin R, un atributo o coleccin de atributos B tiene una dependencia funcional total de otra coleccin de atributos A de la relacin R, si B es funcionalmente dependiente de todos los atributos de A pero no de un subconjunto de A.
NCLI CANT NART FECHA
NOMBRE, LOCALIDAD, CT ARTICULO, PVP
Figura 2 Diagrama de dependencia funcional
Versin 3.0
37
Bases de Datos I
INACAP PRIMERA FORMA: 1FN
Una relacin est en primera forma normal si todo atributo contiene un valor indivisible, atmico. Esta forma normal est justificada por la sencillez y la esttica en la representacin de los registros (Fig. 1). NCLI 11 NOMBRE Luis LOCALIDAD Mlaga CT 0.8 NART A1 ARTICULO Papel CANT 100 50 PVP FECHA 5 5 3/5 5/5
se puede normalizar con la creacin de un registro nuevo por cada uno de los distintos valores de un campo, tal que permita expresar la relacin como una tabla NCLI 11 11 NOMBRE Luis Luis LOCALIDAD Mlaga Mlaga CT 0.8 0.8 NART A1 A3 ARTICULO Papel Cinta CANT 100 50 PVP FECHA 5 500 3/5 5/5
Una relacin en 1FN contiene una serie de anomalas de almacenamiento a la hora de realizar las actualizaciones por la informacin redundante, como se puede apreciar en la Figura 1. NORMALIZACIN DE LA RELACIN 1FN Las anomalas de almacenamiento, que se deben a la presencia de campos no clave en la relacin, se pueden subsanar de la siguiente forma: a) Dividiendo la relacin universal en nuevas relaciones. b) Cada relacin tiene la propiedad de que su clave, en su totalidad, es necesaria para definir cada uno de los campos no clave. Al proceso de dividir cualquier relacin en dos o ms relaciones se llama proceso de normalizacin. Consiste en reemplazar las relaciones por proyecciones adecuadas, de tal forma que la reunin natural de las proyecciones genere la relacin original, es decir, que no se produzca prdida de la informacin. Incluso las nuevas relaciones pueden contener informacin que no se poda representar originalmente (un nuevo registro en alguna de las nuevas relaciones), pero siempre conservando las dependencias funcionales.
Versin 3.0
38
Bases de Datos I
INACAP
Descomposicin sin prdida. Descomposicin de una relacin R en R1, R2, ... RN, tal que: R = R1 * R2 * ... * RN. Cuando se actualiza la base de datos, el sistema debe poder comprobar que la actualizacin no va a generar una relacin ilegal, es decir, una que no satisfaga todas las DF establecidas. Para llevar a cabo el proceso de normalizacin es aconsejable dar los siguientes pasos: 1. Elegir una clave primaria que puede representar de forma nica a cada registro de la relacin. 2. Construir un diagrama de dependencia en funcin de esas claves. 3. Construir las nuevas relaciones basndose en dichas claves. Por el paso 1, en la relacin ORDENES-VENTA, los atributos que forman la clave primaria son: NCLI, NART, FECHA.
Versin 3.0
39
Bases de Datos I
INACAP
Los diagramas y las nuevas relaciones aparecen descritas en la figura siguiente.
Relacin Clientes Relacin Artculos Relacin Ventas
NCLI NART NCLI NART FECHA
Nombre, Localidad, Artculo, PVP CANT
CT
a) Diagramas de dependencias funcionales Relacin CLIENTES NCLI 11 44 55 NOMBRE Luis Ana Jos LOCALIDAD CT Mlaga Gijn Valencia 0.8 1.1 1.4 Relacin VENTAS PVP 5 500 50 200 NCLI 11 11 11 44 55 NART A1 A3 A9 A1 A4 CANT 100 50 25 130 30 FECHA 3/5 5/5 7/5 10/5 3/5
Relacin ARTICULOS NART A1 A3 A4 A9 ARTICULO Papel Cinta Grapas Disco
b)Registros de las relaciones
RELACION 1FN NORMALIZADA
Versin 3.0
40
Bases de Datos I
INACAP SEGUNDA FORMA NORMAL: 2FN Una relacin est en segunda forma normal s, y slo s:
1. Est en 1FN 2. Todo atributo que no pertenezca a la clave debe depender de la clave en su totalidad y no slo de una parte; debe tener una dependencia funcional total. Las relaciones mostradas en la Figura siguiente pertenecen ya a la 2FN. Sin embargo, la relacin CLIENTES presenta anomalas de almacenamiento debido a que el atributo CT es funcionalmente dependiente de LOCALIDAD, que a su vez depende de NCLI; es decir, hay una dependencia transitiva que ocasiona problemas a la hora de las actualizaciones. Por ejemplo, no se puede insertar un CT para una localidad determinada hasta que haya un cliente para dicha localidad. Dependencia transitiva Supongamos la relacin R(A,B,C). Si A B B, B C y
A ; entonces se dice que C depende transitivamente de A y se
puede formar la cadena
A B C. En un diagrama de dependencia funcional, C es transitivamente dependiente de A si se tiene la siguiente situacin:
Relacin R
B, C
Se puede descomponer en dos relaciones por la proyeccin del ltimo eslabn de la forma; Relacin R1 Relacin R2 A A B C
Normalizacin de la relacin 2FN Las anomalas de almacenamiento, originadas por la dependencia transitiva en una relacin 2FN, se puede normalizar mediante los siguientes pasos: 1. En una relacin, determinar el atributo que es funcionalmente dependiente de un atributo funcional. 41 Versin 3.0 no clave y dibujar el diagrama de dependencia Bases de Datos I
INACAP
2. Crear una nueva relacin para almacenar el atributo no clave y su determinante El diagrama de dependencia funcional y las relaciones CLIENTES y TRANSPORTE se muestran en la figura 13.4. Han desaparecido las anomalas surgidas por la dependencia transitiva, como se puede comprobar al dar de alta un nuevo registro en la relacin TRANSPORTE, aunque no haya ningn cliente de esa ciudad.
Relacin Clientes Relacin Transportes Relacin Artculos NART Relacin Ventas
NCLI
Nombre, Localidad LOCALIDAD Artculo, PVP CT
NCLI NART FECHA
CANT
a) Diagramas de dependencias funcionales Relacin CLIENTES NCLI 11 44 55 Relacin TRANSPORTES LOCALIDAD Mlaga Gijn Valencia CT 0.8 1.1 1.4 NOMBRE Luis Ana Jos LOCALIDAD Mlaga Gijn Valencia
b) Registros de las relaciones CLIENTES Y TRANSPORTES RELACION 2FN NORMALIZADA Versin 3.0 42 Bases de Datos I
INACAP
TERCERA FORMA NORMAL: 3FN Una relacin est en 3FN s, y slo s: 1. Est en 2FN 2. Todo atributo que no pertenezca a la clave no depende de un atributo no clave. La 3FN elimina las redundancias ocasionadas por las dependencias transitivas. Las relaciones mostradas en la figura 13.4 pertenecen ya a la 3FN. En la 3FN se puede decir que en cada relacin no existe u atributo no clave que defina a otro atributo. Existe una excepcin: Cuando en una relacin hay dos atributos que podra ser la clave, como el DNI y l nmero de la seguridad social.
Unidad 4: Metodologa de Diseo de una Base de Datos.

Versin 3.0 4.1 Enfoque metodolgico 43 Bases de Datos I
INACAP
Todo proceso tiene entradas -recursos humanos, tecnolgicos, materiales y otros- para el desarrollo de las actividades que lo conforman; como salidas se esperan productos, servicios, informacin, activos financieros u otros. Si bien la distincin entre actividad y proceso no es ntida, por Bases de Datos I lo general un proceso es 44 Versin 3.0 visto como un conjunto de actividades o una macro actividad. Otra definicin, entiende todo proceso como un "conjunto de tareas lgicamente
INACAP
PROCESOS DE APOYO Gestin de recursos humanos Gestin de adquisiciones Gestin de recursos tecnolgicos Gestin de logstica de entrada Gestin de operaciones Gestin de logstica de salida Gestin de ventas Gestin de servicio PROCESOS PRINCIPALES Por tanto, los procesos principales seran los conjuntos de actividades vinculadas a la creacin, venta, transferencia y asistencia posterior de productos o servicios; mientras que los de apoyo seran todos aquellos conjuntos de actividades que sustentan las actividades involucradas en los procesos principales proporcionndoles insumos, tecnologas, recursos humanos y variadas funciones administrativas. Modelo de Procesos por Regulacin Uno de los modelos para representar los conjuntos de actividades asociados a los procesos es el llamado Modelo de Procesos por Regulacin (MPR). El modelo asume que el propsito de todo sistema de gestin es el de regular el comportamiento de los recursos que manejan las organizaciones ante perturbaciones generadas por un entorno cambiante y
Versin 3.0
45
Bases de Datos I
INACAP
no controlable. Los recursos regulados son ingresados desde el entorno hacia la organizacin, para ser "operados" o "transformados" en su interior y devueltos al exterior. Bajo este modelo es crucial identificar los recursos que interesan regular, que pueden ser recursos materiales, humanos u otros. A modo de ejemplo, para la organizacin de una conferencia de informtica, un recurso que interesar regular seran los trabajos que se presenten. Con propsitos de "regulacin" interesar informacin ms all del contenido del "trabajo"
Las operaciones o actividades que se ejecutan sobre los recursos son las que estn sometidas a regulacin. Por tanto, a nivel de actividades suelen distinguirse aquellas que producen bienes / servicios (actividades fsicas) de las actividades que las regulan (actividades administrativas). Lo anterior implica que a nivel de los flujos existen los fsicos y los de informacin. Los flujos fsicos son aquellos asociados a los recursos que se aspira regular a travs de los flujos de informacin. Ejemplos de flujos fsicos pueden ser flujos de materiales, de dinero, de personas, de documentos, etc. Las actividades que tienen como entrada los flujos fsicos modifican el estado de los recursos involucrados para dar origen a productos / servicios. Las actividades administrativas que regulan estos flujos, lo realizan a travs de procesamientos, procedimientos, monitoreo, coordinacin, toma de decisiones, direccin y control de los flujos fsicos. Los objetos del entorno son todas aquellas unidades organizacionales o personas que originan o reciben los flujos fsicos de entrada / salida, en tanto que lo sistemas externos son aquellos con los cuales s interacta y que inciden en la toma de decisiones. La siguiente figura presenta la estructura bsica de un ciclo clsico de regulacin, observndose que las actividades administrativas pueden descomponerse en las orientadas a registrar los cambios de estado que experimenta el recurso regulado, y aquellas orientadas a tomar decisiones que impliquen acciones sobre las actividades fsicas llevadas a cabo Versin 3.0 46 Bases de Datos I
INACAP
Sistemas de Informacin Se entender por sistema de informacin al conjunto de componentes interrelacionados que operan conjuntamente para capturar, procesar, almacenar y distribuir informacin que apoye la toma de decisiones, la coordinacin, el control y anlisis en una organizacin. Segn el nivel organizacional al cual los sistemas satisfacen y su valor para la organizacin, los tipos de sistemas que interesarn son:

de Procesamiento de Transacciones (SPT): registran las transacciones rutinarias del negocio y que sirven para el nivel operacional de las organizaciones. de Apoyo a las Decisiones (SAD): estn a nivel de gestin de las organizaciones, y combinan datos y modelos analticos sofisticados para apoyar el proceso de decisin. de Informacin Administrativos o de Gestin (SIA o SIG): estn a nivel de gestin de las organizaciones, y apoyan las funciones de planificacin y control para proveer informes de resumen y de excepcin; dependen de datos proporcionados por los SPT. de Apoyo Ejecutivos (SAE): estn a nivel estratgico de la organizacin diseados para apoyar las decisiones no estructuradas y crear un entorno generalizado de automatizacin y comunicaciones de redes; son sistemas que incorporan informacin de eventos externos, tales como polticas impositivas, comportamientos de la competencia.
Versin 3.0
47
Bases de Datos I
INACAP
Metodologa Para estructurar un sistema de informacin orientado a satisfacer requerimientos estratgicos de las organizaciones se desarroll una metodologa, apoyada en el modelamiento de procesos por regulacin, que consta de las siguientes etapas: Etapa 1: Identificacin de procesos Utilizando la cadena de valor planteada por Porter se identifican los procesos ms relevantes dentro de una organizacin, diferenciando los principales y los de apoyo. En esta etapa se deben tomar en consideracin la misin y los objetivos estratgicos fijados en la organizacin. Etapa 2: Seleccin de procesos Cumplido lo anterior se seleccionan aquellos en los que interesa focalizar los esfuerzos y recursos disponibles. Entre las herramientas de apoyo utilizadas en esta fase se encuentran el anlisis FODA (Fortalezas/Oportunidades/Debilidades/Amenazas) y los FCE (Factores Crticos de xito). Etapa 3: Descomposicin de procesos A continuacin se identifican los recursos a regular, los subprocesos fsicos que afectarn al recurso involucrado, y los administrativos o de gestin que regularn el comportamiento de los subprocesos fsicos. Etapa 4: Estructuracin del sistema de informacin Cada uno de los subprocesos administrativos da origen a tres subsistemas de informacin: de procesamiento de transacciones, de informacin administrativa, y de apoyo a las decisiones. El primero captura las transacciones que den cuenta de los cambios de estado del recurso que se est regulando; el segundo apoya las funciones de planificacin y control; el tercero apoya el proceso de toma de decisiones. Sobre la totalidad de estos subsistemas se implementa el sistema de apoyo ejecutivo con propsitos de coordinacin e interaccin con los anteriores y con el medio externo. Este enfoque metodolgico genera, para cada uno de los subprocesos identificados, sistemas de informacin orientados a los procesos con componentes a nivel operacional, tctico y estratgicos.
Versin 3.0
48
Bases de Datos I
INACAP 4.3. Obtencin del Modelo Corporativo
Una sola visin de la base de datos puede describirse mediante un modelo. Un modelo de visin representa un pequeo subconjunto de la realidad, apropiado para una aplicacin del contenido de la base de datos. La mayora de las bases de datos para especificarse requerirn varios modelos de visin. El estrecho enfoque de visin por visin para comprender la estructura de una base de datos tiene la ventaja de que la complejidad de los vnculos que se presentan en las bases de datos del mundo real puede dominarse. Cuando se ha establecido un conjunto comprensivo de modelos de visin, es posible establecer la construccin de un modelo para toda la base de datos. Se combinan relaciones provenientes de modelos separados de visin con base en los atributos que tengan en comn. Si los modelos de visin no tienen atributos en comn no se obtiene ningn beneficio al unir estos datos en un solo modelo de base de datos. Aunque haya atributos comunes podra no haber conexiones. La falta de conexiones indica que las visiones o los grupos de visiones pueden mantenerse independientemente unas de otras. A una base de datos creada a partir de visiones que no se conectan con otras bases de datos se les denomina base de datos independiente, esta se mantiene mejor en forma distribuida, an cuando el equipo de computacin sea compartido. Hay beneficios ( funcionales, geogrficos, desempeo, autonoma, confiabilidad, crecimiento) al efectuar distribucin, y si las bases de datos pueden conservarse ms pequeas y manejarse en forma autnoma, probablemente los costos totales sean ms bajos. Para permitir consultas de recuperacin con acceso a datos de mltiples bases de datos independientes suele forzarse a que bases de datos ms independientes queden en una base de datos integrada. Actualmente slo unos cuantos sistemas de manejo de base de datos permiten que se procesen consultas con acceso a ms de una base de datos. El costo de combinar bases de datos independientes consiste en un costo incrementado en demasa del sistema de base de datos, a fin de proporcionar la independencia requerida del modelo de visin y la proteccin para las transacciones de actualizacin. Los costos de manejo, debidos al intento de volver comunitarias reas en las que existen pocos incentivos naturales para cooperar, tambin pueden ser altos. Ni siquiera deben integrarse todos los modelos conectados de visin. El enlace entre algunos conjuntos de visiones puede ser relativamente dbil y no garantizar la integracin de un modelo de visin en la base de datos. Un enlace dbil puede deberse a un atributo compartido, pero que no cambia. En esos casos tambin se disearn bases de datos
Versin 3.0
49
Bases de Datos I
INACAP
independientes de datos, con un procedimiento para mantener sincronizado el atributo compartido. Por ejemplo, si los empleados estn identificados con un departamento, y la produccin de bienes con otro, la lista de departamentos podra proporcionar tal enlace relativamente constante. Slo si los empleados se relacionaran con la produccin habra un acoplamiento suficientemente fuerte entre las dos reas para justificar la combinacin de modelos de visin. La existencia de un atributo compartido que frecuentemente se actualice en dos modelos independientes de otro modo, proporciona otro incentivo para combinar los modelos y evitar as esfuerzos redundantes de actualizacin. Un ejemplo de base de datos centralizada se encuentra en los sistemas de reservaciones de lneas areas. Las relaciones bsicas que proporcionan la disponibilidad de asientos y los programas de vuelos tienen que compartirse por todos los usuarios y reciben frecuente acceso. En las compaas manufactureras a menudo resultan convenientes las bases de datos distribuidas. Puede existir gran actividad en una sola fbrica, pero que no resulte de inters para todos los que trabajen en ella. Datos generales de entrada y salida, en trminos de materiales, dinero y productos, describen la fbrica en forma adecuada desde un punto de vista externo. Las decisiones referentes a distribucin se basan principalmente en la experiencia y la intuicin. Hasta qu punto es ms conveniente la distribucin que la centralizacin?, depende del costo de manejo de operaciones, comunicaciones y procesamiento. Una base de datos distribuida no implica distribucin fsica sino ms bien una distribucin de responsabilidades a mltiples bases de datos. Un sistema disperso puede estar bien integrado o distribuido. El costo de las comunicaciones necesarias para un sistema integrado pero repartido en sitios remotos har posible un enfoque distribuido. Cada base de datos en el conjunto distribuido tendr sus conexiones internas y algunas con otros sitios. Las relaciones y conexiones disponibles pueden describirse mediante un submodelo de base de datos. Este puede representar una sola visin o aumentarse y modificarse para tener en cuenta informacin y datos provenientes de otras visiones incluidos en la base de datos. Un sitio tambin podra tener un modelo global integrado de todos los datos en las bases distribuidas de datos.
Versin 3.0
50
Bases de Datos I
INACAP
Si una base de datos que opera en un sitio tiene derecho de acceso a datos provenientes de bases ubicadas en otros puntos, puede convenir tener disponible una copia en cada sitio del modelo global de base de datos, an cuando en ese sitio slo se almacenen datos para el submodelo local de base de datos. La capacidad de cambiar localmente inclusive la parte local de un modelo de base de datos estar restringida ahora, ya que se vern afectados modelos remotos, aunque sus bases de datos no sean afectadas por el cambio de modelo. Un ejemplo se presenta en los bancos, donde durante las horas de negocios, las bases de datos primarias se encuentran en las sucursales (submodelos). Despus del cierre diario, la correspondencia de los datos locales con los datos de la oficina central (modelo global) se verifica y se da la responsabilidad primaria al sitio central. Durante la noche, la base de datos central puede actualizarse rpidamente con transacciones que llegan de otros bancos a la oficina central. Los mensajes de actualizacin se comunican a las sucursales. En la maana la responsabilidad pasa a las sucursales, despus de una verificacin de integridad. Se observa que la creacin de submodelos de bases de datos implica la existencia de un modelo integrado de bases de datos (modelo corporativo) aun cuando los datos puedan no estar integrados. En una base de datos distribuida puede existir un esquema global basado en el modelo integrado de base de datos que ayude a las consultas globales. Una vez que se ha decidido cules modelos de visin se incluirn en uno slo, es posible construir el modelo integrado de bases de datos, que consistir en relaciones de varios tipos y en las conexiones entre dichas relaciones. La combinacin puede tener el aspecto de un rbol, de cierto nmero de rboles (un bosque) o de una red. Cuando se est construyendo la base integrada de datos, deben tenerse en cuenta algunos objetivos: 1. 2. 3. 4. 5. 6. Obtener relaciones con el mayor grado de claridad semntica. Conservar la independencia de visin para simplificar la distribucin posterior. Tener el menor nmero de relaciones. Tener el menor nmero de tuplas. Hacer que el nmero de datos almacenados sea mnimo. Hacer que el nmero de conexiones entre relaciones y atributos compartidos sea mnimo. 7. Hacer que sea mnima la actividad a lo largo de todas las conexiones entre relaciones.
Versin 3.0
51
Bases de Datos I
INACAP
Se han estudiado reglas para establecer una situacin ptima de acuerdo con los ltimos cuatro criterios, utilizando dependencias funcionales entre atributos como elementos bsicos para la toma de decisiones. En muchos casos prcticos los diseos de bases de datos sustentados en cualquiera de los criterios no diferirn mucho. La claridad semntica aumenta cuando se agrupan aquellos atributos fuertemente relacionados, y esto puede lograrse con un nmero limitado de relaciones y conexiones de interrelacin. A menudo la normalizacin habr aumentado el nmero de tuplas y reducido el nmero de datos almacenados. La integracin puede reducir el nmero total de tuplas al combinarlas, pero normalmente aumenta el nmero total de relaciones y sus conexiones. El modelo integrado de base de datos puede ser complejo, pero presenta una descripcin precisa de las necesidades del usuario. Algunas veces es mejor adaptar el submodelo de base de datos a un subconjunto propio de la base integrada, ya que esto puede proporcionar una visin ms realista de la operacin y sus restricciones. Cuando los submodelos de base de datos son subconjuntos del modelo de base de datos, tal transformacin slo requiere seleccin y puede lograrse fcilmente.
4.4. Obtencin de las bases de datos requeridas por la organizacin Es posible construir sistemas de manejo de base de datos con una amplia gama de generalidad. Una clasificacin de estos enfoques en tres niveles distingue los sistemas que apoyan a una sola aplicacin, a varias aplicaciones del mismo tipo o a mltiples tipos de aplicaciones. Se han desarrollado algunos sistemas a travs de estos tres niveles; otros se han diseado para resolver problemas en un nivel especifico. Sistemas de bases de datos de una sola aplicacin Una organizacin establece una operacin de base de datos utilizando las facilidades disponibles de sistema de archivo y disea programas de aplicacin que realizan una interfase a la base de datos utilizando un paquete mantenido centralmente que implanta el grado necesario de descripcin de datos y de estructura. El sistema original de reservacin de la lnea area American Airlines, SABRE, muchos grandes sistemas de informacin, tales como MEDLARS (sistema para consultar informacin mdica) y sistemas de comando y control militar son ejemplos de este enfoque.
Versin 3.0
52
Bases de Datos I
INACAP
Sistemas de bases de datos para varias aplicaciones del mismo tipo. Un grupo de usuarios trabajando en cierto tipo de reas de aplicacin reconoce la existencia de necesidades comunes. Ellos o su vendedor de equipo electrnico disean un sistema que cubran sus necesidades. Las diferencias entre usuarios se incluyen en tablas y esquemas especficos para cada usuario. A menudo, este ltimo paso se realiza despus de obtener xito con un sistema orientado ms bien a un solo objetivo. Son ejemplos de este enfoque los sistema generalizados de reservacin de lneas areas (PARS), sistemas de informacin clnica (TOD, GEMS), y sistemas de facturacin de materiales (BOMP).
Sistemas de bases de datos de tipo de aplicacin mltiple. Un vendedor de equipo electrnico o un grupo acadmico disean un sistema con la intencin de que cubra las necesidades generales de la base de datos en una forma mejor. Desde luego, habr cierta tendencia a subrayar aquellos aspectos relacionados con la experiencia de los diseadores de manera que en la prctica se encuentra una gran diferencia entre los sistemas generalizados. Otra fuente para los sistemas generalizados es una evolucin continuada a partir de servicios para una sola aplicacin o del tipo de aplicacin. Una orientacin hacia una aplicacin especfica o a un tipo de aplicacin permite reconocer vnculos semnticos difciles de explotar en un sistema generalizado. Sin embargo, un sistema generalizado presenta un mejor equilibrio de los problemas en la implantacin de un sistema de base de datos.
4.5. Proceso de diseo de bases de datos La concepcin de una Base de Datos Relacional es una tarea larga y costosa. Existe la necesidad de contar con procedimientos ordenados que faciliten el desarrollo de un producto software, ya que esto tiene una incidencia en cuanto a costos y plazos de entrega, adems de la calidad y mantenimiento del producto. Segn Sommerville (1988) " un buen diseo es la clave de una eficiente ingeniera del software. Un software bien diseado es fcil de aplicar y mantener, adems de ser comprensible y fiable. Los sistemas mal diseados, aunque puedan funcionar, sern costosos de mantener, difciles de probar y poco fiables".
Versin 3.0
53
Bases de Datos I
INACAP
Muchas veces, el diseo de una base de datos se limita aplicar la teora de normalizacin, cuando en realidad debe abarcar muchas otras etapas, que van desde la concepcin hasta la instrumentacin. Una metodologa es un conjunto de modelos y herramientas que nos permiten pasar de una etapa a la siguiente en el proceso de diseo de la base de datos. Rolland y Benci (1988). En la determinacin de las fases de la metodologa debemos definir una jerarqua de niveles de abstraccin que resulte apropiada, en el sentido de ser lo suficientemente amplia para que a cada nivel le correspondan decisiones de diseo bien definidas, pero, a la vez, no proponer demasiados niveles, ya que sera muy sensible a la interpretacin del diseador. No existe una metodologa consagrada, sin embargo, ciertas etapas son distinguibles:
Diseo Conceptual, cuyo objetivo es obtener una buena representacin de los recursos de informacin de la empresa, con independencia de usuarios o aplicaciones en particular y fuera de consideraciones de eficiencia del computador. Diseo Lgico, cuyo objetivo es transformar el esquema conceptual obtenido en la etapa anterior, adaptndolo al modelo de datos en el que se apoya el SGBD que se va a utilizar (modelo relacional). Diseo Fsico, cuyo objetivo es conseguir una instrumentacin lo ms eficiente posible del esquema lgico.
Causas de malos diseos
Falta de conocimiento del dominio de la aplicacin, conocimiento que no posee el informtico, pero s el usuario (aunque no sepa estructurarlo ni expresarlo de forma precisa). Falta de experiencia en el modelado
Etapa 1: Diseo Conceptual Consiste de bsicamente 2 etapas:

Etapa de anlisis de requisitos Etapa de conceptualizacin
Versin 3.0
54
Bases de Datos I
INACAP
El anlisis de requisitos debe responder a la pregunta: qu representar? Para ello hay que estudiar las reglas de la empresa (del negocio) a los diferentes niveles de la organizacin, para elaborar una descripcin de la organizacin. Esquema percibido. Puede utilizarse el lenguaje natural. La segunda etapa responde a la pregunta Cmo representar?. Aqu se utilizan los modelos conceptuales. Nosotros utilizaremos el MER y sus extensiones, que bsicamente define entidades, atributos, interrelaciones y restricciones semnticas. Esquema conceptual. En el paso del esquema percibido al esquema conceptual. No existen reglas claras que permitan decidir que elemento es una entidad o cual otro una interrelacin. Existen 2 enfoques. Enfoque lingstico y categorizacin de objetos. En el enfoque lingstico:
un sustantivo (nombre comn) que acta como sujeto o complemento directo en un frase es por lo general un tipo de entidad, aunque podra ser un atributo. Ej.: los socios piden prestados libros, existen 2 posibles entidades: SOCIO y LIBRO. los nombres propios indican ocurrencias de un tipo de entidad, Ej: Date,C indica una ocurrencia de AUTOR. un verbo transitivo o una frase verbal es un tipo de interrelacin, Ej: pedir prestado indica una interrelacin entre las entidades LIBRO y SOCIO. una preposicin entre 2 nombres suele ser un tipo de interrelacin o tambin establece la asociacin entre una entidad y sus atributos. Ej: la institucin del autor, podemos pensar en la interrelacin entre AUTOR e INSTITUCION o bien, el atributo institucin de AUTOR.
En el enfoque de categorizacin de objetos (Navathe, 1983):
una entidad es un objeto de datos que tiene ms propiedades que su nombre o se utiliza como operando en una sentencia de seleccin, borrado o insercin. Ej: en la biblioteca existen libros que poseen una serie de propiedades, como son el ttulo, idioma, nro. de copias, etc. LIBRO es una entidad, ya que tiene varias propiedades. Ej: cuando un socio deja serlo, es preciso eliminarlo de la base de datos, SOCIO es una entidad, por ser un operando en una sentencia de borrado. un atributo es un objeto de datos al que se asigna un valor o se utiliza como operando en una operacin aritmtica, boolean, etc. Ej: se puede consultar si el ttulo de un libro es Bases de datos, luego, ttulo es un atributo.
Versin 3.0
55
Bases de Datos I
INACAP
Direccin rea Informtica una interrelacin es un objeto de datos que hace posible la seleccin de una entidad por medio de una referencia a un atributo de otra entidad. Ej: seleccionar los libros que ha escrito un determinado autor, por lo que escribir es una interrelacin, ya que nos permite seleccionar una entidad (LIBRO) por medio de una referencia a un atributo de otra entidad (Nombre de AUTOR).
Casos especiales: 1. "ES_UN" nos permite crear jerarquas de entidades, corresponde al concepto de generalizacin de Smith y Smith (1977). Ej: tanto un libro como un artculo son documentos
Los atributos de DOCUMENTO son heredados por ARTICULO y LIBRO. Tambin pueden haber atributos que son exclusivos de las entidades subtipos, por ejemplo, editorial podra ser un atributo de LIBRO pero no de ARTICULO. 2. TIENE, este verbo, posee muchas interpretaciones. Ocurrencia de, Ej.: un libro tiene varios ejemplares, en el sentido que un ejemplar es una ocurrencia de libro. Cual sera el identificador de la entidad, que es ocurrencia, (EJEMPLAR)???. Se forma con el identificador de la entidad principal (LIBRO) junto a un atributo discriminante de la ocurrencia. Ej: libros con 5 dgitos y 2 dgitos para los ejemplares. Interrelacin entre entidades Ej: los libros pueden tener ms de un autor, acta como interrelacin entre AUTOR y LIBRO. Asociacin de las entidades con sus atributos (agregacin) Ej: los libros tienen un ttulo, un ao de publicacin y un idioma, estamos asociando a la entidad LIBRO una serie de atributos. Algunas maas: Si decimos los socios piden prestados libros, estaramos generando un diagrama con entidades LIBRO, SOCIO, EJEMPLAR, e interrelaciones presta (LIBRO, SOCIO) y tiene (LIBRO,EJEMPLAR), lo que es incorrecto.
Versin 3.0
56
Bases de Datos I
INACAP
Debera ser, las mismas entidades, e interrelaciones tiene (LIBRO, EJEMPLAR) y presta (EJEMPLAR,SOCIO). En las jerarquas de supertipo y subtipos, los atributos deben definirse a un nivel adecuado, es decir, si tanto libros como artculos tienen titulo e idioma, estos atributos deben estar en DOCUMENTO.
Caractersticas del esquema conceptual La fase de modelacin conceptual cumple los siguientes objetivos:
Captar y almacenar el universo del discurso mediante una descripcin rigurosa, representando la informacin que describe a la organizacin y que es necesaria para su funcionamiento. Aislar la representacin de la informacin de los requisitos de la mquina y exigencias de cada usuario en particular. Independizar la definicin de la informacin de los SGBD en concreto.
Los esquemas conceptuales se caracterizan por:

Claridad, la significacin es no ambigua. Coherencia, sin contradicciones o confusiones Plenitud, representa lo esencial sin ser exhaustivo. Fidelidad, la representacin del universo del discurso ha de hacerse sin desviaciones ni deformaciones. Simplicidad, mxima sencillez (N reducido de componentes, conceptos separados, redundancia controlada).
Notar que desde un mismo universo del discurso se pueden obtener distintos esquemas conceptuales. El problema de la equivalencia entre DEI es importante. Algunos criterios de equivalencia son:

Compatibilidad de dominios de datos, los DEI representan el mismo UD Equivalencia de dependencias de datos, representan las mismas restricciones. Equivalencia de ocurrencias de datos
Existen ciertas restricciones de tipo semnticas que no son posibles de describir a travs de tpicamente el MER extendido. Muchas de estas se escriben en lenguaje natural dentro del mismo DEI.
Versin 3.0
57
Bases de Datos I
INACAP
Proceso de integracin de vistas Las vistas se dividen en idnticas y no idnticas. Las idnticas contienen los mismos tipos de objetos, puede que con distintos nombres. Las no idnticas, poseen diferentes tipos de objetos (todo o en parte). Dentro de estas ultimas hay que distinguir las que son equivalentes de las que no lo son. La integracin de vistas consiste en partir de dos vistas y obtener una tercera que las englobe, as sucesivamente hasta llegar al esquema global. Al querer integrar vistas surgen algunos problemas: 1.- Conflictos de nombres:

Homonimia, a dos objetos se les ha asignado el mismo nombre Sinonimia, un mismo objeto con mas de un nombre Ejemplo: conflicto de nombre e entidades, un sistema trata con AUTOR y con cod_autor como atributo identificador y otro, con ESCRITOR e identificador cod_escritor. Solucin: usar una sola con su respectivo identificador. Conflicto de nombre en interrelaciones, una REVISTA publica ARTICULO o bien, en una REVISTA aparece un ARTICULO. Solucin: Cambiar el nombre, adoptar uno solo.
2.- Conflictos entre entidades:

o
una entidad es un subconjunto de otra. Solucin: introducir un subtipo. Ej: entidades REVISTA y PUBLICACION, esta ltima incluye adems revistas, recopilaciones y otros tipos, se puede resolver introduciendo la revista como un subtipo de publicacin. Se llama restriccin de seleccin. una entidad es disjunta con respecto a otra, pero ambas poseen atributos comunes, es decir, son un subtipo de una tercera entidad. Solucin: crear el supertipo. Se llama restriccin de disyuncin.
3.- Conflicto entre tipos de objetos en los que un atributo en una vista es una entidad es otra o viceversa: La solucin es transformar el atributo en entidad o la entidad en atributo segn convenga. Ej: entidad EDITORIAL o atributo de LIBRO?. Si vemos que es importante almacenar informacin de la editorial la consideraremos una entidad, sino ser atributo.
Versin 3.0
58
Bases de Datos I
INACAP
4.- Conflicto de cardinalidades en interrelaciones: Ej: interrelacin escribe entre AUTOR y DOCUMENTO, en un caso 1,n y en otro n,n.
o o
se trata de la misma interrelacin, en este caso se deja la menos restrictiva n,n. se trata de dos interrelaciones distintas como escribe de tipo n,n y edita de tipo 1,n (suponiendo que un documento puede ser editado por una persona). En este caso se deben reflejar ambas interrelaciones con distintos nombres. la entidad AUTOR tiene una interrelacin con DOCUMENTO que es escribe, mientras que un subtipo de ella (que es EDITOR) tiene otra interrelacin con DOCUMENTO, que es edita. existen dos subtipos de la entidad AUTOR, que poseen interrelaciones distintas con DOCUMENTO, por ejemplo, el subtipo ESCRITOR y el subtipo EDITOR con las interrelaciones escribe y edita, respectivamente.
5.- Anlisis de redundancia de interrelaciones: Una vez integradas las vistas, habr que analizar si se producen redundancias de interrelaciones, lo que grficamente se refleja en ciclos.
Versin 3.0
59
Bases de Datos I
INACAP
Etapa 2: Diseo Lgico En esta etapa transformaremos el esquema conceptual obtenido en la fase anterior a un esquema relacional. Este esquema sigue siendo independiente del SGBD que se utilizar en la siguiente etapa. El paso del esquema E/R al relacional se basa en los siguientes principios:

Todo tipo de entidad se convierte en una relacin Todo tipo de interrelacin N:M se transforma en una relacin
Todo tipo de interrelacin 1:N se traduce en el fenmeno de propagacin de la clave o bien se crea una nueva relacin.
Reglas de transformacin 1.-Transformacin de Dominios CREATE DOMAIN Estados_Civiles AS CHAR(1) CHECK(VALUE in ( S, C, V, D) 2.-Transformacin de entidades
Versin 3.0
60
Bases de Datos I
INACAP
Direccin rea Informtica CREATE TABLE... Cada entidad se transforma en una relacin.
3.-Transformacin de atributos de entidades Los AIP, pasan a ser la clave primaria de la relacin PRIMARY KEY. Los AIA, pasan a ser UNIQUE. Ambas son clusulas en el comando CREATE TABLE. 4.-Transformacin de Interrelaciones i ) Interrelaciones N:M Se transforma en una relacin que tendr como clave primaria la concatenacin de los AIP de las entidades que asocia. Cada uno de estos atributos que forman parte de la clave primaria son clave fornea respecto a las tablas en donde son claves primarias. Esto se representa por al clusula FOREING KEY dentro del comando CREATE TABLE de la relacin. ii ) Interrelaciones 1:N

Propagar el AIP de la entidad que tiene cardinalidad mxima 1 a la que tiene n. Transformarlo en una relacin, como si se tratara de una interrelacin N:M. Esto es ms conveniente cuando: o El nmero de ocurrencias de la entidad que propaga su clave es muy pequeo, evitando los valores nulos. o Cuando se prev que en el futuro dicha interrelacin se convierta en una N:M o Cuando la interrelacin tiene atributos propios Un aspecto importante en estas interrelaciones se relaciona con las cardinalidades mnimas. Si la cardinalidad mnima de la entidad que se propaga es 1, significa que no pueden admitirse valores nulos en la clave fornea (clave propagada). En cambio, si es 0, si se admiten valores nulos.
iii ) Interrelaciones 1:1 Son casos en donde se puede crear una relacin o bien propagar la clave. Esto ltimo puede ser en ambas direcciones.
Si las entidades que se asocian tienen ambas cardinalidades (0,1):
Versin 3.0
61
Bases de Datos I
INACAP
En el MR: MATRIMONIO(cod_hombre , cod_mujer) HOMBRE(cod_hombre,....) MUJER(cod_mujer,....) As, se evitan los valores nulos que apareceran en caso de propagar la clave de la entidad MUJER a la entidad HOMBRE o viceversa. Recordar que no todos los hombres ni todas las mujeres estn casados. Una de las entidades tiene cardinalidad (0,1) y la otra (1,1), conviene propagar la clave de la entidad con cardinalidad (1,1) a la tabla resultante de la entidad de cardinalidad (0,1).
En MR: EMPLEADO(cod_empleado,...) DEPTO(cod_depto,cod_empleado) , clave fornea, NOT NULL En el caso de que ambas entidades tengan cardinalidades (1,1), se puede propagar la clave en cualquier direccin. Sera conveniente tener en cuenta acceso ms frecuentes y prioritarios de los datos. 5.-Transformacin de atributos de interrelaciones Es conveniente que aquellas interrelaciones que posean atributos propios se transformen en una relacin en donde aquellos atributos pasan a ser columnas de dicha relacin. 6.-Transformacin de restricciones Las restricciones son por ejemplo rango de valores para un determinado dominio. Muchas de las restricciones no se representan en el esquema conceptual por lo que no existen reglas claras para transformarlas. Usualmente las restricciones se consideran en la fase siguiente y se implementan a travs de funcionalidades particulares que ofrecen los SGBD comerciales. Tpicamente esto es a travs de triggers.
Versin 3.0
62
Bases de Datos I
INACAP
7.-Transformacin de dependencias en identificacin y en existencia
En MR: LIBRO(cod_libro,...) EJEMPLAR(cod_libro, cod_ejemplar,...) clave fornea, NOT NULL, ON DELETE CASCADE, ON UPDATE CASCADE. Para dependencia en identificacin, la clave primaria de la entidad dbil debe estar formada por la concatenacin de las claves de las dos entidades participantes en la interrelacin. 8.-Transformacin de tipos y subtipos
a ) Una sola relacin, correspondiente al supertipo. Es conveniente cuando existan muy pocos atributos diferentes entre los subtipos y las interrelaciones que los asocian con el resto de las entidades del diagrama son las mismas para todos los subtipos. DOCUMENTO(cdigo, ttulo, idioma,...,tipo) b ) Una relacin para entidad: el supertipo y los subtipos correspondientes. Es conveniente cuando existen muchos atributos diferentes entre los subtipos y adems se quieren mantener los atributos comunes de todos ellos en una relacin (supertipo). DOCUMENTO(cdigo, ttulo, idioma,...) ARTICULO(cdigo,....) LIBRO(cdigo,...)
Versin 3.0
63
Bases de Datos I
INACAP c)
Relaciones para los subtipos, que contengan adems los atributos comunes. Es conveniente cuando existen muchos atributos distintos entre los subtipos y los accesos realizados sobre los datos de los distintos subtipos siempre afectan a atributos comunes. LIBRO(cdigo,ttulo, idioma,...) ARTICULO(cdigo,ttulo, idioma, ....)
Etapa 3: Diseo Fsico Esta etapa depende del SGBD comercial que se utilizar para implementar la base de datos Algunos elementos de diseo fsico son: Indices Son lgicamente y fsicamente independientes de los datos. Se crean o eliminan sin que produzca efectos en la base de datos. Se mantienen en forma automtica por los SGBD. Se utiliza el comando CREATE UNIQUE INDEX. Se estructuran en rboles B*-tree. Secuencias Son generadores de nmeros secuenciales utilizados como valor nico para un determinado atributo de una relacin. Sin secuencias, el proceso normal de generacin de estos enteros conlleva un bloqueo manual en acceso para actualizacin de la tabla que los contiene. Con este mecanismo, las estructuras se bloquean justo en el momento de la actualizacin. Se utiliza el comando CREATE SEQUENCE... Cluster o agrupaciones Es una estructura formada por una o varias tablas. Las filas de stas que comparten el mismo valor de clave se almacenan fsicamente juntas. Vistas Son visiones lgicas de tablas, que permiten entregar a los usuarios slo la informacin que a stos les interesa. Facilitan el control de la seguridad de la base de datos
Versin 3.0
64
Bases de Datos I
INACAP
Sinnimos Proporcionan un nombre alternativo para referenciar tablas, vistas o secuencias. Links Son enlaces definidos desde la base de datos local a una base de datos remota.
Versin 3.0
65
Bases de Datos I
INACAP
Unidad 5: Lenguaje de consulta estndar (SQL).
El lenguaje de consulta estructurado (SQL) es un lenguaje de bases de datos normalizado, utilizado por el motor de base de datos Microsoft Jet. SQL se utiliza para crear objetos QueryDef, como el argumento de origen del mtodo. OpenRecordSet y como la propiedad RecordSource del control de datos. Tambin se puede utilizar con el mtodo Execute para crear y manipular directamente las bases de datos Jet y crear consultas SQL de paso a travs para manipular bases de datos remotas Cliente Servidor. El lenguaje SQL est compuesto por comandos, clusulas, operadores y funciones de agregado. Estos elementos se combinan en las instrucciones para crear actualizar y manipular las bases de datos. Existen dos tipos de comandos SQL: Los DLL que permiten crear y definir nuevas bases de datos, campos e ndices. Los DML que permiten generar consultas para ordenar , filtrar y extraer datos de la base de datos.
5.1 Instrucciones de definicin de los datos Comandos DLL Create: Utilizado para crear nuevas tablas campos e ndices Alter: Utilizado para modificar las tablas agregando campos o cambiando campos. Drop: Empleado para eliminar tablas e ndices la definicin de los
Versin 3.0
66
Bases de Datos I
INACAP 5.2 Instrucciones de manipulacin de los datos Comandos DML Select:
Utilizado para consultar registros de la base de datos que satisfagan un criterio determinado Insert: Utilizado para cargar lotes de datos en la base de datos en un a nica operacin Delete: Utilizado para eliminar registros de una tabla de una base de datos. Update Utilizado para modificar los valores de los campos y registros especificados.
5.4 Operadores de comparacin < Menor que > Mayor que <> Distinto que <= Menor igual que >= Mayor igual que = Igual que Versin 3.0 67 Bases de Datos I
INACAP Between Utilizado para expresar un intervalo de valores Like Utilizado en la comparacin de un modelo In Utilizado para especificar registros de una base de datos
5.5 Operadores Lgicos And Es el y lgico. Evala dos condiciones y devuelve un valor de verdad slo si ambas son ciertas Or Es el o lgico. Evala dos condiciones y devuelve un valor de verdad si en alguna de las dos es cierta. Not Negacin lgica. Devuelve el valor contrario de la expresin.
Versin 3.0
68
Bases de Datos I
INACAP
5.6 Consultas sobre mltiples tablas y 5.7 Formato de las salidas
SQL y el lgebra relacional SQL como lenguaje para consultas se fundamenta en el lgebra relacional, se dice que SQL ser completo cuando incluya todas las operaciones del lgebra. Se sealaba hace un par de dcadas respecto de las variadas versiones existentes que la mejor versin de SQL debera incorporar todas las operaciones del lgebra relacional. Actualmente SQL no incluyen la operacin divisin por esto podemos afirmar que SQL es incompleto respecto del lgebra relacional. Sin embargo es posible emular esta operacin en la mayora de las versiones de SQL. Lenguaje de definicin de datos
OBJETIVOS: 1- RECONOCER DDL DE SQL. 2- IDENTIFICAR LOS TIPOS DE DATOS DE CREATE TABLE. 3- APLICAR CORRECTAMENTE CREATE TABLE
Tabla de base Es una tabla que tiene existencia independiente. En la base de datos fsica se representa por un archivo almacenado. Se puede crear una tabla de base en cualquier momento ejecutando la proposicin CREATE TABLE del DDL de SQL, la cual adopta la forma general:
Versin 3.0
69
Bases de Datos I
INACAP
CREATE TABLE nombre-de-tabla-de-base (definicin-de-campo [,definicin-de-campo ] ...) [ IN SEGMENT nombre-de-segmento ] donde una definicin-de-campo, a su vez, adopta la forma: nombre-de-campo ( tipo-de-datos [NONULL] ) (salvo que se indique de modo explcito lo contrario) CREATE TABLA S ( NOMS ESTADO CIUDAD CREATE TABLA P ( NOMP COLOR PESO CIUDAD CREATE TABLA SP( PX CTD SX (CHAR(5), NONULL), (CHAR(20) ), (SMALLINT) ), (CHAR(15) ) ) PX (CHAR(6), NONULL), (CHAR(20) ), (CHAR(6) ), (SMALLINT) ), (CHAR(15) ) ) SX (CHAR(5), NONULL), (CHAR(6), NONULL), (INTEGER) )
La ejecucin fructfera de una proposicin CREATE TABLE hace que una tabla de base nueva (vaca) se cree en el segmento especificado con el nombre-de-tabla-de-base especificado v las definiciones-de-campo especificadas. (Los segmentos y las definiciones-decampo se explican ms adelante). El usuario puede ahora proceder a introducir datos en esa tabla usando la proposicin INSERT de SQL (parte del DML de SQL). Por otra parte, el usuario puede invocar al cargador de System R, que es un programa de utilera suministrado por el sistema para realizar esta funcin. Campos Cada definicin-de-campo de CREATE TABLE incluye tres elementos: un nombre-de-campo, un tipo-de-datos para el campo y (como opcin) una especificacin NONULL. El nombre-decampo, desde luego, debe ser nico en la tabla de base. Los tipos-de-datos permitidos son los siguientes: CHAR (n) hilera de caracteres de longitud fija. CHAR (n) VAR hilera de caracteres de longitud variable. INTEGER entero en binario de una palabra. SMALLINT entero en binario de media palabra. FLOAT nmero en punto flotante de doble palabra.
Versin 3.0
70
Bases de Datos I
INACAP
SQL admite el concepto de valores de campos nulos. En efecto, cualquier campo puede contener un valor nulo a menos que la definicin de ese campo en CREATE TABLE incluya de modo explcito la especificacin NONULL. Nulo es un valor especial que se usa para representar un "valor desconocido o un valor inaplicable". Por ejemplo, un registro de remesa puede contener un valor nulo de CTD (se sabe que la remesa existe, pero se desconoce la cantidad enviada); o un registro de proveedor puede contener un valor nulo de ESTADO (quiz el "estado" no se aplique a los proveedores de pars por alguna razn). Aqu no se estudian en detalle las propiedades del valor nulo, sino que basta sealar que (a) las expresiones aritmticas donde uno de los operandos es nulo se evalan en el valor nulo, y (b) las comparaciones donde uno de los operandos de comparacin es nulo se evalan en el valor de verdad "desconocido". Al igual que una tabla de base nueva puede crearse en cualquier momento, tambin una tabla de base existente puede agrandarse en cualquier instante, adicionando una nueva columna (un campo) a la derecha: EXPAND TABLE nombre-de-tabla-de-base ADD FIELD nombre-de-campo (tipo-de-datos) Por ejemplo EXPAND TABLE SP ADD FIELD FECHA ( CHAR (6) ) Esta proposicin adiciona un campo FECHA a la tabla SP. Todos los registros existentes de SP se aumenta de tres a cuatro campos; el valor del campo nuevo es nulo en cada caso (no se permite la especificacin NONULL en EXPAND TABLE ). Ntese, adems, que la ampliacin de los registros existentes antes mencionada no significa que los registros de la base de datos sean en realidad actualizados en ese instante solo su descripcin almacenada cambia. Tambin es posible destruir una tabla de base existente en cualquier instante: DROP TABLE nombre-de-tabla-de-base Todos los registros de tabla de base especificada se eliminan, todos los ndices y las vistas sobre esa tabla se destruyen, y luego se destruye, tambin la tabla misma (es decir, su descripcin se suprime del diccionario y su espacio de almacenamiento se libera).
Versin 3.0
71
Bases de Datos I
INACAP ndices
Al igual que las tablas de base, los ndices se crean y eliminan usando el DDL de SQL sin embargo, CREATE INDEX y DROP INDEX as como ciertas proposiciones de control de los datos, son las nicas del lenguaje SQL que se refieren a los ndices; otras proposiciones -en particular las de acceso a los datos, como SELECT- no incluyen de modo explcito ninguna de esas referencias. La decisin en cuanto a usar o no un ndice al responder una solicitud particular de datos no la toma el usuario, sino System R (en realidad el optimizador componente del precompilador de RDS). CREATE INDEX adopta la forma general: CREATE [UNIQUE] INDEX nombre-de-ndice ON Nombre-de-tabla-de-base (nombre-de-campo [ORDER] [, nombre-de-campo [ORDER] ] ...) donde "orden" es ASC (ascendente) o DESC (descendente). Si no se especifica ASC ni DESC, entonces se supone ASC por omisin. La secuencia de izquierda a derecha de los campos nombrados en la proposicin CREATE INDEX corresponden a un ordenamiento de mayor a menor en la manera usual; por ejemplo, la proposicin: CREATE INDEX X ON T ( A, B, C ) crear un ndice llamado X sobre la tabla de base T donde las entradas se ordenan por valores ascendentes de C dentro de valores ascendentes de B dentro de los valores ascendentes de A. Una vez creado, un ndice se mantiene de manera automtica (por RSS) para reflejar las actualizaciones en la tabla de base indicada, hasta el instante en que el ndice se suprime. La opcin UNIQUE de CREATE INDEX especifica que no habr dos registros en la tabla de base indicada a los que se les permita tomar el mismo valor para el campo o combinacin de campos indicados (al mismo tiempo). Esta es la nica manera de especificar que no se permiten valores duplicados para ningn campo o combinacin de campos. De esta manera, si se desea hacer cumplir la unicidad de las llaves primarias en la base de datos de proveedores y partes, se deben aadir proposiciones tales como las siguientes: CREATE UNIQUE INDEX XS ON S ( SX ) CREATE UNIQUE INDEX XP ON P ( PX ) CREATE UNIQUE INDEX XSP ON SP ( SX PX )
Versin 3.0
72
Bases de Datos I
INACAP
(los ndices, al igual que las tablas de base, se pueden crear y suprimir en cualquier momento. En el ejemplo se debe asegurar que los ndices XS, XP y XSP se crean antes de colocar cualquier dato en las tablas de base S, P y SP; de lo contrario, las restricciones de unicidad pueden haberse violado. Un intento de crear un ndice nico sobre una tabla que no satisfaga la restriccin de unicidad tendr que fracasar). La proposicin para suprimir un ndice es DROP INDEX nombre-de-ndice. El comando CREATE TABLE es usado para crear archivos de base de datos, tambin se encuentra un par de comandos para insertar tuplas o para actualizarlas. Se puede definir un archivo o tabla de hasta 27 Columnas. SINTAXIS : CREATE TABLE table-name ( column_definition [, column_definition . . .] [, uniqueness constraint] );
COMPONENTES DE CREATE TABLE table_name El nombre de un archivo de base de datos puede ser de 1 a 10 caracteres. Los primeros ocho caracteres son los significativos, el primer carcter debe ser alfabtico. Column_definition Column_name data_type [NOT NULL [UNIQUE]] column_name Un atributo puede tener de 1 a 10 caracteres, el primer carcter del atributo debe ser una letra. data_type Los tipos de datos son de dos clases: nmeros o caracteres. Numeric (Exact Numeric) NUMERIC [ ( length [.decimal_places] ) ] DECE [ (length [, declmal_places ] ) ] INT SMALLINT Characters [Char (length) ] Este tipo de datos permite combinar caracteres, se justifica a la izquierda, el mximo es ochenta caracteres. CHARACTER y CHAR pueden usarse indistintamente. Si se omite el length modifier, entonces se asume el largo uno.
Versin 3.0
73
Bases de Datos I
INACAP Date
Este tipo crea una columna de ancho ocho caracteres. Las fechas son de la forma mm/dd/'yy estimndose atmica. Logical Y, y, N, n, T, t, F, f, or ? Not Null Caracteriza valores que son distinto de blanco. UNIQUE modifier Seala llave primaria. ACTIVIDAD: EMPRESA MANUFACTURAS MONOLITICAS Manufacturas monolticas produce y vende productos de alta calidad en el oeste de los EE.UU. posee sucursales en varios estados. Los productos son manufactura dos por lotes, cuando el lote es terminado se registra en la base de datos, especficamente en el archivo de base de datos correspondiente, con la fecha, el cdigo del producto, el estado donde el producto fue manufacturado la cantidad de tems vendibles y el porcentaje de defectuosos del lote. Seala al archivo de manufacturado el archivo de productos algo tan simple como, dado el cdigo, la descripcin del producto. Las ventas efectuadas por cada sala de venta es registrada en un archivo de ventas. Cuando una venta es efectuada, se registra la fecha, la sucursal, el comprador, el vendedor, el producto y la cantidad vendida. Seala el archivo de ventas al archivo de sucursales, al de vendedores y al de clientes. El archivo de empleados contiene el nmero del empleado, su nombre, y el empleado jefe. El archivo de sucursales contiene el nmero de sucursal el estado y el administrador. El archivo de cliente contiene el nmero de cliente, el estado donde reside, su nombre. En detalle los seis archivos de la base de datos de manufacturas monolticas:
VEN FEC_VEN SUC_COD COD_CLI COD_EMP COD_ART QTY_ART
CLI COD_CLI NOM_CLI EST_CLI RTG_CLI
LOT FEC_LOT COD_ART EST_ART DEF_ART QTY_ART
SUC COD_SUC EST_SUC COD_JEF
EMP COD_EMP NOM_EMP COD_JEF
PRO COD_ART ESTY_ART DES_ART
Versin 3.0
74
Bases de Datos I
INACAP
Ejemplificamos con la creacin del archivo de base de datos CLI(ente): create table CLI ( COD_CLI char(2) not null unique, NOM_CLI char(15) not null, EST_CLI char(2) not null, RTG CLI numeric(2) ); Lenguaje de manipulacin de datos OBJETIVOS: 1- RECONOCER EL DML DE SSQL. 2- POBLAR ARCHIVOS DE BASE DE DATOS. 3- APLICAR CORRECTAMENTE INSERT. CONTENIDO: INSERT SINTAXIS: INSERT INTO table_name [column_name [,colum_name. ... ] ] VALUES (column_value [, column_value ] );
EJEMPLO:
insert into values
CLI COD_CLI, NOM_CLI, EST_CLI, RTG _CLI (AA, Compugorp, WA ,20);
ACTIVIDAD: Dada la siguiente lista de tuplas de la base de datos de manufacturas monolticas, poblar los archivos del ejercicio anterior. Sucursal EST_SU C AZ CA AZ ARTiculo COD_JE F 10 20 30 COD_ART MW GC NM DD DES_ART Megawamp Gigasnarf Nanomouse Dynamic Dis
COD_SU C 1A 2A 1B
COD_EMP 1 10 11 12 13
EMPleado NOM_EMP Harvey Bigcheese Mary Hizzle Marty Nogglater Elark Kaboom Kelly Unlucky
COD_JEF 1 12 10 12
Versin 3.0
75
Bases de Datos I
INACAP 14 20 22 24 27 30 32 33 35 37 Bobo Butters Nancy Umlat Kanga Rat Xero Xanadu Quarkly Poslak Vern Equinox Otto Otter Yarquark Moon Duncan Donut Duncan Bagel EMPleado EST_ART
Direccin rea Informtica 12 1 20 22 20 1 35 35 30 35
COD_EMP 1 10 11 12 13 14 20 22 24 27 30 32 33 35 37
COD_ART
DEF_ART
QTY_ART
GC GC NM DD DD NM DD DD GC
ID ID CA ID WA WA AZ CA AZ
12 0 17 22 15 12 15 4
15 55 93 25 46 25 25 25 43
FEC_VEN 04/01/94 04/01/94 04/08/94 04/08/94 04/10/94 04/12/94 04/15/94 04/18/94 04/01/94 04/08/94 04/15/94 04/08/94 04/01/94 04/08/94 04/15/94 Versin 3.0
COD_SUC 1A 1A 1A 1B 1B 1B 2A 2A 1A 1A 1A 1B 2A 2A 2A
VENta COD_CLI COD_EMP ZZ 11 ZZ 11 DD 12 EE 24 BB 27 BB 27 BB 33 AA 35 AA 10 AA 10 AA 10 DD 11 ZZ 12 ZZ 12 AA 30 76
COD_ART MW DD AB MW NM MW GC MW MW DD NM GC NM MW GC
QTY_ART 23 34 2 81 3 41 33 125 947 452 32 845 45 73 127
Bases de Datos I
INACAP 04/15/94 2A AA 30
Direccin rea Informtica DD 32
COD_CLI AA BB ZZ DD EE FF Manipulacin de datos del SQL
CLIente NOM_CLI EST_CLI Compugorp WA Technoharp OR s AZ Organomice AZ QuarkCo CA Marswarp NV Multicrud
RTG_CLI 20 15 34 10 30 2
OBJETIVOS: 1- COMPRENDER EL COMANDO SELECT EN SUS ASPECTOS MAS ELEMENTALES. 2REPRODUCIR EFICIENTEMENTE CONSULTAS EFECTUADAS EN SQL. 3- IDENTIFICAR LA SEMANTICA DE CADA QWERY SOBRE SELECT. En esta parte se presenta la porcin de DML del lenguaje SQL El DML de SQL opera a la vez con tablas de base y vistas. Operaciones de recuperacin La operacin fundamental en SQL es la transformacin, que se representa sintacticamente como un bloque SELECT-FROM-WHERE. Por ejemplo, la consulta obtenga nmeros de proveedores y estado para los proveedores en pars" puede expresarse como sigue: SELECT SX, ESTADO FORM WHERE CIUDAD = PARIS Se puede advertir en este ejemplo que la operacin de 'transformacin" es, en efecto, la formacin de un subconjunto horizontal (halle todos los renglones donde CIUDAD = "PARIS") seguida de la formacin de un subconjunto vertical (extraiga Sx y ESTADO de estos renglones). En trminos algebraicos se puede considerar como un SELECT seguido por un PROJECT excepto que, como se seala despus, la operacin encaminada a formar un subconjunto horizontal puede ser mucho ms compleja que la sencilla operacin algebraica SELECT. (no Versin 3.0 77 Bases de Datos I
INACAP
debe confundirse el SELECT algebraico con el SELECT de SQL) Ahora se procede a explicar las caractersticas principales del lenguaje de recuperacin por medio de un conjunto de ejemplos desarrollados con cuidado. Recuperacin simple Obtenga los nmeros de parte de todas las partes suministradas: SELECT FROM PX SP
Se sugiri que una transformacin (SELECT-FROM-WHERE) puede considerarse como una formacin de un subconjunto horizontal seguida por una proyeccin. En este ejemplo, el subconjunto horizontal es la tabla completa (sin la clusula WHERE). En cuanto a la proyeccin, se recuerda al lector que PROJECT, como se defini formalmente, opera extrayendo columnas especificadas y luego eliminando los renglones duplicados redundantes de las columnas extradas (el resultado es una relacin, sin renglones duplicados). Sin embargo, SQL en general no elimina los duplicados del resultado de ejecutar una proposicin SELECT a menos que el usuario lo solicite de modo explcito por medio de la palabra clave UNIQUE, como en el ejemplo siguiente: SELECT UNIQUE PX FROM SP La justificacin para exigir al usuario que especifique UNIQUE en tales casos es que (a) la eliminacin de duplicados puede ser una operacin costosa, y (b) los usuarios a menudo no advertirn la presencia de los duplicados en sus resultados. Adems, se adopta en INGRES una filosofa semejante. Recuperacin simple Obtenga todos los detalles de todos los proveedores. SELECT * FORMS Resultado : Una copia de la tabla S completa. El asterisco es una abreviatura de una lista ordenada de todos los nombres de campo en la tabla FROM (como lo especific el diccionario se SQL en el momento en que el SELECT se precompil: no se incluir ningn campo agregado despus de la tabla por medio de EXPAND TABLE). La proposicin SELECT mostrada es, pues, equivalente a:
Versin 3.0
78
Bases de Datos I
INACAP SELECT SX, NOMS, ESTADO, CIUDAD FROMS Recuperacin calificada:
Obtenga nmeros de proveedor para los proveedores de Pars con estado > 20. SELECT SX FROMS WHERE CIUDAD = aPARISa AND ESTADO > 20 La condicin o predicado que sigue a WHERE puede incluir los operadores de comparacin =, =(no igual), >, >=, <, y <=, los operadores booleanos AND, OR y NOT; y parntesis para indicar un orden deseado de evaluacin. Recuperacin con ordenamiento: Obtenga nmeros de proveedor y estado de los proveedores en Pars, en orden descendente de estado. SELECT SX, ESTADO FROMS WHERE CIUDAD = PARIS ORDER BY ESTADO DESC Recuperacin de ms de una tabla: Para cada parte suministrada, obtenga el nmero de la parte y los nombres de todas las ciudades que suministran la parte: SELECT UNIQUE PX.CIUDAD FROMSP, S WHERE SP.SX = S.SX Recuperacin usando IN Obtenga nombres de proveedores para los proveedores que suministran la parte P2. SELECT NOMS FROMS
Versin 3.0
79
Bases de Datos I
INACAP
WHERE SX IN (SELECT SX FROMSP WHERE PX = "P2") IN y =ANY son completamente intercambiables. Cada uno puede equipararse al operador E de pertenencia a un conjunto. En adelante se usar a menudo IN en lugar de =ANY. Recuperacin con niveles mltiples de anidamiento Obtenga nombres de proveedor para los proveedores que suministran al menos una parte roja. SELECT NOMS FROM S WHERE SX IN (SELECT SX FROM SP WHERE PX IN (SELECT PX FROM P WHERE COLOR = ROJO) ) Recuperacin con una subconsulta, con referencia entre bloques Obtenga nombres de proveedor para los proveedores que suministran la parte P2. Se indica a continuacin otra solucin a este problema para introducir un punto nuevo. SELECT NOMS FROM S WHERE P2 IN (SELECT PX FROMSP WHERE SX = S.SX) Recuperacin con una subconsulta, con la misma tabla en ambos bloques Obtenga nmeros de proveedor para los proveedores que suministran al menos una parte suministrada por el proveedor S2. SELECT UNIQUE SX FROM SP WHERE PX IN (SELECT PX Versin 3.0 80 Bases de Datos I
INACAP FROM SP WHERE SX = S2)
Recuperacin con una subconsulta, con referencia entre bloques y la misma tabla en ambos bloques Obtenga nmeros de parte para todas las partes suministradas por ms de un proveedor. SELECT UNIQUE PX FROM SP SPX WHERE PX IN ( SELECT PX FROM SP WHERE SX = SPX.SX ) Recuperacin usando ALL Obtenga nombres de proveedor para los proveedores que no suministran la parte P2. Una vez ms hay muchas soluciones posibles, la que se muestra se escogi para ejemplificar una comparacin ALL. SELECT NOMS FROM S WHERE P2 <> ALL (SELELECT PX FROMSP WHERE SX = S.X) Recuperacin usando EXISTS Obtenga nombres de proveedor para los proveedores que suministran la parte P2. SELECT NOMS FROM S WHERE EXISTS (SELECT * FROMSP WHERE SX = S.SX AND PX = P2) EXISTS representa aqu al cuantificador existencial.
Versin 3.0
81
Bases de Datos I
INACAP
Recuperacin usando NOT EXISTS Obtenga nombres de proveedor para los proveedores que suministran todas las Partes. SELECT NOMS FROM S WHERE NOT EXISTS (SELECT * FROM P WHERE NOT EXISTS (SELECT * FROM SP WHERE SX = S.SX AND PX = P.PX) ) La consulta puede describirse as: Seleccione nombres de proveedor para los proveedores tales que no exista una parte que no suministren". Recuperacin usando UNION Obtenga nmeros de partes para las partes que pesen ms de 18 libras o que actualmente sean suministradas por el proveedor S2 (o ambas cosas). SELECT PX FROM P WHERE PESO > 18 UNION SELECT PX FROM SP WHERE SX = S2
Recuperacin que comprende a NULL Para los fines de ejemplo, supngase que el proveedor S5 tiene un estado de nulo. Obtenga nmeros de proveedor para los proveedores con estado mayor que 25.
Versin 3.0
82
Bases de Datos I
INACAP SELECT SX FROM S WHERE ESTADO > 25
El proveedor S5 no satisface los requisitos. Cuando un valor nulo se compara con algn otro valor al evaluar un predicado, cualquiera que sea el operador de comparacin utilizado, el resultado de la comparacin nunca es verdadero, incluso si ese otro valor tambin es nulo; en otras palabras, ninguna de las siguientes comparaciones da verdadero: nulo > 25 nulo < 25 nulo = 25 nulo = 25 nulo = nulo ACTIVIDAD: APLICANDO SQL PRUEBE CADA UNO DE LOS SIGUIENTES EJEMPLOS 1SELECT * FROM LOT; FEC_LOT COD_ART EST_ART DEF_ART QTY_ART 02-07-94 GC ID 12 15 02-01-94 GC ID 0 55 02-02-94 NM CA 17 93 02-02-94 DD ID 25 02-03-94 DD WA 22 46 02-02-94 NM WA 15 25 02-04-94 DD AZ 12 25 02-04-94 DD CA 15 25 02-06-94 GC AZ 4 43
2-
SELECT COD_ART, EST_ART FROM LOT; COD_ART GC GC NM DD DD NM DD EST_ART ID ID CA ID WA WA AZ
Versin 3.0
83
Bases de Datos I
INACAP DD GC CA AZ
3-
SELECT DISTINCT EST_ART FROM LOT; EST_ART ID CA WA AZ
4-
SELECT EST_ART, COD_ART FROM LOT; EST_ART ID ID CA ID WA WA AZ CA AZ COD_ART GC GC NM DD DD NM DD DD GC
5-
SELECT * FROM CLI WHERE EST_CLI = AZ; COD_CLI NOM_CLI EST_CLI ZZ ORGANOMICE AZ DD QUARKO AZ RTG_CLI 34 AZ
6-
SELECT * FROM LOT WHERE DEF_ART > 10; FEC_LOT COD_ART EST_ART DEF_ART QTY_ART 02-07-94 GC ID 12 15 02-02-94 NM CA 17 93 02-03-94 DD WA 22 46
Versin 3.0
84
Bases de Datos I
INACAP 02-02-94 02-04-94 02-04-94 7NM DD DD WA AZ CA 15 12 15 25 25 25
SELECT NOM_CLI FROM CLI WHERE NOM_CLI > MACHADO; NOM_CLI TECHNOHARPS ORGANOMICE QUARKCO MARSWARP MULTICRUD
8-
SELECT * FROM LOT WHERE EST_ART = ID; FEC_LOT COD_ART EST_ART DEF_ART QTY_ART 02-07-94 GC ID 12 15 02-01-94 GC ID 0 55 02-02-94 DD ID 0 25
9-
SELECT COD_ART FROM LOT WHERE DEF_ART IS NULL; COD_ART DD
10- SELECT * FROM LOT WHERE DEF_ART IS NOT NULL; FEC_LOT COD_ART EST_ART DEF_ART QTY_ART 02-07-94 GC ID 12 15 02-01-94 GC ID 0 55 02-02-94 NM CA 17 93 02-03-94 DD WA 22 46 02-02-94 NM WA 15 25 02-04-94 DD AZ 12 25 02-04-94 DD CA 15 25 Versin 3.0 85 Bases de Datos I
INACAP
02-06-94
GC
AZ
43
11- SELECT DISTINCT COD_ART FROM LOT WHERE EST_ART = WA AND DEF_ART > 16; COD_ART DD 12- SELECT DISTINCT COD_ART FROM LOT WHERE EST_ART = WA OR EST_ART = ID; COD_ART GC DD NM 13- SELECT DISTINCT COD_ART FROM LOT WHERE EST_ART = WA AND EST_ART = ID; COD_ART NO ROWS FOUND 14- SELECT * FROM LOT WHERE NOT(EST_ART = WA OR EST_ART = ID); FEC_LOT COD_ART EST_ART DEF_ART QTY_ART 02-02-94 NM CA 17 93 02-04-94 DD AZ 12 25 02-04-94 DD CA 15 25 02-06-94 GC AZ 4 43 15- SELECT DISTINCT COD_ART FROM LOT WHERE COD_ART = NM AND COD_ART = GC AND COD_ART = DD;
Versin 3.0
86
Bases de Datos I
INACAP
16- SELECT DISTINCT COD_ART FROM LOT WHERE EST_ART = WA OR EST_AR = ID; COD_ART GC DD NM 17- SELECT DISTINCT COD_ART FROM LOT WHERE (EST_ART = WA OR COD_ART = ID) AND DEF_ART < 16; FEC_LOT COD_ART EST_ART DEF_ART QTY_ART 02-07-94 GC ID 12 15 02-01-94 GC ID 0 55 02-02-94 NM WA 15 25 18- SELECT DISTINCT COD_ART FROM LOT WHERE EST_ART = WA OR COD_ART = ID AND DEF_ART < 16; FEC_LOT COD_ART EST_ART DEF_ART QTY_ART 02-07-94 GC ID 12 15 02-01-94 GC ID 0 55 02-03-94 DD WA 22 46 02-02-94 NM WA 15 25 19- SELECT FEC_LOT, COD_ART, EST_ART FROM LOT WHERE DEF_ART = ANY(12,15); FEC_LOT COD_ART EST_ART 02-07-94 GC ID 02-02-94 NM WA 02-04-94 DD AZ 02-04-94 DD CA
Versin 3.0
87
Bases de Datos I
INACAP 20- SELECT FEC_LOT, COD_ART, EST_ART FROM LOT WHERE EST_ART != ALL(WA, ID); FEC_LOT COD_ART EST_ART 02-02-94 NM CA 02-04-94 DD AZ 02-04-94 DD CA 02-06-94 GC AZ 21- SELECT COD_ART, EST_ART, DEF_ART FROM LOT WHERE DEF_ART BETWEEN 12 AND 16; COD_ART GC NM DD DD ID WA AZ CA EST_ART DEF_ART 12 15 12 15
22- SELECT * FROM LOT WHERE DEF_ART != 15; FEC_LOT COD_ART EST_ART DEF_ART QTY_ART 02-07-94 GC ID 12 15 02-01-94 GC ID 0 55 02-02-94 NM CA 17 93 02-03-94 DD WA 22 46 02-04-94 DD AZ 12 25 02-06-94 GC AZ 4 43 23- SELECT FROM LOT WHERE DEF_ART != 15; (NO HAY RESULTADO, NO SE INDICO LO QUE SE DEBIA SELECCIONAR)
Versin 3.0
88
Bases de Datos I
INACAP FUNCIONES INTEGRADAS
OBJETIVOS: 1- REPRODUCIR CADA UNA DE LAS CONSULTAS. 2- APLICAR FUNCIONES: SUM, COUNT Y AVG. 3- IDENTIFICAR VALORES NULL. El lenguaje de recuperacin descrito hasta ahora es completo, segn se acaba de explicar, es an inadecuado para muchos problemas prcticos. SQL, por tanto, proporciona varias funciones integradas especiales para mejorar su poder bsico de recuperacin. Las funciones soportadas actualmente son: COUNT, SUM, AVG, MAX y MIN. Todas estas funciones producen el siguiente resultado: COUNT : SUM : AVG : MAX : MIN : el nmero de valores la suma de los valores el promedio de 10 valores el valor ms grande el valor ms pequeo
ACTIVIDAD: En SQL aplique cada una de las consultas dadas e identifique la semntica de cada consulta, seale en que consultas afectan los valores NULL de los archivos de base de datos monoltica. 24- SELECT COUNT(COD_ART) FROM LOT; CNT(COD_ART) 25- SELECT COUNT(DISTINCT EST_ART) FROM LOT; CNT(EST_ART) 4 26- SELECT COUNT(*)
Versin 3.0
89
Bases de Datos I
INACAP FROM LOT; CNT(*) 9 27- SELECT COUNT(COD_JEF) SELECT EMP;
CNT(COD_JEF) 14 28- SELECT COUNT(DISTINCT COD_JEF) SELECT EMP; CNT(COD_JEF) 7 29- SELECT COD_ART, EST_ART, DEF_ART FROM LOT WHERE EST_ART = ID; COD_ART GC GC DD ID ID ID EST_ART DEF_ART 12 0
30- SELECT AVG (DEF_ART) FROM LOT WHERE EST_ART = ID; AVG (DEF_ART) 6 31- SELECT SUM (QTY_ART) FROM LOT WHERE COD_ART = DD; SUM(QTY_ART) 121 32- SELECT AVG (QTY_ART), SUM (QTY_ART) FROM LOT WHERE COD_ART = DD; AVG(QTY_ART) SUM(QTY_ART) 30 121
Versin 3.0
90
Bases de Datos I
INACAP
OBJETIVOS: 1- APLICAR OPERACIONES ARITMETICAS SOBRE LOS ATRIBUTOS DE LAS RELACIONES EN CONSULTA. 2- APLICAR ORDER BY Y HAVING EN LA CONFECCION DE CONSULTAS. 3- INTERPRETAR SEMANTICAMENTE QWERY EN SQL.
ACTIVIDAD: Reproducir cada consulta e indicar su correspondiente significado. 33- SELECT COD_ART, DEF_ART*2 FROM LOT; COD_ART GC GC NM DD DD NM DD DD GC DEF_ART 24 0 34 44 30 24 30 8
34- SELECT EST_ART, AVG(DEF_ART) FROM LOT GROUP BY EST_ART; EST_ART AZ CA ID WA AVG(DEF_ART) 8 16 6 18
35- SELECT EST_ART, AVG(DEF_ART) FROM LOT GROUP BY EST_ART HAVING AVG(DEF_ART) > 10; 36- SELECT FEC_LOT, COD_ART, DEF_ART FROM LOT
Versin 3.0
91
Bases de Datos I
INACAP WHERE EST_ART = ID ORDER BY ART_DEF;
37- SELECT FEC_LOT, EST_ART, COD_ART, QTY_ART FROM LOT GROUP BY FEC_ART, EST_ART;
OBJETIVOS: APLICAR CORRECTAMENTE LAS SIGUIENTES ORDENES. ORDENES: - UPDATE - DELETE Y DROP - CREATE VIEW
Una vista es una relacin o archivo de base de datos derivado, que describe una alternativa de acceso a los archivos de la base de datos (que ya existen), las vistas son relaciones virtuales. SINTAXIS: CREATE VIEW view_name [(column_name [, column_name... )]] AS select_statement UPDATE Permite modificar los valores de los atributos. SINTAXIS: UPDATE table_name SET column_name = value [, column_name = value...] WHERE search_condition DELETE (ATRIBUTOS) SINTAXIS:_ DELETE FROM table_name
Versin 3.0
92
Bases de Datos I
INACAP WHERE search expression]
DROP TABLE/VIEW El comando DROP elimina archivos de base de datos y vistas. SINTAXIS: DROP TABLE table_name; o DROP VIEW view_name;
ACTIVIDAD: Determine la salida de cada consulta sin aplicar SSQL, aplique slo para verificar. 38- SELECT * FROM LOT WHERE EST_ART = AZ REDIRECTO ARIZ ORDER BY COD_ART; 39- SELECT COD_ART, EST_ART FROM LOT WHERE EST_ART = CA UNION SELECT COD_ART, EST_ART FROM PRO WHERE EST_ART = ID; 40- SELECT NOM_CLI, COD_ART, QTY_ART FROM VEN, CLI WHERE VEN.COD_CLI = CLI.COD_CLI; 41- SELECT COD_CLI, QTY_ART FROM VEN WHERE COD_ART = NM AND QTY_ART > (SELECT SUM(QTY_ART) FROM VEN WHERE COD_CLI= BB AND COD_ART = NW); 42- SELECT DISTINCT COD_ART FROM VEN WHERE COD_CLI IN (SELECT COD_CLI FROM CLI WHERE EST_CLI = AA); 43- SELECT * FROM VEN Versin 3.0 93 Bases de Datos I
INACAP WHERE QTY_ART > (SELECT AVG(QTY_ART) FROM VEN); 44- Suponga existe VEN1 idntica a VEN! SELECT * FROM VEN, VEN1 WHERE QTY_ART > (SELECT AVG(QTY_ART) FROM VEN WHERE VEN.COD_ART = VEN1.COD_ART); 45- SELECT DES_ART FROM ART WHERE EXIST (SELECT * FROM VEN WHERE ART_COD_ART = VEN.COD_ART); 46- UPDATE CLI SET RTG_CLI = RTG_CLI + 5 WHERE COD_CLI = AA; 47- UPDATE CLI SET RTG_CLI = NULL WHERE COD_CLI = CC; 48- UPDATE LOT SET DEF_ART = 10 WHERE FEC_LOT = 07/21/94 AND COD_CLI = GC AND EST_ART = ID; 49- UPDATE CLI SET RTG_CLI = 14, EST_CLI = ID WHERE COD_CLI = BB;
50- UPDATE CLI SET RTG_CLI = 30 WHERE COD_CLI IN (SELECT DISTINCT COD_CLI FROM CLI, VEN WHERE CLI.COD_CLI = VEN.COD_CLI AND COD_SUC = 2A; AND QTY_ART > (SELECT AVG(QTY_ART) FROM VEN) );
Versin 3.0
94
Bases de Datos I
INACAP 51- DELETE FROM CLI; 52- DELETE FROM CLI WHERE RTG_CLI < 10; 53- SELECT * FROM VEN WHERE COD_CLI IN (SELECT COD_CLI FROM CLI WHERE RTG_CLI < 10); 54- DELETE FROM VEN WHERE COD_CLI IN (SELECT COD_CLI FROM CLI WHERE RTG_CLI < 10); 55- DELETE FROM VEN WHERE NOT EXISTS (SELECT * FROM CLI WHERE VEN.COD_CLI = CLI.COD_CLI); 56- CREATE VIEW CLTE AS SELECT COD_CLI, NOM_CLI, EST_CLI FROM CLI; 57- SELECT * FROM CLTE; 58- DROP TABLE CLI 59- DROP VIEW CLTE
Fin
Versin 3.0
95
Bases de Datos I
INACAP
BIBLIOGRAFA
Silberschatz, Abraham Korth, Sudarshan, S. Fundamentos de Bases de Datos, Tercera Edicin, Madrid, Editorial Mc Hill, 1998. Wiederhold, Gio Graw Hill, 1998. Diseo de Bases de Datos. Segunda Edicin, USA, Editorial Mc
http://usuarios.tripod.es/smaug Bases de Datos tema1. DECUPS, curso 2000 2001. Introduccin a las Bases de Datos, Victor Prez, Editorial Universitaria. Introduccin a los Sistemas de Bases de Datos, C. J. Date, Prentice H.
CC42A Bases de Datos, Universidad de Chile, Facultad de Ciencias Fsicas y Matemticas, Departamento de Ciencias de la Computacin
Versin 3.0
96
Bases de Datos I

Manual Inacap Base Datos I.pdf - Adobe Reader, Versión - Firma1, Firmado Por DAI, 2002.04.26 13 - 24 - 43 - 04'00'

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Manual Inacap Base Datos I.pdf - Adobe Reader, Versión - Firma1, Firmado Por DAI, 2002.04.26 13 - 24 - 43 - 04'00'

Cargado por

Copyright:

Formatos disponibles

INACAP

Direccin rea de Informtica

MANUAL Bases de Datos I

Programa de Estudios: INGENIERA EN GESTIN INFORMTICA ANALISTA PROGRAMADOR

Direccin rea Informtica

Direccin rea Informtica 26 26 26

Direccin rea Informtica

Direccin rea Informtica

Unidad 1: Enfoques de Bases de Datos.

INACAP Datos de entrada:

Direccin rea Informtica

INACAP Nivel de planeamiento estratgico:

Direccin rea Informtica

Direccin rea Informtica

INACAP Sobre el diseo lgico:

Direccin rea Informtica

Direccin rea Informtica

INACAP 1. Administracin de la informacin:

Direccin rea Informtica

INACAP Las actividades del AI:

Direccin rea Informtica

INACAP Elementos de una Base de Datos:

Direccin rea Informtica

Direccin rea Informtica

INACAP Entre las ventajas del DD se tiene:

Direccin rea Informtica

INACAP Beneficios y riesgos de usar Banco de Datos.

Direccin rea Informtica

Direccin rea Informtica

Direccin rea Informtica

UNIDAD 2: Caractersticas y representacin de Datos.

INACAP Ejemplo de una base de datos en red:

Direccin rea Informtica

6 21344 Rivera Juan 7 23456 Ros Mara 8

INACAP Ejemplo de una base de datos jerrquica:

Direccin rea Informtica

Curso Cois 5100 Cois 5100 Cois 5120 Cois 5130

Direccin rea Informtica

INACAP 2.2 Naturaleza del dato

Direccin rea Informtica

Direccin rea Informtica

INACAP Cmo se identifican Entidades?

Direccin rea Informtica

Direccin rea Informtica

Unidad 3: Modelos de Datos.

Direccin rea Informtica

Direccin rea Informtica

Direccin rea Informtica

INACAP Enfoque Jerrquico

Direccin rea Informtica

Direccin rea Informtica

EMPLEADO a) Estructura lgica con cuatro tipos de registros

b) Ejemplo de la base de datos jerrquica de la estructura a

Archivo jerrquico con cuatro tipos de registros

INACAP Terminologa para describir los rboles

Direccin rea Informtica

INACAP El Enfoque de Red

Direccin rea Informtica

Direccin rea Informtica

Direccin rea Informtica

Direccin rea Informtica

INACAP 3.12 Normalizacin