Механизмы восстановления БД после отказа носителя

Необх-мо делать резервные копии БД и журнала транз., при чём копии БД и журнала д. хранится на разн носителях.

В случае сбоя БД восстан-ть на основе последней копии. Все изм-я, произв-е в данных после послед. копир-я, утрачив-ся; но при наличии журнала транз-й их м. выполнить ещё раз, обеспечив полное восстан-е БД.

 

Ускор-е раб достиг-ся за счёт структуры индекса, оптимиз-й под поиск. Индексы стоит соз-ть для: ключ. поля, для полей по кот. часто выпол-ся поиск или сортир-ка, для внеш-х кл (для соедин-я). Индексы поддерж-ся динамически, т.е. при добав-и или удал-и записей, при модиф-и полей, вход-х в индекс, – индекс приводится в соотв-е с обновл-м. Обновл-е индекса, занимает некот. время (иногда, оч. большое), поэтому существов многих индексов м замедл работу БД.

Если индексу соотв-ет ключ-е поле, то он наз-ся перви-чным, иначе вторичным.

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

Неплотные индексы строятся в предположении, что на кажд. странице памяти хранятся записи, отсорт-е по зн-м ключа индексир-я (задана кластериз-я). Тогда для кажд. страницы индекс задаёт диапазон зн-й ключей хранимых в ней записей, и поиск записи осуще-ся среди записей на указанной стр.

Древовидн-й индексПолуч-ся в рез-те постр-я индексов над уже постр-м индексом.

Если построен неплотный индекс, то его инд-й файл м. б. рассм-н как основной файл, над кот. надо снова построить неплотный индекс, а потом снова над нов. индексом строится след-й. И так до тех пор, пока не останется всего 1 индексный блок (получ-ся плотный индекс). В рез-те плуч-м цепочку инд-х файлов. В общ. случае получ-ся некот дерево, кажд родит-й блок кот. связан с одинаковым кол-м подчин-х блоков, число кот. равно числу индексных записей, размещ-х в этом блоке.

Снимки- именов-е копии табл, хран-ся в БД вместе с реал-ми табл, доступные только для чтения. Запрос выпол-ся 1 раз и сохр-ся рез-т. Снимки читаются точно так же, как табл. Снимок хранит статические данные, извлеч-е в нек. момент времени, кот. нельзя изм-ть. М.указ-ть, как должен обнов-я снимок, и задать распред-й запрос, кот. опред-т этот снимок.

Примен-е при след-х усл-х: *Табл редко обновл-ся, но часто запраш-ся.* Польз-ли запраш-т данные табл из разных узлов в системе распредел-й БД.

Неоправданное использов снимков без необход-ти снижает произв-ть БД и увелич-т расходы дисковой памяти.

 

4) инкрементная модель, аналог каскадной, но с рекурсией по подзадачам

+ для больш систем

- ного документации

5) v образная модель

Планир проекта \/произв эксплуатац и сопров

Анал треб и спец\/системное тестир

Разработка архитект\/интеграция и тестирование

Детализирован-я разработка\/модульное тести

\кодирование/

6) RAD (Rapid application development)

Спец ПО

+ разраб занимает небольш время

Пользоват присутств на кажд этапе

Использ мощные генераторы кода

21 UML

Unifed Modeling Language - язык графического описания для объектно моделирования в области разработки ПО.

1)диагр сценариев 2)д класс-сов 3)д состояний4) деятельн 5) последовательности6) ком-муникации 7) компонентов

8) топологии и разветвления

Д Сценариев

Д-мы сценариев - описывают функциональное назначение системы (что она б делать?).

Она явл-ся исход концеп-туальной моделью сист в пр-се проектиров.

Сценарий (прецедент) – фрагмент поведения ИС без раскрытия его внутренней структуры (сервис). Актер представляет собой любую внеш по отнош к моделир ИС сущность, кот взаимод с системой и использует ее функциональные возм-ти для достижения опред целей

Интерфейс опред совокупн операц, кот обеспечивают необх набор сервисов для актера. Отношения: ассо-циации (сценар с актером); расширене, включение, обоб-щение (м/у прецедентами)

Диагр классов - предназнач для представл статич стр-ры модели сист в терминологии классов ООП

Пакет – способ организ элементов модели. Кажд элем модели ∈только 1 пакету.

Класс – обозначает мн-во объектов, кот обладают одинак структ-й, поведением и отношениями с об из других классов (назван, поля, методы)

Интерфейс – набор операц, кот задают некоторые аспекты поведения класса и представляют его для других классов.Объект явл-ся отде-льным экземп класса, кот создается в процессе выпол-нения программы. Объект м иметь имя и конкретные значения свойств.

Отношения: зависимости, ас-социации‏, агрегации, компо-зиции, обобщения, реализации

Диаграмма состояний - описывает процесс изменения состояний только одного класса (т. е. моделирует все возможные изменения в состоянии конкретного объекта). Представлена в виде конечного автомата. Состояние – набор конкр значений атрибутов объекта. Переход происходит по событию (мгновенно). Истор перех не запомин-ся. В кажд момент врем об-т нах-ся в 1 сост и сколько угодно долго. Составное состояние состоит из вложенных в него подсостояний.

Диаграмма деятельности описыв процесс выполнения действий (логику или последовательность перехода от 1 действия к другому; исп для моделир Бизн проц)

Действие – операция, выражение, вычисления и т.д. Переход срабатывает сразу после завершения действия Ветвление – разделение на

22 Проектирование баз данных

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

На инфологическом, опред, какая инф-я о пред области будет храниться и обрабатываться в комп, и в рез-те исследования пр об строится ее инфолог модель. Информация в инф мод представляется вне завис-ти от того, какие программные и техн ср-ва б использованы в дальнейшем для ее хранения и обработки. На этом уровне пр об опис-ся в терминах классов объектов и их взаимосвязей, кот явл-ся понятными конечным польз и людям, работающим в пр об, не знакомым с принципами организации БД.

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

Пр обл <-> пользователь

|

Инфологич модель

_ _ | _ _ _ _ _ _ _ _

|Датологич модель|

| | |

|Физич модель |

_ _ | _ _

|Память|

Даталогические и физическая модели непосредственно реализуются в СУБД.

ER-модель («сущность-связь»)

Среди объектов пр обл выдел общ признаки, хар-ки и по ним объекты объедин-ся в классы. Каждый класс опред-ся набором атрибутов(св-в, кот облад ∀ объект принад классу). Св-ва м.б. статическими (к связи припис S) или динамич (изменяемые - D). Класс – прямоуг. Св-ва – овалы. М/у классами объек м существовать некотор отнош, называемые связями (ромб). Связи м иметь св-ва.

Однозначность связей:

1) 1:1 - ∀ объект из 1 класса соответ ровно 1 об второго класса, и наоборот (<–>)

 

23 Качество пользова-тельского интерфейса

Польз интерфейс объед в себе мн-во элем и компонентов, кот способны оказыв влиян на взаимодейств.

Основные критер кач-ва интерфейса: скорость работы пользователей, количество человеческих ошибок, скорость обучения и субъективное удовлетворение пользователей.

1) Ск выполн работы

- длительность воспр исходн инф-ии

- длит интеллект работы

- длит физ действ пользоват

- длит реакц системы (наименее значим фактор)

Пользов д непосредств манипулир объектами (он долж знать что ему нужно, как управл и др)

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

Уменьшение длительности физическ действий (степень точности элем-в и автоматизации работы) Закон Фица: время достиж цели обр пропорц размеру цели и дистанции до цели.

Отображать реакц системы: индикатор выполнения процесса, при печать если пользоват не ответил на вопрос да/нет печатать ч/з минуту автоматич

24 Проектирование пользовательского интерфейса ИС

Этапы:

1) определение функцио-нальности системы:

-анализ целей пользователя (ориент на конечн продукт)

-анализ действий пользов

2) создание пользовательских сценариев: - для понимания функций системы - для оптимизации функций системы - для тестирования интерфейса

3) проектирование общей структуры

Выделение отдельных функциональных блоков и определение связей между ними (формы и переходы м/у ними)

Иерархическая, сетевая структура.

 

альтерн-е ветви. Соединение – объединение альтерн ветвей. Разделение – распараллеливание действий Согласование – переход к следующему действию после окончания всех согласуемых действий.

Диаграмма последовательн-ти используется для представления временных особенностей передачи и приема сообщений м/у объектами. Элементы:Объект, Линия жизни, Фокус управления, Сообщение, Уничтожение объекта.Вызов процедуры - Один объект вызывает процедуру и ожидает, пока она не закончится. Асинхронное сообщение - Объект передает сообщение и продолжает выполнять свою деят-ть, не ожидая ответа. Возврат из вызова процедуры - Объект передает сообщ об окончании выполнения процедуры.

Диаграмма коммуникации (кооперации) предназнач для спецификации структурных аспектов взаимод объектов. Любую диагр последоват м преобразовать в диаграмму коммуникации, и наоборот.

Элементы:Объект, Ассоциация, Сообщение.

Диаграмма компонентов опис особенности физического представления системы

Цели построения диаграмм-мы компонентов –визуа-лизация общей структуры исходн кода прогр системы,

спецификация исполнимого варианта пр системы,

обеспечение многократного использ отдельных фрагме-нтов программного кода,

представл концептуальной и физической схем баз данных

Компонент – крупно модульный объект: испол-няемый файл, подсистема, документ и др.

Диаграмма топологии примен для представления общей конфигурации и топологии распределенной программной системы и содержит распределение компонентов по отдельным узлам системы