 | | The underlying data in an organisation is always critical to the successful execution of the business mission. That is simply a fact that cannot be reasonably impugned. Mis-management of the data, mis-management of the information derived from the data or mis-interpretation of derived information will always compromsie the business mission. TMIT are experts in ensuring that data is properly captured, stored and made accessible to business management. The result is a 'database'. | | We take that to the logical next step and provide information management, reporting and interpretation tools. These aid the day-to-day operations as well as the tactical and strategic decision making for management. These tools are the Database Application Software |
|
|
TMIT style themselves as 'the database experts' for good reason. Since 1977 the founders have been actively involved in all aspects of Relational Database Management Systems (RDBMS) from education and training to commercial design, deployment and support. As mathematicians, educationalists and business management experts, they have used dozens of different RDBMS, taught others how to use them and guided small and large enterprises to benefit from them. Academic roots in theoretical mathematics provided the foundation to fully understand the meaning and power of the relational concept. Backgrounds in secondary and tertiary) teaching of mathematics and information technology gave them the ability to convey their comprehensive understanding of RDBMS to others in a way they could benefit. Many years in business management (IT, sales, marketing and CEO) have given them the most formidable experience in deploying RDBMS technology from almost every perspective in the business value chain.
So why is 'database' important to business? To anyone who understands the value of information, the question is almost as redundant as 'why are sales important?' or 'why is stock important?'. If you have nothing to sell then you don't have a 'business'. If you do and you fail to sell it, then you still have no business. Without 'information' no business can exist. It's as simple as that!
A business needs to take care of information just like it takes care of stock. You need to store it, protect it, make it available to just the right people, get more of it, manage what types you have and in what quantities. Often you also need to process it (stock or information) to change it into something else - something more saleable or more useful.
|
|
Read more...
|
|
How do I know when I need to move my spreadsheets to a proper database?
When a business first charges into the unknowns of IT, the spreadsheet is usually the first useful business tool encountered. Suddenly, business managers find a tool to keep information more ordered than before and are able to instantly do quite complicated calculations that took hours without the spreadsheet. It is all much tidier and the printed output is very impressive.
As the business grows two things happen. The spreadsheet user gets to understand the tool better, gains confidence and starts to do more intricate things with it. Alongside this, the spreadsheets get more complicated - multiple related spreadsheets, complex data lookups, macros and even integration with word-processing.
Naturally, this combination of confidence and complexity compels the business manager to more and more deeply commit to this spreadsheet technology - often to a point way beyond where spreadsheets were ever intended to be. Until...
suddenly things start to go wrong - anomalies and mistakes start to increase. To compound this, the problem of handing the management of the spreadsheet over to someone else becomes almost impossible. Worse - dividing the workload (having more than one person using the spreadsheet is even more difficult.
At this point the clever business manager realises that they have pushed the spreadsheet thing too far; and they seek professional help. Any professional IT consultant will, at this point, suggest that a 'database' solution be sought. So what is the difference?
A spreadsheet is simply one or more arrays of cells where you put data items. The spreadsheet is designed to be able to 'see' the actual data placed in the cells. If the same column or row of data items need to be displayed in more than one sheet (array) then they are simply copied from one sheet to the other. If, however, you wanted to change the value of a cell in all those places to where you had copied the original, then you would have quite a problem - either manually changing them all or keeping track of all the cell references where this needed to be done.
If you want to reorder the rows/columns then most modern spreadsheets make this quite easy. If, however, you want to SELECT only some rows or columns or both using different selection criteria in different situations then the process becomes extremely difficult and one quickly realises this in not a job for even the most sophisticated spreadsheets.
A database is similar - a collection of 'tables' of data (rows and columns - technically called 'Relations') just like a spreadsheet. The difference lies in the ability to design a database so that if an item needs to be referred to by more than one table then it is 'tokenised' by reference to a 'key' in the original table. A fundamental objective in designing a database is to avoid ALL duplication of actual data ('normalisation'). Modern databases are part of a RDBMS (Relational Database Management System) with a structured query language (SQL) to enable us to SELECT any subset of any table (row/column set) in any way we like. SQL goes further than that and allows us to SELECT any subset of any combination of 'related' tables. Even further, we can INSERT, DELETE and UPDATE date in the tables in accordance with any SELECTion we might choose.
When we put all this together, we have a very powerful tool to manage data in a totally controlled and secure way. Fortunately we do not need to learn SQL to manage this data. We can build an 'application' (that uses SQL) in a way that is expressed in terms normally used by the business manager (or other 'users' of the database application).
What are the signs that you have exhausted the capability of spreadsheets?
- Do I cut-and-paste whole columns (or rows) of cells from one sheet to another?
- Do I have the same items on the left column or top row in more than two sheets?
- Do I want to select and display only parts of a sheet?
- Are there more than 100 rows in any sheet?
- Are there more than 20 columns in any sheet?
- Do I need spreadsheets from the past (last year, month, week, yesterday)?
- Are there increasing anomalies or mistakes in the totals rows/columns?
- Do I need to share the workload on my spreadsheets?
If you need to answer 'yes' to any of these questions then it is time to start moving your spreadsheets into a database before they become a real headache. |
|
|
|
|
|
IT Services 
