Pgin a1

Unidad 1. aplicar el anlisis de sistema de acuerdo a las necesidades y los requerimientos de los usuarios 1.1.- investigacin preliminar 1.2.- propuesta de solucin 1.3.- estudio de factibilidad 1.4.- Toma de decisiones 1.5.- requerimiento de un sistema 1.6.- obtener los datos del sistema empleando herramientas Unidad ll. determinar los elementos de bases de datos 2.1.- identificar el tipo de informacin 2.2.- identificar los tipos de usuarios 2.3.- determinar el equipo a utilizar 2.4.- determinar los programas a utilizar Unidad lll. disear una base de datos en base al modelo entidad /relacin 3.1.- definir entidades y relaciones 3.2.- establecer atributos 3.3.- establecer los esquemas para los enunciados semnticos 3.4.- definir los enunciados semnticos 3.5.- realizar el diagrama entidad/relacin Unidad IV. Desarrollar bases de datos mediante un programa administrador 4.1.- crear tablas de acuerdo a las entidades diseadas 4.2.- agregar claves principales a las tablas creadas Pgin a2

3 3 4 4 5 5 6 7 7 8 9 1 2 1 4 1 4 1 8 2 3 2 5 2 7 3 2 3 3 3 6

UNIDAD I. APLICAR EL ANALISIS DE SISTEMAS DE ACUERDO A LAS NECESISDADES Y REQUERIMIENTOS DE LOS USUARIOS.
1.1INVESTIGACION PREELIMINAR Si un proyecto de sistema parece ser viable y tiene suficiente prioridad, se comienza la investigacin preliminar. Esta investigacin requiere uno o ms analistas de sistemas analizando el systemrequest para determinar la verdadera naturaleza y alcance del problema y recomendar si es que se debe continuar con el proyecto. El propsito de la investigacin preliminar es buscar informacin suficiente para determinar si se debe continuar con el Ciclo de Vida del Desarrollo del Sistema. La investigacin no es una actividad de recoleccin de datos; no se espera que se definan todos los problemas ni que se propongan todas las posibles soluciones. La investigacin preliminar debe cumplir con los siguientes cinco objetivos: 1. Entender la naturaleza del problema Muchas veces, el problema presentado en el systemrequest no es el problema real, sino un sntoma. Hay que identificar el verdadero problema para as darle una solucin adecuada. 2. Definir el alcance y las restricciones o limitaciones del sistema El alcance del proyecto es la extensin del proyecto o del sistema, o sea, hasta dnde se debe llegar. Se debe determinar quin es afectado por el problema o por la solucin. Tambin es importante definir las limitaciones del sistema. Una limitacin es una condicin, restriccin o requisito que el sistema debe

Pgin a3

satisfacer. La limitacin puede tener que ver con el equipo, programas, tiempo, leyes, costos y otros. 3. Identificar los beneficios que se obtendran si el sistema propuesto es completado Se debe identificar los beneficios tangibles e intangibles que se esperan como resultado del systemrequest. Estos beneficios, junto a los estimados de costo, sern usando para decidir si se contina con el proyecto. Los beneficios tangibles son aquellos que se pueden expresar en trminos de dinero. Los beneficios intangibles son difciles de contabilizar en dlares y centavos, pero son igualmente importantes. Tienen que ver con la satisfaccin del empleado, mayor informacin disponible para tomar decisiones, mejorar la imagen de la compaa y otros aspectos que no se miden en trmino de dinero. 4. Especificar un estimado de tiempo y costo para las prximas fases de desarrollo Se debe presentar un estimado del tiempo que tomar realizar cada uno de las siguientes fases del desarrollo del sistema y del costo que debe incurrir para completar el sistema. Se debe incluir los costos de desarrollo costos que ocurren una sola vez y los costos continuos costos pagados peridicamente. 5. Presentar un informe a la gerencia describiendo el problema y detallando si se recomienda continuar con la fase de anlisis del sistema Debe incluir la evaluacin del systemrequest, estimado de tiempo y costo-beneficios y las recomendaciones.

1.2.- PROPUESTA DE SOLUCION Esta fase se ocupa de la reunin y estudio a detalle de los datos del sistema en operacin y la especificacin de los nuevos requerimientos del sistema a desarrollar. Concluye en general con un documento que recoge el resultado del anlisis. El aspecto ms importante de cualquier propuesta es identificar y comprender el problema que el cliente busca resolver. Uno de los puntos del desarrollo de una propuesta de solucin es presentar una nocin propia del problema, as como la propuesta para resolverlo, con el fin de convencer al cliente de que tal propuesta es la mejor. Para ello, se presentara lo que implica una descripcin de los problemas:

1.- La Naturaleza del problema. Pgin a4

2.- La historia del problema. 3.- Las caractersticas del problema. 4.- Las soluciones alternas consideradas. 5.- La solucin o la tcnica seleccionada

1.3.- ESTUDIO DE FACTIBILIDAD Un resultado importante de la investigacin preliminar es la determinacin de que el sistema requerido es factible. Existen tres aspectos en el estudio de factibilidad de la investigacin preliminar: 1. Factibilidad tcnica. Puede realizarse el trabajo para el proyecto con el equipo actual, tecnologa de software y el personal disponible? Si se requiere nueva tecnologa, qu probabilidades hay de que pueda desarrollarse? 2. factibilidad econmica. Existen suficientes beneficios en la creacin del sistema para hacer que los costos sean aceptables? O, en forma inversa, son tan altos los costos como para que el proyecto no deba llevarse a cabo? 3. Factibilidad operativa. Se utilizar el sistema si se desarrolla y pone en marcha? Habr resistencia de los usuarios, que los posibles beneficios reducirn del sistema.

1.4.- TOMA DE DECISIONES Se basa en el anlisis de varias alternativas que se nos van presentando durante el proceso, y estas posibilidades pueden llevarnos a terminar el proceso ya sea de la mejor manera o conducirnos al error. Como todo proceso, la toma de decisiones tiene unos pasos o recomendaciones que se podran tener en cuenta, como lo es el analizar y tener un buen conocimiento del problema o incgnita que se tiene para saber de verdad cual es la mejor manera de resolverlo.

Pgin a5

1.5.- REQUERIMIENTO DE UN SISTEMA Los requerimientos son declaraciones que identifican atributos, capacidades, caractersticas y/o cualidades que necesita cumplir un sistema (o un sistema de software) para que tenga valor y utilidad para el usuario. En otras palabras, los requerimientos muestran qu elementos y funciones son necesarias para un proyecto. Etapas de la fase de requerimientos

* Obtencin de requerimientos: bsqueda y obtencin de los requerimientos desde los grupos de inters. * Anlisis: comprobacin requerimientos. de la consistencia y completitud de los

* Verificacin: constatacin de que los requerimientos especificados son correctos.

Clasificacin de los requerimientos * Requerimientos funcionales: qu debe hacer el sistema o software. * Requerimientos no funcionales: cmo debe funcionar el sistema o software (no su implementacin), por ej. calidad, rendimiento, facilidad de uso, etc. * Requerimientos externos: a qu se debe atener el sistema o software con respecto a su entorno: compatibilidad con otros sistemas, adecuacin a determinadas leyes, etc.

1.6.- OBTENER LOS DATOS DEL SISTEMA EMPLEANDO HERRAMIENTAS ANALITICAS 1.- Definir la metodologa adecuada para desarrollar el software. Pgin a6

2.- Obtener los requerimientos y realizar el anlisis de los mismo, puedes utilizar rbol de Decisiones o Tablas de Decisin, Caso de Usos (muy utilizado tanto en orientados a objetos como para estructurados), diagrama de flujo de datos (para anlisis estructurado) entre otras. 3.- Diseo, pantallas, tablas en base de datos si se necesita hacer persistencia, las capas que poseer el aplicativo, casi la mayoras utilizan: Capa de aplicacin, Acceso a datos y Base de Datos. 4.- Desarrollo, en la comienzas a generar cdigo fuente sobre todo lo diseado, y si est bien es posible que la etapa de diseo no cambie mucho, por el contrario, puede replantearte todo lo diseado, posiblemente por no haber tenido en cuenta o mal interpretado un requerimiento.

UNIDAD II: DETERMINAR LOS ELEMENTOS DE BASES DE DATOS

2.1 TIPOS DE INFORMACIN

Una vez identificados los objetos principales de la base de datos como candidatos para las tablas, el siguiente paso es identificar los tipos de informacin que deben almacenarse para cada objeto. Estos tipos son las columnas de la tabla del objeto. Las columnas de una tabla de base de datos contienen algunos tipos de informacin comunes: Columnas de datos sin procesar Estas columnas almacenan informacin tangible, como por ejemplo nombres, determinada por un origen externo a la base de datos.
Pgin a7

Columnas de categoras Estas columnas clasifican o agrupan los datos y almacenan una seleccin limitada de datos, tales como verdadero o falso; casado o soltero; presidente, director o responsable de equipo; etc.Columnas de identificadores Estas columnas proporcionan un mecanismo para identificar cada elemento almacenado en la tabla. Estas columnas suelen incluir un Id. o un nmero en el nombre (por ejemplo, Id del Empleado, nmero de Factura y Id del Editor. La columna del identificador es el componente principal para los usuarios y las funciones internas de proceso de la base de datos para el acceso a una fila de datos de la tabla. Algunas veces el objeto tiene una forma tangible de Id. Utilizada en la tabla (por ejemplo, un nmero de la seguridad social), aunque en la mayora de los casos se puede definir la tabla para poder crear un Id. Confiable y artificial para la fila. Columnas relacionales o diferenciales Estas columnas establecen un vnculo entre la informacin de una tabla y la informacin relacionada que se encuentra en otra tabla. Por ejemplo, una tabla que realiza el seguimiento de transacciones comerciales puede tener un vnculo con una tabla clientes, de modo que pueda asociarse toda la informacin del cliente a la transaccin comercial.

2.2.- TIPOS DE USUARIOS

USUARIOS: Hay tres tipos de usuarios. Programadores de aplicaciones: Se encargan de disear y programar las aplicaciones necesarias para la utilizacin de la B.D., realizando las peticiones pertinentes al SGBD. Usuario final: Es la persona que se dedica a trabajar sobre los datos almacenados en la B.D. Hay usuarios finales avanzados que por medio del lenguaje de programacin SQL pueden acceder a los datos. Administrador de B.D: Es el usuario ms importante de los tres, ya que es el que se encarga de disear y modificar la estructura de la B.D.
QUIN ES USUARIO?

Pgin a8

Identificar a los usuarios de un software puede parecer sencillo. Pero el grupo de personas u organizaciones afectadas por un sistema y con influencia directa o indirecta en sus requisitos, es mayor del que normalmente pensamos. La definicin ms obvia de usuario es: aquellos que interactan directamente con el producto para realizar una tarea.
Holtzblatt y Jones (1993) incluye en su definicin de usuario a quienes:

Gestionan a los usuarios directos. Reciben productos del sistema. Testan el sistema. Tienen decisin de compra. Usan productos de la competencia.

Eason (1987) identifica tres categoras de usuario: Primarios: son quienes frecuentemente usan el sistema. Secundarios: los que ocasionalmente utilizan el sistema. Terciarios: todos los afectados por la introduccin del sistema o que influencian su compra.

IDENTIFICAR TIPOS DE USUARIOS

Podemos definir a los usuarios como toda persona que tenga todo tipo de contacto con el sistema de base de datos desde que este se disea, elabora, termina y se usa. Los usuarios que acceden a una base de datos pueden clasificarse como: *Programadores de aplicaciones: Los profesionales en computacin que interactan con el sistema por medio de llamadas en DML (Lenguaje de Manipulacin de Datos), las cuales estn incorporadas en un programa escrito en un lenguaje de programacin (Por ejemplo, COBOL, PL/I, Pascal, C, etc.) * Usuarios sofisticados: Los usuarios sofisticados interactan con el sistema sin escribir programas. En cambio escriben sus preguntas en un lenguaje de consultas de base de datos.

Pgin a9

*Usuarios especializados: Algunos usuarios sofisticados escriben aplicaciones de base de datos especializadas que no encajan en el marco tradicional de procesamiento de datos. *Usuarios ingenuos: Los usuarios no sofisticados interactan con el sistema invocando a uno de los programas de aplicacin permanentes que se han escrito anteriormente en el sistema de base de datos, podemos mencionar al usuario ingenuo como el usuario final que utiliza el sistema de base de datos sin saber nada del diseo interno del mismo por ejemplo: un cajero.

2.3.- DETERMINAR EL EQUIPO A UTILIZAR. Un servidor de bases de datos, no es ms que un equipo que contiene un software SGBD (Sistema Gestor de Bases de Datos), existe infinidad de software de este tipo y puedes instalar cualquiera en tu propio equipo, volvindolo as un servidor.

Pgin a 10

En estos momentos las ms usadas son las Bases de Datos Relacionales que almacenan los datos en tablas que mantienen los datos "relacionados" entre s, de forma que se mantienen coherentes. La mayora de las pginas web que contienen foros, o contenido actualizable, almacena sus datos en una o ms mquinas que tienen instalado un sistema de bases de datos. Los ms comunes son Oracle, MySQL, SQL Server y utilizan un lenguaje de comunicacin llamado SQL (Simple Query Language) que permite hacer selecciones de datos complejas, inserciones, actualizaciones y eliminacin de datos.

Una vez que el servidor est funcionando, un equipo puede acceder con un cliente (que es un programa que conecta al servidor) que establece una conexin bidireccional con el servidor tanto en local como en remoto.

Pgin a 11

2.4 DETERMINAR LOS PROGRAMAS A UTILIZAR

Pgin a 12

Son las aplicaciones (software) adicionales que necesitamos para que un sistema trabaje mejor o poder reutilizar los resultados que nos arroje de una mejor manera, principalmente stos son como el Word y el Excel en donde nosotros podemos pegar informacin que nos arroje un sistema para generar algn reporte o imprimirlo en una hoja o lo que sea que se nos antoje. Al igual que cualquier otro tipo de software de oficina, hay un montn de programas de diseo de bases de datos disponibles para uso personal o profesional, idealmente, un usuario de base de datos busca el objetivo de su base de datos posibles antes de elegir un programa de diseo. Sin embargo, todo aqul que busque un diseo innovador de bases de datos sin conocer los datos concretos que entran en el sistema puede utilizar varios criterios para encontrar el programa ptimo diseo de bases de datos para sus necesidades. Los usuarios potenciales de bases de datos necesitan buscar primero la sencillez del software de base de datos. Normalmente, una compaa de software permitir que un cliente potencial eche un vistazo a las capturas de pantalla o incluso descargue una versin demo del programa para la obtencin de muestras. Con la excepcin de las personas instruidas en diseo de bases de datos, ms sencillo siempre es mejor y un interfaz desarrollado con muchas campanas y silbidos puede ser desaconsejable. La cuestin que los compradores deben considerar es si una persona con una mnima cantidad de conocimientos o ideas preconcebidas puede utilizar el programa. Adems de facilidad de uso, los diseadores de bases de datos necesitan ver algunos pequeos factores. La compatibilidad con los sistemas de computacin de la oficina esta dada pero los profesionales de un negocio, deben considerar si el programa cumple con los requerimientos de desarrollo de un futuro prximo. Adems, siempre hay una consideracin de precio en la compra de software de bases de datos.

Algunos programas pueden ser prohibitivamente caros, pero otros pueden ser demasiado costosos para el servicio que prestan. Los compradores deben mirar primero su funcionalidad y luego determinar si el precio es demasiado grande para sus presupuestos.
Pgin a 13

COMENTARIOS: Como una opcin aparte, se pueden desarrollar ciertos programas que ayuden al uso del sistema de informacin, sin embargo, es importante mencionar la compatibilidad entre ellos par evitar problemas.

UNIDAD III.- DISEAR UNA BASE DE DATOS EN BASE AL MODELO ENTIDAD/RELACION.

Pgin a 14

3.1.- Definir Entidades y Relaciones

Entidad y Relacin El modelo de datos ms extendido es el denominado ENTIDAD/RELACIN (E/R) En el modelo E/R se parte de una situacin real a partir de la cual se definen entidades y relaciones entre dichas entidades: ENTIDAD: Objeto del mundo real sobre el que queremos almacenar informacin. Las entidades estn compuestas de atributos que son los datos que definen el objeto (para la entidad persona seran DNI, nombre, apellidos, direccin,...). De entre los atributos habr uno o un conjunto de ellos que no se repite; a este atributo o conjunto de atributos se le llama clave de la entidad, (para la entidad persona una clave seria DNI). En toda entidad siempre hay al menos una clave que en el peor de los casos estar formada por todos los atributos de la tabla. Ya que puede haber varias claves y necesitamos elegir una, lo haremos atendiendo a estas normas: Que se tenga pleno conocimiento de ella. Que sea mnima, ya que ser muy utilizada por el gestor de base de datos.

RELACIN: Asociacin entre entidades, sin existencia propia en el mundo real que estamos modelando, pero necesaria para reflejar las interacciones existentes entre entidades. Las relaciones pueden ser de tres tipos:
Las entidades que intervienen en la relacin se asocian una a una

(Ejemplo: la entidad HOMBRE, la entidad MUJER y entre ellos la relacin MATRIMONIO).

Una ocurrencia de una entidad est asociada con muchas (n) de otra

(Ejemplo: la entidad EMPERSA, la entidad TRABAJADOR y entre ellos la relacin TRABAJAR-EN).

Cada ocurrencia, en cualquiera de las dos entidades de la relacin, puede

estar asociada con muchas (n) de la otra y viceversa (Ej: la entidad ALUMNO, la entidad EMPRESA y entre ellos la relacin MATRCULA Un modelo lgico representa los conceptos reales que ha de cubrir la aplicacin y permite asegurar que el software cubrir dichos conceptos.
Pgin a 15

El modelado de funciones de objetos (Object Role Modeling ) es el proceso de representar conceptos del mundo real que definen influyen en el software. Los diagramas ORM incluyen unos objetos primarios llamados entidades, las relaciones entre esas entidades y los atributos que definen esos objetos. Estos diagramas se crean descomponiendo los requerimientos de usuario y los casos de uso en entidades, relaciones y atributos.

La notacin ORM ofrece un nmero de formas y conectores para definir el modelo lgico: Objetos ORM: Entidades. Son representados con forma oval y el nombre de la entidad, definen los elementos que toman parte en el desempeo de la aplicacin. Relacin ORM: Se representan como una lnea que conecta las entidades, en medio hay un rectngulo dividido en tantos segmentos como relaciones haya, definen como dos ms entidades se relacionan unas con otras. Hecho ORM: Se representan como un pequeo texto bajo el rectngulo de una relacin, definen como dos ms entidades se relacionan. Utilizan "..." y "/" para indicar qu papel toma cada parte de la relacin, de forma que se debe poder leer en ambos sentidos (un hecho "puede ser / es " indica Producto puede ser Mechero, Mechero es Producto). Restricciones ORM: Definen como las entidades participan en la relacin, cuales son dominantes y su cantidad. Un pequeo crculo relleno en la conexin entidad-relacin indica que dicha relacin es dominante. Unas flechas encima del rectngulo de la relacin indica su cardinalidad.

Los diagramas ORM deben ser una vista lgica de las entidades de la aplicacin, no representar clases bases de datos

ENTIDAD Representa una cosa u "objeto" del mundo real con existencia independiente, es decir, se diferencia unvocamente de cualquier otro objeto o cosa, incluso siendo del mismo tipo. Ejemplo:
Pgin a 16

 Una persona. (Se diferencia de cualquier otra persona, incluso siendo

gemelos).
Un automvil. (Aunque sean de la misma marca, el mismo modelo,...,

tendrn atributos diferentes, por ejemplo, el nmero de motor).

Una casa (Aunque sea exactamente igual a otra, an se diferenciar en su

direccin).

Una entidad puede ser un objeto con existencia fsica como: una persona, un animal, un casa, etc. (entidad concreta), o un objeto con existencia conceptual como: un puesto de trabajo, una asignatura de clases, un nombre,etc. (entidad abstracta). Una entidad est descrita y se representa por sus caractersticas o atributos. Por ejemplo, la entidad Persona puede llevar consigo las caractersticas: Nombre, Apellido, Sexo, Estatura, Peso, Fecha de nacimiento, etc...

Relacin: Describe cierta dependencia entre entidades o permite la asociacin de las mismas. Ejemplo: Dadas dos entidades "Habitacin 502" y "Mark", es posible relacionar que la habitacin 502 se encuentra ocupada por el husped de nombre Mark. La dependencia o asociacin entre los conjuntos de entidades es llamada participacin. En el ejemplo anterior los conjuntos de entidades "Habitacin" y "Husped" participan en el conjunto de relaciones habitacin-husped. Se llama grado del conjunto de relaciones a la cantidad de conjuntos de entidades participantes en la relacin.

Restricciones Son reglas que deben mantener los datos almacenados en la base de datos. No se deben quebrantar a menos que tenga otra relacin de una tabla de uno a muchos.

Pgin a 17

Correspondencia de cardinalidades Dado un conjunto de relaciones en el que participan dos o ms conjuntos de entidades, la correspondencia de cardinalidad indica el nmero de entidades con las que puede estar relacionada una entidad dada. Dado un conjunto de relaciones binarias y los conjuntos de entidades A y B, la correspondencia de cardinalidades puede ser:
Uno a Uno: Una entidad de A se relaciona nicamente con una entidad en

B y viceversa.
Uno a varios: Una entidad en A se relaciona con cero o muchas entidades

en B. Pero una entidad en B se relaciona con una nica entidad en A.

Varios a Uno: Una entidad en A se relaciona exclusivamente con una

entidad en B. Pero una entidad en B se puede relacionar con 0 o muchas entidades en A.

Varios a Varios: Una entidad en A se puede relacionar con 0 o muchas

entidades en B y viceversa.

3.2. Establecer atributos

Qu es un atributo?
Pgin a 18

Los atributos son las propiedades que describen a cada entidad en un conjunto de entidades. Un conjunto de entidades dentro de una entidad, tiene valores especficos asignados para cada uno de sus atributos, de esta forma, es posible su identificacin unvoca.

Ejemplos: A la coleccin de entidades Alumnos, con el siguiente conjunto de atributos en comn, (id, nombre, edad, semestre), pertenecen las entidades: (1, Sophie, 18 aos, 2) (2, Penny, 19 aos, 5) (3, Sophie, 20 aos, 2) Durante esta fase se deben listar todos los posibles atributos del sistema de administracin de BD. Se pueden listar ms atributos de los que realmente se necesita para su aplicacin particular, pero eso no es problema ya que los atributos innecesarios sern eliminados durante la fase de refinamiento de datos. Cada una de las entidades pertenecientes a este conjunto se diferencia de las dems por el valor de sus atributos. Ntese que dos o ms entidades diferentes pueden tener los mismos valores para algunos de sus atributos, pero nunca para todos. En particular, los atributos identificativos son aquellos que permiten diferenciar a una instancia de la entidad de otra distinta. Por ejemplo, el atributo identificativo que distingue a un alumno de otro es su nmero de id. Para cada atributo, existe un dominio del mismo, este hace referencia al tipo de datos que ser almacenado o a restricciones en los valores que el atributo puede tomar (Cadenas de caracteres, nmeros, solo dos letras, solo nmeros mayores que cero, solo nmeros enteros...). Cuando una entidad no tiene un valor para un atributo dado, este toma el valor nulo, bien sea que no se conoce, que no existe o que no se sabe nada al respecto del mismo Cules de los atributos son importantes y cules no lo son. Una forma de determinar las relaciones entre los atributos es cuestionar las mismas preguntas que se le plantearan en la base de datos. Si un vendedor quiere una lista de apartamentos cuyos precios orden los 900 dlares al mes, el sistema de base de
Pgin a 19

datos debe establecer una relacin entre el tipo de propiedad en alquiler (casa, chalet o apartamento) y el costo de alquiler. Las relaciones pueden ser ms complejas. El presidente de la compaa podra desear saber cuntos apartamentos con dos o ms habitaciones estn alquilados por menos de 400 dlares al mes. El sistema de administracin de base de datos debe comparar atributos de los costos de alquiler con atributos del nmero de habitaciones y del tipo de propiedad en alquiler. Preguntas como estas ayudarn a ver qu atributos son prescindibles de forma que puedan ser eliminados de la base de datos.

Claves Es un subconjunto del conjunto de atributos comunes en una coleccin de entidades, que permite identificar unvocamente cada una de las entidades pertenecientes a dicha coleccin. Asimismo, permiten distinguir entre s las relaciones de un conjunto de relaciones Dentro de los conjuntos de entidades existen los siguientes tipos de claves:

Superclave: Es un subconjunto de atributos que permite distinguir unvocamente cada una de las entidades de un conjunto de entidades. Si otro atributo unido al anterior subconjunto, el resultado seguir siendo una superclave.

Clave candidata: Dada una superclave, si sta deja de serlo removiendo

nicamente uno de los atributos que la componen, entonces sta es una clave candidata. Clave primaria: Es una clave candidata, elegida por el diseador de la base de datos, para identificar unvocamente las entidades en un conjunto de entidades Los valores de los atributos de una clave, no pueden ser todos iguales para dos o ms entidades. Para poder distinguir unvocamente las relaciones en un conjunto de relaciones R, se deben considerar dos casos: R NO tiene atributos asociados: En este caso, se usa como clave primaria de R la unin de las claves primarias de todos los conjuntos de entidades participantes.

Pgin a 20

 R tiene atributos asociados: En este caso, se usa como clave primaria de R la unin de los atributos asociados y las claves primarias de todos los conjuntos de entidades participantes. Si el conjunto de relaciones, R, sobre las que se pretende determinar la clave primaria est compuesto de relaciones binarias, con los conjuntos de entidades participantes A y B, se consideran los siguientes casos, segn sus cordialidades:
R es de muchos a uno de A a B entonces slo se toma la clave primaria de

A, como clave primaria de R.

R es de uno a muchos de A a B entonces se toma slo la clave primaria de

B, como clave primaria de R.

R es de uno a uno de A a B entonces se toma cualquiera de las dos claves

primarias, como clave primaria de R Atributos: es una caracterstica (adjetivo) de una entidad que puede hacer 1 de tres cosas: Identificar Relacionar Describir

Ejemplos de entidades con sus atributos En el diseo se pueden considerar 3 categoras de atributos
Simples o compuestos: ya sea que el atributo sea un todo o bien este

compuesto Color es simple, toma valores rojo, azul, etc.

Nombre es compuesto, contiene nombre de pila, apellido materno, apellido

materno
Pgin a 21

Con valores simples o multivaluados: en base a si consisten de un solo valor o un conjunto de valores. Telfono o Telfonos
Derivados: que se pueden calcular en base a otros atributos

El promedio de prstamos se puede derivar si tenemos los valores de cada prstamo realizado a un persona

Conjuntos de relaciones

Relaciones: la conexin que existe entre 2 entidades (verbo).

Relacin entre 2 entidades

Pgin a 22

3.3. Establecer esquemas para enunciados semnticos

Introduccin
Pgin a 23

Definicin de Enunciados semnticos: El trmino semntica se refiere a los aspectos del significado o interpretacin del significado de un determinado smbolo, palabra, lenguaje o representacin formal. Mecanismos para establecer esquemas sintcticos A partir de enunciados y para adscribirles a sus formantes etiquetas de carcter semntico. Esos mismos mecanismos fueron aplicados para determinar los esquemas agenticos y clasificarlos en grupos y subgrupos con el fin de compararlos y oponerlos a partir de propiedades combinatorias y caractersticas aspectuales.

Esquema conceptual Especifica principalmente los componentes estticos de la base de datos, incluyendo las estructuras y restricciones estticas Esquema conceptual. Se especifica en un lenguaje de modelacin, tal como el modelo entidad interrelacin [Chen76] o UML [Booch98], pudiendo incluir algunas especificaciones extra, expresadas en lenguaje natural o alguna lgica. Este esquema es un modelo de una realidad o la especificacin de una solucin a un problema, dependiendo de si se utiliza el lenguaje para anlisis o diseo respectivamente. Pasos para un esquema conceptual La entrada al proceso de diseo conceptual es el documento de especificacin de requisitos, el cual es el resultado principal de la etapa de anlisis. Las bases de datos deben ser desarrolladas de modo de asegurar ciertos niveles mnimos de calidad.

Existen criterios de calidad. Algunas aportes fueron realizados por:

Batini [Batini94], Pgin a 24

 Moody [Moody94] y Kesh [Kesh95.

Para cada uno de los criterios de calidad bajo consideracin, se propone una mtrica, con lo que se puede obtener una medida de la calidad de un esquema conceptual. El proceso de diseo conceptual Es una tarea humano-dependiente, en el sentido que requiere de habilidades que son muy difciles de automatizar. El diseador debe analizar la realidad bajo modela miento, documentar los hechos relevantes para satisfacer un conjunto de requerimientos, y complementar el documento de especificacin de requisitos una vez que obtiene nueva informacin a travs del proceso de diseo.

Decisiones de diseo. En cada etapa se utilizan distintas polticas para tomar decisiones de diseo, las cuales pueden variar su importancia (ponderacin o peso) dependiendo del diseador o la etapa del desarrollo en que se encuentre.

3.4 Definir los enunciados semnticos

El trmino semntica se refiere a los aspectos del significado o interpretacin del significado de un determinado smbolo, palabra, lenguaje o representacin formal. En principio cualquier medio de expresin (lenguaje formal o natural) admite una correspondencia entre expresiones de smbolos o palabras y situaciones o
Pgin a 25

conjuntos de cosas que se encuentran en el mundo fsico o abstracto que puede ser descrito por dicho medio de expresin. Por su naturaleza las variables semnticas no tienen las cualidades aritmticas que permitan su agregacin o el clculo de indicadores. Aunque existe la posibilidad de reducir a categoras mas simples dichas variables, de tal manera de poder asignarles un valor numrico, en este proceso de reduccin y simplificacin se pierden los valores explicativos intrnsecos a dichas variables. Para construir indicadores es necesario: agregar las variables, esto es el equivalente a la suma en los datos numricos.

En el sistema propuesto, la agregacin se efectuar por tipo de fuente, lugar y total. Para la agregacin por tipo de fuente o lugares se deben listar los valores de todas las fuentes que integran el tipo, o el lugar, dependiendo del caso y se procede a elaborar un enunciado semntico que sintetice el conjunto des enunciados en uno solo. Los enunciados semnticos pueden apoyar o descartar en diferentes grados, una situacin dada, estar a favor o en contra, identificar o no un problema o situacin, o simplemente expresar una opinin sobre una situacin dada. Cuando se efecta la agregacin semntica, es necesario identificar estas diferentes tendencias y tratar de incluirlas en el enunciado sntesis. Estas tendencias pueden ser, centrales (la mayora de los enunciados coinciden en una apreciacin central y descartan los extremos posibles), izquierdos o derechos (la mayora de los enunciados coinciden en una apreciacin en uno de los extremos posibles), bimodal (una parte de los enunciados coinciden en una apreciacin en uno de los extremos posibles y los otros en el extremo opuesto).

Para la construccin de indicadores semnticos se listan los valores de las variables que lo integran, estos pueden ser semnticos, numricos y lgicos, y el operador debe elaborar una sntesis de los valores observados, en un enunciado semntico que siga las siguientes normas *1.El enunciado debe estar contenido en un solo prrafo.
Pgin a 26

* 2. Puede haber hasta un mximo de tres oraciones por prrafo.3. Cada oracin debe seguir las reglas de la construccin gramatical (sujeto, verbo y complemento). La agregacin de indicadores semnticos o numricos por medio de procedimientos. Su estudio, a partir de un escueto anlisis de las capacidades mentales del lxico descubiertas por la psicologa, se concentra en su aplicacin en la lexicografa. Su organizacin del lxico en cinco categoras bsicas como sustantivos (jerarqua tpica), verbos (relaciones de encabalgamiento), adjetivos, adverbios (espacios dimensionales) y palabras funcionales, y su posterior aplicacin a WordNet.
Segn Fellbaum, la diferencia entre un campo semntico y WordNet es que

en el primero los lexemas se diferencian de otros lexemas, mientras que en el segundo, los lexemas se organizan de forma conjunta como sinnimos (synsets) Adems, explica, las relaciones sintagmticas no se consideran en las bases de datos, donde se emplean inventarios de clases semnticas y se sitan a los lexemas dentro de ellas, mientras que en el campo semntico s entran en consideracin.

Por tanto, los dominios no son importantes, pues el significado de un lexema se expresa por su relacin de similitud con otros lexemas.

3.5 Realizar el diagrama entidad/relacin

Un diagrama o modelo entidad-relacin (a veces denominado por su siglas, E-R "Entity relationship", o, "DER" Diagrama de Entidad Relacin) es una herramienta para el modelado de datos de un sistema de informacin. Estos modelos expresan entidades relevantes para un sistema de informacin as como sus interrelaciones y propiedades. Se representa mediante un nmero muy reducido de conceptos semnticos bsicos.
Pgin a 27

Denominado por sus siglas como: E-R; Este modelo representa a la realidad a travs de un esquema grfico empleando los terminologa de entidades, que son objetos que existen y son los elementos principales que se identifican en el problema a resolver con el diagramado y se distinguen de otros por sus caractersticas particulares denominadas atributos, el enlace que rige la unin de las entidades est representada por la relacin del modelo.

El modelo E/R aporta una herramienta de modelado para representar las entidades, propiedades y relaciones: los diagramas Entidad/Relacin. Mediante stos, el esquema conceptual abstracto puede ser mostrado grficamente y mantener una independencia conceptual con respecto a la implementacin propiamente dicha. En realidad, podemos hacer que los diagramas sean un reflejo fiel de las relaciones, interrelaciones y atributos del modelo relacional de datos o podemos englobar diversas relaciones en una sola entidad o conjunto de propiedades. Estas entidades poseen un nmero indeterminado de propiedades, que son "trozos" de informacin que describen a las entidades de uno u otro modo. Cada una de las entidades tiene una identidad, esto es, son identificables de forma
Pgin a 28

nica. Grupos de entidades relacionadas mantienen relaciones con otros grupos de entidades. Tambin existen subtipos de entidades. En un diagrama entidad/ relacin, los rectngulos representan entidades, los rombos relaciones y los valos propiedades

Pgin a 29

EN

Pgin a 30

Los diagramas E/R son parecidos a los diagramas de flujo (organigramas) clsicos en que utilizan rectngulos, rombos y valos, pero los significados de estos elementos son distintos. Otra diferencia fundamental con los organigramas es que stos tienen un principio y un final, mientras que un diagrama E/R no. Esto es obvio, puesto que los organigramas representan procesos, mientras que los diagramas E/R representan estados El tipo de relacin entre dos entidades se representa mediante 1s y Ms (tambin el smbolo o n)

Una propiedad cuyo nombre est subrayado seala que sa es la propiedad que identifica de forma nica a la entidad, y que se corresponder con la clave primaria de una relacin en la implementacin relacional. Finalmente, un rectngulo doble, significa que esa entidad es dependiente o dbil, es decir, su existencia depende de la existencia de otra entidad. En algunos diagramas E/R el rombo que indica la relacin entre una entidad independiente y otra dependiente tambin aparece con lneas dobles.

Pgin a 31

Finalmente, las relaciones tipo/subtipo (self-joint en la implementacin relacional) se especifican mediante una relacin de una entidad consigo misma y con las lneas de unin dirigidas, tales como las que muestra la relacin En el siguiente modelo especifica la existencia de tres entidades, Profesor, Curso y Departamento, que se corresponden con otras tantas relaciones. Un departamento tiene muchos profesores y un profesor puede dar muchos cursos. Para cada una de las entidades existe una propiedad que las identifica nicamente y que se corresponde con la clave primaria (en este caso clave subrogada) de cada una de las tablas en la implementacin relacional. Las entidades tienen otras propiedades que las describen y que se corresponden con los distintos campos de
Pgin a 32

la tabla (relacin). Finalmente, las tres entidades contempladas son consideradas como independientes

Otro ejemplo:

Pgin a 33

UNIDAD IV.- DESARROLLAR BASES DE DATOS MEDIANTE UN PROGRAMA ADMINISTRADOR

Pgin a 34

Un RDBMS es un Sistema Administrador de Bases de Datos Relacionales. RDBMS viene del acrnimo en ingls Relational Data Base Management System. Los RDBMS proporcionan el ambiente adecuado para gestionar una base de datos Los sistemas de gestin de bases de datos (en ingls database management system, abreviado DBMS) son un tipo de software muy especfico, dedicado a servir de interfaz entre la base de datos, el usuario y las aplicaciones que la utilizan

*
*

4.1.- CREAR TABLAS DE ACUERDO A LAS ENTIDADES DISEADAS Una tabla es una estructura lgica que sirve para almacenar los datos de un mismo tipo, esto significa que cada entidad se almacena en estructuras separadas. Por ejemplo: la entidad factura se almacena en estructuras diseadas para ese tipo de entidad: la tabla FACTURA. Cada elemento almacenado dentro
Pgin a 35

de la tabla recibe el nombre de //registro// o //fila.// As, si la tabla FACTURA almacena 1.000 facturas, se dice que la tabla FACTURA contiene 1.000 registros o filas. Una tabla se compone de //campos// o //columnas, //que son conjuntos de datos del mismo tipo, los datos de una columna son de todos del mismo tipo: numricos, alfanumricos, fechas la estructura de una tabla es esta: Cada fila almacena los datos de una factura, y cada columna almacena los datos de un mismo tipo (las descripciones, los clientes, etc.). De este modo se pude crear una tabla para cada tipo de entidad, y almacenar en ella los valores correspondientes

Para crear una tabla debes crear una nueva base de datos, insertando una tabla en una base de datos existente o importando o vinculando una tabla desde otro origen de datos, como un libro de Microsoft Office Excel 2007, un documento de Microsoft Office Word 2007, un archivo de texto u otra base de datos. Cuando crea una nueva base de datos en blanco, se inserta automticamente una nueva tabla vaca. A continuacin, puede escribir datos para empezar a definir los campos.

Pgin a 36

Para crear una tabla Contactos, Tareas, Problemas, Eventos o Activos, tal vez desee partir de una de las plantillas de tablas para estos temas que se incluyen en Office Access 2007 Generalmente en un Sistema de Base de Datos relacional, la informacin se almacena en tablas. Cada tabla contiene un conjunto de informacin asociada a un grupo de similar entidad. Una columna representa un tipo nico de informacin acerca de la entidad (atributo). Una fila es un conjunto de tipos de informacin que describe una entidad. Generalmente, la tabla est compuesta de mltiples filas, que constituyen un conjunto de entidades similares que son descritas de acuerdo con un criterio predefinido.

Relaciones entre tablas.

Pgin a 37

En una Base de Datos Relacional la relacin entre tablas se define de forma temporal. Dicha relacin se crea de acuerdo con las necesidades del usuario en cuanto a la disponibilidad de la informacin, definindose una relacin especfica entre una columna de una tabla y una columna de otra tabla. La relacin entre las dos tablas es inherente a la informacin contenida en sus columnas. La relacin se puede definir entre tipos de columnas muy diferentes, pero en la mayor parte de los casos existe una similitud entre ellas. Se denomina clave al conjunto de columnas utilizadas para definir una relacin entre tablas. Si se establece una clave de columna nica en cada tabla de una aplicacin, se dice que es una clave primaria o un campo de clave primaria. La relacin de la informacin entre una tabla y otra se facilita teniendo la misma columna en cada una de las tablas, siendo este mtodo el tipo de relacin ms eficiente. La mayor parte de las Bases de Datos se disean de forma que cada tabla que se va a relacionar con otra, contenga al menos una columna con el mismo tipo de informacin, esto permite una relacin rpida y eficaz. Los registros de una tabla se almacenan uno detrs de otro, respetando las longitudes de cada columna. Esto es una norma general pero en la actualidad no cumple en todas las bases de datos. Las formas normales no son ms que tres reglas que se deben tener una cuenta dentro del Anlisis conceptual, utilizando concretamente el mtodo Entidad/Relacin. El proceso de aplicar las tres formas normales se llama normalizacin. Un diseo de base de datos que no cumpla la primera forma normal no ser correcto. Cuantas ms formas normales cumpla el diseo de base de datos, significar que la base de datos est ms correctamente analizada. Primera forma normal Identificar cada tabla con una clave primaria, y poner los datos en tablas separadas, de manera que los datos de cada tabla sean de un tipo similar (desde el punto de vista conceptual) Segunda forma normal Sacar las columnas que slo dependen de una parte de la clave primaria a otra tabla.

Tercera forma normal Incluir en cada tabla slo datos que pertenezcan a la misma unidad lgica.
Pgin a 38

En una Base de Datos Relacional la relacin entre tablas se define de forma temporal. Dicha relacin se crea de acuerdo con las necesidades del usuario en cuanto a la disponibilidad de la informacin, definindose una relacin especfica entre una columna de una tabla y una columna de otra tabla. La relacin entre las dos tablas es inherente a la informacin contenida en sus columnas. La relacin se puede definir entre tipos de columnas muy diferentes, pero en la mayor parte de los casos existe una similitud entre ellas.

4.2.-ASIGNAR CLAVES PRINCIPALES A LAS TABLAS CREADAS Cada tabla de la base de datos debe tener un campo o un conjunto de campos que identifiquen inequvocamente cada registro almacenado en la tabla. Este campo recibe el nombre de clave principal. Qu es una clave principal? Una clave principal es un campo o conjunto de campos de la tabla que proporcionan a Microsoft Office Access 2007 un identificador exclusivo para cada fila. En una base de datos relacional como Office Access 2007, la informacin se divide en tablas distintas en funcin del tema. Este enfoque funciona porque una vez definida la clave principal, se puede utilizar en otras tablas para hacer referencia a la tabla que contiene la clave principal. Por ejemplo, un campo Id. de cliente de la tabla Compradores podra aparecer tambin en la tabla Pedidos. En la tabla Compradores es la clave principal y en la tabla Pedidos es una clave externa. Una clave externa, en trminos simples, es la clave principal de otra tabla. A menudo, un nmero de identificacin exclusivo, como un nmero de Id. o un nmero de serie o cdigo, sirve como clave principal en una tabla. Por ejemplo, en una tabla Clientes, cada cliente podra tener un nmero de Id. de cliente distinto. El campo Id. de cliente sera, en ese caso, la clave principal. Clave principal Clave externa

Pgin a 39

Un buen candidato para una clave principal debe tener varias caractersticas. En primer lugar, debe identificar inequvocamente cada fila. En segundo lugar, nunca debe estar vaco ni ser nulo (siempre debe contener un valor). En tercer lugar, casi nunca (o, preferiblemente, nunca) debe cambiar. Access utiliza campos de clave principal para reunir rpidamente los datos de varias tablas. Un ejemplo de una mala eleccin de clave principal sera un nombre o una direccin, ya que tanto el nombre como la direccin contienen informacin que puede cambiar con el tiempo. Siempre debe especificar una clave principal para una tabla. Access crea automticamente un ndice para la clave principal, que permite agilizar las consultas y otras operaciones. Access comprueba tambin que cada registro tiene un valor en el campo de clave principal y que ste es siempre distinto. Cuando crea una nueva tabla en la vista Hoja de datos, Access crea automticamente una clave principal y le asigna un nombre de campo de "Id." y el tipo de datos Auto numrico. El campo est oculto de forma predeterminada en la vista Hoja de datos, pero se puede ver en la vista Diseo. el tipo de datos Auto numrico de identificador no es "fctico", es decir, no contiene informacin objetiva sobre la fila que representa. Es aconsejable utilizar este tipo de identificadores porque sus valores no cambian. Una clave principal que contiene datos sobre una fila (un nmero de telfono o el nombre de un cliente, por ejemplo) es ms probable que cambie, ya que la propia informacin "fctica" podra cambiar. 1 Una columna con el tipo de datos Auto numrico suele ser una buena clave principal, porque garantiza que no habr dos Id. de producto iguales.

Pgin a 40

En algunos casos, tal vez considere conveniente utilizar dos o ms campos juntos como clave principal de una tabla. Por ejemplo, una tabla Detalles de pedidos que contenga artculos de lnea de pedidos tendra dos columnas en su clave principal: Id. de pedido e Id. de producto. Cuando una clave principal est formada por ms de una columna se denomina clave compuesta. Si tiene una tabla en la que cada registro contiene un nmero de identificacin exclusivo, como un nmero de Id. o un nmero de serie o cdigo, ese campo podra convertirse en una buena clave principal. Para que una clave principal funcione correctamente, el campo debe identificar inequvocamente cada fila, no debe contener un valor vaco o nulo y casi nunca (o, preferiblemente, nunca) debe cambiar. Para definir explcitamente la clave principal, debe utilizar la vista Diseo.

Haga clic en el botn de Microsoft Office

y, a continuacin, haga clic en Abrir.

En el cuadro de dilogo Abrir, seleccione y abra la base de datos. En el panel de exploracin, haga clic con el botn secundario en la tabla en la que desea establecer la clave principal y, en el men contextual, haga clic en Vista Diseo. Seleccione el campo o los campos que desea utilizar como clave principal. Para seleccionar un campo, haga clic en el selector de filas del campo que desee. Para seleccionar varios campos, presione la tecla CTRL y haga clic en el selector de filas de cada campo. En la ficha Diseo, en el grupo Herramientas, haga clic en Clave principal. Se agrega un indicador de clave a la izquierda del campo o campos que ha especificado como clave principal.
Pgin a 41

Quitar la clave principal Cuando quite la clave principal, el campo o campos que hacan la funcin de clave principal ya no servirn como identificadores principales de un registro. Sin embargo, al quitar una clave principal no se elimina el campo o los campos de la tabla. Lo que se quita es la designacin de clave principal de esos campos. Al quitar la clave principal se quita tambin el ndice que se cre para ella.

Haga clic en el botn de Microsoft Office y, a continuacin, haga clic en Abrir. En el cuadro de dilogo Abrir, seleccione y abra la base de datos. Antes de quitar una clave principal, debe asegurarse de que no interviene en ninguna relacin de tabla. Si intenta quitar una clave principal para la que existe una relacin, Access le advertir de que debe eliminar primero la relacin.

Pgin a 42

4.3.-Establecer relaciones entre las tablas creadas

La Relacin se define como una asociacin establecida entre campos comunes de dos tablas, en la que se pueden combinar informacin de varias tablas, por medio de campos comunes.

Una vez creadas tablas independientes para cada tema de la base de datos, se necesita una forma de indicar a Access cmo debe combinar la informacin. El primer paso de este proceso consiste en definir relaciones entre las tablas. Una vez realizada esta operacin, ya se puede comenzar a crear otros tipos de objetos, como consultas, formularios e informes para mostrar informacin de varias tablas a la vez.

Pgin a 43

En una relacin se hacen coincidir los datos de los campos clave (normalmente un campo con el mismo nombre en ambas tablas). En la mayora de los casos, estos campos coincidentes son la //clave principal// de una tabla, que proporciona un identificador nico para cada registro, y una clave externa de la otra tabla. Por ejemplo, una tabla con informacin sobre empleados puede relacionarse con otra con datos de pedidos a travs de un campo comn que podra ser id. de empleado. A la hora de establecer relaciones entre tablas pueden presentarse tres situaciones diferentes:

====== Relacin un======

Pgin a 44

La relacin uno a varios es el tipo de relacin ms comn. En este tipo de relacin, un registro de la Tabla A puede tener muchos registros coincidentes en la Tabla B, pero un registro de la Tabla B slo tiene un registro coincidente en la Tabla

En una relacin uno a uno, cada registro de la Tabla A slo puede tener un registro coincidente en la Tabla V, y viceversa. Este tipo de relacin no es habitual, debido a que la mayora de la informacin relacionada de esta forma estara en una sola tabla. Puede utilizar la relacin uno a uno para dividir una tabla con muchos campos, para aislar parte de una tabla puto por razones de seguridad o para almacenar informacin que slo se aplica a un subconjunto de la tabla principal. Por ejemplo, puede crear una tabla que registre los empleados acogidos a un determinado plan de jubilacin. ====== Definir relaciones ====== Para definir una relacin es necesario agregar a la ventana Relaciones las tablas que se desea relacionar y, a continuacin, arrastrar el campo clave de una tabla y colocarlo sobre el campo clave de la otra tabla.

Pgin a 45

UNIDAD V. VERIFICAR EL SISTEMA DE INFORMACION

Verificar el sistema de informacin
En un mtodo y un sistema para controlar y cambiar el funcionamiento de un sistema informtico, el sistema consta de una red de rea local o redes de reas locales interconectadas, cada una de las cuales tiene una pluralidad de ordenadores. El sistema contiene adems al menos un generador de informes de eventos en cada uno de los programas ejecutables cuya ejecucin se debera controlar, una maquina procesadora de eventos, para procesar los eventos sobre los que se ha realizado un informe a travs de un generador de informes de eventos dependiendo de una base de reglas elsticas incluida en la maquina procesadora de eventos y un cierto evento con una accin predeterminada para determinar la accin asociada al evento sobre el que se ha realizado el informe. Un equipo controlado por la maquina procesadora de informes y adaptado para llevar a cabo una accin determinada por la maquina procesadora de eventos. Y una interfaz para transferir un evento sobre el que el generador de informes de eventos ha realizado un informe a una maquina procesadora de eventos y para transmitir un mensaje relativo a una accin asociada al evento. Desde la maquina procesadora de eventos a un programa que se puede ejecutar en el sistema informtico, para el cambio o inicio de la misma.

5.1.- Realizar pruebas al sistema de informacin.

Pgin a 46

Pruebas (unitarias y de integracin) Entre las diversas pruebas que se le efectan al software se pueden distinguir principalmente: Pruebas unitarias: Consisten en probar o testear piezas de software pequeas; a nivel de secciones, procedimientos, funciones y mdulos; aquellas que tengan funcionalidades especficas. Dichas pruebas se utilizan para asegurar el correcto funcionamiento de secciones de cdigo, mucho ms reducidas que el conjunto, y que tienen funciones concretas con cierto grado de independencia. Pruebas de integracin: Se realizan una vez que las pruebas unitarias fueron concluidas exitosamente; con stas se intenta asegurar que el sistema completo, incluso los subsistemas que componen las piezas individuales grandes del software funcionen correctamente al operar e interpelar en conjunto. Las pruebas normalmente se efectan con los llamados datos de prueba, que es un conjunto seleccionado de datos tpicos a los que puede verse sometido el sistema, los mdulos o los bloques de cdigo. Los datos de prueba no necesariamente son ficticios o creados, pero normalmente si lo son los de poca probabilidad de ocurrencia. Generalmente, existe una fase probatoria final y completa del software, llamada beta test, durante la cual el sistema instalado en condiciones normales de operacin y trabajo es probado exhaustivamente a fin de encontrar errores, inestabilidades, respuestas errneas, etc. que hayan pasado los previos controles

5.2.-Validar el Sistema de Informacin.

Validar datos hace referencia a verificar, controlar o filtrar cada una de las entradas de datos que provienen desde el exterior del sistema. Especialmente en sitios web o sistemas online, es fundamental poner algn sistema para validar datos en formularios online y en los parmetros en las direcciones URL. Por ejemplo, una direccin de una pgina web como la siguiente: "nota.php?id=20", recibe el parmetro "id" con valor "20", eso mostrara la nota identificada con ese valor. El cdigo de la pgina "nota.php", debera validar el dato de entrada, verificando que siempre entre un nmero entero. De lo contrario, cualquier atacante podra cambiar ese nmero por un cdigo SQL maligno y, por ejemplo, eliminar toda la base de datos del servidor web. Esta tcnica maligna es llamada inyeccin SQL.
Pgin a 47

La validacin de datos tambin puede hacerse en los formularios web, tanto del lado del cliente (con JavaScript por ejemplo), como del lado del servidor. La validacin por el lado del cliente permite, por ejemplo, avisarle al usuario que el campo de email que acaba de llenar no contiene una direccin de email vlida. Tambin permite avisar si falta rellenar campos o que se estn utilizando caracteres no vlidos, etc. En tanto, del lado del servidor, se deben volver a verificar todos esos datos, adems de otras verificaciones. Esto es as porque la validacin por JavaScript puede evitarse si el usuario tiene alguna mal intencin. En definitiva, se debe identificar cada uno de los flujos de entrada, verificar que el tipo de dato sea el esperado y no otro, verificar que no haya cdigos ocultos, etc. Las etapas del ciclo de vida de un sistema de informacin son: 1). - Planificacin del proyecto o Investigacin Preliminar. 2). - Definicin del sistema. 3). - Recoleccin y anlisis de los requisitos. 4). - Diseo de la aplicacin o del sistema. 5). - Implementacin y evaluacin del sistema. 6). - Prueba de sistemas. 7). - Mantenimiento. Validar" el sistema informtico, est haciendo referencia a la evaluacin y la prueba del sistema.

5.3.-Implantar el sistema de informacin

En la fase de implantacin, las especificaciones del diseo del sistema sirven como base para la construccin del nuevo sistema. En este punto, los programadores y los analistas de sistemas asumen diferentes responsabilidades. El analista debe proveer especificaciones claras y correctas al programador. El programador codifica, prueba y documenta los mdulos de programas, mientras que el analista de sistema planifica la integracin de los programas y asegura que trabajen unidos para satisfacer las necesidades de la organizacin. Un nuevo sistema requiere planificacin, construccin y prueba. Los programas y mdulos deben ser diseados, codificados, probados y documentados. Cuando se planifica el sistema, muchas veces se usa un estilo de arriba-hacia-abajo (topdown), que procede de un diseo general a una estructura detallada siguiendo unos pasos lgicos.
Pgin a 48

En el estilo top-down, el analista de sistemas define los objetivos generales, y luego los descompone en subsistemas y mdulos en un proceso llamado partitioning. Este estilo tambin se conoce como diseo modular. Un mdulo es un conjunto de instrucciones de programas que se pueden ejecutar como un grupo. Asignando mdulos a diferentes programadores se agiliza el desarrollo del programa.

Codificacin Codificar es el proceso de transformar la lgica del programa en instrucciones especficas que puedan ser ejecutadas por el sistema de computadoras. Si se ha preparado un buen diseo, el proceso de codificar es una simple traduccin de funciones lgicas a un cdigo de programa. Cada departamento de sistemas tiene su estndar en lenguajes de programacin, como Visual C++, Access, Visual Basic, SQL, HTML, Java, entre otros.

Probando la aplicacin Despus de codificar, el programador debe hacer pruebas con el programa para asegurarse que trabaja correctamente. Luego, los programas se prueban en grupos, y finalmente, el sistema completo se prueba

Primero, el programa se compila para detectar errores de sintaxis (syntax errors), que son errores gramaticales del lenguaje usado en el cdigo. Los errores se corrigen y se vuelve a compilar el programa. Este proceso se repite hasta que se obtenga una compilacin libre de errores. Luego el programador realiza una verificacin de escritorio (desk checking), para asegurar que no existen errores de lgica (logic errors), que producen resultados incorrectos. Finalmente, el programador prueba el programa. El proceso de prueba de un programa individual o de un mdulo se llama unit testing. Los objetivos son identificar y eliminar errores de ejecucin que causan que el programa termine en forma anormal y encontrar y corregir errores de lgica, que no se identificaron en el desk checking. Se debe incluir datos correctos e incorrectos y deben probar todas las posibles situaciones que el programa debe manejar.

Pgin a 49

Probar dos o ms programas que dependen uno del otro es llamado "link testing". El probar los programas en forma independiente no asegura que al unirlos trabajen adecuadamente. Luego de completar el "link testing", se deben ejecutar pruebas que involucre todo el sistema de informacin. Un "system test" incluye todas las situaciones tpicas: los usuarios entran los datos, que deben ser ejemplo de datos reales, y simulan operaciones actuales. Todos los procesos y outputs son verificados por los usuarios y el grupo de IS para asegurar que el sistema funciona correctamente.

Instalacin y Evaluacin

El ambiente operacional o ambiente de produccin es el ambiente de equipo y programas donde opera el sistema actual. El ambiente que los analistas y programadores usan para desarrollar y mantener programas se llama ambiente de prueba (test environment).Un rea de prueba separada es necesaria para mantener la seguridad e integridad del sistema y proteger el ambiente operacional. El acceso a este ambiente es limitado a los usuarios y estrictamente controlado. Los analistas y programadores no deben tener acceso al mismo excepto para corregir problemas del sistema o realizar modificaciones autorizadas. El ambiente de prueba contiene copias de todos los programas. Antes de realizar cualquier cambio en el sistema operacional, se deben verificar en el ambiente de prueba y se debe obtener autorizacin del usuario.

5.4 REALIZAR MANTENIMIENTO AL SISTEMA DE INFORMACION Mantenimiento de los sistemas de informacin Con posterioridad a la fase de implementacin de los sistemas, se impone la fase de mantenimiento. El mantenimiento de sistemas es el mantenimiento continuo despus del inicio del funcionamiento.
Pgin a 50

Cuando se elaboran planes para la estrategia de informacin, las organizaciones no pueden dejar de considerar que el mantenimiento de sistemas es la fase ms prolongada y costosa del ciclo de vidade los sistemas. Las implicaciones del volumen de trabajo para mantenimiento para los planes de estrategia de informacin en una organizacin es un tema que merece atencin especial La estructura de organizacin necesita flexibilidad para apoyar el mantenimiento de los sistemas existentes concurrentemente con la ejecucin de nuevas tecnologas. Es importante considerar la evaluacin y el monitoreo de un sistema en trminos del mantenimiento necesario y, en consecuencia, reducir o contener los costos implcitos El mantenimiento de sistemas puede clasificarse en cuatro grupos, cada uno de los cuales repercute en el plan estratgico de informacin institucional de diferentes maneras:
Mantenimiento correctivo. Independientemente de cun bien diseado,

desarrollado y probado est un sistema o aplicacin, ocurrirn errores inevitablemente. Este tipo de mantenimiento se relaciona con la solucin o la correccin de problemas del sistema. Atae generalmente a problemas no identificados durante la fase de ejecucin. Un ejemplo de mantenimiento correctivo es la falta de una caracterstica requerida por el usuario, o su funcionamiento defectuoso.

Mantenimiento para fines especficos. Este tipo de mantenimiento se refiere a la creacin de caractersticas nuevas o a la adaptacin de las existentes segn lo requieren los cambios en la organizacin o los usuarios, por ejemplo, los cambios en el cdigo tributario o los reglamentos internos de la organizacin.

Mantenimiento para mejoras. Se trata de la extensin o el mejoramiento

del desempeo del sistema, ya sea mediante el agregado de nuevas caractersticas, o el cambio de las existentes. Un ejemplo de este tipo de mantenimiento es la conversin de los sistemas de texto a GUI (interfaz grfica de usuarios).

Mantenimiento preventivo. Este tipo de mantenimiento es probablemente uno de los ms

Pgin a 51

eficaces en funcin de los costos, ya que si se realiza de manera oportuna y adecuada, puede evitar serios problemas en el sistema. Un ejemplo de este mantenimiento es la correccin del problema del ao 2000.

Unidad VI.- Elaborar documentos del sistema de informacin en un lenguaje de programacin estructurado.
6.1.- Elaborar el manual tcnico Un Manual tcnico es un documento que se hace con la finalidad de dejar documentado, es decir, explicado todo el trabajo que se ha realizado al desarrollar un sistema o proyecto, como la
Pgin a 52

estructura de datos que usaste, cada funcin o procedimiento, cada variable, metodologas, etc. y puede ser un documento impreso o en digital. Un manual tcnico es aquel que va dirigido a un pblico con conocimientos tcnicos sobre algn rea.

Objetivo general del sistema. Se debe de describir el objetivo general del sistema. Objetivos especficos. Se deben describir brevemente los objetivos especficos que se cumplieron con el desarrollo del sistema. Descripcin de campos requeridos por pantalla con presentacin de pantallas.

Describir todos las herramientas que se utilizaron y especificar como se introdujeron. Plataforma de usuario. Aqu se describen los requerimientos mnimos que se deben tener tanto de hardware como de software para que el sistema se pueda instalar y ejecutar correctamente (en caso de que se considere necesario).
Pgin a 53

Y ya por ultimo necesitas hacer una prueba del sistema para ver si funciona correctamente.

Pgin a 54

6.2.- Elaborar el manual de usuario.

Manual de Usuario: Documento elaborado con el fin de capacitar, ensear, aprender y/o conocer un programa de manera detallada, y mediante el uso de capturas de pantalla. Este documento est dirigido al usuario final. Pasos para elaborar el manual del usuario: 1. Portada: De que se trata el documento y quien lo elaboro. 2. Introduccin: Describe el uso del documento; (para qu sirve? y de qu habla?).

Pgin a 55