Разработка программного обеспечения для Отделения Реанимации и Интенсивной Терапии Новорожденных при Муниципальной Городской Больнице № 1 города Сургута
Основные понятия и функции (управление данными, транзакциями, журнализация) баз данных. Изучение систем, основанных на инвертированных списках, иерархических и сетевых СУБД. Анализ понятий (домен, атрибут, кортеж) и систем управления реляционными БД.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | дипломная работа |
| Язык | русский |
| Дата добавления | 07.11.2009 |
| Размер файла | 1,9 M |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Наконец, авторизация доступа к объектам БД производится также на основе специального набора операторов SQL. Идея состоит в том, что для выполнения операторов SQL разного вида пользователь должен обладать различными полномочиями. Пользователь, создавший таблицу БД, обладает полным набором полномочий для работы с этой таблицей. В число этих полномочий входит полномочие на передачу всех или части полномочий другим пользователям, включая полномочие на передачу полномочий. Полномочия пользователей описываются в специальных таблицах-каталогах, контроль полномочий поддерживается на языковом уровне.
Более точное описание возможных реализаций этих функций на основе языка SQL будет приведено в лекциях, посвященных языку SQL и его реализации.
2.2 Типовая организация современной СУБД
Естественно, организация типичной СУБД и состав ее компонентов соответствует рассмотренному нами набору функций. Напомним, что мы выделили следующие основные функции СУБД:
управление данными во внешней памяти;
управление буферами оперативной памяти;
управление транзакциями;
журнализация и восстановление БД после сбоев;
поддержание языков БД.
Логически в современной реляционной СУБД можно выделить наиболее внутреннюю часть - ядро СУБД (часто его называют Data Base Engine), компилятор языка БД (обычно SQL), подсистему поддержки времени выполнения, набор утилит. В некоторых системах эти части выделяются явно, в других - нет, но логически такое разделение можно провести во всех СУБД.
Ядро СУБД отвечает за управление данными во внешней памяти, управление буферами оперативной памяти, управление транзакциями и журнализацию. Соответственно, можно выделить такие компоненты ядра (по крайней мере, логически, хотя в некоторых системах эти компоненты выделяются явно), как менеджер данных, менеджер буферов, менеджер транзакций и менеджер журнала. Как можно было понять из первой части этой лекции, функции этих компонентов взаимосвязаны, и для обеспечения корректной работы СУБД все эти компоненты должны взаимодействовать по тщательно продуманным и проверенным протоколам. Ядро СУБД обладает собственным интерфейсом, не доступным пользователям напрямую и используемым в программах, производимых компилятором SQL (или в подсистеме поддержки выполнения таких программ) и утилитах БД. Ядро СУБД является основной резидентной частью СУБД. При использовании архитектуры "клиент-сервер" ядро является основной составляющей серверной части системы.
Основной функцией компилятора языка БД является компиляция операторов языка БД в некоторую выполняемую программу. Основной проблемой реляционных СУБД является то, что языки этих систем (а это, как правило, SQL) являются непроцедурными, т.е. в операторе такого языка специфицируется некоторое действие над БД, но эта спецификация не является процедурой, а лишь описывает в некоторой форме условия совершения желаемого действия (вспомните примеры из первой лекции). Поэтому компилятор должен решить, каким образом выполнять оператор языка прежде, чем произвести программу. Применяются достаточно сложные методы оптимизации операторов, которые мы подробно рассмотрим в следующих лекциях. Результатом компиляции является выполняемая программа, представляемая в некоторых системах в машинных кодах, но более часто в выполняемом внутреннем машинно-независимом коде. В последнем случае реальное выполнение оператора производится с привлечением подсистемы поддержки времени выполнения, представляющей собой, по сути дела, интерпретатор этого внутреннего языка.
Наконец, в отдельные утилиты БД обычно выделяют такие процедуры, которые слишком накладно выполнять с использованием языка БД, например, загрузка и выгрузка БД, сбор статистики, глобальная проверка целостности БД и т.д. Утилиты программируются с использованием интерфейса ядра СУБД, а иногда даже с проникновением внутрь ядра.
3. Ранние подходы к организации БД. Системы, основанные на инвертированных списках, иерархические и сетевые СУБД. Примеры. Сильные места и недостатки ранних систем
Прежде, чем перейти к детальному и последовательному изучению реляционных систем БД, остановимся коротко на ранних (дореляционных) СУБД. В этом есть смысл по трем причинам: во-первых, эти системы исторически предшествовали реляционным, и для правильного понимания причин повсеместного перехода к реляционным системам нужно знать хотя бы что-нибудь про их предшественников; во-вторых, внутренняя организация реляционных систем во многом основана на использовании методов ранних систем; в-третьих, некоторое знание в области ранних систем будет полезно для понимания путей развития пост реляционных СУБД.
Заметим, что в этой лекции мы ограничиваемся рассмотрением только общих подходов к организации трех типов ранних систем, а именно, систем, основанных на инвертированных списках, иерархических и сетевых систем управления базами данных. Мы не будем касаться особенностей каких-либо конкретных систем; это привело бы к изложению многих технических деталей, которые, хотя и интересны, находятся несколько в стороне от основной цели нашего курса. Детали можно найти в рекомендованной литературе.
Начнем с некоторых наиболее общих характеристик ранних систем:
a. Эти системы активно использовались в течение многих лет, дольше, чем используется какая-либо из реляционных СУБД. На самом деле некоторые из ранних систем используются даже в наше время, накоплены громадные базы данных, и одной из актуальных проблем информационных систем является использование этих систем совместно с современными системами.
b. Все ранние системы не основывались на каких-либо абстрактных моделях. Как мы упоминали, понятие модели данных фактически вошло в обиход специалистов в области БД только вместе с реляционным подходом. Абстрактные представления ранних систем появились позже на основе анализа и выявления общих признаков у различных конкретных систем.
c. В ранних системах доступ к БД производился на уровне записей. Пользователи этих систем осуществляли явную навигацию в БД, используя языки программирования, расширенные функциями СУБД. Интерактивный доступ к БД поддерживался только путем создания соответствующих прикладных программ с собственным интерфейсом.
d. Можно считать, что уровень средств ранних СУБД соотносится с уровнем файловых систем примерно так же, как уровень языка Кобол соотносится с уровнем языка Ассемблера. Заметим, что при таком взгляде уровень реляционных систем соответствует уровню языков Ада или APL.
e. Навигационная природа ранних систем и доступ к данным на уровне записей заставляли пользователя самого производить всю оптимизацию доступа к БД, без какой-либо поддержки системы.
f. После появления реляционных систем большинство ранних систем было оснащено "реляционными" интерфейсами. Однако в большинстве случаев это не сделало их по-настоящему реляционными системами, поскольку оставалась возможность манипулировать данными в естественном для них режиме.
3.1 Основные особенности систем, основанных на инвертированных списках
К числу наиболее известных и типичных представителей таких систем относятся Datacom/DB компании Applied Data Research, Inc. (ADR), ориентированная на использование на машинах основного класса фирмы IBM, и Adabas компании Software AG.
Организация доступа к данным на основе инвертированных списков используется практически во всех современных реляционных СУБД, но в этих системах пользователи не имеют непосредственного доступа к инвертированным спискам (индексам). Кстати, когда мы будем рассматривать внутренние интерфейсы реляционных СУБД, вы увидите, что они очень близки к пользовательским интерфейсам систем, основанных на инвертированных списках.
3.1.1 Структуры данных
База данных, организованная с помощью инвертированных списков, похожа на реляционную БД, но с тем отличием, что хранимые таблицы и пути доступа к ним видны пользователям. При этом:
a. Строки таблиц упорядочены системой в некоторой физической последовательности.
b. Физическая упорядоченность строк всех таблиц может определяться и для всей БД (так делается, например, в Datacom/DB).
c. Для каждой таблицы можно определить произвольное число ключей поиска, для которых строятся индексы. Эти индексы автоматически поддерживаются системой, но явно видны пользователям.
3.1.2 Манипулирование данными
Поддерживаются два класса операторов:
a. Операторы, устанавливающие адрес записи, среди которых:
прямые поисковые операторы (например, найти первую запись таблицы по некоторому пути доступа);
операторы, находящие запись в терминах относительной позиции от предыдущей записи по некоторому пути доступа.
Операторы над адресуемыми записями
Типичный набор операторов:
LOCATE FIRST - найти первую запись таблицы T в физическом порядке; возвращает адрес записи;
LOCATE FIRST WITH SEARCH KEY EQUAL - найти первую запись таблицы T с заданным значением ключа поиска K; возвращает адрес записи;
LOCATE NEXT - найти первую запись, следующую за записью с заданным адресом в заданном пути доступа; возвращает адрес записи;
LOCATE NEXT WITH SEARCH KEY EQUAL - найти следующую запись таблицы T в порядке пути поиска с заданным значением K; должно быть соответствие между используемым способом сканирования и ключом K; возвращает адрес записи;
LOCATE FIRST WITH SEARCH KEY GREATER - найти первую запись таблицы T в порядке ключа поиска K cо значением ключевого поля, большим заданного значения K; возвращает адрес записи;
RETRIVE - выбрать запись с указанным адресом;
UPDATE - обновить запись с указанным адресом;
DELETE - удалить запись с указанным адресом;
STORE - включить запись в указанную таблицу; операция генерирует адрес записи.
3.1.3 Ограничения целостности
Общие правила определения целостности БД отсутствуют. В некоторых системах поддерживаются ограничения уникальности значений некоторых полей, но в основном все возлагается на прикладную программу.
3.2 Иерархические системы
Типичным представителем (наиболее известным и распространенным) является Information Management System (IMS) фирмы IBM. Первая версия появилась в 1968 г. До сих пор поддерживается много баз данных, что создает существенные проблемы с переходом как на новую технологию БД, так и на новую технику.
3.2.1 Иерархические структуры данных
Иерархическая БД состоит из упорядоченного набора деревьев; более точно, из упорядоченного набора нескольких экземпляров одного типа дерева.
Тип дерева состоит из одного "корневого" типа записи и упорядоченного набора из нуля или более типов поддеревьев (каждое из которых является некоторым типом дерева). Тип дерева в целом представляет собой иерархически организованный набор типов записи.
Пример типа дерева (схемы иерархической БД):
Здесь Отдел является предком для Начальник и Сотрудники, а Начальник и Сотрудники - потомки Отдел. Между типами записи поддерживаются связи.
База данных с такой схемой могла бы выглядеть следующим образом (мы показываем один экземпляр дерева):
Все экземпляры данного типа потомка с общим экземпляром типа предка называются близнецами. Для БД определен полный порядок обхода - сверху-вниз, слева-направо.
В IMS использовалась оригинальная и нестандартная терминология: "сегмент" вместо "запись", а под "записью БД" понималось все дерево сегментов.
3.2.2 Манипулирование данными
Примерами типичных операторов манипулирования иерархически организованными данными могут быть следующие:
Найти указанное дерево БД (например, отдел 310);
Перейти от одного дерева к другому;
Перейти от одной записи к другой внутри дерева (например, от отдела - к первому сотруднику);
Перейти от одной записи к другой в порядке обхода иерархии;
Вставить новую запись в указанную позицию;
Удалить текущую запись.
3.2.3 Ограничения целостности
Автоматически поддерживается целостность ссылок между предками и потомками. Основное правило: никакой потомок не может существовать без своего родителя. Заметим, что аналогичное поддержание целостности по ссылкам между записями, не входящими в одну иерархию, не поддерживается (примером такой "внешней" ссылки может быть содержимое поля Каф_Номер в экземпляре типа записи Куратор).
В иерархических системах поддерживалась некоторая форма представлений БД на основе ограничения иерархии. Примером представления приведенной выше БД может быть иерархия\
3.3 Сетевые системы
Типичным представителем является Integrated Database Management System (IDMS) компании Cullinet Software, Inc., предназначенная для использования на машинах основного класса фирмы IBM под управлением большинства операционных систем. Архитектура системы основана на предложениях Data Base Task Group (DBTG) Комитета по языкам программирования Conference on Data Systems Languages (CODASYL), организации, ответственной за определение языка программирования Кобол. Отчет DBTG был опубликован в 1971 г., а в 70-х годах появилось несколько систем, среди которых IDMS.
3.3.1 Сетевые структуры данных
Сетевой подход к организации данных является расширением иерархического. В иерархических структурах запись-потомок должна иметь в точности одного предка; в сетевой структуре данных потомок может иметь любое число предков.
Сетевая БД состоит из набора записей и набора связей между этими записями, а если говорить более точно, из набора экземпляров каждого типа из заданного в схеме БД набора типов записи и набора экземпляров каждого типа из заданного набора типов связи.
Тип связи определяется для двух типов записи: предка и потомка. Экземпляр типа связи состоит из одного экземпляра типа записи предка и упорядоченного набора экземпляров типа записи потомка. Для данного типа связи L с типом записи предка P и типом записи потомка C должны выполняться следующие два условия:
Каждый экземпляр типа P является предком только в одном экземпляре L;
Каждый экземпляр C является потомком не более, чем в одном экземпляре L.
На формирование типов связи не накладываются особые ограничения; возможны, например, следующие ситуации:
a. Тип записи потомка в одном типе связи L1 может быть типом записи предка в другом типе связи L2 (как в иерархии).
b. Данный тип записи P может быть типом записи предка в любом числе типов связи.
c. Данный тип записи P может быть типом записи потомка в любом числе типов связи.
d. Может существовать любое число типов связи с одним и тем же типом записи предка и одним и тем же типом записи потомка; и если L1 и L2 - два типа связи с одним и тем же типом записи предка P и одним и тем же типом записи потомка C, то правила, по которым образуется родство, в разных связях могут различаться.
e. Типы записи X и Y могут быть предком и потомком в одной связи и потомком и предком - в другой.
f. Предок и потомок могут быть одного типа записи.
Простой пример сетевой схемы БД:
3.3.2 Манипулирование данными
Примерный набор операций может быть следующим:
Найти конкретную запись в наборе однотипных записей (инженера Сидорова);
Перейти от предка к первому потомку по некоторой связи (к первому сотруднику отдела 310);
Перейти к следующему потомку в некоторой связи (от Сидорова к Иванову);
Перейти от потомка к предку по некоторой связи (найти отдел Сидорова);
Создать новую запись;
Уничтожить запись;
Модифицировать запись;
Включить в связь;
Исключить из связи;
Переставить в другую связь и т.д.
3.3.3 Ограничения целостности
В принципе их поддержание не требуется, но иногда требуют целостности по ссылкам (как в иерархической модели).
3.4 Достоинства и недостатки
Сильные места ранних СУБД:
Развитые средства управления данными во внешней памяти на низком уровне;
Возможность построения вручную эффективных прикладных систем;
Возможность экономии памяти за счет разделения подобъектов (в сетевых системах).
Недостатки:
Слишком сложно пользоваться;
Фактически необходимы знания о физической организации;
Прикладные системы зависят от этой организации;
Их логика перегружена деталями организации доступа к БД.
Теоретические основы
Мы приступаем к изучению реляционных баз данных и систем управления реляционными базами данных. Этот подход является наиболее распространенным в настоящее время, хотя наряду с общепризнанными достоинствами обладает и рядом недостатков. К числу достоинств реляционного подхода можно отнести:
наличие небольшого набора абстракций, которые позволяют сравнительно просто моделировать большую часть распространенных предметных областей и допускают точные формальные определения, оставаясь интуитивно понятными;
наличие простого и в то же время мощного математического аппарата, опирающегося главным образом на теорию множеств и математическую логику и обеспечивающего теоретический базис реляционного подхода к организации баз данных;
возможность ненавигационного манипулирования данными без необходимости знания конкретной физической организации баз данных во внешней памяти.
Реляционные системы далеко не сразу получили широкое распространение. В то время, как основные теоретические результаты в этой области были получены еще в 70-х, и тогда же появились первые прототипы реляционных СУБД, долгое время считалось невозможным добиться эффективной реализации таких систем. Однако отмеченные выше преимущества и постепенное накопление методов и алгоритмов организации реляционных баз данных и управления ими привели к тому, что уже в середине 80-х годов реляционные системы практически вытеснили с мирового рынка ранние СУБД.
В настоящее время основным предметом критики реляционных СУБД является не их недостаточная эффективность, а присущая этим системам некоторая ограниченность (прямое следствие простоты) при использование в так называемых нетрадиционных областях (наиболее распространенными примерами являются системы автоматизации проектирования), в которых требуются предельно сложные структуры данных. Еще одним часто отмечаемым недостатком реляционных баз данных является невозможность адекватного отражения семантики предметной области. Другими словами, возможности представления знаний о семантической специфике предметной области в реляционных системах очень ограничены. Современные исследования в области постреляционных систем главным образом посвящены именно устранению этих недостатков.
4. Общие понятия реляционного подхода к организации БД. Основные концепции и термины
На этой лекции мы введем на сравнительно неформальном уровне основные понятия реляционных баз данных, а также определим существо реляционной модели данных. Основной целью лекции является демонстрация простоты и возможности интуитивной интерпретации этих понятий. В дальнейших лекциях будут приводиться более формальные определения, на которых основывается математическая теория реляционных баз данных
4.1 Базовые понятия реляционных баз данных
Основными понятиями реляционных баз данных являются тип данных, домен, атрибут, кортеж, первичный ключ и отношение.
Для начала покажем смысл этих понятий на примере отношения СОТРУДНИКИ, содержащего информацию о сотрудниках некоторой организации:
4.1.1 Тип данных
Понятие тип данных в реляционной модели данных полностью адекватно понятию типа данных в языках программирования. Обычно в современных реляционных БД допускается хранение символьных, числовых данных, битовых строк, специализированных числовых данных (таких как "деньги"), а также специальных "темпоральных" данных (дата, время, временной интервал). Достаточно активно развивается подход к расширению возможностей реляционных систем абстрактными типами данных (соответствующими возможностями обладают, например, системы семейства Ingres/Postgres). В нашем примере мы имеем дело с данными трех типов: строки символов, целые числа и "деньги".
4.1.2 Домен
Понятие домена более специфично для баз данных, хотя и имеет некоторые аналогии с подтипами в некоторых языках программирования. В самом общем виде домен определяется заданием некоторого базового типа данных, к которому относятся элементы домена, и произвольного логического выражения, применяемого к элементу типа данных. Если вычисление этого логического выражения дает результат "истина", то элемент данных является элементом домена.
Наиболее правильной интуитивной трактовкой понятия домена является понимание домена как допустимого потенциального множества значений данного типа. Например, домен "Имена" в нашем примере определен на базовом типе строк символов, но в число его значений могут входить только те строки, которые могут изображать имя (в частности, такие строки не могут начинаться с мягкого знака).
Следует отметить также семантическую нагрузку понятия домена: данные считаются сравнимыми только в том случае, когда они относятся к одному домену. В нашем примере значения доменов "Номера пропусков" и "Номера групп" относятся к типу целых чисел, но не являются сравнимыми. Заметим, что в большинстве реляционных СУБД понятие домена не используется, хотя в Oracle V.7 оно уже поддерживается.
4.1.3 Схема отношения, схема базы данных
Схема отношения - это именованное множество пар {имя атрибута, имя домена (или типа, если понятие домена не поддерживается)}. Степень или "арность" схемы отношения - мощность этого множества. Степень отношения СОТРУДНИКИ равна четырем, то есть оно является 4-арным. Если все атрибуты одного отношения определены на разных доменах, осмысленно использовать для именования атрибутов имена соответствующих доменов (не забывая, конечно, о том, что это является всего лишь удобным способом именования и не устраняет различия между понятиями домена и атрибута).
Схема БД (в структурном смысле) - это набор именованных схем отношений.
4.1.4 Кортеж, отношение
Кортеж, соответствующий данной схеме отношения, - это множество пар {имя атрибута, значение}, которое содержит одно вхождение каждого имени атрибута, принадлежащего схеме отношения. "Значение" является допустимым значением домена данного атрибута (или типа данных, если понятие домена не поддерживается). Тем самым, степень или "арность" кортежа, т.е. число элементов в нем, совпадает с "арностью" соответствующей схемы отношения. Попросту говоря, кортеж - это набор именованных значений заданного типа.
Отношение - это множество кортежей, соответствующих одной схеме отношения. Иногда, чтобы не путаться, говорят "отношение-схема" и "отношение-экземпляр", иногда схему отношения называют заголовком отношения, а отношение как набор кортежей - телом отношения. На самом деле, понятие схемы отношения ближе всего к понятию структурного типа данных в языках программирования. Было бы вполне логично разрешать отдельно определять схему отношения, а затем одно или несколько отношений с данной схемой.
Однако в реляционных базах данных это не принято. Имя схемы отношения в таких базах данных всегда совпадает с именем соответствующего отношения-экземпляра. В классических реляционных базах данных после определения схемы базы данных изменяются только отношения-экземпляры. В них могут появляться новые и удаляться или модифицироваться существующие кортежи. Однако во многих реализациях допускается и изменение схемы базы данных: определение новых и изменение существующих схем отношения. Это принято называть эволюцией схемы базы данных.
Обычным житейским представлением отношения является таблица, заголовком которой является схема отношения, а строками - кортежи отношения-экземпляра; в этом случае имена атрибутов именуют столбцы этой таблицы. Поэтому иногда говорят "столбец таблицы", имея в виду "атрибут отношения". Когда мы перейдем к рассмотрению практических вопросов организации реляционных баз данных и средств управления, мы будем использовать эту житейскую терминологию. Этой терминологии придерживаются в большинстве коммерческих реляционных СУБД.
Реляционная база данных - это набор отношений, имена которых совпадают с именами схем отношений в схеме БД.
Как видно, основные структурные понятия реляционной модели данных (если не считать понятия домена) имеют очень простую интуитивную интерпретацию, хотя в теории реляционных БД все они определяются абсолютно формально и точно.
5. Открытая архитектура Delphi
Базовым инструментом для написания данного проекта был взят Delphi.
Компания Borland в развитии своих объектно-ориентированных средств разработки явно пришла к тому выводу, что повторное использование кода и объектная ориентация не являются единственными средствами повышения производительности программистов. С появлением Delphi разработчик может не только создавать и предоставлять своим коллегам готовые к использованию компоненты, но и расширять функциональные возможности среды, в которой он работает, с помощью так называемых "открытых интерфейсов". Такой подход позволяет использовать Delphi уже в роли общего ядра набора инструментальных средств на всех этапах создания прикладных систем - начиная с CASE-систем и заканчивая генерацией документации по создаваемым проектам, с полной их интеграцией в "святая святых" любой среды программирования - IDE. Рассмотрим основные возможности расширения функциональности среды Delphi для того, чтобы оценить степень "открытости" архитектуры этого инструмента.
"Строительные блоки" приложений - компоненты
Как известно, фундаментальной основой визуальных средств Delphi является компонентный подход. В чем же он заключается?
Delphi строится на базе компилятора объектно-ориентированного языка Object Pascal, продолжающего линию диалектов Pascal - Turbo Pascal и Borland Pascal. По мере своего развития, каждая очередная реализация Pascal компании Borland включала все новые расширения синтаксиса, отражающие последние достижения в области языков программирования. Если подходить к оценке качественных "ступеней" развития Pascal, особо следует отметить три из них, направленные на поддержку концепции повторного использования кода:
модульная архитектура, с возможностью разделения интерфейсной и описательной частей (Turbo Pascal 4.0);
средства объектной ориентации, со всеми, присущими ей характеристиками - наследованием, инкапсуляцией и полиморфизмом (Turbo Pascal 5.5);
поддержка механизмов RTTI (Run-Time Type Information), позволяющих получать информацию о базовых характеристиках объектных типов (классов) и их экземпляров (объектов) с помощью языковых средств, непосредственно встроенных в системную библиотеку и структуру организации описаний классов (Delphi 1.0 - Object Pascal);
Следствием введения поддержки RTTI стала возможность создания визуального инструмента разработки приложений, каковым и является Delphi. На определенном уровне иерархии наследования базовой библиотеки классов Delphi появляется класс TPersistent, обеспечивающий необходимый уровень абстракции потокового ввода/вывода объектов (экземпляров классов). Его наследником выступает класс TComponent, определяющий основы поведения компонент Delphi VCL (Visual Component Library) в режиме design-time (этап "конструирования" приложения). На оконечных точках ветвей иерархии VCL находятся как таковые компоненты - готовые к визуальному использованию классы, непосредственно регистрируемые в рабочей библиотеке компонент и доступные из Палитры Компонент (Components Palette) IDE Delphi.Так как компоненты, используемые в разрабатываемой программе, написаны на том же языке, который используется при создании приложений, программист может достаточно легко создавать и регистрировать в Палитре свои компоненты, наследуя их от тех или иных представителей иерархии VCL или уже созданных программистом своих классов.
С другой стороны, механизмы регистрации и дальнейшего наследования уже существующих стандартов динамического связывания (Windows DLL) и компонентной архитектуры (VBX в Delphi 1.0 и OCX - в 32- разрядной версии Delphi) позволяют использовать в Delphi доступные внешние инструменты (например, компиляторы C++) и, созданные с их помощью, программные блоки.Самодостаточность Delphi для расширения набора доступных компонент является первым признаком открытости архитектуры этого инструмента.
Редакторы свойств и редакторы компонент - поведение IDE
Логично, что при визуальном подходе к определению характеристик компонент (работа в design- time), необходимы средства определения редакторов специфических свойств в Инспекторе Объектов (Object Inspector).
Рис. 1
Особенно остро встает для разработчиков компонент вопрос создания и использования редакторов свойств, когда свойства имеют сложный тип. Например, свойство может предоставлять ссылку на достаточно сложную структуру - запись или на строго определенных наследников одного из стандартных или пользовательских классов (возможные ситуации: 1) класс "множество данных" TDataSet - является предком и таблиц, и запросов, и хранимых процедур; можно сформулировать такую задачу, когда в качестве значения свойства в design-time должны выступать только запросы и таблицы, но, ни в коем случае - хранимые процедуры; 2) шрифт описывается рядом характеристик, представляемых вложенными записями).
Delphi предоставляет разработчику ряд базовых классов, входящих в иерархию VCL, которые предназначены для создания редакторов свойств.
Рис. 2
Стандартные редакторы свойств (более 20) являются наследниками базовых редакторов и, вместе с последними, доступны программисту для расширения/изменения функциональности, опять-таки, с использованием механизмов наследования и полиморфизма. Регистрация редакторов свойств и регистрации компонент аналогична регистрации самих компонент. Так как редакторы свойств и редакторы компонент определяют design-time, существование таких редакторов и возможность расширения их функциональности являются вторым признаком открытости Delphi.
Рис. 3
Генерация кода - эксперты
В процессе развития и, в том числе, визуализации средств разработки приложений, на фоне стандартизации пользовательского интерфейса в различных областях применения конечных систем, неотъемлемой частью таких инструментов стали генераторы кода и форм представления и ввода информации - эксперты.
Кроме того, что Delphi включает ряд уже готовых к использованию экспертов (например, DataBase Form Expert, генерирующий формы и соответствующий код для простых приложений обработки баз данных с использованием запросов), эта среда программирования предоставляет разработчикам интерфейс для создания собственных экспертов, встраиваемых в IDE.Необходимо отметить, что функциональность таких экспертов может не ограничиваться на генерации кода, в силу того, что интерфейс экспертов дает возможность получения информации о внутренних объектах IDE, таких как палитра компонент. Вследствие этого, под общим названием "эксперты" могут фигурировать программные модули, позволяющие управлять повелением IDE, окна дизайнера и ее редактора исходных текстов, а также генерировать отчетную информацию о создаваемом проекте. (На приведенном выше рисунке вы можете увидеть эксперт, разработанный в Delphi и встроенный в IDE; функциональность этого эксперта заключается в предоставлении разработчику информации об иерархии наследования зарегистрированных компонент без компиляции; в данном случае доступ осуществляется через меню "Help", хотя возможна регистрация и в "галерее" шаблонов Delphi).
Рис. 4
Наличие средств построения программных модулей генерации кода и обработки внутренней IDE- информации, называемых экспертами, являются третьим признаком открытости архитектуры Delphi.
Интеграция с внешними приложениями - открытые интерфейсы
Как следствие возможности обмена информацией с IDE, реальным кажется и интеграция среды разработки Delphi с внешними инструментальными средствами - системами контроля версий, мониторами транзакций, CASE-системами и т.п.
Рис. 5
И действительно, ряд производителей программных продуктов, относящихся к перечисленным категориям, заявил о поддержке ими Delphi на достаточно высоком уровне интеграции (подразумевая, например, для CASE-систем, не только генерацию кода в соответствии с синтаксисом Object Pascal, но и доступ к таким продуктам непосредственно из IDE). В качестве примера можно привести компанию Popkin Software (производителя CASE-средства System Architect), объявившую о поддержки Delphi в своих продуктах еще в августе 1995 года. Известен ряд систем контроля версий - Intersolv PVCS и MKS Source Integrity, способных работать с Delphi (32-разрядная версия PVCS входит в поставку Delphi Client/Server Suite 2.0, и, например, мониторов транзакций (существует опыт взаимодействия с Novell Tuxedo и др.).
Описанные возможности интеграции с внешними приложениями на базе совокупности открытых интерфейсов, определяют четвертый признак открытости архитектуры Delphi.
Delphi - оптимальный инструмент разработчика БД.
Наконец, мы можем концептуально представить архитектуру открытых интерфейсов Delphi. Она приведена на следующей диаграмме:
Рис. 6
Вследствие такой открытости архитектуры Delphi, большое количество третьих компаний уже выбросило на рынок (или объявило о соответствующих планах) как различные расширения библиотеки компонент VCL (более 200 только коммерческих наборов компонент на октябрь 1995г.) так и средства интеграции своих продуктов (external-site interface).
Получение результатов.
Дипломный проект был условно разбит на четыре этапа.
Анализ существующей структуры отделения. Анализ работы отделения.
Разработка модели АСУ ОРИТН.
Описание АРМа "ОРИТН в порядке".
Внедрение программного продукта.
На первом этапе был проведен детальный анализ существующей структуры отделения путем опроса и анкетирования специалистов отделения, ознакомлением с документацией и существующими отчетными формами.
Была предложена следующая схема автоматизации отделения. При поступлении больного дежурный врач заносит начальные сведения в базу данных ОРИТН. При занесении больному присваивается уникальный номер и он закрепляется за дежурным врачом на данные сутки. После регистрации активизируется пакет плановых мероприятий, предлагающий дежурному врачу выбрать и назначить необходимые анализы и процедуры. Данный пакет активизируется на рабочем месте медицинской сестры ежесуточно, которая после проведения конкретной процедуры фиксирует в пакете плановых мероприятий о выполнении или о не выполнении. "ОРИТН в порядке" контролирует выполнение всего пакета плановых мероприятий, в случае невыполнения хотя бы одного из пунктов система сигнализирует вплоть до полного завершения всех плановых мероприятий. Дежурный врач в случае необходимости составляет пакет экстренных мероприятий. Контролирование выполнения данного пакета выполняется аналогично предыдущему. Прекращение работы данных пакетов происходить после заполнения врачом формы о смерти или выписке. Полная история архивируется и остается в базе данных "ОРИТН в порядке".
АРМ "ОРИТН в порядке" реализован на языке Delphi. В программе реализованы 8 уровней доступа характеризованные разделением функций персонала по штатному расписанию.
Заведующий отделением.
Врач ординатор реаниматолог-неонатолог.
Старшая медицинская сестра.
Процедурная медицинская сестра.
Палатная медицинская сестра.
Сестра-хозяйка.
Санитарка палатная.
Санитарка автоклава.
У каждого работника персонала есть собственный уникальный пароль на доступ к программе. В начале каждых суток "ОРИТН в порядке" закрывает существующие сессии и предлагает новой смене зарегистрироваться. Затем происходит закрепление больных за врачами-ординаторами и медицинскими сестрами. Активизируются пакеты плановых мероприятий на рабочих местах врачей-ординаторов (с возможностью корректировки) и медицинских сестер. Врач-ординатор анализирует данные за прошедшие сутки и вносит необходимые изменения в один из пакетов.
6. Модуль "Администратор программы "ОРИТН в порядке""
Поскольку разграничение доступа не позволяет корректировать записи в базе данных, появилась необходимость в разработке. Данный модуль позволяет вносить коррективы в любой раздел БД.
При загрузке модуль проверяет наличие прав доступа и в случае наличия полномочий загружает основное окно (рис. 1п).
Рис. 1п
В наглядном виде представляются все данные, режим редактирования общепринятый и интуитивно понятный.
В виде закладок отображены поля БД, для осуществления операций ввода и удаления предусмотрены кнопочки. Ввод новой записи контролируется на уникальность.
Рис. 2п
На рис. 2п представлена одна из закладок "персонал".
Рис. 3п
Заключение
Модель автоматизации деятельности отделения РИТН МГБ №1 соответствует требованиям, разработанным в ходе построения модели. Стандартизированы нами формы отчетности приняты за основу при дальнейшей разработке региональной базы данных по учету больных в данной области медицины. Результатом проектирования стало написание статистической базы данных "ОРИТН в порядке" версии 1.0 и "модуля администратора" "ОРИТН в порядке" на языке Delphi 3.0. Проделанная работа одобрена руководством отделения РИТН, в лице зав. Отделением Челнокова С.Б.
Литература
1. С.Д. Кузнецов "Основы современных баз данных",
http://www.citforum.ru/database/osbd/contents.shtml
2. К. Дейта, "Введение в системы баз данных", Наука, 1980.
3. "Руководство по реляционной СУБД DB2", Финансы и статистика, 1988.
4. Дж. Ульман "Основы систем баз данных", Финансы и статистика, 1983.
5. Материалы 6-й Ежегодной Конференции Разработчиков Borland.
6. Периодические издания (1998 год): Delphi Informant, Delphi Developer, Microsoft System Journal, Dr. Dobb Journal, Компьютерр-Пресс и др.
7. WWW-серверы: Borland, Miller Friman, Turbo Power, ProtoView, Popkin Software, InterSolv, AOL и др.
8. "Delphi Developers Guide", S.Tiexeira & X. Pacheco, SAMS Publishing / Borland PRESS.
9. Каталоги программных продуктов "Delphi Only Tools" ZAC Catalog, "Delphi Power Tools" Informant Communications Group.
Приложение 1
Задание на дипломное проектирование
Студента специальности: 05.13.16 Гудониса Юрия Владимировича
Тема: Разработка программного обеспечения для автоматизации работы ОРИТН.
Целевая установка: Разработка базы данных и интерфейса программы для данных на поступающего в отделение больного.
Исходные данные: Паспортные данные т.е. Ф.И.О., дата рождения, дата поступления, рост, вес, диагноз при поступлении и т.д.
Начало проектирования:01.01.98 Конец проектирования 04.06.98
Содержание работы.
Исследование объекта проектирования.
Приведение в систему всей вводимой информации.
Реализация проекта:
Разработка интерфейса.
Разработка модуля администратора баз данных "ОРИТН в порядке"
Предварительное тестирование программы на месте.
Устранение ошибок и дополнение.
Окончательная установка программы.
Отчетный материал.
1. Пояснительная записка на листах.
2. Графики и схемы на листах.
Литература.
1. "Delphi Developers Guide", S.Tiexeira & X. Pacheco, SAMS Publishing / Borland PRESS.
2. Дж. Ульмана "Основы систем баз данных" (Финансы и статистика, 1983).
Подписи:
Задание получил студент: Ю. В. Гудонис
Руководитель проекта: С. Б. Челноков
Зав. Кафедрой: В. А. Острейковский
Приложение 2
Исходные тексты программы
Модуль "Администратор программы "ОРИТН в порядке""
Main.pas
unit Main;
interface
uses
Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs,
ExtCtrls, ComCtrls, StdCtrls, Buttons, ToolWin, Grids, DBGrids, DBCtrls;
type
TFrmMain = class(TForm)
Panel1: TPanel;
ToolBar1: TToolBar;
BitBtn1: TBitBtn;
PageControl1: TPageControl;
TabSheet1: TTabSheet;
TabSheet2: TTabSheet;
TabSheet3: TTabSheet;
TabSheet4: TTabSheet;
TabSheet5: TTabSheet;
TabSheet6: TTabSheet;
TabSheet7: TTabSheet;
TabSheet8: TTabSheet;
TabSheet9: TTabSheet;
Panel2: TPanel;
DBGrid1: TDBGrid;
PageControl2: TPageControl;
TabSheet10: TTabSheet;
TabSheet11: TTabSheet;
TabSheet12: TTabSheet;
TabSheet13: TTabSheet;
DBMemo1: TDBMemo;
DBMemo2: TDBMemo;
DBMemo3: TDBMemo;
DBMemo4: TDBMemo;
DBGrid2: TDBGrid;
Panel3: TPanel;
DBNavigator1: TDBNavigator;
Panel4: TPanel;
DBNavigator2: TDBNavigator;
Panel5: TPanel;
Panel6: TPanel;
Panel7: TPanel;
Panel8: TPanel;
Panel9: TPanel;
Panel10: TPanel;
Panel11: TPanel;
Panel12: TPanel;
EditDS: TEdit;
BitBtn2: TBitBtn;
BtnSAVE: TBitBtn;
Panel13: TPanel;
DBNavigator3: TDBNavigator;
DBGrid3: TDBGrid;
BitBtn3: TBitBtn;
Panel14: TPanel;
Panel15: TPanel;
DBNavigator4: TDBNavigator;
DBGrid4: TDBGrid;
BitBtn4: TBitBtn;
BitBtn5: TBitBtn;
BtnSAVEENTER: TBitBtn;
EditENTER: TEdit;
Panel16: TPanel;
BitBtn6: TBitBtn;
BitBtn7: TBitBtn;
BtnSAVEENTER2: TBitBtn;
EditENTER2: TEdit;
Panel17: TPanel;
DBNavigator5: TDBNavigator;
DBGrid5: TDBGrid;
Panel18: TPanel;
BitBtn8: TBitBtn;
BitBtn9: TBitBtn;
BtnSAVEPERSONAL: TBitBtn;
Panel19: TPanel;
DBNavigator6: TDBNavigator;
EditPERSONAL: TEdit;
DBGrid6: TDBGrid;
Panel20: TPanel;
BitBtn10: TBitBtn;
BitBtn11: TBitBtn;
BtnSAVEPTYPE: TBitBtn;
EditPTYPE: TEdit;
Panel21: TPanel;
DBNavigator7: TDBNavigator;
DBGrid7: TDBGrid;
Panel22: TPanel;
BitBtn12: TBitBtn;
BitBtn13: TBitBtn;
BtnSAVESTREET: TBitBtn;
EditSTREET: TEdit;
Panel23: TPanel;
DBNavigator8: TDBNavigator;
DBGrid8: TDBGrid;
Panel24: TPanel;
BitBtn14: TBitBtn;
BitBtn15: TBitBtn;
BtnSAVEVILLAGE: TBitBtn;
EditVILLAGE: TEdit;
Panel25: TPanel;
DBNavigator9: TDBNavigator;
DBGrid9: TDBGrid;
procedure EditDSChange(Sender: TObject);
procedure BitBtn2Click(Sender: TObject);
procedure BtnSAVEClick(Sender: TObject);
procedure EditDSClick(Sender: TObject);
procedure BitBtn4Click(Sender: TObject);
procedure BitBtn3Click(Sender: TObject);
procedure BitBtn5Click(Sender: TObject);
procedure BtnSAVEENTERClick(Sender: TObject);
procedure EditENTERChange(Sender: TObject);
procedure EditENTERClick(Sender: TObject);
procedure BitBtn6Click(Sender: TObject);
procedure BitBtn7Click(Sender: TObject);
procedure BtnSAVEENTER2Click(Sender: TObject);
procedure EditENTER2Change(Sender: TObject);
procedure EditENTER2Click(Sender: TObject);
procedure BitBtn8Click(Sender: TObject);
procedure BitBtn9Click(Sender: TObject);
procedure BtnSAVEPERSONALClick(Sender: TObject);
procedure EditPERSONALChange(Sender: TObject);
procedure EditPERSONALKeyPress(Sender: TObject; var Key: Char);
procedure BitBtn10Click(Sender: TObject);
procedure BitBtn11Click(Sender: TObject);
procedure BtnSAVEPTYPEClick(Sender: TObject);
procedure EditPTYPEChange(Sender: TObject);
procedure EditPTYPEKeyPress(Sender: TObject; var Key: Char);
procedure BitBtn12Click(Sender: TObject);
procedure BitBtn13Click(Sender: TObject);
procedure BtnSAVESTREETClick(Sender: TObject);
procedure EditSTREETChange(Sender: TObject);
procedure EditSTREETKeyPress(Sender: TObject; var Key: Char);
procedure BitBtn14Click(Sender: TObject);
procedure BitBtn15Click(Sender: TObject);
procedure BtnSAVEVILLAGEClick(Sender: TObject);
procedure EditVILLAGEChange(Sender: TObject);
procedure EditVILLAGEKeyPress(Sender: TObject; var Key: Char);
private
{ Private declarations }
public
{ Public declarations }
end;
var
FrmMain: TFrmMain;
implementation
uses AdminDM, DB;
{$R *.DFM}
procedure TFrmMain.EditDSChange(Sender: TObject);
begin
With DMAdmin do
begin
TblDS.Locate('TITLE', EditDS.Text, [loPartialKey]);
if (TblDSTITLE.Value <> EditDS.Text) and
(EditDS.Text <> '')
then
BtnSAVE.Enabled := True
else
BtnSAVE.Enabled := False;
TblDS.Locate('TITLE', EditDS.Text, [loPartialKey]);
end;
end;
procedure TFrmMain.BitBtn2Click(Sender: TObject);
begin
EditDS.Enabled := True;
EditDS.SetFocus;
end;
procedure TFrmMain.BtnSAVEClick(Sender: TObject);
begin
DMAdmin.TblDS.Insert;
DMAdmin.TblDSCODE.Value := DMAdmin.TblDS.RecordCount;
DMAdmin.TblDSTITLE.Value := EditDS.Text;
DMAdmin.TblDS.Post;
DMAdmin.TblDS.Refresh;
EditDS.Text := '';
EditDS.Enabled := False;
BtnSAVE.Enabled := False;
end;
procedure TFrmMain.EditDSClick(Sender: TObject);
begin
With DMAdmin do
begin
TblDS.Locate('TITLE', EditDS.Text, [loPartialKey]);
if (TblDSTITLE.Value <> EditDS.Text) and
(EditDS.Text <> '')
then
BtnSAVE.Enabled := True
else
BtnSAVE.Enabled := False;
TblDS.Locate('TITLE', EditDS.Text, [loPartialKey]);
end;
end;
procedure TFrmMain.BitBtn4Click(Sender: TObject);
begin
EditENTER.Enabled := True;
EditENTER.SetFocus;
end;
procedure TFrmMain.BitBtn3Click(Sender: TObject);
begin
EditDS.Text := '';
EditDS.Enabled := False;
BtnSAVE.Enabled := False;
end;
procedure TFrmMain.BitBtn5Click(Sender: TObject);
begin
EditENTER.Text := '';
EditENTER.Enabled := False;
BtnSAVEENTER.Enabled := False;
end;
procedure TFrmMain.BtnSAVEENTERClick(Sender: TObject);
begin
DMAdmin.TblENTERA.Insert;
DMAdmin.TblENTERACODE.Value :=
DMAdmin.TblENTERA.RecordCount;
DMAdmin.TblENTERATITLE.Value := EditENTER.Text;
DMAdmin.TblENTERA.Post;
DMAdmin.TblENTERA.Refresh;
EditENTER.Text := '';
EditENTER.Enabled := False;
BtnSAVEENTER.Enabled := False;
end;
procedure TFrmMain.EditENTERChange(Sender: TObject);
begin
With DMAdmin do
begin
TblENTERA.Locate('TITLE', EditENTER.Text, [loPartialKey]);
if (TblENTERATITLE.Value <> EditENTER.Text) and
(EditENTER.Text <> '')
then
BtnSAVEENTER.Enabled := True
else
BtnSAVEENTER.Enabled := False;
TblENTERA.Locate('TITLE', EditENTER.Text, [loPartialKey]);
end;
end;
procedure TFrmMain.EditENTERClick(Sender: TObject);
begin
With DMAdmin do
begin
TblENTERA.Locate('TITLE', EditENTER.Text, [loPartialKey]);
if (TblENTERTITLE.Value <> EditENTER.Text) and
(EditENTER.Text <> '')
then
BtnSAVEENTER.Enabled := True
else
BtnSAVEENTER.Enabled := False;
TblENTERA.Locate('TITLE', EditENTER.Text, [loPartialKey]);
end;
end;
procedure TFrmMain.BitBtn6Click(Sender: TObject);
begin
EditENTER2.Enabled := True;
EditENTER2.SetFocus;
end;
procedure TFrmMain.BitBtn7Click(Sender: TObject);
begin
EditENTER2.Text := '';
EditENTER2.Enabled := False;
BtnSAVEENTER2.Enabled := False;
end;
procedure TFrmMain.BtnSAVEENTER2Click(Sender: TObject);
begin
DMAdmin.TblENTER2A.Insert;
DMAdmin.TblENTER2ACODE.Value :=
DMAdmin.TblENTER2A.RecordCount;
DMAdmin.TblENTER2ATITLE.Value := EditENTER2.Text;
DMAdmin.TblENTER2A.Post;
DMAdmin.TblENTER2A.Refresh;
EditENTER2.Text := '';
EditENTER2.Enabled := False;
BtnSAVEENTER2.Enabled := False;
end;
procedure TFrmMain.EditENTER2Change(Sender: TObject);
begin
With DMAdmin do
begin
TblENTER2A.Locate('TITLE', EditENTER2.Text, [loPartialKey]);
if (TblENTER2ATITLE.Value <> EditENTER2.Text) and
(EditENTER2.Text <> '')
then
BtnSAVEENTER2.Enabled := True
else
BtnSAVEENTER2.Enabled := False;
TblENTER2A.Locate('TITLE', EditENTER2.Text, [loPartialKey]);
end;
end;
procedure TFrmMain.EditENTER2Click(Sender: TObject);
begin
With DMAdmin do
begin
TblENTER2A.Locate('TITLE', EditENTER2.Text, [loPartialKey]);
if (TblENTER2TITLE.Value <> EditENTER2.Text) and
(EditENTER2.Text <> '')
then
BtnSAVEENTER2.Enabled := True
else
BtnSAVEENTER2.Enabled := False;
TblENTER2A.Locate('TITLE', EditENTER2.Text, [loPartialKey]);
end;
end;
procedure TFrmMain.BitBtn8Click(Sender: TObject);
begin
EditPERSONAL.Enabled := True;
EditPERSONAL.SetFocus;
end;
procedure TFrmMain.BitBtn9Click(Sender: TObject);
begin
EditPERSONAL.Text := '';
EditPERSONAL.Enabled := False;
BtnSAVEPERSONAL.Enabled := False;
end;
procedure TFrmMain.BtnSAVEPERSONALClick(Sender: TObject);
begin
DMAdmin.TblPERSONAL.Insert;
DMAdmin.TblPERSONALID.Value :=
DMAdmin.TblPERSONAL.RecordCount + 1;
DMAdmin.TblPERSONALFIO.Value := EditPERSONAL.Text;
DMAdmin.TblPERSONAL.Post;
DMAdmin.TblPERSONAL.Refresh;
EditPERSONAL.Text := '';
EditPERSONAL.Enabled := False;
BtnSAVEPERSONAL.Enabled := False;
end;
procedure TFrmMain.EditPERSONALChange(Sender: TObject);
begin
With DMAdmin do
begin
TblPERSONAL.Locate('FIO', EditPERSONAL.Text, [loPartialKey]);
if (TblPERSONALFIO.Value <> EditPERSONAL.Text) and
(EditPERSONAL.Text <> '')
then
BtnSAVEPERSONAL.Enabled := True
else
BtnSAVEPERSONAL.Enabled := False;
TblPERSONAL.Locate('FIO', EditPERSONAL.Text, [loPartialKey]);
end;
end;
procedure TFrmMain.EditPERSONALKeyPress(Sender: TObject; var Key: Char);
begin
With DMAdmin do
begin
TblPERSONAL.Locate('FIO', EditPERSONAL.Text, [loPartialKey]);
if (TblPERSONALFIO.Value <> EditPERSONAL.Text) and
(EditPERSONAL.Text <> '')
then
BtnSAVEPERSONAL.Enabled := True
else
BtnSAVEPERSONAL.Enabled := False;
TblPERSONAL.Locate('FIO', EditPERSONAL.Text, [loPartialKey]);
end;
end;
procedure TFrmMain.BitBtn10Click(Sender: TObject);
begin
EditPTYPE.Enabled := True;
EditPTYPE.SetFocus;
end;
procedure TFrmMain.BitBtn11Click(Sender: TObject);
begin
EditPTYPE.Text := '';
EditPTYPE.Enabled := False;
BtnSAVEPTYPE.Enabled := False;
end;
procedure TFrmMain.BtnSAVEPTYPEClick(Sender: TObject);
begin
DMAdmin.TblPTYPE.Insert;
DMAdmin.TblPTYPECODE.Value := DMAdmin.TblPTYPE.RecordCount + 1;
DMAdmin.TblPTYPETITLE.Value := EditPTYPE.Text;
DMAdmin.TblPTYPE.Post;
DMAdmin.TblPTYPE.Refresh;
EditPTYPE.Text := '';
EditPTYPE.Enabled := False;
BtnSAVEPTYPE.Enabled := False;
end;
procedure TFrmMain.EditPTYPEChange(Sender: TObject);
begin
With DMAdmin do
begin
TblPTYPE.Locate('TITLE', EditPTYPE.Text, [loPartialKey]);
if (TblPTYPETITLE.Value <> EditPTYPE.Text) and
(EditPTYPE.Text <> '')
then
BtnSAVEPTYPE.Enabled := True
else
BtnSAVEPTYPE.Enabled := False;
TblPTYPE.Locate('TITLE', EditPTYPE.Text, [loPartialKey]);
end;
end;
procedure TFrmMain.EditPTYPEKeyPress(Sender: TObject; var Key: Char);
begin
With DMAdmin do
begin
TblPTYPE.Locate('TITLE', EditPTYPE.Text, [loPartialKey]);
if (TblPTYPETITLE.Value <> EditPTYPE.Text) and
(EditPTYPE.Text <> '')
then
BtnSAVEPTYPE.Enabled := True
else
BtnSAVEPTYPE.Enabled := False;
TblPTYPE.Locate('TITLE', EditPTYPE.Text, [loPartialKey]);
end;
end;
procedure TFrmMain.BitBtn12Click(Sender: TObject);
begin
EditSTREET.Enabled := True;
EditSTREET.SetFocus;
end;
procedure TFrmMain.BitBtn13Click(Sender: TObject);
begin
EditSTREET.Text := '';
EditSTREET.Enabled := False;
BtnSAVESTREET.Enabled := False;
end;
procedure TFrmMain.BtnSAVESTREETClick(Sender: TObject);
begin
DMAdmin.TblSTREET.Insert;
DMAdmin.TblSTREETCODE.Value :=
DMAdmin.TblSTREET.RecordCount + 1;
DMAdmin.TblSTREETTITLE.Value := EditSTREET.Text;
DMAdmin.TblSTREET.Post;
DMAdmin.TblSTREET.Refresh;
EditSTREET.Text := '';
EditSTREET.Enabled := False;
BtnSAVESTREET.Enabled := False;
end;
procedure TFrmMain.EditSTREETChange(Sender: TObject);
begin
With DMAdmin do
begin
TblSTREET.Locate('TITLE', EditSTREET.Text, [loPartialKey]);
if (TblSTREETTITLE.Value <> EditSTREET.Text) and
(EditSTREET.Text <> '')
then
BtnSAVESTREET.Enabled := True
else
BtnSAVESTREET.Enabled := False;
TblSTREET.Locate('TITLE', EditSTREET.Text, [loPartialKey]);
end;
end;
procedure TFrmMain.EditSTREETKeyPress(Sender: TObject; var Key: Char);
begin
With DMAdmin do
begin
TblSTREET.Locate('TITLE', EditSTREET.Text, [loPartialKey]);
if (TblSTREETTITLE.Value <> EditSTREET.Text) and
(EditSTREET.Text <> '')
then
BtnSAVESTREET.Enabled := True
else
BtnSAVESTREET.Enabled := False;
TblSTREET.Locate('TITLE', EditSTREET.Text, [loPartialKey]);
end;
end;
procedure TFrmMain.BitBtn14Click(Sender: TObject);
begin
EditVILLAGE.Enabled := True;
EditVILLAGE.SetFocus;
end;
procedure TFrmMain.BitBtn15Click(Sender: TObject);
begin
EditVILLAGE.Text := '';
Подобные документы
Высокоуровневые и низкоуровневые функции СУБД. Управление данными во внешней памяти. Главные особенности управления транзакциями, буферами. Ведение журнала изменений в базе данных (журнализация изменений). Обеспечение целостности данных и безопасности.
презентация [38,8 K], добавлен 14.10.2013Механизмы управления транзакциями в СУБД. Обзор средств удаленного взаимодействия с объектами. Разработка подсистемы управления транзакциями. Практический анализ производительности подсистемы. Способы защиты пользователей от опасных и вредных факторов.
дипломная работа [449,9 K], добавлен 14.03.2013Теоретические аспекты СУБД. Основные понятия. Функциональные возможности СУБД. Архитектура систем управления. Разработка базы данных. Крупные массивы данных размещают, как правило, отдельно от исполняемого программы, и организуют в виде базы данных.
курсовая работа [30,5 K], добавлен 23.02.2006Изучение областей использования вычислительной техники, истории систем управления данными во внешней памяти. Анализ разработки ряда стандартов в рамках языков описания и манипулирования данными. Обзор технологий по обмену данными между различными СУБД.
презентация [263,2 K], добавлен 30.05.2012Основные функции системы управления базами данных. Комплекс программных и лингвистических средств общего или специального назначения. Условия принятой технологии обработки данных. Управление буферами оперативной памяти. Журнализация и её значение.
курсовая работа [1,2 M], добавлен 19.01.2012Основные понятия базы данных и систем управления базами данных. Типы данных, с которыми работают базы Microsoft Access. Классификация СУБД и их основные характеристики. Постреляционные базы данных. Тенденции в мире современных информационных систем.
курсовая работа [46,7 K], добавлен 28.01.2014Внутренний язык СУБД для работы с данными. Результат компиляции DDL-операторов. Описание DML-языка, содержащего набор операторов для поддержки основных операций манипулирования содержащимися в базе данными. Организация данных и управление доступом в SQL.
лекция [131,0 K], добавлен 19.08.2013Основные понятия и типы связей, первичные и внешние ключи, реляционная модель данных. Основные функции СУБД, язык запросов SQL. Краткая характеристика настольных реляционных, объектно-ориентированных и корпоративных (промышленных) систем управления.
курсовая работа [3,4 M], добавлен 25.08.2010Создание автоматизированных систем управления для предприятий нефтяной и газовой промышленности. Система управления базами данных (СУБД), ее функциональные возможности, уровневая архитектура. Характеристика реляционных, объектных и распределенных СУБД.
курсовая работа [434,7 K], добавлен 20.07.2012Программные продукты компании Microsoft: Access, Visual FoxPro7.0, dBASE. Возможности интеграции, совместной работы и использования данных. Системы управления базами данных (СУБД), их основные функции и компоненты. Работа с данными в режиме таблицы.
курсовая работа [805,5 K], добавлен 15.12.2010
