Главная страница
Навигация по странице:

  • INSERT INTO ARRAY | FROM MEMVAR

  • INSERT INTO kadr (fam, tab, szar) VALUES (Петров В.П., 860, 560000)

  • Формирование запросов из базы данных

  • SELECT FROM INTO WHERE GROUP BY

  • SELECT [DISTINCT] [ .] [AS ] [,[ .] [AS ]...] FROM [, ...] [[INTO ] | TO FILE

  • [AND | OR ...]]] [GROUP BY [, ...]] [HAVING ] [ORDER BY [ASC | DESC] [, [ASC | DESC]...]]

  • INSERT [BLANK], MODIFY STRUCTURE, PACK, REINDEX, ZAP.

  • USE EXCLUSIVE Функция FLOCK([область])

  • LOCK | RLOCK([ ] | [ , ])

  • UNLOCK [IN | ALL]

  • Методичка. Базы данных (ПОВТ) 2009. Методические указания для студентов дневного отделения специальности "Программное обеспечение вычислительной техники" Барнаул 2009 2


    Скачать 2 Mb.
    НазваниеМетодические указания для студентов дневного отделения специальности "Программное обеспечение вычислительной техники" Барнаул 2009 2
    АнкорМетодичка. Базы данных (ПОВТ) 2009.pdf
    Дата04.10.2019
    Размер2 Mb.
    Формат файлаpdf
    Имя файлаМетодичка. Базы данных (ПОВТ) 2009.pdf
    ТипМетодические указания
    #13290
    страница6 из 11

    Подборка по базе: Программа обучения студентов (Syllabus) по дисциплине Основы пра, методичка по цитологии 2019 для студентов.pdf, Методические указания к самостоятельной работе по дисциплине «Ме, Метод указания-19.docx, Методические указания по практике .doc, Методические указания по практике .doc, ГАОУ СПО Десмургия - Методические рекомендации для студентов по .
    1   2   3   4   5   6   7   8   9   10   11
    Дополнение базы
    INSERT INTO <файл БД> [(<поле1> [, <поле2> [, ...]])] VALUES (<выр1> [, <выр2>
    [,...]])
    Команда добавляет записи в конец существующего <файла базы данных>, используя
    <выражения>, перечисленные после слова VALUES. Если опущены имена полей, <выражения> будут запираться в последовательные поля <базы данных> в соответствии с ее структурой.
    Другая форма этой команды
    INSERT INTO <имя БД> ARRAY <массив> | FROM MEMVAR
    Переносит данные, содержащиеся в указанном <массиве> (опция ARRAY), или данные из временных переменных (опция MEMVAR). Такие переменные должны существовать и иметь те же самые имена, что и поля базы данных (но с префиксом М). Такие переменные, например, вырабатываются по команде SCATTER MEMVAR. Поля, для которых нет переменных с подходящими именами, останутся пустыми.
    Таким образом, команда INSERT соответствует паре команд -APPEND BLANK и
    REPLACE, но выполняется быстрее.
    В следующей команде база KADR.DBF дополняется новой записью с данными для полей
    FAM, TAB и SZAR.
    INSERT INTO kadr (fam, tab, szar) VALUES ('Петров В.П.', 860, 560000)
    Дополняемая база данных может быть и не открыта к моменту выполнения команды, однако после этого она останется открытой и активной.
    Формирование запросов из базы данных
    Команда является мощным средством обработки запросов. С ее помощью из базы- источника выделяются нужные данные и пересылаются на экран или в файл-приемник. Данные могут быть извлечены из разных баз, а также сгруппированы и упорядочены желаемым образом.
    Команда имеет массу опций-возможностей. Ввиду этого сначала приведем ее предварительный синтаксис, который позволит затем лучше осознать детали.
    SELECT <что выводится> FROM <откуда (источник)> INTO <куда (получатель)>
    WHERE <каким условиям должно отвечать> GROUP BY <колонки, по которым
    выполняется группирование> HAVING <условие группирования записей в одну строку>
    ORDER BY <в каком порядке выводить данные>
    Команда SELECT и вообще команды SQL мало зависят от текущего состояния среды
    FoxPro. Они сами открывают нужные им базы данных и индексные файлы. Если необходимых для выполнения команды индексов нет, они будут созданы, а по завершении команды уничтожены.
    Однако, конечно, лучше, чтобы применялись готовые индексы - для этого они должны быть

    39
    открыты (используются только компактные индексы). Исключение составляют структурные CDX- индексы. Открытие соответствующей базы данных (например, с помощью команды SELECT) открывает и индекс. Теперь рассмотрим ее более полный формат.
    SELECT
    [DISTINCT] [<псевдоним>.]<выражение> [AS <колонка>]
    [,[<псевдоним>.]<выражение> [AS <колонка>]...] FROM <БД> [,<БД> ...]
    [[INTO <получатель> ] | TO FILE <файл>
    [ADDITIVE] | TO PRINTER]] [NOCONSOLE] [PLAIN] [NOWAIT] [WHERE <условие
    связи>
    [AND <условие связи>...] [AND | OR <условие отбора>
    [AND | OR <условие отбора>...]]] [GROUP BY <колонка> [, <колонка> ...]] [HAVING
    <условие отбора> ]
    [ORDER BY <колонка> [ASC | DESC] [,<колонка> [ASC | DESC]...]]
    Работа в сети
    Работа в сети дня пользователя означает просто доступ к еще одному диску, где располагаются данные, доступные и другим пользователям. Одновременное чтение данных разными пользователями не вызывает практически никаких проблем при работе в сети.
    Конфликты между пользователями возникают в случае необходимости одновременного изменения данных. Такие ситуации должны, конечно, разрешаться корректно.
    Исполняемый файл программы может находиться где угодно - на сервере или на рабочей станции. Однако с точки зрения скорости загрузки, лучше, если на каждой рабочей станции находится свой экземпляр exe-файла, а с точки зрения сопровождения прикладной программы удобнее иметь единственную копию приложения. В случае, если программа все-таки находится на сервере, для ускорения работы системы временные файлы все равно должны формироваться на локальном диске. Для этого в файл CONFIG.FP каждой станции следует включить директивы, указывающее место их расположения (например С:\ТМР\):
    SORTWORK=C:\TMP\
    EDITWORK=C:\TMP\
    PROGWORK=C:\TMP\
    Размещение данных зависит от технологии обработки информации в конкретной системе.
    Общедоступные данные должны размещаться на сервере. Данные, важные только для конкретного пользователя, - на его станции. Результаты (базы данных, текстовые данные) - там, где они интересны. Здесь следует обратить внимание на справочники. Они, конечно, нужны всем пользователям, как формирующим запросы к базе, так и вводящим данные в нее. Во втором случае справочники ввода нужны очень часто и, если они размещены на сервере, это может вызывать раздражающие пользователя задержки. Здесь, если возможно, в начале сеанса следует скопировать справочники на рабочую станцию и использовать их отсюда. Однако в большинстве случаев это исключает возможность изменения справочников во время рабочего дня.
    По степени конфликтности и, соответственно, уровню сложности разработок сетевых приложений их можно условно разделить на несколько групп:
    1. Ввод/редактирование данных выполняется с одного рабочего места. Остальные пользователи имеют доступ только для чтения. Схема: "Один работник, много начальников".
    Это довольно распространенная ситуация чисто информационной системы.
    2. Несколько операторов могут иметь одновременный доступ для редактирования одной и той же записи. Например, одновременная обработка операционистками одного и того же счета в банке по запросу разных клиентов. Здесь отсутствие контроля может даже повлечь снятие со счета большей суммы денег, чем там имеется (повторное снятие).
    3. Несколько операторов могут иметь одновременный доступ для редактирования нескольких записей, например одновременная обработка пересекающихся списков товаров, запрошенных

    40
    разными покупателями с разных рабочих мест на складе. Может случиться, что некоторые предметы из перечня нужных товаров для первого покупателя будут уже проданы (зафиксированы как проданные) вторым продавцом второму покупателю, о чем не будет известно первому продавцу.
    Таким образом, первому покупателю может быть выписан счет, который невозможно полностью отоварить на складе (например, товар закончился). Эта ситуация, конечно, недопустима.
    4. Несколько операторов могут иметь одновременный доступ сразу ко многим или даже всем записям базы данных. Например, руководство торговой организации может пожелать изменить цены всех товаров из-за изменения курса доллара и при этом обслуживание клиентов (отпуск товаров) с рабочих мест не должно прекращаеться.
    5. Пользователь может захотеть сделать радикальные изменения данных, например изменить структуру базы данных. Такие действия совершенно исключают доступ к базе с других рабочих мест как для редактирования, так и для просмотра и вообще не могут быть выполнены в многопользовательском режиме. К этим командам относятся команды INSERT [BLANK],
    MODIFY STRUCTURE, PACK, REINDEX, ZAP.
    При работе в сети базы данных могут находиться в одном из четырех состояний:
    • Пользователь открывает базу для монопольной работы. База закрыта для других как для чтения, так и для записи.
    • Пользователь захватывает файл для ввода/преобразования/вывода данных. Остальные операторы в это время могут только читать такой файл. Эта ситуация очевидна в случае необходимости одновременного изменения нескольких и тем более всех (REPLACE ALL) записей. Формирование отчетов и сводных справок также может потребовать блокировки файлов. Если этого не сделать, в некоторых случаях возможно получение неполноценного документа. Решение о блокировке принимается в зависимости от важности справки. С учетом этого, можно предоставить пользователю возможность самому принять решение о блокировке/неблокировке базы в зависимости от требуемой достоверности отчета за счет временного отключения других пользователей. Впрочем, без очереди даже и начальник не сможет захватить файл/запись. Здесь уместно сказать, что формирование сложного и, следовательно, требующего заметного времени отчета нужно попытаться организовать не из рабочей базы/баз, а из ее копии. Копирование базы во временный файл обычно происходит гораздо быстрее, чем формирование капитального отчета. Это позволит уменьшить время блокировки базы. Далее можно сколько угодно исследовать и преобразовывать такую базу-копию без ущерба для других пользователей.
    • Пользователь захватывает запись для ввода данных. Остальные операторы в это время могут только читать эту запись.
    • Никто из пользователей не изменяет/выводит данные. База полностью доступна.
    В зависимости от потенциальной конфликтности действий операторов, программирование сетевых приложений усложняется на 10-100% сравнительно с однопользовательскими и часто вносит серьезные ограничения на используемые средства СУБД и технологию обработки данных.
    Если в однопользовательском режиме программист совершенно не ограничен в выборе средств обработки данных, то при работе в сети он должен постоянно учитывать наличие других пользователей и избегать действий, на длительное время ограничивающих их возможности и тем более операций, указанных в пункте 5.
    Работа в сети, по крайней мере, теоретически, не требует специальных приемов и команд.
    С помощью только обычной команды READ можно редактировать запись непосредственно в базе данных. При этом происходит автоматический захват записи (READ LOCK). Другие пользователи в это время могут ее только читать. Их попытки редактирования пресекаются с выдачей системного сообщения, на которое они могут реагировать сами или же оно может быть обработано как ERROR-событие. Режим повторных запросов здесь может быть определен с помощью установки параметров команады SET REPROCESS TO.

    41
    Однако, поскольку пользователь, захвативший запись, может удерживать ее неопределенное время (даже при наличии опции TIMEOUT в команде READ), это может сделать затруднительной работу всей системы в целом. В виду этого редактирование информации непосредственно в базе никогда не выполняется. Изменение данных осуществляется с использованием временных переменных. С записи из базы командой SCATTER делается копия, которая и подвергается обработке. Собственно изменение данных в базе выполняется командами присваивания
    REPLACE или GATHER. Это позволяет выполнить контроль доступности и захват нужных за- писей при сведении к минимуму времени "занятости" записей из базы коллективного пользования.
    При работе в сети практически исключается ввод/редактирование данных с помощью команды BROWSE/CHANGE (конечно, если пользователем не заблокирована вся база целиком). В этой команде фактом начала редактирования считается ввод любого символа в поле. Если в это же время другой пользователь пытается редактировать ту же запись, произойдет прерывание. Вместе с тем допускается использование команды для просмотра данных. При этом, однако, можно предусмотреть возможность (параллельного или поверх BROWSE) вызова пользователем READ-окна для ввода- редактирования. С тем, чтобы пользователь мог получить информацию об актуальных данных, следует периодически использовать команду SHOW WINDOW <окно> REFRESH. При этом в
    BROWSE-окно "засасывается" текущая на данный момент информация.
    Обычно техника доступа к отдельной записи базы в сети включает следующие (возможно не все) элементы:
    1. С помощью команды SCATTER во временных переменных создаются дубликаты полей редактируемой записи. Именно эти переменные, а не сами поля, пользователь будет в дальнейшем редактировать, а затем и сохранять в базе. Назовем эти переменные рабочими.
    2. Одновременно рабочие переменные копируются в некоторые другие переменные с тем, чтобы иметь еще один экземпляр данных из записи. Эти переменные остаются постоянными и служат для выявления факта изменения данных в базе другим пользователем за время с начала редактирования.
    Назовем их эталонными переменными.
    3. Строится интерфейс для редактирования рабочих переменных с помощью команды
    READ и выполняется их редактирование.
    4. По завершении редактирования делается попытка блокирования оригинальной записи в базе. Если она удалась, оригинал записи сравнивается с хранящимся эталоном и в зависимости от результата сравнения принимается одно из двух решений.
    • Если данные совпадают, отредактированные рабочие переменные заносятся в базу, запись разблокируется и работа с ней заканчивается.
    • Если данные различаются, значит за время редактирования другой пользователь изменил их. Запись разблокируется и в качестве эталонных значений запоминаются новые данные из базы. С этой целью в интерфейсе ввода должны быть предусмотрены места для индицирования эталонных переменных. Пользователь сравнивает новое содержимое записи с тем, что он хочет ввести в базу.
    Если нет содержательного противоречия между тем, что он хочет ввести, и эталоном, делается попытка блокировки и процесс повторяется. Если новое состояние записи исключает ее изменение первоначальным образом, пользователь пересматривает свой ввод или отказывается от редактирования.
    5. Если заблокировать запись не удалось, пользователь должен иметь возможность продолжить эти попытки, а еще лучше, чтобы приложение само выполняло попытки захвата зиписей, а пользователь, наоборот, мог бы их прервать в нужный (надоело ждать!) момент.
    Здесь рассмотрен самый полный вариант. На практике эталонная информация может понадобиться, а может и не понадобиться в зависимости от конкретных данных, с которыми вы имеете дело, ответственности действий и технологии обработки.

    42
    Например, уже рассмотренная ситуация в банке. Положим клиент пришел в банк и потребовал снять со своего счета некоторую сумму. Операционистка вызывает данные, относящиеся к этому клиенту и в случае, если имеющаяся сумма не меньше запрошенной, вводит значение изымаемой суммы. По завершении переговоров с клиентом и ввода реквизитов платежного требования, операционистка дает команду системе на снятие денег. В этот момент сначала запрашивается текущее содержимое записи и обнаруживается, например, что она уже не такая, как в момент первоначального обращения. Действия операционистки могут быть разными в зависимости от того, что она увидела. Если, положим, оказался измененным почтовый адрес клиента, то его вероятно изменил другой работник банка, контролирующий реквизиты клиентов.
    Беспокоиться здесь не о чем - деньги могут быть сняты. Если же изменилась сумма на счету
    (например, вследствие одновременного обращения к этому счету другого клиента с другого рабочего места в банке), операционистка (и/или прикладная система) должна убедиться, что она покрывает запросы вкладчика и снятие возможно. В противном случае, клиенту должно быть отказано.
    Если иметь в виду именно банк, то (поскольку здесь очень высока ответственность действий и маловероятен сам факт одновременного обращения к счету с нескольких рабочих мест), скорее всего, доступ к данным будет организован таким образом, что другая операционистка не сможет их изменить до завершения работы первой Здесь, вероятно, можно надолго заблокировать запись и исключить потребность в анализе и обработке обнаруженного факта изменения данных другим пользователем. Однако есть сколько угодно примеров, когда обрабатываемая запись должна быть свободна постоянно для всех пользователей и допускается лишь очень кратковременный захват записи для занесения новых обновленных данных.
    Прежде, чем создавать какие-либо приложения, рассмотрим средства FoxPro, обеспечивающие работу в сети. FoxPro предоставляет программисту ряд команд и функций управления захватом данных в сети.
    Коллективный доступ к базам возможен только при задании установки
    SET EXCLUSIVE ON | OFF
    В файл CONFIG.FP или непосредственно в программу (прежде команд открытия баз данных) должна быть включена команда SET EXCLUSIVE OFF (в CONFIG.FP - директива
    EXCLUSIVE=OFF). По умолчанию - ON. Все базы, открываемые с этого момента, будут доступны всем пользователям. Базы, открытые до того, своего статуса не изменят. В файлах, открытых монопольно, далее не нужно выполнять каких-либо блокировок. Монопольный режим используется очень редко, обычно только администратором базы во внерабочее для других пользователей время.
    Да и установить монопольный доступ невозможно, если база/базы открыты другими пользователями.
    Установление монопольного режима может быть совмещено с открытием базы данных, если команда USE использует опцию EXCLUSIVE, т.е.
    USE <файл> EXCLUSIVE
    Функция
    FLOCK([область])
    делает попытку заблокировать базу данных в текущей или другой рабочей области. Если блокировка не удалась (файл уже кем-то захвачен), функция возвращает .F., иначе - .Т., и другие пользователи сети файл могут только читать.
    Функция
    LOCK | RLOCK([<область>] | [<вырC>,<область>])
    осуществляет блокировку записи/записей текущей (или из указанной области) базы данных.
    Если она удалась (запись не захвачена другим пользователем), возвращается значение .Т..
    Заблокированные записи доступны для чтения и изменения только пользователю, установившему блокировку. Остальные пользователи сети эти записи могут только читать. В противном случае функция возвращает .F..

    43
    Допускается множественная блокировка записей. Их номера, перечисленные через запятую, включаются в <вырС>, например: LOCK('26,27,34','kadr'). Если некоторые из записей не удалось заблокировать, возвращается значение .F.. Однако остальные записи останутся заблокированными.
    Возможность множественной блокировки доступна, только если установлено
    SET MULTILOCKS ON
    По умолчанию SET MULTILOCKS OFF - разрешено блокировать только одну запись.
    Допускается одновременная блокировка около 8000 записей в каждой рабочей области.
    Команда
    UNLOCK [IN <область> | ALL]
    снимает блокировки записей/файлов в текущей или указанной рабочей области.
    Команда действует только на блокировки, установленные данным пользователем. Параметр ALL снимает блокировки со всех баз во всех рабочих областях. Команда не влияет на статус баз, открытых монопольно. Изменение установки MULTILOCKS из ON в OFF или наоборот автоматически выполняет UNLOCK ALL.
    При интенсивном обращении к сетевой базе командой READ LOCK часто может возникать ситуация, когда пользователю временно запрещается доступ к записи/файлу, захваченной другим пользователем. Чтобы избежать необходимости раздражающего "ручного" повторения обращения к данным, может использоваться режим автоматического повтора попыток блокировки в течение заданного времени или заданное число раз.
    Этот режим определяется командой
    1   2   3   4   5   6   7   8   9   10   11


    написать администратору сайта