Восстановление базы данных. Журнал транзакций. Контрольные точки.

Восстановление БД – это процесс возвращения ее в корректное состояние, утраченное в результате сбоя или отказа системы.

Возможные причины отказа:

1. ­ аварийное прекращение работы системы, вызванное ошибкой оборудования или ошибкой СУБД, приведшей к разрушению оперативной памяти

2. ­отказ физических носителей информации

3. ­ошибки прикладных программ, послужившие причиной сбоев при выполнении некоторых транзакций

4. стихийные бедствия

5. ­непреднамеренное или преднамеренное разрушение данных пользователями или при внешних атаках.

Типичная СУБД должна иметь следующие функции восстановления:

1. механизм резервного копирования. Резервная копия может представлять собой либо файл в уникальном формате, который может быть открыт только конкретной СУБД, либо текстовый файл, содержащий команды SQL и позволяющий создать БД (create table, insert). Такой файл иногда называют скриптом. Резервная копия отличается от простого копирования тем, что не требует остановки СУБД. Резервное копирование можно выполняться для БД в целом или для ее отдельных таблиц или для отдельных файлов БД. Резервное копирование может выполняться в полном объеме, либо в так называемом инкрементном режиме или режиме отличий. Во 2ом случае резервная копия будет содержать только те данные, которые были изменены с момента последней полной копии.

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

· ­ идентификатор транзакции;

· ­ тип операции (начало транзакции, завершение транзакции, insert, delete, update);

· ­ идентификатор элемента данных, над которым выполняется операция;

· ­значение этого элемента до начала операции;

· ­ значение элемента после завершения операции;

· ­ указатели на предыдущую и последующую операции этой транзакции.

3. контрольная точка (checkpoint). Помещаемая в журнал информация используется в процессе восстановления после сбоя. Возникает вопрос – насколько далеко необходимо откатиться в журнале транзакций, чтобы начать обработку транзакций активных на момент сбоя? Контрольная точка – это запись в журнале транзакций, означающая момент синхронизации между журналом и основным файлом БД, т.е. это тот момент, когда вся информация из оперативной памяти переносится на диск. Журнал БД имеет тенденцию к быстрому увеличению, поэтому необходимо иметь механизм усечения журнала транзакций. Журнал транзакций усекается до последней контрольной точки.

Вопрос №9

Понятия целостности и безопасности данных

Термины безопасность и целостность часто используются совместно.

Безопасность – это защита данных от несанкционированного доступа. Целостность – это требование к точности и непротиворечивости данных.

Иначе говоря, безопасность – это разрешенные пользователям действия, а целостность – это действия, не приводящие БД к противоречивым состояниям.

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

При обеспечении безопасности и целостности данных выделяют два уровня:

1. Программный. Подразумевает распределение прав пользователей на программы или на функции внутри программы; наличие кода программы не позволяющего вносить не корректные данные.

2. Уровень СУБД, т.е. реализация правил на уровне СУБД. Обеспечивать безопасность и целостность на уровне СУБД обязательно, т.к. отсутствие правил может привести к нарушению конфиденциальности информации или ее противоречивости.

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

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

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

Проектирование информационных систем

28) Жизненный цикл информационных систем: этапы планирования разработки, определения требований, сбора и анализа требований, проектирования БД и выбора СУБД.

29) Жизненный цикл информационных систем: этапы разработки приложений, создания прототипов, реализации, конвертирования и загрузки данных, тестирования, эксплуатации

Вопросы №28, 29

Информационная система – ресурсы, которые позволяют выполнить сбор, корректировку и распространение информации. Типичная информационная система (ИС) состоит из БД, ПО БД, прикладного ПО, аппаратное обеспечение и персонал.

Жизненный цикл ИС.

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

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

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

1 – Планирование разработки ИС;

2 – Определение требований к системе;

14 – сбор и анализ требований к с-ме;

3 – Концептуальное планирование БД;

4 – Логическое проектирование БД;

5 – Физическое проектирование БД;

6 – Проектирование БД;

7 – Выбор целевой СУБД;

8 – Разработка приложений;

9 – Реализация;

10 – Создание прототипов;

11 – Конвертирование и загрузка существующих

данных;

12 – Тестирование

13 – Эксплуатация и сопровождение

Планирование разработки ИС. Выполняются подготовительные

действия, позволяющие с максимально возможной эф-тью реализовывать

этапы ЖЦ. На этом этапе решаются следующие задачи: определение

бизнес-плана и целей организации с последующим выявлением

ее потребностей в ИТ; оценка показателей уже существующих ИС с целью

выявления их сильных и слабых сторон; определение возможностей использования ИТ для достижения конкурентного преимущества фирмы.

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

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

Определение требований к с-ме. Определяется диапазон действий, границы разрабатываемой ИС, состав пользователей и область применения.

Сбор и анализ требований к с-ме. На этом этапе собирается и анализируется информация той части предприятия, для которой разрабатывается ИС. Результатом этого анализа является полный набор требований пользователей к системе, обычно информация собирается следующим образом: опрос работников организации; наблюдение за деятельностью предприятия; изучение документов; использование опыта разработки предыдущих ИС; анкетирование.

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

Проектирование БД.На этом этапе создается проект БД, предназначенный для поддержки функционирования, организации и достижения ее целей.

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

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

Физическое проектирование. Создается описание реализации БД на запоминающих устройствах с указанием способов хранения и методов доступа к данным. Для реляционной модели этот этап включает следующее: создание набора таблиц и ограничений для них; определение методов доступа к данным и разработка средств защиты проектируемой с-мы.

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