Учебно-методический комплекс дисциплины «информационные технологии управления»
Скачать 3.77 Mb.
|
Основные понятия баз данных Современные информационные системы характеризуются большими объектами хранимых данных, их сложной организацией, а также высокими требованиями к скорости и эффективности обработки этих данных. Это становится возможным при использовании специальных средств- систем управления базами данных (СУБД). Большинство современных СУБД основаны на реляционной модели данных. Название «реляционная» связанно с тем, что все данные в таких БД представлены в виде таблиц. Каждая строка таблицы содержит информацию только об одном объекте и называется также записью. Столбец таблицы содержит однотипную для всех записей информацию и называется также полем. Для успешного функционирования базы данных важна правильная организация в ней данных. При определение структуры данных в базе выделяют следующие основные понятия. Класс объектов- совокупность объектов, обладающих одинаковым набором свойств. Например, в базе данных «Деканат» классами объектов являются студенты, преподаватели, дисциплины. Для каждого отдельного объекта из данного класса в таблице создаётся отдельная запись. Свойство (атрибут)- некоторая информация об объекте, хранится в столбце (поле) таблицы. Например, фамилия, имя, отчество - это свойства для объекта Студент. Связь (отношение)- способ, которым связана информация о разных объектах. Основными структурными компонентами реляционной базы данных, являются таблицы. При определении состава таблиц следует руководствоваться правилом: в каждой таблице должны храниться данные только об одном классе объектов. Например, в одной таблиц нельзя хранить анкетные данные студента и названия дисциплин, по которым он сдавал экзамены, т.к. это свойства объектов разных классов. Если в базе данных должна содержаться информация об объектах разных классов, то она должна быть разбита на отдельные таблицы. Связь между таблицами осуществляется с помощью общих полей. Связь любыми двумя таблицами относится к одному из трёх типов: один -к- одному (1:1), один -ко- многим (1:М) и много –ко- многим (М:М). Связь типа «один –к- одному» (1:1). При этом типе связи каждой записи в одной таблице соответствует не более одной записи в другой таблице. Это вид связи встречается редко: в основном в тех случаях, когда часть информации об объекте либо редко используется, либо является конфиденциальной (такая информация хранится в отдельной таблице, которая защищена от несанкционированного доступа). Связь типа «один –ко- многим» (1:М). При таком типе связи каждой записи в одной таблице соответствует несколько записей в связанной таблице. Это наиболее распространённый тип связей. Для его реализации используются две таблицы. Одна из них представляет сторону «один», а другая – сторону «много». Например, нужно иметь информацию о поставщиках (наименование фирмы, фамилия директора, расчётный счёт, ИНН т. д.) и поставках им товара (наименование товара, количество, дата заказа и т.д. ). Если всё это хранить в одной таблице то её объём неоправданно возрастёт, т.к. в ней для каждой записи об очередном заказе будут храниться данные о поставщике. Поскольку Поставщики и Поставки – это объекты разных классов, то и свойства их должны храниться в разных таблицах. Решением этой задачи является создание двух таблиц. Условно назовем их Поставщик и Поставки. В каждой из них хранятся соответствующие свойства. Для связи этих таблиц нужно использовать часть информации о поставщике, осуществляющем поставки товара: она должна однозначно определять каждого поставщика. Такой информацией может явиться, например, уникальный «Код поставщика». Ниже будет рассмотрена более подробно модель базы данных для учёта поставок товара. В таблице со стороны «один» (в нашем примере поле «Код поставщика» в таблице Поставщики ) такие поля называются ключевыми. Основное требование к значениям в ключевых полях – это их уникальность для каждой записи (т.е. они не должны повторяться). Связь типа «много –ко- многим» (М:М). При таком типе связи множество записей в одной таблице соответствует множество записей в связанной таблице. Большинство современных СУБД непосредственно не поддерживают такой тип связи. Для его реализации в БД добавляется дополнительная таблица и такая связь разбивается на две связи типа «один –ко- многим». Система управления базами данных Microsoft Access Описание демонстрационного примера Для демонстрации основных возможностей и приёмов работы в MS Access рассмотрим следующий пример. Пусть для некоторого магазина, торгующего аудио- видеотехникой, требуется автоматизировать учёт поставок товаров. Для автоматизации этого процесса предполагается использовать систему управления базами данных MS Access. Такой учёт может быть организован в таблице MS Excel (табл. 5.1). Таблица 5.1 Таблица учёта поставок продукции
Следует отметить, что в действительности в таблице требуется хранить информации о поставщиках (фамилию директора, ИНН и т.д. ) и товарах ( марка, фирма производитель и т.д. ). Будем иметь это ввиду, но, чтобы не усложнять пример, ограничимся только наименованием поставщика. Как это будет видно из разбиения таблицы на три таблицы, наличие большого количества данных о клиентах не существенно. Как легко заметить, в таблице 5.1 храниться многократно одна и та же информация (например, адрес фирмы). Такая ситуация в моделировании БД называется «избыточность данных». Кроме того, в этой таблице имеется ещё один существенный недостаток: при изменении только одной характеристики, например, адреса фирмы «Конус», необходимо внести изменения во многие строки таблицы. Такая ситуация в моделировании БД называется аномалия обновления. Для ликвидации этих недостатков к таблице необходимо применить процедуру, которая называется нормализация. В рамках данного курса процесс нормализации в полном объёме не рассматриваться. Для устранения указанных недостатков таблицу 5.1 разобьём её на три: «Поставщики», «Товары» и «Поставки». В таблицах «Поставщики» и «Товары» добавим поля «Код_ Поставщика» и «Код_ Товара»,которые будут являться первичными ключами в этих таблицах. Для описания связей между таблицами в таблице «Поставки» для указания поставщика будем использовать поле «Код- П», а для указания – поле «Код- Т». Эти поля называются внешними ключами. Для обозначения имён полей в разных таблицах можно использовать одинаковые имена, однако для того, чтобы было понятно, из какой таблицы выбирается поле выберем для них разные имена. Кроме того, для удобства в табл. 5.2-5.4 сократим имена полей. Заметим, что в некоторых строках значение даты поставки не заполнены. Это означает, что данный заказ ещё не выполнен. Таблица 5.2 |
Похожие:
 | Учебно-методический комплекс составлен в соответствии с требованиями государственного стандарта высшего профессионального образования... |  | Учебно-методический комплекс составлен в соответствии с требованиями государственного образовательного стандарта высшего профессионального... |
| Учебно-методический комплекс составлен в соответствии с требованиями государственного образовательного стандарта высшего профессионального... | | Учебно-методический комплекс составлен в соответствии с требованиями государственного образовательного стандарта высшего профессионального... |
| Профиль подготовки информационно-измерительная техника и технологии информационные системы и технологии | | Учебно-методический комплекс составлен в соответствии с требованиями федерального государственного образовательного стандарта высшего... |
| Рабочей программы учебной дисциплины «информационные технологии в профессиональной деятельности» 4 | | Учебно-методический комплекс дисциплины обсуждена на заседании кафедры Информационные системы управления «29» июня 2011 г |
| При разработке учебно – методического комплекса учебной дисциплины в основу положены | | Учебно-методический комплекс составлен в соответствии с требованиями государственного образовательного стандарта высшего профессионального... |