Курсовая работа (т): Разработка базы данных предметной области

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

Министерство образования и науки Российской Федерации

ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ

ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ

ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ

"ОРЕНБУРГСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ"

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

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

КУРСОВАЯ РАБОТА

По дисциплине "Базы данных"

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

Руководитель работы

канд. тех. наук, доцент

С.А.Щелоков

Оренбург 2014

Аннотация

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

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

Проектирование базы данных будет на основе системы управления базами данных СУБД SQL Server.

Пояснительная записка содержит 31 страниц, в том числе 28 рисунков, 11 источников, 1 приложение.

Содержание

Ведение

. Схема информационных потоков ДПО

. Диаграммы: IDEF0, IDEF3, DFD

3. Информационно-логическая модель предметной области по нотациям Ричарда Баркера

. Даталогическая модель реляционной БД в виде диаграммы схемы отношений

5. Запросы к БД на уровне представлений и параметрические запросы на уровне функций пользователя и хранимых процедур

. Мероприятия по защите (описание ролей) и обеспечению целостности (описание триггеров) базы данных

.1 Триггеры

.2 Роли

. Приложение интерфейса для базы данных на языке программирования С# в программной среде Visual Studio

8. Инструкцию по администрированию и пользованию БД

Заключение

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

Приложение

реляционный база интерфейс программирование

Введение

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

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

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

Объектом для создания базы данных являлась рекламная фирма. Необходимо было решить следующие задачи:

1.      Хранить информацию о имеющихся в наличии фирмы щитах.

.        Информация о фирмах-клиентах и фирмах-установщиках щитов.

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

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

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

1. Схема информационных потоков ДПО

Клиенты заказывают размещение своей рекламы на щитах. Фирма по рекламе предоставляет свободные щиты и составляет договор с клиентом. Если щитов нужного размера нет или не хватает свободных щитов, то делается заказ у фирм-изготовителей. С ними также заключается договор. После изготовления и установки щита, на нем размещается реклама клиентов.

Рисунок 1 - Схема информационных потоков

1.      Заказ на размещение рекламы на свободных щитах.

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

.        Заказ щитов, составления договоров на их изготовление и установку.

.        Составление договоров на изготовление и установку щитов, изготовление и установка щитов, согласно заключенным договорам.

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

2. Диаграммы: IDEF0, IDEF3, DFD

Для построения диаграмм использовалась инструментальная среда BPwin.

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

Рисунок 2 - Функциональная модель IDEF0

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

Рисунок 3 - Функциональная модель декомпозиции IDEF0

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

Рисунок 4 - Бизнес процесс предметной области на диаграммеIDEF3

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

Рисунок 5 - Диаграмма потоков данных DFD

3. Информационно-логическая модель предметной области по нотациям Ричарда Баркера

Исходными данными для построения информационно-логической модели предметной области (ИЛМ) являются результаты анализа предметной области, представленные в виде описания классов объектов и связей между ними. Чаще всего ИЛМ предметной области представляют в терминах семантической модели данных, в виде ER-диаграммы предметной области.

В методологии используются следующие соглашения:

–    класс объектов отображается в виде четырехугольника с закругленными углами, а имя класса объектов указывается внутри четырехугольника, это имя существительное в единственном числе, отображенное заглавными буквами;

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

–       четырехугольник, отображающий класс объектов, можно увеличивать до любых размеров, четырехугольники могут быть разных размеров;

–       опциональность свойств помечается: обязательное свойство - звездочкой (*), необязательное - кружочком (о);

–       уникальный идентификатор помечается #, если уникальных идентификаторов несколько, тогда каждый помечается номером, указанным в скобках, например, # (1), #(2);

–       обязательная связь помечается сплошной линией, необязательная связь пунктирной линией;

–       тип (мощность) связи "один" помечается линией, "много" - "вороньей лапой".

Рисунок 6 - Инфологическая модель по нотации Ричарда Баркера

4. Даталогическая модель реляционной БД в виде диаграммы схемы отношений

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

·        Microsoft SQL Server 2008,

·        Microsoft SQL Server Management Studio.

Далее средствами ManagementStudio создана база данных АИС.

Рисунок 7 - Создание базы данных

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

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

Следуя данным руководствам, была создана следующая диаграмма:

Рисунок 8 - Даталогическая модель

5. Запросы к БД на уровне представлений и параметрические запросы на уровне функций пользователя и хранимых процедур

Теперь мы можем заполнить некоторые таблицы, такие как Рекламные щиты, Фирмы-клиенты и т.д. Это также можно сделать средствами Management Studio:

Рисунок 9 - Заполнение таблиц средствами Management Studio

Представления позволяют объединять несколько таблиц в одну и фильтровать их по предопределенному фильтру. К примеру, есть таблица [Договоры с фирмами клиентами], но выборка из этой таблицы не даст полной информации о том рекламном объявлении, которое сейчас расположено на щите. Но можно согласно полю [№ рекламы] присоединить таблицу [Рекламные объявления], в которой есть более полная информация. На рисунке 9 изображено представление, отображающее полною информацию о рекламных объявлениях и том, на каком щите они расположены. Конструктор представлений позволяет, не вникая детально в синтаксис SQL создавать необходимые объединения и фильтрацию таблиц.

Рисунок 10 - Конструктор представлений

В базе данных так же реализованы запросы: по конструкции щитов.

Рисунок 11 - Результат запроса

И запрос на нахождение договоров с фирмами-клиентами за определенный промежуток времени.

Рисунок 12 - Результат запроса

6. Мероприятия по защите (описание ролей) и обеспечению целостности (описание триггеров) базы данных

.1      Триггеры

Триггер - это особая разновидность хранимой процедуры, выполняемая автоматически при возникновении события на сервере базы данных. Триггеры языка обработки данных выполняются по событиям, вызванным попыткой пользователя изменить данные с помощью языка обработки данных. Событиями DML являются процедуры INSERT, UPDATE или DELETE, применяемые к таблице или представлению. Эти триггеры срабатывают при запуске любого допустимого события независимо от того, влияет ли оно на какие-либо строки таблицы.

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

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

Создадим триггер для таблицы Договоры с фирмами-клиентами. Установим, что стоимость договора не может быть меньше 2000 руб.

Рисунок 13 - Триггер ограничения стоимости договора

Теперь при добавлении договора стоимостью меньше 2000 будет выводиться ошибка.

Рисунок 14 - Ошибка в стоимости договора

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

Рисунок 15 - Триггер ограничения срока размещения рекламы

Теперь при добавлении нового договора, в котором срок размещения рекламы более полугода будет выводиться ошибка.

Рисунок 16 - Ошибка в сроке размещения рекламы

6.2 Роли

Для примера настройки в сети разработчика создан тестовый пользователь на компьютере LENOVO1234, с именем "1". На сервере необходимо создать имя входа для него.

Рисунок 17 - Создание пользователя базы данных

Рисунок 18 - Роли сервера тестового пользователя

Далее необходимо добавить пользователя в базу данных "Рекламное агентство", и тоже задать роль.

Рисунок 19 - Создание пользователя базы данных

Пользователь базы данных ассоциируется с ранее созданным тестовым именем входа на сервер. Далее создаем роль Менеджер

Рисунок 20 - Настройка роли менеджера

Роль Менеджер разрешает выборку и обновление данных рекламных щитов.

7. Приложение интерфейса базы данных

Приложения создано с помощью Microsoft Visual Studio 2010 на языке программирования С#.

Рисунок 21 - Главная форма программы

Рисунок 23 - Пример работы программы - запрос "Договоры с клиентами"