Презентация на тему Лекция 3. Проектирование структуры БД

положенной в основу проектирования, различают подходы
«от предметной области»

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

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

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

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

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

от запроса
При реализации подхода от запроса на начальной стадии

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

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

минимизация модели;
4-преобразование модели к виду, воспринимаемому СУБД;
5-проверка адекватности даталогической модели предметной области;
6-уточнение взглядов пользователей.

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

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

после сбоев
Контроль доступа к данным
Поддержка обмена данными
Поддержка целостности данных
Поддержка независимости от данных
Вспомогательные функции

хранилищем информации, описывающей данные в базе данных (по сути,

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

отдельным пользователем или прикладной программой с целью доступа или

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

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

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

многими пользователями.

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

восстановления базы данных на случай какого - либо ее

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

данным. СУБД должна иметь механизм, гарантирующий возможность доступа к

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

непротиворечивость хранимых данных. Она может рассматриваться как еще один

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

за счет реализации механизма поддержки представлений или подсхем. Физическая

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

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

,
статистический анализ ( оценка производительности или степени использования базы данных ),
реорганизация индексов,
перераспределение памяти.
Сегодня считают, что все формы , отчеты , меню , как и программный код , содержащийся в них , входят в приложение БД .
Автономные программы , вызывающие СУБД , также являются частью приложения . Все структуры , правила и ограничения , касающиеся таблицы , а также определения связей относятся к ведению СУБД и входят в состав БД .
Приложения выполняют пять основных функций :
1. Создание , чтение , обновление и удаление представлений .
2. Форматирование представлений .
3. Реализация ограничений .
4. Обеспечение механизмов безопасности и контроля .
5. Реализация логики обработки информации .

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

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

размещение всех атрибутов в одном отношении является очень неестественной

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

базах данных является:
таблица
запрос
форма
отчет

Ответ:

правильного ответа

Ответ:

Решение проблемы передачи данных б) Анализ предметной области, с учетом

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

б, г, в, а
а, б, г, в 
а, б, в, г 
г, б, в, а
Порядок действий значения не имеет 
Ответ:

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

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

Power Point.
MS Outlook.
MS Word.

атрибутов, значения которых в одно и тоже время не

бывают одинаковыми, то есть однозначно определяют запись таблицы - это 

Первичный ключ
Внешний ключ 
Индекс
Степень отношения 
Нет правильного варианта

нескольких записей 
Из одного атрибута 
Из одного атрибута, длина значения которого

больше заданного количества символов 
Нет правильного варианта 

а, следовательно, и других операций использующих поиск называется 
Индекс
Хеш-код 
Первичный

ключ 
Внешний ключ 
Нет верного варианта