[SOLUCIONADO] Ejemplo BD relacional

[tec01]

Hola, estoy trabajando con sql y java y no consigo aclarame cómo hacer una base de datos sencilla, concretamente Cliente (tiene Facturas ) ,Factura (tiene Productos), Productos.
Segun entendí la mejor forma son 4 tablas:

Clientes (nif, nombre, id_factura)
Factura (id, lista_productos) // no sé como relacionar una lista
Productos (p1, p2, p3, p4)
FacturaProducto() //Aqui se va a repetir la id de la factura por cada linea de producto que tenga? Y van a estar todas las facturas juntas?

Gracias.

[gnzsoloyo]

En principio, SI, este sería el diseño básico que debes usar:

Clientes
Factura
Productos
FacturaProducto

De todos modos, la forma en que describes algunas cosas (" Clientes (nif, nombre, id_factura)", por ejemplo), y tu pregunta ("van a estar todas las facturas juntas?") muestra que desconoces completa y profundamente los principios del modelo entidad - relacion (sin pretender ofender). Por ello te recomiendo antes que nada que trates de ver lo básico, o de lo contrario los errores que cometerás serán letales para tu proyecto.
Las reglas no son difíciles, pero tienes que no pensar las cosas como programador (Java o lo que sea), porque no se miran desde BBDD de la misma forma.

Por lo pronto, lo que se definen en el Modelo E-R de las bases de datos relacionales NO SON CLASES, sino Entidades, y las Entidades poseen Atributos, pero no tienen ni Propiedades ni comportamientos o métodos, lo que ya marca una gran diferencia.
Hay asociatividad, pero no existe composición, y la instanciación de una Entidad no existe. Cuando hablas de instancias en la base de datos te estás refiriendo en realidad al conjunto de valores que una relación (no sólo una clase) toma en el mundo real, de acuerdo a las entidades que están en tal relación y las entidades que representamos.

Las diferencias lelgan a tal punto que las relaciones pueden representarse en el modelo físico como entidades virtuales, lo que da como resultado tablas físicas (eso es lo que en realidad es ñla tabla FacturaProducto.

Finalmente, una regla universal y simple: La base debe estar desacoplada de la aplicación que la usa, lo que quiere decir que tu bien podrías cambiar toda la aplicación, y hasta el LENGUAJE usado, sin modificar nada de la base o sus objetos.

¿Se entiende?

Dicho esto, pasemos a la pregunta más básica:

Factura (id, lista_productos) // no sé como relacionar una lista

No existen listas, eso está en el detalle de la factura, lo que significa que una factura es en realidad DOS tablas:

Cabecera_Factura(nro_factura, tipo_factura, id_cliente, fecha_factura, descuentos...)
Detalle_factura(nro_factura, nro_item, , id_producto, producto_cantidad, ...)

Por su lado, esto está MAL:

Clientes (nif, nombre, id_factura)

La factura NO ES un atributo del Cliente. Si lo fuera tendrías que ingresar una vez el mismo cliente por cada factura que se le haya emitiodo, lo que es un error básico.
Como tal vez notes por el esquema anterior, el cliente se relaciona con la FACTURA, en una cardinalidad 1:N, dado que del mismo cliente pueden existir N facturas. Esto implica que la dependencia funcional es de la Factura al cliente, y no al revés.

¿Se entiende?

FacturaProducto, en la descripcion que te hago, es lo que está representado en Detalle_factura, por lo que en realidad estamos incluyendo lo mismo.


Este sería un esquema generico: (recordar que "invoices" es lo miso que Factura):

[tec01]

Me expresé mal. Ya sabia todo lo que mencionas aca ( almenos gran parte xd)
Lo que no veia era como hacer una tabla factura que tubiera productos.
Me ayudo eso que dijiste de DOS tablas ( la cabecera y el contenido).
Puede que falte algo, pero ya me funciona:

Código MySQL:

create table Clientes (
    nif varchar(10) not null PRIMARY KEY,
    nom_client varchar(20)
);
    
create table Facturas (
    id varchar(10) not null PRIMARY KEY,
    id_client varchar(10),
    FOREIGN KEY (id_client) REFERENCES Clientes(nif) on delete cascade
);
    
create table Productos(
    nombre varchar(20) not null PRIMARY KEY 
);
    
create table FacturaProductos (
    id_factura varchar(10) not null,
    nombre_producto varchar(20) not null,
    FOREIGN KEY (nombre_producto) REFERENCES Productos(nombre),
    FOREIGN KEY (id_factura) REFERENCES Facturas(id) ON DELETE CASCADE
    );
 

[gnzsoloyo]

Bueno, estás más cerca, pero tu esquema tiene aún muchos errores, algunos bastante importantes...

Más allá de los atributos faltantes en tu descripción para el Cliente, que sin duda tiene mas que esos dos, estás definiendo un "ID" a la factura que es un VARCHAR, y usualmente una factura se numera, y los números JAMAS se almacenan en campos de tipo caracter como ese.
Si el caso es que tienes que guardar un tipo de factura alfanumérico, como A, B, C, X, o lo que sea, mas un numero de punto de venta, y además el numero de la factura de ESE punto de venta, eso son TRES columnas, cada una dedicada a uno de esos atributos.

Los Productos no pueden diferenciarse sólo por nombre. Eso es insuficiente. Los productos deben diferenciarse por un identificador absolutamente único y que no permita que un data-entry meta la pata, registrando el mismo producto con nombres similares o abreviados.
Imagina que pone "pantalones marrones jersey" en un registro y "pantalones jersey marrones" en otro, e incluso "pant. marr. jersey".
¿Te das cuenta que podrían ser el mismo producto?
Por eso usualmente se utilizan los números de producto utilizados en los códigos de barras, si los tienen, o una codificación numérica o alfanumérica propia de la empresa. En este ultimo caso debe existir una funcionalidad que permita hacer altas de productos y stock, con las pertinentes validaciones.

Además de eso, el producto tiene que relacionarse con su precio, o de lo contrario no puede automatizarse la emisión de la factura. Sea que lo haga en una lista de precios por producto (otra tabla), o que el precio unitario esté en la misma tabla de Producto, o incluso que haya una tabla de Stock, vinculada al producto, el precio debe existir.

En el caso de tu tabla FacturaProductos, le faltan al menos dos columnas: El id de la linea de detalle (una por cada producto vendido en la misma factura) y además la cantidad de unidades del producto que vendes. ASí como la tienes se infiere que sólo venderás un
único producto por cada factura emitida.
Pero por sobre todo hay un error gravísimo en esa tabla: No tiene primary key, y es o es simplemente inaceptable. Es OBLIGATORIO que tenga una PK, sea esta de un único campo o una PK compuesta. Tiene que tenerla, y no la has definido.