Content-length: 6212 Content-Type: text/html; charset=UTF-8

MESSAGE FROM THE PRESIDENT

October 97


Greetings Fellow Members,

 Today I would like to talk on a subject that is near and dear to my heart; data. Did you realize that the amount of data available doubles every year? How can we handle all that information? How can we organize that data so that it is useful to everyone that needs it? How can we do that on a limited budget? Now there are some questions I know that I can't answer, but here are my thoughts anyhow.

 We are currently living in the information age. Our users demand data that is not only correct, but available to them when they want it. No more requesting the IS department to run this report or that, and waiting for the next batch to run. They are demanding tools that allow them to access the data, design and run the report -all on their schedule.

 With the newer software and relational databases, it is fairly easy to concede to the user's request. But what if the data is not in a relational database? Most companies with large budgets simply hire consultants to convert the existing data into a newer format. Once you do that however, all reporting software has to be updated to access the new data format. Again, large companies with large budgets simply hire it done. For smaller companies, or separate departments of large companies, it can be a major headache.

 For an example, I would like to relay some problems that I am dealing with. Many moons ago, when the PC was just an infant, one of our engineers became well versed in a program called "Visicalc." This later led the engineer to "Lotus 1-2-3". He developed spreadsheets to do engineering calculations off data that was input from the part prints. He then got the bright idea that if he saved the part data off in a file, the next time that he needed the data for a calculation, he could load it off the disk instead of inputting the data again. This saved time and minimized keypunch errors. All this information came to be known as the engineering database. As the years passed, more and more information was added to the engineering database. Due to memory constraints, the data was not kept in one large file; it had to be broken down into a separate file for each part number. As the use of PCs spread, and we installed our first "engineering network," the other engineers began developing Lotus spreadsheets to take advantage of the engineering database.

 Fast forward to today. The engineering database consists of over two thousand separate data files (in Lotus 1-2-3 format), with many spreadsheet programs that access the data. We have discussed consolidating the data into one large relational database file. Creating the file would be simple; the hard part is rewriting the access programs to allow for the new method of data storage. The original programs have been changed and expanded by so many different people over the past years that it will be a monumental task to rewrite the files. I do not have the budget, the money, or the time to redo the data or the access programs. I am stuck with using a system designed 15 years ago instead of taking advantage of new database strategies.

 I guess the moral of this little story is this: put a lot of thought into the decisions you make today because you don't know how they will influence the future.

See you at the next meeting.

 

Kevin