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

Access

Предметной области для последующего создания БД в СУБД

Проектирование информационно-логической модели

Основные сведения о MS Access

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

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

2.1. Особенности СУБД ACCESS:

1. Совместимость: СУБД Access совместима с любыми базами данных, управляемыми программой- администратором ODBC(открытый доступ к данным) и структурированный язык запросов SQL.

Можно импортировать и экспортировать данные из текстовых файлов и электронных таблиц, сохранять базу данных (БД) в формате HTML (редактор в сети Интернет).

2. Логическая стройность: Удобство при работе с большим объемом информации, которая перед внесением в базу данных структурируется в виде сложных проектов со связями между таблицами, что дает возможность автоматического поиска логических противоречий в записях, вводимых в таблицы. Формы и отчеты “наследуют”

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

3. Универсальность: Диалоговые средства выборки и обработки информации, которые позволяют решать многие задачи, не прибегая к программированию (запросы по примеру (QBE) с возможностью трансформации в запросы общего вида (SQL)).Для решения более

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

4. Защита информации, возможность ставить индивидуальный пароль.

5. Удобства в создании интерфейса пользователя с применением мастеров, например, для создания подчиненных и связанных форм, отчетов и т. д.

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

Проектирование базы данных можно разбить на два этапа. Первый этап - проектирование информационно-логической (инфологической) модели предметной области. Второй этап - проектирование логической структуры базы данных.

Остановимся на основных определениях.

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

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

Примеры информационных объектов: ТОВАРЫ, ПОСТАВЩИКИ.

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

Информационный объект образуется совокупностью атрибутов. Атрибуты это количественные и качественные характеристики реального объекта. Например, атрибуты объекта ТОВАРЫ: Код товара, Код поставщика, Наименование, Марка, Цена.

Атрибуты подразделяются на ключевые и описательные. Ключевой атрибут (ключ) однозначно определяет отдельный конкретный экземпляр объекта. Неключевые атрибуты называются описательными.

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

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

Атрибут В функционально зависит от атрибута А, если каждому значению атрибута А соответствует только одно значение атрибута В.

Требования нормализации, которые реализуются в Access следующие:

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

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

т.е. между ними не может быть функциональных зависимостей;

- все атрибуты, входящие в составной ключ, должны быть также

взаимно независимы;

- каждый описательный атрибут должен функционально зависеть

от ключа;

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

- каждый описательный атрибут не может зависеть от ключа

транзитивно, т.е. через другой промежуточный атрибут. В случае транзи-

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

Выполнение требований нормализации обеспечивает построение

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

поддержки целостности при внесении изменений.

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

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

атрибуты, подлежащие хранению в базе данных;

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

-выбрать все зависимые атрибуты и указать для них ключевые

атрибуты;

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

атрибутов.

Полученные группы зависимых атрибутов вместе с

ключевыми атрибутами образуют информационные объекты.

Например, перечислим атрибуты, характеризующие товары:

1) код товара;

2) наименование;

3) марка;

4) цена;

5) код поставщика;

6) фирма;

В Access предусмотрена автоматизированная нормализация таблиц (выполняется сервис—анализ – таблица). Для этого необходимо указать

значения атрибутов. Они указаны в таблице, приведенной ниже:

Таблица№1

Код товара	Код пос- тавщика	Наименование	Марка	Цена	Фирма
		Телевизор	Gold star		Техносила
		Плеер	Philips		Техносила
		Плеер	Panasonic		М.Видео
		Видеомагнитофон	Gold star		М.Видео

Значения повторяются в полях «Наименование», а также в полях «Код поставщика» и «Фирма».Согласно определения функциональной зависимости, это означает следующее:

Атрибуты 2-5 функционально зависят от кода товара, атрибут фирма функционально зависит от кода поставщика. Атрибут 6-фирма транзитивно зависит от кода товара через атрибут 5-код поставщика.

Условие нормализации выполнится, если в данном случае будут созданы два информационных объекта: ТОВАРЫ (таблица «Товары») и ПОСТАВЩИКИ(таблица «Поставщики»), содержащие ключевые атрибуты «код товара» и «код поставщика» соответственно.

Таблица «Товары»

Код товара	Код пос- тавщика	Наименование	Марка	Цена
		Телевизор	Gold star
		Плеер	Philips
		Плеер	Panasonic
		Видеомагнитофон	Gold star

Таблица «Поставщики»

Код поставщика	Фирма
	Техносила
	М.Видео

Обратите внимание, что между полями марка и наименование нет функциональной зависимости. Если бы зависимости между полями имели место, то для нормализации нужно было бы создать еще одну таблицу. Без применения нормализации получение правильных результатов в Access не гарантируется. Во многих случаях, однако, получение корректных результатов удается, особенно при применении в SQL-запросах операции проектирования (в главе мы рассмотрим применение операторов DISTINCT, DISTINCTROW) типами отношений связи:

Одно-однозначные (1: 1)

Одно-многозначные (1: М)
Много-многозначные (М: N)

Одно-однозначные типы отношений имеют место, когда каждому экземпляру первого объекта (А) соответствует только один экземпляр второго объекта (B) и, наоборот, каждому экземпляру второго объекта (В) соответствует только один экземпляр первого объекта (А).

Одно-многозначные типы отношений характеризуются тем, что каждому экземпляру одного объекта (А) может соответствовать несколько экземпляров другого объекта (В), а каждому экземпляру второго объекта (В) соответствует только один экземпляр первого объекта (А).

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

Типы отношений связи 1:М и М:1 различаются лишь выбором главного объекта, причем главным считается тот объект, каждому экземпляру

которого соответствуют много экземпляров другого объекта.

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

Исходные объекты будут связаны с этим объектом одно-многозначным типом отношений. Таким образом, объект- связка является подчиненным в одно-многозначных типах отношений по отношению к каждому из исходных объектов (см. рис. ниже).

Примером много-многозначных типов отношений может быть связь поставщики-товары, если один поставщик поставляет разные товары, а один и тот же товар поставляется несколькими поставщиками. В качестве объекта-связки используем таблицу «Заказано».Из таблицы «Товары» удалим поле

«Код поставщика», так как таблицы «Товары» и «Поставщики» связываются только через таблицу-связку.

Товары

Код товара

М:N 1:М

	Поставляет
	Код поставщика + Код товара
Поставщики
Код поставщика

1:M

Рис.1.Схема данных для отношения связи многие-ко-многим

Тип отношений М:N реализуется, если один и тот же товар поставляют несколько поставщиков, например, с кодом поставщика 1 и 2. В этом случае формируется таблица-связка «Поставляет», в которой повторяются все записи из таблицы «Товары» и первая запись с изменением кода поставщика 1 на 2. Таблица «Поставляет» имеет составной ключ, состоящий из двух полей «Код товара» и «Код поставщика» так, что с таблицей «Товары» осуществляется связь по полю «Код товара», а с таблицей «Поставщики» по полю «Код поставщика».Поскольку в каждом из полей, составляющих составной ключ, есть повторяющиеся записи, таблица «Поставляет» связана с каждой из нормализованных таблиц «Товары» и «Поставщики» в отношении М:1.

Таблица «Поставляет»

Код товара	Код поставщика	Наименование	Марка	Цена
		Телевизор	Gold star
		Плеер	Philips
		Плеер	Panasonic
		Видеомагнитофон	Gold star
		Телевизор	Gold star

На этом этапе информационные объекты изображаются соответ-

ствующими реляционными таблицами. В таблице каждый столбец

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

В нашем примере таблица ТОВАРЫ должна содержать следующие поля: Код товара, название, марка, цена. Ключевое поле – код товара, так как от этого атрибута функционально зависят все другие атрибуты.

Таблица «ПОСТАВЩИКИ» содержит следующие поля: Код поставщика, фирма, телефон, адрес. Ключевое поле-код поставщика.

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

СУБД Access поддерживает реляционные базы данных.

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

Разработать структуру таблицы - это означает задать поля и их ат-

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

Имя поля (до 64 символов) не может начинаться с пробела и не содержит символы: «.», «!», «‘», «[», «]».

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

Тип данных Размер поля

1. Текстовый (не более 255 символов)   2.Memo   3.Числовой - длинное целое - целое - с плавающей точкой - дробные с плавающей точкой с точностью до 15 знаков - действительное 4.Денежный с фиксированной точкой (15 знаков целая часть и 4 знака дробная часть) 5.Логический 6.Счетчик - длинное целое или код репликации (глобальный уникальный идентификатор реплик (копий) баз данных) 7.Поле объекта ОLE (объект, связанный или внедренный в таблицу) 8.Гиперссылка 9.Мастер подстановок Мастер строит для поля список значений на основе полей из другой таблицы. Тип данных поля определяется типом данных поля списка

От 1 до 255 байтов (по умолчанию 50) 64 000 символов     4байта 2байта 4байта 8байт 12байт 8байт 1бит 4байта   128 байт До 1Гбайта До 64 000 символов

Для установления взаимосвязей между таблицами, а также

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

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

Дата добавления: 2014-01-07