Теоретические аспекты проектирования БД
1 Этапы проектирования БД
Предметная область — часть реального мира, подлежащая изучению с целью организации управления и, в конечном счете, автоматизации. Предметная область представляется множеством фрагментов, например рассмотрим в соответствии с заданием работы, гостиницы — номера, сотрудники, услуги и т.д. Каждый фрагмент предметной области характеризуется множеством объектов и процессов, использующих объекты, а также множеством пользователей, характеризуемых различными взглядами на предметную область.
В теории проектирования информационных систем предметную область (или, если угодно, весь реальный мир в целом) принято рассматривать в виде трех представлений:
- представление предметной области в том виде, как она реально существует;
- как ее воспринимает человек (имеется в виду проектировщик базы данных);
- как она может быть описана с помощью символов.
Говорят, что мы имеем дело с реальностью, описанием (представлением) реальности и с данными, которые отражают это представление.
Данные, используемые для описания предметной области, представляются в виде трехуровневой схемы (так называемая модель ANSI/SPARC):
Внешнее представление (внешняя схема) данных является совокупностью требований к данным со стороны некоторой конкретной функции, выполняемой пользователем. Концептуальная схема является полной совокупностью всех требований к данным, полученной из пользовательских представлений о реальном мире. Внутренняя схема — это сама база данных.
Рисунок 1 — Трехуровневая схема
Отсюда вытекают основные этапы, на которые разбивается процесс проектирования базы данных информационной системы:
Концептуальное проектирование — сбор, анализ и редактирование требований к данным. Для этого осуществили следующие мероприятия:
- обследовали предметную область, изучив ее информационную
- выявили все фрагменты, каждый из которых характеризовался пользовательским представлением, информационными объектами и связями между ними, процессами над информационными объектами
- смоделировали и интегрировали все представления.
По окончанию данного этапа получили концептуальную модель, инвариантную к структуре базы данных. Часто она представляется в виде модели «сущность-связь».
Проектирование базы сжиженного газа для города Уральска с населением ...
... базы хранения сжиженного газа При проектировании баз сжиженного газа, выбор стационарных площадок и планировки сооружений руководствуется нормами проектирования, включающие основные положения правил проектирования, ... компрессорного способа перемещения сжиженных газов следующие : конструктивная простота схемы; полнота опорожнения ... для перекачки СУГ Исходные данные: Определить подачу компрессора для ...
Логическое проектирование — преобразование требований к данным в структуры данных. На выходе получили СУБД-ориентированную структуру базы данных и спецификации прикладных программ. На этом этапе смоделировали базы данных и провели сравнительный анализ моделей.
Физическое проектирование — определение особенностей хранения данных, методов доступа и т.д.
1.2 Описание модели данных
Создавая базу данных, мы стремились упорядочить информацию по различным признакам для того, чтобы потом извлекать из нее необходимые нам данные в любом сочетании. Сделать это возможно, только если данные структурированы. Структурирование — это набор соглашений о способах представления данных. Структурировать информацию можно по-разному. В зависимости от структуры различают иерархическую, сетевую, реляционную, объектно-ориентированную и гибридную модели баз данных.
Иерархическая структура базы данных — это древовидная структура представления информации. Ее особенность в том, что каждый узел на более низком уровне имеет связь только с одним узлом на более высоком уровне. Посмотрим, например, на фрагмент иерархической структуры базы данных «Институт»:
Рисунок 2 — Фрагмент иерархической структуры данных
Из структуры понятно, что на одной кафедре может работать несколько преподавателей. Такая связь называется «один ко многим» (одна кафедра — много преподавателей).
Но если мы попытаемся добавить в эту структуру группы студентов, то нам понадобится связь «многие ко многим»: (один преподаватель может работать со многими группами, а одна группа может учиться у многих преподавателей), а такой связи в иерархической структуре быть не может (т.к. связь может быть только с одним узлом на более высоком уровне).
Это основной недостаток подобной структуры базы данных.
Рисунок 3 — Связь многие — ко — многим
Сетевая структура базы данных. По сути, это расширение иерархической структуры. Все то же самое, но существует связь «многие ко многим». Сетевая структура базы данных позволяет нам добавить группы в наш пример. Недостатком сетевой модели является сложность разработки серьезных приложений.
Реляционная структура базы данных . Все данные представлены в виде простых таблиц, разбитых на строки и столбцы, на пересечении которых расположены данные. Эта структура стала настоящим прорывом в развитии баз данных.
Объектно-ориентированные и гибридные базы данных. В объектно-ориентированных базах данных данные хранятся в виде объектов, что очень удобно. Но на сегодняшний день такие БД еще распространенны, т.к. уступают в производительности реляционным.
Гибридные БД совмещают в себе возможности реляционных и объектно-ориентированных, поэтому их часто называют объектно-реляционными.
Каждый этап строится на предыдущем и если что — возвращается к нему.
Концептуальная модель представляет объекты и их взаимосвязи без указания способов их физического хранения. Концептуальная модель включает описания объектов и их взаимосвязей, представляющих интерес в рассматриваемой предметной области и выявляемых в результате анализа данных.
Гидродинамическое моделирование объекта ЮВ 1 Тайлаковского месторождения
... месторождения. Выявлена и подготовлена к бурению структура Северная. Далее в центральной части месторождения ... моделей относят геологические модели. В динамических же моделях свойства модели зависят от времени. Представителем данного типа моделей являются гидродинамические (фильтрационные) модели. ... ВНК, за обводненностью скважин. Полученные данные периодически подвергаются комплексной обработке и ...
Концептуальная модель транслируется затем в модель данных, совместимую с выбранной СУБД.
Версия концептуальной модели, которая может быть обеспечена конкретной СУБД, называется логической моделью.
Физическая модель, определяющая размещение данных, методы доступа и технику индексирования, называется внутренней моделью системы.
Внешние модели никак не связаны с типом физической памяти, в которой будут храниться данные, и с методами доступа к этим данным. Это положение отражает первый уровень независимости данных. Если концептуальная модель способна учитывать расширение требований к системе в будущем, то вносимые в нее изменения не должны оказывать влияния на существующие внешние модели. Это — второй уровень независимости данных. Построение логической модели обусловлено требованиями используемой СУБД. Поэтому при замене СУБД она также может измениться.
Основное различие между указанными выше тремя типами моделей данных (концептуальной, логической и физической) состоит в способах представления взаимосвязей между объектами.
Иерархическая модель данных строится по принципу иерархии типов объектов, то есть один тип объекта является главным, а остальные, находящиеся на низших уровнях иерархии, — подчиненными. Между главным и подчиненными объектами устанавливается взаимосвязь «один ко многим». Иными словами, для данного главного типа объекта существует несколько подчиненных типов объекта. В то же время для каждого экземпляра главного объекта может быть несколько экземпляров подчиненных типов объектов.
Узлы и ветви образуют иерархическую древовидную структуру. Узел является совокупностью атрибутов, описывающих объект. Наивысший в иерархии узел называется корневым (это главный тип объекта).
Корневой узел находится на первом уровне. Зависимые узлы (подчиненные типы объектов) находятся на втором, третьем и т. д. уровнях.
Недостатки: из нижних уровней иерархии нельзя направить информационный поиск по вышележащим узлам.
В сетевой модели данных понятия главного и подчиненных объектов несколько расширены. Любой объект может быть и главным и подчиненным (в сетевой модели главный объект обозначается термином «владелец набора», а подчиненный — термином «член набора»).
Один и тот же объект может одновременно выступать и в роли владельца, и в роли члена набора. Это означает, что каждый объект может участвовать в любом числе взаимосвязей.
В реляционной модели данных объекты и взаимосвязи между ними представляются с помощью таблиц. Взаимосвязи также рассматриваются в качестве объектов. Каждая таблица представляет один объект и состоит из строк и столбцов. В реляционной базе данных каждая таблица должна иметь первичный ключ (ключевой элемент) — поле или комбинацию полей, которые единственным образом идентифицируют каждую строку в таблице. Благодаря своей простоте и естественности представления реляционная модель получила наибольшее распространение в СУБД для персональных компьютеров. В ходе создания БД Гостиницы использовали реляционную модель данных.
1.3 Основные проблемы проектирования реляционных БД
Проблема проектирования реляционной базы данных состоит в обоснованном принятии решений о том, из каких отношений должна состоять БД и какие атрибуты должны быть у этих отношений.
В классическом подходе весь процесс проектирования базы данных осуществляется в терминах реляционной модели данных методом последовательных приближений к удовлетворительному набору схем отношений. Исходной точкой является представление предметной области в виде одного или нескольких отношений, и на каждом шаге проектирования производится некоторый набор схем отношений, обладающих «улучшенными» свойствами. Процесс проектирования представляет собой процесс нормализации схем отношений, причем каждая следующая нормальная форма обладает свойствами, в некотором смысле, лучшими, чем предыдущая.
модель база данный аэропорт
2. Инфологическое проектирование ПО
2.1 Определение сущностей
Прежде, чем приступать к созданию системы автоматизированной обработки информации, Были сформированы понятия о предметах, фактах и событиях, которыми оперирует данная система. Для этого было заменено их информационное представление. Одним из наиболее удобных инструментов унифицированного представления данных, независимого от реализующего его программного обеспечения, является модель «сущность-связь» (entity-relationship model, ER-model).
Модель «сущность-связь» основывается на некой важной семантической информации о реальном мире и предназначена для логического представления данных. Она определяет значения данных в контексте их взаимосвязи с другими данными. Важным является тот факт, что из модели «сущность-связь» могут быть порождены все существующие модели данных (иерархическая, сетевая, реляционная, объектная), поэтому она является наиболее общей.
Модель «сущность-связь» не является моделью данных в строгом смысле, поскольку не определяет операций над данными и ограничивается описанием только их логической структуры.
Любой фрагмент предметной области может быть представлен как множество сущностей, между которыми существует некоторое множество связей.
Сущность (entity) — это объект, который может быть идентифицирован неким способом, отличающим его от других объектов.
Вабор сущностей (entity set) — множество сущностей одного типа(обладающих одинаковыми свойствами).
Сущность фактически представляет из себя множество атрибутов, которые описывают свойства всех членов данного набора сущностей.
Спецификация сущностей представлена в таблице 1. В первом столбце таблицы указано наименование сущности. Во втором столбце описательные атрибуты.
Таблица 1
Спецификация сущностей
|
Сущность |
Описательные атрибуты |
|
Услуги |
Номер, код услуги, описание, стоимость |
|
Клиент |
ФИО, паспортные данные, дата заселения, дата выезда, код номера, стоимость, код клиента |
|
Номер |
Код сотрудника, код номера, вместимость, описание, стоимость, наименование |
|
Сотрудники |
Код сотрудника, ФИО, возраст, пол, адрес, Телефон, паспортные данные, код должности |
|
Должности |
Код должности, наименование должности, оклад, требования |
2.2 Описание атрибутов
Атрибут представляет собой свойство сущности. Это понятие аналогично понятию атрибута в отношении.
Ключ сущности — атрибут или набор атрибутов, используемый для идентификации экземпляра сущности.
Спецификация атрибутов сущностей представлена в таблице 2. В первом столбце таблицы указано название сущности. Во втором — наименование атрибута. В третьем столбце указывается тип атрибута.
Таблица 2
Спецификация атрибутов
|
Сущность |
Атрибут |
Тип |
|
Услуги |
Код услуги |
Счетчик |
|
Стоимость |
Денежный |
|
|
Описание |
Текстовый |
|
|
Номер |
Числовой |
|
|
Клиент |
Паспортные данные |
Числовой |
|
ФИО |
Текстовый |
|
|
Дата заселения |
Дата/время |
|
|
Дата выезда |
Дата/время |
|
|
Код номера |
Числовой |
|
|
Стоимость |
Денежный |
|
|
Код клиента |
Числовой |
|
|
Номер |
Счетчик |
|
|
Стоимость |
Денежный |
|
|
Код сотрудника |
Числовой |
|
|
Описание |
Мастер подстановок |
|
|
Наименование |
Текстовый |
|
|
Вместимость |
Мастер подстановок |
|
|
Сотрудники |
Код сотрудника |
Счетчик |
|
ФИО |
Текстовый |
|
|
Возраст |
Числовой |
|
|
Пол |
Мастер подстановок |
|
|
Адрес |
Текстовый |
|
|
Телефон |
Числовой |
|
|
Паспортные данные |
Числовой |
|
|
Код должности |
Числовой |
|
|
Должности |
Код должности |
Счетчик |
|
Наименование должности |
Текстовый |
|
|
Оклад |
Денежный |
|
|
Обязанности |
Текстовый |
|
|
Требования |
Текстовый |
3 Установление связей между типами сущностей
Спецификация связей между сущностями представлена в таблице 3. В первом столбце указан тип связи, где буква M означает «многие». Во втором столбце указано название первой сущности связи, в третьем — название второй сущности связи.
Таблица 3
Спецификация связей
|
Тип связи |
Первая сущность |
Вторая сущность |
Поля связи |
|
1:М |
Должности |
Сотрудники |
Код должности |
|
1:М |
Сотрудники |
Номер |
Код сотрудника |
|
1:М |
Номер |
Клиенты |
Код номера |
|
1:М |
Связь |
Клиенты |
Код клиента |
|
1:М |
Услуги |
Связь |
Код услуги |
4 Нормализация БД
Нормализацией схемы базы данных называется процедура, производимая над базой данных с целью удаления в ней избыточности.
Нормализация несет с собой немало преимуществ. Очевидно, что в нормализованной базе данных уменьшается вероятность возникновения ошибок, она занимает меньше места на жестком диске и т.д.
Определенный набор отношений обладает лучшими свойствами при включении, модификации, удалении данных, чем все остальные возможные наборы отношений, если он отвечает требованиям нормализации отношений.
Нормализация отношений — формальный аппарат ограничений на формирование отношений (таблиц), который позволяет устранить дублирование, обеспечивает непротиворечивость хранимых в базе данных, уменьшает трудозатраты на ведение (ввод, корректировку) базы данных.
Выделили три нормальные формы отношений и предложили механизм, позволяющий любое отношение преобразовать к третьей (самой совершенной) нормальной форме.
- Первая нормальная форма:
Отношение называется нормализованным или приведенным к первой нормальной форме, если все его атрибуты простые (далее неделимы).
Преобразование отношения к первой нормальной форме может привести к увеличению количества реквизитов (полей) отношения и изменению ключа.
Все отношение БД Гостиницы наводится в первой нормальной форме.
- Вторая нормальная форма:
Чтобы привести отношений ко второй нормальной форме, необходимо дать пояснения к таким понятиям, как функциональная зависимость и полная функциональная зависимость.
Описательные реквизиты информационного объекта логически связаны с общим для них ключом, эта связь носит характер функциональной зависимости реквизитов.
Функциональная зависимость реквизитов — зависимость, при которой экземпляре информационного объекта определенному значению ключевого реквизита соответствует только одно значение описательного реквизита.
Такое определение функциональной зависимости позволяет при анализе всех взаимосвязей реквизитов предметной области выделить самостоятельные информационные объекты.
В случае составного ключа вводится понятие функционально полной зависимости.
Функционально полная зависимость не ключевых атрибутов заключается в том, что каждый не ключевой атрибут функционально зависит от ключа, но не находится в функциональной зависимости ни от какой части составного ключа.
Отношение БД Гостиницы находиться во второй нормальной форме, так как оно находится в первой нормальной форме, и каждый не ключевой атрибут функционально полно зависит от составного ключа.
- Третья нормальная форма:
Понятие третьей нормальной формы основывается на понятии не транзитивной зависимости.
Транзитивная зависимость наблюдается в том случае, если один из двух описательных реквизитов зависит от ключа, а другой описательный реквизит зависит от первого описательного реквизита.
Отношение находиться в третьей нормальной форме, так как оно находится во второй нормальной форме, и каждый не ключевой атрибут не транзитивно зависит от первичного ключа.
Для устранения транзитивной зависимости описательных реквизитов необходимо провести «расщепление» исходного информационного объекта. В результате расщепления часть реквизитов удаляется из исходного информационного объекта и включается в состав других (возможно, вновь созданных) информационных объектов.
2.5 Построение инфологической модели ПО (Предметной области)
Для построения инфологической модели данных определим сущности их связи и атрибуты.
Определим сущности:
1. Услуги, потребляемые клиентами;
2. Клиенты, имеющие номера;
- Номера, которые обслуживают сотрудники;
- Сотрудники, имеющие должности;
- Дополнительные данные.
Опишем атрибуты сущностей для каждой в отдельности:
- Услуги, потребляемые клиентами:
- Код услуги;
- Стоимость;
- Описание;
- Номер.
- Клиенты, имеющие номера:
- Паспортные данные;
- ФИО;
- Дата заселения;
- Дата выезда;
- Код номера;
- Код клиента;
- Стоимость;
- Номера, которые обслуживают сотрудники:
- Код номера;
- Вместимость;
- Наименование;
- Описание;
- Стоимость;
- Код сотрудника.
- Сотрудники, имеющие должности
- Код сотрудника;
- ФИО;
- Возраст;
- Пол;
- Адрес;
- Телефон;
- Паспортные данные;
- Код должности.
- Дополнительные данные:
- Код должности;
- Наименование должности;
- Оклад;
- Обязанности;
- Требования.
Построим инфологическую модель по определенным сущностям (рис.4):
Рисунок 4 — Инфологическая модель данных
3. Выбор СУБД
Важнейшей характеристикой любой СУБД является используемый в ней тип транслятора (интерпретатор или компилятор).
Программы написанные для системы интерпретатора исполняются лишь в присутствии самой системы. В настоящее время скорость работы таких программ не уступает скорости программ сгенерированных компилятором. Бесспорным преимуществом интерпретаторов для программистов является удобство в разработке и отладки программных продуктов, а так же при освоении языка. СУБД dBASE, FoxPro, Access являются интерпретаторами, а Clipper- компилятором.
К основным возможностям СУБД microsoft access можно отнести следующие:
Проектирование базовых объектов — двумерные таблицы с полями разных типов данных.
Создание связей между таблицами, с поддержкой целостности данных, каскадного обновления полей и каскадного удаления записей.
Ввод, хранение, просмотр, сортировка, изменение и выборка данных из таблиц с использованием различных средств контроля информации, индексирования таблиц и аппарата алгебры логики.
На Access можно делать все что угодно и даже больше (конечно, в рамках предназначения среды).
Access — современная среда разработки, идущая в ногу со временем т.е. самая богатая корпорация никогда не бросит поддерживать и развивать Access (да и весь пакет Office) поэтому базы данных и интерфейс на MS Access будут всегда
К недостаткам СУБД Microsoft Access можно отнести следующие:
Размер файла MS Access не может превышать 2 ГБ.
- Для корректной работы интерфейса на MS Access порой необходима регистрация различ ныхбиблиотек <#»524743.files/image005.gif»>
Рисунок 5 — Даталогическая модель данных
5. Описание средств обеспечения целостности данных
Обеспечение защиты данных на рабочих ЭВМ:
- Защита содержания данных объединяет функции, процедуры и средства защиты, которые предупреждают несанкционированное раскрытие конфиденциальных данных и информации в БД.
- Средства контроля доступа разрешают доступ к данным только полномочных объектов в соответствии со строго определенными правилами и условиями.
- Управление потоком защищенных данных при передаче из одного сегмента БД в другой обеспечивает перемещение данных вместе с механизмами защиты, присущими исходным данным.
- Предотвращение возможности выявления конфиденциальных значений из данных, содержащихся в регулярных или статистических БД, в результате выявления статистически достоверной информации.
— Контроль согласованности при использовании БД предполагает процедуры, которые обеспечивают защиту и целостность отдельных элементов-данных, в частности их значений (зависимость от значений).
Успешная реализация таких процедур означает, что данные в БД всегда логически связаны и значения критических данных передаются от узла к узлу только при наличии специальных полномочий.
— Контекстная защита данных, характерная для схем защиты динамических БД, также должна быть включена в состав процедур защиты БД. В этом случае защита отдельного элемента БД в каждый данный момент времени зависит от поведения всей системы защиты, а также предшествующих операций, выполненных над этим элементом (зависимость от предыстории).
— Предотвращение создания несанкционированной информации предполагает наличие средств, которые предупреждают, что объект получает (генерирует) информацию, превышающую уровень прав доступа, и осуществляет это, используя логическую связь между данными в БД.
6. Разработка средств обеспечения безопасности данных
Установка защиты на уровне пользователей.
Процесс установки защиты можно разделить на этапы:
- создание файла рабочей группы и подключение к нему Access ;
- назначение владельца базы данных и ее объектов;
- создание учетных записей групп и пользователей в рабочей группе;
- назначение разрешений на доступ к объектам базы данных.
Установить защиту можно с помощью Мастера защиты или самостоятельно средствами Access.
7. Реализация запросов на SQL
Microsoft SQL Server — система управления реляционными базами данных (СУБД) <#»524743.files/image006.gif»>
Рисунок 6 — Реализация Запроса Должности на SQL
Рисунок 7 — Реализация Запроса Дорогие номера на SQL
Рисунок 8 — Реализация Запроса Клиенты на SQL
Рисунок 9 — Реализация Запроса Номера гостиницы на SQL
Рисунок 10 — Реализация Запроса Отдел кадров SQL
8. Описание программного средства
8.1 Требования к аппаратному и программному обеспечению
Конечная цель выполнения любой программы — управление аппаратными средствами. Программное и аппаратное обеспечение работают в непрерывном взаимодействии, и их разделение является довольно условным.
Между программами, также как между аппаратными средствами, существует взаимосвязь, поэтому можно говорить о программном интерфейсе. Программный интерфейс основан на протоколах — соглашениях о взаимодействии программ. Всё программное обеспечение вычислительной системы разбивается на несколько взаимодействующих между собой уровней (рис. 11).
Каждый следующий уровень опирается на программное обеспечение предшествующих уровней. Такое разделение программного обеспечения упрощает разработку и эксплуатацию программ. Каждый следующий уровень повышает функциональные возможности всей системы.
Рисунок — 11. Уровни программного обеспечения
Требование к программному обеспечению аппаратным средствам для работы с данной программой минимальны, в основном каждый современный ПК им удовлетворяет.
8.2 Функциональное назначение программы
Функциональным назначением данной программы является разработка и создание баз данных, которые хранят, обрабатывают и проверяют информацииб. Затем на основе разработанной базы данных можно создавать отчеты, формы, запросы. Просмотреть запросы с фильтром.
8.3 Входные данные
Входными данными данной работы являются таблицы (Услуги, Клиенты, Номера, сотрудники, Должности) приведенные в приложении 1(рис. 12-17).
8.4 Выходные данные
Выходными данными являются отчеты, фильтры и гистограмма приведенная в приложении 6.
На сегодняшний день реляционные базы данных остаются самыми распространенными, благодаря своей простоте и наглядности как в процессе создания так и на пользовательском уровне.
Основным достоинством реляционных баз данных совместимость с самым популярным языком запросов SQL. С помощью единственного запроса на этом языке можно соединить несколько таблиц во временную таблицу и вырезать из нее требуемые строки и столбцы (селекция и проекция).
Так как табличная структура реляционной базы данных интуитивно понятна пользователям, то и язык SQL является простым и легким для изучения. Реляционная модель имеет солидный теоретический фундамент, на котором были основаны эволюция и реализация реляционных баз данных. На волне популярности, вызванной успехом реляционной модели, SQL стал основным языком для реляционных баз данных.
В процессе анализа вышеизложенной информации выявлены следующие недостатки рассмотренной модели баз данных:
- так как все поля одной таблицы должны содержать постоянное число полей заранее определенных типов, приходится создавать дополнительные таблицы, учитывающие индивидуальные особенности элементов, при помощи внешних ключей. Такой подход сильно усложняет создание сколько-нибудь сложных взаимосвязей в базе данных;
— высокая трудоемкость манипулирования информацией и изменения связей.
Список литературы
[Электронный ресурс]//URL: https://drprom.ru/diplomnaya/proekt-nebolshogo-aeroportaskachat/
1. Информатика. Базовый курс / Симонович С.В. и др. — СПб: Издательство «Питер», 2000. — 640с.
2. Информатика. Учебное пособие / Под ред. В.Г. Кирия. — Иркутск: ИрГТУ,2003 часть 2. — 382с.
— Информатика. Учебное пособие /Ломтадзе В.В., Шишкина Л.П. — Иркутск: ИрГТУ, 2005. — 116с.
4. Богумирский Б. Эффективная работа на IBM PC в среде Windows 95 СПб, «Питер», 1997.
5. Вейскас Д. Эффективная работа с Microsoft Access 7.0 «Microsoft Press», 1997.
— Вудкок Дж., Янг М. Эффективная работа с Microsoft Office 95 «Microsoft Press».
— Горев А., Макашарипов С., Эффективная работа с СУБД: СПб, «Питер», 1997.
— Кириллов В.В. Основы проектирования реляционных баз данных. Учебное пособие. — СПб.: ИТМО, 1994.
— Потапкин А.В. Основы Visual Basic для пакета Microsoft Office:М, «Эком», 1995.
— Журнал «PC Magazine Russian Edition» 17, 1994, статья У. Плейна, «Microsoft Access».
11. Журнал «PC Magazine Russian Edition» 15, 1994.
12. Журнал «КомпьюТерра» №37-38 1994.
13. #»524743.files/image012.gif»>
Приложение 2
Приложение 3
Приложение 4
