Реляционная модель

В 1970 г. Э. Ф. Кодд (Е. F. Codd) опубликовал свою эпохальную статью (Е. Е. Codd, «A Relational Model of Data for Large Shared Databanks», Communications of the ACM 06.1970, c. 377-387.), в кото­рой он применил концепции раздела математики, называемого реляционной ал­геброй, к проблеме хранения больших объемов данных. Статья Кодда положила начало движению в сфере проектирования баз данных, которое привело несколь­ко лет спустя к созданию реляционной модели базы данных (relational database model). Эта модель представляет собой определенный способ структурирования и обработки базы данных, и мы будем подробно обсуждать ее в главе 5, а также в главах 9-14.

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

Согласно реляционной модели, не все виды таблиц одинаково приемлемы. С помощью процесса, называемого нормализацией (normalization), нежелатель­ная таблица может быть преобразована в две или более приемлемых. Более под­робно о процессе нормализации вы узнаете из главы 5.

Другое преимущество реляционной модели состоит в том, что в столбцах содержатся данные, связывающие одну строку с другой. Например, на рис. 1.1 столбец CUSTOMER_ID в таблице JOB связан со столбцом CUSTOMER_ID в таблице CUSTOMER. Это делает связи между строками видимыми для пользователя.

Поначалу считалось, что реляционная модель позволит пользователям извле­кать информацию из баз данных без помощи профессионалов MIS (администра­тивно-информационной системы). Доля истины в этом есть, так как таблицы представляют собой простые и интуитивно понятные конструкции. Кроме того, поскольку связи хранятся вместе с данными, пользователи могут при необходи­мости комбинировать нужные строки. Например, чтобы получить запись о кон­кретном договоре аренды, пользователь базы данных бюро проката Treble Clef Music мог бы скомбинировать строку таблицы CUSTOMER со строками таблицы RENTAL

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

Коммерческие субд для микрокомпьютеров

В 1979 г. небольшая компания под названием Ashton-Tate представила новый программный продукт для микрокомпьютеров, dBase II, и назвала его реляцион­ной СУБД. Применяя чрезвычайно успешную рыночную тактику, Ashton-Tate почти бесплатно распространила более 100 000 копий своего продукта среди по­купателей новых в то время микрокомпьютеров Osborne. Многие из тех, кто при­обрел эти компьютеры, были пионерами микрокомпьютерной индустрии. Они начали создавать приложения для микрокомпьютеров с использованием dBase, и число dBase-приложений быстро росло. В результате Ashton-Tate стала одной из первых крупных корпораций в индустрии микрокомпьютеров. Позднее она была приобретена компанией Borland, которая в настоящее время продает про­дукты линии dBase.

Успех этого продукта, однако, вызвал неразбериху и путаницу в мире баз дан­ных. Проблема была в следующем: в соответствии с определением, которое стало преобладать в конце 70-х годов, продукт под названием dBase II вообще не яв­лялся СУБД, а тем более реляционной. Фактически это был язык программиро-

вания с расширенными возможностями для обработки файлов. Системы, разрабо­танные на базе dBase II, гораздо более напоминали то, что изображено на рис. 1.8, чем то, что на рис. 1.7. Около миллиона пользователей dBase II были уверены, что используют реляционную СУБД, хотя в действительности это было не так.

Таким образом, термины система управления базами данных (database manag­ement system) т реляционная база данных (relational database) в начале бума мик­рокомпьютеров использовались достаточно произвольно. Большинство тех, кто работал с базами данных на микрокомпьютерах, на самом деле занимались обра­боткой файлов и не получали тех преимуществ, которые характерны для баз дан­ных (хотя они и не замечали этого). Сегодня, когда рынок микрокомпьютеров стал более зрелым и искушенным, ситуация стала иной. dBase IV и последую­щие продукты линии dBase, такие как FoxPro, являются по-настоящему реляци­онными СУБД.

Хотя продукты dBase действительно были первым ориентированным на мик­рокомпьютеры приложением технологии баз данных, примерно в это же время другие производители начали переносить свои продукты с больших ЭВМ на микрокомпьютеры. В качестве примеров коммерческих СУБД, перенесенных на микрокомпьютеры, можно упомянуть Oracle, Focus и Ingress. Они действитель­но являются СУБД, и многие также согласятся с тем, что они действительно ре­ляционные.

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

Сочетание микрокомпьютеров, реляционной модели и значительно улучшен­ного пользовательского интерфейса позволило перенести технологию баз дан­ных из контекста организации в контекст персональных компьютеров. Когда это произошло, число мест, где используется технология баз данных, увеличилось на порядки. В 1980 г. в США было около 10 000 мест, где использовались СУБД, сегодня же их более 40 миллионов!