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

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

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

Федеральное агентство связи Ордена Труда Красного Знамени

Федеральное государственное образовательное бюджетное учреждение высшего образования

«Московский технический университет связи и информатики»

Кафедра «Интеллектуальные системы в управлении и автоматизации»

Курсовая работа

На тему: «Разработка базы данных для автоматизированной системы управления «Продажа компьютерной техники»»

Москва 2017



Оглавление

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

Приложение



Введение

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

Задачи курсового проекта:

· провести системный анализ предметной области «Магазин “ТехноТорг”»;

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

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

· описать требования, предъявляемые к разработке данной базы данных;

· разработать инфологическую модель базы данных;

· обосновать выбор модели данных и осуществить логическое проектирование базы данных;

· нормализовать спроектированную модель и составить схему базы данных;

· осуществить реализацию БД на выбранной СУБД;

Разрабатываемая автоматизированная система управления «Магазин “ТехноТорг”» является актуальной в связи с высокой потребностью в компьютерной технике.

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

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

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

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



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

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

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

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

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

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

· Ноутбуки

· Телефоны

· Планшеты

· Аксессуары

· Фотоаппараты

· Видеокамеры



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

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

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

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

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

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

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

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

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

· ФИО

· Дата рождения

· Паспортные данные

· Телефон

· Адрес

· Дата приема на работу

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

· ФИО

· Дата рождения

· Телефон

· Адрес

· Почтовый индекс

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

· ФИО

· Телефон

· Товар

· Количество товара

· Дата заказа

· Адрес доставки

· Дата доставки

· Стоимость доставки

· Стоимость заказа

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

· Наименование товара

· Категория

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

· Цена

· Срок гарантии

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

· Код чека

· Товар

· Количество

· Сумма

· Дата покупки

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

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

· домашние (настольные) СУБД - подходят для использования в домашних условиях и создания небольших баз данных;

· полупрофессиональные СУБД - в основном используются предприятиями малого бизнеса для проектирования баз данных обычных размеров;

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

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

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



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

· построитель таблиц;

· построитель экранных форм;

· построитель SQL-запросов (язык SQL в MS Access не соответствует стандарту ANSI);

· построитель отчётов, выводимых на печать.

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

Microsoft Jet Database Engine, которая используется в качестве движка базы данных MS Access является файл-серверной СУБД и потому применима лишь к приложениям, работающим с небольшими объёмами данных и при небольшом числе пользователей, одновременно работающих с этим данными. Непосредственно в Access отсутствует ряд механизмов, необходимых в многопользовательских БД, таких, например, как триггеры.

Встроенные средства взаимодействия 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 Enterprise Grid мощных многопроцессорных серверных систем, от отдельных кластеров до корпоративных распределенных вычислительных систем.

Oracle Database позволяет пользователям виртуализировать использование аппаратного обеспечения - серверов и систем хранения данных. Oracle Database обладает технологиями, которые позволяют администраторам надежно хранить и быстро распределять и извлекать данные для пользователей и приложений, работающих в сетях Grid. Oracle 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 Обзор продуктов аналогов АСУ «Продажа компьютерной техники»

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

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

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

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



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

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

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

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

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

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

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

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

· Администратор

· Менеджер

· Клиент

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

· вносить изменения в личные данные клиентов и работников

· добавлять или удалять информацию о товарах

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

· посматривать любую информацию

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

· просматривать информацию по чекам

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

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

· посматривать любую информацию

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

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

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

· работники не моложе 18 лет;

· у каждого сотрудника должны быть обязательно заполнены все данные;

· при заказе обязательно требуется заполнение полей ФИО и моб. Телефона;

· при заказе от 10 тыс. рублей доставка бесплатная.



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

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

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

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

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



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

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

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

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

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

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

· корректность схемы БД (Адекватное отображение моделированной ПО);

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

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

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

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

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

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

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

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

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

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

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

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

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

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



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

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

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

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

· сетевая модель;

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

· объектно-ориентированная модель;

· реляционная модель;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В реляционной модели достигается гораздо более высокий уровень абстракции данных, чем в иерархической или сетевой. Реляционная модель предоставляет средства описания данных на основе только их естественной структуры, т.е. без потребности введения какой-либо дополнительной структуры для целей машинного представления. Другими словами, представление данных не зависит от способа их физической организации. Это обеспечивается за счет использования математической теории отношений (само название "реляционная" происходит от английского relation - "отношение").

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

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



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

Многомерные структуры развивают реляционные модели данных и представляются как гиперкубы данных. Каждая грань куба является размерностью. Основными понятиями, используемыми в многомерных моделях данных, являются «измерение» и «ячейка». Наиболее подходящей моделью данных для этого случая является так называемая многомерная модель, используемая в технологии OLAP (OnLine Analytical Processing - оперативная аналитическая обработка). Отметим, что многомерность модели данных означает здесь многомерное логическое представление структуры информации и, вообще говоря, не связана с многомерностью визуализации.

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

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



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

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

· отсутствие дублируемой информации;

· поддержание целостности данных при вставке, удалении или изменении записей;

· возможность организации всех видов связи между отношениями 1:1, 1:M и M:M.

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

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

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

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

Процесс разработки корректной схемы РБД и является даталогическим проектированием. Возможны 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.

CREATE OR REPLACE TRIGGER Orders_Trig

AFTER INSERT OR UPDATE ON ORDERS FOR EACH ROW

BEGIN

IF :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

AFTER INSERT OR UPDATE ON CHEK_INFO

FOR EACH ROW

DECLARE pCost INT;

BEGIN

SELECT PRICE INTO pCost

FROM PRODUCT

WHERE ID_Product = :new.ID_Product;

UPDATE CHEK

SET 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

IF :new.Country='America' THEN

BEGIN

UPDATE PRODUCT SET Price = '5000'

WHERE 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 триггера.



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

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;

Insert into CATEGORY (ID_Category, Name)

Values (ID_Cat.NextVal, 'Telephone');

Insert into CATEGORY (ID_Category, Name)

Values (ID_Cat.NextVal, 'Notebook');

Insert into CATEGORY (ID_Category, Name)

Values (ID_Cat.NextVal, 'Planshet');

Insert into CATEGORY (ID_Category, Name)

Values (ID_Cat.NextVal, 'Aksessuari');

Insert into CATEGORY (ID_Category, Name)

Values (ID_Cat.NextVal, 'PhotoCamera');

Insert into CATEGORY (ID_Category, Name)

Values (ID_Cat.NextVal, 'VideoCamera');

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

create table MAKER (

ID_Maker int PRIMARY KEY,

Name varchar(25) NOT NULL,

Country varchar(25) NOT NULL,

Site varchar(50) NOT NULL,

Phone int NOT NULL);

Create Sequence ID_Maker Increment by 1 start with 1;

Insert into MAKER (ID_Maker, Name, Country, Site, Phone)

Values (ID_Maker.NextVal, 'ASUS','China','asus.ru','88001002787');

Insert into MAKER (ID_Maker, Name, Country, Site, Phone)

Values (ID_Maker.NextVal, 'Huawei','China','shop.huawei.ru','84953201221');

Insert into MAKER (ID_Maker, Name, Country, Site, Phone)

Values (ID_Maker.NextVal, 'Lenovo','China','lenovo.com','861058868888');

Insert into MAKER (ID_Maker, Name, Country, Site, Phone)

Values (ID_Maker.NextVal, 'Nikon','Japan','nikon.ru','84952216912');

Insert into MAKER (ID_Maker, Name, Country, Site, Phone)

Values (ID_Maker.NextVal, 'Canon','Japan','canon.ru','84952585601');

Insert into MAKER (ID_Maker, Name, Country, Site, Phone)

...