Разработка концептуальной схемы реляционной базы данных "Продажа керамической плитки"

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

Задание

на курсовой проект

по дисциплине "Базы данных и системы управления базами данных"

Разработать автоматизированную информационную систему на основе СУБД Access 2000.

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

В процессе защиты курсового проекта работа системы должна быть продемонстрирована на компьютере.

Ниже приведен рекомендуемый перечень основных разделов пояснительной записки.

1.Характеристика АИС.

Описание предметной области. Назначение и пользователи АИС. Возможные запросы к системе. Задачи, решаемые системой. Ведение БД.

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

Типы объектов и свойства объектов. Ограничения, наложенные на данные. Анализ связей между объектами. Экземпляры объектов. Модель данных.

3.Разработка реляционной модели данных.

Основные понятия реляционной модели. Отношения БД и атрибуты отношений. Ключи отношений. Установление связей между отношениями. Нормализация отношений. Уменьшение объема хранимых данных. Новые ключи отношений и схема БД. Фрагмент текущего состояния БД.

4.Запросы к БД и процедуры обработки данных.

5.БД информационной системы.

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

6. Интерфейс пользователя-непрограммиста. Интерфейс администратора БД.

Исполнитель

Руководитель проекта

Срок сдачи проекта

Рекомендуемая литература

Харитонова И. Самоучитель Access 2000. СПб.: Питер, 2001.

Робинсон С.Microsoft Access 2000:Учебный курс. СПб.: Питер, 2002.

Трофимова И.П., Сосулин Ю.А. Создание баз данных Access. Рязань, РГРТА, 2003.

Вейскас Дж. Эффективная работа с Microsoft Access 97. - СПб: ЗАО "Издательство "Питер", 1999.

Пасько В. Access 97. К.: Издательская группа BHV, 2000

Содержание

1. Характеристики автоматизированной информационной системы

1.1 Описание предметной области

1.2 Назначение системы и пользователей

1.3 Возможные запросы к системе

1.4 Задачи, решаемые системой

1.5 Задачи ведения базы данных

2. Логическое проектирование базы данных (БД)

2.1 Типы объектов и свойства объектов

2.2 Ограничения, накладываемые на данные

2.3 Анализ связей между объектами предметной области

2.4 Экземпляры объектов Плитка

2.5 Модель данных

3. Разработка реляционной модели данных

3.1 Основные понятия реляционной модели

3.2 Отношения базы данных и атрибуты отношений

3.3 Ключи отношений

3.4 Установление связей между отношениями

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

3.6 Устранение избыточности и объема данных

3.7 Фрагмент текущего состояния БД

4. Запросы к базе данных и процедуры обработки данных

5. БД информационной системы

5.1 Структура и содержание таблиц БД

5.2 Схема БД

5.3 Запросы к БД: формирование запросов, бланки запросов в режиме конструктора, результаты выполнения запросов

5.4 Формы БД: назначение каждой из форм, источник данных, внешний вид формы, назначение кнопок формы

5.5 Назначение, источник данных и структура других объектов БД (отчеты, макросов)

6. Интерфейс пользователя-непрограммиста. Интерфейс администратора БД

Заключение

1. Характеристики автоматизированной информационной системы

1.1 Описание предметной области

Фирма «Керамик Стиль» закупает керамическую плитку у поставщиков и продает ее физическим лицам (клиентам). Каждому клиенту предоставлена информация по любому интересующему его наименованию плитки: коллекция, назначение, тип плитки, описание, и ее фабрик-производителей.

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

Наша фирма регистрирует каждый заказ, при этом фиксируются такие сведения как: Ф.И.О. клиента, коллекция, дата заказа, дату отгрузки, кол-во заказанной плитки в единицах измерения. Так же регистрируются все поставки плитки на фирму, при этом фиксируется фирма поставщик, коллекция, кол-во плитки в единицах измерения, цена по которой плитка поставлена на склад, дата производства и дата поставки. Также следует отметить, что цена, по которой плитка продается, отличается от цены, по которой эти плитка была поставлена на фирму на величину НДС(18%) и процента накрутки фирмой, который составляет 30%.

Договором фиксируются обязательства сторон, то есть фирма обязуется поставить заказанное кол-во плитки в установленный срок (он составляет 14 дней с момента заказа - подписания договора купли-продажи), в противном случае «Керамик Стиль» выплачивает неустойку клиенту в размере 3% за каждый просроченный день, а клиент в свою очередь обязан произвести оплату в полном объеме за сделанный им заказ не позднее одного дня после факта отгрузки товара.

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

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

Следует отметить, что фирма «Керамик Стиль» имеет свой склад, на котором хранится плитка до момента отгрузки ее клиенту.

1.2 Назначение системы и пользователей

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

1.3 Возможные запросы к системе

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

К примеру, в системе возможны запросы следующего характера:

- узнать исчерпывающую информацию о заказе клиента;

- поиск по названию фирмы-поставщика информации о поставках, ею произведенных;

- поиск по фамилии клиента информации о его заказах;

- определение количества заказов у клиента и поставок у поставщика;

- определение дней просрочек и расчет соответствующей неустойки;

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

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

1.4 Задачи, решаемые системой

Приложение базы данных должно решать следующие задачи:

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

ь вести учет клиентов и всей информации о них;

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

ь списывать бракованную плитку со склада фирмы;

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

ь рассчитывать объем продаж и определять доход фирмы;

ь осуществлять контроль за отгрузкой заказанного товара клиентам;

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

ь ведение архива заказов, данные в котором хранятся до того момента, пока сам пользователь(Администратор) не посчитает нужным их удалить из него.

1.5 Задачи ведения базы данных

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

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

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

Необходимо, чтобы база данных обеспечивала удаление:

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

- сведений о заказах и поставках.

Необходимо обеспечивать добавление:

- сведений о новых клиентах

- сведений впервые включенной в ассортимент плитки

- сведений о новых поставщиках.

2. Логическое проектирование базы данных (БД)

2.1 Типы объектов и свойства объектов

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

Объекты имеющиеся в базе, характеризуется следующими свойствами:

ПЛИТКА (Код коллекции, Коллекция, Назначение, Тип плитки, Описание, Цена поставки/ед. изм.);

КЛИЕНТЫ (Код клиента, Ф.И.О. клиента, Город, Телефон);

ПОСТАВЩИКИ (Код поставщика, Контактное лицо, Фирма-поставщик, Город, Телефон);

ПРОИЗВОДИТЕЛИ КОНФЕТ (Код производителя, Название фабрики-производителя, Страна).

Опишем свойства объектов:

ПЛИТКА:

Код коллекция - уникальный номер, присваиваемый каждому наименованию плитки

Коллекция - название плитки с указанием её размеров и толщины (калибра)

Назначение - место выбора плитки в соответствии с помещением (ванная, кухня, комната)

Тип плитки - место предназначения плитки (настенная, напольная, декор, бордюр, вставки и т.д.)

Описание - краткое описание данной коллекции плитки

Цена поставки - цена, по которой поставляется данное наименование плитки на склад фирмы «Керамик Стиль»

КЛИЕНТЫ:

Код клиента - уникальный номер, присваиваемый каждому клиенту

Ф.И.О. клиента - фамилия, имя, отчество клиента

Город - место нахождения клиента

Телефон - контактный номер телефона клиента

ПОСТАВЩИКИ:

Код поставщика - уникальный номер, присваиваемый каждому поставщику

Фирма-поставщик - название фирмы-поставщика

Город - место нахождения фирмы-поставщика

Телефон - городской номер телефона фирмы-поставщика

Контактное лицо - лицо представитель фирмы-поставщика

ПРОИЗВОДИТЕЛИ КОНФЕТ:

Код производителя - уникальный номер, присваиваемый каждому производителю конфет

Фирма-производитель - название фабрики - производителя

Страна - страна фирмы-производителя

2.2 Ограничения, накладываемые на данные

При разработке базы данных очень сложно абсолютно реально отразить предметную область и поэтому возникает необходимость принятия следующих ограничений:

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

2. Клиент, обратившийся на фирму может, сделать одновременно заказ на наименование только одной коллекции.

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

4. Дата отгрузки клиенту ставится по факту отгрузки.

5. Оплата ведется по факту отгрузки.

6. Нельзя регистрировать двух и более клиентов с одинаковыми Ф.И.О..

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

8. Невозможно, чтобы названия фирм-производителей совпадали (были одинаковыми).

2.3 Анализ связей между объектами предметной области

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

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

- одну коллекцию может производить многие производители, а один производитель может произвести много коллекций, следовательно, между объектами КОЛЛЕКЦИИ и ПРОИЗВОДИТЕЛИ ПЛИТКИ существует связь М:М

- одну и ту же коллекцию могут купить многие клиенты, а один клиент может приобрести многие коллекции, следовательно, между объектами КОЛЛЕКЦИИ и КЛИЕНТЫ связь М:М (коллекции связаны с клиентами через заказы)

- одну и ту же коллекцию могут поставить многие поставщики, а один поставщик может поставить много коллекций, следовательно, между объектами КОЛЛЕКЦИИ и ПОСТАВЩИКИ связь М:М (коллекции связаны с поставщиками через поставки)

2.4 Экземпляры объектов Плитка

Клиенты

Поставщики

Производители плитки

2.5 Модель данных

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

3. Разработка реляционной модели данных

3.1 Основные понятия реляционной модели

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

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

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

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

- все элементы столбца имеют одинаковый тип данных;

- столбцам присвоены уникальные имена;

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

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

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

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

Связи между таблицами бывают трех типов: «один к одному», «один ко многим» и «многие ко многим». Если мы составляем список сотрудников, то отношение между конкретным сотрудником и его адресом - «один к одному». А название лаборатории по отношению к списку сотрудников - «один ко многим», так как в одной лаборатории работает много (больше одного) сотрудников. А если сопоставить список преподавателей какого-либо вуза со списком учебных дисциплин, которые в этом вузе преподаются, придется использовать связь типа «многие ко многим»: одну дисциплину могут преподавать разные преподаватели, и в то же время один преподаватель может читать разные дисциплины. При организации связи типа «один ко многим» таблицу «один» принято называть главной, а таблицу «многие» - подчиненной. Ключ главной таблицы называют первичным, а подчиненной - внешним.

Любую таблицу реляционной базы данных можно назвать отношением, так как в таблицах с данными также реализованы связи между атрибутами записей типа «один к одному».

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

СУБД позволяет выполнять следующие операции с данными (записями):

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

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

- удаление записей;

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

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

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

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

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

3.2 Отношения базы данных и атрибуты отношений

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

В соответствии с разработанной логической структурой данных в модели БД «Продажа керамической плитки» будут определены четыре отношения:

- отношение ПЛИТКА содержит атрибуты: Коллекция, Назначение, Тип плитки, Описание, Цена поставки/ед. изм.;

- отношение КЛИЕНТЫ содержит атрибуты: Ф.И.О. клиента, Город, Телефон;

- отношение ПРОИЗВОДИТЕЛИ ПЛИТКИ содержит атрибуты: Фабрика-производитель, Страна изготовитель;

- отношение ПОСТАВЩИКИ содержит атрибуты: Фирма-поставщик, Город, Телефон.

3.3 Ключи отношений

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

В отношении КОЛЛЕКЦИЯ первичным ключом является Код коллекции, в отношении ПРОИЗВОДИТЕЛИ ПЛИТКИ - название Фирмы-производителя, в отношении КЛИЕНТЫ первичный ключ - Ф.И.О. клиента, в отношении ПОСТАВЩИКИ - Фирма-поставщик.

3.4 Установление связей между отношениями

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

Для установления связей М:М между отношениями ПЛИТКА и ПРОИЗВОДИТЕЛИ ПЛИТКИ, создадим новое отношение, которое называется ПЛИТ_ПРОИЗВ, в нем должны быть первичные ключи связываемых отношений. В предметной области связь между этими объектами характеризуется определенными свойствами - это наименование коллекции и фабрика-производитель. Поэтому в связующее отношение ПЛИТ_ПРОИЗВ помимо ключевого атрибута добавим два дополнительных атрибута - Наименование коллекции и Фабрика-производитель. Получим:



Внешним ключом отношений ПЛИТКА и ПЛИТ_ПРОИЗВ является атрибут Наименование коллекции, а внешним ключом отношений ПЛИТ_ПРОИЗВ и ПРОИЗВОДИТЕЛИ ПЛИТКИ является атрибут Фабрика-производитель.

Для установления связей М:М между отношениями ПЛИТКА и КЛИЕНТЫ, создадим новое отношение, которое называется ЗАКАЗЫ, в нем должны быть первичные ключи связываемых отношений. В предметной области связь между этими объектами характеризуется определенными свойствами - это количество/Един. Изм. заказанной плитки, дата заказа и дата отгрузки. Поэтому в связующее отношение ЗАКАЗЫ помимо ключевых атрибутов добавим три дополнительных атрибута - Количество/Един. Изм., ЕД. Изм., Дата заказа и Дата отгрузки. Получим:

Внешним ключом отношений ПЛИТКА И ЗАКАЗЫ является атрибут Коллекция, а внешним ключом отношений КЛИЕНТЫ и ЗАКАЗЫ является атрибут Ф.И.О. клиента. Для установления связей М:М между отношениями ПЛИТКА и ПОСТАВЩИКИ, создадим новое отношение, которое называется ПОСТАВКА ПЛИТКИ, в нем должны быть первичные ключи связываемых отношений. В предметной области связь между этими объектами характеризуется определенными свойствами - это поставленное количество плитки (в ед. изм.), дата производства плитки и дата поставки. Поэтому в связующее отношение ПОСТАВКА ПЛИТКИ помимо ключевых атрибутов добавим три дополнительных атрибута - Поставленное количество/ЕД. Изм., Дата производства и Дата поставки. Получим:

Внешним ключом отношений ПЛИТКА и ПОСТАВКА ПЛИТКИ является атрибут Коллекция, а внешним ключом отношений ПОСТАВЩИКИ и ПОСТАВКА ПЛИТКИ является атрибут Фабрика-поставщик.

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

Все отношения реляционной модели данных должны быть нормализованы. Считается, что отношения находятся в первой нормальной форме, если значение каждого его атрибута неструктурированно, т.е. на пересечении каждой строки и каждого столбца должно находится одно единственное значение. Рассмотренные отношения находятся в первой нормальной форме (1НФ), значение каждого атрибута не структурировано.

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

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

Проанализируем отношение КЛИЕНТЫ:

Ф.И.О. клиента

клиент Город

Код города

Телефон

Значение атрибута Код города функционально полно зависит от атрибута Город, т.е. для того чтобы узнать код города не надо знать Ф.И.О. клиента, достаточно знать лишь название города. Отношение КЛИЕНТЫ разделим на два отношения:

КЛИЕНТЫ (Ф.И.О. клиента, Город, Телефон)

и ЗВОНИТЬ (Город, Код города).

Проанализируем отношение ПОСТАВЩИКИ:

Город

Фирма-поставщик Телефон

Код города

Значение атрибута Код города функционально полно зависит от атрибута Город. Отношение Поставщики разделим на два отношения:

ПОСТАВЩИКИ (Фирма-поставщик, Город, Телефон)

и ЗВОНИТЬ (Город, Код города).



Теперь модель данных состоит из 8 отношений: ПЛИТКА, КЛИЕНТЫ, ЗАКАЗЫ, ПОСТАВЩИКИ, ПОСТАВКИ ПЛИТКИ, ПРОИЗВОДИТЕЛИ ПЛИТКИ, ПЛИТК_ПРОИЗВ, ЗВОНИТЬ.

3.6 Устранение избыточности и объема данных

Объем хранимых данных можно уменьшить, если пронумеровать строки в таблицах. Получим следующие таблицы:

1) ПЛИТКА (Код коллекции, Назначение плитки, Тип плитки, Описание, ЕД. Изм., Цена поставки/ед. изм.);

2) КЛИЕНТЫ (Код клиента, Ф.И.О. клиента, Город, Телефон);

3) ПОСТАВЩИКИ (Код поставщика, Фирма-поставщик, Город, Телефон);

4) ПРОИЗВОДИТЕЛИ ПЛИТКИ (Код производителя, Фирма-производитель, Город);

5) ПЛИТ_ПРОИЗВ (Код произв_плитки, Код коллекции, Код производителя);

6) ПОСТАВКА ПЛИТКИ (Код поставки, Код поставщика, Код коллекции, Поставленное количество/ЕД. Изм., Дата производства, Дата поставки);

7) ЗАКАЗЫ (Код заказа, Код клиента, Код плитки, Количество/ЕД. Изм., Дата заказа, Дата отгрузки);

8) ЗВОНИТЬ (Город, Код города).

3.7 Фрагмент текущего состояния БД

Приведем таблицы после всех модификаций.

Плитка

Клиенты

Производители плитки

Поставщики

Заказы

Поставки плитки

Плит_Произв

Звонить

4. Запросы к базе данных и процедуры обработки данных

Разработанная система должна обеспечивать возможные поиски информации по запросам пользователей, для примера приведем несколько запросов:

Запрос 1.

Узнать номер телефона Брынцалова Александра Васильевича.

Мы получим ответ на этот запрос, если из таблицы КЛИЕНТЫ выделим строку, содержащую сведения о клиенте Брынцалове Александре Васильевиче.

Это можно сделать, выполнив операцию сцепления отношения КЛИЕНТЫ с известной из запроса константой Брынцалова Александра Васильевича, то есть, выполнив операцию сцепления отношения с одноэлементным множеством.

КЛИЕНТЫ*{ФИОКлиента*{Брынцалов Александр Васильевич} [ФИОКлиента, Телефон]}

Процедуры обработки данных.

Рассмотрим, как выполняется отбор данных, нужных для решения поставленных задач и какие операции следует над ними выполнить, чтобы решить задачу:

1. Определим количество заказов каждого клиента.

Для ответа на поставленный вопрос в таблице ЗАКАЗЫ выполним операцию проекции на [КодКлиента] сделав группировку по КодКлиента с определением значения поля Count(КодКлиента) в поле Кол-во заказов.

5. БД информационной системы

5.1 Структура и содержание таблиц БД

1. Таблица «Плитка» хранит информацию о плитках, такую как коллекцию плитки, назначение, тип плитки, описание, единицы измерения, цена поставки/ед. изм.. Таблица содержит 7 полей:

2. Таблица «Клиенты» хранит информацию о ФИОклиентов, их контактных телефонах и месте нахождения- городе. Таблица содержит 4 поля:

3.Таблица «Поставщики» хранит информацию о фирме-поставщике, городе, в котором она находится, его контактном телефоне и его контактном лице. Таблица содержит 5 полей:



4. Таблица «Производители конфет» хранит информацию о фабрике-производителе и стране, в которой она находится. Таблица содержит 3 поля:

5. Таблица «Заказы» хранит информацию о клиенте и сделанном им заказе, который включает в себя: коллекцию плитки, количестве/ед. изм., ЕД. Изм., дату заказа и дату отгрузки. Таблица содержит 7 полей.

6. Таблица «Поставки плитки» хранит информацию о поставщике и его поставках на фирму, включающую в себя: коллекцию плитки, количестве/ед. изм, ЕД. Изм, дату производства, а также дату поставки. Таблица содержит 7 полей.

7. Таблица «Звонить» хранит информацию о названии города и его коде. И содержит 2 поля.

8. Таблица «Плит_Произв» выступает связующей таблицей между «Плитка» и «Производители» и содержит информацию о коллекции и фабрике-производителе.

9. Таблица «Списание» предназначена для хранения информации о плитке, которая пришла бракованная или битая, и содержит 4 поля.

10. Таблица «Архив заказов» используется, для того чтобы не загружать основную таблицу заказов устаревшими данными, т.е. заказами которые были заключены давно. Записи имеют структуру и типы данных, соответствующие определению таблиц Заказы и Клиенты.

5.2 Схема БД

продажа плитка база данные

5.3 Запросы к БД: формирование запросов, бланки запросов в режиме конструктора, результаты выполнения запросов

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

Так как в нашей БД реализовано множество запросов, приведем к рассмотрению только некоторые основные из них, так как остальные запросы подобны этим.

Запрос : «Данные о поставках»

Подсчитывает стоимость произведенных поставок по каждому поставщику по дате поставки



Запрос: «Поиск заказа по дате»

Позволяет найти определенный заказ со всеми его параметрами по его дате.

Запрос «Итоги по поставкам»

Позволяет определить стоимость поставленной плитки по дате поставок за месяц.

Запрос «Доход». Вычисляет доход фирмы по каждому месяцу.

Запрос на удаление «Удаление устаревших заказов».

5.4 Формы БД: назначение каждой из форм, источник данных, внешний вид формы, назначение кнопок формы

Формы являются наиболее важными объектами в Microsoft Access, потому что в основном через них осуществляется взаимодействие пользователей с БД. Через формы можно загружать данные в таблицы, просматривать и корректировать их. Работая с формой, пользователь может добавлять и удалять записи в таблицах, изменять значения в полях, получать расчетные данные. В форме можно контролировать вводимые данные, устанавливать ограничения на доступ к информации, выводить необходимые сообщения. Источником данных для создания форм являются таблицы или запросы.

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

Во всех формах БД используются следующие кнопки:

или используется для добавления новых записей;

при нажатии сохраняет запись, внесенные изменения;

удаляет запись;

при помощи этих кнопок осуществляется переход, соответственно, к первой, предыдущей, следующей и последней записям;

печать;

выходит, закрывает;

открывается окно поиска и замены.

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

После нажатия кнопки «Вход в систему» откроется окно «Ввод пароля»

Если пароль неверный, открывается окно: «Неверный пароль!!!»

При нажатии кнопки «Ок» это окно закроется. Если пароль был введен верно, то после нажатия по кнопке «Ок» первого диалогового окна открывается форма выбора пользователей: администратор и пользователь.

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



1. Кнопка «Клиенты» открывает форму, содержащую данные обо всех клиентах фирмы.

При помощи этой формы можно отредактировать любые данные о клиенте, найти клиента по фирме-клиенту. При нажатии на кнопку «Новый город» открывается форма, в которую нужно добавить новый город, которого еще нет в раскрывающемся списке поля «Город» на предыдущей форме, и его телефонный код.

2. При нажатии на кнопку «Заказы» открывается форма для просмотра и редактирования сведений о клиентах и их заказах. На этой форме можно также оформить договор купли-продажи, в котором возможен просмотр перечня заказа, просмотреть неотгруженные заказы, воспользоваться поисковыми кнопками «Найти клиента» и «Поиск по дате заказа».

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

4. Кнопка «Отчеты» открывает форму для выбора той информации (отчетов), которая интересует администратора:

Соответственно можно просмотреть:

5. Кнопка «Списание» открывает форму для просмотра и добавления (списания) бракованной или битой плитки.

6. Кнопка «Архив» открывает форму «Работа с архивом»

Нажатие кнопки «Открыть»…

Остальные кнопки «Смена пользователя» и «Выход» совершают соответствующие действия.

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

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

При нажатии кнопки «Выход» на форме «Смена пользователя»

Появляется форма «Выйти из системы».

5.5 Назначение, источник данных и структура других объектов БД (отчеты, макросов)

Отчёты.

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

В данной БД представлено 4 отчёта:

1.«Доход фирмы»

Данный отчет, отображает информацию о доходах фирмы по месяцам.

2. «Количество заказов клиента» отображает клиентов с количествами заказов. Отчет основан на использовании запроса «Количество заказов клиента».

3. «Лучшие клиенты» показывает клиентов стоимости заказов которых превышает 100.000р. основан на запросе «Лучший клиент».

4. «Прайс-плитки» выводит всю исчерпывающую информацию по наименованию плитки, всех её характеристиках и цене. Источником данных для отчета является запрос «Запрос для прайса»

Макросы.

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

Например макрос «Пароль»

«Открыть Новые_Производители»

Остальные макросы выглядят аналогично.

6. Интерфейс пользователя-непрограммиста. Интерфейс администратора БД

Интерфейс пользователя-непрограммиста и интерфейс администратора БД значительно отличаются друг от друга. Пользователь-непрограммист не имеет доступа к структуре элементов БД: таблицам, запросам, формам, макросам, отчётам. Возможности пользователя-непрограммиста при работе с БД ограничиваются выполнением тех функций, которые доступны при работе с формами БД в режиме формы. Администратор БД имеет доступ к структуре различных элементов БД и может ее менять, Настройки интерфейса пользователя-непрограммиста формируются в меню «Параметры запуска». Для игнорирования этих настроек администратор должен удерживать Нажатой клавишу «Shift» при запуске БД.

Заключение

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

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