CHAPTER 1 ■ RELATIONAL DATABASE MANAGEMENT SYSTEMS
9
reporter cornered me and asked if I was willing to answer a few questions for the camera. I was flattered,
but when the reporter pointed the camera at me and asked, “Why are databases important to society?” all I
could think of to say was (paraphrasing), “Well, they’re important because they’re, like, really important, you
know.” All those years of database administration under my belt, and I still flunked the final exam!
I’d therefore like to spend a few minutes at the outset considering what the word database signifies. An
understanding of the implications of the word and the responsibilities that go along with them will serve you
well as a good database administrator.
I’ll begin by saying that databases can contain data that is confidential and must be protected from
prying eyes. Only authorized users should be able to access the data, their privileges must be suitably
restricted, and their actions must be logged. Even if the data in the databases is for public consumption, you
still may need to restrict who can update the data, who can delete from it, and who can add to it. Competent
security management is therefore part of your job.
Databases can be critical to an organization’s ability to function properly. Organizations such as
banks and e-commerce web sites require their databases to be available around the clock. Competent
availability management is thus an important part of your job. In the event of a disaster such as a flood
or fire, the databases may have to be relocated to an alternative location using backups. Competent
continuitymanagement is therefore another important element of your job. You also need competent
changemanagement to protect a database from unauthorized or badly tested changes, incident management
to detect problems and restore service quickly, problem management to provide permanent fixes for known
issues, configuration management to document infrastructure components and their dependencies, and
release management to bring discipline to the never-ending task of applying patches and upgrades to
software and hardware.
I’ll also observe that databases can be very big. The first database I worked with, for the semiconductor
manufacturing giant Intel, was less than 100MB in size and had only a few dozen data tables. Today,
databases used by enterprise application suites like PeopleSoft, Siebel, and Oracle Applications are tens or
hundreds of gigabytes in size and might have 10,000 tables or more. One reason databases are now so large is
that advancements in magnetic disk storage technology have made it feasible to efficiently store and retrieve
large quantities of nontextual data such as pictures and sound. Databases can grow rapidly, and you need
to plan for growth. In addition, database applications may consume huge amounts of computing resources.
Capacity management is thus another important element of your job, and you need a capacity plan that
accommodates both continuous data growth and increasing needs for computing resources.
When you stop thinking in terms of command-line syntax such as create database and GUI tools
such as the Database Creation Assistant (dbca) and start thinking in terms such as security management,
availability management, continuity management, change management, incident management, problem
management, configuration management, release management, and capacity management, the business
of database administration begins to make coherent sense and you become a more effective database
administrator. These terms are part of the standard jargon of the IT Infrastructure Library (ITIL), a suite of
best practices used by IT organizations throughout the world.
What Is a Relational Database?
Relational database theory was laid out by Codd in 1970 in a paper titled “A Relational Model for Data
for Large Shared Data Banks.” His theory was meant as an alternative to the “programmer as navigator”
paradigm that was prevalent in his day.
In pre-relational databases, records were chained together by pointers, as illustrated in Figure1-6. Each
chain has an owner and zero or more members. For example, all the employee records in a department
could be chained to the corresponding department record in the departments table. In such a scheme, each
employee record points to the next and previous records in the chain as well as to the department record. To
list all the employees in a department, you would first navigate to the unique department record (typically
using the direct-access technique known as hashing) and then follow the chain of employee records.
www.it-ebooks.info
我的内容管理
展开
