- •Министерство образования и науки рф Федеральное государственное бюджетное образовательное учреждение высшего профессионального образования
- •Введение в базы данных
- •Учебное пособие
- •Воронеж 2012
- •Понятие информационной системы
- •Процессы в информационной системе
- •Этапы развития информационных систем
- •Структура информационной системы. Типы обеспечивающих подсистем
- •Математическое и программное обеспечение
- •Правовое обеспечение
- •Классификация информационных систем по признаку структурированности задач
- •Понятие структурированности задач
- •Типы информационных систем, используемые
- •Классификация ис по характеру использования информации
- •Классификация ис по сфере применения
- •Классификация ис по степени автоматизации
- •Контрольные вопросы
- •2. Введение в субд
- •2.1. Понятие базы и банка данных
- •2.2. Средства реализации баз данных
- •2.2.1. Программные средства банка данных
- •2.2.2. Языковые средства
- •2.2.3. Технические и организационно-методические средства
- •2.2.4. Требования к банкам данных
- •2.3. Функции субд
- •2.4. Классификация банков данных
- •2.4.1. Классификация баз данных
- •2.4.2. Классификация субд
- •2.4.3. Классификация БнД по экономико-организационным признакам
- •2.5. Концепция централизованного управления
- •Преимущества централизованного управления данными
- •2.6. Трехуровневая архитектура системы баз данных
- •2.7. Пользователи банков данных
- •2.8. Архитектура клиент/сервер
- •Контрольные вопросы
- •3. Модели и типы данных
- •3.1. Иерархическая модель
- •3.2. Сетевая модель
- •3.3. Реляционная модель
- •3.4. Постреляционная модель
- •3.5. Многомерная модель
- •3.6. Типы данных
- •Контрольные вопросы
- •4. Применение Баз данных в корпоративных информационных системах
- •4.1. Корпоративная информационная система
- •Контуром оперативного управления
- •4.2. Контур административного управления
- •4.2.1. Наполнение баз данных на примере модуля «Управление персоналом»
- •4.3. Контур оперативного управления
- •4.3.1. Пример организации модуля «Управление продажами (сбыт)»
- •Базы данных модуля «Автотранспорт»
- •4.4. Контур бухгалтерского учета
- •Контрольные вопросы
- •5. Справочно-правовые базы данных
- •5.1. Общая характеристика справочно-правовых баз
- •5.2. Наиболее популярные юридические базы данных
- •5.2.1. База юсис
- •5.2.2. Информационно-поисковая система "Кодекс"
- •5.2.3. Справочно-правовая система "Гарант"
- •5.2.4. Справочно-правовая система «Консультант Плюс»
- •5.2.5. Программный комплекс "Эталон"
- •Контрольные вопросы
- •6. Проектирование баз данных
- •6.1. Этапы проектирования
- •6.2. Инфологическое моделирование
- •6.2.1. Компоненты инфологической модели Модель «сущность — связь»
- •6.2.2. Классификация бинарных связей
- •6.2.3. Моделирование локальных представлений
- •6.2.4. Объединение моделей локальных представлений
- •6.3. Даталогическое проектирование
- •6.4. Проектирование реляционных баз данных
- •6.5. Нормализация отношений
- •Контрольные вопросы
- •7. Реляционная модель данных
- •Общие понятия
- •7.2. Реляционные объекты данных
- •7.2.1. Основные понятия
- •7.2.2. Фундаментальные свойства отношений
- •7.2.3. Виды отношений
- •Целостность реляционных данных
- •Реляционные операторы
- •7.4.1. Реляционная алгебра
- •Примеры использования реляционной алгебры для выражения словесных запросов в виде формулы
- •Назначение реляционной алгебры
- •Операции расширения и подведения итогов
- •Операторы обновления
- •7.4.2. Реляционное исчисление
- •Контрольные вопросы
- •8. Язык реляционных баз данных sql
- •8.1. Функции и основные возможности
- •8.2. Средства определения схемы
- •8.2.1. Определение таблицы
- •8.2.2. Определение ограничений целостности таблицы
- •8.2.3. Определение представлений
- •8.3. Структура запросов
- •8.3.1. Спецификация курсора
- •8.3.2. Оператор выборки
- •8.3.3. Подзапрос
- •8.3.4 Табличное выражение
- •Раздел where
- •Предикат сравнения
- •Предикат between
- •Предикат in
- •Предикат null
- •Предикат с квантором
- •Предикат exists
- •Раздел group by
- •Раздел having
- •8.4. Агрегатные функции и результаты запросов
- •8.5. Операторы обновления
- •Оператор изменения записей
- •Контрольные вопросы
- •9. Внутренняя организация реляционных субд
- •9.1. Хранение отношений
- •9.2. Индексы
- •9.3. Журнальная информация
- •9.4. Служебная информация
- •Контрольные вопросы
- •10. Настольные субд
- •10.1. Общие сведения о настольных субд
- •10.2. Наиболее популярные настольные субд
- •Контрольные вопросы
- •11. Серверные субд
- •11.1. Характерные черты современных серверных субд
- •Наиболее популярные серверные субд
- •Контрольные вопросы
- •Заключение
- •Корелина Татьяна Валерьевна введение в базы данных
- •394006 Воронеж, ул. 20-летия Октября, 84
6.2.3. Моделирование локальных представлений
Моделирование локальных проектных представлений завершается построением модели локального представления. Для удобства проектирования в отдельном локальном представлении желательно использовать шесть-семь типов сущностей. Чаще всего локальное представление соответствует отдельному внешнему приложению, например отдельной функциональной задаче либо отдельному пользователю.
Для каждого локального представления необходимо сформулировать сущности, требуемые для его описания, т. е. указать типы объектов предметной области, о которых в системе должна накапливаться информация.
В отдельных случаях это сделать сложно, так как некоторая порция информации может быть представлена любым из типов конструктивных элементов: сущность, атрибут или связь. В этих случаях рекомендуется проработать несколько вариантов моделей локального представления и отобрать более гибкий с точки зрения представления информации, т. е. позволяющий представлять не только всю порцию некоторой информации, но и ее отдельные фрагменты.
Пример. Пусть в некотором локальном представлении выполняется описание поставок товаров на склад. Предполагается, что в одной поставке может участвовать только один поставщик, поставляя только один вид товара. При этом поставщик может участвовать в нескольких поставках [29].
Для описания воспользуемся только двумя основными конструкциями - сущность и атрибут. Графическая диаграмма локального представления показана на рис. 6.2.
Такая модель обладает определенными недостатками. С ее помощью нельзя представить порцию информации об отдельном поставщике, который не выполняет поставок в настоящее время. Для этого необходимо ввести в модель сущность ПОСТАВЩИК, назначить ей соответствующие атрибуты, связать с сущностью ПОСТАВКА, если это необходимо, и удалить избыточные элементы (рис. 6.3).
При таком представлении всегда можно определить, какой конкретно поставщик выполнил поставку, используя для этих целей связь ПОСТАВЛЯЕТ между сущностями ПОСТАВЩИК и ПОСТАВКА, т.е. в информационном плане данная модель сохраняет все возможности предыдущей. При этом она более богата с точки зрения информационного представления, так как дает информацию и об отдельных поставщиках независимо от того, выполняли они поставку товаров или нет.
Однако полученный вариант не представляет информацию об отдельных товарах, если они отсутствуют в поставках. Чтобы такие порции информации можно было представлять, необходимо ввести в модель сущность ТОВАР и выполнить аналогичные процедуры построения, как и для сущности ПОСТАВЩИК (рис. 6.4).
Рис. 6.3. Графическая диаграмма с введением в модель сущности ПОСТАВЩИК
Рис. 6.4. Графическая диаграмма с введением в модель сущности ТОВАР
Полученный вариант не позволяет представить информацию «какие товары может поставлять отдельный поставщик» и «какие поставщики могут поставлять данный товар». Для реализации в модели подобной информации необходимо организовать соответствующие связи между сущностями ПОСТАВЩИК и ТОВАР (рис. 6.5).
МОЖЕТ ПОСТАВЛЯТЬ и МОЖЕТ БЫТЬ ПОСТАВЛЕН
Для локального представления, рассмотренного в примере, выбираем заключительный вариант модели, поскольку он более гибкий для представления информации: позволяет представлять информацию о поставках и ее отдельных фрагментах, поставщиках, товарах, возможностях поставщиков, распределении поставщиков по видам товаров. Следовательно, база данных, реализующая это представление, окажется более гибкой в обработке данных и будет обладать большими возможностями по обработке произвольных запросов. Следовательно, для данного локального представления целесообразно сформулировать такие сущности, как ПОСТАВКА, ПОСТАВЩИК, TOBАР.
Каждой выбранной сущности должно быть присвоено четкое наименование, отражающее смысловое содержание вводимого понятия. Общее количество сформулированных сущностей в отдельном локальном представлении должно быть ограниченным.
Для каждой сущности необходимо указать идентификатор, служащий для однозначного распознавания экземпляров сущности. В качестве идентификатора служит один атрибут или совокупность из нескольких атрибутов, в этом случае идентифицирующий атрибут является составным атрибутом, набор значений которого уникален, т. е. значения идентифицирующего атрибута находятся во взаимно однозначном соответствии с экземплярами сущности.
Одним из этапов моделирования локальных представлений является спецификация связей. Выявляются все зависимости между сущностями и атрибутами и определяется, какие связи необходимые, а какие избыточные. В зависимостях «атрибут-атрибут» целесообразно стремиться к случаю, когда наблюдаются только зависимости описательных атрибутов от идентифицирующего, других зависимостей нет.
Моделирование локального представления заканчивается графическим оформлением всех выявленных сущностей, связей между ними и атрибутов и составлением всех перечисленных выше спецификаций.