Foreign Key de Vista

Me parece bien la propuesta si no se deben identificar de manera diferente
el mismo articulo, ya sea porque se precisa cambiar el nombre y agregar
varios nombres de fantasia (muchos productos quimicos se conocen bajo
nombres diferentes) o porque tienen distinto significado de acuerdo al rol
que le toca (compra, venta,etc)



Saludos


Ing. Jose Mariano Alvarez
SQLTotal Consulting

(Cambia los ceros por O y saca lo que sobra)

Este mensaje se proporciona tal como es, SIN GARANTIAS de ninguna clase. Por
favor tratar de indicar la versión de SQL y Service Pack. La inclusión de
(CREATE, INSERTS, etc.) para poder reproducir el problema también ayuda.










"Jesús" wrote in message
news:

Aquí tienes un modelado de tipos y subtipos. Hay dos alternativas:

Alternativa 1:

Tres tablas

Tabla Artículo con los campos CodArticulo, DescArticulo, CodFamilia, donde
CodArticulo es clave primaria

Tabla Articulo de Venta; con los campos CodArticulo y los campos
especificos de un artículo de venta, donde CodArticulo es clave primaria y
clave externa referenciando a la tabla Artículo

Tabla Artículo de producción: con los campos CodArtículo y los campos
específicos de un artículo de producción, donde CodArticulo es clave
primaria y clave externa referenciando a la tabla Artículo


La tabla ordenes de compra tiene el campo CodArticulo que es clave externa
referenciando a la tabla Artículos.


Alternativa 2:

Una tabla:

La tabla Articulos que tiene todos los campos de un artículo de venta y
todos los campos de un artículo de producción, mas un campo adicional
TipoArtículo que puede tener solo dos valores: "Artículo de Venta" y
"Artículo de producción"

La tabla órdenes de compra tiene el campo CodArtículo que es clave externa
referenciando a la tabla Artículos


La altenativa 1 es normalizada, mientras que la alternativa 2 es
desnormalizada. La alternativa 2 es más eficiente y sencilla, pero deja
muchos valores nulos en los campos.

"Francizk0" escribió en el mensaje de noticias
news:

Q tal gente acudiendo a uds

Tengo dos tablas articulos:
- Articulo de Venta ( 10 Campos )
- Articulo de Produccion ( 23 campos )
Cada tabla es independiend ya q contiene campos total mente distintos
salvo 3 q son
CodArticulo , DescArticulo , CodFamilia
y tengo una tabla de ordenes de compra que su campo CodArticulo puede
ser FK de cualquiera de estas 2 tablas.
Mi duda es posible hacer esto que el campo CodArticulo de la tabla O.
de Compra sea FK de ambas tablas?????? o como puede hacer para hacer
algo similar

Hola Carlos,

Tienes toda la razón, no son equivalentes.

Recapitulando tenemos que:

1) Con la alternativa 1 sin modificar un artículo puede ser a la vez de
venta y de producción.
2) Con la alternativa 2 sin modificar tenemos que no pueden ser las dos
cosas a la vez
3) Con la alternativa 2 según tú la has modificado, podrían ser las dos
cosas a la vez

Falta pues modificar la alternativa 1 para que no puedan ser las dos cosas a
la vez:


CREATE TABLE Articulos
(
CodArticulo int NOT NULL PRIMARY KEY,
TipoArticulo tinyint NOT NULL CHECK(TipoArticulo IN (1, 2)),
NombreArticulo varchar(50) NOT NULL,
UNIQUE (CodArticulo, TipoArticulo)
)

CREATE TABLE ArticulosVenta
(
CodArticulo int PRIMARY KEY REFERENCES Articulos(CodArticulo),
TipoArticulo tinyint NOT NULL CHECK(TipoArticulo = 1) DEFAULT 1,
PrecioVenta decimal(9,2) NOT NULL,
FOREIGN KEY(CodArticulo, TipoArticulo) REFERENCES Articulos(CodArticulo,
TipoArticulo)
)

CREATE TABLE ArticulosProduccion
(
CodArticulo int PRIMARY KEY REFERENCES Articulos(CodArticulo),
TipoArticulo tinyint NOT NULL CHECK(TipoArticulo = 2) DEFAULT 2,
ProduccionObjetivo int NOT NULL,
FOREIGN KEY(CodArticulo, TipoArticulo) REFERENCES Articulos(CodArticulo,
TipoArticulo)
)

Si un artículo sólo puede ser de un tipo al mismo tiempo yo me decantaría
por tener una sola tabla, más que nada por sencillez y eficiencia.

Si un artículo puede ser las dos cosas al mismo tiempo, parece que lo mejor
sería tener tres tablas.

Saludos:

Jesús López



"Carlos M. Calvelo" escribió en el mensaje de
noticias
news:
Hola Jesús,

On 5 feb, 21:26, Jesús wrote:

Aquí tienes un modelado de tipos y subtipos. Hay dos alternativas:

Alternativa 1:

Tres tablas

Tabla Artículo con los campos CodArticulo, DescArticulo, CodFamilia, donde
CodArticulo es clave primaria

Tabla Articulo de Venta; con los campos CodArticulo y los campos
especificos
de un artículo de venta, donde CodArticulo es clave primaria y clave
externa
referenciando a la tabla Artículo

Tabla Artículo de producción: con los campos CodArtículo y los campos
específicos de un artículo de producción, donde CodArticulo es clave
primaria y clave externa referenciando a la tabla Artículo

La tabla ordenes de compra tiene el campo CodArticulo que es clave externa
referenciando a la tabla Artículos.

Alternativa 2:

Una tabla:

La tabla Articulos que tiene todos los campos de un artículo de venta y
todos los campos de un artículo de producción, mas un campo adicional
TipoArtículo que puede tener solo dos valores: "Artículo de Venta" y
"Artículo de producción"

La tabla órdenes de compra tiene el campo CodArtículo que es clave externa
referenciando a la tabla Artículos

Estas dos alternativas no son equivalentes. En la primera, artículo
X puede ser al mismo tiempo artículo de venta y de producción. En
la segunda se tiene que considerar TipoArtículo parte de la clave
(y de la clave foránea en órdenes también) para conseguir lo mismo.
Sino artículo X será o bien de producción o bien de venta, pero no
las dos cosas.

Lo digo porque si se presentan como alternativas, serán
alternativas a lo mismo y con la misma capacidad de expresión.

La altenativa 1 es normalizada, mientras que la alternativa 2 es
desnormalizada. La alternativa 2 es más eficiente y sencilla, pero deja
muchos valores nulos en los campos.

Como las alternativas no son equivalentes, difícilmente se puede
hablar de normalización/denormalización aquí.

Saludos,
Carlos

Espera un momento,

Con la alternativa 2, es decir con una sola tabla, puedes hacerlo todo sin
incluir el tipo en la clave primaria.

Permitir que un artículo sea las dos cosas al mismo tiempo:

CREATE TABLE Articulos
(
CodArticulo int NOT NULL PRIMARY KEY,
EsVenta bit NOT NULL DEFAULT 0,
EsProduccion bit NOT NULL DEFAULT 0,
NombreArticulo varchar(20) NOT NULL,
PrecioVenta decimal(9,2) NULL ,
ProduccionObjetivo int NULL ,
CHECK(EsProduccion = 0 OR ProduccionObjetivo IS NOT NULL),
CHECK(EsVenta = 0 OR PrecioVenta IS NOT NULL),
CHECK(EsVenta = 1 OR EsProduccion = 1)
)

No permitir que un artículo sea las dos cosas al mismo tiempo:

CREATE TABLE Articulos
(
CodArticulo int NOT NULL PRIMARY KEY,
TipoArticulo tinyint NOT NULL CHECK(TipoArticulo IN (1,2)),
NombreArticulo varchar(20) NOT NULL,
PrecioVenta decimal(9,2) NULL ,
ProduccionObjetivo int NULL ,
CHECK(TipoArticulo <> 2 OR ProduccionObjetivo IS NOT NULL),
CHECK(TipoArticulo <> 1 OR PrecioVenta IS NOT NULL),
)


"Jesús" escribió en el mensaje de
noticias news:

Hola Carlos,

Tienes toda la razón, no son equivalentes.

Recapitulando tenemos que:

1) Con la alternativa 1 sin modificar un artículo puede ser a la vez de
venta y de producción.
2) Con la alternativa 2 sin modificar tenemos que no pueden ser las dos
cosas a la vez
3) Con la alternativa 2 según tú la has modificado, podrían ser las dos
cosas a la vez

Falta pues modificar la alternativa 1 para que no puedan ser las dos cosas
a la vez:


CREATE TABLE Articulos
(
CodArticulo int NOT NULL PRIMARY KEY,
TipoArticulo tinyint NOT NULL CHECK(TipoArticulo IN (1, 2)),
NombreArticulo varchar(50) NOT NULL,
UNIQUE (CodArticulo, TipoArticulo)
)

CREATE TABLE ArticulosVenta
(
CodArticulo int PRIMARY KEY REFERENCES Articulos(CodArticulo),
TipoArticulo tinyint NOT NULL CHECK(TipoArticulo = 1) DEFAULT 1,
PrecioVenta decimal(9,2) NOT NULL,
FOREIGN KEY(CodArticulo, TipoArticulo) REFERENCES Articulos(CodArticulo,
TipoArticulo)
)

CREATE TABLE ArticulosProduccion
(
CodArticulo int PRIMARY KEY REFERENCES Articulos(CodArticulo),
TipoArticulo tinyint NOT NULL CHECK(TipoArticulo = 2) DEFAULT 2,
ProduccionObjetivo int NOT NULL,
FOREIGN KEY(CodArticulo, TipoArticulo) REFERENCES Articulos(CodArticulo,
TipoArticulo)
)

Si un artículo sólo puede ser de un tipo al mismo tiempo yo me decantaría
por tener una sola tabla, más que nada por sencillez y eficiencia.

Si un artículo puede ser las dos cosas al mismo tiempo, parece que lo
mejor sería tener tres tablas.

Saludos:

Jesús López



"Carlos M. Calvelo" escribió en el mensaje de
noticias
news:
Hola Jesús,

On 5 feb, 21:26, Jesús wrote:

Aquí tienes un modelado de tipos y subtipos. Hay dos alternativas:

Alternativa 1:

Tres tablas

Tabla Artículo con los campos CodArticulo, DescArticulo, CodFamilia,
donde
CodArticulo es clave primaria

Tabla Articulo de Venta; con los campos CodArticulo y los campos
especificos
de un artículo de venta, donde CodArticulo es clave primaria y clave
externa
referenciando a la tabla Artículo

Tabla Artículo de producción: con los campos CodArtículo y los campos
específicos de un artículo de producción, donde CodArticulo es clave
primaria y clave externa referenciando a la tabla Artículo

La tabla ordenes de compra tiene el campo CodArticulo que es clave
externa
referenciando a la tabla Artículos.

Alternativa 2:

Una tabla:

La tabla Articulos que tiene todos los campos de un artículo de venta y
todos los campos de un artículo de producción, mas un campo adicional
TipoArtículo que puede tener solo dos valores: "Artículo de Venta" y
"Artículo de producción"

La tabla órdenes de compra tiene el campo CodArtículo que es clave
externa
referenciando a la tabla Artículos

Estas dos alternativas no son equivalentes. En la primera, artículo
X puede ser al mismo tiempo artículo de venta y de producción. En
la segunda se tiene que considerar TipoArtículo parte de la clave
(y de la clave foránea en órdenes también) para conseguir lo mismo.
Sino artículo X será o bien de producción o bien de venta, pero no
las dos cosas.

Lo digo porque si se presentan como alternativas, serán
alternativas a lo mismo y con la misma capacidad de expresión.

La altenativa 1 es normalizada, mientras que la alternativa 2 es
desnormalizada. La alternativa 2 es más eficiente y sencilla, pero deja
muchos valores nulos en los campos.

Como las alternativas no son equivalentes, difícilmente se puede
hablar de normalización/denormalización aquí.

Saludos,
Carlos

Hola Jose Mariano,

On 5 feb, 22:59, "Jose Mariano Alvarez"
wrote:

Carlos no entiendo por que dices que las dos alternativas presentadas por
Jesus no son equivalentes.

Pues he dejado ver un aspecto según el cual no lo son. No?

A mi si me parece que lo son si no introduces lo que propones (TipoArtículo)

El TipoArtículo no lo he introducido yo, sino Jesús. Solo he
sugerido que para hacer alternativa 2 equivalente a alternativa 1
(en cuanto a la diferencia que he dicho) habría que incluir
TipoArtículo en la clave (también en la clave foránea en órdenes)

Mas alla de eso coincido con parte de tu razonamiento en cuanto a las
limitaciones del modelo.

Bueno.. en cuanto a limitaciones/ventajas de las alternativas y
elecciones que se están barajando se puede decir poco.
Es que no sabemos que es lo que se está modelando. Que
es lo que dá lugar es este rollito. :-)

Saludos,
Carlos

Hola Jesús,

On 5 feb, 23:11, Jesús wrote:

Hola Carlos,

Tienes toda la razón, no son equivalentes.

Recapitulando tenemos que:

1) Con la alternativa 1 sin modificar un artículo puede ser a la vez de
venta y de producción.
2) Con la alternativa 2 sin modificar tenemos que no pueden ser las dos
cosas a la vez
3) Con la alternativa 2 según tú la has modificado, podrían ser las dos
cosas a la vez

El sentido de haber cambiado alternativa 2 era para hacerlas
equivalentes de alguna manera en cuanto a ese aspecto.

La otra opción sería algo como lo que expones tu aquí abajo,
para completar el cuadro de posibilidades. Francisco va a tener
que tomar algunas decisiones. :)

Falta pues modificar la alternativa 1 para que no puedan ser las dos cosas a
la vez:

CREATE TABLE Articulos
(
CodArticulo int NOT NULL PRIMARY KEY,
TipoArticulo tinyint NOT NULL CHECK(TipoArticulo IN (1, 2)),
NombreArticulo varchar(50) NOT NULL,
UNIQUE (CodArticulo, TipoArticulo)
)

CREATE TABLE ArticulosVenta
(
CodArticulo int PRIMARY KEY REFERENCES Articulos(CodArticulo),
TipoArticulo tinyint NOT NULL CHECK(TipoArticulo = 1) DEFAULT 1,
PrecioVenta decimal(9,2) NOT NULL,
FOREIGN KEY(CodArticulo, TipoArticulo) REFERENCES Articulos(CodArticulo,
TipoArticulo)
)

CREATE TABLE ArticulosProduccion
(
CodArticulo int PRIMARY KEY REFERENCES Articulos(CodArticulo),
TipoArticulo tinyint NOT NULL CHECK(TipoArticulo = 2) DEFAULT 2,
ProduccionObjetivo int NOT NULL,
FOREIGN KEY(CodArticulo, TipoArticulo) REFERENCES Articulos(CodArticulo,
TipoArticulo)
)

Si un artículo sólo puede ser de un tipo al mismo tiempo yo me decantaría
por tener una sola tabla, más que nada por sencillez y eficiencia.

Si un artículo puede ser las dos cosas al mismo tiempo, parece que lo mejor
sería tener tres tablas.

En general, yo me quedaría con las tres tablas en los dos casos
(demasiados nulos). En el primer caso, parece que realmente estamos
hablando de entidades distintas (con tanta diferencia en que
atributos son aplicables o no ...)

Saludos,
Carlos