| « Поставить закладку » « Сделать стартовой » | |||
|
|||
| Статьи:: Базы данных :: Учебник по Access 2002 :: Глава 17. Проекты Microsoft Access 2002.
Глава 17. Проекты Microsoft Access 2002.
Глава 17. Проекты Microsoft Access 2002 В данной главе
мы постараемся показать, что Microsoft Access 2000, будучи настольной СУБД, не
ограничивает пользователя в разработке приложений различной сложности и
масштабируемости. Кроме создания достаточно сложных многопользовательских
приложений, Access может использоваться в качестве средства для разработки
клиентской части приложения с архитектурой "клиент-сервер". С помощью объектов
Access может быть создан интерфейс к базам данных, которые размещаются на мощных
серверах баз данных, таких как Microsoft SQL Server, Oracle и т.
д. Для доступа к
серверным базам данных из приложений Access используется один из двух
стандартных способов доступа к удаленным данным: ODBC или OLE DB. Достоинством
Access как клиента к серверной базе данных является наличие мощных и простых
средств для разработки интерфейса — форм, отчетов и страниц Web. Наиболее
простым и перспективным способом создания приложений в архитектуре
"клиент-сервер" являются проекты Microsoft Access 2002 — файлы с расширением
adp. В отличие от файла базы данных Access файл проекта не содержит таблиц с
данными. Все таблицы, с которыми работает клиентское приложение, размещаются на
сервере базы данных, а файл проекта включает в себя только те объекты, которые
создаются на базе этих таблиц: формы, отчеты, страницы, макросы и модули. Однако
из проекта Access доступны не только таблицы, но и другие объекты сервера:
представления (views), хранимые процедуры (stored procedures), схемы базы данных
(database diagrams). Доступ к этим объектам выполняется посредством OLE DB —
универсального интерфейса, разработанного фирмой Microsoft для доступа к данным
произвольного типа как реляционным, так и нереляционным. В качестве
сервера базы данных в проектах Access 2002 может быть использован либо Microsoft
SQL Server версии 6.5 и выше, либо настольная (desktop) версия Microsoft SQL
Server 2000. Замечание
В данном разделе
мы рассмотрим основные понятия модели "клиент-сервер". Независимо от
того, как определяется понятие архитектуры "клиент-сервер" (а таких определений
в литературе много), в основе этого понятия лежит распределенная модель
вычислений. В самом общем случае под клиентом и сервером
понимаются два взаимодействующих процесса, из которых один является
поставщиком некоторого сервиса для другого.
Здесь и далее в
книге речь будет идти о частном случае архитектуры "клиент-сервер", а именно о
приложениях баз данных, в которых сервером является мощная реляционная СУБД,
такая как Microsoft SQL Server (back-end), а клиентом — приложение, созданное в
среде Access 2000, которое использует данные с сервера
(front-end). Отличие архитектуры "клиент-сервер" от архитектуры
"файл-сервер" Такое приложение
от сетевого многопользовательского приложения, которое рассматривалось в
предыдущей главе, отличается только тем, где конкретно ведется обработка
данных. Сетевое
многопользовательское приложение строится по принципу файл-серверной
архитектуры. Данные в виде одного или нескольких файлов размещаются на файловом
сервере. Файловый сервер принимает запросы, поступающие по сети от
компьютеров-клиентов, и передает им требуемые данные. Однако обработка этих
данных выполняется на компьютерах-клиентах. На каждом из компьютеров запускается
полная копия процессора обработки данных Jet Engine. Любая копия Jet независимо
управляет файлами MDB, содержащими данные. Единственная связь между этими
независимыми действиями — файл блокировок (файл, который имеет имя, совпадающее
с именем файла приложения, но с расширением Idb), который обязательно создается
для каждого файла базы данных с расширением mdb. При этом каждая копия Jet
выполняет изменения индексов, работу с системными таблицами и другие функции,
входящие в компетенцию СУБД. В архитектуре
"клиент-сервер" сервер базы данных не только обеспечивает доступ к общим данным,
но и берет на себя всю обработку этих данных. Клиент посылает на сервер запросы на чтение или
изменение данных, которые формулируются на языке SQL. Сервер сам выполняет все
необходимые изменения или выборки, контролируя при этом целостность и
согласованность данных, и результаты в виде набора записей или кода возврата
посылает на компьютер клиента. Недостатки
архитектуры с файловым сервером очевидны и вытекают главным образом из того, что
данные хранятся в одном месте, а обрабатываются в другом. Это означает, что их
нужно передавать по сети, что приводит к очень высоким нагрузкам на сеть и,
вследствие этого, резкому снижению производительности приложения при увеличении
числа одновременно работающих клиентов. Вторым важным недостатком такой
архитектуры является децентрализованное решение проблем целостности и
согласованности данных и одновременного доступа к данным. Такое решение снижает
надежность приложения. Архитектура
"клиент-сервер" позволяет устранить все указанные недостатки. Кроме того, она
позволяет оптимальным образом распределить вычислительную нагрузку между
клиентом и сервером, что также влияет на многие характеристики системы:
стоимость, производительность, поддержку. Распределение функций в архитектуре
"клиент-сервер" Процесс
разработки таких систем достаточно сложен и одной из наиболее важных задач
является как раз решение о том, как функциональность приложения должна быть
распределена между клиентской и серверной частью. Пытаясь решить эту задачу,
разработчики получают двух-звенные, трехзвенные и многозвенные архитектуры. Все
зависит от того, сколько промежуточных звеньев включается между клиентом и
сервером. Основная задача,
которую решает клиентское приложение, — это обеспечение интерфейса с
пользователем, т. е. ввод данных и представление результатов в удобном для
пользователя виде, и управление сценариями работы приложения. Основные функции
серверной СУБД — обеспечение надежности, согласованности и защищенности данных,
управление запросами клиентов, быстрая обработка SQL-запросов. Вся логика
работы приложения — прикладные задачи, бизнес-правила — в двух-звенной
архитектуре распределяются разработчиком между двумя процессами: клиентом и
сервером (рис. 17.1). Сначала большая
часть функций приложения решалась клиентом, сервер занимался только обработкой
SQL-запросов. Такая архитектура получила название "толстый клиент — тонкий
сервер". Появление возможности создавать на сервере хранимые процедуры, т. е.
откомпилированные программы с внутренней логикой работы, привело к тенденции
переносить все большую часть функций на сервер. Сервер становился все более
"толстым", а клиент — "утоньшался". Такое решение имеет очевидные преимущества,
например его легче поддерживать, т. к. все изменения нужно вносить только в
одном месте — на сервере. Однако язык, на котором пишутся хранимые процедуры, не
является достаточно мощным и гибким, чтобы на нем было удобно реализовывать
сложную логику приложения.
Рис. 17.1.
Распределение функций между клиентом и сервером Тогда возникла
тенденция поручить выполнение прикладных задач и бизнес-правил отдельному
компоненту приложения (или нескольким компонентам), которые могут работать как
на специально выделенном компьютере — сервере приложений, так и на том же
компьютере, где работает сервер базы данных. Так возникли трехзвенные и
многозвенные архитектуры "клиент-сервер". Появилось специальное программное
обеспечение (ПО) промежуточного слоя, которое должно обеспечить совместное
функционирование множества компонентов такого многокомпонентного приложения.
Такие приложения являются гибкими, масштабируемыми, но сложными в
разработке. Далее в данной
главе мы будем говорить только о двухзвенных приложениях "клиент-сервер", в
которых клиент, реализованный на базе Access 2002, непосредственно обращается с
запросами к серверу базы данных. Промежуточное ПО в данном случае только
транслирует эти запросы и результирующие наборы записей между клиентом и
сервером и не реализует никаких функций приложения. Универсальный доступ к данным через OLE
DB Интерфейс ODBC
был первым средством, которое обеспечило универсальный доступ к данным
реляционного типа посредством SQL-запросов. Однако реляционные базы данных не
единственный формат хранения данных, а современные приложения требуют интеграции
информации из разных источников, не только SQL-ориентированных. Отсюда возникает
потребность либо перевести все данные в единый формат, т. е. создать
универсальную базу данных, что очень-дорого и неэффективно, либо обеспечить
универсальный доступ к данным разных типов без необходимости их преобразовывать
и реплицировать. OLE DB
представляет собой разработанный фирмой Microsoft набор интерфейсов OLE,
обеспечивающих унифицированный доступ приложений к данным из разнообразных
источников, включая текстовые файлы, файлы электронной почты, электронные
таблицы, данные мультимедиа и пр. Основные отличия
OLE DB от ODBC состоят в следующем:
Архитектура
приложения, использующего интерфейсы OLE DB для доступа к данным, представлена
на рис. 17.2. Эта архитектура является многокомпонентной. Компоненты доступа к
данным делятся на три категории: потребители, провайдеры и сервисные
компоненты. Потребители
данных (Data Consumer) — это любое приложение или компонент, которые
используют интерфейсы OLE DB для доступа к данным. Провайдеры
данных (Data Provider) — это компоненты, которые обеспечивают потребителям
доступ к данным через строго специфицированный набор интерфейсов. Они
взаимодействуют с данными и представляют их единообразно в табличном виде,
используя абстракцию, называемую набор рядов (rowsef).
Рис. 17.2.
Архитектура универсального доступа к данным Сервисы
(Services) — это дополнительные компоненты, которые обеспечивают функции, не
реализованные провайдером OLE DB. Они являются как потребителями OLE DB данных,
так и провайдерами. Примером сервиса может быть процессор запросов, который
может объединять табличную информацию от разных OLE DB провайдеров и
обеспечивать доступ к результирующим данным через OLE
DB-интерфейс. Функционирование
компонентов может реализовываться как разными процессами, так и на разных
компьютерах через сетевые протоколы, такие как DCOM (Distributed Component
Object Model — Распределенная компонентная модель объектов) или HTTP. При этом
для выполнения распределенных транзакций может использоваться координатор
распределенных транзакций, например Microsoft Transaction Server
(MTS). В OLE DB
определена иерархия компонентов, каждый из которых является СОМ-объектом (рис.
17.3).
Рис. 17.3.
Объекты — компоненты OLE DB П Источники
данных (Data Source) — объекты, которые реализуют подключение к источнику
данных: Они определяют нужный OLE DB-провайдер, проверяют права доступа
потребителя данных и инициируют соединение с источником данных. Замечание
Microsoft ActiveX Data Objects (ADO) Хотя OLE DB
является очень мощным интерфейсом для работы с данными, этот интерфейс является
низкоуровневым. Для удобства работы с OLE DB, так же как и для ODBC, была
разработана объектная модель, которую назвали ADO (ActiveX Data Objects). Эта
модель была описана в разд. "Объектные модели Microsoft Access" гл. 13.
Здесь хотелось бы указать на те достоинства этой модели, которые позволяют
говорить о ее ключевой роли в приложениях, связанных с обработкой данных, в
ближайшем будущем.
Установка связи с источником данных посредством интерфейса OLE
DB При установке на
компьютере Microsoft Office XP или отдельного приложения Access 2002
автоматически устанавливаются следующие провайдеры OLE DB:
Для того чтобы
посмотреть, какие провайдеры OLE DB установлены на вашем компьютере, необходимо
открыть диалоговое окно Data Link Properties. Это окно открывается при
создании или редактировании специальных файлов — Microsoft Data Link, или файлов
UDL (universal data link), в которых хранится информация о конкретном источнике
данных OLE DB (тип провайдера OLE DB, сервер, на котором размещаются данные,
база данных или файл, в котором они хранятся). Информация о
соединении может храниться и запрашиваться также в том приложении, которое
использует интерфейс OLE DB для доступа к данным. В нашем случае таким
приложением яапяется проект Microsoft Access, однако о проектах Microsoft Access
речь еще впереди, поэтому пока мы опишем только, как работать с файлами связей
Microsoft Data Link. Для того чтобы
создать новый UDL-файл, проще всего воспользоваться программой Проводник
(Explorer) Windows:
Вкладка
Connection и следующая вкладка Advanced содержат параметры
соединения с источником данных. Вид этих вкладок зависит от используемого
провайдера OLE DB. Для SQL Server провайдера OLE DB вкладка Connections
выглядит так, как представлено на рис. 17.5. Замечание
Рис. 17.4.
Список провайдеров OLE DB
Рис. 17.5.
Определение связи с SQL Server На этой вкладке
нужно определить сервер, с которым будет выполняться соединение, имя базы данных
и параметры регистрации на сервере. Можно использовать интегрированную с Windows
NT (Use Windows NT integrated security) или стандартную (Use a specific user
name and password) схему безопасности. При выборе переключателя Use a
specific user name and password нужно ввести имя и пароль для регистрации на
сервере. Флажок Blank password предназначен для использования пустого
пароля в строке соединения (connection string). Флажок Allow saving password
позволяет сохранить пароль в строке соединения. Если используется
интегрированная схема безопасности, то подключение к SQL Server будет
выполняться с тем именем и паролем, под которым вы зарегистрировались в сети
Windows NT. На этой вкладке есть также кнопка Test Connection,
позволяющая немедленно протестировать соединение с заданными
параметрами. Следующая
вкладка Advanced позволяет определить дополнительные свойства соединения,
например Connection timeout (рис. 17.6). Это время ожидания (в секундах)
соединения с источником данных. Если через заданный промежуток времени связь с
источником данных установить не удалось, выдается сообщение об
ошибке.
Рис. 17.6.
Определение дополнительных свойств соединения Все свойства
соединения можно увидеть и отредактировать на вкладке All (рис. 17.7).
Перечень свойств в списке зависит от типа провайдера OLE DB. Для того чтобы
отредактировать любое свойство, нужно выделить его в списке и нажать кнопку
Edit Value. Появится диалоговое окно Edit Property Value. В поле
Property Value можно ввести новое значение свойства, предварительно очистив
его при необходимости нажатием кнопки Reset Value (рис.
17.8).
Рис. 17.7.
Список свойств соединения
Рис. 17.8.
Диалоговое окно Edit Property Value Настольная версия Microsoft SQL Server
2000 Данная версия
сервера представляет собой процессор обработки данных, который является
альтернативой процессору Jet (первая версия этого процессора называлась MSDE —
Microsoft Server Database Engine и была совместима с Microsoft SQL Server 7.0).
Он может быть
использован либо как локальный сервер, и в этом случае устанавливается на тот же
компьютер, на котором установлен Access 2002, либо как сервер баз данных для
небольшой рабочей группы, и в этом случае будет удаленным по отношению к
клиентским компьютерам. Основное его достоинство по сравнению с процессором Jet
— полная совместимость с Microsoft SQL Server 2000. Это означает, что, создав
приложение целиком на персональном компьютере, можно в любой момент времени без
труда перенести всю серверную его часть на Microsoft SQL Server 2000. В
результате становится возможным многократное увеличение числа пользователей
приложения и получение доступа к многочисленным службам SQL Server, например
Data Transformation Services, OLAP Services и т. д. В отличие от
Microsoft SQL Server 2000, Standard Edition Microsoft SQL Server 2000 Desktop
Engine имеет ограничение на количество одновременно работающих с базой данных
пользователей и на объем базы данных, не поддерживает симметричную
мультиобработку (SMP) и в процессе репликации может функционировать только как
подписчик. Максимальный объем базы данных, так же как и у Jet равен 2 Гбайт, а
количество одновременно работающих пользователей ограничивается пятью активными
запросами (потоками). Итак, с помощью
проектов Access, используя Microsoft SQL Server 2000 Desktop Engine, вы можете
создавать надежные многопользовательские приложения, а когда потребуется
подключить к базе данных большое число пользователей или объем базы данных будет
превышать 2 Гбайт, можно легко масштабировать этот проект, просто перенеся базу
данных на SQL Server 2000. Установить
Microsoft SQL Server 2000 Desktop Engine можно с того же компакт-диска, что и
Microsoft Office XP. Он находится в папке Msde2000. При этом программа установки
не запрашивает ни имя папки, в которую будет установлен сервер, ни имя самого
сервера. Установка выполняется в папку C:PROGRAM FILESMICROSOFT SQL SERVER, а
имя сервера по умолчанию — MSSQLSERVER. Если требуется изменить эти значения,
нужно использовать при установке параметры командной строки (см. разд. справки
Access 2002 "Работа с проектами Microsoft Access, Основные задачи, Установка и
конфигурирование SQL Server 2000 Desktop Engine" (Working with Microsoft Access
Projects, Basic Tasks, Install and configure SQL Server 2000 Desktop
Engine)). Замечание
Создание проекта
Access аналогично созданию базы данных Access. Поэтому мы опишем эту процедуру
кратко (см. разд. "Создание новой базы данных" гл. 2). Существует три
возможности создания проекта Access:
В любом случае
нужно сначала выполнить команду меню Файл, Создать (File, New),
чтобы появилась область задач Создание файла (New File). Создание проекта с использованием существующей базы
данных
Замечание
Рис. 17.9.
Установление соединения с базой данных на сервере Можно убедиться
в правильности задания параметров соединения, нажав кнопку Test Connection.
Нажмите кнопку ОК. Появится окно проекта Access 2000, очень похожее на окно
обычной базы данных Access, однако список ярлыков на панели объектов будет
несколько отличаться от традиционного списка объектов базы данных Access (рис.
17.10).
Рис.
17.10. Окно проекта Access 2002 Замечание
Еще одним
примером может служить демонстрационная база данных Pabs, которая создается на
SQL Server при его установке и содержит данные о книгах, их авторах и
издателях. Создание проекта с новой базой данных Выберите ярлык
Проект (новые данные) (Project (New Database)) в группе Создание
(New) области задач Создание файла (New File). Откроется пустое окно
базы данных и запустится Мастер баз данных Microsoft SQL Server (Microsoft SQL
Server Database Wizard). В диалоговом окне мастера (рис. 17.11) нужно ввести имя
сервера (если Access обнаруживает на локальном компьютере MSDE, то имя сервера
автоматически подставляется), имя и пароль пользователя для регистрации на
сервере и имя базы
данных. После этого нажмите кнопку Далее (Next). Если все введено
правильно, во втором диалоговом окне мастера нужно только нажать кнопку
Готово (Finish). После этого появится окно с индикатором процесса
создания новой базы "данных на сервере (рис. 17.12).
Рис.
17.11. Первое диалоговое окно Мастера баз данных Microsoft SQL
Server
Рис.
17.12. Диалоговое окно с индикатором процесса создания базы данных на
сервере Замечание
При создании
нового проекта можно не устанавливать соединение с базой данных на сервере
сразу, а выполнить подключение позже. Для этого в диалоговом окне Data Link
Properties необходимо нажать кнопку Отмена (Cancel). Присоединить
базу данных на сервере к существующему проекту Access 2002 можно с помощью
команды меню Файл,
Подключение (File, Connection). Эту же команду можно использовать также для
соединения проекта с другой базой данных. Чтобы подключить проект Access 2000 к
базе данных на сервере, выберите команду меню Файл, Подключение (File,
Connection) и введите необходимые параметры соединения в диалоговое окно Data
Link Properties. Файл проекта
Access открывается аналогично файлу базы данных. Однако, в отличие от файла базы
данных, файл проекта всегда открывается в монопольном режиме. Если вы пытаетесь
открыть файл, который уже открыт другим пользователем, он откроется в режиме
"только для чтения". Тем не менее и в этом режиме можно работать с объектами,
размещенными на сервере (изменять, удалять, создавать новые объекты).
Запрещается только модифицировать объекты, находящиеся в самом файле проекта.
Для примера можно открыть файл NorthwindCS.adp, который размещается в папке
Samples при установке Access 2002. При первом открытии данного файла Access
может автоматически создать базу данных на SQL Server. Для этого используется
файл сценария установки NorthwindCS.SQL, который находится в той же папке
Samples. Сначала Access ищет настольную версию SQL Server на локальном
компьютере, и если найдет, то спросит вас, хотите ли вы создать на нем новую
базу данных "NorthwindCS". Если на локальном компьютере сервер не найден, то
Access попросит ввести имя удаленного сервера, имя пользователя и пароль. После
этого исполняется сценарий установки базы данных на соответствующем сервере, и
файл проекта NorthwindCS.ADP соединяется с новой базой данных
"NorthwindCS". Окно проекта
представлено выше, на рис. 17.10. В списке таблиц вы видите те же таблицы, что и
в базе данных "Борей" (Northwind). Однако эти таблицы хранятся не в файле
проекта, а на сервере. Хотя значок таблицы выглядит так, как если бы это были
локальные таблицы. На панели объектов проекта Access 2002 по сравнению с базой
данных Access 2002 появился новый ярлык — Схемы баз данных (Database
Diagrams). Соответствующие новые объекты также размещены на сервере. Все
остальные объекты (кроме страниц доступа к данным) находятся в файле
проекта. Если вы откроете
одну из таблиц, например "Товары" (Products), то увидите, что форма
представления таблицы почти не изменилась (рис. 17.13). Появились только две
дополнительные кнопки справа от кнопок навигации. Одна из них (крайняя справа)
используется для задания максимального числа записей, которые будут передаваться
с сервера. Это значение отображается в небольшом диалоговом окне. Вы можете
ограничить передаваемое число записей, введя требуемое значение в текстовое поле
Максимальное число записей (Max Record Count). Еще одна кнопка (вторая
справа) подсвечивается красным цветом в процессе передачи записей. С помощью
этой кнопки можно прервать процесс передачи записей с сервера. Заметим, что
такой возможности явно не хватает в базе данных Access. Когда запрос выполняется
достаточно долго, вы не можете прервать этот процесс.
Рис.
17,13. Отображение таблицы, хранящейся на SQL Server, в проекте
Access 2000 Определение и изменение структуры таблицы Открыв таблицу в
режиме Конструктора, вы увидите, что способ отображения структуры таблицы
незначительно отличается от принятого в режиме Конструктора таблиц базы данных
Access (рис. 17.14). В верхней части Конструктора появились два новых
столбца:
Рис.
17.14. Таблица SQL Server в режиме Конструктора Значение в
столбце Длина (Lengh) может изменяться пользователем только для текстовых
полей, в остальных случаях это значение устанавливается по умолчанию при выборе
типа данных и не может быть изменено. Раскрывающийся список в столбце Тип
данных (Data Type) содержит значения, отличающиеся от типов данных, принятых
в базах данных Access. Это типы данных для Microsoft SQL Server. Столбец
Описание (Description) — эквивалент поля Примечание (Comment) в
Access — отображается только для SQL Server 2000. Остальные
свойства полей таблицы отображаются на вкладке Столбцы (Columns) в нижней
части окна Конструктора. Описание этих свойств приведено в табл.
17.1. Таблица
17.1. Свойства полей
Типы данных,
которые поддерживает SQL Server, приведены в табл. 17.2. Таблица
17.2. Типы данных Microsoft SQL Server
Диалоговое окно свойств таблицы Если щелкнуть
правой кнопкой мыши в верхней части окна Конструктора и выбрать в контекстном
меню команду Свойства (Properties), появится диалоговое окно Свойства
(Properties), имеющее пять вкладок. На них перечисляется ряд свойств
таблицы, которые можно просматривать и изменять. Наиболее важны три
вкладки:
На вкладке
Связи (Relationships) отображаются и могут модифицироваться внешние ключи
(foreign keys) таблицы, которые отражают ее связи с другими таблицами. Внешние
ключи создаются автоматически в процессе задания связей между таблицами на схеме
данных. Поле со списком
Выделенная связь (Selected relationship) содержит список связей таблицы.
Выбрав из этого списка значение, в остальных полях можно увидеть описание
выбранной связи. Поле Имя
связи (Relationship name) показывает имя данной связи. Таблица из двух
столбцов отображает две стороны связи: слева — имя таблицы и имя поля, которое
является первичным ключом; справа — имя таблицы и имя поля, которое является
внешним ключом, т. е. содержит значения первичного ключа другой таблицы. Эти
таблицы связаны по полю "КодТипа" (Categoryld). Это поле в таблице "Типы"
является первичным ключом, а в таблице "Товары" — внешним. Имя связи состоит из
трех частей и формируется следующим образом: первым пишется имя таблицы,
включающей внешний ключ, затем имя таблицы, содержащей первичный ключ, и перед
ними ставится префикс. Префикс зависит от того, на какой стороне оказывается
таблица, связи которой мы описываем: если она содержит внешний ключ, то пишется
префикс FK_, если она содержит первичный ключ, то пишется префикс РК_. В данном
примере получается имя FK_Products_Categories, т. к. мы смотрим связи
таблицы "Товары"
(Products). Перед именем связи присутствует значок. Значок "бесконечность"
указывает, что данная таблица находится в связи на стороне "многие", а значок
"ключ" означает, что данная таблица находится на стороне "один". Имя связи
формируется автоматически, однако оно может быть откорректировано в поле Имя
связи (Relationship name). Для выбранной
связи можно изменить поле, которое будет содержать вторичный ключ, выбрав из
списка полей таблицы нужное поле. Изменить поле первичного ключа нельзя, это
можно сделать только на вкладке Индексы и ключи
(Indexes/Keys). Флажки в нижней
части вкладки имеют следующие значения.
|