- •А.И. Костюк
- •Введение
- •1. Данные
- •1.1. Источники данных
- •1.1.1. Предметная область
- •1.1.2. Объект
- •1.1.3. Атрибуты (элементы данных)
- •1.2. Значение данных
- •1.2.1. Ключевой элемент данных
- •1.2.2. Запись данных
- •1.2.3. Файл данных
- •1.3. Недостатки традиционной организации файлов данных
- •1.4. База данных
- •1.4.1. Определение базы данных
- •1.4.2. Система управления базами данных
- •1.4.3. Недостатки интеграции данных
- •1.5. Администратор базы данных
- •1.6. Независимость данных
- •1.6.1. Два уровня независимости данных
- •1.6.2. Способы достижения независимости данных
- •1.7. Словарь данных
- •1.8.Принципы проектирования базы данных и достижения требуемых эксплуатационных характеристик
- •2. Администрирование базы данных
- •2.1. Функция администрирования базы данных
- •2.1.1. Обязанности абд
- •2.1.2. Абд и администрация предприятия
- •2.1.3. Абд и пользователи
- •2.1.4. Абд и разработчики прикладных программ
- •2.1.5. Абд и системная группа
- •2.1.6. Абд и эксплуатационная группа
- •2.1.7. Абд и поставщики программного обеспечения
- •2.1.8. Абд и поставщики аппаратных средств
- •2.2. Жизненный цикл системы с базой данных
- •2.2.1. Проектирование базы данных (этап 1)
- •2.2.2. Материализация базы данных (этап 2)
- •2.2.3. Конвертирование существующих наборов данных и прикладных программ во вновь созданную базу данных (этап 3)
- •2.2.4. Интеграция конвертированных и новых прикладных программ для работы в среде вновь созданной базы данных (этап 4)
- •2.2.5. Эксплуатация (этап 5)
- •2.2.6. Развитие, совершенствование и сопровождение (этап 6)
- •2.3. Абд, группа абд и ее обязанности
- •3. Словарь данных
- •3.1. Что такое словарь данных
- •3.1.1. Назначение
- •3.1.2. Словарь данных и система управления базами данных
- •3.1.3. Интерфейсы
- •3.1.4. Идеальный словарь данных. Требования и организация
- •3.2. Стратегия реализации словаря данных
- •3.2.1. Экономическая целесообразность
- •3.2.2. Условия применения
- •3.2.3. Рекомендации по определению данных
- •4. Модели данных
- •4.1. Что такое модель данных
- •4.2. Взаимосвязи в модели данных
- •4.2.1. Взаимосвязь «один к одному» (между двумя типами объектов)
- •4.2.2. Взаимосвязь «один ко многим» (между двумя типами объектов)
- •4.2.3. Взаимосвязь «многие ко многим» (между двумя типами объектов)
- •4.2.4. Взаимосвязь «один к одному» (между двумя атрибутами)
- •4.2.5. Взаимосвязь «один ко многим» (между двумя атрибутами)
- •4.2.6. Взаимосвязь «многие ко многим» (между двумя атрибутами)
- •4.2.7. Обзор моделей данных
- •4.3. Реляционная модель данных
- •4.3.1. Достоинства модели
- •4.3.2. Недостатки модели
- •4.4. Иерархическая модель данных
- •4.4.1. Иерархическая древовидная структура
- •4.4.2. Включение и удаление данных
- •4.4.3. Достоинства модели
- •4.4.4. Недостатки модели
- •4.5. Сетевая модель данных
- •4.5.1. Представление взаимосвязи «один ко многим»
- •4.5.2. Дополнительные классы наборов
- •4.5.3. Операции включения и удаления в сетевой модели данных
- •4.5.4. Достоинства модели
- •4.5.5. Недостатки модели
- •5. Проектирование концептуальной модели данных
- •5.1. Анализ данных
- •5.1.1. Сбор информации о данных, используемых в существующих прикладных программах
- •5.1.2. Сбор информации о данных для перспективных приложений
- •5.2. Нормализация отношений
- •5.3. Графическое представление
- •6. Проектирование логической модели данных
- •6.1. Отображение на реляционную модель данных
- •6.2. Отображение на иерархическую модель данных
- •6.3. Отображение на сетевую модель данных
- •7. Физическая модель данных
- •7.1. Интерфейсы между пользователем и базой данных
- •7.2. Методы доступа внутренней модели (физической)
- •7.2.1. Физический последовательный метод доступа
- •7.2.2. Индексно-последовательный метод доступа
- •7.2.3. Индексно-произвольный метод доступа
- •7.2.4. Инвертированный метод доступа
- •7.2.5. Прямой метод доступа
- •7.2.6. Метод доступа посредством хеширования
- •7.3. Методы доступа внешней модели (представления пользователя)
- •8. Языкsql
- •8.1. Состав языка sql
- •8.2. Реляционные операции. Команды языка манипулирования данными
- •Команда select Простейшие конструкции команды select
- •Список полей
- •Все поля
- •Все поля в произвольном порядке
- •Вычисления
- •Литералы
- •Конкатенация
- •Использование квалификатора as
- •Работа с датами
- •Агрегатные функции
- •Предложение from команды select
- •Ограничения на число выводимых строк
- •Is null
- •Операции сравнения
- •Between
- •Containing
- •Is null
- •Логические операторы
- •Преобразование типов (cast)
- •Изменение порядка выводимых строк (order by)
- •Упорядочивание с использованием имен столбцов
- •Упорядочивание с использованием номеров столбцов
- •Устранение дублирования (модификатор distinct)
- •Соединение (join)
- •Внутренние соединения
- •Самосоединения
- •Внешние соединения
- •9. Общая характеристика баз знаний и экспертных систем
- •9.1. Терминология
- •9.2. Принципы, структура и функции систем баз знаний (сбз)
- •9.3. Классификация инструментальных средств построения сбз
- •Литература
- •Содержание
- •1. Данные 6
- •2. Администрирование базы данных 21
- •3. Словарь данных 43
- •4. Модели данных 57
- •5. Проектирование концептуальной модели данных 82
2.2.1. Проектирование базы данных (этап 1)
Структура базы данных является моделью предметной области. Она должна ее точно представлять и удовлетворять ее требованиям. Необходимо, чтобы процесс проектирования поддерживался всеми функциональными подразделениями предприятия, которые обязаны описать и определить элементы данных с точки зрения управляющего и пользователя. В функции АБД входит также устранение всех противоречий и двусмысленностей в определении данных. Качество проекта базы данных зависит от качества определения элементов данных и их взаимосвязей. Фактически процесс проектирования – это описание предприятия в терминах его наиболее важных объектов и внутренних связей.
В системе образования наиболее важными объектами являются студенты и преподаватели. В числе других важных объектов можно назвать читаемые курсы, списки абитуриентов, расписание занятий, размер платы за обучение, денежные расходы и особые проекты. Эти объекты и их взаимосвязи должны быть определены на начальном этапе проектирования с участием АБД.
Эффективному решению указанных задач способствует словарь данных (СД), подробно рассматриваемый далее.
На практике введение базы данных одновременно для всех используемых на предприятии прикладных программ может оказаться нежелательным или просто нереальным. Для прикладных программ, непосредственная установка которых невозможна, создается долгосрочный план. Преимущества постепенного развития очевидны. Ключевым моментом внедрения любого проекта является успешная реализация его первой части при демонстрации потенциальных возможностей концепции базы данных и способность АБД конвертировать все функции предметной области для работы в среде базы данных. Первые конвертируемые прикладные программы должны быть достаточно представительными, но не самыми важными. Однако они не должны принадлежать и к числу наименее важных. Поскольку реализация всех функций осуществляется постепенно, шаг за шагом, этапу проектирования придается первостепенное значение.
Проект должен быть легко расширяемым. Немногие предприятия могут позволить себе начать все сначала, если проект оказывается недостаточно гибким. В связи с необходимостью постоянного изменения и развития базы данных ее реструктуризация по мере добавления новых типов данных и новых прикладных программ должна быть простой. В некоторых системах управления базами данных предусмотрены средства реструктуризации. Если же их нет, то написание соответствующей процедуры (обычно называемой процедурой загрузки/разгрузки) возлагается на пользователя. АБД должен учитывать, что переход от традиционной «эры наборов данных» к внедрению технологии баз данных связан с уменьшением стоимости сопровождения и обеспечением дополнительных возможностей.
На рис. 2.5 представлены основные шаги проектирования. При логическом проектировании АБД должен сконцентрировать свое внимание на причинах существования определенных взаимосвязей между объектами, а не на способах их реализации в базе данных.
Рис. 2.5
2.2.2. Материализация базы данных (этап 2)
После определения физической структуры, удовлетворяющей эксплуатационным требованиям, описание этой скелетной структуры (структур) физической базы (баз) данных необходимо передать СУБД. Иногда такие описания заносятся в библиотеку описаний базы данных, куда могут заноситься и логические представления пользователей (называемые также «внешними моделями»).
До загрузки и использования базы данных в полном объеме желательно реализовать ее экспериментальный прототип или построить ее модель. На основе прототипа можно получить приемлемую оценку эксплуатационных характеристик полной базы данных и прогнозировать увеличение объема или числа функций. Применение полной базы данных без предварительного тестирования недопустимо. Возможно частичное перекрытие этапа анализа с этапом конвертирования и интеграции. В том случае, когда прототип не отвечает эксплуатационным требованиям, приходится возвращаться к этапу проектирования.
Если в результате тестирования выявлено, что прототип отвечает эксплуатационным требованиям, можно проводить загрузку базы данных. Производится проверка соответствия эксплуатационных характеристик требованиям, предъявляемым к проекту полной базы данных. При неудовлетворительных результатах необходимо модифицировать проект базы данных. Если же результаты оказываются удовлетворительными, переходят к проверке средств обеспечения безопасности, секретности и разграничения доступа на полной физической базе данных. В случае успешного тестирования этих средств (рис. 2.6) выполняются работы этапа конвертирования (этапа 3) в полном объеме.
Рис. 2.6