Slides:



Advertisements
Presentaciones similares
IBD Plan 90 y 2003 Clase 11.
Advertisements

IBD Plan 90 y 2003 Clase 10.
IBD Clase 13.
También conocido como Diseño Lógico Rodrigo Salvatierra Alberú.
Unidad II Modelo Entidad-Relación
TECNICATURA UNIVERSITARIA EN INFORMATICA
Entidad Cosa u objeto real (una persona) o abstracto (un préstamo) de interés en el mundo real (una organización). Es distinguible de todos los demás objetos.
Modelo Entidad Relación
TECNICATURA EN INFORMATICA
Introducción a LAS Bases de Datos
Fundamentos de Base de Datos Modelo E-R
Base de Datos Distribuidas FUNDAMENTOS DE BASES DE DATOS DISTRIBUIDAS
Elementos para Interpretar el Modelo Conceptual de Datos
MODELO RELACIONAL.
Entidad Relación Doc. Ing. Marleny Soria Medina
2.1Definición de un modelo de datos
Modelo de Datos Unidad II.
Guia Diseño Robert Echeverria
Diseño del Esquema de BD
Modelo Entidad Relación E-R
Base de Datos Relacional.
Mayo de 2009Dos Ideas - La visión de Sistemas desde el Desarrollo Introducción a Base de Datos Conceptos básicos.
ESCUELA: PONENTE: BIMESTRE: BASES DE DATOS I CICLO: CIENCIAS DE LA COMPUTACIÓN II BIMESTRE Ing. Audrey Romero ABRIL – AGOSTO 2007.
INTEGRANTES ALEXIS MENDOZA ALDAIR ARRIETA CARLOS PASTOR LORENA RODRIGUEZ ANTHONY JIMENEZ.

UNIDAD I Conceptos Básicos.
BASE DE DATOS I Clase # 1.

Diseño de Bases de Datos
Facultad de Ciencias de la Computación
Ing. Marco Zarate Z.. Entidades Relaciones Atributos.

Diseño del Software Diseño de datos Diseño arquitectónico
Ing. Fabián Ruano.  Definición  Diferencias con BD Centralizadas.
Sistemas de Bases de Datos I
Actividad 6. Requisitos del software, referente a la estructura y base de datos. M.C. Juan Carlos Olivares Rojas Syllabus May,
Viviana Poblete López Módulo: Modelo de Datos
Introducción a la Base de Datos
Introducción A Las Bases De Datos
Bases de Datos Modelamiento.
Métrica v2.1 Técnicas: Modelado de datos (Parte 2)
MODELADO DE DATOS (PARTE 2) Viviana Poblete L. Modelo de Datos I.
Modelos de Bases de Datos
Introducción a las Bases de Datos Relacionales Juan Alberto Sigüenza Escuela Técnica Superior de Informática Universidad Autónoma de Madrid.
Chapter 13 Normalization Transparencies © Pearson Education Limited 1995, 2005.
Modelos de Datos.
Ing. Héctor Abraham Hernández Erazo
CICLO DE VIDA Y NORMAALIZACION DE UN SISTEMA DE BASE DE DATOS
Trainning DFD.
El modelo de análisis tiene como objetivo generar una arquitectura de objetos que sirva como base para el diseño posterior del sistema. Dependiendo del.
Introducción La gestión de bases de datos ha evolucionado.
Métrica v2.1 Técnicas: Modelado de datos (Parte 1)
REQUISITOS.
Diagramas.
Ciclo de vida de un sistema
Diagrama Entidad-Relación
CICLO DE VIDA CLÁSICO DE UN SISTEMA
Normalización Prof. Gloria Toro Oñate
Un requerimiento es una condición o capacidad a la que el sistema (siendo construido) debe conformar [ Rational ]. Un requerimiento de software puede.
¿QUÉ ES EL MODELO ENTIDAD-RELACIÓN?  Como ya he comentado este modelo es solo y exclusivamente un método del que disponemos para diseñar estos esquemas.

Proceso de desarrollo de Software
DISEÑO DE BASES DE DATOS (modelos para el diseño)
Licda. Noelia Gómez Gutiérrez
M ODELO DE DATOS DE ENTIDAD - VÍNCULO El modelo de entidad-vínculo es un modelo de datos conceptual de uso muy extendido. Este modelo, y sus variantes,
Identificación de entradas, salidas y herramientas de procesos de gestión del PMI Jairo A. Orozco L.
Fundamentos de Ingeniería de Software
BASES DE DATOS CONCEPTOS BASICOS Elizabeth Maite Zarate Machaca “El tratamiento eficiente de la información al servicio del usuario”
BASES DE DATOS DISTRIBUIDAS M.C.C. María Guadalupe Villanueva Carrasco INGENIERIA EN SISTEMAS COMPUTACIONALES.
Modelos Entidad – Relación (E-R). El modelo entidad-relación Los MD soportados por los SGBD no suelen ofrecer, dado su bajo nivel de abstracción, los.
Transcripción de la presentación:

Análisis en Sistemas de Bases de Datos MC Beatriz Beltrán Martínez Benemérita Universidad Autónoma de Puebla

Introducción al desarrollo Cuando se diseñan bases de datos, es una tarea compleja debido a que el sistema debe satisfacer los requerimientos de varios usuarios. Las Bases de Datos se usan ampliamente en distintas organizaciones. Las industrias de servicios dependen totalmente de que sus Bases de Datos funcionen a la perfección, estos sistemas suelen recibir el nombre de sistemas de procesamiento de transacciones. MC. Beatriz Beltrán Martínez FCC - BUAP Otoño 2015

Introducción al desarrollo El término Desarrollo de Bases de Datos, se utiliza para describir el proceso de diseño y ejecución de bases de datos. El objetivo principal en el diseño de bases de datos es crear modelos de bases de datos completos normalizados, no redundantes, conceptuales, lógicos y físicos totalmente integrados. La fase de ejecución se incluye estructuras de almacenamiento, carga de datos, entre otros. MC. Beatriz Beltrán Martínez FCC - BUAP Otoño 2015

Fase I. Recolección y Análisis de Requerimientos Las actividades que se llevan a cabo son: Identificación de las principales áreas de aplicación y grupos de usuarios. Estudio y análisis de la documentación existente relativa a las aplicaciones. Se repasan manuales de política formas, informes y diagramas de organización. Análisis de los tipos de transacciones y de sus frecuencias, así como del flujo de información dentro del sistema. MC. Beatriz Beltrán Martínez FCC - BUAP Otoño 2015

Fase I. Recolección y Análisis de Requerimientos Se especifican los datos de entrada y salida de las transacciones. Recolección de respuestas escritas a grupos de preguntas hechas a los posibles usuario de la Base de Datos. Estas preguntas se refieren a las prioridades de los usuarios y a la importancia que le dan a las aplicaciones. MC. Beatriz Beltrán Martínez FCC - BUAP Otoño 2015

Fase II. Diseño Conceptual de la Base de Datos Esta fase se compone a la vez de otras dos: FASE 2a: Diseño del esquema conceptual. Examina los requerimientos de datos resultantes de la fase 1 y produce un esquema de bases de datos conceptual. Se da en un modelo de datos. FASE 2b: Diseño de transacciones. Examina las aplicaciones de base de datos analizadas en la fase 1 y produce especificaciones de alto nivel para estas transacciones. Se realiza en paralelo con la otra fase. MC. Beatriz Beltrán Martínez FCC - BUAP Otoño 2015

Fase II En la Fase 2a, se consideran las siguientes subtareas: Identificación de correspondencia y conflictos entre los esquemas. Durante este proceso es posible que se descubra varios tipos de conflictos: Conflictos de nombres estos son de dos tipos: sinónimos y homónimos. Conflictos de tipos: El mismo concepto puede representarse en dos esquemas mediante elementos de modelado diferentes. MC. Beatriz Beltrán Martínez FCC - BUAP Otoño 2015

Fase II Conflictos de dominio. Un atributo puede tener diferentes dominios en dos esquemas. Conflictos entre restricciones. Dos esquemas pueden imponer diferentes restricciones. Modificación de las vistas para ajustarlas entre si. Combinación de vistas. El esquema global se crea combinando los esquemas individuales. Reestructuración. Paso opcional, donde se puede analizar y reestructurar el esquema para eliminar cualquier redundancia o una complejidad innecesaria. MC. Beatriz Beltrán Martínez FCC - BUAP Otoño 2015

Fase II Fase 2b: Diseño de transacciones. Una parte importante del diseño de BD es especificar las características funcionales de las transacciones. Las transacciones pueden agruparse en tres categorías: Transacciones de obtención. Transacciones de actualización. Transacciones mixtas. MC. Beatriz Beltrán Martínez FCC - BUAP Otoño 2015

Fase III. Elección de un DBMS Esta elección depende de varios factores, algunos de ellos técnicos, otros económicos y otros más relativos a las políticas de organización. Al escoger un DBMS debemos considerar los siguientes costos: Costos de adquisición del software, de mantenimiento del sistema, de adquisición de hardware, de creación y conversión de la base de datos, del personal, de capacitación y de operación. MC. Beatriz Beltrán Martínez FCC - BUAP Otoño 2015

Fase III Entre los beneficios del DBMS están: Facilidad de uso, mayor disponibilidad de datos, rápido acceso, reducción del costo de creación de aplicaciones, menor redundancia de datos, mejor control y seguridad. Con base en un análisis de costo-beneficios se tiene que decidir cuando cambiar a un DBMS y depende de: La complejidad de los datos. Compartimiento entre aplicaciones. Evolución o crecimiento de los datos. Frecuencia de solicitudes de datos. Volumen de datos y necesidad de control. MC. Beatriz Beltrán Martínez FCC - BUAP Otoño 2015

Fase IV. Transformación al Modelo de Base de Datos (Diseño Lógico) Consiste en crear un esquema conceptual y esquemas externos en el modelo de datos de DBMS elegido. La transformación puede establecerse en dos etapas: Transformación independiente del sistema. Adaptación de los esquemas a un DBMS especifico. MC. Beatriz Beltrán Martínez FCC - BUAP Otoño 2015

Fase V. Diseño Físico de la Base de Datos Es el proceso de elegir estructuras de almacenamiento y caminos de acceso especifico para que los archivos tengan un buen rendimiento con las diversas aplicaciones de la Base de Datos. Una vez seleccionado un DBMS especifico, el proceso de diseño físico se reduce a elegir las estructuras más apropiadas para los archivos de la Base de Datos entre las opciones ese DBMS. A menudo se utilizan los siguientes criterios para guiar la elección del diseño físico: Tiempo de respuesta, Aprovechamiento del espacio y Productividad de transacciones. MC. Beatriz Beltrán Martínez FCC - BUAP Otoño 2015

Fase VI. Implementación del Sistema de la Base De Datos Una vez complementados los diseños lógico y físico se puede implementar el sistema de Base de Datos. En esta etapa los programadores de aplicaciones deben implementar las transacciones de la Base de Datos. Una vez que las transacciones estén listas y los datos se hayan almacenado en la base de datos, la fase de diseño e implementación habrá terminado Finalmente, se iniciará la fase de operación del sistema. MC. Beatriz Beltrán Martínez FCC - BUAP Otoño 2015

MC Beatriz Beltrán Martínez Benemérita Universidad Autónoma de Puebla Diseño Conceptual MC Beatriz Beltrán Martínez Benemérita Universidad Autónoma de Puebla

Modelo Conceptual El modelo de datos entidad – relación (E-R) está basado en una percepción del mundo real consistente en objetos básicos: Entidades Relaciones Se desarrolló para facilitar el diseño de bases de datos permitiendo la especificación de un esquema de una empresa que representa la estructura completa. MC. Beatriz Beltrán Martínez FCC - BUAP Otoño 2015

Entidades Una entidad es un objeto que existe y se distingue de otros objetos de acuerdo a sus características llamadas atributos. Las entidades pueden ser concretas como una persona o abstractas como una fecha. Una entidad se representa mediante un conjunto de atributos. Las entidades débiles, no tienen por sí mismas datos suficientes como para poder ser identificadas, por lo que dependen de otra, y especialmente dependen de la clave de esa otra entidad para poder ser identificadas. MC. Beatriz Beltrán Martínez FCC - BUAP Otoño 2015

Atributos Cada entidad puede tener su propio valor para cada atributo. Para cada atributo hay un conjunto de valores permitidos, llamados el dominio o conjunto de valores de ese atributo. Como un conjunto de entidades puede tener diferentes atributos, cada entidad se puede describir como el conjunto de pares (atributo, valor) para cada atributo que tenga la entidad. MC. Beatriz Beltrán Martínez FCC - BUAP Otoño 2015

Atributos Un atributo se puede caracterizar por: Atributos simples: Que no se dividen en subpartes. Atributos compuestos: Que se pueden dividir en otros atributos. El uso de estos atributos proporciona un modelo más claro y agrupa atributos relacionados. Atributos monovalorados: Tienen un valor solo para una entidad concreta. Atributos multivalorados: Tienen un conjunto de valores para una entidad específica. Se pueden dar límites. MC. Beatriz Beltrán Martínez FCC - BUAP Otoño 2015

Atributos Atributos derivados: El valor se puede obtener de otros atributos o entidades relacionadas. Un atributo toma el valor nulo cuando una entidad no tiene un valor para un atributo. El valor nulo también puede indicar: “No aplicable”, es decir no existe. Valor desconocido, no se sabe si existe o no. Valor perdido, existe pero no se conoce. MC. Beatriz Beltrán Martínez FCC - BUAP Otoño 2015

Superclave Una clave permite identificar un conjunto de atributos suficiente para distinguir las entidades entre sí. Una superclave es un conjunto de uno o más atributos que tomados colectivamente, permiten identificar de forma única una entidad en el conjunto de identidades. Existen superclaves minimales, a las que se les llama claves candidatas. La clave primaria, denota una clave candidata que es elegida como elemento principal para identificar la entidad. MC. Beatriz Beltrán Martínez FCC - BUAP Otoño 2015

Relaciones Una relación es una asociación entre diferentes entidades. Un conjunto de relaciones es un conjunto de relaciones del mismo tipo. Formalmente es una relación matemática con n>=2 de conjuntos de identidades. Si E1, E2, ..., En son conjunto de entidades, entonces un conjunto de relaciones R es un subconjunto de: {(e1, e2, ..., en) | e1  E1, ..., en  En} donde (e1, e2, ..., en) es una relación. La función que desempeña una entidad en una relación se llama papel. MC. Beatriz Beltrán Martínez FCC - BUAP Otoño 2015

Ejemplo Relaciones Entidad Entidad 32002 Sánchez 12 sur Puebla 01928 Gómez Norte 10 Orizaba 67789 López 15 poniente 55555 Morales Narvarte México DF 24466 Pérez Oriente 15 96396 Marín 20 norte Monterrey 33557 Fernández 44 oriente Cuernavaca P17 1000 P23 2000 P15 1500 P14 P19 500 P11 900 P16 1300 MC. Beatriz Beltrán Martínez FCC - BUAP Otoño 2015

Tipos de relaciones Cuando un conjunto de entidades de una relación participa en una relación más de una vez con diferentes papeles se le conoce como conjunto de relaciones recursivas. Una relación también puede tener atributos descriptivos, los cuales describen a las entidades. Una relación binaria, es aquella en la que se tienen dos conjuntos de relaciones. El número de conjunto de entidades que participan en un conjunto de relaciones se le conoce como grado. MC. Beatriz Beltrán Martínez FCC - BUAP Otoño 2015

Cardinalidad Correspondencia de cardinalidad, expresa el número de entidades a las que otra entidad puede estar asociada vía un conjunto de relaciones. La correspondencia de cardinalidades es más útil describiendo conjunto de relaciones binarias. Para un conjunto de relaciones binarias R entre los conjuntos de entidades A y B, la correspondencia de cardinalidades debe ser: MC. Beatriz Beltrán Martínez FCC - BUAP Otoño 2015

Cardinalidad Uno a uno: Una entidad en A se asocia con a la sumo una entidad de B, y una entidad en B se asocia con a lo sumo una entidad en A. a1 a3 a2 a4 b1 b3 b2 b4 MC. Beatriz Beltrán Martínez FCC - BUAP Otoño 2015

Cardinalidad Uno a varios: Una entidad A se asocia con cualquier número de entidades en B (ninguna o varias). Una entidad B, en cambio, se puede asociar con a lo sumo una entidad en A. a1 a3 a2 b1 b3 b2 b4 MC. Beatriz Beltrán Martínez FCC - BUAP Otoño 2015

Cardinalidad Varios a uno: Una entidad A se asocia con a los sumo asocia con una entidad en B. Una entidad B, en cambio, se puede asociar con cualquier número de entidades (ninguna o varias) en A. a1 a3 a2 a4 b1 b3 b2 MC. Beatriz Beltrán Martínez FCC - BUAP Otoño 2015

Cardinalidad Varios a varios: una entidad A se asocia con cualquier número de entidades (ninguna o varias) en B, y una entidad A se asocia con cualquier número de entidades (ninguna o varias) en B. a1 a3 a2 a4 b1 b3 b2 b4 MC. Beatriz Beltrán Martínez FCC - BUAP Otoño 2015

Participación La participación de un conjunto de entidades E en un conjunto de relaciones R es total si cada entidad de E participa al menos en una relación en R. Si sólo algunas entidades en E participan en relaciones en R, la participación del conjunto de entidades E en la relación R es parcial. MC. Beatriz Beltrán Martínez FCC - BUAP Otoño 2015

Diagrama E – R La estructura lógica de una base de datos se puede expresar gráficamente mediante un diagrama E – R. Los diagramas son simples y claros. Los componentes son: Rectángulos: conjuntos de entidades. Elipses: atributos. Rombos: relaciones. Líneas: que unen conjuntos. MC. Beatriz Beltrán Martínez FCC - BUAP Otoño 2015

Diagrama E – R Elipses dobles: atributos multivalorados. Elipses discontinuas: atributos derivados. Líneas dobles: participación total de una entidad en un conjunto de relaciones. Rectángulos dobles: conjunto de entidades débiles. La clave primaria se subraya. MC. Beatriz Beltrán Martínez FCC - BUAP Otoño 2015

Diagrama E – R cliente préstamo Uno a varios cliente préstamo prestatario cliente préstamo Uno a varios prestatario cliente préstamo Varios a varios prestatario cliente préstamo Uno a uno MC. Beatriz Beltrán Martínez FCC - BUAP Otoño 2015

Diagrama E – R cliente préstamo Uno a varios cliente préstamo prestatario cliente préstamo Uno a varios prestatario cliente préstamo Varios a varios prestatario cliente préstamo Uno a uno MC. Beatriz Beltrán Martínez FCC - BUAP Otoño 2015

Diagrama E – R Se pueden tener atributos unidos a un conjunto de relaciones. Fecha_ac Nombre Dirección Num_prestamo Id_cliente saldo prestatario cliente préstamo MC. Beatriz Beltrán Martínez FCC - BUAP Otoño 2015

Diagrama E – R Atributos compuestos, multivalorados y derivados. Ap_pat Ap_mat Num_ca Nompila Calle Nom_ca Nombre Dirección Num_ext Id_cliente Num_int Fec_nac cliente CP Edad Tel MC. Beatriz Beltrán Martínez FCC - BUAP Otoño 2015