Реляционная база данных состоит из: Базы данных — Урок 3. Реляционные базы данных

Содержание

Структура реляционной базы данных | Основы реляционных баз данных

PostgreSQL — СУБД, созданная для работы с реляционными базами данных. Понятие «реляционная» мы рассмотрим в уроке, посвященном реляционной модели, а сейчас сосредоточимся на её прикладных аспектах. В этом уроке обзорно рассказывается о том, как устроены базы данных, а уже начиная со следующего, мы начнём создавать базу собственными руками.

Данные в реляционных базах данных представлены в табличном виде и хранятся в таблицах. Такая структура очень напоминает Microsoft Excel. Каждая строка в такой таблице — это связанный набор данных, относящийся к одному предмету.

Разные таблицы предназначены для хранения информации о различных предметах: например, пользователи, статьи или заказы в интернет-магазине. В типичных веб-приложениях таблиц десятки и сотни. В больших — тысячи. На Хекслете их несколько сотен.

У таблиц в базе данных есть определённая структура, которая включает в себя фиксированный набор столбцов (говорят: «полей»). Поля расположены в строго определённом порядке, и каждое поле имеет своё уникальное имя в рамках одной таблицы. Кроме того, у таблицы есть имя, которое, как правило, уникально в рамках одной базы данных. Имя таблицы и её структура задаются при создании, но могут быть изменены впоследствии.

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

Число строк в таблице переменно — оно отражает текущее количество находящихся в ней данных. В отличие от таблиц в Exсel, в таблицах реляционных баз данных нет никаких гарантий относительно порядка строк в таблице. Он может быть любым. При необходимости этот порядок можно задать с помощью языка SQL, который рассматривается далее по курсу.

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

Пример описания таблицы с именем users (на псевдоязыке):

Структура

users

first_name string
last_name  string
email      string
created_at datetime

Содержание

| first_name | last_name |       email       | created_at |
|------------|-----------|-------------------|------------|
| Сергей     | Петров    | [email protected]    | 11.10.2005 |
| Иван       | Сидоров   | [email protected] | 03.08.2000 |
| Виктор     | Курганов  | [email protected]  | 23.12.2011 |

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

Именование таблиц и полей в базе (и других сущностей) не фиксировано и зависит от программиста. В проектах, активно использующих ORM (название группы фреймворков или библиотек, которые помогают моделировать предметную область и связывать её с базой данных), имена определяются соглашениями конкретной экосистемы. В этом курсе я использую именование, принятое во фреймворке Rails и его ORM (ActiveRecord). Оно состоит из нескольких правил:

Все имена в нижнем регистре
Для имён, состоящих из нескольких слов, используется snake_case
Имя таблицы во множественном числе

В отличие от Excel, где ввод данных и отображение происходит визуально, в обычных СУБД данные не имеют никакого представления. Вводятся они с помощью команд и выбираются тоже, а вот дальше, всё зависит от программистов, которые выводят эти данные в своих программах. Но существуют специальные клиенты, предназначенные для удобного визуального управления базами данных. Можно сказать, что это «psql на стероидах».

Эти решения бывают как платные, так и бесплатные. Из бесплатных, в мире PostgreSQL, наиболее популярен PgAdmin. Рекомендую поставить его и поэкспериментировать внутри.

SQL

Управление структурой базы данных и данными внутри таблиц — две разных задачи, выполняющиеся одним инструментом — языком SQL. SQL (Structured Query Language) — специализированный язык, разработанный для управления данными в реляционных СУБД.

SELECT * FROM users;

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

С его помощью выполняются практически все задачи внутри СУБД: начиная с управления ролями и правами для них, заканчивая обновлением данных в таблицах конкретных баз данных. Даже создание базы данных выполняется с помощью SQL. SQL-запрос может быть как простым, так и очень сложным. Вряд ли существуют люди, которые знают его на 100%, но некоторый базис должны понимать все прикладные программисты.

Самостоятельная работа

Что такое реляционная база данных?

Реляционная база данных — это связанная информация, представленная в виде двумерных таблиц. Представьте себе адресную книгу. Она содержит множество строк, каждая из которых соответствует данному индивидууму. Для каждого из них в ней представлены некоторые независимые данные, например, имя, номер телефона, адрес. Представим такую адресную книгу в виде таблицы, содержащей строки и столбцы. Каждая строка (называемая также записью) соответствует определенному индивидууму, каждый столбец содержит значения соответствующего типа данных: имя, номер телефона и адрес, представленных в каждой строке. Адресная книга может выглядеть таким образом:

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

Установление связи между таблицами

Давайте используем пример адресной книги для того, чтобы обсудить базу данных, которую можно реально использовать в деловой жизни. Предположим, что индивидуумы первой таблицы являются пациентами больницы. Дополнительную информацию о них можно хранить в другой таблице. Столбцы второй таблицы могут быть поименованы таким образом: Patient (Пациент), Doctor (Врач), Insurer (Страховка), Balance (Баланс).

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

Предположим, Dr.Halben желает получить номера телефонов всех своих Пациентов. Для того чтобы извлечь эту информацию, он должен связать таблицу с номерами телефонов пациентов (адресную книгу) с таблицей, определяющей его пациентов. В данном простом примере он может мысленно проделать эту операцию и узнать телефонные номера своих пациентов Grillet и Brock, в действительности же эти таблицы вполне могут быть больше и намного сложнее.

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

Порядок строк произволен

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

Рассмотрим вторую таблицу. Содержащуюся в ней информацию иногда удобно рассматривать упорядоченной по имени, иногда — в порядке возрастания или убывания баланса (Balance), а иногда — сгруппированной по доктору. Внушительное множество возможных порядков строк помешало бы пользователю проявить гибкость в работе с данными, поэтому строки предполагаются неупорядоченными. Именно по этой причине вы не можете просто сказать: «Меня интересует пятая строка таблицы». Независимо от порядка включения данных или какого-либо другого критерия, этой пятой строки не существует по определению. Итак, строки таблицы предполагаются расположенными в произвольном порядке.

Идентификация строк (первичный ключ)

По этой и ряду других причин, необходимо иметь столбец таблицы, который однозначно идентифицирует каждую строку. Обычно этот столбец содержит номер, например, приписанный каждому пациенту. Конечно, можно использовать для идентификации строк имя пациента, но ведь может случиться так, что имеется несколько пациентов с именем Mary Smith. В подобном случае нет простого способа их различить. Именно по этой причине обычно используются номера. Такой уникальный столбец (или их группа), используемый для идентификации каждой строки и обеспечивающий различимость всех строк, называется первичным ключом таблицы (primary key of the table).

Первичный ключ таблицы — жизненно важное понятие структуры базы данных. Он является сердцем системы данных: для того чтобы найти определенную строку в таблице, укажите значение ее первичного ключа. Кроме того, он обеспечивает целостность данных. Если первичный ключ должным образом используется и поддерживается, вы будете твердо уверены в том, что ни одна строка таблицы не является пустой и что каждая из них отлична от остальных.

Столбцы поименованы и пронумерованы

В отличие от строк, столбцы таблицы (также называемые полями (fields) упорядочены и поименованы. Следовательно, в нашей таблице, соответствующей адресной книге, можно сослаться на столбец «Address» как на «столбец номер три». Естественно, это означает, что каждый столбец данной таблицы должен иметь имя, отличное от других имен, для того, чтобы не возникло путаницы. Лучше всего, когда имена определяют содержимое поля. В этой книге мы будем использовать аббревиатуру для именования столбцов в простых таблицах, например: cname — для имени покупателя (customer name), odate — для даты поступления (order date). Предположим также, что таблица содержит единственный цифровой столбец, используемый как первичный ключ.

Пример базы данных

Таблицы 1.1, 1. 2, 1.3 образуют реляционную базу данных, которая достаточно мала для того, чтобы можно было понять ее смысл, но и достаточно сложна для того, чтобы иллюстрировать на ее примере важные понятия и практические выводы, связанные с применением SQL.

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

Например, поле snum в таблице Customers определяет, каким продавцом (salespeople) обслуживается конкретный покупатель (customer). Номер поля snum устанавливает связь с таблицей Salespeople, которая дает информацию об этом продавце (salespeople). Очевидно, что продавец, который обслуживает данного покупателя, существует, т.е. значение поля snum в таблице Customers присутствует также и в таблице Salespeople. В этом случае мы говорим, что система находится в состоянии ссылочной целостности (referential integrity).

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

Перед вами объяснение столбцов таблицы 1.1:

Поле	Содержимое
snum	Уникальный номер, приписанный каждому продавцу («номер служащего»)
sname	Имя продавца
city	Место расположения продавца
comm	Вознаграждение (комиссионные) продавца в форме с десятичной точкой

Таблица 1.2 содержит следующие столбцы:

Поле	Содержимое
cnum	Уникальный номер, присвоенный покупателю
cname	Имя покупател
city	Место расположения покупателя
rating	Цифровой код, определяющий уровень предпочтения данного покупателя. Чем больше число, тем больше предпочтение
snum	Номер продавца, назначенного данному покупателю (из таблицы Salesperson)

И, наконец, столбцы таблицы 1.3:

Поле	Содержимое
onum	Уникальный номер, присвоенный данной покупке
amt	Количество
odate	Дата покупки
cnum	Номер покупателя, сделавшего покупку (из таблицы Customers)
snum	Номер продавца, обслужившего покупателя (из таблицы Salespeople)

Источник: SQL для простых смертных / Мартинн Грабер

С уважением, Артём Санников

Сайт: ArtemSannikov.ru

Метки: MySQL, База данных.

База данных SQl или NoSQL: какую выбрать для проекта?

Масштабируемость. Вертикальная, то есть при росте нагрузки растет производительность сервера. Если в базу поступает большой объем данных, рано или поздно наступит порог вертикального масштабирования — сервер не сможет далее увеличивать производительность. Тогда понадобится горизонтальное масштабирование — параллельная обработка данных в кластере серверов.

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

Самые известные SQL-базы данных

MySQL — одна из самых популярных open source реляционных баз данных. Подходит небольшим и средним проектам, которым нужен недорогой и надежный инструмент работы с данными. Поддерживает множество типов таблиц, есть огромное количество плагинов и расширений, облегчающих работу с системой.

Отличается простой установкой, может быть интегрирована с другими СУБД, также интеграция с MySQL есть в любой CMS, фреймворке, языке программирования. Среди минусов — не все задачи выполняет автоматически, если что-то нужное не включено в функционал, придется потратить время на доработку, нет встроенной поддержки OLAP.

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

PostgreSQL — вторая по популярности open source SQL СУБД. У нее много встроенных функций и дополнений, в том числе для масштабирования в кластер и шардинга таблиц. Подходит, если важна сохранность данных, предполагается их сложная структура. Позволяет работать со структурированными данными, но поддерживает JSON/BSON, что дает некоторую гибкость в схеме данных.

Отличается стабильностью, ее практически невозможно вывести из строя или что-то сломать в таблицах.

Из минусов — сложность конфигурации требует от пользователей некоторого опыта. Также скорость работы может падать во время проведения пакетных операций или при запросах на чтение.

PostgreSQL также можно развернуть в облаке — в отличие от MySQL, она подходит для крупных и масштабных проектов. Кроме того, ее стоит выбрать, если недопустимы ошибки в данных или есть особые требования к базе данных, например поддержка геоданных. Различные расширения PostgreSQL позволяют реализовать многие специализированные запросы.

В чем разница между реляционной и нереляционной базой данных — Разница Между

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

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

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

Ключевые области покрыты

1. Что такое реляционная база данных
— определение, функциональность
2. Что такое нереляционная база данных
— определение, функциональность
3. В чем разница между реляционной и нереляционной базой данных
— Сравнение основных различий

Основные условия

База данных, СУБД, NoSQL, Нереляционная база данных, Реляционная база данных

Что такое реляционная база данных

Модель базы данных определяет логический дизайн и структуру базы данных. Кроме того, он определяет, как данные хранятся и доступны с помощью СУБД. Здесь реляционная база данных основана на реляционной модели. Реляционная база данных хранит данные в таблицах. Таблица состоит из строк и столбцов. Где, строки представляют каждую сущность, в то время как столбцы представляют атрибуты.

Рисунок 1: Таблица в реляционной базе данных

Например, предположим, что база данных продаж. Таблица клиентов имеет столбцы или атрибуты, такие как customer_id, name, address, contact_no. Каждая строка в таблице представляет одного клиента. Первичным ключом таблицы customer является customer_id. Это помогает идентифицировать каждую запись в отдельности. Кроме того, предположим, что в базе данных продаж есть еще одна таблица, называемая заказами. У него есть order_id, order_name, date, customer_id. Customer_id в таблице customer является внешним ключом в таблице заказа. Таким образом, две таблицы связаны друг с другом. В реляционной базе данных таблицы связаны друг с другом.

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

Что такое нереляционная база данных

Реляционная база данных не эффективна для хранения большого количества данных, таких как BigData. Нереляционная база данных является решением этой проблемы. Кроме того, нереляционная база данных также называется NoSQL, Эти базы данных могут хранить большие данные. Также возможно кластеризовать данные на несколько машин, чтобы снизить затраты на обслуживание.

Существуют различные типы нереляционных баз данных.

Базы документов — Хранить динамические данные. Они хранят данные в формате JavaScript Object Notation (JSON). Например. CouchDB, Монго

Базы данных столбцов — Чтение и запись данных столбца мудро. Это полезно в аналитике данных. Например. Апач Кассандра.

Значение ключа хранимых баз данных — Быстро и не очень настраиваемый. Например. Couchbase Server, Redis.

Кэш базы данных — Храните данные на диске или в кеше. Например. Memcache

Граф базы данных — состоят из узлов. Отношения создаются с использованием ребер. Например. Oracle NoSQL, Neo4J.

Разница между реляционной и нереляционной базой данных

Определение

Реляционная база данных — это база данных, основанная на реляционной модели данных, предложенной EF Codd в 1970 году. Нереляционная база данных, с другой стороны, представляет собой тип базы данных, которая обеспечивает механизм для хранения и извлечения данных, которые моделируются таким образом, кроме табличных отношений, используемых в реляционных базах данных.

Synonms

Реляционные базы данных также называются базами данных SQL, в то время как нереляционные базы данных также называются базами данных NoSQL.

SQL

Реляционные базы данных используют SQL, тогда как нереляционные базы данных не используют SQL.

присоединяется

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

Типы

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

использование

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

Примеры

MySQL, SQLite3 и PostgreSQL — это некоторые СУБД, использующие реляционные базы данных. Cassendra, Hbase, MongoDB и Neo4 — некоторые нереляционные базы данных.

Заключение

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

Ссылка:

1. «Модели баз данных СУБД». Модели баз данных в СУБД | Studytonight,

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

Реляционная БД

Реляционная БД является множеством реляционных таблиц – взаимосвязанных двумерных таблиц, которые также называют отношениями. Каждое отношение содержит сведения об одной сущности предметной области, которая автоматизируется.

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

Определение 1

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

Структура реляционной таблицы

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

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

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

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

Связь двух таблиц В нормализованной реляционной БД характеризуется чаще всего отношениями записей двух типов: «один-к-одному» (1:1) и «один-ко-многим» (1:M).

Готовые работы на аналогичную тему

При связи 1:1 каждой записи одной таблицы ставится в соответствие одна запись другой.

При связи типа 1:М каждой записи первой таблицы ставится в соответствие много записей второй, но каждой записи второй таблицы ставится в соответствие лишь одна запись первой.

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

На рисунке 1 представлены 2 таблицы, которые содержат список покупателей и перечень заключенных договоров. Таблицы связаны отношением типа 1:M и логически связаны общим полем (столбцом) Код покупателя, которое является ключом связи. Данное поле –уникальный ключ в главной таблице ПОКУПАТЕЛЬ и неключевое поле в подчиненной таблице ДОГОВОР.

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

Access содержит средство редактирования и просмотра связанных записей нескольких таблиц. Если раскрыть один уровень иерархии, рядом с записью главной таблицы будут отображаться связанные записи подчиненной. К примеру, для таблиц ДОГОВОР и ПОКУПАТЕЛЬ (рисунок 2), которые связаны отношением 1:М, для каждой записи таблицы ПОКУПАТЕЛЬ можно отобразить и отредактировать связанные записи в таблице ДОГОВОР.

6. Реляционные базы данных.. Информационные ресурсы Интернет, относящиеся к области бизнеса и коммерции

4 — Основные понятия реляционных баз данных

ЛЕКЦИЯ 4

· ОСНОВНЫЕ ПОНЯТИЯ РЕЛЯЦИОННЫХ БАЗ ДАННЫХ

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

Для начала покажем смысл этих понятий на примере отношения СЛУЖАЩИЕ, содержащего информацию о служащих некоторого предприятия (рис. 1).

Рис. 2.1. Соотношение основных понятий реляционного подхода

· Тип данных

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

Обычно в современных реляционных базах данных допускается хранение символьных, числовых данных (точных и приблизительных), специализированных числовых данных (таких, как «деньги»), а также специальных «темпоральных» данных (дата, время, временной интервал). Кроме того, в реляционных системах поддерживается возможность определения пользователями собственных типов данных .

Рекомендуемые файлы

В примере на рис. 1 мы имеем дело с данными трех типов: строки символов, целые числа и «деньги».

· Домен

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

Наиболее правильной интуитивной трактовкой понятия домена является его восприятие как допустимого потенциального, ограниченного подмножества значений данного типа. Например, домен ИМЕНА в нашем примере определен на базовом типе символьных строк, но в число его значений могут входить только те строки, которые могут представлять имена (в частности, для возможности представления русских имен такие строки не могут начинаться с мягкого или твердого знака и не могут быть длиннее, например, 20 символов). Если некоторый атрибут отношения определяется на некотором домене (как, например, на рис. 1 атрибут СЛУ_ИМЯ определяется на домене ИМЕНА), то в дальнейшем ограничение домена играет роль ограничения целостности, накладываемого на значения этого атрибута.

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

· Элементы отношения

Понятие отношения является наиболее фундаментальным в реляционном подходе к организации баз данных, поскольку n-арное отношение является единственной родовой структурой данных, хранящихся в реляционной базе данных. Это отражено и в общем названии подхода – термин реляционный (relational) происходит от relation (отношение). Однако сам термин отношение является исключительно неточным, поскольку, говоря про любые сохраняемые данные, мы должны иметь в виду тип этих данных, значения этого типа и переменные, в которых сохраняются значения. Соответственно, для уточнения термина отношение выделяются понятия заголовка отношения, значения отношения и переменной отношения. Кроме того, нам потребуется вспомогательное понятие кортежа.

Итак, заголовком (или схемой) отношения r (Hr) называется конечное множество упорядоченных пар вида <A, T>, где A называется именем атрибута, а T обозначает имя некоторого базового типа или ранее определенного домена. По определению требуется, чтобы все имена атрибутов в заголовке отношения были различны. В примере на рис. 2.1 заголовком отношения СЛУЖАЩИЕ является множество пар {<слу_номер, номера_пропусков>, <слу_имя, имена>, <слу_зарп, размеры_выплат>, <слу_отд_номер, номера_отделов>}.

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

Кортежем tr, соответствующим заголовку Hr, называется множество упорядоченных триплетов вида <A, T, v>, по одному такому триплету для каждого атрибута в Hr. Третий элемент – v – триплета <A, T, v> должен являться допустимым значением типа данных или домена T. Заголовку отношения СЛУЖАЩИЕ соответствуют, например, следующие кортежи: {<слу_номер, номера_пропусков, 2934>, <слу_имя, имена, Иванов>, <слу_зарп, размеры_выплат, 22.000>, <слу_отд_номер, номера_отделов, 310>}, {<слу_номер, номера_пропусков, 2940>, <слу_имя, имена, Кузнецов>, <слу_зарп, размеры_выплат, 35.000>, <слу_отд_номер, номера_отделов, 320>}.

Телом Br отношения r называется произвольное множество кортежей tr. Одно из возможных тел отношения СЛУЖАЩИЕ показано на рис. 2.1. Заметим, что в общем случае, как это демонстрируют, в частности, рис. 2.1 и пример предыдущего абзаца, могут существовать такие кортежи tr, которые соответствуют Hr, но не входят в Br.

Значением Vr отношения r называется пара множеств Hr и Br. Одно из допустимых значений отношения СЛУЖАЩИЕ показано на рис. 2.1.

В изменчивой реляционной базе данных хранятся отношения, значения которых изменяются во времени. Переменной VARr называется именованный контейнер, который может содержать любое допустимое значение Vr. Естественно, что при определении любой VARr требуется указывать соответствующий заголовок отношения Hr.

Здесь стоит подчеркнуть, что любая принятая на практике операция обновления базы данных – INSERT (вставка кортежа в переменную отношения), DELETE (удаление кортежа из значения-отношения переменной отношения) и UPDATE (модификация кортежа значения-отношения переменной отношения) – с модельной точки зрения является операцией присваивания переменной отношения некоторого нового значения-отношения. Это совсем не означает, что перечисленные операции должны выполняться именно таким образом в СУБД: главное, чтобы результат операций соответствовал этой модельной семантике.

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

По определению, степенью, или «арностью», заголовка отношения, кортежа, соответствующего этому заголовку, тела отношения, значения отношения и переменной отношения является мощность заголовка отношения. Например, степень отношения СЛУЖАЩИЕ равна четырем, т. е. оно является 4-арным (кватернарным).

При приведенных определениях разумно считать схемой реляционной базы данных набор пар <имя_VARr, Hr>, включающий имена и заголовки всех переменных отношения, которые определены в базе данных. Реляционная база данных – это набор пар <VARr, Hr> (конечно, каждая переменная отношения в любой момент времени содержит некоторое значение-отношение, в частности, пустое).

Заметим, что в классических реляционных базах данных после определения схемы базы данных могли изменяться только значения переменных отношений. Однако теперь в большинстве реализаций допускается и изменение схемы базы данных: определение новых и изменение заголовков существующих переменных отношений. Это принято называть эволюцией схемы базы данных.

· Первичный ключ

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

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

Конечно, это достаточно грубая терминология, поскольку у обычных таблиц и строки, и столбцы упорядочены, тогда как атрибуты и кортежи отношений являются элементами неупорядоченных множеств. Тем не менее, когда мы перейдем к рассмотрению практических вопросов организации реляционных баз данных и средств управления, то будем использовать эту «житейскую» терминологию. Подобной терминологии придерживаются в большинстве коммерческих реляционных СУБД. Иногда также используются термины файл как аналог таблицы, запись как аналог строки и поле как аналог столбца. Напомню, что этой терминологией мы пользовались в лекции 1.

· Фундаментальные свойства отношений

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

Отсутствие кортежей-дубликатов,
первичный и возможные ключи отношений

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

Именно из этого свойства вытекает наличие у каждого значения отношения первичного ключа – минимального множества атрибутов, являющегося подмножеством заголовка данного отношения, составное значение которых уникально определяет кортеж отношения. Действительно, поскольку в любое время все кортежи тела любого отношения различны, у любого значения отношения свойством уникальности обладает, по крайней мере, полный набор его атрибутов. Однако в формальном определении первичного ключа требуется обеспечение его «минимальности», т. е. в набор атрибутов первичного ключа не должны входить такие атрибуты, которые можно отбросить без ущерба для основного свойства – однозначного определения кортежа. Немного позже мы покажем, почему свойство минимальности первичного ключа является критически важным. Понятно, что если у любого отношения существует набор атрибутов, обладающий свойством уникальности, то существует и минимальный набор атрибутов, обладающий свойством уникальности.

Конечно, могут существовать значения отношения с несколькими несовпадающими минимальными наборами атрибутов, обладающими свойствами уникальности. Например, если вернуться к предположениям лекции 1 об уникальности значений атрибутов СЛУ_НОМЕР и СЛУ_ИМЯ отношения СЛУЖАЩИЕ, то для каждого значения этого отношения мы имеем два множества атрибутов, претендующих на звание первичного ключа – {СЛУ_НОМЕР} и {СЛУ_ИМЯ}. В этом случае проектировщик базы данных должен решить, какое из альтернативных множеств атрибутов назвать первичным ключом, а остальные минимальные наборы атрибутов, обладающие свойством уникальности, называются возможными ключами¹⁾.

Понятие первичного ключа является исключительно важным в связи с понятием целостности баз данных. Заметим, что хотя формально существование первичного ключа значения отношения является следствием того, что тело отношения – это множество, на практике первичные (и возможные) ключи переменных отношений появляются в результате явных указаний проектировщика отношения. Определяя переменную отношения, проектировщик моделирует часть предметной области, данные из которой будет содержать база данных. И конечно, проектировщик должен знать природу этих данных. Например, ему должно быть известно, что никакие два служащих ни в какой момент времени не могут иметь удостоверение с одним и тем же номером. Поэтому он может (и даже должен, как будет показано немного позже) явно объявить {СЛУ_НОМЕР} возможным ключом. Если на предприятии установлено, что у всех служащих должны быть разные полные имена, то проектировщик может (и опять же должен) объявить возможным ключом и {СЛУ_ИМЯ}. Затем проектировщик должен оценить, какой из возможных ключей является более надежным (свойство его уникальности никогда не будет отменено) и выбрать наиболее надежный возможный ключ в качестве первичного (в нашем случае естественным выбором был бы ключ {СЛУ_НОМЕР}, потому что решение об уникальности полных имен служащих выглядит искусственным и может быть легко отменено руководством предприятия).

Теперь поясним, почему проектировщику следует явно объявлять первичный и возможные ключи переменных отношений²⁾. Дело в том, что в результате этого объявления СУБД получает информацию, которая в дальнейшем будет использоваться как ограничения целостности³⁾. СУБД никогда не допустит появления в переменной отношения значения-отношения, содержащего два кортежа с одинаковым значением атрибута СЛУ_НОМЕР (определение первичного ключа для данной переменной отношения отменить нельзя). Появление двух кортежей с одинаковым значением атрибута СЛУ_ИМЯ будет также невозможно до тех пор, пока остается в силе определение {СЛУ_ИМЯ} как возможного ключа. Тем самым объявления первичного и возможных ключей дают СУБД возможность поддерживать целостность базы данных даже в случае попыток занесения в нее некорректных данных.

Наконец, вернемся к свойству минимальности первичного и возможных ключей. Как отмечалось выше, это свойство является критически важным, и важность проявляется именно при трактовке первичного и возможных ключей как ограничений целостности. В нашем примере с отношением СЛУЖАЩИЕ свойством уникальности будет обладать не только множество атрибутов {СЛУ_НОМЕР}, но и, например, множество {СЛУ_НОМЕР, СЛУ_ОТД_НОМЕР}. Но если бы мы выставили в качестве ограничения целостности требование уникальности {СЛУ_НОМЕР, СЛУ_ОТД_НОМЕР}, то СУБД гарантировала бы отсутствие кортежей с одинаковым значением атрибута СЛУ_НОМЕР не во всем значении отношения СЛУЖАЩИЕ, а только в группах кортежей с одним и тем же значением атрибута СЛУ_ОТД_НОМЕР. Понятно, что это не соответствует смыслу моделируемой предметной области.

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

Отсутствие упорядоченности кортежей

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

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

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

Отсутствие упорядоченности атрибутов

Атрибуты отношений не упорядочены, поскольку по определению заголовок отношения есть множество пар <имя атрибута, имя домена>. Для ссылки на значение атрибута в кортеже отношения всегда используется имя атрибута. Легко заметить явную аналогию между заголовками отношений и структурными типами в языках программирования. Даже в языке программирования C с его практически неограниченными возможностями работы с указателями настойчиво рекомендуется обращаться к полям структур только по их именам. Если, например, на языке C определена структурная переменная

struct {int a; char b; int c} d;

то в стандарте языка решительно не рекомендуется использовать для доступа к символьному полю b конструкцию *(&d + sizeof(int)) (взять адрес структурной переменной d, прибавить к нему число байтов в целом числе и взять значение байта по полученному адресу). Это объясняется тем, что при реальном расположении в памяти полей такой структурной переменной в том порядке, как они определены, во многих компьютерах потребуется выровнять поле c по байту с четным адресом. Поэтому один байт просто пропадет. При расположении структурной переменной в памяти экономный компилятор (вернее, оптимизатор) переставит местами поля b и c, и указанная выше конструкция не обеспечит доступа к полю b. Для корректного обращения к полю b переменной d нужно использовать конструкции d.b или &d->b, т. е. явно указывать имя поля.

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

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

Атомарность значений атрибутов
Первая нормальная форма отношения

Значения всех атрибутов являются атомарными (вернее, скалярными). Это следует из определения домена как потенциального множества значений скалярного типа данных, т. е. среди значений домена не могут содержаться значения с видимой структурой, в том числе множества значений (отношения). Заметим, что это не противоречит тому, что говорилось в разделе «Основные понятия реляционных баз данных» о потенциальной возможности использования при спецификации атрибутов типов данных, определяемых пользователями. Например, можно было бы добавить в схему отношения СЛУЖАЩИЕ атрибут СЛУ_ФОТО, определенный на домене (или типе данных) ФОТОГРАФИИ. Главное в атомарности значений атрибутов состоит в том, что реляционная СУБД не должна обеспечивать пользователям явной видимости внутренней структуры значения. Со всеми значениями можно обращаться только с помощью операций, определенных в соответствующем типе данных.

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

Пример ненормализованного отношения показан на рис. 2.2. Можно сказать, что здесь мы имеем бинарное отношение, в котором значениями атрибута ОТДЕЛЫ являются отношения. Заметим, что исходное отношение СЛУЖАЩИЕ является нормализованным вариантом отношения ОТДЕЛЫ-СЛУЖАЩИЕ. Нормализованный вариант показан на рис. 2.3.

Нормализованные отношения составляют основу классического реляционного подхода к организации баз данных. Они обладают некоторыми ограничениями¹⁾ (не всякую информацию удобно представлять в виде плоских таблиц), но существенно упрощают манипулирование данными. Рассмотрим, например, два идентичных оператора занесения кортежа:

n зачислить служащего Кузнецова (пропуск номер 3000, зарплата 25000.00) в отдел номер 320;

n зачислить служащего Кузнецова (пропуск номер 3000, зарплата 25000.00) в отдел номер 310.

Рис. 2. Ненормализованное отношение ОТДЕЛЫ-СЛУЖАЩИЕ

Рис. 3. Отношение СЛУЖАЩИЕ: нормализованный вариант
отношения ОТДЕЛЫ-СЛУЖАЩИЕ

Если информация о служащих представлена в виде отношения СЛУЖАЩИЕ, оба оператора будут выполняться одинаково (вставить кортеж в отношение СЛУЖАЩИЕ). Если же работать с ненормализованным отношением ОТДЕЛЫ-СЛУЖАЩИЕ, то первый оператор приведет к простой вставке кортежа, а второй – к добавлению кортежа в значение-отношение атрибута ОТДЕЛ кортежа с первичным ключом 310.

При работе с ненормализованными отношениями аналогичные затруднения возникают при выполнении операций удаления и модификации кортежей.

· Реляционная модель данных

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

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

Хотя понятие модели данных является общим, и можно говорить об иерархической, сетевой, семантической и других моделях данных, нужно отметить, что в области баз данных это понятие было введено Эдгаром Коддом применительно к реляционным системам и наиболее эффективно используется именно в данном контексте. Попытки прямолинейного применения аналогичных моделей к дореляционным организациям показывают, что реляционная модель слишком «велика», а для постреляционных организаций она оказывается «мала».

Общая характеристика

Хотя понятие реляционной модели данных первым ввел основоположник реляционного подхода Эдгар Кодд, наиболее распространенная трактовка реляционной модели данных, по-видимому, принадлежит известному популяризатору идей Кодда Кристоферу Дейту, который воспроизводит ее (с различными уточнениями) практически во всех своих книгах (см., например, К. Дейт. Введение в системы баз данных. 6-е изд., М.; СПб.: Вильямс.– 2000). Согласно трактовке Дейта, реляционная модель состоит из трех частей, описывающих разные аспекты реляционного подхода: структурной части, манипуляционной части и целостной части.

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

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

Целостность сущности и ссылок

Наконец, в целостной части реляционной модели данных фиксируются два базовых требования целостности, которые должны поддерживаться в любой реляционной СУБД. Первое требование называется требованием целостности сущности (entity integrity). Объекту или сущности реального мира в реляционных БД соответствуют кортежи отношений. Конкретно требование состоит в том, что любой кортеж любого значения-отношения любой переменной отношения должен быть отличим от любого другого кортежа этого значения отношения по составным значениям заранее определенного множества атрибутов переменной отношения, т. е., другими словами, любая переменная отношения должна обладать первичным ключом. Как мы видели в предыдущем разделе, это требование автоматически удовлетворяется, если в системе не нарушаются базовые свойства отношений.

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

Конечно, теоретически любой кортеж, заносимый в сохраняемое отношение, должен содержать все характеристики моделируемой им сущности реального мира, которые мы хотим сохранить в базе данных. Однако на практике не все эти характеристики могут быть известны к тому моменту, когда требуется зафиксировать сущность в базе данных. Простым примером может быть процедура принятия на работу человека, размер заработной платы которого еще не определен. В этом случае служащий отдела кадров, который заносит в отношение СЛУЖАЩИЕ кортеж, описывающий нового служащего, просто не может обеспечить значение атрибута СЛУ_ЗАРП (любое значение домена РАЗМЕРЫ_ВЫПЛАТ будет неверно характеризовать зарплату нового служащего).

Эдгар Кодд предложил использовать в таких случаях неопределенные значения. Неопределенное значение не принадлежит никакому типу данных и может присутствовать среди значений любого атрибута, определенного на любом типе данных (если это явно не запрещено при определении атрибута). Если a – это значение некоторого типа данных или NULL, op – любая двуместная «арифметическая» операция этого типа данных (например, +), а lop – операция сравнения значений этого типа (например, =), то по определению:

a op NULL = NULL

NULL op a = NULL

a lop NULL = unknown

NULL lop a = unknown

Здесь unknown – это третье значение логического, или булевского, типа, обладающее следующими свойствами:

NOT unknown = unknown

true AND unknown = unknown

true OR unknown = true

false AND unknown = false

false OR unknown = unknown

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

Так вот, первое из требований — требование целостности сущности — означает, что первичный ключ должен полностью идентифицировать каждую сущность, а поэтому в составе любого значения первичного ключа не допускается наличие неопределенных значений. (В классической реляционной модели это требование распространяется и на возможные ключи; как будет показано в следующих лекциях, в SQL-ориентированных СУБД такое требование для возможных ключей не поддерживается.)

Второе требование, которое называется требованием целостности по ссылкам (referential integrity), является более сложным. Очевидно, что при соблюдении нормализованности отношений сложные сущности реального мира представляются в реляционной БД в виде нескольких кортежей нескольких отношений. Например, представим, что требуется представить в реляционной базе данных сущность ОТДЕЛ с атрибутами ОТД_НОМЕР (номер отдела), ОТД_РАЗМ (количество служащих) и ОТД_СЛУ (множество служащих отдела). Для каждого служащего нужно хранить СЛУ_НОМЕР (номер служащего), СЛУ_ИМЯ (имя служащего) и СЛУ_ЗАРП (заработная плата служащего). Как мы увидим в лекции 7, при правильном проектировании соответствующей БД в ней появятся два отношения: ОТДЕЛЫ {ОТД_НОМЕР, ОТД_РАЗМ} (первичный ключ – {ОТД_НОМЕР}) и СОТРУДНИКИ {СЛУ_НОМЕР, СЛУ_ИМЯ, СЛУ_ЗАРП, СЛУ_ОТД_НОМ} (первичный ключ – {СЛУ_НОМЕР}).

Как видно, атрибут СЛУ_ОТД_НОМ вводится в отношение СЛУЖАЩИЕ не потому, что номер отдела является собственным свойством служащего, а лишь для того, чтобы иметь возможность при необходимости восстановить полную сущность ОТДЕЛ. Значение атрибута СЛУ_ОТД_НОМ в любом кортеже отношения СЛУЖАЩИЕ должно соответствовать значению атрибута ОТД_НОМ в некотором кортеже отношения ОТДЕЛЫ. Атрибут такого рода (возможно, составной) называется внешним ключом (foreign key), поскольку его значения однозначно характеризуют сущности, представленные кортежами некоторого другого отношения (т. е. задают значения их первичного ключа). Конечно, внешний ключ может быть составным, т. е. состоять из нескольких атрибутов. Говорят, что отношение, в котором определен внешний ключ, ссылается на соответствующее отношение, в котором такой же атрибут является первичным ключом.

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

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

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

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

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

Рекомендация для Вас — 19 — Поиски слепых и погребенных залежей.

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

· Заключение

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

В нескольких лекциях данного курса достаточно подробно обсуждаются возможности текущих стандартов языка SQL: SQL:1999 и SQL:2003. Но сначала читателям предлагается материал, который представляет реляционный подход в чистом виде. В данной лекции вводится понятийная основа реляционного подхода; определяются основные термины; исследуются фундаментальные следствия базовых определений. Рассматриваемая реляционная модель данных предназначена, прежде всего, для оценки соответствия различных реализаций СУБД общему реляционному подходу.

Вопросы и ответы по реляционной базе данных и схемам

Этот набор вопросов и ответов с множественным выбором баз данных (MCQ) посвящен теме «Реляционная база данных и схема базы данных».

1. Реляционная база данных состоит из набора из
a) таблиц
b) полей
c) записей
d) ключей
Просмотр ответа

Ответ: a
Объяснение: Поля — это столбцы отношения или таблиц. Записи — это каждая строка в отношении. Ключи — это ограничения в отношении.

2. Значок ________ в таблице представляет связь между набором значений.
a) Столбец
b) Ключ
c) Строка
d) Запись
Просмотр ответа

Ответ: c
Объяснение: Столбец имеет только один набор значений. Ключи — это ограничения, а строка — это целый набор атрибутов. Запись — это всего лишь часть данных.

3. Термин _______ используется для обозначения строки.
a) Атрибут
b) Кортеж
c) Поле
d) Экземпляр
Просмотр ответа

Ответ: b
Объяснение: Кортеж — это одна запись отношения с несколькими атрибутами, которые являются полями.

4. Термин атрибут относится к ___________ таблицы.
a) Запись
b) Столбец
c) Кортеж
d) Ключ
Просмотр ответа

Ответ: b
Объяснение: Атрибут — это конкретный домен в отношении, в котором есть записи всех кортежей.

5. Для каждого атрибута отношения существует набор разрешенных значений, который называется ________ этого атрибута.
a) Домен
b) Связь
c) Установить
d) Схема
Просмотреть ответ

Ответ: a
Объяснение: Значения атрибута должны присутствовать в домене.Домен — это набор разрешенных значений.

6. База данных __________, которая является логической структурой базы данных, и база данных _______, которая является моментальным снимком данных в базе данных в данный момент времени.
a) Экземпляр, схема
b) Отношение, схема
c) Отношение, домен
d) Схема, экземпляр
Просмотреть ответ

Ответ: d
Объяснение: Экземпляр — это экземпляр времени, а схема — представление.

7. Курс (course_id, sec_id, semester)
Здесь course_id, sec_id и семестр __________, а курс — _________
a) Отношения, Атрибут
b) Атрибуты, Отношение
c) Кортеж, Отношение
d) Кортеж, Атрибуты
Посмотреть ответ

Ответ: b
Объяснение: Связанный курс имеет набор атрибутов course_id, sec_id, semester.

8. Отдел (название отдела, здание, бюджет) и сотрудник (идентификатор сотрудника, имя, название отдела, зарплата)
Здесь атрибут dept_name появляется в обоих отношениях. Здесь использование общих атрибутов в схеме отношений — это один из способов связать ___________ отношений.
a) Атрибуты общего
b) Кортеж общего
c) Кортеж различных
d) Атрибуты различных
Просмотр Ответ

Ответ: c
Объяснение: Здесь отношения связаны общими атрибутами.

9. Домен считается атомарным, если элементы домена считаются ____________ единиц.
a) Другой
b) Независимый
c) Постоянный
d) Делимый
Просмотреть ответ

Ответ: b
Пояснение: Нет.

10. Кортежи отношений могут иметь порядок ________.
a) Любой
b) То же
c) Сортированный
d) Постоянный
Просмотр ответа

Ответ: a
Объяснение: Только значения считаются. Порядок кортежей не имеет значения.

Sanfoundry Global Education & Learning Series — Система управления базами данных.

Примите участие в конкурсе сертификации Sanfoundry, чтобы получить бесплатную Почетную грамоту. Присоединяйтесь к нашим социальным сетям ниже и будьте в курсе последних конкурсов, видео, стажировок и вакансий!

Концепции реляционных баз данных

Глава 2 Термины и концепции базы данных

Система управления реляционными базами данных (СУБД) хранит и
извлекает данные, представленные в таблицах.Реляционная база данных
состоит из набора таблиц, в которых хранятся взаимосвязанные данные.

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

Таблицы базы данных

В реляционной базе данных все данные хранятся в таблицах ,
которые состоят из строк и столбцов .

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

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

emp_ID	emp_lname	emp_fname	emp_phone
10057	Хуонг	Чжан	1096
10693	Дональдсон	Анна	7821

Таблицы реляционной базы данных имеют некоторые важные характеристики:

Нет значения
порядок столбцов или строк.
Каждая строка содержит одно и только одно значение для каждого
столбец.
Каждое значение для данного столбца имеет один и тот же тип.

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

Формальный термин отношений	Неформальный термин отношений	Эквивалентный термин, не связанный с отношениями
Отношение	Стол	Файл
Атрибут	Колонка	Поле
Кортеж	Ряд	Запись

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

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

Реляционная база данных — это набор связанных таблиц. Ты используешь
первичный и внешний ключи для описания отношений между информацией
в разных таблицах.

Первичный и внешний ключи

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

Таблицы имеют первичный ключ

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

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

Примеры

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

В примере базы данных таблица позиций заказа на продажу имеет
следующие столбцы:

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

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

Таблицы связаны внешними ключами

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

Пример

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

dept_id Идентификационный номер отдела. Это первичный
ключ для стола.
dept_name Столбец, содержащий название отдела.
dept_head_id Идентификатор сотрудника для руководителя отдела.

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

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

Прочие объекты базы данных

Реляционная база данных содержит больше, чем набор связанных таблиц.Среди других объектов, составляющих реляционную базу данных:

Индексы Индексы позволяют быстро искать информацию. Концептуально,
указатель в базе данных похож на указатель в книге. В книге
index связывает каждый проиндексированный термин со страницей или страницами, на которых этот
слово появляется. В базе данных индекс связывает каждый индексированный столбец
значение в физическое расположение, в котором строка данных, содержащая
индексированное значение сохраняется. Индексы
являются важным элементом дизайна для обеспечения высокой производительности,
однако их использование прозрачно для пользователя.
Представления Представления — это вычисляемые таблицы или виртуальные таблицы. Они
выглядят как таблицы для клиентских приложений, но не содержат данных.
Вместо этого, всякий раз, когда к ним обращаются, информация в них
вычисляется из базовых таблиц.
Таблицы, которые фактически содержат информацию, иногда
называется базовыми таблицами , чтобы отличить их от
Просмотры.
Хранимые процедуры и триггеры Это процедуры, хранящиеся в самой базе данных, которые
действовать в соответствии с информацией в базе данных.
Вы можете создавать собственные хранимые процедуры и давать им имена для выполнения
конкретные запросы к базе данных и для выполнения других задач базы данных. Хранится
процедуры могут принимать параметры. Например, вы можете создать
хранимая процедура, которая возвращает имена всех клиентов, у которых есть
потрачено больше суммы, указанной вами в качестве параметра в
вызов на процедуру.
Триггер — это специальная хранимая процедура, которая автоматически
срабатывает всякий раз, когда пользователь обновляет, удаляет или вставляет данные, в зависимости от
от того, как вы определяете триггер.Вы связываете триггер с таблицей
или столбцы в таблице. Триггеры полезны для автоматического
ведение бизнес-правил в базе данных.
Пользователи и группы У каждого пользователя базы данных есть идентификатор пользователя и пароль.
Вы можете установить разрешения для каждого пользователя, чтобы конфиденциальная информация
хранится в секрете, и пользователи не могут делать несанкционированные
изменения. Пользователи могут быть распределены по группам, чтобы администрирование
разрешений проще.
Объекты Java Вы можете установить классы Java в базу данных.Классы Java предоставляют мощный способ встраивать логику в ваш
база данных и специальный класс определяемых пользователем типов данных для хранения
Информация.

Запросы

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

Выступ — это подмножество столбцов
в таблице. Ограничение (также называемое выбором )
— это подмножество строк в таблице, основанное на некоторых условиях.

Например, следующий оператор SELECT
извлекает названия и цены всех продуктов, которые стоят более 15 долларов:

 ВЫБРАТЬ имя, unit_price 
 FROM product 
 WHERE unit_price> 15

В этом запросе используются оба ограничения (WHERE unit_price> 15)
и прогноз (ВЫБЕРИТЕ имя, unit_price)

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

 ВЫБЕРИТЕ sales_order_items.id, product.name 
 FROM product KEY JOIN sales_order_items 
 ГДЕ sales_order_items.quantity> 12

Таблица товаров и sales_order_items
таблицы объединяются на основе отношений внешнего ключа
между ними.

Другие операторы SQL

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

Системные столы

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

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

XML-представление реляционной базы данных

W3C
XML

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

В этой статье описывается применение (простой
подмножество) XML, которое можно использовать для представления такой базы данных.

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

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

Вступление

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




<авторы>

 Роберт Робертс 
 10 Tenth St, Decapolis 
 Элла Эллис 
 ftp: // docs / rr-10 
 26 мая 1960 г. 



 Том Томас 
 2 Second Av, Duo-Duo 
 Элла Эллис 
 ftp: // docs / tt-2 



 Отметить отметки 
 1 Premier, Maintown 
 Элла Эллис 
 ftp: // docs / mm-1 



<редакторы>
<редактор>
 Элла Эллис 
 7356

Формат подробный, поскольку XML многословен.С другой стороны, он сжимает
хорошо со стандартными инструментами для сжатия. Также легко распечатать базу данных
(или его часть) со стандартными браузерами XML и простой таблицей стилей.

База данных

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

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

name « url «>
< name >
table ₁
table ₂
…
таблица _n
< / название >

Имя произвольно. URL-адрес указывать необязательно, но его можно
используется для указания информации о базе данных. Мы не определяем, что это
указывает на. [Или мы должны?]

Порядок таблиц также произвольный, поскольку реляционная база данных определяет
никакого заказа на них.

Стол

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

< имя >
запись ₁
запись ₂
…
запись _м
название >

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

Запись

Запись также представлена элементом
node с его полями в качестве дочерних:

< имя >
поле ₁
поле ₂
…
поле _м
название >

Имя является произвольным, поскольку реляционная модель данных не
определить имя для типа записи. Однако в XML его нельзя опускать. Один
схема заключается в повторном использовании имени таблицы или, если таблица имеет имя, которое
является множественным числом, чтобы использовать форму единственного числа (`персонажи ‘->` человек’, `части ‘
-> `часть ‘).

Порядок полей снова несущественен.

Поле

Поле представлено как узел элемента
с узлом данных в качестве его единственного дочернего элемента:

< name type = « t «>
d
name

Если d опущено, это означает, что значение полей пустое.
нить.

Значение t указывает тип значения (например, строка,
число, логическое значение, дата). [Следует ли давать полный список?] Если атрибут type
опускается, предполагается, что типом является `строка ‘.

Нулевые значения

Нулевые значения представлены отсутствием поля.

Обратите внимание, что это отличается от того, чтобы оставить поле пустым, что означает
что поле содержит строку нулевой длины. У нулевых значений есть особые
свойства в реляционных базах данных.Например, два поля с нулевым значением
значения не равны (в отличие от двух полей со строками нулевой длины,
которые равны ).

Сильная типизация

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




<авторы>
  
  xml-sqltype = "varchar" 
  xml-sqlsize = "40" 
 ?> 
  
  xml-sqltype = "varchar" 
  xml-sqlsize = "40" 
 ?> 
 ... 
  
  xml-sqltype = "date" 
  xml-sqlmin = "1900/01/01" 
  xml-sqlmax = "1990/01/01" 
 ?> 
...


<редакторы>
  
  xml-sqltype = "varchar" 
  xml-sqlsize = "40" 
 ?> 
...

и т. д. Это позволит приложению, которое знает об этих атрибутах,
проверьте содержимое каждого поля.

использованная литература

Реляционная модель данных описана во многих книгах. Вот два примера:

Джеффри Д. Уллман. Принципы баз данных и систем баз знаний,
том I. Computer Science Press, Rockville, Maryland, 1988. (ISBN
0-88175-188-X)
C. J. Date. Введение в системы баз данных, том I.
Аддисон-Уэсли, Рединг, Массачусетс, 1986. (ISBN 0-201-19215-2).

XML в настоящее время является черновиком, а «Модель данных XML» является одним из предложений по разработке
этот проект:

Постскриптум

Если вам нравится редактировать XML вручную, с помощью текстового редактора вы можете
конечно, используйте красивую печать, чтобы легче было распознать.Здесь
это один из примеров:




<АВТОРЫ>


 Роберт Робертс 
<адрес> Десятая улица, 10, Декаполис 
<редактор> Элла Эллис 
 ftp: // docs / rr-10 



 Том Томас 
<адрес> 2 секунды Av, Duo-Duo 
<редактор> Элла Эллис 
 ftp: // docs / tt-2 



 Отметить отметки 
 1 Premier, Maintown 
<редактор> Элла Эллис 
 ftp: // docs / mm-1 




<РЕДАКТОРЫ>

<редактор>
 Элла Эллис 
<телефон> 7356

Берт Бос
Последнее изменение: $ Дата: 1997/07/11 19:39:01 $

Глава 7 Реляционная модель данных — Проектирование базы данных — 2-е издание
Адриенн Ватт
Реляционная модель данных была введена К.F. Codd в 1970 году. В настоящее время это наиболее широко используемая модель данных.
На основе реляционной модели:
Исследования по теории данных / отношений / ограничений
Многочисленные методологии проектирования баз данных
Стандартный язык доступа к базе данных, называемый s Tructured Query Language (SQL)
Практически все современные коммерческие системы управления базами данных
Реляционная модель данных описывает мир как «набор взаимосвязанных отношений (или таблиц).”
Основные концепции реляционной модели данных
Отношение
Отношение , , также известное как таблица или файл , является подмножеством декартового произведения списка доменов, характеризуемых именем. А внутри таблицы каждая строка представляет группу связанных значений данных. Строка или запись также известна как кортеж . Столбцы в таблице — это поле, которое также называется атрибутом. Вы также можете думать об этом так: атрибут используется для определения записи, а запись содержит набор атрибутов.
Следующие шаги описывают логику между отношением и его доменами.
Дано n доменов обозначены D1, D2,… Dn
И r — отношение, определенное на этих доменах
Тогда r ⊆ D1 × D2 ×… × Dn
Стол
База данных состоит из нескольких таблиц, и каждая таблица содержит данные. На рисунке 7.1 показана база данных, содержащая три таблицы.
Рисунок 7.1. База данных с тремя таблицами.
Колонна
База данных хранит информацию или факты в организованном порядке. Понимание того, как использовать базы данных и получать от них максимальную отдачу, требует от нас понимания этого метода организации.
Основные единицы хранения называются столбцами или полями или атрибутами . Они содержат основные компоненты данных, на которые можно разбить ваш контент. При принятии решения о том, какие поля создавать, вам необходимо в общих чертах подумать о своей информации, например, выделить общие компоненты информации, которые вы будете хранить в базе данных, и избежать специфических особенностей, которые отличают один элемент от другого.
Посмотрите на пример идентификационной карты на рис. 7.2, чтобы увидеть взаимосвязь между полями и их данными.
Рисунок 7.2. Образец удостоверения личности А. Ватта.
Домен
Домен — это исходные наборы атомарных значений, используемых для моделирования данных. Под атомным значением мы подразумеваем, что каждое значение в домене неделимо с точки зрения реляционной модели. Например:
Область Семейного положения имеет набор возможностей: женат, холост, разведен.
В домене Shift заданы все возможные дни: {Пн, Вт, Ср…}.
Область Salary — это набор всех чисел с плавающей запятой больше 0 и меньше 200 000.
Область имени — это набор строк символов, представляющих имена людей.
Таким образом, домен — это набор допустимых значений, которые разрешено содержать в столбце. Это основано на различных свойствах и типе данных для столбца. Мы обсудим типы данных в другой главе.
Записи
Так же, как содержимое любого документа или элемента необходимо разбить на составляющие его биты данных для хранения в полях, также должна быть доступна связь между ними, чтобы их можно было воссоздать в их целостную форму. Записи позволяют нам это делать. Записи содержат связанные поля, такие как клиент или сотрудник. Как отмечалось ранее, кортеж — это еще один термин, используемый для записи.
Записи и поля составляют основу всех баз данных.Простая таблица дает нам наиболее четкое представление о том, как записи и поля работают вместе в проекте хранилища базы данных.
Рисунок 7.3. Пример простой таблицы А. Ватта.
В простом примере таблицы на рис. 7.3 показано, как поля могут содержать различные типы данных. У этого:
Поле идентификатора записи: это порядковый номер; его тип данных — целое число.
Поле PubDate: отображается как день / месяц / год; его тип данных — дата.
Поле «Автор»: отображается как Начальное.Фамилия; его тип данных — текст.
A Текст поля заголовка: здесь можно ввести произвольный текст.
Вы можете дать команду базе данных просеивать данные и организовывать их определенным образом. Например, вы можете запросить, чтобы выбор записей был ограничен датой: 1. все до заданной даты, 2. все после заданной даты или 3. все между двумя заданными датами. Точно так же вы можете выбрать сортировку записей по дате. Поскольку поле или запись, содержащая данные, настроено как поле даты, база данных считывает информацию в поле даты не только как числа, разделенные косой чертой, но скорее как даты, которые должны быть упорядочены в соответствии с календарной системой.
Степень
градус — это количество атрибутов в таблице. В нашем примере на рисунке 7.3 степень равна 4.
Свойства таблицы
Имя таблицы отличается от имени всех других таблиц в базе данных.
Нет повторяющихся строк; каждая строка отличается.
Записи в столбцах атомарны. Таблица не содержит повторяющихся групп или многозначных атрибутов.
Записи из столбцов относятся к одному домену в зависимости от их типа данных, включая:
число (числовое, целое, с плавающей запятой, smallint,…)
символ (строка)
дата
логический (истина или ложь)
Операции, объединяющие разные типы данных, запрещены.
У каждого атрибута есть собственное имя.
Последовательность столбцов несущественная.
Последовательность строк несущественная.
атомарное значение : каждое значение в домене неделимо с точки зрения реляционной модели атрибут : основная единица хранения в базе данных
столбец: см. Атрибут
степень : количество атрибутов в таблице
домен : исходные наборы атомарных значений, используемых для моделирования данных; набор допустимых значений, которые столбец может содержать
поле : см. Атрибут
файл : см. Отношение
запись : содержит связанные поля; см. Кортеж
отношение : подмножество декартова произведения списка доменов, характеризуемых именем; технический термин для таблицы или файла
ряд : см. Кортеж
язык структурированных запросов (SQL) : стандартный язык доступа к базе данных
таблица: см. Отношение
кортеж : технический термин для строки или записи
Ключ терминологии
Некоторые термины, используемые в этой главе, являются синонимами.В дополнение к ключевым терминам, указанным выше, см. Таблицу 7.1 ниже. Чаще всего используются термины в столбце Альтернатива 1.
Таблица 7.1. Термины и их синонимы А. Ватта.
Используйте таблицу 7.2, чтобы ответить на вопросы 1–4.
Используя правильную терминологию, определите и опишите все компоненты в таблице 7.2.
Каков возможный домен для поля EmpJobCode?
Сколько записей отображается?
Сколько атрибутов отображается?
Список свойств таблицы.
Таблица 7.2. Таблица вопросов для упражнений А. Ватта.
Атрибуция
Эта глава Database Design (включая изображения, если не указано иное) является производной копией Relational Design Theory, разработанной Нгуен Ким Ань под лицензией Creative Commons Attribution License 3.0, лицензия
Адриенн Ватт написала следующий материал:
Все или часть разделов отношений, таблиц, столбцов и степеней
Ключевые термины
Упражнения
Структура реляционных баз данных MCQ — система управления базами данных
Этот набор расширенной системы управления базами данных ориентирован на MCQ структуры реляционных баз данных (вопросы и ответы с несколькими вариантами ответов).

1
. Давайте рассмотрим таблицу account. Она имеет три заголовка столбцов; номер счета , название филиала и остаток . Следуя терминологии реляционной модели, эти заголовки можно обозначать как что?

2
. Для каждого атрибута в таблице есть набор разрешенных значений, который называется _____ этого атрибута.

3
. Математические термины отношения и кортежи обозначаются как?

4
.Что из следующего описывает логическую структуру базы данных?

5
. Что из следующего описывает моментальный снимок данных в базе данных в данный момент времени?

6
. Что из следующего описывает имя отношения (имя таблицы), атрибуты и их имена?

7
. __________ — это снимок отношений в определенное время. Он состоит из данных, которые присутствуют внутри отношения в определенный момент времени.Повторяющиеся записи строк не допускаются в _____. Хотя в SQL в таблице разрешены повторяющиеся строки.

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

9
. Какое из следующих утверждений верно?
I. Реляционная база данных состоит из набора атрибутов
II.Реляционная база данных состоит из наборов таблиц.
III.Реляционная база данных состоит из наборов столбцов.
IV.Реляционная база данных состоит из наборов строк

10
. A___ в таблице представляет отношение между набором значений.
Вас может заинтересовать:
Основы системы управления базами данных MCQ
Онлайн-тесты системы управления базами данных
Краткие вопросы по системе управления базами данных с ответами
Учебники по системе управления базами данных
Реляционная база данных состоит из набора
1
Обсудить
Операция _______ выполняет объединение двух таблиц «аналогичной структуры»
2
Обсудить
Наиболее часто используемая операция в реляционной алгебре для проецирования набора кортежей из отношения —
.
3
Обсудить
Курс (course_id, sec_id, семестр)
Здесь course_id, sec_id и семестр __________, а курс _________
4
Обсудить
Домен считается атомарным, если элементы домена считаются ____________ единиц.
5
Обсудить
Предложение ________ используется для перечисления атрибутов, требуемых в результате запроса.
6
Обсудить
ВЫБРАТЬ имя ОТ инструктора ГДЕ зарплата <= 100000 И зарплата> = ;
Что из следующего можно заменить этим запросом?
1]
ВЫБРАТЬ имя ОТ инструктора ГДЕ Заработная плата МЕЖДУ И 100000;

7
Обсудить
Термин «атрибут» относится к ___________ таблицы.
8
Обсудить
Кортежи отношений могут иметь порядок ________.
9
Обсудить
ВЫБРАТЬ emp_name ОТ отдела ГДЕ dept_name LIKE ’_____ Computer Science’;
Что из следующего должно быть добавлено в пустое поле, чтобы выбрать dept_name, конечной строкой которого являются компьютерные науки?
10
Обсудить
Предложение ______ позволяет нам выбирать только те строки в результирующем отношении предложения ____, которые удовлетворяют указанному предикату.
Что такое таблица базы данных?
Реляционная база данных состоит из нескольких компонентов, из которых таблица является наиболее важной. Таблица базы данных — это место, где хранятся все данные в базе данных, и без таблиц не было бы большого использования для реляционных баз данных.
Общая структура таблицы базы данных
База данных состоит из одной или нескольких таблиц.Каждая таблица состоит из строк и столбцов. Если вы думаете о таблице как о сетке, столбец идет слева направо по сетке, и каждая запись данных перечисляется в виде строки.
Каждая строка в реляционном элементе однозначно идентифицируется первичным ключом. Это может быть один или несколько наборов значений столбца. В большинстве сценариев это один столбец, например employeeID.
Каждая реляционная таблица имеет один первичный ключ. Его цель — однозначно идентифицировать каждую строку в базе данных. Никакие две строки не могут иметь одинаковое значение первичного ключа.Практический результат этого состоит в том, что вы можете выбрать каждую строку, просто зная ее первичный ключ.
Колонны
Столбцы определены для хранения данных определенного типа, например дат, числовых или текстовых данных. В простейшем из определений столбец определяется своим именем и типом данных. Имя используется в операторах SQL при выборе и упорядочивании данных, а тип данных используется для проверки сохраненной информации.
Итак, столбец DateOfBirth, определенный как дата, может упоминаться в предложении order by как
ЗАКАЗАТЬ ПО ДАТЕ РОЖДЕНИЯ
И, если вы попытаетесь добавить значение «Hello Kitty» в столбец, как часть его проверки, он распознает, что это не дата, и отклонит его.
Названия столбцов нельзя дублировать в таблице. Таким образом, наличие двух столбцов с «именами» — это не проблема. Хотя у вас может быть два столбца «name», например name1 и name2, позже вы узнаете, что это не одобряется, так как нарушает нормальную форму (я объясню это в другом посте).
рядов
Таблица может содержать ноль или более строк. Когда их нет, он считается пустым. Практического ограничения на количество строк в таблице не существует; однако помните, что первичный ключ таблицы может иметь некоторое влияние на это.Я имею в виду, что если ваша таблица содержит состояния, а первичный ключ — это аббревиатура состояния, то по определению, поскольку в объединении всего пятьдесят состояний, и у вас не может быть дубликатов в первичном ключе, ваша таблица ограничена до пятидесяти рядов.
Нет гарантии, что строки в таблице хранятся в определенном порядке. Для этого используйте предложение ORDER BY.
Также, строго говоря, в реляционной базе данных нет ни первой, ни последней строки. Да, вы можете выделить первую строку результата с помощью такого ключевого слова, как LIMIT или TOP, но они используются после получения и сортировки данных.
Добавить комментарий Отменить ответ
Ваш адрес email не будет опубликован. Обязательные поля помечены *
Комментарий *
Имя *
Email *
Сайт

Навигация по записям
Previous PostФото голубого неба с облаками высокого качества: D0 b3 d0 be d0 bb d1 83 d0 b1 d0 be d0 b5 d0 bd d0 b5 d0 b1 d0 be d0 be d0 b1 d0 bb d0 b0 d0 ba d0 b0 картинки, стоковые фото D0 b3 d0 be d0 bb d1 83 d0 b1 d0 be d0 b5 d0 bd d0 b5 d0 b1 d0 be d0 be d0 b1 d0 bb d0 b0 d0 ba d0 b0
Next PostДерево клипарт: Изображения Дерево клипарт | Бесплатные векторы, стоковые фото и PSD

Реляционная база данных состоит из: Базы данных — Урок 3. Реляционные базы данных

Структура реляционной базы данных | Основы реляционных баз данных

SQL

Самостоятельная работа

Что такое реляционная база данных?

Что такое реляционная база данных?

Установление связи между таблицами

Порядок строк произволен

Идентификация строк (первичный ключ)

Столбцы поименованы и пронумерованы

Пример базы данных

База данных SQl или NoSQL: какую выбрать для проекта?

Самые известные SQL-базы данных

В чем разница между реляционной и нереляционной базой данных — Разница Между

Ключевые области покрыты

Основные условия

Что такое реляционная база данных

Что такое нереляционная база данных

Разница между реляционной и нереляционной базой данных

Определение

Synonms

SQL

присоединяется

Типы

использование

Примеры

Заключение

Ссылка:

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

Реляционная БД

Структура реляционной таблицы

Готовые работы на аналогичную тему

6. Реляционные базы данных.. Информационные ресурсы Интернет, относящиеся к области бизнеса и коммерции

Похожие главы из других работ:

Реляционные связи между таблицами баз данных

—Создание базы данных и объектов базы данных

3. Создание базы данных и объектов базы данных

2.5 Ограничения на связи между таблицами базы данных хлебной базы

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

1.3 Этапы проектирование базы данных. Подходы к проектированию базы данных

2.5 Сравнительный анализ спроектированной базы данных и базы данных существующих информационных систем

Глава 3. Разработка логической модели базы данных. Нормализация таблиц базы данных

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

2.1.1 Реляционные СУБД

1.1.6 Реляционные отношения между таблицами базы данных

3.3 Определение логической структуры базы данных, разработка физической структуры базы данных с помощью ER-диаграмм (IDEF1X)

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

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

1.3 Реляционные БД: отношения, реляционные операции, ключи

4 — Основные понятия реляционных баз данных

Рекомендуемые файлы

Вопросы и ответы по реляционной базе данных и схемам

Концепции реляционных баз данных

Таблицы базы данных

Первичный и внешний ключи

Таблицы имеют первичный ключ

Примеры

Таблицы связаны внешними ключами

Пример

Прочие объекты базы данных

Запросы

Другие операторы SQL

Системные столы

XML-представление реляционной базы данных

Вступление

База данных

Стол

Запись

Поле

Нулевые значения

Сильная типизация

использованная литература

Постскриптум

Глава 7 Реляционная модель данных — Проектирование базы данных — 2-е издание

Основные концепции реляционной модели данных

Отношение

Стол

Колонна

Домен

Записи