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

     Если  запросы – это специальные  средства для отбора и анализа  данных, то формы – это средства для ввода данных. Смысл их тот же – предоставить пользователю средства для заполнения только тех полей, которые ему заполнять положено. Одновременно с этим в форме можно разместить специальные элементы управления (счетчики, раскрывающиеся списки, переключатели, флажки и прочее) для автоматизации ввода. Преимущества форм раскрываются особенно наглядно, когда происходит ввод данных с заполненных бланков. В этом случае форму делают графическими средствами так, чтобы она повторяла оформление бланка – это заметно упрощает работу наборщика, снижает его утомление и предотвращает появление печатных ошибок.

     По  своим свойствам и структуре  отчеты во многом похожи на формы, но предназначены только для вывода данных, причем для вывода не на экран, а на принтер. В связи с этим отчеты отличаются тем, что в них приняты специальные меры для группирования выводимых данных и для вывода специальных элементов оформления, характерных для печатных документов.

     Это специальные объекты баз данных, реализованных в последней версии СУБД  Microsoft Access (Access 2000). Правда, более корректно их называть страницами доступа к данным. Физически это особый объект, выполненный в коде HTML, размещаемый на Web-странице и передаваемый клиенту вместе с ней. Сам по себе этот объект не является базой данной, но содержит компоненты, через которые осуществляется связь переданной Web-страницы с базой данных, остающейся на сервере. Пользуясь этими компонентами, посетитель Web-узла может просматривать записи базы в полях страницы доступа. Таким образом, страницы доступа к данным осуществляют интерфейс между клиентом, сервером и базой данных, размещенной на сервере. Эта база данных не обязательно должна быть базой данных Microsoft Access. Страницы доступа, созданные средствами Microsoft Access, позволяют работать также с базами данных Microsoft SQL Server.

     Эти категории объектов предназначены  как для автоматизации повторяющихся операций при работе с СУБД, так и для создания новых функций путем программирования. В СУБД Microsoft Access макросы состоят из последовательности внутренних команд СУБД и являются одним из средств автоматизации работы с базой. Модули создаются средствами внешнего языка программирования, в данном случае языка Visual Basic for Applications. Это одно из средств, с помощью которых разработчик базы может заложить в нее нестандартные функциональные возможности, удовлетворить специфическое требование заказчика, повысить быстродействие системы управления, а также уровень ее защищенности.

     1.4. Концепция баз данных

      Активная  деятельность по отысканию приемлемых способов обобществления непрерывно растущего  объема информации привела к созданию в начале 60-х годов специальных программных комплексов, называемых "Системы управления базами данных" (СУБД).

      Основная  особенность СУБД – это наличие процедур для ввода и хранения не только самих данных, но и описаний их структуры. Файлы, снабженные описанием хранимых в них данных и находящиеся под управлением СУБД, стали называть банки данных, а затем "Базы данных" (БД).

      Пусть, например, требуется хранить расписание движения самолетов и ряд других данных, связанных с организацией работы аэропорта (БД "Аэропорт"). Используя для этого одну из современных "русифицированных" СУБД, можно подготовить следующее описание расписания:

      СОЗДАТЬ ТАБЛИЦУ Расписание

        (Номер_рейса        Целое

         Дни_недели         Текст (8)

         Пункт_отправления  Текст (24)

         Время_вылета       Время

         Пункт_назначения   Текст (24)

         Время_прибытия     Время

         Тип_самолета       Текст  (8)

         Стоимость_билета   Валюта);

      и ввести его вместе с данными в  БД "Аэропорт".

      Язык  запросов СУБД позволяет обращаться за данными, как из программ, так и с терминалов (рис. 1.1). Сформировав запрос

      ВЫБРАТЬ  Номер_рейса, Дни_недели, Время_вылета

      ИЗ  ТАБЛИЦЫ  Расписание

      ГДЕ  Пункт_отправления = 'Москва'

        И  Пункт_назначения  = 'Киев'

        И  Время_вылета > 17;

      получим расписание "Москва-Киев" на вечернее время, а по запросу 

      ВЫБРАТЬ  КОЛИЧЕСТВО (Номер_рейса)

      ИЗ  ТАБЛИЦЫ  Расписание

      ГДЕ  Пункт_отправления = 'Москва'

        И  Пункт_назначения  = 'Минск';

      получим количество рейсов "Москва-Минск".  

      

      Рис. 1.1 Связь программ и данных при использовании СУБД

      Эти запросы не потеряют актуальности и  при расширении таблицы:

      ДОБАВИТЬ  В ТАБЛИЦУ Расписание

      Длительность_полета  Целое;

      Однако  за все надо расплачиваться: на обмен  данными через СУБД требуется  большее время, чем на обмен аналогичными данными прямо из файлов, специально созданных для того или иного приложения. (Список основных команд операций описан в Приложении 1)

 

2. Иерархическая модель данных

     2.1. Иерархическая модель данных

     Иерархическая модель данных имеет много общих  черт с сетевой моделью данных, хронологически она появилась даже раньше, чем сетевая. Допустимыми информационными конструкциями в иерархической модели данных являются отношение, веерное отношение и иерархическая база данных. В отличие от ранее рассмотренных моделей данных, где предполагалось, что информационным отображением одной предметной области является одна база данных, в иерархической модели данных, допускается отображение одной предметной области в несколько иерархических баз данных.

     Понятия отношения и веерного отношения  в иерархической модели данных не изменяются.

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

     Основные  недостатки: отношение "многие ко многим" реализуется очень сложно, дает громоздкую структуру и требует хранения избыточных данных, что особенно нежелательно на физическом уровне, иерархическая упорядоченность усложняет операции удаления и включения, доступ к любой вершине возможен только через корневую, что увеличивает время доступа.

     Иерархическая модель данных основана на понятии  деревьев, состоящих из вершин и  ребер. Вершина дерева ставится в  соответствие  совокупности атрибутов  данных, характеризующих некоторый  объект. Вершины и ребра дерева как бы образуют иерархическую древовидную структуру, состоящую из n уровней.

     На  рис. 2.1 изображена структура иерархической базы данных о студентах и преподавателях вуза, удовлетворяющая всем ограничениям, указанным в определении. 
 

 

 
 
 

                                                        а 
 

 

 
 

                                                                   б  

Иерархическая база данных для вуза:

а – исходная структура;

б – с добавленными сведениями о группах дипломников 

Рис. 2.1 Пример структуры иерархической базы данных 

     В графических иллюстрациях структуры  приводятся ключи соответствующих  отношений.

     Если  понадобится в рамках данной иерархической структуры указать для групп, выполняющих дипломное проектирование, связь с соответствующей выпускающей кафедрой, то установить веерное отношение Р (Кафедра, Группа) невозможно, так как Группа не может быть зависимым отношением дважды (она уже является зависимой для отношения Факультет). Зафиксировать связь студенческих групп с выпускающей кафедрой можно путем выделения соответствующих групп в отдельное отношение с ключом В-группа, что приводит к появлению избыточной информации.

     Ограничение, которое поддерживается в иерархической модели данных, состоит в невозможности нарушения требований, фигурирующих в определении иерархической базы данных. Это ограничение обеспечивается специальной укладкой значений отношений в памяти ЭВМ.

     Записью иерархической базы данных называется множество значений, содержащих одно значение корневого отношения и все верны, доступные от него в соответствии со структурой иерархической базы данных. В нашем примере одну запись образуют данные, относящиеся к одному факультету.

     Для веерных отношений в составе  иерархической базы данных справедлива  уже известная закономерность: если существует веерное отношение, то ключ зависимого отношения функционально  определяет ключ основного отношения, и наоборот, если ключ одного отношения  функционально определяет ключ второго отношения, то первое отношение может быть зависимым, а второе - основным в некотором веерном отношении.

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

     2.2. Сегмент иерархической модели данных

     Сегмент в терминологии Американской Ассоциации по базам данных DBTG (Data Base Task Group) называется записью, при этом в рамках иерархической модели определяются два понятия: тип сегмента или тип записи и экземпляр сегмента или экземпляр записи (рис. 2.2).  
 

     

      Логически исходный сегмент

     

     Логически подчиненные сегменты

     Рис. 2.2 Пример иерархических связей между сегментами

 

     Тип сегмента — это поименованная совокупность типов элементов данных, в него входящих. Экземпляр сегмента образуется из конкретных значений полей или элементов данных, в него входящих. Каждый тип сегмента в рамках иерархической модели образует некоторый набор однородных записей. Для возможности различия отдельных записей в данном наборе каждый тип сегмента должен иметь ключ или набор ключевых атрибутов (полей, элементов данных). Ключом называется набор элементов данных, однозначно идентифицирующих экземпляр сегмента. Например, рассматривая тип сегмента, описывающий сотрудника организации, мы должны выделить те характеристики сотрудника, которые могут его однозначно идентифицировать в рамках БД предприятия. Если предположить, что на предприятии могут работать однофамильцы, то, вероятно, наиболее надежным будет идентифицировать сотрудника по его табельному номеру. Однако если мы будем строить БД, содержащую описание множества граждан, например нашей страны, то, скорее всего, нам придется в качестве ключа выбрать совокупность полей, отражающих его паспортные данные.