Znamená vývoj kontaktních informací změnu vaší databáze?

V dnešní době existuje řada způsobů, jak někoho kontaktovat, ne?

Máme různé telefony:mobilní i pevné, osobní i pracovní. Máme různé adresy – bydliště, poštovní, fakturační, obchodní atd. – a pravděpodobně také několik e-mailových adres. Nezapomeňte na Skype a různé aplikace pro zasílání zpráv. Nyní přidejte LinkedIn a Facebook – které mimochodem mají oba své vlastní prvky pro zasílání zpráv.

Není to tak dávno, co mnoho z nich neexistovalo. Takže můžete do značné míry zaručit, že za pár let budeme mít nový způsob kontaktování lidí a organizací.

Můžeme všechny tyto kontaktní údaje modelovat tak, abychom nemuseli měnit design naší databáze, když přijde „nejnovější věc“? Čtěte dále a dozvíte se…

Model kontaktního bodu strany

Jedním slovem ano. Databáze mohou být navrženy tak, aby obsahovaly informace, které ještě ani nemáme.

Skočím přímo do toho a ukážu vám řešení a poté popíšu, jak jednotlivé části spolupracují. Zavolám na různé způsoby kontaktování stran na kontaktní místa , i když jsem viděl kontaktní metody a dokonce kontaktní místa použité.

Fyzicky budou všechny tyto kontaktní body uloženy v jediném sloupci tabulky contact_point.contact_value . Vzpomeňte si na telefonní číslo, e-mailovou adresu nebo webovou adresu (URL) a pochopíte, proč je zde můžeme všechny uložit; jsou to jen řetězce (varchars) na této úrovni. Rozdíl je v metadatech. Jedinou výjimkou je poštovní adresa, která bude podrobněji popsána později.

Žluté tabulky nalevo obsahují metadata a modré tabulky napravo obsahují obchodní data.

Hlavní kategorie

Ačkoli máme mnoho způsobů, jak někoho kontaktovat, tyto způsoby ve skutečnosti spadají do malého počtu kategorií nebo typů. Uvidíte, co tím myslím, když se podíváte na seznam níže:

V jistém smyslu jsou fyzicky odlišné. Samozřejmostí je možnost volání z mobilního telefonu na pevnou linku nebo jiný mobil. Pokud jde o hlasové hovory mezi pevnými linkami a mobilními telefony, rozdíl není tak důležitý. Přesto je pravděpodobnější, že pošleme textovou zprávu (SMS) na mobil než na pevnou linku.

Není však pravděpodobné, že byste úmyslně zavolali na faxové číslo. Ostatně, co tomu řeknete, až to uslyšíte, kromě ‚Jejda, špatné číslo‘? Přirozeně je mnohem pravděpodobnější, že zavoláte s jiným faxem, ať už fyzickým nebo emulovaným. Neposílali byste ani dopis na pevnou linku, ani byste se nepokoušeli zavolat na poštovní adresu.

Je důležité, abychom tyto typy rozlišovali, protože s nimi interagujeme odlišně. To bude platit zejména v případě, že vaše aplikace má jakýkoli druh integrace s komunikačními službami. Potřebuje vědět, se kterým typem interagovat.

Jak strany využívají kontaktní místa

To je pravděpodobně trochu intuitivnější, trochu více v souladu s tím, jak přemýšlíme o typech kontaktů. Zde je delší seznam (ale ne vyčerpávající!), který vám pomůže získat představu o těchto typech:

Poštovní adresa – zvláštní případ

Všechny tyto typy kontaktních míst jsou uloženy v jediném poli, s výjimkou poštovní adresy. To obvykle vyžaduje určitý počet řádků (nebo polí).

Zde je článek na blogu, který navrhuje jednoduchý, jazykově agnostický způsob ukládání poštovních adres. Pokud jsou vaše požadavky spíše základní – např. tisknout adresní štítky v podstatě tak, jak jsou zadány do systému – tento přístup bude pravděpodobně stačit. Pokud jsou vaše potřeby sofistikovanější, budete pravděpodobně muset vyvinout jiné řešení.

Chcete-li získat představu o tom, jak složité může být adresování, podívejte se rychle na toto schéma pro britské standardní typy adres BS7666. Norma se skládá z řady částí, které zahrnují seznamy ulic, seznamy pozemků a nemovitostí a místa dodání. Nerozlišuje mezi komerčními nebo rezidenčními nemovitostmi; mezi okupovanou, zastavěnou nebo prázdnou půdou; mezi městskými a venkovskými oblastmi; nebo mezi entitami s poštovní adresou a entitou bez poštovní adresy s jako komunikační stožáry (věže). Aby toho bylo dosaženo, zavádí termíny, které většina z nás pravděpodobně nezná, jako je primární adresovatelný objekt (PAO), což je název přidělený adresovatelnému objektu, který lze adresovat bez odkazu na jiný adresovatelný objekt. Mezi známé příklady PAO patří název budovy nebo číslo ulice. Sekundární adresovatelný objekt (SAO) je dán jakémukoli adresovatelnému objektu, který je adresován odkazem na PAO. Toto může být první patro pojmenované budovy.

Abychom si to mohli představit, rychle jsem to převedl zpětně do modelovacího nástroje UML. Zde je to, co dostáváme:

Jde mi o to, že to může být pěkně komplikované a chaotické; adresování v některých doménách může být skutečně velmi složité.

Pokud byste to srovnali do jedné relační tabulky, dostali byste něco jako následující:

I když to zachycuje komponenty adresy BS7666, neříká vám, jak model funguje. Veškerá relační logika schématu XML je skryta v aplikační logice.

Tyto dva diagramy představují dva extrémy datového modelování . Existuje však střední cesta k modelování adres?

Je skutečně možné mít relativně jednoduchý model adresy, který je flexibilní a konfigurovatelný.

Součásti adresy

Komponenta adresy je obvykle řádek na štítku adresy, nebo spíše typ řádku na adresním štítku. Druhy komponent, které bychom obvykle používali pro adresy ve Spojeném království, jsou uvedeny v následující tabulce:

Můžete mít tři nebo čtyři řádky adresy plus PSČ a PSČ. Problém, se kterým se však setkáte, je určit, co tyto řádky skutečně obsahují když na tom záleží – např. při mapování dat mezi systémy. Když provádíte profilování dat, zjistíte, že řádek adresy 3 někdy obsahuje závislou lokalitu, ale jindy obsahuje okres nebo lokalitu. Nyní jste u zpracování přirozeného jazyka (NLP); musíte rozpoznat rozdíl mezi lokalitou a krajem. A permutace se násobí, když přidáváte další země.

Musíme tedy definovat všechny součásti adresy pro všechny země, ve kterých působíme.

Formáty adres

Formáty adres se skládají ze dvou částí:hlavičky a jejího detailu. Záhlaví je v podstatě jméno nebo titul, který má formát adresy je známý tím. Příklady mohou zahrnovat:

Vezmeme-li jako příklad britský Full Post Office Address Format (PAF), pak definujeme následující složky formátu adresy:

Naše aplikace čte tato metadata a zobrazuje komponenty adresy ve správném pořadí. Když je vyžadováno zachycení adresy, metadata nám řeknou, zda je komponent adresy povinný nebo ne.

Častěji si naše aplikace vyžádá od koncového uživatele PSČ a vyhledá odpovídající hodnoty a automaticky naplní komponenty adresy. Některé aplikace umožňují uživateli upravit adresu; ostatní [otravní] ne!

Nezobrazuje se v PDM, ale pokud vaše organizace působí mezinárodně, můžete definovat vztah mnoho k mnoha mezi address_format_type a country aby byl koncovému uživateli (party) předložen správný formát adresy (na základě země uživatele) ).

Kdy a jen když contact_point je poštovní adresa contact_point_type , musí mít vztah k typu_formátu_adresy. Naopak z toho vyplývá, že nepoštovní typy adres nikdy mít vztah k address_format_type . Kromě toho formát musí zůstat pevný po dobu životnosti contact_point , jinak zavedete možnost problémů s integritou dat. (Aby tomu tak nebylo , cílový address_format_components musí být podmnožinou zdroje address_format_components ).

Sloupec contact_value nemá pro poštovní adresu žádný význam, protože hodnoty jsou uloženy v ddress_line.line_content . A naopak contact_value je povinné pro všechny ostatní contact_point_types . V podstatě contact_point.contact_value a address_line.line_content se vzájemně vylučují.

Vztah mnoho k mnoha mezi stranou a kontaktním místem

Můžete si představit contact_point (plus address_line ) jako obsahující hodnoty a party_contact jako definování použití. To umožňuje jeden contact_point mít mnohonásobné použití . Naše domácí [poštovní] adresa může být také naší fakturační adresou a dodací adresou, v závislosti na kontextu.

Doposud vyprávění předpokládalo, že strana vlastní konkrétní contact_point . Datový model však toto pravidlo vlastnictví neukládá! Nečiní žádné takové omezení. S tímto designem existuje další možnost:více stran pro stejná kontaktní místa.

Než se vydáte touto cestou, musíte pečlivě zvážit důsledky.

Zde je příklad. Ve Spojeném království udělující organizace (AOs) obecně zaměstnávají učitele jako zkoušející. Učitel má dva vztahy:jeden se školou, kde pracuje, a druhý s AO jako zkoušející. Škola bude mít banku contact_points s různými telefonními čísly a případně jednou nebo více poštovními adresami. Budou to věci jako hlavní adresa školy (poštovní adresa), hlavní e-mail (e-mailová adresa), hlavní fax (faxové číslo) a hlavní telefon (telefonní číslo).

Je zcela možné, že náš zkoušející může používat stejné contact_points jako jeho nebo její škola, ale on nebo ona použije party_contact definovat je jako pracovní. Pokud se změní hlavní telefonní číslo školy, automaticky se aktualizuje i pracovní číslo učitele, což je docela úhledné.

Pokud se vydáte touto cestou, budete muset definovat na úrovni aplikace která strana nebo strany mohou aktualizovat contact_points .

Rychlé slovo o výkonu

Žluté tabulky metadat budou neustále používány dotazy. V důsledku toho pravděpodobně zůstanou v paměti. Na většině RDBMS můžete tabulky připnout do paměti, abyste to zajistili. V Oracle bych je vytvořil jako indexově organizované tabulky, které jsou malé a fungují dobře. Udělejte cokoli, co je ekvivalentní pro váš RDBMS.

Také se chcete ujistit, že party_contact řádky jsou umístěny ve stejném bloku (nebo stránce) pomocí seskupeného indexu na party_id . Udělejte totéž s address_line.contact_point_id . Tím se sníží množství IO.

Další možnost existuje, pokud chcete party k výhradnímu vlastnictví contact_point . Poté můžete sloučit contact_point do party_contact vytvořit party_contact_point (stále seskupené na party_id ). To zjednodušuje model a může zvýšit výkon.

Změna kontaktů neznamená změnu databází

Žijeme v době, kdy lze říci, že změna je jedinou konstantou.

To neznamená, že pokaždé, když se něco změní, musí to ovlivnit vaši databázi. S trochou přemýšlení můžeme naše návrhy prověřit do budoucna – možná více než doposud. Pomůže nám to rychle reagovat na nevyhnutelnou změnu.

Pokud se pouštíte do projektu na zelené louce, doporučoval bych organizacím a lidem využít Party Model (jehož součástí je Contact Point). Proč neotevřete model a nevyladíte jej podle svých potřeb? Neváhejte a pořiďte si kopii a vytvořte si vlastní.

Ale pokud jsou vaše databáze nebo databáze již určeny, schéma, které jsem zde uvedl, lze stále použít ve formě XML k definování vaší užitečné zátěže při integraci dat mezi systémy.