История развития баз данных. Основные понятия и определения. Архитектура базы данных. Физическая и логическая независимость, страница 5

Преподаватель

Код преподавателя

Фио

Должность

Кафедра

001

Иванов

доцент

К1

002

Петров

профессор

К1

003

Сидоров

доцент

К2

Кафедра

Кафедра

Факультет

К1

Ф1

К1

Ф1

К2

Ф2

Существуют и более высокие формы нормализации, но при проектировании баз данных они используются достаточно редко.

Следует отметить, что в процессе нормализации отношений кроме устранения трудностей в реализации функций обработки данных, ликвидируется избыточность данных, т.е. дублирование определённого значения атрибута в различных экземплярах объектов базы данных. Так, например, если в первой нормальной форме сведения о принадлежности кафедры факультету указывалась в трёх строках, то после перевода в третью нормальную форму – только в одной строке.

Устранение избыточности сокращает объём базы данных и повышает эффективность работы системы, т.е. исключает не синхронный ввод данных.

Тема 3.

Вопросы темы:

1. Дополнительные общие рекомендации по проектированию базы данных.

2. Разработка приложений в среде Microsoft Windows.

1. Дополнительные общие рекомендации по проектированию базы данных.

Рекомендации следующие:

  1. Нежелательно включать в базу данных атрибут, значение которого можно рассчитать по другим атрибутам. Это приведёт к необходимости изменения значения атрибута синхронно с изменением данных.
  2. Повторяющиеся атрибуты в объектах нежелательны, т.е. необходимо создать новое отношение «Код атрибута – Значение атрибута» и дальше использовать только код. Это необходимо сделать по следующим причинам:
    1. Значения могут не обладать уникальностью – и код решит проблему.
    2. Изменение значений во времени не мешает правильно определить объект.
    3. Появляется возможность пользователя выбрать значение из таблицы, а не вводить его, что предотвращает ошибки ввода.
    4. Длина кода меньше длины значения, что способствует повышению быстродействия системы.

2. Разработка приложений в среде MicrosoftWindows.

Архитектура системы СУБД MicrosoftAccess является реляционной базой данных, работающей в среде Windows. MicrosoftAccess включает в себя следующие объекты, связанные с хранением данных: таблицы, запросы, формы, отчёты, макросы и модули. Из них для хранения данных используются только таблицы. Остальные служат только для автоматизации.

Рассмотрим более подробно назначение каждого объекта:

  1. Таблица. Объект предназначен, как уже отмечалось, для хранения данных. Таблица содержит записи (строки) и поля (столбцы). Для каждой таблицы можно определить первичный ключ
  2. и один или несколько индексов для увеличения скорости доступа к данным.
  3. Форма. Предназначена, в основном, для ввода данных, отображения их на экране и управления работы приложением.
  4. Запрос.  Этот объект позволят получить данные из одной или нескольких таблиц. Можно создать запрос на выбор, обновление, удаление  или добавление  данных. С помощью запроса можно создать новую таблицу (таблицы), используя данные из существующих таблиц и запросов.
  5. Отчёт. Этот объект предназначен для создания документа, который, в последствии, будет распечатан или включен в документ другого приложения.
  6. Макрос. Этот объект представляет собой структурированное описание одного или нескольких действий, которые должно выполнить MicrosoftAccess в ответ на определённое событие.
  7. Модуль. Этот объект содержит программы на языке MicrosoftAccessBasic. Использование таких программ позволяет реализовать такие функции приложений, которые не могут быть реализованы другими средствами MicrosoftAccess.