Diseño e Implementación de una Base de Datos para la

Ferretería El Rocco

Mercado Esteban
Piedra Miguel
Sánchez Alem
Vigo Alberth
Universidad Nacional de Trujillo
Base de Datos I
Quispe Varón Celestino Medardo
12 de mayo de 2023
 i

Índice

Diseño e Implementación de una Base de Datos para la Ferretería

El Rocco 1
Reseña de la Empresa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Realidad Problemática . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Antecedente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Empresa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Descripción de la problemática de la empresa . . . . . . . . . . . . . . . . . 3
Necesidad de la empresa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Aplicación del software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Conclusiones del Antecedente . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Marco Teórico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Base de Datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Modelo de Datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Modelo de Bases de Datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Gestores de Bases de Datos . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Justificación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Limitaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Desarrollo del Trabajo Final . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Reglas de Negocio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Modelo Relacional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Modelo Lógico Relacional - Tablas . . . . . . . . . . . . . . . . . . . . . . . . 15
Integridad de lo Datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Restricciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Referencias 22
 ii

Índice de fíguras
1. Diagrama ER para la ferretería El Rocco . . . . . . . . . . . . . . . . . . . . 11
2. Relaciones PERSONA, EMPLEADO y CLIENTE. . . . . . . . . . . . . . . 12
3. Relaciones CONSULTA, EMPLEADO y KARDEX. . . . . . . . . . . . . . . 12
4. Relaciones KARDEX y PRODUCTO. . . . . . . . . . . . . . . . . . . . . . 13
5. Relaciones CONTROLA, KARDEX y PRODUCTO. . . . . . . . . . . . . . 14
6. Relaciones PRODUCTO, PROVEE y PROVEEDOR. . . . . . . . . . . . . . 14
7. Relaciones PEDIDO, CLIENTE y PRODUCTO. . . . . . . . . . . . . . . . 15
8. Modelo Lógico Relacional de la ferretería El Rocco. . . . . . . . . . . . . . . 17
 iii

Índice de tablas
 1

Diseño e Implementación de una Base de Datos para la Ferretería

El Rocco
Reseña de la Empresa

El objeto de estudio en este caso es la ferretería, ubicada en la localidad de

Salaverry, el Rocco. Esta es una micro empresa la cual ha enfocado su financiamiento en un
principio a construir un negocio capaz de suplir la necesidad de su localidad, puesto que
esta es de las únicas en todo Salaverry.
Debido a que el gerente pudo identificar esta necesidad, destinó todo su
financiamiento a conseguir el local y los insumos necesarios para crear su negocio. Según
Torres (2019) la financiación en una empresa es uno de los requisitos indispensables para
su creación y sustento a través del tiempo; asimismo, le da la capacidad de elevar su
competitividad.
En el caso de la ferretería el Rocco, el gerente se ha visto en la necesidad de destinar
su financiamiento a la mejora de su empresa. Esto debido a que constantemente tiene
clientes y ha sentido la necesidad de agilizar sus procesos. Su objetivo con esto es atender
al número máximo de clientes en el menor tiempo posible; asimismo, brindar una atención
mucho más rápida y agradable a los clientes. Otra necesidad es la de gestionar su negocio
de una mejor manera, puesto que los problemas con el inventario no suelen ser raros.

Realidad Problemática

Hoy en día el manejo eficiente de la información se ha vuelto una necesidad para los
negocios, puesto que esto genera oportunidades a las empresas que los recopilan y hacen el
análisis debido, a la vez que facilita la toma de decisiones importantes. Sin embargo, varios
son los empresarios que tan solo emplean herramientas útiles y no software especializado,
limitando así la capacidad de explotar la información.
En este caso, la ferretería “El Rocco” tiene en su planilla de trabajadores a cuatro
personas. Conforme entran los clientes a la ferretería, la persona encargada de la caja
 2

registradora se encarga de atenderlo y ayudarlo a buscar sus productos. En caso el cliente

(DNI, nombres, apellidos, dirección, celular, correo) solicite un producto (Código de
producto, marca) el cuál este trabajador(DNI, nombres, direccion, celular) no conoce si se
posee o no, se comunica o consulta con el encargado de llevar el registro en las hojas de
cálculo de Excel, el cual informará acerca del stock del producto y actualizará la
información si es que hace una compra. Si se realiza la compra, los otros dos trabajadores
son los encargados de buscar en el almacén el producto, entregarlo ayudar al cliente a
transportarlo. Son necesarias dos personas en caso el producto sea pesado. La ferretería El
Rocco constantemente tiene salida e ingreso de productos, puesto que es la única tienda de
su tipo en su localidad. Ellos llevan los Kardex (Precio, categoría, tipo, cantidad) con los
que controlan sus productos en las hojas de cálculo de Excel; sin embargo, la falta de
automatización en sus procesos y el uso de aplicaciones no enfocadas a las necesidades del
negocio han ocasionado diversos problemas en el negocio.
Uno de los principales problemas que la ferretería presenta es la deficiencia de
control del tráfico de sus productos, es decir el registro, seguimiento y actualización de los
artículos que entran y salen de la ferretería. Al llevar esa información en las hojas de cálculo
se generan otros problemas como: lentitud de atención al cliente por la verificación de stock,
tardío contacto con los proveedores (RUC, nombre dirección), pérdida de información o
desfasada, incapacidad de realizar proyecciones a futuro debido a la falta de información y
un registro ineficiente en la tienda; finalmente, el acceso a las datos en la hoja de cálculo no
está debidamente administrada y posee problemas de seguridad al no estar restringida.

Antecedente

Empresa

La empresa conocida como Ferretería Méndez S.A. de C.V. fue establecida en mayo
de 2003. Su objetivo principal es competir en el sector de la ferretería, ofreciendo a los
clientes productos de calidad en áreas como fontanería, material eléctrico, herramientas en
general, entre otros, provenientes de marcas nacionales e internacionales. La función
 3

principal de la empresa, para la cual se creará una base de datos, es la venta de productos
clasificados en categorías que incluyen herramientas eléctricas, herramientas manuales,
fontanería, electricidad, iluminación, muebles, organización, hogar, accesorios para baños y
cocinas, jardinería, mascotas, pintura, cerrajería, hogar y limpieza.Morales (2004)

Descripción de la problemática de la empresa

La empresa ha tenido como objetivo primordial desde su inicio satisfacer las

necesidades de los clientes y expandir su base de clientes. En cuanto al control de
inventario, anteriormente se llevaba a cabo de forma manual utilizando archivos en papel,
lo cual resultaba en una tarea laboriosa para encontrar información y ocasionaba demoras
en los servicios. En relación a la nómina, la gestión de los empleados recaía completamente
en la memoria del gerente, lo cual generaba conflictos en los pagos. Por otro lado, el control
de la cartera de clientes se realizaba mediante un archivo de Excel donde se registraba el
nombre, teléfono, dirección y pedidos de cada cliente. Sin embargo, esta información estaba
dispersa y se requería consultar varias fuentes para surtir un producto, lo cual no resultaba
fácil debido a que el equipo informático se encontraba en el piso superior del local de la
empresa.Morales (2004)

Necesidad de la empresa

La empresa tenia una necesidad la cual era garantizar una atención rápida al
cliente, para esto fue fundamental contar con una base de datos almacenada en una o
varias computadoras. En donde la base de datos contiene información actualizada sobre los
productos disponibles, evitando así la pérdida de tiempo al buscar la existencia de los
mismos, así como sus características, tales como precio, marca, color, y otros detalles
relevantes.Morales (2004)

Aplicación del software

Según Morales (2004)Se utilizó el siguiente software para lograr el objetivo de crear
un sistema de bases de datos que permitiera el control de inventario, registro de ventas de
productos y la gestión de la nómina de la ferretería:
 4

Para la interfaz del programa se utilizó PHP, con la ayuda de HTML.

MYSQL se utilizó como manejador de bases de datos.

APACHE se utilizó como servidor.

MACROMEDIA DREAM WEAVER se empleó para facilitar el manejo de HTML en

algunas interfaces.

El software consta de los siguientes módulos:

1. Módulo de Conexión: En esta área, los usuarios se registran con su nombre de usuario
y contraseña para acceder al sistema.

2. Módulo de Ventas: Este módulo se encarga de realizar las operaciones de ventas y de

actualizar el inventario.

3. Módulo de Productos: En este módulo, los usuarios, según sus privilegios, pueden
realizar altas, bajas, modificaciones y consultas de productos, así como de marcas y
categorías.

4. Módulo de Nómina: El sistema de nómina se encarga de gestionar la información de

los empleados, permitiendo realizar altas, bajas, modificaciones y búsquedas.

5. Módulo de Clientes: En este módulo, se accede a la información de los clientes y se

pueden realizar altas, bajas, modificaciones y consultas.

6. Módulo de Proveedores: Este módulo permite realizar las mismas operaciones que en
el módulo de Clientes o Nómina, pero en relación a la información de los proveedores.

7. Módulo de Reportes: En esta parte del sistema, se generan informes con los datos de
las ventas o el inventario. Para este módulo, se utiliza Microsoft Access como
herramienta de apoyo.
 5

Conclusiones del Antecedente

Según Morales (2004) luego de poner en prueba el sistema de base de datos del
proyecto con distintos casos, se logro concluir lo siguiente:

1. Se logro crear un sistema de base de datos el cual permita el cual permita manejar
procesos ,los cuales no poseían mucho control, como lo son :la manipulación de datos,
el Sistema cuenta con los módulos de Productos,Clientes, Ventas, Proveedores,
Reportes de Ventas e Inventario.

2. El proyecto tiene el potencial de expandirse a diversas áreas. Se puede llevar a cabo

una implementación en la sección de Proveedores y Clientes, que permita gestionar
tanto las Cuentas por Pagar como las Cuentas por Cobrar. Además, se puede
incorporar información sobre los productos adquiridos por los Clientes y qué
proveedor se encarga de suministrarlos. Hasta el momento, el Sistema solo permite
realizar altas, bajas, modificaciones y búsquedas de los datos personales de los
Clientes y Proveedores.

Marco Teórico

Base de Datos

Una base de datos es un conjunto de información organizada y estructurada que

permite el almacenamiento, acceso y manipulación de datos de manera eficiente y segura.
Según Ramez y Navathe (2019), una base de datos es un conjunto de datos relacionados
entre sí, que están diseñados para satisfacer las necesidades de información de una
organización.

Modelo de Datos

El modelo de datos es una representación abstracta de la estructura de la base de

datos que describe cómo se organizan los datos y cómo se relacionan entre sí. Existen
diferentes tipos de modelos de datos, como el modelo jerárquico, el modelo de red, el
 6

modelo relacional, entre otros. En este proyecto se reafirmó el modelo relacional, el cual se
basa en el concepto de tablas relacionales.
Modelo Conceptual. El modelo conceptual es la representación abstracta de los
requisitos de información de un sistema de información, y proporciona una visión global de
los objetos y relaciones que forman parte del sistema. Este modelo se utiliza para entender
los requisitos de información de un sistema y para comunicarlos a los diseñadores y
usuarios del sistema. Según Hoffer et al. (2011), el modelo conceptual se centra en las
entidades, atributos y relaciones que forman parte del sistema.
Modelo Lógico. El modelo lógico es la representación de cómo se organiza y
almacena la información en una base de datos, y se enfoca en los detalles de
implementación de la base de datos. En este modelo se especifican los campos de las tablas,
las relaciones entre ellas, las restricciones de integridad, entre otros aspectos. Según
Connolly y Begg (2014), el modelo lógico se basa en el modelo conceptual y proporciona
una descripción detallada de la estructura de la base de datos.
Modelo Físico. El modelo físico es la representación de cómo se implementa la
base de datos en un sistema de gestión de bases de datos (DBMS), y se enfoca en los
detalles técnicos de la implementación, como el tamaño de los campos, la ubicación de los
datos en disco, etc. Según Ramakrishnan y Gehrke (2007), el modelo físico se basa en el
modelo lógico y proporciona una descripción detallada de la implementación de la base de
datos en el DBMS.

Modelo de Bases de Datos

El modelo de bases de datos es una combinación del modelo conceptual, lógico y

físico, que describe cómo se organizan, almacenan y acceden los datos en una base de
datos. Este modelo es utilizado para diseñar y desarrollar bases de datos eficientes y
escalables. Según Coronel, Morris, y Rob (2011), el modelo de bases de datos es un marco
de trabajo que se utiliza para diseñar y desarrollar bases de datos.
 7

Modelo Entidad - Relación. El modelo entidad-relación es una técnica para

modelar datos de una manera abstracta y conceptual. Este modelo se utiliza para
representar las entidades relevantes de un sistema y las relaciones entre ellas. El modelo
entidad-relación se compone de tres elementos principales: entidades, atributos y relaciones.
Las entidades representan objetos o conceptos del mundo real, como personas,
lugares o cosas. Los atributos describen las características de las entidades, como el nombre,
la edad o la dirección. Las relaciones describen cómo se relacionan las entidades entre sí.

Gestores de Bases de Datos

Gestores de Bases de Datos: Un gestor de bases de datos (DBMS, por sus siglas en
inglés) es un software que permite a los usuarios crear, modificar y gestionar bases de
datos. Los gestores de bases de datos proporcionaron herramientas para crear tablas,
definir relaciones, insertar y actualizar datos, y consultar la información almacenada. Entre
los gestores de bases de datos más utilizados se encuentran MySQL, Oracle, Microsoft SQL
Server, PostgreSQL y MongoDB. Cada uno de ellos tiene características y capacidades
diferentes, por lo que es importante seleccionar el gestor de bases de datos adecuado para el
proyecto en cuestión.
Referencias:

Justificación

La implementación de una base de datos para la Ferretería .El Rocco.es necesaria

para solucionar los problemas que presenta el manejo inadecuado de la información y la
falta de automatización de sus procesos. El uso de hojas de cálculo como herramienta para
el control de stock de productos y otros datos importantes ha ocasionado problemas como
la lentitud en la atención al cliente, la pérdida de información, la incapacidad de realizar
proyecciones y la falta de seguridad en el acceso a los datos.
La implementación de una base de datos permitirá a la ferretería contar con una
herramienta especializada en el manejo de la información, lo que generará una serie de
ventajas competitivas para el negocio. Una base de datos permitirá tener una más clara y
 8

actualizada el stock de productos, lo que facilitará la visión al cliente, la toma de decisiones

y la proyección a futuro del negocio. Además, la automatización de los procesos permitirá
un mayor control en el tráfico de productos, una mejor gestión de proveedores y una
reducción de errores en el registro de información.

Objetivos

Analizar los procesos actuales de la Ferretería .El Rocco determinar las necesidades
2

de información y los problemas asociados al manejo inadecuado de la misma.

Diseñar un modelo conceptual de la base de datos que represente de manera precisa y

completa los objetos, atributos y relaciones relevantes para la Ferretería.

Desarrollar el modelo lógico de la base de datos, definiendo las tablas, claves,

primarias, claves foráneas y restricciones de integridad necesarias.

Implementar el modelo físico de la base de datos utilizando un gestor de bases de

datos adecuado, configurando las tablas, índices y relaciones necesarias.

Migrar los datos existentes en las hojas de cálculo de Excel a la nueva base de datos,
asegurando la integridad y consistencia de la información.

Desarrollar interfaces de usuario intuitivas y amigables que permitan el ingreso,

consulta y modificación de datos en la base de datos de manera eficiente.

Implementar funcionalidades automatizadas, como la actualización del stock de

productos, el registro de ventas y compras, y la generación de reportes de manera ágil.

Limitaciones

Para realizar este proyecto hemos tenido una serie de inconvenientes que hemos
tratado de superar cada uno y obtener una investigación solidad y concisa.
Uno de los problemas es la falta de práctica con las herramientas disponibles para el
diseño e implementación de la Base de Datos, por lo que el producto final tendrás varios
aspectos a mejorar.
 9

Otro problema vendría a ser la falta de información accesible de la ferretería, puesto

que el gerente no brindará los datos completos del negocio.
Por último, la falta de conocimientos avanzados acerca de Bases de Datos puede
hacer que el producto final cumpla con las necesidades del negocio pero que esta solución
no sea la más óptima que existe.

Desarrollo del Trabajo Final

Reglas de Negocio

El primer paso para poder diseñar la base datos para la ferretería El Rocco fue
realizar una análisis de las reglas de negocio que esta mantiene; por lo tanto, tras ello se
encontraron las siguientes entidades y relaciones que forman parte de la empresa.
Entidades:

Persona: Superclase de que hereda sus atributos a Empleado y Cliente.

Atributos: DNI (Clave primaria), Nombres, Apellidos, Dirección, Celular.

Empleado: Clase hija que hereda los atributos de Persona.

Atributos: Cargo.

Cliente: Clase hija que hereda los atributos de Persona.

Atributos: Correo.

Kardex: Representa el kardex de la empresa, el cual recoge toda la información de las

transacciones y el flujo de los productos de la empresa.
Atributos: Código de referencia (Clave primaria), Tipo de transacción, Punto de
reorden, Precio de transacción, Cantidad, Fecha.

Producto: Representa a un producto de la empresa.

Atributos: Código de Producto (Clave primaria), Nombre, Marca.

Proveedor: Representa al proveedor asociado a la empresa que provee de los

productos necesarios a la misma.
 10

Atributos: RUC (Clave primaria), Dirección, Nombre.

Relaciones:

Consulta: Relación entre Empleado y Kardex.

Atributos: Fecha

Entrega: Relación entre Empleado y Producto.

Atributos: Código de entrega (Clave primaria), Cantidad.

Solicita: Relación entre Cliente y Producto.

Atributos: Código de pedido (Clave primaria), Fecha, Cantidad.

Controla: Relación entre Kardex y Producto.

Provee: Relación entre Producto y Proveedor.

Atributos: Código de Venta (Clave primaria), Fecha de pedido, Cantidad solicitada,
Fecha de entrega.

Una vez se tienen las entidades y relaciones definidas se puede diseñar el modelo
Entidad Relación, este se presenta en la figura 1.
 11

Figura 1
Diagrama ER para la ferretería El Rocco

Como se puede apreciar en el modelo ER, se tienen cuatro relaciones de muchos a

muchos (Consulta, Entrega, Solicita, Provee) y una relación de uno a uno en Controla.
Tanto Consulta, Entrega, Solicita como Provee generan detalles y contienen información de
interés para las relaciones entre sus entidades. También hay una especialización que nace
de la herencia generada de Persona hacia Empleado y Cliente.
 12

Modelo Relacional

Para la superclase PERSONA, la cual hereda sus atributos a las entidades

EMPLEADO y CLIENTE, puesto que estos en las reglas de negocio tienen atributos
en común, se le aplica la primera estrategia de conversión. De esta manera, se tiene lo
siguiente:
Figura 2
Relaciones PERSONA, EMPLEADO y CLIENTE.

El detalle CONSULTA, de las entidades EMPLEADO y KARDEX tiene cardinalidad

N:M, puesto que así se entiende que uno o más empleados consultan uno o más
Kardex, sin la necesidad de especificar otra entidad adicional. La transformación en
este caso requiere que la relación CONSULTA contenga los atributos principales de
las entidades que relaciona, incluyendo sus propios atributos. De esta manera, el
modelo relacional queda de la siguiente manera:
Figura 3
Relaciones CONSULTA, EMPLEADO y KARDEX.

La relación CONTROLA de las entidades KARDEX y PRODUCTO tiene

cardinalidad 1:1, puesto que tan solo un Kardex controla un solo producto. Como la
 13

transformación en este caso implica una restricción en la relación creada, lo que se

hizo fue añadir en la relación de Kardex unico_producto, esto permitirá que la
relación mantenga su cardinalidad. De esta manera, la transformación quedaría de la
siguiente manera:

Figura 4
Relaciones KARDEX y PRODUCTO.

El detalle ENTREGA, de las entidades EMPLEADO y PROVEEDOR tiene

cardinalidad N:M, puesto que así se entiende que uno o más empleados entregan uno
o más productos, sin la necesidad de especificar otra entidad adicional. La
transformación en este caso requiere que la relación ENTREGA contenga los
atributos principales de las entidades que relaciona, incluyendo sus propios atributos.
De esta manera, el modelo relacional queda de la siguiente manera:
 14

Figura 5
Relaciones CONTROLA, KARDEX y PRODUCTO.

El detalle VENTA cuya relación es PROVEE, de las entidades PROVEEDOR y

PRODUCTO tiene cardinalidad N:M, puesto que así se entiende que uno o más
proveedores provee uno o más productos, sin la necesidad de especificar otra entidad
adicional. La transformación en este caso requiere que la relación VENTA contenga
los atributos principales de las entidades que relaciona, incluyendo sus propios
atributos. De esta manera, el modelo relacional queda de la siguiente manera:

Figura 6
Relaciones PRODUCTO, PROVEE y PROVEEDOR.

El detalle PEDIDO cuya relación es SOLICITA, de las entidades CLIENTE y

PRODUCTO tiene cardinalidad N:M, puesto que así se entiende que uno o más
clientes solicitan uno o más productos, sin la necesidad de especificar otra entidad
adicional. La transformación en este caso requiere que la relación PEDIDO contenga
los atributos principales de las entidades que relaciona, incluyendo sus propios
atributos. De esta manera, el modelo relacional queda de la siguiente manera:
 15

Figura 7
Relaciones PEDIDO, CLIENTE y PRODUCTO.

Modelo Lógico Relacional - Tablas

Persona: Esta tabla es una superclase, cuya única clave principal es DNI. Esta tabla
representa una generalización en el Modelo Entidad – Relación, por lo que dicha clave
primaria pasaría a ser foránea en las dos tablas siguientes: Empleado y Cliente. Según
las reglas de negocio de la ferretería, esta generalización es del tipo traslapada, puesto
que puede haber un empleado que también es cliente.

Empleado: Empleado tiene como clave foránea DNI, y el atributo que distingue a
esta de la tabla Cliente, cargo. Esto debido a que es una tabla que hereda los
atributos de la tabla Persona.

Cliente: Cliente tiene como clave foránea DNI, y el atributo que distingue a esta de
la tabla Empleado, correo. Esto debido a que es una tabla que hereda los atributos de
la tabla Persona.

consultado_kardex: Esta tabla representa al detalle CONSULTA en el Modelo

Entidad – Relación. Debido a la transformación al Modelo Lógico Relacional, es
necesaria la creación de esta, puesto que almacenará como claves foráneas las claves
principales de las entidades que se relacionan, en este caso las tablas Empleado y
Kardex.
 16

Kardex: Esta tabla en el Modelo Entidad – Relación tiene una cardinalidad de

muchos a muchos con Empleado y una cardinalidad de uno a uno con producto. Por
lo que su clave principal código_referencia va como clave foránea en la tabla
consultado_por. Otro atributo a resaltar en esta tabla es la clave foránea
unico_producto, la cual tiene la intención de mantener la cardinalidad entre las
entidades Kardex y Producto.

entregado_por: Esta tabla en el Modelo Entidad – Relación al detalle ENTREGA.

Esta relaciona a las entidades Empleado y Producto con una cardinalidad de muchos
a muchos, por lo que contiene como claves foráneas a las claves primarias de estas dos
entidades: DNI y codigo_producto, además de sus atributos propios.

Producto: Esta tabla tiene por clave primaria a codigo_producto y como clave
foránea a DNI. La razón de esta clave foránea es que mantiene una relación de uno a
muchos con la tabla Cliente.

Orden_venta: Esta tabla representa en el Modelo Entidad – Relación al detalle

VENTA. Esta relaciona a las entidades Producto y Proveedor, por lo que en el
Modelo Lógico Relacional esta tiene por claves foráneas a las claves principales de
ambas entidades, además de las propias.

Proveedor: Esta tabla contiene por clave principal a RUC, la cual pasa como clave
foránea a la tabla provisto_por.

Orden_pedido: Esta tabla representa en el Modelo Entidad – Relación al detalle

PEDIDO. Esta relaciona a las entidades Cliente y Producto, por lo que en el Modelo
Lógico Relacional esta tiene por claves foráneas a las claves principales de ambas
entidades, además de las propias.
 17

Figura 8
Modelo Lógico Relacional de la ferretería El Rocco.

Integridad de lo Datos

Restricciones

De Dominio
El campo nombre no puede contener caracteres numéricos ni símbolos.
El campo apellido no puede contener caracteres numéricos ni símbolos.
El campo celular solo puede aceptar 9 caracteres numéricos.
El FK DNI debe aceptar 8 caracteres numéricos.
El campo Preciot ransacciónnopuedesernegativo.
El campo cantidad no puede ser negativo.
El campo cantidadp edidanopuedesernegativo.

De las Entidades
La entidad Cliente es distinguible porque su clave primaria Correo y DNI son únicas
para cada cliente.
 18

La entidad Empleado es distinguible porque su clave DNI es única para cada

empleado.
La entidad Consultakardex es distinguible porque su clave primaria
Codigoreferencia y DNI es única para cada consulta.
Cada Kardex es distinguible por su Codigoreferencia.
Un Proveedor se distingue por su RUC.
Una Ordenventa se distingue por su RUC, Codigoproducto, Codigoreferencia,
código de venta.
Una Ordenpedido se distingue por su Correo, DNI, Codigoproducto,
Codigoreferencia, código de pedido.
Cada Producto se distingue por su Codigoproducto, Codigoreferencia.
Cada Entrega se distingue por su DNI, Codigoproducto, Codigoreferencia.
Cada Entrega de producto se distingue por su DNI, Codigoproducto,
Codigoreferencia, codigoentrega.

Referencial
EMPLEADO
¿Puede aceptar nulos esa clave ajena?
No, ya que no tendría sentido un empleado sin identificación por DNI.
¿Qué deberá suceder si hay un intento de eliminar el objetivo de una
referencia de clave ajena?
RESTRINGIDA
¿Qué deberá suceder si hay un intento de modificarla clave primaria del
objetivo de una referencia de clave ajena?
RESTRINGIDA

CLIENTE
¿Puede aceptar nulos esa clave ajena?
 19

No, ya que no tendría sentido un cliente sin identificación por DNI para una futura
orden.
¿Qué deberá suceder si hay un intento de eliminar el objetivo de una
referencia de clave ajena?
SE PROPAGA
¿Qué deberá suceder si hay un intento de modificarla clave primaria del
objetivo de una referencia de clave ajena?
ANULA

CONSULTA KARDEX
¿Puede aceptar nulos esa clave ajena?
No, ya que contiene datos fundamentales para la consulta
¿Qué deberá suceder si hay un intento de eliminar el objetivo de una
referencia de clave ajena?
RESTRINGIDA
¿Qué deberá suceder si hay un intento de modificarla clave primaria del
objetivo de una referencia de clave ajena?
RESTRINGIDA

PRODUCTO
¿Puede aceptar nulos esa clave ajena?
No, ya que el código de referencia es indispensable para ubicar el producto.
¿Qué deberá suceder si hay un intento de eliminar el objetivo de una
referencia de clave ajena?
RESTRINGIDA
¿Qué deberá suceder si hay un intento de modificarla clave primaria del
objetivo de una referencia de clave ajena?
 20

SE PROPAGA

ORDEN DE PEDIDO
¿Puede aceptar nulos esa clave ajena?
No, no es posible eliminar ninguna de las FK debido a que son datos indispensables
para la Orden de pedido
¿Qué deberá suceder si hay un intento de eliminar el objetivo de una
referencia de clave ajena?
RESTRINGIDA
¿Qué deberá suceder si hay un intento de modificarla clave primaria del
objetivo de una referencia de clave ajena?
SE PROPAGA

ORDEN DE VENTA
¿Puede aceptar nulos esa clave ajena?
No, no es posible eliminar ninguna de las FK debido a que son datos indispensables
para la Orden de venta.
¿Qué deberá suceder si hay un intento de eliminar el objetivo de una
referencia de clave ajena?
RESTRINGIDA
¿Qué deberá suceder si hay un intento de modificarla clave primaria del
objetivo de una referencia de clave ajena?
SE PROPAGA

ENTREGA DE PRODUCTO
¿Puede aceptar nulos esa clave ajena?
 21

No, no es posible eliminar ninguna de las FK debido a que son datos indispensables
para la Entrega del producto
¿Qué deberá suceder si hay un intento de eliminar el objetivo de una
referencia de clave ajena?
RESTRINGIDA
¿Qué deberá suceder si hay un intento de modificarla clave primaria del
objetivo de una referencia de clave ajena?
SE PROPAGA
 22

Referencias
Coronel, C., Morris, S., y Rob, P. (2011). Bases de datos. diseño, implementación y
administración (9.a ed.). CENGAGE Learning.
Morales, L. (2004). Sistema de base dedatospara una ferretería (Tesis de Licenciatura).
Benemérita Universidad Autónoma de Puebla, Puebla de Zaragoza, México.
Ramakrishnan, R., y Gehrke, J. (2007). Sistemas de gestión de bases de datos.
McGrawHill.
Ramez, E., y Navathe, S. (2019). Fundamentos de sistemas de bases de datos (7.a ed.).
Pearson Educación.
Torres, L. (2019). El financiamiento, rentabilidad y tributación en las micro y pequeÑa
empresa, sector comercio del perú: Caso ferreteria cefiro e.i.r.l del distrito de san juan
bautista, 2018. [Tesis de Titulación, Universidad Católica Los Ángeles Chimbote].
Descargado de https://hdl.handle.net/20.500.13032/14400