Основные  данные о работе

Содержание

     Введение……………………………………………………………………….……3

     Основная  часть………………………………….…………………………….…….5

     1.Базы  данных и СУБД………………………..…………………………...………5

     1.1.Понятие  банка данных, базы данных и СУБД…………………….....………5

     1.2. Функции СУБД………………………………………………………...…..…..8

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

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

     2.Обзор  MySQL…………………………………………………………………...12

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

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

     2.3.Полнотекстовый  поиск в MySQL……………………………………………19

     Заключение………………………………………………………………………..25

     Глоссарий …………………………………………………………………………26

     Список  использованных источников……………………………………………27

     Приложения……………………………………………………………………….28

Введение

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

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

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

     Среди наиболее ярких представителей систем управления базами дан-ных можно  отметить: Lotus Approach, Microsoft Access, Borland dBase, Bor-land Paradox, Microsoft Visual FoxPro, Microsoft Visual Basic, а также  СУБД Microsoft SQL Server и Oracle, используемые в приложениях, построенных по технологии "клиент-сервер". Фактически, у любой современной СУБД существует аналог, выпускаемый другой компанией, имеющий аналогичную область применения и возможности, любое приложение способно работать со многими форматами представления данных, осуществлять экспорт и импорт данных благодаря наличию большого числа конвертеров. Общепринятыми, также, являются технологи, позволяющие использовать возможности других приложений, например, текстовых процессоров, пакетов построения графиков и т.п., и встроенные версии языков высокого уровня (чаще – диалекты SQL и/или VBA) и средства визуального программирования интерфейсов разрабатываемых приложений. Поэтому уже не имеет существенного значения, на каком языке и на основе какого пакета написано конкретное приложение, и какой формат данных в нем используется. Более того, стандартом "де-факто" стала "быстрая разработка приложений" или RAD (от английского Rapid Application Development), основанная на широко декларируемом в литературе "открытом подходе", то есть необходимость и возможность использования различных прикладных программ и технологий для разработки более гибких и мощных систем обработки данных. Поэтому в одном ряду с "классическими" СУБД все чаще упоминаются языки программирования Visual Basic 4.0 и Visual C++, которые позволяют быстро создавать необходимые компоненты приложений, критичные по скорости работы, которые трудно, а иногда невозможно разработать средствами "классических" СУБД. Современный подход к управлению базами данных подразумевает также широкое использование технологии "клиент-сервер".

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

     Основная  часть

      1.Базы  данных и СУБД 
 

      1.1.Понятие  банка данных, базы  данных и СУБД 
 

     Существует  множество различных систем управления базами данных, именуемые в последующем "СУБД", такие как: MySQL, PostgreSQL, Oracle, Clipper, FoxPro, Access. Но перед тем как приступить к изучению СУБД, рассмотрим несколько основных понятий.

     Данные - систематизированная и структурированная каким-либо образом информация.

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

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

     Поле - основной и минимальный элемент  данных.

     Запись - несколько полей.

     Связи - логические взаимосвязи между записями или полями.

     База  данных - это набор данных, который  связан с определенной темой или назначением.

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

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

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

     ТАБЛИЦА - это набор записей (строк), состоящих  из отдельных полей (столбцов), в  которых хранится информация и составляющая, собственно, содержание базы данных.

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

     Таблицы баз данных, как правило, допускают работу с гораздо большим количеством разных типов данных. Так, например, базы данных Microsoft Access работают со следующими типами данных.

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

     Числовой  – тип данных для хранения действительных чисел.

     Поле  Мемо – специальный тип данных для хранения больших объемов  текста (до 65 535 символов). Физически  текст не хранится в поле. Он храниться  в другом месте базы данных, а в поле храниться указатель на него, но для пользователя такое разделение заметно не всегда.

     Дата/время  – тип данных для хранения календарных  дат и текущего времени.

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

     Счетчик – специальный тип данных для уникальных (не повторяющихся в поле) натуральных чисел с автоматическим наращиванием. Естественное использование – для порядковой нумерации записей.

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

     Гиперссылка – специальное поле для хранения адресов URL Web-объектов Интернета. При  щелчке на ссылке автоматически происходит запуск браузера и воспроизведение  объекта в его окне.

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

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

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

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

     1.2. Функции СУБД 
 

     Современная система управления базами данных должна выполнять следующие функции:

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

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

     Запросы бывают "планируемые" и "не планируемые".

     Планируемый запрос – это запрос, необходимость  которого предусмотрена заранее. АД должен настроить физический проект базы данных таким образом, чтобы гарантировать достаточное быстродействие для таких запросов. Он характерен для "операционных приложений".

     Не  планируемый запрос – это специальный  запрос, необходимость которого не была предусмотрена заранее. Он характерен для приложений "поддержки решений".

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

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

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

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

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

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

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

     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. Имеется несколько случаев, когда стоит блокировать таблицы: