REPASO Base de Datos

Introducción a las Bases de Datos
PROF. CINTHYA ACOSTA S.

Introducción
 En una organización existen una gran cantidad de recursos:

humano, financiero, material (tecnológico) y el dato.
 ¿ Por qué el dato se debe considerar un recurso?
 Tiene valor intrínseco.

 Aporta información valiosa al desempeño y a la toma de decisiones .
 Su obtención, almacenamiento y control involucran gastos (inversión).
 ¿Cómo definiríamos el dato?
 Aquel hecho relacionado con personas, objetos, lugares, eventos u otras

entidades del mundo real. A través de un símbolo o de una dupla
<atributo, valor>.
Prof. Cinthya Acosta S.

Introducción
 Entidad  Objeto que se desea representar.
 Atributo  Elemento que describe la entidad o una propiedad de

ella.
 Valor  Medida asociada al atributo.

Dato v/s Información
Dato Información
Recurso importante Datos agrupados y

en la Organización elaborados
Toma de Decisiones

Introducción a las Bases de Datos
 Antes de la existencia de las Bases de Datos, la información

lógica de una organización se guardaba en Archivos,
 Archivo: conjunto de registros de uno o más tipos.

 Registro: instancia (ocurrencia) de un tipo de registro.
 Campo: característica de un tipo de registro.
 Un archivo es:
 Conjunto estructurado/organizado de datos, con un significado, que

representa características de una entidad del mundo real.
 Ejemplo Archivo: Entidad Alumno

Desventajas del Uso de Archivos
 Redundancia de Datos no Controlada

 Se produce frecuentemente con aplicaciones independientes que se
encuentran en las organizaciones.
 Inconsistencia de Datos
 Se produce debido a la descoordinación con la que realizan
operaciones de ingreso, actualización o eliminación en archivos que
presentan información redundante.
 Dificultad para Modificar Estructura Lógica

 Situación que se presenta al momento de querer realizar cambios en
la estructura de un archivo o bien responder a requerimientos de
información.

 Escasa Posibilidad de Compartir Datos
 Cada aplicación tiene sus propios archivos.

 El mismo dato debe ser ingresado varias veces para actualizar los archivos con datos
duplicados.
 Al desarrollar nuevas aplicaciones no es posible a veces, explotar los datos contenidos
en archivos que ya existen:
 Crear nuevos archivos
 Duplicación de datos.
 Baja productividad del programador
 Debe diseñar cada archivo para la aplicación en cuestión pues, normalmente se

trabaja de forma descentralizada.

 Baja Estandarización
 Referente a la definición para nombres, formatos y accesos en el desarrollo de SI.
 Problemas como Sinónimos:
 Uso de nombres diferentes para un mismo ítem de datos.
 Ejemplo: # ESTUDIANTE y ROL ALUMNO
 Problemas como Homónimos:
 Uso de un mismo nombre simple para ítems de datos distintos.
 Ejemplo: Nota (calificación-descripción)
 Esfuerzo de mantención
 Cualquier modificación de archivo incide directamente en la modificación del o los
programas en donde se utiliza.

Enfoque Base de Datos
 Los datos se visualizan como un recurso.

 Este recurso debe ser compartido por todos los usuarios.
 Cada usuario puede contar con una visión de la BD – requerimientos de
información.
 Datos almacenados de tal forma que son independientes del programa que lo usa.
 Control centralizado operaciones a través de Data Base Managment System
(DBMS):
 Protección,
 Ingreso,
 Modificación,
 Eliminación,
 Recuperación

Definición de base de Datos
 Es una colección de archivos relacionados, diseñados de tal

manera que pueden ser accesados por numerosos usuario, a
través de distintos medios.
 Características :
 Representan aspectos del mundo real
 Comprende una colección coherente de datos.
 Un conjunto de datos aleatorios no podría considerarse como una base
de datos.
 Una base de datos se diseña, construye y puebla con datos para un
propósito específico.

Ventajas de las Bases de Datos
 Redundancia Controlada:
 Al integrar los archivos de datos en una sola estructura lógica y
almacenando cada ocurrencia de un ítem de dato en un solo lugar de la
Base de Datos, se reduce la redundancia.
 Toda redundancia puede ser eliminada, pero algunas veces existen
razones válidas para almacenar múltiples copias del mismo dato.
 En un sistema de Base de Datos la redundancia es controlada.

 Consistencia de Datos:
 Controlada la redundancia de datos, se reduce la inconsistencia.
 Al almacenarse un dato en un solo lugar, las actualizaciones no producen
inconsistencia.
 Si existe redundancia controlada, el enfoque de BD se preocupa que al
producirse una actualización, se realicen las modificaciones en todos los
registros donde esté el dato.

 Integración de Datos:
 En una BD, los datos se organizan de una manera lógica que permite
definir las relaciones entre ellos.
 Un usuario puede relacionar un dato con otro, por ejemplo, para un
determinado producto un usuario puede determinar que materias
primas son requeridas para fabricarlo y también asociar a las materias
primas los proveedores que las venden.
 Los sistemas de Base de Datos tienen la función de asociar lógicamente
datos relacionados.

 Compartir Datos:
 Una BD es creada para ser compartida por todos los usuarios que
requieran de sus datos.
 Muchos sistemas de BD permiten a múltiples usuarios compartir la BD
en forma concurrente, aunque bajo ciertas restricciones.
 Bajo este enfoque, cada unidad funcional tiene su visión de la BD, se
simplifica el compartir datos.
 A cada usuario se le puede asignar una vista precisa de los datos
requeridos para tomar sus decisiones.
 No necesita conocer toda la Base de Datos.

 Esfuerzo por Estandarización:

 Establecer la función del DBA es una parte importante de este enfoque.
 El objetivo es tener la autoridad para definir y fijar los estándares de los
datos, así como también posteriores cambios de estándares.
 Facilitar el Desarrollo de Aplicaciones:

 Se reduce el costo y tiempo para desarrollar nuevas aplicaciones.
 El programador no necesita efectuar las tareas de diseño, construcción y
mantención de archivos maestros.

 Controles de Seguridad, Privacidad e Integridad:

 El DBA es responsable por establecer controles de acceso para proteger
los datos.
 El control centralizado que se ejerce bajo este enfoque puede mejorar la
protección de datos en comparación con archivos tradicionales.
 Si no se aplican los controles pertinentes, una BD puede ser más
vulnerable que los archivos tradicionales dado que una gran cantidad de
usuarios están compartiendo un recurso común.

 Flexibilidad en el Acceso:
 Este enfoque provee múltiples trayectorias de recuperación de cada ítem
de dato, permitiendo a un usuario mayor flexibilidad para ubicar datos
que en archivos tradicionales.
 Es posible satisfacer ciertos requerimientos ad-hoc sin necesidad de un
programa de aplicación, a través de lenguajes de consulta orientados al
usuario (query language) o de generadores de reportes (report writer)
que proveen los DBMS.

 Independencia de la Datos:
 Se refiere a la separación de las descripciones de datos de los programas
de aplicaciones que usan esos datos.
 Permitiendo cambiar la organización de los datos sin necesidad de
alterar los programas de aplicación que procesan los datos.

 Reducción de la Mantención de Programas:

 Los datos almacenados deben ser cambiados frecuentemente por
diversas razones; se agregan nuevos datos, se cambian formatos de los
datos, aparecen nuevos dispositivos de almacenamiento o métodos de
acceso, etc.
 En archivos tradicionales, estos cambios generan modificación a los
programas de aplicación.
 En sistemas de BD, los datos son independientes de los programas,
reduciendo la necesidad de modificar (mantener) los programas.

Proceso de Diseño de Base de Datos
Etapas del proceso:
Primera Etapa: Análisis y Recolección de Requerimientos
Objetivo: Identificar las necesidades de información de los usuarios.
Pasos:
a) Identificación de las áreas de aplicación y grupos de usuarios.
b) Análisis y estudio de la documentación existente en las actuales aplicaciones.
Además considerar manuales de políticas, formas, reportes y diagramas
organizacionales.

Primera Etapa: Análisis y Recolección de Requerimientos
Pasos:
c) Estado del actual ambiente operativo y uso de la información. Incluye un
análisis de los tipos de transacciones y sus frecuencias, y el flujo de
información en el sistema.
d) Respuestas de cuestionarios son obtenidas desde los potenciales usuarios.
Identificación de prioridades.

Segunda Etapa: Diseño Conceptual
Objetivo: Producir un esquema conceptual que represente los datos necesarios

para el sistema de información, que sea independiente del sistema administrador
de base de datos a utilizar.
Pasos:
a) Diseño del Esquema Conceptual: Generación de un modelo de datos
con características de ser expresivo, simple, mínimo, formal, diagramático.
• Técnica Top-Down: El diseñador comienza con el modelo de la

organización y agrega detalles a ese modelo hasta alcanzar un diseño
conceptual satisfactorio.
• Técnica Bottom-Up : Aquí el analista realiza un análisis detallado, por
separado, de los requerimientos y modelos de cada vista de usuario.
Para formar un esquema conceptual.

Segunda Etapa: Diseño Conceptual
Pasos:
b) Diseño de las transacciones: Identificar Entradas-Proceso-
Salidas. Transacciones de recuperación, de actualización y
mixtas.
En ambos casos, el Esquema Conceptual obtenido debe servir para:

• Medio de Comunicación entre usuarios y especialistas.
• Mecanismos para validar entendimiento alcanzado del problema, por
parte del especialista (analista del sistema).
• Descripción estable del contenido.

Tercera Etapa: Elección del Software
Objetivo: Seleccionar aquel tipo de software que mejor se adecué a las necesidades
del sistema a construir.
Pasos:
a) Costos: adquisición de software, mantención, adquisición del hardware,

migración, personal capacitado, entrenamiento, operación del software.
b) Cambio de Software (de existir otro actualmente): complejidad de
los datos, compartición de datos entre aplicaciones, dinámica de los datos,
frecuencia de los requerimientos, volumen de datos.
c) Factores organizacionales y económicos: estructura de los datos,
familiaridad del personal, soporte del vendedor del software, características
de lenguajes de cuarta generación (como editores de texto, generadores de
reporte, browsers, software de comunicación y herramientas gráfica.

Cuarta Etapa: Diseño Lógico
Objetivo: Crear un esquema conceptual basado en el modelo de datos soportado

por el software escogido.
Pasos:
a) Transformación independiente del sistema, a un modelo relacional,

orientado al objeto u otro.
b) Conversión de los esquemas a un software de base de datos específico.

Quinta Etapa: Diseño Físico
Objetivo: Escoger las estructuras de almacenamiento y métodos de acceso y la

ubicación de los archivos de base de datos para obtener un buen rendimiento de
las distintas aplicaciones que interactúan con la base de datos.
Criterios:
• Tiempo de Respuesta: es el tiempo que transcurre desde el ingreso de la

transacción y el recibo de su respuesta.
• Utilización del espacio en disco: cantidad de memoria secundaria
ocupada por los archivos y los índices.
• Rendimiento de la transacción: numero promedio de transacciones que
pueden ser procesadas por minutos.

Sexta Etapa: Implementación
Objetivo: Codificación de sentencias para la definición y la manipulación

de la base de datos, para crear los archivos y su poblamiento.

Modelamiento de Datos Conceptual
 Es el segundo paso del proceso de desarrollo de base de datos.
 Su objetivo es desarrollar un Modelo Entidad – Relación que

represente los requerimientos de información del negocio.
 El modelamiento de datos conceptual es independiente del

hardware o software a usar para la implementación. Un
Modelo ER puede ser mapeado a una base de datos relacional,
jerárquica o de redes.

Modelo Entidad – Relación (ER)
 Nomenclatura Gráfica del Modelo – Representación de Objetos

 En el modelo ER se utiliza el concepto de “entidad” para referenciar al
concepto de objeto.
 Un tipo de entidad permite denotar tipos de objetos y se representan con un

rectángulo nominado.
Nombre- Entidad

 Nomenclatura Gráfica del Modelo – Representación de Relaciones
 Los objetos del mundo real se relacionan entre sí, siendo también
interesante modelar estas asociaciones; para ello se utilizan los tipos de
relaciones, o simplemente relaciones.
 En el modelo ER, una relación se representa por un rombo nominado unido

con un arco a cada una de las entidades que representan los objetos
relacionados.
ALUMNO tiene ASIGNATURA

 Nomenclatura Gráfica del Modelo – Representación de Relaciones
 El “grado” de una relación es el número de entidades, no necesariamente

distintas, que participan en la relación. En función del grado se habla de
relaciones binarias, ternarias, etc.

 Nomenclatura Gráfica del Modelo – Representación de Atributos
 Los atributos se representan mediante elipses nominados unidos con un

arco a la entidad o a la relación que describen.
Nombre
Rut
PERSONA
Dirección
Teléfono

 Nomenclatura Gráfica del Modelo – Representación de Atributos
Los atributos se pueden clasificar según varios criterios:
Desde el punto de vista de su estructura

 Simples o escalares: toman valores indivisibles.
 Compuestos o estructurados: los valores que toma el atributo se componen de otros

valores (que pueden ser de cualquier tipo). En estos casos se representa uniendo con
arcos la elipse que representa un atributo compuesto con las elipses que representan
sus atributos componentes.
número
cod_ciudad
fono
PROVEEDOR cod_país
Rut_prov

 Nomenclatura Gráfica del Modelo – Cardinalidad
 Se les denomina restricciones de cardinalidad. Estas son las restricciones

más importantes sobre las relaciones. Las relaciones de cardinalidad que el
modelo de ER permite expresar:
 Cardinalidad Mínima: solo se puede expresar la cardinalidad mínima de cada

entidad respecto a la relación. Esta puede ser 0 o 1, representando esta última la
“relación de existencia” . Está relación de existencia se representa con una doble
línea en el arco que une la relación con la entidad.
 Cardinalidad Máxima: sólo se puede expresar la cardinalidad máxima de cada
conjunto de n-1 entidades respecto a la relación. Esta cardinalidad se indica
mediante una etiqueta con el valor de la cardinalidad en el arco que une la entidad.
1 N
PROFESOR inscribe PARALELO

 Nomenclatura Gráfica del Modelo – Categorización
 Categorización: Proceso por el que varias clases de naturaleza

distinta se agrupan en una nueva clase.
 La clase resultante de la categorización es la categoría.
 Diferencias con la generalización:
 No todas las ocurrencias de las clases tienen que pertenecer a la
categoría.
 Herencia selectiva de atributos.

 Nomenclatura Gráfica del Modelo – Categorización
PROPETARIO
PERSONA BANCO EMPRESA

 Nomenclatura Gráfica del Modelo – Generalización
 Esta se representa uniendo todas las entidades especializadas según un

criterio con la entidad general a través de un circulo en el que se indican las
propiedades (O= overwide, D = disjunta, y S = Solapada). En el caso que
haya una sola subclase no hace falta el circulo.
EMPLEADO
SECRETARIA TECNICO INGENIERO

Transformación Modelo ER a Relacional
Tres reglas básicas
 Las tres reglas básicas para convertir un esquema en el modelo

E/R al relacional son las siguientes:
1) Todo tipo de entidad se convierte en una relación.
2) Todo tipo de relación M:M (muchos a muchos) se transforma en una

relación.
3) Para todo tipo de relación 1:M se realiza lo que se denomina

propagación de clave (regla general), o se crea una nueva relación.

Reglas detalladas de Transformación
 Transformación de Entidades
 Cada tipo de entidad se convierte en una tabla.
 La tabla se llamará igual que el tipo de entidad de donde proviene.
 Transformación de Atributos de Entidades

 Cada atributo de una entidad se transforma en una columna de la tabla a la
que ha dado lugar la entidad.
 Teniendo en cuenta que existen atributos identificador principal, otros que
son identificadores alternativos (únicos) y el resto de los atributos que no
son identificadores – atributos no principales-.
 Esta regla se divide en subreglas.


 Atributos Identificadores
 Los atributos que son identificadores principales pasan a formar la clave
primaria de la tabla.
 Atributos Identificadores Alternativos

 Se les denomina mediante un cláusula denomina UNIQUE.
 Atributos No Identificadores
 Se representan solo como columnas de la tabla correspondiente.


 Atributos Multivaluados
 Puesto que el modelo relacional no permite dominios multivaluados, deberá
crearse una nueva tabla cuyos únicos atributos ( y clave primaria ) será la
concatenación de la clave primaria de la entidad original y el atributo
multivaluado.
 Además, se debe crear una clave ajena referenciado a la tabla primaria.

número
FONO
fono cod_ciudad
rut_prov
PROVEEDOR 1
PROVEEDOR
cod_país rut_prov cod_país
Rut_prov N
cod_ciudad

 Transformación de relaciones M:M
 Un tipo de relación M:M se transforma en una tabla que tendrá como clave
primaria la concatenación de las claves primarias (CP) de los tipos de
entidades que asocia.
 Además, cada uno de los atributos que forman la clave primaria de esta tabla
también son claves ajenas que referencian a las tablas en que se han
convertido las entidades relacionadas (claves primarias).
M
FACTURA detalle PRODUCTO
N
nro_factura cantidad subtotal nro_producto

 Transformación de relaciones M:M
DETALLE
nro_factura
FACTURA 1 PRODUCTO
1
nro_producto
nro_factura nro_producto
N N
cantidad
subtotal

 Transformación de relaciones 1:N
 Por cada asociación binaria 1:N (no débil) identificar la relación S que está en el lado
de la cardinalidad N, he incluirle como clave foránea, la clave primaria de la entidad
con cardinalidad 1.
 Incluir cada atributo simple de la asociación como atributo de S.
M
PRODUCTO vendio PROVEEDOR
1
nro_producto rut_prov
precio

 Transformación de relaciones 1:N
PRODUCTO
nro_producto
1 PROVEEDOR
precio
rut_proveedor
N
rut_proveedor

 Transformación de relaciones 1:1
 Para cada asociación binaria 1:1, identificar las relaciones del modelo relacional
correspondiente ; escoger una de las relaciones e incluir su clave primaria como
foránea en la otra relación.
1
CIUDAD tiene FARMACEUTICO
1
nombre rut_farmaceutico

 Transformación de relaciones 1:1
CIUDAD
1 FARMACEUTICO
Nombre
rut_farmaceutico
1
rut_farmaceutico

 Transformación de Generalización (tipos y subtipos)

 Existen tres soluciones de transformación al modelo relacional:
a) Englobar todos los atributos de la entidad y sus subtipos en una sola tabla. En
general, se debe adoptar esta solución cuando los subtipos se diferencien en
muy pocos atributos y las relaciones que los asocian con el resto de las
entidades del esquema sean las mismas para todos (o casi todos) los subtipos.
b) Crear una tabla para el supertipo y tantas tablas como subtipos haya, con sus
atributos correspondientes. Esta es la solución adecuada cuando existen
muchos atributos distintos entre los subtipos y se quieren mantener de todas
maneras los atributos comunes a todos ellos en una tabla.
c) Considerar tablas distintas para cada subtipo, que contengan, además de los
atributos propios, los atributos comunes. Se elegirá esta opción cuando se den
las mismas condiciones anteriores.

PROFESOR
DOCTOR NO DOCTOR

 Opción
a) PROFESOR (Cod_prof, nombre, ….., tipo, Año_doc, Materia_doc,..)
b) PROFESOR (Cod_prof, Nombre, ….)

DOCTOR (Cod_prof, …… )
NO_DOCTOR (Cod_prof, …..)
c) DOCTOR (Cod_prof, Nombre, ……, Año_doc, ….)

NO_DOCTOR ( Cod_prof, Nombre, ……)

Ejercicios
 Una base de datos para una pequeña empresa debe contener información acerca de clientes, artículos y
pedidos. Hasta el momento se registran los siguientes datos en documentos varios:
 Para cada cliente: Número de cliente (único), Direcciones de envío (varias por cliente), Saldo,
Límite de crédito (depende del cliente, pero en ningún caso debe superar los 3.000.000 pts),
Descuento.
 Para cada artículo: Número de artículo (único), Fábricas que lo distribuyen, Existencias de ese
artículo en cada fábrica, Descripción del artículo.
 Para cada pedido: Cada pedido tiene una cabecera y el cuerpo del pedido. La cabecera está
formada por el número de cliente, dirección de envío y fecha del pedido. El cuerpo del pedido son
varias líneas, en cada línea se especifican el número del artículo pedido y la cantidad. Además, se
ha determinado que se debe almacenar la información de las fábricas. Sin embargo, dado el uso de
distribuidores, se usará: Número de la fábrica (único) y Teléfono de contacto. Y se desean ver
cuántos artículos (en total) provee la fábrica. También, por información estratégica, se podría
incluir información de fábricas alternativas respecto de las que ya fabrican artículos para esta
empresa.
 Nota: Una dirección se entenderá como Nº, Calle, Comuna y Ciudad. Una fecha incluye hora.
 Se pide hacer el diagrama ER para la base de datos que represente esta información.

Ejercicios
 Sistema de ventas
 Le contratan para hacer una BD que permita apoyar la gestión de un sistema de
ventas. La empresa necesita llevar un control de proveedores, clientes, productos
y ventas.
 Un proveedor tiene un RUT, nombre, dirección, teléfono y página web. Un cliente
también tiene RUT, nombre, dirección, pero puede tener varios teléfonos de
contacto. La dirección se entiende por calle, número, comuna y ciudad.
 Un producto tiene un id único, nombre, precio actual, stock y nombre del
proveedor. Además se
 organizan en categorías, y cada producto va sólo en una categoría. Una categoría
tiene id, nombre y descripción.
 Por razones de contabilidad, se debe registrar la información de cada venta con
un id, fecha, cliente, descuento y monto final. Además se debe guardar el precio
al momento de la venta, la cantidad vendida y el monto total por el producto.

Ejercicios
En un campeonato mundial de carreras de fórmula 1, es posible identificar los siguientes

hechos y eventos:
Los pilotos firman contratos para correr durante una temporada (un año) en los
autos de una escudería. Por ésta pueden firmar contrato varios pilotos. La escudería debe
tener al menos un piloto y debe pertenecer a un país, del cual es representante; notar que
cada país puede tener varias escuderías.
Para poder participar en una carrera, los automóviles deben estar inscritos en una
escudería para poder participar. Estos son asignados a los pilotos para una carrera en
particular, dependiendo si están disponibles técnicamente. Un piloto puede usar sólo un
automóvil durante una carrera. La participación de una piloto, en una carrera exige que se le
tenga asignado un automóvil para participar en ella.
En una temporada se realizan muchas carreras en circuitos existentes en los
distintos países. En un mismo circuito pueden desarrollarse varias carreras (en una misma o
distintas temporadas). Además, un circuito puede estar en reparaciones y no tener carreras
programadas.
Plantear el modelo conceptual correspondiente.

REPASO Base de Datos

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

REPASO Base de Datos

Enviado por

Direitos autorais:

Formatos disponíveis

Introducción a las Bases de Datos

PROF. CINTHYA ACOSTA S.

 En una organización existen una gran cantidad de recursos:

 ¿ Por qué el dato se debe considerar un recurso?

 Tiene valor intrínseco.

 ¿Cómo definiríamos el dato?

 Aquel hecho relacionado con personas, objetos, lugares, eventos u otras

Prof. Cinthya Acosta S.

 Entidad  Objeto que se desea representar.

 Atributo  Elemento que describe la entidad o una propiedad de

Prof. Cinthya Acosta S.

Recurso importante Datos agrupados y

Prof. Cinthya Acosta S.

 Antes de la existencia de las Bases de Datos, la información

 Archivo: conjunto de registros de uno o más tipos.

 Conjunto estructurado/organizado de datos, con un significado, que

 Ejemplo Archivo: Entidad Alumno

Prof. Cinthya Acosta S.

 Redundancia de Datos no Controlada

 Dificultad para Modificar Estructura Lógica

Prof. Cinthya Acosta S.

 Escasa Posibilidad de Compartir Datos

 Cada aplicación tiene sus propios archivos.

 Baja productividad del programador

 Debe diseñar cada archivo para la aplicación en cuestión pues, normalmente se

Prof. Cinthya Acosta S.

Prof. Cinthya Acosta S.

 Los datos se visualizan como un recurso.

Prof. Cinthya Acosta S.

 Es una colección de archivos relacionados, diseñados de tal

Prof. Cinthya Acosta S.

Prof. Cinthya Acosta S.

Prof. Cinthya Acosta S.

Prof. Cinthya Acosta S.

Prof. Cinthya Acosta S.

 Esfuerzo por Estandarización:

 Facilitar el Desarrollo de Aplicaciones:

Prof. Cinthya Acosta S.

 Controles de Seguridad, Privacidad e Integridad:

Prof. Cinthya Acosta S.

Prof. Cinthya Acosta S.

Prof. Cinthya Acosta S.

 Reducción de la Mantención de Programas:

Prof. Cinthya Acosta S.

Etapas del proceso:

Primera Etapa: Análisis y Recolección de Requerimientos

Objetivo: Identificar las necesidades de información de los usuarios.

Prof. Cinthya Acosta S.

Primera Etapa: Análisis y Recolección de Requerimientos

Prof. Cinthya Acosta S.

Segunda Etapa: Diseño Conceptual

Objetivo: Producir un esquema conceptual que represente los datos necesarios

• Técnica Top-Down: El diseñador comienza con el modelo de la

Prof. Cinthya Acosta S.

Segunda Etapa: Diseño Conceptual

En ambos casos, el Esquema Conceptual obtenido debe servir para:

Prof. Cinthya Acosta S.

Tercera Etapa: Elección del Software

a) Costos: adquisición de software, mantención, adquisición del hardware,

Prof. Cinthya Acosta S.

Cuarta Etapa: Diseño Lógico

Objetivo: Crear un esquema conceptual basado en el modelo de datos soportado

a) Transformación independiente del sistema, a un modelo relacional,

Prof. Cinthya Acosta S.