Разработка информационной системы общественного рейтинга ВУЗов и их профессорского-преподавательского состава
Разработка структуры информационной системы связки "преподаватель-студент". Создание базы данных, прав доступа, аутентификации, идентификации, авторизации. Внедрение системы защиты, прикладных программ обработки данных и системы администрирования.
Рубрика | Программирование, компьютеры и кибернетика |
Вид | дипломная работа |
Язык | русский |
Дата добавления | 16.11.2013 |
Размер файла | 2,9 M |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
· отслеживание эффективности работы различных участков и служб для выявления и устранения слабых звеньев, а также для совершенствования бизнес-процессов и организационных единиц (т.е. анализ информации может привести к изменению правил выполнения тех или иных управленческих процессов и даже к изменению организационной структуры предприятия);
· анализ деятельности отдельных подразделений;
· обобщение данных из различных подразделений;
· анализ показателей различных направлений финансово-хозяйственной деятельности предприятия для выделения перспективных и убыточных направлений бизнеса;
· выявление тенденций, развивающихся на предприятии, так и на рынке. Не следует забывать и о том, что работать с системой придется обычным людям, являющимся специалистами в своей предметной области, но зачастую обладающими весьма средними навыками в работе с компьютерами. Интерфейс информационных систем должен быть им интуитивно понятен.
2.1 Общая схема системы
Общую схему системы, которую мы разрабатываем в виде сайта можно представить в виде схемы, которая будет являться удобным отображением информации для всей целевой аудитории ИС. Для примерного составления составим схему зарубежного сайта, представленную ниже.
Рис. 14. Разработка информационной системы
2.2 Функциональные блоки
Для удобства разработки информационной системы, а именно для структурированного подхода к данному вопросу были определены функциональные блоки каждой информационной единицы ИС, как её отображения, а именно веб-интерфейса, так же рассмотрим зарубежный сайт для этого.
Рис. 15 схема информационных блоков
2.3 Пользовательские сценарии
В продолжение разработки информационной системы было сделано распределение пользовательских сценариев. Пользовательскими сценариями являются действия различных групп пользователей при нахождении на оболочке ИС. Их возможные и вероятные действия. Благодаря этим сценариям мы видим, что будут делать пользователи, как сделать интерфейс информационной системы более удобным, на что акцентировать внимание и как возможно управлять маршрутом пользователя на сайте.
Рис. 16. Пользовательские сценарии
2.4 Модель базы данных
В продолжении моделирования ИС была создана структура базы данных, как неотъемлемая часть основы ИС. БД является чуть ли не сердцем ИС. При формировании структуры БД необходимо сделать её максимально гибкой и нормализованной. Более подробно о формировании БД и её реализации можно будет прочитать в другой главе работы.
Рис. 16. Модель базы данных
2.5 Принципы построения приложения
При построении приложения, а именно веб-интерфейса нашей информационной системы целиком были использованы следующие принципы
1 Каждый крупный элемент (страницы, окно оценивания) оформлен в виде класса, который наследуется от базового
2 Общие методы описаны в базовом классе
3 Все обращения к сайту ведутся через редирект к главному файлу index.php в котором мы получаем POST и GET.
4 В главном файле создается экземпляр главного класса, в котором и происходит вся обработка, описанная в п.3
5 Аутентификация делится на внутреннюю и внешнюю. Первая проверяет - залогинен ли пользователей и выдает в систему права. Внешняя - логинит пользователя.
6 Внутренняя осуществляется путем проверки sessionId в coocies, а также ip и user-agent.
Данные принципы выбраны для обеспечения прозрачной структуры ИС, а также для обеспечения масштабируемости системы.
2.6 Система аутентификации и прав доступа
Аутентификация - это проверка подлинности предъявленного пользователем идентификатора. Аутентификация требуется при доступе к таким интернет сервисам, как:
· электронная почта
· веб-форумы
· социальные сети
· интернет-банкинг
· платежные системы
· корпоративные сайты
· интернeт-магазины
Положительным результатом аутентификации (кроме установления доверительных отношений и выработки сессионного ключа) является авторизация пользователя, т. е. предоставление ему прав доступа к ресурсам, определенным для выполнения его задач.
В зависимости от важности ресурса, для доступа к нему могут применяться разные методы аутентификации:
В данном ресурсе требуется аутентификация для доступа к информационным системам, содержащим информацию, разглашение которой не несет существенных последствий. Минимальным требованием для аутентификации является использование многоразовых паролей
Итого, из чего состоит наша система:
· Все пользователи будут хранится в таблице базы данных MySQl
· В качестве логина будет использоваться email (уникален для всего мира), пароль хранится в БД в зашифрованном виде.
· В качестве уникального идентификатора будем использовать ID пользователя
· После успешной авторизации уникальный идентификатор будет хранится в переменной сессии
· Для запоминания логина и пароля между сеансами необходимо использовать cookie
Так же существует несколько типов пользователей для нашей системы:
· Гость
· Преподаватель
· Студент
· Администратор
Для разных типов пользователей предоставлены различные права доступа, частично они отображаются в схеме пользовательские сценарии.
3. Система управления базами данных
Система управления базами данных-- совокупность программных и лингвистических средств общего или специального назначения, обеспечивающих управление созданием и использованием баз данных
К функциям СУБД можно отнести
· управление данными во внешней памяти (на дисках);
· управление данными в оперативной памяти с использованием дискового кэша;
· журнализация изменений, резервное копирование и восстановление базы данных после сбоев;
· поддержка языков БД (язык определения данных, язык манипулирования данными).
· Обычно современная СУБД содержит следующие компоненты:
· ядро, которое отвечает за управление данными во внешней и оперативной памяти и журнализацию,
· процессор языка базы данных, обеспечивающий оптимизацию запросов на извлечение и изменение данных и создание, как правило, машинно-независимого исполняемого внутреннего кода,
· подсистему поддержки времени исполнения, которая интерпретирует программы манипуляции данными, создающие пользовательский интерфейс с СУБД
· а также сервисные программы (внешние утилиты), обеспечивающие ряд дополнительных возможностей по обслуживанию информационной системы.
3.1 Принципы построения базы данных
При построении базы данных ИС была выбрана самая оптимальная, гибкая и современная модель- это реляционная база данных.
Реляционная база данных -- это совокупность взаимосвязанных таблиц, каждая из которых содержит информацию об объектах определенного типа. Строка таблицы содержит данные об одном объекте (например, товаре, клиенте), а столбцы таблицы описывают различные характеристики этих объектов -- атрибутов (например, наименование, код товара, сведения о клиенте). Записи, т. е. строки таблицы, имеют одинаковую структуру -- они состоят из полей, хранящих атрибуты объекта. Каждое поле, т. е. столбец, описывает только одну характеристику объекта и имеет строго определенный тип данных. Все записи имеют одни и те же поля, только в них отображаются различные информационные свойства объекта.
В реляционной базе данных каждая таблица должна иметь первичный ключ -- поле или комбинацию полей, которые единственным образом идентифицируют каждую строку таблицы. Если ключ состоит из нескольких полей, он называется составным. Ключ должен быть уникальным и однозначно определять запись. По значению ключа можно отыскать единственную запись. Ключи служат также для упорядочивания информации в БД.
Таблицы реляционной БД должны отвечать требованиям нормализации отношений. Нормализация отношений -- это формальный аппарат ограничений на формирование таблиц, который позволяет устранить дублирование, обеспечивает непротиворечивость хранимых в базе данных, уменьшает трудозатраты на ведение базы данных.
Пусть создана таблица Студент, содержащая следующие поля: № группы, ФИО, № зачетки, дата рождения, название специальности, название факультета. Такая организация хранения информации будет иметь ряд недостатков:
· дублирование информации (наименование специальности и факультета повторяются для каждого студента), следовательно, увеличится объем БД;
· процедура обновления информации в таблице затрудняется из-за необходимости редактирования каждой записи таблицы.
Нормализация таблиц предназначена для устранения этих недостатков. Имеется три нормальные формы отношений.
Первая нормальная форма. Реляционная таблица приведена к первой нормальной форме тогда и только тогда, когда ни одна из ее строк не содержит в любом своем поле более одного значения и ни одно из ее ключевых полей не пусто. Так, если из таблицы Студент требуется получать сведения по имени студента, то поле ФИО следует разбить на части Фамилия, Имя, Отчество.
Вторая нормальная форма. Реляционная таблица задана во второй нормальной форме, если она удовлетворяет требованиям первой нормальной формы и все ее поля, не входящие в первичный ключ, связаны полной функциональной зависимостью с первичным ключом. Чтобы привести таблицу ко второй нормальной форме, необходимо определить функциональную зависимость полей. Функциональная зависимость полей -- это зависимость, при которой в экземпляре информационного объекта определенному значению ключевого реквизита соответствует только одно значение описательного реквизита.
Третья нормальная форма. Таблица находится в третьей нормальной форме, если она удовлетворяет требованиям второй нормальной формы, ни одно из ее неключевых полей не зависит функционально от любого другого неключевого поля. Например, в таблице Студент (№ группы, ФИО, № зачетной книжки, Дата рождения, Староста) три поля -- № зачетной книжки, № группы, Староста находятся в транзитивной зависимости. № группы зависит от № зачетной книжки, а Староста зависит от № группы. Для устранения транзитивной зависимости необходимо часть полей таблицы Студент перенести в другую таблицу Группа. Таблицы примут следующий вид: Студент (№ группы, ФИО, № зачетной книжки, Дата рождения), Группа (№ группы, Староста).
Над реляционными таблицами возможны следующие операции:
· Объединение таблиц с одинаковой структурой. Результат-- общая таблица: сначала первая, затем вторая (конкатенация).
· Пересечение таблиц с одинаковой структурой. Результат -- выбираются те записи, которые находятся в обеих таблицах.
· Вычитание таблиц с одинаковой структурой. Результат -- выбираются те записи, которых нет в вычитаемом.
· Выборка (горизонтальное подмножество). Результат -- выбираются записи, отвечающие определенным условиям.
· Проекция (вертикальное подмножество). Результат -- отношение, содержащее часть полей из исходных таблиц.
· Декартово произведение двух таблиц Записи результирующей таблицы получаются путем объединения каждой записи первой таблицы с каждой записью другой таблицы.
Реляционные таблицы могут быть связаны друг с другом, следовательно, данные могут извлекаться одновременно из нескольких таблиц. Таблицы связываются между собой для того, чтобы в конечном счете уменьшить объем БД. Связь каждой пары таблиц обеспечивается при наличии в них одинаковых столбцов.
Существуют следующие типы информационных связей:
· один-к-одному;
· один-ко-многим;
· многие-ко-многим.
Связь один-к-одному предполагает, что одному атрибуту первой таблицы соответствует только один атрибут второй таблицы и наоборот.
Связь один-ко-многим предполагает, что одному атрибуту первой таблицы соответствует несколько атрибутов второй таблицы.
Связь многие-ко-многим предполагает, что одному атрибуту первой таблицы соответствует несколько атрибутов второй таблицы и наоборот.
3.2 Принципы проектирования
Принципы разработки многопользовательских баз данных должны сводиться к соблюдению двух обязательных условий: системного подхода и стандартизации.
Системный подход. Системный подход к разработке информационной системы означает, что такая система рассматривается как большая система, состоящая из некоторого множества взаимосвязанных и взаимодействующих между собой элементов. При проектировании информационных систем необходимо соблюдать следующие принципы:
· учет интересов всех потенциальных пользователей систем;
· модульный принцип разработки и внедрения.
Учет интересов всех потенциальных пользователей систем. Этот принцип означает следующую последовательность разработки БД.
1 Установить, каким специалистам и в каких подразделениях предприятия необходима информация о конкретном информационном объекте.
2 Установить признаки описания объектов различными пользователями.
3 Установить общий состав признаков объектов одного класса.
Такой подход к проектированию увеличивает сроки разработки БД, но обеспечивает значительное снижение затрат на разработку всей системы в целом.
Для пояснения этого принципа можно привести следующий реальный пример разработки БД на одном из предприятий. Появление программ создания баз данных было по достоинству оценено сотрудниками и они "бросились" разрабатывать необходимые для себя базы данных.
Одной из задач, стоящих перед технологами цехов, являлась задача выбора инструмента для механической обработки деталей. Они разработали свою, цеховую БД по режущему инструменту (затратив на это и время, и средства).
В то же время в конструкторском отделе завода специалисты, занимающиеся проектированием режущего инструмента, также создали свою БД. Однако когда руководство приняло решение создать общезаводскую информационную систему по режущему инструменту, то оказалось, что одни и те же признаки режущего инструмента разные специалисты описывали разными способами. В результате разработанные базы данных пришлось полностью переделывать, что потребовало, как дополнительного времени, так и дополнительных затрат. Средства на разработку несогласованных между специалистами баз данных были потеряны для предприятия.
Модульный принцип разработки и внедрения. Модульный принцип означает, что любая система должна разрабатываться в виде отдельных взаимосвязанных модулей (подсистем), которые могут внедряться в производстве отдельно, до окончательной разработки всей системы.
Стандартизация. Стандартизация разработки информационных систем, учитывая их многопользовательский характер, имеет следующие аспекты:
* информационный;
* программный;
* аппаратный.
Стандартизация информационного обеспечения обусловлена принципами компьютерной обработки символьной информации, так как объекты баз данных должны однозначно распознаваться компьютером.
Этот аспект разработки БД означает, что на все информационные объекты должны быть установлены четкие правила их идентификации (грамматические правила их написания). Так, установив название инструмента для механической обработки детали "Резец расточной", не допускается никакого другого способа его обозначения (например, название "Расточной резец" не идентично названию "Резец расточной").
Необходимость стандартизации программного обеспечения очевидна -- при разработке многопользовательских, удаленных друг от друга систем данные одной системы должны обрабатываться программным обеспечением другой системы.
Стандартизация аппаратного обеспечения связана с необходимостью снижения затрат на эксплуатацию компьютерной техники.
3.3 Принципы нормализации
Нормальная форма -- свойство отношения в реляционной модели данных, характеризующее его с точки зрения избыточности, потенциально приводящей к логически ошибочным результатам выборки или изменения данных. Нормальная форма определяется как совокупность требований, которым должно удовлетворять отношение.
Процесс преобразования отношений базы данных (БД) к виду, отвечающему нормальным формам, называется нормализацией. Нормализация предназначена для приведения структуры БД к виду, обеспечивающему минимальную логическую избыточность, и не имеет целью уменьшение или увеличение производительности работы или же уменьшение или увеличение физического объёма базы данных. [1] Конечной целью нормализации является уменьшение потенциальной противоречивости хранимой в базе данных информации. Как отмечает К. Дейт, общее назначение процесса нормализации заключается в следующем:
· исключение некоторых типов избыточности;
· устранение некоторых аномалий обновления;
· разработка проекта базы данных, который является достаточно "качественным" представлением реального мира, интуитивно понятен и может служить хорошей основой для последующего расширения;
· упрощение процедуры применения необходимых ограничений целостности.
При том, что идеи нормализации весьма полезны для проектирования баз данных, они отнюдь не являются универсальным или исчерпывающим средством повышения качества проекта БД. Это связано с тем, что существует слишком большое разнообразие возможных ошибок и недостатков в структуре БД, которые нормализацией не устраняются. Несмотря на эти рассуждения, теория нормализации является очень ценным достижением реляционной теории и практики, поскольку она даёт научно строгие и обоснованные критерии качества проекта БД и формальные методы для усовершенствования этого качества. Этим теория нормализации резко выделяется на фоне чисто эмпирических подходов к проектированию, которые предлагаются в других моделях данных. Более того, можно утверждать, что во всей сфере информационных технологий практически отсутствуют методы оценки и улучшения проектных решений, сопоставимые с теорией нормализации реляционных баз данных по уровню формальной строгости.
Нормализацию иногда упрекают на том основании, что "это просто здравый смысл", а любой компетентный профессионал и сам "естественным образом" спроектирует полностью нормализованную БД без необходимости применять теорию зависимостей. Однако, как указывает К. Дейт, нормализация в точности и является теми принципами здравого смысла, которыми руководствуется в своём сознании зрелый проектировщик, то есть принципы нормализации -- это формализованный здравый смысл. Между тем, идентифицировать и формализовать принципы здравого смысла -- весьма трудная задача, и успех в её решении является существенным достижением.
Уровень нормализации определяется нуждами на которые ориентирована БД , для нашего случая достаточным уровнем формы является нормальная форма Бойса-Кодда.
В создании и развитии теории нормализации принимали участие многие учёные. Однако первые три нормальные формы и концепцию функциональной зависимости предложил Э. Кодд.
Нормальные формы
Первая нормальная форма (1NF)
Переменная отношения находится в первой нормальной форме (1НФ) тогда и только тогда, когда в любом допустимом значении отношения каждый его кортеж содержит только одно значение для каждого из атрибутов.
В реляционной модели отношение всегда находится в первой нормальной форме по определению понятия отношение. Что же касается различных таблиц, то они могут не быть правильными представлениями отношений и, соответственно, могут не находиться в 1НФ.
Вторая нормальная форма (2NF)
Переменная отношения находится во второй нормальной форме тогда и только тогда, когда она находится в первой нормальной форме, и каждый неключевой атрибут неприводимо (функционально полно) зависит от ее потенциального ключа.
Третья нормальная форма(3NF)
Переменная отношения находится в третьей нормальной форме тогда и только тогда, когда она находится во второй нормальной форме, и отсутствуют транзитивные функциональные зависимости неключевых атрибутов от ключевых.
Нормальная форма Бойса -- Кодда (BCNF)
Переменная отношения находится в нормальной форме Бойса -- Кодда (иначе -- в усиленной третьей нормальной форме) тогда и только тогда, когда каждая ее нетривиальная и неприводимая слева функциональная зависимость имеет в качестве своего детерминанта некоторый потенциальный ключ.
3.4 Системы защиты на сервере. Резервирование
Наш интернет-сервер выполняет следующие основные функции:
· Web-сервера для поддержки Интернет- и интранет-сайтов компании;
· сервера удаленного доступа для контроля доступа удаленных или мобильных пользователей к Интернет-серверу;
· Web-кэширования для "зеркалирования" Web-страниц Интернет-провайдера (ISP);
· сервера электронной почты для работы с внешней и внутренней почтовой корреспонденцией;
· файл-сервера для управления доступом сотрудников к совместно используемым файлам;
· сервера FTP для создания ftp-архива компании;
· сервера печати для совместного использования сетевой печати;
· сервера DNS для управления локальными записями DNS для имеющихся у компании серверов;
· сервера DHCP для динамичной автоматической настройки IP-адресов.
Следует отметить, однако, что Интернет-сервер восприимчив к попыткам нарушения безопасности сети.
Установленный на компьютере с операционной системой Windows NT, Интернет-сервер является приложением, и вот в этом-то и кроется причина его уязвимости.
Как прикладная задача Интернет-сервер находится выше стека протоколов сервера NT.
В Windows NT нет такого уровня контроля доступа, который необходим для защиты Интернет-сервера.
Например, эта ОС не проводит мониторинг и регистрацию событий в сети, при ее использовании не блокируется множество входящих и исходящих соединений и не выявляется подозрительная активность в сети.
Недостаток функций контроля доступа и обнаружения вторжений открывают Windows NT и ее приложения для попыток нарушения защиты сети посредством DoS-атак, таких как Ping Flood, SYN Flood, IP Packet Fragmentation, TCP and UDP Port Spoofing, Session Highjacking и Oversized IP Packet Attacks, а также для внедрения "троянских коней" и подбора пароля.
Рис. 17. Классическая схема защиты корпоративных серверов
Даже если Интернет-сервер как приложение защищен стандартными средствами, это не предотвратит нарушения безопасности самой операционной системы. Если атакующий, используя DoS-атаку, блокирует сервер, то блокируется и Интернет-сервер - и компания теряет корректный механизм, обеспечивающий взаимодействие с открытой сетью. Вся полезная активная деятельность в Интернете будет прекращена, что приведет компанию к финансовым убыткам.
Для обеспечения безопасности Интернет-сервера, а следовательно, и всей корпоративной сети здесь, по мнению специалистов, необходимо использовать специальные средства защиты.
3.5 Защита от внутренних ошибок
Защита от внутренних ошибок связана в первую очередь с проработкой системы безопасности взаимоотношений межу клиентами и регламентирование доступа к информации предоставляемой информационным ресурсом. Также неотъемлемая часть -- это отсутствие ошибок в коде, которые проявляются в процессе эксплуатации.
Учитывая специфику использованного ПО можно рассмотреть сообщения об ошибках, которые указываются при каких-либо неисправностях
Директива ErrorDocument добавляет серверу не слишком много функциональных возможностей. Это скорее косметическая опция, позволяющая управлять тем, что видит пользователь в случае каких-либо неполадок, например, когда запрашиваемый документ не найден или сценарий CGI не возвратил браузеру ожидавшихся данных. Однако директива ErrorDocument позволяет повлиять на деятельность сервера, если для обработки информации, вызвавшей ошибку, используется сценарий CGI. Обработанная информация может использоваться для передачи клиенту более информативного сообщения об ошибке либо для создания более подробной записи об ошибке в журнальном файле.
Основное применение директивы ErrorDocument является очень простым. В ней помещается текстовая строка, возвращаемая клиенту, либо адрес, на который перенаправляется клиентский запрос.
Таб.2 коды возврата
Коды возврата HTTP |
Значение |
|
200 |
[ОК]: Документ существует и доступ к нему разрешен. |
|
302 |
[Found]: Требуемый документ находится по другому адресу URL. |
|
400 |
[Bad Request]: Сервер не смог распознать запрос. |
|
401 |
[Unauthorized]: Клиент не имеет права осуществлять доступ к документу без специальных полномочий. |
|
403 |
[Forbidden]: Сервер ни при каких обстоятельствах не предоставляет указанный документ. |
|
404 |
[Not Found]: Документ не найден. |
|
500 |
[Server Error]: На сервере произошла ошибка. |
|
501 |
[Not Implemented]: Запрошенная возможность не поддерживается сервером. |
Борьба с этими ошибками ведется путем оперативного вмешательства программиста в процесс работы сервера и устранения этих ошибок либо методом трассировки, либо другими.
3.6 Защита от внешних воздействий
В ИС защита сервера от информационных воздействий предоставляется в основном ресурсами провайдера, предоставляющего хостинг. Её реализация происходит классическим методом.
Вместо того чтобы выставлять сервер Web на всеобщее обозрение под ненадежной защитой маршрутизатора, вы можете выбрать компромиссный вариант. Сервер Web можно расположить в экранированной подсети, или "демилитаризованной зоне", т. е. фактически брандмауэр будет обслуживать три сети. В результате брандмауэр будет защищать и сервер Web, и внутреннюю сеть.
Рис. 18. Сервер Web защищен брандмауэром; администрирование сервера Web упрощено благодаря зеркалированию.
В такой конфигурации брандмауэр пропускает из Internet на сервер только трафик HTTP (и, возможно, S/HTTP). Кроме того, он контролирует доступ сервера Web во внутреннюю сеть, ограничивая его внутренними серверами баз данных. В дополнение к этому, внутренним пользователям следует разрешить доступ к серверу Web для тестирования.
Несмотря на все достоинства, этот подход имеет свои "подводные камни". Как пользователи внутренней сети будут администрировать сервер Web? Он по-прежнему остается лакомым кусочком для злоумышленников и нуждается в очень тщательном администрировании. Если администраторы Web станут относиться к нему так же, как к внутреннему серверу, - жди неприятностей.
Общедоступные серверы Web нужно конфигурировать как неприступные хосты (форт-хосты): все ненужные службы программного обеспечения с них следует удалить. В идеале на сервере должно остаться только необходимое ПО, и ничего более. Так, систему UNIX вполне можно настроить как форт-хост: при этом она будет содержать менее 100 файлов, без учета документов и сценариев. Все прочее программное обеспечение следует удалить, а лучше вообще не устанавливать. Если вы не хотите удалять ненужное ПО, то по крайней мере блокируйте те сетевые сервисы, которые не требуются серверу Web для выполнения его непосредственных функций.
Необходимо убедиться, что сервер Web допускает удаленное администрирование. Для безопасного удаленного администрирования мы рекомендуем использовать шифруемое соединение, организовать которое можно с помощью защищенного программного обеспечения telnet или Secure Shell (SSH).
Еще один принцип форт-хоста - сокращение до минимума числа пользовательских бюджетов. В идеале их вообще не должно быть, за исключением бюджетов системного администратора и мастера Web. Чем меньше в системе пользователей, тем меньше вероятность того, что кто-то из них сделает ошибку и откроет лазейку для злоумышленников.
3.7 Резервирование
Неотъемлемая часть безопасности данных и безопасности сервера является создание резервных копий состояний ИС и соответственно, как её неотъемлемой составляющей БД.
Резервирование в нашей системе заключается в автоматическом создании дампов БД на сервере. Дамп памяти -- содержимое рабочей памяти одного процесса, ядра или всей операционной системы. Также может включать дополнительную информацию о состоянии программы или системы, например значения регистров процессора и содержимое стека.
Идея, стоящая за методом дампа, заключается в генерации текстового файла с командами SQL, которые при выполнении на сервере, пересоздадут базу данных в том же самом состоянии, в котором она была на момент создания дампа. Провайдер предоставляет для этой цели программную утилиту.
4. Прикладные программы обработки данных. Серверная часть
Рассмотрим те прикладные программы в коде, которые относятся непосредственно к коду сервера, операции серверной части.
Для начала, любое корректное обращение сайту через редирект (rewrite mode, конфиг в файле .htaccess) переводится к файлу index.php.
В этом файле создается экземпляр класса
generalClass (файл generalClass.php)
Конструктор этого класса (function __construct() - универсальное название конструтора)
Подключает модуль аутентификации
require_once $this->path_pageAuth;
$this->objAuth = new authenticationClass();
Здесь и далее имя файла доступно в переменной с префиксом 'path_' в классе generalClass.
Модуль аутентификации конструктором запускает метод getAuthCookies(), который по $sessionId из cookie, по $ip и по $userAgent проверяет - авторизирован ли пользователь.
Если да - то выставляет переменную $this->isAuth = true, и в переменную $this->permissions запрашивает права.
По полученным правам пользователь получает/не получает доступ к функционалу и разделам приложения.
Далее в конструкторе generalClass.php производится проверка запроса на POST параметры.
Если их не было, то переходим к проверке GET параметров.
POST параметры в системе сервер получает только от ajax.
GET параметры - от ссылок.
Полная структура GET запроса:
../?a=<действие>&m=<модуль>&p=<параметр>
Например:
http://uni-prof-test.zz.mu/?a=pageTeacher&p=54
В зависимости от сочетания параметров выдается нужная страница.
Структура POST запроса: В POST -запрос передается с помощью ajax переменная data, в которой определены обязательные переменные actionType (модуль обращения) и action (метод обращения).
В зависимости от их сочетания выполняется определенный метод и возвращаются данные.
Методом GET доступны следующие модули(их количество будет изменяться):
$act = $_GET['a'];
switch($act) {
case 'teacherList': $main = $this->openModule_teacherList(); break; //Модуль списка преподавателей
case 'pageTeacher': $main = $this->openModule_pageTeacher(); break; //Модуль страницы преподавателя
case 'Admin': $main = $this->openModule_Admin(); break; //Админка
case 'account': $main = $this->openModule_account(); break; //Профиль пользователя
Методом POST доступны следующие модули:
actionType = admin
actionType = auth
actionType = account
actionType = teacherEvaluate
В основном это: получение и сохранение данных.
Метод execute() в каждом из классов запускает все методы обработки, в каждом из которых стоит проверка на входящие параметры. Выполняется тот, для которого выставлены нужные управляющие параметры.
5. Экономическая составляющая
5.1 Стратегия внедрения
Сам по себе портал ИС является чем-то отдаленно напоминающим социальную сеть, а именно- обезличенную для студентов социальную сеть. Поэтому стратегия распространения и внедрения чем-то сходна со стратегией распространения социальной сети. Если говорить о конкретике, то рост сети связан распространением "от мала до велика" то есть изначально предполагается использование ИС на каких-либо малых структурах. Применимо к структуре университета малой структурой является кафедра, далее стоит факультет (институт) и в дальнейшем развитие объёма идет к уровню университета.
5.2 Модель монетизации
Под моделью монетизации мы воспринимаем дальнейшую реализацию ИС, как источника дохода получаемого различными путями, так или иначе связанные с веб-интерфейсом либо с полученной ценной информацией благодаря деятельности ИС.
Что касается сайта, то скорее денежные средства на его обслуживание и функционирование, а так же для получения дохода будут получаться с помощью рекламы, которая будет размещаться в специальных блоках, продуманных заранее при формировании структуры ИС.
Не стоит забывать, что ИС несет в себе первоочередную цель повышения качества образования, а следовательно может подпадать под какие-либо государственные гранты софинансирования социально полезных проектов, тем более изначально сформированных в рамках квалификационной работы.
6. Юридическая составляющая
6.1 Пользовательское соглашение
1. Общие положения
1.1. Использование материалов и сервисов сайта регулируется нормами действующего законодательства Российской Федерации.
1.2. Настоящее Соглашение является публичной офертой. Получая доступ к материалам сайта, Пользователь считается присоединившимся к настоящему Соглашению.
1.3. Правила являются обязательными для исполнения всеми Пользователями данного сайта. В случае неисполнения правил Администрация сайта оставляет за собой право закрыть нарушителю доступ к сайту, при этом удалить все комментарии и оценки Пользователя нарушившего правила.
1.4. Администрация сайта вправе в любое время в одностороннем порядке изменять условия настоящего Соглашения без какого-либо специального уведомления. Такие изменения вступают в силу по истечении 3 (трех) дней с момента размещения новой версии Соглашения на сайте. При несогласии Пользователя с внесенными изменениями он обязан отказаться от доступа к сайту, прекратить использование материалов и сервисов сайта.
2. Запрещается
2.1. Нарушение требований действующего законодательства Российской Федерации, правил настоящего Соглашения.
2.2. Публикация комментариев и иных записей Пользователя на сайте, нарушающих требования законодательства Российской Федерации и общепринятые нормы морали и нравственности.
2.3. Проявление неуважительного отношения в любой форме к Участникам и Пользователям сайта (оскорбления, нецензурная речь, угрозы). Участники должны соблюдать уважительную форму общения.
2.4. Распространение заведомо ложной информации, в том числе применение любых форм и способов незаконного представления другим лицом.
2.5. Публикация информации о взятии и даче взяток какими-либо лицами.
2.6. Проявление расовой и национальной неприязни, пропаганда терроризма, экстремизма, наркотиков и прочие темы, несовместимые с общепринятыми законами морали и приличия.
2.7. Пропаганда порнографии и детской эротики, а также реклама интимных услуг.
2.8. Распространение вирусов или других компьютерных кодов, предназначенных для нарушения, уничтожения либо ограничения функциональности любого компьютерного или телекоммуникационного оборудования, или программ, для осуществления несанкционированного доступа, а также серийные номера к коммерческим программным продуктам, логины, пароли и прочие средства для получения несанкционированного доступа к платным ресурсам в Интернете, а также размещения ссылок на вышеуказанную информацию.
2.9. Размещение ссылок на ресурсы сети Интернет, содержание которых нарушает требования действующего законодательства Российской Федерации.
2.10. Флуд -- многократное размещение одинаковых или слабо отличающихся сообщений, бессмысленные сообщения.
2.11. Публикация чужих почтовых адресов, адресов электронной почты, номеров ICQ, номеров телефонов, паспортных данных и другой персональной информации.
2.12. Публикация рекламы (в том числе скрытой) персональных сайтов, форумов, предложение платных услуг или иные виды рекламы и коммерческих объявлений.
2.13. Использование сайта в качестве почтовой доски объявлений для размещения сообщений приватного характера адресованных конкретному Пользователю.
2.14. Использование в общении на сайте языка, отличного от русского, и шрифта, отличного от кириллического. Администраторы сайта имеют право редактировать или удалять сообщения, написанные на языке, отличном от русского, и шрифтом, отличным от кириллического, без предупреждения.
2.15. Публичное предъявление претензий и обсуждение действий Администрации сайта.
2.16. Осуществление доступа к сервисам сайта способом, не предусмотренным Администрацией. Доступ ко всем разделам и сервисам сайта предоставляется исключительно через веб-интерфейс.
2.17. Нарушение функционирования сайта.
3. Публикация информации
3.1. При публикации персональной информации (должность, ученая степень и ученое звание, специализация, сфера научных интересов, педагогический стаж работы, профессиональные достижения, образование, повышение квалификации, дополнительная информация, контактная информация, личный сайт) пользователь обязуется предоставить Администрации сайта настоящие действующие данные. Публикация персональной информации доступна только лицом, информация о котором публикуется.
3.2. Участники проекта, отправляющие фотографии, обязуются, что они являются непосредственными владельцами этих фотографии и не возражают от использования фотографий на сайте.
4. Прочие условия
4.1. Все возможные споры, вытекающие из настоящего Соглашения или связанные с ним, подлежат разрешению в соответствии с действующим законодательством Российской Федерации.
4.2. Ничто в Соглашении не может пониматься как установление между Пользователем и Администрации сайта агентских отношений, отношений товарищества, отношений по совместной деятельности, отношений личного найма, либо каких-то иных отношений, прямо не предусмотренных Соглашением.
4.3. Признание судом какого-либо положения Соглашения недействительным или не подлежащим принудительному исполнению не влечет недействительности иных положений Соглашения.
4.4. Администрация сайта следит за соблюдением настоящих Правил и оставляет за собой право редактировать и удалять комментарии Пользователей, если они не отвечают требованиям настоящего Соглашения, требованиям действующего законодательства Российской Федерации или тематике данного сайта.
4.5. Администрация сайта не несет ответственности за текст комментариев и верность оценок оставленных Пользователями. Все претензии и споры со стороны Участников и Пользователей сайта принимаются по электронной почте. Администрация сайта обязуется в скорейшие сроки решать вопросы удаления комментариев, противоречащих условиям данного соглашения.
4.6. Администрация сайта вправе в любой момент изменить или закрыть какой-либо сервис, предоставляемый в рамках сайта, в том числе без предварительного уведомления Пользователей.
4.7. Администрация сайта не несет ответственности за любой косвенный, случайный, умышленный и неумышленный ущерб, включая вред чести, достоинству или деловой репутации, вызванный в связи с использованием сайта.
4.8. Администрация сайта не несет прямой и/или косвенной ответственности за последствия, возникшие в результате прекращения доступа к сервисам, предоставляемым сайтом, при нарушении функционирования одного или нескольких сервисов в результате технического сбоя, либо по причине проведения профилактических мероприятий.
4.9. Страницы сайта могут содержать ссылки на другие ресурсы. Пользователь соглашается с тем, что Администрация не несет никакой ответственности за доступность подобных ресурсов и/или за их контент, а также за любые последствия, связанные с использованием контента этих ресурсов.
4.10. Пользователь принимает положение о том, что все материалы и сервисы сайта или любая их часть могут сопровождаться рекламой. Пользователь согласен с тем, что Администрация сайта не несет какой-либо ответственности и не имеет каких-либо обязательств в связи с такой рекламой.
4.11. Пользователь соглашается с тем, что использует сервисы сайта на свой собственный риск. Все сервисы сайта предоставляются "как есть" без каких-либо гарантий. Администрация не несет ответственности за несоответствие сервисов сайта требованиям Пользователя.
6.2 Закон о защите персональных данных
Немаловажным фактором при создании данного ресурса является учет законов, в особенности самого актуального из них, касающегося источников данных о людях и их личных данных -федеральный закон РФ №152-ФЗ "О персональных данных"
В соответствии с законом, в России существенно возрастают требования ко всем частным и государственным компаниям, и организациям, а также физическим лицам, которые хранят, собирают, передают или обрабатывают персональные данные (в том числе фамилия, имя, отчество). Такие компании, организации и физические лица относятся к операторам персональных данных.
Согласно закону, а также ряду подзаконных актов и руководящих документов регулирующих органов (ФСТЭК России, ФСБ России, Роскомнадзор), операторы ПД должны выполнить ряд требований по защите персональных данных физических лиц (своих сотрудников, клиентов, посетителей и т. д.) обрабатываемых в информационных системах Компании, и предпринять ряд действий:
· Направить уведомление об обработке персональных данных (Закон №152-ФЗ Ст. 22 п. 3)
· Получать письменное согласие субъекта персональных данных на обработку своих персональных данных (Закон №152-ФЗ ст. 9 п. 4)
· Уведомлять субъекта персональных данных о прекращении обработки и об уничтожении персональных данных (Закон №152-ФЗ ст. 21 п. 4)
· Уведомление об обработке персональных данных и письменное согласие субъекта персональных данных не требуется, если оператор персональных данных и субъект персональных данных находятся в трудовых отношениях или иных договорных отношениях (Закон №152-ФЗ ст. 22 п. 2, ст. 6 п. 2)
Заключение
В настоящей дипломной работе была разработана информационная система общественного рейтинга ВУЗов и их профессорского-преподавательского состава.
Проведен анализ существующих аналогов немногочисленных информационных систем, выбор пути реализации данной системы, разработка макетов и полная её реализация.
В целом создание ИС общественного рейтинга как социального проекта процесс достаточно долгий и продолжительный, ввиду того что доведение до совершенства данного источника и средства обработки информации является проектом с большим спектром задач на больших участках времени. Ввиду того, что доработка уместна исключительно в процессе эксплуатации.
Литература
преподаватель информационный программа авторизация
1. В.Э. Фигурнов, "IBM PC для пользователя", 5-е изд., СПб.: Коруна, 1993 г.
2. А.Н. Жигарев, Н.В. Макарова, М.А. Путинцева, "Основы компьютерной грамоты", Ленинград: Машиностроение, 1987 г.
3. Э. Фримен, Э. Фримен Изучаем HTML
4. Сибах, Питер Знакомимся с ECMAscript. developerWorks Россия. IBM (13 июня 2007).
5. Эд Титтел, Джефф Ноубл HTML, XHTML и CSS для чайников
6. ЧОИ ВИН как спроектировать современный сайт
7. С.А. Нестеров "Информационная безопасность и защита информации" 2011 г.
8. Питер Лабберс, Брайан Олберс, Фрэнк Салим. HTML5 для профессионалов: мощные инструменты для разработки современных веб-приложений
9. Скотт Хокинс. Администрирование веб-сервера Apache и руководство по электронной коммерции
10. Иванов Б.С. Педагогическая диагностика
11. Майоров А.Н. Теория и практика создания тестов для системы образования (2002)
12. Ст. Андрущак Г. - Системы оценивания преподавателей студентами (Вопросы экономики, 2007, №6)
13. Кузнецов Максим, Симдянов Игорь. Объектно-ориентированное программирование на PHP.
14. Различные статьи и категории ru.wikipedia.org
Приложение 1
Прикладные серверные программы
public function getListEduFaculty($arrObjects)
{
//Получение списка вузов
if ($arrObjects->action == 'getListEduSchool') {
$query = '
SELECT schoolId,abbreviation FROM `school`
';
$result = $this->performQuery($query);
return $this->json_safe_encode($result);
}
return false;
}
public function getSelectListFaculty($arrObjects)
{
//Получение списка факультетов
if ($arrObjects->action == 'getSelectListFaculty') {
if (!is_numeric($arrObjects->schoolId)) {
return 0;
}
$data = array(
'schoolId' => htmlspecialchars($arrObjects->schoolId)
);
$query = '
SELECT facultyId,abbreviation FROM `faculty`
WHERE schoolId="'.$data['schoolId'].'"
';
$result = $this->performQuery($query);
return $this->json_safe_encode($result);
}
return false;
}
public function getSelectListDepartment($arrObjects)
{
//По факультету получение списка кафедр
if ($arrObjects->action == 'getSelectListDepartment') {
if (!is_numeric($arrObjects->facultyId)) {
return 0;
}
$data = array(
'facultyId' => htmlspecialchars($arrObjects->facultyId)
);
$query = '
SELECT departmentId,abbreviation FROM `department`
WHERE facultyId="'.$data['facultyId'].'"
';
$result = $this->performQuery($query);
return $this->json_safe_encode($result);
}
return false;
}
public function getSelectListSubject($arrObjects)
{
//По факультету получение списка предметов (автокомплит)
if ($arrObjects->action == 'getSelectListSubject') {
if (!isset($arrObjects->ac_letters)) {
return false;
}
$data = array(
'ac_letters' => htmlspecialchars($arrObjects->ac_letters)
);
$query = '
SELECT name FROM `subject`
WHERE name like "'.$data['ac_letters'].'%"
';
$result = $this->performQuery($query);
return $this->json_safe_encode($result);
}
return false;
}
public function saveStudentProcedure($data){
//Сохранение студента
//$data: 'id','name','surname','patronymic','work'
$arr = array();
//Создадим новый объект $newData, в который перепишем $data
//нужно $data['work'] переделать в ассоциативный массив
$newData = array();
foreach ($data['work'] as $key => $value){
$newData[$key] = $value;
}
$data['work'] = $newData;
//student_info - обновление/добавление данных студента
if($data['id'] == '' || !isset($data['id'])){
//Добавление студента
$query =
"INSERT INTO `student_info`
(`name`, `surname`, `patronymic`,`birthday`,`authId`)
VALUES
(
null,
null,
null,
'".date("Y-m-d",$data['birthday'])."',
'".$this->getAuthId()."'
)";
$result = $this->performQuery($query);
$arr[__LINE__] = $result['err'];
$data['id'] = intval($result['res']);
}else{
//Обновление преподавателя
$query =
"UPDATE `student_info` SET
`birthday`= '".date("Y-m-d",$data['birthday'])."',
`authId`='".$data['authId']."'
WHERE
`studentId`='".intval($data['id'])."'
";
$result = $this->performQuery($query);
$arr[__LINE__] = $result['err'];
}
//Обновление мест учебы (удаление лишних)
$strWorkId = '';
foreach($data['work'] as $key => $value){
//Пройдемся по каждому ключу массива работ и
//составим список положительных id, которые нужно оставить
if($key<0){continue;}
$strWorkId .= ' studyId!="'.$key.'" AND';
}
$query = "
DELETE FROM `student` WHERE ".$strWorkId." studentId='".$data['id']."'
";
$result = $this->performQuery($query);
$arr[__LINE__] = $result['err'];
//Обновление мест учебы (добавление новых)
foreach($data['work'] as $key => $value){
//По всем положительным id сделаем обновление student
if($key < 0){continue;}
$query = "
UPDATE `student` SET
`departmentId`='".$value->department."',
`studyStart`='".date("Y-m-d",$value->studyStart)."',
`studyStop`='".date("Y-m-d",$value->studyStop)."'
WHERE `studyId`='".$key."'
";
$result = $this->performQuery($query);
$arr[__LINE__] = $result['err'];
}
//Этап 4
foreach($data['work'] as $key => $value){
//По всем отрицательм id сделаем вставку и получим положительный id
if($key >= 0){continue;}
//Этап 3.1
$query = "
INSERT INTO `student`
(`studyId`,`studentId`, `specialitiesId`, `departmentId`, `studyStart`, `studyStop`)
VALUES (
null,
'".$data['id']."',
null,
'".$value->department."',
'".date("Y-m-d",$value->studyStart)."',
'".date("Y-m-d",$value->studyStop)."'
)
";
$result = $this->performQuery($query);
$arr[__LINE__] = $result['err'];
}
return $arr;
}
public function saveTeacherProcedure($data){
//Сохранение преподавателя
//$data: 'id','name','surname','patronymic','telephone','work'
$arr = array();
//Преобразуем work, и work.subject из json в нормальные объекты
foreach($data['work'] as $key => $value){
$data['work']->$key = $this->json_safe_decode($value);
foreach($data['work']->$key->subject as $key1 => $value1){
$data['work']->$key->subject[$key1] = $this->json_safe_decode($value1);
}
}
Приложение 2
Инструкция пользования сайтом
Главная страница
На главной странице располагаются основные информационные элементы и подкатегории оценочных объектов
Нижняя панель
На нижней панели находятся быстрые ссылки для перехода по основным элементам
Регистрация
Для регистрации необходимо нажать на кнопку "регистрация".
Ввести свои сгенерированные e-mail и пароль, после чего нажать на кнопку "войти".
Ввести все необходимые данные, предварительно выбрав тип учетной записи
Авторизация
Авторизация проходит после нажатия кнопки "войти"
Проставление оценок
Для того чтобы посмотреть и оставить оценки с комментариями используйте поле поиска на сайте.
Поиск на сайте ведется по преподавателям и по вузам.
Поиск преподавателя ведется по его фамилии, имени и отчеству (например, "Иванов Петр Сергеевич"), поиск вуза может вестись как по полному, так и краткому его названию.
Универсальным вариантом поиска является поиск вуза, переход по которому позволит Вам найти все его факультеты и кафедры с преподавателями.
После нахождения нужного вам преподавателя можно проставить ему или вузу оценки согласно описанным критериям
Просмотр оценок
Просмотр оценок осуществляется с помощью навигационного меню в верхней части сайта, при нажатии на преподавателя или учебное заведение открывается его персональная характеристика с отзывами и комментариями
Размещено на Allbest.ru
...Подобные документы
Разработка и внедрение автоматизированной информационной системы. Изучение основных процессов, протекающих в предметной области. Создание базы данных. Исследование средств защиты информации от несанкционированного доступа и идентификации пользователей.
курсовая работа [487,2 K], добавлен 17.03.2014Детализация функций системы и требования к информационной системе. Анализ категорий пользователей. Этапы внедрения автоматизированной информационной системы на предприятии. Описание таблиц базы данных. Защита данных от несанкционированного доступа.
дипломная работа [1,0 M], добавлен 22.07.2015Технические средства обеспечения функционирования информационной системы. Проектирование базы данных информационной системы. Разработка веб-приложения – справочно-информационной системы для предприятия. Организация записи информации в базу данных.
дипломная работа [4,4 M], добавлен 16.05.2022Разработка программного обеспечения для автоматизации деятельности работников книжного магазина. Проектирование информационной системы с использованием базы данных Access. Методы хранения данных. Средства защиты данных от несанкционированного доступа.
контрольная работа [664,9 K], добавлен 13.06.2014Задачи, функции и структура филиала университета. Оценка информационных потоков и UML-моделирование. Анализ структуры информационной системы и системы навигации. Проектирование базы данных, физическая реализация и тестирование информационной системы.
дипломная работа [6,0 M], добавлен 21.01.2012Разработка структуры информационной системы с использованием СУБД MS Access. Моделирование бизнес-процессов с помощью IDEF0-диаграмм. Проектирование приложения в среде Delphi. Физическая реализация структуры базы данных. Создание интерфейса системы.
отчет по практике [3,4 M], добавлен 07.01.2015Создание базы данных, построение на ее основе информационной системы в виде веб-сайта. Обоснование и выбор системы управления базой данных. Датологическое проектирование, разработка алгоритма решения задачи, создание форм. Результаты обработки данных.
отчет по практике [904,1 K], добавлен 13.04.2015Выбор методологии проектирования и разработка информационной системы "Расчёт зарплаты" для предприятия ОАО РТП "Авторемонтник". Архитектурное проектирование базы данных информационной системы и разработка её интерфейса. Тестирование программного модуля.
дипломная работа [2,3 M], добавлен 25.05.2014Проектирование информационной системы. Анализ языков программирования и существующих решений для администрирования системы управления базами данных. Разработка модуля взаимодействия и структуры программы. Модули авторизации и соединения с базой данных.
дипломная работа [4,1 M], добавлен 19.07.2014Выбор инструментальной среды для разработки базы данных. Подсистема сбора, обработки и загрузки данных. Укрупненный алгоритм разрабатываемой информационной системы. Формирование области запросов базы, интерфейс ввода и редактирования входных данных.
курсовая работа [2,2 M], добавлен 25.12.2012Создание структуры базы данных. Таблица реквизитов входных данных информационной системы "Видеобиблиотека". Процессы, составляющие действие в базе данных. Формирование ведомостей с использованием MS Excel. Использование интегрированной среды Delphi.
курсовая работа [455,8 K], добавлен 05.01.2013Разработка базы данных для информационной поддержки деятельности аптеки с целью автоматизированного ведения данных о лекарствах аптеки. Проектирование схемы базы данных с помощью средства разработки структуры базы данных Microsoft SQL Server 2008.
курсовая работа [3,6 M], добавлен 18.06.2012Анализ организационной структуры и информационной системы академии. Выявление недостатков и выбор метода устранения недостатков. Проектирование и принципы разработки базы данных. Тестирование, апробация, внедрение информационной системы, эффективность.
курсовая работа [2,1 M], добавлен 02.12.2014Разработка информационной системы для предметной области с использованием заданных структур данных. Создание и проверка базы данных, которая позволяет вводить информацию, хранить её в файле, осуществлять поиск, модификацию, сортировку и удаление данных.
курсовая работа [240,0 K], добавлен 29.03.2016Разработка информационной системы ресторана, определение ее границ для реализации базы данных. Перечень запросов, отчетов и операций по вводу информации в информационной системе "Ресторан". Проектирование базы данных, выбор средств ее реализации.
курсовая работа [7,6 M], добавлен 27.04.2011Назначение для информационной системы OpenPOS для автоматизации рабочих процессов в заведениях общественного питания. Состав и структура исходных данных. Основные сведения о предметной области, ее моделирование. Создание и запуск базовых запросов SQL.
курсовая работа [2,2 M], добавлен 28.01.2016Нормативно-правовые документы в сфере информационной безопасности в России. Анализ угроз информационных систем. Характеристика организации системы защиты персональных данных клиники. Внедрение системы аутентификации с использованием электронных ключей.
дипломная работа [2,5 M], добавлен 31.10.2016Выявление сущностей и связей, атрибутов сущностей и назначение первичных ключей при разработке базы данных. Реляционная модель данных. Описание стадий жизненного цикла информационной системы: анализ, проектирование, реализация, внедрение, сопровождение.
курсовая работа [152,2 K], добавлен 11.05.2014Разработка и внедрение информационной и телекоммуникационной системы органов Федерального казначейства Республики Мордовия с учетом обеспечения безопасности данных. Создание автоматизированной системы и пакета прикладных программ "Центр-КС" и "Центр-Ф".
дипломная работа [548,1 K], добавлен 02.07.2011Анализ входной информации и процессов, уровня автоматизации на предприятии. Выявление объекта и задачи автоматизации. Разработка концепции построения информационной модели информационной системы. Разработка структуры базы данных и клиентского приложения.
дипломная работа [2,0 M], добавлен 22.11.2015