Реляционные базы данных. Таблицы базы данных. Поля, записи, свойства полей. Типы полей. Ключевые поля. Типы отношений между таблицами реляц

Реляционные базы данных. Таблицы  базы данных. Поля, записи, свойства полей. Типы полей. Ключевые поля. Типы отношений между  таблицами реляционной  базы данных .

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

     Реляционная модель данных впервые была предложена американским математиком Коддом в 1970 году . Фундаментальным понятием реляционной БД является отношение. Это отражено и в общем названии подхода - термин реляционный ( relational ) происходит от relation (отношение). На физическом уровне отношения представляют собой таблицы. В реляционной модели все данные представлены в виде простых таблиц, разбитых на строки и столбцы. К сожалению, практическое определение понятия «реляционная база данных» оказалось гораздо более расплывчатым, чем точное математическое определение, данное этому термину Коддом в 1970 году. Поставщики СУБД реализовывали в своих продуктах лишь некоторые черты реляционных систем, и, фактически, потенциальные возможности и смысл реляционного подхода искажались.

     В ответ на это в 1985 году Кодд написал  статью, где сформулировал 12 правил, которым должна удовлетворять любая  база данных, претендующая на звание реляционной. Приведенные ниже двенадцать правил Кодда считаются определением реляционной  СУБД [1, 2].

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

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

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

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

     5. Правило исчерпывающего подъязыка данных. Реляционная система может поддерживать различные языки и режимы взаимодействия с пользователем (например, режим вопросов и ответов). Однако должен существовать, по крайней мере, один язык, операторы которого можно представить в виде строк символов, в соответствии с некоторым четко определенным синтаксисом и который в полной мере поддерживает следующие элементы:

     •  определение данных;

     •  определение представлений;

     •  обработку данных (интерактивную и программную);

     •  условия целостности;

     •  идентификация прав доступа;

     •  границы транзакций (начало, завершение и отмена).

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

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

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

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

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

     11. Правило независимости распространения. Реляционная СУБД не должна зависеть от потребностей конкретного пользователя.

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

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

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

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

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

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

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

     Поля - это основные элементы структуры базы данных. Они  обладают свойствами. От свойств полей  зависит, какие типы данных можно  вносить в поле, а какие нет, а также то, что можно делать с данными, содержащимися в поле.  
          Например, данные, содержащиеся в поле Цена, можно просуммировать, чтобы определить итоговый результат. Суммировать данные, содержащиеся в поле Номер телефона, совершенно бессмысленно, даже если номера телефонов записаны цифрами. Очевидно, что эти поля обладают разными свойствами и относятся к разным типам.  
          Основным свойством любого поля является его длина. Длина поля выражается в символах или, что, то же самое, в знаках. От длины поля зависит, сколько информации в нем может поместиться. Мы знаем, что символы кодируются одним или двумя байтами, поэтому можно условно считать, что длина поля измеряется в байтах.  
          Очевидным уникальным свойством любого поля является его Имя. Разумеется, одна база данных не может иметь двух полей с одинаковым именем, поскольку компьютер запутается в их содержимом. Но кроме имени у поля есть еще свойство Подпись. Подпись - это та информация, которая отображается в заголовке столбца. Ее не надо путать с именем поля, хотя если подпись не задана, то в заголовке отображается имя поля. Разным полям, например, можно задать одинаковые подписи. Это не помешает работе компьютера, поскольку поля при этом по-прежнему сохраняют разные имена.  
Разные типы полей имеют разное назначение и разные свойства.  
         1. Основное свойство текстового поля - размер.  
          2. Числовое поле служит для ввода числовых данных. Оно тоже имеет размер, но числовые поля бывают разными, например для ввода целых чисел и для ввода действительных чисел.

     В последнем случае кроме размера  поля задается также размер десятичной части числа.  
          3. Поля для ввода дат или времени имеют тип Дата/время. Для ввода логических данных, имеющих только два значения (Да или Нет; 0 или 1; Истина или Ложь и т. п.), служит специальный тип - Логическое поле. Нетрудно догадаться, что длина такого поля всегда равна 1 байту, поскольку этого более чем достаточно, чтобы выразить логическое значение.  
          4. Особый тип поля - Денежный. Из названия ясно, какие данные в нем хранят. Денежные суммы можно хранить и в числовом поле, но в денежном формате с ними удобнее работать. В этом случае компьютер изображает числа вместе с денежными единицами, различает рубли и копейки, фунты и пенсы, доллары и центы, в общем, обращается с ними элегантнее.  
          5. В современных базах данных можно хранить не только числа и буквы, но и картинки, музыкальные клипы и видеозаписи. Поле для таких объектов называется полем объекта OLE.  
          6. У текстового поля есть недостаток, связанный с тем, что оно имеет ограниченный размер (не более 256 символов). Если нужно вставить в поле длинный текст, для этого служит поле типа MEMO. В нем можно хранить до 65 535 символов. Особенность поля MEMO состоит в том, что реально эти данные хранятся не в поле, а в другом месте, а в поле хранится только указатель на то, где расположен текст.  
          7. Очень интересно поле Счетчик. На первый взгляд это обычное числовое поле, но оно имеет свойство автоматического наращивания. Если в базе есть такое поле, то при вводе новой записи в него автоматически вводится число, на единицу большее, чем значение того же поля в предыдущей записи. Это поле удобно для нумерации записей.

     Ключевое  поле - это поле, значение которого од нозначно определяет запись в таблице.

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

     Связи между таблицами

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

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

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

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

     Мощность связи представляет собой отношение количества экземпляров родительской сущности к соответствующему количеству дочерней сущности. По мощности связи выделяют отношения «один к одному», «один ко многим», «многие ко многим».

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

     «Один ко многим» - наиболее распространенный вид связи. При этом типе связи одной строке родительской таблицы может соответствовать множество строк дочерней таблицы, но любой строке дочерней таблицы может соответствовать только одна строка родительской таблицы.