Database reporting

Data Normalization - Know Your Data

A post here in these ITKnowledgeExchange blogs that recently caught my eye was this one written by Stephen Harris entitled “Data Challenges Can be Solved With Business Intelligence“.  It is a rather lengthy post touching on several points about data challenges and BI.  What I immediately latched onto in his post was what he refers to as a motto - “Thou shalt know thy data“.

While I have never phrased my firm belief in knowing your data in the way he does, I certainly agree that knowing your data is an absolute must.  Furthermore, his reference to cleansing, auditing, securing, managing and refreshing data is also an essential ingredient toward any meaningful reporting - never mind the special requirements for an effective BI implementation.

Once again I find myself “down sizing” information and ideas I read about to the needs of the businesses which I service, the small ones.  I’ve blogged recently about reporting requirements in these economic times, and certainly “…having information about your business at your fingertips…” is critical, not just a “nice to have”.

Reporting, BI and data “cleanliness” all depend to some extent upon the normalization of the data.  I can’t imagine trying to normalize a database without knowing your data.  If you would like a quick introduction to the topic of normalization I found “Introduction to Data Normalization: A Database “Best” Practice” to be an excellent place to start. 

As with so many areas in development there are multitudes of tradeoffs which come into play with the design of a database.  It is absolutely critical that the developer know and understand the data pieces (fields) and how they relate, but just as critical is that the developer understand the reporting requirements and other characteristics of the data, the database itself, the network and hardware platform, and “how” data will be queried.  Many speed issues can actually be caused by a database which has been normalized to such an extent that in order to provide the reporting required in an acceptable time span many extra steps are required to prep the data for the presentation sequence desired. 

The more up close and personal a developer is with the data the greater the opportunity there is to evaluate the data quality.  After there have been a number of changes in the form of additions and subtractions to fields or tables in the database it is a good practice to review the design again to determine if there are changes that should be made to further normalize the database.  My experience indicates that often changes are desired.

Reporting, Reporting, Reporting

My subject for this post - Reporting! (Perhaps you guessed! )

A few days ago I posted about “Green IT” and reporting methods and considerations to utilize less “paper”.  My post today regarding reporting is simply this — I posit that it is reporting which provides the greatest value of any business IT system.  Given this position I further venture to say that in this economic climate there will be an ever increasing demand for reporting which previously was neither desired, requested or dreamed of!  Just within my limited client base I have seen an increased interest in looking at new ways to report the wealth of information contained within client systems.

In addition, I have also seen that in some cases to get the information now being asked for will require additional input - (being of course that if data isn’t available it cannot be reported ).  This presents an interesting mix of work, application maintenance and report building - just what the doctor ordered for an otherwise “slow” time.

Through my years in IT and application development I have experienced many times the frustration of users regarding the presentation of their “data” in meaningful ways, or worse yet, their frustration knowing that data useful to them is simply “inaccessible” - “locked up” within the database somewhere.  During times such as these management becomes more interested in the “finer points” of their operations - “What does this cost us? … How about that? …Can we look at …?”.  During the busier times there seems to be a fear of having “too much” information, and surely “information overload” is easy to accomplish!  But in these tight times the value of specific pin-pointed reporting cannot be overlooked. 

Perhaps this is an appropriate time to be looking at what we can do in reporting to help our companies to succeed during this economic downturn.  Wherever possible it seems appropriate that we application developers “suggest” reporting that will add value.  Heck, it might also mean some job security

This probably isn’t the time, however, to suggest starting on implementing a new BI system, although wouldn’t that be nice?

Application Design for Green Reporting

Perhaps the phrase “Green IT” and various variations of same is over-used, however I suspect that its prevalence does cause us to think “green”, even if we’re sick of doing so.  When I chose “Application Design for Green Reporting” perhaps you wondered why I might have chosen such a title.  Good question

Seriously though, my reasoning is simple - and that is my belief that we as developers can and should do everything we can to ensure an appropriate use of resources - and in those resources I would include not only the obvious paper, but also disk space  (since inefficient disk usage may result in the need for added disks, and thus more energy used). 

Saving paper is certainly the easiest way to design for green, and we as developers have the opportunity to affect paper usage in a dramatic way - those steps may include:

• Offering on-screen views in lieu of paper
• Offering ability to print to a document such as PDF
• Designing reports using minimal header and footer margins
• Working with users to ensure ALL data printed is used
• Working with different font sizes to reduce paper needs
• Reviewing sub-total lines, are they used or just there because…?
• Reviewing page breaks - Are ALL page breaks required?

Additional Notes:

• Printing to PDF documents is great, but … here is an area where disk usage should be considered and an appropriate way to maintain (delete) out-dated or no longer needed “printouts”
• Margins in general require review with a critical eye.  Header and footer areas should contain only information useful to the users.  Use one liners wherever feasible.
• If a report will be going only to a laser printer, pages required for printing a report can sometimes be significantly reduced by going from two-lines per record to a single line per record - all with the same information only by changing to landscape mode
• A proper mix of font sizes can also significantly reduce paper use, while at the same time ooften producing a much more readable report!
• I have found many an opportunity to eliminate sub-total lines which has resulted in great paper savings
• Page break review might be a situation such as providing an alternative to printing the report with a page break at each customer change - or not.  Providing an option rather than forcing the page break can make a hugh difference.  Make the default to the “green” choice of no page-break.

How many pages have you saved today?

Quick Thoughts on Application Value

Experience a major meltdown of your workstation and I suspect the value of various applications will come to mind VERY quickly! There is nothing like going without your favorite applications, or your workhorse applications for a few days to develop a significant appreciation for application value. My last 2 weeks have been filled with recovering from such a meltdown.

If you’re like me as you have used your workstation (…perhaps for years) it has accumulated a number of handy utilities that are not “big” names, yet you use them each and every day. Perhaps they were something you found on the internet years ago and fell in love with and it has become part and parcel of your day-to-day work. What happens IF (or more likely when?) suddenly your workstation has a meltdown? It’s really not pretty!

Replacing a defunct workstation with a brand new one is only the start of the battle - the easy part. Gathering all the software you had, reloading it, re-registering it, restoring all the “little” applications (…finding where you got them from can even be a challenge I found!) all present challenges. Doing all this while at the same time tending (…or trying to tend to) the business needs becomes a stress-producing and frustrating experience.

When it comes to establishing application value I really wonder how one would determine in advance the effect of having an application suddenly NOT available once all the investment in application creation and implementation was made. I believe that if in the early stages of application definition one would be able to look ahead 5 years to look at what the potential dependency might be on the application it could be another way to think of application value.

Applications, the Business and the Processes

Reading Bob Lewis’s most recent article in KJR set my head spinning with thoughts of a commoditized IT similar to that of an electric company.  What Bob Lewis refers to in his article is a recent book entitled The Big Switch: Rewiring the World, from Edison to Google (W. W. Norton, 2008), and written by Nicholas Carr.  The very concept of IT as a commodity makes my stomach churn, as I’m sure it does with many of my associates.  Continued »

Software Development Using Multiple Environments

I have used the Basic, ASP, Java, Progress 4GL and DataFlex languages to some degree within the past week.  (…as well as operating system specific programs which are another form of programming).  Each of these were used with different tools for different applications.  For Each (…there I go looping again) there are syntaxes which are very similar to identical, and at least for this brain, easily confused.  Thankfully, many of the tools provided for development today shield the programmer from the intricacies of the language. Continued »

Developer - User Communications - Another Visit

Once again I find myself writing about the value of having good communication between the application developer and the users expected to use the program for their day-to-day operations.  Two noteworthy instances of this value came to me once again - just yesterday.  Each incident was unique in its own way, but the common thread was clearly communication - either poor, incomplete, misunderstood or a combination of all.  In each case the end result has been delay in getting the task completed. Continued »

Software Implementations - An Investment of Time

How many times do we hear “I don’t have time for that!” during a software implementation?   I’ve written some about the current implementations which I have going at this time, and some of the challenges, and as I’ve been writing I found myself being guilty of that very statement as it relates to an implementation of my own for which I have not found my “roundtuit”. 

What I refer to here is a piece of software which will help me in countless ways (…once I set it up and begin to use it!).  It will help me in creating this blog — yet it sits loaded on my laptop waiting for me to find the magic “time” to learn enough about it to make it useful to me.  That software waiting for me is Dragon Naturally Speaking, a voice recognition software that I saw demonstrated as part of an application some 8 months ago (…or maybe longer).  I was totally impressed and got myself a copy. Continued »

The Challenges of Application Software Implementations

Contrary to what my blog may be showing, I have not been on vacation this past week, nor have I been sick, nor have I been tending to many matters other than the current projects I have on my plate.  I could certainly use a vacation after this week!

 It’s said that timing is everything.  Well it would seem that my timing is off because I currently have two clients in the throws of new software implementations, and neither one has been without challenges.  For one thing, the challenges at each have been as different as their respective organizations. 

The main ingredient and common thread among these two implementations has been more along the line of user challenges than the technical issues of the software design or network implementation.  You know how users are - don’t you? Continued »

Just What Is Software Quality?

How do you define software quality?  There has been a great deal written about software quality, and as perhaps may be expected, many differing points of view regarding just what constitutes software quality.  I’ll not attempt to add yet another definition to the mix, although I certainly do have some ideas about the subject.

My recent software quality thoughts have been prompted by my getting up close and personal with an application I originally developed sometime in the late 80’s.  It has truly been an eye opener to have the opportunity to look at code which I generated back then.  This is code that fails many tests for quality — particularly understandability, consistency and maintainability…and structure?…what’s that? Continued »