5 Understanding Data Sources
This chapter contains the following topics:
Data Sources
The data sources define where the database tables reside and where the software runs logic objects for the enterprise. Data sources can point to:
-
A database in a specific location (for example, a local database, such as E1Local located in \E900\data, or an IBM i data library, such as PRODDATA)
-
A specific machine in the enterprise that processes logic
Data source definitions are stored in the Data Source Master table (F98611). Workstations use a Common table F98611, which generally resides in the system data source on the enterprise server. Oracle's JD Edwards EnterpriseOne servers that process logic and request data require their own unique definitions for data sources; therefore, they have their own table F98611 in the server map data source.
A least two sets of table F98611 exist. They reside in a centralized system data source normally kept on an enterprise server which is accessed by workstations, and in a server map data source, which each logic server requires.
Data Source Types
Data sources are the building blocks that you use to set up an enterprise configuration. Data sources define all the databases and logic machines required by the Oracle JD Edwards EnterpriseOne configuration. Each database and machine in the enterprise must be defined as a data source for JD Edwards EnterpriseOne to recognize it.
There are two types of data sources:
- Database Data Sources
-
A database is a grouping of tables in a database management system. You must identify databases to the applications that access them. You can distribute databases across a network and involve various servers and database management systems. A database data source identifies the database information that the software needs to connect to a database.
- Logic Machine Data Sources
-
A logic machine is the machine on which batch applications and master business functions run. You must identify logic machines using a data source definition. The data source definition must include the network information about the machine, such as a server name - HP9000, for example.
When mapping logic objects for distributed processing, the software uses the machine data source (distributed processing data source) as the target location for processing logic objects.
Data Source Names
Data source names that you define are names used to identify the data source. You should use a meaningful name for the data sources. For example, to indicate that you are storing business data for production users, the data source name could be Business Data - Prod.
JD Edwards EnterpriseOne provides demonstration data source names at installation; you can use these for your own data sources.
See JD Edwards EnterpriseOne Applications Release 9.0 Upgrade Guide (for your database and platform).
Data Source Definitions
The data source definition must contain information about the database and the server in which it is located. Different database management systems identify the databases in different ways. For example, you must identify Oracle databases by the Oracle SQL*Net V.2 connect string. You must identify databases that you access through ODBC by the ODBC data source name.
Network Machine/Server Names
Database management systems reside on a machine/server. You must identify this machine/server to the network so that other computers can access its resources. You must provide to JD Edwards EnterpriseOne (in the data source definition) the machine/server name for the machine/server that hosts the database management system in which the database resides.
Required Data Source Types
You must set up a minimum number of data sources for JD Edwards EnterpriseOne to run. Two of the required data sources define machines that process logic in the enterprise. The other data sources define various databases used in the enterprise.
The installation software provides samples of these required data sources to build your system configuration:
- Object Librarian
-
This data source points to the Object Librarian tables you use for custom development. You should have only one set of Object Librarian tables for each software release, regardless of how many path codes (sets of central objects) you maintain. This data source can reside on any supported platform. The Object Librarian data source is named by base release number; for example, Object Librarian - 900.
- System
-
This data source consists of the technical tables you use to run all JD Edwards EnterpriseOne applications. You must set up one system data source per release.
All workstations use a central set of system tables usually stored on the enterprise server but not on the deployment server. Each logic server requires its own subset of system tables. These server system tables are stored in the server map data source.
When running applications, the system tables provide:
-
Object mappings (location of tables, batch processes, and business functions)
-
Data source definitions
-
JD Edwards EnterpriseOne security
-
Next IDs (used for development only)
-
- Data Dictionary by Release
-
This data source enables you to store data dictionary master tables in a central location to enable easier administration of changes. Group these master tables together to form a data dictionary database. You should share one data dictionary between the production (such as PD900) and development (such as DV900) path codes. The software allows one data dictionary per path code, but multiple data dictionaries are not recommended or supported. The Data Dictionary data source is named by base release number-for example, Data Dictionary - 900, Data Dictionary - B7334, or Data Dictionary - B732.
- Local
-
This data source defines the JD Edwards EnterpriseOne workstation. Use this data source to override the process location of a batch application that you mapped in the Object Configuration Manager to run on the server.
- Business Data
-
This data source is used when you divide the business data into multiple owners or libraries, which can reside on the same enterprise server or on different ones. Each group of data requires a separate data source. The installation software provides demonstration data that you can copy to supported host databases. The data source name is Business Data - PS900.
Some examples of business data include:
-
Production data (non technical data, such as financial and manufacturing data)
-
Test data
-
Demo data (demonstration or training data)
-
Conference Room Pilot (CRP) data
-
- Distributed Processing
-
This data source definition contains information that the software uses to identify the logic machine in the network. You need to define each logic machine as a data source.
- Server Map
-
This data source enables you to create for each logic server its own subset of system tables, which are called server map tables. Server map tables are required for each logic server. You must maintain these tables to ensure integrity with the workstation's system tables.
Use Server Map data sources to establish unique object mappings for logic servers. When batch jobs and business functions running on the server request data, they look to the Object Configuration Master and the Data Source Master tables in the server map data source; this is necessary because the mappings are different.
For example, suppose a user logs on to an environment that maps static local data on the workstation, dynamic transaction data to the server, and the master business functions and batch processes to the server. The user enters a sales order and clicks OK to enter the order, which runs the Sales Order Entry master business function on the server. It does not make sense for the master business function to go back to the workstation to retrieve user defined codes and tax information; therefore, the server map Object Configuration Manager table maps all data to the appropriate server data source.
These tables in the Server Map database are unique to a server's perspective of processing:
-
Object Configuration Master (F986101): Provides logic objects processing on a server request data and perhaps other logic objects. When these requests are made to JD Edwards EnterpriseOne running on a server, Object Configuration Master must be accessed to find the correct mappings for the data and logic objects. Servers might have different mapping requirements than workstations.
For example, you should map all user defined codes locally to the workstation for performance during interactive processing. Server processing would require you to map these files locally to a server database to enhance server processing performance.
-
Job Control Status Master (F986110): Records information about batch jobs launched on a server.
-
Job Number Master File (F986111): Records next numbers for batch jobs launched on a server.
-
- Central Objects
-
This data source points to the source objects (central objects specifications), as well as the User Overrides table (F98950). Central Objects data sources are databases.
If you have multiple path codes, each must have a separate Central Objects data source. Developers check objects out of a Central Objects data source for modification. When the developer checks in the objects, the system copies the objects from the developer's workstation to the relational database tables in the Central Objects data source. You must set up one Central Objects data source for every path code needed in the configuration, for example, Central Objects - PD900 or Central Objects - DV900.
You must have a Central Objects data source for:
-
Pristine objects
-
Production objects
-
Development objects
You connect each Central Objects data source to a path code used by the environments that you created for the configuration.
-
- Control Table
-
This data source consists of user defined codes, menus, and next numbers.
- Versions
-
This data source corresponds to the path code, as in Versions - PD900. It stores versions and processing option information. It includes these tables:
Database Structures
All supported database platforms have a similar configuration of tables and data sources.
This diagram illustrates owners and databases for four different platforms:
Figure 5-1 Example of owners and databases structure
Description of "Figure 5-1 Example of owners and databases structure"
Oracle Structure and JD Edwards EnterpriseOne
The basic architecture of an Oracle database includes many different logical and physical storage structures.
Typically, an Oracle database is divided into one or more logical storage structures. The highest-level structures are table spaces and user schema. These structures provide two categories that data may be logically grouped. Data belonging to one table space may belong to different schema, and data for one schema may belong to different table spaces.
- Table Spaces
-
The physical database storage units, data files, are associated with table spaces according to the logical structure of the database. For example, table spaces may be created to separate different categories of data. Table spaces are divided into smaller logical divisions called segments, which are divided further into extents and data blocks. These levels of data storage allow control over how the data files are allocated for physical storage.
- User Schema
-
A schema is a set of objects associated with a user. Schema objects include tables and other data structures used by the database. These objects do not directly correspond to data files stored on the server. Each object's data is stored in one or more data files within a table space. You can specify the space allocated for tables and a few other objects.
- Tables
-
A schema is a set of objects associated with a user. Schema objects include tables and other data structures used by the database. These objects do not directly correspond to data files stored on the server. Each object's data is stored in one or more data files within a table space. You can specify the space allocated for tables and a few other objects.
This diagram illustrates the Oracle structure with JD Edwards EnterpriseOne:
Figure 5-2 Oracle Structure and JD Edwards EnterpriseOne
Description of "Figure 5-2 Oracle Structure and JD Edwards EnterpriseOne"
SQL Server Structure and JD Edwards EnterpriseOne
SQL Server provides a comprehensive platform that makes it easy to design, build, manage, and use data warehousing solutions which enable your organization to make effective business decisions based on timely and accurate information. SQL Server delivers nine separate databases with JD Edwards EnterpriseOne during an installation.
This diagram illustrates the SQL structure with JD Edwards EnterpriseOne:
Figure 5-3 SQL structure with JD Edwards EnterpriseOne
Description of "Figure 5-3 SQL structure with JD Edwards EnterpriseOne"
DB2 for IBM i Server Structure and JD Edwards EnterpriseOne
DB2 for IBM i is the relational database manager that is fully integrated and provides numerous functions and features such as triggers, stored procedures, and dynamic bitmapped indexing that serve a wide variety of application types. These applications range from traditional host-based applications to client/server solutions to business intelligence applications.
In the IBM i system, each file (also called a file object) has a description that describes the file characteristics and how the data associated with the file is organized into records and the fields in the records. The operating system uses this description whenever a file is processed.
DB2 for IBM i installations store all tables in their respective data sources in a single database.
This diagram illustrates the DB2 for IBM i structure with JD Edwards EnterpriseOne:
Figure 5-4 DB2 for IBM i structure with JD Edwards EnterpriseOne
Description of "Figure 5-4 DB2 for IBM i structure with JD Edwards EnterpriseOne"
IBM DB2 for LUW (Linux, UNIX, Windows) 8.1.4 Structure for JD Edwards EnterpriseOne
Every data element in a database is stored in a column of a table, and each column is defined to have a data type. The data type places limits on the types of values you can put into the column and the operations you can perform on them. DB2 for IBM i includes a set of built-in data types with defined characteristics and behaviors: character strings, numerics, datetime values, large objects, nulls, graphic strings, binary strings, and datalinks.
When organizing the data into tables, it is beneficial to group tables and other related objects together. This is done by defining a schema. Information about the schema is kept in the system catalog tables of the database to which you are connected. As other objects are created, they can be placed within this schema.
Each schema has a set of four dedicated tablespaces in which the data is physically stored. IBM recommends that each tablespace be stored on a separate disk drive.
This diagram illustrates the IBM DB2 for LUW (Linux, UNIX, Windows) 8.1.4 structure with JD Edwards EnterpriseOne:
Figure 5-5 Schemas and tablespaces for IBM DB2 for LUW (Linux, UNIX, Windows) 8.1.4
Description of "Figure 5-5 Schemas and tablespaces for IBM DB2 for LUW (Linux, UNIX, Windows) 8.1.4"
Figure 5-6 Schemas and tablespaces for IBM DB2 for LUW (Linux, UNIX, Windows) 8.1.4
Description of "Figure 5-6 Schemas and tablespaces for IBM DB2 for LUW (Linux, UNIX, Windows) 8.1.4"
System Data Source Connections
When JD Edwards EnterpriseOne starts on a workstation, the software attempts to connect to the base data source found in the workstation jde.ini file. If this data source is unavailable, the software attempts to connect to a secondary data source for system information. It is important to have processes for ensuring that the alternate system data source location contains current information. You can maintain an alternate data source's information using table conversion or data replication.
The jde.ini file should look like the example for the primary system data source connection:
[DB SYSTEM SETTINGS]
.
.
Default Env=DEMO900A
Default PathCode=DEMO
Base Datasource=System 900
Database=System 900
.
.
.
Secondary System Data Source connection
[DB SYSTEM SETTINGS - SECONDARY]
Base Datasource=Access32
Object Owner=
Server=
Database=Access32
During installation, the Release Master application relates the system data source to a release. Configuring the release updates the setup.inf file used during the workstation install to create the jde.ini file.
See Also:
-
Major Technical Tables in the JD Edwards EnterpriseOne Guide 9.0 Installation Supplemental Reference.
System Table Caching
When a user firsts logs on, the software uses the user ID and environment to retrieve information from the system tables for that user and environment. This information is cached in memory on the workstation. Any time a change is made to the central system tables, dynamic caching of the system information occurs for those workstations with an active JD Edwards EnterpriseOne session.