Book Image

OCA Oracle Database 11g: Database Administration I: A Real-World Certification Guide

Book Image

OCA Oracle Database 11g: Database Administration I: A Real-World Certification Guide

Overview of this book

Oracle Database Server is the most widely used relational database in the world today. This book gives you the essential skills to master the fundamentals of Oracle database administration and prepares you for Oracle DBA certification."OCA Oracle Database 11g: Database Administration I: A Real-World Certification Guide" prepares you to master the fundamentals of Oracle database administration using an example driven method that is easy to understand. The real world examples will prepare you to face the daily challenges of being a database administrator.Starting with the essentials of why databases are important in today's information technology world and how they work, you are then guided through a full, customized installation of the Oracle software and creating your own personal database. We then examine fundamental concepts of Oracle, including architecture, storage structures, security, performance tuning, networking, and instance management. Finally, we take an in-depth look at some of the most important concepts in the daily life of an Oracle DBA - backup, recovery, and data migration."OCA Oracle Database 11g: Database Administration I: A Real-World Certification Guide" provides you with the skills you need in order to become a successful Oracle DBA, both for certification and real life tasks.
Table of Contents (24 chapters)
OCA Oracle Database 11g: Database Administration I: A Real-World Certification Guide
Credits
Foreword
About the Author
About the Reviewer
www.packtpub.com
Preface
Index

Understanding the RDBMS


To better prepare ourselves to understand the Oracle database, we should first familiarize ourselves with the history of databases and how the RDBMS became such an important part of today's IT infrastructure. We'll follow this with a look at the Oracle product family.

The importance of databases

Imagine, for a moment, that you have telephone books for the twenty largest cities in the United States, and I ask you to find all the phone numbers for all individuals named "Rick Clark" in the greater Chicago area. In order to satisfy the request, you simply do the following:

  1. Open the Chicago phone book.

  2. Scan to the "C" section of names.

  3. Find all individuals that match with "Clark" and"Rick".

  4. Report back their phone numbers.

Now imagine that I take each phone book, tear out all of the pages and throw them into the air. I then proceed to shuffle the thousands of pages on the ground into a completely disorganized mess. Now I repeat the same request to find all the phone numbers for individuals named "Rick Clark" in the greater Chicago area. How do you think you would do it? It would be nearly impossible. The data is all there, but is completely disorganized. Finding the individuals named "Rick Clark" of Chicago would involve individually examining each page to see if it satisfied the request—a very frustrating task, to say the least.

This example underscores the importance of an RDBMS. Today's RDBMS is the system that enables the storage, modification, and retrieval of massive amounts of data.

Flat file databases

When the devices that we know as computers first came into existence, they were primarily used for one thing—computation. Computers became useful entities because they were able to do numeric computation on an unprecedented scale. For example, one of the first computers, ENIAC, was designed (although not used) for the US Army to calculate artillery trajectories, a task made simpler through the use of complex sequences of mathematical calculations. As such, originally, computers were primarily a tool for mathematical and scientific research. Eventually, the use of computers began to penetrate the business market, where the company's data itself became as important as computational speed. As the importance of this data grew, the need for data storage and management grew as well, and the concept of a database was born.

The earliest databases were simple to envision. Most of them were simply large files that were similar in concept to a spreadsheet or a comma-separated values (CSV) file. Data were stored as fields. A portion of these databases might look something like the following:

Susan, Bates, 123 State St, Somewhere, VA
Fred, Hartman, 234 Banner Rd, Anywhere, CA
Bill, Franklin, 345 Downtown Rd, Somewhere, MO
Emily, Thompson, 456 Uptown Rd, Somewhere, NY

In this example, the first field is determined by reading from left to right until a delimiter, in this case a comma, is reached. This first field refers to the first name of the individual. The next field is determined by reading from the first delimiter to the next. That second field refers to the last name of the individual. It continues in this manner until we have five fields: first name, last name, street address, city, and state. Each individual line or record in the file refers to the information for a distinct individual. Because this data is stored in a file, it is often referred to as a flat file database. To retrieve a certain piece of information, programs could be written that would scan through the records for the requested information. In this way, large amounts of data could be stored and retrieved in an ordered, structured way.

Limitations of the flat file paradigm

The flat file database system served well for many years. However, as time passed and the demands of businesses to retain more data increased, the flat file paradigm began to show some flaws.

In our previous example, the amount of information in the flat file is quite limited. It contains only five fields representing five distinct pieces of information. If this flat file database contained the data for a real company, five distinct pieces of information would not even begin to suffice. A complete set of customer data might include addresses, phone numbers, order information, the date of the order, the delivery date of the order, and so on. In short, as the need to retain more data increases, the number of fields grows. As the number of fields grows, our flat file database gets wider and wider. We should also consider the amount of data being stored. Our first example had four distinct records, not a very realistic amount for storing customer data. The number of records could actually be in the thousands or even millions. Eventually, it is completely plausible that we could have a single flat file that is hundreds of fields wide and millions of records long. We could easily find that the speed with which our original data retrieval programs can retrieve the required data is decreasing at a rapid rate and is insufficient for our needs. It is clear that this flat file paradigm needs to be revised in order to meet the growing demands for our database.

A new paradigm

The world of databases changed in the early 1970s due in large part to the work done by Dr. Edgar "Ted" Codd. In his paper A Relational Model of Data for Large Shared Data Banks, Dr. Codd presented a new paradigm— the relational paradigm. The relational paradigm seeks to resolve the limitations of the flat file architecture by organizing our data in such a way that the data and its inter-relationships can be clearly identified. When we design a database, we begin by asking two questions: "What data do I have ?" and "How do the pieces of data relate to each other?" During this process, the data is identified and organized into entities. An entity is any person, place, or thing. An entity also has attributes , or characteristics that pertain to it.

These entities represent distinct pieces of information. We could have an Employee entity that represents information about employees, an Email entity that represents information about e-mail addresses, and so on. These entities, and any others we choose to add, make up our data model. We can also look a little closer at the attributes of a particular entity, as shown in the following diagram:

In our example, data such as First name, Last name, Address, and Branch name are the attributes of the Employee entity—they provide information about the employee. We can extend this idea to any other entities that represent a group of related information.

The true strength of the relational paradigm, however, is its ability to structure these entities in a way that forms relationships between them based on data that is common to both. Following is a simple diagram of this:

Here, we have two entities, Employee and Email, that form a relationship. The Employee entity contains information about the various employees in Companylink. The Email entity contains the e-mail addresses of these employees. Since any given employee can have one or more e-mail addresses, we say that there is a one-to-many relationship between Employee and Email, designated by the crowsfoot symbol between them. This relationship is the heart of the relational model that allows us to separate data into different entities. In the RDBMS world, we call these entities tables, while their attributes are known as columns . We will look much more closely at tables and their characteristics in future chapters. An entire data model can be visually displayed using an Entity Relationship Diagram (ERD). An ERD makes it easier to view the inter-relationships between entities.