Модели данных. Инфологическая модель.

Понятие базы данных (БД).

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

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

Обращение пользователей к системам обработки данных чаще всего приводит к обновлению информации. Вывод информации может вовсе отсутствовать или представлять собой результат программной обработки хранимых сведений, а не сами сведения. Примером системы обработки данных может быть ИС сберегательного банка города. Она содержит сведения о вкладах жителей города, большинство обработок банковской информации предполагает обновление сумм вкладов, расчет процентов, подведение итогов за некоторый период работы и т.д.

Локальные и глобальное пользовательские представления.

Чтобы разобраться в задаче, нам необходимо структурировать информацию:

• определить предметную область, в рамках которой, вероятнее всего, лежит наша задача;

• определить участников событий и пересечение их интересов;

• среди взглядов участников событий на предметную область выделить ту часть, которую занимает наша задача.

При проектировании ИС взгляды отдельных пользователей на предметную область называют локальными пользовательскими представлениями (ЛПП).

Сведение этих взглядов в единую систему, выявление пересекающихся эпизодов и определение той части, которая необходима для решения поставленной задачи, разработчик ни в коей мере не может перекладывать на плечи пользователя. Этот этап является одним из основных при построении ИС. Его реализация невозможна без изучения тех процессов, которые протекают в изучаемой предметной области.

Завершение этапа приведет к формированию глобального пользовательского представления (ГПП), т.е. будет отражать точку зрения администратора БД.

Требования, предъявляемые к БД.

Проектирование базы данных – это процесс создания проекта базы данных, предназначенной для поддержки функционирования экономического объекта и способствующей достижению его целей. Оно представляет собой трудоемкий процесс, требующий совместных усилий аналитиков, проектировщиков и пользователей. При проектировании базы данных необходимо учитывать тот факт, что база данных должна удовлетворять комплексу требований. Эти требования следующие:

1) целостность базы данных – требование полноты и непротиворечивости данных;

2) многократное использование данных;

3) быстрый поиск и получение информации по запросам пользователей;

4) простота обновления данных;

5) уменьшение излишней избыточности данных;

6) защита данных от несанкционированного доступа, искажения и уничтожения.

Реляционное исчисление.

Это система обозначений для получения необходимого отношения в терминах данных отношений. Языки исчисления – это не процедурные языки, поскольку их средствами можно выразить все, что необходимо и необязательно указывать, как это получить. Выражение в исчислении описывает лишь свойства желаемого результата, фактически не указывая, как его получить. Основными понятиями исчисления являются понятие переменной с некоторой областью допустимых значений и понятие правильно построенной формулы, опирающейся на предикаты, переменные и кванторы.

В реляционной модели определяются два базовых механизма манипулирования данными: * основанная на теории множеств реляционная алгебра; * основанное на математической логике реляционное исчисление.

Формулы реляционного исчисления определяются над отношениями реляционных баз данных, и результатом вычисления является отношение.

Эти механизмы манипулирования данными различаются уровнем процедурности: * запрос, представленный на языке релационной алгебры, может быть вычислен на основе вычисления элементарных алгебраичесских операций с учетом их старшинства и возможных скобок; * формула реляционного исчисления только устанавливает условия, которым должны удовлетворять кортежи результирующего отношения. Поэтому языки реляционного исчисления являются более непроцедурными или декларативными.

Пример: Пусть даны два отношения:

СОТРУДНИКИ (СОТР_НОМЕР, СОТР_ИМЯ, СОТР_ЗАРПЛ, ОТД_НОМЕР)

ОТДЕЛЫ(ОТД_НОМЕР, ОТД_КОЛ, ОТД_НАЧ)

Необходимо узнать имена и номера сотрудников, являющихся начальниками отделов с количеством работников более 10.

(1).выполнить соединение отношений СОТРУДНИКИ и ОТДЕЛЫ по условию СОТР_НОМ = ОТДЕЛ_НАЧ.

С1 = СОТРУДНИКИ [СОТР_НОМ = ОТД_НАЧ] ОТДЕЛЫ

(2).из полученного отношения произвести выборку по условию ОТД_КОЛ > 10

С2 = С1 [ОТД_КОЛ > 10].

(3).спроецировать результаты предыдущей операции на атрибуты СОТР_ИМЯ, СОТР_НОМЕР

С3 = С2 [СОТР_ИМЯ, СОТР_НОМЕР]

На языке реляционного исчисления данный запрос может быть записан как:

Выдать СОТР_ИМЯ и СОТР_НОМ для СОТРУДНИКИ таких, что

существует ОТДЕЛ с таким же, что и СОТР_НОМ значением ОТД_НАЧ

и значением ОТД_КОЛ большим 50.

 

Указываются только характеристики результирующего отношения, но не указываем о способе его формирования. СУБД сама должна решить какие операции и в каком порядке надо выполнить над отношениями СОТРУДНИКИ и ОТДЕЛЫ.

Физическое проектирование

Анализ сущностей инфологической модели, их атрибутов и связей позволяет сделать вывод: каждая сущность может быть представлена отдельной таблицей, причем все они уже находятся в третьей нормальной форме.

Переход от логического к физическому описанию модели состоит из следующих шагов:

1. Все простые сущности превращаются в отношения, имя сущности становится именем отношением.

2. Каждый атрибут становится возможным столбцом с тем же именем. Столбцы, соответствующие необязательным атрибутам, могут содержать NULL - значения.

3. Компоненты уникального идентификатора сущности превращаются в первичный ключ отношения.

4. Связи "многие к одному" становятся внешними ключами.

5. В таблицах, построенных на основе ассоциаций, внешние ключи используются для идентификации участников ассоциаций, а в таблицах, построенных на основе характеристик, внешние ключи используются для идентификации сущностей, описываемых этими характеристиками.

6. Разрешение проблемы наличия подтипов.

7. Выполнение шагов по нормализации полученных отношений. Имеющаяся модель находится в третьей нормальной форме.

8. Указание ограничений целостности проектируемой базы данных и краткое описание полученных таблиц и их полей.

Учитывая прямое соответствие логическое модели и физической реализации, последняя четко отражает первую, внося некоторые уточнения по способу хранения информации. То есть с учетом всего выше сказанного о разработке логической модели АС и логической схемы БД получена физическая модель БД.

Основные функции СУБД.

1. Непосредственное управление данными во внешней памяти -включает обеспечение необходимых структур внешней памяти как для хранения данных, непосредственно входящих в БД, так и для служебных целей, например, для убыстрения доступа к данным в некоторых случаях. 2. Управление буферами оперативной памяти. СУБД обычно работают с БД значительного размера. Единственным способом реального увеличения скорости работы с БД является буферизация данных в оперативной памяти. 3. Управление транзакциями. Транзакция - последовательность операций над БД, рассматриваемых СУБД как единое целое. Либо транзакция успешно выполняется, и СУБД фиксирует (COMMIT) изменения БД, произведенные этой транзакцией, во внешней памяти, либо ни одно из этих изменений никак не отражается на состоянии БД. С управлением транзакциями в многопользовательской СУБД связаны важные понятия сериализации транзакций и сериального плана выполнения смеси транзакций. ериализация транзакций - это механизм их выполнения по некоторому сериальному плану. Обеспечение такого механизма является основной функцией компонента СУБД, ответственного за управление транзакциями. Система, в которой поддерживается сериализация транзакций обеспечивает реальную изолированность пользователей. Сериальный план выполнения смеси транзакций - это такой план, который приводит к сериализации транзакций. 4. Журнализация. Одним из основных требований к СУБД является надежность хранения данных во внешней памяти. Под надежностью хранения понимается то, что СУБД должна быть в состоянии восстановить последнее согласованное состояние БД после любого аппаратного или программного сбоя. Журнал - это особая часть БД, недоступная пользователям СУБД и поддерживаемая с особой тщательностью, в которую поступают записи обо всех изменениях основной части БД. 5. Поддержка языков БД. Для работы с базами данных используются специальные языки, в целом называемые языками баз данных. В ранних СУБД поддерживалось несколько специализированных по своим функциям языков. Чаще всего выделялись два языка - язык определения схемы БД (SDL - SchemaDefinitionLanguage) и язык манипулирования данными (DML - DataManipulationLanguage). SDL служил главным образом для определения логической структуры БД, т.е. той структуры БД, какой она представляется пользователям.

DML содержал набор операторов манипулирования данными, т.е. операторов, позволяющих заносить данные в БД, удалять, модифицировать или выбирать существующие данные. В современных СУБД обычно поддерживается единый интегрированный язык, содержащий все необходимые средства для работы с БД, начиная от ее создания, и обеспечивающий базовый пользовательский интерфейс с базами данных. Стандартным языком наиболее распространенных в настоящее время реляционных СУБД является язык SQL (StructuredQueryLanguage).

Прежде всего, язык SQL сочетает средства SDL и DML, т.е. позволяет определять схему реляционной БД и манипулировать данными.

Язык SQL содержит специальные средства определения ограничений целостности БД. Специальные операторы языка SQL позволяют определять так называемые представления БД, фактически являющиеся хранимыми в БД запросами (результатом любого запроса к реляционной БД является таблица) с именованными столбцами. Наконец, авторизация доступа к объектам БД производится также на основе специального набора операторов SQL. Идея состоит в том, что для выполнения операторов SQL разного вида пользователь должен обладать различными полномочиями.

Процедурные объекты Oracle

Для программирования алгоритмов обработки данных, реализации механизмов поддержки целостности базы данных Oracle использует такие объекты как процедура, функция, пакет и триггер. Для написания этих программных единиц используется встроенный в Oracle процедурный язык программирования PL/SQL (ProgramLanguage/SQL).

Функция (FUNCTION) – это поименованный, структурированный набор переменных и операторов SQL и PL/SQL, предназначенный для решения конкретной задачи и возвращающий значение (результат работы) в вызывающую программу (среду).

Процедура (PROCEDURE) – это поименованный, структурированный набор переменных и операторов SQL и PL/SQL, предназначенный для решения конкретной задачи. Процедура не возвращает значений в вызывающую программу (среду).

Пакет (PACKAGE) – это поименованный, структурированный набор переменных, процедур и функций, связанных единым функциональным замыслом. Например, Oracle поставляет пакет DBMS_OUTPUT, в котором собраны процедуры и функции, предназначенные для организации ввода-вывода.

Триггер (TRIGGER) – это хранимая процедура, которая автоматически запускается тогда, когда происходит связанное с триггером событие. Обычно события связаны с выполнением операторов INSERT, UPDATE или DELETE в некоторой таблице.

Типы данных.

В СУБД Oracle используются следующие основные типы данных:

Примечание: параметры, заключённые в квадратные скобки, можно не указывать. Тогда будет использоваться значение по умолчанию.

Символьные:

CHAR [(длина)] – используется для хранения символьных строк фиксированной длины. Длина строки по умолчанию – 1 байт, максимальная длина – 2000б.

VARCHAR2 (длина) – используется для хранения символьных строк переменной длины. Параметр длина определяет максимальную длину строки, значение этого параметра не может превышать 4000.

Числовые:

NUMBER [(точность[, масштаб])] – используется для представления чисел с заданной точностью.

Если значение параметра точность не указано явно, оно полагается равным 38. Значение параметра масштаб по умолчанию предполагается равным 0. Значение параметра точность может изменяться от 1 до 38; значение параметра масштаб может изменяться от -84 до 128. Использование отрицательных значений масштаба означает сдвиг десятичной точки в сторону старших разрядов. Например, определение NUMBER (7, -3) означает округление до тысяч.

Примечание: в СУБД Oracle существуют и другие типы числовых данных, но тип NUMBER является базовым, поэтому лучше пользоваться именно этим типом данных.

Календарные:

DATE – хранит дату и время с точностью до секунды, занимает 7 байт.

Агрегирование данных

Язык SQL включает группу функций, которые называются агрегирующими и позволяют производить различные подсчеты на таблицах:

· COUNT – определяет в результате количество строк (записей) или значений поля, не являющихся NULL -значениями. Применяется к записям и полям любого типа.

· MAX, MIN – определяет максимальное (минимальное) значение указанного поля в результирующем множестве. Применяется к полям любого типа.

· SUM – определяет арифметическую сумму значений указанного числового поля в результирующем множестве записей. Применяется только к числовым полям.

· AVG – определяет среднее арифметическое значений указанного числового поля в результирующем множестве записей (не учитывает NULL -значения, и сумма значений поля делится на количество определённых значений). Применяется только к числовым полям.

Пример -- Количество сотрудников:selectcount(*) fromemp;

Группировка данных

Агрегирующие функции обычно используются совместно с предложением GROUP BY. Например, следующая команда позволяет посчитать количество сотрудников по отделам:

selectdepno, count(*) ascnt, 'сотрудник(а)'

fromemp

group by depno;

Работает эта команда так. Система группирует все записи таблицы Emp по значению поля deptNo (номер отдела), т.е. создаёт на каждое значение одну запись в результирующей таблице. А функция count(*) позволяет посчитать, сколько записей исходной таблицы образуют каждую группу (т.е. имеют такое значение поля deptNo).

Для предложения GROUP BY существует строгое правило:

В списке выбора при использовании GROUP BY могут быть указаны только функции агрегирования, константы и поля, перечисленные в GROUP BY.

Если включить в список выбора поля, не указанные в GROUP BY, то СУБД не будет разбирать такой запрос и выдаст ошибку "нарушение условия группирования" (not a GROUP BY expression).

Группировку можно проводить и по нескольким полям. В этом случае результат будет содержать по одной записи на каждую комбинацию значений полей, по которым проводится группировка.

Работа с курсорами

Курсор – поименованный запрос, содержащий некоторое фиксированное число строк выборки.

Курсор является окном, через которое пользователь получает доступ к информации БД. SQL неявно объявляет курсор для всех SQL-приложений манипулирования данными, включая запросы, возвращающие ровно одну строку. Под курсором в Oracle понимается получаемый при выполнении запроса результирующий набор,а также связанный с ним указатель текущей записи. В SQL поддерживается 2 типа курсоров: явный и неявный.

Явный курсор объявляется разработчиком, а неявный не требует объявления. Курсор может возвращать одну строку, несколько строк или не возвращать их вообще.

Для управления явными курсорами используются следующие операторы:

CURSOR – объявление явного курсора.

OPEN – открывает курсор, создавая новый результирующий набор на базе запроса.

FETCH – последовательное извлечение строк из результирующего набора от начала до конца.

CLOSE – закрывает курсор и освобождает занимаемые им ресурсы.

CURSOR cursor_name[(parameter[,parameter]..)] [RETURN return_type] IS select_statement.

Каждыйпараметр parameter определяетсякак: cursor_ parameter_name [IN] datatype [{:=\DEFAULT} expr].

Тип возвращаемого значения должен соответствовать столбцу, перечисленному в операторе select. Для работы с курсорами можно использовать атрибуты, которые указываются послеимени курсора:

% ISOREN – возвращает “True”, если курсор открыт.

% FOUND – определяет, найдена ли строка удовлетворяющая условию.

% NOTFOUND – возвращает “True”, если строка не найдена.

% ROWCOUNT – номер текущей строки.

Пример создания курсора:

CURSOR c3(p1 INTEGER DEFAULT 10, p2 INTEGER DEFAULT 1300)

IS SELECT f1, f2, f3, f4

FROM tbl1

WHERE f4>p1 AND f2=p2;

При выполнении SQL-оператора, для которого не был явно объявлен курсор, ORACLEавтоматически открывает неявный курсор. При использовании неявного курсора нельзя использовать операторы управления явным курсором.

Целостность баз данных

Средства обеспечения целостности БД включают автоматическую поддержку некоторой системы данных.

Правила реляционной модели:

· Ограничение домена

· Ограничение таблицы

Целостность домена предполагает, что допустимые значения каждого атрибута являются формально определенными. Целостность таблицы означает, что каждая строка в таблице должна быть уникальной.

Типы статических ограничений целостности:

- ограничение на определенность значения атрибута (NOTNULL)

- ограничение на уникальность значения атрибута (UNIQUE) – сервер автоматически запретит выполнение операции по вставке строки, содержащей значение, совпадающее с ранее введенным.

- ограничение – первичный ключ (описывает совокупность атрибутов или атрибут, который для данной таблицы выбран в качестве первичного ключа. При вставке новой строки или модификации атрибутов, входящих в состав первичного ключа, автоматически проверяется уникальность набора их значений и отсутствие неопределенных значений атрибутов)

- ограничение – внешний ключ

Работа с триггерами

Триггер БД – это процедура, которая автоматически запускается при возникновении определенных событий, связанных с выполнением операций вставки, удаления или модификации данных таблицы. Триггер необходим там, где требуется обеспечить сложный контроль защиты данных. Он может также осуществлять контроль, когда требуется более сложная проверка, чем проверка декларативными ограничениями целостности.

Триггер запускается при выполнении одной из 3-х операций изменения содержимого таблицы: INSERT, DELETE, UPDATE.Код триггера может выполняться либо до, либо после тех операторов, которые инициировали его запуск. Код триггера может быть ассоциирован с каждой строкой, над которой выполняется операция. Операторные триггеры обычно используются для проверки файла, оперирующего таблицей в целом.

Построчные – для проверки ограничения целостности при вставке строк.

Взаимовлияние транзакций

Транзакции в многопользовательской БД должны быть изолированы др от др, т.е. в идеале каждая из них должна выполняться так, как будто выполняется только она одна. В реальности же транзакции выполняются одновременно и могут влиять на результаты друг на друга, если они обращаются к одному и тому же набору данных.

Взаимовлияние пишущих транзакций на читающие может проявляться в виде:

1. Чернового чтения

2. Неповторяемого чтения

3. Фантома

Неповторяемого чтения: транзакция видит изменения внесенные другими незавершенными транзакциями.

Фантомы – особый тип неповторяемого чтения. Их возникновение может происходить в ситуации, когда одна и та же транзакция сначала производит обновление набора данных, а затем считывание этого же набора. Если считывание начинается раньше, чем заканчивается их обновление, то в результате чтения можно получить несогласованный набор данных. При последующих запросах это явление пропадает, т.к. на самом деле запрошенные данные после завершения обновления будут согласованными согласно свойствам транзакции.

Работа с индексами.

Индексы обычно создаются с целью удовлетворенияопределённых критериев поиска. После того как таблица уже находилась некоторое время в работе и увеличилась в размерах.

Создания индекса не предусмотрено созданием стандарта языка SQL. ОднакоподдерживаютсяследующиеоператорыCreateindex [UNIQUE] indexnameONtablename (column [ASCLDESC])

Указанные в операторе столбцы составляют ключ в индексе, должны быть перечислены в возрастающем или убывающем порядке. Индексы могут создаваться только для таблиц, а не для представления. Если в операторе указано ключевое слово UNIQUE уникальное значения ключа индекса будет поддерживаться автоматически система. Требования уникальности значении обязательно для первичных ключей. Для каждого из ключевых столбцов должен быть указан порядок сортировки значений по возрастанию и по убыванию. Если сортировка не задана, то по умолчанию по возрастающей.
44. Оптимизация запросов в реляционных СУБД.

Каждая команда языка манипулирования данными может быть выполнена разными способами. Определение наиболее оптимального плана выполнения запроса называется оптимизацией. Выбором этого плана занимается оптимизатор – специальная компонента СУБД. Выполнение запроса состоит из последовательности шагов, каждый из которых либо физически извлекает данные из памяти, либо делает подготовительную работу. Последовательность шагов, которую строит оптимизатор, называется планом выполнения.

Обработка запроса, поступившего в систему и представленного на некотором языке запросов, состоит из этапов или фаз. На первой фазе запрос, представленный на языке запросов, подвергается лексическому и синтаксическому анализу. При этом вырабатывается его внутреннее представление, отражающее структуру запроса и содержащее информацию, которая характеризует объекты базы данных, упомянутые в запросе (отношения, поля и константы). На второй фазе запрос в своем внутреннем представлении подвергается логической оптимизации. При этом могут применяться различные преобразования, "улучшающие" начальное представление запроса. Среди этих преобразований могут быть эквивалентные преобразования, после проведения, которых получается внутреннее представление, семантически эквивалентное начальному (например, приведение запроса к некоторой канонической форме). Преобразования могут быть и семантическими, когда получаемое представление не является семантически эквивалентным начальному, но гарантируется, что результат выполнения преобразованного запроса совпадает с результатом запроса в начальной форме при соблюдении ограничений целостности, существующих в базе данных. Третий этап обработки запроса состоит в выборе на основе информации, которой располагает оптимизатор, набора альтернативных процедурных планов выполнения данного запроса в соответствии с его внутреннем представлением, полученным на второй фазе. Основой является информация о существующих путях доступа к данным. Единственный путь доступа, который возможен в любом случае, – это последовательное чтение (FULL). На этом же этапе для каждого плана оценивается предполагаемая стоимость выполнения запроса по этому плану. При оценках используется либо доступная оптимизатору статистическая информация о состоянии базы данных, либо информация о механизмах реализации различных путей доступа. Из полученных альтернативных планов выбирается наиболее оптимальный с точки зрения некоторого (заранее выбранного или заданного) критерия. На четвертом этапе по внутреннему представлению наиболее оптимального плана выполнения запроса формируется процедурное представление плана. Выполняемое представление плана может быть программой в машинных кодах, если, как в случае System R, система ориентирована на компиляцию запросов в машинные коды, или быть машинно-независимым, но более удобным для интерпретации, если, как в случае INGRES, система ориентирована на интерпретацию запросов. на последнем, пятом этапе обработки запроса происходит его реальное выполнение в соответствии с выполняемым планом запроса. Существуют два принципиально разных подхода к оптимизации запросов. Если оптимизатор основывается только на информации о механизмах реализации путей доступа, то метод оптимизации основан на синтаксисе (на правилах, RULE). Если же помимо этого используется статистическая информация о распределении данных, то это метод оптимизации, основанный на стоимости (на издержках, COST). Рассмотрим эти подходы подробнее.

Методы оптимизации запросов

Метод оптимизации, основанный на синтаксисе. При использовании этого метода план составляется на основании существующих путей доступа и их рангов. Все пути доступа ранжируются на основании знаний о правилах и последовательности осуществления этих путей. Ранг пути доступа определяется на основании знаний о последовательности реализации этого пути. Например, самый быстрый способ доступа – это чтение по КБД: если он известен, то это одно физическое чтение. А поиск конкретного значения через индекс (ранг 9) обычно занимает меньше времени, чем поиск в закрытом интервале (ранг 10). Метод оптимизации по синтаксису учитывает ранги путей доступа. Если для какой-либо операции существует более одного пути доступа, то выбирается тот путь, чей ранг выше, т.к. в большинстве случаев он выполняется быстрее, чем путь с более низким рангом.

Метод оптимизации, основанный на стоимости. При использовании этого метода оптимизатор сначала строит несколько возможных планов выполнения запроса. При этом он применяет некоторые эвристики, т.е. правила, полученные опытным путем. Эти правила позволяют сузить пространство поиска оптимального плана благодаря тому, что неэффективные планы отбрасываются в самом начале и не рассматриваются. Для каждого из построенных планов рассчитывается его стоимость. Стоимость – это оценка ожидаемого времени выполнения запроса с использованием конкретного плана выполнения. При расчёте стоимости оптимизатор может учитывать такие параметры, как: количество необходимых ресурсов памяти, время операций дискового ввода-вывода, время процессора.

Из множества возможных планов выполнения запроса (обычно, 2-3 плана) оптимизатор в соответствии с критерием выбирает лучший план.

Критерии оптимизации: 1.Наилучшая общая производительность системы. 2. Минимальное время реакции – время, необходимое для обработки и выдачи первой строки. 3.Минимальные затраты времени на обработку всех строк, к которым обращается данная команда.

Стоимость плана выполнения запроса определяется на основании сведений о распределении данных в таблицах, к которым обращается команда, и связанными с ними кластерами и индексами. Эти сведения о распределении значений данных называются статистикой. Статистика может включать в себя: *количество блоков данных, занимаемых таблицей; *количество записей в таблице; *среднюю длину записей в таблице; *минимальные и максимальные значения данных по столбцам; *количество различных значений по столбцам и т.п.

В Oracle статистика собирается командой ANALYZE, которая имеет два вида – для точного расчёта статистики и для её оценки:

ANALYZE {table | index} <имя> compute statistics;

ANALYZE {table | index} <имя> estimate statistics on <число> {percent | rows};

Если таблица (индекс) небольшая (несколько тысяч строк), то следует рассчитывать статистику, например:

ANALYZE table EMP compute statistics;

Если таблица (индекс) большая, то статистику можно оценить, например:

ANALYZE table EMP estimate statistics on 2000 rows; -- по 2000 строк

ANALYZE index IND_EMP estimate statistics on 20 percent; -- по 20 процентам

Имейте в виду, при оценке статистики производится случайный выбор строк, при котором точность оценки распределения значений достигает 0.05%.

Методы защиты БД.

Существуют различные приемы управления доступом, обеспечивающие разный уровень безопасности.

Шифрование / дешифрование.

Шифрование БД – это простейший способ защиты, при котором файл БД видоизменяется и становится недоступным для чтения с помощью стандартных служебных программ или текстовых редакторов. Шифрование незащищенной БД неэффективно, поскольку исходную БД можно открыть и получить полный доступ к ее объектам. Шифрование применяется при электронной передаче БД или сохранении ее на внешних носителях. Дешифрование БД – это операция, обратная шифрованию.

Использование пароля.

Простым способом защиты является установка пароля для открытия БД. При каждом открытии БД будет появляться диалоговое окно, в которое требуется ввести пароль. Может быть установлен единый пароль для всех пользователей, но наиболее гибким является способ, при котором пароль присваивается каждому пользователю. Для каждого пользователя могут быть определены объекты, доступ к которым он получает. Учет и хранение паролей производится самой СУБД.

Восстановление БД.

Итак, общей целью журнализации изменений баз данных является обеспечение возможности восстановления согласованного состояния базы данных после любого сбоя. Общими принципами восстановления являются следующие:

5. результаты зафиксированных транзакций должны быть сохранены в восстановленном состоянии базы данных (т.е. должно поддерживаться свойство долговечности (durability) транзакций);

6. результаты незафиксированных транзакций должны отсутствовать в восстановленном состоянии базы данных (в противном случае состояние базы данных могло бы оказаться не целостным).

Возможны следующие ситуации, при которых требуется производить восстановление состояния базы данных:

7. Индивидуальный откат транзакции. Тривиальной ситуацией отката транзакции является ее явное завершение оператором ROLLBACK. Возможны также ситуации, когда откат транзакции инициируется системой. Примерами могут быть возникновение исключительной ситуации в прикладной программе (например, деление на ноль) или выбор транзакции в качестве жертвы при разрушении синхронизационного тупика. Для восстановления согласованного состояния базы данных при индивидуальном откате транзакции нужно устранить последствия операторов модификации базы данных, которые выполнялись в этой транзакции.

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

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

Во всех трех случаях основой восстановления является хранение избыточных данных. Эти избыточные данные хранятся в журнале, содержащем последовательность записей об изменении базы данных.

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

Данный подход позволяет быстро выполнять индивидуальные откаты транзакций, но приводит к дублированию информации в локальных и общем журналах. Поэтому чаще используется второй вариант – поддержка только общего журнала изменений базы данных, который используется и при выполнении индивидуальных откатов. Здесь мы рассматриваем именно этот вариант.

BDE. Фирма Borland разработала собственную технологию доступа к данным SQL Links, имеющую возможность взаимодействовать с ODBC через специальные «интерфейс-мосты». Технология BDE является набором динамических библиотек, которые предоставляют интерфейсы, позволяющие передавать запросы на получение или модификацию данных из приложения в нужную базу данных и получать результат обработки. В процессе работы библиотеки используют вспомогательные файлы языковой поддержки и информацию о настройках среды.

Для разработчика BDE предоставляет множество преимуществ:

· непосредственный доступ к локальным базам данных (dBase, Paradox, текстовые файлы);

· доступ к SQL-серверам (Oracle, Sybase, MS SQL server, InterBase, Informix, DB2) с помощью набора драйверов Borland SQL Links;

· доступ к любым источникам данных, имеющим драйвер ODBC, например к файлам электронных таблиц (Excel, Lotus 1-2-3), и серверам баз данных, не имеющим драйверов SQL Links;

· создание приложений «клиент-сервер», использующих разнородные данные;

· использование SQL, в том числе и при работе с локальными данными;

· изоляцию приложения от средств языковой поддержки.

Основные конструкции OLE DB

На верхнем уровне абстракции можно выделить три главных компонента: потребители; провайдеры данных; провайдеры сервисов.

Провайдеры выполняют несколько задач: принятие запросов на доступ к данным, поступающих от потребителя; выполнение выборки и обновления данных; передача результатов потребителю

Провайдер сервисов реализует расширенные возможности, которые не поддерживаются обычными провайдерами данных, и сам не «владеет» данными.

ADO. Технология Microsoft ActiveX Data Object (ADO) представляет собой высокотрехуровневую объектную надстройку над OLE DB. ADO может использоваться для работы с любыми провайдерами OLE DB.

Объект Connection инкапсулирует в себе объекты OLE DB DataSource и Session. От содержит единственную сессию с источником данных. Объект определяет свойства соединения, определяет возможности локальных транзакций, предоставляет централизованный объект для получения информации об ошибках Error и указатели для использования схем запросов.