Отношения между прикладными программами и субд

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

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

Рис. 1.7. Отношения между пользователями, приложениями базы данных, СУБД и базой данных

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

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

Системы обработки файлов ^;

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

В первых деловых информационных системах группы записей хранились в от­дельных файлах; такие системы назывались системами обработки файлов (file-processing systems). На рис. 1.8 приведены в качестве примера две системы об­работки файлов, которые можно было бы использовать в бюро проката Treble Clef Music. Одна система обрабатывает данные клиентов, а другая — информа­цию о прокате.

Хотя системы обработки файлов являются огромным усовершенствованием по сравнению с ведением записей вручную, у них есть значительные ограничения:

+ данные разделены и изолированы;

4- значительная часть данных дублируется;

+ прикладные программы зависят от форматов файлов;

+ зачастую файлы несовместимы друг с другом;

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

Рис. 1.8. Две системы обработки файлов

Разделенные и изолированные данные

Служащие бюро Treble Clef Music должны ассоциировать клиентов с инструмен­тами, которые те берут в аренду. Для системы, изображенной на рис. 1.8, нужно каким-то образом извлечь данные из файлов клиентов и проката и скомбиниро­вать их в третий файл. В системах обработки файлов это вызовет сложности. Во-первых, системные аналитики и программисты должны определить, какие части каждого из файлов для этого требуются, а затем решить, как файлы долж­ны относиться друг к другу; наконец, они должны скоординировать обработку файлов таким образом, чтобы извлечение данных происходило корректно. Даже для двух файлов эта задача довольно сложна, а вообразите себе, что необходимо скоординировать 10 или более файлов!

Дублирование данных

В примере с бюро проката Treble Clef Music часто возникает ситуация, когда имя клиента, его адрес и другие данные записываются несколько раз. А именно, эти данные записываются один раз в файл клиентов, а затем каждый раз, когда с дан­ным клиентом заключается договор аренды, — в файл проката. То, что при этом впустую тратится дисковое пространство, — еще не самая большая проблема: главная проблема, возникающая при дублировании данных, касается целостно­сти данных (data integrity).

Совокупность данных обладает целостностью, если данные в ней логически согласованы. Когда данные дублируются, это зачастую нарушает их целостность. Например, если клиент сменит фамилию или адрес, то все файлы, содержащие эти данные, необходимо будет обновить, но существует опасность, что об­новлены будут не все файлы, и между ними появятся несоответствия. В случае Treble Clef Music может оказаться, что в разных записях в файле проката кли­ент имеет разные адреса.

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

Зависимость прикладных программ от форматов файлов

При обработке файлов прикладные программы зависят от форматов файлов. Обыч­но в системах обработки файлов физические форматы файлов и записей являют­ся частью кода приложения. В языке COBOL, например, форматы файлов запи­сываются в разделе DATA DIVISION. Проблема заключается в том, что при внесении изменений в форматы файлов приходится также менять и прикладные программы. Например, если в записи о клиенте поле почтового индекса будет расширено с пяти цифр до девяти, все программы, работающие с этой записью, необходимо будет модифицировать, даже если они не используют это поле. Поскольку файл клиентов может обрабатываться двадцатью программами, такое изменение озна­чает, что программист должен обнаружить все затронутые программы, внести в них изменения и затем заново протестировать их; все это требует значитель­ных временных затрат и является дополнительным источником ошибок. Кроме того, требовать от программистов модификации программ, не использующих то поле, формат которого изменился, — значит просто бросать деньги на ветер.

Несовместимость файлов

Одним из следствий зависимости прикладных программ от форматов файлов яв­ляется то, что сами форматы файлов зависят от языка или средства, используемого для их генерации. Так, формат файла, созданного программой на языке COBOL, отличается от формата файла, созданного программой на Visual Basic, который, в свою очередь, отличается от формата файла, созданного программой на C-t-+.

В результате, оперативно комбинировать или сравнивать файлы оказывается невозможно. Пусть, например, в файле под названием FILE-A хранятся данные о клиенте, содержащие поле Номер_Клиента, а в файле под названием FILE-B хра­нятся данные об аренде, также содержащие поле Номер_Клиента. Пусть нам тре­буется скомбинировать записи, у которых значение этого поля одинаково. Если FILE-A обрабатывается программой на Visual Basic, a FILE-B обрабатывается про­граммой на C++, то прежде чем мы сможем комбинировать записи из них, нам придется преобразовать оба файла к некоторому общему формату. Это требует времени, а иногда вызывает затруднения. С увеличением количества комбини­руемых файлов растет и число таких проблем.

Трудность представления данных в удобном для пользователя виде

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