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

провести системный анализ предметной области «Магазин “ТехноТорг”»;
провести обзор информационных технологий, подходящих для разработки БД;
изучить аналогичные информационные системы данной предметной области;
описать требования, предъявляемые к разработке данной базы данных;
разработать инфологическую модель базы данных;
обосновать выбор модели данных и осуществить логическое проектирование базы данных;
нормализовать спроектированную модель и составить схему базы данных;
осуществить реализацию БД на выбранной СУБД;
Разрабатываемая автоматизированная система управления «Магазин “ТехноТорг”» является актуальной в связи с высокой потребностью в компьютерной технике.

Описание структуры курсового проекта:

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

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

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

Глава 1. Анализ предметной области АСУ «Продажа компьютерной техники»

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

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

1.1 Системный анализ предметной области АСУ «ТехноТорг»

Магазин компьютерной техники «ТехноТорг» начал свою работу в конце 2016 года в г. Москва. За это время он стал достаточно популярным за счет низких цен и хорошего качества продаваемой продукции.

19 стр., 9495 слов

Разработка базы данных для магазина бытовой техники

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

Граждане России получили возможность заказывать следующие категории товаров:

Ноутбуки
Телефоны
Планшеты
Аксессуары
Фотоаппараты
Видеокамеры

Рис. 1. Организационная структура магазина «ТехноТорг»

На рисунке 1 представлена организационная структура магазина «ТехноТорг», которая состоит из руководителя, бухгалтерии, менеджера, администратора, кассы, продавца и курьера.

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

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

Администратор магазина контролирует работу продавца в отделе продаж.

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

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

В магазине «ТехноТорг» ведется учет всех работников, товаров, заказов и клиентов.

Для сотрудника магазина хранится следующая информация:

ФИО
Дата рождения
Паспортные данные
Телефон
Адрес
Дата приема на работу

При оформлении заказа клиентом, данные о нем также фиксируются и хранятся:

ФИО
Дата рождения
Телефон
Адрес
Почтовый индекс

Данные о заказе:

ФИО
Телефон
Товар
Количество товара
Дата заказа
Адрес доставки
Дата доставки
Стоимость доставки
Стоимость заказа

Данные о товарах:

Наименование товара
Категория
Производитель
Цена
Срок гарантии

Данные в чеке:

Код чека
Товар
Количество
Сумма
Дата покупки

1.2 Обзор информационных технологий, подходящих для разработки БД

СУБД можно условно разделить на следующие классы:

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

Домашние (настольные) СУБД

Microsoft Office Access

Основные компоненты MS Access:

построитель таблиц;
построитель экранных форм;
построитель SQL-запросов (язык SQL в MS Access не соответствует стандарту ANSI);
построитель отчётов, выводимых на печать.

Они могут вызывать скрипты на языке VBA, поэтому MS Access позволяет разрабатывать приложения и БД практически «с нуля» или написать оболочку для внешней БД.

18 стр., 8997 слов

Разработка СУБД «Кондитерские фабрики»

... цену за единицу товара, дату поставки, ФИО директора. Это позволяет систематизировать работу фабрик: фиксировать дату выпуска и дату сбыта продукции, ее тип, название; легко узнать данные магазина (потребителя), которой ...

Microsoft Jet Database Engine

Встроенные средства взаимодействия MS Access со внешними СУБД с использованием интерфейса ODBC снимают ограничения, присущие Microsoft Jet Database Engine. Инструменты MS Access, которые позволяют реализовать такое взаимодействие называются «связанные таблицы» (связь с таблицей СУБД) и «запросы к серверу» (запрос на диалекте SQL, который «понимает» СУБД).

Корпорация Microsoft для построения полноценных клиент-серверных приложений на базе MS Access рекомендует использовать в качестве движка базы данных СУБД MS SQL Server. При этом имеется возможность совместить с присущей MS Access простотой инструменты для управления БД и средства разработки.

Известны также реализации клиент-серверных приложений на базе связки Access 2003 c другими СУБД, в частности, MySQL.

Полупрофессиональные СУБД

MySQL является собственностью компании Sun Microsystems, осуществляющей разработку и поддержку приложения. Распространяется под GNU General Public License и под собственной коммерческой лицензией, на выбор. Помимо этого компания MySQL AB разрабатывает функциональность по заказу лицензионных пользователей, именно благодаря такому заказу почти в самых ранних версиях появился механизм репликации.

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

Гибкость СУБД MySQL обеспечивается поддержкой большого количества типов таблиц: пользователи могут выбрать как таблицы типа MyISAM, поддерживающие полнотекстовый поиск, так и таблицы InnoDB, поддерживающие транзакции на уровне отдельных записей. Более того, СУБД MySQL поставляется со специальным типом таблиц EXAMPLE, демонстрирующим принципы создания новых типов таблиц. Благодаря открытой архитектуре и GPL-лицензированию, в СУБД MySQL постоянно появляются новые типы таблиц.

MySQL портирована на большое количество платформ:AIX, BSDi, FreeBSD, HP-UX, GNU/Linux, Mac OS X, NetBSD, OpenBSD, OS/2 Warp, SGI IRIX, Solaris, SunOS, SCO OpenServer, SCO UnixWare, Tru64, Windows 95, Windows 98, Windows NT, Windows 2000, Windows XP, Windows Server 2003, WinCE, Windows Vista и Windows 7. Существует также порт MySQL на OpenVMS. Важно отметить, что компания MySQL AB предоставляет для свободной загрузки не только исходные коды СУБД, но и откомпилированные и оптимизированные под конкретные операционные системы готовые исполняемые модули.

MySQL имеет API для языков Delphi, C, C++, Эйфель, Java, Лисп, Perl, PHP, Python, Ruby, Smalltalk и Tcl, библиотеки для языков платформы .NET, а также обеспечивает поддержку для ODBC посредством ODBC-драйвера MyODBC.

Профессиональные СУБД

Oracle Database

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

37 стр., 18434 слов

Проектирование Базы Данных для коммерческого предприятия

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

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

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

Некоторые ключевые возможности Oracle Database:

Real Application Cluster (RAC) обеспечивает работу одного экземпляра базы данных на нескольких узлах grid, позволяя управлять нагрузкой и гибко масштабировать систему в случае необходимости.
Automatic Storage Management (ASM) позволяет автоматически распределять данные между имеющимися ресурсами систем хранения данных, что повышает отказоустойчивость системы и снижает общую стоимость владения (TCO).
Производительность. Oracle Database позволяет автоматически управлять уровнями сервиса и тиражировать эталонные конфигурации в рамках всей сети.
Простые средства разработки. Новый инструмент разработки приложений HTML DB позволит простым пользователям создавать эффективные приложения для работы с базами данных в короткие сроки.
Самоуправление. Специальные механизмы Oracle Database позволяют самостоятельно перераспределять нагрузку на систему, оптимизировать и корректировать SQL-запросы, выявлять и прогнозировать ошибки.
Большие базы данных. Теперь максимальный размер экземпляра базы данных Oracle может достигать 8 экзабайт.
Недорогие серверные системы. Oracle Database может использовать недорогие однопроцессорные компьютеры или модульные системы из «серверов-лезвий».

— В новой версии базы данных реализована поддержка переносимых табличных пространств, система управления потоками данных Oracle Streams и модель распределенных SQL-запросов. Для переноса существующих баз данных в среду Grid в них не потребуется вносить изменений, что позволяет быстро начать использовать все преимущества Oracle Database.

Ядром СУБД является сервер базы данных, который поставляется в одной из четырех редакций (Oracle Database 10g Enterprise Edition, Oracle Database 10g Standard Edition, Oracle Database 10g Standard Edition One, Oracle Database 10g Personal Edition) в зависимости от масштаба информационной системы, в рамках которой предполагается его применение.

Oracle опирается на стандарт SQL-3, позволяющий описывать определения новых типов объектов, состоящих из атрибутов (скалярных — то есть других типов, множеств объектов, ссылок на объекты) и обладающих ассоциированными с ним методами.

1.3 Обзор продуктов аналогов АСУ «Продажа компьютерной техники»

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

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

6 стр., 2874 слов

Данные дистанционного зондирования Земли как источник информации ...

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

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

Информационная система интернет-магазина «DNS»

Рис. 2. Внешний вид магазина «DNS»

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

Информационная система интернет-магазина «М.видео»

Рис. 3. Внешний вид магазина «М.видео»

«М.Видео» — лидер по продаже электроники и бытовой техники среди розничных сетей России. Данный магазин существует уже 23 года. «М.видео» предоставляет возможность покупать электронику в интернет-магазине или бронировать товары и забирать их в любом удобном магазине сети. Огромный ассортимент бытовой и цифровой техники и выгодные цены.

1.4 Требования к разрабатываемой БД магазина «ТехноТорг»

В соответствии с ГОСТ 34.601-90 сформированы следующие требования:

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

Администратор
Менеджер
Клиент

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

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

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

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

При работе с базой данных клиент может:

просматривать информацию о заказах

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

работники не моложе 18 лет;
у каждого сотрудника должны быть обязательно заполнены все данные;
при заказе обязательно требуется заполнение полей ФИО и моб. Телефона;
при заказе от 10 тыс. рублей доставка бесплатная.

Выводы по первой главе

В первой главе проведен системный анализ предметной области объекта автоматизации «ТехноТорг», в ходе которого перечислены должности работников и их функции.

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

Рассмотрены продукты-аналоги на рынке информационных систем (АСУ «DNS», «М.видео») и даны описания данных систем.

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

Глава 2. Проектирование базы данных для объекта автоматизации «Магазин ТехноТорг»

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

9 стр., 4417 слов

Проектирование базы данных ‘Гостиница’

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

2.1 Разработка инфологической модели БД магазина «ТехноТорг»

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

При проектировании на инфологическом уровне создается информационно-логическая модель, которая должна отвечать следующим требованиям:

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

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

Для информационной системы «Магазин ТехноТорг» на основе проведенного системного анализа предметной области выделены следующие сущности:

1. продавец: сущность содержит информацию о продавцах, работающих в магазине;

2. продажа товара: сущность содержит информацию о продаже товара;

3. товар: сущность содержит информацию о товарах;

4. категории: сущность содержит информацию о категории товара, продаваемого в магазине;

5. производитель: сущность содержит информацию о производителях товаров;

6. клиент: сущность содержит информацию о клиентах;

7. заказ: сущность содержит информацию о заказе;

8. доставка товара: сущность содержит информацию об осуществлении заказа;

9. менеджеры: сущность содержит информацию о менеджерах, работающих в магазине.

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

Рис. 4. Инфологическая модель предметной области

2.2 Обоснование выбора модели данных

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

Существуют несколько типов даталогических моделей данных:

сетевая модель;
иерархическая модель;
объектно-ориентированная модель;
реляционная модель;

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

26 стр., 12757 слов

Проектирование и разработка базы данных ‘Магазин продажи одежды’

... курсовой работы является проектирование и разработка базы данных «Магазина продажи одежды». Особенности: Введение данных в БД осуществляется с админ зоны У каждого товара ... модель базы данных Содержание поля Имя поля Тип данных Примечание Admin_description Кодадмина id int Not null, auto_incriment, primery key email email varchar Not null Пароль password varchar Not null имя name varchar Not null ...

Рассмотрим подробнее каждый тип даталогической модели.

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

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

Сетевая БД состоит из набора экземпляров определенного типа записи и набора экземпляров определенного типа связей между этими записями.

Тип связи определяется для двух типов записи: предка и потомка. Экземпляр типа связи состоит из одного экземпляра типа записи предка и упорядоченного набора экземпляров типа записи потомка. Для данного типа связи L с типом записи предка P и типом записи потомка C должны выполняться следующие два условия:

каждый экземпляр типа записи P является предком только в одном экземпляре типа связи L;
каждый экземпляр типа записи C является потомком не более чем в одном экземпляре типа связи L.

Достоинством сетевой модели данных является возможность эффективной реализации по показателям затрат памяти и оперативности. Недостатком сетевой модели данных являются высокая сложность и жесткость схемы БД, построенной на ее основе.

Пример сетевой модели показан на рисунке 5.

Рис. 5. Сетевая модель.

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

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

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

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

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

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

9 стр., 4493 слов

Базы данных, основные модели их организации

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

На рисунке 6 представлено графическое изображение иерархической модели.

Рис. 6. Иерархическая модель.

объектно-ориентированной модели

Логическая структура объектно-ориентированной БД внешне похожа на структуру иерархической БД. Основное различие между ними состоит в методах манипулирования данными.

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

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

реляционной модели

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

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

На рисунке 7 показана реализация реляционной модели данных.

Рис. 7. Реляционная модель данных.

Многомерные структуры

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

информационный база данные логический

2.3 Логическое проектирование БД магазина «ТехноТорг»

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

отсутствие дублируемой информации;
поддержание целостности данных при вставке, удалении или изменении записей;
возможность организации всех видов связи между отношениями 1:1, 1:M и M:M.

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

9 стр., 4434 слов

Разработка структуры базы данных для информационной системы «Аэропорт»

... выполнения работы необходимо использовать 3 Проектирование БД 3.1 Описание предметной области Предметная область курсовой работы представляет собой разработку базы данных для информационного функционирования аэропорта. Аэропорт – ... данных ER – модель физического уровня: 5.1.1 Таблица Airplanes SQL – код: Create table Airplanes ( > ID INTEGER not null primary key, > Plane VARCHAR (255) not null ...

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

Основой анализа корректности схемы являются функциональные зависимости между атрибутами БД. Некоторые могут быть нежелательными.

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

Процесс разработки корректной схемы РБД и является даталогическим проектированием. Возможны 2-а способа:

Декомпозиция (разбиение);
Синтез;

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

1. каждой сущности ставится в соответствие отношение;

2. каждому атрибуту сущности ставится в соответствие соответствующий атрибут соответствующего отношения;

3. первичный ключ сущности становится PK соответствующего отношения, при этом атрибуты, входящие в PK, обязательны для заполнения (NOT NULL);

4. в каждое отношение, соответствующее подчинённой сущности, добавляется набор атрибутов основной сущности, являющийся в ней первичным ключом. В отношении, соответствующее подчинённой сущности эти атрибуты становятся FK (внешним ключом);

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

6. для отражения категоризации сущностей возможны несколько вариантов;

7. все связи М:М должны быть раскрыты;

Воспользуемся данным алгоритмом и опишем каждую сущность инфологической модели:

Категории

Код категории — int NOT NULL PK

Название — varchar(40) NOT NULL

Товар

Код товара — int NOT NULL PK

Название — varchar(30) NOT NULL
Код категории — int NOT NULL FK
Код производителя — int NOT NULL FK
Срок гарантии — int NOT NULL
Цена товара — int NOT NULL

Продавец

Код продавца — int NOT NULL PK

ФИО — varchar(40) NOT NULL
Дата рождения — date NOT NULL
Паспортные данные — varchar(20) NOT NULL
Адрес — varchar(100) NOT NULL
Телефон — int NOT NULL
Дата приема на работу — date NOT NULL

Клиент

Код клиента — int NOT NULL PK

ФИО — varchar(40) NOT NULL
Дата рождения — date NOT NULL
Адрес — varchar(100) NOT NULL
Телефон — int NOT NULL
Почтовый индекс — int NOT NULL

Заказ

Код заказа — int NOT NULL PK

Код доставки — int NOT NULL FK
Код клиента — int NOT NULL FK
Код товара — int NOT NULL
Количество товара — int NOT NULL
Дата заказа — date NOT NULL
Стоимость — int NOT NULL

Доставка товара

Код доставки — int NOT NULL PK

Стоимость доставки — int NOT NULL
Адрес доставки — varchar(40) NOT NULL
Телефон — int NOT NULL
Дата доставки — int NOT NULL
Код менеджера — int NOT NULL FK

Менеджеры

Код менеджера — int NOT NULL PK

ФИО — varchar(40) NOT NULL
Дата рождения — date NOT NULL
Паспортные данные — varchar(20) NOT NULL
Адрес — varchar(100) NOT NULL
Телефон — int NOT NULL
Дата приема на работу — date NOT NULL

Продажа товара

Код чека — int NOT NULL PK

Код продавца — int NOT NULL FK
Количество товара- int NOT NULL

Содержание чека

Код чека — int NOT NULL FK

Код товара — int NOT NULL FK

Сумма — int NOT NULL

Производитель

Код производителя — int NOT NULL PK

Название — varchar(25) NOT NULL
Страна — varchar(25) NOT NULL
Адрес сайта — varchar(30) NOT NULL
Телефон — int NOT NULL

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

Исходя из приведённых выше отношений, построим схему получившейся БД (Рисунок 8):

Рисунок 8. Схема реляционной модели БД «Магазин ТехноТорг»

2.4 Нормализация, схема базы данных

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

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

Понятие нормализации тесно связано с понятием функциональной зависимости. Функциональная зависимость (ФЗ) определяет отношения между объектами и их свойствами в рассматриваемой ПО.

ФЗ R.A R.B называется полной, если набор атрибутов B ФЗ от A и не зависит функционально от любого подмножества А.

ФЗ R.А R.В называется транзитивной, если существует такой набор атрибутов С, который удовлетворяет следующим свойствам: 1. С ў А; 2. В ў С; 3. существует ФЗ

R.А R.С; 4. не существует ФЗ R.С R.А; 5. не существует ФЗ R.С R.B.

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

Отношение находится во второй нормальной форме, если она находится в первой нормальной форме, и при этом любой её атрибут, не входящий в состав первичного ключа, функционально полно зависит от первичного ключа. Функционально полная зависимость означает, что атрибут функционально зависит от всего первичного составного ключа, но при этом не находится в функциональной зависимости от какой-либо из входящих в него атрибутов (частей).

Или другими словами: в 2НФ нет не ключевых атрибутов, зависящих от части составного ключа.

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

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

3НФ — отношение находится в 3НФ, если оно находится во 2НФ и не содержит транзитивных зависимостей. Все отношения данной модели находятся в 3НФ, т.к. ни в одном из них нет транзитивных зависимостей.

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

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

Выводы по второй главе

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

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

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

Глава 3. Программная реализация БД магазина «Техноторг»

В данной главе проведем анализ и выбор СУБД. База данных магазина «ТехноТорг» содержит 10 таблиц, которые будут спроектированы в разделе Физическое проектирование БД. Также будут показаны скриншоты готовых таблиц. В конце главы буду написаны 3 триггера и показана их реализация.

3.1 Анализ и выбор СУБД

Oracle Application Express (сокращённо именуется как Oracle Apex, APEX, ранее называлась Oracle HTMLDB) — свободная среда быстрой разработки прикладного программного обеспечения на основе СУБД Oracle Database, целиком реализованная как веб-приложение. Все элементы, возникающие в цикле разработки приложения в данной среде хранятся непосредственно в инфраструктуре Oracle Database, тем самым обеспечивается совместная работа разработчиков и контроль версий без использования файлов и дополнительных систем управления версиями.

Oracle Application Express (Apex) — это инструмент ускоренной разработки Web приложений для базы данных Oracle. С Apex Вы можете создавать профессиональные приложения, даже с небольшим опытом программирования, Вам необходим только Web-браузер.

Ускоренная разработка обеспечивается за счет встроенных в Apex средств:

темы пользовательского интерфейса;
управление навигацией;
управление формами;
гибкие отчеты;

3.2 Физическое проектирование БД магазина «ТехноТорг»

На основе реляционной модели произведена программная реализация. База данных содержит 10 таблиц:

Продавец
Клиент
Заказ
Доставка
Менеджер
Продажа товара
Товар
Категории
Производитель
Содержание чека

Таблица Продавцы (SELLER)

Таблица Менеджер (MANAGER)

Таблица Клиенты (CLIENT)

Таблица Категории (CATEGORY)

Таблица Производитель (MAKER)

Таблица Товар (PRODUCT)

Таблица Продажа товара (CHEK_INFO)

Таблица Содержание чека (CHEK)

Таблица Доставка (DELIVERY)

Таблица Заказ (ORDERS)

3.3 Реализация ограничений

С базой данных могут работать 3 типа пользователей: администратор, менеджер и клиент.

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

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

Клиент может только просматривать необходимую ему информацию.

Для реализации ограничения «Бесплатная доставка при сумме заказа от 10 тысяч рублей» создадим завершающий триггер Orders_Trig.

Orders_Trig

AFTER INSERT OR UPDATE ON ORDERS FOR EACH ROW

BEGIN

new.SUMMA>10000 then

BEGIN

UPDATE DELIVERY SET Price_Delivery = 0 WHERE ID_Order=:new.ID_Order;

END;

END IF;
END;
Проверим его работу, изменив цену в 1 строке таблицы ORDERS. После изменения в таблице DELIVERY автоматически произошло изменение цены доставки на 0.

Второй триггер реализует подсчет «Сумма» чека в таблице «Продажа товара». Для этого нужно поле «Количество» из таблицы «Содержание чека» по «Коду товара» умножить на поле «Цена товара» из таблицы «Товар».

CREATE OR REPLACE TRIGGER Chek_T

CHEK_INFO

FOR EACH ROW

DECLARE pCost INT;

BEGIN

SELECT PRICE INTO pCost

FROM PRODUCT

ID_Product = :new.ID_Product;

UPDATE CHEK

Summa = pCost * :new.Kolichestvo

WHERE ID_Chek = :new.ID_Chek;

END;
После изменения или добавления информации в таблицу Продажа товара (CHEL_INFO), в таблице Содержание чека будет меняться Сумма.

Третий триггер: если страной производителя является Америка, то цена на его товар устанавливается на отметке 5000 р.

CREATE OR REPLACE TRIGGER Trig2

AFTER UPDATE ON MAKER FOR EACH ROW

BEGIN

:new.Country=’America’

BEGIN

UPDATE PRODUCT SET Price = ‘5000’

ID_Maker=:new.ID_Maker;

END;
END IF;
END;

3.4 Безопасность и контроль

Средства безопасности в Oracle можно разделить на две категории:

Безопасность доступа.
Безопасность данных.

Безопасность доступа.

В Oracle имеется целый ряд механизмов для идентификации и верификации пользователей. Самый простой из них — обязательное указание пользователем своих имени и пароля при каждом подключении. Эта верификация должна выполняться независимо от того, какое внешнее интерфейсное средство используется для доступа к базе данных. Идея состоит в том, чтобы допустить пользователей к работе со средствами базы данных только после того, как он установит санкционированное соединение с ней. Имя пользователя и пароль сверяются с указанными в таблице SYS.USERS, куда пароль заносится в зашифрованной форме.

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

Безопасность данных.

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

В Oracle имеются системные и объектные привилегии. Системные привилегии — это права на выполнение общих задач, таких как SELECT ANY TABLE и UPDATE ANY TABLE. Объектные привилегии относятся к действиям с определенными элементами базы данных — таблицами, представлениями и последовательностями. Для предоставления привилегий другому пользователю можно использовать оператор GRANT.

Выводы по третьей главе

В данной главе произведено физическое проектирование базы данных магазина “ТехноТорг”. Создано три триггера. Определены ограничения. Произведен анализ безопасности в СУБД Oracle.

Заключение

Курсовая работа посвящена разработке базы данных магазина “ТехноТорг”.

Решены следующие задачи:

Произведен системный анализ предметной области;
Построена инфологическая модель;
Построена реляционная модель;
Реализация базы данных в СУБД Oracle apex.

Разработана реляционная база данных, содержащая элементы автоматизации и обработки данных. В ее составе: 10 таблиц, 3 триггера.

Список литературы

[Электронный ресурс]//URL: https://inzhpro.ru/kursovaya/avtomatizirovannyie-bazyi-dannyih/

1. Воронова Л.И. «Лабораторный практикум по дисциплине “базы данных”» — Москва 2010г.

2. ГОСТ 2.105-95 Единая система конструкторской документации. Общие требования к текстовым документам

3. Гуриков С.Р. Введение в программирование на языке Visual C#: учебное пособие / С.Р. Гуриков. — М.: ФОРУМ: ИНФРА-М, 2013. — 448 с. — (Высшее образование. Бакалавриат).

4. Карпова Т.С. «Базы Данных» — Питер, 2002г. — Режим доступа:http://biblioteka.cc/index.php?newsid=74396

5. Компактная встраиваемая реляционная база данных SQLite: sqlite.org

6. Крёнке Д. «Теория и практика построения баз данных» — Питер, 2003г.-800с.

7. Левченко Ольга: [Электронный ресурс] Статья «Microsoft SQL Server» — режим доступа:http://bourabai.kz/dbt/servers/MicrosoftSQLServer.htm

8. Работа с MS Word в C# [Электронный ресурс]. — Режим доступа:http://wladm.narod.ru/C_Sharp/comword.html .

9. Свободная реляционная СУБД MySQL: mysql.com

10. Система управления реляционными базами данных разработанная корпорацией Microsoft: https://www.microsoft.com/en-us/server-cloud/products/sql-server/#fbid=JQk2DSKWQLz

11. СУБД Oracle:http://www.oracle.com/technetwork/database/database-t..

12. Microsoft Access — реляционная СУБД: https://products.office.com/ru-RU/access

Приложение

Программный код

Создание таблицы Клиенты

create table CLIENT (

ID_Client int PRIMARY KEY,

FIO varchar(25) NOT NULL,

Birth_Date date NOT NULL,

Phone varchar(20) NOT NULL,

Address varchar(50) NOT NULL,

ZIP int NOT NULL);

— Create Sequence ID_Cl Increment by 1 start with 1;

Insert into CLIENT (ID_Client, FIO, Birth_Date, Phone, Address, ZIP)

Values (ID_Cl.NextVal,’Shirokov V.N.’,TO_DATE(‘1980/01/01′,’YYYY/MM/DD’), ‘9183212115’, ‘Moscow, Volgogradskaya, 31-15′,’111352’);

Insert into CLIENT (ID_Client, FIO, Birth_Date, Phone, Address, ZIP)

Values (ID_Cl.NextVal,’Malaxova O.U.’, TO_DATE(‘1990/11/22′,’YYYY/MM/DD’), ‘9031823574’, ‘Moscow, Komsomolskaya, 64-12′,’196182’);

Insert into CLIENT (ID_Client, FIO, Birth_Date, Phone, Address, ZIP)

Values (ID_Cl.NextVal,’Nikolaev A.N.’, TO_DATE(‘1989/04/13′,’YYYY/MM/DD’), ‘9032183131’,’Moscow, Zelenaya, 25-18′,’315112′);

Создание таблицы Продавцы

create table SELLER (

ID_Seller int PRIMARY KEY,

FIO varchar(25) NOT NULL,

Birth_Date date NOT NULL,

Pasport int NOT NULL,

Phone varchar(20) NOT NULL,

Address varchar(50) NOT NULL,

Date_Priema date NOT NULL);

— Create Sequence ID_Sel Increment by 1 start with 1;

Insert into SELLER (ID_Seller, FIO, Birth_Date, Pasport, Phone, Address, Date_Priema)

Values (ID_Sel.NextVal,’Ivanov I.I.’, TO_DATE(‘1991/05/13′,’YYYY/MM/DD’),’6115348243′,’9051237816′,’Moscow, Aviamotornaya, 34-8′, TO_DATE(‘2015/02/05′,’YYYY/MM/DD’));

Insert into SELLER (ID_Seller, FIO, Birth_Date, Pasport, Phone, Address, Date_Priema)

Values (ID_Sel.NextVal,’Alekseeva N.D.’, TO_DATE(‘1987/04/21′,’YYYY/MM/DD’),’6211354218′,’9203211515′,’Moscow, Volgogradskaya, 7-64′, TO_DATE(‘2016/03/21′,’YYYY/MM/DD’));

Insert into SELLER (ID_Seller, FIO, Birth_Date, Pasport, Phone, Address, Date_Priema)

Values (ID_Sel.NextVal,’Smirnov N.I.’, TO_DATE(‘1990/09/21′,’YYYY/MM/DD’),’3208114586′,’9207421881′,’Moscow, Avtozavodskaya, 16-5′, TO_DATE(‘2015/01/17′,’YYYY/MM/DD’));

Insert into SELLER (ID_Seller, FIO, Birth_Date, Pasport, Phone, Address, Date_Priema)

Values (ID_Sel.NextVal,’Xoxlova I.V.’, TO_DATE(‘1987/02/01′,’YYYY/MM/DD’),’6512132476′,’9031283516′,’Tula, Biruzova, 13-17′, TO_DATE(‘2014/05/30′,’YYYY/MM/DD’));

Insert into SELLER (ID_Seller, FIO, Birth_Date, Pasport, Phone, Address, Date_Priema)

Values (ID_Sel.NextVal,’Krasnova E.A.’, TO_DATE(‘1992/08/29′,’YYYY/MM/DD’),’3842132115′,’9037422835′,’Moscow, Uznaya, 24-64′, TO_DATE(‘2016/09/24′,’YYYY/MM/DD’));

Создание таблицы Менеджеры

create table MANAGER (

ID_Manager int PRIMARY KEY,

FIO varchar(25) NOT NULL,

Birth_Date date NOT NULL,

Pasport int NOT NULL,

Phone varchar(20) NOT NULL,

Address varchar(50) NOT NULL,

Date_Priema date NOT NULL);

— Create Sequence ID_Man Increment by 1 start with 1;

Insert into MANAGER (ID_Manager, FIO, Birth_Date, Pasport, Phone, Address, Date_Priema)

Values (ID_Man.NextVal,’Rublev A.I.’, TO_DATE(‘1984/01/13′,’YYYY/MM/DD’),’1235748212′,’9035721801′,’Moscow, Svobodnaya, 30-2′, TO_DATE(‘2014/12/13′,’YYYY/MM/DD’));

Insert into MANAGER (ID_Manager, FIO, Birth_Date, Pasport, Phone, Address, Date_Priema)

Values (ID_Man.NextVal,’Ivanova A.M.’, TO_DATE(‘1987/04/20′,’YYYY/MM/DD’),’6117841211′,’9213151694′,’Moscow, Bolshaya, 18-24′, TO_DATE(‘2015/01/17′,’YYYY/MM/DD’));

Insert into MANAGER (ID_Manager, FIO, Birth_Date, Pasport, Phone, Address, Date_Priema)

Values (ID_Man.NextVal,’Soboleva I.N.’, TO_DATE(‘1991/12/03′,’YYYY/MM/DD’),’3151821322′,’9037541118′,’Moscow, Svobodi, 21-24′, TO_DATE(‘2015/08/02′,’YYYY/MM/DD’));

Insert into MANAGER (ID_Manager, FIO, Birth_Date, Pasport, Phone, Address, Date_Priema)

Values (ID_Man.NextVal,’Vitko A.G.’, TO_DATE(‘1990/10/10′,’YYYY/MM/DD’),’6215312418′,’9203182111′,’Moscow, Pushkina, 31-21′, TO_DATE(‘2016/09/15′,’YYYY/MM/DD’));

Создание таблицы Категории

create table CATEGORY (

ID_Category int PRIMARY KEY,

Name varchar(25) NOT NULL);

— Create Sequence ID_Cat Increment by 1 start with 1;