Ѕаза знаний студента. –еферат, курсова€, контрольна€, диплом на заказ

курсовые,контрольные,дипломы,рефераты

–азработка программного обеспечени€ дл€ ќтделени€ –еанимации и »нтенсивной “ерапии новорожденных ћ√Ѕ N1 г. —ургута — ѕрограммирование, Ѕазы данных

ѕосмотреть видео по теме ƒиплома

ћинистерство общего и профессионального образовани€ –‘

—ургутский государственный университет

‘акультет информационных технологий

 афедра информатики и вычислительной техники

ƒипломна€ работа

Ќа тему

Ђ–азработка программного обеспечени€ дл€ ќтделени€ –еанимации и »нтенсивной “ерапии Ќоворожденных при ћуниципальной √ородской Ѕольнице є 1 города —ургутаї

¬ыполнил:† ёрий ¬. √удонис

–уководитель: „елноков —. Ѕ.

–ецензент:† Ўепелев ј.—.

—ургут 1998г.

—одержание

¬ведение

4

ѕостановка задачи

5

ќсновы современных баз данных

6

1.     Ѕазы данных и файловые системы

6

1.1. ‘айловые системы

8

1.1.1.              —труктуры файлов

9

1.1.2.              »менование файлов

11

1.1.3.              «ащита файлов

13

1.1.4.              –ежим многопользовательского доступа

14

1.2.         ќбласти применени€ файлов

15

1.3.         ѕотребности информационных систем

16

2.     ‘ункции —”Ѕƒ. “ипова€ организаци€ —”Ѕƒ. ѕримеры

21

2.1.         ќсновные функции —”Ѕƒ

22

2.1.1.              Ќепосредственное управление данными во внешней пам€ти

22

2.1.2.              ”правление буферами оперативной пам€ти

22

2.1.3.              ”правление транзакци€ми

23

2.1.4.              ∆урнализаци€

24

2.1.5.              ѕоддержка €зыков Ѕƒ

27

2.2.         “ипова€ организаци€ современной —”Ѕƒ

29

3.     –анние подходы к организации Ѕƒ. —истемы, основанные на инвертированных списках, иерархические и сетевые —”Ѕƒ. ѕримеры. —ильные места и недостатки ранних систем

31

3.1.         ќсновные особенности систем, основанных на инвертированных списках

33

3.1.1.              —труктуры данных

33

3.1.2.              ћанипулирование данными

34

3.1.3.              ќграничени€ целостности

35

3.2.         »ерархические системы

35

3.2.1.              »ерархические структуры данных

35

3.2.2.              ћанипулирование данными

37

3.2.3.              ќграничени€ целостности

37

3.3. —етевые системы

38

3.3.1. —етевые структуры данных

38

3.3.2.  ћанипулирование данными

40

3.3.3.  ќграничени€ целостности

41

3.3.4.  ƒостоинства и недостатки

41

“еоретические основы

41

4.              ќбщие пон€ти€ рел€ционного подхода к организации Ѕƒ. ќсновные концепции и термины

43

4.1.         Ѕазовые пон€ти€ рел€ционных баз данных

44

4.1.1.  “ип данных

44

4.1.2.      ƒомен

45

4.1.3.  —хема отношени€, схема базы данных

45

4.1.4.   ортеж, отношение

46

5.       ћетоды использованные дл€ решени€ задачи.

48

6.       ќткрыта€ архитектура Delphi

48

7.       ѕолученные результаты

56

8.       ћодуль Ђјдминистратор программы Ђќ–»“Ќ в пор€дкеїї

58

9.       «аключение

62

10.  Ћитература

63

12. ѕриложение 1 Ђ«адание на дипломное проектированиеї

64

13. ѕриложение 2 »сходные тексты программы ћодуль Ђјдминистратор программы Ђќ–»“Ќ в пор€дкеїї

65


¬ведение

†††††††††

ќтделение –еанимации Ќоворожденных† уже в течение семи лет занимаетс€ спасением жизней еще не познавших самой жизни младенцев. ƒемографическа€ ситуаци€ нашего региона достаточно благополучна€. –ождаемость год от года не только не падает но еще и растет, но т€желые услови€ крайнего севера и посто€нно ухудшающиес€ услови€ окружающей среды внос€т свои коррективы в полноценность подростающего поколени€. «а период с 1991 года количество поступающих в отделение ежегодно детей возросло почти в два раза,† соответственно возрос и поток информации необходимой дл€ создани€ и анализа статистических отчетов. ƒо последнего времени ввод и анализ данных производилс€ практически вручную, что называетс€ на пальцах. Ќе существовало единого стандарта на отчеты, что затрудн€ло анализ данных необходимых дл€ прин€ти€ правильных решений в выборе методов лечени€. —ургутское отделение ќ–»“Ќ на сегодн€шний день €вл€етс€ лучшим по –оссии, что позволило прин€ть его УстолицейФ в данной области медицины. ѕо этому на отделение возложена об€занность по стандартизации исходных данных и отчетов. — 1996 года в —ургуте функционирует окружной учебно-консультативный центр на базе отделени€ ќ–»“Ќ ћ√Ѕ є1. ќсновной задачей центра €вл€етс€ повышение квалификации врачей и консультативно-методическа€ помощь. —оздание на основе сети »нтернет статистического сервера в городе —ургуте на который будет стекатьс€ информаци€ со всего региона,† позволит центру практически молниеносно разрешить любую проблему, с которой к нему обращаютс€ врачи всего региона.†† «а основу данной системы будет вз€та модель ј—” построенна€ нами в ходе дипломного проектировани€.


ѕостановка задачи.

–азработка модели ј—” ќ–»“Ќ. –еализаци€ модели ј—” ќ–»“Ќ на €зыке Delphi корпорации Inprise. ¬недрение программного продукта.


ќсновы современных баз данных

†††††††††

Ѕазы данных и файловые системы

–ассмотрим общий смысл пон€тий Ѕƒ и —”Ѕƒ. Ќачнем с того, что с самого начала развити€ вычислительной техники образовались два основных направлени€ ее использовани€. ѕервое направление - применение вычислительной техники дл€ выполнени€ численных расчетов, которые слишком долго или вообще невозможно производить вручную. —тановление этого направлени€ способствовало интенсификации методов численного решени€ сложных математических задач, развитию класса €зыков программировани€, ориентированных на удобную запись численных алгоритмов, становлению обратной св€зи с разработчиками новых архитектур Ё¬ћ.

¬торое направление, которое непосредственно касаетс€ темы нашего дипломного проекта, это использование средств вычислительной техники в автоматических или автоматизированных информационных системах. ¬ самом широком смысле информационна€ система представл€ет собой программный комплекс, функции которого состо€т в поддержке надежного хранени€ информации в пам€ти компьютера, выполнении специфических дл€ данного приложени€ преобразований информации и/или вычислений, предоставлении пользовател€м удобного и легко осваиваемого интерфейса. ќбычно объемы информации, с которыми приходитс€ иметь дело таким системам, достаточно велики, а сама информаци€ имеет достаточно сложную структуру.  лассическими примерами информационных систем €вл€ютс€ банковские системы, системы резервировани€ авиационных или железнодорожных билетов, мест в гостиницах и т.д.† Ќе €вл€етс€ исключением и разработанна€ нами система Ђќ–»“Ќї.

Ќа самом деле, второе направление возникло несколько позже первого. Ёто св€зано с тем, что на заре вычислительной техники компьютеры обладали ограниченными возможност€ми в части пам€ти. ѕон€тно, что можно говорить о надежном и долговременном хранении информации только при наличии запоминающих устройств, сохран€ющих информацию после выключени€ электрического питани€. ќперативна€ пам€ть этим свойством обычно не обладает. ¬ начале использовались два вида устройств внешней пам€ти: магнитные ленты и барабаны. ѕри этом емкость магнитных лент была достаточно велика, но по своей физической природе они обеспечивали последовательный доступ к данным. ћагнитные же барабаны (они больше всего похожи на современные магнитные диски с фиксированными головками) давали возможность произвольного доступа к данными, но были ограниченного размера.

Ћегко видеть, что указанные ограничени€ не очень существенны дл€ чисто численных расчетов. ƒаже если программа должна обработать (или произвести) большой объем информации, при программировании можно продумать расположение этой информации во внешней пам€ти, чтобы программа работала как можно быстрее.

— другой стороны, дл€ информационных систем, в которых потребность в текущих данных определ€етс€ пользователем, наличие только магнитных лент и барабанов неудовлетворительно. ѕредставьте себе покупател€ билета, который сто€ у кассы должен дождатьс€ полной перемотки магнитной ленты. ќдним из естественных требований к таким системам €вл€етс€ средн€€ быстрота выполнени€ операций.

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

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

1.1. ‘айловые системы

»сторическим шагом €вилс€ переход к использованию централизованных систем управлени€ файлами. — точки зрени€ прикладной программы файл - это именованна€ область внешней пам€ти, в которую можно записывать и из которой можно считывать данные. ѕравила именовани€ файлов, способ доступа к данным, хран€щимс€ в файле, и структура этих данных завис€т от конкретной системы управлени€ файлами и, возможно, от типа файла. —истема управлени€ файлами берет на себ€ распределение внешней пам€ти, отображение имен файлов в соответствующие адреса во внешней пам€ти и обеспечение доступа к данным.

ѕерва€ развита€ файлова€ система была разработана фирмой IBM дл€ ее серии 360.   насто€щему времени она очень устарела, и мы не будем рассматривать ее подробно. «аметим лишь, что в этой системе поддерживались как чисто последовательные, так и индексно-последовательные файлы, а реализаци€ во многом опиралась на возможности только по€вившихс€ к этому времени контроллеров управлени€ дисковыми устройствами. ≈сли учесть к тому же, что пон€тие файла в OS/360 было выбрано как основное абстрактное пон€тие, которому соответствовал любой внешний объект, включа€ внешние устройства, то работать с файлами на уровне пользовател€ было очень неудобно. “ребовалс€ целый р€д громоздких и перегруженных детал€ми конструкций. ¬се это хорошо знакомо программистам среднего и старшего поколени€, которые прошли через использование отечественных аналогов компьютеров IBM.

1.1.1. —труктуры файлов

ƒальше мы будем говорить о более современных организаци€х файловых систем. Ќачнем со структур файлов. ѕрежде всего, практически во всех современных компьютерах основными устройствами внешней пам€ти €вл€ютс€ магнитные диски с подвижными головками, и именно они служат дл€ хранени€ файлов. “акие магнитные диски представл€ют собой пакеты магнитных пластин (поверхностей), между которыми на одном рычаге двигаетс€ пакет магнитных головок. Ўаг движени€ пакета головок €вл€етс€ дискретным, и каждому положению пакета головок логически соответствует цилиндр магнитного диска. Ќа каждой поверхности цилиндр "высекает" дорожку, так что кажда€ поверхность содержит число дорожек, равное числу цилиндров. ѕри разметке магнитного диска (специальном действии, предшествующем использованию диска) кажда€ дорожка размечаетс€ на одно и то же количество блоков таким образом, что в каждый блок можно записать по максимуму одно и то же число байтов. “аким образом, дл€ произведени€ обмена с магнитным диском на уровне аппаратуры нужно указать номер цилиндра, номер поверхности, номер блока на соответствующей дорожке и число байтов, которое нужно записать или прочитать от начала этого блока.

ќднако эта возможность обмениватьс€ с магнитными дисками порци€ми меньше объема блока в насто€щее врем€ не используетс€ в файловых системах. Ёто св€зано с двум€ обсто€тельствами. ¬о-первых, при выполнении обмена с диском аппаратура выполн€ет три основных действи€: подвод головок к нужному цилиндру, поиск на дорожке нужного блока и собственно обмен с этим блоком. »з всех этих действий в среднем наибольшее врем€ занимает первое. ѕоэтому существенный выигрыш в суммарном времени обмена за счет считывани€ или записывани€ только части блока получить практически невозможно. ¬о-вторых, дл€ того, чтобы работать с част€ми блоков, файлова€ система должна обеспечить соответствующего размера буфера оперативной пам€ти, что существенно усложн€ет распределение оперативной пам€ти.

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

¬ некоторых файловых системах базовый уровень доступен пользователю, но более часто прикрываетс€ некоторым более высоким уровнем, стандартным дл€ пользователей. –аспространены два основных подхода. ѕри первом подходе, свойственном, например, файловым системам операционных систем фирмы DEC RSX и VMS, пользователи представл€ют файл как последовательность записей.  ажда€ запись - это последовательность байтов посто€нного или переменного размера. «аписи можно читать или записывать последовательно или позиционировать файл на запись с указанным номером. Ќекоторые файловые системы позвол€ют структурировать записи на пол€ и объ€вл€ть некоторые пол€ ключами записи. ¬ таких файловых системах можно потребовать выборку записи из файла по ее заданному ключу. ≈стественно, что в этом случае файлова€ система поддерживает в том же (или другом, служебном) базовом файле дополнительные, невидимые пользователю, служебные структуры данных. –аспространенные способы организации ключевых файлов основываютс€ на технике кэшировани€ и B-деревьев. —уществуют и много ключевые способы организации файлов.

¬торой подход, ставший распространенным вместе с операционной системой UNIX, состоит в том, что любой файл представл€етс€ как последовательность байтов. »з файла можно прочитать указанное число байтов либо начина€ с его начала, либо предварительно произвед€ его позиционирование на байт с указанным номером. јналогично, можно записать указанное число байтов в конец файла, либо предварительно произвед€ позиционирование файла. «аметим, что тем не менее скрытым от пользовател€, но существующим во всех разновидност€х файловых систем ќ— UNIX, €вл€етс€ базовое блочное представление файла.

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

1.1.2. »менование файлов

ќстановимс€ коротко на способах именовани€ файлов. ¬се современные файловые системы поддерживают многоуровневое именование файлов за счет поддержани€ во внешней пам€ти дополнительных файлов со специальной структурой - каталогов.  аждый каталог содержит имена каталогов и/или файлов, содержащихс€ в данном каталоге. “аким образом, полное им€ файла состоит из списка имен каталогов плюс им€ файла в каталоге, непосредственно содержащем данный файл. –азница между способами именовани€ файлов в разных файловых системах состоит в том, с чего начинаетс€ эта цепочка имен.

¬ этом отношении имеютс€ два крайних варианта. ¬о многих системах управлени€ файлами требуетс€, чтобы каждый архив файлов (полное дерево справочников) целиком располагалс€ на одном дисковом пакете (или логическом диске, разделе физического дискового пакета, представл€емом с помощью средств операционной системы как отдельный диск). ¬ этом случае полное им€ файла начинаетс€ с имени дискового устройства, на котором установлен соответствующий диск. “акой способ именовани€ используетс€ в файловых системах фирмы DEC, очень близко к этому наход€тс€ и файловые системы персональных компьютеров. ћожно назвать эту организацию поддержанием изолированных файловых систем.

ƒругой крайний вариант был реализован в файловых системах операционной системы Multics. Ёта система заслуживает отдельного большого разговора, в ней был реализован целый р€д оригинальных идей, но мы остановимс€ только на особенност€х организации архива файлов. ¬ файловой системе Miltics пользователи представл€ли всю совокупность каталогов и файлов как единое дерево. ѕолное им€ файла начиналось с имени корневого каталога, и пользователь не об€зан был заботитьс€ об установке на дисковое устройство каких-либо конкретных дисков. —ама система, выполн€€ поиск файла по его имени, запрашивала установку необходимых дисков. “акую файловую систему можно назвать полностью централизованной.

 онечно, во многом централизованные файловые системы удобнее изолированных: система управлени€ файлами принимает на себ€ больше рутинной работы. Ќо в таких системах возникают существенные проблемы, если кому-то требуетс€ перенести поддерево файловой системы на другую вычислительную установку.  омпромиссное решение применено в файловых системах ќ— UNIX. Ќа базовом уровне в этих файловых системах поддерживаютс€ изолированные архивы файлов. ќдин из этих архивов объ€вл€етс€ корневой файловой системой. ѕосле запуска системы можно "смонтировать" корневую файловую систему и р€д изолированных файловых систем в одну общую файловую систему. “ехнически это производитс€ с помощью заведени€ в корневой файловой системе специальных пустых каталогов. —пециальный системный вызов курьер ќ— UNIX позвол€ет подключить к одному из этих пустых каталогов корневой каталог указанного архива файлов. ѕосле монтировани€ общей файловой системы именование файлов производитс€ так же, как если бы она с самого начала была централизованной. ≈сли учесть, что обычно монтирование файловой системы производитс€ при раскрутке системы, то пользователи ќ— UNIX обычно и не задумываютс€ об исходном происхождении общей файловой системы.

1.1.3. «ащита файлов

ѕоскольку файловые системы €вл€ютс€ общим хранилищем файлов, принадлежащих, вообще говор€, разным пользовател€м, системы управлени€ файлами должны обеспечивать авторизацию доступа к файлам. ¬ общем виде подход состоит в том, что по отношению к каждому зарегистрированному пользователю данной вычислительной системы дл€ каждого существующего файла указываютс€ действи€, которые разрешены или запрещены данному пользователю. —уществовали попытки реализовать этот подход в полном объеме. Ќо это вызывало слишком большие накладные расходы как по хранению избыточной информации, так и по использованию этой информации дл€ контрол€ правомочности доступа.

ѕоэтому в большинстве современных систем управлени€ файлами примен€етс€ подход к защите файлов, впервые реализованный в ќ— UNIX. ¬ этой системе каждому зарегистрированному пользователю соответствует пара целочисленных идентификаторов: идентификатор группы, к которой относитс€ этот пользователь, и его собственный идентификатор в группе. —оответственно, при каждом файле хранитс€ полный идентификатор пользовател€, который создал этот файл, и отмечаетс€, какие действи€ с файлом может производить он сам, какие действи€ с файлом доступны дл€ других пользователей той же группы, и что могут делать с файлом пользователи других групп. Ёта информаци€ очень компактна, при проверке требуетс€ небольшое количество действий, и этот способ контрол€ доступа удовлетворителен в большинстве случаев.

1.1.4. –ежим многопользовательского доступа

ѕоследнее, на чем мы остановимс€ в св€зи с файлами, - это способы их использовани€ в многопользовательской среде. ≈сли операционна€ система поддерживает многопользовательский режим, вполне реальна ситуаци€, когда два или более пользователей одновременно пытаютс€ работать с одним и тем же файлом. ≈сли все эти пользователи собираютс€ только читать файл, ничего страшного не произойдет. Ќо если хот€ бы один из них будет измен€ть файл, дл€ корректной работы этой группы требуетс€ взаимна€ синхронизаци€.

»сторически в файловых системах примен€лс€ следующий подход. ¬ операции открыти€ файла (первой и об€зательной операции, с которой должен начинатьс€ сеанс работы с файлом) помимо прочих параметров указывалс€ режим работы (чтение или изменение). ≈сли к моменту выполнени€ этой операции от имени некоторой программы A файл уже находилс€ в открытом состо€нии от имени некоторой другой программы B (правильнее говорить "процесса", но мы не будем вдаватьс€ в терминологические тонкости), причем существующий режим открыти€ был несовместимым с желаемым режимом (совместимы только режимы чтени€), то в зависимости от особенностей системы программе A либо сообщалось о невозможности открыти€ файла в желаемом режиме, либо она блокировалась до тех пор, пока программа B не выполнит операцию закрыти€ файла.

«аметим, что в ранних верси€х файловой системы ќ— UNIX вообще не были реализованы какие бы то ни было средства синхронизации параллельного доступа к файлам. ќпераци€ открыти€ файла выполн€лась всегда дл€ любого существующего файла, если данный пользователь имел соответствующие права доступа. ѕри совместной работе синхронизацию следовало производить вне файловой системы (и особых средств дл€ этого ќ— UNIX не предоставл€ла). ¬ современных реализаци€х файловых систем ќ— UNIX по желанию пользовател€ поддерживаетс€ синхронизаци€ при открытии файлов.  роме того, существует возможность синхронизации нескольких процессов, параллельно модифицирующих один и тот же файл. ƒл€ этого введен специальный механизм синхронизационных захватов диапазонов адресов открытого файла.

1.2. ќбласти применени€ файлов

ѕосле этого краткого экскурса в историю файловых систем рассмотрим возможные области их применени€. ѕрежде всего, конечно, файлы примен€ютс€ дл€ хранени€ текстовых данных: документов, текстов программ и т.д. “акие файлы обычно образуютс€ и модифицируютс€ с помощью различных текстовых редакторов. —труктура текстовых файлов обычно очень проста: это либо последовательность записей, содержащих строки текста, либо последовательность байтов, среди которых встречаютс€ специальные символы (например, символы конца строки).

‘айлы с текстами программ используютс€ как входные тексты компил€торов, которые в свою очередь формируют файлы, содержащие объектные модули. — точки зрени€ файловой системы, объектные файлы также обладают очень простой структурой - последовательность записей или байтов. —истема программировани€ накладывает на эту структуру более сложную и специфичную дл€ этой системы структуру объектного модул€. ѕодчеркнем, что логическа€ структура объектного модул€ неизвестна файловой системе, эта структура поддерживаетс€ программами системы программировани€.

јналогично обстоит дело с файлами, формируемыми редакторами св€зей и содержащими образы выполн€емых программ. Ћогическа€ структура таких файлов остаетс€ известной только редактору св€зей и загрузчику - программе операционной системы. ѕримерно така€ же ситуаци€ с файлами, содержащими графическую и звуковую информацию.

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

1.3. ѕотребности информационных систем

ќднако ситуаци€ коренным образом отличаетс€ дл€ упоминавшихс€ в начале лекции информационных систем. Ёти системы главным образом ориентированы на хранение, выбор и модификацию посто€нно существующей информации. —труктура информации зачастую очень сложна, и хот€ структуры данных различны в разных информационных системах, между ними часто бывает много общего. Ќа начальном этапе использовани€ вычислительной техники дл€ управлени€ информацией проблемы структуризации данных решались индивидуально в каждой информационной системе. ѕроизводились необходимые надстройки над файловыми системами (библиотеки программ), подобно тому, как это делаетс€ в компил€торах, редакторах и т.д.

Ќо поскольку информационные системы требуют сложных структур данных, эти дополнительные индивидуальные средства управлени€ данными €вл€лись существенной частью информационных систем и практически повтор€лись от одной системы к другой. —тремление выделить и обобщить общую часть информационных систем, ответственную за управление сложно структурированными данными, €вилось, на наш взгл€д, первой побудительной причиной создани€ —”Ѕƒ. ќчень скоро стало пон€тно, что невозможно обойтись общей библиотекой программ, реализующей над стандартной базовой файловой системой более сложные методы хранени€ данных.

ѕокажем это на примере. ѕредположим, что мы хотим реализовать простую информационную систему, поддерживающую учет сотрудников некоторой организации. —истема должна выполн€ть следующие действи€: выдавать списки сотрудников по отделам, поддерживать возможность перевода сотрудника из одного отдела в другой, приема на работу новых сотрудников и увольнени€ работающих. ƒл€ каждого отдела должна поддерживатьс€ возможность получени€ имени руководител€ этого отдела, общей численности отдела, общей суммы выплаченной в последний раз зарплаты и т.д. ƒл€ каждого сотрудника должна поддерживатьс€ возможность выдачи номера удостоверени€ по полному имени сотрудника, выдачи полного имени по номеру удостоверени€, получени€ информации о текущем соответствии занимаемой должности сотрудника и о размере его зарплаты.

ѕредположим, что мы решили основывать эту информационную систему на файловой системе и пользоватьс€ при этом одним файлом, расширив базовые возможности файловой системы за счет специальной библиотеки функций. ѕоскольку минимальной информационной единицей в нашем случае €вл€етс€ сотрудник, естественно потребовать, чтобы в этом файле содержалась одна запись дл€ каждого сотрудника.  акие пол€ должна содержать така€ запись? ѕолное им€ сотрудника (—ќ“–_»ћя), номер его удостоверени€ (—ќ“–_Ќќћ≈–), информацию о его соответствии занимаемой должности (дл€ простоты, "да" или "нет") (—ќ“–_—“ј“), размер зарплаты (—ќ“–_«ј–ѕ), номер отдела (—ќ“–_ќ“ƒ_Ќќћ≈–). ѕоскольку мы хотим ограничитьс€ одним файлом, та же запись должна содержать им€ руководител€ отдела (—ќ“–_ќ“ƒ_–” ).

‘ункции нашей информационной системы требуют, чтобы обеспечивалась возможность много ключевого доступа к этому файлу по уникальным ключам (не дублируемым в разных запис€х) —ќ“–_»ћя и —ќ“–_Ќќћ≈–.  роме того, должна обеспечиватьс€ возможность выбора всех записей с общем значением —ќ“–_ќ“ƒ_Ќќћ≈–, то есть доступ по неуникальному ключу. ƒл€ того, чтобы получить численность отдела или общий размер зарплаты, каждый раз при выполнении такой функции информационна€ система должна будет выбрать все записи о сотрудниках отдела и посчитать соответствующие общие значени€.

“аким образом мы видим, что даже дл€ такой простой системы ее реализаци€ на базе файловой системы, во-первых, требует создани€ достаточно сложной надстройки дл€ много ключевого доступа к файлам, и, во-вторых, вызывает требование существенной избыточности хранени€ (дл€ каждого сотрудника одного отдела повтор€етс€ им€ руководител€) и выполнение массовой выборки и вычислений дл€ получени€ суммарной информации об отделах.  роме того, если в ходе эксплуатации системы нам захочетс€, например, выдавать списки сотрудников, получающих заданную зарплату, то придетс€ либо полностью просматривать файл, либо реструктуризовывать его, объ€вл€€ ключевым поле —ќ“–_«ј–ѕ.

ѕервое, что приходит на ум, - это поддерживать два много ключевых файла: —ќ“–”ƒЌ» » и ќ“ƒ≈Ћџ. ѕервый файл должен содержать пол€ —ќ“–_»ћя, —ќ“–_Ќќћ≈–, —ќ“–_—“ј“, —ќ“–_«ј–ѕ и —ќ“–_ќ“ƒ_Ќќћ≈–, а второй - ќ“ƒ_Ќќћ≈–, ќ“ƒ_–” , ќ“ƒ_—ќ“–_«ј–ѕ (общий размер зарплаты) и ќ“ƒ_–ј«ћ≈– (общее число сотрудников в отделе). Ѕольшинство неудобств, перечисленных в предыдущем абзаце, будут преодолены.  аждый из файлов будет содержать только не дублируемую информацию, необходимости в динамических вычислени€х суммарной информации не возникает. Ќо заметим, что при таком переходе наша информационна€ система должна обладать некоторыми новыми особенност€ми, сближающими ее с —”Ѕƒ.

ѕрежде всего, система должна теперь знать, что она работает с двум€ информационно св€занными файлами (это шаг в сторону схемы базы данных), должна знать структуру и смысл каждого пол€ (например, что —ќ“–_ќ“ƒ_Ќќћ≈– в файле —ќ“–”ƒЌ» » и ќ“ƒ_Ќќћ≈– в файле ќ“ƒ≈Ћџ означают одно и то же), а также понимать, что в р€де случаев изменение информации в одном файле должно автоматически вызывать модификацию во втором файле, чтобы их общее содержимое было согласованным. Ќапример, если на работу принимаетс€ новый сотрудник, то необходимо добавить запись в файл —ќ“–”ƒЌ» », а также соответствующим образом изменить пол€ ќ“ƒ_«ј–ѕ и ќ“ƒ_–ј«ћ≈– в записи файла ќ“ƒ≈Ћџ, описывающей отдел этого сотрудника.

ѕон€тие согласованности данных €вл€етс€ ключевым пон€тием баз данных. ‘актически, если информационна€ система (даже така€ проста€, как в нашем примере) поддерживает согласованное хранение информации в нескольких файлах, можно говорить о том, что она поддерживает базу данных. ≈сли же некотора€ вспомогательна€ система управлени€ данными позвол€ет работать с несколькими файлами, обеспечива€ их согласованность, можно назвать ее системой управлени€ базами данных. ”же только требование поддержани€ согласованности данных в нескольких файлах не позвол€ет обойтись библиотекой функций: така€ система должна иметь некоторые собственные данные (метаданные) и даже знани€, определ€ющие целостность данных.

Ќо это еще не все, что обычно требуют от —”Ѕƒ. ¬о-первых, даже в нашем примере неудобно реализовывать такие запросы как "выдать общую численность отдела, в котором работает ѕетр »ванович —идоров". Ѕыло бы гораздо проще, если бы —”Ѕƒ позвол€ла сформулировать такой запрос на близком пользовател€м €зыке. “акие €зыки называютс€ €зыками запросов к базам данных. Ќапример, на €зыке SQL наш запрос можно было бы выразить в форме:

SELECT ќ“ƒ_–ј«ћ≈–

FROM —ќ“–”ƒЌ» », ќ“ƒ≈Ћџ

WHERE —ќ“–_»ћя = "ѕ≈“– »¬јЌќ¬»„ —»ƒќ–ќ¬"

AND —ќ“–_ќ“ƒ_Ќќћ≈– = ќ“ƒ_Ќќћ≈–

“аким образом, при формулировании запроса —”Ѕƒ позволит не задумыватьс€ о том, как будет выполн€тьс€ этот запрос. —реди ее метаданных будет содержатьс€ информаци€ о том, что поле —ќ“–_»ћя €вл€етс€ ключевым дл€ файла —ќ“–”ƒЌ» », а ќ“ƒ_Ќќћ≈– - дл€ файла ќ“ƒ≈Ћџ, и система сама воспользуетс€ этим. ≈сли же возникнет потребность в получении списка сотрудников, не соответствующих занимаемой должности, то достаточно предъ€вить системе запрос

SELECT —ќ“–_»ћя, —ќ“–_Ќќћ≈–

FROM —ќ“–”ƒЌ» »

WHERE —ќ“–_—“ј“ = "Ќ≈“",

и система сама выполнит необходимый полный просмотр файла —ќ“–”ƒЌ» », поскольку поле —ќ“–_—“ј“ не €вл€етс€ ключевым.

ƒалее, представьте себе, что в нашей первоначальной реализации информационной системы, основанной на использовании библиотек расширенных методов доступа к файлам, обрабатываетс€ операци€ регистрации нового сотрудника. —леду€ требовани€м согласованного изменени€ файлов, информационна€ система вставила новую запись в файл —ќ“–”ƒЌ» » и собиралась модифицировать запись файла ќ“ƒ≈Ћџ, но именно в этот момент произошло аварийное выключение питани€. ќчевидно, что после перезапуска системы ее база данных будет находитьс€ в рассогласованном состо€нии. ѕотребуетс€ вы€снить это (а дл€ этого нужно €вно проверить соответствие информации с файлах —ќ“–”ƒЌ» » и ќ“ƒ≈Ћџ) и привести информацию в согласованное состо€ние. Ќасто€щие —”Ѕƒ берут такую работу на себ€. ѕрикладна€ система не об€зана заботитьс€ о корректности состо€ни€ базы данных.

Ќаконец, представим себе, что мы хотим обеспечить параллельную (например, многотерминальную) работу с базой данных сотрудников. ≈сли опиратьс€ только на использование файлов, то дл€ обеспечени€ корректности на все врем€ модификации любого из двух файлов доступ других пользователей к этому файлу будет блокирован (вспомните возможности файловых систем дл€ синхронизации параллельного доступа). “аким образом, зачисление на работу ѕетра »вановича —идорова существенно затормозит получение информации о сотруднике »ване —идоровиче ѕетрове, даже если они будут работать в разных отделах. Ќасто€щие —”Ѕƒ обеспечивают гораздо более тонкую синхронизацию параллельного доступа к данным.

“аким образом, —”Ѕƒ решают множество проблем, которые затруднительно или вообще невозможно решить при использовании файловых систем. ѕри этом существуют приложени€, дл€ которых вполне достаточно файлов; приложени€, дл€ которых необходимо решать, какой уровень работы с данными во внешней пам€ти дл€ них требуетс€, и приложени€, дл€ которых безусловно нужны базы данных.

‘ункции —”Ѕƒ. “ипова€ организаци€ —”Ѕƒ. ѕримеры

 ак было показано выше, традиционных возможностей файловых систем оказываетс€ недостаточно дл€ построени€ даже простых информационных систем. ћы вы€вили несколько потребностей, которые не покрываютс€ возможност€ми систем управлени€ файлами: поддержание логически согласованного набора файлов; обеспечение €зыка манипулировани€ данными; восстановление информации после разного рода сбоев; реально параллельна€ работа нескольких пользователей. ћожно считать, что если прикладна€ информационна€ система опираетс€ на некоторую систему управлени€ данными, обладающую этими свойствами, то эта система управлени€ данными €вл€етс€ системой управлени€ базами данных (—”Ѕƒ).

2.1. ќсновные функции —”Ѕƒ

Ѕолее точно, к числу функций —”Ѕƒ прин€то относить следующие:

2.1.1. Ќепосредственное управление данными во внешней пам€ти

Ёта функци€ включает обеспечение необходимых структур внешней пам€ти как дл€ хранени€ данных, непосредственно вход€щих в Ѕƒ, так и дл€ служебных целей, например, дл€ убыстрени€ доступа к данным в некоторых случа€х (обычно дл€ этого используютс€ индексы). ¬ некоторых реализаци€х —”Ѕƒ активно используютс€ возможности существующих файловых систем, в других работа производитс€ вплоть до уровн€ устройств внешней пам€ти. Ќо подчеркнем, что в развитых —”Ѕƒ пользователи в любом случае не об€заны знать, использует ли —”Ѕƒ файловую систему, и если использует, то как организованы файлы. ¬ частности, —”Ѕƒ поддерживает собственную систему именовани€ объектов Ѕƒ.

2.1.2. ”правление буферами оперативной пам€ти

—”Ѕƒ обычно работают с Ѕƒ значительного размера; по крайней мере этот размер обычно существенно больше доступного объема оперативной пам€ти. ѕон€тно, что если при обращении к любому элементу данных будет производитьс€ обмен с внешней пам€тью, то вс€ система будет работать со скоростью устройства внешней пам€ти. ѕрактически единственным способом реального увеличени€ этой скорости €вл€етс€ буферизаци€ данных в оперативной пам€ти. ѕри этом, даже если операционна€ система производит общесистемную буферизацию (как в случае ќ— UNIX), этого недостаточно дл€ целей —”Ѕƒ, котора€ располагает гораздо большей информацией о полезности буферизации той или иной части Ѕƒ. ѕоэтому в развитых —”Ѕƒ поддерживаетс€ собственный набор буферов оперативной пам€ти с собственной дисциплиной замены буферов.

«аметим, что существует отдельное направление —”Ѕƒ, которое ориентировано на посто€нное присутствие в оперативной пам€ти всей Ѕƒ. Ёто направление основываетс€ на предположении, что в будущем объем оперативной пам€ти компьютеров будет настолько велик, что позволит не беспокоитьс€ о буферизации. ѕока эти работы наход€тс€ в стадии исследований.

2.1.3. ”правление транзакци€ми

“ранзакци€ - это последовательность операций над Ѕƒ, рассматриваемых —”Ѕƒ как единое целое. Ћибо транзакци€ успешно выполн€етс€, и —”Ѕƒ фиксирует (COMMIT) изменени€ Ѕƒ, произведенные этой транзакцией, во внешней пам€ти, либо ни одно из этих изменений никак не отражаетс€ на состо€нии Ѕƒ. ѕон€тие транзакции необходимо дл€ поддержани€ логической целостности Ѕƒ. ≈сли вспомнить наш пример информационной системы с файлами —ќ“–”ƒЌ» » и ќ“ƒ≈Ћџ, то единственным способом не нарушить целостность Ѕƒ при выполнении операции приема на работу нового сотрудника €вл€етс€ объединение элементарных операций над файлами —ќ“–”ƒЌ» » и ќ“ƒ≈Ћџ в одну транзакцию. “аким образом, поддержание механизма транзакций €вл€етс€ об€зательным условием даже однопользовательских —”Ѕƒ (если, конечно, така€ система заслуживает названи€ —”Ѕƒ). Ќо пон€тие транзакции гораздо более важно в многопользовательских —”Ѕƒ.

“о свойство, что кажда€ транзакци€ начинаетс€ при целостном состо€нии Ѕƒ и оставл€ет это состо€ние целостным после своего завершени€, делает очень удобным использование пон€ти€ транзакции как единицы активности пользовател€ по отношению к Ѕƒ. ѕри соответствующем управлении параллельно выполн€ющимис€ транзакци€ми со стороны —”Ѕƒ каждый из пользователей может в принципе ощущать себ€ единственным пользователем —”Ѕƒ (на самом деле, это несколько идеализированное представление, поскольку в некоторых случа€х пользователи многопользовательских —”Ѕƒ могут ощутить присутствие своих коллег).

— управлением транзакци€ми в многопользовательской —”Ѕƒ св€заны важные пон€ти€ сериализации транзакций и сериального плана выполнени€ смеси транзакций. ѕод сериализаций параллельно выполн€ющихс€ транзакций понимаетс€ такой пор€док планировани€ их работы, при котором суммарный эффект смеси транзакций эквивалентен эффекту их некоторого последовательного выполнени€. —ериальный план выполнени€ смеси транзакций - это такой план, который приводит к сериализации транзакций. ѕон€тно, что если удаетс€ добитьс€ действительно сериального выполнени€ смеси транзакций, то дл€ каждого пользовател€, по инициативе которого образована транзакци€, присутствие других транзакций будет незаметно (если не считать некоторого замедлени€ работы по сравнению с однопользовательским режимом).

—уществует несколько базовых алгоритмов сериализации транзакций. ¬ централизованных —”Ѕƒ наиболее распространены алгоритмы, основанные на синхронизационных захватах объектов Ѕƒ. ѕри использовании любого алгоритма сериализации возможны ситуации конфликтов между двум€ или более транзакци€ми по доступу к объектам Ѕƒ. ¬ этом случае дл€ поддержани€ сериализации необходимо выполнить откат (ликвидировать все изменени€, произведенные в Ѕƒ) одной или более транзакций. Ёто один из случаев, когда пользователь многопользовательской —”Ѕƒ может реально (и достаточно непри€тно) ощутить присутствие в системе транзакций других пользователей.

2.1.4. ∆урнализаци€

ќдним из основных требований к —”Ѕƒ €вл€етс€ надежность хранени€ данных во внешней пам€ти. ѕод надежностью хранени€ понимаетс€ то, что —”Ѕƒ должна быть в состо€нии восстановить последнее согласованное состо€ние Ѕƒ после любого аппаратного или программного сбо€. ќбычно рассматриваютс€ два возможных вида аппаратных сбоев: так называемые м€гкие сбои, которые можно трактовать как внезапную остановку работы компьютера (например, аварийное выключение питани€), и жесткие сбои, характеризуемые потерей информации на носител€х внешней пам€ти. ѕримерами программных сбоев могут быть: аварийное завершение работы —”Ѕƒ (по причине ошибки в программе или в результате некоторого аппаратного сбо€) или аварийное завершение пользовательской программы, в результате чего некотора€ транзакци€ остаетс€ незавершенной. ѕервую ситуацию можно рассматривать как особый вид м€гкого аппаратного сбо€; при возникновении последней требуетс€ ликвидировать последстви€ только одной транзакции.

ѕон€тно, что в любом случае дл€ восстановлени€ Ѕƒ нужно располагать некоторой дополнительной информацией. ƒругими словами, поддержание надежности хранени€ данных в Ѕƒ требует избыточности хранени€ данных, причем та часть данных, котора€ используетс€ дл€ восстановлени€, должна хранитьс€ особо надежно. Ќаиболее распространенным методом поддержани€ такой избыточной информации €вл€етс€ ведение журнала изменений Ѕƒ.

∆урнал - это особа€ часть Ѕƒ, недоступна€ пользовател€м —”Ѕƒ и поддерживаема€ с особой тщательностью (иногда поддерживаютс€ две копии журнала, располагаемые на разных физических дисках), в которую поступают записи обо всех изменени€х основной части Ѕƒ. ¬ разных —”Ѕƒ изменени€ Ѕƒ журнализуютс€ на разных уровн€х: иногда запись в журнале соответствует некоторой логической операции изменени€ Ѕƒ (например, операции удалени€ строки из таблицы рел€ционной Ѕƒ), иногда - минимальной внутренней операции модификации страницы внешней пам€ти; в некоторых системах одновременно используютс€ оба подхода.

¬о всех случа€х придерживаютс€ стратегии "упреждающей" записи в журнал (так называемого протокола Write Ahead Log - WAL). √рубо говор€, эта стратеги€ заключаетс€ в том, что запись об изменении любого объекта Ѕƒ должна попасть во внешнюю пам€ть журнала раньше, чем измененный объект попадет во внешнюю пам€ть основной части Ѕƒ. »звестно, что если в —”Ѕƒ корректно соблюдаетс€ протокол WAL, то с помощью журнала можно решить все проблемы восстановлени€ Ѕƒ после любого сбо€.

—ама€ проста€ ситуаци€ восстановлени€ - индивидуальный откат транзакции. —трого говор€, дл€ этого не требуетс€ общесистемный журнал изменений Ѕƒ. ƒостаточно дл€ каждой транзакции поддерживать локальный журнал операций модификации Ѕƒ, выполненных в этой транзакции, и производить откат транзакции путем выполнени€ обратных операций, следу€ от конца локального журнала. ¬ некоторых —”Ѕƒ так и делают, но в большинстве систем локальные журналы не поддерживают, а индивидуальный откат транзакции выполн€ют по общесистемному журналу, дл€ чего все записи от одной транзакции св€зывают обратным списком (от конца к началу).

ѕри м€гком сбое во внешней пам€ти основной части Ѕƒ могут находитьс€ объекты, модифицированные транзакци€ми, не закончившимис€ к моменту сбо€, и могут отсутствовать объекты, модифицированные транзакци€ми, которые к моменту сбо€ успешно завершились (по причине использовани€ буферов оперативной пам€ти, содержимое которых при м€гком сбое пропадает). ѕри соблюдении протокола WAL во внешней пам€ти журнала должны гарантированно находитьс€ записи, относ€щиес€ к операци€м модификации обоих видов объектов. ÷елью процесса восстановлени€ после м€гкого сбо€ €вл€етс€ состо€ние внешней пам€ти основной части Ѕƒ, которое возникло бы при фиксации во внешней пам€ти изменений всех завершившихс€ транзакций и которое не содержало бы никаких следов незаконченных транзакций. ƒл€ того, чтобы этого добитьс€, сначала производ€т откат незавершенных транзакций (undo), а потом повторно воспроизвод€т (redo) те операции завершенных транзакций, результаты которых не отображены во внешней пам€ти. Ётот процесс содержит много тонкостей, св€занных с общей организацией управлени€ буферами и журналом. Ѕолее подробно мы рассмотрим это в соответствующей лекции.

ƒл€ восстановлени€ Ѕƒ после жесткого сбо€ используют журнал и архивную копию Ѕƒ. √рубо говор€, архивна€ копи€ - это полна€ копи€ Ѕƒ к моменту начала заполнени€ журнала (имеетс€ много вариантов более гибкой трактовки смысла архивной копии).  онечно, дл€ нормального восстановлени€ Ѕƒ после жесткого сбо€ необходимо, чтобы журнал не пропал.  ак уже отмечалось, к сохранности журнала во внешней пам€ти в —”Ѕƒ предъ€вл€ютс€ особо повышенные требовани€. “огда восстановление Ѕƒ состоит в том, что исход€ из архивной копии по журналу воспроизводитс€ работа всех транзакций, которые закончились к моменту сбо€. ¬ принципе, можно даже воспроизвести работу незавершенных транзакций и продолжить их работу после завершени€ восстановлени€. ќднако в реальных системах это обычно не делаетс€, поскольку процесс восстановлени€ после жесткого сбо€ €вл€етс€ достаточно длительным.

2.1.5. ѕоддержка €зыков Ѕƒ

ƒл€ работы с базами данных используютс€ специальные €зыки, в целом называемые €зыками баз данных. ¬ ранних —”Ѕƒ поддерживалось несколько специализированных по своим функци€м €зыков. „аще всего выдел€лись два €зыка - €зык определени€ схемы Ѕƒ (SDL - Schema Definition Language) и €зык манипулировани€ данными (DML - Data Manipulation Language). SDL служил главным образом дл€ определени€ логической структуры Ѕƒ, т.е. той структуры Ѕƒ, какой она представл€етс€ пользовател€м. DML содержал набор операторов манипулировани€ данными, т.е. операторов, позвол€ющих заносить данные в Ѕƒ, удал€ть, модифицировать или выбирать существующие данные. ћы рассмотрим более подробно €зыки ранних —”Ѕƒ в следующей лекции.

¬ современных —”Ѕƒ обычно поддерживаетс€ единый интегрированный €зык, содержащий все необходимые средства дл€ работы с Ѕƒ, начина€ от ее создани€, и обеспечивающий базовый пользовательский интерфейс с базами данных. —тандартным €зыком наиболее распространенных в насто€щее врем€ рел€ционных —”Ѕƒ €вл€етс€ €зык SQL (Structured Query Language). ¬ нескольких лекци€х этого курса €зык SQL будет рассматриватьс€ достаточно подробно, а пока мы перечислим основные функции рел€ционной —”Ѕƒ, поддерживаемые на "€зыковом" уровне (т.е. функции, поддерживаемые при реализации интерфейса SQL).

ѕрежде всего, €зык SQL сочетает средства SDL и DML, т.е. позвол€ет определ€ть схему рел€ционной Ѕƒ и манипулировать данными. ѕри этом именование объектов Ѕƒ (дл€ рел€ционной Ѕƒ - именование таблиц и их столбцов) поддерживаетс€ на €зыковом уровне в том смысле, что компил€тор €зыка SQL производит преобразование имен объектов в их внутренние идентификаторы на основании специально поддерживаемых служебных таблиц-каталогов. ¬нутренн€€ часть —”Ѕƒ (€дро) вообще не работает с именами таблиц и их столбцов.

язык SQL содержит специальные средства определени€ ограничений целостности Ѕƒ. ќп€ть же, ограничени€ целостности хран€тс€ в специальных таблицах-каталогах, и обеспечение контрол€ целостности Ѕƒ производитс€ на €зыковом уровне, т.е. при компил€ции операторов модификации Ѕƒ компил€тор SQL на основании имеющихс€ в Ѕƒ ограничений целостности генерирует соответствующий программный код.

—пециальные операторы €зыка SQL позвол€ют определ€ть так называемые представлени€ Ѕƒ, фактически €вл€ющиес€ хранимыми в Ѕƒ запросами (результатом любого запроса к рел€ционной Ѕƒ €вл€етс€ таблица) с именованными столбцами. ƒл€ пользовател€ представление €вл€етс€ такой же таблицей, как люба€ базова€ таблица, хранима€ в Ѕƒ, но с помощью представлений можно ограничить или наоборот расширить видимость Ѕƒ дл€ конкретного пользовател€. ѕоддержание представлений производитс€ также на €зыковом уровне.

Ќаконец, авторизаци€ доступа к объектам Ѕƒ производитс€ также на основе специального набора операторов SQL. »де€ состоит в том, что дл€ выполнени€ операторов SQL разного вида пользователь должен обладать различными полномочи€ми. ѕользователь, создавший таблицу Ѕƒ, обладает полным набором полномочий дл€ работы с этой таблицей. ¬ число этих полномочий входит полномочие на передачу всех или части полномочий другим пользовател€м, включа€ полномочие на передачу полномочий. ѕолномочи€ пользователей описываютс€ в специальных таблицах-каталогах, контроль полномочий поддерживаетс€ на €зыковом уровне.

Ѕолее точное описание возможных реализаций этих функций на основе €зыка SQL будет приведено в лекци€х, посв€щенных €зыку SQL и его реализации.

2.2. “ипова€ организаци€ современной —”Ѕƒ

≈стественно, организаци€ типичной —”Ѕƒ и состав ее компонентов соответствует рассмотренному нами набору функций. Ќапомним, что мы выделили следующие основные функции —”Ѕƒ:

Ј        управление данными во внешней пам€ти;

Ј        управление буферами оперативной пам€ти;

Ј        управление транзакци€ми;

Ј        журнализаци€ и восстановление Ѕƒ после сбоев;

Ј        поддержание €зыков Ѕƒ.

Ћогически в современной рел€ционной —”Ѕƒ можно выделить наиболее внутреннюю часть - €дро —”Ѕƒ (часто его называют Data Base Engine), компил€тор €зыка Ѕƒ (обычно SQL), подсистему поддержки времени выполнени€, набор утилит. ¬ некоторых системах эти части выдел€ютс€ €вно, в других - нет, но логически такое разделение можно провести во всех —”Ѕƒ.

ядро —”Ѕƒ отвечает за управление данными во внешней пам€ти, управление буферами оперативной пам€ти, управление транзакци€ми и журнализацию. —оответственно, можно выделить такие компоненты €дра (по крайней мере, логически, хот€ в некоторых системах эти компоненты выдел€ютс€ €вно), как менеджер данных, менеджер буферов, менеджер транзакций и менеджер журнала.  ак можно было пон€ть из первой части этой лекции, функции этих компонентов взаимосв€заны, и дл€ обеспечени€ корректной работы —”Ѕƒ все эти компоненты должны взаимодействовать по тщательно продуманным и проверенным протоколам. ядро —”Ѕƒ обладает собственным интерфейсом, не доступным пользовател€м напр€мую и используемым в программах, производимых компил€тором SQL (или в подсистеме поддержки выполнени€ таких программ) и утилитах Ѕƒ. ядро —”Ѕƒ €вл€етс€ основной резидентной частью —”Ѕƒ. ѕри использовании архитектуры "клиент-сервер" €дро €вл€етс€ основной составл€ющей серверной части системы.

ќсновной функцией компил€тора €зыка Ѕƒ €вл€етс€ компил€ци€ операторов €зыка Ѕƒ в некоторую выполн€емую программу. ќсновной проблемой рел€ционных —”Ѕƒ €вл€етс€ то, что €зыки этих систем (а это, как правило, SQL) €вл€ютс€ непроцедурными, т.е. в операторе такого €зыка специфицируетс€ некоторое действие над Ѕƒ, но эта спецификаци€ не €вл€етс€ процедурой, а лишь описывает в некоторой форме услови€ совершени€ желаемого действи€ (вспомните примеры из первой лекции). ѕоэтому компил€тор должен решить, каким образом выполн€ть оператор €зыка прежде, чем произвести программу. ѕримен€ютс€ достаточно сложные методы оптимизации операторов, которые мы подробно рассмотрим в следующих лекци€х. –езультатом компил€ции €вл€етс€ выполн€ема€ программа, представл€ема€ в некоторых системах в машинных кодах, но более часто в выполн€емом внутреннем машинно-независимом коде. ¬ последнем случае реальное выполнение оператора производитс€ с привлечением подсистемы поддержки времени выполнени€, представл€ющей собой, по сути дела, интерпретатор этого внутреннего €зыка.

Ќаконец, в отдельные утилиты Ѕƒ обычно выдел€ют такие процедуры, которые слишком накладно выполн€ть с использованием €зыка Ѕƒ, например, загрузка и выгрузка Ѕƒ, сбор статистики, глобальна€ проверка целостности Ѕƒ и т.д. ”тилиты программируютс€ с использованием интерфейса €дра —”Ѕƒ, а иногда даже с проникновением внутрь €дра.

–анние подходы к организации Ѕƒ. —истемы, основанные на инвертированных списках, иерархические и сетевые —”Ѕƒ. ѕримеры. —ильные места и недостатки ранних систем

ѕрежде, чем перейти к детальному и последовательному изучению рел€ционных систем Ѕƒ, остановимс€ коротко на ранних (дорел€ционных) —”Ѕƒ. ¬ этом есть смысл по трем причинам: во-первых, эти системы исторически предшествовали рел€ционным, и дл€ правильного понимани€ причин повсеместного перехода к рел€ционным системам нужно знать хот€ бы что-нибудь про их предшественников; во-вторых, внутренн€€ организаци€ рел€ционных систем во многом основана на использовании методов ранних систем; в-третьих, некоторое знание в области ранних систем будет полезно дл€ понимани€ путей развити€ пост рел€ционных —”Ѕƒ.

«аметим, что в этой лекции мы ограничиваемс€ рассмотрением только общих подходов к организации трех типов ранних систем, а именно, систем, основанных на инвертированных списках, иерархических и сетевых систем управлени€ базами данных. ћы не будем касатьс€ особенностей каких-либо конкретных систем; это привело бы к изложению многих технических деталей, которые, хот€ и интересны, наход€тс€ несколько в стороне от основной цели нашего курса. ƒетали можно найти в рекомендованной литературе.

Ќачнем с некоторых наиболее общих характеристик ранних систем:

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.1. Ѕазовые пон€ти€ рел€ционных баз данных

ќсновными пон€ти€ми рел€ционных баз данных €вл€ютс€ тип данных, домен, атрибут, кортеж, первичный ключ и отношение.


ƒл€ начала покажем смысл этих пон€тий на примере отношени€ —ќ“–”ƒЌ» », содержащего информацию о сотрудниках некоторой организации:

4.1.1. “ип данных

ѕон€тие тип данных в рел€ционной модели данных полностью адекватно пон€тию типа данных в €зыках программировани€. ќбычно в современных рел€ционных Ѕƒ допускаетс€ хранение символьных, числовых данных, битовых строк, специализированных числовых данных (таких как "деньги"), а также специальных "темпоральных" данных (дата, врем€, временной интервал). ƒостаточно активно развиваетс€ подход к расширению возможностей рел€ционных систем абстрактными типами данных (соответствующими возможност€ми обладают, например, системы семейства Ingres/Postgres). ¬ нашем примере мы имеем дело с данными трех типов: строки символов, целые числа и "деньги".

4.1.2. ƒомен

ѕон€тие домена более специфично дл€ баз данных, хот€ и имеет некоторые аналогии с подтипами в некоторых €зыках программировани€. ¬ самом общем виде домен определ€етс€ заданием некоторого базового типа данных, к которому относ€тс€ элементы домена, и произвольного логического выражени€, примен€емого к элементу типа данных. ≈сли вычисление этого логического выражени€ дает результат "истина", то элемент данных €вл€етс€ элементом домена.

Ќаиболее правильной интуитивной трактовкой пон€ти€ домена €вл€етс€ понимание домена как допустимого потенциального множества значений данного типа. Ќапример, домен "»мена" в нашем примере определен на базовом типе строк символов, но в число его значений могут входить только те строки, которые могут изображать им€ (в частности, такие строки не могут начинатьс€ с м€гкого знака).

—ледует отметить также семантическую нагрузку пон€ти€ домена: данные считаютс€ сравнимыми только в том случае, когда они относ€тс€ к одному домену. ¬ нашем примере значени€ доменов "Ќомера пропусков" и "Ќомера групп" относ€тс€ к типу целых чисел, но не €вл€ютс€ сравнимыми. «аметим, что в большинстве рел€ционных —”Ѕƒ пон€тие домена не используетс€, хот€ в Oracle V.7 оно уже поддерживаетс€.

4.1.3. —хема отношени€, схема базы данных

—хема отношени€ - это именованное множество пар {им€ атрибута, им€ домена (или типа, если пон€тие домена не поддерживаетс€)}. —тепень или "арность" схемы отношени€ - мощность этого множества. —тепень отношени€ —ќ“–”ƒЌ» » равна четырем, то есть оно €вл€етс€ 4-арным. ≈сли все атрибуты одного отношени€ определены на разных доменах, осмысленно использовать дл€ именовани€ атрибутов имена соответствующих доменов (не забыва€, конечно, о том, что это €вл€етс€ всего лишь удобным способом именовани€ и не устран€ет различи€ между пон€ти€ми домена и атрибута).

—хема Ѕƒ (в структурном смысле) - это набор именованных схем отношений.

4.1.4.  ортеж, отношение

 ортеж, соответствующий данной схеме отношени€, - это множество пар {им€ атрибута, значение}, которое содержит одно вхождение каждого имени атрибута, принадлежащего схеме отношени€. "«начение" €вл€етс€ допустимым значением домена данного атрибута (или типа данных, если пон€тие домена не поддерживаетс€). “ем самым, степень или "арность" кортежа, т.е. число элементов в нем, совпадает с "арностью" соответствующей схемы отношени€. ѕопросту говор€, кортеж - это набор именованных значений заданного типа.

ќтношение - это множество кортежей, соответствующих одной схеме отношени€. »ногда, чтобы не путатьс€, говор€т "отношение-схема" и "отношение-экземпл€р", иногда схему отношени€ называют заголовком отношени€, а отношение как набор кортежей - телом отношени€. Ќа самом деле, пон€тие схемы отношени€ ближе всего к пон€тию структурного типа данных в €зыках программировани€. Ѕыло бы вполне логично разрешать отдельно определ€ть схему отношени€, а затем одно или несколько отношений с данной схемой.

ќднако в рел€ционных базах данных это не прин€то. »м€ схемы отношени€ в таких базах данных всегда совпадает с именем соответствующего отношени€-экземпл€ра. ¬ классических рел€ционных базах данных после определени€ схемы базы данных измен€ютс€ только отношени€-экземпл€ры. ¬ них могут по€вл€тьс€ новые и удал€тьс€ или модифицироватьс€ существующие кортежи. ќднако во многих реализаци€х допускаетс€ и изменение схемы базы данных: определение новых и изменение существующих схем отношени€. Ёто прин€то называть эволюцией схемы базы данных.

ќбычным житейским представлением отношени€ €вл€етс€ таблица, заголовком которой €вл€етс€ схема отношени€, а строками - кортежи отношени€-экземпл€ра; в этом случае имена атрибутов именуют столбцы этой таблицы. ѕоэтому иногда говор€т "столбец таблицы", име€ в виду "атрибут отношени€".  огда мы перейдем к рассмотрению практических вопросов организации рел€ционных баз данных и средств управлени€, мы будем использовать эту житейскую терминологию. Ётой терминологии придерживаютс€ в большинстве коммерческих рел€ционных —”Ѕƒ.

–ел€ционна€ база данных - это набор отношений, имена которых совпадают с именами схем отношений в схеме Ѕƒ.

 ак видно, основные структурные пон€ти€ рел€ционной модели данных (если не считать пон€ти€ домена) имеют очень простую интуитивную интерпретацию, хот€ в теории рел€ционных Ѕƒ все они определ€ютс€ абсолютно формально и точно.


ћетоды, использованные дл€ решени€ задачи.

Ѕазовым† инструментом дл€ написани€ данного проекта был вз€т 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).


ѕолучение результатов.

ƒипломный проект был условно разбит на четыре этапа.

1)    јнализ существующей структуры отделени€. јнализ работы отделени€.

2)    –азработка модели ј—” ќ–»“Ќ.

3)    ќписание ј–ћа Уќ–»“Ќ в пор€дкеФ.

4)    ¬недрение программного продукта.

Ќа первом этапе был проведен детальный анализ существующей структуры отделени€ путем опроса и анкетировани€ специалистов отделени€, ознакомлением с документацией и существующими отчетными формами.

Ѕыла предложена следующа€ схема автоматизации отделени€. ѕри поступлении больного дежурный врач заносит начальные сведени€ в базу данных ќ–»“Ќ. ѕри занесении больному присваиваетс€ уникальный номер и он закрепл€етс€ за дежурным врачом на данные сутки. ѕосле регистрации активизируетс€ пакет плановых меропри€тий, предлагающий дежурному врачу выбрать и назначить необходимые анализы и процедуры. ƒанный пакет активизируетс€ на рабочем месте медицинской сестры ежесуточно, котора€ после проведени€ конкретной процедуры фиксирует в пакете плановых меропри€тий о выполнении или о не выполнении. Уќ–»“Ќ в пор€дкеФ контролирует выполнение всего пакета плановых меропри€тий, в случае невыполнени€ хот€ бы одного из пунктов система сигнализирует вплоть до полного завершени€ всех плановых меропри€тий. ƒежурный врач в случае необходимости составл€ет пакет экстренных меропри€тий.  онтролирование выполнени€ данного пакета выполн€етс€ аналогично предыдущему. ѕрекращение работы данных пакетов происходить после заполнени€ врачом формы о смерти или выписке. ѕолна€ истори€ архивируетс€ и остаетс€ в базе данных Уќ–»“Ќ в пор€дкеФ.

ј–ћ Уќ–»“Ќ в пор€дкеФ реализован на €зыке Delphi. ¬ программе реализованы 8 уровней доступа характеризованные разделением функций персонала по штатному расписанию.

1.  «аведующий отделением.

2.  ¬рач ординатор реаниматолог-неонатолог.

3.  —тарша€ медицинска€ сестра.

4.  ѕроцедурна€ медицинска€ сестра.

5.  ѕалатна€ медицинска€ сестра.

6.  —естра-хоз€йка.

7.  —анитарка палатна€.

8.  —анитарка автоклава.

” каждого работника персонала есть собственный уникальный пароль на доступ к программе. ¬ начале каждых суток Фќ–»“Ќ в пор€дкеФ закрывает существующие сессии и предлагает новой смене зарегистрироватьс€. «атем происходит закрепление больных за врачами-ординаторами и медицинскими сестрами. јктивизируютс€ пакеты плановых меропри€тий на рабочих местах врачей-ординаторов (с возможностью корректировки) и медицинских сестер. ¬рач-ординатор анализирует данные за прошедшие сутки и вносит необходимые изменени€ в один из пакетов.†



ћодуль Ђјдминистратор программы Ђќ–»“Ќ в пор€дкеїї

ѕоскольку разграничение доступа не позвол€ет корректировать записи в базе данных, по€вилась необходимость в разработке.† ƒанный модуль позвол€ет вносить коррективы в любой раздел Ѕƒ.

ѕри загрузке модуль провер€ет наличие прав доступа и в случае наличи€ полномочий загружает основное окно (рис. 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. ѕриведение в систему всей вводимой информации.†††††††††††††††††††††††††††††††††††††††††††††

3. –еализаци€ проекта: †††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††

Ј     –азработка интерфейса.†††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††

Ј     –азработка модул€ администратора† баз данных Уќ–»“Ќ в пор€дкеФ†††††

4. ѕредварительное тестирование программы на месте.††††††††††††††††††††††††††††††††

5. ”странение ошибок и дополнение.†††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††

6. ќкончательна€ установка программы.††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††

ќтчетный материал.

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 := '';

† EditVILLAGE.Enabled := False;

† BtnSAVEVILLAGE.Enabled := False;

end;

procedure TFrmMain.BtnSAVEVILLAGEClick(Sender: TObject);

begin

† DMAdmin.TblVILLAGE.Insert;

† DMAdmin.TblVILLAGECODE.Value := DMAdmin.TblVILLAGE.RecordCount + 1;

† DMAdmin.TblVILLAGETITLE.Value := EditVILLAGE.Text;

† DMAdmin.TblVILLAGE.Post;

† DMAdmin.TblVILLAGE.Refresh;

† EditVILLAGE.Text := '';

† EditVILLAGE.Enabled := False;

† BtnSAVEVILLAGE.Enabled := False;

end;

procedure TFrmMain.EditVILLAGEChange(Sender: TObject);

begin

† With DMAdmin do

††† begin

††††† TblVILLAGE.Locate('TITLE', EditVILLAGE.Text, [loPartialKey]);

††††† if (TblVILLAGETITLE.Value <> EditVILLAGE.Text) and

†††††††† (EditVILLAGE.Text <> '')

††††††† then

†††††††† †BtnSAVEVILLAGE.Enabled := True

††††††† else

††††††††† BtnSAVEVILLAGE.Enabled := False;

††††† TblVILLAGE.Locate('TITLE', EditVILLAGE.Text, [loPartialKey]);

††† end;

end;

procedure TFrmMain.EditVILLAGEKeyPress(Sender: TObject; var Key: Char);

begin

† With DMAdmin do

††† begin

††††† TblVILLAGE.Locate('TITLE', EditVILLAGE.Text, [loPartialKey]);

††††† if (TblVILLAGETITLE.Value <> EditVILLAGE.Text) and

†††††††† (EditVILLAGE.Text <> '')

††††††† then

††††††††† BtnSAVEVILLAGE.Enabled := True

††††††† else

†††††††† †BtnSAVEVILLAGE.Enabled := False;

††††† TblVILLAGE.Locate('TITLE', EditVILLAGE.Text, [loPartialKey]);

††† end;

end;

end.

AdminDM.pas

unit AdminDM;

interface

uses

† Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs,

† Db, DBTables;

type

† TDMAdmin = class(TDataModule)

††† TblDATA: TTable;

††† DatSrcDATA: TDataSource;

††† TblYEARS: TTable;

††† DatSrcYEARS: TDataSource;

††† TblDATAYEARNUM: TFloatField;

††† TblDATANN: TFloatField;

††† TblDATAHISTORYNUM: TFloatField;

††† TblDATAFIO: TStringField;

††† TblDATABORNDATE: TDateField;

††† TblDATABORNTIMEH: TSmallintField;

††† TblDATABORNTIMEM: TSmallintField;

††† TblDATAENTERDATE: TDateField;

††† TblDATAENTERTIMEH: TSmallintField;

††† TblDATAENTERTIMEM: TSmallintField;

††† TblDATASEX: TSmallintField;

††† TblDATABODYMASS: TFloatField;

††† TblDATABODYLENGHT: TFloatField;

††† TblDATAAPGAR: TStringField;

††† TblDATADN: TSmallintField;

††† TblDATAENTER: TFloatField;

††† TblDATAENTER2: TSmallintField;

††† TblDATAENTERDS: TMemoField;

††† TblDATADS: TFloatField;

††† TblDATADSNOTE: TMemoField;

††† TblDATASTATUS: TFloatField;

††† TblDATASTATUSDATE: TDateField;

††† TblDATASTATUSTIME: TStringField;

††† TblDATASTATUSNOTE: TMemoField;

††† TblDATAADDRESS: TFloatField;

††† TblDATAVILLAGE: TFloatField;

††† TblDATASTREET: TFloatField;

††† TblDATAHOME: TStringField;

††† TblDATAFLAT: TStringField;

††† TblDATAPHONE: TStringField;

††† TblDATANOTE: TMemoField;

††† TblDATAOPERATION: TFloatField;

††† TblDATAYEARs: TIntegerField;

††† TblDATABORNTIMEs: TStringField;

††† TblDATAENTERTIMEs: TStringField;

††† TblDATASEXs: TStringField;

††† TblDATADNs: TStringField;

††† TblENTER: TTable;

††† DatSrcENTER: TDataSource;

††† TblENTER2: TTable;

††† DatSrcENTER2: TDataSource;

††† TblDATAENTERs: TStringField;

††† TblDATAENTER2s: TStringField;

††† TblDS: TTable;

††† DatSrcDS: TDataSource;

††† TblDATADSs: TStringField;

††† TblDATASTATUSs: TStringField;

††† TblDATAADDRESSs: TStringField;

††† TblSTREET: TTable;

††† DatSrcSTREET: TDataSource;

††† TblVILLAGE: TTable;

††† DatSrcVILLAGE: TDataSource;

††† TblDATASTREETs: TStringField;

††† TblDATAVILLAGEs: TStringField;

††† TblDATA2: TTable;

††† DatSrcDATA2: TDataSource;

††† TblDATA2NN: TFloatField;

††† TblDATA2NEUROL1: TSmallintField;

††† TblDATA2NEUROL2: TSmallintField;

††† TblDATA2NEUROL3: TSmallintField;

††† TblDATA2NEUROL4: TSmallintField;

††† TblDATA2NEUROL5: TSmallintField;

††† TblDATA2NEUROL6: TSmallintField;

††† TblDATA2NEUROL7: TSmallintField;

††† TblDATA2NEUROL8: TSmallintField;

††† TblDATA2NEUROL9: TSmallintField;

††† TblDATA2NEUROL10: TSmallintField;

††† TblDATA2EXT1: TSmallintField;

††† TblDATA2EXT2: TSmallintField;

††† TblDATA2EXT3: TSmallintField;

††† TblDATA2EXT4: TSmallintField;

††† TblDATA2EXT5: TSmallintField;

††† TblDATA2EXT6: TSmallintField;

††† TblDATA2EXT7: TSmallintField;

††† TblDATA2EXT8: TSmallintField;

††† TblDATA2EXT9: TSmallintField;

††† TblDATA2EXT10: TSmallintField;

††† TblDATA2EXT11: TSmallintField;

††† TblDATA2NAMEs: TStringField;

††† TblENTERTITLE: TStringField;

††† TblENTERCODE: TSmallintField;

††† TblENTER2ENTERID: TSmallintField;

††† TblENTER2TITLE: TStringField;

††† TblENTER2CODE: TSmallintField;

††† TblDSTITLE: TStringField;

††† TblDSCODE: TFloatField;

††† TblSTREETTITLE: TStringField;

††† TblSTREETCODE: TFloatField;

††† TblVILLAGETITLE: TStringField;

††† TblVILLAGECODE: TFloatField;

††† TblENTER2ENTERs: TStringField;

††† TblENTERA: TTable;

††† DatSrcENTERA: TDataSource;

††† TblENTER2A: TTable;

††† DatSrcENTER2A: TDataSource;

††† TblENTER2AENTERID: TSmallintField;

††† TblENTER2ATITLE: TStringField;

††† TblENTER2ACODE: TSmallintField;

††† TblENTERATITLE: TStringField;

††† TblENTERACODE: TSmallintField;

††† TblENTER2AENTERs: TStringField;

††† TblPERSONAL: TTable;

††† DatSrcPERSONAL: TDataSource;

††† TblPTYPE: TTable;

††† DatSrcPTYPE: TDataSource;

††† TblPERSONALID: TSmallintField;

††† TblPERSONALFIO: TStringField;

††† TblPERSONALNAME1: TStringField;

††† TblPERSONALNAME2: TStringField;

††† TblPERSONALTYPE: TSmallintField;

††† TblPERSONALISACTIVE: TSmallintField;

††† TblPERSONALPSW: TStringField;

††† TblPTYPECODE: TSmallintField;

††† TblPTYPETITLE: TStringField;

††† TblPERSONALPTYPEs: TStringField;

††† procedure DMAdminCreate(Sender: TObject);

††† procedure TblDATACalcFields(DataSet: TDataSet);

† private

††† { Private declarations }

† public

††† { Public declarations }

† end;

var

† DMAdmin: TDMAdmin;

implementation

{$R *.DFM}

procedure TDMAdmin.DMAdminCreate(Sender: TObject);

begin

† TblDATA.Open;

† TblDATA2.Open;

† TblYEARS.Open;

† TblENTER.Open;

† TblENTER2.Open;

† TblDS.Open;

† TblSTREET.Open;

† TblVILLAGE.Open;

† TblENTERA.Open;

† TblENTER2A.Open;

† TblPERSONAL.Open;

† TblPTYPE.Open;

end;

procedure TDMAdmin.TblDATACalcFields(DataSet: TDataSet);

begin

† TblDATABORNTIMEs.Value := IntToStr(TblDATABORNTIMEH.Value) +

††††††††††††††††††††††††††† ':' +

††††††††††††† ††††††††††††††IntToStr(TblDATABORNTIMEM.Value);

† TblDATAENTERTIMEs.Value := IntToStr(TblDATAENTERTIMEH.Value) +

††††††††††††††††††††††††††† ':' +

††††††††††††††††††††††††††† IntToStr(TblDATAENTERTIMEM.Value);

† Case TblDATASEX.AsInteger of

††† 0:

††††† TblDATASexs.Value := 'ћ”∆';

††† 1:

††††† TblDATASexs.Value := '∆≈Ќ';

††† else

††††† TblDATASexs.Value := '???';

† end; { Case }

† Case TblDATADN.AsInteger of

††† 0:

††††† TblDATADNs.Value := 'ƒќЌ';

††† 1:

††††† TblDATADNs.Value := 'Ќ≈ƒ';

††† else

††††† TblDATADNs.Value := '???';

† end; { Case }

† Case TblDATASTATUS.AsInteger of

††† 0:

††††† TblDATASTATUSs.Value := 'Ѕ≈« »«ћ≈Ќ≈Ќ»…';

††† 1:

††††† TblDATASTATUSs.Value := 'ѕ≈–≈¬≈ƒ≈Ќ';

††† 2:

††††† TblDATASTATUSs.Value := '”ћ≈–';

††† else

††††† TblDATASTATUSs.Value := '???';

† end; { Case }

† Case TblDATAADDRESS.AsInteger of

††† 0:

††††† TblDATAADDRESSs.Value := '—”–√”“';

††† 1:

††††† TblDATAADDRESSs.Value := '–ј…ќЌ';

††† else

††††† TblDATAADDRESSs.Value := '???';

† end; { Case }

end;

end.

ћинистерство общего и профессионального образовани€ –‘ —ургутский государственный университет ‘акультет информационных технологий  афедра информатики и вычислительной техники ƒипломна€ работа Ќа тему Ђ–азработка программного обеспече

 

 

 

¬нимание! ѕредставленный ƒиплом находитс€ в открытом доступе в сети »нтернет, и уже неоднократно сдавалс€, возможно, даже в твоем учебном заведении.
—оветуем не рисковать. ”знай, сколько стоит абсолютно уникальный ƒиплом по твоей теме:

Ќовости образовани€ и науки

«аказать уникальную работу

ѕохожие работы:

 омплекс программ построени€ справочников по формальным €зыкам
–азработка системы автоматизации дл€ малого коммерческого предпри€ти€, работающего в сфере информационных услуг
–азработка ѕќ "ѕравила ƒорожного ƒвижени€"
—остав и функционирование »— построенной по принципу "клиент-сервер" дл€ численного обосновани€ решений
—опр€жение факсимильного аппарата с IBM PC
јвтоматизированное рабочее место регистрации и документировани€ комплекса средств автоматизации
„еловеко-машинный интерфейс, разработка эргономичного интерфейса
ј–ћ дл€ бухгалтерии ¬”«а
–азработка системы управлени€ работой коммерческой компании
‘ормирование структуры электронного учебника и решение задач на ней

—вои сданные студенческие работы

присылайте нам на e-mail

Client@Stud-Baza.ru