История развития систем управления базами данных. Объектно-ориентированный подход к проектированию баз. Совместная упаковка данных и кода для их обработки. Объектно-реляционные шлюзы. Язык объектных запросов. Средства обеспечения целостности объектов.
Аннотация к работе
Поэтому история развития компьютеров тесно связана с таким направлением деятельности человека как программирование и представляет собой историю непрерывного движения от языка и уровня коммуникации машины к уровню пользователя. На начальном этапе применялись так называемые языки низкого уровня (машинные языки и машинно-ориентированные языки), которые требовали указания мелких деталей процесса обработки данных. Они более удобны для человека и делятся на: · процедурные (алгоритмические) (Basic, Pascal, C и др.), которые предназначены для однозначного описания алгоритмов; для решения задачи процедурные языки требуют в той или иной форме явно записать процедуру ее решения; · логические (Prolog, Lisp и др.), которые ориентированы не на разработку алгоритма решения задачи, а на систематическое и формализованное описание задачи с тем, чтобы решение следовало из составленного описания; История развития систем управления базами данных (СУБД), в свою очередь, начиналась с модели записей и индексов (ISAM и др.), позднее приобретя способность восстановления после сбоев, проверки целостности данных и возможности работы нескольких пользователей одновременно.Объектно-ориентированный подход при создании систем управления базами данных дает возможность упаковывать вместе данные и код для их обработки. Компромиссным является комбинированный подход, который дает возможность пользователям воспользоваться достоинствами объектно-ориентированных баз данных, не отказываясь при этом полностью от своих реляционных баз данных. Такие компромиссные решения дают возможность поддержать баланс между объектами и реляционными таблицами. Например, объектно-реляционный адаптер Odapter фирмы Hewlett-Packard для СУБД Oracle, можно с успехом применять во многих областях, например в качестве связующего программного обеспечения, которое объединяет объектно-ориентированные приложения с реляционными базами данных. Некоторые из существующих объектных СУБД, например GEMSTONE, могут сами выступить в роли объектно-реляционного адаптера, тем самым давая возможность объектно-ориентированным приложениям обращаться к реляционным базам данных.В состав этой группы в настоящее время входят компании Sun Microsystems, EXCELON Corporation, Objectivity Inc., POET Software, Computer Associates и Versant Corporation. · Язык объектных запросов (Object Query Language - OQL). В период между выпусками версий 2.0 и 3.0 группа ODMG расширила свой устав и включила в него разработку спецификаций универсальных стандартов хранения объектов. Стандарт на хранение объектов ODMG разработан на основе трех существующих стандартов: управление базами данных (SQL), объекты (стандарты OMG - Object Management Group) и стандарты на объектно-ориентированные языки программирования (C , Smalltalk, Java). ODMG добавляет возможности взаимодействия с базами данных в объектно-ориентированные языки программирования: определяются средства долговременного хранения объектов и расширяется семантика языка, вносятся операторы управления данными.Рассмотрим преимущества и недостатки, которыми обладают объектно-ориентированные СУБД. Объектно-ориентированные базы данных (ODBMS - Object-oriented Database Management System) применяют с конца 1980-х для обеспечения управления БД приложений, которые построены в соответствии с концепцией объектно-ориентированного программирования. В объектном программировании для улучшения сохранности целостности данных и повторного применения кода, данные и код для их обработки организуются в объекты. Тогда как в объектно-ориентированной СУБД каждая определенная пользователем структура является объектом, который непосредственно управляется базой данных. В объектно-ориентированной СУБД пользователь просто объявляет связь, и далее СУБД автоматически генерирует методы управления, динамически создавая, удаляя и пересекая связи.Например, при небольшом количестве пользователей, длинных транзакциях и малой загрузке сервера объектно-ориентированные СУБД не требуют поддержки сложных механизмов резервного копирования/восстановления данных Связано это с тем, что исторически первые объектно-ориентированные БД были спроектированы для поддержки небольших рабочих групп (порядка десяти человек) и не были приспособлены для обслуживания сотен пользователей. Однако надо учитывать, что при такой модели объект с ошибкой может повредить объекты и разрушить базу данных. Большинство СУБД передают приложению указатели на объекты, и с неизбежностью такие указатели обязательно со временем становятся неверными. Если же приложение попытается использовать указатель в неподходящий для этого момент, то в лучшем случае произойдет крах СУБД, а в худшем случае будет потеряна информация в середине другого объекта и нарушится целостность БД. СУБД добавляет дополнительный указатель и в случае необходимости, если объект перемещается, то система может автоматически разрешить ситуацию (перезагрузить, если это необходимо, объект) без возникновения конфликтной ситуации.