При разработке баз данных вам может понадобиться установить ограничения на то, какие данные могут храниться в том или ином столбце. Например, если бы у нас была таблица, в которой хранится информация о небоскребах, мы бы запретили отрицательные значения в столбце, содержащем высоту зданий.
Реляционные системы управления базами данных (РСУБД) позволяют контролировать данные, помещаемые в таблицу. Этот контроль выполняется при помощи ограничений. В контексте РСУБД ограничение – это специальное правило, которое применяется к одному или нескольким столбцам (иногда и ко всей таблице) и определяет, какие изменения могут быть внесены в данные с помощью операторов INSERT, UPDATE или DELETE.
В этой статье мы подробно рассмотрим, что такое ограничения и как они используются в СУБД. Также мы отдельно остановимся на каждом из пяти ограничений, определенных в стандарте SQL, и объясним их функции.
Что такое ограничения SQL?
В SQL ограничение – это любое правило, применяемое к столбцу или таблице, которое определяет, какие данные можно в него вносить, а какие – нет. Каждый раз, когда вы пытаетесь выполнить операцию, изменяющую данные в таблице, – такую как INSERT, UPDATE или DELETE, – СУБД проверяет, не нарушают ли эти данные какие-либо существующие ограничения. Если ограничения запрещают выполнять такую операцию, она возвращает ошибку.
Администраторы баз данных часто применяют ограничения, чтобы БД следовала набору определенных бизнес-правил. В контексте СУБД бизнес-правило – это любая политика или процедура, которой придерживается бизнес или организация и которым должны соответствовать их данные.
Предположим, что вы создаете базу данных, которая будет каталогизировать инвентарь магазина клиента. Если клиент указывает, что каждая запись продукта должна иметь уникальный идентификационный номер, вы можете создать столбец с ограничением UNIQUE, которое гарантирует, что в одном столбце не может быть двух одинаковых записей.
Кроме того, ограничения также помогают поддерживать целостность данных. Целостность данных – это широкий термин, который обычно используется для описания точности, согласованности и рациональности данных БД в зависимости от конкретного случая использования. Таблицы в БД часто тесно связаны, при этом столбцы в одной таблице зависят от значений в другой. При вводе данных часто есть риск человеческой ошибки, и здесь на помощь приходят ограничения: благодаря им неправильно введенные данные не смогут повлиять на отношения внутри БД и, следовательно, не смогут повредить целостность данных.
Представьте, что вы создаете базу данных с двумя таблицами: одна для перечисления текущих учеников школы, а другая – для перечисления членов баскетбольной команды этой школы. В таком случае вам бы пригодилось ограничение FOREIGN KEY. Если применить его к столбцу в таблице баскетбольной команды, который ссылается на столбец в общей школьной таблице, вы установите между двумя таблицами связь: любая запись в таблице баскетбольной команды должна обязательно ссылаться на существующую запись в общей таблице учеников.
Ограничения определяются при создании таблицы или могут быть добавлены позже с помощью оператора ALTER TABLE (при этом ограничения не должны конфликтовать с данными, уже находящимися в таблице). Создавая ограничение, СУБД автоматически генерирует его имя, но в большинстве реализаций SQL вы можете самостоятельно выбрать имя для любого ограничения. Эти имена используются для обозначения ограничений в операторах ALTER TABLE при их изменении или удалении.
Стандарт SQL формально определяет всего пять ограничений:
- PRIMARY KEY
- FOREIGN KEY
- UNIQUE
- CHECK
- NOT NULL
Примечание: Многие СУБД также поддерживают ключевое слово DEFAULT, которое используется для определения ненулевого стандартного значения для столбца на случай, если значение не указано при вставке строки. В документации некоторых из этих СУБД ключ DEFAULT упоминается как ограничение, поскольку их реализации SQL используют синтаксис DEFAULT по аналогии с синтаксисом таких ограничений, как UNIQUE или CHECK. Однако технически DEFAULT не является ограничением, поскольку не ограничивает, какие данные могут быть введены в столбец.
Теперь, когда у вас есть общее представление о том, как используются ограничения, давайте подробнее рассмотрим каждое из этих пяти базовых ограничений.
Ограничение PRIMARY KEY
Ограничение PRIMARY KEY требует, чтобы каждая запись в данном столбце была уникальной и не равнялась NULL. Оно позволяет использовать столбец, в котором оно применяется, для идентификации каждой отдельной строки в таблице.
В контексте реляционной модели ключ – это столбец или набор столбцов в таблице, в которой каждое значение гарантированно уникально и не содержит значений NULL. Первичный ключ (primary key) – это специальный ключ, значения которого используются для идентификации отдельных строк в таблице; столбец или столбцы, представляющие собой первичный ключ, могут использоваться для идентификации во всех остальных таблицах БД.
Это важный аспект реляционных баз данных: имея первичный ключ, пользователь может не беспокоиться о том, где данные хранятся физически, а СУБД может отслеживать каждую запись и возвращать их на разовой основе. В свою очередь, это значит, что записи не имеют определенного логического порядка, и пользователи имеют возможность возвращать свои данные в любом порядке или через любые фильтры.
Вы можете создать первичный ключ в SQL с помощью ограничения PRIMARY KEY, которое по сути представляет собой комбинацию ограничений UNIQUE и NOT NULL. После определения первичного ключа СУБД автоматически создаст связанный с ним индекс. Индекс – это структура БД, которая помогает быстрее извлекать данные из таблицы (она работает подобно указателю в учебнике). Запросы просматривают только записи из проиндексированного столбца, чтобы найти связанные значения. Таким образом, первичный ключ действует как идентификатор для каждой строки в таблице.
Таблица может иметь только один первичный ключ, но, как и обычные ключи, первичный ключ может состоять из нескольких столбцов. С учетом сказанного, определяющей особенностью первичных ключей является то, что они используют минимальный набор атрибутов, необходимых для уникальной идентификации каждой строки в таблице. Чтобы проиллюстрировать эту идею, представим себе таблицу, в которой хранится информация об учениках. Предположим, таблица содержит следующие три столбца:
- studentID: используется для хранения уникального идентификационного номера каждого учащегося.
- firstName: хранит имя каждого учащегося.
- lastName: содержит фамилию каждого ученика.
Велика вероятность, что среди учеников одно и то же имя будет встречаться множество раз, что делает столбец firstName плохим кандидатом на роль первичного ключа. То же верно и для столбца lastName. Первичный ключ, состоящий из комбинации столбцов firstName и lastName, может сработать, но все же существует вероятность, что в одной школе появятся ученики, у которых совпадет и имя, и фамилия.
Первичный ключ, состоящий из всех трех столбцов, тоже может существовать, но такой вариант будет избыточным: сам по себе идентификационный номер каждого ученика уже уникален, а значит, имя или фамилия тут будут лишними. Лучше всего выбрать минимальный набор атрибутов, который может идентифицировать каждую строку, это и будет первичным ключом таблицы, – в нашем примере вполне достаточно данных из столбца studentID.
Если ключ состоит из данных, которые представляют сущности, события или атрибуты реального мира, он называется естественным ключом (или natural key). Ключ, который создается внутри базы данных и не представляет ничего за ее пределами, называется суррогатным или синтетическим ключом (surrogate key). Некоторые СУБД не рекомендуют использовать естественные ключи, поскольку даже кажущиеся постоянными точки данных могут изменяться непредсказуемым образом.
Ограничение FOREIGN KEY
Ограничение FOREIGN KEY требует, чтобы каждая запись в данном столбце уже существовала в определенном столбце из другой таблицы.
Если у вас есть две таблицы, которые вы хотите связать друг с другом, то определить внешний ключ FOREIGN KEY – один из способов сделать это. Внешний ключ – это столбец в одной (дочерней) таблице, значения которого берутся из столбца в другой (родительской) таблице. Это способ выразить связь между двумя таблицами: ограничение FOREIGN KEY требует, чтобы значения в столбце, к которому оно применяется, уже существовали в столбце, на который оно ссылается.
Если вы попытаетесь добавить запись в дочернюю таблицу, а значение, введенное в столбец внешнего ключа, не существует в родительской таблице, операция вставки выдаст ошибку. Так это ограничение помогает поддерживать целостность на уровне отношений, поскольку строки в обеих таблицах всегда будут связаны правильно.
Часто внешний ключ дочерней таблицы является первичным ключом родительской таблицы, но это не всегда так. В большинстве СУБД внешний ключ дочерней таблицы может ссылаться на любой столбец родительской таблицы, к которому применено ограничение UNIQUE или PRIMARY KEY.
Ограничение UNIQUE
Ограничение UNIQUE запрещает добавлять в заданный столбец любые повторяющиеся значения.
Как следует из названия, ограничение UNIQUE требует, чтобы каждая запись в данном столбце была уникальной. Любая попытка добавить значение, которое уже существует в этом столбце, приведет к ошибке.
Ограничения UNIQUE обеспечивают между таблицами отношения «один к одному». Как упоминалось выше, вы можете установить связь между двумя таблицами с помощью внешнего ключа, но между таблицами может существовать несколько видов отношений:
- «один к одному»: отношения, при которых строки в родительской таблице связаны с одной и только одной строкой в дочерней таблице.
- «один ко многим»: строка в родительской таблице может относиться к нескольким строкам в дочерней таблице, но каждая строка в дочерней таблице может относиться только к одной строке в родительской.
- «многие ко многим»: строки в родительской таблице могут относиться к нескольким строкам в дочерней таблице и наоборот.
Добавляя ограничение UNIQUE к столбцу, к которому было применено ограничение FOREIGN KEY, вы можете установить между таблицами связь «один к одному»:, каждая запись в родительской таблице появляется в дочерней таблице только один раз.
Обратите внимание, определить ограничение UNIQUE можно как на уровне таблицы, так и на уровне столбца. При определении на уровне таблицы UNIQUE может применяться более чем к одному столбцу. В подобных случаях каждый столбец, на который распространяется ограничение, может содержать повторяющиеся значения, но каждая строка должна иметь уникальную комбинацию значений в соответствующих столбцах.
Ограничение CHECK
CHECK определяет для столбца предикат, которому должно соответствовать каждое введенное в него значение.
Предикаты CHECK записываются в форме выражения, которое может иметь значение TRUE, FALSE или потенциально UNKNOWN. Если вы попытаетесь ввести в столбец с ограничением CHECK какое-то значение и предикат оценит его как TRUE или UNKNOWN (для значений NULL), операция завершится успешно. Однако, если выражение получит оценку FALSE, оно выдаст ошибку.
Часто для ограничения диапазона данных, разрешенных в данном столбце, предикаты CHECK полагаются на математический оператор сравнения (например, < или >, =). Например, CHECK часто используется для того, чтобы запретить отрицательные значения в некоторых столбцах (это полезно в тех случаях, когда отрицательное значение не имеет смысла, как вы увидите в следующем примере).
Следующий оператор CREATE TABLE создает таблицу productInfo со столбцами для наименования каждого продукта, его идентификационного номера и цены. Цена не может быть выражена отрицательным числом, потому этот оператор накладывает ограничение CHECK на столбец price, чтобы он содержал только положительные значения:
CREATE TABLE productInfo ( productID int, name varchar(30), price decimal(4,2) CHECK (price > 0) );
Не каждый предикат CHECK должен использовать математический оператор сравнения. Как правило, вы можете использовать любой оператор SQL, который может оцениваться как TRUE, FALSE или UNKNOWN, в том числе LIKE, BETWEEN, IS NOT NULL и другие. Некоторые реализации SQL (но не все!) даже позволяют включать подзапрос в предикат CHECK. Однако имейте в виду, что большинство реализаций все же не позволяют ссылаться на другую таблицу в предикате.
Ограничение NOT NULL
NOT NULL запрещает добавлять в данный столбец значения NULL.
В большинстве реализаций SQL СУБД по умолчанию представляет отсутствующие данные как NULL, если вы добавляете строку данных, но не указываете значение для определенного столбца. NULL в SQL – это специальное ключевое слово, используемое для представления неизвестного, отсутствующего или иного неуказанного значения. Однако NULL – это не само значение, а состояние неизвестного значения.
Попробуем проиллюстрировать эту разницу. Представьте себе таблицу для отслеживания клиентов в кадровом агентстве, в которой есть столбцы для имени и фамилии каждого клиента. Если клиент использует мононим, – как, например, Cher или Beyoncé, – администратор базы данных может ввести его только в столбец для имени, в результате чего СУБД введет NULL в столбец фамилии. Конечно, база данных не считает, что фамилия клиента буквально равна нулю. Это просто означает, что значение данного столбца в этой строке неизвестно или это поле не применяется для этой конкретной записи.
Из названия видно, что ограничение NOT NULL не позволяет хранить значения NULL в данном столбце. Значит, при вставке новой строки вы должны указать какое-то значение для столбца с ограничением NOT NULL. В противном случае операция INSERT завершится ошибкой.
Заключение
Ограничения – важный механизм, который позволяет создать базу с высоким уровнем целостности и безопасности данных. Ограничивая данные, которые можно хранить в том или ином столбце, вы можете быть уверены, что сохраните отношения между таблицами и что база данных будет придерживаться бизнес-правил, определяющих ее назначение.
Источник: www.8host.com
Бизнес-правила
Бизнес-правила представляют собой специализированный вид логики, описывающей ограничения на образ действий, которые система или люди должны учитывать в своем поведении. Эти правила определяются целым рядом факторов, включая директивы распорядительных органов, промышленные стандарты, деловую хватку и простой здравый смысл. Нередко они изменяются от страны к стране, от отрасли к отрасли, и даже от бизнеса к бизнесу. В качестве примера бизнес-правила в банковском деле можно привести закон, по которому о любой сделке, превышающей сумму 10 000 долларов наличными, государство должно ставится в известность. Несомненно, данное бизнес-правило необходимо принимать во внимание при создании банковской системы вложения/снятия наличных денег.
Бизнес-правила существуют на разных уровнях. Некоторые из них оказывают влияние на всю систему, и многие системы, на самом деле, целиком создаются лишь для того, чтобы ввести в действие бизнес-правила. Бизнес-правила также могут значительно различаться по размерам области влияния.
Но, не смотря на это, все бизнес-правила имеют одно общее свойство: они управляют некоторой составляющей бизнеса. По определению, бизнес-правило есть ограничение, применяемое по отношению к человеку, бизнесу, составляющей бизнеса или действию. Далее речь пойдет о некоторых подробностях, характерных для унифицированных языков моделирования.
Большинство бизнес-правил представляет собой простую проверку достоверности, например, обеспечение соответствия почтовых индексов с индексами, имеющимися у штатов США.
В общем случае существует три типа правил. К первому типу принадлежат правила вывода.
Правило вывода (derivation rule) преобразует полученную информацию в возвращаемые значения. Например, скидки на товары можно вычислить с помощью специального алгоритма, учитывающего размер заказа, рекламную поддержку и значимость клиента, которому будут поставляться товары. Правила этого типа допускают изменения, и поэтому, прежде чем с ними можно было работать, их требуется выделить.
Правило ограничения (constraint rule) проверяет значения транзакции или операции на непротиворечивость. Например, чтобы заказчик получил письмо, почтовый индекс на письме должен соответствовать индексу штата, в котором проживает заказчик. Эти правила могут использоваться для изучения взаимосвязей между объектами, например, когда все клиенты имеют адресующие объекты в интернет-магазине видеоаппаратуры. Кроме того, они могут применяться вместе с Булевыми результатами. Если они не истинны, то мы не сможем продолжить или завершить операцию.
Наконец, существуют инвариантные правила. Инвариантные правила (invariant rules) проверяют множественные изменения и обеспечивают непротиворечивость итоговых результатов. Например, баланс сберегательного счета должен быть равен предыдущему балансу плюс сумма прихода или минус сумма расхода. Если у вас что-то не сходится, значит, ваша система теряет деньги, и пришло время поднять исключение на более высокий уровень.
Бизнес-правила в БД представляют собой условия того, что данные соответствуют предметной области.
Бизнес-правила можно разделить на элементарные и расширенные.
· Элементарные правила ограничивают значения конкретного атрибута или агрегата атрибутов через ограничения домена.
· Расширенные правила выражаются в виде некоторой зависимости между атрибутами.
Ограничения могут быть статическими или динамическими. Статические ограничения должны выполняться для каждого состояния базы данных. Динамические ограничения проявляются при переходе базы данных из одного состояния в другое. Например, при повышении заработной платы служащего новое значение должно быть больше старого.
Ограничения могут найти свое выражение:
· при описании атрибутов отношений в концептуальной схеме;
· в запросе к базе данных;
· процедуре базы данных;
· в правиле (в триггере).
Процедуры базы данных создаются проектировщиком базы данных и дополняют СУБД. В различных СУБД они носят название хранимых, присоединенных, разделяемых и т. д. В системах с архитектурой «клиент-сервер» использование процедур баз данных позволяет значительно снизить трафик сети. Прикладная программа, вызывающая процедуру, передает серверу лишь ее имя и параметры.
Структурные ограничения реализуются процедурой нормализации, использующей функциональные зависимости, действующие между сущностями и атрибутами.
Правило (триггер) – программа для наблюдения за ситуацией, возникающей при изменениях в базе данных. Правило придается таблице базы данных и применяется при выполнении над ней операций включения, удаления или обновления строк, а также при изменении значений в столбцах таблицы. Применение правила заключается в проверке условия, при наступлении истинности которого вызывается указанная внутри правила процедура базы данных. Правила (так же, как и процедуры баз данных) хранятся независимо от прикладных программ.
Словарь данных
Словарь данных – термин может иметь одно из близких по смыслу значений, относясь к базам данных и СУБД:
· документ, описывающий базу данных или комплект баз данных
· целый компонент СУБД, необходимый для определения её структуры
· часть подпрограммного ПО, расширяющее или подменяющее встроенные словари данных СУБД
Словарь данных содержит информацию об источниках, форматах и взаимосвязях между данными, их описания, сведения о характере использования и распределении ответственности. Словарь данных можно рассматривать как вспомогательную базу данных, в которой хранится информация об основной базе данных.
Пользователи баз данных и разработчики приложений могут получить выгоду от единого стандартизированного документа словаря данных, который перечисляет организацию, содержимое, соглашения по одной или более баз данных. Это обычно включает в себя имена и описания различных таблиц и полей в каждой базе данных, дополнительные детали такие, как тип и длина каждого элемента данных. Не существует универсального стандарта, описывающего уровень детализации в подобном документе, но есть основное описание метаданных о структуре базы данных, а не о самих данных. Документ словаря данных также может включать в себя дополнительную информацию, описывающую кодирование элементов данных. Одним из преимуществ хорошо спроектированного документа словаря данных является то, что он помогает упорядочить структуру базы данных или большого комплекса распределенных баз данных.
Словарь данных в СУБД Oracle это набор таблиц, которые содержат следующую информацию:
· Имена пользователей сервера Oracle
· Уровни привилегий пользователей
· Имена объектов базы данных
dBase – семейство широко распространённых систем управления базами данных, а также язык программирования, используемый в них. Самая первая СУБД этого семейства называлась dBase II и была выпущена в 1980 году компанией Ashton-Tate под CP/M, позже появились версии для Apple II, Apple Macintosh, UNIX, VMS и IBM PC под DOS. Версия для PC вместе с пришедшими ей на смену dBase III и dBase IV были несколько лет одной из самых распродаваемых программ. Долгое время dBase не портировали под Microsoft Windows, в результате чего в этой нише у программы оказались сильные конкуренты — Paradox, Clipper, FoxPro и Microsoft Access.
Название «dBase II» предложил рекламный агент. По его мнению, оно звучало весьма респектабельно с технической точки зрения и, кроме того, содержало тонкий намек на то, что это некая новая и, видимо, улучшенная версия своего предшественника — системы dBase.
Конечно, никакого предшественника, который следовало бы улучшить, не было и в помине, однако система dBase II действительно имела ощутимые преимущества по сравнению с другими программами, ориентированными на решение данного класса задач.
Благодаря простоте в использовании, нетребовательности к ресурсам компьютера и, что не менее важно, грамотной маркетинговой политике компании-производителя этот продукт приобрел немалую популярность, а с выходом следующих его версий — dBase III и dBase III Plus (1986 г.), оснащенных весьма комфортной по тем временам средой разработки и средствами манипуляции данными, быстро занял лидирующие позиции среди настольных СУБД и средств создания использующих их приложений.
Хранение данных в dBase основано на принципе «одна таблица — один файл» (эти файлы обычно имеют расширение *.dbf). MEMO-поля и BLOB-поля (доступные в поздних версиях dBase) хранятся в отдельных файлах (обычно с расширением *.dbt). Индексы для таблиц также хранятся в отдельных файлах. При этом в ранних версиях этой СУБД требовалась специальная операция реиндексирования для приведения индексов в соответствие с текущим состоянием таблицы.
Формат данных dBase является открытым, что позволило ряду других производителей заимствовать его для создания dBase-подобных СУБД, частично совместимых с dBase по форматам данных. Например, весьма популярная некогда СУБД FoxBase (разработанная Fox Software, Inc. и ныне принадлежащая Microsoft) использовала формат данных dBase для таблиц, однако форматы для хранения MEMO-полей и индексов были своими собственными, несовместимыми с dBase.
После покупки dBase компанией Borland этот продукт, получивший впоследствии название Visual dBase, приобрел набор дополнительных возможностей, характерных для средств разработки этой компании и для имевшейся у нее другой настольной СУБД — Paradox. Среди этих возможностей были специальные типы полей для графических данных, поддерживаемые индексы, хранение правил ссылочной целостности внутри самой базы данных, а также возможность манипулировать данными других форматов, в частности серверных СУБД, за счет использования BDE API и SQL Links.
Источник: studopedia.su
Бизнес-правила управления базой данных
Бизнес-правила представляют собой механизмы управления БД и предназначены для поддержания БД в целостном состоянии, а также для выполнения ряда других действий, например, накапливания статистики работы с БД.
Бизнес-правила являются просто правилами управления БД и не имеют отношения к бизнесу как предпринимательству.
В первую очередь бизнес-правила реализуют следующие ограничения БД:
- задание допустимого диапазона значений;
- задание значения по умолчанию;
- требование уникальности значения;
- запрет пустого значения;
- ограничения ссылочной целостности.
Бизнес-правила можно реализовывать как на физическом, так и на программном уровнях. В первом случае эти правила (например, ограничения ссылочной целостности для связанных таблиц) задаются при создании таблиц и входят в структуру БД. В дальнейшей работе нельзя нарушить или обойти ограничение, заданное на физическом уровне.
Вместо бизнес-правил, заданных на физическом уровне, или в дополнение к ним можно определить бизнес-правила на программном уровне. Действие этих правил распространяется только на приложение, в котором они реализованы. Для программирования в приложении бизнес-правил используются компоненты и предоставляемые ими средства. Достоинство такого подхода заключается в легкости изменения бизнес-правил и определении правил «своего» приложения. Недостатком является снижение безопасности БД, связанное с тем, что каждое приложение может устанавливать свои правила управления БД.
При работе с удаленными БД в архитектуре «клиент-сервер» бизнес-правила можно реализовывать также на сервере.
Источник: cubook.pro
