Базы данных

     Восстановление  и дублирование данных осуществляется СУБД или администратором.

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

     СУБД  должна выполнять все указанные  функции с максимально возможной  эффективностью.

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

     1.3. Модели данных, поддерживаемые  СУБД 
 

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

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

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

     Дерево - ориентированный граф где все  вершины, кроме корня, находятся  в голове только одной дуги, корень не находится в голове ни одной  из дуг и связан с вершиной дерева.

     Между записями в иерархии могут быть определены связи: “один ко многим”, или “один к одному”, где запись, соответствующая элементу “один” указанной связи, определяется как исходная, а соответствующая элементу “много” - как порожденная.

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

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

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

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

     Автоматизированные  информационные системы (АИС), основу которых  составляют базы данных, появились  в 60-х годах в военной промышленности и в бизнесе – там, где были накоплены значительные объемы полезных данных. Первоначально автоматизированные информационные системы были ориентированы лишь на работу с информацией фактического характера – числовыми или текстовыми характеристиками объектов. Затем, по мере развития техники, появилась возможность обрабатывать текстовую информацию на естественном языке.

     Принципы  хранения разных видов информации в  АИС сходны, но алгоритмы ее обработки  определяются характером информационных ресурсов. Соответственно были выделены два класса АИС: документальные и  фактографические.

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

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

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

     2.Обзор MySQL 
 

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

     2.1. Базисные команды клиента MySQL 
 

     Синтаксис USE. Команда USE db_name сообщает, чтобы MySQL использовал базу данных db_name как заданную по умолчанию для последующих запросов. База данных остается текущей до конца сеанса, или пока не будет выдана другая инструкция USE:

     mysql> USE db1;

     mysql> SELECT count(*) FROM mytable;      # selects from db1.mytable

     mysql> USE db2;

     mysql> SELECT count(*) FROM mytable;      # selects from db2.mytable

     Создание  специфической базы данных посредством  инструкции USE не препятствует Вам обращаться к таблицам в других базах данных. Пример ниже обращается к таблице author из базы данных db1 и таблице editor из базы данных db2:

     mysql> USE db1;

     mysql> SELECT author_name,editor_name FROM author,db2.editor

                WHERE author.editor_id = db2.editor.editor_id;

     Инструкция  USE предусмотрена для совместимости с Sybase.

     Синтаксис DESCRIBE (получение информации о столбцах)

     {DESCRIBE | DESC} tbl_name {col_name | wild}

     DESCRIBE представляет собой сокращение для вызова SHOW COLUMNS FROM. DESCRIBE обеспечивает информацию относительно столбцов таблицы. col_name может быть именем столбца или строкой, содержащей групповые символы SQL `%' и `_'.

     Если  типы столбцов не те, которые Вы задавали в инструкции CREATE TABLE, обратите внимание, что MySQL иногда изменяет типы столбцов.

     Эта инструкция предусмотрена для совместимости с Oracle.

     Инструкция  SHOW обеспечивает подобную информацию.  
 

     2.2.Команды  транзакций и блокировок  в MySQL 
 

     Синтаксис BEGIN/COMMIT/ROLLBACK. По умолчанию, MySQL выполняется в режиме autocommit. Это означает, что, как только Вы сделаете модификацию, MySQL сохранит ее на диск.

     Если  Вы используете транзакционно-безопасные таблицы (подобно BDB, InnoDB, Вы можете перевести MySQL в режим не-autocommit следующей командой:

     SET AUTOCOMMIT=0

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

     Если  Вы хотите переключать режим AUTOCOMMIT для одного набора инструкций, Вы можете использовать команды обрамления BEGIN или BEGIN WORK так:

     BEGIN;

     SELECT @A:=SUM(salary) FROM table1 WHERE type=1;

     UPDATE table2 SET summmary=@A WHERE type=1;

     COMMIT;

     Обратите  внимание, что, если Вы используете  не транзакционно-безопасные таблицы, изменения будут сохранены сразу, независимо от состояния режима autocommit.

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

     Если  Вы используете BEGIN или SET AUTOCOMMIT=0, Вы должны использовать двоичный файл регистрации MySQL для резервирования вместо старого файла регистрации модификаций. Транзакции сохранены в двоичном протоколе, запись для COMMIT может гарантировать, что транзакции, которые прокручены обратно, не сохранены.

     Следующие команды автоматически заканчивают  транзакцию (как будто Вы сделали  COMMIT перед выполнением команды):

     ALTER TABLE BEGIN CREATE INDEX

     DROP DATABASE DROP TABLE RENAME TABLE

     TRUNCATE

     Вы  можете изменять уровень изоляции для  транзакций командой SET TRANSACTION ISOLATION LEVEL .... Синтаксис LOCK TABLES/UNLOCK TABLES:

     LOCK TABLES tbl_name [AS alias] {READ|[READ LOCAL]|[LOW_PRIORITY] WRITE}

                 [, tbl_name {READ | [LOW_PRIORITY] WRITE} ...]

     ...

     UNLOCK TABLES

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

     Основные  причины использовать LOCK TABLES: эмуляция транзакций или получение большего быстродействия при модифицировании таблиц. Это объясняется более подробно позже.

     Если  поток получает блокировку READ на таблице, он (и все остальные) могут только читать из таблицы. Если поток получает блокировку WRITE на таблице, то только он может читать или писать таблицу. Другие потоки блокированы.

     Различие между READ LOCAL и READ в том, что READ LOCAL позволяет непротиворечивым инструкциям INSERT выполняться в то время, как установлена блокировка. Это не может использоваться, если Вы собираетесь управлять файлами базы данных снаружи MySQL в то время, как Вы поставили блокировку.

     Когда Вы используете LOCK TABLES, Вы должны блокировать все таблицы, которые Вы собираетесь использовать, и использовать тот же самый псевдоним, который собираетесь применить в Ваших запросах! Если Вы используете таблицу в запросе несколько раз (с псевдонимами), Вы должны получить блокировку для каждого псевдонима!

     Блокировки  WRITE обычно имеют более высокий приоритет, чем READ, чтобы гарантировать, что модификации будут обработаны как можно скорее. Это означает, что, если один поток получает блокировку READ, и затем другой поток запрашивает блокировку WRITE, последующие запросы блокировки READ будут ждать, пока поток WRITE не получит блокировку и не снимет ее. Вы можете использовать блокировку LOW_PRIORITY WRITE, чтобы позволить другим потокам получать блокировки READ, в то время как поток ждет блокировку WRITE. Вы должны использовать блокировку LOW_PRIORITY WRITE только в случае, если Вы уверены, что будет в конечном счете такой момент, когда никакие потоки не будут иметь запрос на блокировку READ.

     LOCK TABLES работает так:

• Сортирует все таблицы, которые будут блокированы, во внутреннем определенном порядке (с точки зрения пользователя, порядок неопределен).
• Если таблица блокирована с помощью блокировок read и write, write всегда размещается перед read.
• Блокируется одна таблица за раз, пока поток не получает все блокировки.

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

     Если  Вы используете блокировку LOW_PRIORITY_WRITE для таблицы, это означает, что MySQL будет ждать эту блокировку до тех пор, пока не останется потока, который просит блокировку READ. Когда поток имеет блокировку WRITE и ждет, чтобы получить блокировку для следующей таблицы в списке таблиц блокировки, все другие потоки будут ждать освобождения блокировки WRITE. Если это становится серьезной проблемой для Вашей прикладной программы, Вы должны рассмотреть преобразование некоторых из Ваших таблиц в транзакционно-безопасные.

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

     Обратите  внимание, что Вы НЕ должны блокировать  таблицы, которые Вы используете  с INSERT DELAYED. Это потому, что в этом случае INSERT выполняется отдельным потоком.

     Обычно  Вы не должны блокировать таблицы, поскольку все одиночные инструкции UPDATE атомные: никакой поток не может сталкиваться с любым другим, в настоящее время выполняющим инструкции SQL. Имеется несколько случаев, когда стоит блокировать таблицы: