- •9) Иерархическая модель бд
- •10) Сетевая модель данных
- •13) Типы взаимосвязей в модели
- •14) Основные этапы проектирования бд
- •Проекция отношения
- •17) Декартово произведение отношений
- •Объединение отношений
- •22) Основные объекты реляционной базы данных
- •Acid-свойства транзакций
- •28) Блокировки
- •29) В иды восстановления данных
- •30) Основные функции субд
- •31) Структурированный язык запросов sql Что такое язык запросов sql?
- •Зачем нужно знать язык запросов sql?
- •2. 6 Набор операторов манипулирования данными
- •2. 6. 1 Операторы, связанные с курсором
- •2. 6. 1. 1 Оператор объявления курсора
- •2. 6. 1. 2 Оператор открытия курсора
- •2. 6. 1. 3 Оператор чтения очередной строки курсора
- •2. 6. 1. 4 Оператор позиционного удаления
- •2. 6. 1. 5 Оператор позиционной модификации
- •2. 6. 1. 6 Оператор закрытия курсора
- •Курсоры (ядро субд)
- •35) Настольные субд
- •36) Серверные субд и унаследованные данные
- •38) Интеграция базы данных с глобальной сетью Интернет
14) Основные этапы проектирования бд
Концептуальное (инфологическое) проектирование
Концептуальное (инфологическое) проектирование — построение семантической модели предметной области, то есть информационной модели наиболее высокого уровня абстракции. Такая модель создаётся без ориентации на какую-либо конкретную СУБД и модель данных. Термины «семантическая модель», «концептуальная модель» и «инфологическая модель» являются синонимами. Кроме того, в этом контексте равноправно могут использоваться слова «модель базы данных» и «модель предметной области» (например, «концептуальная модель базы данных» и «концептуальная модель предметной области»), поскольку такая модель является как образом реальности, так и образом проектируемой базы данных для этой реальности.
Конкретный вид и содержание концептуальной модели базы данных определяется выбранным для этого формальным аппаратом. Обычно используются графические нотации, подобные ER-диаграммам.
Чаще всего концептуальная модель базы данных включает в себя:
описание информационных объектов, или понятий предметной области и связей между ними.
описание ограничений целостности, т.е. требований к допустимым значениям данных и к связям между ними.
Логическое (даталогическое) проектирование
Логическое (даталогическое) проектирование — создание схемы базы данных на основе конкретной модели данных, например, реляционной модели данных. Для реляционной модели данных даталогическая модель — набор схем отношений, обычно с указанием первичных ключей, а также «связей» между отношениями, представляющих собой внешние ключи.
Преобразование концептуальной модели в логическую модель, как правило, осуществляется по формальным правилам. Этот этап может быть в значительной степени автоматизирован.
На этапе логического проектирования учитывается специфика конкретной модели данных, но может не учитываться специфика конкретной СУБД.
Физическое проектирование
Физическое проектирование — создание схемы базы данных для конкретной СУБД. Специфика конкретной СУБД может включать в себя ограничения на именование объектов базы данных, ограничения на поддерживаемые типы данных и т.п. Кроме того, специфика конкретной СУБД при физическом проектировании включает выбор решений, связанных с физической средой хранения данных (выбор методов управления дисковой памятью, разделение БД по файлам и устройствам, методов доступа к данным), создание индексов и т.д.
15) ОБЪЕДИНЕНИЕ ОТНОШЕНИЙ
Объединением двух совместимых по типу отношений А и В (А union В) называется отношение с тем же заголовком, как и в отношениях А и В, и с телом, состоящим из множества всех кортежей t, принадлежащих А или В, или обоим отношениям за исключением повторяющихся.
ПЕРЕСЕЧЕНИЕ ОТНОШЕНИЙ
Пересечением двух совместимых по типу отношений A и B (A intersect B) называется отношение с тем же заголовком, как и в отношениях A и B, и с телом, состоящим из множества кортежей t, принадлежащих одновременно обоим отношениям A и B.
Пересечение / INTERSECT /
РАЗНОСТЬ ОТНОШЕНИЙ
Разность двух совместимых по типу отношений A и B (A minus B) – это отношение с тем же заголовком, как и в отношениях A и B, и с телом, состоящим из множества всех кортежей t, принадлежащих отношению A и не принадлежащих отношению B.
16) Ограничения в реляционных БД гарантируют целостность данных на самом низком уровне. Данные, которые не удовлетворяют ограничениям, физически не могут попасть в базу. В хранилищах типа ключ-значение таких ограничений нет, поэтому контроль целостности данных полностью лежит на приложениях. Однако в любом коде есть ошибки. Если ошибки в правильно спроектированной реляционной БД обычно не ведут к проблемам целостности данных, то ошибки в хранилищах типа ключ-значение обычно приводят к таким проблемам.