8 de noviembre:
hemos practicado mas diagramas del modelo entidad-relacion.
12 de noviembre:
examen
1. una parte del test consistia en un bloque de cuatro preguntas teoricas.
2. el segundo bloque era de razonar y desarrollar una serie de questiones, relacionadas con el modelo entidad-relacion extendido. Preguntas sobre la relacion jerarquica de los conjuntos y subconjuntos, otra de interpretar un diagrama del modelo extendido y finalmente el desarrollo de una arquitectura de un sistema gestor de bases de datos.
3. en el tercer bloque se trataba de dibujar dos diagramas de acuerdo a los anunciados.
ASIR Angel de la Fuente
miércoles, 13 de noviembre de 2013
martes, 5 de noviembre de 2013
5.11.2013
Practicando el diseño entidad/relacion.
Hemos creado diagramas conceptuales del modelo entidad/relacion. Para ello utilizamos el enunciado que nos proporciona Luis. En el apartado "resolucion de prácticas" voy colgando los diagramas hechos.
Concretamente, en la práctica numero cinco (que está colgada en practicas), se pide que se cuenten las unidades de las piezas que tenemos en el almacen. En la relación entre "piezas" y "estanterias" he puesto un atributo "cantidad" para hacer este recuento, aunque realmente no es necesario, ya que SQL lleva la cuenta de cada ocurrencia creada. De modo, que se cuentan las piezas aunque no se crea un atributo especifico.
Practicando el diseño entidad/relacion.
Hemos creado diagramas conceptuales del modelo entidad/relacion. Para ello utilizamos el enunciado que nos proporciona Luis. En el apartado "resolucion de prácticas" voy colgando los diagramas hechos.
Concretamente, en la práctica numero cinco (que está colgada en practicas), se pide que se cuenten las unidades de las piezas que tenemos en el almacen. En la relación entre "piezas" y "estanterias" he puesto un atributo "cantidad" para hacer este recuento, aunque realmente no es necesario, ya que SQL lleva la cuenta de cada ocurrencia creada. De modo, que se cuentan las piezas aunque no se crea un atributo especifico.
lunes, 4 de noviembre de 2013
31 de octubre
Dibujando diagramas
------------------------
En la clase del dia 31 de octubre hemos estado practicando crear diagramas conceptual del modelo entidad-relación, a partir de un enunciado tipo examen, donde se explicaban determinadas circunstancias, que habian de reflejarse en una base de datos.
El primer ejemplo describia una biblioteca, con unos socios, que alquilaban libros, de los cuales podia haber mas de un volumen de cada ejemplar. Habia que almacenar los datos del socio, los datos del libro, los volumenes alquilados y las fechas.
Una de las dificultades de este caso era el hecho, de tener que crear volumenes de cada libro. Estos volumenes eran como las instancias o ocurrencias de los libros.
Adjunto un diagrama posible de este trabajo que hicimos en clase.
Dibujando diagramas
------------------------
En la clase del dia 31 de octubre hemos estado practicando crear diagramas conceptual del modelo entidad-relación, a partir de un enunciado tipo examen, donde se explicaban determinadas circunstancias, que habian de reflejarse en una base de datos.
El primer ejemplo describia una biblioteca, con unos socios, que alquilaban libros, de los cuales podia haber mas de un volumen de cada ejemplar. Habia que almacenar los datos del socio, los datos del libro, los volumenes alquilados y las fechas.
Una de las dificultades de este caso era el hecho, de tener que crear volumenes de cada libro. Estos volumenes eran como las instancias o ocurrencias de los libros.
Adjunto un diagrama posible de este trabajo que hicimos en clase.
viernes, 18 de octubre de 2013
Fecha 15.10.2013 y 18.10.2013
Entidades, ocurrencias y las relaciones entre entidades
entidad
1. tiene que tener existencia propia
2. cada ocurrencia de un tipo de entidad debe poder distinguirse de las demas
ocurrencia:
1. todas las ocurrencias de la misma entidad deben tener las mismas caracteristicas (atributos)
atributos
1. caracteristicas
2. se representan como elipses
3. dominio: un conjunto de valores permitidos, como los tipos de datos en programacion
tipos de atribuos
1. atributo principal
2. atributo descriptor
entidad debil y entidad fuerte: la entidad debil no tiene razón de ser sin la entidad fuerte.
Jerarquia entre entidades y subconjuntos
a. jerarquia exclusiva
1. total: tiene que existir una relacion obligatoriamente entre la entidad fuerte la debil
2. parcial: la entidad fuerte puede relacionarse además con otras entidades debiles, pero solo con una
b. jerarquia de subtipos solapados
1. total: la entidad fuerte puede relacionarse al mismo tiempo con las entidades debiles
2. parcial: la entidad fuerte puede relacionarse además con otras entidades debiles
Entidades, ocurrencias y las relaciones entre entidades
entidad
1. tiene que tener existencia propia
2. cada ocurrencia de un tipo de entidad debe poder distinguirse de las demas
ocurrencia:
1. todas las ocurrencias de la misma entidad deben tener las mismas caracteristicas (atributos)
atributos
1. caracteristicas
2. se representan como elipses
3. dominio: un conjunto de valores permitidos, como los tipos de datos en programacion
tipos de atribuos
1. atributo principal
2. atributo descriptor
entidad debil y entidad fuerte: la entidad debil no tiene razón de ser sin la entidad fuerte.
Jerarquia entre entidades y subconjuntos
a. jerarquia exclusiva
1. total: tiene que existir una relacion obligatoriamente entre la entidad fuerte la debil
2. parcial: la entidad fuerte puede relacionarse además con otras entidades debiles, pero solo con una
b. jerarquia de subtipos solapados
1. total: la entidad fuerte puede relacionarse al mismo tiempo con las entidades debiles
2. parcial: la entidad fuerte puede relacionarse además con otras entidades debiles
Fecha 10.10.2013
La clase del dia 10 de octubre trata sobre la clasificacion de los SGBD. Hay varios criterios que podemos emplear para ello:
1. Según el modelo lógico utilizado:
a. modelo relacional
b. modelo en red
c. modelo jerárquico
2. Según el número de usuarios a los que da servicio
a. monousuario
b. multiusuario
3. Según la distribución física de la base de datos
a. centralizado
b. distribuido
4. Según el coste económico
5. Según el propósito:
a.propósito general
b. propósito específico
La clase del dia 10 de octubre trata sobre la clasificacion de los SGBD. Hay varios criterios que podemos emplear para ello:
1. Según el modelo lógico utilizado:
a. modelo relacional
b. modelo en red
c. modelo jerárquico
2. Según el número de usuarios a los que da servicio
a. monousuario
b. multiusuario
3. Según la distribución física de la base de datos
a. centralizado
b. distribuido
4. Según el coste económico
5. Según el propósito:
a.propósito general
b. propósito específico
fecha. 8.10.2013
En la clase del martes 8.10 hablamos sobre las ventajas y los inconvenientes de un SGBD.
ventajas de un SGBD
a. control de redundancia
b. consistencia
c. comparticion de datos
d. estandarización
e. seguridad (proteccion frente a usuarios no autorizados)
f. sistema de hacer consulta, sin necesidad de una aplicacion especifica
g. aumenta concurrencia
h. mejora de copias y recuperacion de datos
inconvenientes
a. complejidad de los programas
b. tamaño. los SBBD son muy extensos
c. coste económico
d. Coste del equipamiento adicional.
e. Coste de la conversión > en la migración de un sistema bd a un sistema gestor de base de datos
En la clase del martes 8.10 hablamos sobre las ventajas y los inconvenientes de un SGBD.
ventajas de un SGBD
a. control de redundancia
b. consistencia
c. comparticion de datos
d. estandarización
e. seguridad (proteccion frente a usuarios no autorizados)
f. sistema de hacer consulta, sin necesidad de una aplicacion especifica
g. aumenta concurrencia
h. mejora de copias y recuperacion de datos
inconvenientes
a. complejidad de los programas
b. tamaño. los SBBD son muy extensos
c. coste económico
d. Coste del equipamiento adicional.
e. Coste de la conversión > en la migración de un sistema bd a un sistema gestor de base de datos
Fecha 3.10.2013
Los temas tocados durante este dia son el esquema de una base de datos, la arquitectura de los SGBD, la estructura operacional de un SGBD y los servicios generales que proporcionan los SGBD.
Esquemas de bases de datos
El esquema se refiere al diseño estructural de una base de datos y no se suele modificar muy frecuentemente.
La arquitectura
Un SGBD está construido a partir de tres niveles, o tres capas. Está el nivel externo, el nivel conceptual y el nivel interno.
En el nivel externo se produce la interaccion del SGBD con aplicaciones externas o con el propio usuario mediante las distintas vistas.
El nivel conceptual se refiere al diseño entidad-relacion de la base de datos. Esta parte es administrada por el administrador de la bbdd y no se suele modificar a menudo.
El nivel interno es el tratamiento de la información a nivel logico y fisico. Como se almacena la informacion en el disco, que seguridad se aplica, la redundancia, etc.
En cuanto a la estructura operacional, se refiere a la relacion cliente-servidor. Una base de datos puede estar alojado en un solo servidor, o estar distribuida en varios servidores. Tambien es mencionada la relacion cliente-servidor web, que no es mas que una variacion del primer caso.
Un tema importante son los servicios que ha de ofrecer un SGBD. Es una lista bastante completa que elaboro un tal Codd: serian los siguientes puntos:
1. capacidad de almacenar datos
2. existencia de un diccionario
3. la transaccion se ejecuta completa o no se ejecuta (roll-back)
4. asegurar la concurrencia
5. capacidad de recuperar en caso de algun daño
6. solo los usuarios autorizados pueden acceder a la base de datos
7. debe poder comunicarse con los usuarios
Además de estas reglas, hay otras que se recomiendan pero no son obligatorias.
Los temas tocados durante este dia son el esquema de una base de datos, la arquitectura de los SGBD, la estructura operacional de un SGBD y los servicios generales que proporcionan los SGBD.
Esquemas de bases de datos
El esquema se refiere al diseño estructural de una base de datos y no se suele modificar muy frecuentemente.
La arquitectura
Un SGBD está construido a partir de tres niveles, o tres capas. Está el nivel externo, el nivel conceptual y el nivel interno.
En el nivel externo se produce la interaccion del SGBD con aplicaciones externas o con el propio usuario mediante las distintas vistas.
El nivel conceptual se refiere al diseño entidad-relacion de la base de datos. Esta parte es administrada por el administrador de la bbdd y no se suele modificar a menudo.
El nivel interno es el tratamiento de la información a nivel logico y fisico. Como se almacena la informacion en el disco, que seguridad se aplica, la redundancia, etc.
En cuanto a la estructura operacional, se refiere a la relacion cliente-servidor. Una base de datos puede estar alojado en un solo servidor, o estar distribuida en varios servidores. Tambien es mencionada la relacion cliente-servidor web, que no es mas que una variacion del primer caso.
Un tema importante son los servicios que ha de ofrecer un SGBD. Es una lista bastante completa que elaboro un tal Codd: serian los siguientes puntos:
1. capacidad de almacenar datos
2. existencia de un diccionario
3. la transaccion se ejecuta completa o no se ejecuta (roll-back)
4. asegurar la concurrencia
5. capacidad de recuperar en caso de algun daño
6. solo los usuarios autorizados pueden acceder a la base de datos
7. debe poder comunicarse con los usuarios
Además de estas reglas, hay otras que se recomiendan pero no son obligatorias.
Suscribirse a:
Comentarios (Atom)
