Отче т по производственной практике пм 01 Эксплуатация и модификация информационных систем по специальности



страница4/4
Дата14.01.2020
Размер1.46 Mb.
Название файла-
ТипКраткое содержание
1   2   3   4


1. Общие сведения


1.1. Наименование системы

Полное наименование: База Данных: Классный руководитель.

Краткое наименование: БД Классный руководитель.

1.2. Основания для проведения работ

Работа выполняется на основании договора № 32 от 12.02.18

1.3. Наименование организаций – Заказчика и Разработчика

1.3.1. Заказчик

Заказчик:МБОУ СОШ №15


Адрес фактический: г. Арзамас
Телефон: +7 (495) 2222222
Факс: +7 (495) 2222222

1.3.2. Разработчик

Разработчик: Лукин Андрей
Адрес фактический: г. Арзамас
Телефон: +7 (495) 3333333
Факс: +7 (495) 3333333

1.4. Плановые сроки начала и окончания работы

Сроки выполнения с 12.02.18 по 21.04.18

1.5. Источники и порядок финансирования

Финансирование производится согласно договора №32

1.6. Порядок оформления и предъявления заказчику результатов работ


Работы по созданию ИС сдаются Разработчиком поэтапно в соответствии с календарным планом Проекта. По окончании каждого из этапов работ Разработчик сдает Заказчику соответствующие отчетные документы этапа, состав которых определены Договором.

2. Назначение и цели создания системы

2.1. Назначение системы

Информационная система предназначена для повышения надежности хранения и обработки информации.


Основным назначением ИС является хранение информационно-статистической деятельности в бизнес-процессах Заказчика.
В рамках проекта автоматизируется информационно-аналитическая деятельность в следующих бизнес-процессах:
1. хранение и обработка информации для отчетов;
2. анализ деятельности предприятия и клиентов ; 


2.2. Цели создания системы

Информационная система создается с целью:
- обеспечения сбора и первичной обработки исходной информации, необходимой для подготовки отчетности по показателям деятельности;
- создания единой системы отчетности по показателям деятельности;
- повышения качества (полноты, точности, достоверности, своевременности, согласованности) информации;
- обеспечения безопасности данных;

-облегчения работы с информацией;


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

3. Характеристика объектов автоматизации

Объектом автоматизации выбран один из отделов организации. В рамках отдела было произведен анализ и выделение основных бизнес процессов.
Выделены следующие процессы в деятельности отдела АТС, в рамках которых производится анализ информации и вынесены соответствующие выводы о возможности их автоматизации:

4. Требования к системе

4.1. Требования к системе в целом

4.1.1. Требования к структуре и функционированию системы

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

Определяются требования к режимам функционирования системы.



  1. Система должна быть стабильна в работе.

  2. Необходимо установленное антивирусное программное обеспечение.

  3.  Персональный компьютер должен иметь бесперебойное питание.

4.1.2.3. Требования к надежности технических средств и программного обеспечения
К надежности оборудования предъявляются следующие требования:
- в качестве аппаратных платформ должны использоваться средства с средней надежностью;
- применение технических средств соответствующих классу решаемых задач;
- аппаратно-программный комплекс системы должен иметь возможность восстановления в случаях сбоев.
К надежности электроснабжения предъявляются следующие требования:
- с целью повышения отказоустойчивости системы в целом необходима обязательная комплектация компьютеров источником бесперебойного питания с возможностью автономной работы системы не менее 5 минут;
- должно быть обеспечено бесперебойное питание активного сетевого оборудования.

4.1.2.4. Требования к методам оценки и контроля показателей надежности на разных стадиях создания системы в соответствии с действующими нормативно-техническими документами.

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

4.1.3. Требования к эргономике и технической эстетике


База данных формирования и визуализации отчетности данных должна обеспечивать удобный для конечного пользователя интерфейс, отвечающий следующим требованиям.
В части внешнего оформления:
- интерфейсы подсистем должен быть типизированы;
В части диалога с пользователем:
- для наиболее частых операций должны быть предусмотрены «горячие» клавиши;
В части процедур ввода-вывода данных:
- должна быть возможность многомерного анализа данных в табличном и графическом видах.

Требования к информационной безопасности


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

4.1.3.1. Требования к антивирусной защите


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

4.1.4. Требования к защите от влияния внешних воздействий

Применительно к программно-аппаратному окружению персонального компьютера предъявляются следующие требования к защите от влияния внешних воздействий.
Требования по стойкости, устойчивости и прочности к внешним воздействиям:
- Информационная система должна иметь возможность функционирования при колебаниях напряжения электропитания в пределах от 155 до 265 В (220 ± 20 % - 30 %);
- Информационная система должна иметь возможность функционирования в диапазоне допустимых температур окружающей среды, установленных изготовителем аппаратных средств.

4.2. Требования к функциям, выполняемым системой

В данном подразделе приводят:
Функция выполняемой системой - это хранение, обработка, и предоставление отчетности по данным из базы данных. База данных должна предоставлять формы для ввода данных и их редактирования. Формы базы данных должны корректно обрабатывать данные и заносить их в таблицы базы данных. База данных должна предоставлять отчеты по различным данным и давать сводный анализ по базе данных.

4.2.1. Подсистема сбора, обработки и загрузки данных


4.2.1.1 Перечень функций, задач подлежащей автоматизации

Управляет процессами сбора, обработки и загрузки данных

Создание, редактирование и удаление процессов сбора, обработки и данных






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

Определение и изменение расписания процессов сбора, обработки и данных













4.3. Требования к видам обеспечения

4.3.1. Требования к информационному обеспечению

Приводятся требования:
1) к составу, структуре и способам организации данных в системе;
2) к информационной совместимости со смежными системами;
3) по использованию общесоюзных и зарегистрированных республиканских, отраслевых классификаторов, унифицированных документов и классификаторов, действующих на данном предприятии;
4) по применению систем управления базами данных;
5) к структуре процесса сбора, обработки, передачи данных в системе и представлению данных;
6) к защите данных от разрушений при авариях и сбоях в электропитании системы;
7) к контролю, хранению, обновлению и восстановлению данных;
8) к процедуре придания юридической силы документам, продуцируемым техническими средствами АС (в соответствии с ГОСТ 6.10.4).

4.3.2.1. Требования по применению систем управления базами данных


Для реализации подсистемы хранения данных должна использоваться промышленная СУБД FoxPro8.4.3.2.2. Требования к контролю, хранению, обновлению и восстановлению данных
К контролю данных предъявляются следующие требования:
- система должна протоколировать все события, связанные с изменением своего информационного наполнения, и иметь возможность в случае сбоя в работе восстанавливать свое состояние, используя ранее запротоколированные изменения данных.
К хранению данных предъявляются следующие требования:
- хранение исторических данных в системе должно производиться не более чем за 5 (пять) предыдущих лет. По истечению данного срока данные должны переходить в архив;
- исторические данные, превышающие пятилетний порог, должны храниться на ленточном массиве с возможностью их восстановления.
К обновлению и восстановлению данных предъявляются следующие требования:
- для базы данных необходимо обеспечить резервное копирование его бинарных файлов раз в 2 недели и хранение копии на протяжении 2-х месяцев;
- для данных хранилища данных необходимо обеспечить резервное копирование и архивацию на ленточный массив в следующие промежутки времени:
   -холодная копия - ежеквартально;
   -логическая копия - ежемесячно (конец месяца);
   -инкрементальное резервное копирование - еженедельно (воскресение);
   -архивирование - ежеквартально;При реализации системы должны применяться следующие языки высокого уровня: SQL и д.р.
Должны выполняться следующие требования к кодированию и декодированию данных: Windows CP1251 для подсистемы хранения данных; Windows CP1251 информации, поступающей из систем-источников.
Для реализации алгоритмов манипулирования данными в базе данных необходимо использовать стандартный язык запроса к данным SQL.

4.3.2. Требования к программному обеспечению

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

- наличие антивируса соответствующий пункту 4.1.7.2. Требования к антивирусной защите.

К обеспечению качества программных средств предъявляются следующие требования:
- функциональность должна обеспечиваться выполнением подсистемами всех их функций.
- надежность должна обеспечиваться за счет предупреждения ошибок - не допущения ошибок в готовых программных средств;
- легкость применения должна обеспечиваться за счет применения покупных программных средств;
- эффективность должна обеспечиваться за счет принятия подходящих, верных решений на разных этапах разработки программных средств и системы в целом;
- сопровождаемость должна обеспечиваться за счет высокого качества документации по сопровождению, а также за счет использования в программном тексте описания объектов и комментариев; использованием осмысленных (мнемонических) и устойчиво различимых имен объектов; размещением не больше одного оператора в строке текста программы; избеганием создания фрагментов текстов программ с неочевидным или скрытым смыслом.
- также на каждом этапе в разработке программных средств должна проводится проверка правильности принятых решений по разработке и применению готовых программных средств.
Необходимость согласования вновь разрабатываемых программных средств с фондом алгоритмов и программ отсутствует.

4.3.4. Требования к организационному обеспечению

Приводятся:
1) требования к защите от ошибочных действий персонала системы.

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


Обеспечивает эксплуатацию информационной системы подразделение информационных технологий Заказчика.
Состав сотрудников каждого из подразделений определяется штатным расписанием Заказчика, которое, в случае необходимости, может изменяться.
К защите от ошибочных действий персонала предъявляются следующие требования:
- должна быть предусмотрена система подтверждения легитимности пользователя при просмотре данных;
- для всех пользователей должна быть запрещена возможность удаления преднастроенных объектов и отчетности;
- для снижения ошибочных действий пользователей должно быть разработано полное и доступное руководство пользователя.

5. Состав и содержание работ по созданию системы

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

6. Порядок контроля и приёмки системы

6.1. Виды и объем испытаний системы
Система подвергается испытаниям следующих видов:
1. Предварительные испытания.
2. Опытная эксплуатация.
3. Приемочные испытания.
Состав, объем и методы предварительных испытаний системы определяются документом «Программа и методика испытаний», разрабатываемым на стадии «Рабочая документация».
Состав, объем и методы опытной эксплуатации системы определяются документом «Программа опытной эксплуатации», разрабатываемым на стадии «Ввод в действие».
Состав, объем и методы приемочных испытаний системы определяются документом «Программа и методика испытаний», разрабатываемым на стадии «Ввод в действие» с учетом результатов проведения предварительных испытаний и опытной эксплуатации.

7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие

В перечень основных мероприятий включают:
1) приведение поступающей в систему информации (в соответствии с требованиями к информационному и лингвистическому обеспечению) к виду, пригодному для обработки с помощью ЭВМ;
2) изменения, которые необходимо осуществить в объекте автоматизации;
3) создание условий функционирования объекта автоматизации, при которых гарантируется соответствие создаваемой системы требованиям, содержащимся в техническое задание ;
4) создание необходимых для функционирования системы подразделений и служб;
5) сроки и порядок комплектования штата и обучения персонала.

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

8. Требования к документированию

В данном разделе приводят:


1) согласованный Разработчиком и Заказчиком перечень подлежащих разработке комплектов и видов документов, соответствующих требованиям ГОСТ 34.201-89 и НТД отрасли Заказчика;
перечень документов, выпускаемых на машинных носителях;
требования к микрофильмированию документации;
2) требования по документированию комплектующих элементов межотраслевого применения в соответствии с требованиями ЕСКД и ЕСПД;
3) при отсутствии государственных стандартов, определяющих требования к документированию элементов системы, дополнительно включают требования к составу и содержанию таких документов.

Вся документация должна быть подготовлена и передана как в печатном, так и в электронном виде (в формате Microsoft Word). 

9. Источники разработки

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

Настоящее Техническое Задание разработано на основе следующих документов и информационных материалов:
- Договор № 32 от 19.03.11
- ГОСТ 24.701-86 «Надежность автоматизированных систем управления».
- ГОСТ 15150-69 «Машины, приборы и другие технические изделия. Исполнения для различных климатических районов. Категории, условия эксплуатации, хранения и транспортирования в части воздействия климатических факторов внешней среды».
- ГОСТ 21958-76 «Система "Человек-машина". Зал и кабины операторов. Взаимное расположение рабочих мест. Общие эргономические требования».
- ГОСТ 12.1.004-91 «ССБТ. Пожарная безопасность. Общие требования».
- ГОСТ Р 50571.22-2000 «Электроустановки зданий».

Проектирование или изменение инфологической модели имеющейся БД.


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

Основными свойствами, которым должна удовлетворять инфологическая модель БД, являются прежде всего следующие:

1. Предметная область должна быть описана адекватно и непротиворечиво.

2. Все возможные пользователи должны трактовать эту модель однозначно и легко ее воспринимать.

3. При необходимости инфологическая модель должна иметь возможность легко модифицироваться, подвержена композиции и декомпозиции.

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

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

Первым шагом при разработке инфологической модели БД является описание объектов предметной области и связей между ними. Инфологическое моделирование направлено на отображение семантики (то есть смысла) предметной области на модель БД. На ранних этапах развития теории БД было предложено несколько семантических моделей. Все эти модели имели свои преимущества и недостатки и к настоящему моменту времени в подавляющем большинстве случаев используется так называемая модель “сущность-связь”. Эта модель называется также методом ER-диаграмм или ER-моделей (Essence - сущность, Relation - связь).



Отношение изображается линией между двумя сущностями.ER – модель по методологии Баркера представлена на Рисунке 1

Рис 1 инфологическая модель базы данных по методологии Баркера

В настоящее время существует целый ряд автоматизированных средств проектирования ER-моделей, называемых CASE-средствами. Среди них следует отметить Design/IDEF, Power Designer,Oracle. Использование этих средств дает ряд преимуществ, к которым относятся: снижаются требования к знанию языков описания данных и конкретных СУБД; автоматически контролируются целостность и согласованность схемы описания БД; сокращается в целом время проектирования; появляется возможность автоматического тестирования проекта на разных стадиях его проектирования.

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

1. Определение сущностей и выявление связей между ними.

2. Построение ER-диаграммы с учетом всех сущностей и связей между ними.

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

4. Нормализация предварительных отношений, приведение их по возможности к нормальной форме Бойса-Кодда

Создание или модификация имеющейся БД.
Все данные, хранящиеся в базе данных, находятся в следующих таблицах:


  1. Данные ученика;

  2. Данные о родителях;

  3. Группа здоровья;

  4. Классные часы;

  5. Предметы;

  6. Пропуски;

  7. Расписание уроков;

  8. Успеваемость;

  9. Учителя;

  10. Журнал по ТБ.

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


Таблица Данные ученика

В таблице Данные ученика хранится информация о учениках, структура таблице показана на рисунке 2.


Рисунок 2 Таблица Данные ученика в режиме Конструктора




Рис. 3 Таблица Данные ученика



Таблица Данные о родителях
В таблице Данные о родителях хранится информация о родителях учеников.

Рис. 4 Таблица Данные о родителях в режиме Конструктора




Рис. 5 Таблица Данные о родителях

Таблица Группа здоровья


В таблице Группа здоровья хранится информация о здоровье учеников.

Рис. 6 Таблица Группа здоровья в режиме Конструктора


Рис. 7 Таблица Группа здоровья
Таблица Классные часы
В таблице Классные часы хранится информация о проведённых классных часах.

Рис. 8 Таблица Классные часы в режиме Конструктора


Рис. 9 Таблица Классные часы



Таблица Предметы
В таблице Предметы хранится информация о предметах.

Рис. 10 Таблица Предметы в режиме Конструктора



Рис. 11 Таблица Предметы



Таблица Успеваемость
В таблице Успеваемость хранится информация о успеваемости учеников.

Рис. 12 Таблица Успеваемость в режиме Конструктора



Рис. 13 Таблица Успеваемость



Таблица Пропуски
В таблице Пропуски хранится информация о пропусках занятий.

Рис. 14 Таблица Пропуски в режиме Конструктора



Рис. 15 Таблица Пропуски



Таблица Расписание уроков
В таблице Расписание уроков хранится информация о расписании уроков.


Рис. 16 Таблица Расписание уроков в режиме Конструктора


Рис. 17 Таблица Расписание уроков
Таблица Учителя
В таблице Учителя хранится информация о учителях.



Рис. 18 Таблица Учителя в режиме Конструктора

Рис. 19 Таблица Учителя


Таблица Журнал по ТБ
В таблице Журнал по ТБ хранится информация по технике безопасности.



Рис. 20 Таблица Журнал по ТБ в режиме Конструктора

Рис. 21 Таблица Журнал по ТБ


Исходя из инфологической модели и назначения БД была построена схема базы данных.

Схема данных изображена ниже



Рис. 22 Схема базы данных классного руководителя

Проверка и обеспечение целостности в БД.

Обеспечение целостности БД составляет необходимое условие успешного функционирования БД. Целостность БД есть свойство базы данных, означающее, что в ней содержится полная, непротиворечивая, согласованная и адекватно отражающая предметную область информация. Мы привыкли доверять данным, помещаемым в печатных изданиях. При подготовке книги размещаемые в ней данные проверяют несколько редакторов. Они же стараются сделать так, чтобы книга была написана грамотно и соответствовала неким нормам. Например, при чтении детектива было бы странно встретить детальный химический и физический анализ остатков пепла со ссылками на научную литературу. При общении с компьютером соблюдается все тот же принцип, т.е. компьютер сравнивается с известным издательством. Если что-то сделано на компьютере, то большинство людей этому слепо верит, мотивируя тем, что компьютер не может ошибаться. Но это не совсем так. О достоверности данных придется забыть, если в компьютер будут помещены некорректные данные или они могут стать некорректными вследствие сбоев, ошибок и т.д.

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

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

К средствам обеспечения целостности данных на уровне СУБД относятся:

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

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

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

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

· Ограничители значений. К ним относятся:

- задание типа и формата, которые позволяют ввод только определенных данных (задание типа Дата в формате дд.мм.гггг позволит ввести правильную дату);

- задание диапазона значений;

- задание списка значений;

· Ссылочная целостность. Обеспечивается контролем отношений между связанными данными и введением каскадного удаления и обновления связанных записей;

· Целостность записи. Обеспечивается проверкой на уникальность некоторых данных и объявлением обязательных данных.

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

· атомарность (выполняются все входящие в транзакцию операции или ни одна);

· согласованность (любая транзакция должна переводить БД из одного согласованного состояния в другое согласованное состояние);

· изолированность (транзакции выполняются независимо друг от друга);

· безопасность (даже аварийное завершение работы не приводит к потери данных).



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

Поделитесь с Вашими друзьями:
1   2   3   4


База данных защищена авторским правом ©genew.ru 2020
обратиться к администрации

    Главная страница
Контрольная работа
Курсовая работа
Лабораторная работа
Рабочая программа
Методические указания
Практическая работа
Методические рекомендации
Теоретические основы
Пояснительная записка
Общая характеристика
Учебное пособие
История развития
Общие сведения
Физическая культура
Теоретические аспекты
Практическое задание
Федеральное государственное
Теоретическая часть
Направление подготовки
Техническое задание
Самостоятельная работа
Общие положения
Дипломная работа
государственное бюджетное
Методическая разработка
Образовательная программа
квалификационная работа
Выпускная квалификационная
Технологическая карта
Техническое обслуживание
учебная программа
Решение задач
История возникновения
Методическое пособие
Краткая характеристика
Рабочая учебная
Исследовательская работа
Общие требования
Общая часть
Метрология стандартизация
Рабочая тетрадь
Основная часть
История создания
Техническая эксплуатация
Название дисциплины
Математическое моделирование
Экономическая теория
Государственное регулирование
Современное состояние
Организация работы
Информационная безопасность