- •1.Понятие информации и данных, их сходство и различие.
- •2.Сущность инфологического и даталогического подходов к проектированию баз данных. Задачи, решаемые на этапе инфологического проектирования информационной модели базы данных.
- •3.Понятие банка данных. Компоненты банка данных и их назначение. Задачи банком данных.
- •4.Этапы проектирования базы данных. Задачи информационно-логического (инфологического) этапа проектирования.
- •5.Нормализация реляционных отношений. Четвертая нормальная форма.
- •6.Архитектура базы данных. Физическая и логическая независимость данных. Архитектура базы данных в соответствии со стандартом ansy.
- •7. Пользователи систем баз данных. Основные функции группы администратора базы данных.
- •8. Явные и неявные ограничения целостности реляционной модели, их реализация средствами языка ddl.
- •9.Определение субд. Этапы развития. Языковые и программные средства субд.
- •10.Операции, выполняемые над реляционными отношениями. Односхемные операции реляционной алгебры. Примеры.
- •11. Классификация баз данных. Документальные базы данных.
- •13.Определение базы данных (бд), требования, предъявляемые к бд.
- •15. Двухуровневая архитектура банка данных (БнД). Процесс прохождения пользовательского запроса в БнД с двухуровневой архитектурой.
- •16.Трехуровневая архитектура банка данных (БнД). Процесс прохождения пользовательского запроса в БнД с трехуровневой архитектурой.
- •17. Функциональная зависимость атрибутов реляционных отношений. Нормализация отношений. Задачи нормализации отношений.
- •18. Первая и вторая нормальные формы реляционных отношений. Привести пример приведения отношения ко второй нормальной форме.
- •19.База данных (бд), определение, классификация бд, требования, предъявляемые к бд.
- •20.Структура даталогической модели данных, определенная стандартом codasyl. Определение и назначение структурных компонентов этой модели.
- •21.Аномалии модификации реляционных таблиц. Нормализация реляционных отношений. Пример.
- •22.Концептуальный, внутренний и внешний уровни представления данных в базе данных, их назначения.
- •23. Атрибуты в модели «Сущность-связь». Определение атрибутов, их назначение, способы изображения на er- диаграммах.
- •25.Реляционные таблицы. Первичные и внешние ключи отношений. Ограничения целостности по внешним ключам.
- •26. Идентификационно-зависисмые сущности в модели «Сущность-связь». Определение, пример, графическая интерпретация.
- •27.Подтипы сущностей в модели «Сущность-связь». Определение, пример, графическая интерпретация. Реализация в реляционной субд.
- •28.Агрегированные объекты в модели «Сущность-связь». Определение, пример, графическая интерпретация.
- •29.Реляционная схема таблиц. Типы ключей реляционных отношений. Определение, назначение, пример.
- •30.Язык описания данных реляционных таблиц (ddl). Структура этого языка.
- •31. Инфологическая модель "Сущность-связь", структурные компоненты модели, определение и назначение компонентов.
- •32.Тип связи “1: m” между объектами предметной области, определение, пример. Графическая интерпретация. Привести схему реализации в базе данных.
- •33.Агрегация и обобщение в модели «Сущность-связь» определение, сходство и различие. Примеры агрегации и обобщения.
- •34. Понятие отображения и ассоциации в модели «Сущность-связь», их сходство и различие. Привести пример.
- •35.Древовидная иерархическая структура базы данных. Рекурсивное дерево, пример.
- •36.Автоматизированные информационные системы, основанных на базе данных. Информационно-поисковые системы и системы обработки данных. Основные компоненты систем.
- •37.Реляционная модель данных. Операции реляционной алгебры, выполняемые над унарными и бинарными отношениями. Примеры.
- •38.Представление древовидных структур связанными линейными списками. Метод указателей на исходные записи.
- •39.Представление древовидных структур связанными линейными списками. Метод указателей на порожденные записи.
- •40.Физическая организация данных. Списковые структуры, последовательное распределение памяти.
- •41.Физическая организация данных. Списковые структуры, связное распределение памяти.
- •42.Организация данных в памяти. Связанное распределение памяти. Адресная функция.
- •43.Набор в модели данных codasyl. Определение, назначение, графическая интерпретация.
- •44.Этапы проектирования базы данных. Задачи логического (даталогического) этапа.
- •45.Физическая организация данных. Бинарное дерево. Технология поиска записи по бинарному дереву.
- •46.Неплотный индекс. Технология поиска записей в основном файле внешней памяти с использованием неплотного индекса.
- •47.Плотный индекс. Технология поиска записей базы данных в основном файле внешней памяти с использованием плотного индекса.
- •48.Инвертированный файл. Реализация многоключевого поиска в базе данных с использованием инвертированного файла.
- •49.Транзитивная зависимость атрибутов реляционных отношений. Третья нормальная форма. Привести пример приведения отношения к 3нф.
- •50. Физическая организация данных. Линейный список.
- •51.Анализ предметной области с помощью er-метода. Типы атрибутов сущности.
- •52. Инвертированный файл. Технология доступа к данным по вторичному ключу.
- •53. Назначение служебной и информационной частей хранимой записи
- •54.Методы обработки файлов на физическом уровне. Алгоритм поиска по бинарному дереву.
- •55.Правила перехода от er- модели предметной области к схеме базы данных.
- •56. Структуризация пространства внешней памяти при хранении объектов базы данных.
- •58.Логическое проектирование базы данных. Преобразование er- диаграммы в схему базы данных.
- •59. Корректирующие запросы в субд access. Команды sql, реализующие эти запросы.
- •60. Плотный индекс. Технология поиска записей базы данных в основном файле внешней памяти с использованием плотного индекса.
- •61.Установить функциональную зависимость атрибутов реляционного отношения вклад (фио вкладчика, Номер сберкнижки, Дата, Приход, Расход, Остаток), нормализовать его, приведя к 3 нормальной форме.
- •73. Из таблиц r2(фио, Группа) и r3(Группа, Дисциплина, Дата_экзамена) сформировать sql-запрос: «Вывести список студентов, которым надо сдавать экзамен с указанием названия сдаваемых дисциплин».
- •74.Команда Select языка запросов к базе данных sql. Формат и назначение этой команды.
- •1. Понятие информации и данных, их сходство и различие.
- •2.Сущность инфологического и даталогического подходов к проектированию баз данных. Задачи, решаемые на этапе инфологического проектирования информационной модели базы данных.
- •12. Описание реляционных таблиц в нотации Бэкуса-Наура. Пример.
- •14.Реляционное отношение. Определение, свойства. Разносхемная операция реляционной алгебры естественное соединение, пример.
- •24. Слабые сущности в инфологической модели «Сущность-связь». Определение, пример, графическая интерпретация.
5.Нормализация реляционных отношений. Четвертая нормальная форма.
Нормальная форма — свойство отношения в реляционной модели данных, характеризующее его с точки зрения избыточности, потенциально приводящей к логически ошибочным результатам выборки или изменения данных. Процесс преобразования отношений базы данных к виду, отвечающему нормальным формам, называется нормализацией. Нормализация предназначена для приведения структуры БД к виду, обеспечивающему минимальную логическую избыточность, и не имеет целью уменьшение или увеличение производительности работы или же уменьшение или увеличение физического объёма базы данных. Конечной целью нормализации является уменьшение потенциальной противоречивости, хранимой в базе данных информации.
Отношение находится в четвертой нормальной форме (4НФ), если оно находится в 3НФ или НФБК и все независимые многозначные ФЗ разнесены в отдельные отношения с одним и тем же ключом.
Иными словами, 4НФ применяется при наличии в отношении более чем одной многозначной ФЗ и требует, чтобы отношение не содержало независимых многозначных ФЗ.
Нормализация отношений выполнялась путем разложения (декомпозиции) схем отношений.
Очевидно, что при таком подходе должен соблюдаться принцип обратимости: соединение проекций должно приводить к исходным отношениям.
Это предполагает отсутствие потери кортежей; появление ранее не существовавших кортежей; сохранение ФЗ (семантика взаимосвязей между данными не должна нарушаться).
6.Архитектура базы данных. Физическая и логическая независимость данных. Архитектура базы данных в соответствии со стандартом ansy.
В процессе научных исследований, посвященных тому, как именно должна быть устроена СУБД, предлагались различные способы реализации. Самым жизнеспособным из них оказалась предложенная американским комитетом по стандартизации ANSI
Уровень внешних моделей — самый верхний уровень, где каждая модель имеет свое "видение" данных. Этот уровень определяет точку зрения на БД отдельных приложений. Каждое приложение видит и обрабатывает только те данные, которые необходимы именно этому приложению. Например, система распределения работ использует сведения о квалификации сотрудника, но ее не интересуют сведения об окладе, домашнем адресе и телефоне сотрудника, и наоборот, именно эти сведения используются в подсистеме отдела кадров.
Концептуальный уровень — центральное управляющее звено, здесь база данных представлена в наиболее общем виде, который объединяет данные, используемые всеми приложениями, работающими с данной базой данных. Фактически концептуальный уровень отражает обобщенную модель предметной области (объектов реального мира), для которой создавалась база данных. Как любая модель, концептуальная модель отражает только существенные, с точки зрения обработки, особенности объектов реального мира.
Физический уровень — собственно данные, расположенные в файлах или в страничных структурах, расположенных на внешних носителях информации.
Эта архитектура позволяет обеспечить логическую (между уровнями 1 и 2) и физическую (между уровнями 2 и 3) независимость при работе с данными. Логическая независимость предполагает возможность изменения одного приложения без корректировки других приложений, работающих с этой же базой данных. Физическая независимость предполагает возможность переноса хранимой информации с одних носителей на другие при сохранении работоспособности всех приложений, работающих с данной базой данных. Это именно то, чего не хватало при использовании файловых систем.
