Размер и сложность базы данных

Базы данных бывают любых размеров, начиная от простого набора из нескольких записей до огромных систем с миллионами записей.

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

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

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

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

Система СУБД, работающая на платформах нескольких классов, больших и малых, называется масштабируемой.

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

Много лет назад один умник подсчитал, что если разложить любое человеческое существо на компоненты, такие как атомы углерода, водорода, кислорода и азота (плюс незначительное количество других), то их стоимость будет только 97 центов. Впрочем, это совершеннейшая глупость. Люди не состоят из простых изолированных наборов атомов. Наши атомы комбинируются в энзимы, протеины, гормоны и другие вещества, стоимость которых на фармацевтическом рынке обычно составляет миллионы долларов за унцию.

Точная структура таких комбинаций атомов – вот что составляет их ценность. И, аналогично, структура баз данных позволяет интерпретировать данные, кажущиеся бессмысленными. Закономерности и тенденции, имеющиеся в данных, становятся известными благодаря структуре этих данных. Неструктурированные данные, как и неупорядоченные атомы, имеют малую ценность или совсем ее не имеют.

Рис. 1.1. Схема информационной системы, работающей на основе СУБД

Плоские файлы

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

Скажем, вам нужно сохранить в системе плоских файлов имена и адреса клиентов вашей компании. У этой системы может быть примерно такая структура.

Harold Percival	26262	S. Howards Mill Rd	Westminster	CA92683
Jerry Appel	32323	S. River Lane Rd	Santa Ana	CA92705
Adrian Hansen	232	Glenwood Court	Anaheim	CA92640
John Baker	2222	Lafayette St	Garden Grove	CA92643
Michael Pens	77730	S. New Era Rd	Irvine	CA92715
Bob Michimoto	25252	S. Kelmstey Dr	Stanton	CA92610
Linda Smith	444	S.E. Seventh St	Costa Mesa	CA92635
Robert Funnell	2424	Shen Court	Anaheim	CA92640
Bill Checkal	9595	Curry Dr	Stanton	CA92610
Jed Style	3535	Randall St	Santa Ana	CA92705

Как видите, в файле нет ничего, кроме данных. Каждое поле имеет фиксированную длину (например, длина поля имени всегда равна 15 символам), и в этой структуре поля не отделены друг от друга. Тот, кто создал базу данных, для каждого из полей назначил позицию и длину. Любая программа, которая использует этот файл, должна "знать", какие характеристики назначены каждому полю, потому что этой информации в самой базе данных нет.

Такая структура плоских файлов позволяет работать с ними очень быстро. Однако недостатком является то, что программная логика, которая предназначена для манипуляции данными из файлов, должна быть очень подробной. Приложение должно точно "знать", где и как в файле хранятся данные. Итак, что касается малых систем, то в них плоские файлы работают прекрасно. Но чем больше система плоских файлов, тем труднее с ней работать. Использование базы данных вместо системы плоских файлов позволяет этого избежать. Хотя файлы базы данных имеют больший "фундамент", приложения могут работать на большем количестве аппаратных платформ и операционных систем. Кроме того, базы данных позволяют легче писать прикладные программы, потому что программисту не нужно вникать в детали того, как в файлах физически расположены данные.

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

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

Модели баз данных

Независимо от размеров баз данных все они относятся к одной из трех нижеприведенных моделей.

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

· Иерархическая. Иерархические базы данных получили такое название потому, что имеют простую иерархическую структуру, позволяющую иметь быстрый доступ к данным. Их недостатками являются избыточность данных, т.е. их дублирование, и негибкость структуры, что усложняет модификацию таких баз данных.

· Сетевая. В сетевых базах данных дублирование минимально, но за это приходится платить сложностью структуры.

Первыми базами данных, получившими широкое распространение, были большие базы данных организаций, созданные в соответствии с иерархической или сетевой моделью. Через несколько лет появились системы, созданные в соответствии с реляционной моделью. Язык SQL является по-настоящему современным; он применяется только к реляционной модели и ее производной – объектно-реляционной модели. Так что в этом месте книги остается сказать иерархической и сетевой моделям: "Приятно было познакомиться, а теперь – до свидания".

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

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

Впервые реляционную модель баз данных сформулировал в 1970 году работавший в компании IBM доктор И.Ф. Кодд (E. F. Codd), а примерно десятилетие спустя эта модель начала появляться в готовых продуктах. По иронии судьбы первую реляционную СУБД разработала не IBM. Такая честь выпала на долю маленькой компании-новичка, назвавшей свой продукт Oracle.

Базы данных, созданные на основе предыдущих моделей, были заменены реляционными, потому что не имели тex ценных свойств, которые и отличают реляционные базы от баз других типов. Вероятно, самым важным из этих свойств является то, что в реляционной базе данных можно менять структуру, не внося изменений в приложения. Такого не скажешь о приложениях, созданных на основе старых структур. Предположим, например, что в таблицу базы данных вы добавили один или несколько новых столбцов. В этом случае нет необходимости менять никакое из уже написанных приложений, которые будут продолжать обрабатывать эту таблицу, – только если вы не изменили столбцы, с которыми работают эти приложения.

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