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

Содержание:

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 правил. Устанавливаются  связи между таблицами посредством  механизма первичных и внешних  ключей. Структуры таблиц и установленные  связи между ними документируются.

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

4. Проверка логической  модели данных  на предмет возможности  выполнения всех транзакций, предусмотренных  пользователями. Транзакция – это  набор действий, выполняемых отдельным  пользователем или прикладной  программой с целью изменения  содержимого базы данных. Так,  примером транзакции в проекте  БАНК может быть передача права  распоряжаться счетами некоторого  клиента другому клиенту. В  этом случае в базу данных  потребуется внести сразу несколько  изменений. Если во время выполнения  транзакции произойдет сбой в  работе компьютера, то база данных  окажется в противоречивом состоянии,  так как некоторые изменения  уже будут внесены, а остальные  еще нет. Поэтому все частичные  изменения должны быть отменены  для возвращения базы данных  в прежнее непротиворечивое состояние.

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

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

· обязательные данные. Выясняется, есть ли атрибуты, которые не могут иметь Null-значений;

· ограничения для  значений атрибутов. Определяются допустимые значения для атрибутов;

· целостность сущностей. Она достигается, если первичный  ключ сущности не содержит Null-значений;

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

· ограничения, накладываемые  бизнес-правилами. Например, в случае с проектом БАНК может быть принято  правило, запрещающее клиенту распоряжаться, скажем, более чем тремя счетами.

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

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

Физическое  проектирование - определение особенностей хранения данных, методов доступа и т.д.

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

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

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

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

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

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

Принятые решения  по изложенным вопросам документируются.

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

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

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

  основные принципы проектирования Базы данных

Процесс проектирования ИС состоит из

сбора данных;

составления частных  ЛПП;

унификации пересекающихся эпизодов;

составления ГПП;

формирования модели предметной области (инфологическое проектирование);

составления схемы  с учетом используемого СУБД (концептуальное проектирование);

физического проектирования.

 Инфологическое  моделирование 

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

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

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

Модель «сущность-связь» позволяет представлять объекты  предметной области и отношения  между ними, т.е. позволяет описывать  структуру предметной области. Она  определяется в терминах: сущность, атрибут, связь.

Сущность - представление (абстракция) реально существующего объекта, процесса или явления. Наименование сущности должно быть уникально во всей модели.

Тип сущности - определяет набор однородных объектов.

Экземпляр сущности - конкретный объект из этого набора.

Атрибут - свойство сущности (объекта). Его имя должно быть уникально в рамках одной сущности.

Экземпляр атрибута - конкретное значение свойства.

Идентифицирующий  атрибут (идентифицирующая совокупность атрибутов, ИСА) - атрибут (несколько атрибутов), значение которого определяет уникальность экземпляра сущности.

Связь позволяет моделировать отношения между объектами предметной области. Наименование связи должно быть уникально во всей модели.

Теперь попытаемся составить полную инфологическую модель задачи «Школьный журнал». Для этого  перечислим те правила, которым должна удовлетворять модель «сущность-связь»:

Модель должна давать полное представление о предметной области.

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

Имена сущностей  должны быть уникальны.

Имена атрибутов  в пределах одной сущности должны быть уникальны.

Мы должны гарантировать  однозначную трактовку модели.

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

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

Представленная на рисунке ниже модель позволяет решить основные задачи школьного журнала. Она является одним из многих возможных  вариантов решения. Ее составление  шло для вымышленной школы. Более  того, представленная модель не в полной мере отвечает требованию гибкости. Мы не можем ученику по одному предмету выставить сразу несколько оценок. Обойти такое ограничение можно  введением абстрактного атрибута «№ оценки». Этот атрибут не несет смысловой  нагрузки, кроме количественной, однако, определив его как идентифицирующий, мы избежим трудностей при выставлении  оценок.

Сущность «Ученик» содержит все личные данные учащегося.

Сущность «Кабинет»  содержит информацию о техническом  уровне, состоянии, количестве мест.

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

Сущность «Оценка» содержит информацию об оценке, полученной учеником по определенному предмету, выставленную преподавателем в конкретный день. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Литература:

- Дейт К. Дж. Введение в системы баз данных = Introduction to Database Systems. — 8-е изд. — М.: «Вильямс», 2006. — 1328 с. — ISBN 0-321-19784-4

- Кузнецов С. Д. Основы баз данных. — 2-е изд. — М.: Интернет-Университет Информационных Технологий; БИНОМ. Лаборатория знаний, 2007. — 484 с. — ISBN 978-5-94774-736-2

- http://www.online-academy.ru/demo/access/urok1/teor/teor2.htm