22 replies to this topic

[robert01]

Me gustaría saber si este diagrama de base de datos sería más o menos adecuado para un negocio de Alquiler de inmuebles. No se si hay errores en las relaciones entre las tablas. ¿que le cambiarían, eliminarían o agregarían uds? Gracias si Si alguno se toma unos minutos de su tiempo. Saludos a todos

Attached Files

•  3736_0fe0e1409eb962f9a2040bbcda66082d529c07e6.jpg   320.2KB   29 downloads

[TiammatMX]

Sin conocer el negocio, te puedo decir que es un buen diseño de bases de datos. Personalmente yo eliminaría la tabla de CONYUGE, no le veo mucho caso.

Regla #0 del diseño de bases de datos: Los datos necesarios en tus reportes SIEMPRE deben estar presentes en tu diseño.

¡Felicidades!

[Delphius]

Hola Robert01, hace tiempo que no te veo por aquí.

Yo soy de la idea de que la base de datos debe responder a las necesidades del negocio y del contexto, cuyo análisis y diseño responde a nuestro propio entendimiento y análisis que hagamos del mismo. Por tanto, en principio no se puede asegurar de que esté mal... pero no necesariamente esto quiere decir que esté bien.
Estará bien en la medida en que tu diseño te responda a tus observaciones. Si logras eso, pues ¡lo tienes hecho!
Que deberías cambiar, que eliminar, o que agregar pues no se... como no estoy al tanto del contexto no debería aventurarme a decir mucho.

Pero si me lo permites quisiera que nos expliques el porqué y a que se debe que haces distinción entre persona física, jurídica, locatario, propietario, garantes y hasta cónyugues y las relaciones entre éstas (es decir, entiendo que deba hacerse esta aclaración... sino más bien el porqué a esa forma en el diseño). A mi primera visión algo no me convence, y me parece algo lioso. Esto como primer punto ya que es donde veo que algo a tocar aquí puede tironear mucho más al resto del diseño.
En segundo lugar, como detalles no tan primordiales:
1) no logro entender el objetivo detrás de la tabla ALQ_A_RECIB y su relación respecto a CONTRATO. Me pregunto, ¿Tiene alguna relación, indirecta, con la tabla ALQUILER?
2) Relacionado con el punto 1, veo una tabla PAGO_PROP. ¿Existe alguna relación, aunque sea indirecta, entre un PAGO y un ALQUILER? ¿O es que la tabla PAGO_PROP está pensada para otro tipo de operación comercial, como una venta?
3) La tabla IMPUESTOS ¿debe responder a alguna operatoria que afecte a los montos para ALQUILER y/o PAGO?

Yo al menos distingo dos "centros de gravedad" (un término que yo "inventé" para referirme a tablas fuertemente relacionadas y dependientes), medianamente independientes: el primero formado por las tablas que hacen a las definiciones y clasificación de las personas, y el segundo formado por las posibles operaciones comerciales que se realizan.
Si se ha de tocar algo en algunos de estos centros es altamente probable que se vea afectado el resto del diseño.

Haciendo cierta analogía a las burbujas de una bebida gasificada, los centros de gravedad que sean más "pesados" tironean el diseño al fondo, mientras que la más entidades más ligeras tienden a subir. Cuantas más burbujas pesadas tengas es más probable que exploten, con el tiempo, en infinidades de burbujas pequeñas. Las burbujas pequeñas duran más, y dan mejor sabor. De lo que hay que tener cuidado es de no agitar demasiado el vaso porque sino nos quedamos sin burbujas y perdemos el gas...  O por llenarnos demasiado de burbujas pequeñitas que empiezan a subir súbitamente a la superficie debido al tanto gas que se justan tanto y rebalsan el vaso

Saludos,

[robert01]

Hola Delphius. Si hace tiempo que no andaba por aquí. Ahora ando bien de un problemita que tenía y voy a entrar más seguido a tomar cervezas virtuales.

El diseño se basa en en 3 o 4 diseños que estuve viendo por lo tanto es un engendro que se me ocurrió y que no se si puede andar más o menos bien o aún si tiene una lógica sustentable.
El negocio es de una abogada que se dedica entre otras cosas a administrar propiedades de terceros. Alquila casas y departamentos, cobra una comisión por el trabajo, percibe los alquileres y le gira el dinero a los propietarios de dichos inmuebles.
Hay en casos en que los impuestos son abonados por el inquilino, y otros en que los paga el propietario.
Se me ocurrió hacer una distinción entre personas físicas y jurídicas porque alguna vez puede ser una persona no física el inquilino, y pensando mejor ahora, tal vez la tabla Alquileres a Recibir no tenga sentido. Y la tabla Pagos a Propietario no se si debe estar relacionada con la tabla Persona

Saludos y gracias por responder

[Delphius]

Hola Roberto,

Como dices que se trata de una abogada ahora me queda en claro esas distinciones; aún así creo que se podría encarar de otra manera. Si puedo darme un tiempo mañana te hago llegar mis impresiones y una posible propuesta para que las compares. Aunque como dije: no es mi intención decir si está bien o mal... esto es lo "malo" del análisis; que cada quien tiene sus ideas y no necesariamente están errados.

Saludos,

[Delphius]

De lo visto al momento, así es como yo lo veo e interpreto:

delphi

Contratos -1--M- Integrantes -M---1- Personas -M--1- TipoPersona
                PK IDIntegrante
		FK ContratoID
		FK PersonaID
		FK CaracterID
 
TipoPersonas
//Física|Juridica
 
Integrantes -M--1- CaracterPersona
		   // Locatario|Propietario o Locador|Garante

Entonces ahora en Personas se disponen de todos los campos necesarios para llenar tanto a una persona física como jurídica. Simplemente se llena la información de los campos que se requieran según el tipo establecido y se dejan los otros vacíos.

Como en los contratos se expresan explícitamente, y así lo exige la ley, la relación material entonces es necesario hacer expresa la relación entre los cónyugues. Se puede recurrir a una tabla autoreferenciada:

delphi

Persona-1--+
     |     | {FK ConyugueID} <es cónyugue>
     +--M--+

De modo que la FK ConyugueID apunte a la PK de la propia tabla. Este diseño permite que una persona esté vinculada a muchas; lo que le dota la capacidad de casarse muchas veces.
El problema que puede surgir es que quizá se necesite hacer una estricta correspondencia marital al momento de celebrar el contrato. Es decir, que así como está este diseño no es capaz de identificar que al momento de celebrar el contrato X, en la fecha Y, la persona Z esté efectivamente en nupcias con W. Para lograr esto se debería alterar el diseño; aunque no sabría el modo de encararlo (no le encuentro la vuelta). O bien llevar el control por otra vía.
   

Preguntas habiertas a debate:
Un inmueble puede figurar en más de un contrato (y por tanto diferentes), a lo largo del tiempo, pero la pregunta es ¿un contrato está vinculado única y exclusivamente a un inmueble? ¿O puede darse el caso de que en un contrato se haga mención a más de un inmueble?
De ser lo segundo, entonces habrá que redefinir bien el diseño anterior para hacer una mejor vinculación y poder determinar las partes y en que caracter sea han asociado y vinculado a cada inmueble en forma particular.

Si asumimos el primer caso entonces el diseño es elemental:

delphi

Inmuebles -1--M- Contratos

Si es lo segundo entonces, tenemos una clara relación (M,M) entre Contratos e Inmuebles; pero además es posible que se dieran casos en que una persona esté asociada a más de un inmueble (¡y hasta en diferente carácter!), por tanto que exista una relación (M,M) entre Personas e Inmuebles. Mi propuesta inicial, a debatir es:

delphi

Contratos -1--M- Asignaciones -M--1- Inmuebles -1--M- Integrantes -M--1- Personas

La tabla Asignaciones establece la relación "a tiempo" entre un contrato y todas las propiedades que figuran en éste, como es de esperar se requiere de las debidas FK para lograr esta relación. La tabla Integrantes sigue manteniéndose tal como está, en ella se establece la relación entre cada persona que figure en el contrato (lo correcto sería llamarlas como en la jerga legal: partes) y bajo que carácter.

Lo que me queda por analizar es el segundo centro de gravedad. Sería muy oportuno que nos hagas llegar tus observaciones en más detalles; puesto que por tus palabras al parecer no estás del todo convencido en este punto.

Espero que se entienda mi propuesta. Quedo a la observación de ustedes.

Saludos,

[Delphius]

Ha... por cierto, no estaría demás añadir y registrar datos sobre las refacciones, mejoras, y condiciones habitacionales en la que se encuentra el inmueble o se les vaya haciendo al mismo.

Al menos, así es como nos manejamos en mi flía con el alquiler de una propiedad que tenemos. En el contrato de alquiler se deja asentado el estado en que se ha recibido la casa, y bajo que términos debe devolverlas. Y en vista a que se han hecho mejoras y ampliaciones la descripción del inmueble ha variado. Yo sospecho que puede ser útil, tener esto registrado... un inmueble no es un bien que necesariamente permanezca "fijo" y en su estado por toda la vida. Más aún si recordamos que estamos en Argentina y tenemos la costumbre de ahorrar e invertir nuestro dinero en ladrillos y darle mantenimiento.

Yo al menos veo útil señalar y dejar constancia que a cierta fecha por dar un ejemplo, un inmueble X contaba con 5 habitaciones y luego para otro contrato (o una renovación) el propietario cuando haya realizado algunas mejoras pueda decir que ahora tiene 6 habitaciones, un quincho y vaya a saber que más. 

Esto es ya algo como frutilla de postre, y no de importancia... incluso como algo terciario y si sobra tiempo.

Saludos,

[robert01]

Hola Delphius

Con respecto a las personas si, se da el caso de que una persona puede ser inquilino y garante. Perso no es muy común

Me parece que un contrato se hace para un inmueble en un tiempo determinado, en estos casos es improbable que se un contrato se refiera a varios inmuebles pero pensándolo bien no es algo inusual que se alquilen varios inmuebles juntos.

Y en cuanto a las condiciones en que se entrega el inmueble hay casos en que el inquilino al retirarse no entrega como está, sin haberlo pintado y dejado como se le entregó el ingresar y en este caso, el propietario le cobra una suma para hacer el mismo las refacciones.

En cuanto a lo de ahorrar en ladrillos yo creía que se ahorraba en dólares o dolores, jaja

Saludos

[Delphius]

Hola Delphius

Con respecto a las personas si, se da el caso de que una persona puede ser inquilino y garante. Perso no es muy común

Como bien dices, no es algo común pero pueden darse casos. El diseño que yo propongo lo permite para darle cierta flexibilidades. Además, el que se pueda realizar estas caracterizaciones permite que una misma persona pueda aparecer en diferentes contratos bajo diferentes caracterizaciones... quien sabe, a lo mejor el señor X vivió alquilando pero justo un amigo le pidió que sea de garante y fueron a parar al mismo estudio para hacer los papeles. Si se registrase a esa persona X con una caracterización en concreto se harían más difíciles las cosas.

Me parece que un contrato se hace para un inmueble en un tiempo determinado, en estos casos es improbable que se un contrato se refiera a varios inmuebles pero pensándolo bien no es algo inusual que se alquilen varios inmuebles juntos.

Si, yo también considero que un contrato es específico y puntual a un inmueble; aunque vaya a saber si es posible que se dieran algunas de esas situaciones... Justamente me lo quedé pensando porque me hizo acordar a un borrador de contrato que estuve viendo con mi viejo mientras estábamos resolviendo cuestiones de la flia en donde se nombraban a dos propiedades y sus usos y en donde se disponían las cláusulas propias a cada una como las comunes a éstas.
Y bueno, por las dudas preferí dejar abierto esta posibilidad... después de todo no veo que cueste demasiado llevar el sistema con esto.

Y en cuanto a las condiciones en que se entrega el inmueble hay casos en que el inquilino al retirarse no entrega como está, sin haberlo pintado y dejado como se le entregó el ingresar y en este caso, el propietario le cobra una suma para hacer el mismo las refacciones.

Pues si, eso de las condiciones es muy relativo y la mayoría de las veces se arreglan entre el locatario y el locador. Yo más bien apuntaba a la posibilidad de que se analice si es de utilidad e interés poder ver el modo de como registrar el estado del inmueble y posibles mejoras que se hagan.
Por ejemplo, la inmobiliaria que administra una propiedad que tenemos lleva registro de los arreglos y refacciones que el inquilino ha realizado, como así también las que hemos realizado nosotros. El inquilino previamente tiene que pedir una autorización. Generalmente estos arreglos y alguna manito de pintura los hemos dejado en que se le descuente del alquiler.

Esto les permite saber el estado en que está el inmueble y poder darle un mejor estimado de su valor. Yo me imagino algo como una especie de histórico y con la posibilidad de que si el inmueble lo permite que se amplíe las locaciones de éste. Tu has dispuesto una tabla Habitaciones con una pequeña modificación se la puede adaptar para permitir que se le ingrese más locaciones y otros detalles.

En cuanto a lo de ahorrar en ladrillos yo creía que se ahorraba en dólares o dolores, jaja

Saludos

Pues si... en las dos cosas... cuando se puede. Aunque con estas trabas que nos ha puesto la reinita ya ni se puede hacer ni lo uno ni lo otro. Bien dices... ¡dolores! Eso si tenemos ahorrados... dolores de oidos por sus discursos, dolores de estómago por la repulsión que provocan sus dichos, dolores de bolsillo, dolores por todos lados.
Yo ya tengo una rabia... ya de por si era difícil adquirir una licencia de Delphi, ahora directamente NO PUEDO. Menos mal que ya dispongo de Linux y Lazarus porque de otro modo imposible adquirir algo de afuera y más sabiendo que es a dólares. La verdad es que no entiendo como se espera que se pueda seguir promoviendo y avanzando en la "Innovación Tecnológica" (que al menos alguito bueno han querido hacer desde el ministerio de Tecnología en los últimos 3 años) si está cerrada la entrada tanto de equipos como de licencias y la posibilidad de moverse con dólares.

Saludos,

[robert01]

Ahora me quedo medio confundido porque no veo que hacer con la tabla Alquileres y la otra de Pagos al propietario o Locador.

La base de datos quedaría así como en la imágen.

Ahora me doy cuenta que el locador puede no ser el propietario. Hay gente que tiene administradores que se ocupan de eso pero noc reo que sea este el caso

Attached Files

•  3738_316cf8e0bb137ed90ef857bfb1ce2caa456aa43d.jpg   115.22KB   5 downloads

[Delphius]

Ahora me quedo medio confundido porque no veo que hacer con la tabla Alquileres y la otra de Pagos al propietario o Locador.

La base de datos quedaría así como en la imágen.

Ahora me doy cuenta que el locador puede no ser el propietario. Hay gente que tiene administradores que se ocupan de eso pero noc reo que sea este el caso

Lo de alquileres y pagos no lo he visto aún Robert por lo que no te sabría decir hasta el momento como orientarlo; no me he dado el tiempo. El problema es que hay ocasiones en que estos arreglos y los pagos y sus formas tienen cosas que a veces se escapan de la norma. Para Pepito se hace así, que a Pedrito asá...

Lo que veo del diseño es que aprovechaste mi propuesta. Noto que por una falta mía en explicarme tienes dos errores menores. Las tablas CaracterPersona y TipoPers no cuentan con esos campos, sino con al menos un campo PK y un campo Nombre o Descripción. De este modo uno puede llenar tantos carácteres y tipos como necesite.
Por tanto Locatario, Propietario y Locatario son ejemplos de los tres registros básicos que dispone CaracterPersona:

CaracterPersona:
---------------------
01 - Locatario
02 - Propietario
03 - Garante

El mismo principio se aplica para TipoPers.
¿Se entiende?

Dices que puede darse el caso en que el Locador no sea efectivamente el propietario, sino que hay un administrador que se encarga de ello. La base de datos permite eso, basta que añadas un nuevo registro:

04 - Administrador

E ingreses a la persona y le asignes el caracter. La intención de la tabla Integrantes es que justamente se permita llevar registro de toda persona que participe y se le asigne las atribuciones que les corresponde a cada uno.
Ahora bien, yo al menos tengo entendido que no interesa quien administre o lleve el estado del alquiler... En el contrato figura el propietario y dueño real del inmueble, aún cuando quien administre fuera un tercero. Ya que el contrato deben figurar el inquilino y el dueño. Por ejemplo, en el contrato de alquiler de la propiedad que tenemos en la flia figura como propietario mi padre y mi madre, y eso que el que lleva el control es la inmobiliaria.
En todo caso es que existe el contrato entre mi padre y la inmobilaria en donde se deja expreso que se delega parte de las responsabilidades de una persona a otra a cargo de cierto porcentaje y se deja aviso y constancia al inquilino de ello continuando vigente el contrato original entre el dueño y el inquilino.
Ahora bien hay contratos, y se puede, en donde se deja en claro quien es el propietario, quien administra, etc. Por ejemplo en otra propiedad que tenemos dejamos en mano de un pariente el control del alquiler. En el contrato figuran estas tres personas: el dueño, el "administrador" y el inquilino.

Pero todo esto no afecta al menos a nivel de base de datos, como he dicho el diseño es lo suficiente flexible para permitirlo. Incluso hasta se permite que una misma persona tenga varias caracterizaciones:

Monchito -> Propietario
Monchito -> Administrador
...

No hay que confundir la tabla Integrantes con la cantidad física y real de miembros que aparecen en el contrato. Quizá el nombre que escogí no es lo más adecuado... Quizá sea más apropiado AsignacionesResponsabilidades o algo por el estilo. La cantidad de personas, e integrantes, para el contrato se determina consultando en la tabla Personas (naturalmente aplicando el filtro y las condiciones adecuadas)

Saludos,

[robert01]

Hola Delphius

Si, no había entendido bien lo que significaba. Ahora entiendo lo de la tabla CaracterPersona pero no se me ocurre como relacionarlo con una tabla Alquileres, etc
ummm, o tal vez no debería relacionar la Tabla CaracterPersona con la tabla Alquileres sino la tabla Inmuebles con Alquileres
Espero tener una idea en algún momento

Saludos

Attached Files

•  3746_4abb74aba992a71ffbe9e98f2dbc49fed2bf8e5d.jpg   125.09KB   3 downloads

[Delphius]

Hola Robert01,
Considero que no es buena idea que esa parte del problema esté relacionada con CaracterPersona; es más yo no veo alguna posible relación a esperar entre CaracterPersona y Alquileres. Me parece que la relación va más hacia la tabla Contratos y/o Inmuebles.

Todo dependerá de lo fino y detallado que se necesite llevar el proceso en este punto. Estoy pensando que incluso se debería pensar en una diferencia entre lo que es el alquiler y el cobro del mismo. Es decir, separar la definición y la asignación del valor del alquiler del cobro del mismo. Así como existe en algunos sistemas de facturación las entidades Ventas, Cobros, Remitos, etc. que responden en forma conjunta a un proceso que podríamos llamar "Cobrar Ventas", en la misma forma quizá sea necesario llevarlo para el caso del "Cobrar Alquiler".
Más sabiendo que es posible que el valor del alquiler no siempre sea el mismo, si bien se lo define por contrato en éste se dejan en claro los porcentajes de aumentos, cada cuanto serán, etc. Por ejemplo: por contrato se define que a mediado de año se aumente el valor del alquiler en un 20%. O por ejemplo, que tras una reforma al inmueble el valor sube $300...

Entonces al menos, para comenzar yo dispondría y aprovecharía la tabla intermedia Asignaciones para además de formar la relación entre contrato e inmueble para relacionarla con una tabla AsignacionesAlquiler. Esta tabla está pensada para registrar los aumentos/descuentos/etc que sufre el alquiler. La relación es:

delphi

AsignacionesAlquier -M---1- Asignaciones

Para esta tabla visualizo los siguientes campos:
PK IDAsignAlquiler
AFecha: Fecha/Hora ó Fecha //Fecha a la que entra en vigencia este valor del alquiler
Valor //Monto asignado
FK ExpresionID
Vencimiento: Fecha/Hora ó Fecha
Interes

Siendo ExpresionID una clave foránea que apunta a la PK de una tabla ExpresionValor. Esta tabla registra las posibles maneras en como se puede definir o expresar el valor del alquiler. A modo de ejemplo:

ExpresionValor:
PK IDExpr
Nombre
Descripcion

Entonces se tendría algo como:

01 - Porcentaje - Inc/Dec expresado en forma porcentual, por ej: +15%, -10%
02 - Entero - Inc/Dec expresado en un monto entero, por ej: +$500, -$300
03 - Fijo - No hay inc/dec. El valor del alquiler es fijo, por ej: $5000

Se podría obviar esta tabla si no se prevee más posibles maneras y directamente asumir para el campo "Expresion" (como ya no sería FK omito el sufijo ID) ciertos valores pre-establecidos.

Luego dispondría de una tabla para registrar los cobros. Algo como:

Cobros:
IDCobro
Fecha
Monto
FK AsignAlqID //FK hacia AsignacionesAlquiler

Este diseño responde a una relación (M,1):

delphi

Cobros -M---1- AsignacionesAlquier

Para permitirle la posibilidad de que se haga pagos parciales... quien sabe, hay gente que te paga el alquiler como si fuera a cuotas  Aunque si no se va a dar ese caso entonces puede obviarse esta tabla y disponer de su información directamente en AsignacionesAlquier... que se resume a añadirle un campo como "CobradoEl" de tipo Fecha/Hora y si se considera adecuado un campo "Cobrado" de tipo verdadero/Falso, que para el caso de Firebird se ha de hacer con un integer a nivel 0/1 o un (var)char "SI"/"NO".

Por ahora solo puedo decirse esto. No he pensado en más, y seguro que me estoy dejando muchas cosas. Ha decir verdad sólo me limité a verlo de la forma más simple que se me ocurrió y no se hasta donde más necesitas llegar.
Como nota final, noto en tu último DER que añades un campo NombreConyuge a la tabla Persona. Este campo puede obviarse ya que justamente existe el campo Nombre. 

Saludos,

[robert01]

Gracias Delphius. Muy claras tus explicaciones. No puedo calificar porque da error. No se si es porque ya calificaron antes.

Sólo me faltan los impuestos que algunas veces los pagan la mitad el propietario y la mitad el inquilino y otras, los paga el propietario o por lo menos a algunos los paga en forma total el propietario.
Creo que voy a poner un campo con la suma del monto de los impuestos y otro con el alquiler más los impuestos que corresponda pagar en la tabla Cobro

Saludos

[Delphius]

Hola Robert01,
¡Lo que me comentas sobre los impuestos se me ha pasado por alto! Considerando los posibles casos, y que efectivamente ¡se dan! el diseño ya se complica un tanto.
No se muy bien como implementar esa parte... mi primer pensamiento, así sin pensarlo demasiado es disponer de una tabla de AsignacionesImpuestos que esté relacionada justamente con la ex tabla Integrantes (como he dicho en uno de mis mensajes anteriores... Integrantes no es un nombre muy apropiado). Como justamente en esa tabla se designa el carácter de cada persona, y por tanto sus responsabilidades contractuales, pienso que una manera de distinguir y asociar que Impuestos van a cada persona es justamente formalizando su vínculo.

Mi primera aproximación es:

delphi

ExIntengrantes -1---M- AsignacionesImpuestos -M---1- Impuestos

¿Porqué una relación (M,M) entre "ex Integrantes" e Impuestos por medio de esta intermedia? Porque como hemos dicho, hay impuestos que son compartidos y otros que no. De ese modo en tabla Impuestos se almacena la descripción del impuesto y en AsignacionesImpuestos se deja para llevar la relación, y en que tantos, respecto a cada persona.

Ahora bien mi cabeza me dice que posiblemente existe una relación no identificada y escondida entre AsignacionesAlquileres/Cobros y AsignacionesImpuestos; lo que me hace dudar del impacto en el diseño en general.

Como dije en un ocasión anterior, justamente en otro hilo tuyo sobre el caso de los análisis clínicos, hay que hacer lo posible para evitar los ciclos en un DER. Mi propuesta y que tu estás siguiendo, tiene uno: Contrato -> Asignaciones -> Inmuebles -> ExIntegrantes -> Contrato. Y si mi cabeza está en lo cierto y se descubre dicha entidad y se considera útil es casi una certeza de que se formará un segundo ciclo.

No estaría mal que alguien más revisara mis propuestas y se debatiera, y si alguien considera que hay otra forma de llevar el DER (sobre todo si la propuesta ofrece algo que no conduzca a ciclos) bienvenido sea.

Saludos,

[robert01]

Hola

Efectivamente en ese post me recomendaste evitar los ciclos, cuando se formó ese ciclo de acordé de eso.
No se si habrá otro ciclo, yo no lo veo ahora. Voy a subir el DER tal como quedó ahora, a lo mejor algún compañero forista lo ve y da su opinión.

Saludos

Attached Files

•  3748_1575c5dcf0f9f6742604599daa369c8ea1db3db7.jpg   255.1KB   8 downloads

[Delphius]

Hola Robert01,
Bueno, en realidad no es que está contraindicado los ciclos... hay veces (estimativamente entre un 35% al 50% de los DERs los tienen) en que surgen naturalmente.
Se trata de un consejo o algo a tener en cuenta por y para cuando el análisis y el diseño se vaya haciendo más refinado y complejo.
Los ciclos por si mismos no son un problema, más bien los problemas surgen al momento de llevar a cabo el sistema y la forma en como se lleve a cabo las funcionalidades a las que dan soporte las tablas involucradas; sumándose los dobles sentidos para recorrer y capturar los datos al momento de realizar las operaciones SQL.
Un ciclo no es demasiado lio, y hasta se puede considerar algo normal... cuando se encuentran 2, 3... y que comparten la mayor parte de entidades en común (peor si es un subciclo dentro de otro) es que se puede disparar la alarma de que algo quizá no se haya comprendido o analizado mal.

Yo tampoco veo otro ciclo... pero como dije... como que me ha quedado la sensación de que es posible de que exista o se requiera de alguna relación entre la tabla AsignacionesAlquier (y/o Cobros) y la tabla Impuestos (o quizá más propiamente, AsignacionesImpuestos) y se termine formando otro ciclo. Aunque al momento no la he podido explotar o reconocer.
El DER que te propongo puede funcionar... para algunas cosas mejor que en otras. Lo bien o malo dependerá de como sea capaz de absorber los requisitos y funcionalidades que requieras y de la creatividad que tengas para encarar el desarrollo del sistema.
Para mi al momento puede venir bien... aunque no estaría mal que otros se sumaran al debate. En parte porque siento que estoy en un monólogo y estoy monopolizando ideas, y por el otro se me está quedando el cerebro más apagado últimamente y no me estoy dando el debido respiro.

Saludos,

[robert01]

Hola

Necesito que el monto en la Tabla Cobro se calcule como la suma o resta entre alquiler e impuestos pagados. Creo que me conviene relacionar la tabla Impuestos con la tabla Cobro pero no se si sería correcto. A lo mejor no hace falta y lo pueda hacer de otra forma.

Saludos

[Delphius]

Hola

Necesito que el monto en la Tabla Cobro se calcule como la suma o resta entre alquiler e impuestos pagados. Creo que me conviene relacionar la tabla Impuestos con la tabla Cobro pero no se si sería correcto. A lo mejor no hace falta y lo pueda hacer de otra forma.

Saludos

Alli ya me quemaste los cables  Quizá sea viable buscar el modo de normalizar el diseño justamente en ese punto, y evaluar el modo de relacionar las entidades en cuestión. En una de esas podría favorecer a los cálculos y hacer el sistema más llevadero.
Aunque también se podría encarar el problema de otra forma.

Volviendo a ver el último DER y recordando mis palabras se he ha pasado por explicar mejor algunas cuestiones que podrían ayudar a unir cosas:
La existencia de la tabla ExpresionValor y su relación con AsignAlquiler está pensada justamente para determinar el valor real del alquiler a ese momento (fecha). De modo que dependiendo del tipo de Expresión se determine lo que corresponde. Inicialmente yo determiné 3 modos: inc/desc porcentual, inc/desc en un valor entero, o fijado (exacto).
Cuando se trata de un inc/desc se asume que se toma como valor "base" el alquiler del mes anterior (o para ser más exactos y ubicarnos en el diseño: en la asignación del alquiler para el mes anterior). Por tanto, supongamos que para enero el valor era de $2500. Entonces si para la asignación del alquiler a Febrero se tiene pensando un incremento del 10% lo que se hace es justamente es: 2500 x 1,10 = $2750. Ese valor calculado se almacena en el campo Valor.
Lo mismo se aplica si se determinase incrementos o decrementos en una expresión entera... Hagamos de cuenta que al propietario le ha picado el bicho del espíritu navideño y ha dicho que para Diciembre se le descuente $300 a su inquilino que nunca le ha fallado. Entonces si para Noviembre el valor era de 2800, el cálculo para Diciembre es: 2800 - 300 = 2500.
Cuando se trata de un caso exacto, no tiene una "evaluación hacia atras" sino que se trata de una correspondencia directa.... Al propietario se le pasó el buen humor y justo en reyes sufrió un incendio y no se le ocurrió mejor idea que hacerle sufrir a su inquilino. Dijo que para Marzo el alquiler sea de 3200. Ni más ni menos. Entonces la asignación al campo valor es directa, se fija en 3200 y no hay cálculo alguno.

Ahora bien, aquí surge el tema de los impuestos. He apreciado que tu añadiste en AsignAlquiler un campo Interes. Pregunto ¿Este campo es y hace referencia a algún impuesto?. Si recordamos, hay impuestos que son para el inquilino, otros para el propietario, etc. Debido a eso mi propuesta fue disponer de una tabla intermedia que haga las relaciones entre "ExIntegrantes" e "Impuestos".
Si se ha de establecer una relación directa entre Impuestos y Alquileres la pregunta a hacernos es ¿Cuál sería su cardinalidad? A mi parecer, diría (M,M):

AsingAlquiler -1---M- ¿? -M---1- Impuestos

Estoy un tanto falto de nombres, tu luego verás es más adecuado. Por ahora yo la llamaré Impuestos_X_Alquiler.

La ventaja de haber hecho efectiva esta relación es que se puede hacer consultas y operaciones directas para obtener el valor del alquiler. En términos simples diríamos:
Valor = [Valor-mes-anterior +/- {Porcentaje|Entero}|Exacto] + Impuestos

Es decir, lo "calculado" según el modo de expresión, y agregarle los Impuestos.

Ahora bien, el "peligro" de haber hecho esta relación explícita es que se podría hacer correspondencias entre ciertos impuestos que no corresponden a cuenta del inquilino y no hacen al alquiler. Peligro entre comillas debido a que ya es una responsabilidad conjunta entre el sistema y el motor de la base de datos, de asegurar que al momento de hacer los cálculos tengan lugar los impuestos adecuados. Esto se hace aplicando por ejemplo una consulta con los encuentros (JOINs) necesarios hacia CaracterPersona y filtrando aquellos que sean para el inquilino.

A mi humilde parecer Impuestos_X_Alquiler es ahora quien contiene entre sus campos, el que almacena el valor del impuesto. Aunque, aquí habrá que hacer unos paréntesis... Hay impuestos ya fijos, y es posible que existan otros en los que dependan del valor del alquiler, como por ejemplo en términos porcentuales. En principio no supondría demasiado problemas, se puede prever un diseño parecido al de ExpresionValor. O quizá hasta directamente aprovecha esta tablita para vincular a ambas:

Impuestos_X_Alquiler -M---1- ExpresionValor -1---M- AsignAlquiler

A mi ver, quizá no suponga demasiado problemas hacer tener esta tabla "Impuestos_X_Alquiler".
El resto es más de imaginación e ingenio para hacer algunos cálculos.

Respecto a la tabla Cobros, como te comentaba lo que yo consideraba es la posibilidad de que se pudiera abonar en varios pagos, a modo de cuota. De allí que existiera una relación (1,M) entre AsignAlquiler y Cobros. Para saber si se ha pagado el alquiler en su totalidad basta con calcular la sumatoria de dichos cobros y comprobar si es igual al valor asignado para el alquiler. Gracias a este diseño, y con un poco de astucia se pueden armar consultas e informes para saber los morosos, cuanto deben y que deben.
Entonces esta tabla la pensaba para que se registre el pago real que hiciera el inquilino. Y no en el valor total a cobrarle a éste. Lo que tu llamas monto en Cobro ya estaría en el campo Valor de AsingAlquiler.

Ahora bien, si tu tienes la intención de que el monto de tabla Cobros se calcule efectivamente como sumas/restas entre los alquileres e impuestos pagados/no pagados si que debería hacerse unos cuantos cambios al diseño. Para ir dando un norte, yo lo entiendo así:

Cobro -1---M- AsignAlquiler

Y dejaría intacto la relación entre AsignAlquiler, Impuestos_X_Alquiler e Impuestos.

A menos que el contexto de los impuestos no se apliquen de forma particular a cada alquiler, es decir que el valor de los impuestos se determine en general y global como si se tratase de un "paquete" por los alquileres pagados/no pagados (de aquí ya puede verse que podría ser de interés este campo o atributo booleano para AsignAlquiler). Si fuera este caso entonces lo correcto sería que la relación de los Impuestos vaya hacia Cobros y por tanto ya no sería Impuestos_X_Alquiler sino Impuestos_X_Cobros.

Mi error estuvo en haberla llamada Cobros, según mi visión debería haberla llamado PagosAlquiler. Si tu en verdad quieres destinar la tabla Cobros para efectivamente almacenar el "valor real" a cobrar puedes hacerlo. Para este caso, te dejo que evalúes si te resulta de interés una tabla Pagos que registre los pagos efectivos para dichos Cobros. Una primera impresión es que no es necesaria: 1 Cobro -> 1 Pago; a menos que consideres el sistema de "cuotas" en donde si necesitarás una Tabla de Pagos, o PagosCuotas... el nombre lo ves tú.

Ahora bien... ya está el tema de los pagos de inquilinos. Como dijiste que hay Impuestos que hacen al Propietario, la pregunta es ¿Este impuesto hace o tiene alguna relación, o depende del alquiler? Porque dependiendo de tu respuesta quizá sea necesario un buen giro de tuerca...
Hasta ahora mis propuestas se han centrado en lo que lleva al alquiler y al inquilino.... pero es posible que surjan cosas que hagan aparecer tablas como del tipo CobroPropietario/PagoPropietario como forma análoga a las de lo referente a los alquileres y que caen al Inquilino.
A estas alturas cabe la pregunta ¿Llevamos un diseño que se parta en dos y distinga de lo que hace a cada uno (y que por tanto ya la tabla CaracterPersona no tiene sentido) o se sigue buscando la forma de amoldarlo según lo ya hecho?
Pregunta: Si el inquilino paga Alquileres, ¿cómo se llama lo que paga el Propietario (fuera de lo que podría ser Impuestos)?

Como ves, ya se está haciendo más complicado el diseño... cada vez hace falta afinar más los detalles y conocer lo mejor posible el contexto. Yo hago muchas asunciones, y suposiciones... no es la forma correcta de llevarlo a cabo. Si tu puedes colaborar en una puesta del contexto y bajar a tierra la mayor cantidad de cosas podríamos evaluar bien en forma integral. De otro modo estaremos viendo punto por punto lo que nos pone a una postura de ir tratando de "parchear" el diseño para amoldarlo... y no en una visión más sana sin parches... O peor incluso: que se intente amoldar los puntos al diseño.
Lo correcto es que el contexto nos diga y dirija el diseño, no que el diseño nos condicione y termine haciendo que el contexto se adapte. Por ello es que pongo tanto énfasis a que se evalúe el contexto, se haga un más que bien merecido análisis de todo y recién con todo eso ir al diseño de la base de datos.

Saludos,

[Delphius]

Por cierto, ¿Que herramienta usas para dibujar el DER? Yo utilizo el casi extinto IBUtils... y tengo mis reservas de si será compatible con las versiones superiores... al menos con FB 1.5.x funciona.

Saludos,