- •139 Дипломный проект
- •Дипломный Проект
- •Задание реферат
- •Оглавление
- •Сокращения
- •1. Введение
- •2. Выбор операционной системы
- •2.1. Определение операционной системы
- •2.2. Ос как система управления ресурсами
- •2.3. Классификация ос
- •2.3.1. Особенности алгоритмов управления ресурсами
- •2.3.1.1. Поддержка многозадачности.
- •2.3.1.2. Поддержка многопользовательского режима.
- •2.3.1.3. Вытесняющая и невытесняющая многозадачность
- •2.3.1.4. Поддержка многонитевости
- •2.3.1.5. Многопроцессорная обработка
- •2.3.1.6. Поддержка сети
- •2.3.2. Особенности аппаратных платформ
- •2.3.3. Особенности областей использования
- •2.3.3.1. Системы пакетной обработки
- •2.3.3.2. Системы разделения времени
- •2.3.3.3. Системы реального времени
- •2.4.Обзор сетевых операционных систем
- •2.5. Выбор операционной системы
- •3. Выбор базы данных
- •3.1. Определение субд
- •3.2. Основные функции субд
- •3.2.1. Непосредственное управление данными во внешней памяти
- •3.2.2. Управление буферами оперативной памяти
- •3.2.3. Управление транзакциями
- •3.2.4. Журнализация
- •3.2.5. Поддержка языков бд
- •3.3. Варианты построения информационных приложенийс использованием субд
- •Типовые компоненты информационных приложений
- •3.3.1. Централизованные многотерминальные системы
- •3.3.2. Файл-серверные приложения
- •Варианты построения файл-серверных приложений.
- •3.3.3.Приложения клиент-сервер
- •Варианты построения приложений клиент-сервер.
- •Приложения клиент-сервер на основе многотерминальной системы.
- •4. Выбор языка программирования Классификация средств разработки информационных приложений
- •4.1.Традиционные системы программирования
- •4.2.Инструменты для создания файл-серверных приложений
- •4.3. Средства разработки приложений клиент-сервер
- •4.3.1. Среды разработки приложений для серверов баз данных
- •4.3.2. Средства поддержки распределенных информационных приложений
- •5. Выводы по выбору операционной системы, языка программирования и базы данных
- •6. Структура и основные задачи управления по делам гражданской обороны и чрезвычайным ситуациям
- •6.1. Определение го
- •6.2. Основные задачи го
- •6.3. Схема управления по делам го и чс
- •7. Разработка программного обеспечения для системы управления базой данных объектов го.
- •7.1. Назначение и цели создания программного продукта
- •7.2. Решаемые задачи
- •7.3. Определение необходимых таблиц базы данных
- •7.4. Нормализация базы данных
- •7.4.1. Первая нормальная форма
- •7.4.2. Вторая нормальная форма
- •7.4.3. Третья нормальная форма
- •7.4.4. Четвертая нормальная форма
- •7.4.5. Пятая нормальная форма
- •7.5. Определение столбцов в таблицах
- •7.6. СозданиеSql сценария
- •7.6.1. Создание базы данных
- •7.6.2. Создание таблиц
- •7.6.7. Создание последовательностей
- •7.7.Выбор типа создаваемого приложения
- •7.8. Соглашение о название компонентов в программеGobase
- •7.9. Структура главного меню
- •7.9.1. Меню«Файлы»
- •7.9.2. Меню«Таблицы»
- •7.9.3. Меню«Отчеты»
- •7.9.4. Меню«Помощь»
- •7.10. Проектирование иерархий форм и отчетов
- •7.11. Иерархия форм программы
- •7.12. Основные органы управления форм программыGoBase
- •7.13. Основные формы программы
- •7.13.1. Форма ввода объектов экономики
- •7.13.2. Форма ввода учащихся в умц
- •7.13.3. Форма отчетов (управления)
- •7.14. Экспорт вExcel
- •7.15. Требования к аппаратуре и программным средствам
- •7.16. Установка программы
- •8. Организационно-экономический раздел
- •8.1. Введение
- •8.2. Описание программы
- •8.3. Последовательность выполнения работ
- •8.4. Оценка издержек на разработку программы.
- •8.4.1. СтатьяI. Оплата труда
- •Диаграмма 8.1. Временные затраты на реализацию цикла разработки программного обеспечения
- •8.4.2. СтатьяIi. Материальные ресурсы
- •8.4.3. СтатьяIii.Отчисления на социальные нужды
- •8.4.4. СтатьяIv. Накладные расходы
- •1.4.5. Затраты
- •8.5. Цена программного продукта
- •8.6. Анализ эффективности внедрения программы
- •9. Мероприятия, обеспечивающие оптимальные условия труда пользователя на рабочем месте
- •9.1. Специфика дипломного проекта
- •9.2. Обзор вредных особенностей работы, встречающихся при изготовлении, наладке и эксплуатации программ
- •9.3.1. Работа с монитором
- •9.3.2. Кресло
- •9.3.3. Клавиатура
- •9.3.4. Эффекты отражения и рабочий стол.
- •9.3.5. Оригиналодержатель
- •9.3.6. Шумы
- •9.3.7. Выделение избытков теплоты
- •9.4. Анализ категории тяжести труда инженера-программиста.
- •9.5. Анализ освещения на рабочем месте программиста.
- •9.6. Вывод
- •10. Применение эвм для повышения эффективности работы штаба го
- •10.1. Задачи гражданской обороны.
- •10.2. Основной расчет поражающих факторов ядерного взрыва
- •10.2.1. Исходные данные:
- •10.2.2. Выходные данные:
- •10.3. Текст программы
- •10.4. Проврка работоспособности
- •10.5. Выводы:
- •11. Эргономическая оценка информационного обеспечения эвм
- •11.1. Введение
- •11.2. Проектирование форм
- •11.3. Формы выдачи решений
- •11.4. Интерактивные формы.
- •11.5.Формы ввода данных.
- •11.6. Проектирование отчетов.
- •12. Выводы
- •13. Литература
- •Приложение1 п.1. Техническое задание п.1.1 Общие сведения
- •П.1.2. Постановка задачи
- •П.1.3. Основания для разработки
- •П.1.4. Назначение и цели создания программного продукта
- •П.1.5. Требования к программе
- •П.1.6. Состав и содержание работ по созданию программы
- •П.1.7. Входная информация
- •П.1.8. Выходная информация
- •Приложение3
- •Приложение4
3.2.4. Журнализация
Одним из основных требований к СУБД является надежность хранения данных во внешней памяти. Под надежностью хранения понимается то, что СУБД должна быть в состоянии восстановить последнее согласованное состояние БД после любого аппаратного или программного сбоя. Обычно рассматриваются два возможных вида аппаратных сбоев: так называемые мягкие сбои, которые можно трактовать как внезапную остановку работы компьютера (например, аварийное выключение питания), и жесткие сбои, характеризуемые потерей информации на носителях внешней памяти. Примерами программных сбоев могут быть: аварийное завершение работы СУБД (по причине ошибки в программе или в результате некоторого аппаратного сбоя) или аварийное завершение пользовательской программы, в результате чего некоторая транзакция остается незавершенной. Первую ситуацию можно рассматривать как особый вид мягкого аппаратного сбоя; при возникновении последней требуется ликвидировать последствия только одной транзакции.
Понятно, что в любом случае для восстановления БД нужно располагать некоторой дополнительной информацией. Другими словами, поддержание надежности хранения данных в БД требует избыточности хранения данных, причем та часть данных, которая используется для восстановления, должна храниться особо надежно. Наиболее распространенным методом поддержания такой избыточной информации является ведение журнала изменений БД.
Журнал - это особая часть БД, недоступная пользователям СУБД и поддерживаемая с особой тщательностью (иногда поддерживаются две копии журнала, располагаемые на разных физических дисках), в которую поступают записи обо всех изменениях основной части БД. В разных СУБД изменения БД журнализуются на разных уровнях: иногда запись в журнале соответствует некоторой логической операции изменения БД (например, операции удаления строки из таблицы реляционной БД), иногда - минимальной внутренней операции модификации страницы внешней памяти; в некоторых системах одновременно используются оба подхода.
Во всех случаях придерживаются стратегии "упреждающей" записи в журнал (так называемого протокола Write Ahead Log - WAL). Грубо говоря, эта стратегия заключается в том, что запись об изменении любого объекта БД должна попасть во внешнюю память журнала раньше, чем измененный объект попадет во внешнюю память основной части БД. Известно, что если в СУБД корректно соблюдается протокол WAL, то с помощью журнала можно решить все проблемы восстановления БД после любого сбоя.
Самая простая ситуация восстановления - индивидуальный откат транзакции. Строго говоря, для этого не требуется общесистемный журнал изменений БД. Достаточно для каждой транзакции поддерживать локальный журнал операций модификации БД, выполненных в этой транзакции, и производить откат транзакции путем выполнения обратных операций, следуя от конца локального журнала. В некоторых СУБД так и делают, но в большинстве систем локальные журналы не поддерживают, а индивидуальный откат транзакции выполняют по общесистемному журналу, для чего все записи от одной транзакции связывают обратным списком (от конца к началу).
При мягком сбое во внешней памяти основной части БД могут находиться объекты, модифицированные транзакциями, не закончившимися к моменту сбоя, и могут отсутствовать объекты, модифицированные транзакциями, которые к моменту сбоя успешно завершились (по причине использования буферов оперативной памяти, содержимое которых при мягком сбое пропадает). При соблюдении протокола WAL во внешней памяти журнала должны гарантированно находиться записи, относящиеся к операциям модификации обоих видов объектов. Целью процесса восстановления после мягкого сбоя является состояние внешней памяти основной части БД, которое возникло бы при фиксации во внешней памяти изменений всех завершившихся транзакций и которое не содержало бы никаких следов незаконченных транзакций. Для того, чтобы этого добиться, сначала производят откат незавершенных транзакций (undo), а потом повторно воспроизводят (redo) те операции завершенных транзакций, результаты которых не отображены во внешней памяти.
Для восстановления БД после жесткого сбоя используют журнал и архивную копию БД. Грубо говоря, архивная копия - это полная копия БД к моменту начала заполнения журнала (имеется много вариантов более гибкой трактовки смысла архивной копии). Конечно, для нормального восстановления БД после жесткого сбоя необходимо, чтобы журнал не пропал. Как уже отмечалось, к сохранности журнала во внешней памяти в СУБД предъявляются особо повышенные требования. Тогда восстановление БД состоит в том, что исходя из архивной копии по журналу воспроизводится работа всех транзакций, которые закончились к моменту сбоя. В принципе, можно даже воспроизвести работу незавершенных транзакций и продолжить их работу после завершения восстановления. Однако в реальных системах это обычно не делается, поскольку процесс восстановления после жесткого сбоя является достаточно длительным.