Рефераты. Информационная система о программных продуктах

Существует три принципиальных преимущества МS Access

1. возможность обеспечения эффективной обработки больших объёмов информации;

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

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

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

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

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

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

3. РАЗРАБОТКА ER-МОДЕЛИ

ER-модель описывает совокупность семантически важных объектов предметной области сущности, их свойств и отношений между объектами (связей). Разработка ER-модели является важным этапом в создании информационной системы и проходит несколько этапов:

- идентификация сущностей и их атрибутов;

- идентификация отношений между сущностями и указания типов отношений;

- разрешения не специфических видов отношений.

ER-модель принято отображать с помощью графического образа - ER-диаграммы.

Выбрав и исследовав в первом разделе курсового проекта предметную область разработки информационной системы можно определить сущности.

Основными сущностями являются: «Программный продукт», «Производитель», «Страна» (страна-производитель), «Интерфейс» (программного продукта), «Операционная система», «Платформа ЭВМ», «Вид программного продукта», «Класс программного продукта», «Лицензия», «Степень защиты», «Область использования», «Место продажи», «Минимальные системные требования», а так же «Объём HDD», «Наминал ОЗУ», «Наминал видеокарты» и «Наминал процессора». Для связывания сущностей Программный продукт и Место продажи используется сущность «Продажа программного продукта»; «Поддерживающие организации» и «Программный продукт» - сущность «Поддержка Программного продукта». Для связывания сущностей используется связь «многие-к-одному», которая является основным видом связи при построении ER-диаграммы. На Рисунке 1. отражены сущности и связи между ними.

Рисунок 1. Сущности и их связи ИС о программных продуктах.

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

.

Рисунок 2. ER-диаграмма ИС о программных продуктах

В центре всей ER - модели сущность «Программный продукт». С сущностью «Программный продукт» связаны 10 сущностей.

Сущности: «Вид программного продукта», «Интерфейс», «Лицензия», «Область использования», «Продажа программного продукта», «Поддержка Программного продукта», «Производитель», «Операционная система», «Степень защиты», «Минимальные системные требования».

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

Сущность «Вид программного продукта» связана с сущностью «Класс программного продукта» - «каждый вид ПП должен содержаться в одном и только одном классе ПП»

Сущность «Продажа программного продукта» связана с сущностью «Место продажи» так - «каждый код продажи ПП должен осуществлен в одном и только одном месте продажи».

Сущность «Поддержка Программного продукта» связана с сущностью «Место продажи» так - «каждый поддержка ПП должна осуществляться одной и только одной поддерживающей организацией». Сущность «Поддерживающие организации» связана с сущностью «Страна» - «каждой поддерживающей организации должна принадлежать одна и только одна страна».

Сущность «Производитель» связана с сущностью «Страна» так «каждому производителю должна принадлежать одна и только одна страна».

Сущность «Операционная система» связана с сущностью «Платформа ЭВМ» так «каждая операционная система должна построена на одной и только одной платформе».

Сущность «Минимальные системные требования» семантически связана еще с четырьмя сущностями: «Объём HDD», «Наминал ОЗУ», «Наминал видеокарты» и «Наминал процессора».

Семантическая связь: «каждое минимальное системное требование должно включать один и только один параметр объёма HDD», «каждое минимальное системное требование должно включать один и только один параметр наминала ОЗУ», «каждое минимальное системное требование должно включать один и только один параметр наминала видеокарты», «каждое минимальное системное требование должно включать один и только один параметр наминала процессора».

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

Проверка качества сущностей:

· Имена сущностей - существительное в единственном числе или записаны компактным словосочетанием.

· Смысл каждой сущности отражен в ее имени.

· Описание сущности является достаточно кратким и смысловым.

· Сущности не являются разновидностью другой сущности с упущенной рекурсивной связью.

· Каждая сущность согласуется с принципами нормализации отношений.

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

· Ключ сущности действительно минимален.

Проверка атрибутов:

· Имя атрибутов - существительное в единственном числе.

· Смысл атрибута отражен в его имени.

· Описание атрибута является достаточно краткими смысловым.

· Атрибуты не представляют упущенную связь.

· Атрибуты не являются агрегатами других данных.

· Значение обязательного атрибута всегда известно.

Проверка связей:

· Связи действительно необходимы.

· Если связь обязательная, то всегда определена сущность с другого конца.

После проверки качества ER -модели можно перейти к разработке структуры базы данных о сдаче сессии.

4. РАЗРАБОТКА СТРУКТУРЫ БАЗЫ ДАННЫХ

Разработав базу данных о программных продуктах при помощи выбранной СУБД Microsoft Access на основа построенной ER-модели, получили 20 таблиц, связанных между собой отношениями «один-ко-многим», таким образом каждой записи со стороны первой таблицы может (или должна) соответствовать одна и более записей в таблице с другой стороны. Связи между таблицами позволяют быстро структурировать и анализировать информацию, схема данных (Приложение №1) отражает данные связи.

Основной является таблица «Программные продукты», которая создана при помощи Конструктора. Технология создания таблицы «Программные продукты»:

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

2. На вкладке ''Общие'' дважды щелкнуть по значку ''База данных''. В окне «Файл новой базы данных'' ввести имя базы данных «Программные продукты».

3. В окне базы данных щелкнуть по кнопке ''Создать''. В окне базы данных выбрать режим создания таблицы с помощью конструктора.

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

5. Сохраняем таблицу и присваиваем ей имя - «Программные продукты».

6. В таблицу вводится необходимые данные.

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

Рисунок 3. Таблица «Программные продукты»

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

Рисунок 4. Применение подстановки к полю «Код производителя»

При подстановке задаются следующие параметры (рис.5):

Рисунок 5. Параметры подстановки

Таблица «Вид ПП» (рис.6) содержит сведения о имеющихся видах программных продуктов, она связана с таблицей «Программные продукты» связью «один-ко-многим» по полю «Код вида ПП», состоит из полей: код вида ПП, название вида ПП, код класса ПП. Также она связана с таблицей «Классы ПП» (рис.7)(поля: код класса ПП, название класса), содержащей классы программных продуктов, что является более широким понятием, по полю «Код класса ПП».

Страницы: 1, 2, 3, 4



2012 © Все права защищены
При использовании материалов активная ссылка на источник обязательна.