A Brief History of Modern RDBMS Technology
& Information Technology Management Practice
PRF Brown
Winluck Pty Ltd.
IT Managers & Engineers
Falls Creek, NSW, Australia
http://www.mountainman.com.au/software/Winluck
Welcome.
In the following series of articles a specific environment in the many
and varied realms of Information Technology environments will be explored
in a little detail. This is the domain of the RDBMS, or Relational Database
Management System. Such systems have evolved, in the course of time, due
to the demand for the services that these systems provide.
Also considered in these articles is the parallel requirements of IT
Management practices as the decades brought one wave of technological
change after another. When the first cars appeared, they were often
accompanied by a stand-by mechanic with a toolbox in hand riding on the
running boards and ready for any roadside repairs.
IT Management started as a similar form of occupation, but in this
instance the machines were data processing engines, and their purpose
was not to traverse the earth, but to traverse the diurnal organizational
cycle of capitalising on the electronic record keeping arrangments.
Organisational investment in these machines became more focussed.
Scientific, administrative and business organisations strove to
idealise the paperless office. Up-time and reliablity were gradually
pegged back and harnessed through plain old research and development,
until the data processing engines could be relied upon to function
day in and day out.
What was it like a decade back to manage an IT environment, and what is
the nature of the occupation today? These questions and others are explored
and the answers provided are from experience on the production floor.
The articles are below indexed:
- Article 1: In the beginning was the Code.
This article examines the origins of IT's holy grail, a shoebox
full of punch cards, and a box of valves conspire to work together
and perform a task of computation. Enter loadable programmatic
coded instructions. Enter a host of hardware platforms. The code
went rampant. Organizational intelligence was redefined many times
over each second as the code went through its executions.
- Article 2: Emergence of the Database Management System (DBMS)
This section deals with the crystalisation of applications that were
characterised by their ability to manage data structures earlier
specified by the application code. But problems soon appeared in the
primitive data structures when load was applied, either
through increased transaction throughput, or in increased record lengths
of the constituent database structures. Concurrency problems, multi-
user access problems, ever-increasing structural sizes. These and other
challenges were met on the ground of theory, as well as on the production
floor of live systems.
- Article 3: Emergence of the Relational Database Management System (RDBMS)
This section diverges into the theory of the Relational Database model
as first espoused by Codd, Date, and others. It examines history not according
to the RDBMS vendors secure pathway of benefits that has advanced over time.
It is certainly acknowledged that the rigorous and academic, shall we say
"quality assurance by peer review process" of all RDBMS products is necessary
for the long-term evolution of such systems. However my perspective is different
again simply due to my experience in the field of IT Management at organisations
which had to come up with the workable solution by dawn and the opening of business.
We look at data integrity issues, their consequences and their work-arounds
when the underlying DBMS (or is it RDBMS?) fails to provide a consistent
integrity constraint mechanism.
- Article 4: Under the hood of the Modern RDBMS
When the bonnet is lifted on a modern RDBMS it is beginning to look
like there has been alot of work going on behind the scenes. These
Database Management Systems have a range of attendant suites of tools
and utilities which are all geared towards automation. Import and
export, inter-database object transfers, scripting, indexation
management, database backups and restorations, user and security
administration, transaction logging, rollback and recovery,
replication mechanisms, and at the backbone of the organisation,
a mechanism to schedule all such tasks.
- Article 5: Change Management and Systems Environments
Long serving IT professionals can probably recall at least one
major overhaul of their database systems environment every decade.
But often that is because their memory is failing, and the days of
mainframe, or midrange computer operating system software (and DBMS)
upgrades are remote in time. Somehow things have gotten more complex.
Change Management is probably the largest single task (if indeed it
could ever be called single) performed by an IT Manager and support
staff at any organisation. It is simply the management of change,
but it is rarely a simple task due to the complexity of the environment.
- Article 6: The Generic Change Management Flowchart
This article examines the 11 steps of the change management cycle
from a global perspective, and then scrutinises in succession each
of these steps, to determine what is the essence of step. This is
an exhausting but worthwhile process, for it quantifies a number
of variables in change management, including the turnaround time,
(and this from multiple perspectives), the number of coordinating
parties at any given time, the exact number of critical points
where all the involved people may consult in realtime. Also, it
provides a mechanism to derive approximations of the costs of
change management, by identifying its workflow patterns.
- Article 7: Future change management
Large scientific, administrative and business organisations all share a common
focus in the RDBMS. Today they also share a task in the management
and change management of their preferred database application software
product or products, running on their preferred RDBMS solution. Costs
of such environments are not decreasing, and this concerns executive.
Complexity of solutions is not decreasing, and this concerns the IT
Manager. Where is change leading information technology?
1) Answer: Not known
2) ETA: Not known (See 1)
3) COST: Not cheap.(See 2)
The problem appears to me clearly to reside in the manner by which
change in the RDBMS client environment is inordinately dominating
attention. By this I mean continuous change of the database application
software product code, either in the text of the code, or in its form,
in its version or patch or new release, or in any other form whatsoever
that "the code" might be conceived.
- Article 8: The Future Technology of the RDBMS Environment ...
The above picture appears reasonably non-eventful in terms of new horizons.
Nothing much has changed in the underlying management and administration
problems associated with large scale database application software required
as the user-interface to the RDBMS. It will take a new approach to this
long-term problem in order to solve it.
This final article in the series examines such a newly appeared alternative to
the deployment and development of organisational intelligence, whether it be
scientific, administrative or business in nature.
In this article we use our experience as IT Managers of yesteryear to
specify and reverse engineer one mode of dealing with all such identified problems.
The method utilised is unique, universal and rich in benefits, not the least
of which being the empowerment of those people with initimate knowledge of
the RDBMS native utilities and their functionality.
In this final article we examine what will more than likely become a new technology.
