Гостевая
Форум
Разделы
Главная страница
Js скрипты
Php скрипты
Html шаблоны
Книги по Web дизайну
Статьи


Главная страница статей --> Хитрости при программировании php, заметки по базам данных

SQL. С самого начала.

Источник: realcoding.net

Политика безопасности


Мюллер в "17 мгновений весны" говорил: "В разведке верить нельзя никому, даже самому себе, мне - можно". Современный бизнес очень часто пользуется методиками, позаимствованными у спецслужб, так что шутка г-на Мюллера более чем уместна. Поэтому чем большую ценность представляет собой информация, которая в распоряжении организации находится, тем выше стоимость задач организации, тем острее стоят вопросы доверия организации по отношению к своим сотрудникам и пользователям информации, тем совершеннее должны быть средства отслеживания доступа к корпоративной информации, бесконтрольное использование которой может причинить серьезный вред.

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

Идентификация решается при помощи присвоения пользователю соответствующего регистрационного имени, а аутентификация, т.е. подтверждение того, что пользователь является именно тем лицом, за которое он себя выдает, решается при помощи пароля. Схемы реализации могут быть различны. Например, в oracle7 есть две схемы аутентификации пользователей: первая - непосредственно сервером СУБД, а вторая - средствами базовой ОС, причем у разных пользователей могут быть назначены разные схемы, но не более одной для каждого пользователя.

При аутентификации через ОС, если пользователь уже зашел в систему, то сервер СУБД не запрашивает у пользователя пароля при доступе к ресурсам БД. При аутентификации через сервер СУБД, oracle запрашивает пароль вне зависимости от того, зарегистрировался ли пользователь в ОС или нет. Корпорация oracle считает аутентификацию через сервер СУБД более безопасной и рекомендует использовать именно ее. Причем пароль внутри oracle и пароль системный являются независимыми друг от друга и могут отличаться.

Правда, необходимо иметь в виду такое свойство паролей oracle, как возможность их задания в командной строке для всех утилит и компонент, которые работают с СУБД. Это иногда применяется для облегчения доступа к системе, например, при работе в пакетном режиме. К сожалению, в этом случае, пароли пользователей, регистрирующихся непосредственно в oracle видны в столбце командной строки в таблице процессов, выводимой по команде ps l . Это значит, что остальные пользователи не должны иметь доступа к командной строке системы, в противном случае, безопасность системы будет серьезно нарушена. Еще лучше если в данной ситуации машина будет использоваться только как сервер СУБД и не будет заниматься под другие задачи, связанные с пользовательским доступом.

В informix ds используется аутентификация только средствами ОС

Чтобы не назначать каждому пользователю большое количество прав доступа к каждой из групп таблиц в системе, формируется некоторый список, в котором все эти права перечисляются. Дальнейшее назначение прав делается при помощи этого списка. Совокупность таких прав доступа к объектам СУБД называются ролью доступа. В oracle помимо ролей доступа, есть еще и роли приложений (более подробно про них указано в описании oracle cde, раздел про sql*menu). Функционально эти роли похожи, но роли приложения являются исключительным свойством sql*menu. Они не связаны непосредственно с возможностями oracle и отвечают лишь за доступ пользователя к приложениям.

Ролей приложений в informix ds как таковых нет l . Для того чтобы создать нечто подобное, каждый раз приходится изобретать велосипед.

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

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

Зато если в системе помимо приложений используются еще и другие средства доступа к серверу СУБД, например, sql-консоль или ведется работа при помощи скриптов, то внутренний аудит СУБД является единственным средством регистрации работы пользователей, в том числе и системного администратора.

Так что работайте и не забывайте, что "big brother watches you".

Лицензирование


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

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

i love it! :-)

Все триальные версии, которые мне попадались работоспособны и после окончания срока триала, тем более выпускает oracle триалы в большом количестве. Как мне понравилось в su.dbms кто-то сказал: "... считается что после окончания срока триала человека начинает страшно мучить совесть..." j

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

Допустим программист работал на "черной" или "серой" копии системы a, допустим, что он где-то украл к ней документацию. Систему А он знает и понимает. Настало время "Ч" и возникла необходимость либо в легализации разработок, либо пришла пора "внедрежа" новых технологий в конторе. Догадайтесь с трех раз, какую систему он будет рекомендовать своему руководству для приобретения из систем, представленных на рассмотрение: a, b и c?

У oracle есть один существенный минус: если сделанную на oracle систему надо кому-то продавать, то для oracle corporation надо выплачивать royalty с каждой проданной копии за его исполняемые модули, необходимые для запуска системы (runtime). Так по крайней мере было раньше. Если сейчас что-то изменилось - не знаю, из других СУБД этим никто вроде бы не страдает.

А как ви телаете руские пуквы, товарисч?


Как уже упоминалось, поддержка национального языка является критичным свойством для всех СУБД. В поддержке русского языка у informix и oracle есть много общего. Клиент, в виде переменных окружения указывает, какой он кодовой страницей пользуется сам, на каком языке он хотел бы получать диагностические сообщения, в случае необходимости указывает форматы даты, денежных единиц и пр. Для informix указывается также, какая кодовая страница должна быть у базы данных для успешного к ней присоединения, иначе пользователь получит от ворот поворот.

Дальше все просто, при соединении сервер проверяет кодовые страницы у базы данных и клиента, если они совпадают, то нет проблем. Если они отличаются, то сервер проверяет, может ли он осуществить преобразование из одной таблицы в другую, если может (например, из серверной koi-8 в клиентскую 866), то нет проблем, если это сделать нельзя (например, из koi-8 в us7ascii), то в oracle мы имеем ересь на экране, а informix рапортует об ошибке и завершает соединение.

Сервер oracle поддерживает практически все мыслимые русские страницы, включая русскую страницу для apple macintosh и странную 855 страницу, так странно любимую oracle. Настройка русского языка для oracle на конкретной платформе может потребовать некоторых усилий. В частности мне пришлось потратить некоторое время, прикручивая русские буквы и псевдографику на sco openserver, причем как на самом сервере, так и в cde. Сервер понимал все кодовые страницы, но cde нормально пропускал только 8859-5. Вдобавок сам openserver двоил большую русскую "А", но это удалось побороть при помощи mapchan. Также удалось сделать корректный ввод и вывод псевдографики не только на терминальном эмуляторе, но и на системной консоли, для чего пришлось переправить описания терминалов соответственно для консоли и терминального эмулятора в oracle, а также перестроить определения клавиатуры в openserver. А как кодируется псевдографика в oracle*terminal - это просто хит!

Зато с поддержкой русского языка в informix (как для linux, так и для solaris x86) не было никаких проблем в принципе. Все стало и заработало с полоборота. У informix не такое большое разнообразие русских кодовых страниц, но все основные есть: koi-8, win1251, pc866, iso8859-5. Лучшая для linux это koi-8.

Терминальные эмуляторы, которые мне довелось использовать (ansiw95 и telneat) поддерживают перекодировку из koi8 в 866 "на лету".

Ты скажи, чё те надо:.


oracle 8i ee для linux желает ни много ни мало 128 mb ram минимум, хотя рекомендованное типичное значение составляет 256mb ram. informix dynamic server 7.30.uc7 в этом плане менее прожорлив. Ему достаточно и 64 mb, но следует помнить что по своим возможностям он примерно соответствует oracle 7.3, а у того потребности в памяти примерно аналогичные.

Среда разработчика. А также четверг и 7 пятниц.


Так уж получилось, что мне довелось заниматься в основном СУБД на unix, и поэтому буду рассматривать только то, что с этой системой связано.

Рассмотрим две отличающиеся идейно среды разработчика: oracle cde1 для unix и informix rds для unix .

oracle corporative development environment (cde).

Это одно из самых проверенных интегрированных средств разработки корпорации oracle. Благодаря своим функциональным возможностям находится в использовании до сих пор, хотя и выпущено впервые в 1992 году, в индустрии ПО это практически вечность.

oracle cde состоит из нескольких автономных частей. Это sql*forms 3.0 для генерации экранных форм, sql*reportwriter 1.0 для генерации отчетов для печати на принтере или экране. sql*menu, для генерации меню, которое в свою очередь связывает в готовое приложение формы и отчеты. Ну и еще есть sql*plus - замечательная sql-консоль, которая может использоваться и для быстрого построения отчетов. Здесь рассматриваются версии oracle cde для sun solaris (sparc) и oracle cde для sco openserver, которые с точки зрения разработчика идентичны.

sql*forms 3.0.

Будет, наверное, правильно (хотя и очень грубо) сказать, что разработка приложения для ввода/вывода пользовательской информации, сводится к рисованию полей таблицы на экране и их правильной компоновке, т.е. по своей сути sql*forms является дизайнером.

Но попрограммировать все же придется. Основа основ разработки под sql*forms - это триггеры, т.е. срабатывание сохраненной в БД процедуры по некоторому событию. Только здесь события связаны с формой. Т.е. если пользователь заходит в форму, то при этом срабатывает соответствующий триггер, заходит в поле формы, нажимает на соответствующую функциональную клавишу, выходит из формы - также срабатывают соответствующие триггеры.

Триггеров в sql*forms много - на все события, которые могут произойти в форме и практически на все случаи жизни. Схемы их срабатывания описаны в достаточно объемной документации (~400 страниц). Для написания триггеров используется pl/sql, который должен быть установлен на сервере (procedural option).

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

Указываем таблицу для генерации формы. При этом sql*forms самостоятельно пытается разместить на экране поля этой формы. Приводим за ним в порядок экран, т.е. осмысленно называем поля, расставляем их в нужном порядке на экране, рисуем рамочки, выставляем требуемую длину полей. Сохраняем, компилируем. Все! На это ушло минут пятнадцать. В данном примере нет проверок, сложных условий, работа ведется только с одной таблицей, нет блоков "мастер-подчиненный", нет подсказок, многостраничной работы и вызова подчиненных форм. И тем не менее, в данном приложении мы имеем возможность вставлять данные в таблицу и удалять их оттуда. Кроме того, можно выполнять поиск данных из таблицы по условию в любом поле, редактировать отобранные строки и сохранять их назад в таблицу!

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

Столь же простым является программирование списков выбора (lov). Сначала пишется sql-выражение в котором указывается куда будут сохраняться возвращенные значения в виде select : into :var1, :.:varn where :, затем указываются координаты окна, название окна и наш список практически готов. Кроме того, в нем еще можно осуществлять поиск по критерию.

Откомпилированная форма представляет собой бинарный файл с псевдокодом, который передается для запуска компоненту runform. В принципе форму можно выгрузить в перемещаемый формат (*.inp), там все хорошо и красиво структурировано, но oracle категорически не рекомендует прямое редактирование этого файла, т.к. в случае если там будут содержаться неверные команды есть риск повреждения таблиц с формами. Тем не менее, описание перемещаемого формата полностью документировано в sql*forms designers reference.

sql*forms очень жестко задает стиль программирования, поэтому все экранные интерфейсы похожи друг на друга. Но это не очень большой недостаток, в конце концов "нам надо шашечки или нам надо ехать?". Приложения создаются быстро, свою самую первую рабочую форму я получил через три дня, после того как начал осваивать sql*forms. Аналогичное по сути приложение я разрабатывал в informix 4gl в течение месяца.

sql*forms поддерживает многостраничную работу, т.е. форма может иметь размеры большие чем физический размер экрана, поддерживается вертикальный и горизонтальный скроллинг (scroll-regions), наслаивающиеся окна (pop-up windows), списки значений (lov), в которых возможен поиск, и многое другое.

Кстати клавиатурный интерфейс также единообразен, т.к. определяется лишь настройками терминала и контекстом используемых клавиш. Т.е. если известно, что для ansi-терминала значения по умолчанию клавиш "перейти в режим поиска" и "выполнить поиск" равны соответственно и ,, то это справедливо для любой формы разработанной в sql*forms и не зависит от того, кто и когда ее разрабатывал.

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

Раскладка клавиатуры в sql*forms радикально отличается от всех прочих приложений и стандартов, но проблемы с клавиатурным интерфейсом есть только у профессиональных пользователей или программистов. Неподготовленному пользователю все равно на что нажимать для выполнения поиска - на ctrl+f или на f11.

Также в sql*forms есть возможность автоматической генерации документации на создаваемое приложение.

sql*reportwriter 1.0

Безбумажные технологии, как это ни парадоксально, не способствуют уменьшению количества бумажных отчетов. Помочь в их создании помогает sql*reportwriter. Он позволяет выводить отчет на экран, в файл или на принтер, осуществлять его постраничный просмотр. Как и sql*forms, средство для генерации отчетов sql*reportwriter работает по типу "программирование без программирования", т.е. чем меньше кода, тем лучше. Его создавала другая команда программистов, поэтому его интерфейс отличается от sql*forms даже для одного типа терминала. Несмотря на свою непривычность, это универсальное средство, которое позволяет создавать отчеты любой сложности.

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

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

sql*reportwriter умеет выгружать файл в формат независящий от платформы (файлы с расширением .rex), но к сожалению этот файл для человеческого восприятия слабо пригоден, хотя и содержит только ascii символы.

Интерпретатор отчетов runrep может выполняться непосредственно из формы. Таким образом, из необходимого места приложения, пользователь может сразу запускать отчет.

sql*menu 5.0

sql*menu является относительно несложным в понимании средством, которое организует первичный пользовательский интерфейс. Оно интегрирует все компоненты системы (отчеты и формы) в единое приложение, которое в конечном итоге выглядит как некоторое главное меню, из которого вызываются элементы приложения - формы, отчеты, скрипты, в случае необходимости - бинарные исполняемые программы. Меню организованы иерархически в виде произвольного дерева и могут быть как вертикальными, так и выпадающими. Каждым элементом меню может быть либо элемент приложения, либо подменю.

Доступ к элементам меню организован на основе ролей приложения. Они подобны ролям доступа, которые существуют в сервере СУБД. Для элементов меню перечисляются роли, которые отвечают за доступ к каждому элементу. Если пользователю назначена соответствующая роль, то он видит те пункты меню, для которых эта роль указана. Роли назначаются непосредственно в sql*menu, но так как информация о ролях, назначенных пользователям, хранится в таблицах, то роли, в случае необходимости, можно назначать и создавать из программы пользовательского приложения. Это удобно. Естественно, что доступ к этим модулям приложения должен иметь только администратор приложения.

sql*menu компилирует описание меню в файл с расширением .dmm, который запускается специализированным интерпретатором runmenu. Как правило строка, содержащая sqlmenu, является последней командной строкой в профиле unix для обычного пользователя. Здесь начинается и заканчивается его рабочий день. Обычный пользователь системы, грамотно написанной на oracle, доступа к командной строке операционной системы не имеет вообще, в связи с чем его не надо обучать системе unix, и таким образом снимается много проблем, в том числе и безопасности доступа.

sql*plus 3.1

Эта замечательная утилита oracle, которая по своей сути является sql-консолью, позволяет решать массу задач. Например, управлять данными, структурами данных, создавать простые отчеты (причем с достаточно сложным форматированием), выполнять скрипты (работать в batch-mode), быстро лазить по системе и делать многое другое. Без нее жизнь под oracle была бы гораздо более скучной и сложной.

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

sql*plus в повседневных задачах в некоторой степени может заменять часть свойств sql*dba (ПО, из которого администратор управляет СУБД) , в частности выполнение операторов манипулирования данными (dml), управления параметрами пользователей и т.д, но, естественно, далеко не все.

Пользовательский интерфейс sql*plus - командная строка. И никаких меню!

oracle*terminal

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

Достоинства и недостатки oracle cde


Отладчик отсутствует как класс. Опция debug в sql*forms позволяет выполнять просмотр порядка срабатывания триггеров. Без отладчика не просто разрабатывать сложные приложения. Все остальное делается при помощи контрольной печати. Это не удобно. На cde достаточно сложно перейти с процедурных языков, так как его идеи разработки сильно отличаются от традиционных, хотя можно создать работоспособное приложение, не написав ни строки кода.

И тем не менее, oracle cde1 - это система с богатыми функциональными возможностями даже для 1999 года, поэтому oracle 7.3 часто используется для разработки современных проектов, там где требуется высокая надежность, допускается использование терминалов, и на рабочем месте пользователя нет необходимости работать с графикой.

Другие средства разработки oracle


Для windows 3.1 есть cde2 (те же forms, reportwriter, menu), для windows95 есть developer/2000, кроме того oracle дает скачивать со своего сервера такое средство разработки как jdeveloper. Весьма любопытное средство для создания java-ориентированных проектов. Кроме того, есть предкомпиляторы, которые транслируют sql-выражения в тексте программы в библиотечные вызовы для различных языков. Существуют oracle pro*c, pro*pascal, pro*ada, pro*cobol, pro*fortran, pro*pl/1. Ничем из выше перечисленного мне не приходилось пользоваться, так что не спрашивайте как это работает.



Похожие статьи:
- Работа с хэшами в Perl
- Создание wap-страниц (в формате *.wml)
- За что можно схлопотать бан от поисковых систем!
- Освоение Ajax: Использование XML в запросах и ответах
- Некоторые аспекты использования пользовательских функций в предложениях SQL.
- ADO и XML
- Динамические формы - проверка ввода на JavaScript
- SQL Server в вопросах и ответах
- Схемы блокировок в Базах Данных
- Динамические SQL-запросы Oracle для ускорения выборок данных
- Защита баз mdb
- Один из вариантов соглашения об именах объектов MS SQL Server
- Создание и удаление БД в MS SQL Server


Оглавление | Обсудить на форуме | Главная страница сайта | Карта сайта |
[0.001]