An

1
Análisis en Sistemas de Bases de Datos

• MC Beatriz Beltrán Martínez
• Benemérita Universidad Autónoma de Puebla

2
Introducción al desarrollo

• Cuando se diseñan bases de datos para sistemas de
  información, se vuelve complejo, ya que el
  sistema debe satisfacer los requerimientos de
  varios usuarios.
• Tales 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.

3
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.

4
Introducción al desarrollo

• Un sistema de información incluye todos los
  recursos dentro de la organización que participan
  en la recolección, administración, uso y
  diseminación de la información.
• Así pues el Sistema de Base de Datos es solo una
  parte de un sistema de información mucho mayor
  dentro de una organización.
• El ciclo de vida de un sistema de información a
  menudo se le llama macro ciclo de vida.

5
Fase I. Recolección y Análisis de Requerimientos

• Antes de empezar el diseño formal se deben
  conocer las expectativas de los usuarios y los
  usos que se piensan dar a la base de datos con
  mucho detalle.
• Para lograr la recolección y análisis de
  requerimiento se realizan ciertas actividades.
• Las actividades que se llevan a cabo son
• Identificación de las principales áreas de
  aplicación y grupos de usuarios que utilizaran la
  base de datos.

6
Fase I

• 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 para ver si influyen
  en esta fase.
• Análisis de los tipos de transacciones y de sus
  frecuencias, así como del flujo de información
  dentro del sistema.
• 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.

7
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.
• 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.

8
Fase II

• Fase 2a Diseño del esquema conceptual.
• El esquema conceptual que resulta de esta fase
  suele estar contenido en un modelo de datos de
  alto nivel independiente del DBMS.
• La importancia de un esquema conceptual no puede
  sobreestimarse por algunas razones

9
Fase II

1. La meta del diseño del esquema conceptual es un
   entendimiento completo de la estructura, el
   significado, los vínculos y las restricciones de
   la Base de Datos.
2. El esquema conceptual es muy valioso como una
   descripción estable del contenido de la base de
   datos.
3. Un buen entendimiento del esquema conceptual es
   decisivo para los usuarios de la Base de Datos y
   los diseñadores de aplicaciones.
4. La descripción gramatical del esquema conceptual
   puede servir como un excelente vinculo de
   comunicación entre los usuarios, diseñadores y
   analistas de la BD.

10
Fase II

• En esta fase del diseño es importante usar un
  modelo de datos semántico o conceptual que tenga
  las características
• Expresividad
• Sencillez
• Minimalidad
• Representación diagramática
• Formalidad

11
Fase II

• Hay dos enfoques para diseñar el esquema
  conceptual
• Enfoque centralizado de diseño del esquema, los
  requerimientos de las diferentes aplicaciones y
  grupos de usuarios, se combinaran en uno solo. La
  suposición en la que se basa este enfoque es que
  una autoridad centralizada del DBA se encarga de
  decidir como combinar los requerimientos, y de
  diseñar el esquema conceptual para toda la base
  de datos.
• Enfoque de integración de vistas, no se combinan
  los requerimientos mas bien se diseña un esquema
  o vista para cada grupo de usuarios o aplicación
  con base en solo sus requerimientos.

12
Fase II

• Se enumeran cuatro estrategias para el diseño de
  esquemas
• Estrategia descendente Se parte de un esquema
  que contiene abstracciones de alto nivel y luego
  se aplican refinaciones descendentes sucesivas.
• Estrategia ascendente Se parte de un esquema que
  contiene abstracciones básicas y luego se
  combinan o se les añaden otras abstracciones.

13
Fase II

• Estrategia de adentro hacia fuera Este es un
  caso especial de estrategia ascendente él la que
  la atención se concentra en un conjunto central
  de conceptos que no son los más evidentes.
• Estrategia mixta En esta estrategia los
  requerimientos son dividirán según una estrategia
  descendente y se diseñará una parte del esquema
  para cada partición de acuerdo con una estrategia
  ascendente. Por último, se combinaran las
  diferentes partes del esquema.

14
Fase II

• La integración de esquemas se puede dividir en
  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.

15
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. Algunos esquemas se modifican de modo que se
  ajusten mejor a otros esquemas.

16
Fase II

1. Combinación de vistas. El esquema global se crea
   combinando los esquemas individuales. Los
   conceptos que se corresponden se representan solo
   una vez en el esquema global, y se especifican
   las transformaciones de las vistas al esquema
   global.
2. Reestructuración. Como último paso opcional, el
   esquema global podría analizarse y
   reestructurarse para eliminar cualquier
   redundancia o una complejidad innecesaria.

17
Fase II

• Fase 2b Diseño de transacciones.
• El propósito de esta fase que se realiza en
  paralelo con la fase anterior es diseñar las
  características de las transacciones conocidas de
  la base de datos con independencia de DBMS.
• Una parte importante del diseño de BD es
  especificar las características funcionales de
  estas transacciones en una etapa temprana del
  proceso de diseño.
• El esquema incluirá toda la información requerida
  por dichas transacciones.

18
Fase II

• Una técnica común para especificar transacciones
  en un nivel conceptual es identificar su
  comportamiento de entrada/salida y funcional.
• Las transacciones pueden agruparse en tres
  categorías
• Transacciones de obtención Sirven para obtener
  datos los cuales son exhibidos en una pantalla o
  producen un informe.
• Transacciones de actualización Sirven para
  introducir datos nuevos o para modificar datos ya
  existentes en una Base de Datos.
• Transacciones mixtas Se usan en aplicaciones más
  complejas que obtienen y actualizan datos.

19
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.

20
Fase III

• Costos de adquisición del software.
• Costo de mantenimiento del sistema.
• Costos de adquisición de hardware.
• Costo de creación y conversión de la base de
  datos.
• Costo del personal.
• Costo de capacitación.
• Costo de operación.

21
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.

22
Fase III

• Por último hay varios factores económicos y de
  organización que influyen en la elección de un
  DBMS
• Estructura de los datos.
• Familiaridad del personal con el sistema.
• Disponibilidad de servicios del proveedor.

23
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.

24
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.

25
Fase V

• A menudo se utilizan los siguientes criterios
  para guiar la elección del diseño físico
• Tiempo de respuesta Es el tiempo que transcurre
  entre la introducción de una transacción para ser
  ejecutada y la obtención de una respuesta.
• El tiempo de respuesta también depende de otros
  factores como son la carga del sistema, la
  planificación de tareas del sistema operativo o
  los retrasos de comunicación.

26
Fase V

1. Aprovechamiento del espacio Este se refiere a la
   cantidad de espacio de almacenamiento que ocupan
   los archivos de la Base de Datos y su estructura
   de acceso.
2. Productividad de transacciones Este es el número
   promedio de transacciones que el sistema de Base
   de Datos puede procesar por minuto la
   productividad de transacciones debe medirse en
   las condiciones pico del sistema.

27
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.

28
Fase VI

• Se examinan las especificaciones conceptuales de
  las transacciones, y se escribe y se prueba el
  código de programa correspondiente con órdenes de
  DML incorporadas.
• 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.

29
Diseño Conceptual

• MC Beatriz Beltrán Martínez
• Benemérita Universidad Autónoma de Puebla

30
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.

31
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.
• Un conjunto de entidades es un grupo de entidades
  del mismo tipo.

32
Entidades

• Los conjuntos de entidades no son necesariamente
  disjuntos.
• Una entidad se representa mediante un conjunto de
  atributos.
• Los atributos describen propiedades que posee
  cada miembro de un conjunto de entidades.
• La designación de un atributo para un conjunto de
  identidades expresa que en la base de datos se va
  a guardar información similar.

33
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.

34
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.

35
Atributos

• Atributos multivalorados Tienen un conjunto de
  valores para una entidad específica.
• Para este tipo de atributos se pueden dar límites
  para dar un mínimo y un máximo del atributo.
• 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.

36
Valores Nulos

• 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.

37
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 ngt2
  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.

38
Ejemplo
Relaciones
Entidad
Entidad
P17 1000
P23 2000
P15 1500
P14 1500
P19 500
P11 900
P16 1300
32002 Sánchez 12 sur Puebla
01928 Gómez Norte 10 Orizaba
67789 López 15 poniente Puebla
55555 Morales Narvarte México DF
24466 Pérez Oriente 15 Orizaba
96396 Marín 20 norte Monterrey
33557 Fernández 44 oriente Cuernavaca
39
Relaciones

• La asociación entre conjuntos de entidades se
  conoce como participación es decir, los
  conjuntos de entidades E1, E2, ..., En participan
  en el conjunto de relaciones R.
• Un ejemplar de relación es un esquema ER
  representa que existe una asociación entre las
  entidades denominadas en la empresa que se
  modela.
• La función que desempeña una entidad en una
  relación se llama papel.

40
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.

41
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

42
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.

43
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.

44
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.

b1
b2
b3
45
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.

46
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.

47
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.

48
Superclave

• La clave primaria, denota una clave candidata que
  es elegida como elemento principal para
  identificar la entidad.
• Una clave, es una propiedad del conjunto de
  entidades más que de las entidades individuales.
• La designación de una clave denota una
  restricción.
• La clave primaria debe elegirse de tal forma que
  su valor no cambie o raramente cambie.

49
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.

50
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.
• Para distinguir los tipo se tiene
• Línea dirigida Denota uno.
• Línea no dirigida Denota varios.

51
Diagrama E R
Uno a varios
Varios a varios
Uno a uno
52
Diagrama E R
Uno a varios
Varios a varios
Uno a uno
53
Diagrama E R

• Se pueden tener atributos unidos a un conjunto de
  relaciones.

Fecha_ac
Nombre
Dirección
Num_prestamo
Id_cliente
saldo
54
Diagrama E R

• Atributos compuestos, multivalorados y derivados.

Ap_pat
Num_ca
Ap_mat
Nompila
Calle
Nom_ca
Nombre
Dirección
Num_ext
Id_cliente
Num_int
Fec_nac
CP
Edad
Tel