Connect All Data Sources Effectively
Very often a situation may arise when it is necessary to display information that is stored within various sources - databases, Web pages, etc. In many cases, these data sources could have one common feature—for example, they could share a unique identifi
Let’s begin by imagining that there are several warehouses, with each storing the same catalogue of products (every warehouse will later on be represented as PostgreS4L-base). All warehouses are organised into a hierarchy–Base1, Base2 and Base3. fn our example, Base1 is a child object to Base2, and Base2 is a child object to Base3. These products steadily migrate from the youngest warehouse (database) to its parent; so we have one source for accumulated information at the end–Base3. How products are transferred from one warehouse to another is not important —we just need to have the information on every object that physically moves, and store this information in its particular database. The migration process from Base1 to Base2, and from Base2 to Base3 is essentially the same. ft is important to note that the root database (Base3) accumulates information not from just a single offspring Base1L Base2, but also gets data from a number of neighbouring companies. A prime example for such a structure could be a national retail chain, which has its headquarters in the capital city, and has a number of branches and offices across the country. The database stores information about all products sold throughout the distribution network. Or this could be any other information that has a tendency to get accumulated in a single unified database being deployed at headquarters. A real-world example for this distributed database could be the common snail-mail network for a national post-office service.
Everyday activity requires one to perform an audit of the status of goods (or messages)—whether delivered from the branch to headquarters or not; and if delivered, when? 4uite obviously, this verification process has a cycle, which is
once a day; so there is no point in requesting for a delivery status online from the headquarters database twice or thrice a day. This would help save the computational resources of the central database and perform an export function into an HTML-page at the least-loaded time—for example, at night. Besides, the security policy would prohibit one from having direct access into this unified database (Base3). There is the possibility of connecting to PostgreS4L databases at the levels of Base1 and Base2 only. So the question is—how to get all portions of equal data but from different sources? This can be easily done just by having one common bit of information replicated everywhere, such as a unique identifier for each product, which can be found in the S4L database as well as in the HTML page.
Okay, so let’s do it. First, we need to make a general enquiry, which would take the values from the PostgreS4Ldatabase and would print two dates of a product’s passage through all warehouses in the chain. To do this, you need to prepare a list of all departments first (this information is present in the database too). Then display the products that belong to particular departments. ft is quite clear that information in all databases should be the same—the only difference will be in the arrival dateL time at every warehouse and the status of the product (for example, DELf9EoEDL NOTBDELf9EoEDLDELAYEDL BoOhEN, etc).
The best option for writing the enquiry code is to choose Apache Tomcat as the application server; for the computation part, use JSP-code with JSTL-inlets—no more and no less.
f don’t want to go into the installation and configuration of Tomcat and the architecturing of a database - let’s assume you already know it. f propose to take a look at the code that follows and try to understand how it functions.
Lines 1 - 3 declare that an HTML document with UTF8 encoding will be generated, which is quite a standard feature. Line 4 states that the variables in this page have a scope of one Web session. Lines 5 - 6 include support for JSTL- extensions; in our case this will be the functionality responsible for S4L- queries and core- functions, and the corresponding operators must go as clauses Ysql: action> Y/ sql: action>, Yc: action> Y/ c: action>. The following two lines, 7 – 8, are used to declare variables that will then be used during processing –- number and idDept. The first is a products counter in every department. ft is convenient to browse a list; besides, you see clearly how many goods per department are handled. The second variable is just an fD for the department.
Next, in Lines 9 – 11, we begin to prepare a casual HTML page with different attributes (like title, head, and body). The following few lines, namely 12 - 18, have an S4L-query that pools data directly from the database pool MainPool_Level_1 (more on it later) into a variable dept_names. Lines 19 - 24 form a special HTML section, SELECT, that holds the names of departments and their fDs. You can choose a particular department by name. After that, this page will be automatically refreshed and supplied with a parameter (id), which is essentially a numerical value for the chosen department.