Diseño de un modelo de base de datos para almacenamiento de direcciones

Rachmaninov

Lanero Reconocido
21 Mar 2007
1,101
Cordial saludo comunidad,

Tengo un modelo profesional de base de datos que consiste en un almacenamiento de direcciones. Generalmente este tipo de información no es almacenada de manera desglosada, a lo mejor por la complejidad de manejarla de este modo.

Es común encontrar un Atributo en una Entidad por allá llamado "direccion", declarado como varchar(255) ó varchar(1024) con la nomenclatura completa correspondiente a la dirección. Este mecanismo afortunadamente funciona en muchos sistemas, y "la solución más simple posible es la mejor". Así que siempre que es posible, se aplica esta solución.

La sencilla solución anterior no siempre es la mejor aplicable, en algunos casos es necesario, y muy útil por cierto, desglosar la información de las direcciones. Principalmente para propósitos estadísticos entre otros beneficios.

Con el propósito de compartir y al mismo tiempo buscar algún apoyo e información valiosa para mejorar el modelo, quiero exponer el trabajo que he realizado, tengo dudas al respecto y no logro plantear correctamente algunas Entidades y definir lo más correcto posible las relaciones entre ellas, desde el punto de vista de diseño. Esperando que el beneficio sea mutuo, ojalá encuentre miembros interesados y conocedores del tema.

Prosigo con la información del modelo. Anexo una imágen con el modelo, dicho modelo es casi físico, no es un modelo lógico, pero dada la simpleza del modelo no vi necesario ponerles un diagrama lógico de entidades, son 3 entidades relacionadas entre sí, no más.

Puntos a tener en cuenta son:
  • Se trata de contemplar todo tipo de direcciones posible, extrañas, habidas y por haber: AV, Transversal/Diagonales, BIS, Conjuntos Residenciales. Dentro de los conjuntos residenciales sub-nomenclaturas especiales como Interior, Bloques, Apartamentos, Casas,... cualquier organización interna posible.
  • El modelo debe ser lo menos redundante y flexible posible. Es decir, en términos técnicos, lo más normalizado posible.
A continuación les muestro por medio de un ejemplo, algo así como el estado de los datos en el modelo para ilustrar mejor el propósito de las entidades, atributos y relaciones:

Ejemplo de Datos

Data la dirección: Kra 74A #74B-21. Conjunto Residencial "Torres de Juana" INT 5 APTO 516.

La información se reflejaría en el modelo de la siguiente forma:

ubicaciones

id_ubic = 1
num_seccion = 5
num_vivienda = 516
id_unom = 2

ubicaciones_nomenclatura

id_unom = 2
cod_localizacion = K (KRA)
val_localizacion = 74A
val1 = 74B
val2 = 21
id_barrio = 7

conjuntos_residenciales

id_unom = 2
nombre = Torres de Juana
cod_tipo_seccion = I (INTERIOR)
cod_tipo_vivienda = A (APARTAMENTO)

Dudas, Lagunas

El modelo funciona, acapara los casos (si alguien tiene algún caso que seguro no considero, sería valiosa la información, me sacaría de esta falsa seguridad y estaría muy agradecido). La duda que me asalta es la relación entre la Entidad "ubicaciones_nomenclatura" y "conjuntos_residenciales"; en el modelo está planteado como una "extensión" o "derivación" de entidades, pero igualmente las cosa podría ser:
  1. Un atributo que identifique específicamente el conjunto residencial, un id, algo como "id_cres". Además un atributo "id_cres" en la entidad "ubicacion_nomenclaturas" que relacione las entidades.
NOTA: Quisiera haber nombrado los pros/contras que noté en cada alternativa, pero ya resulta muy largo este post y lo menos que deseo es volverme aburridor.

PD: no ignoro un tema que ronda por la comunidad relacionado al diseño de base de datos, es un tema de diseño de base de datos en general, considero esto un diseño específico para profundizar, por eso he creado un tema aparte.
Gracias.
 

Archivos adjuntos

  • Modelo.png
    Modelo.png
    25.2 KB · Visitas: 798

Los últimos temas