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

 

 

Содержание:

1. Задачи проектирования базы данных                                                3-4 стр.
2. Основные этапы проектирования                                                        5-10 стр.
3. Основные принципы проектирования Базы данных                      11-14 стр.
4. Литература                                                                                                  15 стр.                                                   

 

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

1. Определение цели  создания базы данных.

2. Определение таблиц, которые должна содержать база  данных.

3. Определение необходимых  в таблице полей.

4. Задание первичного  ключа для каждой таблицы.

5. Определение связей  между таблицами.

6. Обновление структуры  базы данных.

7. Добавление данных  и создание других объектов  базы данных.

1. Определение цели  создания базы  данных

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

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

2. Определение таблиц, которые должна  содержать база  данных

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

  При проектировании таблиц вовсе не обязательно использовать Microsoft Access. Сначала лучше разработать структуру на бумаге. При проектировке таблиц рекомендуется руководствоваться следующими основными принципами:

- Информация в  таблице не должна дублироваться.  Не должно быть повторений и между таблицами.

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

- Каждая таблица  должна содержать информацию  только на одну тему.

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

3. Определение необходимых  в таблице полей

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

- Каждое поле должно  быть связано с темой таблицы.

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

- В таблице должна  присутствовать вся необходимая  информация.

- Информацию следует  разбивать на наименьшие логические  единицы (Например, поля «Имя»  и «Фамилия», а не общее поле  «ФИО»).

4. Задание первичного  ключа для каждой  таблицы

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

5. Определение связей  между таблицами

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

6. Обновление структуры  базы данных

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

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

   7. Добавление данных и создание других объектов базы данных

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

   
 
 
 
 
 

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

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

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

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

В теории проектирования информационных систем предметную область (или, если угодно, весь реальный мир  в целом) принято рассматривать  в виде трех представлений:

-представление предметной области в том виде, как она реально существует

-как ее воспринимает человек (имеется в виду проектировщик базы данных)

-как она может  быть описана с помощью символов.

Данные, используемые для описания предметной области, представляются в виде трехуровневой схемы (так  называемая модель ANSI/SPARC):

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

Отсюда вытекают основные этапы, на которые разбивается  процесс проектирования базы данных информационной системы:

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

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

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

-моделирование и  интеграция всех представлений 

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

Процедуры концептуального  проектирования

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

1. Определение сущностей  и их документирование. Для идентификации сущностей определяются объекты, которые существуют независимо от других. Такие объекты являются сущностями. Каждой сущности присваивается осмысленное имя, понятное пользователям. Имена и описания сущностей заносятся в словарь данных. Если возможно, то устанавливается ожидаемое количество экземпляров каждой сущности.

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

3. Создание ER-модели  предметной области.  Для представления сущностей и связей между ними используются ER-диаграммы. На их основе создается единый наглядный образ моделируемой предметной области – ER-модель предметной области.

4. Определение атрибутов  и их документирование. Выявляются все атрибуты, описывающие сущности созданной ER-модели. Каждому атрибуту присваивается осмысленное имя, понятное пользователям. О каждом атрибуте в словарь данных помещаются следующие сведения:

· имя атрибута и  его описание;

· тип и размерность  значений;

· значение, принимаемое  для атрибута по умолчанию (если такое имеется);

· может ли атрибут иметь Null-значения;

· является ли атрибут  составным, и если это так, то из каких  простых атрибутов он состоит.

· является ли атрибут  расчетным, и если это так, то как вычисляются его значения.

5. Определение значений  атрибутов и их  документирование.  Для каждого атрибута сущности, участвующей в ER-модели, определяется набор допустимых значений и ему присваивается имя. Например, атрибут "Тип счета" может иметь только значения "депозитный", "текущий", "до востребования", "карт-счет". Обновляются записи словаря данных, относящиеся к атрибутам, – в них заносятся имена наборов значений атрибутов.

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

7. Обсуждение концептуальной  модели данных  с конечными пользователями. Концептуальная модель данных представляется ER-моделью с сопроводительной документацией, содержащей описание разработанной модели данных. Если будут обнаружены несоответствия предметной области, то в модель вносятся изменения до тех пор, пока пользователи не подтвердят, что предложенная им модель адекватно отображает их личные представления.

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

Процедуры логического проектирования

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

1. Выбор модели  данных. Чаще  всего выбирается  реляционная модель данных в  связи с наглядностью табличного  представления данных и удобства работы с ними.

2. Определение набора  таблиц исходя из ER-модели и  их документирование. Для каждой  сущности ER-модели создается таблица.  Имя сущности – имя таблицы.  Осуществляется формирование структуры  таблиц на основании изложенных  в параграфе 1.4 правил. Устанавливаются  связи между таблицами посредством  механизма первичных и внешних  ключей. Структуры таблиц и установленные  связи между ними документируются.