Механизмы восстановления БД после отказа носителя
Необх-мо делать резервные копии БД и журнала транз., при чём копии БД и журнала д. хранится на разн носителях. В случае сбоя БД восстан-ть на основе последней копии. Все изм-я, произв-е в данных после послед. копир-я, утрачив-ся; но при наличии журнала транз-й их м. выполнить ещё раз, обеспечив полное восстан-е БД.
Ускор-е раб достиг-ся за счёт структуры индекса, оптимиз-й под поиск. Индексы стоит соз-ть для: ключ. поля, для полей по кот. часто выпол-ся поиск или сортир-ка, для внеш-х кл (для соедин-я). Индексы поддерж-ся динамически, т.е. при добав-и или удал-и записей, при модиф-и полей, вход-х в индекс, – индекс приводится в соотв-е с обновл-м. Обновл-е индекса, занимает некот. время (иногда, оч. большое), поэтому существов многих индексов м замедл работу БД. Если индексу соотв-ет ключ-е поле, то он наз-ся перви-чным, иначе вторичным. В плотных индексах для кажд. записи (зн-я ключа) имеется стран индекс-го ф-ла, указыв-я место размещ-я записи (записи распол-ны в произв-м порядке). 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) проектирование общей структуры Выделение отдельных функциональных блоков и определение связей между ними (формы и переходы м/у ними) Иерархическая, сетевая структура.
альтерн-е ветви. Соединение – объединение альтерн ветвей. Разделение – распараллеливание действий Согласование – переход к следующему действию после окончания всех согласуемых действий. Диаграмма последовательн-ти используется для представления временных особенностей передачи и приема сообщений м/у объектами. Элементы:Объект, Линия жизни, Фокус управления, Сообщение, Уничтожение объекта.Вызов процедуры - Один объект вызывает процедуру и ожидает, пока она не закончится. Асинхронное сообщение - Объект передает сообщение и продолжает выполнять свою деят-ть, не ожидая ответа. Возврат из вызова процедуры - Объект передает сообщ об окончании выполнения процедуры. Диаграмма коммуникации (кооперации) предназнач для спецификации структурных аспектов взаимод объектов. Любую диагр последоват м преобразовать в диаграмму коммуникации, и наоборот. Элементы:Объект, Ассоциация, Сообщение. Диаграмма компонентов опис особенности физического представления системы Цели построения диаграмм-мы компонентов –визуа-лизация общей структуры исходн кода прогр системы, спецификация исполнимого варианта пр системы, обеспечение многократного использ отдельных фрагме-нтов программного кода, представл концептуальной и физической схем баз данных Компонент – крупно модульный объект: испол-няемый файл, подсистема, документ и др. Диаграмма топологии примен для представления общей конфигурации и топологии распределенной программной системы и содержит распределение компонентов по отдельным узлам системы
Популярное: Как построить свою речь (словесное оформление):
При подготовке публичного выступления перед оратором возникает вопрос, как лучше словесно оформить свою... Модели организации как закрытой, открытой, частично открытой системы: Закрытая система имеет жесткие фиксированные границы, ее действия относительно независимы... ©2015-2024 megaobuchalka.ru Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. (524)
|
Почему 1285321 студент выбрали МегаОбучалку... Система поиска информации Мобильная версия сайта Удобная навигация Нет шокирующей рекламы |