Разработка базы данных филателиста

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

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

Санкт-Петербургский государственный университет телекоммуникаций им. профессора М.А. Бонч-Бруевича

Факультет информационных систем и технологий

Информационные технологии

Курсовой проект

Разработка базы данных филателиста

Выполнил

студент группы ИСТ-25с:

Алексеев П.М.

Проверил преподаватель:

Липанова И.А.

Санкт-Петербург

2013



Оглавление

Введение

1. Исследование предметной области и обоснование разработки проекта

2. Разработка автоматизированной информационной системы

2.1 Разработка инфологической модели

2.2 Выбор средства проектирования и общие требования к продукту

2.3 Разработка физической модели

2.4 Формы

2.5 Запросы

2.6 Отчеты

Заключение

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



Введение

автоматизированный информационный коллекционирование

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

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

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



1. Исследование предметной области и обоснование разработки проекта

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

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

О каждой марке должна иметься следующая информация:

тема марки

страна выпуска

серия

размер

цена

местонахождение в каталоге.

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

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

Данный программный продукт предусматривает так же следующие вопросы:

добавление:

информации о новых марках;

новых тем;

удаление всех марок одной темы;

изменение месторасположения марки;

выдача:

перечня стран, чьи марки содержатся в данном разделе;

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

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

темы марок заданной страны и их количество;

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

отчет по коллекции:

количество и название тем и стран по разделам;

количество марок каждой страны по каждой теме;

количество страниц в коллекции.

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



2. Разработка автоматизированной информационной системы

2.1 Разработка инфологической модели

Инфологическое (концептуальная, семантическая) проектирование является построением информационной модели предметной области. Такая модель находится на самом верхнем уровне информационной абстракции и обычно не ориентирована на какую-либо СУБД.

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

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

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

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

Проанализировав логику суждений, можно выделить несколько сущностей, и соответственно связей между ними.

Для графического представления инфологической модели используются диаграммы «сущность-связь» (Entity-Relationship). ER-диаграмма на Рисунке 1 построена по нотации Гордона Эвереста, более известной как нотация Crow's Foot (воронья лапка) или Fork (вилка).



Рисунок 1. ER-диаграмма

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

Таблица 1. Определение атрибутов и первичных ключей

Сущность	Первичный ключ	Атрибуты
Раздел	Номер раздела	Название раздела
Тема	Код темы	Код раздела Название темы
Том	Код тома	Код темы Код раздела
Страница	Код страницы	Код тома Номер страницы
Марка	Код марки	Код страницы Номер ячейки Название Серия Страна Размер Цена



2.2 Выбор средства проектирования и общие требования к продукту

Для реализации данной базы данных был использован Microsoft Office Access 2010, так как БД выполненная в данной среде отвечает всем требованием заказчика. Устойчивость системы, простота эксплуатации, надежность и совместимость с программным обеспечение установленным на предприятии.

Системные требования для работы приложения MS Access 2010:

Процессор с тактовой частотой 500 МГц или выше;

ОЗУ объемом 256 МБ или больше;

2 ГБ свободного дискового пространства;

Монитор с разрешением 1024 х 768 или выше;

Операционные системы Windows XP с пакетом обновления 3 (SP3) (32-разрядная), Windows Vista с пакетом обновления 1, Windows Server 2003 R2 с установленным MSXML 6.0, Windows Server 2008 (32- или 64-разрядная), Windows 7 или более поздних версий;

Установленное ПО Microsoft .NET Framework 3.5.

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

организация бесперебойного питания технических средств;

использование лицензионного программного обеспечения;

регулярное сервисное обслуживание техники;

регулярным выполнением рекомендаций Министерства труда и социального развития российской федерации, изложенных в Постановлении от 23 июля 1998 года «Об утверждении межотраслевых типовых норм времени на работы по сервисному обслуживанию ПЭВМ и оргтехники и сопровождению программных средств»;

регулярное испытание программных средств на наличие компьютерных вирусов.

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

На этапе разработки программы была выполнена работа по разработке базы данных и созданию пользовательского интерфейса.

На этапе разработки программной документации бала выполнена разработка программных документов в соответствии с требованиями к составу документации.

Приемо-сдаточные испытания программы проводились согласно разработанной Исполнителем и согласованной Заказчиком Программы и методик испытаний.

Ход проведения приемо-сдаточных испытаний Заказчик и Исполнитель документируют в Протоколе проведения испытаний.

На основании Протокола проведения испытаний Исполнитель совместно с Заказчиком подписывает Акт приемки-сдачи программы в эксплуатацию.

2.3 Разработка физической модели

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

Физическая модель содержит всю информацию, необходимую для реализации конкретной БД. Различают два уровня физической модели:

трансформационную модель (содержит всю информацию, необходимую для реализации в среде конкретной СУБД и дает возможность проверить соответствие физической модели данных требованиям моделируемой системы);

модель СУБД (получается путем автоматической генерации из трансформационной модели и является отображением системного каталога СУБД).

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

Исходя из данных ER-диаграммы, составляем следующие таблицы:

Таблица 2. Раздел

Имя поля	Тип данных	Размер поля
Код раздела	Счетчик	Длинное целое
Название раздела	Текстовый	20

Таблица 3. Тема

Имя поля	Тип данных	Размер поля
Код темы	Счетчик	Длинное целое
Код раздела	Числовой	Целое
Название темы	Текстовый	20



Таблица 4. Том

Имя поля	Тип данных	Размер поля
Код тома	Счетчик	длинное целое
Код темы	Числовой	Целое
Номер тома	Числовой	Целое

Таблица 5. Страница

Имя поля	Тип данных	Размер поля
Код страницы	Счетчик	Длинное целое
Код тома	Числовой	Целое
Номер тома	Числовой	Целое

Таблица 6. Марка

Имя поля	Тип данных	Размер поля
Код ячейки	Счетчик	Длинное целое
Код страницы	Числовой	Целое
Номер ячейки	Числовой	Целое
Название	Текстовый	20
Страна	Текстовый	20
Серия	Текстовый	20
Размер	Числовой	Целое
Цена	Денежный

После того, как необходимые таблицы построены, строится диаграмма физического уровня (см. Рисунок 2).

Рисунок 2. Физическая модель данных



На рисунке 3 приведен пример заполненных таблиц от раздела до марки.

Рисунок 3. Рабочие таблицы

2.4 Формы

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

выполнять проверку корректности данных при вводе, проводить вычисления;

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

Работа с формами может происходить в трех режимах: в режиме Формы, в режиме Таблицы, в режиме Конструктора. Выбрать режим работы можно при помощи кнопки Вид панели инструментов Конструктор форм либо с помощью команды меню Вид.

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

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

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

Рисунок 4. Пример формы добавления марки

2.5 Запросы

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

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

При разработке базы данных были сформированы 6 запросов, отвечающих требованиям разработчика.

Выдача перечня стран, чьи марки содержатся в данном разделе - рисунок 5.

Рисунок 5. Создание первого запроса через Конструктор запросов

Код SQL:

SELECT DISTINCT Марка.Страна

FROM ((Раздел INNER JOIN Тема ON Раздел.Код = Тема.[Код раздела]) INNER JOIN Том ON Тема.Код = Том.[Код темы]) INNER JOIN (Страница INNER JOIN Марка ON Страница.[Код страницы] = Марка.[Код страницы]) ON Том.[Код тома] = Страница.[Код тома]

WHERE (((Раздел.[Название Раздела])=[Имя раздела]));

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

Рисунок 6



Код SQL:

SELECT Том.[Код тома], Том.[Номер тома]

FROM Тема INNER JOIN Том ON Тема.Код = Том.[Код темы]

WHERE (((Тема.Тема)=[Название темы]));

Выдача перечня тем для серий, включающих марки определенного размера показана на рисунке 7.

Рисунок 7

Код SQL:

SELECT Тема.Тема

FROM Тема INNER JOIN (Том INNER JOIN (Страница INNER JOIN Марка ON Страница.[Код страницы] = Марка.[Код страницы]) ON Том.[Код тома] = Страница.[Код тома]) ON Тема.Код = Том.[Код темы]

WHERE (((Марка.Серия)=[Название серии]) AND ((Марка.Размер)=[Размерчик]));

Выдача темы марок заданной страны, и их количество указана на рисунке 8.



Рисунок 8

Код SQL:

SELECT DISTINCT Тема.Тема, Count(Марка.[Код ячейки]) AS [Count-Код ячейки]

FROM (Тема INNER JOIN Том ON Тема.Код = Том.[Код темы]) INNER JOIN (Страница INNER JOIN Марка ON Страница.[Код страницы] = Марка.[Код страницы]) ON Том.[Код тома] = Страница.[Код тома]

GROUP BY Тема.Тема, Марка.Страна

HAVING (((Марка.Страна)=[Откуда марка]));

Выдача страны, где выпущена марка описана на рисунке 9.

Рисунок 9

Код SQL:

SELECT Марка.Страна

FROM Раздел INNER JOIN (Тема INNER JOIN (Том INNER JOIN (Страница INNER JOIN Марка ON Страница.[Код страницы] = Марка.[Код страницы]) ON Том.[Код тома] = Страница.[Код тома]) ON Тема.Код = Том.[Код темы]) ON Раздел.Код = Тема.[Код раздела]

WHERE (((Страница.[Номер страницы])=[Стр]) AND ((Том.[Номер тома])=[№ тома]) AND ((Тема.Тема)=[Имя темы]) AND ((Раздел.[Название раздела])=[Какой раздел]));

Удаление всех марок одной темы изображено на рисунке 10.

Рисунок 10

Код SQL:

DELETE Марка.*, Тема.Тема

FROM (Тема INNER JOIN Том ON Тема.Код = Том.[Код темы]) INNER JOIN (Страница INNER JOIN Марка ON Страница.[Код страницы] = Марка.[Код страницы]) ON Том.[Код тома] = Страница.[Код тома]

WHERE (((Тема.Тема)=[Название темы]));

2.6 Отчеты

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

Рисунок 11. Отчет по свойствам базы данных



Заключение

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

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

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



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

1. Кириллов В.В. Основы проектирования реляционных баз данных. Учебное пособие. - СПб.: ИТМО, 1995. - 92 с.

2. Карпов Т.С. Базы данных: модели, разработка, реализация. - СПб.: Питер, 2002. - 304 с.: ил.

3. Кириллов В.В. Введение в реляционные базы данных / В.В. Кириллов, Г.Ю. Громов. - СПб.: БХВ - Петербург, 2009. - 464с.: ил.

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

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