Файл-серверные приложения

Сущ-т различные треб-я и задачи, след выбираются различн арх-ры. Орг-я ИС на основе исп-я выделенных файл-серверов все еще является наиб распространенной в связи с наличием больш кол-ва ПК разного ур-ня развитости и сравнительной дешевизны связывания PC в локальные сети. При опоре на ф-с арх-ры сохр-ся автономность прикладного (и большей части системного) ПО, работающего на кажд PC сети. Компоненты ИС, выполняемые на разных PC, взаимодействуют только за счет наличия общего хранилища ф-лов, к-е хранится на ф-с-ре. В классическом случае в каждPC дублируются не только прикладные программы, но и ср-ва упр-я базами данных. Ф-с представляет собой разделяемое всеми PC комплекса расширение дисковой памяти. (клиент: приклад часть упр-я БД, сетевой д-п→ ф-с). Осн + явл простота орг-и. Имеются удобные и развитые ср-ва разработки графич польз-го интерфейса, простые в исп-и ср-ва разработки с-м БД и/или СУБД. Но во многом эта простота является кажущейся. Во-первых, ИС предстоит работать с БД. Следовательно, эта БД д-на быть спроектирована. Естественно, сложность проектир-я БД опр-ся объективной сложностью моделируемой предметной обл-ти. Мин усл-ми, при соблюдении к-х м-о удовлетворить эти требования, являются: наличие транзакционного упр-я, хранение избыточных д (например, с применением методов журнализации), возм-ть формулировать огр-я цел-ти и проверять их соблюдение. В принципе, ф-с орг-я не противоречит соблюдению отмеченных усл-й. В кач-ве примера системы мо привести популярный в прошлом "сервер баз данных" Informix SE. При исп-и этой с-мы копия ПО СУБД поддерживалась для кажд инициированного поль-лем сеанса работы с СУБД. Для кажд поль-льского пр-са, взаимод-го с БД создавался служебный процесс СУБД, к-й вып-ся на том же пр-ре, что и польз-й пр-с (на стороне клиента. Вся синхронизация возможной параллельной работы с БД производилась на ур-не ф-лов внешней памяти, сод-х БД. Условимся впредь называть такие СУБД не серверами БД, а с-ми упр-я БД, осн-ми на Ф-с арх-ре (СУБД-ФС). Под истинным сервером БД мы будем понимать пр-ное образование, привязанное к соотв БД, сущ-ющее, независимо от сущ-я польз-ских (клиентских) пр-сов и выполняемое на выделенной аппаратуре. Истинные серверы БД сущ-но сложнее по орг-и, чем СУБД-ФС, на зато обеспечивают более тонкое и эффективное упр-е БД. В третьих, интерфейс развитых серверов БД основан на исп-и высокоуровневого языка БД SQL, что позволяет исп-ть сетевой трафик между клиентом и сервером БД только в полезных целях (от клиента к серверу в основном пересылаются операторы языка SQL, от сервера к клиенту - результаты выполнения операторов). В ф-с орг-и клиент работает с удаленными ф-лами, что вызывает существенную перегрузку трафика (поскольку СУБД-ФС работает на стороне клиента, то для выборки полезных данных в общем случае необходимо просмотреть на стороне клиента весь соответствующий файл целиком). В целом, в ф-с арх-ре мы имеем "толстого" клиента и очень "тонкий" сервер в том смысле, что почти вся работа выполняется на стороне клиента, а от сервера требуется только достаточная емкость дисковой памяти. Простое, работающее с небольш объемами инф-и и рассчитанное на применение в однополь-ком режиме, ф-с приложение можно спроектировать, разработать и отладить очень быстро.

№20 Клиент-серверные приложения.Под к-с приложением мы будем понимать ИС, осн-ю на исп-и серверов БД. (Клиент: клиентская часть прил-я, клиентская часть упр-я БД, сетевой д-п→сервер БД серверная часть прил-я). На стороне кл вып-ся код прил-я, в к-й обязательно входят компоненты, поддерживающие интерфейс с конечн поль-лем, производящие отчеты, вып-щие др специфич для прил-ния ф-ции. Кл часть прил-я взаимодействует с кл частью ПО упр-я БД, к-я, фактически, явл-ся индивидуальным представителем СУБД для прил-я. Заметим, что интерфейс м/у кл частью прил-я и клиентской частью сервера БД основан на исп-и я-ка SQL. Поэтому такие ф-и, как предварительная обработка форм, или формирование результ-щих отчетов вып-ся в коде прил-я. Кл часть сервера БД, исп-я ср-ва сетевого д-па, обращается к серверу БД, передавая ему текст оператора языка SQL. Посмотрим теперь, что же происходит на стороне сервера БД. Сервер производит компиляцию полученного оператора. Далее происходит вып-е оп-ра. Оп-р м-т относиться к классу оп-ров опр-я объектов БД. В частности, м-т опр-ся домены, таблицы, ограничения целостности, триггеры, привилегии поль-лей, хранимые пр-ры. При вып-и оп-ра созд эле-та схемы БД соотв инф-я помещается в таблицы-каталоги БД (в таблицы метабазы данных). Огр-я цел-ти обычно сохр-ся в метабазе д прямо в текстовом представлении. Для действий, опр-х в триггерах, и хранимых пр-р выраб-ся и сохр-ся в таблицах-каталогах пр-рный вып-й код. Заметим, что ограничения целостности, триггеры и хранимые пр-ры явл-ся составляют основу серверной части прил-я. При вып-и оп-ров выборки данных на осн содержимого затрагиваемых з-сом таблиц и с исп-м поддерживаемых в БД индексов формируется результирующий набор д. Серверная часть СУБД пересылает рез-т кл части, и окончательная обр-ка производится уже в клиентской части прил-я. При вып-и оп-ров модификации сод-го БД проверяется, что не будут нарушены опр-е к этому моменту огр-я цел-ти. Далее сервер проверяет, не затрагивает ли данное изм-е усл-е срабатывания какого-либо триггера, и если такой триггер обнаруживается, вып-т пр-ру его действия. Особый класс оп-ров я-ка SQL составляют оп-ры вызова ранее опр-х и сохр-х в БД хр-мых пр-р. При вып-и оп-ра завершения транзакции сервер д-н проверить соблюдение всех, отложенных огр-ний цел-ти. Снова к проверке отложенных огр-й цел-ти м-о относиться как к вып-ю серверной части прил-я. Как видно, в к-с орг-и кл м-т явл-ся достаточно "тонкими", а сервер должен быть "толстым" настолько, чтобы быть в состоянии удовлетворить потребности всех клиентов. С другой стороны, разработчики и поль-ли ИС, осн-ных на арх-ре "к-с", часто бывают неудовлетворены постоянно существующими сетевыми накладными расходами, которые следуют из потребности обращаться от клиента к серверу с каждым очередным з-сом. На практике распространена ситуация, когда для эф-ной р-ты отдельной кл составляющей ИС в дейст-ти требуется только небольшая часть общей БД. Это приводит к идее поддержки локального кэша общей БД на стороне каждого клиента.. Как и в общем случае, для поддержки локального кэша БД ПО РС д-о сод-ть компонент упр-я БД - упрощенный вариант сервера БД, к-й, м-т не обеспечивать многопольз-кий режим д-па. Отд. пр-мой явля обесп-е согласованности кэшей и общей БД. Здесь возможны различные решения - от автоматической поддержки согласованности за счет ср-тв базового ПО упр-я БД до полного перекладывания этой задачи на прикладной ур-нь. В любом случае, клиенты становятся более толстыми при том, что сервер тоньше не делается.

№ 21Intranet-приложенияВозникновение и внедрение в широкую практику высокоуровневых служб Internet естеств образом повлияли на технологию созд-я корпоративных ИС, породив направление, известное теперь под названием Intranet. По сути дела, информационная Intranet-с-ма - это корпоративная с-ма, в к-й исп-ся м-ы и ср-ва Internet. Такая с-ма м-т быть локальной, изолир-й от ост мира Internet, или опираться на виртуальную корпоративную подсеть Internet. В последнем случае особенно важны ср-ва з-ты инф-и от несанкц-го д-па. Хотя в общем случае в Intranet-с-ме м-т исп-ся все возможные службы Internet, наиб внимание привлекает гипермедийная служба WWW. Во-первых, с исп-м я-ка гипермедийной разметки документов HTML м-о сравнительно просто разработать удобную для исп-я инф-ную стр-ру, к-я в дальнейшем будет обслуживаться одним из готовых Web-серверов. Во-вторых, наличие нескольких готовых к исп-ю кл частей - браузеров, или "обходчиков" избавляет от необх-ти создавать собственные интерфейсы с поль-ми, предоставляя им удобные и развитые механизмы д-па к инф-и (клиент: бреузер→Веб-сервер).Однако, при всех своих преимуществах (простота орг-и, удобство исп-я, стандартность интерфейсов и т.д.) эта схема обладает сильными ограничениями. Прежде всего, в ИC отсутствует прикладная обработка д. Все, что может поль-ль, это только просмотреть информацию, поддерживаемую Web-сервером. Далее, гипертекстовые стр-ры трудно модифицируются. Для того, чтобы изменить наполнение Web-сервера, необходимо приостановить работу с-мы, внести изм-я в HTML-описания и только затем продолжить нормальное функционирование. Наконец, не всегда достаточен поиск инф-и в стиле просмотра гипертекста. БД и соответствующие ср-ва выборки д по-прежнему часто необходимы. На самом деле, все перечисленные трудности м-т быть разрешены с исп-м более развитых мех-мов Web-технологии. Эти мех-мы непрерывно совершенствуются, что одновременно и хорошо и плохо. Хорошо, потому что появл-ся новые возм-ти. Плохо, потому что отсутствует стандартизация. Что касается логики приложения, то при применении Web-технологии сущ-т возм-ть ее реализации на стороне Web-сервера. Для этого м-т исп-ся два подхода - CGI (Common Gateway Interface) и API (Application Programming Interface). Оба подхода осн-ся на наличии в я-ке HTML специальных конструкций, информирующих клиента-браузера, что ему следует послать Web-серверу специальное сообщение, при получении к-го сервер д-н вызвать соотв-ю внешнюю пр-ру, получить ее рез-ты и вернуть их клиенту в стандартном формате HTTP. Аналогичная техника широко исп-ся для обеспечения унифицированного д-па к БД в Intranet-с-мах. Я-к HTML позволяет вставлять в гипертекстовые документы формы. Когда браузер натыкается на форму, он предлагает поль-лю заполнить ее, а затем посылает серверу сообщение, содержащее введенные параметры. Как правило, к ф-ме приписывается некот внешняя пр-ра сервера. При получении сообщения от кл сервер вызывает эту внешнюю пр-ру с передачей параметров поль-ля. Понятно, что такая внешняя пр-ра м-т, в частности, играть роль шлюза между Web-сервером и сервером БД. В этом случае параметры должны специфицировать з-с поль-ля к БД. Клиент↔Веб-сервер; Стандартная часть, внешняя пр-ра↔сервер БД. На пр-пах исп-я внешних пр-р основ-ся также возм-ть модификации док-тов, поддерживаемых Web-сервером, а также создание временных "виртуальных" HTML-страниц. Даже начальное введение в Intranet было бы неполным, если не упомянуть про возм-ти я-ка Java. Java - это интерпретируемый объектно-ориент я-к пр-вания. Мобильные коды (апплеты), полученные в рез-те компиляции Java-пр-мы, м-т быть привязаны в HTML-док-ту. В этом случае они поступают на сторону клиента вместе с док-том и вып-ся либо автоматически, либо по явному указанию. Апплет м. б. специализирован как шлюз к серверу БД. На наш взгляд, Intranet явл-ся удобным и мощным ср-вом разработки и исп-я ИС.

№ 22. Склады данных (DataWarehousing) и системы опер-й аналит-й обр-ки д. До сих пор мы рассматривали сп-бы и возможные арх-ры ИС, предназначенных для опер-й обр-ки д, т.е. для получ-я текущей инф-и, позволяющей решать повседневные проблемы корпорации. Однако у аналит-х отделов корпорации и у высшего звена упр-го состава имеются и др з-чи: проанализировав поведение корпорации на рынке с учетом сопутствующих внешних факторов и спрогнозировав хотя бы ближайшее будущее, выработать тактикуи стратегию корпорации. В послед неск лет все более популярным становится подход, осн-й на концепциях склада д и с-мы опер-й аналитической обр-ки д. Различие м/у опер-ными и аналит инф-ными приложения с точки зрения обеспечения треб-х д. Р идет о так называемых OLAP-с-мах (от On-Line Analitical Processing), т.е. аналит с-мах, помогающих принимать бизнес-решения за счет динамически производимых анализа, модел-я и/или прогнозирования д. 1.Склад д д-н включать как внутр корпор-е д, так и внешние данные, характеризующие рынок в целом. 2.В складе д н-но поддерживать хр-е инф-и о деят-ти корпорации и сост-и рынка на протяжении неск лет. Аналитические БД имеют объем как мин на порядок больший, чем оперативные. 3.Необходимость наличия компонента склада д, извлекающего инф-ю из оперативных БД и "очищающего" эту инф-ю. 4. Склады д для того и сущ-т, чтобы отвечать на неожиданные з-сы аналитиков. М-о рассчитывать только на то, что з-сы будут поступать не слишком часто и затрагивать большие объемы инф-и. Размеры аналитической базы данных стимулируют исп-е з-сов с агрегатами (сумма, минимальное, максимальное, среднее значение и т.д.). 5.Если для опер-х ИС обычно хватает защиты инф-и на уровне таблиц, то информация аналитических БД настолько критична для корпорации, что для ее защиты требуются более тонкие приемы. Стр-ра – операт. БД и внешние ист-ки→аналит БД ↔с-ма аналит обр-ки д. Треб-я к с-мам, поддерживающим аналит бд. Многомерное концептуальное представление д. Бизнес-поль-ль естественно представляет историю и деят-ть своей корпорации многомерными (например, одно измерение - время, другое - заказчики, третье - производимая продукция и т.д Прозрачность. Для бизнес-пол-ля не д-о быть существенно, где конкретно расположены ср-ва динамического анализа д. Доступность. Логическая схема, с к-й работает OLAP-система, д-на отображаться в схемы разнородных физ хранилищ д. При д-пе к д д-но поддерживаться их единое и согласованное представление. Согласованная эф-ть произ-ва отчетов. Эта эф-ть не д-на деградировать при увеличении ч-ла измерений. Арх-ура "клиент-сервер". Серверный компонент OLAP-системы д-н быть достаточно развитым, чтобы разнообразные кл могли подключаться к нему с мин усилиями и затратами на дополнительное "интегрирующее" прогр-вание. Родовая многомерность. Стр-ые и операционные возм-ти р-ты с кажд измерением д д-ны быть эквивалентны. Для всех измерений д-на сущ-ть только одна логич стр-ра. Любая ф-ция, применимая к одному измерению, д-на быть применима к любому др измерению. Упр-е динамическими разреженными матрицами. Сервер OLAP-с-мы д-н уметь эф-но хр-ть и обраб-ть разреженные матрицы. Физ м-ды д-па д-ны быть разнообразны, включая прямое вычисление, B-деревья, хэширование или комбинации этих методов. Поддержка многопольз-го р-ма. Неограниченные операции м/ду измерениями. При вып-и многомерного анализа д все измерения созд-ся и обрабатываются единообразно. OLAP-с-ма д-на быть в сост-и вып-ть соотв-щие вычисления м/у измерениями. Интуитивное манипулирование д. Манипуляции, подобные смене пути анализа или ур-ня детализации, д-ны вып-ся с пом-ю прямого воздействия на эл-ты OLAP-модели без потребности исп-ть меню или др вспомогательные ср-ва. Гибкая с-ма отчетов. Бизнес-поль-ль д-н иметь возм-ть манипулировать д, анализировать и/или синтезировать, а также просматривать их таким образом, как ему захочется. Неограниченное ч-ло измерений и ур-ней агрегации. OLAP-сервер должен поддерживать не менее 15 измерений для кажд аналит модели. Для кажд измерения д-но допускаться неогранич ч-ло опр-х поль-лями агрегатов. Осн выводом из материала этого раздела явл-ся то, что подход складов д еще слишком молод, чтобы вокруг него сложился круг общепринятых понятий, терминов, технологических приемов.

№ 23 Интегрированные распределенные приложения. По разным причинам возникают потребности в интеграции независимо и по-разному организованных информационно-вычислительных ресурсов. Видимо, ни в одной действительно серьезной распределенной ИС не удастся обойтись без применения некот технологии интеграции. К счастью, теперь сущ-т путь решения этой пр-мы, к-й сам лежит в русле открытых систем, - подход, предложенный крупнейшим м/унар консорциумом OMG (Object Management Group). Ф-ры стимулирующих исп-е м-дов интеграции разнородных инф-х р-сов. Неоднородность, распределенность и автономность инф-х р-сов системы. Потребности в интеграционном комплексировании компонентов ИС. Очевидно, что наиболее естественным способом орг-и сложной ИС явл-ся ее иерархически-вложенное построение. Реинжинерия с-мы. После созд-я начального варианта ИС неизбежно последует пр-с ее непрерывных переделок (реинжинерии). Реконструкция с-мы не должна быть революционной. Все компоненты, не затрагиваемые пр-сом реинжиниринга, д-ны сохранять работоспособность. Решение проблемы унаследованных (legacy) с-м. Любая комп с-ма со временем становится бременем корпорации. Постоянно приходится решать з-чу встраивания устаревших -х компонентов в с-му, осн-ю на новой технологии. Повторно исп-е (reusable) р-сы. Техн-я разработки ИС д-на способствовать исп-ю уже сущ-х компонентов, что в конечном итоге д-о перевести нас от экстенсивного ручного программ-го труда к интенсивным м-дам сборки ориентированной на конкретную область применения ИС. Продление жизненного цикла ИС. Чем дольше живет и приносит пользу ИС, тем это выгоднее для корпорации. Естественно, что для этого д-на сущ-ть возможность добавления в нее компонентов, спроектированных и разработанных в др техн-и. Осн з-чей интеграции неоднородных БД является предоставление поль-лям интегрированной с-мы глобальной схемы БД, представленной в некот модели д, и автоматическое преобразование оп-ров манипулирования БД глобального ур-ня оп-ры, понятные соотв-щим локальным СУБД. При строгой интеграции неоднородных БД локальные с-мы БД утрачивают свою автономность. После включения локальной БД в федеративную с-му все дальнейшие действия с ней, включая администрирование, д-ны вестись на глобальном ур-не. Как правило, интегрировать приходится неоднородные БД, распр-е в вычислительной сети. Дополнительно к собственным проблемам интеграции приходится решать все пр-мы, присущие распр-ным СУБД: упр-е глобальными транзакциями, сетевую оптимизацию з-сов и т.д. Очень трудно добиться эф-ти. Как правило, для внешнего представления интегрированных и мульти-БД используется (иногда расширенная) реляционная модель д. В посл время все чаще предлагается исп-ть объектно-ориент м-ли, но на практике пока основой является реляционная модель. Осн недостатком с-м интеграции неоднородных БД является то, что при этом не учитываются "поведенческие" аспекты компонентов прикладной с-мы. Естественным развитием взглядов на инф-е р-сы явл-ся их представление в виде набора типиз-х объектов, сочетающих возм-ти сохр-я инф-и и обр-ки этой инфо-и. Наиб сущ-ный вклад в созд-е соотв-й техн-и внес м/дунар консорциум OMG, выпустивший ряд док-тов, в к-х специфицируются арх-ра и инструментальные ср-ва поддержки распред-х ИС, интегрированных на основе общего объектно-ориентир подхода. В базовом документе специфицируется эталонная модель арх-ры (OMA - Object Management Architecture) распределенной ИС. Прикладные объекты и общ ср-ва ↔ брокер объектных заявок↔объектные службы. Согласованная с арх-рой OMA прикладная ИС представляется как совок-ть классов и экземпляров объектов, к-е взаимодействуют при поддержке брокера объектных заявок (ORB - Object Request Broker). ORB, общие ср-ва (Common Facilities) и объектные службы (Object Services) относятся к категории промежуточного ПО и д-ны поставляться вместе. Объектные службы представляют собой набор услуг (интерфейсов и объектов), к-е обеспечивают вып-е базовых ф-ций, требуемых для реализации прикладных объектов и объектов категории "общие ср-ва". Общие ср-ва содержат набор классов и экземпляров объектов, поддерживающих ф-ции, полезные в разных прикладных областях. В осн OMA лежит базовая объектная модель COM (Core Object Model), в к-й специфицированы такие понятия, как объект, операция, тип, подтипизация, наследование, интерфейс.

№ 24,25 Обязанности администратора БД по защите данных в ИСОдна из наиболее важных задач. 2 осн. ф-ции защиты: ф. безопасности (защита дан при сбоях аппаратуры, ПО, некоррект. работы пользов,т.е. при непреднамеренной порче дан) ф. секретности (защ дан при несанкц доступе, преднамер порче дан, их кражи. Разделение всех дан на 2 гр: секр, общедост. Виды i: секретная (i, отнесенная к гос тайне, сохранность которой регламентируется з-нами); конфиденциальная (i, кот. не д. стать известной посторонним, но не имеющая грифа секретности; испол-ся огран кругом лиц, утечка м. нанести ущерб гос-ву); общедоступная(i, доступ к которой не ограничен). Исходя из конкр особен ИС, при разработке всей системы защиты следует обесп защиту объектов, процессов, процедур, каналов связи, программ. Реализация ф-ции секретности связано с физич защитой дан, или защ дан при несанкц доступе. Ф-ции защ дан ИС реализуются на основе широкого спектра методов: организац (ограничение круга лиц, получающих право доступа к аппаратуре) процедурные (обеспечение доступа к дан тех пользов, которые имеют соотв права); аппаратные (разнообр электрон уст-ва, встраиваемые в состав технич ср-в)

Администратор БД решает следующий спектр вопросов:

1) Классификация данных в соотв-ии с их использованием.

2) Определение прав пользователя к определенным группам данных; определение ограничений и видов

операций, доступных для пользователя.

3) Организация системы контроля. Пример: Если 3 раза неправильно набран пароль, то система отключает

пользователя на некот. время (для того чтобы администратор мог проследить к кому ломились и принять

меры).

4) Тестирование новых систем ЗД.

5) Периодическое проведение проверок правильности функционирования системы защиты.

6) Исследование всех возм-ых случаев попытки несанкционированного доступа и определение политики

предотвращения таких действий.

7) Анализ теоретических наработок по ЗД и изучение и применение новых методов ЗД.

№ 26 Идентификация и аутентификация пользов. Виды, требования к паролю. Идент-я – задание поль-лю некот логич имени, осущ-ся при регистрации поль-ля в сети. Аутентиф – проверка за того ли выдает себя поль-ль в сооотв-и с логич именем при входе в с-му. Способы аутентиф: пр-ка многораз п-ля; пр-ка однораз п-ля; вход по диалогу, вход по алгоритму. Админ БД определяет права польз, т.е. условия санкц доступа к i. Здесь определяется какие операции и с какими данными разрешены либо данному пользов, либо группе пользов. Необходимо наличие паспорта пользов (ПП), благодаря которому реализуется ср-ва идентиф-ии пользователя, кот. м. реализоваться на основе:- проведение развернутого диалога пользов (в ПП должны входить ответы пользов на вопросы); это сложный способ.- пароль.В ПП входит: - перечень доступных данных.- Перечень тех операций, кот. м. применяться к данным. С т.зр. идентиф пользователя ПП не обязателен, но его наличие необходимо при исп-нии метода управления доступом. паспорта пользователя вводит сам пользователь при регистрации в системе.Как правило, любая процедура ид-ации предполагает ввод поль-лем логич имени (login) и пароля (password). В зависимости от ос-тей ф-вания с-мы пароль м-т выбирать либо сам польз-ль, либо назначать админ (в некоторых случаях его генерирует сама с-ма). 1. Пароль не д-н сод-ть личностных данных поль-ля 2. П-ль не д-н быть словом из какого-либо словаря.3. Пароль не д-н быть слишком коротким.4. П-ль не д-н состоять из повторяющихся букв или слов.5. П-ль не д-н состоять из символов, соотв-х подряд идущим клавишам клавиатуры. 6. Желательно включать в пароль символы с разных регистров, знаки препинания, цифры и прочее.7. Для того чтобы пароль хорошо запоминался, его можно составить из отдельных частей слов, входящих в какую-либо фразу. Пароли тоже следует защищать. Необх регулярная смена п-ля. Ограничение по кол-ву интераций для входа в с-му. Сред вр. Безопас п-ля: Тср=(д+м/н)*(s/2), где s- кол-во всех возм п-лей, д – время м/у 2мя неудачн попытками ввода п-ля, м – кол-во символов в п-ле, н- кол-во символов в ед времени, м/н – время на ввод п-ля задан дины. При аутен поль-ля п-ль не только отображается заменителем знаков, но и не соотв длины.При исп-и однораз п-лей с-ма м-т информировать поль-ля о сост-и аутен различн способами, также м-т задаваться фиксир кол-во попыток и оповещение об оставшемя кол-ве попыток. Если п-ль был верен, но он уже был исп-н, то с-ма д-на предупреждать поль-ля.В ситуации неправ пары п-ля и логина не акцентир какой эл-т не верен.

№ 27 Хар-ка ур-ней доступа.В наст время реляц м-ль д в ИС явл наиб часто используемой. В основе реляционной модели лежит понятие «отношение».Совокупность взаимосвязанных реляционных отношений, фактически описывающая базу данных реляционного типа, называется схемой реляционной базы данных. Заголовок (схема реляционного отн-я) – сов-ть атр-тов, опр-х реляционное отн-е. Схемой реляц отн-я называется конечное мн-во имен атр-тов {A₁, A₂, … A_n}. Сов-ть зн-ний атр-тов для заданного экземпляра объекта явл кортежем отн-я. Тело – сов-ть кортежей. Следует заметить, что тело отн-я на доменах состоит из меняющегося со временем кол-ва кортежей, каждый из к-х опр-ся заданным значением V_i для атрибута A_i (i=1 .. n, где n - количество атрибутов). Т.о., кортеж – это строка отн-я реляц м-ли д, представляющая собой послед-ть значений (атомов) атрибутов. Ч-ло атр-тов в отн-и называется степенью отн-я, а кол-во кортежей в отн-и – его мощностью. По отн-ю к бд выделяют, как правило, 3 ур-ня д-па.1. Неогр д-п ко всем отн-ям бд. При этом под неогр д-пом понимают возм-ть применения различных операций с д. 2. Ограниченный д-п. Под ограниченным д-пом понимают наложение запрета на выполнение некот операций с данными. 3. Запрет д-па.Если говорить об ур-нях д-па к отдельному реляционному отн-ю, то их выделяют значительно больше. 1. Неогр д-п ко всем атр-там Р(а1..ан) реляц отн-я , включающего в себя атр-ты а1..ан.2. запрет д-па к люб атр-там … 3.неогр д-п… . 4. Неогр д-п к атр а1..ак реляц отн-я при огранич д-пе к ост атр-там. 5. Неогр д-п к атр а1..ак реляц отн-я при запрете д-па к ост атр-там. 6. Огр д-п к атр а1..ак при запрете д-па к ост 7. Огр д-п к атр а1..ак, запрет д-па к атр ак+1…ан неогр д-п ко всем ост. На ур-не картежа: 8. Неогр д-п к а1..ак реляц онт-я при огр д-пе к ост атр-там в 1м картеже. 9.неогр д-п к атр-там а1..ак реляц отн-я при запрете д-па к ост атр картежа. 10 огранич д-п к атр а1..ак запрет к атр ак+1..ан наогр д-п ко всем ост атр в картеже. 11. Д-п в соотв-и с пунктами 1,3-10 при текущем времени в интервале. 12. Д-п к атр-там в соотв-и с пунктами 1,3-10 при усл-и, что зн-е атр-тов а1..ан удовл соотв логич выр-ю в1..вн.

№ 28 ПП. Админ БД опр-т права польз, т.е. усл-я санкционированного д-па к с-ме. Здесь опр-ся какие операции и с какими д разрешены либо данному поль-ю, либо группе поль-лей. Необх наличие паспорта поль-ля (ПП), благодаря к-му реализуется ср-ва идентиф-ии поль-ля, кот. м. реализоваться на основе:

- проведение развернутого диалога пользователя (в ПП должны входить ответы пользователя на в-сы); - пароль.В ПП входит: - перечень доступных д.- Перечень тех операций, кот. м. применяться к данным.

С т.зр. идентиф поль-ля ПП не обязателен, но его наличие необхпри исп-нии м-да упр-я д-пом.

№ 29, 30 Понятие криптографии. Криптология- наука о з-нах, м-дах и ср-вах на осн закрытия д м-дом шифровки.. Криптография- раздел крип-ии, в рамках кот. осущ-ся поиск и исслед-ние матем метод преобр i с целью её защиты от незакон пользов. Процессы зашифр и расшиф исп-ют один и тот же кл; обладают высоким быстродейст. Криптоустойчивым считается шифр, при применения к-го нарушитель, знающий алгоритм неспособен ракрыть шифр. Кодир-е- преобр-ние защищаемых дан, при кот они делятся на блоки, имеющие смысл знач (слог), и каждый блок замен. цифр., букв. или комбинир кодом. . Шифр-е- такой вид закрытия, при кот самост преобразов подвергается кажд симв закрыв-ых дан. Криптоанализ – з-ны раскрытия шифра. М-д прямой замены - зам симв исх текста, построен на одном алф, на симв др, называемого алф замены. Кажд эл-т текста напис в рамке исх алфавита заменяется на соотв эл-т из порожденного алфавита, т.о. табл соответствия явл ключом. Суть криптоанализа закл в след: необх построить табл частотных хар-к символов в зашифрованном тексте, на осн имеюйся открытой инф-и о част хар-ке, сопоставить частотные хар-ки и постоить табл соотв-я. Можно составить общую формулу моноалфавитной замены. Она выглядит следующим образом: Y_i = chr(K₁· asc(X_i) +K₂) mod n, где Y_i – символ шифротекста; X_i – символ открытого текста; K₁, K₂ – произвольные константы;

Chr(N)– функция, позволяющая определить символ, по его месту N в алфавите; asc(S)– функция, позволяющая определить место символа S в алфавите (функция, обратная функции asc()).r mod n– остаток от целочисленного деления r на n;n – количество символов в алфавите.М-д прямой замены неэффективен. -м Цезаря: a=d, b=e, c=f . М-д замены, где зад символ заменяется на др по опр правилам. В частн-ти м Вижинера: 1.строится таб n*n :АБ В Г ….Я Б В Г Д …А 2. осущ-ся выбор кл шифр-ния (симв не повторяются, сост из символов исх алфавита) 3. под кажд симв исх текста подпис ключ по кольцу. 4. сост шифр – берется столбец буквы исх алфавита и строка буквы ключа на их пересечении выбираем букву. Для расшифровки берем строку буквы ключа, ведемдо тех пор пока в этой строке не встретится буква зашифр текстас и поднимаемся вверх. Мет. Перестановки по м-це векторов: опр-м м-цу м*н, весь кодируемый текст разбивется на м*н символов.ключи вектора 1й длной м, другой н, содержит числа от 1 до м и от1 до н в произв порядке без повторения. Р-та с блоками в м-це в соотв с ключами. Построение записи букв исх блока (если ключ 4,5,2,6,3,1, а м-ца размером 5*6, то 1е пять символов запис в 4ю строку, далее 2е пять символов в 5ю строку). Считываем м-we в соотв-и со 2м ключом по столбцам. Ключ 5,1,4,3,2 значит берем сначала 5й столбец м-цы и записываем его в строку, затем 1й столбей и т.д. Метод перестановки на основе магических квадратов Сначала необх разбить текст на блоки, длина которых равна n*n, где n – длина стороны квадрата (измеряемая в клетках), затем по определенному правилу занести символы блока в квадрат, а затем построчно считать и склеить в строку. Так поступить с каждым блоком текста. Правило, по к-му текст заносится в квадрат следующее: шифруемый текст необходимо вписать в магический квадрат в соответствии с нумерацией его клеток.

Очевидно, что криптоанализ сводится к поиску магического квадрата.

№ 31 Принципы построения з-ты данных в ИС.Кач-во функционир любой ИС во многом зависит от сохранности д, на осн обр-ки к-х реализуются конкретные инф-е з-чи. Выд-т две осн ф-ции з-ты д в ИС: ф-цию безопасности и ф-цию секретности. Ф-ция безопасности предполагает з-ту д при сбоях аппаратуры,ПО, некорректной р-ты поль-лей, т.е. при непреднамеренной порче (искажении) или разрушении данных. Сюда следует отнести и защиту от ошибок персонала при вводе д, к-я обеспечивается за счет реализации огр-й цел-ти. В соотв-и с ф-цией безопасности ИС д-на быть спроектирована и реализована таким образом, чтобы свести к мин возможные потери в указанных ситуациях, для кажд из которых характерны свои специфические способы и методы защиты. Фактически реализация защиты данных в рамках ф-ции безопасности явл внутренней задачей ИС.Ф-ция секретности предполагает защиту д при несанкц д-пе, преднамеренной порче данных, их краже. Реализация ф-ции секретности предполагает разделение всех д на две гр: секретные данные и общедоступные.Секретной принято считать инф-ю, отнесенную к гос тайне, сохр-ть к-й регламентируется, соотв законами и за разглашение к-й установлена уголовная ответ-ть.К конфиденциальной относят инф-ю, к-я предназначена для исп-я ограниченным кругом лиц и утечка к-й, хотя и не наносит гос ущерба, но м-т нанести значит ущерб опр кругу лиц или фирм. Примером конфиденциальной инф-и явл-ся коммерческие секреты, к-ми пользуются доверенные лица какой-либо фирмы, банка и т.п. Отнесение инф-и к конфиденциальной осущ-ся в порядке, установленном законодательством РФ. Кроме этого, 11 статья закона «ОБ ИНФ-И, ИНФОРМАТИЗАЦИИ И З-ТЕ ИНФ-И» опр-т персональные сведения о гражданах как конфиденциальные и регламентирует порядок их исп-я.Статья 11. Информация о гражданах (персональные данные) Открытой инф-й наз-ся такая инф-я, д-п к к-й не ограничен. Под инф-й безопас-ю ИС понимают св-во защищенности ее инф-й сферы от случайных или преднамеренных воздействий естественного или искусственного хар-ра, способных привести к ухудшению заданных качественных хар-к ф-вания ИС. В соотв-и с федеральным законом «ОБ ИНФ-И, И-ЗАЦИИ И З-ТЕ ИНФ-И» под инф-ми р-ми понимают отдельные док-ты и отдельные массивы док-тов, док-ты и массивы док-тов в ИС. В целом же ф-ции защиты данных в ИС реализуются на основе широкого спектра методов, которые можно разделить на организационные, процедурные, структурные, аппаратные и программные. Осн целью исп-я организационных м-дов явл ограничение круга лиц, получающих право д-па к аппаратуре, на к-рой ф-рует ИС. Целью исп-я пр-рных м-дов з-ты д в ИС является обеспечение д-па к д тех поль-лей, к-е имеют соответствующие права. Стр-рные м-ды з-ты д применяются на этапе проектирования стр-ры бд. Осн цель исп-я этой группы м-дов состоит в обесп-и такой стр-ризации д, при к-й их распределение по группам, логическим и физическим записям, уст-е взаимосвязей м/у ними позволяют повысить ур-нь защищенности всей БД.Аппаратными ср-вами з-ты д явл-ся разнообразные электронные ус-ва, встраиваемые в состав техн ср-в вычислит с-мы или сопрягаемые с ними с помощью стандартного интерфейса. К ним же относятся различные датчики, представляющие собой радиолокационные ус-ва, инфракрасные приборы, оконные и дверные контакты и многое др. Пр-мные м-ды защиты достаточно эф-ны при з-те д от несанкционированного д-па. Пр-мные м-ды за-ты данных в ИС м-т быть реализованы след различн способами:включение разработанных пр-м в состав исп-мых ОС; включение разработанных пр-м в состав СУБД, но основе к-й ф-рует ИС; выд-е пр-м з-ты д в отд пакет, инициализация к-го происходит перед началом пр-са обслуживания з-сов поль-лей. Важными хар-ми пр-мных м-дов явл-ся их универсальность, гибкость, простота реализации, возм-ть модификации и развития. Все сказанное выше свидетельствует, что реализация ф-ций защиты данных в ИС, построение с-мы ее безопасности, предполагает след последовательность вып-х при этом р-т (этапов построения системы безопасности ИС): опр-е инф-х и техн р-сов, а также объектов ИС, подлежащих защите; выявление всевозможных потенциальных угроз и каналов утечки инф-и; оценка уязвимости р-сов ИС при имеющихся угрозах и каналах утечки; опр-е треб-й к с-ме з-ты инф-и; осущ-е выбора ср-в з-ты инф-и и их хар-к; внедрение и орг-я исп-я выбранных мер, способов и средств защиты; осущ-е к-ля цел-ти и упр-е с-мой за-ты.

№ 32. Цел-ть д и огр-я цел-ти Целостность– сост-е данных, когда они сохраняют свое инф-ное сод-е и однозначность интерпретации в усл-х случайных воздействий. Адекватное опис-е предметной обл-ти, к-ю она опис-т. Цел-ть БД опис-ся на 3х ур-нях: внешн, внутр, на ур-не полей. Внутр – в табл не д-о быть повтор строк. На ур-не полей – обесп тем, что поле соотв опр домену (допуст зн-ю). Внеш - ссылочная цел-ть. Предложения, опис-щие цел-ть данных называютограничениями целостности (сов-ть мер, к-е способствуют, но не обеспеч адекватное опис-е той предм обл-ти, к к-й они относятся). Транзакция– это з-с на изм-е бд, т.е. входное сообщение, переводящее БД из одного непротиворечивого состояния в др. В ИС для некот огра-й цел-ти не предусматривается их проверка до конца транзакции. Такие ограничения называются отложенными. Для таких ограничений и их проверка является отложенной, выполняющейся лишь по завершении соответствующей транзакции. Для поддержания цел-ти БД необх некоторый набор обслуживающих стандартных программ (пр-мы ведения журнала, пр-ы разгрузки, пр-мы восстан-я, пр-мы отката, пр-мы контрольных точек, пр-мы к-ля ). 1. Первич ключ – атр-т/сов-ть атр-тов однозначно детерминирующих картеж в отн-и. Значение первичн ключа д-о быть уникальным. Огр-е на ключ поле – оно не д-о иметь нулевое зн-е и д-о быть обяз заполнено. 2. Огранич-е по формату. 3. Огр-е по ф-цианальному зн-ю. 4.Огр-е по перечислимому зн-ю. 5. Огр-е по условно-перечисл зн-ю (круг зн-й не явл небольш, но он конечен). 6. Запрет на NULL зн-е. 7. Уст-ка зн-я по умолчанию.