Базы данных (стр. 3 )

f.  Содержание большего объема полезной информации при том же объеме хранимых данных.

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

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

4.  Дружелюбность интерфейсов, малое время на обучение.

5.  Применение стандартов.

6.  Повышение эффективности с ростом масштабов системы.

7.  Возможность нахождения компромисса при противоречивых требованиях.

8.  Надежность хранения и защита данных:

a.  Защита данных от случайного и преднамеренного разрушения.

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

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

9.  Упрощение сопровождения системы за счет независимости от данных.

10.  Улучшенное управление параллельностью.

5.  Недостатки банков данных

Недостатки БнД вытекают из их достоинств.

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

2.  Высокие требования к квалификации разработчиков БнД.

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

4.  Более серьезные последствия при выходе системы из строя.

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

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

В конце 60-х годов прошлого века появились БД для meinfraimов, основным принципом организации которых была централизация хранения и обработки данных.

Первые настольные СУБД появились около 20 лет назад (с появлением и использованием ПК). Они как таковые не содержали специальных приложений и сервисов, управляющих данными, — взаимодействие с ними осуществлялось с помощью файловых сервисов операционной системы. Нередко подобные СУБД имели в своем составе и средства разработки, ориентированные на работу с данными формата, характерного для этой СУБД, и позволяющие создать более или менее комфортный пользовательский интерфейс. Что же касается обработки данных — она целиком и полностью осуществлялась в пользовательском (клиентском) приложении.

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

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

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

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

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

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

БД подразделяются на централизованные и распределенные. Централизованная БД хранится в памяти одной вычислительной системы. Распределенная БД состоит из нескольких пересекающихся частей, хранимых в различных ЭВМ вычислительной сети.

Вопросы для самоконтроля

1.  Перечислите экономико-правовые классификационные признаки банков данных.

2.  Перечислите признаки классификации баз данных.

3.  Перечислите признаки классификации СУБД.

4.  Каковы недостатки использования банков данных?

5.  Каковы преимущества использования банков данных?

6.  Расскажите об этапах развития баз данных.

Тема 4. Модели данных.

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

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

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

«Модель данных» - средство моделирования; «модель БД» - результат разработки БД.

Модель данных можно рассматривать как сочетание трех компонентов:

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

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

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

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

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

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

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

В настоящее время имеется свыше 30 моделей представления данных. Их можно разделить на 2 группы:

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

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

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

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

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

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

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

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

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

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

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

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

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

В настоящее время ER-модель стала одним из основных методов концептуального проектирования БД.

Широко развивается объектно-ориентированная модель данных.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

b.  Деревья.

c.  Сетевые структуры.

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

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

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

рис. 4.1. Структура типа дерево.

Пример иерархической БД показан на рис. 4.2.

рис. 4.2. Пример иерархической БД.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4.  Сетевые модели данных

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

рис. 4.3. Сетевая модель данных.

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

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

Пример схемы простейшей сетевой БД показан на рис. 4. Типы связей обозначены надписями на соединяющих линиях.

рис. 4.4. Пример сетевой БД.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Реляционная модель базируется на теоретико-множественном понятии отношения. В математических дисциплинах существует понятие «отношение» (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-х годов. В настоящее время существует несколько сотен типов различных реляционных СУБД.

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

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

Основными понятиями, с помощью которых определяется реляционная модель, являются следующие:

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

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

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

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

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

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

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

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

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

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

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

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

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

Соотношение этих понятий иллюстрируется на рис. 4.5.

Атрибуты

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

Из за большого объема этот материал размещен на нескольких страницах: 1 2 3 4 5 6 7 8 9 10