Information is to knowledge as...

Bit is to Byte.

Byte is to data.

Data is to information.

 

A computer is such a nice tool to collect, prepare / process, and consume knowledge. But nice is different from easy. The level of ease in using computer for the aforementioned activities however are usually inversely proportional to one another. For example, if it could be considered easy to collect data, it can be reasonably said (and observed) that the data processing is relatively more difficult than the its collection; or so the logic dictates, for what it's worth.

Fast forward to preparing cubes for SQL Server Analysis Services, I found myself trying to figure out how to prepare an ease of processing for my work product's audience, starting with its setup. After a little bit of struggle through the various binaries in my machine, I found the following steps helpful for those of you trying to do the same:

Local environment variable path setup:

1. Add to your local environment path an entry pointing your VS.2005 IDE location (screen Evp1.1 - 1.4).
2. Add to the same local environment path another entry pointing to the location where you find Microsoft.AnalysisServices.Deployment.exe, if it isn't already there. (Notes local environment path entries are separated by semi-colon).

Screens:

Evp1.1 Evp1.2

Evp1.3 Evp1.4

 

The lazy version:

1. prompt:> devenv [solution filepath and filename] /deploy

Well... sure you might run into a couple of pop-up dialogs, but just a couple of OK clicks without knowing what they mean will put you back on the processing track. No worries though, even when you don't click the buttons until the end the show will go on until completion with the exception that the thread is still be hanging until said clicks are made.

If you're bothered by the only seemingly semi-autonomous run (since you still may be needed for those two manual clicks), here's another way to do it... properly... starting with the same local environment path setup steps above, then followed by these steps:

1. Build the .asdatabase file from your solution file using prompt:> devenv [solution filepath and filename] /build
2. The deploy using prompt:> microsoft.analysisservices.deployment [solution filepath]/bin/[project name].asdatabase /s:[deployment log filepath and filename]

A word of caution: Don't be alarmed if your screen seemingly freezes during the deployment; this will likely be the scenario depending on your hardware configuration and the volume of data in your database that Analysis Service engine processes.

Why do we want to go through this when we can just load the solution file in VS.IDE then with just a few clicks to the above easily without having to memorize seemingly arcane and puzzling commands and steps? There are several different answers to this, but my favorite one doesn't have anything to do with it as knowledge that reliable technician needs to have; rather, it has to do with the pursuit of knowledge itself.

If our knowledge is the sum of our experience, and if we postulate that human beings learn more from difficult experience than an easy one, then it follows that by doing the above steps we will retain this knowledge longer that had we just done the usual mouse-clicks. And that my friend is what knowledge is to an application...

Database

Ahhh... the base of the world's data. The repository where all the secrets of the universe is contained. We can consider anything to be a database. And database can be in any forms. The speed with which we come to a full understanding of what a given set of data is about is what determines its usefulness. How we come to that understanding is the process applied against it.

For a database to be useful it must be well-structured. For its usefulness quickly understood, the process(es) applied must be efficient and intuitive. Only when we fully grasp these fundamental ideas can we also appreciate and begin to study its complexity.

Let's for a moment imagine that a book is a kind of database. Conceptually, the structure of a book could be: the binding and the leaves. The binding may contain the backbone, front- and back-cover. The leaves may contain the table of contents, the content itself, and the content indices. Further, the contents may contain chapters, sections, and paragraphs. We can go on to the sentences containing phrases, words, letters (alphabets), numbers, and punctuation. Since we were but a tot, we learned ABC's. We then learned to put words together, sentences, and so on. We also learned how to read. In effect, we learned methods of operation, where the objects being operated on are letters, words, sentences, etc. so that we can communicate with one another be it orally or via written materials. From a very young age all we learn is essentially this very same concept of database — its structure and mode of operations or behaviors.

Database is one of the most significant part of an information system. Despite the simplicity of a database concept, it is still oft misunderstood. Why is that? To illustrate, let's consider the following story. I am a database developer, and yet if I sell myself solely on my technical skills, i.e., in my ability designing and implementing database applications I would not be able to compete with the younger generations of coders many of whom are very creative, to say the least, in their programming styles and habits. In addition, many modern programming tools almost makes someone with a highly disciplined programmer obsolete, i.e., it almost take no brains these days to be able to program anything. The reality is different. These tools don't make us obsolete. We are in greater demand more than ever for a very simple reason, tools and technologies don't replace knowledge and judgement. Similarly, having knowledge and judgement alone won't be enough if one does not know how to execute them in timely manners.