- •Глава 1 введение в банки данных 12
- •Глава 2 концептуальное проектирование 72
- •Глава 3 даталогическое проектирование 183
- •Глава 4 целостность базы данных 233
- •Глава 5 создание и ведение баз данных 251
- •Глава 6 язык запросов qbe 294
- •Глава 7 язык sql 347
- •Глава 8 создание экранных форм и страниц доступа 400
- •Глава 9 создание отчетов 441
- •Глава 10 распределенные банки данных 474
- •Предисловие
- •Глава 1 введение в банки данных
- •1.1. Понятие банка данных
- •1.2. Компоненты банка данных
- •1.2.1. Информационный компонент
- •1.2.2. Программные средства БнД
- •1.2.3. Языковые средства БнД
- •1.2.4. Технические средства БнД
- •1.2.5. Организационно-методические средства
- •1.2.6. Администраторы банка данных
- •1.2.7. Взаимодействие компонентов БнД
- •1.3. Классификация банков данных
- •1.3.1. Классификация баз данных
- •1.3.2. Классификации субд
- •1.3.3. Классификационные группировки, относящиеся к БнД в целом
- •1.4. Выбор субд
- •1.4.1. Тенденции развития субд
- •1.4.2. Общая характеристика проблемы выбора субд
- •1.4.3. Факторы влияния на выбор субд
- •1.4.4. Выбор субд
- •1.5. Уровни моделей и этапы проектирования бд
- •1.5.1. Уровни моделей
- •1.5.2. Взаимосвязь этапов проектирования бд
- •1.5.3. Факторы влияния на проектирование бд
- •На это следует обратить внимание
- •Контрольные вопросы
- •Глава 2 концептуальное проектирование
- •2.1. Общие сведения о моделировании предметной области
- •2.1.1. Уточнение понятия концептуальной модели
- •2.1.2. Основные компоненты концептуальной модели
- •2.1.3. Требования, предъявляемые к концептуальной модели
- •2.1.4. Преимущества использования er-моделирования
- •2.2. Описание базовой er-модели
- •2.2.1. Понятия «объект» и «класс объектов»
- •2.2.2. Разновидности объектов
- •2.2.3. Изображение простого объекта
- •2.2.4. Описание свойств объекта. Разновидности свойств
- •2.2.5. Алгоритмические зависимости
- •2.2.6. Интегральные характеристики класса объектов
- •2.2.7. Связи между объектами
- •2.2.8. Сложные объекты
- •2.2.9. Рекомендации по построению базовой er-модели
- •2.3. Сравнение методик построения er-моделей
- •2.3.1. Несущественные различия в использовании условных обозначений
- •2.3.2. Различия в использовании и изобразительных средств, приводящие к изменениям в методике построения модели
- •2.3.3. Пространственное размещение элементов er-модели
- •2.3.4. Отсутствующие возможности
- •2.3.5. Различия в классификации объектов и отношений между ними
- •2.3.6. Терминологические различия
- •2.3.7. Соглашения по именованию элементов er-модели
- •2.3.8. Дополнительные характеристики case-средств
- •2.3.9. Использование графических пп для изображения er-моделей
- •2.4. Особенности методологии построения er-моделей
- •2.5. Использование Design/idef для проектирования баз данных
- •2.5.1. Построение er-модели при использовании Design/idef Общая характеристика
- •Описание сущности
- •Описание связи
- •Описание обобщенного объекта
- •2.5.2. Методология построения er-модели при использовании Design/idef
- •2.6. Особенности моделирования в erWin
- •2.6.2. Построение логической модели Создание новой сущности
- •Описание свойств сущности
- •Дополнительные свойства атрибутов
- •Описание обобщенных объектов
- •Задание связей между сущностями
- •2.6.3. Особенности методологии моделирования
- •На это следует обратить внимание
- •Контрольные вопросы
- •Глава 3 даталогическое проектирование
- •3.1. Общие сведения о даталогическом проектировании
- •3.1.1. Исходные данные для даталогического проектирования
- •3.1.2. Результат даталогического проектирования
- •3.1.3. Подход к даталогическому проектированию
- •3.1.4. Определение состава базы данных
- •3.1.5. Введение искусственных идентификаторов
- •3.1.6. Критерии оценки бд
- •3.2. Особенности даталогических моделей
- •3.2.1. Внутризаписная структура
- •3.2.2. Межзаписная структура
- •3.3. Проектирование логической структуры реляционной базы данных
- •3.3.1. Вводные положения
- •3.3.2. Алгоритм перехода от базовой er-модели к схеме реляционной базы данных
- •Отображение простых объектов
- •Отображение связи между объектами
- •Отображение сложных объектов
- •Использование дополнительных характеристик концептуальной модели
- •Дополнительные рекомендации по проектированию бд
- •3.4. Создание физической модели в erWin
- •3.4.1. Выбор целевой субд
- •3.4.2. Нотации, используемые при построении физической модели
- •3.4.3. Уровни просмотра физической модели
- •3.4.4. Сравнение логической и физической моделей
- •3.4.5. Создание хранилищ данных
- •3.4.6. Переход к даталогической модели
- •На это следует обратить внимание
- •Контрольные вопросы
- •Глава 4 целостность базы данных
- •4.1. Классификация ограничений целостности
- •4.2. Er-модели и ограничения целостности
- •4.3. Задание ограничений целостности в erWin
- •4.3.1. Обязательный атрибут
- •4.3.2. Ограничения целостности связи
- •4.3.3. Триггер ссылочной целостности
- •На это следует обратить внимание
- •Контрольные вопросы
- •Глава 5 создание и ведение баз данных
- •5.1. Описание структуры баз данных. Общие сведения
- •5.2. Создание бд в Microsoft Access
- •5.2.1. Создание новой таблицы путем описания ее структуры
- •Описание полей таблицы
- •Определение ключа таблицы
- •Свойства полей
- •Сохранение описания таблицы
- •Создание таблиц для контрольного примера
- •5.2.2. Изменение структуры таблиц
- •5.2.3. Другие способы создания таблиц
- •5.2.4. Связывание таблиц
- •5.2.5. Просмотр связанных таблиц
- •5.2.6. Задание ограничений целостности в Access
- •Ограничения, относящиеся к полю
- •Ограничения, относящиеся к записи
- •Целостность связи
- •5.3. Организация ввода и корректировки данных в бд
- •5.3.1. Общие сведения
- •5.3.2. Возможности ввода данных в Access
- •На это следует обратить внимание
- •Контрольные вопросы
- •Глава 6 язык запросов qbe
- •6.1. Общая характеристика языка qbe
- •6.2. Реализация ове в Access
- •6.2.1. Общие сведения
- •Добавление таблиц в запросе
- •Удаление таблицы из запроса
- •6.2.4. Включение полей в запрос
- •6.2.5. Поля, выводимые в ответ
- •6.2.6. Управление выводом повторяющихся строк
- •6.2.7. Простые запросы
- •6.2.8. Сложные запросы
- •6.2.9. Просмотр ответа
- •6.2.10. Определение числа записей, выводимых в ответ
- •6.2.11. Формирование запросов к связанным таблицам
- •6.2.12. Выполнение агрегирующих операторов
- •6.2.13. Вычисляемые поля
- •6.2.14. Перекрестные запросы
- •6.2.15. Создание запроса с параметрами
- •6.2.16. Корректирующие запросы
- •6.2.17. Запрос на создание таблицы
- •6.2.18. Специальные запросы
- •6.2.19. Режим сводной таблицы и сводной диаграммы
- •На это следует обратить внимание
- •Контрольные вопросы
- •Глава 7 язык sql
- •7.1. Общая характеристика sql
- •7.2. Описание базы данных
- •7.2.1. Описание таблиц
- •7.2.2. Ограничения целостности
- •7.3. Запросы на выборку
- •7.4. Возможности корректировки хранимых данных
- •7.5. Создание представлений (view)
- •7.6. Создание и использование курсоров
- •Управление транзакциями
- •7.8. Стандартный sql-92
- •7.8.1. Создание объектов Виды объектов
- •Определение таблицы
- •Определение домена
- •7.8.2. Запросы Оператор select
- •Запросы, затрагивающие несколько таблиц
- •Корректирующие операторы
- •7.8.3. Создание представлений (view) Оператор create view
- •Цели использования представлений
- •Ограничения при использовании представлений
- •Создание представлений с использованием erWin
- •7.8.4. Курсоры
- •7.9. Ms Jet Access sql
- •7.9.1. Оператор select Общая характеристика оператора
- •Предложение select
- •Предложение from
- •Предложение where
- •Предложение group by
- •Предложение having
- •Предложение order by
- •7.9.2. Подчиненные запросы sql
- •7.9.3. Корректирующие операторы Добавление
- •Обновление
- •Удаление записей
- •7.9.4. Запрос к серверу
- •На это следует обратить внимание
- •Контрольные вопросы
- •Глава 8 создание экранных форм и страниц доступа
- •8.1. Понятие, классификация и роль экранных форм
- •8.2. Рекомендации по созданию форм
- •8.3. Создание экранных форм в субд Access
- •8.3.1. Выбор способа создания формы
- •8.3.2. Создание форм с помощью Мастера Создание простой связанной формы с помощью Мастера
- •Создание многотабличной формы с помощью Мастера
- •8.3.3. Корректировка формы в режиме Конструктор
- •Изменения, связанные с уже включенными в форму элементами управления
- •Включение новых элементов в форму
- •Изменение типа элемента управления
- •Создание форм, состоящих из нескольких страниц
- •Последовательность обхода полей
- •Свойства формы
- •Задание ограничений целостности при создании форм
- •Добавление кнопок в форму
- •8.3.4. Кнопочная форма
- •8.3.5. Возможные случаи возникновения ошибок
- •8.3.6. Открытие формы в режиме сводной таблицы или в режиме диаграммы
- •8.3.7. Создание страниц доступа
- •На это следует обратить внимание
- •Контрольные вопросы
- •Глава 9 создание отчетов
- •9.1. Общая характеристика отчетов
- •9.2. Создание отчетов в системе Access
- •9.2.1. Выбор способа создания отчета
- •9.2.2. Создание отчетов с использованием Мастера отчетов
- •9.2.3. Корректировка отчета в режиме Конструктор Переход в режим Конструктор
- •Корректировка отчета
- •Вычисления в отчете
- •Ввод нового поля в отчет
- •Группировка
- •Использование графических элементов
- •Задание номеров страниц
- •9.2.4. Создание отчета, базирующегося на нескольких таблицах
- •9.2.5. Создание сложных отчетов
- •9.2.6. Свойства
- •9.2.7. Создание отчета анкетной формы
- •9.2.8. Совместная работа с другими приложениями ms Office
- •На это следует обратить внимание
- •Контрольные вопросы
- •Глава 10 распределенные банки данных
- •10.1. Основные понятия
- •10.2. Классификация рБнД
- •10.3. Транзакции
- •10.3.1. Понятие транзакции
- •10.3.2. Плоские транзакции
- •10.3.3. Контрольные точки
- •10.3.4. Многозвенные транзакции
- •10.3.5. Вложенные транзакции
- •10.4. Проблемы параллелизма и пути их решения
- •10.4.1. Параллелизм
- •10.4.2. Блокировки
- •10.4.3. Режимы доступа к информации
- •10.4.4. Уровни изоляции в sql
- •10.4.5. Использование хранимых процедур и триггеров для контроля целостности бд
- •10.5. Тиражирование данных
- •10.5.1. Основные понятия
- •10.5.2. Преимущества и недостатки тиражирования
- •10.5.3. Виды тиражирования
- •10.6. Обеспечение целостности и безопасности данных в рбд
- •10.6.1. Особенности обеспечения целостности в рбд
- •10.6.2. Средства защиты данных Способы защиты данных
- •Создание и удаление пользователей
- •Определение и отмена привилегий
- •10.7. Работа в распределенной среде при использовании субд Access
- •10.7.1. Способы совместного использования данных в Access
- •10.7.2. Виды блокировок
- •10.7.3. Проекты Microsoft Access
- •10.7.4. Средства защиты Microsoft Access Управление правами доступа пользователей
- •Средства защиты бд
- •На это следует обратить внимание
- •Контрольные вопросы
- •Приложения
- •1. Основные понятия реляционной модели данных
- •1. Информационные единицы.
- •2. Ключи.
- •3. Связи.
- •2. Сквозной пример использования er-моделирования для проектирования бд
- •Глоссарий
- •Литература
- •Сокращения
2.3.3. Пространственное размещение элементов er-модели
ER-модель даже для небольшой и несложной предметной области включает в себя описание значительного числа компонентов и связей между ними. При этом встает проблема наглядности общей схемы. Эта проблема по-разному решается при ручном и автоматизированном построении инфологической модели. В автоматизированных системах чаще всего строится единое изображение ER-модели и используется прием масштабирования, когда, уменьшая или увеличивая масштаб изображения на экране, можно посмотреть как всю схему, так и отдельный ее фрагмент.
Многие CASE-средства позволяют выделять фрагменты из общей схемы и работать с ними как с самостоятельными компонентами модели, а также проводить объединение отдельных фрагментов в единую схему.
Различные приемы используются и для того, чтобы уменьшить число пересечений линий на схеме. Так, в системе ProKit*WORKBENCH для этих целей допускается дублирование изображения объекта и размещение дубля рядом с тем объектом, с которым его надо связать. Чтобы показать, что это не новый объект, а дубликат уже изображенного в модели объекта, используется какое-либо условное обозначение, например у соответствующих блоков, отражающих дубликат, отчеркивается уголок.
При ручном проектировании изобразить всю ER-модель в виде единой схемы обычно не представляется возможным. В этом случае можно порекомендовать следующий прием: изобразить и описать каждый объект самостоятельно, присвоить каждому объекту короткий код. Используя эти кодовые обозначения, для каждого объекта указать его связи с другими объектами в виде отдельных схем. При этом нужно не упускать из виду, что, несмотря на такую дефрагментацию при изображении, модель является единой и связанной.
Многие CASE-системы позволяют выводить на экран информацию с разной степенью детализации (например, только названия сущностей, либо сущности и все их свойства, либо только ключевые атрибуты и т.п.). Такие возможности совсем не присущи ручным способам проектирования (хотя могут использоваться как методологический прием: проектирование сначала выполняется с минимальной степенью детализации, а затем проводится последовательное повышение степени детализации - обычный прием в структурном проектировании).
2.3.4. Отсутствующие возможности
Некоторые возможности, имеющиеся в одних системах или методиках, отсутствуют в других. В этих случаях возможны различные варианты:
для изображения ситуации, имеющей место в предметной области, используются возможности, предоставляемые данной методологией, но это требует применения определенных приемов, часто несколько искусственных, для их представления;
ситуация просто не отображается в модели.
Например, во многих системах инфологического моделирования предполагается, что свойства у объекта могут быть только единичными., В этом случае каждое множественное свойство следует представлять как самостоятельный объект и изображать связь между этим вновь введенным объектом и исходным объектом.
Так, в IDEF1X, как и в других широко известных CASE-системах, свойства объекта могут быть только единичные и всегда определенные (не условные). Если свойство может отсутствовать у каких-либо объектов, то надо выделять отдельные сущности, например СЛУЖАЩИЙ_ШТАТНЫЙ с атрибутом «Оклад» и ПОЧАСОВИК, не имеющий такого атрибута. Это приведет к необходимости выделения большого числа объектов и связей в ИЛМ, к снижению наглядности модели. Например, отдельные экземпляры объекта ЛИЧНОСТЬ могут иметь или не иметь ученое звание, ученую степень, год окончания вуза и много других признаков. По каждому из этих признаков придется выделять подклассы (либо не фиксировать в модели, являются ли эти свойства условными).
Некоторые методики не вводят агрегированный объект как самостоятельную категорию. В таком случае сущность, соответствующая агрегированному объекту, изображается как простой объект; при этом пользователь должен предварительно определить идентификатор этого объекта (что является далеко не тривиальной задачей) и его свойства. Далее изображение будет зависеть от того, могут ли в используемой нотации быть изображены только бинарные связи либо с объектом можно связать несколько разных объектов.
Кроме указанных сложностей при определении идентификатора агрегированной сущности могут возникнуть и проблемы при переходе от ИЛМ к даталогической модели.
Если модель допускает изображение только двоичных (бинарных) связей, то проектировщик должен преобразовать n-арную связь в совокупность бинарных.
Связь типа «арк», использованная в базовой модели и имеющаяся в CASE Oracle, отсутствует в большинстве других рассматриваемых в данном учебнике систем. Это делает неудобным отображение тех ситуаций, где следовало бы использовать эту возможность (чаще всего при этом приходится вводить лишнюю сущность).
Если методика построения модели не предполагает фиксацию класса принадлежности объекта в связи, то эта информация будет просто потеряна.
Ни в одной из известных нам систем моделирования нет понятия составное свойство. Поэтому при моделировании предметной области проектировщик должен либо каждый из составляющих элементов составного свойства изобразить как отдельные самостоятельные свойства, либо изобразить это свойство без разделения на составляющие. И в том, и в другом случае часть информации о ПО будет утеряна: в первом случае мы не увидим, что элементы составного свойства являются логически единым целым, а во втором - не увидим его состава.
В некоторых CASE-системах имеет место ситуация, когда какая-то конструкция допускается в системе как промежуточная. Например, в IDEF1X и CASE Oracle связь М:М допускается как так называемое неспецифическое отношение. Его наличие разрешается на ранних стадиях разработки проекта, но в дальнейшем оно должно быть заменено на специфическое отношение (т.е. отношение типа 1:М). Это достигается посредством введения в модель дополнительной третьей сущности и соединения с ней исходных сущностей связью типа 1:М (другими словами, одна связь М:М заменяется на две 1:М). Это является недостатком подобных систем, так как, во-первых, не все целевые СУБД требуют такого преобразования (некоторые системы поддерживают отношение М:М в явном виде) и, во-вторых, если такое преобразование все-таки потребуется, система автоматизации проектирования вполне могла бы выполнить его автоматически на этапе даталогического проектирования. Даже если выполняется ручное проектирование, то указанное преобразование должно выполняться проектировщиком на стадии даталогического проектирования, а не при описании предметной области. Кроме того, при рассматриваемом преобразовании на стадии инфологического проектирования в IDEF вводится новая категория сущностей - сущности пересечения, или ассоциативные сущности. Введение новых сущностей влечет за собой введение в ER-модель и дополнительных связей. Все это вместе взятое усложняет и без того нелегкую задачу инфологического проектирования.
В предметной области могут быть сущности, идентификаторы которых являются зависимыми от идентификатора какого-то другого объекта. Например, если участки на предприятии нумеруются в пределах цеха, то идентификатор участка будет составным, включающим в себя код цеха и код участка. В инфологической модели можно ограничиться указанием этого составного идентификатора. Некоторые методики построения ER-моделей (например, IDEF1X, ProKit*WORKBENCH) предусматривают введение особых видов сущностей и особых видов отношений для отображения подобных ситуаций. Так, в IDEF1X сущность, для идентификации которой надо рассматривать ее отношение с другими сущностями, называется зависимой от идентификатора сущностью, и для ее изображения используется блок с закругленными углами (в отличие от сущности, не зависимой от идентификации, для обозначения которой используются прямоугольники). Для связи объектов, один из которых нужен для полной идентификации другого, вводится понятие идентифицирующего отношения. Дня него также вводится свое условное обозначение. В IDEF1X для идентифицирующего отношения используется сплошная линия, а для неидентифицирующего - пунктирная.
Способ идентификации отражает не особенности предметной области, а языковые характеристики, а именно - способ именования объектов. Но лингвистические отношения тоже являются частью ИЛМ, и они могут быть отражены в ER-модели.
Если модель не использует в явном виде указание на способ идентификации объекта, то, как указывалось выше, эту ситуацию нужно отразить просто путем соответствующего использования идентификаторов. Так, например, если на предприятии участки нумеруются в пределах цеха, то в качестве идентификатора объекта ЦЕХ следует использовать «Код_цеха*Код_участка» (рис. 2.34). Следует обратить внимание на то, что прямоугольник, соответствующий зависимой по идентификации сущности, в этом случае на сектора не делится.
Рис. 2.34. Изображение зависимой по идентификации сущности
в случае отсутствия специальных обозначений
Как отмечалось выше, ИЛМ включает в свой состав много разнообразных компонентов. Методологии моделирования и конкретные системы различаются полнотой и широтой охвата характеристик, отражаемых при описании предметной области. Так, некоторые системы предусматривают описание запросов (в частности, ключей поиска), количественных характеристик классов объектов и запросов, ограничений целостности и т.д., другие - нет. Указанные описания иногда бывают объединены с ER-моделью (например, в ProKit*WORKBENCH) или оформляются как отдельные самостоятельные компоненты.