¿La evolución de la información de contacto significa cambiar su base de datos?

Hay varias formas de contactar a alguien en estos días, ¿verdad?

Disponemos de varios teléfonos:móviles y fijos, personales y de trabajo. Tenemos diferentes direcciones (residencial, postal, de facturación, comercial, etc.) y probablemente también varias direcciones de correo electrónico. No olvides Skype y varias aplicaciones de mensajería. Ahora agregue LinkedIn y Facebook, que por cierto, ambos tienen sus propios elementos de mensajería.

No hace mucho tiempo, muchos de estos no existían. Entonces, puede garantizar que, en unos años, tendremos una nueva forma de contactar personas y organizaciones.

¿Podemos modelar toda esta información de contacto de tal manera que no tengamos que cambiar el diseño de nuestra base de datos cuando aparezca "lo último"? Siga leyendo para averiguarlo...

El modelo de punto de contacto del partido

En una palabra, sí. Las bases de datos se pueden diseñar para acomodar información que aún no tenemos.

Voy a saltar directamente y mostrarte la solución, luego describiré cómo funcionan las piezas juntas. Voy a llamar a las diversas formas de contactar a las partes puntos de contacto , aunque he visto métodos de contacto e incluso ubicaciones de contacto usado.

Físicamente, todos estos puntos de contacto se almacenarán en una sola columna de tabla, contact_point.contact_value . Piense en un número de teléfono, una dirección de correo electrónico o una dirección web (URL) y comprenderá por qué podemos almacenarlos todos aquí; son solo cadenas (varchars) en este nivel. La diferenciación está en los metadatos. La única excepción a esto es la dirección postal, que se describirá con más detalle más adelante.

Las tablas amarillas de la izquierda contienen metadatos y las tablas azules de la derecha contienen datos comerciales.

Las principales categorías

Aunque tenemos muchas formas de contactar a alguien, estas formas en realidad se dividen en una pequeña cantidad de categorías o tipos. Verás lo que quiero decir cuando mires la lista a continuación:

En cierto sentido, estos son físicamente distintos. Por supuesto, puedes usar un teléfono móvil para llamar a un teléfono fijo o a otro móvil. Cuando se trata de llamadas de voz entre teléfonos fijos y móviles, la distinción no es tan importante. Aun así, es más probable que enviemos un mensaje de texto (SMS) a un teléfono móvil que a un teléfono fijo.

Pero no es probable que deliberadamente llame por voz a un número de fax. Después de todo, ¿qué le vas a decir cuando lo escuches, aparte de 'Ups, número equivocado'? Naturalmente, es mucho más probable que llame con otra máquina de fax, ya sea física o emulada. Tampoco enviarías una carta a un teléfono fijo, ni intentarías hacer una llamada de voz a una dirección postal.

Es importante que distingamos estos tipos, porque interactuamos de manera diferente con ellos. Esto será especialmente cierto si su aplicación tiene algún tipo de integración con los servicios de comunicaciones. Necesita saber con qué tipo interactuar.

Cómo utilizan las partes los puntos de contacto

Esto es probablemente un poco más intuitivo, un poco más en línea con nuestra forma de pensar sobre los tipos de contacto. Aquí hay una lista más larga (¡pero no exhaustiva!) que te ayudará a tener una idea de estos tipos:

La dirección postal:un caso especial

Todos estos tipos de puntos de contacto se almacenan en un solo campo, con la excepción de una dirección postal. Esto normalmente requiere un número de líneas (o campos).

Hay un artículo de blog aquí que propone una forma simple e independiente del idioma para almacenar direcciones postales. Si sus requisitos son bastante básicos, p. para imprimir las etiquetas de direcciones prácticamente a medida que se ingresan en el sistema; este enfoque probablemente sea suficiente. Si sus necesidades son más sofisticadas, probablemente tendrá que desarrollar una solución diferente.

Para tener una idea de cuán complejo puede ser el direccionamiento, eche un vistazo rápido a este esquema para los tipos de direcciones del estándar británico BS7666. La norma comprende una serie de partes que abarcan los nomenclátores de calles, los nomenclátores de terrenos y propiedades y los puntos de entrega. No diferencia entre propiedades comerciales o residenciales; entre terrenos ocupados, urbanizados o baldíos; entre zonas urbanas o rurales; o entre entidades con direcciones postales y entidades sin direcciones postales s tales como mástiles de comunicaciones (torres). Para lograr esto, introduce términos con los que la mayoría de nosotros probablemente no estamos familiarizados, como Objeto direccionable primario (PAO), que es el nombre que se le da a un objeto direccionable que se puede direccionar sin hacer referencia a otro objeto direccionable. Los ejemplos familiares de PAO incluyen el nombre de un edificio o el número de una calle. Se otorga un objeto direccionable secundario (SAO) a cualquier objeto direccionable que se dirija por referencia a un PAO. Este podría ser el primer piso de un edificio con nombre.

Para darnos una visualización de esto, rápidamente invertí la ingeniería en una herramienta de modelado UML. Esto es lo que obtenemos:

Mi punto es que puede volverse bastante complicado y desordenado; el direccionamiento en algunos dominios puede ser muy complejo.

Si tuviera que aplanar esto en una sola tabla relacional, obtendría algo como lo siguiente:

Si bien esto captura los componentes de la dirección BS7666, no le dice cómo funciona el modelo. Toda la lógica relacional del esquema XML se oculta en la lógica de la aplicación.

Estos dos diagramas representan dos extremos de modelado de datos . Pero, ¿existe un camino intermedio para modelar direcciones?

De hecho, es posible tener un modelo de dirección relativamente simple que sea flexible y configurable.

Componentes de dirección

Un componente de dirección suele ser una línea en una etiqueta de dirección, o más bien un tipo de línea en una etiqueta de dirección. El tipo de componentes que normalmente usaríamos para las direcciones del Reino Unido se enumeran en la siguiente tabla:

Podría tener tres o cuatro líneas de dirección, además de la ciudad postal y el código postal. Sin embargo, la dificultad que encontrará es identificar qué contienen realmente estas líneas cuando importa, p. al mapear datos entre sistemas. Cuando realice perfiles de datos, encontrará que la línea de dirección 3 a veces contiene una localidad dependiente, pero otras veces contiene un condado o localidad. Ahora estás en el procesamiento del lenguaje natural (NLP); tienes que reconocer la diferencia entre localidad y provincia. Y las permutaciones se multiplican a medida que agrega más países.

Por lo tanto, debemos definir todos los componentes de dirección para todos los países en los que operamos.

Formatos de dirección

Los formatos de dirección se componen de dos partes:un encabezado y su detalle. El encabezado es básicamente el nombre o título que el formato de dirección es conocido por. Los ejemplos podrían incluir:

Tomando el formato completo de dirección de oficina de correos (PAF) del Reino Unido a modo de ejemplo, definimos los siguientes componentes de formato de dirección:

Nuestra aplicación lee estos metadatos y muestra los componentes de la dirección en el orden correcto. Cuando se requiere la captura de direcciones, los metadatos nos dicen si el componente de dirección es obligatorio o no.

Más a menudo, nuestra aplicación solicita el código postal del usuario final y busca los valores correspondientes y completa los componentes de la dirección automáticamente. Algunas aplicaciones permiten al usuario editar la dirección; ¡otros [molestos] no!

No se muestra en el PDM, pero si su organización opera internacionalmente, puede definir una relación de muchos a muchos entre address_format_type y country para que el formato de dirección correcto (basado en el país del usuario) se presente al usuario final (party ).

Cuándo y solo cuando el contact_point es una dirección postal contact_point_type , debe tener una relación con un address_format_type. Por el contrario, se deduce que los tipos de direcciones no postales nunca tener una relación con un address_format_type . Además, el formato debe permanecer fijo durante la vida del contact_point , de lo contrario, presentará la posibilidad de problemas de integridad de datos. (Para que esto no sea el caso , el objetivo address_format_components debe ser un subconjunto de la fuente address_format_components ).

La columna contact_value no tiene significado para una dirección postal porque los valores se almacenan en un ddress_line.line_content . Por el contrario, contact_value es obligatorio para todos los demás contact_point_types . Básicamente, contact_point.contact_value y address_line.line_content son mutuamente excluyentes.

La relación de muchos a muchos entre la parte y el punto de contacto

Puedes pensar en contact_point (más address_line ) que contiene los valores y party_contact como definir el uso. Esto permite un solo contact_point tener múltiples usos . Nuestra dirección [postal] de casa también podría ser nuestra dirección de facturación y de entrega, según el contexto.

Hasta ahora, la narrativa ha asumido que una parte posee un contact_point particular. . ¡Pero el modelo de datos no impone esta regla de propiedad! No hace tal restricción alguna. Existe otra posibilidad con este diseño:varias partes para los mismos puntos de contacto.

Debe considerar las implicaciones cuidadosamente antes de aventurarse por esta ruta.

Aquí hay un ejemplo. En el Reino Unido, las organizaciones de otorgamiento de premios (AO, por sus siglas en inglés) generalmente emplean a profesores como examinadores. Un docente tiene dos relaciones:una con la escuela donde trabaja y otra con el AO como examinador. La escuela tendrá un banco de contact_points con varios números de teléfono y posiblemente una o más direcciones postales. Estos serán cosas como la dirección principal de la escuela (dirección postal), el correo electrónico principal (dirección de correo electrónico), el fax principal (número de fax) y el teléfono principal (número de teléfono).

Es completamente factible que nuestro examinador pueda usar los mismos contact_points como su escuela, pero usará party_contact para definirlos como relacionados con el trabajo. Si el número de teléfono principal de la escuela cambia, el número de trabajo del maestro se actualizará automáticamente, lo cual es bastante bueno.

Si sigue esta ruta, deberá definir en el nivel de la aplicación qué parte o partes pueden actualizar contact_points .

Una palabra rápida sobre el rendimiento

Las tablas de metadatos amarillas van a ser utilizadas constantemente por las consultas. En consecuencia, es probable que permanezcan en la memoria. En la mayoría de los RDBMS, puede anclar tablas en la memoria para garantizar esto. En Oracle, las crearía como tablas organizadas por índices, que son pequeñas y funcionan bien. Haga lo que sea equivalente para su RDBMS.

También quiere asegurarse de que party_contact las filas se ubican en el mismo bloque (o página) usando un índice agrupado en party_id . Haz lo mismo con address_line.contact_point_id . Esto reduce la cantidad de IO.

Existe otra opción si quieres una party ser propietario exclusivo de un contact_point . Luego puede fusionar contact_point en party_contact para crear party_contact_point (aún agrupado en party_id ). Esto simplifica el modelo y podría mejorar el rendimiento.

Cambiar contactos no significa cambiar bases de datos

Vivimos en una época en la que se puede decir que el cambio es la única constante.

Eso no significa que cada vez que algo cambie tenga que afectar su base de datos. Con un poco de reflexión, podemos preparar nuestros diseños para el futuro, quizás más de lo que hemos hecho hasta la fecha. Hacerlo nos ayuda a responder rápidamente al cambio inevitable.

Si se está embarcando en un proyecto de campo nuevo, recomendaría usar el modelo de fiesta (del cual Contact Point es parte) para organizaciones y personas. ¿Por qué no abrir el modelo y ajustarlo a sus necesidades? Siéntase libre de obtener una copia y personalizarla.

Pero si su base de datos o bases de datos ya están determinadas, el esquema que he presentado aquí aún se puede usar, en formato XML, para definir su carga útil al integrar datos entre sistemas.