Элементы разработки ИС на примере предметной области "Приемная комиссия в вузе"

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

МИНИСТЕРСТВО ПО ОБРАЗОВАНИЮ И НАУКЕ РОССИЙСКОЙ ФЕДЕРАЦИИ

Государственное бюджетное образовательное учреждение высшего профессионального образования

Рубцовский институт (филиал) Алтайского Государственного Университета

Кафедра математики и прикладной информатики

КУРСОВАЯ РАБОТА

По дисциплине: Теория экономических информационных систем

Тема: Элементы разработки ИС на примере предметной области «Приемная комиссия в вузе»

Рубцовск 2017

Реферат

Перечень ключевых слов:

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

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

Информационная система - прикладная программная подсистема, ориентированная на сбор, хранение, поиск и обработку текстовой и/или фактографической информации,

Предметная область - элементы материальной системы, информация о которых хранится и обрабатывается в информационной системе.

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

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

В данной работе отражены основные этапы при проектировании ИС для приемной комиссии вуза. Целью работы является исследование предметной области «приемная комиссия в вузе».

Содержание

• Введение
• 1. История развития информационных систем
• 1.1 История развития ИС
• 1.2 Жизненный цикл ИС
• 1.3 Критерии эффективности ИС
• 1.4 Классификация ИС и ЭИС
• 1.5 Моделирование информации
• 1.5.1 Концептуальные модели данных
• 1.5.2 ER-модель (модель «сущность-связь»)
• 1.5.3 Реляционная модель данных
• 1.5.4 Переход от ER-модели к реляционной модели данных
• 1.5.5 Постреляционная модель данных
• 1.6 Нормализация данных
• 1.7 CASE-системы для проектирования ИС
• 2. Проектирование ИС приемной комиссии вуза
• 2.1 Пользователи информационной системы
• 2.2 Описание объектов и связей
• 2.2.1 «Учебные заведения»
• 2.2.2 «Специальности»
• 2.2.3 «Абитуриенты»
• 2.2.4 «Экзамены»
• 2.3 Переход к физической модели
• 2.4 Заполнение таблиц данными
• 2.5 Запросы
• 2.6 Возможные аналитические и графические подходы к обработке информации, хранимой в данной ИС
• Заключение
• Список используемых источников
• Введение
• Теория управления предприятием представляет собой довольно обширный предмет для изучения и совершенствования. Это обусловлено широким спектром постоянных изменений ситуации на мировом рынке. Все время растущий уровень конкуренции вынуждает руководителей компаний искать новые методы сохранения своего присутствия на рынке и поддержания рентабельности своей деятельности. Такими методами могут быть диверсификация, децентрализация, управление качеством и многое другое. Современная информационная система должна отвечать всем нововведениям в теории и практике менеджмента. Несомненно, это самый главный фактор, так как построение продвинутой в техническом отношении системы, которая не отвечает требованиям по функциональности, не имеет смысла.
• Экономическая информационная система (ЭИС) представляет собой совокупность организационных, технических, программных и информационных средств, объединенных в единую систему с целью сбора, хранения, обработки и выдачи необходимой информации, предназначенной для выполнения функций управления. ЭИС связывает объект и систему управления между собой и с внешней средой через информационные потоки.
• Цель - исследование предметной области «приемная комиссия в вузе», «учет абитуриентов», «ведение справочника учебных заведений», «ведение справочника специальностей» и изучение их взаимосвязей.
• Объект исследования - приемная комиссия вуза, организующая учет поступающих в вуз абитуриентов.
• Предмет исследования - разработка ИС учета абитуриентов, поступающих в вуз, составление статистики, ведение справочников специальностей и учебных заведений.
• Задачи:
• - Учет абитуриентов, поступающих в вуз;
• - Ведение справочника учебных заведений;
• - Ведение справочника специальностей вуза.
• В данной работе рассмотрены: история развития ИС, жизненный цикл информационных систем, критерии эффективности, концептуальные модели данных, реляционные модели, переход от ER-модели к реляционной модели данных, нормализация данных, CASE-системы для проектирования ИС, создание логической модели системы, перенос данных из физической модели в MS Access, запросы и анализ обрабатываемой информации.
• 1. История развития информационных систем
• 1.1 История развития ИС
• Эффективность применения экономических информационных систем (ЭИС) для управления экономическими объектами (предприятиями, банками, торговыми организациями, государственными учреждениями и т.д.) зависит от широты охвата и интегрированности на их основе функций управления, от способности оперативно подготавливать управленческие решения и адаптироваться к изменениям внешней среды и информационных потребностей.
• Экономические информационные системы с момента появления первых электронных вычислительных машин претерпели существенное изменение в своем развитии.
• В 50-е годы на ЭВМ в основном решались отдельные экономические задачи, связанные с необходимостью переработки больших информационных массивов.
• В 60-е годы возникает идея комплексной автоматизации управления предприятиями и интеграции информационного обеспечения на основе баз данных. Реальностью автоматизированные системы управления стали в 70-е годы на базе ЭВМ 3-го поколения, которые позволили создавать вычислительные системы с распределенной терминальной сетью. Однако недостаточное быстродействие и надежность вычислительных машин, отсутствие гибких средств реализации информационных потребностей пользователей, не смогли превратить ЭИС в инструмент коренного повышения эффективности управления предприятиями.
• 80-е годы отмечены широким использованием персональных ЭВМ управленческими работниками, созданием большого набора автоматизированных рабочих мест (АРМ) на базе языков 4-го поколения (4GL), позволяющих с помощью генераторов запросов, отчетов экранных форм, диалога быстро разрабатывать удобные для пользователей приложения. Однако рассредоточение ЭИС в виде АРМов, локальная («островная») автоматизация не способствовали интеграции управленческих функций и, как следствие, существенному повышению эффективности управления предприятием.
• Для 90-х годов характерно развитие телекоммуникационных средств, которое привело к созданию гибких локальных и глобальных вычислительных сетей, предопределивших возможность разработки и внедрения корпоративных ЭИС (КЭИС). КЭИС объединяют возможности систем комплексной автоматизации управления 70-х годов и локальной автоматизации 80-х годов. Наличие гибких средств связи управленческих работников в процессе хозяйственной деятельности, возможность коллективной работы, как непосредственных исполнителей хозяйственных операций, так и менеджеров, принимающих управленческие решения, позволяют во многом пересмотреть принципы управления предприятиями или проводить кардинальный реинжиниринг бизнес-процессов. Развитие методов интеллектуального анализа данных на основе применения концепций информационных хранилищ, экспертных систем, систем моделирования бизнес-процессов, реализованных в контуре общей информационной системы, способствуют усилению обоснованности принимаемых управленческих решений. Таким образом, современные информационные системы обеспечивают оперативность коммуникации и интеграцию участников бизнес-процессов, повышают качество принимаемых решений на всех уровнях управления.
• Усложнение архитектуры современных информационных систем предопределяет разработку и использование эффективных технологий проектирования, обеспечивающих ускорение создания, внедрения и развития проектов ЭИС, повышение их функциональной и адаптивной надежности.
• 1.2 Жизненный цикл ИС
• Методология проектирования информационных систем описывает процесс создания и сопровождения систем в виде жизненного цикла (ЖЦ)ИС, представляя его как некоторую последовательность стадий и выполняемых на них процессов. Для каждого этапа определяются состав и последовательность выполняемых работ, получаемые результаты, методы и средства, необходимые для выполнения работ, роли и ответственность участников и т.д. Такое формальное описание ЖЦ ИС позволяет спланировать и организовать процесс коллективной разработки и обеспечить управление этим процессом.
• Жизненный цикл ИС можно представить как ряд событий, происходящих с системой в процессе её создания и использования.
• Модель жизненного цикла отражает различные состояния системы, начиная с момента возникновения необходимости в данной ИС и заканчивая моментом её полного выхода из употребления. Модель жизненного цикла - структура, содержащая процессы, действия и задачи, которые осуществляются в ходе разработки, функционирования и сопровождения программного продукта в течение всей жизни системы, от определения требований до завершения её использования.
• В настоящее время известны и используются следующие модели жизненного цикла:
• · Каскадная модель (рис. 2.1) предусматривает последовательное выполнение всех этапов проекта в строго фиксированном порядке. Переход на следующий этап означает полное завершение работ на предыдущем этапе.
• · Поэтапная модель с промежуточным контролем (рис. 2.2). Разработка ИС ведется итерациями с циклами обратной связи между этапами. Межэтапные корректировки позволяют учитывать реально существующее взаимовлияния результатов разработки на различных этапах; время жизни каждого из этапов растягивается на весь период разработки.

• Рис. 2.1. Каскадная модель ЖЦ ИС
• Рисунок 2.2 - Поэтапная модель с промежуточным контролем
• · Спиральная модель (рис. 2.3). На каждом витке спирали выполняется создание очередной версии продукта, уточняются требования проекта, определяется его качество и планируются работы следующего витка.
• Рисунок 2.3 - Спиральная модель
• Особое внимание уделяется начальным этапам разработки - анализу и проектированию, где реализуемость тех или иных технических решений проверяется и обосновывается посредством создания прототипов (макетирования).
• На практике наибольшее распространение получили две основные модели жизненного цикла:
• · Каскадная модель (характерна для периода 1970-1985 гг.)
• · Спиральная модель (характерна для периода после 1986 г.).
• Существует целый ряд стандартов, регламентирующих ЖЦ ПО, а в некоторых случаях и процессы разработки. Среди наиболее известных можно выделить следующие: ГОСТ 34.601-90, ISO/IEC 12207:1995, Custom Development Method (методика Oracle) и т.д.

1.3 Критерии эффективности ИС

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

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

Величина, выбранная в качестве критерия, должна удовлетворять ряду требований:

· должна прямо зависеть от процесса проектирования (функционирования) системы,

· давать наглядное представление об одной из целей системы,

· иметь сравнительно простой алгоритм расчета,

· допускать приближенную оценку по экспериментальным данным.

ЭИС обычно оценивается по комплексу критериев. Оценке подлежат:

· система в целом

· отдельные составляющие этапа проектирования системы, например проекты информационного, программного и технического обеспечения,

· важнейшие компоненты этапа эксплуатации системы, например подготовка информации, её обработка, ведение информационных массивов.

Как правило, функционирование ЭИС направлено на успешную реализацию нескольких целей.

Типичный перечень может включать следующие цели.

1. Повышение эффективности управления объектом (цели С1 - С3):

С1 - максимальную полноту информации для обеспечения принимаемых решений;

С2 - представление информации с максимально возможной скоростью;

С3 - максимальное удобство взамодействия информационной системы с потребителями.

2. Эффективное использование ресурсов ЭИС (цели С4 - С6):

С4 - сокращение расходов на создание, эксплуатацию и развитие ЭИС;

С5 - максимальное извлечение выходной информации из имеющегося объема данных;

С6 - сокращение избыточности в базе данных.

Критериями для названных целей будут:

К1 - отношение объема информации в базе данных к объему информации на объекте управления;

К2 - время обработки информации в ЭИС;

К3 - время, которое потребители расходуют на запрос необходимой информации и её использование в управлении;

К4 - сумма капитальных вложений и текущих затрат на создание, эксплуатацию и развитие ЭИС;

К5 - отношение объемов входной и выходной информации;

К6 - доля избыточной информации в общем объеме данных.

Одновременное достижение указанных целей практически неосуществимо. Например, повышение эффективности ЭИС по критериям К1 и К3вызывает увеличение К4 и достигнутое состояние системы противоречит С4.

1.4 Классификация ИС и ЭИС

ЭИС классифицируются по многим аспектам. Эта классификация является расширяющейся.

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

С функциональной точки зрения можно выделить такие классы ЭИС, как системы обработки данных (СОД), автоматизированные системы управления(АСУ) и информационно-поисковые системы (ИПС). Многие реальные ЭИС обладают чертами нескольких из названных классов, а не какого-то одного.

Основными функциями ЭИС являются сбор, передача, хранение информации и такие операции обработки, как ввод, выборка, корректировка и выдача информации. Для операций преобразования входной информации в выходную, которые не обеспечиваются названными выше функциями, необходимо создание прикладных программ.

ЭИС, дополненная прикладными программами различного назначения, образует систему обработки данных - СОД. Для прикладных программ СОД характерно наличие математичсеких соотношений, которые позволяют вычислять значения элементов выходной информации по известным значениям входной информации без применения методов оптимизации процессов управления экономическим объектом.

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

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

· определения тем, которые отражаются в данном документе,

· выражения этих тем на языке, принятом в информационно-поисковой системе, и записи в виде поисковых образов, которые связываются с документом.

1.5 Моделирование информации

1.5.1 Концептуальные модели данных

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

Обычно различают концептуальные модели двух видов:

· объектно-ориентированные модели, в которых сущности реального мира представляются в виде объектов, а не записей реляционных таблиц;

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

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

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

Концептуальное моделирование баз данных на основе семантических моделей поддерживается во всех известных CASE-средствах (например, таких как ERWin и Power Designer). Кроме того, семантические модели более просты для понимания, особенно при проектировании сравнительно небольших баз данных.

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

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

1.5.2 ER-модель (модель «сущность-связь»)

Одной из наиболее популярных семантических моделей данных является модель «сущность-связь» (часто называемая также ER-моделью - по первым буквам английских слов Entity (сущность) и Relation (связь)).

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

Для моделирования структуры данных используются ER-диаграммы (диаграммы «сущность-связь»), которые в наглядной форме представляют связи между сущностями. В соответствии с этим ER-диаграммы получили распространение в CASE-системах, поддерживающих автоматизированное проектирование реляционных баз данных. Наиболее распространенными являются диаграммы, выполненные в соответствии со стандартом IDEF1X, который используют наиболее популярные CASE-системы (в частности, ERwin, Design/IDEF, Power Designer).

Основными понятиями ER-диаграммы являются сущность, связь и атрибут.

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

· иметь уникальный идентификатор;

· содержать один или несколько атрибутов, которые либо принадлежат сущности, либо наследуются через связь с другими сущностями;

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

Любая сущность может иметь произвольное количество связей с другими сущностями.

В диаграммах ER-модели сущность представляется в виде прямоугольника, содержащего имя сущности.

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

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

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

1.5.3 Реляционная модель данных

Реляционная модель данных была предложена Е. Коддом, известным американским специалистом в области баз данных. Основные концепции этой модели были впервые опубликованы в 1970 г. в статье «A Relational Model of Data for Large Shared Data Banks» (CACM, 1970, Vol. 13, № 6). Реляционная модель позволила решить одну из важнейших задач в управлении базами данных - обеспечить независимость представления и описания данных от прикладных программ, следствием чего было бы существенное упрощение проектирования и программирования баз данных.

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

К основным достоинствам реляционного подхода к управлению базой данных следует отнести:

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

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

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

Несмотря на все свои достоинства, реляционные системы далеко не сразу получили широкое признание. Хотя уже во второй половине 70-х годов появились первые прототипы реляционных СУБД, долгое время считалось невозможным добиться эффективной реализации таких систем. Однако постепенное накопление методов и алгоритмов организации реляционных баз данных и управления ими привели к тому, что уже в середине 80-х годов реляционные системы практически вытеснили с мирового рынка ранние СУБД.

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

На устранение именно этих недостатков в основном и направлены исследования по созданию объектно-ориентированных баз данных.

Основными понятиями реляционной модели данных являются:

· тип данных;

· домен - множество атомарных значений одного и того же типа;

· атрибут - столбцы отношения (таблицы);

· кортеж - множество пар {имя атрибута, значение}, которое содержит одно вхождение каждого имени атрибута, принадлежащего схеме отношения;

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

1.5.4 Переход от ER-модели к реляционной модели данных

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

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

· Каждому атрибуту сущности ставится в соответствие атрибут соответствующего отношения. Переименование атрибутов производится в соответствии с теми же правилами, что и переименование сущностей. Затем каждому атрибуту отношения задается конкретный (допустимый в используемой СУБД) тип данных и обязательность или необязательность данного атрибута (необязательность атрибута означает, что он может принимать специальное значение NULL - пусто).

· Первичный ключ сущности становится первичным ключом (PRIMARY KEY) соответствующего отношения. Все атрибуты, которые входят в первичный ключ сущности, автоматически получают свойство обязательности (NOT NULL - не пусто).

· В каждое отношение, соответствующее подчиненной сущности, добавляется набор атрибутов, являющийся первичным ключом основной сущности. В подчиненном отношении этот набор атрибутов становится внешним ключом (FOREIGN KEY), с помощью которого и реализуются связь между отношениями.

· Для моделирования необязательной связи у атрибутов, соответствующих внешнему ключу, устанавливается возможность принимать неопределенные значение (NULL). Для моделирования обязательной связи атрибутам внешнего ключа устанавливается недопустимость неопределенных значений (NOT NULL).

· Разрешение связей «многие-ко-многим». В реляционной модели поддерживается только один тип связи по множественности - связи «один-ко-многим». Вместе с тем, ER-модель поддерживает и связи «многие-ко-многим». Поэтому требуется специальный механизм преобразование связей «многие-ко-многим» при переходе к реляционной модели. В этом случае вводится дополнительное отношение, атрибутами которого являются первичные ключи двух связанных отношений. Данные ключи являются в новом отношении внешними (FOREIGN KEY), образуя вместе уже первичный ключ нового отношения (PRIMARY KEY). Само новое отношение связано с каждым из исходных отношений связью «один-ко-многим».

1.5.5 Постреляционная модель данных

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

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

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

Примерами постреляционных СУБД являются системы UniVers, Budda и Dasdb.

1.6 Нормализация данных

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

Отношения в первой нормальной форме (сокращенно 1НФ) - это обычное отношение с двухуровневой структурой. Недопустимость в структуре отношения третьего и последующих уровней является ограничением, определяющим 1НФ отношения.

Реляционная база данных в целом характеризуется 1НФ, если все её отношения соответствуют 1НФ.

Отношение имеет вторую нормальную форму (2НФ), если оно соответствует 1НФ и не содержит неполных функциональных зависимостей. Неполная функциональная зависимость - это две зависимости:

· вероятный ключ отношения функционально определяет некоторый неключевой атрибут,

· часть вероятного ключа функционально определяет этот же неключевой атрибут.

Отношение, не соответствующее 2НФ, характеризуется избыточностью хранимых данных. База данных находится в 2НФ, если все её отношения находятся в 2НФ.

Отношение соответствует 3НФ, если оно соответствует 2НФ и среди его атрибутов отсутствуют транзитивные функциональные зависимости (ФЗ).

Транзитивная ФЗ - это две ФЗ:

· вероятный ключ отношения функционально определяет неключевой атрибут,

· этот атрибут функционально определяет другой неключевой атрибут.

Отношения, в которых наблюдается одна ФЗ либо ни одной, будут соответствовать условиям 2НФ и 3НФ, так как неполная и транзитивная ФЗ представляют собой две зависимости. На этом принципе основан алгоритм получения отношений в 3НФ.

Алгоритм получения отношений в 3НФ обладает следующими свойствами:

· сохраняет все первоначальные функциональные зависимости, что гарантирует получение осмысленных отношений с легко интерпретируемой структурой,

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

· результат декомпозиции в 3НФ обычно содержит меньше значений атрибутов, чем исходное отношение (происходит уменьшение избыточности).

1.7 CASE-системы для проектирования ИС

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

Наиболее трудоемкими этапами разработки информационных систем являются этапы анализа и проектирования, в процессе которых CASE-средства обеспечивают качество принимаемых технических решений и подготовку проектной документации. При этом большую роль играют методы визуального представления информации. Это предполагает построение структурных или иных диаграмм в реальном масштабе времени, использование многообразной цветовой палитры, сквозную проверку синтаксических правил. Графические средства моделирования предметной области позволяют разработчикам в наглядном виде изучать существующую информационную систему, перестраивать ее в соответствии с поставленными целями и имеющимися ограничениями.

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

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

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

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

Интегрированное CASE-средство (или комплекс средств, поддерживающих полный жизненный цикл программного обеспечения) содержит следующие компоненты:

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

· графические средства анализа и проектирования, обеспечивающие создание и редактирование иерархически связанных диаграмм (DFD, ER-диаграмма и др.), образующих модели информационных систем;

· средства разработки приложений, включая языки 4GL и генераторы кодов;

· средства конфигурационного управления;

· средства документирования;

· средства тестирования;

· средства управления проектом;

· средства реинжиниринга.

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

Помимо этого, CASE-средства можно классифицировать по следующим признакам:

· применяемым методологиям и моделям систем и БД;

· степени интегрированности с СУБД;

· доступным платформам.

На сегодняшний день Российский рынок программного обеспечения рас-полагает следующими наиболее развитыми CASE-средствами: Vantage Team Builder (Westmount I-CASE), Designer/2000, Silverrun, ERwin+BPwin и т.д.

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

2. Проектирование информационного обеспечения ИС приемной комиссии вуза

2.1 Пользователи информационной системы

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

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

Задачи, которые будут решаться с использованием данной ИС:

- Учет абитуриентов, поступающих в вуз;

- Ведение справочника учебных заведений;

- Ведение справочника специальностей вуза.

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

2.2 Описание объектов и связей

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

2.2.1 «Учебные заведения»

В этой сущности содержаться сведения об учебных заведениях, которые окончили абитуриенты. Атрибуты сущности: school_№ - номер средней школы; school_name - название (аббревиатура) школы; address - адрес учебного заведения; fio_dir - ФИО директора; tel - телефон школы. Сущность «Учебные заведения» показана на рисунке 2.1.

Рисунок 2.1 - Сущность «Учебные заведения»

2.2.2 «Специальности»

Эта сущность содержит информацию об имеющихся специальностях вуза. Атрибуты сущности: spec - название специальности; kaf - кафедра; kol_mest - общее количество мест по специальности; kol_bud_mest - количество бюджетных мест. Сущность «Специальности» показана на рисунке 2.2.

Рисунок 2.2 - Сущность «Специальности»

2.2.3 «Абитуриенты»

Эта сущность содержит основные сведения об абитуриентах и имеет атрибуты: №abiturients - уникальный номер абитуриента; fam - фамилия; name - имя; otch - отчество; birth_date - дата рождения; age - возраст; school№ - номер средней школы; kod_spec - код специальности; form_study - форма обучения. Данная сущность представлена на рисунке 2.3.



Рисунок 2.3 - Сущность «Абитуриенты»

2.2.4 «Экзамены»

Эта сущность содержит информацию об экзаменах, которые необходимо сдавать будущим абитуриентам. Для каждой специальности предусмотрен свой набор экзаменов. Атрибуты сущности: kod_spec - код специальности; predmet - название предмета; date_ex - дата экзамена. Сущность «Экзамены» показана на рисунке 2.4.

Рисунок 2.4 - Сущность «Экзамены»

Связь «Абитуриенты» к «Специальности»: многие к одному.

Связь «Абитуриенты» к «Учебные заведения»: многие к одному.

Связь «Специальности» к «Экзамены»: многие к одному.

Логическая модель ИС, созданная с помощью CASE-средства ERwin, представлена на рисунке 2.5.

2.3 Переход к физической модели

CASE-средства ERwin также позволяет построить физическую модель ИС (рисунок 2.6).

Рисунок 2.5 - Логическая модель ИС

Рисунок 2.6 - Физическая модель ИС

Теперь можно экспортировать данную модель в существующий файл базы данных MS Access (рис. 2.7 - рис. 2.12):

Рисунок 2.7 - экспорт в MS Access



Рисунок 2.8 - экспорт в MS Access

Рисунок 2.9 - экспорт в MS Access

Рисунок 2.10 - экспорт в MS Access



Рисунок 2.11 - экспорт в MS Access

Рисунок 2.12 - экспорт в MS Access

Экспорт данных в MS Access прошел успешно.

информация реляционный запрос access

2.4 Заполнение таблиц данными

Рисунок 2.13 - таблица «Специальности»

Рисунок 2.14 - таблица «Абитуриенты»

Рисунок 2.15 - таблица «Учебные заведения»

Рисунок 2.16 - таблица «Экзамены»

2.5 Запросы

1. Упорядочение по полям: ФИО абитуриента, специальность.

SELECT *

FROM Abiturients

ORDER BY Abiturients.fam, Abiturients.name, Abiturients.otch, Abiturients.kod_spec;

Результат запроса:

Рис. 2.17

2. Все сведения об абитуриенте по первым буквам фамилии.

3. Выпускающая кафедра и полное название специальности X.

SELECT Specialities.kaf, Specialities.spec

FROM Specialities

WHERE Specialities.spec = "Психология"

Результат запроса:

Рис. 2.18

4. Абитуриенты, закончившие школу X.

SELECT Abiturients.fam, Abiturients.name, Abiturients.otch, Schools.school_num

FROM Schools INNER JOIN Abiturients ON Schools.school_num = Abiturients.school_num

WHERE (((Schools.school_num)=1));

Результат запроса:

Рис. 2.19

5. Количество заявлений, поданных на специальность X.

SELECT count (*)

FROM Abiturients

Where Abiturients.spec = "Юриспруденция";

Результат запроса:

Рис. 2.20

6. Средний возраст абитуриентов выбранной специальности.

SELECT avg(Abiturients.age)

FROM Abiturients

WHERE (((Abiturients.spec)="Механизация"));

Результат запроса:

Рис. 2.21

Заключение

В данной работе рассмотрены принципы моделирования и проектирования ЭИС приемной комиссии вуза.

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

Информационная система позволяет решать следующие задачи приемной комиссии вуза:

- Учет абитуриентов, поступающих в вуз;

- Ведение справочника учебных заведений;

- Ведение справочника специальностей вуза.

Данную ИС можно использовать для анализа, прогнозирования и составления статистики текущей ситуации приемной кампании.

Список используемых источников

1. Петров В.Н. Информационные системы. М. ЮНИТИ, 2002. 688с.

2. Смирнова Г.Н. Проектирование экономических информационных систем / Смирнова Г.Н., Сорокин А.А., Тельнов Ю.Ф., М: Финансы и статистика, 2003. 512 с.

3. ГрекулВ.И. Проектирование информационных систем / В.И. Грекул, Г.Н. Денищенко, Н.Л. Коровкина. М.: Интуит.ру, 2005. 304 с.

4. Мишенин А.И. Теория экономических информационных систем. М.: Финансы и статистика, 2003. 240 с.

Размещено на Allbest.ru