10 Cap 9 Planificacion, Diseño y administracion de bases de datos.pdf

arte

Técnicas de análisis ydiseño de bases de datos

Capítulo 9 Planificación, diseño y administración de bases de datos

Capítulo 10 Técnicas de determinación de hechos

Capítulo 11 Modelado entidad-relación

Capítulo 12 Modelado entidad-relación avanzado

Capítulo 13 Normalización

Capítulo 14 Normalización avanzada

(

Capítulo

Planificación, diseño yadministración de

bases de datos

Objetivos del capítulo:

En este capítulo aprenderá:

• Los componentes principales de un sistema de información.

• Las etapas principales del desarrollo de sistemas de bases de datos.

• Las fases principales del diseño de una base de datos: diseño conceptual, lógico y fisico.

• Las ventajas de las herramientas CASE (Computer-Aided Software Engineering, ingeniería del soft-ware asistida por computadora).

• Los tipos de criterios utilizados para evaluar un SGBD.

• Cómo evaluar y seleccionar un SGBD.

• La distinción entre administración de datos y administración de bases de datos.

• El propósito y las tareas asociados a la administración de datos y la administración de bases de datos.

El software ha sobrepasado al hardware como clave principal del éxito de numerosos sistemas informáticos.Desafortunadamente, el éxito de los proyectos de desarrollo de software no resulta particularmente impresionante. En las últimas décadas hemos visto la proliferación de aplicaciones software que van desde pequeñasy relativamente simples aplicaciones compuestas por unas pocas líneas de código, hasta grandes y complejasaplicaciones donde las líneas de código se cuentan por millones. Muchas de estas aplicaciones han requeridoa lo largo del tiempo un mantenimiento constante, lo que implicaba corregir los fallos detectados, implementar nuevos requisitos de usuario y modificar el software para que se ejecutara en plataformas nuevas o actualizadas. Poco a poco, el esfuerzo invertido en tareas de mantenimiento comenzó a absorber recursos a una tasacada vez más alarmante. Como resultado, muchos proyectos de software de gran envergadura se retrasaban,consumían todo el presupuesto disponible o generaban productos que eran poco fiables, difíciles de mantener

y con prestaciones muy bajas. Esttcondujo a lo que se denominó crisis del software. Aunque este términofue utilizado por primera vez a fina es de la década de los sesenta, la crisis continúa con nosotros cuarenta añosdespués. Como resultado, algunos utores se refieren ahora a la crisis del software con el nombre de depresión del software. Como indicativo de la crisis, un estudio llevado a cabo en el Reino Unido por OASIG, ungrupo de trabajo dedicado a los aspectos organizativos de las tecnologías de la información, llegó a lassiguientes conclusiones acerca de los proyectos software (OASIG, 1996):

• entre un 80 y un 90% no cumplen con los requisitos de prestaciones establecidos;

• cerca de un 80% se retrasan y sobrepasan el presupuesto asignado;

• alrededor de un 40% fracasan o se abandonan;

• menos de un 40% de los productos contemplan adecuadamente los requisitos de capacitación y formación;

258 Sistemas de bases de datos

• menos de un 25% de los proyectos integran adecuadamente los objetivos empresariales y tecnológicos;

• sólo entre un 10 y un 20% satisfacen todos los criterios de éxito establecidos.

Son varias las razones a las que atribuir este fracaso de los proyectos software, entre las cuales podemoscitar:

• la falta de una especificación de requisitos completa;

• la falta de una metodología de desarrollo apropiada;

• una pobre descomposición del diseño en una serie de componentes manejables.

Como solución a estos problemas, se ha propuesto un enfoque estructurado del desarrollo de software quese denomina ISLC (Information Systems Lifecycle, ciclo de vida de los sistemas de información) o SDLC(Software Development Lifecycle, ciclo de vida del desarrollo software). Sin embargo, cuando el software que se está desarrollando es un sistema de bases de datos, ese ciclo de vida se suele denominar, más específicamente DSDLC (Database System Development Lifecycle, ciclo de vida del desarrollo de sistemas debases de datos).

Estructura del capítuloEn la Sección 9.1 vamos a describir brevemente el ciclo de vida de los sistemas de información y a explicarcómo se relaciona este ciclo de vida con el del desarrollo de sistemas de base de datos. En la Sección 9.2 pre

sentaremos una panorámica de las etapas que componen el ciclo de vida del desarrollo de sistemas de basesde datos. En las Secciones 9.3 a 9.13 describiremos cada una de las etapas de ese ciclo de vida con mayordetalle. En la Sección 9.14 veremos cómo pueden las herramientas CASE (Computer-Aided SoftwareEngineering) proporcionar soporte para el ciclo de vida del desarrollo de sistemas de bases de datos.Concluiremos en la Sección 9.15 con una explicación de propósito y las tareas asociadas con la administración de datos y la administración de bases de datos dentro de una organización.

9.1 El ciclo de vida de los sistemas de informaciónSistema deinformación

Los recursos que permiten la recopilación, gestión, control y diseminación de la información en una determinada organización.

Desde la década de 1970, los sistemas de bases de datos han ido sustituyendo de manera gradual a los sistemas basados en archivos como parte de la infraestructura de sistemas de información de las organizaciones.Al mismo tiempo, cada vez se ha hecho más patente que los datos son un recurso comparativo de gran importancia que debe tratarse con respecto, al igual que cualquier otro recurso de la organización. Esto hizo que

muchas organizaciones crearan departamentos o áreas funciona~s específicos a los que se les atribuyó laadministración de datos y la administración de bases de datos y qu eran responsables de la gestión y controlde los datos y de la base de datos corporativos, respectivamente.

Los sistemas de información incluyen las bases de datos, el software de base de datos, el software de aplicación, el hardware informático y el personal que utiliza y desarrolla el sistema.

La base de datos es un componente fundamental de los sistemas de información, y su desarrollo y utilización deben contemplarse desde la perspectiva de los requisitos globales de la organización. Por tanto, el ciclode vida de los sistemas de información de una organización está inherentemente enlazado con el ciclo de vidadel sistema de base de datos que los da soporte. Normalmente, podemos identificar una serie de etapas clarasen el ciclo de vida de los sistemas de información: planificación, recopilación y análisis de requisitos, diseño,prototipado, implementación, conversión y manteniendo operativo. En este capítulo vamos a analizar estas etapas desde la perspectiva del desarrollo de un sistema de base de datos. Sin embargo, es importante tener en cuenta que el desarrollo de un sistema de base de datos también debe contemplarse desde la perspectiva más ampliadel desarrollo de lo que no es, en definitiva, sino un componente del sistema de información corporativo.

Capítulo 9 Planificación, diseño y administración de bases de datos 259

A lo largo de este capítulo utilizaremos los términos 'área funcional' y 'área de aplicación' para referimosa actividades empresariales concretas dentro de una organización, como por ejemplo marketing, personal ocontrol de almacén.

9.2 El ciclo de vida del desarrollo de sistemasde base de datos

Como los sistemas de base de datos son un componente fundamental de los sistemas de información corporativos, el ciclo de vida del desarrollo de sistemas de bases de datos está inherentemente asociado con el delos propios sistemas de información. La Figura 9.1 muestra las etapas del ciclo de vida del desarrollo desistemas de base de datos. Debajo del nombre de cada etapa se indica la sección de este capítulo donde se ladescribe.

Es importante tener en cuenta que las etapas del ciclo de vida del desarrollo de sistemas de base de datosno son estrictamente secuenciales, sino que existe una cierta repetición de las etapas anteriores a través de loque se denomina bucles de realimentación. Por ejemplo, los problemas que se encuentren durante el diseñode la base de datos pueden necesitar una nueva labor de recopilación y análisis de requisitos adicionales.Puesto que existen bucles de realimentación entre la mayoría de las etapas, en la Figura 9.1 solamente semuestran alguno de los más obvios. La Tabla 9.1 proporciona un resumen de las actividades principales asociadas con cada etapa del ciclo de vida del desarrollo de sistemas de base de datos.

Tabla 9.1. Resumen de las actividades principales asociadas con cada etapadel ciclo de vida del desarrollo de sistemas de base de datos.

Etapa

Planificación de la base de datos

Actividades principales

Planificación del modo en que pueden llevarse a cabo las distintas etapas delciclo de vida de la forma más eficiente y efectiva.

Definición del sistema Especificación del ámbito y los límites del sistema de base de datos, incluyendolas principales vistas de usuario, los tipos de usuario y las áreas de aplicación.

Recopilación y análisis de requisitos Recopilación y análisis de los requisitos del nuevo sistema de base de datos.

Diseño de la base de datos

Selección del SGBD (opcional)

Dise, de la aplicación

Prototipado (opcional)

lmplementación

Conversión y carga de los datos

Pruebas

Mantenimiento operativo

Diseño conceptual, lógico y físico de la base de datos.

Selección de un SGBD adecuado para el sistema de base de datos.

Diseño de la interfaz de usuario y de los programas de aplicación que sirvanpara utilizar y procesar los datos de la base de datos.

Construcción de un modelo funcional del sistema de base de datos que permitea los diseñadores o usuarios visualizar y evaluar el aspecto y la función del sistema final.

Creación de las definiciones físicas de la base de datos y de los programas deaplicación.

Carga de los datos del antiguo sistema en el nuevo y, siempre que sea posible,conversión de las aplicaciones existentes para que se ejecuten sobre la nuevabase de datos.

Prueba de la base de datos en busca de errores y validación de la misma conrespecto a los requisitos especificados por los usuarios.

El sistema de base de datos está complemente implementado, después de locual se lo monitoriza y mantiene de manera continua. Cuando sea necesario, seincorporarán nuevos requisitos al sistema de base de datos aplicando de nuevolas etapas precedentes del ciclo de vida.


Planificación de labase de datos

(Sección 9.3)

Definición del sistema

(Sección 9.4)

Recopilación y análisisde requisitos(Sección 9.5

Diseño de labase de datos

(Sección 9.6I

Diseño conceptual dela base de datos

Selección del SGBD

(opcional)(Sección 9.7)

Diseño lógico dela base de datos

Diseño físico dela base de datos

Diseño de la aplicación(Sección 9.8)

Prototipado (opcional)(Se~ción 9.9)

Implementación(Sección 9.10)

Conversión y cargade los datos

(Sección 9.11)

Pruebas

(Sección 9.12)

Mantenimiento operativo(Sección 9.13)

Figura 9.1. Las etapas del ciclo de vida del desarrollo de sistemas de base de datos.


Para pequeños sistemas de base de datos, con un número reducido de usuarios, el ciclo de vida necesitaser muy complejo. Sin embargo, cuando se están diseñando sistemas de base de datos de tamaño medio ogrande, con decenas o miles de usuarios que utilizan centenares de consultas y programas de aplicación, elciclo de vida puede llegar a ser extremadamente complejo. A lo largo de este capítulo nos centraremos en lasactividades asociadas con el desarrollo de sistemas de base de datos de tamaño medio o grande. En las siguientes secciones se describen con más detalle las actividades principales asociadas con cada etapa del ciclo devida del desarrollo de sistemas de base de datos.

9.3 Planificación de la base de datosPlanificaciónde la basede datos

Las actividades de gestión que permiten llevar a cabo las distintas etapas del ciclode vida del desarrollo de sistemas de base de datos de la forma más eficiente yefectiva posible.

La planificación de la base de datos debe estar integrada con la estrategia global de sistemas de informaciónde la organización. Son tres las cuestiones principales que hay que considerar a la hora de formular una estrategia para los sistemas de información:

• identificación de los planes y objetivos de la empresa, con la subsiguiente determinación de las necesidades de los sistemas de información;

• evaluación de los sistemas de información actuales para determinar las fortalezas y debilidades existentes;

• aprovechamiento de oportunidades en tecnologías de la información que puedan proporcionar una ventaja competitiva.

Las metodologías utilizadas para resolver estas cuestiones caen fuera del alcance de este libro; sin embargo, el lector interesado puede encontrar en Robson (1997) un análisis más detallado.

Un paso importante antes de comenzar la planificación de la base de datos consiste en enunciar claramente la misión del sistema de base de datos. El enunciado de la misión define los objetivos principales del sistema. Las personas encargadas de sacar adelante el proyecto de base de datos dentro de la organización (como,por ejemplo, el director y/o el propietario) son quienes definen normalmente cuál es esa misión. Enunciar lamisión ayuda a clarificar el propósito del sistema de base de datos y a proporcionar una ruta más clara queconduzca a la creación del sistema de base de datos requerido de forma efectiva y eficiente. Una vez defini

da la JUisión, la siguiente actividad implica identificar los objetivos de la misión. Cada objetivo de la misión®bé identificar una tarea concreta a la que el sistema de base de datos debe proporcionar soporte. La suposición en que esto se basa es que, si el sistema de base de datos soporta adecuadamente los objetivos de lamisión, podrá cumplirse con esa misión de forma satisfactoria. El enunciado y los objetivos de la misión pueden acompañarse de cierta información adicional que especifique en términos generales la tarea que hay querealizar, los recursos con los que hay que llevarla a cabo y el dinero que debe costar. Ilustraremos el procesode definición de la misión y de los objetivos de la misión para el sistema de base de datos de DreamHome enla Sección 10.4.2.

La planificación de la base de datos debe también incluir el desarrollo de estándares que regulen cómorecopilar los datos, cómo especificar el formato, qué documentación hará falta y cómo debe procederse aldiseño y la implementación. Puede consumir mucho tiempo desarrollar y mantener los estándares, debiendoasignarse recursos para su definición inicial y para encargarse del mantenimiento posterior. Sin embargo, unconjunto de estándares bien diseñado proporciona una base para formar al personal y para efectuar un controlde calidad, y puede garantizar que el trabajo se adapte a unas ciertas normas, independientemente de las capacidades y la experiencia de los empleados. Por ejemplo, una serie de reglas específicas pueden determinarcómo deben asignarse nombres a los elementos que componen el diccionario de datos, lo que a su vez puedeimpedir la aparición de redundancia o de incoherencias. Es necesario documentar todas las normas legales oempresariales relativas a los datos, como por ejemplo las normas que indican que ciertos tipos de datos debentratarse de forma confidencial.


9.4 Definición del sistemaDefinición delsistema

Describe el ámbito y los límites de la aplicación de base de datos y las principalesvistas de usuario.

Antes de empezar con el diseño de un sistema de base de datos, resulta esencial que identifiquemos primerolos límites del sistema que se pretende diseñar y el modo en que éste debe interactuar con otras partes del sistema de información de la organización. Es importante incluir dentro de las fronteras del sistema no sólo losusuarios y áreas de aplicación actuales, sino también los futuros usuarios y aplicaciones. En la Figura 10.10se presenta un diagrama que ilustra el ámbito y los límites del sistema de base de datos de DreamHome.Dentro de ese ámbito del sistema de base de datos deben estar incluidas las principales vistas de usuario a lasque la base de datos deberá dar soporte.

9.4.1 Vista de usuario

Vista de usuario Define qué es lo que se requiere de un sistema de base de datos desde la perspectiva de un determinado rol de la organización (como, por ejemplo, Gerente oSupervisor) o de un área de aplicación empresarial (como, por ejemplo, marketing,personal o control de almacén).

Un sistema de base de datos puede tener una o más vistas de usuario. La identificación de las vistas de usuario es un aspecto de gran importancia a la hora de desarrollar un sistema de base de datos, porque ayuda agarantizar que no se deje de lado a ninguno de los usuarios principales de la base de datos a la hora de desarrollar los requisitos para el nuevo sistema. Las vistas de usuario también son particularmente útiles en eldesarrollo de un sistema de base de datos relativamente complejo, al permitir descomponer los requisitos enuna serie de piezas más manejables.

Una vista de usuario define lo que se requiere del sistema de base de datos en términos de los datos quehay que almacenar y de las transacciones que hay que ejecutar con dichos datos (en otras palabras, lo que losusuarios harán con los datos). Los requisitos relativos a una vista de usuario pueden diferir de los de otras vistas, o solaparse con ellos. La Figura 9.2 es un diagrama que representa un sistema de base de datos con múltiples vistas de usuario (denominadas vista de usuario 1 a 6). Observe que, mientras que las vistas de usuario(1,2,3) Y (5 Y 6) tienen requisitos solapados (que se muestran como áreas sombreadas), la vista de usuario 4tiene requisitos completamente independientes.

9.5 RecopiÍación y análisis de requisitosRecopilacióny análisis derequisitos

El proceso de recopilar y analizar la información acerca de la parte de la organización a la que el sistema de base de datos tenga que dar soporte, y utilizar esta información para identificar los requisitos relativos al nuevo sistema.

Esta etapa implica la recopilación y análisis de información acerca de aquella parte de la empresa a la que labase de datos debe dar servicio. Existen muchas técnicas para recopilar esta información, denominadas técnicas de determinación de hechos, de las que hablaremos en detalle en el Capítulo 10. Se recopila información para cada una de las vistas de usuario principal (es decir, para cada uno de los puestos de trabajo o áreasde aplicación empresarial), incluyendo:

• una descripción de los datos utilizados o generados;

• los detalles acerca de cómo hay que utilizar o generar los datos;

• cualesquiera otros requisitos que sean aplicables al nuevo sistema de base de datos.

Esta información se analiza a continuación para identificar los requisitos (o características) que hay queincluir en el nuevo sistema de base de datos. Estos requisitos se describen en una serie de documentos a losque se denomina colectivamente especificaciones de requisitos para el nuevo sistema de base de datos.


Base de datos

Vista de usuario 2

Sistema de bases de datos

Figura 9.2. Representación de un sistema de base de datos con múltiples vistas de usuario: las vistas de

usuario (1, 2, 3) Y (5 Y 6) tienen requisitos que se solapan (mostrados como áreas sombreadas),

mientras que la vista de usuario 4 tiene requisitos completamente independientes.

La recopilación y análisis de requisitos es una de las etapas preliminares en el diseño de base de datos. Lacantidad de datos recopilados dependerá de la naturaleza del problema y de las políticas vigentes en la empresa. Un estudio demasiado detallado al principio conduce a lo que se denomina parálisis por el análisis. Unestudio demasiado superficial puede dar como resultado un desperdicio tanto de tiempo como de dinero debido al trabajo dedicado a obtener la solución incorrecta para el problema inapropiado.

La¡información recopilada en esta etapa puede no estar demasiado estructurada y puede incluir determin~ requisitos informales, que deberán ser convertidos en un enunciado de requisitos más estructurados.Esto se consigue empleando técnicas de especificación de requisitos, que incluyen, por ejemplo: técnicasSAD (Structured Analysis and Design, diseño y análisis estructurados), diagramas DFD (Data FlowDiagrams, diagramas de flujo de datos), HIPO (Hierarchical Input Process Output, diagrama jerárquico deentrada, salida y procesamiento), con el correspondiente soporte documental. Como veremos en breve, lasherramientas CASE (Computer-Aided Software Engineering) pueden servir como ayuda a la automatizaciónpara garantizar que los requisitos sean completos y coherentes. En la Sección 25.7 veremos cómo soporta ellenguaje UML (Unified Modeling Language, lenguaje unificado de modelado) la recopilación y análisis derequisitos.

La identificación de la funcionalidad requerida de un sistema de base de datos es una actividad de importancia crítica, ya que los sistemas con una funcionalidad inadecuada o incompleta constituirán una auténticamolestia para los usuarios, lo que puede conducir a un rechazo o a una infrautilización del sistema. Sin embargo, también puede ser problemática una funcionalidad excesiva, ya que puede complicar demasiado un sistema, haciéndolo difícil de implementar, mantener o utilizar o aprender.

Otra actividad importante asociada con esta etapa es la de decidir cómo resolver aquellas situaciones enlas que haya más de una vista de usuario para el sistema de base de datos. Existen tres técnicas principalespara gestionar los requisitos de un sistema de base de datos que tengan múltiples vistas de usuario:

• el enfoque centralizado;


• el enfoque de integración de vistas;• una combinación de ambas técnicas.

9.5.1 Enfoque centralizadoEnfoquecentralizado

Los requisitos de cada vista de usuario se combinan en un único conjunto de requisitos para el nuevo sistema de base de datos. Durante la etapa de diseño de la basede datos se crea un modelo de datos que representa todas las vistas de usuario.

El enfoque centralizado implica combinar los requisitos de las diferentes vistas de usuario en una única listade requisitos. A la recopilación de las vistas de usuario se le asigna un nombre que proporciona algún tipo deindicación del área funcional cubierta por esa combinación de vista. En la etapa de diseño de la base de datos(véase la Sección 9.6), se creará un modelo global de los datos que represente todas las vistas de usuario. Elmodelo global de los datos está compuesto por una serie de diagramas y documentación que describen formalmente los requisitos de datos de los usuarios. En la Figura 9.3 se muestra un diagrama que representa lagestión de tres vistas de usuario mediante el enfoque centralizado. Generalmente se tiende a preferir este enfoque cuando haya un solapamiento significativo de los requisitos de cada vista de usuario y el sistema de basede datos no sea en exceso complejo.

9.5.2 Enfoque de integración de las vistas

Enfoque deintegraciónde las vistas

Los requisitos de cada vista de usuario se mantienen en listas separadas. Durantela etapa de diseño de la base de datos se crean y combinan los modelos de datosque representan cada una de las vistas de usuario.

El enfoque de integración de vistas implica mantener los requisitos de cada vista de usuario en una lista separada. En la etapa de diseño de la base de datos (véase la Sección 9.6) se crea primero un modelo de datos paracada vista de usuario. Los modelos de datos que representan una única vista de usuario (o un subconjunto de

Sistema debase de

datos

+

oModelo ER

Relaciones, diccionariode datos y otra

documentación de

soporte

Modelo global de datos

CJRequisitos de todaslas vistas de usuario

CJ

CJ

CJ

Requisitos de lavista de usuario 3



Figura 9.3. El enfoque centralizado de gestión de múltiples vistas de usuario.


todas las vistas de usuario) se denomina modelos de datos locales. Cada modelo está compuesto por una seriede diagramas y de documentación que describe formalmente los requisitos de una o más vistas de la base dedatos, aunque no de todas ellas. Después se combinan los modelos de datos locales en una etapa posterior deldiseño de la base de datos para producir un modelo global de datos, que representa todos los requisitos deusuario para la base de datos. En la Figura 9.4 se representa un diagrama de la gestión de tres vistas de usuario mediante el enfoque de integración de vistas. Generalmente se tiende a preferir este enfoque cuando hayadiferencias significativas entre las vistas de usuario y el sistema de base de datos sea suficientemente complejo como para justificar la división del trabajo en una serie de componentes más manejables. Ilustraremos lautilización del enfoque de integración de vistas en el Paso 2.6 del Capítulo 16.

Para algunos sistemas de base de datos complejos, puede resultar apropiado utilizar una combinación delos enfoques centralizado y de integración de vistas, con el fin de gestionar múltiples vistas de usuario. Por

Sistema debase de

datos

+

oModelo ER

Relaciones, diccionariode datos y otradocumentación

de soporte

Modelo global de datos

[KJ---[[]I-°1 +ORequisitos de la

vista de usuario 1 Vista de usuario 1

-Di

~

+

O 11

Requisitos de la vista de usuario 2Vista de usuario 2-~~_._--.-.-

t-wI-°1 +ORequisitos de lavista de usuario 3 Vista de usuario 3

Modelos locales de

datos

Figura 9.4. Enfoque de integración de vistas para la gestión de múltiples vistas de usuario.


ejemplo, los requisitos de dos o más vistas de usuario pueden primero combinarse utilizando el enfoque centralizado, lo que resulta útil para construir un modelo lógico local de los datos. Este modelo puede despuéscombinarse con otros modelos lógicos locales de los datos utilizando el enfoque de integración de vistas, conel fin de producir un modelo lógico global de los datos. En este caso, cada modelo lógico local de datos representa los requisitos de dos o más vistas de usuario y el modelo lógico global de los datos representa los requisitos de todas las vistas de usuario del sistema de base de datos.

Veremos con más detalle cómo gestionar múltiples vistas de usuario en la Sección 10.4.4 e ilustraremos,utilizando la metodología descrita en este libro, cómo construir una base de datos para el caso de estudio dela base de datos de alquileres de DreamHome utilizando una combinación de los enfoques centralizado y deintegración de vistas.

9.6 Diseño de la base de datos


El proceso de creación de un diseño que dé soporte a la misión y a los objetivos dela misión de la empresa para el sistema de base de datos requerido.

En esta sección se presenta una panorámica de las técnicas principales del diseño de bases de datos. Tambiénse analiza el propósito y la utilización del modelado de datos en el diseño de bases de datos. Después se describen las tres fases del diseño de bases de datos, es decir, el diseño conceptual, lógico y físico.

9.6.1 Técnicas de diseño de bases de datos

Las dos técnicas principales de diseño de base de datos se denominan técnicas 'de abajo a arriba' y 'de arriba a abajo'. La técnica de abajo a arriba comienza en el nivel fundamental de los atributos (es decir, de laspropiedades de las entidades y relaciones) que, mediante análisis de las asociaciones entre los atributos, seagrupan para formar relaciones que representan tipos de entidades y relaciones entre dichas entidades. En losCapítulos 13 y 14 analizaremos el proceso de normalización, que constituye una técnica de abajo a arriba parael diseño de bases de datos. La normalización implica la identificación de los atributos requeridos y su subsiguiente agregación en una serie de relaciones normalizadas basadas en independencias funcionales entre losatributos.

La técnica de abajo a arriba resulta apropiada para el diseño de bases de datos simples que tengan unnúmero relativamente pequeño de atributos. Sin embargo, esta técnica se complica si se la intenta aplicar aldiseño de bases de datos más complejas con un mayor número de atributos, en las que puede resultar difícil

establecer todas las d~encias funcionales entre unos atributos y otros. Puesto que los modelos de datosconceptuales y lógicos para las bases de datos complejas pueden contener cientos o miles de atributos, resulta esencial utilizar una técnica que permita simplificar el proceso de diseño. Asimismo, en las etapas inicialesde establecimiento de los requisitos de datos para una base de datos compleja, puede resultar difícil determinar todos los atributos que hay que incluir en los modelos de datos.

Una estrategia más apropiada para el diseño de bases de datos complejas es la técnica de arriba a abajo.Esta técnica comienza con el desarrollo de modelos de datos que contengan unas pocas entidades y relaciones de alto nivel y luego aplica una serie de refinamientos sucesivos de arriba a abajo para identificar entidades y relaciones de nivel inferior, junto con sus atributos asociados. La técnica de arriba a abajo se ilustrautilizando los conceptos del modelo ER (Entidad-Relacción), comenzando con la identificación de las entidades y de las relaciones entre las entidades que sean de interés para la organización. Por ejemplo, podemoscomenzar identificando las entidades PrivateOwner (propietario) y PropertyForRent (inmueble) y luego la relación entre dichas entidades, PrivateOwner Posee PropertyForRent, después de lo cual se identificarán los atributos asociados, tales como PrivateOwner (ownerNo, name y address) y PropertyForRent (propertyNo y address). Enlos Capítulos 11 y 12 se explica cómo construir un modelo de datos de alto nivel utilizando los conceptosdel modelo ER.

Existen otras técnicas de diseño de bases de datos, como la técnica 'de dentro hacia afuera' y la técnica de

estrategia mixta. La técnica de dentro hacia afuera está relacionada con la técnica de abajo a arriba, pero


difiere en que primero se identifica un conjunto de entidades principales y luego se lo amplía para considerarotras entidades, relaciones y atributos asociados con aquellas que se han identificado en primer lugar. Laestrategia mixta utiliza tanto la técnica de abajo a arriba como la técnica de arriba a abajo para diversas partes del modelo, antes de combinar finalmente todas las diferentes partes.

9.6.2 Modelado de datos

Los dos propósitos principales del modelado de datos son ayudar a comprender el significado (semintica) delos datos y facilitar la comunicación de los requisitos de información. La construcción de un modelo de datosrequiere responder a una serie de preguntas acerca de las entidades, las relaciones y los atributos. Al formular las respuestas, los diseñadores descubren la semántica de los datos empresariales, la cual existe siemprecon independencia de si está representada mediante un modelo de datos formal. Las entidades, relaciones yatributos resultan fundamentales para todas las empresas. Sin embargo, su significado puede no ser adecuadamente comprendido hasta que hayan sido correctamente documentadas. Los modelos de datos hacen quesea más fácil comprender el significado de los datos; por tanto, modelamos los datos para estar seguros decomprender:

• la perspectiva que cada usuario tiene de los datos;

• la naturaleza de los propios datos, independiente de su representación física;

• la utilización de los datos en distintas vistas de usuario.

Los modelos de datos pueden utilizarse para representar la visión que el diseñador tiene de los requisitosde información de la empresa. Si ambas partes están familiarizadas con la notación utilizada en el modelo,éste mejorará la comunicación entre los usuarios y los diseñadores. Las empresas están estandarizando cadavez más la forma de modelar los datos, seleccionando una técnica concreta de modelado de datos y utilizándola en todos sus proyectos de desarrollo de bases de datos. El modelo de datos de alto nivel más popular delos que se utilizan en el diseño de bases de datos (y el que usaremos en este libro) está basado en los conceptos del modelo de entidad-relación (ER). Hablaremos en detalle de los modelos de entidad-relación en losCapítulos 11 y 12.

Criterios relativos a los modelos de datos

Un modelo de datos óptimo debe satisfacer los criterios enumerados en la Tabla 9.2 (Fleming y Van Halle,1989). Sin embargo, en ocasiones estos criterios no son compatibles entre sí, por lo que se hace necesario lle

gar a ciertos/compromisos. Por ejemplo, al tratar de mejorar la capacidad de expresión de un modelo de datospodem6S1Íegar a perder algo de simplicidad.

Tabla 9.2. Criterios para generar un modelo de datos óptimo.

Validez estructural Coherencia con la forma en que la empresa define y organiza la información.

Simplicidad Facilidad de comprensión por parte de los profesionales de los sistemas de informacióny por parte de los usuarios no técnicos.

Capacidad de expresión Capacidad de distinguir entre diferentes datos, relaciones entre los datos y restricciones.

No redundancia Exclusión de la información no pertinente; en particular, la representación de cada ele-mento de información una única vez.

Capacidad de compartición No específico de ninguna aplicación o tecnologías concretas y, como consecuencia, uti-lizable por muchas aplicaciones o tecnologías.

Ampliabilidad Capacidad de evolucionar para satisfacer nuevos requisitos con un efecto mínimo sobrelos usuarios existentes.

Integridad Coherencia con la forma en que la empresa utiliza y gestiona la información

Representación diagramática Capacidad de representar un modelo utilizando una notación diagramática fácilmentecomprensible.


9.6.3 Fases del diseño de la base de datos

El diseño de la base de datos está compuesto de tres fases principales, denominadas diseño conceptual, diseño lógico y diseño físico.

Diseño conceptual de la base de datos

Diseño conceptualde la base de datos

El proceso de construcción de un modelo de los datos utilizados en unaempresa, de forma independiente de todas las consideraciones fisicas.

La primera fase del diseño de la base de datos se denomina diseño conceptual de la base de datos e implica la creación de un modelo de datos conceptual para aquella parte de la empresa que queramos modelar. Elmodelo de datos se construye utilizando la información documentada en la especificación de requisitos de losusuarios. El diseño conceptual de la base de datos es enteramente independiente de los detalles de implementación tales como el software SGBD de destino, los programas de aplicación, los lenguajes de programación,la plataforma hardware o cualquier otra consideración física. En el Capítulo 15 presentaremos una guía práctica paso a paso para el diseño conceptual de la base de datos.

Durante el proceso de desarrollo de un modelo conceptual de los datos, el modelo se prueba y se validade acuerdo con los requisitos de usuario. El modelo conceptual de datos de la empresa es una fuente de información para la siguiente fase, la de diseño lógico de la base de datos.

Diseño lógico de la base de datos

Diseño lógico dela base de datos

El proceso de construcción de un modelo de los datos utilizados en unaempresa basándose en un modelo de datos específico, pero de forma independiente de un SGBD concreto y de cualquier otra consideración física.

La segunda fase del diseño de la base de datos se denomina diseño lógico de la base de datos, el cual tienecomo resultado la creación de un modelo lógico de los datos para la parte de la empresa que queramos modelar. El modelo conceptual de datos creado en la fase anterior se refina y se hace corresponder con un modelológico de los datos. Este modelo lógico está basado en el modelo de datos objetivo de la base de datos (porejemplo, el modelo de datos relacional).

Mientras que el modelo conceptual de los datos es independiente de todas las consideraciones fisicas, elmodelo lógico se construye conociendo el modelo de datos subyacente del SGBD objetivo. En otras palabras,

sabemos que el SGBD~r ejemplo, relacional, en red, jerárquico u orientado a objetos. Sin embargo, notomamos en consideración ningún otro aspecto del SGBD elegido y, en concreto, hacemos caso omiso detodos los detalles físicos, como puedan ser las estructuras de almacenamiento o los índices.

Durante el proceso de desarrollo de un modelo lógico de los datos, el modelo se prueba y se valida deacuerdo con los requisitos de los usuarios. Se utiliza la técnica de la normalización para comprobar la corrección de un modelo lógico de los datos. La normalización garantiza que las relaciones extraídas del modelo dedatos no presenten redundancia, que podría provocar anomalías de actualización en la implementación. En elCapítulo 13 ilustraremos los problemas asociados con la redundancia de los datos y describiremos en detalleel proceso de normalización.

El modelo lógico de los datos debe también examinarse para garantizar que soporta las transacciones especificadas por los usuarios. El modelo lógico de los datos es una fuente de información para la siguiente fase,la del diseño físico de la fase de datos, proporcionando al encargado de efectuar ese diseño físico una herramienta para alcanzar compromisos que tienen una gran importancia para el diseño eficiente de una base dedatos. El modelo lógico también cumple un importante papel durante la etapa de mantenimiento operativo delsistema de base de datos, dentro del ciclo de vida del desarrollo. Si el modelo de datos se mantiene adecuadamente y se conserva actualizado, los futuros cambios que se efectúen en los programas de aplicación o enlos datos podrán ser representados de forma precisa y eficiente mediante la base de datos.

En el Capítulo 16 se presenta una guía práctica paso a paso para el diseño lógico de la base de datos.


Diseño físico de la base de datos

Diseño físico dela base de datos

El proceso de generar una descripción de la implementación de la base dedatos en el almacenamiento secundario; describe las relaciones base, la organización de los archivos y los índices utilizados para conseguir un accesoeficiente a los datos, así como cualesquiera medidas de seguridad y restricciones de integridad asociadas.

El diseño físico de la base de datos es la tercera y última fase del proceso de diseño de la base de datos, fasedurante la cual el diseñador decide cómo hay que implementar la base de datos. La fase anterior del diseño dela base de datos implicaba el desarrollo de una estructura lógica para la misma, en la que se describieran lasrelaciones y las restricciones empresariales. Aunque esta estructura es independiente del SGBD, se desarrollade acuerdo con un modelo de datos concreto, como por ejemplo el modelo relacional, en red o jerárquico. Sinembargo, al llegar a la fase del diseño físico de la base de datos lo primero que debemos hacer es identificarel SGBD de destino. Por tanto, el diseño físico estará adaptado a un sistema SGBD concreto. Existe una cierta realimentación entre el diseño físico y el diseño lógico, porque durante la fase de diseño físico se tomandecisiones de mejora de las prestaciones que pueden afectar a la estructura del modelo lógico de los datos.

En general, el objetivo principal del diseño físico de la base de datos consiste en describir cómo pretendemos implementar físicamente el diseño lógico de la base de datos. Para el modelo relacional, esto implica:

• crear un conjunto de tablas relacionales y especificar las restricciones relativas a estas tablas, todo elloa partir de la información presentada en el modelo lógico de los datos;

• identificar las estructuras de almacenamiento específicas y los métodos de acceso a los datos que permitan conseguir unas prestaciones óptimas en el sistema de base de datos;

• diseñar las medidas de seguridad del sistema.

Idealmente, los diseños conceptual y lógico de la base de datos para los sistemas de gran tamaño debenestar separados del diseño físico por tres razones principales:

• tratan de un tema diferente: el qué no el cómo;

• se realizan en un momento distinto; el qué debe comprenderse perfectamente antes de poder determinar el cómo;

• ~eren diferentes capacidades, que a menudo se encuentran en personas distintas.El diseño de bases de datos es un proceso iterativo, que tiene un punto de partida y un número indetermi

nado de pasadas de refinamiento. En cierto modo, se lo puede considerar una especie de proceso de aprendizaje. A medida que los diseñadores comprenden cada vez mejor el funcionamiento de la empresa y el significado de los datos, y a medida que expresan dicha comprensión en los modelos de datos seleccionados, esainformación adicional puede requerir cambios en otras partes del diseño. En particular, los diseños conceptualy lógico de la base de datos resultan críticos para el éxito final del sistema. Si esos diseños no constituyen unaverdadera representación de la empresa, será difícil, por no decir imposible, definir todas las vistas de usuario requeridas o mantener la integridad de la base de datos. Puede incluso resultar difícil definir la implementación física o conseguir unas prestaciones del sistema aceptables. Por otro lado, la capacidad para adaptarsea los cambios es una de las medidas de calidad de los diseños de bases de datos. Por tanto, merece la penainvertir el tiempo y la energía necesarios para generar el mejor diseño posible.

En el Capítulo 2, hemos analizado la arquitectura ANSI-SPARC en tres niveles de un sistema de base dedatos, compuesta por los esquemas externo, conceptual e interno. La Figura 9.5 ilustra la correspondenciaentre esta arquitectura y los procesos de diseño conceptual, lógico y físico de la base de datos. En losCapítulos 17 y 18 presentaremos una metodología paso a paso para la fase de diseño físico de la base de datos.

9.7 Selección del SGBDSelección del SGBD La selección de un SGBD apropiado para soportar el sistema de base de

datos.


tDiseño lógico/conceptual de la base de datos

tDiseño físico de la base de datos¡

Figura 9.5. El modelado de datos en la arquitectura ANSI-SPARC.

Si no se dispone ya de un SGBD, una parte apropiada del ciclo de vida en la que se puede realizar la selección es entre las fases de diseño conceptual y lógico de la base de datos (véase la Figura 9.1). Sin embargo,dicha selección puede llevarse a cabo en cualquier instante anterior al diseño lógico, supuesto que haya disponible la suficiente información referida a requisitos del sistema tales como las prestaciones, la facilidad dereestructuración, la seguridad y las restricciones de integridad.

Aunque el proceso de selección de un SGBD pueda ser infrecuente, a medida que la empresa necesitaexpandir o sustituir los sistemas existentes, puede que llegue la ocasión de tener que evaluar nuevos productos SGBD. En tales casos, el objetivo consiste en seleccionar un sistema que satisfaga los requisitos actualesy futuros de la empresa, equilibrando esos requisitos con respecto a los costes relevantes, que incluyen la compra del producto SGBD y de cualquier hardware/software adicional requerido para soportar el sistema de basede datos, y los costes asociados con los cambios y con la formación del personal.

Una técnica simple de selección consiste en comparar las características de cada SGBD con los requisitos.Al seleccionar un nuevo producto SGBD, se tiene la oportunidad de garantizar que el proceso de selecciónesté bien garantizado y que el sistema proporcione beneficios reales a la empresa. En la siguiente sección sedescribe una técnica típica de selección del 'mejor' SGBD.

9.7.1 SelecciQnAel SGBDLos pasos principales para seleccionar un SGBD son los que se indican en la Tabla 9.3.

Tabla 9.3. Pasos principales para seleccionar un SGBD.

Definición de los términos de referencia del estudio

Selección de dos o tres productos candidatos

Evaluación de los productos

Recomendación de un producto y generación del informe

Definición de los términos de referencia del estudio

Los términos de referencia para la selección del SGBD indican los objetivos y el ámbito del estudio y las tareas que hay que llevar a cabo. Este documento puede también incluir una descripción de los criterios (basados en la especificación de requisitos de los usuarios) que habrá que utilizar para evaluar los productos SGBD,junto con una lista preliminar de posibles productos y una especificación de todas las restricciones necesariasy de los plazos disponibles para el estudio.


Selección de dos o tres productos candidatos

Pueden utilizarse los criterios que se consideren 'críticos' para una adecuada implementación con el fin degenerar una lista preliminar de productos SGBD para su evaluación. Por ejemplo, la decisión de incluir undeterminado producto SGBD puede depender del presupuesto disponible, del nivel de soporte proporcionadopor el fabricante, de la compatibilidad con otros programas y software o de si el producto funciona sobre unhardware concreto. Puede recopilarse información adicional de utilidad sobre un producto contactando conusuarios existentes, los cuales pueden proporcionar detalles concretos sobre la calidad del soporte proporcionado por el fabricante, sobre la compatibilidad del producto con determinadas aplicaciones concretas y sobresi ciertas plataformas hardware son más problemáticas que otras. También puede que haya disponibles pruebas comparativas que permitan evaluar las prestaciones de los diferentes productos SGBD. Tras ese estudioinicial de la funcionalidad y de las características de los productos SGBD, puede identificarse una lista de doso tres productos candidatos.

La World Wide Web es una fuente excelente de información que puede utilizarse para identificar productos SGBD candidatos. Por ejemplo, el sitio web www.intelligententerprise.com proporciona un índice bastante completo de productos SGBD. Los sitios web de los fabricantes pueden también proporcionar informaciónde gran valor sobre los diferentes productos.

Evaluación de los productos

Hay varias características que pueden utilizarse para evaluar un producto SGBD. Para propósitos de la evaluación, estas características pueden clasificarse en una serie de grupos (por ejemplo, definición de datos) oevaluarse individualmente (por ejemplo, tipos de datos disponibles). La Tabla 9.4 indica una serie de posiblescaracterísticas para la evaluación del un SGBD, clasificadas en una serie de grupos: definición de datos, definición física, accesibilidad, gestión de transacciones, utilidades, desarrollo y otras características.

Tabla 9.4. Características para la evaluación de un SGBD.

Definición de los datos

Imposición de la clave principal

Especificación de la clave externa

Tipos de datos disponibles

Ampliabilidad de los tipos de datos

Especificación de dominio

Facilidad de reestructuración

Controles de integridad

Mecanismos de vistas

Diccionario de datos

Independencia de los datos

Modelo de datos subyacente

Evolución del esquema

Accesibilidad

Lenguaje de consulta: compatible con SQL2/SQL: 2003/ODMG

Interfaz con lenguajes 3GL

Definición física

Estructuras de archivo disponibles

Mantenimiento de las estructuras de archivos

Facilidad de reorganización

Indexación

Camposlregistros de longitud variable

Compresión de los datos

Rutinas de cifrado

Requisitos de memoria

Requisitos de almacenamiento

Gestión de transacciones

Rutinas de copia de seguridad y de recuperación

Puntos de comprobación

Registro de actividades

(Continúa)


Tabla 9.4. Características para la evaluación de un SGBD. (Cant.)

Multiusuario

Seguridad

- Controles Oflice Access

- Mecanismo de autorización

Utilidades

Medida del rendimiento

Optimización

Facilidades de carga/descarga

Monitorización de la utilización por parte de los usuarios

Soporte para la administración de la base de datos

Otras características

Capacidad de actualización

Estabilidad empresarial del fabricante

Base de usuario

Soporte de formación y soporte al usuario

Documentación

Sistema operativo requerido

Coste

Ayuda en línea

Estándares uti Iizados

Gestión de versiones

Optimización de consultas ampliables

Escalabilidad

Soporte para herramie~alíticas

Granularidad de la concurrencia

Estrategia de resolución de interbloqueos

Modelos de transacciones avanzados

Procesamiento paralelo de consultas

Desarrollo

Herramientas 4GL/5GL

Herramientas CASE

Capacidades de gestión de ventanas

Procedimientos almacenados, disparadores y reglas

Herramientas de desarrollo web

Interoperabilidad con otros SGBD y otros sistemas

Integración web

Utilidades de replicación

Capacidades distribuidas

Portabilidad

Hardware requerido

Soporte de red

Capacidades de orientación a objetos

Arquitectura (cliente/servidor de 2 o 3 niveles)

Prestaciones

Tasa de procesamiento de transacciones

Número máximo de usuarios concurrentes

Soporte para XML

Si nos limitamos a comprobar una a una las características, indicando lo bueno o malo que es el producto en ese aspecto, puede resultar difícil realizar comparaciones entre los diferentes productos SGBD. Unatécnica más útil consiste en ponderar las características y/o grupos de características teniendo en cuenta suimportancia para la organización, y obtener un valor ponderado global que pueda utilizarse para compararlos productos. La Tabla 9.5 ilustra este tipo de análisis para el grupo de 'Definición física' con un productoSGBD de ejemplo. A cada una de la características mencionadas se le da una puntuación entre 1 y 10 conuna ponderación entre O y 1 para indicar su importancia relativa con respecto a otras características delgrupo, calculándose luego la puntuación total teniendo en cuenta esas puntuaciones individuales y la respectiva ponderación. Por ejemplo, en la Tabla 9.5 la característica 'Facilidad de reorganización' tiene una puntuación de 4 y una ponderación de 0,25, 10 que nos da un total de 1,0 puntos. Esta característica es la quetiene la mayor ponderación de la tabla, 10 que indica su importancia en esta parte de la evaluación. Además,la característica 'Facilidad de reorganización' tiene una ponderación, por ejemplo, cinco veces superior a lade la característica 'Compresión de datos', que tiene la ponderación más baja, de 0,05. Por su parte, las doscaracterísticas 'Requisitos de memoria' y 'Requisitos de almacenamiento' tienen una ponderación de 0,00,por lo que no se incluyen en esta evaluación.


Tabla 9.5. Análisis de las caracteristicas para la evaluación de un producto SGBD.

SGBD: Producto de ejemplo

Fabricante: Fabricante de ejemplo

Grupo de definición física

Características Comentarios Puntuación Ponderación Puntos

Estructuras de archivo disponibles Existen 4 distintas

Mantenimiento de las estructuras NO se autorregulade archivos

Se especifica con la estructura del archivo 7

Facilidad de reorganización

lndexación

Campos/registros de longitudvariable

Compresión de los datos

Rutinas de cifrado

Requisitos de memoria

Requisitos de almacenamiento

Totales

Grupo de definición física

2 posibilidades distintas

8

6

4

6

6

4

O

O

41

5,75

0,15 1,2

0,2

1,2

0,25

1,0

0,15

0,9

0,15

0,9

0,05

0,35

0,05

0,2

0,00

O

0,00

O

1,0

5,75

0,25

1,44

La puntuación del propio grupo se pondera a continuación para indicar su importancia relativa con respecto a otros grupos de características incluidos en la evaluación. Por ejemplo, en la Tabla 9.5, la puntuación totaldel grupo de 'Definición fisica' es 5,75; sin embargo, esta puntuación tiene una ponderación de 0,25.

Finalmente, se suman todas las puntuaciones ponderadas de cada uno de los grupos de características evaluados con el fin de generar una puntuación final para el producto SGBD, la cual se compara con las puntuaciones de otros productos. El producto con la máxima puntuación es el 'ganador'.

Además de este tipo de análisis, también podemos evaluar los productos dejando que los fabricantes efec

túen demostrationes de los mismos o comprobando los productos en la propia empresa. La evaluación interna en la em-¡5resaimplica la creación de un sistema de pruebas utilizando los productos candidatos. Cada unode los productos se comprueba para verificar su capacidad de satisfacer los requisitos de usuario del sistemade base de datos. En el sitio web www.tpc.org podrá encontrar una serie de pruebas comparativas publicadaspor la organización Transaction Processing Council.

Recomendación de un producto y generación del informe

El paso final en la selección del SGBD consiste en documentar el proceso y proporcionar un informe de todolo que se haya averiguado para cada producto SGBD concreto y las recomendaciones pertinentes.

9.8 Diseño de la aplicaciónDiseño de la

aplicaciónEl diseño de la interfaz de usuario y de los programas de aplicación que permitenutilizar y procesar la base de datos.

En la Figura 9.1, observe que el diseño de la base de datos y el diseño de la aplicación son actividades quetranscurren en paralelo dentro del ciclo de vida del desarrollo de sistemas de bases de datos. En la mayoría de


los casos, no resulta posible completar el diseño de la aplicación hasta que el propio diseño de la base de datoshaya finalizado. Por otro lado, el propósito de la base de datos consiste precisamente en dar soporte a las aplicaciones, así que deberá existir un flujo de información entre los procesos de diseño de la aplicación y de diseño de la base de datos.

Debemos garantizar que toda la funcionalidad expresada en la especificación de requisitos de los usuariosesté presente en el diseño de la aplicación para el sistema de la base de datos. Esto implica diseñar los programas de aplicación que accedan a la base de datos y diseñar las transacciones, es decir, los métodos de acceso a la base de datos. Además de diseñar cómo hay que obtener la funcionalidad requerida, tenemos que diseñar una interfaz de usuario apropiada para el sistema de base de datos. Esta interfaz debe presentar lainformación requerida de una manera 'amigable'. A menudo se tiende a ignorar la importancia del diseño dela interfaz de usuario o se deja esta interfaz para las últimas etapas de diseño. Sin embargo, es preciso comprender que la interfaz puede ser uno de los componentes más importantes del sistema. Si es fácil de aprender, sencilla de utilizar, lógica y amigable, los usuarios se sentirán inclinados a hacer un buen uso de la información presentada. Por el contrario, si la interfaz no presenta ninguna de estas características, sin ningunaduda, el sistema causará problemas.

En las siguientes secciones vamos a examinar brevemente dos aspectos del diseño de aplicaciones: el diseño de las transacciones y el diseño de la interfaz de usuario.

9.8.1 Diseño de las transaccionesAntes de analizar el diseño de las transacciones, vamos primero a describir lo que representa una transacción:

Transacción Una acción o serie de acciones llevadas a cabo por un único usuario o programa de

aplicación y que acceden al contenido de la base de datos o los modifican.

Las transacciones representan sucesos 'del mundo real', como la introducción de un inmueble en alquiler,la adicción de un nuevo empleado, el registro de un nuevo cliente o la conclusión de un contrato de alquilerde un inmueble. Estas transacciones tienen que aplicarse a la base de datos para garantizar que los datos contenidos en ésta continúen estando actualizados con respecto a la situación del 'mundo real' y para soportar lasnecesidades de información de los usuarios.

Cada transacción puede estar compuesta por varias operaciones, como por ejemplo la transferencia dedinero desde una cuenta a otra. Sin embargo, desde la perspectiva del usuario, estas operaciones continúanviéndose como una única tarea. Desde el punto de vista del SGBD, una transacción hace que la base de datos

pase de un estado coherente ~ otro. El SGBD garantiza la coherencia de la base de datos incluso aunque seproduzca un fallo. El SG~ambién garantiza que, una vez que se ha completado una transacción, los cambios realizados se almacenan de forma permanente en la base de datos y no pueden perderse o deshacerse (sinejecutar otra transacción para compensar el efecto de la primera. Si la transacción no puede completarse poralguna razón, el SGBD debe garantizar que los cambios realizados por dicha transacción se deshagan. En elejemplo de la transferencia bancaria, si se extrae dinero de una cuenta y la transacción falla antes de que sehaya introducido en la otra, el SGBD debe volver a ingresar el dinero en la cuenta original. Si separáramoslas operaciones de extracción de una cuenta y de ingreso en la otra como transacciones separadas, una vez quehubiéramos extraído el dinero de la primera cuenta y completado la transacción, no podríamos deshacer dichocambio (sin ejecutar otra transacción que ingresara en la cuenta original la cantidad referida).

El propósito del diseño de las transacciones consiste en definir y documentar las características de altonivel en las transacciones requeridas en la base de datos, incluyendo la información siguiente:

• los datos que tiene que utilizar la transacción;

• las características funcionales de la transacción;

• la salida de la transacción;

• la importancia para los usuarios;

• la frecuencia esperada de uso.


Esta actividad debe llevarse a cabo en una fase temprana del proceso de diseño, para garantizar que la basede datos que se implemente sea capaz de soportar todas las transacciones requeridas. Hay tres tipos principales de transacciones: transacciones de extracción, transacciones de actualización y transacciones mixtas .

• Las transacciones de extracción se utilizan para extraer datos con el fin de mostrar/os en la pantalla o para emplear/os en la generación de un informe. Por ejemplo, la operación consistente en buscar y visualizar los detalles de un inmueble (dado el número del inmueble) constituye un ejemplo detransacción de extracción.

• Las transacciones de actualización se utilizan para insertar nuevos registros, borrar registrós anteriores o modificar registros existentes en la base de datos. Por ejemplo, la operación consistente en insertar los detalles de un nuevo inmueble en la base de datos constituye un ejemplo de transacción deactualización .

• Las transacciones mixtas implican tanto la extracción como la actualización de datos. Por ejemplo, laoperación consistente en buscar y visualizar los detalles de un inmueble (dado el número del inmueble) y luego actualizar el valor del alquiler mensual constituye un ejemplo de transacción mixta.

9.8.2 Directrices de diseño de interfaces de usuario

Antes de implementar un formulario o informe, resulta esencial que primero diseñemos su aspecto fisico. Enla Tabla 9.6 se enumeran una serie de directrices útiles que pueden seguirse a la hora de diseñar formularioso informes (Shneiderman, 1992).

Título significativo

La información proporcionada por el título debe identificar de forma clara y no ambigua el propósito del formulario/informe.

Instrucciones comprensibles

Debe utilizarse terminología familiar para proporcionar las instrucciones al usuario. Las instrucciones deben

ser breves y, cuando se requiera más información, deben proporcionarse pantallas de ayuda. Las instrucciones deben escribirse con un estilo gramatical coherente, utilizando el formato estándar.

Tabla 9.6. Directrices para el diseño de formularios/informes.

Título significativo

Instrucciones comprensib]es

Agrupamiento y secuenciamiento lógicos de los campos

Diseño visua]mente atractivo de] formu]ariolinforme

Etiquetas familiares para los campos

Termino]ogía y abreviaturas coherentes

Utilización coherente del color

Espacio y límites visibles para los campos de introducción de datos

Movimiento cómodo del cursor

Corrección de errores para caracteres individuales y campos completos

Mensajes de error para los valores no aceptables

Campos opcionales marcados claramente

Mensajes explicativos para los campos

Señal de terminación


Agrupamiento y secuenciamiento lógicos de los campos

Los campos que estén relacionados deben situarse juntos en el formulario/informe. El secuenciamiento de loscampos debe ser lógico y coherente.

Diseño visual mente atractivo del formulario/informe

El formulario/informe debe presentar una interfaz atractiva al usuario. El formulario/informe debe aparecerequilibrado, con los campos o grupos de campos situados de forma homogénea a lo largo del formulario/informe. No debe haber áreas del formulario/informe que tengan demasiados campos o demasiado pocos. Los campos o grupos de campos deben estar separados por un espacio suficiente. Cuando sea apropiado, los camposdeberán alinearse vertical u horizontalmente. En aquellos casos en los que un formulario en pantalla tenga unequivalente impreso, la apariencia de ambos formularios debe ser coherente.

Etiquetas familiares para los campos

Las etiquetas de los campos deben ser familiares. Por ejemplo, si se sustituye Sexo por Género, es posible quealgunos usuarios se sientan confundidos-

Terminología y abreviaturas coherentesDebe utilizarse de forma coherente una lista previamente acordada de términos y abreviaturas familiares.

Utilización coherente del color

Debe utilizarse el color para mejorar la apariencia del formulario/informe y para resaltar los campos omensajes de mayor importancia. Para conseguir esto, debe utilizarse el color de una forma coherente y significativa. Por ejemplo, los campos de un formulario que tengan un fondo blanco pueden indicar campos deintroducción de datos, mientras que aquellos que tengan el fondo azul pueden indicar campos utilizados exclusivamente para la presentación de información.

Espacio y límites visibles para los campos de introducción de datosEl usuario debe ser visualmente consciente de la cantidad total de espacio disponible para cada campo. Esto

permite que el usuario reflexione sobre el formato apropiado para los datos, antes de introducir los valores enel campo.

Movimiento cómodo del cursor

El usuario debe poder identifico/" fácilmente la operación requerida para desplazar un cursor a lo largo de unformulario/informe. DebenjJtilizarse mecanismos simples, como la utilización de la tecla de tabulación, delas flechas o del puntero del ratón.

Corrección de errores para caracteres individuales y campos completos

El usuario debe poder identificar fácilmente la operación requerida para efectuar correcciones en los valoresde los campos. Deben proporcionarse mecanismos simples, como la utilización de la tecla de retroceso o lasobreescritura de la información anterior.

Mensajes de error para los valores no aceptablesSi un usuario intenta introducir datos incorrectos en un campo, debe mostrarse un mensaje de error. El men

saje debe informar al usuario del error e indicar los valores permitidos.

Campos opcionales marcados claramente

Los campos opcionales deben estar claramente identificados para el usuario. Esto puede conseguirse utilizando una etiqueta de campo apropiada o mostrando el campo con un color que indique su tipo. Los camposopcionales deben situarse después de los campos obligatorios.


Mensajes explicativos para los campos

Cuando un usuario sitúa un cursor sobre un campo, debe aparecer la información sobre el campo en una posición fija de la pantalla, como por ejemplo la barra de estado de la ventana.

Señal de terminación

Debe quedar claro para el usuario cuándo se ha completado el proceso de introducción de datos en los campos de un formulario. Sin embargo, la propia opción de completar el proceso no debe ser automática, ya queel usuario puede desear revisar los datos que ha introducido.

9.9 PrototipadoEn varios puntos del proceso de diseño, tenemos la opción de implementar completamente el sistema de basede datos o construir un prototipo.

Prototipado Construcción de un modelo operativo de un sistema de base de datos.

Un prototipo es un modelo operativo que no tiene, normalmente, todas las características requeridas niproporciona toda la funcionalidad del sistema final. El principal propósito de desarrollar un sistema de basede datos prototipo es permitir a los usuarios utilizar el prototipo para identificar las características del sistemaque funcionan bien o que son inadecuadas y, si es posible, sugerir mejoras o incluso nuevas características queel sistema de base de datos deba poseer. De esta forma, podemos clarificar enormemente los requisitos deusuario tanto para los usuarios como para los desarrolladores del sistema y evaluar la factibilidad de un diseño concreto del sistema. Los prototipos deben tener la ventaja principal de ser relativamente baratos y rápidos de construir.

Hay dos estrategias de prototipo que se utilizan de forma común hoy en día. El prototipado de requisitosy el prototipado evolutivo. El prototipado de requisitos utiliza el prototipo para determinar los requisitos deun sistema de base de datos propuesto y, una vez completados los requisitos, el prototipo se descarta. Por suparte, el prototipado evolutivo se utiliza para el mismo propósito, pero la diferencia fundamental es que elprototipo no se descarta sino que, con un desarrollo interior, se termina transformando en el sistema final debase de datos.

9.10 Implementación

) Implementación La realización física del diseño de la base de datos y del diseño de las aplicaciones.

Al completar las etapas de diseño (que pueden o no incluir tareas de prototipado) ya nos encontramos en situación de poder implementar la base de datos y los programas de aplicación. La implementación de la base dedatos se lleva a cabo utilizando el lenguaje de definición de datos (DDL) del SGBD seleccionado o una interfaz gráfica de usuario (GUl, Graphical User Interface), que proporciona la misma funcionalidad al mismotiempo que oculta las instrucciones DDL de bajo nivel. Las instrucciones DDL se emplean para crear lasestructuras de la base de datos y una serie de archivos de la base de datos vaCÍos. En esta etapa se implementan también las vistas de usuario especificadas.

Los programas de aplicación se implementan utilizando el lenguaje de tercera o cuarta generación (3GL o4GL) que se prefiera. Partes de estos programs de aplicación son las transacciones de la base de datos, que seimplementan utilizando el lenguaje de manipulación de datos (DML) del SGBD objetivo, posiblemente integrado dentro de un lenguaje de programación HOST, como Visual Basic (VB), VB.net, Python, Delphi, C,C++, C#, lava, COBOL, Fortran, Ada o Pascal. También se implementan los otros componentes del diseñode la aplicación, como pantallas de menús, formularios de introducción de datos e informes. De nuevo, elSGBD objetivo puede tener sus propias herramientas de cuarta generación que permitan el desarrollo rápidode aplicaciones mediante el uso de lenguajes de consulta no procedimentales, herramientas de generación deinformes, generadores de formularios y generadores de aplicaciones.


También hay que implementar los controles de seguridad e integridad para el sistema. Algunos de estoscontroles se implementan utilizando el DDL, pero puede que otros haya que definidos fuera del DDL, utilizando, por ejemplo, una serie de utilidades suministradas por el SGBD o una serie de controles del sistemaoperativo. Observe que SQL (Structured Query Language) es tanto un DDL como un DML, como se describe en los Capítulos 5 y 6.

9. 11 Conversión y carga de los datosConversión ycarga de losdatos

Transferencia de los datos existentes a la nueva base de datos y conversión de lasaplicaciones existentes para que se ejecuten con la nueva base de datos.

Esta etapa sólo es necesaria cuando se está sustituyendo un sistema anterior mediante un nuevo sistema debase de datos. Hoy en día, resulta común que los SGBD dispongan de una utilidad para cargar archivos yaexistentes en la nueva base de datos. Dicha utilidad, normalmente requiere que se especifique el archivo deorigen en la base de datos de destino, después de lo cual convierte automáticamente los datos al formatorequerido para los nuevos archivos de base de datos. Cuando sea aplicable, el desarrollador puede convertir yutilizar programas de aplicación del antiguo sistema, para usados en el nuevo. Cuando los procesos de conversión y de carga sean necesarios, dichos procesos deben planificarse de la forma adecuada para garantizaruna transición suave a la etapa de plena operación.

9.12 PruebasPruebas El proceso de operar el sistema de base de datos con la intención de localizar posi

bles errores.

Antes de entrar en producción, el nuevo sistema de base de datos debe comprobarse cuidadosamente. Esto selleva a cabo utilizando estrategias de prueba cuidadosamente planeadas y datos realistas, de modo que todo elproceso de pruebas se realiza de forma metódica y rigurosa. Observe que no hemos utilizado en nuestra definición de pruebas el concepto común de que las pruebas son el proceso de demostración de que no hay presente ningún fallo. De hecho, las pruebas no pueden demostrar la ausencia de fallos; lo único que puedendemostrar es que existe el fallo software. Si las pruebas se llevan a cabo adecuadamente, se podrán descubrir

errores en ~o programas de aplicación y, posiblemente, en la estructura de la base de datos. Otro beneficioderivado es ue las pruebas demuestran que la base de datos y los programas de aplicación parecen funcionar de acu rdo con la especificación y que los requisitos de prestaciones parecen satisfacerse. Además, lasmétricas recopiladas en la etapa de pruebas proporcionan una medida de la fiabilidad y calidad del software.

Al igual que sucede con el diseño de la base de datos, los usuarios del nuevo sistema también deben involucrarse en el proceso de pruebas. La situación ideal para las pruebas de un sistema consiste en disponer deuna base de datos de prueba sobre un sistema hardware independiente, pero a menudo no se dispone de tantas facilidades. Si hay que utilizar datos reales, resulta esencial que se realicen copias de seguridad, por siacaso se produjera algún error.

Las pruebas también deben cubrir los aspectos de usabilidad del sistema de base de datos. Idealmente,debe realizarse una evaluación de acuerdo con una especificación de usabilidad. Como ejemplos de criteriosque pueden emplearse para llevar a cabo esa evaluación, podemos citar (Sommerville, 2002):

• Facilidad de aprendizaje. ¿Cuánto tiempo requiere un nuevo usuario para comenzar a ser productivocon el nuevo sistema?

• Prestaciones. ¿Hasta qué punto se adapta la respuesta del sistema a las prácticas de trabajo del usuario?

• Robustez. ¿Hasta qué punto es el sistema tolerante a los errores de los usuarios?

• Capacidad de recuperación. ¿Es capaz el sistema de recuperarse adecuadamente después de un errordel usuario?


• Adaptabilidad. ¿Hasta qué punto está el sistema ligado a un determinado modelo de trabajo?

Algunos de estos criterios pueden evaluarse en otras etapas del ciclo de vida. Después de completar laspruebas, el sistema de base de datos estará listo para su aceptación y su entrega a los usuarios.

9.13 Mantenimiento operativoMantenimiento

operativoEl proceso de monitorizar y mantener el sistema de base de datos después de lainstalación.

En las etapas anteriores, e] sistema de base de datos ha sido completamente implementado y probado. Ahora,el sistema se mueve a la etapa de mantenimiento, que implica las siguientes actividades:

• Monitorización de las prestaciones del sistema. Si las prestaciones caen por debajo de un nivel aceptable, puede que se necesite optimizar o reorganizar la base de datos.

• Mantenimiento y actualización del sistema de base de datos (cuando sea requerido). Se incorporan nuevos requerimientos al sistema de base de datos recorriendo otra vez las etapas precedentes del ciclo devida.

Una vez que el sistema de base de datos está completamente operativo, se lleva a cabo una monitorizacióncuidadosa para garantizar que las prestaciones continúan estando dentro de los niveles aceptables. Un SGBDproporciona normalmente diversas utilidades como ayuda para administración de base de datos, incluyendoutilidades para cargar datos en una base de datos y para monitorizar el sistema. Las utilidades de monitorización del sistema proporcionan información sobre, por ejemplo, ]a utilización de la base de datos, la eficienciade bloqueo (incluyendo el número de interb]oqueos que se han producido, etc.) y la estrategia de ejecución deconsultas. El administrador de la base de datos (DBA) puede utilizar esta información para afinar el sistemacon e] fin de obtener mejores prestaciones, por ejemplo creando índices adicionales para acelerar las consu]tas, alterando las estructuras de almacenamiento o combinando o dividiendo tablas.

El proceso de monitorización continuará durante toda ]a vida del sistema de base de datos y, a su debidotiempo, puede conducir a la reorganización de la base de datos para satisfacer los cambios en los requisitos.Estos cambios proporcionan, a su vez, información sobre ]a evolución probable de] sistema y los futurosrecursos que pueden llegar a ser necesarios. Esto, junto con el conocimiento de las nuevas aplicaciones propuestas, permite al DBA realizar ]a planificación de la capacidad y notificar o alertar a los gerentes de altonivel para que ajusten sus planes de forma correspondiente. Si el SGBD carece de ciertas utilidades, el DBA

) puede desarrollar internamente las utilidades requeridas o comprar herramientas adicionales de otros fabricantes, si es que están disponibles. Hablaremos con más detalle de la administración de la base de datos en ]aSección 9.15.

Cuanto pasa a estar en línea (operativa) una nueva aplicación de base de datos, los usuarios deben utilizarla en paralelo con el antiguo sistema durante un periodo de tiempo. Esto permite que se salvaguarden lasoperaciones actuales en caso de que se produzcan problemas no previstos con el nuevo sistema. Será necesario realizar comprobaciones periódicas de la coherencia de los datos entre los dos sistemas y sólo debe prescindirse del sistema antiguo cuando ambos sistemas parezcan estar produciendo los mismos resultados deforma coherente. Si el salto de un sistema a otro es demasiado abrupto, el resultado fina] podría ser desastroso. A pesar de la suposición de que el anterior sistema puede eliminarse porque ambos sistemas arrojan yaresultados coherentes, puede haber situaciones en las que se decida mantener ambos sistemas.

9.14 Herramientas CASE

La primera etapa del ciclo de desarrollo de un sistema de base de datos, la de planificación de la base de datos,puede también implicar la selección de las adecuadas herramientas CASE (Computer-Aided SoftwareEngineering). En su sentido más amplio, el término CASE puede aplicarse a cualquier herramienta que désoporte a la ingeniería de software. El personal de administración de datos y de administración de la base de


datos necesita las adecuadas herramientas de productividad para que las actividades de desarrollo de la basede datos se lleven a cabo de la forma más eficiente y efectiva posible. El soporte CASE puede incluir:

• un diccionario de datos para almacenar información acerca de los datos del sistema de base de datos;

• herramientas de diseño para soportar el análisis de datos;

• herramientas que permitan el desarrollo del modelo de datos corporativo y de los modelos conceptualy lógico de los datos;

• herramientas que permitan el prototipado de aplicaciones.

Las herramientas CASE se pueden dividir en tres categorías: CASE de alto nivel, CASE de bajo nivel yCASE integrado, como se ilustra en la Figura 9.6. Las herramientas CASE de alto nivel soportan las etapasiniciales del ciclo de desarrollo de los sistemas de base de datos, desde la planificación hasta el diseño de labase de datos. Las herramientas CASE de bajo nivel soportan las últimas etapas del ciclo de vida, desdela implementación a las pruebas y el mantenimiento operativo. Las herramientas CASE integradas soportantodas las etapas del ciclo de desarrollo y proporcionan, por tanto, la funcionalidad de las herramientas CASEde alto y bajo nivel en una única herramienta.


Prototipado

Diseño de

la aplicación

CASE dealto nivel

CASE de

bajo nivel

CASE integrado

Figura 9.6. Aplicación de las herramientas CASE.

cgarcia

Highlight

cgarcia

Highlight

cgarcia

Highlight


Beneficios de las herramientas CASE

El uso de herramientas CASE apropiadas debería mejorar la productividad del desarrollo de un sistema debase de datos. Utilizamos el término 'productividad' para hacer referencia tanto a la eficiencia del proceso dedesarrollo como a la efectividad del sistema desarrollado. El término eficiencia hace referencia al coste, entérminos de tiempo y de dinero, de llevar a la práctica el sistema de base de datos. Las herramientas CASEtratan de soportar y automatizar las tareas de desarrollo y mejorar así la eficiencia. La efectividad hace referencia al grado con el que el sistema satisface las necesidades de información de los usuarios. Para tratar deconseguir una mayor productividad, mejorar la efectividad del proceso de desarrollo puede ser aún másimportante que mejorar su eficiencia. Por ejemplo, no tendría sentido desarrollar un sistema de base de datosextremadamente eficiente si el producto final no es lo que los usuarios desean. De esta forma, la efectividadestá relacionada con la calidad del producto final. Puesto que las computadoras son mejores que los sereshumanos para realizar ciertas tareas, por ejemplo las tareas de comprobación de coherencia, pueden utilizarse herramientas CASE para mejorar la efectividad de algunas tareas del proceso de desarrollo.

Las herramientas CASE proporcionan los siguientes beneficios que permiten mejorar la productividad:

• Estándares. Las herramientas CASE ayudan a imponer los estándares en un producto software o entoda la organización. Fomentan la producción de componentes de prueba estándar que puedan reutilizarse, simplificando así el mantenimiento e incrementando la productividad.

• Integración. Las herramientas CASE almacenan toda la información generada en un repositorio, o diccionario de datos, como se explica en la Sección 2.7. Así, debería ser posible almacenar los datos recopilados durante todas las etapas del ciclo de desarrollo del sistema de base de datos. Los datos puedenentonces ponerse en relación para garantizar que todas las partes del sistema estén integradas. De estaforma, el sistema de información de la organización no tiene ya por qué estar compuesto por una seriede componentes independientes y desconectados.

• Soporte para métodos estándar. Las técnicas estructuradas hacen un uso significativo de diagramas,que son difíciles de dibujar y mantener de forma manual. Las herramientas CASE simplifican este proceso, lo que da como resultado una documentación correcta y más actualizada.

• Coherencia. Puesto que toda la información del diccionario de datos está interrelacionada, las herramientas CASE pueden comprobar su coherencia.

• Automatización. Algunas herramientas CASE puede transformar automáticamente parte de una espe

c~cación de diseño en código ejecutable. Esto reduce el trabajo requerido para producir el sistemaimplementado, y puede contribuir a eliminar errores que aparecen normalmente durante el proceso decodificación.

Para obtener más información sobre las herramientas CASE, el lector interesado puede consultar Gane(1990), Batini et al. (1992) y Kendall y Kendall (1995).

9.15 Administración de datos y administraciónde bases de datos

El administrador de datos (DA) y el administrador de la base de datos (DBA) son responsables de gestionary controlar las actividades asociadas con los datos corporativos y con la base de datos corporativa, respectivamente. El DA se preocupa más de las etapas tempranas del ciclo de desarrollo, desde la planificación hastael diseño lógico de la base de datos. Por contraste, el DBA está más concentrado en las etapas posteriores,desde el diseño de las aplicaciones y el diseño físico de la base de datos hasta el mantenimiento operativo. Enesta sección final del capítulo, hablaremos del propósito y de las tareas asociadas con la administración dedatos y la administración de bases de datos.


9.15.1 Administración de datos

Administraciónde datos

La gestión de los recursos de datos, lo que incluye la planificación de la base dedatos, el desarrollo y el mantenimiento de estándares, políticas y procedimientos,así como el diseño conceptual y lógico de la base de datos.

El administrador de datos (DA) es responsable de los recursos de datos corporativos, que incluye los datos no

informatizados y en la práctica implica a menudo la gestión de los datos compartidos por los distintos usua

rios o áreas de aplicación de una organización. El DA es quien tiene la responsabilidad principal de aconse

jar a los gerentes de alto nivel y de garantizar que la aplicación de las tecnologías de base de datos continúe

dando soporte a los objetivos corporativos. En algunas empresas, la administración de datos es un área fun

cional independiente, mientras que en otras puede estar combinada con la administración de bases de datos.Las tareas asociadas con la administración de datos se describen en la Tabla 9.7.

9.15.2 Administración de bases de datos

Administraciónde bases dedatos

La gestión de la implementación física de un sistema de bases de datos, lo queincluye el diseño físico de la base de datos y su implementación, la configuraciónde los controles de seguridad e integridad, la monitorización de las prestaciones delsistema y la reorganización de la base de datos según sea necesario.

Tabla 9.7. Tareas de administración de datos.

Selección de las herramientas de productividad apropiadas.

Ayuda en el desarrollo de las estrategias corporativas relativas a las tecnologías de la información y sistemas de información.

Realización de estudios de factibilidad y planificación del desarrollo de la base de datos.

Desarrollo de un modelo de datos corporativo.

Determinación de los requisitos de datos de la organización.

Establecimiento de estándares de recopilación de datos y de formatos de los datos.

Estimación de los volúmenes de datos y del crecimiento previsible.

Determinación de los patrone/> y frecuencias de la utilización de los datos.Determinación de los reqursi'tos de acceso a los datos y de las salvaguardas relacionadas con los requisitos empresariales y legales.

Realización del diseño conceptual y lógico de la base de datos.

Colaboración con el personal de administración de la base de datos y con los desarrolladores de aplicaciones paragarantizar que las aplicaciones cumplan los requisitos establecidos.

Educación de los usuarios en lo que respecta a los estándares de datos y a las responsabilidades de carácter legal.

Mantenerse actualizado en lo que respecta a los desarrollos relativos a las tecnologías de la información y sistemas deinformación.

Garantizar que la documentación está actualizada y es completa, incluyendo estándares, políticas, procedimientos, utilización del diccionario de datos y controles relativos a los usuarios finales.

Gestión del diccionario de datos.

Colaboración con los usuarios para determinar nuevos requisitos y resolver las dificultades relativas a las prestacioneso al acceso a los datos.

Desarrollo de una política de seguridad.


El personal de administración de la base de datos está más técnicamente orientado que el personal de administración de datos, requiriéndose el conocimiento de productos SGBD específicos y del entorno correspondiente al sistema operativo utilizado. Aunque las responsabilidades principales se centran en el desarrollo ymantenimiento de sistemas utilizando el software SGBD de la mejor forma posible, el DBA también ayuda alDA en otras áreas, como se indica en la Tabla 9.8. El número de personas asignadas al área funcional encargada de la administración de la base de datos es muy variable, estando a menudo determinado por el tamañode la organización. Las tareas de administración de la base de datos se describen en la Tabla 9.8.

9.15.3 Comparación de las tareas de administración de datosy de administración de la base de datos

En las secciones precedentes hemos examinado el propósito y las tareas asociados con la administración dedatos y la administración de la base de datos. En esta sección final vamos a comparar brevemente estas dosáreas funcionales. La Tabla 9.9 resume las principales diferencias en cuanto a tareas de la administración dedatos y la administración de la base de datos. Quizá la diferencia más obvia radique en la naturaleza del propio trabajo que se lleva a cabo. El personal de administración de datos tiende a estar mucho más orientadohacia la gestión, mientras que el personal de administración de bases de datos tiende a ser más técnico.

Tabla 9.8. Tareas de administración de la base de datos.

Evaluación y selección de productos SGBD.

Realización del diseño fisico de la base de datos.

Implementación del diseño fisico de la base de datos utilizando un SGBD objetivo.

Definición de las restricciones de seguridad e integridad.

Colaboración con los desarrolladores de aplicaciones de base de datos.

Desarrollo de las estrategias de prueba.

Formación de los usuarios.

Aprobación final del sistema de base de datos implementado.

Monitorización de las implementaciones del sistema y optimización de la base de datos, según sea apropiado.

Realización de copias de seguridad rutinarias.

Garantizar la prese~cia de mecanismos y procedimientos de recuperación.Garantizar que 1~6cumentación esté completa, incluyendo el material producido internamente.Mantenerse actualizado en lo que respecta a los desarrollos en el campo del software y el hardware y sus costescorrespondientes, e instalar las actualizaciones según sea necesario.

Tabla 9.9. Administración de datos y administración de la base de datos:

principales diferencias en cuanto a tareas.

Administración de datos

Implicado en la planificación estratégica de los sistemasde información.

Determina objetivos a largo plazo.

Impone los estándares, políticas y procedimientos.

Determina los requisitos relativos a los datos.

Administración de la base de datos

Evalúa nuevos SGBD.

Ejecuta los planes necesarios para conseguir los objetivos.

Impone los estándares, políticas y procedimientos.

Implementa los requisitos relativos a los datos.(Continúa)


Tabla 9.9. Administración de datos y administración de la base de datos:

principales diferencias en cuanto a tareas. (Cant.)

Administración de datos

Lleva a cabo los diseños conceptual y lógico de la basede datos.

Desarrolla y mantiene el modelo de datos corporativo.

Coordina el desarrollo del sistema.

Orientación de gestión.

Independiente del SGBD.

Resumen del capítulo

Administración de la base de datos

Lleva a cabo los diseños lógico y físico de la base dedatos.

Implementa el diseño físico de la base de datos.

Monitoriza y controla la base de datos.

Orientación técnica.

Dependiente del SGBD.

• Un sistema de información está constituido por los recursos que permiten la recopilación, gestión, control y diseminación de la información a lo largo de una organización

• Un sistema de información basado en computadora incluye los siguientes componentes: base de datos,software de base de datos, software de aplicación, hardware informático (incluyendo los medios de almacenamiento) y el personal que utiliza y desarrolla el sistema.

• La base de datos es un componente fundamental de los sistemas de información y su desarrollo y utilización deben contemplarse desde la perspectiva de los requisitos globales de la organización. Por tanto, elciclo de vida de un sistema de información corporativo está inherentemente enlazado con el ciclo de vidade la base de datos que le da soporte.

• Las etapas principales del ciclo de desarrollo de un sistema de base de datos incluyen: planificación dela base de datos, definición del sistema, recopilación y análisis de requisitos, diseño de la base de datos,selección del SGBD (opcional), diseño de la aplicación, prototipado (opcional), implementación, conversión y carga de los datos, pruebas y mantenimiento operativo.

• La planificación de la base de datos está compuesta por las actividades de gestión que permiten llevar acabo las distintas etapas del ciclo de desarrollo de un sistema de base de datos de la forma más eficientey efectiva posible.

• La definición del sistema implica identificar el ámbito y los límites del sistema de base de datos, así comolas vistas de usuario. Una vista de usuario define lo que se requiere del sistema de base de datos desde la

perspectiva de un puesto de ~o concreto (como por ejemplo Gerente o Supervisor) o de una aplicación corporativa (como por ejemplo marketing, personal o control de almacén).

• La recopilación y análisis de requisitos es el proceso de recopilar y analizar información acerca de aquella parte de la organización a la que el sistema de base de datos deba dar soporte, así como utilizar estainformación para identificar los requisitos del nuevo sistema. Hay tres técnicas principales para gestionarlos requisitos de un sistema de bases de datos que tenga múltiples vistas de usuario: el enfoque centralizado, el enfoque de integración de vistas y una combinación de ambos enfoques.

• El enfoque centralizado implica combinar los requisitos de cada vista de usuario en un único conjunto derequisitos para el nuevo sistema de base de datos. Durante la etapa de diseño de la base de datos se crearáun modelo de datos que represente todas las vistas de usuario. En el enfoque de integración de vistas, losrequisitos de cada vista de usuario se conservan como listas independientes; durante la etapa de diseño dela base de datos se crean después modelos de datos que representan cada una de las vistas de usuario.

• El diseño de la base de datos es el proceso de crear un diseño que dé soporte a la misión y a los objetivos de la empresa para el sistema de base de datos requerido. Hay tres fases en el diseño de bases de datos:diseño conceptual, lógico y físico.


• El diseño conceptual de la base de datos es el proceso de construir el modelo de los datos utilizados enuna empresa, independientemente de todas las consideraciones físicas.

• El diseño lógico de la base de datos es el proceso de construir un modelo de los datos utilizados en unaempresa basándose en un modelo de datos específico, pero con independencia del SGBD concreto y delresto de consideraciones físicas.

• El diseño físico de la base de datos es el proceso de generar una descripción de la implementación de labase de datos en almacenamiento secundario; describe las relaciones básicas, la organización de los archivos y los índices empleados para conseguir un acceso eficiente a los datos, así como cualesquiera restricciones de integridad y medidas de seguridad asociadas.

• La selección del SGBD implica seleccionar un SGBD apropiado para el sistema de base de datos.

• El diseño de la aplicación implica el diseño de la interfaz de usuario y el diseño de las transacciones, quedescriben los programas de aplicación que utilizan y procesan la base de datos. Una transacción de basede datos es una acción, o serie de acciones, llevada a cabo por un único usuario o programa de aplicacióny que accede al contenido de la base de datos o lo modifica.

• El prototipado implica la construcción de un modelo operativo de sistema de la base de datos que permita a los diseñadores o usuarios visualizar y evaluar el sistema.

• La implementación es la realización física del diseño de la base de datos y del diseño de las aplicaciones.

• La conversión y carga de los datos implica la transferencia de los datos existentes a la nueva base dedatos y la conversión de las aplicaciones existentes para que se ejecuten sobre la nueva base de datos.

• Las pruebas son el proceso de operar el sistema de base de datos con la intención de localizar posibleserrores.

• El mantenimiento operativo es el proceso de monitorizar y mantener el sistema después de la instalación.

• El término CASE (Computer-Aided Software Engineering) se aplica a cualquier herramienta que desoporte a la ingeniería del software y que permita que las actividades de desarrollo del sistema de base dedatos se lleven a cabo de la forma más eficiente y efectiva posible. Las herramientas CASE pueden clasificarse en tres categorías: CASE de alto nivel, CASE de bajo nivel y CASE integrado.

• La administración de datos es la gestión de los recursos de datos, incluyendo las tareas de planificación

de base d~da os, desarrollo y mantenimiento de estándares, políticas y procedimientos y diseño concep

tual y lógico e la base de datos.

• La admi lstración de la base de datos es la gestión de la realización física de un sistema de base dedatos, incluyendo las tareas de diseño físico de la base de datos e implementación de la misma, configuración de la seguridad y los controles de integridad, monitorización de las prestaciones del sistema y reorganización de la base de datos según sea necesario.

Cuestiones de repaso

9.1. Describa los componentes principales de un sistema de información.

9.2. Explique la relación existente entre el ciclo de vida de los sistemas de información y el ciclo dedesarrollo de los sistemas de bases de datos.

9.3. Describa el propósito y actividades principales asociados con cada etapa del ciclo de desarrollo de unsistema de base de datos.

9.4. Explique lo que representa una vista de usuario en el contexto de un sistema de base de datos.

9.5. Explique las técnicas principales para la gestión del diseño de un sistema de base de datos que tengamúltiples vistas de usuario.

9.6. Realice una comparación entre las tres fases del diseño de una base de datos.


9.7. ¿Cuáles son los objetivos principales del modelado de datos? Identifique los criterios aplicables a unmodelo de datos óptimo.

9.8. Identifique la etapa o etapas en las que resulta apropiado seleccionar un SGBD y describa una técnicapara elegir el 'mejor' SGBD.

9.9. El diseño de aplicaciones implica el diseño de las transacciones y el diseño de la interfaz de usuario.Describa el propósito y las actividades principales asociados con cada una de esas tareas.

9.10. Explique por qué las pruebas no pueden demostrar la ausencia de fallos, sino sólo la presencia de losmIsmos.

9.11. Describa las principales ventajas de utilizar la técnica de prototipado a la hora de construir un sistemade bases de datos.

9.12. Defina el propósito y las tareas asociados con la administración de datos y la administración de basesde datos.

Ejercicios

9.13. Suponga que es responsable de seleccionar un nuevo producto SGBD para un grupo de usuarios de suorganización. Para realizar este ejercicio, primero debe establecer una serie de requisitos para el grupoy luego identificar un conjunto de características que el producto SGBD deba presentar con el fin desatisfacer dichos requisitos. Describa un proceso de evaluación y selección del mejor producto SGBD.

9.14. Describa el proceso de evaluación y selección de un producto SGBD para cada uno de los casos deestudio descritos en el Apéndice B.

9.15. Averigtie si la administración de datos y la administración de bases de datos existen como áreas funcionales independientes dentro de su organización. Si fuera así, describa la organización, responsabilidades y tareas asociadas con cada una de las dos áreas funcionales.

10 Cap 9 Planificacion, Diseño y administracion de bases de datos.pdf

Documents

Transcript of 10 Cap 9 Planificacion, Diseño y administracion de bases de datos.pdf