Valores Venezolanos

Bases relacionales son aquellas bases de datos que usan el modelo relacional para guardar la información. El modelo relacional es en el que, cada tabla de la base de datos representa una entidad para persistir, y el modo en el que se relacionan esas entidades se expresa a base de importar las llaves primarias entre las tablas (es decir, crear relaciones). De ahí el nombre. Básicamente el concepto es la forma lógica en la que la base de datos almacena la información: existe también el modelo jerárquico (el de árboles e índices) y el orientado a objetos (que es parecido al relacional pero soportan algunos conceptos de la orientación a objetos como herencia de tablas).

Las bases distribuidas son aquellas con las que puedes formar clústeres (o granjas). Es decir, varios equipos que almacenan la misma información y los cambios que sucedan en una de las bases de datos, la misma base de datos lo refleja en los otros nodos del clúster. Esto es independiente a si es relacional, jerárquica u orientada a objetos, las bases distribuidas solo implican que puedas hacer distribución de datos.

BASES DE DATOS RELACIONALES

OBJETIVO PRIMARIO: Independencia de datos.

DATOS SOLAMENTE: la base de datos almacena datos solamente.

COMPARTIMIENTO DE DATOS: los datos pueden ser compartidos por cualquier proceso. Los datos son diseñados para cualquier tipo de uso.

DATOS PASIVOS: los datos son pasivos. Ciertas operaciones limitadas pueden ser automáticamente disparadas (triggers) cuando los datos son usados.

CAMBIO CONSTANTE: los procesos que usan los datos cambian constantemente.

INDEPENDENCIA DE DATOS: los datos pueden ser físicamente reorganizados sin afectar como ellos son usados.

SIMPLICIDAD: los usuarios perciben los datos como columnas, filas y tablas.

TABLAS SEPARADAS: cada relación (tabla) está separada. Los comandos JOIN relacionan datos de tablas separadas.

DATOS NO REDUNDANTES: La normalización de datos es hecha para ayudar a eliminar la redundancia de datos (No ayuda en la redundancia en el desarrollo de las aplicaciones)

BASES DE DATOS ORIENTADOS A OBJETOS

OBJETIVOS PRIMARIOS: encapsulación, independencia de clase.

DATOS MÁS MÉTODOS: la base de datos almacena datos más métodos

ENCAPSULACIÓN: los datos pueden ser usados solo por los métodos de las clases. Los datos son diseñados para ser usados mediante métodos específicos solamente.

OBJETOS ACTIVOS: los objetos son activos. Las solicitudes causan que los objetos ejecuten sus métodos. Algunos métodos pueden ser altamente complejos, por ejemplo aquellos que usan reglas y un motor de inferencia.

CLASES DISEÑADAS PARA EL REUSO: las clases diseñadas para una alta reusabilidad raramente cambian.

INDEPENDENCIA DE CLASE: las clases pueden ser reorganizadas sin afectar como ellas son usadas.

COMPLEJIDAD: la estructura de los datos pueden ser complejos. Los usuarios desconocen la complejidad debido a la encapsulación.

DATOS ENTRELAZADOS: los datos pueden ser entrelazados de modo que los métodos de las clases consigan

Los diagramas de casos de uso documentan el comportamiento de un sistema desde el punto

de vista del usuario. Por lo tanto los casos de uso determinan los requisitos funcionales del

sistema, es decir, representan las funciones que un sistema puede ejecutar.

Su ventaja principal es la facilidad para interpretarlos, lo que hace que sean especialmente

útiles en la comunicación con el cliente

1. Capitulo I II CASOS DE USO Los casos de uso son un fenómeno interesante, durante mucho tiempo, tanto en el desarrollo orientado a objeto como en el tradicional, las personas se auxiliaban de escenarios típicos que le ayudaban a entender los requerimientos. Sin embargo, estos, se trataban de modo muy informal; siempre se construían, pero pocas veces se documentaban.

2. Capitulo I II CASOS DE USO ¿Qué es un caso de uso? Un caso de uso es, en esencia, una interacción típica entre un usuario y un sistema de cómputo. El caso de uso capta alguna función visible para el usuario. El caso de uso puede ser pequeño o grande. El caso de uso logra un objetivo discreto para el usuario.

3. Capitulo I II CASOS DE USO (Modelo USE CASE) Este modelo traduce las necesidades del usuario en un modelo fácil de comprender. El usuario puede ser un individuo o un sistema externo, y se conoce como ACTOR . De esta manera el modelo Use Case es una representación de cómo el sistema, o parte del sistema, trabaja desde el punto de vista del actor.

4. Capitulo I II CASOS DE USO Casos de Uso es una técnica para capturar información de cómo un sistema o negocio trabaja actualmente, o de cómo se desea que trabaje No pertenece realmente al enfoque orientado a objetos, más bien es una técnica para el modelado de escenarios en los cuales el sistema debe operar

5. Capitulo I II CASOS DE USO (Diagramas de Casos de Uso) Cada Caso de Uso puede estar definido por: texto que lo describe secuencia de pasos ejecutados dentro del escenario condiciones pre-post para que el escenario comience o termine mezclando las anteriores Un Caso de Uso es representado por una elipse y describe una situación de uso del sistema interactuando con actores Un actor es un agente, alguien o algo que solicita un servicio al sistema o actúa como catalizador para que ocurra algo

6. Capitulo I II CASOS DE USO Un caso de uso ofrece una vista estática de las relaciones entre diferentes casos de uso y actores. Un caso de uso se representa en UML como un óvalo: En UML, cada caso de uso debe tener al menos un actor. Esta forma de ver el sistema nos ayuda a concebirlo como un todo. En UML, un actor se representa con AgregarDocente

7. Capitulo I II CASOS DE USO (Actores) Un actor representa un conjunto coherente de roles que los usuarios de los casos de uso juegan al interactuar con estos. Los actores se deteminan observando: Usuarios directos del sistema Responsables del uso o mantenimiento del sistema Otros sistemas que interactúan con el sistema en cuestión La misma persona física puede interpretar varios papeles como actores distintos El nombre del actor describe

...