Много информации это просто груда мусора



страница3/9
Дата29.04.2018
Размер1.56 Mb.
ТипЛекция
1   2   3   4   5   6   7   8   9

Лекция 3. Модели данных

  1. Этапы развития БД

  2. Модели данных

    1. Объектные модели данных

    2. Модели данных на основе записей

        1. Структуры данных

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

          1. Недостатки иерархической модели данных

        3. Сетевая модель данных

          1. Недостатки сетевой модели данных

        4. Реляционная модель данных

          1. Основные понятия реляционной модели данных

  3. Физические модели данных




Этапы развития БД

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


В конце 60-х годов прошлого века появились БД для meinfraimов, основным принципом организации которых была централизация хранения и обработки данных.
Первые настольные СУБД появились около 20 лет назад (с появлением и использованием ПК). Они как таковые не содержали специальных приложений и сервисов, управляющих данными, — взаимодействие с ними осуществлялось с помощью файловых сервисов операционной системы. Нередко подобные СУБД имели в своем составе и средства разработки, ориентированные на работу с данными формата, характерного для этой СУБД, и позволяющие создать более или менее комфортный пользовательский интерфейс. Что же касается обработки данных — она целиком и полностью осуществлялась в пользовательском (клиентском) приложении.
Следующим шагом в развитии настольных СУБД было появление их сетевых многопользовательских версий, позволяющих обрабатывать данные, находящиеся в общедоступном хранилище (например, на сетевом диске) нескольким пользователям одновременно. От чисто настольных СУБД их многопользовательские версии отличаются наличием механизма блокировок частей файлов данных (содержащих одну или несколько записей таблицы), что позволяет обращаться к одному и тому же файлу нескольким пользователям одновременно.
Недостатки настольных СУБД не очевидны и становятся заметны, как правило, при росте хранимых объемов данных и увеличении числа пользователей. Обычно они проявляются в снижении производительности и в возникновении сбоев при обработке данных после некоторого времени использования клиентских приложений. Причина подобных проблем кроется в основном принципе работы таких СУБД и основанных на них информационных систем, заключающемся в обработке данных внутри пользовательского приложения. Например, если с помощью такой системы требуется выполнить запрос согласно какому-либо критерию (например, выбрать заказы, обработанные за последние два часа, из таблицы заказов), то, в лучшем случае (если эта таблица проиндексирована по времени поступления заказа), приложение должно прочесть с сетевого диска весь индекс, найти в нем сведения о местоположении записей в файлах, содержащих таблицу, и затем прочесть эти части файлов. В общем же случае, когда таблица не проиндексирована по данному полю, ее необходимо загрузить с сетевого диска и проанализировать.
Еще одна проблема настольных СУБД заключается в возможности нарушения ссылочной целостности данных, так как единственным механизмом, контролирующим ее, является пользовательское приложение. Поэтому все пользовательские приложения должны содержать соответствующий код, и доступ к файлам БД из любых других приложений должен быть запрещен. В наиболее популярных настольных СУБД (например, Microsoft Access, Corel Paradox) код, контролирующий стандартную ссылочную целостность, содержится в библиотеках, используемых всеми приложениями, работающими с этой БД, а сама БД при этом может содержать описание правил ссылочной целостности.
Следующим этапом развития СУБД для персональных компьютеров были так называемые серверные СУБД.
Архитектура «клиент/сервер», для которой предназначены серверные СУБД, основана на модели, в которой хранение и обработка данных централизованы на одном выделенном компьютере, где функционирует специальное приложение или сервис, называемый сервером БД. Сервер БД отвечает за работу с файлами БД, поддержку ссылочной целостности, резервное копирование, обеспечение авторизованного доступа к данным, протоколирование операций и, конечно, за выполнение пользовательских запросов на выбор и модификацию данных и метаданных. Клиентские приложения, являющиеся источниками этих запросов, функционируют на ПК в сети.
При использовании серверных СУБД выполнение запросов производится самим сервером, поэтому клиентские приложения получают от сервера только результаты самого запроса и не требуют передачи всего индекса или всей таблицы, что существенно снижает сетевой трафик при обработке запросов.
БД подразделяются на централизованные и распределенные. Централизованная БД хранится в памяти одной вычислительной системы. Распределенная БД состоит из нескольких пересекающихся частей, хранимых в различных ЭВМ вычислительной сети.
Модели данных
БД есть отражение предметной области реального мира: ее объекты, отношения между ними и отношения в БД должны соответствовать друг другу. Компьютер оперирует только формальными понятиями (моделями), соответствующими объектам и связям внешнего мира.
Таким образом, ядром любой БД является модель данных. Модель данных – интегрированный набор понятий для описания данных, связей между ними и ограничений, накладываемых на данные. Модель данных – средство абстракции, позволяющее видеть информационное содержание (обобщенную структуру), а не их конкретные значения.
«Модель данных» - средство моделирования; «модель БД» - результат разработки БД.
Модель данных можно рассматривать как сочетание трех компонентов:


  1. Структурная часть, т. е. набор правил, по которым может быть построена БД.

  2. Управляющая часть, определяющая типы допустимых операций с данными.

  3. Набор ограничений поддержки целостности данных.

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


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

  1. формальные (математические), предполагающие разработку БД с участием человека;

  2. математические представления, рассчитанные на автоматизацию процесса проектирования БД («компьютерное представление»).

Первая группа, в свою очередь, подразделяется на три категории:




  • объектные (object-based) модели данных;

  • модели данных на основе записей (record-based);

  • физические модели данных.

Первые две используются для описания данных на концептуальном, логическом и внешнем уровнях, а последняя – на внутреннем уровне.



Объектные модели данных


При построении объектных моделей данных используются такие понятия как сущности, атрибуты и связи. Некоторые наиболее общие типы объектных моделей:


  • модель типа «сущность – связь», или ER-модель (Entity-Relationship model);

  • семантическая модель;

  • функциональная модель;

  • объектно-ориентированная модель.

Имеется большое количество методик описания предметной области (построения инфологической модели). Одними из первых моделей в этом направлении были так называемые форрестеровские модели. Из наиболее известных можно назвать методику структурного анализа SADT и основанную на ней IDEF0, диаграммы потоков данных Гейна-Сарсона, методику объективно-ориентированного анализа UML и др.


SADT – аббревиатура слов Structured Analysis and Design Technique (технология структурного анализа и проектирования) – это графические обозначения и подход к описанию систем. Дуглас Т. Росс начал работу над проектом в 1969 г. Графический язык SADT организует естественный язык вполне определенным и однозначным образом, за счет чего SADT и позволяет описывать системы, которые до недавнего времени не поддавались адекватному представлению.
Методологию IDEF0 можно считать следующим этапом развития хорошо известного графического языка описания функциональных систем SADT. Исторически, IDEF0, как стандарт был разработан в 1981 году в рамках обширной программы автоматизации промышленных предприятий. Существуют и модификации этой методологии:
IDEF1 – методология моделирования информационных потоков внутри системы, позволяющая отображать и анализировать их структуру и взаимосвязи;
IDEF1X (IDEF1 Extended) – методология построения реляционных структур. IDEF1X относится к типу методологий «сущность – связь» (ER – Entity – Relationship) и, как правило, используется для моделирования реляционных БД, имеющих отношение к рассматриваемой системе;
IDEF2 – методология динамического моделирования развития систем. В связи с весьма серьезными сложностями анализа динамических систем от этого стандарта практически отказались, и его развитие приостановилось на самом начальном этапе. Однако в настоящее время присутствуют алгоритмы и их компьютерные реализации, позволяющие превращать набор статических диаграмм IDEF0 в динамические модели, построенные на базе «раскрашенных сетей Петри» (CPN – Color Petri Nets);
IDEF3 – методология документирования процессов, происходящих в системе, которая используется, например, при исследовании технологических процессов на предприятиях. С помощью IDEF3 описываются сценарий и последовательность операций для каждого процесса. IDEF3 имеет прямую взаимосвязь с методологией IDEF0 – каждая функция (функциональный блок) может быть представлена в виде отдельного процесса средствами IDEF3;
IDEF4 – методология построения объектно-ориентированных систем. Средства IDEF4 позволяют наглядно отображать структуру объектов и заложенные принципы их взаимодействия, тем самым позволяя анализировать и оптимизировать сложные объектно-ориентированные системы;
IDEF5 – методология онтологического исследования сложных систем. С помощью методологии IDEF5 онтология системы может быть описана при помощи определенного словаря терминов м правил, на основании которых могут быть сформулированы достоверные утверждения о состоянии рассматриваемой системы в некоторый момент времени. На основе этих утверждений формируются выводы о дальнейшем развитии системы и производится ее оптимизация.
UML (Unified Modeling Language, унифицированный язык моделирования) – это стандартная нотация визуального моделирования программных систем, принятая консорциумом Object Managing Group (OMG) осенью 1997 г., и на сегодняшний день она поддерживается многими объектно-ориентированными CASE продуктами.
В настоящее время ER-модель стала одним из основных методов концептуального проектирования БД.
Объектно-ориентированная модель расширяет определение сущности с целью включения в него не только атрибутов, которые описывают состояние объекта, но и действий, которые с ним связаны, т. е. его поведение.

Модели данных на основе записей


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


  1. иерархическая модель данных (hierarchical data model);

  2. сетевая модель данных (network data model);

  3. реляционная модель данных (relation data model);

  4. объектно-ориентированная модель.

Физические модели данных
Физические модели данных описывают то, как данные хранятся в компьютере, предоставляя информацию о структуре записей, их упорядоченности и существующих путях доступа. Самыми популярными из физических моделей являются обобщающая модель (unifying model) и модель памяти кадров (frame memory).
Исторически первыми системами хранения и доступа были файловые структуры и системы управления файлами (СУФ), которые фактически являлись частью операционных систем. СУБД создавала над этими файловыми моделями свою надстройку, которая позволяла организовать всю совокупность файлов таким образом, чтобы она работала как единое целое и получала централизованное управление от СУБД. Однако непосредственный доступ осуществлялся на уровне команд операционной системы, которые СУБД использовала при манипулировании всеми файлами. Однако механизмы операционной системы не приспособлены для решения задач собственно СУБД, они разрабатывались просто для традиционной обработки файлов, и с ростом объемов хранимых данных они стали неэффективными для использования СУБД. Тогда постепенно произошел переход от базовых файловых структур к непосредственному управлению размещением данных на внешних носителях самой СУБД.
Для размещения данных на внешних носителях используют следующие типы файловых структур данных:

  • последовательные файлы;

  • прямые файлы;

  • библиотечные файлы;

  • индексно-последовательные файлы.

Для всех типов файлов возможны два основных режима их обработки:



  • последовательный;

  • произвольный (прямой).

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


В произвольном режиме (режиме прямого доступа) записи передаются в оперативную память и там обрабатываются в том порядке, в котором этого требует прикладная программа.
В последовательном файле доступ к составляющим его записям возможен только через указатель текущей записи, который отмечает запись, прочитанную или записанную последней. В таком файле «перебирать» записи можно только одну за другой, последовательно. Посредством буфера все записи последовательно переносятся в оперативную память для их обработки. Произвольный режим обработки как таковой невозможен, так как для поиска записи по какому-либо признаку необходимо провести последовательный перебор всех записей. Новые записи могут добавляться только в конец файла. Удаление записей выполняется путем создания нового файла, не содержащего удаленных записей.
В прямых файлах существует непосредственная связь между ключом записи и ее месторасположением на носителе. При занесении логической записи в файл выполняется преобразование или отображение ключа записи в адрес памяти, по которому запись будет размещена. Основной режим работы – произвольный. Возможен последовательный режим обработки данных. В режиме корректировки файла новые данные размещаются в соответствии со значением ключа. Удаленные записи помечаются символом удаления. пространство памяти, занятое удаленной записью, может использоваться под новую запись, получившую этот же адрес.
На практике обработка записей производится по нескольким полям. В этом случае преимущества прямых файлов практически сводятся на нет, поскольку в этих файлах обработка записей на основе произвольного доступа возможна только по одному ключевому полю.
Файл с библиотечной организацией (библиотечный файл, библиотека) состоит из последовательно организованных разделов, каждый из которых имеет свое имя и содержит одну или несколько логических записей. В начале файла размещается специальный служебный раздел, называемый оглавлением файла. К каждому разделу имеется прямой доступ через оглавление. Обработка данных в разделе осуществляется последовательным доступом. Возможно добавление и удаление разделов файла путем его преобразования.
Вместе с тем очевидно. Что одним из наиболее доступных способов повышения эффективности обработки данных является упорядочение записей в порядке убывания или возрастания значений конкретного поля. Такое упорядочение проводится, как правило, не в исходном файле, а в дополнительно создаваемом. Преобразованный по какому-либо полю (ключу) файл называется инвертированным. При обработке файла по нескольким ключам требуется создать соответствующее количество инвертированных файлов. Поскольку каждый инвертированный файл содержит ту же информацию, что и исходный файл, то это требует больших объемов внешней памяти. Инвертированный файл обрабатывается в последовательном режиме.
Для повышения скорости обработки данных, хранимых в БД, используются индексно-последовательные файлы. Индексно-последовательный файл представляет собой совокупность файла данных и одного или нескольких индексных файлов. Индексный файл представляет собой инвертированный файл, в котором хранятся не сами исходные данные, а номера (индексы) записей исходного файла, определяющие порядок обработки исходного файла по определенному ключу. Индексный файл обрабатывается в последовательном режиме, а файл данных – прямым доступом.
Добавление записей осуществляется, как правило, в конец файла данных. Вновь добавляемой записи присваивается атрибут «активная». Если СУБД поддерживает режим замещения удаленных записей, то добавление новых записей может выполняться и на место удаленных. Но в любом случае индексный файл должен быть перестроен (выполнена переиндексация).
При удалении записей выполняется процедура, так называемого, логического удаления, когда запись остается в БД, но значение атрибута изменено с «активная» на «удалена». Для физического удаления записей выполняется процедура преобразования (сжатия) БД. И в том, и в другом случае индексный файл должен быть перестроен.
Таким образом, каждая запись, находящаяся в БД, называется физическая, но она может быть либо активной, либо удаленной.
При корректировке данных, затрагивающих ключевые поля, индексные файлы необходимо перестроить. Если же корректировка данных выполнялась в неключевых полях, то переиндексацию выполнять нет необходимости.
Поскольку одним из компонентов модели данных является структура, рассмотрим основные известные структуры данных.

Структуры данных

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




  1. Порядок следования элементов линейных структур имеет линейный характер и соответствует порядку расположения элементов в памяти: один за другим без каких-либо промежутков. Адрес элемента соответствует его положению и определяется индексом – порядковым номером элемента в последовательности размещения. К элементу имеется прямой доступ, если известен его индекс.

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




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




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




  1. Таблица – последовательность, представляемая строками – совокупностями разнотипных элементов. Таблица – это множество записей, каждая из которых представляет набор поименованных полей.

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


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


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




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

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


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


  1. перекрестные;

  2. боковые;

  3. иерархические;

  4. множественные.


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


    1. Деревья. Дерево (рис. 1) представляет собой иерархию элементов, называемых узлами. На самом верхнем уровне иерархии имеется только один узел – корень, являющийся входом в структуру. Каждый узел, кроме корня, связан с одним узлом на более высоком уровне, называемым исходным узлом для данного узла. Каждый элемент имеет только один исходный. Каждый элемент может быть связан с одним или несколькими элементами на более низком уровне, которые называются порожденными. Между исходным узлом и порожденными узлами имеется отношение «один – ко – многим». Связи между узлами называются дугами или ребрами. Между двумя узлами может быть только одна связь. Любая часть дерева, исходящая из одного узла (кроме корня), называется ветвью. Элементы, расположенные в конце ветви, т. е. не имеющие порожденных, называются листьями.




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



рис. 2.

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



  • найти указанное дерево БД (например, отдел с заданным номером);

  • перейти от одного дерева к другому;

  • перейти от одной записи к другой внутри дерева (например, от отдела к первому сотруднику);

  • перейти от одной записи к другой в порядке обхода иерархии;

  • вставить новую запись в указанную позицию;

  • удалить текущую запись.

Система IMS (Information Management System) является самой первой коммерческой СУБД, она до сих пор остается основной иерархической СУБД, используемой на большинстве крупных мейнфреймах. Эта система появилась в качестве программного обеспечения для осуществления проекта полета корабля Apollo на Луну. Основная идея этой системы была построена на том, что малые компоненты объединяются вместе как части более крупных компонентов до тех пор, пока не будет собран воедино весь проект. Т. е. использовалась иерархическая структура.


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


        1. Иерархическая модель данных не дает адекватных средств для явного указания ограничений, накладываемых на данные.




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




        1. Трудность моделирования связей типа «многие – ко – многим». Включение связей такого типа приводит к необходимости дублирования данных.

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


На иерархической модели данных основано сравнительно ограниченное количество СУБД, в числе которых можно назвать зарубежные системы IMS, PC/Focus, Team-Up и data Edge, а также отечественные системы Ока, ИНЭС и МИРИС.
Сетевые модели данных


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




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



рис. 4.

Типичные операции в сетевой модели:



  • найти следующую запись данного типа и сделать ее текущей;

  • извлечь запись в буфер прикладной программы для обработки;

  • заменить в записи значения указанных элементов данных;

  • запомнить запись из буфера в БД.

Первая сетевая структура появилась в середине 60-х годов прошлого века. Это была система IDS (Integrated Data Store) фирмы General Electric. Сетевая СУБД создавалась для представления более сложных взаимосвязей между данными, чем те, которые можно было моделировать с помощью иерархических структур.


Наибольшее распространение среди сетевых моделей получила модель КОДАСИЛ (CODASYL Conference on Data System Language – Ассоциация по языкам систем обработки данных), предложенная Рабочей группой по БД (DBTG – Data Base Task Group). Эта модель считается наиболее развитой сетевой моделью данных, постоянно развивается, поддерживается и сопровождается, являясь стандартом. Основная цель КОДАСИЛ – создание сетевой модели, позволяющей описывать отношения М:М, т.е. уменьшить недостатки иерархической модели.
Недостатки сетевой модели данных:


        1. Обладает ограниченной гибкостью по отношению к изменению требований к данным и методам доступа.




        1. Доступ к данным осуществляется путем перемещения (навигации) по структуре.




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

Системы на основе сетевой модели не получили широкого распространения на практике. Наиболее известными сетевыми СУБД являются следующие: DSM (корпорация UNIVAC), IDMS (Cullinane), DBMS (DEC), IDS (Honeywell), db_VistaIII, СЕТЬ, СЕТОР и КОМПАС.


Иерархическая и сетевая модели считаются моделями БД первого поколения. Помимо перечисленных выше их недостатков этим двум моделям присущи общие недостатки:


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




  1. Независимость от данных существует лишь в минимальной степени.




  1. Отсутствие общепризнанных теоретических основ.

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


Реляционная модель данных
Реляционная модель базируется на теоретико-множественном понятии отношения. В математических дисциплинах существует понятие «отношение» (relation), физическим представлением которого является таблица. Отсюда и произошло название модели – реляционная.
Применительно к БД понятия «реляционная БД» и «табличная БД» являются синонимами. Реляционные базы получили наибольшее распространение в мире. Почти все продукты БД, созданные с конца 70-х годов, являются реляционными.
В 1970 году появились работы, в которых обсуждались возможности применения различных табличных моделей данных. Наиболее значительной из них была статья сотрудника фирмы IBM д-ра Э. Кодда (Codd E.F., A Relational Model of Data for Large Shared Data Banks (Реляционная модель данных для больших совместно используемых банков данных). CACM 13: 6, June 1970), где впервые был применен термин "реляционная модель данных". Проект System R был разработан в исследовательской лаборатории корпорации IBM. Этот проект был задуман с целью доказать практичность реляционной модели. Реляционные СУБД относятся к СУБД второго поколения.
Цели создания реляционной модели данных:


  1. Обеспечение более высокой степени независимости от данных.

  2. Создание прочного фундамента для решения проблем непротиворечивости и избыточности данных.

  3. Расширение языков управления данными за счет включения операций над множествами.

Коммерческие системы на основе реляционной модели данных начали появляться в конце 70-х – начале 80-х годов. В настоящее время существует несколько сотен типов различных реляционных СУБД.


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


  1. реляционная БД – набор нормализованных отношений;

  2. отношение – файл, плоская таблица, состоящая из столбцов и строк; таблица, в которой каждое поле является атомарным;

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

  4. универсум – совокупность значений всех полей или совокупность доменов;

  5. кортеж – запись, строка таблицы;

  6. кардинальность - количество строк в таблице;

  7. атрибутыпоименованные поля, столбцы таблицы;

  8. степень отношения - количество полей (столбцов);

  9. схема отношения – упорядоченный список имен атрибутов;

  10. схема реляционной БД – совокупность схем отношений;

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

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


Правило целостности объектов утверждает, что первичный ключ не может быть полностью или частично пустым.
Соотношение этих понятий иллюстрируется на рис. 5.

Универсум





Первичный


ключ

Домены

Отношение










ФИО

Год рожд.

Должность

Кафедра



Иванов И. И.

1958

Зав. каф.

22



Сидоров С. С.

1963

Проф.

22



Андреева Г. Г.

1955

Проф.

22



Цветкова С. С.

1960

Доцент

22



Козлов К. К.

1959

Доцент

22



Петров П. П.

1960

Ст. преп.

22

Атрибуты



Степень


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


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


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


    • имеет имя, которое отличается от имен всех других таблиц;

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

    • все столбцы в таблице однородные, т.е. все элементы в столбце имеют одинаковый тип (числовой, символьный и т.д.) и длину;

    • каждый столбец имеет уникальное имя;

    • одинаковые строки в таблице отсутствуют;

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

Концепция реляционной модели определяется следующими 12 правилами


Кодда
:


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

В пользу этого правила имеется два довода:



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

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




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

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




      1. Правило систематической трактовки недействительных Null-значений. В РБД должна быть реализована поддержка недействительных значений (NULL), которые отличаются от строки символов нулевой длины, строки пробельных символов, от нуля или любого другого числа и используются для представления отсутствующих данных независимо от типа этих данных.


Null-значение – это специальное значение, применяемое в БД для обозначения «неизвестных» данных.
Существует проблема: как трактовать Null-значения при использовании в запросах к РБД логических выражений? Считывать эти строки в запросе или пропускать?
Когда СУБД оценивает Null-значение на соответствие логическому критерию, она не может точно определить, отвечает ли этому критерию строка, содержащая Null-значение. Может быть, да, а может быть, и нет. По этой причине говорят, что в РБД используется трехзначная логика. Результатом оценки логического выражения является или «истина», или «ложь», или «может быть». Чаще всего строки с Null-значениями не считываются в запросах.


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

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




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

        • определение данных;

        • определение представлений;

        • обработку данных;

        • условия целостности;

        • идентификацию прав доступа;

        • границы транзакций (начало, завершение и отмена).

Язык SQL вполне отвечает всем этим требованиям.




      1. Правило обновления представлений (видов, View). Все представления, которые теоретически можно обновить, должны быть доступны для обновления самой системе.

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




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

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




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

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




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

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


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


      1. Правило независимости условий целостности. Должна существовать возможность определять условия целостности, специфичные для конкретной РБД, на подъязыке РБД и хранить их в каталоге, а не в прикладной программе.

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


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


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

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




      1. Правило единственности (соблюдения правил) («правило, запрещающее обман»). Если в реляционной системе есть низкоуровневый язык, обрабатывающий одну запись за один раз, то его нельзя использовать для того, чтобы обойти правила и условия целостности, выраженные на реляционном языке высокого уровня, обрабатывающем несколько записей за один раз. Т. е. с БД необходимо работать только с помощью языка БД, поскольку это может нарушить ее целостность. Нельзя обходить ограничения, введенные с помощью языка SQL.

Согласно Дейту, реляционная модель состоит из трех частей:



  • структурной части;

  • целостной части;

  • манипуляционной части.

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


Целостная часть описывает ограничения специального вида, которые должны выполняться для любых отношений в любых реляционных БД. Это целостность сущностей и целостность внешних ключей.
Манипуляционная часть описывает два эквивалентных способа манипулирования реляционными данными – реляционную алгебру и реляционное исчисление.
Достоинство реляционной модели данных заключается в простоте, понятности и удобстве физической реализации на ЭВМ. Именно простота и понятность для пользователя явились основной причиной их широкого использования. Проблемы же эффективности обработки данных этого типа оказались технически вполне разрешимыми.
Основными недостатками реляционной модели являются следующие: отсутствие стандартных средств идентификации отдельных записей и сложность описания иерархических и сетевых связей.
Примерами зарубежных реляционных СУБД для ПЭВМ являются следующие: dBaseIII Plus и dBaseIY, DB2, Paradox и dBase for Windows, Visual FoxPro и Access, Clarion, Ingres и Oracle.
Реляционная модель данных (РМД) отличается от сетевой и иерархической следующими положениями:


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

  2. Логическими ключевыми указателями. РМД использует первичные ключи для представления отношений между двумя записями, так как данная модель отличается независимостью исполнения. Однако, предполагается, что физическая БД (полностью скрытая от пользователя) может использовать адреса указателей и т.д.

  3. Высокоуровневыми языками программирования (ЯП). Эти языки манипулируют данными как файлом, а не только одной записью.


Выводы: Таким образом, иерархическая, сетевая и реляционная модели данных различаются в основном способами информационного отображения объектов и их взаимосвязей.
Реляционная и иерархическая модели данных реализуют только линейную структуру таблиц, тогда как сетевая и объектно-ориентированная модели позволяют использовать и нелинейную структуру.
По сути, понятия «исходный» и «порожденный» элемент в иерархических и сетевых моделях, «первичный» и «внешний» ключ в реляционной модели передают одно и то же явление – наличие связи «один – ко – многим» между записями соответствующих файлов.
При использовании иерархической и сетевой моделей от пользователя требуется знание физической организации БД, к которой он должен осуществлять доступ, в то время как при работе с реляционной моделью независимость от данных обеспечивается в значительно большей степени. Следовательно, если в реляционных системах для обработки информации в БД принят декларативный подход (т. е. они указывают, какие данные следует извлечь), то в сетевых и иерархических системах – навигационный подход (т. е. они указывают, как их следует извлечь).
Реляционная модель БД также обладает некоторыми недостатками - ограниченными возможностями моделирования. Для решения этой проблемы был выполнен большой объем исследовательской работы. В 1976 году Чен предложил модель «сущность – связь». В 1979 году Кодд сделал попытку устранить недостатки собственной модели и предложил расширенную версию реляционной модели.
Кроме традиционных моделей данных (иерархическая, сетевая, реляционная) в последние годы появились и стали более активно внедряться на практике следующие модели данных:

  • постреляционная;

  • многомерная – разновидность реляционной модели.

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





Каталог: upload -> iblock -> 549
iblock -> Часы-смартфон
iblock -> Руководство пользователя для телефона Apple iPhone 6
iblock -> Руководство по эксплуатации Методика калибровки Технические характеристики. Минимальный радиус кривизны поверхностей контролируемых изделий, 6мм
iblock -> Технические требования
iblock -> Технологические карты
iblock -> Оптимизация процесса восстановления измененных и уничтоженных маркировочных обозначений на блоках двигателей транспортных средств
iblock -> Инструкция по эксплуатации Температурный gsm извещатель Grinson T7 Благодарим Вас за выбор температурного gsm извещателя Grinson T7
549 -> Гост 4011-72 Вода питьевая. Методы измерения массовой концентрации общего железа


Поделитесь с Вашими друзьями:
1   2   3   4   5   6   7   8   9


База данных защищена авторским правом ©vossta.ru 2019
обратиться к администрации

    Главная страница