All posts in “Uncategorized”

Neo4j Northwind Traders Database Schema

Graph Databases: Loading Data with Neo4j

Graph databases are becoming more popular as a way of storing and analysing large connected datasets.

Neo4j is a popular Graph DBMS because of its powerful querying language: Cypher and its growing community and excellent supporting tools.

A new paradigm comes with a new set of challenges. In this case we are focused on the challenge of creating a data pipeline to load data into Neo4j, thinking about how we might design our schema and how we might query it.

Today, we’ll take you through an ETL of The Northwind Traders Sample Database and some of the things we can do with Cypher that makes it special and worth a look.

We’ll be using Kettle to orchestrate our ETL and making use of the Neo4j Output Plugin to help us interact with our Neo4j server. We’ll also load the same dataset to PosgreSQL, to see how the two technologies compare.


Environment Setup

The installation of Kettle, Neo4j Output Plugin and Neo4j server is outside the scope of this post but it is important to note that the connection is not stored in the transformations as they usually are. It’s stored in the metastore which is found in your home folder. For that reason, you’ll have to create a new connection before you can load data into Neo4j.

Create connection is available the Neo4j Menu of Kettle
Neo4j Connection dialog allows you to add a connection to your metastore

Once you can test your connection you are good to go, just make sure the connection name is local-hardcoded so that you don’t need to change any of the transformations provided at the end of the post.

To set up your PostgreSQL connection you’ll need to edit the conf/kettle.properties files with the correct details for your connection. This will change the connection for each of the transformations and the main job as we have parameterised the connection for your convenience. If you do not have a password you can remove everything after DATABASE_PASS from the file and it will work fine.

With that out of the way, let’s get started with Northwind.


Northwind Traders Database

The Northwind Traders database is a sample database that comes with Microsoft Access. The database contains sales data for a fictitious company called Northwind Traders.

As you can see it represents an OLTP focused on parts of orders.

We will be using a version of Northwind compiled by Neo4j as csv files, available on GitHub, which is more or less the same as the original and the image above.


Loading Data

The ETL we have created is relatively simple; there is a single job, RUN.kjb, that runs, in sequence, the transformations that load nodes and relationships into Neo4j from the csv files.

Similarly, there is a single job for loading into Postgres; one important difference is that for Postgres we must create our dimension and fact schemas beforehand using SQL create statements. In Neo4j this is not necessary because graph databases are schema-less.

We’ll be using the Neo4j Output step to create nodes and relationships and the Neo4j Cypher step for lookups.

The sequence of steps below shows a common pattern to ensure that poorly delimited and enclosed csv files produce the expected columns and rows:

Handling poorly delimited files in Kettle

Address Nodes

Addresses occur often within Northwind: suppliers, customers, shipment receivers and employees all have addresses. For that reason we have tried to create a generic way to link an address, an actor that allows for performant geographic queries.

Rather than have addresses and their components (country, region, city, postcode, street and building name) stored as a property for each customer, supplier, etc. each address is stored as its own node. Each address node is linked to a city node and each city to a region and so on; this creates a hierarchy, using composite keys to make sure the same region isn’t linked to two countries. The result of this is easier indexing which speeds up queries because searches on nodes are faster than searches on properties.

Producing nodes and relationships from a table of addresses in Kettle

After we have collected all the addresses from all the files, we remove duplicates and replace any null regions (some countries have only one region, which is null) with the country name. We create the region nodes and link them to their appropriate country node, do the same for cities -> regions and addresses -> city nodes. 

We now have a more efficient way to query locations and slice our data. 

Example address heirarchy in Neo4j Browser

Relational Addresses

In Postgres we need to do little to get addresses into our dimensions. If it wasn’t for other complications such as poorly delimited and enclosed csv files and replacing null regions it would be as simple as table input -> table output. This is because each address is stored in the same dimension as the other information for that actor, i.e. customer addresses are stored in the customer dimension.


Date Nodes and Date Dimension

Creating date nodes in Kettle

Creating date nodes is identical to any date dimension that you have created in the past except that you are creating nodes instead of rows. The result is a node with many properties that allow you to query in a variety of ways without having to do on the fly date operations:

Date node properties in Neo4j Browser

In PostgreSQL, we populate our date dimension with the same fields as in Neo4j but each date is a row not a node.


Order Nodes and Relationships 

In our graph, order nodes are the most connected node; you could compare this node to a fact table that contains no additive fields (also known as a factless fact table)

Joining orders.csv and order-details.csv in Kettle

We start by joining order-details to orders so that we can create all the nodes and relationships we want in one go.

Date and shipment receiver node lookups in Kettle

Next, we do some lookups on previously created nodes so that we can link the order nodes to date nodes and shipment receivers.

Creating order nodes and the relationship between products before grouping in Kettle

Calculate totals from unitPrice, discount and quantity; this reduces query time because values are precalculated. Create our order nodes and their relationships to products (remembering that the CONTAINS_PRODUCT relationship uses part orders coming from order-details.csv

Define the CONTAINS_PRODUCT relationship and its properties in Kettle

All the additive fields apart from freight are stored in our CONTAINS_PRODUCT relationship between Order and Product nodes. This is the most logical location to store these properties unless we wanted to create a Part Order which would only increase traversal and reduce performance of queries.

Creating relationships between orders and many other nodes in Kettle

Finally, we create all the relationships between our order nodes and the other nodes we created before using a sequence of Neo4j Output steps.

Define the SHIPPED_TO relationship and its properties in Kettle

It’s worth noting that we store our freight costs, another additive field, in the relationship between the Order and ShipmentReceiver: SHIPPED_TO. This allows us to maintain additivity without introducing complications surrounding the freight field as you will see later on.

The schema we have created looks like this:

“call db.schema()” in Neo4j Browser

Part Fact Orders

In PostgreSQL, we still join orders to order details to get part orders; however, we must isolate a single freight value for each order so that freight is additive. Some of the options here are:

  • Split the freight evenly between the products contained in an order.
    • This is misleading as packaging and shipping costs are usually dependant on size and/or weight of the package so we want to avoid splitting evenly.
  • Split the freight proportionately between the products contained in an order.
    • This is the ideal scenario but it is not possible because we do not have weight or size information for the products, unfortunately.
  • Store freight with only a single part order.
    • This is the compromise we chose as it maintains the additivity of the freight field and is less misleading.

As you can see, all options mean we cannot do analysis of freight costs per product. 

We accomplish this using a changing sequence and a javascript calculation.

Remove freight from all but the first row of an order in Kettle

Relational data warehouses depend heavily on surrogate keys to join facts to dimensions. For each dimension we have created a sequence for this purpose. 

When we create the fact table we lookup these sequences so we can add them to the fact table. This is a distinct difference between Neo4j and relational databases as Neo4j manages its own keys to identify which relationships are connected to a given node.

Dimension lookups in Kettle

Finally, before loading to the table we create a sequence to be the primary key for the fact table.

Add a primary key sequence before table output in Kettle

Querying

Let’s look at how we can query our newly created databases.

Value of sales for each year from customers in the USA

In Cypher:

MATCH (p:Product)<-[r]-(o:Order)--(:Customer)--()--()--()--(c:Country)
WHERE toLower(c.country) = "usa"
WITH o AS order, c.country AS country, r AS rel
MATCH (order)-[:ORDERED_ON_DATE]->(d)
RETURN 
  country, d.calendarYear AS year
, count(DISTINCT order) AS number_of_orders
, apoc.number.format(sum(rel.netAmount), '$#,##0.00', 'en') AS 
  value_in_dollars
ORDER BY year ASC

In PostgreSQL:

SELECT
  customers.country AS country
, dates.calendar_year AS year
, count(DISTINCT orders.order_nk) AS number_of_orders
, cast(sum(orders.net_amount) AS money) AS value_in_dollars
FROM
  public.fact_part_orders AS orders
, public.dim_customers AS customers
, public.dim_date AS dates
WHERE orders.customer_id = customers.customer_id
AND   orders.order_date_id = dates.date_id
AND   lower(customers.country) = 'usa'
GROUP BY country, year
order BY year ASC;

We can refactor our schema to include direct relationships between orders and cities, orders and regions, orders and countries, giving us a quicker way to retrieve the same results. After you do this the matching pattern changes from (p:Product)<-[r]-(o:Order)--(:Customer)--()--()--()--(c:Country) to (p:Product)<-[r]-(o:Order)--(c:Country) and the performance boost would be significant as there are less hops to traverse and fewer searches to complete. 

Products most likely to be bought together

In Cypher:

MATCH 
  p=(original:Product)--(:Order)--(related:Product)
WHERE
  toLower(original.productName) = "teatime chocolate
  biscuits"
RETURN
  DISTINCT original.productName AS product
, related.productName AS most_likely_to_be_bought_with
, count(p) AS popularity 
ORDER BY
  popularity DESC
, most_likely_to_be_bought_with DESC
LIMIT 5

In PostgreSQL:

SELECT
  original.product_name AS product
, related.product_name AS most_likely_to_be_bought_with
, count(r_orders.order_nk) AS popularity
FROM
  public.dim_products AS original
, public.dim_products AS related
, public.fact_orders AS o_orders
, public.fact_orders AS r_orders
WHERE 
    original.product_id = o_orders.product_id
AND o_orders.order_nk =  r_orders.order_nk
AND r_orders.product_id = related.product_id
AND lower(original.product_name) = 'teatime chocolate biscuits'
AND lower(related.product_name) <> 'teatime chocolate biscuits'
GROUP BY
  original.product_name
, related.product_name
ORDER BY
  popularity DESC
, most_likely_to_be_bought_with DESC
LIMIT 5;

Isn’t that a mouthful.

This type of query has become common in online shopping; the shop will recommend products based on what you are looking at or what you have in your cart.

As you can see in Cypher the Products most likely to be bought together query is more compact. Importantly, this makes querying far less error prone; accidentally running a cross-join because you forgot a join condition can go unnoticed and be very costly.

In SQL, fewer joins will lead to the best performance, especially when your fact table has several billions of rows (or you’re joining the fact table to itself like we are here). Neo4j does not have the concept of joins because there are no tables. Graph queries are easier to write, read and modify which is why recommendation queries work well in graph databases.


Improvement Strategies 

This schema is a good start and allows us to think about how to use Neo4j to analyse our data. In loading the data into Neo4j, we have come up with new ideas that have not been implemented as of yet.

Firstly, aggregation nodes could be a useful way to query old data quickly by storing pre-calculated values for later; these nodes play the same role as aggregation tables do in a relational database. In a schema-less model, we can add new nodes easily without building new tables making aggregation a valuable strategy.

The most simple version of this is to calculate the total value of an order and store it in that order, this should improve query time.

We can create these nodes on several aggregation levels, e.g. Yearly Sales, Monthly Sales, Daily Sales, etc.

There is also a possibility of creating geographic aggregation nodes, e.g. USA Sales, London Sales etc.

Separating date nodes into year, month and day nodes is another strategy; this should allow performant querying for specific years and months as a search through all properties of date nodes is not necessary.

Finally, creating a LinkedList between nodes of the same type may prove to be valuable. For example, (:Year)->[:NEXT_YEAR]->(:Year) allows you to compare one years sales to the previous years sales; the same can be done for previous and next month or previous and next day. Thus we can make use of reduced hop traversal to improve query performance when interested in sequences of dates. This is quite difficult to implement in a relational model as each comparison to a previous period and future period will require an additional column on the date dimension.


Conclusion

  • Cypher queries are less error-prone because its more difficult to miss join conditions when SQL-style FROM and JOIN are expressed through a single pattern.
  • Kettle has a nice plugin to visualise and perform your output to Neo4j.
  • We can optimise our graph for a number of different queries without impacting overall performance.
  • The flexible, schema-less nature means changes can be made without refactoring the whole ETL.
  • Graphs produce efficient recommendation queries.
  • There are many improvements yet to explore.

Next Steps

  • Compare performance on large, connected datasets between relational and graph databases.
  • Load and query databases built from the ground up for connected use cases: social media, map navigation, city planning.
  • Explore hybrid schemas (relational when needed, graph when appropriate) with a virtualisation layer.
  • Optimise Date nodes for different use cases.

Where to get the code

The Neo4j ETL can be downloaded here: loading_northwind_neo4j.zip

The PostgreSQL ETL can be downloaded here: loading_northwind_postgres.zip

PDI and XML: Beyond the native steps

Motivation

In day to day development we are sometimes faced with having to not only parse data delivered in XML, but a. lso generate complex XML files containing said data. It is nowadays common to exchange database extracts in XML format, and, in many other cases, results to API calls are provided in XML. Moreover, in many occasions one needs to construct either simple or complex XML, either to transmit data or to notify other systems that an action is required.

All of this requires a data engineer to create processes that receive, parse, and construct XML in near real time.

Parsing XML in PDI

Constructing a process to parse XML in PDI can be a frustrating ordeal. The developer creates a transformation to read XML using the native steps, optimises it for large throughput to a database only to discover that, once the source files increase in size, the real bottleneck is in the reading process. Moreover, when splitting the original file into several streams, issues with recursion or complex structures, memory and CPU resources increase almost exponentially.

To overcome this problem we suggest reading XML using the StAX parser step and processing its output. All of the parsing needs to be done manually, of course, but now all of the data is being streamed before being interpreted. We also suggest staging data using one or several “Serialize to file” steps before doing any merges or joins before finally saving to a database. Storing the data locally during processing is considerably faster than storing it in a staging database over the network, especially for large files.

Constructing XML

Creating an XML to represent a complex relational database structure can be a daunting task, especially when several hierarchical levels need to be represented. We proposed that the best way to do this is to template the output corresponding to the data in the leaves of the hierarchies.

This, in turn, will become the data to be represented by the higher levels. This recursion can be easily constructed using PDI transformations.

Ordering requirements, such as XML sequences, can easily be catered for and joins between parts of the XML are now reduced to a sorting of snippets according to a pre-defined priority.

Not only does this reduce the memory requirements when generating large XML files, it also significantly reduces the number of queries one makes to the database where the data is stored, thus considerably speeding up XML generation.

Conclusion

PDI is a generic tool that allows not only the integration of data sources but also its export. By its visual nature, it allows the creation of complex pipelines without forcing the developers to do any type of advanced coding. XML, however, has traditionally been in the domain of library utilization and custom code. We present a number of patterns that bring both the parsing and construction of complex and large XML files to the domain of visual programming used in PDI.

You can download the code and example data here.

Filling in the gaps

Today I saw Harris Ward asking a question I’ve seen pop up over and over again. And somehow the solution is never obvious.

The problem is how to fill in the gaps when we have nulls in our data stream. For example, our data set looks like:

And we want to replace all those nulls by the last non-null value we’ve seen in the data set: all non null values stay as is, but Mar, Apr and May get the value 20, Jul gets 50 and Sep, Oct and Nov get 40.

If we’re ingesting the data from a CSV, Excel or XML file, it’s easy to achieve this (ever wondered what the “Repeat” flag means in the fields tab of the Text File input step?).

But suppose our data doesn’t come from files. We need to implement the equivalente of the repeat flag inside a PDI transformation.

Invariably, when any of us encounters this requirement we all go through the same attempts. Let’s use the Analytical query step! Or the Group by with a “pass all rows option”. Or the NVL operation of the calculator step. And then we learn these all fail.

This is perhaps one of the best examples where a Javascript step is the best option. Because it lets us persist variables between rows, and we can control their values at will.

So, to achieve the desired result, here’s our proposed solution: add a Javascript step and use the following code:

Variable tmp is only initialized with the first row of data. From then on it’ll keep the last non null value of sales (or 0).

Sure, we’ve all heard the motto “Don’t use Javascript, it kills PDI performance”. But the occasional simple JS script doesn’t hurt that much in most cases, you’re likely to have a slower step elsewhere in your transformation (a DB read or write operation, for example). And, if performance is vital, you can always re-code this as a User defined Java class. But for all but the most extreme applications Javascript will work just fine, though.

Don’t forget to specify on the configuration of the output fields that you want to overwrite the value of the sales field, though:

And here’s the transformed data:

Exactly as intended.

Download the sample transformation here.

Ctools table component tweaks

(tl;dr: jump straight to section 3 below if you already know about scrolling tables)

Tables in Ctools are implemented by DataTables.net, a jQuery plugin to… well, display tables. However, as it normally is the case with Ctools, not all features are exposed via the CDE interface. And how could they, given the astounding number of features available plus the ever growing list of DataTables plugins out there. Implementing that extra bit of behaviour the users really love ends up being more an exercise in googling and finding the right plugin or trick to do the task than exploring the list of available properties in the Advanced column of CDE.

And that is the subject of today’s post. A specific tweak to the DataTables component that may be quite handy to know about.

1. To paginate or not to paginate.
By default tables are paginated in DataTables and, therefore, in CDE. However, especially if the result set is not very large, users may prefer a single page table to be displayed. Ok, that’s easy, just go to your Advanced properties tab and set pagination to False. Done, easy.

2. Don’t paginate, but scroll
However, single page tables are really only useful if your table is displaying a handful of rows. If you’re displaying some 20-30 records, for example, they may not be enough to justify pagination, but they’re way too many to display in a single page. One way around it is via CSS: just set its parent div height to be of a fixed size and set its overflow property to scroll. Again, done, easy.

Ah, except that now the table headers, filter box, etc. disappear when you scroll. And you can’t just set the scroll on the tbody element (ok, maybe you can with some really clever CSS hack). Fortunately, there’s an easy way around. A quick google search brings us to an example showing a scrollable table. The relevant property is scrollY, which can be set to any meaningful unit (e.g., 200px; vh and vw are units proportional to the viewpoort). To use it in CDE all we need is to add a new Extra option on the Advanced properties panel and set the property scrollY to whatever value we want.

Ok, but this is all relatively old news. If you have some experience with CDE and tables you may already know all this. So lets move on to something cooler.

3. But when the table refreshes, the scrollable area goes back to the top
Ah, so now your table scrolls up and down, but it has a major issue: the user wants the table to remember where it was. Namely, when the table refreshes because some parameter changed, the table should keep the search string and the scroll position and go back to the previous state.

For that, unfortunately, there’s no option in DataTables we can use, at least none we know about. So we need to implement it. Fortunately, it’s not that complex and the idea can be generalized for other properties we want to keep across component updates.

Step 1: add the following to the table’s preExecution function:

function(){
if( typeof this.tableState == "undefined"){
this.tableState = {
search: '',
scroll: 0
};
}
return true;
}

This creates the tableState property where we can store the two values we want to keep.

Step 2: add the following on the preChange of any selector that changes a parameter the table listens to:

function(){
var t = render_customerTable;
if( typeof t.tableState != "undefined"){
t.tableState.search = $("#" + t.htmlObject + " div.dataTables_filter input").val();
t.tableState.scroll = $("#" + t.htmlObject + " .dataTables_scrollBody" ).scrollTop();
}
}

(we need the condition just in case the selector renders before the table itself, which is the case in the sample provided)

This retrieves the two values we want to keep and updates the tableState to reflect them.

Step 3: add this to the postExecution of the table:

function(){
var e = this.placeholder().find("div.dataTables_filter input");
e.val(this.tableState.search);
e.keyup();
this.placeholder().find(" .dataTables_scrollBody" ).scrollTop(this.tableState.scroll);
}

This will restore the contents of the search box, force the table to draw itself again (by calling the keyup event) and then scroll the table body.

And that’s it. The table now does what we needed with relatively low effort.

Note that the code was written in the pre-require framework. If your dashboard has support for require.js the code should still work, but there are probably better ways to interact with the table, other than jQuerying its HTML target.

If you want to try it, download the sample we created.

Join the team!

We’re looking for a new junior member to join our team of Business Analytics and Big Data consultants.

If you’re passionate about data and have strong analytical skills this is a good opportunity to join a dynamic team developing high quality solutions using Pentaho and Hadoop.

Previous experience in programming (Java or Javascript preferred) and in SQL is desired, but not essential.

Apply now

Ctools now supports Require.js – But… what about jQuery plugins?

Great news from the Pentaho Community Dashboards front. As of the current version (15.06.30), there’s support for Require.js, which greatly streamlines the javascript downloaded when rendering a dashboard, cleans up the global scope and provides a proper management of modules and dependencies. I won’t bother you with the details, you can read more about it in Pedro Alves’s post.

This is truly a game changer when it comes to developing CDF/CDE dashboards. We have to write our code better, with a proper architecture in place to make all the pieces talk to each other, we need to use the proper methods to set or get parameter values, to run custom functions in pre-execution or post-execution code snippets, etc.

This is not a bad thing, far from it. But it doesn’t come without its challenges. We’ve started playing with the new require.js framework here at Ubiquis and we’ve learned useful tricks already.

Here’s one: remember how easy it was to upload that myAwesomeJqueryPlugin that you found on some github repository and allowed you to implement that super-duper feature on your dashboard? Well, it won’t work anymore. Not without a bit of work, at least. Here’s why: your typical jQuery plugin is a function of the type

(function ($) {
// your awesome code goes here
})(jQuery);

But now it will fail. The reason is that $ is no longer defined in the global scope. It’s still exposed and you can access it as usual from within any component’s internal methods, but not when you’re loading your jQuery plugins.

So, after some reading we got to a very interesting Stack Overflow post (see , that pretty much solves the problem. We just need some tweaks on the plugin code to make it require friendly:


(function (factory) {
if (typeof define === 'function' && define.amd) {
// AMD. Register as an anonymous module depending on jQuery.
define(['jquery'], factory);
} else {
// No AMD. Register plugin with global jQuery object.
factory(jQuery);
}
}(function ($) {
// your awesome code goes here
})(jQuery));

(note that the whole jQuery plugin is passed as a parameter to the factory function)

And there you have it, you can continue to use all the jQuery plugins you want, which are now loaded as require.js modules.

Dynamic date ranges in MDX: what happens if there’s no data?

Imagine the following scenario: a user wants a query to return the sales value from the past N years (lets say 5). It’s quite an easy query, your rows clause would look like this:

SELECT {[Measures].[Sales]} ON COLUMNS,
([Time].[2005].Lag(4) : [Time].[2005]) ON ROWS
FROM [SteelWheelsSales]

(As we’re using our good old friend SteelWheelsSales, lets pretend we’re back in 2005; If you’d like to have SteelWheelsSales updated, say to cover 2013-2015, please vote on the JIRA we created)

Here lies the problem: SteelWheelsSales only has data from 2003 to 2005, so the member [Time].[2005].Lag(4), which would be 2001, doesn’t exist. As such, the first member of that range doesn’t exist and the row set is empty.

And that’s not nice. It would be good to have a query that goes back N years in time but if there’s not enough data it still displays something.

What we need is a dynamic date range. It goes as far back as 4 years ago or, if there aren’t enough years in your database, shows all years.

Here’s what such a query would look like:

WITH
Set YEARS as [Time].[Years].Members
Member [Measures].[Year Number] as Rank([Time].[2005], YEARS ) - 1
Member [Measures].[Lag] as Iif( [Measures].[Year Number]<4, [Measures].[Year Number], 4) SELECT [Time].[2005].Lag( [Measures].[Lag] ) : [Time].[2005] ON ROWS, [Measures].[Sales] ON COLUMNS FROM [SteelWheelsSales]

Here's how it works:

  • The Year Number measure determines the rank of the last year of the date range; we subtract 1 to make it zero based;
  • The Lag measure checks whether the last year's rank is at least 4. If it's not, it takes the zero based rank (which means, it takes the first available year as the start of the date range
  • The date range on Rows takes this Lag measure to set the beginning of the range

This query returns all three years available in SteelWheelsSales. However, if more periods are available, it'll display up to 5 years of data.

And we can parametrize the query to take a year number:

WITH
Set YEARS as [Time].[Years].Members
Member [Measures].[Year Number] as Rank([Time].[${year}], YEARS ) - 1
Member [Measures].[Lag] as Iif( [Measures].[Year Number]<4, [Measures].[Year Number], 4) SELECT [Time].[${year}].Lag( [Measures].[Lag] ) : [Time].[${year}] ON ROWS, [Measures].[Sales] ON COLUMNS FROM [SteelWheelsSales]

Bonus points: make it smarter, that is, make the query dinamycally return a range of members of the time dimension, regardless of the level of the parameter:

WITH
Set MEMBERS as ${timeParameter}.Level.Members
Member [Measures].[Member Number] as (Rank(${timeParameter}, MEMBERS) - 1)
Member [Measures].[Lag] as IIf(([Measures].[Member Number] < 4), [Measures].[Member Number], 4) SELECT {[Measures].[Sales]} ON COLUMNS, (${timeParameter}.Lag([Measures].[Lag]) : ${timeParameter}) ON ROWS FROM [SteelWheelsSales]

This query takes a parameter ${timeParameter} as a fully qualified MDX member, e.g. [Time].[2004] or [Time].[2004].[QTR1] or [Time].[2004].[QTR1].[Jan] and returns a row set with 5 time periods, or a smaller range if we don't have that much data in the past.

1 year gone by

Ubiquis Consulting turned 1 year old last Saturday. It’s been a great year, full of the normal ups and downs of starting a business, but overall a very positive experience. And we got to bake a cake to celebrate the anniversary, which is always a plus.

IMG_1503

For our second year, we plan to keep this blog a bit busier, so stay tuned.

So, what else?… Oh, yes, please join me in welcoming Miguel Cunhal to the Ubiquis Consulting family. Miguel is a very bright young consultant and he is looking forward to learn all things BI and Pentaho. We’re sure he’s a very valuable adition to our team.

Hello world, again

We got some very good feedback to our World population demo, thanks everyone.

And in response to your opinions, we made a few modifications:
– Moving the globe no longer brings up the country details overlay;
– Clicking on a country in the table will bring the details overlay;
– When a country is selected, it’s highlighted in a different color.

The new version is updated in the demo site.

Hello world.

Welcome to Ubiquis. Come back to read everything about our work, projects and development.

Take a look at our first demo, currently available here (no login required).

It’s a CDE dashboard with a geographical visualisation built with D3.JS, featuring zoom and pan features.

Here’s a screenshot:
World_population2