InterSystems IRIS BI (DeepSee) is a Business Intelligence (BI) technology that enables the real-time analysis of transactional data, and is designed to be optimal for embedding within transactional applications.
Easily transform a CSV file into a personalized preview of DeepSee - InterSystems BI
AnalyzeThis can be found on InterSystems Open Exchange. Use the Download link to navigate to GitHub and begin installing the project. Follow the “Installation” section of the GitHub README.
I am planning to implement Business Intelligence based on the data in my instances. What is the best way to set up my databases and environment to use DeepSee?
In part 1 we started working on a security model for DeepSee and create a user type having privileges typical of end users. In this part we are going to create a second user type with ability to edit and create DeepSee pivot tables and dashboards.
I have a few cubes and numerous dashboards and I am ready to deploy them to our end users and administrators. How to configure DeepSee so that users don’t disrupt each other’s areas and are restricted from using functionalities specific to developers?
The following post outlines an architectural design of intermediate complexity for DeepSee. As in the previous example, this implementation includes separate databases for storing the DeepSee cache, DeepSee implementation and settings. This post introduces two new databases: the first to store the globals needed for synchronization, the second to store fact tables and indices.
Users of analytical applications often need to generate and send out PDF reports comprised of elements of the analytical panel. In the InterSystems stack, this task is solved using the DSW Reports project that is an extension of DeepSeeWeb. In this article, we will explain how to use DSW Reports for generating PDF reports and emailing them.
The following post outlines a more flexible architectural design for DeepSee. As in the previous example, this implementation includes separate databases for storing the DeepSee cache, DeepSee implementation and settings, and synchronization globals. This example introduces one new databases to store the DeepSee indices. We will redefine the global mappings so that the DeepSee indices are not mapped together with the fact and dimension tables.
Any election is a highly mysterious process, and when you look at its results, the overall picture is not quite clear. I decided to put them, region by region, on the map of Moscow using InterSystems technologies that offer both storage and data analysis functionality. In this particular case, I used InterSystems Ensemble, a platform for application development and integration, but you can also build this solution using the multi-model InterSystems Caché DBMS, as well as InterSystems’ new product called IRIS Data Platform.
The source class of a DeepSee cube has a property referencing a different class:
Class ClassA Extends %Persistent {
Property P1 As ClassB;
}
When records in class B change, the ^OBJ.DSTIME global for Class A will not be automatically updated. This means that synchronization of cubes based on source class A will not reflect the changes occurred to property P1. This post will help you determine the best way to achieve synchronization of properties referencing a different class
I was approached recently by and end use who wanted to perform analysis of their databases and see how they could save some space by picking data good for deletion without harming the application. As part of investigation, they wanted to know sizes of globals within datasets. This can be achieved by various means but all of them provide data in text form only.
I thought I might be a good tool for database administrators in general - to see global sizes in a graphical way.
The following post is a guide to implement a basic architecture for DeepSee. This implementation includes a database for the DeepSee cache and a database for the DeepSee implementation and settings.
By design, DSW provides an implementation for every widget in DeepSee library. But there are some extra features in DSW which make solutions built with DSW dashboards more functional. This article describes it.
In part 1, part 2, and part 3 parts of this series we set up three user types. In part 4 we saw how to secure model elements and DeepSee items. In this last part of the tutorial we conclude with some remarks on DeepSee security and troubleshooting tips. In particular, we see how pivot tables in User Portal can be "hidden".
In part 1, part 2, and part 3 of this series we set up three user types. In this part of the tutorial we see how to secure model elements (such as DeepSee cubes) and DeepSee items (such as a folder containing pivot tables and dashboards in the DeepSee User Portal).
In part 1 and part 2 of this series we set up two user types, simpleuser and poweruser. In this part of the tutorial we create one last user type having privileges typically needed by an administrator/developer in analytics.
By update
