Составные части инфологической модели

ФОНДОВАЯ ЛЕКЦИЯ

По дисциплине «Компьютерные технологии в экспертной деятельности»

Для обучающихся на 2 курсе по направлению подготовки (специальности) 031003.65 «Судебная экспертиза», (квалификация (степень) специалист).

Раздел I. Информационные системы в экспертной деятельности

Тема 1. «Системы управления базами данных»

Занятие № 1 «Общая характеристика информационных систем»

 

Обсуждена на заседании ПМС № 1

Протокол № 25

от ”12” июня 2013 года

 

ПОНЯТИЙНЫЙ АППАРАТ ИНФОРМАЦИОННЫХ СИСТЕМ (15 МИН)

 

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

Ба́за да́нных — представленная в объективной форме совокупность самостоятельных материалов (статей, расчётов, нормативных актов, судебных решений и иных подобных материалов), систематизированных таким образом, чтобы эти материалы могли быть найдены и обработаны с помощью электронной вычислительной машины (ЭВМ) (Гражданский кодекс РФ, ст. 1260).

Другие определения из авторитетных монографий и стандартов:

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

База данных — совокупность данных, хранимых в соответствии со схемой данных, манипулирование которыми выполняют в соответствии с правилами средств моделирования данных.[2]

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

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

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

 

СТРУКТУРА ИНФОРМАЦИОННОЙ СИСТЕМЫ (10 МИН)

 

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

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

Структуру двумерной таблицы образуют столбцы и строки. Их аналогами в структуре простейшей базы данных являются поля и записи.

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

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

Режимы работы с базами данных

Обычно с БД работают две категории исполнителей:

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

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

СУБД имеет два режима: проектировочный и пользовательский.

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

Объекты базы данных

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

Таблицы – основные объекты любой БД, в которых хранятся все данные, имеющиеся в базе, и хранится сама структура базы (поля, их типы и свойства).

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

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

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

Запросы и формы

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

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

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

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

СОДЕРЖАНИЕ И ПОРЯДОК СОЗДАНИЯ БАЗ ДАННЫХ

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

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

Такое представление уровней данных не единственное. Существуют и другие варианты многоуровневого представления данных. Так, в соответствии с предложениями исследовательской группы по системам управления данными Американского национального института стандартов ANSI/X3/SPARC, а также CODASYL (Conference on Data Systems Languages), как правило, выделяется три уровня представления данных:

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

§ концептуальный уровень (с точки зрения СУБД),

§ внутренний уровень (с точки зрения системного программиста).

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

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

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

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

Все внешние представления интегрируются на инфологическом уровне, где формируется инфологическая (каноническая) модель данных, которая не является простой суммой внешних представлений данных.

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

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

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

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

От параметров физической модели зависят такие характеристики функционирования БД: объем памяти и время реакции системы. Физические параметры БД можно изменять в процессе ее эксплуатации с целью повышения эффективности функционирование системы. Изменение физических параметров не предопределяет необходимости изменения инфологической и даталогической моделей.

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

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

Рис. 4.1. Схема взаимосвязи уровней представление данных в БД

Внешний уровень — подготовительный этап инфологического проектирования

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

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

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

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

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

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

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

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

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

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

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

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

Рис.4.2. Обобщенная схема процесса проектирование на внешнем уровне

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

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

Составные части инфологической модели

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

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

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

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

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

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

Требования и подходы к инфологическому проектированию

Целью инфологического проектирования есть создание структурированной информационной модели ПО, для которой будет разрабатываться БД. При проектировании на инфологическом уровне создается информационно-логическая модель (ИЛМ), которая должна отвечать таким требованиям:

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

§ корректность схемы БД, то есть адекватное отображение моделированной ПО;