Разработка базы данных «Склад магазина оптовой продажи»

?????????? ? ????????? ??????????, ??????? ?????????? ? ???????.

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

????????? ???????????? ???????? ??????????? ?????????? ???? ?????? «????? ???????? ??????? ???????» ? ????? Access ? Delphi.

В качестве теоретической основы для курсового проекта использованы труды следующих авторов: В.А. Бородина, А.Д. Хоменко, А.Г. Фёдорова, А.В. Фёдорова, а также ряд других источников.

Курсовой проект или его элементы могут представлять интерес для предпринимателей занимающийся торговой деятельностью.

1 Этапы разработки Базы данных

1.1 Описание предметной области

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

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

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

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

1.2 Концептуальная модель и её описание

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

основе этого анализа реализуется конкретная модель в конкретной программной среде. Результаты каждого этапа проектирования используются в качестве исходного материала для следующего этапа. Анализируется текущая организация предприятия, выделяются проблемы для решения, определяются объекты и отношения между ними, составляется «эскиз» текущей организации предприятия, разрабатывается модель с учетом конкретных условий ее функционирования. База данных ориентирована на определенную предметную область, например: учёт товарной продукции, и организована на основе некоторого подмножества данных. Возможности баз данных полезны в областях, связанных с долговременным управлением информацией, таких как электронные библиотеки и хранилища данных. Предварительное планирование, подготовка данных, последовательность создания информационной модели. В первую очередь при проектировании системы обработки данных необходимо решить вопрос: «Как организовать данные?». Помочь понять организацию данных, призвана информационная модель. Процесс создания информационной модели начинается с определения концептуальных требований ряда пользователей. Концептуальные требования могут определяться и для некоторых задач (приложений), которые в ближайшее время реализовывать не планируется. Это может несколько повысить трудоемкость работы, однако поможет наиболее полно учесть все нюансы функциональности, требуемой для разрабатываемой системы, и снизит вероятность переделки в дальнейшем. Требования отдельных пользователей должны быть представлены в едином «обобщенном представлении». Последнее называют концептуальной моделью. Объект – это абстракция множества предметов реального мира, обладающих одинаковыми характеристиками и законами поведения. Объект представляет собой типичный неопределенный экземпляр такого множества. Объекты объединяются в классы по общим характеристикам. Например, в предложении «Белый Дом является зданием», «Белый Дом» представляет объект, а «здание» – класс. Классы обозначаются абстрактными существительными. Класс – это множество предметов реального мира, связанных общностью структуры и поведением.

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

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

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

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

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

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

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

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

Рисунок 1.1 – Концептуальная модель

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

Объект «Остатки» позволяет всегда быть в курсе имеющихся товаров на складе.

Объект «Единицы измерения» позволяет измерить товары в количественном эквиваленте.

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

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

1.3 Логическая модель

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

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

Рисунок 1.2 – Логическая модель

Как видно из логической схемы (см. рисунок 1.2), база данных будет состоять из следующих восьми сущностей:

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

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

3) клиенты – в данном случае под видом лица понимается поставщик или потребитель, в случае если клиент является поставщиком тогда ставиться галочка в поле «Вид лица».

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

5) товары – содержит список товаров, использующийся в различных операциях.

6) единицы измерения – в поле «Название» пишется полное название единицы измерения, например: «килограммы», а поле «СокрНазвание» его сокращённое название: «кг», это сделано для удобства и экономии места на формах ввода/вывода.

7) цены товара – Таблица хранит информацию обо всех ценах для товаров, которые были назначены на определённую дату.

8) остатки – содержится информация о товарах имеющихся в складских помещениях.

1.4 Физическая модель

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

Внешние модели никак не связаны с типом физической памяти, в которой

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

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

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

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

«Накладная», регистрирует приходные и расходные операции (см. таблицу 1.1.)

Таблица 1.1–Накладная

Для регистрации типа накладной используется логическое поле №3 (см.таблицу 1.1). В поле №6 будет ссылаться на таблицу «ОТВЕТСТВЕННЫЕ» по числовому значению. Поля №5 и №8 имеют тип дата/время.

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

Таблица 1.2–Накладные строки

Все поля таблицы за исключением цены и суммы, являются числовыми которые, по их значениям ссылаются на другие таблицы базы данных (далее БД). Поле №6 равно цене ед. товара, а поле №7 равно поле №4 умноженное на №7.

«Клиенты», содержит информацию о поставщиках и заказчиках (см. таблицу 1.3)

Таблица 1.3–Клиенты

В поле №2 имеющее тип логический отличает значением «истина» поставщика от клиента.

«Ответственные лица», через ключевое поле №1, эта таблица связывается с таблицей «накладные» (см. таблицу 1.4).

Таблица 1.4–Ответственные лица

«Товары» первичный ключ связывает таблицу с остальными (см. таблицу 1.5).

Таблица 1.5–Товары

Таблица «Единицы Измерения» (см. таблицу 1.6)

Таблица 1.6–Единицы Измерения

«Цены товара», Эта таблица предназначена для формирования продажной цены товаров (см. таблицу 1.7).

Таблица 1.7–Цены товара

«Остатки», здесь используются два первичных ключа которые поля №1 и №2 вместе они создают уникальное значение для записи (см. таблицу 1.8).

Таблица 1.8 – Остатки

Сделаем наиболее важные выводы по первым трем этапам проектирования БД.

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

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

2 проектирование приложений

2.1 Выбор среды программирования

Delphi – это попытка фирмы borland объединить лучшее, что было создано на тему визуального программиро­вания, в единый продукт. В Delphi мы имеем: среду для создания программ, напоминающую среду Visual Basic и включающую в себя средство для наглядного создания программ, и редактор для напи­сания кода. В Delphi практически все создаваемые программы яв­ляются объектно-ориентированными. В качестве языка был вы­бран Object Pascal – объектно–ориентированное расширение язы­ка третьего поколения Раsса1. Почему Pascal, а не язык C++, став­ший практически индустриальным стандартом? Все дело в том, что на язык Pascal нет стандарта. Точнее, есть ANSI-стандарт, принятый в начале 80-х годов. Отсутствие стандарта на язык позволяет разработчикам ком­пиляторов вносить в него необходимые расширения, что недопус­тимо, скажем, в С/С++. Если первые версии turbo Pascal ещё как-то следовали спецификации, предложенной Никлаусом Виртом, то далее стала заметна не только тенденция привязки языка к компьютеру, но и стремление сделать его гибким и удобным инструментом, которому «тесно» в рамках каких-либо стандартов.

С помощью Delphi можно создавать компоненты ActiveX без использования Microsoft IDL, расширять возможности web-сервера, практически ничего не зная об HTML, XML или ASP. Можно создавать Интернет- и intranet-приложения, используя для доступа к данным Borland DataBase Engine, ODBC-драйверы или Microsoft ADO.

Мощность и гибкость Delphi при работе с базами данных основана на
низкоуровневом ядре - процессоре баз данных Borland Database Engine (BDE).
Его интерфейс с прикладными программами называется Integrated Database
Application Programming Interface (IDAPI). В принципе. BDE позволяет
осуществлять доступ к данным как с использованием традиционного record-
ориентированного (навигационного) подхода, так и с использованием set-
ориентированного подхода, используемого в SQL-серверах баз данных. Кроме
BDE, Delphi позволяет осуществлять доступ к базам данных, используя
технологию Open DataBase Connectivity (ODBC) фирмы Microsoft.

Все инструментальные средства баз данных Borland - Paradox, dBase,
Database Desktop - используют BDE. Все особенности, имеющиеся в Paradox или
dBase, «наследуются» BDE, и поэтому этими же особенностями обладает и
Delphi.

Одним из преимуществ Delphi является то, что он поддерживает все SQL-БД, доступ к которым осуществляется через Borland Database Engine, ADO или драйверы InterBase. Через Borland SQL Links BDE так же возможен доступ к Oracle, Sybase, Informix, MS SQL Server, DB2 и InterBase

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

С помощью Access можно разрабатывать простые и удобные формы ввода данных, а также осуществлять обработку данных и выдачу сложных отчетов.
Access – мощное приложение Windows, впервые производительность СУБД органично сочетается с теми удобствами, которые имеются в распоряжении пользователей Microsoft Windows. Поскольку оба эти продукта, детища компании Microsoft, они прекрасно взаимодействуют между собой.
С помощью объектов OLE (Object Linking and Embedding – связывание и внедрение объектов) в Windows и компонентах Microsoft Office (Excel, Word, PowerPoint и Outlook) можно превратить Access в настоящую операционную

среду баз данных. С помощью новых расширений для Internet можно создавать формы, которые будут напрямую взаимодействовать с данными из World Wide Web, и транслировать их в представление на языке HTML, обеспечивающее работу с такими продуктами, как Internet Explorer и Netscape Navigator.
Как реляционная СУБД Access обеспечивает доступ ко всем типам данных и позволяет использовать одновременно несколько таблиц базы данных. Таблицу Access можно связать с данными, хранящимися на большой ЭВМ или на сервере.
Система Access – это набор инструментов конечного пользователя для управления базами данных. В ее состав входят конструкторы таблиц, форм, запросов и отчетов. Эту систему можно рассматривать и как среду разработки приложений. Используя макросы или модули для автоматизации решения задач, можно создавать ориентированные на пользователя приложения такими же мощными, как и приложения, написанные непосредственно на языках программирования.

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

2.2 Формы ввода-вывода информации

Программа, будет начинать работу с вывода главной формы, т.е. на котором будет «панель навигации» по другим формам (см. рисунок 2.1).

Рисунок 2.1 – Склад магазина

При наведении курсора на «Документы» выпадает меню с выбором документов, «Накладная», «Прайс-лист» и «Склад».

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

Справа от «Списков» кнопка «Выход из программы» при её нажатии приложение закроется.

При наведении мышки на слово «Списки» (см. рисунок 2.1) открывается субменю, которое предоставляет возможность выбрать одну из форм для ввода данных в БД.

Например, при выборе «Поставщики» в субменю «Клиенты», в «Списках». Откроется форма ввода данных о поставщиках (см. рисунок 2.2)

Рисунок 2.2–Поставщики

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

В поле «Название организации» вводиться название фирмы поставщика.

В поле «ФИО» вводиться фамилия руководителя фирмы.

В поле «Адрес» вводиться юридический адрес фирмы.

При нажатии кнопки «Отчёт» (см. рисунок) 2.2 программа выводит отчёт обо всех поставщиках товарной продукции (см. рисунок 2.3).

При наведении курсора мыши на «Документы» откроется субменю (см. рисунок 2.4)

Рисунок 2.3–Отчёт организации поставщики

«Накладные» приход и расход составляются с помощью разных форм

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

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

В форму вводятся три значения для полей:

1) товар;

2) дата;

3) цена.

При нажатии кнопки «Склад» выводится информация об имеющихся товарах на складе (см. рисунок 2.7).

Рисунок 2.7 – Отчёт склад

2.3 Схема взаимодействия по данным

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

В каждую таблицу вводяться данные через формы ввода: orgnz, FClients, otvetstvenie, edizm, pricelist, Tovar, rashod, prihod.

Многочисленные связи в схеме (см. приложение В), позволяют отследить взаимодействия форм и таблиц в базе данных. Так же используются формы вывода данных: otchprih, otchrash, otchTov, otchPris, otchediz, otchost, otchediz, otchotv, otchclts, otchorg.

2.4 Разработка запросов

Для соединения формы с таблицами использовался объект приложения Delphi, ADOConnections, который помещаю в DataModule.

ADOConnections подключается к базе данных. Поставщики данных (Provider) перечислены все доступные ADO драйверы доступа к базам данных: для Access используется драйвер Microsoft Jet OLE DB Provider. Такой драйвер обязательно устанавливается на машину вместе с MS Office, а в последних версиях Windows он устанавливается всегда по умолчанию. В новом окне с заголовком Form1.ADOTable1.ConnectionString нужно выбрать пункт Use Connection String затем, Build в вновь открывшемся окне указывается путь к своей базе данных.

Как только произошёл выбор нужной базы данных, необходимо проверить подключение, для этого нажимается кнопка «Проверить подключение» (Test Connection), чтобы протестировать соединение.

Следующий шаг, на форму устанавливается компонент DataSource с вкладки Data Access палитры компонентов. Теперь этому компоненту указывается таблица отображения: свойство DataSet–ADOTable1, который связан с таблицей. Все приготовления готовы, далее нужно приступить к реальному отображению данных. Самый простой способ отобразить таблицу – установить компонент DBGrid (Вкладка Data Controls). Этот компонент – сетка, которая может отображать данные в виде таблицы. DBGrid (см. рисунок 2.6). Так же есть другой способ отображения данных, с помощью компонента Delphi DBEdit, это так называемое поле (см. рисунок 2.2).

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

Чтобы отобразить форму ввода для «Прайс–листа» (см. рисунок 2.6), использовался следующий запрос:

SELECT ЦеныТовара.ЦенаТовара, ЦеныТовара.Товар, Товары.Название, ЦеныТовара.Дата, ЦеныТовара.Цен

FROM ЦеныТовара, Товары

WHERE ЦеныТовара.Товар=Товары.[Код товара]

ORDER BY Товары.Название;

Этот запрос был реализован в СУБД Access, он подключён через компонент Delphi ADOTeble, и компонент DataSet, данные выведены на форму с помощью DBGrid.

Запрос основан на двух таблицах: «ЦеныТовара», «Товары» которые объединены через «Код товара» и упорядочены по текстовому полю таблицы «Товары».

Раздел реквизитов формы «Накладная приход» основана на следующем запросе, созданном в СУБД Access:

SELECT Накладные.Накладная, Накладные.Номер, Накладные.Приход,

Накладные.Клиент, Накладные.Дата, Накладные.Ответственный,

Накладные.Комментарий, Накладные.Обработана

FROM Накладные

WHERE (((Накладные.Приход)=True) AND ((Накладные.Обработана) Is Null))

ORDER BY Накладные.Дата;

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

должно равняться значению Null. Это было сделано для того, чтобы человек вводящий данные мог работать только с необработанными накладными, т.е. с теми заказами, которые были сделаны, но не пришли ещё на склад (ожидаемыми поставками).

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

SELECT Клиенты.Клиент, Клиенты.[Вид лица], Клиенты.[Наименование общества], Клиенты.[Название орг], Клиенты.ФИО, Клиенты.Адрес, Клиенты.Телефон

FROM Клиенты

WHERE (((Клиенты.[Вид лица])=True))

ORDER BY Клиенты.[Название орг];

ЗАКЛЮЧЕНИЕ

? ?????? ?????????? ?????????? ????????? ??????? ???? ??????????? ????????? ???????: ????????????? ???? ????????? ????????, ????????????? ?????? ? ?????????????? ???? ??????, ?????????????? ???? ?????? ?????????? ?????, ???????? ??????? ?????????? ????? ??????.

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

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

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

- использование web-технологий для доступа к данным через Интернет;

- создание пользователей с определёнными правами доступа к данным;

- разработка дополнительных форм ввода/вывода информации о накладных.

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

Библиографический список

1. Бабаева Ю.А. Бухгалтерский учет. – М.: Юнити, 2002. – 237с.

2. Бородин В.А. Бухгалтерский учёт: Учебник для вузов. – 3-е изд.,

перераб. и доп. – М.: ЮНИТИ–ДАНА, 2004. – 528с.

3. Фёдоров А.В. ADO в Delphi. – Пер. с англ. – СПб.: БХВ–Петербург, 2002. – 816с.

4. Фёдоров А.Г. Создание Windows–приложений в среде Delphi. – М.: ТОО «Компьютер Пресс», 1995. – 287с.

5. Хоменко А.Д. Delphi 7. – СПб.: БХВ–Петербург, 2003. – 1216с.

6. Хоменко А.Д. Основы современных компьютерных технологий. – М.: ТОО «Компьютер Пресс», 2000г. – 467с.