9 Вопрос:

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

Исчисление кортежей, где переменными являются кортежи.

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

Основные операции

В состав теоретико-множественных операций входят операции:

- объединения отношений;

- пересечения отношений;

- взятия разности отношений;

- прямого произведения отношений.

Специальные реляционные операции включают:

- ограничение отношения;

- проекцию отношения;

- соединение отношений;

- деление отношений.

10)

Функциональная зависимость между атрибутами (множествами атрибутов) X и Y означает, что для любого допустимого набора кортежей в данном отношении: если два кортежа совпадают по значению X, то они совпадают по значению Y. Например, если значение атрибута «Название компании» — Canonical Ltd, то значением атрибута «Штаб-квартира» в таком кортеже всегда будет Millbank Tower, London, United Kingdom. Обозначение: {X} -> {Y}.

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

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

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

Модель	Фирма	Цена	Скидка
M5	BMW	5500000	5%
X5M	BMW	6000000	5%
M1	BMW	2500000	5%
GT-R	Nissan	5000000	10%

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

Модель	Фирма	Цена
M5	BMW	5500000
X5M	BMW	6000000
M1	BMW	2500000
GT-R	Nissan	5000000

Фирма	Скидка
BMW	5%
Nissan	10%

11)

В отношении R (A, B, C) существует многозначная зависимость R.A -> -> R.B в том и только в том случае, если множество значений B, соответствующее паре значений A и C, зависит только от A и не зависит от С.

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

Рассмотрим таблицу:

Модель	Магазин	Телефон
BMW	Риал-авто	87-33-98
Audi	Риал-авто	87-33-98
Nissan	Некст-Авто	94-54-12

Таблица находится во 2НФ, но не в 3НФ. В отношении атрибут «Модель» является первичным ключом. Личных телефонов у автомобилей нет, и телефон зависит исключительно от магазина. Таким образом, в отношении существуют следующие функциональные зависимости: Модель → Магазин, Магазин → Телефон, Модель → Телефон. Зависимость Модель → Телефон является транзитивной, следовательно, отношение не находится в 3НФ. В результате разделения исходного отношения получаются два отношения, находящиеся в 3НФ: Риал-авто 87-33-98  Риал-авто 87-33-98  Некст-Авто 94-54-12 

Модель	Магазин
BMW	Риал-авто
Audi	Риал-авто
Nissan	Некст-Авто

Нормальная форма Бойса-Кодда (НФБК) (частная форма третьей нормальной формы)

Определение 3НФ не совсем подходит для следующих отношений: 1) отношение имеет две или более потенциальных ключа; 2) два и более потенциальных ключа являются составными; 3) они пересекаются, т.е. имеют хотя бы один атрибут. Для отношений, имеющих один потенциальный ключ (первичный), НФБК является 3НФ. Отношение находится в НФБК, когда каждая нетривиальная и неприводимая слева функциональная зависимость обладает потенциальным ключом в качестве детерминанта. Предположим, рассматривается отношение, представляющее данные о бронировании стоянки на день:

Номер стоянки	Время начала	Время окончания	Тариф
1	09:30	10:30	Бережливый
1	11:00	12:00	Бережливый
1	14:00	15:30	Стандарт
2	10:00	12:00	Премиум-В
2	12:00	14:00	Премиум-В
2	15:00	18:00	Премиум-А

Тариф имеет уникальное название и зависит от выбранной стоянки и наличии льгот, в частности:

«Бережливый»: стоянка 1 для льготников

«Стандарт»: стоянка 1 для не льготников

«Премиум-А»: стоянка 2 для льготников

«Премиум-B»: стоянка 2 для не льготников.

Таким образом, возможны следующие составные первичные ключи: {Номер стоянки, Время начала}, {Номер стоянки, Время окончания}, {Тариф, Время начала}, {Тариф, Время окончания}. Отношение находится в 3НФ. Требования второй нормальной формы выполняются, так как все атрибуты входят в какой-то из потенциальных ключей, а неключевых атрибутов в отношении нет. Также нет и транзитивных зависимостей, что соответствует требованиям третьей нормальной формы. Тем не менее, существует функциональная зависимость Тариф → Номер стоянки, в которой левая часть (детерминант) не является потенциальным ключом отношения, то есть отношение не находится в нормальной форме Бойса — Кодда. Недостатком данной структуры является то, что, например, по ошибке можно приписать тариф «Бережливый» к бронированию второй стоянки, хотя он может относиться только к первой стоянки. Можно улучшить структуру с помощью декомпозиции отношения на два и добавления атрибута Имеет льготы, получив отношения, удовлетворяющие НФБК (подчёркнуты атрибуты, входящие в первичный ключ.): Тарифы

Тариф	Номер стоянки	Имеет льготы
Бережливый	1	Да
Стандарт	1	Нет
Премиум-А	2	Да
Премиум-В	2	Нет

Бронирование

Тариф	Время начала	Время окончания
Бережливый	09:30	10:30
Бережливый	11:00	12:00
Стандарт	14:00	15:30
Премиум-В	10:00	12:00
Премиум-В	12:00	14:00
Премиум-А	15:00	18:00

12)

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

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

Теперь настало время рассмотреть алгоритм нормализации отношения до 1НФ.

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

Для каждого кортежа исходного отношения включить в новое столько строк, сколько кортежей содержится в подчинённом отношении этого кортежа.

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

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

Код сотрудника	ФИО	Должность	Проекты
1	Иванов Иван Иванович	Программист	ID: 123; Название: Система управления паровым котлом; Дата сдачи: 30.09.2011 ID: 231; Название: ПС для контроля и оповещения о превышениях ПДК различных газов в помещении; Дата сдачи: 30.11.2011 ID: 321; Название: Модуль распознавания лиц для защитной системы; Дата сдачи: 01.12.2011

Код сотрудника	ФИО	Должность	Код проекта	Название	Дата сдачи
1	Иванов Иван Иванович	Программист	123	Система управления паровым котлом	30.09.2011
1	Иванов Иван Иванович	Программист	231	ПС для контроля и оповещения о превышениях ПДК различных газов в помещении	30.11.2011
1	Иванов Иван Иванович	Программист	321	Модуль распознавания лиц для защитной системы	01.12.2011

13)

Вторая нормальная форма

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

Код поставщика	Город	Статус города	Код товара	Количество
1	Москва	20	1	300
1	Москва	20	2	400
1	Москва	20	3	100
2	Ярославль	10	4	200
3	Ставрополь	30	5	300
3	Ставрополь	30	6	400
4	Псков	15	7	100

Заранее известно, что в этом отношении содержатся следующие функциональные зависимости: { {Код поставщика, Код товара} -> { Количество}, {Код поставщика} -> {Город}, {Код поставщика} -> {Статус}, {Город} -> {Статус} } Первичный ключ в отношении: {Код поставщика, Код товара}. Очевидно, что отношение обладает избыточностью: оно описывает две сущности — поставку и поставщика. В связи с этим возникают следующие аномалии:

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

Аномалия удаления. Если от поставщика была только одна поставка, то при удалении информации о ней будет удалена и вся информация о поставщике.

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

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

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

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

В итоге будут получены два отношения:

Код поставщика	Код товара	Количество
1	1	300
1	2	400
1	3	100
2	4	200
3	5	300
3	6	400
4	7	100

Первому отношению теперь соответствуют следующие функциональные зависимости: {Код поставщика, Код товара} -> {Количество}

Код поставщика	Город	Статус города
1	Москва	20
2	Ярославль	10
3	Ставрополь	30
4	Псков	15

Второму отношению соответствуют: { {Код поставщика} -> {Город},  {Код поставщика} -> {Статус},  {Город} -> {Статус} } Такое разбиение устранило аномалии, описанные выше: можно добавить информацию о поставщике, который ещё не поставлял товар, удалить информацию о поставке без удаления информации о поставщике, а также легко обновить информацию в случае если поставщик переехал в другой город. Теперь можно сформулировать определение второй нормальной формы, до которого, скорее всего, читатель уже смог догадаться самостоятельно: отношение находится во второй нормальной форме (сокращённо 2НФ) тогда и только тогда, когда оно находится в первой нормальной форме и каждый его неключевой атрибут неприводимо зависим от первичного ключа.

14)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Роль - идентифицирует динамическую группу пользователей СУБД, каждый из которых обладает всеми привилегиями данной роли для доступа к объектам БД. Каждая SQL сессия ассоциируется с идентификатором пользователя (1-м), и с именем роли (Также с 1-м). Текущая роль может быть получена командой: >CURRENT ROLE

Создание ролей: >CREATE ROLE role_name

Удаление ролей: >DROP ROLE role_name

Выбор роли: >SET ROLE [role_name | NONE]

18) После создания роли, она не обладает какими-либо привилегиями по отношению к объектам базы. Это соответствует модели безопасности SQL: отсутствие любых прав до предоставления их явным образом. Привилегии для роли назначаются с использованием оператора выдачи разрешений, общий синтаксис которого, в данном случае, имеет следующий вид:

GRANT <privileges> ON [TABLE] {tablename | viewname} TO rolename;

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

SYSDBA

Владельцем таблицы или представления

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

Приведем примеры, предоставления объектных прав роли:

GRANT ALL ON TEST_SCORES TO FULL_ACCESS; GRANT INSERT, SELECT ON TABLE EMPLOYEE TO BJONES;

19) Проектирование баз данных — процесс создания схемы базы данных и определения необходимых ограничений целостности.

Основные задачи:

Обеспечение хранения в БД всей необходимой информации.

Обеспечение возможности получения данных по всем необходимым запросам.

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

Обеспечение целостности базы данных.

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

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

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

Чаще всего концептуальная модель базы данных включает в себя:

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

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

Логическое (даталогическое) проектирование

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

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

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

Физическое проектирование

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

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

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

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

Модель сущность-связь (ER-модель) (англ. entity-relationship model, ERM) — модель данных, позволяющая описывать концептуальные схемы предметной области.

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

Во время проектирования баз данных происходит преобразование ER-модели в конкретную схему базы данных на основе выбранной модели данных (реляционной, объектной, сетевой или др.).

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

20) Типы команд SQL

Команды языка SQL обычно подразделяются на несколько групп. Основные типы команд следующие:

1. DLL-язык определения данных. Команды данной группы используются для создания и изменения структуры объектов базы данных (например, для создания и удаления таблиц);

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

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

4. DQL-язык. Это наиболее часто используемые команды, предназначенные для формирования запросов к базе данных (запрос — это обращение к базе данных для получения соответствующей информации);

5. команды администрирования базы данных предназначены для осуществления

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

6. команды управления транзакциями.

Команды языка манипулирования данными DML (Data Manipulation Language) позволяют пользователю перемещать данные в базу данных и из нее:

INSERT — осуществляет вставку строк в таблицу.

DELETE — осуществляет удаление строк из таблицы.

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

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

SQL - Урок 4. Выборка данных - оператор SELECT

Итак, в нашей БД forum есть три таблицы: users (пользователи), topics (темы) и posts (сообщения). И мы хотим посмотреть, какие данные в них содержатся. Для этого в SQL существует оператор SELECT. Синтаксис его использования следующий: 

SELECT что_выбрать FROM откуда_выбрать;

Вместо "что_выбрать" мы должны указать либо имя столбца, значения которого хотим увидеть, либо имена нескольких столбцов через запятую, либо символ звездочки (*), означающий выбор всех столбцов таблицы. Вместо "откуда_выбрать" следует указать имя таблицы. Давайте сначала посмотрим все столбцы из таблицы users: SELECT * FROM users; 

Оператор UPDATE изменяет имеющиеся данные в таблице. Команда имеет следующий синтаксис:

UPDATE <имя таблицы>

SET {<имя столбца> = {<выражение для вычисления значения столбца>

| NULL

| DEFAULT},...}

[ {WHERE <предикат>}]

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

SQL-запрос на удаление записей из таблицы:

DELETE FROM users WHERE login='TestUser2'

После команды "DELETE FROM" идёт имя таблицы, в которой требуется удалить записи. Дальше описываем конструкцию "WHERE". Если запись будет соответствовать описанным условиям, то она будет удалена. Опять же обратите внимание, в зависимости от количества записей, удовлетворяющих условию после "WHERE", может удалиться любое их количество.

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

Синтаксис оператора DROP TABLE

DROP TABLE [IF EXISTS] tbl_name [, tbl_name,...] [RESTRICT | CASCADE]

Этот оператор удаляет таблицу или таблицы из текущей базы данных.

tbl_name

- Имя удаляемой таблицы.