Теория и практика построения баз данных

JDBC

admin — Wed, 25 Aug 2010 15:49:07 +0000

Для начала заметим, что, несмотря на утверждения многих источников, JDBC не означает Java Database Connectivity. По утверждению компании Sun, изобретателя Java, JDBC — это вообще не аббревиатура, а просто JDBC. Остается только догадываться, какие правовые или личностные конфликты стоят за этим утверждением. Драйверы JDBC существуют почти для всех мыслимых СУБД. Корпорация Sun поддерживает каталог этих драйверов на своем сайте по адресу http:/ java.sun.com/products/jdbc. Некоторые драйверы являются бесплатными, и почти у всех есть ознакомительные версии, которые можно свободно использовать в течение ограниченного периода времени. Драйверы JDBC, взятые при подготовке этой главы, — это драйверы MySQL с открытыми исходными текстами, разработанные Марком Мэтьюсом (Mark Mathews). Их можно загрузить по адресу http://worldserver.com/mm.mysql.
Чтобы вы не приобрели вредные привычки, прежде чем продолжить, исправим одну потенциальную ошибку. Название СУБД MySQL произносится «май эс-кью-эл», а не «май сиквел». Вряд ли это важно, но если вы хотите произвести впечатление, всегда говорите «май эс-кью-эл».

Типы драйверов

admin — Wed, 11 Aug 2010 15:49:47 +0000

Sun определяет четыре типа драйверов. Драйверы первого типа представляют собой мост от JDBC к ODBC. Они обеспечивают интерфейс между Java и обычными драйверами ODBC. Большинство драйверов ODBC написано на С или C++. По причинам, которые не важны для нас здесь, между Java и C/C++ существует определенная несовместимость. Драйверы JDBC-ODBC устраняют эту несовместимость и позволяют обращаться к источникам данных ODBC из Java. Поскольку использование ODBC было описано нами в предыдущей главе, первый тип драйверов мы далее рассматривать не будем.
Драйверы типов 2-4 написаны полностью на Java и отличаются только способом соединения с СУБД. Драйверы типа 2 соединяются с СУБД через «родные» интерфейсы — например, обращаются к Oracle с использованием стандартного (не ODBC) программного интерфейса Oracle. Драйверы типов 3 и 4 предназначены для использования в сетях связи. Драйвер типа 3 транслирует вызовы JDBC в независимый от СУБД сетевой протокол. Этот протокол затем преобразуется в сетевой протокол конкретной СУБД. Драйвер типа 4 транслирует вызовы JDBC в сетевой протокол конкретной СУБД.
Чтобы понять различия между драйверами типов 2-4, нужно сначала понять различия между сервлетом (servlet) и апплетом (applet). Как вы, возможно, знаете, язык Java разрабатывался как переносимый. Чтобы удовлетворить требованию переносимости, Java-программы компилируются не в конкретный машинный язык, а в машинно-независимый байт-код. Sun, Microsoft и другие компании разработали интерпретаторы байт-кода для каждой платформы (Intel 386, Alpha и т. д.). Эти интерпретаторы называются виртуальными машинами Java (Java virtual machines).
Для выполнения скомпилированной Java программы машинно-независимый байт-код интерпретируется виртуальной машиной. Оборотная сторона заключается в том, что интерпретация байт-кода добавляет промежуточный шаг и, следовательно, такие программы не могут выполняться так же быстро, как программы, компилируемые непосредственно в машинный код. В зависимости от нагрузки приложения это может вызывать неудобства или нет.
Апплет — это программа в байт-коде Java, выполняемая на компьютере пользователя приложения. Байт-код апплета посылается пользователю по HTTP и вызывается с пользовательской машины также с помощью HTTP. Интерпретация байт-кода производится виртуальной машиной, которая обычно является частью браузера. По причине переносимости один и ют же байт-код может быть отправлен на компьютер под управлением Windows, Unix или MacOS.
Сервлет — это Java-программа, вызываемая по HTTP на web-сервере. Она отвечает на запросы от браузеров пользователей. Сервлеты интерпретируются и выполняются виртуальной машиной Java, работающей на web-сервере.
Поскольку драйверы типов 3 и 4 работают с сетевыми протоколами, их можно использовать в коде апплетов и сервлетов. Драйверы типа 2 могут использоваться только в ситуации, когда Java-программа и СУБД находятся на одной и той же машине или когда в СУБД имеется специальная программа, занимающаяся связью между компьютером, на котором работает Java-программа, и компьютером, на котором располагается СУБД.
Таким образом, если ваша программа должна соединяться с базой данных из апплета (двухуровневая архитектура), можно использовать только драйверы типов 3 и 4. При этом, если ваша СУБД имеет драйвер типа 4, используйте его, поскольку он будет работать быстрее, чем драйвер типа 3.
В трехуровневой или многоуровневой архитектуре, если web-сервер и СУБД работают на одной и той же машине, можно использовать драйвер любого из трех типов. Если же они находятся на разных машинах, то безо всяких трудностей могут быть использованы драйверы типов 3 и 4. Подойдет также и драйвер типа 2, если в СУБД имеются средства, обеспечивающие связь между web-сервером и СУБД.

JSP-страницы и сервлеты

admin — Wed, 04 Aug 2010 15:50:17 +0000

JSP-страницы преобразуются в стандартный язык Java и затем компилируются как обычные Java-программы. В частности, они преобразуются в сервлеты Java, то есть в подклассы класса HttpServlet. Таким образом, код JSP-страницы имеет доступ к объектам, представляющим HTTP-запросы и их результаты, к их методам и другим функциям HTTP.
Поскольку JSP-страницы преобразуются в подклассы сервлетов, в них не требуется создавать полноценные Java-классы или методы. Вы можете просто вставлять фрагменты Java-кода там, где пожелаете, а при синтаксическом анализе страницы они будут корректным образом помещены в подкласс сервлета. Так, например, следующий фрагмент будет отлично работать в JSP-странице без всякого дополнительного Java-кода:
<% String partyName="KapHaBan";
partyName = partyName. toUpperCaseO;
out.println ("Приходите на наш " + partyName): %>
В результате обработки этой части JSP-страницы в окне браузера появится надпись «Приходите на наш КАРНАВАЛ». Кстати, обратите внимание, что Java-код помещается между «<%» и «%>», как и код на VBScript или JScript в ASP-стра-
ницах.
Чтобы использовать JSP-страницы, web-сервер должен поддерживать спецификации Java servlet 2.1 + и Java Server Pages 1.0+. Список серверов, поддерживающих эти спецификации, вы можете найти по адресу http://java.sun.com/products/ servlet/industry.html. Есть по крайней мере пять-шесть подходящих вариантов. В оставшейся части главы мы будем использовать для этих целей сервер Apache Tomcat.

Apache Tomcat

admin — Sat, 31 Jul 2010 15:50:26 +0000

По состоянию на декабрь 2000 года web-сервер Apache не поддерживает сервлеты. Однако фонд Apache и корпорация Sun выступили совместными спонсорами проекта Jakarta, в рамках которого был создан обработчик сервлетов под названием Apache Tomcat. Исходные тексты и двоичный вариант Tomcat можно найти на сайте проекта Jakarta по адресу http://jakarta.apache.org.
Tomcat представляет собой обработчик сервлетов, который может работать в связке с Apache или как автономный web-сервер. Возможности Tomcat как web-сервера ограничены, поэтому в автономном режиме он обычно используется только для тестирования сервлетов и JSP-страниц. В коммерческих приложениях Tomcat следует использовать совместно с Apache.
Если Tomcat и Apache работают отдельно на одном web-сервере, они должны использовать разные порты. По умолчанию для web-сервера предназначен порт 80, и обычно Apache использует именно этот порт. При использовании Tomcat в автономном режиме для него обычно выделяется порт 8080, хотя номер порта, разумеется, можно изменить,
В приведенных ниже примерах Tomcat использует порт 8080. Эти примеры запускатись в закрытой интрасети, где машине, на которой работал Tomcat, был присвоен IP-адрес 10.0.0.3.Таким образом, чтобы вызвать страницу somepage.jsp, в поле адреса браузера нужно ввести строку http://10.0.0.3:8080/somepage.jsp.

Настройка Tomcat для обработки JSP

admin — Sat, 10 Jul 2010 15:50:47 +0000

При установке Tomcat для него будет создана структура каталогов, куда необходимо поместить библиотеки классов и web-страницы. Для Tomcat версии 3.1 библиотеки классов следует помещать в каталог install-dir/lib, a JSP-страницы — в каталог install-dir/webapps/ROOT/WEB-INF/classes, где instaU-dir — это каталог, в который устанавливается Tomcat. В Linux утилита RPM по умолчанию устанавливает Tomcat в каталог /usr/local/jakarta-tomcat. Соответственно, библиотеки классов в этом случае нужно поместить в каталог /usr/local/jakarta-tomcat/ lib, a JSP-страницы — в каталог/usr/local/jakarta-tomcat/webapps/ROOT/WEB-INF/ classes. Если вы устанавливаете Tomcat в другой операционной системе или вообще устанавливаете другой обработчик сервлетов, стоит обратиться к документации.
Устанавливая файлы классов в подкаталог lib, нужно иметь в виду маленький нюанс: Tomcat создает свой CLASSPATH при запуске. Поэтому после того, как вы установите новый файл класса в каталог lib, вы должны остановить и перезапустить Tomcat, чтобы он смог увидеть этот файл. Если же вы просто скопируете новый файл в подкаталог lib без перезапуска Tomcat, вы получите исключение Class not found (класс не найден). (Поверьте мне, я знаю это...)
Все приведенные ниже JSP-страницы используют драйверы MySQL mm.mysql. Чтобы работа с этими драйверами стала возможной, необходимо поместить в подкаталог lib библиотеку класса соответствующего драйвера. Для примеров этой главы использовалась библиотека mm_uncomp.jar.
На рис. 16.2 изображена схема процесса компиляции JSP-страниц. Получив запрос на обработку JSP-страницы, Tomcat (или другой обработчик сервлетов) находит скомпилированную версию этой страницы и проверяет, является ли данная версия текущей. Для этого он ищет некомпилированную версию страницы с более поздней датой и временем, чем скомпилированная страница. Если страница не является текущей (нашлась более поздняя некомпилированная страница), производится синтаксический анализ новой страницы, после чего она преобразуется в исходный Java-файл, который затем компилируется. Полученный сервлет загружается и выполняется. Если же скомпилированная JSP-стра-ница оказывается текущей, то она загружается в память и выполняется. Если JSP-страница уже находится в памяти, обработчик просто выполняет ее.
(Между прочим, у такой автоматической компиляции есть один недостаток: если вы сделаете синтаксические ошибки и забудете протестировать свои страницы, то первый пользователь, обратившийся к этим страницам, получит сообщение об ошибках компиляции.)
В отличие от CGI-файлов и некоторых других web-серверных программ, одновременно в памяти находится не более одной JSP-страницы. Более того, страницы выполняются одним из потоков Tomcat, а не независимым процессом. Это означает, что для выполнения JSP-страницы требуется гораздо меньше памяти и процессорного времени, чем для выполнения сравнимого по функциональности CGI-сценария.

Резервное копирование и восстановление

admin — Thu, 01 Jul 2010 15:51:33 +0000

Возможности MySQL в сфере резервного копирования и восстановления ограничены. В MySQL есть утилита для сохранения базы данных и отдельных таблиц из нее. В некоторых случаях, однако, более быстрым и столь же простым методом является сохранение файлов базы данных на резервных носителях с помощью команд копирования операционной системы.
MySQL ведет журнал выполняемых действий. Но этот журнал состоит из команд и выполняемой работы, а не из исходных и конечных образов. Для восстановления базы данных копируется более ранняя версия базы и к ней применяются команды, записанные в журнале. Массовые изменения записываются в виде команд: в журнале указывается только имя файла, явившегося источником изменений. Отдельные изменения не регистрируются.
Кстати, если вы восстанавливаете базу данных после ввода ошибочного оператора, например
DROP TABLE CUSTOMER;
не забудьте перед повторной обработкой журнала удалить из него этот оператор DROP. В противном случае он будет выполнен диспетчером журнала, и вы вернетесь туда, откуда пришли, — к отсутствующей таблице CUSTOMER.

Заключительное слово о MySQL

admin — Tue, 29 Jun 2010 15:51:57 +0000

Насколько можно судить по этому разделу, система MySQL лишена многих возможностей и функций, имеющихся в современных СУБД. Может возникнуть вопрос, зачем же она вообще нужна. Дело в том, что, как сказано выше, эта СУБД распространяется свободно и имеет открытые исходные тексты. Если вы хотите принять участие в проекте open source в области СУБД, MySQL будет хорошим выбором. Кроме того, MySQL проста и даже приятна в использовании. Имеющиеся в ней возможности и функции реализованы хорошо. Создается впечатление, что сообщество разработчиков MySQL предпочитает делать немного, но качественно. Работать с таким продуктом — одно удовольствие.это Java-программа, работающая на сервере и отвечающая на HTTP-запросы. Драйверы типов 3 и 4 могут использоваться как для апплетов, так и для сервле-тов. Драйверы типа 2 могут использоваться только в сервлетах, и только если СУБД и web-сервер находятся на одной машине, или если СУБД самостоятельно обеспечивает связь между web-сервером и сервером базы данных.
Алгоритм использования JDBC состоит из четыргх шагов: (1) загрузить драйвер; (2) установить соединение с базой данных; (3) создать оператор; (4) выполнить оператор. Библиотеки классов драйвера должны быть в CLASSPATH компилятора и виртуальной машины Java. Они загружаются в Java-программу с помощью метода forName. Соединение устанавливается с помощью метода getConnection объекта DriverManager. Строка соединения состоит из символов jdbc:, за которыми следует имя драйвера и URL базы данных.
Операторы создаются с помощью метода createStatement объекта Connection. Выполнение операторов производится методами executeQuery и executeUpdate объекта Statement. Объекты ResultSetMetaData создаются при помощи метода getMetaData объекта ResultSet. JDBC позволяет выполнять скомпилированные запросы и хранимые процедуры с использованием объектов PreparedStatement и CallableStatement.
Технология Java Server Pages (JSP) позволяет создавать динамические web-страницы с использованием HTML, XML и Java. JSP-страницы предоставляют в распоряжение разработчика всю мощь полноценного объектно-ориентированного языка программирования. Ни VBScript, ни JavaScript в JSP использоваться не могут. JSP-страницы компилируются в машинно-независимый байт-код.
JSP-страницы компилируются в виде подклассов класса HttpServlet. Следовательно, в JSP-страницу можно помещать как законченные Java-программы, так и фрагменты Java-кода. Чтобы работа с JSP-страницами была возможна, web-сервер должен реализовывать спецификации Java Servlet 2.1+ и Java Server Pages 1.0+. Apache Tomcat, свободно распространяемый продукт с открытыми исходными текстами от проекта Jakarta, поддерживает эти спецификации. Tomcat может работать в связке с Apache или как автономный тестовый web-сервер.
При использовании Tomcat (или любого другого обработчика JSP) драйверы JDBC и JSP-страницы должны помещаться в специальные каталоги. То же самое относится и к классам Java bean, используемым JSP-страницами. Получив запрос на обработку JSP-страницы, Tomcat сначала убеждается, что используется самая новая версия страницы. Если обнаруживается более поздняя некомпи-лированная версия страницы, Tomcat автоматически производит ее синтаксический анализ и компиляцию. В памяти одновременно находится максимум одна копия JSP-страницы, и запросы на обработку JSP-страниц выполняются отдельным потоком обработчика сервлетов, а не отдельным процессом. Если требуется, Java-код в JSP-странице может вызывать скомпилированный класс Java bean.
MySQL — это свободно распространяемая СУБД с открытыми текстами, работающая под управлением Unix, Linux и Windows. Платить за лицензию на ее установку не требуется. MySQL может обеспечить весьма быструю обработку запросов, но она не поддерживает представления, хранимые процедуры и триггеры. Ограничения ссылочной целостности могут быть определены, но они не будут реализовываться MySQL. MySQL поддерживает словарь данных в базе данных с именем mysql. Для определения полномочий пользователей можно запросить таблицы user и db из этой базы данных. Для обращения к MySQL через JDBC учетной записи пользователя должен быть предоставлен доступ к базе данных либо с любого компьютера, либо с IP-адреса, представляющего локальный компьютер.
MySQL предоставляет ограниченные возможности для управления параллельной обработкой. Транзакции не поддерживаются, поэтому нет операторов COMMIT и ROLLBACK и невозможно установить уровень изоляции. MySQL налагает блокировки на уровне таблицы. Коллективная блокировка чтения налагается при выполнении операторов SELECT, а при записи налагается монопольная блокировка. Блокировка на уровне таблиц может привести к снижению пропускной способности. Операторы, которые должны выполняться в рамках транзакции, можно окружать командами LOCK TABLES и UNLOCK TABLES. Взаимная блокировка предотвращается за счет того, что одновременно может быть активен только один оператор LOCK TABLES. «Грязное» чтение возможно, если некоторые приложения производят откат выполняемых действий, но не блокируют таблицы на время выполнения этих действий.
Возможности MySQL в сфере резервного копирования и восстановления также ограничены. В MySQL имеется утилита, которая дополняет программы копирования операционной системы. MySQL ведет журнал выполненных команд. Этот журнал не содержит исходных и конечных образов, и в него не записываются результаты массовых обновлений или удалений. Хотя MySQL имеет множество ограничений MySQL, она проста в использовании, а те возможности и функции, которые в ней реализованы, реализованы качественно.

Архитектуры организационных систем обработки данных

admin — Thu, 17 Jun 2010 15:52:29 +0000

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

Системы совместного использования файлов

admin — Tue, 08 Jun 2010 15:52:52 +0000

В этой архитектуре, которая носит название архитектуры с совместным использованием файлов (file-sharing), на пользовательских компьютерах находятся не только прикладные программы, но и СУБД. В этом случае сервер является файловым сервером, а не сервером базы данных. Почти во всех системах с совместным использованием файлов применяются локальные сети из микрокомпьютеров.
Архитектура с совместным использованием файлов была разработана до клиент-серверной архитектуры и во многих отношениях является более примитивной. При совместном использовании файлов СУБД каждого пользовательского компьютера посылает запросы на обработку файлов подсистеме обработки данных операционной системы файлового сервера. Это означает, что при такой архитектуре трафик в локальной сети гораздо больше, чем при клиент-серверной архитектуре.
Рассмотрим, например, запрос, возвращающий столбцы Name и Address всех строк таблицы CUSTOMER, где столбец Zip имеет значение 98033. В клиент-серверной системе прикладная программа послала бы следующую SQL-команду:
SELECT NAME. ADDRESS FROM CUSTOMER WHERE ZIP=98033
Сервер возвратил бы столбцы Name и Address всех строк, удовлетворяющих критерию отбора.
В системе с совместным использованием файлов СУБД находится на локальном компьютере, поэтому программы на файловом сервере не способны обработать SQL-запрос. Подобная обработка должна происходить иа пользовательском компьютере, поэтому СУБД вынуждена запрашивать у файлового сервера всю таблицу CUSTOMER целиком. Если эта таблица имеет индексы или другие связанные с ней избыточные данные, они также должны быть переданы клиенту. Ясно, что при совместном использовании файлов по локальной сети передаются гораздо большие объемы данных.
Из-за этих проблем системы с совместным использованием файлов редко используются для обработки больших объемов данных, которая ориентирована на транзакции. Слишком много данных необходимо блокировать и передавать для выполнения каждой транзакции, и производительность такой архитектуры оказывается слишком низкой. Однако для этой архитектуры все же есть одно применение: запрос данных, загруженных из базы. Если одному или нескольким пользователям требуется доступ к большим фрагментам базы данных для составления отчетов или ответов на запросы, то, возможно, имеет смысл поставить сервер, загружающий большие порции данных. При этом загруженные данные не обновляются и не возвращаются в базу данных. Примеры обработки загруженных данных мы будем рассматривать далее в этой главе.
Системы с совместным использованием файлов имеют также приложения, не связанные с базами данных. В качестве примера можно привести системы, где требуется хранить большие файлы (звук, графику и анимацию) на высокоскоростных дисках большого объема. С помощью таких систем организуется также совместное использование дорогих принтеров, плоттеров и другого периферийного оборудования.

Распределенная обработка и обработка распределенных баз данных

admin — Sat, 22 May 2010 15:53:07 +0000

Система с совместным использованием файлов, клиент-серверная система и система обработки распределенных баз данных имеют одно важное отличие от системы удаленной обработки данных: всех них для обработки приложений или СУБД используется более одного компьютера. Соответственно, большинство сказало бы, что все эти три архитектуры являются примерами распределенных систем (distributed systems), поскольку обработка приложения распределена по нескольким компьютерам.