Манипулирование данными

БД созданы для манипулирования данными. Вот примерный набор операций манипулирования данными:

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

Основные принципы создания реляционных БД

1. База данных – это хранилище информации. Это, собственно, следует из самого понятия: база и данные. Причем храниться может совершенно разнородная информация. В современных базах ничто не мешает хранить вместе с прочими данными, например картинки или видеоролики. Хотя в основном все сводится к хранению строковых и числовых значений, что обуславливается требованиями бизнеса (суммы продаж, адреса покупателей и поставщиков и т.п.).

2. Любая информация внутри базы хранится (записывается) в виде таблиц. Это очевидно самый простой, логичный и универсальный способ хранения разнородной информации. Давайте рассмотрим на примере. Предположим нужно хранить данные о деталях, использующихся на заводе. Как бы велся их учет, не прибегая к использованию компьютера? Ответ очевиден – завели бы отдельную тетрадку, разлиновали табличку, в которой в каждой новой строчке записывали бы названия деталей, а в колонках по строке указывали бы необходимые для работы с этой деталью данные. Причем состав колонок как правило будет заранее известен и одинаков для всех деталей. Также обстоит дело и с хранением информации внутри базы данных. Разработчики по аналогии с реальной жизнью организовали хранение в таблицах (см. рис.7).



Рис.7



3. Механизм реляции. Поскольку информации в базе может быть много и самого разного вида, то для ее хранения может быть выделено множество таблиц. Большинство таблиц взаимосвязаны между собой, и для таких взаимосвязей был придуман специальный механизм, названный реляцией (от англ. relation – отношение). Отсюда берет свое начало термин «реляционные базы данных».

---

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

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

Ключевым полем является некий уникальный идентификатор, однозначно характеризующий сами данные. Поясним на примере.

Представьте, что разным отделам на заводе необходима информация о деталях, хранящаяся в БД. Пусть это будут: бухгалтерия, отдел снабжения и конструкторский отдел. Посмотрим, как бы было организованно хранение, если бы не было механизма реляции (рис.8):


Рис.8


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



Рис.9


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

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

4. Каждая реляционная таблица должна обладать следующими свойствами:

1. 
   один элемент таблицы – один элемент данных;
   
2. 
   все столбцы таблицы содержат однородные по типу данные (целочисленный, числовой, текстовый и т.д.);
   
3. 
   каждый столбец имеет уникальное имя;
   
4. 
   число столбцов задаётся при создании таблицы;
   
5. 
   порядок записей в отношении может быть произвольным;
   
6. 
   записи не должны повторяться;
   
7. 
   количество записей в отношении не ограничено.
   

---

Структура простейшей БД

Структура представлена полями (столбцами) и записями (строками) (рис.10). Поле – это атрибут сущности, а запись – один элемент данных (сущность) с конкретными значениями атрибутов. Число столбцов – фиксировано, число строк – переменно.

Строкам таблицы соответствуют кортежи, а столбцам - атрибуты отношения.




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

Элементы реляционной модели данных и формы их представления приведены в таблице:

Элемент реляционной модели	Форма представления
Отношение	Таблица
Схема отношения	Строка заголовков столбцов таблицы (заголовок таблицы)
Кортеж	Строка таблицы
Сущность	Описание свойств объекта
Атрибут	Заголовок столбца таблицы
Домен	Множество допустимых значений атрибута
Значение атрибута	Значение поля в записи
Первичный ключ	Один или несколько атрибутов
Тип данных	Тип значений элементов таблицы

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

В отношении СТУДЕНТ первичным ключом может быть поле ФАМИЛИЯ, если во всём списке нет однофамильцев – это будет простой первичный ключ. Если есть однофамильцы, то совокупность полей – фамилия, имя, отчество – создадут составной первичный ключ. Итак:




На практике обычно в качестве простого первичного ключа выбирают поле, в котором совпадения заведомо исключены. Для рассматриваемого примера таким полем может служить номер зачётной книжки (ЗЧ) студента:


Простой первичный ключ

Номер ЗЧ	Фамилия	Имя	Отчество	Группа
1001001	Сидоров	Илья	Сергеевич	Эд-11
1301002	Китаев	Вадим	Анатольевич	Мд-12
1340096	Сидоров	Илья	Сергеевич	Кд-21
…	…	…	…	…

---

Обычно в базе содержится не одна, а несколько связанных таблиц. Например, если в отношении СТУДЕНТ надо описать вуз, в котором он обучается, то, на первый взгляд, можно было бы включить в отношение следующие поля: СТУДЕНТ (ФАМИЛИЯ, ИМЯ, ОТЧЕСТВО, ГРУППА, НАЗВАНИЕ вуза, АДРЕС вуза). Но при заполнении такой таблицы для каждого студента придётся указывать довольно длинное наименование вуза и его адрес, что неудобно:

Номер ЗЧ	Фамилия	Имя	Отчество	Группа	Название ВУЗа	Адрес ВУЗа
1001001	Сидоров	Илья	Сергеевич	Эд-11	***	***
1301002	Китаев	Вадим	Анатольевич	Мд-12	***	***
1340096	Сидоров	Илья	Сергеевич	Кд-21	***	***
…	…	…	…	…	…	…

Более того, любая незначительная ошибка во вводе этих полей приведёт к нарушению непротиворечивости базы данных. Например, ошибка в адресе вуза приведёт к тому, что в БД появятся два вуза с одинаковым наименованием и разными адресами.

Поступают в таком случае так: в отношение СТУДЕНТ (ФАМИЛИЯ, ИМЯ, ОТЧЕСТВО, ГРУППА) вводят поле «Код ВУЗа» (целое число) и добавляют ещё одно отношение – ВУЗ (КОД вуза, НАЗВАНИЕ, АДРЕС). Таблицы СТУДЕНТ и ВУЗ при этом будут связаны по полю «КОД вуза». В отношении ВУЗ поле «КОД вуза» будет первичным ключом, а в отношении СТУДЕНТ поле «КОД вуза» будет внешним ключом.

Отношение «СТУДЕНТ»

Номер ЗЧ	Код ВУЗа	Фамилия	Имя	Отчество	Группа
1001001	1	Сидоров	Илья	Сергеевич	Эд-11
1301002	2	Китаев	Вадим	Анатольевич	Мд-12
1340096	3	Сидоров	Илья	Сергеевич	Кд-21
…	…	…	…	…	…

---

Первичный ключ для связи


Отношение «ВУЗ»

Код ВУЗа	Название	Адрес
1	Московский экономический институт	г. Москва, ул. Королева, 19
2	Челябинский юридический институт	г. Челябинск, ул. Авдеева, 107
3	Московская сельскохозяйственная академия	г. Москва, ул. Косыгина, 23
…	…	…

При работе с такими таблицами повторяться могут только данные в поле «Код ВУЗа», а все необходимые сведения о вузе можно взять из отношения ВУЗ.

Понятие о связывании отношений

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

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

Связь между таблицами позволяет:

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

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

Между таблицами могут устанавливаться бинарные (между двумя таблицами), тернарные (между тремя таблицами) и, в общем случае, n-арные связи.

Рассмотрим наиболее часто встречающиеся бинарные связи. При связывании двух таблиц выделяют основную и дополнительную (подчиненную) таблицы. Логическое связывание таблиц производится с помощью

---

Смотрите также файлы

• 3 глава i. Теоретические аспекты изучения связной речи у детей с нарушением слуха.pdf

• Отбасы жне неке. Баыт не келеді жне баыта не кедергі.docx

• Утвержден приказом Министра здравоохранения Республики Казахстан от 11 августа 2020 года.docx

• Итоговая работа слушателя курсов.doc

• Итоговое повторение по курсу история Древнего мира 5 класс.docx