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

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

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

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

Переход от схемы объект - отношение к реляционной модели данных осуществляется следующим образом: все объекты схемы объект - отношение это определенные таблицы название полей которых являются свойствами объектов, если отношение имеет свойства то оно также является таблицей в полученной реляционной модели данных

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

Рисунок 4.3 - Реляционная модель данных

Таким образом, после рассмотрения приведенных выше моделей данных для разработанной в пункте 3 схемы объект-отношение была выбрана РМД, которая проста и понятна для пользователя и отвечает требованиям изучаемого курса.

5 ОБОСНОВАНИЕ ВЫБОРА СУБД

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

Этим требованиям отвечают многие современные СУБД, в том числе и Access. МА включает в себя традиционные технологии и возможности реляционных СУБД, предоставляет средства создания базы нормализованных данных и форм для диалоговой работы с ней и удобным графическим интерфейсом. С построением базы нормализованных данных тесно связана разработка и эффективная реализация задач пользователя. Для рения многих задач достаточно использовать такие объекты Access, как формы, запросы ,отчеты. Эти объекты легко создаются в диалоговом режиме. Для реализации целостного приложения пользователя в некоторой предметной области возникает необходимость в создании макросов и модуле на языке Visual Basic for Applications (VBA). Механизм обработки событий, возникающих в процессе диалоговой работы с данными, позволяет объединять в приложении пользователя отдельные запросы, формы и отчеты и получать нестандартные рения в практических приложениях пользователя.

Программа Microsoft Access 2000 является реляционной СУБД, которая может функционировать под управлением операционных систем Windows 95/98/Me, Windows NT, Windows XP, и позволяет реализовать поставленную цель. Обеспечивает удобство работы пользователя: имеется возможность создания пользовательских интерфейсов при использовании Visual Basic для приложений, автоматизация разработки различных объектов. Для построения и выполнения запросной функции в Access 2000 очень удобным и доступным является язык запросов по образцу QBE, поддерживаемый мощным интерфейсом пользователя, а также встроенный язык запросов SQL, который является удобным языком управления базами данных.

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

6 ОПИСАНИЕ КОНЦЕПИУАЛЬНОЙ МОДЕЛИ РЕЛЯЦИОННОЙ БАЗЫ ДАННЫХ

6.1 Схема Данных

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

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

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

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

Таблица находится во второй нормальной форме (2НФ), если она удовлетворяет определению 1НФ и все ее поля, не входящие в первичный ключ, связаны полной функциональной зависимостью с первичным ключом.

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

Рисунок 6.2 - Таблица данных в 1НФ

Представим функциональные зависимости для таблицы в 1НФ:

6.2 Описание и обоснование полей таблиц

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

Таблица «Предприятие» (таблица 6.2.1):

1. Код предприятия

-Ключ: первичный ключ;

-Счетчик;

-Длинное целое;

-Размер: 3;

-Совпадение не допускаются, так как это первичный ключ, он считает записи в таблице.

2. Название предприятия

- Текстовое;

- Размер 80;

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

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

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

3. Дата открытия предприятия

- Тип дата;

- Размер 10;

- Обязательное поле, так как у каждого предприятия есть дата открытия;

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

-Маска: 00.00.0000;

-Значение по умолчанию =Date();

-Условие на значения <=Date(), так как предприятие не может открыться позже, чем в день рассмотрения его деятельности.

4. Город

-Тип длинное целое;

-Размер 2;

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

-Совпадения допускаются, так как разные предприятия могут находиться в одном городе;

-Подстановка: из таблицы «Город», поле «Название города»;

-Внешний ключ.

5. Тип

-Тип длинное целое;

-Размер 2;

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

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

-Подстановка: из таблицы «Тип», поле «Название типа»;

-Внешний ключ.

Таблица 6.2.1 «Предприятие»

Таблица «Город» (таблица 6.2.2):

1. Код города

-Ключ: первичный ключ;

-Счетчик;

-Длинное целое;

-Размер: 3;

-Совпадение не допускаются, так как это первичный ключ, он считает записи в таблице.

2. Название города

- Текстовое;

- Размер 20;

- Обязательное поле, так как город не может быть без названия;

- Пустых строк нет, так как город не может иметь пустое название;

- Совпадения не допускаются, так как разные города не могут иметь одно и то же название.

Таблица 6.2.2 «Город»

Таблица «Тип» (таблица 6.2.3):

1. Код типа

-Ключ: первичный ключ;

-Счетчик;

-Длинное целое;

-Размер: 3;

-Совпадение не допускаются, так как это первичный ключ, он считает записи в таблице.

2. Название типа

- Текстовое;

- Размер 30;

- Обязательное поле, так как тип не может быть без названия;

- Пустых строк нет, так как тип не может иметь пустое название;

- Совпадения не допускаются, так как разные типы не могут иметь одно и то же название.

Таблица 6.2.3 «Тип»

Страницы: 1, 2, 3