SEARCHING: Boost a search term

September 25, 2012

BI24 provides the relevance level of matching documents based on the terms found. To boost a term use the caret, “^”, symbol with a boost factor (a number) at the end of the term you are searching. The higher the boost factor, the more relevant the term will be.

Boosting allows you to control the relevance of a document by boosting its term. For example, if you are searching for “Manchester” or “Pie” and you want the term “Manchester” to be returned towards the top of the document list, using the ^ symbol along with the boost factor next to the term. You would type:

This will make documents with the term Pie appear at the top of the document list.

You can also boost grouped terms;


SEARCHING: Grouping Syntax and Queries

September 25, 2012

BI24 supports using parentheses to group clauses to form sub queries. This can be very useful if you want to control the Boolean logic for a query.

To search for either “beef” or “chicken” and “London”, use the query:

This eliminates any confusion and makes sure you that “London” must exist and either term “chicken” or “beef” may exist.


OLAP’s Only Half The Story

July 4, 2011

Before I start, I’d like to make it absolutely clear that I think OLAP was a great technology and innovation, and when I first got introduced to it, I was blown away.

Although OLAP had been around a while, the first time I really started to become familiar with it was around the turn of the Century.

This makes me sound old but also shows how long OLAP has been around.

Coming from a relational background and spoon-fed on Oracle, Informix, DB2, Sybase and SQL Server I was firmly in the world of “Structured Query Language”.

I found great joy (and success) in learning how to do clever, unfathomable stuff joining as many tables as I could together in one go and exploring the limits of what was possible from one database supplier to another.

However, SQL was and is slow to retrieve data AND SQL is difficult and often a step to far for non-techies to understand and become proficient in.

When I saw OLAP and how easy it was to build a cube it came as a bit of a revelation. Why hadn’t I used this before? Why doesn’t everyone use it?

Well…

It works well because it’s working over pre-aggregated data.

“OK so there is MOLAP, ROLAP and HOLAP, all different variants of OLAP that either pre-aggregate, partially pre-aggregate or don’t aggregate at the expense of reduced performance… so if you want it to be fast it’s OLAP all the way.”

Building a cube takes time and over large data sets andfor really big cubes, can take hours. It’s this pre-aggregation that give you performance so that’s the trade-off.

OLAP only gives you half the story.

You can only see the data in an aggregated form and can’t drill through to the transactional data quickly as you have to go from the world of OLAP back to the world of SQL as soon as you go from a number to the raw data.

OLAP gives you flexibility through hierarchical dimensions and multiple measures but this is down to the programmer, the person who builds and maintains the cubes often hasn’t a clue what the business really needs and is trying to come up with structures that satisfy the many as opposed to YOU.

Move over OLAP and move over SQL.

There is a new way of doing things. A way that gives the business user access to the information they need that is quicker than OLAP, destroys the performance and flexibility of SQL and can be used by non-techies.

BI has been around for decades. There are so many products that do more or less the same thing in more or less identical ways.

Lipstick on a pig is a good description for modern day BI. At the end of day it’s still a pig.

A new layer of make up to provide a thin veneer over a fossilised architecture that is based on outdated ideas.

Search technology has been designed for speed. Designed for ease of use and designed for the non-techy (and it can be made to run real time…) and the 21st Century.

It’s about time someone thought about “Re-inventing Business Intelligence” by starting with a fresh way of thinking. By embracing the latest in search, social media, networking, web and phone.

When it comes to BI, move over OLAP and SQL, your time is up!

Richard Lewis


Brand Over Substance?

July 4, 2011

I come from an age when the Spectrum was the new kid on the block. I remember the smell of the machine when I took it out its box. The comforting heat omitted from it when I switched it on and sat at it writing code for hours on end.

For those of you who don’t know, the Spectrum was a competitor to the BBC computer, Commodore 64 and later the Acorn. Despite it’s rubber keys and the need to be some form of contortionist to get the keyboard to type “Beep” or “Poke” I loved it.

I bought magazines about the latest games. I brought them to school and ended up arguing with fellow geeks about the merits of the Spectrum over the Commodore 64. Why there wasn’t enough RAM in a VIC 20, why the Oric (which made me think of the talking plastic cube Orac out of Blake’s 7) came too late and was a year too late and never going to take off.

After learning to code and writing a few games I realised that I couldn’t do things by myself anymore. Games were becoming a big business. In fact games were no longer something that could be knocked up by a spotty teenager in their bedroom upstairs. Games now required teams of graphics designers, sound engineers, testers, marketing moguls and hordes of developers.

The games Industry was starting to boom. Hardware suppliers started to build low cost, powerful gaming machines. It was GAMES WAR. It was Atari against the PC, it was the Amiga against the Atari, it was both of them against the Sega and then all three against the Nintendo. That was the start and it’s been relentless ever since.

Think of some of the technology battles that have occurred over the past 20 years;

  • Windows versus Apple
  • DOS versus OS2
  • VHS versus BETAMAX
  • IE versus NetScape
  • iPod versus Walkman
  • Sky versus BSB
  • HD DVD versus Blue Ray
  • Sega versus Nintendo
  • Play Station versus XBOX
  • Google versus MSN
  • Sky versus Virgin Media
  • iPhone versus Blackberry
  • iPhone versus Android

All of these have been great products but there is only ever one winner. Is it always the best product? What is it that makes the winner “float to the top?” Is it the quality of the product or is it the way the product is marketed and branded?

As a consumer what do I want? Do I want the product that everyone else has or do I want the best product? Personally I want the best product. I don’t go for designer labels and I don’t go for things that are in vogue, I go for the things that make a difference to me, make a difference to my business and above all helps the bottom line.

I run a software company that writes bleeding edge technology. This is my story about why we do what we do and why I think that what we have is all about substance. For us the brand comes second however if we get that right too then perhaps someone will write about us in the future and see us as “remember the way things changed in BI? Remember Bi24 versus Business Objects, remember Bi24 versus Microsoft?

When I started my life as an IT professional, I was an analyst programmer specialising in COBOL and IDMSX on ICL mainframes. It was not long before I got into Oracle and enjoyed the delights of SQL, Oracle Forms 2.3 and Report Writer version 1.0 (which was shocking…)

I then moved onto SQL Windows, Ingres, Informix, SQL Server, DB2, C, C++ and finally Java with a bit of .NET before I decided enough was enough – get other people to do the programming as keeping up–to–date with new technologies and standards is a young mans game!

Throughout this time, I concentrated on data access and management information solutions. Designing applications to put data into a database and finding ways of getting it back out again – what a fulfilling career!

All sounds simple, in fact it really is however despite your best efforts you can only do as good a job as the tools that you are using will allow.

If the database does not support stored procedures or functions you end up writing more code and things tend to go slower. If you need to program in a language that doesn’t have very good de–bugging facilities you end up having to take twice as long and resort to adding loads of print statements and stack traces to help you identify where you are in the code when things go wrong – back in the 80’s, the Spectrum had no de–bugger so I was in my element here!

Up until the last 10 years of my career I had no say in what software languages we used or what database technologies we adopted. They were all chosen for different reasons. Some because they were functionally great but the majority because they had a good brand and the guy making the decision felt a “warm glow” when they spoke to the supplier (as if things didn’t work out they could always defend their position by the fact the supplier was in the magic quadrant at Gartner or had a balance sheet that RBS or Northern Rock would have died for).

Throughout this time I battled to create the best software solutions possible based on the raw materials I had at my disposal. I was pretty successful although if these solutions were re–produced today using the latest and greatest, the users would have been blown away.

One of my greatest loves was SQL (Structured Query Language) which I learned on a series of excellent Oracle courses in the late 80’s. A lot of what I programmed subsequently was around accessing databases, and I became pretty good at getting the best out of Oracle and applying what I knew to other databases “to get data out” that either I or someone else had managed to “get the data in”.

I grew to be (and would like to think still am) a SQL expert who could write line after line of SQL to navigate around the most complex of database schemas to return the relevant data rows back to the screen or a report. Twenty years of experience meant that SQL was no trouble to me.

Unfortunately, in later years, implementing solutions to customers, I found that end users and other IT departments did not share the same depth of knowledge that I have in “getting data out of a database” (perhaps this is because they didn’t know how to “get the data in?”) and struggled to use the same tools I grew to love as a serious software developer.

I now realise that getting data out of databases is not easy. It requires a lot of expertise in understanding where the data is, how to get at the data and how to bring it back in a meaningful form. Let a user loose on a database who is not a “professor in databases” is like letting a tourist attempt to translate a foreign paper when they don’t understand the language. They may understand part of it but will never see the full picture.

5 years ago I got all excited about search technology. It wasn’t new but I was starting to use it more and more to find “stuff” on the web and was amazed how easy it was to get results and how quick it was to get answers to the most bizarre of questions. The fact the answers were somewhere amongst several million search results was irrelevant to start with, I was simply amazed at the scale and the speed of this new technology.

It was not long before I formed a few ideas in my head about how searching for stuff using a search engine was child’s play and how searching for stuff in a database was for the “weird and unwashed” – like myself.

“What would happen if we used search technology to search databases?”

“How great would it be if people that understood the business but didn’t understand SQL could finally get at their data?”

From this idea came CXAIR – A business intelligence tool that takes the best elements of search engine technology and combines them with the best elements of business intelligence. A master stroke!

It’s super-fast, easy to use, easy to implement, based on the latest technology, an evolutionary leap from other business technology that sits on top of the now legacy database systems however… we’re not Microsoft. We’re not Oracle. We’re not Business Objects.

I run a UK company with a team of extremely gifted geeks who like me love software and love “getting data out” of systems – they’re not to bothered about “getting data in” as we leave this to the database specialists because after all databases are designed for “storing data” not “retrieving data”.

We understand business intelligence but don’t have the legacy the big boys have and have been able to come up with something that is fundamentally different from any other BI tool. It’s easy to use! It’s lightning fast! It’s installed and working in under a day!

We are all about substance. What we have is real and not over egged by some giant marketing machine. What we have is amazing. Give us a call and we’ll show you what we mean.

Richard Lewis


%d bloggers like this: