§3.1. Базы данных

§3.1. Табличные базы данных

Содержание урока

Базы данных

Табличные базы данных

Тип поля

База данных «Процессоры»

Контрольные вопросы

Табличные базы данных

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

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

Поле базы данных — это столбец таблицы, содержащий значения определенного свойства.

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

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

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

Ключевое поле — это поле, значения которого однозначно определяют запись в таблице.

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

Следующая страница Тип поля

Cкачать материалы урока

§3.1. Базы данных

Содержание урока

Базы данных

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

Иерархическая модель данных

Сетевая модель данных

Контрольные вопросы

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

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

Слово «реляционная» происходит от английского «relation» — отношение. Это строгое математическое понятие, относящееся к теории множеств. Для пользователя базы данных отношения удобно представлять в виде неупорядоченных таблиц. Таблицы состоят из столбцов и строк и содержат данные.

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

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

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

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

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

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

Тип поля определяется типом данных, которые оно содержит.

Поля могут содержать данные следующих основных типов:

• Текстовый. Содержит до 255 символов.
• Числовой. Число.
• Счетчик. Вид числового типа. Последовательность целых чисел, которые задаются автоматически при вводе записей. Эти числа не могут быть изменены пользователем.
• Денежный. Вид числового типа. Число в денежном формате.
• Дата/Время. Дата и/или время.
• Логический. Значение Истина (Да) или Ложь (Нет).
• Гиперссылка

. Ссылка на информационный ресурс в Интернете (например, Web-сайт).

Поле каждого типа имеет свой набор свойств.

Наиболее важными свойствами полей являются:

• Размер поля. Определяет максимальную длину текстового или числового поля.
• Формат поля. Устанавливает формат данных.
• Непустое поле. Указывает на то, что данное поле обязательно надо заполнить.

Рассмотрим, например, базу данных «Процессоры», которая содержит перечень объектов (процессоров).

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

• № п/п (счетчик),
• Название процессора (текстовое поле),
• Частота (числовое поле),
• Год выпуска (поле даты),
• Наличие нескольких ядер (логическое поле)

• Сайт производителя (гиперссылка) (табл. 3.1).

Таблица 3.1. Реляционная база данных, представленная в виде таблицы

№ п/п	Название процессора	Частота	Год выпуска	Наличие нескольких ядер	Сайт производителя
1	Intel Pentium	266	1993	Нет	www.intel.com
2	AMD Duron	1300	1999	Нет	www.amd.com
3	Intel Pentium 4	3200	2000	Нет	www.intel.com
4	AMD Antlon X2	3200	2005	Да	www.amd.com
5	Intel Core 2 Quad	2900	2008	Да	www.intel.com

Следующая страница Иерархическая модель данных

Cкачать материалы урока

Руководство по проектированию реляционных баз данных (4-6 часть из 15) [перевод]

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

4. ТАБЛИЦЫ И ПЕРВИЧНЫЕ КЛЮЧИ

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

В таблице имеются 6 уроков. Все 6 – разные, но для каждого урока значения одинаковых полей хранятся в таблице, а именно: tutorial_id (идентификатор урока), title (заголовок)и category (категория).

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

Первичные ключи в повседневной жизни

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

Несколько примеров

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

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

Что характеризует первичный ключ? Характеристики первичного ключа.

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

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

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

Первичный ключ уникален.

Первичный ключ всегда имеет уникальное значение. Представьте, что его значение не уникально. Тогда его бы нельзя было использовать для того, чтобы идентифицировать данные в таблице. Это значит, что какое-либо значение первичного ключа может встретиться в столбце, который выбран в качестве первичного ключа, только один раз. РСУБД устроены так, что не позволят вам вставить дубликаты в поле первичного ключа, получите ошибку.
Еще один пример. Представьте, что у вас есть таблица с полями first_name и last_name и есть две записи:

| first_name | last_name |
| vasya |pupkin |
| vasya |pupkin |

Т.е. есть два Васи. Вы хотите выбрать из таблицы какого-то конкретного Васю. Как это сделать? Записи ничем друг от друга не отличаются. Вот здесь и помогает первичный ключ. Добавляем столбец id (классический вариант синтетического первичного ключа) и…

Id | first_name | last_name |
1 | vasya |pupkin |
2 | vasya |pupkin |

Теперь каждый Вася уникален.

Типы первичных ключей.

Обычно первичный ключ – числовое значение. Но он также может быть и любым другим типом данных. Не является обычной практикой использование строки в качестве первичного ключа (строка – фрагмент текста), но теоретически и практически это возможно.
Составные первичные ключи.
Часто первичный ключ состоит из одного поля, но он может быть и комбинацией нескольких столбцов, например, двух (трех, четырех…). Но вы помните, что первичный ключ всегда уникален, а значит нужно, чтобы комбинация n-го количества полей, в данном случае 2-х, была уникальна. Подробнее об этом расскажу позднее.

Автонумерация.

Поле первичного ключа часто, но не всегда, обрабатывается самой базой данных. Вы можете, условно говоря, сказать базе данных, чтобы она сама автоматически присваивала уникальное числовое значение каждой записи при ее создании. База данных, обычно, начинает нумерацию с 1 и увеличивает это число для каждой записи на одну единицу. Такой первичный ключ называется автоинкрементным или автонумерованным. Использование автоинкрементных ключей – хороший способ для задания уникальных первичных ключей. Классическое название такого ключа – суррогатный первичный ключ [Как и упоминалось выше. – прим. перев.]. Такой ключ не содержит полезной информации, относящейся к сущности (объекту), информация о которой хранится в таблице, поэтому он и называется суррогатным.

5. СВЯЗЫВАНИЕ ТАБЛИЦ С ПОМОЩЬЮ ВНЕШНИХ КЛЮЧЕЙ

Когда я начинал разрабатывать базы данных я часто пытался сохранять информацию, которая казалась родственной, в одной таблице. Я мог, например, хранить информацию о заказах в таблице клиентов. Ведь заказы принадлежат клиентам, верно? Нет. Клиенты и заказы представляют собой отдельные сущности в базе данных. И тому и другому нужна своя собственная таблица. А записи в этих двух таблицах могут быть связаны для того, чтобы установить отношения между ними. Проектирование базы данных – это решение двух вопросов:

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

Один-ко-многим.

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

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

Какую информацию мы будем хранить? Решаем первый вопрос.

Для начала мы определимся какую информацию о заказах и о клиентах мы будем хранить. Чтобы это сделать мы должны задать себе вопрос: “Какие единичные блоки информации относятся к клиентам, а какие единичные блоки информации относятся к заказам?”

Проектируем таблицу клиентов.

Заказы действительно принадлежат клиентам, но заказ – это это не минимальный блок информации, который относится к клиентам (т.е. этот блок можно разбить на более мелкие: дата заказа, адрес доставки заказа и пр., к примеру).
Поля ниже – это минимальные блоки информации, которые относятся к клиентам:

• customer_id (primary key) – идентификатор клиента
• first_name — имя
• last_name — отчество
• address — адрес
• zip_code – почтовый индекс
• country — страна
• birth_date – дата рождения
• username – регистрационное имя пользователя (логин)
• password – пароль

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

Создание таблицы в SQLyog. Обратите внимание, что выбран флажок первичного ключа (PK) для поля customer_id. Поле customer_id является первичным ключом. Также выбран флажок Auto Incr, что означает, что база данных будет автоматически подставлять уникальное числовое значение, которое, начиная с нуля, будет каждый раз увеличиваться на одну единицу.

Проектируем таблицу заказов.
Какие минимальные блоки информации, необходимые нам, относятся к заказу?

• order_id (primary key) – идентификатор заказа
• order_date – дата и время заказа
• customer – клиент, который сделал заказ

Ниже – пример таблицы в SQLyog.

Проект таблицы. Поле customer является ссылкой (внешним ключом) для поля customer_id в таблице клиентов.

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

Создание связи по внешнему ключу.

Вы можете задаться вопросом: “Каким образом я могу убедиться или как я могу увидеть, что поле customer в таблице заказов ссылается на поле customer_id в таблице клиентов”. Ответ прост – вы не можете сделать этого потому, что я еще не показал вам как создать связь.
Ниже – окно SQLyog с окном, которое я использовал для создания связи между таблицами.

Создание связи по внешнему ключу между таблицами заказов и клиентов.

В окне выше вы можете видеть, как поле customer таблицы заказов слева связывается с первичным ключом (customer_id) таблицы клиентов справа.

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

Заказы связаны с клиентами через поле customer, которое ссылается на таблицу клиентов.

На изображении вы видите, что клиент mary поместила три заказа, клиент pablo поместил один, а клиент john – ни одного.
Вы можете спросить: “А что же именно заказали все эти люди?” Это хороший вопрос. Вы возможно ожидали увидеть заказанные товары в таблице заказов. Но это плохой пример проектирования. Как бы вы поместили множественные продукты в единственную запись? Товары – это отдельные сущности, которые должны храниться в отдельной таблице. И связь между таблицами заказов и товаров будет являться связью один-ко-многим. Я расскажу об этом далее.

6. СОЗДАНИЕ ДИАГРАММЫ СУЩНОСТЬ-СВЯЗЬ

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

Сущности.

Вы можете задаться вопросом, что же такое сущность. Нуу… это “вещь” в системе. Там. Моя Мама всегда хотела, чтобы я стал учителем потому, что я очень хорошо объясняю различные вещи.

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

Давайте возьмем интернет-магазин для примера. Интернет-магазин продает товары. Товар мог бы стать очевидной сущностью в системе интернет-магазина. Товары заказываются клиентами. Вот мы с вами и увидели еще две очевидных сущности: заказы и клиенты.

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

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

Давайте не будет слишком академичными.

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

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

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

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

Связи.

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

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

большой обзор типов и подходов. Доклад Яндекса / Блог компании Яндекс / Хабр

Это конспект лекции Татьяны Денисовой tdenisova — бэкенд-разработчика в Яндекс.Учебнике. Вы узнаете, какие бывают базы данных, какие их особенности важно помнить, как в работе с данными учитывать характеристики системы и планы масштабирования, в какую из тем нужно углубиться для решения конкретной задачи. А также как при возникновении багов определить, является ли работа с БД источником проблемы (и если да, то в какую сторону копать).

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

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

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

Сначала мы с вами поговорим о данных. Что это такое вообще? Вокруг нас много фактов, много сведений, но пока они никак не собраны, они для нас бесполезны. Мы их собираем, структурируем и сохраняем. И именно это сохраненное структурирование называется данными, а то, что их хранит, — базой данных. Но пока эти данные просто где-то лежат собранные, они для нас тоже в принципе бесполезны. Поэтому существует прослойка над базами данных — СУБД. Это то, что позволяет нам доставать данные, сохранять их и анализировать. Таким образом, данные, которые мы получаем, мы превращаем в информацию, которую уже можем вывести пользователю. Пользователь получает знания и применяет их.

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

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

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

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

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

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

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

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

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

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

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

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

Для такого случая, для ускорения поиска, используют индексы. Самая простая ассоциация с индексами — это содержание в книге. Если вам нужно в книге найти информацию, вы можете просто пролистать книгу, а можете зайти в оглавление. Индексы — это своего рода оглавление.

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

Прошу обратить внимание, как именно мы будем работать с данными. Не с тем, какие у нас есть строки в таблице, а вообще. Индексы строятся по принципу того, какие запросы вы делаете.

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

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

Как оно работает? У нас есть номер чата, это целое значение, и дерево выстраивается по такому принципу: то, что слева от узла значений меньше, справа от узла значений больше. Что нам дает такая структура? Если посмотреть на итоговые листы этого дерева, то все значения внизу упорядочены. Это огромный плюс в приросте производительности. Сейчас покажу, почему.

Например, мы ищем значение. Одно значение искать очень просто. Мы проходим вниз по дереву или влево, вправо — в зависимости от того, больше это значение или меньше.

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

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

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

Что тут важно знать? Казалось бы, классная структура — мы сейчас на каждый столбец построим по такому дереву и будем искать. Как вы думаете, почему это не сработает? Почему у нас не будет прироста скорости, если мы на каждый столбец построим по дереву? (…)

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

На самом деле удаление не перестроит, а просто фрагментирует это дерево, и у нас получатся много пустых значений. Будет огромное дерево с пустыми значениями. Но именно при update и при create эти деревья каждый раз будут перестраиваться. В итоге мы получим огромный overhead над всех этой структурой. И вместо того, чтобы быстренько достать данные и ускорить базу данных, мы будем замедлять наши запросы.

Что еще важно знать? Когда вы будете работать с базой, посмотрите, почитайте, какие индексы в ней существуют, потому что в каждой базе свои реализации, свои разные индексы. Есть индексы для ускорения, есть индексы для обеспечения целостности. Один из самых простых — как раз primary key. Это тоже индекс уникальности. И относительно вашей базы смотрите, как он устроен, как с ним работать, потому что это такие знания, которые вам помогут писать наиболее оптимальные запросы.

Мы обсудили, что нужно иметь в виду накладные расходы на поддержание индексов при вставке данных. Забыла сказать, что когда вы выстраиваете индекс, он должен обладать высокой селективностью. Что это значит?

Посмотрим на это дерево. Мы понимаем, что если стоит индекс на true false, то получается просто два огромных куска дерева слева и справа. И мы проходимся в лучшем случае по 50% таблицы, что на самом деле не очень эффективно. Лучше всего делать индекс именно на те столбцы, у которых наиболее разные значения. Таким образом мы ускорим наши выборки.

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

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

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

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

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

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

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

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

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

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

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

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

Давайте посмотрим на конкретных примерах, о чем идет речь.

Представим, что есть два пользователя, которые хотят забронировать переговорку. Пользователь 1 видит, что переговорка в это время свободна, и начинает ее бронировать. У него открывается окошко, и он думает, кого же из коллег я позову. Пока он думает, пользователь 2 тоже видит, что переговорка свободна, и открывает себе окошко редактирования.

В итоге, когда пользователь 1 сохранил эти данные, он ушел и думает, что все отлично, переговорка забронирована. Но в это время пользователь 2 перезаписывает его данные, и получается так, что переговорка закрепилась за пользователем 2. Это называется конфликтом данных. И мы должны уметь показывать эти конфликты людям и как-то их разрешать. Именно в этом месте у нас будет перезапись.

Как это сделать? Мы можем просто заблокировать переговорку на какое-то время, пока пользователь 1 думает. Если он сохранил данные, то пользователю 2 мы не разрешим это делать. Если он данные отпустил и не стал сохранять, то пользователь 2 сможет забронировать переговорку. Подобную картину вы могли видеть, когда покупаете билеты в кино. Вам дается 15 минут на то, чтобы оплатить билеты, иначе они вновь предоставляются другим людям, которые тоже могут их взять и оплатить.

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

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

Для решения таких проблем существует понятие транзакции — атомарного, целостного выполнения всех трех операций одновременно.

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

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

У транзакций есть четыре свойства, четыре требования к ним. Это Atomicity, Consistency, Isolation и Durability — атомарность, согласованность, изоляция и сохраняемость данных. Что это за свойства?

• Atomicity или атомарность — гарантия того, что операция, которую вы выполняете, будет выполнена полностью, что она не будет выполнена частично. Таким образом мы гарантируем, что общая согласованность данных в нашей базе будет и до операции, и после.
• Consistency или согласованность — больше бизнес-правило, скорее не со стороны СУБД или самой базы данных. Согласованность не нужно путать с целостностью (Integrity). Если кто-то из вас работал с базами данных и передавал данные с айдишника, который не существует, то вы могли получать Integrity Error, ошибку целостности: система не понимала, что с ним делать. Именно наличие взаимосвязи отношений и уникальности ключей называется целостностью. А согласованность — то, что мы пишем в самой транзакции.

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

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

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

Существует четыре основных класса проблем — потерянное обновление, «грязное» чтение, неповторяющееся чтение и фантомное чтение. Рассмотрим подробнее.

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

Проблема «грязного» чтения возникает, когда пользователь видит временные изменения другого пользователя, которые потом могут быть откатаны или просто сделаны временно.

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

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

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

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

Чтобы решать эти проблемы, есть четыре уровня изоляции. Первый, самый низкий уровень — Read uncommitted. Это то, что в PostgreSQL описывается как No lock. Когда мы читаем или пишем данные, мы не блокируем другим пользователям ни чтение, ни запись этих данных. Получается, что мы не блокируем никакие изменения. Все четыре перечисленные проблемы по-прежнему могут произойти. Но от чего защищает этот уровень изоляции? Он гарантирует, что все транзакции, которые пришли в базу данных, будут выполнены. Если два пользователя одновременно начали выполнять запросы с одними и теми же данными, то обе эти транзакции будут выполнены последовательно.

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

Read committed, чтение фиксированных данных. Этот уровень изоляции используется по умолчанию в большинстве реляционных баз, в том числе и в PostgreSQL, и в Oracle. Он гарантирует, что вы никогда не прочитаете «грязные» данные. То есть другая транзакция никогда не видит промежуточных этапов первой транзакции. Преимущество в том, что это очень хорошо подходит для маленьких коротких запросов. Мы гарантируем, что у нас никогда не будет ситуации, когда мы видим какие-то части данных, недописанные данные. Например, увеличиваем зарплату целому отделу и не видим, когда только часть людей получили прибавку, а вторая часть сидит с неиндексированной зарплатой. Потому что если у нас будет такая ситуация, логично, что наша аналитика сразу «поедет».

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

Уровень изоляции Repeatable read защищает от первых трех проблем, которые мы с вами обсуждали. Это и потерянное обновление, когда перезаписали нашу переговорку; «грязное» чтение — чтение незафиксированных данных; и это неповторяющееся чтение — чтение данных, обновленных другими транзакциями.

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

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

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

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

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

Что нужно знать о транзакциях? Что они нам упрощают жизнь, потому что реализованы на уровне СУБД и нам нужно только правильно делать наши запросы, правильно их формировать, так, чтобы данные в итоге были согласованы. И чтобы блокировать именно те данные, с которыми наши пользователи работают. Нужно иметь в виду, что плохо блокировать всё и везде. В зависимости от того, какая у вас система и кто сколько читает/пишет, у вас будет разный уровень изолированности. Если вам нужна максимально быстрая система, которая допускает какие-то ошибки, вы можете выбрать минимальный уровень изоляции. Если у вас банковская система, которая должна гарантировать, что данные согласованы, все выполнено и ничего не потерялось — тогда, конечно, нужно выбирать максимальный уровень изоляции.

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

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

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

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

Во-первых, если с БД что-то случилось, мы можем перенаправить запросы на другую копию базы данных, что в принципе логично. Это основное применение. Как еще мы можем это использовать?

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

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

Также у нас есть понятие OLTP-запросов и OLAP-запросов. Что это такое? OLTP — короткие транзакционные запросы. OLAP — долгая аналитика. Это когда мы берем огромный джойн, огромный селект, всё мёржим и нам очень важно, чтобы в этот момент все данные были залочены, чтобы не было никаких изменений и БД была целостна.

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

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

Очень важный параметр реплицируемой системы — синхронно или асинхронно выполняются запросы. Что такое синхронный запрос? Это когда Master отправляет запрос на синхронную реплику, на синхронный Slave, и ждет, когда Slave скажет: «Да, я принял», — и вернет Master подтверждение. Только тогда Master вернет пользователю ответ. Если же реплика асинхронная, то Master отправляет запрос на реплику, но сразу говорит пользователю, что «Всё, я записал». Давайте посмотрим, как это работает.

Есть юзер, который записал данные в Master. Master отправил их на две реплики, подождал ответа от синхронной реплики и сразу дал ответ пользователю. Асинхронная реплика записала и сказала Master: «Да, все окей, данные записаны».

С точки зрения такой иерархии, Master и Slave, у нас может быть одна голова или несколько. Если у нас один ведущих узел, в него очень удобно писать, а читать можно из синхронной реплики. Почему именно из синхронной? Потому что синхронная реплика с максимальной точностью гарантирует, что в ней актуальные данные.

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

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

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

Это очень простой пример такой репликации. Она часто применяется для совместного редактирования онлайн-документов, либо когда очень велика вероятность потери сети.

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

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

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

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

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

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

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

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

Есть одно «но»: все реплики должны иметь одинаковую конфигурацию. Если говорить на примере PostgreSQL, они должны иметь одинаковую версию самого PostgreSQL, потому что разные версии базы могут иметь и разный формат журнала операций. И если реплика поднимается из другой версии, она просто может не прочитать операции, которые записала другая база.

Что такое реплика? Это полная копия всех данных. Представим, что данных так много, что сервер не справляется. Какое первое решение?

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

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

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

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

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

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

Бывает толстый клиент. Это когда мы не зашиваем сам клиент в отдельную прослойку, а зашиваем в него самого данные о том, как у нас шардированы данные.

Вот этот случай. Он, кстати, самый частоиспользуемый. Хорош тем, что наше приложение, наш клиент, даже тот код, который вы пишете, — он не знает о том, что таблица шардирована, хотя мы указываем это в config, в самой базе. Мы просто говорим ей — селект, и уже в самой БД идет разбиение на шарды и понимание, откуда селектить. Здесь же вы в самом коде определяете то, откуда читать данные.

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

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

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

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

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

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

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

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

Отвечу на вопрос, который был до этого. Что лучше сделать — определить индексы или сделать шарды? Конечно, индексы.

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

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

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

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

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

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

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

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

А можем посмотреть на другие схемы, на другие системы хранения. NoSQL — очень кричащая аббревиатура, даже прямо провоцирующая — «нет SQL». Как она появилась?

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

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

Ключ-значение. Это самое простое. Вот словарь, вот соотношение. Эта база данных, в которой данные хранятся по ключам, причем неважно, что лежит под конкретным ключом. У нас и сам ключ, и данные могут быть и простыми, и гораздо более сложными структурами. Такая база хороша тем, что она, подобно индексу, очень быстро ищет данные. Именно поэтому key-value очень часто используется для кэша. Преимущество в том, что наше value может быть разное в разных ключах.

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

Примеры — Redis, Memcached, Amazon DynamoDB, Riak, LevelDB. Вы можете посмотреть особенности реализации именно key-value хранилищ.

Документоориентированные базы данных очень похожи на key-value в какой-то из областей их применения. Но у них единицей является документ. Это такая сложная структура, по которой мы можем селектить определенные данные, делать балковые операции: Bulk insert, Bulk update.

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

Преимущество документоориентированных БД: они обладают очень высокой доступностью и гибкостью данных. В любой документ, в любой JSON вы можете записать абсолютно любой набор данных. И они очень часто применяются — например, когда нужно сделать какой-нибудь каталог и когда каждый продукт в каталоге может иметь разные характеристики.

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

Еще одна модель, в которой удобно хранить данные, — столбцовые БД. Их еще называют колоночными, column database.

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

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

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

Самые популярные столбцовые — это, наверное, Cassandra, HBase и ClickHouse. Испытайте их. Очень интересно инвертировать в голове отношение строк и столбцов. И это действительно эффективный и быстрый доступ к большому количеству данных.

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

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

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

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

Если вы делаете кэш, то, естественно, берете какой-нибудь Redis, простое и быстрое key-value. Если у вас есть огромное количество логов для анализа, вы можете скинуть его в ClickHouse или в какую-нибудь колоночную базу, по которой потом будет очень удобно искать. Либо записать в документоориентированную базу, потому что там может быть разное значение документов. Это тоже может оказаться удобно для селекта.

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

Вы сегодня узнали очень много о самых разных проблемах и способах хранения данных. Еще раз повторю то, что я говорила в самом начале: не нужно знать прямо все досконально, не нужно копаться в чем-то одном. Если интересно — конечно, можно. Но важно знать о том, что это вообще существует, какие есть подходы и как вообще можно мыслить. Если нужна отказоустойчивость, есть смысл сделать реплику. Предположим, я записала данные, но не увидела. Тогда, наверное, моя реплика дала лаг. Не нужно изобретать велосипеды — есть уже много готовых решений для разных задач. Расширяйте кругозор, а если появится баг или какая-нибудь другая проблема, вы по характеристикам бага поймете, где именно произошел сбой, сможете найти решение через поисковик. Спасибо за внимание.

Связи между таблицами базы данных / Хабр

1. Введение

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

1.1. Для кого эта статья?

Эта статья будет полезна тем, кто хочет разобраться со связями между таблицами базы данных. В ней я постарался рассказать на понятном языке, что это такое. Для лучшего понимания темы, я чередую теоретический материал с практическими примерами, представленными в виде диаграммы и запроса, создающего нужные нам таблицы. Я использую СУБД Microsoft SQL Server и запросы пишу на T-SQL. Написанный мною код должен работать и на других СУБД, поскольку запросы являются универсальными и не используют специфических конструкций языка T-SQL.

1.2. Как вы можете применить эти знания?

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

2. Благодарности

Учтены были советы и критика авторов jobgemws, unfilled, firnind, Hamaruba.
Спасибо!

3.1. Как организовываются связи?

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

3.2. Виды связей

Связи делятся на:

1. Многие ко многим.
2. Один ко многим.
   
   • с обязательной связью;
   • с необязательной связью;
3. Один к одному.
   
   • с обязательной связью;
   • с необязательной связью;

Рассмотрим подробно каждый из них.

4. Многие ко многим

Представим, что нам нужно написать БД, которая будет хранить работником IT-компании. При этом существует некий стандартный набор должностей. При этом:

• Работник может иметь одну и более должностей. Например, некий работник может быть и админом, и программистом.
• Должность может «владеть» одним и более работников. Например, админами является определенный набор работников. Другими словами, к админам относятся некие работники.

Работников представляет таблица «Employee» (id, имя, возраст), должности представляет таблица «Position» (id и название должности). Как видно, обе эти таблицы связаны между собой по правилу многие ко многим: каждому работнику соответствует одна и больше должностей (многие должности), каждой должности соответствует один и больше работников (многие работники).

4.1. Как построить такие таблицы?

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

На эту таблицу можно посмотреть с двух сторон:

1. Таким образом, мы говорим, что работник с id 1 находится на должность с id 1. При этом обратите внимание на то, что в этой таблице работник с id 1 имеет две должности: 1 и 2. Т.е., каждому работнику слева соответствует некая должность справа.
2. Мы также можем сказать, что должности с id 3 принадлежат пользователи с id 2 и 3. Т.е., каждой роли справа принадлежит некий работник слева.

4.2. Реализация

Диаграмма

Код на T-SQL

create table dbo.Employee
(
	EmployeeId int primary key,
	EmployeeName nvarchar(128) not null,
	EmployeeAge int not null
)

-- Заполним таблицу Employee данными.
insert into dbo.Employee(EmployeeId, EmployeeName, EmployeeAge) values (1, N'John Smith', 22)
insert into dbo.Employee(EmployeeId, EmployeeName, EmployeeAge) values (2, N'Hilary White', 22)
insert into dbo.Employee(EmployeeId, EmployeeName, EmployeeAge) values (3, N'Emily Brown', 22)

create table dbo.Position
(
	PositionId int primary key,
	PositionName nvarchar(64) not null
)

-- Заполним таблицу Position данными.
insert into dbo.Position(PositionId, PositionName) values(1, N'IT-director')
insert into dbo.Position(PositionId, PositionName) values(2, N'Programmer')
insert into dbo.Position(PositionId, PositionName) values(3, N'Engineer')

-- Заполним таблицу EmployeesPositions данными.
create table dbo.EmployeesPositions
(
	PositionId int foreign key references dbo.Position(PositionId),
	EmployeeId int foreign key references dbo.Employee(EmployeeId),
	primary key(PositionId, EmployeeId)
)

insert into dbo.EmployeesPositions(EmployeeId, PositionId) values (1, 1)
insert into dbo.EmployeesPositions(EmployeeId, PositionId) values (1, 2)
insert into dbo.EmployeesPositions(EmployeeId, PositionId) values (2, 3)
insert into dbo.EmployeesPositions(EmployeeId, PositionId) values (3, 3)

ОбъясненияС помощью ограничения foreign key мы можем ссылаться на primary key или unique другой таблицы. В этом примере мы

• ссылаемся атрибутом PositionId таблицы EmployeesPositions на атрибут PositionId таблицы Position;
• атрибутом EmployeeId таблицы EmployeesPositions — на атрибут EmployeeId таблицы Employee;

4.3. Вывод

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

5. Один ко многим

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

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

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

Другими словами, телефон принадлежит только одному пользователю. А пользователю могут принадлежать 1 и более телефонов (многие).

Как мы видим, это отношение один ко многим.

5.1. Как построить такие таблицы?

Пользователей будет представлять некая таблица «Person» (id, имя, фамилия, возраст), номера телефонов будет представлять таблица «Phone». Она будет выглядеть так:
Данная таблица представляет три номера телефона. При этом номера телефона с id 1 и 2 принадлежат пользователю с id 5. А вот номер с id 3 принадлежит пользователю с id 17.
Заметка. Если бы у таблицы «Phones» было бы больше атрибутов, то мы смело бы их добавляли в эту таблицу.

5.2. Почему мы не делаем тут таблицу-посредника?

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

1. Каждому работнику принадлежат несколько должностей (многие).
2. Каждой должности принадлежит несколько работников (многие).

Но в нашем случае мы не можем сказать, что каждому телефону принадлежат несколько пользователей — номеру телефона может принадлежать только один пользователь.
Теперь прочтите еще раз заметку в конце пункта 5.1. — она станет для вас более понятной.

5.3. Реализация

Диаграмма

Код на T-SQL

create table dbo.Person
(
	PersonId int primary key,
	FirstName nvarchar(64) not null,
	LastName nvarchar(64) not null,
	PersonAge int not null
)

insert into dbo.Person(PersonId, FirstName, LastName, PersonAge) values (5, N'John', N'Doe', 25)
insert into dbo.Person(PersonId, FirstName, LastName, PersonAge) values (17, N'Izabella', N'MacMillan', 19)

create table dbo.Phone
(
	PhoneId int primary key,
	PersonId int foreign key references dbo.Person(PersonId),
	PhoneNumber varchar(64) not null
)

insert into dbo.Phone(PhoneId, PersonId, PhoneNumber) values (1, 5, '11 091-10')
insert into dbo.Phone(PhoneId, PersonId, PhoneNumber) values (2, 5, '19 124-66')
insert into dbo.Phone(PhoneId, PersonId, PhoneNumber) values (3, 17, '21 972-02')

Объяснения

Наша таблица Phone хранит всего один внешний ключ. Он ссылается на некого пользователя (на строку из таблицы Person). Таким образом, мы как бы говорим: «этот пользователь является владельцем данного телефона». Другими словами, телефон знает id своего владельца.

6. Один к одному

Представим, что на работе вам дали задание написать БД для учета всех работников для HR. Начальник уверял, что компании нужно знать только об имени, возрасте и телефоне работника. Вы разработали такую БД и поместили в нее всю 1000 работников компании. И тут начальник говорит, что им зачем-то нужно знать о том, является ли работник инвалидом или нет. Наиболее простое, что приходит в голову — это добавить новый столбец типа bool в вашу таблицу. Но это слишком долго вписывать 1000 значений и ведь true вы будете вписывать намного реже, чем false (2% будут true, например).

Более простым решением будет создать новую таблицу, назовем ее «DisabledEmployee». Она будет выглядеть так:

Но это еще не связь один к одному. Дело в том, что в такую таблицу работник может быть вписан более одного раза, соответственно, мы получили отношение один ко многим: работник может быть несколько раз инвалидом. Нужно сделать так, чтобы работник мог быть вписан в таблицу только один раз, соответственно, мог быть инвалидом только один раз. Для этого нам нужно указать, что столбец EmployeeId может хранить только уникальные значения. Нам нужно просто наложить на столбец EmloyeeId ограничение unique. Это ограничение сообщает, что атрибут может принимать только уникальные значения.

Выполнив это мы получили связь один к одному.

Заметка. Обратите внимание на то, что мы могли также наложить на атрибут EmloyeeId ограничение primary key. Оно отличается от ограничения unique лишь тем, что не может принимать значения null.

6.1. Вывод

Можно сказать, что отношение один к одному — это разделение одной и той же таблицы на две.

6.2. Реализация

Диаграмма

Код на T-SQL

create table dbo.Employee
(
	EmployeeId int primary key,
	EmployeeName nvarchar(128) not null,
	EmployeeAge int not null
)

insert into dbo.Employee(EmployeeId, EmployeeName, EmployeeAge) values (159, N'John Smith', 22)
insert into dbo.Employee(EmployeeId, EmployeeName, EmployeeAge) values (722, N'Hilary White', 29)
insert into dbo.Employee(EmployeeId, EmployeeName, EmployeeAge) values (937, N'Emily Brown', 19)
insert into dbo.Employee(EmployeeId, EmployeeName, EmployeeAge) values (100, N'Frederic Miller', 16)
insert into dbo.Employee(EmployeeId, EmployeeName, EmployeeAge) values (99, N'Henry Lorens', 20)
insert into dbo.Employee(EmployeeId, EmployeeName, EmployeeAge) values (189, N'Bob Red', 25)

create table dbo.DisabledEmployee
(
	DisabledPersonId int primary key,
	EmployeeId int unique foreign key references dbo.Employee(EmployeeId)
)

insert into dbo.DisabledEmployee(DisabledPersonId, EmployeeId) values (1, 159)
insert into dbo.DisabledEmployee(DisabledPersonId, EmployeeId) values (2, 722)
insert into dbo.DisabledEmployee(DisabledPersonId, EmployeeId) values (3, 937)

Объяснения

Таблица DisabledEmployee имеет атрибут EmployeeId, что является внешним ключом. Он ссылается на атрибут EmployeeId таблицы Employee. Кроме того, этот атрибут имеет ограничение unique, что говорит о том, что в него могут быть записаны только уникальные значения. Соответственно, работник может быть записан в эту таблицу не более одного раза.

7. Обязательные и необязательные связи

Связи можно поделить на обязательные и необязательные.

7.1. Один ко многим

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

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

У одной биологической матери может быть много детей. У ребенка есть только одна биологическая мать.

А) У женщины необязательно есть свои дети. Соответственно, связь необязательна.
Б) У ребенка обязательно есть только одна биологическая мать – в таком случае, связь обязательна.

7.2. Один к одному

1. Один к одному с обязательной связью:
   У одного гражданина определенной страны обязательно есть только один паспорт этой страны. У одного паспорта есть только один владелец.
2. Один к одному с необязательной связью:
   У одной страны может быть только одна конституция. Одна конституция принадлежит только одной стране. Но конституция не является обязательной. У страны она может быть, а может и не быть, как, например, у Израиля и Великобритании.

Одну и ту же связь можно рассматривать как обязательную и как необязательную:

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

А) Наличие загранпаспорта необязательно – его может и не быть у гражданина. Это необязательная связь.
Б) У загранпаспорта обязательно есть только один владелец. В этом случае, это уже обязательная связь.

7.3. Многие ко многим

Любая связь многие ко многим является необязательной. Например:

Человек может инвестировать в акции разных компаний (многих). Инвесторами какой-то компании являются определенные люди (многие).

А) Человек может вообще не инвестировать свои деньги в акции.
Б) Акции компании мог никто не купить.

8. Как читать диаграммы?

Выше я приводил диаграммы созданных нами таблиц. Но для того, чтобы их понимать, нужно знать, как их «читать». Разберемся в этом на примере диаграммы из пункта 5.3.

Мы видим отношение один ко многим. Одной персоне принадлежит много телефонов.

1. Возле таблицы Person находится золотой ключик. Он обозначает слово «один».
2. Возле таблицы Phone находится знак бесконечности. Он обозначает слово «многие».

9. Итоги

1. Связи бывают:
   • Многие ко многим.
   • Один ко многим.
     1) с обязательной связью;
     2) с необязательной связью.
   • Один к одному.
     1) с обязательной связью;
     2) с необязательной связью.
2. Связи организовываются с помощью внешних ключей.
3. Foreign key (внешний ключ) — это атрибут или набор атрибутов, которые ссылаются на primary key или unique другой таблицы. Другими словами, это что-то вроде указателя на строку другой таблицы.

10. Задачи

Для лучшего усвоения материала предлагаю вам решить следующие задачи:

1. Описать таблицу фильм: id, название, длительность, режиссер, жанр фильма. Обратите внимание на то, что у фильма может быть более одного жанра, а к одному жанру может относится более, чем один фильм.
   
2. Описать таблицу песня: id, название, длительность, певец. При этом у песни может быть более одного певца, а певец мог записать более одной песни.
3. Реализовать таблицу машина: модель, производитель, цвет, цена
   
   • Описать отдельную таблицу производитель: id, название, рейтинг.
   • Описать отдельную таблицу цвета: id, название.
   
   У одной машины может быть только один производитель, а у производителя — много машин. У одной машины может быть много цветов, а у одного цвета может быть много машин.
   
4. Добавить в БД из пункта 6.2. таблицу военно-обязанных по типу того, как мы описали отдельную таблицу DisabledEmployee.

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

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

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

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

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

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

Шифры (коды) – цифровые или символьные обозначения каких либо величин или их комбинаций.

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

Свойства первичного ключа:

• Однозначное определение записи;

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

полей базы данных | Типы полей

Ресурсы баз данных KS3 (14-16 лет)

• Редактируемая презентация урока в PowerPoint
• Редактируемые раздаточные материалы для исправлений
• Глоссарий, охватывающий ключевые термины модуля
• Тематические интеллектуальные карты для визуализации ключевых понятий
• Печатные карточки, помогающие учащимся активнее вспоминать и повторять на основе уверенности
• Викторина с сопровождающим ключом для проверки знаний и понимания модуля

A-level Введение в базы данных (16-18 лет)

• Редактируемая презентация урока в PowerPoint
• Редактируемые раздаточные материалы для исправлений
• Глоссарий, охватывающий ключевые термины модуля
• Тематические интеллектуальные карты для визуализации ключевых понятий
• Карточки для печати, помогающие учащимся активнее вспоминать и повторять на основе уверенности
• Викторина с сопровождающим ключом для проверки знаний и понимания модуля

База данных

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

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

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

Поле

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

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

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

Идентификационный номер сотрудника	Фамилия	Имя	Позиция	Отдел	Дата аренды
00108	Доу	Джон	Помощник менеджера	Управление персоналом	16 ноября 2000 г.
00109	Паркер	Энн	Руководитель	Финансовые услуги	1 мая 2003 г.

Обязательные, необязательные и вычисляемые поля

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

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

Поля и записи

Поля организованы в записи, которые содержат всю информацию в таблице, относящуюся к определенному объекту. Записи составляют строки таблицы, а поля — столбцы таблицы.

Поля фиксированной и переменной длины

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

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

• Текст, буквенно-цифровой, символьный, строка
• Байт
• Короткое целое число
• Long

Основы проектирования баз данных — Access

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

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

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

В этой статье

Некоторые термины базы данных, которые нужно знать

Что такое хороший дизайн базы данных?

Процесс проектирования

Определение цели вашей базы данных

Поиск и систематизация необходимой информации

Разделение информации на таблицы

Превращение информационных элементов в столбцы

Указание первичных ключей

Создание отношений таблицы

Доработка дизайна

Применение правил нормализации

Некоторые термины базы данных, которые необходимо знать

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

Каждую строку правильнее называть записью , а каждый столбец — полем . Запись — это значимый и последовательный способ объединения информации о чем-либо.Поле — это отдельный элемент информации — тип элемента, который появляется в каждой записи. В таблице «Товары», например, каждая строка или запись будет содержать информацию об одном продукте. Каждый столбец или поле содержит некоторую информацию об этом продукте, такую ​​как его название или цена.

Верх страницы

Что такое хороший дизайн базы данных?

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

Следовательно, хороший дизайн базы данных должен:

• Делит вашу информацию в тематических таблицах, чтобы уменьшить количество избыточных данных.

• Предоставляет доступ к информации, необходимой для объединения информации в таблицах вместе по мере необходимости.

• Помогает поддерживать и обеспечивать точность и целостность вашей информации.

• Удовлетворяет ваши потребности в обработке данных и отчетности.

Верх страницы

Процесс проектирования

Процесс проектирования состоит из следующих этапов:

• Определите цель вашей базы данных

  Это поможет вам подготовиться к оставшимся шагам.

• Найдите и систематизируйте необходимую информацию

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

• Разделить информацию на таблицы

  Разделите ваши информационные элементы на основные объекты или темы, такие как Продукты или Заказы.Затем каждый предмет становится таблицей.

• Превратить информационные элементы в столбцы

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

• Укажите первичные ключи

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

• Настроить связи таблиц

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

• Усовершенствуйте свой дизайн

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

• Применить правила нормализации

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

Верх страницы

Определение цели вашей базы данных

Хорошая идея — записать цель базы данных на бумаге — ее назначение, то, как вы собираетесь ее использовать и кто будет ее использовать.Для небольшой базы данных для домашнего бизнеса, например, вы можете написать что-то простое, например: «База данных клиентов хранит список информации о клиентах с целью создания рассылок и отчетов». Если база данных более сложная или используется многими людьми, как это часто бывает в корпоративной среде, целью может легко быть параграф или больше и должен включать, когда и как каждый человек будет использовать базу данных. Идея состоит в том, чтобы иметь хорошо разработанное заявление о миссии, на которое можно ссылаться в процессе проектирования.Такое утверждение поможет вам сосредоточиться на своих целях при принятии решений.

Верх страницы

Поиск и систематизация необходимой информации

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

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

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

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

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

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

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

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

После сбора этой информации вы готовы к следующему шагу.

Верх страницы

Разделение информации на таблицы

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

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

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

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

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

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

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

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

Верх страницы

Преобразование информационных единиц в столбцы

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

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

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

В следующем списке приведены несколько советов по определению столбцов.

• Не включать расчетные данные

  В большинстве случаев не следует сохранять результаты вычислений в таблицах. Вместо этого вы можете попросить Access выполнить вычисления, когда захотите увидеть результат. Например, предположим, что есть отчет «Продукты по заказу», в котором отображается промежуточный итог по заказанным единицам для каждой категории продуктов в базе данных.Однако ни в одной таблице нет столбца промежуточных итогов «Единицы заказа». Вместо этого в таблице «Продукты» есть столбец «Единицы заказа», в котором хранятся заказанные единицы для каждого продукта. Используя эти данные, Access вычисляет промежуточный итог при каждой печати отчета. Сам промежуточный итог не следует хранить в таблице.

• Хранить информацию в самых маленьких логических частях

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

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

Верх страницы

Указание первичных ключей

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

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

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

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

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

Если вы не имеете в виду столбец или набор столбцов, которые могли бы стать хорошим первичным ключом, рассмотрите возможность использования столбца с типом данных AutoNumber.Когда вы используете тип данных AutoNumber, Access автоматически присваивает вам значение. Такой идентификатор лишен фактов; он не содержит фактической информации, описывающей строку, которую он представляет. Бесконечные идентификаторы идеально подходят для использования в качестве первичного ключа, поскольку они не меняются. Первичный ключ, содержащий факты о строке — например, номер телефона или имя клиента — с большей вероятностью изменится, потому что сама фактическая информация может измениться.

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

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

Для базы данных продаж продуктов вы можете создать столбец AutoNumber для каждой таблицы, который будет служить в качестве первичного ключа: ProductID для таблицы Products, OrderID для таблицы Orders, CustomerID для таблицы Customers и Sup

Что такое база данных ? Знать определение, типы и компоненты

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

Рассмотрены следующие темы:

Итак, приступим!

Что такое данные?

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

Пример : имя, возраст, вес, рост и т. Д.

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

Что такое база данных?

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

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

Факты о базе данных:

• Базы данных значительно эволюционировали с момента их создания в начале 1960-х годов.
• Некоторые навигационные базы данных, такие как Иерархическая база данных и Сетевая база данных, были исходными системами, используемыми для хранения и управления данными.Хотя эти ранние системы на самом деле были негибкими
• В начале 1980-х годов Реляционные базы данных стали очень популярными, за которыми позже последовали объектно-ориентированные базы данных.
• Совсем недавно, базы данных NoSQL возникли как ответ на рост Интернета и потребность в более высокой скорости и обработке неструктурированных данных.
• Сегодня у нас есть облачная база данных, и автономные базы данных, которые создают новую основу, когда дело доходит до того, как данные собираются, хранятся, управляются и используются.

Примечание: Данные взаимозаменяемы.

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

Как создать базу данных?

Мы используем оператор CREATE DATABASE для создания новой базы данных.

Синтаксис:

 CREATE DATABASE имя базы данных; 

Пример:

 СОЗДАТЬ БАЗУ ДАННЫХ Колледж 

Таким образом, будет создана база данных имени Колледж.

Вот как просто можно создать базу данных.

Компоненты базы данных

Основными компонентами базы данных являются:

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

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

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

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

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

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

Какие типы баз данных

Есть несколько типов, которые очень важны и популярны.

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

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

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

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

Что такое SQL?

Язык структурированных запросов SQL произносится как «S-Q-L» или иногда как «See-Quel», который является стандартным языком для работы с реляционными базами данных .

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

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

Преимущества

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

Недостатки

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

На этом мы подошли к концу статьи «Что такое база данных». Надеюсь, вам понравилось это читать.

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

Есть к нам вопрос? Пожалуйста, отметьте это в разделе комментариев к « Что такое база данных », и я вернусь к вам.

6 Управление базой данных

6 Управление базой данных Глава 6

Управление базой данных

6.1 Иерархия данных [Рисунок 6.1] [Слайд 6-4]

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

Данные логически организованы в:

1. Биты (символы)

2. Поля

3. Рекорды

4. Файлы

5. Базы данных

Бит (символ) — бит — наименьшая единица представление данных (значение бита может быть 0 или 1).Восемь бит составляют байт, который может представляют символ или специальный символ в коде символа.

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

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

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

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

6.2 Файловая среда и ее ограничения

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

Файловая организация [Рисунок 6.2 и 6.3]

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

Доступ к записи для чтения — это существенная операция с данными. Есть два типа доступа:

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

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

Существует три метода организации файлов: [Таблица 6.1]

1. Последовательная организация 2.Индексированный-последовательный организация 3. Прямая организация

Последовательная организация

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

Преимущества последовательного доступа:

1. Это быстро и эффективно при работе с большими объемами данных, которые необходимо периодически обрабатывать (пакетная система).

Недостатки последовательного доступа:

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

Индексированная последовательная организация

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

Прямая организация

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

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

6.3 Среда базы данных [Рисунок 6.6] [Слайд 6-5]

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

СУБД:

1. Помогает организовать данные для эффективный доступ для множества пользователей с разными потребностями доступа и для эффективного место хранения. 2. Это позволяет создавать, получать доступ, поддерживать и контролировать базы данных. 3. Через СУБД данные могут быть интегрированным и представленным по запросу.

Преимущества подхода к управлению базами данных:

1. Избегать неконтролируемых избыточность данных и предотвращение несогласованности 2. Программа-данные независимость 3.Гибкий доступ к общие данные 4. Преимущества централизованный контроль данных

6.4 Уровни определения данных в базах данных [Рисунок 6,7]

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

1. Схема — это общий логический вид отношения между данными в базе данных.

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

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

6.5 Модели данных или способы их представления Связи между данными

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

1. Иерархическая структура

2. Структура сети

3. Структура отношений

Иерархический:

Ранние пакеты СУБД для мэйнфреймов использовали иерархическую структуру . структура , в которой:

1.Отношения между записями образуют иерархию или древовидная структура.

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

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

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

Структура сети:

Структура сети:

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

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

Реляционная структура:

Реляционная структура:

1.Самая популярная из трех структур базы данных.

2. Используется большинством пакетов микрокомпьютерных СУБД, а также многие системы миникомпьютеров и мэйнфреймов.

3. Элементы данных в базе данных хранятся в форма простых столов . Таблицы связаны между собой, если они содержат общие поля.

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

Оценка структур базы данных

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

6.6 Реляционные базы данных [Рисунки 6.11, 6.13]

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

1. Выберите, который выбирает из указанной таблицы строки, удовлетворяющие заданному условию. 2. Проект, который выбирает из данной таблицы указанные значения атрибутов 3.Присоединяйтесь, что создает новый таблица из двух указанных таблиц.

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

6.7 SQL — язык реляционных запросов

Structured Query Languages ​​(SQL) стал международный стандартный язык доступа для определения и управления данными в базах данных.Это является языком определения данных и управления большинством известных СУБД, включая некоторые нереляционные. SQL может использоваться как независимый язык запросов для определения объектов. в базе данных, введите данные в базу данных и получите доступ к данным. Так называемые встроенный SQL также предоставляется для программирования на процедурных языках (Ahost @ языки), например C, COBOL или PL / L, для доступа к базе данных из приложения. программа. В среде конечного пользователя SQL обычно скрыт более удобными для пользователя интерфейсы.

Основные возможности SQL включают:

1. Определение данных 2. Манипулирование данными

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

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

Цель логический дизайн , также известный как данных моделирование , заключается в разработке схемы базы данных и всех необходимых подсхемы.Реляционная база данных будет состоять из таблиц (отношений), каждая из которых описывает только атрибуты определенного класса сущностей. Логический дизайн начинается с определением классов сущностей, которые будут представлены в базе данных, и установлением отношения между парами этих сущностей. Отношения — это просто взаимодействие между сущностями, представленными данными. Эти отношения будут важны для доступ к данным. Часто используются диаграммы сущности-отношения (E-R) . для моделирования данных.

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

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

6.9 Словарь данных

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

Словари данных хранят следующую информацию о данные хранятся в базах данных:

1. Схема, подсхемы и физическая схема 2. Какие приложения и пользователи могут получать конкретные данные и то, какие приложения и пользователи могут изменять данные 3. Перекрестная ссылка информация, например, какие программы используют какие данные и какие пользователи получают какие отчеты 4. Где индивидуальные данные элементы, и кто несет ответственность за поддержание данных 5.Что за стандартное именование соглашения предназначены для сущностей базы данных. 6. Что правила честности для данных 7. Где данные хранятся в географически распределенных базах данных.

Словарь данных:

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

6.10 Управление ресурсами данных организации

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

Компоненты управления информационными ресурсами [Рисунок 6.17]

И организационные действия, и технологические средства необходимо:

1. Убедитесь, что фирма систематически накапливает данные в своих базах данных 2.Поддерживает данные более время 3. Обеспечивает соответствующие доступ к данным соответствующим сотрудникам.

Основные компоненты этого информационного ресурса управление:

1. Организационные процессы

— Информационное планирование и моделирование данных

2. Разрешающие технологии

— СУБД и словарь данных

3. Организационные функции

— Администрирование данных и администрирование баз данных

Администрирование баз данных и Администрирование баз данных [Рисунок 6.18]

Функциональные подразделения, отвечающие за управление данными являются:

1. Администратор данных (DA)

2. Администратор базы данных (DBA)

Администратор данных — лицо, имеющее центральная ответственность за данные организации.

Обязанности включают:

1. Создание политики и специальные процедуры для сбора, проверки, совместного использования и инвентаризации данные, которые будут храниться в базах данных и сделать информацию доступной для членов организации и, возможно, лицам вне ее.2. Администрирование данных — это Функция разработки политики и DA должны иметь доступ к высшему корпоративному руководству. 3. Ключевое лицо, участвующее в стратегическое планирование ресурса данных. 4. Часто определяет основные объекты данных, их атрибуты и отношения между ними.

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

Обязанности включают:

1.Создание баз данных и выполнение политик, установленных администратором данных. 2. В крупных организациях Функцию DBA фактически выполняет группа профессионалов. В небольшой фирме программист / аналитик может выполнять функцию DBA, в то время как один из менеджеров действует как DA. 3. Схема и подсхемы базы данных чаще всего определяются администратором баз данных, который обладает необходимыми техническими знаниями. Они также определяют физическую структуру баз данных с целью оптимизации производительность системы для ожидаемой схемы использования базы данных.

Совместные обязанности DA и DBA:

1. Ведение данных толковый словарь 2. Стандартизация имен и другие аспекты определения данных 3. Обеспечение резервного копирования 4. Обеспечьте безопасность данные, хранящиеся в базе данных, и обеспечить конфиденциальность на основе этой безопасности. 5. Установить катастрофу план восстановления баз данных

6.11 Тенденции развития в управлении базами данных

Три важных направления в управлении базами данных включают:

1.Распределенные базы данных 2. Хранилище данных 3. Богатые базы данных (включая объектно-ориентированные базы данных)

Распределенные базы данных [Рисунок 6.19] [Слайд 6-8]

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

Хранилища данных Базы данных [Рисунок 6.20]

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

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

Системы, поддерживающие хранилище данных, состоят из трех компонентов:

1. Извлечение и подготовка данных

— первая подсистема извлекает данные из операционные системы, многие из которых являются устаревшими системами, и Ascrubs @ it путем устранения ошибок и несоответствий.

2. Сохраните дату в Склад

— вторым компонентом поддержки фактически является СУБД который будет управлять данными хранилища.

3. Обеспечьте доступ и Возможности анализа

— третья подсистема состоит из инструментов запросов которые помогают пользователям получать доступ к данным и включают OLAP и другие инструменты DSS, поддерживающие данные анализ.

Объектно-ориентированные и другие расширенные базы данных

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

1. Географическая информация системы 2. Объектно-ориентированный базы данных 3. Гипертекст и гипермедиа базы данных 4. Базы данных изображений и текст базы данных

Информация о том, что такое база данных, как она используется и зачем.

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

Что такое база данных?

Что на самом деле представляют собой базы данных? Как мы все знаем, гениальные вещи просты. То же самое и с базами данных. База данных — это таблица, состоящая из столбцов (полей) и строк (записей), где каждый столбец содержит определенный атрибут, а каждая строка имеет определенное значение для соответствующего атрибута. Количество столбцов в одной таблице зависит от того, сколько различных типов / категорий информации нам нужно хранить в базе данных, а количество строк определяется количеством объектов, для которых необходимо ввести категоризованные записи.Такая простая организация данных в таблицах базы данных позволяет компьютерной программе быстро выбирать и обрабатывать необходимые фрагменты информации.

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

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

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

Базы данных плоского типа

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

Иерархические базы данных

Иерархическая модель базы данных представляет собой древовидную структуру, и очень хорошая ассоциация — это проводник Windows. Чтобы лучше объяснить это, мы можем использовать структуру родитель-потомок. Каждый родитель может иметь столько детей, сколько хочет, но у каждого ребенка есть только один родитель. Самой популярной иерархической базой данных является IMS (система управления информацией), созданная IBM.

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

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

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

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

Что такое база данных? Как WordPress использует базу данных?

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

WordPress использует MySQL в качестве системы управления базами данных. MySQL — это программное обеспечение, используемое для создания баз данных, хранения и получения данных по запросу. MySQL также является программным обеспечением с открытым исходным кодом, как и WordPress, и лучше всего работает с другим популярным программным обеспечением с открытым исходным кодом, таким как веб-сервер Apache, PHP и операционная система Linux.

Для установки WordPress вам потребуется база данных MySQL. Все хостинг-провайдеры WordPress предлагают MySQL в составе своих хостинговых пакетов. Во время установки (см. Полное руководство по установке WordPress) вы предоставляете WordPress информацию о своей базе данных, а затем WordPress позаботится обо всем остальном.

Что такое хост базы данных

Хост базы данных — это компьютер, на котором размещена ваша база данных на сервере MySQL. В большинстве случаев это localhost , и ввод localhost в поле host подключит WordPress к вашей базе данных.Однако некоторые провайдеры веб-хостинга могут использовать разные имена хостов для управления серверами MySQL. Вы найдете имя своего хоста в разделах MySQL или База данных на панели управления хостингом. Если вы не можете найти имя хоста, обратитесь к своему хостинг-провайдеру.

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

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

Пример: офисная база данных может иметь таблицу с именем employee_records .В этой таблице могут быть следующие столбцы:

• ID сотрудника
• имя сотрудника
• Дата присоединения к сотруднику
• employee_phone_no

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

• wp_commentmeta
• wp_comments
• wp_links
• wp_options
• wp_postmeta
• wp_posts
• wp_terms
• wp_term_relationships
• wp_term_taxonomy
• wp_usermeta
• wp_users

Каждая из этих таблиц будет иметь разные столбцы, в которых хранятся данные.Например, таблица wp_users в WordPress имеет следующие столбцы:

• ID
• user_login
• user_pass
• user_nicename
• адрес_пользователя
• user_url
• зарегистрированный пользователь
• user_activation_key
• user_status
• display_name

Что такое SQL-запрос

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

Типичный запрос MySQL выглядит так:

ВЫБРАТЬ * ИЗ wp_posts ГДЕ ID = 23;
 

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