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

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

К основным понятиям иерархической структуры относятся: уровень, элемент (узел), связь. Узел — это совокупность атрибутов данных, описывающих некоторый объект. На схеме иерархического дерева узлы представляются вершинами графа. Каждый узел на более низком уровне связан только с одним узлом, находящимся на более высоком уровне. Иерархическое дерево имеет только одну вершину (корень дерева), не подчиненную ника­кой другой вершине и находящуюся на самом верхнем (первом) уровне. Зависимые (подчи ненные) узлы находятся на втором, третьем и т.д. уровнях. Количество деревьев в базе данных определяется числом корневых записей.

К каждой записи базы данных существует только один (иерархический) путь от корневой записи.

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

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

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

Понятие реляционный (англ. relation — отношение) связано с разработками известного аме риканского специалиста в области систем баз данных Е. Кодда.

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

Реляционная модель ориентирована на организацию данных в виде двумерных таб лиц. Каждая реляционная таблица представляет собой двумерный массив и обла дает следующими свойствами:

· каждый элемент таблицы — один элемент данных;

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

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

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

· порядок следования строк и столбцов может быть произвольным.

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

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

Чтобы связать две реляционные таблицы, необходимо ключ первой таблицы ввести в состав ключа второй таблицы (возможно совпадение ключей); в противном случае нужно ввести в структуру первой таблицы внешний ключ — ключ второй таблицы.

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

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

Информационный объект — это информационное описание некоторой сущности — реального объекта, процесса, явления или события. Информационный объект образуется совокупностью логически взаимосвязанных реквизитов, представляющих качественные и количественные характеристики некоторой сущности предметной области. Примерами информационных объектов могут быть — ТОВАР, ПОСТАВЩИК, ЗАКАЗЧИК, ПОСТАВКА, ОТГРУЗКА, СОТРУДНИК, ОТДЕЛ, СТУДЕНТ, ПРЕПОДАВАТЕЛЬ, КАФЕДРА и т.п.

Информационные объекты выделяются на основе описания предметной области путем определения функциональных зависимостей между реквизитами. Совокупность реквизитов информационного объекта должна отвечать требованиям нормализации. Каждому информационному объекту нужно присвоить уникальное имя, например, СТУДЕНТ, ПРЕДМЕТ, ПРЕПОДАВАТЕЛЬ, КАФЕДРА.

Информационный объект имеет множество реализаций — экземпляров. Например, каждый экземпляр объекта СТУДЕНТ представляет конкретного студента. Экземпляр образуется совокупностью конкретных значений реквизитов и должен однозначно определяться (идентифицироваться) значением ключа информационного объекта, который состоит из одного или нескольких ключевых реквизитов. Таким образом, реквизиты подразделяются на ключевые и описательные. Последние являются функционально зависимыми от ключа. Функциональная зависимость реквизитов имеет место в том случае, если одному значению ключа соответствует только одно значение описательного (зависимого) реквизита.

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

Исключить дублирование информации в таблицах.

Обеспечить возможность изменений в структуре таблиц.

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

Процесс нормализации состоит из нескольких этапов. Первые три из них, выполняемых чаще всего, были описаны в 1972 году доктором Коддом

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

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

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

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

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

Существуют следующие типы информационных связей: 

• один-к-одному; 

• один-ко-многим; 

• многие-ко-многим. 

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

28 вопрос. . Требования, предъявляемые к базе данных.

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

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

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

• учет интересов всех потенциальных пользователей систем;

•  модульный принцип разработки и внедрения.

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

1. Установить, каким специалистам и в каких подразделениях предприятия необходима информация о конкретном информаци онном объекте.

2. Установить признаки описания объектов различными пользо вателями.

3. Установить общий состав признаков объектов одного класса.

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

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

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

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

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

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

• информационный;

• программный;

• аппаратный.

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

компьютером.

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

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

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