- •Межрегиональный открытый социальный институт
- •Содержание
- •Примечание! 108
- •2. Цели и задачи дисциплины, ее место в учебном процессе
- •1.1. Цели и задачи дисциплины
- •1.2. Место дисциплины в учебном процессе
- •1.3. Итоговый контроль знаний по курсу
- •3. Содержание дисциплины
- •План занятий
- •3. Содержание дисциплины
- •План занятий
- •Наименование и краткое содержание лекций
- •Тема 2. Администрация базы данных.
- •Тема 3. Взаимодействие компонентов системы Баз данных.
- •Тема 4. Классификация субд.
- •Тема 5. Модели данных.
- •Тема 6. Уровни моделирования предметной области.
- •Тема 7. Концептуальное проектирование баз данных
- •Тема 9. Требования к распределенным базам данных
- •Тема 10. Транзакции.
- •Конспект лекций
- •Тема 2. Администрация базы данных
- •Тема 3. Взаимодействие компонентов системы баз данных
- •Тема 4. Классификация субд
- •Тема 5. Модели данных
- •5.1. Основные понятия реляционной модели данных
- •5.2. Целостность реляционных данных
- •5.3. Операции над отношениями
- •5.4. Нормализация баз данных
- •Тема 6. Уровни моделирования предметной области
- •Тема 7. Концептуальное проектирование баз данных
- •7.1.Даталогическое проектирование
- •7.2. Физические модели
- •Тема 8. Case-средства разработки баз данных
- •8.1. Пример нотации er-модели – метод idef1x
- •Тема 9. Требования к распределенным базам данных
- •9.1. Базовые архитектуры распределенной обработки
- •Сервер бд
- •Тема 10. Транзакции
- •Тема 11. Проблема сжатия больших информационных массивов.
- •Тема 11. Фракталы и Фрактальные методы архивации
- •2. Математические основы фрактального сжатия
- •3. Типовая схема фрактального сжатия
- •Методические рекомендации для выполнения лабораторных работ
- •Создание таблицы в режиме таблицы и определение свойств для полей таблицы
- •Импорт таблиц. Работа с мастером подстановок
- •Создание связей между таблицами
- •Ввод и просмотр данных в режиме таблицы
- •Заполните таблицу Продажи товаров, рис. 5.11
- •Создание формы базы данных с помощью мастера
- •Работа с конструктором форм. Элементы управления
- •Создание подчиненной формы
- •Оформление формы
- •Создание простого запроса на выборку
- •Задание нескольких условий отбора в запросе
- •Создание вычисляемого поля в запросе
- •Групповые расчеты в запросе
- •Создание запроса на удаление
- •Создание запроса на обновление
- •Создание запроса на создание таблицы
- •Создание отчета базы данных с помощью мастера
- •Просмотр и печать отчета
- •Создание макроса
- •Тестовая база
- •Ответы:
- •Глоссарий
7.2. Физические модели
Физическая модель БДопределяет способ размещения данных на носителях (устройствах внешней памяти), а также способ и средства организации эффективного доступа к ним. Поскольку СУБД функционирует в составе и под управлением операционной системы, то организация хранения данных и доступа к ним зависит от принципов и методов управления данными операционной системы.
К вопросам организации данных относятся:
· выбор типа записи – единицы обмена в операциях ввода-вывода;
· выбор способа размещения записей в файле и, возможно, метода оптимизации размещения;
· выбор способа адресации и метода доступа к записям.
Стадия физического проектирования БД в общем случае включает:
· выбор способа организации БД;
· разработку спецификации внутренней схемы;
· описание отображения концептуальной схемы во внутреннюю.
В отличие от ранних СУБД, многие современные системы не предоставляют разработчику какого-либо выбора на этой стадии. Реально к вопросам проектирования физической модели можно отнести:
· выбор схемы размещения данных (разделение по файлам или тип RAID-массива);
· определение числа и типа индексов (например, кластеризованный или некластеризованный в случае MS SQL Server).
Способ хранения БД определяется механизмами СУБД автоматически по умолчанию на основе спецификаций концептуальной схемы БД, и внутренняя схема в явном виде в таких системах не используется. Внешние схемы БД обычно конструируются на стадии разработки приложений.
Тема 8. Case-средства разработки баз данных
ER-модели широко используются в практике создания БД. Они применяются при ручном и автоматизированном проектировании с использованием CASE-средств, поддерживающих весь цикл разработки СБД или отдельные его стадии. К таким средствам относятся: ProKit*WORKBENCH, Design / IDEF, CASE Oracle (Designer / 2000), Power Designer (S-Designor), ERWin, SILVERRUN, ERStudio и другие. CASE-средства являются сравнительно новым направлением в информационных технологиях. Первая версия инструментария Oracle появилась в 1989 г.
CASE-средства поддерживают концептуальное проектирование, позволяют осуществить логическое и физическое проектирование путем автоматической генерации БД для целевой СУБД. Но следует обратить внимание на различия в терминологии. Во многих CASE-системах ER-модель называется логической моделью, а представление логической структуры целевой БД – физической моделью.
При сравнении CASE-систем кроме используемой методологии ER-моделирования, необходимо учитывать специфические критерии, связанные с реализацией функций автоматизированного проектирования:
число и перечень поддерживаемых целевых СУБД;
поддержку распределенных БД;
поддержку коллективной работы при проектировании (управление правами пользователей, ведение репозитория и т. д.);
построение концептуальной ER-модели по описанию структуры существующей БД – реверс-инжиниринг;
автоматизируемые функции проектирования и степень их автоматизации;
качество и жесткость проектных решений (возможность выбора из нескольких альтернативных решений, возможность ручного вмешательства в процесс);
надежность работы;
документирование проекта;
открытость системы (возможность стыковки с другими средствами);
удобство графического редактора;
количественные ограничения (общее число сущностей, число уровней вложенности для обобщенной сущности и др.);
возможность автоматической оценки объема памяти для проектируемой БД;
возможность автоматической генерации процедур;
наличие средств моделирования хранилищ данных;
требования к ресурсам компьютера;
операционную среду;
стоимость системы.
CASE-средства показывают модель с разной степенью детализации:
только обозначения сущностей и связей между ними;
сущности + ключи;
сущности + ключи + внешние ключи;
сущности + все атрибуты.
Наличие таких возможностей создает существенные удобства, особенно при создании больших и сложных моделей.
Важной характеристикой CASE-средств является возможность получать подмодели из общей модели и обеспечивать интеграцию фрагментов в единую модель. Эти возможности могут быть полезны не только при коллективной разработке проекта – при обсуждении модели с конечными пользователями очень удобно каждому из них предоставлять только ту часть модели, которая имеет для него интерес. Декомпозиция модели облегчает процесс проектирования.
Еще одним критерием сравнения СASE-средств является степень проверки правильности построенных моделей. Ни одна система автоматизации проектирования не может гарантировать соответствия построенной концептуальной модели реалиям предметной области. Это определяется только квалификацией разработчиков, их пониманием предметной области и умением отобразить ее в модели.
Наличие средств проверки моделей может помочь устранить ошибки, связанные с невнимательностью – отсутствие идентификатора у сущности, отсутствие связи объекта с другими объектами, неправильное задание имен, отсутствие информации, необходимой при дальнейшем проектировании (объемные характеристики для классов объектов и связей между ними и т. п.), противоречия в модели (что особенно важно при коллективной разработке) и др.
Многие CASE-средства этим позволяют задавать в модели ограничения целостности и генерируют программы (триггеры, хранимые процедуры), проверяющие эти ограничения при эксплуатации БД. Кроме того, CASE-средства могут генерировать программы ведения БД.
Многие CASE-средства позволяют экспортировать модели в другие системы и, наоборот, импортировать их из других систем.