1.2. Описание предметной области
В управленческой, экономической, финансовой, правовой сферах широко используется информация, представляющая собой неструктурированную информацию (помимо структурированной информации, организованной в БД, находящихся под управлением СУБД). Информационные ресурсы представляют собой отдельные документы и отдельные массивы документов в информационных системах (библиотеках, архивах, фондах, банках данных, других видах информационных систем). К ним относятся рукописные, печатные и электронные издания, содержащие нормативную, распорядительную, фактографическую, справочную, аналитическую и др. информацию по различным направлениям общественной деятельности (законодательство, политика, демография, социальная сфера, наука, техника, технология и т.д.).
Для однопользовательских АС характерно использование следующих баз данных:
локальные реляционные базы данных, находящиеся под управлением одной или нескольких СУБД (Microsoft Access, FoxPro и т.п.) и предназначенные для решения пользователем прикладных задач с использованием собственного или покупного специального программного обеспечения на его АРМе;
локальные базы неструктурированной информации (текстовых и табличных документов, созданных пользователем средствами Microsoft Word и Microsoft Excel, полученных по электронной почте, на машинных носителях, а также документов, полученных в результате решения пользователем прикладных задач с использованием информации реляционных баз данных), организованные и хранящиеся в виде каталогов и подкаталогов на его АРМе;
базы данных, размещенные на удаленных ПК в федеральных и международных сетях, к которым организован доступ самим пользователем со своего АРМ (если АРМ подключен к федеральным и международным сетям передачи данных).
Современные автоматизированные информационные системы представляют собой, как правило, ЛВС, подключенные к федеральным и международным сетям передачи данных. Пользователь ЛВС использует не только вышеперечисленные локальные базы данных, но и распределенные:
реляционные базы данных на сервере ЛВС, находящиеся под управлением одной или нескольких СУБД;
базы неструктурированной информации (документов, созданных и полученных разными пользователями ЛВС), организованные и хранящиеся в виде каталогов и подкаталогов на сервере ЛВС;
базы данных различных приобретенных АС, установленные в ЛВС и доступные всем пользователям сети;
базы данных, размещенные на удаленных ПК в федеральных и международных сетях, к которым организован доступ для всех пользователей ЛВС.
Значительная часть неструктурированной информации в вышеназванных базах является, как правило, гипертекстовыми и гипермедиа-документами, объединенными с помощью гиперссылок в гипертекстовые базы данных.
В последние годы находят все более широкое применение так называемые геоинформационные системы. Геоинформационные системы (ГИС)–это интегрированные в единой информационной среде электронные пространственно-ориентированные изображения (карты, схемы, планы и т.п.) и базы данных (БД). В качестве БД могут использоваться таблицы, паспорта, иллюстрации, расписания и т. п. Такая интеграция значительно расширяет возможности системы и позволяет упростить аналитические работы с координатно-привязанной информацией. Принципиальным отличием ГИС является наличие в них картографических данных местности, региона и т.д., к которым привязывается остальная информация системы. Геоинформационные системы уже широко используются в управлении градостроительством, транспортом, природными ресурсами и т.п.
Для современного этапа развития информационных технологий характерно наличие разнообразных инструментальных средств и покупного специального программного обеспечения, которыми может овладеть любой пользователь, а также наличие большого количества промышленно функционирующих БД коммерческих организаций, органов государственной власти и местного самоуправления, предприятий и организаций.
Такая ситуация позволяет при создании многих АС отказаться от проектирования и разработки собственных реляционных баз данных и собственного специального программного обеспечения. Использование современных инструментальных средств позволяет пользователю самостоятельно (без помощи системного программиста) организовывать со своего АРМ доступ к различным информационным ресурсам, например, создавать каталоги нормативно-правовых актов, каталоги адресов WWW-серверов Интернета и т.п. Появление ОПО последних версий позволяет пользователю организовывать доступ к различным ресурсам АРМ и ЛВС через гиперссылки (по принципу “паутины”) взамен иерархического принципа доступа (принципа “дерева”).
Распределенная система организации баз данных предполагает наличие соответствующей технологии доступа пользователей к информационным ресурсам, ориентированной, прежде всего, на вычислительные модели типа "клиент-сервер".
Технология "клиент-сервер" предполагает разделение функций обработки данных на три группы: функции ввода/вывода и отображения данных; прикладные функции, характерные для данной предметной области; функции хранения и управления данными. Каждая группа функций выполняется отдельным логическим компонентом.
Различия в реализации приложений в рамках "клиент-сервер" определяются механизмом использования и распределения между компьютерами в сети этих компонент, в соответствии с этим выделяют три подхода, реализованные в моделях:
модель доступа к удаленным данным (Remote Data Access-RDA), в которой компонент представления и прикладной компонент совмещены и выполняются на одном компьютере. Запросы к информационным ресурсам направляются по сети к удаленному компьютеру, который обрабатывает запросы и возвращает блоки данных. Эта модель является самой простой и традиционно используется в локальных вычислительных сетях, где скорость обмена достаточно высока, однако она неприемлема при работе в среде низкоскоростных каналов передачи данных. Поскольку вся логика локализована на одном компьютере, то приложение нуждается в передаче по сети большого, часто избыточного объема данных, что существенно повышает загрузку информационной системы в целом и может привести к длительному блокированию данных от других пользователей;
модель сервера базы данных (DataBase Server-DBS), которая строится в предположении, что процесс, выполняемый на компьютере-клиенте, ограничивается функциями представления, в то время как собственно прикладные функции реализованы в хранимых непосредственно в базе данных процедурах, выполняющихся на компьютере-сервере БД. Преимущества DBS-модели перед RDA заключаются в очевидном снижении сетевого трафика. Однако DBS-модель не обеспечивает требуемой эффективности использования вычислительных ресурсов в случае нескольких серверов;
модель сервера приложений (Application Server-AS), в которой процесс, выполняющийся в компьютере-клиенте, реализует функции первой группы. Прикладные функции выполняются на удаленном компьютере. Доступ к информационным ресурсам, необходимым для решения прикладных задач, обеспечивается тем же способом, что и в RDA модели. AS-модель не требует обеспечения миграции прикладных функций между серверами, что значительно облегчает администрирование системы в целом, однако, для обеспечения достаточной скорости обработки данных сервер приложений и сервер БД должны находится в одной ЛВС или быть соединены по выделенному каналу.
На практике часто для создания более гибких и динамичных систем используются смешанные модели.
Компьютер-клиент и компьютер-сервер могут работать в условиях ЛВС и быть абонентами глобальной компьютерной сети, общаясь между собой по организуемому виртуальному каналу или, используя для этого (при снижении требований на реактивность системы) электронную почту.
В настоящее время существует целый ряд программных средств, как системных, так и прикладных, реализующих описанные выше модели. Стоит отметить такие пакеты, как Oraclе SQL Server и Sybase SQL Server для платформы NetWare, продукт Microsoft Windows NTSQL Server, Oracle для среды Unix, Lotus Notes. Все эти программные средства работают на различных платформах (на машинах с процессорами Intel, на RISC-серверах и станциях производства HP, DEC и т.д.), в различных операционных средах. СУБД Oracle выделяется среди прочих исключительным быстродействием, мощными сетевыми средствами и средствами межплатформенной связи. Развитые средства электронной почты пакета Oracle позволяют организовать безбумажный документооборот, совместную подготовку и обработку документов. Существует интегрированный программный продукт ORACLE 2000WG, объединяющий достоинства популярной сетевой операционной системы Novell NetWare и СУБД Oracle. В структурах управления федеральных, государственных и местных органов власти все шире применяется пакет Lotus Notes.
Инфологическая модель отображает реальный мир в некоторые понятные человеку концепции, полностью независимые от параметров среды хранения данных. Существует множество подходов к построению таких моделей: графовые модели, семантические сети, модель "сущность-связь" и т.д. Наиболее популярной из них оказалась модель "сущность-связь" или называемая ещё ER-моделью (от англ. Entity-Relationship, т.е. сущность-связь).
Инфологическая модель применяется после словесного описания предметной области.
Проведем анализ предметной области проектируемой БД.
Пользователи |
Код пользователя |
Логин |
Пароль |
Примечание |
Права пользователя |
Код доступа |
Права |
Сеанс |
Код сеанса |
Код пользователя |
Код доступа |
Номер сеанса |
Время начала |
Время окончания |
Как любая модель, модель «сущность-связь» имеет несколько базовых понятий, которые образуют исходные кирпичики, из которых строятся уже более сложные объекты по заранее определенным правилам.
Эта модель в наибольшей степени согласуется с концепцией объектно-ориентированного проектирования, которая в настоящий момент, несомненно, является базовой для разработки сложных программных систем, поэтому многие понятия вам могут показаться знакомыми, и если это действительно так, то тем проще вам будет освоить технологию проектирования баз данных, основанную на ER-модели.
Сущность, с помощью которой моделируется класс однотипных объектов. Сущность имеет имя, уникальное в пределах моделируемой системы. Так как сущность соответствует некоторому классу однотипных объектов, то предполагается, что в системе существует множество экземпляров данной сущности. Объект, которому соответствует понятие сущности, имеет свой набор атрибутов – характеристик, определяющих свойства данного представителя класса. При этом набор атрибутов должен быть таким, чтобы можно было различать конкретные экземпляры сущности.
Рассмотрим сущности БД на примере исследуемой предметной области.
Между сущностями могут быть установлены связи – бинарные ассоциации, показывающие, каким образом сущности соотносятся или взаимодействуют между собой. Связь может существовать между двумя разными сущностями или между сущностью и ей же самой (рекурсивная связь). Она показывает, как связаны экземпляры сущностей между собой. Если связь устанавливается между двумя сущностями, то она определяет взаимосвязь между экземплярами одной и другой сущности.
Определим связи между выявленными сущностями.
Связь ОДИН-КО-МНОГИМ (1:М): одному представителю сущности А соответствуют 0, 1 или несколько представителей сущности В.
В разных нотациях мощность связи изображается по-разному. Между двумя сущностями может быть задано сколько угодно связей с разными смысловыми нагрузками. Связь любого из этих типов может быть обязательной, если в данной связи должен участвовать каждый экземпляр сущности, необязательной – если не каждый экземпляр сущности должен участвовать в данной связи. При этом связь может быть обязательной с одной стороны и необязательной с другой стороны. Обязательность связи тоже по-разному обозначается в разных нотациях. Мы снова используем нотацию POWER DESIGNER. Здесь необязательность связи обозначается пустым кружочком на конце связи, а обязательность перпендикулярной линией, перечеркивающей связь. И эта нотация имеет простую интерпретацию. Кружочек означает, что ни один экземпляр не может участвовать в этой связи. А перпендикуляр интерпретируется как то, что, по крайней мере, один экземпляр сущности участвует в этой связи.
Сущность имеет имя, уникальное в пределах модели. При этом имя сущности – это имя типа, а не конкретного экземпляра.
Сущности подразделяются на сильные и слабые. Сущность является слабой, если ее существование зависит от другой сущности – сильной по отношению к ней.
Сущность может быть расщеплена на два или более взаимоисключающих подтипов, каждый из которых включает общие атрибуты и/или связи. Эти общие атрибуты и/или связи явно определяются один раз на более высоком уровне. В подтипах могут определяться собственные атрибуты и/или связи. В принципе выделение подтипов может продолжаться на более низких уровнях, но в большинстве случаев оказывается достаточно двух-трех уровней.
Связи делятся на три типа по множественности: один-ко-одному (1:1), один-ко-многим (1:М), многие-ко-многим (М:М).
Связь один-ко-одному означает, что экземпляр одной сущности связан только с одним экземпляром другой сущности.
Связь один-ко-многим (1:М) означает, что один экземпляр сущности, расположенный слева по связи, может быть связан с несколькими экземплярами сущности, расположенными справа по связи.
Связь «многие-ко-многим (М:М) означает, что несколько экземпляров первой сущности могут быть связаны с несколькими экземплярами второй сущности, и наоборот. Между двумя сущностями может быть задано сколько угодно связей с разными смысловыми нагрузками.
Процесс проектирования БД на основе принципов нормализации представляет собой последовательность переходов от неформального словесного описания информационной структуры предметной области к формализованному описанию объектов предметной области в терминах некоторой модели.
Инфологическая модель применяется на втором этапе проектирования БД, то есть после словесного описания предметной области. Процесс проектирования длительный и требует обсуждений с заказчиком и со специалистами в предметной области. Наконец, при разработке серьезных корпоративных информационных систем проект базы данных является тем фундаментом, на котором строится вся система в целом, и вопрос о возможном кредитовании часто решается экспертами банка на основании именно грамотно сделанного инфологического проекта БД. Следовательно, инфологическая модель должна включать такое формализованное описание предметной области, которое легко будет «читаться» не только специалистами по базам данных. И это описание должно быть настолько емким, чтобы можно было оценить глубину и корректность проработки проекта БД, и конечно, оно не должно быть привязано к конкретной СУБД. Выбор СУБД – это отдельная задача, для корректного ее решения необходимо иметь проект, который не привязан ни к какой конкретной СУБД.
Инфологическое проектирование прежде всего связано с попыткой представления семантики предметной области в модели БД. Реляционная модель данных в силу своей простоты и лаконичности не позволяет отобразить семантику, то есть смысл предметной области.
1. Бекаревич Ю.Б., Пушкина Н.В. Самоучитель Microsoft Access 2002. – СПб.: БХВ-СПб., 2003. – 720 с.
2. Виноградова И.А., Грибова Е.А., Зубков В.Г. Практикум на ЭВМ. MS Access: Учебное пособие для студентов заочной (дистанционной) формы обучения. – М.: ГИНФО, 2000. – 124 с.
3. Голицина О.Л., Максимов Н.В., Попов И.И. Базы данных: Учебное пособие. – М.: ФОРУМ: ИНФРА-М, 2003. – 352 с.
4. Информатика. Базовый курс. /Под ред. С.В.Симоновича. – СПб.: Питер, 1999. – 640 с.
5. Карпова Т.С. Базы данных: модели, разработка, реализация. – СПб.: Питер, 2002. – 304 с.
6. Петров В.Н. Информационные системы. – СПб.: Питер, 2003. – 688 с.
7. Тихомиров Ю.В. MS SQL Server 2000: разработка приложений. – СПб.: БХВ-Петербург, 2000. – 368 с.
... сущностей реализуется с помощью отношения. Мощность связи – один-ко-многим (1: М). 1 М М 1 Взаимодействие сущностей 2.2. Связи между сущностями инфологической модели Разработку информационного обеспечения АРМ проведем на базе системы управления базами данных (СУБД) Access XP из состава выбранного интегрированного пакета Microsoft Office XP. СУБД Access предназначена для ...
... ЭВМ. Приложения, созданные с помощью SQL и рассчитанные на однопользовательские системы, по мере своего развития могут быть перенесены в более крупные системы. Информация из корпоративных реляционных баз данных может быть загружена в базы данных отдельных подразделений или в личные базы данных. Наконец, приложения для реляционных баз данных можно вначале смоделировать на экономичных персональных ...
... можно с успехом использовать неформальные эквиваленты этих понятий: Отношение – Таблица (иногда Файл), Кортеж – Строка (иногда Запись), Атрибут – Столбец, Поле. 3.2 Реляционная база данных Реляционная база данных – это совокупность отношений, содержащих всю информацию, которая должна храниться в БД. Однако пользователи могут воспринимать такую базу данных как совокупность таблиц. 1. Каждая ...
... купленных номеров; 6. Ведение учета, сколько, какие номера свободны или куплены покупателями и сколько по времени они будут заняты. 2. Разработка базы данных 2.1 Технологический процесс обработки информации 2.1.1 Описание предметной области Гостиничный комплекс, который мы будем рассматривать в данной работе, будет содержать одну гостиницу, пункт питания и автостоянку. ...
0 комментариев