Диплом: Проектирование информационной системы учета и ведения документации на примере "МТУ №4 МИНИСТЕРСТВА СОЦИАЛЬНОГО РАЗВИТИЯ ПЕРМСКОГО КРАЯ"

Внимание! Если размещение файла нарушает Ваши авторские права, то обязательно сообщите нам
27
ведения бумажного архива нельзя, установка электронного архива позволяет
вывезти бумаги в удаленное защищенное хранилище и работать только с
электронными копиями документов. При организации электронного
документооборота возможно как архивирование, так и быстрый и
оперативный поиск документов. В таких условиях скорость работы с
бумагами гораздо увеличивается, а оригиналы ваших документов надежно
защищены.
11
В свою очередь хотелось бы предложить современную
автоматизированную систему "Центр Финансовых Технологий (ЦФТ) -
Соцзащита".
ЦФТ-Соцзащитасовременная автоматизированная система,
позволяющая объединить в защищенном режиме в единое информационное
пространство большинство государственных и муниципальных служб
работающих с населением (СоцЗащита, Пенсионный Фонд, Федеральная
Миграционная Служба, ЗАГС и др).
ЦФТ-Соцзащита – программный продукт нового поколения. В
отличие от традиционно используемых в отделах социальной защиты
программ, применение в «ЦФТ-Соцзащита» современных промышленных
баз данных под управлением СУБД Oracle, позволяет централизовать
хранение и обработку данных по всем льготным категориям граждан по
региону.
Преимущества данного продукта:
1. Централизованная база: возможность загрузки информации из
существующих программ и баз данных.
2. Быстрый доступ к информации любого подразделения в режиме
работы Онлайн.
3. Своевременная отчетность: сводные отчеты предоставляются в
первый день нового отчетного периода.
11
Автоматизация [Электронный ресурс] http://dic.academic.ru/dic.nsf (дата обращения: 15.12.2016).
28
4. Удобная работа с районными отделениями: экономия времени и
средств на сопровождения удаленных рабочих мест, контроль соблюдения
нормативов их работы.
5. Надежная защиты информации:
административные средства ограничения доступа;
шифрование каналов передачи данных к удаленным рабочим
местам;
возможность использовать цифровую подпись;
шифрование документов при организации документооборота.
6. Ведение «Личной карточки» каждого льготника и любого
человека, проходящего по ведомству отделов социальной защиты населения.
Возможность хранить и обрабатывать в Системе любую информацию по
льготникам.
Результатом внедрения будет: создание единой базы данных для всех
участников Системы; возможность получения любой аналитической
информации на основе единых данных, имеющихся в базе; сокращение
временных и финансовых затрат.
12
1.3.2 Выбор и обоснование способа приобретения ИС для
автоматизации комплекса задач
База данных (БД) представляет собой совокупность специальным
образом организованных данных, хранимых в памяти вычислительной
системы и отображающих состояние объектов и их взаимосвязей в
рассматриваемой предметной области.
Система управления базами данных (СУБД) — это комплекс
языковых и программных средств, предназначенный для создания, ведения и
совместного использования БД многими пользователями. Обычно СУБД
различают по используемой модели данных. Так, СУБД, основанные на
12
ЦФТ-Соцзащита [Электронный ресурс] http://www.myshared.ru (дата обращения: 15.01.2017).
29
использовании реляционной модели данных, называют реляционными
СУБД.
13
Современная архитектура системы БД характеризуется
многоуровневым представлением предметной области.
Предметная область– часть реального мира, которая описывается или
моделируется с помощью баз данных и использующих их приложений. Это
может быть целиком предприятие, некоторая его функциональная часть,
процесс, система.
В качестве предметной области могут рассматриваться:
1. Библиографическая информация, архив в библиотеке;
2. В БД института могут быть сведения о студентах, преподавателях
и учебных планах;
3. В БД предприятия содержится информация о выпускаемых
изделиях, используемых деталях, поставщиках
14
.
Архитектура СУБД разделена на три основных
уровня: внутренний, концептуальный, внешний.
Внешний уровень представляет некоторую часть предметной области
в той форме, как она воспринимается приложением или группой
приложений.
Концептуальный уровень представляет соответственно предметную
область. Подробность представления предметной области на концептуальном
уровне зависит от специфики конкретной разработки.
Внутренний уровень включает данные о предметной области с учетом
требований хранения и доступа.
Данным уровням соответствуют модели данных и описывающие эти
модели схемы.
13
Хомопепко А. Д., Цыганков В. М., Мальцев М. Г Под ред. А. Д. Хомопепко.Базы данных:
Учебник для высших учебных заведений, 2009. - 736 с.
14
Калитина В.В., Формирование программно-алгоритмической компетентности бакалавров
информационных направлений при обучении программированию: учебное пособие, 2015 год.
30
Модели данных – это определенным образом структурированные
данные.
Схема является описанием модели, предназначенным для
использования СУБД.
Все уровни являются реальными, то есть отражают определенные
взгляды на данные соответственно с позиции приложений, предметной
области и вычислительной машины.
15
Введение концептуального уровня обеспечивает важные свойства
систем БД:
1. Независимость данных;
2. Целостность;
3. Разграничение доступа.
Внешняя модель является совокупностью объектов, которые
представляют часть предметной области, входящую в круг интересов
некоторого приложения или группы приложений, со степенью подробности и
в форме, необходимой для этих приложений. Каждому приложению может
соответствовать определенная внешняя модель. Различные внешние модели
пересекаются. Объекты внешней модели материализуются по требованию
приложений и прекращают существовать после их использования.
Концептуальная модель – это совокупность объектов,
представляющих предметную область. В то время как возможно
использование множества внешних моделей, существует лишь одна
концептуальная модель. Любые данные могут быть использованы, только
если они отражены в концептуальной модели. Объекты концептуальной
модели не обязательно должны быть материализованы. Она – есть
представление полного информационного содержания БД в абстрактной
форме в целом по сравнению со способом хранения данных.
15
Медведкова И. Е., Бугаев Ю. В., Чикунов С. В.Базы данных, 2014 год, 105 страниц.
31
Внутренняя модель представляет собой совокупность объектов,
содержащих хранимые данные. Во внутренней модели отражены
используемые СУБД технологии хранения и пути доступа к данным. В
отличие от предыдущих двух моделей, объекты во внутренней модели
фактически существуют и продолжают существовать до тех пор, пока не
будут удалены из системы.
БД бывают:
централизованными - хранится в памяти одной вычислительной
системы, если эта вычислительная система является компонентом сети ЭВМ,
возможен распределенный доступ к такой БД, то есть доступ к ней
пользователей различных ЭВМ данной сети;
распределенными - состоит из нескольких, возможно
пересекающихся или даже дублирующих друг друга частей, хранимых в
различных ЭВМ вычислительной сети. Однако, пользователь
распределенной БД не обязан знать каким образом её компоненты
размещаются в узлах сети и представляет себе эту БД как единое целое.
Работа с такой БД осуществляется с помощью распределенной СУБД.
16
Современные базы данных можно разделить на три категории:
- Программные продукты корпоративного направления – Oracle и
MS SQL Server;
- СУБД, предназначенные для работы с информационными
массивами в небольших компаниях, - MS Access и BorlandInterbase;
- СУБД для Web, реализующих создание Web-сайтов с
небольшими базами данных, - MySQL и опять-таки BorlandInterbase.
17
К базовым функциям СУБД можно отнести следующие:
1) Непосредственное управление данными во внешней памяти.
16
Бодров, О.А. Предметно-ориентированные экономические информационные системы: Учебник
для вузов / О.А. Бодров. - М.: Гор. линия-Телеком, 2013. - 244 c.
17
Проектирование информационных систем: учебник и практикум для академического
бакалавриата / под ред. Д. В. Чистова. — М. : Издательство Юрайт, 2016. — 258 с.
32
Непосредственное управление подразумевает снабжение нужных
структур внешней памяти как для хранения информации, естественно
включенных в базу данных, так и для вспомогательных целей, вроде
повышения скорости доступа к содержанию БД в отдельных случаях (в таких
случаях обычно использую нумерацию). В отдельных реализациях СУБД
часто имеют место возможности наличествующих файловых систем, в иных
работа осуществляется вплоть до уровня устройств внешней памяти. Однако
стоит заметить, что в более сформированных СУБД пользователи по
условию не обязаны знать, применяет ли СУБД файловую систему, и если
это так, то как в этом случае организованы файлы. В отдельности, СУБД
имеет возможность применять собственную систему именования объектов
БД.
2)Управление буферами оперативной памяти.
Обычно СУБД функционируют с БД большого размера; по крайней
мере этот размер как правило гораздо больше имеющейся емкости
оперативной памяти. Тут же если при вызове какого-либо элемента данных
совершается обмен с внешней памятью, то система как единое целое
работает с быстротой устройства внешней памяти. Самым подходящим
способом значительного возрастания этой быстроты выступает буферизация
содержимого оперативной памяти. Однако, даже если ОС осуществляет
буферизацию общую для всех систем (как, например, в случае ОС UNIX), то
этого мало для целей СУБД, располагающей значительными данными о
преимуществах буферизации одной или другой части базы данных. По этой
причине в развитых СУБД может использоваться свой личный комплект
буферов оперативной памяти со своими правилами замены буферов.
Имеется обособленное ответвление СУБД, направленное на
непрерывное нахождение в оперативной памяти полной БД. Это ответвление
базируется на теории о том, что в будущем объем оперативной памяти ПК
будет настолько большим, что будет позволять не волноваться о
буферизации. Но пока что данные работы только на стадии исследований.
33
3)Управление транзакциями.
Транзакцией именуют последовательность производимых над БД
действий, воспринимаемых СУБД как единое целое. Вообще возможны два
варианта развития событий:
- либо транзакция воплощается благополучно и СУБД закрепляет
изменения БД, осуществленные этой транзакцией во внешней памяти;
- либо никакое из произошедших изменений абсолютно не имеет
влияния на состояние БД.
Понятие транзакции требуется для сохранения целостности логики
БД. Из чего следует вывод, что сохранение механизма транзакций
представляет собой необходимое условие не только многопользовательских,
но и однопользовательских СУБД. При этом понятие транзакции все же
существенно влиятельнее в многопользовательских СУБД.
Свойство, которое определяет, что каждая транзакция приступает к
работе при целостности БД и сохраняет целостность БД после окончания
своей работы, делает употребление понятия транзакции как единицы
активности пользователя связи с БД очень удобным. При необходимом
контроле параллельно происходящим транзакциями относительно СУБД
любой из применяющих их вполне может чувствовать себя единственным
работающем в СУБД. Хотя правильно будет сказать, что это все-таки
приближенное к идеалу суждение, так как в отдельных ситуациях
пользователи многопользовательских СУБД имеют возможность чувствовать
присутствие других.
Многие важные понятия, например, сериализация транзакций и
сериальный план исполнения смеси транзакций связаны с контролем
транзакций в многопользовательском режиме СУБД. Сериализация не
пересекающихся исполняемых транзакций - это тот порядок структуризации
их работы, при котором совместный эффект смеси транзакций фактически
равен эффекту их какого-либо выполнения последовательно.
34
Сериальным планом смеси транзакций называют такой план, при
котором осуществляется сериализация транзакций. Ясно, что если на самом
деле получается осуществлять настоящий сериальный план, то в частности
для каждого исполнителя, который был основателем данной транзакции,
наличие здесь иных транзакций будет не замечено (если не учитывать
определенное падение скорости работы относительно однопользовательского
режима).
Наличествует определенное количество основных алгоритмов
сериализации транзакций. В централизованных СУБД самыми популярными
являются алгоритмы, построенные на синхронизационных захватах объектов
баз данных. Во время применения какого-либо алгоритма сериализации
возможны случаи конфликтов между несколькими разными транзакциями по
доступу к объектам баз данных. В данном случае для сохранения
сериализации нужно обязательно произвести откат (отменить все изменения,
осуществленные в базе данных) одной или всех необходимых транзакций.
Подобный случай является одним из тех, когда человек, работающий в
многопользовательской СУБД имеет возможность весьма сильно (и в целом
с отрицательной стороны) заметить существование транзакций других людей
в данной системе.
4)Журнализация.
Надежность хранения данных во внешней памяти - одно из главных
требований к СУБД. Под этим понятием подразумевается, что СУБД должна
иметь возможность восстановить последнее состояние БД, которое было
согласовано всеми пользователями, после любого аппаратного или
программного сбоя. Чаще всего учитываются два возможных варианта
аппаратного сбоя: первые - это мягкие сбои, которые могут трактоваться как
неожиданное прекращение работы компьютера (такое как аварийное
прекращение подачи питания), и жесткие сбои, которые характеризуются
утерей содержимого внешних носителях. Некоторые программных сбои
перечислены ниже: аварийное закрытие системы управления базами
35
данных(по причине возникшей в программе ошибки или из-за определенного
аппаратного сбоя) или же аварийное закрытие пользовательской программы,
из-за чего определенная транзакция закрывается будучи незавершенной.
Первый случай можно является специальным видом мягкого аппаратного
сбоя; если же случается второй, то необходимо исправить результаты только
одной транзакции.
Для возобновления работы БД во всех ситуациях требуется иметь в
наличии определенные данные. Для сохранения безопасности хранения
информации в БД требуется избыточность хранения информации, к тому же
определенную долю информации, необходимую для восстановления, нужно
еще более старательно сохранять. Ведение журнала изменений СУБД
представляет собой очень популярный способ для сохранения такой
избыточной информации.
Журнал является особой частью БД, которая недоступна
пользователям СУБД и поддерживается с особенной тщательностью (порой
поддерживается не одна копия журнала, иные располагаются на разных
физических дисках), в которую поступают записи обо всех изменениях
основной части БД. В различных СУБД изменения БД документируются на
разных уровнях: иногда запись в журнале соответствует определенной
логической операции изменения БД (например, операция удаления строки из
таблицы реляционной БД), иногда - минимальной внутренней операции
модификации страницы внешней памяти; в некоторых системах могут
одновременно использоваться оба подхода.
Во всех случаях принято придерживаться стратегии «упреждающей»
записи в журнал (так называемого протокола Write Ahead Log - WAL). То
есть, данная стратегия заключается в том, что запись об изменении любого
объекта БД не должна попасть во внешнюю память журнала позже, чем
измененный объект попадет во внешнюю память основной части БД. Если в
СУБД корректно соблюдается протокол WAL, то с помощью журнала можно
решить все проблемы восстановления БД после какого-либо сбоя.
36
Индивидуальный откат транзакции. В этом случае не нужен
общесистемный журнал изменений баз данных. Достаточно поддерживать
для каждой транзакции локальный журнал операций модификации БД,
которые были выпонены в этой транзакции, и производить откат транзакции
методом выполнения обратных операций, начиная от конца локального
журнала. В определенных СУБД так и происходит, но в большинстве систем
локальные журналы не поддерживаются, а индивидуальный откат
транзакции выполняется по общесистемному журналу, где все записи от
одной транзакции связывают обратным списком (от конца к началу).
При мягком сбое во внешней памяти основной части БД могут
находиться объекты, модифицированные транзакциями, не закончившимися
к моменту сбоя, и могут отсутствовать объекты, модифицированные
транзакциями, которые к моменту сбоя успешно завершились (из-за
использования буферов оперативной памяти, содержимое которых при
мягком сбое исчезает). При соблюдении протокола WAL во внешней памяти
журнала гарантированно должны находиться записи, которые относились бы
к операциям модификации обоих видов объектов. Главной задачей процесса
восстановления после мягкого сбоя является состояние внешней памяти
основной части БД, возникающее во время фиксации во внешней памяти
изменений всех завершившихся транзакций и которое не содержало бы
никаких следов незаконченных транзакций. Для того, чтобы этого добиться,
сначала производят откат незавершенных транзакций (undo), а потом
повторно воспроизводят (redo) те операции завершенных транзакций,
результаты которых не отображены во внешней памяти. Этот процесс
содержит множество тонкостей, которые связаны с общей организацией
управления буферами и журналом.
Для восстановления БД после жесткого сбоя используется архивная
копия базы данных и журнал. Архивная копия - это полная копия БД к
моменту начала заполнения журнала (имеется множество вариантов более
общей трактовки смысла архивной копии). Необходимо, чтобы после сбоя не

Смотрите также:

"Автоматизация обработки заявок ООО "Проектно-Строительная Компания"
"Автоматизация процесса аттестации персонала для ООО "Нэт Бай Нэт Холдинг"
"Анализ интернет-активности конкурентов ( на примере конкурентов "Газпром нефть")
"Бухгалтерский учёт и аудит расчётов с подотчётними лицами в организации на примере ООО "ЛОЦ 10""
«Психологическое сопровождение персонала в организации на примере ООО «Крокус»
Cовершенствование деловой оценки персонала в организации (на примере ООО "Даймонд кейтеринг развитие")
PR как средство продвижения организации (на примере ПАО "Тамбовский завод "Комсомолец им. Н.С. Артемова")
PR-коммуникации в сфере общественного питания (на примере кафе-кондитерской «Cream Cheese»)
SMM как средство повышения эффективности работы учреждений социокультурной сферы (на примере Малого театра)
Value-based education: ценности в системе образования и способы их реализации на уроке английского языка. Опыт Европейских стран