Галерея
7757 8119 8300 8698 8817 9504 9722 9937
Интересные записи
Новое на сайте
Топовые новости

Структура данных

В первом и втором правилах Кодда говорится, что «информация логически представлена в виде таблиц» и что «логический доступ к данным должен осуществляться по таблице, первичному ключу и столбцу». Поэтому процесс создания таблицы в SQL не требует, чтобы прикладная программа указывала базе данных, как ей нужно взаимодействовать с низкоуровневыми физическими структурами данных. Более того, SQL логически изолирует процесс доступа к данным и физическое обслуживание этих данных в соответствии с правилом 8: «пакетные операции и операции конечных пользователей логически отделены от физических методов хранения и доступа».

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

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

Далее приводится терминология SQL 2003, применяемая для описания иерархических структур данных, используемых в реляционной базе данных: кластеры содержат набор каталогов, каталоги содержат набор схем, схемы содержат набор объектов, таких, как таблицы и представления. Таблицы состоят из набора столбцов и записей.

Например, в таблице BusinessExpense1 столбец под названием Expense_Date может показывать дату, когда были произведены данные расходы. Каждая запись в таблице описывает конкретную сущность, в данном случае — все, что повлекло за собой деловые расходы (когда это случилось, какова стоимость, кто произвел трату, с какой целью и тому подобное). Предполагается, что каждый признак расходов, иными словами, каждый столбец является неделимым, то есть допускает одно и только одно значение в каждом ряду. Если таблица создается таким образом, что на пересечении столбца и записи может содержаться несколько значений, это нарушает одно из главных требований, предъявляемых SQL к структуре базы. (Конечно, некоторые платформы баз данных, описываемые в этой книге, позволяют размещать в столбце больше одного значения при помощи типов данных VARRAY или TABLE.)

Для значений в столбце существуют определенные правила. Самое главное состоит в том, что значения столбца должны относиться к одному домену, который больше известен под названием тип данных. Например, в поле Expense_Date нельзя поместить значение ELMER. Значение ELMER представляет собой строку, а не дату, а в поле ExpenseJDate могут содержаться только даты. Следовательно, данный столбец определяется как столбец, содержащий тип данных DATE. Кроме этого, SQL 2003 позволяет осуществлять дополнительный контроль над значениями столбца при помощи ограничений (constraints) и утверждении (assertions). С помощью ограничений SQL можно ограничить данные по столбцу Expcnse_Date только теми расходами, которые были выполнены не более года назад.

Кроме этого, доступ к данным для всех пользователей и компьютерных процессов контролируется на уровне схем по Авторизационному ID (AuthorizationlD) или по пользователю (user). Каждому пользователю можно предоставлять или запрещать доступ к конкретным наборам данных.

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

Источник