🕍 🎐 ♏️ मेल पता मान्यता 🤗 ⛹️ ⚔️

मामला इस तथ्य से शुरू हुआ कि एक छोटी सी अंग्रेजी कंपनी ने अपने मौजूदा और संभावित ग्राहकों को उड़ाने भेजने का फैसला किया।

समस्या की खोज की गई थी: उन ग्राहकों का एक अलग आंतरिक डेटाबेस है जिन्होंने फोन करके ऑर्डर किए थे; वेब क्लाइंट का एक अलग डेटाबेस जिसने साइट पर ऑर्डर किए हैं; और विभिन्न मुखबिरों से "संभावित ग्राहकों" के कई डेटाबेस।

हजारों ग्राहक एक साथ कई डेटाबेस में मिल गए, या एक डेटाबेस में भी कई बार।

यदि एक ग्राहक जो पांच बार "रोशनी करता है" उसे एक नाम या पते की थोड़ी अलग वर्तनी के साथ पांच समान पत्रक मिलते हैं, तो इस तरह के अभियान का प्रभाव विपरीत होगा - अतिरिक्त पत्रक की व्यर्थ लागत का उल्लेख नहीं करना।

मेलिंग सूची में दोहराव को कैसे हटाएं?

सभी ग्राहक डेटा के बीच, सबसे स्पष्ट जो इसे परिभाषित करता है वह है पोस्टकोड। यह पर्याप्त नहीं है, लेकिन यह एक अच्छा प्रारंभिक बिंदु है।

डाक कोड

ब्रिटिश रॉयल मेल (रॉयल मेल) की अनुक्रमणिकाएं अधिकांश देशों के डाक कोड में स्वीकृत से काफी भिन्न हैं:

5 से 7 अक्षर लंबे, बीच में एक स्थान के साथ, अल्फ़ान्यूमेरिक इंडेक्स का उपयोग करता है - उदाहरण के लिए, प्रसिद्ध पता "221 बी बेकर स्ट्रीट, लंदन" के लिए NW1 6XE;
एक सूचकांक औसतन 15 प्राप्तकर्ताओं (वितरण बिंदु) से मेल खाता है - यह चौराहे से चौराहे तक सड़क के लगभग एक तरफ है;
जियोलोकेशन के लिए ज़िप कोड का व्यापक रूप से उपयोग किया जाता है, उदाहरण के लिए, Google मैप्स पर: maps.google.com/maps?q=NW1+6XE मैप को तुरंत वांछित तिमाही में रखता है; बड़े शहरों में, अभिविन्यास की सुविधा के लिए, डाक जिले में सड़क के नाम के साथ घरों पर हस्ताक्षर किए जाते हैं;
सूचकांक में एक पदानुक्रमित संरचना है: क्षेत्र (क्षेत्र; काउंटी का हिस्सा), जिला (जिला; शहर या शहर का हिस्सा), क्षेत्र, इकाई। हमारे उदाहरण में, NW क्षेत्र उत्तर-पश्चिमी लंदन से मेल खाता है, NW1 जिला वेस्टमिंस्टर का हिस्सा है और कैमडेन का हिस्सा है। कम घनी आबादी वाले क्षेत्र से एक उदाहरण: EX ( एक्सेटर ) क्षेत्र, डेवोनशायर के उत्तरी आधे हिस्से से मेल खाता है, और EX20 जिला उत्तरी टावन और ओकेहैम्पटन और उनके वातावरण के कुछ शहरों से मेल खाता है।
जैसा कि आप देख सकते हैं, क्षेत्रों में मेल प्राप्तकर्ताओं का टूटना किसी भी तरह से प्रशासनिक विभाजन के अनुरूप नहीं है: कई मेल क्षेत्र काउंटी की सीमाओं को पार करते हैं, और कुछ - इंग्लैंड की सीमाएं। एकमात्र शर्त जिसके द्वारा विभाजन किया गया था, प्रत्येक मेल क्षेत्र में प्राप्तकर्ताओं की लगभग समान संख्या थी।

प्रत्येक प्राप्तकर्ता को एक दो-वर्ण डीपीएस (डिलीवरी पॉइंट प्रत्यय) सौंपा गया है - सूचकांक के साथ, यह मेल को उस मेल को वितरित करता है जिस पर मेल भेजा जाता है। उदाहरण के लिए, शर्लक होम्स के घर में एक इनबॉक्स NW1 6XE 1F मिला।

सूचकांक का ऐसा "विस्तार" अमेरिकी जिप + 4 के समान है; अंतर यह है कि ब्रिटिश डीपीएस आम जनता के लिए विज्ञापित नहीं हैं, और अधिकांश निवासियों को यह पता नहीं है कि डीपीएस क्या है, और इससे भी अधिक डीपीएस उनके मेलबॉक्स में क्या है।

डीपीएस का एकमात्र विज्ञापित उपयोग बड़े पैमाने पर मेलिंग के लिए शुल्क कम कर दिया जाता है, जब एक सूचकांक और डीपीएस सहित प्रत्येक लिफाफे पर एक बारकोड मुद्रित किया जाता है।

हमने तय किया कि "इंड्स + डीपीएस" जोड़ी हमें पते के लिए एक विशिष्ट पहचानकर्ता के रूप में सूट करती है: हालांकि सैद्धांतिक रूप से कई ग्राहकों के पास एक आम मेलबॉक्स हो सकता है (मान लीजिए कि वे आधा अपार्टमेंट किराए पर लेते हैं), और बड़े ग्राहकों के पास कई इमारतें और प्रत्येक में एक अलग मेलबॉक्स हो सकता है मामला - लेकिन "एक मेलबॉक्स - एक पत्रक" का सिद्धांत इसकी पारदर्शिता के साथ है।

एक कार्य योजना को परिभाषित किया गया था: प्रत्येक पते के लिए हम डीपीएस को परिभाषित करते हैं, और यदि दो रिकॉर्ड सूचकांक और डीपीएस में मेल खाते हैं, तो यह एक ही पता है।

डाक पते

कठोर रूप से संरचित सोवियत डाक पते "शहर-गली-घर-अपार्टमेंट" के आदी हैं, यह स्पष्ट नहीं हो सकता है: डीपीएस से परेशान क्यों? सीधे पतों में डुप्लिकेट की तलाश क्यों न करें?

तथ्य यह है कि ब्रिटिश डाक पते की एक बहुत ही ढीली संरचना है, जिससे उन्हें "हेड-ऑन" की तुलना करना असंभव है:

एक घर में कई कमरे हो सकते हैं (उदाहरण के लिए, 15-17 रेलवे रोड); एक कमरा नहीं हो सकता है (उदाहरण के लिए, सफारी हाउस, अस्पताल लेन);
पते में सड़क का संकेत नहीं दिया जा सकता है - केवल भवन और निपटान; उदाहरण के लिए, पूर्व सेंट मैरी चर्च, ट्रेमडॉग;
एक सड़क और एक "साइड स्ट्रीट" नामित किया जा सकता है, उदाहरण के लिए, "दूसरी ड्राइव, डावलिश रोड, टेग्नमाउथ" - इसके विपरीत, "सेकंड ड्राइव, लैंड्सकोर रोड, टेग्नमाउथ" भी है;
शहर के क्षेत्र का संकेत हो सकता है; विभिन्न क्षेत्रों में एक ही नाम से सड़कें हो सकती हैं। चूंकि जिलों के बीच कोई स्पष्ट सीमाएं नहीं हैं, इसलिए हर कोई अपने विवेक से चुनता है कि उसके पते पर किस जिले में संकेत दिया जाए, और क्या संकेत दिया जाए।
डाकघर यह सलाह नहीं देता है कि काउंटी को पते में इंगित किया जाए, लेकिन अधिकांश अभी भी संकेत देते हैं। चूंकि बड़े शहर काउंटियों के अधीनस्थ नहीं हैं, इसलिए कुछ निवासी दो बार शहर के नाम का संकेत देते हैं: एक बार एक निपटान के रूप में, दूसरी बार एक काउंटी के रूप में।
लंदन के साथ विशेष भ्रम: इसे "इनर लंदन, लंदन" के रूप में भी जाना जा सकता है; और "लंदन, दक्षिण लंदन" के रूप में; और कई अन्य तरीकों से - इस तथ्य के बावजूद कि डाक की आवश्यकताओं के लिए, राजधानी के अधिकांश निवासी लंदन को लिखते हैं और होम्स के घर के उदाहरण के रूप में सड़क को इंगित करते हैं।

सहमत हूँ कि स्वचालित रूप से "221B बेकर स्ट्रीट, लंदन NW1 6XE" और "शर्लक होम्स संग्रहालय, बेकर सेंट, वेस्टमिंस्टर, ग्रेटर लंदन NW1 6XE" की पहचान को निर्धारित करना एक असंभव कार्य है। लेकिन उसी घर को "मल्टी-होम" पते के हिस्से के रूप में इंगित किया जा सकता है, उदाहरण के लिए 219-221B

पोस्टल बेस

रॉयल मेल आधिकारिक तौर पर (और सस्ते में नहीं) सभी मौजूदा मेल पतों का एक डेटाबेस प्रदान करता है - पोस्टकोड एड्रेस फाइल (पीएएफ)। प्रत्येक पते के लिए एक "मानक" वर्तनी, सूचकांक और डीपीएस है। (एक पते पर डीपीएस निर्धारित करने के लिए पीएएफ खरीदना एकमात्र कानूनी तरीका है।) एक संग्रहीत पेंटटेक्स्ट के रूप में, पूरे डेटाबेस को 300 एमबी लेता है।

पते की "मानक" वर्तनी को तार्किक क्षेत्रों में विभाजित किया गया है: संगठन का नाम, घर, सड़क, निपटान।

इन क्षेत्रों में से प्रत्येक को और अधिक विभाजित किया गया है: संगठन के नाम में विभाग का नाम शामिल हो सकता है; घर का नाम - अपार्टमेंट नंबर या नाम; और इसी तरह।

उदाहरण के लिए, यहां पीएएफ से तीन प्रविष्टियां हैं, जो एक ही सड़क पर पतों से संबंधित हैं:

विभाग संगठन			Microwhite
घर का हिस्सा घर का नंबर घर का नाम	फ्लैट 3 वेस्टवुड फार्म हाउस	समतल 16	76A
उप का नाम कुशन का प्रकार गली का नाम सड़क का प्रकार	मुख्य सड़क	मुख्य सड़क	मुख्य सड़क
तहसील जिला / उपनगर शहर	Keevil Trowbridge	Keevil Trowbridge	Keevil Trowbridge
सूची डीपीएस	BA14 6LU 2P	BA14 6LU 2W	BA14 6ND 1J

यह उदाहरण आगे पोस्टल कोड के पदानुक्रम को दिखाता है: बीए डाक क्षेत्र में बाथर्स शहर और समरसेट और विल्टशायर के काउंटी का हिस्सा शामिल है; BA14 काउंटी - Trowbridge और आसपास के शहर; सेक्टर BA14 6 - किवील सहित ट्रॉब्रिज के पूर्व में एक दर्जन गाँव।

पता पहचान

इसलिए, हमारे पास एक इंडेक्स के साथ एक क्लाइंट पता है, और हमें इसका डीपीएस निर्धारित करने की आवश्यकता है। ललाट दृष्टिकोण - किसी दिए गए अनुक्रमणिका के अनुरूप सभी पतों को सूचीबद्ध करना और "झूठी सकारात्मक" की अनिवार्यता के कारण "सबसे समान" - को अस्वीकार कर दिया गया। एक सूचकांक से संबंधित पते सबसे अधिक घर की संख्या या नाम से भिन्न होते हैं; और यह ठीक उसी पते का हिस्सा है जिसमें वैकल्पिक रूप एक दूसरे के साथ कम हो सकते हैं। इसके अलावा, इस बात की कोई गारंटी नहीं है कि डेटाबेस में सूचकांक सही ढंग से लिखा गया है।

इसके बजाय, मैंने पते को एक डाकिया के रूप में पढ़ने के तर्क को दोहराते हुए, नीचे से ऊपर तक के पते का विश्लेषण करने का फैसला किया: पहले शहर, फिर सड़क, अंत में घर को पहचानें, और अंत में रिकॉर्ड किए गए के साथ सूचकांक की तुलना करें। यदि अनुक्रमणिका मेल खाती है, तो यह बहुत ठोस सबूत है कि पता सही ढंग से पहचाना गया है।

ग्राहक डेटाबेस में प्रारंभिक डेटा चार क्षेत्रों में भरे गए थे: पता, शहर, काउंटी और ज़िप कोड। चूंकि पूरा पता मैन्युअल रूप से इन चार क्षेत्रों में टूट गया था, इसलिए फ़ील्ड के उद्देश्य के लिए सामग्री का पत्राचार गलत नहीं था; "काउंटी" फ़ील्ड में शहर के नाम को विस्थापित करते हुए, लंबे पते अक्सर पहले दो क्षेत्रों में भरे जाते थे; छोटे पते - इसके विपरीत, उन्हें पहले क्षेत्र में शहर के साथ एक साथ संकेत दिया गया था, जबकि काउंटी "शहर" क्षेत्र में गिर गया, और "काउंटी" क्षेत्र खाली रह गया। इन सभी ने पतों को पहचानने में कठिनाइयों का कारण बनाया: यह स्पष्ट नहीं है कि पते की किस हिस्से की तुलना शहरों की सूची से की गई है, कौन सा हिस्सा गलियों की सूची के साथ है, आदि।

एक अन्य कठिनाई में कई टाइपो और विसंगतियों के पते शामिल थे। (ब्रिटिश स्थान के नाम कई में भयानक हैं: "लिवरपूल लिखा गया है, और मैनचेस्टर पढ़ा जाता है"; यह एक गलती के बिना कान से पते को रिकॉर्ड करना संभव है।) इसे ध्यान में रखना, फजी स्ट्रिंग तुलना के लिए एक एल्गोरिथ्म की आवश्यकता थी। Google ने मुझे यूनिवर्सिटी ऑफ़ शेफील्ड द्वारा जारी MS SQL के लिए SimMetrics लाइब्रेरी में ले गया। वास्तविक पते के उदाहरणों के साथ कई मीट्रिक आज़माने के बाद, मैंने जारो-विंकलर मीट्रिक का विकल्प चुना। यह लेवेंशेटिन दूरी के अपने विचार के समान है, लेकिन अंत में लाइनों की शुरुआत में पात्रों को अधिक वजन देता है। यह पता चला कि अधिकांश टाइपोस को वास्तव में नाम के दूसरे भाग में अनुमति दी गई थी; नामों के पहले दो अक्षरों में व्यावहारिक रूप से कोई टाइपोस नहीं थे।

मेरे पहचानकर्ता की सामान्य वास्तुकला सारणीबद्ध यूडीएफ कार्यों का एक झरना है, जिनमें से प्रत्येक पता के अंत से एक टुकड़ा "काटता है", इसे पहचानने की कोशिश करता है, और इनपुट लाइनों को फ़िल्टर करता है या उन्हें पार्स करने के लिए नए विकल्प जोड़ता है। पहला फ़ंक्शन सभी उपयुक्त काउंटियों पर विचार करता है, दूसरा - इन काउंटियों में सभी उपयुक्त शहरों, और इसी तरह। यह पता चला है कि मान्यता के दौरान आंशिक रूप से पढ़े गए पते की सभी (हजारों) संभावित व्याख्याओं पर विचार किया जाता है। शायद "शाखा-और-बाउंड विधि" जैसी किसी चीज़ का उपयोग करना अधिक कुशल होगा: हर बार केवल सबसे संभावित आंशिक व्याख्या पर विचार करने के लिए, और जैसे ही उपयुक्त पूर्ण व्याख्या मिलती है, विश्लेषण को रोक दें। मैंने फैसला किया कि इस तरह के कार्यान्वयन टी-एसक्यूएल की "भावना" को पूरा नहीं करेंगे, डेटा सरणियों के समान प्रसंस्करण की ओर उन्मुख; इसके अलावा, स्वतंत्र कार्यों का एक झरना कोड का परीक्षण और पुन: उपयोग करना आसान बनाता है।

काउंटी मान्यता

तो, हम काउंटी के नाम के साथ, पते के अंत से शुरू करते हैं। डाक नियमों के अनुसार, पते में काउंटी का संकेत वैकल्पिक है, और पते की पहचान करते समय इसे अनदेखा किया जा सकता है। हम "काउंटी" क्षेत्र में काउंटी के नाम की तलाश कर रहे हैं, अगर हमें यह मिल जाए, तो हम काट लेते हैं और शेष को वापस कर देते हैं। यदि हम इसे नहीं पाते हैं, तो दो विकल्प संभव हैं: या तो काउंटी को संकेत नहीं दिया गया है, और आपको शेष के रूप में पूरी लाइन वापस करने की आवश्यकता है ताकि अगला फ़ंक्शन इसमें शहर का नाम ढूंढ सके; या गैर-विद्यमान काउंटी के नाम से संकेत मिलता है (मैं "दक्षिण बकिंघमशायर", "सेंट्रल लंदन" और यहां तक कि "इंग्लैंड") से मिला, और फिर आपको पूरी लाइन काटने की आवश्यकता है - हम अगले शहर की तलाश करेंगे।

अतिरिक्त सूक्ष्मता के एक जोड़े - जो काउंटी के पूर्ण और संक्षिप्त नाम दोनों को पूरा कर सकते हैं; और अगर शहर शहर के नाम से मेल खाता है, तो इसे काटने की आवश्यकता नहीं है - हमें दूसरे चरण में इस शहर की आवश्यकता होगी।

CREATE FUNCTION Address_GetCounty(@address varchar(30)) RETURNS TABLE AS RETURN select distinct county, isnull(data.leftover, deflt.leftover) leftover, sim from ( select max(county) county, max(leftover) leftover, max(sim) sim from ( select top 1 county, leftover, sim from ( select county, leftover, length, sim, row_number() over (partition by county order by sim desc) as rn from ( select county.name as county, left(@address,len(@address)-lv) as leftover, lv as length, dbo.maxf(dbo.JaroWinkler(county.name,upper(right(@address,lv))), dbo.JaroWinkler(upper(county.abbrev),upper(right(@address,lv)))) as sim from PAF.dbo.Counties_ExceptPosttowns county, dbo.Generate(len(@address)) l where left(right(@address,lv),1) like '[A-Za-z]' --word boundary and (left(right(@address,l.v+1),1) not like '[A-Za-z]' or lv=len(@address)) ) data ) data where rn=1 and sim > 0.92 order by length desc, sim desc union select null, null, null ) data ) data, (select @address leftover union select '') deflt

जनरेट (एन) फ़ंक्शन 1 से एन तक प्राकृतिक संख्या देता है; शायद MS SQL के आधुनिक संस्करणों में इस तरह की तालिका बनाने के लिए पहले से ही एक अंतर्निहित तरीका है।

नमूने के लिए स्ट्रिंग की समानता के लिए 0.92 की दहलीज को आनुभविक रूप से चुना गया था। यह महत्वपूर्ण है कि सबसे "बिल्कुल उपयुक्त" विकल्प नहीं चुना जाता है, लेकिन सभी "सबसे उपयुक्त" वाले सबसे लंबे हैं। उदाहरण के लिए, लाइन "सौथ ग्लॉस्टरशायर" की पूंछ "ग्लॉस्टरशायर" पैटर्न से बिल्कुल मेल खाती है, लेकिन हमें इसे काटने की जरूरत नहीं है, लेकिन पैटर्न के लिए एक लंबा और कम सटीक मैच - "दक्षिण ग्लूस्टरशायर"।

शहर की मान्यता

दूसरा चरण "शहर" क्षेत्र में शहर की मान्यता है और "काउंटी" क्षेत्र की अपरिचित शेष है। चूंकि ब्रिटेन में हज़ारों शहर हैं, प्रत्येक शहर के नाम के साथ प्रत्येक टेल लाइन की एक फजी तुलना में अनुचित रूप से लंबा समय लगता है। खोज को अनुकूलित करने के लिए, हम पहले एक सटीक मिलान (इंडेक्स का उपयोग करके) खोजने की कोशिश करते हैं, और केवल तभी जब कोई सटीक मिलान नहीं होता है, हम एक फजी खोज करते हैं। इस दृष्टिकोण के लिए एक खामी है - सौथ ग्लॉस्टरशायर जैसे मामलों में, एक सटीक मैच मिल जाएगा, बजाय एक लंबे समय तक, गलत मैच।

कुछ और सूक्ष्मताएँ: यह पता चल सकता है कि काउंटी को दो बार (उदाहरण के लिए, "वेस्ट यॉर्कशायर, यॉर्कशायर") के रूप में इंगित किया गया है - यह तब हुआ जब पता छोटा है, और इसमें प्रवेश करने वाला व्यक्ति सभी लाइनों को भरना चाहता था। इसलिए, पता मान्यता इस तथ्य से शुरू होती है कि हम काउंटी के लिए किसी अन्य नाम को काटने की कोशिश कर रहे हैं, अगर यह नमूने से बिल्कुल मेल खाता है। एक और सूक्ष्मता - "पोस्टल शहरों" की आधिकारिक सूची के अलावा, "छद्म शब्द" को पते में अनुमति दी जाती है; रॉयल मेल उन्हें अलग अलियास डेटाबेस में प्रकाशित करता है, जिसे पीएएफ के अलावा खरीदा जा सकता है। (उदाहरण के लिए, "बेकर स्ट्रीट, लंदन" के मानक रूप के बजाय "बेकर स्ट्रीट, वेस्टमिंस्टर" लिखना अनुमत है। अंत में, जब एक चरित्र के लिए शहर के नामों की तुलना करते हैं, तो हम एक स्थान और एक हाइफ़न पर विचार करते हैं: समान संभावना वाला एक अंग्रेज "ब्रैडफोर्ड ऑन एवन" या "ब्रैडफोर्ड-" लिखेगा। ऑन-एवन ”, लेकिन केवल एक वर्तनी को आदर्श माना जाता है।

 CREATE FUNCTION Address_GetPosttownId(@address varchar(60)) RETURNS @res TABLE(local_id int, posttown varchar(30), leftover varchar(60), sim float, byalias bit) AS BEGIN --chip away double county, on a very good match SELECT @address=leftover FROM Address_GetCounty(@address) WHERE sim>0.95; INSERT INTO @res select distinct isnull(Localities.local_id,alias.local_id) as local_id, name.posttown, leftover, sim, byalias from ( select top 1 posttown, left(@address,len(@address)-lv) as leftover, 1 as sim, byalias from (select 0 as byalias, posttown from PAF.dbo.Localities union select 1 as byalias, name from PAF.dbo.LocalityIndex) names, dbo.Generate(len(@address)) l where left(right(@address,lv),1) like '[A-Za-z]' --word boundary and (left(right(@address,l.v+1),1) not like '[A-Za-z]' or lv=len(@address)) and posttown=upper(right(@address,lv)) order by lv /*length*/ desc ) name left join PAF.dbo.Localities on name.posttown=Localities.posttown left join PAF.dbo.LocalityAliases alias on name.posttown=alias.name IF @@rowcount!=0 RETURN; INSERT INTO @res select distinct isnull(Localities.local_id,alias.local_id) as local_id, name.posttown, leftover, sim, byalias from ( select top 1 posttown, leftover, sim, byalias from ( select posttown, leftover, length, sim, byalias, row_number() over (partition by posttown order by sim desc) as rn from ( select posttown, left(@address,len(@address)-lv) as leftover, lv as length, 0 as byalias, dbo.JaroWinkler(replace(posttown,'-',' '),replace(upper(right(@address,lv)),'-',' ')) as sim from (select 0 as byalias, posttown from PAF.dbo.Localities union select 1 as byalias, name from PAF.dbo.LocalityIndex) names, dbo.Generate(len(@address)) l where left(right(@address,lv),1) like '[A-Za-z]' --word boundary and (left(right(@address,l.v+1),1) not like '[A-Za-z]' or lv=len(@address)) ) data ) data where rn=1 and sim > 0.92 order by length desc, sim desc ) name left join PAF.dbo.Localities on name.posttown=Localities.posttown left join PAF.dbo.LocalityAliases alias on name.posttown=alias.name RETURN END

अगली समस्या जो मुझे मिली, वह यह थी कि कुछ पतों में दो डाक शहरों को एक साथ इंगित किया गया था: एक छोटा और एक बड़ा; - हालांकि दोनों का अपना-अपना जिला था: उदाहरण के लिए, "हेसल, हल"। (हेसल एचयू 13 जिले से संबंधित है, और हल एचयू 1 से एचयू 12 तक के जिलों से संबंधित है।) इन मामलों में, दूसरे शहर को बस अनदेखा किया जाना चाहिए।

कभी-कभी डाक शहर को पते पर संकेत नहीं दिया गया था: केवल जिले का नाम। फिर हम शेष पूरे प्रेषित पते के रूप में लौटते हैं।

 CREATE FUNCTION dbo.Address_GetPosttownId_2(@address varchar(160), @town varchar(60)) RETURNS @res TABLE(local_id int, posttown varchar(30), leftover varchar(160), sim float, byalias bit) AS BEGIN insert into @res select local_id, posttown, @address+' '+leftover, sim, byalias from Address_GetPosttownId(@town); -- multiple posttowns in address? insert into @res select distinct local_id, posttown, new.leftover, sim*.95, byalias from (select distinct leftover from @res) lo cross apply Address_GetPosttownId(dbo.rtrimna(leftover)) new -- also try without a posttown (rare) INSERT INTO @res VALUES(null, null, @address+' '+@town, .8, 0) RETURN END

"पता" क्षेत्र में जिले / उपनगर के नाम की खोज और "शहर" क्षेत्र के शेष बस्ती की मान्यता को पूरा करता है। वहां का कोड काफी लंबा निकला, इसलिए मैं केवल इसके तर्क को याद करूंगा। यदि डाक शहर अभी भी अज्ञात है, तो पूरे आधार में एक उपयुक्त क्षेत्र की खोज करने का प्रयास करें; यदि ज्ञात हो, तो केवल इस शहर के जिलों के बीच। यदि शहर एक छद्म नाम से पाया जाता है, या उसके पास नामहीन क्षेत्र हैं, तो क्षेत्र का नाम खाली हो सकता है: हम शेष के रूप में प्राप्त पूरे पते को वापस कर देते हैं। पहले की तरह, पतों में अक्सर होने वाली अशुद्धि को दूर करना आवश्यक था - उस क्षेत्र के नाम का एक संकेत जहां इसे डाक नियमों द्वारा इंगित करना आवश्यक नहीं है। इसलिए, यदि नामहीन जिलों वाला शहर स्थानांतरित किया जाता है, और पते की पूंछ उसके नाम वाले जिलों में से एक के समान है, तो हम पते से जिले का नाम काटते हैं, लेकिन नामांकित व्यक्ति के पहचानकर्ता को वापस करते हैं। मैं मानता हूं कि मेरा कोड पूरी तरह से सबरैस के नामों की उपेक्षा करता है: वास्तविक पते में वे काफी दुर्लभ हैं।

सड़क की पहचान

अगला कदम सड़क की मान्यता है। हम पाए गए बस्ती की सभी सड़कों को देख रहे हैं, पहले पते के शेष हिस्से की पूंछ से मेल खाते हैं, फिर - लगभग मिलान करते हैं। यदि यह लगभग एक ही समान खोजने के लिए संभव नहीं था, और खोज एक अनाम क्षेत्र में की गई थी, तो हम एक ही शहर के सभी क्षेत्रों में खोज करने का प्रयास करेंगे: यह संभव है कि पता उस क्षेत्र को इंगित करने के लिए भूल गया था जिसे डाक नियमों द्वारा आवश्यक है। यदि किसी जिले में समान सड़क नहीं मिली, तो हम पूरी तरह से आत्मसमर्पण करने से पहले एक और संभावना की जांच करेंगे: चयनित क्षेत्र में सड़क के बिना पते हो सकते हैं। इस तरह के पते काफी दुर्लभ हैं, इसलिए हम उन्हें अंतिम जांचते हैं। हम एलियास डेटाबेस से सड़क के एलियास की बिल्कुल भी जांच नहीं करते हैं: वे और भी दुर्लभ हैं।

 CREATE FUNCTION Address_GetThoroughfare (@local_id int, @address varchar(160)) RETURNS @res TABLE(local_id int, thfare varchar(30), thfare_id int, thdesc_id int, leftover varchar(160), sim float) AS BEGIN INSERT INTO @res select top 1 @local_id, thfare, thfare_id, thdesc_id, leftover, 1 from ( select distinct thfare, thfare_id, thdesc_id, left(@address,len(@address)-lv) as leftover, lv as length from PAF.dbo.ThoroughfareIndex, dbo.Generate(len(@address)) l where left(right(@address,lv),1) like '[0-9A-Za-z]' --word boundary and (left(right(@address,l.v+1),1) not like '[0-9A-Za-z]' or lv=len(@address)) and local_id=@local_id and thfare=upper(right(@address,lv)) ) data order by length desc; IF @@rowcount!=0 RETURN; INSERT INTO @res select top 1 @local_id, thfare, thfare_id, thdesc_id, leftover, sim from ( select thfare, thfare_id, thdesc_id, leftover, length, sim, row_number() over (partition by thfare order by sim desc) as rn from ( select distinct thfare, thfare_id, thdesc_id, left(@address,len(@address)-lv) as leftover, lv as length, dbo.JaroWinkler(thfare,upper(right(@address,lv))) as sim from PAF.dbo.ThoroughfareIndex, dbo.Generate(len(@address)) l where left(right(@address,lv),1) like '[0-9A-Za-z]' --word boundary and (left(right(@address,l.v+1),1) not like '[0-9A-Za-z]' or lv=len(@address)) and local_id=@local_id ) data ) data where rn=1 and sim > 0.92 order by length desc, sim desc; IF @@rowcount!=0 RETURN; --try dependents INSERT INTO @res select dep.local_id, thfare, thfare_id, thdesc_id, leftover, sim from PAF.dbo.Localities parent join PAF.dbo.Localities dep on parent.posttown=dep.posttown and dep.dependent1 is not null cross apply Address_GetThoroughfare(dep.local_id, @address) where parent.local_id=@local_id and parent.dependent1 is null IF @@rowcount!=0 RETURN; --still no luck? if exists (select 1 from PAF.dbo.Addresses_ByThoroughfare(@local_id, null, null)) INSERT INTO @res VALUES (@local_id, null, null, null, @address, .8); RETURN END

फिर, इसी तरह, केवल अन्य क्षेत्रों में खोज के बिना, हम उप-सड़क को पहचानने की कोशिश करते हैं। अधिकांश पतों को पीटा ट्रैक से दूर किया जाता है, इसलिए अब हमेशा नामहीन विकल्प पर विचार किया जाता है, और अंतिम नहीं। फ़ंक्शन कोड Address_GetThoroughfare_d dependent मैं नहीं देता।

Jaro-Winkler मीट्रिक का उपयोग करने से एक महत्वपूर्ण अतिरिक्त बोनस यह है कि आपको सड़क के प्रकार के नामों (Rd = Road, Ln = Lane, Ct = Court, आदि) के लिए संक्षिप्त सूची बनाने की आवश्यकता नहीं है: चयनित मैट्रिक बहुत कमजोर हो जाता है जब अक्षर गायब होते हैं नाम के बहुत अंत में।

प्राप्तकर्ता की मान्यता

अंतिम चरण मेल प्राप्तकर्ता की मान्यता है, वांछित डीपीएस सहित, शेष "पते" फ़ील्ड में। अधिकांश कंपनियों के लिए, कंपनी का नाम डाक पते का एक आवश्यक तत्व है, इसलिए अब इसे पते पर जोड़ें। गंतव्य मान्यता तर्क पूरे कोड में सबसे भ्रमित करने वाला हिस्सा है। सबसे पहले, हम प्राप्त पते से "द" शब्दों को मिटा देते हैं: पीएएफ में घरों और कंपनियों के नाम और वास्तविक पते में उनकी व्यवस्था में अंतर सबसे आम विसंगति है। हम घरों के नामों के साथ-साथ उनके हिस्सों के बीच पते की पूंछ को खोजने का प्रयास करते हैं: यदि "15-17 रेलवे रोड" पते को PAF में परिभाषित किया गया है, तो हम पूंछ की तुलना "15-17", "15", "17" के साथ करेंगे। घरों के नामों के साथ तुलना करते समय, हम प्रारंभिक "फ्लैट" को भी छोड़ देते हैं: पीएएफ में यह आमतौर पर अपार्टमेंट नंबर के सामने लिखा जाता है, असली पतों में यह अक्सर नहीं होता है।

यदि पूंछ घर के किसी भी नाम से मेल नहीं खाती है, तो हम इसे कंपनी के नामों में खोजने की कोशिश करते हैं: अक्सर कंपनी का नाम घर का "निहित" नाम होता है। कंपनी के नामों की तुलना करने के लिए, मीट्रिक थ्रेशोल्ड को 0.85 तक कम करना पड़ा - पीएएफ में नाम की स्पेलिंग और पते में अंतर के बीच अंतर इतना शानदार रहा।

आखिरी तुलना, अगर घरों के नाम के साथ या कंपनियों के नाम के साथ कोई मेल नहीं है - घर के कुछ हिस्सों के नाम के साथ: कभी-कभी, जब घर और विस्तार के अपने नाम होते हैं, तो पते में केवल विस्तार नाम का संकेत दिया गया था।

और फिर, मैं स्वीकार करता हूं कि अलियास बेस से घरों के उपनामों पर विचार नहीं किया गया था: यह पता चला है कि उपयोग किए गए पते लगभग हमेशा घरों के "मुख्य" नामों का उपयोग करते हैं।

लिखित कार्यों को एक बड़े अनुरोध में मिलाएं:

 CREATE FUNCTION Address_MatchDPS (@CUNAME varchar(40), @AD_ADDRESS varchar(160), @AD_ADDRESS_USER1 varchar(30), @AD_ADDRESS_USER2 varchar(30), @AD_POSTCODE varchar(12)) RETURNS TABLE AS RETURN select distinct postcode, dps, oname from Address_GetCounty(dbo.rtrimna(@AD_ADDRESS_USER2)) cross apply Address_GetPosttownId_2(@AD_ADDRESS, dbo.rtrimna(@AD_ADDRESS_USER1+' '+leftover)) address cross apply Address_GetPosttownId_dependent(local_id, byalias, dbo.rtrimna(address.leftover)) dep cross apply Address_GetThoroughfare(dep.local_id, dbo.rtrimna(dep.leftover)) tf cross apply Address_GetThoroughfare_dependent(tf.local_id, thfare_id, thdesc_id, dbo.rtrimna(tf.leftover)) dtf cross apply Address_GetBuilding(tf.local_id, thfare_id, thdesc_id, dbo.rtrimna(@CUNAME+' '+dtf.leftover)) bu where postcode=isnull(@AD_POSTCODE,postcode) --AD_POSTCODE=NULL disables check

ग्राहक के अनुसार, वह पीएएफ में उपयुक्त पते ढूंढता है, और पाया इंडेक्स, डीपीएस और कंपनी के नाम देता है। यदि एक ग्राहक के लिए कई रिकॉर्ड हैं, तो कॉलर कंपनी के नाम से उन्हें फ़िल्टर करने का प्रयास करेगा। (आखिरकार, यदि पते में घर का नाम और कंपनी का नाम दोनों शामिल हैं, तो Address_GetBuilding केवल घर के नाम की तुलना में है, और अन्य कंपनियां एक ही घर में स्थित हो सकती हैं।)

Address_MatchDPS में अलग का चयन करना आवश्यक है क्योंकि एक ही मेलबॉक्स को विभिन्न तरीकों से पाया जा सकता है - उदाहरण के लिए, स्रोत पते के विभिन्न तत्वों को गिराकर।

परिणामी फ़ंक्शन ने लगभग 500 पते प्रति घंटे की गति से काम किया, और मुख्य समय, जाहिरा तौर पर, जोरोविंक फ़ंक्शन के लिए कॉल से संबंधित था; एक चार-प्रोसेसर सर्वर पर, स्क्रिप्ट के चार उदाहरणों को चलाने से प्रदर्शन को चौगुना करने की अनुमति मिलती है। लगभग 60% पते सफलतापूर्वक पहचाने गए; शेष में या तो "बहुत ही गैर-मानक" रूप थे, या बस गलत या अपूर्ण थे, या एक गलत सूचकांक के साथ। अब एक छोटी अंग्रेजी कंपनी के कर्मचारियों को सभी गैर-मान्यता प्राप्त पतों को मैन्युअल रूप से देखना होगा और अशुद्धियों को ठीक करना होगा: सभी ग्राहकों के सटीक पतों का डेटाबेस प्रयास के लायक है।

मेल पता मान्यता