Manual Base de Datos I V3.0

8/8/2019 Manual Base de Datos I V3.0

1/98

Bases de Datos

- 1


2/98

INDICE

Tema Pgina

1. Enfoques de Bases de Datos 41.1 Enfoque tradicional de procesamientos de datos 4

Enfoque por agregacin 7Sistemas de procesamiento de archivos 7Desventajas 7

Redundancia no controlada 7Inconsistencia de Datos 7Inflexibilidad 7Escasa posibilidad de compartir datos 7Pobre estandarizacin 7Baja productividad del programador 7Excesiva Mantencion 7

1.2 Enfoque de bases de datos 9Elementos del enfoque de banco de datos 9Implementacin del enfoque de banco de datos 9Beneficios y riesgos de usar banco de datos 15

1.3 Tipos de sistemas de informacinOperacionalesAdministrativosDe apoyo a la toma de decisionesConcepto Data-Warehouse 15

1.4 Metodologas de Desarrollo1.5 Administracin del recurso informacin

2. Caractersticas y representacin de datos 172.1 Tipos de bases de datos 17

Jerrquicas 18De red 17Relacional 19Orientada al objeto 20

2.2 Naturaleza del dato 212.3 Representacin del dato 22

2.4 Entidades 232.5 Atributos 232.6 Tipos de relaciones 23

Uno a uno 23Uno a muchos 23Muchos a muchos 23Recursivas 23

2


3/98

3. Modelos de datos 243.1 Niveles de abstraccin 24

3


4/98

3.2 Semntica de los datos 263.3 Cardinalidad 263.4 Grado 263.5 Dependencia3.6 Tiempo3.7 Unicidad

3.8 Clase 273.9 Agregacin 27

3.10 Modelos de datos dependientes de la tecnologa 27Jerrquico 28De red 31Relacional 31

3.11 Modelos de datos independientes de la tecnologa 32Orientada a objeto 32Entidad Relacin 33

3.12 Normalizacin de los modelos 35Primera forma normal 38Segunda forma normal 41Tercera forma normal 43

4. Metodologa de diseo de una base de datos 444.1 Enfoque metodolgico 44

Planificacin Top Down 44Diseo Bottom Up 44

4.2 Planificacin de base de datos 44Anlisis Organizacional 45Funciones 46

Procesos 47ActividadesMatrices que relacionan los componentes de una

organizacin4.3 Obtencin del modelo corporativo 494.4 Obtencin de las bases de datos requeridas por la organizacin 524.5 Proceso de diseo de bases de datos 53

Etapa 1: Formulacin y anlisis de Requerimientos 54Paso1:Identificacin del mbito de la base de datos

Paso2:Establecer estndares de recoleccin dedatos

Paso 3: Identificacin de las vistas de usuariosPaso 4: Construccin del Diccionario de DatosPaso5:Establecer requerimientos de procesamiento

Etapa 2: Diseo Conceptual 60Paso 1: NormalizacinPaso 2: Integracin de vistasPaso3: Generacin del modelo conceptual de datos

4


5/98

Paso 4: Revisin del diseoEtapa 3: Diseo de la implementacin 64

Paso 1: Distribucin de datosPaso 2: Organizacin de archivosPaso 3: Indexacin

Paso 4: Restricciones de integridadPaso 5: Mapeo o modelo internoPaso 6: Diseo de programas

5. Lenguaje de consulta estndar (SQL) 665.1 Instrucciones de definicin de los datos 66

Create 66Alter 66Drop 66

5.2 Instrucciones de manipulacin de los datos 67Select 67

Insert 67Delete 67Update 67

5.3 Funciones EspecialesDe nmeroDe cadenaDe fecha

5.4 Operadores de comparacin 675.5 Operadores Lgicos 685.6 Consulta sobre mltiples tablas 695.7 Formato de salidas 69

5


6/98

6

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 conel fin de resolver problemas puntuales que apoyen la toma de decisiones. Laplanificacin de un SIA utiliza dos enfoques tradicionales denominados enfoque poragregacin y enfoque de base de datos.

Para iniciar el tema es necesario que demos una mirada introductoria a algunosconceptos elementales de anlisis de sistemas tradicionales que son la basepara una adecuada comprensin del enfoque por agregacin y del enfoque debase de datos.

Las Empresas e Instituciones, organizan su estructura interna en pos de la eficienciatecnolgica, econmica y administrativa para alcanzar los objetivos y metas que

justifican su existencia como tal. Esto determina la bsqueda de herramientastcnicas y metodolgicas que faciliten el proceso de toma de decisiones. Lossistemas de informacin administrativos, SIA, son las herramientas que apoyan latoma de decisiones.

Qu es un Sistema de Informacin Administrativo?

Se entiende por SIA, las personas, estructura organizacional, mquinas manuales ycomputarizadas, procedimientos administrativos, recursos logsticos, que en suconjunto 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 lasecuencia y la forma de diferentes acciones que determinan la forma en que setransforman los datos

Procesos de transformacin:

Se nutren de datos de entrada y recursos logsticos que logren la transformacin delos datos.


7/98

7

Datos de entrada:

Los datos de entrada se obtienen de tres vertientes, datos primarios o losprovenientes de procesos internos, de datos obtenidos de cmo se tomaron lasdecisiones pasadas y desde los resultados de las acciones llevadas a buentermino 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 losniveles administrativos de la organizacin sea lo ms eficiente y efectiva posible.Las metas y objetivos son el resultado de acciones generadas por decisionestomadas 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 sonapoyadas y los problemas que surgen son enfrentados con informacin ( relevantey oportuna).

Procedimientos administrativos:

Para llevar a buen fin las actividades administrativas mencionadas la organizacinimplementa un conjunto de procedimientos administrativos.

Toma de decisiones y Sias

La toma de decisiones en un SIA se establece en tres niveles, las estructuradas oprogramables, las semi-estructuradas, las no estructuradas o no programables.

En al marco de la toma de decisiones estructuradas se desarrollan modelosreglados que establecen la forma de tomar las decisiones.

Respecto de la toma de decisiones no estructuradas, son aquellas que se tomanpor expertos y no es posible desarrollar un algoritmo que automatice tal procesoheurstico.

Niveles de decisin:

Los Sias proporcionan informacin para la toma de decisiones a tres niveles dedecisin, nivel de planeamiento estratgico, niveles de control de gestin yoperativo.


8/98

8

Nivel de planeamiento estratgico:

Los informes que proporcionan los Sias a este nivel contienen en general: informacinactualizada de la base de datos, estimaciones a futuro, basada en la informacinactualizada de la base de datos e informacin que pone el nfasis en situacionesexcepcionales.

Nivel de control de gestin:

Se relaciona con la informacin necesaria para el uso eficiente y efectivo de los recursosque permitan cumplir los objetivos y metas de la organizacin. Los informes emanadospor los Sias para este nivel son aquellos que contengan informacin para: analizar yefectuar acciones correctivas sobre la operacin y estado de las funcionescorrespondientes 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 acuerdoa las polticas establecidas. Los informes que apoyan la toma de decisiones a nivel decontrol operacional se caracterizan por incluir: transacciones rutinarias, datos utilizadosen 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 especificadentro 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 logro de objetivometas.

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 deinformacin relevante.


9/98

9

5. El SIA provee todos los procedimientos administrativos y documentacin necesariaque hacen posible operar las diferentes actividades del SIA.

Enfoque por agregacin

Cuando la organizacin implementa los SIAS por primera vez lo hacen para resolverproblemas puntuales que apoyan la toma de decisiones y controlar el logro de susmetas 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 unainteraccin mnima entre ellos y que apenas comparten recursos. Estos SIAS puntualesse desarrollan uno sobre el otro a medida que se van necesitando, originando problemascomo la conocida duplicidad de informacin.

La expansin de las organizaciones produce naturalmente la evolucin progresiva de losSIAS, implicando problemas puntuales de procesamiento de informacin ( cuellos debotella), al desarrollar estas soluciones bajo el enfoque por agregacin se han producidolos siguientes inconvenientes:

1. Los SIAS se desarrollan en forma independiente entre s, sin compartir recursos niinteraccin.

2. Se produce consecuentemente duplicidad de informacin, un dato se encuentra envarios archivos.

3. Se produce como corolario de lo anterior problemas con la consistencia de lainformacin ya que los datos duplicados no sern actualizados al mismo tiempo.

4. Adems la responsabilidad de la actualizacin de estos datos recae en muchaspersonas.

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 porprovenir de fuentes distintas, ser interpretados en forma distinta, poseer procesosde actualizacin que obedezcan a acontecimientos distintos.

3. Los mismos datos pueden derivar en resultados diferentes dependiendo del SIA ysus procesos.

Respecto del diseo de los SIAS aplicando el enfoque por agregacin, surgen lassiguientes consecuencias:


10/98

10

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 elsistema.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 comonuevos datos.

2. El uso de diferentes lenguajes de programacin produce incompatibilidad en losformatos de almacenaje.

3. Al modificar programas de aplicacin generalmente es necesario modificar tambinsus 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 deprogramas denominados BALANCE LINE, que se caracterizan por operar con dos tipos dearchivos clsicos de la poca, denominados archivos maestros y de transacciones. Lalgica de operacin de este tipo de programa conocidos hoy como pareo de archivos sebasa en la actualizacin de uno o ms archivos maestros a partir de uno o ms archivo detransacciones. 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 conocidocorte de control, aplicado para producir informes de acuerdo a un criterio de agrupamientode datos. Es el caso de la cartola mensual de una cuenta corriente, all las transacciones uoperaciones son ordenadas por fecha.

Desventajas del enfoque tradicional de datos

1. Redundancia no controlada2. Inconsistencia de datos3. Inflexibilidad

4. Escasa posibilidad de compartir datos5. Pobre estandarizacin

6. Baja productividad del programador7. Excesiva Mantencin


11/98

11

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 unmanejo, control y uso eficiente y efectivo.

En consecuencia se requiere un nivel de decisiones dentro de la organizacin cuyaresponsabilidad sea administrar el recurso informacin.

Todos los datos de la informacin se encuentran almacenados en archivoscentralizados, que permiten el acceso de las aplicaciones que las necesitan.

Los archivos centralizados son accesibles por las aplicaciones y los usuarios segnsus necesidades.

Contempla un sistema de identificacin, descripcin y definicin de los datos de laorganizacin.

Incluye dispositivos de acceso directo y pantallas que facilitan la interrogacin porparte del usuario.

Permite establecer distintos tipos de usuarios con distintos tipos de accesoscentralizados.

Incluye software que facilita la interrogacin de la base de datos para los distintosniveles de usuarios.

Implementa condiciones de seguridad e integridad de los datos y procedimientos derecuperacin de datos en caso de error.

Comprende un almacn centralizado que incluye toda la informacin necesaria de losdatos de la base de datos con el fin de evitar problemas en su administracin aprogramadores, 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 examinarlas funciones que deben incluirse en la implementacin de este enfoque. Para laimplementacin del enfoque de base de datos se debe distinguir las siguientes funciones:


12/98

12

1. Administracin de la informacin:

Encargada de caracterizar, identificar y estandarizar los datos contemplados para labase de datos

2. Almacenamiento de datos:Centraliza los datos de la base de datos en archivos integrados, que genricamente sedenominan base de datos.

3. Supervisin del almacenamiento y recuperacin de los datos:

Proporciona las facilidades necesarias para definir, acceder, manejar, recuperar ycontrolar los datos que se encuentran en la base de datos. Esta funcin es apoyada porel denominado SABD sigla de sistema administrador de base de datos, este softwareinteracta fuertemente con el sistema operativo.4. Administracin de la implementacin computacional de la base de datos:

Identifica, caracteriza, estructura y estandariza computacionalmente aquellos datos quenutren la base de datos y que estarn bajo el control del SABD, por lo cual se llamaASABD, es decir administrador el SABD. Esta funcin adems se encarga deadministrar el hardware y software asociado que permite operar al SABD, as comoaquellos archivos que este origina.

5. Demanda:

Debe agrupar todos los usuarios de la base de datos, que aprovechan las facilidadesprovistas por el SABD. Se entiende por usuarios a los que toman decisiones, lossistemas de informacin administrativos, los programadores, analistas de sistemas yotros.

Elementos del enfoque:

A. Administrador de la Informacin (AI):

El administrador de la informacin debe identificar, caracterizar y controlar los datosincluidos en la base de datos, tal que los usuarios finales encuentren en ella los datosnecesarios para la toma de decisiones y los SIAS encuentren los datos para opera. ElAI centraliza los datos evitando la duplicidad descontrolada, ambigedad einconsistencias de la informacin.


13/98

13

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 lacreacin y Mantencin de la base de datos debe ser segura, confiable y fiable. Entre lasactividades del AI para identificar la informacin a incluir en la base de datos estn:

1. Determinacin de las necesidades de informacin de cada usuario.2. Establecimiento de estndares o medidas de los datos de la base de datos.3. Determinacin, anlisis y filtrado de los datos a incluir en la base de datos.4. 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 unvocamediante el diccionario de datos, el cual se transforma en la fuente de informacin quetiene la organizacin, en cuanto a la disponibilidad de datos. La especificacin derequerimientos de informacin se realiza a travs del diccionario de datos, cuyaMantencin 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 losdatos 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.


14/98

14

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 suinterrogacin. Los SABD proporcionan las herramientas necesaria para la produccinde este tipo de archivos, denominadas lenguajes de definicin de datos ( LDD),adems de lenguajes de manipulacin de datos ( LMD) para interrogar la base dedatos.

El catlogo es un archivo creado y mantenido por el SABD, en el que se mantienenlas caractersticas fsicas de los datos de la base de datos. Estas caractersticas sonusadas por el SABD en la traduccin y ejecucin de aplicaciones computacionales. lcatlogo es producido por un conjunto de rutinas del SABD mediante lasdescripciones proporcionadas por el ASABD. Para ser accesado por otro conjunto derutinas 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 deseguridad, fecha de origen, archivo de residencia, modo de acceso yalmacenamiento.

B. Administrador de SABD

La persona encargada de esta funcin tiene la responsabilidad de la implementacin yoperacin 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 lasfacilidades 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 SABD7. 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 delSABD, 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.


15/98

15

3. Crear y mantener un diccionario de datos4. 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 siguientesactividades:

1. Coordinacin y apoyo en el desarrollo de SIAS para que estos aprovechen lasfacilidades del SABD y la BD.

2. Mantener el contacto con los proveedores del SABD y de otros SABD3. Mantener informacin para los usuarios respecto de la organizacin de la BD.4. Mantener un control total sobre el DDL5. Definir las caractersticas e identificacin de los datos6. 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 datos10.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 empleado13.Definicin de procedimientos de proteccin contra destruccin o accesos no

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 de

seguridad e integridad, buscando la identificacin del causante e informando a losniveles que corresponda.

B. Diccionario de datos ( DD)Este elemento del enfoque de base de datos es el conjunto centralizado de atributos lgicosque 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 lgicosde dichos datos.


16/98

16

Entre las ventajas del DD se tiene:

1. Es un medio centralizado de tener informacin sobre los atributos lgicos de losdatos de la BD.

2. Es un medio de estandarizacin en el manejo y uso de los datos3. 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 desarrollode un SIA.

5. Permite introducir procedimientos estandarizados en le manejo de datos, informes ydocumentacin de procesos y aplicaciones.

Los usuarios del DD son: el AI, el SABD, usuarios finales, Analistas de Sistemas yprogramadores entre otros.

El diccionario de datos contiene para cada dato los siguientes atributos lgicos o metadatos:

Informacin respecto de: identificacin, control administrativo, seguridad, validacin ysobre 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 locontiene por primera vez en la organizacin, las unidades organizacionales y programasde aplicacin que lo usan, Cardinalidad del dato.

Atributos de seguridad identificacin de las personas autorizadas para cambiar lascaractersticas del dato, accesarlo o actualizarlo, fecha de ltima actualizacin eidentificacin del usuario que efectu esta actualizacin.

Atributos de validacin contienen lista o rango de valores permitidos, nombre de losprogramas validadores que actan sobre l.

Atributos de relaciones lgicas algoritmos de derivacin, identifica la forma de generacindel 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.


17/98

17

Beneficios y riesgos de usar Banco de Datos.

Un banco de datos esta constituido por todos los datos formales, relevantes para latoma de decisiones. Los datos del banco de datos se encuentran dispersos en laorganizacin 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, almacenadosen archivos centralizados altamente disciplinados, de tal forma que puedan serrequeridos de diversas maneras lgicas, con el fin de satisfacer las consultas de losdistintos usuarios de la base de datos.

Los beneficios del banco de datos son amplios y casi innumerables, el banco dedatos como se sealo en l prrafos anteriores representa toda la informacinrelevante y formalizada de la organizacin, entindase por datos de la constitucin dela empresa hasta los relativos al pago de patentes pasando por datos de acreedoresy deudores.

El riesgo del banco de datos es que el volumen de informacin va aumentandopaulatinamente y se hace inmanejable si no es vertida a un sistema de base dedatos.

1.3 Concepto Data Warehouse

La traduccin literal es almacenamiento de datos. Como es sabido existen muchoslugares donde podemos buscar datos, pero ha surgido la idea que exista unmayorista al interior de la empresa que acumule toda la informacin, bodega dedatos inteligente.

Existen muchas definiciones de DW, pero la ms completa es la de Bill Inmn, la cualdice: Data Warehouse es una tecnologa orientada a temas especficos, integrada,variante con el tiempo y es una coleccin no voltil que soporta la administracin delproceso 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 nuevasformas de solucionarlos, la idea de DW data de hace mucho tiempo pero la razn deque hoy da sea un tema de actualidad es que hoy existen tecnologas de HW y SWsuficientemente poderosas para depurar esta informacin.

l porque se asocia a la necesidad de mejorar la informacin analtica a travs deun medio computacional, la mayora de la informacin til en una empresa


18/98

18

est encerrada en viejas aplicaciones y los usuarios crean que bastaba con crearnuevas formas de acceso pero no es as porque adems tienen las siguientescaractersticas, complejidad en la estructura de los sistemas, diseo de sistemasorientados al rendimiento ptimo, informacin dependiente, informacin a menudodispersa en mltiples o diversos sistemas, definicin inconsistente y la solucin fue crearun 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 comosoporte a la toma de decisiones.

Su creacin se ha estimulado gracias a la necesidad de sistemas de informacin queapoyen la toma de decisiones de una organizacin.


19/98

19

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 deregistros, los cuales estn conectados entre s por medio de enlaces. El registro es similar alde una entidad como las empleadas en el modelo entidad relacin.

Un registro es una coleccin de campos (atributos), cada uno de los cuales contienesolamente almacenado un solo valor, el enlace es la asociacin entre dos registrosexclusivamente, as que podemos verla como una relacin estrictamente binaria.

Una estructura de datos de red, llamada algunas veces estructura de plex, abarca ms que laestructura de rbol porque un nodo hijo en la estructura red puede tener ms de un padre. Enotras 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 casoespecial de la estructura de red tal como lo muestra la siguiente figura. Para ilustrar lasestructura 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 = recordnombreA: string[30];control: string[8] ;esp: string[3]

end;

type material= recordclave: string[7]nombreM: string[25]cred= string[2];

end;


20/98

Ejemplo de una base de datos en red:

Base de Datos Jerrquicas:

En este tipo de bases de datos la informacin se distribuye en distintos nivelessegn su importancia estructural: por ejemplo de la entidad automvil, depende laentidad 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. Tienedos 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 formade un grafo arbitrario, mientras que el modelo jerrquico en forma de un rbol conraz.

Las reglas para la formacin de rbol son:

1. No hay ciclos2. 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 dediagramas de estructuras de rbol. Para cada diagrama existe una nica instanciade rbol base de datos. La raz de este rbol es un nodo ficticio. Los hijos de esenodo son instancias del tipo de registros adecuados:

20

11234 lvarez Rosa

21344 Rivera Juan

23456 Ros Mara

6 Cois 5100

1 Cois 5100

7 Cois 5120

8 Cois 5130


21/98

Ejemplo de una base de datos jerrquica:

Base de Datos Relacional:

Base de datos en la cual la informacin est almacenada en forma de tablas, yque permite establecer relaciones entre distintas entidades por medio de camposen comn; por ejemplo, cdigo de cliente en factura y en archivo de clientes.

Ejemplo de una base de datos relacional:

21

11234 lvarez Rosa 23456 Ros Mara

21344 Rivera Juan

1 Cois 5100 7 Cois 5120

6 Cois 5100 7 Cois 5120 8 Cois 5130

Seccin Curso1 Cois 51006 Cois 51007 Cois 51208 Cois 5130


22/98

N Est. Apellido Nombre Seccin11234 lvarez Rosa 121344 Rivera Juan 621344 Rivera Juan 723456 Ros Mara 7

23456 Ros Mara 8

22

Diferencia entre modelos relacional, red y jerrquico:

Los modelos relacionales se diferencian de los modelos de red y jerrquico en que nousan puntaros o enlaces. En Cambio el modelo relacional conecta los registros mediantevalores 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 objetocontiene valores almacenados en instancias dentro del objeto. Estos valores son objetospor si mismo, esto es, los objetos contienen objetos a un nivel de anidamiento deprofundidad arbitraria.Un objeto tambin contiene partes de un cdigo que operan sobre el objeto, estas partesse llaman mtodos.

Los objetos que contienen los mismos tipos de valores y los mismos mtodos se agrupanen 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 ocurreen 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 propiaidentidad nica independiente de los valores que contiene. As, dos objetos que contienenlos mismos valores son, sin embargo, distintos. La distincin entre objetos individuales semantiene en el nivel fsico por medio de identificadores de objeto.

2.2 Naturaleza del dato

La percepcin del mundo puede ser descrita como una sucesin de fenmenos. Desde elcomienzo de los tiempos el hombre ha tratado de descubrirlos, ya sea que los entiendacompletamente o no.

La descripcin de estos fenmenos es llamado Dato. Los datos corresponden al registrodiscreto (no continuo) de hechos acerca de un fenmeno, con lo cual ganamos informacinacerca del mundo que nos rodea (Informacin: Incremento del conocimiento que puede serinferido de los datos).

Usualmente el dato y su significado son registrados juntos, ya que el lenguaje natural es losuficientemente poderoso para hacerlo. Por ejemplo, el Kilo de pan cuesta $460 registrael 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 denotas es una tabla de datos. Su interpretacin implcita y se supone que quien la leeconoce su significado.

El uso del computador para procesar datos ha trado consigo una mayor separacin entrelo 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 notiene 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 manualexterno al computador.

En muchos sistema la interpretacin de datos se encuentra en los programas que hacenusos 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 conellos. As los datos no slo son valores, si no que tambin tienen una semntica y lo datosestn ms cerca de la interpretacin del mundo. Ellos forman


23/98


24/98

24

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 deldominio al que est asociado.


25/98

2.6Tipos de relaciones.

Uno a Uno:

Relaciones uno a uno (1:1). Una entidad A est asociada a lo ms con unaentidad B, y una entidad B a lo ms con una entidad A. Ejemplo: Ser jefe dees 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 ovarias entidades B. Una entidad B, sin embargo, puede estar a lo msasociada con una entidad A. Ejemplo: Ser profesor es una relacin 1: n entreprofesor 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 ovarias entidades B, y una entidad B est asociada con una o varias entidadesB, y una entidad B est asociada con una o varias entidades A. Ejemplo: Estarinscrito es una relacin n : m entre las entidades alumno y curso

25

Dominio

ATRIBUTO

Unidad 3: Modelos de Datos.

Es aparente que una representacin del mundo es necesaria, la que debe ser suficientementeabstracta para que no sea afectada por la dinmica del mundo (los pequeos cambios), y debeser 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 formams o menos razonable alguna realidad. El modelo de datos permite realizar abstracciones delmundo, 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 losvalores 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 quenos interesa. As un modelo captura la cantidad de conocimiento tal que cumpla con losrequerimientos que nos hemos impuesto previamente.

Un Modelo de Datos define las reglas por las cuales los datos son estructurados. Estaestructuracin sin embargo, no da a una interpretacin completa acerca de los significados delos datos y la forma en que sern usados. Las operaciones que se permiten efectuar a los datosdeben ser definidos..

3.1 Niveles de Abstraccin de los datos

La mayora de las aplicaciones son dependientes de los datos; la organizacin delalmacenamiento y los modos de acceso dependen de los requerimientos de la aplicacin y elconocimiento de la organizacin fsica de los datos y las tcnicas de acceso forman parte de lalgica de la aplicacin. La aplicacin es dependiente de los datos, porque no se puede mejorarla 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 losdetalles de almacenamiento fsico (como se almacenan y se mantienen los datos) peroestos deben extraerse eficientemente.

Independencia de los datos:La independencia de los datos es la capacidad de un sistema para permitir que las referenciasa 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, comopueden ser la forma de almacenar dichos


26/98

26


27/98

datos, el modo de compartirlos con otros programas y como se reorganizan paramejorar el rendimiento del sistema de bases de datos.

Para conseguir esta independencia entre los datos y las aplicaciones es necesarioseparar la representacin fsica y lgica de los datos, distincin que fue reconocida

oficialmente en 1978, cuando el comit ANSI/X3/SPARC propuso un esqueletogeneralizado para sistemas de bases de datos. Este esqueleto propone unaarquitectura de tres niveles, los tres niveles de abstraccin bajo los que podraverse una base de datos: el nivel interno, el nivel conceptual y el nivel externo.

Los tres niveles de la arquitectura ANSI/X3/SPARC

27

NE 1 NE 2 NE 3 NIVEL EXTERNO

NIVEL

CONCEPTUAL

NIVEL INTERNO

NE 1 NE 2 NE 3 NIVEL EXTERNO

NIVEL

CONCEPTUAL

NIVEL INTERNO

Los tres niveles de la arquitectura ANSI/X3/SPARC

Nivel Interno: En el se define la estructura fsica de la base de datos: dispositivos dalmacenamiento fsico, direcciones fsicas, estrategias de acceso, relaciones, ndicesapuntadores, etc. Es responsabilidad de los diseadores de la base de datos fsicaNingn usuario, en calidad de tal, tiene conocimiento de este nivel.

Nivel Conceptual: Contiene el nivel conceptual de la base de datos, que implica e

anlisis de las necesidades de informacin de los usuarios y las clases de datonecesarias para satisfacer dichas necesidades. El resultado del diseo conceptuacontiene la descripcin de todos los datos y las interrelaciones entre ellos, as como larestricciones de integridad y de confidencialidad.


28/98

28

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 vistasse derivan directamente del esquema conceptual, o de otras vistas, y con tienen unadescripcin de los elementos de datos y sus interrelaciones orientadas al usuario oaplicacin y de las que se compone la vista. Una misma vista puede ser utilizada porvarias aplicaciones.

Esta arquitectura de tres niveles nos proporciona la deseada independencia, que definiremoscomo capacidad para cambiar el esquema en un nivel sin tener que cambiarlo en ningn otronivel. Distinguimos entre independencia fsica y lgica:

Independencia lgica de los datos: Cambio del esquema conceptual sin cambiar las vistasexternas o las aplicaciones.

Independencia fsica de los datos: Cambio del esquema interno sin necesidad de cambiarel 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 delas 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, entendindosepor ocurrencia de una entidad o instancia de un objeto, al producto de asociar valores a losatributos 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 ydbiles, 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 ladependencia en identificacin.


29/98

29

Dependencia en existencia: Cuando la ocurrencia en un tipo de entidad dbil no puede existir sdesaparece la ocurrencia de la entidad fuerte de la que depende.

Dependencia en Identificacin: Cuando, adems de ser una dependencia en existencia laocurrencias de la entidad dbil no pueden identificarse nicamente mediante los atributos propio

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 sistemaactuales 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 elas tres categoras siguientes: Jerrquica , Red y Relacional.

Cualquier categora del DBMS debe permitir un acceso aleatorio a los datos requeridosutilizando para tal fin una de las siguientes estructuras lgicas para almacenar los datosredes, rboles, tablas o listas enlazadas.

Cada DBMS esta diseado para manejar un tipo determinado de estructura lgica. Loprogramas 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 laespecificaciones del grupo de trabajo de base de datos (DBTG) de CODASYL. Enfoque Relacional: System R y QBE de IBM, MAGNUM de Tymshare, ORACLE otros.


30/98

30

Enfoque Jerrquico

Un DBMS de enfoque jerrquico utiliza RBOLES para la representacin lgica delos datos.

A los archivos que entre sus registros guardan una relacin tipo rbol se les llamaArchivos Jerrquicos.

La figura siguiente muestra una estructura en rbol con 4 tipos de registros:

SUCURSAL

AUTOMOVILEMPLEADOSFECHA-MANTENIMIENTO

Que representan las sucursales filiales de una empresa, los automviles asignadosa cada una de ellas, los empleados que deben conducir un determinado coche y lafecha de mantenimiento. El registro SUCURSAL contiene los campos NUMERO-SUCURSAL, NOMBRE-SUCURSAL, NOMBRE-CIUDAD, etc.; el registro AUTOMOVILincluye los datos de los coches; el registro EMPLEADO, los datos personales delmismo: NUMERO, NONBRE, etc. y, por ltimo el registro FECHA-MANTENIMIENTO

contiene los campos FECHA, OPERACIN.

Ver figura Anexa.


31/98


32/98

El anexo siguiente muestra un rbol compuesto por una jerarqua deelementos llamados nodos. Los rboles se dibujan con la raz arriba y lashojas abajo

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 )

El Enfoque de Red

32

A

B

G

C D

HF

E

Nivel 1: Raz

Nivel 2

Nivel 3

Estructura de un rbol


33/98

Una estructura de datos en RED, tambin llamada estructura PLEX, secaracteriza porque cada nodo hijo puede tener ms de un padre, a diferenciade la estructura en rbol en la que un hijo slo poda tener un padre.

El nodo C tiene dos padres A y B. Lo mismo sucede con en nodo Hcuyos padres son D Y E

33

A B

G

C

D

H

F

E

I J

Estructura de red

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 comolos lenguajes para el manejo de los datos. Pero todava no se ha considerado un aspectofundamental 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 mnimode 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 aformar parte de la base de datos y reunirlos en una relacin universal. Hastaque se hayan concretado los campos necesarios no podr el diseadorestablecer 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 losproblemas de actualizacin y borrado.

Orientado a Objeto

El Modelo Orientado a Objetos se basa en el paradigma de programacin orientada aobjetos. Este paradigma ha tenido gran aceptacin debido a que es de gran naturalidadbuscar objetos en la realidad a modelar.

Estructura de objetos.El Modelo orientado a objetos se basa en encapsular cdigo y datos en una nica unidadllamada objeto. La Interfaz entre un objeto y el resto del sistema se define mediante unconjunto de mensajes.

El motivo de este enfoque puede ilustrase considerando una base de datos de documentosen la que los documentos se preparan usando uno entre varios paquetes software conformateador de texto. Para imprimir un documento debe ejecutarse el formateador correcto enel documento. Bajo un enfoque orientado a objetos cada documento es un objeto quecontiene el texto de un documento y el cdigo que opera sobre el objeto.


34/98

34

Todos los objetos del tipo documento responden al mensaje imprimir, pero lo hacen de formadiferente. 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 deun 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 decdigo 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 queresponde, 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 elnmero 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 estconsiderada como una de las mayores ventajas del modelo de programacin orientada aobjetos.

Entidad - Relacin

En 1976, Peter Chen public el modelo entidad relacin, el cual tuvo gran aceptacinprincipalmente por su expresividad grfica. Sobre esta primera versin han trabajado

numerosos autores, generando distintas extensiones de mayor a menor utilidad y deaceptacin variable en el medio acadmico y profesional. Muchas de estas extensiones sonmuy tiles, pero poco difundidas debido principalmente ala ausencia de herramientasautomatizadas 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 entidades2. Identificar los tipos de Interrelaciones3. Encontrar las cardinalidades


35/98

35

4. Identificar los atributos de cada entidad5. Identificar las claves de cada tipo de entidad

La regla bsica es distinguir tipos de entidades e interrelaciones de atributos. As, losatributos deben ser atmicos y caractersticos del tipo entidad o interrelacin quedescriban.

Tambin los atributos deben pertenecer al tipo de entidad o interrelacin que describeny no a otro tipo.

Otra diferencia entre tipo entidad y atributo es que, por ejemplo, se puede tener el tipode entidad empleado, que tiene como atributo el departamento al que pertenece. EnForma alternativa se pueden tener los tipos de entidades Empleado y Departamento, yel tipo de interrelacin trabaja_en, que relaciona a un empleado con el departamentoen donde trabaja.

Esta segunda alternativa es mejor desde el punto de vista del modelamiento conceptualy 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 tiposde entidad).

2. En los tipos de interrelacin, la clave es la composicin de las claves de los tiposde entidad involucrados, en caso que no se pueda utilizar la clave de unsubconjunto 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 alumnosy la hora y el lugar de las clases. Para cada par estudiante asignatura seregistra su nota.

2. Construir un esquema MER para una compaa de seguros de autos con unconjunto de clientes, cada uno de los cuales es propietario de un nmero deautos. Cada auto tiene asociado el nmero de accidentes asociados.

3. Construir un esquema MER para modelar la documentacin requerida para unesquema conceptual E R.


36/98

3.12 Normalizacin

36


37/98

Se entiende por normalizacin la descomposicin o subdivisin de una relacin endos o ms relaciones para evitar la redundancia; en definitiva, que cada hechoest 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 unDBMS jerrquico o de red.

La relacin universal

Supongamos que se desea implantar en una base de datos las ventas de unadeterminada empresa a sus clientes por la relacin ORDENES-VENTA (NCLI,NOMBRE, LOCALIDAD, CT, NART, ARTICULO, CANT, PVP, FECHA), dondeNCLI es el nmero del cliente, CT es el costo de transporte y NART el nmero deartculo. La implantacin, tal como indica la Figura 1, no se puede realizar debido ala gran cantidad de informacin redundante y los problemas que surgen a la horade las actualizaciones.

Relacin ORDENES-VENTA

NCLI NOMBRE LOCALIDAD CT NART ARTICULO CANT PVP FECHA1111114455

LuisLuisLuisAnaJos

MlagaMlagaMlagaGijnValencia

0.80.80.81.11.4

A1A3A9A1A4

PapelCintaDiscoPapelGrapas

100502510030

5500200550

3/55/57/510/53/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 esfuncin de X si el valor de Y est siempre determinado por el valor de X.

Tanto A como B pueden ser un conjunto de atributos en lugar de atributos simples.

37

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 deB, 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 B


38/98

La dependencia funcional establece condiciones entre atributos pertenecientes ala misma relacin. No permite establecer condiciones entre atributospertenecientes a la misma relacin. No permite establecer condiciones entreatributos de diferentes relaciones.

Las DF se determinan al estudiar las propiedades de todos los atributos de larelacin y deducir cmo estn relacionados los atributos entre s.

La dependencia funcional est ntimamente ligada con el concepto de clave. Parael diseo, las claves aparecen subrayadas.Se pueden distinguir los siguientes tipos de claves:

Para encontrar la clave candidata es preciso estudiar las dependenciasfuncionales y, a partir de ellas, obtener el mnimo conjunto posible de atributostales que, una vez conocidos sus valores en la tupla, los dems queden definidos

NCLI NOMBRENCLI LOCALIDADEn forma abreviada:NCLI (NOMBRE, LOCALIDAD)

La proposicin NCLI NOMBRE se lee: el atributoNOMBRE es funcionalmente dependiente del atributo NCLI, o tambin: elatributo NCLI determina funcionalmente al atributo NOMBRE.

La proposicin NCLI (NOMBRE, LOCALIDAD) se puede

leer: el atributo compuesto formado por NOMBRE y LOCALIDAD esfuncionalmente 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

38

Clave candidata: Conjunto de uno o ms atributos que podra ser utilizado como claveprincipal de una relacin.

Superclave: Conjunto de uno o ms atributos que, juntos, permiten identificar de formanica a una entidad dentro de una relacin.

Clave principal: Es una clave candidata en la que ningn componente puede tomar elvalor nulo.

Consideremos la relacin CLIENTES: NCLI, NOMBRE, LOCALIDAD, donde NCLI es elnmero del cliente. Los campos NOMBRE y LOCALIDAD son funcionalmentedependientes de NCLI: Para un valor de NCLI existe un nico valor de NOMBRE yLOCALIDAD. Se expresa:

LOCALIDAD asociados a l. NCLI es una superclave. Sin embargo, el NOMBRE no es undeterminante de la LOCALIDAD, ya que puede haber varias personas con igual nombre enciudades diferentes o en la misma ciudad.


39/98

Es conveniente representar las DF de una relacin en un diagrama dedependencia funcional; en el ejemplo anterior:

NOMBRE NOMBRE

LOCALIDAD LOCALIDAD

39

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.

NCLI o NCLI

El diagrama de dependencia funcional para la relacin ORDENES-VENTA se muestraen 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.

NOMBRE, LOCALIDAD, CTNCLI

NART

FECHA

CANT ARTICULO, PVP

Figura 2 Diagrama de dependencia funcional

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


40/98

NCLI NOMBRE LOCALIDAD CT NART ARTICULO CANT PVP FECHA11 Luis Mlaga 0.8 A1 Papel 10050

55

3/55/5

NCLI NOMBRE LOCALIDAD CT NART ARTICULO CANT PVP FECHA

1111

LuisLuis

MlagaMlaga

0.80.8

A1A3

PapelCinta

10050

5500

3/55/5

40

se puede normalizar con la creacin de un registro nuevo por cada uno de los distintosvalores de un campo, tal que permita expresar la relacin como una tabla

Una relacin en 1FN contiene una serie de anomalas de almacenamiento a la horade realizar las actualizaciones por la informacin redundante, como se puede apreciaren la Figura 1.

NORMALIZACIN DE LA RELACIN 1FN

Las anomalas de almacenamiento, que se deben a la presencia de campos no clave en larelacin, 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 paradefinir cada uno de los campos no clave.

Al proceso de dividir cualquier relacin en dos o ms relaciones se llama proceso denormalizacin. Consiste en reemplazar las relaciones por proyecciones adecuadas, de talforma que la reunin natural de las proyecciones genere la relacin original, es decir, que no seproduzca prdida de la informacin. Incluso las nuevas relaciones pueden contener informacinque no se poda representar originalmente (un nuevo registro en alguna de las nuevasrelaciones), pero siempre conservando las dependencias funcionales.

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 nova 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 larelacin.

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.


41/98

41

Los diagramas y las nuevas relaciones aparecen descritas en la figura siguiente.


42/98

Relacin Clientes NCLI Nombre, Localidad, CT

Relacin Artculos NART Artculo, PVP

Relacin Ventas NCLINART CANTFECHA

a) Diagramas de dependencias funcionales

Relacin CLIENTES

NCLI NOMBRE LOCALIDAD CT

11 Luis Mlaga 0.844 Ana Gijn 1.155 Jos Valencia 1.4

Relacin ARTICULOS Relacin VENTAS

NART ARTICULO PVP

A1 Papel 5A3 Cinta 500A4 Grapas 50

A9 Disco 200

b)Registros de las relaciones

NCLI NART CANT FECHA

11 A1 100 3/511 A3 50 5/511 A9 25 7/544 A1 130 10/555 A4 30 3/5

42

RELACION 1FN NORMALIZADA


43/98

Dependencia transitiva

Supongamos la relacin R(A,B,C). Si A B, B C y

B 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 Asi se tiene la siguiente situacin:

Relacin R A B, C

Se puede descomponer en dos relaciones por la proyeccin del ltimo eslabn dela forma;

Relacin R1 A B

Relacin R2 A C

43

SEGUNDA FORMA NORMAL: 2FN

Una relacin est en segunda forma normal s, y slo s:

1. Est en 1FN2. 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, larelacin CLIENTES presenta anomalas de almacenamiento debido a que el atributo CT esfuncionalmente dependiente de LOCALIDAD, que a su vez depende de NCLI; es decir, hayuna 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.

Normalizacin de la relacin 2FN

Las anomalas de almacenamiento, originadas por la dependencia transitiva en una relacin2FN, se puede normalizar mediante los siguientes pasos:

1. En una relacin, determinar el atributo que es funcionalmente dependiente de unatributo no clave y dibujar el diagrama de dependencia funcional.


44/98

Relacin Clientes NCLI Nombre, LocalidadRelacin Transportes LOCALIDAD CT

Relacin Artculos NART Artculo, PVP

Relacin Ventas NCLINART CANTFECHA

a) Diagramas de dependencias funcionales

44

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 semuestran en la figura 13.4. Han desaparecido las anomalas surgidas por la dependenciatransitiva, como se puede comprobar al dar de alta un nuevo registro en la relacinTRANSPORTE, aunque no haya ningn cliente de esa ciudad.

Relacin CLIENTES

NCLI NOMBRE LOCALIDAD

11 Luis Mlaga44 Ana Gijn55 Jos Valencia

Relacin TRANSPORTES

LOCALIDAD CT

Mlaga 0.8Gijn 1.1Valencia 1.4

b) Registros de las relaciones CLIENTES Y TRANSPORTES

RELACION 2FN NORMALIZADA


45/98

45

TERCERA FORMA NORMAL: 3FN

Una relacin est en 3FN s, y slo s:

1. Est en 2FN2. 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 otroatributo. Existe una excepcin: Cuando en una relacin hay dos atributos que podra ser laclave, como el DNI y l nmero de la seguridad social.


46/98


47/98

PROCESOS DE APOYOGestin de recursos humanosGestin de adquisicionesGestin de recursostecnolgicosGestin de logstica de entradaGestin de operaciones

Gestin de logstica de salidaGestin de ventasGestin de servicioPROCESOS PRINCIPALES

47

Todo proceso tiene entradas -recursos humanos, tecnolgicos, materiales y otros-para el desarrollo de las actividades que lo conforman; como salidas se esperanproductos, servicios, informacin, activos financieros u otros. Si bien la distincinentre actividad y proceso no es ntida, por lo general un proceso es visto como unconjunto de actividades o una macro actividad.

Otra definicin, entiende todo proceso como un "conjunto de tareas lgicamenterelacionadas que existen para obtener un resultado bien definido dentro de unnegocio". En adelante nos basaremos en esta ltima definicin.

El concepto de la Cadena de Valor es la herramienta bsica para examinar todaslas actividades que una empresa desempea. Bajo ese enfoque, los procesos sonclasificados en principales y de apoyo. Los procesos principales estn directamenterelacionados con la actividad productiva de las organizaciones. Los procesos deapoyo son los que apoyan, asisten, respaldan a los procesos primarios; cuyasegmentacin se realiza en funcin de factores estratgicos, funcionales y

organizacionales. El resultado general de la segmentacin de procesos es elsiguiente:

Por tanto, los procesos principales seran los conjuntos de actividadesvinculadas a la creacin, venta, transferencia y asistencia posterior de productoso servicios; mientras que los de apoyo seran todos aquellos conjuntos deactividades que sustentan las actividades involucradas en los procesosprincipales proporcionndoles insumos, tecnologas, recursos humanos yvariadas funciones administrativas.

Modelo de Procesos por Regulacin

Uno de los modelos para representar los conjuntos de actividades asociados a losprocesos es el llamado Modelo de Procesos por Regulacin (MPR). El modelo asumeque el propsito de todo sistema de gestin es el de regular el comportamiento de losrecursos que manejan las organizaciones ante perturbaciones generadas por unentorno cambiante y


48/98

48

no controlable. Los recursos regulados son ingresados desde el entorno hacia laorganizacin, para ser "operados" o "transformados" en su interior y devueltos alexterior. Bajo este modelo es crucial identificar los recursos que interesan regular, quepueden ser recursos materiales, humanos u otros.

A modo de ejemplo, para la organizacin de una conferencia de informtica, un recursoque interesar regular seran los trabajos que se presenten. Con propsitos de"regulacin" interesar informacin ms all del contenido del "trabajo" propiamente tal:

Las operaciones o actividades que se ejecutan sobre los recursos son las queestn sometidas a regulacin. Por tanto, a nivel de actividades suelen

distinguirse aquellas que producen bienes / servicios (actividades fsicas) de lasactividades que las regulan (actividades administrativas). Lo anterior implica quea nivel de los flujos existen los fsicos y los de informacin. Los flujos fsicos sonaquellos asociados a los recursos que se aspira regular a travs de los flujos deinformacin. Ejemplos de flujos fsicos pueden ser flujos de materiales, dedinero, de personas, de documentos, etc. Las actividades que tienen comoentrada los flujos fsicos modifican el estado de los recursos involucrados paradar origen a productos / servicios. Las actividades administrativas que regulanestos 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 opersonas que originan o reciben los flujos fsicos de entrada / salida, en tantoque lo sistemas externos son aquellos con los cuales s interacta y que incidenen la toma de decisiones.

La siguiente figura presenta la estructura bsica de un ciclo clsico deregulacin, observndose que las actividades administrativas puedendescomponerse en las orientadas a registrar los cambios de estado que


49/98

49

experimenta el recurso regulado, y aquellas orientadas a tomar decisiones que impliquenacciones sobre las actividades fsicas llevadas a cabo

Sistemas de Informacin

Se entender por sistema de informacin al conjunto de componentes interrelacionados quoperan conjuntamente para capturar, procesar, almacenar y distribuir informacin que apoyla toma de decisiones, la coordinacin, el control y anlisis en una organizacin. Segn enivel organizacional al cual los sistemas satisfacen y su valor para la organizacin, los tipos dsistemas que interesarn son:

de Procesamiento de Transacciones (SPT): registran las transacciones rutinarias denegocio y que sirven para el nivel operacional de las organizaciones.

de Apoyo a las Decisiones (SAD): estn a nivel de gestin de las organizaciones, 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 laorganizaciones, y apoyan las funciones de planificacin y control para proveer informede resumen y de excepcin; dependen de datos proporcionados por los SPT.

de Apoyo Ejecutivos (SAE): estn a nivel estratgico de la organizacin diseados parapoyar las decisiones no estructuradas y crear un entorno generalizado dautomatizacin y comunicaciones de redes; son sistemas que incorporan informacide eventos externos, tales como polticas impositivas, comportamientos de lcompetencia.


50/98

50

Metodologa

Para estructurar un sistema de informacin orientado a satisfacer requerimientos

estratgicos de las organizaciones se desarroll una metodologa, apoyada en elmodelamiento 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 msrelevantes dentro de una organizacin, diferenciando los principales y los de apoyo. Enesta etapa se deben tomar en consideracin la misin y los objetivos estratgicosfijados en la organizacin.

Etapa 2: Seleccin de procesos

Cumplido lo anterior se seleccionan aquellos en los que interesa focalizar los esfuerzosy recursos disponibles. Entre las herramientas de apoyo utilizadas en esta fase seencuentran el anlisis FODA (Fortalezas/Oportunidades/Debilidades/Amenazas) y losFCE (Factores Crticos de xito).

Etapa 3: Descomposicin de procesos

A continuacin se identifican los recursos a regular, los subprocesos fsicos queafectarn al recurso involucrado, y los administrativos o de gestin que regularn elcomportamiento de los subprocesos fsicos.

Etapa 4: Estructuracin del sistema de informacin

Cada uno de los subprocesos administrativos da origen a tres subsistemas deinformacin: de procesamiento de transacciones, de informacin administrativa, y deapoyo a las decisiones. El primero captura las transacciones que den cuenta de loscambios de estado del recurso que se est regulando; el segundo apoya las funcionesde planificacin y control; el tercero apoya el proceso de toma de decisiones. Sobre latotalidad de estos subsistemas se implementa el sistema de apoyo ejecutivo conpropsitos 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 niveloperacional, tctico y estratgicos.


51/98

51

4.3. Obtencin del Modelo Corporativo

Una sola visin de la base de datos puede describirse mediante un modelo. Unmodelo de visin representa un pequeo subconjunto de la realidad, apropiado parauna aplicacin del contenido de la base de datos. La mayora de las bases de datospara especificarse requerirn varios modelos de visin. El estrecho enfoque de visinpor visin para comprender la estructura de una base de datos tiene la ventaja de quela complejidad de los vnculos que se presentan en las bases de datos del mundo realpuede dominarse.

Cuando se ha establecido un conjunto comprensivo de modelos de visin, es posibleestablecer la construccin de un modelo para toda la base de datos. Se combinanrelaciones provenientes de modelos separados de visin con base en los atributos quetengan en comn. Si los modelos de visin no tienen atributos en comn no se obtieneningn beneficio al unir estos datos en un solo modelo de base de datos.

Aunque haya atributos comunes podra no haber conexiones. La falta de conexionesindica que las visiones o los grupos de visiones pueden mantenerseindependientemente unas de otras. A una base de datos creada a partir de visionesque no se conectan con otras bases de datos se les denomina base de datosindependiente, esta se mantiene mejor en forma distribuida, an cuando el equipo decomputacin sea compartido. Hay beneficios ( funcionales, geogrficos, desempeo,autonoma, confiabilidad, crecimiento) al efectuar distribucin, y si las bases de datospueden conservarse ms pequeas y manejarse en forma autnoma, probablementelos 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 quedenen una base de datos integrada. Actualmente slo unos cuantos sistemas de manejode base de datos permiten que se procesen consultas con acceso a ms de una basede datos. El costo de combinar bases de datos independientes consiste en un costoincrementado en demasa del sistema de base de datos, a fin de proporcionar laindependencia requerida del modelo de visin y la proteccin para las transacciones deactualizacin. Los costos de manejo, debidos al intento de volver comunitarias reas enlas que existen pocos incentivos naturales para cooperar, tambin pueden ser altos.

Ni siquiera deben integrarse todos los modelos conectados de visin. El enlace entrealgunos 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 debersea un atributo compartido, pero que no cambia. En esos casos tambin se disearnbases de datos


52/98

52

independientes de datos, con un procedimiento para mantener sincronizado el atributocompartido.

Por ejemplo, si los empleados estn identificados con un departamento, y la produccinde bienes con otro, la lista de departamentos podra proporcionar tal enlacerelativamente constante. Slo si los empleados se relacionaran con la produccin habraun acoplamiento suficientemente fuerte entre las dos reas para justificar la combinacinde modelos de visin.

La existencia de un atributo compartido que frecuentemente se actualice en dos modelosindependientes de otro modo, proporciona otro incentivo para combinar los modelos yevitar as esfuerzos redundantes de actualizacin.

Un ejemplo de base de datos centralizada se encuentra en los sistemas dereservaciones de lneas areas. Las relaciones bsicas que proporcionan ladisponibilidad 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 datosdistribuidas. Puede existir gran actividad en una sola fbrica, pero que no resulte deinters para todos los que trabajen en ella. Datos generales de entrada y salida, entrminos de materiales, dinero y productos, describen la fbrica en forma adecuadadesde un punto de vista externo.

Las decisiones referentes a distribucin se basan principalmente en la experiencia y laintuicin.

Hasta qu punto es ms conveniente la distribucin que la centralizacin?, depende delcosto de manejo de operaciones, comunicaciones y procesamiento.

Una base de datos distribuida no implica distribucin fsica sino ms bien una distribucinde responsabilidades a mltiples bases de datos.

Un sistema disperso puede estar bien integrado o distribuido. El costo de lascomunicaciones necesarias para un sistema integrado pero repartido en sitios remotoshar 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 unsubmodelo de base de datos. Este puede representar una sola visin o aumentarse ymodificarse para tener en cuenta informacin y datos provenientes de otras visionesincluidos en la base de datos. Un sitio tambin podra tener un modelo global integradode todos los datos en las bases distribuidas de datos.


53/98

53

Si una base de datos que opera en un sitio tiene derecho de acceso a datos provenientesde bases ubicadas en otros puntos, puede convenir tener disponible una copia en cadasitio del modelo global de base de datos, an cuando en ese sitio slo se almacenendatos para el submodelo local de base de datos. La capacidad de cambiar localmenteinclusive la parte local de un modelo de base de datos estar restringida ahora, ya quese vern afectados modelos remotos, aunque sus bases de datos no sean afectadas porel cambio de modelo.

Un ejemplo se presenta en los bancos, donde durante las horas de negocios, las basesde datos primarias se encuentran en las sucursales (submodelos). Despus del cierrediario, la correspondencia de los datos locales con los datos de la oficina central (modeloglobal) se verifica y se da la responsabilidad primaria al sitio central. Durante la noche, labase de datos central puede actualizarse rpidamente con transacciones que llegan deotros bancos a la oficina central. Los mensajes de actualizacin se comunican a lassucursales. En la maana la responsabilidad pasa a las sucursales, despus de unaverificacin de integridad.

Se observa que la creacin de submodelos de bases de datos implica la existencia de unmodelo integrado de bases de datos (modelo corporativo) aun cuando los datospuedan no estar integrados. En una base de datos distribuida puede existir un esquemaglobal basado en el modelo integrado de base de datos que ayude a las consultasglobales.

Una vez que se ha decidido cules modelos de visin se incluirn en uno slo, es posibleconstruir el modelo integrado de bases de datos, que consistir en relaciones de variostipos y en las conexiones entre dichas relaciones. La combinacin puede tener el aspectode 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 cuentaalgunos objetivos:

1. Obtener relaciones con el mayor grado de claridad semntica.2. Conservar la independencia de visin para simplificar la distribucin posterior.3. Tener el menor nmero de relaciones.4. Tener el menor nmero de tuplas.5. Hacer que el nmero de datos almacenados sea mnimo.6. 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 entrerelaciones.


54/98

54

Se han estudiado reglas para establecer una situacin ptima de acuerdo con los ltimcuatro criterios, utilizando dependencias funcionales entre atributos como elementos bsicpara la toma de decisiones. En muchos casos prcticos los diseos de bases de datsustentados en cualquiera de los criterios no diferirn mucho.

La claridad semntica aumenta cuando se agrupan aquellos atributos fuertemenrelacionados, y esto puede lograrse con un nmero limitado de relaciones y conexiones interrelacin. A menudo la normalizacin habr aumentado el nmero de tuplas y reducidonmero de datos almacenados. La integracin puede reducir el nmero total de tuplascombinarlas, pero normalmente aumenta el nmero total de relaciones y sus conexiones.

El modelo integrado de base de datos puede ser complejo, pero presenta una descripciprecisa de las necesidades del usuario.

Algunas veces es mejor adaptar el submodelo de base de datos a un subconjunto propio debase integrada, ya que esto puede proporcionar una visin ms realista de la operacin y s

restricciones. Cuando los submodelos de base de datos son subconjuntos del modelo de bade 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 generalidad. Una clasificacin de estos enfoques en tres niveles distingue los sistemas qapoyan a una sola aplicacin, a varias aplicaciones del mismo tipo o a mltiples tipos aplicaciones. Se han desarrollado algunos sistemas a travs de estos tres niveles; otros

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 facilidaddisponibles de sistema de archivo y disea programas de aplicacin que realizan una interfaa la base de datos utilizando un paquete mantenido centralmente que implanta el granecesario de descripcin de datos y de estructura.

El sistema original de reservacin de la lnea area American Airlines, SABRE, muchgrandes sistemas de informacin, tales como MEDLARS (sistema para consultar informac

mdica) y sistemas de comando y control militar son ejemplos de este enfoque.


55/98

55

Sistemas de bases de datos para varias aplicaciones del mismo tipo.

Un grupo de usuarios trabajando en cierto tipo de reas de aplicacin reconoce laexistencia de necesidades comunes. Ellos o su vendedor de equipo electrnico disean

un sistema que cubran sus necesidades. Las diferencias entre usuarios se incluyen entablas y esquemas especficos para cada usuario. A menudo, este ltimo paso se realizadespus de obtener xito con un sistema orientado ms bien a un solo objetivo.

Son ejemplos de este enfoque los sistema generalizados de reservacin de lneasareas (PARS), sistemas de informacin clnica (TOD, GEMS), y sistemas defacturacin 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 laintencin de que cubra las necesidades generales de la base de datos en una formamejor. Desde luego, habr cierta tendencia a subrayar aquellos aspectos relacionadoscon la experiencia de los diseadores de manera que en la prctica se encuentra unagran diferencia entre los sistemas generalizados. Otra fuente para los sistemasgeneralizados es una evolucin continuada a partir de servicios para una sola aplicacino del tipo de aplicacin.

Una orientacin hacia una aplicacin especfica o a un tipo de aplicacin permitereconocer vnculos semnticos difciles de explotar en un sistema generalizado. Sin

embargo, un sistema generalizado presenta un mejor equilibrio de los problemas en laimplantacin 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 lanecesidad 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 deentrega, adems de la calidad y mantenimiento del producto.

Segn Sommerville (1988) " un buen diseo es la clave de una eficiente ingeniera delsoftware. Un software bien diseado es fcil de aplicar y mantener, adems de sercomprensible y fiable. Los sistemas mal diseados, aunque puedan funcionar, serncostosos de mantener, difciles de probar y poco fiables".


56/98


57/98

57

El anlisis de requisitos debe responder a la pregunta: qu representar? Para ello hayque estudiar las reglas de la empresa (del negocio) a los diferentes niveles de laorganizacin, 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 losmodelos conceptuales. Nosotros utilizaremos el MER y sus extensiones, quebsicamente define entidades, atributos, interrelaciones y restricciones semnticas.Esquema conceptual.

En el paso del esquema percibido al esquema conceptual. No existen reglas claras quepermitan decidir que elemento es una entidad o cual otro una interrelacin. Existen 2enfoques.

Enfoque lingstico y categorizacin de objetos.

En el enfoque lingstico:

un sustantivo (nombre comn) que acta como sujeto o complementodirecto en un frase es por lo general un tipo de entidad, aunque podra ser unatributo. 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,Cindica 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 otambin establece la asociacin entre

Manual Base de Datos I V3.0

Documents

Transcript of Manual Base de Datos I V3.0