Что такое код interbase


Содержание

Что такое код interbase

SQL-сервер баз данных Borland InterBase 6 объединяет простоту использования, низкие затраты на сопровождение и мощность систем корпоративного уровня. Borland гарантирует, что InterBase 6 совмещает силу мощной, апробированной архитектуры с развитыми технологиями, необходимыми для успеха прикладных систем.

Повышенная производительность за счет развитой архитектуры

Сервер InterBase реализует архитектуру множественных поколений записей (MGA — Multi-Generational Architecture). MGA обеспечивает уникальные возможности использования версий, что ведет к высокой степени доступности данных как для пользователей, работающих с транзакциями, так и для пользователей, использующих приложения поддержки принятия решений. Механизм MGA в InterBase хорошо работает при оперативной обработке коротких транзакций (OLTP — On-Line Transaction Processing) и является уникальным для крупномасштабных реальных приложений, превосходя другие базы данных в области параллельного исполнения длительных транзакций для поддержки принятия решений. Механизм версий устраняет необходимость блокировки записей, к которым осуществляется доступ по чтению во время транзакции, делая их свободными от конфликтов доступа – доступ по чтению никогда не блокирует доступ по записи. В отличие от других баз данных, InterBase обеспечивает своевременные, устойчиво воспроизводимые результаты для каждого запроса без специального программирования. В результате достигается максимальная пропускная способность для всех пользовательских транзакций.

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

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

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

  • Идентичность функциональных возможностей в Linux, Solaris, и других Unix-средах, Window s 2000, NT, ME, 98
  • Многопотоковая архитектура сервера — высокоэффективная многопоточная обработка на сервере
  • InterClient— драйвер JDBC, обеспечивающий Java приложениям доступ к данным, хранимым в базах данных InterBase
  • Строгое соблюдение стандарта SQL-92 и надежный интерфейс SQL
  • Поддержка больших чисел без потери точности
  • Уникальные механизмы версионности одновременно поддерживающие системы поддержки принятия решений (DSS) и оперативную обработку транзакций (OLTP)
  • Автоматическая двухфазная фиксация транзакций и распределенное восстановление при двухфазной фиксации
  • Функции, определяемые пользователем (UDF — User-defined function) для расширения функциональных возможностей сервер

Высокая надежность всех ваших приложений

В InterBase впервые реализована концепция активного ядра сервера баз данных. Функции активного ядра InterBase включают запатентованный механизм сигнализаторов событий, хранимые процедуры, триггеры, функции, определяемые пользователем (UDF — User-defined function) и BLOB-фильтры. Совместная работа этих функций обеспечивает перенос обработки данных на сервер, где они выполняются быстрее и надежнее. InterBase обеспечивает высокую доступность и целостность данных с помощью механизмов декларативной ссылочной целостности, включая каскадные операции.

Мощная поддержка различных типов данных

Многим приложениям (мультимедиа, научные, интернет – приложения), требуется возможность обработки неструктурированных данных. InterBase является первой реляционной базой данных, удовлетворившей это требование с помощью BLOB. Использование BLOB позволяет сохранять в базе данных аудио-, видео-, графическую и бинарную информацию. В современных приложениях фильтры BLOB используются для сжатия и трансформации данных. Разработка приложений и улучшенная производительность для научных приложений поддерживаются многомерными типами данных InterBase, обеспечивающими хранение до 16 измерений в одном поле базы данных.

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

Самонастройка и простота инсталляции

Инсталляция InterBase занимает не более пяти минут. Одна команда – и все готово. Это сильно отличается от традиционных серверов реляционных баз данных, требующих участия всего штата отдела информационных технологий для настройки и постоянной поддержки функционирования. Множество функций самонастройки InterBase включает автоматическую сборку мусора для старых записей и индексов, развертывание базы данных, отслеживание версий и транзакций, так что вы сможете сосредоточиться непосредственно на разработке приложения.

Реальная идентичность функциональных возможностей

Когда придет время перенести ваше приложение InterBase на другую операционную систему, просто сделайте резервную копию базы данных и загрузите ее под управлением новой операционной системы! Масштабирование ваших решений от самых маленьких до самых больших серверов в соответствии с нуждами ваших клиентов не требует модификации приложения.

Независимость от клиента и инструментария

InterBase поддерживает взаимодействие со всеми популярными клиентами для настольных компьютеров и средами разработки приложений, такими как: Delphi, C++Builder, JBuilder, Kylix, Microsoft Access, все ODBC-совместимые клиенты и совместимые с интегрированным API баз данных приложения и инструментальные средства.

Эффективность использования ресурсов

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

Строгое соблюдение индустриальных стандартов

InterBase придерживается строгого соответствия индустриальным стандартам для клиент-серверных вычислительных сред, таким как ANSI/SQL, Java, UNICODE и XDR (External Data Representation – внешнее представление данных). Наша приверженность критически важным технологическим стандартам означает, что вы можете сократить время, необходимое для разработки, внедрения и сопровождения ваших приложений на множестве платформ с гарантией немедленного достижения наивысшей производительности.

Поддержка интернациональных требований бизнеса

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

В InterBase впервые реализована технология встраиваемых баз данных, удовлетворяющая потребности приложений компаний по всему миру, которые нуждаются в надежных системах с низкими затратами на сопровождение. Вступайте в ряды разработчиков убедившихся, что использование InterBase для встраиваемых приложений позволяет вам работать по принципу Embed . Deploy . Relax – встроив InterBase , развернуть ее и затем забыть о каком-либо сопровождении!

Репликация в InterBase

InterBase 6 включает IBReplicator — специальное программное обеспечение, обеспечивающее высокий уровень управляемости переноса данных и метаданных — репликации.

Уникальность этого механизма заключается не только в его широких функциональных возможностях, но и в поддержке репликации между многопользовательскими (InterBase Server) и локальными (однопользовательскими — InterBase Desktop) базами данных. При этом вы имеете возможность не только переноса выбранных данных и метаданных «один-в-один», но и явно указывать имена источников и целевых объектов базы, даже если их имена не совпадают, а структура отличается.

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

Система управления базами данных InterBase

Interbase — СУБД от компании Borland. Основой InterBase был проект, разработанный Джимом Старки (Jim Starkey) во время работы над СУБД Datatrive. Джим создал его как реализацию своей идеи базы данных с многоверсионной архитектурой. В то время ( 1984 ) она называлась JRD (Jim’s Relational Databas). По-видимому, за основу была взята архитектура Rdb, так как Джим Старки был одним из разработчиков этой СУБД в DEC.

В 1985 Джим Старки, его жена Анн Харрисон и Дон ДеПалма (Don Depalma) основали компанию Groton Database Systems (именно поэтому базы данных InterBase до последнего времени имели традиционное расширение gdb — Groton DataBase). После ряда перепродаж и изменения наименования компании в InterBase Software Corporation в 1986 году был выпущен InterBase 2.

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

В 1988 году компания Ashton-Tate приобретает 51 % акций Interbase, а в 1991 году Borland покупает Ashton-Tate. В том же году выходит InterBase 3.

Большую популярность InterBase приобрел с выходом версии 4 в 1994 году. Для того времени это была очень мощная СУБД, конкурировавшая по возможностям и производительности с MS-SQL (6.5) и SyBase (5).

В 1997 году выходит InterBase 5, а в 1998 InterBase 5.1.1 был включен в дистрибутив Delphi 4, что в значительной мере предопределило его популярность среди разработчиков на Delphi и C++ Builder.

В конце 1999 года 3 ключевых сотрудника InterBase (Bill Karwin, Paul Beach и Wayne Ostiguy) увольняются из отдела Interbase. В конференциях Borland начинаются волнения. Австралийская активистка Хелен Борри (Helen Borrie) создает список людей в защиту IB под названием “Спасем InterBase”, с целью не допустить закрытия IB. Образуется группа IBDI (IB Developer’s Initiative) для защиты разработчиков-пользователей Interbase, основатели — Helen Borrie, Jason Wharton и Dalton Calford.

Но самое интересное происходит в 2000 году. Компания Borland выпустила версию InterBase 6.0 в открытых кодах — InterBase 6 Open Source Edition, под InterBase Public License (IPL). Не было выпущено ни документации, ни системы тестирования, ни системы сборки проекта — просто груда некомпилируемых исходников. Фактически Borland в тот момент отказался от дальнейшего развития InterBase.

31 июля 2000 года инициативная группа, отчаявшись добиться от Borland поддержки или хотя бы внятной позиции, скопировала исходные коды InterBase 6 и образовала проект Firebird — полностью Open Source проект, основанный на кодах InterBase 6 Open Source.

В 2001 году компания Borland снова решила развивать InterBase. Директором подразделения Interbase стал Джон Артур (John Arthur), а ведущим разработчиком — Чарли Каро (Charlie Caro). В следующей версии InterBase (6.5) компания Borland очевидно отказалась от модели бизнеса на основе Open Source. Чуть позже официально полностью была прекращена поддержка InterBase Open Source Edition.

Современное состояние

В настоящее время последней версией является InterBase XE (2011) , в которой появилась поддержка Unicode и шифрование AES/DES. InterBase 7.5/2007 и Firebird 1.5/2.0 похожи, но уже далеки от полной совместимости — то есть миграция между их форматами баз данных легче, чем между форматами совсем “чужих” баз данных, но все же сопряжена с определенными проблемами.

Основными достоинствами последней версии InterBase являются низкие требования к системе, с одновременной масштабируемостью на несколько процессоров, плюс развитая система мониторинга, временные таблицы, встраиваемая аутентификация пользователей, журналирование. Традиционным достоинством считается кросс-платформенность — InterBase поддерживает Linux, Microsoft Windows, Unix и Solaris.

Особенности СУБД InterBase

СУБД InterBase отличается чрезвычайно низкими системными требованиями и при этом высокой производительностью и легкостью администрирования.
InterBase является кросплатформенным продуктом, поддерживающим большое количество различных операционных систем, включая Microsoft Windows NT/2000/XP/98/ME, LINUX, SCO UNIX, HP UNIX. Вы можете работать с InterBase, используя несколько сетевых протоколов: TCP/IP, NetNEUI, IPX/SPX.
Одной из основных особенностей InterBase можно считать версионную архитектуру, которая обеспечивает уникальные возможности при многопользовательской работе — пишущие пользователи никогда не блокируют читающих! Помимо этого, версионная архитектура позволяет отказаться от использования протокола транзакций (transction log), который в других СУБД служит для восстановления базы данных после сбоев, поэтому InterBase обладает очень высокой надежностью и устойчивостью.
Также в InterBase реализован механизм оптимистической блокировки на уровне записи. Это означает, что сервер блокирует только те записи, которые реально были изменены пользователем, и не блокирует всю страницу данных целиком. Эта особенность еще больше снижает вероятность конфликтов при многопользовательском режиме.

InterBase полностью совместим со стандартом ANSI SQL 92, а также имеет свое собственное расширение SQL для хранимых процедур и триггеров. В сравнении со многими другими СУБД, InterBase предоставляет очень эффективный механизм триггеров: каждая таблица может иметь большое количество триггеров, которые выполняются автоматически при вставке, изменении или удалении каждой отдельной записи, до или после этих событий. Многие функции существующих СУБД были впервые реализованы в InterBase — это, в частности, обновляемые представления, события (event alerters), многомерные масссивы и BLOB-поля. Более того, некоторые механизмы, такие, например, как двухфазное подтверждение транзакций, до сих пор остаются совершенно уникальными, представленными только в InterBase.
Немаловажной особенностью сервера InterBase является возможность расширения стандартного набора SQL-функций при помощи пользовательских библиотек — User Defined Functions, а также механизмы обработки BLOB-полей на сервере при помощи BLOB-фильтров. Остается только сказать, что InterBase отличается значительной устойчивостью, поскольку специально был спроектирован для применения в Intranet-приложениях, приложениях для мобильных устройств и встроенных приложениях баз данных.

Текущие версии СУБД InterBase

В настоящее время существует несколько клонов серверов InterBase. Есть коммерческая версия, принадлежащая компании Borland — СУБД InterBase версии 5.6. Есть целое семейство серверов InterBase 6.x — Borland InterBase 6.0, 6.5, 7.0, XE, Firebird 3.x и Yaffil (разработка команды программистов из Санкт-Петербурга). Все эти версии основаны на исходном коде Borland InterBase 6.0 и являются практически полностью совместимыми между собой. Системы Borland InterBase 6.0, FireBird 1.x и Yaffil являются Open Source- продуктами, которые можно использовать бесплатно без ограничений на количество пользователей в рамках условий InterBase Public License. Версии Borland 5.6, 6.5 и 7.0, Embarcadero InterBase XE являются коммерческими продуктами и требуют покупки соответствующих лицензий.
Опыт множества внедрений подтверждает, что информационные системы работают быстро и устойчиво на любой из версий InterBase.

Что такое код interbase

InterBase — это система управления реляционными базами данных, поставляемая корпорацией BORLAND для построения приложений с архитектурой клиент-сервер произвольного масштаба: от сетевой среды небольшой рабочей группы с сервером под управлением Novell NetWare или Windows NT на базе IBM PC до информационных систем крупного предприятия на базе серверов IBM, Hewlett-Packard, SUN и т.п.

В пакет Delphi версии входит однопользовательская версия InterBase для Windows — Local InterBase. Используя Local InterBase можно создавать и отлаживать приложения, работающие с данными по схеме клиент-сервер, без подключения к настоящему серверу. В дальнейшем потребуется только перенастроить используемый псевдоним базы данных и программа будет работать с реальной базой без перекомпиляции. Кроме того, Local InterBase можно использовать в приложениях для работы с данными вместо таблиц Paradox.

В данном уроке рассматриваются утилиты, поставляемые в пакете Delphi , которые служат для администрирования баз данных (как локальных, так и на сервере) и для доступа к этим данным посредством SQL запросов.

Некоторые технические характеристики InterBase

Отличия Local InterBase от InterBase для других платформ, в частности, от InterBase для Windows NT:

Local InterBase не поддерживает:

  • функции, определяемые пользователем (UDF).
  • BLOB фильтры
  • сигнализатор событий (event alerters)
  • запись через журнал (Write Ahead Log (WAL))
  • «отключение» и «включение» базы данных (database shutdown or restart)
  • ведение теневой базы данных (database shadowing)

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

Максимальный размер базы данных

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

Максимальное количество физических файлов, из которых может состоять база

В системных таблицах InterBase поле, описывающее из каких файлов состоит база данных, включая все shadow, имеет тип SHORT. Соответственно не более 65,536.

Максимальное количество таблиц в базе данных

65,536. Таблицы нумеруются с использованием типа данных SHORT.

Максимальное количество записей в таблице и полей в записи

В записи может быть не более 1000 полей. Количество записей в таблице не ограничено.

Максимальный размер записи и поля

Запись не может быть больше 64К байт (не считая размера BLOB). Поле не может быть больше 32К байт, размер поля типа BLOB не ограничен.

Максимальное количество индексов в таблице и базе

В базе может быть 64K индексов. В одной таблице — 64 индекса.

Максимальное количество уровней вложенности SQL запроса

16 уровней вложенности.

Максимальное количество полей в составном индексе

Составной индекс может включать в себя не более 16 полей.

Максимальный размер stored procedure или trigger

Stored procedure или trigger может иметь размер кода не более 48K байт.

Количество UDF, определенных в одной базе

Длина имени UDF не более 31 символа. Соответственно максимальное количество UDF в базе ограниченно количеством уникальных имен в пределах этой длины.

InterBase Interactive SQL

В поставке Delphi есть две утилиты для доступа к базам данных и администрации сервера InterBase. Утилита Windows ISQL позволяет интерактивно выполнять SQL запросы к базе данных и получать результат. Это требуется в двух случаях: для отладки SQL выражения и для управления данными и их структурой.


Кроме того, создать базу данных, хранимые процедуры, триггеры, и т.п. также удобнее с помощью ISQL. ISQL позволяет обращаться как к данным на удаленном сервере, так и к локальным (к Local InterBase).

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

После запуска ISQL выберите пункт меню «File|Connect to Database:», появится диалог (см. рис.1), в котором нужно выбрать сервер (удаленный или локальный, в данном случае мы обращаемся к Local InterBase), файл базы данных, указать имя пользователя (SYSDBA — имя системного администратора) и пароль (masterkey — пароль по умолчанию). Если все указано правильно, то по нажатию клавиши «OK» установится соединение с базой данных и можно приступать к дальнейшей работе.

Рис. A: Диалог соединения с базой данных.

Создание новой базы данных

Эту операцию можно выполнить в пункте меню «File|Create Database» (см. рис.2). В диалоге нужно указать имя файла (c:\bases\new_base.gdb), имя и пароль системного администратора (SYSDBA и masterkey), и, при необходимости, дополнительные параметры. В данном случае создается база данных, поддерживающая русскую кодовую страницу WIN1251. Если Вы собираетесь работать из ISQL с базой данных в русской кодировке, то перед установкой соединения нужно в пункте меню «Session|Advanced Settings» установить «Character set on connect» в WIN1251.

Рис. B: Диалог создания новой базы данных

Получение информации о структуре базы данных

В ISQL можно получить полную информацию о структуре базы данных: список таблиц и их структуры, списки и текст триггеров, хранимых процедур и т.п. Эту операцию можно выполнить в пункте меню View или Extract. Например, для базы данных из поставки Delphi (лежит в \IBLOCAL\EXAMPLES\EMPLOYEE.GDB), попробуем выбрать «Extract|SQL Metadata for Table» для таблицы COUNTRY. В окошке ISQL Output появится текст SQL запроса, который создавал данную таблицу:

Выполнение SQL запросов

Текст SQL запроса вводится в окошке «SQL Statement». Для запуска его на выполнение, нажмите кнопку «Run». На рис.3 приведен результат работы примерного запроса.

Рис. C: Окно ISQL с текстом и результатом выполнения SQL запроса.

InterBase Server Manager

Утилита предназначена для администрирования InterBase. С ее помощью можно выполнить следующие операции:

  • определить пользователей и их пароли
  • произвести резервное копирование
  • удалить «мусор» из базы
  • завершить/откатить зависшие транзакции
  • произвести проверку базы на наличие ошибок

Рис. D: Утилита для администрирования InterBase

Соответствующий диалог показан на рис. 5

Рис. E: Диалог резервного копирования базы данных.

Обычно, операционные системы сами предоставляют возможности по сохранению баз данных в архивах. Однако, при резервном копировании, проведенном с помощью Server Manager, выполняются дополнительные операции. При этом:

  • Увеличивается быстродействие базы. В процессе копирования/восстановления происходит «сбор мусора» — в базе данных освобождается место, занятое удаленными записями. Тем самым уменьшается физический размер базы. При восстановлении можно изменить размер страницы и разбить базу на несколько файлов.
  • Резервное копирование может выполняться на работающей базе, для этого не надо отключать пользователей от нее. При этом, изменения, вносимые в базу данных после начала процесса копирования, не записываются в резервный файл.
  • Данные можно перенести на другую операционную систему. Различные компьютеры имеют собственные форматы файлов баз данных и эти файлы нельзя просто перенести на другую операционную систему. Для выполнения этой операции нужно создать резервную копию базы в транспортном формате.
Илон Маск рекомендует:  Открытие ссылки в родительском окне

Создание базы данных в InterBase

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

Мы разработаем базу данных в InterBase!

Реляционная база данных – это система таблиц, связанных между собой. Вот такое простое определение :)

Сотрудник компании IBM Эдгар Кодд в 1970 году предложил реляционную модель баз данных. За базовую структуру данных в реляционной модели принято отношение (relation).

Но Питер Чен был крайне не согласен с Эдгаром и поэтому в 1976 году предложил интерпретировать реляционные структуры данных (отношения), как набор сущностей и связей между ними.

А еще во времена СССР и даже раньше писали учебники для школьников и решили, что отношения и сущности проще будет называть таблицами, а на связи между ними забили :)

Вот что получилось в результате длинного пути развития человечества, помни: все эти слова синонимы!

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

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

Вообще наличие у каждой таблицы ключа необязательно, но его отсутствие – дурной тон, поэтому в каждой таблице определяй первичный ключ! Первичный ключ таблицы — важный элемент в структуре базы данных. Они — основа твоей системы, когда ты захочешь найти определённую строку в таблице, ты будешь ссылаться на этот первичный ключ.

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

Если что-то не понятно, сильно не беспокойся – на практике все достаточно просто!

Представь, что к тебе пришел умный дядька и просит тебя написать ему программу, которая организует прозрачность работы автомойки (на самом деле компания не имеет принципиального значение, ну у нас пусть будет автомойка :). А что такое прозрачность? Прозрачность в данном контексте означает то, что есть система, которая хранит все операции автомойки и позволяет следить за бизнесом.

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

• Таблица (справочник) ПЕРСОНАЛ (PERSONAL)

PERSONALID Поле – счетчик Число FIO Фамилия Имя Отчество сотрудника Текст (40) DATA_BD Дата рождения сотрудника Дата TEL Номер телефона Текст (20), текст лучше массива цифр, сам поймешь на практике

• Таблица ГРАФИК РАБОТЫ (GRAFWORK)

WORKID Поле – счетчик Число PERSONALKOD Вторичный ключ, для связи с таблицей «ПЕРСОНАЛ» Число NOTE Описание графика работы Текст (150) DATA Дата занесения записи в таблицу Дата

• Таблица КЛИЕНТЫ (CLIENT)

CLIENTID Поле – счетчик Число FIO Фамилия Имя Отчество клиента Текст (40) DATA_BD Дата рождения клиента Дата TEL Номер телефона Текст (20)

• Таблица АВТОМОБИЛИ (CAR)

CARID Поле – счетчик Число CLIENTKOD Вторичный ключ, для связи с таблицей «КЛИЕНТЫ» Число MARK Марка автомобиля Текст (30) NUMCAR Номер автомобиля Текст (10) NOTE Примечание Текст (150)

• Таблица ОПЕРАЦИИ (OPERATION)

OPERID Поле – счетчик Число PERSONALKOD Вторичный ключ, для связи с таблицей «ПЕРСОНАЛ» Число CLIENTKOD Вторичный ключ, для связи с таблицей «КЛИЕНТЫ» Число DATA Дата совершения операции Дата NOTE Примечание Текст (150)

• Таблица СЕРВИСЫ (TSERVICE)

TSERVICEID Поле – счетчик Число OPERKOD Вторичный ключ, для связи с таблицей «ОПЕРАЦИИ» Число SERVICEKOD Вторичный ключ, для связи со справочником «УСЛУГИ» Число

• Таблица (справочник) УСЛУГИ (SERVICE)

SERVICEID Поле – счетчик Число NAME Название услуги Текст (30) COST Цена услуги Число (4 цифры для целой части, 2 цифры – дробной)

По поводу двух последних таблиц: в SERVICE мы заносим все услуги предоставляемые автомойкой, а TSERVICE необходима для связи справочника УСЛУГИ (SERVICE) с таблицей ОПЕРАЦИИ (OPERATION). Дело в том, что клиент может заказать несколько услуг, и чтобы они все принадлежали одной операции нужна таблица TSERVICE.

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

Чтобы вообще все стало понятно, посмотри диаграмму (рис. 1), на которой изображены все семь таблиц и показаны связи между ними.

Рис. 1. ER-диаграмма.

Приведенная диаграмма выполнена в нотации IDEF1X (Integration Definition for Function Modeling), разработанной Т.Рэмей.

В этой нотации:

— поля, определяющие первичный ключ, размещаются наверху списка и отделяются от других полей горизонтальной чертой;

— связи таблиц типа «один-ко-многим» изображают линиями, которые на одном конце заканчиваются кружком. Связь «один-ко-многим» на примере таблиц «CLIENT» и «CAR» означает, что у одного клиента может быть несколько автомобилей, т.е. запись о данном клиенте в «CLIENT» одна, а в «CAR» может быть несколько записей, относящихся к данному клиенту!

— связи таблиц типа «один-к-одному» изображают линиями. Это жесткие связи таблиц, то есть любой одной записи из первой таблице соответствует одна определенная запись из второй. Как ты уже заметил, в нашей диаграмме таких связей нет, они могли быть, если б мы разбили таблицу «PERSONAL» на две, выделив в отдельную таблицу список дат рождения, но это крайне дурацкая затея :) а потому она отметается!
Наша диаграмма еще с 1976 года стала называться ER-диаграммой (Entity-Relationship, сущность-связь) – стандартный способ детализации хранилищ данных.

С постановкой задачи разобрались! Теперь за практику!

Установка InterBase 7.5

Я решил использовать InterBase 7.5. Именно 7.5! Потому что люблю использовать последние версии программных продуктов, так как в новых версиях появляется много интересных фишек и исправлена добрая куча ошибок, замеченных в предыдущих версиях ПО. Но о том, что в свежей версии всегда есть куча новых багов лучше не думать :)

Рис.2 Установка IB 7.5.

Кликай на кнопку ‘Next’, выбирай тип установки ‘Server and Client’ и еще несколько раз жми на ‘Next’.
Вот и вся установка!

Теперь в Пуске появился новый пункт меню:

Пуск – Программы – InterBase 7.5 Developer Edition.

Все, теперь можно приступать к запуску InterBase, для этого запусти IBConsole:

Пуск – Программы – InterBase 7.5 Developer Edition – IBConsole.

После запуска появится окно, изображенное на рис.3.

Нам нужно зарегистрировать сервер InterBase, для этого лезь в меню “Server” и выбирай “Register …”, появится окошко, заполни его так чтобы получилось что-то вроде этого (рис.4):

Мы будем создавать базу на своем компе, поэтому выбирай Local Server. В поле Description введи описание нашего сервера. В поле Login Information – вводим логин и пароль админа базы данных, по умолчанию он будет (не знаю почему, но введи именно эти данные, потом можно будет добавлять и удалять пользователей):

User Name: SYSDBA
Password: masterkey

Жми «Ok» – сервер зарегистрирован!

Обязательно создай папку, где ты хочешь сохранить свою базу данных (вся твоя база будет состоять из одного GDB-файла!).
Теперь создадим базу данных – выбираем пункт меню “Database” – “Create Database …”
Появится следующее окно (рис.5.):

Указываем название файла базы данных и его месторасположение, в одной из строк списка Files.

Список Default Character Set не трогай! Если на твоем компе используется русский язык (то есть в настройках винды указано что ты в России), то русские буквы будут поддерживаться твоей базой.

В поле Alias вводим произвольный псевдоним.

Жмем ОК, база создана, окно IBConsole стала такой (рис.6.):

Теперь все готово, можно переходить непосредственно к реализации того, что мы разобрали в Постановке задачи.

InterBase версии 7.5 позволяет манипулировать данными с помощью гуя, но мы все будем делать через утилиту Interactive SQL, так как с интерфейсом я думаю ты и так разберешься, а вот основные команды SQL тебе пригодятся.

Запускай утилиту Interactive SQL, выбрав в меню Tools – Interactive SQL, появится окошко (рис.7):


Определение типов данных таблиц

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

Введи в окне Interactive SQL следующий SQL-скрипт:

CREATE DOMAIN dnDB AS DATE
CHECK (Value 0)
NOT NULL;
commit;

CREATE DOMAIN dnNOTE AS CHAR(150);
commit;

CREATE DOMAIN dnNAME AS CHAR(30);
commit;

CREATE DOMAIN dnNumCar AS CHAR(10);
commit;

CREATE DOMAIN dnCost AS NUMERIC(4, 2)
CHECK (VALUE > 0)
NOT NULL;
commit;

Жми CTRL+E, у тебя должны создаться 9 доменов (рис.9)

Введи в окне Interactive SQL следующий код:

CREATE TABLE Personal (
PersonalID dnNum,
FIO dnFIO,
DATA_BD dnDB,
TEL dnTEL,

PRIMARY KEY (PersonalID)
);
commit;

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

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

Командой PRIMARY KEY определяем первичный ключ.
Не знаешь что такое первичный ключ? Бегом в начало статьи я об этом подробно писал!

Жми кнопку «Высокого напряжения» — третья справа, вуаля, таблица создана.

Не останавливаемся на достигнутом, создаем еще 6 таблиц:

CREATE TABLE Client (
ClientID dnNum,
FIO dnFIO,
DATA_BD dnDB,
TEL dnTEL,

PRIMARY KEY (ClientID)
);
commit;

CREATE TABLE GrafWork (
WorkID dnNum,
PersonalKod dnNum,
Note dnNOTE,
Data dnDATA,

PRIMARY KEY (WorkID),
FOREIGN KEY (PersonalKod) REFERENCES Personal (PersonalID)
);
commit;

CREATE TABLE Car (
CarID dnNum,
ClientKod dnNum,
Mark dnNAME,
NumCar dnNUMCAR,
Note dnNOTE,

PRIMARY KEY (CarID),
FOREIGN KEY (ClientKod) REFERENCES Client (ClientID)
);
commit;

CREATE TABLE Service (
ServiceID dnNum,
Name dnNAME,
Cost dnCOST,

PRIMARY KEY (ServiceID)
);
commit;

CREATE TABLE Operation (
OperID dnNum,
PersonalKod dnNum,
ClientKod dnNum,
Data dnDATA,
Note dnNOTE,

PRIMARY KEY (OperID),
FOREIGN KEY (PersonalKod) REFERENCES Personal (PersonalID),
FOREIGN KEY (ClientKod) REFERENCES Client (ClientID)
);
commit;

CREATE TABLE TService (
TServiceID dnNum,
OperKod dnNum,
ServiceKod dnNum,

PRIMARY KEY (TServiceID),
FOREIGN KEY (OperKod) REFERENCES Operation (OperID),
FOREIGN KEY (ServiceKod) REFERENCES Service (ServiceID)
);
commit;

Команда «FOREIGN KEY (PersonalKod) REFERENCES Personal (PersonalID)» связывает таблицу GRAFWORK и PERSONAL.

Чтобы разобраться со всеми связями обратись к ER-диаграмме, на самом деле, здесь все просто.

Жми CTRL+E, у тебя должны создаться 7 таблиц (рис.10):

В Interbase нет такого типа как счетчик или autoincrement, выход из этой ситуации обеспечивается созданием, так называемого генератора!

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

Вызываем Interactive SQL, пятая кнопка справа. Пишем запрос:

CREATE GENERATOR GEN_CAR;

Нажимаем выполнить.
Мы создали генератор GEN_CAR. Теперь нам надо установить начальное значение генератора, делается это следующим образом:

SET GENERATOR GEN_CAR TO 0;

Нажимаем выполнить.
При этом запрос выполнится, и окно запросов очиститься.

Остальные генераторы создаются аналогично:

CREATE GENERATOR GEN_CLIENT;
commit;

SET GENERATOR GEN_CLIENT TO 0;
commit;

CREATE GENERATOR GEN_GRAFWORK;
commit;

SET GENERATOR GEN_GRAFWORK TO 0;
commit;

CREATE GENERATOR GEN_OPERATION;
commit;

SET GENERATOR GEN_OPERATION TO 0;
commit;

CREATE GENERATOR GEN_PERSONAL;
commit;

SET GENERATOR GEN_PERSONAL TO 0;
commit;

CREATE GENERATOR GEN_SERVICE;
commit;

SET GENERATOR GEN_SERVICE TO 0;
commit;

CREATE GENERATOR GEN_TSERVICE;
commit;

SET GENERATOR GEN_TSERVICE TO 0;
commit;

Теперь жми CTRL+E, у тебя должно получится вот так (рис. 11):

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

SET TERM !!;
CREATE TRIGGER «BEF_INS_CAR» FOR «CAR»
ACTIVE BEFORE INSERT
AS
BEGIN
NEW.CAR > END!!
SET TERM ;!!
commit;

Выполняем запрос! Опаньки, наш генератор теперь введен в работу :)

Конструкция SET TERM задает новый разделитель операторов. Если ее не использовать, то получится, что у тебя и после NEW.CAR >
Также хочу обратить твое внимание на то, что в строках:

SET TERM !!;
SET TERM ;!!

после TERM необходимо поставить пробел, а между «!!» и «;» ставить пробел необязательно! С этой проблемой я столкнулся при переходе на версию 7.5, в IB6 скрипты работали без разделения пробелом «TERM» и «!!;».

Рассмотрим поподробней, что же мы накодили:

Create Trigger – говорит, что мы хотим создать триггер (правило), далее указываем название триггера и для какой таблицы он будет предназначен (FOR «CAR»).
Предложение ACTIVE BEFORE INSERT – указывает, когда триггер должен выполняться, в данном случае, каждый раз перед созданием новой записи. Слово AS – зарезервированное, открывает тело триггера. Тело триггера всегда (даже если триггер содержит единственный оператор – как в нашем случае) должно ограничиваться парой ключевых слов BEGIN – END. В шестой строке расположен оператор, в котором новому значению (слово NEW) поля CARID присваивается значение, полученное от встроенной функции GEN_ID. Двумя параметрами обращения к этой функции указывается имя генератора и то значение, на которое должно увеличиться текущее значение генератора («шаг» генератора).

Создаем остальные триггеры:

SET TERM !!;
CREATE TRIGGER «BEF_INS_CLIENT» FOR «CLIENT»
ACTIVE BEFORE INSERT
AS
BEGIN
NEW.CLIENT > END!!
SET TERM ;!!
commit;

SET TERM !!;
CREATE TRIGGER «BEF_INS_GRAFWORK» FOR «GRAFWORK»
ACTIVE BEFORE INSERT
AS
BEGIN
NEW.WORK > NEW.DATA = ‘TODAY’;
END!!
SET TERM ;!!
commit;

SET TERM !!;
CREATE TRIGGER «BEF_INS_OPERATION» FOR «OPERATION»
ACTIVE BEFORE INSERT
AS
BEGIN
NEW.OPER > NEW.DATA = ‘TODAY’;
END!!
SET TERM ;!!
commit;

SET TERM !!;
CREATE TRIGGER «BEF_INS_PERSONAL» FOR «PERSONAL»
ACTIVE BEFORE INSERT
AS
BEGIN
NEW.PERSONAL > END!!
SET TERM ;!!
commit;

SET TERM !!;
CREATE TRIGGER «BEF_INS_SERVICE» FOR «SERVICE»
ACTIVE BEFORE INSERT
AS
BEGIN
NEW.SERVICE > END!!
SET TERM ;!!
commit;

SET TERM !!;
CREATE TRIGGER «BEF_INS_TSERVICE» FOR «TSERVICE»
ACTIVE BEFORE INSERT
AS
BEGIN
NEW.TSERVICE > END!!
SET TERM ;!!
commit;

Выполняй запрос. Теперь все генераторы связаны со своими таблицами.

В теории баз данных есть такая фишка: каскадное удаление данных, то есть при удалении строки из родительской таблицы происходит автоматическое удаление данных из дочерних таблиц. В нашем случае, например, тебе захочется удалить какого-нибудь сотрудника из таблицы «PERSONAL», но в «GRAFWORK» есть информация о графике работы этого сотрудника и в «OPERATION» находятся все операции совершенные им. То есть если сотрудник исчезнет, в связанных таблицах данные «повиснут», и твоя база будет засорена.

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

Заходи в Interactive SQL и пиши:

SET TERM !!;
CREATE TRIGGER «BEF_DEL_PERSONAL» FOR «PERSONAL»
ACTIVE BEFORE DELETE
AS
BEGIN
DELETE FROM «GRAFWORK» WHERE GRAFWORK.PERSONALKOD=PERSONAL.PERSONALID;
DELETE FROM «OPERATION» WHERE OPERATION.PERSONALKOD=PERSONAL.PERSONALID;
END!!
SET TERM ;!!
commit;

Жми CTRL+E, получишь триггер.

Мы создали триггер «BEF_DEL_PERSONAL» для таблицы «PERSONAL», который будет срабатывать перед удаление строки (ACTIVE BEFORE DELETE), выполняя удаление из таблицы «GRAFWORK» и «OPERATION» (DELETE FROM . ).

Теперь сделай еще два триггера с помощью скрипта:

SET TERM !!;
CREATE TRIGGER «BEF_DEL_OPERATION» FOR «OPERATION»
ACTIVE BEFORE DELETE
AS
BEGIN
DELETE FROM «TSERVICE» WHERE TSERVICE.OPERKOD=OPERATION.OPERID;
END!!
SET TERM ;!!
commit;

SET TERM !!;
CREATE TRIGGER «BEF_DEL_CLIENT» FOR «CLIENT»
ACTIVE BEFORE DELETE
AS
BEGIN
DELETE FROM «CAR» WHERE CAR.CLIENTKOD=CLIENT.CLIENTID;
DELETE FROM «OPERATION» WHERE OPERATION.CLIENTKOD=CLIENT.CLIENTID;
END!!
SET TERM ;!!
commit;

Выполни скрип, у тебя получатся вот такие триггеры (рис.12):

Всё готово.
Можешь кричать: «Ура!» и радостно бегать по комнате :)


Использование базы данных

Чтобы от нашей базы была хоть какая-то польза необходимо внести в нее информацию.

Можно, конечно, это сделать с помощью интерфейса IBConsole, но я опять-таки рекомендую юзать Interactive SQL. Запускай его, выбирай меню Querty – Load Script, находи в моих исходниках папку ‘sql’ и выбирай файл ‘insert.sql’ жми Ok.

Скрипт загрузится из файла в твое окошко, выполняй запрос и начинай изучать свою базу!

Можешь вносить свои данные и изменять старые. Удалять строки из таблиц, проверяя, как действует каскадное удаление.

Если ты заметил, в папке ‘sql’ есть еще несколько файлов, так вот в них содержатся все скрипты по созданию БД описанные выше! Теперь ты понял фишку использования SQL-скриптов? Сейчас ты в любой момент можешь заново создать свою базу буквально за 30 секунд :) Тебе достаточно в нужном порядке выполнять скрипты, а именно:

1. domain.sql
2. table.sql
3. generator.sql
4. trigger.sql
5. insert.sql

Ну, вот и все! Что знал – написал!

Помни: в этой статье изложены лишь основы БД (на примере InterBase), так сказать, чтоб ты был в курсе. Настоятельно рекомендую продолжить изучать СУБД, так как дело прибыльное и интересное ;)

Madin, 02.01.2006

Роли SQL: пользователи и безопасность в InterBase

Brett Bandy, Markus Kemper, BorCon, 1998.

Что такое пользователь InterBase?

Безопасность InterBase основана на концепции «пользователя» (user). Безопасность всей базы данных, в сущности, зависит от проверки подлинности идентификатора пользователя. Информация о пользователях , зарегистрированных для конкретного сервера InterBase, хранится в особой базе данных безопасности (security database) – ISC4.GDB (из-за проблем с резервированием файлов с расширением gdb в Windows XP в IB7 этот файл переименован в ADMIN.IB, в FB1.5 – в SECURITY.FDB. В обоих случаях для сервера можно указать иное имя). Для каждого сервера InterBase существует своя собственная база данных безопасности, таким образом, пользователь «привязан» к конкретному серверу. Пользователь с таким же именем может существовать на нескольких серверах, но для этого информация о нем должна быть заведена на каждом из серверов. В базе данных безопасности также для каждого пользователя хранится зашифрованное значение пароля. Пользователь, авторизованный на сервере, имеет доступ ко всем базам данных этого сервера.

Имя пользователя может состоять максимум из 31 символа, при этом их регистр не учитывается. Пароль может состоять максимум из 8 символов (если ввести больше, лишние символы игнорируются), регистр – учитывается.

KDV: механизм логина на сервере следующий – клиентская часть, принимая пароль пользователя, шифрует его алгоритмом DES с потерей данных (см. раздел www.ibase.ru/d_security.htmLINK), после чего передает зашифрованный пароль на сервер. Сервер, приняв пароль, шифрует его еще раз тем же алгоритмом, и сравнивает со строкой, хранящейся в таблице users базы isc4.gdb. Т. е. пароль никогда не дешифруется в исходный вид, и это сделать невозможно. Даже перехватив «полузашифрованный» пароль на этапе его пересылки с клиента на сервер единственным способом «взлома» остается только прямой подбор пароля.

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

Поле Обязательно? Тип Описание
User Name Yes String Имя пользователя, указываемое при подключении
Password Yes String Пароль пользователя
UID No Integer Необязательный UserID. В данный момент поле не используется
GID No Integer Необязательный GroupID. В данный момент поле не используется
Full Name No String Полное имя пользователя

Расширение списка пользователей InterBase пользователями ОС

Все версии InterBase используют базу данных безопасности для аутентификации пользователей, при этом некоторые версии позволяют организовать разграничение доступа на основе системы разграничения доступа операционной системы. Версии InterBase, работающие под управлением Unix, позволяют при подключении к серверу InterBase или его базам использовать либо учетные записи операционной системы, либо учетные записи InterBase. Версии, работающие под Win95 или NT, не позволяют использовать систему разграничения доступа этих операционных систем, соответственно, пользователи Win95 или NT не являются легальными пользователями InterBase. В данном случае,для аутентификации пользователей, InterBase полностью полагается на свою базу данных безопасности.

В случае с Unix, InterBase будет трактовать пользователя Unix точно так же как и пользователя, хранящегося в собственной базе данных InterBase, до тех пор, пока сервер видит клиента в качестве доверенного хоста. Учетные записи пользователя должны существовать как на клиенте, так и на сервере. Для того чтобы установить доверительные отношения с хостом клиента, необходимо на сервере занести соответствующую запись в файл /etc/hosts.equiv или /etc/gds_hosts.equiv. В файле hosts.equiv прописываются доверительные отношения на уровне операционных систем, которые, соответственно, распространяются на все сервисы (например, rlogin, rsh, rcp). В файле gds_hosts.equiv устанавливаются доверительные отношения между хостами, только для InterBase. Формат записи идентичен для обоих файлов, и выглядит следующим образом:

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

Системные учетные записи Unix используются если при установлении соединения с сервером InterBase не указывается имя пользователя.

Пользователь SYSDBA

KDV: 10 января 2001 в исходных текстах IB 6.0 была обнаружена дыра в безопасности – вкомпилированный в код сервера username/password (politically/correct). Однако, пользователь зайдя под таким account ничего не может делать (только просматривать сист. таблицы). Кроме того, username должен быть введен в нижнем регистре, а подавляющее количество инструментария (99%) автоматически при вводе конвертируют username в верхний регистр. Для 5.6, 6.0, и FB 0.9.3 был выпущен патч (IBPhoenix, Embarcadero). В версии 6.0.1 и выше эта дыра закрыта.

Управление пользователями

KDV: сейчас ServerManager уже нет, и можно пользоваться IBConsole, IBExpert, GrantManager и т. п. – www.ibase.ru/d_security.htmLINK). Кроме этого добавился еще один способ – через Services API (который пока не полностью работает в версиях > Команда Описание di[splay] Показывает информацию обо всех пользователях из базы ISC4.GDB di[splay] name Показывает информацию о пользователе name a[dd] name -pw passwd [option argument option argument . ] Добавляет пользователя с именем name, паролем passwd и дополнительной информацией mo[dify] name [options] Изменяет атрибуты пользователя de[lete] name Удаляет информацию о пользователе с именем name из ISC4.GDB h[elp] Показывает синтаксис команд GSEC q[uit] Завершает сеанс

Просмотр информации о пользователях

Добавление пользователя

Чтобы добавить нового пользователя в базу данных безопасности необходимо использовать команду ADD.

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

Опция Описание
-pw Пароль пользователя
-u[id] ID пользователя
-g[id] ID группы
-f[name] Имя пользователя (first name)
-mn[ame] Отчество пользователя (middle name)
-l[name] Фамилия пользователя (last name)

В следующем примере заводится пользователь BJONES с паролем «blah» и указываются его имя и фамилия:

Изменение информации о пользователе

Удаление пользователя

Использование InterBase API для управления пользователями

KDV: далее описание функций isc_add_user, isc_modify_user, isc_delete_user и примеры удалены для сокращения объема статьи. Примеры на C см. в API Guide, примеры на Delphi – ibusers.zip. Пример использования всех InterBase Admin (services api) компонент – AdminDemo.
KDV: при использовании функций user api есть одна проблема – вы должны передавать в вызове username/password SYSDBA. Для приложений, которые дают возможность пользователям самим модифицировать свой пароль, это неприемлемо. Проблема решается только через модификацию ISC4.GDB: дается GRANT UPDATE ON USERS TO PUBLIC после чего на таблице users создается exception и триггер before update: if USER <> ‘new.USER’ then exception NOTALLOWED; Таким образом пользователю разрешается менять только свой, а не чужой пароль. Подробнее этот способ и другие модификации isc4.gdb описан в документе.

Логин по умолчанию

Существует возможность определить username/password, который будет использоваться клиентской частью (gds32.dll) по умолчанию. Это делается при помощи переменных среды ISC_USER/ISC_PASSWORD. Если вы укажете в этих переменных имя пользователя и пароль, то при «пустой» информации при логине к серверу будут использоваться именно эти имя и пароль.
Однако, не все инструменты или программы позволяют ввести пустой username.

Данными переменными среды удобно пользоваться для административных целей, например, при ремонте БД или других операциях, однако нужно учитывать интересную особенность – если эти переменные среды определены на серверной стороне, то клиент также может осуществить «логин по умолчанию» не указывая username/password! Поэтому, если вы и используете данную возможность, то определяйте переменные среды только для контекста пользователя, но не для всей системы (см. закладки User и System в MyComputer/Properties/Advanced/Environment variables).

Привилегии SQL: Второй уровень безопасности

Как уже отмечалось, в InterBase реализована двухуровневая модель безопасности. На первом уровне осуществляется аутентификация пользователя в момент подключения к базе данных, при этом используется база данных безопасности (более подробно см. предыдущий раздел). Второй уровень реализуется уже на уровне самой базы данных. Все привилегии по доступу к объектам базы данных хранятся в самой базе. Авторизованный пользователь не имеет никаких привилегий по доступу к данным, хранящимся в базе, пока какие-либо права не будут ему предоставлены явным образом. Контроль привилегий осуществляется на уровне таблиц. Каждому пользователю сопоставлен список операций, которые допускается произвести над данной таблицей или представлением. Этот список и составляет привилегии пользователя. Возможность использования хранимых процедур в InterBase регулируется отдельной привилегией. Право на доступ к любому объекту базы данных после его создания имеют только SYSDBA и владелец этого объекта. Владельцем объекта является пользователь создавший этот объект. SYSDBA или владелец объекта могут выдавать привилегии другим пользователям, в том числе и привилегии на право выдачи привилегий другим пользователям. Собственно сам процесс раздачи привилегий на уровне SQL реализуется двумя операторами: GRANT и REVOKE. Оператор GRANT выдает привилегии авторизованным пользователям на доступ к таблицам или представлениям, а оператор REVOKE, соответственно, изымает ранее выданные привилегии.

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

Для всех операций, связанных с управлением безопасностью, SYSDBA всегда имеет права назначать и отменять привилегии пользователям. SYSDBA – это суперпользователь, которому невозможно отменить доступ к какому-либо объекту базы данных. Соответственно, операторы GRANT и REVOKE не имеют смысла в отношении пользователя SYSDBA.

Оператор GRANT

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

Привилегия Пользователь получает возможность.
Insert Добавлять новые строки в таблицу
Update Изменять данные в таблице
Delete Удалять строки из таблицы
Select Извлекать содержимое таблицы
Execute Выполнить хранимую процедуру ( в том числе и как select)
References Сервер может проверять внешние ссылки на другие таблицы
All Делать все выше обозначенные, за исключением Execute
KDV: существование пользователя, которому выдаются права, не проверяются при выполнении оператора grant. Помните, что пользователи существуют в isc4.gdb. Права же в базе данных могут быть выданы каким угодно, в том числе несуществующим (пока или по ошибке) пользователям.

Назначение привилегий пользователю PUBLIC

Назначение привилегий на выполнение хранимых процедур

KDV: начинающие пользователи часто опускают слово procedure думая что to name самостоятельно определит, что name – это имя процедуры. Это не так. При выдаче прав to name означает выдачу права именно пользователю, а не объекту вообще. Кроме того, существование таких пользователей не проверяется (они находятся в isc4.gdb).

KDV: при модификации процедур (alter) права, выданные им, сбрасываются.

KDV: права, выданные процедуре, проверяются сразу при ее загрузке в память для выполнения, а не по ходу выполнения процедуры. Это значит, что если в коде процедуры (или триггера) есть обращение к объекту при каком то условии (if . then), то права на этот объект должны быть даны процедуре обязательно. В противном случае при выполнении процедуры сразу будет выдана ошибка о нехватке прав, даже если по всем условиям данная ветка if не выполняется.

Назначение привилегий для представлений

В основном, процесс назначения привилегий для представлений соответствует аналогичному процессу для таблиц. Но, имеются некоторые особенности, которые хотелось бы отметить. Необходимо помнить, что представление это своего рода «виртуальная» таблица, представляющая собой запрос в базовую таблицу. Данные, извлекаемые по этому запросу, не хранятся в представлении. В самом представлении храниться только описание запроса, соответственно, любой запрос типа INSERT, UPDATE или DELETE предполагает модификацию базовой таблицы. Поэтому, привилегии типа INSERT, UPDATE или DELETE имеет смысл выдавать только для обновляемых представлений. В общем случае, обновляемое представление – это представление, в запросе которого не используются агрегатные функции и нет соединений (более подробно, например, см. [2]). Хотя и разрешается выдавать привилегии INSERT, UPDATE, или DELETE на представления только для чтения без каких-либо сообщений об ошибке, любая попытка изменения данных через такое представление успеха не достигнет. Привилегию SELECT для доступных только на чтение представлений можно использовать, например, с целью контроля доступа за тем, какие конкретно пользователи могут извлекать из него данные.

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

Например, представим себе таблицу TEST_SCORES, содержащую поля LASTNAME, FIRSTNAME, TESTNAME, SCORE. Столбцы LASTNAME, FIRSTNAME и TESTNAME таблицы содержат информацию, доступную для всех пользователей – в них хранится информация о том, кто проходил какие тесты. Но есть также информация, которую не следовало бы делать доступной для всех категорий пользователей – поле SCORE (результаты). Соответственно, необходимо обеспечить всем пользователям доступ к определенному набору полей таблицы TEST_SCORES, и только некоторым избранным ко всем полям, включая и поле SCORE. Это можно реализовать, создав представление, на основе запроса, выбирающего необходимый набор полей, доступный для каждого пользователя, и выдав привилегии всем пользователям на доступ только к этому представлению, а не к таблице:

KDV: механизм выдачи прав на view несколько отличается от других прав, выдаваемых объектам. Например, не требуется выдавать право view на доступ к таблице, к которой обращается view.

Примеры использования оператора GRANT

Предоставление прав с GRANT OPTION

Оператор REVOKE

Только тот пользователь, который выдавал ранее привилегию, может удалить её. Например, если пользователь А предоставил какую-либо привилегию пользователю Б, то пользователь В не сможет отнять её у пользователя Б. Только у пользователя А имеется такое право. Пользователь SYSDBA всегда может предоставить и/или отменить любую привилегию любому пользователю.

Привилегия ALL объединяет привилегии SELECT, INSERT, UPDATE, DELETE и может использоваться для упрощения отмены множества привилегий пользователя. Для того, чтобы использовать аргумент ALL в выражении отмены прав, необязательно, чтобы пользователь обладал всеми привилегиями, включаемыми в ALL. При отмене привилегии ALL, он потеряет подмножество привилегий ALL. Например, предположим, что пользователь имеет привилегии INSERT и SELECT, и если SYSDBA выполнит команду REVOKE ALL для данной таблицы, то пользователь больше не будет иметь какие-либо права для этой таблицы.

Выше уже объяснялось, что предложение WITH GRANT OPTION предоставляет право передавать другим пользователям назначаемые привилегии. Пользователь, получивший такое право, может в свою очередь, передать возможность передачи прав другим пользователям. Это может привести к образованию дыр в системе разграничения доступа базы данных. Начиная с того, что только несколько пользователей имеют права предоставления привилегий, очень быстро можно прийти к ситуации, когда уже огромное число пользователей обладают такими возможностями. Для того, чтобы остановить рост своеобразного кома, можно воспользоваться командой отмены привилегий. Отмена привилегий пользователю, предоставленных ему с GRANT OPTION, приводит к тому, что и все другие пользователи, получившие эти привилегии от данного пользователя, также теряют их. Следующая последовательность поясняет сказанное:

  1. Предоставление привилегий пользователю USERA с GRANT OPTION
  2. Пользователь USERA передает права пользователю USERB
  3. Отмена привилегий пользователя USERA
  4. Ни пользователь USERA, ни USERB не имеют привилегий

Последовательность команд GRANT и REVOKE демонстрирующих рассмотренный сценарий:

Отмена привилегий пользователя PUBLIC

Примеры использования оператора Revoke

Отмена привилегии, назначенной с GRANT OPTION

Низкая эффективность средств безопасности SQL

Стандартные средства разграничения доступа SQL (в данном документе под стандартом понимается стандарт SQL-92) позволяют ограничить доступ к данным, однако они недостаточно эффективны с точки зрения управления доступом к данным в целом. SQL ориентирован на работу с индивидуальным пользователем. За исключением пользователя PUBLIC, не имеется возможностей по управлению пользователями на групповом уровне. Более того, механизм привилегий требует, чтобы права назначались непосредственно для каждой таблицы базы данных.

Например, предположим, что администратору необходимо настроить привилегии по доступу к 100 таблицам для 100 пользователей базы данных. В общем случае, для каждого пользователя потребуется выполнить по одной команде на каждую из таблиц. Таким образом, требуется 100 команд только для одного пользователя и, соответственно, 10000 команд для всех пользователей. В команде GRANT для таблиц можно перечислить сразу несколько пользователей, но такой подход может привести ко многим ошибкам. Администратору базы данных потребуется каким-либо образом разделять пользователей между командами и учитывать, кому он уже выдал и какие привилегии к каждой из таблиц. В большинстве случаев, администраторы предпочитают выдавать права для каждого пользователя в отдельной команде.

Трудности управления пользователями средствами безопасности SQL

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

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

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

Слабая гибкость средств безопасности SQL

Что такое роли (SQL Roles)?

В InterBase 5.0 было введено расширение стандартных средств SQL – роли, реализующее концепцию управления безопасностью на групповом уровне. Роли служат своего рода шаблонами для предустанавливаемых наборов привилегий. К обычному механизму привилегий SQL привилегии добавляют преимущество группового управления безопасностью, позволяя определять набор привилегий для нескольких таблиц в базе данных.

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

Роль служит групповым шаблоном для пользователей. В выше приведенном примере, программист может быть одни пользователем или группой пользователей. Роли позволяют, также, пользователям выступать в различных ролях (т.е. получать различные наборы привилегий). Программист в примере, может получать разные привилегии, выступая в разных ролях. Маркетинговая роль, предположим, может иметь один набор привилегий, а роль пользователя совершенно другой.

Идентификация ролей

Аддитивность ролей

Какие экземпляры InterBase поддерживают роли?


Роли доступны в InterBase 5.0 и выше. При переходе с предыдущих версий (4.x) недостаточно просто перенести базу данных на новый сервер, необходимо пройти процедуру backup/restore под новым сервером.

Далее перечислены основные требования и условия применения ролей:

  • Роль связана с базой данных, в которой она создается.
  • Имя роли должно быть уникальным с учетом имен других ролей и имен пользователей.
  • Роли должны указываться при подключении. Пользователь не может сменить роль, без переподключения к базе данных.
  • Для того, чтобы использовать роли, база данных от IB 4.x должна быть восстановлена из резервной копии (backup) на сервере InterBase версии 5.0 или выше. Возможно использование баз данных, созданных сервером версии 4.0, на сервере версии 5.0, при этом роли не будут доступны.

Преимущества ролей

Модель безопасности SQL

Давайте пересмотрим пример с настройкой прав доступа для 100 таблиц 100 пользователям. Мы уже пришли к выводу, что стандартными средствами SQL для полной настройки привилегий 100 пользователям относительно 100 таблиц придется выполнить 10000 команд. При использовании ролей, в лучшем случае – все пользователи получают одинаковые права для всех таблиц, потребуется только 200 команд.

В данном случае, администратор может настроить одну роль, для этого потребуется 100 команд, для назначения роли пользователям потребуется еще 100 команд, итого 200. В общем случае, потребуется 100*n + 100 команд, где n – количество необходимых различных ролей. Например, для 5 ролей необходимо выполнить 600 команд. Т.е. понятно, что использование ролей значительно упрощает процесс настройки безопасности базы данных.

Преимущества ролей при управлении пользователями

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

Для каждого нового пользователя базы данных, при использовании обычных средств SQL, администратору необходимо заново назначать права для каждой таблицы. Роли могут выступать в качестве шаблонов при назначении привилегий для новых пользователей. Т. е. можно определить роль с обобщенным набором привилегий и при добавлении нового пользователя просто назначить ему эту роль. Одним из общих решений, применяемым администраторами для выхода из ситуации с отсутствием группового управления привилегиями, является использование одной общей учетной записи для всех пользователей базы данных.

KDV: бывает и еще хуже – права не разграничивают, и все пользователи логинятся как SYSDBA. В результате невозможно нормально сделать базе shutdown, т. к. SYSDBA может работать в таком режиме (и перевод в shutdown ничего не меняет).

Такой подход упрощает настройку и поддержание привилегий. Основной минус, учитывая, что при подключении все пользователи указывают одно и то же имя – отсутствие возможности как-то различать их на уровне СУБД. Использование ролей в качестве шаблонов позволяет устранить этот недостаток. Администратор, по-прежнему, единовременно настраивает привилегии, на этот раз для роли, а не общего пользователя. При подключении пользователи, как и в случае с одним общим именем, указывают свои регистрационные имена, на этот раз уникальные, и, дополнительно, используемую роль, что позволяет InterBase, поддерживая механизм привилегий, дифференцировать пользователей. Между использованием общего пользователя и роли имеется два различия. Во-первых, пользователь должен указывать роль при подключении. Во-вторых, администратору необходимо всем пользователям выдать право на использование этой роли.

Второе, основное преимущество ролей – управление группами пользователей. Роли определяют концепцию безопасности на уровне групп, позволяя администраторам управлять привилегиями для целых групп пользователей, а не для каждого пользователя в отдельности, как при стандартном подходе SQL.

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

Гибкость ролей

KDV: не следует перебарщивать с раздачей прав, осуществляя это для группы разработчиков из 5-10 человек. Может оказаться, что вы только зря потратите время и усложните жизнь отдельным разработчикам. Лучше потратить это время на планирование и организацию прав доступа для пользователей (приложений).

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

Суммарный привилегии = Привилегии, непосредственно выданные пользователю + Привилегии, назначенные используемой роли.

Продолжая рассматривать пример с жизненным циклом программного продукта, предположим, что пользователь BJONES получил право использовать роль QA. BJONES несёт ответственность за ежемесячный подсчет количества изменений, внесенных разработчиками в исходный код. Учитывая, что ему выдано право на использование только роли QA, он не может получить доступ к таблицам, используемым в разработке. Администратор, в свою очередь, не хотел бы назначать BJONES роль DEVELOPMENT, потому что необходимые права являются лишь подмножеством привилегий, имеющихся у роли DEVELOPMENT. В этом случае, администратор может выдать требуемый набор привилегий непосредственно пользователю. Тогда при подключении с указанием роли QA, BJONES будет обладать привилегиями как по доступу к подмножеству таблиц, используемым в разработке, так и к таблица, используемым в тестировании продукта. Исходя из «соединительной» природы ролей, BJONES получает привилегии, назначенные используемой роли, плюс привилегии, непосредственно выданные ему администратором.

Применение ролей

Создание роли

KDV: одним из «хакерских» способов защиты БД от доступа SYSDBA (при распространении приложений с базами данных) является создание роли SYSDBA, после чего пользователь SYSDBA к базе логиниться не может. Однако, нельзя гарантировать что такое поведение останется во всех будущих версиях InterBase и его клонах. Например, в Firebird 1.5 RC5 для создания роли SYSDBA база должна быть создана не от имени SYSDBA, а также не должна иметь объектов, созданных SYSDBA.

Предоставление привилегий роли

Назначение роли пользователю

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

Оператор предоставления пользователю права использования роли имеет следующий синтаксис:

Использование роли

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

Распространенная ошибка: Часто встречается неправильное представление о механизме ролей, что после того как пользователю назначили роль, он сразу же получает все привилегии, выданные этой роли. Это неверно. Чтобы пользователь приобрел все привилегии, назначенные роли, он должен указать эту роль при подключении к базе данных. Если же пользователь при подключении не указал имя роли, то ему не будут доступны ни одна из привилегий этой роли.

Ниже приведен пример подключения пользователя BJONES к базе данных с указанием роли FULL_ACCESS. В примере используется ISQL, утилита InterBase интерактивного выполнения команд SQL:

InterBase

ЛАБОРАТОРНАЯ РАБОТА №1

InterBase представляет собой полнофункциональный SQL-сервер. Сервер баз данных — это программа или служба, которая выполняется на сетевом компьютере (сервере), где физически расположена сама база данных. На этом курсе мы изучим установку сервера InterBase версии 6.5, который входит в поставку Delphi 7. InterBase — очень надежный сервер БД, при этом он не требователен к ресурсам ПК, благодаря чему является одним из самых популярных SQL-серверов на рынке программного обеспечения. Благодаря тому, что InterBase обеспечивает автоматическое восстановление и готовность к работе после сбоев системы (пользователи часто даже не замечают, что у сервера были проблемы), он используется во многих военных проектах США. Во многом из-за этого InterBase так поздно появился на нашем рынке.

InterBase выгодно отличается от многих других серверов следующими качествами:

· Высокая производительность и надежность при минимальных требованиях к ПК.

· Поддержка стандарта SQL-92, что позволяет обеспечить переносимость программ.

· Относительно низкая стоимость продукта (с Delphi поставляется сервер InterBase с бесплатной лицензией на 5 клиентов, этого достаточно для разработки БД и приложения, но обычно недостаточно для развертывания сервера в организации).

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

В 1985 году сервер носил название GDS (Groton Database System), но вскоре был переименован в InterBase. В 1991 году сервер был перекуплен фирмой Aston Tate, но уже в 1992 году вместе с фирмой сервер перешел во владение корпорацией Borland. Начиная со второй версии Delphi, дистрибутив включает в себя бесплатную локальную версию сервера InterBase. Поскольку InterBase является «родным» для Delphi сервером БД и не требует для своей работы установки дополнительных драйверов, а также, принимая во внимание все вышесказанное, мы остановимся именно на нем. Средств самой Delphi вполне достаточно для программирования приложений, работающих с InterBase, однако имеются разработки и сторонних производителей — компоненты, программы для облегчения администрирования БД и т.д.

Предполагается, что при установке Delphi вы также установили и InterBase Server. Впрочем, если это не так, то вставьте дистрибутивный диск и установите InterBase 6.5 Server:

Рис. 2. Выбор установки сервера в поставляемом дистрибутиве Delphi

Если же вы не знаете, установлен ли у вас уже InterBase, достаточно посмотреть в список меню «Программы», где он должен присутствовать отдельной папкой. Тут следует сделать одно замечание: если вы используете ОС Windows NT, 2000 или XP, то InterBase может запускаться как служба (по умолчанию) или как приложение. В случае Windows 95, 98 или ME InterBaseзапускается только как приложение. Вне зависимости от того, какая ОС у вас установлена, если сервер запущен как приложение, в правом нижнем углу (в трее) вы увидите значок InterBaseGuardian:

Рис. 3. Значок InterBase Guardian

InterBase Guardian — утилита, которая устанавливается вместе с сервером. Эта утилита осуществляет начальный запуск сервера, и его перезапуск, если по каким то причинам сервер «рухнул».

Если же у вас установлена Windows NT, 2000 или XP, то загрузите Панель управления (Пуск -> Настройки -> Панель управления). Среди прочих имеющихся служб вы увидите и InterBase Manager :

Рис. 4. Панель управления в Windows XP SP-2

Щелкните дважды по этой службе, чтобы открыть ее. Вы увидите следующее окно:

Рис. 5. Окно службы InterBase Manager

В группе Startup Mode этого окна вы можете выбрать одну из радиокнопок: Automatic (Сервер запускается автоматически) и Manual (Сервер запускается вручную). Если вы установилиInterBase на ПК, который действительно будет сервером, то лучше оставить включенной кнопку Automatic. Но если же это ваш рабочий ПК, на котором вы лишь разрабатываете приложение, используя локальный сервер, то запускать его лучше вручную. Дело в том, что запущенный сервер пусть немного, но отнимает оперативную память. Кроме того, сервер постоянно «прослушивает» свой порт, по которому к нему может обращаться клиентское приложение, что также незначительно снижает производительность ПК. Данные между компьютерами передаются «пакетами», которые в служебной части содержат и номер порта. Порт — это целое число, которое используется при приеме и передаче данных для идентификации процесса (программы), которая этими данными обменивается. Например, протокол HTTP использует порт 80. Сервер InterBase использует порт 3050. (Все установленные порты описаны в файле SERVICES, расположенном в одном из папок Windows. Для Windows XP это адрес C:\WINDOWS\SYSTEM32\DRIVERS\ETC).

Ниже расположен раздел Root Directory (корневая папка сервера). В этом разделе указан адрес, по которому была произведена установка InterBase.

Еще ниже расположен раздел Status. Если сервер находится в рабочем состоянии, то зеленым цветом выводится Running (выполняется), а кнопка справа имеет название Stop(остановить). Если же сервер не работает, то красным цветом выводится надпись Stopped (остановлено), а кнопка справа содержит надпись Start (запустить). Вы можете безбоязненно попробовать нажимать на эту кнопку, запуская или останавливая сервер. «Галочка» Run the InterBase server as a service on Windows NT (Загружать сервер InterBase как службу Windows NT) позволяет вам указать способ загрузки сервера: как службу Windows (при отмеченном состоянии) или как простое приложение. Рекомендуется запускать сервер, как службу.

В самом низу расположен раздел Properties (Свойства), где вы можете посмотреть или изменить текущие свойства сервера или служебной программы InterBase Guardian .

Создание базы данных в Interbase и настройка ProxyInspector для работы с ней

Внимание:
IBConsole не входит в стандартный дистрибутив FireBird. Вы можете скачать эту утилиту отдельно с сайта Borland(нужно будет зарегистрироваться на сайте):
http://codecentral.borland.com/codecentral/ccweb.exe/download? >

Для того, чтобы создать базу данных необходимо на компьютере, на котором установлен Interbase/Firebird, запустить утилиту IBConsole(ярлык находится в группе Interbase), войти на сервер(Server | Login, по умолчанию после установки пользователь: SYSDBA, пароль: masterkey), далее запустить утилиту Interactive SQL: пункт меню Tools | Interactive SQL . .

Если это первый запуск IBConsole после установки Interbase/Firebird, то сервер необходимо сначала зарегистрировать в IBConsole. Выберите пункт меню Server | Register, в появившимся окне выберите Local Server и нажмите ОК. После чего нужно выполнить процедуру входа на сервер описанную выше.

После установки ProxyInspector SQL скрипт для создания БД на сервере Interbase/Firebird находится в каталоге

— каталог в который установлен ProxyInspector. Нажно открыть этот скрипт в ISQL командой Query | Load Script:

вместо строки enter database filename here ввести желаемое полное имя и путь к файлу БД(с расширением .gdb), также заменить если нужно имя пользователя и пароль(сохранять не рекомендуется), после чего выполнить команду Query | Execute. База данных будет создана.

Теперь нужно указать путь к ней в ProxyInspector. Запустите ProxyInspector, выберите пункт меню База | Настройки программы, страница База данных | Сервер Interbase:

при доступе по протоколу TCP/IP путь к БД будет состоять из имени или IP-адреса сервера БД, и полного имени файла БД(это же имя указывалось в SQL скрипте при создании БД), разделенных двоеточием. Например: db-server:c:\db-data\interbase\pi_ent.gdb или 10.0.0.5:d:\data\pi_ent.gdb и.т.д.

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

После этого на странице База данных настроек также нужно выбрать Сервер Interbase, нажать OK и перезапустить PI. После чего выбрать База данных | Соединить для подключения к БД.

Для доступа к БД Interbase с других компьютеров необходимо наличие библиотеки gds32.dll в каталоге \system32. Эта библиотека находится в каталоге \system32 компьютера с сервером Interbase и также устанавливается при установке Interbase Client.

Список библиотек доступа к InterBase

Список библиотек доступа к InterBase

Широкое распространение InterBase и его клонов по всему миру и использование в самых различных ипостасях привело к тому, что было создано множество библиотек доступа к InterBase/Firebird, ориентированных на самые различные среды программирования. Ниже, в таблице 1.6, приведен список наиболее популярных продуктов:

Free IB Components (FIBC)

Четыре компонента, написанные в 1998 г. Грегори Детцем. Идеи, заложенные в FIBC, послужили основой для создания библиотек FIBPlus и IBX

Библиотека прямого доступа, оформленная в виде компонентов, применяется в Delphi 3-6, C++ Builder 3-6, Kylix. Поддерживает интеграцию со стандартными data-aware-компонентами. Основана на коде Free IB Components

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

InterBase Express (IBX)

Набор компонентов для работы с базами данных InterBase, позволяющий использовать data-aware- компоненты для представления данных. Продукт основан на коде FreelBComponents и входит в стандартную поставку Borland Delphi/C++ Builder Enterprise Edition

codecentral.borland.com/ codecentral/ccweb.exe/ author?author >

Zeos Database Objects

Набор компонентов для работы с различными серверами баз данных, в том числе и InterBase. Позволяет использовать стандартные data- aware-компоненты для представления данных, а также содержит свои собственные визуальные компоненты

Библиотека классов для C++, позволяющая работать со многими SQL- серверами, в том числе и InterBase

Open Source Firebird and InterBase ODBC Driver

ODBC-драйвер для InterBase/Firebird. Существует в виде открытых кодов. Также поддерживает возможность организации «моста» ODBC-JDBC

Gemini InterBase ODBC Driver


ODBC-драйвер, поддерживает все версии InterBase, начиная с 4.x, а также предоставляет поддержку всех возможностей InterBase 6.5 и Firebird 1.0

OLE DB-провайдер для доступа к базам данных InterBase. Полностью поддерживает все свойства InterBase б.х/Firebird 1.0

OLE DB-провайдер для доступа к базам данных InterBase

Объектно-ориентированная библиотека для PerlS для работы с базами данных InterBase

DBI-драйвер для InterBase

PHPLib for InterBase

Библиотека доступа к InterBase для языка РНР

ADODB — InterBase PHP4 Database Wrapper

Библиотека доступа к InterBase для языка РНР

Zope Driver for InterBase

Библиотека доступа к InterBase для языка Python

JDBC-драйвер для доступа к базам данных InterBase из Java

Включен в стандартную поставку Borland InterBase

Самый полный и «свежий» список библиотек доступа всегда можно найти на сайте поддержки данной книги www.InterBase-world.com, а также на сайте www.ibase.ru

Похожие главы из других книг

Создание библиотек фрагментов и моделей

Создание библиотек фрагментов и моделей Для создания этого типа библиотек вам не потребуется никаких специальных навыков, кроме умения работать в КОМПАС-График или КОМПАС-3D. Библиотеки фрагментов или моделей формируются с помощью стандартных инструментов,

Создание библиотек шаблонов

Создание библиотек шаблонов Приложение для создания библиотек шаблонов (по своей сути также прикладная библиотека к КОМПАС-3D, названная Менеджером шаблонов) позволяет создавать особый вид пользовательских прикладных библиотек. Эти библиотеки состоят из базового

Механизмы эволюции библиотек

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

Глава 8 Создание и использование библиотек

Глава 8 Создание и использование библиотек Исполняемые файлы могут получать функции из библиотек одним из двух способов: функции можно скопировать из статической библиотеки непосредственно в образ исполняемого файла или на них могут иметься неявные ссылки в файле

8.3. Разработка совместно используемых библиотек

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

8.3.3. Разработка совместимых библиотек

8.3.3. Разработка совместимых библиотек При разработке собственных библиотек необходимо знать факторы, делающие библиотеку несовместимой. Существуют три основных причины несовместимости.1. Изменение или удаление интерфейсов экспортированных функций.2. Изменение

8.5. Инсталляция совместно используемых библиотек

8.5. Инсталляция совместно используемых библиотек Программа ldconfig выполняет всю рутинную работу по инсталляции совместно используемых библиотек. Вам всего лишь нужно получить файлы и запустить ldconfig. Выполните описанные ниже шаги.1. Скопируйте совместно используемую

8.6.1. Использование деинсталлированных библиотек

8.6.1. Использование деинсталлированных библиотек После запуска программы динамический загрузчик обычно ищет необходимые программе библиотеки в кэше (/etc/ld.so.cache, созданном ldconfig) библиотек, которые находятся в каталогах, записанных в /etc/ld.so.conf. Однако если установлена

8.6.2. Предварительная загрузка библиотек

8.6.2. Предварительная загрузка библиотек В некоторых случаях вместо замены целой библиотеки совместно использования возникает необходимость замены лишь нескольких функций. Вследствие того, что динамический загрузчик выполняет поиск функций, начиная с первой

Совместное использование образцов и библиотек

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

Выгрузка библиотек при выходе из программы

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

9.4.1. Список контроля доступа

9.4.1. Список контроля доступа Первое, с чем нам предстоит познакомиться, — это ACL (Access Control List, список контроля доступа), который предоставляет большие возможности для дальнейшей настройки прав доступа к сайтам. С помощью списка имен вы как бы группируете действия или

Обзор библиотек доступа к InterBase

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

Основа библиотек доступа к InterBase

Основа библиотек доступа к InterBase Какова бы ни была библиотека доступа, для какой бы среды разработки она ни предназначалась, в любом случае основой является InterBase API. InterBase API предоставляет базовый набор функций низкого уровня для работы с базами данных. Таким образом,

2.3. Создание и использование библиотек

2.3. Создание и использование библиотек Практически со всеми программами компонуется одна или несколько библиотек. К любой программе, использующей функции языка С (например, printf() или malloc()), подключается библиотека времени выполнения. Если у программы есть графический

2.3.5. Преимущества и недостатки библиотек

2.3.5. Преимущества и недостатки библиотек Познакомившись со статическими архивами и совместно используемыми библиотеками. читатели, очевидно, задумались: какие же из них лучше использовать? Есть несколько важных моментов, о которых следует помнить.Большим преимуществом

InterBase: тормозология и глюконавтика
Страница 17. Пароли и права доступа

Пароли и права доступа

Первый вопрос выясняется в момент подключения к БД. Во-первых, все средства, предусматривающие подключение, начиная от функций interbase API и кончая интерактивными утилитами предоставляют возможность явно задать имя и пароль. И если значения указаны, то они имеют приоритет надо всеми остальными умолчаниями. Если же нет, то пробуются два других источника — переменные окружения ISC_* и пользователи Unix, если дело происходит под соответствующей системой.

Из переменных окружения нас в данном случае интересуют две: ISC_USER=имя_пользователя и ISC_PASSWORD=пароль. Эти переменные одинаково воспринимаются подо всеми операционками, которые поддерживает InterBase. Кроме того, они одинаково воспринимаются как утилитами командной строки, так и интерактивными программами, потому что на клиенте их проверяет gds32.dll (linterbasegds.so).

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

Несмотря на то, что сегодня interbase применяется в основном под Windows, по своей природе и истории это в основном юниксовый продукт. Соответственно его система управления правами в большей степени оринетирована на Юниксы. В частности, interbase умеет доверять юниксовой системе, принимая соединения от неё пользователей без проверки пароля. Для этого достаточно, чтобы имя пользователя (без учёта регистра) совпало с именем пользователя, зарегистрированного в системе и чтобы этот пользователь подключался из системы, которой доверяет сервер.

Доверие между системами устанавливается традиционым для Юниксов способом. Во-первых, каждая система доверяет сама себе. То есть подвключения в пределах одного компьютера пройдут без проблем. Внешние подключения должны исходить с клиентов, перечисленных в файле /etc/hosts.eqiv на сервере. Или в файле /etc/gds_hosts.equiv. Первый — общесистемный, его воспринимают все сервисы. Второй Борландовцы придумали под себя. Форматы одинаковы и описаны в юниксовой документации.

Ещё одно условие состоит в том, что на доверяемом клиенте должен работать сервис auth, способный подтвердить: да, это соединение в моей системе исходит действительно от процесса, принадлежащего указанному пользователю. Поскольку такой сервис обитает исключительно в Юниксах, все упомянутые механизмы доверия системе работают только между Юниксами. Если же клиент или сервер — не Юникс, то тогда ничего не остаётся, кроме как явно указывать имя и пароль другими способами. С другой стороны, в Юниксе тоже можно явно указать имя с паролем, чтобы подключиться под правами пользователя, отличного от текущего в системе.

И так, сервер выудил через параметры, переменные и доверия имя и пароль пользователя. Как же он узнает, допустимы ли они для него, или нет? Для этого существует специальная БД, которая обычно лежит непосредственно в установочном каталоге interbase и как правило, называется, isc4.gdb. Именно туда заносятся все пользователи, регистрируемые через gsec или Server Manager.

В базе всего две таблицы.

HOST_INFO — дополнительная информация об узлах сети. То есть о доверяемых системах, как описано выше. Полей всего два:

HOST_NAME — имя узла. Имеется в виду hostname из TCP/IP. Обратите внимание: без домена! По какой-то странной причине практически все утилиты InterBase не воспринимают имена с доменами. То есть нельзя написать gw.krista.ru, можно только просто gw. Соответственно клиент и сервер должны быть в одном домене.
HOST_KEY — какой-то ключ для данного узла. По всей видимости, предусмотрен какой-то дополнительный механизм для проверки возможности доверия через ключи. Только вот где указать этот ключ на клиенте, я в документации откопать так и не смог.

USER_NAME — имя пользователя в InterBase.
SYS_USER_NAME — хотя по умолчанию имена пользователя в системе и в InterBase должны совпадать, вероятно предусмотрена (не задокументированная сейчас) возможность задавать произвольное соответствие. Это одна из гипотез по поводу существования этого следующего поля. Другая: пользователь, входящий в interbase под указанным именем обязан быть в системе тем-то и принадлежать к группе такой-то, если они указаны. Что из этого правда и работает ли вообще хоть что-то я не проверял.
GROUP_NAME — имя группы. См. замечание к предыдущему пункту.
UID — Численное значение идентификатора пользователя согласно Юниксу. В других системах игнорируется. Как я понял, именно под этим идентификатором в системе запускается процесс (или может где-то — поток), обслуживающий текущего пользователя. При условии, что головной процесс работает под правами root. Данный идентификатор самым непосредственным образом влияет на права доступа к файлам БД.
GID — аналогично предыдущему полю идентификатор группы.
PASSWD — пароль в зашифрованном виде. Шифруются и хранятся только первые 8 символов (хотя вводить можно и больше) согласно классическому юниксовому алгоритму. То есть можно взять какую-нибудь шифровку пароля из /etc/shadow и записать её сюда. И пользователь interbase приобретёт пароль взятый из Юникса.
PRIVILEGE — по всей видимости, ненулевое значение должно указывать на то, что пользователь привилегированный. Прикол в том, что в записи для SYSDBA там обычно null, как и у обычных пользователей.
COMMENT — какой-то комментарий к пользователю. Тоже обычно null.
FIRST_NAME — Имя.
MIDDLE_NAME — Отчество.
LAST_NAME — Фамилия.
FULL_NAME — поле, вычисляемое из FIRST_NAME, MIDDLE_NAME, LAST_NAME.

Итак, как мы видели, имеется предостаточно информации о том, под какими правами должен существовать в системе процесс или поток, работающий на пользователя. Эта информация актуальна для Unix, а так же для Windows NT при работе через протокол NetBEUI. Во всех остальных случаях все процессы InterBase работают под теми правами, под которыми их запустили.

Поведение под Unix описано в разделе Установка под Linux. Оно радикальным образом зависит от того, обезопасились ли Вы при установке, отобрав у interbase права root, или нет. Если да, то несмотря на все настройки, процессы interbase будут работать из-под одного и того же UID. Все файлы БД должны быть доступны ему для записи.

Если же interbase запускается, как root, то всё зависит от пользователя. В первую очередь interbase смотрит, не заданы ли для пользователя конкретные UID и GID. Если да, то процесс переключается на них. Иначе в системе ищется пользователь с тем же именем (ещё раз повторюсь: без учёта регистра). Если найден, то производится переключение на него. А вот если не найден, то процесс остаётся нормально работать под правами root! То есть любое наличие пользователя в InterBase, не прописанного в системе означает дыру в безопасности всей системы. В сочетании с возможностью писать UDF не составляет труда запустить привилегированный shell и получить полную власть.

Таким образом, установка под Unix черезвычайно опасна и требует либо очень внимательного сопровождения, либо переключения на непривилегированный UID. В заключение отмечу, что interbase делает особое исключение для SYSDBA и root. Подключения под SYSDBA порождают в системе процесс с правами root (если есть возможность), а подключения под системным пользователем root на уровне БД считаются эквивалентыми SYSDBA.

Что же касается NT, то там похожие эффекты возникают в NetBEUI. Этот протокол, а точнее, способ его использования Энтями, позволяет соединениям в сервере наследовать права того клиента, который соединение создал. Клиент же при установлении соединения предъявляет те права, под которыми пользователь зашёл в клиентскую систему. Это означает, что сервер сможет открыть БД от имени данного клиента тогда, и только тогда, когда данный клиент имеет права на доступ к файлу БД.

Самый большой прикол состоит в том, что пользователь interbase, в отличие от случая с Юниксом, здесь вообще не причём! Клиентский пользователь Windows предъявляется серверу Windows. Правда, проверка файловых прав делается после того, как пользователь прошёл обычную проверку InterBase. Если клиент вошёл в домен NT, то соответственно его подключение трактуется, примерно как попытка открыть файл БД по сети. Если же клиент в домен не входил, то с точки зрения сервера он рассматривается, как посторонний пользователь. То есть в этом случае база должна быть Read/Write для всех.

Отсюда мораль: если не хотите запутаться — пользуйтесь TCP/IP. Он учитывает только то, что прописано в InterBase, и ничего больше.

Итак, interbase идентифицировал пользователя, убедился, что это точно он, породил ему процесс (или поток) с нужными правами, и процесс успешно открыл файл БД. Всё, можно работать. Рассмотрим теперь, как определяются права пользователей на отдельные объекты БД. Операционная система здесь уже полностью не причём.

Обработка ошибок InterBase

Обработка ошибок SQL

Обработка исключений

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

  • Прекращается выполнение блока BEGIN . END, содержащего исключение, и отменяются действия, выполненные в блоке.
  • Если блок содержит оператор WHEN, управление передается в WHEN, в противном случае аналогичные действия производятся в блоке, содержащем данный. Подобные действия производятся до тех пор, пока либо не будет найден соответствующий WHEN, либо не будет достигнут уровень процедуры. В последнем случае про­цедура будет завершена, а исключение не будет обработано.
  • Выполняются действия, определенные оператором (блоком), за­данным в конструкции WHEN (если он обнаружен).

Управление возвращается оператору (блоку) программы, следующе­му за оператором WHEN.

Если исключение обработано с помощью WHEN, то соответствую­щее сообщение об ошибке не выдается.

Процедуры могут также обрабатывать ошибки SQL по кодам, воз­вращенным в SQLCODE. После выполнения каждой команды SQL фор­мируется код ее завершения – SQLCODE, отражающий успешность вы­полнения, или код ошибки. SQLCODE может также содержать код пре­дупреждения, типа того, что перечень строк в выборке по циклу FOR SELECT исчерпан.

SQLCODE Описание
Успешное завершение
1-99 Предупреждение или информационное сообщение
Конец файла (списка)

Не нашли то, что искали? Воспользуйтесь поиском:

Лучшие изречения: Учись учиться, не учась! 10390 — | 7890 — или читать все.

Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL