Базы данных PDF

1. 2. - - - - - - - - - - - - - 3. - Многократное использование данных - Сохранение затрат умственного труда - Небольшие затраты на разработку - Уменьшение избыточности данных - Легкость использования - П...

1. 2. - - - - - - - - - - - - - 3. - Многократное использование данных - Сохранение затрат умственного труда - Небольшие затраты на разработку - Уменьшение избыточности данных - Легкость использования - Простота внесения изменений - Достоверность - Конфиденциальность (секретность) - Защита от уничтожения и искажения - Готовность 4. - На больших ЭВМ - Настольные СУБД (эпоха ПК) - Распределенные БД (интеграция, транзакции, поддержка структурной целостности, многоплатформенная архитектура, начало работ по созданию ООБД, разработка стандартов языков) - Интранет **Особенности первого этапа** - Все СУБД базируются на мощных мультипрограммных операционных системах (MVS, SVM, RTE, OSRV, RSX, UNIX), поэтому в основном поддерживается работа с централизованной базой данных в режиме распределенного доступа. - Функции управления распределением ресурсов в основном осуществляются операционной системой (ОС). - Поддерживаются языки низкого уровня манипулирования данными, ориентированные на навигационные методы доступа к данным. - Значительная роль отводится администрированию данных. - Проводятся серьезные работы по обоснованию и формализации реляционной модели данных, и была созданная первая система (System R), ориентированная идеологию реляционной модели данных. - Проводятся теоретические работы по оптимизации запросов и управлению распределенным доступом к централизованной БД, было введено понятие транзакции. - Результаты научных исследований открыто обсуждаются в печати, идет мощный поток общедоступных публикаций, касающихся всех аспектов теории и практики баз данных, и результаты теоретических исследований активно внедряются в коммерческие СУБД. **Особенности второго этапа** - Все СУБД были рассчитаны на создание БД в основном с монопольным доступом. И это понятно. Компьютер персональный, он не был подсоединен к сети, и база данных на нем создавалась для работы одного пользователя. В редких случаях предполагалась последовательная работа нескольких пользователей, например, сначала оператор, который вводил бухгалтерские документы, а потом главбух, который определял проводки, соответствующие первичным документам. - Большинство СУБД имели развитый и удобный пользовательский интерфейс, В большинстве существовал интерактивный режим работы с БД, как в рамках описания БД, так и в рамках проектирования запросов. Кроме того, большинство СУБД предлагали развитый и удобный инструментарии для разработки готовых приложений без программирования. Инструментальная среда состояла из готовых элементов приложения в виде шаблонов экранных форм, отчетов, этикеток (Labels), графический редактор, которые действительно просто могли быть собраны в единый комплекс. - Во всех настольных СУБД поддерживался только внешний уровень представления реляционной модели, то есть только внешний табличный вид структур данных. - При наличии высокоуровневых языков манипулирования данными типа реляционной алгебры и SQL в настольных СУБД поддерживались низкоуровневые языки манипулирования данными на уровне отдельных строк таблиц. - В настольных СУБД отсутствовали средства поддержки ссылочной и структурной целостности базы данных. Эти функции должны были выполнять приложения, однако скудость средств разработки приложений иногда не позволяла это сделать, и в этом случае эти функции должны были выполняться пользователем, требуя от него дополнительного контроля при вводе и изменении информации, хранящейся в БД. - Наличие монопольного режима работы фактически привело к вырождению функций администрирования БД и в связи с этим к отсутствию инструментальных средств администрирования БД. - И, наконец, последняя и в настоящий момент весьма положительная особенность \-- это сравнительно скромные требования к аппаратному обеспечению со стороны настольных СУБД. Вполне работоспособные приложения, разработанные, например, на Clipper, работали на PC 286. - Практически все современные СУБД обеспечивают поддержку полной реляционной модели, а именно: - структурной целостности - допустимыми являются только данные, представленные в виде отношений реляционной модели; - языковой целостности, то есть языков манипулирования данными высокого уровня (с использованием SQL); - ссылочной целостности - контроля за соблюдением ссылочной целостности в течение всего времени функционирования системы, и гарантий невозможности со стороны СУБД нарушить эти ограничения. - Большинство современных СУБД рассчитаны на многоплатформенную архитектуру, то есть они могут работать на компьютерах с разной архитектурой и под разными операционными системами, при этом для пользователей доступ к данным, управляемым СУБД, на разных платформах практически неразличим. - Необходимость поддержки многопользовательской работы с базой данных и возможностьn децентрализованного хранения данных потребовали развития средств администрирования БД с реализацией общей концепции средств защиты данных. - Потребность в новых реализациях вызвала создание серьезных теоретических трудов по оптимизации реализации распределенных БД и работе с распределенными транзакциями и запросами с внедрением полученных результатов в коммерческие СУБД. - Для того чтобы не потерять клиентов, которые ранее работали на настольных СУБД, практически все современные СУБД имеют средства подключения клиентских приложений, разработанных с использованием настольных СУБД, и средства экспорта данных из форматов настольных **Особенности четвертого этапа** - Этот этап характеризуется появлением новой технологии доступа к данным- интранет. Основное отличие этого подхода от технологии клиент-сервер состоит в том, что отпадает необходимость использования специализированного клиентского программного обеспечения. Для работы с удаленной базой данных используется стандартный браузер Internet, например Microsoft Internet Explorer, и для конечного пользователя процесс обращения к данным происходит аналогично использованию Internet. - При этом встроенный в загружаемые пользователем HTML- страницы код, написанный обычно на языках Java, Java-script, Perl и других, отслеживает все действия пользователя и транслирует их в низкоуровневые SQL-запросы к базе данных, выполняя, таким образом, ту работу, которой в технологии клиент-сервер занимается клиентская программа. 5. **Определение целостности** 6. **Функции СУБД** 7. **Низкоуровневые функции СУБД** 8. **Пользователи СУБД** 9. **Транзакция. Её свойства** 10. **12 принципов Кодда** 1. **Информация** логически представлена **в виде таблиц**. 2. **Логический доступ к данным** должен осуществляться **по таблице, первичному ключу и столбцу**. 3. **Пустые значения** трактуются как «**отсутствие информации**», а не как пустые строки, пробелы или нули. 4. **Метаданные** (данные о базе данных) должны **храниться в базе данных**, как обычные данные. 5. Для работы с данными, представлениями, целостностью, авторизацией, транзакциями и операциями должен использоваться единый язык **должен использоваться один язык**. 6. **Обновления** в таблицах базы данных должны быть **отражены в представлениях,** и наоборот. 7. **Каждое** **действие** должно **осуществляться при помощи одной отдельной операции**: извлечение данных, вставка данных, обновление данных и удаление данных. 8. Методы **работы с данными для пользователей** и **внутренние механизмы хранени**я логически **разделены**. 9. Схему базы данных можно изменять (с помощью **пакетных операций** и **операций конечных пользователей)** без необходимости пересоздания самой базы или приложения, которое ее использует. 10. **Ограничения**, которые обеспечивают **целостность данных**, должны **храниться в метаданных**, а не в прикладной программе. 11. **Язык манипулирования данными** реляционной системы **не должен учитывать**, **где и как распределены данные физически**, и не должен требовать внесения изменений в зависимости от того, являются данные централизованными или распределенными. 12. Любые операции(процессы) со строками должны соблюдать те же правила целостности, что и процессы обработки наборов данных. 11. **Модели данных, используемые в СУБД** 12. **Иерархическая модель представления данных** 13. **Сетевая модель представления данных** 14. **Реляционная модель представления данных** 15. **Постреляционная модель представления данных** 16. **Многомерная модель представления данных** 17. **Структура реляционной модели. Типы данных реляционной модели** 18. **Отношение. Атрибуты и кортежи. База данных. Схема БД. Свойства отношений.** 19. **Зависимости между атрибутами** 20. **Метаданные** 21. **Целостность. Типы.** 22. **Элементы модели «Сущность-Связь»** 23. **Связывание таблиц** 24. **Реляционная алгебра. Отношение. Предикат отношения** 25. **Декартово произведение** 26. **Первичный ключ. Целостность сущностей** 27. **Вторичный индекс** 28. **Правила формирования отношений** 29. **Внешний ключ. Целостность внешних ключей** 30. **Ссылочная целостность. Стратегии поддержания ссылочной целостности** 31. **Замкнутость реляционной алгебры. Совместимость отношений по типу. Её достижение** 32. **Теоретико-множественные операторы реляционной алгебры** 33. **Выборка. Проекция. Соединение** 34. **Эквисоединение. Естественное соединение. Деление.** 35. **Внешнее соединение** 36. **Законы эквивалентных преобразований реляционной алгебры** 37. **Реляционное исчисление** 38. **SQL. История** 39. **SQL. Запросы действия** 40. **SQL. Команды языка DDL, DML, DCL** 41. **SQL. Составные части и методы использования** 42. **SQL. Управляющие конструкции** 43. **SQL. Курсор** Курсор в SQL ------------ Основные действия при работе с курсором --------------------------------------- Категории курсоров ------------------ Команды для управления курсором ------------------------------- 44. **SQL. Триггер** Триггеры в SQL -------------- Типы триггеров -------------- Пример триггера --------------- 45. **SQL. Хранимая процедура** Хранимые процедуры ------------------ Этапы создания хранимой процедуры --------------------------------- Пример создания хранимой процедуры ---------------------------------- 46. **SQL. Методы защиты данных** 47. **SQL. Индексы** 48. **Оператор SELECT. Использование агрегатных функций. Использование группировок. Использование имён корреляции. Использование сортировок** 49. **Оператор SELECT. Использование подзапросов. Использование объединения, пересечения и разности** 50. **Оператор SELECT. Предикат EXIST. Предикат LIKE. Предикат IN. Предикат BETWEEN. Предикат NULL.** 51. **Порядок выполнения оператора SELECT** 52. **Оптимизация реляционных запросов. Аспекты. План выполнения запроса**  53. **Критерии оптимизации запросов** 54. **Методы оптимизации запросов** 55. **Рекомендации по написанию запросов (оптимальных запросов)** 56. **[Логическое проектирование]** - Определение числа и структуры таблицы - Формирование запросов к БД - Определение типов отчетных документов - Разработка алгоритмов обработки информации - Создание форм для ввода и редактирования данных - И т.п. **[Методология логического проектирования данных]** (ДОП ИНЕТ): **[Этапы разработки базы данных:]** Модель предметной области Модель предметной области - это наши знания о предметной области. Знания могут быть как в виде неформальных знаний в мозгу эксперта, так и выражены формально при помощи каких-либо средств. Логическая модель данных Логическая модель описывает понятия предметной области, их взаимосвязь, а также ограничения на данные, налагаемые предметной областью. Примеры понятий - \"сотрудник\", \"отдел\", \"проект\", \"зарплата\". Физическая модель данных Физическая модель данных описывает данные средствами конкретной СУБД. Отношения, разработанные на стадии формирования логической модели данных, преобразуются в таблицы, атрибуты становятся столбцами таблиц, для ключевых атрибутов создаются уникальные индексы, домены преображаются в типы данных, принятые в конкретной СУБД. Собственно база данных и приложения **[Критерии оценки:]** - Адекватность базы данных предметной области - Легкость разработки и сопровождения базы данных - Скорость выполнения операций обновления данных (вставка, обновление, удаление кортежей) - Скорость выполнения операций выборки данных 57. Отношение находится в 1НФ, если все его атрибуты являются простыми (имеют единственное значение) 58. Отношение находится в 2НФ, если оно находится в 1НФ и каждый неключевой атрибут функционально полно зависит от первичного ключа 59. **3 НФ** Отношение находится в 3НФ, если оно находится в 2НФ и ни один неидентифицирующий атрибут не зависит от каких-либо других неидентифицирующих атрибутов (нет транзитивных зависимостей) В таблице \"Сумма\" зависит от \"Цена товара\" и \"Количество\", то есть, существует транзитивная зависимость между атрибутами. Создать таблицу продажи (код прод, код товара, кол-во), таблица товара (код товара, цена), таблица сумма (код прод, сумма) **3-ая усиленная НФ** Отношение находится в БКНФ (3-ей усиленной НФ), если оно находится в 3НФ и в нем отсутствуют зависимости ключей от неключевых атрибутов 60. Отношение находится в 4НФ в том и только том случае, когда существует многозначная зависимость А=\> В, а все остальные атрибуты отношения функционально зависят от А  Здесь \"Товары\" и \"Поставщики\" зависят от \"Код магазина\", но их зависимости независимы. Для 4НФ нужно разделить таблицу на несколько, чтобы избежать таких зависимостей. 61. Отношение находится в 5НФ (или нормальной форме проекции соединения) в том и только том случае, когда любая зависимость соединения в R следует из существования некоторого возможного ключа в R **Пример 5НФ**: Если у вас есть таблица, которая хранит информацию о продавцах, клиентах и товарах, то это может привести к ненужному дублированию данных, если таблица будет иметь слишком много соединений. 5НФ устраняет такие избыточности, разбивая таблицу на более мелкие связи. 62. Шестая нормальная форма устраняет все зависимости между атрибутами, включая временные. Доменно-ключевая нормальная форма требует, чтобы все ограничения в таблице базировались на ключах и доменах. 63. **Объектно-ориентированные базы данных:** a. **Активные и дедуктивные базы данных.** - **БД называется активной, если СУБД по отношению к ней выполняет не только те действия, которые явно указывает пользователь, но и дополнительные действия в соответствии с правилами, заложенными в саму БД.** - **Дедуктивная БД -- это система баз данных, которая может делать выводы (то есть заключать дополнительные факты) на основе правил и фактов хранящихся в (дедуктивной) базе данных. Дедуктивная БД состоит из двух частей: экстенциональной, содержащей факты, и интенциональной, содержащей правила для логического вывода новых фактов на основе экстенциональной части и запроса пользователя.** b. **Достоинства. Недостатки.** 1. **ООБД позволяют представлять сложные объекты более непосредственным образом, нежели реляционные системы.** 2. **Определение пользовательских абстракций. ООБД предоставляют возможность определять новые абстракции и управлять реализацией таких абстракций.** 3. **Облегченное проектирование некоторых связей.** 4. **Отсутствие потребности в определяемых пользователями ключах.** 5. **Наличие предикатов сравнения (дополнительные типы сравнения).** 6. **Меньшая потребность в соединениях.** 7. **Выигрыш в производительности. В большинстве ООБД при загрузке объекта в память хранимые в этом объекте идентификаторы объектов преобразуются в указатели по памяти.** 8. **Объектная алгебра. Объектная алгебра определяет пять фундаментальных операций, сохраняющих объекты: union, difference, select, generate и map.** 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. c. **Язык Smalltalk.** d. **Объект. Поведенческий аспект объектов.** - **Каждый объект имеет состояние и поведение.** - **Состояние объекта - набор значений его атрибутов. Поведение объекта - набор методов (программный код), оперирующих над состоянием объекта.** - **Значение атрибута объекта --- это тоже некоторый объект или множество объектов.** - **Состояние и поведение объекта инкапсулированы в объекте; взаимодействие между объектами производится на основе передачи сообщений и выполнении соответствующих методов.** - **Множество объектов с одним и тем же набором атрибутов и методов образует класс объектов.** - **Формальный аппарат и системная поддержка совместного моделирования и гарантирования согласованности этих структурной (статической) и поведенческой (динамической) частей.** - **В среде ООБД проектирование, разработка и сопровождение прикладной системы становится процессом, в котором интегрируются структурный и поведенческий аспекты.** e. **Объектно-ориентированные модели данных.** - **два уровня моделирования объектов: нижний (структурный) и верхний (поведенческий)** - **ООБД --- это набор элементов данных, связанных отношениями "входит в класс" или "является атрибутом"** - **может рассматриваться как ориентированный граф** - **четкое разделение схемы БД и самой БД** - **в качестве первичных концепций схемного уровня ООБД выступают типы и классы** 64. **Объектно-реляционные базы данных:** a. **Манифест систем баз данных третьего поколения.** - помимо традиционных услуг по управлению данными, СУБД третьего поколения должны обеспечивать поддержку более богатых структур объектов и правил; - СУБД третьего поколения должны включить в себя СУБД второго поколения; - СУБД третьего поколения должны быть открыты для других подсистем. b. **Поколения СУБД.** - Первое поколение относится к дореляционнымсистемам, таким как IMS, - СУБД второго поколения ---это системы SQL, - СУБД третьего поколения ---те, что придут (пришли) за ними c. **Informix Universal Server, Oracle8, DB2 Universal Database.** - Интеллектуальные большие объекты - Определение новых базовых типов данных - Индивидуальные типы - Типы со скрытой структурой - Специальные методы хранения, поиска и индексации - Составные типы данных - Тип данных со структурой записи - Типы коллекций (множеств, мультимножеств и списков ) - Модули DataBlade - Объектные типы и объектные таблицы - аналог типа записи - можно определить и набор методов типа - строки объектных таблиц -строчные объекты (rowobjects). - Типы коллекций - Табличный тип (тип одного из столбцов) - Тип массива (переменного размера) - Компания IBM - Вконце 1998 - Базовые идеи объектно-реляционных расширений DB2: - Объектная инфраструктура - Реляционные расширители - Создание иерархий типизированных таблиц - Дополнительные объектно-реляционные возможности: - Структура, поведение, наследование - Создание иерархий типизированных таблиц d. **Возможности.** - n-мерное объектно-ориентированное моделирование; - двухмерное реляционное моделирование; - наследование; - инкапсуляция; - постоянство существования объектов ( objectpersistence); - композиция классов; - полиморфизм; - навигационный доступ к объектам; - реляционный доступ (соединения); - непроцедурный доступ через запросы; - интерфейсы для традиционных языков третьего поколения; - интерфейсы для объектных языков третьего поколения; - интерфейсы для языков четвертого поколения; - независимое от языков хранение данных; - независимость служб баз данных от файловых систем; - поддержка оперативных служб СУБД. e. **Проблемы.** f. **User Defined Type.** - Позволяет определять новые типы данных, которые могут быть гораздо более сложными, чем встроенные типы данных языка SQL. - При определении структурного UDT требуется специфицировать не только содержащиеся в нем элементы данных, но и семантику типа данных, т.е. его поведение на основе интерфейса вызовов методов. - UDT являются полностью инкапсулированными. Доступ к значениями UDT возможен только через методы этого типа. 65. \- это базы данных, хранящие темпоральные данные; ТЕМПОРАЛЬНЫЕ ДАННЫЕ -**это произвольные данные, которые явно или неявно связаны с определенными датами или промежутками времени**. g. **Виды данных для представления времени.** h. **Транзакционное время.** i. **Типы темпоральных данных.** j. **Модели темпоральных данных.** **[Модель Снодграса.]** Имеется битемпоральное отношение R(А1, \..., Аn, T), где А1, \..., An --- набор атрибутов, Т --- битемпоральный атрибут. Тогда R можно представить в виде R = (А1, \..., Аn, Ts, Te, Vs, Ve), где Ts, Te, Vs, Ve --- атомарные темпоральные атрибуты, содержащие дату начала и окончания транзакционного и модельного времени. **[Модель К. Дженсена].** Историчные кортежи никогда не обновляются, то есть доступны только для чтения. Таким образом, это представление данных хорошо подходит для основанного на архивах хранения битемпоральных отношений. Битемпоральное отношение R с набором атрибутов A1,..., An может быть представлено в следующем виде: R=(A1,..., An, Vs, Ve, T, Op). атрибуты Vs и Ve хранят даты начала и окончания актуальности факта в моделируемой реальности соответственно. атрибут Т хранит информацию о времени внесения кортежа в журнал изменений. Запросы на создание и удаление кортежей обозначаются в атрибуте Op символами -- I (Insert) и D (Delete). Модификация данных - пара запросов -- удаление и создание записи -- с одинаковым атрибутом времени T. **[Модель C. Гадия]** Предполагает наличие битемпоральных меток у каждого из атрибутов кортежа, что обеспечивает возможность более гибкого моделирования реальности. Пусть битемпоральное отношение R имеет атрибуты (A1, \..., An, T), где Т -- темпоральный атрибут, определенный на множестве битемпоральных элементов. Тогда битемпоральное отношение R может быть представлено в виде отношений, где каждый из атрибутов имеет свою темпоральную метку: R=({(\[Ts, Te\] \[Vs, Ve\] A1)},...,{ (\[Ts, Te\] \[Vs, Ve\] An)}). Кортеж состоит из n элементов. Каждый элемент представляет собой тройку значений: транзакционное время \[Ts, Te\], модельное время \[Vs, Ve\] и значение атрибута Ai. **[Модель Е. МакКензи]** Битемпоральное отношение -- это последовательность состояний в модельном времени, проиндексированная транзакционным временем. В кортежах с модельным временем атрибуты имеют свои темпоральные метки. Битемпоральное отношение R с набором атрибутов A1,..., Anможет быть представлено в виде отношения, в котором каждый атрибут помечается временной меткой: R=(VR, T), где VR -- отношение в модельном времени; Т транзакционное время. Схема состояний отношения модельного времени имеет вид: VR=(A1V1, \..., AnVn), где A1,..., An-- набор атрибутов; Vi-- атрибут модельного времени, связанный с каждым атрибутом Ai и обозначающий время актуальности значения атрибута Ai в моделируемой реальности. **[Модель Дж. Бен-Зви]** Пусть битемпоральное отношение R состоит из набора атрибутов (A1, \..., An, T), где Т -- темпоральный атрибут, определенный на множестве битемпоральных элементов. Тогда R может быть представлено следующим образом: R=(A1,..., An, Tes, Trs, Tee, Tre, Td). В кортеже значение атрибута Tes (effective start) -- это время, когда значение атрибута кортежа становится актуальным. Атрибут Trs хранит информацию о том, когда Tes было сохранено в БД. Аналогично Tre хранит информацию о том, когда факт перестает быть актуальным в моделируемой реальности, а Tee когда Tre было зафиксировано в БД. Атрибут Td указывает на время, когда запись была логически удалена из БД. Там 2 разбиение на модели по подходам создания: **ПОДХОДЫ К СОЗДАНИЮ ТЕМПОРАЛЬНОЙ МОДЕЛИ** накопление моментальных снимков, или кумулятивных снимков (Cumulative snapshots); поддержка истории изменений данных, или непрерывной исторической модели (Continuous history model), -- таблицы событий и состояний **МОДЕЛЬ, ОСНОВАННАЯ НА ТАБЛИЦАХ МОМЕНТАЛЬНЫХ СНИМКОВ** Сбор снимков фрагмента предметной области и накоплении таких снимков в различных фрагментах БД или другой БД как истории жизни данных предметной области. Например, если снимки фиксируются в конце дня, то совокупность собранных за период снимков будут представлять ежедневное изменение картины данных предметной области, поддерживаемой в БД. Таблица моментального снимка **МОДЕЛЬ, ОСНОВАННАЯ НА ТАБЛИЦАХ СОБЫТИЙ** Добавление временной метки фиксации события (факта) как атрибута экземпляра сущности предметной области и отражение момента времени в таблице БД как истории жизни данных предметной области. (Например, учет оплаты счетов покупателем). Таблица реляционной БД, представляющая события предметной области, называется таблицей событий (Event Table). Обновление данных этой таблицы не производится, поскольку она предназначена для накопления данных (только операции добавления) **МОДЕЛЬ, ОСНОВАННАЯ НА ТАБЛИЦАХ СОСТОЯНИЯ** Добавление временных меток для фиксации начала и завершения определенного состояния как атрибутов экземпляра сущности предметной области экземпляров сущности и отражение моментов времени начала и завершения определенного состояния сущности в таблице БД как истории жизни данных предметной области. Таблица реляционной БД, представляющая состояние объектов предметной области, называется таблицей состояния (State Table). Под состоянием понимаются объекты, которые существуют в определенный период времени. k. **Архитектура многоуровневой темпоральной СУБД.** l. **Моделирование темпоральных данных.** 66. Последовательность операций над БД, рассматриваемая СУБД как единое целое. При выполнении транзакция может быть либо успешно завершена m. **Свойства транзакций.** **Свойства транзакции:** 1. **Атомарность**\ Это свойство означает, что транзакция должна быть выполнена полностью или не выполнена вообще. Частичные изменения не допускаются. Оно совпадает с \"неразрывностью (atomicity)\" из ACID. 2. **Сериализуемость**\ Гарантирует, что результаты выполнения параллельных транзакций идентичны результатам их последовательного выполнения. Это свойство связано с \"изолированностью (isolation)\" из ACID, но термин \"сериализуемость\" более узкий и указывает на конкретную модель изоляции транзакций. 3. **Согласованность**\ Транзакция переводит базу данных из одного согласованного состояния в другое, соблюдая правила целостности. Это совпадает с \"правильностью (correctness)\" или частично пересекается с \"согласованностью (consistency)\" в более широком смысле. 4. **Долговечность**\ Гарантирует, что результаты подтвержденной транзакции сохраняются даже при сбоях системы. Полностью соответствует \"устойчивости (durability)\" из ACID. **Свойства ACID-транзакций**: 1. **Неразрывность (atomicity)**\ Полностью соответствует \"атомарности\" из первого списка. 2. **Правильность (correctness)**\ Этот термин редко используется в стандарте ACID и часто является синонимом \"согласованности (consistency)\" из первого списка. В большинстве случаев \"правильность\" связана с выполнением правил бизнес-логики или целостности базы данных. 3. **Изолированность (isolation)**\ Это свойство говорит о том, что транзакция выполняется так, как если бы она была единственной. В первом списке это частично отражено через \"сериализуемость\". 4. **Устойчивость (durability)**\ Полностью соответствует \"долговечности\" из первого списка. **Соответствие между свойствами и acid свойствами:** - Атомарность = Неразрывность (atomicity). - Сериализуемость = Частный случай Изолированности (isolation). - Согласованность ≈ Правильность (consistency/correctness). - Долговечность = Устойчивость (durability). n. **Диспетчер транзакций.** **Диспетчер транзакций, или ТР-монитор, обеспечивает выполнение транзакций как логических единиц работы.** **Основные операции, которые обрабатывает диспетчер, это:** - **COMMIT: для фиксации изменений.** - **ROLLBACK: для отката изменений в случае ошибки.** **Диспетчер также отвечает за работу с журналами восстановления, которые состоят из активной (оперативной) и архивной частей. Журнал регистрации фиксирует все операции транзакций, обеспечивая возможность восстановления в случае сбоя. Например, если система завершится во время выполнения транзакции, диспетчер откатит ее и восстановит согласованное состояние базы данных​​.** o. **Параллельность.** **Параллельность - свойство СУБД, позволяющее многим транзакциям одновременно обращаться к одной базе данных. Проблемы параллельности включают:** - **Потерянные обновления: когда две транзакции одновременно изменяют одну запись, и изменения одной из них теряются.** - **Грязное чтение: одна транзакция читает данные, которые были изменены, но не зафиксированы другой транзакцией.** - **Неповторяющееся чтение: данные, которые транзакция читала ранее, могут измениться другой транзакцией.** - **Фантомное чтение: если другая транзакция добавляет или удаляет строки, которые соответствуют критериям выборки первой транзакции​​​.** **Для предотвращения этих проблем используются механизмы блокировок, протоколы синхронизации и уровни изолированности​​.** **Пример: если две транзакции пытаются одновременно обновить одну строку, блокировка гарантирует, что только одна из них завершит обновление​.** p. **Восстановление.** **Восстановление данных необходимо для предотвращения потерь в случае сбоя системы. Основной принцип восстановления - избыточность.** **Обеспечивается путем использования журналов транзакций (UNDO и REDO). Журнал транзакций используется для отслеживания всех операций. При сбое он помогает выполнить накат (REDO) успешных транзакций и откат (UNDO) незавершенных.** **Системы восстановления:** - **Простое восстановление с использованием контрольных точек -- контрольные точки фиксируют текущее состояние базы данных, что ускоряет процесс восстановления.** - **Алгоритм ARIES: позволяет эффективно восстанавливать базу данных, анализируя журналы, выполняя накат (REDO) успешных транзакций и откат (UNDO) незавершенных​​ (анализ, накат, откат​​​​)** q. **Реализация транзакций.** **Обновления данных сначала сохраняются в оперативной памяти, а запись на диск записываются только после подтверждения транзакции через COMMIT. Это оптимизирует производительность и позволяет избежать избыточных операций. Однако для обеспечения надежности используется правило опережающей записи в журнал (Write-Ahead Logging), которое фиксирует изменения еще до их применения к основной базе данных​​.** r. **Блокировка.** **Механизм блокировок предотвращает конфликты между транзакциями при доступе к одним и тем же данным (Управление параллельным выполнением транзакций).** **Типы блокировок:** - **Разделяемые (S - shared) - позволяют читать данные** - **Исключительные (X - exclusive) - блокируют все операции с данными** **Протоколы блокировки:** - **Протокол двухфазной блокировки:** **Фаза приобретения: транзакция запрашивает все необходимые блокировки.** **Фаза освобождения: после снятия блокировки транзакция больше не может запрашивать новые. Это предотвращает взаимные блокировки​​​** - **Протокол намеченной блокировки для более тонкого контроля​​​.** **Протоколы помогают избежать взаимных блокировок и обеспечивают согласованность​​.** s. **Уровень изолированности транзакций.** Уровень изолированности определяет степень защиты транзакции от влияния других. **Уровни изолированности:** **Read Uncommitted** - позволяет читать данные незавершенных транзакций. **Read Committed** - позволяет читать только зафиксированные данные. **Repeatable Read** - предотвращает изменение данных, прочитанных транзакцией. **Serializable** -- (**наивысший уровень**) обеспечивает полную упорядочиваемость транзакций.Высокий уровень изолированности повышает согласованность данных, но снижает параллелизм​​​. **Чем выше уровень изолированности, тем выше согласованность данных, но ниже производительность системы из-за большего числа блокировок​​.** В реальных системах часто выбираются промежуточные уровни, такие как Read Committed или Repeatable Read, которые обеспечивают баланс между производительностью и консистентностью данных​​. 67. *[Больши́е да́нные -]* обозначение структурированных и неструктурированных данныхогромных объёмов и значительного многообразия, эффективно обрабатываемых горизонтально масштабируемымипрограммнымиинструментами, появившимися в конце 2000-х годови альтернативных традиционным системам управления базами данныхи решениям класса BusinessIntelligence (термин появился 3 сентября 2008 года) ИсточникиBig Data - Интернет---соцсети, блоги, СМИ, форумы, сайты, интернет вещей (IoT). - Корпоративные данные---транзакционная деловая информация, архивы, базы данных. - Показания устройств---датчиков, приборов, атакже метеорологические данные, данные сотовой связи и т. д. - Социальные сети и их данные - Данные от измерительных устройств - Данные от RFID - Журналы доступа пользователей веб-сайтов - Сенсорные сети - Тексты и документы из Интернета - Научные данные (астрономия, геном человека, исследования атмосферы, биохимия, биология) - Данные министерства обороны - Медицинские наблюдения - Фото-и видео-архивы - Данные электронной коммерции  Новые технологии обработки больших данных *[Shared Nothing Architecture]* - Sharednothingarchitecture(SNA) -архитектура независимых распределенных вычислений, в которой отдельные узлы имеют собственную память, дисковые массивы и устройства ввода/вывода. Каждый узел в такой архитектуре самодостаточен и ничем не делится с другими узлами сети. Такая архитектура хорошо масштабируется и становится все более популярной. - Каждый узел в SNA выполняет собственную задачу, взаимодействуя с другими узлами по специальному протоколу *[MapReduce]* Модель распределённых вычислений Google для параллельных вычислений очень больших, несколько петабайт, данных в компьютерных кластерах. Работа MapReduce состоит из двух шагов: Mapи Reduce. - На Map-шаге происходит предварительная обработка входных данных. Для этого один из компьютеров (называемый главным узлом---masternode) получает входные данные задачи, разделяет их на части и передает другим компьютерам (рабочим узлам---workernode) для предварительной обработки. - На Reduce-шаге происходит сбор предварительно обработанных данных. Главный узел получает ответы от рабочих узлов и на их основе формирует результат---решение задачи *[Hadoop]* - Hadoop-это программный фреймворк соткрытымисходнымкодом, используемый для хранения и обработки больших данных распределенным образом на больших кластерах товарного оборудования. - Hadoopлицензируется по лицензии Apache v2. - Hadoopбыл разработан на основе статьи, написанной Google о системе MapReduce, и в ней применяются концепции функционального программирования. - Hadoop---проект фонда Apache Software Foundation, свободно распространяемыйнабор утилит, библиотеки фреймворкдля разработки и выполнения распределённых программ, работающих на кластерахиз сотен и тысяч узлов. Используется для реализации поисковых и контекстных механизмов многих высоконагруженных веб-сайтов, в том числе, для Yahoo!и Facebook. Разработан на Javaв рамках вычислительной парадигмы MapReduce, согласно которой приложение разделяется на большое количество одинаковых элементарных заданий, выполнимых на узлах кластера и естественным образом сводимых в конечный результат. *[NoSQL]* NoSQL(от англ.*notonlySQL*---*не только SQL*)---термин, обозначающий ряд подходов, направленных на реализацию систем управления базами данных, имеющих существенные отличия от моделей, используемых в традиционных реляционных СУБДс доступом к данным средствами языка SQL. Применяется к базам данных, в которых делается попытка решить проблемы масштабируемостии доступностиза счёт атомарности(англ.*atomicity*) и согласованности данных(англ.*consistency*) *[R (язык программирования)]* Язык программирования, созданный специально для статистического анализа данных. - Разработан на факультете статистики Оклендского университета для внутреннего использования под влиянием другого подобного языка ---S, который был платным и недоступным для широкого круга разработчиков. Поэтому в Окленде решили создать бесплатную альтернативу. - У него свой уникальный синтаксис, функции и принципы работы и чёткая сфера применения ---статистические вычисления, анализ данных и машинное обучение. Его создавали специально для этих задач, и для других он не подходит. - R ---не только язык для анализа данных, но и целая рабочая среда, куда уже встроены готовые методы статистического анализа и инструменты для визуализации. 68. **1. Типы СУБД** **- Реляционные: MySQL, Oracle, PostgreSQL, Microsoft SQL Server.** **- Объектно-ориентированные: db4o, ObjectStore, Caché.** **- Объектно-реляционные: Informix, Sybase.** **- Иерархические и сетевые: IMS, InterSystems Caché.** **2. Классификация СУБД** **- По модели данных: реляционные, объектно-реляционные, сетевые, иерархические.** **- По степени распределённости: локальные, распределённые.** **- По способу доступа: файл-серверные, клиент-серверные, встраиваемые.** **3. Особенности популярных СУБД** **- Oracle: Высокая надёжность, но дорогая.** **- MySQL: Бесплатная, поддерживает несколько интерфейсов, но отсутствует встроенная поддержка XML.** **- PostgreSQL: Масштабируемая, поддерживает JSON, но сложная конфигурация.** **- MongoDB: Легко работать с данными любой структуры, но SQL не используется.** **- SQLite: Встраиваемая, легковесная, хранит всю базу данных в одном файле.** **4. Критерии выбора СУБД** **- Тип данных: Определите, какие данные будут храниться в базе (текст, мультимедиа, графы и т.д.), чтобы выбрать оптимальную СУБД для их обработки.** **- Масштаб проекта: Оцените предполагаемый объем данных и количество пользователей для выбора СУБД, способной обеспечить необходимую производительность и масштабируемость.** **- Интеграция с существующими системами: Убедитесь, что выбранная СУБД легко интегрируется с уже используемыми в организации технологиями и инструментами.** **- Стоимость владения: Рассмотрите не только первоначальные затраты на приобретение лицензий, но и расходы на поддержку, обучение персонала и масштабирование системы.** **5. Советы по выбору СУБД** **- Определите цели: Какие задачи должна решать СУБД?** **- Оцените инфраструктуру: Какие ресурсы есть в наличии?** **- Проанализируйте стоимость: Не только начальную, но и поддерживающую.** **- Проверьте поддержку: Наличие и доступность технической поддержки.** 69. это совокупность ее основных функциональных компонентов, а также средств обеспечения их взаимодействия друг с другом пользователями и системным персоналом t. **Виды баз данных** u. **Уровни архитектуры** [Внутренний (физический) уровень] -- наиболее близок к физическому хранилищу информации, связан со способами хранения информации на внешних устройствах - Определяет внутреннее представление базы данных - Внутреннее представление содержит экземпляры всех определенных типов внутренних (хранимых) записей - Внутреннее представление отделено от представления базы данных на аппаратном уровне, т.к. не рассматривает физические записи (блоки, страницы) [Внешний (пользовательский) уровень] - наиболее близок к пользователям, связан со способами представлений конкретных пользователей - Для каждого пользователя определен свой внешний уровень - Внешний уровень отражает особенности представления данных с точки зрения пользователя - Определяет *пользовательскую модель БД* - Определяет *язык управления базой данных*, приемлемый для конкретного пользователя [Концептуальный (общий логический, логический) уровень] -- связан с обобщенным представлением пользователей, абстрактным представлением данных в целом - Представление всей информации базы данных в более абстрактном, по сравнению с физическим уровнем, виде - В отличии от пользовательских представлений, данные представляются не так, как их видит конкретный пользователь, а так, как они есть на самом деле v. **Отображения** w. **Зависимость/независимость данных** x. **Функции СУБД** - - y. **Архитектурные подходы** - [распределенная; ] - [клиент-сервер; ] - [промежуточного слоя (разновидность распределенной); ] - компонентная; - [мобильная; ] - [агентов; ] - [одноранговая. ] (Доп): АРХИТЕКТУРА «ФАЙЛ-СЕРВЕР» Предполагает выделение одного из устройств сети ЭВМ в качестве центрального. Оно будет считаться сервером файлов. На главной машине хранится совместно используемая централизованная база данных. Другие же устройства сети выступают рабочими станциями, которые поддерживают пользовательский доступ к основной БД АРХИТЕКТУРА \"КЛИЕНТ-СЕРВЕР\" предполагается наличие машины в сети, которая будет являться главной. - Главный компьютер не только хранит централизованную БД, но и обеспечивает основную часть обработки требуемых пользователю данных. - Технология разделяет систему на две части: серверную и клиентскую. Последняя будет обеспечивать интерактивный сервис, а серверная - разделение информации, управление данными, безопасность и администрирование 70. z. **Определение. Характеристики.** **NoSQL - это тип систем управления базами данных (СУБД), которые предоставляют альтернативу традиционным реляционным базам данных. Основное отличие заключается в отказе от жесткой схемы данных и поддержке более гибких структур хранения.** **Характеристики NoSQL:** 1. **Отсутствие строгой схемы:\ NoSQL не требует заранее определенной схемы таблиц. Это позволяет легко изменять структуру данных в процессе разработки приложения.** 2. **Горизонтальное масштабирование:\ NoSQL-системы могут легко масштабироваться, добавляя новые серверы, что делает их подходящими для работы с большими объемами данных.** 3. **Поддержка различных моделей данных:\ NoSQL предлагает различные подходы к хранению данных: ключ-значение, документоориентированные базы, колоночные хранилища и графовые базы.** 4. **Высокая производительность:\ Благодаря оптимизации для специфичных задач, таких как обработка больших объемов данных в реальном времени, NoSQL базы часто быстрее реляционных баз для определенных типов нагрузок.** 5. **Гибкость и масштабируемость:\ NoSQL-системы поддерживают распределенные архитектуры, что делает их идеальными для облачных и распределенных приложений.** 6. **Отказ от ACID-свойств:\ В большинстве случаев NoSQL базам свойственны свойства BASE (Basically Available, Soft state, Eventually consistent), которые делают их подходящими для приложений с высокой доступностью и терпимостью к временной неконсистентности данных.** a. **Типы NoSQL СУБД (модели)** - [Хранилище «ключ-значение»] --- в нём есть большая хеш-таблица, содержащая ключи и значения. Примеры: Riak, Amazon DynamoDB; - [Документоориентированное хранилище] --- хранит документы, состоящие из тегированных элементов. Пример: CouchDB, MongoDB; - [Колоночное хранилище] --- в каждом блоке хранятся данные только из одной колонки. Примеры: HBase, ApacheCassandra, Google BigTable; - [Хранилище на основе графов] --- сетевая база данных, которая использует узлы и рёбра для отображения и хранения данных. Пример: **Amazon Neptune, Neo4J,** InfoGridи Infinite Graph.