PLANIFICACIÓN DE SISTEMAS:TÉCNICAS Y PROCEDIMIENTOS

PARA MODELO E/RIntegrantes:

Jorge Ng CI:25.492.631Eder Perozo CI:20.458.782

Profesora: Ing. Carla V. Leal C. MSc.

REPÚBLICA BOLIVARIANA DE VENEZUELAMINISTERIO DEL PODER POPULAR PARA

LAEDUCACIÓN UNIVERSITARIA

INSTITUTO UNIVERSITARIO POLITECNICO “SANTIAGO MARIÑO”

EXTENSIÓN COL-SEDE CIUDAD OJEDA

EntidadRepresenta una “cosa”, "objeto" o "concepto" del mundo real con existencia independiente, es decir, se diferencia únicamente de otro objeto o cosa, incluso siendo del mismo tipo, o una misma entidad.

Algunos Ejemplos:

Una persona. (Se diferencia de cualquier otra persona, incluso siendo gemelos).

Un automóvil. (Aunque sean de la misma marca, el mismo modelo,..., tendrán atributos diferentes, por ejemplo, el número de chasis).

Una casa (Aunque sea exactamente igual a otra, aún se diferenciará en su dirección).

AtributosLos atributos son las características que definen o identifican a una entidad. Estas pueden ser muchas, y el diseñador solo utiliza o implementa las que considere más relevantes.A la colección de entidades «alumnos», con el siguiente conjunto de atributos en común, (id, nombre, edad, semestre), pertenecen las entidades:

(1, Sophia, 15 años, 2)(2, Josefa, 19 años, 5)(3, Carlos, 20 años, 2)

RelaciónDescribe cierta dependencia entre entidades o permite la asociación de las mismas.Si tenemos dos entidades, CLIENTE y HABITACIÓN, podemos entender la relación entre ambas al tomar un caso concreto (ocurrencia) de cada una de ellas. Entonces, podríamos tener la ocurrencia Habitación 502, de la entidad HABITACIÓN y la ocurrencia Henry Johnson McFly Bogard, de la entidad CLIENTE, entre las que es posible relacionar que la habitación 502 se encuentra ocupada por el huésped de nombre Henry Johnson McFly Bogard.

DatoEs una unidad mínima o ítem aislado que por si solo no significa nada, es la unidad mínima semántica

Modelo conceptual especifico de datos

Es un conjunto de conceptos que pueden servir para describir la estructura de una Base de Datos; tipo de datos, las relaciones y que deben cumplirse para esos datos. Por lo general los modelos de datos contienen además un conjunto de operaciones básicas para especificar lecturas y actualizaciones de la base de datos. Son modelos de datos de muy alto nivelEn general se concentran en las estructuras y restricciones de integridad Suelen tener una representación gráfica asociada

Ejemplos: Modelo Entidad-Relación (1976)Modelo ER Extendidos (80’s y 90’s)

Modelo entidad-relacion Es una herramienta para el modelado de datos que permite representar las entidades relevantes de un sistema de información así como sus interrelaciones y propiedades.El modelado de datos no acaba con el uso de esta técnica. Son necesarias otras técnicas para lograr un modelo directamente implementable en una base de datos. Brevemente: permite mostrar resultados entre otras entidades pertenecientes a las existentes de manera que se encuentre la normatividad de archivos que se almacenarán

Transformación de relaciones múltiples en binarias.Normalización de una base de datos de relaciones (algunas relaciones pueden transformarse en atributos y viceversa).Conversión en tablas (en caso de utilizar una base de datos relacional).

Ejemplo de modelo entidad relacion

ComposiciónSi bien las Bases de Datos no son todas iguales, podemos nombrar algunos componentes comunes:

Tablas: comprende definición de tablas, campos, relaciones e índices. Es el componente principal de las Bases de Datos Relacionales.

Formularios: se utilizan principalmente para actualizar datos.

Consultas: se utilizan para ver, modificar y analizar datos.

Informes: se utilizan para presentar los datos en formato impreso.

Macros: conjunto de instrucciones para realizar una operación determinada.

Tipos de asociaciónUn modelo de datos debe especificar las asociaciones existentes entre las entidades. Estas asociaciones son las relaciones entre entidades. Por ejemplo, la frase "los clientes compran productos" nos dice que hay dos entidades, "Clientes" y "Productos", que están relacionadas por "comprar".

La gran mayoría de las asociaciones son binarias, como "los clientes compran productos" o "los empleados venden productos". Entre las dos hay una asociación ternaria implícita: "los empleados venden productos a los clientes". Con las dos asociaciones binarias independientemente no podríamos saber a qué clientes se han vendido los productos que ha vendido un cierto empleado: en este caso necesitamos de la asociación ternaria.

Las asociaciones entre dos entidades cualesquiera pueden ser de tres tipos: uno-a-uno, uno-a-muchos y muchos-a-muchos.

Asociaciones uno-a-uno: Si es cierto que cualquier ejemplar de la entidad X se puede asociar con tan sólo un ejemplar de la entidad Y, entonces decimos que la asociación es uno-a-uno. Cuando elegimos una asociación uno-a-uno debemos asegurarnos de que o bien se mantiene la asociación en todo momento, o en caso de que cambie no nos interesan los valores pasados.

Por ejemplo: si asumimos que en los despachos de un edificio hay uno por persona, entonces la asociación será uno-a-uno. Pero esta asociación sólo es cierta en un momento dado. A lo largo del tiempo, se irán asignando diferentes empleados en el edificio. Habrá que valorar si el mantenimiento de esta información es útil en nuestro modelo o no.

Asociaciones uno-a-muchos: Es el tipo de asociación más común, donde un solo ejemplar de una entidad se puede asociar con cero, uno o muchos ejemplares de otra entidad. Por ejemplo, una persona puede tener varios números de teléfono.

Asociaciones muchos-a-muchos: Los clientes compran en muchas tiendas, una tienda tiene muchos clientes. Como este tipo de relaciones no se puede modelar directamente en una base de datos relacional, se modela usando una tabla intermedia que tenga una asociación uno-a-muchos con cada uno de los participantes originales. Por ejemplo, un pedido puede tener muchos tipos de confección, y un tipo de confección puede aparecer en varios pedidos.

Ejemplos de tipos de asociación Asociaciones uno-a-uno

Asociaciones uno-a-muchos

Asociaciones muchos-a-muchos

NormalizaciónLa normalización de bases de datos es un proceso que consiste en designar y aplicar una serie de reglas a las relaciones obtenidas tras el paso del modelo entidad-relación al modelo relacional.

Las bases de datos relacionales se normalizan para:

Evitar la redundancia de los datos.Disminuir problemas de actualización de los datos en las tablas.Proteger la integridad de los datos.En el modelo relacional es frecuente llamar tabla a una relación, aunque para que una tabla sea considerada como una relación tiene que cumplir con algunas restricciones:

Cada tabla debe tener su nombre único.No puede haber dos filas iguales. No se permiten los duplicados.Todos los datos en una columna deben ser del mismo tipo.

Manuales de procedimiento

Es el documento que contiene la descripción de los pasos que deben seguirse en la realización de las funciones de una o más unidades del sistema. El manual incluye además las tablas y relaciones que intervienen en la base de datos. Suelen contener información y ejemplos de formularios, autorizaciones o documentos necesarios, y cualquier otro dato que pueda auxiliar al correcto desarrollo de las actividades del usuario. En él se encuentra registrada y transmitida sin distorsión la información básica referente al funcionamiento de todo el sistema, facilita las labores de auditoria, la evaluación y control interno y su vigilancia, la conciencia en los empleados y en sus jefes de que el trabajo se está realizando o no adecuadamente

Elección, técnicas de diseño

Diseño conceptual1. Definición del problema2. Descripción funcional3. Restricciones4. Diagramas de flujo de datos5. Modelo de Modelo de datos6. Diccionario de datos7. Casos de uso8. Documentos adicionales

Diseño lógicoLas tareas a realizar en el diseño lógico son las siguientes:1. Identificar las entidades.2. Identificar las relaciones.3. Identificar los atributos y asociarlos a entidades y relaciones.4. Determinar los dominios de los atributos.5. Determinar los identificadores.6. Determinar las jerarquías de generalización (si las hay).7. Dibujar el diagrama entidad-relación.8. Revisar el esquema lógico con el usuario.

Diseño físicoLas tareas a llevar a cabo durante este proceso son:

- Convertir entidades en tablas físicas. Cuando la entidad es fuerte se convierte en una tabla.

- Escoger qué atributos se utilizarán para las columnas de las tablas y en qué tablas deben ir.

- Escoger los nombres finales de las columnas, en ocasiones abreviándolos. Esta tarea es importante en bases de datos que limitan el tamaño de nombres de columnas.

- Escoger qué columnas se transformarán en claves de identificación de la tabla.

- Escoger también qué columnas serán índices y de esta manera volver más eficiente la búsqueda de información en las consultas SQL sobre estas.

- Identificar las vistas a definirse en las tablas. Una vista es una forma alternativa para describir los datos que existen en una o más tablas.

- Resolver las relaciones (n:m ó muchos a muchos) entre entidades. Usualmente se crea una tabla extra que contiene las claves de ambas tablas relacionadas.

- Aplicar cierta desnormalización, dado que las reglas de normalización no consideran el rendimiento de la base de datos. Por lo que, en ocasiones, cierta desnormalización es necesaria para un funcionamiento más eficiente.

Bibliografia

https://es.wikipedia.org/wiki/Modelo_entidad-relaci%C3%B3n

https://es.wikipedia.org/wiki/Normalizaci%C3%B3n_de_bases_de_datos

https://en.wikipedia.org/wiki/Associative_entity https://es.wikipedia.org/wiki/Manual_de_procedimientos http://www3.uji.es/~mmarques/f47/teoria/tema6.pdf http://dis.um.es/~lopezquesada/documentos/IES_1415/

LMSGI/curso/xhtml/html16/doc/bd2.pdf http://www.alegsa.com.ar/Dic/dise

%C3%B1o_fisico_de_bases_de_datos.php