- •(Перечень, подлежащих разработке вопросов) :
- •Введение
- •Проектирование базы данных
- •1.1 Анализ предметной области
- •1. Назначение и предметная область
- •1.2 Проектирование инфологической, даталогической, физической моделей, построение er-диаграмм
- •1.2.1 Инфологическая модель
- •Классификация сущностей
- •О первичных и внешних ключах
- •Ограничения целостности
- •О построении инфологической модели
- •Описание предметной области.
- •Экзаменационная ведомость
- •Выделение объектов справочной информации
- •Выделение объектов учётной информации
- •1.2.2 Даталогическая модель
- •1.2.3 Физическое проектирование
- •Разработка базы данных
- •Структура субд ms Access
- •Справочная система ms Access
- •Начало работы с ms Access
- •Создание новой базы данных с помощью Конструктора
- •Создание таблиц с помощью Мастера таблиц
- •Определение ключевых полей
- •Определение связи таблиц
- •Использование режима таблицы Ввод, редактирование и просмотр данных
- •Использование Мастера подстановок при вводе данных в таблицы
- •Изменение проекта базы данных
- •Изменение структуры таблиц
- •Переименование и удаление таблиц
- •Изменение первичных ключей
- •Редактирование связей
- •Изменение макета таблицы
- •Изменение шрифта и внешнего вида ячеек таблицы
- •Изменение высоты строк и ширины столбцов
- •Изменение порядка следования столбцов
- •Другие изменения макета таблицы
- •Сортировка данных
- •Поиск данных
- •Создание форм в access Основные сведения о формах
- •Способы создания форм
- •Использование Мастера по созданию форм
- •Создание форм в режиме Конструктора
- •Разделы форм
- •Панель элементов и Список полей
- •Свойства объектов формы
- •Создание управляющих кнопок
- •Управление элементами формы
- •Редактирование элементов формы
- •Изменение порядка обхода элементов формы
- •Разработка сложных форм
- •Построение диаграмм в формах
- •2.7.1 Элементы диаграмм и подготовка исходных данных
- •Построение диаграммы с помощью Мастера диаграмм
- •Редактирование диаграмм
- •4. Создание запросов на выборку к однотабличным и многотабличным субд access” Понятие запроса
- •Создание запроса
- •Окно конструктора запроса
- •Рис 17 . Окно конструктора запроса. Пример ввода условия.
- •Включение полей в запрос
- •Например, на рис. В бланк запроса включены поля Фамилия, Имя и Город из таблицы Студент.
- •Установка критериев отбора записей
- •Виды критериев
- •Логическая операция или
- •Логическая операция и
- •Оператор Between
- •Использование построителя выражений
- •Итоговые запросы
- •Выполнение запроса
- •Запросы к нескольким таблицам
- •5. Выбор данных с помощью запросов-действий. Перекрестные запросы Понятие запросов-действий
- •Особенности работы с запросами-действиями
- •Запросы на создание таблицы
- •Запросы на обновление записей
- •Запрос на удаление записей
- •Запрос на добавление записей
- •Перекрестные запросы
- •Использование Мастера для создания перекрестной таблицы
Ограничения целостности
Целостность (от англ. integrity – нетронутость, неприкосновенность, сохранность, целостность) – понимается как правильность данных в любой момент времени. Но эта цель может быть достигнута лишь в определенных пределах: СУБД не может контролировать правильность каждого отдельного значения, вводимого в базу данных (хотя каждое значение можно проверить на правдоподобность). Например, нельзя обнаружить, что вводимое значение 5 (представляющее номер дня недели) в действительности должно быть равно 3. С другой стороны, значение 9 явно будет ошибочным и СУБД должна его отвергнуть. Однако для этого ей следует сообщить, что номера дней недели должны принадлежать набору (1,2,3,4,5,6,7).
Поддержание целостности базы данных может рассматриваться как защита данных от неверных изменений или разрушений (не путать с незаконными изменениями и разрушениями, являющимися проблемой безопасности). Современные СУБД имеют ряд средств для обеспечения поддержания целостности (так же, как и средств обеспечения поддержания безопасности).
Выделяют три группы правил целостности:
Целостность по сущностям;
Целостность по ссылкам;
Целостность, определяемая пользователем.
Не допускается, чтобы какой-либо атрибут, участвующий в первичном ключе, принимал неопределенное значение.
Значение внешнего ключа должно либо:
быть равным значению первичного ключа цели;
быть полностью неопределенным, т.е. каждое значение атрибута, участвующего во внешнем ключе должно быть неопределенным.
Для любой конкретной базы данных существует ряд дополнительных специфических правил, которые относятся к ней одной и определяются разработчиком. Чаще всего контролируется:
уникальность тех или иных атрибутов,
диапазон значений (экзаменационная оценка от 2 до 5),
принадлежность набору значений (пол "М" или "Ж").
О построении инфологической модели
Основная сложность восприятия рекомендаций, приведенных в методических рекомендациях, чисто психологического плана.
Действительно, для определения перечня и структуры хранимых данных надо собрать информацию о реальных и потенциальных приложениях, а также о пользователях базы данных, а при построении инфологической модели следует заботиться лишь о надежности хранения этих данных, напрочь забывая о приложениях и пользователях, для которых создается база данных.
Это связано с абсолютно различающимися требованиями к базе данных прикладных программистов и администратора базы данных. Первые хотели бы иметь в одном месте (например, в одной таблице) все данные, необходимые им для реализации запроса из прикладной программы или с терминала. Вторые же заботятся о исключении возможных искажений хранимых данных при вводе в базу данных новой информации и обновлении или удалении существующей. Для этого они удаляют из базы данных дубликаты и нежелательные функциональные связи между атрибутами, разбивая базу данных на множество маленьких таблиц. Так как многолетний мировой опыт использования информационных систем, построенных на основе баз данных, показывает, что недостатки проекта невозможно устранить любыми ухищрениями в программах приложений, то опытные проектировщики не позволяют себе идти навстречу прикладным программистам (даже тогда, когда они сами являются таковыми).
Большинство людей предпочитает учиться на собственных ошибках, все же еще раз советуем неопытным проектировщикам баз данных:
четко разграничивать такие понятия как запрос на данные и ведение данных (ввод, изменение и удаление);
помнить, что, как правило, база данных является информационной основой не одного, а нескольких приложений, часть их которых появится в будущем;
плохой проект базы данных не может быть исправлен с помощью любых (даже самых изощренных) приложений.
Рассмотрим выделение информационных объектов на примере предметной области "Учебный процесс".