SQL - problema con el alter table

Buenas, tengo una consulta acerca de dos tablas que deseo relacionar
estas son




como verán, en DETALLE_VENTA agregue "NUM_VENTA" y "PRODUCTO" mediante alter table :



pero como verán en la imagen anterior intente agregarle a la tabla DETALLE_VENTA la columna "DESCRIPCION_PRODUCTO" de la tabla PRODUCTO. pero al no ser una llave principal me lanza este error

Mens. 1776, Nivel 16, Estado 0, Línea 1
No hay claves principales ni candidatas en la tabla a la que se hace referencia ('producto') que concuerden con la lista de columnas que hace la referencia en la clave externa 'FK__detalle_v__descr__2E1BDC42'.
Mens. 1750, Nivel 16, Estado 0, Línea 1
No se pudo crear la restricción. Consulte los errores anteriores.



mi pregunta es como agregar correctamente esta columna a la tabla DETALLE_VENTA

Gracias !

Hola Juan:

Aquí la pregunta sería, ¿para qué necesitas la descripción del producto en la tabla detalle?

Una llave foránea siempre debe ser relacionada contra un campo llave de la tabla a la que hace referencia, ese es como bien comentas el error que está apareciendo. De tal manera que para poder agregar la FK, el campo DESCRIPCIÓN, de tu tabla productos TAMBIÉN DEBERÍA SER CAMPO LLAVE...

Sin embargo, el agregar esta descripción ES ALGO COMPLETAMENTE INÚTIL y por ningún motivo lo debes hacer.

Como puse en la primer línea, no entiendo por qué o para qué necesitas tener esta descripción en la tabla detalle. Al relacionar el campo CODIGO (que es la llave primaria de tu tabla producto) entonces TIENES ACCESO A TODOS LOS ATRIBUTOS DE ESTA TABLA, incluyendo la descripción. Lo único que necesitarías es hacer un JOIN para mostrar todos los atributos. Esta forma de trabajar es la esencia del modelo Entidad-Relación y del proceso de normalización de tablas. Lo que intentas hacer va contra estos principios y sólo te traerá dolores de cabeza.

De hecho, con un simple vistazo veo varios posibles errores de diseño:

1. ¿Un mismo producto puede tener varios precios? si no es así, entonces NO TIENE RAZÓN QUE PONGAS EL PRECIO EN LA TABLA DETALLE. Si bien puedes agregar un DESCUENTO para un producto, lo "normal" es que el precio de un producto NO VARIE... de Hecho esto en la realidad es una práctica desleal que implica un delito.

2. ¿Qué almacenas en el campo TOTAL, en tu tabla detalle? puedo suponer que se trata del total a pagar por el producto, es decir,


Si estoy en lo correcto ESTO ES UN TERRIBLE ERROR, una de las reglas de la normalización indica que NO DEBES GUARDAR CAMPOS QUE PUEDAN SER CALCULADOS.

Estos son solo dos detalles para estas tablas, habría que revisar el resto del modelo. Si estuvieras en una clase de Diseño de Bases de Datos, estarías reprobado... Si fueras un empleado de cualquier empresa, estarías despedido... Así de graves son los errores de diseño.

Te recomiendo darle un vistazo a cualquier libro de Diseño y normalización de BD's, o pregúntale a SAN GOOGLE, el generalmente tiene la respuesta.

Saludos
Leo.

muchas gracias Leo. necesitaba correcciones, hasta ahora estoy aprendiendo, es la primera base de datos que realizo, de los errores se aprende.
muy bien explicado

gracias

saludos Leo, tengo otra duda, quiero saber si la base de datos esta bien realizada o tengo que corregir algo?


gracias !

Hola de nuevo Juan:

El modelado de Base de Datos es algo "artesanal", en el sentido de que no hay una mejor o peor forma de hacerlo, todo depende de las necesidades y reglas de negocio que tengas... en mi post pasado hablaba de algunas situaciones que igual y habría que revisar, para ver que no estés haciendo algo "incorrecto"

1. El campo TOTAL, de tus tablas COMPRAS Y VENTAS. Si este dato LO PUEDES CALCULAR, entonces NO DEBES INCLUIRLO EN LA TABLA...
2. El campo PRECIO de tus tablas DETALLE_COMPRAS y DETALLE_VENTAS, ¿es distinto al campo PRECIOVENTA de tabla PRODUCTOS? No entiendo muy bien por qué manejar precios distintos... insisto, eso lo debes determinar tu.
3. El campo ESTADO lo manejas en varias tablas... puedo suponer que se trata de una especie de BANDERA que te indica si la ENTIDAD está activa, inactiva, de baja, etc. No nos dices qué es lo que almacenas en este dato, pero te recomiendo que lo conviertas en un CATÁLOGO y que en tus tablas manejes sólo el id...
4. Ojo con el tipo de datos que utilizas para cada campo... no nos mencionas de qué tipo son tus campos, pero debes tener cuidado en este aspecto. Si almacenas FECHAS, entonces utiliza campos tipo FECHA. (un error común es guardar estos campos como TEXTO, lo cual es un error)
5. Ojo con campos que puedan ser multivariados (como por ejemplo el teléfono)... por ningún motivo vayas a poner atributos separados por comas.

Insisto, hay mucha tela de donde cortar sin que esto quiera decir que lo que tienes está mal, esto de aprender modelado de Base de Datos, en realidad nunca terminas de aprenderlo. De cualquier manera sirve bastante la documentación, por eso lo de la recomendación de que leas cualquier libro de Diseño de Base de Datos para entender la teoría y llevarla después a la práctica.

Saludos
Leo.