El BLOG de FLamelas

• Proyecto Laboratorio de Física - UNITEC/Tegucigalpa: http://bdlabfisica.blogspot.com/
• Proyecto ENDEVHO: http://teoriabdd-endevho.blogspot.com/
• Proyecto Hotel Cay View: http://grupodrvtdbi.blogspot.com/
• Proyecto Comercial Miriam: http://tbdcomercialmiriams.blogspot.com/
• Proyecto Dra. Bejarano (SpaMedic): http://proyecto-mandela.blogspot.com
• Proyecto AUTOPINTURA: http://teoriabasedatos.blogspot.com/
• Proyecto Biblioteca Virgina Sapp: http://sistemabibliotecasapp.blogspot.com/

Saludos cordiales,

Ing. Franklin Lamelas

# posted by Franklin Lamelas @ 8:59 a. m. 1 comments

1. www.proyectocyd.blogspot.com (Proyecto: CyD)
2. http://proyrocafuerte.blogspot.es (Proyecto: Roca Fuerte)
3. http://grupo01-db.blogspot.com/ (Proyecto: A la Luz de los Valores)

Saludos,

# posted by Franklin Lamelas @ 3:04 p. m. 0 comments

Fundamentos de Bases de Datos, 5ta. Edición

Abraham Silberschatz, Henry F. Korth y S. Sudarshan

# posted by Franklin Lamelas @ 11:24 a. m. 1 comments

Proyecto de Clase 1

Teoría Bases de Datos II – Ing. Franklin Lamelas

Segundo Semestre, Quinto Periodo, 2006

El presente proyecto tiene por objetivo, desarrollar un software en un lenguaje de programación visual (el de su predilección) que implemente de manera general una serie de técnicas y algoritmos propios del diseño de bases de datos relacionales.

De manera específica, se requiere que el software implemente lo siguiente:

1. Cálculo del Cierre de Dependencias Funcionales (F+) y cálculo de claves candidatas. (2.5 Oro)
2. Cálculo del Recubrimiento Canónico (Fc). (2.5 Oro)
3. Normalización de esquemas relacionales a las formas normales: 1FN, 2FN, 3FN, BCFN. (5 Oro)

En la opción 1, el INPUT deberá ser un esquema relacional y el conjunto de dependencias funcionales básicas (F). El OUTPUT por su parte, deberá ser el conjunto completo de dependencias funcionales (F+) así como las claves candidatas del esquema relacional proporcionado.

En la opción 2, el INPUT deberá el conjunto completo de dependencias funcionales (F+) obtenido en la opción 1 y el OUTPUT el conjunto canónico de dependencias funcionales (Fc).

En la opción 3, el INPUT deberá ser uno o varios conjuntos de esquemas relacionales así como el conjunto de dependencias funcionales básicas y/o claves candidatas. El OUTPUT por su parte, deberá ser el conjunto de esquemas relacionales YA NORMALIZADOS, indicando a qué forma normal se encuentran los esquemas relacionales una vez se haya ejecutado la rutina de normalización.

Entrega y Presentación

El proyecto deberá ser entregado en un CD y el mismo deberá contar con un instalador que permita la instalación del software en cualquier computadora. El software que desarrolle cada equipo de trabajo deberá contar con un nombre y una versión y el mismo deberá ser entregado con un manual de usuario.

Criterios de Evaluación

En cada una de las opciones, se evaluarán los siguientes aspectos (en orden de prioridad):

• Completitud (esto es, que se incluyan todos los componentes enunciados)
• Correctitud (esto es, que realice lo que se indicó)
• Creatividad (esto es, la forma en que cada grupo implementó la solución)

# posted by Franklin Lamelas @ 12:03 a. m. 0 comments

PAUTA 1:

Diseñe un esquema de relación de modo que sea fácil explicar su significado. No combine atributos de varios tipos de entidad ni tipos de relación en una única relación.

EMPLEADO (NSS, NOMBREE, FECHA_NCTO, DIRECCION, NUMEROD)

DEPARTAMENTO (NUMEROD, NOMBRED, NSS_JEFED)

LOCALIZACIONES_DEPT (NUMEROD, LOCALIZACIOND)

PROYECTO (NUMEROP, NOMBREP, LOCALIZACIONP, NUMD)

TRABAJA_EN (NSS, NUMEROP, HORAS)

Diseñe los esquemas de las relaciones de base de modo que NO haya anomalías de inserción, eliminación o modificación en las relaciones.

Esquemas de Relación que Sufren Anomalías de Actualización

EMP_DEPT
(NSS, NOMBREE, FECHA_NCTO, DIRECCION, NUMEROD,NOMBRED, NSS_JEFED)

EMP_PROY
(NSS, NUMERO, HORAS, NOMBREE, NOMBREP, LOCALIZACIONP)

PAUTA 3:

Hasta donde sea posible, evite incluir en una relación de base atributos cuyos valores puedan ser nulos. Si no es posible evitar los nulos, asegúrese de que se apliquen sólo en casos excepcionales y no a la mayoría de las tuplas de una relación.

PAUTA 4:

Diseñe los esquemas de relación de modo que puedan REUNIRSE mediante condiciones de igualdad sobre atributos que sean claves primarias o claves externas, a fin de garantizar que NO se formarán tuplas espurias.

Esquemas de Relación que Permiten Tuplas Espurias

LOCS_EMP (NOMBREE, LOCALIZACIONP)

EMP_PROY1 (NSS, NUMEROP, HORAS, NOMBREP, LOCALIZACIONP)

# posted by Franklin Lamelas @ 9:56 a. m. 0 comments

Invitación

Si eres estudiante de: Ingeniería en Sistemas Computacionales, Ingeniería en Teleco-municaciones, Ingeniería en Mecatrónica, Ingeniería en Informática o Ingeniería en Sistemas Electrónicos

Estás cordialmente invitado a la Reunión Informativa de la IEEE, además de informarte acerca de la próxima Conven-ción de Estudiantes de Centroamérica y Panamá CONESCAPAN XXV.

Aula: 403/02

Hora: 1130 Hrs

# posted by Franklin Lamelas @ 3:18 p. m. 0 comments

Se desea diseñar una base de datos para una red de agencias franquiciadas a MI-CASA, empresa especializada en el alquiler y compra de inmuebles. A continuación se describen los requerimientos obtenidos en la primera entrevista:

Cada agencia tiene un titular y un conjunto de vendedores. Tanto el titular como los vendedores sólo pueden pertenecer a una agencia. De los vendedores interesa almacenar: nombre completo (dos vendedores podrían tener los mismos nombres y apellidos), dirección del domicilio, móvil, correo electrónico, sueldo base y comisión.

Sobre las agencias interesa almacenar: nombre (que es único), dirección, teléfonos (que pueden ser varios), fax y correo electrónico. Además, cada agencia tiene asignada una zona de actuación que es única.

Las agencias disponen de inmuebles que pueden ser locales comerciales, apartamentos o casas. Todos los inmuebles se identifican por un código y se requiere guardar: el propietario, la dirección, la superficie en m2, estado del inmueble (alquiler/venta/ambos). Si el inmueble se alquila, se deberá almacenar el precio del alquiler y el valor del depósito; por el contrario, si el inmueble se vende, se deberá almacenar el precio de venta y si el mismo está o no hipotecado. Si el inmueble se vende o se alquila, se deberán almacenar lógicamente todos los valores recién expuestos.

En el caso de las casas interesa conocer la cantidad de habitaciones, la cantidad de baños, si tiene o no garaje, si tiene o no jardín. Para los locales comerciales se debe conocer si dispone de licencia de apertura y para los apartamentos interesa conocer cantidad de ambientes y si tiene o no incluído los servicios básicos (agua, luz, teléfono, cable).

Un cliente puede acudir a varias agencias (se requiere guardar la fecha en que el cliente visitó cada agencia), en cada una se le asigna sólo un vendedor, que es el encargado de seleccionar los inmuebles que cumplen las características deseadas, y en caso de estar interesado, el cliente debe dar una señal para reservar el inmueble (o los inmuebles) que desea. Un inmueble; sin embargo, sólo puede ser reservado por un cliente. Del cliente se desea almacenar: Número de identidad, nombre completo, teléfono, dirección del domicilio, móvil y correo electrónico (si tiene).

1. Construya el Diagrama Entidad-Relación que mejor modele los requerimientos de información de MI CASA. (0.5 Oro)

2. Reduzca el Diagrama Entidad-Relación generado en el apartado anterior al Esquema Relacional. (0.5 Oro)

# posted by Franklin Lamelas @ 12:27 p. m. 1 comments

El objetivo del presente proyecto es diseñar y construir una base de datos en el SGBD SQL Anywhere 9.0.2 de Sybase así como construir un aplicativo en el lenguaje visual de su elección que interactúe con dicha base de datos por medio de un driver ODBC, JDBC u OLEDB.

La Oficina de Registro del MIN (Museo de la Identidad Nacional) desea que se le diseñe y construya una base de datos y una aplicación que le permita llevar un mejor control sobre el inventario de los bienes culturales que son administrados por el MIN.

El MIN cuenta con una serie de salas que pueden ser de dos tipos: Exhibición Permanente y Exhibición Temporal. Las salas se identifican por medio de un código alfanumérico único; de las salas se desea guardar también: espacio en mts. cuadrados, nombre completo del responsable de la sala (que es un personal de tipo administrativo con cargo de Coordinador), cantidad de lámparas y cantidad de vitrinas. Se desea llevar un control de cada vitrina disponible en cada sala, esto porque en una sala pueden existir vitrinas de distinta forma que deben ser identificables de alguna manera.

Las salas de Exhibición Permanente cuentan con un nombre y una breve descripción de la sala (que ilustra a los visitantes sobre el contenido de los bienes que se exhiben de manera permanente en dicha sala). Por su parte, las salas de Exhibición Temporal cuentan con: nombre de la colección que se exhibe, nombre del museo propietario de la colección, cantidad de piezas que se exhiben, periodo de tiempo de la exhibición (fecha inicial y fecha final).

El MIN cuenta con personal que se puede catalogar de dos tipos: administrativo y técnico. El personal se identifica por medio del número de identidad (en el caso de hondureños) y por el número de pasaporte (en el caso de extranjeros). Adicionalmente, se desea almacenar la siguiente información del personal: nombre completo (nombres y apellidos), domicilio, teléfono del domicilio, teléfono móvil (si posee), correo electrónico, formación académica (primaria/secundaria/universitaria). Todo personal del MIN que sea técnico cuenta adicionalmente con un título (por ejemplo: “curador”, “conservador”, “museógrafo”) y con una serie de especialidades (por ejemplo: frescos, óleo, escultura, orfebrería, entre otros). Por su parte, el personal administrativo cuenta con una cargo (por ejemplo: registrador, coordinador, electricista, carpintero, instalador, vigilante, entre otros).

Un personal de tipo administrativo puede ser responsable de más de una sala del MIN; sin embargo, una sala sólo cuenta con una persona responsable.

Los bienes culturales son identificados por medio de un código único y cuentan además con: nombre, autor, año de realización (si se conoce), antigüedad, clasificación de la obra (pintura/escultura/dibujo), fecha y hora de ingreso al MIN, tipo del ingreso (donación/compra/canje/reubicación) y una historia breve del bien. También se desea almacenar en la base de datos una imagen del bien, de igual forma, se requiere que en el aplicativo se pueda ver una imagen pequeña (thumbnail) del bien.

Del autor de cada bien se desea almacenar: código único de identificación, nombre completo (nombres y apellidos), domicilio, nacionalidad, teléfono del domicilio, correo electrónico (si posee), fecha de nacimiento y edad. Cabe destacar que una obra puede ser realizada por más de un autor y que un autor puede ser el creador de más de un bien.

Un bien cultural cuando ingresa al MIN se ingresa a la Oficina de Registro y una vez codificado el bien, el mismo es ubicado posteriormente en alguna vitrina de una sala de acuerdo a la exposición que se realizará; no obstante, como en una sala pueden coexistir bienes de distinta índole que no necesariamente requieren de alguna vitrina, un bien se ubica directamente en una sala. El aplicativo que se desarrolle deberá indicar dónde se encuentra ubicado exactamente cada bien a una fecha y hora determinada y por qué motivo se encuentra en dicha ubicación; esto es, si aún no ha sido ubicado (por encontrarse en el proceso de registro), en qué sala y vitrina (si el bien requiere de vitrina) o sólo en qué sala (si se trata de bienes que se ubican en las paredes, como es el caso de los cuadros).

En el sistema, cuando un bien es ubicado en alguna sala, se deberá registra la fecha y hora en que el bien ingresa a la sala; igualmente, se deberá registrar el motivo del ingreso a dicha sala. Igualmente, si un bien es movido a otra sala, en el sistema se deberá registrar la fecha y hora en que el bien sale de dicha sala y el motivo por el cual el bien se traslada a otra sala.

El sistema deberá llevar un registro de todos los movimientos que ha experimentado un bien (desde el momento mismo en que ingresa a la Oficina de Registro hasta su ubicación actual).

Se requiere que el aplicativo que se desarrolle cuente con un sub-sistema de control de accesos. Lo anterior se requiere porque existen distintos tipos de usuarios en el sistema con distintos niveles de acceso. Se deberá validar que aquellos usuarios con acceso al sistema (no todo el personal del MIN contaría con un usuario en el sistema) sólo puedan visualizar y operar las pantallas que se enuncian a continuación.

Existen usuarios que mantienen actualizada la información del personal que labora en el MIN. Se trata de usuarios tipo COORDINADOR y básicamente deberán tener acceso a realizar: Alta/Baja/Cambio del Personal en el sistema así como Alta/Baja/Cambio de las Salas y Alta/Baja/Cambio de las Vitrinas que existen en el MIN.

Por su parte existen usuarios del tipo REGISTRADOR que realizan el: Alta/Baja/Cambio de los bienes culturales en el sistema y el Alta/Baja/Cambio de los autores de bienes. Igualmente, los usuarios de tipo REGISTRADOR tienen acceso a ingresar la ubicación inicial de los bienes culturales (luego de que estos han sido inventariados en la Oficina de Registro) así como a mover los bienes de una sala a otra, indicando la fecha, hora y motivo de los movimientos.

Tanto los usuarios de tipo COORDINADOR y REGISTRADOR pueden accesar las pantallas de movimientos experimentados por un bien y ambos tipos de usuarios pueden consultar la ubicación de un bien a una fecha y hora determinada y conocer el motivo por el cual el bien se encuentra en dicha sala.

A. Elaborar un documento impreso que contenga el Diseño Conceptual de la base de datos relacional que resuelva los requerimientos expuestos. El documento en cuestión usará los lineamientos generales contenidos en el Ejemplo de Diseño de una Base de Datos Relacional colocado en el blog de la clase (flamelas.blogspot.com) (5 puntos).

Los apartados del documento deberán ser estos (además de contar con una portada y tabla de contenido):

a. Identificación de Entidades y criterios usados para su selección.

b. Identificación de atributos por Entidad.

c. Identificación de Relaciones o Vínculos existentes y criterios usados para su selección.

d. Identificación de Restricciones de Clave Primaria para las Entidades.

e. Identificación de Restricciones de Cardinalidad de las Relaciones identificadas.

f. Diagrama Entidad-Relación (E-R) construído con el software DIA.

B. Elaborar un documento impreso que contenga el Diseño Lógico y Físico de la base de datos relacional que resuelva los requerimientos expuestos. El documento en cuestión usará los lineamientos generales contenidos en el Ejemplo de Diseño de una Base de Datos Relacional colocado en el blog de la clase (flamelas.blogspot.com). Adicionalmente, el documento contendrá las sentencias DDL del Modelo Relacional. Dichas sentencias se construirán usando la sintaxis SQL del SGBD Sybase Adaptive Server Anywhere 9 tomando en cuenta TODAS las restricciones de integridad necesarias (llaves primarias, llaves foráneas, referencias relacionales, checks). (10 puntos)

Los apartados del documento deberán ser estos (además de contar con una portada y tabla de contenido):

a. Esquema Relacional (2 puntos)

b. Sentencias DDL del SQL de Sybase (1 punto)

Ejecutar en el aula de clases en la base de datos Sybase SQL Anywhere del proyecto, las sentencias DDL (que incluyen las tablas, vistas y demás objetos identificados) así como las sentencias de llenado de las tablas antes creadas con datos muestra (básicamente se deberán llenar TODAS las tablas MAESTRAS). (2 puntos)

Presentar TODAS las pantallas con las que se satisfarán los requerimientos estipulados en el punto C de esta misma sección (en esta entrega se evaluará sólo presentación o diseño de las pantallas). (5 puntos)

C. Construir un aplicativo en un lenguaje de programación visual que interactúe con el SGBD Sybase Adaptive Server Anywhere 9. (13 puntos)

Por medio del aplicativo visual se deben poder realizar las siguientes operaciones de mantenimiento y consulta en la base de datos:

a) Utilizando un usuario tipo COORDINADOR: Crear, borrar, modificar y visualizar los datos de distintos tipos de personal. (2 puntos)

b) Utilizando un usuario tipo COORDINADOR: Crear, borrar, modificar y visualizar los datos de: Salas y de Vitrinas. (3 puntos)

c) Utilizando un usuario tipo REGISTRADOR: Crear, borrar, modificar y visualizar los datos de: Bienes Culturales y de Autores. (3 puntos)

Por medio del aplicativo visual se deben poder realizar las siguientes transacciones sobre la base de datos:

d) Ingresar ubicación inicial de bienes (utilizando un usuario tipo REGISTRADOR). (2 puntos)

e) Realizar movimientos de bienes entre salas (utilizando un usuario tipo REGISTRADOR). (3 puntos)

D. Por medio del aplicativo visual se debe poder satisfacer los siguientes requerimientos de información por medio de consultas a pantalla o de reportes (utilizando un usuario tipo: COORDINADOR o REGISTRADOR): (2 puntos)

a) Mostrar a una fecha determinada, la ubicación de todos los bienes registrados en el sistema. Se deberá presentar: código del bien, nombre del bien, motivo por el cual el bien se encuentra en dicha ubicación. (1 punto)

b) Mostrar el historial de movimientos que ha experimentado un bien (que puede ser cualquiera). Se deberá presentar: código del bien, nombre del bien, fecha y hora de ingreso del bien en cada ubicación, motivo del ingreso, fecha y hora de salida del bien en cada ubicación, motivo de la salida. (1 punto)

· El proyecto tiene un valor total de 30 puntos ORO y deberá ser presentado por ambos integrantes del equipo en el AULA DE CLASES el día que les corresponda.

· Si uno de los miembros del equipo NO se presenta el día de la presentación del proyecto y la causa de su ausencia NO ES JUSTIFICADA, perderá los puntos correspondientes a esa revisión.

· Si un grupo NO se presenta el día que le corresponda, perderá 2.5 puntos ORO por cada día de atraso en la primera entrega, 5 puntos ORO por cada día de atraso en la segunda entrega y 7.5 puntos ORO por cada día de atraso en la tercera entrega.

· A partir de la segunda entrega de la presentación del proyecto, cada equipo deberá traer un computador desde donde le mostrará al profesor distintos aspectos del proyecto desarrollado.

· El proyecto será presentado en tres (3) entregas (La primera con un valor de 5 puntos ORO, la segunda con un valor de 10 puntos ORO y la tercera con un valor de 15 puntos ORO. La primera entrega se efectuará el día: 3 de agosto y comprende el punto A de la descripción del proyecto. La segunda entrega se realizará los días: 30 y 31 de agosto y comprende el punto B de la descripción del proyecto. La tercera y última entrega se llevará a cabo los días: 19 y 20 de septiembre y comprende los puntos C y D de la descripción del proyecto.

· En la primera entrega, cada grupo sólo deberá entregar su documento. Durante la segunda y tercera entrega, además de la entrega de documentos se harán revisiones en el aula de clases (segunda entrega, revisión de scripts DDLs/carga de datos y de pantallas del aplicativo; tercera entrega, revisión de interacción del aplicativo visual desarrollado con la base de datos creada en las fases anteriores).

· Los documentos de la primera y segunda entrega serán revisados por el profesor y serán entregados hasta el día lunes de la siguiente semana con las correcciones sugeridas para cada caso. Cada grupo deberá aplicar dichas correcciones antes de proceder con las siguientes etapas del proyecto.

· En la última entrega, cada grupo deberá presentar la versión final impresa del documento del diseño de la base de datos relacional, un manual de usuario donde se muestre el uso del aplicativo desarrollado y un CD que contenga el aplicativo desarrollado y la base de datos Sybase SQL Anywhere creada.

El documento impreso deberá contener:

o Portada

o Tabla de contenido

o Introducción

o Objetivos

o Versión corregida del Diseño Conceptual

o Versión corregida del Diseño Lógico y Conceptual

o Conclusiones

o Bibliografía

o Anexos (Manual de Usuario)

El CD deberá contener los códigos fuente y objeto del software de aplicación desarrollado. Se deberán incluir los scripts DDLs de creación de la base de datos y los scripts de llenado de tablas. Se deberá incluir la base de datos final con los datos de muestra. Igualmente, se deberá incluir el manual de usuario.

· Toda consideración que se haga en el proyecto, deberá estar debidamente documentada y justificada en los distintos documentos donde se aplique.

· Cada grupo deberá construir y darle mantenimiento a un ciberdiario (blog site) (usando las facilidades que provee el blogger.com). En este blog site, se deberán colocar avances semanales en el desarrollo del proyecto. Cada grupo deberá enviarme por correo electrónico la dirección de su blog.

· La descripción del proyecto representa los productos mínimos esperados en este proyecto y se podrán otorgar puntos adicionales sólo si el proyecto excede las expectativas de todos los productos mínimos esperados en el mismo.

· El calendario de entregas por grupo se muestra al final de este documento.

# posted by Franklin Lamelas @ 9:53 a. m. 0 comments