Clairification on two DAI concepts & terms

[Bob Cergol]

I downloaded the server edition and docs this morning and am scouring them to learn as much as quick as I can. I need some help understanding DAI's meaning of: relations, partitions.

Relations
The doc says: Using defined relations Dynamic AI offers the possibility to integrate and
relate information across several defined Dynamic AI database connections.
Relations can be defined e.g. between a customer table in an Oracle Database
located on a UNIX database server and a file-based Microsoft Access Query
with order data located on a shared local area network drive.

Later it says: If a number of reports and listings are created on the same data-source, it will
in many cases be the most efficient solution to define a relation between the
data-source and the data-source itself. It then shows relating the same connection/table/field specification to itself.

Also, I'm wondering if defining relations in DAI is somehow analogous to a DDO structure in a VDF view.

Partitions
Does the "partition" feature discussed in data dictionaries refer to SQL's physical table partitioning -- or is it a kind of virtual view of a subset of data within a single table?

Thanks for your time in answering.
Bob

[Carsten Sørensen]

Hi Bob,

Relations:
Relations in Dynamic AI terms is a "front-end" type relation - allowing us to mix information from any data-sources. However with the limitation that the links can only be viewed - i.e. not merged or manipulated as one source. E.g. If you have customer ID in a table on a SQL Server - a Dynamic AI relation can help you to relate the Customer ID content from the SQL Server to e.g. an Order system on Oracle - by using the SQL Server Customer ID as a criteria for the jump to the Oracle data.

This can be achieved as part of a drill down on a report where the Customer ID can be used as a drill-down criteria - OR - as a link to a FORM. E.g. The SQL Server Customer ID can be part of a report ending up in a detailed listing where clicking to the Form can then bring the Customer ID as a criteria for showing Oracle order data for that particular Customer ID. Finally you can also insert related sub-forms which is probably the most useful way of using relate - where you can browse the Customer data on one database and display sub-forms of reports from other data-sources using the related ID as a criteria.

I believe the documentation refers to the fact that you can also relate a data-source to itself - in order to force Dynamic AI to use a specific ID as a criteria for displaying form data. That is the most efficient way instead of scrolling the underlying data-set for form-data (can be relevant on large datasets). Dynamic AI however offers other ways to do this nowadays - such as using a "forcedsort-key" in the dictionary and I believe we also support the use of a unique key (conditions page) to achieve the same results.

Partitions:
Partitions where originally used solely to have one report point to time-partitioned data-sources based on the user selecting a partition-value from a drop-down filter. E.g. If you have daily "as per" balances in separate data tables like GL20090101, GL20090102 etc. partitioning in Dynamic AI would support the inclusion of the physical tables matching a user-selected parameter when e.g.: producing a Profit and Loss statement, a balance sheet etc. This can be a fast optimizer for large data-sets that grows over time and makes a database table unnecessary slow - and it eliminates the need for sophisticated DB partitioning features. Some call it "poor man's partitioning"

The functionality to replace a value in the underlying SQL to a report - what we in this case call partitioning - can however also be used to restrict subsets of data within a single data-source (or even across multiple data-sources eventually using partition p1,p2,... parameters) as you mention. As the partitioning table options available to the end-user can be dynamically created / restricted / computed - the combinations of it's use are almost "unlimited".

Best regards
Carsten

[Bob Cergol]

Carsten,

Thanks, I think I had the gist of it correct, and your elaboration confirms this is a fairly sophisticated topic for advanced use.

Defining relations within the same connection does remind me of a DDO structure in a VDF header/detail view and as a parent header record was found, the detail grid would be constrained to the child data.

After reading the docs on that and mulling it over I also informed our management here that we could use Dynamic AI to integrate information views into disparate systems we have -- for example Solomon Accounting, ProMail Fulfillment -- and our Paradigm production mgt. system. We could allow one of our customers to see their invoices, manufacturing orders, and fulfillment inventory all in one "view"! Amazing.

Bob

[Eddy Kleinjan]

Hi Bob,

You could compare this to creating a Data Dictionary Object (DDO) structure in a way. Setting up relationships between data sources in Dynamic AI can however be better compared to setting up relationships between views. When such a relationship is defined, it allows you to 'jump' from reports based on one data source to report based on the related data source.

The ability to show report from various data source, which might be different database systems, can also be filtered on so called 'alias' values that are bound to a logged in user. The alias values can be used in many places within Dynamic AI, for example, as a filter on reports (customer_id = @alias1).

That way you can create dashboards and reports for various users who will see all of _their_ relevant data, but automatically filtered to only show their data.

Best regards,
Eddy Kleinjan

[Bob Cergol]

Hi Eddy,

Thanks, that helps sharpen my grasp of the concept as used in DAI.

I picked up on the alias parameters as soon as I encountered the first mention in the docs. And I had asked Fern at DAW before I even downloaded the personal edition if I could pass a parameter to constrain data per logged in user. So I'm very happy with that capability. I informed our management that this tool would allow us to create personalized portals for our customers after I scanned through the section on style sheets, etc. in the administrator docs. I'm looking forward to careful study of the whole manual. I want to absorb as much as I can as fast as I can on this product so when I start in earnest to craft a prototype system after the holidays I will be doing it with the right foundation to support all the things I have in mind to build on top of that foundation.

Which reminds me .... is there any way to rename a connection? Is the name the internal connection ID or is that name assigned an internal connection number. I already know I can edit all the parameters of the connection ID itself.

Bob

[Carsten Sørensen]

Hi Bob,
The connection ID can't be renamed. We can do it for you in the background repository if needed.
Best regards,
Carsten