Замечание: Все последующие диаграммы, входящие в состав моделей выполняются в CASE-средстве методологии IDEF1X.

6.6. Создание форм, запросов и отчетов в среде СУБД Visual FoxPro

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

На экранных формах можно организовать выбор информации из таблиц-справочников с использованием раскрывающихся списков или отдельных окон, использовать специальные режимы редактирования данных с сохранением или отменой изменений, режимы поиска и отбора информации, печати необходимых отчетов на принтере и пр.[5, 6].

Для работы с данными, отобранными в соответствии с каким-либо условием, может быть использована команда SET FILTER TO <условие> - установить фильтр для открытой таблицы базы данных.

Однако большими возможностями обладает так называемый SQL-запрос - команда SELECT, сформированная в соответствии с правилами языка запросов SQL (Structured Query Language).

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

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

В VFP и других системах фирмы Microsoft (Word, Excel) можно использовать Конструктор запросов, что упрощает и ускоряет написание запросов. Кроме того, в VFP есть Мастер для разработки запросов разного вида. Однако использование этих средств не позволяет реализовать все возможности языка запросов. Максимальные возможности - при написании запроса в текстовом виде в любом программном модуле в соответствии с синтаксисом команды SELECT (полный синтаксис будет описан далее).

Принцип формирования запросов наиболее легко освоить при использовании Мастера запросов [5, 6].

Для разработки отчетов - печатных документов, отражающих информацию базы данных, в системе VFP существует Конструктор отчетов (Report Designer) и Мастер отчетов (Report Wizard). Важным свойством отчетов является возможность группировки данных и получения итоговых данных для групп и всего отчета. При формировании отчетов можно задавать фильтр отбора необходимых данных либо формировать отчет на основе данных SQL-запроса или представления данных (View).

Наиболее просто для разработки основы отчета воспользоваться Мастером отчетов с последующей модификацией и дополнением отчета в Конструкторе.

Существует 2 типа Мастера отчетов:

One-to-Many Report Wizard - Мастер отчета, в котором для одной записи главной таблицы существует множество записей связанной с ней дочерней таблицы.

Report Wizard - Мастер простого отчета, но с возможностью задания группировки данных [5, 6].

6.7. Заключение

Рекомендуется сделать выводы по проекту, определить пути его внедрения и направления дальнейшего совершенствования БД ЭИС.

6.8. Приложение

Обязательно должна быть распечатка созданных: форм (2-3), запросов (3-4) и отчетов (3-4) в среде СУБД Visual FoxPro 9.0 [5, 6].

7. Для защиты курсового проекта предоставляются

1. Пояснительная записка в распечатанном и сброшюрованном виде, оформленная в соответствии с методическими указаниями к курсовому проекту;

2. Электронный носитель, содержащий:

• файл с пояснительной запиской,

• файл со скриптами создания базы данных, всех ее объектов и заполнения данными контрольного примера,

• исходные и исполняемые модули приложений для пользователя,

• файлы, используемые и создаваемые приложением (файлы инициализации, файлы отчетов и справок контрольного примера, сохраняемые в MS Office);

3. Дистрибутив приложения пользователя (если он предусмотрен проектом)

8. Порядок защиты

Защита производится перед комиссией, утверждаемой кафедрой.

Студент допускается к защите при условии наличия подписанной руководителем и студентом пояснительной записки и расчетно-графической части проекта.

Для защиты студенту отводится 8 - 10 минут на изложение содержания работы; в процессе защиты комиссия высказывает свои замечания; выявленные ошибки проекта должны быть отмечены красным карандашом.

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

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

9. Список рекомендуемой литературы

1. Хомоненко, А.Д., Цыганков, В.М., Мальцев, М.Г. Базы данных: Учебник для высших учебных заведений / Под ред. проф. А.Д. Хомоненко. – 5-е изд., доп. и перераб. – СПб.: КОРОНА принт, 2006. – 736 с.

2. Диго, С.М. Базы данных: проектирование и использование: Учебник. – М.: Финансы и статистика, 2005. – 592 с.

3. Кузнецов, С.Д. Основы баз данных: Курс лекций. Учебное пособие / С.Д. Кузнецов. - М.: ИНТУИТ.РУ, Интернет-Университет Информационных Технологий, 2005. — 488 с.

4. Маклаков, С.В. Создание информационных систем с AllFusion Modeling Suite. – М.: ДИАЛОГ-МИФИ, 2003. – 432 с.

5. Мусина, Т.В. Visual FoxPro 8.0. Учебный курс – К.: ВЕК +, СПб.: КОРОНА принт, К.: НТИ, 2004. – 464 с.

6. Вендров, А.М. Проектирование программного обеспечения экономических информационных систем: Учебник. – М.: Финансы и статистика, 2002. – 352 с.: ил.

7. Технологии разработки программного обеспечения/ С.Орлов. СПб.: Питер, 2002. – 464 с.

8. Калянов, Г.Н. CASE – технологии. Консалтинг в автоматизации бизнес-процессов. – 3-е изд. – М.: Горячая линия – Телеком, 2002. – 320 с.

Список использованных источников

1. Хомоненко, А.Д., Цыганков, В.М., Мальцев, М.Г. Базы данных: Учебник для высших учебных заведений / Под ред. проф. А.Д. Хомоненко. – 5-е изд., доп. и перераб. – СПб.: КОРОНА принт, 2006. – 736 с.

2. Диго, С.М. Базы данных: проектирование и использование: Учебник. – М.: Финансы и статистика, 2005. – 592 с.

3. Кузнецов, С.Д. Основы баз данных: Курс лекций. Учебное пособие / С.Д. Кузнецов. - М.: ИНТУИТ.РУ, Интернет-Университет Информационных Технологий, 2005. — 488 с.

4. Маклаков, С.В. Создание информационных систем с AllFusion Modeling Suite. – М.: ДИАЛОГ-МИФИ, 2003. – 432 с.

5. Мусина, Т.В. Visual FoxPro 8.0. Учебный курс – К.: ВЕК +, СПб.: КОРОНА принт, К.: НТИ, 2004. – 464 с.

6. Омельченко, Л.Н. Самоучитель Visual Foxpro 8. – СПб: БХВ-Петербург, 2003. – 688 с.

7. Вендров, А.М. Проектирование программного обеспечения экономических информационных систем: Учебник. – М.: Финансы и статистика, 2002. – 352 с.

8. Белых А.А. Проектирование экономических информационных систем. Методическое пособие по курсовому проектированию. Пермь: Пермская ГСХА, 2005 - 34 с.

9. Белых А.А. Проектирование ЭИС. Методическое пособие по дипломному проектированию. Пермь: Пермская ГСХА, 2006 - 60 с.

Приложение 1

Министерство сельского хозяйства РФ

Федеральное государственное бюджетное образовательное учреждение

высшего профессионального образования

«Пермская государственная сельскохозяйственная академия

имени академика Д. Н. Прянишникова»

Кафедра: Информационных технологий и

автоматизированного проектирования

КОНТРОЛЬНАЯ РАБОТА

по дисциплине «Базы данных»

на тему: «Разработка базы данных экономической информационной системы для автоматизации учета сведений об оргтехнике на предприятии»

Проект выполнил:

студент факультета Прикладной информатики

Направления подготовки 230700

группы ПИ – 31а

Пепеляева Анастасия Ивановна

Руководитель:

доцент кафедры ИТАП,

к.т.н., доцент Прохоров А.А.

Оценка ………………………………

…………………………………………

(дата защиты)

…………………………………………

(подпись преподавателя)

Пермь 201_

Приложение 2

Основы методологии IDEF1X

Предназначение IDEF1X

IDEF1X является методом для разработки реляционных баз данных и использует условный синтаксис, специально разработанный для удобного построения концептуальной схемы. Концептуальной схемой мы называем универсальное представление структуры данных в рамках коммерческого предприятия, независимое от конечной реализации базы данных и аппаратной платформы. Будучи статическим методом разработки, IDEF1X изначально не предназначен для динамического анализа по принципу "AS IS", тем не менее, он иногда применяется в этом качестве, как альтернатива методу IDEF1. Использование метода IDEF1X наиболее целесообразно для построения логической структуры базы данных после того, как все информационные ресурсы исследованы (скажем с помощью метода IDEF1) и решение о внедрении реляционной базы данных, как части корпоративной информационной системы, было принято. Однако не стоит забывать, что средства моделирования IDEF1X специально разработаны для построения реляционных информационных систем, и если существует необходимость проектирования другой системы, скажем объектно-ориентированной, то лучше избрать другие методы моделирования.

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

Концепция и семантика IDEF1X

Сущности в IDEF1X и их атрибуты

Хотя терминология IDEF1X практически совпадает с терминологией IDEF1, существует ряд фундаментальных отличий в теоретических концепциях этих методологий. Сущность в IDEF1X описывает собой совокупность или набор экземпляров похожих по свойствам, но однозначно отличаемых друх от друга по одному или нескольким признакам. Каждый экземпляр является реализацией сущности. Таким образом, сущность в IDEF1X описывает конкретный набор экземпляров реального мира, в отличие от сущности в IDEF1, которая представляет собой абстрактный набор информационных отображений реального мира. Примером сущности IDEF1X может быть сущность "СОТРУДНИК", которая представляет собой всех сотрудников предприятия, а один из них, скажем, Иванов Петр Сергеевич, является конкретной реализацией этой сущности. В примере, приведенном на рис. 1, каждый экземпляр сущности СОТРУДНИК содержит следующую информацию: ID сотрудника, имя сотрудника, адрес сотрудника и т.п. В IDEF1X модели эти свойства называются атрибутами сущности. Каждый атрибут содержит только часть информации о сущности.

Связи между сущностями

Связи в IDEF1X представляют собой ссылки, соединения и ассоциации между сущностями. Связи это суть глаголы, которые показывают, как соотносятся сущности между собой. Ниже приведен ряд примеров связи между сущностями:

Отдел <состоит из> нескольких Сотрудников.

Самолет <перевозит> нескольких Пассажиров.

Сотрудник <пишет> разные Отчеты.

Во всех перечисленных примерах взаимосвязи между сущностями соответствуют схеме один ко многим. Это означает, что один экземпляр первой сущности связан с несколькими экземплярами второй сущности. Причем первая сущность называется родительской, а вторая — дочерней. В приведенных примерах глаголы заключены в угловые скобки. Связи отображаются в виде линии между двумя сущностями с точкой на одном конце и глагольной фразой, отображаемой над линией. На рис. 1 приводится диаграмма связи между Сотрудником и Отделом.

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