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

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

• Запрос - объект, позволяющий пользователю получить нужные данные из одной или нескольких таблиц. Для определения запроса можно использовать конструктор отчётов или написать инструкцию SQL. Можно создать запрос на выборку, обновление, удаление или добавление данных. С помощью запросов можно также создавать новые таблицы, используя данные из одной или нескольких существующих таблиц.

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

• Отчёт - объект, предназначенный для форматирования, вычисления итогов и печати выбранных данных.

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

• Формирование пакета

• Подклассы

• Наследование

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

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

Так как VFP является современным приложением Windows, в распоряжении пользователя оказываются все возможности DDE (Dynamic Data Exchange, динамический обмен данными), OLE (Object Linking and Embedding, связь и внедрение объектов) и элементов управления ActiveX. DDE позволяет выполнять функции и производить обмен данными между VFP и любым другим, поддерживающим DDE приложением Windows. OLE является более совершенной технологией Microsoft, которая, в частности, позволяет устанавливать связи с объектами другого приложения или внедрять некоторые объекты в базу данных VFP. Это могут быть рисунки, диаграммы, электронные таблицы или документы из других приложений Widows, поддерживающих OLE.

VFP воспринимает множество самых разнообразных форматов данных, включая файловые структуры других СУБД. Существует возможность осуществления импорта и экспорта данных из текстовых и электронных таблиц. VFP предоставляет прямой доступ и позволяет обновлять файлы Paradox, dBase Ш, dBase IV, Microsoft Access и других баз данных. Можно также импортировать данные из этих файлов в таблицы VFP. В дополнение к этому, VFP может работать с наиболее популярными базами данных, поддерживающими стандарт ODBC (Open Database Connectivity - открытый доступ к данным), включая Microsoft SQL Server, Oracle, DB2.

Когда возникает необходимость коллективного использования информации, настоящая система управления базами данных позволяет защищать информацию от несанкционированного доступа так, что право просматривать данные или вносить в них изменения получают только определенные пользователи. Предназначенная для коллективного пользования СУБД имеет средства, не позволяющие нескольким людям одновременно изменять одни и те же данные. VFP спроектирован таким образом, что он может быть использован как в качестве самостоятельной СУБД на отдельной рабочей станции, так и в сети режима «клиент-сервер». Поскольку в VFP доступ к данным могут иметь одновременно несколько пользователей, в нем предусмотрены надежные средства защиты и обеспечения целостности данных. В VFP применяется механизм автоматической блокировки для избежания одновременного изменения объекта несколькими пользователями.

Глава 3. Разработка логической схемы.

Полноценное проектирование любого АРМ должно осуществляться согласно некоторым правилам или этапам проектирования.

Ниже приведены основные этапы проектирования АРМ, в соответствии с которыми будет осуществляться её дальнейшая разработка в среде Microsoft Visual FoxPro:

1. Логическое проектирование.

1. Определение цели создания АРМ

2. Определение таблиц и необходимых полей

3. Определение связей между таблицами

1. Разработка таблиц

2.1 Построение таблиц

1. Назначение типов данных для полей таблиц

2. Создание индексов и связей между таблицами

3.1 Логическое проектирование

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

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

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

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

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

3.1.1 Определение цели создания АРМ.

На первом этапе проектирования необходимо определить цель создания АРМ, основные функции и информацию, которую АРМ должен содержать, то есть нужно определить основные темы таблиц базы данных и содержащуюся в них информацию.

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

3.1.2 Определение таблиц и необходимых полей.

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

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

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

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

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

Д27	Дейт К. Руководство по реляционной СУБД DB2 / пер. с англ. И предисловие М.Р.Когаловского. –М.: Финансы и статистика, 1988. – 320 с.: ил.
	ISBN 5-279-00063-9
	Книга американского специалиста в области реляционных баз данных К.Дейта, автора популярной в СССР монографии «Введение в системы баз данных», представляет собой руководство по СУБД фирмы IBM DB2. Для специалистов по программному обеспечению информационных систем и студентов вузов.
	ББК 32.973

Рис. 3.1 Аннотированная каталожная карточка

• Автор (фамилия и имена (инициалы) или псевдонимы каждого автора издания);

• Название (заглавие) книги;

• Номер тома (части, книги, выпуска);

• Вид издания (сборник, монография, справочник,…);

• Составитель (фамилия и имена (инициалы) каждого из составителей издания);

• Под чей редакцией (фамилия и имена (инициалы) каждого из составителей издания);

• Повторность издания;

• Издательство;

• Место издания (город);

• Год выпуска;

• Издательская аннотация или реферат;

• Библиотечный шифр;

• Авторский знак.

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

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

К

1. Техника.Технические науки.

32 Радиоэлектроника.

32.97 Вычислительная техника.

32.973 Электронные вычислительные машины и устройства.

32.973.2 Электронно-вычислительные машины и устройства дискретного действия.

аждый из девяти классов (1.Марксизм-ленинизм; 2.Естественные науки; 3.Техника. Технические науки; 4.Сельское и лесное хозяйство; 5.Здравоохранение; 6/8.Общественные и гуманитарные науки; 9.Библиографические пособия. Справочные издания. Журналы.) делится на подклассы и следующие ступени деления:

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

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

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

• Номер (инвентарный номер) переплёта;

• Дата приобретения (поступления) конкретного переплёта;

• Номер читательского билета;

• Фамилия читателя;

• Имя читателя;

• Отчество читателя;

• Адрес читателя;

• Телефон читателя;

• Дата выдачи читателю конкретного переплёта;

• Дата возврата переплёта.

Анализ приведённых выше объектов и атрибутов позволяет выделить сущности проектируемой базы данных, приняв решение о создании реляционной базы данных, можно построить её модель.

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

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

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

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

• Информацию следует разбивать на наименьшие логические единицы.

Выделяем следующие таблицы и атрибуты:

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

2. Издательства (Код_издательства, Название, Город) – здесь находятся данные о названии издательства и городе, где расположено издательство. Так же вводим целочисленный атрибут Код_издания, который будет автоматически наращиваться на единицу при добавлении нового издания.

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

4. Раздел (Название_раздела, Библиотечный_код, Код_раздела, Код_родителя) – здесь хранятся данные о названии разделов, их коды по библиотечно-библиографическому классификатору и их взаимосвязи (ерархия). Так же вводим целочисленный атрибут Код_раздела, который будет автоматически наращиваться на единицу при добавлении нового раздела.

5. Издание (Код_издания, Код_раздела, Заглавие, Вид_издания, Авторский_знак, Код_издательства, Год_издания, Аннотация) – здесь хранится общая информация об экземпляре и его принадлежности к разделу. Так же вводим целочисленный атрибут Код_издания, который будет автоматически наращиваться на единицу при добавлении нового издания.

6. Переплёты (Номер_переплёта, Код_издания, Дата_приобретения) – здесь хранится информация о конкретном экземпляре (переплёте), такая как инвентарный номер, дата проибретения.

7. Группа (Код_группы, Название_группы, Код_родителя) – здесь хранятся данные о названии групп читателей, и их взаимосвязи (ерархия). Так же вводим целочисленный атрибут Код_группы, который будет автоматически наращиваться на единицу при добавлении нового группы.

8. Читатели (Номер_читателя, Код_группы, Код_фамилии, Код_имени, Код_отчества, Код_города, Код_улицы, Дом_Квартира, Номер_телефона, Дата_рождения, Дата_регистрации, Комментарий) – здесь хранится информация о читателе и его принадлежности к группе. Так же вводим целочисленный атрибут Номер_читателя, который будет автоматически наращиваться на единицу при добавлении нового читателя и будет являться номером читательского билета.

9. Авторы (Код_создателя, Код_издания) – эта таблица является ассоциацией между таблицами Создатели и Издание.

10. Составители (Код_создателя, Код_издания) – эта таблица является ассоциацией между таблицами Создатели и Издание.

11. Редакторы (Код_создателя, Код_издания) – эта таблица является ассоциацией между таблицами Создатели и Издание.

12. Выдача (Номер_переплёта, Номер_читателя, Дата_выдачи, Дата_сдачи) - эта таблица хранит ассоциации между таблицами Переплёт и Читатель.

13. Фамилии (Код_фамилии, Фамилия) – здесь хранятся данные о фамилиях читателей. Так же вводим целочисленный атрибут Код_фамилии, который будет автоматически наращиваться на единицу при добавлении новой фамилии.

14. Имена (Код_имени, Имя) – здесь хранятся данные об именах читателей. Так же вводим целочисленный атрибут Код_имени, который будет автоматически наращиваться на единицу при добавлении нового имени.

15. Отчества (Код_отчества, Отчество) – здесь хранятся данные об отчествах читателей. Так же вводим целочисленный атрибут Код_отчества, который будет автоматически наращиваться на единицу при добавлении нового отчества.

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

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

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

3.1.3 Определение связей между таблицами.

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