Системы управления базами данных.(субд)

В банках данных обычно применяется одны из следующих моделей данных:

1. Реляционная

2. Иерархическая

3. Сетевая

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

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

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

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

В сетевой модели наряду с вертикальными допускаются и горизонтальные связи.

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

Субд реляционного типа.

К числу СУБД, предназначенных для персональных ЭВМ относят семейство “Fox Pro”, ”dBase”, “Paradox”, “Clipper”. В этих СУБД записи и соответственно поля обычно имеют фиксированную длину от 4 до 5000 байт, число полей вирируется от 128 до 1024. Большинство СУБД реляционного типа позволяют создавать БД числом записей до одного миллиарда и объемом до двух гигабайт. Обычно в состав СУБД, предназначенных для работы на ПК входят три основных компонента:

1. Командный язык

2. Интерпретирующая система или компилятор для преобразования команд к выполнимому виду

3. Средство взаимодействия пользователя с СУБД (интерфейс пользователя)

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

Интерпретирующая система и компилятор – два принципиально разных способа преобразования команд к исполнимому виду. Интерпретирующая система преобразует поочередно команды в исполнимый вид перед их непосредственным выполнение (“Fox Pro”, ”dBase”, “Paradox”). Во втором способе сначала вся исходная программа преобразуется в программу из исполнимых машинных команд, а затем эта программа выполняется. (СУБД “Clipper”)

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

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

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

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

В задачах обработке информации, основанных на системах БД, существует два варианта расположения данных:

1. Локальное

2. Удаленное

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

Удаленные данные располагаются вне компьютера пользователя либо на файловом сервере сети, либо на специально выделенном для этих целей компьютере. Существует две технологии или архитектуры обработке удаленных данных. Это файл - серверная архитектура и архитектура клиент – сервер.

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

Построение банка данных САПР – сложная задача, обусловленная следующими особенностями САПР:

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

2. Нередко обмены должны происходить с высокой частотой, предъявляет жесткие требования к быстрому обмену

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

4. Транзакции могут быть длительными и трудоемкими. Транзакцией называют последовательность операций по удовлетворению запроса. В САПР транзакции могут включать в себя очень трудоемкие операции в результате могут длится даже несколько часов

5. Иерархическая структура проектных данных и следовательно отражение на следование в целях сокращения объема БД.

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