Betekent het evolueren van contactgegevens dat u uw database moet wijzigen?

Er zijn tegenwoordig een aantal manieren om contact met iemand op te nemen, toch?

We hebben verschillende telefoons:mobiel en vast, persoonlijk en zakelijk. We hebben verschillende adressen - privé, post, facturering, zakelijk, enz. - en waarschijnlijk ook meerdere e-mailadressen. Vergeet Skype en verschillende berichten-apps niet. Voeg nu LinkedIn en Facebook toe, die trouwens beide hun eigen berichtelementen hebben.

Nog niet zo lang geleden bestonden veel van deze niet. Je kunt er dus vrijwel zeker van zijn dat we over een paar jaar een nieuwe manier hebben om contact op te nemen met mensen en organisaties.

Kunnen we al deze contactgegevens zo modelleren dat we ons database-ontwerp niet hoeven te veranderen als 'het laatste nieuws' langskomt? Lees verder om erachter te komen...

Het model van het partijcontactpunt

In één woord, ja. Databases kunnen zo worden ontworpen dat ze informatie bevatten die we nog niet eens hebben.

Ik ga meteen naar binnen en laat je de oplossing zien, dan zal ik beschrijven hoe de stukjes samenwerken. Ik ga de verschillende manieren om contact op te nemen met partijen contactpunten . noemen , hoewel ik contactmethoden heb gezien en zelfs contactlocaties gebruikt.

Fysiek worden al deze contactpunten opgeslagen in een enkele tabelkolom, contact_point.contact_value . Denk aan een telefoonnummer, een e-mailadres of een webadres (URL) en je begrijpt waarom we ze hier allemaal kunnen opslaan; het zijn gewoon strings (varchars) op dit niveau. Het onderscheid zit in de metadata. De enige uitzondering hierop is het postadres, dat later in meer detail wordt beschreven.

De gele tabellen aan de linkerkant bevatten metadata en de blauwe tabellen aan de rechterkant bevatten bedrijfsgegevens.

De belangrijkste categorieën

Hoewel we veel manieren hebben om contact met iemand op te nemen, vallen deze manieren eigenlijk in een klein aantal categorieën of typen. Je zult zien wat ik bedoel als je naar de onderstaande lijst kijkt:

In zekere zin zijn deze fysiek verschillend. Uiteraard kunt u met een mobiele telefoon naar een vaste of een andere mobiele telefoon bellen. Als het gaat om spraakoproepen tussen vaste lijnen en mobiele telefoons, is het onderscheid niet zo belangrijk. Toch sturen we eerder een sms (sms) naar een mobiel dan naar een vaste lijn.

Maar het is niet waarschijnlijk dat u opzettelijk een faxnummer belt. Wat ga je er tenslotte tegen zeggen als je het hoort, behalve 'Oeps, verkeerd nummer'? Het is natuurlijk veel waarschijnlijker dat u met een ander faxapparaat belt, of het nu fysiek of geëmuleerd is. U zou ook geen brief naar een vaste lijn sturen of proberen een spraakoproep te doen naar een postadres.

Het is belangrijk dat we deze typen onderscheiden, omdat we er anders mee omgaan. Dit geldt met name als uw toepassing enige vorm van integratie met communicatiediensten heeft. Het moet weten met welk type het moet communiceren.

Hoe partijen contactpunten gebruiken

Dit is waarschijnlijk een beetje intuïtiever, een beetje meer in lijn met hoe we denken over contacttypes. Hier is een langere lijst (maar geen uitputtende!) die je zal helpen een idee te krijgen van deze typen:

Het postadres – een speciaal geval

Al deze typen contactpunten worden in één veld opgeslagen, met uitzondering van een postadres. Dit vereist normaal gesproken een aantal regels (of velden).

Er is hier een blogartikel dat een eenvoudige, taalonafhankelijke manier voorstelt om postadressen op te slaan. Als uw vereisten vrij eenvoudig zijn - b.v. om adreslabels af te drukken zoals ze in het systeem worden ingevoerd - deze aanpak zal waarschijnlijk voldoende zijn. Als uw behoeften geavanceerder zijn, zult u waarschijnlijk een andere oplossing moeten ontwikkelen.

Om een ​​idee te krijgen van hoe complex adressering kan zijn, kunt u dit Schema voor Britse standaard BS7666-adrestypes even bekijken. De standaard bestaat uit een aantal onderdelen die betrekking hebben op Straatgazetteers, Land- en Property Gazetteers en afleverpunten. Er wordt geen onderscheid gemaakt tussen commercieel of residentieel vastgoed; tussen bezette, bebouwde of braakliggende gronden; tussen stedelijke of landelijke gebieden; of tussen postadresseerbare entiteiten en niet-postadresseerbare entiteiten s zoals communicatiemasten (torens). Om dit te bereiken introduceert het termen die de meesten van ons waarschijnlijk niet kennen, zoals Primary Addressable Object (PAO), de naam die wordt gegeven aan een adresseerbaar object dat kan worden geadresseerd zonder verwijzing naar een ander adresseerbaar object. Bekende voorbeelden van PAO's zijn een gebouwnaam of een huisnummer. Een secundair adresseerbaar object (SAO) wordt gegeven aan elk adresseerbaar object dat wordt geadresseerd door verwijzing naar een PAO. Dit kan de eerste verdieping van een genoemd gebouw zijn.

Om ons hiervan een visualisatie te geven, heb ik het snel reverse-engineered tot een UML-modelleringstool. Dit is wat we krijgen:

Mijn punt is dat het behoorlijk ingewikkeld en rommelig kan worden; adressering in sommige domeinen kan inderdaad erg complex zijn.

Als je dit zou samenvatten in een enkele relationele tabel, zou je zoiets als het volgende krijgen:

Hoewel dit BS7666-adrescomponenten vastlegt, vertelt het u niet hoe het model werkt. Alle relationele logica van het XML-schema wordt verborgen in applicatielogica.

Deze twee diagrammen vertegenwoordigen twee extremen van gegevensmodellering . Maar is er een middenweg om adressen te modelleren?

Het is inderdaad mogelijk om een ​​relatief eenvoudig adresmodel te hebben dat flexibel en configureerbaar is.

Adrescomponenten

Een adrescomponent is meestal een regel op een adreslabel, of liever een type regel op een adresetiket. Het soort componenten dat we doorgaans gebruiken voor Britse adressen staan ​​vermeld in de volgende tabel:

U kunt drie of vier adresregels hebben, plus de plaats en postcode. De moeilijkheid die u echter zult tegenkomen, is het identificeren van wat deze regels eigenlijk bevatten wanneer het er toe doet - bijv. bij het in kaart brengen van gegevens tussen systemen. Wanneer u gegevensprofilering uitvoert, zult u merken dat adresregel 3 soms een afhankelijke plaats bevat, maar op andere momenten een provincie of plaats. Nu ben je bezig met natuurlijke taalverwerking (NLP); je moet het verschil herkennen tussen plaats en provincie. En de permutaties vermenigvuldigen zich naarmate je meer landen toevoegt.

We moeten dus alle adrescomponenten definiëren voor alle landen waarin we actief zijn.

Adresformaten

Adresformaten bestaan ​​uit twee delen:een koptekst en het detail ervan. De koptekst is in feite de naam of titel die het adresformaat staat bekend bij. Voorbeelden kunnen zijn:

Als we bijvoorbeeld het Full Post Office Address Format (PAF) van het VK nemen, definiëren we de volgende componenten van het adresformaat:

Onze applicatie leest deze metadata en toont de adrescomponenten in de juiste volgorde. Wanneer adresregistratie vereist is, vertellen de metadata ons of de adrescomponent verplicht is of niet.

Vaker vraagt ​​onze applicatie de postcode op bij de eindgebruiker en zoekt de bijbehorende waarden op en vult automatisch de adrescomponenten. Bij sommige toepassingen kan de gebruiker het adres bewerken; andere [vervelende] niet!

Het wordt niet weergegeven in de PDM, maar als uw organisatie internationaal opereert, kunt u een veel-op-veel-relatie definiëren tussen address_format_type en country zodat het juiste adresformaat (gebaseerd op het land van de gebruiker) wordt gepresenteerd aan de eindgebruiker (party ).

Wanneer en alleen wanneer het contact_point is een postadres contact_point_type , moet het een relatie hebben met een address_format_type. Omgekeerd volgt hier dat niet-postadrestypen nooit een relatie hebben met een address_format_type . Verder moet het formaat vast blijven voor de levensduur van het contact_point , anders introduceert u de mogelijkheid van problemen met gegevensintegriteit. (Hiervoor niet het geval , het doel address_format_components moet een subset zijn van de bron address_format_components ).

De kolom contact_value heeft geen betekenis voor een postadres omdat de waarden zijn opgeslagen in address_line.line_content . Omgekeerd, contact_value is verplicht voor alle andere contact_point_types . Kortom, contact_point.contact_value en address_line.line_content sluiten elkaar uit.

De veel-op-veel-relatie tussen partij en contactpunt

Je kunt denken aan contact_point (plus address_line ) met de waarden en party_contact als het definiëren van het gebruik. Dit maakt een enkel contact_point . mogelijk voor meerdere toepassingen . Ons thuis [post] adres kan ook ons ​​factuuradres en afleveradres zijn, afhankelijk van de context.

Tot dusverre ging het verhaal ervan uit dat een partij eigenaar is van een bepaald contact_point . Maar het datamodel legt deze eigendomsregel niet op! Het legt geen enkele beperking op. Er is nog een andere mogelijkheid met dit ontwerp:meerdere partijen voor dezelfde contactpunten.

U moet de implicaties zorgvuldig overwegen voordat u deze route bewandelt.

Hier is een voorbeeld. In het VK hebben Awarding Organizations (AO's) over het algemeen docenten in dienst als examinatoren. Een leraar heeft twee relaties:een met de school waar hij of zij werkt, en een andere met de AO als examinator. De school heeft een bank van contact_points met diverse telefoonnummers en eventueel een of meerdere postadressen. Dit zijn zaken als het hoofdadres van de school (postadres), hoofd-e-mailadres (e-mailadres), hoofdfax (faxnummer) en hoofdtelefoon (telefoonnummer).

Het is heel goed mogelijk dat onze examinator dezelfde contact_points kan gebruiken als zijn of haar school, maar hij of zij zal party_contact . gebruiken om ze als werkgerelateerd te definiëren. Als het hoofdtelefoonnummer van de school verandert, wordt het werknummer van de leraar automatisch bijgewerkt, wat best netjes is.

Als u deze route volgt, moet u op applicatieniveau . definiëren welke partij of partijen toestemming hebben om contact_points te updaten .

Een kort woord over prestaties

De gele metadatatabellen zullen constant door zoekopdrachten worden gebruikt. Bijgevolg zullen ze waarschijnlijk in het geheugen blijven. Op de meeste RDBMS'en kunt u tabellen in het geheugen vastzetten om dit te garanderen. In Oracle zou ik deze als index-georganiseerde tabellen maken, die klein zijn en goed presteren. Doe wat het equivalent is voor uw RDBMS.

U wilt er ook voor zorgen dat party_contact rijen bevinden zich samen in hetzelfde blok (of pagina) met behulp van een geclusterde index op party_id . Doe hetzelfde met address_line.contact_point_id . Dit vermindert de hoeveelheid IO.

Er is een andere optie als je een party . wilt exclusief eigenaar zijn van een contact_point . U kunt dan contact_point samenvoegen naar party_contact om party_contact_point te maken (nog steeds geclusterd op party_id ). Dit vereenvoudigt het model en kan de prestaties ten goede komen.

Contactpersonen wijzigen betekent niet dat databases worden gewijzigd

We leven in een tijd waarin kan worden gezegd dat verandering de enige constante is.

Dat betekent niet dat elke keer dat er iets verandert, dit gevolgen moet hebben voor uw database. Met een beetje nadenken kunnen we onze ontwerpen toekomstbestendig maken - misschien meer dan we tot nu toe hebben gedaan. Hierdoor kunnen we snel reageren op de onvermijdelijke verandering.

Als je aan een greenfield-project begint, raad ik je aan om het Partijmodel (waarvan Contactpunt een onderdeel is) voor organisaties en mensen te gebruiken. Waarom zou u het model niet openen en aanpassen aan uw behoeften? Neem gerust een kopie en maak er je eigen exemplaar van.

Maar als uw database of databases al zijn bepaald, kan het schema dat ik hier heb gepresenteerd nog steeds worden gebruikt, in XML-vorm, om uw payload te definiëren bij het integreren van gegevens tussen systemen.