Таблица 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
Тэги: всевидящая таблица, портал