- •Лекция 2. Введение в базы и банки данных
- •Оглавление
- •Основные понятия
- •Файловые системы
- •Системы с использованием баз данных
- •Система управления базами данных – субд
- •Программное обеспечение
- •База данных
- •Классификация субд Классификация по типу принятой модели данных
- •Классификация по архитектуре
- •Классификация по способу доступа к бд
- •Двухзвенные Трехзвенные
- •Классификация по скорости обработки информации
- •Функции субд
- •2. Среда баз данных
- •2.1. Предметная область базы данных
- •2.2. Трехуровневая архитектура базы данных
- •3. Независимость от данных
- •4. Языки баз данных
- •2.5.1. Язык определения данных ddl
- •2.5.2. Язык управления данными – dml
- •2.6. Классификация моделей данных
- •2.6.1. Объектные модели данных
- •2.6.2. Модели данных на основе записей
- •2.6.3. Физические модели данных
- •2.7. Функции и службы субд
- •2.8. Компоненты субд
- •2 .9. Архитектура многопользовательских субд
- •2.9.2. Файловый сервер
- •2.9.3. Технология «клиент-сервер»
Классификация субд Классификация по типу принятой модели данных
Классификацию баз данных по модели данных иллюстрирует рис. 5
.
Рис. 5. Классификация баз данных по модели данных
Иерархические базы данных основаны на иерархической модели данных, в которой связь между объектами базы данных образует перевернутое дерево. При такой модели каждый нижележащий элемент иерархии соединен только с одним расположенным выше элементом.
http://www.mstu.edu.ru/study/materials/zelenkov/ch_3_1.html
Рис. 6. Пример иерархической модели данных
Организация данных в СУБД иерархического типа определяется в терминах: элемент, агрегат, запись (группа), групповое отношение, база данных.
Атрибут (элемент данных) - наименьшая единица структуры данных. Обычно каждому элементу при описании базы данных присваивается уникальное имя. По этому имени к нему обращаются при обработке. Элемент данных также часто называют полем.
Запись - именованная совокупность атрибутов. Использование записей позволяет за одно обращение к базе получить некоторую логически связанную совокупность данных. Именно записи изменяются, добавляются и удаляются. Тип записи определяется составом ее атрибутов. Экземпляр записи - конкретная запись с конкретным значением элементов
Групповое отношение - иерархическое отношение между записями двух типов. Родительская запись (владелец группового отношения) называется исходной записью, а дочерние записи (члены группового отношения) - подчиненными. Иерархическая база данных может хранить только такие древовидные структуры.
Корневая запись каждого дерева обязательно должна содержать ключ с уникальным значением. Ключи некорневых записей должны иметь уникальное значение только в рамках группового отношения. Каждая запись идентифицируется полным сцепленным ключом, под которым понимается совокупность ключей всех записей от корневой по иерархическому пути.
Для групповых отношений в иерархической модели обеспечивается автоматический режим включения и фиксированное членство. Это означает, что для запоминания любой некорневой записи в БД должна существовать ее родительская запись. При удалении родительской записи автоматически удаляются все подчиненные.
Недостатки иерархических БД:
Иерархическая модель реализует отношение между исходной и дочерней записью по схеме 1:N, то есть одной родительской записи может соответствовать любое число дочерних. Допустим теперь, что исполнитель может принимать участие более чем в одном контракте (т.е. возникает связь типа M:N). В этом случае в базу данных необходимо ввести еще одно групповое отношение, в котором ИСПОЛНИТЕЛЬ будет являться исходной записью, а КОНТРАКТ - дочерней (рис. (6)). Таким образом, мы вынуждены дублировать информацию.
Сетевые базы данных основаны на сетевой модели данных, в которой связи между объектами данных могут быть установлены в произвольном порядке.
http://www.mstu.edu.ru/study/materials/zelenkov/ch_3_2.html
Рис. 7. Пример сетевой модели данных
Сетевая модель данных определяется в тех же терминах, что и иерархическая. Она состоит из множества записей, которые могут быть владельцами или членами групповых отношений. Связь между между записью-владельцем и записью-членом также имеет вид 1:N. Основное различие этих моделей состоит в том, что в сетевой модели запись может быть членом более чем одногогруппового отношения.
Реляционные базы данных основаны на реляционной модели данных, в которой каждая единица данных в базе данных однозначно определяется именем таблицы (называемой отношением), идентификатором записи (кортежа) и именем поля.
http://www.mstu.edu.ru/study/materials/zelenkov/ch_4_1.html
В реляционной модели достигается гораздо более высокий уровень абстракции данных, чем в иерархической или сетевой. Другими словами, представление данных не зависит от способа их физической организации. Это обеспечивается за счет использования математической теории отношений (само название "реляционная" происходит от английского relation - "отношение"). Отношения удобно представлять в виде таблиц. В отличие от иерархической и сетевой моделей данных в реляционной отсутствует понятие группового отношения. Для отражения ассоциаций между кортежами разных отношений используется дублирование их ключей.
Рис. 8. Пример реляционной модели данных
Объектно-реляционные базы данных содержат объектно-ориентированные механизмы построения структур данных (как минимум, механизмы наследования и поддержки методов) в виде расширений языка и программных надстроек над ядром СУБД.
http://www.fnti.kiae.ru/content/data_base.htm#19
Объектно-реляционная модель данных (ОРМД) реализована с помощью реляционных таблиц, но включает объекты, аналогичного понятию объекта в объектно-ориентированном программировании. В ОРМД используются такие объектно-ориентированные компоненты, как пользовательские типы данных, инкапсуляция, полиморфизм, наследование, переопределение методов и т.п.
К сожалению, до настоящего времени разработчики не пришли к единому мнению о том, что должна обеспечивать ОРМД. В 1999 г. был принят стандарт SQL-99, а в 2003 г. вышел второй релиз этого стандарта, получивший название SQL-3, который определяет основные характеристики ОРМД. Но до сих пор объектно-реляционные модели, поддерживаемые различными производителями СУБД, существенно отличаются друг от друга. О перспективах этого направления свидетельствует тот факт, что ведущие фирмы–производители СУБД, в числе которых Oracle, Informix, INGRES и др., расширили возможности своих продуктов до объектно-реляционной СУБД (ОРСУБД).
В большинстве реализаций ОРМД объектами признаются агрегат и таблица (отношение), которая может входить в состав другой таблицы. Методы обработки данных представлены в виде хранимых процедур и триггеров, которые являются процедурными объектами базы данных, и связаны с таблицами. На концептуальном уровне все данные объектно-реляционной БД представлены в виде отношений, и ОРСУБД поддерживают язык SQL.
Объектно-ориентированные базы данных определяют как новое поколение баз данных, основанное на сочетании трех принципов: реляционной модели, стандартов на описание объектов и принципов объектно-ориентированного программирования.
http://www.fnti.kiae.ru/content/data_base.htm#19
Моделирование данных в ООМД базируется на понятии объекта. ООМД обычно применяется в сложных предметных областях, для моделирования которых не хватает функциональности реляционной модели (например, для систем автоматизации проектирования (САПР), издательских систем и т.п.).
При создании объектно-ориентированных СУБД (ООСУБД) используются разные методы, а именно:
встраивание в объектно-ориентированный язык средств, предназначенных для работы с БД;
расширение существующего языка работы с базами данных объектно-ориентированными функциями;
создание объектно-ориентированных библиотек функций для работы с БД;
создание нового языка и новой объектно-ориентированной модели дан-ных
К достоинствам ООМД можно отнести широкие возможности моделирования предметной области, выразительный язык запросов и высокую производительность. Каждый объект в ООМД имеет уникальный идентификатор (OID – object identifier). Обращение по OID происходит существенно быстрее, чем поиск в реляционной таблице.
Среди недостатков ООМД следует отметить отсутствие общепринятой модели, недостаток опыта создания и эксплуатации ООБД, сложность использования и недостаточность средств защиты данных.