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

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

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

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

по курсу

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

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

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

Преподователь Кизяева Е. О.

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

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

«____»__________2008 г.

2008

СОДЕРЖАНИЕ

Введение 3

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

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

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

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

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

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

3 Выбор СУБД 11

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

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

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

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

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

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

Заключение 32

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

ВВЕДЕНИЕ

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

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

• содержание БД;

• способ организации данных, эффективный для всех её будущих пользовате­лей;

• инструментальные средства управления данными.

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

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

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

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

Постепенно с развитием программного обеспечения ЭВМ появились идеи созда­ния управляющих систем, которые позволяли бы накапливать, хранить и обнов­лять взаимосвязанные данные по целому комплексу решаемых задач. Эти идеи нашли свое воплощение в системах управления базами данных. СУБД взаимодейст­вуют не с локальными, а взаимосвязанными по информации массивами, называе­мыми базами данных. СУБД становятся наиболее популярным средством обработки табличной информации. Они являются инструментальным средством проектирова­ния банков данных при обработке больших объемов информации.

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

Посредством СУБД обеспечивается решение следующих задач:

• создание базы данных;

• занесение, корректировка и изъятие данных;

• упорядочение данных;

• выбор совокупности данных, что отвечают заданным критериям;

• оформление выходных данных и т.д.

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

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

Инфологическая модель является человеко-ориентированной: средой ее хране­ния может быть память человека, а не ЭВМ. Инфологическая модель не изменя­ется до тех пор, пока какие-то изменения в реальном мире не потребуют измене­ния в ней некоторого определения, чтобы эта модель продолжала отражать предметную область.

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

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

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

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

• операторы: код оператора (ключевой атрибут), название оператора сотовой связи;

• для каждого абонента: код абонента (ключевой атрибут), фамилия, имя и отче­ство абонента, его паспортные данные и дата рождения;

• тарифы: код оператора сотовой связи, код тарифа (ключевой атрибут), назва­ние тарифа, срок действия, система оплаты, наличие абонентской платы, используемая валюта;

Для сущностей операторы и тарифы были выделены характеризующие сущно­сти:

• данные оператора: код оператора (ключевой атрибут), дата создания, фами­лия, имя и отчество главы оператора, электронный адрес оператора и ад­рес центрального офиса в России;

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

Также выделена ассоциативная связь между таблицами операторы и або­ненты – подключение, для описания которой используются следующие атрибуты: код абонента, код оператора и код тарифа, которые являются ключевыми, а также описательные атрибуты: дата подключения и номер телефона.

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

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

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

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

База данных «Сотовая связь» будет использоваться работниками салонов связи для хранения информации об абонентах и абонентами для получения информа­ции об операторах, тарифах и услугах.

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

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

При определении объема работы информационной системы будем исходить из того, что база данных будет содержать:

- информацию о 4 операторах;

- информацию о 20 абонентах;

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

- информацию о 31услуге;

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

Если взять в расчет увеличение нагрузки на систему в полтора раза (пиковый мо­мент), то общее число записей будет равно

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

В нашем случае N=1206. Данная цифра является пиковой, то есть более этого количества записей в системе находиться, не может.

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

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

Объем памяти отводимый под данные можно приблизительно оценить по фор­муле:

(2)

где – длина i записи;

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

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

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

База данных «Сотовая связь» не содержит архивных дан­ных, поэтому коэффициентом можно пренебречь. Уравнение примет вид:

(3)

Таблица 1 – Данные об операторах

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

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

Итоговые значения мощностей базы данных «Сотовая связь» приведены в таблице 2.

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

Название таблицы	Мощность (байт)
Операторы	2340
Данные об операторах	380
Абоненты	58000
Подключение	66000
Тарифы	7100
Услуги	35500

Итоговый объем памяти, отводимый под БД составляет 165,35 Кб. Такая мощ­ность таблицы не станет причиной появления замедления в процессе работы.

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

В настоящее время существует большое количество программных продук­тов, в которых можно реализовать спроектированную базу данных. Самыми популяр­ными СУБД на сегодняшний день являются: «Microsoft Access», «Lotus Approach», «dBase», «Clipper».

Рассмотрим достоинства и недостатки каждой и СУБД:

• СУБД «dBase»:

Поддержка dBase введена для импорта и экспорта ваших данных из и в вашу web базу данных, так как этот формат обычно понимают многие программы, например электронные таблицы, в Windows. Поддержка dBase для любого экс­порта или импорта данных хорошо выполняет эти условия.

Использовать dBase файлы для профессионального использования баз дан­ных не рекомендуется. В dBase не поддерживаются индексы и мемо(записи) поля. Также не поддерживается блокировка. Два webсервер процесса, одновременно изме­няющие файлы dBase вполне возможно повредят вашу базу данных. В dBase нельзя изменять определение полей после их создания. Если только файл создан, то поля базы данных фиксировано определены. Не имеется никаких индексов, кото­рые ускоряют поиск или иначе организовывает ваши данные. dBase файлы - это простые последовательные файлы с записями фиксированного размера.

• СУБД «Approach»:

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

Достоинства: Простота использования при формировании запроса и отчета для разнообразных баз данных; SmartMasters позволяют конечному пользователю быстро приступить к разработке приложений; простые инструментальные средства анализа, предоставляемые конечному пользователю через возможности углублен­ного анализа данных, таблицы перекрестных ссылок и непревзойденные фильтры; возможность настраивания приложений Approach с помощью языка программирова­ния LotusScript и управляющих элементов OLE; лучшие в своем классе инструментальные средства построения отчетов по “живым” данным; возмож­ность доступа к широкому разнообразию форматов баз данных с использова­нием технологии PowerKey.

Недостатки: Низкое быстродействие при проведении тестов загрузки базы дан­ных; отсутствие комплекта для широкого развертывания приложений; построи­тель форм и SmartMasters менее совершенны, чем их двойники в пакете Access; неудоб­ный метод для включения диаграмм в отчеты.

• СУБД «Clipper»:

Clipper — это созданная фирмой Nantucket Corp. система программирова­ния приложений в среде БД, включающая в себя быстрый компилятор программ, напи­санных на языке, близком к языку СУБД dBaseIII PLUS, редактор связей, разви­тый интерактивный символический отладчик, обладающий пользовательским интерфейсом в стиле меню, который можно связать с разрабатываемой програм­мой для облегчения ее отладки, большую библиотеку объектных модулей систем­ных функций, а также ряд служебных программ (утилит).

Система Clipper представляет собой, по существу, СУБД компилирующего типа с автономным (self-contained) языком, в значительной мере совместимую по вход­ному языку программирования и организации базы данных с СУБД dBaseIII PLUS. Основная цель разработки этого программного продукта достижение более высокой производительности прикладных систем по сравнению с созданными с помо­щью средств dBaseIII PLUS. Эта задача решается благодаря использованию на стадии исполнения заранее скомпилированного кода вместо интерпретации исход­ных программ, а также за счет более эффективных механизмов индексирова­ния файлов БД.

• СУБД «MS Access»:

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

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

На основе анализа каждой из описанных выше СУБД, составим таблицу (таб­лица 3) , оценивающую эти программы по определенным характеристикам:

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

СУБД	dBase	Approach	Clipper	MS Access
Легкость освоения	-	-	-	+
Создание отчетов и запросов к данным в базе	-	+	-	+
Ресурсоемкость	+	-	+	+
Изменяемость и дополнение дан­ных в базу	-	+	+	+
Целостность данных	-	+	-	+
Востановимость данных	-	+	+	+
Низкая стоимость разработки и лицензирования	+	-	-	+

Из таблицы видно, что наилучшей из рассмотренных СУБД является MS Access. Поэтому для физической реализации данного курсового проекта выбираем СУБД Microsoft Office - Microsoft Access 2007.

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

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

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

• Представить каждый стержень и обозначение таблицей базы данных (базо­вой таблицей) и специфицировать первичный ключ этой базовой таб­лицы.

Таблица 4 – Сущность «Операторы»

Имя поля	Тип данных	Свойства поля
Код Оп	Счетчик	Подпись - Код оператора
Название	Текстовый	Размер поля – 15 Обязательное поле – Да

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

Имя поля	Тип данных	Свойства поля
Код А	Счетчик	Подпись - Код абонента
ФИО	Текстовый	Размер поля – 15 Обязательное поле – Да
Паспортные дан­ные	Текстовый	Размер поля – 15 Маска ввода - !0000\-000000;;_
Дата рождения	Дата/время	Формат поля – Краткий формат даты

Таблица 6 – Сущность «Тарифы»

Имя поля	Тип данных	Свойства поля
Код Оп	Числовой	Подпись - Код оператора
Код Т	Счетчик	Подпись - Код тарифа
Название	Текстовый	Размер поля – 30
Срок действия	Текстовый	Размер поля – 21 Маска ввода – 00\.00\.0000\-00\.00\.0000;;_
Система оплаты	Логический	Формат поля – ;“Предоплата”;”Постоплата”
Абонентская плата	Логический	Формат поля – Да/Нет
Валюта	Текстовый	Размер поля – 4

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

Таблица 7 – Ассоциация «Подключение»

Имя поля	Тип данных	Свойства поля
Код А	Числовой	Подпись - Код абонента
Код Оп	Числовой	Подпись - Код оператора
Код Т	Числовой	Подпись - Код тарифа
Дата подключения	Дата/время	Формат поля – Краткий формат даты
Номер телефона	Текстовый	Размер поля – 13 Маска ввода – !\(999\)000\-0000;;_

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

Таблица 8 – Характеристика «Данные об операторах»

Имя поля	Тип данных	Свойства поля
Код Оп	Числовой	Подпись - Код оператора
Дата создания	Дата/время	Формат поля – Краткий формат даты
Глава	Текстовый	Размер поля – 35
Сайт	Текстовый	Размер поля – 20
Центральный офис	Текстовый	Размер поля – 50

Таблица 9 – Характеристика «Услуги»

Имя поля	Тип данных	Свойства поля
Код Т	Числовой	Подпись - Код тарифа
Код У	Счетчик	Подпись - Код услуги
Название	Текстовый	Размер поля – 30 Обязательное поле – Да
Стоимость	Денежный	Формат поля – # ##0,00 “руб.”
Срок действия	Текстовый	Размер поля – 21 Маска ввода–00\.00\.0000\-00\.00\.0000;;_
Абонентская плата	Логический	Формат поля – Да/Нет

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

Изобразим схему проектируемой базы данных «Сотовая связь» в формате, в кото­ром она выглядит в окне схемы данных приложения Microsoft Access (рисунок 2).

Рисунок 2 – Схема данных БД «Сотовая связь»