91650

Организация данных во внутримашинной сфере

Доклад

Информатика, кибернетика и программирование

Физическая организация данных определяет способ размещения информации непосредственно на машинных носителях и выполняется программными инструментариями автоматически без участия человека. Разработчики внутримашинной информационной базы АСУ оперируют в программах только представлениями о логической организации данных которая определяется видом модели данных. Под моделью данных понимается совокупность взаимосвязанных структур данных и операций над этими структурами.

Русский

2015-07-21

114.65 KB

0 чел.

Организация данных во внутримашинной сфере

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

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

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

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

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

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

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

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

Файловые информационные базы обрабатываются системами управления файлами (Q&A, Reflex, FFS File и др.), которые не считаются системами управления базами данных. Файловые системы легко осваиваются, достаточно просты и эффективны в использовании. Для работы с ними используются простые языки запросов, либо и вовсе ограничиваются набором программ-утилит. Такие системы обычно поддерживают работу с небольшим числом файлов, содержащих ограниченное число записей с небольшим количеством полей.

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

Иерархические модели имеют древовидную структуру, когда каждому узлу структуры соответствует один сегмент, представляющий собой поименованный линейный кортеж данных. Каждому сегменту, кроме корневого, соответствует один входной и несколько выходных сегментов (рис. 3.6).

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

 

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

Сетевая модель во многом подобна иерархической и отличается от нее только тем, что допускает несколько входных сегментов наряду с возможностью наличия сегментов без входов с точки зрения иерархической структуры. На рис. 3.7 представлен простой пример сетевой структуры, полученной на основе модификации иерархической топологии (рис. 3.6).

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


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

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

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

ются на основе моделей подобного типа. Реляционную модель представления информации предложил в 1970 г. сотрудник фирмы IBM Эдгар Кодд. Данная модель позволяет выполнять все необходимые операции по запоминанию и поиску данных и обеспечивает целостность данных.

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

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

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

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


 

А также другие работы, которые могут Вас заинтересовать

23329. Макросы. Создание макросов 36.5 KB
  Отчет по работе: Открыть таблицу CtrlF1: USE{SPACEBAR}table1{SPACEBAR}AGAIN{SPACEBAR}IN{SPACEBAR}0{ENTER} SELECT{SPACEBAR}Table1{ENTER} BROWSE{SPACEBAR}LAST{ENTER} Удалить таблицу CtrlF2: Remove{SPACEBAR}Table{SPACEBAR}table1{ENTER} Установить отношение между таблицами CtrlR: SET{SPACEBAR}RELATION{SPACEBAR}TO{SPACEBAR}фамилия{SPACEBAR}INTO{SPACEBAR}Table2{SPACEBAR}ADDITIVE{ENTER} Модифицировать отчёт CtrlM: MODIFY{SPACEBAR}REPORT{SPACEBAR} c: artamonov базы данных visual foxpro9 save artlab10 report1.frx {SPACEBAR}NOENVIRONMENT{ENTER}...
23330. Генератор прикладных программ 91 KB
  Цель работы: научиться создавать стандартные приложения с помощью генератора FoxApp. Задание: Перед началом работы создать отдельный каталог для файлов приложения. Выполните генерацию стандартного приложения создавая или указывая базу данных на шаге 1. Проверьте работу стандартного приложения: стандартный экран форма ввода кнопки управления; меню стандартного приложения.
23331. Интегрированная cреда FoxPro for Windows 39 KB
  Задание на лабораторную работу: Создайте на диске Х: каталог под именем FOXPRO для хранения примеров. Войдите в среду FoxPro. Ознакомьтесь с интерфейсом FoxPro: изучите систему главного меню – пункты Файл Правка База Запись Программа Запуск Текст Окно; изучите способы выбора пунктов меню с помощью мыши комбинаций клавиш; повторите правила работы с окнами: закрыть открыть свернуть развернуть распахнуть переместить изменить размеры переключиться между окнами; ознакомьтесь с командами пунктов меню Окно и ; повторите...
23332. Создание структуры базы данных в СУБД FoxPro 166 KB
  Задание на лабораторную работу: Создайте структуру базы данных в соответствии с вашей темой расчетнографического задания. Изучите возможности среды СУБД FoxPro for Windows для создания структуры базы данных. Выполните просмотр содержимого базы данных.
23333. Сортировка и индексирование баз данных 244 KB
  Задание на лабораторную работу: Выполните сортировку по одному полю базы данных содержащей не менее 15 записей. Повторите сортировку для полей содержащих разные типы данных. Просмотрите результат сортировки в новой базе данных.
23334. Установка отношений между базами данных 233.5 KB
  Задание на лабораторную работу: Проверьте проект базы данных на предмет проектирования связей ключи первичные вторичные. В проекте базы данных предметной области выделите 2–3 связанные таблицы родственные таблицы. Просмотрите связанные базы данных на экране.
23335. Поиск информации в базах данных. Установка фильтров 453.5 KB
  Задание на лабораторную работу: Составьте не менее 10 логических выражений для поиска данных в базе данных. Выполните поиск данных с помощью команды Locate. Выполните стандартный поиск в индексированной базе данных.
23336. Обработка запросов 404 KB
  SELECT SALES.SNUM SALES.SNAME SALES.CITY; FROM SALES; WHERE SALES.
23337. Создание отчётов 434.5 KB
  Задание на лабораторную работу: Определите структуру отчета. Создать и выполнить стандартный отчет. На основе стандартного отчета создать сложный отчет. Запустить отчет.