consulta con modelo relacional

[-thor-]

hola,
Estoy haciendo un sistema,para un control de bodega,en donde los trabajadores,podran consultar,que productos,estan disponibles,ofertas,precios,sacar listados,unidades existentes,productos suspendidos,etc.

En la tabla usuarios,pienso almacenar a todos los trabajadores que tendran acceso al sistema,al usuario root,tambien lo almacenare en la tabla usuarios,las contraseñas las guadare como md5.

La tabla password la utilizo,para relacionar ,la tabla de usuarios con la tabla producto,esta tabla solo almacenara los password.


las funciones de los usuarios son las siguientes:

trabajadores de bodega:consultar,listar.

jefes de bodega:ingresar productos,modificar,consultar.

administrador:ingresar usuarios(jefes de bodega,trabajadores de bodega),ingresar productos,consultar,modificar,ingresar categorias,marcas,etc,
eliminar usuarios.




este es mi modelo de datos,el que consta de 5 tablas:

categoria:almacena las categorias disponibles,para cada producto.
marca:almacena las marcas disponibles,para cada producto.
producto:almacena los productos.
password:contiene los password de usuarios.
usuarios:almacena los nombres de usuario,junto a sus datos personales.





estas son mis consultas,y si me pueden aconsejar con mi modelo:

Es necesario,que relacione la tabla password,con la tabla productos,para controlar el acceso de usuario,ya que la consulta,para comprobar si un usuario tiene acceso o no al sistema,la hago directamente a la tabla password,en donde compruebo el rut y password de dicho usuario.

Y mi otra consulta es con la eliminacion de usuarios,que puede realizar el administrador del sistema.
Por ejemplo:si elimino al usuario luis,tendria que borrarlo de la tabla usuarios,luego de la tabla password,y luego de la tabla productos,pero si borro el rut del usuario luis,de la tabla producto,el campo pass_rut_persona,me quedare en blanco y luego me dara un error,ya que es clave foranea.

me pueden aconsejar con esas dos consultar y decirme si debo modificar,algo en mi modelo relacional

gracias

[TolaWare]

Iniciado por -thor-

hola,
Es necesario,que relacione la tabla password,con la tabla productos,para controlar el acceso de usuario,ya que la consulta,para comprobar si un usuario tiene acceso o no al sistema,la hago directamente a la tabla password,en donde compruebo el rut y password de dicho usuario.

Realmente no entiendo tu pregunta.

Iniciado por -thor-

Y mi otra consulta es con la eliminacion de usuarios,que puede realizar el administrador del sistema.
Por ejemplo:si elimino al usuario luis,tendria que borrarlo de la tabla usuarios,luego de la tabla password,y luego de la tabla productos,pero si borro el rut del usuario luis,de la tabla producto,el campo pass_rut_persona,me quedare en blanco y luego me dara un error,ya que es clave foranea.

A lo que tu te refieres es a la integridad referencial.
Para solucionar el tema de que al eliminar una tupla cuya llave primaria es llave foranea de otra tupla, no queden inconsistencias, se utiliza la clausula

ON DELETE CASCADE.

La sintaxis es mas o menos esta

CONSTRAINT nombre REFERENCES tablaexterna (campoexterno1)
ON UPDATE CASCADE

Esto queire decir que cuando defines una llave foranea en una tabla mediante SQL, y utilizas la rectriccion CASCADE, cuando se elimine la tupla con la llave a la cual nuestra tabla hace referencia, entonces se eliminara tambien esta tupla.

[-thor-]

Originalmente publicado por -thor-
hola,
Es necesario,que relacione la tabla password,con la tabla productos,para controlar el acceso de usuario,ya que la consulta,para comprobar si un usuario tiene acceso o no al sistema,la hago directamente a la tabla password,en donde compruebo el rut y password de dicho usuario.


Realmente no entiendo tu pregunta.

Disculpa,fui poco claro,en esta pregunta quize referirme a lo de integridad referencial,por eso preguntaba si era necesario,la relacion de la tabla password a la tabla productos,porque,si yo borraba un usuario,la clave foranea que pertenece al rut del usuario,quedaria en blanco y me daria un error.

A lo que tu te refieres es a la integridad referencial.
Para solucionar el tema de que al eliminar una tupla cuya llave primaria es llave foranea de otra tupla, no queden inconsistencias, se utiliza la clausula

ON DELETE CASCADE.

La sintaxis es mas o menos esta

CONSTRAINT nombre REFERENCES tablaexterna (campoexterno1)
ON UPDATE CASCADE

Esto queire decir que cuando defines una llave foranea en una tabla mediante SQL, y utilizas la rectriccion CASCADE, cuando se elimine la tupla con la llave a la cual nuestra tabla hace referencia, entonces se eliminara tambien esta tupla.

Este es mi codigo sql de la tabla producto y de las claves foranea,
que cambios debo realizarle,para lograr borrar en cascade.

Código:

/*==============================================================*/
/* Table: producto                                              */
/*==============================================================*/
create table producto
(
   prd_cod_pro                    INT(4)                         not null,
   cat_cod_id                     INT(4),
   pass_rut_persona               CHAR(10),
   mar_cod_marca                  INT(4),
   prd_fecha_creacion             DATE,
   prd_hora_creacion              TIME,
   prd_fecha_lanzamiento          DATE,
   prd_nombre_producto            CHAR(20),
   prd_precio                     INT(6),
   prd_descripcion                CHAR(80),
   prd_producto_existente         INT(4),
   prd_unidad_caja                INT(4),
   prd_suspendido                 CHAR(2),
   prd_oferta                     CHAR(2),
   primary key (prd_cod_pro)
)type = InnoDB charset=latin1 collate=latin1_spanish_ci;




alter table password add constraint FK_USUARIOS foreign key (pass_rut_persona)
      references usuarios (per_rut_persona) on delete restrict on update restrict;

alter table producto add constraint FK_CATEGORIA foreign key (cat_cod_id)
      references categoria (cat_cod_id) on delete restrict on update restrict;

alter table producto add constraint FK_MARCA foreign key (mar_cod_marca)
      references marca (mar_cod_marca) on delete restrict on update restrict;

alter table producto add constraint FK_PASSWORD foreign key (pass_rut_persona)
      references password (pass_rut_persona) on delete restrict on update restrict;

gracias

[TolaWare]

Estos son los cambios que debes realizar:

alter table password add constraint FK_USUARIOS foreign key (pass_rut_persona)
references usuarios (per_rut_persona) on delete cascade on update cascade;

alter table producto add constraint FK_CATEGORIA foreign key (cat_cod_id)
references categoria (cat_cod_id) on delete cascade on update cascade;

alter table producto add constraint FK_MARCA foreign key (mar_cod_marca)
references marca (mar_cod_marca) on delete cascade on update cascade;

alter table producto add constraint FK_PASSWORD foreign key (pass_rut_persona)
references password (pass_rut_persona) on delete cascade on update cascade;

[-thor-]

toloware,gracias por la ayuda
Ahora como encuentras mi modelo relacional,crees que tiene algun error,o deberia agregarle o cambiarle algo.Consulto,porque debeo estar seguro que no tenga errores,ya que ese modelo lo ocupare,para un sistema de bodega,que necesita una empresa,y luego lo presentare en un examen de titulo.

gracias

aqui explico de que trata mi sistema y la funcion de cada tabla.

Estoy haciendo un sistema,para un control de bodega,en donde los trabajadores,podran consultar,que productos,estan disponibles,ofertas,precios,sacar listados,unidades existentes,productos suspendidos,etc.

En la tabla usuarios,pienso almacenar a todos los trabajadores que tendran acceso al sistema,al usuario root,tambien lo almacenare en la tabla usuarios,las contraseñas las guadare como md5.

La tabla password la utilizo,para relacionar ,la tabla de usuarios con la tabla producto,esta tabla solo almacenara los password.


las funciones de los usuarios son las siguientes:

trabajadores de bodega:consultar,listar.

jefes de bodega:ingresar productos,modificar,consultar.

administrador:ingresar usuarios(jefes de bodega,trabajadores de bodega),ingresar productos,consultar,modificar,ingresar categorias,marcas,etc,
eliminar usuarios.


este es mi modelo de datos,el que consta de 5 tablas:

categoria:almacena las categorias disponibles,para cada producto,esta tabla la relaciono con la tabla productos
.
marca:almacena las marcas disponibles,para cada producto,tambien la tengo relacionada con la tabla productos.

producto:almacena los productos.

password:contiene los password de usuarios.Y esta tabla la utilizo,para relacionar,mi tabla de usuarios con la tabla productos.

usuarios:almacena los nombres de usuario,junto a sus datos personales.

[TolaWare]

EN general esta bien. Lo unico que no logro entender, es la relacion entre Producto, password y usuario.

[-thor-]

Iniciado por TolaWare

EN general esta bien. Lo unico que no logro entender, es la relacion entre Producto, password y usuario.

usuario:Esta tabla la utilizare,para almacenar los nombres de usuarios,los cuales son:root,jefes de bodega,y trabajadores de la bodega.

password:Esta tabla almacenara los password de los usuarios,antes mencionados,en realidad la hice,para tener los password de usuarios en una tabla diferente,asi estaran mas ordenados,y el rut de usuario lo utilizo,para relacionar,esta tabla con la tabla usuarios,en donde el rut,sera clave primaria en la tabla usuarios,y clave foranea en la tabla password.


Esta tabla la relaciono con la tabla productos,porque de no hacerlo,me quedara con la tabla password sin relacion :s o no. O no es necesario,que deje como foranea el rut de usuario en la tabla productos.

este es el nuevo modelo,en donde rut,ya no es foranea en la clave productos.

que opinas ahora?

modelo

[TolaWare]

En realidad, por reglas de normalización, el password es un datos que depende totalmente del usuario, por loq ue este dato deberia estar junto que el usuario y no en una tabla aparte. De esta manera, te ahorras una tabla y una relación.

[-thor-]

muchas gracias,pero ahora modifique,mis sistema relacional,ya que le agregue una nueva tabla.

[-thor-]

muchas gracias por los consejos

Hice un modelo nuevo,en donde agregue la informacion que me faltaba en la tabla despachos.

Tabla despachos:Sera la encargada de almacenar la informacion de los clientes que realizan un pedido.El pedido de ellos es recibido,por el personal de ventas,luego esa informacion se envia a la bodega,en donde los trabajadores de bodega o jefe de bodega,registran al cliente,productos,fecha actual(es la fecha en donde se realizo el pedido),fecha de despacho,es la fecha que se envia el pedido a su cliente,camion(son los camiones que entregan los pedidos),bodega(es en donde se registro la informacion).

prd_cod_pro:En esta tabla es foranea,ya que relaciona la tabla productos con la tabla despachos,la razon es porque de esta forma se registrara la cantidad de productos que se van a despachar.

prd_rut_persona:En esta tabla es foranea,ya que relaciona la tabla usuarios con la tabla despachos,la razon es porque de esta forma se registra,que trabajador o jefe,realizo el despacho del producto.

y los demas campos,ciudad,direccion,telefono,es la informacion a donde llegara el pedido.

Una consulta en el campo direccion,me aconsejan descomponerlo o dejarlo de esa manera.

me explico al descomponer el campo direccion,quedaria asi:

campo:nombre_calle,y numero_calle.

Ahora que opinan de mi modelo relacional?
gracias

modelo

[uamistad]

El modelo relacional se me hace bastante malo.

Si me permites voy a hacer unas críticas constructivas sobre el mismo.

MARCA
Muy bien.
- Si la fecha de creación no aportará nada a tu sistema, no le veo caso.

CATEGORÍA
Muy bien.
- Si la fecha de creación no aportará nada a tu sistema, no le veo caso.

PRODUCTO
Muy mal.
- En lugar de almacenar la fecha de creación y la hora de creación en dos campos, considera usar el tipo de dato DATETIME.
- El precio no tiene que ver con el producto, debería formar parte de otra entidad. Te voy a decir por qué. Supongamos que te compro tus productos hoy. El próximo año, el precio de tus productos ha subido. Yo quiero que me reimprimas las facturas de mis compras. ¿Vas a tomar el precio de la tabla PRODUCTOS siendo que este precio ya es otro?
- La existencia tampoco es parte de un producto. Un producto es una cosa que bien se puede describir en una entidad. La entidad Productos no tiene por qué enterarse de cuántas existencias hay de él. Te voy a poner otro ejemplo, quiero me digas cuánto producto tenías en existencia en Febrero del año pasado. ¿Checarías tu tabla de PRODUCTOS para decirme? ¿hallarías ahí la respuesta?
- Las ofertas qué tienen que hacer aquí. A ver dime, ¿cuáles son los productos que tuviste en oferta la semana pasada? Si ya has cambiado esos datos, no podrás saberlo.
- De la fecha de lanzamiento ya mejor ni hablo.

DESPACHO
Muy mal.
- Qué significa el atributo 'cantidad'. Espero que no sea la cantidad que te está comprando, porque en ese caso estarías repitiendo en cada compra la información de teléfono, calle, ciudad, etc, etc. y con eso tienes un tache del tamaño de neptuno en tu proyecto.
- ¿Numero de camión? Será el camión que se llevó el pedido? Parece que no andaba muy perdido en lo que escribí en el inciso anterior, ¿cierto?
- De fecha despacho ya mejor ni hablo.

USUARIOS
Muy mal.
-En otras tablas pusiste fecha de creación aunque no eran importantes y aquí donde sí importaría saber cuándo se dio de alta un nuevo usuario, no lo pones.





CONCLUSIONES

Te hace falta mucho en ese trabajo. En realidad no hay un trabajo ideal, el diseñar una DB es un arte legendario, jeje, bueno quítale lo de 'legendario'.

Se puede hacer tan robusta como lo quieras, por ejemplo, a una empresa le gustaría que se registrara la actividad que tuvo cada uno de los usuarios que tuvieron acceso al sistema. A otras les importa mucho las estadísticas de compras/ventas para tomar mejores decisiones y quizá a otros les interese más la optimización de la base de datos porque una base de datos optimizada es como un ser vivo, puede crecer y hacerse más fuerte añadiendo pequeños módulos, conectando unos con otros, etc.

Yo no digo que hagas algo demasiado complejo y que haga todas esas cosas, pero si va a ser sencilla, al menos que esté bien hecha.

Como digo, sólo es una opinión, no me lo tomes a mal.

[-thor-]

uamistad gracias por las criticas constructivas,por lo cual rediseñe mi modelo de base de datos y espero que ahora este mejor.

uamistad ahora que opinas de mi modelo?
gracias

tablas:

categoria:almacena las categorias disponibles,para cada producto,esta tabla la relaciono con la tabla productos,le saque el campo fecha,ya que es innecesario.
.
marca:almacena las marcas disponibles,para cada producto,tambien la tengo relacionada con la tabla productos.le saque el campo fecha,ya que es innecesario.

oferta:almacena las ofertas que esten disponibles,la relaciona con la tabla producto,ya que de esta sacare el codigo del producto,que se encuentre en oferta,y de la tabla precios,saco el precio que se designado,para la oferta.

En esta tabla oferta ocupo el campo estado:para controlar los productos que esten en oferta o no:por ejemplo:todos los productos que se encuentre relacionados en la tabla ofertas,y tienen el estado="SI",seran listados en un informe.

precio:almacena los precios de los productos que se van a comercializar.

producto:almacena los productos de la empresa,en esta tabla quite la fecha de lanzamiento,ya que encontre,que no sera necesaria,tambien quite los campos de unidades existentes y unidades por caja,para agregarlos a nueva entidad.

existencia: almacena la cantidad de productos que se encuentren en bodega,y las unidades que vengan por caja,por ejemplo:una caja de chocolates,trae 20 unidades.,y ahora para el caso de las unidades existentes,quiere decir,el total de productos que hay:por ejemplo:en bodega se encuentran disponible50 cajas de chocolate.

detalle despacho:Almacena la cantidad de productos,que se despachen de la bodega,el campo des_numero_guia:sera ppk y fk en esta tabla,la razon es que de esta manera,sera clave primaria,ya que una guia de despacho no puede tener el mismo codigo,y sera foranea,ya que relaciona la tabla despacho con detalles de despacho.

Tambien utilizo el campo prd_cod_pro,el cual relaciona la tabla detalle despacho,con la tabla productos,en este campo almacenare los codigos de los productos que se venden,y en elc ampo det_cantidad_productos,tendre la cantidad de cada producto que se vendio.

por ejemplo: guia de despacho:200,se relaciona con detalle despacho:200,en donde tendra los productos de codigo 300 con 5 productos vendidos,y el codigo 400 con 7 productos vendidos.

despacho:Almacena los datos personales del cliente,al cual se le entregaran los productos,y en esta tabla modifique el campo fecha,para dejarlo como datetime.

usuario:Tendra a los usuarios que utilizan el sistema,y la relaciono con la tabla despacho,para que quede registrado el rut del usuario,que realizo la entrega de productos.En esta tabla añadi,el campo fecha.

Este es mi nuevo modelo

[uamistad]

Qué onda man, te mandé igual un MP.

Quería preguntarte qué programa estás usando, no lo había visto antes.

¿Puedes meterle integridad referencial a tus diseños con él? ¿te genera el SQL?

[-thor-]

Iniciado por uamistad

Qué onda man, te mandé igual un MP.

Quería preguntarte qué programa estás usando, no lo había visto antes.

¿Puedes meterle integridad referencial a tus diseños con él? ¿te genera el SQL?

holaa,gracias por la ayuda,agregare las otras tablas.

ocupo el power designer,si se puede meter integridad referencial,y tambien genera el codigo en sql

[uamistad]

ahhh va, thanks man. No había checado el post. Power Designer, lo checaré, thanks.

[uamistad]

Hola Thor, thanks.

Mira, el diseño está bien y el otro también estaba bien y anotar los datos en un cuaderno también está bien si nada más se tratara de almacenar información. Pero el objetivo aquí es que usar la DB debería ser un medio para extraer la información rápido cuando se requiera.

Lo que no sé es qué tipo de información solicitaría la empresa, pues el diseño se basa más bien en qué es lo que se pretende extraer de ella.

Hazte preguntas acerca de qué es lo que le quieres extraer a la base de datos, pues tú más que nadie conoce lo que esta empresa necesitará.

No sería necesario agregar detalles del pedido por ejemplo ya que mencionas que eso le corresponde a la gente de ventas, pero ya que tú estás encargado del control de inventario, tienes uno de los módulos más importantes del sistema en tus manos (y la responsabilidad).

Parece que más o menos he entendido el funcionamiento de la empresa, pero deberías hacerte preguntas sobre lo que se necesitará.

Te comenté que sería bueno que independizaras al producto de su precio porque quizá alguien se podría preguntar, ¿cuánto se gastó Juan Chuchito en sus compras de Diciembre y qué fue lo que compró?

El si esta pregunta es algo que tu sistema debe solucionar, pues independizando una tabla de precios no lo vas a poder saber, más bien tendrías que anotar en qué consiste el pedido de Juan Chuchito y con los precios de aquél tiempo. Por lo que Ese campo de precio, no importa que lo hayas independizado o no, no sirve para responder esa pregunta.

En general sería dificil adivinar las preguntas que esa empresa que tienes en mente se haría. En el post anterior se me ocurrieron algunas que tu sistema no podía resolver y si éstas eran importantes, pues tendrías que re-estructurar el diseño para que pudiera hacerlo.

Aún el diseño más completo es insuficiente para algunas preguntas muy estrictas, como por decir, ¿quién fue el usuario que borró los productos que se ingresaron ayer? Es una pregunta que obliga a un diseño más sólido y que quizá la empresa que requiere este diseño no se preguntaría porque confía en todos sus empleados.

A eso es a lo que me refiero con las 'preguntas correctas', todo diseño de bases de datos debería incluir una introducción de lo que el sistema pretende hacer, no sólo de la descripción de la empresa.

Cuando hago mis diseños comienzo por algún diseño 'esqueleto' como el tuyo y luego empiezo a preguntarme:

"¿me interesaría registrar qué forma de pago usó el cliente?" "Me interesaría llevar un control de los pagos que hace un cliente, de un producto que compró en abonos y cada cuándo se están registrando esos pagos y recibir alertas de cuando un cliente no haya cumplido con su pago?"

Etc, etc.

Un diseño no es mejor por ser más grande que otro.

Si tú pones una tabla de teléfonos porque tu cliente pudiera ser que actualice sus teléfonos constantemente y en lugar de simplemente actualizar el nuevo teléfono de tu cliente quieres llevar un control de cada cuándo están cambiando de número telefónico y tener acceso a esas consultas, ¿te parecería demasiado?

Posiblemente, pero si en lugar de teléfonos fueran números de tarjeta, ahí quizá no sería demasiado, pues un mismo cliente podría usar tarjetas diferente y no por que cambie de tarjeta vas a meter el registro de tu cliente COMO SI FUERAN DOS CLIENTES DIFERENTES si es que te interesa poder contestar la pregunta: "¿Cuáles son las compras que el cliente con ID 3423 ha hecho en nuestra tienda?"

CONCLUSIÓN

Imagínate preguntas y mira si tu diseño las puede contestar. Tu diseño como te digo está bien así como está si nadie se va a preguntar nada. También te serviría un cuadernito y un lápiz.

Pero ya que vas a necesitar EXTRAER de ese diseño cierta información, debes hacerte preguntas y diseñar la DB de forma que éste sea una respuesta funcional de las preguntas que te hiciste.

"No está bien ni está mal, todo depende de las preguntas que tu diseño deba contestar."

Jaja, el párrafo anterior lo enmarqué con comillas porque salió con rima y todo.

Suerte =)

[-thor-]

uamistad muchas gracias por la ayuda,y por la explicacion tan completa,ahora hare lo que dices y comenzare ha realizarme preguntas en un cuaderno sobre mi modelo,para ver si cumple todo lo que necesito.

nuevamente gracias

[-thor-]

este modelo,ocupare para hecerme las preguntas,porque encuentro que esta completo a comparacion del anterior,que hice.

[haron]

una cosa solamente.

normalmente un usuario esta muy involucrado en lo que es la base de datos. borrar un usuario y todo lo que depende de el puede ser peligroso, porque estas borrando a su vez informacion valiosa.

en lugar de eso, muchos prefieren dar de baja al usuario (que no borrarlo). tendrias que añadir un campo mas (llamemosle "usuario_baja") que te indique que un usuario ha sido dado de baja.

en las consultas posteriores deberas tener en cuenta este campo.