
- •Файловый подход:
- •2. Организация интегрированной информационной базы сои – сущность подхода, достоинства и недостатки.
- •3. Понятие субд, основные функции субд.
- •4. Обеспечения безопасности и секретности данных.
- •5.Избирательный подход к обеспечению безопасности данных.Обязательный подход к обеспечению безопасности данных.
- •6. Контрольный след файла, модификация запроса как подходы к обеспечению безопасности данных.
- •7. Безопасность в статистических бд.
- •8. Проблемы обеспечения управляемой избыточности и целостности данных.
- •9. Понятие транзакции, свойства транзакции, способы завершения транзакции.
- •10.Основные подходы к обеспечению параллельного выполнения транзакций. Проблемы параллельного выполнения транзакций.
- •11. Проблема пропавших изменений.
- •12. Проблема промежуточных данных.
- •13. Проблема несогласованных данных.
- •14. Проблема данных–призраков.
- •15. Синхронизация запросов к бд с использованием блокировок. Элементы бд. Необходимость блокировки элементов бд. Элемент как примитив синхронизации. Легальное расписание.
- •16. Бесконечные ожидания. Решение проблемы бесконечного ожидания.
- •17. Тупики. Способы предотвращения тупиков.
- •18. Понятие расписания совокупности транзакций. Сериализуемое расписание.
- •19. Понятие протокола. Двухфазный протокол. Двухфазные транзакции. Типы блокировок.
- •20. Стратегия временных отметок, оптимистические стратегии.
- •21. Защита бд от отказов. Типы отказов. Архивные копии бд, Журнал бд. Зафиксированные транзакции. Стратегия двухфазной фиксации
- •23. Администрирование бд
- •25. Трехуровневая архитектура бд
- •27.Инфологический и даталогический уровни моделирования предметной области.
- •28. Классификация моделей данных
- •30. Инфологическое моделирование. Модель «сущность–связь»: Сущности,классификация и характеристика сущностей.
- •31. Инфологическое моделирование. Модель «сущность–связь»: Атрибуты, классификация и характеристика атрибутов.
- •32. Инфологическое моделирование. Модель «сущность–связь»: Связи, классификация и характеристика связи.
- •33. Инфологическое моделирование. Модель «сущность–связь»: Первичные и внешние ключи.
- •34. Инфологическое моделирование. Модель «сущность–связь»: ограничение целостности.
- •35. Документальные,тезаурусные и дескрипторные модели данных.
- •Операции над данными, определенные в иерархической модели:
- •Ограничения целостности.
- •Недостатки
- •Особенности построения сетевой модели данных
- •Преимущества
- •Недостатки
- •Операции над данными сетевой модели
- •38. Реляционная модель данных Состав реляционной модели данных
- •Достоинства и недостатки реляционной модели данных
- •40. Нормализованные отношения. Первичные и вторичные ключи отношений. Моделирование связей в реляционной модели данных. Внешние ключи
- •52. Реляционное исчисление.
- •60. Язык sql. Назначения языка. Стандарты sql. Подмножества языка.
27.Инфологический и даталогический уровни моделирования предметной области.
Концептуальное (инфологическое) моделирование — построение семантической модели предметной области, то есть информационной модели наиболее высокого уровня абстракции. Такая модель создаётся без ориентации на какую-либо конкретную СУБД и модель данных. Термины «семантическая модель», «концептуальная модель» и «инфологическая модель» являются синонимами. Кроме того, в этом контексте равноправно могут использоваться слова «модель базы данных» и «модель предметной области» (например, «концептуальная модель базы данных» и «концептуальная модель предметной области»), поскольку такая модель является как образом реальности, так и образом проектируемой базы данных для этой реальности.
Логическое (даталогическое) проектирование — создание схемы базы данных на основе конкретной модели данных, например, реляционной модели данных. Для реляционной модели данных даталогическая модель — набор схем отношений, обычно с указанием первичных ключей, а также «связей» между отношениями, представляющих собой внешние ключи.
Преобразование концептуальной модели в логическую модель, как правило, осуществляется по формальным правилам. Этот этап может быть в значительной степени автоматизирован.
На этапе логического проектирования учитывается специфика конкретной модели данных, но может не учитываться специфика конкретной СУБД.
28. Классификация моделей данных
Кроме трех рассмотренных уровней абстракции при проектировании БД существует еще один уровень, предшествующий им. Модель этого уровня должна выражать информацию о предметной области в виде, независимом от используемой СУБД. Эти модели называются инфологическими, или семантическими.
Инфологические модели данных - отражают в естественной и удобной для разработчиков и других пользователей форме информационно-логический уровень абстрагирования, связанный с фиксацией и описанием объектов предметной области, их свойств и их взаимосвязей.
Инфологические модели данных используются на ранних стадиях проектирования для описания структур данных в процессе разработки приложения, а дата-логические модели уже поддерживаются конкретной СУБД.
Документальные модели данных - соответствуют представлению о слабоструктурированной информации, ориентированной в основном на свободные форматы документов, текстов на естественном языке.
Тезаурусные модели - это модели, которые основаны на принципе организации словарей, содержат определенные языковые конструкции и принципы их взаимодействия в заданной грамматике. Эти модели эффективно используются в системах-переводчиках, особенно многоязыковых переводчиках. Принцип хранения информации в этих системах и подчиняется тезаурусным моделям.
Дескрипторные модели - самые простые из документальных моделей, они широко использовались на ранних стадиях использования документальных баз данных. В этих моделях каждому документу соответствовал дескриптор - описатель. Этот дескриптор имел жесткую структуру и описывал документ в соответствии с теми характеристиками, которые требуются для работы с документами в разрабатываемой документальной БД. Например, для БД, содержащей описание патентов, дескриптор содержал название области, к которой относился патент, номер патента, дату выдачи патента и еще ряд ключевых параметров, которые заполнялись для каждого патента. Обработка информации в таких базах данных велась исключительно по дескрипторам, то есть по тем параметрам, которые характеризовали патент, а не по самому тексту патента
29. Тоже самое, немного изменено