Base de datos

Bases de datos

Definición de Base de datos

Almacén de datos relacionados con diferentes modos de organización. Una base de datos representa algunos aspectos del mundo real, aquellos que le interesan al diseñador. Se diseña y almacena datos con un propósito específico. Con la palabra "datos" se hace referencia a hechos conocidos que pueden registrarse, como ser números telefónicos, direcciones, nombres, etc.Las bases de datos almacenan datos, permitiendo manipularlos fácilmente y mostrarlos de diversas formas.

Características

Independencia lógica y física de los datos: se refiere a la capacidad de modificar una definición de esquema en un nivel de la arquitectura sin que esta modificación afecte al nivel inmediatamente superior. Para ello un registro externo en un esquema externo no tiene por qué ser igual a su registro correspondiente en el esquema conceptual.

Redundancia mínima: se trata de usar la base de datos como repositorio común de datos para distintas aplicaciones.

Acceso concurrente por parte de múltiples usuarios: control de concurrencia mediante técnicas de bloqueo o cerrado de datos accedidos.

Distribución espacial de los datos: la independencia lógica y física facilita la posibilidad de sistemas de bases de datos distribuidas. Los datos pueden encontrarse en otra habitación, otro edificio e incluso otro país. El usuario no tiene por qué preocuparse de la localización espacial de los datos a los que accede.

Integridad de los datos: se refiere a las medidas de seguridad que impiden que se introduzcan datos erróneos. Esto puede suceder tanto por motivos físicos (defectos de hardware, actualización incompleta debido a causas externas), como de operación (introducción de datos incoherentes).

Consultas complejas optimizadas: la optimización de consultas permite la rápida ejecución de las mismas.

Seguridad de acceso y auditoría: se refiere al derecho de acceso a los datos contenidos en la base de datos por parte de personas y organismos. El sistema de auditoría mantiene el control de acceso a la base de datos, con el objeto de saber qué o quién realizó una determinada modificación y en qué momento.

Respaldo y recuperación: se refiere a la capacidad de un sistema de base de datos de recuperar su estado en un momento previo a la pérdida de datos.

Acceso a través de lenguajes de programación estándar: se refiere a la posibilidad ya mencionada de acceder a los datos de una base de datos mediante lenguajes de programación ajenos al sistema de base de datos propiamente dicho.

Redundancia

Control sobre la redundancia de datos. 

Los sistemas de ficheros almacenan varias copias de los mismos datos en ficheros distintos. Esto hace que se desperdicie espacio de almacenamiento, además de provocar la falta de consistencia de datos. En los sistemas de bases de datos todos estos ficheros están integrados, por lo que no se almacenan varias copias de los mismos datos. Sin embargo, en una base de datos no se puede eliminar la redundancia completamente, ya que en ocasiones es necesaria para modelar las relaciones entre los datos, o bien es necesaria para mejorar las prestaciones.

Ventajas

Consistencia de datos.

Eliminando o controlando las redundancias de datos se reduce en gran medida el riesgo de que haya inconsistencias. Si un dato está almacenado una sola vez, cualquier actualización se debe realizar sólo una vez, y está disponible para todos los usuarios inmediatamente. Si un dato está duplicado y el sistema conoce esta redundancia, el propio sistema puede encargarse de garantizar que todas las copias se mantienen consistentes. Desgraciadamente, no todos los SGBD de hoy en día se encargan de mantener automáticamente la consistencia.

Más información sobre la misma cantidad de datos. Al estar todos los datos integrados, se puede extraer información adicional sobre los mismos.

Compartición de datos.

 En los sistemas de ficheros, los ficheros pertenecen a las personas o a los departamentos que los utilizan. Pero en los sistemas de bases de datos, la base de datos pertenece a la empresa y puede ser compartida por todos los usuarios que estén autorizados. Además, las nuevas aplicaciones que se vayan creando pueden utilizar los datos de la base de datos existente.

Mantenimiento de estándares. Gracias a la integración es más fácil respetar los estándares necesarios, tanto los establecidos a nivel de la empresa como los nacionales e internacionales. Estos estándares pueden establecerse sobre el formato de los datos para facilitar su intercambio, pueden ser estándares de documentación, procedimientos de actualización y también reglas de acceso

Componentes de una base de datos

· Datos del usuario. En la actualidad, casi todas las bases de datos representan los datos del usuario como afinidades que son tablas de datos. No todas las afinidades son igualmente deseables; algunas están mejor estructuradas que otras. Para crear afinidades bien estructuradas se realiza un proceso llamado normalización.

· Metadatos. Debido a que los productos DBMS están diseñados para almacenar y manipular tablas, la mayor parte de ellos almacenan los metadatos en forma de tablas, algunas veces llamadas tablas del sistema.

· Índices. Están encaminados a mejorar el funcionamiento y la accesibilidad de la base de datos. Se usan para ordenar y para obtener un acceso rápido a los datos. Los índices son muy valiosos pero implican un costo. Cada vez que se actualiza una fila en una afinidad o tabla, también deben actualizarse los índices. Esto no es malo; sólo significa que los índices no son gratuitos y que deben reservarse para casos en los que sean de verdad necesarios.

· Metadatos de aplicación. Se usan para almacenar la estructura y el formato de formas, reportes, consultas de usuarios, y otros componentes de aplicación. Normalmente no se accede de forma directa a los metadatos de aplicación sino que se hace a través de herramientas proporcionadas por el DBMS para tal fin.

Read More

Diagrama de flujo de datos

Diagrama de flujo de datos

Un diagrama de flujo de datos o DFD (sus siglas en español e inglés), se utiliza para hacer varias cosas entre ellas trabajos y tareas. Es una representación gráfica del flujo de datos a través de un sistema de información. Un diagrama de flujo de datos también se puede utilizar para la visualización de procesamiento de datos (diseño estructurado). Es una práctica común para un diseñador dibujar un contexto a nivel de DFD que primero muestra la interacción entre el sistema y las entidades externas.

Los diagramas de flujo de datos fueron inventados por Larry Constantine, el desarrollador original del diseño estructurado, basado en el modelo de computación de Martin y Estrin: "flujo gráfico de datos" . Los diagramas de flujo de datos (DFD) son una de las tres perspectivas esenciales de Análisis de Sistemas Estructurados y Diseño por Método SSADM. El patrocinador de un proyecto y los usuarios finales tendrán que ser informados y consultados en todas las etapas de una evolución del sistema. Con un diagrama de flujo de datos, los usuarios van a poder visualizar la forma en que el sistema funcione, lo que el sistema va a lograr, y cómo el sistema se pondrá en práctica. El antiguo sistema de diagramas de flujo de datos puede ser elaborado y se comparó con el nuevo sistema de diagramas de flujo para establecer diferencias y mejoras a aplicar para desarrollar un sistema más eficiente. Los diagramas de flujo de datos pueden ser usados para proporcionar al usuario final una idea física de cómo resultarán los datos a última instancia, y cómo tienen un efecto sobre la estructura de todo el sistema. La manera en que cualquier sistema es desarrollado, puede determinarse a través de un diagrama de flujo de datos.


Los niveles de un DFD son:

Nivel 0: Diagrama de contexto
Nivel 1: Diagrama de nivel superior
Nivel 2: Diagrama de detalle o expansión

Conexiones entre los elementos de un DFD

Conexiones permitidas

ENTIDAD - PROCESO
PROCESO - ALMACÉN

Conexiones prohibidas

ENTIDAD - ENTIDAD
ALMACÉN - ALMACÉN
ENTIDAD - ALMACÉN


Características de los niveles de un DFD

Diagrama de Contexto: Nivel 0
En el diagrama de contexto se caracterizan todas las interacciones que realiza un sistema con su entorno (entidades externas), estas pueden ser otros sistemas, sectores internos a la organización, o factores externos a la misma. Se dibuja un sólo proceso que representa al sistema en cuestión y se escribe su nombre en dicha burbuja como un sustantivo común más adjetivos. De él solamente parten los flujos de datos que denotan las interrelaciones entre el sistema y sus agentes externos, no admitiéndose otros procesos ni almacenamientos en el dibujo.

ya que estos son procesos estructurados y ordenados, además posee una cardinalidad que varia según la función que desempeñe cada diagrama
Resulta de gran utilidad para los niveles posteriores de análisis como herramienta de balanceo. Y es conocido como el Diagrama de Flujo de Datos DFD de Nivel "0".

Diagrama de Nivel Superior: Nivel 1
En el diagrama de nivel superior se plasman todos los procesos que describen al proceso principal. En este nivel los procesos no suelen interrelacionarse directamente, sino que entre ellos debe existir algún almacenamiento o entidad externa que los una. Esta regla de construcción sirve como ayuda al analista para contemplar que en un nivel tan elevado de abstracción (DFD Nivel 1) es altamente probable que la información que se maneja requiera ser almacenada en el sistema aunque no esté especificado por un Requisito funcional, siendo en realidad un requisito no-funcional.

Diagrama de Detalle o Expansión: Nivel 2
En un diagrama de nivel 3 o mayor, comienzan a explotarse las excepciones a los caminos principales de la información dado que aumenta progresivamente el nivel de detalle. De aquí en adelante se permiten los flujos entre procesos.

El DFD (Diagrama De Flujo De Datos) nivel 2 puede considerarse el máximo para ser validado en forma conjunta con el usuario dado que en los niveles posteriores el alto grado de complejidad del diagrama puede resultar de muy difícil lectura para personas ajenas al equipo de sistemas. También se recomienda el diagrama de nivel superior.

Read More

Fases de vida de un sistema

Según la metodología de Kendall & Kendall el ciclo de vida de un sistema consta de siete partes: siendo la primera la identificación del problema, la segunda identificación de requisitos de información, la tercera es el análisis de las necesidades del sistema, la cuarta es el diseño del sistema recomendado, la quinta desarrollo y documentación del sistema, la sexta prueba y mantenimiento y la última implementación y evaluación. Cada fase se explica por separado pero nunca se realizan como pasos aislados, más bien es posible que algunas actividades se realicen de manera simultánea, y algunas de ellas podrían repetirse.

FASE I: Identificación de problemas, oportunidades y objetivos

Observación directa del entorno 

Aplicación de entrevista para recolectar información. 

Sintetizar la información recolectada para construir objetivos 

Estimar el alcance del proyecto 

Identificar si existe una necesidad, problema u oportunidad argumentada 

Documentar resultados 

Estudiar los riesgos del proyecto 

Presentar un informe de vialidad 

En la primera fase el analista es el encargado de identificar los problemas de la organización, detallarlos, examinar, evaluar las oportunidades y objetivos.

El analista debe identificar y evaluar los problemas existentes en la organización de manera critica y precisa. Mayormente los problemas son detectados por alguien más y es cuando el analista es solicitado a fin de precisarlos.

Las oportunidades son situaciones que el analista considera susceptibles de mejorar utilizando sistemas de información computarizados, lo cual le da mayor seguridad y eficacia a las organizaciones además de obtener una ventaja competitiva. El analista debe identificar los objetivos, es decir, el analista debe averiguar lo que la empresa trata de conseguir, se podrá determinar si algunas funciones de as aplicaciones de los sistemas de información pueden contribuir a que el negocio alcance sus objetivos aplicándolas a problemas u oportunidades específicos. Los usuarios, los analistas y los administradores de sistemas que coordinan el proyecto son los involucrados en la primera fase. Las actividades de esta fase son las entrevistas a los encargados de coordinar a los usuarios, sintetizar el conocimiento obtenido, estimar el alcance del proyecto y documentar los resultados. El resultado de esta fase en un informe de viabilidad que incluye la definición del problema y un resumen de los objetivos. La administración debe decidir si se sigue adelante o si se cancela el proyecto propuesto.

FASE II: Determinación de los requerimientos de información

Revisión de los objetivos 

Identificar el dominio 

Investigar la razón por la cual se implementa el sistema actual 

Recolectar información sobre los procedimientos y operaciones que se desempeñan actualmente.

Detallar específicamente: Quiénes son los involucrados, cuál es la actividad, regla y restricciones del negocio, entorno de desarrollo de las actividades, momentos oportunos de desarrollo de cada función, la manera en que se desempeñan los procedimientos actuales.

Elaborar una lista detallada y organizada de todos los procedimientos.

Separar requerimientos funcionales y no funcionales

Adicionar al informe de la primera fase, esta nueva información

En esta fase el analista se esfuerza por comprender la información que necesitan los usuarios para llevar a cabo sus actividades. Entre las herramientas que se utilizan para determinar los requerimientos de información de un negocio se encuentran métodos interactivos como las entrevistas, los muestreos, la investigación 

de datos impresos y la aplicación de cuestionarios; métodos que no interfieren con el usuario como la observación del comportamiento de los encargados de tomar 

las decisiones y sus entornos e oficina, al igual que métodos de amplio alcance como la elaboración de prototipos.

Esta fase es útil para que el analista confirme la idea que tiene de la organización y sus objetivos.

Los implicados en esta fase son el analista y los usuarios, por lo general los trabajadores y gerentes del área de operaciones.

El analista necesita conocer los detalles de las funciones del sistema actual: 

el quién (la gente involucrada), el qué (la actividad del negocio), el dónde (el entorno donde se desarrollan las actividades), el cuándo (el momento oportuno) y el cómo (la manera en que se realizan los procedimientos actuales) del negocio que se estudia.

Al término de esta fase, el analista debe conocer el funcionamiento del negocio y poseer información muy completa acerca de la gente, los objetivos, los datos y los procedimientos implicados.

FASE III: Análisis de las necesidades

Evaluar las dos fases anteriores. 

Modelar las entradas, los procesos y las salidas de las funciones ya identificadas. 

Elaborar diccionario de datos y sus especificaciones. 

Elaborar diagramas de procesos de cada función. 

Elaborar propuesta del sistema con todos los diagramas de operaciones y de procesos. 

Realizar el análisis del riesgo sobre el realizado en las fases anteriores, tomando en cuenta el aspecto económico, técnico y operacional (estudio de factibilidad) 

Estimar en un diagrama de Gantt el tiempo que tomará desarrollar el sistema. 

En esta fase el analista evalúa las dos fases anteriores, usa herramientas y técnicas como el uso de diagramas de flujo de datos para graficar las entradas, los procesos y las salidas de las funciones del negocio en una forma gráfica estructurada. 

A partir de los diagramas de flujo de datos se desarrolla un diccionario de datos que enlista todos los datos utilizados en el sistema así como sus respectivas especificaciones.

El analista prepara en esta fase, una propuesta de sistemas que sintetiza sus hallazgos, proporciona un análisis de costo/beneficio de las alternativas y ofrece, en su caso, recomendaciones sobre lo que se debe hacer.

FASE IV: Diseño del sistema recomendado 

Evaluar las tres fases anteriores. 

Realizar el diseño lógico de todo el sistema. 

Elaborar procedimientos precisos para la captura de los datos que van a ingresar al sistema de información 

Elaborar el diseño de la base de datos. 

Diseñar las diferentes interfaces de usuarios de cada operación, procedimiento y/o función. 

Diseñar controles y procedimientos de respaldos que protejan al sistema y a los datos. 

Producir los paquetes específicos de programas para los programadores. 

Elaborar una lista de las funciones genéricas y de las que será obligatorio crear. 

En esta fase el analista utiliza la información recopilada en las primeras fases para realizar el diseño lógico del sistema de información.

El analista diseña procedimientos precisos para la captura de datos que aseguran que los datos que ingresen al sistema de información sean correctos.

Facilita la entrada eficiente de datos al sistema de información mediantes técnicas adecuadas de diseño de formularios y pantallas.

La concepción de la interfaz de usuario forma parte del diseño lógico del sistema de información. 

La interfaz conecta al usuario con el sistema y por tanto es sumamente importante.

También incluye el diseño de archivos o bases de datos que almacenarán gran parte delos datos indispensables para los encargados de tomar las decisiones en la organización. 

En esta fase el analista interactúa con los usuarios para diseñar la salida (en pantalla o impresa) que satisfaga las necesidades de información de estos últimos.

Finalmente el analista debe diseñar controles y procedimientos de respaldo que protejan al sistema y a los datos y producir paquetes de especificaciones de programa para los programadores. 

Cada paquete debe contener esquemas para la entrada y la salida, especificaciones de archivos y detalles del procesamiento. 

FASE V: Desarrollo y documentación del software 

Evaluar los procedimientos que va a ser desarrollados por el programador. 

Mostrar y explicar cada procedimiento, función y operación al programador. 

Elaborar manuales de procedimientos internos del sistema. 

Elaborar manuales externos de ayuda a los usuarios del sistema. 

Elaborar demostraciones para los usuarios y la interacción con distintas interfaces 

Elaborar actualizaciones para los diferentes procedimientos 

Elaborar un informe con el tiempo que se llevó construir cada procedimiento. 

En la quinta fase del ciclo del desarrollo de sistemas, el analista trabaja de manera conjunta con los programadores para desarrollar cualquier software original necesario. Entre las técnicas estructuradas para diseñar y documentar software se encuentran los diagramas de estructuras, los diagramas de Nassi-Shneiderman y el pseudocódigo.

Durante esta fase el analista trabaja con los usuarios para desarrollar documentación efectiva para el software, como manuales de procedimientos, ayuda en línea y sitios web que incluyan respuestas a preguntas frecuentes en archivos “léame” que se integrarán al nuevo software.

La documentación indica a los usuarios cómo utilizar el sistema y qué hacer en caso de que surjan problemas derivados de este uso.

Los programadores desempeñan un rol clave en esta fase porque diseñan, codifican y eliminan errores sintácticos de los programas de cómputo.

FASE VI: Prueba y mantenimiento del sistema 

Realizar la programación de las pruebas del sistema. 

Realizar un instrumento para evaluar el sistema de información. 

El programador deberá elaborar un resumen de las pruebas del sistema. 

El analista deberá realizar un informe de sus pruebas y discutirlo con el programador 

Elaborar la planificación de las horas del mantenimiento del sistema. 

Elaborar la lista de las operaciones que pudieran sufrir modificaciones de códigos

Antes de poner en funcionamiento el sistema es necesario probarlo es mucho menos costoso encontrar los problemas antes que el sistema se entregue a los usuarios.

Una parte de la pruebas la realizan los programadores solos, y otra la llevan a cabo de manera conjunta con los analistas de sistemas. Primero se realizan las pruebas con datos de muestra para determinar con precisión cuáles son los problemas y posteriormente se realiza otra con datos reales del sistema actual.

El mantenimiento del sistema de información y su documentación empiezan en esta fase y se llevan de manera rutinaria durante toda su vida útil. 

FASE VII: Implementación y evaluación del sistema

Planificar gradualmente la conversión del sistema anterior. 

Instalar los equipos de hardware necesarios para el funcionamiento del software creado. 

Capacitar por medio de talleres a los usuarios en el manejo de equipos y software creados 

Evaluar la adaptabilidad de los usuarios al sistema.

Esta es la última fase del desarrollo de sistemas, y aquí el analista participa en la implementación del sistema de información. En esta fase se capacita a los usuarios en el manejo del sistema. Parte de la capacitación la imparten los fabricantes, pero la supervisión de ésta es responsabilidad del analista de sistemas.

Se menciona la evaluación como la fase final del ciclo de vida del desarrollo de sistemas principalmente en áreas del debate. En realidad, la evaluación se lleva a cabo durante cada una de las fases.

El trabajo de sistemas es cíclico, cuando un analista termina una fase del desarrollo de sistemas y pasa a la siguiente, el surgimiento de un problema podría obligar a regresar a la fase previa y modificar el trabajo realizado.

Read More