Proyecto Pedidos-Correo

Tecnológico Nacional de México Instituto Tecnológico de Chilpancingo Ingeniería en Sistemas Computacionales Asignatura:

Views 88 Downloads 1 File size 324KB

Report DMCA / Copyright

DOWNLOAD FILE

Recommend stories

  • Author / Uploaded
  • Wolf
Citation preview

Tecnológico Nacional de México Instituto Tecnológico de Chilpancingo Ingeniería en Sistemas Computacionales Asignatura: Fundamentos de base de datos

Base de datos PEDIDOS_CORREO

Elaboro: - Garcia Ramos Cesar Emmanuel Numero de control: 18520372

Planteamiento Diseñe el diagrama Entidad – Relación para la descripción del siguiente problema a resolver utilizando para ello una base de datos, construya el diseño de esta, utilizando la herramienta de modelado de datos Dia. Para el diseño considere una base de datos PEDIDOS_CORREO en la que los empleados registran los pedidos de piezas por parte de los clientes. Los requisitos en cuanto a datos son los siguientes: 1. La empresa de venta por correo tiene empleados identificados por un número de empleado único, además del nombre, los apellidos y el código postal. 2. Cada cliente de la empresa está identificado mediante un numero de cliente único, el nombre los apellidos y el código postal. 3. Cada pieza o repuesto vendido por la empresa está identificado por un numero de repuesto único, un nombre, un precio y la cantidad en stock. 4. Cada pieza o repuesto es fabricado por un fabricante, y este está identificado por la empresa por medio de un número único, el nombre los apellidos y el código postal. 5. Cada pieza o repuesto es surtido a la empresa a través de un proveedor, y este está identificado por la empresa por medio de un número único, el nombre los apellidos y el código postal. 6. Cada código postal, pertenece a una colonia y una ciudad. 7. Cada pedido efectuado por un cliente es registrado por un empleado y se le asigna un número de pedido que es único. Cada pedido (detalle pedido) contiene la cantidad especificada de uno o más repuestos, la fecha de recibido, fecha de envió estimada. También se registra la fecha de envió real. 8. Cada pedido genera una factura, la factura tiene un número único, la fecha de la emisión de la factura, el dato de a quien se le expide la factura, la cantidad total por la que se emite la factura, y el dato del pedido al que corresponde la factura.

Identificación de las entidades y sus atributos Empleado • • • •

Número de empleado (NumEmpleado) Nombre (Nombre) Apellidos (Apellidos) Código postal (CP): o Colonia (Colonia) o Ciudad (Ciudad)

Cliente • • • •

Número de cliente (NumCliente) Nombre (Nombre) Apellidos (Apellidos) Código postal (CP): o Colonia (Colonia) o Ciudad (Ciudad)

Pieza • • • •

Número de repuesto único (NumPieza) Nombre (Nombre) Precio (Precio) Cantidad en stock (CantStock)

Fabricante (Entidad Débil) • • • •

Número único (NumFabricante) Nombre (Nombre) Apellidos (Apellidos) Código postal (CP): o Colonia (Colonia) o Ciudad (Ciudad)

Proveedor (Entidad Débil) • • • •

Número único (NumProveedor) Nombre (Nombre) Apellidos (Apellidos) Código postal (CP): o Colonia (Colonia) o Ciudad (Ciudad)

Pedido • • • • •

Número de pedido (NumPedido) Cantidad de los repuestos (CantRepuestos) Fecha de recibido (FechaRec) Fecha de envió estimada (FechaEnv) Fecha de envió real (FechaReal)

Factura • • • •

Número de factura (NumFactura) Dato de quien se le expide la factura (Comprador) Cantidad total por la que se emite la factura (Precio) Pedido al que corresponde la factura (NumPedido)

El diagrama Entidad – Relación queda de la siguiente manera

a) Conversión del Modelo Entidad – Relación a Modelo relacional

Transformamos cada entidad a una tabla, posteriormente analizar la interrelación que existe. Identificando el atributo primario y pasándolo como Llave Primaria (PK)

b) El esquema de la base de datos.

Empresa_Envios = {Empleado, Proveedor, Pedido, Factura}

Cliente,

Pieza,

Fabricante,

Diagrama del esquema de la base de datos relacional EMPRESA Empleado NumEmpleado

Nombre

Apellidos

CP

Cliente NumCliente

Nombre

Apellidos

CP

Pieza NumPieza

Nombre

Precio

CantStock

NumFabricante

Fabricante NumFabricante

Nombre

Apellidos

CP

Proveedor NumProveedor

Nombre

Apellidos

CP

Pedido NumPedido

CantRepuestos

Factura NumFactura

FechaRec

Comprador

FechaEnv

FechaReal

Precio

NumEmpleado

NumCliente

NumPedido

NumFactura

NumCliente

c) El esquema que define los atributos de las relaciones (dominio). Empleado (NumEmpleado:interger, Nombre:String, Apellidos:String, CP:String)

Cliente (NumCliente:interger, Nombre:String, Apellidos:String, CP:String)

Pieza (NumPieza:interger, Nombre:String, Precio:Decimal, CantStock:integer, numFabricante:integer)

Fabricante (Entidad Débil) (NumFabricante:interger, Nombre:String, Apellidos:String, CP:String)

Proveedor (Entidad Débil) (NumProveedor:interger, Nombre:String, Apellidos:String, CP:String)

Pedido (NumPedido:interger, CantRepuestos:integer, FechaRec:date, FechaEnv:date, FechaReal:date, NumEmpleado:integer, NumCliente:integer, NumFactura:integer)

Factura (NumFactura:interger, Comprador:String, Precio:decimal, NumPedido:integer)

d) Las restricciones de integridad referencial mostradas en el esquema relacional

a) Determinar las dependencias funcionales y transitivas. NumEmpleado-> {Nombre, Apellidos} NumCliente-> {Nombre, Apellidos, CP} NumPieza-> {Nombre, Precio} NumFabricante-> {Nombre, Apellidos} NumProveedor-> {Nombre, Apellidos} PrecioFactura-> {CantRepuestos, PrecioPieza} NumPedido-> {FechaRec, FechaEnv, FechaReal}

b) Aplicar la 1FN, 2FN, 3FN y Forma normal Boyce-Codd (BCFN).

Primera forma normal.

En este caso, como apreciamos en la tabla, nos podemos dar cuanta de que no existen atributos multivalor, ni compuestos. Esta tabla esta optimizada para no incluir redundancia de los datos. La 1FN prohíbe los grupos repetidos, en este caso ya tenemos separados en las determinadas entidades. Por lo que ya estaría aplicada la primera forma normal.

Segunda forma normal Tenemos que eliminar cualquier columna no llave que no dependa de la llave primaria de la tabla. Los pasos a seguir son: 1. Determinar cuáles columnas que no son llave y que no dependen de la llave primaria de la tabla. 2. Eliminar dichas columnas de la tabla base. 3. Crear una segunda tabla con esas columnas y la(s) columna(s) de la PK de la cual dependen. Al aplicar estas reglas nuestras entidades quedarían de la siguiente manera: Empleado NumEmpleado NombreEmpleado ApellidosEmpleado CPEmpleado Pedido NumPedido CantRepuestos FechaRec FechaEnv FechaReal NumEmpleado NumCliente NumFactura

Factura NumFactura NombreCliente PrecioFactura NumPedido NumCliente

Cliente NumCliente NombreCliente ApellidosCliente CPCliente

Pieza NumPieza NombrePieza PrecioPieza CantStock NumFabricante NumProveedor

Proveedor NumProveedor NombreProveedor ApellidosProveedor CPProveedor NumFabricante

Fabricante NumFabricante NombreFabricante ApellidosFabricante CPFabricante

Tegunda forma normal La 3FN nos dice que tenemos que eliminar cualquier columna no llave que sea dependiente de otra columna no llave. Los pasos a seguir son: • Determinar las columnas que son dependientes de otra columna no llave. • Eliminar las columnas de la tabla base. • Crear una segunda tabla con esas columnas y con la columna no llave de la cual son dependientes. Si revisamos las entidades, verificamos que cumples con lo señalado para la tercera forma normal. Por lo tanto, el modela relacional quedaría de la siguiente manera: