Основы реляционных баз данных
Ограничения
Ограничения являются важным, хотя часто и недооцениваемым компонентом базы данных. Ограничения – это правила, определяющие допустимые значения для атрибутов таблицы.
Предотвратить ввод в столбец неправильных данных можно, применяя к этому столбцу жесткие ограничения. Конечно, любое значение, правильно входящее в домен столбца, должно удовлетворять всем ограничениям, которые имеются для этого столбца. Как уже говорилось в предыдущем разделе, доменом столбца является множество всех тех значений, которые могут быть в этом столбце. Ограничение – это именно ограничение на то, что может находиться в столбце. Характеристики табличного столбца и применяемые к нему ограничения определяют домен этого столбца. Применяя ограничения, можно предотвратить ввод в столбец таких данных, которые не входят в его домен.
Что касается примера с автомобилями, то можно применить к таблице ограничение, при котором в столбец Color (цвет) можно будет вводить только одно из перечисленных значений. Если после этого оператор ввода данных попытается ввести в этот столбец такое значение, как, например, темно-зеленый, система это значение не примет. Ввод данных нельзя будет продолжить до тех пор, пока оператор не введет в поле Color правильное значение.
Объектная модель бросает вызов реляционной
Реляционная модель имела невероятный успех в большом количестве самых разных прикладных областей. Однако "беспроблемной" ее назвать нельзя. Проблемы сильнее проявились из-за роста популярности объектно-ориентированных языков программирования, таких как C++, Java и С#. Такие языки могут решать более сложные задачи, чем обычные языки программирования. Это достигается благодаря таким возможностям, как расширяемые пользователями системы типов, инкапсуляция, наследование, динамическое связывание методов, сложные и составные объекты и объектная целостность. Мы не собираемся в этой книге объяснять, что означают все эти понятия (хотя позднее затронем некоторые из них). Достаточно сказать, что со многими из этих особенностей классическая реляционная модель не совсем хорошо стыкуется. В результате были разработаны и появились на рынке системы управления базами данных, работающие на основе объектной модели. Впрочем, пока что их доля на рынке относительно невелика.
Объектно-реляционная модель
Проектировщики баз данных, как и все остальные люди, постоянно ищут самый лучший из всех возможных миров. Они размышляют: "Не правда ли, было бы прекрасно, чтобы у нас были преимущества систем объектно-ориентированных баз данных и одновременно сохранялась совместимость с реляционной системой, которую мы узнали и полюбили?" Такого рода размышления и привели к созданию гибридной объектно-реляционной модели. Объектно-реляционные СУБД расширяют реляционную модель настолько, чтобы в ней можно было поддерживать объектно-реляционное моделирование данных. Объектно-ориентированные модели были добавлены в международный стандарт SQL для того, чтобы поставщики реляционных СУБД могли перевести свои продукты в объектно-реляционные СУБД, сохраняя при этом совместимость со стандартом. Таким образом, в то время как стандарт SQL – 92 описывает чисто реляционную модель баз данных, SQL: 1999 (ранее известный как SQL 3) описывает объектно-реляционную модель. A SQL:2003 описывает даже больше – объектно-ориентированные возможности.
В этой книге описывается международный стандарт SQL, подготовленный ISO / IEC. В основном он соответствует реляционной модели. Кроме того, в ней рассказывается и об объектно-ориентированных расширениях стандарта, которые появились благодаря SQL: 1999, и дополнительных расширениях, включенных в SQL:2003. Объектно-ориентированные возможности позволяют разработчикам решать с помощью баз данных SQL проблемы, которые не по зубам старой, чисто реляционной парадигме. (Чуть язык не сломал.)
Соображения по поводу проектирования баз данных
База данных является представлением физической или умозрительной структуры, такой, например, как организация, автосборочное производство или статистика выступлений всех бейсбольных клубов высшей лиги. Точность представления зависит от уровня детализации, достигнутого в проекте базы данных. Сколько усилий прикладывать к этому проекту – это должно зависеть от типа информации, которую вы собираетесь получать из базы данных. Слишком большая детализация – это напрасная трата усилий, времени, да и места на жестких дисках. А слишком малая детализация может свести ценность базы данных на нет. Решайте, какая степень детализации вам нужна сейчас, а какая может потребоваться в будущем, а затем воплотите этот уровень в свой проект (не больше и не меньше). Впрочем, не удивляйтесь, если придется этот уровень корректировать в соответствии с постоянно меняющимися условиям повседневной жизни.
Сегодняшние системы управления базами данных, снабженные привлекательными графическими пользовательскими интерфейсами и интуитивными инструментами проектирования, могут навеять претенденту на звание проектировщика ложное чувство безопасности. Такие системы приводят к тому, что проектирование базы данных кажется сравнимым с созданием электронной таблицы или с выполнением другой, относительно простой задачи. Но это не тот случай. Проектировать базу данных трудно. Если будете неправильно проектировать, то получите базу, которая со временем станет только хуже. Часто проблема не проявляется до тех пор пока вы не потратите немалые усилия на ввод данных. И к тому времени, когда проблема себя проявит, она станет достаточно серьезной. Во многих случаях решение состоит в том, чтобы полностью перепроектировать базу и заново ввести все данные. Единственным утешением при этом будет приобретаемый опыт работы с базами данных.