Вопросы (стр. 1 )

1. Что побудило создание СУБД; дать определение понятия СУБД, какие бы­вают СУБД; для чего используется; что включают языковые средства СУБД.

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

СУБД – система управления БД – совокупность языковых и программных средств, предназначенных для создания, ведения и использования БД. СУБД могут быть персональными (локальные БД: dbase, FoxPro и др.) и многопользовательскими (информационные системы в архитектуре Клиент - Сервер: Oracle, SQL-server).

Языковые средства СУБД включают:

1. Язык описания данных (для описания логической структуры данных).

2. Язык манипулирования данными (обеспечивает основные операции над данными).

3. Структурированный язык запросов – SQL (обеспечивает управление структурой БД, манипулирование данными и доступ к удаленным БД).

2. Дать определение базы данных;

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

модели БД.

Иерархическая – данные представляются в виде древовидной структуры, удобно для работы с данными, упорядоченными иерархически. При оперировании данными со сложными логическими связями оказывается слишком громоздкой.

Сетевая – данные организуются в виде графа. Сетевая модель характерна внутренними ссылками. Недостатком является жесткость структуры и сложность организации.

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

Объектно-ориентированная – Объединяет сетевую и реляционную. модели. Используется для крупных БД со сложной структурой.

3. Охарактеризовать работу локальных и удаленных баз данных; в чем заклю­чается архитектура файл-сервер; клиент-сервер.

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

1 – БД и приложения располагаются на сервере, при этом на компьютере запускается копия приложения. Такой вариант соответствует архитектуре Файл-Сервер. Когда пользователь работает с БД, на его компьютере появляется копия БД, которая периодически обновляется. Такая архитектура используется, когда в сети не много рабочих станций.

Недостатки:

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

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

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

BDE – процесс между пользователем и сервером.

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

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

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

Достоинства:

- Низкая нагрузка сети.

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

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

4. Что такое реляционная база данных?

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

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

5. Что такое проектирование??

Проектирование Включает в себя три области:

1. проектирование объектов БД.

2. проектирование модулей кода.

3. проектирование стратегий работы с конкретными средами и технологиями.

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

Создается три типа моделей.

1). Концептуальная информационная модель (КИМ). Сущность бизнеса: не должна содержать связующих сущностей и должны быть полностью нормализована. Преобразуется в логическую.

2). ЛИМ. Принятым способом представления ЛИМ является диаграмма «сущность отношения» (ER-диаграмма). Абстрактное представление данных, где рассматриваемые строки – категории данных и логические связи между ними. Преобразуется в физическую.

3). ФИМ. Проектирование физической БД начинается с назначения атрибутов столбца, кластера, являющегося минимальной единицей физической памяти. Атрибуты столбца определяют способ его физического хранения в БД, задавая его тип и максимальную длину. Во время проектирования следует тщательно выбирать тип данных и длину столбца. Определение атрибутов столбцов является важным шагом в определении объема памяти для данных.

6. Этапы проектирования;

10. Определить задачи проектирования.

12. Что включает в себя проектирование логической и физической модели БД?

Проектировщик берет выходные данные анализа и:

- составляет схему БД на основании модели сущностей; схема БД содержит описание всех объектов БД: таблиц, представлений, столбцов, индексов, ограничений и т. д.

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

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

Результаты этапа проектирования оформляются в единый описательный документ – техническую спецификацию.

Рассмотрим задачи проектирования. Они разбиваются на задачи ранней стадии проекта, непосредственного проектирования БД и проектирование процессов и кода.

1. Ранняя стадия проекта включает:

1). Процесс передачи.

Проектировщик принимает результаты анализа и проверяет:

2). «Прогон» отдельных процессов через спланированную систему с помощью диаграммы потока данных, блок-схемы или общего описания основных шагов, с указанием функций системы, ручных процедур и методику работы.

3). Определение критических участков. Критические участки – это кандидаты на макетирование. Назначение макетирования – избежать дорогостоящих ошибок

4). Оценку системных ограничений:

5). Определение целевой структуры:

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

7). Согласование стандартов проектирования и реализации:

8). Рассмотрение возможности использования средств автоматизированной разработки систем.

2. Проектирование БД включает:

1). Построение согласованной и нормализованной информационной модели. Модель должна быть полностью нормализована под 3-ю нормальную форму.

2). Построение логической модели данных.

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

3). Создание физической БД для разработки.

- целостности данных и правил для данных;

- разработать стратегию индексирования и кластеризации;

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

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

- разработать сетевую топологию БД и механизм доступа к удаленным данным.

9. Какие виды связей между отношениями существуют; дать определение каж­дому виду связи.

Концептуальная модель строится на втором этапе создания БД – этапе анализа

Цель этапа анализа – подробное исследование бизнес процессов (функций) и информации, необходимой для этих функций.

Результат анализа - концептуальная модель; иерархия выполняемых функций, разбивающая процесс обработки на отдельные составляющие; модель «сущность-отношение», охватывающая все сущности, их архитектуру и отношения между ними.

В результате анализа:

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

- модель представляется в виде ER-диаграммы;

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

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

- составляется план тестирования системы.

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

Информационную модель можно использовать как входную информацию для проектирования. Она, как правило, не привязана к технологии реализации.

Механизм для реализации отношений – это ограничение целостности по внешнему ключу.

Реляционные базы не поддерживают указатели из одной записи на другую, поэтому приходится в одной записи хранить уникальный идентификатор другой. Таким образом, можно организовать отношения «один-к-одному» и «один-ко-многим». Отношения могут связывать сущность саму с собой, такие отношения называются рефлексивными.

Сущность – это особый класс реальных вещей или явлений (объектов). Например, корабль – это сущность, а «Титаник» - это экземпляр сущности.

Отношение представляет собой связь между двумя сущностями. Отношение в контексте теории реляционных баз данных не следует путать со связью. В реляционной модели отношение можно рассматривать как неупорядоченную двумерную таблицу, где не повторяется ни одна строка. Между отношениями (таблицами) связи формируются через общие атрибуты, которые называют ключами. Атрибут – это свойство сущности. Каждая сущность должна иметь свойства, которые ее описывают. Некоторые свойства не только описывают сущность, но и уникальным образом ее идентифицируют. Их называют первичными ключами. Если первичный ключ состоит более чем из одного свойства, то его называют составным. Следует различать атрибуты и экземпляр атрибута, например, регистрационный номер автомобиля – это атрибут, а 180 EOD – это экземпляр атрибута. Между сущностями существуют реальные отношения. Например, Вы и ваш автомобиль связаны: Вы для него владелец.

11. Раскрыть понятие нормализации базы данных;

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

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

Определены два типа зависимостей:

функциональная зависимость: поле «В» функционально зависит от поля «А» той же таблицы в том и только в том случае, когда в любой заданный момент времени для каждого из различных значений поля «А» обязательно существует только одно из различных значений поля «В». Полная функциональная зависимость – это когда поле «В» функционально зависит от поля «А», не зависит функционально от любого подмножества поля «А»;

многозначная зависимость: поле «А» многозначно определяет поле «В» в той же таблице, если для каждого поля «А» существует хорошо определенное множество соответствующих значений поля «В».

Существует 5 этапов (форм) нормализации, каждый последующий этап включает предыдущий (на практике используются первые 3):

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

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

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

Нормализация имеет и недостатки: 1). При большом количестве таблиц и связей между ними затрудняется целостное восприятие БД; 2). При выполнении запросов к нескольким таблицам БД, связанным между собой, операции поиска выполняется медленнее, чем в ненормализованных таблицах, где вся информация находится в одном месте. Поэтому, при обработке данных большого объема приходится искать компромисс между требованиями нормализации и необходимости улучшения быстродействия.

13. Что такое денормализация? Для чего она используется? Типы денормализации.

Денормализация яавляется особенностью проектирование БД в Oracle

Денормализация – это процесс достижения компромиссов в нормализованных таблицах посредством намеренного введения избыточности в целях увеличения

Типы денормализации

1). Нисходящая денормализация – предполагает перенос атрибута из родительской сущности в дочернюю.

2). Восходящая денормализация – предполагает сохранение информации из дочерней сущности в родительской в форме

3). Внутритабличная денормализация – выполняется внутри одной таблицы, т. е. хранение значения, полученного из других данных этой же строки. Веской причиной для использования этого типа является необходимость запроса по производному значению.

4). «Разделяй и властвуй» – разбиение одной нормализованной таблицы на две и более таблиц и создание между ними отношений «один-к-одному». Это может быть вызвано ограничениями Oracle

5). Слияние таблиц – примером применения обоснованного слияния может быть наличие повторяющейся группы с фиксированным числом элементов. Такие элементы целесообразно держать одной строкой: можно выполнить анализ столбцов, их группировку и суммирование, и для добавления группы, как одной строки нужен один оператор INSERT, а не количество операторов = числу элементов в группе.

14. Сформулировать требования к непротиворечивости данных; к безопасности данных; связь с унаследованными системами; прием и передача данных в смежные системы.

Рассмотрим задачи проектирования. Они разбиваются на задачи ранней стадии проекта, непосредственного проектирования БД и проектирование процессов и кода.

Ранняя стадия проекта включает:

1). Процесс передачи.

Проектировщик принимает результаты анализа и проверяет:

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

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

имеет ли каждый атрибут «создателя» и «читателя».

2). «Прогон» отдельных процессов через спланированную систему с помощью диаграммы потока данных, блок-схемы или общего описания основных шагов, с указанием функций системы, ручных процедур и методику работы.

3). Определение критических участков. Критические участки – это кандидаты на макетирование. Назначение макетирования – избежать дорогостоящих ошибок. Для макетирования нужно определить самый сложный (сложные) участок (участки), выбрать 2-3 подхода к решению проблемы, отмакетировать их и сравнить полученные результаты. Как правило, берутся две взаимосвязанные формы, создается макет, и знакомят пользователя с внешним видом и общим стилем работы: размещение данных на экране, использование клавиатуры, функциональных клавиш и мыши, выбор элементов из списка, навигацию между формами. Это позволяет на ранних стадиях привлечь конечных пользователей к работе и помогает выявить отдельные недостатки.

4). Оценку системных ограничений:

- сроков и сметы;

- допуска персонала к секретным объектам;

обеспечение совместимости с унаследованными системами;

5). Определение целевой структуры:

- будет ли система клиент/сервер;

- будет ли БД распределенной;

- все ли БД будут продуктами Oracle или это будет неоднородная сеть;

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

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

7). Согласование стандартов проектирования и реализации:

- правила именования объектов БД;

- стандарты проектной документации;

- механизм инициирования изменений;

стандарты по использованию языков SQL и PL/SQL.

8). Рассмотрение возможности использования средств автоматизированной разработки систем.

15. Загрузка и выгрузка данных;

Внешние интерфейсы можно разбить на две категории: одноразовые; периодические.

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

- определить периодичность использования интерфейса и объем передаваемых данных;

- установить степень синхронизации;

- исследовать методы транспортировки (файловые, коммуникационные и др.);

- согласовать формат данных (тип файлов, формат полей и т. д.);

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

- установить правила обработки частично разрушенных данных;

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

- создать общие правила регистрации операций передачи данных;

При нарушении ссылочной целостности в унаследованных наборах данных существуют несколько подходов:

- отбросить данные, не удовлетворяющие требованиям ссылочной целостности (практически неприемлемый подход);

- «изобрести» отсутствующие сущности, заменив недостающую информацию стандартными значениями. При этом нужно позаботиться о том, чтобы эти синтетические записи исключались из некоторых процессов и отчетов, снабдив их каким-нибудь признаком;

- разместить данные с нарушенной ссылочной целостностью в отдельных таблицах и попытаться «подогнать» их путем обработки по правилам (создать для этого отдельный интерфейс), используя опытных пользователей.

16. Защита данных

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

Задачу по защите данных нужно включить в план проекта и сделать одним из основных критериев приемки системы.

1. Архивация – хранение информации без немедленного доступа, но допускающей их выборку.

Архивация может означать:

- полное уничтожение устаревших данных;

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

- сохранение возможности полного доступа, но перевод их в неизменяемое состояние.

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

17. Требования к экранным формам. Требования к отчетным формам.

Требования к экранным формам

1. Все экранные формы должны иметь уникальные информативные заголовки.

2. Все поля необходимо снабдить надписями; при вызове справочной системы должны быть доступны подробные описания полей.

3. Курсор по умолчанию, как правило, должен перемещаться слева направо, а затем сверху вниз.

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