Концепции проектирования БД

Трехуровневая архитектура базы данных

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

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

Концептуальная схема должна содержать: ƒ сущности и их атрибуты;

ƒ связи между сущностями;

ƒ ограничения, накладываемые на данные;

ƒ семантическую информацию о данных;

ƒ обеспечение безопасности и поддержки целостности данных.

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

Концепции проектирования БД

3.1. Жизненный цикл БД

Как и любой программный продукт, база данных обладает собственным жизненным циклом (ЖЦБД). Главной составляющей в жизненном цикле БД является создание единой базы данных и программ, необходимых для ее работы. ЖЦБД включает в себя следующие основные этапы (рис. 3.1):

1. планирование разработки базы данных;

2. определение требований к системе;

3. сбор и анализ требований пользователей;

4. проектирование базы данных: концептуальное проектирование базы данных; логическое проектирование базы данных; физическое проектирование базы данных;

5. разработка приложений: проектирование пользовательского интерфейса;

6. реализация;

7. загрузка данных;

8. тестирование;

9. эксплуатация и сопровождение:

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

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

Вторая часть — проверка операционной осуществимости — выяснение наличия экспертов и персонала, необходимых для работы БД.

Третья часть — проверка экономической целесообразности осуществления проекта.

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

· величина риска, связанного с реализацией системы базы данных;

· ожидаемая выгода от внедрения подлежащих созданию приложений; ƒ

· время окупаемости внедренной БД;

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

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

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

Концептуальное проектирование базы данных Первая фаза процесса проектирования базы данных заключается в создании для анализируемой части предприятия концептуальной модели данных. Проектирование сложных баз данных с большим количеством атрибутов осуществляется использованием, так называемого, нисходящего подхода. 29 Этот подход начинается с разработки моделей данных, которые содержат несколько высокоуровневых сущностей и связей, затем работа продолжается в виде серии нисходящих уточнений низкоуровневых сущностей, связей и относящихся к ним атрибутов. Нисходящий подход демонстрируется в концепции модели "сущность — связь" (Entity-Relationship model — ER-модель) — самой популярной технологии высокоуровневого моделирования данных, предложенной П. Ченом. Модель "сущность — связь" относится к семантическим моделям. Семантическое моделирование данных, связанное со смысловым содержанием данных, независимо от их представления в ЭВМ. В построении общей концептуальной модели данных выделяют ряд этапов. ƒ Выделение локальных представлений, соответствующих обычно относительно независимым данным. Каждое такое представление проектируется как подзадача. ƒ Формулирование сущностей, описывающих локальную предметную область проектируемой БД, и описание атрибутов, составляющих структуру каждой сущности. ƒ Выделение ключевых атрибутов. ƒ Спецификация связей между сущностями. Удаление избыточных связей. ƒ Анализ и добавление неключевых атрибутов. ƒ Объединение локальных представлений. Созданная концептуальная модель данных предприятия является источником информации для фазы логического проектирования базы данных.

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

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

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

ƒ разработка средств зашиты создаваемой системы.

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

ƒ содержательное название;

ƒ ясные и понятные инструкции;

ƒ логически обоснованные группировки и последовательности полей;

ƒ визуально привлекательный вид окна формы или поля отчета;

ƒ легко узнаваемые названия полей;

ƒ согласованную терминологию и сокращения;

ƒ согласованное использование цветов;

ƒ визуальное выделение пространства и границ полей ввода данных;

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

ƒ средства исправления отдельных ошибочных символов и целых полей;

ƒ средства вывода сообщений об ошибках при вводе недопустимых значений;

ƒ особое выделение необязательных для ввода полей;

ƒ средства вывода пояснительных сообщений с описанием полей;

ƒ средства вывода сообщения об окончании заполнения формы.

Реализация На данном этапе осуществляется физическая реализация базы данных и разработанных приложений, позволяющих пользователю формулировать требуемые запросы к БД и манипулировать данными в БД. База данных описывается на языке определения данных выбранной СУБД. В результате компиляции его команд и их выполнения создаются схемы и пустые файлы базы данных. На этом же этапе определяются и все специфические пользовательские представления. Прикладные программы реализуются с помощью языков третьего или четвертого поколений. Кроме того, на этом этапе создаются другие компоненты проекта приложения — например, экраны меню, формы ввода данных и отчеты. Реализация этого, а также и более ранних этапов проектирования БД может осуществляться с помощью инструментов автоматизированного проектирования и создания программ, которые принято называть CASE- инструментами (Computer-Aided Software Engineering).

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

Тестирование Для оценки законченности и корректности выполнения приложения базы данных может использоваться несколько различных стратегий тестирования:

ƒ нисходящее тестирование;

ƒ восходящее тестирование;

ƒ тестирование потоков;

ƒ интенсивное тестирование.

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

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

Фундаментальные понятия проектирования Для нормального функционирования информационной системы необходимо, чтобы концептуальная модель адекватно отображала реалии той предметной области, для которой она разрабатывается. Методологии, позволяющие эффективно отображать существующую смысловую содержательность реальности в конструкции модели, относятся к так называемым семантическим методологиям. Наиболее популярной семантической моделью стала уже упоминавшаяся раннее модель "сущность — связь" (ER-модель), предложенная П. Ченом в 1976 году, которая с тех пор неоднократно усовершенствовалась самим Ченом и многими другими специалистами.

Главными элементами семантической модели данных являются сущности, их атрибуты и типы связей. Сущности часто представляют в виде существительных, а типы связей — в виде глаголов. Семантическая модель предметной области изображается в виде диаграммы с учетом принятых обозначений для ее элементов {рис. 3.2).

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

Атрибут — это поименованная характеристика сущности, с помощью которой моделируется ее свойство. Каждой сущности присущи свои атрибуты. Например, сущность ТОВАР должна иметь такие атрибуты: Наименование_товара, Индекс_товара, Цена_товара, Количество.

Ключи Среди атрибутов особое положение занимают такие, с помощью которых можно идентифицировать экземпляр сущности. Такие атрибуты называются ключами. Атрибут или несколько атрибутов, значения которых уникальным образом идентифицируют каждый экземпляр сущности, являются потенциальным ключом данной сущности. Потенциальных ключей может быть несколько. Например, экземпляр сущности ФАКУЛЬТЕТ (Код_факультета, Название_факультета, ФИО_декана) может однозначно идентифицироваться любым из первых двух указанных атрибутов. Один из потенциальных ключей может быть выбран в качестве первичного ключа. Обычно в качестве первичного ключа выбирается тот, который имеет наименьшую длину. Остальные потенциальные ключи называются альтернативными. Тот факт, что атрибут служит первичным ключом, отмечается его подчеркиванием. Идентификацию некоторых сущностей иногда приходится осуществлять при помощи составных ключей, которые включают несколько атрибутов. Например, сущность: ЛЕЧЕНИЕ (ФИО_врача, ФИО_пациента, Дата_назначения, Лекарство) , однозначно идентифицировать можно только составным ключом: (ФИО_врача, ФИО_пациента, Дата_назначения).

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