
- •Тема: Базы данных, Банки Данных, Системы Управления Базами Данных — субд
- •Оглавление
- •1. Проектирование баз данных. Введение.
- •1.1. История развития баз данных
- •1.2. Файлы и файловые системы
- •1.3. Первый этап — базы данных на больших эвм
- •1.4. Второй этап - эпоха персональных компьютеров
- •1.5. Третий этап - распределенные базы данных
- •1.6. Четвертый этап - Интранет
- •2. Базы данных, Банки Данных, субд
- •2.1. Основные понятия и определения
- •4. Защита информации в бд и защита бд.
- •2.2. Языковые средства субд
- •2.3. Пользователи банков данных
- •2.4. Основные функции группы администратора бд
- •2.5. Архитектура базы данных
- •2.6. Классификация банков данных
- •2.7. Понятие категорий «данные» и «модель данных».
- •3. Проектирование баз данных
- •3.1.Этапы проектирования баз данных
- •3.2. Составные части инфологической модели
- •3.3. Требования и подходы к инфологическому проектированию
- •3.4. Элементы модели «сущность-связь»
- •3.5. Создание инфологической модели базы данных
- •4. Системы Управления Базами Данных
- •4.1. Основные функции субд
- •4.2. Основные средства субд
- •4.3. Субд в многопользовательских системах
- •4.4. Основные свойства субд и базы данных
- •4.5. Технология использования субд
- •4.5.1. Установка субд.
- •4.5.2. Процесс поэтапного внедрения.
- •4.5.3. Разработка структуры базы данных.
- •4.5.4. Создание базы данных средствами субд.
- •4.5.5 Обработка данных средствами субд.
- •4.6. Обзор субд
- •5. Microsoft Access Введение
- •5.1. Еще раз о реляционной модели данных.
- •5.2. Основные этапы разработки бд
- •5.3. Стратегия разработки бд
- •5.4. Данные и информация
- •5.5. Отбор необходимых данных
- •5.6. Нормализация
- •5.7. Чужие ключи
- •5.8. Архитектура Microsoft Access
- •5.9. Создание базы данных
- •Список использованных источников
3.5. Создание инфологической модели базы данных
Разработка информационно-логической модели реляционной БД начинается с рассмотрения необходимых для её создания информационных объектов.
Если, например, представить связь между объектами "Студенты" и "Дисциплины", то вполне очевидно, что студент изучает несколько дисциплин (связь «один» обозначается одинарной стрелкой, а многозначная связь отражается двойной стрелкой). Каждая дисциплина изучается множеством студентов – это тоже многозначная связь. Следовательно, связь между объектами "Студенты" и "Дисциплины" является отношением «Многие-ко-многим» (М : М или M:N).
Множественные связи усложняют управление базой данных, поэтому их использование нежелательно.
Например в Access с этой целью создают вспомогательный объект связи, состоящий из ключевых реквизитов связываемых объектов, который может быть дополнен описательными реквизитами. В данном случае таким новым объектом для связи может быть объект «Оценки».
Его реквизиты: код студента, код дисциплины и оценки. Каждый студент имеет оценки по нескольким дисциплинам. При этом связь между объектами «Студенты» и «Оценки» будет «Один-ко-многим» (1 : М). Каждую дисциплину сдаёт множество студентов, поэтому связь между объектами «Дисциплины» и «Оценки» тоже «Один-ко-многим» (1 : М). В результате получается следующая информационно-логическая модель базы данных.
Рис.12. Информационно-логическая модель базы данных.
После определения структуры БД: объектов (таблиц), состава их полей (структуры таблиц) и связей между таблицами приступают к непосредственному формированию структуры таблиц и определяют ключевые поля в них.
Ключевое поле – это одно или несколько полей, комбинация значений которых однозначно определяет каждую запись в таблице; это уникальный идентификатор записей, используемый для поиска записей и объединения таблиц. При ссылке на ключевое поле из другой таблицы оно называется полем внешнего ключа. В качестве примера приведём характеристики полей таблиц «Студенты» и «Преподаватели».
Таблица 1"Студенты"
Таблица 2"Преподаватели"
Практически любая реляционная БД создаётся из нескольких таблиц, на основе которых формируются формы и запросы. Таблицы между собой связываются посредством общих полей, т.е. полей, одинаковых по форматам и, как правило, по названию, имеющихся в обеих таблицах. Такая организация данных позволяет уменьшить избыточность хранимых данных, упрощает их ввод и организацию запросов и отчётов. Каждая таблица включает в свой состав поле кода, используемого обычно как счётчик (идентификатор) главного её параметра и, как правило, являющегося ключевым полем.
Записи таблицы всегда располагаются в файле БД в том порядке, в котором они были включены в таблицу. Для удобства просмотра записей их можно сортировать в таблице в определённой последовательности, например, в порядке убывания или возрастания какого-либо характеризующего поле (столбец) параметра. Сортировку можно произвести по нескольким полям одновременно. Функция сортировки относится к процессу фильтрации данных. Таблица «Студены», созданная средствами СУБД Access представлена в таблице 3.
Таблица 3 «Студенты»