Теория СУБД. Научный подход к базам данных - файл n1.doc

Теория СУБД. Научный подход к базам данных
Скачать все файлы (84.3 kb.)

Доступные файлы (1):
n1.doc311kb.13.10.2009 07:38скачать

n1.doc

  1   2   3   4   5
Докучаев Дмитрий



Теория СУБД. Научный подход к базам данных.

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

ЧТО ТАКОЕ СУБД И С ЧЕМ ЕЕ ЕДЯТ

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

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

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

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

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

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

ЗА ТАБЛИЦАМИ – НАШЕ БУДУЩЕЕ!

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

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

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

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

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

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

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

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

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

СВЯЗЫВАЕМ ДАННЫЕ

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

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

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

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

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

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

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

ОБЪЕКТНЫЙ РАЙ

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

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

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

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

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

DO YOU SPEAK ENGLISH?

Для каждой модели БД существу ет свой язык управления. Для реля­ционной модели таким языком явля­ется 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).

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

  1   2   3   4   5
Учебный текст
© perviydoc.ru
При копировании укажите ссылку.
обратиться к администрации