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

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

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

1. Постановка задачи.

2. Разработка информационно-логической (инфологической) модели.

3. Выбор СУБД. Разработка логической модели базы данных.

4. Разработка программного обеспечения базы данных.

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

Рассмотрим эти этапы более подробно.

1-й этап. Постановка задачи

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

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

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

2-й этап. Разработка информационно-логической (инфологической) модели

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

Нередко для описания инфологической модели используются диаграммы "сущность-связь" (ER-диаграммы).

3-й этап. Выбор СУБД. Разработка логической модели базы данных

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

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

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

4-й этап. Разработка программного обеспечения базы данных

Созданные на 3-м этапе таблицы заполняются данными контрольного примера. Разрабатываются дополнительные объекты базы данных: запросы, программные модули, формы для работы с данными, печатаемые на основе данных базы документы и т.п. Результаты разработки проверяются на контрольном примере. Желательно согласовывать результаты с персоналом, который в будущем будет работать с базой.

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

5-й этап. Заполнение базы рабочими данными и поддержание ее в актуальном состоянии

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

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

Вопросы для самоконтроля:

1. Перечислите этапы разработки базы данных.

2. На каком этапе производится первичное обучение пользователей?

3. На каком этапе определяется перечень входной и выходной информации и детальные характеристики этой информации?

4. На каком этапе определяются цели разработки БД?

5. На каком этапе производится распределение данных по таблицам, описывается структура каждой таблицы?

1.5 Особенности архитектуры информационных систем. Одно – двух – и трехуровневые системы

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

· централизованная архитектура;

· архитектура "файл-сервер";

· архитектура "клиент – сервер";

· трехзвенная (многозвенная) архитектура "клиент – сервер"

Рассмотрим эти технологии более подробно.

При разработке БД можно выделить следующие этапы работы.

I этап. Постановка задачи.

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

II этап. Анализ объекта.

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

III этап. Синтез модели.

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

IV этап. Выбор способов представления информации и программного инструментария.

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

В большинстве СУБД данные можно хранить в двух видах:

• с использованием форм;
• без использования форм.

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

V этап. Синтез компьютерной модели объекта.

В процессе создания компьютерной модели можно выделить некоторые стадии, типичные для любой СУБД.

Стадия 1. Запуск СУБД, создание нового файла базы данных или открытие созданной ранее базы.

Стадия 2. Создание исходной таблицы или таблиц.

Создавая исходную таблицу, необходимо указать имя и тип каждого поля. Имена полей не должны повторяться внутри одной таблицы. В процессе работы с БД можно дополнять таблицу новыми полями. Созданную таблицу необходимо сохранить, дав ей имя, уникальное в пределах создаваемой базы.

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

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

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

4. База данных должна иметь первичный ключ. Это необходимо для того, чтобы СУБД могла связать данные из разных таблиц, например, данные о клиенте и его заказы.

Стадия 3. Создание экранных форм.

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

Стадия 4. Заполнение БД.

Процесс заполнения БД может проводиться в двух видах: в виде таблицы и в виде формы. Числовые и текстовые поля можно заполнять в виде таблицы, а поля типа МЕМО и OLE – в виде формы.

VI этап. Работа с созданной базой данных.

Работа с БД включает в себя следующие действия:

• поиск необходимых сведений;
• сортировка данных;
• отбор данных;
• вывод на печать;
• изменение и дополнение данных.

Процесс проектирования включает в себя следующие этапы.

Инфологическое проектирование.

Определение требований к операционной обстановке, в которой будет функционировать информационная система.

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

Логическое проектирование БД.

Физическое проектирование БД.

1.1. Инфологическое проектирование.

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

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

В настоящее время применяют проектирование с использованием метода "Сущность-связь"(entity–relation, ER–method), который является комбинацией предметного и прикладного методов и обладает достоинствами обоих.

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

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

Сущность – это объект, о котором в системе будет накапливаться информация. Сущности бывают как физически существующие (например, СОТРУДНИК или АВТОМОБИЛЬ ), так и абстрактные (например, ЭКЗАМЕН или ДИАГНОЗ ).

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

Стержневая сущность (стержень ) – это независимая сущность, которая не является ни ассоциацией, ни обозначением, ни характеристикой. Такие сущности имеют независимое существование, хотя они и могут обозначать другие сущности.

Ассоциативная сущность (ассоциация ) – это связь вида "многие-ко-многим" между двумя или более сущностями или экземплярами сущности. Ассоциации рассматриваются как полноправные сущности, они могут: участвовать в других ассоциациях и обозначениях точно так же, как стержневые сущности; обладать свойствами, т.е. иметь не только набор ключевых атрибутов, необходимых для указания связей, но и любое число других атрибутов, характеризующих связь.

Характеристическая сущность ( характеристика ) – это связь вида "многие-к-одной" или "одна-к-одной" между двумя сущностями (частный случай ассоциации). Единственная цель характеристики в рамках рассматриваемой предметной области состоит в описании или уточнении некоторой другой сущности. Необходимость в них возникает в связи с тем, что сущности реального мира имеют иногда многозначные свойства.

Например, муж может иметь несколько жен, книга – несколько характеристик переиздания (исправленное, дополненное, ...) и т.д.

Существование характеристики полностью зависит от характеризуемой сущности: женщины лишаются статуса жен, если умирает их муж.

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

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

Тип сущности характеризуется именем и списком свойств, а экземпляр – конкретными значениями свойств.

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

Например, читатель библиотеки – сильная сущность, а абонемент этого читателя – слабая, которая зависит от наличия соответствующего читателя.

Слабые сущности называют подчинёнными (дочерними) , а сильные – базовыми (основными, родительскими) .

Для каждой сущности выбираются свойства (атрибуты).

Различают:

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

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

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

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

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

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

Каждая связь характеризуется именем, обязательностью , типом и степенью . Различают факультативные и обязательные связи. Если вновь порождённый объект одного типа оказывается по необходимости связанным с объектом другого типа, то между этими типами объектов существует обязательная связь (обозначается двойной линией). Иначе связь является факультативной .

По типу различают множественные связи "один к одному" (1:1), "один ко многим" (1:n) и "многие ко многим" (m:n). ER–диаграмма, содержащая различные типы связей, приведена на рис. 1. Обратите внимание, что обязательные связи на рис. 1 выделены двойной линией.

Степень связи определяется количеством сущностей, которые охвачены данной связью. Пример бинарной связи – связь между отделом и сотрудниками, которые в нём работают. Примером тернарной связи является связь типа экзамен между сущностями ДИСЦИПЛИНА , СТУДЕНТ , ПРЕПОДАВАТЕЛЬ . Из последнего примера видно, что связь также может иметь атрибуты (в данном случае это Дата проведения и Оценка ). Пример ER–диаграммы с указанием сущностей, их атрибутов и связей приведен на рис. 2.

Принимаемые проектные решения можно описать языком инфологического моделирования (ЯИМ), основанном на языке SQL, который позволяет дать удобное и полное описание любой сущности и, следовательно, всей базы данных. Например:

СОЗДАТЬ ТАБЛИЦУ Блюда *(Стержневая сущность)

ПЕРВИЧНЫЙ КЛЮЧ (БЛ)

ПОЛЯ (БЛ Целое, Блюдо Текст 60, Вид Текст 7)

ОГРАНИЧЕНИЯ (1. Значения поля Блюдо должны быть

уникальными; при нарушении вывод

сообщения "Такое блюдо уже есть".

2. Значения поля Вид должны принадлежать

набору: Закуска, Суп, Горячее, Десерт,

Напиток; при нарушении вывод сообщения

"Можно лишь Закуска, Суп, Горячее,

Десерт, Напиток");

СОЗДАТЬ ТАБЛИЦУ Состав *(Связывает Блюда и Продукты)

ПЕРВИЧНЫЙ КЛЮЧ (БЛ, ПР)

ВНЕШНИЙ КЛЮЧ (БЛ ИЗ Блюда

NULL-значения НЕ ДОПУСТИМЫ

УДАЛЕНИЕ ИЗ Блюда КАСКАДИРУЕТСЯ

ОБНОВЛЕНИЕ Блюда.БЛ КАСКАДИРУЕТСЯ)

ВНЕШНИЙ КЛЮЧ (ПР ИЗ Продукты

NULL-значения НЕ ДОПУСТИМЫ

УДАЛЕНИЕ ИЗ Продукты ОГРАНИЧИВАЕТСЯ

ОБНОВЛЕНИЕ Продукты.ПР КАСКАДИРУЕТСЯ)

ПОЛЯ (БЛ Целое, ПР Целое, Вес Целое)

ОГРАНИЧЕНИЯ (1. Значения полей БЛ и ПР должны принадлежать

набору значений из соответствующих полей таблиц

Блюда и Продукты; при нарушении вывод сообщения

"Такого блюда нет" или "Такого продукта нет".

2. Значение поля Вес должно лежать в пределах от 0.1 до 500 г.);

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

В ER диаграммах "Сущность-связь" сущности изображаются (рис.2) помеченными прямоугольниками , ассоциации – помеченными ромбами или шестиугольниками , атрибуты – помеченными овалами , а связи между ними – ненаправленными ребрами (линиями, соединяющими геометрические фигуры), над которыми может проставляться степень связи (1 или буква, заменяющая слово "много") и необходимое пояснение.

В языке инфологического моделирования "Таблица-связь" (рис.3) все сущности изображаются одностолбцовыми таблицами с заголовками , состоящими из имени и типа сущности . Строки таблицы – это перечень атрибутов сущности, а те из них, которые составляют первичный ключ, располагаются рядом и обводятся рамкой. Связи между сущностями указываются стрелками, направленными от первичных ключей или их составляющих.

(стержень)