Vigo Briones BD Actividad 1

UNIVERSIDAD NACIONAL DE TRUJILLO FACULTAD DE INGENIEÍRA ESCUELA PROFESIONAL DE INGENIERÍA DE SISTEMAS ACTIVIDAD N°1 NOR

Views 31 Downloads 0 File size 1MB

Report DMCA / Copyright

DOWNLOAD FILE

Recommend stories

Citation preview

UNIVERSIDAD NACIONAL DE TRUJILLO FACULTAD DE INGENIEÍRA ESCUELA PROFESIONAL DE INGENIERÍA DE SISTEMAS

ACTIVIDAD N°1 NORMALIZACIÓN DE DATOS  DOCENTE

: Dr. Boy Chavil, Luis Enrique

 ESTUDIANTE : VIGO BRIONES DIEGO ERNESTO



CICLO

: SÉPTIMO

TRUJILLO – PERÚ

202

Vigo Briones Diego Ernesto

Ing Sistemas

ACTIVIDAD N°1 Elabore el modelado de datos normalizado, paso a paso, desde la entidad (Tabla) no normalizada, hasta la 5NF, en el siguiente caso:

Consideraciones adicionales - El Pedido contiene varias especificaciones. - Los productos que se fabrican se encuentran en un mismo Lote de fabricación especificado por un número. Un mismo Lote puede estar en muchas órdenes de producción. - Cada orden de producción solamente contiene un Producto. - En Materiales requeridos: SubTotal = Precio x Cantidad - En Actividades: SubTotal = HorasTrabajadas x ValorHora - En Gastos Indirectos: SubTotal = Cantidad x CostoUnitario; - Los Items; de Gastos Indirectos, son: Materiales indirectos, Labor indirecta, Otros gastos (por ejemplo: Renta, depreciación, Luz, Reparación, Seguros, Combustibles, Aceites, etc.) - Fecha de presentación de la actividad: Semana Nº 02 (Lunes 13 de julio del 2020) - Hora de presentación: 17:00. Ingresado en el Aula Virtual.

Vigo Briones Diego Ernesto

Ing Sistemas

Entidad No Normalizada

Tenemos la siguiente entidad no normalizada: OrdenProduccion(NOrden,FechaOrden,Referencia,FechaPedido,CodigoProvinciaSolicit ante,Provincia,CodigoResponsableProv,NombreResponsableProv,TextoEspecificacion, CodigoProducto,Descripcion,UnidadMedida,Cantidad,FechaInicioProduccion,FechaFin Produccion,CodigoRecepcionistaProduccion,NombreRecepcionistaProduccion,FechaRe cepcion,HoraRecepcion,FechaEntradaAlmacen,NLoteFabricacion,FechaExpiracionProd ucto ,MR_NVale, MR_Codigo, MR_Descripcion, MR_Medida, MR_Precio, MR_Cantidad, MR_SubTotal, A_Codigo, A_Descripcion, A_NObreros, A_HorasTrab, A_ValorHora, A_SubTotal,GI_Item, GI_Descripcion, GI_Cant, GI_CostoUnit, GI_SubTotal, GI_Observ )

Vigo Briones Diego Ernesto

Ing Sistemas

1. Primera Forma Normal Notamos un grupo de datos repetitivos conformado por los atributos correspondientes a la tabla detalle de la Producción ordenada. Separamos los atributos en 3 grupos correspondientes a las 3 subtablas de la imagen. De igual manera, existe el campo Especificaciones, en el cual se detallan las especificaciones de la produccion deseada, ya que en una misma orden pueden haber varias especificaciones, también separamos este campo.



Se han creado las tablas: Detalle_MaterialRequerido(NOrden, MR_NVale, MR_Codigo, MR_Descripcion, MR_Medida, MR_Precio, MR_Cantidad, MR_SubTotal, ValeDescripción) Detalle_Actividad(NOrden ,A_Codigo, A_HorasTrab, A_ValorHora, A_SubTotal) Detalle_GastoIndirecto(NOrden ,GI_Item, GI_CostoUnit, GI_SubTotal, GI_Observ) Especificacion(NOrden, TextoEspecificacion)

A_Descripcion,

A_NObreros,

GI_Descripcion,

GI_Cant,

Nota: en Detalle_MaterialRequerido se ha creado el campo ValeDescripción aunque no se encuentre en la ficha brindada, esto para que en el futuro podamos tener el registro de cada vale y su texto referido.

Vigo Briones Diego Ernesto

Ing Sistemas

2. Segunda Forma Normal Se ha supuesto que, de los materiales ya están definidos los campos descripción, medida y precio actual. Sin embargo crearemos un atributo Precio para tener un historial de operaciones de los precios que fueron pagados al momento de la compra. En Actividad y GastoIndirecto, se ha supuesto que ya está definida únicamente la descripción. Analizando, encontramos dependencias parciales a elminar con la 2NF en los siguientes casos:  En la tabla Detalle_MaterialRequerido , Los campos MR_Descripcion, MR_Medida,MR_Precio dependen de MR_Codigo, por lo tanto tenemos una dependencia parcial a eliminar. MR_Codigo → MR_Descripcion MR_Codigo → MR_Medida MR_Codigo → MR_Precio  En la tabla Detalle_MaterialRequerido , el campo ValeDescripcion depende de MR_NVale, por lo tanto tenemos una dependencia parcial a eliminar. MR_NVale→ ValeDescripcion  En la tabla Detalle_Actividad, el campo A_Descripción depende de A_Codigo, por lo tanto tenemos una dependencia parcial a eliminar. A_Codigo → A_Descripcion

Vigo Briones Diego Ernesto 

Ing Sistemas

En la tabla Detalle_GastoIndirecto, el campo descripción depende de GI_Item, por lo tanto tenemos una dependencia parcial a eliminar. GI_Item → GI_Descripcion

Se han creado las tablas: MaterialRequerido(MR_Codigo,MR_Descripcion,MR_Medida,MR_PrecioActua l) Actividad(A_Codigo,A_Descripcion) GastoIndirecto(GI_Item,GI_Descripcion) Vale(NVale,ValeDescripcion) Nota: el atributo MR_NVale, al moverse a la nueva tabla Vale, se cambió de nombre a NVale pues ya no forma parte de Detalle_MaterialRequerido

3. Tercera Forma Normal En la 3ra forma normal debemos ajustar las entidades para que todos los atributos de las entidades dependan funcionalmente de su clave primaria, de lo contrario creamos una nueva tabla. 

En la tabla OrdenProduccion los CodigoResponsableProvincia dependen

atributos ProvinciaNombre, funcionalmente de

Vigo Briones Diego Ernesto







Ing Sistemas

CodigoProvinciaSolicitante. Por lo cual creamos la tabla Provincia. (En la cual crearemos también otra tabla llamada Responsable para alojar el código y el nombre de los responsables) CodigoProvinciaSolicitante → ProvinciaNombre, CodigoResponsableProvincia, NombreResponsableProvincia. En la tabla OrdenProduccion el atributo NombreRecepcionistaProduccion depende funcionalmente de CodigoRecepcionistaProduccion. Por lo cual creamos la tabla Recepcionista. CodigoRecepcionistaProduccion→ NombreRecepcionistaProduccion En la tabla Detalle_MaterialRequerido el atributo MR_ValeDescripción depende de MR_NVale. Por lo cual creamos la tabla Vale, añadimos un atributo ValeDescripción a esta tabla para que no exista vacía. MR_NVale → MR_ValeDescripción En la tabla OrdenProduccion el atributo FechaExpiraciónProducto depende del NLoteFabricación. Por lo cual creamos la tabla Lote. NLoteFabricación → FechaExpiraciónProducto



  

En la tabla OrdenProduccion los atributos Descripcion y unidad de medida dependen funcionalmente de CodigoProducto. Por lo cual creamos la tabla Producto. Esta tabla podrá adherirse a la tabla Lote,puesto que un mismo lote siempre almacenará un mismo Producto. CodigoProducto→ Descripcion,UnidadDeMedida En la tabla Detalle_MaterialRequerido, borramos el campo MR_SubTotal puesto que es calculable. En la tabla Detalle_Actividad, borramos el campo A_SubTotal puesto que es calculable. En la tabla Detalle_GastoIndirecto, borramos el el campo GI_SubTotal puesto que es calculable.

Vigo Briones Diego Ernesto

Ing Sistemas

4. Forma Normal Boyce Codd La forma normal de Boyce Codd nos dice qué, para estar normalizadas nuestras entidades deben estar en 3FN y además, Para cada dependencia funcional no trivial que exista, el determinante debe ser una super llave. Analizamos entonces las relaciones existentes dentro de la entidad Detalle_MaterialRequerido, la cual tiene una Primary Key de 3 atributos. 

La primera relación que notamos, es la siguiente: MR_Codigo,NOrden → Precio, cantidad

Sabemos que MR_Codigo,NOrden forman una llave concatenada que es una superclave pues determina a todos los atributos. 

Y Aunque en una orden puedan aparecer varios vales, debemos notar que un vale solo puede aparecer en una orden, por lo tanto un NVale siempre estará correspondiendo a solamente un NOrden. NVale→NOrden

Sabemos que NVale no es una superclave, pues no puede determinar a los atributos Precio y Cantidad en Detalle_MaterialRequerido, por lo cual viola la Forma Normal de Boyce Codd.

Para solucionar este problema, separamos la relación de NOrden y NVale, creando una nueva tabla Vale_Orden.

Vigo Briones Diego Ernesto

Ing Sistemas

5. Cuarta Forma Normal Para convertir nuestro modelo de datos a la 4FN, buscamos dependencias funcionales multivaluadas. Notamos que en la tabla Pedido, existe el campo TextoEspecificación el cual corresponde a una dependencia funcional multivaluada, pues un NPedido puede tener varias especificaciones.

Procedemos entonces, a crear 2 tablas para crear la conexión de muchos a muchos (se ha supuesto que una especificación puede ya estar definida además de poder escribirse al momento de generar la orden).

Vigo Briones Diego Ernesto

Ing Sistemas

Se han creado las tablas Especificacion y EspecificacionADD.

6. Quinta Forma Normal En este caso, la tabla OrdenProduccion presenta algunos campos que, si bien sí corresponden al atributo NOrden, podrían ser separados en una nueva entidad denominada Produccion. De manera que tengamos los datos bien clasificados.