Мегаобучалка Главная | О нас | Обратная связь


Этапы создания информационных систем



2019-12-29 172 Обсуждений (0)
Этапы создания информационных систем 0.00 из 5.00 0 оценок




Введение

Российская образовательная система находится на пороге важных событий. Нас ждет массовое проникновение в учебную жизнь электронных пособий, дистанционного обучения, Интернета. Это время принятия ключевых решений, влияние которых распространяется на многие годы. На сегодняшний день основой общероссийского образования является Концепция модернизации российского образования на период до 2010 года, утвержденной распоряжением Правительства Российской Федерации от 29.12.2001 г. № 1756-р, приоритетными направлениями развития образовательной системы Российской Федерации иФедеральной целевой программой развития образования, утвержденной постановлением Правительства Российской Федерации от 23.12.2005 г. № 803. Согласно этим программам в качестве основного фактора обновления профессионального образования выступают запросы развития экономики и социальной сферы, науки, техники, технологий, федерального и территориальных рынков труда, а также перспективные потребности их развития.[1]

В Костромской области на сегодняшний день основной является целевая программа «Информатизация образовательных учреждений Костромской области в 2006-2010 годах», основной целью, которой является поддержка процессов информатизации как важнейшего ресурса развития системы образования для достижения нового уровня и качества обучения на основе эффективного использования информационных коммуникационных технологий. Одним из итогов реализации данной программы является: обеспечение всеобщей ИКТ-компетентности выпускников школ [2]

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

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

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

В реферате содержится теоретический материал «Основные понятия баз данных», а также приведено примерное тематическое и поурочное планирование по учебнику Н.Д. Угриновича темы «Поиск, хранение и обработка информации», конспекты уроков.

В качестве изучения СУБД была выбрана Microsoft Access.

Microsoft Access является СУБД реляционного типа, в которой разумно сбалансированы все средства и возможности, типичных для современных СУБД. Реляционная база упрощает поиск, анализ, поддержку и защиту данных, поскольку они сохраняются в одном месте. Microsoft Access в переводе с английского означает «доступ». Microsoft Access — это функционально полная реляционная СУБД. Кроме того, Microsoft Access одна из самых мощных, гибких и простых в использовании СУБД. В ней можно создавать большинство приложений, не написав ни единой строки программы, но если нужно создать нечто очень сложное, то на этот случай Microsoft Access предоставляет мощный язык программирования — Visual Basic Application.


Основная часть

Глава 1 Базы данных

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

При обработке на ЭВМ данные трансформируются, условно проходя следующие этапы:

1) D1 – данные как результат измерений и наблюдений;

2) D2 – данные на материальных носителях информации (таблицы, протоколы, справочники);

3) D3 – модели (структуры) данных в виде диаграмм, графиков, функций;

4) D4 – данные в компьютере на языке описания данных;

5) D5 – базы данных на машинных носителях информации.[3]

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

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

Суть функционального разбиения хорошо отражена в известной формуле:

«Программа = Данные + Алгоритмы».

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

Объектное разбиение в последнее время называют компонентным, что нашло отражение в специальном термине: «разработка, основанная на компонентах» (Component Based Development - CBD). При этом используется иной принцип декомпозиции - система разбивается на «активные сущности» – объекты или компоненты, которые взаимодействуют друг с другом, обмениваясь сообщениями и выступая, друг к другу в отношении «клиент/сервер». Сообщения, которые может принимать объект, определены в его интерфейсе. В этом смысле посылка сообщения «объекту-серверу» эквивалентна вызову соответствующего метода объекта. Большинство существующих CASE-средств опираются в основном на структурные методологии.

Примером системы, в которой осуществляется функциональное разбиение, является BPwin (система моделирования потоков данных), поддерживающая методологии IDEF0 (функциональная модель) , IDEF3 (WorkFlow Diagram) и DFD (DataFlow Diagram).[5] Функциональная модель предназначена для описания существующих бизнес-процессов на предприятии и идеального положения вещей – того, к чему нужно стремиться. Методология IDEF0 предписывает построение иерархической системы диаграмм – единичных описаний фрагментов системы. Сначала проводится описание системы в целом и ее взаимодействия с окружающим миром (контекстная диаграмма), после чего проводится функциональная декомпозиция – система разбивается на подсистемы и каждая подсистема описывается отдельно (диаграммы декомпозиции). Затем каждая подсистема разбивается на более мелкие и так далее до достижения нужной степени подробности. После каждого сеанса декомпозиции проводится сеанс экспертизы: каждая диаграмма проверяется экспертами предметной области, представителями заказчика, людьми, непосредственно участвующими в бизнес-процессе. Такая технология создания модели позволяет построить модель, адекватную предметной области на всех уровнях абстрагирования.

Этапы создания информационных систем

Принято выделять два уровня представления модели данных – логический и физический.

Цель моделирования данных на логическом уровне состоит в обеспечении разработчика ИС концептуальной схемой базы данных в форме одной модели или нескольких локальных моделей, которые относительно легко могут быть отображены в любую систему баз данных. Логический уровень это абстрактный взгляд на данные, на нем данные представляются так, как выглядят в реальном мире, и могут называться так, как они называются в реальном мире, например «Отдел», «Фамилия сотрудника». Объекты, модели, представляемые на логическом уровне, называются сущностями и атрибутами. Логическая модель данных может быть построена на основе другой логической модели, например модели процессов. Такая модель данных является универсальной и никак не связана с конкретной реализацией СУБД (системы управления базой данных). Построение логической модели ИС до ее программной разработки или до начала проведения архитектурной реконструкции столь же необходимо, как наличие проектных чертежей перед строительством большого здания. Хорошие модели ИС позволяют наладить плодотворное взаимодействие между заказчиками, пользователями и командой разработчиков.

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

1.3 Логические модели.  На логическом уровне проектирования строится так называемая визуальная модель объекта.

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

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

¾ повышение качества программного продукта,

¾ сокращение стоимости проекта,

¾ поставка системы в запланированные сроки.

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

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

Сначала стали использовать иерархические даталогические модели.

Иерархические БД состоят из упорядоченного набора деревьев; более точно, из упорядоченного набора нескольких экземпляров одного типа дерева.

Тип дерева состоит из одного «корневого» типа записи и упорядоченного набора из нуля или более типов поддеревьев (каждый из которых является некоторым типом дерева). Тип дерева в целом представляет собой иерархически организованный набор типов записи.

Пример типа дерева приведен на рис.1

Рис.1 Иерархическая модель данных.

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

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

Сетевые модели также создавались для мало ресурсных ЭВМ.

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

Сетевая БД (рис.2) состоит из набора записей и набора связей между этими записями, а если говорить более точно, из наборов экземпляров каждого типа из заданного в схеме БД набора типов записи и набора экземпляров каждого типа из заданного набора типов связи. Тип связи определяется для двух типов записи: предка и потомка.

Рис.2. Сетевая модель данных.

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

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

Сегодня наиболее распространены реляционные (основанные на двумерных таблицах) модели данных. Любая система данных, не имеет значения какой сложности, может быть сведена к набору таблиц (или «отношений» в терминологии СУРБД). Каждое отношение (таблица) может быть представлено в виде прямоугольного массива со следующими свойствами:

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

· каждая таблица имеет однородные столбцы; все элементы в любом из столбцов одного и того же вида;

· каждому столбцу назначено определенное имя;

· все строки различны; дублировать строки не разрешается;

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

· каждая строка олицетворяет уникальный элемент данных, который ею и описывается;

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

Строки обычно называют записями, а столбцы – полями.

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

 

 

 

 

Рис.3 Реляционная модель данных.

К числу достоинств реляционного подхода можно отнести:

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

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

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

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

Несмотря на всю свою привлекательность и «привычность», классические реляционные системы управления базами данных являются ограниченными. Они идеально походят для таких традиционных приложений, как системы резервирования билетов или мест в гостиницах, а также банковских систем, но их применение в системах автоматизации проектирования, интеллектуальных производственных системах и других системах, основанных на знаниях, часто является затруднительным. Это, прежде всего, связано с примитивностью структур данных, лежащих в основе реляционной модели данных. Плоские нормализованные отношения универсальны и теоретически достаточны для представления данных любой предметной области. Однако в нетрадиционных приложениях в базе данных появляются сотни, если не тысячи таблиц, над которыми постоянно выполняются дорогостоящие операции соединения, необходимые для воссоздания сложных структур данных, присущих предметной области.

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

В качестве других недостатков реляционных СУБД отмечаются следующие:

· негибкость структуры для развивающихся БД;

· затруднения в построении концептуальной модели для объектов с многочисленными связями «многие – ко – многим»;

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

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

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

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

Реляционные БД с их строгим определением структуры и ограниченным набором разрешенных операций, бесспорно, не подходят в качестве базовой платформы для ООБД.[6]



2019-12-29 172 Обсуждений (0)
Этапы создания информационных систем 0.00 из 5.00 0 оценок









Обсуждение в статье: Этапы создания информационных систем

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

Отправить сообщение

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



©2015-2020 megaobuchalka.ru Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. (172)

Почему 1285321 студент выбрали МегаОбучалку...

Система поиска информации

Мобильная версия сайта

Удобная навигация

Нет шокирующей рекламы



(0.011 сек.)