Что такое база данных

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

В этой книге база данных определяется как самоописательное собрание интегрированных записей. При этом она является компьютерной технологией, укомплектованной языками типа SQL .

Помни: Запись является представлением некоего физического или умозрительного объекта. Скажем, вы, например, собираетесь сохранять данные о своих клиентах. Каждый из них имеет свою запись. А в каждой записи имеется набор атрибутов, таких как имя, адрес и номер телефона. Имена, адреса и другие значения, соответствующие этим атрибутам, и представляют собой данные.

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

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

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

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

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

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

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

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

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

Домены

Атрибут отношения (т.е. столбец таблицы) может допускать некоторое конечное число значений. Множество всех таких значений и является доменом атрибута.

Скажем, например, что вы являетесь дилером по продаже автомобилей и торгуете новинкой — спортивным Curarri GT 4000 с двухместным закрытым кузовом. Данные об автомобилях, находящихся на складе, вы держите в базе данных, а именно в таблице, которую называете INVENTORY (наличные товары). Один из столбцов этой таблицы вы назвали Color (цвет), и в нем находятся данные о наружном цвете каждого автомобиля. GT 4000 поступают только четырех цветов: огненно-малиновый ( blazing crimson ), насыщенный черный ( midnight black ), снежно-белый ( snowflake white ) и металлический серый ( metallic grey ). Эти четыре цвета и представляют собой домен атрибута Color.

Основы реляционных баз данных

Глава 1. Основы реляционных баз данных

Каждая строка базы данных содержит

Рисунок 1.3. Каждая строка базы данных содержит запись; каждый столбец этой базы содержит один атрибут

Помни: Понятие отношения в модели базы данных — это то же самое, что таблица в базе данных, основанной на определенной модели. Попробуйте повторить это определение быстро десять раз.

Компоненты реляционной базы данных

Гибкость реляционных баз данных объясняется тем, что их данные находятся в таблицах, которые в значительной степени независимы друг от друга. В таблицу данные можно добавлять, удалять их из нее, вносить в них изменения и при этом не затрагивать данные из других таблиц — если только таблица не является родительской по отношению к этим другим таблицам. (Об отношениях родительских и дочерних таблиц рассказывается в главе 5, но там речь пойдет не о конфликте поколений.) В этом разделе будет показано из чего состоят таблицы и как они связаны с другими частями реляционной базы данных.

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

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

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

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

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

Объектная модель бросает вызов реляционной

Реляционная модель имела невероятный успех в большом количестве самых разных прикладных областей. Однако "беспроблемной" ее назвать нельзя. Проблемы сильнее проявились из-за роста популярности объектно-ориентированных языков программирования, таких как C++, Java и С#. Такие языки могут решать более сложные задачи, чем обычные языки программирования. Это достигается благодаря таким возможностям, как расширяемые пользователями системы типов, инкапсуляция, наследование, динамическое связывание методов, сложные и составные объекты и объектная целостность. Мы не собираемся в этой книге объяснять, что означают все эти понятия (хотя позднее затронем некоторые из них). Достаточно сказать, что со многими из этих особенностей классическая реляционная модель не совсем хорошо стыкуется. В результате были разработаны и появились на рынке системы управления базами данных, работающие на основе объектной модели. Впрочем, пока что их доля на рынке относительно невелика.

Объектнореляционная модель

Объектно-реляционная модель

Проектировщики баз данных, как и все остальные люди, постоянно ищут самый лучший из всех возможных миров. Они размышляют: "Не правда ли, было бы прекрасно, чтобы у нас были преимущества систем объектно-ориентированных баз данных и одновременно сохранялась совместимость с реляционной системой, которую мы узнали и полюбили?" Такого рода размышления и привели к созданию гибридной объектно-реляционной модели. Объектно-реляционные СУБД расширяют реляционную модель настолько, чтобы в ней можно было поддерживать объектно-реляционное моделирование данных. Объектно-ориентированные модели были добавлены в международный стандарт SQL для того, чтобы поставщики реляционных СУБД могли перевести свои продукты в объектно-реляционные СУБД, сохраняя при этом совместимость со стандартом. Таким образом, в то время как стандарт SQL -92 описывает чисто реляционную модель баз данных, SQL : 1999 (ранее известный как SQL 3) описывает объектно-реляционную модель. A SQL :2003 описывает даже больше — объектно-ориентированные возможности.

В этой книге описывается международный стандарт SQL , подготовленный ISO / IEC . В основном он соответствует реляционной модели. Кроме того, в ней рассказывается и об объектно-ориентированных расширениях стандарта, которые появились благодаря SQL : 1999, и дополнительных расширениях, включенных в SQL :2 OO 3. Объектно-ориентированные возможности позволяют разработчикам решать с помощью баз данных SQL проблемы, которые не по зубам старой, чисто реляционной парадигме. (Чуть язык не сломал.)

Оцените представление

В моем представлении часто возникает один из моих любимых пейзажей: вид на Йосе-митскую долину весенним вечером на выезде из туннеля Уовона. Золотой свет заливает отвесную поверхность скалы Эль-Капитан, вдали сияет пик Хаф-Доум, а водопад "Фата невесты" (Бридалвейл) создает серебряный каскад сверкающей воды, в то время как стайка легких облаков слегка закрывает небо. У баз данных также имеются виды, пусть даже не такие живописные. Называются они представлениями. Их красота заключена в реальной пользе, которую они приносят при работе с данными.

В таблицах может находиться достаточно много строк и столбцов. Иногда все эти данные могут вас интересовать, а иногда — нет. Вас, возможно, интересуют только некоторые из столбцов, имеющихся в таблице, или только строки, которые удовлетворяют определенному условию. Или могут интересовать некоторые столбцы из одной таблицы и некоторые другие — из другой, связанной с ней таблицы. Чтобы исключить данные, которые вам в данный момент не нужны, можно создать представление. Представление ( view ) — это подмножество базы данных, которое обрабатывается приложением. В представлении могут находиться части одной или множества таблиц.

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

Скажем, вы работаете, например, с базой данных, в которой имеются таблицы CUSTOMER (клиент) и INVOICE (счет-фактура). В первой таблице имеются столбцы CustomerlD (идентификатор клиента), FirstName (имя), LastName (фамилия), Street (улица), City (город), State (штат), Zipcode (почтовый код) и Phone (телефон). А столбцами второй таблицы являются InvoiceNumber (номер счета-фактуры), CustomerlD (идентификатор клиента), Date (дата), TotalSale (всего продано), TotalRemitted (всего переведено денег) и FormOfPayment (форма платежа).

Главный менеджер по продажам хочет видеть на экране только такие реквизиты клиентов, как имя, фамилия и номер телефона. Если из таблицы CUSTOMER создать представление, в котором содержатся лишь три столбца с названной информацией, то менеджер будет просматривать только нужную ему информацию. А данные из тех столбцов, которые его не интересуют, он видеть не будет. На Рисунок 1.4 показано получение представления для главного менеджера по продажам.

Ограничения

Ограничения являются важным, хотя часто и недооцениваемым компонентом базы данных. Ограничения — это правила, определяющие допустимые значения для атрибутов таблицы.

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

Что касается примера с автомобилями, то можно применить к таблице ограничение, при котором в столбец Color (цвет) можно будет вводить только одно из перечисленных значений. Если после этого оператор ввода данных попытается ввести в этот столбец такое значение, как, например, темно-зеленый, система это значение не примет. Ввод данных нельзя будет продолжить до тех пор, пока оператор не введет в поле Color правильное значение.

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

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

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

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 символам), и в этой структуре поля не отделены друг от друга. Тот, кто создал базу данных, для каждого из полей назначил позицию и длину. Любая программа, которая использует этот файл, должна "знать", какие характеристики назначены каждому полю, потому что этой информации в самой базе данных нет.

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

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

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

Почему реляционная модель лучше

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

У реляционных баз данных более гибкая структура. Приложения для таких баз поддерживать легче, чем те, что написаны для иерархических или сетевых баз данных. Эта гибкость структуры дает возможность получать такие комбинации данных, которые, возможно, еще не были нужны при проектировании базы данных.

Представление для главного менеджера

Рисунок 1.4. Представление для главного менеджера по продажам, получаемое из таблицы CUSTOMER

Региональный менеджер по продажам, возможно, хочет видеть имена, фамилии и номера телефонов всех клиентов, с почтовым кодом в диапазоне между 90000 и 93999 (Южная и Центральная Калифорния). Эту работу выполняет представление, которое накладывает ограничение на получаемые с его помощью строки, а также на выводимые с его помощью столбцы. На Рисунок 1.5 показано получение представления для регионального менеджера по продажам.

Менеджеру по оплате счетов, возможно, требуется просматривать имена и фамилии клиентов из таблицы CUSTOMER и значения столбцов Date , TotalSale , TotalRemitted и FormOfPayment из таблицы INVOICE , причем только из таких записей, где значение TotalRemitted меньше значения TotalSale . Это ограничение на записи имеет место тогда, когда оплата еще не проведена полностью. Для такого просмотра требуется создать представление, которое собирает данные из обеих таблиц. На Рисунок 1.6 показаны потоки данных, идущие из обеих таблиц, CUSTOMER и INVOICE , в представление для менеджера по оплате счетов, которое называется ACCTS_PAY.

Работа с данными

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

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

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

Малое — это прекрасно В области хранения данных компьютеры действительно предстали во всей своей красе. Это произошло потому, что они могут хранить в двоичном виде любую информацию: текст, числа, звуки, графические изображения, телевизионные программы или анимацию. Причем компьютер может хранить данные с очень высокой плотностью, позволяя поместить большое количество информации. По мере совершенствования технологий все больше и больше данных занимают все меньше и меньше места. Где только ни используются сейчас компьютеры: и в газовых насосах, и в новых автомобилях, и в ошеломляющем количестве игрушек. Осталось недолго ждать появления компьютеризованных туфель, меняющих упругость своих подошв в зависимости от того, идете ли вы, бежите или прыгаете. А звезды баскетбола, может быть, вскоре смогут использовать обувь с возможностью хранения небольшой базы данных с игровой статистикой...

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

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

Этим четырем критериям и соответствуют базы данных. Если приходится хранить более десятка элементов данных, то, вероятнее всего, появляется желание хранить эти элементы именно в базе данных.

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

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

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

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

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

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

Родственники и таблицы что общего?

Родственники и таблицы - что общего?

В праздничные дни многие родственники приходят ко мне в гости и сидят за моим столом. В базах данных также имеются отношения (но не родственные), и каждое из них имеет свою собственную таблицу (английское слово " table " может иметь два значения: "стол" или "таблица", a " relation " — "родство" или "отношение"). Реляционная база данных состоит из одного или нескольких отношений.

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

Большинство людей знакомы с двумерными массивами строк и столбцов. Это электронные таблицы, с которыми можно работать в таких приложениях, как Microsoft Excel . Другой пример двумерного массива — это статистика на обратной стороне бейсбольной карточки игрока высшей лиги. В такой карточке имеются столбцы, указывающие год, команду, количество игр, ударов битой, попаданий, выигранных очков и т.п. Строки соответствуют годам, на протяжении которых игрок играл в высшей лиге. Эти данные также можно хранить в отношении (таблице), которое имеет ту же простую структуру. На Рисунок 1.2 показана таблица реляционной базы данных, содержащая статистику по одному из игроков высшей лиги. В действительности такая таблица может хранить статистику для всей команды или даже целой лиги.

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

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

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

Схемы

Структура всей базы данных — это ее схема или концептуальное представление. Кроме того, эта структура иногда называется полным логическим представлением базы данных. Схема представляет собой метаданные и в качестве таковых является частью базы данных. Сами метаданные, которые описывают структуру базы данных, хранятся в таблицах, похожих на те таблицы, в которых хранятся обычные данные. Метаданные — тоже данные, и в этом их прелесть.

Схемы домены и ограничения

Схемы, домены и ограничения

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

Соображения по поводу проектирования баз данных

База данных является представлением физической или умозрительной структуры, такой, например, как организация, автосборочное производство или статистика выступлений всех бейсбольных клубов высшей лиги. Точность представления зависит от уровня детализации, достигнутого в проекте базы данных. Сколько усилий прикладывать к этому проекту — это должно зависеть от типа информации, которую вы собираетесь получать из базы данных. Слишком большая детализация — это напрасная трата усилий, времени, да и места на жестких дисках. А слишком малая детализация может свести ценность базы данных на нет. Решайте, какая степень детализации вам нужна сейчас, а какая может потребоваться в будущем, а затем воплотите этот уровень в свой проект (не больше и не меньше). Впрочем, не удивляйтесь, если придется этот уровень корректировать в соответствии с постоянно меняющимися условиям повседневной жизни.

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

Таблица со статистикой игрока

Рисунок 1.2. Таблица со статистикой игрока

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

Каждый столбец в таблице из базы данных представляет один из атрибутов этой таблицы. Это означает, что столбец содержит однородные данные в каждой строке таблицы. Например, в таблице могут находиться имена, адреса и номера телефонов всех клиентов организации. Каждая табличная строка (также называемая записью, или кортежем) содержит данные по одному клиенту. А каждый столбец содержит один атрибут. Это, например, может быть один из следующих атрибутов: номер клиента, его имя, улица, на которой он живет, его город, штат, почтовый код или номер телефона. Столбцы и строки такой таблицы показаны на Рисунок 1.3.

Что такое реляционная база данных

В этой главе...

Организация информации Что такое база данных Что такое СУБД Сравнение моделей баз данных Что такое реляционная база данных С какими трудностями можно столкнуться при проектировании баз данных SQL ( Structured Query Language — язык структурированных запросов) — это стандартный язык, предназначенный для создания баз данных, добавления новых и поддержки имеющихся данных, а также извлечения требуемой информации. В зависимости от используемой теоретической модели, базу данных относят к одному из нескольких типов. Язык SQL был создан для работы с данными из тех баз, которые следуют реляционной модели. Недавно в международный стандартный язык SQL были включены элементы объектной модели, в результате чего появились гибридные структуры, называемые объектно-реляционными базами данных. В этой главе рассказывается о хранении данных. Один из ее разделов посвящен сравнению реляционной и других основных моделей. Кроме того, в ней представлен обзор главных особенностей реляционных баз данных.
Впрочем, перед тем как рассказывать о SQL , нужно дать определение понятию базы данных. Развитие компьютеров изменило способы хранения и обработки информации, а также значение этого термина.

В представлении для регионального

Рисунок 1.5. В представлении для регионального менеджера по продажам имеются только некоторые строки из таблицы CUSTOMER

к которому обращается имеющееся приложение,

Внимание

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