- •1) Файловые системы хранения данных: принцыпы построения, область применения, достоинства и недостатки.
- •3)Система управления базой данных (субд) и языковые средства субд.
- •5. Персонал для поддержки БнД
- •6) Трехуровневая архитектура баз данных, назначение отдельных уровней.
- •2)Принципы централизованного управления данными.
- •5) Преимущества и недостатки технологии баз данных.
- •7) Принципы информационного моделирования. Виды моделей данных и требования к ним.
- •8) Концепция реляционной модели данных.
- •9) Структурная организация данных в реляционной модели. Фундаментальные свойства отношения.
- •10) Требования целостности данных в реляционной модели. Поддержка целостности таблиц и целостности по ссылкам.
- •11) Реляционная алгебра и реляционное исчисление. Реляционная алгебра э. Кодда.
- •29) Избыточность и виды аномалий при изменении данных
- •1) Аномалии коррекции (обновления)
- •2) Аномалии удаления
- •3) Аномалии вставки
- •30) Виды функциональных зависимостей между атрибутами.
- •18) Создание таблиц бд с помощью языка sql.
- •17) Возможности современного языка sql.
- •16) Язык запросов по образцу (qbe).
- •19) Выборка данных с помощью языка sql. (Слишком много)
- •20) Общая характеристика модели «сущность-связь».
- •21) Сущность и ее атрибуты. Виды атрибутов. Ключевые атрибуты и виды ключей.
- •23) Пример построения er-моделию
- •25) Методология концептуального проектирования бд.
- •22) Связи между сущностями. Классификация связей по их степени. Типы связей с точки зрения их мощности. Степень участия в связи. Атрибуты связей.
- •24) Этапы проектирования бд: концептуальное, логическое физическое.
- •27) Необходимость проверки таблиц с учетом требований нормализации
- •28) Этапы процесса нормализации и взаимосвязи между разными нормальными формами.
- •1. Исключение элементов, несовместимых с реляционной моделью данных
- •2. Формирование набора таблиц для логической структуры реляционной бд
- •31) Требования нормальных форм 1нф, 2нф, 3нф и нфбк.
24) Этапы проектирования бд: концептуальное, логическое физическое.
Процесс проектирования БД состоит их трех основных этапов:
концептуальное проектирование;
логическое проектирование;
физическое проектирование.
1. Концептуальное проектирование БД – это процесс создания высокоуровневой семантической модели для данных, которые присутствуют в определенной предметной области.
Важно, что такая модель никак не зависит от любых аспектов ее физической реализации:
тип СУБД и вычислительной платформы;
набор прикладных программ;
средства программирования приложений и др.
Концептуальная модель данных создается на основе информации, записанной в требованиях пользователей.
Дополнительно проводится специальный опрос (анкетирование) пользователей.
В процессе разработки этой модели она постоянно обсуждается с пользователями для достижения полного согласия.
2. Логическое проектирование БД – это процесс создания информационной модели на основе выбранной модели структурной организации данных при их хранении и обработке.
Это делается без выбора конкретной СУБД и без учета остальных аспектов физической реализации БД.
Логическая модель данных создается путем преобразования концептуальной модели с учетом особенностей выбранной модели организации данных.
Важную роль логическая модель данных играет и при эксплуатации (сопровождении) уже готовой БД.
Эта модель, если ее постоянно поддерживать в актуальном состоянии, позволяет точно и наглядно представить любые изменения в структуре БД, а также оценить их влияние на прикладное ПО.
3. Физическое проектирование – это процесс принятия решений по реализации проекта разрабатываемой БД.
В случае реляционной БД это означает:
выбор конкретной (целевой) СУБД;
построение процедуры создания таблиц на жестком диске;
определение методов доступа к данным, чтобы обеспечить высокую производительность СУБД:
выбор необходимой файловой структуры (т.е. типов файлов для хранения данных);
оценка целесообразности использования индексных файлов;
планирование средств информационной безопасности и защиты данных.
27) Необходимость проверки таблиц с учетом требований нормализации
Нормализация улучшает модель данных за счет исключения нежелательной избыточности (дублирования) элементов данных.
В дальнейшем это гарантирует минимальное количество несоответствий (противоречий) между отдельными элементами данных и максимальную целостность данных.
В некоторых случаях глубокая нормализация препятствует достижению максимальной производительности СУБД.
Однако это не должно быть аргументом для отказа от нормализации, поскольку:
Особые требования к производительности СУБД учитываются на следующем этапе физического проектирования, когда, в случае необходимости, можно провести денормализацию.
Процедура нормализации будет успешной только при углубленном понимании смысла данных, их природы и назначения для конечных пользователей, что очень важно при проектировании БД.
Мощность современных компьютеров резко возросла, поэтому затраты при работе с нормализованными данными часто увеличиваются не очень существенно.
Суть процедуры нормализации состоит в том, чтобы проверить корректность объединения атрибутов для каждой таблицы в составе логической модели БД.
Нормализация — это формальный метод анализа таблиц с учетом ряда правил (требований).
Если некоторое требование не выполняется, то необходимо произвести декомпозицию соответствующей таблицы, чтобы по отдельности каждая из полученных таблиц удовлетворяла всем требованиям нормализации.