L'evoluzione delle informazioni di contatto significa cambiare il database?

Ci sono molti modi per contattare qualcuno in questi giorni, giusto?

Abbiamo vari telefoni:mobile e fisso, personale e di lavoro. Abbiamo indirizzi diversi (residenziale, postale, fatturazione, affari, ecc.) e probabilmente anche diversi indirizzi e-mail. Non dimenticare Skype e varie app di messaggistica. Ora aggiungi LinkedIn e Facebook, che tra l'altro hanno entrambi i propri elementi di messaggistica.

Non molto tempo fa, molti di questi non esistevano. Quindi puoi praticamente garantire che in pochi anni avremo un nuovo modo di contattare persone e organizzazioni.

Possiamo modellare tutte queste informazioni di contatto in modo tale da non dover modificare il design del nostro database quando arriva "l'ultima cosa"? Continua a leggere per scoprirlo...

Il modello del punto di contatto per le parti

In una parola, sì. I database possono essere progettati per ospitare informazioni che non abbiamo ancora.

Passo subito dentro e ti mostrerò la soluzione, quindi descriverò come i pezzi funzionano insieme. Chiamerò i vari modi per contattare le parti punti di contatto , anche se ho visto metodi di contatto e persino luoghi di contatto usato.

Fisicamente, tutti questi punti di contatto verranno archiviati in un'unica colonna della tabella, contact_point.contact_value . Pensa a un numero di telefono, un indirizzo e-mail o un indirizzo web (URL) e capirai perché possiamo archiviarli tutti qui; sono solo stringhe (varchar) a questo livello. La differenziazione è nei metadati. L'unica eccezione è l'indirizzo postale, che verrà descritto più dettagliatamente in seguito.

Le tabelle gialle a sinistra contengono metadati e le tabelle blu a destra contengono dati aziendali.

Le categorie principali

Sebbene abbiamo molti modi per contattare qualcuno, questi modi in realtà rientrano in un piccolo numero di categorie o tipi. Capirai cosa intendo quando guardi l'elenco qui sotto:

In un certo senso, questi sono fisicamente distinti. Naturalmente, puoi utilizzare un telefono cellulare per chiamare una linea fissa o un altro cellulare. Quando si tratta di chiamate vocali tra fissi e cellulari, la distinzione non è così importante. Tuttavia, è più probabile che inviamo un SMS (SMS) a un cellulare piuttosto che a una rete fissa.

Ma non è probabile che chiami deliberatamente un numero di fax. Dopotutto, cosa gli dirai quando lo sentirai, a parte "Oops, numero sbagliato"? È naturalmente molto più probabile che chiami con un altro apparecchio fax, fisico o emulato. Né invierai una lettera a rete fissa, né tenterai di effettuare una chiamata vocale a un indirizzo postale.

È importante distinguere questi tipi, perché interagiamo in modo diverso con loro. Ciò sarà particolarmente vero se la tua applicazione ha un qualsiasi tipo di integrazione con i servizi di comunicazione. Deve sapere con quale tipo interagire.

Come le parti utilizzano i punti di contatto

Questo è probabilmente un po' più intuitivo, un po' più in linea con il modo in cui pensiamo ai tipi di contatto. Ecco un elenco più lungo (ma non esaustivo!) che ti aiuterà a farti un'idea di questi tipi:

L'indirizzo postale:un caso speciale

Tutti questi tipi di punti di contatto sono memorizzati in un unico campo, ad eccezione di un indirizzo postale. Questo normalmente richiede un numero di righe (o campi).

C'è un articolo del blog qui che propone un modo semplice e indipendente dalla lingua per memorizzare gli indirizzi postali. Se i tuoi requisiti sono piuttosto basilari, ad es. stampare le etichette degli indirizzi non appena vengono immesse nel sistema:questo approccio sarà probabilmente sufficiente. Se le tue esigenze sono più sofisticate, probabilmente dovrai sviluppare una soluzione diversa.

Per avere un'idea di quanto possa essere complesso l'indirizzamento, dai una rapida occhiata a questo schema per i tipi di indirizzo British Standard BS7666. Lo standard comprende una serie di parti che coprono i dizionari geografici stradali, i dizionari geografici e immobiliari e i punti di consegna. Non distingue tra immobili commerciali o residenziali; tra terreno occupato, sviluppato o libero; tra aree urbane o rurali; o tra entità indirizzabili per posta e entità non indirizzabili per posta s come antenne di comunicazione (torri). Per ottenere ciò, introduce termini con cui la maggior parte di noi probabilmente non ha familiarità, come Primary Addressable Object (PAO), che è il nome dato a un oggetto indirizzabile che può essere indirizzato senza riferimento a un altro oggetto indirizzabile. Esempi familiari di PAO includono il nome di un edificio o un numero civico. Un oggetto indirizzabile secondario (SAO) viene assegnato a qualsiasi oggetto indirizzabile indirizzato in riferimento a un PAO. Questo potrebbe essere il primo piano di un edificio con nome.

Per darci una visualizzazione di questo, l'ho rapidamente reingegnerizzato in uno strumento di modellazione UML. Ecco cosa otteniamo:

Il mio punto è che può diventare piuttosto complicato e disordinato; l'indirizzamento in alcuni domini può essere davvero molto complesso.

Se dovessi appiattirlo in un'unica tabella relazionale, otterresti qualcosa di simile al seguente:

Sebbene questo acquisisca i componenti dell'indirizzo BS7666, non ti dice come funziona il modello. Tutta la logica relazionale dello schema XML viene nascosta nella logica dell'applicazione.

Questi due diagrammi rappresentano due estremo di modellazione dei dati . Ma esiste una via di mezzo per modellare gli indirizzi?

È infatti possibile avere un modello di indirizzo relativamente semplice, flessibile e configurabile.

Componenti dell'indirizzo

Un componente di indirizzo è in genere una riga su un'etichetta di indirizzo, o meglio un tipo di riga su un'etichetta di indirizzo. Il tipo di componenti che utilizzeremo in genere per gli indirizzi del Regno Unito sono elencati nella tabella seguente:

Potresti avere tre o quattro righe di indirizzo, più la città e il codice postale. Tuttavia, la difficoltà che incontrerai è identificare cosa contengono effettivamente queste righe quando è importante, ad es. durante la mappatura dei dati tra i sistemi. Quando si esegue la profilazione dei dati, si scoprirà che la riga di indirizzo 3 a volte contiene una località dipendente, ma altre volte contiene una contea o località. Ora sei nell'elaborazione del linguaggio naturale (NLP); devi riconoscere la differenza tra località e provincia. E le permutazioni si moltiplicano man mano che aggiungi altri paesi.

Quindi dobbiamo definire tutti i componenti dell'indirizzo per tutti i paesi in cui operiamo.

Formati indirizzi

I formati degli indirizzi sono costituiti da due parti:un'intestazione e il relativo dettaglio. L'intestazione è fondamentalmente il nome o il titolo del formato dell'indirizzo è conosciuto da. Gli esempi potrebbero includere:

Prendendo a titolo di esempio il Full Post Office Address Format (PAF) del Regno Unito, definiamo i seguenti componenti del formato dell'indirizzo:

La nostra applicazione legge questi metadati e visualizza i componenti dell'indirizzo nell'ordine corretto. Quando è richiesta l'acquisizione dell'indirizzo, i metadati ci dicono se il componente dell'indirizzo è obbligatorio o meno.

Più spesso, la nostra applicazione richiede il codice postale all'utente finale e cerca i valori corrispondenti e popola automaticamente i componenti dell'indirizzo. Alcune applicazioni consentono all'utente di modificare l'indirizzo; altri [fastidiosi] no!

Non viene mostrato nel PDM, ma se la tua organizzazione opera a livello internazionale, puoi definire una relazione molti-a-molti tra address_format_type e country in modo che il formato dell'indirizzo corretto (basato sul paese dell'utente) venga presentato all'utente finale (party ).

Quando e solo quando il contact_point è un indirizzo postale contact_point_type , deve avere una relazione con un address_format_type. Al contrario, ne consegue che l'indirizzo non postale digita mai avere una relazione con un address_format_type . Inoltre, il formato deve rimanere fisso per tutta la vita del contact_point , altrimenti introdurrai la possibilità di problemi di integrità dei dati. (Affinché questo non sia il caso , il target address_format_components deve essere un sottoinsieme dei address_format_components di origine ).

La colonna contact_value non ha significato per un indirizzo postale perché i valori sono memorizzati in address_line.line_content . Al contrario, contact_value è obbligatorio per tutti gli altri contact_point_types . Fondamentalmente, contact_point.contact_value e address_line.line_content si escludono a vicenda.

Il rapporto molti-a-molti tra la parte e il punto di contatto

Puoi pensare a contact_point (più address_line ) come contenente i valori e party_contact come definire l'uso. Ciò consente un unico contact_point avere più usi . Il nostro indirizzo [postale] di casa potrebbe anche essere il nostro indirizzo di fatturazione e l'indirizzo di consegna, a seconda del contesto.

Finora, la narrativa ha presupposto che una parte possieda un particolare contact_point . Ma il modello di dati non impone questa regola di proprietà! Non fa alcuna restrizione di sorta. C'è un'altra possibilità che esiste con questo design:più parti per gli stessi punti di contatto.

È necessario considerare attentamente le implicazioni prima di avventurarsi lungo questa strada.

Ecco un esempio. Nel Regno Unito, le Organizzazioni di aggiudicazione (AO) generalmente impiegano insegnanti come esaminatori. Un insegnante ha due rapporti:uno con la scuola in cui lavora e un altro con l'AO come esaminatore. La scuola avrà una banca di contact_points con vari numeri di telefono ed eventualmente uno o più indirizzi postali. Questi saranno cose come l'indirizzo principale della scuola (indirizzo postale), l'e-mail principale (indirizzo e-mail), il fax principale (numero di fax) e il telefono principale (numero di telefono).

È del tutto possibile che il nostro esaminatore possa utilizzare gli stessi contact_points come sua scuola, ma utilizzerà party_contact per definirli legati al lavoro. Se il numero di telefono principale della scuola cambia, il numero di lavoro dell'insegnante verrà aggiornato automaticamente, il che è abbastanza accurato.

Se segui questa strada, dovrai definire a livello di applicazione quale parte o parti sono autorizzate ad aggiornare contact_points .

Una breve parola sulle prestazioni

Le tabelle di metadati gialle verranno costantemente utilizzate dalle query. Di conseguenza, è probabile che rimangano nella memoria. Sulla maggior parte degli RDBMS, è possibile bloccare le tabelle in memoria per garantire ciò. In Oracle, li creerei come tabelle organizzate per indici, che sono piccole e funzionano bene. Fai qualunque cosa sia l'equivalente per il tuo RDBMS.

Vuoi anche assicurarti che party_contact le righe si trovano nello stesso blocco (o pagina) utilizzando un indice cluster su party_id . Fai lo stesso con address_line.contact_point_id . Ciò riduce la quantità di IO.

Esiste un'altra opzione se vuoi una party possedere esclusivamente un contact_point . Puoi quindi unire contact_point in party_contact per creare party_contact_point (ancora raggruppato su party_id ). Ciò semplifica il modello e potrebbe favorire le prestazioni.

Cambiare i contatti non significa cambiare i database

Viviamo in un'epoca in cui si può dire che il cambiamento è l'unica costante.

Ciò non significa che ogni volta che qualcosa cambia deve avere un impatto sul tuo database. Con un po' di riflessione, possiamo rendere i nostri progetti a prova di futuro, forse più di quanto abbiamo fatto fino ad oggi. Ciò ci aiuta a rispondere rapidamente all'inevitabile cambiamento.

Se stai intraprendendo un progetto green, consiglierei di utilizzare il Party Model (di cui Contact Point fa parte) per organizzazioni e persone. Perché non aprire il modello e modificarlo in base alle tue esigenze? Sentiti libero di prenderne una copia e farla tua.

Ma se il tuo database o i tuoi database sono già determinati, lo schema che ho presentato qui può ancora essere utilizzato, in formato XML, per definire il tuo carico utile durante l'integrazione dei dati tra i sistemi.