SeeMoreData Frequently Asked Questions

A reporting applications' performance may be affected by many different kinds of bottlenecks and restrictions. SeeMoreData removes some of these automatically. For example, SeeMoreData uses bind variables (prepared statements) to minimize the need for expensive reparsing of database queries, greatly improving database efficiency. Network compression between the SeeMoreData application server and clients cuts typical response times by 10:1. Pre-spawning and reusing database connections drastically cuts database connection overheads. The SeeMoreData governor automatically terminates long-running queries. Few, if any, comparable reporting applications employ equivalent features.

Second, by allowing developers to write queries in the native SQL for each database, SeeMoreData empowers suitably skilled developers to write well performing queries that take full advantage of the native power of each database - for example, over-riding database optimizer decisions with hints, or fully exploiting SQL extensions such as Oracle's analytic functions (partition over, lead, lag, rollup, cube etc) or SQL Server's 'top N' function, PL/SQL constructs and Transact SQL..

Dynamic parameterized conditions mean that if all the values from a parameter list are selected, the condition is simply dropped in the SQL being sent to the database, so that there is not a long list of IN values in the subquery. This improves database performance by leading to simplified query execution plans.

SeeMoreData caching is the most advanced in the BI industry. SeeMoreData can have user-specific caches for user-specific data and also generic caches. The cache retention and expiration is highly configurable, allowing the Administrator to set the cache expiration from as little as 1 minute to as large as 365 days. There is no theoretical limit to the server cache size.

SeeMoreData is not a Data Warehouse solution. Data warehousing solutions may potentially be used for more than reporting. For example, such solutions may allow users for perform complex 'what if' analysis from other applications and the storage of large volumes of historical data. SeeMoreData is suitable for the more immediate needs of OLTP type databases, though it could be equally suited to generate reports based on DW summary tables.

However, if you are thinking of implementing a data warehousing solution just for reporting, you may well be able to achieve a similar result with far less overhead by using SeeMoreData.

A SeeMoreData developer can define "data objects", each of which represents the result of a specific query run against a specific data source. These data objects then become reusable data components, similar to Data Beans, and each component can be reused by other reports or queries.

The developer can then write another SQL query that joins and selects information from multiple data objects.

Each data object may be cached. Alternatively, the query associated with each data object may run each time the data object is evaluated thus returning real-time information.

Administrator training is 1 day.

Developer training 1 ˝ days. The only skillsets required to be a successful developer is a knowledge of the corporate data model and a reasonable proficiency in SQL.

Any email client. Reports are email-able from inside SeeMoreData. Moreover, the users can annotate the report itself, thus adding intellectual value to reports as they are passed higher up the chain of command within the organization. At the time of email dialog, the user can decide whether the email is to be sent as an attachment (PDF, Word, Excel, CS, HTML, XML) or as a zipped file or inline (where MIME types allow).

There is theoretically no limit to the number of drilldown levels in SeeMoreData. On a practical note, very seldom has a need for more than 8 levels ever been required.

SeeMoreData Developer and Power User interface has a built-in query generator, (GQD, which is short for Graphical Query Designer). GQD allows you to create queries in a drag-and-drop fashion, choosing the columns you want to include in your query with the ability to evaluate the query on a sample set of rows

It may be that the underlying structure is very complex and the joins are not straight forward and really requires an expert in SQL and data modelling to be able to create the joins. In this case, a developer or such an expert could create a view in the database or in the case where database access is restricted (as all production environments should be), then a materialized view can be created in SeeMoreData as a data object, which would reduce the complexity and present a 2-dimensional structure, with rows and columns (like a spreadsheet) and then you are able to select the attributes and measures you want to see in a report from this structure.

However, regardless of the approach, you are not absolved from having to know the data model, of at least the simplified Data Object. In other words, you must know what data is contained in the columns and how it relates to your business.

Yes. Absolutely !

To support on-the-fly pivot analysis or freewheeling X by Y by Z graphic analysis and exploration by the user at runtime, the only effort required of the developer is to write a query that returns data and measures that are capable of being analyzed.

Most conventional queries do this as a matter of course.

While developers have the option of defining default pivot analysis settings at design time, it is not necessary to do this in order to make pivot analysis functions fully available to users at runtime.

No Problem !

SeeMoreData has the ability for each customer to define their own Java functions and to load these functions into the function library that is available to all reports

To invoke these functions during report design, the developer can use the function type field format on the relevant report/s.

None ! SeeMoreData does not need to duplicate / replicate any information or transform it. Usikng SQL / MDX / XQuery, most information can be retrieved from its source. If real-time access proves to be disadvantageous to the online community, then the report / data objects can be cached and the refresh of these caches can be scheduled overnight.

SeeMoreData developers can write queries against data sources such as databases or spreadsheets using whatever flavor of SQL is appropriate for the data source concerned, taking advantage of all RDBMS-specific SQL enhancements.

The results of such a query may be passed directly to the SeeMoreData display engine, or may be stored internally in an SeeMoreData "data object".

Subsequent queries against an SeeMoreData "data object" must employ standard ANSI-compliant SQL.

Yes. SeeMoreData supports Netscape, Novell, Sun One and MS Active Directory LDAP services.

SeeMoreData also has internal security in the way of privilege groups. Reports are made part of one or more privilege groups. Users also are granted one or more privilege groups. At run-time, a user can only see the reports that belong to the same privilege groups that he / she has access to.

For users who access SeeMoreData via a standard web browser, SSL is an option on the Java Servlet container.

People often execute queries against live OLTP systems. When these queries are either poorly written for performance, or the user is analyzing vast quantities of data in real-time against a live OLTP system, this can have the effect slowing overall response for mission-critical applications. SeeMoreData has been written to accommodate for that, and gives the Administrator the right to determine at a system-wide level and with individual user overrides, how long queries can run for at various times of the dat, and the governor can be set.

The governor has two thresholds, the warning threshold and the timeout threshold.

Say the Administrator decided that anyone running a query in production between the hours 9 a.m. and 4 p.m. will be given a warning message after 10 seconds, giving the user the option to kill the query. However after 30 seconds, the timeout threshold is reached. This means that anyone running a query that takes more than 30 seconds will have the query automatically terminated by SeeMoreData Governor (server based) in the relevant datasource.

Certain users may be privileged users and require higher thresholds than the rest of the users. The Administrator can create special timeouts for these users for different times of day that would override the general environment-wide governor settings.

No.

SeeMoreData ROS (Remote ODBC Service) extension which acts as a local SeeMoreData agent on the host that contains the data, supports this requirement. Moreover, the data is sent back to the SeeMoreData via a compressed, encrypted delivery method, using sockets instead of http, thus making the data far more secure, and reducing network bandwidth and not requiring the actual data (spreadsheet, Access DB, etc) to be exposed on a shared network drive.

SeeMoreData has full report audit logging, showing who ran which reports, when, who emailed which reports and to whom, what changes were made in the reports repository, by whom, when.

SeeMoreData also keeps its own logs of the which reports took how long to run and the their completion code, so that tuning opportunities are immediately visible to reports developers and Administrators.

Yes, it could to some extent.

However, the SeeMoreData governor does automatically protect databases from long running queries, terminating these after a set period.

The behaviour of the governor is fully configurable by user and time of day.

SeeMoreData' three tier client server architecture makes the application highly scalable.

Both the SeeMoreData application server and data repository (SeeMoreData' own database) may be readily scaled as necessary.

Yes.

The use of network compression between the SeeMoreData interactive browser client and the SeeMoreData application server mean interactive use of SeeMoreData is feasible over quite slow network connections.

Where network connectivity is available only intermittently, users may order and access reports via email using a menu driven email interface.

Yes.

SeeMoreData can automatically send personalized reports to users that contain only the information that is relevant to each user's needs.

For example, SeeMoreData can automatically email a weekly report to each cost centre owner that lists only items for that user's cost centre.

Yes.

SeeMoreData can publish report information through user-defined HTML Templates, PDF templates or XSL Style sheets.

This makes is possible, for example, to include report information in documents such as pre-designed web pages or PDF documents such as certificates.

SeeMoreData runs as a Java Applet and very basic JavaScript for main clients ( Admin and Reporter), although we also have JSP based client for reporting part or to integrate with other software.

From SeeMoreData Client to Server there is an HTTP connection, and from server to database we use JDBC in most cases. SSL is an available option, though usually encouraged in a high concurrency situation only with the inclusion of an SSL hardware accelerator in the architecture.

Java Servlets.

SeeMoreData is fully J2EE compliant application that currently runs on one of:
• Apache Tomcat
• WebLogic
• JBOSS
• JRUN
• Web-Sphere
• Sun ONE
• Oracle Application Server
• SAP WAS
• IIS (kind of, since IIS is not a J2EE compliant web server, but can be easily integrated into a servlet container)

SeeMoreData uses various level of caching, including:
• "Caching on Client"
• in-memory caching of data as Java Object
• caching of data in temp database tables
• caching of data in file system

Various type of caching can be controlled by configuration parameters and in the report definition which is stored in the central repository.

SeeMoreData has a very sophisticated level of caching control, probably the most advanced in the BI industry.

There are 3 types of users in SeeMoreData:
• Administrator
• Developer
• Reporter (end user / report consumer).

Administrator users define roles / privileges. Reports are grouped into 1 or more privileges. Users can have 1 or more privileges associated with their logins, and access to reports is limited by the privileges that the reports and the end users of reports have in common. Thus a user can only see and execute the reports that their privilege/s allow them to see.

SeeMoreData performance when executing real-time query based non-cached report, depends on Database performance. SeeMoreData is J2EE compliant so it can be deployed on any commercial J2EE app server like WebLogic, Web-Sphere, etc. Tomcat is pretty stable and can handle easily 100 concurrent users on a reasonably powerful server (2 X P4 CPU @ 2.0 GHz with 2 GB RAM).

When query results have been cached in SeeMoreData, the call to the database is avoided, thus, for cached reports, only the first call to populate the cached SeeMoreData cache is dependant on database performance, thereafter, for cached queries that are executed within the cached dataset’s validity period, no call is made to the database, which can often have dramatic performance improvements.

For instance, of there are 400 users all needing to access week-to-date (up to COB previous day) information several times per day, it makes sense to let the scheduler run a process to populate a server-side cache, which is set to expire at the end of each day. This way if 400 users require information from this report 10 time per day each, the caching mechanism has just saved 4,000 database queries (actually, 3,999 since the first query will populate the cache). This saves strain on the database.

Database queries are executed once per report call. Thereafter, all interaction with the report happens on the client applet and no more calls are made to the database. This is for things such as filters, Pivot Analysis, Analytical Explorer, Layout interaction, sorting, annotating, summarization.

SeeMoreData’s architecture is such that WAN / Internet response times and speeds are very similar to LAN speeds. Upon login, the cached local jar files are interrogated to see if there is a different (newer) version on the server, and with a ‘server-wins’ logic, the relevant applets are loaded either from the server or from local java cache directories.

With built-in network compression, large datasets are compressed first at the server side and uncompressed at the client, to save network bandwidth and end-user response time.

Thus if a 1 MB dataset (absolutely gigantic report) that resulted from a query is sent across a 256 KBPS WAN / Internet link, this would take at least 35 seconds to transmit, assuming the entire 256 KBPS bandwidth was available. However, using the built-in network compression, the 1 MB dataset would be compressed to about 80 KB in 0.2 seconds, transmitted across the WAN / Internet in about 3 seconds (assuming once again that the entire 256 KBPS bandwidth was available to this process) and then uncompress on the client in about 0.2 seconds. Thus the total transmission time would be 3.4 seconds, as opposed to 35 seconds, and the total amount of network traffic sent would be 80 KB instead of 1 MB.

Thus, SeeMoreData is the ideal solution for strained networks / WAN / Internet environments, since it has the built-in network performance enhancing mechanism combined with intelligent caching on both client and server.

SeeMoreData’s philosophy is that even though cosmetic aesthetics might sell a solution, it is performance and keeping TCO down by enhanced built-in performance that will keep a solution in place in modern business where data volumes just keep growing and complexity keeps increasing.

SeeMoreData is designed by an Oracle DBA with years of performance tuning experience. SeeMoreData complies with the Cary Millsap - Hotsos tuning methodology that states that end user response time depends on the sum of actions by the application, network, database, O/S and storage components, thus tuning should concentrate on overall response times, not just particular isolated components of it

SeeMoreData’s repository resides on Oracle 9.2 or above. The reason for this is a significant part of the SeeMoreData engine is written in PL/SQL, which only runs on Oracle. There are various reasons for why PL/SQL is the chosen platform, including robustness, speed (as it executes inside the database itself), seamless transportation across database host operating systems, native support for hierarchical queries and the ability to wrap the source code easily.

More to the point, in November 2005, Oracle released Oracle XE (Express Edition), which can be distributed at no charge, with some restrictions. What this means for SeeMoreData is that the limits set by Oracle XE will probably constrain the average implementation to about 200,000 reports and about 300 concurrent users (with a 5% average concurrency formula, that means about 6,000 users). Once these limits are exhausted, you will need to upgrade to Oracle Standard Edition, at which time our support team and sales force would help you to find a way that will not impact you financially, to achieve this upgrade.

SeeMoreData Profiles allow the Administrator to disable / enable certain functionality. The users are then granted 1 profile and via the profile, certain end-user functionality can be disabled for some user yet left enabled for others, or vice verca.