Нефть и песок О стали Компрессор - подбор и ошибки Из истории стандартизации резьб Соперник ксерокса - гектограф Новые технологии производства стали Экспорт проволоки из России Прогрессивная технологическая оснастка Цитадель сварки с полувековой историей Упрочнение пружин Способы обогрева Назначение, структура, характеристики анализаторов Промышленные пылесосы Штампованные гайки из пружинной стали Консервация САУ Стандарты и качество Технология производства Водород Выбор материала для крепежных деталей Токарный резец в миниатюре Производство проволоки Адгезия резины к металлокорду Электролитическое фосфатирование проволоки Восстановление корпусных деталей двигателей Новая бескислотная технология производства проката Синие кристаллы Автоклав Нормирование шумов связи Газосварочный аппарат для тугоплавких припоев
Главная страница / Архитектура отрасли

Основные вехи в развитии СУБД

Условно к базам данным могут быть отнесены десктопные (настольные) приложения, которые широко применяются при работе на персональных компьютерах, в том числе xBase и Paradox, 1-2-3 и Excel таблицы и другие файловые структуры, хранящие данные.

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

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

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

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

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

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

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

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

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

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

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

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

Постепенно акцент с использования реляционных систем в домашних компьютерах смещается на их применение в мейнфреймах. Реляционные системы также единственные системы, которые способны обеспечить реальную распределенную базу данных. Реляционные и распределенные системы одновременно становятся популярными. Это уже более мощные системы типа Oracle, SyBase, Informix и Ingres.

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

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

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

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

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

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

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

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

Появление объектно-ориентированного подхода в программировании привело к тому, что перед базами данных была поставлена новая задача: хранение в базах данных элементов объектно-ориентированной технологии. Разработчики программного обеспечения предложили, их решения, как создание чисто объектно-ориентированных баз (GemStone, Object Store, Object Database и т. д.) и расширение уже имеющихся реляционных моделей, так называемых объектно-реляционных конструкций. Такую возможность предоставляет, например, расширение Оracle.

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

Главная страница / Архитектура отрасли