первом этапе проектирования БД определил цель создания БД, ее функции и примерный перечень информации.
Целью создания БД «Банковские вклады» являются операции по вкладам.
Этап 2. Выделение информационных объектов предметной области.
На втором этапе проектирования БД составил описание предметной области в виде реквизитов, извлекаемых из первичных документов – источников загрузки БД.
Этап 3. Определение логической структуры БД.
Реальные отношения между информационными объектами являются отношениями «многие-ко-многим», которые непосредственно не поддерживаются реляционными СУБД. Поэтому их следует трансформировать в отношения «один-ко-многим» путем ввода объекта-связки Операции.
Для установления связей каждому объекту назначается ключ (ключевое поле). При этом первичные ключи объектов Вклады и Вкладчики должны присутствовать как внешние ключи в объекте Операции.
В соответствии с понятиями реляционной СУБД каждому информационному объекту в проектируемой БД будет соответствовать отдельная таблица (Вкладчики,Вклады,Операции).
Связь между таблицами устанавливается с помощью ключей Номер счета в банке и Код вклада, которые в главных таблицах Вкладчики и Вклады являются первичными, а в таблице-связке Операции – внешними.
Таким образом, между таблицами Вкладчики и Операции, а также между таблицами Вклады и Операции устанавливаются отношения «один-ко-многим», которые поддерживаются реляционной СУБД.
Этап 4. Создание таблиц БД средствами СУБД MS Access.
4.1. Загрузил СУБД MS Access. Создал файл БД (Файл/Создать/ Новая БД…).
4.2. Выбрал в окне БД вкладку Таблицы.
4.3. Создал макет таблицы Вкладчики в режиме Конструктора (режим Таблицы) (в соответствии с рисунками 1-2).
4.4. Создал макет таблицы Вклады в режиме Конструктора (режим Таблицы) (в соответствии с рисунками 3-4).
4.5. Создал макет таблицы Операции в режиме Конструктора (режим Таблицы) (в соответствии с рисунками 5-6).
4.6. Построил схему данных (в соответствии с рисунком 7).
Рисунок 1- Таблица Вкладчики в режиме Конструктор.
Рисунок 2- Таблица Вкладчики в режиме Таблицы.
Рисунок 3- Таблица Вклады в режиме Конст-р.
Рисунок 4- Таблица Вклады в режиме Таблицы.
Рисунок 5-Таблица Операции в режиме Конст-р.
Рисунок 6- Таблица Операции в режиме Таблицы.
Рисунок 7- Схема данных.
Контрольные вопросы:
1. Требования к содержанию таблиц реляционной БД.
2. Нормализация таблиц реляционной базы данных. Правила нормализации.
3. Способы создания таблиц в СУБД MS Access.
4. Порядок создания макета таблицы в режиме Конструктора.
5. Понятие типа данных. Краткая характеристика типов данных MS Access.
6. Какие типы данных не могут быть использованы при определении первичного ключа?
7. Понятие свойства поля. Назначение и краткая характеристика свойств полей таблиц БД MS Access.
8. Для чего применяется индексирование полей?
9. Понятие схемы БД и порядок ее формирования в СУБД MS Aсcess.
Ответы на контрольные вопросы:
1. Требования к реляционным моделям:
Рациональные варианты концептуальной схемы базы данных должны удовлетворять третьей нормальной форме, а также следующим требованиям:
Выбранный перечень отношений должен быть минимален. Отношение используется, если только его необходимость обусловлена задачами.
Выбранный перечень атрибутов должен быть минимален. Атрибут включается в отношение только в том случае, если он будет использоваться.
Первичный ключ отношения должен быть минимальным. То есть невозможно исключить ни один атрибут из идентифицирующей совокупности атрибутов, не нарушив при этом однозначной идентификации.
При выполнении операций над данными не должно возникать трудностей.
2.Нормализация-это процесс, используемый с целью повышения эффективности памяти, удаления избыточной информации, упрощение процесса разработки приложений.
Правила нормализации:
1)Уникальность полей- каждое поле таблицы должно представлять уникальный вид (следует избавиться от повтора полей)
2)Наличие уникального идентификатора, или ПК, который может состоять
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.
