Структура базы данных

Проектирование структуры базы данных ведется за четыре этапа.

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

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

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

Физическое проектирование состоит в размещении спроектированных таблиц БД на ЭВМ в формате выбранной СУБД.

Этап 1. Построение вербальной (описательной) модели данных.

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

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

Табл. Данные, необходимые для формирования справок и документов.

№ п/п.	Информационный элемент.	Данные.
1.	Справка «Поиск владельца по номеру участка» .	— Номер участка — Лицевой счет владельца — Фамилия, имя, отчество владельца — Дата рождения — Паспортные данные — Домашний адрес — Телефон — Наличие льгот
2.	Справка «Поиск участка по владельцу» .	— Фамилия, имя, отчество владельца — Номер участка — Дата вступления (покупки) — Статус участка (приватизирован/не приватизирован, в залоге и т. д.) — Площадь участка (в сотках) — Строения на участке — Подключение воды — Подключение света — Садовые насаждения — Параметры огородного участка
3.	Справка «Выплаты по участку» .	— Номер участка — Лицевой счет владельца — Фамилия, имя, отчество владельца — Назначение платежа — Дата платежа — Сумма платежа
4.	Отчет «Члены садового кооператива» .	— Лицевой счет владельца — Фамилия, имя, отчество владельца — Дата рождения — Паспортные данные — Домашний адрес — Телефон — Наличие льгот
5.	Отчет «Садовые участки» .	— Фамилия, имя, отчество владельца — Лицевой счет владельца — Номер участка — Дата вступления (покупки) — Статус участка (приватизирован/не приватизирован, в залоге и т. д.) — Площадь участка (в сотках) — Строения на участке — Подключение воды — Подключение света — Садовые насаждения — Параметры огородного участка
6.	Отчет «Оплата вступительных, членских и целевых взносов.	— Номер участка — Лицевой счет владельца — Фамилия, имя, отчество владельца — Назначение платежа — Дата платежа — Сумма платежа

Таким образом, получим следующую структуру данных.

• — Номер участка
• — Лицевой счет владельца
• — Фамилия, имя, отчество владельца
• — Дата рождения
• — Паспортные данные
• — Домашний адрес
• — Телефон
• — Наличие льгот

— Дата вступления (покупки).

— Статус участка (приватизирован/не приватизирован, в залоге и т. д.).

— Площадь участка (в сотках).

— Строения на участке.

— Подключение воды.

• — Подключение света
• — Садовые насаждения
• — Параметры огородного участка

— Назначение платежа.

— Дата платежа.

— Сумма платежа Этап 2. Концептуальное проектирование На данном этапе необходимо построить концептуальную модель данных, которая не зависит от методов последующей реализации БД.

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

• — садовые участки;
• — члены кооператива;
• — выплаты взносов.

Рис. 6 Основные объекты предметной области

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

На данном рисунке приведена концептуальная модель данных в виде модели «сущность-связь». Ключевые атрибуты объектов на рисунке выделены подчеркиванием. Следует отметить, что если один член кооператива приобрел 2 и более участка, то для бухгалтерии это будут разные экземпляры объекта «Член кооператива» с разными лицевыми счетами несмотря на идентичность остальных параметров.

Этап 3. Логическое проектирование Логическое проектирование БД по сути состоит из трех подэтапов:

NLS.

NOM.

DATA.

STATUS.

SQUARE.

STROIKA.

VODA.

SVET.

SAD.

OGOROD.

C.

C.

D.

C.

N.

C.

C.

C.

C.

C.

• 5
• 5
• 8
• 30
• 5,1
• 30
• 30
• 30
• 30
• 30

• — Лицевой счет владельца
• — Номер участка
• — Дата вступления (покупки)
• — Статус участка
• — Площадь участка (в сотках)
• — Строения на участке
• — Подключение воды

• — Подключение света
• — Садовые насаждения
• — Параметры огородного участка

Таблица «Plata» — содержит данные об оплате членских, целевых и вступительных взносах.

Поле.	Тип.	Размер
NOM. VID. DATA. SUMMA.	C. C. D. N.	5 30 8 10,2	— Номер участка — Назначение платежа — Дата платежа — Сумма платежа

Этап 4. Физическое проектирование На данном этапе выполняется выбор СУБД и размещение таблиц на физических носителях. Кроме того, могут определяться способы организации доступа к информации на уровне обработки данных в СУБД. При этом создаются дополнительные виртуальные поля, триггеры, генераторы, встраиваемые функции, представления.

Приведенные выше таблицы были реализованы в самом популярном среди табличных СУБД на сегодняшний день формате — «dbf» (версия DBASE IV).

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

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

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

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

Программно это не представляет больших трудностей. Однако, есть два больших недостатка.

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

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

Поэтому наиболее предпочтительным является применение по возможности LookUp-полей.

В данной БД целесообразно добавить следующие LookUp-поля;

• 1. В таблицу «Ludi» добавить поле «Nom1» из таблицы «Uchastki», которое является отображением поля «Nom» и связывается по полю «NLS». Это позволит при формировании справки «Поиск владельца по номеру участка» фактически обращаться только к одному набору данных. Для создания LookUp-поля необходимо выполнить следующие операции:
  • — набор данных (Table1), в который необходимо добавить поле, сделать неактивным (свойство Active=False);
  • — в набор полей добавить новое поле и появившуюся форму создания нового поля заполнить следующим образом

Рис. 12 Добавление LookUp-поля в набор данных

Набор данных «Table2» соответствует таблице «Uchastki» ;

• — набор данных (Table1), в который было добавлено поле, сделать активным (свойство Active=True).
• 2. Таким же образом в таблицу «Uchastki» (набор «Table2») добавить поле «FIO1», которое является образом поля «FIO» из таблицы «Ludi» (набор «Table1»). Это позволит при формировании справки «Поиск участка по Ф.И.О. владельца» фактически обращаться только к одному набору данных (таблица «Uchastki», набор «Table2») для вывода всей необходимой информации, в том числе и Ф.И.О. владельца участка.
• 3. В таблицу «Plata» (набор «Table3») добавить поле «FIO1», которое является образом поля «FIO» из таблицы «Ludi» (набор «Table1»). Это позволит при формировании отчета «Оплата взносов» и справки «Поиск оплат взносов по номеру участка» обращаться только к одному набору данных (таблица «Oplata», набор «Table3») для вывода всей необходимой информации, в том числе и Ф.И.О. владельца участка.