Базы данных | Access, SQL, Big Data

​​Удаление существующей связи.

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

1. Выберите вкладку Работа с базами данных (Database Tools), а затем инструмент Схема данных (Relationships).
2. Щелкните по линии, соединяющей две таблицы, которая предоставляет связь, подлежащую удалению, правой клавишей мыши.
3. Щелкните по кнопке Удалить (Delete). Access выведет окно с запросом на подтверждение этих действий.

#Связи #УдалениеСвязей #СхемаДанных

​​Создание связей между двумя таблицами.

Чтобы установить связь между двумя таблицами, выполните следующие действия:

1. Откройте диалоговое окно Схема данных (Relationships).
2. Если окно Схема данных (Relationships), относящееся к конкретной базе данных, открывается впервые, то появляется диалоговое окно Добавление таблицы (Show Table). Выделите все таблицы, между которыми необходимо установить связи, и щелкните по кнопке Добавить (Add).
3. Если в текущей базе данных уже определены конкретные связи, то окно Схема данных (Relationships) открывается сразу. Если таблицы, которые необходимо включить в намеченную связь, не отображается на экране, щелкните по кнопке Отобразить таблицу (Show Table) в группе Схема данных (Relationships) на ленте. Чтобы добавить желаемые таблицы в окно Схема данных (Relationships), выбирайте каждую из этих таблиц, а затем щелкните по кнопке Добавить (Add). Повторите этот процесс для каждой таблицы, которую необходимо добавить в окно. Чтобы выбрать сразу несколько таблиц, удерживайте нажатой клавишу <Shift>, щелкая на первой и последней из непрерывного ряда таблиц, или удерживайте нажатой клавишу <Ctrl>, щелкая на отдельно расположенных таблицах для их выбора; затем щелкайте по кнопке Добавить (Add). После окончания выбора таблиц щелкните по кнопке Закрыть (Close).
4. Щелкните на поле одной таблицы, которое нужно связать с полем другой таблицы, и перетащите его на это поле. Откроется диалоговое окно Изменение связей (Edit Relationships).
5. Укажите должны ли быть заданы правила ссылочной целостности и следует ли применять каскадное обновление связанных полей или каскадное удаление связанных строк, установив соответствующие флажки.
6. Щелкните по кнопке Создать (Create).

#Связи #СозданиеСвязей #СхемаДанных

​​Определение связей в СУБД Access. Схема данных.

Для определения связей между таблицами Access используется диалоговое окно Схема данных (Relationships). Чтобы открыть окно, щелкните и выберите вкладку Работа с базами данных (Database Tools) на ленте, а затем выберите инструмент Схема данных (Relationships). Если в базе данных не установлено не одной связи, откроется диалоговое окно Добавление таблицы (Show Table), позволяющее добавить таблицы, которые после этого отображаются в окне Схема данных (Relationships).

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

#Связи #СхемаДанных

​​Связь "один к одному".

В связи "один к одному" каждая строка таблицы на стороне "один" связи должна иметь относящуюся к ней единственную строку в другой таблице на другой стороне связи.
Такая связь встречается редко и применяется лишь в особых ситуациях. Обычно вместо создания связи один к одному между двумя таблицами проще создать новую таблицу, в которую входят все поля этих таблиц. Основные ситуации, в которых имеет смысл использовать связь один к одному:
▪️количество полей в таблице превышает количество, допускаемое Microsoft Access;
▪️некоторые поля в таблице являются обязательными только для ограниченного подмножества строк таблицы.

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

#Связи #ОдинКОдному

​​Связь "многие ко многим".

В связи "многие ко многим" обе таблицы могут иметь строки, согласующиеся с несколькими строками другой таблицы. Возможность непосредственно определить связь "многие ко многим" в Access отсутствует. Для реализации связи такого типа необходимо ввести в действие так называемую соединительную таблицу. После этого создаются связи "один ко многим" между этой соединительной таблицей и каждой из двух таблиц, участвующих в связи "многие ко многим". В качестве примера можно привести таблицы tblOrders и tblItems. Каждый заказ может включать несколько товаров, а каждый товар может присутствовать во многих заказах. Решение состоит в создании третьей таблицы tblOrderDetails. Связь между таблицами tblOrders и tblOrderDetails устанавливается как связь "один ко многим" с помощью поля OrderID. С другой стороны, для согласования таблиц tblOrderDetails и tblItems создается связь "один ко многим" на основе поля ItemID.

#Связи #МногиеКоМногим

​​Связь "один ко многим".

Связь "один ко многим" - наиболее часто применяемая. Данная связь характеризуется тем, что каждая строка одной таблицы может быть ассоциирована со многими относящимися к ней строками другой таблицы. В качестве примера рассмотрим связь между таблицами tblClients и tblOrders. Для каждого клиента из таблицы tblClients может быть введено произвольное количество заказов в таблицу tblOrders. С другой стороны, каждый заказ из таблицы tblOrders может принадлежать только одному клиенту из таблицы tblClients. Считается, что таблица tblClients относится к стороне "один" данной связи, а таблица tblOrders к стороне "многие".
Реализация связи "один ко многим" возможна только в том случае, если поле, соединяющее две таблицы со стороны "один", содержит уникальные значения.

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

#Связи #ОдинКоМногим #ПервичныйКлюч #ВнешнийКлюч #УникальныйИндекс

Основные типы связей.

Между двумя таблицами базы данных может быть определена связь одного из следующих трех типов:
▪️"Один ко многим"
▪️"Один к одному"
▪️"Многие ко многим"

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

#Связи #ТипыСвязей #ОдинКОдному #ОдинКоМногим #МногиеКоМногим

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

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

#ПравилаЦелостности #ПравилаЦелостностиБазы

​​Общие правила целостности.

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

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

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

#ОбщиеПравилаЦелостности #СсылочнаяЦелостность #СущностнаяЦелостность

Правила целостности.

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

#ПравилаЦелостности #ОбщиеПравилаЦелостности #ПравилаЦелостностиБазы

Денормализация – умышленное нарушение правил.

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

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

#НормальныеФормы #Денормализация

Третья нормальная форма.

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

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

#НормальныеФормы #ТретьяНормальнаяФорма

Вторая нормальная форма. Декомпозиция.

Во второй нормальной форме все не ключевые столбцы должны полностью зависеть от первичного ключа. Иными словами, в каждой таблице должны храниться данные только об одной сущности. Рассмотрим таблицу, она включает в себя информацию о заказах (OrderID, ClientID и OrderDate), а также о том, какие товары заказаны каждым клиентом (Item и Quantity). Чтобы привести эту таблицу ко второй нормальной форме, необходимо разбить ее на две таблицы: таблицу заказов и таблицу сведений о заказе.

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

#НормальныеФормы #ВтораяНормальнаяФорма #Декомпозиция

Первая нормальная форма.

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

#НормальныеФормы #ПерваяНормальнаяФорма

Нормализация и нормальные формы.

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

#Нормализация #НормальныеФормы

Правила уникальности и применения ключей.

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

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

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

#Ключи #ПроектированиеТаблиц

Правила проектирования таблиц.

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

#Таблицы #ПроектированиеТаблиц

Channel created