Реляционные базы данных и «цифровой бульон»
Программы, задействующие технологии баз данных, обычно предъяв' ляют к пользователям два простых требования: Во'первых, пользова' тель должен заранее задать формат данных, а во'вторых, он должен впоследствии следовать заданному формату. Относительно пользовате' лей программного продукта также справедливы два утверждения: во' первых, они редко способны заранее сформулировать, чего хотят, а во' вторых, даже если и способны, то, скорее всего, потом передумают.
Как организовать неорганизуемое
В век Интернета мы все чаще сталкиваемся с информационными сис' темами, которые не проходят тест на соответствие реляционным кри' териям. Мы не только не можем определить информацию заранее, но даже не можем последовательно придерживаться какого'то мыслимо' го определения. Эту дилемму хорошо иллюстрируют, в частности, два явления, переживающие период бурного роста.
Первое из них – электронная почта. В то время как запись в базе дан' ных имеет изначально заданное содержательное сходство с другими подобными ей записями и поэтому хранится в одной таблице с ними, сообщения электронной почты не вписываются в эту парадигму. Мы можем разделить почтовые сообщения на входящие и исходящие, но в этом мало проку. Предположим, вы получили письмо от Джерри на' счет Салли и по поводу проекта «Аякс», который имеет отношения к фирме «Джонс Консалтинг» и к вашей совместной презентации на ближайшем совещании. Вы можете сохранить это письмо в папке
«Джерри», или «Салли», или «Аякс» – но по'хорошему вы хотели бы сохранить его во всех трех папках. Через шесть месяцев у вас может появиться необходимость просмотреть это письмо по одной из множе' ства непредсказуемых причин – и у вас должна быть возможность най' ти его независимо от причины.
Второе явление – это Всемирная паутина. Подобно бесконечному, не' организованному, избыточному, бесхозному жесткому диску она со' противляется любым попыткам структуризации. В Интернете доступ' ны громадные объемы информации, но его размеры и явная неодно' родность практически гарантируют, что сеть не поддастся какой'либо систематизации. Даже если бы Всемирную паутину можно было бы организовать, метод организации должен был бы находиться вовне, поскольку ее содержимое принадлежит миллионам личностей, ни од' на из которых не признает власть над собой. В отличие от записей в ба' зе данных, нельзя ожидать от документов в Интернете, что они будут содержать предсказуемые идентификационные пометки.
Сложности с базами данных
С базами данных связана еще одна проблема. Каждая запись в базе дан' ных имеет один заранее определенный тип, а все однотипные записи сгруппированы. Запись в базе данных может быть представлением сче' та на оплату или клиента, но она никогда не является представлением счета на оплату и клиента одновременно. Аналогичным образом, поле записи может содержать имя клиента или номер его медицинской стра' ховки, но оно никогда не содержит и имя, и номер страховки. Это фун' даментальная концепция, лежащая в основе всех баз данных. Она слу' жит жизненно важной цели – позволяет упорядочить систему хране' ния. К сожалению, она неспособна решить реальную проблему извлече' ния в примере с электронной почтой, приведенном выше. Недостаточно определить тип записи «электронное сообщение» для письма от Джер' ри. Мы должны каким'то образом назначить ему еще типы «Джерри»,
«Салли», «Аякс», «Джонс Консалтинг» и «Совещание». Мы должны иметь возможность добавить новый или изменить существующий тип даже после того, как письмо будет сохранено. Более того, тип «Аякс» может относиться к документам, не являющимся сообщениями элек' тронной почты, например к планам проекта. Поскольку формат записи непредсказуем, значение, которое идентифицирует запись как относя' щуюся к проекту «Аякс», не может храниться вместе с самой записью. Это положение прямо противоречит принципам работы баз данных.
Базы данных способны предоставить более гибкие инструменты поис' ка и выборки записей, нежели поиск по простым типам данных. Они позволяют найти запись по ее содержимому, применяя заданные кри' терии поиска. Например, мы можем найти счет номер 77329 или кли' ента с идентифицирующей строкой «Goodyear Tire and Rubber». Тем не менее эти инструменты не помогают решить проблему идентифика' ции электронного сообщения. Если мы разрешим пользователю поме' щать в запись ключевые слова «Джерри», «Салли», «Аякс», «Джонс Консалтинг» и «Совещание», мы должны будем заранее задать эти по' ля. Однако, как мы говорили, предварительное определение чего бы то ни было не гарантирует, что пользователь будет впоследствии придер' живаться этого определения. Например, он может заняться поиском писем, относящихся к корпоративному пикнику. Добавление полей с ключевыми словами приведет нас к одной из фундаментальных зага' док обработки данных: если вы предоставите пользователям десять по' лей, то кому'нибудь обязательно понадобится одиннадцатое.