>From: Alf <[EMAIL PROTECTED]> >Date: Wed, 19 Jun 2002 19:43:04 -0600 (CST)
>El criterio que priv� en el dise�o fue que, despu�s de que particip�s con >una m�quina en un InstallFest, ya sab�s c�mo instalarla - por lo que ya no >volv�s a llevarla. Esto puede ser una visi�n muy optimista, pero creo que >es relativamente limpia. �Qu� constituye la identidad de una m�quina? �cu�ndo dos m�quinas son la misma? Por un lado, una persona puede solicitar instalaciones para dos m�quinas con configuraciones id�nticas. Se supone que la instalaci�n en una deber�a ser la misma instalaci�n en la otra. As�, desde el punto de vista de instalaci�n, las dos m�quinas son la misma �cierto? La persona no deber�a pedir la instalaci�n para la segunda m�quina. Por otro lado, si la persona solicita la instalaci�n para una m�quina con cierta configuraci�n, y luego le cambia la configuraci�n (agrega/cambia quemador, tarjetas de sonido o video, discos,interfaz de red, etc). Me parece que la instalaci�n no ser�a la misma. �Puede solicitar otra instalaci�n para la "misma" m�quina pero con configuraci�n diferente? �y si no le cambia nada, pero quiere una instalaci�n con una distro diferente? �Se vale repetir? >Algo que no soluciona apropiadamente el modelo es >el caso de una instalaci�n de m�ltiples m�quinas (como un cl�ster, por >ejemplo) - pero nos pareci� que era hilar demasiado fino. ok >Otro asunto que se pens� pero se decidi� no modelar es la pertenencia >mancomunada de una m�quina. Se logra con ponerle cardinalidad n-m a >tiene(Persona, Maquina) - pero no nos pareci� muy buena idea. �Alguien >opina lo contrario? a m� tampoco me parece una buena idea. Qu� tal si, en vez de la relaci�n de pertenencia, se piensa en una relaci�n m�s d�bil. P.ej: el responsable de las m�quinas para cierta instalaci�n, que ser�a la persona que la solicita. Esto para no preocuparse de a cu�ntas personas pertenece una m�quina y no sentir que haya que hacerla n-m. La relaci�n se quedar�a siempre como 1-n porque no se vale traer la misma m�quina m�s de una vez. > > Todo esto, porque me parece que la relaci�n tiene(Persona, M�quina) no > > es relevante para el sistema.[2] > >Podr�a ser importante/interesante desde un punto de vista estad�stico. ten�s raz�n. > > De hecho, a lo sumo es una relaci�n derivada que se obtiene > > indirectamente de las relaciones pide(Persona, Instalaci�n) y > > recibe(Instalaci�n, M�quina). > >Nope. Si una persona llega a distintos festivales de instalaci�n con >distintas m�quinas, a nivel del modelo de datos no sabr�as de cu�l m�quina >se est� hablando en cada caso. �por qu� no? No lo veo. Voy a darle vueltas un rato. > > Tambi�n me parece que Maquina es una entidad d�bil, cuya existencia no >tiene > > por qu� separarse de la existencia de la instalaci�n en la que se >recibe. > > (S� que esto no es real, pero me parece razonable desde el punto de >vista de > > la aplicaci�n y siguiendo las ideas de los p�rrafos anteriores). > >Ah� estamos en desacuerdo. Especialmente en el modelo de datos. Est� bien, el razonamiento era que, como creo no tiene sentido tener registro alguno de una m�quina que nunca participa de ninguna instalaci�n, pod�a verse como dependiente de la entidad Instalaci�n. Pero es cierto que modelarlo as� no es muy natural. > > Una cosa que no entiendo es por qu�, en la relaci�n califica, Persona > > est� involucrada 2 veces. > >Una persona califica el trabajo de otra persona en una versi�n de una >distribuci�n durante un festival de instalaci�n. Se mantiene la >informaci�n del calificador y el calificado para ponderar el nivel del >calificado de acuerdo con los niveles de quienes lo califican. entendido. Encantado de poder participar. Saludos. Paulo. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. -- Desuscripci�n: escriba a [EMAIL PROTECTED], tema 'unsubscribe' Problemas a: [EMAIL PROTECTED] http://www.linux.or.cr/listas
