Существуют два простых правила, помогающих избежать данной ситуации. Во-первых, необходимо выполнять все действия в одинаковой последовательности, т.е. 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 и Sybase SQL 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. Описание предметной области

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

Для однопользовательских АС характерно использование следующих баз данных:

локальные реляционные базы данных, находящиеся под управлением одной или нескольких СУБД (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.

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 Server 2000: разработка приложений. - СПб.: БХВ-Петербург, 2000. - 368 с.

Страницы: 1, 2