Мы поможем в написании ваших работ!



ЗНАЕТЕ ЛИ ВЫ?

Этапы проектирования базы данных

Поиск

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

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

При разработке эскиза необходимо ответить на следующие вопросы:

Какими данными мы располагаем?

Какие данные будут содержать таблицы?

Какой тип и какие свойства должны иметь данные в каждом поле таблицы?

Как эти таблицы будут связаны друг с другом?

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

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

Этапы проектирования базы данных:

1. Исследование предметной области и формулировка основных допущений (накладываемых условий). На этом этапе составляется список всех форм и отчетов, которые могут быть затребованы пользователями вашей БД.

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

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

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

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

Правило 3: В таблице не должно быть данных не относящихся к объекту, определяемому первичным ключом.

Правило 4: Независимость полей. Это правило означает возможность изменять значения любого поля (не входящего в первичный ключ) без воздействия на данные других полей.

Результатом 3 этапа должна явиться группа таблиц, удовлетворяющих правилам нормализации. На этом же этапе необходимо установить связи между таблицами.

Пример проектирования БД

Задача: Создать БД реализации товаров со складов, при условии, что на одном складе может храниться только один вид товара.

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

Отчет №1. Данные о товарах (Наименование, Марка, Цена, Номер телефона склада, где хранится товар, Количество имеющегося на складе товара, Описание товара, Название фирмы, которая занимается реализацией товара).

Отчет №2. Данные о фирмах (Название фирмы, Адрес фирмы, Телефон фирмы, Наименование товара, реализуемого фирмой).

Отчет №3. Система скидок (Фирма, Товар, Скидка).

Отчет №4. Продажи (Дата, Фирма, Товар, Марка товара, Количество проданного товара).

Отчет №5. Данные о складах (Номер склада, Адрес склада, Телефон склада, Фамилия заведующего, Товар, хранимый на складе).

Отчет №6. Данные о контактных лицах фирм (Фамилия, Имя, Дата рождения, Домашний адрес, Домашний телефон, Должность, Название фирмы, сотрудником которой он является).

Отчет №7. Список директоровфирм (Фамилия, Телефон фирмы, Адрес фирмы, Домашний телефон, Домашний адрес)*.

2. Составим подробный перечень всех элементов данных, требуемых для отчетов и сгруппируем их в таблицы БД:

  Отчет №1 Отчет №2 Отчет №3 Отчет №4 Отчет №5 Отчет №6 Отчет №7
Наименование товара + + + + +    
Марка товара +     +      
Цена +            
Количество +            
Описание товара +            
Название фирмы + + + +   +  
Адрес фирмы   +         +
Телефон фирмы   +         +
Скидка     +        
Номер склада         +    
Адрес склада         +    
Телефон склада +       +    
Фамилия заведующего         +    
Дата продажи       +      
Количество продажи       +      
Фамилия контактного лица           + +
Имя           +  
Дата рождения           +  
Адрес домашний           + +
Телефон домашний           + +
Должность           + +

 


Сгруппируем данные в таблицы:

Таблица 1 Таблица 2 Таблица 3

Товары Фирмы Склады

           
 
Товар Марка Цена Телефон склада Количество Описание Фирма
 
Фирма Адрес фирмы Телефон фирмы Товар
 
Склад Адрес склада Телефон склада Заведующий
 

 

 


Таблица 4 Таблица 5

Фирма Товар Марка товара Кол-во товара Дата продажи Скидка
Фамилия Имя Дата рождения Адрес домашний Телефон домашний Фирма Должность
Контактные лица Продажи

 

 

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

Код фирмы Название фирмы Адрес фирмы Телефон фирмы Код товара
Код товара Наименование товара Марка Цена № склада Количество Описание Код фирмы
Товары Фирмы Контактные лица

Код сотрудника Фамилия Имя Дата рождения Адрес домашний Телефон домашний Код фирмы Должность

 

 


№ cклада Адрес склада Телефон склада Заведующий
Склады

 

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

Существует 3 типа связей:

"один к одному" – каждой записи одной таблицы соответствует только одна запись в другой;

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

"многие ко многим" – множеству записей одной таблицы соответствует множество записей другой таблицы.

При определении связи ключ в одной таблице содержит ссылки на конкретные записи в другой таблице. Поле, не являющееся ключевым для данной таблицы, но значения которого являются значениями первичного ключа другой таблицы, называют внешним ключом[3]. Содержимое поля внешнего ключа (значения и свойства) должно совпадать с содержимым ключевого поля. Эти поля также могут иметь одинаковые имена.

В нашем примере между полученными объектами установились следующие отношения:

"Склады" и "Товары"–– отношение "один ко многим"[4];

"Фирмы" и "Контактные лица" –– отношение "один ко многим";

"Фирмы" и "Товары" - отношение "многие ко многим".

Аccess не позволяет определить прямую связь "многие ко многим" между двумя таблицами. В этом случае необходимо создать дополнительную таблицу пересечения, с помощью которой одна связь "многие ко многим" будет сведена к двум связям типа "один ко многим". В нашем примере такой дополнительной таблицей может являться таблица "Продажи", ключ которой состоит из двух полей (составной ключ), являющимися полями первичного ключа в таблицах "Фирмы" и "Товары".

Код фирмы Код товара Кол-во товара Дата продажи Скидка
Продажи

 

 

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

 
 

Графически связи и таблицы после преобразования могут быть представлены в следующем виде:

Рисунок 2. Схема БД Продажи.



Поделиться:


Последнее изменение этой страницы: 2016-07-16; просмотров: 714; Нарушение авторского права страницы; Мы поможем в написании вашей работы!

infopedia.su Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Обратная связь - 3.14.254.103 (0.007 с.)