Содержание

Введение

1 ER- метод проектирования баз данных

1.1 Основные требования при проектировании

1.2 Нормализация отношений

1.3 CASE– средства проектирования

1.4 ER-метод проектирования

2 Проектирование и реализация бд гаи

2.1 Анализ предметной области

2.2 Разработка информационной модели

Введение

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

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

Системы управления базами данных (СУБД, DBMS – Database Management System) на протяжении всего пути развития компьютерной техники совершенствовались, поддерживая все более сложные уровни абстрактных данных, заданных пользователем, и обеспечивая взаимодействие компонентов, распределенных в глобальных сетях и постепенно интегрирующихся с телекоммуникационными системами.

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

В данном дипломном проекте рассмотрены вопросы проектирования и администрирования баз данных в сервере MSSQLServer2005 для решения задач автоинспекции.

1 Er- метод проектирования баз данных

1.1 Основные требования при проектировании

Проектирование базы данных (БД) – одна из наиболее сложных задач, связанных с созданием информационной системы (ИС). При проектировании информационной системы необходимо провести анализ целей этой системы и выявить требования к ней отдельных пользователей [1].

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

Общие требования к БД в процессе проектирования:

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

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

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

• установка защиты базы данных от несанкционированного доступа;

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

Конкретные требования к реляционной СУБД раскрываются в следующих правилах [8].

Информационное правило. Вся информация, хранимая в базе данных, должна быть представлена единственным образом: в виде значений в реляционных таблицах.

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

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

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

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

• определение данных;

• определение правил целостности;

• манипулирование данными (в диалоге и из программы);

• определение таблиц-представлений (в том числе и возможности их модификации);

• определение правил авторизации;

• границы транзакций.

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

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

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

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

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

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

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

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

В процессе проектирования баз данных часто выделяют три этапа [8]:

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

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

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

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

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