US20130066920A1 - Relational Database Model Optimized for the Use and Maintenance of Watchlist Data in a High Demand Environment - Google Patents

Relational Database Model Optimized for the Use and Maintenance of Watchlist Data in a High Demand Environment Download PDF

Info

Publication number
US20130066920A1
US20130066920A1 US13/232,412 US201113232412A US2013066920A1 US 20130066920 A1 US20130066920 A1 US 20130066920A1 US 201113232412 A US201113232412 A US 201113232412A US 2013066920 A1 US2013066920 A1 US 2013066920A1
Authority
US
United States
Prior art keywords
watchlist
information
tables
entry table
agency
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
US13/232,412
Other versions
US8412745B1 (en
Inventor
Bryan J. Walaschek
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Raytheon Co
Original Assignee
Raytheon Co
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Raytheon Co filed Critical Raytheon Co
Priority to US13/232,412 priority Critical patent/US8412745B1/en
Assigned to RAYTHEON COMPANY reassignment RAYTHEON COMPANY ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: WALASCHEK, Bryan J.
Priority to EP12779187.9A priority patent/EP2795479A4/en
Priority to PCT/US2012/055468 priority patent/WO2013040382A2/en
Publication of US20130066920A1 publication Critical patent/US20130066920A1/en
Application granted granted Critical
Publication of US8412745B1 publication Critical patent/US8412745B1/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/28Databases characterised by their database models, e.g. relational or object models
    • G06F16/284Relational databases

Definitions

  • This disclosure relates to a system and method for accessing and managing data related to a plurality of watchlists. More specifically, this disclosure relates to a method and system for accessing and managing data related to a plurality of traveler watchlists utilizing a watchlist table, a watchlist entry table for storing high-level information, and a plurality of detail tables associated with the watchlist entry table for storing detailed information.
  • a system for accessing and storing traveler-related watchlist information is disclosed.
  • a means for storing data related to one or more watchlists in a relational database management system (“RDBMS”) is disclosed.
  • RDBMS relational database management system
  • a normalized layout of the tables of the database allows the RDBMS to satisfy queries in a performance-optimized manner, while the minimal number of required attributes allows for the greatest degree of flexibility in its use.
  • Query information may be especially fast when the model is deployed in an enterprise class RDBMS incorporating such features as index-organized tables and partitioning.
  • An advantage of one embodiment of the disclosure may be improved performance in using and maintaining watchlist related data.
  • Another advantage of one embodiment of the disclosure may be separating detailed watchlist information from high level watchlist information.
  • FIG. 1 depicts a model of the system in accordance with the present disclosure.
  • the disclosed system relates to a system 10 and method for accessing and managing data related to a plurality of watchlists in a relational database system in a high demand environment.
  • the system 10 comprises a watchlist table 12 , a plurality of agency tables 14 , a watchlist entry table 16 , and plurality of detail tables 18 .
  • a hub-and-spoke architecture may be utilized wherein the watchlist entry table 16 serves as the hub with the plurality of detail tables 18 serving as the spokes.
  • the watchlist table 12 is preferably configured to capture or store metadata about the data stored throughout the system 10 .
  • This metadata may include (for example only) information about when the particular watchlist entry was created, loaded, or received from the respective agency.
  • the metadata may also include temporal information wherein the temporal information may define an effective start and stop time for the particular watchlist.
  • the watchlist table 12 may also be associated with a plurality of agency tables 14 .
  • the agency tables 14 may realize the many-to-many relationship between agencies that produce or maintain watchlists (i.e. FBI, CIA, law enforcement, etc.) and the various watchlists that may be maintained within the system 10 .
  • the watchlist entry table 16 may be a key component of the present disclosure. This main table may serve as the primary repository for high-level information related to watchlists. High-level information may include the minimal set of watchlist attributes which have been determined to increase system performance. For instance, attributes that are regularly searched in order to identify possible watchlist violations would appropriately be stored in the watchlist entry table 16 , while the detailed information about the particular attributes would more preferably be stored in the detail tables 18 .
  • the watchlist entry table 16 attributes are defined by the particular business requirements of the system 10 .
  • the watchlist entry table 16 attributes may include name, ethnic code, gender, date of birth, place of birth, height, hair color, eye color, and family information (such as the number of children cohabitating with the individual).
  • fast searches can still be performed to gather individuals that satisfy particular criteria maintained in the watchlist entry table 16 . (I.e., the system 10 may quickly search for all individuals born in a certain city between a particular time.) Because each of these key attributes is stored in a single table, performance may be improved because the RDBMS is not called upon to perform joins across numerous related tables.
  • the list of key attributes stored in the watchlist entry table 16 may change based upon the particular business requirements.
  • demographic information is a key searching component, and thus demographic information is properly stored in the watchlist entry table 16 .
  • the watchlist entry table 16 is thus designed to store the attributes that are used for regular and fast searching of the entire data set stored in the system 10 .
  • the detail tables 18 preferably contain the detailed information about the respective high level information contained in the watchlist entry table 16 . Once a search has been performed using the watchlist entry table 16 , detailed information about the respective watchlist information may then be retrieved from the detail tables 18 .
  • the computationally expensive step of searching across all individuals for particular criteria is optimized by segregating pre-selected criteria into a watchlist entry table 16 and searching across that table. Once the individuals of interest are returned, detailed information about them can be retrieved from the detail tables 18 .
  • the watchlist table 12 , agency tables 14 , watchlist entry table 16 , and detail tables 18 may be centrally located in a single location or remotely located from one another. Additionally, the watchlist table 12 may be a single database table, or may be a combination of tables logically presented to appear as a single table.
  • Appendix A is a data model dictionary for one embodiment of the present disclosure for use in the immigration control and identity management space. The contents of Exhibit A is herein incorporated by reference.
  • the system 10 may preferably be implemented in a computing system, which can include a personal computer, a workstation, a network computer, a hand held computer, or any other computing system. Further, the system can be written as a software program in any appropriate computer language.
  • the system 10 may include a processing device, which can be any computer processing unit, and could be a single central processing unit, or a number of processing units configured to operate either in sequence or in parallel.
  • the processing device can be configured to execute software processes which implement the steps disclosed herein.
  • the system may also include a memory capable of storing the steps necessary for a processing device to implement the steps disclosed herein. This memory could be in the form of memory resident within the processing device or in the form of standalone memory coupled to the processing unit via a communication path, such as a bus or a network.

Landscapes

  • Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

A data structure embodied on a computer-readable medium in conformance with a database schema for accessing and managing data related to a plurality of watchlists in a relational database system in a high demand environment, wherein the database schema comprising a watchlist table, a watchlist entry table for storing high-level information, and a plurality of detail tables for storing detailed information associated with a watchlist.

Description

    TECHNICAL FIELD
  • This disclosure relates to a system and method for accessing and managing data related to a plurality of watchlists. More specifically, this disclosure relates to a method and system for accessing and managing data related to a plurality of traveler watchlists utilizing a watchlist table, a watchlist entry table for storing high-level information, and a plurality of detail tables associated with the watchlist entry table for storing detailed information.
  • BACKGROUND OF THE INVENTION
  • Processing international travelers for immigration and other purposes is a complex risk management function. The vast majority of international travelers are law-abiding citizens, however some travelers present risks for security, illegal immigration, narcotics smuggling, and customs revenue evasion (to name a few). Given the volume of travelers, the finite availability of control authority resources, and the constraints on time available for passenger processing, border agencies face significant challenges in identifying potentially risky travelers without delaying legitimate travel and trade
  • The collection of pre-departure electronic data on travelers is emerging as the foundation of modern immigration control and border management. This approach is beneficial because electronic travel records can facilitate the implementation of a variety of automated functions, including watchlist checks and risk analysis, before passengers arrive. The analysis and presentation of this data also enables frontline immigration officers to be more effective during primary and secondary inspections. The combination of identifying risks earlier in the travel cycle and performing more effective primary inspections improves the processing time for arriving flights and facilitates international travel
  • Hence, there exists a need in the industry to overcome these problems and provide a method and system for accessing and processing data related to watchlists. Additionally, there exists a need in the industry to allow skilled border protection resources to focus on better assessing travelers rather than on paperwork requirements.
  • SUMMARY OF THE INVENTION
  • According to one embodiment of the present disclosure, a system for accessing and storing traveler-related watchlist information is disclosed. In one aspect, a means for storing data related to one or more watchlists in a relational database management system (“RDBMS”) is disclosed. In another aspect, a normalized layout of the tables of the database allows the RDBMS to satisfy queries in a performance-optimized manner, while the minimal number of required attributes allows for the greatest degree of flexibility in its use. Query information may be especially fast when the model is deployed in an enterprise class RDBMS incorporating such features as index-organized tables and partitioning.
  • An advantage of one embodiment of the disclosure may be improved performance in using and maintaining watchlist related data.
  • Another advantage of one embodiment of the disclosure may be separating detailed watchlist information from high level watchlist information.
  • Various embodiments of the disclosure may have none, some, or all of these advantages. Other technical advantages of the present disclosure may also be readily apparent to one skilled in the art.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • For a more complete understanding of the present disclosure and its advantages, reference is now made to the following descriptions, taken in conjunction with the associated drawing, in which:
  • FIG. 1 depicts a model of the system in accordance with the present disclosure.
  • DETAILED DESCRIPTION OF THE DRAWINGS
  • The disclosed system relates to a system 10 and method for accessing and managing data related to a plurality of watchlists in a relational database system in a high demand environment. In a preferred embodiment, the system 10 comprises a watchlist table 12, a plurality of agency tables 14, a watchlist entry table 16, and plurality of detail tables 18. In a preferred configuration, a hub-and-spoke architecture may be utilized wherein the watchlist entry table 16 serves as the hub with the plurality of detail tables 18 serving as the spokes.
  • The watchlist table 12 is preferably configured to capture or store metadata about the data stored throughout the system 10. This metadata may include (for example only) information about when the particular watchlist entry was created, loaded, or received from the respective agency. The metadata may also include temporal information wherein the temporal information may define an effective start and stop time for the particular watchlist.
  • The watchlist table 12 may also be associated with a plurality of agency tables 14. The agency tables 14 may realize the many-to-many relationship between agencies that produce or maintain watchlists (i.e. FBI, CIA, law enforcement, etc.) and the various watchlists that may be maintained within the system 10.
  • The watchlist entry table 16 may be a key component of the present disclosure. This main table may serve as the primary repository for high-level information related to watchlists. High-level information may include the minimal set of watchlist attributes which have been determined to increase system performance. For instance, attributes that are regularly searched in order to identify possible watchlist violations would appropriately be stored in the watchlist entry table 16, while the detailed information about the particular attributes would more preferably be stored in the detail tables 18.
  • In one preferred embodiment, the watchlist entry table 16 attributes are defined by the particular business requirements of the system 10. For example, in a security monitoring situation designed to assist in travel restriction databases (such as management and monitoring of a no-fly list), the watchlist entry table 16 attributes may include name, ethnic code, gender, date of birth, place of birth, height, hair color, eye color, and family information (such as the number of children cohabitating with the individual).
  • Thus, when the system 10 is fully populated, fast searches can still be performed to gather individuals that satisfy particular criteria maintained in the watchlist entry table 16. (I.e., the system 10 may quickly search for all individuals born in a certain city between a particular time.) Because each of these key attributes is stored in a single table, performance may be improved because the RDBMS is not called upon to perform joins across numerous related tables.
  • As would be understood to one of skill in the art, the list of key attributes stored in the watchlist entry table 16 may change based upon the particular business requirements. Thus, in the example discussed above, demographic information is a key searching component, and thus demographic information is properly stored in the watchlist entry table 16.
  • The watchlist entry table 16 is thus designed to store the attributes that are used for regular and fast searching of the entire data set stored in the system 10. The detail tables 18 preferably contain the detailed information about the respective high level information contained in the watchlist entry table 16. Once a search has been performed using the watchlist entry table 16, detailed information about the respective watchlist information may then be retrieved from the detail tables 18. Thus, the computationally expensive step of searching across all individuals for particular criteria is optimized by segregating pre-selected criteria into a watchlist entry table 16 and searching across that table. Once the individuals of interest are returned, detailed information about them can be retrieved from the detail tables 18.
  • The watchlist table 12, agency tables 14, watchlist entry table 16, and detail tables 18 may be centrally located in a single location or remotely located from one another. Additionally, the watchlist table 12 may be a single database table, or may be a combination of tables logically presented to appear as a single table.
  • Appendix A is a data model dictionary for one embodiment of the present disclosure for use in the immigration control and identity management space. The contents of Exhibit A is herein incorporated by reference.
  • The system 10 may preferably be implemented in a computing system, which can include a personal computer, a workstation, a network computer, a hand held computer, or any other computing system. Further, the system can be written as a software program in any appropriate computer language.
  • The system 10 may include a processing device, which can be any computer processing unit, and could be a single central processing unit, or a number of processing units configured to operate either in sequence or in parallel. The processing device can be configured to execute software processes which implement the steps disclosed herein. The system may also include a memory capable of storing the steps necessary for a processing device to implement the steps disclosed herein. This memory could be in the form of memory resident within the processing device or in the form of standalone memory coupled to the processing unit via a communication path, such as a bus or a network.
  • Although this disclosure has been described in terms of certain embodiments and generally associated methods, alterations and permutations of these embodiments and methods will be apparent to those skilled in the art. Accordingly, the above description of example embodiments does not define or constrain this disclosure. Other changes, substitutions, and alterations are also possible without departing from the spirit and scope of this disclosure.

Claims (20)

1. A data structure embodied on a computer-readable medium in conformance with a database schema for accessing and managing data related to a plurality of watchlists in a relational database system in a high demand environment, the database schema comprising:
a watchlist table for containing top-level metadata about each watchlist stored within the system wherein the top-level metadata comprises source information about each watchlist, and temporal information related to the enforceability of each watchlist; the watchlist table further associated with a plurality of agency tables wherein the plurality of agency tables comprise information about the agency associated with each watchlist;
a watchlist entry table for containing a minimal set of watchlist attributes comprising high-level demographic information about an individual to be watched wherein the high-level demographic information comprises a name, an ethnic code, a gender, a date of birth, a place of birth, height, hair color, eye color, and family information; and
a plurality of detail tables wherein each detail table is associated with the watchlist entry table and contains detailed data comprising detailed information about each watchlist attribute contained in the watchlist entry table.
2. A system embodied on a computer-readable medium for accessing and managing data related to a plurality of watchlists in a relational database, the system comprising:
a watchlist table for containing top-level metadata about each watchlist stored within the system;
a watchlist entry table for containing a set of watchlist attributes; and
a plurality of detail tables wherein each detail table is associated with the watchlist entry table and contains detailed data about each watchlist attribute contained in the watchlist entry table.
3. The system of claim 2 wherein the watchlist table comprises source information about each watchlist.
4. The system of claim 2 wherein the watchlist table comprises temporal information related to the enforceability of each watchlist.
5. The system of claim 2 wherein the watchlist table is further associated with a plurality of agency tables.
6. The system of claim 5 wherein the plurality of agency tables comprise information about the agency associated with each watchlist.
7. The system of claim 2 wherein the set of attributes contained in the watchlist entry table is a minimal set of attributes.
8. The system of claim 2 wherein the set of attributes comprises demographic information about an individual to be watched.
9. The system of claim 8 wherein the demographic information comprises a name, an ethnic code, a gender, a date of birth, a place of birth, height, hair color, eye color, and family information.
10. The system of claim 9 wherein the family information comprises the number of children known to be cohabitating with the individual.
11. The system of claim 2 further comprising a computer processor communicatively connected to the relational database.
12. The system of claim 2 further, comprising a data storage device wherein the database is contained on the data storage device.
13. A method for optimizing access and management of data related to a plurality of watchlists in a relational database in a high demand environment utilizing a watchlist table, a watchlist entry table, and a plurality of detail tables, the method comprising the following steps:
storing top-level meta data about each watchlist in the watchlist table;
storing high-level watchlist information in the watchlist entry table and storing detailed watchlist information in the plurality of detail tables, wherein the plurality of detail tables is associated with the watchlist entry table in order to optimize performance.
14. The method of claim 13 wherein the high-level information is demographic information.
15. The method of claim 14 wherein the demographic information comprises a name, an ethnic code, a gender, a date of birth, a place of birth, height, hair color, eye color, and family information.
16. The method of claim 15 wherein the family information comprises the number of children known to be cohabitating with the individual.
17. The method of claim 13 wherein performance is optimized by searching only the watchlist entry table.
18. The method of claim 13 wherein the high-level information is a set of information pre-selected to optimize searching within the database.
19. The method of claim 13 further comprising searching the watchlist entry table based on a set of criteria, and then gathering detailed information about the results returned from the watchlist entry table by consulting the plurality of detail tables.
20. The method of claim 13 further comprising associating the watchlist table with a plurality of agency tables.
US13/232,412 2011-09-14 2011-09-14 Relational database model optimized for the use and maintenance of watchlist data in a high demand environment Active US8412745B1 (en)

Priority Applications (3)

Application Number Priority Date Filing Date Title
US13/232,412 US8412745B1 (en) 2011-09-14 2011-09-14 Relational database model optimized for the use and maintenance of watchlist data in a high demand environment
EP12779187.9A EP2795479A4 (en) 2011-09-14 2012-09-14 A relational database model optimized for the use and maintenance of watchlist data in a high demand environment
PCT/US2012/055468 WO2013040382A2 (en) 2011-09-14 2012-09-14 A relational database model optimized for the use and maintenance of watchlist data in a high demand environment

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US13/232,412 US8412745B1 (en) 2011-09-14 2011-09-14 Relational database model optimized for the use and maintenance of watchlist data in a high demand environment

Publications (2)

Publication Number Publication Date
US20130066920A1 true US20130066920A1 (en) 2013-03-14
US8412745B1 US8412745B1 (en) 2013-04-02

Family

ID=47089118

Family Applications (1)

Application Number Title Priority Date Filing Date
US13/232,412 Active US8412745B1 (en) 2011-09-14 2011-09-14 Relational database model optimized for the use and maintenance of watchlist data in a high demand environment

Country Status (3)

Country Link
US (1) US8412745B1 (en)
EP (1) EP2795479A4 (en)
WO (1) WO2013040382A2 (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160155053A1 (en) * 2013-03-15 2016-06-02 International Business Machines Corporation Interactive method to reduce the amount of tradeoff information required from decision makers in multi-attribute decision making under uncertainty

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6567807B1 (en) * 2000-01-28 2003-05-20 Ccbn.Com, Inc. Investor relations event scheduling system and method
US7028018B2 (en) * 2002-05-14 2006-04-11 Ideal Innovations, Inc. Cooperative biometrics abnormality detection system (C-BAD)
AU2003298731A1 (en) * 2002-11-26 2004-06-18 Digimarc Id Systems Systems and methods for managing and detecting fraud in image databases used with identification documents
US7945035B2 (en) * 2003-02-28 2011-05-17 Siemens Enterprise Communications, Inc. Dynamic presence proxy for call sessions
US20060026669A1 (en) * 2004-07-29 2006-02-02 Zakas Phillip H System and method of characterizing and managing electronic traffic
US7822775B2 (en) * 2007-07-20 2010-10-26 Sap Ag Method and system for managing complex database information
US8555354B2 (en) * 2008-02-21 2013-10-08 Anthony S. Iasso Systems and methods for secure watchlisting
US7937385B2 (en) * 2008-05-05 2011-05-03 International Business Machines Corporation Obtaining a plan for executing a query in a relational database
US8239526B2 (en) * 2008-11-14 2012-08-07 Oracle International Corporation System and method for performance data collection in a virtual environment

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160155053A1 (en) * 2013-03-15 2016-06-02 International Business Machines Corporation Interactive method to reduce the amount of tradeoff information required from decision makers in multi-attribute decision making under uncertainty
US10366331B2 (en) * 2013-03-15 2019-07-30 International Business Machines Corporation Interactive method to reduce the amount of tradeoff information required from decision makers in multi-attribute decision making under uncertainty

Also Published As

Publication number Publication date
EP2795479A4 (en) 2019-01-16
WO2013040382A3 (en) 2015-01-08
EP2795479A2 (en) 2014-10-29
US8412745B1 (en) 2013-04-02
WO2013040382A2 (en) 2013-03-21

Similar Documents

Publication Publication Date Title
US11531717B2 (en) Discovery of linkage points between data sources
Cuzzocrea et al. Big data: a research agenda
US9224007B2 (en) Search engine with privacy protection
US8972387B2 (en) Smarter search
US9779172B2 (en) Personalized search result summary
US20100306206A1 (en) System and method for high precision and high recall relevancy searching
US20140188993A1 (en) Method and apparatus for analysis of social media
US20220100899A1 (en) Protecting sensitive data in documents
US20180129708A1 (en) Query processing management in a database management system
CN104508662B (en) The system and method for storing classification
CN109597843A (en) Data managing method, device, storage medium and the electronic equipment of big data environment
US10915535B2 (en) Optimizations for a behavior analysis engine
US20110225138A1 (en) Apparatus for responding to a suspicious activity
CN111913860B (en) Operation behavior analysis method and device
CN106682042A (en) Relational data cache and inquiry method and device
US10380115B2 (en) Cross column searching a relational database table
EP3493076B1 (en) Cognitive decision system for security and log analysis using associative memory mapping in graph database
US8412745B1 (en) Relational database model optimized for the use and maintenance of watchlist data in a high demand environment
CN114003634A (en) Big data analysis and retrieval system and method based on ES technology
US20160196331A1 (en) Reconstitution order of entity evaluations
US20210406708A1 (en) Machine learning based identification and classification of database commands
US20200293561A1 (en) Systems and methods for providing an object platform for datasets
Sagi et al. Multi-source uncertain entity resolution at yad vashem: Transforming holocaust victim reports into people
US10262042B2 (en) System and method for determining that two data records relate to the same subject
CN107885834A (en) A kind of Hadoop big datas component uniformly verifies system

Legal Events

Date Code Title Description
AS Assignment

Owner name: RAYTHEON COMPANY, MASSACHUSETTS

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:WALASCHEK, BRYAN J.;REEL/FRAME:026934/0452

Effective date: 20110913

FEPP Fee payment procedure

Free format text: PAYOR NUMBER ASSIGNED (ORIGINAL EVENT CODE: ASPN); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

STCF Information on status: patent grant

Free format text: PATENTED CASE

FPAY Fee payment

Year of fee payment: 4

MAFP Maintenance fee payment

Free format text: PAYMENT OF MAINTENANCE FEE, 8TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1552); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

Year of fee payment: 8