Введение
Про "Pro"

 

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

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

I. Ввод данных в иерархических структурах с множественными связанными таблицами (каталоги, структура персонала, сложные сметы и т.п.).

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

III. Создание единого и комфортного интерфейса-скелета для всех экранных форм вашей БД, легко размножаемого простым "копипастом" - без переделок.

Как это работает в реальных проектах, вы можете посмотреть в разделе "Проекты/Обзор", там же можно скачать полнофункциональные демо-файлы.


 

I. Ввод данных: классический способ и способ "Pro" 

В FileMaker'e любая форма (лэйаут) для ввода и просмотра данных, печати отчетов и иных специфических задач всегда базируется (создается) на основе какой-то таблицы. 

Например, при создании структуры, которую условно назовем "Компании-Отделы-Сотрудники", нам потребуются три таблицы и, соответственно, три формы ввода:

1. Форма "Компании" - базируется на таблице  Companies, каждая запись которой содержит поля Компания, Адрес, Директор и т.п.

 

2. Форма "Отделы" - базируется на таблице  Departments, каждая запись которой содержит поля Отдел, Руководитель, Численность и т.п.

 

3. Форма "Карточка сотрудника" - базируется на таблице  Personal, каждая запись которой содержит поля Фамилия, Имя, ДатаРождения, Должность, Отдел, Фото и т.п.

     

Все эти три таблицы, естественно, связаны друг с другом соотношением "один-ко-многим", как показано на рисунке-графе.
То есть в одной компании может быть много отделов (связь по полю IDCompany), в одном отделе может быть много сотрудников (связь по полю IDDepartment). 

При стандартном подходе, чтобы отредактировать или завести новые данные, нужно:

- перейти в соответствующую форму (лэйаут),

- найти соответствующую запись или создать новую (кнопкой "New/Новая" или командой меню New Record),

- если запись "подчиненная", обязательно указать, к какой "родительской" записи она относится; например, к какой компании относится новый отдел (помимо основных данных отдела ввести код компании IDCompany) или к какому отделу относится новый сотрудник (помимо основных данных сотрудника ввести код отдела IDDepartment).

Довольно много мелкой ручной работы, не так ли?

Автоматический ввод родительского кода в дочерних записях легко организовать для простой двухуровневой  конструкции, когда на одном лэйауте мы размещаем как записи главной таблицы (например, Заказы - №заказа, Дата, Клиент... ), так и записи подчиненой таблицы в портале (СтрочкиЗаказа - Наименование, Количество, Цена...).

Тогда при вводе подчиненной записи в портале она автоматически приобретает код "родителя" - IDЗаказа:

Похожими примерами таких двухуровневых конструкций являются также пары таблиц типа: "Страны - Города", "Писатели - Книжки", "Изделия - Состав изделий", "Классы - Студенты" и т.п.

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

Примеры того, что хотим:

Пример A. Структура "Компании-Отделы-Сотрудники".

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

 

Пример B. Ввод, редактирование и общий обзор структуры строительной сметы.

Вводим и видим как детали выбранной сметы по объектам, услугам, материалам, так и итоговые значения по всем сметам.

Нет нужды "бегать" по разным лэйаутам и отыскивать нужные записи. Все в одной форме - просто выделяем/создаем нужную родительскую запись и сразу видим и можем редактировать все дочерние , внучатые и т.д.

 

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


 

А теперь возникает естественный вопрос - когда мы создаем такой лэйаут, "вмещающий" данные из разных таблиц, то на какой же таблице должен базироваться он сам?

Ответ: это должна быть отдельная таблица (мы уже назвали ее Pro), особенностью которой является то, что она состоит всего из одной записи и все ее поля являются глобальными. Состав этих полей определяется только потребностями вашей задачи. Единственное обязательное и неизменное поле-ключ  -  KeyOne (тип Global, Number), значение которого всегда равно единице. 

Глобальное поле KeyOne служит для организации сквозных связей "один-ко-всем" со всеми остальными таблицами БД, в каждой из которых также обязательно присутствует свое поле KeyOne (тип Number, Auto-enter Data: 1). 

Таблица Pro "видит" все таблицы, данные которых размещены (и даже не размещены) на лэйауте.

"Видит" в данном случае означает, что между таблицей Pro и другими таблицами существуют связи (relationships) - либо по полю KeyOne вида:

Pro::KeyOne = Companies::KeyOne

- при этом мы "видим" данные ВСЕХ записей таблицы Companies, так как значение поля KeyOne во всех записях таблицы Companies всегда равно единице  (см. портал "Компании" на рис. к примеру A),

 

либо по конкретным полям вида: 

Pro::GL_IDDepartment = Personal::IDDepartment 

- при этом, если глобальное поле GL_IDDepartment = 4, то "видим" ТОЛЬКО записи таблицы Personal с кодом отдела IDDepartment=4, т.е. всех сотрудников отдела №4 (см. портал "Сотрудники" на рис. к примеру A). 

 

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

Аналогично, если мы хотим, находясь в лэйауте таблицы Pro, увидеть развернутые в виде карточки данные ОДНОГО выбранного сотрудника с кодом IDPerson=1 (см. рис. к примеру А), то в таблице Pro нужно просто задать значение поля GL_IDPerson равным единице и вывести поля таблицы Personal, "видимые" через связь (TO - table occurrence) по полям Pro::GL_IDPerson = Personal::IDPerson 

 

 

 

 

 

 

 

 

 

 

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

При взгляде на этот граф может возникнуть вопрос - почему именно так названы различные ТО (или по-русски - "связи")? Почему в каких-то ТО достаточно указать только имя базовой таблицы (Companies, Pics, Zodiak), а в других помимо этого следует дополнительно прописывать имя "вышестоящей" таблицы да еще и связующее поле (Personal Departments|IDDepartment|)?

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

Ну и наконец: когда мы говорим "просто выделяем нужную родительскую запись и сразу видим и можем редактировать все дочерние , внучатые и т.д.", это означает, что при выделении (клике) родительской записи каскадно срабатывают простые скрипты-триггеры, обеспечивающие соответственную фильтрацию записей во всех подчиненных порталах.
Как это делается на примере структуры "Компании-Отделы-Сотрудники", вы можете посмотреть, скачав Демо-файл (FMPro11, архив Win RAR ~1.5 Mb).

II. Создание обзорных и управляющих форм

Эта часть еще пишется...

 

 

 

III. Создание единого и комфортного интерфейса-скелета

И эта часть еще пишется...

 

 

 

 




Автор: FMLogia

Тэги: всевидящая таблица, портал

← Вернуться к списку статей