[Php-avanzado] Ejercicios Normalizacion

[Leonardo Tadei - Pegasus Tech Supply]

Hola Matías!

El lun, 01-11-2010 a las 16:47 -0300, Matias Prieto escribió:
> Hola Leo, te paso las resoluciones de los 5 primeros ejercicios de
> normalizacion:

	Buenísimo.
	Te comento:

> 1-)
> Presonas

	Es Personas ;-)

> -id
> -nombre
> -apellido
> -dir
> -tel
> -mail
> -id_ciudad

> Ciudades
> -id
> -ciudad
> -CP
> -id_prov
> 
> Provincias
> -id
> -provincia
> -id_pais
> 
> Paises
> -id
> -pais
> 
> Consultas
> -id
> -txt_consulta
> -id_estado
> 
> Estados
> -id
> -estado
> 
> Respuestas
> -id
> -txt_rta
> 
> Cons-Rta
> -id
> -id_cons
> -id_rta

Y la fecha de nacimiento?

> Nota: la ultima tabla la creo porque considero q puede habier mas de
> una respuesta por consulta, y una misma respuesta puede ser valida
> para mas de una consulta

Nota de normalización: si una pregunta puede tener más de una respuesta,
esto no está bien; la tabla Cons-Rta no existe y Respuestas tendría id,
id_consulta y txt_rta.

Nota importante: se pide resolver el problema planteado, y no un
problema parecido, como vos hiciste... el enunciado indica "Respuesta a
la Consulta", con lo cual cada consulta tiene una respuesta, y no más de
una.

> ---------------------------------
> 
> 2-)
> Personas
> -id
> -nombre
> -apellido
> -telefono
> 
> Direcciones
> -id
> -id_calle
> -nro
> -id_persona (pq una persona puede tener mas de una dreccion)

	Sí, según el enunciado puede tener exactamente 2: una llamada principal
y otra llamada secundaria... y esta tabla no aparece normalizando bien
estos datos.

> Calles
> -id
> -calle

	Esto tampoco se pide... 

> Ciudades
> -id
> -ciudad
> -CP
> -id_prov
> 
> Provincias
> -id
> -provincia
> -id_pais
> 
> Paises
> -id
> -pais
> 
> ---------------------------------
> 
> 3-)
> 
> Personas
> -id
> -nombre
> -apellido
> -direccion
> -tel
> -mail
> 
> Pedidos
> -id
> -id_persona
> -id_pago
> -txt_pedido
> 
> Pagos
> -id
> -fecha
> -valor

	De dónde sacás "fecha" ???
	La normalización no justifica esta tabla. Fijate que "Pago del Pedido"
depende únicamente del Pedido: no se justifica una tabla aparte.
	

> Items
> -id
> -id_ped
> -item
> 
> ---------------------------------
> 
> 4-)
> Pacientes
> -id
> -nombre
> -apellido
> 
> Medicos
> -id
> -nombe
> -apellido
> -id_especialidad
> 
> Especialidades
> -id
> -especialidad
> 
> Centros
> -id
> -nombre
> -direccion
> -id_ciudad
> 
> Ciudades
> -id
> -ciudad
> 
> Consultas
> -id
> -id_paciente
> -fecha
> -id_medico
> -notas
> -id_centro

	Correcto!

> ---------------------------------
> 
> 5-)
> Clientes
> -id
> -nom
> -apellido
> -direccion
> -telefono
> -id_catImp
> 
> Categorias_imp
> -id
> -categoria
> 
> Formas_pago
> -id
> -forma_pago
> 
> Sucursales
> -id
> -nombre
> -direccion
> -telefono
> -id_ciudad
> 
> Ciudades
> -id
> -ciudad
> 
> Articulos
> -id
> -codigo
> -nombre
> -precio
> -iva
> 
> Facturas_cab
> -id
> -id_sucursal
> -nro_fact
> -fecha
> -id_cliente
> -nombre(historico)
> -apellido(historico)
> -cant_articulos
> -id_formaPago

	Bien planteados los históricos.
	cant_articulos no va, porque no tenés que guardar lo que podés
calcular.

> Facturas_items
> -id
> -id_factura
> -id_articulo
> -precio(historico)
> -codigo(historico) 

	Te falta el poder representar las Listas de Precios, es decir, que un
Artículo tenga un precio distinto según la lista de precios elegida.


	En general están bien Matiás, pero arrancaste resolviendo un problema
distinto al pedido, con lo que en el mundo real, tendrías un jefe o
cliente insatisfecho, porque el sistema no hace lo que se pidió.

	Estoy de acuerdo con que el problema que plateaste es más completo y
hasta más entretenido: pero no era el pedido por el enunciado.

	Corregilo y reenviá los que tiene observaciones!
	Seguimos!

-- 

Leonardo Tadei
leonardot en pegasusnet.com.ar
http://blog.pegasusnet.com.ar
Firma pública: http://www.pegasusnet.com.ar/LeonardoTadei-public.key