- •Базы данных: основные понятия
- •Индексирование
- •Введение. Для чего нужны базы данных.
- •Компоненты субд
- •1.1.2.Обобщенные структуры или модели данных.
- •1.2.Методы доступа к данным.
- •1.2.1.Методы поиска по дереву.
- •1.2.2.Хеширование.
- •2.1.Представление данных с помощью модели "сущность-связь".
- •2.1.1.Назначение модели.
- •2.1.2.Элементы модели.
- •2.2.Диаграмма "сущность-связь".
- •Выделим интересующие нас сущности и связи:
- •Обобщая все проведенные выше рассуждения, получим диаграму "сущность-связь", показанную на слудющем рисунке.
- •2.3.Целостность данных.
- •2.4.Обзор нотаций, используемых при построении диаграмм "сущность-связь"
- •2.4.1.Нотация Чена.
- •2.4.2.Нотация Мартина
- •2.4.3.Нотация idef1x.
- •2.4.4.Нотация Баркера.
- •3.1.Иерархическая модель данных.
- •3.1.1.Структура данных.
- •3.1.2.Операции над данными, определенные в иерархической модели:
- •3.1.3.Ограничения целостности.
- •3.2.Сетевая модель данных
- •3.2.1.Структура данных.
- •3.2.2.Операции над данными.
- •3.2.3.Ограничения целостности.
- •4.1.Реляционная модель данных
- •4.1.1.Структура данных.
- •4.1.2.Свойства отношений.
- •4.2.Теория нормальных форм.
- •4.2.1.Функциональные зависимости.
- •4.2.2. 1Nf - первая нормальная форма.
- •4.2.3. 2Nf - вторая нормальная форма.
- •4.2.4. 3Nf - третья нормальная форма.
- •4.2.5. Bcnf - нормальная форма Бойса-Кодда.
- •4.2.6. Многозначные зависимости и четвертая нормальная форма (4nf).
- •4.2.7. Зависимости по соединению и пятая нормальная форма (5nf).
- •4.3.Ограничения целостности
- •4.3.1.Целостность сущностей.
- •4.3.2.Целостность ссылок
- •4.4.Операции над данными (реляционная алгебра).
- •4.4.0.Система управления базами данных leap
- •4.4.1.Операции обработки кортежей.
- •4.4.2.Операции обработки отношений.
- •4.5.Реляционное исчисление.
- •4.6.Язык sql
- •4.6.1.Типы данных sql.
- •4.6.2.Ddl: Операторы создания схемы базы данных.
- •Операторы базы данных
- •Создание и удаление таблиц
- •4.6.3.Ddl: Операторы создания индексов.
- •4.6.4.Ddl: Операторы управления правами доступа.
- •4.6.5.Dml: Команды модификации данных.
- •Удаление записей
- •4.6.6.Dml: Выборка данных.
- •4.6.7.Dml: Выборка из нескольких таблиц.
- •4.6.8.Dml: Вычисления внутри select.
- •4.6.9.Dml: Групировка данных.
- •4.6.10.Dml: Cортировка данных.
- •4.6.11.Dml: Операция объединения.
- •4.6.12.Использование представлений.
- •4.6.13.Другие возможности sql.
- •4.7.Вопросы практического програмирования.
- •4.7.1.Использование специализированных библиотек и встраиваемого sql.
- •4.7.2.Cli - интерфейс уровня вызовов.
- •4.7.3.Odbc - открытый интерфейс к базам данных на платформе ms wIndows.
- •4.7.4.Jdbc - мобильный интерфейс к базам данных на платформе Java.
- •4.8.Навигационный подход к манипулированию данными и персональные субд.
- •4.9.Транзакции, блокировки и многопользовательский доступ к данным.
- •4.10.Как определить степень соответствия субд реляционной модели.
- •5.1.Этапы проектирования данных
- •5.2.Инструментальные средства проектирования информационных систем.
- •5.3.Методологии функционального моделирования.
- •5.3.1.Диаграммы потоков данных. Нотация Йордона - Де Марко
- •5.3.2.Другие нотации, используемые при построении диаграмм потоков данных.
- •5.3.3.Методология sadt (idef0).
- •5.3.4.Сравнительный анализ методологий функционального моделирования.
- •5.4.Концептуальное моделирование. Пример построения модели "сущность-связь"
- •5.5.Правила порождения реляционных отношений из модели "сущность-связь"
- •5.5.1.Бинарные связи
- •5.5.2.N - арные связи.
- •5.5.3.Иерархические связи.
- •5.6.Проектирование реляционной базы данных на основе декомпозиции универсального отношения.
- •5.7.Обзор некоторых case-систем.
- •5.7.1.Power Designer компании Sybase.
- •5.7.2.Silverrun компании Silverrun Technologies Ltd.
- •5.7.3.BpWin и erWin компании LogicWorks.
- •5.7.4.Designer/2000 компании Oracle.
- •6.1.Ограничения реляционных баз данных.
- •6.2.Постреляционные субд.
- •6.3.Объектно-ориентированные субд.
- •6.3.1.Объектно-ориентированная парадигма.
- •6.3.2.Объектно-ориентированные субд.
- •6.3.3.Стандарт odmg.
- •6.3.4.Объектные расширения реляционных субд. Язык sql-3.
- •6.4.Объектно-реляционные субд.
- •6.5.Нечисловая обработка и ассоциативные процессоры.
- •7.1.Архитектура "клиент-сервер".
- •7.1.1.Основные понятия.
- •7.1.2.Модели взаимодействия клиент-сервер.
- •7.1.3.Мониторы транзакций.
- •Основные понятия субд
4.10.Как определить степень соответствия субд реляционной модели.
Заврешая обсуждение моделей данных подведем некоторые итоги. Преимущества реляционного подхода достаточно очевидны:
Предсказуемость результатов работы с данными. В основе реляционной модели лежит математическая модель, следовательно, любой запрос к базе данных, составленный на корректном языке влечет ответ, однозначно определяемый схемой БД и конкретными данными. При этом пользователю не требуется информация о физической организации данных.
Предметная область часто достаточно естественно описывается в терминах таблиц (к сожалению, в реляционной модели имеются проблемы с представлением иерархических структур, подробнее см. раздел 5.5.3.
По этим причинам идея создания реляционной СУБД стала популярна среди разработчиков вскоре после ее появления. Сейчас существует множество коммерческих и некоммерческих систем, создатели которых заявляют об их "реляционности". Для того, чтобы более определенно сформулировать цель, к которой разработчикам нужно стремится, Е.Кодд в конце 70-х годов опубликовал 12 правил соответствия реляционной модели, которые опираются на основное (подразумеваемое) правило:Система, которая провозглашается поставщиком как реляционная СУБД, должна управлять базами данных исключительно способами, соответствующими реляционной модели.
Конкретные требования к реляционной СУБД раскрываются в следующих правилах (цитируется по статье В.Пржиялковский Модели, базы данных и СУБД в информационных системах):
Информационное правило.Вся информация, хранимая в базе данных, должна быть представлена единственным образом: в виде значений в реляционных таблицах.
Правило гарантированного логического доступа.К каждому имеющемуся в реляционной базе атомарному значению должне быть гарантирован доступ с помощью указания имени таблицы, значения первичного ключа и имени атрибута.
Правило наличия значения (missing information).В полностью реляционной СУБД должны иметься специальные индикаторы (отличные от пустой символьной строки или строки из одних пробелов и отличные от нуля или какого-то другого числового значения) для выражения (на логическом уровне, не зависимо от типа данных) того факта, что значение отсутствует по меньшей мере по двум различным причинам: его действительно нет, либо оно не применимо к данной позиции. СУБД должна не только отражать этот факт, но и распространять на такие индикаторы свои функции манипулирования данными не зависимо от типа данных.
Правило динамического диалогового реляционного какталога.Описание базы данных выглядит логически как обычные данные, так что авторизованные пользователи и прикладные программы могут употреблять для работы с этим описанием тот же реляционный язык, что и при работе с обычными данными.
Правило полноты языка работы с данными.Сколько бы много в СУБД ни поддерживалось языков и режимов работы с данными, должен иметься по крайней мере один язык, выразимый в виде командных строк в некотором удобном синтаксисе, который бы позволял формулировать:
определение данных
определение правил целостности
манипулирование данными (в диалоге и из программы)
определение таблиц-представлений (в том числе и возможности их модификации)
определение правил авторизации
границы транзакций
Правило модификации таблиц-представлений.В СУБД должен существовать корректный алгоритм, позволяющий автоматически для каждой таблицы-представления определять во время ее создания, может ли она использоваться для вставки и удаления строк и какие из столбцов допускают модификацию, и заносящий полученную таким образом информацию в системный каталог.
Правило множественности операций.Возможность оперирования базовыми таблицами или таблицами-представлениями распространяется полностью не только на выдачу информации из БД, но и на вставку, модификацию и удаление данных.
Правило физической независимости.Диалоговые операторы и прикладные программы на логическом уровне не должны страдать от каких-либо изменений во внутреннем хранении данных или методах доступа СУБД
Правило логической независимости.Диалоговые операторы и прикладные программы на логическом уровне не должны страдать от таких изменений в базовых таблицах, которые сохраняют информацию и теоретически допускают неизменность этих операторов и программ.
Правило сохранения целостности.Диалоговые операторы и прикладные программы не должны изменяться при изменении правил целостности в БД, задаваемых языком работы с данными и хранимых в системном каталоге.
Правило независимости от распределенности.Диалоговые операторы и прикладные программы на логическом уровне не должны зависеть от совершаемого физического разнесения данных (если первоначально СУБД работала с нераспределенными данными) или перераспределения (если СУБД распределенная).
Правило ненарушения реляционного языка.Если в реляционной СУБД имеется язык низкого уровня (для работы с отдельными строками), он не должен позволять нарушать или "обходить" правила, сформулированные на языке высокого уровня (множественном) и занесенные в системный каталог.
Перед началом детального обсуждения способов проектирования баз данных необходимо отметить, что любая база данных является составной частью некой информационной системы (ИС), которая подразумевает не только хранение данных, но и их обработку. Поэтому, проектированию данных всегда сопутствует (а чаще предшествует) проектирование алгоритмов их использования. Здесь мы рассмотрим все этапы проектирования информационной системы: от функционального моделирования предметной области, до построения структуры реляционной базы данных.