Расстройство, связанное с неадекватными способностями сетевых и иерархических баз данных, закончилось изобретением реляционной модели данных. Реляционная модель данных брала идею из сетевой базы данных, но на несколько шагов дальше. Реляционные модели - точно так же как иерархические и сетевые модели - основаны на таблицах и используют родительско/дочерние отношения. (Хотя эти отношения были осуществлены через значения столбца в противоположность физическому указателю низкого уровня, определяющему отношения; больше об этом в дальнейших главах.)
Таблица - основной сборочный узел реляционной базы данных. Это - довольно интуитивный путь организации данных и он был вокруг в течение столетий. Таблица состоит из строк и столбцов (в жаргоне базы данных называемые записями и полями). Каждая таблица в базе данных имеет уникальное название (то есть, уникальное полностью составное имя, которое включает схему или название базы данных как префикс).
Примечание: Точка (.) в полностью составном имени в мире программирования обычно используется, чтобы описать иерархию объектов и их свойств. Это можно отнести не только к объектам базы данных но также и к структурам, определяемых пользователем типов. Например, поле таблицы в MS SQL Server database могло упоминаться как ACME.DBO.CUSTOMER.CUST_ID_N, где ACME - название базы данных, DBO - владелец таблицы (стандарт Микрософта), CUSTOMER - название таблицы, и CUST_ID_N - название столбца в таблице CUSTOMER.
Каждое поле в пределах таблицы имеет уникальное название, и любая таблица должна иметь по крайней мере одно поле. Число полей в таблицу обычно ограничивается, ограничение зависит от каждой системы управления. В отличие от структуры наследственных баз данных, записи в таблице не сохраняются и не находятся в специфическом порядке (хотя, запии могут быть размещены в специфическом порядке посредством использования сгруппированного индекса - обсужденный в Главе 4); задача сортировки записей в Системе Управления Реляционными Базами Данных (СУРБД) понижена к SQL.
Запись, таким образом, составлена из ряда ячеек, где каждая ячейка имеет уникальное название и может содержать какие-либо данные. Таблица, которая не имеет никаких записей, называется пустой таблицей.
Данные в пределах поля должны иметь одинаковый тип, например, поле AMOUNT содержит только числа, и поле DESCRIPTION, только слова. Набор данных в пределах одного поля, называют домен столбца.
Примечание: Ранние базы данных – реляционные и другие - были предназначены, для хранения только текстовых данных; современные базы данных хранят все, что может быть конвертировано в бинарный код: изображения, кино, аудио записи, и так далее.
Хороший реляционный дизайн подразумевает, что в записях описывается только один объект – это еще один термин из реляционных баз данных, который будет обсужден в книге позже, но стоящий упоминания здесь. Говоря другими словами, запись не должна содержать несоответствующую информацию: таблица CUSTOMER имеет дело с информацией только по заказчику, ее записи не должны содержать информацию о, скажем, изделиях, которые этот заказчик заказывал.
Примечание: Процесс группировки уместных данных вместе, устранение избыточности называется нормализацией и будет обсужден в Главе 2 . Это - не часть SQL, но это налагает пределы на эффективность SQL запроса.
Нет никакого теоретического предела на число строк, которые таблица могла бы иметь, хотя некоторые задачи налагают ограничения; также есть (или по крайней мере должны быть) практические соображения о пределах: быстродействие поиска данных, количество памяти и так далее.
Отношения
Таблицы в СУРБД могут быть связанными, а могут быть и несвязанными. Поскольку это было упомянуто прежде, СУРБД построена на понятии родительско/дочерних отношениях (отсюда и название - реляционные), и в отличие от наследственных баз данных(иерархических и сетевых) эти отношения основаны исключительно на значениях в столбцах таблицы; эти отношения обозначены в логических терминах(на логическом уровне), а не определены в компьютерных указателях низкого уровня. Давайте возьмем например нашу фиктивную базу данных (ту, которую мы будем проектировать, строить и использовать во всей книге). Таблица ORDER_HEADER связана с таблицей CUSTOMER, так как обе из этих таблиц имеют общий набор значений: полю ORDHDR_CUSTID_FN (ID заказчика) в ORDER_HEADER (и его значениям) соответствует CUST_ID_N в таблице CUSTOMER. Поле CUST_ID_N, как считают, первичный ключ для таблицы CUSTOMER и вторичный ключ для таблицы ORDER_HEADER (хоть и под различным названием).
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.