БАЛАКОВСКИЙ ИНСТИТУТ ТЕХНИКИ ТЕХНОЛОГИИ И УПРАВЛЕНИЯ

ИНЖЕНЕРНО-СТРОИТЕЛЬНЫЙ ФАКУЛЬТЕТ

КАФЕДРА УПРАВЛЕНИЯ И ИНФОРМАТИКИ В ТЕХНИЧЕСКИХ СИСТЕМАХ

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

по курсу

«Информационное обеспечение систем управления»

ПРОЕКТИРОВАНИЕ РЕЛЯЦИОННОЙ БАЗЫ ДАННЫХ

Допущен к защите Выполнил: ст. гр. УИТ-41

Преподователь Буганов В. Н.

Капралова О. А.________ Принял

«____»__________2009 г. Капралова О. А.________

«____»__________2009 г.

2009

СОДЕРЖАНИЕ

Введение 3

1Инфологическое проектирование БД 5

1.1 Анализ предметной области 5

1.2 Анализ информационных задач 8

2 Определение требований к операционной обстановке 9

2.1 Объем работы ИС 9

2.2 Объем памяти, отводимой под данные 9

3 Выбор СУБД 11

4 Логическое проектирование БД 13

4.1 Создание таблиц и связей между ними 13

4.2 Нормализация отношений 19

5 Физическое проектирование БД 20

5.1 Составление форм, запросов и отчетов 20

5.2 Защита данных 32

Заключение 34

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

Введение

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

Основные функции СУБД – это описание структуры базы данных, обработка данных и управление данными.

База данных – это совокупность сведений о реальных объектах, процессах, событиях или явлениях, относящихся к определённой теме или задаче, организованная таким образом, чтобы обеспечить удобное представление этой совокупности, как в целом, так и любой её части. Реляционная база данных представляет собой множество взаимосвязанных таблиц, каждая из которых содержит информацию об объектах определённого типа. Каждая строка таблицы содержит данные об одном объекте (например, клиенте, автомобиле, документе), а столбцы таблицы содержат различные характеристики этих объектов – атрибуты (например, наименования и адреса клиентов, марки и цены автомобилей). Строки таблицы называются записями, все записи имеют одинаковую структуру – они состоят из полей, в которых хранятся атрибуты объекта. Каждое поле в записи содержит одну характеристику объекта и имеет строго определённый тип данных (например, текстовая строка, число, дата). Все записи имеют одни и те же поля, только в них содержатся разные значения атрибутов.

Любая СУБД позволяет выполнять четыре простейшие операции с данными:

- добавить в таблицу одну или несколько записей;

- удалить из таблицы одну или несколько записей;

- обновить значения некоторых полей в одной или нескольких записях;

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

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

Взаимосвязанные двухмерные таблицы, являющиеся объектами СУБД, называются реляционными таблицами, а сами СУБД – реляционными базами данных.

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

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

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

1 Инфологическое проектирование

Процесс реализации БД представляет собой последовательность переходов от неформального словесного описания информационной структуры предметной области к формализованному описанию объектов предметной области в терминах некоторой модели.

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

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

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

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

1. Клиенты;

2. Заказ;

3. Вид ремонта;

4. Исполнение ремонта;

5. Исполнители;

6. Требуемые запчасти;

7. Запчасти;

8. Заказ деталей;

9. Завод изготовитель;

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

Сущность	Атрибут
Клиенты	ФИО, адрес, телефон (сот), телефон (дом)
Заказ	№ заказа, ФИО, дата заказа, гарантия, тип ремонта, поломка, выполнен
Вид ремонта	Тип ремонта, срок ремонта, цена ремонта
Исполнение ремонта	ФИО исполнителей, № заказа
Исполнители	ФИО исполнителей, образование, стаж, телефон (сот)
Требуемые запчасти	№ заказа, название запчасти
Запчасти	Название запчасти, цена запчасти, наличие
Заказ деталей	Название запчасти, название завода, количество
Завод изготовителей	Название завода, адрес, телефон, факс

Построим ER-диаграмму:

Факс

Телефон

Назв. завода

Кол-во

Назв. запчасти

Завод изготовитель

Заказ деталей

Срок ремонта

Назв. запчасти

Адрес

Тип ремонта

Наличие

Назв. завода

Вид ремонта

Запчасти

Цена запчасти

Тип ремонта

Цена ремонта

№ заказа

Требуемые запчасти

Поломка

Гарантия

ФИО исп

Заказ

Исп.ремонта

Дата

№ заказа

ФИО

Назв. запчасти

Выполнен

№ заказа

Адрес

Исполнители

ФИО исп

Клиенты

Телефон (дом)

Стаж

Телефон

ФИО

Телефон (сот)

Образование

Рисунок 1 - ER-диаграмма базы данных «Ремонт бытовой техники»

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

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

База данных «Ремонт бытовой техники» предназначена в первую очередь для сотрудников мастерской, осуществляющих прием и оформление заказов на ремонт и заказ необходимых деталей на заводе.

2 ОПРЕДЕЛЕНИЕ ТРЕБОВАНИЙ К ОПЕРАЦИОННОЙ ОБСТАНОВКЕ, В КОТОРОЙ БУДЕТ ФУНКЦИОНИРОВАТЬ ИНФОМАЦИОННАЯ СИСТЕМА

2.1 Объём работы информационной системы

Данная база данных будет содержать:

- информацию о 9 заводах;

- информацию о 14 исполнителях;

- информацию о 14 клиентах;

2.2 Объем памяти, отводимый под данные

Для определения объема памяти, отводимой под данные БД воспользуемся сле­дующей форамулой ,

Где l_i-длина записи в i –й таблице;

N_i – примерное (максимально возможное) количество записей i таблице;

N_ai – количество записей в архиве i таблице.

Коэффициент 2 перед суммой нужен для того, чтобы выделить память для хране­ния индексов, промежуточных данных, и для выполнения объемных операций и тому подобных.

Проведем расчет на примере одной таблицы «Вид ремонта»

Таблица 1 – Данные о Виде ремонта

Код Оп	Дата создания	Глава	Сайт	Центральный офис
4	8	35	20	50

Подставив значения, получим:

М_д=2*(50+4+8)*12= 1488

Итоговые значения объема памяти базы данных «Ремонт бытовой техники» приведены в таблице 2.

Таблица 2 – Значения объема данных базы данных таблиц

Название таблицы	Объема памяти (байт)
Вид ремонта	1488
Завод изготовитель	2640
Заказ	3472
Заказ деталей	1428
Запчасти	1652
Исполнение ремонта	672
Исполнители	1652
Клиенты	1960
Требуемые запчасти	1512

Тогда общий объем памяти будет равен:

М_д=1488+2640+3472+1428+1652+672+1652+1960+1512=164,76Кб

Общий объем памяти, отводимый под БД составляет 164,74 Кб. Такой объем памяти приемлем для работы с БД MS Access

3 ВЫБОР СИСТЕМЫ УПРАВЛЕНИЯ БАЗОЙ ДАННЫХ (СУБД)

Среди наиболее ярких представителей систем управления базами данных можно отметить: Lotus Approach, Microsoft Access, Borland dBase, Borland Paradox, Microsoft Visual FoxPro, Microsoft Visual Basic, а также баз данных Microsoft SQL Server и Oracle, используемые в приложениях, построенных по технологии «клиент-сервер». Фактически, у любой современной СУБД существует аналог, выпускаемый другой компанией, имеющий аналогичную область применения и возможности, любое приложение способно работать со многими форматами представления данных, осуществлять экспорт и импорт данных благодаря наличию большого числа конвертеров. Общепринятыми, также, являются технологи, позволяющие использовать возможности других приложений, например, текстовых процессоров, пакетов построения графиков и т.п., и встроенные версии языков высокого уровня (чаще – диалекты SQL и/или VBA) и средства визуального программирования интерфейсов разрабатываемых приложений. Поэтому уже не имеет существенного значения на каком языке и на основе какого пакета написано конкретное приложение, и какой формат данных в нем используется. Более того, стандартом «де-факто» стала «быстрая разработка приложений» или RAD (от английского Rapid Application Development), основанная на широко декларируемом в литературе «открытом подходе», то есть необходимость и возможность использования различных прикладных программ и технологий для разработки более гибких и мощных систем обработки данных. Поэтому в одном ряду с «классическими» СУБД все чаще упоминаются языки программирования Visual Basic 4.0 и Visual C++, которые позволяют быстро создавать необходимые компоненты приложений, критичные по скорости работы, которые трудно, а иногда невозможно разработать средствами «классических» СУБД. Современный подход к управлению базами данных подразумевает также широкое использование технологии «клиент-сервер».

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

Visual FoxPro отличается высокой скоростью, имеет встроенный объектно-ориентированный язык программирования с использованием xBase и SQL, диалекты которых встроены во многие СУБД. Имеет высокий уровень объектной модели. При использовании в вычислительных сетях обеспечивает как монопольный, так и раздельный доступ пользователей к данным. Применяется для приложений масштаба предприятия для работы на различных платформах: Windows 3.x, Windows 95, Macintosh...

Visual Basic – это универсальный объектно-ориентированный язык программирования, диалекты которого встроены в Access, Visual FoxPro. Преимущества: универсальность, возможность создания компонентов OLE, невысокие требования к аппаратным ресурсам ЭВМ. Применяется для создания приложений средней мощности, не связанных с большой интенсивностью обработки данных, разработки компонентов OLE, интеграция компонентов Microsoft Office. Visual C++ – наиболее мощный объектно-ориентированный язык программирования, обладает неограниченной функциональностью. Предназначен для создания компонентов приложений для выполнения операций, критичных по скорости.

SQL Server – сервер баз данных, реализует подход «клиент-сервер» и взаимодействует с указанными пакетами. Главные достоинства: высокая степень защиты данных, мощные средства для обработки данных, высокая производительность. Область применения: хранение больших объемов данных, хранение высокоценных данных или данных, требующих соблюдения режима секретности.

Из всех рассмотренных СУБД, мы будим использовать для создания базы данных Microsoft Аccess, который кроме перечисленных особенностей обладает таким достоинством как распространенность, что является также важным фактором при выборе БД.

Составим сравнительную характеристику основных критерий для выбора СУБД:

Таблица 3 - Характеристики СУБД

СУБД	Visual Basic	Microsoft Access	Microsoft FoxPro	SQL Server
Целостность данных	--	++	--	++
безопасность данных	++	+	+	+
производительность	-	+	++	-
работа в многопользовательских средах	++	++	+	++
импорт-экспорт	+
ресурсоемкость	-	+	-	+
Низкая стоимость разработки и лицензирования	+	-	-	+
Легкость освоения	-	++	-	+

+ поддерживает критерий;

++ является лидером по этому критерию;

- слабая поддержка данного критерия;

-- не поддерживает данный критерий.

4 ЛОГИЧЕСКОЕ ПРОЕКТИРОВАНИЕ БАЗЫ ДАННЫХ

4.1 Создание таблиц

База данных созда­ётся на основании схемы базы данных. Инфологическую модель данных, постро­енную в виде ER–диаграммы, следует преобразовать в схему БД. Преобразова­ние ER–диаграммы в схему БД выполняется путем сопоставления каж­дой сущности и каждой связи, имеющей атрибуты, в отношения (таблицы БД).

Рисунок 1 – Таблица «Вид ремонта»

Таблица 4 – Сущность «Вид ремонта»

Имя поля	Тип данных	Свойства поля
Тип ремонта	Текстовый	Размер поля – 50 Обязательное поле – Да
Срок ремонта	Числовой	Размер поля – Длинное целое Обязательное поле – Да
Цена ремонта	Денежный	Формат поля – # ##0,00" руб." Условие на значение – >0 Сообщение об ошибке – Цена >0!

Рисунок 2 – Таблица «Завод изготовитель»

Таблица 5 – Сущность «Завод изготовитель»

Имя поля	Тип данных	Свойства поля
Название завода	Текстовый	Размер поля – 40 Обязательное поле – Да
Адрес	Текстовый	Размер поля – 40 Обязательное поле – Да
Телефон	Текстовый	Размер поля – 15 Маска ввода – !"+7("999\)000\-0000;;_
Факс	Текстовый	Размер поля – 15 Маска ввода – !"+7("999\)000\-0000;;_

Рисунок 3 – Таблица «Заказ»

Таблица 6 – Ассоциация «Заказ»

Имя поля	Тип данных	Свойства поля
№ заказа	Числовой	Размер поля – Длинное целое Обязательное поле – Да
Состояние ремонта	Логический	Формат поля – ;" Выполнен"[Синий];" Находится на ремонте"[Красный]
ФИО	Текстовый	Размер поля – 20 Обязательное поле – Да
Дата заказа	Дата/время	Формат поля – dd\ mmm", "yyyy
Гарантия	Логический	Формат поля – ;"На гаранти"[Синий];"Гарантия истекла"[Красный]
Тип ремонта	Текстовый	Размер поля – 50 Обязательное поле – Да
Поломка	Текстовый	Размер поля – 40 Обязательное поле – Да

Рисунок 4 – Таблица «Заказ деталей»

Таблица 7 – Ассоциация «Заказ деталей»

Имя поля	Тип данных	Свойства поля
Название запчасти	Текстовый	Размер поля – 50 Обязательное поле – Да
Название завода	Текстовый	Размер поля – 40 Обязательное поле – Да
Дата	Дата/время	Формат поля – dd\ mmm", "yyyy

Рисунок 5 – Таблица «Запчасти»

Таблица 8 – Сущность «Запчасти»

Имя поля	Тип данных	Свойства поля
Название запчасти	Текстовый	Размер поля – 50 Обязательное поле – Да
Цена запчасти	Денежный	Формат поля – # ##0,00" руб." Условие на значение – >0 Сообщение об ошибке – Цена >0!
Наличие	Логический	Формат поля – ;"Имеется"[Синий];"Отсутствует"[Красный]

Рисунок 6 – Таблица «Исполнение ремонта»

Таблица 9 – Ассоциация «Исполнение ремонта»

Имя поля	Тип данных	Свойства поля
ФИО	Текстовый	Размер поля – 20 Обязательное поле – Да
№ заказа	Числовой	Размер поля – Длинное целое Обязательное поле – Да

Рисунок 7 – Таблица «Исполнители»

Таблица 10 – Сущность «Исполнители»

Имя поля	Тип данных	Свойства поля
ФИО	Текстовый	Размер поля – 20 Обязательное поле – Да
Образование	Текстовый	Размер поля – 20 Обязательное поле – Да
Стаж	Числовой	Маска ввода - 99
Телефон (сот)	Текстовый	Размер поля – 15 Маска ввода – !"+7("999\)000\-0000;;_

Рисунок 8 – Таблица «Клиенты»

Таблица 11 – Сущность «Клиенты»

Имя поля	Тип данных	Свойства поля
ФИО	Текстовый	Размер поля – 20 Обязательное поле – Да
Телефон (сот)	Текстовый	Размер поля – 15 Маска ввода – !"+7("999\)000\-0000;;_
Телефон (дом)	Текстовый	Размер поля – 15 Маска ввода – !"+7("999\)000\-0000;;_
Адрес	Текстовый	Размер поля – 40 Обязательное поле – Да

Рисунок 9– Таблица «Требуемые запчасти»

Таблица 12 – Ассоциация «Требуемые запчасти»

Имя поля	Тип данных	Свойства поля
№ заказа	Числовой	Размер поля – Длинное целое Обязательное поле – Да
Название запчасти	Текстовый	Размер поля – 50 Обязательное поле – Да

Объединяя все таблицы, получим схему базы данных. Каждая таб­лица связана с другой, и при этом наложено ограничение целостности данных.

Рисунок 10– База данных «Ремонт бытовой техники»