lunes, 10 de octubre de 2011

Semana 9

                                                           Atributos y Dominios

1.-Atributos:

Es una característica de interés o un hecho sobre una entidad o sobre una relación. Los atributos representan las propiedades básicas de las entidades y de las relaciones. Toda la información extensiva es portada por los atributos. Gráficamente, se representan mediante bolitas que cuelgan de las entidades o relaciones a las que pertenecen.

Cada atributo tiene un conjunto de valores asociados denominado dominio. El dominio define todos los valores posibles que puede tomar un atributo. Puede haber varios atributos definidos sobre un mismo dominio.

Los atributos pueden ser simples o compuestos:

*Atributo simple: Es un atributo que tiene un solo componente, que no se puede dividir en partes más pequeñas que tengan un significado propio.

*Atributo compuesto: Es un atributo con varios componentes, cada uno con un significado por sí mismo. Un grupo de atributos se representa mediante un atributo compuesto cuando tienen afinidad en cuanto a su significado, o en cuanto a su uso. Un atributo compuesto se representa gráficamente mediante un óvalo.

Los atributos también pueden clasificarse en:

* Atributo monovalente: Es aquel que tiene un solo valor para cada ocurrencia de la entidad o relación a la que pertenece.

*Atributo polivalente: Es aquel que tiene varios valores para cada ocurrencia de la entidad o relación a la que pertenece. A estos atributos también se les denomina multivaluados, y pueden tener un número máximo y un número mínimo de valores. La cardinalidad de un atributo indica el número mínimo y el número máximo de valores que puede tomar para cada ocurrencia de la entidad o relación a la que pertenece. El valor por omisión es .
Por último, los atributos pueden ser derivados. Un atributo derivado es aquel que representa un valor que se puede obtener a partir del valor de uno o varios atributos, que no necesariamente deben pertenecer a la misma entidad o relación.


2.-Dominio:

Un dominio describe un conjunto de posibles valores para cierto atributo. Como un dominio restringe los valores del atributo, puede ser considerado como una restricción. Matemáticamente, atribuir un dominio a un atributo significa "todos los valores de este atributo deben de ser elementos del conjunto especificado".
   *El valor NULL no forma parte del dominio

   *Todos los atributos tienen un solo dominio que nunca cambia
 
   *Los dominios son diferentes entre ellos

   *Podemos especificar los operadores válidos para manipular los valores del dominio.


   * Ningún SGBD lo implementa SQL no tiene dominios.
   *Cada dominio tiene un nombre diferente
   *Hay dos clases de dominios:
           -Simples: atributo simple Entero, string, carácter, boolear (true / falso), real.
          - Compuesto: Combinación de simples.
Los dominios restringir las comparaciones (entre dominios diferentes. Ej.: entre edades) y las operaciones extrañas.
Ejemplo:Deportista. Edad es del dominio EDAD
             Deportista. Peso es del dominio PESO
Los dominios se encuentran definidos en el diseño de la BD (Los dominios se han de definir en la base de datos, sino se han de definir aparte. Especificaremos lo máximo posible).


      Semana 8

      Recursivas:

      Modelan las situaciones en que dos entidades del mismo conjunto se relacionan entre sí.
      Es necesario especificar el rol de cada entidad en la relación.

      Entidades Asociativas:

      La entidad que resulta de considerar una interrelación entre entidades como si fuese una entidad es una entidad asociativa, y tendrá el mismo nombre que la interrelación sobre la que se define.

      La utilidad de una entidad asociativa consiste en que se puede interrelacionar con otras entidades y, de forma indirecta, nos permite tener interrelaciones en las que intervienen interrelaciones. Una entidad asociativa se denota recuadrando el rombo de la interrelación de la que proviene.

      Dependencias Funcionales:

      Son restricciones de integridad sobre los datos. Conocer las dependencias funcionales en el momento del diseño de la base de datos permite crear mecanismos para evitar la redundancia (y los potenciales problemas de integridad que eso conlleva) y mejorar la eficiencia.

       A veces es fácil encontrar dependencias en un esquema. Esto es un indicador de un mal modelo entidad-relación o de una mala conversión a relacional.

      Por ejemplo, sea Película (título, año, estudio, presidente, fono presidente). Digamos que “título” es llave de la relación (determina todo). Sin embargo, notemos que el presidente de un estudio se puede determinar conociendo el estudio y el año (idealmente). Luego, estudio, año! presidente.

      Además, es claro que presidente! fono presidente.La relación “Película” fue mal modelada desde un principio. En un modelo entidad-relación, “Película”, “Estudio” y “Presidente” habrían sido entidades distintas, luego relaciones distintas en el modelo relacional.

      sábado, 8 de octubre de 2011

      Semana 7

      Relaciones:

      Una  relacion es una asociación entre entidadesLas relaciones se representas gráficamente con rombos, dentro de ellas se coloca el nombre de la relación.

      Cardinalidad:


      Número de elementos de un tipo que se conectan con un elemento de otro (restricción que se observa en el dominio del problema y que controla las ocurrencias de las relaciones).

      *Relaciones "uno a uno"
      Estas relaciones entre bases de datos se dan cuando cada campo clave aparece sólo una vez en cada una de las tablas.
      Tomando un ejemplo del mundo real, una clara relación de "uno a uno" podría ser, el nombre de cualquier persona y su número de teléfono. Si partimosdel supuesto en que cada persona tiene un solo número de teléfono, se podría hablar de una relación "uno a uno".
      *Relaciones de "uno a varios"
      El ejemplo del caso anterior (cada persona, un teléfono), si bien es correcto teóricamente, es muy improbable desde el punto de vista de la realidad. Conla gran expansión de los teléfonos, por lo general, cada persona tiene un número de teléfono fijo, y ademas del teéfono móvil. Debemos tener en cuenta que de el de su casa también tendrá un número de teléfono de empresa, y que quizá también sus móviles estén divididos en ocio y trabajo
      *Relaciones de "varios con varios"
      La última de las relaciones que podemos encontrar es la de "varios con varios". Dado que en la vida las cosas rara vez son sencillas, éste será el tipo de relación que nos encontraremos más a menudo.

      Tipos de Relaciones:

      *Relaciones involutivas:

      Relaciones de un tipo consigo mismo
      *Relaciones n-arias:

      El grado de una relación no tiene por qué ser siempre 2.
      Pueden existir relaciones ternarias, cuaternarias.. En la práctica, a menudo se reemplaza una relación n-aria por nuevo tipo de entidad y un conjunto de relaciones binarias.

      jueves, 6 de octubre de 2011

      Semana 6

                                                            Modelo Entidad Relación III
      Modelo Físico:

      Es el proceso de producción de una descripción, de una implementación, de un almacenamiento secundario de la Base de Datos, describe el almacenamiento de estructuras y métodos de acceso usados para conseguir el acceso eficiente a los datos. El Diseño Físico de la Base de Datos es la última etapa del proceso de diseño, en el cual, teniendo presentes los requisitos de los procesos, características del SGBD, del SO y el hardware, se pretenden los siguientes objetivos:

       · Disminuir los tiempos de respuesta.

      · Minimizar espacio de almacenamiento.

      · Evitar las reorganizaciones.

      · Proporcionar la máxima seguridad.

      · Optimizar el consumo de recursos.


      No existe un modelo formal para el Diseño Físico (como por ejemplo, el modelo relacional para el diseño lógico), el Diseño Físico resulta muy dependiente del producto comercial concreto hasta el momento.
      El Diseño Físico consta de entradas y salidas. En las entradas se podría destacar además de los objetivos del Diseño Físico; los recursos máquina (soporte físico), recursos lógicos (sistemas operativos), esquema lógico y la información sobre las aplicaciones (tiempos de respuesta y seguridad).
      A partir de las entradas, en la salida obtendremos; normas de seguridad, estructura
      interna, y especificaciones para el ajuste.
      El problema del Diseño Físico para el administrador de la Base de Datos consiste en
      proveer un conjunto eficiente de estructuras de acceso de modo que el optimizador pueda tomar las mejores decisiones. Entre los instrumentos más importantes del Diseño Físico se encuentra la selección de los índices secundarios, que es uno de los problemas en la instrumentación física de una Base de Datos.
      Una vez diseñadas las aplicaciones se conocerá cuáles son las consultas más frecuentes y prioritarias a la Base de Datos, por lo que será conveniente crear un índice secundario que ayude a localizar las filas seleccionadas en dichas consultas y reducir los accesos a disco.

      domingo, 2 de octubre de 2011

      Semana 5

                                                         Modelo Entidad Relación II

      Modelo Lógico:

      El objetivo del diseño lógico es convertir los esquemas conceptuales locales en un esquema lógico global que se ajuste al modelo de SGBD sobre el que se vaya a implementar el sistema. Mientras que el objetivo fundamental del diseño conceptual es la compleción y expresividad de los esquemas conceptuales locales, el objetivo del diseño lógico es obtener una representación que use, del modo más eficiente posible, los recursos que el modelo de SGBD posee para estructurar los datos y para modelar las restricciones

      Los modelos de bases de datos más extendidos son el modelo relacional, el modelo de red y el modelo jerárquico. El modelo orientado a objetos es también muy popular, pero no existe un modelo estándar orientado a objetos.

      El modelo relacional (y los modelos previos) carecen de ciertos rasgos de abstracción que se usan en los modelos conceptuales. Por lo tanto, un primer paso en la fase del diseño lógico consistirá en la conversión de esos mecanismos de representación de alto nivel en términos de las estructuras de bajo nivel disponibles en el modelo relacional.

      Metodología :

      La metodología que se va a seguir para el diseño lógico en el modelo relacional consta de dos fases, cada una de ellas compuesta por varios pasos que se detallan a continuación.

      * Construir y validar los esquemas lógicos locales para cada vista de usuario.

      * Convertir los esquemas conceptuales locales en esquemas lógicos locales.

      * Derivar un conjunto de relaciones (tablas) para cada esquema lógico local.

      *Validar cada esquema mediante la normalización.

      * Validar cada esquema frente a las transacciones del usuario.

      *Dibujar el diagrama entidad-relación.

      * Definir las restricciones de integridad.

      *Revisar cada esquema lógico local con el usuario correspondiente.

      *Construir y validar el esquema lógico global.

      *Mezclar los esquemas lógicos locales en un esquema lógico global.

      * Validar el esquema lógico global.

      * Estudiar el crecimiento futuro.

      *Dibujar el diagrama entidad-relación final.

      * Revisar el esquema lógico global con los usuarios