Базы данных (стр. 2 )

Области приложений баз данных.

Основные функциональные требования к базам данных:

Понятие модели данных.

Ранние модели данных – иерархическая и сетевая.

Введение в реляционную модель данных.

2. Реляционная модель

Отношения – основной структурный элемент.

Операции над отношениями и реляционная алгебра. Язык запросов.

Поддержка целостности.

3.Инфологическое проектирование

Концептуальные модели данных и семантические модели данных.

Анализ предметной области.

Модель “сущность-связь”.

Отношения между таблицами.

Рекурсивное отношение.

Устранение избыточности и неоднозначности при хранении данных.

CASE-средства разработки баз данных.

4. Нормализация данных.

Функциональная зависимость.

Нормальные формы (первая, вторая, третья, Бойса-Кодда), их иерархия и требования к ним.

Многозначная зависимость.

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

Процесс совершенствования модели данных на основе нормализации.

5. Язык SQL

Основные средства манипулирования данными.

Стандарты SQL.

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

Типы данных.

Определение данных с ограничениями целостности.

Оператор select, вложенные запросы, внешние объединения.

Встроенные функции.

Использование агрегатных функций и группировка.

Задание способа сортировки.

Операторы изменения данных.

SQL на стороне сервера: триггеры и загружаемые процедуры

Встраивание SQL в прикладную программу.

Динамический SQL.

6. Параллельная работа с базами данных. Транзакции, журнализация.

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

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

Связь с управлением буферами оперативной памяти.

Методы восстановления баз данных после сбоев.

7. Физическая организация баз данных и СУБД

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

Хешированные, индексированные файлы, бинарные деревья, инвертированные списки.

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

8. Архитектуры доступа к БД. Системные аспекты

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

Реализация систем с бизнес-логикой на сервере.

Типы организации серверов баз данных.

Модель с сервером приложений.

Интерфейсы доступа к базам данных.

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

Стандарты SQL.

Язык загружаемых модулей.

9. Информационные хранилища. OLAP-технология..

Различия требований к аналитической и оперативной обработке данных.

Многомерная модель данных (“многомерный куб”).

Многомерные, реляционные и гибридные системы OLAP.

Язык MDX.

Хранилища данных, витрины данных, извлечение данных.

Интеграция информации в хранилище данных.

Полуструктурированная модель данных и язык XML.

10. Перспективы развития баз данных

Перспективы развития БД.

Объектно-ориентированные БД, XML-серверы.

Объединение технологий БД и экспертных систем. Дедуктивные БД.

Гипертекстовые, мультимедийные БД.

1.4. Содержание практических занятий

Подробно содержание практических занятий изложено в учебном пособии “Базы данных, SQL и все такое. Лабораторный практикум” (на электронном носителе, входит в состав электронного УМК “Базы данных и технология SQL”, , 2005). Эти темы могут быть использованы при проведении лабораторных занятий в компьютерном классе (см. раздел 5.2.3. настоящего УМК).

Работа №1. Знакомство с принципами программирования доступа к базам данных в Delphi. Работа №2. Разработка первого приложения баз данных.

Работа №3. Разработка утилиты для выполнения SQL-запросов.

Работа №4. Построение инфологической модели базы данных.

Работа №5. Выбор сквозного задания (тема курсового проекта).

Работа №6. Проектирование структуры приложения сквозного задания.

Работа №7. Работа со справочниками.

Работа №8. Формирование твердой копии справочника.

Работа №9. Просмотр справочников иерархической структуры.

Работа №10. Редактирование справочников иерархической структуры.

Работа №11. Разработка программы для ввода основных фактов о предметной области.

Работа №12. Разработка системы регламентированной отчетности.

Работа №13. Перенос базы данных на Microsoft SQL Server 2000.

Работа №14. Хранимые процедуры и триггеры.

Работа №15. Разработка системы нерегламентированной отчетности (аналитическая система) на основе OLAP. Первый подход.

Работа №16. Разработка системы нерегламентированной отчетности на основе OLAP. Второй подход.

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

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

Материалы, определяющие порядок и содержание проведения промежуточных и итоговых аттестаций, соответствуют требованиям ГОС, приказам, распоряжениям и рекомендациям МО РФ, учебно-методического управления КемГУ и учебно-методического отдела НФИ КемГУ.

2.1. Состав материалов и формы контроля знаний

Контроль знаний студентов проводится по следующей схеме:

·  промежуточная аттестация знаний и умений в течение семестра;

·  защита курсового проекта;

·  аттестация по итогам семестра в форме зачета.

Материалы, определяющие порядок и содержание промежуточных и итоговой аттестаций, включают:

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

·  фонд тестовых заданий по дисциплине в целом;

·  методические указания к выполнению курсового проекта (см. раздел 5).

2.2. Требования к уровню усвоения программы, формы контроля

В результате изучения курса студенты должны:

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

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

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

Знания итогово оцениваются при защите курсового проекта и сдаче экзамена. Умения итогово оцениваются при защите курсового проекта.

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

·  Словесное описание предметной области;

·  Инфологическая модель данных;

·  Даталогическая модель;

·  Обсуждение степени нормальности предложенных структур;

·  Физическая модель.

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

·  диаграммы использования на языке UML для объяснения условий применения и функций разработанного прототипа системы;

·  диаграммы классов и диаграммы компонентов на языке UML для объяснения устройства программной системы;

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

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

·  модуль для работы со справочной информацией;

·  модуль формирования твердой копии справочников;

·  модуль описания данных;

·  модуль ввода фактических данных;

·  модуль формирования отчета.

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

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

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

Знания студента положительно оцениваются на экзамене при условии наличия защищенного курсового проекта и достаточно полного и точного ответа на вопросы. Возможно проведение зачета с использованием компьютерной тестовой системы, включенной в состав электронного УМК по дисциплине. В этом случае ”отлично” выставляется при наборе не менее 80 баллов.

2.3. Примерные вопросы к экзамену

1. Области приложений СУБД.

2. Интерфейсы СУБД для обеспечения интерактивного доступа к данным и создания программ.

3. Языки запросов, запросы через формы, генераторы отчетов, языки быстрого прототипирования приложений.

4. Жизненный цикл БД.

5. Согласованное хранение независимых наборов данных.

6. Независимый от прикладной задачи интерфейс по управлению данными.

7. Ограничение прав доступа.

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

9. Управление данными во внешней памяти, управление буферами оперативной памяти,

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

11. Анализ предметной области. Даталогическое проектирование. Инфологическое моделирование, модель “сущность-связь”. Отношения между таблицами, рекурсивное отношение.

12. Устранение избыточности и неоднозначности при хранении данных.

13. Реляционная алгебра и реляционное исчисление.

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

15. Способы хранения отношений, индексов, журналов.

16. Хешированные, индексированные файлы, бинарные деревья, инвертированные списки.

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

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

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

20. Методы восстановления баз данных после сбоев.

21. Язык SQL. Основные средства манипулирования данными. Стандарты SQL.

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

23. Типы данных.

24. Определение данных с ограничениями целостности.

25. Оператор select, вложенные запросы, внешние объединения.

Встроенные функции.

26. Использование агрегатных функций и группировка. Задание способа сортировки.

27. Операторы изменения данных.

28. SQL на стороне сервера: триггеры и загружаемые процедуры

29. Встраивание SQL в прикладную программу. Динамический SQL.

30. Двухуровневые модели доступа к БД: модель файлового сервера, модель удаленного доступа, модель сервера БД.

31. Типы организации серверов БД

32. Модель сервера приложений.

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

34. Информационные хранилища. OLAP-технология.

35. Различия требований к аналитической и оперативной обработке данных.

36. Многомерная модель данных (“многомерный куб”). Многомерные, реляционные и гибридные системы olap

37. Хранилища данных, витрины данных, извлечение данных.

38. Объектно-ориентированные БД. XML-серверы.

39. Объединение технологий БД и экспертных систем. Дедуктивные БД.

Гипертекстовые, мультимедийные БД.

2.4. Тест по курсу (итоговая оценка знаний)

Вопросы теста, а также автоматизированная система тестирования и оценки знаний QuickTutor (разработка автора) приведены в электронном УМК “Базы данных и технология SQL”, , 2005. Образцы вопросов теста, входящие в курс тестирования на основе автоматизированной системы, представлены ниже. Они даны в нотации, воспринимаемой компилирующим модулем тестовой системы.

Вопрос т:О Б:100

ER-диаграмма это:#

диаграмма производительности базы данных#

диаграмма “сущность – связь” #+

диаграмма потоков данных#

функциональная диаграмма #

##

Вопрос т:О Б:100

База данных, основанная на модели “сущность-связь”, представленной ниже,

НЕ позволит ответить на вопрос#

Какую суммарную зарплату получили сотрудники отдела Y за месяц Z за работу в отделе (не за участие в проектах)?#

Сколько денег выплачено сотрудникам, работавшим над проектом X за месяц Z?#

Сотрудники каких отделов работают над проектом X?#

Сколько денег заработали сотрудники отдела Y работая над проектом X за месяц Z? #+

##

Вопрос т:О Б:100

Диаграмма “сущность-связь”, представленная ниже, является

#

некорректной, т. к. набор сущностей Сотрудники связан сразу с четырьмя другими наборами сущностей.#

некорректной, т. к. наборы сущностей Проекты и Сотрудники связаны отношением “многие ко многим”.#

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

корректной. #+

##

Вопрос т:О Б:100

Как лучше всего описать структуру базы данных, которую разрабатывает Ваша проектная команда, для каждого из ее членов?#

С помощью карты зависимостей данных #

С помощью диаграммы использования (Use case) #

С помощью ER-диаграммы #+

Путем формирования словаря данных #

Путем определения отношений и зависимостей между ними #

##

Вопрос т:О Б:100

К какому типу связи относится связь между сущностями A и C?#

Один к одному#

Ни одного к одному#

Один ко многим#

Многие к одному#+

Многие ко многим#

##

Вопрос т:О Б:100

Что из следующего является начальной стадией в проектировании базы данных?#

Анализ предметной области#+

Определение системных требований #

Определение структур данных#

Определение ограничений #

Выявление рисков #

##

Вопрос т:О Б:100

Что может означать обязательная связь типа “один к одному” между таблицами?#

Модель не может быть реализована физически #

Требуются большее количество атрибутов #

Таблицы неправильно проиндексированы #

Следует объединить сущности с такой связью в одну #+

Требуется большее число сущностей #

##

Вопрос т:О Б:100

Что может означать необязательная связь типа “один к одному” между таблицами?#

Эта связь реализует отношение наследования одной таблицы от другой #+

Такая связь не имеет смысла #

Таблицы неправильно проиндексированы #

Следует объединить сущности с такой связью в одну #

Требуется большее число сущностей #

##

Вопрос т:О Б:100

Имеются две таблицы: A(ФИО, ГодРожд, Адрес) и B(ФИО, ГодРожд, Адрес, КатегорияВодителя). В каком отношении они находятся друг к другу?#

В отношении наследования, причем наследником является таблица B #+

В отношении наследования, причем наследником является таблица A #

В отношении “один ко многим” #

В отношении “многие ко многим” #

В отношении “многие к одному” #

##

Вопрос т:О Б:100

Имеются две таблицы: A(ID, ФИО, ГодРожд, Адрес) и B(ID, КатегорияВодителя)

Какую зависимость они реализуют?#

Зависимость наследования, причем таблица B наследует свойства таблицы A #+

Зависимость наследования, причем таблица A наследует свойства таблицы B #

В отношении “один ко многим” #

В отношении “многие ко многим” #

В отношении “многие к одному” #

##

Вопрос т:О Б:100

Каким образом следует реализовать связи между наборами сущностей СТУДЕНТ(ФИО, ДатаРожд, Адрес), ДИСЦИПЛИНА(Название), ПРЕПОДАВАТЕЛЬ(ФИО, Факультет)? #

Ввести еще один набор сущностей ЭКЗАМЕН(ФИОСтудента, ФИОПреподавателя, НазваниеДисциплины, Дата, Оценка) #+

Ввести еще один набор сущностей ЭКЗАМЕН(ФИОСтудента, ФИОПреподавателя, НазваниеДисциплины) а атрибуты Дата и Оценка разместить среди ранее определенных наборов сущностей#

Набор сущностей ДИСЦИПЛИНА расширить атрибутами, характеризующими понятие “экзамен по дисциплине”#

Атрибут Оценка добавить в набор сущностей СТУДЕНТ, атрибут ДатаЭкзамена добавить в наборы сущностей ДИСЦИПЛИНА и ПРЕПОДАВАТЕЛЬ#

##

Вопрос т:О Б:100

Каким образом лучше реализовать связи между наборами сущностей РЕЙС(Номер, Дата), САМОЛЕТ(Номер, Тип), НАПРАВЛЕНИЕ(Номер, АэропортНазначения), ПАССАЖИР(ФИО)? #

Ввести еще один набор сущностей БИЛЕТ(ФИОПассажира, НомерРейса, НомерТипаСамолета, НомерНаправления) #

Сделать такие преобразования: ввести набор сущностей БИЛЕТ(ФИОПассажира, НомерРейса) а набор сущностей РЕЙС расширить до следующего: РЕЙС(Номер, Дата, НомерНаправления, НомерТипаСамолета) #+

##

Вопрос т:О Б:100

Можно ли провести нормализацию таблиц базы данных на уровне инфологической модели? #

Можно #+

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

Нельзя #

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

##

Вопрос т:М Б:100

Укажите все верные высказывания: #

Даталогическая модель включает типы данных, а инфологическая нет #+

В даталогической модели определены первичные ключи, а в инфологической не определены #

В даталогической модели обязательно указано, как реализуются связи типа “многие ко многим” а в инфологической модели это не требуется #+

##

Вопрос т:М Б:100

Укажите все верные высказывания: #

Даталогическая модель зависит от СУБД #

Даталогическая модель не зависит от СУБД #+

Даталогическая модель содержит определения индексов #

Даталогическая модель не содержит определения индексов, т. к. они не значимыми для

отражения логических аспектов модели #+

##

Вопрос т:М Б:100

Укажите все верные высказывания: #

Физическая модель зависит от СУБД #+

Физическая модель не зависит от СУБД #

Физическая модель не содержит определения индексов #

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

##

Вопрос т:О Б:100

Результатом полной нормализации универсального отношения

Счета <Город, Банк, Клиент, АдресКлиента, №счета, Сумма, Валюта>

является его декомпозиция на следующие отношения (с учетом оптимизации структуры)#

<Клиент, КодКлиента, АдресКлиента>

<Город, КодГорода>

<Банк, КодБанка>

<КодГорода, КодБанка>

<КодКлиента, №счета>

<№счета, Сумма>#

<Клиент, КодКлиента, АдресКлиента>

<Город, КодГорода>

<КодГорода, Банк>

<КодКлиента, №счета, Банк>

<№счета, Банк, Сумма>#

<Клиент, КодКлиента, АдресКлиента>

<Город, КодГорода>

<Банк, КодБанка>

<КодГорода, КодБанка>

<КодКлиента, №счета, КодБанка>

<№счета, КодБанка, Сумма>#+

##

Вопрос т:О Б:100 №:1 П:2

В отношении ЗВЕРИ со схемой <ЗООПАРК, ЖИВОТНОЕ, ЕСТЕСТВЕННАЯ ЗОНА ОБИТАНИЯ> атрибут ЕСТЕСТВЕННАЯ ЗОНА ОБИТАНИЯ #

функционально полно зависит от совокупности атрибутов ЗООПАРК, ЖИВОТНОЕ#

функционально полно зависит от ЖИВОТНОЕ #+

функционально полно зависит от ЗООПАРК#

не зависит функционально полно ни от какой совокупности атрибутов отношения.#

##

Вопрос т:О Б:100 №:2

Отношение ЗВЕРИ, схема которого <ЗООПАРК, ЖИВОТНОЕ, ЕСТЕСТВЕННАЯ ЗОНА ОБИТАНИЯ> находится#

в первой нормальной форме #+

во второй нормальной форме #

в третьей нормальной форме#

в нормальной форме Бойса-Кодда.#

##

Вопрос т:О Б:100

Отношение ПРЕДПРИЯТИЯ со схемой

<ГОРОД, УПРАВЛЯЮЩАЯ КОМПАНИЯ, ПРЕДПРИЯТИЕ, ТОВАР>

можно нормализовать, выполнив его декомпозицию на отношения#

<ГОРОД, ПРЕДПРИЯТИЕ>

<УПРАВЛЯЮЩАЯ КОМПАНИЯ, ПРЕДПРИЯТИЕ>

<ПРЕДПРИЯТИЕ, ТОВАР>#+

<ГОРОД, ПРЕДПРИЯТИЕ>

<УПРАВЛЯЮЩАЯ КОМПАНИЯ, ГОРОД>

<ПРЕДПРИЯТИЕ, ТОВАР>#

<ГОРОД, ТОВАР>

<УПРАВЛЯЮЩАЯ КОМПАНИЯ, ПРЕДПРИЯТИЕ>

<ПРЕДПРИЯТИЕ, ТОВАР>#

<ГОРОД, ПРЕДПРИЯТИЕ>

<УПРАВЛЯЮЩАЯ КОМПАНИЯ, ТОВАР>

<ПРЕДПРИЯТИЕ, ТОВАР>#

##

Вопрос т:О Б:100

A	B	C
1	Гвозди	Молоток
2	Гвозди	Молоток
3	Гвозди	Молоток
4	Шурупы	Отвертка
5	Шурупы	Отвертка
6	Доски	Рубанок
7	Доски	Рубанок

Отношение, изображенное в таблице, имеет первичный ключ, основанный на атрибуте A. Какой нормальной форме противоречат данные в отношении?#

1NF#

2NF#

3NF#+

4NF#

5NF#

##

Вопрос т:О Б:100

A	B	C
1	Бананы	Южная Америка
1	Фейхоа	Южная Америка
1	Помела	Южная Америка
2	Мандарины	Африка
2	Апельсины	Африка

Отношение, изображенное в таблице, имеет первичный ключ, основанный на атрибутах A и B. Какой нормальной форме противоречат данные в отношении?#

1NF#

2NF#+

3NF#

4NF#

5NF#

##

Вопрос т:О Б:100

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

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

Определение требований #

Устранение ошибок #

Логическое проектирование #+

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

##

Вопрос т:О Б:100

Укажите наиболее правильное описание степени нормализации отношения со схемой ПРОИЗВОДИТЕЛИ <ПРЕДПРИЯТИЕ, ТОВАР, НАЧАЛЬНИК_ЦЕХА> :#

Отношение находится в третьей нормальной форме, т. к. НАЧАЛЬНИК_ЦЕХА находится в полной функциональной зависимости от ключа и не зависит ни от какого другого неключевого поля (т. к. само и является единственным неключевым). Но отношение не в нормальной форме Бойса-Кодда, т. к. кроме того, имеется функциональная зависимость атрибута ПРЕДПРИЯТИЕ от атрибута НАЧАЛЬНИК_ЦЕХА, который не является суперключом (или ключом-кандидатом).#+

Отношение находится во второй нормальной форме т. к. атрибут НАЧАЛЬНИК_ЦЕХА функционально полно зависит от ключа отношения#

Отношение очевидно удовлетворяет условиям первой нормальной формы. Кроме того, оно удовлетворяет требованиям второй нормальной формы. Более того, отношение находится в третьей нормальной форме т. к. единственный неключевой атрибут функционально полно зависит от первичного ключа. С другой стороны, атрибут ПРЕДПРИЯТИЕ функционально полно зависит от атрибута НАЧАЛЬНИК_ЦЕХА, который, следовательно, является ключом-кандидатом отношения.#

Отношение находится во второй нормальной форме т. к. ключ отношения составлен из двух атрибутов.#

##

Вопрос т:М Б:100

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

Обеспечить анализ данных для принятия верных управленческих решений.#

Обеспечить согласованное хранение независимых наборов данных. #+

Извлекать данные с помощью простого языка запросов без необходимости описывания сложных алгоритмов доступа и переработки данных. #+

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

Обеспечить независимый от прикладной задачи интерфейс по управлению данными. #+

##

Вопрос т:М Б:100

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

Обеспечить возможность одновременного доступа к данным нескольким пользователям.#+

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

Обеспечить надежное хранение данных даже не смотря на возможность сбоя в программе или технических средствах. #+

Обеспечить удобный интерфейс с человеком-оператором при работе с приложением баз данных.#

Обеспечить возможность формирования “твердой” копии результата запроса к базе данных. #

##

Вопрос т:М Б:100

Какие утверждения относительно системы управления файлами (СУФ) верны? (несколько ответов)#

СУФ (в отличии от СУБД) не может обеспечить высокопроизводительный поиск #+

СУФ (в отличии от СУБД) не способна выполнять сложные запросы, сформулированные на высокоуровневом языке запросов. #+

СУФ (в отличии от СУБД) не поддерживает транзакции #+

СУФ (в отличии от СУБД) не обеспечивает многопользовательского доступа #+

СУФ (в отличии от СУБД) не может предоставить единый интерфейс, независимый от прикладной задачи.#

##

Вопрос т:М Б:100

Что следует отнести к преимуществам централизованного подхода к хранению и управлению данными? (Несколько ответов)#

поддержка целостности данных #+

сокращение избыточности #+

возможность общего одновременного доступа к данным #+

возможность устранения противоречивости #+

##

Вопрос т:М Б:100

На чем основаны принципиальные различия в требованиях к структуре данных для систем OLTP (оперативной обработки) и систем OLAP (аналитической обработки)? Выберите несколько правильных ответов.#

В OLTP необходимо обеспечить выполнение многих мелких транзакций по изменению данных а в OLAP – немного длинных транзакций, читающих данные #+

В OLTP приходится использовать индексы а в OLAP нет#

В OLTP необходимо обеспечить выполнение параллельных изменений в базе данных а в OLAP как правило нет #+

В OLTP используется реляционная модель данных а в OLAP “многомерная” модель данных, хотя не всегда для хранения – иногда только для представления данных #+

Для OLTP достаточно обычного сервера баз данных а для OLAP необходим сервер, основанный на “многомерной” модели данных #

Для OLTP необходимо обеспечить запись информации с максимальной подробностью в то время как в OLAP обычным является интерес к агрегированным данным #+

##

Вопрос т:О Б:100

Какое утверждение относительно “хранилищ данных” НЕВЕРНО?#

Они, в отличие от обычных баз данных, предназначены для надежного хранения наиболее важной информации, объем которой превышает возможности обычных СУБД. #+

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

Они позволяют проводить “разработку” данных с целью выявления закономерностей. #

Они не применяются для реализации систем оперативного учета.#

##

Вопрос т:О Б:100

Что из перечисленного более всего повышает вероятность тупиков в системах OLTP?#

Использование триггеров#

Использование хранимых процедур#

Использование оптимистической блокировки#

Пользовательский ввод в ходе выполнения транзакции#+

Использование неявных транзакций#

##

Вопрос т:О Б:100

При каких условиях следует использовать денормализацию?#

При проектировании базы данных, которая будет работать в условиях частых обновлений #

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

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

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

##

Вопрос т:О Б:100

Что из перечисленного записывается в журнал транзакций?#