методичка. методичка АИС2. Архитектура информационных систем
 Скачать 4.53 Mb.
|
|
МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ОБРАЗОВАНИЯ «СИБИРСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ ГЕОСИСТЕМ И ТЕХНОЛОГИЙ» (СГУГиТ) Басаргин А.А., Бугаков П.Ю. АРХИТЕКТУРА ИНФОРМАЦИОННЫХ СИСТЕМ Утверждено редакционно-издательским советом университета в качестве практикума для студентов, обучающихся по программе подготовки: 09.03.02 – «Информационные системы и технологии»Новосибирск СГУГиТ 2017 УДК 004.056.5 Б27 Рецензенты: кандидат технических наук, доцент, НГТУ В. С. Карманов кандидат технических наук, СГУГиТ А. А. Колесников Басаргин, А.А. Б27 Архитектура информационных систем [Текст] : практикум / А. А. Басаргин, П. Ю. Бугаков. – Новосибирск: СГУГиТ, 2017. – 90 с. ISBN 978-5-87693-000-0 Практикум подготовлен доцентами кафедры прикладной информатики и информационных систем, кандидатами технических наук А. А. Басаргиным и П. Ю. Бугаковым. В настоящем издании содержится краткое изложение теоретического материала и примеры по выполнению практических задач, направленных на реализацию прототипа информационной системы, в объеме, определенном рабочим планом учебной дисциплины «Архитектура информационных систем». Печатается по решению редакционно-издательского совета СГУГиТ УДК 004.056.5 ISBN 978-5-87693-000-0 © СГУГиТ, 2017 ОГЛАВЛЕНИЕ Введение 4 Методические рекомендации по подготовке к лабораторным работам 6 1. Проектирование базы данных 6 2. Работа с таблицами в СУБД Visual FoxPro 24 3. Программирование на языке FoxPro 35 4. Создание экранных форм, отчетов, этикеток и меню. Визуальное программирование 50 5. Варианты заданий 51 Библиографический список рекомендуемой литературы 125 ВВЕДЕНИЕ Данный практикум является частью учебно-методического комплекса по дисциплине «Архитектура информационных систем» и предназначен для проведения практических занятий у студентов, обучающихся по программе подготовки 09.03.02 – «Информационные системы и технологии». Главная цель практикума – помощь студентам в организации самостоятельной работы в процессе лабораторных занятий и подготовки к экзамену по дисциплине «Архитектура информационных систем». В издании рассмотрены некоторые теоретические вопросы и разобран пример разработки и реализации прототипа автоматизированной информационной системы средствами в СУБД Visual FoxPro. Основные теоретические и практические материалы показаны на основе примера по разработке и сопровождению баз данных и связанных с ней приложений. В конце практикума приведен список рекомендуемой литературы, который позволяет студентам самостоятельно изучить дополнительный материал по темам дисциплины «Архитектура информационных систем». МЕТОДИЧЕСКИЕ РЕКОМЕНДАЦИИ ПО ПОДГОТОВКЕ К ЛАБОРАТОРНЫМ РАБОТАМКаждый студент должен ознакомиться с теоретическими основами и описанием, разбираемых в практикуме, примеров, выполнить задание на ПК, придерживаясь описанной технологии, а также подготовить печатный отчет. Для выполнения лабораторных работ необходимо использовать ПК, на которых установлен офисный пакет программ и система управления базами данных Visual FoxPro. В итоге исполнения работ у студента должен быть создан и реализован на основе программного продукта прототип автоматизированной информационной системы, соответствующий предложенной в вариантах предметной области. Интерфейс АИС обязан демонстрировать собою список, реализующее функции ввода и корректировки информации, отбор информации согласно шаблону, представление диаграмм, печать информации и вывод. Порядок выполнения работы. получить от преподавателя вариант задания, включающий в себя описание предметной области и цель проектирования базы данных; проанализировать предметную область, выделить сущности и их атрибуты, построить отношения; построить базу данных средствами СУБД Visual FoxPro; ввести данные в таблицы базы данных; создать программный интерфейс, состоящий из форм, отчетов и этикеток; написать на встроенном языке программирования программные приложения для поиска данных и построения гистограммы; разработать пользовательское меню; выполнить отладку и тестирование разработанного программного обеспечения; оформить отчет. Требования к программной реализации: прототип информационной системы должен включать в себя, по крайней мере, три таблицы (не менее 5 полей и не менее 10 строк данных в каждой); написать не менее двух программ в соответствии с заданием; необходимо реализовать не менее четырех форм (по одной для каждой таблицы и одну форму со связью «один-ко-многим»); при создании формы с помощью мастера форм (Wizard) необходимо добавить на нее хотя бы один дополнительный элемент управления, например, кнопку; необходимо реализовать, по крайней мере, один отчет (report) и не менее одной этикетки (label); реализовать меню, обеспечивающее доступ ко всем объектам разработанного прототипа информационной системы (формам, отчетам. этикеткам, программам и т.д.). По результатам выполнения практических занятий оформляется отчет, который должен содержать: титульный лист; формулировку задания в предметной области; описание логической структуры проекта базы данных; описание физической структуры базы данных в СУБД Visual FoxPro с распечаткой данных, введенных в информационную систему; описание разработанного интерфейса (форм, отчетов, этикетки); тексты программ с комментариями; заключение. После выполнения лабораторной работы студент проходит процедуру ее защиты, отвечая на вопросы преподавателя. Работа считается полностью выполненной при наличии у студента всех файлов, подтверждающих практическое выполнение работы, аккуратно оформленного печатного отчета и положительной оценки за ответы на контрольные вопросы. 1. ПРОЕКТИРОВАНИЕ БАЗЫ ДАННЫХ Время выполнения – 4 часа. Цель работы: научиться создавать концептуальные логические и физические модели данных и на их основе определять основные сущности предметной области, атрибуты таблиц, первичные и альтернативные ключи, устанавливать связи между таблицами. 1.1. Концептуальное проектирование базы данных Известно, что база данных представляет собой набор специально организованных данных о предметной области, хранящихся в памяти вычислительной системы. Они отражают состояние объектов и их взаимосвязи в предметной области [1]. Таким образом, база данных будет представлять набор таблиц, связанных отношениями. Основным этапом проектирования базы данных является разработка концептуальных моделей данных для каждого из существующих типов пользователей созданного приложения (локальные концептуальные модели). Пользовательский вид включает данные, на основе которых конкретный пользователь должен принимать решения или выполнять определенные задачи. Как правило, пользовательский вид отражает некоторую функциональную область в общем поле предприятия - например, производство, продажи, управление персоналом или управление запасами. Пользователь может быть либо отдельным сотрудником, либо группой людей, которые будут работать непосредственно с создаваемым приложением [8]. Таким образом, любая локальная концептуальная модель данных будет содержать: виды таблиц; виды связей; атрибуты таблиц; домены атрибутов; потенциальные ключи; первичные ключи. Во-первых, нужно определить основные объекты, которые могут быть заинтересованы пользователем. Эти объекты представляют собой типы сущностей, которые составляют модель базы данных. Сущность представляет собой абстракцию набора объектов в реальном мире, в котором все объекты набора обладают похожими свойствами и согласуются с одним и тем же набором правил и поведением. Одним из методов идентификации объектов является изучение спецификаций для выполнения конкретных пользовательских функций на предприятии. Из этих спецификаций необходимо извлечь все существительные или комбинации существительного и прилагательного. Для данного варианта - создания базы данных товаров в обувном магазине вы можете выделить следующие объекты: «Товар», «Страна происхождения», «Количество товаров», «Цена продукта», «Цвет продукта», «Адрес производителя», «Директор фирмы-производителя». Потом среди выбранных объектов отбираются самые большие концепции, представляющие интерес. Затем исключаются все существительные, которые просто характеризуют другие объекты. Например, таблица «Адрес производителя» и «Директор производственной компании» можно соединить в объект под названием «Производитель». В этом случае субъекты «Цена товара», «Цвет продукта», «Количество товаров», можно объединить по существу под именем «Товар». Исходя из выше сказанного, оказывается, что для нашего варианта выделяются только две таблицы: «Товар» и «Производитель». После того, как сущности будут выбраны, следующим этапом в разработке модели концептуальных данных будет определение всех существующих отношений между сущностями. Связь - это идентификатор требований, согласно которому субъект вовлечен в отношения. Отношения определяются с помощью глагола. Надо определить все высказывания со словами-сущностями, в которых будут содержаться глаголы. Например, производитель производит товары. Мы заинтересованы только в связях между объектами, которые необходимы для удовлетворения требований проекта. В большинстве случаев ссылки спарены - другими словами, ссылки существуют только между двумя объектами. Тем не менее, следует тщательно изучить наличие сложных отношений в проекте, объединив более двух объектов разных типов, а также рекурсивные отношения, существующие между объектами одного типа [8]. Особое внимание следует уделить проверке того, были ли идентифицированы все ссылки, явно или неявно присутствующие в спецификациях проекта. В принципе, каждая возможная пара сущностей будет полезна для проверки определенной взаимосвязи между ними, что может быть чрезвычайно трудоемкой задачей. Но в целом отказаться от выполнения таких проверок необоснованно [8]. Установив соединения, которые будут иметь место в созданной модели, необходимо определить мощность каждого из них. Существуют следующие мощности: «один к одному» (1:1) «один ко многим» (1:M) «много-ко-многим» (M:N). Таким образом в нашем варианте: - производитель может производить несколько товаров; - один товар (с уникальным артикулом) может быть произведен только одним производителем. Таким образом, мощность связи между субъектами «Производитель» и «Товар» является «один ко многим» (1:М). Это показано на рисунке 1.1. Эта схема называется диаграммой сущность-связь (или диаграммой ER). ER-диаграмма - это метод представления информационно-логической модели базы данных в графической форме для более простого и интуитивного отображения главных элементов базы данных нашего проекта. Одна и та же ER-модель может быть преобразована как в реляционную модель данных, так и в модель данных для иерархической и сетевой СУБД. Однако, поскольку мы рассматриваем реляционные СУБД, можно сказать, что модель логических данных для нас сформулирована в терминах модели реляционных данных. Известно четыре основных графических нотаций для диаграммы «сущность-связь»: IDEF1x; Чена (Chen); Мартина (Martin); Баркера (Barker). В данном лабораторном практикуме будет применена нотация Мартина, для нее основные сущности будут представлены в виде прямоугольников, тип связи изображен на линии, которая ее обозначает, а атрибуты таблицы необходимо записывать в виде списка внутри прямоугольника сущности, при этом первичный ключ будет подчеркнут.  Рис. 1.1. Пример диаграммы “сущность-связь” на уровне сущностей Затем на основе данной методологии построения концептуальной модели требуется идентифицировать атрибуты сущностей. Это все данные, описывающие сущности и связи, выделенные в создаваемой модели базы данных. Мы будем использовать тот же метод, который используется для идентификации сущностей, т.е. выберем все существительные и их содержащие фразы, которые присутствуют в спецификациях для проекта. Выбранное существительное представляет атрибут, если оно описывает свойство, качество, идентификатор или характеристику какого-либо объекта или отношения [8]. Самый простой способ идентификации атрибутов - после определения следующего объекта или соединения задайте себе следующий вопрос: «Какая информация требуется для хранения ...». Каждому идентифицированному атрибуту должно быть предоставлено значимое имя, понятное для пользователей. Основные требования к информации, которая будет содержаться в базе данных, необходимо определить с помощью будущих пользователей[8]. Так в нашем варианте для таблицы «Товар» можно выделить следующие атрибуты, как: «Наименование товара», «Фирма-производитель», «Цена», «Цвет», «Количество». Для сущности «Производитель» – «Название фирмы», «Адрес», «Телефон», «ФИО директора», «№ банковского счета». Это представлено на рис. 1.2. ER-диаграмма на уровне атрибутов. Известно, что любой атрибут таблицы базы данных может быть либо простым, либо составным. Составные атрибуты являются набором простых атрибутов. В нашем случае, атрибут «Адрес» может быть простым и представлять все элементы адреса как единое значение: «630033, г. Новосибирск, ул. Плахотного, д.10». В другом случае этот же атрибут можно представить как составной, а именно он будет состоять из нескольких простых атрибутов, которые будут содержать несколько элементов адреса. Тогда это самое значение может быть разделено на несколько атрибутов, такие как «Почтовый индекс» (630033), «Город» (Новосибирск), «Улица» (Плахотного.), «Дом» (10). Выбор того, как представлять адрес как простой или составной атрибут, определяется требованиями, предъявляемыми к приложению пользователем. Если пользователю не нужен доступ к отдельным элементам адреса, рекомендуется указать его как простой атрибут. Но если пользователю нужен доступ к отдельным элементам адреса, тогда атрибут «Адрес» должен быть составной, сформированный из необходимого количества простых атрибутов.  Рис. 1.2. Диаграмма “сущность-связь” на уровне атрибутов В нашем случае атрибут ФИО директора также можно представить составным, потому что при написании письма, например, требуются только имя и отчество, а при использовании почтового адреса еще и инициалы. Если атрибут адрес будет применен только как почтовый адрес, то такой атрибут будет простым. В отчете о каждом из атрибутов будут содержаться следующие сведения: название атрибута и его характеристика; какое значение принимает атрибут по умолчанию(если таковое имеется); будет или нет данный атрибут обязательным(т.е. может ли он отсутствовать или иметь значение NULL); из каких возможных простых атрибутов он состоит; если атрибут будет иметь вычисляемое значение, то надо определить метод для вычисления этого числа; если атрибут является множественным, т.е. возможно он имеет несколько значений одновременно для одной и той же записи таблицы. Рассмотрим понятие домена. Доменом атрибута называется некоторый набор значений, элементы которого выбираются для присвоения значений атрибуту. Домены должны содержать следующие данные: - для каждого атрибута необходимо иметь набор возможных значений; - каждое из полей атрибутов должно содержать сведения о его размере и формате. Теперь определим возможные домены для каждого из атрибутов таблиц для нашего варианта (табл. 1.1). Таблица 1.1 Возможные домены для каждого из атрибутов
На данном этапе для каждого объекта устанавливается потенциальный ключ (или ключи). После этого выбирается первичный ключ. Потенциальный ключ - это атрибут или минимальный набор атрибутов данного объекта, который позволяет однозначно идентифицировать каждый атрибут сущности. Для некоторых объектов может быть несколько потенциальных ключей. Тогда среди них должен быть определен один ключ, который будет называться первичным ключом. Первичный ключ – это минимальный набор атрибутов, значения которого могут однозначно идентифицировать требуемый атрибут объекта. Альтернативными будут являться все остальные потенциальные ключи. Для определения первичного ключа среди множества имеющихся потенциальных ключей необходимо использовать следующие действия [8]: набор атрибутов для потенциального ключа должен быть минимальным; изменения вероятности возможных значений атрибута потенциального ключа должна быть минимальной; изменение уникальности значений атрибута в будущем для потенциального ключа, должна иметь минимальную вероятность; значения потенциального ключа должны быть минимальны по длине (для текстовых атрибутов таблицы); необходимо выбрать наиболее простой потенциальный ключ, с которым легче всего работать для будущего пользователя информационной системы. Для нашего варианта возможными потенциальными ключами могут являться: для таблицы «Товар»: «Название товара» + «Фирма-производитель» + «Цвет»; для сущности «Производитель»: «Название фирмы». Среди потенциальных ключей выберем первичные ключи: для сущности «Товар»: так как потенциальный ключ сущности «Товар» сложен (состоит из 3 атрибутов), то целесообразно создать «искусственное» ключевое поле, например, «Уникальный индекс товара»; для сущности «Производитель»: «Название фирмы». |