- •Содержание
- •1. Архитектура базы данных. Физическая и логическая независимость (трехуровневая модель ansi).
- •2. Описать процесс прохождения пользовательского запроса.
- •3. Модели данных.
- •4. Пользователи баз данных. Основные функции группы администратора бд.
- •3. Задание ограничений целостности при описании структуры бд и процедур обработки бд:
- •4. Первоначальная загрузка и ведение бд:
- •5. Защита данных:
- •6. Обеспечение восстановления бд:
- •6. Этапы разработки аис.
- •I стадия – предпроектное обследование:
- •II стадия – проектирование:
- •III стадия – ввод системы в действие:
- •7. Режимы работы с базой данных.
- •8. Архитектура клиент-сервер: структура типового интерактивного приложения.
- •10. Реляционная алгебра. Теоретико-множественные операции реляционной алгебры. Основные операции.
- •11. Реляционная алгебра. Специальные операции.
- •12. Язык sql. История развития sql. Структура sql. Типы данных.
- •Структура sql.
- •Типы данных.
- •13. Операторы описания данных (ddl).
- •14. Операторы манипулирования данными (dml).
- •15. Язык запросов dql. Оператор выбора select.
- •16. Предикаты раздела where.
- •17. Null-значения, трехзначная логика.
- •18. Агрегатные функции в операторе выбора. Вложенные запросы.
- •19. Этапы жизненного цикла ис. Этапы проектирования бд.
- •20. Системный анализ предметной области.
- •21. Инфологическое моделирование. Er - модель.
- •22. Алгоритм перехода от er к реляционной модели данных.
- •23. Даталогическое проектирование, корректная схема бд.
- •25. Последовательность нормальных форм. Их свойства. Первая нормальная форма (1нф), вторая нормальная форма (2нф).
- •26. Третья нормальная форма (3нф).
- •27. Сурбд Oracle. Конфигурации Oracle. Архитектура Oracle (физический и логический уровень).
- •28. Субд Oracle. Табличные пространства. Сегменты, экстенты и блоки данных.
- •29. Объекты бд Oracle. Создание таблиц. Типы данных. Пользовательские типы данных.
- •30. Субд Oracle. Создание индексов.
- •31. Субд Oracle. Создание представлений.
- •35. Субд Oracle. Создание табличных пространств.
- •36. Основные понятия и конструкции pl/sql. Архитектура pl/sql.
- •37. Поддерживаемый набор символов pl/sql. Арифметические операторы и операторы отношения.
- •38. Структура программы и переменные pl/sql.
- •39. Pl/sql. Условные операторы if.
- •40. Pl/sql. Циклы.
- •41. Pl/sql. Курсоры. Курсорный цикл for.
- •42. Pl/sql. Хранимые процедуры.
- •43. Pl/sql. Функции.
- •44. Pl/sql. Триггеры.
21. Инфологическое моделирование. Er - модель.
Инфологическая модель применяется на втором этапе проектирования БД, то есть после словесного описания предметной области. Инфологическая модель – это формализованное описание предметной области, которое легко "читается» и специалистами по БД и ПрО. Оно должно быть достаточно емким, чтобы можно было оценить глубину и корректность проработки проекта БД. Инфологическое проектирование прежде всего связано с попыткой представления семантики предметной области в модели БД.
ER-модель (от англ. entity-relationship model, модель «сущность — связь») — модель данных, позволяющая описывать концептуальные схемы предметной области.
ER-модель используется при высокоуровневом (концептуальном) проектировании баз данных. С её помощью можно выделить ключевые сущности и обозначить связи, которые могут устанавливаться между этими сущностями.
ER-модель представляет собой формальную конструкцию, которая сама по себе не предписывает никаких графических средств её визуализации. В качестве стандартной графической нотации, с помощью которой можно визуализировать ER-модель, была предложена диаграмма «сущность-связь» (англ. entity-relationship diagram, ERD, ER-диаграмма).
Во время проектирования баз данных происходит преобразование ER-модели в конкретную схему базы данных на основе выбранной модели данных (реляционной, объектной, сетевой или др.).
22. Алгоритм перехода от er к реляционной модели данных.
Правила преобразования ER-модели в реляционную.
1. Каждой сущности ставится в соответствие отношение реляционной модели данных. При этом имена сущности и отношения могут быть различными, потому что на имена сущностей могут не накладываться дополнительные синтаксические ограничения, кроме уникальности имени в рамках модели. Имена отношений могут быть ограничены требованиями конкретной СУБД, чаще всего эти имена являются идентификаторами в некотором базовом языке, они ограничены по длине и не должны содержать пробелов и некоторых специальных символов. Например, сущность может быть названа «Книжный каталог", а соответствующее ей отношение желательно назвать, например, BOOKS (без пробелов и латинскими буквами).
2. Каждый атрибут сущности становится атрибутом соответствующего отношения. Переименование атрибутов должно происходить в соответствии с теми же правилами, что и переименование отношений в п.1. Для каждого атрибута задается конкретный допустимый в СУБД тип данных и обязательность или необязательность данного атрибута (то есть допустимость или недопустимость NULL значений для него).
3. Первичный ключ сущности становится PRIMARY KEY соответствующего отношения. Атрибуты, входящие в первичный ключ отношения, автоматически получают свойство обязательности (NOT NULL).
4. В каждое отношение, соответствующее подчиненной сущности, добавляется набор атрибутов основной сущности, являющейся первичным ключом основной сущности. В отношении, соответствующем подчиненной сущности, этот набор атрибутов становится внешним ключом (FOREING KEY).
5. Для моделирования необязательного типа связи на физическом уровне у атрибутов, соответствующих внешнему ключу, устанавливается свойство допустимости неопределенных значений (признак NULL). При обязательном типе связи атрибуты получают свойство отсутствия неопределенных значений (признак NOT NULL).