Составители:
Рубрика:
4
реального мира, информацию об этих явлениях, представление этой
информации посредством данных.
Описание информационных потребностей, которые должна обслуживать
разрабатываемая информационная система, позволяет определить объекты
хранения, уточнить структуру данных, содержательное наполнение базы. Как
правило, хорошо описанные информационные потребности позволяют
создать эффективные средства обслуживания запросов пользователя.
Создание концептуальной схемы базы данных позволяет облегчить
решение дополнительных задач, которые возникают на этапе эксплуатации
базы данных – разделение доступа и администрирование, поддержание
целостности и непротиворечивости, развитие и модификацию базы данных.
Рассмотрим эти этапы проектирования более подробно на примере
создания «Электронного телефонного справочника»
1.2. Описание предметной области
Зададимся вопросом, для кого предназначена разрабатываемая
информационная система – для частного лица, для
компании,
специализирующейся на рекламе, для телефонной компании, для налоговой
инспекции…. Список тех, кому может понадобиться такая система можно
продолжить, однако для нас имеет смысл определиться. Будем разрабатывать
телефонный справочник для частного лица – некоторый аналог записной
книжки.
Какая информация должна храниться в базе? Вот первый пришедший в
голову список.
• Обязательно
телефонные номера
• Обязательно владельцы
• Адреса, связанные с владельцем телефонного номера.
Данная информация похожа на содержание обычной телефонной книжки,
что, впрочем, неудивительно. Так, или примерно так, нам представляется та
часть реального мира, которую мы хотим описать и хранить о ней
информацию.
Уточним содержание хранимой информации.
Телефонные номера – храним ли мы
коды городов, фиксируем ли мы
стационарный это телефон или мобильный, какой оператор поддерживает
данный номер, какой тариф на этом номере, нужно ли вводить добавочную
информацию, спаренный это телефон, подключен через мини АТС?
Владелец – частное лицо или организация, чем занимается и т.д.
Адрес – страна, город, улица, дом, квартира или офис,
всякие дроби,
корпуса, литеры, строения, подъезды, звонки, ближайшая станция метро и тд.
5
Приведенный список показывает, что усложнять данную задачу можно до
бесконечности.
1.2. Описание информационных запросов
Обратимся теперь к информационным потребностям. Что же мы хотим от
нашей системы? Попробуем сформулировать возможный набор
содержательных запросов, которые должна обслуживать наша
информационная система.
• Какой (или какие) телефоны связаны с конкретным лицом или
организацией?
• С
каким адресом связан данный номер телефона?
• Какие еще телефоны есть у владельца данного номера?
• Какие телефонные номера связаны с конкретным адресом?
• Какие телефонные номера не связаны с адресом или владельцем (это
для администратора)?
• Какие номера телефонов или владельцы телефонов ассоциируются с
конкретной сферой деятельности?
Сформулированные запросы
дают нам представление о том, как должна быть
организована информация.
1.3. Описание объектов хранения
Название организации и имя владельца должны храниться в базе и по ним
должен осуществляться поиск. С организацией может быть связано несколько
телефонов, владельцев, адресов и т.д. То же относится и к владельцам
телефонов. Такая ситуация подводит
нас к решению о том, что Владелец
телефона, Организация должны быть отдельными объектами хранения. По
некоторым соображениям Адрес и Телефонный номер должны быть
отдельными объектами хранения. Таким образом, в нашей базе выделяются
четыре объекта
Какие свойства объектов, или другими словами, атрибуты должны
храниться? Как могут или должны
представляться и обрабатываться
Владелец
телефона
Телефонный
номер
Организация
Адрес
