Таразский государственный университет имени М.Х.Дулати
Факультет естественных наук
Кафедра "Компьютерные системы"
Курсовая работа
по дисциплине: "Системы Базы Данных"
на тему "База данных по учёту видеокассет"
Студент группы:ИС-25 Козыбаев А.Б.
Руководитель: Сейпилова Б.С.
Тараз-2007
СОДЕРЖАНИЕ
ВВЕДЕНИЕ
1. КОНЦЕПТУАЛЬНАЯ МОДЕЛЬ БАЗЫ ДАННЫХ ПО УЧЁТУ ВИДЕОКАССЕТ
1.1 Основные понятия
1.2 Описание предметной области
1.3 Каталог задач и запросов базы
1.4 Описание сущностей
1.5 Описание атрибутов
1.6 Концептуальная модель
1.7 Описание связей
1.8 Итоги построения концептуальной модели
2. РЕЛЯЦИОННАЯ МОДЕЛЬ БАЗЫ ДАННЫХ "ОТДЕЛ СБЫТА ПРЕПРИЯТИЯ"
2.1 Основные понятия
2.2 Модель данных логического уровня
2.3 Построение реляционной модели
3. МАТЕМАТИЧЕСКОЕ ОПИСАНИЕ РЕЛЯЦИОННОЙ МОДЕЛИ БАЗЫ
ДАННЫХ "ОТДЕЛ СБЫТА ПРЕПРИЯТИЯ"
3.1 Описание доменов
3.2 Описание ключей
3.3 Правила целостности
3.4. Описание запросов
4. ВЫБОР ТЕХНИЧЕСКИХ СРЕДСТВ С ТОЧКИ ЗРЕНИЯ БАЗ ДАННЫХ
5. РЕАЛИЗАЦИЯ БД "ОТДЕЛ СБЫТА ПРЕПРИЯТИЯ"
6. РЕЗУЛЬТАТЫ РАБОТЫ БД " ОТДЕЛ СБЫТА ПРЕПРИЯТИЯ"
6.1 Приложение
6.2 Запросы
6.3 Отчеты
ЗАКЛЮЧЕНИЕ
СПИСОК ЛИТЕРАТУРЫ
ВВЕДЕНИЕ
В деловой или личной сфере часто приходится работать с данными из разных источников, каждый из которых связан с определенным видом деятельности. Для координации всех этих данных необходимы определенные знания и организационные навыки. Microsoft Access объединяет сведения из разных источников в одной реляционной базе данных. Создаваемые формы, запросы и отчеты позволяют быстро и эффективно обновлять данные, получать ответы на вопросы, осуществлять поиск нужных данных, анализировать данные и печатать отчеты. Система база данных в MSAccess представляет собой совокупность инструментов для ввода, хранения, просмотра, выборки и управления информацией. К этим средствам относятся таблицы, формы, отчеты, запросы. В MSAccess поддерживаются два способа создания базы данных. Вы можете создать пустую базу данных, а затем добавить в нее таблицы, формы, отчеты и другие объекты. Такой способ является наиболее гибким, но требует отдельного определения каждого элемента базы данных. Кроме этого имеется возможность создать с помощью мастера базу данных определенного типа со всеми необходимыми таблицами, формами и отчетами. Так как MSAccess содержит большой выбор подготовленных для вас баз данных, второй способ во многих случаях может оказаться предпочтительным. В обоих случаях у Вас останется возможность в любое время изменить и расширить созданную вами базу данных.
Система Access — это набор инструментов конечного пользователя для управления базами данных. В ее состав входят конструкторы таблиц, форм, запросов и отчетов. Эту систему можно рассматривать и как среду разработки приложений. Используя макросы или модули для автоматизации решения задач, можно создавать ориентированные на пользователя приложения такими же мощными, как и приложения, написанные непосредственно на языках программирования. При этом они будут включать кнопки, меню и диалоговые окна. Программируя на языке VBA, можно создавать такие мощные программы, как сама система Access.
Создание приложений без программирования с использованием макросов Access. Пользователи электронных таблиц и баз данных должны быть знакомы со многими ключевыми понятиями, используемыми в Access. Прежде чем приступить к работе с каким-либо программным продуктом, важно понять его возможности и типы задач, для решения которых он предназначен. MicrosoftAccess (далее — просто Access) — это многогранный продукт, использование которого ограничено только воображением пользователя.
В Access в полной мере реализовано управление реляционными базами данных. Система поддерживает первичные и внешние ключи и обеспечивает целостность данных на уровне ядра (что предотвращает несовместимые операции обновления или удаления данных). Кроме того, таблицы в Access снабжены средствами проверки допустимости данных, предотвращающими некорректный ввод вне зависимости от того, как он осуществляется, а каждое поле таблицы имеет свой формат и стандартные описания, что существенно облегчает ввод данных. Access поддерживает все необходимые типы полей, в том числе текстовый, числовой, счетчик, денежный, дата/время, MEMO, логический, гиперссылка и поля объектов OLE. Если в процессе специальной обработки в полях не оказывается никаких значений, система обеспечивает полную поддержку пустых значений.
1. КОНЦЕПТУАЛЬНАЯ МОДЕЛЬ БАЗЫ ДАННЫХ "ОТДЕЛ СБЫТА ПРЕПРИЯТИЯ"
1.1 Основные понятия
При разработке концептуальной модели мы будем пользоваться следующими понятиями:
Сущность
– личности, факты, объекты реального мира, имеющие отношение к некоторой проблемной области. /1,2/
Атрибут
– это информационное отображение свойств объекта. При реализации информационной модели на каком-либо носителе информации, атрибут часто называют элементом данных, полем данных или просто полем.
Экземпляр объекта
– это один набор значений его элементов данных.
Доменом
называется набор записей данных одного типа, отвечающих поставленным условиям.
Связь
– это функциональная зависимость между сущностями.
Концептуальная модель
представляет интегрированные концептуальные требования всех пользователей к базе данных данной предметной области.
Концептуальная схема
– это графическое представление данных на концептуальном уровне./2,3/
1.2 Описание предметной области
При проектировании концептуальной модели все усилия разработчика должны быть направлены в основном на структуризацию данных и выявление взаимосвязей между ними без рассмотрения особенностей реализации и вопросов эффективности обработки. Проектирование концептуальной модели основано на анализе решаемых на этом предприятии задач по обработке данных. Концептуальная модель включает описания объектов и их взаимосвязей, представляющих интерес в рассматриваемой предметной области и выявляемых в результате анализа данных. Имеются в виду данные, используемые как в уже разработанных прикладных программах, так и в тех, которые только будут реализованы./4,5/
Фирма, в которой будет эксплуатироваться данная база данных, занимается работой с заказчиками и поставщиками, т.е. ведется работа по приему заявок от заказчиков и их осуществление и заключением договоров на поставку товаров от поставщиков. В базе данных должно храниться полный перечень поставщиков и заказчиков с указанием всех требуемых адресов и телефонов, перечень ведется с момента создания фирмы. Также в базе данных должно храниться весь перечень товаров имеющихся на оптовой базе на данный момент, перечень товаров включенных в накладные и договора, список всех накладных и договоров заключенных ранее, должна иметься возможность добавление новых договоров и накладных. Также база должна хранить все счета оформленных в результате заключенных договоров и оформления накладных. Ограничение прав на доступ должно разделяться на пользователь и администратор. Пользователь должен иметь ограниченные права доступа, т.е. не иметь права корректировать, у администратора нет ограничений, кроме изменений структуры базы данных. /6/
Определим первоначальные данные:
Договора
- заключаются с поставщиками на определённый вид товара/7/.
Поставщики
- организации или физические лица, с которыми заключаются договора на поставку товара.
Заказчики
- в основном магазины, а также предприятия и организации, подающие заказ на приобретение того или иного товара.
Счета
- ведутся на этапе заключения договором с поставщиками, а также с заказчиками.
Накладные
- создаются на основании получения заказа о заказчика, для отгрузки.
Товар
- присутствует на основании заявки и договора с поставщиком.
1.3 Каталог задач и запросов базы
Основываясь на описании предметной области (п.1.2), а также путём опроса экспертов и изучения документальных источников,/8,9,10/ определим круг запросов и задач, которые предполагается решать с использованием базы данных "Отдел Сбыта Преприятия".
Задачи:
· сведения о поставщиках и заказчиках;
· сведения о накладных, договорах и счетах;
· сведения о товарах;
· возможность пополнять базу данных информацией новыми видами товара, накладных, договоров, список поставщиков, заказчиков и счетов;
· возможность при необходимости корректировать данные.
Вследствие большого объема информации хранящегося в базе данных пользователь должен иметь быстрый доступ к интересующим ему данным. Анализируя возможные запросы пользователя получаем такие запросы:
· по названию фирмы поставщика получение информации о всех заключенных договоров и счетов с этим поставщиком.
· по названию фирмы заказчика получение информации о всех полученных накладных от этого заказчика, также о всех оформленных счетах с этим заказчиком.
· по названию товара получение информации когда и в каких накладных и договорах участвовал этот товар.
· по номеру накладной или номеру договора получение полной информации о данном договоре или накладной.
1.4 Описание сущностей
Основываясь на описании предметной области (см.п.1.2) и определённых запросов и задач (см.п.1.3), выявляем сущности. Описание сущностей приведено в таблице (табл. 1.1).
Таблица 1.1
Наименование сущности |
Первичный ключ | Кол. экземпл. сущности | Динамика роста | Частота коррекции | Ограничение на доступ | |
| Администр | Пользователь | |||||
| Товар | Код товара | 3000 | 20% | Раз в месяц | Нет | Только чтение |
| Поставщик | Код поставщика | 10 | 5% | Раз в год | Нет | Только чтение |
| Заказчик | Код заказчика | 30 | 15% | Раз в 6 месяцев | Нет | Только чтение |
| Договор | Номер договора | 20 | 5% | Раз в месяц | Нет | Только чтение |
| Накладная | Номер накладной | 20 | 5% | Раз в месяц | Нет | Только чтение |
| Счет | Номер счета | 20 | 5% | Раз в месяц | Нет | Только чтение |
Описание сущностей
Количество экземпляров сущности – это количество известных разработчику на момент проектирования базы данных.При вычислении динамики роста оценивается отношение количества сущностей, на которое может увеличиться общее количество сущностей, к количеству сущностей.Частота коррекции содержит сведения о периодичности изменений количества сущностей.
1.5 Описание атрибутов
На основании таблицы сущностей (см.табл.1.1) и каталога задач и запросов (см.п.1.3), а также путём опроса экспертов и изучения документальных источников,/11,12/ выделим все необходимые атрибуты.
В таблице (табл.1.2) приводится описание атрибутов:
Таблица 1.2
Описание атрибутов
Наименование атрибута |
Тип Значения |
Диапазон Значений |
Возм-ть принимать неопределённые значения |
Метод контроля достоверности |
| 1 | 2 | 3 | 4 | 5 |
| Код товара | Числовой | Диапазон | Нет | <0 And >=100000 |
| Наименование | Текстовый | - | Нет | <=60 симв |
| Вес брутто (гр) | Числовой | Диапазон | Нет | <0 |
| Вес нетто (гр) | Числовой | Диапазон | Нет | <0 |
| Цена за единицу | Денежный | - | Нет | <0 |
| Вид упаковки | Текстовой | - | Нет | <=20 симв |
| Номер договора | Числовой | Диапазон | Нет | <0 And <=10000000 |
| Дата | Датавремя | Диапазон | Нет | [1..31],[1..12], [1996..2025] |
| Сумма | Денежный | - | Нет | <0 |
| Код заказчика | Числовой | Диапазон | Нет | <0 And <=10000000 |
| Наименование заказчика | Текстовый | - | Нет | <=60 симв |
| ФИО руководителя | Текстовый | - | Нет | <=60 симв |
| Адрес | Текстовый | - | Нет | <=80 симв |
| ТелФакс | Текстовый | - | Нет | <=40 симв |
| Номер накладной | Числовой | - | Нет | <0 And <=10000000 |
| Дата накладной | Датавремя | Диапазон | Нет | [1..31],[1..12], [1996..2025] |
| Сумма по накл | Денежный | - | Нет | <0 |
| Код поставщика | Числовой | Диапазон | Нет | <0 And <=10000000 |
| Наименование поставщика | Текстовый | - | Нет | <=60 симв |
| ФИО Руководителя | Текстовый | - | Нет | <=60 симв |
| Адрес | Текстовый | - | Нет | <=80 симв |
| ТелФакс | Текстовый | - | Нет | <=40 симв |
| Номер счета | Числовой | Диапазон | Нет | <0 And <=10000000 |
| Дата | Датавремя | Диапазон | Нет | [1..31],[1..12], [1996..2025] |
| Сумма | Денежный | - | Нет | <0 |
| НДС | Денежный | - | Нет | <0 |
| Сумма к оплате | Денежный | - | Нет | <0 |
| Количество | Числовой | Диапазон | Нет | <0 And <=10000 |
Диапазоны значений определяются из анализа документов, так же как и ограничения на длину текста. Нужно также сказать, что для осуществления взаимосвязи между атрибутами-ключами различных связанных таблиц необходимо совпадение по типу данных и ограничению по длине строки. Эта проблема решается путём унификации всех сходных атрибутов-ключей.
1.6 Концептуальная модель
На рис. 1.1 представлена графическая схема концептуальной модели определением всех связей и первичных ключей.
рис. 1.1
Графическое представление концептуальное модели наглядно поясняет предметную область.
1.7 Описание связей
1. Многие ко многим. Один поставщик поставляет много товара и одно
наименование товара может поставлять много поставщиков.
2. Один ко многим. Один поставщик может заключить много договор на
поставку товара с оптовой базой и в одном договоре может участвовать
только один поставщик
3. Один ко многим. С одним поставщиком может заключаться много счетов и
определенный счет может быть только у одного поставщика.
4. Многие ко многим. В одной накладной много товара и одно наименование
товара может быть во многих накладных.
5. Один ко многим. В одной накладной может быть несколько счетов.
6. Один ко многим. Заказчик создает много накладных.
7. Многие ко многим. В одном договоре много товара и одно наименование товара может встречаться в нескольких договорах.
8. Многие ко многим. Один заказчик заказывает партию товара и одно наименование товара может быть заказано многими заказчиками.
9. Один ко многим. С одним заказчиком может заключаться много счетов и только каждый счет соответствует одному заказчику.
10. Один ко многим. Счет создается на партию товара.
11. Один к одному. Договор может содержать только один счет.
1.8 Итоги построения концептуальной модели
В концептуальной модели мы смогли выделить из всей предметной области набор сущностей и установить связи между ними. Для каждой сущности определили первичный ключ и атрибуты.
2. РЕЛЯЦИОННАЯ МОДЕЛЬ БАЗЫ ДАННЫХ
2.1 Выбор логической модели
Хранимые в базе данные имеют определённую логическую структуру, то есть модель. Различают следующие основные модели представления данных в базе данных:
- иерархическую
- сетевую
- реляционную
- объектно-ориентированную
В иерархической модели данные представляются в виде древовидной иерархической структуры./3/ Достоинством данной модели является возможность реализовать очень быстрый поиск, когда условия запроса соответствуют иерархии в схеме БД, однако при работе с данными со сложными логическими связями иерархическая модель оказывается слишком громоздкой.
В сетевой модели данные организуются в виде произвольного графа./4/ Достоинством этой модели является высокая скорость поиска и возможность адекватно представлять данные для решения множества задач в самых различных предметных областях. Высокая скорость поиска основывается на классическом способе реализации сетевой модели - на основе списков. Недостатком сетевой модели является жесткость структуры и высокая сложность ее организации.
Кроме того, существенным недостатком иерархической и сетевой моделей является то, что структура данных задается на этапе проектирования БД и не может быть изменена при организации доступа к данным.
Реляционная модель получила свое название от английского термина relation (отношение) и была предложена в 1970-х годах сотрудником фирмы IBM Эдгаром Коддом. Реляционная БД представляет собой совокупность таблиц, связанных отношениями. Разница между таблицей в привычном смысле и понятием отношения заключается в том, что в отношении нет порядка - это неупорядоченное множество записей. Порядок определяется не отношением, а конкретной выборкой из отношения. Связь между таблицами существует на логическом уровне и определяется предметной областью. Практически связь между таблицами устанавливается путем использования логически связанных данных в разных таблицах.
Для работы с реляционными СУБД используется стандартизированный язык структурированных запросов SQL.
Достоинствами реляционной модели данных являются простота, гибкость структуры, удобство реализации на компьютере, высокая стандартизованность и использование математического аппарата реляционной алгебры и реляционного исчисления.
К недостаткам можно отнести атомарность, ограниченность и предопределенность набора возможных типов данных. Это затрудняет использование реляционных моделей для некоторых современных приложений. Названная проблема решается расширением реляционных моделей в объектно-реляционные.
В объектно-реляционной модели отдельные записи база данных представляются в виде объектов. Между записями базы данных и функциями их обработки устанавливаются взаимосвязи с помощью механизмов, подобных соответствующим средствам в объектно-ориентированных языках программирования. Объектно-ориентированные модели сочетают особенности сетевой и реляционной моделей и используются для создания крупных БД со сложными структурами данных.
Перейти к иерархической модели данных сложно, ввиду сложности реализации сложных связей через древовидные структуры (хотя реализация части сущностей и связей иерархии (см.п.1.6) через данную логическую модель достаточно просто). Гораздо больше подходит сетевая модель данных, однако мы выбираем реляционную модель, потому что
· представление данных в виде двухмерных таблиц проще, чем виде списков;
· большинство современных СУБД поддерживают реляционную модель данных, что облегчает нам выбор СУБД;
· реляционная модель проста, обладает гибкой структурой, удобна для реализации на компьютере.
Выбор объектно-реляционной модели решил бы проблемы с реализацией связей, однако возникли бы неоправданные проблемы с созданием математического представления и выбором СУБД./4/ Принимая во внимание всё вышесказанное, делаем выбор – реляционная модель данных.
2.2 Основные понятия
Реляционная модель данных – это представление данных в виде совокупности двумерных таблиц./4/
Свойства двумерных таблиц:
1) каждый элемент таблицы представляет собой один элемент данных, т.е. список не может быть значением;
2) все столбцы в таблице однородные, т.е. элементы столбца одной природы;
3) столбцам однозначно присвоены имена;
4) в таблице нет двух одинаковых строк;
5) строки и столбцы таблиц могут просматриваться в любом порядке, без учета их содержания и смысла.
Для математического описания реляционной модели нам понадобятся следующие понятия
Атомарные данные – это наименьшие единицы данных неразложимые с точки зрения модели.
Домен – это множество атомарных значений одного и того же типа.
Атрибут – это некоторое подмножество домена, имеющее уникальное имя.
Отношение на доменах D1
, D2
, ..Dn
состоит из заголовка и тела.
R (A1
, A2
, ..An
) ÍD1
´D2
´D3
Заголовок состоит из такого фиксированного множества атрибутов
А1
, A2,
..An
, что существует отношение между атрибутами и их доменами.
Тело состоит из меняющихся во времени множества кортежей.
Кортеж состоит из значений каждого атрибута по одному значению на атрибут./6/
Таблица в реляционной теории соответствует отношению.
Строке соответствует кортеж.
Столбцу – атрибут.
Введем понятие ключа отношения.
Пусть А – множество атрибутов отношения
А = {A1
, A2
,..An
} и пусть k – это подмножество А
kÍA
Возможным ключом отношения R является такое подмножество k, которое удовлетворяет следующему условию:
1) в произвольный момент времени никакие два различных картежа не имеют одного и того же значения для k
2) ни один из атрибутов не может быть исключен из k без нарушения первого условия.
2.3 Проектирование реляционной модели
Существует два основных метода проектирования реляционной модели:
1. метод декомпозиции (используется при количестве ключевых атрибутов не более 20);
2. на основе концептуальной модели.
Так как концептуальная модель уже построена, то воспользуемся вторым методом. Для осуществления перехода к реляционной модели необходимо рассмотреть некоторые алгоритмы перехода.
Алгоритмы перехода от концептуальной модели к реляционной
1. Реализация частичной связи для одной сущности (рис.2.1).
Рис 2.1
В этом случае строится два отношения по одному на каждую сущность. Ключ сущности с необязательной связью добавляется в качестве атрибута в отношении для сущности с обязательной связью.
2. Реализация бинарной связи один-ко-многим (рис.2.2)
Рис.2.2
В этом случае строится 2 отношения, при этом ключ односвязной сущности добавляется в отношение для многосвязной сущности.
По описанным выше алгоритмам получаем реляционную модель. В полученной модели есть ряд фиктивных отношений, предназначенных для реализации некоторых связей, организации целостности данных и выполнимости запросов (см.п.1.3).
3. МАТЕМАТИЧЕСКОЕ ОПИСАНИЕ РЕЛЯЦИОННОЙ МОДЕЛИ
3.1 Описание доменов
Математическое описание реляционной модели необходимо для облегчения пользователю задачи написания программ ее реализации на разных языках программирования.
Домен – это множество атомарных значений одного и того же типа.
Введем следующие понятия:
Length(x) – функция, возвращающая значение длины x;
String(x) – функция определения длины строки х;
Dom(x) – домен атрибута х;
По результатам описания сущностей (см.п.1.4) и созданной реляционной модели (см.п.2.3), можно сделать вывод о типичности отношений, что позволяет нам не описывать все отношения, а остановиться на конкретных примерах.
Текстовые атрибуты
К таким атрибутам можно отнести, например, атрибуты "Наименование заказчика" или "Адрес" и подобные им.
Dom (Отношение. Текстовый атрибут) = {x | String(x)}; где x – цепочка следующих друг за другом символов.
{String(x) = true, если Length(x) < С} or {String(x) = false, если Length(x) ³С},
где С-константа.
Её можно взять из таблицы атрибутов (см.табл.1.2). Приведём два примера.
1. Dom (Заказчики. Наименование заказчика) = {x | String(x)};
где x – цепочка следующих друг за другом символов.
{String(x) = true, если Length(x) < 20} or {String(x) = false, если Length(x) ³ 20}
2. Dom (Поставщики. Адрес) = {x | String(x)}; где x – цепочка следующих друг за другом символов.
{String(x) = true, если Length(x) < 20} or {String(x) = false, если Length(x) ³ 20}
Это правило распространяется на все текстовые атрибуты. Отличие заключается в ограничение на длину строки. Конкретную цифру получаем из таблицы атрибутов в столбце "Метод контроля" (см.табл.1.2).
Числовые атрибуты
К этой категории относят атрибуты отношений, например "Код поставщика", "Цена", "Количество" и т.д. Домены числовых атрибутов записываются так:
Dom (Отношение. Числовой атрибут) = {с1..с2}, где с1 и с2 – соответственно начало и конец диапазона.
Например,
Dom (Заказчики. Код заказчика) = {0…10000}.
Диапазон значений {с1..с2} определяется для каждого атрибута описан в таблице атрибутов в столбце "Метод контроля" (см.табл.1.2).
Атрибуты Дата/Время
К этой категории относят атрибуты "Дата накладной", "Дата оформления счета", "Дата договора" и т.д.
Домены атрибутов Дата/Время записываются так:
Dom (Отношение. Атрибут Дата/Время) = {с1..с2},
где с1 и с2 – соответственно начало и конец диапазона.
Приведём примеры с атрибутами "Дата накладной", "Дата оформления счета"
Dom (Накладная. Дата накладной) = {x | 01.01.1996 £x£ 31.12.2025}
Dom (Счет. Дата оформления счета) = {x | 01.01.1996 £x£ 31.12.2025}
Диапазон значений {с1..с2} определяется для каждого атрибута описан в таблице атрибутов в столбце "Метод контроля" (см.табл.1.2).
Денежный атрибут
К этой категории относят атрибуты "Сумма", "Цена за единицу", "НДС".
Домены Денежных атрибутов записываются так:
Dom(Отношение. Денежный атрибут) = {<C}
где С – константа
Приведем примеры с атрибутами "Сумма" и "Цена за единицу"
Dom (Накладная. Сумма) = {<0}
Dom (Договор. Цена за единицу) = {<0}
Значения для каждого атрибута взяты из Таблицы 1.2. столбца "Метод контроля"
3.2 Описание ключей
Первичный ключ уникально определяет отношение. После выбора первичного ключа из набора потенциальных ключей, оставшиеся ключи называются альтернативными.
Пусть даны отношения R1
и R2
. Пусть k1
, - это первичный ключ отношения R1
.
Если в отношении R2
присутствуют атрибуты k1
, то для отношения R2
, k1
– это внешний ключ
Рассмотрим математическое представление первичных ключей.
Из анализа таблицы сущностей (см.табл.1.1) следует, что ключами сущностей является Код товара, Код заказчика, Код поставщика, Номер договора, Номер накладной, Номер счета. Так как все первичные ключи имеют числовые атрибуты. Следовательно, математическое представление первичных ключей будет однотипным:
("x,yÎ Отношение).[Код(x) = Код(y)]®x = y
("x,yÎ Отношение).[Номер(x) = Номер(y)]®x = y.
Например,
("x,yÎТовар).[Код товара(x) = Код товара(y)]®x = y
("x,yÎНакладная).[Номер накладной(x) = Номер накладной(y)]®x =y
Остальные первичные ключи будут иметь такое же математическое представление.
3.3 Правила целостности
Различают целостность по сущностям и целостность по ссылкам. В целостности по сущностям не разрешается, чтобы какой-либо атрибут, участвующий в первичном ключе базового отношения принимал неопределенные значения./6/
Базовые отношения – это реально существующие модели отношения, которые соответствуют реальному объекту предметной области.
Целостность по ссылкам основана на понятии внешнего ключа.
Пусть даны отношения R1
и R2
. Пусть k1
, - это первичный ключ отношения R1
.
Если в отношении R2
присутствуют атрибуты k1
, то для отношения R2
, k1
– это внешний ключ. Если базовое отношение R2
содержит внешний ключ k1
, то каждое значение k1
в R2
должно быть либо равным какому-либо значению R1
, либо полностью неопределенным.
Рассмотрим математическое представление целостности данных.
1. Целостность по сущностям имеет место, так как первичные ключи всех отношений не принимаю и не могут принимать неопределённые значения (см.табл.1.2).
2. Целостность по ссылкам достигнута при разработке реляционной модели (см.п.2.3). В качестве примера рассмотрим математическое представление целостности по ссылкам отношения Накладная (для отношений Договор и Счет аналогично (см.2.3)), отношение Заказчик(для отношения Поставщик аналогично).
Отношение Накладная
Одна и та же Накладная не может быть оформлена в разные даты.
("x,yÎ Накладная).[Дата оформления(x) = Дата оформления(y)]®(Дата оформления(x) ¹ Дата оформления (y))
Одна и та же Накладная не может иметь разные номера.
("x,yÎ Накладная).[Номер накладной(x) = Номер накладной(y)]®(Номер накладной (x) ¹ Номер накладной (y))
Одна и та же Накладная не может иметь разную сумму.
("x,yÎ Накладная).[Сумма накладной(x) = Сумма накладной(y)]®(Сумма накладной (x) ¹Сумма накладной (y))
Отношение Заказчик
Один и тот же Заказчик не может иметь разные наименования.
("x,yÎ Заказчик).[Наименование заказчик(x) = Наименование заказчик (y)]®
( Наименование заказчик (x) ¹ Наименование заказчик (y))
Отношение Счет
Один и тот же Счет не может иметь разные даты:
("x,yÎ Счет).[Дата оформления(x) = Дата оформления(y)]®(Дата оформления(x) ¹ Дата оформления (y))
Один и тот же Счет не может иметь разную сумму.
("x,yÎ Счет).[Сумма(x) = Сумма(y)]®(Сумма(x) ¹ Сумма(y))
Один и тот же Счет не может иметь разные номера.
("x,yÎ Счет).[Номер счета(x) = Номер счета(y)]®(Номер счета (x) ¹ Номер счета (y))
3.4 Описание запросов
Для описания запросов необходимо рассмотреть специальную реляционную операцию реляционной алгебры селекция. Пусть С-любой допустимый оператор сравнения. Дано отношение R (А1
, А2
, А3
, … , Аn
). Селекцией отношения R по атрибутам Аj
и Аk
называется множество всех кортежей t таких, что аjt
Cаkt
– истина. Вместо аkt
может быть константа.
S (R, <условие>) – операция селекции.
Опишем определённые запросы (см.п.1.2).
Первый запрос реализуется через группу однотипных запросов. Например,S (Номер договора, Дата, Сумма, Номер счета, Дата, Сумма = x),
где x – это число, соответствующих коду поставщика.
Второй запрос реализуется аналогично первому.
Третий запрос реализуется через серию однотипных запросов. Например,
S (Номер договора, количество, цена за единицу, дата, номер накладной, количество, цена за единицу, дата =x),
где х – число соответствующие коду товара.
Четвертый запрос реализуется через серию однотипных запросов. Например,
S (Дата, количество, цена за единицу, наименование товара=х),
где х – число соответствующий номеру договора или счета.
4. ВЫБОР ТЕХНИЧЕСКИХ СРЕДСТВ С ТОЧКИ ЗРЕНИЯ БАЗ ДАННЫХ
Исходя из полученной реляционной (см.п.2.3) и её математического описания делаем выбор технических средств.
Выбираем платформу, на которой будет решаться задача. В соответствии с поставленной задачей, техническим заданием к курсовому проекту и учитывая экономичные требования, выбираем платформу IBMPC.
Выбор среды проектирования.
Так как поставленная задача должна быть решена в комплексе с передачей информации в другие системы, выбираем готовый программный продукт со встроенным языком программирования, поддержкой необходимого набора типов данных, работающую на платформе IBMPC, имеющую визуальные средства разработки и обеспечивающий защиту информации. Кроме того, выбор в качестве логической модели – реляционной модели заставляет нас искать СУБД с наиболее простой реализацией двухмерных таблиц и связей между ними. В данном случае выбираем систему Ассess 2000 c встроенным языком программирования SQL - StructuredQueryLanguage.
Описание типов данных системы Access 2000, которые будут использоваться в базе данных "Отдел Сбыта Преприятия" представлены в табл.4.1.
Таблица 4.1
Используемые типы данных Access 2000
| Значение | Тип данных | Размер |
| Текстовый | Текст или числа, не требующие проведения расчетов, например номера телефонов. | Число знаков, не превышающее минимальное из двух значений: 255. Microsoft Access не сохраняет пробелы в неиспользуемой части поля. |
| Числовой | Числовые данные, используемые для проведения расчетов | 1, 2, 4 или 8 байт |
| Дата/время | Даты и время, относящиеся к годам с 100 по 9999. | 8 байт |
| Денежный | Используется для записи денежных форматов | 2,4 или 8 байт |
Выбор ОС.
ОС выбираем исходя из выбранной платформы и программного продукта в котором мы решаем поставленную задачу проектирования. Учитываем также, чтобы ОС была современной, устойчиво работала и обеспечивала максимум удобства. В связи с выше перечисленными требованиями выбираем WindowsXP.
Выбор материнской платы.
Выбор материнской платы включает в себя выбор центрального процессора, шины обмена и объема оперативной памяти. Быстро действие центрального процессора выбирается так, чтобы время ожидания расчетной задачи или обновления экрана по возможности не превышало трёх секунд. Таким образом, выбираем Celeron 400МГц. Материнскую плату выбираем так, чтобы она обеспечивала максимальную скорость обмена информацией. Объем оперативной памяти высчитывается по формуле:
V = Vос
+ Vут
+ Vср.пр
. + Vдоп
,
где V - объем оперативной памяти;
Vос
- объем операционной системы;
Vут
- объем оперативных утилит;
Vср.пр
- объем среды проектирования;
Vдоп
- дополнительный объем под решаемую задач.
V=128Мб+20Мб+12Мб+10Мб=170Мб.
Таким образом, для компьютера Celeron 400МГц выбираем объём ОП равный 256 Мб.
Выбор основных периферийных устройств.
Основные периферийные устройства это - устройства отображения информации (монитор), устройства хранения информации (винчестер), устройства обмена информацией (локальная сеть, дискета, оптические накопители).
Монитор должен отвечать требованиям безопасности, иметь экономичную стоимость и желательно высокую разрешающую способность. Исходя из требований высокой частоты обмена и по экономическим требованиям, выбираем 15ти дюймовый CRT-монитор.
Винчестер выбираем по трем параметрам: объем необходимый под ОС, объем памяти под программу, объем памяти под результаты работы.
Vв=Vос + Vпр + Vут,
где Vв – объем винчестера;
Vос – объем под ОС;
Vпр – объем памяти под программу MicrosoftAccess2000;
Vут – объем памяти под результаты работы. Определяется по табл.4.1.
Vв=1,5Гб+46Мб+20Мб=1622Мб.
Таким образом, для компьютера Celeron 400МГц, с ОП 256Мб винчестер на 20Гб, что устраивает для нашей задачи.
Устройства обмена.
Для обмена информацией могут быть использованы: локальная сеть, дискета, оптические накопители.
Исходя из того, что необходимо вести архивы выбираем оптический пишущий накопитель, так как объём Vв больше объёма дискеты выбираем CDRW.
Дополнительное периферийное оборудование.
К дополнительным периферийным устройствам относят: устройство ввода информации, устройство получения твердых копий.
Для ввода информации необходимо и достаточно стандартного комплекта – клавиатуры и мышки.
5.РЕАЛИЗАЦИЯ
На основе созданной концептуальной (см.п.1.7), реляционной модели (см.п.2.3) и её математического описания (см.п.3), используя выбранное оборудование (см.п.4), создаём в СУБД MicrosoftAccess таблицы и ключи.. На рис.5.1 представлены созданные таблицы.
рис 5.1
После создания таблиц, связываем их в единую схему данных используя средства Access 2000 в соответствие с описанием связей, см.п.1.6 и см.п.2.3. Полученная схема данных представлена на рис.5.2
В соответствии с каталогом задач и запросов (см. п. 1.3), были реализованы требуемые запросы (рис. 5.3).
рис 5.2
рис 5.3
Для организации диалога с пользователем была создана систем форм, представленная на рис.5.4. Интерфейс форм реализован с учётом специфики предметной области (см.п.1.2).
рис 5.4
Для реализации прав доступа был использован мастер защиты. Были созданы два типа пользователей – Администратор и Пользователь со своими правами доступа. Администратор обладает полным доступом, за исключением изменения структуры базы данных. Пользователь обладает ограниченным доступом. Вход под именем Администратор защищён паролем. При открытии базы данных открывается окно, показанное на рис.5.6
Рис.5.6
В случаи не правильного ввода пароля под администратором вход в базу данных будет запрещен.
6. РЕЗУЛЬТАТЫ РАБОТЫ БД " ОТДЕЛ СБЫТА ПРЕПРИЯТИЯ"
6.1 Приложение
В результате реализации реляционной модели на физическом уровне мы получаем систему форм, которая позволяет пользователю получать необходимые сведения согласно задачам и запросам (см.п.1.3). Рис.6.1 демонстрирует главную форму.
рис 6.1
Форма предоставляет возможность просматривать интересующие пользователя данные. Интуитивный интерфейс поможет пользователю не запутаться в огромном потоке данных. Форма разделена на отдельные закладки помогающие быстрой навигации.
Вызывая соответствующие формы пользователь может осуществлять быструю работу с данными, например на рис 6.2 представлена форма для отображения счетов поставщиков.
рис 6.2
На главной форме также предусмотрена вкладка "Приложение" в которой пользователь может запустить необходимые для работы офисные приложения.
рис 6.3
Для быстроты и удобства работы с документами предусмотрена вкладка "Документы" представлена на рис 6.4
рис 6.4
рис 6.5
6.2 Запросы
Первый запрос
Описание запроса на языке SQL
SELECT Заказчики.[наименование заказчика], Заказчики.[ФИО руководителя], Заказчики.адрес, Заказчики.[телефофакс], [Заказчики и накладные].[Номер накладной], [Заказчики и накладные].[Дата заключения], Накладные.Сумма
FROM Накладные INNERJOIN (Заказчики INNERJOIN [Заказчики и накладные] ON Заказчики.[код заказчика] = [Заказчики и накладные].[Код заказчика]) ON Накладные.[номер накладной] = [Заказчики и накладные].[Номер накладной]
WHERE (((Заказчики.[наименование заказчика])=[Заказчик]));
Представлении запроса в СУБД MicrosoftAccess 2000
рис 6.6
Второй запрос имеет практически такую же реализацию как и первый, поэтому описывать его не будем.
Третий запрос
Описание запроса на языке SQL
SELECT Товары.Наименование, Товары.[вес брутто (гр)], Товары.[вес нетто (гр)], Товары.[цена за еденицу], Товары.[вид упаковки], [Товары в договоре].[Номер договора], [Товары в договоре].Количество AS [Товары в договоре_Количество], [Товары в накладной].[Номер накладной], [Товары в накладной].Количество AS [Товары в накладной_Количество]
FROM (Товары INNERJOIN [Товары в накладной] ON Товары.[код товара] = [Товары в накладной].[Код товара]) INNERJOIN [Товары в договоре] ON Товары.[код товара] = [Товары в договоре].[Код товара]
WHERE (((Товары.Наименование)=[Товар]));
рис 6.7
Четвертый запрос реализуется так же как третий поэтому описывать его не будем.
6.3 Отчеты
Приведем несколько примеров отчетов сформированных в результате выполнения курсовой работе.
Первый отчет
рис 6.8
Второй отчет
рис 6.9
ЗАКЛЮЧЕНИЕ
В результате проделанной работы по описанию предметной области мы разработали концептуальную модель, а на её основе реляционную модель по которой создали в СУБД MicrosoftAccess приложение. Разработанное приложение отвечает всем требованиям предметной области (см.п.1.2), а так же каталогу задач и запросов (см.п.1.3). Все поставленные задачи в техническом задании были выполнены полностью. База данных "Отдел Сбыта Преприятия" предназначена для частных фирм и крупных организаций занимающихся торгово – закупочной деятельностью.
Данная база данных и приложение были разработаны с целью облегчить работу с большим количеством и долгосрочном хранении информации в этих организациях. В дальнейшим планируется расширить круг задач реализуемых с помощью данного приложения, также планируется добавление поиска по остальным категориям. Было реализовано деление пользователей на Специалистов и Пользователей по правам доступа.
СПИСОК ЛИТЕРАТУРЫ
1. Дж. Тельман, "Основы систем баз данных", Москва, Финансы и статистика, 1983г.
2. Дейт К. "Введение в системы баз данных", Москва, Hаука, 1980 г.
3. Горев А. Ахаян Р., Макашарипов С. "Эффективная работа с СУБД" СПб. Питер 1997— 704 с.
4. Кириллов В.В. Структуризованный язык запросов (SQL). – СПб.: ИТМО, 1994. – 80 с.
5. Мейер М. Теория реляционных баз данных. М. Мир, 1987. – 608 с.
6. Ноздрева Р.Б., Цыгичко Л.И. Маркетинг: "Как побеждать на рынке" М.
ФиС 1991
7. Т.В. Тимошок "Самоучитель MicrosoftAccess 2003"
8. М.Ю. Горский "Организация и управление бизнесом", Москва 1998г.
9. Нефедов В.Н., Осипова В.А. Курс дискретной математики – М. 1992
10. Интернет – ресурс www.nix.ru
11. Интернет – ресурс www.lizard.ru
12. Интернет – ресурс www.library/buhg.ru