построение запросов sql

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

Правило 1 напоминает неформальное определение реляционной базы данных, приведенное ранее.

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

Правило 3 требует, чтобы отсутствующие данные можно было представить с помощью недействительных значений (NULL).

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

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

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

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

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

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

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

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

Однако можно сформулировать и более простое определение.

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

В настоящем пособии используется учебная реляционная база данных, которая представляет собой очень упрощенный пример информационной модели системы Абонент+ , используемой для информационного обеспечения деятельности газораспределительных организаций и региональных компаний по реализации газа [3]. Полное описание таблиц учебной базы данных и содержащихся в ней данных приведено в приложении А. Далее будут рассмотрены основные понятия реляционных баз данных на примере учебной базы данных.

1.2. Таблицы

В реляционной базе данных информация организована в виде реляционных таблиц, разделённых на строки и столбцы, на пересечении которых содержатся значения данных [4].

Таблица - это некоторая регулярная структура, состоящая из конечного набора однотипных записей.

Таблица отражает тип объекта реального мира (сущность). Строки соответствуют экземпляру объекта, конкретному событию или явлению. Столбцы соответствуют атрибутам (признакам, характеристикам, параметрам) объекта, события, явления. У каждой таблицы имеется уникальное имя внутри базы данных, описывающее её содержимое.

У каждого столбца в таблице есть своё имя, которое обычно служит заголовком столбца. Все столбцы в одной таблице должны иметь уникальные имена, однако разрешается присваивать одинаковые имена столбцам, расположенным в различных таблицах. В реляционной модели данных атрибуты отношений не упорядочены, т.е. обращение к полям всегда происходит по именам, а не по расположению. Однако в языке SQL допускается индексное указание столбцов таблиц, при этом столбцы рассматриваются в порядке слева направо (их порядок определяется при создании таблицы) [1].

В любой таблице всегда есть как минимум один столбец. В стандарте ANSI/ISO не указывается максимально допустимое число столбцов в таблице, однако почти во всех коммерческих СУБД этот предел существует. В СУБД Firebird этот предел составляет 32767 столбцов.

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

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

Проиллюстрируем более наглядно структуру одной из таблиц учебной базы данных (см. приложение А). На рис. 1.1 приведена структура таблицы Abonent, содержащей сведения об абонентах газораспределительной организации.

Данные об абоненте Конюхов B.C.

Данные об абоненте Шмаков СВ.

Номер лицевого счета абонента

ФИО абонента

Номер телефона абонента

Номер дома

Идентификатор Номер

улицы, на которой квартиры проживает абонент

Рис. 1.1. Структура реляционной таблицы Abonent

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

Каждый вертикальный столбец таблицы представляет совокупность значений конкретного атрибута объекта. Например, в столбце AccountCD содержатся уникальные номера лицевых счетов абонентов. В столбце Phone содержатся телефонные номера абонентов.

Значение данных представляет собой действительные данные, содержащиеся в каждом элементе данных. На пересечении каждой строки с каждым столбцом таблицы содержится в точности одно значение данных. Например, в строке, представляющей абонента КОНЮХОВ В.С., в столбце Fio содержится значение КОНЮХОВ В.С.. В столбце AccountCD той же строки содержится значение 015527, которое является номером лицевого счета абонента кОнЮХОВ В.С. Все значения, содержащиеся в одном и том же столбце, являются данными одного типа. Например, в столбце Fio содержатся только слова, а в столбце StreetCD содержатся целые числа, представляющие идентификаторы улиц. В реляционной модели данных общая совокупность значений, из которой берутся действительные значения для определенных атрибутов (столбцов) называется доменом [1]. Доменом столбца Fio, например, является множество фамилий абонентов. Каждый столбец всегда определяется на одном домене.

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