UNIVERSIDAD INTERAMERICANA DE PUERTO RICO DEPARTAMENTO DE CIENCIAS Y TECNOLOGIA PROGRAMA GRADUADO DE CIENCIAS DE COMPUTADORAS RECINTO DE FAJARDO COMP 6500 TALLER DE BASE DE DATOS Ciclo de vida de una base de datos Bases de datos-modelo de datos-cliclo de vida El ciclo de vida de un desarrollo de una base de datos consta de siete pasos: 1. Análisis de las necesidades 2. Estudio de viabilidad 3. Definición de requisitos 4. Diseño conceptual / lógico 5. Implementación 6. Evaluación y Mantenimiento 1. - Análisis de las necesidades En reunión con el cliente se deben documentar los tres grupos de usuarios definidos en la introducción de la guía, las necesidades de información de cada uno de ellos, así como los informes que cada uno necesita para su actividad y el contenido de los mismos. Cuanta más precisión exista en estos requisitos iniciales más preciso será el desarrollo de la base de datos. En esta reunión también debe quedar documentados los niveles de seguridad de los grupos de usuarios, los derechos de cada uno de ellos sobre los datos, los requisitos de los sistemas informáticos del cliente (sistema operativo, tipo de red, servidores, etc.) y la ubicación de los usuarios. No hay que olvidar que normalmente en las empresas existen ya sistemas de almacenamiento de datos, por tanto es conveniente analizar los datos ya
existentes y analizar las posibles relaciones con la base de datos a desarrollar. Un cuestionario muy sencillo pero muy útil para el administrador es el siguiente (a rellenar por todos los usuarios): o Nombre o Cargo o Area de Responsabilidad o Obligaciones principales que requieren información de la base datos o De qué aplicaciones recibe información? o Con cuánta frecuencia recibe información? o Qué hace con esta información? o Qué precauciones de seguridad debe tomar con respecto a la información? o Para que aplicación proporciona datos? o Están contemplados cambios para alguna de sus actividades actuales que involucren alguna de las informaciones anteriores? 2. -Estudio de viabilidad Un estudio de viabilidad implica la preparación de un informe con las características siguientes: 1. Viabilidad tecnológica. Hay tecnología suficiente para el desarrollo? 2. Viabilidad operacional. Existen suficientes recursos humanos, presupuesto, experiencia y formación para el desarrollo? 3. Viabilidad económica. Se pueden identificar los beneficios? Los beneficios costearían el desarrollo del sistema? Se pueden medir los costes y los beneficios? 3. - Definición de requisitos Los requisitos de desarrollo involucran el software y hardware necesario para la implementación, los recursos humanos necesarios (tanto internos como externos), la formación al personal. Aunque un poco al margen del tema es conveniente parar en este momento y planificar las acciones a realizar elaborando un cronograma del proyecto y un organigrama con las responsabilidades de cada miembro del equipo. Conviene señalar quienes van a ser los interlocutores y fijar un calendario de reuniones de
seguimiento del proyecto. Hay que definir la figura del validador, esta persona será la encargada de velar en cada momento que no se está rebasando el alcance del proyecto, así como asegurar que la implementación está encaminada a subsanar las necesidades del cliente. 4. - Diseño En esta etapa se crea un esquema conceptual de la base de datos. Se desarrollan las especificaciones hasta el punto en que puede comenzar la implementación. Durante esta etapa se crean modelos detallados de las vistas de usuario y sobre todo las relaciones entre cada elemento del sistema, documentando los derechos de uso y manipulación de los diferentes grupos de usuarios. Si parte de la información necesaria para crear algún elemento establecido ya se encuentra implementado en otro sistema de almacenamiento hay que documentar que relación existirá entre uno y otro y detallar los sistemas que eviten la duplicidad o incoherencia de los datos. El diseño consta, como se vio anteriormente, de tres fases: el diseño global o conceptual, el diseño lógico y el modelo físico. 5. - Implementación Una vez totalmente detallado el modelo conceptual se comienza con la implementación física del modelo de datos, a medida que se va avanzando en el modelo el administrador del sistema va asegurando la corrección del modelo y el validador la utilidad del mismo. La implementación consiste en el desarrollo de las tablas, los índices de los mismos, las condiciones de validación de los datos, la relación entre las diferentes tablas. Por otro lado, la definición de las consultas y los parámetros a utilizar por cada una de ellas. Una vez finalizada la implementación física, se asignan las correspondientes medidas de seguridad y se ubica la base de datos en el lugar correspondiente. 6. - Evaluación y Perfeccionamiento En esta última etapa todos los usuarios del sistema acceden a la base de datos y deben asegurarse el correcto funcionamiento de la misma, que sus derechos son los adecuados, teniendo a su disposición cuanta información necesiten. También deberán asegurarse que el acceso a los datos es cómodo, práctico, seguro y que se han eliminado, en la medida de lo posible, las posibilidades de error. El administrador se asegura que todos los derechos y todas las restricciones han sido implementadas correctamente y que se ha seguido en manual de estilo en la
totalidad de la implementación. El validador se asegurará que todas las necesidades del cliente han sido satisfechas. Criterios de calidad Bases de datos-modelo de datos-criterios de calidad Legibilidad El diseño de una base de datos ha de estar redactado con la suficiente claridad para que pueda ser entendido rápidamente. El lenguaje utilizado debe ser lo suficientemente claro, conciso y detallado para que explique con total claridad el diseño del modelo, sus objetivos, sus restricciones, en general todo aquello que afecte al sistema de forma directa o indirecta. En este punto conviene aplicar el principio que una imagen vale más que mil palabras, pero en ocasiones son necesarias esas mil palabras y obviar la imagen. Fiabilidad Se trata de realizar un sistema de bases de datos lo suficientemente robusto para que sea capaz de recuperarse frente a errores o usos inadecuados. Se deben utilizar gestores con las herramientas necesarias para la reparación de los posibles errores que las bases de datos pueden sufrir, por ejemplo tras un corte inesperado de luz. Portabilidad El diseño deber permitir la implementación del modelo físico en diferentes gestores de bases de datos. Modificabilidad Ningún sistema informático es estático, las necesidades de los usuarios varían con el tiempo y por lo tanto las bases de datos se deben adaptar a las nuevas necesidades, por lo que se precisa que un buen diseño facilite el
mantenimiento, esto es, las modificaciones y actualizaciones necesarias para adaptarlo a una nueva situación. Eficiencia Se deben aprovechar al máximo los recursos de la computadora, minimizando la memoria utilizada y el tiempo de proceso o ejecución, siempre que no sea a costa de los requisitos anteriores. En este punto se debe tener en cuenta los gestores cliente / servidor de bases de datos. En muchas ocasiones es más rentable cargar de trabajo al servidor y liberar recursos de los clientes, pero no todos los gestores permiten este tipo de trabajo, por lo tanto se ha de tener en cuenta estas dos circunstancias en el diseño de la base de datos. Auto descripción En la documentación generada debe estar todo el detalle del diseño, evitando referencias a otros documentos que no estén incluidos dentro de la documentación de la base de datos. Trivialidad Tanto el diseño como la implantación se deben realizar utilizando los estándares fijados a priori, estos estándares deberán quedar reflejados al inicio del documento. Claridad Todos los documentos deben estar redactados de forma clara y fácil de entender, los nombre utilizados para las tablas, los campos, índices, etc. deben ser autodescriptivos y estar perfectamente documentados. Coherencia Las anotaciones y terminología utilizada deben ser uniformes, para ello se debe seguir algún tipo de metodología estándar, indicado cual se ha empleado, en los casos en que se utilice alguna metodología no estándar se debe adjuntar a la documentación. Completo
Todos los elementos constitutivos de la base de datos existen, no se han dejado partes incompletas, sin documentar o sin implementar. Concisión No existen elementos inútiles ni repetitivos. En este apartado hay que hacer un especial hincapié en la repetición de datos en diferentes tablas, hay que evitar a toda costa que el mismo dato se repita en varias tablas para conseguir así una optimización del tamaño de la base de datos. Facilidad de Aprendizaje La documentación de la base de datos se puede utilizar sin necesidad de otros conocimientos informáticos fuera del alcance del diseño e implementación de la base de datos. Facilidad de Uso Los datos deben ser fáciles de elaborar y los resultados fáciles de entender. Generalidad La base de datos debe ser capaz de adaptarse a cualquier tipo de empresa y a cualquier casuística. Independencia de Usuario La base de datos no debe estar ligada a la utilización en una única instalación, hay que tener en cuenta que, aunque se trate de un desarrollo a medida, en un futuro se podría realizar la instalación en un cliente diferente al inicial. Independencia de Sistema Las prestaciones y diseño de la base de datos no están vinculadas al entorno. Independencia de Instalación La base de datos se puede transportar fácilmente de una instalación a otra.
Modularidad La base de datos puede ser descompuesta en elementos independientes. Si se trata de un diseño grande, en donde hay un gran número de tablas, conviene realizar agrupaciones entre ella, creando módulos funcionales que permitan la mejor compresión del diseño y de la implantación. Observable La base de datos debe permitir observar los accesos a los datos. Siempre que se pueda hay que dejar un rastro de la utilización de los datos por parte de los usuarios, esta información ayuda al redimensionado de la base de datos y a conocer el número de accesos a los datos. Precisión Los cálculos efectuados se deben realizar con la precisión requerida. Protección La base de datos debe permitir la protección de los datos frente a usos no debidos, para ello hay que elaborar un sistema de accesos definiendo diferentes usuarios con diferentes claves y especificar que autorizaciones tendrá cada usuario sobre los diferentes datos. Trazabilidad Tomando como punto de partida la versión actual se puede remontar su diseño hasta las especificaciones iniciales. Indicadores de calidad Bases de datos-modelo de datos-indicadores de calidad Al finalizar el diseño de una base de datos podemos utilizar la siguiente tabla para comprobar el grado de calidad del trabajo. 1 2 3 4 5 6 7 8 9 10
Legibilidad Fiabilidad Portabilidad Modificabilidad Eficiencia Auto Descripción Trivialidad Claridad Coherencia Completo Conciso Facilidad de Aprendizaje Facilidad de Uso Generalidad Independencia de Usuario Independencia del Sistema Independencia de Instalación Modularidad Observable Precision Protección Trazable Legibilidad TOTAL PUNTUACION FINAL El modelo lógico Bases de datos-modelo de datos-el modelo lógico
Anteriormente se expuso el ciclo de vida del desarrollo de una base de datos. Este capítulo se centrará en el diseño del modelo lógico de los datos, por tanto antes de comenzar esta modelación es necesario tener documentado las necesidades, viabilidad y definición de los requisitos, así como tener elaborado el modelo global o conceptual del diseño. El paso del modelo global o conceptual de datos al modelo lógico supone una abstracción, un mecanismo para la conversión del mundo real a un mundo formado por datos, a su agrupación y clasificación. El proceso de abstracción consiste en identificar los elementos ó conceptos empleados en el modelo global y transformarlo en lo que denominamos entidades en el modelo lógico. La abstracción se puede realizar de las siguientes formas: Clasificación Consiste en generar una única entidad conceptos con características comunes, todos ellos tendrán las mismas características y se diferencian unos de otros por los valores que toman dichas características. Por ejemplo: los conceptos cursos de inglés, cursos de español y cursos de francés se pueden agrupar en una única entidad denominada "CURSOS" que englobe y diferencie cada uno de los diferentes cursos que se imparten. Agregación Consiste en separar cada una de las partes de un concepto para generar distintas entidades, por ejemplo el concepto coche lo podemos definir utilizando las entidades rueda, motor y chasis. Generalización
Consiste en ir generado entidades de diferentes niveles de tal forma que cada entidad de nivel superior agrupe las de nivel inferior. Asociación Consiste en la generalización de entidades a partir de entidades ya existentes. Restricciones de integridad Bases de datos-modelo de datos-restricciones de integridad En el mundo real existen ciertas restricciones que deben cumplir los elementos en él existentes; por ejemplo, una persona sólo puede tener un número de DNI y una única dirección oficial. Cuando se diseña una base de datos se debe reflejar fielmente el universo del discurso que estamos tratando, lo que es los mismo, reflejar las restricciones existentes en el mundo real. Los componentes de una restricción son los siguientes: La operación de actualización (inserción, borrado o eliminación) cuya ejecución ha de dar lugar a la comprobación del cumplimiento de la restricción.
La condición que debe cumplirse, la cual es en general una proposición lógica, definida sobre uno o varios elementos del esquema, que puede tomar uno de los valores de verdad (cierto o falso). La acción que debe llevarse a cabo dependiendo del resultado de la condición. En general, se puede decir que existen tres tipos de integridad: Integridad de dominio: restringimos los valores que puede tomar un atributo respecto a su dominio, por ejemplo EDAD >= 18-65. Integridad de entidad: la clave primaria de una entidad no puede tener valores nulos y siempre deberá ser única, por ejemplo DNI. Integridad referencial: las claves ajenas de una tabla hija se tienen que corresponder con la clave primaria de la tabla padre con la que se relaciona. Por ejemplo, en la tabla familiares de los empleados necesitaremos el DNI de empleado, que es la clave ajena de la tabla. Las restricciones se clasifican en: A. Inherentes o Están impuestas por el modelo, o No tiene que ser definidas por el usuario, ya que se encuentran en el propio modelo, o Se activan en el momento de la definición del esquema cuando se produce un intento de violación, o Se rechaza todo esquema que no cumple estas restricciones, o Introducen rigideces en el modelo. B. Semánticas o Impuestas por el universo del discurso, o Tienen que ser definidas por los diseñadores, o Se activan en el momento de la actualización de la base de datos, o Se rechaza todo ejemplar que no cumpla estas restricciones (o se ponen en marcha otros medios a fin de que no se produzca un estado de inconsistencia), o Ayudan a capturar la semántica de los datos y a conseguir su consistencia. 1. Ajenas Se especifican en los programas de aplicación, No están almacenadas en el esquema de la base de datos, Pueden ser violadas por actualizaciones en las que no se haya programado la restricción, El sistema de bases de datos no puede comprobar si son consistentes en sí mismas. El optimizador no puede tomarlas en consideración, Proporcionan el máximo de flexibilidad,
Pueden ser programadas en un lenguaje de propósito general o en algún lenguaje propio del sistema de bases de datos, Suponen una importante carga de programación y mantenimiento. 2. Propias Se identifican en el esquema, Están almacenadas en el esquema de la base de datos, No pueden ser violadas por ninguna actualización. a. Acción General Es obligatorio especificar la condición y la acción, Son procedimentales (al menos en parte, ya que la acción se especifica siempre mediante un procedimiento), Suponen carga de programación, Es muy difícil (prácticamente imposible en la mayor parte de los casos) que el sistema de bases de datos pueda comprobar su consistencia, El optimizador no puede tomarlas en consideración, Hasta ahora no están estandarizadas, Están muy ligadas a los productos, Son muy flexibles, Tienen nombre y existencia propia dentro del programa. i. Procedimientos almacenados Es obligatorio especificar la condición (además de la acción), Son totalmente procedimentales, Pueden ser tan complejas como imponga la semántica del mundo real (tanto en la condición como en la acción), Son las más flexibles dentro de las restricciones propias. ii. Disparadores Combinan los enfoques declarativo (en la condición) y procedimental (en la acción),
Pueden ser tan complejas como imponga la semántica del mundo real en cuanto a la acción, y bastantes complejas en la condición (todo lo que permite la proposición lógica mediante la que se expresa la condición), El cumplimiento de la condición dispara la acción, Son más flexibles que las restricciones de acción específica. b. Acción Específica La acción está implícita en la misma restricción, por lo que no hay que definirla, Son declarativas, puesto que no especifica la acción y la condición, si se define, es declarativa, El no cumplimiento de la condición lleva a aplicar la acción, Podrían ser definidas mediante un lenguaje de tipo general, El sistema de bases de datos puede comprobar si son consistentes en sí mismas, El optimizador puede tomarlas en consideración, No suponen carga de programación, sólo de definición. i. Condición General No se especifica la acción, que es siempre de rechazo (el no cumplimiento de la condición lleva consigo el rechazo de la actualización), Es obligatorio declarar la condición mediante una proposición lógica que permite condiciones de complejidad arbitraria,
Además de la condición, se puede especificar algún otro componente, Son más flexibles que las de condición específica, Es más difícil optimizar su ejecución que en el caso de las de condición específica. I. Verificación II. Aserción ii. Condición Específica No tienen existencia en sí mismas, Su definición forma parte de la definición del elemento afectado por la restricción, Se aplican a un único elemento y aunque pueden afectar a otros, en este caso se complica su definición, Pueden no tener nombre. Tienen existencia por sí mismas, Se definen con independencia de cualquier elemento del esquema, Pueden afectar a más de un elemento, Tienen nombre.
Son opciones proporcionadas por el propio modelo, No se especifica ninguno de los componentes relativos a una restricción (ni la operación, ni la condición, ni la acción), Son poco flexibles, El optimizador puede tomarlas en consideración, Su ejecución puede ser más fácilmente optimizada que las de condición general. Los Usuarios Bases de datos-modelo de datos-los usuarios En todo sistema de base de datos cabe diferenciar tres tipos diferentes de usuarios, entre todos comparten la información pero acceden a ella de una forma diferente, siempre en función de sus necesidades. El primer grupo de usuarios es el PED (Procesamiento Electrónico de Datos), normalmente compuestos por los operarios de la organización. Las necesidades básicas de este grupo de usuarios son: El foco operativo fundamental se centra en el almacenamiento de los datos, el procesamiento de los mismos y el flujo de datos; Generan informes de tipo listados; Poseen acceso restringido a la información. El segundo grupo de usuarios es el SIM (Sistemas de Información de Gestión) y suele estar formado por los mandos medios de la organización. Las necesidades básicas de este grupo de usuarios son: El foco operativo se fundamenta en la toma de decisiones, tomando como partida los datos del grupo PED e introduciendo un volumen pequeño de información; No poseen acceso medianamente restringido a la información;
Generan informes de resúmenes de datos del grupo PED y listados de la información que introducen. El tercer último grupo de usuarios lo forman el STD (Sistema de apoyo a Toma de Decisiones), este grupo se centra en el nivel más alto de la organización y poseen las características siguientes: El foco operativo se centra en la decisión, con una entrada mínima de datos; No tienen acceso restringido; Generan informes globales que les sirven como apoyo a las tomas de decisiones del negocio, estos son los informes más importantes y suelen ir acompañados de resúmenes, gráficas y sobre todo centrados en la evolución y comparación de la información. Cabe destacar la figura de un cuarto grupo de usuarios, en este caso usuarios avanzados, que está compuesto por los administradores del sistema, cuya opinión es fundamental para seleccionar el soporte de los datos, evitar la duplicación de información ya existente en otros sistemas y sobre todo puede aportar el conocimiento de sus usuarios, sus necesidades y los problemas ya resueltos. En general, podemos decir que los objetivos de una base de datos son los siguientes: Ayudar en la toma de decisiones; Compartir de forma controlada y restringida los datos y el acceso a la información; Integrar los datos de una forma lógica, evitando la duplicidad; Asegurar un rápido acceso a la información y los datos.