Diseño de Bases de Datos

1

GUÍA DE ENTREGA DEL PROYECTO DEL CURSO

CARRERA : Ingeniería de Sistemas – Estudios Profesionales para Ejecutivos CURSO : Diseño de Bases de Datos

PROFESORES : Alberto Capcha / Jorge del Mar / Lizardo Silva / Carlos Rabines SECCIONES :

CONTENIDO

CRONOGRAMA DE ENTREGAS ............................................................................................................................. 2 ENTREGAS ..................................................................................................................................................................... 3 Contenido del documento en Word:.................................................................................................................... 4 Contenido del modelo en Oracle SQL Developer Data Modeler: ................................................................. 6 SUSTENTACIÓN........................................................................................................................................................... 7 CRITERIOS DE EVALUACIÓN DEL TRABAJO FINAL ................................................................................... 8

El trabajo grupal se desarrollará a lo largo de todo el ciclo. El seguimiento al avance será evaluado a través de informes que los grupos entregarán a los profesores en las fechas y modalidades fijadas en este documento.

Diseño de Bases de Datos

2

CRONOGRAMA DE ENTREGAS

Las fechas, contenido y peso de los informes de avance y entregas son las siguientes:

N° Sesión A41A D42A E42A X41A Entrega

Distribución del peso de la nota del Trabajo final

Observaciones

1 6 22 ene.. 24 ene. 24 ene. 24 ene. (A y B) 30% Por el aula virtual

2 10 05 feb. 07 feb. 07 feb. 07 feb. (C y D)

70 % Por el aula virtual

12 17 feb. 16 feb. 19 feb. 18 feb. Sustentación de trabajos En la sesión de clase

Diseño de Bases de Datos

3

ENTREGAS

Entrega 1:

(A): Considerando que el punto de partida para un adecuado diseño es la correcta identificación de las dependencias funcionales entre los datos y su consecuente normalización, lo que se deriva de lo que cada uno de ellos significa, cada grupo deberá subir al aula virtual un documento en Word

con el siguiente contenido:

Las hipótesis en las que basarán su análisis. Esto es, las reglas de negocio que incorporarán en el modelo, ya sea derivadas directamente del enunciado del caso o

precisando puntos que pudieran aceptar más de una interpretación válida. En ningún caso estas hipótesis podrán estar en conflicto con lo presentado en el enunciado de cada tema de trabajo.

Una relación de los elementos de datos a considerar: nombre único ajustado al estándar y definición clara (tipo glosario). Presentarla como lista, sin agrupar en lo que estiman que serán las entidades resultantes del proceso posterior de normalización .

Ejemplo:

CoAlumno Código de identificación del alumno, único absoluto en todo el sistema

QtNota Nota obtenida por un alumno en una evaluación de un curso

CoCurso Código de identificación del curso, único en cada facultad

NoCurso Nombre del curso

CoCiclo Código de identificación del período lectivo o ciclo académico, único absoluto.

CoFacultad Código de identificación de la facultad, único absoluto

(B): Diagrama de dependencias funcionales, procedimiento de normalización y relación de entidades derivadas del proceso de normalización.

Entrega 4 (Entrega Final):

(C): Distribución de responsabilidades en el modelado y modelo de datos.

Ejemplo:

Nombre del miembro del grupo Responsabilidad en el modelo

Juan Pérez Productos, su formulación e insumos

Pedro López Clientes y ventas

María Gonzáles Vendedores, almaceneros, transportistas y empleados en general

Diseño de Bases de Datos

4

(D): Documento y modelo según instrucciones a continuación:

Fechas límite de entrega:

Sección A41A: hasta el jueves 05 de febrero a las 11 pm.

Sección D42A: hasta el sábado 07 de febrero a las 11 pm.

Sección E42A: hasta el sábado 07 de febrero a las 11 pm.

Sección X41A: hasta el sábado 07 de noviembre a las 11 pm.

En la fecha y hora señalada cada grupo colocará en el Aula Virtual o enviará por correo un archivo zip con el siguiente contenido:

Documento en Word de su informe

Modelo en Oracle SQL Developer Data Modeler

El retraso u omisión en el envío según lo indicado será tomado en cuenta en la evaluación.

Contenido del documento en Word:

1. Enunciado del problema (incluir el texto completo)

2. Reglas de negocio.

Las reglas de negocio extraídas del enunciado del caso y del análisis efectuado: supuestos o cosas que se asumen como válidas y sobre las que se basará la concepción y estructura de

la base de datos

3. Descripción y Documentación de los Elementos de Datos

Elaborar una lista con los elementos de datos o atributos relevantes para dar soporte al caso de estudio, asegurando que no dejen ningún aspecto importante de éste sin soporte, o cuya omisión en esta etapa del trabajo impacte en la estructura del modelo a elaborar.

Posteriormente, en el desarrollo del modelo conceptual (acápite 5) pueden incluir un mayor nivel de detalle.

Nombre: Según estándar, único.

Definición: Una oración clara y completa del significado del atributo y de su propósito y uso en el sistema, si es preciso incluyendo ejemplos que aclaren cada

concepto. Para los códigos indicar si son únicos absolutos, únicos dentro de determinado grupo, etc.

Tipo de dato: Longitud y dominio del atributo.

Rango: Si los datos son numéricos se debe especificar los límites superior e inferior del rango (mayor que cero y menor que 100, etc.)

Unidad de medida: de ser aplicable.

Valores restringidos: Si los valores permitidos están limitados a un conjunto de palabras o caracteres particulares lo suficientemente invariable. Ejemplos: los valores para el Sexo pueden ser “masculino” o “femenino”; los estados de un pedido

“pendiente”, “atendido”, “cancelado”, “anulado”.

Diseño de Bases de Datos

5

Valores por omisión: de ser aplicable.

4. Refinamiento

Normalización.

Gráfico de dependencias funcionales

Procedimiento de Normalización

Conjunto de relaciones resultante.

Relación de Entidades.

La relación de entidades derivadas del proceso de normalización, con una definición clara que permita establecer sin ambigüedades los ejemplares o instancias de entidad que representa.

Relación de Entidades

Id Entidad Descripción

5. Modelado

Especificar las responsabilidades de cada integrante del grupo en el modelo elaborado. Cada estudiante debe ser “propietario” de un m ínimo de cuatro entidades.

Ejemplo:

Nombre del miembro del grupo

Responsabilidades

Juan Pérez Entidades: Producto, Formula, Insumo, Categoria_Productos

Producto Cada uno de los productos que se

fabrican o comercializan en la empresa.

Formula Combinación de insumos necesarios para la fabricación de

los productos

Insumo Elemento empleado en la fabricación de uno o más productos

Categoria_Producto Clasificación de los productos de

acuerdo a su condición de: lácteos, panadería,

Pedro López Clases: Cliente, Venta, Detalle_Venta, Tipo_Venta, Tipo_Cliente

Cliente Persona natural o jurídica a quien la empresa vende sus productos.

Venta Transacción de venta realizada a

un cliente, de uno o más productos

Detalle_Venta Cada uno de los productos vendidos a un cliente en una

Diseño de Bases de Datos

6

transacción de venta

Tipo_Venta Calificación de las transacciones de venta de acuerdo a la forma en que es colocada (en tienda,

telefónica, web, etc.)

Tipo_Cliente Clasificación de los clientes según su nivel de compra en montos.

Contenido del modelo en Oracle SQL Developer Data Modeler:

1. Modelo Lógico.

Elaborar el modelo lógico para el caso de estudio, el que deberá comprender:

Usar la notación Bachman

Entidades nombradas y definidas adecuadamente.

Atributos de cada entidad, nombrados de acuerdo al estándar empleando minúsculas, definidos y con tipo de dato asignado

Atributos de cada entidad que serán parte de la identificación de la misma (los que en el modelo de datos conformarán las respectivas PK)

Relaciones entre las entidades, con nombre, cardinalidad y tipo: identificativa y no

identificativas.

Diagrama Lógico que muestre todos los elementos del modelo. Las entidades que son responsabilidad de cada integrante del grupo deben tener un color que

identifique visualmente a su propietario.

2. Modelo Relacional

Empleando Data Modeler generar el modelo de Relacional a partir del modelo Lógico:

En cuarta forma normal.

Asignar valores por omisión (default) para las columnas que lo ameriten.

Establecer soporte para columnas que admitirán nulos.

Definir restricciones de tabla y de columna (listas de valores, rangos, etc.)

Las tablas que son responsabilidad de cada integrante del grupo deben tener un

color que identifique visualmente a su propietario, correspondiéndoles el mismo color de las entidades que le dan origen.

IMPORTANTE

Todos los elementos deberán estar apropiadamente documentados y definidos en el mismo modelo de manera que no deberá ser necesario recurrir al

documento en Word para su interpretación.

Diseño de Bases de Datos

7

SUSTENTACIÓN

Orientaciones para la sustentación

Todos los miembros de cada grupo deben tener dominio completo del modelo elaborado, no solamente de lo que fue su responsabilidad desarrollar.

No es necesario que preparen ninguna presentación en Power Point.

La sustentación se realizará con el trabajo entregado en las fechas fijadas en este documento, según sección.

Al momento de la sustentación solamente estarán presentes en el salón los alumnos del

grupo que expone, de acuerdo a la programación que se les hará llegar en su oportunidad.

Para iniciar la sustentación deben estar presentes todos los miembros del grupo.

El tiempo asignado a cada grupo fluctuará entre 20 y 25 minutos, dependiendo de la

cantidad de integrantes.

Los profesores del jurado plantearán preguntas individuales a cada uno de los miembros del grupo. Se evaluará la pertinencia y seguridad en las respuestas.

Las preguntas podrán ser, entre otras, del tipo:

o Explicar alguna parte del modelo (no necesariamente la trabajada por el alumno a quien se formula la pregunta).

o ¿Qué sucedería si cambian las reglas del negocio de alguna manera en particular? Explicar el impacto en el modelo, de haberlo.

o Se desea conocer cierta información relacionada con el tema, ¿es posible con el

diseño elaborado? Si no es posible, ¿qué cambio habría que realizar para atender el requerimiento?

o Explicar las razones por las que se ha diseñado el modelo de cierta manera, en

lugar de alguna otra posible (tipos de relaciones elegidas, entidades consideradas, cardinalidad, etc.)

Diseño de Bases de Datos

8

CRITERIOS DE EVALUACIÓN DEL TRABAJO FINAL

Evaluación Grupal

Avance continuo 6.00

Descripción y Documentación de los elementos de datos 2.00

Diagrama de dependencias funcionales 3.00

Normalización 1.00

Integración del modelo 6.00

Presentación (orden, redacción, ortografía) 2.00

Puntualidad (2 puntos menos por cada 12 horas de retraso en la entrega)

(en contra)

Nota Grupal (TG) 20.00

Evaluación Individual

Avance continuo 2.00

Nombre apropiado y definición de entidades 0.50

Nombre apropiado (único) y definición de atributos 0.50

Nombres y tipo de relaciones 0.50

Tipo de dato de los atributos 0.50

Solución del problema en 4FN. Incluye cardinalidad de las relaciones, FK nulas y construcción apropiada 6.00

Valores por omisión y soporte para nulos 1.00

Restricciones a columnas y tablas 1.00

Sustentación 8.00

Nota Individual (TP) 20.00

FÓRMULA DE NOTA DE TRABAJO FINAL:

(TG + TP * 3 ) / 4

Donde: TG = 0.3 * E1 + 0.7*E2