- •Введение
- •Глава 1. Проектирование баз данных
- •1.1. История развития баз данных и субд
- •1.2. Введение в субд
- •1.2.1. Основные термины, понятия и определения
- •1.2.2. Классификация субд
- •1) Сетевые, корпоративные, распределенные, клиент-серверные, полнофункциональные, масштабируемые, “большие” субд.
- •2) Локальные, персональные, настольные, файл-серверные, “малые” субд.
- •1.3. Модели данных
- •1.3.1. Типы связей между объектами
- •1.3.2. Формы записи инфологической (концептуальной) модели
- •1.3.3. Уровни представления и независимости данных
- •1.3.4. Порядок взаимодействия пользователя, субд и ос
- •1.3.5. Поддержка целостности базы данных
- •1.3.6. Иерархическая модель
- •1.3.7. Сетевая модель
- •1.3.8. Реляционная модель
- •1.3.8.1. Отношения
- •1.3.8.2. Теоретико-множественные операции с отношениями
- •1.3.8.3. Правила Кодда
- •1.3.8.4. Индексирование таблиц
- •1.3.8.5. Связывание таблиц
- •1.3.9. Постреляционная модель
- •1.3.10. Многомерная модель
- •1.3.11. Объектно‑ориентированная модель
- •1.4. Модели использования баз данных в сети
- •1.4.1. Сеть
- •1.4.2. Модели использования баз данных
- •1.4.2.1. Локальная однопользовательская модель
- •1.4.2.2. Файл-серверная модель
- •1.4.2.3. Клиент-серверная модель
- •В моделях «клиент–сервер»
- •1.4.2.4. Модель удаленного доступа (rda)
- •1.4.2.5. Модель сервера данных
- •1.4.2.6. Трехзвенная распределенная модель
- •1.4.2.7. Модели серверов баз данных
- •1.4.2.8. Клиент-Интернет
- •1.4.2.9. ИнтерфейсOdbc
- •1.4.3. Мониторы обработки транзакций (tpm)
- •1.4.4. Децентрализованное управление базами данных
- •1.4.5. Таблицы в локальных сетях
- •1.5. Проектирование баз данных
- •1.5.1. Принципы и этапы проектирования и создания баз данных
- •1.4.Определение доменов атрибутов.
- •1.5. Определение первичных и вторичных ключей.
- •1.6. Определение суперклассов и подклассов для типов сущностей.
- •1.7. Создание er‑диаграмм для отдельных пользователей.
- •2.6. Создание er‑диаграмм для отдельных пользователей.
- •3.4. Создание er‑диаграммы глобальной логической модели.
- •4. Создание глобальной логической модели в среде целевой субд.
- •6. Разработка механизма защиты.
- •1.5.3. Правила формирования взаимосвязанных таблиц
- •1.5.4. Модели жизненного цикла и проектирование баз данных
- •1.5.4.1. Модели жизненного цикла
- •1.5.4.2. Обследование, системный анализ и постановка задачи
- •1.5.4.3. Инфологическое проектирование
- •1.5.4.4. Датологическое проектирование
- •1.5.4.5. Проектирование физической модели
- •1.5.4.6. Реализация, интеграция и внедрение
- •1.5.5. Выбор субд
- •1.5.5.1. Сравнение Visual FoxPro, Access, sql Server, Oracle и Excel
- •1.5.5.2. Методика балловой оценки программных средств
- •1.5.6. Case‑средства автоматизации проектирования
- •1. Ориентация на этапы жизненного цикла
- •2. Функциональная полнота
- •Пользователя в ms sql Server 7.0
- •1.6.2. Резервирование информации
- •1.6.3. Варианты разработки приложений
- •1.7. Стандартизация баз данных
- •1.8. ЯзыкSql
- •1.8.1. Введение вSql
- •1.8.2. Типы данныхSql
- •1.8.3. Оператор выбора данныхSelect
- •1.8.3.1. Назначение и синтаксис оператора
- •1.8.3.2. Объединение таблиц
- •1.8.3.3. Вложенные и коррелированные запросы
- •1.8.3.4. Запросы, использующиеExist, any, all
- •1.8.3.5. Стандартные функции
- •1.8.3.6. Запрос с группировкой
- •1.8.4. Операторы обновления базы
- •1.8.4.1. Оператор корректировки данныхUpdate
- •1.8.4.2. Оператор удаления записейDelete
- •1.8.4.3. Оператор включения записей insert
- •1.8.5. Представления
- •1.9. Транзакции
- •1.9.1. Определение транзакций
- •1.9.2. Организация транзакций
- •1.9.3. Журнал транзакций
- •1.9.4. Журнализация и буферизация
- •1.9.5. Индивидуальный откат транзакций
- •1.9.6. Восстановление после мягкого сбоя
- •1.9.7. Физическая согласованность базы данных
- •1.9.8. Восстановление после жесткого сбоя
- •1.9.9. Параллельное выполнение транзакций
- •1.9.10. Уровни изолированности пользователей
- •1.9.11. Гранулированные синхронизационные захваты
- •1.9.12. Предикатные синхронизационные захваты
- •1.9.13. Метод временных меток
- •1.10. ВстроенныйSql
- •1.10.1. Особенности встроенногоSql
- •1.10.2. Определение курсора
- •1.10.3. Открытие курсора
- •1.10.4. Чтение очередной строки курсора
- •1.10.5. Закрытие курсора
- •1.10.6. Удаление и обновление данных
- •1.10.7. Хранимые процедуры
- •Хранимой процедуры на сервере
- •1.10.8. Триггеры
- •1.10.9. ДинамическийSql
- •1.11. Архитектура субд и оптимизация запросов
- •1.12. Перспективы развития субд
- •Вопросы для самопроверки и контроля
- •1Оглавление
1.3.8.5. Связывание таблиц
Таблицы обычно связываются попарно через ключи связи (п. 1.3.1). Ключи связи должны быть одинакового типа в родительской и дочерней таблицах. Связи бывают постоянные и временные. Постоянные связи устанавливаются до выполнения прикладной программы при создании логической модели данных (обычно визуальными средствами). Этими связями можно пользоваться в прикладной программе. Временные связи устанавливаются при выполнении прикладной программы (в FoxPro командой Set Relation, в языке SQL– в фразахJOINиWHEREоператораSELECT) и удаляются после ее выполнения. Использование связанных таблиц существенно упрощает пользователю обработку таблиц (так, перемещаясь по родительской таблице, происходит автоматическое перемещение по ее дочерним таблицам по условию равенства ключей связи), автоматически обеспечивая контроль целостности (п. 1.3.5). Дочерняя таблица должна иметь индекс по ключу связи.
1.3.9. Постреляционная модель
Во многом нормализация отношений нарушает естественные иерархические связи между объектами, которые достаточно распространены в нашем мире. Возможность сохранять их на концептуальном (но не па физическом) уровне позволяет пользователям более естественно отражать семантику предметной области. В настоящий момент уже существует теоретическое обоснование работы с ненормализованными отношениями и практические реализации подобных систем.
Постреляционная модель ‑ это реляционная модель, допускающая многозначные поля (атрибуты), т.е. само поле может быть таблицей.
Пример. Имеется реляционная база из двух таблиц:
НАКЛАДНЫЕ (номер накладной, дата поставки, код поставщика).
ТОВАРЫ (номер накладной,код товара, количество, единица измерения).
Ее можно перевести в постреляционную базу из одной таблицы:
НАКЛАДНЫЕ‑ТОВАРЫ (номер накладной, дата поставки, код поставщика, товары в накладной).
Поле “Товары в накладной” является таблицей “ТОВАРЫ”.
Достоинство: уменьшение числа таблиц в базе, что повышает наглядность представления данных, не требует операции соединения двух таблиц при выполнении программы, повышает эффективность хранения и обработки данных.Недостатки:проблема обеспечения целостности и непротиворечивости данных (используются не нормализованные таблицы).
Примеры СУБД: uniVers, Bubba, Dasdb.
1.3.10. Многомерная модель
Информация, накопленная в базах данных, является чрезвычайно ценным материалом, и в настоящий момент широко распространяются методы обработки баз данных с точки зрения извлечения из них дополнительных знаний, методов, которые связаны с обобщением и различными дополнительными способами обработки данных (содержание данного пункта скопировано из работы [19]). Базы данных в данной концепции выступают как хранилища информации, это направление называется «Хранилища данных» (Data Warehouse).
Для работы с «Хранилищами данных» наиболее значимым становится так называемый интеллектуальный анализ данных (ИАД), или data mining. На рынке программных продуктов стали появляться соответствующие инструментальные средства. Особенно широко методы ИАД применяются в бизнес-приложениях аналитиками и руководителями компаний. Для этих категорий пользователей разрабатываются инструментальные средства высокого уровня, позволяющие решать достаточно сложные практические задачи без специальной математической подготовки.
В бизнес-приложениях наибольший интерес представляет интеграция методов интеллектуального анализа данных с технологией оперативной аналитической обработки данных (On-Line Analytical Processing, OLAP). OLAP использует многомерное представление агрегированных данных для быстрого доступа к важной информации и дальнейшего ее анализа.
Системы OLAP обеспечивают аналитикам и руководителям быстрый последовательный интерактивный доступ к внутренней структуре данных и возможность преобразования исходных данных с тем, чтобы они позволяли отразить структуру системы нужным для пользователя способом. OLAP-системы позволяют просматривать данные и выявлять имеющиеся в них закономерности либо визуально, либо простейшими методами (такими как линейная регрессия), а включение в их арсенал нейросетевых методов обеспечивает существенное расширение аналитических возможностей.
В основе концепции оперативной аналитической обработки (OLAP) лежит многомерное представление данных. Термин OLAP ввел Кодд (Е. F. Codd) в 1993 году.
Одновременный анализ по нескольким измерениям данных определяется как многомерный анализ. Каждое измерение включает направления интеграции данных, состоящие из серии последовательных уровней обобщения, где каждый вышестоящий уровень соответствует большей степени агрегации данных по соответствующему измерению. Так, измерение Исполнительможет определяться направлением консолидации, состоящим из уровней обобщения «предприятие–подразделение–отдел-служащий». Измерение Время может даже включать два направления консолидации – «год–квартал–месяц–день» и «неделя–день», поскольку счет времени по месяцам и по неделям несовместим. В этом случае становится возможным произвольный выбор желаемого уровня детализации информации по каждому из измерений. Операция спуска (drilling down) соответствует движению от высших ступеней консолидации к низшим; напротив, операция подъема (rolling up) означает движение от низших уровней к высшим.
Многомерная модель ‑ узкоспециализированная модель, предназначенная для хранения данных в виде многомерного массива (гиперкуба), используемых системами оперативной аналитической обработки типа OLAP или систем поддержки принятия решений DSS(DecisionSupport.System, примерMSDSS).
Пример. Объем продаж автомобилей по маркам автомобилей, годам и городам можно представить в виде трехмерной модели (куба со сторонами: марки автомобилей, годы, города и с ячейками ‑ количество проданных автомобилей) вместо реляционной (таблицы с полями: марка автомобиля, год продажи, город и количество проданных автомобилей). Куб более нагляден, чем таблица, и с ним удобнее и быстрее работать.
Рассмотрим ряд терминов этой модели.
Агрегируемость данныхозначает наличие различных уровней обобщения информации (аналитик, пользователь, руководители различных рангов).
Историчность данныхподразумевает привязку данных ко времени (наличие временных рядов).
Прогнозируемость данныхпредполагает их использование в процедурах прогнозирования на различные временные периоды.
Срез (Slice)‑ подмножество гиперкуба, полученное в результате фиксации одного или нескольких измерений.
Пример.Если ограничить значения измерения “Марка автомобиля” маркой “ВАЗ 2105”, то получим двухмерную таблицу продажи автомобилей этой марки по городам и годам.
Вращение (Rotate)‑ вращение гиперкуба (местоположение отдельных осей меняются местами).
Агрегация/детализация (Drill Up/Down)‑ переход к более общему/детальному представлению информации пользователю из гиперкуба.
Пример.Можно сформировать итоговую таблицу продаж автомобилей (независимо от их марок) по городам и годам.
Достоинства:удобство и эффективность аналитической обработки больших объемов данных.Недостаток:громоздкость и не эффективность для простой оперативной обработки небольших объемов данных.
Примеры СУБД: Essbase (Arbor Software), Media Multi‑matrix и Media/MR (Speedware), Oracle Express Server (Oracle), Cache.