Инструментарий, поставляемый с MySQL

Программные блокировки

Функции GET_LOCK() и RELEASE_LOCK() реализуют другой механизм блокирования. Эти блокировки не связаны с какими-либо ресурсами и не контролируются самой СУБД. Поэтому их называют программными блокировками, т.е. их контроль должен осуществляться программным путем. У каждой такой блокировки есть имя, и в конкретный момент времени поток может ставить только одну программную блокировку.

Функция запрашивает именованную блокировку (имя) на указанное число секунд (тайм-аут) и не завершится, пока не истечет период времени тайм-аута или пока блокировка не будет получена.

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

Функция снимает указанную именованную блокировку, которая ранее была получена с помощью функции GET_LOCK(). Если имя блокировки не было зарегистрировано, возвращается NULL.

На внутреннем уровне программа MySQL блокирует таблицы целиком в случае необходимости. Допускается также блокировать строки, столбцы и страницы (под страницей понимается произвольный блок данных, связанных с таблицей). С точки зрения производительности преимущество той или иной модели проявляется по-разному.

Табличное блокирование выгодно для Web-приложений.

Блокирование на уровне строк лучше подходит для баз данных, в которых часто происходят откаты.

6.Распределенные базы данных.Проблемы распределенной обработки. РБД (англ. "Distributed DataBase", DDB) представляют определенным образом связанные между собой БД, рассредоточенные на какой-либо территории (локально или регионально), обеспечивающие свободный обмен информацией и поиск данных в них. Такие БД могут располагаться на различных узлах компьютерной сети.
Выделяют однородные и неоднородные РБД. Часто данные размещаются в БД и СУБД по месту своего возникновения или наиболее эффективного использования в ЭВМ, удаленных друг от друга на большие расстояния, хотя каждая из этих ЭВМ управляет своими локальными СУБД. Возникает необходимость решения задач с распределенными БД путем организации между ЭВМ сети передачи данных по каналам связи, а также обеспечения технической и программной поддержки обмена данными между ними.

Для работы с распределенными данными создаются системы управления распределенными базами данных (СУРБД), оснащенные каталогами, хранящими структуру сети, информацию о локальных СУРБД и БД, а также программным обеспечением, управляющим взаимодействием прикладной программы и конкретной локальной БД сети. Управление однотипными локальными СУРБД осуществляется просто. В противном случае в сеть РБД включают различные программные и технические устройства, обеспечивающие единый интерфейс, согласование и возможность выполнения информационных процессов (промежуточную интерфейсную СУРБД, протокол Z39.50 и др.).

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

В распределенной СУБД различаются четыре типа сбоев:

· сбой транзакции,

· сбой узла (системы),

· сбой носителя (диска),

· сбой коммуникационной линии.

Причин сбоев транзакции может быть несколько:

· ошибки, вызванные неверными входными данными,

· обнаружение возникшего или возможного тупика.

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

Cбои узлов (системные сбои) могут быть вызваны

· аппаратными отказами (процессора, оперативной памяти, питания) или

· программными ошибками (в системном или прикладном коде).

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

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

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

· ошибки в сообщениях,

· нарушение упорядоченности сообщений,

· потерянные (недоставленные) сообщения,

· повреждения на линиях связи

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

8+10.Клиент-серверная СУБД —Клиент-серверная СУБД позволяет обмениваться клиенту и серверу минимально необходимыми объёмами информации. При этом основная вычислительная нагрузка ложится на сервер. Клиент может выполнять функции предварительной обработки перед передачей информации серверу, но в основном его функции заключаются в организации доступа пользователя к серверу.

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

Архитектура клиент-сервер

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

- изменения в инфраструктуре бизнеса;

- возросшие требования доступа к данным предприятия;

- необходимость повышения производительности конечных пользователей на базе эффективного использования информации;

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

Термин «клиент-сервер» используется при разработке компьютеризированных систем для описания вычислительной модели. Эта модель основана на распределении функций между двумя типами независимых и автономных процессов: серверами и клиентами. Клиент – это любой процесс, который запрашивает определенные ресурсы или сервисы от других (серверных) процессов. Сервер – это процесс, который предоставляет необходимые сервисы (услуги) другому процессу (клиенту). Клиент и сервер какого-либо ресурса могут находиться как в рамках одной вычислительной системы, так и на различных компьютерах, связанных сетью. Уровень распределения задач обработки данных – главное отличие клиент-серверных систем от систем с мэйнфреймом.

В зависимости от степени разделения процессов между клиентом и сервером, сервер и клиент считаются либо сильным, либо слабым. Слабый («тонкий») клиент (thin client) выполняет минимум отработки на стороне клиента, в то время как сильный («толстый») клиент (fat client) берет на себя относительно большую часть обработки данных. Соответственно, сильный («толстый») сервер (fat server) несет основную нагрузку по обработке данных, нагрузка же на слабый сервер (thin server) относительно невелика. Поэтому, как правило, слабые клиенты связаны с сильными серверами, а сильные клиенты – со слабыми серверами. С этой точки зрения система с мэйнфреймом представляет собой пример максимально сильного сервера и максимально слабого клиента, т.к. все процессы обработки данных выполняются на серверной стороне (главная машина), а на клиентской стороне (неинтеллектуальные терминалы) никакая обработка данных не ведется.

Особенных аппаратных средств для этой архитектуры не требуется.

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

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

Главная черта архитектуры клиент – сервер является то, что клиент посылает сообщения именованным серверам. Это дает ряд важных преимуществ:

1) Клиентский и серверный процессы не обязательно должны находиться на одной и той же машине, хотя это допустимо.

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

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

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

Проектируя любое приложение клиент – сервер, необходимо решить две задачи:

- минимизация числа операций обмена между клиентом и сервером;

- выбор места обработки.

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

Клиент обычно качественно обеспечивает работу прикладного интерфейса, а сервер – обработку совместно используемых данных.

Очевидное решение состоит в следующем – реализовать на клиенте прикладной интерфейс, а на сервере – выполнять все операции под совместно используемыми данными.

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

Клиент включает в себя аппаратные и программные компоненты. Желательно, чтобы в состав клиента были включены:

- мощное оборудование;

- ОС с возможностью многозадачной обработки информации;

- графический интерфейс пользователя (GUI);

- коммуникационные возможности.

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

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

· файловые сервисы для локальных сетей, в которых компьютер с быстрыми дисками большой емкости совместно используется разными пользователями;

· сервисы печати для локальных сетей, в которых ПК с одним или более принтерами совместно используется несколькими клиентами;

· сервисы факсимильной связи, которые требуют, чтобы, по крайней мере, один сервер был оборудован факсом;

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

· сервисы БД, в которых содержатся наиболее распространенные клиент-серверные реализации;

· сервисы транзакций, предоставляемые серверами транзакций, подключенными к серверу БД;

· другие сервисы, включая обслуживание устройств CD-ROM, видео, резервное копирование и др.

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

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

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

9+11.Этапы развития БД. Файлы и файловые системы.БД на больших ЭВМ.БД на ПК.

Файлы и файловые системы

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

· создания файла,

· открытия ранее созданного файла,

· чтения некоторой записи из файла (текущей, следующей, предыдущей, первой, последней),

· занесения в файл новой записи на место текущей или добавления новой записи в конец файла.

Увы! Файловые системы оказались не очень хорошо приспособленными к работе с системами хранения и управления информацией.

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

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

Указанный недостаток был первым существенным недостатком файловых систем, который явился толчком к созданию новых систем хранения и управления информацией.

2) Для разных файловых систем серьезное администрирование режимов доступа не предусматривалось вообще или устанавливалось с помощью подхода, впервые реализованного в ОС UNIX. В последнем случае каждому пользователю соответствует пара идентификаторов, определяющих группу, к которой относится пользователь, и номер пользователя в группе, с помощью которых определяются доступные действия с файлом для каждого пользователя. При этом для каждого такого файла хранится идентификатор пользователя, который создал этот файл, и фиксируется, какие действия с файлом может производить создатель, а какие действия доступны пользователям той же группы и других групп.

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

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

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

· Разделение и изоляция данных. Это приводит к затруднениям при организации доступа к этим данным и их последующей обработки.

· Дублирование данных. В файловой системе фактически поощряется бесконтрольное дублирование данных. Однако такое дублирование сопровождается, с одной стороны, неэкономным расходованием ресурсов (памяти), а с другой – может привести к нарушению целостности данных, поскольку данные по одному вопросу могут стать противоречивыми.

· Зависимость от данных. Физическая структура и способ хранения записей файлов данных жестко фиксируются в коде программы приложений. Любое изменение данных обязательно требуют и изменения в коде обрабатывающего приложения.

· Несовместимость файлов. Структура файлов данных определяется кодом приложения, т.е. зависит от языка программирования этого приложения. Несовместимость файлов данных, созданных с использованием разных языков, затрудняет процесс их совместной обработки. Для совместного использования файлов данных требуется программа, преобразующая данные из этих файлов в некоторый общий формат.

· Фиксированные запросы / быстрое увеличение количества приложений. Все требуемые запросы из файлов данных с использованием файловых систем должны создаваться программистом. Изобилие вариантов запросов приводит к тому, что программисты оказываются не в силах справиться с потоком задач и успевают обеспечить только фиксированное, ограниченное число запросов, либо в попытке обеспечить приложениями всех клиентов обнаруживают, что они не в силах удовлетворить всех заказчиков.

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

Ниже кратко описаны основные этапа развития СУБД за период более, чем 30 лет.

Базы данных на больших ЭВМ

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

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

Характерные черты этого периода:

· СУБД базируются на мощных мультипрограммных ОС (в основном поддерживается работа с централизованной БД в режиме распределенного доступа).

· Функции управления распределением ресурсов в основном осуществляются операционной системой.

· Поддерживаются языки низкого уровня манипулирования данными.

· Значительная роль отводится администрированию данных.

· Проводятся серьезные работы по обоснованию и формализации реляционной модели данных (была создана первая система System R с идеологией реляционной модели данных).

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

· Появляются первые языки высокого уровня для работы с реляционной моделью данных. Однако стандарты для этих языков пока отсутствуют.

Эпоха персональных компьютеров

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

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

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

Особенности этого периода:

· СУБД рассчитаны на создание БД в основном с монопольным доступом. Лишь иногда предполагалась последовательная работа нескольких пользователей (бухгалтер-главбух).

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

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

· При наличии высокоуровневых языков манипулирования данными типа SQL (использующих достижения реляционной алгебры) в настольных СУБД поддерживались низкоуровневые языки манипулирования данными на уровне отдельных строк таблиц.

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

· Наличие монопольного режима работы фактически привело к вырождению функций администрирования БД и к отсутствию инструментальных средств администрирования БД.

· Относительно скромные требования к аппаратному обеспечению со стороны настольных СУБД. Вполне приличные приложения иногда могли работать даже на РС-286 (например, на Clipper).

Распределенные базы данных

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

Распределенная СУБД может рассматриваться как некий способ совместной работы отдельных локальных СУБД, расположенных на отдельных локальных узлах.

Особенности этого периода:

· Практически все современные СУБД обеспечивают поддержку реляционной модели в плане целостности (т.е. защиты базы данных от санкционированных пользователей):

· структурной целостности – допустимыми являются только данные, представленные в виде отношений реляционной модели,

· языковой целостности – используются языки манипулирования данными высокого уровня (в основном SQL),

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

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

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

· Появились серьезные теоретические труды по оптимизации реализаций распределенных БД и работе с распределенными транзакциями и запросами с внедрением полученных результатов в коммерческие СУБД.

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

· Разработаны стандарты в рамках языков описания и манипулирования данными (начиная с SQL) технологий по обмену данными между различными СУБД.

· Начались работы, связанные с концепцией объектно-ориентированных БД– ООБД.

Особенности настоящего периода:

· Этот этап характеризуется появлением новой технологии доступа к данным – Интранет. В этом случае отпадает необходимость использования специализированного клиентского программного обеспечения. Для работы с удаленной базой данных используется стандартный броузер. Процесс обращения к данным происходит аналогично скольжению по всемирной паутине.

· Встроенный код (чаще всего на языке Jawa, Jawa-script, Perl) отслеживает все действия пользователя и транслирует их в низкоуровневые SQL-запросы к БД.

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

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

Система управления базами данных (СУБД) MySQL.Основы использования.Инсталляция.Характеристика клиентов

SQL (Structured Query Language — Структурированный Язык Запросов) — это стандартный язык запросов по работе с реляционными БД. Язык SQL появился после реляционной алгебры, и его начальный вариант был разработан в конце 70-х годов в компании IBM Research. Он был реализован в первом прототипе реляционной СУБД фирмы IBM System R. В дальнейшем этот язык применялся во многих коммерческих СУБД и в силу своего широкого распространения постепенно стал стандартом «де-факто» для языков манипулирования данными в реляционных СУБД, хотя он и весьма далек от полноценной реализации реляционной модели.

SQL больше напоминает человеческий язык, чем, например, C, PHP, или Java, так как это язык четвертого поколения[1].

Состоит из многопотокового сервера (mysqld), клиентской библиотеки (в версии 4.0 появилась возможность встраивать сервер в приложение) и множества утилит. Одна из утилит - mysql - представляет собой клиентское приложение для полного доступа к возможностям сервера (отправляет SQL-запросы и выдаёт ответ на терминал). Для запуска mysqld можно использовать программы mysql.server и mysqld_safe (mysqld_multi для запуска нескольких серверов). Первоначально мимикрировала под mSQL (включая интерфейс утилит и API). Имеются API для C, C++, Java (JDBC), Eiffel, Perl, PHP, Python, Ruby, Tcl. Поддержка ODBC 2.5 с расширениями.

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

Программы MySQL

MySQL состоит из достаточно большого набора программ (утилит). Ниже рассматриваются назначение, синтаксис вызова, поддерживаемые опции и используемые переменные.

Основные утилиты следующие:

mysqlaccess – Perl-сценарий, проверяющий привилегии заданных узла, пользователя и базы данных.

mysqladmin – утилита, которая выполняет ряд административных задач. С помощью утилиты на сервер посылаются команды, обычно разрешенные лишь администратору базы данных.

mysqld – это сервер MySQL, работающий в фоновом режиме, принимая запросы от клиентов (демон MySQL). Эта программа обеспечивает клиентам доступ к управляемым базам данных:

· mysqld-max – версия сервера, скомпилированная с включением всех возможных опций;

· mysqld-nt – версия сервера, скомпилированная для систем Windows NT и Windows 2000. Включена поддержка именованных каналов;

· mysqld-opt – версия сервера, оптимизированная для процессоров Pentium и рекомендуемая для Windows 95 и Windows 98;

mysqld-multi – позволяет запускать несколько серверов MySQL одновременно.

mysqldump – утилита резервирования содержимого таблиц баз данных в текстовых файлах. Она извлекает информацию из указанной базы данных и формирует SQL-инструкции, предназначенные для воссоздания указанных таблиц в другой базе данных. Полученные инструкции записываются в поток stdout. Как минимум, это будут инструкции CREATE TABLE и INSERT.

mysqlimport – импортирует записи в таблицы из указанного текстового файла. Это оболочка инструкции LOAD DATA INFILE, обеспечивающая импорт записей в таблицы.

mysqlshow – утилита, обеспечивающая сбор информации о базах данных и таблицах, возвращает информацию о базах данных и таблицах. Это оболочка инструкций SHOW DATABASES, SHOW TABLES и SHOW COLUMNS. При отсутствии опций будет выдан список баз данных.

perror – возвращает описание числового кода ошибки.

Есть еще достаточно большой набор утилит (isamchk, myisamchk, myisampack, pack_isam) и сценариев (mysql.server, mysqlbug, safe_mysqld), которые обеспечивают решение тех или иных задач при работе с СУБД, но их изучение рационально только при необходимости. Две утилиты: mysql и mysqlc ‑ будут рассмотрены далее.

Администрирование БД

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

· интерпретация и представление данных в удобном формате путем структурирования информации;

· распространение информации среди соответствующих работников в нужное время;

· защита данных и контроль доступа к данным;

· контроль дублирования данных и использования их как на внешнем, так и на внутреннем уровнях.

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

Для высшего исполнительного руководства БД должна:

· предоставлять информацию, необходимую для предприятия стратегических решений, стратегического планирования, формирования политики и определения целей;

· обеспечивать доступ к внешним и внутренним данным для выявления возможности роста и направления этого роста;

· предоставлять структуру для определения и проведения в жизнь политики предприятия;

· повышать вероятность позитивных изменений в инвестиционной деятельности компании за счет поиска новых способов снижения затрат и повышения производительности труда;

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

Для руководства среднего звена БД должна обеспечить:

· предоставление необходимых сведений для принятия тактических решений и планирования;

· наблюдение и контроль (мониторинг) размещения и использования ресурсов предприятия;

· предоставление структуры для реализации поддержки защиты и секретности данных в БД.

Для оперативного руководства БД должна обеспечить:

· представление и поддержку операций предприятия, насколько это возможно;

· получать результаты запросов на определенном уровне исполнения;

· расширять возможности краткосрочных операций предприятия.

Можно сказать, что БД – это совокупность операционных данных, отражающих деятельность предприятия.

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

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

- технологические: программное и аппаратное обеспечение СУБД;

- организационные: административные действия;

- интеллектуальные: внутреннее противодействие сотрудников предприятия любым нововведениям.

Появление СУБД с ее идеологией совместного использования данных – это новый уровень управления информацией, который привел к необходимости иметь отдел ИС.

По мере роста приложений БД управление данными становилось все более сложной задачей, что привело к разработке функций администрирования БД, а лицо, ответственное за управление централизованной и распределенной БД, называется администратором БД (DBA).

Основные функции DBA

Деятельность администратора должна охватывать следующие направления:

· планирование БД, включая определение стандартов и процедур, проведение их в жизнь;

· сбор требований к БД и концептуальное проектирование;

· логическое проектирование БД и разработка транзакций;

· физическое проектирование БД и ее реализация;

· тестирование и отладка БД;

· операции с БД и ее обслуживание;

· обучение работе с БД и поддержка пользователей.

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

· Управление доступом пользователей.

Системы управления файлами

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