Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Лекция 1 - ОБЗОР баз данных Oracle.doc
Скачиваний:
78
Добавлен:
15.05.2015
Размер:
920.58 Кб
Скачать

5

Обзор баз данных Oracle

На этой лекции мы познакомимся со следующими областями

- Обзор баз данных Oracle

- Выборка данных из Oracle

Каждый пользователь, разработчик или АБД Oracle должен в совершенстве овладеть этими вопросами, прежде чем переходить к следующим рассматриваемым материалам по курсу лекций по данной тематике. В настоящий момент рассмотрены основные аспекты выборки данных из баз данных Oracle.

Материалы, которые будут рассмотрены сейчас, составляют примерно 8% содержания первого экзамена программы ОСР.

Обзор Oracle

В этом разделе для обзорного знакомства с базами данных Oracle рассмотрим следующие вопросы:

  • Теоретические и физические аспекты реляционных баз данных

  • Реализации РСУБД и ОРСУБД Oracle

  • Использование PL/SQL и его преимущества

В этом разделе очень много вводного материала, который может оказаться полезным для знакомства с Oracle при подготовке к использованию запросов для получения данных из базы данных. Прежде чем с головой уйти в подробности функционирования программного обеспечения Oracle, многим читателям, никогда ранее не имевшим дела с Oracle, будет полезно ознакомиться с этим материалом для получения общего представления о нем. Если вы относитесь к их числу, смело можете приступать к чтению! Даже если вы уже большой дока по части использования Oracle SQL, все равно вы можете захотеть бегло просмотреть этот материал, прежде чем идти дальше, особенно если раньше вам не приходилось сталкиваться с обзорными материалами по программному обеспечению Oracle. Сначала мы поговорим о некоторых основных аспектах теоретической и физической стороны реляционных баз данных, а также о реализациях РСУБД и ОРСУБД Oracle. Кроме того, речь пойдет об использо­вании и преимуществах PL/SQL — собственного языка корпорации Oracle, используемого для разработки приложений базы данных, которые хранятся и выполняются непосредственно внутри базы данных Oracle.

Теоретические и физические аспекты реляционных баз данных

Корни Oracle лежат в теории реляционных баз данных, начала которой были заложены в 1950-е гг. в работах Е. Ф. Кодда и которая впоследствии была распространена на бесконечное число таких направлений, как работа с хранилищами данных, онлайновая обработка транзакций и приложения, поддерживающие работу в Web. Без сомнения, завоеванная этим программным обеспечением популярность является одной из причин того, что вы держите в руках эту книгу. В этой книге есть ответы на все вопросы, которые вы можете задать; что такое база данных Oracle, как она работает и что можно сделать с ее помощью. Ответы на все эти вопросы потребуются вам для того, чтобы выдер­жать первый экзамен: введение в SQL.

Занимающиеся разработкой программного обеспечения компании используют много различных подходов к управлению информацией. На протяжении многих лет наиболее популярные софтверные пакеты для хранения и выборки данных использовали в качестве основного средства хранения данных системы простых (или, как их иногда называют, плоских) файлов. При этом выбор того, как именно хранится и выбирается информация, оставался за вами, а в качестве языка программирования обычно использовался COBOL. В некоторых ранних разновидностях систем плоских файлов использовались иерархические системы хранения, где записи данных хранились в иерархическом виде, подобном той иерархической структуре каталогов, которую можно уви­деть в окне Windows Explorer, например для жесткого диска вашего ПК. Такие приложения выполнялись на мэйнфреймах, а среди широко известных торго­вых марок можно выделить IMS — иерархическую систему корпорации IBM и IDMS — сетевую систему компании Computer Associates. Наиболее часто употреблявшимся в этих системах для разработки механизмов добавления данных и управления ими языком программирования был, как мы уже говорили, COBOL.

Такие системы с плоскими файлами прекрасно подходили для определенных задач, например для создания отношений типа "родитель-потомок". Эти отношения могли, к примеру, использоваться для представления отношений между сотрудниками отдела продаж компании, занимающейся дистрибуцией пищевых продуктов, и клиентами компании. Еще одним примером отношения "родитель-потомок" может служить отслеживание номеров счетов и их связи с позициями номенклатуры продукции в заказах клиентов этой дистрибьюторской продовольственной компании. Однако один из недостатков таких систем плоских файлов был следствием того, что отношения "родитель-потомок" не могли моделировать все возможные типы взаимосвязей данных. В приведенном выше примере с продовольственной компанией в заказе пользователя могло быть перечислено много различных продуктов. Каждый из этих продуктов сам по себе может появляться во многих различных заказах. Как в этом случае, который принято называть отношением "многие продукты во многих заказах", следует проектировать иерархию? Какой объект следует использовать в качестве родителя, а какой — в качестве потомка? Обычное решение заключалось в создании двух отдельных иерархий: одной, где в качестве родителя выступает продукт, и другой, где в этой же роли используется заказ. К сожалению, это зачастую означает сопровождение во многом совпадающей информации в двух местах (или в большем количестве мест), что приводит к появлению избыточных данных. Поддержание согласованности данных в нескольких местах хранения делает хранение и выборку данных сложной задачей. Еще один существенный недостаток иерархических баз данных, использующих систему плоских файлов, заключается в том, что их довольно трудно адаптировать к изменению бизнес-потребностей предприятия. Если дистрибьютор продовольствия создаст у себя новую систему продаж, которая предусматривает возможность совместного владения учетными записями клиентов несколькими сотрудниками отдела продаж, компании потребуется заново проектировать иерархическую базу данных.

Мотивируя свои исследования неудовлетворенностью громоздкими характеристиками иерархических баз данных, состоящих из плоских файлов, Е. Ф. Кодд, ученый-компьютерщик, работавший в 1950-е гг. на IBM, разработал альтернативу — реляционную модель. Вместо хранения данных в иерархиях Кодд предложил хранить связанные элементы данных, например контрольные номера и заказанные продукты, в таблицах. Как обнаружил Кодд, если эти таблицы спроектированы в соответствии с несколькими простыми принципами, они будут понятными и чрезвычайно эффективными для хранения данных. Один элемент данных может храниться только в одном месте. По прошествии некоторого времени многие производители программного обеспечения поняли всю значимость работы Кодда и начали разрабатывать продукты, соблюдающие модель Кодда. Начиная с 1980-х гг. практически все софтверные продукты для баз данных (включая Oracle) соответствуют реляционной модели.

Главным элементом, принесшим успех реляционной модели, является использование для хранения и выборки данных и манипулирования ими реляционной системы управления базами данных (РСУБД). При использовании более ранних продуктов организациям для кодирования механизмов управления процедурами выборки данных, которые непосредственно взаимодействуют с файлами базы данных, приходилось иметь в штате множество программистов на языке COBOL, В противоположность этому механизму РСУБД обрабатывает такие задачи автоматически, используя для этого функциональный язык программирования SQL (произносится либо как "сиквел", либо согласно произношению каждой буквы: Эс-Ку-Эль). SQL означает "Structured Query Language — язык структурированных запросов", и с его помощью пользователи могут делать запросы к требующимся им данным в соответствии со строгими критериями сравнения. К примеру, если вы желаете для сотрудника по фамилии SMITH проверить идентификационный номер (ID) и информацию о его заработной плате, вам поможет сделать это следующий оператор SQL:

SQL> SELECT EMPNO, ENAME, SAL FROM EMP

2 WHERE ENAHE = 'SMITH';

Совет Предшествующий блок был взят непосредственно из SQL*Plus — инструментального средства, предоставляемого корпорацией Oracle для взаимодействия со своими базами данных. Символ "2", означающий, что вы начали ввод второй строки, записывается SQL*Plus автоматически. Вы не должны пытаться ввести этот символ."2"собственноручно. Сейчас вас не должно волновать, что на самом деле означает этот оператор SQL или какими должны быть его результаты; просто поймите, что перед вами пример оператора SQL.

В системе, оставаясь, так сказать, за кулисами, РСУБД транслирует этот оператор в последовательность операций, которые выбирают информацию из файлов, размещенных на машине, где хранится ваша база данных. Этот шаг называется анализом или разбором (parsing). По окончании разбора РСУБД выполняет ряд операций для завершения требующихся действий.

При этом могут быть выполнены некоторые (или все) операции из приведенного ниже списка (порядок их выполнения может быть произвольным):

  • Неявное преобразование типов

  • Поиск по индексам (в случае необходимости) для сокращения времени реакции системы

  • Операции чтения с диска или записи на диск

  • Фильтрация данных таблицы в соответствии с критериями поиска

  • Сортировка и форматирование возвращаемых данных

Совет Индексом называется специальный объект базы данных, который может быть использован для повышения производительности конкретных операций РСУБД. Типом данных (datatype) называется определение типа данных (data type), хранящихся в столбцах таблицы. Более подробно речь об индексах будет идти в следующих главах.