Тема 5. Использование баз данных для организации хранения данных. Технология корпоративной работы.

Вопросы

1. Понятие СУБД.

2. Реляционные базы данных.

3. Виды баз данных.

4. Виды структур баз

 

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

Внесение объекта в базу – только полдела. Его еще нужно как-то характеризовать, связать с ним определенное значение. И тут нужно ввести понятие "данное". Данное – это определенный показатель, характеризующий объект и наделяющий его определенным значением. Причем не обязательно, чтобы объект был определен одним данным – их может быть много. Представь, что ты имеешь дело с хакерской структурой. Хакерство – это объект. А вот данные - это уже хакерские течения, стаж незаконной деятельности, количество написанных эксплойтов и взломанных машин и т.п. Другими словами, данные – это характеристики определенного объекта. Именно это больше всего интересует клиента, обратившегося к пока еще будущей БД.

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

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

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

Реляционные базы данных.

Та или иная СУБД зависит от модели, которая положена в основу базы. В наше время стали наиболее распространенными две модели: реляционная (модель отношений) и объектно-ориентированная (модель объектов).

Начнем с реляционной модели. В далеком 1969 году американский математик доктор Э.Ф. Кодд (Е.F. Codd) проанализировал сложившуюся к тому времени ситуацию по базам данных и пришел к выводу, что дело плохо. Во всех имевшихся в то время моделях были существенные недостатки: избыточность данных, сложность обработки и отсутствие безопасности хранения информации и т.п. После тягостных раздумий Кодд решил создать свою модель - реляционную. Для тех, кто злостно прогуливал английский, напомню, что relation переводится как "отношение" или просто "таблица". Гениальный доктор просто реализовал хранение данных в табличной форме, то есть организовал такие "хранилища" в виде логических структур (физические методы хранения могут быть любыми). Тем самым Кодд сумел добиться наглядности представления информации и удобства ее обработки. Благодаря достижению этого гения для формирования таблицы данных стало достаточно выполнить определенный логический запрос, подчиняющийся законам булевой алгебры. Среди операторов манипуляции данными существуют минимум три операции: извлечение строк (SELECT), извлечение столбцов (PROJECT) и объединение таблиц (JOIN). В результате этих действий мы получаем таблицу. И простой вывод из всего этого: результатом любой операции в реляционной модели является объект того же рода, что и объект, над которым осуществлялось действие.

Это и есть основное свойство описываемой модели.

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

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

Атрибут – это столбец в таблице с данными. Например, если на экране имеется информация о хакерских течениях, эксплойтах и стаже деятельности, то все эти столбцы являются атрибутами.

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

Отношение – таблица в целом. Описание типов данных, применяемых в табличке, называется заголовком отношения, а все остальное (собственно данные) – телом отношения.

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

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

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

1. Один -к-о дному. Этот вид связи применяется в том случае, когда первичный ключ одной таблицы ссылается на ключ другой. Чтобы было понятнее, приведу пример: допустим, у нас имеется три таблицы хакерской БД. Первая – информация о хакере: дата рождения, пол (девушки тоже бывают взломщиками;)) и ICQ. Вторая – хакер-ские течения (тип течения, его сложность и начальные капиталовложения). Ну и третья – тип выхода в интернет (технология, скорость доступа, оценка безопасности). Все эти таблицы нельзя свести в одну, так как в результате отсутствия связи между данными о доступе в интернет и о хакерс-ких течениях (и не только о них) мы получим путаницу. А при реализации связи в виде трех разных таблиц (с помощью первичного ключа - порядкового номера) обеспечивается и высокая скорость обработки, и упорядоченность данных.

2. Один - к о - м ногим. Наиболее типичная связь. Реализуется при копировании первичного ключа одной таблицы в другую. В этом случае во второй таблице этот ключик называется уже внешним. Непонятно? Тогда опять обращусь к примеру. Возьмем две таблицы – с информацией о хакере (таблица "Хакеры") и об отношениях с характеристиками эксплойтов, которые он написал (таблица "Эксплойты"). По сути, они связаны механизмом один-ко-многим. Действительно, каждый хакер может быть автором нескольких эксплойтов (так часто и бывает), но каждый эксплойт может быть написан одним и только одним автором (даже при совместной работе в хак-группах определенным эксплойтом занимается один человек). Здесь в качестве внешнего ключа в таблице "Эксплойты" используется ник хакера, а в качестве первичного – название эксплойта. При этом внешний ключ "ник хакера" является первичным ключиком в таблице "Хакеры", а сюда введен намеренно для связи двух таблиц и организации поиска нужной информации. Кстати, отношение "Эксплойты" совсем не обязательно будет состоять лишь из одного атрибута – можно добавить характеристики операционок, к которым применим эксплойт, количество целей, тип (локальный или удаленный) и т.п.

3. Многие -к о -м ногим. Суть этого типа связи в том, что ключ в одной таблице связывается с ключом другой и наоборот. С этим типом в реляционной модели дела обстоят очень плохо. Точнее, эту связь напрямую вообще никак не реализовать. Чтобы обойти этот недостаток, используется классическое решение: добавляется промежуточное отношение, которое будет связано типом "один-ко-многим" как с первой, так и со второй таблицей. Опять наглядный пример. Имеем два отношения: информация о хакерах и данные о серверах, которые когда-то были взломаны. Если подумать, то мы владеем следующей структурой: одним злоумышленником могут быть хакнуты несколько серверов (так часто и бывает в жизни), а на один сер-вак могут поселиться несколько хакеров (одновременно или последовательно), если админ вовремя не про-патчил баг. Чтобы реализовать подобную схему в реляционной БД, мы добавим промежуточное отношение из двух полей: ник хакера и адрес сервера. Таким образом, эта вспомогательная таблица будет иметь связь "один-ко-многим" как с первым, так и со вторым отношением. Конечно, в этом случае повысится избыточность данных, поэтому эксперты рекомендуют избегать таких связей.

Для каждой модели БД существует свой язык управления. Для реляционной модели таким языком является SQL (Structured Query Language, или структурированный язык запросов). Создатели этого языка стремились максимально приблизить свое детище к человеческому (английскому) языку и при этом наполнить его логическим смыслом.

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

Все SQL-запросы очень похожи на логические условия булевой алгебры (кто не прогуливал матан, тот меня поймет:)). Ты сам в этом убедишься, если посмотришь на врезку с основными командами языка.

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

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

Основные языки обращений к БД все же основываются на простом SQL-синтаксисе и имеют своего рода расширение, применимое к объектам. Примерами таких языков служат ORION, Iris и O2 Reloop.

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

Для нужд обычного человека (то есть тебя) вполне хватит реляционных СУБД, которые применяются повсеместно. Это и всенародно любимый MySQL, и менее любимый Access, и MSSQL. Подобных систем управления масса, определись и выбери ту, что тебе больше по сердцу. А сделать этот нелегкий выбор, как всегда, поможет этот уникальный СПЕЦвыпуск;).

Типы баз данных.

Какие бывают базы данных? В большинстве случаев решения программистов ограничиваются двумя типами: локальная и клиент-серверная. В первом случае получается шампунь "все-в-одном". Во втором мы разделяем данные и клиентское приложение и получаем два уровня.

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

ЛОКАЛЬНАЯ БАЗА

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

Яркими и наиболее распространенными представителями такого рода баз являются Dbase (файлы с расширением.dbf), Paradox (расширение.db) и Access (расширение.mdb). Форматы Dbase и Paradox - это даже не базы данных, а таблицы, потому что в одном файле может храниться только одна таблица данных. Индексы, ускоряющие поиск и осуществляющие сортировку, находятся в отдельных файлах. Таким образом, одна база данных может состоять из множества файлов, и это иногда приводит к определенным проблемам при поставке приложения конечному пользователю.

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

Самый главный недостаток локальных баз данных, как говорит юморист М. Задорнов, – "они тупые". Да-да. Качество и скорость доступа напрямую зависит от драйвера. В большинстве из них не было оптимизаторов SQL-запросов и какого-либо кеширо-вания. Возможности железа использовались минимально, поэтому на больших базах запросы выполняются крайне медленно.

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

Что такое разрушенный индекс? Индекс – это колонка, в которой все значения строк обязательно уникальны. Чаще всего для этих целей используется простой счетчик. Допустим, пользователь добавил запись и счетчик присвоил ей значение 195, но само значение счетчика не изменилось. При добавлении следующей записи счетчик снова пытается втулить нам число 195, но так как такая запись уже есть, происходит ошибка. Это и есть нарушение индекса, и лечить его достаточно просто (но нудно) – переформировать индекс.

СЕТЕВАЯ БАЗА ДАННЫХ

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

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

Посмотрим, как происходит обращение к базе данных. Программа и драйвер находятся на клиенте, а данные находятся на сервере или просто на удаленном компьютере. Как программа получает данные? Клиент передает драйверу SQL-запрос, который должен быть выполнен, но данные-то находятся удаленно! Чтобы отработать запрос, вся нужная таблица (в случае с Access - вся база данных, потому что все в одном файле) выкачивается на компьютер клиента, где драйвер обрабатывает данные.

Я бы побил того, кто придумал такую технологию, потому что это самое настоящее издевательство над системой. Представляешь, что будет, если надо выполнить запрос на базе данных в 1 Гб с телефонным соединением в 34 Кб/с? Это то же самое, что заставить

добывать нефть через трубочку для молочных коктейлей.

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

Но страшнее всего начали вести себя индексы. У таблиц Paradox, если они находились на расшаренном диске Win95, мне приходилось ремонтировать индексы как минимум раз в неделю. Когда я убрал файлы базы данных на сетевой диск сервера NetWare 3.11 (это был где-то 1998 год), проблемы с нарушением индексации сразу исчезли (наверное, потому что это действительно сервер, а не корявый Windows 9x).

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

КЛИЕНТ-СЕРВЕР

 

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

В технологии клиент-сервер драйвер уже изменил свое назначение, и теперь он уже должен только знать, как подключится к серверу и передать ему запрос. Остальное перекладывается на плечи сервера. Такая технология намного сокращает трафик, особенно при хорошем программировании. Допустим, пользователю нужно увидеть все данные, в которых имя определенной колонки содержит слова на букву "А". Клиен ту достаточно направить серверу всего лишь такой текст:

SELECT *

FROM Имя таблицы

WHERE Колонка LIKE ‘А%’

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

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

Получив нужные данные, сервер возвращает только их и ничего больше. Таким образом, клиент в любой момент может запросить у сервера нужные данные и не будет необходимости гонять по сети всю базу данных. При хорошо построенном приложении и оптимальных запросах клиент сможет работать с базой данных любого размера даже через модем в 56 Кбит/с. Неплохо? Главное - запрашивать только то, что нужно, и маленькими кусками.

ОСОБЕННОСТИ КЛИЕНТ-СЕРВЕРА

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

В более солидных клиент-серверных базах (MS SQL Server, Oracle и т.д.)

есть следующие дополнительные возможности:

1. вьюшки – более подробно обсуДим в статье по безопасности;

2. триггеры – функции, которые могут вызываться на определенные события (вставка, изменение и удаление данных), в этих функциях может производиться какая-то логика по обеспечению целостности данных;

3. репликация – объединение баз данных (допустим, у фирмы есть два офиса и в каждом из них своя база; настроив репликацию, обе базы могут автоматически сливаться в одну в главном офисе или обмениваться изменениями по расписанию);

хранимые процедуры и функции, которые выполняются на сервере по мизерному запросу клиента и могут содержать целые подпрограммы с логикой, которые будут выполнять какие-либо действия; для написания таких программ используется уже не просто язык SQL, а его расширение – Transact-SQL (для MS баз) и PL/SQL (для Oracle и др.).

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

ИНДЕКСЫ НА СЕРВЕРЕ

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

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

В локальных базах данных индексы хранятся линейно. Это как колонка из упорядоченных данных, и для строк это то же самое, что выстроить все слова по алфавиту. Конечно же, такой индекс упрощает поиск. Когда происходит сканирование по индексу и когда программа видит, что уже пошло слово больше, чем задано в условии поиска, сканирование может прекращаться и не придется просматривать всю базу данных. Например, поищем слово "Абажур". Оно будет где-то в начале, и чтобы его найти, нужно просканировать всего лишь начало таблицы, не дальше, чем все слова на букву А. За счет того, что данные упорядочены, мы можем быть уверенными, что все остальные слова будут на буквы Б, В и т.д.

В случае с серверной базой индексы чаще всего (в зависимости от базы и типа индекса) хранятся немного подругому – в виде дерева. Сколько слов надо проверить для поиска слова "якорь" в базе данных при линейном индексе? По сути, практически все. При древовидном хранении индекса - не более чем для слова "Абажур". Для пояснения древообразного индекса рассмотрим классическую задачу (в реальности все немного сложнее, но идея такая же). В самом верху дерева хранится алфавит. Программа находит букву А и спускается на уровень ниже. Здесь она находит все слова на буквы А, Б и двигается еще ниже. И так - пока не найдется нужное слово

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

ТРЕТИЙ УРОВЕНЬ

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

Я работал в одной фирме (не будем тыкать в нее вилами), у которой было несколько офисов по России, и в каждом из них - парк компьютеров из 20-30 штук. В московском офисе эта цифра превышала сотню. Корпоративные программы обновлялись каждые две недели (вносились изменения, добавления и т.д.). Бедные админы в момент обновлений работали по субботам, чтобы пропатчить софт на каждой машине и убедиться в функциональности. Как решить эту проблему?

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

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

Представим себе классическую задачу – появление новой версии базы данных или переход на базу качественно более нового уровня. Ну не хватает нам уже возможностей MySQL, захотелось заполучить всю мощь Oracle. Для этого переустанавливается сервер баз данных, изменяется сервер приложений на подключение к новой базе - и клиенты готовы к работе. Их обновлять не надо!

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

Виды структур баз

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