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

Модель данных в реляционных СУБД

Читайте также:
  1. Access. Базы данных. Определение ключей и составление запросов.
  2. Decide which answer А, В, С or D best fits each space. Подумайте, какие из предложенных ответов лучше подходят для данных выражений.
  3. Decide which answer А, В, С or D best fits each space. Подумайте, какие из предложенных ответов лучше подходят для данных выражений.
  4. I. Разработка структуры базы данных.
  5. I.5.3. Подготовка данных для задачи линейного программирования
  6. I.5.7. Mодификация (изменение) данных задачи
  7. III. Векторное произведение векторов, заданных координатами
  8. ODBC - открытый интерфейс к базам данных на платформе Microsoft Windows — до 15 мин.
  9. V2. Модель IS-LM
  10. V2. Равновесие совокупного спроса и предложения. Модель AD-AS.
  11. V2: Равновесие совокупного спроса и предложения. Модель AD-AS.
  12. XXII. Модель «К» и отчаянный риск

Прежде чем сохранять какие-либо данные в СУБД, необходимо описать модель этих данных. По типу модели данных СУБД делятся на сетевые, иерархические и реляционные. СУБД реляционного типа являются наиболее распространенными и часто используемыми. В качестве примеров можно привести Oracle
и Microsoft SQL Server.

Теория реляционных СУБД была разработана Коддом из IBM в 60-х годах ХХ века и базируется на математической теории отношений. Важнейшие понятия этой теории – таблица, строка, столбец, отношение, первичный и вторичный ключ.

Реляционная СУБД представляет собой совокупность именованных двумер­ных таблиц данных, логически связанных (находящихся в отношении) между собой. Таблицы состоят из строк и именованных столбцов, строки представляют собой экземпляры информационного объекта, столбцы – атрибуты объекта. В рассмотренном ранее примере таблица (назовем ее “Склад”) состоит из информационных объектов-строк, отдельная строка содержит сведения об отдельном товаре. Каждый товар характеризуется некими параметрами-атри­бутами (“Наименование”, “Цена” и т.д.). Строки иногда называют записями, а столб­цы – полями записи.

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

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

Пример логически взаимосвязанных таблиц:

Сотрудники  
Табельный № Фамилия Должность № отдела
  Иванов Начальник  
  Петров Инженер  
  Сидоров Менеджер  

 

Отделы  
№ отдела Наименование
  Производственный отдел
  Отдел продаж

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

  • Первичный ключ (или главный ключ, primary key, PK). Представляет собой столбец или совокупность столбцов, значения которых однозначно идентифицируют строки. В данном примере первичным ключом в таблице “Сотрудники” является столбец “Табельный №”, ибо в одной организации не бывает сотрудников с одинаковыми табельными номерами. Очевидно, что в таблице “Отделы” первичным ключом является столбец, содержащий номер отдела;
  • Вторичный (или внешний ключ, foreign key, FK). Столбец или совокупность столбцов, которые в данной таблице не являются первич­ными ключами, но являются первичными ключами в другой таблице. В рассматриваемом примере столбец “№ отдела” таблицы “Сотрудники” содержит вторичный ключ, с помощью которого может быть установлена логическая взаимосвязь строк таблицы с соответствующими строками таблицы “Отделы”.

Если какая-либо таблица содержит вторичный ключ, то она считается логически взаимосвязанной с таблицей, содержащей соответствующий первичный ключ. В общем случае эта связь имеет характер “один ко многим” (одному значению первичного ключа может соответствовать несколько значений вторичного, пример – отдел № 15). Возможны варианты, когда вторичный ключ входит в состав первичного ключа. Всё зависит от предметной области, которую описывает модель. В общем случае СУБД ничего “не знает” о логической взаимосвязи таблиц модели. При обращении к СУБД с запросом пользователь должен в явном виде указать условия связывания двух таблиц. В нашем примере условие будет выглядеть примерно так: “Сотрудники”.”№ отдела” = “Отделы”.”№ отдела”. Следовательно, в процессе написания запроса возможно связать две таблицы по любым произвольным полям (не только по первичным и вторичным ключам), которые
в принципе могут быть сравнимы друг с другом. В этом случае связь носит характер “многие ко многим”. Иногда это бывает необходимо делать при написании сложных и специфических запросов, но в общем случае не рекомендуется и свидетельствует об ошибках при проектировании логической модели БД.

В некоторых реляционных СУБД возможно создавать так называемые ограничения целостности, которые в том числе контролируют взаимосвязь между PK и FK. Так, СУБД заблокирует попытки удалить запись из таблицы, на первичный ключ которой “ссылаются” вторичные ключи в других таблицах. И наоборот – нельзя будет внести в поле вторичного ключа значение, отсутствующее в первичном ключе логически взаимосвязанной таблицы. Но это – только средство поддержания целостности данных и защиты от ошибок. Даже при наличии таких конструкций СУБД всё равно требует от пользователя логического связывания таблиц в явном виде при написании запросов к данным.


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 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | 52 | 53 | 54 | 55 | 56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 | 64 | 65 | 66 | 67 | 68 | 69 | 70 | 71 | 72 | 73 | 74 | 75 | 76 | 77 | 78 | 79 | 80 | 81 | 82 | 83 | 84 | 85 | 86 | 87 | 88 | 89 | 90 | 91 | 92 | 93 | 94 | 95 | 96 | 97 | 98 | 99 | 100 | 101 | 102 | 103 | 104 | 105 | 106 | 107 | 108 | 109 | 110 | 111 | 112 | 113 | 114 | 115 | 116 | 117 | 118 | 119 | 120 | 121 | 122 | 123 | 124 | 125 | 126 | 127 | 128 | 129 | 130 | 131 | 132 | 133 | 134 | 135 | 136 | 137 | 138 | 139 | 140 | 141 | 142 | 143 |

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



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