In the case of Argos, any task a user performs is based upon a DataBlock. Any form you design, any dashboard you build, and any report you run will be done within the scope of a particular DataBlock. But even though DataBlocks are the starting point for everything an Argos user does, defining what a DataBlock actually is can be surprisingly difficult.
So, what is a DataBlock, really?
A DataBlock is just a word we basically made up. Argos allows you access to your data. A block can be a lot of things, but we use it here in the programming sense: “[a block is] a group of declarations and statements treated as a unit” (definition from Wikipedia). DataBlocks can contain an abundance of information or none at all. They can include a complex array of forms, objects, and reports (more on this in a moment), or they can consist of a single, simple query to return one specific data set.
The easiest way to understand the role of a DataBlock is as a container. Every time an Argos user creates a new DataBlock, they’re essentially creating a new, empty box. By adding objects—which are used to define the data returned to the DataBlock—users “fill” the box by displaying data from their institution’s databases or data warehouses. Users can also design forms that include elements like charts, OLAP cubes and multi-column lists to display the data. They can also generate reports based on the data returned, which can be printed, distributed, and exported. Since every institution has a variety of departments, each with different reporting requirements, DataBlocks can be used to present relevant data in a way that suits a particular department’s needs.
Guide to key DataBlock elements
When designing a DataBlock—the form design is used to create individual “pages” for the DataBlock, and the report query contains the SQL query that allows end users to generate reports using the data returned. Report writers can design one or more reports. The dashboard allows users easy access to all forms and reports. These four elements make up the anatomy of your average DataBlock.
Below is a little more detail on the role of each element:
The dashboard is the control panel for the DataBlock, providing end users with a visual interface to all the pieces of a DataBlock. Uses can constrain and interact with the data being returned. Dashboards are made up of all of the forms, reports, control objects, graphics, OLAP cubes, and any other visual elements the DataBlock designer wants the end user to see. Dashboards also include controls that allow users to save their variable selections for future use.
The report query is the part of the DataBlock which contains the SQL statement to return the desired data. Typically, the SQL refers to objects on the forms to gather input from the end users. While not every DataBlock requires a report query, if the end user wants to produce any kind of report, the DataBlock must have a report query. Although DataBlocks can include many reports, they will only have one report query.
Forms make up the individual “pages” of the DataBlock’s dashboard. Forms typically include variables, which collect input from the end user. When an end user chooses a value for a particular variable, it constrains the data returned. Forms can also contain visual elements to display Charts, OLAP cubes, data lists, graphics, and other visual elements can be added to forms to visually represent the data, making it much easier for the end user to interpret.
Reports Generated using the data returned by the report query, reports are the final product of the DataBlock. They can be used to present the data outside of Argos—on paper or in a file. Banded reports allow end users to design formatted reports with groupings and subtotals. Users can print banded reports directly or email them as PDF files. Comma-delimited and extract reports deliver the data in various file formats, making it possible for users to easily work with the data outside of Argos.