База данных "Рекламное агентство" (курсовая: программа (база данных Access) и пояснительная записка)


СОДЕРЖАНИЕ

ВВЕДЕНИЕ    3
1. РЕЛЯЦИОННАЯ БАЗА ДАННЫХ:  ОСНОВНЫЕ ПОНЯТИЯ    4
2. ЯЗЫК SQL    10
3. ПРОЕКТИРОВАНИЕ БАЗЫ ДАННЫХ    12
3.1. Предметная область    12
3.2. Таблицы БД    13
3.3. Формы БД    19
3.4. SQL запросы    22
3.5. Отчеты    27
ЗАКЛЮЧЕНИЕ    29
СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ    30
ПРИЛОЖЕНИЕ    31

 

Введение

 

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

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

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

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

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

  • рассмотреть теоретическую основу разработки БД;
  • спроектировать БД с реляционной структурой;
  • создать неизбыточную БД с контролем целостности данных;
  • использовать в БД 8 таблиц, 3 отчета, 6 запросов и 6 форм.


1. Реляционная база данных:  основные понятия

 

Часто, говоря о базе данных, имеют в виду просто некоторое автоматизированное хранилище данных. Такое представление не вполне корректно. Действительно, в узком смысле слова, база данных — это некоторый набор данных, необходимых для работы (актуальные данные). Однако данные — это абстракция; никто никогда не видел "просто данные"; они не возникают и не существуют сами по себе. Данные суть отражение объектов реального мира.

Пусть, например, требуется хранить сведения о деталях, поступивших на склад. Как объект реального мира — деталь — будет отображена в базе данных? Для того чтобы ответить на этот вопрос, необходимо знать, какие признаки или стороны детали будут актуальны, необходимы для работы. Среди них могут быть название детали, ее вес, размеры, цвет, дата изготовления, материал, из которого она сделана и т.д. В традиционной терминологии объекты реального мира, сведения о которых хранятся в базе данных, называются сущностями — entities, а их актуальные признаки — атрибутами (attributes).

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

Так, например, в базе данных можно хранить информацию о заказах на поставку деталей на склад (хотя он — не физический объект, а процесс). Атрибутами сущности "заказ" будут название поставляемой детали, количество деталей, название поставщика, срок поставки и т.д. Объекты реального мира связаны друг с другом множеством сложных зависимостей, которые необходимо учитывать в информационной деятельности. Например, детали на склад поставляются их производителями. Следовательно, в число атрибутов детали необходимо включить атрибут "название фирмы-производителя".

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

Таким образом, в широком смысле слова база данных — это совокупность описаний объектов реального мира и связей между ними, актуальных для конкретной прикладной области. Итак, мы получили представление о том, что хранится в базе данных. Теперь необходимо понять, как сущности, атрибуты и связи отображаются на структуры данных. Это определяется моделью данных.

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

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

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

Каждый столбец таблицы — это совокупность значений конкретного атрибута объекта. Так, столбец Материал представляет собой множество значений "Сталь", "Олово", "Цинк", "Никель" и т.д. В столбце Количество содержатся целые неотрицательные числа. Значения в столбце Вес — вещественные числа, равные весу детали в килограммах. Эти значения не появляются из воздуха. Они выбираются из множества всех возможных значений атрибута объекта, которое называется доменом (domain).

Так, значения в столбце материал выбираются из множества имен всех возможных материалов — пластмасс, древесины, металлов и т.д. Следовательно, в столбце Материал принципиально невозможно появление значения, которого нет в соответствующем домене, например, "вода" или "песок". Каждый столбец имеет имя, которое обычно записывается в верхней части таблицы (рис. 1). Оно должно быть уникальным в таблице, однако различные таблицы могут иметь столбцы с одинаковыми именами.

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

 

3.1. Предметная область

 

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

В качестве рекламного агентства будем рассматривать организацию, имеющую 3 филиала (в Москве, Казани и Йошкар-Оле), которые находятся  под общим руководством генерального директора, и которые, в свою очередь, возглавляют на местах заместители директора.

В данной БД будут храниться данные о сотрудниках и заказчиках, проектах агентства и ответственных за них лиц, материально-технической базе организации – автотранспорте и технике, предназначенных для функционирования организации. Также в БД будет храниться такая информация, как: список должностей сотрудников; оклады, соответствующие этим должностям; подразделения агентства и комнаты, в которых находятся сотрудники.

 

3.2. Таблицы БД

 

Таблицы – это основные объекты любой базы данных. Во-первых, в таблицах хранятся все данные, имеющиеся в базе, а во-вторых, таблицы хранят и структуру базы (поля, их типы и свойства). В данной БД мы используем 8 таблиц. Основные из них -  Sotrudniki, Zakazchiki, Projects, Oklad. Вспомогательные – Komnata, Machina, Podrazd, Tehnika. Эти таблицы связаны между собой средствами поддержания целостности, заданными на физическом уровне, то есть на уровне структуры БД.

Например, при добавлении нового объекта в таблицу Sotrudniki, надо обязательно указать внешний ключ к таблице Oklad. Если данный ключ не указан или ключа с таким значением в таблице Oklad не существует, то запись в таблицу Sotrudniki не будет добавлена.

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

1) Поле Sotrudnik_Id – это поле первичного ключа таблицы автоинкрементального типа (то есть счетчик).

2) Поле FIO – текстовое поле с ФИО сотрудника.

3) Oklad_Id – поле внешнего ключа – то есть ссылка на таблицу Oklad, где хранятся названия должностей и оклады, соответствующие им.

4) Komn_Id – внешний ключ для таблицы Komnata

 

Рис. 3. Структура таблицы Sotrudniki

 

На рис 4. изображена структура таблицы Zakazchiki. В этой таблице хранятся данные о заказчиках.

1) Поле Zakazchik_Id – поле первичного ключа данной таблицы автоинкрементального типа.

2) Поле FIO – ФИО заказчика.

3) Поле Telefon – поле Телефон

 

Рис. 4. Структура таблицы Zakazchiki

 

На рис. 5 изображена структура таблицы Projects. В этой таблице хранятся данные о проектах, выполняющихся или уже выполненных в рекламном агентстве.

1) Поле Project_Id – поле первичного ключа типа счетчик.

2) Поле Nazvanie – название проекта.

3) Budget – бюджет проекта. Тип поля – денежный.

4) Ispolnen – флаг исполнения. Если запись отмечена, то проект исполнен. Тип – логический.

5) Otvetstv_Sotrudnik - поле внешнего ключа. Связано с полем Sotrudnik_Id таблицы Sotrudniki и обозначает сотрудника, ответственного за выполнение проекта.

6) Zakazchik_Id - поле внешнего ключа. Связано с полем Zakazchik_Id таблицы Zakazchiki и обозначает сотрудника, ответственного за выполнение проекта.

 

Рис. 5. Структура таблицы Projects

 

На рис. 6 изображена структура таблицы Oklad. В этой таблице хранится информация должностях и соответствующих им окладов сотрудников рекламных агентств.

1) Поле Oklad_Id – поле первичного ключа  типа счетчик.

2) Dolzhnost – наименование должности.

3) Oklad – оклад соответствующий данной должности.

 

Рис. 6. Структура таблицы Oklad

 

На рис. 7 изображена структура таблицы Tehnika. В этой таблице хранятся данные о технике, находящейся на балансе организации.

1) Поле Ser_nomer – поле первичного ключа числового типа – серийный номер.

2) Nazvanie – наименование единицы техники.

3) Stoimost – стоимость единицы техники. Тип – денежный.

4) Otvetstv_Sotrudnik – поле внешнего ключа (ссылка на таблицу Sotrudniki).

 

Рис. 7. Структура таблицы Tehnika

 

В таблице Podrazd хранятся сведения о подразделениях организации в разных городах.

1) Поле Podr_Id – это ключевое авто инкрементальное поле.

2) Поле Podrazd – это текстовое поле с названиями подразделений.

3) Поле Adres – текстовое поле типа char c адресами подразделений.

 

Рис. 8. Структура таблицы Podrazd

 

В таблице Komnata хранятся данные о комнатах в различных подразделениях.

1) Поле Komn_Id – это ключевое автоинкрементальное поле.

2)  Nomer_Komnaty – номер комнаты.

3) Podr_Id – внешний ключ - код подразделения – связь с таблицей Podrazd.

4)  Telefon – номер телефона в комнате с кодом города.

 

Рис. 9. Структура таблицы Komnata

 

В таблице Mashina хранятся данные об автомобилях, закрепленных за подразделениями.

1) Mashina_Id – ключевое автоинкрементальное поле.

2) Mashina – название машины.

3) GosNomer – госномер автомобиля.

4) Tehosmotr – дата техосмотра автомобиля.

5) Podr_Id – внешний ключ – связь с таблицей Podrazd

 

Рис. 10. Структура таблицы Mashina

 

Связь таблиц можно визуально проследить на схеме данных (рис. 11). Жирным шрифтом обозначены ключевые поля таблиц. Связи характеризуют отношения один-ко-многим.

 

База данных "Рекламное агентство"

Рис. 11. Схема данных

 

Заказать курсовую

 

Добавить комментарий


Защитный код
Обновить