DISEÑO DE LA BASE DE DATOS INMOBILIARIOS RESIDENCIALES

Por W H Inmon

El método tradicional de diseño de una base de datos es determinar qué campos para el procesamiento son necesarios para definirlos en la estructura. Dependiendo de la aplicación, los campos típicos de datos pueden incluir el nombre del cliente, la identificación del cliente, la dirección, la fecha del artículo comprado, etc.

Las prácticas del diseño clásico de la base de datos han sido las mismas desde que la primera base de datos hizo su aparición. 

Pero el diseño de una base de datos para bienes raíces residenciales es una historia diferente. Hay algunos problemas muy básicos. El primer problema es que hay MUCHOS, MUCHOS campos diversos de datos encontrados en una transacción inmobiliaria, como el comprador, el precio de compra, la fecha de compra, el vendedor, fecha de transporte, y así sucesivamente. Algunas transacciones inmobiliarias informan sobre la hipoteca, la empresa hipotecaria, los términos de la hipoteca, y así sucesivamente. O podría haber información sobre gravámenes sobresalientes en la propiedad. O sobre co-hipotecarios. O podría haber información sobre los impuestos adeudados. En resumen, es casi un accidente si dos transacciones inmobiliarias registradas tienen los mismos campos de información. Hay una amplia variedad de datos que se encuentra en las transacciones inmobiliarias y tratar de identificar y capturar toda la información que podría contener en la escritura es un asunto bastante difícil de hacer.

Además, cuando se crea la base de datos inmobiliarios que considera diferentes regiones, es casi una garantía de que habrá diferentes datos en las escrituras de fideicomiso. Esta profusión y confusión de elementos de datos encontrados en transacciones patrimoniales deja al diseño de la base de datos en un dilema: Si trata de usar el  método clásico de diseño de base de datos, este no funcionará muy bien.

Un diseño alternativo es no poner elementos de datos en la base de datos, sino poner clases de elementos en la base de datos, cada uno con un identificador contextual. Un ejemplo simple: podría haber una clasificación general de MÉTODO DE PAGO en la base de datos. Un identificador contextual es si se usó efectivo, cheque, o vale vista.

Cuando se encuentra una nueva forma de pago, un nuevo identificador se agrega a la base de datos. Ninguna redefinición de la base de datos es obligatoria. El analista de datos simplemente inserta (a nivel de aplicación) una nueva entrada contextual. Al utilizar este enfoque, no es necesario que el analista trate de capturar todas las formas de pago y cada una de esas formas de pago en la base de datos como su propio elemento de dato único.

Además, una escritura de fideicomiso tiene una forma de pago y la siguiente escritura de fideicomiso tiene otra forma de pago, y no hay conflicto en información en la base de datos, al menos en cuanto a los datos del analista (y el sistema de gestión de la base de datos).

Al romper ligeramente las reglas del diseño clásico de la base de datos, se pueden acomodar textos de forma libre como el que se encuentra en las escrituras de fideicomiso.

Y al romper ligeramente las reglas de la base de datos clásica el analista puede simplificar mucho el mantenimiento del día a día.

Hay un gran valor en la colocación de un volumen de las transacciones de bienes raíces en forma de una base de datos estándar. Mediante la creación de datos estándar base, el analista ahora puede manejar un volumen significativamente grande de transacciones. Para ilustrar la diferencia, intente dar 100.000 transacciones de bienes raíces a un analista que tiene que leer cada transacción para entender lo que está en ella. Vea cuánto tiempo tarda en procesar manualmente las transacciones (y vea cuán preciso es el análisis, también).

Ahora dé la misma propuesta a un analista que ha invertido tiempo en crear una base de datos. Pida al analista informático que lea y procese los registros. Ahora, compare cuánto tiempo le tomó a la persona que leyó los registros manuales en comparación con el tiempo que tardó el analista informático. No será una comparación justa.

Además, ahora cambie la cuestión de lo que debe analizar y vea qué analista se queja más: el que tiene que leer las transacciones o el que utiliza el computador para leer las transacciones.

Afortunadamente, con Forest Rim y la tecnología Textual ETL se puede leer y procesar datos textuales y colocarlos en una base de datos, utilizando técnicas simples como la descrita en este artículo. Ahora el texto sin formato se puede leer y convertir en una base de datos estándar. Ahora puede crear de manera cómoda, rápida y precisa una base de datos inmobiliarios que luego puede ser manejada por cualquier tecnología de base de datos.

Forest Rim Technology es una empresa de Bill Inmon ubicada en Denver, Colorado. Forest Rim tiene la tecnología necesaria para construir una base de datos inmobiliaria. Se puede entrar en contacto con Bill a www.whinmon@msn.com.