WWW.KNIGA.SELUK.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА - Книги, пособия, учебники, издания, публикации

 


Pages:   || 2 | 3 |

«Э.Г. Федоров Базы данных Курс лекций для студентов специальности 080801 Прикладная информатика (в экономике) всех форм обучения Волгоград 2010 Рецензент: Игнатьев А.В., ...»

-- [ Страница 1 ] --

Центросоюз Российской Федерации

Российский университет кооперации

Волгоградский кооперативный институт (филиал)

Кафедра информационных систем в экономике

Э.Г. Федоров

Базы данных

Курс лекций

для студентов специальности 080801

«Прикладная информатика (в экономике)»

всех форм обучения

Волгоград 2010 Рецензент:

Игнатьев А.В., кандидат технических наук, доцент кафедры информационных систем в экономике Волгоградского кооперативного института (филиала) Российского университета кооперации Федоров Э.Г.

Базы данных Курс лекций для студентов специальности 080801 «Прикладная информатика (в экономике)» всех форм обучения. – Волгоград:

Волгоградский кооперативный институт, 2010. – 120 с.

Курс лекций содержит основные разделы дисциплины «Базы данных».

Рассмотрены вопросы, касающиеся моделей данных, методологии проектирования реляционных баз данных, изложены основы языка запросов SQL, освещены перспективы развития баз данных и новых технологий работы с данными.

Предназначен для студентов специальности 080801.65 «Прикладная информатика (в экономике)» всех форм обучения. Также может быть использован студентами любых специальностей, изучающими вопросы создания и использования баз данных.

Рассмотрен и одобрен на заседании кафедры информационных систем в экономике протокол № 1 от 30 августа 2010 г.

Фёдоров Э.Г., Волгоградский кооперативный институт (филиал) Российского университета кооперации, Оглавление Введение ………………………...……………………………………………… Лекция 1. Понятие базы данных и системы управления базами данных …. Лекция 2. Модели организации работы пользователей с базой данных..…. Лекция 3. Модели данных ……………………………………..……………… Лекция 4. Реляционная модель данных …………………………..………...... Лекция 5. Основы реляционной алгебры ………………………….………… Лекция 6. Модели и стадии проектирования баз данных ………..………..... Лекция 7. Проектирование реляционной базы данных ……………….......... Лекция 8. Пример проектирования реляционной БД ………………..……… Лекция 9. Язык SQL: основные понятия и компоненты. Ограничения целостности данных ………………………………….……………. Лекция 10. Язык SQL: управление таблицами ………...…………..………… Лекция 11. Язык SQL: SELECT – основной оператор извлечения данных……………………………………………………………... Лекция 12. Язык SQL: Извлечение данных с учетом условий……...…..…... Лекция 13. Язык SQL: Объединение, добавление, обновление и удаление данных……………………………………………….. Лекция 14. Тенденции развития баз данных ………………………...………. Контрольные вопросы……...………………………………………………….. Заключение ………………………………...…………………………………... Список литературы……...……...……………………………………………… Введение В настоящее время трудно представить себе информационную систему, которая не имела бы в качестве основы или важной составляющей базу данных (БД). Концепции и технологии баз данных всегда были тесно связаны с развитием систем автоматизированной обработки информации. Создание баз данных после появления реляционного подхода превратилось из искусства в науку. Базы данных – это вполне сложившаяся дисциплина, являющаяся скорее инженерной, чем чисто научной, основанная на достаточно формализованных подходах.



Базам свойственная «перманентность» данных. Соответственно назначение систем управления базами данных (СУБД) – обеспечение в течение длительного времени их сохранности, а также возможностей выборки и актуализации.

Базы данных в стремительно развивающихся информационных технологиях – это сравнительно консервативное направление, где СУБД и сами базы представляют собой «долговременные сооружения». Элементная база ЭВМ и парадигмы программирования изменяются быстрее, чем хранимые данные теряют актуальность. В таких условиях, в отличие от прикладных программистов, разработчики СУБД, администраторы БД должны постоянно помнить о проблеме «наследственности» - о том, как интегрировать в создаваемую систему наследуемые данные, находящиеся под управлением устаревшей СУБД, о том, как построить систему, чтобы вновь создаваемые данные могли быть, в свою очередь, наследованы следующим поколением систем.

Достаточно консервативны и концепции баз данных. Эта консервативность – следствие не только свойства «долговечности», но и того факта, что базы вторичны по отношению к описываемым ими реальным процессам и объектам, достаточно стабильным и типичным.

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

Данное учебное пособие может рассматриваться как введение в в проблематику теории и практики информационных систем, основанных на базах данных. Материал пособия может стать «отправной точкой» при освоении специальных дисциплин, посвященных информационным системам, изучаемых в рамках специальности «Информационные системы в технике и технологиях».

Лекция Понятие базы данных и системы управления базами данных 1. Понятие базы и банка данных.

2. Функции систем управления базами данных.

3. Проблема целостности базы данных. Транзакции и блокировки.

1. Понятие базы и банка данных Развитие вычислительной техники и появление емких внешних запоминающих устройств предопределило интенсивное развитие автоматических и автоматизированных систем разного назначения и масштаба, в первую очередь заметное в области бизнес-приложений. Такие системы работают с большими объемами информации, которая обычно имеет достаточно сложную структуру, требует оперативности в обработке, часто обновляется и в то же время требует длительного xpaнения. Примерами таких систем являются автоматизированные системы управления предприятием, банковские системы, системы резервирования и продажи билетов и т. д.





Другими направлениями, стимулировавшими развитие, стали, с одной стороны, системы управления физическими экспериментами, обеспечивающими сверхоперативную обработку в реальном масштабе времени огромных потоков данных от датчиков, а с другой автоматизированные библиотечные информационно-поисковые системы.

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

Банк данных (БнД) - это система специально организованных данных, программных, языковых, организационных и технических средств, предназначенных для централизованного накопления и коллективного многоцелевого использования данных. Следует отметить, что термин «банк данных» используется сравнительно редко. В современной литературе понятию «банк данных» соответствует понятие системы баз данных.

Под базой данных (БД) обычно понимается именованная совокупность данных, отображающая состояние объектов и их отношений в рассматриваемой предметной области. Характерной чертой баз данных является постоянство: данные постоянно накапливаются и используются;

состав и структура данных, необходимых для решения тех или иных прикладных задач, обычно постоянны и стабильны во времени; отдельные или даже все элементы данных могут меняться - но и это есть проявление постоянства - постоянная актуальность.

Система управления базами данных (СУБД) – это совокупность языковых и программных средств, предназначенных для создания, ведения и совместного использования БД многими пользователями. Иными словами, СУБД играет роль интерфейса между прикладными программами и базой данных (рис. 1).

Прикладная программа Прикладная программа Рис. 1. Формирование запроса на выборку в СУБД Access Иногда в составе банка данных выделяют архивы. Основанием для этого является особый режим использования данных, когда только часть данных находится под оперативным управлением СУБД. Все остальные данные (собственно архивы) обычно располагаются на носителях, оперативно не управляемых СУБД. Одни и теже данные в разные моменты времени могут входить как в базы данных, так и в архивы. Банки данных могут не иметь архивов, но если они есть, то в состав банка данных может входить и система управления архивами.

В это мсмыле главной отличительной чертой баз данных является использование центализованной ситемы управления данными, причем как на уровне файлов, так и на уровне элементов данных. Централизованное хранение совместно используемых данных приводит не только к сокращению затрат н создание и поддержание данных в актуальном состоянии, но и к сокращению избыточности информации, упрощению процедур поддержания непротиворечивости и целостности данных.

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

Многократное использование данных: пользователи должны иметь возможность использовать данные различным образом.

Простота: пользователи должны иметь возможность легко узнать и понять, какие данные имеются в их распоряжении.

Легкость использования: пользователи должны иметь возможность осуществлять (процедурно) простой доступ к данным, при этом все сложности доступа к данным должны быть скрыты в самой ситеме управления базами данных.

Гибкость использования: обращение к данным или их поиск должны осуществляться с помощью различных методов доступа.

Быстрая обработка запросов на данные: запросы на данные, в том числе незапланированные, должны обрабатываться с помощью высокоуровневого языка запросов, а не только прикладными программами, написанными с целью обработки конкретных запросов (разработка таких программ в каждом конкретном случае связана с большими затратами времени). Пользователь должен иметь возможность кратко выразить нетривиальные запросы (в нескольких словах или несколькими нажатиями клавиш мыши). Это означает, что средство формулирования должно быть достаточно «декларативным», т.

е. упор должен быть сделан на «что», а не на «как». Кроме того, средство обработки запросов не должно зависеть от приложения, т.е. оно должно работать с любой возможной базой данных.

Язык взаимодействия конечных пользователей с системой должен обеспечивать конечным пользователям возможность получения данных без использования прикладных программ.

База данных - это основа для будущего наращивания прикладных программ: базы данных должны обеспечивать возможность быстрой и дешевой разработки новых приложений.

Сохранение затрат умственного труда: существующие программы и логические структуры данных (на создание которых обычно затрачивается много человеко-лет) не должны переделываться при внесении изменений в базу данных.

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

Распределенная обработка данных: система должна функционировать в условиях вычислительных сетей и обеспечивать эффективный доступ пользователей к любым данным распределенной БД, размещенным в любой точке сети.

Адаптивность и расширяемость: база данных должна быть настраиваемой, причем настройка не должна вызывать перезаписи прикладных программ. Кроме того, поставляемый с СУБД набор предопределенных типов данных должен быть расширяемым – в системе должны иметься средства для определения новых типов и не должно быть различий в использовании системных и определенных пользователем типов.

Контроль за целостностью данных: система должна осуществлять контроль ошибок в данных и выполнять проверку взаимного логического соответствия данных.

Восстановление данных после сбоев: автоматическое восстановление без потери данных. В случае аппаратных или программных сбоев система должна возвращаться к некоторому согласованному состоянию данных.

Вспомогательные средства должны позволять разработчику или администратору базы данных предсказать и оптимизировать производительность системы.

Автоматическая реорганизация и nеремещение: система должна обеспечивать возможность перемещения данных или автоматическую реорганизацию физической структуры.

2. Функции систем управления базами данных Перечислим основные функции системы управления базами данных.

1. Определение структуры создаваемой базы данных, ее инициализация и проведение начальной загрузки.

В большинстве современных СУБД база данных представляется в виде совокупности таблиц. Рассматриваемая функция позволяет описать и создать в памяти структуру таблицы, провести начальную загрузку данных в таблицы.

Как правило, создание структуры базы данных происходит в режиме диалога. СУБД последовательно запрашивает у пользователя необходимые данные.

2. Предоставление пользователям возможности манипулирования данными (выполнение вычислений, разработка интерфейса ввода/вывода, визуализация).

В MS Access реализация данной функции сводится к созданию и выполнению запросов и форм ввода (рис. 2).

Рис. 2. Формирование запроса на выборку в СУБД Access 3. Обеспечение логической и физической независимости данных.

Важнейшим свойством СУБД является возможность поддерживать два независимых взгляда на базу данных – взгляд пользователя, воплощаемый в «логическом» представлении данных и «взгляд» системы – «физическое»

представление данных в памяти ЭВМ. Обеспечение логической независимости данных предоставляет возможность изменения (в определенных пределах) «логического» представления базы данных без необходимости изменения физических структур хранения данных. Таким образом, изменение «логического» представления данных в прикладных программах не приводит к изменению структур хранения данных.

Обеспечение физической независимости данных представляет возможность изменять (в определенных пределах) способы организации базы данных в памяти ЭВМ не вызывая необходимости изменения «логического»

представления данных. Таким образом, изменение способов организации базы данных не приводит к изменению прикладных программ.

4. Защита логической целостности базы данных.

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

5. Защита физической целостности.

При работе ЭВМ возможны сбои в работе (например, из-за отключения электропитания), повреждение машинных носителей данных. При этом могут быть нарушены связи между данными, что приводит к невозможности дальнейшей работы. Развитые СУБД имеют средства восстановления БД. В таких системах в определенный момент БД копируется на резервные носители. Все обращения к БД записываются программно в журнал изменений. Если БД, запускается процедура восстановления, в процессе которой в резервную копию из журнала изменений вносятся все произведенные изменения.

6. Управление полномочиями пользователей на доступ к базе данных.

Разные пользователи могут иметь разные полномочия по работе с данными (некоторые данные должны быть недоступны; определенным пользователям не разрешается обновлять данные и т.п.). В СУБД предусматриваются механизмы разграничения полномочий доступа, основанные либо на принципах паролей, либо на описании полномочий.

7. Синхронизация работы нескольких пользователей.

Достаточно часто может иметь место ситуация, когда несколько пользователей одновременно выполняют операцию обновления одних и тех же данных. Такие коллизии могли привести к нарушению логической целостности данных, поэтому система должна предусматривать меры, не допускающие обновление данных другим пользователям, пока работающий с этими данными пользователь полностью не закончит с ними работать.

8. Управление ресурсами среды хранения.

БД располагается во внешней памяти ЭВМ. При работе в БД заносятся новые данные (занимается память), удаляются данные (освобождается память). СУБД выделяет ресурсы памяти для новых данных, перераспределяет освободившуюся память, организует ведение очереди запросов к внешней памяти и т.п.

9. Поддержка деятельности системного персонала.

При эксплуатации базы данных может возникать необходимость изменения параметров СУБД, выбора новых методов доступа, изменения (в определенных пределах) структуры хранимых данных, а также выполнения ряда других общесистемных действий. СУБД предоставляет возможность выполнения этих и других действий для поддержки деятельности БД обслуживающему системному персоналу, называемому администратором БД.

3. Проблема целостности базы данных. Транзакции и блокировки В функции современной СУБД кроме ведения собственно базы данных входит также ведение журнала транзакций.

Транзакция – это единица действий, производимых с базой данных. В состав транзакции может входить несколько операторов изменения базы данных, но эти операторы либо выполняются все, либо не выполняется ни один.

Необходимость использования транзакций в базах данных проиллюстрируем на упрощенном примере.

Предположим, что база данных используется в некотором банке и один из клиентов банка желает перевести деньги на счет другого клиента банка. В базе данных хранится информация о количестве денег у каждого из клиентов.

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

Предположим также, что после выполнения первого из действий (уменьшения суммы денег на счете первого клиента) произошел сбой.

Например, могла прерваться связь клиентского компьютера с базой данных, или на клиентском компьютере мог произойти системный сбой, что привело к перезагрузке операционной системы. Что в этом случай стало с базой данных? Команда на уменьшение денег на счете первого клиента была выполнена, а вторая команда – на увеличение денег на другом счете – нет.

Без использования транзакций описанная выше ситуация привела бы к противоречивому, неактуальному состоянию базы данных.

Использование механизма транзакций позволяет находить решение в этом и подобных случаях. Перед выполнением первого действия выдается команда начала транзакции. Поскольку после выполнения первого действия транзакция не была завершена, изменения не будут внесены в базу данных.

Изменения вносятся (фиксируются) только после завершения транзакции.

Оператор завершения транзакций обычно называется COMMIT. До выдачи данного оператора сохранения данных в базе не произойдет.

В нашем примере, поскольку оператор фиксации транзакции не был выдан, БД откатится в первоначальное состояние – иными словами, суммы на счетах клиентов останутся те же, что и были до начала транзакции.

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

Транзакции не обязательно могут быть короткими. Бывают транзакции, которые длятся несколько часов или даже несколько дней. Увеличение количества действий в рамках одной транзакции требует увеличения занимаемых системных ресурсов. Поэтому, желательно делать транзакции, по возможности, короткими. В журнал транзакций заносятся все транзакции – и зафиксированные и завершившиеся откатом. Ведение журнала транзакций совместно с созданием резервных копий базы данных позволяет достичь высокой надежности базы данных.

Предположим, что база данных была испорчена в результате аппаратного сбоя компьютера, на котором был установлен сервер СУБД. В этом случае нужно использовать последнюю сделанную резервную копию базы данных и журнал транзакций. Причем применить к базе данных нужно только те транзакции, которые были зафиксированы после создания резервной копии.

Большинство современных СУБД позволяют администратору воссоздать базу данных исходя из резервной копии и журнала транзакций.

С понятием транзакции тесно связано понятие блокировки. Блокировки необходимы для того, чтобы дать различным пользователям возможность одновременно работать с базой данных. При одновременной работе в некоторый момент времени разные пользователи могут обратиться к одной и той же записи. СУБД должна запрещать подобные действия, поскольку они могут привести к ошибкам.

Для реализации этого запрета СУБД устанавливает блокировку на объекты, которые использует транзакция. Существуют разные типы блокировок – табличные, страничные, строчные и другие, которые отличаются друг от друга количеством заблокированных записей. Чаще других используется строчная блокировка – при обращении транзакции к одной строке блокируется только эта строка, остальные строки остаются доступными для изменения.

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

Лекция 2.

Модели организации работы пользователей с базой данных 1. Модель с централизованной архитектурой.

2. Модель с автономными персональными ЭВМ.

3. Модель вычислений с сетью и файловым сервером (архитектура «файл-сервер»).

4. Распределенная модель вычислений (архитектура «клиент-сервер»).

5. Распределенная модель вычислений (Клиент-сервер. Трехзвенная (многозвенная) архитектура).

6. Краткий обзор СУБД.

Постоянное изменение основных свойств вычислительной техники и развитие программного обеспечения обуславливало возникновение различных моделей взаимодействия пользователей с базой данных. Дадим характеристику этим моделям в хронологическом порядке.

1. Модель с централизованной архитектурой При использовании этой технологии база данных, СУБД и прикладная программа (приложение) располагаются на одном компьютере - мэйнфрейме или персональном компьютере (рис. 3). Для такого способа организации не требуется поддержка сети и все сводится к автономной работе. Работа построена следующим образом:

БД в виде набора файлов находится на жестком диске компьютера.

На том же компьютере установлены СУБД и приложение для работы с Пользователь запускает приложение. Используя предоставляемый приложением пользовательский интерфейс, он инициирует обращение к БД на выборку/обновление информации.

Все обращения к БД идут через СУБД, которая инкапсулирует внутри себя все сведения о физической структуре БД.

СУБД инициирует обращения к данным, обеспечивая выполнение запросов пользователя (осуществляя необходимые операции над данными).

СУБД возвращает результат в приложение.

Приложение, используя пользовательский интерфейс, отображает результат выполнения запросов.

Подобная архитектура использовалась в первых версиях СУБД DB2, Oracle.

Таким образом, в этой модели реализуется однопользовательский режим работы. Исходная же идея создания и использования баз данных предполагала многопользовательское использование данных. В данной многопользовательский режим работы. С этой целью к мейнфрейму подключалось несколько терминалов, но тогда приходилось обслуживать в рамках ресурсов одного компьютера весь комплекс возникающих задач, начиная от обработки и хранения данных, до отображения информации и приема запросов от пользователей. Модель использовалась в период «господства» больших ЭВМ (IBM-370, ЕС-1045, ЕС-1060). Все программы разных пользователей выполнялись одной ЭВМ в режиме разделения времени или мультипрограммирования. С ростом сложности задач росло количество пользователей и объемы баз данных, вследствие чего подобная архитектура более не обеспечивала удовлетворительной производительности.

Основным недостатком является резкое снижение производительности при увеличении числа пользователей.

2. Модель с автономными персональными ЭВМ Каждый пользователь имеет свою автономную персональную ЭВМ. База данных и СУБД копируется на компьютере каждого пользователя.

Каждый пользователь работает с базой данных на своей ЭВМ. Модель широко использовалась в начальный период появления персональных ЭВМ.

Для модели характерна полная децентрализация данных. Основным недостатком модели является невозможность оперативного обновления данных на всех компьютерах при изменении их одним из пользователей.

3. Модель вычислений с сетью и файловым сервером (архитектура «файл-сервер») Увеличение сложности задач, появление персональных компьютеров и локальных вычислительных сетей явилось предпосылками появления новой архитектуры «файл-сервер». Эта архитектура баз данных с сетевым доступом предполагает назначение одного из компьютеров сети в качестве выделенного сервера, на котором будут храниться файлы базы данных. В соответствие с запросами пользователей файлы с файл-сервера передаются на рабочие станции пользователей, где и осуществляется основная часть обработки данных. Центральный сервер выполняет в основном только роль хранилища файлов, не участвуя в обработке самих данных (рис. 4).

Работа построена следующим образом:

База данных в виде набора файлов находится на жестком диске специально выделенного компьютера (файлового сервера).

Существует локальная сеть, состоящая из клиентских компьютеров, на каждом из которых установлены СУБД и приложение для работы с БД.

На каждом из клиентских компьютеров пользователи имеют возможность запустить приложение. Используя предоставляемый приложением пользовательский интерфейс, он инициирует обращение к БД на выборку/обновление информации.

Все обращения к БД идут через СУБД, которая инкапсулирует внутри себя все сведения о физической структуре БД, расположенной на файловом сервере.

СУБД инициирует обращения к данным, находящимся на файловом сервере, в результате которых часть файлов БД копируется на клиентский компьютер и обрабатывается, что обеспечивает выполнение запросов пользователя (осуществляются необходимые операции над данными).

При необходимости (в случае изменения данных) данные отправляются назад на файловый сервер с целью обновления БД.

СУБД возвращает результат в приложение.

Приложение, используя пользовательский интерфейс, отображает результат выполнения запросов.

В рамках архитектуры «файл-сервер» были выполнены первые версии популярных так называемых настольных СУБД, таких как dBase и MS Access.

Основные недостатки данной архитектуры:

При одновременном обращении множества пользователей к одним и тем же данным производительность работы резко падает, т.к.

необходимо дождаться пока пользователь, работающий с данными, завершит свою работу. В противном случае возможно затирание исправлений, сделанных одними пользователями, изменениями других пользователей.

Вся тяжесть вычислительной нагрузки при доступе к БД ложится на приложение клиента, так как при выдаче запроса на выборку информации из таблицы вся таблица БД копируется на клиентскую машину и выборка осуществляется на клиенте. Таким образом, не оптимально расходуются ресурсы клиентского компьютера и сети. В результате возрастает сетевой трафик и увеличиваются требования к аппаратным мощностям пользовательского компьютера.

Недостаточно развитый аппарат транзакций служит потенциальным источником ошибок в плане нарушения целостности информации при одновременном внесении изменений в одну и ту же запись.

4. Распределенная модель вычислений (архитектура «клиент-сервер») Использование архитектуры «клиент-сервер» предполагает наличие некоторого количества компьютеров, объединенных в сеть, один из которых выполняет особые управляющие функции (является сервером сети) (рис. 5).

Так, архитектура «клиент-сервер» разделяет функции приложения пользователя (называемого клиентом) и сервера. Приложение-клиент формирует запрос к серверу, на котором расположена БД, на структурном языке запросов SQL (Structured Query Languague), являющемся промышленным стандартом в мире реляционных БД. Удаленный сервер принимает запрос и переадресует его SQL-серверу БД.

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

Все это повышает быстродействие системы и снижает время ожидания результата запроса. При выполнении запросов сервером существенно повышается степень безопасности данных, поскольку правила целостности данных определяются в БД на сервере и являются едиными для всех приложений, использующих эту БД. Мощный аппарат транзакций, поддерживаемый SQL-серверами, позволяет исключить одновременное измене-ние одних и тех же данных различными пользователями и предоставляет возможность откатов к первоначальным значениям при внесении в БД изменений, завершившихся аварийно.

Итак, в результате работа построена следующим образом:

База данных в виде набора файлов находится на жестком диске специально выделенного компьютера (сервера сети).

СУБД располагается также на сервере сети.

Существует локальная сеть, состоящая из клиентских компьюте-ров, на каждом из которых установлено клиентское приложение для работы с На каждом из клиентских компьютеров пользователи имеют возможность запустить приложение. Используя предоставляемый приложением пользовательский интерфейс, он инициирует обра-щение к СУБД, расположенной на сервере, на выбор-ку/обновление информации. Для общения используется специаль-ный язык запросов SQL, т.е. по сети от клиента к серверу переда-ется лишь текст запроса.

СУБД инкапсулирует внутри себя все сведения о физической структуре БД, расположенной на сервере.

СУБД инициирует обращения к данным, находящимся на сервере, в результате которых на сервере осуществляется вся обработка данных и лишь результат выполнения запроса копируется на кли-ентский компьютер.

Таким образом, СУБД возвращает результат в приложение.

Приложение, используя пользовательский интерфейс, отображает результат выполнения запросов.

Рассмотрим, как выглядит разграничение функций между сервером и клиентом:

Функции приложения-клиента:

Посылка запросов серверу.

Интерпретация результатов запросов, полученных от сервера.

Представление результатов пользователю в некоторой форме (интерфейс пользователя).

Функции серверной части:

Прием запросов от приложений-клиентов.

Интерпретация запросов.

Оптимизация и выполнение запросов к БД.

Отправка результатов приложению-клиенту.

Обеспечение системы безопасности и разграничение доступа.

Управление целостностью БД.

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

К разряду промышленных СУБД принадлежат Oracle, Gupta, Informix, Sybase, MS SQL Server, DB2, InterBase и ряд других.

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

Рассмотрим основные достоинства данной архитектуры по сравнению с архитектурой «файл-сервер»:

Существенно уменьшает сетевой трафик.

Уменьшает сложность клиентских приложений (большая часть нагрузки ложится на серверную часть), а, следовательно, и требо-вания к аппаратным мощностям клиентских компьютеров.

Наличие специального программного средства – SQL-сервера – приводит к тому, что существенная часть проектных и программистских задач становится уже решенной.

Существенно повышает целостность и безопасность БД.

Однако нельзя не указать и некоторые недостатки данной архитектуры.

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

хорошо зарекомендовала себя на практике, в настоящий момент функционирует большое количество БД, построенных в соответствии с данной архитектурой.

5. Распределенная модель вычислений (Клиент-сервер. Трехзвенная (многозвенная) архитектура) Конец 90-х годов 20-го века был ознаменован развитием сети Интернет.

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

Так, в современных условиях является совершенно нормальным то, что человек, находясь дома, имеет возможность войти в глобальную сеть, посетить сайт компании, торгующей интересующими его товарами, и посмотреть, есть ли в наличии интересующий его товар, сколько он сейчас стоит, как обстоит дело с доставкой и, если все его устраивает, оформить заказ на приобретение товара.

Новое понимание действительности привело к возникновению новых технологий, новых подходов к хранению и обработке данных. Использование архитектуры «клиент-сервер» для организации такой деятельности, как описано выше в примере, не целесообразно.

Один из основных моментов – необходимость снижения затрат на организацию рабочих мест пользователей. Так, для полноценной работы в Интернет не требуется каких-то запредельных мощностей. Требуется лишь возможность установки операционной системы и Web-браузера. Когда Вы запрашиваете информацию о книге (выполняете запросы к базе данных Интернет-магазина), на Ваш компьютер не ложится практически никакой нагрузки.

Второй момент – устранение трудностей с обновлением клиентских приложений. Когда Интернет-магазин меняет свое программное обеспечение, это никак не сказывается на Вас как пользователе. Вы не скачиваете никаких дополнительных файлов.

Для обеспечения описанных выше преимущетв появилось некоторое развитие архитектуры «клиент-сервер». В настоящий момент это развитие представляет собой так называемую трехзвенную (в некоторых случаях многозвенную) архитектуру. Рассмотрев архитектуру «клиент-сервер», можно заключить, что она является 2-звенной: первое звено – клиентское приложение, второе звено – сервер БД + сама БД.

В трехзвенной архитектуре вся бизнес-логика (деловая логика), ранее входившая в клиентские приложения, выделяется в отдельное звено, называемое сервером приложений. При этом клиентским приложениям остается лишь пользовательский интерфейс. Так, в качестве клиентского приложения в описанном выше примере выступает Web-браузер.

Что улучшается при использовании трехзвенной архитектуры? Теперь при изменении бизнес-логики более нет необходимости изменять клиентские приложения и обновлять их у всех пользователей. Кроме того, максимально снижаются требования к аппаратуре пользователей.

Итак, в результате работа построена следующим образом:

БД в виде набора файлов находится на жестком диске специально выделенного компьютера (сервера сети).

СУБД располагается также на сервере сети.

Существует специально выделенный сервер приложений, на котором располагается программное обеспечение (ПО) делового анализа (бизнес-логика).

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

На каждом из клиентских компьютеров пользователи имеют возможность запустить приложение – тонкий клиент. Используя пользовательский интерфейс, он инициирует обращение к программному обеспечению делового анализа, расположенному на сервере приложений.

Сервер приложений анализирует требования пользователя и формирует запросы к БД. Для общения используется специальный язык запросов SQL, т.е. по сети от сервера приложений к серверу БД передается лишь текст запроса.

СУБД инкапсулирует внутри себя все сведения о физической структуре БД, расположенной на сервере.

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

Сервер приложений возвращает результат в клиентское приложение (пользователю).

Приложение, используя пользовательский интерфейс, отображает результат выполнения запросов.

6. Краткий обзор СУБД В большинстве корпоративных приложений, обеспечивающих ежедневную деятельность крупных компаний и организаций, используются БД. Эти приложения подразделяются на несколько быстро развивающихся категорий:

Планирование ресурсов предприятий (Enterprise Resource Planning – Регулирование отношений с клиентами (Customer Relationship Management – CRM).

Управление системой поставок (Supply Chain Management – SCM).

Автоматизация продаж (Sales Force Automation – SFA).

Финансовые приложения.

СУБД подразделяют на две большие категории: так и называемые «настольные» и «серверные».

Настольные СУБД. К числу подобных СУБД относятся DBase, FoxPro, Paradox, MS Access. Настольные СУБД основаны на файл-серверной архитектуре и используются в следующих условиях: объемы данных и частота обновлений не бывают слишком большими, организация территориально обычно расположена в одном небольшом здании, количество пользователей колеблется от одного до 10-15 человек.

Серверные СУБД. Для крупных организаций использование файлсерверных технологий является неудовлетворительным, поэтому автоматизация обработки данных в этих условиях ведется с помощью серверных СУБД: DB2, Informix, MS SQL Server, Oracle, Sybase, Interbase.

Лекция 3. Модели данных 1. Многоуровневые модели предметной области.

2. Обзор моделей данных СУБД как инструмент представления концептуальной 1. Многоуровневые модели предметной области Обычно база данных содержит информацию о некоторой предметной области – наборе объектов, представляющих интерес для пользователей. То есть, реальный мир отображается совокупностью понятий, между которыми существуют (и фиксируются) определенные связи.

Перед тем как разместить в памяти компъютера базу данныx с информацией, необходимой для решения задач пользователей, исходная информация должна пройти многошаговую предварительную обработку.

Сначала проводится работа по выяснению того, какие данные нужны и где их можно получить. Затем исследуются взаимосвязи в этом множестве данных, в результате образуется некоторая структурная схема данных, в которой должны найти отражение требовaния всех потенциальных заказчиков информации. Затем в рассмотрение включают СУБД, в среде которой будет производиться создание и заполнение дaнными файлов базы данных, а также размещение их во внешней памяти компьютера.

Абстрагированное описание предметной области с логической точки зрения будем называют концептуальной схемой. Соответственно, систематизация понятий и связей предметной области называется логическим или концептуальным проектированием. Совокупность функциональных характеристик объектов и особенностей представления информации (например, в числовой или текстовой форме), называют моделью данных.

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

Рассмотрим 3-уровневое представление данных (рис. 6).

1). Концептуальный уровень отражает требования всех потенциальных пользователей БД к структуре организации данных в предметной области и представляется в виде концептуальной схемы (или информационной структуры). Концептуальная схема разрабатывается в терминах некоторой модели данных, но без учета требований к конкретной СУБД, т.е. является проблемно-ориенrтиpованной и системно-независимой (независимой от конкретной СУБД, операционной системы или aппаратных средств).

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

пользователей 2). Логический уровень (или уровень реализации) соответствует требованиям каждого пользователя или прикладной программы к необходимой информации с учетом способов описания этой информации в конкретной вы6ранной СУБД. Однако физические способы размещения информации во внешней памяти компьютера и методы доступа к ней здесь не рассматриваются.

Логический уровень представления данных соответствует внутренней схеме данных (логической схеме) или просто схеме. Представление данныx на логическом уровне является представлением концептуальной схемы с помощью конкретной СУБД.

3). Физический уровень представления данных характеризуется детальной информацией о размещении файлов БД во внешней памяти ЭВМ (т.е. на разоичных внешних носителях данных), а также о методах физического доступа к данным. Это представление называется внутренней моделью БД, рассмaтpивается и реализуется системными программистами.

Отражение взгляда отдельного пользователя на концептуальную схему (как вариант восприятия предметной области) называют внешней схемой.

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

Посредством внешней схемы и обеспечивается доступ пользователя лишь к тем данным, которые нужны для решения его задачи.

Таким образом, база данных на логическом уровне, средствами СУБД описывается одной внутренней схемой и некоторым числом внешних схем (для каждого пользовaтеля и прикладной программы). Выделение внешних схем позволяет также установить средства защиты базы данных от несанкционированного доступа, а также обеспечить секретность некоторых данных в отношении определенных пользователей.

Встречаются также варианты 2-уровневого представления данных:

логический и физический уровни (здесь логический уровень объединяет концептуальный и логический уровни трехуровневого представления);

инфологический и даталогический уровни (инфологический соответствует концептуальному, а даталогический объединяет логический и физический уровни трехуровневого представления).

2. Обзор моделей данных СУБД как инструмент представления концептуальной модели После построения концептуальной модели выбирается СУБД, с помощью которой будет организована БД и работа с ней. Каждая СУБД поддерживает определенные типы данных, а также средства представления связей между данными, составляющими модель данных СУБД. Таким образом, следующий этап проектирования БД состоит в отображении концептуальной модели в модель данных СУБД. Этот этап называют логическим проектированием БД.

Полученную при этом модель называют логической структурой данных.

К числу классических относятся следующие модели данных:

иерархическая, сетевая, реляционная, многомерная и другие.

Иерархическая модель В иерархической модели связи между данными можно описать с помощью упорядоченного графа (или дерева). Упрощенно представление связей между данными в иерархической модели показано на рис. 7.

Рис. 7. Представление связей в иерархической модели Для описания структуры (схемы) иерархической БД на некотором языке программирования используется тип данных «дерево». Корневым называется тип, который имеет подчиненные типы и сам не является подтипом.

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

представляет собой иерархически организованный набор типов «запись».

Иерархическая БД представляет собой упорядоченную совокупность экземпляров данных типа «дepeво» (деревьев).

К достоинствам иерархической модели данных относятся эффективное использование памяти ЭВМ и неплохие показатели времени выполнения основных операций над данными. Иерархическая модель данных удобна для работы с иерархически упорядоченной информацией. Недостатком модели является громоздкость для обработки информации со сложными логическими связями, а также сложность понимания для обычного пользователя.

На иерархической модели данных основано сравнительное ограниченное количество СУБД, в числе которых можно назвать зарубежные системы IMS, PC/Focus, Теаm-Up и Data Edge, а также отечественные системы Ока, ИНЭС и МИРИС. Примером иерархической СУБД для ПЭВМ для ПЭВМ является отечественная система НИКА (адаптация системы ИНЭС для IBM PC).

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

Для описания схемы сетевой БД используются две группы типов: «запись» и «связь». Сетевая БД состоит из набора записей и набора соответствующих связей. На формирование связи особых ограничений не накладывается. Если в иерархических структурах запись-потомок могла иметь только одну запись-предка, то в сетевой модели данных записьпотомок может иметь произвольное число записей-предков. Пример схемы сетевой БД показан на рис. 9. Типы связей здесь обозначены надписями на соединяющих типы записей линиях.

Достоинством сетевой модели данных является возможность эффективной реализации по показателям затрат памяти и оперативности. В сравнении с иерархической моделью сетевая модель предоставляет большие возможности в смысле допустимости образования произвольных связей.

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

Наиболее известными сетевыми СУБД являются IDMS, db_Vista, UNIBAD.

Реляционная модель Реляционная модель данных предложена сотрудником фирмы IBM Эдгаром Коддом и основывается на понятии “отношение” (relation).

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

Физическое размещение данных в реляционных базах на внешних носителях легко осуществляется с помощью файлов.

Достоинство реляционной модели данных заключается в простоте, понятности и удобстве физической реализации на ЭВМ. Именно простота и понятность для пользователя явились основной причиной их широкого использования. Основными недостатками реляционной модели являются следующие: отсутствие стандартных средств идентификации отдельных записей и сложность описания иерархических и сетевых связей.

Примерами зарубежных реляционных СУБД для ПЭВМ являются dBaseподобные системы, DB2, FoxPro, Access, Oracle, MS SQL Server.

Многомерная модель В развитии концепций ИС можно выделить следующие два направления:

системы оперативной (транзакционной) обработки;

системы аналитической обработки (системы поддержки принятия В системах аналитической обработки наиболее эффективными оказываются многомерные СУБД, использующие технологию OLAP (OnLine Analytical Processing - оперативная аналитическая обработка).

Многомерность модели данных означает многомерное логическое представление структуры информации и, вообще говоря, не связано с многомерностью визуализации представления данных.

Многомерные структуры представляются как гиперкубы данных. Каждая грань гиперкуба является размерностью.

В существующих многомерных СУБД используются два основных варианта организации данных: гиперкубическая и поликубическая.

В поликубической схеме предполагается, что в БД может быть определено несколько гиперкубов с различной размерностью и с различными измерениями в качестве граней. Примером системы, поддерживающей поликубический вариант БД, является сервер Oracle Express Server.

В случае гиперкубической схемы предполагается, что при наличии нескольких гиперкубов БД все они имеют одинаковую размерность и совпадающие измерения.

По сравнению с реляционной моделью многомерная организация данных обладает более высокой наглядносmъю и информаmивносmъю.

Для иллюстрации на рис. 10 упрщенно приведены реляционное (а) и многомерное (б) представления одних и тех же данных об объемах продаж автомобилей одним из менеджеров автосалона.

К числу основных понятий многомерных моделей данных относятся измерение и ячейка.

Измерение (Dimension) - это множество однотипных значений, принимаемых кокретным параметром, и соответствующих одной из граней гиперкуба. Примерами измерений могут быть месяцы (июнь, июль, август), марки автомобилей («Жигули», «Москвич», «Волга»), объемы продаж автомобилей (20, 23, 24, …), фамилии менеджеров по продажам (Иванов, Петров, Сидоров) и т.д. В многомерной модели данных измерения играют роль индексов, служащих для идентификации конкретных значений в ячейках гиперкуба.

Рис. 10. Реляционное и многомерное представление данных Ячейка (сеll) или показатель - это поле, значение которого однозначно определяется фиксированным набором значений параметров-измерений.

В примере на рис. 10,б каждое значение ячейки «Объем продаж»

однозначно определяется комбинацией временного измерения (Месяц продаж) и модели автомобиля. На практике зачастую требуется большее количество измерений.

В случае многомерной модели данных применяется ряд специальных операций, к которым относятся: формирование «среза», «вращение», агрегация и детализация.

Операция «cрез» (slice) в качестве результата формирует подмножество гиперкуба, полученное в результате фиксации одного или нескольких измерений (значений параметров). Формирование «cpeзов» выполняется для ограничения используемых пользователем значений, так как все значения гиперкуба практически никогда одновременно не используются.

Операция «вращение» (rotate) применяется при двухмерном представлении данных. Суть ее заключается в изменении порядка измерений при визуальном представлении данных. Так, «вращение» двумерной таблицы, показанной на рис. 10,б, приведет к изменению ее вида таким образом, что по горизонтальной оси марка автомобиля, а по вертикальной – время (месяцы).

Операцию «вращение» можно обобщить и на многомерный случай, если под ней понимать процедуру изменения порядка следования измерений.

Операции «агрегация» (drill up) и «детализация» (drill down) означают соответственно переход к более общему и к более детальному представлению информации пользователю из гиперкуба. Например, с помощью операции «агрегация» можно найти суммарное количество всех проданных автомобилей марки «Жигули» за несколько месяцев.

Основным достоинством многомерной модели данных является удобство и эффективность обработки больших объемов данных, связанных со временем.

Примерами систем, поддерживающими многомерные модели данных, являются Oracle Express Server, Cache.

Лекция 4. Реляционная модель данных 1. Основные понятия реляционной модели данных.

2. Связи между таблицами.

3. Контроль целостности связей.

1. Основные понятия реляционной модели данных Реляционная модель является удобной и наиболее привычной формой представления данных. В математических дисциплинах понятие «отношние»

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

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

Основными понятиями, с помощью которых определяется реляционная модель, являются следующие: отношение, схема отношения, домен, кортеж, кардинальность, атрибут, степень отношения, первичный ключ, значение атрибута, тип данных. Эти понятия имеют аналоги, соответствие которым приведено в табл 1.

Таблица 1. Форма представления элементов реляционной модели.

Элемент реляционной модели Форма представления (аналог) Отношение – двумерная таблица, содержащая некоторые данные.

Сущность – реальный или абстрактный объект, данные о котором хранятся в одном или нескольких отношениях.

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

Домен – это совокупность значений, из которых берутся значения соответствующих атрибутов определенного отношения. С точки зрения программирования, домен – это тип данных, определяемый системой (стандартный) или пользователем.

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

Первичный ключ, который включает более одного столбца, называют множественным, или комбинированным, или составным.

Правило целостности объектов утверждает, что первичный ключ не может быть полностью или частично пустым, т.е. не может иметь значение null.

Если выбранный первичный ключ состоит из минимально необходимого набора атрибутов, то говорят, что он является не избыточным.

Ключи, которые можно также использовать в качестве первичных, называют возможными, потенциальными или альтернативными ключами.

Внешний ключ – это столбец или подмножество столбцов одной таблицы, которые могут служить в качестве первичного ключа для другой таблицы.

Внешний ключ является ссылкой на первичный ключ другой таблицы.

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

Реляционная модель наладывает на внешние ключи ограничение для обеспечения целостности данных, называемое ссылочной целостностью. Это означает, что каждому знаечнию внешнего ключа должны соответствовать строки в связываемых отношениях.

На практике внешний ключ всегда будет составным, если он ссылается на составной первичный ключ в другой таблице. Очевидно, что количество толбцов и их типы данных в первичном и внешнем ключах совпадают.

Если таблица связана с несколькими другими таблицами, он может иметь несколько внешних ключей.

Ключи обычно используют для достижения следующих целей:

Исключения дублирования значений в ключевых атрибутах (остальные атрибуты в расчет не принимаются);

Упорядочения кортежей. Возможно упорядочение по возрастанию или убыванию значений всех ключевых атрибутов, а также смешанное упорядочение (по одним – возрастание, по другим - убывание);

Ускорения работы с кортежами отношения;

Организация связывания таблиц.

Отметим, что не любой таблице можно поставить в соответствие отношение.

Условия, выполнение которых позволяет таблицу считать отношением, следующие:

Данные в ячейках таблицы должны быть структурно неделимыми (атомарными);

Данные в одном столбце должны быть одного типа;

Каждый столбец быть уникальным (недопустимо дублирование столбцов);

Столбцы и строки могут размещаться в таблице в произвольном Столбцы имеют уникальные наименования.

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

В целом концепция реляционной модели определяется двенадцатью правилами Кодда, основную суть которых представим ниже.

1. Правило информации. Вся информация в БД должна быть представлена исключительно на логическом уровне и только одним способом – в виде значений, содержащихся в таблицах.

2. Правило гарантированного доступа. Логический доступ к каждому элементу данных (атомарному значению) в реляционной БД должен обеспечиваться путем использования комбинации имени таблицы, первичного ключа и имени столбца.

3. Правило поддержки недействительных значений требует, чтобы отсутствующие данные можно было представить с помощью недействительных значений (null).

4. Правило динамического каталога, основанного на реляционной модели.

БД должна сама себя описывать, т.е. содержать набор системных таблиц, описывающих структуру самой БД. Описание БД на логическом уровне должно быть представлено в том же виде, что и основные данные, чтобы пользователи, обладающие соответствующими правами, могли работать с ним с помощью того же реляционного языка, который он применяют для работы с основными данными.

5. Правило исчерпывающего подъязыка данных требует, чтобы СУБД использовала язык реляционной БД (например, SQL), поддерживающий все основные функции СУБД (создание БД, чтение, ввод данных и т.д.

6. Правило обновления представлений гласит, что все представления, которые теоретически можно обновить, должны быть доступны для обновления. Это касается представлений, являющихся виртуальными таблицами, позволяющими показывать пользователям различные фрагменты структуры БД.

7. Правило добавления, обновления и удаления акцентирует внимание на том, что базы данных по своей природе ориентированы на множества. Это правило требует, чтобы операции добавления, обновления и удаления можно было выполнять над множествами строк. Оно предназначено для того, чтобы запретить реализации, в которых поддерживаются только операции над одной строкой.

8. Правило независимости физических данных. Прикладные программы и утилиты для работы с данными должны на логическом уровне оставаться нетронутыми при любых изменениях способов хранения данных или методов доступа к ним.

9. Правило независимости логических данных. Прикладные программы и утилиты для работы с данными должны на логическом уровне оставаться нетронутыми при внесении в базовые таблицы любых изменений, которые теоретически позволяют сохранить нетронутыми содержащиеся в этих таблицах данные.

Правила 8 и 9 означают отделение пользователя и прикладной программы от низкоуровневой реализации БД. Они утверждают, что конкретные способы реализации хранения или доступа, используемые в СУБД, а также изменения структуры таблиц БД не должны влиять на возможность пользователя работать с данными.

10. Правило независимости условий целостности гласит, что язык БД должен поддерживать ограничительные условия, налагаемые на вводимые данные и действия, которые могут быть выполнены над данными.

11. Правило независимости распространения требует независимость реляционной СУБД от потребностей конкретного клиента, язык БД должен обеспечивать возможность работы с распределенными данными, расположенными на других компьютерных системах.

12. Правило единственности предотвращает использование других возможностей для работы с базой, кроме языка базы данных, поскольку это может нарушить ее целостность.

2. Связи между таблицами При проектировании БД информацию обычнo размещают в нескольких таблицах, которые при этом связаны семантикой информации. В реляционных СУБД для указания связей таблиц производят операцию их связывания. Установление связи между таблицами облегчает доступ к данным. Между таблицами могут устанавливаться бинарные (между двумя таблицами), тернарные (между тремя таблицами) и, в общем случае, n-арные связи. Рассмотрим для простоты наиболее часто встречающиеся бинарные связи.

При связывании двух таблиц выделяют основную и дополнительную (подчиненную) таблицы. Логическое связывание таблиц производится с помощью ключа связи. Ключ связи, по аналогии с обычным ключом таблицы, состоит из одного или нескольких полей, которые в данном случае называют полями связи. Суть связывания состоит в установлении соответствия полей связи основной и дополнительной таблиц. Поля связи основной таблицы могут быть обычными и ключевыми. В качестве полей связи подчиненной таблицы чаще всего используют ключевые поля.

В зависимости от того, как определены поля связи основной и дополнительной таблиц (как соотносятся ключевые поля с полями связи), между двумя таблицами в общем случае могут устанавливаться следующие четыре основных вида связи: один - один (1:1), один - много (1:М), много один (М:1), много - много (М:М или M:N). Далее дадим характеристику названным видам связи между двумя таблицами и приведем примеры их использования.

Связь вида 1: Связь 1:1 образуется в случае, когда все поля связи основной и дополнительной таблиц являются ключевыми. Поскольку значения в ключевых полях обеих таблиц не повторяются, обеспечивается взаимно-однозначное соответствие записей из этих таблиц. Сами таблицы, здесь равноправны.

Пример. Пусть имеются основная О1 и дополнительная Д1 таблицы.

Совокупность ключевых полей обозначим символами «*», а используемые для связи поля обозначим символом «+».

Таблица О Таблица Д В приведенных таблицах установлена связь между записью (а, 10) таблицы О1 и записью (а, стол) таблицы Д1. Основанием этого является совпадение значений в полях связи. Аналогичная связь существует и между записями (в, 3) и (в, книга) этих же таблиц.

Сопоставление записей двух таблиц по существу означает образование новых «виртуальных записей» (псевдозаписей). Так, первую пару записей логически можно считать новой псевдозаписью вида (а, 10, стол), а вторую пару - псевдозаписью вида (в, 3, книга).

На практике связи вида 1:1 используются сравнительно редко, так как хранимую в двух таблицах информацию легко объединить в одну таблицу, которая занимает гораздо меньше места в памяти ЭВМ.

Связь вида 1: М Связь 1:М имеет место в случае, когда одной записи основной таблицы соответствует несколько записей вспомогательной таблицы.

Пример. Пусть имеются две связанные таблицы О2 и Д2. В таблице О содержится информация о видах мультимедиа-устройств ПЭВМ, а в таблице Д2 – сведения о фирмах-производителях этих устройств, а также о наличии на складе хотя бы одного устройства.

Таблица О Таблица Д Таблица Д2 имеет два ключевых поля, так как одна и та же фирма может производить устройства различных видов. В примере фирма Sony производит устройства считывания и перезаписи с компакт-дисков.

Сопоставление записей обеих таблиц по полю “Koд” порождает псевдозаписи вида: (а, CD-ReWriter, LG, да), (а, CD- ReWriter, Mitsumi, нет), (а, CD-ReWriter, NЕС, да), (а, CD-ReWriter, Раnаsоnic, да), (а, CD-ReWriter, Sоnу, да), (б, CD-ROM, Philips, нет), (б, CD-ROM, Sony, нет) и т.д.

Если свести псевдозаписи в новую таблицу, то получим полную информацию обо всех видах мультимедиа-устройств ПЭВМ, фирмах, их про изводящих, а также сведения о наличии конкретных видов устройств на складе.

Связь вида М: Связь М:1 имеет место в случае, когда одной или нескольким записям основной таблицы ставится в соответствие одна запись дополнительной таблицы. Вид связи (1:М или М:1) зависит от того, какая таблица является основной, а какая дополнительной.

Пример. Если таблицу Д2 сделать основной, а таблицу O2 – дополнительной, получим связь вида 1:М.

Связь вида М:М Самый общий вид связи М:М возникает, когда нескольким записям основной таблицы соответствует несколько записей дополнительной таблицы.

Пример. Пусть в основной таблице О4 содержится информация о том, на каких станках могут работать рабочие некоторой бригады. Таблица Д содержит сведения о том, кто из ремонтников какие станки обслуживает.

Таблица О Таблица Д Первой и третьей записям таблицы О4 соответствует первая запись таблицы Д4 (у всех этих записей значение второго поля – «станок1»).

Четвертой записи таблицы О4 соответствуют вторая и четвертая записи таблицыД4 (во втором поле этих записей содержится «станок3»).

Исходя из определения полей связи этих таблиц можно составить новую таблицу с именем «O4+Д4», ее записями будут псевдозаписи, котрым можно придать смысл возможных смен, составляемых при планировании работы.

Для удобства, поля новой таблицы переименованы (такую операцию предлагают современные СУБД).

Таблица O4+Д Полученную таблицу можно использовать, например, для получения ответа на вопрос: «Kто обслуживает станки, на которых работает токарь Петров?».

3. Контроль целостности связей Наиболее широко используется связь вида 1:М, поэтому в дальнейшем рассмотрим этот вид связи. Напомним, что при образовании связи 1:М одна запись основной (главной) таблицы (главная, родительская запись) оказывается связанной с несколькими записями дополнительной (дополнительные, подчиненные записи) и имеет место схема, показанная на рис. 11.

Рис. 11. Связь 1:М записей двух таблиц Контроль целостности связей обычно означает анализ содержимого двух таблиц на соблюдение следующих правил:

каждой записи основной таблицы соответствует нуль или более записей дополнительной таблицы;

в дополнительной таблице нет записей, которые не имеют родительских записей в основной таблице;

каждая запись дополнительной таблицы имеет только одну родительскую запись основной таблицы.

При вводе новых записей возникает вопрос определения последовательности ввода записей в таблицы такой, чтобы не допустить нарушения целостности. Исходя из приведенных правил, логичной является схема, при которой данные сначала вводятся в основную таблицу, а затем – в дополнительную. Заполнение полей связи дополнительной таблицы контролируется на предмет совпадения со значениями полей связи основной таблицы. Если вновь вводимое значение в поле связи дополнительной таблицы не совпадет ни с одним соответствующим значением в записях основной таблицы, то ввод такого значения должен блокироваться.

При редактировании полей связи дополнительной таблицы очевидным требованием является то, чтобы новое значение поля связи совпадало с соответствующим значением какой-либо записи основной таблицы. Т.е.

дополнительная запись может сменить родителя, но остаться без него не должна.

Редактирование поля связи основной таблицы разумно подчинить одному из следующих правил:

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

изменения в полях связи основной таблицы передавать во все поля связи всех записей дополнительной таблицы (каскадное обновление ).

В операциях удаления записей связанных таблиц большую свободу, очевидно, имеют записи дополнительной таблицы. Удаление их должно происходить практически бесконтрольно.

Удаление записей основной таблицы логично подчинить одному из следующих правил:

удалять можно запись, которая не имеет подчиненных записей;

запретить (блокировать) удаление записи при наличии подчиненных записей, либо удалять ее вместе со всеми подчиненными записями (каскадное удаление).

Лекция 5. Основы реляционной алгебры С точки зрения внешнего представления (абстрагирования на логическом уровне) объектов реального мира, модель данных - это основные понятия и способы, используемые при анализе и описании предметной области.

Среди многих попыток представить обработку данных на формальном абстрактном уровне реляционная модель, предложенная Э. Ф. Коддом, стала первой работоспособной моделью данных, поскольку помимо средств описания объектов имела эффективный инструментарий преобразований этих описаний - оперaции реляционной алгебры.

Реляционная алгебра в том виде, в котором она была определена Коддом, состоит из двух групп по четыре оператора:

традиционные операции над множествами (но модифицированные с учетом того, что их операндами являются отношения, а не произвольные множества): объединение, пересечение, разность и декартово произведение.

специальные реляционные операции: выборка, проекция, соединение, Ниже рассмотрим подробнее операции реляционной алгебры.

Объединение возвращает отношение, содержащее все кортежи, которые принадлежат либо одному из двух заданных отношений, либо им обоим (рис.

12).

Объединение:

Рис. 12. Объединение.

Пересечение возвращает отношение, содержащее все кортежи, которые принадлежат одновременно двум заданным отношениям (рис. 13).

Пересечение:

Рис. 13. Пересечение Разность возвращает отношение, содержащее все кортежи, которые принадлежат первому из двух заданных отношений и не принадлежат второму (рис. 14).

Разность:

Рис. 14. Разность.

Проuзведенuе возвращает отношение, содержащее все возможные кортежи, которые являются сочетанием двух кортежей, принадлежащих соответственно двум заданным отношениям (рис. 15).

Ст.преп.

Доцент Ассистент Произведение:

Рис. 15. Произведение.

Выборка возвращает отнощение, содержащие все кортежи из заданного отношения, которые удовлетворяют указанным условиям (рис. 16) Иванов Математика Сидоров Математика Макарова Математика Цветкова Информатика Козлов Информатика Выборка:

Кафедра = «Математика»

(Кафедра = «Физика») AND (Год 1970) Рис. 16. Выборка.

Проекцuя возвращает отношение, содержащее все кортежи (подкортежи) заданного отношения, которые остались в этом отношении после исключения из него некоторых атрибутов (рис. 17).

Иванов Математика Зав.каф. Цветкова Информатика Доцент Проекция:

Рис. 17. Проекция.

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

Петров Физика Ст.преп.

Лютикова Физика Ассистент Соединение:

Рис. 18. Соединение Деление для заданных двух унарных отношений и одного бинарного возвращает отношение, содержащее все кортежи из первого унарного отношения, которые содержатся также в бинарном отношении и соответствуют всем кортежам во втором унарном отношении (рис. 19).

Ст.преп. Зав.каф. Информатика Рис. 19. Деление.

Результат выполнения любой операции над отношением также является отношением, поэтому результат одной операции может использоваться в качестве исходных данных для другой. Реляционная алгебра имеет набор правил вывода отношений, позволяюших вывести отношение на выходе произвольной реляционной операции, зная отношения на входе этой операции.

Рассмотренные восемь операторов Кодда не являются минимальным набором, так как не все они примитивны, т.е. часть из них можно определить через другие операторы. Действительно, операции соединения, пересечения и деления можно определить через остальные пять. Эти пять операций (выборка, проекция, произведение, объединение и разность) можно рассматривать как примитивные в том смысле, что ни одна из них не выражается через другие. Они образуют минимальный набор, но тем не менее, не обязательно единственно возможный. Кроме того, остальные три операции (в особенности операция соединения) на практике используются настолько часто, что, несмотря на то, что они не являются примитивными, имеет смысл обеспечить их непосредственную поддержку.

В целом выражения реляционной алгебры служат для символического высокоуровневого представления намерений пользователя (например, в отношении некоторого запроса).

Лекция 6. Модели и стадии проектирования баз данных 1. Модели и стадии проектирования БД.

2. Системный анализ предметной области.

3. Модели и технологии инфологического проектирования реляционных БД:

3.1. Инфологическое проектированне и семантическая модель.

3.2. Модель «Сущность - связь».

3.3. ER-диаграмма.

3.4. Нормальные формы ER-диаграмм.

4. Даталогические модели.

5. Физические модели.

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

Проектирование базы данных - это упорядоченный формализованный процесс создания системы взаимосвязанных описаний, т.е. таких моделей предметной области, которые связывают (фиксируют) хранимые в базе данные с объектами предметной области, описываемыми этими данными.

Проектирование начинается с анализа предметной области и выявления функциональных и других требований к проектируемой системе. Это описание, выполненное с использованием естественного языка, математических выражений, таблиц, графов и других средств называют инфологической моделью.Такая человеко-ориентированная модель практически полностью независима от физических параметров среды хранения данных, поэтому эта модель не изменяется до тех пор, пока нет изменений в предметной области.

Остальные модели являются машинно-ориентированными.

Так как доступ к данным осуществляется с помощью конкретной СУБД, то модели должны быть представлены на языке описания данных этой СУБД.

Такое описание, создаваемое по инфологической модели данных, называют даталогической моделью данных.

С точки зрения моделирования необходимо различать модели предметной области и модели базы данных. Эти модели взаимосвязаны, поскольку представляют собой образы одного и того же оригинала - некоторого множества предметов реального мира, информацию о которых мы предполагаем хранить и обрабатывать с помощью проектируемой БД.

Модель предметной области ассоциируется с неформальным уровнем семантического моделирования, а модель базы данных - с формализованным уровнем системы (и в частности, СУБД). Целью семантического моделирования является формирование основы для формализованного проектирования БД.

Ниже приведены основные стадии процесса моделирования:

1. Системный анализ: определение парадигмы информационной модели (структурированность и динамичность информации; способ представления и характер использования информации).

2. Инфологическое проектирование: определение системы атрибутов, типовых запросов, типовых процедур обработки.

3. Даталогическое проектирование: разработка концептуальной схемы БД, внешних схем, правил семантической целостности.

4. Физическое проектирование: отображение даталогической модели в модель данных выбранной СУБД – проектирование структур данных и связей.

Далее рассмотрим перечисленные стадии проектирования подробнее.

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

Существуют два подхода к определению состава и структуры предметной области.

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

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

Такое деление условно, и на практике используются компромиссные варианты, предполагающие по мере развития системы расширение как состава объектов, так и спектра прикладных задач.

Цель системного анализа предметной области - выделить предметную область как систему обьектов u их взаимосвязей, определив при этом функционально-информационные требования к их последующему представлению в виде системы взаимо связанных данных.

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

Такие модели обобщенно представляют информационные потребности пользователей создаваемой системы в части использования хранимых данных.

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

систему атрибутов и средств описания предметной области (например, логические (алгоритмические) связи между показателями);

ограничения целостности, определяющие допустимость значения отдельных полей и взаимосвязей как на уровне семантики содержимого БД, так и ее физической структуры (отдельных файлов данных и взаимосвязей между ними);

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

3.2. Модель «Сущность - связь»

Одним из наиболее популярных средств формализованного представления предметной области ИС является модель «сущность – связь» (ERмодель), которая положена в основу значительного количества коммерческих продуктов (САSЕ-средств), поддерживающих полный цикл разработки систем БД. Они поддерживают стадию концептуального проектирования предметной области разрабатываемой системы, а также позволяют осуществить на основе построенной их средствами модели стадию логического проектирования путем автоматической генерации концептуальной схемы БД для выбранной СУБД.

Моделирование предметной области базируется на использовании графических диаграмм, строящихся по определенной технологии.

Семантическую основу ЕR-модели составляют следующие положения:

Совокупность взаимосвязанных объектов предметной области представляется как совокупность сущностей;

Сущность обладает характеристическими свойствами (атрибутами), отличающими ее от других сущностей и позволяющими ее идентифицировать;

сущности можно классифицировать по типам сущностей - классам:

каждый экземпляр сущности (представляющий некоторый объект) может быть отнесен к классу, каждый экземпляр которого обладает общими для экземпляров класса и отличающими их от сущностей других классов свойствами;

систематизация представления, основанная на классах, предполагает иерархическую зависимость типов: сущность типа А является подтипом сущности В, если каждый экземпляр типа А является экземпляром сущности типа В;

взаимосвязи объектов могут быть представлены как связи - сущности, которые служат для фиксирования (представления) взаимозависимости двух или нескольких сущностей.

Любой объект предметной области обладает свойствами, часть из которых выделяется как характеристические - значимые с точки зрения прикладной задачи. При этом в процессе анализа и систематизации предметной области обычно выделяются классы - совокупности объектов, обладающих одинаковым набором свойств, задаваемых в виде наборов атрибутов (значения атрибутов для объектов одного класса, разумеется, могут различаться).

На уровне представления предметной области (т. е. ее инфологической модели) объекту, рассматриваемому как понятие (объект в сознании человека), соответствует понятие сущность; объекту, как части материального мира (и существующему независимо от сознания человека), соответствует понятие экземпляр сущности; классу объектов соответствует понятие тип сущности.

Далее будем предполагать тождественность понятий объект и сущность, свойство объекта и свойство сущности.

Как было отмечено ранее, ЕR-моделирование предметной области базируется на использовании графических диаграмм. Изложение основных положений ЕR-модели проиллюстрируем на примере ЕR-диаграммы, приведенной на рис. 20.

Табельный номер Специальность Иностранный язык Рис. 20. Пример ЕR-диаграммы Сущность. Сущность, с помощью которой моделируется класс однотипных объектов, определяется как предмет, который может быть четко идентифицирован. Так же как каждый объект уникально характеризуется набором значений свойств, сущность должна определяться таким набором атрибутов, который позволял бы различать отдельные экземпляры сущности. Уникальным идентификатором сущности может являться атрибут, комбинация атрибутов, комбинация связей или комбинация связей и атрибутов, однозначно отличающая любой экземпляр сущности от других экземпляров сущности того же типа (класса).

Сущность имеет имя, уникальное в пределах модели. При этом имя сущности - это имя типа (класса), а не некоторого конкретного экземпляра.

Сущности подразделяются на сильные и слабые. Сушность является слабой, если ее существование зависит от другой сущности, сильной по отношению к ней. Например, сущность «Подчиненныи» является слабой по отношению к сущности «Сотрудник»: если будет удалена запись, соответствующая некоторому сотруднику, имеющему подчиненных, то сведения о подчинении также должны бытьудалены.

Свойства. Свойство может быть множественным или единичным - т.е.

атрибут, задающий свойство, может одновременно иметь несколько значений или одно. Например, сотрудник может иметь несколько специальностей, но его табельный номер имеет единственное значение.

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

В некоторых случаях различают базовые и производные свойства.

Например, «Поставщик» может иметь свойство «Общее количество поставляемых деталей», которое вычисляется суммированием количества деталей, поставляемых им по проекту.

Если наличие не которого свойства для всех экземпляров сущности не является обязательным, то такое свойство называется условным. Например, не все сотрудники обладают свойством «Ученая степень».

Значения свойств могут быть статическими (постоянными) или динамическими (т. е. меняться со временем). Например, свойство «Табельный номер» является статическим, а «Адрес» - динамическим. Свойство может быть неопределенным, если оно является динамическим, но его текущее значение еще не задано.

Свойство может рассматриваться как ключевое, если его значение уникально и однозначно идентифицирует сущность.

Связи. Кроме связей между объектом и его свойствами, инфологическая модель отражает связи между объектами разных классов. Связь - ассоциация, объединяющая несколько сущностей. Эта ассоциация может существовать между разными сущностями или между сущностью и ею же самой (рекурсивная связь).

Сущности, объединяемые связью, называются участниками. Степень связи определяется количеством участников связи.

Если каждый экземпляр сущности участвует, по крайней мере, в одном экземпляре связи, то такое участие этой сущности называется полным (или обязательным); в противном случае - неполным (или необязательным).

Количественный характер участия экземпляров сущностей (один или многие) задается типом связи (или мощностью связи). Возможны следующие типы: «один к одному» (1:1), «один ко многим» (l:M), «многие к одному» (М:l), «многие ко многим» (М:М).

В большинстве САSЕ-систем для простоты принято, что ассоциация всегда должна быть бинарной и может существовать между двумя разными сущностями или между сущностью и ею же самой (рекурсивная связь).

Среди многих разновидностей взаимосвязей наиболее частыми являются такие отношения иерархического типа, как «часть - целое», «род - вид».



Pages:   || 2 | 3 |
 


Похожие работы:

«Международный консорциум Электронный университет Московский государственный университет экономики, статистики и информатики Евразийский открытый институт Сычев Ю.Н. Основы информационной безопасности Учебно-практическое пособие Москва 2007 1 УДК 004.056 ББК –018.2*32.973 С 958 Сычев Ю.Н. ОСНОВЫ ИНФОРМАЦИОННАЯ БЕЗОПАСНОСТЬ Учебно-практическое пособие. – М.: Изд. центр ЕАОИ, 2007. – 300 с. Сычев Ю.Н., 2007 Евразийский открытый институт, 2007 2 СОДЕРЖАНИЕ Тема 1. Актуальность информационной...»

«Федеральное агентство по образованию Владивостокский государственный университет экономики и сервиса В.М. ГРИНЯК, Е.И. КОГАЙ ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ УПРАВЛЕНИЯ ТОРГОВЛЕЙ Практикум Владивосток Издательство ВГУЭС 2010 ББК 65.01 Г 85 Рецензенты: П.В. Зиновьев, доцент кафедры ММ, ДВГТУ; С.М. Моисеев, директор фирмы Созвездие, г. Владивосток Гриняк, В.М., Когай, Е.И. ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ УПГ 85 РАВЛЕНИЯ ТОРГОВЛЕЙ [Текст] : практикум. – Владивосток : Изд-во ВГУЭС, 2010. – 152 с. Рассмотрены...»

«Согласовано Утверждаю Директор Федерального государственного Ректор ГОУ ВПО научного учреждения Государственный Кемеровский Государственный научно-исследовательский институт Университет информационных образовательных технологий (ГосИнформОбр) И.А. Свиридова В.П.Кулагин Утверждаю Начальник управления программ развития в сфере образования _ А.В.Карпов ОТЧЕТ О ДЕЯТЕЛЬНОСТИ КЕМЕРОВСКОГО ОБЛАСТНОГО ЦЕНТРА НИТ за 2007 год Руководитель ОЦ НИТ д. ф.-м. н. _К.Е. Афанасьев Кемерово, Кемеровский ОЦ НИТ....»

«Федеральное агентство связи Федеральное государственное образовательное бюджетное учреждение высшего профессионального образования Московский технический университет связи и информатики профиль Автоматизация технологических процессов и производств в почтовой связи Квалификация выпускника бакалавр Москва 2011 2 1. Общие положения 1.1. Определение Основная образовательная программа высшего профессионального образования (ООП ВПО) – система учебно-методических документов, сформированная на основе...»

«Российская академия наук Сибирское отделение Институт систем информатики имени А.П.Ершова СО РАН Отчет о деятельности в 2003 году Новосибирск 2004 Институт систем информатики имени А.П.Ершова СО РАН 630090, г. Новосибирск, пр. Лаврентьева, 6 e-mail: iis@iis.nsk.su http: www.iis.nsk.su тел: (3832) 30-86-52, факс: (3832) 32-34-94 Директор Института д.ф.-м.н. Марчук Александр Гурьевич e-mail: mag@iis.nsk.su http: www.iis.nsk.su тел: (3832) 30-86- Заместитель директора по науке д.ф.-м.н. Яхно...»

«Математическая биология и биоинформатика. 2011. Т. 6. № 1. С.102–114. URL: http:// www.matbio.org/2011/Abakumov2011(6_102).pdf ================== МАТЕМАТИЧЕСКОЕ МОДЕЛИРОВАНИЕ ================= УДК: 577.95 Неопределенность при моделировании экосистемы озера * **2 ©2011 Пахт Е.В. 1, Абакумов А.И. 1 ФГОУ ВПО Дальневосточный государственный технический рыбохозяйственный университет, Владивосток, 690087, Россия 2 Учреждение Российской академии наук Институт автоматики и процессов управления ДВО РАН,...»

«The Hidden Language of Computer Hardware and Software Charles Petzold тайный язык информатики Чарльз Петцольд Москва 2001 г. УДК 004 ББК 32.973.26–018 П33 Петцольд Ч. П33 Код. — М.: Издательско-торговый дом Русская Редакция, 2001. — 512 с.: ил. ISBN 978-5–7502–0159–4 Эта книга — азбука компьютерных технологий. Шаг за шагом автор знакомит читателя с сущностью кодирования информации, рассказывает об истории возникновения компьютеров, на практических примерах помогает освоить основные концепции...»

«Министерство экономического развития Российской Федерации Федеральная служба государственной регистрации, кадастра и картографии ГОСУДАРСТВЕННЫЙ (НАЦИОНАЛЬНЫЙ) ДОКЛАД О СОСТОЯНИИ И ИСПОЛЬЗОВАНИИ ЗЕМЕЛЬ В РОССИЙСКОЙ ФЕДЕРАЦИИ В 2009 ГОДУ МОСКВА, 2010 Государственный (национальный) доклад о состоянии и использовании земель в Российской Федерации в 2009 году Редакционная коллегия: С.В. Васильев, В.С. Кислов, В.В. Андропов, Г.Ю. Елизарова, М.В. Прохоров, Л.Е. Васильева, А.В. Нуприенкова, Р.Р....»

«ТКП 204 – 2009 (02140) ТЕХНИЧЕСКИЙ КОДЕКС УСТАНОВИВШЕЙСЯ ПРАКТИКИ ПРАВИЛА ПРОВЕДЕНИЯ МЕТРОЛОГИЧЕСКОГО КОНТРОЛЯ В СИСТЕМЕ МИНИСТЕРСТВА СВЯЗИ И ИНФОРМАТИЗАЦИИ ПРАВІЛЫ ПРАВЯДЗЕННЯ МЕТРАЛАГIЧНАГА КАНТРОЛЮ Ў СIСТЭМЕ МIНIСТЭРСТВА СУВЯЗI I IНФАРМАТЫЗАЦЫI Издание официальное Минсвязи Минск ТКП 204 – 2009 УДК 389.1 МКС 13.020 КП 01 Ключевые слова: метрологический контроль, метрологические нормы и правила Предисловие Цели, основные принципы, положения по государственному регулированию и управлению в...»

«Виталий Петрович Леонтьев Компьютер. Настольная книга школьника Аннотация Книга призвана помочь школьнику в освоении курса информатики. Простым и доступным языком изложены все необходимые сведения о современных компьютерах, операционной системе Windows ХР, подробно раскрыты принципы работы с пакетом Microsoft Office. Большой раздел посвящен Интернету: досконально описано, как подключиться к Сети, быстро находить необходимую информацию, защищаться от вирусов и хакерских атак. Используя это...»

«Информационные технологии в образовании Ежеквартальный бюллетень №3 (7) Июль 2005 Координационного совета НГТУ по информатизации образования В этом выпуске: Телематика’2005 (О. В. Казанская). с. 2 Развитие научно-образовательной сети в Сибирском федеральном округе (Евг. Б. Гаврилов). с. 6 Оснащенность компьютерами рабочих мест преподавателей НГТУ: результаты исследования (Н. С. Фоменко).. с. 8 Научная электронная библиотека E-LIBRARY.RU (Т. В. Баздырева). с. 10 Новые издания ИДО НГТУ. с....»

«М И Н И СТЕРСТВО О БРА ЗО ВА Н И Я И Н А У КИ РО ССИ Й СКО Й Ф ЕДЕРА Ц И И Ф ЕДЕРА ЛЬН О Е А ГЕН СТВО П О О БРА ЗО ВА Н И Ю ГО СУ ДА РСТВЕН Н О Е О БРА ЗО ВА ТЕЛЬН О Е У ЧРЕЖ ДЕН И Е ВЫ СШ ЕГО П РО Ф ЕССИ О Н А ЛЬН О ГО О БРА ЗО ВА Н И Я Н О ВО СИ БИ РСКИ Й ГО СУ ДА РСТВЕН Н Ы Й ТЕХ Н И ЧЕСКИ Й У Н И ВЕРСИ ТЕТ Ф А КУ ЛЬТЕТ А ВТО М А ТИ КИ И ВЫ ЧИ СЛИ ТЕЛЬН О Й ТЕХ Н И КИ УТВЕРЖДАЮ Проректор по учебной работе НГТУ, проф. Ю.А.Афанасьев апреля 2006 г. РАБОЧАЯ ПРОГРАММА Концептуальные основы...»

«ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ ВОРОНЕЖСКИЙ ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ (ФГБОУ ВПО ВГТУ, ВГТУ) УТВЕРЖДАЮ Ректор ВГТУ _ В.Р. Петренко _ _ 20г.. Основная образовательная программа высшего профессионального образования Направление подготовки 220400 Управление в технических системах код, наименование направления подготовки (специальности) Квалификация выпускника: бакалавр бакалавр, магистр, специалист Профиль:...»

«Приложение 1 Государственное образовательное учреждение высшего профессионального образования Тобольский государственный педагогический институт им. Д.И. Менделеева Сведения по основным должностным лицам № Стаж работы Ученая Ученое п/п Фамилия, имя, отчество Должность Образование общий научно- в вузе степень звание педагог 1 Слинкин Сергей Викторович Ректор 27 25 19 к.ф/м.н доцент Московский пединститут, 2 Клюсова Виктория Викторовна Проректор по УР 15 15 15 к.п.н. доцент ТГПИ, 3 Коршун Тамара...»

«В серии: Библиотека ALT Linux Практикум по алгоритмизации и программированию на Python И. А. Хахаев Москва Альт Линукс 2011 УДК 004.432 ББК 22.1 Х27 Хахаев И. А. Х27 Практикум по алгоритмизации и программированию на Python: / И. А. Хахаев М. : Альт Линукс, 2011. 126 с. : ил. (Библиотека ALT Linux). ISBN 978-5-905167-02-7 Учебно-методический комплекс Практикум по алгоритмизации и программированию на Python предназначен для начального знакомства с основными алгоритмами и с программированием на...»

«А. Н. Горский БИОЭНЕРГОИНФОРМАТИКА Второе издание (Эзотерика, начальный курс) Санкт-Петербург 2012 УДК 615.8 ББК 53.59 Г67 Горский А.Н. Биоэнергоинформатика (Эзотерика, начальный курс)/ А.Н.Горский. – СПб.: Петербургский гос.ун-т путей сообщения, 2012. – 327с. ISBN 978-5-7641-0196-5 Книга содержит начальные знания по эзотерике. Рассмотрена энергоинформационная структура человека, дается описание тонких тел человека, такие вопросы как душа и Дух, аура, чакры, карма. С позиции эзотерики...»

«Министерство образования и науки Российской Федерации Владивостокский государственный университет экономики и сервиса _ ЛОГИСТИКА Практикум Владивосток Издательство ВГУЭС 2010 ББК 65.9(2) П 25 Пензина Т.Р. П 25 ЛОГИСТИКА [Текст]: практикум. – Владивосток: Изд-во ВГУЭС, 2010. – 48 с. Практикум по дисциплине Логистика составлен для проведения практических занятий и выполнения контрольных работ и в соответствии с учебной программой по дисциплине Логистика. Предназначен студентам по специальностям...»

«УДК 004.432 ББК 22.1 Х27 Хахаев И. А. Х27 Практикум по алгоритмизации и программированию на Python: / И. А. Хахаев М. : Альт Линукс, 2010. 126 с. : ил. (Библиотека ALT Linux). ISBN 978-5-905167-02-7 Учебно-методический комплекс Практикум по алгоритмизации и программированию на Python предназначен для начального знакомства с основными алгоритмами и с программированием на языке Python в интегрированных средах разработки (IDE) Geany и Eric. Комплекс состоит из учебного пособия, в котором...»

«И.В. Хмелевский, В.П. Битюцкий ОРГАНИЗАЦИЯ ЭВМ И СИСТЕМ ОДНОПРОЦЕССОРНЫЕ ЭВМ ЧАСТЬ 1 Федеральное агентство по образованию ГОУ ВПО Уральский государственный технический университет-УПИ И.В. Хмелевский, В.П. Битюцкий ОРГАНИЗАЦИЯ ЭВМ И СИСТЕМ ОДНОПРОЦЕССОРНЫЕ ЭВМ ЧАСТЬ 1 Конспект лекций Издание второе, исправленное и дополненное Научный редактор проф., д-р техн.наук Л.Г. Доросинский Екатеринбург 2005 УДК 681.3 ББК 32.973.202я73 Х-6 Рецензенты: кафедра информатики УГГУ (зав. кафедрой доц....»

«Министерство образования и науки Российской Федерации Южно-Российский государственный технический университет (Новочеркасский политехнический институт) ВРЕМЯ И ИНФОРМАЦИЯ (время в информатике/виртуальной реальности и в информационных процессах: философский, теоретический и практический аспекты) Сборник научных трудов Новочеркасск НОК 2011 1 УДК 115:00 ББК 87.21:72 В 81 Редакционная коллегия: В.С. Чураков (председатель редакционной коллегии), П.Д. Кравченко, Н.Е. Галушкин, А.М. Анисов, В.А....»






 
© 2014 www.kniga.seluk.ru - «Бесплатная электронная библиотека - Книги, пособия, учебники, издания, публикации»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.