Фактографические и документированные информационные системы
Тип информационной системы зависит от того, чьи интересы она обслуживает и на каком уровне управления. По характеру представления и логической организации хранимой информации информационные системы подразделяются на фактографические, документальные и геоинформационные.
Фактографические информационные системы накапливают и хранят данные в виде множества экземпляров одного или нескольких типов структурных элементов (информационных объектов). Каждый из таких экземпляров или некоторая их совокупность отражают сведения по какому-либо факту, событию отдельно от всех прочих сведений и фактов.
Структура каждого типа информационного объекта состоит из конечного набора реквизитов, отражающих основные аспекты и характеристики объектов данной предметной области. Комплектование информационной базы в фактографических информационных системах включает, как правило, обязательный процесс структуризации входной информации.
Фактографические информационные системы предполагают удовлетворение информационных потребностей непосредственно, т.е. путем представления потребителям самих сведений (данных, фактов, концепций).
Вдокументальных (документированных)информационных системах единичным элементом информации является нерасчлененный на более мелкие элементы документ и информация при вводе (входной документ), как правило, не структурируется, или структурируется в ограниченном виде. Для вводимого документа могут устанавливаться некоторые формализованные позиции (дата изготовления, исполнитель, тематика).
Некоторые виды документальных информационных систем обеспечивают установление логической взаимосвязи вводимых документов – соподчиненность по смысловому содержанию, взаимные отсылки по каким-либо критериям и т.д.
Определение и установление такой взаимосвязи представляет собой сложную многокритериальную и многоаспектную аналитическую задачу, которая не может быть формализована в полной мере.
В геоинформационных системах данные организованы в виде отдельных информационных объектов (с определенным набором реквизитов), привязанных к общей электронной топографической основе (электронной карте). Геоинформационные системы применяются для информационного обеспечения в тех предметных областях, структура информационных объектов и процессов в которых имеет пространственно-географический компонент (маршруты транспорта, коммунальное хозяйство).
4. Чем отличается инфологическая схема предметной области информационной системы от схемы ее базы данных?
Инфологическая схема описывает предметную область без зависимости от конкретной СУБД, вида базы данных и физического её устройства.
инфологическая модель должна включать такое формализованное описание предметной области, которое будет «читабельно» не только для специалистов по базам данных, но и сторонних людей. И это описание должно быть настолько емким, чтобы можно было оценить глубину и корректность проработки проекта БД, и конечно, как говорилось раньше, оно не должно быть привязано к конкретной СУБД. Выбор СУБД — это отдельная задача, для корректного ее решения необходимо иметь проект, который не привязан ни к какой конкретной СУБД.
5. Перечислить основные функции, реализуемые СУБД, и охарактеризовать их с точки зрения системного или прикладного характера решаемых задач.
Основные функции СУБД:
· управление данными во внешней памяти (на дисках);
· управление данными в оперативной памяти с использованием дискового кэша;
· журнализация изменений, резервное копирование и восстановление базы данных после сбоев;
· поддержка языков БД (язык определения данных, язык манипулирования данными).
6. Перечислить основные понятия структурной составляющей реляционной модели данных.
Реляционная модельданных (РМД) некоторой предметной
области представляет собой набор отношений, изменяющихся во времени.
Отношениепредставляет собой двумерную таблицу, содержащую
некоторые данные.
В шапке таблицы записана схема отношения.
В строках записаны кортежи отношения.
1. Все строки таблицы должны быть различными, т.е. не может быть двух
Имена столбцов данной таблицы соответствуют именам атрибутов.
строк с одинаковыми значениями.
2. Имена столбцов таблицы должны быть различными.
3. В каждой ячейке таблицы должно быть записано только одно
значение из домена, соответствующего столбцу.
4. Все строки одной таблицы должны иметь одинаковую структуру,
соответствующую шапке таблицы.
5. Порядок размещения строк в таблице может быть произвольным
Сущностьесть объект любой природы, данные о котором хранятся в
базе данных. Данные о сущности хранятся в отношении.
Сущность определена как «нечто», о чем необходимо записывать информацию "
Сущности имеют некоторые свойства(properties)
Доменпредставляет собой множество всех возможных значений определенного атрибута отношения
Атрибутыпредставляют собой свойства, характеризующие сущность.
В структуре таблицы каждый атрибут именуется и ему соответствует заголовок некоторого столбца таблицы
7. Сформулировать, в чем заключается и каким образом обеспечивается целостность в реляционной модели данных.
Кодд предложил два декларативных механизма поддержки целостности реляционных баз данных, которые затверждены в реляционной модели данных и должны поддерживаться в любой реализующей ее СУБД: ограничение целостности сущности, или ограничение первичного ключа и ограничение ссылочной целостности, или ограничение внешнего ключа. Мы снова оставим подробности и формализмы на лекцию 3 и приведем здесь только изложение общих идей.
Ограничение целостности сущности звучит следующим образом: для заголовка любого отношения базы данных должен быть явно или неявно определен первичный ключ, являющийся таким минимальным подмножеством заголовка отношения, что в любом теле этого отношения, которое может появиться в базе данных, значение первичного ключа в любом кортеже этого тела является уникальным, т.е. отличается от значения первичного ключа в любом другом кортеже. Под минимальностью первичного ключа понимается то, что если из множества атрибутов первичного ключа удалить хотя бы один атрибут, то ограничение целостности изменится, т.е. в БД смогут появляться тела отношений, которые не допускались исходным первичным ключом.
Если первичный ключ не объявляется явно, то в качестве первичного ключа отношения принимается весь его заголовок. Понятно, что поскольку по определению любое тело отношения с заданным заголовком является множеством, следовательно, в нем отсутствуют дубликаты, и первичный ключ, совпадающий с заголовком отношения, всегда обладает свойством уникальности. Должно быть понятно, что в этом случае определение первичного ключа не задает никакого ограничения целостности.
Чтобы пояснить смысл ограничения ссылочной целостности, нужно сначала ввести понятие внешнего ключа.
внешним ключом отношения R1, ссылающимся на отношение R2, называется подмножество заголовка HR1, которое совпадает с первичным ключом отношения R2 (с точностью до имен атрибутов). Тогда ограничение ссылочной целостности реляционной модели данных можно сформулировать следующим образом: в любом теле отношения R1, которое может появиться в базе данных, для «не пустого» значения внешнего ключа, ссылающегося на отношение R2, в любом кортеже этого тела должен найтись кортеж в теле отношения R2, которое содержится в базе данных, с совпадающим значением первичного ключа.
8. В чем заключается концептуальное проектирование?
Концептуальное проектирование - сбор, анализ и редактирование требований к данным. Для этого осуществляются следующие мероприятия:
a. обследование предметной области, изучение ее информационной структуры
b. выявление всех фрагментов, каждый из которых харакетризуется пользовательским представлением, информационными объектами и связями между ними, процессами над информационными объектами
c. моделирование и интеграция всех представлений
По окончании данного этапа получаем концептуальную модель, инвариантную к структуре базы данных. Часто она представляется в виде модели "сущность-связь".
9. Этапы проектирование схемы реляционной базы данных?
- Концептуальное проектирование - сбор, анализ и редактирование требований к данным. Для этого осуществляются следующие мероприятия:
- обследование предметной области, изучение ее информационной структуры
- выявление всех фрагментов, каждый из которых харакетризуется пользовательским представлением, информационными объектами и связями между ними, процессами над информационными объектами
- моделирование и интеграция всех представлений
По окончании данного этапа получаем концептуальную модель, инвариантную к структуре базы данных. Часто она представляется в виде модели "сущность-связь".
- Логическое проектирование - преобразование требований к данным в структуры данных. На выходе получаем СУБД-ориентированную структуру базы данных и спецификации прикладных программ. На этом этапе часто моделируют базы данных применительно к различным СУБД и проводят сравнительный анализ моделей.
- Физическое проектирование - определение особенностей хранения данных, методов доступа и т.д.
10. Нормализация таблиц. Декомпозиция схемы базы данных в третьей нормальной форме.
Первая нормальная форма
Отношение находится в 1НФ, если все его атрибуты являются простыми, все используемые домены должны содержать только скалярные значения. Не должно быть повторений строк в таблице.
Например, есть таблица «Автомобили»:
| Фирма | Модели |
| BMW | M5, X5M, M1 |
| Nissan | GT-R |
Нарушение нормализации 1НФ происходит в моделях BMW, т.к. в одной ячейке содержится список из 3 элементов: M5, X5M, M1, т.е. он не является атомарным. Преобразуем таблицу к 1НФ:
| Фирма | Модели |
| BMW | M5 |
| BMW | X5M |
| BMW | M1 |
| Nissan | GT-R |
Вторая нормальная форма
Отношение находится во 2НФ, если оно находится в 1НФ и каждый не ключевой атрибут неприводимо зависит от Первичного Ключа(ПК).
Неприводимость означает, что в составе потенциального ключа отсутствует меньшее подмножество атрибутов, от которого можно также вывести данную функциональную зависимость.
Например, дана таблица:
| Модель | Фирма | Цена | Скидка |
| M5 | BMW | 5% | |
| X5M | BMW | 5% | |
| M1 | BMW | 5% | |
| GT-R | Nissan | 10% |
Таблица находится в первой нормальной форме, но не во второй. Цену машины зависит от модели и фирмы. Скидка зависят от фирмы, то есть зависимость от первичного ключа неполная. Исправляется это путем декомпозиции на два отношения, в которых не ключевые атрибуты зависят от ПК.
| Модель | Фирма | Цена |
| M5 | BMW | |
| X5M | BMW | |
| M1 | BMW | |
| GT-R | Nissan |
| Фирма | Скидка |
| BMW | 5% |
| Nissan | 10% |
Третья нормальная форма
Отношение находится в 3НФ, когда находится во 2НФ и каждый не ключевой атрибут нетранзитивно зависит от первичного ключа. Проще говоря, второе правило требует выносить все не ключевые поля, содержимое которых может относиться к нескольким записям таблицы в отдельные таблицы.
Рассмотрим таблицу:
| Модель | Магазин | Телефон |
| BMW | Риал-авто | 87-33-98 |
| Audi | Риал-авто | 87-33-98 |
| Nissan | Некст-Авто | 94-54-12 |
Таблица находится во 2НФ, но не в 3НФ.
В отношении атрибут «Модель» является первичным ключом. Личных телефонов у автомобилей нет, и телефон зависит исключительно от магазина.
Таким образом, в отношении существуют следующие функциональные зависимости: Модель → Магазин, Магазин → Телефон, Модель → Телефон.
Зависимость Модель → Телефон является транзитивной, следовательно, отношение не находится в 3НФ.
В результате разделения исходного отношения получаются два отношения, находящиеся в 3НФ:
Риал-авто 87-33-98
Риал-авто 87-33-98
Некст-Авто 94-54-12
| Модель | Магазин |
| BMW | Риал-авто |
| Audi | Риал-авто |
| Nissan | Некст-Авто |