The Master Index Database Structure (Repository)
The following topics provide information about the master index database, including descriptions of
each table and a sample entity relationship diagram. All information in these topics
pertains to the default version of the database. Your implementation might vary depending on
the customization made to the Object Definition and to the scripts used to
create the master index database.
About the Master Index Database (Repository)
The master index database stores information about the entities being indexed, such as people
or businesses. The database stores records from local systems in their original form
and also stores a record for each object that is considered to be
the single best record (SBR).
The structure of the database tables that store object information is dependent on
the information specified in the Object Definition file created by the wizard. Oracle
Java CAPS Master Index generates a script to create the tables and fields
in the database based on the information in the Object Definition file. If
you update the Object Definition file, regenerating the application updates the database scripts
accordingly. This allows you to define the database as you define the object
structure.
While most of the structures created in the database are based on information
in the Object Definition file, some of the tables, such as sbyn_seq_table and
sbyn_common_detail, are standard for all implementations. The database includes tables that store information
about the objects defined for the master index application as well as tables
that store common maintenance information, transactional information, and external system information. The database includes
the tables listed in Table 2.
Table 2 Master Index Database Tables
|
|
|
Stores information for the parent objects associated
with local system records. This database table is named by the parent object name.
For example, a table storing company objects is named sbyn_company; a table storing
person objects is named sbyn_person. Only one table stores parent object information for
system records. |
|
Stores information for the parent objects associated with single best records.
This database table is named by the parent object name followed by “SBR”. For
example, a table storing company objects is named sbyn_companysbr; a table storing person
objects is named sbyn_personsbr. Only one table stores parent object information for SBRs. |
|
Stores
information for child objects associated with local system records. These database tables are
named by their object name. For example, a table storing address objects is
named sbyn_address; a table storing comment objects is named sbyn_comment. One database table
is created for each child object defined in the object structure. |
|
Stores information for
child objects associated with a single best record. These database tables are named
by their object name followed by “SBR”. For example, a table storing address
objects is named sbyn_addresssbr; a table storing comment objects is named sbyn_commentsbr. One
SBR database table is created for each child object defined in the object structure. |
|
Lists
the applications with which each item in stc_common_header is associated. |
|
Stores information about
records that were automatically matched by the master index application. |
|
Stores audit information about
each time object information is accessed from the EDM.
Note - If audit logging is enabled,
this table can grow very large and might require periodic archiving.
|
|
Contains all of the
processing codes associated with the items listed in sbyn_common_header. |
SBYN_COMMON_HEADER |
Contains a list of
the different types of processing codes used by the master index application. These
types are also associated with the drop-down lists you can specify for the
EDM. |
|
Stores the local ID and system pairs, along with their associated EUID. |
|
Stores information about
all merge and unmerge transactions processed from either external systems or the EDM. |
|
Stores
information about fields that are locked for updates in an SBR. |
|
Stores a list of
potential duplicate records and flags potential duplicate pairs that have been resolved. |
|
Stores the
sequential codes that are used in other tables in the database, such as
EUIDs, transaction numbers, and so on. |
|
Stores information about the system objects in
the database, including the local ID and system, create date and user, status,
and so on. |
|
Stores a list of systems in your organization, along with defining information. |
|
Stores
transaction information about an SBR, such as the create or update date, status,
and so on. |
|
Stores a history of changes to each record stored in the
database. |
|
Like the sbyn_common_detail table, this table stores processing codes and drop-down list values.
This table contains additional validation information that allows you to validate information in
a dependent field (for example, to validate cities against the entered postal code). |
|
Master Index Database Table Details (Repository)
The tables in the following topics describe each column in the default database
tables.
The columns are identical for Oracle and SQL Server databases, but the data
types differ in some cases. Table 3 lists the data type differences, and
the differences are noted in the Data Type column for each table in
this section.
Table 3 Oracle and SQL Server Data Type Differences
|
|
BLOB |
Varbinary(MAX) |
DATE |
DateTime |
INTEGER |
Int |
LONG |
Varchar(MAX) |
NUMBER |
Numeric |
TIMESTAMP |
DateTime |
VARCHAR2 |
Varchar |
|
SBYN_OBJECT_NAME
This table stores the parent object in each system record received by the master
index application. It is linked to the tables that store each child object
in the system record by the object_nameid column (where object_name is the name
of the parent object). This table contains the columns listed below regardless of the
design of the object structure, and also contains a column for each field
you defined for the parent object in the Object Definition file. Columns to
store standardized or phonetic versions of certain fields are automatically added when you
specify certain match types in the wizard.
The differences in data types between Oracle and SQL Server are noted in
Table 4. The Oracle type is on the first line, and the SQL Server
type is on the second.
Table 4 SBYN_OBJECT_NAME Table Description
|
|
|
|
|
The system code for the
system record. |
|
|
A local identification code assigned by the specified system. |
OBJECT_NAMEID |
|
A unique ID
for the parent object in a system record. This is named according to
the parent object. For example, if the parent object is “Company”, the name
of this column is “companyid”; if the parent object is “Person”, the name
of this column is “personid”. |
FIELD_NAME |
Varies |
The name of each field in the parent object.
A database column is created for each field, and the data type depends
on the type specified in the Object Definition file. |
|
SBYN_OBJECT_NAMESBR
This table stores the parent object of the SBR for each enterprise object in
the master index database. It is linked to the tables that store each
child object in the SBR by the object_nameid column (where object_name is the
name of the parent object). This table contains the columns listed below regardless of
the design of the object structure, and also contains a column for each
field defined for the parent object in the Object Definition file. In
addition, columns to store standardized or phonetic versions of certain fields are automatically added
when you specify certain match types in the wizard.
The differences in data types between Oracle and SQL Server are noted in
Table 5. The Oracle type is on the first line, and the SQL Server
type is on the second.
Table 5 SBYN_OBJECT_NAMESBR Table Description
|
|
|
|
|
The enterprise unique identifier assigned
by the master index application. |
OBJECT_NAMEID |
|
A unique ID for the parent object in a
system record. This is named according to the parent object. For example, if
the parent object is “Company”, the name of this column is “companyid”; if the
parent object is “Person”, the name of this column is “personid”. |
FIELD_NAME |
Varies |
The name of
each field in the parent object. A database column is created for each
field, and the data type depends on the type specified in the Object
Definition file. |
|
SBYN_CHILD_OBJECT
The sbyn_child_object tables (where child_object is the name of a child object in
the object structure) store information about the child objects associated with a system
record in the master index application. All tables storing child object information for system
records contain the columns listed below. The remaining columns are defined by the
fields you specify for each child object in the object structure, including any
standardized or phonetic fields.
The differences in data types between Oracle and SQL Server are noted in
Table 6. The Oracle type is on the first line, and the SQL Server
type is on the second.
Table 6 SBYN_CHILD_OBJECT and SBYN_CHILD_OBJECTSBR Table Description
|
|
|
OBJECT_NAMEID |
|
The unique ID for the
parent object associated with the child object in the system record. |
CHILD_OBJECTID |
|
The unique ID
for each record in the table. This column cannot be null. |
FIELD_NAME |
Varies |
The name of
each field in the child object. A database column is created for each
field, and the data type depends on the type specified in the Object
Definition file. |
|
SBYN_CHILD_OBJECTSBR
The sbyn_child_objectsbr tables (where child_object is the name of a child object in
the object structure) store information about the child objects associated with an SBR
in the master index application. All tables storing child object information for SBRs contain
the columns listed below. The remaining columns are defined by the fields you
specify for each child object in the Object Definition file, including any standardized
or phonetic fields.
The differences in data types between Oracle and SQL Server are noted in
Table 7. The Oracle type is on the first line, and the SQL Server
type is on the second.
Table 7 SBYN_CHILD_OBJECT and SBYN_CHILD_OBJECTSBR Table Description
|
|
|
OBJECT_NAMEID |
|
The unique ID for the
parent object associated with the child object in the SBR. |
CHILD_OBJECTID |
|
The unique ID for
each record in the table. This column cannot be null. |
FIELD_NAME |
Varies |
The name of each
field in the child object. A database column is created for each field,
and the data type depends on the type specified in the Object Definition
file. |
|
SBYN_APPL
This table stores information about the applications used in the master index system. The
differences in data types between Oracle and SQL Server are noted in Table 8.
The Oracle type is on the first line, and the SQL Server type
is on the second.
Table 8 SBYN_APPL Table Description
|
|
|
|
|
The unique sequence number code for
the listed application. |
|
|
A unique code for the application. |
|
|
A brief description of the
application. |
|
CHAR(1) |
An indicator of whether the current entry can be modified. If the value
of this column is “Y”, the entry cannot be modified. |
|
|
The date the
application entry was created. |
|
|
The logon ID of the user who created the
application entry. |
|
SBYN_ASSUMEDMATCH
This table maintains a record of each assumed match transaction that occurs in the
master index application, allowing you to review these transactions and, if necessary, reverse
an assumed match. This table can grow quite large over time and might
require periodic archiving. The differences in data types between Oracle and SQL Server
are noted in Table 9. The Oracle type is on the first line, and
the SQL Server type is on the second.
Table 9 SBYN_ASSUMEDMATCH Table Description
|
|
|
|
|
The unique ID
for the assumed match transaction. |
|
|
The EUID into which the incoming record was
merged. |
|
|
The system code for the source system (that is, the system from which
the incoming record originated). |
|
|
The local ID of the record in the source
system. |
|
|
The matching weight between the incoming record and the EUID record into which
it was merged. |
|
|
The transaction number associated with the assumed match. |
|
SBYN_AUDIT
This table maintains a log of each instance in which any of the
master index database tables are accessed through the EDM. This includes each time a
record appears on a search results page, a comparison page, the View/Edit page,
and so on. This log is only maintained if the EDM is configured
for it. This table can grow very large over time and might require
periodic archiving. The differences in data types between Oracle and SQL Server are
noted in Table 10. The Oracle type is on the first line, and the
SQL Server type is on the second.
Table 10 SBYN_AUDIT Table Description
|
|
|
|
|
The unique identification code
for the audit record. This column cannot be null. |
|
|
The name of the parent
object as defined in the Object Definition file. |
|
|
The EUID whose information was
accessed during an EDM transaction. |
|
|
The second EUID whose information was accessed during
an EDM transaction. A second EUID appears when viewing information about merge and
unmerge transactions, comparisons, and so on. |
FUNCTION (Oracle) OPERATION (SQL Server) |
|
The type of transaction that caused the
audit record to be written. This column cannot be null. |
|
VARCHAR2(120) Varchar(120) |
A brief description of
the transaction that caused the audit record to be written. |
|
|
The date the transaction
that created the audit record was performed. This column cannot be null. |
|
|
The user
ID of the person who performed the transaction that caused the audit log.
This column cannot be null. |
|
SBYN_COMMON_DETAIL
This table stores the processing codes and descriptions for all of the common maintenance
data elements. This is the detail table for sbyn_common_header. Each data element in
sbyn_common_detail is associated with a data type in sbyn_common_header by the common_header_id column.
None of the columns in this table can be null. The differences in
data types between Oracle and SQL Server are noted in Table 11. The Oracle
type is on the first line, and the SQL Server type is on
the second.
Table 11 SBYN_COMMON_DETAIL Table Description
|
|
|
|
|
The unique identification code of the common table
data element. |
|
|
The unique identification code of the common table data type associated
with the data element (as stored in the common_header_id column of the sbyn_common_header
table). |
|
|
The processing code for the common table data element. |
|
|
A description of the
common table data element. |
|
CHAR(1) |
An indicator of whether the common table data element
can be modified. |
|
|
The date the data element record was created. |
|
|
The user ID of
the person who created the data element record. |
|
SBYN_COMMON_HEADER
This table stores a description of each type of common maintenance data and is
the header table for sbyn_common_detail. Together, these tables store the processing codes and
drop-down menu descriptions for each common table data type. For a person index,
common table data types might include Religion, Language, Marital Status, and so on.
For a business index, common table data types might include Address Type, Phone Type,
and so on. None of the columns in this table can be
null.
The differences in data types between Oracle and SQL Server are noted in
Table 12. The Oracle type is on the first line, and the SQL Server
type is on the second.
Table 12 SBYN_COMMON_HEADER Table Description
|
|
|
|
|
The unique identification code of the
common table data type. |
|
|
The application ID from sbyn_appl that corresponds to the
application for which the common table data type is used. |
|
|
A unique processing code
for the common table data type. |
|
|
A description of the common table data
type. |
|
CHAR(1) |
An indicator of whether an entry in the table is read-only (if this
column is set to “Y”, the entry is read-only). |
|
|
The maximum number
of characters allowed in the code column for the common table data type. |
|
|
This
column is not currently used. |
|
|
The date the common table data type record
was created. |
|
|
The user ID of the person who created the common table
data type record. |
|
SBYN_ENTERPRISE
This table stores a list of all the system and local ID pairs
assigned to the enterprise records in the database, along with the associated EUID for
each pair. This table is linked to sbyn_systemobject by the systemcode and lid
columns, and is linked to sbyn_systemsbr by the euid column. This table maintains
links between the SBR and its associated system objects. None of the columns
in this table can be null.
The differences in data types between Oracle and SQL Server are noted in
Table 13. The Oracle type is on the first line, and the SQL Server
type is on the second.
Table 13 SBYN_ENTERPRISE Table Description
|
|
|
|
|
The processing code of the system
associated with the local ID. |
|
|
The local ID associated with the system and EUID. |
|
|
The
EUID associated with the local ID and system. |
|
SBYN_MERGE
This table maintains a record of each merge transaction that occurs in the
master index application, both through the EDM and from external systems. It also records
any unmerges that occur. The differences in data types between Oracle and SQL
Server are noted in Table 14. The Oracle type is on the first
line, and the SQL Server type is on the second.
Table 14 SBYN_MERGE Table Description
|
|
|
|
|
The unique,
sequential identification code of merge record. This column cannot be null. |
|
|
The EUID of
the record that was retained after the merge transaction. This column cannot be
null. |
|
|
The EUID of the record that was not retained after the merge transaction. |
|
|
The
transaction number associated with the merge transaction. This column cannot be null. |
|
|
The transaction
number associated with the unmerge transaction. |
|
SBYN_OVERWRITE
This table stores information about the fields that are locked for updates in the
SBRs. It stores the EUID of the SBR, the ePath to the
field, and the current locked value of the field. The differences in data types
between Oracle and SQL Server are noted in Table 15. The Oracle type
is on the first line, and the SQL Server type is on the
second.
Table 15 SBYN_OVERWRITE Table Description
|
|
|
|
|
The EUID of an SBR containing fields for which the
overwrite lock is set. |
|
|
The ePath to a field that is locked in an
SBR from the EDM. |
|
|
The data type of a field that is locked
in an SBR. |
|
|
The data that is locked for overwrite in an
integer field. |
|
|
The data that is locked for overwrite in a boolean
field. |
|
VARCHAR2(200) Varchar(200) |
The data that is locked for overwrite in a string field. |
|
CHAR(2) |
The data
that is locked for overwrite in a byte field. |
|
|
The data that is
locked for overwrite in a long integer field. |
|
|
The data that is locked
for overwrite in a date field. |
|
NUMBER(38,4) numeric(38, 4) |
The data that is locked for
overwrite in a floating decimal field. |
|
|
The data that is locked for overwrite in
a timestamp field. |
|
SBYN_POTENTIALDUPLICATES
This table maintains a list of all records that are potential duplicates of one
another. It also maintains a record of whether a potential duplicate pair has
been resolved or permanently resolved. The differences in data types between Oracle and
SQL Server are noted in Table 16. The Oracle type is on the first
line, and the SQL Server type is on the second.
Table 16 SBYN_POTENTIALDUPLICATES Table Description
|
|
|
|
|
The
unique identification number of the potential duplicate transaction. |
|
|
The matching weight of the potential
duplicate pair. |
|
|
This column is reserved for future use. |
|
VARCHAR2(120) Varchar(120) |
A description of what caused
the potential duplicate flag. |
|
|
The status of the potential duplicate pair. The possible
values are:
U – Unresolved
R – Resolved
A – Resolved permanently
|
|
|
This column is reserved for future use. |
|
|
The user ID of the person
who resolved the potential duplicate status. |
|
|
The date the potential duplicate status was resolved. |
|
VARCHAR2(120) Varchar(120) |
Comments
regarding the resolution of the duplicate status. This is not currently used. |
|
|
The EUID
of the second record in the potential duplicate pair. |
|
|
The transaction number associated
with the transaction that produced the potential duplicate flag. |
|
|
The EUID of the first
record in the potential duplicate pair. |
|
SBYN_SEQ_TABLE
This table controls and maintains a record of the sequential identification numbers used in
various tables in the database, ensuring that each number is unique and assigned
in order. Several of the ID numbers maintained in this table are determined
by the object structure. The numbers are assigned sequentially, but are cached in
chunks of 1000 numbers for optimization (so the application does not need to
query the sbyn_seq_table table for each transaction). The chunk size for the EUID sequence
is configurable. If the server is reset before all allocated numbers are used,
the unused numbers are discarded and never used, and numbering is restarted at
the beginning of the next 1000-number chunk.
The differences in data types between Oracle and SQL Server are noted in
Table 17. The Oracle type is on the first line, and the SQL Server
type is on the second.
Table 17 SBYN_SEQ_TABLE Table Description
|
|
|
|
|
The name of the object for
which the sequential ID is stored. |
|
|
The current value of the sequence.
The next record will be assigned the current value plus one. |
|
The default sequence numbers are listed in Table 18.
Table 18 Default Sequence Numbers
|
|
|
The sequence number that
determines how EUIDs are assigned to new records. The chunk size for the
EUID sequence number is configurable in the Threshold file. |
|
The sequence number assigned each
potential duplicate transaction record in sbyn_potentialduplicates (column name “potentialduplicateid”). |
|
The sequence number assigned to
each transaction in the master index application. This number is stored in sbyn_transaction
(column name “transactionnumber”). |
|
The sequence number assigned to each assumed match transaction record in sbyn_assumedmatch
(column name “assumedmatchid”). |
|
The sequence number assigned to each audit log record in
sbyn_audit (column name “audit_id”). |
|
The sequence number assigned to each merge transaction in sbyn_merge (column
name “merge_id”). |
|
The sequence number assigned to each application listed in sbyn_appl (column name
“appl_id”) |
|
The sequence number assigned to each common table data type listed in sbyn_common_header
(column name “common_header_id”). |
|
The sequence number assigned to each common table data element listed
in sbyn_common_detail (column name “common_detail_id”). |
|
Each parent and child object system record table
is assigned a sequential ID. The column names are named after the object
(for example, sbyn_address has a sequential column named “addressid”). The parent object ID is
included in each child object table. |
|
Each parent and child object SBR table
is assigned a sequential ID. The column names are named after the object
(for example, sbyn_addresssbr has a sequential column named “addressid”). The parent object ID is
included in each child object SBR table. |
|
SBYN_SYSTEMOBJECT
This table stores information about the system records in the database, including their local
ID and source system pairs. It also stores transactional information, such as the
create or update date and function. The differences in data types between Oracle
and SQL Server are noted in Table 19. The Oracle type is on
the first line, and the SQL Server type is on the second.
Table 19 SBYN_SYSTEMOBJECT Table Description
|
|
|
|
|
The processing code of the system associated with the local ID. This column
cannot be null. |
|
|
The local ID associated with the system and EUID (the
associated EUID is found in sbyn_enterprise). This column cannot be null. |
|
|
The type of
object being processed (currently only the name of the parent object). This column
is reserved for future use. |
|
|
The user ID of the person who created
the system record. |
|
|
The type of transaction that created the system record. |
|
|
The date
the system record was created. |
|
|
The user ID of the person who last
updated the system record. |
|
|
The type of transaction that last updated the system
record. |
|
|
The date the system record was last updated. |
|
|
The status of the system
record. The status can be one of these values:
|
|
SBYN_SYSTEMS
This table stores information about each system integrated into the master index environment, including
the system’s processing code and name, a brief description, the format of the
local IDs, and whether any of the system information should be masked. The
differences in data types between Oracle and SQL Server are noted in Table 20.
The Oracle type is on the first line, and the SQL Server type
is on the second.
Table 20 SBYN_SYSTEMS Table Description
|
|
|
|
|
The unique processing code of the system. |
|
VARCHAR2(120) Varchar(120) |
A
brief description of the system, or the system name. This is the value
that appears in the tree view panes of the EDM for each system
and local ID pair. |
|
CHAR(1) |
The status of the system in the master index
application. “A” indicates active and “D” indicates deactivated. |
|
|
The length of the local
identifiers assigned by the system. This length does not include any additional characters
added by the input mask. |
|
|
The required data pattern for the local IDs assigned
by the system. For more information about possible values and using Java patterns, see
“Patterns” in the class list for java.util.regex in the Javadocs provided with
the Java™ 2 Platform, Standard Edition (J2SE™ platform). Note that the data pattern is
also limited by the input mask described below. All regex patterns are supported
if there is no input mask. |
|
|
A mask used by the EDM to
add punctuation to the local ID. For example, the input mask DD-DDD-DDD inserts a
hyphen after the second and fifth characters in an 8-digit ID. These character
types can be used.
|
|
|
A mask used to strip any extra characters that
were added by the input mask for database storage. The value mask is
the same as the input mask, but with an “x” in place of
each punctuation mark. Using the input mask described above, the value mask is
DDxDDDxDDD. This strips the hyphens before storing the ID. |
|
|
The date the system information
was inserted into the database. |
|
|
The logon ID of the user who inserted
the system information into the database. |
|
|
The most recent date the system’s information was
updated. |
|
|
The logon ID of the user who last updated the system’s information. |
|
SBYN_SYSTEMSBR
This table stores transactional information about the system records for the SBR, such as
the create or update date and function. The sbyn_systemsbr table is indirectly linked
to the sbyn_systemobjects table through sbyn_enterprise. The differences in data types between Oracle
and SQL Server are noted in Table 21. The Oracle type is on the first
line, and the SQL Server type is on the second.
Table 21 SBYN_SYSTEMSBR Table Description
|
|
|
|
|
The EUID
associated with system record (the associated system and local ID are found in
sbyn_enterprise). This column cannot be null. |
|
|
The type of object being processed (currently only
the name of the parent object). This column is reserved for future use. |
|
|
The
system in which the system record was created. |
|
|
The user ID of the
person who created the system record. |
|
|
The type of transaction that created the
system record. |
|
|
The date the system object was created. |
|
|
The user ID of the
person who last updated the system record. |
|
|
The type of transaction that last
updated the system record. |
|
|
The date the system object was last updated. |
|
|
The status
of the enterprise record. The status can be one of these values:
|
|
|
The
revision number of the SBR. This is used for version control. |
|
SBYN_TRANSACTION
This table stores a history of changes made to each record in the
master index application, allowing you to view a transaction history and to undo certain
actions, such as merging two object records. The differences in data types between
Oracle and SQL Server are noted in Table 22. The Oracle type is
on the first line and the SQL Server type is on the second.
This table also includes one column that has a different name for Oracle
and for SQL Server.
Table 22 SBYN_TRANSACTION Table Description
|
|
|
|
|
The unique number of the transaction. |
|
|
This column is
reserved for future use. |
|
|
The local ID of the second system record involved
in the transaction. |
|
|
This column is reserved for future use. |
|
|
The EUID of the
second object record involved in the transaction. |
FUNCTION (Oracle) OPERATION (SQL Server) |
|
The type of
transaction that occurred, such as update, add, merge, and so on. |
|
|
The logon ID
of the user who performed the transaction. |
|
|
The date and time the transaction
occurred. |
|
|
A list of the changes that occurred to system records as a
result of the transaction. |
|
|
The processing code of the source system in which the
transaction originated. |
|
|
The local ID of the system record involved in the transaction. |
|
|
The EUID
of the enterprise record involved in the transaction. |
|
SBYN_USER_CODE
This table is similar to the sbyn_common_header and sbyn_common_detail tables in that it stores
processing codes and drop-down list values. This table is used when the value
of one field is dependent on the value of another. For example, if
you store credit card information, you could list each credit card type and
specify a required format for the credit card number field. The data stored
in this table includes the processing code, a brief description, and the format
of the dependent fields.
The differences in data types between Oracle and SQL Server are noted in
Table 23. The Oracle type is on the first line, and the SQL Server
type is on the second.
Table 23 SBYN_USER_CODE Table Description
|
|
|
|
|
The code list name of the
user code type (using the credit card example above, this might be similar
to “CREDCARD”). This column links the values for each list. |
|
|
The processing code of
each user code element. |
|
|
A brief description or name for the user code.
This is the value that appears in the drop-down list. |
|
|
The required data pattern
for the field that is constrained by the user code. For more information
about possible values and using Java patterns, see “Patterns” in the class list
for java.util.regex in the Javadocs provided with the J2SE platform. Note that the
data pattern is also limited by the input mask described below. All regex
patterns are supported if there is no input mask. |
|
|
A mask used by the
EDM to add punctuation to the constrained field. For example, the input mask
DD-DDD-DDD inserts a hyphen after the second and fifth characters in an 8-digit
ID. These character types can be used.
|
|
|
A mask used to strip any extra
characters that were added by the input mask for database storage. The value
mask is the same as the input mask, but with an “x” in
place of each punctuation mark. Using the input mask described above, the value
mask is DDxDDDxDDD. This strips the hyphens before storing the ID. |
|
Sample Master Index Database Model (Repository)
The diagrams on the following pages illustrate the table structure and relationships for
a sample Oracle database designed for storing information about companies. The diagrams display
attributes for each database column, such as the field name, data type, whether
the field can be null, and primary keys. They also show directional relationships between
tables and the keys by which the tables are related. This diagram is
very similar to SQL Server, with the exception of a few column name
changes and some different data types as noted in the tables above.