<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>
Buenísimo leo, ahora lo corrijo y mañana lo vemos. Saludos!<br><br>Jorge Di Iorio<br><br><div><div id="SkyDrivePlaceholder"></div>> From: leonardot@pegasusnet.com.ar<br>> To: php-avanzado@pato2.fi.mdp.edu.ar<br>> Date: Tue, 27 Nov 2012 20:09:16 -0300<br>> Subject: Re: [Php-avanzado] DER<br>> <br>> Fe de erratas: el apellido es Codd<br>> <br>> <br>> <br>> Hola Jorge,<br>> <br>> La cosa mejora!<br>> <br>> El lun, 26-11-2012 a las 19:43 -0300, Jorge Di Iorio escribió:<br>> > Leo,<br>> > <br>> > <br>> > Buenas Tardes, ahí te mando nuevamente le DER con las<br>> > observaciones que me hiciste corregidas. Si te parece bien, arranco a<br>> > hacer los ABMC.<br>> <br>> Más allá de mi parecer, tu DER no está en 3FN (Boyd-Cood).<br>> <br>> Antes de empezar, tengo una duda: cuando en el gráfico planteás que un<br>> campo es una FK, implica esto algo a nivel del maneje de datos?<br>> En otras palabras, si Canchas tiene como FK id_complejo, al borrar un<br>> Complejo, qué pasa con las Cachas que tiene relacionadas en la DB?<br>> A esto hay dos respuestas con algunos matices: lo que pasa lo maneja el<br>> software; y lo que pasa lo maneja la DB.<br>> <br>> Cuál será el caso?<br>> <br>> Volviendo a la DER:<br>> <br>> a) En Estados seguís teniendo un campo discriminador. En la SRS tenés 3<br>> tipos de Estados para 3 Entidades distintas. Es posible que en este<br>> nivel los Estados de Reservas y los Estados de Reservas Fijas puedan ser<br>> los mismos, ya que tendría sentido que tengan los mismos valores, pero<br>> los Estados de los Alquileres ni se le parecen.<br>> Fijate si los Estados para ambos tipos de reserva pueden ser los<br>> mismos, con lo que las Reservas tendrían los mismos estados posibles. Si<br>> tiene sentido, te quedarán dos tablas, si no tiene sentido te quedarán 3<br>> tablas.<br>> <br>> b) En Alquileres te decía la iteración pasada que "recargo" y<br>> "descuento" son el mismo dato. Si nunca que se hace un recargo se puede<br>> hacer un descuento, y viceversa, uno de los dos campos sobra.<br>> <br>> c) También en Alquileres, al igual que con el Cliente y la Tarifa, tenés<br>> que poner los datos de la Cancha y del Complejo, ya que si no el borrar<br>> una Cancha o un Complejo, perdés la referencia de los Alquileres que las<br>> usaban.<br>> Con el Cliente, ya que en el problema estos tienen un código, parece<br>> buena idea que este dato también estén en Alquileres, además del<br>> apellido y nombre.<br>> Para las Reservas parece no hacer falta, porque la Reserva, en tanto<br>> que una promesa de futuro, vale la pena solo si los datos relacionados<br>> son actuales.<br>> <br>> <br>> > Con lo de los campos discriminadores me hiciste acordar a un<br>> > compañero de laburo al cual un vez le pregunte porque había "cableado"<br>> > un dato (estaba haciendo un if contra un valor que supuestamente nunca<br>> > iba a cambiar, pero igualmente lo correcto era tomarlo de<br>> > un parámetro). Su respuesta fue la siguiente: "Perdón! ésto no está<br>> > cableado, está finamente ligado..."<br>> <br>> Ahhh.... hacer las cosas mal parece tan fácil, y tiene tanto costo<br>> oculto!<br>> <br>> http://www.codinghorror.com/blog/2009/02/paying-down-your-technical-debt.html<br>> https://es.wikipedia.org/wiki/Deuda_t%C3%A9cnica<br>> http://www.microlopez.org/2011/02/11/deuda-tecnica-la-burbuja-de-las-tic/<br>> <br>> > Saludos<br>> <br>> =mente!<br>> <br>> -- <br>> Leonardo Tadei<br>> leonardot@pegasusnet.com.ar<br>> Web: http://leonardo.tadei.com.ar<br>> Firma pública: http://www.pegasusnet.com.ar/LeonardoTadei-public.key<br>> <br>> <br>> _______________________________________________<br>> Php-avanzado mailing list<br>> Php-avanzado@pato2.fi.mdp.edu.ar<br>> http://www3.fi.mdp.edu.ar/cgi-bin/mailman/listinfo/php-avanzado<br></div> </div></body>
</html>