Проект базы данных магазина заказов товаров и услуг

Работа добавлена на сайт samzan.net:

СОДЕРЖАНИЕ

[1] СОДЕРЖАНИЕ [2] 1. ЦЕЛИ И ЗАДАЧИ КУРСОВОЙ РАБОТЫ [3] 2. СБОР ИСХОДНЫХ ДАННЫХ И РАЗБИЕНИЕ ПРОЕКТА НА ОТДЕЛЬНЫЕ МОДУЛИ [3.1] 2.1. Сбор исходных данных [3.2] 2.2. Выбор программного обеспечения [3.3] 2.3. Системные требования программного продукта [4] 3. СТРУКТУРА ПРОЕКТА БАЗЫ ДАННЫХ [5] 4. ИНТЕРФЕЙС ПРОЕКТА [5.1] 4.1. Главные формы [5.2] 4.2. Запросы [5.3] 4.3. Отчеты [5.4] 4.4. Параметры запуска [5.5] 4.5. Обучение персонала [6] 5. ОЦЕНКА ПРОЕКТА [7] ЗАКЛЮЧЕНИЕ [8] СПИСОК ИСПОЛЬЗУЕМОЙ ЛИТЕРАТУРЫ

ВВЕДЕНИЕ

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

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

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

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

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

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

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

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

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

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

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

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

1. ЦЕЛИ И ЗАДАЧИ КУРСОВОЙ РАБОТЫ

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

Разработанная база предлагает пользователю:

•  простой – интуитивно понятный интерфейс;
•  запуск даже с машины со слабыми системными требованиями;
•  высокая отказоустойчивость, за счет использования при разработке программы от компании Microsoft Access 2003.

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

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

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

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

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

Вывод

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

2. СБОР ИСХОДНЫХ ДАННЫХ И РАЗБИЕНИЕ ПРОЕКТА НА ОТДЕЛЬНЫЕ МОДУЛИ

2.1. Сбор исходных данных

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

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

База данных будет обрабатывать данные:

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

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

Модуль учета товаров магазина выделен для того чтобы содержать в себе сведения о названии, стоимости, типе товара.

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

Модуль ведения сотрудников магазина содержит данные о фамилии, имени, отчестве сотрудника, его дате рождения, какого пола сотрудник – данные поля являются обязательными для заполнения и каждое из них настроено для хранения своего типа данных, например, поле «Дата рождения» - является типом «Дата\время», а «Фамилия» - текстовым с ограничением символов – 20.

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

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

2.2. Выбор программного обеспечения

Когда завершился этап сбора необходимых данных по проекту необходимо определиться с программным обеспечением, при помощи которого это все будет реализовано. В качестве системы управления базами данных (СУБД) был выбран продукт от компании Microsoft – Access 2003, который поставляется со стандартным набором MS Office 2003. Эта СУБД была выбрана из-за широкой распространенности и внедренности, компанией Microsoft своего продукта, во многие формы, компании и учреждения. Данная СУБД позволяет легко и просто спроектировать реляционную базу данных (БД).

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

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

Доктор Е.Ф. Кодд, автор реляционной модели, разработал целый список критериев, которым должна удовлетворять реляционная модель. Описание этого списка, часто называемого «12 правилами Кодда», требует введения сложной терминологии и выходит за рамки дипломной работы. Тем не менее, можно назвать некоторые правила Кодда для реляционных систем. Чтобы считаться реляционной по Кодду, система управления базами данных должна:

•  Представлять всю информацию в виде таблиц;
•  Поддерживать логическую структуру данных, независимо от их физического представления;
•  Использовать язык высокого уровня для структурирования, выполнения запросов и изменения информации в базах данных;
•  Поддерживать основные реляционные операции (выбор, проектирование и объединение), а также теоретико-множественные операции, такие как объединение, пересечение и дополнение;
•  Поддерживать виртуальные таблицы, обеспечивая пользователям альтернативный способ просмотра данных в таблицах;
•  Различать в таблицах неизвестные значения (nulls), нулевые значения и пропуски в данных;
•  Обеспечивать механизмы для поддержки целостности, авторизации, транзакций и восстановления данных.

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

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

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

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

В определении системы управления реляционными базами данных упоминаются три операции по выборке данных – проектирование, выбор и объединение, которые позволяют строго указать системе, какие данные необходимо показать. Операция проектирования выбирает столбцы, операция выбора – строки, а операция объединения собирает вместе данные из связанных таблиц.

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

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

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

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

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

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

•  Определяться на языке высокого уровня, используемом системой для всех других целей;
•  Храниться в словаре данных, а не в программных приложениях.

Эти возможности в том или ином виде реализованы в большинстве систем.

2.3. Системные требования программного продукта

Минимальные требования к системе:

•  Компьютер/Процессор. Компьютер с процессором Pentium III с быстродействием 1300 мегагерц (МГц) или выше.
•  Память. Требования к оперативной памяти (RAM) зависят от используемой операционной системы: Microsoft Windows 2000 или Windows XP 128 Мб RAM плюс 8 Мб RAM для каждой работающей офисной программы (например, Microsoft Access).
•  Жесткий диск. Требования к объему жесткого диска зависят от конфигурации компьютера и установленных систем. 2000 Мб свободного пространства на жестком диске, в том числе 500 Мб на диске для корректной работы программы на котором установлена операционная система.
•  Дисковод. CD-ROM драйвер.
•  Монитор. Super VGA с разрешением 800x600 и выше и цветовой палитрой 256 цветов.
•  Периферия. Microsoft Mouse, Microsoft IntelliMouse или другое совместимое устройство.
•  Приложения. Microsoft Office XP (Access) или более поздняя версия.

Рекомендуемые системные требования:

•  Компьютер/Процессор. Компьютер с процессором Pentium VI с быстродействием 3200 мегагерц (МГц) или выше.
•  Память. 1024 Мб RAM.
•  Жесткий диск. 40 Гбайт.
•  Дисковод. DVD-ROM.
•  Монитор. PCI-E с разрешением 1600x1200 и выше и цветовой палитрой 32 бита.
•  Периферия. Мышь, клавиатура или другое совместимое устройство.
•  Приложения. Microsoft Office XP/2000/2003/2007 (Access) или более поздняя версия.

Вывод

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

3. СТРУКТУРА ПРОЕКТА БАЗЫ ДАННЫХ

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

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

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

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

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

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

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

Далее указываются таблицы проекта.

Список адресов

Таблица 3.1

Наименование поля	Тип поля	Размер	Индексация	Назначение поля
ID адреса	Счетчик	Длинное целое	Совпадения не допускаются	Ключевое поле
Id улицы	Числовой	Длинное целое	Да (Совпадения допускаются)	Связь с полем ID улицы
Id сотрудника	Числовой	Длинное целое	Да (Совпадения допускаются)	Связь с полем ID сотрудника
Дом/Квартира	Текстовой	12 символов	Нет	Ввод квартиры и/или дома сотрудника
Прописка	Логический	-	Нет	Имеется ли прописка

Список должностей

Таблица 3.2

Наименование поля	Тип поля	Размер	Индексация	Назначение поля
ID должности	Счетчик	Длинное целое	Совпадения не допускаются	Ключевое поле
Id наименования	Числовой	Длинное целое	Да (Совпадения допускаются)	Связь с полем ID названия должности
Id сотрудника	Числовой	Длинное целое	Да (Совпадения допускаются)	Связь с полем ID сотрудника
Id ставки	Числовой	Длинное целое	Да (Совпадения допускаются)	Связь с полем ID ставки
Дата приема	Дата/Время	Краткий формат даты	Нет	Дата приема на должность
Продолжение табл. 3.2
Наименование поля	Тип поля	Размер	Индексация	Назначение поля
Дата увольнения	Дата/Время	Краткий формат даты	Нет	Дата увольнения с должности
Причина увольнения	Поле МЕМО	-	Нет	Описание причины увольнения

Список клиентов

Таблица 3.3

Наименование поля	Тип поля	Размер	Индексация	Назначение поля
ID клиента	Счетчик	Длинное целое	Совпадения не допускаются	Ключевое поле
Фамилия	Текстовый	30 символов	Нет	Фамилия клиента
Имя	Текстовый	20 символов	Нет	Имя клиента
Отчество	Текстовый	25 символов	Нет	Отчество клиента
Серия паспорта	Текстовый	4 символов	Нет	Серия паспорта клиента
Номер паспорта	Текстовый	6 символов	Нет	Номер паспорта клиента

Список наименований должностей

Таблица 3.4

Наименование поля	Тип поля	Размер	Индексация	Назначение поля
ID наименований должностей	Счетчик	Длинное целое	Совпадения не допускаются	Ключевое поле
Продолжение табл. 3.4
Наименование поля	Тип поля	Размер	Индексация	Назначение поля
Наименование должности	Текстовый	30 символов	Нет	Наименование должности
Оклад	Денежный	-	Нет	Оклад должности
Количество ставок	Числовой	Длинное целое	Нет	Количество ставок должности
Id отдела	Числовой	Длинное целое	Да (Совпадения допускаются)	Связь с полем ID отдела

Список населенного пункта

Таблица 3.5

Наименование поля	Тип поля	Размер	Индексация	Назначение поля
ID населенного пункта	Счетчик	Длинное целое	Совпадения не допускаются	Ключевое поле
Наименование населенного пункта	Текстовый	30 символов	Нет	Наименование населенного пункта
Id субъекта	Числовой	Длинное целое	Да (Совпадения допускаются)	Связь с полем ID субъекта
Id типа населенного пункта	Числовой	Длинное целое	Да (Совпадения допускаются)	Связь с полем ID типа населенного пункта

Список отделов

Таблица 3.6

Наименование поля	Тип поля	Размер	Индексация	Назначение поля
ID отдела	Счетчик	Длинное целое	Совпадения не допускаются	Ключевое поле
Продолжение табл. 3.6
Наименование поля	Тип поля	Размер	Индексация	Назначение поля
Наименование отдела	Текстовый	30 символов	Нет	Наименование отдела магазина
Телефон отдела	Текстовый	15 символов	Нет	Телефон отдела магазина

Список полов

Таблица 3.7

Наименование поля	Тип поля	Размер	Индексация	Назначение поля
ID пола	Счетчик	Длинное целое	Совпадения не допускаются	Ключевое поле
Наименование пола	Текстовый	7 символов	Нет	Наименование пола

Список паспорта

Таблица 3.8

Наименование поля	Тип поля	Размер	Индексация	Назначение поля
ID паспорта	Счетчик	Длинное целое	Совпадения не допускаются	Ключевое поле
Id сотрудника	Числовой	Длинное целое	Да (Совпадения допускаются)	Связь с полем ID сотрудника
Серия паспорта	Текстовый	4 символов	Нет	Серия паспорта клиента
Номер паспорта	Текстовый	6 символов	Нет	Номер паспорта клиента
Кем выдан	Текстовый	30 символов	Нет	Кем выдан паспорт
Когда выдан	Дата/Время	Краткий формат даты	Нет	Дата выдачи паспорта
Продолжение табл. 3.8
Наименование поля	Тип поля	Размер	Индексация	Назначение поля
Действителен	Логический	-	Нет	Действителен ли паспорт

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

Таблица 3.9

Наименование поля	Тип поля	Размер	Индексация	Назначение поля
ID поставщика	Счетчик	Длинное целое	Совпадения не допускаются	Ключевое поле
Наименование поставщика	Текстовый	20 символов	Нет	Наименование поставщика товаров в магазин
Адрес поставщика	Текстовый	20 символов	Нет	Адрес поставщика товаров в магазин
Телефон поставщика	Текстовый	15 символов	Нет	Телефон поставщика товаров в магазин

Список ремонта

Таблица 3.10

Наименование поля	Тип поля	Размер	Индексация	Назначение поля
ID ремонта	Счетчик	Длинное целое	Совпадения не допускаются	Ключевое поле
Id сотрудника	Числовой	Длинное целое	Да (Совпадения допускаются)	Связь с полем ID сотрудника
Id клиента	Числовой	Длинное целое	Да (Совпадения допускаются)	Связь с полем ID клиента
Id типа ремонта	Числовой	Длинное целое	Да (Совпадения допускаются)	Связь с полем ID типа ремонта
Продолжение табл. 3.10
Наименование поля	Тип поля	Размер	Индексация	Назначение поля
Количество ремонта	Числовой	Длинное целое	Нет	Количество ремонта
Цена (рублей на единицу)	Денежный	-	Нет	Цена единицы ремонта

Список почтовых отделений

Таблица 3.11

Наименование поля	Тип поля	Размер	Индексация	Назначение поля
ID почтовых отделений	Счетчик	Длинное целое	Совпадения не допускаются	Ключевое поле
Почтовый индекс	Текстовый	6 символов	Нет	Почтовый индекс
Id улицы	Числовой	Длинное целое	Да (Совпадения допускаются)	Связь с полем ID улицы

Список состава заказа товаров

Таблица 3.12

Наименование поля	Тип поля	Размер	Индексация	Назначение поля
ID состава заказа товаров	Счетчик	Длинное целое	Совпадения не допускаются	Ключевое поле
Id сотрудника	Числовой	Длинное целое	Да (Совпадения допускаются)	Связь с полем ID сотрудника
Id клиента	Числовой	Длинное целое	Да (Совпадения допускаются)	Связь с полем ID клиента
Id товара	Числовой	Длинное целое	Да (Совпадения допускаются)	Связь с полем ID товара
Продолжение табл. 3.12
Наименование поля	Тип поля	Размер	Индексация	Назначение поля
Количество товара	Числовой	Длинное целое	Нет	Количество заказанного товара
Дата заказа	Дата/Время	Краткий формат даты	Нет	Дата заказа товаров

Список состава заказа услуг

Таблица 3.13

Наименование поля	Тип поля	Размер	Индексация	Назначение поля
ID состава заказа услуг	Счетчик	Длинное целое	Совпадения не допускаются	Ключевое поле
Id сотрудника	Числовой	Длинное целое	Да (сд)	Связь с полем ID сотрудника
Id клиента	Числовой	Длинное целое	Да (сд)	Связь с полем ID клиента
Id услуги	Числовой	Длинное целое	Да (Совпадения допускаются)	Связь с полем ID услуги
Количество услуги	Числовой	Длинное целое	Нет	Количество предоставленной услуги
Дата заказа	Дата/Время	Краткий формат даты	Нет	Дата заказа услуги

Список цвета

Таблица 3.14

Наименование поля	Тип поля	Размер	Индексация	Назначение поля
ID цвета	Счетчик	Длинное целое	Совпадения не допускаются	Ключевое поле
Продолжение табл. 3.14
Наименование поля	Тип поля	Размер	Индексация	Назначение поля
Наименование цвета	Текстовый	15 символов	Нет	Наименование цвета

Список сотрудников

Таблица 3.15

Наименование поля	Тип поля	Размер	Индексация	Назначение поля
ID сотрудника	Счетчик	Длинное целое	Совпадения не допускаются	Ключевое поле
Фамилия	Текстовый	30 символов	Нет	Фамилия сотрудника
Имя	Текстовый	20 символов	Нет	Имя сотрудника
Отчество	Текстовый	25 символов	Нет	Отчество сотрудника
Дата рождения	Дата/Время	Краткий формат даты	Нет	Дата рождения сотрудника
Id пола	Числовой	Длинное целое	Да (Совпадения допускаются)	Связь с полем ID пола

Список средств связи

Таблица 3.16

Наименование поля	Тип поля	Размер	Индексация	Назначение поля
ID средств связи	Счетчик	Длинное целое	Совпадения не допускаются	Ключевое поле
Номер	Текстовый	15 символов	Нет	Номер средства связи сотрудника
Продолжение табл. 3.16
Наименование поля	Тип поля	Размер	Индексация	Назначение поля
Id типа средства связи	Числовой	Длинное целое	Да (Совпадения допускаются)	Связь с полем ID типа средства связи
Id сотрудника	Числовой	Длинное целое	Да (Совпадения допускаются)	Связь с полем ID сотрудника

Список стоимости товара

Таблица 3.17

Наименование поля	Тип поля	Размер	Индексация	Назначение поля
ID стоимости товара	Счетчик	Длинное целое	Совпадения не допускаются	Ключевое поле
Цена (рублей на единицу)	Денежный	-	Нет	Цена за единицу товара
Дата цены	Дата/Время	Краткий формат даты	Нет	Дата установления цены

Список стоимости услуги

Таблица 3.18

Наименование поля	Тип поля	Размер	Индексация	Назначение поля
ID стоимости услуги	Счетчик	Длинное целое	Совпадения не допускаются	Ключевое поле
Цена (рублей на единицу)	Денежный	-	Нет	Цена за единицу услуги
Дата цены	Дата/Время	Краткий формат даты	Нет	Дата установления цены

Список стран

Таблица 3.19

Наименование поля	Тип поля	Размер	Индексация	Назначение поля
ID страны	Счетчик	Длинное целое	Совпадения не допускаются	Ключевое поле
Официальное название	Текстовый	30 символов	Нет	Официальное название страны
Историческое название	Текстовый	30 символов	Нет	Историческое название страны

Список субъектов

Таблица 3.20

Наименование поля	Тип поля	Размер	Индексация	Назначение поля
ID субъекта	Счетчик	Длинное целое	Совпадения не допускаются	Ключевое поле
Наименование субъектов	Текстовый	15 символов	Нет	Наименование субъекта страны
Id страны	Числовой	Длинное целое	Да (Совпадения допускаются)	Связь с полем ID страны
Id типа субъекта	Числовой	Длинное целое	Да (Совпадения допускаются)	Связь с полем ID типа субъектов

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

Таблица 3.21

Наименование поля	Тип поля	Размер	Индексация	Назначение поля
ID ставки	Счетчик	Длинное целое	Совпадения не допускаются	Ключевое поле
Наименование ставки	Текстовый	30 символов	Нет	Наименование ставки

Список типов населенных пунктов

Таблица 3.22

Наименование поля	Тип поля	Размер	Индексация	Назначение поля
ID типов населенных пунктов	Счетчик	Длинное целое	Совпадения не допускаются	Ключевое поле
Наименование типа населенного пункта	Текстовый	20 символов	Нет	Наименование типа населенного пункта
Краткое наименование	Текстовый	5 символов	Нет	Краткое наименование типа населенного пункта

Список типов ремонта

Таблица 3.23

Наименование поля	Тип поля	Размер	Индексация	Назначение поля
ID типа ремонта	Счетчик	Длинное целое	Совпадения не допускаются	Ключевое поле
Наименование типа ремонта	Текстовый	20 символов	Нет	Наименование типа ремонта

Список типов средств связи

Таблица 3.24

Наименование поля	Тип поля	Размер	Индексация	Назначение поля
ID типа ремонта	Счетчик	Длинное целое	Совпадения не допускаются	Ключевое поле
Наименование типа средства связи	Текстовый	15 символов	Нет	Наименование типа средства связи

Список типов субъектов

Таблица 3.25

Наименование поля	Тип поля	Размер	Индексация	Назначение поля
ID типов субъектов	Счетчик	Длинное целое	Совпадения не допускаются	Ключевое поле
Наименование типа субъекта	Текстовый	20 символов	Нет	Наименование типа субъекта
Краткое наименование	Текстовый	5 символов	Нет	Краткое наименование типа субъекта

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

Таблица 3.26

Наименование поля	Тип поля	Размер	Индексация	Назначение поля
ID типа товара	Счетчик	Длинное целое	Совпадения не допускаются	Ключевое поле
Наименование типа товара	Текстовый	15 символов	Нет	Наименование типа товара

Список типов улиц

Таблица 3.27

Наименование поля	Тип поля	Размер	Индексация	Назначение поля
ID типов улицы	Счетчик	Длинное целое	Совпадения не допускаются	Ключевое поле
Наименование типа улицы	Текстовый	20 символов	Нет	Наименование типа улицы
Краткое наименование	Текстовый	5 символов	Нет	Краткое наименование типа улицы

Список услуг

Таблица 3.28

Наименование поля	Тип поля	Размер	Индексация	Назначение поля
ID услуги	Счетчик	Длинное целое	Совпадения не допускаются	Ключевое поле
Наименование услуги	Текстовый	25 символов	Нет	Наименование услуги
Id стоимости	Числовой	Длинное целое	Да (Совпадения допускаются)	Связь с полем ID стоимости

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

Таблица 3.29

Наименование поля	Тип поля	Размер	Индексация	Назначение поля
ID товара	Счетчик	Длинное целое	Совпадения не допускаются	Ключевое поле
Наименование товара	Текстовый	25 символов	Нет	Наименование товара
Id цвета	Числовой	Длинное целое	Да (СД)	Связь с полем ID цвета
Id типа товара	Числовой	Длинное целое	Да (СД)	Связь с полем ID типа товара
Id поставщика	Числовой	Длинное целое	Да (Совпадения допускаются)	Связь с полем ID поставщика
Id стоимости	Числовой	Длинное целое	Да (Совпадения допускаются)	Связь с полем ID стоимости

Вывод

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

4. ИНТЕРФЕЙС ПРОЕКТА

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

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

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

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

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

Таким образом, собрав все составные части интерфейса, был получен хорошо проработанный и реализованный интерфейс.

4.1. Главные формы

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

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

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

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

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

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

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

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

4.2. Запросы

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

Существуют различные типы запросов. Наиболее распространенными являются запросы на выборку, параметрические и перекрестные запросы. Реже используются запросы на действие, Autolookup и запросы SQL (Structured Query Language). Для создания простых запросов используется мастер, в менее тривиальных случаях можно создать запрос вручную в режиме конструктора.

4.3. Отчеты

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

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

Рис. 4.1. Главная кнопочная форма

Рис. 4.2. Форма, при нажатии кнопки «Выход»

Рис. 4.3. Форма отчетов

Рис 4.4 «Товары»

Рис. 4.5. Вкладка «Паспорт»

Рис. 4.6. Вкладка «Средства связи»

Рис. 4.7. Вкладка «Должность»

4.4. Параметры запуска

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

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

Из всех действий нам потребуется задать новый заголовок «Магазин PC-Gamer» – это необходимо сделать для того, чтобы не было стандартного; выбрать подходящую иконку - прописать путь к иконке, таким образом чтобы при переносе нашей базы на стороннюю машину все иконки сохранялись, для того чтобы так происходило необходимо убрать весь путь и оставить только знак «/» и название иконки с расширением; задействовать все созданные нами меню, и главную кнопочную форму, которая автоматически будет загружаться вместе Access 2003, убрать полное контекстное меню, и контекстное меню по умолчанию. Теперь пользователь будет при запуске видеть кнопочную форму, которая поможет ему в дальнейшем при работе с базой, а ограниченное, в рамках тематики, пользовательские меню, повысят скорость работы пользователя.

4.5. Обучение персонала

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

Вывод

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

5. ОЦЕНКА ПРОЕКТА

Проект разработан при помощи мощного программного продукта фирмы Microsoft – Access 2003. Он обеспечивает превосходную совместимость и безотказность работы во всех новоразработанных продуктах от компании. Еще одним плюсом компании Microsoft – это внедрение повсеместно своих продуктов, что дает дополнительное преимущество разработчику. Так как ему не нужно внедрять свою базу в оболочку, что заняло бы у него много дополнительного времени и затрат.

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

Вывод

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

ЗАКЛЮЧЕНИЕ

1.  В курсовой работе при анализе, основываясь на требованиях к проекту, были поставлены основные цели и задачи, а также пути их решения и реализации.
2.  Был произведен сбор всех необходимых данных для начала разработки базы. Выбрана управляющая СУБД для проектирования. Составлены основные технические требования для корректной работы приложения.
3.  Из исходных данных была сформированы схема данных, структура таблиц и их типы полей, взаимодействие и функционирование.
4.  Исходя из рабочей базы данных, на уровне функционирования, был разработан единый интерфейс для работы с данными – формы, запросы, страницы доступа; для вывода данных – отчеты; для работы – внешнее оформление, меню, справка.
5.  Была получена оценка проекта от заказчика, достоинства и недостатки, так же произведена оценка разработчиком с точки зрения конкуренции, достоинств и работы.

СПИСОК ИСПОЛЬЗУЕМОЙ ЛИТЕРАТУРЫ

1.  Томас Коннолли, Каролин Бегг - БАЗЫ ДАННЫХ Проектирование, реализация и сопровождение. Теория и практика Москва, Санкт-Петербург, Киев, 2003. – 1440 с.
2.  Кочегурова Е. А. Методические указания к выполнению курсовой работы, Томск 2001. – 30 с.
3.  Microsoft Access 2002. Русская версия. Шаг за шагом: Практ. пособ. / Пер. с англ.— М.: Издательство ЭКОМ, 2002. – 352 с.
4.  Microsoft Access 2000. Шаг за шагом: Практическое пособие / Пер. с англ. - М.: ЭКОМ, 2000. – 352 с.
5.  Андерсен В., Базы данных Microsoft Access. Проблемы и решения: Практ. пособ. / Пер. с англ.— М.: Издательство ЭКОМ, 2001.—384 с.
6.  Бакаревич Ю.Б., Пушкина Н.В. MS Access 2000 за 30 занятий. - СПб.: БХВ-Петербург, 2001. – 251 с.
7.  Бакаревич Ю.Б., Пушкина Н.В. Самоучитель Microsoft Access 2000. - СПб.: БХВ-Петербург, 2001. – 456 с.
8.  Биллиг В.А., Дехтярь М.И., VBA и Office 97 Офисное программирование, М., изд. "Русская редакция", 1998. – 218 с.
9.  Бойко В.В., Савинков В.М. Проектирование баз данных информационных систем. – М.: Финансы и статистика, 1999. – 351 с.
10.  Вейскас Д., Эффективная работа с Microsoft Access, С.-Пб., 1998. – 315 с.
11.  Вилдермьюс, Шон., Практическое использование ADO.NET. Доступ к данным в Internet.: Пер. с англ. — М. : Издательский дом "Вильяме", 2003. — 288 с.
12.  Винтер Р. Microsoft Access 97: Справочник. - СПб.: Питер, 1998. – 280 с.
13.  Глушаков С.В., Ломотько Д.В. Базы данных: Учебный курс. – М.: АСТ, 2001.- 504 с.
14.  Глушаков С.В., Сурядный А.С. Microsoft Office 2000: Учебный курс. – Ростов-на-Дону: Феникс, 2001. – 500 с.
15.  Гусева Т.И., Башин Ю.Б., Проектирование баз данных в примерах и задачах, М.,1999. – 423 с.
16.  Дженнингс Р. Microsoft Access 97. - СПб.: BHV – Санкт-Петербург. – 1999. – 1270с.
17.  Джулия Келли. Access 97. Самоучитель – СПб: Питер. - 1999. – 336с.
18.  Информатика. Базовый курс / Под ред. С.В. Символовоновича.- СПб.: Питер, 2001. – 560 с.
19.  Картыгин С.А. Access 97 (Серия без проблем) Вост. Книжн. Компания 1997. – 428 с.
20.  Кириллов В.В. Структурированный язык запросов (SQL). – СПб.: ИТМО, 1994. – 80 с.
21.  Леонтьев Ю. Microsoft Office 2000: Краткий курс. - СПб.: Питер, 2001. – 312 с.
22.  Нейбауэр А. Access 97 для занятых – СПб: Питер. - 1997. – 368с.
23.  Нортон П., Андерсен В. Разработка приложений в Access 97. – СПб.: BHV – Санкт-Петербург. – 1999. – 656с.
24.  Райордан Р., Основы реляционных баз данных/Пер, с англ. — М.: Издательско-торговый дом «Русская Редакция», 2001. — 384 с.
25.  Робинсон С. Access 2000 (учебный курс), С-Петербург "Питер", 2000. – 483 с.
26.  Тимоти Бадд, Объектно - ориентированное программирование в действии, С.-Пб., 1997. – 218 с.
27.  Microsoft Access 97. Шаг за шагом: Практ. пособ./Пер. с англ. – М.: Издательство ЭКОМ. - 1999. – 328с.
28.  Фролов А. В., Фролов Г. В., Базы данных в Интернете: практическое руководство по созданию Web-приложений с базами данных. — Изд. 2-ое, испр. — М.: Издательско-торговый дом «Русская Редакция», 2000. — 448 с.
29.  Хаббард Дж. Автоматизированное проектирование баз данных. – М.: Мир, 1984. – 294 с.
30.  Харитонова И. А., Михеева В. Д. Microsoft Access 2000. Энциклопедическое руководство по СУБД Access 2000. БВХ–САНКТ-ПИТЕРБУРГ, 2000, 1078 с.
31.  Цикритизис Д., Лоховски Ф. Модели данных. – М.: Финансы и статистика, 1985. – 344 с.

1. задание.1
2. Обзор литературы 1
3.  На підставі наведених даних з продаж табл
4. Реферат- Облік і контроль в органах Пенсійного фонду України- теорія та практик
5. Учебное пособие- Избранные лекции по фармакологии и клинической фармакологии
6. Пожаробезопасные кабельные системы
7. ТЕМАМИ ПО ТЕМЕ- УРОВНИ УПРАВЛЯЮЩЕЙ СИСТЕМЫ ШКОЛЬ СТРАТЕГИЧЕСКОЕ ТАКТИЧЕСКОЕ И ОПЕРАТИВНОЕ УПРАВЛЕ
8. Дизайн-освіта майбутнього вчителя трудового навчанн
9. тема складається із Сонця і 8 планет
10. Тема 13 ГРОШОВОКРЕДИТНА СИСТЕМА 1
11. Моральный вред в трудовых отношениях
12. д. Ответственность за организацию труда в целом по предприятию несут директор и главный инженер
13. the estblishment nd funding sources
14. Pple nd no hm in hmburger In this unrelible English tongue greyhounds ren~t lwys grey pnd bers nd kol bers ren~t bers nd guine pig is neither pig nor from Guine
15. РЕФЕРАТ дисертації на здобуття наукового ступеня кандидата економічних наук Львів 2008.html
16. тема оплаты Категория работ Разряд I II II1
17. РЕЛИЗ гАлматы 9 декабря 2013 года В Алматы начинает работу экспериментальный офис по предоставле
18. а Gibson MndolinGuitr Mfg
19. багато іншого Всі можливості планшета можуть перечислити лише його розробники
20. Лекция- Сооружения для хранения плодоовощной продукции 1

Материалы собраны группой SamZan и находятся в свободном доступе