Лекции по "Информационные системы"

     

     Рис. 2 

     

     Рис. 3

           АД, повторяющийся  компонент которого является просто ЭД, называется вектором. АД, компонент которого представлен совокупностью данных (рис. 4), называется повторяющейся группой.

           

     Рис. 4

           Запись - поименованная совокупность ЭД и агрегатов. Запись это АД, не входящий в состав никакого другого АД. Запись может иметь сложную иерархическую структуру, так как допускается многократное применение агрегации.

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

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

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

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

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

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

     “имя  атрибута_оператор условия_значение атрибута”

     оператор  условия: =, >, <, На основе простых условий можно построить булевы: AND, OR, NOT, например

     ОБРАЗОВАНИЕ = высшее AND СТАЖ 1.

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

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

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

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

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

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

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

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

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

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

Модель  “сущность - связь”

Модель  “сущность - связь” (МСС) (entity - relation diagram - ERD) является неформальной моделью предметной области (ПО) и используется на этапе инфологического проектирования БД. Моделируются объекты ПО и их взаимоотношения.

Достоинства МСС:

• относительная простота;
• однозначность;
• применение естественного языка;
• доступность для понимания.

Основное  назначение МСС - семантическое описание ПО и представление информации для обоснования выбора видов моделей и структур данных, которые в дальнейшем будут использованы в информационной системе.

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

“Время” в составе конструктивных элементов  отсутствует, но может быть представлено в модели посредством атрибутов (напр.: ГОД-РОЖДЕНИЯ-ПОЛУЧЕНО-В-ИЮНЕ,...).

Сущность - собирательное понятие, некоторая абстракция реально существующего объекта, процесса или явления, о котором необходимо хранить информацию в системе.  
 
 

Примеры сущностей:

В моделях  МСС каждая рассматриваемая сущность является основным местом сбора информации об этой сущности.

“Тип сущности” определяет множество однородных объектов, а “экземпляр сущности” - конкретный объект из множества.

Каждая  сущность должна иметь имя. Например, сущность "СТУДЕНТ".

“Атрибут” (А) - поименованнная характеристика сущности. При помощи атрибутов моделируются свойства сущностей: (сущность: КНИГА, атрибуты: НАЗВАНИЕ, АВТОР, ГОД-ИЗДАНИЯ).

Основная  роль атрибутов - описание свойств сущности. Другая роль - идентификация экземпляра сущности. То есть каждый экземпляр  сущности должен иметь уникальное имя. В качестве имени выступает один или несколько атрибутов. Например, "НОМЕР ЗАЧЕТНОЙ КНИЖКИ" или "НОМЕР" и "СЕРИЯ ПАСПОРТА".

“Связь” - средство представления отношений между сущностями в модели ПО. Тип связи рассматривается между типами сущностей, например, между сущностями СТУДЕНТ и ГРУППА может быть связь УЧИТЬСЯ. То есть введение связи между двумя сущностями отражает семантику некоторого предложения. В данном случае, это СТУДЕНТ УЧИТСЯ В ГРУППЕ. Конкретный экземпляр связи данного типа существует между конкретными экземплярами данных типов сущностей. Например, ИВАНОВ УЧИТСЯ КМ-31.

В модели "сущность-связь" поддерживаются бинарные связи. В общем  случае в ПО могут быть n - арные  связи между сущностями.

Построение  глобальной инфологической модели

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

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

• Поскольку локальные модели разрабатывались автономно, то после семантического (смыслового) анализа необходимо устранить синонимы и омонимы путем переименования атрибутов, связей и сущностей.
• Более общее представление поглощает менее общее Например, в одной ЛИМ "начальник отдела" может существовать как атрибут сущности "отдел", а в другой ЛИМ как экземпляр сущности "сотрудник". В этом случае атрибут удаляется, а устанавливается связь "быть начальником" между сущностями "отдел" и "сотрудник". Два локальных представления одной и той же сущности в глобальной модели объединяются с сохранением полного множества атрибутов. Так представления сущности "студент" для деканата и поликлиники отличаются. В глобальной модели, естественно будет одна сущность "студент" с полным набором атрибутов;
• Устраняются возникшие в результате объединения композиции связей;
• Обобщаются ограничения целостности и бизнес-правила;
• Проводится нормализация глобальной модели;
• Корректируются локальные модели в соответствии с глобальной.

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

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

Итак, проектировщики баз данных должны помнить:

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