КАТЕГОРИИ: Архитектура-(3434)Астрономия-(809)Биология-(7483)Биотехнологии-(1457)Военное дело-(14632)Высокие технологии-(1363)География-(913)Геология-(1438)Государство-(451)Демография-(1065)Дом-(47672)Журналистика и СМИ-(912)Изобретательство-(14524)Иностранные языки-(4268)Информатика-(17799)Искусство-(1338)История-(13644)Компьютеры-(11121)Косметика-(55)Кулинария-(373)Культура-(8427)Лингвистика-(374)Литература-(1642)Маркетинг-(23702)Математика-(16968)Машиностроение-(1700)Медицина-(12668)Менеджмент-(24684)Механика-(15423)Науковедение-(506)Образование-(11852)Охрана труда-(3308)Педагогика-(5571)Полиграфия-(1312)Политика-(7869)Право-(5454)Приборостроение-(1369)Программирование-(2801)Производство-(97182)Промышленность-(8706)Психология-(18388)Религия-(3217)Связь-(10668)Сельское хозяйство-(299)Социология-(6455)Спорт-(42831)Строительство-(4793)Торговля-(5050)Транспорт-(2929)Туризм-(1568)Физика-(3942)Философия-(17015)Финансы-(26596)Химия-(22929)Экология-(12095)Экономика-(9961)Электроника-(8441)Электротехника-(4623)Энергетика-(12629)Юриспруденция-(1492)Ядерная техника-(1748) |
Лекция 1. Введение в клиент-серверные СУБДВ конце 80-х годов все знали, что разработка клиент-серверных многопользовательских систем - это сложно. Разработка велась в основном на языках четвертого поколения, входящих в комплект соответствующих СУБД. Стоимость таких разработок была очень велика и занимались этим в основном серьезные профессионалы. Нишу настольных приложений заняли умельцы, владеющие "народными" СУБД типа Clipper, FoxPro и Paradox, и слои практически не пересекались. Но в начале 90-х радикально подешевели средства организации локальных сетей с разделяемыми файлами (файл-серверов), и появились "сетевые" версии настольных СУБД, позволяющие как-то обеспечить многопользовательскую работу. Они заняли промежуточную ценовую и квалификационную нишу между чисто настольными и клиент-серверными системами (ближе к настольным, естественно). Клиент-серверные разработки в нашей стране оказались вытеснены в область критически важных high-end-решений типа резервирования авиабилетов, учета на очень больших предприятиях, в крупных банках и др. Результаты прогресса привела к тому, что на рынке уверенно возобладали реляционные СУБД, и произошло сближение функциональности ряда лидирующих клиент-серверных систем (Oracle, MS SQL, Sybase, DB2, Interbase, Progress). Цены на эти системы заметно снизились (в разы). При организации архитектуры «клиент-сервер» наиболее трудоемкие операции над базами данных выполняются на выделенном компьютере-сервере, который должен быть достаточно мощным и обладать соответствующим набором ресурсов основной и внешней памяти. До поры серверная часть СУБД обладала простой организацией (рис.1.): запросы, поступающие из клиентских частей системы, обрабатывались последовательно с небольшой оптимизацией для совмещения процессорной работы с работой устройств внешней памяти. Однако с появлением на рынке мультипроцессорных симметричных аппаратных архитектур, производители СУБД были вынуждены пересмотреть организацию своих серверов, допустив в них внутреннюю параллельность. Естественно, это требует очень основательного перепроектирования системы с ее существенным усложнением. Рис 1. Архитектура клиент—сервер Есть несколько причин, определяющих преимущества клиент-серверной архитектуры перед файл-серверной:
Транзакция – это последовательность операций над базой данных, рассматриваемых СУБД как единое целое. Транзакция представляет собой набор действий, выполняемых с целью доступа или изменения содержимого базы данных. Для всех современных реляционных СУБД основным языком доступа к базам данных является SQL. В 1989 г. появился первый международный стандарт этого языка, и большинство производителей СУБД объявляют свои системы соответствующими этому стандарту. Но стандарт 1989 г. был довольно ограниченным (например, в него не входили средства манипулирования схемой БД, динамический SQL и т.д.), а многие вошедшие в стандарт аспекты языка были специфицированы недостаточно строго. Поэтому разные реализации различаются в достаточно важных вопросах. В 1992 г. был принят новый стандарт SQL-92. Этот язык существенно более сложен, чем SQL-89, а конструкции SQL-92 специфицированы в стандарте существенно более полно. Первой компанией, которая объявила о соответствии своего продукта новому стандарту, была компания Oracle со своей седьмой версией (это произошло прямо в 1992 г.). Почти все современные средства разработки позволяют работать с разными серверами баз данных. В значительной степени этому способствовало сближение функциональных возможностей серверов баз данных и появление стандартных программных интерфейсов для работы с ними (ODBC, IDAPI, JDBC). Таким образом, создается иллюзия, что система, разработанная для одного сервера БД, может быть легко перенесена на другой или, более того, можно сделать систему, которая будет работать с различными типами серверов. На самом деле при внешнем сходстве различия между разными серверами баз данных остаются достаточно глубокими, и они критичны для создания реальных промышленных приложений: · у разных серверов разный синтаксис и функциональные возможности языков разработки хранимых процедур и триггеров; · поскольку разные серверы пользуются разными алгоритмами оптимизации, то запросы, хорошо работающие на одной системе, могут оказаться неэффективными на другой. А арсенал способов управления эффективностью у них совершенно разный; · местами не совпадает даже синтаксис SQL - в части, например, внешних соединений таблиц (outer join); · поскольку разные серверы пользуются разными принципами блокировок и организации транзакций, то для эффективной многопользовательской работы нужны разные способы организации программы; · каждый сервер имеет свои собственные, уникальные и, как правило, очень полезные в конкретных приложениях особенности. Дата добавления: 2014-01-07; Просмотров: 366; Нарушение авторских прав?; Мы поможем в написании вашей работы! Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет |