Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Экзамен / Ответы 40-59.docx
Скачиваний:
28
Добавлен:
11.06.2015
Размер:
126.07 Кб
Скачать

40 Объясните своими словами смысл терминов бд, субд, модель данных

База данных - набор сведений, хранящихся некоторым упорядоченным способом.

СУБД - это система, позволяющая создавать базы данных и манипулировать сведениями из них.

Модель данных - это совокупность структур данных и операций их обработки.

41 Каким образом ИС, использующие БД, способствуют повышению ценности информации для организации?

42 Дайте сравнительную характеристику иерархических, сетевых и реляционных баз данных?

Иерархическая модель данных стала применяться в шестидесятых годах, строится по принципу иерархии типов объектов, т. е. один тип объекта является главным, а остальные, находящиеся на низших уровнях иерархии,— подчиненными. Иерархическая модель данных организует данные в виде иерархической древовидной структуры. Эта структура строится из узлов и ветвей. Узел представляет собой совокупность атрибутов данных, описывающих некоторый объект. Наивысший узел в иерархической древовидной структуре называется корнем. Зависимые узлы располагаются на более низких уровнях дерева. Зависимые узлы могут добавляться как в вертикальном, так и в горизонтальном направлении без всяких ограничений. Связи (соединения) между узлами уникальны, Поэтому иерархическая модель данных обеспечивает только линейные пути доступа к данным и между главными и подчиненными типами объекта устанавливается линейная взаимосвязь “один ко многим». Каждый экземпляр корневого узла образует начало записи логической БД, т.е. иерархическая БД состоит из нескольких деревьев. Примером такой модели данных является описание комплектующих автомобиля (ручки, окна, болты, др.), рис.5. Примером иерархической СУБД является СУБД «Ока».

Достоинствами иерархической модели является то, что они наиболее полно отражают семантику предметной области; имеют развитые низкоуровневые средства управления данными во внешней памяти; позволяют построить эффективные прикладные системы. Иерархическая модель более естественно для человека отражает семантику предметной области. Поэтому она проста в понимании и использовании. Схема БД не декларируется явным образом и может изменяться в процессе развития и эксплуатации информационной системы.

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

Рисунок 5 - Фрагмент иерархической модели данных

В сетевой модели данных (рис.6), которая начала применяться в начале восьмидесятых годов, понятия главного и подчиненных объектов несколько расширены. Любой объект может быть и главным, и подчиненным (в сетевой модели главный объект обозначается термином «владелец набора», а подчиненный — термином «член набора»). Один и тот же объект может одновременно, выступать и в роли владельца, и в роли члена набора. Это означает, что каждый объект может участвовать в любом числе взаимосвязей. БД состоит из нескольких областей. Область содержит записи. В свою очередь запись состоит из полей, а набор, который объединяет записи, может размещаться в одной или нескольких областях. Достоинство сетевой модели это простота реализации часто встречающихся в реальном мире взаимосвязей, закладываемых в БД. Основной недостаток сетевой модели состоит в сложности управления данными, в т.ч и возможная потеря независимости данных при реорганизации БД. Сетевая модель использовалась в СУБД СЕТОР.

Рисунок 6 - Фрагмент сетевой БД

Реляционная модель была предложена в семидесятых годах, но получила широкое распространение только в середине восьмидесятых годов. В реляционной модели данных (рис.7) объекты и взаимосвязи между ними представляются с помощью таблиц. Взаимосвязи рассматриваются в качестве объектов (таблиц связей). Каждая таблица представляет один объект. В терминологии реляционной модели таблица называется отношением. Каждый столбец в таблице является атрибутом. Объекты (сущности) предметной области отображаются двумерной таблицей с заголовками, состоящими из имени и типа сущности. Строки такой таблицы представляют собой перечень атрибутов сущности. Назначается один или несколько атрибутов первичным ключом для поиска информации. Значения в столбце выделяются из домена, т.е. домен суть множество значений, которые может принимать некоторый атрибут. Для каждого атрибута всех таблиц фиксирован тип и длина данных. Соединение данных из разных таблиц обеспечивается операторами языка SQL.

Первичный ключ – это столбец, значения которого во всех строках разные. Он может объединять несколько столбцов. В некоторых СУБД первичный ключ может задаваться системой (ACCESS, Oracle). Связь реализуется при помощи внешнего ключа (это столбец таблицы, значения которого совпадают со значениями первичного ключа другой таблицы). Важным моментом является также использование значения NULL в таблицах реляционной БД. NULL – это отсутствующее значение информации в поле. Это поле обрабатывается особым образом.

Рисунок 7 – Фрагмент реляционной БД

Реляционными СУБД являются DB2, Oracle, Paradox, Access, MySQL и др.

Достоинствами реляционной модели является простой и мощный математический аппарат, опирающийся на теорию множеств и математическую логику и обеспечивающий теоретический базис организации БД; обеспечение физической и логической независимости данных. Единственной конструкцией данных в реляционной модели является отношения (связи) между данными (на основании значений данных, а не физических указателей, как в ранних системах). Следствием этого является ненавигационный доступ к данным (отношения трактуются как операнды и результаты операции, а не обрабатываются поэлементно). Простота структуры данных и управления ими облегчает работу пользователей (как программистов, так и непрограммистов).

Недостатками реляционной модели являются минимальные возможности описания семантики предметной области. Рядовые реляционные системы работают медленнее систем, базирующихся на сетевой или иерархической модели данных. Рассмотрим эту модель более подробно.

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

Правила Кодда, которые необходимо использовать при создании реляционной БД:

реляционная СУБД должна управлять БД, используя связи между данными;

вся информация в реляционной БД (включая имена таблиц и столбцов) должна определяться на основе выбранных правил именования;

любое значение БД должно быть гарантированно доступным через комбинацию имени таблицы, первичного ключа и имени столбца;

СУБД должна уметь работать с пустыми значениями (пустое значение - это неизвестное, независимое, неприменимое значение, в отличие от значений по умолчанию и обычных значений);

описание БД и каталог содержимого БД должны быть определены на логическом уровне через таблицы, к которым можно применять запросы, используя язык манипулирования данными;

язык манипулирования данными должен поддерживать определение данных и манипулирование ими, правила целостности, авторизацию и транзакции;

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

СУБД поддерживает не только запрос на данные, но и вставку, обновление и удаление;

физическая независимость данных - логика программ-приложений остается прежней при изменении физических методов доступа к данным и структур хранения;

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

язык БД должен быть способен определять ограничения целостности, ограничения должны быть доступны из оперативного каталога и не должно быть способа их обойти;

несмешиваемость - невозможность обойти ограничения целостности, используя языки низкого уровня.

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

Рекомендации по определению атрибутов. Наименование атрибута должно быть существительным единственного числа, отражающим суть обозначаемого атрибутом свойства. Наименование атрибута не должно включать в себя имя сущности. Каждый атрибут должен иметь только одно значение в каждый момент времени. В таблице должны отсутствовать повторяющиеся значения атрибутов. У всех атрибутов должны быть описаны формат, длина, допустимые значения, алгоритм получения и т.п. Проверьте, если значение атрибута является обязательным, то всегда ли известны все значения. Группировка атрибутов в таблицах должна быть рациональной, т.е. минимизирующей дублирование данных и упрощающей процедуры их обработки и обновления.

43 Перечислите компоненты современной ИС

Современные информационные системы, созданные на основе БД, характеризуется следующими особенностями:

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

подсистемы, имеющие свои задачи и цели функционирования (например, связанные со сбором данных и решением регламентных задач);

отсутствие прямых аналогов, ограничивающих возможность использования типовых проектных решений и прикладных систем;

необходимость интеграции существующих и вновь разрабатываемых приложений;

функционирование на нескольких аппаратных платформах;

разобщенность и разнородность отдельных групп разработчиков по уровню квалификации и сложившимся традициям использования тех или иных инструментальных средств;

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

Высокие требования к документации.

44 Опишите компоненты СУБД

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

Свойства транзакций – атомарность, изолированность, устойчивость.

менеджер протоколирования и восстановления гарантирует устойчивость

Процессор транзакции представлен в виде 2-х основных компонентов:

1. Планировщик заданий, ответственный за обеспечение атомарности и изолированности транзакции. 2. Менеджер протоколирования и восстановления

Процессор транзакции выполняет функции

протоколирование 2. управление параллельными заданиями 3. разрешение взаимоблокировок

Блокировки препятствуют возможности одновременного обращения нескольких транзакций к порции данных такими способами, которые плохо согласуются друг с другом. Признаки блокировки хранятся в таблице блокировок, размещенной в ОП.

Задача управления размещением информации на диске и обмена ею между диском и ОП решается менеджером хранения данных. Менеджер буфера является ответственным за разб. доступной ОП на буферные участки страницы, куда может быть помещено содержание дисковых блоков.

Задачей менеджера буферов является обращение к соответствующим порциям данных на носителях вторичных устройств хранения, где они располагаются постоянно, с последующим переносом данных в буферы, размещаемые в ОП.

Запросы и другие команды языка управления данными группируются в транзакции. Эти процессы должны выполняться атомарно и изолировано друг от друга. Каждый отдельный запрос или операция по изменению данных является самостоятельной транзакцией.

Транзакция должна обладать свойством устойчивости, т.е. результат каждой завершенной транзакции должен быть зафиксирован в БД, даже в тех ситуациях, когда после окончания транзакции система по той или иной причине выходит из строя.

Задача управления размещением информации на диске и обмена ею между диском и ОП решается менеджером хранения данных.

45 Каковы главные функции администратора БД?

Администратор БД отвечает за целостность информационных ресурсов компании. На нем лежит ответственность по созданию, обновлению и сохранности связанных между собой резервных копий файлов, исходя из задач предприятия. Этот человек должен в мельчайших подробностях знать существующие механизмы восстановления программного обеспечения БД. Возможны ситуации, при которых администратору БД потребуется на основе логических прикладных моделей создавать элементы физической схемы, а также поддерживать связь пользователей с системой и обеспечивать соответствующий уровень информационной безопасности, следя за тем, чтобы доступ к данным имели только те люди, которые в нем нуждаются. Администратор БД должен уметь определять узкие места системы, ограничивающие ее производительность, настраивать SQL и программное обеспечение СУРБД и обладать знаниями, необходимыми для решения вопросов оптимизации быстродействия БД. Разделим его обязанности на две категории (основные и дополнительные).  Основные обязанности администратора БД:

  1. Резервное копирование и восстановление системы. Возможно, самая главная задача АБД – сохранять данные в системе. Чтобы делать это эффективно, необходимо разработать процедуру резервного копирования и стратегию восстановления данных. Очень важно периодически тестировать отработанную схему резервного копирования и восстановления.

  2. Обеспечение безопасности – это одна из основных обязанностей АБД. Управление безопасностью и администрирование включают: добавление и удаление пользователей, управление квотами, аудит и разрешение проблем безопасности.

  3. Создание баз данных, табличных пространств, таблиц, представлений и индексов согласно спецификации разработчика приложений.

  4. Периодическая проверка производительности системы и произведение изменений для поддержки необходимого уровня производительности.

  5. Поддержка целостности данных БД.

  6. Планирование и выполнение качественного резервного копирования и стратегии восстановления.

  7. Установка нового программного обеспечения. Очень важно протестировать все программы перед введением их в рабочую среду.

  8. Конфигурация программного и аппаратного обеспечения (вместе с системным администратором). В большинстве случаев доступ к настройке программного обеспечения имеет только системный администратор, поэтому АБД должен вместе с системным администратором производить установку программ, конфигурирование программного и аппаратного обеспечения, чтобы рабочие станции функционировали наиболее оптимально.

  9. Настройка производительности и мониторинг – АБД должен постоянно проверять производительность системы, а при необходимости выполнять настройку. Даже хорошо настроенная система нуждается в постоянной проверке и периодической перенастройке. Иногда достаточно изменить параметры системы, иногда изменить индексы, а иногда и перестроить структуру таблиц.

  10. Процедура планового обслуживания – В задачи АБД входит также обязанность составить календарь обслуживания СУБД. Лучше всего производить обслуживание СУБД в ранние часы по утрам, либо по выходным, чтобы не вызвать недовольства пользователей в случае отказа базы данных. В обслуживание входят архивирование, тестирование и настройка.

  11. Локализация неисправностей – В случае сбоя СУБД, в обязанности АБД входит восстановление работоспособности или помощь в решении этой проблемы. Рекомендуется также решать предполагаемые проблемы, которые могут возникнуть в будущем.

  12. Восстановление системы после сбоя – Поскольку сбой системы приводит к тому, что пользователи теряют доступ к своим данным, АБД обязан как можно быстрее восстановить работу системы. Хорошо подготовленный АБД имеет план восстановления системы после сбоя. 

Соседние файлы в папке Экзамен