Основные данные о работе

СОДЕРЖАНИЕ 

ВВЕДЕНИЕ………………………………………………………..…………………..3

1. БАЗЫ И МОДЕЛИ ДАННЫХ…………………………………………...……….5

     1.1. Данные и компьютер……..………………………………………………..5

     1.2. Базы данных…………………………………………………………..……7

     1.3. Объекты базы данных…………………………………………………..…8

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

2. ИЕРАРХИЧЕСКАЯ МОДЕЛЬ ДАННЫХ……………………………………13

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

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

  2.3. Сравнение сетевой и иерархической модели данных……………..…….18

  2.4. Язык описания данных иерархической модели……………….…….……20

  2.5. Пример иерархической БД……………………………………..………......22

ЗАКЛЮЧЕНИЕ………………………………………………………..……………..27

СПИСОК СОКРАЩЕНИЙ……………………………………………………….....28

БИБЛИОГРАФИЧЕСКИЙ СПИСОК……………………………………..………..29

ПРИЛОЖЕНИЕ 1 Список основных команд операций………………………...…30

ПРИЛОЖЕНИЕ 2 Уровни моделей данных………………………………...……...31

         Введение

     Термин  «модель данных» был введен американским математиком Коддом в 1970 г. при обосновании реляционной модели данных. Это понятие соответствует такому смысловому аспекту термина «модель», который понимается как средство, инструмент для моделирования.

     В этом широком смысле любая система  машинных команд, любой язык программирования, любая СУБД как инструмент для моделирования информации о предметной области, является моделью данных, так как предоставляет свои средства для описания, организации данных и их обработки.

     В ГОСТе понятие модели данных для  СУБД определяется как «совокупность  правил порождения структур данных в базах данных, операций над ними, а также ограничений целостности, определяющих допустимые связи и значения данных, последовательности их изменения».

     Таким образом, в понятие «модель данных»  входят три составляющие:

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

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

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

      Инструментальные  средства логического уровня наиболее типизируются несмотря на то, что каждая СУБД представляет собой оригинальную модель данных. Поэтому «моделью данных» в узком смысле называют тип модели данных логического уровня.

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

     Цель  работы – дать характеристику иерархической модели данных.

     Методы  исследования. При  написании  курсовой работы был произведен комплексный анализ. Основными методами в работе явились методы анализа: метод описания (пример), историко-функциональный, сравнительно-сопоставительный.

     Структура  работы. Курсовая работа состоит из введения, двух глав, заключения, библиографии, приложения

    Основная  часть

1. База  данных и модели данных

    1.1. Данные и компьютер

      Восприятие  реального мира можно соотнести  с последовательностью разных, хотя иногда и взаимосвязанных, явлений. С давних времен люди пытались описать  эти явления. Такое описание называют данными.

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

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

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

      Жесткая зависимость между данными и использующими их программами создает серьезные проблемы в ведении данных и делает использования их менее гибкими.

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

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

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

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

        1.2. Базы данных

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

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

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

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

     Проблемы  сопровождения больших систем, основанных на файлах, привели в конце 60-х годов к появлению СУБД. В основе СУБД лежала простая идея: изъять из программ определение структуры содержимого файла и хранить её вместе с данными в базе данных.

1.3. Объекты базы данных

     Таблицы – это основные объекты любой базы данных. Во-первых, в таблицах хранятся все данные, имеющиеся в базе, а во-вторых, таблицы хранят и структуру базы (поля, их типы и свойства).

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

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

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

     Это специальные объекты баз данных, реализованных в последней версии СУБД  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 Пример иерархических связей между сегментами

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