Capitulo 10 Español PDF

Capítulo
10 Desarrollo del Sistema de Base de Datos

Ciclo vital
Objetivos del capítulo
En este capítulo aprenderá:
• Los principales componentes de un sistema de información.
• Las principales etapas del ciclo de vida de desarrollo del sistema de base de datos (DSDLC).
• Las principales fases de diseño de base de datos: diseño conceptual, lógico y físico.
• Los tipos de criterios utilizados para evaluar un DBMS.
• Cómo evaluar y seleccionar un DBMS.
• Los beneficios de Computer-Aided Software Engineering (CASE).
Software ya ha superado el hardware como la clave para el éxito de muchos sistemas computerbased. Por
desgracia, el historial de desarrollo de software no es particularmente impresionante. Las últimas décadas han visto
la proliferación de aplicaciones de software que van desde aplicaciones pequeñas, relativamente simples que
consisten en unas pocas líneas de código para aplicaciones grandes y complejas que consisten de millones de
líneas de código. Muchas de estas aplicaciones han requerido un mantenimiento constante. Este mantenimiento
implicó la corrección de los fallos que habían sido detectados, la implementación de nuevas necesidades de los
usuarios, y modificar el software para ejecutar en plataformas nuevas o mejoradas. El esfuerzo invertido en el
mantenimiento comenzó a absorber recursos a un ritmo alarmante. Como resultado, muchos de los principales
proyectos de software llegaron tarde, por encima del presupuesto, poco fiables y difíciles de mantener, y un mal
desempeño.
crisis del software. Aunque este término fue utilizado por primera vez a finales de 1960, la crisis todavía está con nosotros.
Como resultado, algunos autores se refieren ahora a la crisis del software como el la depresión de software. Como una
indicación de la crisis, un estudio realizado en el Reino Unido por OASIG, un Grupo de Interés Especial se ocupa de los
aspectos de organización de TI, llegó a las siguientes conclusiones acerca de los proyectos de software (OASIG, 1996):
• 80-90% no cumplen con sus objetivos de rendimiento;
• alrededor del 80% se entregan tarde y por encima del presupuesto;
• alrededor de 40% de fracaso o son abandonados;
• por debajo del 40% frente plenamente los requisitos de formación y capacitación;
345
M10_CONN3067_06_SE_C10.indd 345 06/10/14 16:30

346 | Capítulo 10 Base de datos del ciclo de vida de desarrollo del ordenamiento
• menos del 25% integrar adecuadamente los objetivos de la empresa y la tecnología;
• solo el 10-20% cumple con todos sus criterios de éxito.
Hay varias razones principales del fracaso de los proyectos de software, incluyendo:
• falta de una especificación de requisitos completa;
• la falta de una metodología de desarrollo apropiado;

• pobres descomposición de diseño en componentes manejables. Como solución a estos problemas, un
enfoque estructurado para el desarrollo de software se propuso la llama Sistemas de Información del Ciclo
de Vida (MECOVI) o la
Software Development Lifecycle (SDLC). Sin embargo, cuando se desarrolla el software es un sistema de base de
datos del ciclo de vida se refiere más específicamente a como el
Base de datos del ciclo de vida de desarrollo del sistema (DSDLC).
Estructura de este capítulo En la Sección 10.1 describimos brevemente el ciclo de vida de los sistemas de
información y discutir cómo este ciclo de vida se relaciona con el ciclo de vida de desarrollo del sistema de base de datos.
En la Sección 10.2 se presenta una visión general de las etapas del ciclo de vida de desarrollo del sistema de base de
datos. En las Secciones 10.03 a 10.13 que describen cada etapa del ciclo de vida con más detalle. En la sección 10.14 se
discute cómo Software Engineering (CASE) asistido por ordenador pueden proporcionar apoyo para el ciclo de vida de
desarrollo del sistema de base de datos.
10.1 El Ciclo de Vida de los Sistemas de Información
Sistema de Los recursos que permitan la recogida, gestión, control y difusión de la información
informacion en toda la organización.
Desde la década de 1970, los sistemas de bases de datos han sido reemplazando gradualmente a los sistemas basados
en archivos como parte de los sistemas de información de una organización (IS) infraestructura. Al mismo tiempo, ha
habido un creciente reconocimiento de que los datos es un importante recurso empresarial que debe ser tratado con
respeto, como todos los demás recursos de la organización. Esto dio lugar a muchas organizaciones establecer
departamentos enteros o áreas funcionales llamadas Administración de datos (DA) y la administración de bases de datos
(DBA) que son responsables de la gestión y control de los datos corporativos y la base de datos corporativa,
respectivamente.
Un sistema de información basado en computadora incluye una base de datos, software de base de datos, software
de aplicaciones, hardware, y el personal de usar y desarrollar el sistema.
La base de datos es un componente fundamental de un sistema de información, y su desarrollo y su uso
debe ser vista desde la perspectiva de los requisitos más amplios de la organización. Por lo tanto, el ciclo de
vida del sistema de información de una organización está intrínsecamente ligada al ciclo de vida del sistema
de base de datos que lo soporta. Por lo general, las etapas del ciclo de vida de un sistema de información
incluyen: planificación, recopilación y análisis de requisitos, diseño, prototipos, implementación, prueba,
conversión y mantenimiento operativo. En este capítulo se revisan estas etapas
M10_CONN3067_06_SE_C10.indd 346 06/10/14 16:30

10.3 Planificación de la base de datos | 347
desde la perspectiva de desarrollar un sistema de base de datos. Sin embargo, es importante tener en cuenta que el
desarrollo de un sistema de base de datos también debe ser visto desde la perspectiva más amplia de desarrollo de un
componente del sistema de información en toda la organización más grande.
A lo largo de este capítulo se utilizan los términos “área funcional” y “área de aplicación” para referirse a las
actividades empresariales particulares dentro de una organización como la comercialización, personal y control de
existencias.
10.2 El Ciclo de Vida de Desarrollo del Sistema de Base de Datos

Como un sistema de base de datos es un componente fundamental del sistema de información de toda la organización más
grande, el ciclo de vida de desarrollo del sistema de base de datos está asociada intrínsecamente con el ciclo de vida del
sistema de información. Las etapas de la base de datos del ciclo de vida de desarrollo del sistema se muestran en la figura
10.1. Debajo del nombre de cada etapa es la sección en este capítulo que describe esa etapa.
Es importante reconocer que las etapas del ciclo de vida de desarrollo de sistemas de bases de datos no son
estrictamente secuencial, sino que implican una cierta cantidad de repetición de las etapas anteriores a través circuitos de
retroalimentacion. Por ejemplo, los problemas encontrados durante el diseño de la base de datos pueden hacer necesaria la
recogida y análisis de requisitos adicionales. Como hay bucles de retroalimentación entre la mayoría de las etapas, sólo
mostramos algunas de las más obvias en la figura 10.1. Un resumen de las principales actividades asociadas con cada etapa
de la base de datos del ciclo de vida de desarrollo del sistema se describe en la Tabla 10.1.
Para los sistemas de bases de datos pequeñas, con un pequeño número de usuarios, el ciclo de vida no tiene que ser
muy complejo. Sin embargo, al diseñar un medio de sistemas de bases de datos grandes con decenas de miles de
usuarios, utilizando cientos de consultas y programas de aplicación, el ciclo de vida puede llegar a ser extremadamente
complejo. A lo largo de este capítulo, nos concentramos en las actividades asociadas con el desarrollo de sistemas
medianos y grandes bases de datos. En las siguientes secciones se describen las principales actividades asociadas a cada
etapa del ciclo de vida de desarrollo del sistema de base de datos con más detalle.
10.3 Planificación de la base de datos
Las actividades de gestión que permiten a las etapas del ciclo de vida de desarrollo tem la base de
Base de datos
datos sis- a hacerse realidad la forma más eficiente y efectiva posible.
de planificación
la planificación de base de datos debe estar integrado con el general es la estrategia de la organización. Hay tres cuestiones
principales que intervienen en la formulación de una estrategia es, que son:
• la identificación de los planes y objetivos con la posterior determinación de las necesidades de sistemas de información
empresarial;
• Evaluación de los sistemas de información actuales para determinar las fortalezas y debilidades existentes;
• valoración de las oportunidades de TI que puedan producir una ventaja competitiva. Las metodologías utilizadas para
resolver estos problemas están fuera del alcance de este libro; Sin embargo, el lector interesado puede consultar
Robson (1997) y Cadle y Yeates (2007) para una discusión más completa.
M10_CONN3067_06_SE_C10.indd 347 06/10/14 16:30

Figura 10.1 Las etapas del ciclo de vida de desarrollo del sistema de base de datos.
348
M10_CONN3067_06_SE_C10.indd 348 06/10/14 16:30

10.3 Planificación de la base de datos | 349
Tabla 10.1 Resumen de las principales actividades asociadas con cada etapa del ciclo de vida de desarrollo del sistema de base de datos.
Escenario Actividades principales
Base de datos de planificación La planificación de cómo las etapas del ciclo de vida se pueden realizar de manera más eficiente y efectiva.
definición del sistema Especificando el alcance y los límites del sistema de base de datos, incluyendo los principales puntos de vista de los
usuarios, sus usuarios, y áreas de aplicación.
recopilación y análisis de Recogida y análisis de los requisitos para el nuevo sistema de base de datos.
requerimientos
diseño de bases diseño conceptual, lógico y físico de la base de datos.
la selección de DBMS Selección de un DBMS adecuados para el sistema de base de datos.
diseño de aplicaciones El diseño de la interfaz de usuario y los programas de aplicación que utilizan y procesan la base de datos.
Prototyping (opcional) La construcción de un modelo de trabajo del sistema de base de datos, lo que permite a los diseñadores o los usuarios
visualizar y evaluar cómo el sistema final se verá y función.
Implementación La creación de las definiciones de base de datos físicos y los programas de aplicación.
La conversión de datos y la carga Carga de datos desde el sistema antiguo al nuevo sistema y, cuando sea posible, la conversión de todas las aplicaciones
existentes para ejecutar en la nueva base de datos.
Pruebas sistema de base de datos es la prueba de errores y validado en contra de los requisitos especificados por los usuarios.
mantenimiento operativo sistema de base de datos se aplique plenamente. El sistema se controla y se mantiene continuamente. Cuando sea
necesario, los nuevos requerimientos se incorporan en el sistema de base de datos a través de las etapas anteriores del
ciclo de vida.
Un primer paso importante en la planificación de la base de datos es definir claramente la estado de la misión para el
sistema de base de datos. La declaración de misión define los principales objetivos del sistema de base de datos. Los que
conducen el proyecto de base de datos dentro de la organización (por ejemplo, el Director y / o propietario) normalmente
definen la declaración de la misión. Una declaración de misión ayuda a clarificar el propósito del sistema de base de datos y
proporcionar un camino más claro hacia la creación eficiente y eficaz del sistema de base de datos necesaria. Una vez
definida la declaración de la misión, la siguiente actividad consiste en la identificación de la
objetivos de la misión. Cada objetivo de la misión debe identificar una tarea en particular que el sistema de base
de datos debe apoyar. El supuesto es que si el sistema de base de datos compatible con los objetivos de la misión,
la misión debe ser satisfecha. La declaración y los objetivos de la misión pueden ir acompañados de alguna
información adicional que especifica en términos generales el trabajo a realizar, los recursos con los que lo hacen, y
el dinero para pagar por todo. Se demuestra la creación de una misión objetivos y misión de los estados para el
sistema de base de datos de Casa de sus sueños en la Sección 11.4.2.
la planificación de la base de datos debe incluir también el desarrollo de las normas que rigen la forma en que
se recopilarán, cómo el formato debe ser especificado, qué documentación se necesita, y cómo el diseño e
implementación deberían proceder. Las normas pueden ser mucho tiempo para desarrollar y mantener, lo que
requiere recursos para ponerlos en marcha inicialmente, y continuar su mantenimiento. Sin embargo, un
conjunto bien diseñado de normas proporciona una base para la formación del personal y de medición
M10_CONN3067_06_SE_C10.indd 349 06/10/14 16:30

control de calidad, y se puede asegurar que el trabajo se ajusta a un patrón, independientemente de las capacidades del
personal y experiencia. Por ejemplo, las normas específicas pueden regir el número de elementos de datos pueden ser
nombrados en el diccionario de datos, que a su vez puede prevenir tanto la redundancia e inconsistencia. Todos los requisitos
legales o empresariales relativas a los datos deben ser documentadas, como la estipulación de que algunos tipos de datos
deben ser tratados de forma confidencial.
10.4 Definición del sistema

definición del Describe el alcance y los límites del sistema de base de datos y los principales puntos de vista de los usuarios.
sistema
Antes de intentar diseñar un sistema de base de datos, es esencial que primero identificar los límites del sistema que
estamos investigando y cómo las interfaces con otras partes del sistema de información de la organización. Es
importante que incluimos dentro de nuestros límites del sistema no sólo a los usuarios actuales y áreas de aplicación,
sino también a los usuarios y aplicaciones futuras. Se presenta un diagrama que representa el alcance y los límites de
la Casa de sus sueños sistema de base de datos en la figura 11.10. Incluido dentro del alcance y límites del sistema de
base de datos son los principales puntos de vista de los usuarios que van a ser soportado por la base de datos.
10.4.1 Vistas de los usuarios
Define lo que se requiere de un sistema de base de datos desde la perspectiva de un puesto de trabajo
vista de usuarios en particular (como Gerente o Supervisor) o el área de aplicaciones empresariales (tales como el
marketing, personal, o el control de existencias).
Un sistema de base de datos puede tener uno o más puntos de vista de los usuarios. La identificación de puntos de vista de los
usuarios es un aspecto importante del desarrollo de un sistema de base de datos, ya que ayuda a asegurar que no hay grandes
usuarios de la base de datos se olvidan cuando se desarrollan los requisitos para el nuevo sistema de base de datos. Vistas de
usuario también son particularmente útiles en el desarrollo de un sistema de base de datos relativamente complejos al permitir que
los requisitos para ser dividido en partes manejables.
Una vista usuario define lo que se requiere de un sistema de base de datos en términos de los datos a ser mantenidos y las
operaciones a realizar en los datos (en otras palabras, lo que los usuarios van a hacer con los datos). Los requisitos de una vista
de usuario pueden ser distintos a la vista o se superponen con otros puntos de vista. La figura 10.2 es una representación
esquemática de un sistema de base de datos con múltiples vistas por el usuario (denotada vista del usuario 1 a 6). Tenga en
cuenta que mientras que vistas de usuario (1, 2, y 3) y (5 y 6) tiene requiere superpuestas (que se muestran como áreas
sombreadas), vista del usuario 4 tiene requisitos distintos.
10.5 Colección requisitos y análisis

El proceso de recolección y análisis de información sobre la parte de la
recopilación y
organización que va a ser soportado por el sistema de base de datos, y utilizar esta
análisis de
información para identificar los requisitos para el nuevo sistema.
requerimientos
M10_CONN3067_06_SE_C10.indd 350 06/10/14 16:30

10.5 Requisitos Recogida y análisis | 351
Figura 10.2 Representación de un sistema de base de datos con múltiples vistas de usuario: vistas de usuario (1, 2, y 3) y (5 y 6) tienen
requisitos de solapamiento (que se muestran como áreas sombreadas), mientras que vista del usuario 4 tiene requisitos distintos.
Esta etapa consiste en la recogida y análisis de información sobre la parte de la empresa para ser servido por la base de
datos. Hay muchas técnicas para la recopilación de esta información, llamados determinación de los hechos técnicas, los
cuales se discuten en detalle en el capítulo 11. La información se recopila para cada vista principal de usuario (es decir,
puesto de trabajo o área de aplicaciones empresariales), incluyendo:
• una descripción de los datos utilizados o generados;
• los detalles de cómo los datos se va a utilizar o generado;
• cualquier requisito adicional para el nuevo sistema de base de datos.
Esta información es analizada después para identificar los requisitos (o características) para ser incluidos en el nuevo
sistema de base de datos. Estos requisitos se describen en los documentos a que se refiere colectivamente como especificaciones
de requisitos para el nuevo sistema de base de datos.
recopilación y análisis de requisitos es una etapa preliminar de diseño de base de datos. La cantidad de datos
recogidos depende de la naturaleza del problema y las políticas de la empresa. El exceso de estudio demasiado
pronto conduce a parálisis por análisis. Demasiado poco de pensamiento puede dar lugar a un gasto innecesario de
tiempo y dinero debido al trabajo en la solución equivocada al problema equivocado.
La información recogida en esta etapa puede ser mal estructurada e incluir algunas peticiones informales,
que se deben transformar en una declaración más estructurado de
M10_CONN3067_06_SE_C10.indd 351 06/10/14 16:30

requisitos. Esto se consigue utilizando técnicas de especificación de requisitos, que incluyen, por ejemplo,
estructurada (SAD) técnicas de análisis y diseño, diagramas de flujo de datos (DFD), y gráficos jerárquica del
proceso de entrada de salida (Hipo), apoyado por la documentación. Como se verá en breve, Ingeniería de Software
Asistida por Ordenador (CASE) pueden proporcionar la asistencia automática para asegurar que los requisitos son
completa y consistente. En la Sección 27.8 vamos a discutir cómo el Lenguaje de Modelado Unificado (UML) es
compatible con los requisitos de análisis y diseño.
La identificación de la funcionalidad necesaria para un sistema de base de datos es una actividad crítica, como los
sistemas con funcionalidad inadecuada o incompleta molestan a los usuarios, que pueden conducir al rechazo o la
subutilización del sistema. Sin embargo, la funcionalidad excesivo también puede ser problemático, ya que puede
complicar un sistema, por lo que es difícil de implementar, mantener, usar, o aprender.
Otra actividad importante asociado a esta etapa es decidir cómo hacer frente a la situación en la que hay
más de una vista de usuario para el sistema de base de datos. Hay tres enfoques principales para la gestión de
los requisitos de un sistema de base de datos con múltiples vistas de usuario:
• la centralizado enfoque;
• la vista la integración enfoque;
• una combinación de ambos enfoques.
10.5.1 enfoque centralizado
Los requisitos para cada vista de usuario se combinan en un único conjunto de requisitos para el nuevo
enfoque
sistema de base de datos. Un modelo de datos repre- tando todos los puntos de vista de usuario se crea
centralizado
durante la etapa de diseño de base de datos.
El enfoque centralizado (o de una sola vez) implica el cotejo de los requisitos para diferentes vistas de usuario en una única
lista de requisitos. La colección de vistas de usuario se le da un nombre que proporciona alguna indicación de la zona de
aplicación cubierto por todos los puntos de vista de los usuarios fusionadas. En la etapa de diseño de base de datos (véase la
Sección 10.6), se crea un modelo de datos global, que representa a todos los puntos de vista de los usuarios. El modelo de
datos global se compone de diagramas y documentación que describen formalmente a los requerimientos de información de
los usuarios. Un diagrama que representa la gestión de puntos de vista del usuario 1 a 3 usando el enfoque centralizado se
muestra en la figura 10.3. Generalmente, se prefiere este enfoque cuando hay un solapamiento significativo en los requisitos
para cada vista del usuario y el sistema de base de datos no es excesivamente complejo.
Enfoque 10.5.2 Vista de la integración
Ver enfoque Los requisitos para cada vista del usuario se mantienen como listas separadas. Los modelos de datos que
de integración representan cada vista de usuario se crean y luego se fusionaron posteriormente durante la etapa de diseño de
base de datos.
El enfoque de vista de integración implica dejar los requisitos para cada vista de usuario como listas separadas de
requisitos. En la etapa de diseño de base de datos (véase la Sección 10.6), que
M10_CONN3067_06_SE_C10.indd 352 06/10/14 16:30

10.5 Requisitos Recogida y análisis | 353
Figura 10.3 El enfoque centralizado de gestión de usuarios múltiples vistas 1 a 3.
primero crear un modelo de datos para cada vista del usuario. Un modelo de datos que representa un solo punto de vista del usuario (o un
subconjunto de todos los puntos de vista de usuario) se llama una modelo de datos local. Cada modelo se compone de diagramas y
documentación que describe formalmente los requisitos de uno o más puntos de vista, pero no todos los usuarios de la base de datos. Los
modelos de datos locales son luego se fusionaron en una etapa posterior de la base de datos de diseño para producir una modelo de datos
global,
lo que representa todos Requisitos de usuario para la base de datos. Un diagrama que representa la gestión de puntos de
vista del usuario 1 a 3 usando el enfoque de integración vista se muestra en la figura 10.4. Generalmente, este enfoque se
prefiere cuando hay diferencias significativas entre los puntos de vista del usuario y el sistema de base de datos es lo
suficientemente complejo para justificar dividir el trabajo en partes más manejables. Se demuestra cómo utilizar el enfoque
de integración de la vista en el capítulo 17, el paso 2.6.
Para algunos sistemas de bases de datos complejas, puede ser apropiado utilizar una combinación de ambos los
enfoques centralizados y vista de integración para gestionar múltiples vistas de usuario. Por ejemplo, los requisitos para
dos o más vistas de usuario pueden ser primero fusionado usando el enfoque centralizado, que se utiliza para construir un
modelo lógico de datos local. Este modelo se puede combinar con otros modelos de datos lógicos locales utilizando el
enfoque de vista de integración para producir un modelo global de datos lógicos. En este caso, cada modelo de datos
lógicos locales representa los requisitos de dos o más vistas de usuario y el modelo lógico de datos mundial final
representa los requisitos de todos los puntos de vista de los usuarios del sistema de base de datos.
Se discute cómo manejar múltiples puntos de vista de los usuarios en más detalle en la Sección 11.4.4, y utilizando
la metodología descrita en este libro, se demuestra cómo construir una base de datos para el Casa de sus sueños alquiler
estudio de caso utilizando una combinación de los enfoques de integración centralizadas y ver.
M10_CONN3067_06_SE_C10.indd 353 06/10/14 16:30

Figura 10.4 La vista enfoque de integración de la gestión de usuarios múltiples vistas 1 a 3.
10.6 Diseño de base de datos
diseño de El proceso de crear un diseño que va a apoyar los objetivos de la declaración de misión y la misión
bases de la empresa para el sistema de base de datos necesaria.
En esta sección se presenta una visión general de los principales enfoques de diseño de base de datos. También se analiza
la finalidad y el uso de modelado de datos en el diseño de la base de datos. A continuación describimos las tres fases de
diseño de base de datos: diseño conceptual, lógico y físico.
M10_CONN3067_06_SE_C10.indd 354 06/10/14 16:30

10.6 Diseño de base de datos | 355
10.6.1 enfoques para el diseño de base de datos
Los dos enfoques principales para el diseño de una base de datos se conocen como “abajo hacia arriba” y los
“de arriba hacia abajo.” de abajo hacia arriba enfoque comienza en el nivel fundamental de atributos (es decir,
propiedades de entidades y relaciones), que a través del análisis de las asociaciones entre atributos se agrupan
en las relaciones que representan tipos de entidades y relaciones entre las entidades. En los capítulos 14 y 15
se discute el proceso de normalización, lo que representa un enfoque de abajo hacia arriba para el diseño de
bases de datos. La normalización implica la identificación de los atributos requeridos y su posterior agregación
en relaciones normalizadas en base a las dependencias funcionales entre los atributos.
El enfoque de abajo arriba es apropiado para el diseño de bases de datos simples con un número
relativamente pequeño de atributos. Sin embargo, este enfoque se vuelve difícil cuando se aplica al diseño de
bases de datos más complejos con un mayor número de atributos, donde es difícil establecer todas las
dependencias funcionales entre los atributos. Como los modelos de datos conceptuales y lógicos para bases de
datos complejas pueden contener cientos de miles de atributos, es esencial establecer un enfoque que va a
simplificar el proceso de diseño. Además, en las etapas iniciales del establecimiento de los requisitos de datos
para una base de datos compleja, puede ser difícil de establecer todos los atributos para ser incluidas en los
modelos de datos.
Una estrategia más adecuada para el diseño de bases de datos complejas es utilizar el
De arriba hacia abajo enfoque. Este enfoque comienza con el desarrollo de modelos de datos que contienen
un par de entidades y relaciones de alto nivel y luego se aplica sucesivos refinamientos de arriba hacia abajo
para identificar las entidades de menor nivel, las relaciones y los atributos asociados. El enfoque de arriba
hacia abajo se ilustra utilizando los conceptos del modelo de entidad-relación (ER), a partir de la identificación
de entidades y relaciones entre las entidades, que son de interés para la organización. Por ejemplo, podemos
comenzar por identificar las entidades Propietario privado y PropertyForRent,
y entonces la relación entre estas entidades, Propietario privado es propietaria PropertyForRent,

y finalmente el atributos como asociado PrivateOwner (ownerNo, nombre, y dirección)
y PropertyForRent (propertyNo y dirección). La construcción de un modelo de datos de alto nivel utilizando los conceptos
del modelo ER se discute en los capítulos 12 y 13.
Hay otros enfoques para el diseño de bases de datos, tales como el enfoque de adentro hacia afuera y el enfoque de
estrategia mixta. los De adentro hacia afuera enfoque se relaciona con el enfoque de abajo hacia arriba, pero se diferencia
identificando en primer lugar un conjunto de entidades principales y luego se extiende a considerar otras entidades,
relaciones y atributos asociados a los que identificó por primera vez. los estrategia mixta enfoque utiliza tanto el de abajo
arriba y de arriba hacia abajo para diversas partes del modelo antes de que finalmente la combinación de todas las partes
juntas.
Modelado de datos 10.6.2
Los dos objetivos principales de modelado de datos son para ayudar en la comprensión del significado
(semántica) de los datos y facilitar la comunicación acerca de los requisitos de información. La construcción
de un modelo de datos requiere responder a preguntas sobre las entidades, relaciones y atributos. De este
modo, los diseñadores descubren la semántica de los datos de la empresa, que existen o no pasar a ser
grabada en un modelo formal de datos. Entidades, relaciones y atributos son fundamentales para
M10_CONN3067_06_SE_C10.indd 355 06/10/14 16:30

todas las empresas. Sin embargo, su significado puede siguen siendo poco conocidos hasta que se han documentado
correctamente. Un modelo de datos hace que sea más fácil de entender el significado de los datos, y por lo tanto que
modelo de datos para asegurar que entendemos:
• la perspectiva de cada usuario de los datos;
• la naturaleza de los datos en sí, independiente de sus representaciones físicas;
• el uso de datos a través de vistas de usuario.
Los modelos de datos se pueden utilizar para transmitir una comprensión del diseñador de los requerimientos de
información de la empresa. Siempre que ambas partes están familiarizados con la notación utilizada en el modelo, se
apoyará la comunicación entre los usuarios y diseñadores. Cada vez más, las empresas están estandarizando la forma
en que modelo de datos mediante la selección de un enfoque particular de modelado de datos y su uso a través de sus
proyectos de desarrollo de base de datos. El modelo más popular de alto nivel de los datos utilizados en el diseño de la
base de datos, y el que usamos en este libro, se basa en los conceptos del modelo ER. Se describe el modelado ER en
detalle en los capítulos 12 y 13.
Criterios para modelos de datos
Un óptima modelo de datos debe satisfacer los criterios enumerados en la Tabla 10.2 (Fleming y Von Halle,
1989). Sin embargo, a veces estos criterios son incompatibles entre sí y con las compensaciones son a veces
necesarias. Por ejemplo, en el intento de lograr una mayor expresibilidad en un modelo de datos, podemos perder sencillez.
10.6.3 fases de diseño de base de datos
diseño de base de datos se compone de tres fases principales: diseño conceptual, lógico y físico.
diseño conceptual de bases de datos
diseño conceptual de El proceso de construcción de un modelo de los datos utilizados en una empresa,
bases de datos independiente de todos consideraciones físicas.
Tabla 10.2 Los criterios para producir un modelo de datos óptima.
validez estructural La consistencia con la forma en la empresa define y organiza la información.
Sencillez La facilidad de comprensión por parte de los profesionales de SI y usuarios no técnicos.
expresibilidad Capacidad de distinguir entre diferentes datos, relaciones entre los datos y las limitaciones.
no redundancia Exclusión de información superflua; en particular, la representación de una sola pieza de información exactamente una
vez.
compartible No es específico para cualquier aplicación o tecnología en particular y por lo tanto utilizable por muchos.
Extensibilidad Capacidad de evolucionar para soportar nuevos requisitos con un efecto mínimo sobre los usuarios existentes.
Integridad Coherencia con la forma en que la empresa utiliza y gestiona la información.
representación Capacidad de representar un modelo utilizando una notación diagramática de fácil comprensión.
esquemática
M10_CONN3067_06_SE_C10.indd 356 06/10/14 16:30

10.6 Datos de diseño | 357
La primera fase de diseño de la base de datos se llama diseño conceptual de bases de datos e implica la creación de un
modelo conceptual de datos de la parte de la empresa que estamos interesados en el modelado. El modelo de datos se
construye a partir de la información documentada en la especificación de los requisitos de los usuarios. diseño conceptual
de bases de datos es totalmente independiente de los detalles de implementación como el software DBMS de destino,
programas de aplicación, lenguajes de programación, plataforma de hardware, o cualquier otro tipo de consideraciones
físicas. En el capítulo 16, se presenta una guía práctica paso a paso sobre cómo realizar el diseño de base de datos
conceptual.
A lo largo del proceso de desarrollo de un modelo conceptual de datos, el modelo se ha probado y validado frente
a las necesidades del usuario. El modelo conceptual de datos de la empresa es una fuente de información para la
siguiente fase, es decir, diseño de base de datos lógica.
diseño de base de datos lógica
diseño de base El proceso de construcción de un modelo de los datos utilizados en una empresa basada en un
de datos lógica modelo de datos específico, pero independiente de un DBMS particulares y otras consideraciones
físicas.
La segunda fase de diseño de la base de datos se llama diseño de base de datos lógica, lo que se traduce en
la creación de un modelo de datos lógicos de la parte de la empresa que nos interesa modelar. El modelo de
datos conceptual creado en la fase anterior se refina y cartografiado en un modelo de datos lógico. El modelo
lógico de datos se basa en el modelo de datos de destino para la base de datos (por ejemplo, el modelo de
datos relacional).
Mientras que un modelo de datos conceptual es independiente de todas las consideraciones físicas, un modelo
lógico se deriva saber el modelo de datos subyacente de los DBMS de destino. En otras palabras, sabemos que el
DBMS es, por ejemplo, de relación, de red, jerárquico, o Orientado a Objetos. Sin embargo, ignoramos cualquier
otro aspecto de los DBMS elegidos y, en particular, cualquier detalles físicos, tales como estructuras de
almacenamiento o índices.
Durante todo el proceso de desarrollo de un modelo de datos lógicos, el modelo se prueba y se valida frente a los
requisitos de los usuarios. La técnica de la normalización se utiliza para probar la corrección de un modelo de datos
lógico. La normalización asegura que las relaciones derivadas del modelo de datos no muestran la redundancia de
datos, que pueden causar anomalías de actualización cuando se implementan. En el capítulo 14 se ilustran los
problemas asociados con la redundancia de datos y describimos el proceso de normalización en detalle. El modelo
lógico de datos también debe ser examinado para garantizar que respalda las operaciones especificadas por los
usuarios.
El modelo de datos lógico es una fuente de información para la siguiente fase, es decir, diseño de base de datos física,
proporcionando el diseñador base de datos física con un vehículo para la fabricación de soluciones de compromiso que son muy
importantes para el diseño de la base de datos eficiente. El modelo lógico también desempeña un papel importante durante la
fase de mantenimiento operativo del ciclo de vida de desarrollo del sistema de base de datos. Con el mantenimiento adecuado y
se mantiene hasta la fecha, el modelo de datos permite a los cambios futuros programas de aplicación o datos que se precisa y
eficiente representados por la base de datos.
En el capítulo 17 se presenta una guía práctica paso a paso para el diseño de base de datos lógica.
M10_CONN3067_06_SE_C10.indd 357 06/10/14 16:30

diseño de base de datos física
El proceso de producir una descripción de la aplicación de la base de datos en el almacenamiento

diseño de base
secundario; que describe las relaciones base, organizaciones de archivos, y los índices utilizados
de datos física
para lograr un acceso eficiente a los datos y todas las restricciones de integridad asociados y
medidas de seguridad.
diseño de base de datos física es la tercera y última fase del proceso de diseño de base de datos, durante el
cual el diseñador decide cómo la base de datos debe ser implementado. La fase previa de diseño de base de
datos implicó el desarrollo de una estructura lógica de la base de datos, que describe las relaciones y las
limitaciones de la empresa. Aunque esta estructura es DBMS-independiente, se desarrolla de acuerdo con un
modelo de datos particular, tal como la relacional, red o jerárquica. Sin embargo, en el desarrollo del diseño
de base de datos física, hay que identificar primero el DBMS de destino. Por lo tanto, el diseño físico se
adapta a un sistema DBMS específico. Hay realimentación entre el diseño físico y lógico, porque las
decisiones se toman durante el diseño físico para mejorar el rendimiento que pueda afectar a la estructura del
modelo de datos lógicos.
En general, el objetivo principal del diseño de base de datos física es describir cómo tenemos la intención de aplicar
físicamente el diseño de base de datos lógica. Para el modelo relacional, esto implica:
• la creación de un conjunto de tablas relacionales y las limitaciones de estas tablas a partir de la información
presentada en el modelo de datos lógicos;
• la identificación de la estructuras de almacenamiento y métodos de acceso específico para los datos para lograr un
rendimiento óptimo para el sistema de base de datos;
• el diseño de la protección de seguridad para el sistema.
Idealmente, el diseño de base de datos conceptual y lógico para sistemas más grandes debe ser separado de diseño
físico por tres razones principales:
• se trata de un tema diferente cuestión -la qué, no la cómo;

• que se realiza a una diferente de tiempo de la qué debe entenderse antes de la cómo
puede ser determinado;
• que requiere diferentes habilidades, que se encuentran a menudo en diferentes personas. diseño de base de
datos es un proceso iterativo que tiene un punto de partida y una procesión casi interminable de refinamientos.
Ellos deben ser vistos como procesos de aprendizaje. A medida que los diseñadores llegan a comprender el
funcionamiento de la empresa y los significados de sus datos, y expresar que la comprensión de los modelos de
datos seleccionados, la información obtenida bien puede requerir cambios en otras partes del diseño. En
particular, los diseños de bases de datos conceptuales y lógicos son críticos para el éxito global del sistema. Si
los diseños no son una verdadera representación de la empresa, será difícil, si no imposible, para definir todos los
puntos de vista de usuario necesarios o para mantener la integridad de la base de datos. Incluso puede resultar
difícil de definir la implementación física o para mantener el rendimiento del sistema aceptable. Por otro lado, la
capacidad de adaptarse al cambio es un sello distintivo de un buen diseño de base de datos. Por lo tanto, la pena
invertir el tiempo y la energía necesaria para producir el mejor diseño posible.
M10_CONN3067_06_SE_C10.indd 358 06/10/14 16:30

10.7 Selección DBMS | 359
Figura 10.5
El modelado de
datos y la
arquitectura
ANSISPARC.
En el capítulo 2, discutimos la arquitectura de tres niveles ANSI-SPARC para un sistema de base de datos,
que consiste en los esquemas externos, conceptuales, e internos. La figura 10.5 ilustra la correspondencia
entre esta arquitectura y diseño de base conceptual, lógica y física. En los capítulos 18 y 19 se presenta una
metodología paso a paso para la fase de diseño de base de datos físico.
10.7 Selección DBMS

La selección de un DBMS apropiado para apoyar el sistema de base de datos.
la selección DBMS
Si no existe ningún DBMS, una parte apropiada del ciclo de vida en el que para realizar una selección entre las fases de
diseño de base de datos conceptual y lógico (véase la Figura 10.1). Sin embargo, la selección puede hacerse en cualquier
momento antes de diseño lógico proporciona suficiente información disponible acerca de los requisitos del sistema, tales
como el rendimiento, la facilidad de las limitaciones de reestructuración, de seguridad y de integridad.
Aunque la selección DBMS puede ser poco frecuentes, como las necesidades de las empresas se expanden o se
sustituyen los sistemas existentes, puede ser necesario a veces para evaluar nuevos productos DBMS. En tales casos,
el objetivo es seleccionar un sistema que cumpla con los requerimientos actuales y futuros de la empresa, equilibrarse
con los costos que incluyen la compra del producto DBMS, cualquier software / hardware adicional requerido para
soportar el sistema de base de datos y los costos asociados con cambio y la formación del personal.
Un enfoque simple para la selección es para marcar características DBMS a partir de exigencias. En la
selección de un nuevo producto DBMS, hay una oportunidad para asegurar que el proceso de selección está bien
planificado, y el sistema ofrece beneficios reales para la empresa. En la siguiente sección se describe un método
típico para la selección de la “mejor” DBMS.
10.7.1 Selección del DBMS

Los pasos principales para la selección de un DBMS se enumeran en la Tabla 10.3.
M10_CONN3067_06_SE_C10.indd 359 06/10/14 16:30

Tabla 10.3 Pasos principales para la selección de un DBMS. Definir
términos de referencia del estudio de lista de dos o tres productos de
evaluar los productos
Recomendar la selección y producir informe
Definir los términos de referencia del estudio
Los términos de referencia para la selección de DBMS se establece, indicando los objetivos y alcance del estudio y
las tareas que deben llevarse a cabo. Este documento también puede incluir una descripción de los criterios
(basado en la especificación de requerimientos de los usuarios) que se utilizará para evaluar los productos DBMS,
una lista preliminar de posibles productos, y todas las restricciones y los plazos necesarios para el estudio.
Favoritos dos o tres productos

Los criterios que se consideran “crítico” para una implementación exitosa se pueden utilizar para producir una lista
preliminar de los productos DBMS para su evaluación. Por ejemplo, la decisión de incluir un producto DBMS puede
depender del presupuesto disponible, el nivel de soporte del proveedor, la compatibilidad con otro software, y si el
producto se ejecuta en hardware en particular. Puede obtenerse información adicional sobre un producto puede ser
obtenida poniéndose en contacto con los usuarios existentes, que pueden proporcionar detalles específicos sobre lo
bueno que el soporte del proveedor es en realidad, en la forma en que el producto es compatible con aplicaciones
particulares, y si ciertos plataformas de hardware son más problemáticos que otros. También puede haber puntos de
referencia disponibles que comparan el rendimiento de los productos DBMS. Tras un estudio inicial de la funcionalidad y
características de los productos DBMS, se identifica una lista de dos o tres productos.
La World Wide Web es una excelente fuente de información y se puede utilizar para identificar posibles candidatos
DBMS. Por ejemplo, en línea centro de pruebas de la tecnología de InfoWorld (disponible en www.infoworld /
test-center.com) ofrece una revisión exhaustiva de los productos DBMS. Los sitios web de los vendedores también
pueden proporcionar información valiosa sobre los productos DBMS.
evaluar los productos
Hay varias características que se pueden utilizar para evaluar un producto DBMS. Para los fines de la evaluación, estas
características pueden evaluarse como grupos (por ejemplo, definición de datos) o de forma individual (por ejemplo, tipos de
datos disponibles). características Tabla 10.4 listas de posibles para la evaluación del producto DBMS agrupados por
definición de datos, definición física, la accesibilidad, la manipulación de transacción, los servicios públicos, el desarrollo, y
otras características.
Si se comprueban las características fuera simplemente una indicación de lo bueno o malo que cada uno es,
puede ser difícil hacer comparaciones entre productos DBMS. Un enfoque más útil es de peso características y /
o grupos de características con respecto a su importancia para la organización, y para obtener un valor
ponderado global que puede
M10_CONN3067_06_SE_C10.indd 360 06/10/14 16:30

10.7 Selección DBMS | 361
Tabla 10.4 Características para la evaluación de DBMS.
definición de datos definición física
aplicación de la clave primaria estructuras de archivos disponibles
especificación de clave externa mantenimiento de la estructura de archivos
Los tipos de datos disponibles Facilidad de reorganización
Tipo de datos extensibilidad Indexación
especificación de dominio campos de longitud variable / registros
Facilidad de reestructuración Compresión de datos
controles de integridad rutinas de cifrado
Ver mecanismo Los requisitos de memoria
Diccionario de datos Requisitos de almacenamiento
independencia de datos modelo
de datos subyacente evolución
del esquema
Accesibilidad el tratamiento de transacciones
lenguaje de consulta: SQL2 / SQL: 2011 / ODMG compatible Rutinas de backup y recuperación de las
instalaciones checkpoints
Las interfaces para 3GLs facilidad de registro
Multi usuario Granularidad de concurrencia
Seguridad estrategia de resolución de estancamiento
• Los controles de acceso modelos de transacción avanzados
• mecanismo de autorización procesamiento de consultas en paralelo
Utilidades Desarrollo
medición de la eficacia herramientas 4GL / L5G
Sintonización herramientas CASE
instalaciones de carga / descarga capacidades de Windows
supervisión del uso del usuario procedimientos almacenados, disparadores y reglas
apoyo a la administración de bases de datos herramientas de desarrollo Web
Otras características
Capacidad de actualización La interoperabilidad con otros DBMS y otros sistemas
la estabilidad proveedor la integración web
Usuario base utilidades de replicación
apoyo a la formación y el usuario capacidades distribuidas
(Continuado)
M10_CONN3067_06_SE_C10.indd 361 06/10/14 16:30

Tabla 10.4 ( Continuado)
Otras características
Documentación Portabilidad
Sistema operativo requerido hardware necesario
Costo red de apoyo
Ayuda en linea capacidades orientadas a objetos
normas utilizadas Arquitectura (2- o 3-nivel de cliente / servidor)
gestión de versiones Actuación
la optimización de consultas Extensibile rendimiento de las transacciones
escalabilidad El número máximo de usuarios simultáneos
Soporte para herramientas de informes y analíticas soporte para XML y servicios Web
ser utilizado para comparar productos. Tabla 10.5 ilustra este tipo de análisis para el grupo “definición física” para un
producto de muestra DBMS. Cada entidad seleccionada se da una calificación de 10, una ponderación de 1 para
indicar su importancia en relación con otras características en el grupo, y una puntuación calculada en base a los
tiempos de calificación de la ponderación. Por ejemplo, en la Tabla 10.5 la función “Facilidad de reorganización” se da
una calificación de 4, y una ponderación de 0,25, produciendo una puntuación de 1,0. Esta característica se da la
más alta ponderación en esta tabla, lo que indica su importancia en esta parte de la evaluación. Además, la “Facilidad
de reorganización” característica se pondera, por ejemplo, cinco veces mayor que la característica de “compresión de
datos” con la ponderación más baja de 0,05, mientras que las dos características “Requisitos de memoria” y
“Almacenamiento
Tabla 10.5 Análisis de las características para la evaluación de productos DBMS.
DBMS: Productos Muestra Vendedor: Vendedor Muestra
Las características Definición del grupo
físico COMENTARIOS ponderación CALIFICACIÓN Puntuación
estructuras de archivos disponibles Elección de 4 8 0.15 1.2
mantenimiento de la estructura de archivos No autorregulador 6 0.2 1.2
Facilidad de reorganización 4 0.25 1.0
Indexación 6 0.15 0.9
campos de longitud variable / registros 6 0.15 0.9
Compresión de datos Especificar la estructura de archivos 7 0.05 0.35
rutinas de cifrado Elección de 2 4 0.05 0.2
Los requisitos de memoria 0 0.00 0
Requisitos de almacenamiento 0 0.00 0
Los totales 41 1.0 5.75

grupo de definición física 5.75 0.25 1.44
M10_CONN3067_06_SE_C10.indd 362 06/10/14 16:30

10.8 Diseño de aplicaciones | 363
requisitos”se les da una ponderación de 0.00 y por lo tanto no se incluyen en esta evaluación.
A continuación resumimos todas las puntuaciones para cada característica evaluada para producir una puntuación total para
el grupo. La puntuación para el grupo es entonces sí aplicará un coeficiente corrector, para indicar su importancia en relación con
otros grupos de características incluidas en la evaluación. Por ejemplo, en la Tabla 10.5, la puntuación total para el grupo
“definición física” es 5,75; Sin embargo, este resultado tiene una ponderación de 0,25.
Finalmente, todas las puntuaciones ponderadas para cada grupo evaluado de características se suman para
producir una puntuación individual para el producto DBMS, que se compara con las puntuaciones de los demás
productos. El producto con el puntaje más alto es el “ganador".
Además de este tipo de análisis, también podemos evaluar productos al permitir que los proveedores para demostrar su
producto o ensayando los productos de la casa. En la casa de evaluación implica la creación de un banco de pruebas piloto
utilizando los productos candidatos. Cada producto se prueba en contra de su capacidad para cumplir con los requerimientos
del usuario para el sistema de base de datos. Los informes comparativos publicados por el Consejo de procesamiento de
transacciones se pueden encontrar en www.tpc.org.
Recomendar la selección y producir informe
El paso final de la selección DBMS es documentar el proceso y para proporcionar una exposición de las
conclusiones y recomendaciones para un producto DBMS particular.
10.8 Diseño de aplicaciones

diseño de El diseño de la interfaz de usuario y los programas de aplicación que utilizan y procesan la
aplicaciones base de datos.
En la figura 10.1, observan que la base de datos y diseño de la aplicación son actividades paralelas del ciclo de vida
de desarrollo del sistema de base de datos. En la mayoría de los casos, no es posible completar el diseño de la
aplicación hasta que el diseño de la base de datos en sí ha tenido lugar. Por otro lado, existe la base de datos para
soportar las aplicaciones, y lo que debe haber un flujo de información entre el diseño de aplicaciones y diseño de
base de datos.
Debemos asegurarnos de que toda la funcionalidad se indica en la especificación de requerimientos de los

usuarios está presente en el diseño de aplicaciones para el sistema de base de datos. Esto implica el diseño de
los programas de aplicación que acceden a la base de datos y el diseño de las transacciones, (es decir, los
métodos de acceso a la base de datos). Además de diseñar la forma en la funcionalidad requerida se ha de
lograr, tenemos que diseñar una interfaz de usuario adecuada al sistema de base de datos. Esta interfaz debe
presentar la información requerida en una forma fácil de usar. La importancia del diseño de la interfaz de usuario
a veces se ignora o se queda hasta tarde en las etapas de diseño. Sin embargo, se debe reconocer que la
interfaz puede ser uno de los componentes más importantes del sistema. Si es fácil de aprender, fácil de usar,
sencillo y perdonando, los usuarios estarán dispuestos a hacer buen uso de la información que se presenta. Por
otro lado, si la interfaz no tiene ninguna de estas características, el sistema será, sin duda, causar problemas.
M10_CONN3067_06_SE_C10.indd 363 06/10/14 16:30

En las siguientes secciones, se examinan brevemente dos aspectos de diseño de la aplicación: Diseño de transacción y de
diseño de interfaz de usuario.
10.8.1 Diseño de transacción

Antes de discutir el diseño de transacción, en primer lugar describir lo que representa una transacción.
Una acción o conjunto de acciones, llevadas a cabo por un único programa de aplicación de
Transacción usuario o bien, que tenga acceso o cambia el contenido de la base de datos.
Transacciones representan eventos del “mundo real”, tales como el registro de una propiedad de alquiler, la adición de un
nuevo miembro del personal, el registro de un nuevo cliente, y el arrendamiento de un inmueble. Estas operaciones se
tienen que aplicar a la base de datos para asegurar que los datos en poder de la base de datos sigue siendo actual con la
situación del “mundo real” y para apoyar las necesidades de información de los usuarios.
Una transacción puede estar compuesto de varias operaciones, tales como la transferencia de dinero de
una cuenta a otra. Sin embargo, desde la perspectiva del usuario, estas operaciones todavía lograr una sola
tarea. Desde la perspectiva del DBMS, una transacción transfiere la base de datos de un estado consistente a
otro. El DBMS asegura la consistencia de la base de datos, incluso en presencia de un fallo. El DBMS
también asegura que una vez que una transacción ha terminado, los cambios realizados se almacenan
permanentemente en la base de datos y no se pueden perder o incompleta (sin ejecutar otra transacción para
compensar el efecto de la primera transacción). Si la transacción no se puede completar por cualquier motivo,
el DBMS debe garantizar que los cambios realizados por dicha transacción se deshacen. En el ejemplo de la
transferencia bancaria, si el dinero se debita de una cuenta y la transacción falla antes de acreditar la otra
cuenta, el DBMS debe deshacer el débito. Si tuviéramos que definir las operaciones de débito y crédito como
transacciones separadas, a continuación, una vez que había cargado la primera cuenta y completado la
transacción, no se nos permite deshacer ese cambio (sin ejecutar otra operación de crédito a la cuenta de
adeudo con la cantidad requerida) .
El propósito de diseño transacción es definir y documentar las características de alto nivel de las
operaciones requeridas en la base de datos, incluyendo:
• datos para ser utilizados por la transacción;
• características funcionales de la transacción;

• de salida de la transacción;
• importancia para los usuarios;
• tasa esperada de uso.
Esta actividad debe llevarse a cabo al principio del proceso de diseño para asegurar que la base de datos implementado
es capaz de soportar todas las transacciones necesarias. Hay tres tipos principales de transacciones: las transacciones de
recuperación, las transacciones de actualización y transacciones mixtas:
• operaciones de recuperación se utilizan para recuperar datos para la visualización en la pantalla o en la producción
de un informe. Por ejemplo, la operación de la búsqueda y visualización
M10_CONN3067_06_SE_C10.indd 364 06/10/14 16:30

10.8 Diseño de aplicaciones | 365
los detalles de una propiedad (dado el número propiedad) es un ejemplo de una transacción de recuperación.
• transacciones de actualización se utilizan para insertar nuevos registros, eliminar registros antiguos, o modificar los registros
existentes en la base de datos. Por ejemplo, la operación de insertar los detalles de una nueva propiedad en la base de datos es
un ejemplo de una transacción de actualización.
• transacciones mixtas implicar tanto la recuperación y actualización de datos. Por ejemplo, la operación
para buscar y visualizar los detalles de una propiedad (dado el número de la propiedad) y luego actualizar
el valor del alquiler mensual es un ejemplo de una operación mixta.
10.8.2 del usuario Directrices de diseño de interfaz
Antes de implementar un formulario o informe, es esencial que primero definir el diseño. directrices útiles a
seguir cuando formularios o informes diseño se enumeran en la Tabla 10.6 (Shneiderman et al., 2009).
significativo título
La información transmitida por el título debe identificar claramente y sin ambigüedades el propósito de la
forma / informe.
instrucciones comprensibles
terminología familiar se debe utilizar para transmitir instrucciones para el usuario. Las instrucciones deben ser
breves, y, cuando se requiere más información, pantallas de ayuda deben
Tabla 10.6 Directrices para el diseño de formularios / informe.
significativo título instrucciones comprensibles agrupación
lógica y secuencia de campos visualmente atractivo diseño del
informe Familiar etiquetas de campo de formulario /
terminología coherente y abreviaturas uso
consistente del color
espacio visible y los límites para la entrada de datos de los campos de
movimiento del cursor conveniente
corrección de errores para caracteres individuales y enteras mensajes de error
campos para valores inaceptables campos opcionales marcado mensajes
claramente explicativas para la señal de campos de Terminación
M10_CONN3067_06_SE_C10.indd 365 06/10/14 16:30

se pondrá a disposición. Las instrucciones deben ser escritos en un estilo gramatical consistente, utilizando un formato
estándar.
La agrupación lógica y la secuencia de campos
Los campos relacionados deben ser colocados juntos en el formulario / informe. La secuenciación de los campos debe
ser lógico y consistente.
diseño atractivo a la vista de la forma / informe
La forma / informe debe presentar una interfaz atractiva para el usuario. La forma / informe debería aparecer
equilibrada con campos o grupos de campos uniformemente posicionados a lo largo de la forma / informe. No debería
haber áreas del formulario / informe que tienen muy pocos o demasiados campos. Los campos o grupos de campos
deben estar separados por una cantidad regular de espacio. En su caso, los campos deben ser vertical u
horizontalmente alineadas. En los casos en una forma en la pantalla tiene un equivalente en papel, la aparición de
ambos debe ser coherente.
etiquetas de campo familiares
etiquetas de los campos deben estar familiarizados. Por ejemplo, si el sexo fueron reemplazados por género, es posible que algunos
usuarios podrían confundirse.
terminología consistente y abreviaturas

Una lista acordada de términos y abreviaturas conocidas se debe utilizar de forma coherente.
El uso consistente del color
El color debe ser usado para mejorar la apariencia de un formulario / informe y para resaltar los campos importantes o
mensajes importantes. Para lograr esto, el color se debe utilizar en una forma coherente y significativa. Por ejemplo,
campos de un formulario con un fondo blanco pueden indicar los campos de entrada de datos y los que tienen un
fondo azul pueden indicar los campos de sólo visualización.
espacio visible y los límites de los campos de entrada de datos
Un usuario debe ser visualmente consciente de la cantidad total de espacio disponible para cada campo. Esto permite a un
usuario a tener en cuenta el formato adecuado para los datos antes de entrar en los valores en un campo.
el movimiento del cursor conveniente
Un usuario debe identificar fácilmente la operación requerida para mover un cursor a lo largo de la forma /
informe. se deben utilizar mecanismos simples como el uso de la tecla Tab, flechas, o el puntero del ratón.
corrección de errores para caracteres individuales y campos enteros
Un usuario debe identificar fácilmente la operación requerida para realizar modificaciones en los valores de campo. mecanismos
simples deben estar disponibles, tales como el uso de la tecla de retroceso o sobrescribiendo.
M10_CONN3067_06_SE_C10.indd 366 06/10/14 16:30

10.10 implementación | 367
mensajes de error para los valores inaceptables
Si un usuario intenta introducir datos incorrectos en un campo, un mensaje de error se debe mostrar. El
mensaje debe informar al usuario del error e indicar los valores permisibles.
Los campos opcionales claramente marcados
Los campos opcionales deben estar claramente identificados para el usuario. Esto se puede lograr utilizando una etiqueta de campo
apropiado o mediante la visualización del campo de uso de un color que indica el tipo del campo. Los campos opcionales deben ser
colocados después de los campos requeridos.
mensajes explicativos para los campos
Cuando un usuario coloca un cursor en un campo, información sobre el campo debe aparecer en una posición normal en la
pantalla, tal como una barra de estado de la ventana.
señal de finalización
Debe quedar claro a un usuario cuando el proceso de llenado en campos de un formulario se ha completado. Sin embargo,
la opción de completar el proceso no debe ser automática, ya que el usuario puede desear revisar los datos introducidos.
10.9 prototipado
En varios puntos a lo largo del proceso de diseño, tenemos la opción de aplicar plenamente el sistema de base
de datos o construir un prototipo.
prototipado La construcción de un modelo de trabajo de un sistema de base de datos.
Un prototipo es un modelo de trabajo que normalmente no tiene todas las características requeridas o proporcionar
toda la funcionalidad del sistema final. El objetivo principal de desarrollar un sistema de base de datos prototipo es
permitir a los usuarios utilizar el prototipo para identificar las características del sistema que funcionan bien o son
inadecuados, y si es posible, para sugerir mejoras o incluso nuevas funciones al sistema de base de datos. De esta
manera, podemos aclarar mucho las necesidades de los usuarios, tanto para los usuarios y desarrolladores del
sistema y evaluar la viabilidad de un diseño del sistema en particular. Los prototipos deben tener la gran ventaja de
ser relativamente barato y rápido de construir.
Hay dos estrategias de creación de prototipos de uso común hoy en día: los requisitos de creación de
prototipos y de prototipado evolutivo. requisitos de prototipos utiliza un prototipo para determinar los requisitos
de un sistema de base de datos propuesta, y una vez los requisitos son completa, se descarta el prototipo. A
pesar de que prototipado evolutivo
se utiliza para los mismos fines, la diferencia importante es que el prototipo no se descarta, pero con un mayor
desarrollo se convierte en el sistema de base de datos de trabajo.
10.10 Implementación
La realización física de las bases de datos y aplicaciones diseños.
Implementación
M10_CONN3067_06_SE_C10.indd 367 06/10/14 16:30

Al término de las etapas de diseño (que pueden o no tener prototipos involucrados), ahora estamos en condiciones de aplicar
la base de datos y los programas de aplicación. La implementación de base de datos se consigue utilizando el DDL de los
DBMS seleccionado o de una interfaz gráfica de usuario, que proporciona la misma funcionalidad al tiempo que oculta las
sentencias DDL de bajo nivel. Las instrucciones DDL se utilizan para crear las estructuras de bases de datos y archivos de
base de datos vacía. Cualquier punto de vista de los usuarios especificados, también se aplican en esta etapa.
Los programas de aplicación se implementan utilizando el lenguaje de tercera o cuarta generación preferido (3GL o
4GL). Partes de estos programas de aplicación son las transacciones de bases de datos, que se implementan utilizando
el LMD del DBMS de destino, posiblemente integrados dentro de un lenguaje de programación en el servidor, como
Visual Basic (VB), VB.net, Python, Delphi, C, C ++, C # , Java, COBOL, Fortran, Ada o Pascal. También implementamos
los otros componentes del diseño de aplicaciones tales como pantallas de menús, formularios de entrada de datos e
informes. Una vez más, el DBMS de destino pueden tener sus propias herramientas de cuarta generación que permiten
un rápido desarrollo de aplicaciones a través de la provisión de los lenguajes de consulta no procedimentales, informes,
formularios generadores generadores y generadores de aplicaciones.
También se implementan controles de seguridad e integridad del sistema. Algunos de estos controles se
implementan utilizando el DDL, pero otros pueden necesitar ser definida fuera del DDL, utilizando, por ejemplo, las
utilidades de DBMS suministrados o controles del sistema operativo. Tenga en cuenta que SQL es a la vez un LMD y
una DDL, como se describe en los capítulos
6, 7 y 8.
10.11 La conversión de datos y carga

La conversión de datos y La transferencia de los datos existentes en la nueva base de datos y convertir cualquier
la carga aplicación existente para funcionar en la nueva base de datos.
Se requiere esta etapa sólo cuando un nuevo sistema de base de datos está reemplazando un sistema antiguo. Hoy en
día, es común que un DBMS para tener una utilidad que carga los archivos existentes en la nueva base de datos. La
utilidad por lo general requiere la especificación del archivo de origen y la base de datos de destino y, a continuación,
convierte automáticamente los datos al formato requerido de los nuevos archivos de base de datos. En su caso, puede ser
posible que el desarrollador para convertir y utilizar programas de aplicación del sistema antiguo para su uso por el nuevo
sistema. Cuando se requiera la conversión y de carga, el proceso debe ser planificado correctamente para asegurar una
suave transición a pleno funcionamiento.
10.12 Pruebas
El proceso de ejecución del sistema de base de datos con la intención de encontrar errores.
Pruebas
Antes de ir en vivo, el sistema de base de datos de nuevo desarrollo debe ser probado a fondo. Esto se consigue utilizando
estrategias de prueba cuidadosamente planificadas y datos realistas, por lo que todo el proceso de prueba se lleva a cabo de
forma metódica y rigurosa. Tenga en cuenta que en nuestra definición de la prueba que no hemos utilizado la opinión
generalizada de que la prueba es el procedimiento para demostrar que las fallas no están presentes. De hecho, las pruebas
no pueden
M10_CONN3067_06_SE_C10.indd 368 06/10/14 16:30

10.13 Mantenimiento operativo | 369
mostrar la ausencia de fallos; que puede mostrar sólo que los fallos de software están presentes. Si la prueba se realiza con
éxito, se pondrá al descubierto los errores con los programas de aplicación y, posiblemente, la estructura de base de datos.
Como un beneficio secundario, las pruebas han demostrado que la base de datos y los programas de aplicación Aparecer estar
funcionando de acuerdo con sus especificaciones y que los requisitos de desempeño Aparecer estar satisfecho. Además, las
mediciones recogidas de la fase de pruebas proporcionan una medida de la fiabilidad del software y de la calidad del
software.
Al igual que con el diseño de base de datos, los usuarios del nuevo sistema deben participar en el proceso de prueba. La situación
ideal para las pruebas del sistema es tener una base de datos de prueba en un sistema de hardware separado, pero a menudo esto
no es posible. Si los datos reales se va a utilizar, es esencial disponer de copias de seguridad realizadas en caso de error.
Las pruebas también debe cubrir la facilidad de uso del sistema de base de datos. Idealmente, una evaluación debe
llevarse a cabo contra una especificación de usabilidad. Ejemplos de criterios que pueden utilizarse para llevar a cabo la
evaluación incluyen los siguientes (Sommerville, 2010):
• Facilidad de aprendizaje: ¿Cuánto tiempo se tarda un usuario nuevo para ser productivos con el sistema?
• Rendimiento: ¿En qué medida coincide con la respuesta del sistema la práctica el trabajo del usuario?
• Robustez: ¿Cuán tolerante es el sistema de error de usuario?
• Recuperabilidad: ¿Qué tan bueno es el sistema a recuperarse de los errores de usuario?
• Adapatability: ¿En qué medida es el sistema de atado a un único modelo de trabajo? Algunos de estos criterios
pueden ser evaluados en otras etapas del ciclo de vida. Después de completar la prueba, el sistema de base de datos
está listo para ser “firmado” y entregado a los usuarios.
10.13 Mantenimiento operativo

mantenimiento El proceso de seguimiento y mantenimiento del sistema de base de datos después de la
operativo instalación.
En las etapas anteriores, el sistema de base de datos ha sido completamente implementado y probado. El sistema se
mueve ahora en una etapa de mantenimiento, lo que implica las siguientes actividades:
• El monitoreo del rendimiento del sistema. Si el rendimiento cae por debajo de un nivel, ajuste aceptable o
reorganización de la base de datos que sean necesarios.
• El mantenimiento y la actualización del sistema de base de datos (cuando se requiera). Nuevos los requisitos se
incorporan en el sistema de base de datos a través de las etapas anteriores del ciclo de vida.
Una vez que el sistema de base de datos está en pleno funcionamiento, una estrecha vigilancia se lleva a cabo para asegurar que el
rendimiento se mantiene dentro de niveles aceptables. Un DBMS normalmente proporciona varias utilidades para ayudar a la
administración de bases de datos, incluyendo los servicios públicos para cargar datos en una base de datos y para controlar el
sistema. Las utilidades que permiten la supervisión del sistema dan información sobre, por ejemplo, el uso de la base de datos, la
eficiencia (incluyendo el número de puntos muertos que se han producido, y así sucesivamente) de bloqueo, y la estrategia de
ejecución de la consulta. El DBA puede utilizar esta información para ajustar el sistema para dar un mejor
M10_CONN3067_06_SE_C10.indd 369 06/10/14 16:30

actuación; por ejemplo, mediante la creación de índices adicionales para acelerar las consultas, mediante la alteración de las estructuras de
almacenamiento, o mediante la combinación de tablas o de división.
El proceso de supervisión continúa durante toda la vida de un sistema de base de datos y con el tiempo puede conducir a la
reorganización de la base de datos para satisfacer los requisitos cambiantes. Estos cambios, a su vez proporcionan información
sobre la posible evolución del sistema y los recursos futuros que puedan ser necesarios. Esto, junto con el conocimiento de las
nuevas aplicaciones propuestas, permite que el DBA para participar en la planificación de la capacidad y para notificar o alertar al
personal de alto nivel para ajustar los planes en consecuencia. Si el DBMS carece de ciertos servicios públicos, ya sea el DBA
puede desarrollar los servicios públicos necesarios en la empresa o adquirir herramientas adicionales de proveedores, si está
disponible. Se discute la administración de base de datos con más detalle en el capítulo 20.
Cuando un nuevo sistema de base de datos se pone en línea, los usuarios deben funcionar en paralelo con el
sistema antiguo por un período de tiempo. Este enfoque protege las operaciones actuales en caso de problemas
imprevistos con el nuevo sistema. El control periódico coherencia de los datos entre los dos sistemas necesitan ser
hecha, y sólo cuando ambos sistemas parecen estar produciendo los mismos resultados consistentemente deben
ser dejados el viejo sistema. Si el cambio es demasiado apresurado, el resultado final podría ser desastroso. A pesar
de la suposición anterior de que el viejo sistema se puede eliminar, puede haber situaciones en las que se
mantienen ambos sistemas.
10.14 herramientas CASE

La primera etapa del desarrollo del sistema de base de datos Planning- ciclo de vida-base de datos también puede implicar
la selección de herramientas adecuadas Computer-Aided Software Engineering (CASE). En su sentido más amplio, CASE
se puede aplicar a cualquier herramienta que apoya el desarrollo de software. herramientas de productividad adecuados son
necesarios para el personal de administración de datos y administración de base de datos para permitir las actividades de
desarrollo de base de datos para llevar a cabo la manera más eficiente y efectiva posible. apoyo CASE puede incluir:
• un diccionario de datos para almacenar información sobre los datos del sistema de base de datos;
• herramientas de diseño para apoyar el análisis de datos;
• herramientas para permitir el desarrollo del modelo de datos corporativo, y los modelos de datos conceptuales y
lógicos;
• herramientas que permitan a la creación de prototipos de aplicaciones.
herramientas CASE se pueden dividir en tres categorías: mayúsculas, minúsculas, e integrado de los casos, como se
ilustra en la figura 10.6. Mayúsculas herramientas de apoyo a las etapas iniciales de la base de datos del sistema de
ciclo de vida de desarrollo, desde la planificación hasta el diseño de base de datos. Minúscula herramientas de apoyo a
las últimas etapas del ciclo de vida, desde la aplicación a través de pruebas, al mantenimiento operativo. Integrado-CASE
herramientas de apoyo a todas las etapas del ciclo de vida y por lo tanto proporcionan la funcionalidad tanto de mayúsculas y minúsculas en
una sola herramienta.
beneficios de Caso
El uso de herramientas CASE apropiadas se aumentaría la productividad de desarrollar un sistema de base

de datos. Utilizamos el término “productividad” para referirse tanto a la eficiencia del proceso de desarrollo y la
eficacia del sistema desarrollado.
M10_CONN3067_06_SE_C10.indd 370 06/10/14 16:30

10.14 Herramientas CASE | 371
Figura 10.6 Aplicación de herramientas CASE.
Eficiencia se refiere al costo, en términos de tiempo y dinero, de la realización del sistema de base de datos. herramientas
CASE tienen como objetivo apoyar y automatizar las tareas de desarrollo y por lo tanto mejorar la eficiencia. Eficacia se
refiere al grado en que el sistema satisface las necesidades de información de sus usuarios. En la búsqueda de una mayor
productividad, aumentando la eficacia del proceso de desarrollo puede ser incluso más importante que el aumento de su
eficiencia. Por ejemplo, no sería sensato para desarrollar un sistema de base de datos extremadamente eficiente sin que el
producto final no es lo que los usuarios quieren. De esta manera, la eficacia está relacionada con la calidad del producto
final. Dado que los equipos son mejores que los seres humanos en determinadas tareas, por ejemplo, de consistencia
herramientas de comprobación-CASE se pueden utilizar para aumentar la eficacia de algunas tareas en el proceso de
desarrollo.
herramientas CASE proporcionan los siguientes beneficios que mejoran la productividad:
• normas: herramientas CASE ayudan a hacer cumplir las normas en un proyecto de software o en toda la
organización. Estimulan la producción de prueba estándar
M10_CONN3067_06_SE_C10.indd 371 06/10/14 16:30

componentes que se pueden reutilizar, lo que simplifica el mantenimiento y el aumento de la productividad.
• Integración: herramientas CASE almacenar toda la información generada en un repositorio, o diccionario de datos. Por
lo tanto, debería ser posible almacenar los datos recogidos durante todas las etapas del ciclo de vida de desarrollo del
sistema de base de datos. Los datos pueden ser unidos entre sí para asegurar que todas las partes del sistema están
integrados. De esta manera, el sistema de información de una organización ya no tiene que consistir en componentes
independientes, no conectados.
• Soporte para métodos estándar: técnicas estructuradas hacen un uso significativo de diagramas, que son difíciles
de elaborar y mantener manualmente. herramientas CASE simplificar este proceso, lo que resulta en la
documentación que es correcto y más actual.
• Consistencia: Debido a que toda la información en el diccionario de datos está interrelacionado, herramientas CASE pueden
comprobar su consistencia.
• Automatización: Algunas herramientas CASE pueden transformar automáticamente las partes de un diseño ficación speci-
en código ejecutable. Esta característica reduce el trabajo requerido para producir el sistema implantado, y puede eliminar
los errores que surgen durante el proceso de codificación.
Resumen del capítulo
• Un sistema de informacion es los recursos que permitan la recogida, gestión, control y difusión de la información en toda la
organización.
• Un sistema de información basado en computadora incluye los siguientes componentes: de bases de datos, software de base de datos, software de aplicaciones,
hardware (incluyendo medios de almacenamiento), y el personal de usar y desarrollar el sistema.
• La base de datos es un componente fundamental de un sistema de información, y su desarrollo y su uso debe ser vista desde la perspectiva de los
requisitos más amplios de la organización. Por lo tanto, el ciclo de vida de un sistema de información de la organización está inherentemente vinculada al
ciclo de vida de la base de datos que lo soporta.
• Las principales etapas del la base de datos del ciclo de vida de desarrollo de sistemas incluyen: planificación de la base de datos, definición del sistema, los
requisitos de recogida y el análisis, el diseño de bases de datos, selección de DBMS (opcional), el diseño de aplicaciones, creación de prototipos (opcional), la
implementación, la conversión de datos y la carga, prueba y mantenimiento operativo.
• Base de datos de planificación involucra las actividades de gestión que permiten a las etapas del ciclo de vida de desarrollo del sistema de base de datos que se
dieron cuenta de la forma más eficiente y efectiva posible.
• definición del sistema implica identificar el alcance y los límites del sistema de base de datos y puntos de vista de los usuarios. UNA
Ver usuario define lo que se requiere de un sistema de base de datos desde la perspectiva de un puesto de trabajo en particular (como Gerente o Supervisor) o de
aplicaciones empresariales (tales como el marketing, personal, o el control de existencias).
• recopilación y análisis de requerimientos es el proceso de recolección y análisis de información sobre la parte de la organización que va a ser soportado
por el sistema de base de datos, y utilizar esta información para identificar los requisitos para el nuevo sistema. Hay tres enfoques principales para la
gestión de los requisitos para un sistema de base de datos que tiene múltiples puntos de vista de los usuarios: la centralizado enfoque, el vista la
integración enfoque, y una combinación de ambos enfoques.
• los centralizado enfoque implica la fusión de los requisitos para cada vista de usuario en un único conjunto de requisitos para el nuevo sistema de base de datos. Un
modelo de datos que representa todos los puntos de vista de usuario se crea durante la etapa de diseño de base de datos. En el vista la integración enfoque, los
requisitos para cada vista de usuario se mantienen como listas separadas. Los modelos de datos que representan cada vista de usuario se crean y luego se
fusionaron posteriormente durante la etapa de diseño de base de datos.
M10_CONN3067_06_SE_C10.indd 372 06/10/14 16:30

Preguntas de repaso | 373
• diseño de bases es el proceso de crear un diseño que va a apoyar los objetivos de la declaración de misión y la misión de la empresa para el sistema
de base de datos necesaria. Hay tres fases de diseño de base de datos: diseño conceptual de bases de datos, lógica y física.
• diseño conceptual de bases de datos es el proceso de construcción de un modelo de los datos utilizados en una empresa, independiente de todos consideraciones
físicas.
• diseño de base de datos lógica es el proceso de construcción de un modelo de los datos utilizados en una empresa basada en un modelo de datos específico,
pero independiente de un DBMS particulares y otras consideraciones físicas.
• diseño de base de datos física es el proceso de producción de una descripción de la implementación de la base de datos en el almacenamiento secundario; que
describe las relaciones base, organizaciones de archivos, y los índices utilizados para lograr un acceso eficiente a los datos y todas las restricciones de integridad
asociados y medidas de seguridad.
• la selección DBMS implica la selección de un DBMS adecuados para el sistema de base de datos.
• diseño de aplicaciones implica el diseño de interfaces de usuario y la transacción de diseño, que describe los programas de aplicación que utilizan y procesan la base
de datos. Una base de datos transacción es una acción o conjunto de acciones llevadas a cabo por un único programa de usuario o aplicación, que tenga acceso o
cambia el contenido de la base de datos.
• prototipado implica la construcción de un modelo de trabajo del sistema de base de datos, lo que permite a los diseñadores o usuarios visualizar y evaluar el
sistema.
• Implementación es la realización física de las bases de datos y aplicaciones diseños.
• La conversión de datos y la carga implica la transferencia de los datos existentes en la nueva base de datos y la conversión de todas las aplicaciones existentes
para ejecutar en la nueva base de datos.
• Pruebas es el proceso de ejecución del sistema de base de datos con la intención de encontrar errores.
• mantenimiento operativo es el proceso de seguimiento y mantenimiento del sistema después de la instalación.
• La ingeniería de software asistida por ordenador ( CASE) se aplica a cualquier herramienta que apoya el desarrollo de software y permite que las actividades
de desarrollo de sistema de base de datos para llevar a cabo la manera más eficiente y efectiva posible. herramientas CASE se pueden dividir en tres
categorías: mayúsculas, minúsculas, e integrada caso.
Preguntas de revisión
10.1 Discutir la interdependencia que existe entre las etapas DSDLC.
10.2 ¿Qué entiende por el término “sistema de misión”? ¿Por qué es importante durante el desarrollo del sistema?
10.3 Describir el propósito principal (s) y actividades asociadas con cada etapa del desarrollo del sistema de base de datos
ciclo vital.
10.4 Discutir lo que representa una vista de usuario en el contexto de un sistema de base de datos.
10.5 Discutir los principales enfoques para el diseño de bases de datos. Discutir los contextos en los que cada uno es apropiado.
10.6 Comparar y contrastar las tres fases de diseño de base de datos.
10.7 ¿Cuáles son los principales efectos de modelado de datos e identificar los criterios para un modelo de datos óptima?
10.8 Identificar la etapa (s) en el cual es apropiado para seleccionar un DBMS y describir un método de selección de la “mejor”
DBMS.
10.9 Diseño de la aplicación implica el diseño de transacción y el diseño de interfaz de usuario. Describir las actividades y usos principales
asociado con cada uno.
10.10 Discutir por qué la prueba no puede mostrar la ausencia de fallos, sólo que los fallos de software están presentes.
10.11 ¿Cuál es la diferencia entre el enfoque de la creación de prototipos y sistemas de bases de datos del ciclo de vida de desarrollo?
M10_CONN3067_06_SE_C10.indd 373 06/10/14 16:30

ceremonias
10.12 Asumiremos que ha sido contratada para desarrollar un sistema de base de datos para una biblioteca universitaria. Usted está obligado a utilizar
un enfoque de ciclo de vida de desarrollo de sistemas. Discutir cómo se va a abordar el proyecto. Describir grupos de usuarios que estarán involucrados durante el
análisis de requisitos. ¿Cuáles son los temas clave que necesitan ser contestadas durante la investigación de hechos?
10.13 Describir el proceso de evaluación y selección de un producto DBMS para cada uno de los estudios de casos descritos en
Apéndice B.
10.14 Suponga que usted es un empleado de una empresa de consultoría que se especializa en el análisis, diseño e imple-
mentación de los sistemas de bases de datos. Un cliente ha acercado recientemente a su empresa con el fin de aplicar un sistema de base de datos pero que no
están familiarizados con el proceso de desarrollo. Se le ha asignado la tarea de presentar una visión general de la base de datos del ciclo de vida de desarrollo del
sistema (dsdl) a ellos, la identificación de las principales etapas de este ciclo de vida. Con esta tarea en mente, crear una presentación de diapositivas y / o un informe
corto para el cliente. (El cliente para este ejercicio puede ser cualquiera de los estudios de casos ficticios que figuran en el Apéndice B o alguna empresa real
identificada por usted o su profesor).
10.15 Este ejercicio requiere que el permiso de ganancia de entrevistar a una o más personas encargadas de la Desa-
ción y / o administración de un sistema de base de datos real. Durante la entrevista (s), encontrar la siguiente información:
(una) El enfoque adoptado para desarrollar el sistema de base de datos.
(segundo) ¿Cómo se diferencia el enfoque adoptado o es similar al enfoque dsdl descrito en este capítulo.
(do) ¿Cómo se gestionan los requisitos para los diferentes usuarios (vistas por el usuario) de los sistemas de bases de datos.
(re) Si se utilizó una herramienta CASE para apoyar el desarrollo del sistema de base de datos.
(mi) ¿Cómo se evaluó el producto DBMS y luego seleccionado.

(F) ¿Cómo se controla el sistema de base de datos y mantiene.
M10_CONN3067_06_SE_C10.indd 374 06/10/14 16:30

Capitulo 10 Español PDF

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

Capitulo 10 Español PDF

Cargado por

Copyright:

Formatos disponibles

Capítulo

10 Desarrollo del Sistema de Base de Datos

Objetivos del capítulo

En este capítulo aprenderá:

• Los principales componentes de un sistema de información.

• Los tipos de criterios utilizados para evaluar un DBMS.

• Cómo evaluar y seleccionar un DBMS.

• Los beneficios de Computer-Aided Software Engineering (CASE).

• 80-90% no cumplen con sus objetivos de rendimiento;

• alrededor del 80% se entregan tarde y por encima del presupuesto;

• alrededor de 40% de fracaso o son abandonados;

M10_CONN3067_06_SE_C10.indd 345 06/10/14 16:30

• menos del 25% integrar adecuadamente los objetivos de la empresa y la tecnología;

• solo el 10-20% cumple con todos sus criterios de éxito.

• falta de una especificación de requisitos completa;

• la falta de una metodología de desarrollo apropiado;

desarrollo del sistema de base de datos.

10.1 El Ciclo de Vida de los Sistemas de Información

M10_CONN3067_06_SE_C10.indd 346 06/10/14 16:30

10.2 El Ciclo de Vida de Desarrollo del Sistema de Base de Datos

10.3 Planificación de la base de datos

M10_CONN3067_06_SE_C10.indd 347 06/10/14 16:30

M10_CONN3067_06_SE_C10.indd 348 06/10/14 16:30

Escenario Actividades principales

diseño de bases diseño conceptual, lógico y físico de la base de datos.

la selección de DBMS Selección de un DBMS adecuados para el sistema de base de datos.

M10_CONN3067_06_SE_C10.indd 349 06/10/14 16:30

10.4 Definición del sistema

10.4.1 Vistas de los usuarios

los requisitos para ser dividido en partes manejables.

10.5 Colección requisitos y análisis

M10_CONN3067_06_SE_C10.indd 350 06/10/14 16:30

• una descripción de los datos utilizados o generados;

• los detalles de cómo los datos se va a utilizar o generado;

• cualquier requisito adicional para el nuevo sistema de base de datos.

M10_CONN3067_06_SE_C10.indd 351 06/10/14 16:30

10.5.1 enfoque centralizado

Enfoque 10.5.2 Vista de la integración

M10_CONN3067_06_SE_C10.indd 352 06/10/14 16:30

Figura 10.3 El enfoque centralizado de gestión de usuarios múltiples vistas 1 a 3.

M10_CONN3067_06_SE_C10.indd 353 06/10/14 16:30

Figura 10.4 La vista enfoque de integración de la gestión de usuarios múltiples vistas 1 a 3.

10.6 Diseño de base de datos

M10_CONN3067_06_SE_C10.indd 354 06/10/14 16:30

10.6.1 enfoques para el diseño de base de datos

y entonces la relación entre estas entidades, Propietario privado es propietaria PropertyForRent,

Modelado de datos 10.6.2

M10_CONN3067_06_SE_C10.indd 355 06/10/14 16:30

• la perspectiva de cada usuario de los datos;

• la naturaleza de los datos en sí, independiente de sus representaciones físicas;

• el uso de datos a través de vistas de usuario.

Criterios para modelos de datos

10.6.3 fases de diseño de base de datos

diseño conceptual de bases de datos

Tabla 10.2 Los criterios para producir un modelo de datos óptima.

validez estructural La consistencia con la forma en la empresa define y organiza la información.

Sencillez La facilidad de comprensión por parte de los profesionales de SI y usuarios no técnicos.

Integridad Coherencia con la forma en que la empresa utiliza y gestiona la información.

M10_CONN3067_06_SE_C10.indd 356 06/10/14 16:30

diseño de base de datos lógica

M10_CONN3067_06_SE_C10.indd 357 06/10/14 16:30

diseño de base de datos física

El proceso de producir una descripción de la aplicación de la base de datos en el almacenamiento