Алматы
1998 г.Введение Внедрение ЭВМ во все сферы человеческой деятельности требует
от специалистов разного профиля овладения навыками использования вычислительной
техники. ...
Реферат
1. Краткая история WWW
2. Язык HTML - построение Web-документов:
а) шаблон Web-документа
б) форматирование текста
в) форматирование параграфов
г) работа с изображениями изображений:
I. фоновые изображения
II. статические и динамические изображения
III. изображения-ссылки
д) ссылки в документе:
I. ссылки на метки и на другие документы
е) фреймы:
I. Вертикальные фреймы
II. Горизонтальные фрейм
III. Вложенные фреймы
Альтернативные средства офрмления документов
1. Краткая история World Wide Web
Общеизвестно, что сеть Internet–это, в частности, громадное хранилище всевозможной информации. До появления службы World Wide Web (WWW) навигацию по Internet в поисках нужной информации нельзя было назвать удобной. Чтобы получить файл с FTP–сервера, приходилось отдельно загружать приложение–клиент. При этом нужно было помнить свой пароль, приходилось перемещаться по многочисленным каталогам в поисках нужного файла, не забывая перед его получением установить правильный режим передачи; знать многочисленные команды работы с FTP–серверами и т.д. Если же нужно было просмотреть какую–либо конференцию, то приходилось запускать уже другое приложение, у которого был свой набор команд для чтения, пересылки, сохранения сообщений из конференций. Все это было неудобно.
Около пяти лет назад была предпринята попытка организовать информационный порядок в сети Internet. Это привело к появлению службы World Wide Web (Всемирная Паутина), которая получила рождение в Европейском Центре Ядерных Исследований в Швеции. В основе идеи WWW лежат так называемые hypermedia документы или Web–документы, также называемые Web–страницами, призванные навести порядок в организации и поиске данных. Эти документы могут содержать как текстовую, так и не текстовую информацию (например, изображения, звук), а также ссылки. Ссылки – это указатели, с помощью которых можно свободно перемещаться из одного места документа в другое место, или же вообще ссылаться на отдельный документ, который может находиться на другом конце света. Хотя Web–документы могут содержать самую разную информацию, не только текстовую, их практически всегда называют гипертекстовыми (hypertext) документами, что в общем, не совсем верно.
На экране типичный Web–документ выглядит как набор текста со ссылками, могут присутствовать различные иллюстрации. Документ можно листать, просматривая содержимое, быстро перемещаться по нему или другим документам с помощью ссылок.
С появлением WWW сеть Internet стала обслуживать текст и графику, с помощью мыши стало возможным путешествовать по всему миру и легко находить нужную информацию с помощью простого указания и щелчка. Стало легко перекачивать файлы и читать конференции. Вот почему служба WWW приобрела всемирную популярность и получила большое распространение. Каждый день в сети Internet появляются в больших количествах Web–серверы и публикуются тысячи новых документов.
Для построения Web–документов в WWW используется специальный язык HTML, что означает HyperText Markup Language – язык гипертекстовой разметки, язык форматирования данных. Основанный на языке SGML (Standard Generalized Markup Language), язык HTML определяет форматирование и организацию данных в Web–документах. Он не определяет то, как точно будет размещен текст на экране, этот язык определяет структуру данных. Web–документ может содержать не только текстовую информацию, и поэтому язык HTML правильнее было бы называть HyperMedia Markup Language, однако в литературе практически всегда употребляется аббревиатура HTML. Документ, созданный на языке HTML – это обычный файл в ASCII–формате. В его основе лежат специальные дескрипторы (теги), которые и определяют форматирование данных в любом Web–документе. Естественно, для просмотра HTML–документов в World Wide Web необходимо специальное программное обеспечение. Такие программы называются броузерами (от англ. browse – листать, просматривать). С их помощью можно загружать и просматривать Web–странички, осуществлять навигацию по WWW и т.д. В настоящий момент существует довольно большое количество броузеров, из которых самыми популярными являются броузеры Microsoft Internet Explorer, Netscape Navigator и NCSA Mosaic. Броузер, прочитав HTML–файл, с помощью дескрипторов интерпретирует содержащиеся в документе данные и соответствующим образом отображает их на экране компьютера. На рис. 1 показан пример Web–документа:
Рис.1 Пример Web–документа
Язык HTML быстро развивается. В процессе своего развития он приобретал новые возможности и утрачивал мало использовавшиеся и устаревшие. В настоящий момент текущей официальной версией языка HTML является версия 3.2, обладающая развитыми средствами построения Web–документов. По сравнению с версией HTML 2.0 новая версия предлагает такие новые возможности, как таблицы, «обтекание» изображений текстом, встраивание апплетов Java и др. возможности.
На сегодняшний день кроме официальной версии языка также существуют версии HTML от фирм Microsoft и Netscape, которые также поддерживают и дополнительные возможности, не описанные в спецификации к официальной версии HTML. Чтобы решить проблему совместимости броузеров при отображении документов, составленных с использованием элементов неофициальных версий языка HTML, вышеупомянутые фирмы включают в свои продукты поддержку альтернативной версии языка. На подходе уже есть версия языка под номером 4.0, называемая Dynamic HTML, обещающая усовершенствованные старые и новые захватывающие возможности для оформления Web–документов. W3C (World Wide Web Consortium – организация по стандартам в World Wide Web) уже предлагает на рассмотрение эту версию языка как стандарт. Существуют варианты новой версии языка от фирм Microsoft и Netscape, которые, однако, пока несовместимы между собой. В настоящей работе раскрываются основные средства построения документов из языка HTML версии 3.2 фирмы Netscape Communications.
2. Язык HTML. Построение Web–документов
Как было сказано выше, форматирование документа на языке HTML задается специальными дескрипторами. Дескриптором называется команда форматирования данных и заключена эта команда в угловые скобки «<» и «>». Существуют открывающие и закрывающие дескрипторы, между которыми размещается текст, подлежащий форматированию. Открывающие дескрипторы задают способ форматирования, вторые его отменяют. Разница между такими дескрипторами заключается в том, что в закрывающем дескрипторе перед именем стоит косая черта. Например, дескрипторы ...
Система “Посредник”. Заключение договоров на поставку строительных материалов
Введение
В конце двадцатого века автоматизация всё сильнее завоёвывает все сферы
человеческой деятельности...
Министерство общего и профессионального образования Российской Федерации
Санкт-Петербургский государственный университет
Факультет географии и геоэкологии
Курсовая работа
По теме
«Обзор средств для автоматизации геодезических вычислений.
Программа Microsoft Excel. ...
Оъекгно-СУБД
Оглавление
1. 20 лет эволюции программного обеспечения.
2. Реляционные базы данных.
3. Объектно-реляционные методы.
4. Объектно-ориентированные базы данных.
4.1 Why ODBMS?
4.2 Спорные моменты технологии.
4.3 Стандарты объектных баз данных.
4.4 Поставщики ООСУБД.
5. Заключение.
6. Глоссарий
1.
2. 20 лет эволюциипрограммного обеспечения.
Рисунок 1
Управление информацией всегда было основной сферой применения компьютеров и,
надо думать, будет играть еще большую роль в будущем.Системы управления базами
данных[1] (СУБД, DBMS – Database Management System) на протяжении всего пути
развития компьютерной техники совершенствовались, поддерживая все более сложные
уровни абстрактныхданных, заданных пользователем, и обеспечивая взаимодействие
компонентов, распределенных в глобальных сетях и постепенно интегрирующихся
стелекоммуникационными системами. Позволив себе рассуждения в стиле Билла
Гейтса, предположим, что результатом будет становление систем
управленияинформацией одной из частей повседневной жизни каждого.
История развития компьютерной техники – это история непрерывного движения от
языка и уровня коммуникации машины к уровнюпользователя. Если первые машины
требовали от пользователя оформления того, что ему нужно (то есть написания
программ), в машинных кодах, то языкипрограммирования четвертого уровня (4GLs)
позволяли конечным пользователям, не являющимсяпрофессиональными программистами,
получать доступ к информации без детального описания каждого шага, но только с
встроенными предопределенными типами данных– например, таблицами.
Последним шагом в этом направлении стала объектно-ориентированная
технология,радикально изменившая сферу разработки программного обеспечения уже в
1990-х годах (Рисунок1). Объектно-ориентированный подход позволяет упаковывать
данные и код для их обработки вместе. Таким образом практически снимается
ограничение натипы данных, позволяя работать на любом уровне абстракции.
Эволюция систем управления информацией шла параллельно этому прогрессу, начиная
с низкоуровневых программ, которые, например, напрямуюпроизводили операции
чтения и записи со всей памятью без ограничения доступа, лентой, цилиндрами и
дорожками диска и более высокоуровневыми средствами –файловыми системами,
которые оперировали с такими понятиями, как массивы, записи и индексы для
повышения производительности. Базы данных в свою очередьначинали с модели
записей и индексов (ISAM и др.), приобретая со временем способность
восстановленияпосле сбоев, проверки целостности данных и возможности работы
нескольких пользователей одновременно. Эти ранние модели данных(CODASYL)
относились скорее к уровнюмашинной ориентации. В дальнейшем реляционные базы
данных, пришедшие на смену в 1980‑х годах, приобрели механизм запросов,
позволяющий пользователю указать требуемое, предоставив СУБД самой оптимальным
образом найти результат,используя динамическую индексацию.
Обьектно-ориентированные СУБД (ООСУБД) стали разрабатываться с середины 80‑х
годов восновном для поддержки приложений САПР. Сложные структуры данных систем
автоматизированного проектирования оказалось очень удобно оформлять в
видеобъектов, а технические чертежи проще хранить в базе данных, чем в файлах.
Это позволяет обойтись без декомпозиции графических структур на элементы и
записи их в файлы послезавершения работы с чертежом, выполнения обратной
операции при внесении любого изменения. Если типичные реляционные базы данных
имеют связи глубиной в двауровня, то иерархическая информация чертежей САПР
обычно включает порядка десяти уровней, что требует достаточно сложных операций
для “сборки”результата. Объектные базы данных хорошо соответствовали подобным
задачам, и эволюция многих СУБД началась именно с рынка САПР.
Между тем рынок САПР был быстро насыщен, и в начале 90‑х годов производители
ООСУБД обратили внимание на другие области применения, ужепрочно занятые
реляционными СУБД. Для этого потребовалось оснастить ООСУБД функциями
оперативной обработки транзакций (OLTP), утилитами администратора баз данных
(database administrator – DBA), средствами резервногокопирования/восстановления
и т. д. Работы в данном направлении продолжаются и сегодня, но уже можно
сказать, что переход к коммерческим приложениям идетдостаточно успешно.
3. Реляционные базы данных.
В реляционных базах данных (Relational Database System, RDBS) все данные
отображаются в двумерных таблицах. База данных, таким образом, это ни что
иное,как набор таблиц. RDBS и ориентированные на записи системы организованы на
основе стандарта B-Tree илиметоде доступа, основанном на индексации – Indexed
Sequential Access Method (ISAM) и являются стандартными
системами,использующимися в большинстве современных программных продуктов. Для
обеспечения комбинирования таблиц для определения связей между данными,
которыепрактически полностью отсутствуют в большинстве программных реализаций
B-Tree и ISAM, используется языки, подобные SQL (IBM), Quel (Ingres) и RDO
(Digital Equipment), причем стандартом отрасли внастоящее время стал язык SQL,
поддерживаемый всеми производителями реляционных СУБД.
Оригинальная версия SQL – это интерпретируемый язык, предназначенный для
выполненияопераций над базами данных. Язык SQL был создан в начале 70‑х как
интерфейс для взаимодействия с базами данных, основанными на новой для того
времениреляционной теории. Реальные приложения обычно написаны на других языках,
генерирующих код на языке SQLи передающих их в СУБД в виде текста в формате
ASCII. Нужно отметить также, что практически все реальные реляционные (и не
только реляционные) системы помимореализации стандарта ANSI SQL, известного
сейчас в последней редакции под именем SQL2 (или SQL-92), включают в себя
дополнительныерасширения, например, поддержка архитектуры клиент-сервер или
средства разработки приложений.
Строки таблицы составлены из полей, заранее известных базе данных. В большинстве
систем нельзя добавлять новые типы данных. Каждая строкав таблице соответствует
одной записи. Положение данной строки может изменяться вместе с удалением или
вставкой новых строк.
Чтобы однозначно определить элемент, ему должны быть сопоставлены поле или набор
полей, гарантирующих уникальность элемента внутритаблицы. Такое поле или поля
называются первичным ключом (primary key) таблицы и часто являются числами. Если
одна таблицасодержит первичным ключ другой, это позволяет организовать связь
между элементами разных таблиц. Это поле называетсявнешним ключом (foreign key).
Так как все поля одной таблицы должны содержать постоянное число полей заранее
определенных типов, приходится создавать дополнительныетаблицы, учитывающие
индивидуальные особенности элементов, при помощи внешних ключей. Такой подход
сильно усложняет создание сколько нибудь сложныхвзаимосвязей в базе данных.
Желающим убедится, что это действительно так и не пожалевшим на это
определенный отрезоквремени, компания POET Software любезно предоставляет
возможность ознакомиться с примером в своей “белой книге” “POET Technical
Reference”. База данных рядового предприятия общепита (клиенты – Джордж Буш и
Эдди Мэрфи) состоит изчетырех таблиц.
Еще один крупный недостаток реляционных баз данных – это высокая трудоемкость
манипулирования информацией и изменения связей.
4. Объектно-реляционные методы.
Несмотря на рассмотренные в п. 3 недостатки реляционных баз данных, они обладают
рядом достоинств:
разделение таблиц разными программами;
развернутый “код возврата” при ошибках;
высокая скорость обработки запросов (команда SELECTязыка SQL; результатом
выборки является таблица, которая содержит поля, удовлетворяющие заданному
критерию);
Рисунок 2 Возможные подходы к объединению объектных и реляционных БД.
сама концепция объектных баз данных довольно сложна итребует от программистов
серьезного и длительного обучения;
относительно высокая скорость при работе с большимиобъемами данных.
Кроме того, во всем мире значительные средства уже инвестированы в реляционные
СУБД. Многие организации не уверены, что затраты, связанные с переходом на
объектные базы данных, окупятся.
Поэтому многие пользователи заинтересованы в комбинированном подходе, который бы
им позволил воспользоваться достоинствами объектных базданных, не отказываясь
полностью от своих реляционных БД. Такие решения действительно существуют. Если
переход от реляционной базы к объектнойобходится слишком дорого, то применение
последней в качестве расширения и дополнения реляционных СУБД часто является
более экономичной альтернативой.Компромиссные решения позволяют соблюсти баланс
между объектами и реляционными таблицами (Рисунок2).
Объектно-реляционные адаптеры. Этот метод предполагает использование так
называемогообъектно-реляционного адаптера, который автоматически выделяет
программные объекты и сохраняет их в реляционных базах данных.
Объектно-ориентированныеприложение работает как рядовой пользователь СУБД.
Несмотря на некоторое снижение производительности, такой вариант позволяет
программистам целикомсконцентрироваться на объектно-ориентированной разработке.
Кроме того, все имеющиеся на предприятии приложения по-прежнему могут обращаться
к данным,хранящимся в реляционной форме.
Некоторые объектные СУБД, например GemStone компании GemStone Systems, могут
сами выполнятьроль мощного объектно-реляционного адаптера, позволяя
объектно-ориентированным приложениям обращаться к реляционным БД.
Объектно-реляционные адаптеры, такие как Odapter компании Hewlett-Packard для
СУБД Oracle, можно с успехом использовать вомногих областях, например в качестве
связующего ПО, объединяющего объектно-ориентированные приложения с реляционными
СУБД.
Объектно-реляционные шлюзы. При использовании такого метода пользователь
взаимодействует с БДпри помощи языка ООСУБД, а шлюз заменяет все
объектно-ориентированные элементы этого языка на их реляционные компоненты. За
это опять приходитьсярасплачиваться производительностью. Например, шлюз должен
преобразовать объекты в набор связей, сгенерировать оригинальные идентификаторы
(original identifier – OID) объектов и передать этов реляционную БД. Затем шлюз
должен каждый раз, когда используется интерфейс реляционной СУБД,
преобразовывать OID, найденный в базе, в соответствующий объект, сохраненный
вРСУБД.
Производительность в рассмотренных двух подходах зависит от способа доступа к
реляционной базе данных. Каждая РСУБД состоит из двухуровней: уровня управления
данными (data manager layer) и уровня управления носителем (storage manager
layer). Первый из нихобрабатывает операторы на языке SQL, а второй отображает
данные в базу. Шлюз или адаптер могут взаимодействовать какс уровнем данных (то
есть обращаться к РСУБД при помощи SQL), так и с уровнем носителя
(вызовамипроцедур низкого уровня). Производительность в первом случае намного
ниже (например, система OpenODBфирмы Hewlett-Packard, которая может выполнять
роль шлюза, поддерживает только на высоком уровне).
Гибридные СУБД. Еще одним решением может стать создание гибридных
объектно-реляционных СУБД,которые могут хранить и традиционные табличные данные,
и объекты. Многие аналитики считают, что будущее за такими гибридными БД.
Ведущие поставщикиреляционных СУБД начинают (или планируют) добавлять к своим
продуктам объектно-ориентированные средства. В частности, Sybase и Informix
собираются в следующих версияхСУБД ввести поддержку объектов. Подобные
разработки намерены вести и независимые фирмы. Например, компания Shores
готовится оснастить объектно-ориентированными средствамиСУБД Oracle8, выпуск
которой намечен на конец 1996 г.
С другой стороны, производители объектных СУБД, такие как компания Object
Design,сознают, что объектно-ориентированные базы данных в обозримом будущем не
заменят реляционные СУБД. Это вынуждает их создавать шлюзы для
поддержкиреляционных и иерархических баз данных иди различного рода интерфейсы,
характерным примером которых является объектно-реляционный интерфейс Ontos
Integration Server фирмы Ontos, применяемый всочетании с ее ООБД Ontos/DB.
5. Объектно-ориентированные базы данных.
5.1Why ODBMS?
“Белыми книгами” с названием, вынесенным в заголовок, с избытком снабдит любая
компания, занимающаяся объектными базами данных. Кое-чтоо преимуществах и
недостатках объектно-ориентированных СУБД уже упоминалось выше, подведем в таком
случае итог.
Объектно-ориентированные базы данных применяются с конца 1980-х для обеспечения
управления базами данных приложениями, построенными всоответствии с концепцией
объектно-ориентированного программирования. Объектная технология расширяет
традиционную методику разработки приложений новыммоделированием данных и
методами программирования. Для повторного использования кода и улучшения
сохранности целостности данных в объектном программированииданные и код для их
обработки организованы в объекты. Таким образом, практически полностью снимаются
ограничения на типы данных.
Если данные состоят из коротких, простых полей фиксированной длины (имя, адрес,
баланс банковского счета), то лучшим решением будетприменение реляционной базы
данных. Если, однако, данные содержат вложенную структуру, динамически
изменяемый размер, определяемые пользователемпроизвольные структуры
(мультимедиа, например), представление их в табличной форме будет, как минимум,
непростым. В то же время в ООСУБД каждая определеннаяпользователем структура –
это объект, непосредственно управляемый базой данных.
В РСУБД связи управляются пользователем, создающим внешние ключи. Затем для
обнаружения связей динамически во время выполнения системапросматривает две (или
больше) таблицы, сравнивая внешние ключи до достижения соответствия. Этот
процесс, называемый объединением (join), является слабой сторонойреляционной
технологии. Более двух или трех уровней объединений – сигнал, чтобы искать
лучшее решение. В ООСУБД пользователь просто объявляет связь, и
СУБДавтоматически генерирует методы управления, динамически создавая, удаляя и
пересекая связи. Ссылки при этом прямые, нет необходимости в просмотре
исравнении или даже поиске индекса, который может сильно сказаться на
производительности. Таким образом, применение объектной модели
предпочтительнеедля баз данных с большим количеством сложных связей:
перекрестных ссылок, ссылок, связывающих несколько объектов с несколькими
(many-to-many relationships)двунаправленными ссылками.
В отличие от реляционных, ООСУБД полностью поддерживают объектно-ориентированные
языки программирования. Разработчики, применяющие С++или Smalltalk, имеют дело с
одним набором правил (позволяющих использовать такие преимуществаобъектной
технологии, как наследование, инкапсуляция и полиморфизм). Разработчик не должен
прибегать к трансляцииобъектной модели в реляционную и обратно. Прикладные
программы обращаются и функционируют с объектами, сохраненными в базе данных,
которая используетстандартную объектно-ориентированную семантику языка и
операции. Напротив, реляционная база данных требует, чтобы разработчик
транслировал объектнуюмодель к поддерживаемой модели данных и включил
подпрограммы, чтобы обеспечить это отображение во время выполнения. Следствием
являются дополнительные усилияпри разработке и уменьшение эффективности.
И, наконец, ООСУБД подходят (опять же без трансляций между объектной и
реляционной моделями) для организации распределенных вычислений.Традиционные
базы данных (в том числе и реляционные и некоторые объектные) построены вокруг
центрального сервера, выполняющего все операции над базой. Посуществу, эта
модель мало отличается от мэйнфреймовой организации 60‑х годов с центральной ЭВМ
– мэйнфреймом (mainframe), выполняющей все вычисления, и пассивных
терминалов.Такая архитектура имеет ряд недостатков, главным из которых является
вопрос масштабируемости. В настоящее время рабочие станции (клиенты)
имеютвычислительную мощность порядка 30 ‑ 50 % мощности сервера базы данных, то
есть большая часть вычислительных ресурсов распределена среди клиентов.Поэтому
все больше приложений, и в первую очередь базы данных и средства принятия
решений, работают в распределенных средах, в которых объекты(объектные
программные компоненты) распределены по многим рабочим станциям и серверам и где
любой пользователь может получить доступ к любому объекту.Благодаря стандартам
межкомпонентного взаимодействия (об этом позже) все эти фрагменты кода
комбинируются друг с другом независимо от аппаратного,программного обеспечения,
операционных систем, сетей, компиляторов, языков программирования, различных
средств организации запросов и формирования отчетови динамически изменяются при
манипулировании объектами без потери работоспособности.
5.2 Спорныемоменты технологии.
Все ООСУБД по определению поддерживают сохранение и разделение объектов. Но,
когда дело доходит до практической разработкиприложений на разных ООСУБД,
проявляется множество отличий в реализации поддержки трех характеристик:
Целостность;
Масштабируемость;
Отказоустойчивость.
Отметим, что ООБД не требуют многих из тех внутренних функций и механизмов,
которые столь привычны и необходимы в реляционных БД.Например, при небольшом
числе пользователей, длинных транзакциях и незначительной загрузке сервера
объектные СУБД не нуждаются в поддержке сложных механизмоврезервного
копирования/восстановления (исторически сложилось так, что первые ООБД
проектировались для поддержки небольших рабочих групп – порядка десятичеловек –
и не были приспособлены для обслуживания сотен пользователей). Тем не менее
технология БД определенно созрела для крупных проектов.
Дляиллюстрации первой категории рассмотрим механизм кэширования объектов.
Большинство объектных СУБД помещают код приложения непосредственно в то
жеадресное пространство, где работает сама СУБД. Благодаря этому достигается
повышение производительности часто в 10‑100раз по сравнению с раздельными
адресными пространствами. Но при такой модели объект с ошибкой может повредить
объекты и разрушить базу данных.
Существуют два подхода к организации реакции СУБД для предотвращения потери
данных.Большинство систем передают приложению указатели на объекты, и рано или
поздно такие указатели обязательно становятся неверными. Так, они всегда
неправильныпосле перехода объекта к другому пользователю (например, после
перемещения на другой сервер). Если программист, разрабатывающий приложение,
пунктуален, тоошибки не возникает. Если же приложение попытается применить
указатель в неподходящий для этого момент, то в лучшем случае произойдет крах
системы, вхудшем – будет утеряна информация в середине другого объекта и
нарушится целостность базы данных.
Есть метод, лучший, чем использование прямых указателей (Рисунок 3). СУБД
добавляетдополнительный указатель и при необходимости, если объект перемещается,
система может автоматически разрешить ситуацию (перезагрузить, если это
необходимо,объект) без возникновения конфликтной ситуации.
Существует еще одна причина для применения косвенной адресации: благодаря этому
можноотслеживать частоту вызовов объектов для организации эффективного механизма
свопинга.
Это необходимо для реализации уже второго необходимого свойства баз данных –
масштабируемости. Опять следует упомянуть организациюраспределенных компонентов.
Классическая схема клиент-сервер, где основная нагрузка приходится на клиента
(такая архитектура называется еще “толстыйклиент-тонкий сервер”), лучше
справляется с этой задачей, чем мэйнфреймовая структура, однако ее все равно
нельзя масштабировать до уровня предприятия.Благодаря многозвенной архитектуре
клиент-сервер (N-Tier architecture) происходит равномерноераспределение
вычислительной нагрузки между сервером и конечным пользователем. Нагрузка
распределяется по трем и более звеньям, обеспечивающим
дополнительнуювычислительную мощность. К чему же еще ведет такая практика?
“Архитектура клиент-сервер, еще совсем недавно считавшаяся сложной средой,
постепеннопревратилась в исключительно сложную среду. Почему? Благодаря
ускоренному переходу к использованию систем клиент-сервер нескольких звеньев”
(PCMagazine).Разработчикам приходится расплачиваться дополнительными
сложностями, большими затратами времени и множеством проблем, связанных с
интеграцией. Оставимочередное упоминание распределенных компонентов на этой не
лишенной оптимизма ноте.
Рисунок 3 Прямая и косвенная адресации.
Третье необходимое качество базы данных – это отказоустойчивость. Именно это
свойство отличает программныйпродукт от “прилады”. Существуют несколько способов
обеспечения отказоустойчивости:
резервное копирование и восстановление;
распределение компонентов;
независимость компонентов;
копирование.
Руководствуясь первым принципом, программист определяет потенциально опасные
участки кода и вставляетв программу некоторые действия, соответствующие началу
транзакции – сохранение информации, необходимой для восстановления после сбоя, и
окончанию транзакции –восстановление или, в случае невозможности, принятие
каких-то других мер, например, отправка сообщения администратору. В современных
СУБД этот механизмобеспечивает восстановление в случае возникновения практически
любой ошибки системы, приложения или компьютера, хотя, конечно, нельзя говорить
об идеальнойзащите от сбоев.
В мэйнфреймовой архитектуре единственным источником сбоев была центральная ЭВМ.
При переходе к распределенной многозвенной организацииошибки могут вызывать не
только компьютеры, включенные в сеть, но и коммуникационные каналы. В
многозвенной архитектуре при сбое одного из звеньевбез специальных мер
результаты работы других окажутся бесполезными. Поэтому при разработке
распределенных систем обеспечивается принципиально более высокийуровень
обеспечения отказоустойчивости. Назовем обязательные для современных
распределенных СУБД свойства:
прозрачный доступ ко всем объектам независимо от ихместоположения, благодаря
чему пользователю доступны все сервисы СУБД и может производиться
перераспределение компонентов без нежелательных последствий.
так называемый “трехфазный монитор транзакций” (third-party transaction
monitor), благодаря которомутранзакция выполняется не в два, а в три этапа –
сначала посылается запрос о готовности к транзакции.
Что произойдет, если один из компонентов выйдет из строя? Система, созданная в
соответствии только с вышеизложенными доводами,приостановит работу всех
пользователей и прервет все транзакции. Поэтому важно такое свойство СУБД, как
независимость компонентов.
При сетевом сбое сеть разделяется на части, компоненты каждой из которых не
могут сообщаться с компонентами другой части. Для того,чтобы сохранить
возможность работы внутри каждой такой части, необходимо дублирование критически
важной информации внутри каждого сегмента. Современныесистемы позволяют
администратору базы данных динамически определять сегменты сети, варьируя таким
образом уровень надежности всей системы в целом.
И, наконец, о копировании (replication) данных. Простейшим способом является
добавление к каждому (основному) серверу резервного. После каждойоперации
основной сервер передает измененные данные резервному, который автоматически
включается в случае выхода из строя основного. Естественно, такаясхема не лишена
недостатков. Во-первых, это приводит к значительным накладным расходам при
дублировании данных, что не только сказывается напроизводительности, но и само
по себе является потенциальным источником сбоев. Во-вторых, в случае сбоя,
повлекшего за собой разрыв соединения между двумясерверами, каждый из них должен
будет работать в своем сегменте сети в качестве основного сервера, причем
изменения, сделанные на серверах за время работы втаком режиме, будет невозможно
синхронизовать даже после восстановления работоспособности сети.
Более совершенным является подход, когда создается необходимое (подбираемое в
соответствии с требуемым уровнем надежности) числокопий в сегменте. Таким
образом увеличивается доступность копий и даже (при распределении нагрузки между
серверами) повышается скорость чтения. Проблеманевозможности обновления данных
несколькими серверами одновременно в случае их взаимной недоступности решается
за счет разрешения проведения модификацийтолько в одном из сегментов, например
имеющем наибольшее число пользователей. При хорошо настроенной схеме кэширования
затраты на накладные расходы придублировании модифицированных данных близки к
нулю.
5.3 Стандартыобъектных баз данных.
Для обеспечения переносимости приложений (приложение может работать на разных
СУБД) и совместимости с СУБД (может взаимодействовать сразными СУБД),
естественно, необходима выработка стандартов. Сразу заметим, что установление
стандартов лишает производителя в некоторой степени свободы впринятии решений и
увеличивает стоимость продукта за счет лицензионных отчислений и больше не будем
обсуждать целесообразность (прямо скажем,очевидную) стандартизации.
В области объектных СУБД в настоящее время выработаны стандарты для:
объектной модели;
языка описания объектов;
языка организации запросов (Object Query Language – OQL);
“связующего” языка (C++ и, конечно же, Smalltalk);
администрирования;
обмена (импорт/экспорт);
интерфейсов инструментария и др.
Хотя у Microsoft и свое мнение на этот счет, организацией, выработавшей наиболее
используемые насегодня и устоявшиеся стандарты, является консорциум поставщиков
ООСУБД ODMG (ООСУБД), которого поддерживаютпрактически все действующие лица
отрасли. В сотрудничестве с OMG, ANSI, ISO и другимиорганизациями был создан
стандарт ODMG-93. Этот стандарт включает в себя средства для
построениязаконченного приложения, которое будет работать (после перекомпиляции)
в любой совместимой с этой спецификацией ООСУБД. В книгу ODMG-93 входят
следующие разделы:
Язык определения объектов (Object Definition Language – ODL);
Язык объектных запросов (Object Query Language – OQL);
Рисунок 4 Схема использования ODL для построения приложения.
Связывание с C++;
Связывание со Smalltalk.
ODL. В качестве языка определения объектов (ODL) ODMG был выбран существующий
язык IDL(Interface Definition Language – язык описания интерфейсов), который был
дополнен такими необходимыми дляобъектных БД свойствами, как определение
коллекций, двунаправленных связей типа “многие-ко-многим”, ключей и др. В
сочетании со средствами языка IDL определения атрибутов и операций, это
позволяет определять практически любые объекты. Все дополнения реализованы в
видедоопределения методов, что обеспечивает совместимость со стандартами OMG,
например стандартом CORBA.
Рисунок 4 показывает работоспособную схему для построения приложения на
стандартных языках программирования, в процессе которой
автоматическигенерируются метаданные, заголовочные файлы и методы. Приведем
также пример на языке ODL из “белой книги” компании Objectivity,
которыйиллюстрирует связи типа “один-ко-многим”, объявленные между
преподавателем и студентами:
interface professor : employee {
attribute string <32> name;
unique attribute lang unsigned ssn;
relationship dept works_in inverse faculty; relationship set
teaches inverse taught_by; . . . operations . . .
{
interface section : class {
. . . taught_by: professor . . . ;
. . .
}
OQL. За основу языка OQL была взята команда SELECT языка SQL2 (или SQL-92) и
добавлены возможностьнаправлять запрос к объекту или коллекции объектов и
возможность вызывать методы в рамках одного запроса. Данные, полученные в
результате запроса, могутбыть скалярными (включая кортежи), объектами или
коллекциями объектов. Некоторые примеры наязыке OQL (тот же источник):
• Select x from x in faculty where x.salary >
x.dept.chair.salary
•sort s in (select struct (name: x.name, s:x.ssn) from
x in faculty where for all y in
x.advisees:y.age<25) by s.name
• Chair.salary
• Students except TAs
•list (1,2) + list (count (jse.advisees), 1+2)
• exists x in faculty [1:n]: x.spouse.age<25
C++. Спецификация ODMG-93 позволяет программистам легко использовать объекты в
то время как ООСУБД прозрачнымобразом управляет ими. При определении стандарта
члены ODMG руководствовались следующими принципами:
Использование стандартных компиляторов обеспечивается тем, что все расширения
реализуютсясредствами языка – библиотеками классов и перегрузкой операторов.
Определение временных экземпляров (Transient Instance) и экземпляров,
создаваемых на длительный срок (Transient Instance) припомощи оператора new().
При перегрузке оператора new() оба типа экземпляров могут создаваться от
одного класса, который может существовать продолжительноевремя.
Обеспечение устойчивости через стандартный механизм наследования; пользователь
можетопределять экземпляры временные и рассчитанные на продолжительное
использование средствами оригинальной версии языка.
Использование специального механизма указателей (Smart Pointers). Связи между
объектами объявляются при помощи шаблона Ref<> и перегрузки оператора ->; это
позволяет использовать специальные указатели(контролируемые системой; см.,
например, идентичность в словарике (стр. 21) и упоминание косвеннойадресации
(стр. 10) как обычные.
class Professor: Employee {
long ssn;
char* name;
int age;
Refdept inverse faculty;
Set teachesinverse taught_by;
. . .
void grant_tenure()
void assign_course(section)
}
. . .
Ref...
Сборка и технико-экономическое обоснование персонального компьютера в ключе
поставленных перед ним задач
Эксплуатационные требования к комплектовке компьютера.
Комплектовка и сборка компьютера осуществляется с расчетом на то, что он будет
использован в основном как обычный офисный "секретарский" или бухгалтерский
компьютер способный быстро и оперативно решать как основные, так и сопутствующие
задачи в одном из небольших учреждений, а также регулярно предоставлять
сотрудникам возможность иметь доступ к свежей информации в сети Интернет.
Основные архитектурные и системные требования к машине с учетом возложенных на
нее задач.
Достаточное дисковое пространство для хранения бухгалтерских смет, отчетов,
текущих документов и тд.
Высокое быстродействие для быстроты обработки бухгалтерии.
Поддержка современного мультимедийного ПО
Несложное освоение, унифицированность, интуитивный интерфейс и гибкость системы
Windows 95/98 при установке и использовании офисного программного обеспечения
(Office 97/98, 1С Бухгалтерия, Netscape Communicator), различных графических
приложении, делают целесообразным ее использование на собираемой машине.
Наличие факс-модема для облегчения факсового обмена между организациями и
экономии факс-бумаги организацией, подключение к Internet.
Выбор процессора.
В наши дни круг процессоров которые способны достигнуть максимальной
производительности в работе системы ограничивается следующей последовательностью
Celeron, Pentium II,
Cyrix M-II, и AMD K6-2.
15 апреля среди прочих продуктов фирмой Intel был представлен новый процессор
Celeron. ...
Что такое Internet
История сети Internet
Из чего состоит Internet?
Кто управляет Internet?
Кто платит?
Протоколы сети Internet.
О том, как работает Internet.
Перемещая биты с одного места на другое.
Сети с коммутацией пакетов.
Межсетевой протокол (IP).
Протокол управления передачей (ТСР).
Как сделать сеть дружественной?
Прикладные программы.
Доменная система имён.
Структура доменной системы.
Поиск доменных имён.
Что можно делать в Internet?
Правовые нормы.
Коммерческое использование.
Экспортное законодательство.
Права собственности.
Сетевая этика.
Этические нормы и частная коммерческая Internet.
Соображения безопасности.
Сколь велика Internet сейчас?
Услуги, предоставляемые сетью.
Элементы охраны труда и защиты информации.
Заключение.
Словарь терминов.
Английские термины.
Русские термины.
Приложение А.
Допустимое использование.
Политика допустимого использования базовых услуг сети NSFNET.
Список литературы.
Введение: компьютерные сети.
Локальная сеть представляет собой набор компьютеров, периферийных устройств
(принтеров и т. ...
Вычислительное устройство, выполняющее операции изменения знака числа и деление
чисел.
Числа представлены в формате с плавающей точкой с разрядностью 18+6.
1. ...
Розглянемо основні можливості при роботі з Word і рекомендації по їхньому застосуванню.
*
* Автоматизація виконання задач і отримання допомоги
*
* В Word 97 є широкий вибір засобів автоматизації, що спрощують виконання типових задач.
*
* Автозаміна
*
* Нижче перераховані деякі типи помилок, що можуть бути виправлені автоматичні при введенні:
*
* Наслідку випадкового натиску клавіші CAPS LOCK (вперше з'явилася в Word 95). ...
Теоретическая часть.
В данной расчетно-графической работе (далее РГР) требуется составить программу
для решения системы нелинейных уравнений методом последовательной итерации
обратной матрицы Якоби.
Суть метода в следующем:
Пусть требуется решить систему нелинейных алгебраических или трансцендентных
уравнений:
F1(X1,X2,...,Xn)=0; i=1,2,...,n,
с начальным приближением к решению:
X0=(x10,x20,...xn0).
Вычислительная схема реализованного метода состоит в следующем:
В начале итерационного процесса матрица H полагается равной единичной:
H0=E.
Затем для k=0,1,...
1. ...
Системи автоматзованого проектування (САПР) являють собою принципово новій підхід до процесу розробки приладів та устаткування.
Завдяки тому, що значна частина розрахунків та виконання багатьох однотипових функцій покладається на ЕОМ значно полегшуеться праця конструктора...
ЧИСЛЕННОЕ РЕШЕНИЕ НЕЛИНЕЙНЫХ УРАВНЕНИЙ.
1п. Общий вид нелинейного уравнения
F(x)=0
Нелинейные уравнения могут быть двух видов:
Алгебраические
anxn + an-1xn-1 +… + a0 = 0
Трансцендентные- это уравнения в которых х является аргументом
тригонометрической, логарифмической или показательной функции.
Значение х0 при котором существует равенство f(x0)=0 называется корнем
уравнения.
В общем случае для произвольной F(x) не существует аналитических формул
определения корней уравнения...
До сих пор мы рассматривали методы поиска, основанные на сравнении данного аргумента K с имеющимися в таблице ключами или на использовании его цифр для управления процессом разветвления. ...