Как работают реляционные базы данных (Часть 1)

Как работают реляционные базы данных (Часть 1)

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

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

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

· Тип данных – тип значений конкретного столбца.

· Домен (domain) – множество всех допустимых значений атрибута.

· Атрибут (attribute) – заголовок столбца таблицы, характеризующий поименованное свойство объекта, например, фамилия студента, дата оформления заказа, пол сотрудника и т.п.

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

· Отношение (relation) – таблица, отражающая информацию об объектах реального мира, например, о студентах, заказах, сотрудниках, жителях и т.д.

· Первичный ключ (primary key) – поле (или набор полей) таблицы, однозначно идентифицирующий каждую из ее записей.

· Альтернативный ключ – это поле (или набор полей), несовпадающее с первичным ключом и уникально идентифицирующий экземпляр записи.

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

· Реляционная модель данных (РМД)– организация данных в виде двумерных таблиц.

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

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

2. Каждое значение, записывается на пересечении строки и столбца – является атомарным (неразделимым).

3. Значения каждого поля должны быть одного типа.

4. Каждое поле имеет уникальное имя.

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

Основные элементы БД:

Поле – элементарная единица логической организации данных. Для описания поля используются следующие характеристики:

· имя, например, Фамилия, Имя, Отчество, Дата рождения;

· тип, например, строковый, символьный, числовой, датовый;

· длина, например, в байтах;

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

Запись – совокупность значений логически связанных полей.

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

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

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

Представление данных – сохраняемый в базе данных именованный запрос на выборку данных (из одной или нескольких таблиц).

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

Отчет– компонент системы, основное назначение которого – описание и вывод на печать документов на основе информации из БД.

Общая характеристика работы с РБД:

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

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

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

28. АЛГОРИТМИЧЕСКИЕ ЯЗЫКИ. ТРАНСЛЯТОРЫ (ИНТЕРПРЕТАТОРЫ И КОМПИЛЯТОРЫ). АЛГОРИТМИЧЕСКИЙ ЯЗЫК БЕЙСИК. СТРУКТУРА ПРОГРАММЫ. ИДЕНТИФИКАТОРЫ. ПЕРЕМЕННЫЕ. ОПЕРАТОРЫ. ОБРАБОТКА ОДНОМЕРНЫХ И ДВУХМЕРНЫХ МАССИВОВ. ФУНКЦИИ ПОЛЬЗОВАТЕЛЯ. ПОДПРОГРАММЫ. РАБОТА С ФАЙЛАМИ ДАННЫХ.[15]

Язык высокого уровня – язык программирования, понятия и структура которого удобны для восприятия человеком.

Алгоритмический язык (Algorithmic language) – язык программирования – искусственный (формальный) язык, предназначенный для записи алгоритмов. Язык программирования задается своим описанием и реализуется в виде специальной программы: компилятора или интерпретатора. Примерами алгоритмических языков служат – Borland Pascal, C++, Basic и т.д.

Основные понятия алгоритмического языка:

Состав языка:

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

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

Выражения – это последовательность элементарных конструкций и символов,

Оператор – последовательность выражений, элементарных конструкций и символов.

Описание языка:

Описание символов заключается в перечислении допустимых символов языка. Под описанием элементарных конструкций понимают правила их образования. Описание выражений – это правила образования любых выражений, имеющих смысл в данном языке. Описание операторов состоит из рассмотрения всех типов операторов, допустимых в языке. Описание каждого элемента языка задается его СИНТАКСИСОМ и СЕМАНТИКОЙ.

Синтаксические определения устанавливают правила построения элементов языка.

Семантика определяет смысл и правила использования тех элементов языка, для которых были даны синтаксические определения.

Символы языка – это основные неделимые знаки, в терминах которых пишутся все тексты на языке.

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

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

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

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

Трансляторы –(англ. translator — переводчик) — это программа-переводчик. Она преобразует программу, написанную на одном из языков высокого уровня, в программу, состоящую из машинных команд.

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

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

1.Компиляция: Компилятор (англ. compiler — составитель, собиратель) читает всю программу целиком, делает ее перевод и создает законченный вариант программы на машинном языке, который затем и выполняется.

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

2. Интерпретация: Интерпретатор (англ. interpreter — истолкователь, устный переводчик) переводит и выполняет программу строка за строкой.

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

Откомпилированные программы работают быстрее, но интерпретируемые проще исправлять и изменять

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

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

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

Реляционные базы данных для чайников

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

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

Табличные данные могут быть вставлены, восстановлены, обновлены и удалены. Для пакета этих операций была создана специальная аббревиатура CRUD (Create-Read-Update-Delete).

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

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

Шаг 1. Подготовка данных

Для того чтобы нам было с чем работать, я набрал в твиттере запрос “#databases” и сформировал таблицу из 10 записей:

Таблица 1

В первую очередь, давайте разберёмся с колонками:

• full_name: имя пользователя
• username: логин в Twitter-е
• text: текст твита
• created_at: время создания твита
• following_username: список пользователей, разделённых запятыми, которые подписались на этот твитт. Для краткости я сократил этот список до 2 имён.

Это реальные данные. Если хотите, вы можете их найти и обновить.

Хорошо. Теперь все наши данные находятся в одном месте. Даёт ли это нам возможность легко осуществить поиск по ним? Не совсем. Данная таблица далека от идеала. Во-первых, в некоторых столбцах у нас есть повторяющиеся записи: к примеру, в х “username” и “following_username”. Также колонка “following_username” нарушает правила реляционных моделей, т.к. её в ячейках присутствует более 1 значения (записи разделены запятыми).

К тому же у нас попадаются дубликаты и в строках.

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

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

Шаг 2. Избавляемся от дубликатов в столбцах

Как было оговорено выше, столбцы “username” и “following_username” содержат дубликаты данных. Они возникли в результате того, что я хотел отобразить отношения между твиттами и пользователями. Давайте улучшим нашу структуру БД, разделив существующую таблицу на две: в одной будем хранить информацию, а в другой – отношения между записями.

Поскольку @Brett_Englebert подписан на @RealSkipBayless, то в таблице “following” отобразим это следующим образом: имя @Brett_Englebert поместим в колонку “from_user”, а @RealSkipBayless в “to_user.” Давайте посмотрим, как будет выглядеть таблица “following” после разделения Таблицы 1:

Таблица 2. following

Таблица 3. users

Уже лучше. Теперь в таблице “users” (Таблица 3) у нас хранится только информация о твиттах, а в таблице following (Таблица 2) – зависимость пользователей.

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

Шаг 3. Удаление повторений из строк

Теперь мы займёмся устранением других проблем, а именно, избавимся от дубликатов в строках таблицы “users”. Поскольку пользователи @AndyRyder5 и @Brett_Englebert разместили по несколько твиттов, то их имена в таблице “users” (Таблица 3) дублируются в колонке full_name. Данная проблема также решается разделением таблицы “users”.

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

Таблица 4. tweets

Таблица 5. users

После разделения в таблице users (Таблица 5) у нас присутствуют уникальные (не повторяющиеся) строки.

Данный процесс удаления дубликатов из строк называется приведением ко второй нормальной форме.

Шаг 4. Объединяем таблицы на основе ключей

Итак, в результате наших действий, Таблица 1 была разбита на 3 части: following (Таблица 2), tweets (Таблица 4), users (Таблица 5). Все дубликаты устранены. Для того чтобы в дальнейшем мы могли с лёгкостью извлекать данные из этой структуры, независимые друг от друга таблицы мы должны связать специальными отношениями, которые будут давать нам информацию о том, какому пользователю принадлежит какой твит, и кто на кого подписан.

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

Вообще говоря, в Таблице 4 и 5 мы уже это сделали. В таблице “users” первичным ключом является колонка “username”, потому что логин пользователя должен быть уникальным значением и не может повторяться. В таблице “tweets” мы используем данный ключ для обозначения связи между пользователем и твитом. Колонка “username” в таблице “tweets” называется внешним ключом.

Если вы когда-то работали с базами данных, то у вас может возникнуть вопрос: можем ли мы использовать колонку “username” в качестве первичного ключа?

С одной стороны, это может упростить процесс поиска, ведь мы не используем никаких числовых ID. С другой стороны, что если пользователь захочет поменять свой логин? Это может привести к огромному количеству проблем. Для того чтобы не попасть в подобную ситуацию, лучше воспользоваться числовыми ID. Всё зависит от вашей системы. Если вы предоставляете вашим пользователям возможность менять логины, то лучше в качестве первичного ключа использовать автоинкрементированное числовое поле ID. В противном случае, колонка “username” вполне подойдёт для этой роли. Я оставлю всё как есть.

Давайте посмотрим на таблицу tweets (Таблица 4). Первичный ключ должен быть уникальным для каждой строки. Какую колонку в данной таблице мы можем выбрать для этой роли? Колонка “created_at” не подойдёт, т.к. в принципе 2 разных пользователя могут в одно и то же время опубликовать запись. С колонкой “text” та же история: два разных пользователя могут создать твит с текстом “Hello World”. Колонка “username” в данной таблице является внешним ключом для обозначения связи между пользователем и твитом. Итак, поскольку все возможные варианты нам не подходят, то лучшим решением будет добавление колонки id, которая будет первичным ключом для данной таблицы.

Таблица 6. tweets с колонкой id

Глава 1. РЕЛЯЦИОННЫЕ БАЗЫ ДАННЫХ. ВВЕДЕНИЕ.

ВВЕДЕНИЕ

SQL (произносится обычно “СЭКВЭЛ” (или, более англообразно – СКЬЮЭЛ)) означает Структурированный Язык Запросов.

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

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

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

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

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

В этой книге мы будем в основном следовать стандарту ANSI, но одновременно иногда будем давать и некоторые наиболее распространённые отклонения от его стандарта.

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

ПРЕЖДЕ ЧЕМ ВЫ СМОЖЕТЕ ИСПОЛЬЗОВАТЬ SQL, вы должны понять, что такое реляционные базы данных.

В этой главе мы объясним и покажем, насколько РБД полезны. Мы не будем обсуждать SQL именно здесь, и, если вы уже знаете эти понятия достаточно хорошо, вы можете просто пропустить эту главу.
В любом случае вы должны просмотреть три таблицы, которые предоставляются и объясняются в конце главы; они станут основой наших примеров в этой книге. Вторая копия этих таблиц находится в Приложении E, и мы рекомендуем скопировать их для удобства ссылки к ним.

ЧТО ТАКОЕ “РЕЛЯЦИОННАЯ БАЗА ДАННЫХ”?

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

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

Адресная книга могла бы выглядеть следующим образом:

Как работают реляционные базы данных (Часть 1)

Поддержать автора проекта

Если материал сайта вам помог в решении той или иной проблемы, пожалуйста, поддержите автора проекта любой суммой. Все вырученные средства пойдут на оплату серверов 🙂

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

Категория: Введение / Добавил: Артём

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

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

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

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

Давайте используем пример адресной книги для того, чтобы обсудить базу данных, которую можно реально использовать в деловой жизни. Предположим, что индивидуумы первой таблицы являются пациентами больницы. Дополнительную информацию о них можно хранить в другой таблице. Столбцы второй таблицы могут быть поименованы таким образом: 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:

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

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

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

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

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

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

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

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

Данные

Наша база данных будет состоять из двух таблиц: “ Student ” ( студенты ) и “ Class ” ( предметы ), и содержать в себе информацию, соответственно, о студентах и изучаемых ими предметах.

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

С учётом этой информации нормализуем данные следующим образом:

1. Таблица студентов будет иметь следующие поля:

• идентификатор студента (Student ID);
• имя студента (Student Name);
• операционная система (Operating System);

2. Таблица предметов будет иметь следующие поля:

• идентификатор предмета (Class ID);
• название предмета (Class Name);
• преподаватель (Instructor).

Теперь заполним обе таблицы данными:

Отношения между объектами

Теперь, используя имеющиеся данные, определим отношения и объекты этих отношений.

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

Атрибуты отношений: первичные и внешние ключи

Теперь, когда отношения между объектами ясны, определим атрибуты, которые мы будем использовать для сопоставления объектов друг другу.

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

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

Первичный ключ идентифицирует каждую строку в таблице.

Для установления отношения мы должны сопоставить каждому первичному ключу внешний ключ.

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

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

• идентификатор студента (Student ID) – внешний ключ, ссылающийся на идентификатор студента в таблице студентов;
• идентификатор предмета (Class ID) – внешний ключ, ссылающийся на идентификатор предмета в таблице предметов.

Использование таблицы перекрёстных ссылок

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

Каждая строка получившейся таблицы однозначно определяется собственным первичным ключом – идентификатором зачисления ( Enrollment ID ).

Кроме первичного ключа, таблица содержит ещё два поля:

• внешний ключ Student ID ссылается на первичный ключ Student ID в таблице студентов;
• внешний ключ Class ID ссылается на первичный ключ Class ID в таблице предметов.

Заключение

В нашей сегодняшней статье мы изучили принципы организации реляционных баз данных. Слово « реляционные » можно определить как « характеризуемые отношениями », от латинского слова “ relatio ” – « отношение ».

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

Как же применить изученные нами примеры на практике?

Разумеется, для этого можно использовать специальные программы, которые известны, как « Системы управления реляционными базами данных » ( Relational database management systems , RDBMS ). Но это – материал для другой статьи.

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

Данная публикация представляет собой перевод статьи « The Zen of Relational Database: Learn the Basics Here » , подготовленной дружной командой проекта Интернет-технологии.ру

Реляционная база данных. Проектирование реляционных баз данных

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

Таблица как важная часть реляционной БД

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

Таблицы в таких БД обладают следующими свойствами: – столбцы размещаются в определённом порядке, формируемом при создании таблицы. Таблица может не иметь ни одной строки, однако хотя бы один столбец должен быть обязательно; – в таблице не может быть 2-х одинаковых строк. Если вспомнить математику, то такие таблицы называют отношениями (relation). Именно поэтому данные БД и считаются реляционными; – каждый столбец в пределах таблицы имеет уникальное имя, а все значения в одном столбце должны быть одного типа (дата, текст, число и т. п.); – на пересечении строки и столбца может быть только атомарное значение (значение, не состоящее из группы значений). Таблицы, которые удовлетворяют этим условиям, считаются нормализованными.

Приведём пример

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

В теории всё можно расположить в одной таблице, а именно:

Однако такое расположение противоречит атомарности, причём в столбцах «Созданные сообщения» и «Созданные темы» возможно неограниченное число значений. Целесообразнее всего разбить таблицу на три:

Теперь таблица «Пользователи» соответствует правилам. Но вот таблицы «Сообщения» и «Темы» — нет, т. к. не должно быть 2-х одинаковых строк. В нашем же случае один и тот же пользователь может написать 2 одинаковых сообщения:

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

Ключи в БД

Первичный ключ (РК, primary key) — столбец, значения которого различны во всех строках. РК бывают логические (естественные) и суррогатные (искусственные).

Например, для таблицы «Пользователи» первичным ключом может быть столбец e-mail, т. к. не бывает 2-х пользователей с одним и тем же e-mail.

На практике для хранения и обработки данных рекомендуют применять суррогатные ключи (их использование позволит абстрагировать РК от реальных данных). Это важно, если пользователь, вдруг, сменит e-mail, а ведь первичные ключи нельзя менять.

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

Вносим первичные ключи в наши таблицы:

Заметьте, что каждая запись в таблице уникальна. Осталось лишь установить соответствие между сообщениями и темами, используя первичные ключи. Добавляем в таблицу с сообщениями ещё одно поле:

Теперь становится ясно, что сообщение id=2 относится к теме «О рыбалке» (id=4), которая создана Васей, а остальные принадлежат теме «О рыбалке», созданной Кириллом (id=1). Такое поле будет называться внешний ключ (FK, foreign key). При этом каждое значение данного поля сопоставляется с каким-либо первичным ключом из таблицы «Темы». В результате устанавливается однозначное соответствие между темами и сообщениями.

Ещё момент: допустим, добавляется новый пользователь по имени Вася.

Как узнать, какой же из «Васей» оставил сообщение? Для этого поля «Автор» в наших таблицах «Сообщения» и «Темы» мы тоже сделаем внешними ключами:

Итак, наша база данных фактически готова. Схематично она выглядит так:

В этой небольшой базе данных лишь 3 таблицы. А что делать, если их 10 либо 200? Ясно, что всё не так просто. Именно поэтому любое проектирование реляционных баз данных начинается с разработки концептуальной модели данных.

Концептуальная модель базы данных

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

Простой пример — интернет-магазин. В нём есть товары, поставляемые поставщиками и заказываемые покупателями. Это три объекта и две связи:

Делая поставку, поставщик подтверждает её документами. Аналогично и с покупателем. Таким образом, и поставку, и покупку можно рассматривать в качестве самостоятельных объектов.

Итого 5 объектов и 4 связи. Из них: – 2 связи типа «один ко многим» (один поставщик может делать несколько поставок; один покупатель может делать несколько покупок); – 2 связи типа «многие ко многим» (каждая поставка может включать несколько товаров, причём одинаковый товар может быть в нескольких поставках; аналогичная ситуация по линии «Покупка — Товар»).

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

Видим, что в структуре появились ещё 2 объекта — «Журнал поставок» и «Журнал покупок» со связями типа «один ко многим» (каждый журнал может включать несколько поставок/покупок, но каждая поставка/покупка включает лишь один журнал).

Атрибуты таблицы

Каждый объект интернет-магазина имеет свои атрибуты:

В результате мы создали концептуальную модель будущей базы данных. Точнее говоря, речь идёт лишь о части БД, т. к. мы не учли склады, сотрудников и т. п. Собственно, при обширной предметной области данные лучше разбить на несколько локальных областей. Как правило, объём должен быть в пределах 5-7 объектов. И лишь после создания локальных моделей выполняется их объединение в общую сложную схему. В нашем случае ограничимся созданной моделью. Однако теперь давайте преобразуем её в реляционную модель данных.

Проектирование реляционной базы данных. Преобразование модели в реляционную

Преобразование концептуальной модели данных в реляционную — важная часть проектирования БД. Процесс включает в себя: – построение набора предварительных таблиц; – указание РК; – выполнение нормализации.

Из набора таблиц состоят наши объекты, а из полей таблиц — атрибуты объектов:

Итак, мы определились с таблицами, полями, РК и FK. Следует отметить, что в таблицах «Журнал покупок» и «Журнал поставок» РК составные, т. к. состоят из 2-х полей.

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

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

Нормализация бывает: – 1-й нормальной формы (1НФ); – 2НФ; – 3НФ; – НФБК (нормальной формы Бойса-Кодда); – 4НФ; – 5НФ.

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

Если говорить о реляционных базах данных, то минимум — это 1НФ. Однако в процессе проектирования специалисты по СУБД стремятся нормализовать базу хотя бы до уровня 3НФ, исключив тем самым избыточность данных и аномалии. Это важно, если мы стремимся получить качественный результат проектирования. Однако подробное описание нормализации данных выходит за рамки нашей статьи, поэтому давайте просто посмотрим, как будет выглядеть наша база на уровне 3НФ:

Итак, в процессе проектирования мы преобразовали концептуальную модель в реляционную. Следующий этап — реализация её в конкретной СУБД. Для этого потребуется как сама СУБД, так и знание языка SQL. Например, прекрасно подойдёт СУБД MySQL или какая-нибудь другая СУБД.

Подводим итоги проектирования

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

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

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

В заключение, добавим, что умение проектировать базы вам никогда не помешает. А научиться всему этому вы сможете на нашем курсе «Реляционные СУБД». Ждём вас!