ПО — программное обеспечение

ПО — программное обеспечение

ИО — информационное обеспечение

ТО — техническое обеспечение

Любая информационная система содержит ИО.

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

ПО – предметная область – набор объектов(объект), о котором собирается, хранится, обрабатывается информация.

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

На первых этапах создания АИУС(70-е годы), обычно информация об ОУ накапливалась и хранилась в виде массивов данных, причем отдельно создавались наборы массивов для каждой задачи (или ФП) – т.н. позадачный подход.

В дальнейшем, по мере увеличения объемов обрабатываемой информации, а так же вследствие наличия какой-то части данных, общих для разных ФП, в позадачном подходе выявились существенные недостатки:

- дублирование информации,

- расхождение одних и тех же данных, но в разных ФП

и т.д.

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

Основной подсистемой ИО является автоматизированный банк данных (АБД).

АСУП

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

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

Требования, предъявляемые к ИОСУ:

1. должна удовлетворять информационной потребности пользователя (ФП).

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

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

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

5. должна обеспечивать возможность реорганизации и расширения.

В результате изучения курса ИОСУ необходимо:

1. Знать особенности основных моделей представления данных и методов обработки данных.

2.Уметь использовать основные формальные модели представления данных при разработке фрагментов подсистем ИОСУ с использованием современных СУБД.

3.Преобрести навыки использования моделей денных и средств СУБД:

- FOXPRO,

- ACCESS,

- DELPHI.

 

Тема 2. Информационные системы. Основные понятия.

Информация и данные.

2.1.1. Сигналы и данные.

 

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

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

 

Данные и методы.

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

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

Данные – это ещё не информация.

 

Понятие об информации.

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

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

Информация – это продукт взаимодействия данных и адекватных им методов в момент ее образования.

Клиент – 1 сервер.

2) много клиентов – 1 сервер.

3) несколько клиентов и несколько серверов.

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

Рассмотрим некоторые варианты моделей клиент-сервер.

 

Модель сервера БД.

 

Такую модель поддерживает большинство современных СУБД: SYSBASE, ORACLE, MS SQL SERVER. Основу такой модели составляют т.н. хранимые процедуры, как средства программирования SQL-сервера, а так же механизм «триггеров», используемые для отслеживания состояния и приведения в нужное состояние информационного хранилища. Такая модель называется моделью активного сервера БД(рис. 2.6.3.1.2.).

Рис. 2.6.3.1.2. Модель активного сервера БД.

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

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

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

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

Жизненный цикл ИС.

ИО любой системы управления(АСУ, АСУТП, АИС) является необходимым компонентом этих систем, а поэтому жизненный цикл всей АИС совпадает с жизненным циклом подсистемы ИО.

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

1. разработка технического задания

2. проектирование

3. реализация проекта

4. эксплуатация созданного проекта или системы.

Данные 4 стадии разбиваются на ряд этапов:

Рис. 3.1.1. Этапы жизненного цикла ИО АИС.

 

1 – планирование разработки,

2 – анализ предметной области (ОУ) и определенных требований к ИО(ИС),

3 – концептуальное проектирование,

4 – логическое проектирование,

5 – физическое проектирование,

6 – выбор СУБД,

7 – разработка приложений,

8 – реализация приложений,

9 – загрузка данных,

10 – тестирование системы,

11 – эксплуатация и сопровождение системы.

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

 

Планирование разработки.

Она включает подготовку действий, в результате которых должны быть определены:

1. необходимый объем работ.

2. необходимые ресурсы

3. предварительная общая стоимость проекта.

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

Суть состоит в постановке таких задач, как:

1. определение цели функционирования и развития объекта управления или бизнес-плана ОУ.
2. оценка показателей уже существующих ИС с точки зрения их вклада в эффективность функционирования данного ОУ.
3. оценка использования новых информационных технологий для достижения более эффективного функционирования ОУ.

 

3.1.2. Анализ предметной области (ПО) и определение требований к ИС(ИО).

 

Для этого необходимо:

1. определить саму предметную область и границы приложений данной ИС.

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

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

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

 

Проектирование ИС.

Общими требованиями при проектировании ИС являются:

1. необходимость представления данных о предметной области всем потребителям в соответствие с их полномочиями.

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

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

В настоящее время всё большее распространение получает методология проектирования ИС, базирующаяся на 3-х этапах:

1. концептуальное проектирование.

2. логическое проектирование.

3. физическое проектирование.

 

Выбор СУБД.

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

Общий список параметров включает:

1. физические параметры:

предусмотрены ли файловые структуры в данной СУБД;

наличие средств индексирования;

наличие средств сжатия данных;

возможность шифрования данных;

требуемые объемы ОЗУ и ПЗУ для данной СУБД и т.д.

2. параметры определения данных:

тип базовой модели организации данных;

наличие поддержки в расширении первичных ключей;

наличие средств поддержки целостности данных;

предусмотренные типы данных;

3. общие параметры:

стоимость СУБД;

требуемая ОС для СУБД;

рейтинг производителя для данной СУБД;

наличие поддержки работы СУБД в Internet;

производительность данной СУБД;

и т.д.

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

возможности языка запросов;

наличие многопользовательского доступа;

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

и т.д.

5. группа параметров, описывающих средства технологии разработки ИС:

наличие инструментов для работы с оконным интерфейсом;

наличие case-инструментов;

и т.д.

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

 

Разработка приложений.

Цель разработки приложений заключается:

1. создание проекта транзакций

2. создание проекта интерфейса пользователя.

 

Проектирование транзакций.

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

Обычно транзакция выполняется частично персоналом АИС, а частично ПП или самой СУБД.

Основные типы транзакций:

1. транзакции извлечения – действия, обозначающие выборку данных из базы

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

3. смешанные транзакции

При проектировании транзакций необходимо определить и задокументировать характер(свойства) всех транзакций, которые будут реализовываться в АИС. В их числе:

1. исходные данные, которые использует транзакция;

2. выходные данные, формируемые транзакцией;

3. функциональные характеристики транзакций;

4. степень важности транзакции для пользователя;

5. предполагается интенсивность использования данной транзакции.

 

Реализация.

Цель этого этапа состоит в физической реализации БД и разработке приложений.

1. Реализуется БД посредством описания ее компонент на языке описания данных(ЯОД) используемого в данной конкретной СУБД. Команды ЯОД далее компилируются и используются для создания схем пустых БД.

2. Реализуются приложения(ПП). При этом разработка фрагментов программ может осуществляться либо с использованием языка манипулирования данными, ЯМД, конкретной СУБД, либо с использованием универсальных языков программирования(С++, АДА, Visual Basic? Visual FoxPro и т.д.).

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

4. Реализуются средства защиты данных базы и средства поддержки целостности БД.

 

Тестирование.

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

 

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

Создание локальных концептуальных инфалогических моделей(моделирование локальных представлений) - ЛКИМД(ЛКМД).

 

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

Рис. 3.3.2.1. Условные отображения фрагментации ПО при создании КИМ.

 

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

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

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

Выбор фрагментов (локальных представлений) зависит:

-Во-первых, от характера и масштаба ПО;

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

Для каждого ЛПР (каждой ЛКМД) необходимо:

-сформировать (выделить) набор сущностей требуемых для объективного описания этого фрагмента ПО и атрибуты этих сущностей;

- сформировать (выделить) основные связи между выбранными сущностями;

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

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

Примеры построения ЛКМД.

1. Построить ЛКМД для реализации функции назначения стипендии в рамках АИС Университета. В качестве выбранных сущностей(рис. 3.3.2.1.):

1) студенты группы (контингент) – ФИО, номер группы, форма обучения.

2) Успеваемость студентов группы (сводная ведомость) – ФИО, оценка по П1, оценка по П2…

3) Стипендия (стипендиальный протокол) – ФИО, тип успеваемости(о, о-х, с х, у, н), размер стипендии.

Рис. 3.3.2.2.

 

2. В качестве примера ЛКМД, рассмотрим сущности и их взаимосвязь для учебного процесса (для АИС университета или факультета). Первая фаза концептуального

- выделение сущностей и связей.

В качестве сущностей можно выделить:

-преподаватель (ключ-номер преподавателя, ФИО …);

-занятие(ключ-группа, предмет …);

-стаж (ключ-стаж в годах….);

-должность (ключ- должность);

В качестве связей можно выделить:

-преподаватель ИМЕЕТ стаж;

- преподаватель ВЕДЁТ занятие;

- преподаватель ЗАНИМАЕТ должность;

Вторая фаза - построение диаграммы ER-типа.

Рис.3.3.2.3. Диаграмма ER-типа.

 

Диаграммы ER-типа для рассматриваемого примера приведена на рис. 3.3.2.3.

1. Связь ИМЕЕТ является связью типа М:1, т.к. одинаковый стаж могут иметь несколько преподавателей. Сущность “Преподаватель” имеет обязательный КП, поскольку каждый преподаватель имеет свой стаж.Сущность “Стаж” имеет необязательный КП, т.к. возможны такие значения стажа, которые не имеет не один из преподавателей.

2. Связь ВЕДЁТ имеет тип М:М, т.к. при условии что, преподаватель может вести несколько занятий, а каждое занятие может проводится несколькими преподавателями, т.е. занятие может быть лекционным, практическим, лабораторным, проводимым преподавателем в учебной группе по одной из дисциплин.

Обе сущности в данной связи имеют КП обязательный, в предположении, 1)что нет преподавателей, которые не проводят занятий, и 2)нет занятий, которые не обеспечены преподавателями.

3. Связь “Занимает” имеет тип М:1, т.к. каждый преподаватель занимает определённую должность и одинаковые должности могут занимать несколько преподавателей. Сущность “Преподаватель” имеет обязательный КП, т.к каждый преподаватель занимает какую-либо должность. Сущность “Должность” имеет необязательный КП, т.к. не исключено, что на кафедре, например, отсутствует должность профессора (например, на кафедре физвоспитания).

В конкретных проектах целесообразно диаграммы ER-типа дополнять диаграммами ER-Э.

 

Вводная часть.

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

1. на базе ЛКМД строится локальные логические модели данных(ЛКМД->ЛЛМД),

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

2. осуществляется слияние ЛЛМД в ГЛМД с использованием различных методов интеграции.

 

Удаление связей типа N:M.

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

 

Рис 3.4.2.1.1.1.

Рассмотрим на примере удаления связи типа N:M.

Рис 3.4.2.1.1.2

Для устранения связи M:N в данном случае выделим промежуточную сущность «специальность» и создадим две новые связи(две новые диаграммы ER-типа).

Рис 3.4.2.1.1.3

 

Правило 5.

Если степень связи 1:М (М:1) и КП М-связной сущности является необязательным, то необходимо формирование трех отношений (Рис 3.4.2.2.18,19). Два объектных отношения соответствуют связываемых сущностям, ключ которых является первичным в этих отношениях. Третье отношение являются связным между первыми двумя (его ключ объединяет ключевые атрибуты связываемых отношений).

 

Рис 3.4.2.2.18 Диаграмма ER-типа и схема отношений для правила 5.

В результате применения правила 5 к исходным диаграммам (Рис 3.4.2.2.16) и исходному отношению (Рис 3.4.2.2.17) содержащиеся в них данные формируются в трех отношениях (Рис 3.4.2.2.19)

Рис 3.4.2.2.19 Отношения, полученные по правилу N5

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

Подчеркиваю, что определяющим фактором при выборе между 4 и 5 правилами является КП М-связным сущности.

 

Пример формирования отношений исходя из структуры ЛЛМД.

Как уже отмечалось было разработана ЛЛМД фрагмента, отображающего отдельный аспект учебной части ВУЗа. Диаграмма ER-типа для такой ЛЛМД представлена на Рис 3.4.2.2.23

Рис 3.4.2.2.23 Диаграмма ER-типа учебной части ВУЗа

 

Связь “ ИМЕЕТ ” является связью типа М:1, т.к. одинаковый стаж могут иметь несколько преподавателей. Сущность “Преподаватель” имеет обязательный КП, т.к. каждый преподаватель имеет свой стаж. Сущность “стаж” имеет необязательный КП, т.к. возможны такие значения стажа, которые не имеют ни один из преподавателей.

Связь “ ВЕДЕТ ” имеет тип М:М, т.к. Пр-ль может вести несколько занятий, а каждое занятие может преподаваться несколькими преподавателями. Занятие, проводимое преподавателями по одной из дисциплин, может быть лекционным, практическим, лабораторным и т.д. Обе сущности в данной связи имеют обязательный КП, в предположении, что нет преподавателей, которые не проводят занятий, и нет занятий, которые не обеспечены преподавателями.

Связь “ЗАНИМАЕТ ” имеет тип М:1, так как каждый Пр-ль занимает определенную должность и одинаковые должности могут занимать несколько преподавателей. Сущность “Пр-ль” имеет обязательный КП, т.к. каждый пр-ль занимает должность. Сущность “Должность” имеет необязательный КП, т.к. напротив возможно отсутствие какой-либо должности профессора на кафедре (например, “профессор”).

На основе анализа диаграмм ER-типа (Рис 3.4.2.2.23) с помощью 6-ти сформированных правил получаем набор предварительных отношений, представленных следующими схемами отношений.

1. Связь “ИМЕЕТ”удовлетворяет условиям правила 4, в соответствии с которым получаем 2 (два) отношения:

ПРЕПОДАВАТЕЛЬ (ФИО, СТАЖ,…)-добавился ключевой атрибут СТАЖ.

СТАЖ (СТАЖ,…)

2. Связь “ВЕДЕТ” удовлетворяет условиям правила 6, в соответствии с которым получаем 3 (три) отношения:

ПРЕПОДАВАТЕЛЬ (ФИО, СТАЖ,…)

ЗАНЯТИЕ (ГРУППА, ПРЕДМЕТ…)

ВЕДЕТ (ФИО, ГРУППА, ПРЕДМЕТ,…)

3. Связь “ЗАНИМАЕТ” аналогично связи “ИМЕЕТ” удовлетворяет условиям правила 4, поэтому имеет следующие 2 (два) отношения.

3.1 ПРЕПОДАВАТЕЛЬ (ФИО, СТАЖ, ДОЛЖНОСТЬ,…)

Добавится ключевой атрибут должность.

3.2 ДОЛЖНОСТЬ (ДОЛЖНОСТЬ,…)

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

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

ПРЕПОДАВАТЕЛЬ (ФИО, СТАЖ, ДОЛЖНОСТЬ, КАФЕДРА…)

СТАЖ (СТАЖ, Д _СТАЖ)

ЗАНЯТИЕ (ГРУППА, ПРЕДМЕТ…)

ВЕДЕТ (ФИО, ГРУППА, ПРЕДМЕТ,ВИД.ЗАНЯТИЯ…)ДОЛЖНОСТЬ (ДОЛЖНОСТЬ, ОКЛАД…)

Схема базы данных для данных отношений представлена на Рис 3.4.2.2.24.

 

Рис 3.4.2.2.24. Схема базы данных

 

 

Замечание:

В рассматриваемом примере отношение “Занятие”, кроме ключевых атрибутов (Группа, Препод.), других атрибутов не имеет. Поэтому оно не несет дополнительной информации, кроме содержащейся в отношении “ВЕДЕТ”. Поэтому отношение “ЗАНЯТИЕ” можно исключить из формируемой схемы базы данных. Если бы имелись другие атрибуты, например атрибут “СЕМЕСТР”, в котором некоторая группа изучает конкретную дисциплину, то получили бы отношение занятие (группа, Предмет, семестр), которое вошло бы в Базу Данных. Ключевые атрибуты (Стаж и должность) из отношений “СТАЖ” и “ДОЛЖНОСТЬ” входят как внешние ключи в отношение “ПРЕПОДАВАТЕЛЬ”. Ключевой атрибут “ФИО” входит как часть составного ключа в отношение “ВЕДЕТ”.

 

Создание и проверка ГЛМД.

Цель этого подэтапа – объединение ЛЛМД в единую ГЛМД, представляющую собой либо всю предметную область, либо ту часть ПО, которая охватывается данным приложением.

Этот подэтап имеет следующие фазы:

1. слияние ЛЛМД в ГЛМД(ф.1)

2. проверка ГЛМД (ф.2)

3. создание окончательного варианта диаграммы «Сущность-Связь»(фаза 3).

Рассмотрим коротко эти фазы.

Проверка ГЛМД (фаза 2).

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

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

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

 

3.4.3.3, Создание окончательного варианта глобальной диаграмы Сущность-Связь (ГЛМД) (фаза 3).

Цель этой фазы – создание окончательного варианта ER-Диаграммы, отображающей всю предметную область в виде ГЛМД. Эта фаза может быть выполнена после проверки созданной ГЛМД. В результате этой фазы создается документация (ER-Д, схемы отношений, словарь данных), которая отражает всю ПО и в которой согласованы и устранены все противоречия, возможные и выявленные при объединении ЛЛМД.

 

 

ТЕМА 4.Модель данных. Реляционная модель данных.

 

Модель данных общие понятия

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

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

Определение1. Модель данных-это интегрированный набор правил для описания:

1. Самих данных;

2. Связей между ними;

3. Ограничений накладываемых на данные в данной предметной области.

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

Важно различать:

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

В рамках 3-х уровневой архитектуры базы данных, обычно выделяются 3(три) взаимосвязанные модели данных:

- Инфологические модели

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

-физические модели

Упрощенно соответствие разных моделей, этапов проектирования и уровней представления представлены на рис 4.1

Рис 4.1.1.

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

 

Датологические модели - используются на этапе логического проектирования, а также на 1-ом этапе физического проектирования. Эти модели позволяют на основе КИМ создавать описание ПО с учетом ТИПА СУБД, предполагаемой для использования в АИС.

 

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

 

 

На рис 4.2 Представлена классификация разновидностей этих 3- типов модели

 

 

 

4.1.2 Классификация моделей данных

 

РМД предложена сотрудниками фирмы IBM Эдгаром Коддом и основывается на понятии ОТНОШЕНИЕ (relation).

Определение: Отношение представляет собой множество кортежей, каждый из которых описывает экземпляр сущности и их связи и состоит из элементов (Элементы соответствуют атрибутам отношения).

Наглядной формой представления отношения является двумерная таблица.

Таблица имеет строки (записи) и столбцы (колонки). Каждая строка таблицы имеет одинаковую структуру и состоит из полей. Строкам таблицы соответствуют кортежи, а столбцам - атрибуты отношения. Например: таблица может содержать сведения о группе обучаемых, о каждом из которых известны следующие характеристики: Фамилия, Имя, Отчество, пол, возраст, образование. Поскольку в рамке одной таблицы не удается описать более сложные логические структуры данных о предметной области, применяют СВЯЗЫВАНИЕ таблиц (связные отношения).

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

Недостаток РМД- отсутствие стандартных средств идентификации отдельных записей и сложность описания иерархических и сетевых связей. Примеры реляционных СУБД: (Paradox (Borland). FOXPRO, Visual FOXPRO, ACCES (Microsoft). Oracle (oracle). Ingress и т.д.)

Нормализация отношений.

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

 

1-ая нормальная форма имеет место, если все его атрибуты простые или атомарные.

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

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

Пример:

R1
Табельный номер	Фам	Оклад	Комната	Телефон	Дети
Имя	Возраст
	Иванов	450 р.			Женя Оля
	Темкин	470 р.			Саша
	Кошкин	240 р.			Олег Женя

 

Последний атрибут в данном исходном отношении является сложным и для перехода в 1 н.ф. это отношение должно быть преобразовано. Осуществл