Desarrollo de La Temática Unidad 1 - Conceptos Generales Del Diseño de Sistemas

DESARROLLO DE CONTENIDOS
UNIDAD I
CONCEPTOS GENERALES DEL DISEÑO DE SISTEMAS
Programa Ciencia de la Información y la Documentación,

Bibliotecología y Archivística
Conceptos Generales del Diseño de Sistemas
a) ¿Qué es Diseño de Sistemas?
El diseño de sistemas se refiere a la formulación de especificaciones para el

nuevo sistema o subsistema propuesto, de manera que satisfaga los requisitos
determinados durante la fase de análisis. Finalmente, el diseño de sistemas
vendrá a ser una presentación detallada del informe de terminación del análisis
de sistemas.
El diseño de un sistema puede descomponerse en especificaciones físicas y lógicas.

El diseño lógico representa los componentes del sistema y sus relaciones mutuas,
como aparecerían ante los usuarios. Muestra lo que la solución sistemática hará en
contraposición con el modo como lo es en la actualidad implantada físicamente. Describe
las entradas y salidas, las funciones de procesamiento a realizar, los procedimientos de
negocios, los modelos de datos y los controles. Mientras que El diseño físico es el
proceso de traducción del modelo lógico abstracto a un diseño técnico específico para el
nuevo sistema. Produce las especificaciones reales para el hardware, software y bases
de datos físicas, medios de entrada/salida, procedimientos manuales y controles
2
específicos. Proporciona las especificaciones que transforman el diseño lógico abstracto

en un sistema de funciones de personas y máquinas.
Cuando el analista esté listo para comenzar a diseñar el nuevo sistema, ya

deben estar establecidos ciertos elementos. Debe hacer una definición del
problema, información general de antecedentes sobre el área bajo estudio, una
idea aproximada de las interacciones dentro del área de estudio y con otras
áreas, un buen entendimiento del sistema actual, y un conjunto de
requerimientos para el nuevo sistema.
b) DISEÑO DE UN SISTEMA DE INFORMACIÓN
El diseño de sistemas de información se define como aquellas tareas que se enfocan

en la especificación de una solución detallada basada en computadora. También se usa
para el diseño físico. Por lo tanto, mientras que el análisis de sistemas enfatiza el
problema comercial, el diseño de los sistemas se enfoca en la implementación en
las diferentes fases.
La mayoría de nosotros definimos el proceso de diseño de manera demasiado restrictiva,

nos imaginamos a nosotros mismos dibujando los planos de los sistemas basados en
computador y que serán programados y desarrollados por nosotros mismos o por
nuestros propios programadores. Por lo tanto, realizamos descripciones, resultados,
archivos, bases de datos y otros componentes de la computadora.
3
SISTEMA DE INFORMACIÓN: ANÁLISIS: Proceso de clasificación e

Conjunto de componentes interpretación de diagnóstico de
organizados para llevar a cabo problemas y el empleo de la información
métodos, procedimientos y para recomendar mejoras a los sistemas.
controles mediante el proceso de
información.
DISEÑO: Especificación de
características de un producto terminado.
El análisis y diseño de sistemas se refiere al

proceso de examinar la situación de una empresa
con el propósito de mejorar con métodos y
procedimientos más adecuados.
EL DISEÑO DEL SISTEMA: Es la estrategia de alto nivel para resolver problemas y

construir una solución dentro de la organización. Éste incluye decisiones acerca de la
organización del sistema en subsistemas, la asignación de subsistemas a componentes
hardware y software, y decisiones fundamentales conceptuales y de política que son las
que constituyen un marco de trabajo para el diseño detallado.
La organización global del sistema es lo que se denomina la arquitectura del sistema.

Existe un cierto número de estilos frecuentes de arquitectura, cada uno de los cuales es
adecuado para ciertas clases de aplicaciones. Una forma de caracterizar una aplicación
es por la importancia relativa de sus modelos de objetos, dinámico y funcional. Las
distintas arquitecturas ponen distintos grados de énfasis en los tres modelos.
El diseño de un sistema de información produce los elementos que establecen cómo el

sistema cumplirá los requerimientos identificados durante el análisis del sistema. A esta
etapa se le conoce también con el nombre de Diseño Lógico.
4
El primer paso en el diseño de sistemas es identificar los informes y las salidas que el
sistema producirá; a continuación, los datos específicos de cada uno de éstos se señalan,
incluyendo su localización exacta sobre el papel, la pantalla de despliegue o cualquier otro
medio.
El diseño de sistemas es la primera fase de diseño en la cual se selecciona la
aproximación básica para resolver el problema. Durante el diseño del sistema, se decide
la estructura y el estilo global. La arquitectura del sistema es la organización global del
mismo en componentes llamados subsistemas. La arquitectura proporciona el contexto en
el cual se toman decisiones más detalladas en una fase posterior del diseño. Al tomar
decisiones de alto nivel que se apliquen a todo el sistema, el diseñador desglosa el
problema en subsistemas, de tal manera que sea posible realizar más trabajo por parte de
varios diseñadores que trabajarán independientemente en distintos subsistemas.
El diseño también describe los datos calculados o almacenados que se introducirán. Los
datos y los procedimientos de cálculo se describen con detalle. Se seleccionan las
estructuras de los archivos y los dispositivos de almacenamiento, como son discos o
cintas magnéticas o papel. Los procedimientos deben de mostrar cómo se van a procesar
los datos y cuáles van a ser las salidas.
Los documentos que contienen las especificaciones del diseño se pueden representar por
medio de los diagramas, tablas y símbolos especiales.
El último paso del diseño detallado es pasar la información al grupo de programación que
se inicie el desarrollo del software.
5
El diseño de sistemas es un proceso altamente creativo que en gran medida puede ser
facilitado por lo siguiente:
PRIMERO: SEGUNDO:
Definición sólida Descripción del
del problema. sistema existente.
TERCERO:
Conjunto de
requerimientos del
nuevo sistema.
Por definición, diseño significa hacer un mapa, planear o arreglar las partes en un todo
que satisfaga los objetivos involucrados. El diseño de sistemas requiere principalmente la
coordinación de actividades, los procedimientos de trabajo y la utilización de equipo para
alcanzar los objetivos organizacionales.
El patrón de diseño de sistemas sigue una técnica iterativa. El diseño de sistemas es un
proceso creativo en el que el analista repite a través de varias actividades o
procedimientos de trabajo, uno a la vez, investigando mentalmente a través del proceso
completo.
El analista debe tener en cuenta dos puntos importantes:
1. Resuelva un problema a la vez. No se confunda al querer resolver muchos problemas

a la vez.
2. Su nuevo sistema debe concordar con los objetivos y metas generales del área bajo 6
estudio y la empresa en sí.
En resumen, entonces, los puntos a seguir cuando se diseña un nuevo sistema son:
• Examine todos los datos posibles.

• Concéntrese y piense en forma creativa.
• Proporcione diferentes, entradas, salidas, operaciones, controles y técnicas de
procedimiento.
• Primero evalúe los procedimientos más importantes.
• Examine las diversas alternativas.
Otra consideración en la fase de diseño es el control que se debe ejercer desde el

sistema. Algunos controles se determinarán por medio de diferentes parámetros de
sistemas tales como las aplicaciones y las entradas. Probablemente se necesite diseñar
ciertos controles de calidad. Por ejemplo, todas las entradas deben preparase en forma
consistente para mantener la confianza del sistema y evitar posibles errores en los
procedimientos.
Las especificaciones de diseño describen las características del sistema, sus

componentes o elementos y la forma en que estos aparecerán ante los usuarios. Para
muchos usuarios, el éxito de un sistema está relacionado con la creencia que tengan
sobre sí el sistema tiene las características adecuadas. Los componentes de un sistema
de información descritos durante el análisis de requerimientos, son el punto principal del
diseño. Los analistas deben diseñar los siguientes elementos:
7
1. Flujos de datos: Movimientos de datos hacía, alrededor y desde el sistema.

2. Almacenes de datos: Conjuntos temporales o permanentes de datos.
3. Procesos: Actividades para aceptar, manejar y suministrar datos e
información. Pueden ser anuales o basadas en computadora.
4. Procedimientos: Métodos y rutinas para utilizar el sistema de información y
lograr con ello los resultados esperados.
5. Controles: Estándares y lineamientos para determinar si las actividades
están ocurriendo en la forma anticipada o aceptada, es decir, si se
encuentran bajo control. Así mismo especificar las acciones que deben
emprenderse cuando ocurren problemas o presentan circunstancias
inesperadas. Puede incluirse un reporte sobre las excepciones o
procedimientos para la corrección de los problemas.
6. Funciones del personal: Las responsabilidades de todas las personas que
tienen que ver con el nuevo sistema incluyendo los usuarios, operadores de
computadora y personal de apoyo. Abarca todo el espectro de componentes
del sistema, incluso desde la entrada de datos hasta la distribución de
salidas o resultados. A menudo, las funciones del personal se establecen en
forma de procedimiento.
Desarrollo del software: A menudo los especialistas de sistemas se refieren a esta

etapa como el Diseño Físico, en contraste con el Diseño del sistema que se conoce como
el diseño lógico.
Los desarrolladores pueden instalar o modificar software que se haya comprado (software
comercial), o pueden escribir nuevos programas diseñados a la medida; la decisión
depende del costo de cada una de las opciones dadas, el tiempo y disponibilidad de los
programadores.
8
Los programadores de software son también responsables de la documentación del

programa y de incluir los comentarios que expliquen cómo y porqué se utilizó cierto
procedimiento. La documentación es esencial para probar el programa y darle
mantenimiento una vez que se ha puesto en marcha.
¿El diseño es una solución?
La conversión de los requerimientos en formas que los satisfagan. El diseño determina el

éxito del sistema. A través del diseño, los analistas de sistemas pueden tener gran
influencia sobre la efectividad del usuario, ya sea para el manejo de transacciones o par la
administración de la organización. Algunos diseños son más efectivos que otros.
Mientras que análisis de sistemas describe lo que un sistema debe hacer para satisfacer
los requerimientos de información, el diseño de sistemas muestra cómo el sistema debe
de satisfacer este objetivo. El diseño de sistemas de información es el plan general o
modelo para ese sistema. Como el plano de un edificio o una casa, tiene todas las
especificaciones que dan al sistema su forma y estructura, el diseño de los sistemas de
información es una tarea creativa que requiere de imaginación, sensibilidad al detalle y
habilidades.
Para diseñar un sistema, el analista debe conocer ciertos elementos relacionados con los
siguientes aspectos:
1. Los recursos de la organización.

2. Las necesidades de información de los usuarios.
3. Las necesidades de otros sistemas.
4. Los métodos de procesamiento de datos
5. Las operaciones con los datos.
6. Las herramientas del diseño.
Para producir el diseño, el analista tiene que aplicar el razonamiento y la creatividad a los
elementos mencionados.
9
C. OBJETIVOS DEL DISEÑO DE SISTEMAS DE INFORMACIÓN
El diseño de sistemas tiene tres objetivos:
Primero, el diseñador de sistemas es responsable de la consideración de otras

configuraciones de tecnología para llevar a cabo y desarrollar el sistema tal y como fue
descrito por el análisis. Esto puede implicar análisis del desempeño de diferentes
elementos de hardware y software capacidades de los sistemas, alternativas de redes y
la transportabilidad del hardware de los sistemas.
Segundo, los diseñadores son responsables por la administración y el control de la

realización técnica de los sistemas. Las especificaciones detalladas de programación,
la codificación de los datos, la documentación, pruebas y la capacitación, son todos
responsabilidad del equipo de diseño. Además, los diseñadores son responsables del
abastecimiento actual del hardware y el software que se necesita para el sistema.
10
Tercero, el diseñador de sistemas detalla las especificaciones del sistema que darán
las funciones identificadas durante el análisis de sistemas. Estas especificaciones
deben tocar todos los componentes administrativos, organizacionales y tecnológicos de
la solución de sistemas.
Especificar los Especificaciones detalladas de diseño que describen las

elementos de diseño características de un sistema de información: entradas,
lógico salidas, archivos y base de datos y procedimientos.
Actividades de soporte Los resultados del empleo del sistema serán de ayuda
para la empresa. para mejorar el rendimiento de la empresa.
Satisfacer las necesidades de los usuarios en términos de:
• Efectuar en forma correcta los procedimientos

Satisfacer los apropiados.
requerimientos de los • Presentar en forma apropiada la información.
usuarios. • Proporcionar resultados exactos.
• Utilizar los métodos de interacción apropiados.
• Proporcionar confiabilidad total.
Fácil de usar. Ingeniería humana favorable: El diseño ergonómico debe

ser físicamente cómodo y contribuir a la efectividad y
eficiencia del usuario.
Proporcionar las Especificar los componentes y funciones con suficiente
especificaciones de detalle para construir el software de aplicación.
software.
Ajustarse a los El diseño y sus especificaciones debe estar en
estándares de diseño concordancia con las reglas prácticas establecidas para la
organización.
D. ETAPAS BÁSICAS DEL PROCESO DISEÑO
En de la práctica, la aplicación del proceso de diseño es un esfuerzo repetitivo. A medida

que el analista va considerando cada uno de los elementos del proceso, se ve obligado a
revisar una y otra vez a reexaminar las estructuras y relaciones establecidas hasta el
momento, y a modificarlas para satisfacer la nueva condición. La repetición continúa hasta
que han sido consideradas todas las dimensiones del sistema propuesto y se formula la
proposición final. Las etapas básicas del proceso de diseño pueden exponerse así: 11
I. Definir el objetivo del sistema.
II. Desarrollar un modelo conceptual.
a) Identificar el resultado más importante del sistema.

b) Señalar los datos específicos de entrada necesarios para obtener ese resultado.
c) Describir las operaciones de procesamiento de datos, particularmente los
algoritmos lógicos y de cálculo, que deben aplicarse a los datos de entrada para
producir la información deseada.
d) Identificar los elementos de entrada que se pueden introducir una sola vez y
quedar almacenados para usarlos en operaciones subsecuentes de
procesamiento.
e) Seguir efectuando los pasos a, b, c, d para cada resultado requerido y por orden
de prioridad hasta haberlos considerado en su totalidad.
f) Establecer un banco de datos que pueda sustentar al sistema en la forma más
efectiva.
III. Aplicar restricciones.
a) En base a las restricciones impuestas eliminar los casos extremos de entrada,

salida y procesamiento.
b) Señalar los diferentes puntos de control.
IV. Definir las actividades de procesamiento de datos.

a) diseñar los formatos de entrada y salida que mejor se adapten al diseño del
sistema.
b) Establecer los métodos de procesamiento y los puntos comunes de los datos.
V. Formular la proposición del diseño del sistema.
Analizando específicamente las entradas, las salidas y las actividades de procesamiento

por orden de su contribución al logro del objetivo general del sistema, el analista reduce al
mínimo el tiempo necesario para llegar a una estructuración del diseño principal. 12
Diseño Estructurado:
Diseño Detallado:
13
DIESÑO DE SALIDAS:
( Diseño del sistema de informes y producción de documentos)
El término salida, como es probable que el lector lo conozca, se refiere a los resultados e
información generados por el sistema. Para muchos usuarios finales, la salida es la única
razón para el desarrollo del sistema y la base sobre la que ellos evaluarán la utilidad de la
aplicación. En la realidad, muchos usuarios no operan el sistema de información y
tampoco ingresas datos en él, pero utilizan la salida generada por el sistema. Cuando
diseñan la salida, los analistas deben de realizar lo siguiente:
• Determinar qué información presentar.

• Decidir si la información será presentada en forma visual, verbal o impresa y
seleccionar el medio de salida.
• Disponer la presentación de la información en un formato aceptable.
• Decidir cómo distribuir la salida entre los posibles destinatarios.
Para llevar a cabo las actividades antes mencionadas, se requieren decisiones

específicas tales como el empleo de formatos ya impresos cuando se preparan reportes,
cuántas líneas planear sobre una página impresa o si se debe emplear gráficas y colores.
La salida es la única razón para el desarrollo del sistema y la base sobre la que ellos
evaluarán la utilidad de la aplicación. En la realidad, muchos usuarios no operan el
sistema de información y tampoco ingresan datos en él, pero utilizan la salida generada
por el sistema.
El diseño de la salida de la computadora debe avanzar en una forma organizada y

bien pensada: tiene que desarrollarse correctamente mientras que al mismo tiempo se
garantice que cada elemento de la salida está diseñado para que las personas
encuentren que el sistema es fácil de emplear.
El termino salida se utiliza para expresar cualquier información, ya sea impresa o

en una pantalla.
14
Cuando los analistas diseñan la salida:
• Identifican la salida específica que es necesaria para satisfacer los requerimientos

de la información.
• Seleccionan los métodos para presentar la información.
• Crean los documentos, reportes u otros formatos que contienen la información
producida por el sistema.
Un sistema de información debe alcanzar uno o más de los siguientes objetivos:
1. Expresar información relacionada con actividades pasadas, estado actual o

protecciones para el futuro.
2. Señalar eventos importantes, oportunidades, problemas o advertencias.
3. Iniciar una acción.
4. Confirmar una acción.
El buen diseño de la salida de los sistemas, no puede ser desarrollado en forma

independiente del uso que se dará a la salida. En otras palabras, no se puede clasificar
como buena una salida estéticamente atractiva o que haga uso de una nueva tecnología,
a menos que satisfaga las necesidades de la organización y de sus usuarios. El propio
proceso de diseño comienza cuando el analista de sistemas identifica la salida que debe
producir el sistema (un proceso que se inicia durante la determinación de requerimientos).
Aspectos importantes de las Salidas
Cuatro preguntas, a las que debe darse respuestas en forma completa y apropiada,
ayudan a los expertos de diseño de sistemas a comprender mejor lo que debe ser la
salida de un nuevo sistema:
15
¿Quiénes Recibirán La Salida?
El usuario, ¿forma o no parte de la organización?, Quizá los usuarios externos tengan

requerimientos específicos que no se pueden cambiar y que dictan los requerimientos de
contenido, formato y medio de presentación. Tal vez las organizaciones decidan
presentar la misma información en forma diferente cuando ésta es enviada a los usuarios
tanto externos como internos.
¿Cuántos Detalles Son Necesarios?

Pocos detalles son necesarios para indicarle a alguien que renové una licencia de manejo
(nombre, dirección, fecha de renovación, cuota y una identificación de la salida como
aviso de renovación). Sin embargo, un informe trimestral de venta de ventas contiene
muchos detalles con formatos diferentes que son de ayuda para trasmitir un mensaje (qué
sucedió, cómo ocurrió y cuál fue el resultado) a todos los usuarios. Asimismo, la cantidad
de datos también sugiere si deben emplear métodos de impresión o de presentación en
una pantalla.
¿Cuántos Y Que Tan Frecuente Es La Salida?

El calendario junto con la oportunidad de la salida, son guías específicas del diseño.
Algunas salidas se producen con poca frecuencia y sólo cuando aparecen ciertas
condiciones: la emisión del aviso de renovación de licencia puede ocurrir cada 4 años, la
emisión de una notificación de pago sucede cuando el saldo de la cuenta está vencido.
sin embargo, la organización puede requerir cada mes una salida que indique todas las
licencias que deben renovarse el próximo mes, o una salida cada semana que señale
todas aquellas cuentas cuyo saldo se venció durante la semana.
¿Qué Método Utilizar?

¿Debe ser impresa o presentada en pantalla? Los ejemplos anteriores muestran que la
salida impresa se emplea con bastante frecuencia. Sin embargo, si un sistema da
respuestas del tipo sí o no a las consultas, a menudo es apropiado presentar la respuesta
en una pantalla, algunos sistemas emplean una salida de audio para informarles sobre un
nuevo número telefónico o el cambio de éste.
16
DISEÑO DE ENTRADAS:
(Diseñar el sistema de recopilación de datos)
Las especificaciones de entrada describen la manera en que los datos ingresarán al

sistema para su procesamiento. Las características de diseño de la entrada pueden
asegurar la confiabilidad del sistema y producir resultados a partir de datos exactos, o
también pueden dar como resultado la producción de información errónea. Asimismo, el
diseño de la entrada determina sí el usuario puede interactuar con el sistema de manera
eficiente. El diseño de la entrada es el enlace que une al sistema de información con el
mundo y sus usuarios. Algunos aspectos del diseño cambian, lo que depende si el
sistema está orientado hacia lotes o en línea. Pero sin considerar el sistema, existen
aspectos generales en la entrada que todos los analistas deben tener en cuenta.
El diseño de la entrada consiste en el desarrollo de especificaciones y procedimientos

para la preparación de datos, la realización de los pasos necesarios para poner los datos
de una transacción en una forma utilizable para su procesamiento, así como la entrada de
éstos. La entrada de estos los datos se logra al instruir la computadora para que los lea
ya sea de documentos escritos o impresos, o por personas que los escriben directamente
en el sistema.
Controles de la cantidad de entrada.
Existen varias razones que explican por qué un buen diseño debe controlar la cantidad de
datos en la entrada. Primero, las operaciones de preparación y entrada dependen de las
personas. Dado que los costos de la mano de obra son altos, los asociados con la
preparación e ingreso de los datos también lo son altos. Disminuir los requerimientos de
datos puede reducir los costos y ocurrir lo mismo con los costos de mano de
obra. Segundo, la fase de entrada puede ser un proceso lento que toma mucho más
tiempo que el que necesitan las computadoras para llevar a cabo sus tareas. De hecho,
la computadora quizá permanezca sin hacer nada durante el tiempo en que se preparan
los datos y la entrada para su procesamiento. Al disminuir los requerimientos de la
entrada, el analista puede acelerar todo el proceso desde la captura de datos hasta que
los resultados llegan a manos de los usuarios.
17
• Evitar Retrasos. Un retraso en el procesamiento, que es un resultado de las

operaciones de preparación o de entrada de datos, recibe el nombre de cuello de
botella. Evitar los cuellos de botella debe ser siempre uno de los objetivos que el
analista persiga al diseñar la entrada.
• Evitar errores de datos. En cierto sentido la tasa de errores depende de la cantidad
de datos, ya que entre más pequeña sea ésta, menores serán las oportunidades para
cometer errores. Es común encontrar en las operaciones de venta al por menor una
tasa promedio del 3% de error en las operaciones de entrada de datos. Si el volumen
de datos es de 10,000 transacciones por semana, entonces se presentarán
aproximadamente 300 errores. A pesar de lo anterior, el analista puede reducir el
número de errores al disminuir el volumen de datos que deben ingresarse por cada
transacción. El analista también puede modificar las tasas de error de una operación
a través del diseño de la entrada, ya que la forma en que deben ingresar los datos
puede tener efectos sobre la incidencia de los errores. Otro aspecto del control de
errores es la necesidad de detectarlos cuando éstos se presentan. Las verificaciones
y balances en los programas para entrada de datos, denominadas técnicas de
validación de entradas, también descubren errores en la entrada.
• Evitar pasos adicionales. Algunas veces el volumen de transacciones y la cantidad
de datos en preparación, o en el trabajo de entrada de datos, es algo que no se puede
controlar. Cuando no es posible reducir el volumen de transacciones, el analista debe
asegurar que el proceso sea lo más eficiente posible. El analista experimentado
también evitará diseños para la entrada que traigan como consecuencia una mayor
cantidad de pasos a seguir. El efecto que trae consigo ya sea añadir o quitar un paso
cuando se alimentan los cheques al proceso bancario, será multiplicado muchas
veces en el transcurso de un día de trabajo.
• Mantener la sencillez del proceso. Quizá el mejor consejo para los analistas es
alcanzar todos los objetivos ya mencionados en la forma más sencilla posible. Claro
está que al incluir tantos controles sobre los errores las personas puedan tener
dificultades al emplear el sistema. En otras palabras. el control de los errores puede
obstruir la tarea. El sistema mejor diseñado se ajusta a las personas que lo utilizarán
y al mismo tiempo, proporcionarán métodos para el control de los errores. La
simplicidad funciona y es aceptada por los usuarios. En contraste, cuesta trabajo que 18
los usuarios acepten diseños para la entrada que sean complejos o confusos, y no
existe ninguna garantía para el éxito al instalar un sistema complejo. En
consecuencia, es aconsejable evitar la complejidad cuando hay opciones más
sencillas.
• Validación de la entrada. Los diseños de las entradas tienen como finalidad reducir
la posibilidad de cometer errores o equivocaciones durante la entrada de datos. Sin
embargo, siempre debe suponer que se presentarán errores. Estos deben detectarse
durante la entrada y corregirse antes de guardar los datos o procesarlos. Es mucho
más difícil corregir datos equivocados después de almacenarlos que antes de
hacerlo. De hecho, los datos equivocados se olvidan con frecuencia hasta que
alguien utilice un reporte basado en esos datos y cuestiona su exactitud y validez.
Los analistas de sistemas deciden los siguientes detalles del diseño de entradas.
1. Qué datos ingresan al sistema.

2. Qué medios utilizar.
3. La forma en que se deben disponer o codificar los datos.
4. El diálogo que servirá de guía a los usuarios para dar entrada a los datos.
5. Validación necesaria de datos y transacciones para detectar errores.
6. Métodos para llevar a cabo la validación de las entradas y los pasos a seguir
cuando se presentan errores.
Las decisiones de diseño para el manejo de entradas, especifican la forma en que serán
aceptados los datos para su procesamiento por computadora. Los analistas deciden si los
datos serán proporcionados directamente, quizá a través de una estación de trabajo, o por
el uso de documentos, como talones de venta, cheques bancarios o facturas, donde los
datos a su vez son transferidos hacia la computadora para su procesamiento.
19
DISEÑO DE SISTEMAS DE ARCHIVOS:
Los sistemas de información en las empresas están orientados hacia el uso de archivos y
bases de datos. Los datos se acumulan en archivos que son procesados o mantenidos
por el sistema. Las bases de datos acumulan los datos de las transacciones y otros tipos
de archivos, y están diseñadas para compartir los datos para distintas aplicaciones. Es
importante determinar su contenido y elegir un método para organizar los datos. Al
mismo tiempo, si las aplicaciones propuestas utilizaran los recursos de la base de datos,
el analista debe desarrollar los medios para interactuar con la misma.
Las bases de datos permiten compartir los datos entre distintas aplicaciones. Además de
la responsabilidad de diseñar archivos, determinar sus contenidos y elegir los métodos
apropiados para organizar los datos, los analistas deben diseñar los medios de
interacción con las bases de datos de la organización. En la mayoría de los casos, las
bases de datos ya estarán disponibles y manejadas por el personal de administración de
ésta.
Cuando se diseña un sistema de información para el procesamiento de transacciones, a

menudo el centro de atención es una entidad. Cuando los analistas y usuarios adquieren
experiencia con el sistema de información y surgen nuevos requerimientos de la
aplicación, la atención cambia: de ser capaz de recuperar un registro específico, a
desarrollar la capacidad de relacionar los registros sobre distintas entidades. Es probable
que cambien los requerimientos cuando las empresas quieren más información para las
solicitudes de procesamiento.
El diseño de archivos incluye decisiones con respecto a la naturaleza y contenido del

propio archivo, como si se fuera a emplear para guardar detalles de las transacciones,
datos de tipo histórico o información de referencia. Entre las decisiones que se toman
durante el diseño de archivos, se encuentran las siguientes:
• Los datos deben incluirse en el formato de los registros contenidos en el archivo.

• La longitud de cada registro, con base en las características de los datos que
contiene.
20
• La secuencia a disposición de los registros dentro del archivo (la estructura de

almacenamiento que puede ser secuencial, indexada o relativa).
No todos los nuevos sistemas de información requieren del diseño de todos los archivos
utilizados por la aplicación. Por ejemplo, es probable que ya existan archivos maestros
porque éstos son utilizados por otras aplicaciones existentes.
TERMINOLOGÍA BÁSICA DE ARCHIVOS:
DATOS: Los elementos individuales de los archivos se llaman datos, también conocidos
como campos. Cada dato se identifica por su nombre y tiene un valor específico asociado
a él.
REGISTRO: Un registro es el conjunto completo de datos relacionados pertenecientes a

una entrada.
BASES DE DATOS: Una base de datos es una colección integrada de datos

almacenados en distintos tipos de registros, de forma que sean accesibles para múltiples
aplicaciones.
La interrelación de los registros se obtiene de las relaciones entre los datos, no de su

lugar de almacenamiento físico. Los registros para distintas entidades se almacenan
comúnmente en una base de datos (mientras que los archivos almacenan registros para
una única entidad). Por ejemplo, en una base de datos de una universidad, se
interrelacionan los registros de los estudiantes, cursos y profesores en la misma base de
datos.
Las bases de datos no eliminan la necesidad de archivos en un sistema de información.

Los distintos tipos de archivos siguen siendo necesarios para capturar los detalles de los
eventos y actividades de la empresa, para preparar reportes o almacenar datos que no
están en la base de datos.
El uso de los diagramas de estructuras de datos requiere que el analista haga preguntas
importantes acerca de la entidad a describir:
21
¿Cuáles son los campos que identificarán de manera única una ocurrencia de la
entidad?
¿Por qué medios se accesará la información acerca de la entidad?
¿Cuáles otros datos describen los atributos de la entidad?
DISEÑO DE ESPECIFICACIONES PARA PROGRAMAS:

(Diseñar los programas de aplicación):
Las especificaciones para programas son por sí mismas un diseño. Ellas describen cómo
transformar las especificaciones de diseño del sistema (Salidas, entradas, archivos,
procesamiento y otras) en software de computadora.
El diseño de software de computadora es importante asegurarse que:
• Los programas producidos lleven a cabo todas las tareas y lo hagan en la forma
establecida.
• La estructuración del software en módulos permita su prueba y validación para
determinar si los procedimientos son correctos.
• Las modificaciones futuras se puedan realizar en forma eficiente y con un mínimo
de interrupción en el diseño del sistema.
Un sistema será diseñado sólo una vez, pero será usado repetidamente y es muy
probable que evolucione en la medida que cambien las necesidades de los usuarios.
Estas observaciones añaden más importancia al diseño de software.
Muchos sistemas de información, ya sea implantados en sistemas de cómputo grandes o

pequeños, interactúan con las bases de datos que abarcan varias aplicaciones. Dada la
importancia que tienen las bases de datos en muchos sistemas, su diseño es establecido
y vigilado por un experto en el diseño de sistemas que tiene la responsabilidad de
desarrollar y mantener la base de datos.
22
El analista proporciona:
1. Los datos que son necesarios de la base de datos.

2. Las acciones que tendrán efecto sobre la propia base (por ejemplo, la
recuperación de datos, cambios en los valores de los datos o el ingreso de nuevos
datos en la base).
En algunas organizaciones existe una separación entre las responsabilidades del

programador y las que tiene el analista. En otras, tanto los programadores como analistas
comparten las responsabilidades.
DISEÑO DE PROCEDIMIENTOS:
(Diseñar el sistema de procesamiento de datos)
Los procedimientos especifican qué tareas deben efectuarse al utilizar en sistema y

quiénes son los responsables de llevarlas a cabo. Entre los procedimientos importantes
se encuentran:
• Procedimientos para entrada de datos. Métodos para la captura de datos de las

transacciones y su ingreso en el sistema de información.
• Procedimientos durante la ejecución. Pasos y acciones emprendidos por los
operadores del sistema y, en ciertos casos, por los usuarios finales que
interactúan con el sistema para alcanzar los resultados deseados.
• Procedimientos para el manejo de errores. Acciones a seguir cuando se presentan
resultados inesperados.
• Procedimientos de seguridad y respaldo. Acciones para proteger al sistema y sus
recursos contra posibles daños.
DISEÑO DE CONTROLES
Los analistas de sistemas también deben anticipar los errores que se cometerán al
ingresar los datos en el sistema o al solicitar la ejecución de ciertas funciones. Algunos
errores no tienen importancia ni consecuencias, pero otros pueden ser tan serios que
ocasionarían la eliminación de datos o el uso inapropiado del sistema. Un buen diseño de 23
sistema de información ofrecerá los medios para detectar y manejar el error, los controles
proporcionan medios para asegurar que solo los usuarios autorizados tengan acceso al
sistema:
1. Garantizar que las transacciones son aceptables.

2. Validar los datos para comprobar su exactitud.
3. Determinar si se han omitido datos que son necesarios.
¿QUÉ ES UNA ARQUITECTURA DE SISTEMAS DE INFORMACIÓN?
Se define arquitectura como un diseño estructural integrado de un sistema, donde sus

elementos y definiciones dependen de los requerimientos proporcionados. El concepto de
“arquitectura” es ampliamente usado en el contexto de la construcción de computadoras.
Cuando se aplica a los sistemas de información asumimos que una arquitectura es un
plano abstracto que incluye los diseños de procesos de un sistema, basado en principios
de diseño y dentro de un marco metodológico.
Una de las principales características de las organizaciones de hoy en día, es que están
en constante cambio, y no se puede prever cosas a largo plazo. Para adaptarse a estos
constantes cambios, las organizaciones deben evolucionar e integrar la empresa (quebrar
las barreras organizacionales y mejorar la interoperabilidad para crear sinergia dentro de
la empresa y así operar más eficientemente), igualmente desarrollar una disciplina que
organice todo el conocimiento que se necesita para identificar las necesidades que
cambian en la empresa, a esa disciplina se le llama Ingeniería empresarial que es
simplemente una colección de herramientas y métodos con los cuales se puede diseñar y
continuamente mantener un estado integral de la empresa.
Las entidades que deben participar dentro de la Arquitectura del sistema de información
son la organización y sus productos. Ambas deben ser consideradas para los propósitos
del diseño del sistema de información, implementación y operación.
24
MODELO DE DATOS CONCEPTUAL:
Un modelo conceptual de datos es una perspectiva visual de alto nivel sobre un tema de
importancia para el negocio. Contiene sólo las entidades empresariales básicas y críticas
dentro de un dominio y función dada, con una descripción de cada entidad y las
relaciones entre las entidades. Los modelos de datos conceptuales definen la semántica
(sustantivos y verbos) del vocabulario esencial del negocio. Las áreas temáticas de
modelo conceptual de datos siempre son representativas de los datos asociados a un
proceso de negocio o función de la aplicación. Un modelo conceptual de datos es
independiente de la tecnología (base de datos, archivos, etc.) y del contexto de uso (si la
entidad está en un sistema de facturación o un almacén de datos).
Incluido en un modelo conceptual de datos hay un glosario que define cada objeto dentro
del modelo conceptual de datos. Las definiciones incluyen términos de negocio, términos
de relación, sinónimos de entidad y las clasificaciones de seguridad.
Para crear un modelo conceptual de datos, comenzar con un área temática de las áreas
temáticas del modelo. Determinar qué objetos están incluidos dentro de ésa área y cómo
se relacionan entre sí. Por ejemplo, el área temática Cliente puede contener las siguientes
entidades: Titular de la Cuenta, Sub Cuenta, Preferencia del Contacto e Información de
Contacto. Un Titular de la Cuenta se refiere a una o más Subcuentas.
25
Ejemplo de un Modelo Conceptual
Para mantener un modelo conceptual de datos, es necesario adoptar un proceso para

revisar los cambios propuestos al sistema de producción contra el modelo conceptual.
Si un proyecto implicará cambios, crear un modelo conceptual intermedio y realizar los
cambios allí. Copie los cambios de modelo a la versión del modelo conceptual de
producción del modelo conceptual cuando implemente cambios en el sistema de
producción como parte del Proceso de liberación, para asegurar que el modelo mantiene
en sintonía con la realidad actual.
Entidades: Una entidad de negocio es algo de interés para la organización, un objeto o

un evento. Una entidad de datos es una colección de datos acerca de algo que el
negocio considera importante y digno de captura. Una entidad es un sustantivo.
26
Un quién: Persona, organización, papel, empleado, cliente, proveedor,

estudiante, partido, departamento, organismo regulador, competidor,
Socio, filial, equipo, familia, hogar.
Un qué: El producto, servicio, recursos, materia prima, producto terminado
Un cuándo: Evento, periodo fiscal.
Un dónde: Lugar, dirección, web, nodo de red
Un por qué: Política, norma, solicitud, queja, el retomo, la indagación.
Una forma: Mecanismo, herramienta, documento, factura, contrato, Convenio,
estándar, cuenta.
Una Entidad es un elemento del mundo real, sobre el cual se desea almacenar
información en la base de datos.
Ejemplos de Nombres de Entidades: Alumno, Empleado, Artículo.

• Una casa: Aunque sea exactamente igual a otra, aún se diferenciará en su
dirección.
• Un automóvil: Aunque sean de la misma marca, el mismo modelo, tendrán

atributos diferentes como el número del motor.
Una entidad puede aparecer en un modelo de datos conceptual o lógico. Las entidades
de negocio conceptuales describen las cosas sobre las que recogemos datos, tales como
Clientes, Productos y Cuenta. Las entidades de datos lógicos siguen las reglas de la
normalización y la abstracción y por lo tanto el concepto de Cliente se convierte en varios
componentes, como Cliente, Tipo de Cliente y la Preferencia del Cliente.
Los modelos de datos físicos definen tablas que pueden o no pueden relacionarse
directamente a las entidades en un modelo lógico comparable.
Una entidad está formada por ocurrencias o instancias, que son los valores concretos que
toman los atributos de la entidad en un momento determinado.
27
Una entidad presenta las siguientes propiedades:
✓ Posee existencia propia, ya sea física o conceptual.

✓ Se distingue del resto de los objetos.
✓ Resultan de interés algunas de sus propiedades.
✓ Formada por un conjunto de ocurrencias, que presentan las mismas
propiedades.
Una ocurrencia de entidad es la creación de una instancia de una entidad de negocio en

particular. La entidad Cliente puede tener instancias con nombre Juan, José, Lina y así
sucesivamente. La entidad Cuenta puede tener instancias de la cuenta corriente de Juan,
cuenta de ahorros de José, cuenta Corriente de Lina y así sucesivamente.
Una entidad está formada por ocurrencias o instancias, que son los valores concretos que
toman los atributos de la entidad en un momento determinado.
Las entidades pueden ser entidades independientes o dependientes. Una entidad

independiente (o entidad central) no depende de ninguna otra entidad para su existencia.
Cada ocurrencia de una entidad independiente existe sin hacer referencia a ninguna otra
entidad en el modelo de datos. Una entidad dependiente depende de una o más
entidades para su existencia.
Hay tres tipos principales de entidades dependientes:
Una entidad que depende de una sola

Entidad por Atributo/Característica entidad padre, tal como Beneficiario del
Empleado que depende de Empleado.
Una entidad que depende de dos o más
entidades, tales como Registro, que
Entidad Asociativa/Mapeo:
depende de un Estudiante en particular y
de un Curso.
Una entidad que es "una especie de" otra
Entidad de Categoría entidad. Subtipos y supertipos son
ejemplos de generalización y herencia.
Subtipo / supertipo Una entidad de tipo Super es una
generalización de todos sus subtipos y 28
cada subtipo hereda los atributos de su

supertipo. Por ejemplo, una entidad
Supertipo Individuo tiene enlaces los
susbtipos a Persona y Organización. Los
subtipos pueden ser solapados (no
exclusivos)
o no solapados (exclusivos). Una instancia
de la entidad subtipo no solapada tique
que ser un sub-tipo u otro, pero no ambos.
Relaciones: Las reglas de negocio definen restricciones sobre lo que se puede y no

puede hacer. Las Reglas de Negocio se dividen en dos categorías principales:
• Reglas de datos restringen cómo los datos se relacionan con otros datos.
Por ejemplo, "los estudiantes de primer año pueden inscribirse por un máximo de
18 créditos por semestre." Los modelos de datos se enfocan de reglas de negocio.
• Las reglas de acción son instrucciones sobre qué hacer cuando los Elementos de
datos contienen ciertos valores. Las reglas de acción son difíciles de definir en un
modelo de datos. Las reglas de negocio para la calidad de los datos son reglas de
acción y las aplicaciones las implementan como edición y validación de entrada de
datos.
Los modelos de datos expresan dos tipos principales de reglas de datos:

• Las reglas de cardinalidad definen la cantidad de instancias de la entidad que
puede participar en una relación entre dos entidades. Por ejemplo, "Cada empresa
puede emplear a muchas personas."
• Las reglas de integridad referencial garantizan valores válidos. Por Ejemplo, "Una
persona puede existir sin trabajar para una empresa, pero una empresa no puede
existir a menos que una persona este empleada por la empresa."
La cardinalidad y la integridad de las reglas de negocio son las Relaciones entre las
entidades de los modelos de datos. 29
Si combinamos los ejemplos anteriores para expresar la relación entre la empresa y la

persona obtenemos lo siguiente:
• Cada persona puede trabajar para cero a muchas empresas.

• Cada empresa debe emplear de una o muchas personas.
Las etiquetas de la relación son frases verbales que describen las reglas de negocio en
cada sentido entre dos entidades, junto con las palabras que describen los "muchos" los
aspectos de cada relación (cardinalidad) y el lado "cero o uno" de cada relación
(integridad referencial).
Una relación entre dos entidades puede ser uno de los tres tipos de Relaciones:
Relación de 1 a 1 Es cuando la Entidad padre puede tener solamente una Entidad

(Uno a Uno) Hijo.
Cuando la Entidad padre puede tener una o más entidades
secundarias.
Las relaciones uno-a-muchos son las relaciones más comunes.
En algunas relaciones uno-a-muchos, una entidad niña debe

Relación de 1 a N
tener un padre, pero en otras relaciones, la relación con uno de
(Uno a muchos)
los padres es opcional.
En algunas relaciones uno-a-muchos, una entidad padre debe

tener al menos una entidad niña, mientras que en otras
relaciones uno-a-muchos, la relación a cualquier niño es
opcional.
Relación de N a N. Una instancia de cada Entidad puede estar asociada con cero a
(Muchos a Muchos) muchas instancias de la otra entidad o viceversa.
Instancias de una entidad a otras instancias de la misma

entidad.
Relación recursiva
Relaciones recursivas pueden ser de uno a uno, uno-a-muchos
o muchos- a muchos.
30
Relación 1 a 1 (Uno a Uno)

En una relación de uno a uno, un registro de una tabla se asocia a uno y solo un registro
de otra tabla. Por ejemplo, en una base de datos de un centro educativo, cada alumno
tiene solamente un ID de estudiante, y cada ID de estudiante se asigna solo a una
persona.
En este ejemplo, el campo de clave de cada tabla, ID de estudiante, se ha diseñado para

contener valores exclusivos. En la tabla Alumnos, el campo ID de estudiante es la clave
principal; en la tabla Información de contacto, el campo ID de estudiante es una clave
externa.
Esta relación devuelve registros relacionados cuando el valor del campo ID de estudiante
de la tabla Información de contacto es el mismo que el del campo ID de estudiante de la
tabla Alumnos.
Relación 1 a N (Uno a muchos)

En una relación de uno a muchos, un registro de una tabla se puede asociar a uno o
varios registros de otra tabla. Por ejemplo, cada cliente puede tener varios pedidos de
ventas.
31
En este ejemplo, el campo de clave principal de la tabla Clientes, ID de cliente, se ha

diseñado para contener valores exclusivos. El campo de clave externa de la tabla
Pedidos, ID de cliente, se ha diseñado para permitir varias instancias del mismo valor.
Esta relación devuelve registros relacionados cuando el valor del campo ID de cliente de
la tabla Pedidos es el mismo que el valor del campo ID de cliente de la tabla Clientes.
Relación N a N (Muchos a Muchos)
Una relación de muchos a muchos se produce cuando varios registros de una tabla se
asocian a varios registros de otra tabla. Por ejemplo, existe una relación de muchos a
muchos entre los clientes y los productos: los clientes pueden comprar varios productos y
los productos pueden ser comprados por muchos clientes.
Por lo general, los sistemas de bases de datos relacionales no permiten implementar una
relación directa de muchos a muchos entre dos tablas. Tenga en cuenta el ejemplo de
seguimiento de facturas. Si había muchas facturas con el mismo número de factura y uno
de sus clientes preguntó acerca de ese número de factura, no sabría a qué número se
refería. Este es el motivo por el que se debe asignar un valor exclusivo a cada factura.
32
Para evitar este problema, puede dividir la relación de muchos a muchos en dos
relaciones de uno a muchos mediante el uso de una tercera tabla denominada tabla de
unión. Cada registro de una tabla de unión incluye un campo de coincidencia que contiene
el valor de las claves principales de las dos tablas que se unen. (En la tabla de unión,
estos campos de coincidencia son claves externas). Estos campos de clave externa se
rellenan con datos, ya que los registros de la tabla de unión se crean desde cualquiera de
las tablas que se unen.
Un ejemplo típico de una relación de muchos a muchos es aquella entre los estudiantes y
las clases.
Un estudiante puede matricularse en muchas clases y una clase puede incluir muchos
estudiantes.
En el siguiente ejemplo, se incluye una tabla Alumnos, que contiene un registro para cada
estudiante, y una tabla Clases, que contiene un registro para cada clase. Una tabla de
unión, Matrículas, crea una relación de uno a muchos, una entre cada una de las dos
tablas.
33
Relación Recursiva
Una clase particular de relación que se puede hallar es aquella que refiere a la relación de
una entidad consigo misma (relación recursiva). Indica que un empleado debe ser
subalterno de otro empleado obligatoriamente y que un empleado puede ser jefe de uno o
más empleados.
¿QUÉ ES LA NORMALIZACIÓN?
Es el proceso de organizar de manera eficiente los datos dentro de una base de datos.
Esto incluye la creación de tablas y el establecimiento de relaciones entre ellas según
reglas pre-diseñadas tanto para proteger los datos y la base de datos, como para hacer
más flexible al eliminar la redundancia y dependencia incoherente.
La normalización es el proceso de aplicación de normas para organizar la complejidad del
negocio en estructuras de datos estables. Se requiere una comprensión más profunda de
cada elemento de datos, para ver cada elemento de datos en relación a cualquier otro
elemento de datos. El objetivo básico de la normalización es mantener a cada elemento
de datos en un solo lugar.
La normalización también se puede entender como el proceso mediante el cual se
transforman datos complejos a un conjunto de estructuras de datos más pequeñas, que
además de ser más simples y más estables, son más fáciles de mantener.
Existen algunas reglas para la normalización de bases de datos. Cada regla se denomina
"forma normal". Si dentro de la base de datos se observa la primera regla se dice que está
en "primera forma normal". Si las tres primeras reglas se observan, la base de datos se
considera en "tercera forma normal". Aunque es posible tener otros niveles de
34
normalización, la tercera forma normal es considerada el más alto nivel necesario para la
mayoría de aplicaciones.
La regla de normalización ordena en niveles, donde en cada nivel se aplicará más
granularidad y especificidad en busca de las claves primarias y externas correctas. Cada
nivel consta de una forma normal por separado y cada nivel sucesivo incluye los niveles
anteriores. Los niveles de normalización incluyen:
Asegura que cada entidad tenga una clave principal válida,

Primera Forma cada elemento de datos depende de la clave principal y elimina
Normal(1FN) grupos de repetición y garantiza que cada elemento de datos es
atómica (no multi-valorado).
Asegura que cada entidad tenga una clave principal mínima y
Segunda Forma Normal que cada elemento de datos dependa de la clave primaria
(2FN) completa.
Asegura que cada entidad no tenga claves primarias ocultas y

Tercera Forma Normal que cada elemento de datos no dependa de elemento de datos
(3FN) fuera de la clave ("la clave, la clave de todo y nada más que la
clave").
Resuelve la superposición de claves candidatas compuestas.
Una clave candidata es una clave primaria o bien una clave
La forma normal Boyce / alternativa. 'Compuesto' significa más de uno (por ejemplo, dos
Codd (BCNF) elementos de datos en la clave principal de una entidad) y
'superposición' significa que se hay reglas de negocio ocultas
entre las claves.
Resuelve todas las relaciones muchos-a muchos (y más allá)
La cuarta forma normal en pares hasta que no puedan desglosarse en partes más
(4NF) pequeñas.
Resuelve dependencias entre las entidades en pares básicos y

La quinta forma normal todas las uniones de dependencia utilizan partes de las claves
(5NF) primarias.
Añade objetos temporales a las claves principales, con el fin de

La sexta forma normal permitir la presentación de informes y análisis histórico sobre
(6NF) los plazos.
35
MODELO LÓGICO
Atributos: Los atributos son las características por medio de los cuales se puede
describir una entidad. Por ejemplo, de la entidad alumno podemos asignarle atributos
como: nombre, apellido, dirección, teléfono, y su campo llave que puede ser: número de
cedula, número de matrícula, o un código cualquiera.
La elección de los atributos de una entidad depende del uso que se le dará a la base de
datos. El alumno puede tener una "religión", pero si no interesa, no es necesario
almacenarla en un atributo de la base de datos.
Un atributo es una propiedad de una entidad; un tipo de dato importante para la empresa
cuyos valores ayudan a identificar o describir una instancia de entidad. Por ejemplo, el
atributo Apellido del Estudiante describe el apellido de cada estudiante.
Los atributos se traducen en un modelo de datos físico a un campo de un archivo o una
columna de una tabla de base de datos. Los atributos utilizan nombres de negocio,
mientras que los campos y columnas utilizan nombres técnicos que con frecuencia
incluyen abreviaturas técnicas. En un modelo de datos lógicos, las entidades de negocio
representan los nombres esenciales en el vocabulario de la organización y los atributos
representan adjetivos.
36
Dominios: El conjunto completo de todos los valores posibles para un atributo es un

dominio. Un atributo no puede contener valores fuera de su dominio asignado. Algunos
dominios tienen un número limitado de valores definidos específicos, o límites mínimos o
máximos para los números. Las reglas de negocio también pueden restringir los dominios.
Los atributos a menudo comparten el mismo dominio. Por ejemplo, una fecha de
contratación del empleado y una fecha de la orden de compra deben ser:
• Una fecha del calendario válido (por ejemplo, no el 31 de febrero).
• Una fecha que cae en un día laborable.
• Una fecha que no cae en un día festivo.
Clave: En cualquier base de datos los registros incluidos en sus diferentes tablas deben
estar perfectamente identificados y de seto se encargan las claves o llaves. Trasladando
este concepto a la vida real, cada ciudadano tiene un número de identificación, puede
haber dos personas con el mismo nombre e incluso apellidos iguales, pero ambos se
diferenciarán por su número de identificación, que es único.
Los atributos asignados a las entidades pueden ser o no claves. Un elemento de datos
que es clave ayuda a identificar una instancia única de una entidad de todas los demás ya
sea totalmente (por sí mismo) o parcialmente (en combinación con otros elementos
clave). Los elementos de datos que no son clave describen la instancia de la entidad, pero
no ayudan a identificarlo de forma única.
Una llave (o clave candidata) representa uno o más atributos cuyos valores identifican de
forma exclusiva una instancia de la entidad. Una clave compuesta es una clave que
contiene dos o más atributos. Una de estas claves candidatas se convierte en la clave
principal. Sólo debe haber una clave primaria. Todas las demás claves candidatas se
vuelven claves alternativas.
Para evitar el uso de claves primarias compuestas, o atributos clave con valores que
cambian con el tiempo, se utiliza una clave sustituta. Una clave sustituta contiene un valor
generado aleatoriamente asignado a una instancia de entidad. 'Subrogado' significa
'sustituto'. Utilice una clave sustituta cuando exista un elemento de datos únicos o un 37
conjunto de elementos de datos dentro de la entidad. Otros nombres para las claves
sustitutas son claves anónimas o claves no inteligentes. Tenga en cuenta que
simplemente tener una clave generada por un número secuencial en realidad todavía
tiene algo de inteligencia. Una persona puede decir en qué orden las filas se insertan en
la tabla por la secuencia, similar a un número de fila. Las claves subrogadas son
aleatorias, no secuenciales.
Una clave foránea es un atributo proporciona un enlace a otra entidad. En pocas palabras,
una clave foránea es un atributo aparece en ambas entidades en una relación e identifica
parcialmente o totalmente una o ambas entidades. Cuando existe una relación de uno a
varios entre dos entidades, la entidad en el lado secundario de la relación hereda los
atributos de clave primaria de la entidad en el lado de los padres de la relación. La clave
foránea permite la navegación entre las estructuras de datos.
Una relación de identificación se produce cuando el atributo de la clave foránea de una

entidad padre aparece como parte de la clave primaria compuesta de una entidad hijo.
Una relación sin identificación se produce cuando la clave foránea de una entidad padre
no es un atributo clave que describe la entidad hijo.
MODELO FÍSICO
38
El diseño del modelo de datos físico incluye tomar decisiones sobre:
• El nombre técnico de cada tabla y columna (bases de datos relacionales), o

archivo y campo (bases de datos no relacionales), o esquema y elemento
(bases de datos XML).
• El dominio lógico, tipo de datos físico, longitud y anulabilidad de cada columna
o campo.
• Cualquier valor predeterminado para las columnas o campos, especialmente
para las restricciones NOT NULL.
• Las claves primarias y alternativas únicas e índices, incluyendo la forma de
asignar las claves.
• Implementación de pequeños conjuntos de valores de datos de referencia en el
modelo lógico, tales como a) tablas separadas de código, b) una tabla de
códigos principal compartida, o c) simplemente como reglas ó restricciones.
• Implementación entidades del modelo lógico de supertipo / subtipo en el diseño
de base de datos físicos donde los atributos de las entidades subtipo "se
fusionaron en una tabla que representa la entidad supertipo como columnas
anulables, o colapsando los atributos de la entidad supertipo en una tabla para
cada subtipo.
Diseño de Datos Detallado

El diseño detallado incluye especificaciones de implementación de base de datos. Un
diseño de base de datos física puede tomar ventaja de las funciones y capacidades de un
sistema de gestión de base de datos específica, que puede o no estar incluido en el
modelo de datos en sí únicas.
Colabore o no el DBA en el modelado de datos físicos, el DBA es el principal responsable

de diseño de base de datos detallada, incluyendo:
• Asegurar que el diseño cumpla con los requisitos de integridad de datos.

• Determinar la estructura física más adecuada para albergar y organizar los datos,
ya sea relacional u otro tipo de DBMS, archivos, cubos OLAP, XML, etc. 39
• Determinar las necesidades de recursos de bases de datos, como el tamaño y la

ubicación del servidor, los requisitos de espacio en disco, los requisitos de CPU y
memoria y requisitos de la red.
• Crear las especificaciones de diseño detalladas para las estructuras de datos,
tales como tablas relacionales de bases de datos, índices, vistas, cubos de datos
OLAP, esquemas XML, etc.
• Asegurar que se cumplan los requerimientos de rendimiento, incluidos los lotes y
los requisitos de tiempo de respuesta en línea para consultas, inserciones,
actualizaciones y eliminaciones.Diseñar el esquema de copia de seguridad,
recuperación, archivo y Depuración, lo que garantiza que se cumplan los
requisitos de disponibilidad y las operaciones de mantenimiento de bases de datos
que se pueden realizar dentro de la ventana (s) de tiempo disponible.
• Implementar la seguridad de datos, incluyendo la autenticación, cifrado de
necesidades, las funciones de aplicación y el acceso a datos y actualizar los
permisos que deberían ser asignados. La regla general nunca es conceder
permisos en objetos de base de datos a usuarios individuales, sólo a los roles. Los
usuarios se pueden mover dentro y fuera de los roles según sea necesario; esto
reduce en gran medida el mantenimiento y mejora de la seguridad de los datos.
• Determinar esquemas de particionamiento y hash, donde sea apropiado.
• Exigir la revisión del código SQL para asegurarse de que el código cumple con los
estándares de codificación y funcionará de manera eficiente.
DISEÑO DE BASES DE DATOS FÍSICA

Al diseñar una base de datos es importante tener en cuenta la arquitectura como la
tecnología y tener presente varias consideraciones:
• Con qué frecuencia los datos se actualizan.

• La organización natural de los datos.
• ¿Cómo se visualizan los datos y como se utilizan?
• La elección de la tecnología de aplicación (por ejemplo, relacionales, XML,
OLAP, o tecnología de objetos) puede regirse por muchos factores diferentes,
incluyendo el tiempo que necesita que se mantengan los datos, si deben ser 40
integrado con otros datos o se pasan a través del sistema o límites de

aplicación y de los requisitos de seguridad de los datos, la integridad, la
capacidad de recuperación, la accesibilidad y la reutilización.
Otros factores que pueden influir en el diseño de bases de datos física:
• Compra de licencias, servidor de bases de datos y herramientas de acceso del

lado del cliente.
• Requisitos de auditoria y privacidad.
• Requisitos de compatibilidad de la base de datos.
• Acuerdos de nivel de servicio.
Es importante que los diseñadores de bases de datos encuentren respuestas a las

siguientes preguntas al momento de diseñar.
• ¿Cuáles son los requisitos de rendimiento?

• ¿Cuál es el tiempo máximo permitido para una consulta para devolver los
resultados, o para un conjunto importante de cambios que se produzcan?
• ¿Cuáles son los requisitos de disponibilidad de la base de datos?
• ¿Cuáles es la ventana (s) de tiempo para la realización de operaciones de base
de datos?
• ¿Con qué frecuencia se deben realizar copias de seguridad de bases de datos y
copias de seguridad del registro de transacciones (es decir, ¿cuál es el período
más largo de tiempo, que podemos correr el riesgo de no recuperar de los
datos)?
• ¿Cuál es el tamaño esperado de la base de datos?
• ¿Cuál es la tasa esperada de crecimiento de los datos?
• ¿En qué momento los datos antiguos o no utilizados pueden ser archivados o
eliminados?
• ¿Cuántos usuarios concurrentes se prevé?
41
• ¿Qué tipo de virtualización de datos son necesarios para soportar los

requerimientos de aplicación, de manera tal que la base de datos no perjudique
a la aplicación?
• ¿Las demás aplicaciones necesitarán los datos? Si es así, ¿qué datos y cómo?
• ¿Los usuarios esperan poder hacer consultas ad-hoc y sacar reportes? Si es
así, ¿cómo y con qué herramientas?
• ¿Qué, si existe, procesos de negocio o aplicación necesita implementar la base
de datos? (por ejemplo, el código de disparador que hace comprobación de
integridad entre bases de datos y la actualización, clases de la aplicación de
base de datos encapsulados en procedimientos o funciones, vistas de bases de
datos que proporcionan recombinación de tablas para la facilidad el uso o de
propósitos de seguridad, etc.).
• ¿Existen consideraciones sobre las aplicaciones o de los desarrolladores con
respecto a base de datos, o el proceso de desarrollo de base de datos, que
deben abordarse?
• ¿El código de la aplicación eficiente? ¿Puede un cambio de código aliviar un
problema de rendimiento?
E. EJEMPLOS DE DISEÑO DE SISTEMAS

A) Esquema de las interacciones entre los sistemas Usuario Biblioteca:
42
B) La Biblioteca como sistema:
43
C) Diagrama de proceso de ejemplares adicionales (Componente de la

Catalogación):
44
D) Organigrama administrativo del sistema en estudio:
REFERENCIAS BIBLIOGRAFÍCAS Y WEB
Kendall, K., Kendall, J. ANALISIS Y DISEÑO DE SISTEMAS. Prentice Hall.

James A. Senn. Análisis y Diseño de Sistemas de Información, Segunda Edición Mc.
Graw-Hill
45
Programa Ciencia de la Información y la Documentación,
Bibliotecología y Archivística
Tel: (57) 6 735 9300 Ext

Carrera 15 Calle 12 Norte
Armenia, Quindío – Colombia

Desarrollo de La Temática Unidad 1 - Conceptos Generales Del Diseño de Sistemas

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Desarrollo de La Temática Unidad 1 - Conceptos Generales Del Diseño de Sistemas

Cargado por

Copyright:

Formatos disponibles

DESARROLLO DE CONTENIDOS

Programa Ciencia de la Información y la Documentación,

a) ¿Qué es Diseño de Sistemas?

El diseño de sistemas se refiere a la formulación de especificaciones para el

El diseño de un sistema puede descomponerse en especificaciones físicas y lógicas.

específicos. Proporciona las especificaciones que transforman el diseño lógico abstracto

Cuando el analista esté listo para comenzar a diseñar el nuevo sistema, ya

b) DISEÑO DE UN SISTEMA DE INFORMACIÓN

El diseño de sistemas de información se define como aquellas tareas que se enfocan

La mayoría de nosotros definimos el proceso de diseño de manera demasiado restrictiva,

SISTEMA DE INFORMACIÓN: ANÁLISIS: Proceso de clasificación e

El análisis y diseño de sistemas se refiere al

EL DISEÑO DEL SISTEMA: Es la estrategia de alto nivel para resolver problemas y

La organización global del sistema es lo que se denomina la arquitectura del sistema.

El diseño de un sistema de información produce los elementos que establecen cómo el

El analista debe tener en cuenta dos puntos importantes:

1. Resuelva un problema a la vez. No se confunda al querer resolver muchos problemas

• Examine todos los datos posibles.

Otra consideración en la fase de diseño es el control que se debe ejercer desde el

Las especificaciones de diseño describen las características del sistema, sus

1. Flujos de datos: Movimientos de datos hacía, alrededor y desde el sistema.

Desarrollo del software: A menudo los especialistas de sistemas se refieren a esta

Los programadores de software son también responsables de la documentación del

¿El diseño es una solución?

La conversión de los requerimientos en formas que los satisfagan. El diseño determina el

1. Los recursos de la organización.

C. OBJETIVOS DEL DISEÑO DE SISTEMAS DE INFORMACIÓN

El diseño de sistemas tiene tres objetivos:

Primero, el diseñador de sistemas es responsable de la consideración de otras

Segundo, los diseñadores son responsables por la administración y el control de la

Especificar los Especificaciones detalladas de diseño que describen las

• Efectuar en forma correcta los procedimientos

Fácil de usar. Ingeniería humana favorable: El diseño ergonómico debe

D. ETAPAS BÁSICAS DEL PROCESO DISEÑO

En de la práctica, la aplicación del proceso de diseño es un esfuerzo repetitivo. A medida

I. Definir el objetivo del sistema.

II. Desarrollar un modelo conceptual.

a) Identificar el resultado más importante del sistema.

III. Aplicar restricciones.

a) En base a las restricciones impuestas eliminar los casos extremos de entrada,

IV. Definir las actividades de procesamiento de datos.

V. Formular la proposición del diseño del sistema.

Analizando específicamente las entradas, las salidas y las actividades de procesamiento

• Determinar qué información presentar.

Para llevar a cabo las actividades antes mencionadas, se requieren decisiones

El diseño de la salida de la computadora debe avanzar en una forma organizada y

El termino salida se utiliza para expresar cualquier información, ya sea impresa o

Cuando los analistas diseñan la salida:

• Identifican la salida específica que es necesaria para satisfacer los requerimientos

Un sistema de información debe alcanzar uno o más de los siguientes objetivos:

1. Expresar información relacionada con actividades pasadas, estado actual o

El buen diseño de la salida de los sistemas, no puede ser desarrollado en forma

Aspectos importantes de las Salidas

¿Quiénes Recibirán La Salida?

El usuario, ¿forma o no parte de la organización?, Quizá los usuarios externos tengan

¿Cuántos Detalles Son Necesarios?

¿Cuántos Y Que Tan Frecuente Es La Salida?

¿Qué Método Utilizar?

Las especificaciones de entrada describen la manera en que los datos ingresarán al

El diseño de la entrada consiste en el desarrollo de especificaciones y procedimientos

Controles de la cantidad de entrada.

• Evitar Retrasos. Un retraso en el procesamiento, que es un resultado de las

1. Qué datos ingresan al sistema.