Что такое реляционная база данных (РСУБД)?
Реляционные базы данных представляют собой базы данных, которые используются для хранения и предоставления доступа к взаимосвязанным элементам информации. Реляционные базы данных основаны на реляционной модели — интуитивно понятном, наглядном табличном способе представления данных. Каждая строка, содержащая в таблице такой базы данных, представляет собой запись с уникальным идентификатором, который называют ключом. Столбцы таблицы имеют атрибуты данных, а каждая запись обычно содержит значение для каждого атрибута, что дает возможность легко устанавливать взаимосвязь между элементами данных.
Пример реляционной базы данных
В качестве примера рассмотрим две таблицы, которые небольшое предприятие использует для обработки заказов продукции. Первая таблица содержит информацию о заказчиках: каждая запись в ней включает в себя имя и адрес заказчика, платежные данные и информацию о доставке, номер телефона и т. д. Каждый элемент информации (атрибут) помещен в отдельный столбец базы данных, которому назначен уникальный идентификатор (ключ) для каждой строки. Во второй таблице (с информацией о заказе) каждая запись содержит идентификатор заказчика, совершившего заказ, название заказанного продукта, его количество, размер или цвет и т. д. Записи в этой таблице не содержат таких данных, как имя заказчика или его контактные данные.
У обеих таблиц есть только один общий элемент — идентификатор столбца (ключ). Благодаря наличию этого общего столбца реляционные базы данных могут устанавливать взаимосвязи между двумя таблицами. Когда приложение для обработки заказов передает заказ в базу данных, база данных обращается к таблице со сведениями о заказах, извлекает сведения о продукции и использует идентификатор заказчика из этой таблицы, чтобы найти сведения об оплате и доставке в таблице с информацией о нем. Затем на складе подбирают нужный продукт, заказчик своевременно получает свой заказ и производит оплату.
Структура реляционных баз данных
Реляционная модель подразумевает логическую структуру данных: таблицы, представления и индексы. Логическая структура отличается от физической структуры хранения. Такое разделение дает возможность администраторам управлять физической системой хранения, не меняя данных, содержащихся в логической структуре. Например, изменение имени файла базы данных не повлияет на хранящиеся в нем таблицы.
Разделение между физическим и логическим уровнем распространяется в том числе на операции, которые представляют собой четко определенные действия с данными и структурами базы данных. Логические операции дают возможность приложениям определять требования к необходимому содержанию, в то время как физические операции определяют способ доступа к данным и выполнения задачи.
Чтобы обеспечить точность и доступность данных, в реляционных базах должны соблюдаться определенные правила целостности. Например, в правилах целостности можно запретить использование дубликатов строк в таблицах, чтобы устранить вероятность попадания неправильной информации в базу данных.
Реляционная модель
В первых базах данных данные каждого приложения хранились в отдельной уникальной структуре. Если разработчик хотел создать приложение для использования таких данных, он должен был хорошо знать конкретную структуру, чтобы найти необходимые данные. Такой метод организации был неэффективен, сложен в обслуживании и затруднял оптимизацию эффективности приложений. Реляционная модель была разработана, чтобы устранить потребность в использовании разнообразных структур данных.
Она обеспечила стандартный способ представления данных и отправки запросов, которые могли быть использованы в любых приложениях. Разработчики уяснили, что таблицы являются ключевым преимуществом реляционных баз данных, так как обеспечивают интуитивно понятный, эффективный и гибкий способ хранения структурированной информации и получения к ней доступа.
Со временем, когда разработчики стали использовать язык структурированных запросов (SQL) для записи данных в базу и отправки запросов, стало очевидным и другое преимущество реляционной модели. Вот уже на протяжении многих лет SQL широко используется в качестве языка запросов в базах данных. Он основан на алгоритмах реляционной алгебры и четкой математической структуре, что обеспечивает простоту и эффективность при оптимизации любых запросов к базе данных. Для сравнения: при использовании других подходов приходится создавать отдельные, уникальные запросы.
Преимущества системы управления реляционными базами данных
Компании всех типов и размеров используют простую, но функциональную реляционную модель для обслуживания разнообразных информационных потребностей. Реляционные базы данных применяются для отслеживания товарных запасов, обработки торговых транзакций через Интернет, управления большими объемами критически важных данных заказчиков и т. д. Реляционные базы данных можно рекомендовать для обслуживания любых информационных потребностей, где элементы данных связаны между собой и необходимо обеспечивать безопасное и надежное управление ими на основе правил целостности.
Реляционные базы данных появились в 1970-х годах. На сегодняшний день преимущества реляционного подхода сделали его самой распространенной моделью для баз данных в мире.
Реляционная модель и согласованность данных
Реляционная модель наиболее эффективно поддерживает целостность данных во всех приложениях и копиях (экземплярах) базы данных. Например, когда заказчик кладет деньги на счет с помощью банкомата, а затем проверяет баланс на мобильном телефоне, он ожидает, что поступившие средства сразу же отобразятся на счете. Реляционные базы данных отлично подходят для обеспечения целостности данных в различных экземплярах базы в одно и то же время.
Другие типы баз данных не могут одновременно поддерживать целостность больших объемов данных. Некоторые современные типы баз данных, такие как NoSQL, обеспечивают только так называемую окончательную целостность. Это значит, что, когда выполняется масштабирование данных или несколько пользователей одновременно используют одни и те же данные, необходимо некоторое время на внесение изменений. В некоторых случаях окончательная целостность вполне приемлема (например, для обновления позиций в товарном каталоге), однако для критически важной операционной деятельности бизнеса (например, транзакций с использованием корзины) реляционные базы представляют собой фундаментальный стандарт.
Фиксация изменений и атомарность
В реляционных базах данных используются очень детальные и строгие бизнес-правила и политики в отношении фиксации изменений в базе данных (то есть сохранения изменений в данных на постоянной основе). Рассмотрим для примера складскую базу данных, в которой отслеживаются три запчасти, всегда использующиеся в комплекте. Когда одну из них извлекают из товарных запасов, две другие также должны извлекаться. Если одна из трех запчастей недоступна, две другие также не могут быть проданы отдельно, то есть, чтобы в базу данных можно было внести изменения, должны быть доступны все три запчасти. Реляционная база данных не разрешит сохранять изменения, если они не касаются всех трех запчастей. Эту особенность реляционных баз данных называют атомарностью или неразрывностью. Неразрывность необходима для сохранения точности данных в базе и обеспечения соответствия с правилами, нормативными положениями и бизнес-политиками.
Свойства ACID и РСУБД
Транзакции реляционных баз данных определяются четырьмя основными свойствами: : атомарность, согласованность, изоляция и долговечность, которые обычно обозначаются аббревиатурой ACID.
- Неразрывность определяет все элементы, которые необходимы для совершения транзакции в базе данных.
- Согласованность или целостность определяет правила сохранения состояния данных после выполнения транзакции.
- Изолированность гарантирует, что во избежание путаницы транзакция не повлияет на другие элементы до окончательного сохранения изменений.
- Неизменность обеспечивает неизменность данных после сохранения изменений в результате транзакции.
Хранимые процедуры и реляционные базы данных
Доступ к данным включает в себя множество повторяющихся действий. Например, иногда для получения нужного результата простой запрос для получения информации из таблицы необходимо повторить сотню или тысячу раз. Для таких сценариев доступа к базе данных необходимо что-то вроде программного кода. Разработчикам каждый раз писать стандартный код доступа к данным для нового приложения было бы утомительно. К счастью, реляционные базы данных поддерживают хранимые процедуры, представляющие собой блоки кода, к которым можно получить доступ с помощью обычного вызова со стороны кода приложения. Например, одну и ту же хранимую процедуру можно использовать для последовательной маркировки записей в целях удобства пользователей для различных приложений. Хранимые процедуры также помогают разработчикам убедиться в правильной реализации определенных функций данных в приложении.
Блокировки базы данных и параллельный доступ
Когда несколько пользователей или приложений пытаются одновременно изменить одни и те же данные, это может вести к возникновению конфликта в базе. Блокировки и параллельный доступ снижают вероятность конфликтов и способствуют сохранению целостности данных.
Блокировка не разрешает другим пользователям и приложениям получать доступ к данным во время их обновления. В некоторых базах данных блокировка может применяться к целой таблице, что негативно отражается на эффективности приложения. В других типах баз данных, например реляционных базах Oracle, блокировка выполняется на уровне одной записи, оставляя другие записи в таблице доступными. Такой подход помогает сохранить эффективность приложения.
Инструмент параллельного доступа используется, когда несколько пользователей или приложений пытаются одновременно выполнить запросы к одной базе данных. Он обеспечивает доступ пользователей и приложений к базе данных в соответствии с политиками контроля.
Характеристики, на которые следует обратить внимание при выборе реляционной базы данных
Программное обеспечение, которое используется для сохранения, контроля и извлечения данных в базе, а также выполнения к ней запросов, называют системой управления реляционной базой данных (РСУБД). РСУБД обеспечивает интерфейс между пользователями и приложениями и базой данных, а также административные функции для управления хранением данных, их эффективностью и доступом к ним.
При выборе типа базы данных и продуктов на основе реляционных баз данных необходимо учитывать несколько факторов. Выбор РСУБД зависит от потребностей Вашей компании. Задайте себе следующие вопросы.
- Каковы наши требования к точности данных? Будем ли мы использовать бизнес-логику для хранения и обеспечения точности данных? Предъявляются ли к нашим данным более строгие требования в отношении точности (например, если Вы работаете с финансовыми данными и отчетностью)?
- Нужна ли нам масштабируемость? Какими объемами данных требуется управлять и каков прогнозируемый рост этих объемов? Должна ли модель базы данных поддерживать зеркальные копии (как отдельные экземпляры) в целях масштабирования? Если да, сможем ли мы обеспечивать целостность данных в этих экземплярах?
- Насколько важно наличие параллельного доступа? Потребуется ли пользователям и приложениям одновременный доступ к данным? Поддерживает ли ПО базы данных параллельный доступ без ущерба для безопасности?
- Каковы наши потребности в эффективности и надежности баз данных? Требуется ли нам высокоэффективная и надежная система? Каковы требования к скорости выполнения запросов? Какие гарантии дает поставщик услуг в соответствии с соглашением об уровне обслуживания (SLA) или на случай незапланированного простоя?
Реляционная база данных будущего: автономная база данных
На протяжении лет реляционные базы данных улучшали производительность, надежность и безопасность и становились проще в обслуживании. Однако их структура становилась все более сложной, и, как следствие, администрирование такой базы данных начало требовать немалых усилий. Вместо того чтобы использовать свои навыки для разработки инновационных приложений, которые будут приносить прибыль организации, разработчики вынуждены посвящать львиную долю времени на управление базой данных для оптимизации ее эффективности.
Сегодня автономные технологии используются, чтобы расширить возможности реляционной модели, технологии облачных баз данных и машинного обучения и создать реляционную базу данных нового типа. Самоуправляемая база данных (которую также называют автономной) сохраняет все преимущества и возможности реляционной модели и добавляет к ним средства на основе искусственного интеллекта, машинного обучения и автоматизации для мониторинга и оптимизации скорости выполнения запросов и управления. Например, чтобы улучшить скорость выполнения запросов, самоуправляемая база данных строит прогнозы и проверяет индексы, а затем применяет лучшие результаты на практике — и все это без участия администратора. Самоуправляемые базы данных постоянно вносят такие улучшения в собственную работу без человеческого вмешательства.
Автономные технологии дают возможность разработчикам больше не тратить время на рутинные задачи обслуживания. Например, больше не нужно заблаговременно определять требования к инфраструктуре. При использовании самоуправляемой базы данных можно расширять системы хранения и добавлять вычислительные ресурсы по мере возникновения необходимости в них. Разработчики могут создавать автономные реляционные базы данных всего за несколько шагов, ускоряя процесс разработки приложений.
§ 2. Работа с таблицами базы данных
Таблица — основной объект базы данных, предназначенный для хранения данных в структурированном виде.
База данных может быть однотабличной, т. е. хранить одну таблицу. При большом количестве объектов с многочисленными свойствами хранение данных в одной таблице может быть неудобным для дальнейшего использования базы данных. В таком случае имеет смысл представить БД в виде нескольких таблиц, связи между которыми устанавливаются с помощью совпадающих полей, т. е. как многотабличную базу данных.
На основе таблиц создаются другие объекты базы данных.
В процессе создания таблиц можно выделить этапы:
1. Создание объекта Таблица (пример 2.1).
2. Описание структуры таблицы — имен полей, типов и свойств данных в них.
3. Ввод данных в таблицу.
Работать с таблицами баз данных можно в двух режимах (пример 2.2).
Описание структуры таблицы (пример 2.3) выполняется в режиме Конструктор (см. Приложение к главе 1).
Данные в таблицу вводятся в режиме Таблица. В этом режиме можно также просматривать и изменять структуру таблицы.
Таблицы в реляционных базах данных должны обладать следующими свойствами:
1. В таблице не может быть двух записей с полностью совпадающими данными.
2. Поля таблицы должны располагаться в порядке, который определяется при ее создании.
3. В таблице обязательно должно быть хотя бы одно поле.
Каждое поле должно иметь уникальное имя (одно в пределах таблицы). Все значения в одном поле имеют один тип (число, текст, дата и т. д.).
Таблица базы данных похожа на электронную таблицу, и в Access реализована возможность импортировать данные из электронных таблиц в БД (пример 2.4).
Пример 2.1. Создание объекта Таблица в Access.
Пример 2.2. Режимы работы с таблицами в Access.
Пример 2.3. Описание структуры таблицы.
Пример 2.4. Импорт таблицы из Excel в Access.
1. На вкладке Внешние данные выбрать Excel:
2. В окне Внешние данные нажать кнопку .
3. В окне Открытие файла выбрать файл с электронной таблицей и подтвердить выбор.
4. В окне Импорт электронной таблицы на каждом шаге сделать требуемый выбор и нажать кнопку Далее.
Например, на втором шаге поставить птичку, если содержимое первой строки импортируемой таблицы будет использоваться в качестве имен полей таблицы базы данных:
По завершении нажать кнопку
2.2. Ввод и редактирование данных в таблице
При создании структуры таблицы в режиме Конструктора таблицы (см. Приложение к главе 1) определяются имена полей (пример 2.5) и настраиваются их свойства — тип и формат.
Изменять имена полей можно как в режиме конструктора, так и в режиме таблицы. Выбирать имена полей следует так, чтобы имя было коротким и отражало смысл данных, хранящихся в поле.
Тип данных должен соответствовать значениям, которые предполагается вводить в поле, и операциям, которые будут выполняться с этими значениями. Для поля может быть определен один из следующих типов:
1. Текстовый. Короткий текст (до 255 символов) и длинный текст.
2. Числовой. Числовые данные (целые или действительные).
3. Дата и время. Дата и/или время.
4. Денежный. Денежные данные, хранящиеся с точностью до 4 десятичных знаков после запятой.
5. Счетчик. Последовательность целых чисел, которые задаются автоматически при вводе записей. Эти числа нельзя изменить.
6. Логический. Может иметь значения Истина или Ложь.
7. Поле объекта OLE. Изображения в формате Точечный рисунок.
8. Гиперссылка. Ссылка на информационный ресурс в Интернете.
9. Вложение. Вложениями могут быть изображения, документы, электронные таблицы, диаграммы и другие файлы.
В таблицах вложение отображается знаком с указанием в скобках количества вложений (пример 2.7). Чтобы увидеть содержимое вложения, необходимо создать форму или отчет.
Поле каждого типа имеет свой набор свойств. Наиболее важными являются:
1. Размер поля (пример 2.8), который определяет максимально возможную длину текста или числа.
2. Формат поля, который устанавливает формат данных (пример 2.9).
Обычно одно из полей таблицы при создании структуры определяется как ключевое поле — ключ (пример 2.10).
Ключ (ключевое поле) — поле, значения которого позволяют однозначно определить каждую запись таблицы.
В таблице не может быть двух записей, имеющих одинаковое значение ключа.
Новая таблица состоит из одной пустой записи (пример 2.11). Ввод данных в таблицу базы производится в Режиме таблицы и мало чем отличается от ввода данных в электронную таблицу. При вводе данных пустая запись смещается в конец таблицы (пример 2.12). Отменить ввод значения в поле до перехода к другому полю можно, нажав клавишу Esc или на панели быстрого доступа.
При заполнении таблиц базы данных нужно соблюдать определенные правила:
1. Заполнение таблиц должно производиться по записям.
2. Вводимые данные должны соответствовать заданному при создании структуры таблицы типу. В случае несоответствия появляется предупреждающее сообщение.
Перед редактированием записей таблицы необходимо их выделить. Для этого достаточно выполнить щелчек в поле маркера соответствующей записи (пример 2.13). Отменяется выделение щелчком в любом месте таблицы вне выделения.
При работе с данными в поле маркера записи таблицы может отображаться один из следующих символов:
1. Звездочка. Обозначает пустую запись в конце таблицы.
2. Карандаш. Обозначает, что запись редактируется.
Завершение ввода значений записи осуществляется при переходе к любой другой записи. Access автоматически сохраняет каждую запись по завершении ее обработки.
Для удаления записи необходимо выполнить команду Удалить запись контекстного меню выделенной записи (пример 2.15).
Для быстрого перемещения между записями можно использовать кнопки панели навигации окна таблицы (пример 2.16).
Пример 2.5. Определение имен полей таблицы.
Имена полей должны быть уникальны и содержать не более 64 символов. Они могут включать любые комбинации букв, цифр пробелов и специальных символов за исключением:
- точки;
- восклицательного знака;
- надстрочного символа;
- прямых скобок.
Имя не должно начинаться с пробела.
Пример 2.6. Определение типа данных в поле таблицы.
Для раскрытия списка типов полей необходимо нажать на кнопку со стрелкой.
Пример 2.7. Тип данных Вложение.
В этой таблице вложениями являются файлы с изображениями памятных монет Республики Беларусь (аверс и реверс).
Пример 2.8. Свойство Размер поля типа данных Числовой.
Пример 2.9. Свойство Формат поля типа данных Денежный.
Пример 2.10. Определение ключевого поля в структуре таблицы.
Для определения поля как ключевого нужно выбрать кнопку:
В качестве ключа чаще всего используют поле, содержащее тип данных Счетчик. Однако иногда удобнее в качестве ключа таблицы использовать другие поля: код товара, инвентарный номер и т. п.
Пример 2.11. Новая таблица.
Пример 2.12. Заполнение таблицы данными в Access.
При вводе данных к следующей ячейке можно перейти при помощи клавиши Enter либо Tab. В обратном направлении — с помощью комбинации клавиш Shift + Tab. Используя комбинацию клавиш Ctrl + Home, можно перейти в первую ячейку таблицы, Ctrl + End — в последнюю.
Пример 2.13. Выделение записи таблицы.
Пример 2.14. Символы в поле маркера.
Пример 2.15. Удаление записи из таблицы.
Пример 2.16. Панель навигации таблицы базы данных.
2.3. Связывание таблиц базы данных
Связи между таблицами многотабличной БД позволяют обеспечить объединение данных нескольких таблиц. Логическая структура базы данных (таблицы и связи между ними) запоминается в Схеме данных.
Связь между таблицами БД осуществляется путем сопоставления данных в полях, по которым связываются таблицы, — полях связи (пример 2.17). Перед созданием связей необходимо закрыть все таблицы. Создавать или изменять связи между открытыми таблицами нельзя.
1. Один ко многим. Каждой записи в одной таблице могут соответствовать несколько записей в другой таблице.
2. Многие ко многим. Каждой записи в одной таблице могут соответствовать несколько записей в другой таблице и наоборот.
3. Один к одному. Каждой записи в одной таблице может соответствовать только одна запись в другой таблице. Обычно это связь между двумя ключевыми полями.
При установлении связи между таблицами поля связи не обязательно должны иметь одинаковые названия. Однако у них должен быть один и тот же тип данных. Исключением является случай, когда ключевое поле относится к типу Счетчик. Поле типа Счетчик можно связать с полем числового типа, если формат данных в этих полях совпадает. Это же правило действует в случае, если оба связываемых поля являются числовыми.
Если после установления связи открыть таблицу, от которой идет связь, то в открывшемся окне видны знаки , расположенные в левой части записей (пример 2.18). Их присутствие говорит о наличии связи ключевого поля таблицы «Города» с другой таблицей. После щелчка на знаке откроется вложенная таблица, содержащая те записи таблицы, значение поля которых равно величине одноименного поля записи таблицы «Города».
Пример 2.17. Создание связи.
1. На вкладке Работа с базами данных выбрать кнопку Схема данных:
Появится диалоговое окно:
2. В окне дважды щелкнуть по названиям таблиц, которые необходимо связать, или щелкнуть по названию таблицы и нажать кнопку Добавить.
3. Закрыть окно Добавление таблицы.
4. Перетащить поле связи из одной таблицы на поле связи в другой.
Часто связывают ключевое поле (выделенное полужирным) одной таблицы с аналогичным полем другой таблицы.
Появится окно Изменение связей:
Убедиться, что в каждом из столбцов этого окна отображаются названия нужных полей. При необходимости их можно изменить.
5. Задать параметры связи:
6. Нажать кнопку .
Пример 2.18. Просмотр данных в связанных таблицах.
2.4. Сортировка данных в таблице
Записи в таблицах автоматически воспроизводятся отсортированными в порядке возрастания по ключевому полю. При работе с базами данных может возникнуть необходимость сортировки данных по какому-либо полю таблицы в определенном порядке:
- По алфавиту, если это поле текстовое.
- По значению числа, если поле числовое.
- По времени, если поле имеет тип Дата и время.
Сортировка может производиться либо по возрастанию, либо по убыванию значений поля. При сортировке целостность данных в записях не нарушается.
Для сортировки данных таблицы в Access выделить любую ячейку поля, по которому сортируются записи, и воспользоваться соответствующими кнопками вкладки Главная группы Сортировка и фильтр (пример 2.20). Для удаления сортировки следует воспользоваться кнопкой Удалить сортировку. Так же для выполнения операций сортировки можно использовать возможности контекстного меню поля.
Пример 2.19. Сортировки по полям с различным типом данных.
1. По полю «Кинотеатр» — по алфавиту, в порядке возрастания.
2. По полю «Стоимость» — по значению, в порядке убывания.
3. По полю «Время» — в порядке убывания.
Пример 2.20. Инструменты сортировки вкладки Главная.
Вопросы к параграфу
1. Какой объект баз данных является основным?
2. В каких режимах можно работать с таблицами базы данных?
3. Какие действия с таблицами баз данных можно производить в режиме Конструктор?
4. В каком режиме работы с таблицами осуществляется ввод данных в таблицу базы данных?
5. Откуда можно импортировать данные в таблицу БД?
6. Какими свойствами должны обладать таблицы БД?
7. Какие типы данных могут быть определены для полей таблицы БД?
8. Что такое ключевое поле таблицы?
9. Как выделить запись? Как удалить запись?
10. Что означают символы звездочка и карандаш, отображаемые в поле маркера?
11. Для чего нужно связывать таблицы?
12. Какие существуют виды связей? Чем они отличаются?
13. Каким образом можно сортировать данные в таблице?
Упражнения
1. Определите типы полей таблицы БД, которая хранит данные об оплате за учебные пособия и содержит поля «Дата», «Номер плательщика», «ФИО», «Наименование учебного заведения», «Номер класса», «Сумма», «Наличие льготы».
2. Определите ключевое поле для таблицы БД, которая хранит данные о выданных аттестатах и включает поля «Фамилия», «Имя», «Отчество», «Дата рождения», «Год выпуска», «Номер аттестата».
3. Выполните перечисленные задания.
1. Создайте базу данных абитуриентов университета, состоящую из двух таблиц.
| № | Конструктор | Режим таблицы |
| 1 |  |
 |
| 2 |  |
 |
2. Свяжите таблицы по ключу таблицы «Город» и полю «Код города» таблицы «Абитуриенты».
3. Определите, сколько абитуриентов поступало из Минска. Для этого откройте таблицу «Города» и разверните данные вложенной таблицы «Абитуриенты».
4. Откройте базу данных «Аренда автомобилей.accdb». Выполните перечисленные задания.
1. Откройте таблицу «Автомобили» в режиме Конструктор. Запишите в тетрадь список полей с указанием типа данных для каждого поля. Для числовых полей запишите формат представления.
2. В режиме таблицы добавьте в таблицу «Автомобили» записи, как показано на рисунке:
Для добавления в запись таблицы файла с изображением автомобиля выполните двойной щелчок в поле с типом данных Вложение и в диалоговом окне нажмите Добавить…
Выберите соответствующий файл с изображением.
3. Создайте таблицу «Арендаторы».
Используйте файл «Арендаторы.xlsx» для импортирования данных. Ключ — поле «Код».
4. Создайте таблицу «Аренда».
| Конструктор | Режим таблицы |
 |
 |
5. Отсортируйте записи в таблице «Автомобили» по возрастанию стоимости.
5. Установите связи вида Один ко многим между таблицами базы данных «Аренда автомобилей.accdb». Обеспечьте целостность связей.
Тест. 11 кл. по теме «База данных как модель предметной области»
Внимание! Все тесты в этом разделе разработаны пользователями сайта для собственного использования. Администрация сайта не проверяет возможные ошибки, которые могут встретиться в тестах.
Тест. 11 кл. по теме «База данных как модель предметной области»
Система оценки: 5* балльная
Список вопросов теста
Вопрос 1
Определенная БД включает в себя совокупность данных:
Варианты ответов
- одной предметной области;
- разных предметных областей
- не связанных между собой
- связанных между собой в некотором контексте
Вопрос 2
Данные в реляционной БД представлены в виде:
Варианты ответов
- иерархической модели
- табличной модели
- сетевой модели
- графа
Вопрос 3
Варианты ответов
- совокупность столбцов, содержащих однотипные данные;
- строка таблицы, содержащая набор значений свойств;
- столбец таблицы, содержащий значения определенного типа
- отдельная таблица, входящая в состав базы данных
Вопрос 4
Ниже приведены фрагменты таблиц базы данных учеников школы:
В каком классе наибольший рост у самого низкого ученика в классе?
Варианты ответов
Вопрос 5
База данных службы доставки состоит из двух связанных таблиц:
Каков общий вес товаров, которые курьер должен доставить на ул. Полевая?
Варианты ответов
- 1500 грамм
- 1900 грамм
- 3750 грамм
- 1300 грамм
Вопрос 6
В фрагменте базы данных представлены сведения о родственных отношениях. Определите на основании приведѐнных данных фамилию и инициалы тѐти Петровой И.Б. (тѐтей считается сестра отца или матери).
Варианты ответов
- Острова А.А.
- Кузьминых Л.М.
- Петрова Я.М.
- Власова А.Г.
Вопрос 7
База данных – это:
Варианты ответов
- организованная совокупность данных некоторой предметной области, хранящейся во внешней памяти;
- организованная совокупность данных некоторой предметной области, представленная в табличном виде;
- организованная совокупность данных некоторой предметной области, представленная в электронной таблице;
- неорганизованная совокупность данных некоторой предметной области, хранящейся во внешней памяти
Вопрос 8
В реляционных БД используются:
Варианты ответов
- данные, находящиеся в одной таблице;
- таблицы, между которыми устанавливаются связи;
- списки однородных данных;
- списки неоднородных данных
Вопрос 9
Запись базы данных – это:
Варианты ответов
- совокупность строк, содержащих однотипные данные;
- строка таблицы, содержащая набор значений свойств, размещенных в полях БД;
- столбец таблицы, содержащий значения определенного типа;
- отдельная таблица, входящая в состав БД.
Вопрос 10
Ниже приведены фрагменты таблиц базы данных канцелярского магазина:
Сколько разных (по названию) красных изделий продается в магазине?
В ответе введите только число.
Пособие для студентов Модуль 3
Базы данных могут содержать различные объекты, но основными объектами любой базы данных являются таблицы. Простейшая база данных имеет хотя бы одну таблицу. Даже если таблица не содержит данных, она уже содержит информацию – это информация о структуре таблицы. Структура таблицы определяет методы занесения данных и хранения их в базе данных. Таблицы базы данных создаются таким образом, чтобы каждая из них содержала информацию об одном информационном объекте. Не следует сводить в одну таблицу данные, относящиеся к разным информационным объектам.
После создания различных таблиц, содержащих данные, относящиеся к различным информационным объектам базы данных, между этими таблицами должны быть установлены реляционные связи. Установка таких связей делает возможным выполнение одновременной обработки данных из нескольких таблиц. Для установки связей обычно используют ключевые поля таблиц.
Первичный ключ реляционной таблицы – это поле или группа полей, которые позволяют однозначно определить каждую строку в таблице. Первичный ключ должен обладать двумя свойствами:
- однозначная идентификация записи – запись должна однозначно определяться значением ключа;
- отсутствие избыточности – никакое поле нельзя удалить из ключа, не нарушая при этом свойства однозначной идентификации записи.
Если первичный ключ состоит из одного поля, то он называется простым ключом или ключевым полем. Если первичный ключ состоит из нескольких полей, то такая таблица базы данных имеет составной ключ.
Чтобы связать две реляционные таблицы, необходимо ключ одной связываемой таблицы ввести в состав ключа другой связываемой таблицы (возможно совпадение ключей) или ввести в структуру одной таблицы внешний ключ, т.е. поле, не являющееся ключевым в первой таблице, но являющееся ключевым во второй.
Пример. Рассмотрим базу данных «Деканат», состоящую из трех таблиц: СТУДЕНТ, СЕССИЯ, СТИПЕНДИЯ, имеющих показанную ниже структуру.
Номер личного дела
В этой таблице ключевым полем является поле Номер личного дела, оно однозначно определяет каждую запись (строку) таблицы, т.к. не существует двух или более личных дел с одинаковыми номерами.
Номер личного дела
В столбце Результат содержатся числа 0, 1 или 2 в зависимости от того, получает ли студент стипендию по результатам сессии (0 – студент не получает стипендию, 1 – обычная стипендия, 2 – увеличенная в 2 раза стипендия). В этой таблице ключевым полем также является поле Номер личного дела.
Эта таблица содержит информацию о проценте начисляемой студенту стипендии в зависимости от результата сдачи сессии. В этой таблице ключевым является поле Результат.
Для наглядности представления связей между таблицами перейдем к представлению таблиц в виде структур этих таблиц, т.е. будем указывать только имена полей таблиц. Итак, наша база данных содержит три таблицы (рис. 6).
Рис. 6. Пример реляционной структуры данных.
Таблицы СТУДЕНТ и СЕССИЯ имеют совпадающие первичные ключи (Номер личного дела), что дает возможность легко организовать связь между ними. Таблица СЕССИЯ имеет первичный ключ Номер личного дела и содержит внешний ключ Результат, который обеспечивает ее связь с таблицей СТИПЕНДИЯ.
Будем говорить, что некоторая запись таблицы А связана с некоторой записью таблицы В, если в обеих таблицах эти записи содержат одно и то же значение в поле, по которому установлена связь между таблицами.
Различают три типа связей (отношений) между таблицами реляционной базы данных:
- отношение «один-к-одному» (1 — 1)
- отношение «один-ко-многим» (1 — М)
- отношение «многие-ко-многим» (М — М)
Говорят, что таблицы А и В находятся в отношении «один-к-одному», если каждая запись в таблице А может иметь не более одной связанной с ней записи в таблице В и наоборот, каждая запись в таблице В может иметь не более одной связанной с ней записи в таблице А.
В этом случае для связи используются ключевые поля связываемых таблиц. Этот тип связи используется достаточно редко, т.к. в этом случае данные двух таблиц могут быть объединены в одну таблицу. Можно указать следующие причины, по которым все-таки выполняется разбиение одной таблицы на несколько таблиц, связанных отношением «один-к-одному»:
- разделение очень «широкой» таблицы на несколько таблиц с целью облегчения работы;
- отделение части таблицы по соображениям защиты ее от несанкционированного доступа.
Рассмотренные ранее таблицы СТУДЕНТ и СЕССИЯ находятся в отношении «один-к-одному» (иначе говоря, между таблицами установлена связь типа «один-к-одному») (рис. 7).
Рис. 7. Пример таблиц, находящихся в отношении «один-к-одному».
Говорят, что таблицы А и В находятся в отношении «один-ко-многим», если каждая запись в таблице А может быть связана с несколькими записями таблицы В, но каждая запись в таблице В не может быть связана более чем с одной записью таблицы А. Таблица А в этом случае называется главной таблицей, а таблица В – подчиненной.
В этом случае для связи используется поле, которое является первичным ключом таблицы, находящейся на стороне отношения «один» (таблица А), и являющееся внешним ключом в таблице, находящейся на стороне отношения «многие» (таблица В).
Например, рассмотренные ранее таблицы СТИПЕНДИЯ и СЕССИЯ находятся в отношении «один-ко-многим» (рис. 8). При этом на стороне «один» находится таблица СТИПЕНДИЯ, а на стороне «многие» – таблица СЕССИЯ. Связь устанавливается по полю Результат. Каждая запись таблицы СТИПЕНДИЯ может иметь много связанных с ней записей в таблице СЕССИЯ, иначе говоря, в таблице СЕССИЯ может быть много строк с заданным значением в поле Результат (например, со значением 1). В то же время, если взять любую строку в таблице СЕССИЯ, то для нее найдется не более одной строки в таблице СТИПЕНДИЯ с таким же значением в поле Результат.
Рис. 8. Пример таблиц, находящихся в отношении «один-ко-многим».
Говорят, что таблицы А и В находятся в отношении «многие-ко-многим», если каждая запись таблицы А может быть связана с несколькими записями в таблице В, и наоборот, каждая запись таблицы В может быть связана с несколькими записями в таблице А.
Такая связь всегда реализуется с помощью третьей (связующей) таблицы. Примером могут служить таблицы Читатели и Книги (рис. 9). Связь между ними организуется посредствам таблицы Абонемент.
Рис. 9. Пример таблиц, находящихся в отношении «многие-ко-многим».
Каждой записи в таблице Читатели могут соответствовать несколько записей в таблице Книги, и наоборот, каждая запись таблицы Книги может иметь более одной соответствующей ей записи в таблице Читатели. Соответствие устанавливается с помощью таблицы абонемент. При этом между таблицами ЧИТАТЕЛИ и АБОНЕМЕНТ установлено отношение «один-ко-многим», в котором таблица ЧИТАТЕЛИ является главной, а таблица АБОНЕМЕНТ – подчиненной. Аналогично между таблицами КНИГИ и АБОНЕМЕНТ установлено отношение «один-ко-многим», в которой таблица КНИГИ является главной.