- Generación de un sistema de base de datos
Un Sistema de Bases de Datos (SBD) es una serie de recursos para manejar grandes volúmenes de información, sin embargo no todos los sistemas que manejan información son bases de datos.
Un sistema de bases de datos debe responder a las siguientes características:
Independencia de los Datos. Es decir, que los datos no dependen del programa y por tanto cualquier aplicación puede hacer uso de los datos.
Reducción de la Redundancia. Llamamos redundancia a la existencia de duplicación de los datos, al reducir ésta al máximo conseguimos un mayor aprovechamiento del espacio y además evitamos que existan inconsistencias entre los datos. Las inconsistencias se dan cuando nos encontramos con datos contradictorios.
Seguridad. Un SBD debe permitir que tengamos un control sobre la seguridad de los datos.
Un SBD está formado por:
Personas
Maquinas
Programas
Son los encargados de manejar los datos, son conocidos como DBMS (Data Base Management System) o también SGBD (Sistema Gestor de Base de Datos). Los DBMS tienen dos funciones principales que son:
La definición de las estructuras para almacenar los datos.
La manipulacion de datos.
Es lo que se conoce como base de datos propiamente dicha. Para manejar estos datos utilizamos una serie de programas.
Los SBD pueden ser estudiados desde tres niveles distintos:
1 Nivel Físico Es el nivel real de los datos almacenados. Es decir como se almacenan los datos, ya sea en registros, o como sea. Este nivel es usado por muy pocas personas que deben estar cualificadas para ello. Este nivel lleva asociada una representación de los datos, que es lo que denominamos Esquema Físico. 2 Nivel Conceptual Es el correspondiente a una visión de la base de datos desde el punto de vista del mundo real. Es decir tratamos con la entidad u objeto representado, sin importarnos como está representado o almacenado. Este nivel lleva asociado el Esquema Conceptual. 3 Nivel Visión Son partes del esquema conceptual. El nivel conceptual presenta toda la base de datos, mientras que los usuarios por lo general sólo tienen acceso a pequeñas parcelas de ésta. El nivel visión es el encargado de dividir estas parcelas. Un ejemplo sería el caso del empleado que no tiene porqué tener acceso al sueldo de sus compañeros o de sus superiores. El esquema asociado a éste nivel es el Esquema de Visión.
Los tres niveles vistos, componen lo que conocemos como arquitectura de base de datos a tres niveles. A menudo el nivel físico no es facilitado por muchos DBMS, esto es, no permiten al usuario elegir como se almacenan sus datos y vienen con una forma estándar de almacenamiento y manipulación de los datos. La arquitectura a tres niveles se puede representar como sigue:
Modelo Relacional de Datos
Modelo de Red
Modelo Jerarquico - Los sistemas de base de datos son los recursos mas indispensables para almacener grandes cantidades de información
- http://www.wikilearning.com/curso_gratis/sistemas_de_bases_de_datos/3621-1
jueves, 29 de abril de 2010
generacion de un sistema de una base de datos
diseño fisico de una base de datos
- Diseño físico de una base de datos
El diseño de una base de datos se descompone en tres etapas: diseño conceptual, lógico y físico. La etapa del diseño lógico es independiente de los detalles de implementación y dependiente del tipo de SGBD que se vaya a utilizar. La salida de esta etapa es el esquema lógico global y la documentación que lo describe. Todo ello es la entrada para la etapa que viene a continuación, el diseño físico.
Mientras que en el diseño lógico se especifica qué se guarda, en el diseño físico se especifica cómo se guarda. Para ello, el diseñador debe conocer muy bien toda la funcionalidad del SGBD concreto que se vaya a utilizar y también el sistema informático sobre el que éste va a trabajar. El diseño físico no es una etapa aislada, ya que algunas decisiones que se tomen durante su desarrollo, por ejemplo para mejorar las prestaciones, pueden provocar una reestructuración del esquema lógico.
Metodología de diseño físico para bases de datos relacionales
El objetivo de esta etapa es producir una descripción de la implementación de la base de datos en memoria secundaria. Esta descripción incluye las estructuras de almacenamiento y los métodos de acceso que se utilizarán para conseguir un acceso eficiente a los datos.
El diseño físico se divide de cuatro fases, cada una de ellas compuesta por una serie de pasos:
Traducir el esquema lógico global para el SGBD específico. Diseñar las relaciones base para el SGBD específico. Diseñar las reglas de negocio para el SGBD específico. Diseñar la representación física. Analizar las transacciones. Escoger las organizaciones de ficheros. Escoger los índices secundarios. Considerar la introducción de redundancias controladas. Estimar la necesidad de espacio en disco. Diseñar los mecanismos de seguridad. Diseñar las vistas de los usuarios. Diseñar las reglas de acceso. Monitorizar y afinar el sistema. Traducir el esquema lógico global
La primera fase del diseño lógico consiste en traducir el esquema lógico global en un esquema que se pueda implementar en el SGBD escogido. Para ello, es necesario conocer toda la funcionalidad que éste ofrece. Por ejemplo, el diseñador deberá saber:
Si el sistema soporta la definición de claves primarias, claves ajenas y claves alternativas. Si el sistema soporta la definición de datos requeridos (es decir, si se pueden definir atributos como no nulos). Si el sistema soporta la definición de dominios. Si el sistema soporta la definición de reglas de negocio. Cómo se crean las relaciones base. - El diseño fisico es darle formato a la presentacion de tu base de datos.
- http://www.mailxmail.com/curso-diseno-base-datos-relacionales/diseno-fisico-bases-dat
transformacion al modelo de una base de datos
- Transformación al modelo de base de datos (o fase de diseño lógico).
En esta fase se crea un esquema conceptual y los esquemas externos necesarios en el modelo de datos del SGBD seleccionado, mediante la transformación de los esquemas de modelo de datos a alto nivel obtenidos, al modelo de datos ofrecido por el SGBD.
El método para el desarrollo de BD XML parte del modelo conceptual de datos representado
mediante un diagrama de clases UML. Este modelo se abstrae completamente de la
plataforma final en la que se desplegará la BD y por tanto se considera el modelo a nivel PIM.
Este PIM se podría utilizar como modelo de partida en el desarrollo de cualquier otro tipo de
BD, y de hecho en la propuesta de MIDAS se contempla también como punto de partida en el
desarrollo de la BDOR [15] y se utiliza para el desarrollo del hipertexto [16]. El siguiente
paso es la generación del modelo de datos para una plataforma concreta, es decir se piensa ya
en la plataforma en la que se desplegará finalmente la BD y se habla por tanto de modelo
PSM. Éste modelo no es más que la representación del esquema de la BD, que en el caso de
una BD XML, se recoge en un XML Schema que define la estructura de los documentos
XML que se almacenarán en la BD. MIDAS propone la utilización de estándares a lo largo de
Juan M. Vara, Belén Vela, Esperanza Marcos
4
todo el proceso de desarrollo, y más concretamente el uso de UML como notación para
cualquier actividad de modelado, pero UML no incluye soporte para el modelado de XML
Schemas. Una posible solución sería modificar el metamodelo de UML, pero esta solución es
demasiado drástica. UML, sin embargo, ha sido diseñado para que pueda extenderse de una
forma controlada y proporciona para ello sus propios mecanismos de extensión para cubrir la
necesidad de flexibilidad. Dichos mecanismos permiten crear nuevos bloques de construcción
por medio de estereotipos, valores etiquetados y restricciones recogidos todos ellos en lo que
se denomina perfil UML. Así, como parte de la propuesta para el desarrollo de BD XML, se
ha definido un perfil UML para el modelado de XML Schemas. Dicho perfil permite
representar gráficamente los componentes específicos del estándar XML Schema
conservando el orden y grado de anidamiento dado.
Tanto el perfil propuesto como el metamodelo que resulta de aplicar el perfil se han
presentado anteriormente en [13] y [14], así pues se remite al lector a dichos trabajos para una
mejor comprensión del modelado de XML Schemas en UML.
3. DEL MODELO CONCEPTUAL AL ESQUEMA DE LA BD
Como ya se ha mencionado, MIDAS sigue una aproximación dirigida por modelos para el
desarrollo de SIW y por tanto, considera los modelos como actores de primer orden a lo largo
de todo el proceso de desarrollo. En este contexto se puede pensar en el proceso de desarrollo
como el conjunto de tareas a completar para generar los distintos modelos incluidos en el
proceso. En el caso concreto que se aborda en este trabajo, la transformación resulta
relativamente sencilla: se toma como entrada el modelo conceptual y se obtiene como salida
del proceso el modelo que representa el esquema de la BD XML, esto es, el XML Schema
que dicta la estructura de la BD XML que almacenará los documentos XML. A continuación
se definen formalmente estas transformaciones, primero definiéndolas como reglas
expresadas en lenguaje natural para posteriormente formalizarlas utilizando una aproximación
basada en gramáticas de grafos.
3.1. Reglas de Transformación entre PIM y PSM expresadas en lenguaje natural
De acuerdo con [12], “la descripción de los mappings puede realizarse en lenguaje natural,
un algoritmo en un action language o un modelo en un lenguaje de transformación”. En
nuestro caso, y como una primera aproximación a las transformaciones de modelos para el
desarrollo de BD XML, se ha optado por describir las reglas de transformación en
lenguaje natural, para después expresarlas por medio de gramáticas de grafos. Dichas
reglas se recogen en la tabla 1.
Reglas de Transformación de PIM a PSM
Modelo Conceptual a Modelo XML Schema
1. Cada clase del modelo conceptual corresponderá a un elemento en el XML Schema con el mismo nombre
de la clase. Además, para especificar el tipo del elemento, se incluirá un nuevo complexType inline, o si se
opta por definirlo con nombre se utilizará la expresión nombreclase_type para nombrarlo. El elemento y el
complexType se relacionarán por medio de una asociación uses
Juan M. Vara, Belén Vela, Esperanza Marcos
5
2. Los atributos de una clase se recogerán en el XML Schema como subelementos del complexType que
sirve para definir el tipo del elemento que representa a la clase
2.1. En el caso de atributos obligatorios el valor de la propiedad minOccurs del subelemento será 1 (éste
es el valor por defecto)
2.2. En el caso de atributos opcionales el valor de la propiedad minOccurs del subelemento será 0
2.3. En el caso de atributos multivaluados el valor de la propiedad maxOccurs del subelemento será
unbounded
2.4. En el caso de atributos compuestos el subelemento será de tipo complexType anónimo. Dicho
complexType utilizará el compositor sequence para incluir un subelemento por cada componente del
atributo compuesto
2.5. En el caso de atributos enumerados el subelemento será de un tipo simpleType anónimo. Este
simpleType se relacionará con una clase enumeration donde se especificaran los posibles valores del
atributo
3. Una asociación entre 2 clases se recogerá incluyendo un subelemento en uno de los complexType
correspondiente a las clases que participan en la asociación, ya que se recogerán siempre como
asociaciones unidireccionales. El subelemento recibirá el mismo nombre que la asociación que representa.
Dicho subelemento, de tipo REF, referenciará al elemento que corresponde a la otra clase que participa en
la asociación. El valor del atributo minOccurs de dicho subelemento dependerá de la multiplicidad mínima
de la asociación (0 ó 1) y el valor del atributo maxOccurs será 1
3.1. Si la multiplicidad es 1:N el subelemento se incluirá forzosamente en el complexType que
corresponde a la clase de multiplicidad N.
3.2. Si la multiplicidad es N:M el valor del atributo maxOccurs será unbounded
4. Las relaciones de agregación se recogerán incluyendo un subelemento en el complexType
correspondiente a la clase que actúa como TODO en la relación. Para nombrarlo se utilizará el nombre de
la relación y, en su defecto, la cadena is_aggregated_of. El subelemento será de tipo REF y referenciará al
elemento correspondiente a la clase que actúa como PARTE. El valor del atributo minOccurs de dicho
subelemento dependerá de la multiplicidad mínima de la asociación (0 ó 1)
4.1. Si la multiplicidad máxima de la relación es N, el valor de la propiedad maxOccurs del subelemento
será unbounded
5. Las relaciones de composición se recogerán incluyendo un subelemento en el complexType
correspondiente a la clase que actúa como TODO. Para nombrarlo se utilizará el nombre de la relación y,
en su defecto, la cadena is_composed_of. Este subelemento será de tipo complexType anónimo y utilizará
el compositor all para incluir un conjunto de elementos del tipo del complexType correspondiente a la/s
clase/s que actúan como PARTE en la composición
6. En las relaciones de generalización el complexType utilizado para definir el tipo del elemento que
representa a la clase hija será una extensión del complexType correspondiente a la clase padre.
Tabla 1. Reglas de Transformación PIM – PSM (Modelo Conceptual – Modelo XML Schema). - En esta se crea un esquema conceptual y los externos.
- http://www.slideshare.net/tramullas/bases-de-datos-1176222
http://personales.unican.es/ruizfr/bda/doc/teo/5/bda-t5-diseno-kybele.pdf
eleccion de un gestor de una base de datos
- Elección de un sistema gestor de una base de datos
Un gestor de base de datos o sistema de gestión de base de datos (SGBD o DBMS) es un software que permite introducir, organizar y recuperar la información de las bases de datos; en definitiva, administrarlas. Existen distintos tipos de gestores de bases de datos: relacional, jerárquico, red,... El modelo relacional es el utilizado por casi todos los gestores de bases de datos para PC´s. El modelo relacional (SGBDR) es un software que almacena los datos en forma de tablas
Características Generales de los Sistemas Gestores de B.D.
Aunque hay multitud de aplicaciones para la Gestión de Bases de Datos diferentes en características y precios, podemos encontrar aspectos comunes en todos ellos:
Aceptan definiciones de esquemas y vistas (definición de diferentes bases de datos).
Manipulan los datos siguiendo las órdenes de los usuarios.
Cuidan que se respete la seguridad e integridad de los datos.
Permiten definir usuarios y las restricciones de acceso para cada uno de ellos.
Controlan la concurrencia y las operaciones asociadas a la recuperación de los fallos. - Los sistemas gestores organiza y recupera informacion en la base de datos.
- http://www.wikilearning.com/tutorial/introduccion_a_las_bases_de_datos-tipos_de_gestores_de_bases_de_datos/10147-2
diseño conceptual de la base de datos
- Diseño conceptual de la base de datos
Conjunto de actividades que resultan en un esquema conceptual de alto nivel de una base de datos, independiente del software gestor (SGBD), partiendo de especificaciones de requerimientos.
El diseño conceptual de una base de datos suele hacerse empleando un DER
Las personas encargadas de esta tarea suelen llamarse diseñadores de bases de datos.
El diseño conceptual de una base de datos forma parte del proceso de diseño de la base de datos completa, que incluye el diseño conceptual, diseño lógico y diseño físico de la misma.
Desarrollo del diseño conceptual de una base de datos
El diseño conceptual parte de los requerimientos, resultando en un esquema conceptual de base de datos.
El esquema conceptual sirve luego para el diseño lógico de base de datos. - El diseño conceptual por lo que entendi es para sintetizar la informacion asi como cuando hacemos algun esquema conceptual.
- http://www.alegsa.com.ar/Dic/dise%C3%B1o%20conceptual%20de%20bases%20de%20datos.php
recoleccion y analisis de informacion
- Recolección Y Análisis de Información
Epi Info es un conjunto de programas de microcomputadora para manejar datos en formato de cuestionario y para organizar los resultados en texto que puede formar parte de informes escritos. Se puede confeccionar un cuestionario en pocos minutos, pero, a la vez, Epi Info puede ser la base para una poderosa base de datos de un sistema de vigilancia epidemiológica con muchos tipos de archivos y registros. Incluye los elementos más comúnmente utilizados por los epidemiólogos de programas estadísticos (como SAS o SPSS) y bases de datos (como dBASE) combinados en un sólo sistema. Al contrario que los programas comerciales Epi Info puede ser copiado libremente y regalado a amigos y colegas.
Hay tres niveles de aplicación de Epi Info para procesar cuestionarios u otros datos estructurados. Utilizado de la manera más simple, puede preparar un cuestionario o formulario en pocos minutos haciendo lo siguiente:
Activar el menú principal
Confeccionar un cuestionario con EPED, el procesador de textos
Introducir datos con el programa ENTER
Analizar los datos usando el programa ANALYSIS, produciendo listados, frecuencias, cruces, medias, gráficas o estadísticas complementarias.
A medida que conozca mejor el programa, podrá utilizar más prestaciones del programa e introducir o analizar datos de una manera más acorde a sus necesidades. Podría querer, en el segundo nivel de dificultad:
Impedir errores al teclear datos, definir patrones de salto o hacer codificación automática
Seleccionar registros, crear nuevas variables, recodificar y manipular datos y realizar operaciones condicionales durante el ANALYSIS.
Incorporar estas operaciones en programas que permitan realizarlas repetidamente o por otras personas no familiarizadas con la programación.
Importar y exportar archivos de otros sistemas, como SAS, SPSS, DBASE y Lotus 1-2-3
Cambiar los nombres de las variables de los archivos usando CHECK.
El tercer nivel de dificultad es importante si quiere mantener un sistema permanente de datos, hacer un estudio amplio o adaptar las operaciones de Epi Info a necesidades especiales. Para tales propósitos, podría:
Programar el procedimiento de introducción de datos para realizar operaciones matemáticas, depuración de errores, cambios de colores, ventanas desplegables y rutinas especiales escritas en otros lenguajes.
Especificar el formato de los informes desde ANALYSIS para producir tablas a medida.
Introducir datos en más de un archivo durante la misma sesión, moviéndose automáticamente entre varios cuestionarios dentro de ENTER.
Relacionar diferentes tipos de archivos en ANALYSIS, de forma que se puedan responder a cuestiones que requieran más de un archivo.
Comparar archivos duplicados introducidos por diferentes operadores para detectar errores en la introducción de datos.
EPED, el editor incluido en la Versión 6, contiene un sistema para programar textos llamado EPIAID, que ayuda a estructurarlos. Se incluyen los programas para guiarle en la creación de cuestionarios y en el diseño de una investigación. El texto producido se puede utilizar como parte de un informe. Los programas de EPIAID pueden usarse para escribir cartas o informes con otros propósitos.
La Versión 6 contiene una serie de características nuevas, como un sistema de menús desplegables configurable, órdenes nuevas para la programación en ANALYSIS y ENTER, capacidad para ordenar y relacionar archivos muy grandes, un programa para analizar estudios a partir de muestras complejas, una calculadora epidemiológica nueva, y un programa para el procesamiento automatizado de datos antropométricos. Los archivos creados en las versiones previas de Epi Info se pueden usar en la versión 6. Los programas escritos en la Versión 5 pueden funcionar en la Versión 6 con muy pocas correcciones.
Los programas incluidos en Epi Info son:
EPI6. El menú principal, que permite acceder a otros programas. Es también un menú completamente configurable que puede utilizar con otros programas. Incluye un editor, funciones de menú programables, y la capacidad de visualizar hipertextos.
EPED. Es un procesador de textos para confeccionar cuestionarios o para uso general. Tiene una ayuda especial llamada EPIAID para hacer programas que ayuden a la preparación de textos y en el diseño de investigaciones epidemiológicas.
ENTER. Permite introducir los datos del cuestionario en un archivo. El cuestionario ha sido creado previamente mediante EPED u otro procesador de textos. Permite revisar el formato del archivo incluso después de haber introducido datos.
ANALYSIS. Produce listados, frecuencias, cruces de variables y otros resultados desde archivos de Epi Info o de DBASE. Las tablas se acompañan de cálculos estadísticos apropiados, como Razón de Ventajas (Odds Ratio), riesgo relativo, límites de confianza exactos y valores de p. Realiza análisis estratificado con la técnica de Mantel-Haenzsel, test de Kruskal-Wallis y ANOVA, regresión lineal y análisis de estudios de casos-control con emparejamiento (matching). Los registros pueden ser seleccionados u ordenados de acuerdo con variables definidas, condiciones ("if") y operaciones matemáticas o lógicas. Asimismo se realizan gráficos, informes de formato complejo, generación de una serie de datos y un lenguaje de programación. Se pueden analizar varias bases de datos como si se tratase de una sola.
CHECK. Permite establecer rangos, valores válidos, codificación automática y preguntas encadenadas. Se utiliza opcionalmente con el programa ENTER. Permite hacer operaciones matemáticas y lógicas entre campos, patrones de salto complejos, acceso a varios archivos en el mismo proceso de introducción de datos y uso de programas adaptados a las necesidades de los usuarios.
CSAMPLE. Analiza datos de estudios con muestras complejas, teniendo en cuenta muestreo de aglomerados, estratificación y ponderaciones.
STATCALC. Realiza cálculos estadísticos sobre tablas introducidas desde el teclado, tamaño de una muestra y análisis simple y estratificado de una tendencia.
EPITABLE. Una calculadora epidemiológica teniendo muchas estadísticas de utilidad.
EPINUT. Un programa para antropometría nutricional que suministra cálculos seriados de índices antropométricos.
EXPORT. Exporta archivos de datos de formato Epi Info en 12 tipos de archivo con formato de otros programas estadísticos o de bases de datos.
IMPORT. Mediante este programa, se leen archivos de otros programas y se crea uno con formato de Epi Info.
MERGE. Une archivos con cuestionarios diferentes o revisados. Permite combinar datos introducidos en distintas computadoras y actualizar los registros con nuevas entradas de datos.
VALIDATE. Compara dos archivos Epi Info introducidos por operado- res diferentes e informa de las diferencias.
Archivos de ayuda. Se suministra el manual completo de Epi Info, Versión 6, en formato electrónico. Está accesible desde el menú principal. Gran parte del material de la sección de referencia de este manual está disponible en cada programa pulsando dentro del mismo.
Prg. de ejemp. Se suministra un sistema de vigilancia de enfermedades declarables completo, archivos de dos investigaciones epidemiológicas y un sistema de cálculos antropométricos en estudios nutricionales. Hay, además, numerosos archivos pequeños y muchos ejemplos de programación en este manual.
Tutores. Existen tutores interactivos completos que introducen a las características de EPED, ENTER y ANALYSIS.
Utilitarios. Se suministra el utilitario REC2QES para crear un cuestionario a partir de un .REC ya existente.
Para usar Epi Info, Versión 6, se requiere una microcomputadora PC compatible cuyo sistema operativo sea PC-DOS o MS-DOS (versión 2 o posteriores), que disponga de 512 (524.288) Kbytes de memoria RAM y, al menos, una unidad de disco flexible. Necesita tarjeta gráfica; el programa funciona en versiones Hércules, monocromo, color, EGA, VGA IBM3270, IBM8514 y AT&T. Se suministran archivos para producir los resultados en 30 tipos de impresoras y formatos de archivo. Para un óptimo uso de Epi Info, se recomienda un disco duro, 640 Kb de RAM y tarjeta gráfica y monitor color.
Epi Info puede utilizar de forma limitada la memoria RAM por encima de 640 si tiene un manejador de memoria, como EMM386 o QEMM. Los programas con archivos overlay (.OVR) pueden activar el overlay en memoria alta para tener más memoria, con lo que trabajarán más rápidamente, pero eso no implica que tenga más RAM.
Los archivos pueden constar de tantos registros como pueda manejar el sistema de almacenamiento (hasta 2000 millones). Un cuestionario puede tener hasta 500 líneas o aproximadamente 20 pantallas. El número de variables no está limitado, excepto por las 500 líneas. La longitud máxima para una variable de texto es de 80 caracteres. La longitud total de las variables en un archivo no debe exceder de 2048 caracteres. Dada la posibilidad de relacionar más de un archivo durante la introducción de datos o el análisis, en la práctica no existen limitaciones. Los programas de Epi Info requieren unos 6 megabytes de espacio en disco, pero sólo ANALYSIS, el programa más grande, excede la capacidad de un disquete de 360.000 caracteres.
Varios programas de Epi Info pueden funcionar, ahora, con ratón. Debe estar activo el controlador del ratón suministrado por el fabricante. Aunque, como en las versiones anteriores, se pueden utilizar fácilmente con el teclado. Las versiones futuras de EPED, ENTER, ANALYSIS y CHECK estarán totalmente adaptadas a ratón, ya que en esta versión no lo pueden utilizar.
Las versiones 1-3 de Epi Info fueron producidas por la Epidemiology Program Office (Centers for Desease Control). La versión 5 fue producida por el CDC y la unidad Surveillance, Forecasting and Impact Assessment del Programa Global del SIDA de la Organización Mundial de la Salud (OMS), Ginebra, Suiza. La versión 6 ha sido mayoritariamente responsabilidad de los autores del CDC. - La recolección y análisis de información es importante en todas las bases de datos ayudan a organizar y tener a la mano los datos que necesitamos.
- http://ns.ccp.ucr.ac.cr/~icamacho/salud_repro/contenido/recoleccion.htm
ciclo de vida de una aplicacion de una base de datos
- Ciclo de vida de una aplicacion de base de datos
Las etapas del ciclo de vida de una aplicación de bases de datos son las siguientes:
Planificación del proyecto
Definición del sistema
Recolección y análisis de los requisitos.
Diseño de la base de datos.
Selección del SGBD.
Diseño de la aplicación.
Prototipado.
Implementación.
Conversión y carga de datos.
Prueba.
Mantenimiento.
Estas etapas no son estrictamente secuenciales. De hecho hay que repetir algunas de las etapas varias veces, haciendo lo que se conocen como ciclos de realimentación. Por ejemplo, los problemas que se encuentran en la etapa del diseño de la base de datos pueden requerir una recolección de requisitos adicional y su posterior análisis. - Las aplicaciones de base de datos tienen un ciclo de vida y aveces hay que repetir algunas para hacer lo que conocemos como ciclos de realimentacion.
- http://www3.uji.es/~mmarques/f47/apun/node67.html
Suscribirse a:
Entradas (Atom)
