[Php-avanzado] Ejercicios de normalización
Leonardo Tadei - Pegasus Tech Supply
leonardot en pegasusnet.com.ar
Lun Jun 17 19:18:33 ART 2013
Hola Marco,
El lun, 17-06-2013 a las 11:40 -0300, Marco Riedel escribió:
> Respecto de las claves, te cuento:
>
> En Clientes elegiste usar una clave primaria
> artificial (el ID entero),
> pero en otras tablas estás usando una clave primera natural, y
> no es
> buena idea mezclar ambos tipos de clave: o todas naturales, o
> todas
> artificiales.
> Por lo general uso DNI como clave natural pero no estaba en el
> ejercicio por eso agregué id_cliente. En los
> paises/provincias/ciudades/ al Id_ le pongo el nombre porque asi queda
> el registro en el usuario, si todas tienen que ser artificiales en el
> cliente quedaría un numero en el campo ciudad por ejemplo.
Asumiendo que dónde decís "usuario" te referís a "cliente", si hacés
esto, no estás usando el concepto de relación!
Lo que te quedaría en Clientes, es, tal y cómo decís, la clave primaria
de la tabla relacionada, por lo tanto, si la clave primaria es un
entero, será un entero.
Luego, al hacer la consulta con la relación, tendrás todos los campos
de todas las tablas que quieras proyectar, independientemente del tipo
de campo para establecer la relación.
Con respecto a usar DNI como clave natural, es una buena idea solo si
el sistema es muy chiquito... ni bien tenés que lidiar con libretas
cívicas o de enrolamiento, o con pasaportes o DNI de extranjeros, esta
clave natural deja de funcionar.
> Respecto de las claves primarias, en caso de ser
> naturales, no sirve tu
> definición para ciudades (tenemos en Argentina 3 "Mar
> Chiquita" y tu
> almacenamiento soporta solo una, salvo que el PFK se refiera a
> que
> además de clave foránea, también es clave primaria junto con
> la que
> identificás con PK). Te pasa lo mismo con las Provincias, que
> en algunos
> países se repiten nombres de estados.
> Claro serian claves primarias combinadas, no se podrían poner dos Mar
> Chiquita en Buenos Aires.
No me quedaba claro que la clave era de dos campos, por eso te lo
aclaraba.
Ahora, si la PK es de dos campos, tenés que poner entonces esos dos
campos para establecer la relación en Clientes, que es lo que habías
hecho primero.
> Me parece la mejor manera de evitar duplicaciones si las carga un
> operador, lo que no quita que te escriban MChiquita pero eso se
> validaría desde código no?
También podrías haber usado una PK artificial y crear un índice único
con el nombre, o no haber hecho nada y validar todas estas situaciones
desde el código: en cualquier caso no afecta a la normalización.
> Respecto de la normalización, te cuento:
>
> En Clientes, el Código Postal no depende de él, sino
> de la Ciudad. Si
> lo estás pensando como el nuevo CPA, el campo tiene el nombre
> equivocado, pero aún así por 3FN al no depender únicamente de
> la clave
> primaria, tampoco va ahí.
> Yo pensé que dependía de la dirección porque por ejemplo en Capital
> Federal seria la misma ciudad pero varios códigos postales.
Si pensaste esto, estás normalizando mal, porque en tal caso tendrías
que sacar el código postal a una tabla aparte, porque no depende
exclusivamente de la clave primaria (depende de la dirección!)
> Tampoco van Id_provincia ni Id_pais, ya que vía la
> Ciudad se establecen
> las relaciones para hallarlos.
> Si me parecía redundante a mi también.
Bueno, pero si tu PK de CiudesxProvincia es doble, tenés que poner los
mismos dos campos en Clientes... lo discutimos más arriba.
> La tabla Consultasxusuario está bien, pero introducís
> como nombre de
> campo "usuario", que no es parte de este problema. Debería
> decir
> "cliente", que es como llamaste a la entidad que tiene el
> nombre y el
> apellido: la semántica es relevante.
> Modificado
Bueno Marco, decidite: o todas las tablas tienen claves primarias
naturales, o todas tienen claves primarias artificiales (enteras
autoincrementales).
No es correcto usar dos metodologías distintas para establecer la clave
primaria en el mismo modelo de datos!!!
Además, creeme que si las mezclas, cuando llegás a las 30 o 40 tablas,
indefectiblemente metés la pata en algún lado, porque lo pensás desde el
punto de vista contrario según el caso.
A mi me da lo mismo que uses claves naturales o artificiales, así que
plantealo a tu gusto.
Seguimos!!!
> > Clientes
> > id_cliente (int, identity,PK,NN)
> > Nombre (Varchar50, NN)
> > Apellido (Varchar 50, NN)
> > F_Nac (Date, NN)
> > Direccion (Varchar 50)
> > telefono (Int)
> > E_mail (Varchar 50)
> > Id_ciudad(FK, int, NN)
> > C_Postal (Int)
> >
> >
> >
> >
> >
> > Paises
> > id_pais (PK, Unique, NN, Varchar 50)
> >
> >
> >
> > Provincias
> > Id_provincia (PK, Unique, NN,Varchar 50)
> > Id_pais (PFK, NN)
> >
> >
> >
> > CiudesxProvincia
> > Id_ciudad (PK,NN,Varchar 50)
> > Id_provincia (PFK,NN)
> >
> >
> >
> > Consultasxusuario
> > Id_consulta (PK, identity, int, NN)
> > Id_cliente (FK,NN)
> > Pregunta (text, NN)
> > Respuesta (text)
> > id_estado (FK,Int,NN)
> >
> >
> >
> > Estados_consultas
> > Id_estado (PK,Identity, Int,NN)
> > descripcion (Varchar50, Unique, NN)
> >
> >
> >
> >
> > El 15 de junio de 2013 12:00, Leonardo Tadei - Pegasus Tech
> Supply
> > <leonardot en pegasusnet.com.ar> escribió:
> > Buenas!
> >
> > armé algunos ejercicios de normalización.
> > Dada la importancia del tema y teniendo en
> cuenta que
> > el próximo Jueves
> > por ser feriado no tenemos clase, les pido que los
> resuelvan y
> > vayan
> > enviando resultados y dudas por la lista, para ver
> cómo llevan
> > la
> > cuestión... sobre todo a los que no pudieron estar
> en clase.
> >
> > Si tienen dudas de contexto, consulten!
> >
> >
> > 1) Crear las tablas necesarias en tercera forma
> normal para
> > guardar los
> > siguientes datos: Nombre, Apellido, Fecha de
> Nacimiento,
> > Dirección,
> > Teléfono, e-mail, Ciudad, Código Postal, Provincia,
> País,
> > Consulta
> > Realizada (pregunta), Respuesta a la Consulta,
> Estado de la
> > Consulta
> > (Pendiente, Respondida, Descartada)
> >
> > 2) Crear las tablas necesarias en tercera forma
> normal para
> > guardar los
> > siguientes datos: nombres, apellidos, dirección
> principal,
> > dirección
> > alternativa, teléfono, ciudad, código postal,
> provincia y
> > país.
> >
> > 3) Crear las tablas necesarias en tercera forma
> normal para
> > guardar los
> > siguientes datos: Nombre, Apellido, Dirección,
> Teléfono,
> > e-mail,
> > Pedidos, Valor del Pedido, Items del Pedido, Pago
> del pedido.
> >
> > 4) Crear las tablas necesarias en tercera forma
> normal para
> > guardar los
> > siguientes datos: nombres del paciente, apellidos
> del
> > paciente, fecha de
> > la consulta, médico que lo atendió (nombre, apellido
> y
> > especialidad),
> > notas de la consulta, centro de salud (nombre,
> dirección,
> > ciudad)
> > ----
> > 5) Crear las tablas necesarias en tercera forma
> normal para
> > guardar los
> > siguientes datos: Nombre, Apellido, Dirección,
> Teléfono,
> > Categoría
> > Impositiva, Lista de Precios, Cod Artículo, Nombre
> Artículo,
> > Precio,
> > Tasa de IVA, Nro de Sucursal, Nro de Factura, Fecha,
> Cliente,
> > Cant de
> > Articulos, Artículos, Forma de Pago.
> >
> > 6) Crear las tablas necesarias en tercera forma
> normal para
> > guardar los
> > siguientes datos: Título del Libro, ISBN, Crítica
> del Libro,
> > Autores del
> > Libro, Editorial, Edición. Librería, Cantidad de
> Libros en la
> > Librería.
> >
> > 7) Crear las tablas necesarias en tercera forma
> normal para
> > guardar los
> > siguientes datos: Nombre del Foro, Nick del Usuario,
> Nombre
> > del Usuario,
> > Apellido del Usuario, e-mail del Usuario, Entrada en
> el foro,
> > Comentario
> > a la entrada en el foro. (Nota, las entradas deben
> poder verse
> > con sus
> > comentarios, y se permite poner comentarios a los
> comentarios.
> > Las
> > Entradas y los comentarios muestran su autor)
> >
> >
> > --
> > Leonardo Tadei
> > leonardot en pegasusnet.com.ar
> > Web: http://leonardo.tadei.com.ar
> > Firma pública:
> >
> http://www.pegasusnet.com.ar/LeonardoTadei-public.key
> >
> > _______________________________________________
> > Php-avanzado mailing list
> > Php-avanzado en pato2.fi.mdp.edu.ar
> >
> http://www3.fi.mdp.edu.ar/cgi-bin/mailman/listinfo/php-avanzado
> >
> >
> > _______________________________________________
> > Php-avanzado mailing list
> > Php-avanzado en pato2.fi.mdp.edu.ar
> >
> http://www3.fi.mdp.edu.ar/cgi-bin/mailman/listinfo/php-avanzado
>
> --
> Leonardo Tadei
> leonardot en pegasusnet.com.ar
> Web: http://leonardo.tadei.com.ar
> Firma pública:
> http://www.pegasusnet.com.ar/LeonardoTadei-public.key
>
> _______________________________________________
> Php-avanzado mailing list
> Php-avanzado en pato2.fi.mdp.edu.ar
> http://www3.fi.mdp.edu.ar/cgi-bin/mailman/listinfo/php-avanzado
>
>
>
> _______________________________________________
> Php-avanzado mailing list
> Php-avanzado en pato2.fi.mdp.edu.ar
> http://www3.fi.mdp.edu.ar/cgi-bin/mailman/listinfo/php-avanzado
--
Leonardo Tadei
leonardot en pegasusnet.com.ar
Pegasus Tech Supply
Tel: (+54)(+223) 471-2880
La Salle 1131 - Mar del Plata - Argentina
http://www.pegasusnet.com.ar
http://www.grupopegasus.com
Firma pública: http://www.pegasusnet.com.ar/LeonardoTadei-public.key
Más información sobre la lista de distribución Php-avanzado