Термин «модель данных» был введен американским математиком Коддом в 1970 г. при обосновании реляционной модели данных. Это понятие соответствует такому смысловому аспекту термина «модель», который понимается как средство, инструмент для моделирования.
В этом широком смысле любая система машинных команд, любой язык программирования, любая СУБД как инструмент для моделирования информации о предметной области, является моделью данных, так как предоставляет свои средства для описания, организации данных и их обработки.
В ГОСТе понятие модели данных для СУБД определяется как «совокупность правил порождения структур данных в базах данных, операций над ними, а также ограничений целостности, определяющих допустимые связи и значения данных, последовательности их изменения».
Таким образом, в понятие «модель данных» входят три составляющие:
- средства для организации данных;
- операции для обработки, манипулирования данными;
- ограничения, обеспечивающие целостность данных.
Третья компонента специфична для баз данных и отсутствует, например, в языках программирования.
На каждом уровне работы с данными — инфологическом, логическом и внутреннем используются свои инструментальные средства. На инфологическом наиболее часто используется простейшая модель «сущность-атрибут-связь». На внутреннем уровне все СУБД используют в разных реализациях сходные приемы и средства, такие как страничная организация логических записей БД в наборах данных, организация служебных индексных файлов, сходные методы доступа и т.д.
Инструментальные средства логического уровня наиболее типизируются несмотря на то, что каждая СУБД представляет собой оригинальную модель данных. Поэтому «моделью данных» в узком смысле называют тип модели данных логического уровня.
Исторически, иерархическая модель появилась раньше, и в настоящий момент она используются реже, чем более современная реляционная модель данных. Однако до сих пор существуют системы, работающие на основе этой модели.
Цель работы — дать характеристику иерархической модели данных.
Методы исследования. При написании курсовой работы был произведен комплексный анализ. Основными методами в работе явились методы анализа: метод описания (пример), историко-функциональный, сравнительно-сопоставительный.
1. База данных и модели данных
1.1 Данные и компьютер
Восприятие реального мира можно соотнести с последовательностью разных, хотя иногда и взаимосвязанных, явлений. С давних времен люди пытались описать эти явления. Такое описание называют данными.
Базы данных как основы информационного обеспечения управленческой деятельности
... направить исследования вглубь. База данных - это информационная модель, позволяющая упорядоченно хранить данные о группе объектов, обладающих одинаковым набором свойств. Программное обеспечение, предназначенное для работы с базами данных, называется система управления базами данных (СУБД). СУБД используются для ...
Традиционно фиксация данных осуществляется с помощью конкретного средства общения на конкретном носителе. Обычно данные и их интерпретация фиксируются совместно, так как естественный язык достаточно гибок для представления того и другого. Примером может служить утверждение «Стоимость авиабилета 128». Здесь «128» — данное, а «Стоимость авиабилета» — его семантика.
Применение компьютеров для ведения и обработки данных обычно приводит к еще большему разделению данных и интерпретации. Компьютер имеет дело главным образом с данными как таковыми. Большая часть интерпретирующей информации вообще не фиксируется в явной форме, (компьютер не «знает», является ли «21.50» стоимостью авиабилета или временем вылета).
Это произошло, потому что существует, по крайней мере, две исторические причины, по которым применение компьютера привело к отделению данных от интерпретации. Во-первых, компьютеры не обладали достаточными возможностями для обработки текстов на естественном языке — основном языке интерпретации данных. Во-вторых, стоимость памяти компьютера была первоначально весьма велика. Память использовалась для хранения самих данных, а интерпретация традиционно возлагалась на пользователя. Пользователь закладывал интерпретацию данных в свою программу, которая «знала», например, что шестое вводимое значение связано с временем прибытия самолета, а четвертое — с временем его вылета. Это существенно повышало роль программы, так как вне интерпретации данные представляют собой не более чем совокупность битов на запоминающем устройстве.
Жесткая зависимость между данными и использующими их программами создает серьезные проблемы в ведении данных и делает использования их менее гибкими.
Нередки случаи, когда пользователи одной и той же ЭВМ создают и используют в своих программах разные наборы данных, содержащие сходную информацию. Иногда это связано с тем, что пользователь не знает (либо не захотел узнать), что в соседней комнате или за соседним столом сидит сотрудник, который уже давно ввел в ЭВМ нужные данные. Чаще потому, что при совместном использовании одних и тех же данных возникает масса проблем.
Разработчики прикладных программ размещают нужные им данные в файлах, организуя их наиболее удобным для себя образом. При этом одни и те же данные могут иметь в разных приложениях совершенно разную организацию (разную последовательность размещения в записи, разные форматы одних и тех же полей и т.п.).
Обобществить такие данные чрезвычайно трудно: например, любое изменение структуры записи файла, производимое одним из разработчиков, приводит к необходимости изменения другими разработчиками тех программ, которые используют записи этого файла.
Для иллюстрации обратимся, к примеру, приведенному в книге Девиса, Операционные системы: «Несколько лет назад почтовое ведомство (из лучших побуждений) пришло к решению, что все адреса должны обязательно включать почтовый индекс. Во многих вычислительных центрах это, казалось бы, незначительное изменение привело к ужасным последствиям. Добавление к адресу нового поля, содержащего шесть символов, означало необходимость внесения изменений в каждую программу, использующую данные этой задачи в соответствии с изменившейся суммарной длиной полей. Тот факт, что какой-то программе для выполнения ее функций не требуется знания почтового индекса, во внимание не принимался: если в некоторой программе содержалось обращение к новой, более длинной записи, то в такую программу вносились изменения, обеспечивающие дополнительное место в памяти.
Технология подготовки и проведения концертной программы на базе ...
... опытно - практическая работа в процессе подготовки и проведения конкурсной программы на базе Эвенкийского районного Дома культуры. База исследования: Кемеровский государственный университет культуры и искусств. Институт ... неотъемлемой частью истории. Процитируем историка: «В XVIII веке вокзалами называли загородные сады с клубно-концертными помещениями, сочетавшие в своих стенах концерты и ...
В условиях автоматизированного управления централизованной базой данных все такие изменения связаны с функциями управляющей программы базы данных. Программы, не использующие значения почтового индекса, не нуждаются в модификации — в них, как и прежде, в соответствии с запросами посылаются те же элементы данных. В таких случаях внесенное изменение неощутимо. Модифицировать необходимо только те программы, которые пользуются новым элементом данных».
1.2 Базы данных
В самом общем смысле база данных — это набор записей и файлов, организованных специальным образом. В компьютере, например, можно хранить фамилии и адреса друзей или клиентов. Один из типов баз данных — это документы, набранные с помощью текстовых редакторов и сгруппированные по темам. Другой тип — файлы электронных таблиц, объединяемые в группы по характеру их использования.
С ростом популярности СУБД в 70-80-х годах появилось множество различных моделей данных. У каждой из них имелись свои достоинства и недостатки, которые сыграли ключевую роль в развитии реляционной модели данных, появившейся во многом благодаря стремлению упростить и упорядочить первые модели данных.
До появления СУБД все данные, которые содержались в компьютерной системе постоянно, хранились в виде отдельных файлов. Система управления файлами, которая обычно является частью операционной системы компьютера, следила за именами файлов и местами их расположения. В системах управления файлами модели данных, как правило, не использовались; эти системы ничего не знали о внутреннем содержимом файлов. Для такой системы файл, содержащий документ текстового процессора, ничем не отличается от файла, содержащего данные о начисленной зарплате.
Знание о содержимом файла — какие данные в нём хранятся и какова их структура — было уделом прикладных программ, использующих этот файл. В приложении для начисления зарплаты каждая из программ, обрабатывающих файл с информацией о служащих, содержит в себе описание структуры данных (ОСД), хранящихся в этом файле. Когда структура данных изменялась — например, в случае добавления нового элемента данных для каждого служащего, — необходимо было модифицировать каждую из программ, обращавшихся к файлу. Со временем количество файлов и программ росло, и на сопровождение существующих приложений приходилось затрачивать всё больше и больше усилий, что замедляло разработку новых приложений.
Проблемы сопровождения больших систем, основанных на файлах, привели в конце 60-х годов к появлению СУБД. В основе СУБД лежала простая идея: изъять из программ определение структуры содержимого файла и хранить её вместе с данными в базе данных.
1.3 Объекты базы данных
Таблицы — это основные объекты любой базы данных. Во-первых, в таблицах хранятся все данные, имеющиеся в базе, а во-вторых, таблицы хранят и структуру базы (поля, их типы и свойства).
БАЗЫ ДАННЫХ И ИХ ЗАЩИТА
... MySQL . Дать обзор средств защиты баз данных. Обзор баз данных и их классификация Классификация БД по модели данных : 1. Реляционная модель данных - это абстракция данных, которая представляет данные в базе данных в виде набора таблиц, называемых отношениями. Каждая таблица имеет имя и ...
Запросы служат для извлечения данных из таблиц и предоставления их пользователю в удобном виде. С помощью запросов выполняют такие операции как отбор данных, их сортировку и фильтрацию. С помощью запросов можно выполнять преобразования данных по заданному алгоритму, создавать новые таблицы, выполнять автоматическое наполнения таблиц данными, импортированными из других источников, выполнять простейшие вычисления в таблицах и многое другое.
Если запросы — это специальные средства для отбора и анализа данных, то формы — это средства для ввода данных. Смысл их тот же — предоставить пользователю средства для заполнения только тех полей, которые ему заполнять положено. Одновременно с этим в форме можно разместить специальные элементы управления (счетчики, раскрывающиеся списки, переключатели, флажки и прочее) для автоматизации ввода. Преимущества форм раскрываются особенно наглядно, когда происходит ввод данных с заполненных бланков. В этом случае форму делают графическими средствами так, чтобы она повторяла оформление бланка — это заметно упрощает работу наборщика, снижает его утомление и предотвращает появление печатных ошибок.
По своим свойствам и структуре отчеты во многом похожи на формы, но предназначены только для вывода данных, причем для вывода не на экран, а на принтер. В связи с этим отчеты отличаются тем, что в них приняты специальные меры для группирования выводимых данных и для вывода специальных элементов оформления, характерных для печатных документов.
Это специальные объекты баз данных, реализованных в последней версии СУБД 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;
получим расписание «Москва-Киев» на вечернее время, а по запросу
ВЫБРАТЬ КОЛИЧЕСТВО (Номер_рейса)
ИЗ ТАБЛИЦЫ Расписание
ГДЕ Пункт_отправления = ‘Москва’
И Пункт_назначения = ‘Минск’;
- получим количество рейсов «Москва-Минск».
Эти запросы не потеряют актуальности и при расширении таблицы:
ДОБАВИТЬ В ТАБЛИЦУ Расписание
Длительность_полета Целое;
— Однако за все надо расплачиваться: на обмен данными через СУБД требуется большее время, чем на обмен аналогичными данными прямо из файлов, специально созданных для того или иного приложения.
2. Иерархическая модель данных
2.1 Иерархическая модель данных
Иерархическая модель данных имеет много общих черт с сетевой моделью данных, хронологически она появилась даже раньше, чем сетевая. Допустимыми информационными конструкциями в иерархической модели данных являются отношение, веерное отношение и иерархическая база данных. В отличие от ранее рассмотренных моделей данных, где предполагалось, что информационным отображением одной предметной области является одна база данных, в иерархической модели данных, допускается отображение одной предметной области в несколько иерархических баз данных.
Понятия отношения и веерного отношения в иерархической модели данных не изменяются.
Основные достоинства иерархической модели данных: простота построения и использования, обеспечение определенного уровня независимости данных, простота оценки операционных характеристик.
Основные недостатки: отношение «многие ко многим» реализуется очень сложно, дает громоздкую структуру и требует хранения избыточных данных, что особенно нежелательно на физическом уровне, иерархическая упорядоченность усложняет операции удаления и включения, доступ к любой вершине возможен только через корневую, что увеличивает время доступа.
Иерархическая модель данных основана на понятии деревьев, состоящих из вершин и ребер. Вершина дерева ставится в соответствие совокупности атрибутов данных, характеризующих некоторый объект. Вершины и ребра дерева как бы образуют иерархическую древовидную структуру, состоящую из n уровней.
студентах и преподавателях вуза, удовлетворяющая всем.
Иерархическая база данных для вуза:
- а — исходная структура;
б — с добавленными сведениями о группах дипломников
Если понадобится в рамках данной иерархической структуры указать для групп, выполняющих дипломное проектирование, связь с соответствующей выпускающей кафедрой, то установить веерное отношение Р (Кафедра, Группа) невозможно, так как Группа не может быть зависимым отношением дважды (она уже является зависимой для отношения Факультет).
Зафиксировать связь студенческих групп с выпускающей кафедрой можно путем выделения соответствующих групп в отдельное отношение с ключом В-группа, что приводит к появлению избыточной информации.
Ограничение, которое поддерживается в иерархической модели данных, состоит в невозможности нарушения требований, фигурирующих в определении иерархической базы данных. Это ограничение обеспечивается специальной укладкой значений отношений в памяти ЭВМ.
Записью иерархической базы данных называется множество значений, содержащих одно значение корневого отношения и все верны, доступные от него в соответствии со структурой иерархической базы данных. В нашем примере одну запись образуют данные, относящиеся к одному факультету.
Для веерных отношений в составе иерархической базы данных справедлива уже известная закономерность: если существует веерное отношение, то ключ зависимого отношения функционально определяет ключ основного отношения, и наоборот, если ключ одного отношения функционально определяет ключ второго отношения, то первое отношение может быть зависимым, а второе — основным в некотором веерном отношении.
Кроме того, ограничение на существование единственного корневого отношения в иерархической базе данных трансформируется в требование: первичный ключ каждого некорневого отношения должен функционально определять первичный ключ корневого отношения.
2.2 Сегмент иерархической модели данных
Сегмент в терминологии Американской Ассоциации по базам данных DBTG (Data Base Task Group) называется записью , при этом в рамках иерархической модели определяются два понятия: тип сегмента или тип записи и экземпляр сегмента или экземпляр записи.
Тип сегмента
В иерархической модели сегменты объединяются в ориентированный древовидный граф. При этом полагают, что направленные ребра графа отражают иерархические связи между сегментами: каждому экземпляру сегмента, стоящему выше по иерархии и соединенному с данным типом сегмента, соответствует несколько (множество) экземпляров данного (подчиненного) типа сегмента. Тип сегмента, находящийся на более высоком уровне иерархии, называется логически исходным по отношению к типам сегментов, соединенным с данным направленными иерархическими ребрами, которые в свою очередь называются логически подчиненными по отношению к этому типу сегмента. Иногда исходные сегменты называют сегментами-предками, а подчиненные сегменты называют сегментами-потомками.
Схема иерархической БД представляет собой совокупность отдельных деревьев, каждое дерево в рамках модели называется физической базой данных. Каждая физическая БД удовлетворяет следующим иерархическим ограничениям:
- в каждой физической БД существует один корневой сегмент, то есть сегмент, у которого нет логически исходного (родительского) типа сегмента;
- каждый логически исходный сегмент может быть связан с произвольным числом логически подчиненных сегментов;
- каждый логически подчиненный сегмент может быть связан только с одним логически исходным (родительским ) сегментом.
Очень важно понимать различие между сегментом и типом сегмента — оно такое же, как между типом переменной и самой переменной: сегмент является экземпляром типа сегмента. Например, у нас может быть тип сегмента Группа (Номер, Староста) и сегменты этого типа, такие как (4305, Петров Ф. И.) пли (383, Кустова Т. С.).
Между экземплярами сегментов также существуют иерархические связи. Рассмотрим, например, иерархический граф, представленный на рис. 2.3
Рис. 2.3 Пример структуры иерархического дерева
Каждый тип сегмента может иметь множество соответствующих ему экземпляров. Между экземплярами сегментов также существуют иерархические связи.
Рис. 2.4 Пример двух экземпляров данного дерева
На рис. 2.4 представлены 2 экземпляра иерархического дерева соответствующей структуры.
физической записью
Таблица 1. Принцип линейной записи иерархических графов
|
а 1 b1 b2 b3 c1 d1 d2 o1 |
a 2 b4 b5 c2 d3 d4 e2 e3 e4 |
|
|
Запись1 |
Запись2 |
|
Как видно из примера, физические записи в иерархической модели различаются по длине и структуре.
2.3 Сравнение иерархической и сетевой модели данных
Стандарт сетевой модели впервые был определен в 1975 году организацией CODASYL (Conference of Data System Languages), которая определила базовые понятия модели и формальный язык описания. Сетевая модель описывает элементарные данные и отношения между ними в виде ориентированной сети. Это такие отношения между объектами, когда каждый порожденный элемент имеет более одного исходного и может быть связан с любым другим элементом структуры.
Сетевая модель данных (далее СМД) замышлялась как инструмент для пользователей баз данных — программистов. В связи с этим в СМД больше внимания уделяется структуризации данных, чем развитию ее операционных возможностей.
Для сетевых моделей стоит выделить следующие проблемы:
Сетевые модели не имеют общей теории.
Много эвристики.
Проблема эффективности процедур работы с сетями.
Много видов сетей, в том числе рассчитанных на аппаратную реализацию.
Каждая из моделей (иерархическая и сетевая) обладает характеристиками, делающими ее наиболее удобной для конкретных приложений. Одно из основных различий этих моделей состоит в том, что для иерархических и сетевых СУБД их структура часто не может быть изменена после ввода данных, тогда как для реляционных СУБД структура может изменяться в любое время. С другой стороны, для больших БД, структура которых остается длительное время неизменной, и постоянно работающих с ними приложений с интенсивными потоками запросов на БД-обслуживание именно иерархические и сетевые СУБД могут оказаться наиболее эффективными решениями, ибо они могут обеспечивать более быстрый доступ к информации БД, чем реляционные СУБД.
Ограничения целостности в сетевой и иерархической моделях поддерживаются неявно, регламентирующими организацию данных и манипулирование записями: обязательность ключевых атрибутов для корневых записей, обеспечение режимов включения и исключения записей в соответствии с классами членства и т.д. Кроме того, могут задаваться явно и затем поддерживаться СУБД другие ограничения целостности. Например, можно задать области допустимых значений для элементов данных записей, могут быть включены специальные процедуры проверки корректности состояния данных и др.
Основной единицей организации и обработки данных в иерархической и сетевой модели данных служит запись (или группа данных), состоящая из элементов. Элемент данных — наименьшая (обычно поименованная) единица структуры данных, к которой СУБД может адресоваться. Элементы данных группируются в агрегаты данных — поименованные совокупности элементов или более мелких входящих агрегатов. Запись — это агрегат, который не входит в состав никакого другого агрегата.
Отличительные особенности иерархической и сетевой моделей: основной единицей обработки в них является запись; в иерархической модели данные организованы в иерархические структуры и обработка начинается только с корневой записи, а доступ к некорневым обеспечивается только по иерархическому пути; в сетевой модели данных обработка может быть начата с записи любого типа независимо от её расположения в БД, и от извлеченной записи возможны переходы, как к её подчиненным записям, так и к тем, которым она подчинена; при отображении сетевых структур предметной области в иерархической БД необходимо дублирование данных, при этом семантическая целостность автоматически не поддерживается.
2.4 Язык описания данных иерархической модели
Каждая физическая база описывается набором операторов, определяющих как ее логическую структуру, так структуру хранения БД. Описание начинается с оператора DBD (Data Base Definition):
- DBD Name = <
- имя БД>
- ACCESS = <
- способ доступа>
- Способ доступа определяет способ организации взаимосвязи физических записей.
Определено 5 способов доступа:
HSAM — hierarchical sequential access method (иерархически последовательный метод),
HISАМ — hierarchical index sequential access method (иерархически индексно-последовательный метод),
HDAM — hierarchical direct access method (иерархически прямой метод),
HIDAM — hierarchical index direct access method (иерархически индексно-прямой метод),
INDEX — индексный метод.
Далее идет описание наборов данных, предназначенных для хранения БД: DATA SET DD1 < имя оператора, определяющего хранимый набор данных, DEVICE =< устройство хранения БД>. OVERLOW = < имя области переполнения>.
Так как физические записи имеют разную длину, то при модификации данных запись может увеличиться и превысит исходную длину записи до модификации. В этом случае при определенных методах хранения может понадобиться дополнительное пространство хранения, где и будут размешены дополнительные данные. Это пространство и называется областью переполнения
После описания всей физической БД идет описание типов сегментов, ее составляющих, в соответствии с иерархией. Описание сегментов всегда начинается с описания корневого сегмента, Общая схема описания типа сегмента такова:
- SEGM NAMЕ = <
- имя сегмента>
- BYTES =<
- размер в байтах>, FREQ — <средняя частота реализаций сегмента под одним исходным>
- PARENT = <имя родительского сегмента>.
Параметр FREQ определяет среднее количество экземпляров данного сегмента, связанных с одним экземпляром родительского сегмента. Для корневого сегмента это число возможных экземпляров корневого сегмента.
Для корневого сегмента параметр PARENT равен 0 (нулю).
Далее для каждого сегмента дается описание полей:
- FIELD NAME = {(<имя поля>
- [. SEQ].{U | M}) | <имя поля>
- }. START = <
- номер байта, с которого начинается значения поля >, BYTES = <размер поля в байтах>, TYPE = {X | Р | С}.
Признак SEQ — задается для ключевого поля, если экземпляры данного сегмента физически упорядочены в соответствии со значениями данного поля.
Параметр U задается, если значения ключевого поля уникальны для всех экземпляров данного сегмента, М — в противном случае. Если поле является ключевым, то его описание задается в круглых скобках, в противном случае имя поля задается без скобок. Параметр TYPE определяет тип данных. Для ранних иерархических моделей были определены только три типа данных; X — шестнадцатеричный, Р — упакованный десятичный, С — символьный.
Заканчивается описание схемы вызовом процедуры генерации:
- DBDGEN — указывает на конец последовательности управляющих операторов описания БД;
- FINISH — устанавливает ненулевой код завершения при обнаружении ошибки; Q END — конец.
В системе может быть несколько физических БД (ФБД), но каждая из них оснащается отдельно своим DBD и ей присваивается уникальное имя. Каждая ФБД содержит только одни корневой сегмент. Совокупность ФБД образует концептуальную модель данных.
2.5 Пример иерархической БД
Организация занимается производством и продажей компьютеров, в рамках производства, организация комплектует компьютеры из готовых деталей по индивидуальным заказам. У организации существует несколько базовых моделей, которые продаются без предварительных заказов по наличию на складе. В организации существуют несколько филиалов и несколько складов, на которых хранятся комплектующие. Задание: необходимо вести учет продаваемой продукции.
При приеме заказа мы должны выяснить, какую модель заказывает заказчик: типичную или индивидуальную комплектацию.
Если заказывается типичная модель, то выясняется, какая модель и есть ли она в наличии, если модель есть, то надо уменьшить количество компьютеров данной модели в данном филиале па покупаемое количество. На этом будем считать заказ выполненным, однако при оформлении заказа может потребоваться задание полной спецификации покупаемого изделия.
Если заказывается индивидуальная модель, то требуется описать весь состав новой модели.
Для того чтобы можно было бы принимать заказы на индивидуальные модели, понадобится информация о наличие конкретных деталей на складе.
Перечень операторов поиска данных:
Синтаксис:
GET UNIQUE <имя сегмента> WHERE <список поиска>
- Список поиска состоит из последовательности условий вида <имя сегмента>.<имя поля>ОС <constant или имя другого поля данного сегмента или имя переменной>;
- ОС — операция сравнения;
- условия могут быть соединены логическими операциями И и ИЛИ {&, V}.
Назначение:
Получить единственное значение.
Пример:
Найти типовую модель стоимостью не более $600, которая существует не менее чем л 10 экземплярах.
GET UNIQUE ТИПОВЫЕ МОДЕЛИ WHERE Типовые модели. Стоимость <= $600 AND Типовые модели. Количество на складе >= 10
Данная команда всегда ищет с начала БД и останавливается, найдя первый экземпляр сегмента, удовлетворяющий условиям поиска.
Синтаксис:
GET NEXT <имя сегмента> WHERE «список аргументов поиска>
Назначение:
Получить следующий экземпляр сегмента для тех же условий.
Пример:
Напечатать полный список заказов стоимостью не менее $500.
GET UNIQUE ИНДИВИДУАЛЬНЫЕ МОДЕЛИ WHERE Индивидуальные модели.Стоимость >= $500 WHILE NOT FAIL (пока не конец поиска) DO
PRINT N заказа, Стоимость, Количество
GET NEXT ИНДИВИДУАЛЬНЫЕ МОДЕЛИ
END
Синтаксис:
GET NEXT <имя сегмента> WITHIN PARENT [where <дополнительные.условия>]
Назначение:
Получить следующее для того же исходного.
Пример:
Получить перечень винчестеров, имеющихся на складе номер 1, в количестве не менее 10 с объемом 10 Гбайт.
GET UNIQUE СКЛАД WHERE Склад.Номер = 1
GET NEXT ИЗДЕЛИЕ WITHIN PARENT WHCRE Изделие’.Наименование * “Винчестер”
GET NEXT ХАРАКТЕРИСТИКИ WITHIN’PARENT
WHERE ХАРАКТЕРИСТИКИ.Параметр = 10 AND
ХАРАКТЕРИСТИКИ.Единицы Измерения = ГБ AND
ХАРАКТЕРИСТИКИ.Величина > 10
While Not Fall (пока поиск не завершен) DO
Get Next Wuh-in Parent
End.
Перечень операторов поиска данных с возможностью модификации:
1.Найти и удержать единственный экземпляр сегмента. Эта операция подобна пepвой операции поиска GET UNIQUE, единственным отличием этой операции является то, что после выполнения этой операции над найденным экземпляром сегмента допустимы операции модификации (изменения) данных.
Синтаксис:
GET HOLD UNIQUE <имя сегмента> WHERE <список поиска>
2.Найти и удержать следующее с теми же условиями поиска. Аналогично операции предыдущей операции, эта операция дублирует вторую операцию поиска GET NEXT с возможностью выполнения последующей модификации данных.
Синтаксис:
GET HOLD NEXT [WHERE <дополнительные условия>]
3.Получить и удержать следующее для того же родителя. Эта операция является аналогом операции поиска, но разрешает выполнение операций модификации данных после себя.
Синтаксис:
GET HOLD NEXT WITHIN PARENT [where <дополнительные.условия>]
Заключение
В данной курсовой работе рассмотрена тема иерархические модели данных. На сегодняшний день иерархические модели данных уступают реляционной модели данных, из-за того что, реляционные модели данных простоты и наглядны как в процессе создания, так и на пользовательском уровне.
Из выше написанного следует вывод:
Иерархическая модель данных (далее ИМД) состоит из нескольких деревьев, т.е. является лесом. Каждая корневая вершина образует начало записи логической базы данных. В ИМД вершины, находящиеся на уровне i, называют порожденными вершинами на уровне i-1. Операции в ИМД имеют аналогичный сетевой модели данных «позаписный» характер. Аппарат перемещения по структуре в графовых моделях служит для установки тех объектов данных, к которым будет применяться очередная операция манипулирования данными. Такие объекты называются текущими. Механизмы доступа к данным и перемещения по структуре данных в таких моделях достаточно сложны и существенным образом опираются на концепцию текущего состояния механизма доступа.
В связи с тем, что иерархическая модель обладает большим количеством недостатков она не будет применятся для моделирования АСИС.
Также следует отметить принципы иерархии:
- иерархия всегда начинается с корневой вершины (или главного узла);
- исходный узел, из которого строится дерево, называется корневым узлом или просто корнем, причем одно дерево может иметь только один корень;
- узел может содержать один или несколько атрибутов, описывающих находящийся в нем объект;
- порожденные узлы могут встраиваться в «дерево» как в горизонтальном направлении, так и в вертикальном;
- доступ к порожденным узлам возможен только через исходный узел, поэтому существует только один путь доступа к каждому узлу.
Список использованных источников
[Электронный ресурс]//URL: https://litfac.ru/kursovaya/ierarhicheskaya-model-dannyih/
1 Аладьев В.В., Хунт Ю.Я., Шишаков М.Л. «Основы информатики», Учебное пособие, М., 2000 г.
2 Бойко В.В., Савинков В.М., «Проектирование баз данных информационных систем», М., Финансы и статистика, 2000 г.
3 Девис У., «Операционные системы», М., Мир, 2000 г.
4 Дейт К., «Введение в системы баз данных», М., Наука, 2001 г.
5 Дейт К., «Руководство по иерархической СУБД», М., Финансы и статистика, 2003 г.
6 Дубнов П.Ю. «Access 2000: Проектирование баз данных», М., ДМК : Лайт, 2000 г.
7 Ездов А.А., «Лабораторные работы по физике с использованием компьютерной модели», Информатика и образование, 2002 г.
8 Ермаков М.Г., Андреева Л.Е., «Вопросы разработки тестирующих программ», Информатика и образование, 2001 г.
9 Жуков А. А, Федякина Л.А “Система контроля знаний TSTST”, Информатика и образование, 2001 г.
10 Кодд Дж., «Базы данных», Москва. Мир. 2000 г.
11 Макашарипов С., Горев А., Ахаян Р., «Эффективная работа с СУБД» СПб, Питер, 2000 г.
12 Мейер Д., «Теория иерархических баз данных», М., Мир, 2000 г.
13 Хилайер С., Мизик Д. «Программирование» /Пер. с англ., 3-е изд., доп.- М. : Изд.-торговый дом «Рус. ред.», 2000 г.
14 Цикритизис Д., Лоховски Ф., «Модели данных», М., Финансы и статистика, 2000 г.
15 Шнитман В., Серверы баз данных: проблемы оценки конфигурации системы. СУБД №5-6/02, 2001 г.
