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

1. Реляционная теория, ER и реляционная модель
2. БАЗА ДАННЫХ
3. ВЗАИМОСВЯЗЬ
4. ПРИЗНАК
5. ГРАФИК ОТНОШЕНИЙ
6. SHORT
7. КЛЮЧИ
8. СУПЕРКЛУЧ (КОКТЕЙЛЬ)
9. КАНДИДАТНЫЙ КЛЮЧ
10. ПЕРВИЧНЫЙ КЛЮЧ
11. ИНОСТРАННЫЙ КЛЮЧ
12. Отношения между таблицами (отношения между отношениями)
13. ОТНОШЕНИЕ 1: 1 (один к одному)
14. ОТНОШЕНИЕ 1: N (один ко многим)
15. ОТНОШЕНИЯ N: M (много ко многим)
16. суммирование

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

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

Разработанный в 70-х годах прошлого века, он уже зрелый 40-летний! Стоит познакомиться с этой моделью, потому что вы наверняка найдете ее применение практически в каждой компании. Описанные здесь основы применимы ко всем реализациям реляционных баз данных. В частности, такие системы, как MS SQL Server, Oracle, MySQL, PostgreSQL, DB2 или FireBird.

Полное понимание всей теории проектирования баз данных не обязательно для овладения техникой написания SQL-запросов. Это полезно, однако, во избежание логических ошибок или более осознанного написания запросов.

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

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

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

Реляционная теория, ER и реляционная модель

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

Проектирование каждой реляционной базы данных начинает концептуальный (абстрактный) этап, основанный на модели ER (Entity-Relationship Model), автором которой является др. Питер Чен ,

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

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

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

Теория отношений Модель ER Реляционные базы данных Таблица сущностей отношений Класс Экземпляр Строка Класс экземпляра (объект) Атрибут Атрибут Атрибут Столбец Свойство, атрибут Поле Домен / Тип Тип данных Тип данных
Далее я представлю концепции в упорядоченном направлении - всегда от концептуальной формы (модель ER) до практической (реляционная модель), встречающейся в конкретной реализации реляционной среды, например MS SQL Server.

БАЗА ДАННЫХ

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

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

ВЗАИМОСВЯЗЬ

В модели ER это просто ТАБЛИЦА или структура, в которой хранится информация об объектах определенного типа. Использование языка программистов - КЛАССЫ объектов определенного типа.

КЛАСС СУЩЕСТВ , ОТНОШЕНИЕ (модель ER) = TABLE (RDBMS) = CLASS (объектно-ориентированные языки)

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

Само слово RELACJA в польской языковой номенклатуре может быть немного запутанным здесь. Наконец, ОТНОШЕНИЯ и ОТНОШЕНИЯ являются синонимами, и, как вы можете видеть, они связаны с двумя совершенно разными мирами: ОТНОШЕНИЕ = ТАБЛИЦА И ОТНОШЕНИЕ - это действительно ОТНОШЕНИЕ :).

ПРИЗНАК

Каждое ОТНОШЕНИЕ описывается с использованием набора ATTRIBUTES. Стоит добавить, что эта коллекция всегда должна быть минимальной, необходимой для достижения бизнес-целей.

Каждый из ATTRUES принадлежит определенному ПОЛЕ, то есть он может принимать определенные значения (например, числовые, текстовые, даты и т. Д.) И имеет уникальное имя как часть ОТНОШЕНИЯ.

АТРИБУТ на практике это ничто иное как КОЛОННА. Поэтому при переводе в реляционную модель каждый TABLE описывается с использованием файла COLUMN. Каждый столбец COLUMN строго определен типом данных, то есть он хранит однородные значения из определенного домена DOMAIN (того же типа, например цифры, символы, даты и т. Д.). Имя столбца в таблице должно быть уникальным, потому что движок должен четко знать, к какому атрибуту мы будем обращаться.

АТРИБУТЫ данного ОТНОШЕНИЯ создают неупорядоченный набор. Их порядок в теории не имеет значения. Мы сами решаем, какие из них важны для нас в данный момент и в каком порядке мы хотим их видеть (ВЫБРАТЬ). Теперь небольшое упражнение - усердно работайте и найдите различия между сетами 1 и 2:

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

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

ГРАФИК ОТНОШЕНИЙ

Это просто его определение. Таким образом, информация о структуре, атрибуты, которые описывают данную ОТНОШЕНИЕ.

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

SHORT

Это единственная копия, объект, описанный всеми АТРИБУТАМИ данного ОТНОШЕНИЯ. Кротка - это не что иное, как ряд или запись. На языке программистов мы можем говорить о КЛАССНОЙ ВЫСТАВКЕ.

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

Теория урожая говорит еще один очень важный принцип. Нет дубликатов в наборе.

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

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

КЛЮЧИ

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

СУПЕРКЛУЧ (КОКТЕЙЛЬ)

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

КАНДИДАТНЫЙ КЛЮЧ

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

ПЕРВИЧНЫЙ КЛЮЧ

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

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

Что касается первичного ключа, вы можете встретить термин ЕСТЕСТВЕННЫЙ И ИСКУССТВЕННЫЙ КЛЮЧ . Естественным ключом будет столбец (или набор столбцов), описывающий данный класс объектов - например, NIP. Это атрибут, который с точки зрения системы воспринимается так же естественно, как название компании или ее REGON. В действительности, однако, ему присваивается искусственный идентификатор, но он настолько распространен, что мы можем рассматривать его как естественный ключ. Другим примером естественного ключа может быть адрес электронной почты пользователя системы. Обычно мы предполагаем, что два пользователя не могут иметь один и тот же адрес.

Искусственный ключ - это обычно дополнительный столбец, созданный разработчиком базы данных для идентификации записей с максимально коротким ключом. Как правило, это будет числовое значение целочисленного типа (INT, SMALLINT, BIGINT). Это связано с производительностью или другими аспектами, которые заслуживают отдельной статьи.
Самое главное, что первичный ключ однозначно идентифицирует записи и является максимально коротким.

ИНОСТРАННЫЙ КЛЮЧ

Это атрибут или набор атрибутов, которые указывают на МАСТЕР-КЛЮЧ в другой ССЫЛКЕ (таблица). Внешний ключ - это не что иное, как отношения, отношения между двумя таблицами.

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

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

Отношения между таблицами (отношения между отношениями)

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

Мы будем использовать знания об их существовании и моделировании, например, в написание запросов ко многим таблицам ,

ОТНОШЕНИЕ 1: 1 (один к одному)

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

Примером могут быть производные ОТНОШЕНИЯ. База данных AdventureWorks2008 содержит следующий пример:

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

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

ОТНОШЕНИЕ 1: N (один ко многим)

Это наиболее распространенные отношения. Мы определяем в нем, что каждый элемент из набора A (строка таблицы A) может быть связан со многими элементами из набора B. Пример из базы данных Northwind - Продукты и Категории. В этой модели многие товары могут попасть в одну категорию.

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

ОТНОШЕНИЯ N: M (много ко многим)

Это всегда реализуется как два отношения 1: N. Поэтому, если мы хотим смоделировать отношение N: M между двумя таблицами, нам понадобится третья таблица - соединитель . Примером является фрагмент каждой системы заказов, например, как в базе данных NorthWind. У нас есть заказы и продукты. Каждый из продуктов можно заказать несколько раз, в разных заказах. Каждый заказ может содержать много предметов (товаров). Таблица соединений, реализующая связь 1: N, будет таблицей Order Details.

суммирование

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