1. Проблемы обработки информации.
Современный мир информационных технологий трудно представить себе без использования баз данных. Практически все системы в той или иной степени связаны с функциями долговременного хранения и обработки информации. Фактически информация становится фактором, определяющим эффективность любой сферы деятельности:
Увеличились информационные потоки. При принятии решений приходится учитывать огромное количество данных, поступающих из самых разнообразных источников.
Повысились требования к скорости обработки данных. Теперь уже большинство операций не может быть выполнено вручную, они требуют наиболее перспективных компьютерных технологий, потому что решение необходимо прямо сейчас, а не через несколько минут, часов, дней .
Любые административные решения требуют точной и четкой оценки текущей ситуации и возможных перспектив ее изменения. И если раньше в оценке ситуации участвовало несколько факторов (иногда несколько десятков факторов), то теперь таких факторов сотни, тысячи, десятки и даже сотни тысяч.
Ситуация меняется не в течение года, а через несколько минут, и быстрота и обоснованность принимаемых решений требуется большая, потому что реакция на неправильные решения значительно более серьезная, быстрая и мощная, чем раньше. Неправильные решения часто могут привести к катастрофическим последствиям как в ближайшем, так и в весьма отдаленном будущем.
Невозможно обойтись без информационной модели производства, хранимой в базе данных. В противном случае данные, хранящиеся в базе, будут просто нагромождением чисел, слов, фрагментов, полезный смысл которых определить сразу не представится возможным.
Система баз данных – это, по сути, компьютеризированная система хранения записей. Саму же базу данных можно рассматривать как подобие электронной картотеки, т.е. хранилище для некоторого набора занесенных в компьютер файлов данных.
Пользователю этой системы предоставляется возможность выполнения множества различных операций над такими файлами. Например, пользователь может:
добавлять новые пустые записи в существующие файлы, т.е. добавлять место для размещения полезных данных в будущем,
добавлять собственно новые данные в существующие файлы,
вести поиск данных в существующих файлах в соответствии с определенными правилами,
изменять данные в существующих файлах,
удалять данные из существующих файлов,
удалять существующие файлы из базы данных, т.е. избавляться от их содержимого.
Что дает использование систем баз данных? Можно указать следующие наиболее реальные преимущества применения таких систем:
1) для однопользовательских систем:
Сокращение времени, необходимого для ведения записей (вы просто вводите новую запись, не заботясь о физическом размещении записей).
Компактность. Нет никакой необходимости в многотомных бумажных картотеках. Данные хранятся в весьма компактном виде на устройствах памяти.
Удаленный доступ и передача записей в электронном виде. Данные можно получить с сервера, находящегося совсем в другом месте (городе, регионе, стране), используя каналы сетей (Интернет, …).
Гибкость поиска и представления данных. Можно приказать СУБД расположить записи ответа на запрос в любом порядке.
Гибкость формата вывода. Возможно сгенерировать отчет в требуемой форме практически без затрат труда конечного пользователя.
Скорость получения информации. Сокращение времени, необходимого для поиска необходимых записей (достаточно просто сделать запрос к информационной системе).
Низкие трудозатраты ручного труда человека. Правда, в этом случае требуется несколько (а иногда, значительно) более высокая квалификация пользователя системы.
Применимость. Точная, свежая информация всегда под рукой. Вы можете получить ответ на любой нужный вопрос как бы между прочим, без особых дополнительных трудозатрат.
2) для многопользовательских систем можно указать еще и следующее дополнительное преимущество: система баз данных предоставляет предприятию возможность централизованного управления его данными (а для баз данных это – наиболее ценное свойство), т.е. одновременный многопользовательский доступ к записям (к одним и тем же или различным).
На предприятии, использующем систему баз данных, есть человек, который несет ответственность за данные предприятия. Это – администратор данных, разбирающийся в данных и понимающий нужды предприятия по отношению к данным на уровне управления высшего руководства предприятием. Он, в частности, должен устанавливать, кто, при каких условиях, над какими данными и какие операции может выполнять. Тем самым он должен обеспечивать безопасность данных.
Техническое руководство должен осуществлять специалист по техническим вопросам – администратор базы данных (АБД), профессиональный специалист в области информационных технологий. Работа АБД заключается в создании самих баз данных и техническом контроле, необходимом для осуществления решений администратора данных. АБД несет ответственность за обеспечение необходимого быстродействия системы и ее технического обслуживания.
Централизованный подход в управлении данными обеспечивает следующие дополнительные преимущества использования баз данных:
Возможность сокращения избыточности. Нет никакой необходимости хранить данные «под рукой» в виде отдельного экземпляра данных,
Возможность устранения противоречивости. Раз нет нескольких экземпляров данных, нет и возможности того, что один экземпляр данных противоречит другому. Противоречий можно избежать также, если не удалять избыточность (т.е. не удалять лишние экземпляры данных), а контролировать ее (т.е. предусматривать возможность множественного обновления данных),
Возможность общего доступа к данным. Данные могут быть получены всеми, кому на это дано право, без создания новых данных (или их копий),
Возможность соблюдения стандартов. Один экземпляр данных может тщательно отслеживаться на соответствие стандартам (корпоративным, ведомственным, государственным, …), а использование этого отлаженного экземпляра возможно в самых различных целях,
Возможность введения ограничений для обеспечения безопасности. Централизованная природа системы баз данных в некотором смысле требует наличия хорошей системы безопасности. Без таковой работа СУБД просто не будет возможной. Можно определить правила безопасности, которые будут проверяться при попытке доступа к уязвимым данным,
Возможность обеспечения целостности данных. Задача целостности заключается в обеспечении правильности и точности данных в базе данных. Примерами недостатка целостности являются, положим, противоречие между двумя записями (при наличии избыточности) или ошибочные данные (когда сотрудник имеет 400 рабочих часов в неделю вместо 40). При централизованном подходе администратор данных может определить правила целостности, которые будут применяться при любой попытке проделать какую-либо операцию обновления,
Возможность сбалансировать противоречивые требования, например, доступность и секретность, доступность и сохранность, скорость доступа и размер баз данных,
Возможность обеспечения (в той или иной степени) независимости данных и, следовательно, иммунитета приложений к изменениям в структуре хранения и в методах доступа к данным. Это обеспечивает возможность работы приложений без непрерывного их изменения вслед за изменениями в структурах хранения данных.
Для вузовских образовательных профилей, которые ориентированы на применение компьютеров в производственной сфере или в сфере образования, характерно включение в число специальных дисциплин таких, которые направлены на овладение знаниями и умениями по проектированию баз данных и работе с ними.
2. Понятие о метаданных. Цели и назначение.
Метаданные (от греч. Meta и лат. Data), буквально переводится как «данные о данных», информация о другом наборе данных.
Одно из полезных определений следующее: «Метаданные — это структурированные, кодированные данные, которые описывают характеристики объектов-носителей информации, способствующие идентификации, обнаружению, оценке и управлению этими объектами».
Майкл Брэкет1 (Michael Brackett) определяет метаданные (которые он называет «данными о ресурсах данных») как «любые данные об информационных ресурсах организации». Адриен Танненбаум2 (Adrienne Tannenbaum) называет метаданные «детальным описанием сущности данных». Эти определения раскрывают формулировку «данные о данных».
Тема эта поднимается с тех пор, как существуют данные: метаданные были необходимы для описания значения и свойств информации с целью лучшего ее понимания, управления и использования. Классическим примером являются библиотеки. Книги (данные) можно классифицировать, управлять ими и находить только с помощью соответствующих метаданных (т.е. заголовка, автора и ключевых слов содержания).
Обычно под метаданными понимается любая информация, необходимая в IT для анализа, проектирования, построения, внедрения и применения компьютерной системы. В случае информационных систем метаданные особенно упрощают управление, создание запросов, полноценное использование и понимание данных. Многие недавние проекты, как научные, так и практические, направлены на изучение метаданных. Генерирование, хранение и управление метаданными помогают в поддержке использования огромных объемов информации, доступных в наши дни в любой электронной форме. Так как все, с чем работает компьютер, по сути является данными, и своего рода метаданные сопровождают любые данные, то это понятие имеет место быть в любой сфере приложений и принимает различные формы в зависимости от применения.
Метаданные Хранилища данных
Популярность Хранилищ данных в последние годы существенно возросла. Конкурентоспособные организации находятся на пути построения ХД либо расширения, перепроектирования и усовершенствования уже имеющихся. Метаданные считаются ключевым фактором успеха в проектах по внедрению Хранилищ. Они содержат всю информацию, необходимую для извлечения, преобразования и загрузки данных из исходных систем, а также для последующего использования и интерпретации содержимого ХД.
Метаданные систем Хранилищ данных иногда подразделяют на два типа:
1. служебные метаданные, используемые для функций извлечения, преобразования и загрузки, для переноса OLTP-данных (информации из транзакционных систем) в Хранилище;
2. интерфейсные метаданные, использующиеся для описания экранов и создания отчетов.
Ральф Кимболл3 (Ralph Kimball) перечисляет следующие типы метаданных в Хранилище:
* метаданные исходной системы
* спецификации источников данных, таких как репозитории;
* описательная информация (например, частота обновления, юридические ограничения и методы доступа);
* информация о процессах, таких как график заданий и коды извлечения.
* метаданные преобразования данных
* информация о получении данных (например, планирование передачи данных и результатов, а также сведения об использовании файлов);
* управление таблицами измерений, например, определения измерений и присвоения суррогатных ключей;
* преобразование и агрегирование, например, расширение и отображение данных, программы (скрипты) загрузки СУБД, определения агрегатов данных;
* документирование проверок, работ и журналов, например: журналов преобразования данных и записей слежения за происхождением данных.
* метаданные СУБД, такие как:
* содержание системных таблиц СУБД;
* рекомендации по обработке.
Роль метаданных в Хранилище
Лучше всего объяснить суть метаданных, описывая их роль и назначение в реализации процессов ХД. Метаданные можно использовать тремя способами:
* пассивно, обеспечивая четкую документацию о структуре, процессе разработки и использовании системы ХД. Доступная документация необходима всем участникам (т.е. конечным пользователям, системным администраторам, а также разработчикам приложений);
* активно, путем хранения конкретных семантических аспектов (например, правил преобразования) в виде метаданных, которые можно интерпретировать и использовать во время исполнения. В этом случае процессы Хранилища данных управляются метаданными. А следовательно, код (т.е. активные метаданные) и дополнительная документация согласованно и унифицировано управляются в одном репозитории, при этом актуальность документации возрастает;
* полуактивно, за счет хранения статической информации (например, определений структур, спецификаций конфигураций), которую будет считывать другой программный компонент во время выполнения. Например, обработчикам запросов необходимы метаданные для проверки существования атрибутов. В отличие от активного использования, здесь метаданные только читаются, но не исполняются.
Создание и управление метаданными служит двум целям:
1. минимизации работ по разработке и администрированию ХД;
2. более эффективному извлечению информации из ХД.
Первая цель в основном относится к:
* поддержке интеграции систем. Схемы и интеграция данных зависят от метаданных, описывающих структуру и смысл отдельных источников данных и целевых систем. Правила преобразования можно применить к исходным данным и хранить в качестве метаданных. Более того, интеграция различных инструментов возможна только тогда, когда они разделяют «данные», которые в данном случае представляют собой метаданные системы Хранилища данных;
* поддержке анализа и проектирования новых приложений. Метаданные повышают контролируемость и надежность процесса разработки приложений, обеспечивая информацию о смысле данных, их структуре и источниках. Более того, метаданные касающиеся решений по проектированию приложений, можно использовать повторно;
* повышению гибкости системы и возможности повторного использования существующих программных модулей. Это возможно только для активного и полуактивного использования метаданных. Быстро изменяющиеся семантические аспекты явным образом хранятся в виде метаданных вне прикладных программ. Поддержка поэтому существенно проще. Систему можно расширить и адаптировать без всяких трудностей. Данный подход также дает возможность повторного использования «фрагментов кода»;
* автоматизации административных процессов. Метаданные управляют запуском различных процессов ХД (например, загрузки и обновления). Информация об их исполнении (журналы доступа, количество добавленных в Хранилище записей и т.п.) также содержится в репозитории, легко доступном администратору;
* усилению механизмов безопасности. Метаданные должны обеспечить правила доступа и пользовательские права для всей системы ХД. Управление доступом в Хранилище иногда требует применения сложных методов. Например, оперативный источник может содержать безобидную информацию об отдельных показателях работы компании, однако суммарные значения в Хранилище иногда оказываются важнейшим секретом. С другой стороны, персональные доходы каждого сотрудника являются тайной, но при этом итоговая сумма зарплат в ХД может вовсе не быть критической информацией.
Вторая цель относится к эффективному извлечению информации, а точнее к :
* повышению качества данных. Качество данных определяется следующими характеристиками:
*
1) согласованностью (является ли представление данных однородным, нет ли дубликатов, данных с пересекающимися или конфликтующими определениями);
2) полнотой (все ли данные присутствуют);
3) точностью (совпадением хранимых и фактических значений);
4) своевременностью (актуально ли хранимое значение).
* Правила проверки качества данных необходимо задать, сохранить в виде метаданных и проверять при каждом обновлении Хранилища. Кроме того, высокое качество требует поддержки контроля данных. Метаданные обеспечивают информацию о времени создания и об авторе данных, об источнике, значении данных в момент получения (о наследовании данных), и о дальнейшем пути от источника к текущему местоположению (data lineage — о происхождении данных). Таким образом пользователи могут восстановить цепочку, по которой проходят данные за время преобразования, и проверить точность возвращенной информации;
* улучшению взаимодействия внутри системы ХД. Взаимодействие происходит как посредством выполнения простых запросов и отчетных приложений, так и с использованием сложных аналитических инструментов. Метаданные обеспечивают сведения о значении данных, терминологию и бизнес-концепции предприятия, а также их связь с данными. Поэтому метаданные повышают качество выполняемых запросов за счет более точной и строгой формулировки, а также сокращают расходы на пользователей, которым необходимы доступ, оценка и применение соответствующей информации;
* улучшению анализа данных. Методы анализа данных представлены широко — начиная от простых приложений отчетности и OLAP и заканчивая сложными приложениями data mining. В этом направлении метаданные необходимы для понимания предметной области и ее представления в Хранилище, с тем чтобы адекватно применить и интерпретировать результаты;
* применению общей терминологии и языка взаимодействия внутри корпорации. Доступность метаданных как уникального источника документации для пользователей имеет и другие преимущества. Она гарантирует согласованные средства взаимодействия и интерпретации информации из Хранилища. А также устраняет двусмысленность и обеспечивает согласованность сведений внутри компании, позволяет разделять знания и опыт.
3. Логические компоненты базы данных.
К логическим компонентам БД относятся объекты, режимы сопоставления, идентификаторы пользователей, учетные имена, роли и группы.
1.Объекты баз данных
Данные SQL Server 2000 организованы с помощью нескольких различных объектов, которые доступны пользователям при подключении к базе данных. Краткое описание главных объектов базы данных приводится в следующей таблице. Подробнее эти объекты обсуждаются в следующих главах.
Таблица
Двухмерный объект, состоящий из строк и столбцов, который используется для хранения данных в реляционной базе данных. В каждой таблице хранится информация об одном из типов объектов, моделируемых базой данных. Например, в базе данных образовательного учреждения одна таблица может содержать сведения о преподавателях, вторая — о студентах, а третья — о расписании
Тип данных
Атрибут, задающий тип информации, которая может храниться в столбце, параметре или переменной. SQL Server поддерживает несколько системных типов данных; в дополнение к ним разрешается создавать пользовательские типы данных
Представление
Объект БД, на который в SQL-операторах можно ссылаться так же, как на таблицу. Представления определяются с помощью SQL-операторов и являются аналогами объектов, содержащих результирующие наборы, получаемые при выполнении этих операторов
Хранимая процедура
Откомпилированный набор операторов Transact-SQL, хранимый под определенным именем и обрабатываемый как единое целое. SQL Server предоставляет хранимые процедуры для управления SQL Server и вывода сведений о БД и пользователях. Они называются системными хранимыми процедурами
Функция
Фрагмент кода, действующий как единая логическая сущность. Функцию можно вызвать по имени, при этом разрешается задать ряд необязательных входных параметров. Она возвращает сведения о состоянии и необязательные выходные значения. Функции поддерживаются многими языками программирования, в том числе C, Visual Basic и Transact SQL. В Transact SQL имеется ряд встроенных функций, которые изменить невозможно, а также поддерживаются функции, которые создают и корректируют пользователи
Индекс
Объект реляционной БД, обеспечивающий быстрый доступ к строкам таблицы на основе значений ключа, а так же уникальность строк в таблице. SQL Server поддерживает как кластерные, так и некластерные индексы. Первичный ключ таблицы индексируется автоматически. При полнотекстовом поиске сведения о ключевых словах и их расположении в данном столбце хранятся в полнотекстовом индексе
Ограничение
Свойство, назначаемое столбцу таблицы, которое позволяет предотвратить занесение недопустимых данных в столбец. Например, ограничения UNIQUE или PRIMARY_KEY предотвращают занесение значений, дублирующих существующие. Ограничение CHECK предотвращает занесение значения, не соответствующего критерию поиска, а NOT NULL — пустого значения
Правило
Объект БД, связанный со столбцами или с пользовательскими типами данных, который задает значения данных, приемлемые в данном столбце. Лучше использовать ограничения CHECK, которые предоставляют ту же самую функциональность и соответствуют стандарту SQL-92
Умолчание
Значение, автоматически присваиваемое системой данным, параметру, режиму сопоставления или имени, если оно не задано пользователем. Также определяет действие, автоматически выполняемое при конкретных событиях в отсутствие действий, заданных пользователем
Триггер
Хранимая процедура, исполняемая при модификации данных в заданной таблице. Триггеры часто создают для поддержки ссылочной целостности или согласованности логически связанных данных в различных таблицах
2. Режимы сопоставления
Режимы сопоставления определяют физическую структуру символьных строк в SQL Server 2000. Они задают битовые комбинации, представляющие каждый символ, а также правила сортировки и сравнения символов.
Различные объекты одной и той же базы данных SQL Server 2000 могут использовать разные режимы сопоставления. В SQL Server 2000 разрешается задавать отдельные режимы сопоставления вплоть до уровня столбцов, а каждому столбцу таблицы — присваивать различные режимы сопоставления. Более ранние версии SQL Server поддерживают только один режим сопоставления для каждого экземпляра SQL Server. У всех баз данных и их объектов, которые создаются в экземпляре SQL Server 7.0 или более ранней версии, режим сопоставления одинаков.
SQL Server 2000 поддерживает несколько режимов сопоставления, которые определяют правила использования символов для языка (например, македонского или польского) или для алфавита (например, Latin1_General — для латинского алфавита, который составляет основу письменности народов Западной Европы).
Каждый режим сопоставления SQL Server определяет три свойства:
* порядок сортировки данных Unicode-типов (nchar, nvarchar и ntext);
* порядок сортировки данных не-Unicode (char, varchar и text);
* кодовую страницу для хранения символьных данных в формате, отличном от Unicode.
ПРИМЕЧАНИЕ
Для типов данных Unicode (nchar, nvarchar и ntext) невозможно задать эквивалент кодовой страницы. Двухбайтовые комбинации, используемые для кодировки символов Unicode, определены стандартом Unicode и не могут быть изменены.
Режимы сопоставления SQL Server 2000 задаются на любом уровне. При установке для экземпляра SQL Server 2000 можно задать режимы сопоставления по умолчанию. Во время создания базы данных стоит задать для нее режимы сопоставления по умолчанию; если этого не сделать, то режимами сопоставления по умолчанию для базы данных станут те, что определены для экземпляра. При определении каждого символьного столбца, переменной или параметра разрешается задать режимы сопоставления по умолчанию. Если это не сделано, при создании объекта будут взяты режимы сопоставления по умолчанию для базы данных.
Идентификаторы пользователей, учетные имена, роли и группы В основе механизмов безопасности SQL Server 2000 лежат идентификаторы пользователей, учетные имена, роли и группы. Пользователи, которые подключаются к SQL Server, должны указать свой идентификатор. Затем они смогут просматривать только те таблицы и запускать лишь те хранимые процедуры и административные функции, для которых у них есть соответствующие права. Такая система безопасности основана на использовании идентификаторов пользователей. Все типы механизмов безопасности описаны в следующей таблице.
Идентификаторы
Идентификаторы ассоциируются с пользователями, пользователей когда те подключаются к SQL Server 2000. Идентификаторы представляют собой имена учетных записей, контролирующих доступ к системе SQL Server. Пользователь не сможет подключиться к SQL Server, не указав сначала допустимый идентификатор. Идентификаторы задаются членами фиксированной серверной роли sysadmin
Учетные имена
Позволяют идентифицировать пользователей в базе данных. Все права доступа и собственности на объекты БД контролируются на основе учетного имени. Пользовательские учетные имена уникальны для базы данных, например учетное имя xyz в БД продаж отличается от учетного имени xyz в складской БД, хотя у обоих учетных имен один и тот же идентификатор. Учетные имена определяется членами фиксированной роли базы данных db_owner
Роли
Роль напоминает группу пользователей домена Windows 2000. Она позволяет объединять пользователей в группу, а следовательно, применять права доступа к этим пользователям как к единому целому. Предоставление прав доступа, отказ в их предоставлении, отзыв прав доступа также осуществляется в отношении всех членов роли. Можно установить роль, описывающую задания, которые должны выполнять сотрудники вашей организации, занимающие определенную должность, и предоставить этой роли соответствующие права доступа. При подключении к этому заданию новый работник просто добавляются к членам роли. Когда работник перестает выполнять это задание, его можно удалить из роли. Если их несколько, то вам не придется многократно предоставлять, отказывать и отзывать права доступа для каждого из них. Права доступа применяются автоматически, как только пользователь становится членом роли. Роль похожа на группу в системе безопасности Windows
Группы
В SQL Server 2000 и SQL Server 7.0 группы отсутствуют. Однако предусмотрено управление безопасностью SQL Server на уровне целой группы Windows NT или Windows 2000
4. Блокировки. Виды блокировок.
Блокировки - это механизм, применяемый в MySQL для реализации транзакций и обеспечения одновременного доступа к данным. Помимо этого можно явно запрашивать блокирование таблиц с помощью инструкции LOCK TABLES.
Формат инструкции:
LOCK TABLES таблица [AS псевдоним] READ [LOCAL]|
[LOW_PRIORITY] WRITE :
Инструкция LOCK TABLES ожидает бесконечно долго, пока требуемые блокировки не будут получены. В ней указывается список имен таблиц, разделенных запятыми. После каждого имени задается тип блокировки:
READ - (нежесткая). Нежесткая блокировка запрещает запись в таблицу всем потокам, включая тот, кому она принадлежит.
WRITE - (жесткая). Жесткая блокировка разрешает доступ к таблице для чтения и записи только потоку-владельцу. Для таблицы может быть задан псевдоним, и пока блокировка не снята, таблице нельзя назначать в запросах другие псевдонимы. Если таблица участвует в запросе под несколькими псевдонимами, ее придется заблокировать определенное число раз под соответствующими именами.
LOCAL - разрешает выполнять инструкции INSERT, не приводящие к конфликтам. Но в этом случае файлы, содержащие табличные данные, становятся доступными для записи, из-за чего появляется угроза нарушения целостности данных.
LOW_PRIORITY - делает приоритет запросов на получение жестких блокировок более низким, чем у запросов на получение нежестких блокировок. В этом случае жесткая блокировка будет представлена только тогда, когда нет отложенных нежестких блокировок. Обычно же запросы первого типа имеют более высокий приоритет. С помощью LOCK TABLES можно ставить жесткую и нежесткую блокировки на одну или несколько таблиц. Нежесткая блокировка позволяет потокам осуществлять одновременное чтение данных из таблицы. Жесткая блокировка означает монопольный доступ к таблице со стороны одного единственного потока.
Для снятия блокировок предназначена инструкция UNLOCK TABLES. Кроме того, блокировки снимаются при завершении потока или вводе другой инструкции LOCK TABLES. Имитировать блокировку на уровне строк можно путем добавления к таблице специального столбца.
CREATE TABLE tabl1
(
ID int NOT NULL AUTO_INCREMENT,
:,
RowLock ENUM('UNLOCKED', 'LOCKED') NOT NULL,
PRIMARY KEY (ID)
)
Ячейки этого столбца будут иметь два состояния: заблокировано и не заблокировано. Тип столбца можно задать как SMALLINT или, лучше, ENUM.
Функции GET_LOCK() и RELEASE_LOCK() реализуют другой механизм блокирования. Эти блокировки не связаны с какими-либо ресурсами и не контролируются самой СУБД. Поэтому их называют программными блокировками, т. е. Их контроль должен осуществляться программным путем. У каждой такой блокировки есть имя, и в конкретный момент времени поток может ставить только одну программную блокировку. С помощью этих функций можно создавать блокировки произвольного уровня детализации. Все приложения придерживаются единого правила именования блокировок.
Функция GET_LOCK() позволяет создавать произвольные блокировки. Блокировки работают с любыми таблицами, даже теми, которые не поддерживают транзакции.
Формат функции GET_LOCK():
GET_LOCK(имя, тайм-аут) - запрашивает именованную блокировку на указанное число секунд. Функция не завершится, пока не истечет период тайм-аута или блокировка не будет получена.
Одному сеансу может принадлежать только одна блокировка. Вызов функции GET_LOCK() приводит к снятию всех удерживаемых блокировок, но лучше все же снимать их явно с помощью функции RELEASE_LOCK().
Формат функции RELEASE_LOCK():
RELEASE_LOCK(имя) - снимает указанную именованную блокировку, которая ранее была получена с помощью функции GET_LOCK(). Если имя блокировки не было зарегистрировано, возвращается NULL.
На внутреннем уровне программа MySQL блокирует таблицы целиком в случае необходимости. Допускается также блокировать строки, столбцы и страницы (под страницей понимается произвольный блок данных, связанных с таблицей). С точки зрения производительности преимущество той или иной модели проявляется по-разному.
Табличное блокирование выгодно для Web-приложений.
Блокирование на уровне строк лучше подходит для баз данных, в которых часто происходят откаты.
5. Команды Foxpro2. Виды команд и их структура. Компоненты команд.
FoxPro - реляционная система управления базами данных. FoxPro поддерживает файлы данных в формате dBaseIII+ и на 100% совместима с FoxBase+, а также совместима по языку с dBASE IV. FoxPro работает более, чем в 8 раз быстрее dBase IV и почти в 16 раз быстрее, чем dBaseIII+. FoxPro имеет в высшей степени изящный интерфейс, уникальный среди продуктов для MS DOS, обеспечивающий полную поддержку мыши.
Окно Command является в FoxPro системным окном, в котором вводятся различные команды. Например, команды создания базы данных, создания программ, просмотра данных и т.д.
CREATE Создает таблицу новую таблицу Visual FoxPro.
LIST TABLES Непрерывным потоком отображает список всех таблиц текущей базы данных и информацию об этих таблицах.
REPLACE Обновляет записи в таблице.
BROWSE Открывает окно просмотра и выводит записи из текущей или указанной таблицы.
USE Открывает таблицу и связанные и ней индексы или открывает обзор SQL.
SELECT Активизирует заданную рабочую область.
SELECT( ) Возвращает номер рабочей области, выбранной в данный момент, или наибольший среди номеров неиспользуемых рабочих областей. текущей рабочей области.
SELECT - SQL Стандартный запрос SQL для получения данных из одной или нескольких таблиц. Обычно используется в обзорах или при получении информации для определенного набора критериев.
SET RELATION Устанавливает отношение между двумя открытыми таблицами.
SET RELATION OFF Разрывает установленное отношение между родительской таблицей в текущей рабочей области и связанной с ней дочерней таблицей.
SET SKIP Создает отношение один-ко-многим между таблицами.
MODIFY GENERAL Открывает окна редактирования для полей типа General из текущей записи.
MODIFY MEMO Открывает окнo редактирования для полей типа memo из текущей записи.
MODIFY QUERY Открывает конструктор запросов, в котором можно модифицировать или создать запрос.
MODIFY STRUCTURE Отображает диалоговое окно Конструктор таблиц, в котором можно модифицировать структуру таблицы.
Удаление данных в FoxPro производится с помощью следующих команд:
- ERASE<файл>- удаление любого не открытого в данный момент файла;
- ZAP - удаление всех записей в активном файле базы данных;
- DELETE[<границы>][FOR/WHILE<условие>]-пометка к удалению записей в указанных границах;
- PACK-физическое удаление помеченных ранее записей и сжатие файла;
- RECALL-снятие пометок к удалению.
Поиск данных. Отбор и просмотр записей может осуществляться с помощью команд DISPLAY и LIST с заданными условиями.
Но последовательный поиск одной записи производится командой Locate.
LOCATE FOR<условие>[<границы>][WHILE<условие>]
Например, LOCATE FOR fio='Иванов'.
Для продолжения поиска с заданным условием служит команда CONTINUE.
Для ускорения поиска данных производится индексирование базы данных. Один файл базы данных может быть проиндексирован по нескольким полям. Формат команды обычного индексного файла имеет вид:
INDEX ON <выр> TO <IDX-файл>[FOR<условие>][COMPACT]
Опция COMPACT используется для создания компактного IDX-файла. Если индексный файл уже существует, то при открытии базы данных необходимо открыть и индексный файл: USE kadrs INDEX kadrfio или произвести установку индексного файла командой SET INDEX TO kadrfio. Индексный файл не только упорядочивает базу данных для просмотра, но и ускоряет поиск в ней по ключу, заданному в индексе с помощью команды: SEEK<выражение>
Пример. USE kadrs INDEX kadrfio
SEEK 'Петров'
DISPLAY
Команды экранного ввода/вывода
?/?? - самая простая команда вывода,
\ и \\ - вывод строки текста,
TEXT - ENDTEXT - удобная для вывода значительных объемов текста,
@ n,m SAY <выражение> [PICTURE<шаблон>]- форматированный вывод,
где n=0-24 -номер строки, m=0-79 - номер колонки.
INPUT, ACCEPT - операторы ввода,
WAIT - оператор ввода с ожиданием,
@ n,m GET <переменная> [PICTURE<шаблон>]
READ - форматированный ввод.
Команды управления служат для изменения хода выполнения программ. К командам управления относятся следующие операторы:
Команда IF.
IF <условие>
<команды>
[ELSE
<команды>
ENDIF
Команда DO CASE.
DO CASE
CASE <условие 1>
<команды>
CASE <условие 2>
<команды>
...
[OTHERWISE
<команды>
ENDCASE
Цикл с условием.
DO WHILE<условие>
<команды>
ENDDO
Цикл с параметром
FOR i=n TO m [STEP l]
<команды>
ENDFOR
Цикл сканирования базы данных (обработка от первой записи до последней)
SCAN [<границы>][FOR/WHILE<условие>]
<команды>
ENDSCAN
6. Распределенная обработка данных. Проблемы распределенной обработки.
При размещении БД на персональном компьютере, который не находится в сети, БД всегда используется в монопольном режиме. Даже если БД пользуются несколько пользователей, они могут работать с ней только последовательно, и поэтому вопросов о поддержании корректной модификации БД в этом случае не стоит, они решаются организационными мерами, то есть определением требуемой последовательности работы конкретных пользователей с соответствующей БД (сначала на компьютере работает один пользователь, а затем другой).
Однако работа на изолированном компьютере с небольшой БД в настоящий момент становится уже нехарактерной для большинства приложений. БД отражает информационную модель реальной предметной области, она растет по объему и резко увеличивается количество приложений, работающих с единой БД. Компьютеры объединяются в локальные сети и необходимость распределения приложений, работающих с единой БД по сети, является несомненной.
Даже когда БД строится для небольшой фирмы, например, торговой, появляется ряд особых, специфических пользователей, которые могут быть территориально разделены (например, находиться в разных помещениях), но которым необходимо работать с единой базой данных.
Введем два термина, которые необходимо различать:
1) Система распределенной обработки данных - это система, в которой БД расположена на одной машине и к ней (БД) возможен параллельный доступ нескольких пользователей.
2) Система распределенных БД - это система, в которой БД распределена по нескольким компьютерам, расположенным в сети, и к ней (БД) возможен параллельный доступ нескольких пользователей. Рассмотрим режимы работы с БД. Их можно представить в следующем виде:
Определим терминологию, которая потребуется для дальнейшей работы. Пользователь БД - программа или человек, обращающийся к БД на ЯМД (языке манипулирования данными).
Запрос - процесс обращения пользователей к БД с целью ввода, получения или изменения информации в БД.
Удаленный запрос - запрос, который выполняется с использованием модемной связи.
Распределенный запрос - запрос, при обработке которого используются данные из БД, расположенных в разных узлах сети. Транзакция - последовательность операций модификации данных в БД, переводящая БД из одного непротиворечивого состояния в другое непротиворечивое состояние.
Логическая структура БД - определение БД на физически независимом уровне, ближе всего соответствует концептуальной модели БД. Топология БД = Структура распределенной БД - схема распределения физической БД по сети.
Локальная автономность - означает, что информация локальной БД и связанные с ней определения данных, принадлежат локальному владельцу и им управляются.
Возможность реализации удаленной транзакции - обработка одной транзакции, состоящей из множества SQL-запросов, на одном удаленном узле.
Поддержка распределенной транзакции - допускает обработку транзакции, состоящей из нескольких SQL-запросов, которые выполняются на нескольких узлах сети (удаленных или локальных), но каждый запрос в этом случае обрабатывается только на одном узле, то есть запросы не являются распределенными. При обработке одной транзакции разные локальные запросы могут обрабатываться в разных узлах сети.
Системы распределенной обработки данных в основном связаны с первым поколением БД, которые строились на мультипрограммных операционных системах и использовали централизованное хранение БД на устройствах внешней памяти центральной ЭВМ и терминальный пользовательский режим доступа к ней. При этом пользовательские терминалы не имели собственных ресурсов - то есть процессоров и памяти, которые могли бы использоваться для хранения и обработки данных. Первой полностью реляционной системой, работающей в многопользовательском режиме, была СУБД SYSTEM R, разработанная фирмой IBM. Именно в ней были реализованы как язык манипулирования данными (ЯМД) SQL, так и основные принципы синхронизации, применяемые при распределенной обработке данных.
Процесс объединения компьютеров среднего класса (mainframe-систем) и переход к открытым распределенным информационным системам поставили перед разработчиками СУБД ряд сложных задач. Главная задача состояла в сложности перехода от централизованного управления данными на одном компьютере и СУБД, использовавшей собственные модели, форматы представления данных и языки доступа к данным и т.д., к распределенной обработке данных в неоднородной вычислительной среде, состоящей из соединенных в глобальную сеть компьютеров различных моделей и производителей.
В то же время происходит встречный процесс - бурный рост производительности персональных компьютеров, появление локальных сетей. Высокие темпы роста производительности и функциональных возможностей PC привлекли внимание разработчиков СУБД и привели к активному распространению СУБД на платформе персональных компьютеров.
Сегодня наблюдается явная тенденция создания информационных систем на такой платформе, которая точно соответствовала бы ее масштабам и задачам.
Правда, следует отметить, что большие ЭВМ сохраняются и сосуществуют с современными открытыми системами, что объясняется значительными вложениями в эти разработки в прошлом и успешной эксплуатацией, несмотря на моральное старение.
С точки зрения хронологии, взаимодействие между программами последовательно приобретало следующие формы:
- обмен: программы различных систем посылают друг другу сообщения (как правило, файлы);
- разделение: имеется непосредственный доступ к ресурсам нескольких машин (совместное пользование файлом, например);
- совместная работа: машины играют в реализации программы взаимодополняющие роли.
Рассмотрим пример, иллюстрирующий эту эволюцию. Речь пойдет о проектировании в области механики; традиционный подход заключается в следующем:
- построение "проволочной модели" (maillage) (графического представления геометрии физической модели) на рабочей станции;
- перенос на ЭВМ Cray файла модели, вводящего код вычислений;
- результаты расчетов, выполненных на ЭВМ Cray переносятся на рабочую станцию и обрабатываются графическим постпроцессором.
Этот способ обладает следующими недостатками:
- обмен данными производится посредством переноса файлов с одной машины на другую;
- обработка файлов осуществляется последовательно, в то время как расчеты на ЭВМ Cray только выиграли бы, если было бы возможно обеспечить взаимодействие с пользователем, используя графические и эргономические возможности рабочей станции, а некоторые расчеты, осуществляемые на последней, лучше было бы выполнить на машине Cray.
Для того, чтобы избавиться от этих неудобств, необходимо перейти от вышеназванных вариантов решения задач к применению методики совместной работы, на основе понятия "прозрачности". Пользователь будет видеть только одну машину (свою станцию) и только одну прикладную программу. Распределенная обработка данных, таким образом, представляет собой программу, выполнение которой осуществляется несколькими системами, объединенными в сеть. Как правило, расчетная часть программы выполняется на мощном процессоре, а визуальное отображение выводится на рабочей станции с улучшенной эргономичностью. Разделение опирается на модель "клиент-сервер", к которой мы еще вернемся. Этот вид обработки данных организуется по принципу треугольника (рис.2.4.):
- пользователь обладает рабочей станцией;
- решение задач требует обращения к устройству обработки данных (спецпроцессору, например) и к серверу данных, и все это прозрачно для пользователя.
Рис 2.4. Треугольная организация вычислительного процесса
2.5. Цели распределенной обработки данных
Целью распределенной обработки данных является оптимизация использования ресурсов и упрощение работы пользователя (что может вылиться в усложнение работы разработчика). Каким образом ?
- Оптимизация использования ресурсов.
Термин ресурс, в данном случае используется в самом широком смысле: мощность обработки (процессоры), емкость накопителей (память или диски), графические возможности (2-х или 3-х мерный графический процессор, в сочетании с растровым дисплеем и общей памятью), периферийные устройства вывода на бумажный но- ситель (принтеры, плоттеры). Эти ресурсы редко бывают собраны на одной машине: ЭВМ Cray обладает мощными расчетными возможностями, но не имеет графических возможностей, а также возможностей эффективного управления данными. Отсюда принцип совместной работы различных систем, используя лучшие качества каждой из них, причем пользователь имеет их в распоряжении при выполнении только одной программы.
- Упрощение работы пользователя.
Действительно, распределенная обработка данных позволяет:
- повысить эффективность посредством распределения данных и видов обработки между машинами, способными наилучшим образом управлять ими;
- предложить новые возможности, вытекающие из повышения эффективности;
- повысить удобство пользования. Пользователю более нет необходимости разбираться в различных системах и осуществлять перенос файлов.
Основные недостатки этого подхода заключаются в следующем: - зависимость от характеристик и доступности сети. Программа не сможет работать, если сеть повреждена. Если сеть перегружена, эффективность уменьшается, а время реакции систем увеличивается. - проблемы безопасности. При использовании нескольких систем увеличивается риск, так как появляется зависимость от наименее надежной машины сети.
C другой стороны, преимущества весьма ощутимы:
- распределение и оптимизация использования ресурсов. Это основная причина внедрения распределенной обработки данных;
- новые функциональные возможности и повышение эффективности при решении задач;
- гибкость и доступность. В случае поломки одной из машин, ее пытаются заменить другой, способной выполнять те же функции.
7. Совместное использование таблиц в Foxpro2. Команды, обеспечивающие связь таблиц.
Как обычно, в FoxPro существует путаница и с этим понятиями. Точнее так, эта путаница возникла при включении в среду FoxPro такого объекта как Контейнер базы данных. Впрочем, по порядку.
Итак, в FoxPro термин "связь" или "отношение" применяется в следующих случаях
* Постоянная связь - это некоторый графический объект, визуально отображающий взаимосвязь двух таблиц между собой в контейнере базы данных
* Связь - это некоторая настройка, накладываемая на две таблицы и определяющая положение указателя записи в подчиненной таблице при перемещении указателя записи в главной таблице
* Связь - это некоторый графический объект, визуально отображающий взаимосвязь таблиц в предыдущем смысле, но отображаемая в DataEnvironment формы или отчета
Ну, третий вариант термина "связь" я здесь рассматривать не буду, поскольку это фактически просто визуализация термина "связь" во втором его смысле. Поэтому подробно рассмотрю только первые два определения
Постоянная связь (persistent relationship)
Повторю здесь еще раз свое определение термина "постоянная связь"
Постоянная связь - это некоторый графический объект, визуально отображающий взаимосвязь двух таблиц между собой в контейнере базы данных
Обращаю внимание на то, что это именно "графический объект". Он не несет за собой никакого физического смысла.
Но если "постоянная связь" не имеет физического смысла, то для чего же она используется? Вероятно, точнее, следовало бы определить "постоянную связь", как некоторый шаблон, который используется при создании других объектов. Собственно, я знаю только о трех применениях "постоянной связи"
* Для настройки и создания определенного вида триггеров в Referential Integrity
* Автоматически предлагает создать обычную связь между таблицами, при включении их в DataEnvironment формы или отчета
* Автоматически предлагает взаимосвязь нужного вида JOIN при включении таблиц в дизайнер запросов (Query или Local View)
Обратите внимание, что связь в DataEnvironment (или в дизайнере запросов) уже не имеет никакого отношения к "постоянной связи" в контейнере базы данных.
Да, она может быть создана автоматически на основе существующей "постоянной связи", но это будет исключительно рекомендация, с которой Вы можете согласиться или НЕ согласиться и удалить ее из DataEnvironment (или в дизайнере запросов)
Программно "постоянная связь" настраивается через команду ALTER TABLE, используя ключевое слово REFERENCES. "Постоянная связь" всегда устанавливает связь между тэгами структурных индексных файлов связываемых таблиц. Причем хотя бы в одной из таблиц этот тэг должен иметь тип "Primary". Т.е. связь должна быть либо один-к-одному, либо один-ко-многим. Но никак не много-ко-многим.
Связь вообще и "постоянную связь" в частности нельзя настроить дважды между одними и теми же таблицами. Пусть и по разным критериям. В FoxPro такое недопустимо, даже если связь осуществляется через таблицы посредники.
Т.е. если уж вы настроили связь между двумя таблицами, то другую связь между этими же таблицами Вы можете создать только взамен существующей, но никак не одновременно с ней. Попытка организации такой связи вызовет сообщение об ошибке.
"Постоянная связь" может быть настроена "сама на себя". Т.е. можно установить постоянную связь между двумя индексами одной и той же таблицы. Это имеет смысл, если таблица имеет "древовидную" структуру и Вы хотите установить триггер на удаление по типу "Restrict" (установить триггер на удаление по типу "Cascade" - не получится, точнее он не будет работать, поскольку в FoxPro запрещена рекурсия триггеров).
Конечно, можно использовать "постоянную связь" и в качестве визуализации взаимоотношений таблиц в контейнере базы данных. Я имею в виду, что когда Вы открываете контейнер базы данных на модификацию, то Вы видите некоторую картинку структуры базы данных. Вы можете передвинуть объекты так, чтобы визуально проще было понять структуру базы данных.
Так-то оно так, да вот FoxPro имеет весьма слабый инструментарий для полноценного проектирования базы данных. Вот и эта картинка. Физически она хранится в файле ресурсов FoxUser.dbf (fpt). Т.е. если Вы переносите проект на новое место (в другую папку, на другой компьютер), то чтобы картинка не сбилась, надо будет захватить и файл ресурсов. Подробнее о том, как это сделать читайте в разделе Содержимое главной директории проекта
Проблема в том, что файл ресурсов время от времени приходится удалять или хотя бы чистить. Т.е. есть серьезный риск, что через месяц другой, картинка все-таки собьется. После двух...трех таких восстановлений останется только плюнуть на эту возню и заняться чем-то более полезным.
Для полноценного проектирования базы данных лучше использовать другие продукты, которые имеют общее название: Case - средства для проектирования базы данных. Из наиболее известных это:
* Power Designer - считается самым лучшим
* ERWin - пожалуй, самый известный в паре с BPWin
* Visio - знаменит тем, что это продукт MicroSoft, который был русифицирован, и можно найти бесплатную версию в Internet
В принципе была попытка создать полноценное средство для проектирования базы данных в FoxPro. Этот продукт получил название FoxCase. Но ни широкого распространения, ни полноценного развития он так и не получил.
Связь (обычная)
В принципе, в противовес "постоянной связи" этот вид связи следовало бы назвать "временная связь". В том смысле, что данный тип связи устанавливается "по требованию". Т.е. вот надо мне в этом месте организовать связь, я тут же ее и организовываю, используя команду SET RELATION. Отпала в ней надобность - тут же и удаляю. Или она сама удалится при закрытии одной из связанных таблиц.
Это так надо бы было назвать, но дело в том, что данный вид связи исторически появился раньше, чем "постоянная связь". Еще в версии FoxPro for DOS. Когда "постоянной связи" еще в проекте не было. А поскольку не было необходимости этот вид связи от чего-то отличать, то его так и назвали "связь". Без каких-либо уточняющих прилагательных.
Поэтому, когда в FoxPro используют термин "связь", то, скорее всего, речь идет именно об этой связи. Если же говорят о "постоянной связи", то обязательно добавляют уточняющее прилагательное "постоянная".
Итак, что же такое "связь" в FoxPro
Связь- это некоторая настройка, накладываемая на две таблицы и определяющая положение указателя записи в подчиненной таблице при перемещении указателя записи в главной таблице
Все. На этом функции связи заканчиваются. Более того, связь действует только до тех пор, пока вы находитесь в рабочей области главной таблицы. Стоит Вам перейти в рабочую область подчиненной таблицы, как всякие ограничения перестают действовать, и Вы можете спокойно переместить указатель записи на абсолютно любую запсь.
Можно сказать, что связь - это взгляд на подчиненную таблицу со стороны главной. Не то, что есть подчиненная таблица на самом деле, а то, как ее видит главная таблица. Изменяя "точку зрения" (текущую рабочую область) мы по-другому видим и подчиненную таблицу.
Между парой таблиц нельзя установить несколько связей одновременно. Неважно, сколько таблиц посредников было использовано. Попытка установить дублирующую связь вызовет сообщение об ошибке. Ну, действительно, если бы было настроено сразу две связи, то на какую запись в подчиненной таблице надо было бы установить указатель записей при перемещении в главной таблице? Вот возникновение данной неопределенности и является причиной подобного запрета.
В отличие от "постоянной связи", обычная связь не требует наличия индекса в главной таблице, но вот в подчиненной таблице индекс должен быть и более того, этот индекс должен быть главным. Одна из распространенных ошибок - это переключение главного индекса в подчиненной таблице. При этом настроенная связь не разрывается, но вот результат ее действия становится весьма неопределенным.
Еще одна тонкость заключается в том, что связь можно настроить не по полному, а по частичному (по первым символам) совпадению ключа. Разумеется, если используется настройка SET EXACT OFF (это настройка по умолчанию).
Например, если подчиненная таблица имеет 2 поля ParentID и NickName и требуется упорядочить записи в пределах каждого значения ParentID в алфавитном порядке NickName, то в подчиненной таблице строится примерно такой индекс:
INDEX ON ParentID+NickName TAG SortOrd
Здесь я предполагаю, что ParentID - это поле символьного типа. Тогда в главной таблице настраивается связь по выражению только ParentID
SET RELATION TO ParentID INTO ChildTab
В результате, связь между таблицами будет настроена по значению поля ParentID, но в пределах одного значения ParentID в подчиненной таблице записи буду упорядочены в алфавитном порядке значений поля NickName
Строго говоря, команда SET RELATION TO устанавливает связь по типу один-к-одному. Т.е. если реально связь имеет вид один-ко-многим, то Вы не увидите этих "многих". Отображаться будет только первая попавшаяся запись дочерней таблицы. Для установки связи один-ко-многим после команды SET RELATION TO следует дать команду SET SKIP TO. В подавляющем большинстве случаев использовать команду SET SKIP TO нет необходимости. Надобность в ней возникает только в случае визуального отображения связи вида один-ко-многим. Если речь идет о программировании, то стоит ограничиться только командой SET RELATION TO
Если Вы работаете с DataEnvironment формы или отчета, то установка связи между таблицами фактически означает команду SET RELATION. А установка значения свойства объекта Relation.OneToMany = .T. фактически означает команду SET SKIP TO. Еще раз напомню, для правильной работы связи просто необходимо установить главный индекс в подчиненной таблице. Т.е. свойство Order соответствующего объекта Cursor. Индекс главной таблицы на работу связи никак не влияет.
8. Понятие о модели Клиент-Сервер в технологии баз данных.
Модели клиент-сервер - это технология взаимодействия в информационной сети. Сервер обладает правом управления тем или иным ресурсом, а клиент – пользования им. Каждый конкретный сервер определяется видом того ресурса, которым он владеет. Например, назначением сервера баз данных является обслуживание запросов клиентов, связанных с обработкой данных; файловый сервер, или файл-сервер, распоряжается файловой системой.
Этот принцип распространяется и на взаимодействие программ. Программа, выполняющая предоставление соответствующего набора услуг, рассматривается в качестве сервера, а программы, пользующиеся этими услугами, принято называть клиентами. Программы имеют распределенный характер, т.е. одна часть функций прикладной программы реализуется в программе-клиенте, а другая - в программе-сервере, а для их взаимодействия определяется некоторый протокол.
Рассмотрим эти функции. Один из основных принципов технологии клиент-сервер заключается в разделении функций стандартного интерактивного приложения на четыре группы, имеющие различную природу:
· Функции ввода и отображения данных.
· Прикладные функции, характерные для данной предметной области (для банковской системы - открытие счета, перевод денег и т.д.).
· Функции хранения и управления информационно-вычислительными ресурсами (базами данных, файловыми системами и т.д.).
· Служебные функции, осуществляющие связь между функциями первых трех групп.
В соответствии с этим в любом приложении выделяются следующие логические компоненты: компонент представления (presentation), реализующий функции первой группы; прикладной компонент (business application), поддерживающий функции второй группы; компонент доступа к информационным ресурсам (resource manager), поддерживающий функции третьей группы, а также вводятся и уточняются соглашения о способах их взаимодействия (протокол взаимодействия).
Различия в реализации технологии клиент-сервер определяются следующими факторами: видами программного обеспечения, в которые интегрирован каждый из этих компонентов; механизмами программного обеспечения, используемыми для реализации функций всех трех групп; способом распределения логических компонентов между компьютерами в сети; механизмами, используемыми для связи компонентов между собой.
Выделяются четыре подхода, реализованные в следующих моделях:
· модель файлового сервера (File Server - FS);
· модель доступа к удаленным данным (Remote Data Access - RDA);
· модель сервера баз данных (Data Base Server - DBS);
· модель сервера приложений (Application Server - AS).
Модель сервера баз данных (DBS) -реализована в некоторых реляционных СУБД (Informix, Ingres, Sybase, Oracle), (рис.5.3).
Ее основу составляет механизм хранимых процедур - средство программирования SQL-сервера. Процедуры хранятся в словаре баз данных, разделяются между несколькими клиентами и выполняются на том же компьютере, где функционирует SQL-сервер. В DBS-модели компонент представления выполняется на компьютере-клиенте, в то время как, прикладной компонент оформлен как набор хранимых процедур и функционирует на компьютере-сервере БД. Там же выполняется компонент доступа к данным, т.е. ядро СУБД.
Понятие информационного ресурса сужено до баз данных, поскольку механизм хранимых процедур - отличительная характеристика DBS-модели - имеется пока только в СУБД.
Достоинства DBS-модели:
· возможность централизованного администрирования прикладных функций;
· снижение трафика (вместо SQL-запросов по сети направляются вызовы хранимых процедур);
· возможность разделения процедуры между несколькими приложениями;
· экономия ресурсов компьютера за счет использования единожды созданного плана выполнения процедуры.
К недостаткам относится: ограниченность средств написания хранимых процедур, представляющих собой разнообразные процедурные расширения SQL, которые уступают по изобразительным средствам и функциональным возможностям в сравнении с языками С или Pascal. Сфера их использована ограничена конкретной СУБД из-за отсутствия возможности отладки и тестирования разнообразных хранимых процедур.
На практике чаще используются смешанные модели, когда целостность базы данных и некоторые простейшие прикладные функции обеспечиваются хранимыми процедурами (DBS-модель), а более сложные функции реализуются непосредственно в прикладной программе, которая выполняется на компьютере-клиенте (RDA-модель).
Модель сервера приложений (AS) - представляет собой процесс, выполняемый на компьютере-клиенте (рис.5.4), отвечающий за интерфейс с пользователем (т.е. реализует функции первой группы).
Прикладной компонент реализован как группа процессов, выполняющих прикладные функции, и называется сервером приложения (Application Server - AS).
Доступ к информационным ресурсам осуществляет менеджер ресурсов (например, SQL-сервер). Из прикладных компонентов доступны такие ресурсы как, базы данных, очереди, почтовые службы и др. AS, размещенная на компьютере, где функционирует менеджер ресурсов, избавляет от необходимости направления SQL-запросов по сети, что повышает производительность системы.
Модели RDA и DBS опираются на двухзвенную схему разделения функций:
· в RDA-модели прикладные функции отданы программе-клиенту
· в DBS-модели ответственность за их выполнение берет на себя ядро СУБД.
В AS-модели реализована трехзвенная схема разделения функций. Здесь прикладной компонент выделен как важнейший изолированный элемент приложения. Сравнивая модели, AS обладает наибольшей гибкостью и имеет универсальный характер.
9. Этапы развития баз данных. Использование файлов и файловых систем в качестве баз данных.
Этапы развития БД:
1. файлы и файловые системы
-повторяемость данных и не позволяют СУБД заглядывать в их содержание.
2. БД на больших ЭВМ
-низкоинтеллектуальный(только вывод информации)
3. эпоха ПК
-огромная избыточность и повторяемость данных
4. распределенные БД
+лишились дублирования
-незащищенность
5. Особенность настоящего периода-период интранет.
Файлы и файловые системы
Наличие устройств для хранения большого количества информации привело к разработке и внедрению централизованных систем управления файлами, которые взяли на себя распределение внешней памяти, отображение имен файлов в соответствующие адреса во внешней памяти и обеспечение доступа к данным. Такие системы дают возможность:
создания файла,
открытия ранее созданного файла,
чтения некоторой записи из файла (текущей, следующей, предыдущей, первой, последней),
занесения в файл новой записи на место текущей или добавления новой записи в конец файла.
Увы! Файловые системы оказались не очень хорошо приспособленными к работе с системами хранения и управления информацией.
1) В разных файловых системах эти операции могли несколько отличаться, но общий смысл их был именно таким. Главное, что следует отметить, это то, что для извлечения некоторой информации из файла надо было точно знать структуру файла данных с точностью до бита. Важно, чтобы этим знанием обладали программы, которые с ним (файлом данных) работали.
При этом система управления файлами эту структуру не знала. Поэтому каждая программа, работающая с файлом, должна была иметь у себя внутри структуру данных, соответствующую структуре этого файла. Всякое изменение структуры БД требовало новой компиляции всех программ, работающих с файлом. Такая ситуация характеризовалась как зависимость программы от данных.
Указанный недостаток был первым существенным недостатком файловых систем, который явился толчком к созданию новых систем хранения и управления информацией.
2) Для разных файловых систем серьезное администрирование режимов доступа не предусматривалось вообще или устанавливалось с помощью подхода, впервые реализованного в ОС UNIX. В последнем случае каждому пользователю соответствует пара идентификаторов, определяющих группу, к которой относится пользователь, и номер пользователя в группе, с помощью которых определяются доступные действия с файлом для каждого пользователя. При этом для каждого такого файла хранится идентификатор пользователя, который создал этот файл, и фиксируется, какие действия с файлом может производить создатель, а какие действия доступны пользователям той же группы и других групп.
Отсутствие централизованных методов управления доступом к информации, относящейся к одной предметной области, послужило еще одной причиной разработки СУБД.
3) При работе с системами хранения и обработки информации стала очевидной необходимость обеспечения эффективной параллельной работы многих пользователей с одними и теми же файлами. Операционные системы обеспечивали возможность совместного чтения файла. Однако возможности операционных систем при ситуации, когда один из пользователей будет изменять файл, были такими, что подобный режим работы либо совсем не реализовался, либо выполнялся очень замедленно. Обычно запаздывающему процессу обращения к файлу (файл уже открыт другим процессом ‑ опережающим) сообщалось о невозможности открытия файла, либо он блокировался до тех пор, пока не выполнялась операция закрытия файла опережающим процессом.
Резюмируя, можно отметить следующие ограничения, присущие файловым системам.
Разделение и изоляция данных. Это приводит к затруднениям при организации доступа к этим данным и их последующей обработки.
Дублирование данных. В файловой системе фактически поощряется бесконтрольное дублирование данных. Однако такое дублирование сопровождается, с одной стороны, неэкономным расходованием ресурсов (памяти), а с другой – может привести к нарушению целостности данных, поскольку данные по одному вопросу могут стать противоречивыми.
Зависимость от данных. Физическая структура и способ хранения записей файлов данных жестко фиксируются в коде программы приложений. Любое изменение данных обязательно требуют и изменения в коде обрабатывающего приложения.
Несовместимость файлов. Структура файлов данных определяется кодом приложения, т.е. зависит от языка программирования этого приложения. Несовместимость файлов данных, созданных с использованием разных языков, затрудняет процесс их совместной обработки. Для совместного использования файлов данных требуется программа, преобразующая данные из этих файлов в некоторый общий формат.
Фиксированные запросы / быстрое увеличение количества приложений. Все требуемые запросы из файлов данных с использованием файловых систем должны создаваться программистом. Изобилие вариантов запросов приводит к тому, что программисты оказываются не в силах справиться с потоком задач и успевают обеспечить только фиксированное, ограниченное число запросов, либо в попытке обеспечить приложениями всех клиентов обнаруживают, что они не в силах удовлетворить всех заказчиков.
Именно по этим причинам начал разрабатываться новый подход к управлению информацией, который был реализован в рамках новых программных средств, названных впоследствии системами управления базами данных (СУБД).
10. Двухуровневые модели клиент-серверного взаимодействия.
Двухуровневая модель является фактически результатом распределения пяти функций между двумя процессами, которые выполняются на двух платформах: на клиенте и на сервере. В чистом виде почти никакая модель не существует, однако для каждой модели можно указать наиболее характерные особенности.
1) Модель удаленного управления данными (иначе, модель файлового сервера).
Презентационная логика и бизнес-логика размещаются на клиенте. На сервере располагаются файлы с данными и поддерживается доступ к файлам. Функции управления информационными ресурсами находятся на клиенте. Механизм управления информационными ресурсами находится на клиенте. Монопольное приложение разделено на два взаимодействующих процесса. Сервер может обслуживать множество клиентов, которые обращаются к нему с запросами. Собственно СУБД должна находиться в этой модели на клиенте.
Как выполняется запрос клиента?
Запрос формулируется на ЯМД. СУБД переводит его в последовательность файловых команд. Каждая файловая команда вызывает перекачку блока информации на клиента. СУБД на клиенте анализирует полученную информацию, и если данных недостаточно, принимается решение о перекачке следующего блока. Перекачка продолжается до получения полного ответа на запрос клиента.
Недостатки модели:
-Высокий сетевой трафик из-за передачи множества блоков и файлов.
-Узкий спектр операций, определяемый только файловыми командами. Отсутствие хороших средств безопасности доступа к данным (защита только на уровне файловой системы).
2) Модель удаленного доступа к данным.
База данных хранится на сервере. На сервере же находится ядро СУБД.
На клиенте – презентационная логика и бизнес-логика приложения. Клиент обращается к серверу с запросами на языке SQL.
Преимущества:
-Сервер разгружен от компонентов представления и прикладного.
-Сервер занят только операциями обработки данных, запросов и транзакций, не занимаясь вопросами пересылки файлов.
-Резко уменьшается загрузка сети: передаются только SQL-запросы и результаты их выполнения.
Недостатки:
-Даже на SQL при интенсивной работе клиентов запросы могут существенно загрузить сеть.
-Презентационная логика и бизнес-логика излишне дублируются на различных клиентских приложениях.
-Сервер играет пассивную роль. Каждое приложение должно содержать дублирующиеся компоненты, которые должны выполняться при каждом запуске аналогичных приложений.
3) Модель сервера баз данных.
В этой модели бизнес-логика разделена между клиентом и сервером.
На сервере бизнес-логика реализована в виде хранимых процедур - специальных программных модулей, которые хранятся в БД и управляются непосредственно СУБД.
Клиентское приложение обращается к серверу с командой запуска хранимой процедуры, а сервер выполняет эту процедуру и регистрирует все изменения в БД, которые в ней предусмотрены.
Сервер возвращает клиенту данные, отвечающие на его запрос, необходимые клиенту для вывода на экран, либо для выполнения той части бизнес логики, которая расположена на клиенте. Трафик обмена информацией существенно уменьшается.
Централизованный контроль в модели сервера баз данных выполняется с использованием механизма триггеров. Триггеры также являются частью БД. Триггер в БД является как бы некоторым тумблером, который срабатывает при возникновении определенного события в БД. Ядро СУБД контролирует все события, которые вызывают созданные и описанные триггеры в БД. При возникновении соответствующего события сервер запускает соответствующий триггер. А триггер представляет собой также некоторую программу, которая выполняется над базой данных. Триггеры могут вызывать хранимые процедуры. При срабатывании одного триггера могут возникать события, которые вызовут срабатывание других триггеров.
В данной модели сервер является активным, потому что не только клиент, но и сам сервер может быть инициатором обработки данных в БД.
И хранимые процедуры и триггеры хранятся в БД и могут быть использованы разными клиентами в разных клиентских приложениях.
Недостаток модели:
Очень большая загрузка сервера. Здесь большая часть бизнес-логики приложений переложена на сервер, зато существенно уменьшаются требования к клиентам.
Модель сервера приложений вляется расширением двухуровневой модели, в ней вводится дополнительный промежуточный уровень между клиентом и сервером, который содержит один или несколько серверов приложений.
11. Базы данных на больших ЭВМ. Базы данных на ПК.