Настольные СУБД

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

Настольные СУБД

Курсовой проект

Компьютеры, программирование

Другие курсовые по предмету

Компьютеры, программирование

Сдать работу со 100% гаранией

Введение

 

Лет двадцать назад обработка данных происводилась с помощью мэйнфреймов и мини-ЭВМ и имела свои преимущества, в определенной степени утраченные позже, в эпоху персональных компьютеров и настольных СУБД. К ним, в частности, относились:

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

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

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

1.Настольные СУБД

 

1.1. Основы работы настольных СУБД

 

Многие авторы классифицируют СУБД на две большие категории: «настольные» и «серверные».

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

Работа построена следующим образом:

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

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

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

 

1.2. Наиболее популярные настольные СУБД

 

На сегодняшний день известно более двух десятков форматов данных настольных СУБД, однако наиболее популярными, исходя из числа проданных копий, следует признать dBase, Paradox, FoxPro и Access. Из появившихся недавно СУБД следует также отметить Microsoft Data Engine - по существу серверную СУБД, представляющую собой <облегченную> версию Microsoft SQL Server, но предназначенную, тем не менее, для использования главным образом в настольных системах и небольших рабочих группах.

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

СУБДПроизводительURLVisual dBasedBase, Inchttp://www.dbase2000.com/ParadoxCorelhttp://www.corel.com/Microsoft Access 2000Microsofthttp://www.microsoft.com/Microsoft FoxProMicrosofthttp://www.microsoft.com/Microsoft Visual FoxProMicrosofthttp://www.microsoft.com/Microsoft Visual FoxProMicrosofthttp://www.microsoft.com/Microsoft Data EngineMicrosofthttp://www.microsoft.com/

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

 

dBase и Visual dBase

 

Первая промышленная версия СУБД dBase - dBase II (принадлежащая тогда компании Ashton-Tate, приобретенной позже компанией Borland) появилась в начале 80-х годов. Благодаря простоте в использовании, нетребовательности к ресурсам компьютера и, что не менее важно, грамотной маркетинговой политике компании-производителя этот продукт приобрел немалую популярность, а с выходом следующих его версий - dBase III и dBase III Plus (1986 г.), оснащенных весьма комфортной по тем временам средой разработки и средствами манипуляции данными, быстро занял лидирующие позиции среди настольных СУБД и средств создания использующих их приложений.

Хранение данных в dBase основано на принципе <одна таблица - один файл> (эти файлы обычно имеют расширение *.dbf). MEMO-поля и BLOB-поля (доступные в поздних версиях dBase) хранятся в отдельных файлах (обычно с расширением *.dbt). Индексы для таблиц также хранятся в отдельных файлах. При этом в ранних версиях этой СУБД требовалась специальная операция реиндексирования для приведения индексов в соответствие с текущим состоянием таблицы.

Формат данных dBase является открытым, что позволило ряду других производителей заимствовать его для создания dBase-подобных СУБД, частично совместимых с dBase по форматам данных. Например, весьма популярная некогда СУБД FoxBase (разработанная Fox Software, Inc. и ныне принадлежащая Microsoft) использовала формат данных dBase для таблиц, однако форматы для хранения MEMO-полей и индексов были своими собственными, несовместимыми с dBase. Очень популярное в начале 90-х годов (и кое-где применяемое до сих пор) средство разработки Clipper компании Nantucket Corp (приобретенной впоследствии компанией Computer Associates) манипулировало как с данными формата dBase III (включая индексные файлы и файлы для MEMO-полей), так и с индексными файлами собственного формата.

Помимо популярного формата данных dBase является родоначальником и некогда популярного семейства языков программирования, получившего называние xBase. Все языки этого семейства, использующиеся и в FoxBase, и в Clipper, и в некоторых более поздних средствах разработки, таких как канувший в Лету CA Visual Objects фирмы Computer Associates, содержат сходный набор команд для манипуляции данными и являются по существу интерпретируемыми языками. В роли интерпретатора команд xBase выступает обычно либо среда разработки приложения на этом языке, либо среда времени выполнения, которую можно поставлять вместе с приложением. Отметим, что для скрытия исходного текста xBase-приложения подобные СУБД обычно содержат утилиты для псевдокомпиляции кода, который затем поставляется вместе со средой времени выполнения. В случае Clipper среда времени выполнения содержится в самом исполняемом файле (и сам Clipper формально считается компилятором), но тем не менее этот язык по существу также является интерпретируемым.

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

Отметим, однако, что для работы с данными формата dBase (или иных dBase-подобных СУБД) совершенно необязательно пользоваться диалектами xBase. Доступ к этим данным возможен с помощью ODBC API (и соответствующих драйверов) и некоторых других механизмов доступа к данным (например, Borland Database Engine, некоторых библиотек других производителей типа СodeBase фирмы Sequenter), и это позволяет создавать приложения, использующие формат данных dBase, практически с помощью любого средства разработки, поддерживающего один из этих механизмов доступа к данным.

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

Лучшие

Похожие работы

1 2 3 4 > >>