En tu ejemplo, la tabla de Cliente está en 3FN, pero la primera no está ni siquiera en 1FN.
Para estar en 1FN:
- Tiene que tener una clave primaria (única no nula e irrepetible), que no se cumple, porque no ningún campo que pueda identificar univocamente a un sólo registro.
- No debe haber valores repetidos. No se cumple
- Todos los atributos deben ser atómicos. No se cumple, hay campos que contienen datos diferentes ante otros atributos iguales.
Debes separarla en Factura y DetalleFactura:
Cita: Factura(NroFactura, FechaFactura, NroCliente, [otros datos propios de la factura])
DetalleFactura(NroFactura, NroItem, Descripcion, Código, Categoría, ValorUnitario, Cantidad,Subtotal)
DetalleFactura
tampoco queda normalizada, ya que contiene
datos repetitivos y algunos que depende de datos que no son clave de la tabla (
2FN), como los detalles del producto, su categoría y el precio unitario.
Esto implica que hay al menos dos tablas:
Cita: DetalleFactura(NroFactura, NroItem, CodigoProducto, Cantidad)
Producto(CodigoProducto, Descripcion, PrecioUnitario, Categoria)
Aquí Producto
tampoco está Normalizada, porque
hay datos que pueden pertenecer a una relación (son transitivos) y no a la tabla, como lo es la
categoría (3FN). Es decir,
la categoría no es un atributo propio del Producto; es una
relación de pertenencia a un conjunto y todo conjunto con identidad es otra
tabla:
Cita: Producto(CodigoProducto, Descripcion, NroCategoria, PrecioUnitario)
Categoria(NroCategoria, Denominacion).
Tenemos entonces:
Cita: Cliente(NroCliente, Nombre, Apellido, Direccion, Telefono, Ciudad, CondicionImpuestos)
Factura(NroFactura, FechaFactura, NroCliente, [otros datos propios de la factura])
DetalleFactura(NroFactura, NroItem, CodigoProducto, Cantidad)
Producto(CodigoProducto, Descripcion, NroCategoria, PrecioUnitario)
Categoria(NroCategoria, Denominacion).
...creo que no me olvido de nada.
No estoy poniendo una tabla Productos_Categoría, como sugiere jurena, porque no has aclarado si un producto puede o no pertenecer a más de una categoría. Si puede pertenecer, se encesita esa tabla, sino, la relación es directa y no hace falta (como estandar, se pone para pensar a futuro y para establecer cierta flexibilidad).
Has de notar que ni el
importe ni los
subtotales están en esta normalización. Eso es un tema de criterio de bases de datos, y se basa en una regla genérica de la implementación de bases de datos que dice que
no se deben almacenar valores calculables, esto es, si tenemos el precio unitario y la cantidad, no necesitamos el subtotal del ítem, porque eso surge de multiplicar uno por otro. Y si tenemos la posibilidad de sumar los subtotales, ¿para qué guardamos el total de la factura?
Este es un criterio de implementación general.
Las excepciones surgen de detalles como descuentos aplicados, por ejemplo, caso en el que hay que agregar otra columna, o bien por efectividad de consultas, o por variaciones de precios (para no hacer unas relaciones más complejas).
Queda a criterio del diseñador de BBDD.
¿Se entiende un poco?