Логическое проектирование базы данных
При проектировании любой базы данных всегда следует иметь в виду конечного пользователя. Логическое проектирование базы данных (также называемое построением ее логической модели) представляет собой процесс объединения данных в логически организованные группы объектов, которые можно легко поддерживать. Логическое проектирование базы данных должно приводить к уменьшению повторяющейся информации или даже полному ее устранению. В конце концов, зачем хранить одни и те же данные дважды? Кроме того, все используемые в базе данных соглашения о наименованиях также должны быть стандартными и логически обоснованными.
Потребности конечного пользователя
При проектировании базы данных потребностям конечного пользователя должно быть уделено самое пристальное внимание. Не забывайте, что в конце концов база данных предназначена именно для него. Вы обязаны обеспечить конечному пользователю максимальные удобства при использовании им внешнего интерфейса (программы, которая предоставляет пользователю до-ступ к базе данных), однако всего этого, также как и оптимальной производительности системы, вряд ли можно добиться без учета его потребностей. Далее мы приводим некоторые соображения, которые обязательно следу-ет принимать во внимание при проектировании базы данных. Итак, вы четко должны представлять себе следующее:
Какая информация должна храниться в базе данных?
Каким образом пользователь будет обращаться к базе данных?
Какие привилегии требуются для того или иного пользователя?
Каким образом информация должна быть организована в базе данных?
К каким данным происходит наиболее частое обращение?
Каким образом данные связаны между собой?
Какие меры следует предпринять, чтобы обеспечить достоверность хранимой информации?
Избыточность данных
Данные не должны быть избыточными; существует несколько причин, почему дублирование данных следует стремиться свести к минимуму. Например, нет необходимости хранить домашний адрес сотрудника компании более, чем в одной таблице, поскольку при этом непроизводительно расходуется дисковое пространство. Кроме того, может возникнуть невообразимая путаница, когда, например, адрес сотрудника в одной таблице не соответствует его же адресу в другой. Какая информация достоверна? Есть ли у вас соответствующие документы для проверки действительного адреса этого сотрудника? Как ни сложно управление информацией само по себе, избыточность данных в этом случае может оказаться настоящим бедствием.
Заключение
Создание корпоративных БД в условиях Нового Системного Проектирования - деятельность, использующая многие методы классического проектирования, но требующая иной организации и многих дополнительных методов, а также новых, которые заменили бы некоторые из тех, что были разработаны 10 и более лет назад.
Дисциплина проектирования БД в новых условиях еще отсутствует. Тем не менее, ее начала видны, ее элементы работают в реальных проектах.
В соответствии с принципом сохранения иммунитета к компьютерным классические методы проектирования БД должны продолжать использоваться, но только в тех в областях, где они действительно полезны. Методы проектирования, рассматриваемые в конкретных проектах корпоративных ИС и БД, и соответствующие инструменты должны проверяться на свои возможности обеспечивать функции в соответствии с требованиями Нового Системного Проектирования