avance metodología final

ÍndicePropuesta..............................................................................................................................4

Motivo o Justificación.......................................................................................................4Descripción Detallada de los Requerimientos del Diseño...............................................5Requerimientos del Sistema de Inventario y Facturación................................................6Requerimientos Generales................................................................................................8

Desarrollo Etapas......................................................................................................9

Etapa MDL1..................................................................................................................9Identificar las Entidades.....................................................................................9

Nombrar las Entidades..............................................................................................9Diagramar Entidades...............................................................................................10Diccionario de Datos...............................................................................................11

Etapa MDL2................................................................................................................13Determinar Asociaciones..................................................................................13

Nombrar, Definir y Documentar.............................................................................13Diagramar Asociaciones..........................................................................................15

Etapa MDL3................................................................................................................18Determinar Llaves...............................................................................................18

Llaves Primarias......................................................................................................18Llaves Alternas........................................................................................................19Diccionario de Datos...............................................................................................19

Llaves Primarias..................................................................................................19Llaves Alternas....................................................................................................21

Diagrama.................................................................................................................22Diagrama MDL3.....................................................................................................24

Etapa MDL 4...............................................................................................................25Determinar Llaves Externas............................................................................25

Llaves Externas.......................................................................................................25Nombrar...................................................................................................................26Diccionario de Datos...............................................................................................27Diagrama MDL 4...................................................................................................29

Etapa MDL 5:..............................................................................................................30Determinar Reglas Llave..................................................................................30

Reglas de Inserción................................................................................................30Reglas de Supresión...........................................................................................32

Etapa MDL6................................................................................................................38Agregar Atributos No Llave.............................................................................38

Entidades.................................................................................................................38Nombrar Atributos..................................................................................................41Diccionario de Datos...............................................................................................43

Modelado de Datos Lógicos

Diagrama de Atributos............................................................................................46Diagrama MDL 6....................................................................................................50

Etapa MDL 7...............................................................................................................51Validar Reglas de Normalización..................................................................51

Primera Forma Normal (1N):..................................................................................51Segunda Forma Normal (2N):.................................................................................51Tercera Forma Normal (3N):..................................................................................51

Entidades Normalizadas......................................................................................52Forma Normal Boyce\ Codd (FNBC):....................................................................53Cuarta Forma Normal (4FN):..................................................................................53Quinta Forma Normal (5FN):..................................................................................53Entidades Normalizadas..........................................................................................54Atributos:.................................................................................................................55Diagrama MDL 7....................................................................................................56

UNIVERSIDAD DE COSTA RICASede Guanacaste

2


Propuesta

Motivo o Justificación.

Como estudiantes de la carrera de Informática Empresarial de la Universidad de Costa

Rica sede de Guanacaste, que actualmente tramitamos el curso IF4100 Base de Datos y en

complemento con el curso correquisito IF4101 Lenguajes para Aplicaciones Comerciales,

desarrollaremos el proyecto final en una empresa seleccionada por nosotros como estudiantes.

Para poder desarrollar este proyecto final estará basado en la metodología Flemming/Von

Halle, la cual es una metodología que define los elementos necesarios para el diseño de una base

de datos; hemos seleccionado una empresa de la localidad de Liberia localizada en el Barrio

Moracia al frente de la Cruz Roja, la cual se desempeña en la venta de una gran variedad de ropa

(para niños, caballeros, damas, ropa intima, entre otros).

Tomando en cuenta que dicha Empresa no cuenta con un sistema informático para realizar

sus necesidades hemos decidido desarrollar nuestro proyecto en este negocio, con el fin de

facilitar el manejo de la empresa de la mejor manera.


3


Descripción Detallada de los Requerimientos del Diseño.

Este proyecto final consiste en desarrolla un Sistema informático Comercial en el

ambiente de desarrollo de Visual Basic.NET, el cual interactuará con una base de datos

relacionada en SQL Server. Este sistema a implementar debe contar con un registro de una serie

de articulos para una empresa que se dedica a la venta de una gran variedad de prendas en la

provincia de Guanacaste.

El sistema deberá permitir al usuario manejar un sistema de inventario; el cual le permitirá

realizar una de las siguientes opciones: incluir los productos, actualizar, eliminar productos del

inventario y facturar las ventas.

También le permitirá al usuario hacer unas consultas como: los productos vendidos

diariamente, apartados, entre otras.

Para la elaboración de dicho sistema se debieron plantear múltiples opciones para dar

solución a cada uno de los problemas hasta poder escoger el procedimiento mas adecuado para la

solución de este.

En este sistema se incluirán las opciones que tiene el operador del programa para facilitar

la acción y simplificación del usuario, dado en los casos en los cuales el usuario no tenga

conocimiento alguno sobre temas que abarcan la Informática y la Computación.


4


Requerimientos del Sistema de Inventario y Facturación

1. Modulo de Autenticación: El sistema deberá permitir al usuario autenticarse con su

respectivo login y password para poder ingresar.

2. El sistema de inventario: Este deberá administrar los campos necesarios para llevar el

control de las prendas ingresadas a la empresa. Entre los campos con que este debe contar

son los siguientes:

Cantidad: Controlará el numero total de cada una de las prendas.

Código del Proveedor: Código que registra la administradora para llevar el control de las

prendas enviadas por la proveedora.

Código Local: Código que utiliza la administradora para llevar ella misma el control

interno de la empresa (ingreso de prendas al inventario).

Descripción del Producto: Este se debe dividir en tres campos:

Estilo: Donde se describirá si la prenda es a rayas, lisa, Estampada, entre otras.

Tipo: Se describirá si la prenda es casual, de vestir, Pijama, ropa íntima.

Dirigido a: Describe si la prenda es de Niños, Niñas, Damas y Caballeros.

Precio Unitario: Es el precio de las prendas de manera individual.

Precio Total: Precio de todas las prendas del mismo tipo ingresadas a la empresa.

3. El sistema de Facturación: Este deberá administrar los campos necesarios para llevar el

control de las prendas vendidas. Entre los campos con que este debe contar son los siguientes:

Nombre del producto

Cantidad

Monto unitario

Monto total


5


Pago del Cliente

Vuelto.

Fecha de Venta

4. Los Apartados: De los apartados se controlara la siguiente información.

Nombre del Cliente

Nombre del Producto

Costo

Monto Unitario

Monto total

Abono

Saldo

Fecha del Apartado

Fecha de Retiro


6


Requerimientos Generales:

1. El Sistema debe contar con una pantalla de acceso restringido en donde el usuario deberá

autenticarse para el ingreso al sistema.

2. Deberá contar con un módulo donde se pueda consultar el inventario de las prendas

ingresadas a la Tienda. Además, desde aquí se podrá actualizar y eliminar cualquiera de la

inclusión que se realizaron.

3. Además deberá contar con otro modulo donde se pueda consultar, actualizar y eliminar

cualquiera de las facturas de las ventas.

4. El sistema debe promover los siguientes reportes.

a. Listado de todos los articulos que tiene en inventario la empresa.

b. Listado de todas las facturas realizadas diariamente.

c. Listado de todos los apartados diarios.

d. Listado de los productos más vendidos.

5. Se debe procurar que el sistema sea lo mas automatizado posible, de tal manera que el

usuario, digite la menor cantidad de información del sistema, para evitar inconsistencia en los

datos.

6. Se agregaran mas dependiendo de las necesidades que vallan surgiendo en la empresa.


7


Desarrollo Etapas

Etapa MDL1:

Identificar las Entidades

Nombrar las Entidades:

INVENTARIO

USUARIO

FACTURA_VENTA

FACTURA_DETALLE

PROVEEDOR

FACTURA_PROVEEDOR

FACTURA_COMPRA

APARTADO

CLIENTE


8

Regla MDL 1.1

Nombrar, definir, diagramar, y documentar entidades en el diccionario de datos (DD).


Diagramar Entidades

Diccionario de Datos: UNIVERSIDAD DE COSTA RICA

Sede Guanacaste9


Entidad INVENTARIO

Entidad que contiene todos los datos de las prendas que hay en el local

Entidad FACTURA_VENTA

Entidad que almacena todas las facturas de las prendas vendidas en la tienda diariamente.

Entidad FACTURA_DETALLE

Entidad que almacena los productos vendidos por cada factura registrada.

Entidad APARTADO

Entidad que almacenará una factura de una venta realizada parcialmente (son ventas hasta que se

complete el costo de la prenda).

Entidad PROVEEDOR

Entidad que almacenará los datos de todos los proveedores que abastecen el local.

Entidad FACTURA_COMPRA

Entidad que almacena los productos comprados a los proveedores por cada factura registrada.

Entidad FACTURA_PROVEEDOR

Entidad que almacena todas las facturas de las prendas compradas a los proveedores.

Entidad CLIENTES


10


Entidad que almacenará los datos de los clientes de los apartados realizados.

Entidad USUARIO

Entidad donde se van a definir los usuarios que pueden acceder al sistema.

Etapa MDL2: UNIVERSIDAD DE COSTA RICA

Sede Guanacaste11


Determinar Asociaciones

Nombrar, Definir y Documentar:

1. USUARIO Realiza varias FACTURA_VENTA: Siendo USUARIO la entidad padre y

CLIENTE la entidad hijo, un usuario puede realizar varias facturas de ventas en la

empresa.

Cardinalidad: Uno a varios (1: N)

2. CLIENTE Tiene uno o más FACTURA_VENTA: Siendo CLIENTE la entidad padre y

FACTURA_VENTA la entidad hijo, un cliente puede tener una o más facturas de ventas

registradas por cada compra que realiza a la empresa.

Cardinalidad: Uno a varios (1: N)

3. CLIENTE Tiene uno o más APARTADO: Siendo CLIENTE la entidad padre y

APARTADO la entidad hijo, ya que un cliente puede tener varios apartados registrados.

Cardinalidad: Uno a Varios (1: N)

4. FACTURA_VENTA Registra FACTURA_DETALLE: Siendo FACTURA_VENTA

la entidad padre y FACTURA_DETALLE la entidad hijo, una Factura de ventas registra

por cada venta una factura de detalle con los productos vendidos.


5. INVENTARIO Rebaja una o más FACTURA_DETALLE: Siendo INVENTARIO la

entidad padre y FACTURA_DETALLE la entidad hijo, por lo que el inventario tiene


12

Regla MDL 2.1

Nombrar, definir, diagramar y documentar asociaciones en el diccionario de datos (DD).


muchas facturas detalles de los productos vendidos en el local, y por cada producto

vendido este se rebajará del inventario.


6. INVENTARIO Rebaja una o más APARTADO: Siendo INVENTARIO la entidad

padre y APARTADO la entidad hijo, por lo que el inventario tiene muchos apartados de

los productos vendidos parcialmente en el local, y por cada uno de estos productos

vendidos se rebajará del inventario.


7. PROVEEDOR emite varias FACTURA_PROVEEDOR: Siendo PROVEEDOR la

entidad padre y FACTURA_PROVEEDOR la entidad hijo, un proveedor puede efectuar

varias facturas con los productos adquiridos a los proveedores para la venta en el local.


8. FACTURA_PROVEEDOR Registra FACTURA_COMPRA: Siendo

FACTURA_PROVEEDOR la entidad padre y FACTURA_COMPRA la entidad hijo, ya

que una factura realizada por los proveedores registra varias facturas compras con los

detalles de la prendas ingresadas al local.


9. FACTURA_COMPRA almacena INVENTARIO: Siendo FACTURA_COMPRA la

entidad padre e INVENTARIO la entidad hijo, por cada factura realizada por los

proveedores de los productos comprados a éstos, se ingresarán al inventario.


Diagramar Asociaciones


13


Asociaciones Tipo Relación

PROVEEDOR FACTURA_PROVEEDOR (1: N)


14

Regla MDL 2.2

Clasificar asociaciones de 1: 1 y 1: N. Reducir cada asociación M: N en un nuevo

tipo de entidad y dos asociaciones de 1: N

Emite


FACTURA _PROVEEDOR FACTURA_COMPRA (1: N)

FACTURA_COMPRA INVENTARIO (1: N)

INVENTARIO FACTURA_DETALLE (1: N)

INVENTARIO APARTADO (1: N)

CLIENTE FACTURA_VENTA (1: N)

USUARIO FACTURA_VENTA (1: N)

CLIENTE APARTADO (1: N)

FACTURA_VENTA FACTURA_DETALLE (1: N)


15

Regla MDL 2.3

Reclasificar una asociación compleja con una entidad, asociada a cada una de las

entidades originales.

Realiza

Almacena

Rebaja

Tiene

Realiza

Tiene

Registra

Rebaja


Esta Regla no se emplea, en este caso porque todas las asociaciones definidas anteriormente no

son complejas.

Esta Regla no se emplea, en este caso porque en todas las asociaciones definidas anteriormente

no existen redundancias en las asociaciones.

Esta Regla no se emplea, en este caso porque no se encuentran entidades supertipo y subtipos en

la que sea necesario aplicar la relación 1:1.

Esta Regla no se emplea, en este caso porque todas las asociaciones definidas anteriormente no

son recursivas, por lo cual no es necesario crear una segunda entidad entre ellas.

Etapa MDL3:

Determinar Llaves

Llaves Primarias:


16

Regla MDL 2.4

Eliminar del MDL las asociaciones redundantes.

Regla MDL 2.5

Establecer asociaciones 1: 1 entre supertipos y subtipos. Establecer un tipo especial de

asociación 1:1 (Categoría), entre un supertipo y varios subtipos mutuamente excluyentes.

Regla MDL 2.6

Representar una asociación recursiva 1: N con una asociación 1: N sobre la misma

entidad. Representar una asociación recursiva M: N creando una segunda entidad y

relacionarla con la entidad original (ahora padre) vía dos asociaciones 1: N.

Regla MDL 3.1

Escoger una LLP para cada entidad.


Entidad: Llave Primaria

INVENTARIO INVENTARIO.Codigo _ Local

PROVEEDOR: PROVEEDOR.Codigo_Proveedor

FACTURA_PROVEEDOR: PROVEEDOR * Codigo_Proveedor

FACTURA_PROVEEDOR. Codigo_Factura

FACTURA_COMPRA:FACTURA_PROVEEDOR *Codigo_Factura

FACTURA_COMPRA. Codigo_ Producto

FACTURA_VENTA: FACTURA_VENTA. Numero_Factura

APARTADO: APARTADO. Numero_Apartado

USUARIO: USUARIO. Codigo_Usuario

CLIENTE: CLIENTE.Cedula

FACTURA_DETALLE: INVENTARIO*Codigo_Local

FACTURA_VENTA * Numero _Factura

Llaves Alternas:

PROVEEDOR: Cedula

APARTADO: CLIENTE * Cedula + APARTADO.Fecha_Emision


17

Regla MDL 3.2

Identificar las LLAs para cada entidad.


USUARIO: Cedula

Como se explico anteriormente, en este caso no existen subtipos ni supertipos, por lo cual esta

regla no se desarrollará.

Dicc

ionario de Datos

Llaves Primarias:

PROVEEDOR. Codigo_Proveedor: A cada proveedor se le asigna un código para ser más

fácil su identificación.

FACTURA_PROVEEDOR.PROVEEDOR*Codigo_Proveedor+

FACTURA_PROVEEDOR.Codigo_Factura: Se utiliza para identificar los datos de una

factura de compra, es decir las facturas realizadas por los proveedores de los productos

vendidos a la empresa.

FACTURA_COMPRA.FACTURA_PROVEEDOR*Codigo_Factura+

FACTURA_COMPRA. Codigo_Producto: Se utiliza para identificar con mayor detalle los

datos de las prendas ingresadas al inventario que fueron compradas a los proveedores por

cada factura registrada.


18

Regla MDL 3.3

Escoger como LLP de una entidad subtipo a la LLP de supertipo.

Regla MDL 3.4

Nombrar, diagramar y documentar LLPs y LLAs en el Diccionario de Datos (DD).


INVENTARIO.Codigo_Local: Se utiliza para identificar los datos de los productos y llevar

un control de los que han ingresados vendidos en el local.

USUARIO.Codigo_Usuario: Se utiliza para identificar entre los distintos usuarios que

tienen acceso al sistema.

CLIENTE.Cedula: Se utiliza para identificar a un cliente que tiene apartados en la empresa.

APARTADO.Numero_Apartado: Se utiliza para buscar un apartado de un cliente con

mayor facilidad.

FACTURA_VENTA .Numero_Factura: Se utiliza para identificar los datos de una factura

de venta.

FACTURA_DETALLE.FACTURA_VENTA*Numero_Factura+INVENTARIO*

Codigo_Local: Se utiliza para saber en detalle los productos que se han vendido por facturas

de ventas registradas, por ejemplo la descripción de la prenda.

Llaves Alternas:

PROVEEDOR.Cedula (LLA1): Se utiliza para poder identificar los datos de un proveedor

en específico por medio de la cédula, ya sea jurídica o física.

APARTADO.CLIENTE * Cedula + APARTADO .Fecha_Emision (LLA2): Se utiliza

para poder buscar un apartado de un cliente en específico por medio de la cedula del cliente y

por la fecha en la cual se realizo el apartado.


19


USUARIO.Cedula (LLA3): Se utiliza para poder identificar los datos de un determinado

usuario en específico por medio de su cédula, para saber si tiene acceso al sistema.

Diagrama


20



21

Regla MDL 3.5

Establecer estándares de nombramiento para facilitar la asignación única, clara, descriptiva,

e intuitiva de atributos.


Los nombramientos que se le asignaron a los atributos se relacionan estrechamente con

respecto a lo que se almacena en ellos por locuaz esta regla no aplica en este caso.

Esta regla no se aplicará en el Proyecto porque no utilizamos abreviaciones para definir entidades

y atributos.


22

Regla MDL 3.6

Por brevedad y simplicidad, usar abreviaciones estándar en los nombres. Ser siempre

consistente: o abreviar siempre o nunca una palabra dada.


Diagrama MDL3

Etapa MDL 4: UNIVERSIDAD DE COSTA RICA

Sede Guanacaste23


Determinar Llaves Externas

Llave Externa (LLE): Atributo(s) que completa una asociación identificando al padre.

L

l

a

ves Externas:

FACTURA_PROVEEDOR:

PROVEEDOR*Codigo_Proveedor

FACTURA_COMPRA:

FACTURA_PROVEEDOR *Codigo_Factura

FACTURA_PROVEEDOR.PROVEEDOR *Codigo_Proveedor

FACTURA_VENTA:

CLIENTE*Cedula

USUARIO*Codigo_Usuario

FACTURA_DETALLE:

FACTURA_VENTA *Numero_Factura

INVENTARIO*Codigo_Local

APARTADO:

CLIENTE *Cedula

INVENTARIO*Codigo_Local

INVENTARIO:


24

Regla MDL 4.1

Para cada asociación, identificar la llave externa (LLE).


FACTURA_COMPRA*Codigo_Producto

FACTURA_COMPRA.FACTURA_PROVEEDOR *Codigo_Factura

Nombrar:

LLE-1: FACTURA_PROVEEDOR.PROVEEDOR * Codigo_Proveedor.

LLE-2: FACTURA_COMPRA.FACTURA_PROVEEDOR * Codigo_Factura.

LLE-3: FACTURA_COMPRA.FACTURA_PROVEEDOR.PROVEEDOR *Codigo_Proveedor

LLE-4: FACTURA_VENTA.CLIENTE * Cedula.

LLE-5: FACTURA_VENTA.USUARIO * Codigo_Usuario.

LLE-6: FACTURA_DETALLE.FACTURA_VENTA *Numero_Factura

LLE-7: FACTURA_DETALLE.INVENTARIO *Codigo_Local

LLE-8: APARTADO.CLIENTE * Cedula

LLE-9: APARTADO.INVENTARIO * Codigo_Local

LLE-10: INVENTARIO.FACTURA_COMPRA *Codigo_Producto

LLE-11: INVENTARIO. FACTURA_COMPRA.FACTURA_PROVEEDOR *Codigo_Factura

Diccionario de Datos: UNIVERSIDAD DE COSTA RICA

Sede Guanacaste25

Regla MDL 4.2

Nombrar, diagramar y documentar LLEs en el diccionario de datos (DD).


LLE-1: FACTURA_PROVEEDOR.PROVEEDOR * Codigo_Proveedor: Esto significa que

la entidad PROVEEDOR (padre) le hereda el atributo Codigo_Proveedor (parte de la llave

primaria de la entidad padre), a la entidad FACTURA_PROVEEDOR, para poder encontrar una

factura realizada por un proveedor en especifico.

LLE-2: FACTURA_COMPRA.FACTURA_PROVEEDOR * Codigo_Factura: Esto

significa que la entidad FACTURA_PROVEEDOR (padre) le hereda el atributo Codigo_Factura

(parte de la llave primaria de la entidad padre), a la entidad FACTURA_COMPRA, para tener

un registro detallado de los productos comprados a los proveedores.

LLE-3: FACTURA_COMPRA.FACTURA_PROVEEDOR.PROVEEDOR*

Codigo_Proveedor Esto significa que la entidad FACTURA_PROVEEDOR (padre) le hereda el

atributo Codigo_Proveedor (parte de la llave primaria de la entidad padre), a la entidad

FACTURA_COMPRA de la entidad PROVEEDOR, para tener un registro de las facturas de

compra.

LLE-4: FACTURA_VENTA.CLIENTE * Cedula: Esto significa que la entidad CLIENTE

(padre) le hereda como llave externa el atributo Cedula (parte de la llave primaria de la entidad

padre), a la entidad FACTURA_VENTA, para encontrar una factura de venta de los productos

apartados por los clientes a la empresa.

LLE-5: FACTURA_VENTA.USUARIO * Codigo_Usuario: Esto significa que la entidad

FACTURA_VENTA (padre) le hereda el atributo Codigo_Usuario como parte de la llave externa

(parte de la llave primaria de la entidad padre), a la entidad FACTURA_VENTA de la entidad

USUARIO.

LLE-6: FACTURA_DETALLE.FACTURA_VENTA *Numero_Factura: Esto significa que

la entidad FACTURA_VENTA (padre) le hereda el atributo Numero_Factura como parte de la

llave externa a la entidad FACTURA_DETALLE.


26


LLE-7: FACTURA_DETALLE.INVENTARIO *Codigo_Local: Esto significa que la entidad

INVENTARIO (padre) le hereda el atributo Codigo_Local a la entidad FACTURA_DETALLE,

para poder acceder desde inventario los productos que han sido vendidos para rebajarlos.

LLE-8: APARTADO.CLIENTE * Cedula: Esto significa que la entidad CLIENTE (padre) le

hereda el atributo Cedula (parte de la llave primaria de la entidad padre), a la entidad

APARTADO.

LLE-9: APARTADO.INVENTARIO * Codigo_Local: Esto significa que la entidad

INVENTARIO (padre) le hereda el atributo Codigo_Local como llave externa a la entidad

APARTADO.

LLE-10: INVENTARIO.FACTURA_COMPRA *Codigo_Producto: Esto significa que la

entidad FACTURA_COMPRA (padre) le hereda el atributo Codigo_Producto (parte de la llave

primaria de la entidad padre), a la entidad INVENTARIO.

LLE-11: INVENTARIO. FACTURA_COMPRA.FACTURA_PROVEEDOR

*Codigo_Factura: Esto significa que la entidad FACTURA_PROVEEDOR (padre) le hereda el

atributo Codigo_Factura (parte de la llave primaria de la entidad padre), a la entidad

INVENTARIO como parte de la llave externa, para poder ingresar los productos comprados a los

proveedores.


27


Diagrama MDL 4

Etapa MDL 5: UNIVERSIDAD DE COSTA RICA

Sede Guanacaste28


Determinar Reglas Llave

Reglas de Inserción

U

SUARIO:

Esta regla no se aplicara a esta entidad por ser padre.

PROVEEDOR:


CLIENTE:


FACTURA_PROVEEDOR:

Dependiente: En esta entidad antes debe existir un valor asociado a la entidad PROVEEDOR.

Para realizar una factura a un proveedor, este debe ya existir registrado en la tabla de

los proveedores.

FACTURA_COMPRA:

Dependiente: En esta entidad antes debe existir un valor asociado a la entidad FACTURA _

PROVEEDOR

Para poder realizar una factura de compra con los detalles de las compras antes

debe ya haber existido una factura registrada con un proveedor en específico.


29

Regla MDL 5.1

Identificar una RI para cada asociación.


FACTURA_VENTA:

Dependiente: Debe existir un valor asociado a la entidad USUARIO y a la entidad CLIENTE.

Para poder realizar una factura de ventas antes debe ya haber existido un usuario

con acceso al sistema, pero no necesariamente un cliente.

Sin efecto: La inserción es posible, no es necesario valores asociados a la entidad CLIENTE.

Para poder realizar una factura de venta no es necesario que existan clientes.

FACTURA_DETALLE:

Dependiente: Debe existir un valor asociado a la entidad FACTURA_VENTA, a la entidad

INVENTARIO.

Para poder realizar una facturación de detalle de las prendas vendidas antes debe

existir registrado una factura en la tabla FACTURA_VENTA.

Para registrar una factura de detalle deben existir productos registrados en la entidad

INVENTARIO.

APARTADO:

Dependiente: Debe existir un valor asociado a la entidad CLIENTE.

Para poder realizar un Apartado debe de existir un cliente.

Automática: La inserción es posible si no existiera un valor asociado a la entidad CLIENTE.

Para poder realizar la inserción de un Apartado, es posible aunque no exista un

cliente en la entidad CLIENTE, sin embargo deberá de crearlo.


30


INVENTARIO:

Dependiente: Debe existir un valor asociado a la entidad FACTURA_COMPRA.

Para poder insertar las prendas en le inventario antes deberá de existir los

productos registrados en la tabla FACTURA_COMPRA.

Reglas de Supresión

PROVE

EDOR:

Restringida: La supresión podría ser posible si esta no tiene ningún valor asociado en la entidad

FACTURA_PROVEEDOR.

Podría eliminar a un proveedor siempre y cuando no existan facturas registradas

para este.

Cascada: La supresión es posible, sin embargo se eliminarán los datos asociados en la entidad

FACTURA_PROVEEDOR.

La supresión podría ser posible, sin embargo todos los datos históricos

referentes al proveedor se podrán eliminar.

FACTURA_PROVEEDOR:


31

Regla MDL 5.2

Identificar una RS para cada asociación.



FACTURA_COMPRA.

Esta entidad se podría eliminar si esta no tiene registrados facturas de compras.


FACTURA_COMPRA.

La supresión es posible, sin embargo se eliminarán todos los datos respectivos a

las facturas de compras de estas facturas registradas.

FACTURA_COMPRA:


INVENTARIO.

Para poder eliminar una factura de compra es necesario que no exista registrado

estos detalles de los productos en la entidad de INVENTARIO.

INVENTARIO:


FACTURA_DETALLE y a la entidad APARTADO.

Para poder eliminar al inventario es necesario que no exista en la entidad

FACTURA_DETALLE o en APARTADO productos vendidos.


FACTURA_DETALLE y a la entidad APARTADO.


32


La supresión es posible, sin embargo se eliminarán todos los datos respectivos a

las facturas de ventas y a los apartados que se encuentran registradas.

USUARIO:


FACTURA_VENTA.

Para poder eliminar al inventario es necesario que no exista en la entidad

FACTURA_VENTA facturas realizadas por el usuario.

CLIENTE:

Restringida: La supresión es posible, sin embargo se eliminarán los datos asociados de la

entidad APARTADO y a la entidad FACTURA_VENTA.

Un cliente se puede eliminar sin importar que se asocie con la entidad

FACTURA_VENTA, sin embargo no se podría eliminar si existiera un cliente

con apartados registrados para este cliente.

Cascada: La supresión es posible, sin embargo se eliminarán los datos asociados de la entidad

APARTADO.

Si se eliminará un cliente con un apartado afectara en el registro de los clientes

que tienen apartados.

FACTURA_VENTA:


33


Restringida: La supresión podría ser posible si esta no tiene ningún valor asociado a la entidad

FACTURA_DETALLE.

Puedo eliminar una factura de las ventas realizadas siempre y cuando nos existan

facturas de los detalles de los productos vendidos.


FACTURA_DETALLE.

Podría eliminar las facturas de ventas sin embargo no es recomendable porque

podría perder todos los datos de los productos vendidos detalladamente que se

encuentran registrados en la entidad FACTURA_DETALLE.

FACTURA_DETALLE:

Restringida: La supresión podría ser posible ya que no existe un valor asociado con otra

entidad por ser hijo.

Puedo eliminar una factura detalles realizadas, ya que no existen valores

asociados con otra entidad.

Cascada: La supresión es posible.

La supresión siempre va ser posible por ser una entidad hijo, de la cual ninguna

otra entidad depende de ella.

APARTADO:

Restringida: La supresión podría ser posible ya que esta es una entidad hija de la cual ninguna

entidad depende de ella.


34


Cascada: La supresión es posible, ya que es una entidad hija de la cual ninguna otra entidad

depende de ella.

En este caso esta regla no se desarrollará, ya que en la reglas RI y RS tipo de nulidad no fue

utilizada en ninguna entidad.

Esta regla en este caso, no se aplicará por el mismo motivo anteriormente explicado.

En este caso no se desarrollará esta regla, porque no existen entidades supertipo_subtipo en el

proyecto.

Tabla de Reglas:Padre Hijo Hijo(RI) Padre(RS)

PROVEEDOR FACTURA_PROVEEDOR Dependiente Restringida


35

Regla MDL 5.3

Evitar el uso de RI y RS nulificadas. Favorecer en su lugar reglas por defecto.

Regla MDL 5.4

No definir una RI o RS nulificadas cuando la LLE es parte de la LLP del hijo.

Regla MDL 5.5

Definir la RI para una asociación supertipo-subtipo como una versión a la medida

automática o dependiente(a la medida obliga a la asociación 1:1). Definir la RS de tal

asociación como cascada.


Cascada

FACTURA_PROVEEDOR FACTURA_COMPRA Dependiente RestringidaCascada

FACTURA_COMPRA INVENTARIO Dependiente Restringida

INVENTARIO FACTURA_DETALLE Dependiente RestringidaCascada

FACTURA_VENTA FACTURA_DETALLE Dependiente RestringidaCascada

USUARIO FACTURA_VENTA DependienteSin Efecto

Restringida

CLIENTE APARTADO DependienteAutomática

RestringidaCascada

CLIENTE FACTURA_VENTA DependienteSin Efecto

RestringidaCascada

INVENTARIO APARTADO DependienteAutomática

RestringidaCascada

Etapa MDL6:

Agregar Atributos No Llave


36

Regla MDL 6.1

Asociar cada atributo con la entidad cuya LLP es necesaria y suficiente para determinarlo

o identificarlo.


Entidades:

Entidad Atributo Tipo de Atributo

USUARIO

Codigo_Usuario LLP

Nombre No Llave

Apellido1 No Llave

Apellido2 No Llave

Contraseña No Llave

Cedula No Llave


PROVEEDOR

Codigo_Proveedor LLP

Nombre No Llave

Cedula No Llave

Direccion No Llave

Telefono No Llave


FACTURA_PROVEEDOR

Codigo_Factura LLP

Monto_Total No Llave

Fecha_Emision No Llave


FACTURA_COMPRA

Codigo_Producto LLP

Nombre No Llave

Cantidad No Llave

Precio_Unitario No Llave

Precio_Total No Llave



37


INVENTARIO

Codigo_Local LLP

Estilo No Llave

Tipo_Prenda No Llave

Cliente_Dirigido: No Llave

Precio_Venta No Llave

Precio_Costo No Llave

Nombre_Producto No Llave


FACTURA_VENTA

Numero_Factura LLP

Fecha_Venta No Llave


Pago_Cliente No Llave

Vuelto_Cliente No Llave

CLIENTE *Cedula No Llave

USUARIO *Codigo_Usuario No Llave


FACTURA_DETALLE

Cantidad No Llave


Precio_Unitario No Llave


APARTADO


Abono No Llave

Fecha_Limite No Llave

Fecha_Retiro No Llave

Fecha_Emision No Llave

Numero_Apartado LLP


38



CLIENTE

Cedula LLP

Nombre No Llave

Apellido1 No Llave

Apellido2 No Llave

Telefono No Llave

Direccion No Llave

Esta regla no se desarrollará en este caso porque no es necesario aplicarla.

Esta regla no se desarrollará en este caso porque no es necesario aplicarla.

Nombrar Atributos:

USUARIO:

Codigo_Usuario Nombre Apellido1


39

Regla MDL 6.2

Colocar un atributo no llave lo más alto posible en el MDL (hasta que la LLP lo

identifique en forma única).

Regla MDL 6.3

Si un atributo depende de la LLP y es multivaluado, reclasificarlo como un nuevo hijo. Si

es único, constituye la LLP de éste. Si no, el atributo + la LLP de la entidad original

(ahora padre) constituyen la LLP de este hijo.

Regla MDL 6.4

Nombrar, Diagramar y documentar los atributos en el Diccionario de Datos (DD).


Apellido2 Contraseña Cedula

PROVEEDOR:

Codigo_Proveedor Nombre Cedula Direccion Telefono

FACTURA_PROVEEDOR:

Codigo_Factura Monto_Total Fecha_Emision

FACTURA_COMPRA:

Codigo_Producto Nombre Cantidad Precio_Unitario Precio_Total

INVENTARIO:

Codigo_Local Estilo Nombre_Producto Tipo_Prenda Cliente_Dirigirido: Precio_Venta Precio_Costo

FACTURA_VENTA:

Numero_Factura Fecha_Venta Monto_Total Pago_Cliente Vuelto_Cliente


40


CLIENTE *Cedula USUARIO *Codigo_Usuario

FACTURA_DETALLE:

Cantidad Monto_Total Precio_Unitario

APARTADO:

Monto_Total Abono Fecha_Limite Fecha_Retiro Fecha_Emision FACTURA_VENTA *Numero_Factura

CLIENTE:

Cedula Nombre Apellido1 Apellido2 Telefono Direccion

Diccionario de Datos:

USUARIO:

1. Codigo_Usuario: Es el que identifica a un usuario en especifico.

2. Nombre: Es el nombre que identifica al usuario que tiene acceso al sistema.

3. Apellido1: Es el primer apellido del usuario que tiene acceso al sistema.

4. Apellido2: Es el segundo apellido del usuario que tiene acceso al sistema.

5. Contraseña: Es el que identifica la clave de acceso que posee el usuario.

6. Cedula: Se refiere a la cedula que identifica al usuario.


41


PROVEEDOR:

1. Codigo_Proveedor: Es el que identifica a un proveedor en especifico.

2. Nombre: Se refiere al nombre de la persona o empresa que provee a la empresa.

3. Cedula: Identifica a la cedula del proveedor o la cedula jurídica de la empresa.

4. Direccion: Identifica la direccion del proveedor o de la empresa.

5. Telefono: Ofrece el teléfono del proveedor o empresa que provee a la empresa

FACTURA_PROVEEDOR:

1. Codigo_Factura: Identifica el codigo de la facturas realizadas a los proveedores.

2. Monto_Total: Es el precio total a pagar de la factura a los proveedores.

3. Fecha_Emision: Indica la fecha en la que ingresaron los productos a la empresa.

FACTURA_COMPRA:

1. Codigo_Producto: Indica el codigo de un producto en especifico.

2. Cantidad: Indica la cantidad de un producto comprado.

3. Precio_Unitario: Se refiere al costo del producto por unidad.

4. Precio_Total: Se refiere al costo total por producto comprado.

INVENTARIO:

1. Codigo_Local: Codigo que utiliza la administradora para el control interno de los

productos de la empresa.

2. Estilo: Identifica si la prenda es de rayas, lisa, estampada, entre otras. UNIVERSIDAD DE COSTA RICA

Sede Guanacaste42


3. Tipo_Prenda: Permite designar si la prenda es casual, de vestir, Pijama o ropa

íntima.

4. Cliente_Dirigido: Identifica si la prenda es para Niños, Niñas, Damas o Caballeros.

5. Precio_Venta: Indica el precio con el cual se venderá el producto a los clientes.

6. Precio_Costo: Indica el precio con el cual la administradora los compro a los

proveedores.

7. Nombre_Producto: Indica el nombre del producto comprado.

FACTURA_VENTA:

1. Numero_Factura: Indica el numero de la factura realizada por venta.

2. Fecha_Venta: Indica la fecha en la que se realizo la venta.

3. Monto_Total: Indica el precio total vendido a un cliente.

4. Pago_Cliente: Indica la cantidad con la cual el cliente paga el monto total.

5. Vuelto_Cliente: Se refiere al dinero que se le devuelve al cliente de acuerdo con la

cantidad que pago.

6. CLIENTE *Cedula: Indica el cliente al cual se le realiza una factura de venta de

los apartados.

7. USUARIO *Codigo_Usuario: Indica que usuario se encuentra realizando las

facturas de venta.

FACTURA_DETALLE:

1. Cantidad: Indica la cantidad de vendido de un producto en especifico.

2. Monto_Total: Se refiere al monto total a pagar por producto vendido.

3. Precio_Unitario: Se refiere al monto total a pagar por un producto vendido.


43


APARTADO:

1. Monto_Total: Se refiere al total a pagar por los productos comprados.

2. Abono: Se refiere al 20% del total a pagar que debe dejar el cliente para apartar una

prenda.

3. Fecha_Emision: Indica la fecha en la que se aparto la prenda.

4. Fecha_Retiro: Indica la fecha en la que la prenda fue retirada.

5. Fecha_Limite: Indica la fecha en la que el apartado se vence.

6. FACTURA_VENTA *Numero_Factura: Indica el número de factura en el cual se

registro el apartado.

CLIENTE:

1. Cedula: Se refiere a la cedula que identifica a un cliente con un apartado.

2. Nombre: Se refiere al nombre del cliente con un apartado.

3. Apellido1: Se refiere al primer apellido del cliente.

4. Apellido2: Se refiere al segundo apellido del cliente.

5. Telefono: Indica el telefono del cliente.

6. Direccion: Indica la dirección del cliente con un apartado.

Diagrama de Atributos


44


Esta regla no se desarrollara en este proyecto por que no existen atributos que parecen describir

otra entidad.


45

Regla MDL 6.5

Si existen atributos que parecen describir una asociación (más que una entidad),

reclasificar la asociación como una nueva entidad y como hijo de las dos entidades

originales.

Regla MDL 6.6

Evitar la representación de atributos en forma codificada a menos que los códigos sean

definidos por el usuario y tengan significado dentro de la empresa.


Esta regla no se aplicara en este caso porque no se representaron atributos de manera codificada.

Esta regla no se implementará porque no se utilizaron etiquetas.

Esta regla no se empleará por que no existen atributos codificados.

Esta regla no se desarrollará en este caso por que no es necesario en este caso representar datos

derivados.

Esta regla no se implementará en este caso porque no se necesitan identificadores porque no

existen subtipos.


46

Regla MDL 6.7

No incluir etiquetas orientadas al procesamiento como atributos en el MDL.

Regla MDL 6.8

Si se deben representar atributos en forma codificada, guardar los valores codificados en

forma mutuamente independiente.

Regla MDL 6.9

Opcionalmente, representar los datos derivados como atributos si tiene un significado para

la empresa, pero indicar que son derivados.

Regla MDL 6.10

Usar una designación especial para identificadores subtipo en el MDL.

Regla MDL 6.11

Colocar atributos que son comunes a todas ocurrencias de una entidad supertipo en el

supertipo y no en sus subtipos asociados.


Esta regla no se aplicara en este caso porque no existen entidades supertipos ni subtipos.

Esta regla no se implementará en este caso porque no existen entidades con una misma LLP.

Esta regla no se implementará en este caso por que no existen entidades subtipo y asociaciones.

Esta regla no se empleará por que no aplica en este caso por lo anteriormente descrito.

Esta regla no se empleará por que no aplica en este caso porque no existen entidades que solo

tengan atributos llaves.


47

Regla MDL 6.12

En general, combinar entidades con misma LLP en una sola entidad. Excepciones

incluyen las entidades con significados diferentes en la empresa.

Regla MDL 6.13

Combinar en un subtipo todos los subtipos y asociaciones. Eventualmente, incluir un

nuevo atributo que represente la distinción entre los subtipos originales.Regla MDL 6.14

En general, combinar con su supertipo asociado cualquier subtipo que prolonga al

supertipo.

Regla MDL 6.15

En general, combinar con sus hijas, a las entidades que sólo contienen atributos llave.


Diagrama MDL 6


48


Etapa MDL 7:

Validar Reglas de Normalización

Primera Forma Normal (1N):

Esta regla no se aplicará, porque anteriormente las entidades ya se han normalizado en primera

forma normal.

Segunda Forma Normal (2N):

Esta regla no se aplicará, porque anteriormente ya se le había aplicado una normalización parcial

en segunda forma normal.

Tercera Forma Normal (3N):


49

Regla MDL 7.1

Transformar entidades en IFN trasladando los atributos repetidos o multivaluados a un hijo.

Regla MDL 7.2

Transformar entidades de IFN a 2FN trasladando los atributos que no son plenamente

dependientes de la LLP.


Entidades Normalizadas


50

Regla MDL 7.3

Transformar entidades de 2FN a 3FN trasladando los atributos depende de otros atributos no

llaves (diferentes de las LLAs)


Forma Normal Boyce\ Codd (FNBC):


51


Esta regla no se aplicará en este caso.

Cuarta Forma Normal (4FN):

Esta regla no se aplicará en este caso, ya que no existen entidades transformadas en FNBC.

Quinta Forma Normal (5FN):

Esta regla no se aplicará en este caso, por que a cada entidad le corresponde menos de 3 atributos

en una LLP.

Esta regla no se aplicará en este caso, por que a cada entidad le corresponde menos de 3 atributos

en una LLP.


52

Regla MDL 7.4

Transformar entidades de 3FN a FNBC asegurando que están en 3FN para cualquier

escogencia posible de LLC como LLP.

Regla MDL 7.5

Transformar entidades de FNBC a 4FN trasladando cualquier componente que sea

independientemente multivaluado de la LLP, hacia 2 nuevas entidades padre. Retener la

entidad original (ahora hijo) sólo si contiene otros atributos no llave.

Regla MDL 7.6

Transformar entidades de 4FN a 5FN trasladando pares de dependencias cíclicas (aparecen

con LLPs con 3 atributos) a 3 o más nuevas entidades padre.

Regla MDL 7.7

En general, no descomponer las entidades normalizadas en otras más pequeñas (i.e., no sobre-

normalizar).


Esta regla no se aplicará en este caso, por que las entidades normalizadas no se encuentran

divididas en otras más pequeñas.

Entidades Normalizadas:

Tabla de Reglas para entidades Normalizadas

Atributos:


DIRECCION_PROVEEDORCodigo_Direccion LLP

Dirección No Llave


53

Padre Hijo Hijo(RI) Padre(RS)

PROVEEDOR

DIRECCION_PROVEEDOR Dependiente Restringida

CascadaTELEFONO_PROVEEDOR Dependiente

CLIENTE

DIRECCIÓN_CLIENTE DependienteRestringida

CascadaTELEFONO_CLIENTE Dependiente

APARTADO ABONOS DependienteRestringida

Cascada

Regla MDL 7.8

Reevaluar el MDL normalizado a la luz de las reglas de supresión e inserción. Introducir, si es

necesario, atributos adicionales o entidades para prevenir anomalías de integridad temporales

(pérdida de datos debido a eventos históricos)


TELEFONO_PROVEEDOR

Codigo_Telefono LLP

Telefono_Empresa No Llave

Telefono_Fax No Llave

Telefono_Celular No Llave


DIRECCION_CLIENTECodigo_Direccion LLP

Dirección No Llave

TELEFONO_CLIENTE

Codigo_Telefono LLP

Telefono_Casa No Llave

Telefono_Fax No Llave

Telefono_Celular No Llave


ABONOSFACTURA_VENTA*Numero_Factura LLP

Abono No Llave

Diagrama MDL 7


54



55

avance metodología final

Documents