Преподаватель который помогает студентам и школьникам в учёбе.

Базы данных. Проектирование БД клиентов магазина

Содержание:

Введение

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

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

Предмет курсовой работы – база данных для автоматизации учета товаров в торговом зале магазина.

Методологической основой курсовой работы служат работы по проектированию баз данных зарубежных и отечественных авторов: К. Дж. Дейт, В. Грекул, В.В. Кириллова и Г. Ю. Громова, В. М. Илюшечкина, А.П. Лащенко и Т.В. Кишкурно, С. В. Тарасова. Важными для решения поставленных задач являются учебные пособия по реализации баз данных в СУБД Microsoft Access (В.В. Быкова, О. В. Смирнова и др.)

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

ГЛАВА 1. АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ

1.1. Краткая характеристика предметной области

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

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

1.2. Постановка задачи

Спроектировать базу данных для работников управления торговли.

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

При работе с БД могут потребоваться следующие сведения:

· какие товары имеются в магазине (на базе);

· какие отсутствующие товары может заказать магазин на базе;

· какие товары и в каком количестве имеются в отделе магазина;

· список заведующих отделом магазина;

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

· закупка нового товара;

· закрытие отдела в магазине;

· изменение цены товара.

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

1.3. Обоснование выбора средства разработки базы данных

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

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

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

- Не должно быть повторений и между таблицами.

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

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

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

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

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

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

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

ГЛАВА 2. ПРОЕКТИРОВАНИЕ БАЗЫ ДАННЫХ

2.1. Определение сущностей и их атрибутов

Анализ предметной области позволил выделить сущности.

Товар. Данная сущность предназначена для хранения сведений о товарах;

Продавец. Данная сущность предназначена для хранения сведений о продавцах торгового зала;

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

Секция торгового зала. Данная сущность предназначена для хранения сведений о секциях торгового зала.

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

Товар (наименование товара, цена, тип, процент наценки);
Продавец (ФИО продавца, должность);
Склад (название, адрес, профиль);
Секция торгового зала (название секции, ФИО заведующего).

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

2.2. Общие сведения об инфологической модели

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

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

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

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

Сущность – любой различимый объект, информацию о котором необходимо хранить в базе данных^[2]. Необходимо различать такие понятия, как тип сущности и экземпляр сущности. Понятие тип сущности относится к набору однородных личностей, предметов, событий или идей, выступающих как целое. Экземпляр сущности относится к конкретной вещи в наборе.

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

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

Связь – это графически отображаемая ассоциация, устанавливаемая между сущностями.

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

Могут существовать следующие степени бинарных связей:

один к одному: в каждый момент времени каждому экземпляру сущности А соответствует 1 или 0 представителей сущности B;
один ко многим: одному представителю сущности А соответствуют 0, 1 или несколько представителей сущности В.
многие ко многим – любому экземпляру сущности А соответствует 0, 1 или несколько экземпляров сущности В, и наоборот.

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

Популярной в настоящее время наглядной формой представления модели на информационно–логическом уровне являются ER-диаграммы (от англ. Entity-Relationship, т.е. сущность-связь). С ее помощью можно выделить ключевые сущности предметной области и обозначить связи, которые могут устанавливаться между этими сущностями^[4].

Представим на рисунке 1 ER-диаграмму предметной области «Товары торгового зала».

Рис. 1. ER – диаграмма предметной области «Товары торгового зала»

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

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

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

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

2.3. Преобразование ER- модели в реляционную модель

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

Такой метод основывается на формировании набора предварительных таблиц из ER-диаграмм. Для каждой сущности создается таблица, причем каждому атрибуту сущности соответствует столбец таблицы^[5].

Для преобразования связей используют правила.

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

ПРАВИЛО 5. Если степень связи 1:n и класс принадлежности n-связной сущности необязательный, то необходимы три отношения: по одному для каждой сущности и одно для связи. В отношении для связи среди атрибутов должны быть ключи каждой сущности. Ключами первых двух отношений будут ключи сущностей, а ключом третьего – ключ n-связной сущности.

ПРАВИЛО 6. Если степень связи m:n, то необходимы три отношения: по одному для каждой сущности и одно для связи. Первичный ключ сущности должен быть первичным ключом соответствующей таблицы. Таблица для связи среди своих атрибутов должна иметь ключи обеих сущностей.

ПРАВИЛО 7. Для n-арной связи (n>2) требуется n+1 отношение: по одному для каждой сущности и одно для связи. Ключи каждой сущности превращаются в ключи соответствующих отношений. Кроме того, все ключи входят как атрибуты в отношение для связи.

Перечислим отношения и укажем их первичные ключи:

Продавцы (ФИО продавца, Должность);

Склад (Наименование склада, Адрес, Профиль);

Секция торгового зала (Название секции, ФИО заведующего);

Товары (Наименование товара, Тип, Процент наценки);

Товары на складе (Наименование склада, Наименование товара, Цена, Количество) (отношение добавлено по правилу 6);

Поставки (Наименование склада, Название секции, Наименование товара, Количество, Дата поставки) (отношение добавлено по правилу 7);

Товары в зале (Наименование товара, Название секции, Количество) (отношение добавлено по правилу 5);

Продажи (Номер чека, Наименование товара, Дата продажи, Количество, ФИО продавца) (отношение добавлено по правилу 6).

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

2.4. Нормализация отношений предметной области

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

Понятие нормальной формы было введено Эдгаром Коддом при создании реляционной модели базы данных^[6]. Основное назначение нормальных форм – приведение структуры базы данных к виду, обеспечивающему минимальную избыточность. Устранение избыточности производится за счёт декомпозиции отношений таким образом, чтобы в каждом отношении хранились только первичные факты (факты, не выводимые из других хранимых фактов). Нормализация не имеет целью уменьшение или увеличение производительности работы или же уменьшение или увеличение объёма базы данных. Конечной целью нормализации является уменьшение противоречивости хранимой в базе информации^[7].

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

Существует пять нормальных форм^[8], однако для большинства баз данных достаточно нормализовать базы данных до третьей нормальной формы.

Таблица находится в первой нормальной форме (1NF), если каждый её атрибут атомарен. Под выражением «атрибут атомарен» понимается, что атрибут может содержать только одно значение.

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

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

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

Все исходные таблицы находятся в 1NF и 2 NF, так же все таблицы, кроме таблицы Товары, находятся так же в 3 NF.

Таблица Товары не находится в 3 NF, так как размер наценки на товар зависит от Типа товара. Таким образом, таблица Товары должна быть разделена на две: Товары (Наименование товара, Код типа); Типы товаров (Наименование типа товара, Процент наценки).

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

Перечислим итоговые отношения:

Продавцы (Код продавца, ФИО продавца, Должность);

Товары (Код товара, Наименование товара, Тип);

Склад (Код склада, Наименование склада, Адрес, Профиль);

Секция торгового зала (Номер секции, Название секции, ФИО заведующего);

Типы товаров (Код типа, Наименование типа, Процент наценки);

Товары на складе (Код склада, Код товара, Цена, Количество);

Поставки (Номер поставки, Код склада, Код секции, Код товара, Количество, Дата поставки);

Товары в зале (Код товара, Номер секции, Количество);

Продажи (Номер чека, Код товара, Дата продажи, Количество, Код продавца).

2.5. Физическая модель предметной области

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

Таблица 1

Структура таблицы Продавцы

№	Обозначение	Название	Тип	Длина	Примечание
1	КодПр	Код продавца	Длинное целое	4	Ключ
2	ФИОпр	Фамилия имя отчество продавца	Текстовый	25
3	Должность	Должность	Текстовый	25

Таблица 2

Структура таблицы Типы товаров

№	Обозначение	Название	Тип	Длина	Примечание
1	КодТ	Код типа	Длинное целое	4	Ключ
2	НаименТ	Наименование типа	Текстовый	50
3	ПроцНац	Процент наценки	Одинарное с плавающей точкой	4

Таблица 3

Структура таблицы Товары

№	Обозначение	Название	Тип	Длина	Примечание
1	КодТв	Код товара	Длинное целое	4	Ключ
2	НаимТв	Наименование товара	Текстовый	100
3	КодТ	Код типа товара	Длинное целое	4

Таблица 4

Структура таблицы Секции торгового зала

№	Обозначение	Название	Тип	Длина	Примечание
1	НомС	Номер секции	Длинное целое	4	Ключ
2	НазванС	Название секции	Текстовый	25
3	ФИОЗав	ФИО заведующего	Текстовый	25

Таблица 5

Структура таблицы Продажи

№	Обозначение	Название	Тип	Длина	Примечание
1	НомЧ	Номер чека	Длинное целое	4	Ключ
2	КодТв	Код товара	Длинное целое	4	Ключ
3	Дата	Дата продажи	Дата/время	8
4	Кол	Количество	Целое	2
5	КодПр	Код продавца	Длинное целое	4

Таблица 6

Структура таблицы Склад

№	Обозначение	Название	Тип	Длина	Примечание
1	КодС	Код склада	Длинное целое	4	Ключ
2	НазвС	Название склада	Текстовый	50
3	Адрес	Адрес	Текстовый	100
4	Профиль	Профиль	Текстовый	20

Таблица 7

Структура таблицы Поставки

№	Обозначение	Название	Тип	Длина	Примечание
1	НомПост	Номер поставки	Длинное целое	4	Ключ
2	КодС	Код склада	Длинное целое	4
3	КодС	Код секции торгового зла	Длинное целое	4
4	КодТв	Код товара	Длинное целое	4
5	Количество	Количество	Длинное целое	4
6	Дата	Дата поставки	Дата/время	8

Таблица 8

Структура таблицы Товары на складе

№	Обозначение	Название	Тип	Длина	Примечание
1	КодС	Код склада	Длинное целое	4	Ключ
2	КодТв	Код товара	Длинное целое	4	Ключ
3	Количество	Количество	Длинное целое	4
4	Цена	Цена склада	Длинное целое	4

Таблица 9

Структура таблицы Товары в зале

№	Обозначение	Название	Тип	Длина	Примечание
1	КодТВ	Код товара	Длинное целое	4	Ключ
2	НомС	Номер секции	Длинное целое	4
3	Кол	Количество	Длинное целое	4

Схема базы данных представлена на рисунке 2.

Рис. 2. Схема базы данных

ГЛАВА 3. РЕАЛИЗАЦИЯ БАЗЫ ДАННЫХ

3.1. Создание таблиц

На рисунках 3-11 представлены таблицы базы данных в режиме конструктора.

Рис. 3. Таблица Типы товаров

Рис. 4. Таблица Товары

Рис. 5. Таблица Склад

Рис. 6. Таблица Товары на складе

Рис. 7. Таблица Секции торгового зала

Рис. 8. Таблица Продавцы

Рис. 9. Таблица Поставки

Рис. 10. Таблица Продажи

Рис. 11. Таблица Товары в зале

3.2. Создание форм

Для создания форм в Microsoft Access 2007 разработано несколько инструментов^[9]. Нами использовался Мастер форм.

Формы были созданы для всех таблиц.

На рисунке 12 представлена форма для ввода данных в таблицу Товары в зале. Для Заполнения полей Товар, Секция создано поле со списком.

Рис. 12. Форма Товары в зале

3.3. Создание запросов

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

Вывести список складов, поставляющих продукты питания.

Структура запроса представлена на рисунке 13.

Рис. 13. Запрос Поставка

Выходные данные запроса представлены на рисунке 14.

Рис. 14. Выходные данные запроса Склады_Продукты питания

Сведения о поставке товаров в определенный день.

Дата вводится как параметр.

Структура запроса представлена на рисунке 15.

Рис. 15. Запрос Поставка

Выходные данные запроса представлены на рисунке 16.

Рис. 16. Выходные данные запроса Поставка

Посчитать стоимость товара в чеке.

Создадим формулы для расчета:

Стоимость: [Цена]*[ПроцНац]/100+[Цена];
Итого: [Стоимость]*[Кол].

Структура запроса представлена на рисунке 17.

Рис. 17. Запрос К оплате

Выходные данные запроса представлены на рисунке 18.

Рис. 18. Выходные данные запроса К оплате

Запрос, позволяющий посчитать итоги продаж за день.

Структура запроса представлена на рисунке 19.

Рис. 19. Запрос Итоги дня

Выходные данные запроса представлены на рисунке 20.

Рис. 20. Выходные данные запроса Итоги дня

3.4. Создание отчетов

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

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

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

Отчет представлен на рисунке 21.

Рис. 21. Отчет Продавцы

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

Рис. 22. Отчет Склад

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

Рис. 23. Отчет Чеки

3.5. Создание кнопочной формы

В Microsoft Access можно создавать кнопочные формы^[10]. Они содержат только кнопки и предназначены для выбора основных действий в базе данных. Для создания кнопочной формы необходимо на вкладке ленты Работа с базами данных выбрать команду Диспетчер кнопочных форм.

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

Главная кнопочная форма представлена на рисунке 24.

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

На рисунке 25 представлена одна из страниц Главной кнопочной формы. На каждой странице созданы кнопки для открытия необходимых объектов базы данных и кнопка возврата на первую страницу.

Рис. 25. Страница Склад

Заключение

Цель курсового проекта – разработать реляционную базу данных «Товары торгового зала».

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

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

В процессе выполнения проекта была изучена и смоделирована предметная область «Товары торгового зала». При моделировании использовалось свободное программное обеспечение – программа для построения диаграмм Dia.

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

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

Разработанная база данных содержит 9 таблиц, 9 форм для ввода и отображения данных, 4 запроса и 3 отчет. Для удобства работы пользователей с базой данных создана форма — меню.

Отметим, что данная база может быть расширена. Перспективным направлением развития базы данных может быть

1) увеличение количества характеристик объектов. Так, например, может быть добавлена характеристика товара — срок годности, наличие и срок сертификата качества, состав и др.

2) увеличение количества сущностей. Так, например, можно добавить сущность Должность.

3) Еще одним направлением развития проекта является разграничение прав доступа пользователей.

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

Отметим, что данная база может быть расширена. Перспективным направлением развития базы данных может быть

2) увеличение количества сущностей. Так, например, можно добавить сущность Должность.

3) Еще одним направлением развития проекта является разграничение прав доступа пользователей.

Список используемой литературы

1. Архитектура и технологии IBM eServer zSeries / В.А. Варфоломеев и др. - М.: Интернет-университет информационных технологий, 2015. - 640 c.

2. Владимир, Михайлович Илюшечкин Основы использования и проектирования баз данных / Владимир Михайлович Илюшечкин. - М.: Юрайт, 2015. - 516 c.

3. Голицына, О. Л. Базы данных / О.Л. Голицына, Н.В. Максимов, И.И. Попов. - М.: Форум, 2015. - 400 c.

4. Зубов, А. В. Основы искусственного интеллекта для лингвистов / А.В. Зубов, И.И. Зубова. - Москва: РГГУ, 2013. - 320 c.

5. Илюшечкин, В. М. Основы использования и проектирования баз данных / В.М. Илюшечкин. - М.: Юрайт, Юрайт, 2013. - 224 c.

6. Илюшечкин, В. М. Основы использования и проектирования баз данных. Учебник / В.М. Илюшечкин. - М.: Юрайт, 2014. - 214 c.

7. Илюшечкин, В. М. Основы использования и проектирования баз данных. Учебник / В.М. Илюшечкин. - М.: Юрайт, 2015. - 214 c.

8. Исаев, Г. Н. Информационные системы в экономике. Учебник / Г.Н. Исаев. - М.: Омега-Л, 2015. - 464 c.

9. Карпова, И. П. Базы данных / И.П. Карпова. - М.: Питер, 2013. - 240 c.

10. Кириллов, В.В. Введение в реляционные базы данных (+ CD-ROM) / В.В. Кириллов. - М.: БХВ-Петербург, 2016. - 318 c.

11. Комплекснозначные и гиперкомплексные системы в задачах обработки многомерных сигналов / Я.А. Фурман и др. - М.: ФИЗМАТЛИТ, 2015. - 456 c.

12. Костин, А. Е. Организация и обработка структур данных в вычислительных системах. Учебное пособие / А.Е. Костин, В.Ф. Шаньгин. - М.: Высшая школа, 2014. - 248 c.

13. Кудрявцев, В.Б. Интеллектуальные системы. Учебник и практикум для бакалавриата и магистратуры / В.Б. Кудрявцев, Э.Э. Гасанов, А.С. Подколзин. - Москва: ИЛ, 2016. - 219 c.

14. Кузнецов, С. Д. Базы данных. Модели и языки / С.Д. Кузнецов. - М.: Бином-Пресс, 2013. - 720 c.

15. Кузнецов, С. Д. Основы баз данных / С.Д. Кузнецов. - М.: Бином. Лаборатория знаний, Интернет-университет информационных технологий, 2017. - 488 c.

16. Латыпова, Р. Р. Базы данных. Курс лекций / Р.Р. Латыпова. - Москва: Высшая школа, 2016. - 177 c.

17. Мартишин, С. А. Базы данных. Практическое примечание СУБД SQL и NoSOL. Учебное пособие / С.А. Мартишин, В.Л. Симонов, М.В. Храпченко. - М.: Форум, Инфра-М, 2016. - 368 c.

18. Миркин, Б. Г. Введение в анализ данных. Учебник и практикум / Б.Г. Миркин. - М.: Юрайт, 2015. - 176 c.

19. Нейрокомпьютеры в системах обработки изображений. - М.: Радиотехника, 2013. - 192 c.

20. Остроух, А. В. Ввод и обработка цифровой информации / А.В. Остроух. - М.: Академия, 2016. - 288 c.

21. Персианов, Вячеслав Венедиктович; Технология Проектирования Информационной Базы Для Педагогических Вузов Страны. / Персианов Вячеслав Венедиктович;. - Москва: Огни, 2016. - 594 c.

22. Персианов, Вячеслав Венедиктович; Электронное Образовательное Пространство Педагогического Университета:Формирование, Применение, Проблемы / Персианов Вячеслав Венедиктович;. - Москва: Гостехиздат, 2013. - 195 c.

23. Проектирование баз данных. СУБД Microsoft Access. Учебное пособие. - М.: Горячая линия - Телеком, 2013. - 240 c.

24. Свиридова, М. Ю. Система управления базами данных Access / М.Ю. Свиридова. - М.: Академия, 2016. - 192 c.

25. Советов, Б. Я. Моделирование систем / Б.Я. Советов, С.А. Яковлев. - М.: Высшая школа, 2015. - 343 c.

26. Стружкин, Н. П. Базы данных. Проектирование. Учебник / Н.П. Стружкин, В.В. Годин. - М.: Юрайт, 2016. - 478 c.

27. Фуфаев, Э. В. Базы данных / Э.В. Фуфаев, Д.Э. Фуфаев. - М.: Академия, 2016. - 320 c.

28. Фуфаев, Э. В. Базы данных. Учебное пособие / Э.В. Фуфаев, Д.Э. Фуфаев. - М.: Академия, 2014. - 320 c.

29. Хомоненко, А. Работа с базами данных в C++ BUILDER / А. Хомоненко. - М.: Книга по Требованию, 2017. - 488 c.

30. Цуканова, Н. И. Онтологическая модель представления и организации знаний. Учебное пособие / Н.И. Цуканова. - М.: Горячая линия - Телеком, 2015. - 272 c

Грекул В. Проектирование информационных систем / В. Грекул. [Электронный ресурс]. – Режим доступа: http://www.intuit.ru/studies/courses/2195/55/info ↑
Коннолли Т. Базы данных. Проектирование, реализация и сопровождение. Теория и практика / Т. Коннолли, К. Бегг. – 3-е изд. – М.: Вильямс, 2017. – 1440 c ↑
Илюшечкин В. М. Основы использования и проектирования баз данных. / В. М. Илюшечкин. – М.: Юрайт-Издат, 2011. – 213 с. ↑
Жданов, С.А. Информационные системы: учебник для студентов учреждений высшего образования: учебник / С.А. Жданов, М.Л. Соболева, А.С. Алфимова. - Москва: Прометей. – 2015. - 302 с ↑
Коннолли Т. Базы данных. Проектирование, реализация и сопровождение. Теория и практика / Т. Коннолли, К. Бегг.– 3-е изд. – М.: Вильямс, 2017. – 1440 c ↑
Мирошниченко Г. Реляционные базы данных. Практические приемы оптимальных решений. / Г. Мирошниченко. – СПб: БХВ-Петербург, 2011. – 199 с. ↑
Кириллов В.В. Введение в реляционные базы данных // В.В. Кириллов, Г. Ю. Громов. – BHV, 2017. – 464 с. ↑
Коннолли Т. Базы данных. Проектирование, реализация и сопровождение. Теория и практика / Т. Коннолли, К. Бегг.– 3-е изд. – М.: Вильямс, 2017. – 1440 c. ↑
Лащенко, А.П. Проектирование баз данных и СУБД Access 2007 / А.П. Лащенко, Т.В. Кишкурно. - Минск: БГТУ, 2011. – 120 с ↑
Смирнова О. В. Access 2007 на практике / О. В. Смирнова.– Москва: Феникс, 2009. – 160 с. ↑