АвтоАвтоматизацияАрхитектураАстрономияАудитБиологияБухгалтерияВоенное делоГенетикаГеографияГеологияГосударствоДомДругоеЖурналистика и СМИИзобретательствоИностранные языкиИнформатикаИскусствоИсторияКомпьютерыКулинарияКультураЛексикологияЛитератураЛогикаМаркетингМатематикаМашиностроениеМедицинаМенеджментМеталлы и СваркаМеханикаМузыкаНаселениеОбразованиеОхрана безопасности жизниОхрана ТрудаПедагогикаПолитикаПравоПриборостроениеПрограммированиеПроизводствоПромышленностьПсихологияРадиоРегилияСвязьСоциологияСпортСтандартизацияСтроительствоТехнологииТорговляТуризмФизикаФизиологияФилософияФинансыХимияХозяйствоЦеннообразованиеЧерчениеЭкологияЭконометрикаЭкономикаЭлектроникаЮриспунденкция

Реляционные базы данных

Читайте также:
  1. Access. Базы данных. Определение ключей и составление запросов.
  2. DBASe-подобные реляционные языки
  3. I. Разработка структуры базы данных.
  4. Абстрактные структуры данных
  5. Автоматизированная система обработки данных правовой статистики
  6. Авторское право - правовое положение авторов и созданных их творческим трудом произведений литературы, науки и искусства.
  7. Алгоритм шифрования данных IDEA
  8. Американский стандарт шифрования данных DES
  9. Анализ данных при исследовании систем управления
  10. Анализ матричных данных (матрица приоритетов)
  11. Аппаратура линии связи: аппаратура передачи данных, оконечное оборудование, промежуточная аппаратура.
  12. Архитектура, управляемая событиями. Типы данных Win32. Оконная процедура (функция). Оконный класс.

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

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

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

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

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

Рассмотрим таблицу, содержащую данные о сотрудниках предприятия.

Табельный № Фамилия И.О. Код отдела Рабочий телефон
  ПЕТРОВ А.В.   555-12-67
  РОМАНЕНКО С.Т.   555-12-80
  СТЕПАНОВА И.С.    

Можно увидеть, что у всех трех записей атрибуты одинаковы, однако принимают разные значения. Так, для записи №1 атрибут "табельный №" принимает значение "008976", а для записи №2 - "008980" и т.д.

Значения некоторых атрибутов у разных записей может совпадать, например, у записей №1 и №2 одинаковое значение атрибута "код отдела". Однако в каждой таблице должен иметься атрибут (или совокупность атрибутов), значение которых никогда не повторяется и однозначно идентифицирует каждую ее строку. Это нужно для того, чтобы при работе с базой можно было недвусмысленным образом отличать одну запись от другой. Такие атрибуты называют уникальными. Уникальный атрибут таблицы или совокупность ее уникальных атрибутов называют первичным ключом или ключевым полем. В данной таблице ключом является атрибут "табельный №".

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

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

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

Код Наименование отдела
  ДИРЕКЦИЯ
  БУХГАЛТЕРИЯ
  ОТДЕЛ КАДРОВ
  КАНЦЕЛЯРИЯ

Между двумя приведенными таблицами можно установить отношение "СОТРУДНИК - работает в - ОТДЕЛЕ". Если требуется узнать информацию об отделе, в котором работает сотрудник, нужно взять значение атрибута "код отдела" в таблице "СОТРУДНИКИ" и найти соответствующий код в таблице "ОТДЕЛЫ". Таким образом, две записи из разных таблиц как бы объединятся в одну:

Табельный № Фамилия И.О. Код отдела Рабочий телефон
  РОМАНЕНКО С.Т.   555-12-80

+

Код Наименование отдела
  ОТДЕЛ КАДРОВ

=

Табельный № Фамилия И.О. Код отдела Рабочий телефон Наименование отдела
  РОМАНЕНКО С.Т.   555-12-80 ОТДЕЛ КАДРОВ

Можно увидеть, что отношения между двумя таблицами устанавливаются на основе соответствия значений атрибутов двух таблиц, в нашем случае это атрибут "код отдела" таблицы "СОТРУДНИКИ" и атрибут "код" таблицы "ОТДЕЛЫ". Такие атрибуты называют атрибутами связи. Атрибут связи в одной таблице должен быть ключом. В приведенном примере атрибут "код" является ключом для таблицы "ОТДЕЛЫ". Если бы это было не так, и коды отделов в этой таблице повторялись, невозможно было бы определить, о каком из отделов говорится в первой таблице. Второй атрибут связи - в данном случае атрибут "код отдела" таблицы "СОТРУДНИКИ" – называют внешним ключом, так как он ссылается на ключ другой ("внешней") таблицы.

Для поддержания целостности данных необходимо, чтобы внешний ключ всегда ссылался на существующий ключ. Например, если в таблице "СОТРУДНИКИ" указать код отдела со значением 028, а в таблице "ОТДЕЛЫ" отдела с таким кодом не будет, то целостность данных нарушится - сотрудник будет показан работником несуществующего отдела. Поэтому сама база данных или работающее с ней приложение должно запрещать ввод значений внешнего ключа, ссылающегося на несуществующий ключ.

Подобное нарушение целостности может возникнуть и в том случае, когда удаляется одна из записей таблицы, содержащей ключевое поле. Например, при удалении из таблицы "ОТДЕЛЫ" записи №3, содержащей ключ 024, записи №1 и №2 таблицы "СОТРУДНИКИ" будут ссылаться на несуществующий отдел.

Целостность данных в этом случае поддерживается одним из нескольких способов:

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

· Если запись удаляется, то все внешние ключи ссылающихся на нее записей принимают нулевое значение. В нашем случае атрибут "код отдела" для первых двух сотрудников примет нулевое значение.

· Ссылающиеся записи "каскадно" уничтожаются. При удалении записи об отделе 024 в таблице "ОТДЕЛЫ" все записи о сотрудниках этого отдела в таблице "СОТРУДНИКИ" также будут удалены.

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

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


1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 |

Поиск по сайту:



Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Студалл.Орг (0.003 сек.)