2. Проектирование баз данных. Общая характеристика.

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

Логическое проектирование заключается в определении числа и структу­ры таблиц, формировании запросов к БД, определении типов отчетных доку­ментов, разработке алгоритмов обработки информации, создании форм для ввода и редактирования данных в базе и решении ряда других задач.

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

При проектировании структур данных для автоматизированных систем можно выделить три основных подхода:

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

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

3. Структурирование информации для использования в информационной системе в процессе проведения системного анализа на основе совокупности правил и рекомендаций.

2. Проектирование базы данных. Определение сущностей.

Основное правило при создании таблиц сущностей - это «каждой сущнос­ти - отдельную таблицу» (как в популярном лозунге: «каждой семье - от­дельную квартиру»).

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

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

Иногда в таблицах сущностей имеются поля описания свойств или характерис­тик объектов. Если в таблице есть значительное число повторений по этим полям и эта информация имеет существенный объем, то лучше их выделить в отдельную таблицу (придерживаясь правила: «каждой сущности - отдельную таблицу»). Тем более, следует образовать дополнительную таблицу, если свойства взаимосвязаны.

В более общем виде последние рекомендации можно сформулировать так:

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

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