СОДЕРЖАНИЕ
Введение. 2
1. Системный анализ предметной области. 4
1.1. Краткая характеристика предметной области. 4
1.2. Описание предметной области. 13
2. Инфологическое моделирование. 18
2.1.Модель «сущность-связь». 18
2.2. Связи между сущностями инфологической модели. 20
Заключение. 23
Список литературы… 24
Введение
Целью данной курсовойработы является построение и реализация базы данных защиты распределенной базыданных от несанкционированного доступа.
Основными задачами,поставленными в ходе работы, являлись:
— сбор, анализ исортирование документов с целью описания предметной области;
— отбор необходимыхдокументов для создания базы данных;
— выявлениесущностей инфологической модели и моделирование связей между ними.
В настоящее времяпрактически во всех сферах человеческой деятельности используются базы данных.В том числе решение перечисленных задач позволит достигнуть цели, поставленнойв курсовой работе, а именно, реализовать базу данных защиты распределенной базыданных от несанкционированного доступа.
В общем смысле термин«база данных» (БД) можно применить к любой совокупности связанной информации,объединенной вместе по определенному признаку, т.е. к набору структурированныхданных (организованных определенным образом). При этом большинство БДиспользует табличный способ представления, где данные располагаются по строкам(которые называются записями) и столбцам (которые называются полями), всезаписи должны состоять из одинаковых полей и все данные одного поля должныиметь один тип.
В настоящее времясуществует множество систем управления базами данных (СУБД) и других программ,выполняющих похожие функции, преобладающей является реляционная базаданных.В компьютерном варианте в реляционной БД информация хранится, как правило, внескольких таблицах-файлах, связанных между собой посредством одного илинескольких совпадающих в этих таблицах полей (в некоторых компьютерных системахвсе таблицы одной базы помещаются в один файл). Каждая строка в таблице реляционнойБД должна быть уникальна (т.е. не должно быть одинаковых строк-записей). Такиеуникальные столбцы (или уникальные группы столбцов), используемые, чтобыидентифицировать каждую строку и хранить все строки отдельно, называютсяпервичными ключами таблицы.
Для проектирования БДодной из концепционных является модель «сущность-связь». С помощью сущностимоделируется класс однотипных объектов. Сущность имеет имя, уникальное впределах моделируемой системы. Так как сущность соответствует некоторому классуоднотипных объектов, то предполагается, что в системе существует множествоэкземпляров данной сущности. Объект, которому соответствует понятие сущности,имеет свой набор атрибутов – характеристик, определяющих свойстваданного представителя класса. При этом набор атрибутов должен быть таким, чтобыможно было различать конкретные экземпляры сущности.
Отношение«один-ко-многим» можно назвать основным типом отношений, использующимся припроектировании современных БД. Поскольку оно позволяет представлять иерархическиеструктуры данных.
Отношения один-ко-многиммогут быть жесткими и нежесткими. Для жестких отношений должно выполнятьтребование, что каждой записи в родительской таблице должна соответствоватьхотя бы одна запись в дочерней таблице.
Таким образом, выборреляционной БД открывает широкие возможности для пользователя, позволяя легкосоздать БД, удовлетворяющую требованиям организаций самого разногопользовательского профиля, выполняющих разные по значимости задачи ииспользующих неравнозначные объемы информации в своей деятельности.
1.Системный анализ предметной области 1.1.Краткая характеристика предметной области
В зависимости оразмещения типовых компонентов приложения по узлам сети информационные системыи соответствующие приложения могут строиться различными способами, такими каксистемы на основе локальной сети персональных компьютеров (файл-серверныеприложения), системы с архитектурой клиент-сервер и др.
Суть модели файловогосервера состоит втом, что один из компьютеров в сети считается файловым сервером и предоставляетуслуги по обработке файлов другим компьютерам. Файл-сервер работает подуправлением сетевой операционной системы и играет роль компонента доступа кинформационным ресурсам. На других компьютерах в сети функционирует приложение,в котором функции представления информации и логика прикладной обработкисовмещены. Обращение за сервисом управления данными происходит через средупередачи с помощью операторов языка SQL или вызовом функций библиотеки API (Application Programming Interface – интерфейс прикладного программирования).Основное достоинство такой модели состоит в большом обилии готовых СУБД,имеющих SQL-интерфейсы, и существующихинструментальных сердств, обеспечивающих быстрое создание программ клиентскойчасти. Средства разработки чаще всего поддерживают графический интерфейспользователя в MS Windows, стандарт интерфейса ODBC и средства автоматической генерациикода.
Недостатки моделифайл-сервер:
/> высокий сетевойтрафик (вследствие того, что вся логика сосредоточена в приложении, аобрабатываемые данные расположены на удаленном узле;
/> во время работыприложений обычно по сети передаются целые БД);
/> узкий спектропераций манипуляции с данными;
/> отсутствие надежныхсредств безопасности доступа к данным (защита только на уровне файловойсистемы).
Поэтому предпочтительноприменять технологию клиент-сервер, когда сервер базы данныхиспользуется не только для хранения информации, но и для обработки запросов кбазе данных. Запросы рабочей станции обрабатываются сервером базы данных иобратно возвращается только результат выполнения запроса. Такой подходуменьшает поток данных в сети. Кроме того, обработка запросов сервером базыданных осуществляется быстрее, чем на рабочей станции, так как:
/> в качестве серверабазы данных используется гораздо более мощный компьютер
/> СУБД, используемаяв качестве сервера базы данных, обладает более совершенными средствамиобработки данных
Так как обработказапросов осуществляется на сервере базы данных, а не на рабочей станции,рабочая станция называется клиентом сервера базы данных. При работе в режимеклиент-сервер серверная часть системы управления базами данных устанавливаетсяна файл-сервере, а клиентская часть — на рабочей станции. В ряде случаев клиентскаяи серверная части являются отдельными компонентами одной СУБД (например, Oracleили SQLbase). В других случаях в качестве клиентской части используютсянастольные СУБД или специальные системы разработки приложений клиент/сервер(например, PowerBuilderили SQLWindows), а в качестве сервера базыданных — мощная СУБД типа Oracle или SQL Server.
Основная задача, котораядолжна быть надежно решена при разработке многопользовательского приложения –это управление возможными столкновениями пользователей при одновременноймодификации одних и тех же данных. Эта проблема должна быть решена на двухуровнях:
первый – это сведение количества такихконфликтов к минимуму и
второй – разработка четкого алгоритма ихразрешения.
Таблица 1Низкая конкуренция (случай 1) Высокая конкуренция (случай 2) Блокировка записи Запись данных в переменные Чтение записи Чтение переменных Полноэкранное редактирование Запрос на сохранение данных Сохранение данных Блокировка записи -- Запись данных из переменных в БД Снятие блокировки с записи
В таблице 1 приведены двавозможных алгоритма модификации данных в многопользовательских системах снизким и высоким уровнями конкуренции пользователей при попытке доступа к одними тем же данным. В первом случае мы получаем несомненно более стабильнуюсистему за счет захвата нужной записи и тем самым полного устранениявозможности одновременной модификации одних и тех же данных. В то же времязахваченные данные могут оставаться недоступными долгое время в случае, еслипользователь вдруг заметил какую-то ошибку и надолго застрял в поисках путей ееисправления или просто решил отдохнуть в момент подноэкранного редактирования.Для избежания подобных ситуаций можно поставить ограничение на времяредактирования, но тогда данные могут вдруг изчезнуть с экрана прямо на глазахизумленного зазевавшегося пользователя.
При втором вариантепродожительность блокировки не зависит от поведения пользователя. Это времябудет определяться только продолжительностью записи данных. Во времяредактирования данные продолжают оставаться доступными для других пользователей.Хорошо ли это? Отлично, мы достигли потрясающей гибкости! Но в то же времяполучили массу забот, так как во время редактирования данных однимпользователем их может изменить и другой. При таком подходе есть риск, чтопосле того, как первый пользователь успешно модифицирует запись, ее тут жеосвежит и второй работник, который в глаза не видел обновленных первымабонентом сети данных. Ведь у него на экране были данные из БД до их измененияпервым пользователем.
Для решения этих проблемв СУБД предлагается использовать буферизацию данных. Рассмотрим типичныйнабор блокировок:
/> отсутствиебуферизации.
/> пессимистическаябуферизация записи;
/> оптимистическаябуферизация записи;
/> пессимистическаябуферизация таблицы;
/> оптимистическаябуферизация таблицы.
Буферизация на уровнезаписи означает, что перед началом редактирования содержимое текущей записибудет сохранено во внутреннем буфере СУБД. Буферизация нв уровне таблицысохраняет в буфере содержание всех отобранных для редактирования записей.Оптимистическая буферизация обеспечивает блокировку записей только на времясохранения содержимого буфера в файле, что соответствует приведенному выше случаю2. Пессимистическая буферизация работает как в случае 1, то есть блокируетзапись перед копированием ее содержимого в буфер.
Использование буферизациипозволяет автоматизировать процесс переноса данных из полей БД в переменные иобратно. При этом группа функций позволяет получить исчерпывающую информацию осостоянии буферизованной таблицы, что дает возможность организовать оченьэффективный алгоритм разрешения возможных конфликтов при изменении данных(схема их взаимодействия приведена на рисунке 1).
/>
Рис.1 Функции для работы сбуферизованной таблицей
OLDVAL() – возвращает первоначальное значениеполя, которое было модифицировано, но не обновлялось.
CURVAL() – возвращает значение полянепосредственно с диска или из удаженного источника.
TABLEUPDATE() – фиксирует изменения, внесенные вбуферизованную запись либо в буферизованную таблицу или курсор.
TABLEREVERT() – сбрасывает изменения, внесенные вбуферизованную запись либо в буферизованную таблицу или курсор ивосстанавливает содержимое по данным OLDVAL().
При буферизации таблицымы имеем возможность добавлять и удалять записи в буфере. При добавлении новаязапись помещается в конец буфера и получает номер с отрицательным значением.Доступ к этой записи может быть выполнен с помощью функции RECNO() с отрицательным параметром,например –1.
RECNO() — возвращает номер текущей записи втекущей или заданной таблице
При написании многопользовательскихприложений необходимо учитывать, что целый ряд команд при их использованиивыполняет автоматическую блокировку.
Если вы решили управлятьблокировкой вручную, то придерживайтесь следующего алгоритма:
/> проверьте состояниеблокировки записи или таблицы;
/> если блокировкинет, то требуемые ресурсы можно заблокировать;
/> если ресурсыблокированы, попробуйте еще раз, но при этом следует избегать слишком частыхпопыток. Кроме чрезмерной загрузки сети это ни к чему не приведет.
При разработке алгоритмаблокировки старайтесь придерживаться четкой последовательности событий.Например, в следующем примере при борьбе за несколько ресурсов будетнаблюдаться патовая ситуация (тупик):
Пользователь 1
Пользователь 2 Попытка блокировать запись 1 Попытка блокировать запись 4 Попытка блокировать запись 4 Попытка блокировать запись 1 Если попытка неудачна, ждлем освобождения ресурсов Если попытка неудачна, ждлем освобождения ресурсов Ждем, ждем, ждем … Ждем, ждем, ждем …
Существуют два простыхправила, помогающих избежать данной ситуации. Во-первых, необходимо выполнятьвсе действия в одинаковой последовательности, т.е. 2-й пользователь долженпытаться блокировать записи, также начиная с первой. Во-вторых, всегданеобходимо ставить ограничения по времени на попытки блокировки, чтобы датьвозможность хотя бы одному пользователю закончить работу.
Ряд команд и функцийавтоматически обеспечивают снятие блокировки:
/> Закрытие таблицы
/> Завершениетранзакции
/> Завершение сеансаработы с СУБД
/> Фиксацияизменений, внесенных в буферизованную запись или таблицу
Если вы хотите обеспечитьзащиту изменяемых данных и возможность восстановления первоначальных значенийна протяжении определенного периода испольнения программы, используйте механизмвстроенных транзакций. При использовании транзакций с момента выдачи команды«Начать транзакцию» все изменения сначала сохраняются в памяти компьютера илина диске и только при завершении транзакции переносятся в таблицу. При этомтаблица обязательно должна быть включена в базу данных. Если в процессе работывыяснилась нецелесообразность использования сделанных изменений, до выполнениякоманды «Завершить транзакцию» всегда остается возможность вернуться кпервоначальному состоянию таблицы, выдав команду «Отменить изменения, внесенныев ходе текущей транзакции». Для организации логических групп по обновлениюданных можно использовать вложенные транзакции.
В общем случае прииспользовании транзакций предпочтительной является буферизация записи посравнению с буферизацией таблицы.
Использование транзакцийне может гарантировать сохранение измененных данных, например, при выключениикомпьютера. В этом случае автоматически выполнится откат к состоянию таблицы доначала транзакции.
Интерфейс прикладногопрограммирования ODBC API предоставляет общие методы доступа SQL как креляционным, так и к нереляционным (ISAM) источникам данных.
В ANSI SQL входитинтерфейс на уровне вызовов (CLI — call-level interface), который используетсяODBC для обеспечения доступа и работы с данными во многих системах управлениябазами данных. Интерфейс CLI соответствует требованиям, установленным в 1991году группой SQL Access Group, которые определяют общий синтаксис SQL и интерфейсаAPI. Иметь общий метод доступа к источникам данных удобно потому, что тогдабаза данных на сервере становится прозрачной для приложений, которые написаны всоответствии с некоторым заданным уровнем совместимости ODBC.
Интерфейс ODBC APIреализован как набор расслоенных DLL-функций для Windows. Динамическаябиблиотека ODBC.DLL — это основная библиотека управления драйверами ODBC, котораявызывает специализированные драйверы для разных поддерживаемых системой базданных. Каждый драйвер совместим со своим уровнем CLI и относится к одной издвух категорий: одноуровневые или многоуровневые драйверы.
Одноуровневые драйверыпредназначены для использования при работе с теми источниками данных, которыене могут быть обработаны ANSI SQL. Обычно это локальные базы данных наперсональных компьютерах, такие как dBase, Paradox, FoxPro и др. Драйверы,соответствующие этим базам данных, переводят грамматику ANSI SQL в инструкциинизкого уровня, которые непосредственно обрабатывают составляющие базу данныхфайлы.
Многоуровневые драйверыиспользуют сервер СУРБД для обработки SQL-предложений и предназначены дляработы в среде клиент-сервер. Помимо обработки ANSI SQL, они также могутподдерживать и собственную грамматику конкретной СУРБД, поскольку ODBC можетбез трансляции передавать SQL-предложения источникам данных (механизм«passthrough»).
Драйверы ODBC для базданных типа клиент-сервер реализованы для Oracle, Informix, Microsoft и SybaseSQL Server, Rdb, DB2, Ingres, HP/Image и Any SQL.
Существует 4 важных этапа(шага) процедуры запроса данных через API.
Шаг 1 — установление соединения. Первыйшаг состоит в размещении указателей (handle) среды ODBC, которые выделяютоперативную память под ODBC драйверы и библиотеки. Затем происходит выделениепамяти для указателей соединения, и соединение устанавливается.
Шаг 2 — выполнение предложения SQL.Выделяется указатель предложения, локальные переменные связываются со столбцамив SQL-выражении (это необязате~ьное действие), и выражение представляется наразбор главному ODBC драйверу для обработки.
Шаг 3 — извлечение данных. Передизвлечением данных возвращается информация о результирующем наборе, такая какчисло столбцов в наборе. Исходя из этого числа, результирующий набор помещаетсяв буфер записей, выполняется цикл по нему и извлекается по одному столбцу влокальные переменные. Этот шаг необязателен, если используется связываниестолбцов.
Шаг 4 — освобождение ресурсов. После того,как данные получены, освобождаются ресурсы вызовом функций освобожденияуказателей предложения, соединения и среды. Указатели предложения и соединениямогут быть использованы в процессе обработки.
Технология ODBCразрабатывалась как общий, независимый от источников данных, способ доступа кданным. Также ее применение должно было обеспечить переносимость приложений наразличные базы данных без переработки самих приложений. В этом смыслетехнология ODBC уже стала промышленным стандартом, ее поддерживают практическивсе производители СУБД и средств разработки.
Однако универсальностьстоит дорого. Если при разработке приложений одним из основных критериевявляется переносимость на различные СУБД, то использование ODBC являетсяоправданным. Для увеличения производительности и эффективности приложенияактивно применяют специфические для данной СУБД расширения языка SQL,используют хранимые на сервере процедуры и функции. В этом случае теряется рольODBC как общего метода доступа к данным. Тем более, что для разных СУБДдрайверы ODBC поддерживают разные уровни совместимости. Поэтому многие производителисредств разработки помимо поддержки ODBC поставляют «прямые» драйверык основным СУБД.
1.2. Описание предметной области
В управленческой,экономической, финансовой, правовой сферах широко используется информация,представляющая собой неструктурированную информацию (помимо структурированнойинформации, организованной в БД, находящихся под управлением СУБД).Информационные ресурсы представляют собой отдельные документы и отдельныемассивы документов в информационных системах (библиотеках, архивах, фондах,банках данных, других видах информационных систем). К ним относятся рукописные,печатные и электронные издания, содержащие нормативную, распорядительную, фактографическую,справочную, аналитическую и др. информацию по различным направлениямобщественной деятельности (законодательство, политика, демография, социальнаясфера, наука, техника, технология и т.д.).
Для однопользовательскихАС характерно использование следующих баз данных:
локальные реляционныебазы данных, находящиеся под управлением одной или нескольких СУБД (MicrosoftAccess, FoxPro и т.п.) и предназначенные для решения пользователем прикладныхзадач с использованием собственного или покупного специального программногообеспечения на его АРМе;
локальные базынеструктурированной информации (текстовых и табличных документов, созданныхпользователем средствами Microsoft Word и Microsoft Excel, полученных по электроннойпочте, на машинных носителях, а также документов, полученных врезультате решения пользователем прикладных задач с использованием информации реляционныхбаз данных), организованные и хранящиеся в виде каталогов и подкаталогов на егоАРМе;
базы данных, размещенныена удаленных ПК в федеральных и международных сетях, к которым организовандоступ самим пользователем со своего АРМ (если АРМ подключен к федеральным имеждународным сетям передачи данных).
Современныеавтоматизированные информационные системы представляют собой, как правило, ЛВС,подключенные к федеральным и международным сетям передачи данных. ПользовательЛВС использует не только вышеперечисленные локальные базы данных, но ираспределенные:
реляционные базы данныхна сервере ЛВС, находящиеся под управлением одной или нескольких СУБД;
базы неструктурированнойинформации (документов, созданных и полученных разными пользователями ЛВС),организованные и хранящиеся в виде каталогов и подкаталогов на сервере ЛВС;
базы данных различныхприобретенных АС, установленные в ЛВС и доступные всем пользователям сети;
базы данных, размещенныена удаленных ПК в федеральных и международных сетях, к которым организовандоступ для всех пользователей ЛВС.
Значительная частьнеструктурированной информации в вышеназванных базах является, как правило,гипертекстовыми и гипермедиа-документами, объединенными с помощью гиперссылок вгипертекстовые базы данных.
В последние годы находятвсе более широкое применение так называемые геоинформационные системы.Геоинформационные системы (ГИС)–это интегрированные в единой информационнойсреде электронные пространственно-ориентированные изображения (карты, схемы,планы и т.п.) и базы данных (БД). В качестве БД могут использоваться таблицы,паспорта, иллюстрации, расписания и т. п. Такая интеграция значительнорасширяет возможности системы и позволяет упростить аналитические работы скоординатно-привязанной информацией. Принципиальным отличием ГИС являетсяналичие в них картографических данных местности, региона и т.д., к которым привязываетсяостальная информация системы. Геоинформационные системы уже широко используютсяв управлении градостроительством, транспортом, природными ресурсами и т.п.
Для современного этапаразвития информационных технологий характерно наличие разнообразныхинструментальных средств и покупного специального программного обеспечения,которыми может овладеть любой пользователь, а такженаличие большогоколичества промышленно функционирующих БД коммерческих организаций, органовгосударственной власти и местного самоуправления, предприятий и организаций.
Такая ситуация позволяетпри создании многих АС отказаться от проектирования и разработки собственныхреляционных баз данных и собственного специального программного обеспечения.Использование современных инструментальных средств позволяет пользователюсамостоятельно (без помощи системного программиста) организовывать со своегоАРМ доступ к различным информационным ресурсам, например, создавать каталогинормативно-правовых актов, каталоги адресов WWW-серверов Интернета и т.п.Появление ОПО последних версий позволяет пользователю организовывать доступ кразличным ресурсам АРМ и ЛВС через гиперссылки (по принципу “паутины”) взамениерархического принципа доступа (принципа “дерева”).
Распределенная системаорганизации баз данных предполагает наличие соответствующей технологии доступапользователей к информационным ресурсам, ориентированной, прежде всего, навычислительные модели типа «клиент-сервер».
Технология«клиент-сервер» предполагает разделение функций обработки данных натри группы: функции ввода/вывода и отображения данных; прикладные функции, характерныедля данной предметной области; функции хранения и управления данными. Каждаягруппа функций выполняется отдельным логическим компонентом.
Различия в реализацииприложений в рамках «клиент-сервер» определяются механизмомиспользования и распределения между компьютерами в сети этих компонент, всоответствии с этим выделяют три подхода, реализованные в моделях:
модель доступа кудаленным данным (Remote Data Access-RDA), в которой компонент представления иприкладной компонент совмещены и выполняются на одном компьютере. Запросы кинформационным ресурсам направляются по сети к удаленному компьютеру, которыйобрабатывает запросы и возвращает блоки данных. Эта модель является самойпростой и традиционно используется в локальных вычислительных сетях, гдескорость обмена достаточно высока, однако она неприемлема при работе в среденизкоскоростных каналов передачи данных. Поскольку вся логика локализована наодном компьютере, то приложение нуждается в передаче по сети большого, частоизбыточного объема данных, что существенно повышает загрузку информационнойсистемы в целом и может привести к длительному блокированию данных от другихпользователей;
модель сервера базы данных(DataBase Server-DBS), которая строится в предположении, что процесс,выполняемый на компьютере-клиенте, ограничивается функциями представления, в товремя как собственно прикладные функции реализованы в хранимых непосредственнов базе данных процедурах, выполняющихся на компьютере-сервере БД. ПреимуществаDBS-модели перед RDA заключаются в очевидном снижении сетевого трафика. ОднакоDBS-модель не обеспечивает требуемой эффективности использования вычислительныхресурсов в случае нескольких серверов;
модель сервера приложений(Application Server-AS), в которой процесс, выполняющийся в компьютере-клиенте,реализует функции первой группы. Прикладные функции выполняются на удаленномкомпьютере. Доступ к информационным ресурсам, необходимым для решения прикладныхзадач, обеспечивается тем же способом, что и в RDA модели. AS-модель не требуетобеспечения миграции прикладных функций между серверами, что значительнооблегчает администрирование системы в целом, однако, для обеспечениядостаточной скорости обработки данных сервер приложений и сервер БД должнынаходится в одной ЛВС или быть соединены по выделенному каналу.
На практике часто длясоздания более гибких и динамичных систем используются смешанные модели.
Компьютер-клиент икомпьютер-сервер могут работать в условиях ЛВС и быть абонентами глобальнойкомпьютерной сети, общаясь между собой по организуемому виртуальному каналуили, используя для этого (при снижении требований на реактивность системы)электронную почту.
В настоящее времясуществует целый ряд программных средств, как системных, так и прикладных,реализующих описанные выше модели. Стоит отметить такие пакеты, как Oraclе SQLServer и Sybase SQL Server для платформы NetWare, продукт Microsoft WindowsNTSQL Server, Oracle для среды Unix, Lotus Notes. Все эти программные средстваработают на различных платформах (на машинах с процессорами Intel, наRISC-серверах и станциях производства HP, DEC и т.д.), в различных операционныхсредах. СУБД Oracle выделяется среди прочих исключительным быстродействием, мощнымисетевыми средствами и средствами межплатформенной связи. Развитые средстваэлектронной почты пакета Oracle позволяют организовать безбумажныйдокументооборот, совместную подготовку и обработку документов. Существуетинтегрированный программный продукт ORACLE 2000WG, объединяющий достоинствапопулярной сетевой операционной системы Novell NetWare и СУБД Oracle. Вструктурах управления федеральных, государственных и местных органов власти всешире применяется пакет Lotus Notes.
2.Инфологическое моделирование 2.1.Модель«сущность-связь»
Инфологическая модельотображает реальный мир в некоторые понятные человеку концепции, полностьюнезависимые от параметров среды хранения данных. Существует множество подходовк построению таких моделей: графовые модели, семантические сети, модель«сущность-связь» и т.д. Наиболее популярной из них оказалась модель«сущность-связь» или называемая ещё ER-моделью (от англ. Entity-Relationship, т.е. сущность-связь).
Инфологическая модельприменяется после словесного описания предметной области.
Проведем анализпредметной области проектируемой БД.
Пользователи
Код пользователя Логин Пароль Примечание
Права пользователя
Код доступа Права
Сеанс
Код сеанса Код пользователя Код доступа Номер сеанса Время начала Время окончания
Как любая модель, модель«сущность-связь» имеет несколько базовых понятий, которые образуют исходныекирпичики, из которых строятся уже более сложные объекты по заранееопределенным правилам.
Эта модель в наибольшейстепени согласуется с концепцией объектно-ориентированного проектирования,которая в настоящий момент, несомненно, является базовой для разработки сложныхпрограммных систем, поэтому многие понятия вам могут показаться знакомыми, иесли это действительно так, то тем проще вам будет освоить технологиюпроектирования баз данных, основанную на ER-модели.
Сущность, с помощью которой моделируетсякласс однотипных объектов. Сущность имеет имя, уникальное в пределахмоделируемой системы. Так как сущность соответствует некоторому классуоднотипных объектов, то предполагается, что в системе существует множествоэкземпляров данной сущности. Объект, которому соответствует понятие сущности,имеет свой набор атрибутов – характеристик, определяющих свойстваданного представителя класса. При этом набор атрибутов должен быть таким, чтобыможно было различать конкретные экземпляры сущности.
Рассмотрим сущности БД напримере исследуемой предметной области.
/>
/> /> /> /> /> /> /> /> /> /> /> /> /> /> /> /> /> /> /> /> /> /> /> /> /> /> /> /> /> />
2.2. Связи между сущностямиинфологической модели
Между сущностями могутбыть установлены связи – бинарные ассоциации, показывающие, какимобразом сущности соотносятся или взаимодействуют между собой. Связь может существоватьмежду двумя разными сущностями или между сущностью и ей же самой (рекурсивнаясвязь). Она показывает, как связаны экземпляры сущностей между собой. Еслисвязь устанавливается между двумя сущностями, то она определяет взаимосвязьмежду экземплярами одной и другой сущности.
Определим связи междувыявленными сущностями.
Связь ОДИН-КО-МНОГИМ(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 Server2000: разработка приложений. – СПб.: БХВ-Петербург, 2000. – 368 с.