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

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

Создание базы данных магазина мобильных телефонов

ВВЕДЕНИЕ

база данных учет

В настоящее время все труднее встретить человека, не имеющего мобильного телефона. В 21 веке развитие мобильной связи достигло огромных размеров. На 97 % территории Украины доступна мобильная связь. Последние 10-15 лет рынок мобильных телефонов развивается очень стремительно, потому что мобильной связью пользуются люди всех возрастов: от школьников до пенсионеров. Жизнь в современном мире диктует свои правила, и необходимость иметь мобильный телефон ни у кого не вызывает сомнений. Сотовые телефоны предоставляют мобильность связи, актуальность полученной информации. Благодаря этому полезному устройству появляется возможность всегда быть в курсе событий, находиться рядом с близкими для Вас людьми, увеличить успешность трудовой деятельности. Кроме того, новинки мобильных телефонов способны предоставить большое количество развлекательного контента. Разнообразные полезные приложения, игры, просмотр видео и прослушивание аудио записей не дадут заскучать в дороге и помогут скрасить досуг.

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

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

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

В качестве СУБД для курсового проектирования была выбрана реляционная локальная файл-серверная СУБД Microsoft Access 2010.

1. ОПИСАНИЕ ФУНКЦИОНИРОВАНИЯ МАГАЗИНА МОБИЛЬНЫХ ТЕЛЕФОНОВ

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

Например, потенциальный клиент Семён Петрович пришел в магазин «Звонилочка» чтобы посмотреть телефон Apple iPhone 4S и уточнить его характеристики. Менеджер Артем Тесленко сказал, что это смартфон на платформе iOS 5, который имеет сенсорный экран с поддержкой мультитач. Разрешение экрана 640x960px. Камера 8 МП, вес: 140 г, ШхВхТ: 58.6x115.2x9.3 мм. Цена этого смартфона 9000 грн.

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

Например, Клиент Дмитрий Волков определился с покупкой и попросил её оформить. Менеджер Мироненко Юлия создала новую запись в базе с номером 18547 и спросила у господина Волкова, не хочет ли он стать участником дисконтной программы. Дмитрий согласился и предоставил Юлии своё ФИО, адрес и телефон. Так как это его первая покупка, то он получил скидку 3%.

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

Например, в магазине закончились мобильные телефоны Samsung Galaxy Gio. Менеджер связывается с поставщиками, заказывает 10 новых SG Gio по цене 1100 грн. за штуку. Сделав наценку 35%, на витрину эти телефоны попадут по цене 1485 грн.

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

2. ПОСТАНОВКА ЗАДАЧИ

2.1 Общие определения

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

- информация о продаваемых моделях телефонов;

- информация о сотрудниках, работающих в магазине;

- информация обо всех совершенных продажах;

- информация о клиентах (ФИО, адрес, контактный телефон);

- информация о поставщиках и поставках.

2.2 Цель и задачи разработки

Целью данного курсового проекта является создание базы данных «Магазин мобильных телефонов» в СУБД Microsoft Access.

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

2.3 Постановка задачи разработки программного продукта

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

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

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

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

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

- контроль целостности и сохранности данных, а также достоверности хранимой информации.

3. КОНЦЕПТУАЛЬНОЕ ПРОЕКТИРОВАНИЕ СИСТЕМЫ

Концептуальное проектирование системы состоит из двух частей: концептуальное моделирование и представление концептуальной модели в терминах модели данных определенной СУБД.

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

При разработке концептуальной модели, прежде всего, следует определить объекты. С этой целью нужно сделать следующее:

- необходимо понять, какая информация должна храниться и обрабатываться и можно ли это определить как объект;

- присвоить этому объекту имя;

- выявить свойства объекта и присвоить им имя;

- определить уникальный идентификатор объекта.

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

- то, как экземпляр одного объекта связан с экземпляром другого объекта;

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

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

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

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

Инфологическое моделирование сводится к ряду этапов, представленных ниже.

3.1.1 Построение диаграммы потоков данных

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

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

Рисунок 3.1 - Начальная контекстная диаграмма

В таблице 3.1 приведено соответствие потоков данных между начальной контекстной диаграммой и контекстной диаграммой первого уровня.

Таблица 3.1 - Соответствие потоков данных на диаграммах

Потоки на диаграмме верхнего уровня	Потоки на диаграмме нулевого уровня
Информация от клиента	Данные о клиентеё сделать заказ.
Информация для клиента	Получить заказ.
Информация от сотрудника	Информация о сотрудниках, запрос на скидку, заказ новых телефонов, запрос на создание заказа.
Информация для сотрудника	Ответ на запрос о создании заказа, ответ на запрос о новых телефонах.
Информация от поставщика	Данные о телефоне, данные о поставщике, запрос новых заказов.
Информация для поставщика	Ответ на запрос о новых заказах.

На рисунке 3.2 приведена контекстная диаграмма первого уровня. На приведенной DFD диаграмме накопитель данных «магазин» является глобальным или абстрактным представлением хранилища данных.

Рисунок 3.2 -Контекстная диаграмма первого уровня

3.1.2 Построение диаграммы «сущность-связь»

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

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

Диаграммы "сущность-связь" включают:

- сущности;

- атрибуты;

- связи.

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

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

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

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

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

Основными объектами предметной области являются клиент, сотрудник, телефон, поставщик и производитель.

Телефон имеет свойства: Объем аккумулятора, цвет, % наценки, модель, форм-фактор, тип камеры, операционная система, тип дисплея, характеристики дисплея, тип телефона, размер, вес, срок гарантии.

Телефон изготавливается производителем. Производитель имеет свойства: название и страна. Между телефоном и производителем отношение 1…? т.к. один производитель изготавливает множество телефонов.

Телефон продается сотрудником. Сотрудник имеет свойства: ФИО, телефон. Между телефоном и сотрудником отношение ?…? т.к. один сотрудник может продать множество телефонов, а одна модель телефона может быть продана несколькими сотрудниками. Такое отношение также имеет свойства: дата продажи, %скидки, IMEI проданного телефона.

Телефон покупается клиентом. Клиент имеет свойства: ФИО, адрес, телефон. Между телефоном и клиентом отношение ?…?, т.к. множество один клиент может купить много телефонов, а одна модель телефона может быть продана разным клиентам.

Сотрудник обслуживает клиента. Между клиентом и сотрудником отношение ?…? т.к. один сотрудник может обслужить множество клиентов, а один клиент может быть обслужен разными сотрудниками.

Телефон поставляется поставщиком. Поставщик имеет свойства: название, адрес, страна, город, телефон. Между телефоном и поставщиком связь ?…?, т.к. одна модель телефона может быть поставлена несколькими поставщиками, а один поставщик может поставить много моделей телефонов. Такое отношение имеет свойства: дата поставки, количество.

Схема, изображённая на рисунке 3.3, наглядно показывает взаимодействия объектов.



Рисунок 3.3 - Схема «Объект-отношение»

3.2 Выбор модели представления данных

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

3.2.1 Иерархическая модель данных

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

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

Достоинства иерархической модели данных:

1) высокое быстродействие;

2) эффективное использование памяти - задачи.

Недостатки иерархической модели:

1) медленный доступ к сегментам данных нижних уровней иерархии;

2) отсутствует механизм поддержки связи между элементами разных поддеревьев;

3) четкая ориентация на определенные типы запросов;

4) доступ к данным производится только через корневое отношение от предка к потомку (в одну сторону).

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

Иерархическая модель данных изображена на рисунках 3.4 - 3.7.

Рисунок 3.4 - Первый фрагмент иерархической модели данных



Рисунок 3.5 - Второй фрагмент иерархической модели данных

Рисунок 3.6 - Третий фрагмент иерархической модели данных

Рисунок 3.7 - Четвертый фрагмент иерархической модели данных

3.2.2 Сетевая модель данных

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

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

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

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

Достоинства сетевой модели данных:

1)эффективное использование памяти;

2) произвольность связей;

3) высокое быстродействие.

Недостатки сетевой модели данных:

1) сложность доступа к элементам (навигационный принцип доступа);

2) сложно отследить смысл такой модели данных.

Сетевая модель данных изображена на рисунке 3.8.

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

Рисунок 3.8 - Сетевая модель данных

3.2.3 Реляционная модель данных

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

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

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

- все столбцы в таблице однородные, т.е. все элементы в столбце имеют одинаковый тип (числовой, символьный и т.д.) и длину;

- каждый столбец имеет уникальное имя;

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

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

Таблица такого рода называется отношением.

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

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

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

Достоинства реляционной модели:

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

2) при проектировании реляционной БД применяются строгие правила, базирующие на математическом аппарате;

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

Недостатки реляционной модели:

1) относительно низкая скорость доступа и большой объем внешней памяти;

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

3) далеко не всегда предметную область можно представить в виде совокупности таблиц.

В последнее время всё большее количество БД основываются на РМ в виду её простоты и удобства, а также большого количества программных продуктов для разработки этой СУБД. И даже недостатки реляционной модели компенсируются ростом быстродействия и ресурсов памяти современных ЭВМ.

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

В результате перехода от схемы «Объект-отношение» к реляционной модели данных были выделены 5 таблиц, соответствующие объектам на этой схеме, 5 справочных таблиц и 2 таблицы для реализации отношения ?…?.

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

Таблица «Сотрудники». Соответствует объекту «Сотрудник» на схеме «Объект-отношение». Состоит из 3 полей: ID сотрудника (первичный ключ), ФИО (С60), телефон (С13). Связана с таблицей «Продажи» связью 1…? при помощи первичного ключа.

Таблица «Клиенты». Соответствует объекту «Клиент» на схеме «Объект-отношение». Состоит из 5 полей: ID клиента (первичный ключ), ФИО (С60), телефон (С13), адрес (С100). Связана с таблицей «Продажи» связью 1…? при помощи первичного ключа.

Таблица «Продажи». Появилась в результате преобразования отношения «Продается» на схеме «Объект-отношение». Состоит из 8 полей: № накладной (первичный ключ), ID телефона(N5 - внешний ключ для связи с таблицей «Телефоны»), дата продажи (D10/T5), Скидка (N3), IMEI (N15), ID клиента (N7 - внешний ключ для связи с таблицей «Клиенты»), ID сотрудника (N3 -внешний ключ для связи с таблицей «Сотрудники»), всего к оплате (N8). Связана с таблицей «Телефоны» связью 1…? при помощи первичного ключа, с таблицей «Сотрудники» связью 1…? при помощи внешнего ключа «ID сотрудника» и с таблицей «Клиенты» связью 1…? при помощи внешнего ключа ID Клиента.

Таблица «Телефоны». Соответствует объекту «Телефон» на схеме «Объект-отношение». Состоит из 14 полей: ID телефона (первичный ключ), Модель(С30), ID форм-фактора (N1 -внешний ключ для подстановки данных из справочной таблицы «Форм-фактор), % наценки (N3), Цвет (С15), Тип камеры (С10), ID ОС (N2 -внешний ключ для связи со справочной таблицей «ОС»), ID типа дисплея (N1 -внешний ключ для связи со справочной таблицей «Тип дисплея»), Характеристики дисплея (С50), ID типа телефона (N1 -внешний ключ для связи со справочной таблицей «Тип телефона»),Размер (С16), вес (N3), гарантия (N2), ID производителя (N2 -внешний ключ для связи с таблицей «Производители»). Связана с таблицей «Продажи» связью 1…? при помощи первичного ключа, с таблицей «Поставки» связью 1…? при помощи первичного ключа, и со справочными таблицами «Форм-фактор», «ОС», «Тип дисплея» и «Тип телефона» связями 1…? соответствующими внешними ключами.

Таблица «Производители». Соответствует объекту «Производитель» на схеме «Объект-отношение». Состоит из 3 полей: ID производителя (первичный ключ), название (С60), ID страны (N3 - внешний ключ для связи с таблицей «Страны»). Связана с таблицей «Телефоны» связью 1…? при помощи первичного ключа и со справочной таблицей «Страны» связью 1…? при помощи внешнего ключа ID страны.

Таблица «Поставщики». Соответствует объекту «Поставщик» на схеме «Объект-отношение». Состоит из 6 полей: ID Поставщика (первичный ключ), Название (С60), телефон (С13), адрес (С100), город (С20), ID страны (N3 -внешний ключ для связи со справочной таблицей «Страны»). Связана с таблицей «Поставки» связью 1…? при помощи первичного ключа и со справочной таблицей «Страны» связью 1…? при помощи внешнего ключа ID страны.

Таблица «Поставки». Появилась в результате преобразования отношения «Поставляется» на схеме «Объект-отношение». Состоит из 6 полей: ID Поставки (первичный ключ), ID поставщика (N3 - внешний ключ для связи c таблицей «Поставщики»), ID телефонa (N5 - внешний ключ для связи с таблицей «Телефоны»), Дата поставки (D10), Цена (С8), Количество(N3). Связана с таблицей «Поставщики» связью ?…1 при помощи внешнего ключа ID поставщика и с таблицей «Телефоны» связью ?…1 при помощи внешнего ключа ID Телефона.

Реляционная модель данных представлена на рисунке 3.8.

Рисунок 3.8 - Реляционная модель данных

3.3 Нормализация таблиц

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

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

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

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

IMEI

модель

форм-фактор

ОС

Цвет

объем аккумулятора

% наценки

Разрешение камеры

Тип дисплея

Характеристики дисплея

Тип телефона

Размер

Вес

Гарантия

Название производителя

Страна произв.

ФИО сотрудника

Телефон сотрудника

Дата продажи

Скидка %

ФИО клиента

Адрес клиента

Телефон клиента

Уровень дисконта %

Дата поставки

Количество шт.

Цена

Название поставщика

Город поставщика

Страна поставщика

Адрес поставщика

Телефон поставщика

Рисунок 3.9 - Отношение в первой нормальной форме

Таблица находится во второй нормальной форме (2НФ), если она удовлетворяет определению 1НФ и все ее поля, не входящие в первичный ключ, связаны полной функциональной зависимостью с первичным ключом.

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



Рисунок 3.10 - Диаграмма функциональных зависимостей (2НФ)

Спроектированная БД нормализована до третей нормальной формы (3НФ). Так как, по определению, если БД находится в третьей нормальной форме, то она находится и в первой и во второй нормальных формах.

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

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

Рисунок 3.11 - Диаграмма функциональных зависимостей (3НФ)

4. ПРОГРАММНАЯ РЕАЛИЗАЦИЯ СИСТЕМЫ

4.1 Обоснование выбора СУБД

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

Для реализации этой задачи была выбрана реляционная модель данных.

В качестве СУБД рассматривались несколько вариантов, с которыми был знаком разработчик. Среди них Oracle Database, Microsoft SQL Server и Microsoft Access. Oracle и MS SQL Server были отвергнуты по причине высокой сложности разработки. К тому же разрабатываемый программный продукт не требует всего функционала, предоставляемого данными СУБД.

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

4.2 Описание таблиц

При создании таблиц для БД на основе реляционной модели между ними установлены связи 1…?. Во всех связях присутствует обеспечение целостности данных. Каскадное удаление обеспечено между таблицами «Сотрудники»-«Продажи», «Телефоны»-«Продажи», «Производители»-«Телефоны», «Поставщики»-«Поставки». Между всеми таблицами обеспечено каскадное обновление данных. Схема данных для разрабатываемой БД представлена на рисунке 4.1.

Справочная таблица «Форм-фактор». (Рисунок 4.2)

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

НазваниеФФ - название форм-фактора, размер 20 символов, тип текстовый, поле обязательное, индексированное без повторений.

Рисунок 4.2 - Справочная таблица «Форм-фактор»

Справочная таблица «ОС». (Рисунок 4.3)

Код - Код ОС, тип счетчик, первичный ключ, содержит уникальные значения без повторений.

НазваниеОС - название форм-фактора, размер 15 символов, тип текстовый, поле обязательное, индексированное без повторений.

Рисунок 4.3 - Справочная таблица «ОС»

Справочная таблица «Тип Дисплея». (Рисунок 4.4)

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

НазваниеТипаДисплея - название типа дисплея, размер 20 символов, тип текстовый, поле обязательное, индексированное без повторений.

Справочная таблица «Тип Телефона». (Рисунок 4.5)

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

НазваниеТипаТелфона - название типа телефона, размер 15 символов, тип текстовый, поле обязательное, индексированное без повторений.

Рисунок 4.4 - Справочная таблица «Тип дисплея»



Рисунок 4.5 - Справочная таблица «Тип Телефона»

Справочная таблица «Страны». (Рисунок 4.6)

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

НазваниеСтраны - название страны, размер 20 символов, тип текстовый, поле обязательное, индексированное без повторений.

Флаг - поле объекта OLE, хранит изображение флага страны, обязательный.

Рисунок 4.6 - Справочная таблица «Страны»

Таблица «Производители». (Рисунок 4.7)

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

НазваниеПроизводителя - название производителя, размер 20 символов, тип текстовый, поле обязательное, индексированное без повторений.

НазваниеСтраны - Код страны, числовое поле, подстановка из таблицы «Страны», связь по полю «КодСтраны», подпись «Страна», отображается поле «НазваниеСтраны» таблицы «Страны».

Логотип - поле объекта OLE, хранит изображение логотипа производителя, обязательный.

Рисунок 4.7 - Таблица «Производители»

Таблица «Сотрудники». (Рисунок 4.8)

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

ФИО - фамилия, имя и отчество сотрудника, размер 60 символов, тип текстовый, поле обязательное, индексированное с повторениями, т.к. у сотрудников могут быть абсолютно одинаковые ФИО.

Телефон - содержит номер телефона сотрудника, тип поля текстовый, для ввода используется маска "+"00\(000\)000\-00\-00;0; обязательное, неиндексированное.

Рисунок 4.8 - Таблица «Сотрудники»

Таблица «Клиенты». (Рисунок 4.9)

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

ФИО - фамилия, имя и отчество клиента, размер 60 символов, тип текстовый, поле обязательное, индексированное с повторениями, т.к. у клиентов могут быть абсолютно одинаковые ФИО.

Телефон - содержит номер телефона клиента, тип поля текстовый, для ввода используется маска "+38(0"00\)000\-00\-00;0; не обязательное, неиндексированное.

Адрес - содержит адрес клиента, размер 100 символов, тип текстовый, поле необязательное, не индексированное.

Рисунок 4.9 - Таблица «Клиенты»

Таблица «Поставщики». (Рисунок 4.10)

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

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

ТелефонПоставщика - содержит номер телефона поставщика, тип поля текстовый, для ввода используется маска "+"00\(000\)000\-00\-00;0; обязательное, неиндексированное.

АдресПоставщика - содержит адрес офиса поставщика, тип текстовый, размер 100 символов, поле обязательное, не индексированное.

ГородПоставщика - содержит город, в котором находится офис поставщика, тип текстовый, размер 20 символов, поле обязательное, индексированное с повторениями, т.к. разные поставщики могут находиться в одном городе.

НазваниеСтраны - Код страны, числовое поле, подстановка из таблицы «Страны», связь по полю «КодСтраны», подпись «Страна», отображается поле «НазваниеСтраны» таблицы «Страны».

Рисунок 4.10 - Таблица «Поставщики»

Таблица «Телефоны». (Рисунок 4.11)

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

Модель - название модели телефона, тип текстовый, размер 30 символов, поле обязательное, индексированное без повторений.

НазваниеПроизводителя - код производителя, числовое поле, подстановка из таблицы «Производители», связь по полю «КодПроизводителя», подпись «Производитель», отображается поле «НазваниеПроизводителя» таблицы «Производители».

IDФФ - код форм-фактора, числовое поле, подстановка из таблицы «Форм-фактор», связь по полю «КодФормФактора», подпись «Форм-Фактор», отображается поле «НазваниеФФ» таблицы «Форм-Фактор».

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

Цвет - цвет телефона, тип текстовый, размер 15 символов, поле не обязательное, не индексированное.

ТипКамеры - тип камеры телефона, тип текстовый, размер 10 символов, поле не обязательное, не индексированное.

НазваниеОС - код операционной системы, числовое поле, подстановка из таблицы «ОС», связь по полю «КодОС», подпись «ОС», отображается поле «НазваниеОС» таблицы «ОС».

НазваниеТипаДисплея - код типа дисплея, числовое поле, подстановка из таблицы «Тип Дисплея», связь по полю «КодТипаДисплея», подпись «Тип Дисплея», отображается поле «НазваниеТипаДисплея» таблицы «Тип Дисплея».

ХарактеристикиДисплея - содержит различные характеристики дисплея, как разрешение, диагональ и пр., тип текстовый, размер 25 символов, поле не обязательное, не индексированное, маска ввода 000" х "000" рх",\ 0\,0\';0;

НазваниеТипаТелефона - код типа телефона, числовое поле, подстановка из таблицы «Тип Телефона», связь по полю «КодТипаТелефона», подпись «Тип Телефона», отображается поле «НазваниеТипаТелефона» таблицы «Тип Телефона».

Размеры - содержит физические размеры телефона, тип поля текстовый, для ввода используется маска !#99.9" x "#99.9" x "#99.9;0;_ необязательное, неиндексированное.

Вес - вес телефона, тип числовой, размер 3 символа, поле не обязательное, не индексированное.

Рисунок 4.11 - Таблица «Телефоны»

Таблица «Поставки». (Рисунок 4.12)

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

КодПоставщика - код поставщика, числовое поле, подстановка из таблицы «Поставщики», связь по полю «КодПоставщика», подпись «Поставщик», отображается поле «НазваниеПоставщика» таблицы «Поставщики».

КодТелефона - код телефона, числовое поле, подстановка из таблицы «Телефоны», связь по полю «КодТелефона», подпись «Модель», отображается поле «НазваниеТелефона» таблицы «Телефоны».

ДатаПоставки - дата поставки, тип дата/время, имеет краткий формат даты, маска ввода 00.00.0000;0;_ условие на значение <=Now() (т.к. дата не может быть больше текущей), при неверном значении выводится сообщение об ошибке. Количество - количество телефонов в поставке, числовое поле, обязательное, не индексированное, условие на значение >0, при неверном вводе выводится сообщение об ошибке. НомерПоставки - номер поставки, числовое поле, обязательное, индексированное с совпадениями, маска ввода 00000.

Рисунок 4.12 - Таблица «Поставки»

Таблица «Продажи». (Рисунок 4.13)

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

КодТелефона - код телефона, числовое поле, подстановка из таблицы «Телефоны», связь по полю «КодТелефона», подпись «Модель», отображается поле «НазваниеТелефона» таблицы «Телефоны».

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

Скидка - содержит скидку на модель в процентах, тип поля числовой, значение по умолчанию - 0, условие на значение >=0, сообщение об ошибке «Скидка должна быть положительной», обязательное, не индексированное.

IMEI - серийный номер телефона, тип текстовый, маска ввода !00"-"000000"-"000000"-"09;, обязательное поле, не индексированное.

КодКлиента - код клиента, числовое поле, подстановка из таблицы «Клиенты», связь по полю «КодКлиента», подпись «Клиент», отображается поле «ФИОКлиент» таблицы «Клиенты», обязательное поле, индексированное с повторениями.

КодСотрудника - код сотрудника, числовое поле, подстановка из таблицы «Сотрудники», связь по полю «КодСотрудника», подпись «Продавец», отображается поле «ФИОСотрудника» таблицы «Сотрудники», обязательное поле, индексированное с повторениями.

Сумма - вычисляемлое поле. Сумма покупки с учетом скидки, числовое поле, двойное с плавающей точкой, обязательное, не индексированное, условие на значение >0, при неверном вводе выводится сообщение об ошибке. Формат поля # ##0,00" грн.". Получает значение из формы «Добавить покупку». Рассчитывается по формуле Me.Сумма = Me.цена_Телефоны - (Me.цена_Телефоны * (Me.Скидка / 100)).



Рисунок 4.13 - Таблица «Продажи»

Таблица «users». (Рисунок 4.14)

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

КодСотрудника - код сотрудника, числовое поле, подстановка из таблицы «Сотрудники», связь по полю «КодСотрудника», подпись «Продавец», отображается поле «ФИОСотрудника» таблицы «Сотрудники», обязательное поле, индексированное с повторениями.

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

pass - пароль пользователь, размер 32 символа, тип текстовый, поле обязательное, неиндексированное, маска ввода «Пароль».

group - группа, к которой принадлежит пользователь, тип числовой, размер 1 символ, обязательное, не индексированное.

Рисунок 4.14 - Таблица «users»

4.3 Проектирование пользовательского интерфейса

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

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

4.3.1 Уровни доступа к БД

Для предотвращения изменения структуры БД в системе предусмотрено разграничение уровней доступа. Системой будут пользоваться 2 типа пользователей: администратор и сотрудник.

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

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

Остальные элементы интерфейса доступны в полной мере как сотруднику так и администратору БД.

4.3.2 Модель пользовательского интерфейса

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

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

4.4 Описание функционирования приложения

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

Форма «Авторизация» предназначена для авторизации пользователя для доступа к базе данных (администратор, менеджер). Внешний вид формы представлен на рисунке 4.15.

Кнопка «ОК на форме служит для проверки введенного пароля. Пароль храниться на форме в текстовом поле, не доступном для отображения пользователю и сверяется с таблицей “users” при помощи модуля (Приложение В.1). При совпадении пароля с текстовым полем открывается форма «Главное окно», с теми элементами интерфейса, которые соответствуют группе вошедшего пользователя. В случае несовпадения паролей выдается сообщение «Неверный пароль», либо, если пользователь с таким логином не найден в базе, то будет выведено сообщение «Пользователь не найден». При нажатии кнопки «Отмена» происходить закрытие базы данных.

Рисунок 4.14 - Диаграмма последовательности форм

Рисунок 4.15 - Форма «Авторизация»

Форма «Главное окно» предназначена для навигации по всем формам в БД. Внешний вид формы представлен на рисунке 4.16.

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

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

Рисунок 4.16 - Форма «Главное окно»

Кнопка «Новая покупка» позволяет создать запись о покупке без начальной привязки к клиенту (например, если клиент еще не добавлен в базу). При вводе ФИО Клиента, отсутствующего в базе будет предложено создать такую запись.

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

На данной форме расположены такие кнопки:

- «Новый клиент» отображает пустые поля для добавления нового клиента.

- «Печать» используется для печати списка покупок текущего клиента. Список покупок является простым отчетом. Источник записей для данного отчета:

SELECT Клиенты.КодКлиента, Клиенты.ФИОКлиента, Клиенты.ТелефонКлиента, Клиенты.АдресКлиента, Продажи.КодНакладной, Продажи.МодельТелфона, Продажи.ДатаПродажи, Продажи.Скидка, Продажи.IMEI, Продажи.ФИОКлиента AS ФИОКлиента_Продажи, Продажи.ФИОСотрудника, Продажи.Сумма FROM Клиенты INNER JOIN Продажи ON Клиенты.КодКлиента = Продажи.ФИОКлиента

WHERE (((Клиенты.ФИОКлиента)=[Формы]![Клиенты]![ФИОКлиента]));

Группировка записей отсутствует, сортировка осуществляется по дате продажи от старых к новым.

- кнопка «Удалить клиента» удаляет всю информацию о клиенте и о его покупках.

- кнопки навигации и поиска по записям. Расположены в нижней части формы.

Рисунок 4.17 - Форма «Клиенты»

- «Добавить покупку» используется для добавления записи о покупке текущему клиенту. При нажатии на эту кнопку появляется окно с выбором названия производителя мобильного телефона. Данное окно изображено на рисунке 4.18. Форма добавления покупки изображена на рисунке 4.19. Источник данных для формы добавления покупки:

SELECT Продажи.*, Телефоны.НазваниеПроизводителя, Телефоны.Модель, Телефоны.цена AS цена_Телефоны, Производители.КодПроизводителя, Производители.НазваниеПроизводителя AS НазваниеПроизводителя_Производители

FROM (Производители INNER JOIN Телефоны ON Производители.КодПроизводителя = Телефоны.НазваниеПроизводителя) INNER JOIN Продажи ON Телефоны.КодТелефона = Продажи.МодельТелфона

WHERE (((Производители.КодПроизводителя)=[Формы]![Изготовитель]![ПолеСоСписком2]));

- «Редактировать покупку» используется для изменения информации о покупке, например для изменения процента скидки.

- «Удалить запись» используется для удаления выделенной записи.

- «Печать» возле каждой записи. Используется для печати чека (Приложение Б.1). Источником данных для чека является SQL-запрос:

SELECT Продажи.КодНакладной, Клиенты.ФИОКлиента, Клиенты.ТелефонКлиента, Клиенты.АдресКлиента, Продажи.МодельТелфона, Телефоны.НазваниеПроизводителя, Телефоны.IDФФ, Телефоны.Цвет, Телефоны.[Тип камеры], Телефоны.НазваниеОС, Телефоны.НазваниеТипаДисплея, Телефоны.ХарактеристикиДисплея, Телефоны.НазваниеТипаТелефона, Телефоны.Размер, Телефоны.Вес, Телефоны.цена, Продажи.ДатаПродажи, Продажи.Скидка, Продажи.IMEI, Продажи.ФИОСотрудника, Продажи.Сумма FROM Телефоны INNER JOIN (Клиенты INNER JOIN Продажи ON Клиенты.КодКлиента = Продажи.ФИОКлиента) ON Телефоны.КодТелефона = Продажи.МодельТелфона

WHERE (((Продажи.КодНакладной)=[Формы]![Клиенты]![Подчиненные продажи].[Form]![КодНакладной]));

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

Рисунок 4.18 - Форма «Выбор производителя»

Рисунок 4.19 - Форма «Добавление записи»

Кнопка «Поставщики» на главной форме открывает форму со списком поставщиков и их поставками (Рисунок 4.20).

На данной форме расположены такие кнопки:

- «Новый поставщик» отображает пустые поля для добавления нового поставщика.

- «Удалить поставщика» удаляет всю информацию о поставщике и о его поставках.

- кнопки навигации и поиска по записям. Расположены в нижней части формы.

- «Добавить поставку» открывает форму добавления поставки для текущего поставщика (Рисунок 4.21).

Источник данных для формы «Поставщики»:

SELECT Поставщики.КодПоставщика, Поставщики.НазваниеПоставщика, Поставщики.ТелефонПоставщика, Поставщики.ГородПоставщика, Поставщики.АдресПостащика, Поставщики.НазваниеСтраны

FROM Поставщики;

Рисунок 4.20 - Форма «Поставщики»

- «Поставки» открывает форму, содержащую список поставок текущего поставщика (Рисунок 4.22). Кнопка «Добавить поставку» также доступна на этой форме. Источник данных для формы «Поставки»:

SELECT Поставки.КодПоставки, Поставки.НазваниеПоставщика, Поставки.МодельТелефона, Поставки.ДатаПоставки, Поставки.Количество, Поставки.[Номер поставки]

FROM Поставки

ORDER BY Поставки.[Номер поставки];

- кнопка со значком «Отчет» - полный отчет обо всех поставщиках (Приложение Б.2). Источником данных для отчета является SQL запрос:

SELECT Поставщики.*, Поставки.КодПоставки, Поставки.МодельТелефона, Поставки.ДатаПоставки, Поставки.Количество, Поставки.[Номер поставки] FROM Поставщики INNER JOIN Поставки ON Поставщики.КодПоставщика = Поставки.НазваниеПоставщика;

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



Рисунок 4.21 - Форма «Добавить поставку»

Рисунок 4.22 - Форма «Поставки»

Кнопка «Производители» на главной форме открывает форму «Производители», в которой содержится название производителя, логотип, страна и её флаг (Рисунок.4.23). Также данная форма содержит «подчиненная форма Телефоны». Источник данных для данной формы:

SELECT Производители.*, Страны.флаг

FROM Страны INNER JOIN Производители ON Страны.КодСтраны = Производители.НазваниеСтраны;

На данной форме расположены такие кнопки:

- «Новый производитель» форму для добавления нового поставщика (Рисунок 4.24).

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

- кнопки навигации и поиска по записям. Расположены в нижней части формы.

- Кнопка «Все производители» открывает отчет, содержащий информацию обо всех производителям и моделях телефонов этого производителя, продаваемых в магазине (Приложение Б.3). Источником данных для данного отчета является SQL-запрос:

SELECT Производители.*, Телефоны.Модель, Телефоны.цена, Страны.флаг FROM Страны INNER JOIN (Производители INNER JOIN Телефоны ON Производители.КодПроизводителя = Телефоны.НазваниеПроизводителя) ON Страны.КодСтраны = Производители.НазваниеСтраны;

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

Рисунок 4.23 - Форма «Производители»

Рисунок 4.24 - Форма «Добавить производителя»

Кнопка «Телефоны» на главной форме открывает форму «Телефоны», содержащую все модели телефонов продающихся, либо продававшихся в магазине (Рисунок 4.25).

Источник данных для данной формы:

SELECT Телефоны.*, Производители.НазваниеПроизводителя, Телефоны.Модель

FROM Производители INNER JOIN Телефоны ON Производители.КодПроизводителя = Телефоны.НазваниеПроизводителя

ORDER BY Производители.НазваниеПроизводителя, Телефоны.Модель;

На данной форме расположены такие кнопки:

- «Добавить телефон» отображает пустые поля для добавления нового производителя.

- «Удалить телефон» удаляет всю информацию о телефоне.

- кнопки навигации и поиска по записям. Расположены в нижней части формы.

- кнопка «Все телефоны» открывает отчет, содержащий информацию обо всех моделях телефонов (Приложение Б.4). Источником данных для отчета является SQL-запрос:

SELECT Телефоны.*, Производители.НазваниеПроизводителя AS НазваниеПроизводителя_Производители FROM Производители INNER JOIN Телефоны ON Производители.КодПроизводителя = Телефоны.НазваниеПроизводителя;

Данные в отчете сгруппированы по названию производителя. Внутри групп осуществляется сортировка по названию модели в алфавитном порядке.

- кнопка «Популярные за период» открывает отчет, содержащий информацию о самых продаваемых телефонах за введенный период (Приложение Б.5). Источником данных для отчета является SQL-запрос:

SELECT Продажи.МодельТелфона, Продажи.ДатаПродажи, Телефоны.НазваниеПроизводителя, Count(Продажи.КодНакладной) AS [Count-КодНакладной]

FROM Телефоны INNER JOIN Продажи ON Телефоны.КодТелефона = Продажи.МодельТелфона

GROUP BY Продажи.МодельТелфона, Продажи.ДатаПродажи, Телефоны.НазваниеПроизводителя

HAVING (((Продажи.ДатаПродажи) Between [Формы]![Открыть отчет]![Поле73] And [Формы]![Открыть отчет]![Поле75]))

ORDER BY Count(Продажи.КодНакладной) DESC;