Моор С.М., Моор П.К., Моор А.П. - Информационные технологии управления (1092190), страница 24

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 24)

Большинство современных СУБД основаны на реляционной модели данных. Название «реляционная» связано с тем, что все данные в таких БД представлены в виде таблиц. Каждая строка таблицы содержит информацию только об одном объекте и называется также записью. Столбец таблицы содержит однотипную для всех записей информацию и называется также полем.

Для успешного функционирования базы данных важна правильная организация в ней данных. При определении структуры данных в базе выделяют следующие основные понятия. Класс объектов - совокупность объектов, обладающих одинаковым набором свойств. Например, в базе данных «Деканат» классами объектов являются студенты, преподаватели, дисциплины. Для каждого отдельного объекта из данного класса в таблице создается отдельная запись. Свойство (атрибут) – некоторая информации об объекте, хранится в столбце (поле) таблицы. Например, фамилия, имя, отчество - это свойства для объекта Студент. Связь (отношение) - способ, которым связана информация о разных объектах.

Основными структурными компонентами реляционной базы данных, являются таблицы. При определении состава таблиц следует руководствоваться правилом: в каждой таблице должны храниться данные только об одном классе объектов. Например, в одной таблице нельзя хранить анкетные данные студента и названия дисциплин, по которым он сдавал экзамены, т.к. это свойства объектов разных классов.

Если в базе данных должна содержаться информация об объектах разных классов, то она должна быть разбита на отдельные таблицы. Связь между таблицами осуществляется с помощью общих полей.

Связи между любыми двумя таблицами относятся к одному из трех типов: один-к-одному (1:1), один-ко-многим (1:М) и много-ко-многим (М:М).

Связь типа «один-к-одному» (1:1). При этом типе связи каждой записи в одной таблице соответствует не более одной записи в другой таблице. Этот вид связи встречается редко: в основном в тех случаях, когда часть информации об объекте либо редко используется, либо является конфиденциальной (такая информация хранится в отдельной таблице, которая защищена от несанкционированного доступа).

Связь типа «один-ко-многим» (1:М). При таком типе связи каждой записи в одной таблице соответствует несколько записей в связанной таблице. Этот наиболее распространенный тип связей.

Для его реализации используются две таблицы. Одна из них представляет сторону «один», другая - сторону «много». Например, нужно иметь информацию о поставщиках (наименование фирмы, фамилия директора, расчетный счет, ИНН и т.д) и поставках ими товарах (наименование товара, количество, дата заказа и т.д.). Если все это хранить в одной таблице, то ее объем неоправданно возрастет, т.к. в ней для каждой записи об очередном заказе будут храниться данные о поставщике. Поскольку Поставщики и Поставки - это объекты разных классов, то и свойства их должны храниться в разных таблицах.

Решением этой задачи является создание двух таблиц. Условно назовем их Поставщики и Поставки. В каждой из них хранятся соответствующие свойства. Для связи этих таблиц нужно использовать часть информации о поставщике, осуществляющем поставки товара: она должна однозначно определять каждого поставщика. Такой информацией может явиться, например, уникальный «Код поставщика». Ниже будет рассмотрена более подробно модель базы данных для учета поставок товаров.

В таблице со стороны «один» (в нашем примере поле «Код поставщика» в таблице Поставщики) такие поля называются ключевыми. Основное требование к значениям в ключевых полях - это их уникальность для каждой записи (т.е. они не должны повторяться).

Связь типа «много-ко-многим» (М:М). При таком типе связи множеству записей в одной таблице соответствует множество записей в связанной таблице. Большинство современных СУБД непосредственно не поддерживают такой тип связи. Для его реализации в БД добавляется дополнительная таблица и такая связь разбивается на две связи типа «один-ко-многим».

11.3. Система управления базами данных Microsoft Access

11.3.1. Описание демонстрационного примера

Для демонстрации основных возможностей и приемов работы в MS Access рассмотрим следующий пример. Пусть для некоторого магазина, торгующего аудио- видеотехникой, требуется автоматизировать учет поставок товаров. Для автоматизации этого процесса предполагается использовать систему управления базами данных MS Access. Такой учет может быть организован в таблице MS Excel (табл. 11.1).

Следует отметить, что в действительности в таблице требуется хранить больше информации о поставщиках (фамилию директора, ИНН и т.д.) и товарах (марка, фирма производитель и т.д.). Будем иметь это ввиду, но, чтобы не усложнять пример, ограничимся только наименованием поставщика. Как это будет видно из разбиения таблицы на три таблицы, наличие большего количества данных о клиентах и товарах не существенно.

Как легко заметить, в таблице 11.1 хранится многократно одна и та же информация (например, адрес фирмы). Такая ситуация в моделировании БД называется «избыточность данных». Кроме того, в этой таблице имеется еще один существенный недостаток: при изменении только одной характеристики, например, адреса фирмы «Конус», необходимо внести изменения во многие строки таблицы. Такая ситуация в моделировании БД называется аномалия обновления.

Таблица 11.1

Таблица учета поставок продукции

Для ликвидации этих недостатков к таблице необходимо применить процедуру, которая называется нормализация. В рамках данного курса процесс нормализации в полном объеме не рассматриваться.

Для устранения указанных недостатков таблицу 11.1 разобьем ее на три: «Поставщики», «Товары» и «Поставки». В таблицах «Поставщики» и «Товары» добавим поля «Код_Поставщика» и «Код_Товара», которые будут являться первичными ключами в этих таблицах. Для описания связей между таблицами в таблице «Поставки» для указания поставщика будем использовать поле «Код_П», а для указания – поле «Код_Т». Эти поля называются внешними ключами.

Для обозначения имен полей в разных таблицах можно использовать одинаковые имена, однако для того, чтобы было понятно, из какой таблицы выбирается поле выберем для них разные имена. Кроме того, для удобства в таблицах 11.2 – 11.4 сократим имена полей.

Заметим, что в некоторых строках значение даты поставки не заполнены. Это означает, что данный заказ еще не выполнен.

Таблица 11.2

Таблица «Поставщики»

Таблица 11.3

Таблица «Товары»

Таблица 11.4

Таблица «Поставки»

11.3.2. Структура MS Access

Microsoft Access – это реляционная СУБД, работающая в среде Windows. Она позволяет создавать сложные базы данных, определяя структуру таблиц, связи между ними, обладает удобной системой создания запросов, отчетов и форм любой сложности.

Характеристики

Список файлов книги