Skip Headers
Oracle® Healthcare Master Person Index
Release 1.1
Go to Documentation Home
Home		 Go to Book List
Book List		 Go to Table of Contents
Contents		 Go to Feedback page
Contact Us
Go to previous page
Previous		 Go to next page
Next
 

Master Person Index Database

This chapter presents general information that will help you analyze your database requirements and what you should consider before you design an Oracle Healthcare Master Person Index database. It then provides a procedure that leads you through the process of creating a master person index database.

This chapter includes the following sections:

Understanding Master Person Index Database Scripts and Design

Before you create the master person index database, familiarize yourself with the database scripts and the database structure. Analyze your database requirements, including hardware considerations, startup data, indexing needs, performance, and so on.

The following sections provide information to help you in your analysis:

Master Person Index Database Scripts

The wizard creates SQL scripts based on information you specified about code lists and external systems that you can use to define startup data for the master person index application. When you generate the application, additional scripts are generated for creating or dropping database tables. These scripts appear under the Database Script node of the master person index project, and are named create.sql, systems.sql, codelist.sql, and drop.sql. You can modify these scripts as needed to customize the tables, indexes, startup data, and database distribution. You can also create new database scripts if needed.

Master Person Index Database Requirements

When configuring the master person index database, there are several factors to consider, including basic software requirements, operating systems, disk space, and so on. This section provides a summary of requirements for the database. For more detailed information about designing and implementing the database, refer to the appropriate database platform documentation. The person responsible for the database configuration should be a database administrator familiar with the master person index database and with your data processing requirements.

Database Platform Requirements

The master person index database can be run on MySQL Enterprise Server 5.1x, Microsoft SQL Server 2005SP3 or 2008SP1, or on Oracle 10gR2 or 11gR2. You must have this software installed before beginning the database installation. Make sure you also install the latest patches for the version you are using.

Securing Your Application Requirements

The OHMPI application can be secured via Application Server provided SSL. OHMPI application runs as an EJB application and as a WSDL-based web service. Please refer to the GlassFish/WebLogic security guides on how to configure applications using SSL.

Operating System Requirements

The database can be installed on any operating system supported by the database platform you are using. See the documentation that came with your database server for more information.

Hardware Requirements

This section describes the minimum recommended hardware configuration for a database installation. These requirements are based on the minimum requirements recommended by database vendors for a typical installation. Depending on the size of the database and expected volume, you should increase these recommendations as needed. See the documentation for your database for more information and for supported operating systems.

MySQL Database

For information and tips about installing a MySQL database for Oracle Healthcare Master Person Index, see Chapter 2 of the MySQL 5.1 Reference Manual.

Oracle Database

For a Windows database server, the following configuration is recommended as a minimal installation:

  • Windows 2008, 7, Vista SP1+, XP SP2+, 2003 R2 SP2, 2008 R2 on 64 bits

  • Pentium 266 or later

  • 1 GB RAM (increase this based on the number of users, connections to the database, and volume)

  • Virtual memory should be double the amount of RAM

  • 3 GB disk space plus an additional 2 KB for each system record to be stored in the database (note that this is a conservative estimate per system record, assuming that most records do not contain complete data). This depends on the Oracle environment you install. Enterprise Edition can take up to 5 GB.

  • 256-color video

For a UNIX database server, the following configuration is recommended as a minimal installation:

  • 256 MB RAM (increase this based on the number of users and connections to the database)

  • Swap space should be a minimum of twice the amount of RAM

  • 2 GB disk space plus an additional 2 KB for each system record to be stored in the database (note that this is a conservative estimate per system record, assuming that most records do not contain complete data).

    Note:

    Disk space recommendations do not take into account the volume and processing requirements or the number of users. These are minimal requirements to install a generic database. At a minimum, the empty database and the database software will require 2.5 GB of disk space.
Microsoft SQL Server

The following configuration is recommended as a minimal installation for a SQL Server database.

  • Pentium III-compatible processor or higher

  • 512 MB RAM as a minimum; at least 1 GB is recommended (increase this based on the number of users, connections to the database, and volume)

  • 3 GB disk space plus an additional 2 KB for each system record to be stored in the database (note that this is a conservative estimate per system record, assuming that most records do not contain complete data). This depends on the SQL Server environment you install.

  • VGA or higher resolution

    Note:

    Disk space recommendations do not take into account the volume and processing requirements or the number of users. These are minimal requirements to install a generic database. At a minimum, the empty database and the database software will require 1.6 GB of disk space.

Master Person Index Database Structure

The master person index database contains some common tables that are created for all implementations and some that are customized for each implementation. The common tables include standard database system tables and supporting tables, such as sbyn_seq_table, sbyn_common_header, and sbyn_common_detail. These tables do not store information about the enterprise object structure you defined. The names of the tables that store information about the enterprise object are customized based on the object structure.

Two tables store information about the primary, or parent, object you defined: sbyn_parent_object and sbyn_parent_objectsbr, where parent_object is the name you specified for the parent object in the object structure. The sbyn_parent_object table stores parent object data from each local system and the sbyn_parent_objectsbr table stores the parent object data contained in the SBRs. Similar tables are created for each child object you defined in the object structure.

Designing the Master Person Index Database

In designing the database, there are several factors to consider, such as the volume of data stored in the database and the number of transactions processed by the database daily. The master person index database should be created in its own tablespaces. The following sections describe some of the analyses to perform along with considerations to take into account when designing the database.

Designing for Performance Optimization

The MySQL, Oracle and SQL Server installation guides provide detailed information about installing the database software for optimal performance. Both database platforms include guides containing information about monitoring and fine-tuning your database, including tuning memory, swap space, I/O, CPU usage, block and file size, and so on. You should be familiar with these concepts prior to creating the database.

Data Structure Analysis

Before defining the object structure, you analyzed the structure of the legacy data to help you define the object structure and the attributes of each field. You can use this data analysis to determine the amount of data that will be stored in the database, which will help you size the master person index database and decide how to best distribute the database. Knowing the volume of existing data plus the expected daily transaction volume will help you plan the requirements of the database server, such as networking needs, disk space, memory, swap space, and so on.

The data structure analysis also helps you determine the processing codes and descriptions to enter in the common tables (described below), and should help you determine any default values that have been entered into certain fields that could skew the matching probability weights.

Common Table Data

Common table data analysis involves gathering information about the abbreviations used for specific data elements in each sending system, such as system codes and codes for certain attributes of the objects in your database. For example, if you are indexing person objects, there might be processing codes for genders, such as F for female, M for male, and so on. The processing codes and their descriptions are stored in a set of database tables known as common maintenance tables. The wizard creates a script to help you load the processing codes into the database.

When an enterprise object appears on the MIDM, the master person index application translates the processing codes defined in the common tables into their descriptions so the user is not required to decipher each code. The data elements stored in the common maintenance tables are also used to populate the drop-down lists that appear for certain fields in the MIDM. Users can select from these options to populate the associated fields.

User Code Data

User code data analysis involves gathering information about the abbreviations used for specific data elements in each sending system for a field whose format or possible values are constrained by a separate field. For example, if you store credit card information, you might have a drop-down list in the Credit Card field for each credit card type. The format of the field that stores the credit card number is dependent on the type of credit card you select. You could also use user code data to validate cities with postal codes. The abbreviations and related constraint information are stored in the sbyn_user_code table.

Database Considerations

When you create the master person index database, you need to consider several factors, such as sizing, distribution, indexes, and extents. By default, all of the master person index database tables for an Oracle database are installed in the system tablespace. You should install the master person index tables in different tablespaces, depending on the original size and expected volume of the database. For SQL Server, the master person index tables belong to "dbo" by default.

Database Sizing

To begin the database installation, you first create a database instance using the provided configuration tools or command line functions. Use the tools provided by the database vendor to define the tablespace and extent sizing for the database.

Database Distribution

When you create the database instance, you can define the distribution of your system tables, data tables, rollback logs, dump files, control files, and so on. Use internal policies regarding relational database distribution to determine how to best distribute your master person index database.

Database Indexes

By default, indexes are defined for the following tables: sbyn_appl, sbyn_common_header, sbyn_common_detail, sbyn_enterprise, sbyn_transaction, sbyn_assumedmatch, sbyn_potentialduplicates, sbyn_audit, and sbyn_merge. You can create additional indexes against the database to optimize the searching and matching processes. At a minimum, it is recommended that all combinations of fields used for blocking or matching be indexed. For each query block defined in the blocking query, create an index containing the fields in that block.

The following indexes are automatically created to improve performance when running large reports from the command line or MIDM.

CREATE INDEX SBYN_POTENTIALDUPLICATES3 ON SBYN_POTENTIALDUPLICATES (TRANSACTIONNUMBER ASC);

CREATE INDEX SBYN_ASSUMEDMATCH2 ON SBYN_ASSUMEDMATCH (TRANSACTIONNUMBER ASC);

CREATE INDEX SBYN_TRANSACTION4 on SBYN_TRANSACTION (EUID2 ASC, TIMESTAMP ASC);

CREATE INDEX SBYN_TRANSACTION3 on SBYN_TRANSACTION (TIMESTAMP ASC, TRANSACTIONNUMBER ASC);

Note:

To improve performance, these four indexes should be dropped prior to performing an initial load or batch load of data. They can be recreated once the load is complete if you are running the provided reports.

Creating the Master Person Index Database

Once you have customized the configuration files and generated the master person index application, you can create the master person index database. Before you begin, make sure you have MySQL, Oracle, or SQL Server installed on the database server.

During this process you can define custom startup data, such as code lists and source systems. The wizard defines SQL statements in the Code List and Systems SQL files (codelist.sql and system.sql) to insert startup data into the database based on information you specify, and you can customize the statements to insert the data relevant to your object structure. The code lists you define are used to translate processing codes from incoming messages into descriptions for the MIDM fields and to create drop-down lists for MIDM fields. System information is required in order to add records to the master person index application.

Follow these steps to create the database:

You can also delete the database for testing purposes using the supplied script. See Dropping Master Person Index Database Tables for more information.

Step 1: Analyze the Master Person Index Database Requirements

Before you begin to create the master person index database, perform an analysis of the structure of the legacy data to be stored in the database and determine the amount of data that will be processed daily. During the analysis, be sure to define the processing codes that need to be stored in the common maintenance tables and the systems that will share data with the master person index application. You should also know the length and format of the local IDs assigned by each system.

A database administrator who is familiar with your data and processing requirements should perform this task. After this task is complete, continue to "Step 2: Create a Master Person Index Database and User".

For additional information and guidelines about how to set up your database, see "Understanding Master Person Index Database Scripts and Design".

Step 2: Create a Master Person Index Database and User

Before beginning this step, complete "Step 1: Analyze the Master Person Index Database Requirements". After you create the database instance and user, continue to "Step 3: Define Master Person Index Database Indexes" if you want to define additional database indexes; otherwise skip to "Step 4: Define Master Person Index External Systems".

For this step you need to create a database in which the master person index database instance will be created. Use the tools provided by your database vendor to create the database. Using these tools, you define tablespaces, including their sizes and locations; extents; and dump file, log file, and rollback file sizes and locations. Make sure these issues have been thoroughly analyzed and designed before creating the database.

Note:

For SQL Server databases, make sure to activate remote authentication.

Once you create the database, you can use standard SQL to create the master person index application user for the database. The user you create in this step will be used to create the database structure and to connect to the database through the MIDM and through the application server.

For Oracle, assign the user to the "connect" and "resource" roles for the master person index tablespaces. For example:

create user username identified by password;
grant connect, resource to username;
commit;

where username is the login ID of the administrator user and password is the login password of the administrator user.

For SQL Server, assign this user to the "db_owner" role. You need to create the server login, create the user, and then assign the user to the role. For example:

CREATE LOGIN loginname WITH PASSWORD = 'password', DEFAULT_DATABASE = database; 
CREATE USER username FOR LOGIN loginname; USE database;
EXECUTE sp_addrolemember 'db_owner', 'username' GO

where loginname is the login ID for the administrator user, password is the login password, database is the database name, and username is the owner of the database tables created in the master person index database.

Note:

SQL Server allows Windows Authentication, where only a user name is required. Oracle Healthcare Master Person Index requires full SQL Server authentication, including both a user name and password. You need to create a database user specifically for the master person index application.

For MySQL, you can grant the user access to all permissions, or you can assign the individual permissions listed below. For example:

CREATE USER 'username'@'server_name' IDENTIFIED BY 'password'; 
GRANT ALL ON database TO 'username'@'server_name';
GRANT SELECT, INSERT ON database TO 'username'@'server_name';

where username is the login ID for the user, server_name is the name of the database server, password is the login password, and database is the database name.

If you prefer to assign individual permissions to the user instead of roles, the following permissions are needed.

alter any index delete any table
alter any procedure drop any index
alter any table drop any procedure
alter any trigger drop any table
create any index drop any trigger
create procedure drop any view
create session insert any table
create table select any table
create trigger update any table
create view  

Step 3: Define Master Person Index Database Indexes

To optimize data processing in the master  person index application, you can define additional indexes for the database tables that store object data. Best practice is to define indexes for each field used for searching, blocking, or matching. You can define these indexes in create.sql or create a new script. Before you begin this step, complete "Step 2: Create a Master Person Index Database and User".

To Define an Index

  1. Do one of the following:

    • Under the master person index project in the Projects window, expand Database Scripts and then open create.sql in the NetBeans editor.

    • On your computer, navigate to project_home/src/DatabaseScript, where project_home is the location of the master person index project files. Open create.sql in a text editor.

  2. Do any of the following:

    • Remove an existing index definition (not recommended).

    • Create new index definitions for the required fields.

    • Modify an existing index definition.

  3. Save and close the file.

  4. Continue to "Step 4: Define Master Person Index External Systems".

Step 4: Define Master Person Index External Systems

A SQL script is automatically created to insert the systems you specified in the wizard. These statements are provided in systems.sql in the master person index project. Before you begin this step, complete "Step 2: Create a Master Person Index Database and User" and, optionally, "Step 3: Define Master Person Index Database Indexes".

To Define an External System

  1. Do one of the following:

    • Under the master person index project in the Projects window, expand Database Scripts and then open systems.sql in the NetBeans editor.

    • On your computer, navigate to project_home/src/DatabaseScript, where project_home is the location of the master person index project files. Open systems.sql in a text editor.

  2. For each system, create an INSERT statement using the column descriptions in Master Person Index Database Table Description for sbyn_systems to define the VALUES clause.

    For example:

    INSERT into sbyn_systems (systemcode, description, status, id_length, 
format, input_mask, value_mask, create_date, create_userid) VALUES ('ARS', 
'Automated Registration System', 'A', 8, '[0-9]{8}', 'DD-DDD-DDD', 
'DD^DDD^DDD', sysdate, 'admin');

  3. Delete any default INSERT statements you do not need.

  4. Save and close the file.

  5. Continue to "Step 5: Define Master Person Index Code Lists".

Master Person Index Database Table Description for sbyn_systems

The following table lists and describes the columns in the sbyn_systems database table so you can create SQL statements to insert source system information into the master person index database.

Column Description
systemcode The unique processing code of the system. This field accepts any of the following characters:

  • ! _ ~ ( ) { } + \Q # $ % & : ; - /

  • a-z

  • A-Z

  • 0-9

  • þ ÿ Þ ß 'à-ö ø-ý À-Ö Ø-Ý
description A brief description of the system, or the system name.
status The status of the system in the master person index system. Specify A for active or D for deactivated.
id_length The length of the local identifiers assigned by the system. This length does not include any additional characters added by the input mask (see below).

Note: The default maximum length of the LID database columns is 25. If the system generates longer local IDs, be sure to increase the length of all LID columns in the database.
format 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 Java. Note that the pattern specified here might be further restricted by the input mask described below.
input_mask A mask used by the MIDM to add punctuation to the local ID. For example, you can add an input mask to display the local IDs with hyphens or constant characters. To define an input mask, enter a character type for each character in the field and place any necessary punctuation between the types. For example, to insert a hyphen after the second and fifth characters in an 8-digit ID, the input mask would be DD-DDD-DDD. The following character types can be used; any other characters are treated as constants.

  • D - indicates a numeric character.

  • L - indicates an alphabetic character.

  • A - indicates an alphanumeric character.

If you use an input mask, you should also define a value mask to remove the punctuation from the stored value.
value_mask A mask used to strip any extra characters that were added by the input mask. This mask ensures that data is stored in the database in the correct format.

To specify a value mask, type the same value entered for the input mask, but type an "x" in place of each punctuation mark. Using the 8-digit input mask described above, you would specify a value mask of DDxDDDxDDD. This strips the hyphens before storing the ID in the database.
create_date The date the system information was inserted into the database. You can specify "sysdate" for this column, or use the variables defined in of the sample script.
create_userid The logon ID of the user who inserted the system information into the database. You can enter the logon ID or use the variables defined in of the sample script.

Step 5: Define Master Person Index Code Lists

You only need to perform this step if you defined any fields in the object structure to have a code module. The SQL script for entering processing codes and descriptions into the database is written in PL/SQL. The wizard creates a stanza incodelist.sql (located under the Database Script node of the project) for each code list you specified in the field properties. You need to customize the file by defining the entries for each code list. This script inserts data into two tables: sbyn_common_header, which lists the types of common table data, and sbyn_common_detail, which lists each common table data element. Before you begin this step, complete "Step 4: Define Master Person Index External Systems".

Note:

The codes you specify in this file can be no longer than eight characters (the codes are the second value in the value list for each common table data type and data element).

To Customize Common Table Data for MySQL

  1. Do one of the following:

    • Under the master person index project in the Projects window, expand Database Scripts and then open codelist.sql in the NetBeans editor.

    • On your computer, navigate to project_home/src/DatabaseScript, where project_home is the location of the master person index project files. Open codelist.sql in a text editor.

  2. Scroll to the first line that begins with "- **** ".

    The statements following this line must be customized.

  3. In the first code list stanza, change "module description" in the first line to a brief description of the code type.

    For example:

    -- ****         PHONTYPE   ****
insert into tCodeList values('L', 'PHONTYPE', 'TELEPHONE TYPE');

  4. Create the entries for that module using the following syntax:

    insert into tCodeList values('V', 'code', 'code description');

    where "code" is the processing code of the data element and "code description" is the description of the element as you want it to appear on the Master Person Index Data Manager windows. For example:

    -- ****         PHONTYPE   ****
insert into tCodeList values('L', 'PHONTYPE', 'TELEPHONE TYPE');
insert into tCodeList values('V', 'H', 'HOME');
insert into tCodeList values('V', 'C', 'CELL');
insert into tCodeList values('V', 'F', 'FAX');
insert into tCodeList values('V', 'O', 'OFFICE');
insert into tCodeList values('V', 'HB', 'HOME BUSINESS');

  5. Repeat the previous two steps for each code list type defined in the file.

  6. If you specified additional code list fields in object.xml and midm.xml after the database scripts were generated, add a new stanza for each new code type.

  7. Save and close the file.

  8. Do one of the following:

To Customize Common Table Data for Oracle

  1. Do one of the following:

    • Under the master person index project in the Projects window, expand Database Scripts and then open codelist.sql in the NetBeans editor.

    • On your computer, navigate to project_home/src/DatabaseScript, where project_home is the location of the master person index project files. Open codelist.sql in a text editor.

  2. Scroll to the following line.

    codes tCodeList := tCodeList(

    The statements following this line must be customized.

  3. In the first code list stanza, change "module description" in the first line to a brief description of the code type.

    For example:

    -- ****         PHONTYPE   ****
tCode('L', 'PHONTYPE', 'TELEPHONE TYPE'),

  4. Create the entries for the module using the following syntax:

    tCode('V', 'code', 'code description'),

    where "code" is the processing code of the data element and "code description" is the description of the element as you want it to appear on the Master Index Data Manager windows. For example:

    -- ****         PHONTYPE   ****
tCode('L', 'PHONTYPE', 'TELEPHONE TYPE'),
tCode('V', 'H', 'HOME'),
tCode('V', 'C', 'CELL'),
tCode('V', 'F', 'FAX'),
tCode('V', 'O', 'OFFICE'),
tCode('V', 'HB', 'HOME BUSINESS'),

  5. Repeat the previous two steps for each code list type defined in the file.

  6. If you specified additional code list fields in object.xml and midm.xml after the database scripts were generated, add a new stanza for each new code type.

  7. In the last code module stanza, make sure each line except the last contains a comma at the end.

    For example:

    -- ****         ADDRTYPE   ****
tCode('L', 'ADDRTYPE', 'ADDRESS TYPE'),
tCode('V', 'H', 'HOME'),
tCode('V', 'B', 'BUSINESS'),
tCode('V', 'M', 'MAILING')

  8. Save and close the file.

  9. Do one of the following:

To Customize Common Table Data for SQL Server

  1. Do one of the following:

    • Under the master person index project in the Projects window, expand Database Scripts and then open codelist.sql in the NetBeans editor.

    • On your computer, navigate to project_home/src/DatabaseScript, where project_home is the location of the master person index project files. Open codelist.sql in a text editor.

  2. Scroll to the following line.

    begin

    The statements following this line must be customized.

  3. In the first code list stanza, change "module description" in the first line to a brief description of the code type.

    For example:

    -- ****         PHONTYPE   ****
insert into @codelist values('L', 'PHONTYPE', 'TELEPHONE TYPE')

  4. Create the entries for the module using the following syntax:

    insert into @codelist values('V', 'code', 'code description')

    where "code" is the processing code of the data element and "code description" is the description of the element as you want it to appear on the Master Index Data Manager windows. For example:

    -- ****         PHONTYPE   ****
insert into @codelist values('L', 'PHONTYPE', 'TELEPHONE TYPE')
insert into @codelist values('V', 'H', 'HOME')
insert into @codelist values('V', 'C', 'CELL')
insert into @codelist values('V', 'F', 'FAX')
insert into @codelist values('V', 'O', 'OFFICE')
insert into @codelist values('V', 'HB', 'HOME BUSINESS')

  5. Repeat the previous two steps for each code list type defined in the file.

  6. If you specified additional code list fields in object.xml and midm.xml, add a new stanza for each new code type.

  7. Save and close the file.

  8. Do one of the following:

Step 6: Define Master Person Index User Code Lists

If you specified a value for the Constrained By and User Code properties of a field, you must define the user code values for those fields. Below is a sample insert statement for the sbyn_user_code table.

insert into sbyn_user_code (code_list, code, descr, format, input_mask, 
value_mask) values ('AUXIDDEF', 'CC', 'CREDIT CARD', '[0-9]{16}', 'DDDD-DDDD-DDDD-DDDD', 
'DDDD^DDDD^DDDD^DDDD');

To learn more about the sbyn_user_code table, see "Master Person Index Database Table Description for sbyn_user_code". Complete "Step 5: Define Master Person Index Code Lists" before beginning this step.

To Define a User Code List

  1. Create a new SQL file to contain the user code SQL statements.

  2. Use the above sample to define a value for the user code drop-down list and the required format for the dependent fields.

  3. Repeat the above step for each drop-down list value and type (for example you might have one list for credit cards and another for postal codes and their corresponding cities).

  4. Save and close the file.

  5. Continue to "Step 7: Create Custom Master Person Index Database Scripts" or to "Step 8: Create the Master Person Index Database Structure" if you do not need to create any custom database scripts.

Master Person Index Database Table Description for sbyn_user_code

The following table lists and describes the columns in the sbyn_user_code database table so you can create SQL statements to insert user code data into the master person index database.

Column Name Description
code_list 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.
code The processing code of each user code element.
description A brief description or name for the user code element. This is the value that appears in the drop-down list.
format 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 Java. Note that the pattern might be further restricted by the value of the input mask described below.
input-mask A mask used by the MIDM 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. If you use an input mask, you should also use a value mask to strip the punctuation for database storage (see below).

The following character types can be used.

  • D - Numeric character

  • L - Alphabetic character

  • A - Alphanumeric character
value-mask 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.

Step 7: Create Custom Master Person Index Database Scripts

You can insert additional information into the database by creating a custom script.

To Create a Custom Script

  1. Create a new text file to contain the SQL statements.

  2. In the text editor, create the SQL script to insert the custom data.

  3. Save and close the file.

  4. Continue to "Step 8: Create the Master Person Index Database Structure".

Step 8: Create the Master Person Index Database Structure

After you create the database instance and customize the database scripts, you can create the master person index tables and insert the custom data.

To Create the Database Structure

  1. Open a standard SQL editor or SQL command line and connect to the master person index database using the user you created in "Step 2: Create a Master Person Index Database and User". For MySQL, you can run the files from the mysql prompt.

  2. Do one of the following:

    • Open create.sql in the NetBeans editor, copy and paste the entire text of the file into the SQL editor, and run the script against the database.

    • From the SQL editor or command line, run create.sql directly. The file is located at project_home/src/DatabaseScript.

      Tip:

      To run this script for Oracle or SQL Server, the command is @create.sql. For MySQL, the command is source create.sql.

  3. Repeat the previous two steps for systems.sql, codelist.sql, and any custom scripts you created.

Step 9: Specify a Starting EUID for a Master Person Index

By default, the EUIDs assigned by the master person index application start with "0", with padded zeroes added to the left to make the EUID number the correct length. For more information, see Oracle Healthcare Master Person Index Configuration Reference (Part Number E18592-01). You can modify this numbering format by changing the value of the seq_name column of the sbyn_seq_table database table where the sequence name is "EUID". For example:

update sbyn_seq_table set seq_count=1000000001 where seq_name='EUID';
Go to previous page
Previous		 Go to next page
Next
Go to Documentation Home
Home		 Go to Book List
Book List		 Go to Table of Contents
Contents		 Go to Feedback page
Contact Us