Establecer Relacion Entre las Tablas Creadas
Una vez creadas tablas independientes para cada tema de la base de datos, se necesita una forma de indicar a Access cómo debe combinar la información. El primer paso de este proceso consiste en definir relaciones entre las tablas. Una vez realizada esta operación, ya se puede comenzar a crear otros tipos de objetos, como consultas, formularios e informes para mostrar información de varias tablas a la vez.
En una relación se hacen coincidir los datos de los campos clave (normalmente un campo con el mismo nombre en ambas tablas). En la mayoría 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 información sobre empleados puede relacionarse con otra con datos de pedidos a través de un campo común que podría ser id. de empleado.A la hora de establecer relaciones entre tablas pueden presentarse tres situaciones diferentes:
====== Relación un======
La relación uno a varios es el tipo de relación más común. En este tipo de relación, un registro de la Tabla A puede tener muchos registros coincidentes en la Tabla B, pero un registro de la Tabla B sólo tiene un registro coincidente en la Tabla A.
Relación uno a uno En una relación uno a uno, cada registro de la Tabla A sólo puede tener un registro coincidente en la Tabla V, y viceversa. Este tipo de relación no es habitual, debido a que la mayoría de la información relacionada de esta forma estaría en una sola tabla. Puede utilizar la relación uno a uno para dividir una tabla con muchos campos, para aislar parte de una tabla puto por razones de seguridad o para almacenar información que sólo 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 jubilación.
Una relación varios a varios es, en realidad, dos relaciones uno a varios con una tercera tabla cuya clave principal consta de dos campos: las claves externas de las otras dos tablas.Pero veamos cuáles son los pasos a seguir para definir una relación entre tablas:
1. Cierre todas las tablas que estén abiertas. No es posible crear ni modificar relaciones entre tablas abiertas.
2. Si se encuentra en otra ventana, cámbiese a la ventana Base de datos. Puede pulsar F11 para cambiar a la ventana Base de datos desde cualquier otra ventana.3. Pulse en el botón Relaciones de la barra de herramientas.
4.Pueden darse los siguientes casos:Si la base de datos no tiene ninguna relación definida, se mostrará automáticamente el cuadro de diálogo Mostrar tabla·
Si necesita agregar las tablas que desea relacionar y no aparece el cuadro de diálogo Mostrar tabla, pulse en el botón Mostrar tabla de la barra de herramientas.·
Si las tablas que desea relacionar ya están a la vista en el cuadro Mostrar tabla, continúe en el paso
5.Pulse dos veces en los nombres de las tablas que desea relacionar y, a continuación, cierre el cuadro de diálogo Mostrar tabla. Esto le situará en el cuadro de diálogo Relaciones
6.Arrastre el campo que desea relacionar de una tabla al campo relacionado de la otra tabla. Si desea arrastrar en una sola operación varios campos, mantenga pulsada la tecla CTRL mientras pulsa en cada uno de los campos para seleccionarlos antes de efectuar el arrastre. A la hora de asociar campos, tenga esto en cuenta· En la mayoría de los casos, se arrastra el campo de clave principal (mostrado en texto en negrita) de una tabla a un campo similar (normalmente con el mismo nombre) denominado la clave externa de la otra tabla.· Los campos relacionados no tienen que tener los mismos nombres, pero deben tener el mismo tipo de datos (con dos excepciones, como se explica en el punto cuatro) y deben contener el mismo tipo de información.· Cuando los campos coincidentes son campos Numéricos, deben tener el mismo valor de la propiedad Tamaño del campo.· Las dos excepciones a los tipos de datos coincidentes son que se pude hacer coincidir un campo Autonumérico con un campo Numérico si ambos campos tienen la propiedad Tamaños de campo establecida en id. de réplica.
7.Aparecerá el cuadro de diálogo Relaciones.Compruebe los nombres de los campos mostrados en las dos columnas para asegurarse de que son correctos. Puede cambiarlos si es necesario. Si es necesario, establezca las opciones de relación. Para obtener información acerca de un elemento específico del cuadro de diálogo Relaciones, pulse en el botón de signo de interrogación y después en el elemento en cuestión.
8.Pulse en el botón Crear para establecer la relación de forma efectiva.
9.Repita los pasos del 5 al 8 para cada pareja de tablas que desee relacionar.Al cerrar la ventana Relaciones, Access pregunta si desea guardar el diseño. Independientemente de si lo guarda o no, las relaciones creadas se guardan en la base de datos.En la ventana Relaciones puede realizar lo siguiente:
Si necesita ver todas las relaciones definidas en la base de datos, pulse en Mostrar todas las relaciones en la barra de herramientas. Para ver sólo las relaciones definidas para una tabla determinada, pulse en la tabla y después en el botón Mostrar relaciones directas en la barra de herramientas.
Si necesita realizar un cambio en el diseño de una tabla. Puede pulsar con el botón secundario del ratón en la tabla que desea modificar y seleccionar Diseño de tabla en el menú contextual.· Para crear una relación entre una tabla y si misma, agregue esa tabla dos veces. Esto resulta útil en situaciones en las que necesita realizar una búsqueda dentro de la misma tabla.
===== Definir una relación varios a varios entre tablas =====
Si necesita definir una relación varios a varios entre tablas, siga estos pasos:
1.Cree las dos tablas que tendrán una relación varios a varios.
2.Cree una tercera tabla, denominada //tabla de unión//, y agregue a ésta los campos con las mismas definiciones que los campos de clave principal de cada una de las otra dos tablas. En la tabla de unión, los campos de clave principal funcionan como claves externas. También puede agregar otros campos a la tabla de unión, exactamente igual que lo haría con cualquier otra tabla.
3.En la tabla de unión, establezca una clave principal que incluya los campos de clave principal de las otras dos tablas. He aquí un resumen de los pasos a seguir para conseguir esto:· Abra la tabla de unión en la vista Diseño.· Seleccione los campos que desea definir como clave principal (utilice CTRL para seleccionar ambos campos).· Pulse en el botón Clave principal de la barra de herramientas.
4.Defina una relación uno a varios entre cada una de las dos tablas principales y la tabla de unión, como se ha visto en el apartado anterior.Cuando necesite agregar datos a las tablas, tiene dos opciones:· Crear una consulta basada en ambas tablas.· Crear un formulario basado en las dos tablas.
===== Modificar una relación existente =====
Una vez definidas las relaciones, pueden modificarse éstas siguiendo estos pasos:
1. Cierre todas las tablas abiertas. Tenga presente que no se pueden modificar relaciones entre tablas que se encuentren abiertas.
2. Cambie a la ventana Base de datos (F11), si no estuviese ya en ella.
3. Pulse en le botón Relaciones de la barra de herramientas.
4. Si las tablas cuya relación desea modificar no están a la vista en la ventana Relaciones, pulse en el botón Mostrar tabla en la barra de herramientas y pulse dos veces en cada una de las tablas que desee agregar.
5. Para eliminar una relación, pulse dos veces en la línea correspondiente a la misma en la ventana Relaciones.
6. Establezca en el cuadro de diálogo Relaciones las nuevas opciones de las relaciones y pulse finalmente en el botón Aceptar.
http://www.wikilearning.com/curso_gratis/tablas_en_access-relacionar_tablas/3766-1
miércoles, 23 de junio de 2010
4.2 Asignar las Claves Principales a las Tablas Creadas
Asignar las Claves Principales a las Tablas Creadas
Antes de guardar la tabla tendremos que asignar una clave principal.
La clave principal proporciona un valor único para cada fila de la tabla y nos sirve de identificador de registros de forma que con esta clave podamos saber sin ningún tipo de equivocación el registro al cual identifica. No podemos definir más de una clave principal, pero podemos tener una clave principal compuesta por más de un campo.
Para asignar una clave principal a un campo, seguir los siguientes pasos:
Hacer clic sobre el nombre del campo que será clave principal.
Hacer clic sobre el botón Clave principal en el marco Herramientas de la pestaña Diseño.
A la izquierda del nombre del campo aparecerá una llave indicándonos que dicho campo es la clave principal de la tabla.
Si queremos definir una clave principal compuesta (basada en varios campos), seleccionar los campos pulsando simultaneamente la tecla Ctrl y el campo a seleccionar y una vez seleccionados todos los campos hacer clic en el borón anterior .
Importante: Recordar que un campo o combinación de campos que forman la clave principal de una tabla no puede contener valores nulos y no pueden haber dos filas en la tabla con el mismo valor en el campo/s clave principal.
Cuando intentemos insertar una nueva fila con valores que infrinjan estas dos reglas, el sistema no nos deja crear la nueva fila y nos devuelve un error de este tipo:
.
La clave principal proporciona un valor único para cada fila de la tabla y nos sirve de identificador de registros de forma que con esta clave podamos saber sin ningún tipo de equivocación el registro al cual identifica. No podemos definir más de una clave principal, pero podemos tener una clave principal compuesta por más de un campo.
Para asignar una clave principal a un campo, seguir los siguientes pasos:
Hacer clic sobre el nombre del campo que será clave principal.
Hacer clic sobre el botón Clave principal en el marco Herramientas de la pestaña Diseño.
A la izquierda del nombre del campo aparecerá una llave indicándonos que dicho campo es la clave principal de la tabla.
Si queremos definir una clave principal compuesta (basada en varios campos), seleccionar los campos pulsando simultaneamente la tecla Ctrl y el campo a seleccionar y una vez seleccionados todos los campos hacer clic en el borón anterior .
Importante: Recordar que un campo o combinación de campos que forman la clave principal de una tabla no puede contener valores nulos y no pueden haber dos filas en la tabla con el mismo valor en el campo/s clave principal.
Cuando intentemos insertar una nueva fila con valores que infrinjan estas dos reglas, el sistema no nos deja crear la nueva fila y nos devuelve un error de este tipo:
.
4.1 Crear Tablas de Acuerdo a los Atributos de Diseño
Crear Tablas de Acuerdo a los Atributos de Diseño
Para crear una tabla de datos tenemos que hacer clic en la pestaña Crear para visualizar sus opciones. En el marco Tablas podremos seleccionar estas opciones:
El botón Tabla abre la Vista Hoja de datos, consiste en introducir directamente los datos en la tabla y según el valor que introduzcamos en la columna determinará el tipo de datos que tiene la columna.
Vista diseño es el método que detallaremos en esta unidad didáctica
Plantillas de tabla crea una tabla de entre un listado que tiene predefinido, abre una tabla de este tipo y sólo tendrás que rellenarla con sus datos.
Listas de SharePoint consiste en crear un objeto compatible con un sitio SharePoint desde el que podrás compartir los datos almacenados en la lista o tabla con otras personans con acceso al mismo sitio.
Explicaremos a continuación la forma de crear una tabla en vista diseño. Este método consiste en definir la estructura de la tabla, es decir, definir las distintas columnas que esta tendrá y otras consideraciones como claves, etc...Otra forma rápida de llegar a la vista Diseño es seleccionando la vista desde la pestaña Hoja de datos, o haciendo clic en el botón de Vista de Diseño en la barra de estado:
Aparecerá la vista de Diseño de la tabla:
En la pestaña tenemos el nombre de la tabla (como todavía no hemos asignado un nombre a la tabla, Access le ha asignado un nombre por defecto Tabla1).
A continuación tenemos la rejilla donde definiremos las columnas que componen la tabla, se utiliza una línea para cada columna, así en la primera línea (fila) de la rejilla definiremos la primera columna de la tabla y así sucesivamente.
En la parte inferior tenemos a la izquierda dos pestañas (General y Búsqueda) para definir propiedades del campo es decir características adicionales de la columna que estamos definiendo.
Y a la derecha tenemos un recuadro con un texto que nos da algún tipo de ayuda sobre lo que tenemos que hacer, por ejemplo en este momento el cursor se encuentra en la primera fila de la rejilla en la columna Nombre del campo y en el recuadro inferior derecho Access nos indica que el nombre de un campo puede tener hasta 64 caracteres.
Vamos rellenando la rejilla definiendo cada una de las columnas que compondrá la tabla:
En la primera fila escribir el nombre del primer campo, al pulsar la tecla INTRO pasamos al tipo de datos, por defecto nos pone Texto como tipo de dato. Si queremos cambiar de tipo de datos, hacer clic sobre la flecha de la lista desplegable de la derecha y elegir otro tipo.
Para más información sobre los diferentes tipos de datos haz clic aquí .
Si deseas información sobre el asistente para búsquedas haz clic aquí .
Observa como una vez tengamos algún tipo de dato en la segunda columna, la parte inferior de la ventana, la correspondiente a Propiedades del campo se activa para poder indicar más características del campo, características que veremos con detalle en la unidad temática siguiente.
A continuación pulsar la tecla INTRO para ir a la tercera columna de la rejilla.
Esta tercera columna no es obligatorio utilizarla ya que únicamente sirve para introducir un comentario, normalmente una descripción del campo de forma que la persona que tenga que introducir datos en la tabla sepa qué debe escribir ya que este cometario aparecerá en la barra de estado de la hoja de datos.
Repetir el proceso hasta completar la definición de todos los campos (columnas) de la tabla.
Bibliografía:
http://www.aulaclic.es/access2007/t_3_1.htm
Para crear una tabla de datos tenemos que hacer clic en la pestaña Crear para visualizar sus opciones. En el marco Tablas podremos seleccionar estas opciones:
El botón Tabla abre la Vista Hoja de datos, consiste en introducir directamente los datos en la tabla y según el valor que introduzcamos en la columna determinará el tipo de datos que tiene la columna.
Vista diseño es el método que detallaremos en esta unidad didáctica
Plantillas de tabla crea una tabla de entre un listado que tiene predefinido, abre una tabla de este tipo y sólo tendrás que rellenarla con sus datos.
Listas de SharePoint consiste en crear un objeto compatible con un sitio SharePoint desde el que podrás compartir los datos almacenados en la lista o tabla con otras personans con acceso al mismo sitio.
Explicaremos a continuación la forma de crear una tabla en vista diseño. Este método consiste en definir la estructura de la tabla, es decir, definir las distintas columnas que esta tendrá y otras consideraciones como claves, etc...Otra forma rápida de llegar a la vista Diseño es seleccionando la vista desde la pestaña Hoja de datos, o haciendo clic en el botón de Vista de Diseño en la barra de estado:
Aparecerá la vista de Diseño de la tabla:
En la pestaña tenemos el nombre de la tabla (como todavía no hemos asignado un nombre a la tabla, Access le ha asignado un nombre por defecto Tabla1).
A continuación tenemos la rejilla donde definiremos las columnas que componen la tabla, se utiliza una línea para cada columna, así en la primera línea (fila) de la rejilla definiremos la primera columna de la tabla y así sucesivamente.
En la parte inferior tenemos a la izquierda dos pestañas (General y Búsqueda) para definir propiedades del campo es decir características adicionales de la columna que estamos definiendo.
Y a la derecha tenemos un recuadro con un texto que nos da algún tipo de ayuda sobre lo que tenemos que hacer, por ejemplo en este momento el cursor se encuentra en la primera fila de la rejilla en la columna Nombre del campo y en el recuadro inferior derecho Access nos indica que el nombre de un campo puede tener hasta 64 caracteres.
Vamos rellenando la rejilla definiendo cada una de las columnas que compondrá la tabla:
En la primera fila escribir el nombre del primer campo, al pulsar la tecla INTRO pasamos al tipo de datos, por defecto nos pone Texto como tipo de dato. Si queremos cambiar de tipo de datos, hacer clic sobre la flecha de la lista desplegable de la derecha y elegir otro tipo.
Para más información sobre los diferentes tipos de datos haz clic aquí .
Si deseas información sobre el asistente para búsquedas haz clic aquí .
Observa como una vez tengamos algún tipo de dato en la segunda columna, la parte inferior de la ventana, la correspondiente a Propiedades del campo se activa para poder indicar más características del campo, características que veremos con detalle en la unidad temática siguiente.
A continuación pulsar la tecla INTRO para ir a la tercera columna de la rejilla.
Esta tercera columna no es obligatorio utilizarla ya que únicamente sirve para introducir un comentario, normalmente una descripción del campo de forma que la persona que tenga que introducir datos en la tabla sepa qué debe escribir ya que este cometario aparecerá en la barra de estado de la hoja de datos.
Repetir el proceso hasta completar la definición de todos los campos (columnas) de la tabla.
Bibliografía:
http://www.aulaclic.es/access2007/t_3_1.htm
3.5 Realiza el Diagrama Entidad Relacion (E/R)
Diagrama Entidad-Relación
Denominado por sus siglas como: E-R; Este modelo representa a la realidad a través de un esquema gráfico empleando los terminología 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 características particulares denominadas atributos, el enlace que que rige la unión de las entidades esta representada por la relación del modelo.
Recordemos que un rectángulo nos representa a las entidades; una elipse a los atributos de las entidades, y una etiqueta dentro de un rombo nos indica la relación que existe entre las entidades, destacando con líneas las uniones de estas y que la llave primaria de una entidad es aquel atributo que se encuentra subrayado.
A continuación mostraremos algunos ejemplos de modelos E-R, considerando las cordialidades que existen entre ellos:
Relación Uno a Uno.
Problema:
Diseñar el modelo E-R, para la relación Registro de automóvil que consiste en obtener la tarjeta de circulación de un automóvil con los siguientes datos:- Automóvil- Modelo, Placas, Color - Tarjeta de circulación -Propietario, No_serie, Tipo.
Indicamos con este ejemplo que existe una relación de pertenencia de uno a uno, ya que existe una tarjeta de circulación registrada por cada automóvil.
En este ejemplo, representamos que existe un solo presidente para cada país.
En este ejemplo, representamos que existe un solo presidente para cada país.
Relación muchos a muchos.
El siguiente ejemplo indica que un cliente puede tener muchas cuentas, pero que una cuenta puede llegar a pertenecer a un solo cliente (Decimos puede, ya que existen cuentas registradas a favor de más de una persona).
Bibliografia
martes, 22 de junio de 2010
3.4 Establecer los Esquemas Para los Enunciados Semanticos
Establecer los Esquemas Para los Enunciados Semanticos
Los objetivos de este trabajo fueron de entrada argumentar acerca de los mecanismos para establecer esquemas sintácticos a partir de enunciados y para adscribirles a sus formantes etiquetas de carácter semántico.en grupos y subgrupos con el fin de compararlos y oponerlos a partir de propiedades combinatorias y características aspectuales.
Se trató de buscar, en fin, algunos criterios adecuados para justificar y elaborar un sistema de oposición paradigmática entre una muestra representativa de esquemas oracionales abstractos del español, en este caso de los correspondientes a esquemas agentivos.
Se presenta un enfoque para el diseño de esquemas de bases de datos de calidad. Este enfoque está basado en el trabajo colaborativo e incremental entre usuarios y diseñadores, además de la medición sistemática de la calidad delos esquemas conceptuales.
Se define un conjunto de criterios de calidad con sus correspondientes métricas para apoyar este enfoque.Además se introduce el criterio de economía y se redefine el criterio de expresividad. Las bases de datos poseen diversos componentes.
Uno de ellos es el esquema conceptual, el cual especifica principalmente los componentes estáticos de la base de datos, incluyendo las estructuras y restricciones estáticas.Esta componente es fundamental para todo el sistema y posee la propiedad de ser independiente de las consideraciones de implementación.
El desarrollo de una base de datos considera mucho más que aspectos estáticos, e involucra otros niveles de abstracción que el conceptual, pero aquellos aspectos escapan del ámbito de este artículo, por lo que no serán tratados aquí (para detalles sobre niveles de abstracción y dimensiones de una base de datos, vea el enfoque de codiseño propuesto por Thalheim [Thalheim2000] ).
Un esquema conceptual se especifica en un lenguaje de modelación, tal como el modelo entidad interrelación [Chen76] o UML [Booch98], pudiendo incluir algunas especificaciones extra, expresadas en lenguaje natural o alguna lógica.Este esquema es un modelo de una realidad o la especificación de una solución a un problema, dependiendo de si se utiliza el lenguaje para análisis o diseño respectivamente.
La entrada al proceso de diseño conceptual es el documento de especificación de requisitos, el cual es el resultado principal de la etapa de análisis. Como todo producto de ingeniería, las bases de datos deben ser desarrolladas de modo de asegurar ciertos niveles mínimos de calidad.El problema radica en que la definición del concepto de calidad debe ser previo a su medición. Ambos asuntos han sido cubiertos en el ámbito del software, pero no en el ámbito específico del diseño conceptual de bases de datos.
En este trabajo se han considerado algunos de los aportes realizados por Batini [Batini94], Moody [Moody94] yKesh [Kesh95], quienes han definido criterios de calidad y algunas métricas para poder medirlos. Para cada uno de los criterios de calidad bajo consideración, se propone una métrica, con lo que se puede obtener una medida de localidad de un esquema conceptual.El proceso de diseño conceptual es una tarea humano-dependiente, en el sentido que requiere de habilidades que son muy difíciles de automatizar.
El diseñador debe analizar la realidad bajo modela miento, documentar los hechos relevantes para satisfacer un conjunto de requerimientos, y complementar el documento de especificación de requisitos una vez que obtiene nueva información a través del proceso de diseño.En cada etapa se utilizan distintas políticas para tomar decisiones de diseño, las cuales pueden variar su importancia (ponderación o peso) dependiendo del diseñador o la etapa del desarrollo en que se encuentre.Esto hace que este proceso sea muy dependiente de 1 Investigación parcialmente financiada por Dirección de Investigación, Universidad de Concepción, Proyecto 99.093.003-1.
0quienes lo desarrollen, y que en la práctica, sea difícil justificar una determinada decisión de diseño, si es que no se cuenta con herramientas adecuadas (parte de las cuales proveemos en este trabajo).
BIBLIOGRAFIA:http://www.inf.udec.cl/~mvaras/papers/2001/mvaras-wisw.pdfhttp://dialnet.unirioja.es/servlet/libro?codigo=267510
Los objetivos de este trabajo fueron de entrada argumentar acerca de los mecanismos para establecer esquemas sintácticos a partir de enunciados y para adscribirles a sus formantes etiquetas de carácter semántico.en grupos y subgrupos con el fin de compararlos y oponerlos a partir de propiedades combinatorias y características aspectuales.
Se trató de buscar, en fin, algunos criterios adecuados para justificar y elaborar un sistema de oposición paradigmática entre una muestra representativa de esquemas oracionales abstractos del español, en este caso de los correspondientes a esquemas agentivos.
Se presenta un enfoque para el diseño de esquemas de bases de datos de calidad. Este enfoque está basado en el trabajo colaborativo e incremental entre usuarios y diseñadores, además de la medición sistemática de la calidad delos esquemas conceptuales.
Se define un conjunto de criterios de calidad con sus correspondientes métricas para apoyar este enfoque.Además se introduce el criterio de economía y se redefine el criterio de expresividad. Las bases de datos poseen diversos componentes.
Uno de ellos es el esquema conceptual, el cual especifica principalmente los componentes estáticos de la base de datos, incluyendo las estructuras y restricciones estáticas.Esta componente es fundamental para todo el sistema y posee la propiedad de ser independiente de las consideraciones de implementación.
El desarrollo de una base de datos considera mucho más que aspectos estáticos, e involucra otros niveles de abstracción que el conceptual, pero aquellos aspectos escapan del ámbito de este artículo, por lo que no serán tratados aquí (para detalles sobre niveles de abstracción y dimensiones de una base de datos, vea el enfoque de codiseño propuesto por Thalheim [Thalheim2000] ).
Un esquema conceptual se especifica en un lenguaje de modelación, tal como el modelo entidad interrelación [Chen76] o UML [Booch98], pudiendo incluir algunas especificaciones extra, expresadas en lenguaje natural o alguna lógica.Este esquema es un modelo de una realidad o la especificación de una solución a un problema, dependiendo de si se utiliza el lenguaje para análisis o diseño respectivamente.
La entrada al proceso de diseño conceptual es el documento de especificación de requisitos, el cual es el resultado principal de la etapa de análisis. Como todo producto de ingeniería, las bases de datos deben ser desarrolladas de modo de asegurar ciertos niveles mínimos de calidad.El problema radica en que la definición del concepto de calidad debe ser previo a su medición. Ambos asuntos han sido cubiertos en el ámbito del software, pero no en el ámbito específico del diseño conceptual de bases de datos.
En este trabajo se han considerado algunos de los aportes realizados por Batini [Batini94], Moody [Moody94] yKesh [Kesh95], quienes han definido criterios de calidad y algunas métricas para poder medirlos. Para cada uno de los criterios de calidad bajo consideración, se propone una métrica, con lo que se puede obtener una medida de localidad de un esquema conceptual.El proceso de diseño conceptual es una tarea humano-dependiente, en el sentido que requiere de habilidades que son muy difíciles de automatizar.
El diseñador debe analizar la realidad bajo modela miento, documentar los hechos relevantes para satisfacer un conjunto de requerimientos, y complementar el documento de especificación de requisitos una vez que obtiene nueva información a través del proceso de diseño.En cada etapa se utilizan distintas políticas para tomar decisiones de diseño, las cuales pueden variar su importancia (ponderación o peso) dependiendo del diseñador o la etapa del desarrollo en que se encuentre.Esto hace que este proceso sea muy dependiente de 1 Investigación parcialmente financiada por Dirección de Investigación, Universidad de Concepción, Proyecto 99.093.003-1.
0quienes lo desarrollen, y que en la práctica, sea difícil justificar una determinada decisión de diseño, si es que no se cuenta con herramientas adecuadas (parte de las cuales proveemos en este trabajo).
BIBLIOGRAFIA:http://www.inf.udec.cl/~mvaras/papers/2001/mvaras-wisw.pdfhttp://dialnet.unirioja.es/servlet/libro?codigo=267510
3.3 Definirlos enunciados semanticos
Definirlos enunciados semanticos
El término semántica se refiere a los aspectos del significado, sentido o interpretación del significado de un determinado elemento, símbolo, palabra, lenguaje o representación formal. En principio cualquier medio de expresión (lenguaje formal o natural) admite una correspondencia entre expresiones de símbolos o palabras y situaciones o conjuntos de cosas que se encuentran en el mundo físico o abstracto que puede ser descrito por dicho medio de expresión.La semántica puede estudiarse desde diferentes perspectivas:
• Semántica lingüística, trata de la codificación y decodificación de los contenidos semánticos en las estructuras lingüísticas.
• Semántica lógica, desarrolla una serie de problemas lógicos de significación, estudia la relación entre el signo lingüístico y la realidad. Las condiciones necesarias para que un signo pueda aplicarse a un objeto, y las reglas que aseguran una significación exacta. • Semántica en ciencias cognitivas, intenta explicar por qué nos comunicamos, y cuál es el mecanismo psíquico que se establece entre hablante y oyente durante este proceso.
www.betoo-charolastras.blogspot.com/2009/03/definir-los-enunciados-semanticos.html
3.2 Establecer Atributos
Establecer Atributos
Los siguientes atributos son necesarios para definir un proyecto:
· El proyecto debe de tener bien definido su objetivo, así como el resultado esperado. Los objetivos de un proyecto se definen en términos de alcance, costo y programa.
· Un proyecto se realiza mediante varias series de tareas independientes, se podría decir que un numero de tareas no repetitivas que es necesario realizar en un cierto orden con el fin de llegar al objetivo esperado del proyecto.
· Al realizar las tareas antes mencionadas se necesitan usar recursos varios, los cuales pueden llegar a incluir diferentes personas, organizaciones, equipos, instalación y materiales.
· El proyecto debe de tener un margen de tiempo específico.
· Cada proyecto tiene un cliente. La entidad cliente, ya sea una persona, empresa, organización o grupo de 2 o mas personas u organizaciones, es la que se encarga de proporcionar los recursos necesarios para el logro del proyecto.
· Ya para terminar un proyecto tiene un nivel de incertidumbre, antes de comenzar un proyecto se debe de tener plan, el cual será la base para ciertos supuestos y estimandos.
http://html.rincondelvago.com/atributos-de-un-proyecto.html
Los siguientes atributos son necesarios para definir un proyecto:
· El proyecto debe de tener bien definido su objetivo, así como el resultado esperado. Los objetivos de un proyecto se definen en términos de alcance, costo y programa.
· Un proyecto se realiza mediante varias series de tareas independientes, se podría decir que un numero de tareas no repetitivas que es necesario realizar en un cierto orden con el fin de llegar al objetivo esperado del proyecto.
· Al realizar las tareas antes mencionadas se necesitan usar recursos varios, los cuales pueden llegar a incluir diferentes personas, organizaciones, equipos, instalación y materiales.
· El proyecto debe de tener un margen de tiempo específico.
· Cada proyecto tiene un cliente. La entidad cliente, ya sea una persona, empresa, organización o grupo de 2 o mas personas u organizaciones, es la que se encarga de proporcionar los recursos necesarios para el logro del proyecto.
· Ya para terminar un proyecto tiene un nivel de incertidumbre, antes de comenzar un proyecto se debe de tener plan, el cual será la base para ciertos supuestos y estimandos.
http://html.rincondelvago.com/atributos-de-un-proyecto.html
3.1 Definir Entidad y Relacion
Definicion Entidar y Relacion
Un diagrama o modelo entidad-relación (a veces denominado por su siglas, E-R "Entity relationship", o, "DER" Diagrama de Entidad Relación) es una herramienta para el modelado de datos de un sistema de información. Estos modelos expresan entidades relevantes para un sistema de información así como sus interrelaciones y propiedades
El modelado entidad-relación es una técnica para el modelado de datos utilizando diagramas entidad relación. No es la única técnica pero sí la más utilizada. Brevemente consiste en los siguientes pasos:
Se parte de una descripción textual del problema o sistema de información a automatizar (los requisitos).
Se hace una lista de los sustantivos y verbos que aparecen.
Los sustantivos son posibles entidades o atributos.
Los verbos son posibles relaciones.
Analizando las frases se determina la cardinalidad de las relaciones y otros detalles.
Se elabora el diagrama (o diagramas) entidad-relación.
Se completa el modelo con listas de atributos y una descripción de otras restricciones que no se pueden reflejar en el diagrama.
Entidad
Representa una “cosa” u "objeto" del mundo real con existencia independiente, es decir, se diferencia unívocamente de cualquier otro objeto o cosa, incluso siendo del mismo tipo, o una misma entidad.
Algunos Ejemplos:
Una persona. (Se diferencia de cualquier otra persona, incluso siendo gemelos).
Un automóvil. (Aunque sean de la misma marca, el mismo modelo,..., tendrán atributos diferentes, por ejemplo, el número de bastidor).
Una casa (Aunque sea exactamente igual a otra, aún se diferenciará en su dirección).
Una entidad puede ser un objeto con existencia física como: una persona, un animal, una 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 características o atributos. Por ejemplo, la entidad Persona puede llevar consigo las características: Nombre, Apellido, Género, Estatura, Peso, Fecha de nacimiento, etc...
Relación
Describe cierta dependencia entre entidades o permite la asociación de las mismas.
Ejemplo:
Dadas dos entidades "Habitación 502" y "Mark", es posible relacionar que la
habitacion 502 se encuentra ocupada por el huésped de nombre Mark.
Bibliografia
3 Diseñar una Base de Datos de Acuerdo al Modelo Entidad Relacion (E/R)
Diseñar una Base de Datos de Acuerdo al Modelo Entidad Relacion (E/R)
lunes, 21 de junio de 2010
2.4 Determinar los Programas a Desarrollar
Determinar los Programas a Desarrollar
Al igual que cualquier otro tipo de software de oficina, hay un montón de programas de diseño 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 diseño. Sin embargo, todo aquél que busque un diseño innovador de bases de datos sin conocer los datos concretos que entran en el sistema puede utilizar varios criterios para encontrar el programa óptimo diseño 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 compañía de software permitirá que un cliente potencial eche un vistazo a las capturas de pantalla o incluso descargue una versión demo del programa para la obtención de muestras.
Con la excepción de las personas instruidas en diseño de bases de datos, más sencillo siempre es mejor y un interfaz desarrollado con muchas campanas y silbidos puede ser desaconsejable.La cuestión que los compradores deben considerar es si una persona con una mínima cantidad de conocimientos o ideas preconcebidas puede utilizar el programa. Además de facilidad de uso, los diseñadores de bases de datos necesitan ver algunos pequeños factores.
La compatibilidad con los sistemas de computación 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 próximo.
Además, siempre hay una consideración 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.
Bibliografía
2.3 Identificar el Equipo a Utilizar
Identificar el Equipo a Utilizar
Una base de datos (cuya abreviatura es BD) es una entidad en la cual se pueden almacenar datos de manera estructurada, con la menor redundancia posible. Diferentes programas y diferentes usuarios deben poder utilizar estos datos. Por lo tanto, el concepto de base de datos generalmente está relacionado con el de red ya que se debe poder compartir esta información. De allí el término base. "Sistema de información" es el término general utilizado para la estructura global que incluye todos los mecanismos para compartir datos que se han instalado.
Aplicación de escritorio para proceso simple (con módulos de extensión de plug-ins).Cliente-servidor con clientes delgados y servidor personalizados.
Aplicación Web de 2-puertos: servidor web/servidor de aplicaciones, base de datos.Aplicación Web de 3-puertos: servidor web/servidor de aplicaciones, base de datos.
Servicio web simple: servidor de aplicaciones, base de datos.Servicios de Red o Web.Cliente-a-cliente sin servidor central.Con tuberías y filtros.Malla de computadoras / servidores distribuidos.
BIBLIOGRAFIA
2.2 Identificar Tipos de Ususario
Identificar Tipos de Usuarios
·Usuario Final: es la persona que utiliza los datos, esta persona ve datos convertidos en información:
·Desarrollador de Aplicaciones: es la persona que desarrolla los sistemas que interactuàn con la Base de Datos.
·DBA: es la persona que asegura integridad, consistencia, redundancia, seguridadeste es el Administrador de Base de Datos quien sed encarga de realizar el mantenimiento diario o periòdico de los datos.
Las personas tienen acceso DBMS se clasifican de la siguiente manera:
USUARIOS INGENUOS. – Son aquellos que interactuan con el sistema por medio de aplicaciones permanentes.
USUARIOS SOFISTICADOS.- son aquellos con la capacidad de acceder a la información por medios de lenguajes de consulta.
PROGRAMADORES DE APLICACIÓN.- son aquellos con un amplio dominio del DML capaces de generar nuevos módulos o utilerias capaces de manejar nuevos datos en el sistema.
USUARIOS ESPECIALIZADOS.- son aquellos que desarrollan módulos que no se refieren precisamente al manejo de los datos, si no a aplicaciones avanzadas como sistemas expertos, reconocimientos de imágenes, procesamiento de audio y demás.
Conceptos Bàsicos de Base de datos
·Desarrollador de Aplicaciones: es la persona que desarrolla los sistemas que interactuàn con la Base de Datos.
·DBA: es la persona que asegura integridad, consistencia, redundancia, seguridadeste es el Administrador de Base de Datos quien sed encarga de realizar el mantenimiento diario o periòdico de los datos.
Las personas tienen acceso DBMS se clasifican de la siguiente manera:
USUARIOS INGENUOS. – Son aquellos que interactuan con el sistema por medio de aplicaciones permanentes.
USUARIOS SOFISTICADOS.- son aquellos con la capacidad de acceder a la información por medios de lenguajes de consulta.
PROGRAMADORES DE APLICACIÓN.- son aquellos con un amplio dominio del DML capaces de generar nuevos módulos o utilerias capaces de manejar nuevos datos en el sistema.
USUARIOS ESPECIALIZADOS.- son aquellos que desarrollan módulos que no se refieren precisamente al manejo de los datos, si no a aplicaciones avanzadas como sistemas expertos, reconocimientos de imágenes, procesamiento de audio y demás.
Conceptos Bàsicos de Base de datos
· Archivo: son conjuntos de registros.
·
· Registros:son conjuntos de campos.
·
· Campos: es la minìma unidad de referencia.
Externo:esa es la visiòn del usuario final, se ve como se maneja los datos ya convertidos en información.
Es aquel en el que se presenta al usuario final y que puede combinaciones o relaciones entre los datos que conforman a la base de datos global. Puede definirse como la forma en el que el usuario aprecia la información y sus relaciones.
Conceptual:se ve como esta estructurado la Base Datos, equipos de campo tiene como estan estructurado los registros.
Es aquel en el que se definen las estructuras lógicas de almacenamiento y las relaciones que se darán entre ellas. Ejemplos comunes de este nivel son el diseño de los registros y las ligas que permitirán la conexión entre registros de un mismo archivo, de archivos distintos incluso, de ligas hacia archivos.
Interno: se ve como se almacena los datos fisicamente.Es aquel en el que se determinan las características de almacenamiento en el medio secundario. Los diseñadores de este nivel poseen un amplio dominio de cuestiones técnicas y de manejo de hardware. Muchas veces se opta por mantener el nivel físico proporcionado por el sistema operativo para facilitar y agilizar el desarrollo.
BIBLIOGRAFIA
:http://www.monografias.com/trabajos34/base-de-datos/base-de-datos.shtml#tipos
2.1 Identificar Tipos de Informacion
Indetificar tipos de informacion
Una base de datos está formada por:Los datos: Que deben ser INTEGRADOS, es decir, que en la unión de los archivos que forman el sistema no exista redundancia de datos Veamos el ejemplo de la gestión de los libros de una biblioteca. Una ficha con datos de un libro, una ficha con datos de un lector y una ficha mostrando el listado de lecturas de un libro, esa ficha que nos entregan junto al libro cuándo nos lo prestan en la biblioteca. Si hacemos un listado con el nombre de los campos que hemos introducido en esas fichas obtendríamos:
Título Autor Editorial Año Idioma Lector Fecha préstamo Fecha
Devolución Nombre Apellidos Domicilio Teléfono DNI
Cada dato de ese listado suma , aparece en una ficha junto a otros con los que se relaciona, y ningún dato se repite en el resto de las fichas, por lo tanto los datos están integrados. Hardware:
Es el soporte físico que permite almacenar la información de la base de datos. Nosotros por el momento trabajaremos con un solo soporte físico, pero hay que saber que una base de datos puede estar formada por varios sistemas, entonces se llama base de datos distribuida. El manejo de este tipo de bases de datos compartidas se complica ya que se necesita comunicación entre los sistemas. Software:
Es el que permite trabajar y gestionar la B.D. de la forma más eficiente. El SGBD (Sistema gestor de bases de datos) es el encargado de gestionar la B.D. por lo tanto todas las operaciones que se realicen sobre las mismas han de pasar por el SGBD.
Devolución Nombre Apellidos Domicilio Teléfono DNI
Cada dato de ese listado suma , aparece en una ficha junto a otros con los que se relaciona, y ningún dato se repite en el resto de las fichas, por lo tanto los datos están integrados. Hardware:
Es el soporte físico que permite almacenar la información de la base de datos. Nosotros por el momento trabajaremos con un solo soporte físico, pero hay que saber que una base de datos puede estar formada por varios sistemas, entonces se llama base de datos distribuida. El manejo de este tipo de bases de datos compartidas se complica ya que se necesita comunicación entre los sistemas. Software:
Es el que permite trabajar y gestionar la B.D. de la forma más eficiente. El SGBD (Sistema gestor de bases de datos) es el encargado de gestionar la B.D. por lo tanto todas las operaciones que se realicen sobre las mismas han de pasar por el SGBD.
Bibliografía:
http://albertoluisaguilar.blogspot.com/2009/03/21-identificar-tipo-de-informacion.html
2 Determinar los elementos de un sistema de base de datos
Determinar los elementos de un sistema de base de datos.
1.6 Obtener los datos del sistema empleando herramientas analiticas
Obtener los datos del sistema empleando herramientas analiticas
1.-Técnicas de búsqueda dedatos
2.-Recolección de datos.
3.-Análisis de la información.
4.-Análisis costo-beneficio.
5.-Informe de resultados a la administración
Bibliografia
www.wikipedia/datos-sistemas/ifo.com
1.-Técnicas de búsqueda dedatos
2.-Recolección de datos.
3.-Análisis de la información.
4.-Análisis costo-beneficio.
5.-Informe de resultados a la administración
Bibliografia
www.wikipedia/datos-sistemas/ifo.com
1.5 Requerimiento de un Sistema
Requerimiento de un Sistema
Un requerimiento funcional puede ser una descripción de lo que un sistema debe hacer. Este tipo de requerimiento específica algo que el sistema entregado debe ser capaz de realizar.
Un requerimiento no funcional: de rendimiento, de calidad, etc.; especifica algo sobre el propio sistema, y cómo debe realizar sus funciones. Algunos ejemplos de aspectos solicitables son la disponibilidad, el testeo, el mantenimiento, la facilidad de uso, etc.
Otros tipos de limitaciones externas, que afectan en una forma indirecta al producto. Estas pueden ir desde la compatibilidad con cierto sistema operativo hasta la adecuación a leyes o regulaciones aplicables al producto.
Los requerimientos son declaraciones que identifican atributos, capacidades, características 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.En el modelo clásico de desarrollo de sistemas o desarrollo software, la etapa de los requerimientos viene antecedida de la etapa de factibilidad del sistema/software y precedida por la etapa de diseño del sistema/software.
Etapas de la fase de requerimientos
* Obtención de requerimientos: búsqueda y obtención de los requerimientos desde los grupos de interés.* Análisis: comprobación de la consistencia y completitud de los requerimientos.* Verificación: constatación de que los requerimientos especificados son correctos.
Clasificación de los requerimientos
Requerimientos funcionales
qué debe hacer el sistema o software.*
Requerimientos no funcionales
cómo debe funcionar el sistema o software (no su implementación), 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, adecuación a determinadas leyes, etc.
Características que deberían cumplir los requerimientos
* Actual: el requerimiento no debe volverse obsoleto con el paso del tiempo.* Cohesión: el requerimiento debe dirigirse a solo una única cosa.* Completo: el requerimiento debe estar completamente declarado en un único lugar, sin información faltante.* Consistente: el requerimiento no debe contradecir ningún otro requerimiento y debe ser completamente consistente con toda la documentación.* Correcto/necesario: el requerimiento debe cumplir con la necesidad declarada por los interesados en el sistema/software.* Factible/viable: el requerimiento debe poder ser implementado.* No ambiguo: el requerimiento debe estar concisamente declarado. Debe expresar hechos objetivos, no opiniones subjetivas. Debe poder ser interpretado de una única manera.* Obligatorio: el requerimiento debe representar una característica definida por el grupo interesado en el desarrollo del sistema/software, su ausencia no puede ser reemplazada. * Observable externamente: el requerimiento debe especificar una característica observable externa o experimentable por el usuario del producto.* Verificable/demostrable: La implementación del requerimiento debe poder ser resuelta en alguno de estos cuatro métodos: inspección, análisis, demostración o prueba.
Bibliografía
http://es.wikipedia.org/wiki/Requerimiento_(sistemas)
Un requerimiento funcional puede ser una descripción de lo que un sistema debe hacer. Este tipo de requerimiento específica algo que el sistema entregado debe ser capaz de realizar.
Un requerimiento no funcional: de rendimiento, de calidad, etc.; especifica algo sobre el propio sistema, y cómo debe realizar sus funciones. Algunos ejemplos de aspectos solicitables son la disponibilidad, el testeo, el mantenimiento, la facilidad de uso, etc.
Otros tipos de limitaciones externas, que afectan en una forma indirecta al producto. Estas pueden ir desde la compatibilidad con cierto sistema operativo hasta la adecuación a leyes o regulaciones aplicables al producto.
Los requerimientos son declaraciones que identifican atributos, capacidades, características 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.En el modelo clásico de desarrollo de sistemas o desarrollo software, la etapa de los requerimientos viene antecedida de la etapa de factibilidad del sistema/software y precedida por la etapa de diseño del sistema/software.
Etapas de la fase de requerimientos
* Obtención de requerimientos: búsqueda y obtención de los requerimientos desde los grupos de interés.* Análisis: comprobación de la consistencia y completitud de los requerimientos.* Verificación: constatación de que los requerimientos especificados son correctos.
Clasificación de los requerimientos
Requerimientos funcionales
qué debe hacer el sistema o software.*
Requerimientos no funcionales
cómo debe funcionar el sistema o software (no su implementación), 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, adecuación a determinadas leyes, etc.
Características que deberían cumplir los requerimientos
* Actual: el requerimiento no debe volverse obsoleto con el paso del tiempo.* Cohesión: el requerimiento debe dirigirse a solo una única cosa.* Completo: el requerimiento debe estar completamente declarado en un único lugar, sin información faltante.* Consistente: el requerimiento no debe contradecir ningún otro requerimiento y debe ser completamente consistente con toda la documentación.* Correcto/necesario: el requerimiento debe cumplir con la necesidad declarada por los interesados en el sistema/software.* Factible/viable: el requerimiento debe poder ser implementado.* No ambiguo: el requerimiento debe estar concisamente declarado. Debe expresar hechos objetivos, no opiniones subjetivas. Debe poder ser interpretado de una única manera.* Obligatorio: el requerimiento debe representar una característica definida por el grupo interesado en el desarrollo del sistema/software, su ausencia no puede ser reemplazada. * Observable externamente: el requerimiento debe especificar una característica observable externa o experimentable por el usuario del producto.* Verificable/demostrable: La implementación del requerimiento debe poder ser resuelta en alguno de estos cuatro métodos: inspección, análisis, demostración o prueba.
Bibliografía
http://es.wikipedia.org/wiki/Requerimiento_(sistemas)
1.4 Toma de Desicion
Toma de decisiones:
Es el proceso mediante el cual se realiza una elección entre las alternativas o formas para resolver diferentes situaciones de la vida, utilizando metodologías cuantitativas que brinda la administración), etc., en todo momento se toman decisiones, la diferencia entre cada una de estas es el proceso o la forma en la cual se llega a ellas. La toma de decisiones consiste, en elegir una alternativa entre las disponibles, a los efectos de resolver un problema actual o potencial, (aún cuando no se evidencie un conflicto latente). Los SI y la toma de decisiones. Los SI van mucho más allá que el diseño y desarrollo del subsistema informático. Un SI puede definirse, como "un conjunto de componentes interrelacionados que permiten capturar, procesar, almacenar y distribuir información para apoyar la toma de decisiones y el control de una institución", además de ayudar a dichos directivos y personal a analizar problemas, visualizar cuestiones complejas y crear nuevos productos en un ambiente intensivo de información. La gestión de la información está orientada al control, preservación y retención de la información. Las necesidades de información pueden ser relativas a hechos presentes o a situaciones futuras, con el objetivo de realizar una dirección proactiva. Las necesidades de información se agrupan según las unidades organizativas de la institución y las aplicaciones que cada una de ellas lleve a cabo. Resulta importante la necesidad de información sobre el entorno, implicando un mecanismo de observación que provea constantemente información relativa a los principales factores estratégicos: competencia, tecnología y política, entre otros. Igualmente, resulta una constante el análisis de información sobre aspectos claves de la organización como I+D, producción, recursos humanos y finanzas, entre otros. La elección o combinación de diversos procedimientos, lógicamente dependerá de las condiciones específicas de cada institución y de los individuos que la componen.
Bibliografía
http://www.angelfire.com/dragon2/informatica/estudio_de_factibilidad.htm
Es el proceso mediante el cual se realiza una elección entre las alternativas o formas para resolver diferentes situaciones de la vida, utilizando metodologías cuantitativas que brinda la administración), etc., en todo momento se toman decisiones, la diferencia entre cada una de estas es el proceso o la forma en la cual se llega a ellas. La toma de decisiones consiste, en elegir una alternativa entre las disponibles, a los efectos de resolver un problema actual o potencial, (aún cuando no se evidencie un conflicto latente). Los SI y la toma de decisiones. Los SI van mucho más allá que el diseño y desarrollo del subsistema informático. Un SI puede definirse, como "un conjunto de componentes interrelacionados que permiten capturar, procesar, almacenar y distribuir información para apoyar la toma de decisiones y el control de una institución", además de ayudar a dichos directivos y personal a analizar problemas, visualizar cuestiones complejas y crear nuevos productos en un ambiente intensivo de información. La gestión de la información está orientada al control, preservación y retención de la información. Las necesidades de información pueden ser relativas a hechos presentes o a situaciones futuras, con el objetivo de realizar una dirección proactiva. Las necesidades de información se agrupan según las unidades organizativas de la institución y las aplicaciones que cada una de ellas lleve a cabo. Resulta importante la necesidad de información sobre el entorno, implicando un mecanismo de observación que provea constantemente información relativa a los principales factores estratégicos: competencia, tecnología y política, entre otros. Igualmente, resulta una constante el análisis de información sobre aspectos claves de la organización como I+D, producción, recursos humanos y finanzas, entre otros. La elección o combinación de diversos procedimientos, lógicamente dependerá de las condiciones específicas de cada institución y de los individuos que la componen.
Bibliografía
http://www.angelfire.com/dragon2/informatica/estudio_de_factibilidad.htm
viernes, 18 de junio de 2010
1.3 Estudio de Factivilidad
Estudio de factibilidad
Es el análisis amplio de los resultados financieros, económicos y sociales de una inversión (dada una opción tecnológica -estudio de pre-factibilidad). En la fase de pre-inversión la eventual etapa subsiguiente es el diseño final del proyecto (preparación del documento de proyecto), tomando en cuenta los insumos de un proceso productivo, que tradicionalmente son: tierra, trabajo y capital (que generan ingreso: renta, salario y ganancia). Objetivo de un Estudio de Factibilidad. 1.- Auxiliar a una organización a lograr sus objetivos. 2.- Cubrir las metas con los recursos actuales en las siguientes áreas. Sirve para recopilar datos relevantes sobre el desarrollo de un proyecto y en base a ello tomar la mejor decisión, si procede su estudio, desarrollo o implementación. Factibilidad se refiere a la disponibilidad de los recursos necesarios para llevar a cabo los objetivos o metas señalados, la factibilidad se apoya en 3 aspectos básicos: · Operativo. · Técnico. · Económico.
a). Factibilidad Técnica. - Mejora del sistema actual. - Disponibilidad de tecnología que satisfaga las necesidades.
b).- Factibilidad Económica. - Tiempo del analista. - Costo de estudio. - Costo del tiempo del personal. - Costo del tiempo. - Costo del desarrollo / adquisición.
c).- Factibilidad Operativa. - Operación garantizada. - Uso garantizado.
Bibliografia:
http://www.angelfire.com/dragon2/informatica/estudio_de_factibilidad.htm
Es el análisis amplio de los resultados financieros, económicos y sociales de una inversión (dada una opción tecnológica -estudio de pre-factibilidad). En la fase de pre-inversión la eventual etapa subsiguiente es el diseño final del proyecto (preparación del documento de proyecto), tomando en cuenta los insumos de un proceso productivo, que tradicionalmente son: tierra, trabajo y capital (que generan ingreso: renta, salario y ganancia). Objetivo de un Estudio de Factibilidad. 1.- Auxiliar a una organización a lograr sus objetivos. 2.- Cubrir las metas con los recursos actuales en las siguientes áreas. Sirve para recopilar datos relevantes sobre el desarrollo de un proyecto y en base a ello tomar la mejor decisión, si procede su estudio, desarrollo o implementación. Factibilidad se refiere a la disponibilidad de los recursos necesarios para llevar a cabo los objetivos o metas señalados, la factibilidad se apoya en 3 aspectos básicos: · Operativo. · Técnico. · Económico.
a). Factibilidad Técnica. - Mejora del sistema actual. - Disponibilidad de tecnología que satisfaga las necesidades.
b).- Factibilidad Económica. - Tiempo del analista. - Costo de estudio. - Costo del tiempo del personal. - Costo del tiempo. - Costo del desarrollo / adquisición.
c).- Factibilidad Operativa. - Operación garantizada. - Uso garantizado.
Bibliografia:
http://www.angelfire.com/dragon2/informatica/estudio_de_factibilidad.htm
1.2 Propuesta de Solucion
Propuesta de Solucion
Esta fase se ocupa de la reunión y estudio a detalle de los datos del sistema en operación y la especificación de los nuevos requerimientos del sistema a desarrollar. Concluye en general con un documento que recoge el resultado del análisis. Con la recopilación de datos se completan los datos resultantes de la fase 1:
añadiendo detalles sobre el sistema actual. Son medios comunes para acometer tal recopilación: Las entrevistas, cuestionarios, encuestas a usuarios finales, así como también, las consultas a documentos y manuales que contengan lineamientos de funcionamiento o normas de procedimientos de operación. Existen varias técnicas y herramientas útiles para el análisis de datos. Una de estas es el uso de diagramas de flujo de datos para diagramar la entrada, proceso y salida de las funciones de la organización de manera grafica. Estos diagramas sirven para desarrollar el llamado diccionario de datos, el cual contiene la definición de los datos usados en el sistema, así como sus características de tipo, tamaño, limitaciones o especificaciones especiales. La documentación de la etapa de análisis recoge la descripción del sistema de información en uso, los requerimientos para el nuevo sistema y un probable plan de desarrollo en un reporte dirigido ala gerencia. Este reporte permite tomar la decisión de proseguir o no con el proyecto. El aspecto más 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 solución es presentar una noción 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 descripción de los problemas:
1.- La Naturaleza del problema.
2.- La historia del problema.
3.- Las características del problema.
4.- Las soluciones alternas consideradas.
5.- La solución o la técnica seleccionada
BIBLIOGRAFIA
http://www.miespacio.org/cont/invest/invmer.htm#tipos
Esta fase se ocupa de la reunión y estudio a detalle de los datos del sistema en operación y la especificación de los nuevos requerimientos del sistema a desarrollar. Concluye en general con un documento que recoge el resultado del análisis. Con la recopilación de datos se completan los datos resultantes de la fase 1:
añadiendo detalles sobre el sistema actual. Son medios comunes para acometer tal recopilación: Las entrevistas, cuestionarios, encuestas a usuarios finales, así como también, las consultas a documentos y manuales que contengan lineamientos de funcionamiento o normas de procedimientos de operación. Existen varias técnicas y herramientas útiles para el análisis de datos. Una de estas es el uso de diagramas de flujo de datos para diagramar la entrada, proceso y salida de las funciones de la organización de manera grafica. Estos diagramas sirven para desarrollar el llamado diccionario de datos, el cual contiene la definición de los datos usados en el sistema, así como sus características de tipo, tamaño, limitaciones o especificaciones especiales. La documentación de la etapa de análisis recoge la descripción del sistema de información en uso, los requerimientos para el nuevo sistema y un probable plan de desarrollo en un reporte dirigido ala gerencia. Este reporte permite tomar la decisión de proseguir o no con el proyecto. El aspecto más 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 solución es presentar una noción 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 descripción de los problemas:
1.- La Naturaleza del problema.
2.- La historia del problema.
3.- Las características del problema.
4.- Las soluciones alternas consideradas.
5.- La solución o la técnica seleccionada
BIBLIOGRAFIA
http://www.miespacio.org/cont/invest/invmer.htm#tipos
1.1 Investigacion Preliminar
Investigación Preliminar
Si un proyecto de sistema parece ser viable y tiene suficiente prioridad, comienza la investigación preliminar. Requiere uno o más analistas de sistemas analizando el “system request” para determinar la verdadera naturaleza y alcance del problema y recomendar si es que se debe continuar con el proyecto. El propósito es buscar información suficiente para determinar si se debe continuar con el Ciclo de Vida del Desarrollo del Sistema. La investigación no es una actividad de recolección de datos; no se espera que se definan todos los problemas ni que se propongan todas las posibles soluciones. La investigación debe de cumplir con los siguientes objetivos:
1. Entender la naturaleza del problema – Primer objetivo de la investigación preliminar. Muchas veces, el problema presentado en el “system request” no es el problema real, sino un síntoma. Al interaccionar con los usuarios, se debe evitar el uso de la palabra problema, ya que puede generar una impresión negativa. Es mejor hablar sobre mejoras que necesita el sistema.
2. Definir el alcance y las restricciones o limitaciones del sistema – El alcance del proyecto es la extensión del proyecto o del sistema, hasta dónde se debe llegar. Se debe determinar quién es afectado por el problema o por la solución. También es importante definir las limitaciones del sistema. Una limitación es una condición, restricción o requisito que el sistema debe satisfacer, puede tener que ver con el equipo, programas, tiempo, leyes, costos y otros.
3. Identificar los beneficios que se obtendrían si el sistema propuesto es completado – Se debe identificar los beneficios tangibles e intangibles que se esperan como resultado del “system request”. Estos beneficios, junto a los estimados de costo, serán usado por la gerencia para decidir si se continúa con el proyecto. Los beneficios tangibles son aquellos que se pueden expresar en términos de dinero. Los beneficios intangibles son difíciles de contabilizar en dólares y centavos, pero son igualmente importantes. Tienen que ver con la satisfacción del empleado, mayor información disponible para tomar decisiones, mejorar la imagen de la compañía y otros aspectos que no se miden en término de dinero.
4. Especificar un estimado de tiempo y costo para las próximas 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 la compañía debe incurrir para completar el sistema. Se debe incluir los costos de desarrollo – costos que ocurren una sola vez – los costos continuos – costos pagados periódicamente.
5. Presentar un informe a la gerencia describiendo el problema y detallando si se recomienda continuar con la fase de análisis del sistema – Debe incluir la evaluación del “system request”, estimado de tiempo y costo-beneficios y las recomendaciones.
Si un proyecto de sistema parece ser viable y tiene suficiente prioridad, comienza la investigación preliminar. Requiere uno o más analistas de sistemas analizando el “system request” para determinar la verdadera naturaleza y alcance del problema y recomendar si es que se debe continuar con el proyecto. El propósito es buscar información suficiente para determinar si se debe continuar con el Ciclo de Vida del Desarrollo del Sistema. La investigación no es una actividad de recolección de datos; no se espera que se definan todos los problemas ni que se propongan todas las posibles soluciones. La investigación debe de cumplir con los siguientes objetivos:
1. Entender la naturaleza del problema – Primer objetivo de la investigación preliminar. Muchas veces, el problema presentado en el “system request” no es el problema real, sino un síntoma. Al interaccionar con los usuarios, se debe evitar el uso de la palabra problema, ya que puede generar una impresión negativa. Es mejor hablar sobre mejoras que necesita el sistema.
2. Definir el alcance y las restricciones o limitaciones del sistema – El alcance del proyecto es la extensión del proyecto o del sistema, hasta dónde se debe llegar. Se debe determinar quién es afectado por el problema o por la solución. También es importante definir las limitaciones del sistema. Una limitación es una condición, restricción o requisito que el sistema debe satisfacer, puede tener que ver con el equipo, programas, tiempo, leyes, costos y otros.
3. Identificar los beneficios que se obtendrían si el sistema propuesto es completado – Se debe identificar los beneficios tangibles e intangibles que se esperan como resultado del “system request”. Estos beneficios, junto a los estimados de costo, serán usado por la gerencia para decidir si se continúa con el proyecto. Los beneficios tangibles son aquellos que se pueden expresar en términos de dinero. Los beneficios intangibles son difíciles de contabilizar en dólares y centavos, pero son igualmente importantes. Tienen que ver con la satisfacción del empleado, mayor información disponible para tomar decisiones, mejorar la imagen de la compañía y otros aspectos que no se miden en término de dinero.
4. Especificar un estimado de tiempo y costo para las próximas 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 la compañía debe incurrir para completar el sistema. Se debe incluir los costos de desarrollo – costos que ocurren una sola vez – los costos continuos – costos pagados periódicamente.
5. Presentar un informe a la gerencia describiendo el problema y detallando si se recomienda continuar con la fase de análisis del sistema – Debe incluir la evaluación del “system request”, estimado de tiempo y costo-beneficios y las recomendaciones.
Pasos para realizar la investigación preliminar:
Obtener la autorización de la gerencia.
Identificar la información necesaria para el proyecto para cumplir con los cinco objetivos de la investigación.
Realizar las acciones que sean necesarias para conseguir la información, por ejemplo:
a. Analizar el organigrama para conocer la estructura de los departamentos y las personas claves para el sistema.
b. Realizar entrevistas a los usuarios, éste es el método principal de obtener información.
c. Revisar la documentación actual, verificando con los usuarios si la documentación es correcta y completa.
d. Observar la operación actual para identificar fuentes de Input y Output.
e. Realizar encuestas, método usado cuando se necesita información de muchas personas.
Analizar la información obtenida, identificando alternativas con sus costos y beneficios y recomendando la acción que se debe tomar.
Presentar los resultados y recomendaciones a la gerencia.
Obtener la autorización de la gerencia.
Identificar la información necesaria para el proyecto para cumplir con los cinco objetivos de la investigación.
Realizar las acciones que sean necesarias para conseguir la información, por ejemplo:
a. Analizar el organigrama para conocer la estructura de los departamentos y las personas claves para el sistema.
b. Realizar entrevistas a los usuarios, éste es el método principal de obtener información.
c. Revisar la documentación actual, verificando con los usuarios si la documentación es correcta y completa.
d. Observar la operación actual para identificar fuentes de Input y Output.
e. Realizar encuestas, método usado cuando se necesita información de muchas personas.
Analizar la información obtenida, identificando alternativas con sus costos y beneficios y recomendando la acción que se debe tomar.
Presentar los resultados y recomendaciones a la gerencia.
bibliografia
Diseños de Sistemas de Informacion
Hernandez Lopez Citlally
Monroy Monroy Mariela
Blazquez Garcia Daniel
Lienzo Trejo Gabriela Yazmin
Sanchez Uribe Mariano Valentin
Monroy Monroy Mariela
Blazquez Garcia Daniel
Lienzo Trejo Gabriela Yazmin
Sanchez Uribe Mariano Valentin
Suscribirse a:
Entradas (Atom)