Окончить транзакцию

14. Создание схемы данных обеспечивает целостность взаимосвязанных таблиц:

A) при поиске в таблицах

B) при работе с прикладными программами

C) при модификации значений данных во взаимосвязанных таблицах

D) при работе с ключами

E) при изменении значений данных во взаимосвязанных таблицах

15. Достоинства сетевой модели:

A) разделение данных и связей

B) легкость выполнения операций включения и удапения

C) простота реализации связи М:М

D) трудность обработки элементов

E) четкость в обработке атрибутов

16. Между сегментами в иерархической модели существует связь:

A) предок - потомок

B) линейная или функциональная

C) начальный - конечный

D) исходный - исходный, если будет исходный - конечный

E) Логическая

17. Оператор языка SQL позволяет вюпочить новые значения для ряда полей в таблицу БД:

A) Insert Into A Values (5,100, 25, 400, ”А1mаtу”)

B) Select Аl, А2, А6 Ғrom А Where А5=”Аlmаtу”

C) Select * Ғrom А Where Аl>100 Order ВуА5

D) Insert Into A АЗ, А4 Values (35, 400)

E) Insert Into A A1, A5Values (5, ”А1mаtу”)

F) Insert Into C C1, C3 Values (5, 25)

18. Недостатки сетевой модели:

A) сложность представления данных на физическом уровне

B) сложность представления данных на логическом уровне

C) возможность реализации набора

D) четкость в обработке атрибутов

E) сложность для понимания обычным пользователем

19. Оператор языка SQL позволяет выбрать данные из таблицы БД по усдовию, где используется значение числового поля:

A) Delete From A Where A5=”Almaty”

B) Select* From A Where A1

C) Select* From A

D) Delete From A Where A1

E) Delete From A Where A1

F) Select* From A Where A5=”Almaty”

G) Select A1, A4 From A Where A3

20. Свойства данных, поддерживаемые в базе данных:

A) независимость, интеграция

B) целостность, дублирование, защита

C) нецелостность и интеграция

D) Целостность

E) физическая и логическая зависимостъ, защита

F) зависимость, интеграция и защита-

G) независимость, дублирование, интеграция -

21. Триггер включает в себя:

A) языки программирования

B) ограничения целостности

C) пользовательские приложения

D) систему управления БД

E) схему и подсхемы, действия с логикой

F) БД и языковые средства

Три́ггер (англ. trigger) — это хранимая процедура особого типа, которую пользователь не вызывает непосредственно, а исполнение которой обусловлено действием по модификации данных: добавлением INSERT, удалением DELETE строки в заданной таблице, или изменением UPDATE данных в определенном столбце заданной таблицы реляционной базы данных. Триггеры применяются для обеспечения целостности данных и реализации сложной бизнес-логики. Триггер запускается сервером автоматически при попытке изменения данных в таблице, с которой он связан. Все производимые им модификации данных рассматриваются как выполняемые в транзакции, в которой выполнено действие, вызвавшее срабатывание триггера. Соответственно, в случае обнаружения ошибки или нарушения целостности данных может произойти откат этой транзакции.

Момент запуска триггера определяется с помощью ключевых слов BEFORE (триггер запускается до выполнения связанного с ним события; например, до добавления записи) или AFTER (после события). В случае, если триггер вызывается до события, он может внести изменения в модифицируемую событием запись (конечно, при условии, что событие — не удаление записи). Некоторые СУБД накладывают ограничения на операторы, которые могут быть использованы в триггере (например, может быть запрещено вносить изменения в таблицу, на которой «висит» триггер, и т. п.)

Кроме того, триггеры могут быть привязаны не к таблице, а к представлению (VIEW). В этом случае с их помощью реализуется механизм «обновляемого представления». В этом случае ключевые слова BEFORE и AFTER влияют лишь на последовательность вызова триггеров, так как собственно событие (удаление, вставка или обновление) не происходит.

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

22. Этапы проектирования базы данных:

A) логическое и физическое проектирование

B) концептуальное проектирование

C) эксплуатация и разработка БД

D) этапы формулировки заданий и экспериментального проектирования

E) экспериментальное проектирование

F) экспериментальная разработка

G) формулировки и анализа требований, концептуального, логического и физического проектирования

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

A) преобразование собранной информации

B) сбор информации и алгоритмов

C) определение сферы применения СУБД

D) определение всех функций, сбор данных

E) сбор требований, обработка, печать

F) определение всех функций и алгоритмов, сбор данных

24. Жизненный цикл БД содержит 2 фазы:

A) обработка программ

B) удаления

C) эксплуатация

D) сохранения БД

E) корректировка данных

F) реализация

G) проектирования

25. В операторе UPDATE языка SQL в конструкции SЕТ указывается:

A) имена наборов таблиц и данных

B) выражение, определяющее значение и имя поля

C) имена объектов и значений

D) список с указанием имен атрибутов и новых значений

E) список записей, создающих запрос

F) список объектов и таблиц

G) список полей и их новых значений

UPDATE [LOW_PRIORITY] [IGNORE] имя_таблицы

SET имя_столбца1=выражение1

[, имя_столбца2=выражение2,...]

[WHERE where_definition]

[LIMIT число]

качественные и количественные характеристики сущности.

http:// www.intuit.ru/studies/courses/3439/681/lecture/14024

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

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

Преобразование отношения к первой нормальной форме может привести к увеличению количества реквизитов (полей) отношения и изменению ключа.

Например, отношение Студент = (Номер, Фамилия, Имя, Отчество, Дата, Группа) находится в первой нормальной форме.

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

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

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

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

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

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

реквизитов Студент показан на рис. 5.3, на котором ключевой реквизит указан *.

Рис. 5.3. Графическое изображение функциональной зависимости реквизитов

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

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

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

Итак, таблица, находящаяся во второй нормальной форме, должна удовлетворять следующим правилам:

таблица должна содержать данные об одном типе объектов;

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

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

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

Понятие третьей нормальной формы основывается на понятии нетранзитивной зависимости.

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

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

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

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

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

Пример 5.9 "Расщепление" информационного объекта, содержащего транзитивную зависимость описательных реквизитов, показано на рис. 5.4. Как видно из рис. 5.4, исходный информационный объект Студент группы представляется в виде совокупности правильно структурированных информационных объектов (Студент и Группа), реквизитный состав которых тождественен исходному объекту.

Отношение Студент = (Номер, Фамилия, Имя, Отчество, Дата, Группа) находится одновременно в первой, второй и третьей нормальной форме.

Рис. 5.4. Расщепление" информационного объекта, содержащего транзитивную зависимость описательных реквизитов

Пример 5.5 Пример представления информационного объекта Студент в виде графа

Отношение "один-к-одному" (1:1) означает, что каждая запись в одной таблице соответствует только одной записи в другой таблице.

Отношение " один-ко-многим" (1:М) означает, что каждой записи в одной таблице соответствует одна или несколько записей в другой таблице.

Отношение "многие-к-одному" (М:1) аналогично рассмотренному ранее типу "один-ко-многим". Тип отношения между объектами зависит от вашей точки зрения.

Отношение "многие-ко-многим" (М:М). возникает между двумя таблицами в тех случаях, когда каждой запись в одной таблице соответствует 0, 1, 2 и более записей в другой таблице и наоборот.

Реляционная модель данных

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

Для реляционных отношений характерны следующие особенности.

Любой тип записи содержит только простые (по структуре) элементы данных.

Порядок кортежей в таблице несуществен.

Упорядочение значащих атрибутов в кортеже должно соответствовать упорядочению атрибутов в реляционном отношении.

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

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

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

Пример 5.1. Представим БД "Учебный процесс"в виде реляционной модели (таблица 5.1).

Таблица 5.1.

Рис.. Пример графического изображения информационных объектов с простым и составным ключом

Простой ключ состоит из одного реквизита, а составной ключ - из нескольких реквизитов.

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

7. ИНФОРМАЦИОННО-ЛОГИЧЕСКАЯ

МОДЕЛЬ ДАННЫХ

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

взаимосвязанных моделей данных.

Важнейшим этапом проектирования базы данных является разработка

информационно-логической (инфологической) модели предметной области, не

ориентированной на СУБД. В инфологической модели средствами структур данных

в интегрированном виде отражают состав и структуру данных, а также