Normalizacion, de tabla Productos

Me olvidaba, algo muy necesario que tiene que incluirse en el diseño es la
posibilidad de "rastrear" un producto que se vendio hasta la datos de la
compra en donde se adquirió.

gracias.

Antes de pensarlo, es por si no lo he entendido bien

A ver Productos es multi-marca, o sea Producto1-Marca1, Producto2-Marca2, y
luego cada Producto-Marca, tiene Presentaciones, o tenemos Producto1-Marca1,
Producto2-Marca1, y luego cada Producto-Marca tiene Presentaciones.

Sobre tu segundo correo, lo que quieres decir es que dada una venta,
necesitas saber donde compraste el producto-marca-presentación...

Salu2

"Codigo47" wrote in message
news:

No pueto terminar de entender como conviene diseñar esta parte de un
sistema:

Por una lado tengo PRODUCTOS y VENTAS.

Ahora cada producto puede tener diferentes MARCAS (por ejemplo "coca cola"

o

"pepsi") y PRESENTACIONES (en bolsa chica, bolsa grande, botella, etc)

Como podría diseñarse esta base de datos ??? (si pueden mostrarme un DER o
base de ejemplo se los agradeceria !)

saludos.

Hola:
Normalmente se considera que un producto solo es de una Marca y mas bien
las Marcas tienen multiples productos. Pero asumiendo que efectivamente
quieres que un producto pueda pertenecer a multiples marcas. Podria ser:
= CREATE TABLE Productos(
CodigoProducto
NOT NULL PRIMARY KEY
, NombreProducto
NOT NULL UNIQUE
)
CREATE TABLE Marcas(
CodigoMarca
NOT NULL PRIMARY KEY
, NombreMarca
NOT NULL UNIQUE
)
CREATE TABLE Presentaciones(
CodigoPresentacion ...
NOT NULL PRIMARY KEY
, NombrePresentacion
NOT NULL UNIQUE
)
CREATE TABLE UnidaesDeVenta(
CodigoProducto ...
NOT NULL REFERENCES Productos(CodigoProducto)
, CodigoMarca ...
NOT NULL REFERENCES Marcas(CodigoMarca)
, CodigoPresentacion ...
NOT NULL REFERENCES Presentaciones(CodigoPresentacion)
, Otras Columnas (Precio?)
, CONSTRAINT PKUnidadDeVenta
PRIMARY KEY(CodigoProducto, CodigoMarca, CodigoPresentacion)

)
CREATE TABLE DetalleVentas(
NumeroFactura
NOT NULL
CodigoProducto ...
NOT NULL
, CodigoMarca ...
NOT NULL
, CodigoPresentacion ...
NOT NULL
... Otras Columnas (Cantidad, Precio, Descuentos?)
, CONSTRAINT PK_DetalleVentas(Factura, CodigoProducto
, CodigoMarca,
CodigoPresentacion)
, CONSTRAINT FK_DetalleUnidades
FOREIGN KEY (CodigoProducto, CodigoMarca
, CodigoPresentacion)
REFERENCES UnidadesDeVenta( CodigoProducto,CodigoMarca
, CodigoPresentacion)
)
= Los tres puntos, es que no estoy seguro del tipo indicado para cada uno
de esos codigos. La llave Primaria de Detalle de Ventas asume que no se
repiten articulos en una factura o sea que estan agrupados por item, podria
se que este no sea el caso.


Javier Loria
Costa Rica
Se aprecia la inclusion de DDL (CREATE, INSERTS, etc.)
que pueda ser copiado y pegado al Query Analizer.
La version de SQL y Service Pack tambien ayuda

"Codigo47" wrote in message
news:

No pueto terminar de entender como conviene diseñar esta parte de un
sistema:

Por una lado tengo PRODUCTOS y VENTAS.

Ahora cada producto puede tener diferentes MARCAS (por ejemplo "coca cola"

o

"pepsi") y PRESENTACIONES (en bolsa chica, bolsa grande, botella, etc)

Como podría diseñarse esta base de datos ??? (si pueden mostrarme un DER o
base de ejemplo se los agradeceria !)

saludos.

Gracias Javier.

Y como sé de donde vino un producto que vendi ???

saludos.

Codigo47
Analista en Sistemas
Argentina, Buenos Aires
"Javier Loria" escribió en el mensaje
news:

Hola:
Normalmente se considera que un producto solo es de una Marca y mas

bien

las Marcas tienen multiples productos. Pero asumiendo que efectivamente
quieres que un producto pueda pertenecer a multiples marcas. Podria ser:
=> CREATE TABLE Productos(
CodigoProducto
NOT NULL PRIMARY KEY
, NombreProducto
NOT NULL UNIQUE
)
CREATE TABLE Marcas(
CodigoMarca
NOT NULL PRIMARY KEY
, NombreMarca
NOT NULL UNIQUE
)
CREATE TABLE Presentaciones(
CodigoPresentacion ...
NOT NULL PRIMARY KEY
, NombrePresentacion
NOT NULL UNIQUE
)
CREATE TABLE UnidaesDeVenta(
CodigoProducto ...
NOT NULL REFERENCES Productos(CodigoProducto)
, CodigoMarca ...
NOT NULL REFERENCES Marcas(CodigoMarca)
, CodigoPresentacion ...
NOT NULL REFERENCES Presentaciones(CodigoPresentacion)
, Otras Columnas (Precio?)
, CONSTRAINT PKUnidadDeVenta
PRIMARY KEY(CodigoProducto, CodigoMarca, CodigoPresentacion)

)
CREATE TABLE DetalleVentas(
NumeroFactura
NOT NULL
CodigoProducto ...
NOT NULL
, CodigoMarca ...
NOT NULL
, CodigoPresentacion ...
NOT NULL
... Otras Columnas (Cantidad, Precio, Descuentos?)
, CONSTRAINT PK_DetalleVentas(Factura, CodigoProducto
, CodigoMarca,
CodigoPresentacion)
, CONSTRAINT FK_DetalleUnidades
FOREIGN KEY (CodigoProducto, CodigoMarca
, CodigoPresentacion)
REFERENCES UnidadesDeVenta( CodigoProducto,CodigoMarca
, CodigoPresentacion)
)
=> Los tres puntos, es que no estoy seguro del tipo indicado para cada

uno

de esos codigos. La llave Primaria de Detalle de Ventas asume que no se
repiten articulos en una factura o sea que estan agrupados por item,

podria

se que este no sea el caso.


Javier Loria
Costa Rica
Se aprecia la inclusion de DDL (CREATE, INSERTS, etc.)
que pueda ser copiado y pegado al Query Analizer.
La version de SQL y Service Pack tambien ayuda

"Codigo47" wrote in message
news:
> No pueto terminar de entender como conviene diseñar esta parte de un
> sistema:
>
> Por una lado tengo PRODUCTOS y VENTAS.
>
> Ahora cada producto puede tener diferentes MARCAS (por ejemplo "coca

cola"

o
> "pepsi") y PRESENTACIONES (en bolsa chica, bolsa grande, botella, etc)
>
> Como podría diseñarse esta base de datos ??? (si pueden mostrarme un DER

o

> base de ejemplo se los agradeceria !)
>
> saludos.
>
>

Si, pero la secuencia que puede haber seria:

Producto 1 - Marca 1 - Presentacion 1
Producto 1 - Marca 2 - Presentacion 1
Producto 1 - Marca 2 - Presentacion 2
Producto 1 - Marca 3 - Presentacion 2

O sea todas las posibilidades variando alguno de estos tres items.

Gracias.

Codigo47
Analista en Sistemas
Argentina, Buenos Aires
"Lázaro" escribió en el mensaje
news:

Antes de pensarlo, es por si no lo he entendido bien

A ver Productos es multi-marca, o sea Producto1-Marca1, Producto2-Marca2,

y

luego cada Producto-Marca, tiene Presentaciones, o tenemos

Producto1-Marca1,

Producto2-Marca1, y luego cada Producto-Marca tiene Presentaciones.

Sobre tu segundo correo, lo que quieres decir es que dada una venta,
necesitas saber donde compraste el producto-marca-presentación...

Salu2

"Codigo47" wrote in message
news:
> No pueto terminar de entender como conviene diseñar esta parte de un
> sistema:
>
> Por una lado tengo PRODUCTOS y VENTAS.
>
> Ahora cada producto puede tener diferentes MARCAS (por ejemplo "coca

cola"

o
> "pepsi") y PRESENTACIONES (en bolsa chica, bolsa grande, botella, etc)
>
> Como podría diseñarse esta base de datos ??? (si pueden mostrarme un DER

o

> base de ejemplo se los agradeceria !)
>
> saludos.
>
>