Forma normal ayudita...

[Dogod]

estaría muy agradecido si alguien que sepa me ayuda a llegar a la tercera forma normal de la factura adjunta; inbtenté hacerlo pero creo que está mal:

FACTURA A NORMALIZAR

http://yfrog.com/jotablasip


LO QUE INTENTÉ HACER:

http://yfrog.com/59normalizadaj

Muhcas gracias

[jurena]

Una idea para empezar a orientarte (nada de almacenaje):
tablas:
Empresa
idEmpresa|Empresa|CIF|telefono|direccion|fax|web|u rlicono|etc.

Cliente
id|nombre|apellidos|direccion|telefono

CategoriasProductos
idcategoria|categoria

Productos
idproducto|idcategoria|producto|descripcion|precio unidad


el valor del precio por línea y el del total son valores calculables, y podrás obtenerlos mediante consulta.

Factura
idFactura|numero|Fecha|idcliente

LineaFactura
idlinea|numero|idproducto|cantidad|

[Dogod]

Te entendí, pero, algo más específico para tener más seguridad al realizarlo, algún ejemplo?

Gracias,

Saludos

[gnzsoloyo]

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:

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:

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:

Producto(CodigoProducto, Descripcion, NroCategoria, PrecioUnitario)
Categoria(NroCategoria, Denominacion).

Tenemos entonces:

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?

[jurena]

No sé si toda la parte teórica, pero sí una buena parte, ejemplificada con los datos de tu factura. No me tengas en cuenta los fallos al teclear números.

Empresa
idEmpresa|Empresa|CIF|telefono|direccion
1|COLOMBIAN SYSTEMS ACCESORIOS Y PARTES DE COMPUTADOR|D43134948|944-234092|calle Libertad, nº 5, 1006 Ciudad

Cliente
id|nombre|apellidos|direccion|ciudad|telefono
1|José|Pérez Brito|Cra 7 nº 50-50|Santafe de Bogotá, D. C.|35555555

CategoriasProductos
idcategoria|categoria
1|Memorias
2|Monitores
3|Motherboards
4|Unidades
5|Periféricos

Productos
idproducto|idcategoria|codigo|producto|preciounida d
1|1|51238|Dim PC 133 255MB|115.000
2|2|66989|Samsung Viamaster 550|360.000
3|3|589698|MSI Km255 ATA 133|220.000
4|4|16888|CDRom LG 52x|70.000
5|4|898666|Teclado Genius PS2|5.000

Factura
idFactura|numero|Fecha|idcliente
1|5656801|2004-01-20|1

LineaFactura
idlinea|idfactura|idproducto|cantidad|
1|1|1|2
2|1|2|1
3|1|3|1

y así.
Esa es la idea.

[Dogod]

Gracias a los dos deveras..., gracias a esos datos, y de un proceso que ya venía haciendo, creo que estoy casi que le atino, agradecería una vez más su opinión aquí:

http://img194.yfrog.com/i/tablau.jpg/


Muchas gracias de nuevo y

Un saludo

:)

[jurena]

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

Debes crear una tabla categorias y si sólo le asignas una categoría a un producto un campo idcategoria en la tabla producto.
Yo tampoco usaría totales, ni por línea de factura ni el de factura completa, pues eso lo saco con consultas. En resumen, con estos retoques y tras una lectura atenta a las aclaraciones de gnzsoloyo, la cosa iría bastante bien.

[Dogod]

Iniciado por jurena

Debes crear una tabla categorias y si sólo le asignas una categoría a un producto un campo idcategoria en la tabla producto.
Yo tampoco usaría totales, ni por línea de factura ni el de factura completa, pues eso lo saco con consultas. En resumen, con estos retoques y tras una lectura atenta a las aclaraciones de gnzsoloyo, la cosa iría bastante bien.

Hola, estoy siguiendo las indicaciones de gnzsoloyo pero esto lo voy a dejar para cuando empiece a montar la factura en SQL, o sea, que según tu comentario casi la tengo normalizada de forma correcta, sería así?:

http://yfrog.com/1qnormalizacinj

Estoy suponiendo, ya que el ejercicio no lo dice, que el código del producto es automáticamente el de la Categoría...,


Muchas gracias...

[gnzsoloyo]

Nooo.
La categoría es una entidad por sí misma, y por lo tanto tiene dos atributos propios: su ID y su descripción.
Es el ID de la categoría lo que va en la tabla Producto, o bien, si un producto puede estar en más de una categoría, en otra tabla más.

En el primer caso tienes

Producto(CodigoProducto, Descripcion, CodCategoria, PrecioUnitario)
Categoria(CodCategoria, Denominacion).

En el segundo caso sería:

Producto(CodigoProducto, Descripcion, CodCategoria, PrecioUnitario)
Categoria(CodCategoria, Denominacion).
Producto_Categoria(CodigoProducto, CodCategoria)

Una categoría no puede tener el mismo código que el producto por dos razones: 1) Tomarlo así haría de la categoría un atributo de Producto, y no lo es, y 2) Generarías un valor iterativo (la descripción), que se repetiría montones de veces.

[gnzsoloyo]

Para que se entienda el concepto de categoría:
Si estableces como Categorías:
- Informatica.
- Papelería
- Mobiliario
Todas las memorias, monitores, impresoras, dsicos, etc. quedarían todas agrupadas en un sólo conjunto.
Pero si pones:
- Memorias.
- Discos.
- Impresoras.
Cada una compone un conjunto distinto, y se ordenan de forma distinta. Pero esa distinción y ese agrupamiento surge de la definición de categoría, no del objeto en sí, que sigue siendo una memoria o una impresora.

Ergo: Las categorías son definiciones de agrupamiento arbitrario y no propiedades de los objetos.

[Dogod]

Hola, disculpa por ser tan tosudo, es posible que estemos construyendo el ejemplo más claro de este tipo de cosas en la red..., por lo menos en español, y mi profesor me tiene abandonado, y precisamente por esas dos cosas no tengo de donde guiarme, estoy muy agradecido con ustedes, o sea que la Tercera Forma Normal sería esta?

http://yfrog.com/2pformanormalj

He puesto asteriscos en ID categoría porque el ejercicio no lo proporciona.

Un saludo

[gnzsoloyo]

Exactamente.
La 3FN se cumple si ningún atributo no primario depende transitivamente de una clave candidata.
En tu caso, ya no hay en las tablas ningún atributo que no dependa de su clave primaria, y de ninguna otra.

[Dogod]

Hola,

Muchas gracias por su ayuda. Ahora tengo el problema más grande, ya que estoy trabajando con winsql pero el programita me vive de error en error, cómo crear y enlazar las tablas de la Tercera Forma Normal en este programa o bajo este lenguaje?

De veras muchas gracias,


Saludos

[Dogod]

Hola, vengo después de mucho tiempo a preguntar una cosa, creen ustedes que esta otra tabla también está en tercera forma normal?:

http://yfrog.com/mibasededatosventasp

Tengo mi duda en la tabla Producto, por eso del proveedor. Pero creería que sí ya que todos los campos sólo dependen de la llave primaria.


Un saludo y muchas gracias.

[Dogod]

Parece bastante claro, la duda que tengo es en que un cliente puede tener varios números de teléfono, entonces he pensado crear una tabla TELÉFONOS aparte lo cual no es incorrecto. Sería así:

TABLA_TELEFONOS:

RUT_CLIENTE(Llave foranea)
NUMERO_TEL
TIPO_TEL(Llave primaria, en este caso si es celular o fijo).


Lo que pasa es que en un foro leí que al implementar en SQL habría problemas al borrar, pues si borras un cliente, tendrías también que borrar esta tabla y al percer eso genera problemas, lentitud del sistema.


estará correcto mi planteamiento?

[jurena]

Está claro que si un cliente puede tener varios teléfonos celulares y varios fijos, es esta la estructura que te interesa. Por lo demás, imagino que estarás usando un motor InnoDB, el más adecuado para controlar la integridad sin necesidad de usar programación, sino dejándolo todo en manos de la base. Si es así, eres tú quien controlas lo que quieras que ocurra cuando borres por ej. un cliente o lo actualices. Mira sobre constraint
http://dev.mysql.com/doc/refman/5.1/...nstraints.html

Si es lo que quieres, podrás pedir que al borrar el cliente, se borren sus teléfonos, pero hay otras opciones. Echa un vistazo.

[Dogod]

Ok. Finalmente lo hice como en la siguiente imagen, creo que no hay nada incorrecto, me gustaría conocer tu opinión.

http://yfrog.com/mwbasededatosp


Un abrazo y gracias.

Gracias por el artículo.

Dogod