новой модели он положил два раздела математики: теорию множеств и исчисление предикатов первого порядка. В самом деле, само наименование новой модели происходит от термина отношение (relation), заимствованного из теории множеств. (Широко распространено заблуждение, что свое наименование реляционная модель якобы получила из-за того, что таблицы в рамках реляционной базы данных могут быть связаны (related) одна с другой. Теперь, когда вам известна правда, вы будете мирно и спокойно спать по ночам!) К счастью, вам не требуется что-либо знать о теории множеств и логике предикатов первого порядка для проектирования и использования реляционной базы данных. Если используется хорошая методика проектирования базы данных - как представленная в книге Майкла Хернандеса Проектирование баз данных для простых смертных,- то можно разработать надежную и эффективную структуру БДдя сбора и сохранения любых данных. (Но для того, чтобы решать более сложные задачи, требуются базовые познания в теории множеств. Мы приведем необходимый объем информации в главе 7.)

Программное обеспечение длп реляционных баз данных

С момента своего появления реляционная модель является основой программных продуктов для баз данных, известных как системы управления реляционными базами данных (СУРБД - Relational Database Management System, RDBMS). Выпускаемые различными постави;иками, они спустя несколько лет получили признание в различных отраслях и организациях и используются в средах различного типа. В 70-х годах мэйнфреймы (большие универсальные ЭВМ) использовали такие программы, как System R компании IBM и INGRES, разработанную в Калифорнийском университете в Беркли. В 80-е годы СУРБД для мэйнфреймов получили развитие в таких программных продуктах, как Oracle одноименной компании и DB2 компании IBM. Бурное развитие персональных компьютеров в середине 80-х вызвало появление таких программ, как dBase от Ashton Tate, Paradox от Ansa Software и RiBASE от Microrim. Когда в начале 90-х годов стала очевидной потребность в совместном использовании данных персональными компьютерами, родилась клиент-серверная вычислительная модель вместе с идеей централизованно расположенных обш,их данных, которыми было бы легко управлять и обеспечивать их безопасность. Эта концепция дала начало таким продуктам, как Oracle 81 и Microsoft SQL Server 7. Приблизительно с 1996 г. были приложены более согласованные усилия к обеспечению доступности баз данных в Интернете. Постави;ики программного обеспечения

44 У.

серьезно отнеслись к этим усилиям и теперь предлагают продукты с расширенной поддержкой Web , такие как Cold Fusion от Allaire, Sybase Enterprise Application Studio от Sybase и Visual InterDev от Microsoft.

Пнотомия реляционных боз донных

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

Рис. 1.1. Пример таблицы

Записи

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

Таблицы

Таблицы являются основными структурами в базах данных. Каждая таблица описывает отдельный предмет. Логический порядок записей и полей в таблице совершенно не имеет значения. Каждая таблица содержит хотя бы одно поле (называемое первичным ключом), которое однозначно идентифицирует каждую из записей. Например, на рис. 1.1 CustomerlD является первичным ключом таблицы Customers. Фактически, вследствие последних двух характеристик таблицы данные в реляционной базе данных могут суш,ествовать независимо от способа их физического хранения в компьютере. Это очень удобно для пользователей, поскольку от них не требуется знания физического расположения записей для того, чтобы извлекать данные.

Предмет, который представляет данная таблица, может быть либо объектом, либо событием. Когда предмет является объектом, таблица описывает что-то реальное, например человека, место или веш,ь. Независимо от своего типа, каждый объект имеет характеристики, которые могут сохраняться в качестве данных. Эти данные могут затем обрабатываться почти бесконечным числом способов. Летчики, изделия, машины, студенты, здания и оборудование - это все примеры объектов, которые можно представить в виде таблицы. На рис. 1.1 показан один из наиболее обш,их примеров таблиц такого типа.

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

Patient Visit

Рис. 1.2. Таблица, представляющая событие

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

Полп

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

Каждое поле в базе данных, спроектированной надлежащим образом, содержит одно и только одно значение, а имя поля идентифицирует тип хранимого в нем значения. Это само по себе делает ввод данных в поле интуитивным. Если поля имеют такие имена, как FirstName, LastName, City, State и ZipCode, то не нужно гадать, значения какого типа заносятся в каждое поле. Также облегчается процесс сортировки данных по состоянию или поиск кого-либо с фамилией Hernandez.

Записи

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

На рис. 1.1, например, каждая запись представляет уникального клиента в рамках таблицы, а поле CustomerlD идентифицирует указанного клиента в базе данных. В свою очередь, ка>вдая запись включает все поля таблицы, а каждое поле описывает некоторый аспект клиента, представленного этой записью. Записи являются ключевым фактором в понимании отношений мещ1у таблицами, поскольку необходимо знать, как запись в одной таблице связана с записями в другой таблице.