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

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

Содержание

Введение

1. Анализ предметной области, инфологическое проектирование

2. Даталогическая и физическая модели данных

3. Выбор оптимальной СУБД и обоснование причин

4. Практика: формирование схемы данных, запросы

Заключение

Литература

Приложения

Введение

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

Темой данной курсовой работы является разработка конкретной базы данных информационной системы «Контроль исполнения договоров с клиентами торгового предприятия» для компании «Р-С». База данных будет использоваться в коммерческой организации которая занимается торговлей компьютерной техникой. База будет использоваться в процессе работы на предприятии для систематизации ведения документации, отчетности и анализа результатов её деятельности.

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

Цель моей работы:

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

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

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

- выявлять проблемы на стадии проектировании, найти способы их решения.

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

Задачами моей работы являются:

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

- создать даталогическую и физическую модели базы данных;

- обеспечить ведение данных о договорах, товарах, клиентах.

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

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

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

Объектом исследования является база данных контроля исполнения договоров компании «Р-С», а предметом исследования - конкретный набор договоров с клиентами компании.

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

1. Анализ предметной области, инфологическое проектирование

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

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

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

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

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

2. Анализ данных. Составить перечень всех элементов данных, входящих в формы и отчеты и сгруппировать их в таблицы БД.

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

Проектирование БД осуществляется на основе трехуровневой архитектуры. Наглядно это представлено на рис.1

Рис.1. Трехуровневая архитектура

Прежде чем начинать проектирование базы данных, необходимо разобраться, как функционирует предметная область создаваемой БД. Для этих целей используют искусственные формализованные языковые средства. Инфологическая модель - описание предметной области, выполненное с использованием специальных языковых средств, не зависящих от используемых в дальнейшем программных средств. Цель инфологического моделирования - обеспечение наиболее естественных для человека способов сбора и представления той информации, которую предполагается хранить в создаваемой базе данных. Одной из наиболее популярных моделей данных на этапе инфологического проектирования является неформальная модель «Сущность-Связь» (Entity-Relationship - ER-модель). Моделирование предметной области базируется на использовании графических диаграмм, включающих небольшое число разнородных компонентов. Основными конструктивными элементами инфологических моделей являются сущности, связи между ними и их свойства (атрибуты).

Сущность - любой различимый объект (объект, который мы можем отличить от другого), информацию о котором необходимо хранить в базе данных. Сущностями могут быть люди, места, самолеты, рейсы, вкус, цвет и т.д. Необходимо различать такие понятия, как тип сущности и экземпляр сущности. Понятие тип сущности относится к набору однородных личностей, предметов, событий или идей, выступающих как целое. Экземпляр сущности относится к конкретной вещи в наборе. Например, типом сущности может быть «Клиент», а экземпляром - «Иванов», «Петров» и т.п.

Определяют три основные класса сущностей:

· стержневые

· ассоциативные

· характеристические.

Стержневая сущность - независимая сущность, которая имеет независимое существование, хотя может обозначать другие сущности.

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

Ассоциативная сущность (ассоциация) - это связь вида "многие-ко-многим" между двумя или более сущностями или экземплярами сущности.

В нашем конкретном случае:

Стержневая сущность

«Договоры», «Клиенты», «Товары»,

Договоры ( код договора, №договора, дата договора, количество, сумма заказа, характеристика).

Клиенты (код клиента, ФИО клиента, телефон, адрес).

Товары (код товара, тип товара, наименование, цена).

Характеристическая сущность

«Продажи», «Исполненные договоры», «Заказанные товары»

«Продажи» (код договора, клиент, дата договора, цена, количество, статус договора)

«Исполненные договоры» (код договора, клиент, дата договора, цена, дата закрытия, количество)

Заказанные товары (код товара, количество)

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

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

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

Типы связей между сущностями

Между двумя сущностям, например, А и В возможны четыре вида связей.

Первый тип - связь ОДИН-К-ОДНОМУ (1:1): в каждый момент времени каждому представителю (экземпляру) сущности А соответствует 1 или 0 представителей сущности В.

Второй тип - связь ОДИН-КО-МНОГИМ (1:М): одному представителю сущности А соответствуют 0, 1 или несколько представителей сущности В.

Так как между двумя сущностями возможны связи в обоих направлениях, то существует еще два типа связи МНОГИЕ-К-ОДНОМУ (М:1) и МНОГИЕ-КО-МНОГИМ (М:N).

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

Рис. 2

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

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

Исходя из описания предметной области и решаемых задач выделим следующие сущности: Товары, Договоры, Клиенты, Сотрудники

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

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

Рисунок 4 - Связи между таблицами БД

Следующим шагом в построении базы данных будет заполнение её таблиц (таблицы 1-5).

Таблица 1 - Товары

Код товара	Наименование	Стоимость	Кол-во товара
00001	ЭВМ Kraftway	35000,00р.	20
00002	МФУ Canon 4550	25000,00р	5
00003	Роутер D-link dir-300	2500,00р.	25
00004	Монитор AOC 22 дюйм	13 000,00р.	14
00005	Клавиатура A-Tech	700,00р.	45
00006	Принтер HP 3220	15000,00р.	6
00007	ЭВМ "Р-С"	25000,00р.	45
00008	Усилитель звуковой	50 000,00р.	5
00009	ЖК-панель Samsung 47 дюйм	40000,00р.	6
00010	Аудиосистема Yamaha	80000,00р.	8
00011	ПО AutoCad Professional	45000,00р.	22

Таблица 2 - Клиенты

Код клиента	ФИО клиента	Адрес	Телефон	Код договора
00001	Антонов А.И.	Москва ул.Лесная д.2, кв.133	8-916-2556999	00004
00002	Борисов В.Г.	Москва ул.Щепкина д.3 кв.12	8-915-2654991	00003
00003	Горячев В.В.	Балашиха, ул.Щелковская д.11 кв.312	8-903-1554896	00002
00004	Дмитриев Е.С.	Реутов, ул.Челомея, д.5 кв.11	8-909-635412	00001
00005	Калязин С.Д.	Мытищи, ул.Ленина д.9 кв.33	8-926-8428546	00005
00006	Кочанов В.И.	Москва ул.Маросейка д.16 кв.4	8-903-1537096	00006
00007	Ложкин Д.Е.	Москва ул.Жукова д.33 кв.231	8-915-2654550	00007

Таблица 3 - Заказы

Код клиента	Код товара
0004	00001
0005	00003
0001	00007
0003	00007
0003	00006
0005	00010
0001	00004
0002	00009
0002	00010
0002	00010
0003	00004
0001	00003
0003	00006
0001	00007

Таблица 4 - Договоры

Код договора	Дата	ФИО клиента	ФИО сотрудника	Ст-ть в договоре	Статус договора
00001	05.02.2017	Дмитриев Е.С.	Кузнецов М.И.	140 000 р.	Закрыт
00002	05.02.2017	Горячев В.В.	Головин А.Е.	75 000 р.	Закрыт
00003	12.02.2017	Борисов В.Г.	Голубев Г.В.	200 000 р.	Закрыт
00004	15.02.2017	Антонов А.И.	Кузнецов М.И.	250 000 р.	Закрыт
00005	16.02.2017	Калязин С.Д.	Головин А.Е.	70 000 р.	Не закрыт
00006	17.02.2017	Кочанов В.И.	Кузнецов М.И.	80 000 р.	Закрыт
00007	19.02.2017	Ложкин Д.Е.	Головин А.Е.	60 000 р.	Не закрыт

Схема связей в таблице

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

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

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

ь в главной таблице нельзя удалить запись, если не удалены связанные с ней записи в подчиненной таблице;

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

Рис. 5 Схема связей между объектами в рассматриваемой БД

Нормальные формы отношений

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

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

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

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

Отношение задано в третьей нормальной форме, если оно задано во второй нормальной форме и каждое свойство этого отношения, не являющееся первичным, не транзитивно зависит от каждого возможного ключа этого отношения.

Транзитивная зависимость выявляет дублирование данных в одном отношении. Если А, В и С - три свойства одного отношения и С зависит от В, а В от А, то говорят, что С транзитивно зависит от А. Преобразование в третью нормальную форму происходит за счет разделения исходного отношения на два.

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

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

2. Даталогическая и физическая модели данных

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

1. Определение цели создания БД

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

Моя база данных разработана для компании, занимающейся поставкой технического оборудования (ЭВМ и т.п.). Клиент организации (все данные и контакты находятся в таблице «Клиенты» ) делает заказ на определенный товар (например, ПК). Этот заказ заносится в таблицу «Заказанные товары». Организация привозит со склада нужное количество и далее осуществляется продажа: клиент получает товар, а мы получаем деньги за выполненный заказ. После этого проданный организацией товар вносится в таблицу «Исполненные договоры» со статусом «выполнено». Т.о. будут использоваться, в основном, две таблицы - на заказ товара и на исполнение договора. Остальные таблицы, формы, запросы базы будут нужны для упрощения отчетности. Чтобы можно было сразу узнать кто заказал, какой менеджер продал, описание товара , посчитать суммы заказов, сделать отбор по определенным данным, обновить, удалить, добавить товар, получить отчеты по товарам и клиентам и выйти из базы.

2. Определение таблиц, которые должна содержать база данных

Один из наиболее сложных этапов в процессе создания базы данных - разработка таблиц, так как результаты, которые должна выдавать база данных не всегда дают полное представление о структуре таблицы.

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

3. Присвоение ключевых полей

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

4. Редактирование структуры базы данных

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

5. Добавление данных и создание других объектов базы данных

Если структуры таблиц отвечают поставленным требованиям, то можно вводить все данные (в режиме конструктора таблиц). После ввода создаются любые запросы, формы, отчеты, макросы и модули.

Структура базы данных. Таблицы

Рассматриваемая база данных содержит 6 таблиц:

-Товары

- Клиенты

- Договоры

-Сотруднки

- Продажи

- Исполненные договоры

При формировании таблицы в настройках указываются первичные либо внешние ключи.

На примере таблицы "Товары", предназначенной для хранения всех товаров с полным их описанием, это выглядит следующим образом:

Таблица 5

Код товара	Группа товаров	Производитель	Характеристика	Цена	Кол-во
00001	ЭВМ	Kraftway	Персональная ЭВМ в конфигурации: ....	35000	15

Код товара - уникальный порядковый № товара. Поле является счетчиком.

Группа товаров - подкатегория для сортировки всей номенклатуры товаров.

Производитель - производитель товара. Берется из таблицы "производитель товаров".

Характеристика - поле, где котором содержится описание товара. Данные вводятся вручную в режиме конструктора (для СУБД Access).

Цена - цена товара за одну единицу. Значение вводится вручную.

Количество - количество товаров. Если значение равно нулю, то товара нет в наличии. Цена вводится вручную. Чтобы систематизировать столбец, надо указать формат поля.

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

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

Типы данных

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

Текстовый - тип данных, используемый для хранения обычного неформатированного текста ограниченного размера (до 255 символов).

Числовой - тип данных для хранения действительных чисел.

Поле MEMO - специальный тип данных для хранения больших объемов текста (до 65 535 символов). Физически текст не хранится в поле. Он храниться в другом месте базы данных, а в поле храниться указатель на него, но для пользователя такое разделение заметно не всегда.

Дата/время - тип данных для хранения календарных дат и текущего времени.

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

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

Логический - тип для хранения логических данных (могут принимать только два значения, например Да или Нет).

Гиперссылка - специальное поле для хранения адресов URL Web-объектов Интернета. При щелчке на ссылке автоматически происходит запуск броузера и воспроизведение объекта в его окне.

Таблица 6 Описание физической модели

Наименование поля	Тип данных	Примечание
Таблица «Договоры»
Код договора	Счетчик	Ключ
Дата договора	Дата/время	Краткий формат даты
Сумма договора	Денежный	Денежный
Наименование товара	Текстовый	100
ФИО сотрудника	Текстовый	255
Статус договора	Логический	Договор закрыт, либо не закрыт
Таблица «Клиенты»
Код клиента	Счетчик	Ключ
ФИО клиента	Текстовый	255
Адрес	Текстовый	255
Телефон клиента	Числовой	Длинное целое
Код договора	Счетчик	Ключ
Таблица «Товары»
Код товара	Счетчик	Ключ
Сумма договора	Денежный	Денежный
Наименование товара	Текстовый	127
Таблица «Сотрудники»
Код сотрудника	Счетчик	Ключ
ФИО сотрудника	Текстовый	255
Должность сотрудника	Текстовый	255
Телефон сотрудника	Числовой	Длинное целое
Таблица «Продажи»
Таблица «Исполненные договоры»

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

3. Выбор оптимальной СУБД и обоснование причин

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

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

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

Сетевая модель данных строится по принципу «главный и подчиненный тип одновременно», то есть любой тип данных одновременно может одновременно порождать несколько подчиненных типов (быть владельцем набора) и быть подчиненным для нескольких главных (быть членом набора).

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

Понятие объекта и атрибута были ранее рассмотрены нами в первой главе.

Таблица - упорядоченная структура, состоящая из конечного набора однотипных записей.

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

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

Существует много различных программных пакетов для работы с данными, например dBASE, FoxPro, MySQL, Oracle и др. СУБД, входящая в пакет MS Office, -- это MS Access. Среди программ такого класса можно назвать, вероятно, только две -- кроме Access это OpenOffice.org Base, компонент пакета OpenOffice фирмы SunMicrosytems. Их отличительной особенностью по сравнению с другими пакетами, помимо задачи работы с небольшими базами данных, является наличие дешевого (Access) и бесплатного (Base) графического интерфейса, позволяющего работать с данными без серьезной специальной подготовки.

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

Но есть определенные различия между таблицами в MS Excel и БД в MS Access. С электронными таблицами удобно работать, если число записей невелико (не более 500). При увеличении числа записей работать становится неудобно, главным образом из-за плохой структурированности данных. Кроме того, быстро возрастает нагрузка на оперативную память. Если хранить данные в разных файлах, по мере накопления информации будет все труднее в них ориентироваться. MS Access хранит данные в одном файле, но доступ к ним организован так, чтобы не использовать лишние ресурсы памяти. Отметим, что некоторые другие СУБД хранят информацию в разных файлах, но работе с ними это никак не мешает.

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

В MS Access возможно создание связи между таблицами, что позволяет совместно использовать данные из разных таблиц. Это экономит память, увеличивает скорость обработки данных, позволяет избежать ненужного дублирования и лишних ошибок.

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

Приложение MS Access 2010, входящее в пакет приложений Microsoft Office 2010 - это настольная система управления реляционными базами данных (СУБД), предназначенная для работы на автономном персональном компьютере (ПК) или локальной вычислительной сети под управлением семейства операционных систем Microsoft Windows (Windows 7, Windows 8 и Windows 10).

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

К основным возможностям СУБД MS Access можно отнести следующие:

Ш проектирование базовых объектов - двумерные таблицы с полями разных типов данных;

Ш создание связей между таблицами, с поддержкой целостности данных, каскадного обновления полей и каскадного удаления записей;

Ш ввод, хранение, просмотр, сортировка, изменение и выборка данных из таблиц с использованием различных средств контроля информации, индексирования таблиц и аппарата алгебры логики;

Ш создание, модификация и использование производных объектов (запросов, форм и отчетов).

4. Практика: формирование схемы данных, запросы

Построение запросов

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

Запросы бывают следующих типов:

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

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

ь Создание таблицы - используется для сохранения результата запроса.

ь Обновление - используется для обновления информации в полях таблицы базы данных.

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

ь Удаление - позволяет удалить записи из одной или нескольких взаимосвязанных таблиц с параметром «каскадное удаление связанных записей».

В Access можно создавать несколько типов запросов, например, запрос на выборку и запрос с параметром.

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

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

1. С помощью мастеров.

2. В режиме конструктора.

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

Пример запроса на выборку в нашей БД:

Мы подготовим запрос и назовём его "Анализ продаж". Запрос будет содержать результат заключенных договоров для определенной группы товаров за определенный период. Для примера результат отгрузок ЭВМ за февраль 2017 г. Результатом запроса будет являться:

Таблица 7 Запрос (поиск)

Наименование товара	Валовая Выручка	Количество проданных штук	Количество клиентов
ЭВМ	790 000 руб.	24	3

В условиях отбора мы можем уточнить наш запрос. Например, оставить результаты продаж по конкретному клиенту "Антонов". Либо, поставив в условии отбора столбца "Валовая выручка" фильтр по сумме от 100 000 руб. показать клиентов с крупными партиями заказов.

Другой пример запроса: запрос на обновление товара.

Запрос построен на основе таблиц «Товары» и «Продажи».

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

Рис. 6

Далее мы выбираем поле с данными, которые следует изменить, и вводим выражение (условие изменения) в строке Обновление для этого поля.

Например укажем обновление количества товара с помощью команды [Товар]![Количество].

информация запрос даталогический договор

Заключение

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

В процессе выполнения данной работы нами были достигнуты все поставленные цели:

- мы построили необходимые модели базы данных;

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

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

Итоги:

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

После введения данной базы данных в эксплуатацию ожидается, что время на анализ сократится в 3-4 раза.

Из этого вытекают конкретные задачи моей курсовой работы:

Задачами моей работы являются:

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

- создать даталогическую и физическую модели базы данных;

- обеспечить ведение данных о договорах, товарах, клиентах.

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

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

Литература

1) Базы данных. Учебник и практикум. Сергей Нестеров. Изд. «Юрайт». 2016г.- 230 с.

2) Базы данных. Проектирование. Учебник. Н. Стружкин, В. Годин. Изд. «Юрайт». 2017г.- 478 с.

3) Базы данных. Учебное пособие. О. Голицына, И. Попов, Н. Максимов. Изд. «Дрофа». 2014г.- 400 с.

4) Работа с базами данных в MS ACCESS 2010.Е.А. Мамонтова, О.Н. Цветкова, С.М. Григорьев. Методические указания и задания к изучению курса "Информатика", "Экономическая информатика" для ФГБУ "Финансовый университет при Правительстве Российской Федерации"; 2012г. Эл.издание. - 75 с.

5) «Access 2010 в примерах». Учебно-методическое пособие для Казанского федерального университета. Е.М. Карчевский, И.Е. Филиппов. 2011г. Эл.издание. - 118 с.

6) Базы данных. А. Кузин, С. Левонисова. Изд. «Academia», 2012г. 320 с.

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

...