- •Введение
- •1Базы данных
- •1.1Модели данных
- •1.1.1Иерархическая модель данных
- •1.1.2Сетевая модель данных
- •1.1.3Реляционная модель данных
- •Вопросы для самоконтроля
- •1.2Функции систем управления базами данных
- •1.3Настольные и клиент-серверные субд
- •1.3.1Настольные субд
- •1.3.2Клиент-серверные субд
- •Вопросы для самоконтроля:
- •Вопросы для самоконтроля:
- •1.4Этапы разработки базы данных
- •Вопросы для самоконтроля:
- •1.5Особенности архитектуры информационных систем. Одно – двух – и трехуровневые системы
- •1.5.1Централизованная архитектура
- •1.5.2Архитектура «файл-сервер»
- •1.5.3Архитектура «клиент – сервер»
- •1.5.4Трехзвенная (многозвенная) архитектура «клиент – сервер»
- •Вопросы для самоконтроля:
- •1.6Типы данных в различных субд
- •Вопросы для самоконтроля:
- •1.7Разработка структуры базы данных
- •Вопросы для самоконтроля:
- •1.8Построение выражений в Access
- •Вопросы для самоконтроля:
- •1.9Создание запросов
- •Вопросы для самоконтроля:
- •Тест № 1
- •Клиент-серверные субд;
- •2Интегрированные информационные системы (erp)
- •2.1Задачи и преимущества erp
- •Вопросы для самоконтроля:
- •2.2Локальные информационные системы (mprii, scm, mes, wms, crm)
- •Вопросы для самоконтроля:
- •2.3Сравнение erp и mrp II
- •Вопросы для самоконтроля:
- •Тест № 2
- •3Защита информации
- •3.1Правовая защита информации
- •Вопросы для самоконтроля:
- •3.2Организационная защита информации
- •Вопросы для самоконтроля:
- •3.3Инженерно-техническая защита информации
- •Вопросы для самоконтроля:
- •3.4Защита информации от несанкционированного доступа
- •Вопросы для самоконтроля:
- •3.5Шифрование информации
- •Вопросы для самоконтроля:
- •3.6Защита информации от повреждений
- •3.6.1Антивирусные программы
- •3.6.2Резервирование информации
- •3.6.3Технические мероприятия
- •3.6.4Административные меры
- •Вопросы для самоконтроля:
- •Тест № 3
- •Заключение
- •Библиографический список
- •Список сокращений и условных обозначений
- •Глоссарий
1.1.2Сетевая модель данных
Дублирования можно было бы избежать, если разрешить связи между различными ветвями (горизонтальные). Но это уже будет не иерархическая, а сетевая модель данных. Пример сетевой модели для той же задачи приведен ниже.
Рис. 3. Сетевая модель данных
В сетевой модели к элементу данных может быть более одного пути. Наряду с вертикальными, могут использоваться и горизонтальные связи между элементами данных.
Однако, для реальных систем сетевые модели получаются очень громоздкими и сложными как в разработке, так и при эксплуатации базы данных. В результате на сегодняшний день они в технологии баз данных используются крайне редко.
1.1.3Реляционная модель данных
Самой популярной моделью данных в настоящее время является реляционная модель.
База данных в реляционной модели – это совокупность взаимосвязанных таблиц с информацией.
В каждой таблице хранятся данные об объектах определенного вида.
Например, в базе, хранящей кадровую информацию, в одной таблице записываются данные сотрудников (Табельный номер, ФИО, пол, дата рождения, адрес и т.п.), в другой – информация о продвижении сотрудника по службе (Табельный номер, дата, должность и т.п.), в третьей – поощрения и наказания сотрудников и т.д.
Каждая строка таблицы хранит данные о каком-либо одном объекте и называется записью. Например, в таблице Сотрудники в каждой строке будут записаны сведения о каком-то одном сотруднике.
Столбцы таблиц – это какие-то характеристики объектов. Они называются полями. Каждое поле имеет строго определенный тип и размер в байтах.
В каждой таблице указывается ключ – это поле или совокупность нескольких полей таблицы, однозначно определяющих запись. То есть в таблице не может быть двух записей с одинаковым значением ключа.
Ключи используются для:
предотвращения дублирования записей,
для связывания таблиц
для быстрого поиска нужной записи по её ключу.
При назначении ключа следует учитывать следующее:
ключевое поле никогда не может быть пустым
в составе ключа используется минимально возможный набор полей
из двух возможных ключей выбирают обычно более короткий
введенные значения ключевых полей в таблице по возможности должны как можно реже изменяться
Выбор того или иного поля в качестве ключевого зависит от назначения данных.
Например, в таблице имеются следующие поля:
ФИО |
пол |
телефон |
номер паспорта |
номер зачетки |
номер читательского билета |
адрес |
Если это сведения о студентах ВУЗа, то целесообразно в качестве ключевого выбрать поле номер зачетки, так как зачетка есть у каждого студента, номера зачеток гарантированно разные и в течение срока обучения номер зачетки обычно не изменяется. Паспорт же студент за время обучения может поменять, а читательского билета у него может и не быть.
Если же это сведения о читателях городской библиотеки, то ключевым лучше сделать номер читательского билета.
Иногда для правильного назначения ключа нужно знать некоторые особенности заполнения таблиц.
Например, имеется таблица, в которой должны храниться сведения о сдаче студентами экзаменов за всё время обучения.
Таблица 1. Экзамены
номер зачетки |
дата сдачи |
предмет |
оценка |
экзаменатор |
123456 |
02.06.11 |
история |
5 |
Иванов |
123456 |
04.06.11 |
химия |
5 |
Петров |
123456 |
09.06.11 |
физика |
4 |
Семенов |
123456 |
15.06.11 |
математика |
4 |
Васильев |
123458 |
02.06.11 |
история |
5 |
Иванов |
123458 |
04.06.11 |
химия |
3 |
Петров |
123458 |
09.06.11 |
физика |
3 |
Семенов |
123458 |
15.06.11 |
математика |
3 |
Васильев |
… |
… |
… |
… |
… |
Ни одно поле в такой таблице не может выполнять роль самостоятельного ключа, потому что так или иначе данные в каждом столбце могут повторяться. В таком случае назначается составной ключ – несколько полей, данные которых взятые вместе гарантированно не должны повторяться.
Если в учебном заведении действует железное правило, что в течение дня студент ни при каких обстоятельствах не может сдать более одного экзамена, то ключом можно назначить номер зачетки +дата сдачи. Если хотя бы иногда это правило может нарушаться, то такой ключ не годится, так как некоторые записи (с указанным нарушением) будет просто невозможно ввести в таблицу.
Если названия предметов, которые сдает студент за всё время обучения, никогда не повторяются, то ключом может быть номер зачетки + предмет. При этом названия одних и тех же предметов, сдаваемых в разных семестрах, обязательно должны отличаться, например, математика-1, математика-2 и т.п.
Если ни одно из вышеназванных правил не выполняется, то ключом можно сделать номер зачетки +дата сдачи + предмет. Это будет означать, что в течение одного дня один и тот же студент по указанному предмету может получить только одну оценку.
Таким образом, при назначении ключей в таблицах нужно прогнозировать процесс заполнения таблиц данными.
Помимо ключей в таблицах могут назначаться индексы.
Индекс – это средство быстрого поиска данных в таблицах с большим количеством записей. При необходимости индексов в таблице может быть несколько. Как и ключи, индексы могут включать в себя одно поле или несколько полей одновременно. Фактически индекс хранит порядок следования записей таблицы, как если бы она была отсортирована по полям индекса.
При вводе или изменении данных в таблице индексы тоже обновляются (перестраиваются), на что требуется некоторое время. Как следствие, в больших таблицах со множеством индексов ввод новых данных может слегка "притормаживать". Зато поиск данных по индексным полям будет почти мгновенным.
