Для таблицы реляционной базы данных справедливо что
Экспресс-подготовка к онлайн-тестированию:
для студентов дистанционного обучения, при устройстве на работу, прохождении аттестаций
Сдаешь тесты самостоятельно?
Закажи скайп-консультацию и узнай все секреты успешной сдачи экзаменов онлайн!
Базы данных Тесты с ответами ИММиФ Тема 1-4
Для быстрого поиска по странице нажмите Ctrl+F и в появившемся окошке напечатайте слово запроса (или первые буквы)
ТЕМА 1
Подсистема бухгалтерского учета относится к:
экономической подсистеме ИС
обеспечивающей подсистеме ИС
информационной подсистеме ИС
+функциональной подсистеме ИС
Предметная область – это:
БД, разработанная для решения конкретной задачи
модель «сущность – связь», отражающая заданную область внешнего мира
+часть реального мира, представляющая интерес для данного исследования
ER-диаграмма, отражающая заданную область внешнего мира
Программное обеспечение относится к:
информационной подсистеме ИС
функциональной подсистеме ИС
+обеспечивающей подсистеме ИС
экономической подсистеме ИС
Описание структуры единиц информации, хранящихся в БД, представляет собой:
логическую схему БД
модель «сущность – связь»
ТЕМА 2
Банк данных включает компоненты:
СУБД, базы данных, администрация банка данных, словарь данных, вычисли-тельная и операционная системы
базы данных и персонал банка данных
+базы данных, СУБД, вычислительная система, словарь данных, персонал банка данных
Банк данных – это:
+система баз данных и программных, технических, языковых, организационно-методических средств
система баз данных
специальные языковые и программные средства для создания баз данных
система программных, технических, языковых, организационно-методических средств
Для разработки и эксплуатации баз данных используются:
+системы управления базами данных
системы автоматизированного проектирования
Какой компонент банка данных является его ядром?
Словарь данных – это:
централизованное хранилище полей БД
централизованное хранилище языковых средств БД
централизованное хранилище данных
+централизованное хранилище метаинформации
СУБД – это:
+специальный программный комплекс для обеспечения доступа к данным и управления ими
система средств архивирования и резервного копирования банка данных
система средств администрирования банка данных
система средств управления транзакциями
Транзакция – это:
+последовательность операторов манипулирования данными
операция модификации данных
средство защиты от несанкционированного доступа
запись в журнале о сбое в работе БД
ТЕМА 3
Визуальная система – это система, в которой хранится:
+текстовая, графическая и видео информация
графическая и видео информация
Если в СУБД используется универсальный язык программирования, то она называется:
Если СУБД позволяет вычислять агрегированные показатели, то она называется:
Компьютерная база данных – это:
любой набор данных, хранящихся в компьютерной системе
+совокупность структурированных данных, описывающих какую-либо предметную область
произвольный набор файлов данных
Электронный словарь представляет собой:
ТЕМА 4
В какой модели данных основным элементом является таблица?
Деревья – это:
+нелинейные структуры данных
линейные структуры данных
структуры данных общего типа
способ представления неструктурированных данных
Запись – это:
+одна строка реляционной таблицы
строка заголовка реляционной таблицы
один столбец реляционной таблицы
Как исключить наличие повторяющихся записей в таблице?
проиндексировать поля таблицы
определить внешний ключ
упорядочить строки таблицы
+определить ключевое поле
Кардинальность – это:
количество первичных ключей в таблице
количество столбцов в таблице
количество значений в таблице
+количество строк в таблице
Могут ли в реляционной таблице присутствовать полностью идентичные записи?
могут, если таблица связана с другими таблицами базы данных
Первичный ключ – это:
атрибут, находящийся в левом столбце таблицы
первая запись таблицы
+атрибут, значение которого однозначно идентифицирует запись
Реляционная модель данных основана:
на древовидных структурах
на иерархических списках
Сетевые структуры – это:
структуры данных общего типа
линейные структуры данных
+нелинейные структуры данных
способ представления неструктурированных данных
Степень отношения – это:
количество значений в таблице
+количество столбцов в таблице
количество первичных ключей в таблице
количество строк в таблице
Основы реляционных баз данных
Базы данных всегда являлись краеугольным камнем любого цифрового бизнеса. Поэтому программная индустрия всегда уделяла так много внимания системам управления базами данных.
Реляционная база данных – это коллекция таблиц, организованная согласно реляционной модели. Каждая ячейка этих таблиц имеет соответствующее формальное описание.
Использование реляционной модели означает, что любой элемент данных может быть идентифицирован при помощи двух уникальных идентификаторов, одним из которых является имя столбца, а другим – содержимое ячеек специального столбца, называемого первичным ключом ( primary key ).
Используя внешние ключи ( foreign keys ), можно установить логическую связь между строками и ячейками разных таблиц.
Организация идеальной реляционной базы данных подразумевает нормализацию данных, то есть исключение повторяющихся или заведомо пустых ячеек при помощи разделения данных на разные таблицы.
Вышеприведённых абзацев вполне хватит, чтобы получить представление о теоретических основах организации реляционных баз данных. Но для настоящего понимания предмета сухой теории недостаточно. Поэтому далее в нашей статье мы попробуем спроектировать базу данных для небольшого приложения.
Данные
Наша база данных будет состоять из двух таблиц: “ Student ” ( студенты ) и “ Class ” ( предметы ), и содержать в себе информацию, соответственно, о студентах и изучаемых ими предметах.
Каждый студент будет обозначен уникальным буквенно-цифровым идентификатором. Остальные данные, относящиеся к студенту – имя и фамилия, операционная система, предмет и преподаватель – могут повторяться. Один преподаватель может учить нескольким предметам.
С учётом этой информации нормализуем данные следующим образом:
1. Таблица студентов будет иметь следующие поля:
2. Таблица предметов будет иметь следующие поля:
Теперь заполним обе таблицы данными:
Отношения между объектами
Теперь, используя имеющиеся данные, определим отношения и объекты этих отношений.
Объектами, очевидно, будут являться студенты и предметы. Отношения между ними заключаются в том, что каждый студент изучает один или несколько предметов.
Атрибуты отношений: первичные и внешние ключи
Теперь, когда отношения между объектами ясны, определим атрибуты, которые мы будем использовать для сопоставления объектов друг другу.
Такими атрибутами должны выступать ячейки с уникальным содержимым. В наших таблицах как раз имеется по одному столбцу с уникальными данными.
В таблице студентов у нас есть идентификатор студента, а в таблице предметов – идентификатор предмета. Эти ячейки и называются первичными ключами.
Первичный ключ идентифицирует каждую строку в таблице.
Для установления отношения мы должны сопоставить каждому первичному ключу внешний ключ.
Внешний ключ должен представлять собой первичный ключ другой таблицы. В нашем случае внешний ключ может использоваться для составления особой таблицы – таблицы перекрёстных ссылок. Давайте назовём эту таблицу таблицей зачислений ( enrollment ).
Каждая строка этой таблицы зачислений будет связывать два внешних ключа между собой:
Использование таблицы перекрёстных ссылок
Теперь, когда мы определились с ключами и отношениями, мы можем заполнить таблицу перекрёстных ссылок данными об объектах и их зависимостях.
Каждая строка получившейся таблицы однозначно определяется собственным первичным ключом – идентификатором зачисления ( Enrollment ID ).
Кроме первичного ключа, таблица содержит ещё два поля:
Заключение
В нашей сегодняшней статье мы изучили принципы организации реляционных баз данных. Слово « реляционные » можно определить как « характеризуемые отношениями », от латинского слова “ relatio ” – « отношение ».
Отношения, о которых мы говорили, определяются связями между таблицами базы данных и проявляются как ограничения, накладываемые на допустимый диапазон значений связанных ячеек. Эти ограничения позволяют нормализовать данные, то есть избавиться от ненужных повторений, и связать отдельные таблицы в одно целое.
Как же применить изученные нами примеры на практике?
Я постараюсь вскоре представить вам эту новую статью. Но надеюсь, что и сегодняшний материал был вам полезен, и прошу вас поделиться своими мыслями и замечаниями в комментариях.
Реляционные базы данных
Основной объект реляционной базы данных — таблица. Любая подобная таблица именуется реляционной таблицей или отношением. У неё имеются определённые характеристики:
Самые значимые структурные элементы в реляционной таблице — это поле и запись.
Поле и запись
Поле, по-другому столбец таблицы — это элементарная единица логической организации информации, которая соотносится с определённым атрибутом сущности.
Запись, по-другому строка таблицы — это набор полей с логической связью, который соответствует определённому экземпляру сущности. Допустим, на следующем рисунке в формате реляционной таблицы проиллюстрированы данные о самых крупных озёрах мира.
Для лучшей визуализации связей между таблицами применяют представление структур таблиц, указывая лишь наименования полей:
К примеру, структура таблицы, которая была представлена ранее, будет иметь такой вид:
Ключи и ключевые поля
Первичный ключ или идентификатор реляционной таблицы — это поле или несколько полей, однозначно идентифицирующих всякую строку или запись в таблице.
Главные характеристики первичного идентификатора:
1) Однозначная идентификация записи;
2) Отсутствие переизбытка, так как избавление от всякого поля первичного ключа приведёт к нарушению первого свойства.
Простым ключом или ключевым полем именуют ключ, который содержит в себе единственное поле. Составным называют ключ, если в него входит множество полей.
В таблице о крупных озёрах, представленной ранее, в качестве ключевого может применяться поле «Название», ведь значения в нём считаются уникальными для каждой записи, так как все крупные озёра имеют собственные названия.
Для того чтобы хранить информацию о сущностях конкретной предметной области можно использовать множество взаимосвязанных таблиц. Взаимосвязь между ними учреждается с использованием ключевых полей.
Связи в реляционных таблицах
Две реляционные таблицы можно соединить между собой, если ключ одной внести в состав ключа другой. Ключевое поле одной из таблиц можно внести в систему другой, однако, тогда оно теряет статус ключевого. Подобное поле именуют внешним ключом.
Между таблицами А и В учреждается связь 1:1, если всякая запись в таблице А может иметь не больше одной взаимосвязанной с ней записи в таблице В. Верное и обратное: всякая запись в таблице В способен иметь не больше одной взаимосвязанной с ней записи в таблице А.
Связь вида 1:1 устанавливается между таблицами, если она учреждена по совпадающим первичным ключам.
Таблицы «Ученик» и «Учебный год» взаимосвязаны по типу 1:1. Тогда выполняется совпадение ключей.
Между таблицами «Поощрение» и «Учебный год» описана взаимосвязь 1:М. Тогда ключевое поле связываемой таблицы «Поощрение» внесено в структуру таблицы «Учебный год» так, что в ней оно теряет статус ключевого и рассматривается в качестве внешнего ключа. В рамках этой связи таблица, в которой содержится первичный ключ, именуется главной, а в которой содержится внешний ключ — подчинённой.
Между таблицами А и В учреждается связь М:М, когда всякой записи таблицы А может ставиться в соответствие множество записей в таблице В. Так же и всякой записи таблицы В может ставиться в соответствие множество записей в таблице А.
Подобная связь всегда оформляется с применением дополнительной связующей таблицы С. Связь М:М представляет комбинацию двух связей формы 1:М: между таблицами А и С и таблицами В и С.
Допустим, связь между таблицами «Читатель» и «Книга» базы данных «Библиотека» можно реализовать с использованием таблица «Абонемент».
Для таблицы реляционной базы данных справедливо что
По Вашему запросу ничего не найдено.
Рекомендуем сделать следующее:
Что такое реляционная база данных?
Реляционные базы данных представляют собой базы данных, которые используются для хранения и предоставления доступа к взаимосвязанным элементам информации. Реляционные базы данных основаны на реляционной модели — интуитивно понятном, наглядном табличном способе представления данных. Каждая строка, содержащая в таблице такой базы данных, представляет собой запись с уникальным идентификатором, который называют ключом. Столбцы таблицы имеют атрибуты данных, а каждая запись обычно содержит значение для каждого атрибута, что дает возможность легко устанавливать взаимосвязь между элементами данных.
Пример реляционной базы данных
В качестве примера рассмотрим две таблицы, которые небольшое предприятие использует для обработки заказов продукции. Первая таблица содержит информацию о заказчиках: каждая запись в ней включает в себя имя и адрес заказчика, платежные данные и информацию о доставке, номер телефона и т. д. Каждый элемент информации (атрибут) помещен в отдельный столбец базы данных, которому назначен уникальный идентификатор (ключ) для каждой строки. Во второй таблице—(с информацией о заказе) каждая—запись содержит идентификатор заказчика, совершившего заказ, название заказанного продукта, его количество, размер или цвет и т. д. Записи в этой таблице не содержат таких данных, как имя заказчика или его контактные данные.
У обеих таблиц есть только один общий элемент — идентификатор столбца (ключ). Благодаря наличию этого общего столбца реляционные базы данных могут устанавливать взаимосвязи между двумя таблицами. Когда приложение для обработки заказов передает заказ в базу данных, база данных обращается к таблице со сведениями о заказах, извлекает сведения о продукции и использует идентификатор заказчика из этой таблицы, чтобы найти сведения об оплате и доставке в таблице с информацией о нем. Затем на складе подбирают нужный продукт, заказчик своевременно получает свой заказ и производит оплату.
Структура реляционных баз данных
Реляционная модель подразумевает логическую структуру данных: таблицы, представления и индексы. Логическая структура отличается от физической структуры хранения. Такое разделение дает возможность администраторам управлять физической системой хранения, не меняя данных, содержащихся в логической структуре. Например, изменение имени файла базы данных не повлияет на хранящиеся в нем таблицы.
Разделение между физическим и логическим уровнем распространяется в том числе на операции, которые представляют собой четко определенные действия с данными и структурами базы данных. Логические операции дают возможность приложениям определять требования к необходимому содержанию, в то время как физические операции определяют способ доступа к данным и выполнения задачи.
Чтобы обеспечить точность и доступность данных, в реляционных базах должны соблюдаться определенные правила целостности. Например, в правилах целостности можно запретить использование дубликатов строк в таблицах, чтобы устранить вероятность попадания неправильной информации в базу данных.
Реляционная модель
В первых базах данных данные каждого приложения хранились в отдельной уникальной структуре. Если разработчик хотел создать приложение для использования таких данных, он должен был хорошо знать конкретную структуру, чтобы найти необходимые данные. Такой метод организации был неэффективен, сложен в обслуживании и затруднял оптимизацию эффективности приложений. Реляционная модель была разработана, чтобы устранить потребность в использовании разнообразных структур данных.
Она обеспечила стандартный способ представления данных и отправки запросов, которые могли быть использованы в любых приложениях. Разработчики уяснили, что таблицы являются ключевым преимуществом реляционных баз данных, так как обеспечивают интуитивно понятный, эффективный и гибкий способ хранения структурированной информации и получения к ней доступа.
Со временем, когда разработчики стали использовать язык структурированных запросов (SQL) для записи данных в базу и отправки запросов, стало очевидным и другое преимущество реляционной модели. Вот уже на протяжении многих лет SQL широко используется в качестве языка запросов в базах данных. Он основан на алгоритмах реляционной алгебры и четкой математической структуре, что обеспечивает простоту и эффективность при оптимизации любых запросов к базе данных. Для сравнения: при использовании других подходов приходится создавать отдельные, уникальные запросы.
Преимущества реляционных баз данных
Компании всех типов и размеров используют простую, но функциональную реляционную модель для обслуживания разнообразных информационных потребностей. Реляционные базы данных применяются для отслеживания товарных запасов, обработки торговых транзакций через Интернет, управления большими объемами критически важных данных заказчиков и т. д. Реляционные базы данных можно рекомендовать для обслуживания любых информационных потребностей, где элементы данных связаны между собой и необходимо обеспечивать безопасное и надежное управление ими на основе правил целостности.
Реляционные базы данных появились в 1970-х годах. На сегодняшний день преимущества реляционного подхода сделали его самой распространенной моделью для баз данных в мире.
Целостность данных
Реляционная модель наиболее эффективно поддерживает целостность данных во всех приложениях и копиях (экземплярах) базы данных. Например, когда заказчик кладет деньги на счет с помощью банкомата, а затем проверяет баланс на мобильном телефоне, он ожидает, что поступившие средства сразу же отобразятся на счете. Реляционные базы данных отлично подходят для обеспечения целостности данных в различных экземплярах базы в одно и то же время.
Другие типы баз данных не могут одновременно поддерживать целостность больших объемов данных. Некоторые современные типы баз данных, такие как NoSQL, обеспечивают только так называемую “окончательную целостность.” Это значит, что, когда выполняется масштабирование данных или несколько пользователей одновременно используют одни и те же данные, необходимо некоторое время на “внесение изменений”. В некоторых случаях окончательная целостность вполне приемлема (например, для обновления позиций в товарном каталоге), однако для критически важной операционной деятельности бизнеса (например, транзакций с использованием корзины) реляционные базы представляют собой фундаментальный стандарт.
Фиксация изменений и атомарность
В реляционных базах данных используются очень детальные и строгие бизнес-правила и политики в отношении фиксации изменений в базе данных (то есть сохранения изменений в данных на постоянной основе). Рассмотрим для примера складскую базу данных, в которой отслеживаются три запчасти, всегда использующиеся в комплекте. Когда одну из них извлекают из товарных запасов, две другие также должны извлекаться. Если одна из трех запчастей недоступна, две другие также не могут быть проданы отдельно, то есть, чтобы в базу данных можно было внести изменения, должны быть доступны все три запчасти. Реляционная база данных не разрешит сохранять изменения, если они не касаются всех трех запчастей. Эту особенность реляционных баз данных называют атомарностью или неразрывностью. Неразрывность необходима для сохранения точности данных в базе и обеспечения соответствия с правилами, нормативными положениями и бизнес-политиками.
Реляционные базы данных и ACID
Транзакции в реляционной базе данных имеют четыре важные характеристики: неразрывность (atomicity), целостность (consistency), изолированность (isolation) и неизменность (durability). Это сочетание получило название ACID.
Хранимые процедуры и реляционные базы данных
Доступ к данным включает в себя множество повторяющихся действий. Например, иногда для получения нужного результата простой запрос для получения информации из таблицы необходимо повторить сотню или тысячу раз. Для таких сценариев доступа к базе данных необходимо что-то вроде программного кода. Разработчикам каждый раз писать стандартный код доступа к данным для нового приложения было бы утомительно. К счастью, реляционные базы данных поддерживают хранимые процедуры, представляющие собой блоки кода, к которым можно получить доступ с помощью обычного вызова со стороны кода приложения. Например, одну и ту же хранимую процедуру можно использовать для последовательной маркировки записей в целях удобства пользователей для различных приложений. Хранимые процедуры также помогают разработчикам убедиться в правильной реализации определенных функций данных в приложении.
Блокировки базы данных и параллельный доступ
Когда несколько пользователей или приложений пытаются одновременно изменить одни и те же данные, это может вести к возникновению конфликта в базе. Блокировки и параллельный доступ снижают вероятность конфликтов и способствуют сохранению целостности данных.
Блокировка не разрешает другим пользователям и приложениям получать доступ к данным во время их обновления. В некоторых базах данных блокировка может применяться к целой таблице, что негативно отражается на эффективности приложения. В других типах баз данных, например реляционных базах Oracle, блокировка выполняется на уровне одной записи, оставляя другие записи в таблице доступными. Такой подход помогает сохранить эффективность приложения.
Инструмент параллельного доступа используется, когда несколько пользователей или приложений пытаются одновременно выполнить запросы к одной базе данных. Он обеспечивает доступ пользователей и приложений к базе данных в соответствии с политиками контроля.
Характеристики, на которые следует обратить внимание при выборе реляционной базы данных
Программное обеспечение, которое используется для сохранения, контроля и извлечения данных в базе, а также выполнения к ней запросов, называют системой управления реляционной базой данных (СУРБД). СУРБД обеспечивает интерфейс между пользователями и приложениями и базой данных, а также административные функции для управления хранением данных, их эффективностью и доступом к ним.
При выборе типа базы данных и продуктов на основе реляционных баз данных необходимо учитывать несколько факторов. Выбор СУРБД зависит от потребностей Вашей компании. Задайте себе следующие вопросы.
Реляционная база данных будущего: автономная база данных
На протяжении последних лет реляционные базы данных улучшали свою производительность, надежность и безопасность и становились проще в обслуживании. Однако их структура становилась все более сложной, и, как следствие, администрирование такой базы данных начало требовать немалых усилий. Вместо того, чтобы использовать свои навыки для разработки инновационных приложений, которые будут приносить прибыль компании, разработчики вынуждены посвящать львиную долю времени управлению базой данных для оптимизации ее эффективности.
Мы использовали автономные технологии, чтобы расширить возможности реляционной модели и создать реляционную базу данных нового типа. Самоуправляемая база данных (которую также называют автономной) сохраняет все преимущества и возможности реляционной модели и добавляет к ним средства на основе искусственного интеллекта, машинного обучения и автоматизации для мониторинга и оптимизации скорости выполнения запросов и управления. Например, чтобы улучшить скорость выполнения запросов, самоуправляемая база данных строит прогнозы и проверяет индексы, а затем применяет лучшие результаты на практике — и все это без участия администратора. Самоуправляемые базы данных постоянно вносят такие улучшения в собственную работу без человеческого вмешательства.
Автономные технологии дают возможность разработчикам больше не тратить время на рутинные задачи обслуживания. Например, больше не нужно заблаговременно определять требования к инфраструктуре. При использовании решения IaaS Вы арендуете ресурсы, например вычислительные мощности или хранилище, получаете доступ к нужным ресурсам по мере необходимости и платите только за те из них, которые использует Ваша компания. Разработчики могут создавать автономные реляционные базы данных всего за несколько шагов, ускоряя процесс разработки приложений.