Ayuda para un diseño

Hola:
Una alternativa, que asume que los documentos tienen los mismos
atributos.
CREATE TABLE Clientes(
CodigoCliente CHAR(8)
NOT NULL
PRIMARY KEY
CHECK (CodigoCliente LIKE '[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]')
, Nombre VARCHAR(35)
NOT NULL
UNIQUE
)
CREATE TABLE SaldosCxCobrar(
TipoDocumento INT
NOT NULL
CHECK(TipoDocumento IN (1,2))
, NumDocumento CHAR(8)
NOT NULL
CHECK (NumDocumento LIKE '[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]')
, FechaEmision SMALLDATETIME
NOT NULL
, CodigoCliente CHAR(8)
NOT NULL
FOREIGN KEY REFERENCES Clientes(CodigoCliente)
, MontoOriginal NUMERIC(18,4)
NOT NULL
CHECK(MontoOriginal>0)
, SaldoPendiente NUMERIC(18,4)
NOT NULL
CHECK(SaldoPendiente>0)
, CONSTRAINT PKSaldosCxCobrar
PRIMARY KEY(TipoDocumento, NumDocumento)
)

CREATE TABLE MovimientosCxC(
TipoDocumento INT
NOT NULL
CHECK(TipoDocumento IN (1, 2, 3, 4))
, NumDocumento CHAR(8)
NOT NULL
CHECK (NumDocumento LIKE '[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]')
, TipoDocumentoAplica INT
NULL -- Permite Nulos
CHECK(TipoDocumentoAplica IN (1, 2))
, NumDocumentoAplica CHAR(8)
NULL -- Permite Nulos
CHECK (NumDocumentoAplica LIKE '[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]')
, FechaRegistro SMALLDATETIME
NOT NULL
, MontoDocumento NUMERIC(18,4)
, CONSTRAINT PKMovimientosCxC
PRIMARY KEY(TipoDocumento, NumDocumento)
, CONSTRAINT FKMovimientosSaldosCxCobrar
FOREIGN KEY(TipoDocumentoAplica, NumDocumentoAplica)
REFERENCES SaldosCxCobrar(TipoDocumento, NumDocumento)
)
Saludos,


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

"Ramon Zuluaga" wrote in message
news:

Es un sistema de cuentas por cobrar:

Entidades: Clientes, Facturas, Debitos, Pagos, Creditos
(los 4 ultimos son tipos de documentos con atributos diferentes, que se le
registran a un cliente)

Las facturas y los debitos aumentan el balance del cliente. Los pagos y

los

creditos lo rebajan.

El problema es que los documentos de rebaja (pagos y creditos) deben
aplicarse individualmente a los documentos de aumento (facturas y

debitos).

Es decir: al registrar un pago este se debe aplicar a las facturas o los
debitos que se esten saldando o abonando y debe conservarse el balance
individual de cada factura o debito. Un mismo pago puede pagar tanto
facturas como debitos.
Igual al registrar un credito, este se puede aplicar tanto a facturas como

a

debitos.

Eso implica que hay una tabla de aplicacion que debe relacionar los dos
tipos de documento involucrados.

No se bien como representar esto en un diseño relacional correctamente

para

que sea facil sacar por ejemplo un estado de cuenta de un cliente tanto

para

el cliente como tal como para saber el balance individual de cada factura

y

cada debito.


He estado pensando en reunir en una misma tabla las facturas y los

debitos.

Y por otro lado juntar en una sola tablas los pagos y los creditos pero he
estado viendo que tienen atributos diferentes y como que me complica
juntarlos.

Me pueden dar una idea de como diseñar esta pequeña base de datos pues soy
nuevo en esto ? Si han trabajado en algo similar y me pueden contar su
experiencia es mucho mejor.


Gracias

Ramon Zuluaga