- •Оглавление
- •1. Введение. Представление данных в памяти компьютера 3
- •2. Модели представления данных 43
- •3. Проектирование реляционных бд 83
- •4 Реляционная алгебра 114
- •5. Case – технологии 127
- •6. Организация доступа прикладной программы 178
- •1. Введение. Представление данных в памяти компьютера
- •1.1 Предмет дисциплины и ее задачи
- •1.2 Основные понятия
- •1.3 Файловые системы, как первый шаг к субд
- •1.4 Структурная схема субд и основные функции
- •1.5 Преимущества и недостатки субд по сравнению с файловыми системами
- •1.6 Организация внешней памяти реляционной субд
- •1.7 Типы и структуры данных
- •1.8 Типы и структуры данных, применяемые в реляционных бд
- •1.9 Типы и структуры данных, применяемые в объектно-реляционных бд
- •1.10 Понятие модели данных
- •2. Модели представления данных
- •2.1 Иерархическая модель данных
- •2.2 Сетевая модель данных
- •2.3 Реляционная модель данных
- •2.4 Свойства отношений. Отличие отношений от таблиц.
- •2.5 Понятие целостности данных
- •2.6 Ограничения реляционных баз данных
- •2.7 Суть постреляционного объектно-ориентированного подхода
- •2.8 Объектно-ориентированные субд и стандарт odmg
- •2.9 Объектно-реляционные субд
- •2.10 No sql бд и субд
- •1. NoSql базы в-основном оупенсорсные и созданы в 21 столетии.
- •6. Распределенные системы
- •3. Проектирование реляционных бд
- •3.1 Этапы разработки базы данных
- •3.2 Критерии оценки качества логической модели данных
- •3.3 Проектирование баз данных на основе нормализации отношений
- •3.4 Первая нормальная форма
- •3.5 Аномалии обновления
- •3.6 Функциональные зависимости
- •3.7 Вторая нормальная форма
- •3.8 Третья нормальная форма
- •3.9 Алгоритм нормализации (приведение к 3nf)
- •3.10 Oltp и olap-системы
- •3.11 Корректность процедуры нормализации. Теорема Хеза
- •3.12 Нормальная Форма Бойса-Кодда (nfbk)
- •3.13 Четвертая Нормальная Форма
- •3.14 Пятая Нормальная Форма
- •3.15 Продолжение алгоритма нормализации (приведение к 5 nf)
- •4 Реляционная алгебра
- •4.1 Операции над отношениями: общие сведения
- •4.2 Синтаксис операторов реляционной алгебры
- •4.3 Оптимизация алгоритмов реализации запросов
- •5. Case – технологии
- •5.1 Общие вопросы проектирования ис, понятие case-технологии
- •5.2 Жизненный цикл по ис
- •5.3 Модели жизненного цикла по
- •5.4 Методология rad
- •5.5 Структурный подход к проектированию ис
- •5.6 Методология функционального моделирования sadt (idef0)
- •5.7 Моделирование потоков данных (методология Гейна-Сарсона)
- •5.8 Методы построения диаграмм «сущность-связь» (erd)
- •5.9 Моделирование данных case-методом Баркера
- •5.10 Методология idef1
- •6. Организация доступа прикладной программы к серверу базы данных
- •6.1 Общие сведения
- •6.2 Использование специализированных библиотек и встраиваемого sql
- •6.4 Odbc – открытый интерфейс к бд на платформе ms Windows
- •6.5 Jdbc - интерфейс к базам данных на платформе Java
- •6.6 Прикладные интерфейсы ole db и ado
- •Литература
2.10 No sql бд и субд
В течение многих десятилетий, выбор многих разработчиков и системных администраторов для их приложений всегда падал на реляционные СУБД. Несмотря на то, что они не такие уж и адаптивные, функционал реляционных СУБД позволял создавать довольно сложные системы данных. Этого было более чем достаточно, пока в конце 2000, не появились NoSQL СУБД.
Сам термин NoSQL сначала был названием очередной реляционной системы управления базами данных и подразумевал попытку избежать использования стандартов SQL. Затем другие производители ПО в области БД подхватили эту идею и стали использовать этот термин в отношении всех нереляционных баз данных.
Стоит подчеркнуть, что термин “NoSQL” имеет абсолютно стихийное происхождение и не имеет общепризнанного определения или научного учреждения за спиной. Это название скорее характеризует вектор развития ИТ в сторону от реляционных баз данных. Расшифровывается как Not Only SQL.
Характеристики NoSQL баз данных:
1. NoSql базы в-основном оупенсорсные и созданы в 21 столетии.
2. Не используется SQL .Имеется в виду ANSI SQL DML, так как многие базы пытаются использовать query languages похожие на общеизвестный синтаксис, но полностью его реализовать не удалось никому и вряд ли удастся.
3. Неструктурированные (schemaless) . В NoSQL базах в отличие от реляционных структура данных не регламентирована (или слабо типизированна, если проводить аналогии с языками прогаммирования) — в отдельной строке или документе можно добавить произвольное поле без предварительного декларативного изменения структуры всей таблицы. Таким образом, если появляется необходимость поменять модель данных, то единственное достаточное действие — отразить изменение в коде приложения.
Положительное следствие отсутствия схемы — эффективность работы с разреженными (sparse) данными. Если в одном документе есть поле date_published, а во втором — нет, значит никакого пустого поля date_published для второго создано не будет.
У неструктурированной схемы есть свои недостатки — помимо накладных расходов в коде приложения при смене модели данных — отсутствие всевозможных ограничений со стороны базы (not null, unique, check constraint и т.д.), также возникают дополнительные сложности в понимании и контроле структуры данных при параллельной работе с базой разных проектов (отсутствуют какие-либо словари на стороне базы). Впрочем, в условиях быстро меняющегося современного мира такая гибкость является все-таки преимуществом.
4. Представление данных в виде агрегатов (aggregates). В отличие от реляционной модели, которая сохраняет логическую бизнес-сущность приложения в различные физические таблицы в целях нормализации, NoSQL хранилища оперируют с этими сущностями как с целостными объектами.
Плюсы и минусы обоих подходов представлены в таблице:
Таблица
Нормализация данных |
Агрегированные данные |
Плюсы:
|
Минусы:
|
Минусы:
|
Плюсы:
|
5. Слабые ACID свойства. Долгое время консистентность (consistency) данных была «священной коровой» для архитекторов и разработчиков. Все реляционные базы обеспечивали тот или иной уровень изоляции — либо за счет блокировок при изменении и блокирующего чтения, либо за счет undo-логов. С приходом огромных массивов информации и распределенных систем стало ясно, что обеспечить для них транзакционность набора операций с одной стороны и получить высокую доступность и быстрое время отклика с другой невозможно.
На самом деле слабые ACID свойства не означают, что их нет вообще. В большинстве случаев приложение, работающее с реляционной базой данных, использует транзакцию для изменения логически связанных объектов (заказ - позиции заказа), что необходимо, так как это разные таблицы. При правильном проектировании модели данных в NoSQL базе (агрегат представляет из себя заказ вместе с перечнем пунктов заказа) можно добиться такого же самого уровня изоляции при изменении одной записи, что и в реляционной базе данных.