Н. Р. Бухараев Введение в программирование на sql в среде субд ms visual FoxPro icon

Н. Р. Бухараев Введение в программирование на sql в среде субд ms visual FoxPro




НазваН. Р. Бухараев Введение в программирование на sql в среде субд ms visual FoxPro
Сторінка1/5
Дата конвертації10.04.2013
Розмір0.91 Mb.
ТипДокументи
  1   2   3   4   5

Н.Р.Бухараев


Введение в программирование на SQL


в среде СУБД MS Visual FoxPro


Казань 2002


© Н.Р.Бухараев, доцент, к. ф.-м. н., Казанский государственный университет

Факультет вычислительной математики и кибернетики


Зачем мне SQL?

Введение в технологию "клиент-сервер".


Как показывает практика, системы управления баз данных (СУБД) составляют наиболее значительную часть всех используемых программных систем – при этом часть, все более увеличивающуюся в связи с развитием локальных и, особенно, глобальных компьютерных сетей. Язык структурированных запросов SQL (Structured Query Language)1 фактически играет роль стандарта языка коммуникации сетевых СУБД, часто работающих под управлением различных операционных систем и использующих разные форматы представления информации. "Встроенный" SQL не только является неотъемлемой частью любой современной СУБД, но и любой сколь-нибудь крупной системы программирования, ориентированной на использование технологии "клиент-сервер". Среди прочих достоинств SQL отметим максимальную компактность, обеспечивающую при этом полноценные средства обработки БД и логическую простоту, делающую SQL не только языком программирования, но и неоценимым средством проектирования и функционального описания достаточно больших программных систем. Сказанное объясняет несомненную важность изучения SQL.

Недостатки SQL – обратная сторона его достоинств. Стандартность SQL не идеальна – в действительности, различные СУБД использует отличающиеся диалекты языка, что делает далеко не тривиальным перенос определения и данных БД из одной среды в другую - в частности, т.н. "подъем" (upsizing) БД из локальной среды в сеть. Компактность и декларативность языка, отсутствие в нем традиционных структур управления (циклов, условных операторов и пр.) усложняет переход на SQL программистов, привыкших к процедурному программированию в стиле языков семейства xBase/dBase. В целом, характерный для SQL более абстрактный и высокоуровневый реляционный подход, т.е. взгляд на обработку данных как преобразование таблиц "в целом", сильно отличается по своей логике от характерного для языков этого семейства навигационного подхода - преобразования отдельных записей таблиц.


Цель настоящего пособия скромна - не заменить достаточно богатую "толстую" литературу по SQL и технологиям СУБД в целом, но скорее - подготовить к ее чтению начинающего осваивать эту обширную область, выделив (даже в ущерб если не точности, то полноте изложения) одновременно наиболее существенное и минимально достаточное. Пособие включает краткое теоретическое введение в терминологию реляционных СУБД и технологии "клиент-сервер", синтаксис языка SQL, встроенного в язык MS Visual FoxPro и типовые задания по СУБД. Автор заранее благодарен за все критические замечания и пожелания коллег и студентов, направленные на улучшение данного пособия как по содержанию, так и стилю изложения. Он особенно благодарен Р.Тагирову и В.Байрашевой, уже сделавших ряд ценных предложений подобного рода.

Диаграмма 1. Эволюция сетевых БД.


Как показывает принятое деление данных на локальные (local), т.е. хранимые на компьютере-клиенте и удаленные (remote), т.е. хранимые на сервере, в рамках этой технологии при необходимости возможно и распределение хранения данных.


Диаграмма 2. Навигационный и реляционный подход к СУБД.


Общее (в отличие от иерархической, сетевой и объектной моделей данных) - данные есть совокупность взаимосвязанных таблиц. Но -

^ Единица обработки ( аргументы и результаты команд)

при навигационном подходе - запись, таблица же - объединение (последовательность) записей;

при реляционном подходе - таблица (множество записей)


Диаграмма 3. SQL в составе Visual FoxPro.


Сфера приложения FoxPro SQL, в сравнении с другими частями языка


Во избежание недоразумений - Visual FoxPro не есть объектная или даже смешанная2 СУБД. Аппарат ООП применяется лишь для обработки оперативных данных.


^ Краткое введение в реляционные СУБД.

Базы данных как аппарат моделирования.


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

ER-диаграмма - графическое представление отношения сущность-связь,

отражающего некий факт реальности - здесь, "(Как правило), люди живут в домах"

в виде


^ Таблица (table) - n-арное отношение Т, т.е. произвольное множество n-ок (строк или записей таблицы), компоненты которых в СУБД принято называть столбцами или полями записи.


T={r=: c1D1,… cnDn}


Поля записи могут содержать лишь значения базовых, неструктурных или скалярных типов, а также общее для всех таких типов неопределенное значение NULL. Если, с точки зрения логики моделирования, таблица представляет некоторое понятие, класс единообразно описываемых объектов, то поля записей задают значимые, с точки зрения цели моделирования, атрибуты - характеристики, свойства, параметры этих объектов.


Как при любом моделировании, мы не пытаемся здесь полностью отразить наше понимание/знание объектов (“что есть человек?”), но руководствуемся принципом минимальной достаточности, т.е. отбора наиболее существенных, в контексте данной задачи, атрибутов объекта.


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


Пример описания классов объектов в виде таблиц.

ЛЮДИ =

{<номер_паспорта, фамилия_имя_отчество, пол, доход,... (другие атрибуты людей)>}

ДОМА =

{<номер_дома, название_улицы, город, число_этажей,...(другие атрибуты домов)>}


В отличие от привычного описания сложных типов в процедурных языках, определение таблицы не рекурсивно – таблицы не могут содержать в качестве полей другие таблицы.


Для описания нетривиальных, сложно структурированных объектов и их взаимосвязей используется механизм отношений или связей, реализуемых в виде ссылок между таблицами или, в терминологии СУБД - ключей.


dBase: все отношения определяются в ходе выполнения.

SQL: базовые отношения, отражающие ER-описание предметной области, фиксируются на этапе проектирования и составляют часть определения базы данных.


Точнее, пусть PK(r) - некоторое выражение над полями таблицы PT. Можно считать, что PK различает две записи r1,r2PT, если PK(r1)PK(r2). PK называется (первичным) ключом (primary key) таблицы, если оно позволяет идентифицировать каждую запись таблицы, отличить ее других:


r1,r2 PT (r1=r2 PK(r1)=PK(r2))3


В самом простом - но часто встречающемся на практике - случае ключом таблицы служит значение одного из ее полей (называемого в этом случае ключевым), в противном случае ключ называется составным. По договоренности, все поля записи должны образовывать ее первичный ключ - проще говоря, таблица не может содержать двух записей с полностью совпадающими значениями всех полей.


dBase: выражение-ключ – скалярного типа

SQL: выражение-ключ – список имен столбцов.


Так, в предыдущем примере номер паспорта (но, в силу существования однофамильцев - не фамилия!) – первичный ключ таблицы ЛЮДИ, а первые три поля таблицы ДОМА (адрес дома) образуют составной первичный ключ этой таблицы.


Далее, пусть FK(r) - выражение над полями другой таблицы CT. Запись r1, r1CT ссылается (references) на запись r2, r2PT, если FK(r1)=PT(r2). FK называется внешним ключом (foreign key) таблицы CT, если каждая запись в CT имеет соответствие в PT:


r1 CT r2PT (FK(r1)=PT(r2))


дочерняя

таблица

родительская

таблица

В этом случае таблица PT называется родительской (parent table), таблица CT - дочерней (child table), а соответствующее отношение - связью "многие-ко-многим". Если, к тому же, PT - первичный ключ таблицы PT и, соответственно, каждая запись CT ссылается на единственную запись PT, то получающееся функциональное отношение называют связью "многие-к-одному". Наконец, если эта функция инъективна, т.е. не принимает одинаковых значений на разных аргументах, соответствующую связь называют связью "один-к-одному".


^ Типы связей (отношений)4

(здесь для простоты рассматривается случай простых

ключевых полей с числовыми значениями)


Так, для того, чтобы отразить в нашей модели отношения вида “(Этот) человек живет в (этом) доме”, мы должны будем внести значение первичного ключа таблицы ДОМА (адрес дома) в соответствующие поля таблицы ЛЮДИ.


Отметьте, что вполне корректный логически, наш выбор слишком большего, по объему занимаемой памяти, первичного ключа в родительской таблице ДОМА не оправдан технически, что заставляет нас прибегнуть к стандартному в проектировании БД приему сжатия информации - кодировке.


Так, например, мы можем

а) добавить в таблицу ДОМА дополнительное ключевое поле код_дома – не отражающий никаких реальных атрибутов объекта, искусственный первичный ключ таблицы;

б) завести справочные (кодировочные) таблицы

УЛИЦЫ={<код_улицы, название_улицы>} и

ГОРОДА={<код_города,название_города>},

сопоставляющую длинным названиям улиц и городов некоторые краткие коды с тем, чтобы иметь возможность хранить в таблицах ДОМА и ЛЮДИ более краткие ключи вида

<номер_дома, код_улицы, код_города>

в) связать улицы с номерами имеющихся на них домов, а города – с названиями имеющихся в нем улиц, определив структуру введенных таблиц следующим образом

ЛЮДИ={<код_дома,...(другие атрибуты людей)>}

ДОМА={<код_дома, номер_дома, код_улицы,... (другие атрибуты домов)>},

УЛИЦЫ={<код_улицы, название_улицы, код_города>},

ГОРОДА={<код_города, название_города>},

Будем считать в дальнейшем, что мы приняли последний вариант решения (обоснование такого выбора - см. ниже о "сжатии информации"). Приведенный пример показывает, что соображения физической эффективности хранения и обработки данных могут потребовать уточнения (декомпозиции), но - не ломки! - начальной логической схемы.


В том - крайне нежелательном! - случае, когда задача моделирования подразумевает наличие связи между таблицами, но фактически некоторая запись дочерней таблицы не ссылается ни на одну запись родительской таблицы (т.е. содержит отсутствующий в родительской таблице значение ключа), то такую запись называют сиротой (orphan). По соглашению, запись с неопределенным явно, т.е. равным NULL, ключом сиротой не считается.


Так, в нашем примере запись в таблице ЛЮДИ будет сиротой, если она содержит ссылку на не существующий адрес дома – отсутствующее в таблице ДОМА значение поля код_дома. Запись со значением ссылки NULL ("временно не имеющий места жительства") сиротой не будет.


Функциональные связи наиболее популярны в СУБД. Связи "многие-ко-многим", т.е. отношения общего вида, трудны для понимания и обработки - их обычно стараются представить в виде нескольких отношений "один-ко-многим". Наличие связи "один-к-одному" означает (как правило), что удобнее иметь дело не с двумя, а с одной таблицей (их композицией по этому соответствию); такая связь чаще применяется лишь в случаях, когда лишь небольшое число записей одной таблице имеет соответствие в другой (отношение типа “быть подмножеством”).


В нашем модели-примере, очевидно, мы имеем дело со связью “один-ко-многим” между таблицами ЛЮДИ и ДОМА – в одном доме может жить много людей, но один человек не может считаться живущим в нескольких домах (отсюда - направление стрелки в первоначальной ER-диаграмме).


Осуществив разбиение (декомпозицию) информации о связи между домами и улицами, а также улицами и городами (которую мы намеревались первоначально хранить в таблице ДОМА) и вынеся ее в отдельные таблицы УЛИЦЫ и ГОРОДА, мы получили новые связи “один-ко-многим” между таблицами УЛИЦЫ-ДОМА и ГОРОДА-УЛИЦЫ.


Вернемся к поднятому ранее вопросу выбора вариантов кодирования (сжатия) информации. Очевидно, такое сжатие будет тем более эффективным, чем больше его “коэффициент” - среднее количество дочерних записей, приходящихся на одну родительскую запись. В худшем случае – связи “один-ко-одному” – мы в реальности лишь увеличим объем хранимой информации за счет введения избыточных кодов. Таким образом, (весьма нелегкая в практическом воплощении) стратегия определения структуры БД должна преследовать цель максимизации коэффициента сжатия. Теоретическим фундаментом такого определения является понятие нормальной формы таблиц. Не смотря на сложность теоретического и практического характера, центральной руководящей идеей здесь служит


^ Основной принцип нормализациине дублируй информацию (за очевидным исключением ключей-ссылок)! Каждая ее часть должна храниться в одном, и только одном месте - таблице, определение которой согласовано с логикой задачи. Сведения, которые могут быть выведены (формульно вычислены) – не информация и не должны храниться вообще.


В отличие от центрального для реляционного подхода понятия отношения (таблицы как множества записей), в основе нормальных форм (н.ф.) лежит понятие таблично задаваемой функции (соответствия), взгляд на таблицу как график зависимости значений не ключевых полей от значений ключевых. Первая н.ф. требует, что такая зависимость была действительно функциональной, т.е. однозначной, вторая - то, чтобы в случае составных ключей ее аргументом служил весь ключ, а не отдельные входящие в него поля; третья - то, чтобы ее аргументом служил только ключ, т.е. значения каждого не ключевого поля не зависели от значений никаких других полей, кроме ключевых.


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


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

Данные (информация) - это

не только (даже - не столько) значения,

но и средства их преобразования.


Таким образом, понятие данных приобретает существенно динамический характер. С другой стороны, понятие абстрактного типа данных статично в том смысле, что система типов должно быть предварительно определена, хотя бы в виде абстрактной схемы, до разработки конкретных алгоритмов, с учетом всех возможных в дальнейшем случаев их использования. Такая существенная перемена приоритетов выдвигает на передний, центральный план этапы концептуального анализа и проектирования, с использованием соответствующих логико-математических методов. По статистическим оценкам, соотношение между этапами проектирования и собственно кодирования составляет около 80/20 - пропорция, обратная по отношению к традиционным методам!


Для того, чтобы в процессе модификации - а именно, вставки (insert), обновления (update) и удаления (delete) записей - БД не перестала быть целостной, т.е. не перестала адекватно отражать реальное содержание предметной области, необходимо выполнение следующих требований - правил целостности, или "бизнес-правил":


  • таблицы БД не должны содержать нереальных данных, которые могут появиться как следствие ошибок программ обработки БД или некорректного ввода. Для этого в определение таблиц БД добавляют правила проверки (validation rules) значений поля или группы полей, определяющие необходимые условия их корректности;


так, например, значение поля номер_дома в таблице ДОМА должен принадлежать некоторому допустимому интервалу натуральных чисел – скажем, от 1 до 1000 (при более точном моделировании мы могли бы отражать встречающиеся в реальности номера домов вида натуральное-буква и сформулировать более сложное условие проверки корректности значения поля);


  • БД должна удовлетворять условию ссылочной целостности (referential integrity), т.е. в таблицы БД, - в результате тех же причин - не должны попадать записи-"сироты". Следовательно, модификация связанных таблиц должна быть согласованной. К наиболее простым и популярным вариантам такого согласования относят ситуации, когда модификация записи родительской таблицы является

а) каскадной (cascades), т.е. продолжается на соответствующие записи дочерней таблицы;

b) нулевой (nulls), т.е. устанавливающей ключи дочерних записей в NULL;

c) ограниченной (restricted), т.е. возможной и исполняемой лишь в тех случаях, когда у нее нет ни одной дочерней записи.


Как и правила проверки, варианты сохранения ссылочной целостности БД также являются частью ее определения. Обеспечивающие целостность стандартные хранимые процедуры называются триггерами.5 Разумеется, более сложные варианты согласования модификации двух и более таблиц могут потребовать реализации соответствующих пользовательских процедур-триггеров.


Так, в нашем примере наиболее естественно принять ограниченный вариант удаления – информация о доме не может быть удалена, пока таблица ЛЮДИ содержит хотя бы одну запись о человеке, в этом доме проживающем, и каскадный вариант модификации значений – изменение первичного ключа в любой записи таблицы ДОМА (т.е. одного из полей номер_дома, код_улицы, код_города) должно автоматически изменять атрибуты соответствующих записей дочерней таблицы ЛЮДИ.


dBase: обеспечение целостности данных целиком возлагается на программы клиента

SQL: обеспечение целостности базовой логической схемы возлагается на триггеры сервера


С точки зрения реляционного подхода, все команды СУБД рассматриваются как преобразователи одной или нескольких таблиц, результатом которых снова является таблица (новая или обновленная старая):


T := (T1,…,Tn)


(Стандартный) ^ SQL – фактически, язык, состоящий из одних присваиваний.


К командам модификации (редактирования таблиц) БД относят команды вставки, удаления и изменения групп записей таблицы.


В отличие от них, результатом команды запроса к БД является абстрактная, "виртуальная" таблица, не существующая физически в виде постоянно хранимого файла, но лишь отражающей текущее состояние реально физически хранимых, или – базовых таблиц БД. Цель использования таких таблиц очевидна – отобразить в развернутом, полном и доступном для пользователя виде - разном, для разных групп пользователей - интересующего именно его минимально достаточную по объему информацию о реальных объектах предметной области по компактно закодированной информации, содержащейся в базовых таблицах.


Так, естественная, для большинства пользователей, информация о домах должна включать не о введенных нами в целях экономии хранения кодах улиц и городов, но об их реальных названиях, хранящихся в базовых справочных таблицах УЛИЦЫ и ГОРОДА и, конечно, другие атрибуты домов из базовой таблицы ДОМА. В одних случаях, эта информация должна быть полной, включающей атрибуты всех проживающих в этих домах людей, в других - содержать лишь количество проживающих, относится лишь к одному городу и проч.


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


Итак, представления (views) – это абстрактные (пользовательские) таблицы, определение (но не содержимое!) которых храниться в виде именованных команд запроса как часть БД. Подобно базовым таблицам, представления могут служить аргументами других запросов и представлений, позволяя таким образом программисту определять сложные родо-видовые иерархии объектов предметной области.


Так, в нашей модели-примере естественно определить представление ДОМА1 – именованном запросе, “хранящем” раскодированную по таблицам ДОМА, УЛИЦЫ и ГОРОДА полную информацию о домах в виде, естественном для пользователя БД, и представление ЛЮДИ1, “содержащую” (с точки зрения пользователя БД) информацию о людях, включающую ссылки на представление ДОМА1 и базовую таблицу ЛЮДИ. В свою очередь, эти представления могут служить базой более конкретных представлений ЖИТЕЛИ_КАЗАНИ и ЖИТЕЛИ_ЦЕНТРА.


Пример иерархии представлений. Здесь стрелки отмечают направление ссылок определений (обратное направлению данных при запросах)


В какой степени можно относиться к абстрактным таблицам также, как к реальным, физически существующим? С точки зрения пользователя, “содержимое” модифицируемых представлений можно редактировать с помощью команд модификации – но поскольку такового, в реальности, не существует, последнее может означать лишь подходящую модификацию базовых таблиц


Так, изменение, номера дома в некоторой записи представления ЖИТЕЛИ_ЦЕНТРА в реальности может означать лишь изменение значения дочернего ключа код_дома в таблице ЛЮДИ.6

По существу, модификация, т.е. преобразование представления T, основанном на запросе S к базовым таблицам T1,...,Tn, T=S(T1,..,Tn), к некоторому новому состоянию T’, означает требование к СУБД найти такое модификацию (преобразование) базовых таблиц к новому состоянию T1’,...,Tn’, которое вело бы к желаемому содержимому представления, T’=S(T1’,..,Tn’).


^ Модификация представления в действительности означает

модификацию данных базовой таблицы


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


Пример неосуществимости модификации представления. Заведем в нашей модели-примере представление, содержащее единственное поле – средний доход людей, информация о которых хранится в таблице БД. Как повысить средний доход – т.е. изменить значения поля доход в таблице ЛЮДИ? Как подсказывает математика (и наш жизненный опыт), решение этой задачи далеко не однозначно.

Помимо фундаментальной роли в построении/определении логики программной системы, понятие представления служит для сокрытия реализации не только в смысле сокрытия реальной структуры БД, но и сокрытия реальных источников данных, которые могут быть как локальными (находится физически на клиенте), так и удаленными (находится на сервере). Этот факт существенно используется для создания и безопасного для реальных данных тестирования локального прототипа программной системы, оперирующего локальными представлениями (базирующихся на локальных копиях таблиц уже существующей или будущей серверной БД), после окончательной отладки превращаемого (полу)автоматической заменой ссылок в реальную систему, оперирующую с удаленными данными. Такое преобразование локального прототипа в реальное сетевое приложение называется подъемом (upsizing) БД.


Введенное ранее понятие целостности БД - важнейший случай более общего понятия безопасности данных, подразумевающего включение в рассмотрение не только логической схемы самой БД, но и некоторую схему всех аспектов ее использования - от физического размещения и сохранности данных до определения прав пользователей - относимым к вопросам ведения или администрирования БД. Не касаясь здесь сколь-нибудь подробно этих вопросов, отметим лишь как существенно бóльшую безопасность данных, так и бóльшую сложность задач администрирования при использовании технологии "клиент-сервер"7. Одним из наиболее важных программных средств обеспечения безопасности данных является механизм поддержки транзакций.

  1   2   3   4   5



Схожі:

Н. Р. Бухараев Введение в программирование на sql в среде субд ms visual FoxPro iconПрограммирование
Введение в программирование на языке Pascal. Программа. Структура программы. Идентификатор. Правила записи идентификатора. Блок описаний....
Н. Р. Бухараев Введение в программирование на sql в среде субд ms visual FoxPro iconЯзык разметки xml. Назначение, возможности, перспективы
Сравнительная характеристика субд mysql и ms sql для задач управлениея контентом
Н. Р. Бухараев Введение в программирование на sql в среде субд ms visual FoxPro iconБази даних в інформаційних системах
БД) на електронних носіях. Для подальшого перетворення, передачі та використання бд застосовують спеціальні програми – системи управління...
Н. Р. Бухараев Введение в программирование на sql в среде субд ms visual FoxPro iconПрограммирование на языке Паскаль Введение

Н. Р. Бухараев Введение в программирование на sql в среде субд ms visual FoxPro iconЛабораторная работа №4 Введение в Visual Prolog
Он особенно хорошо приспособлен для решения проблем, которые касаются объектов и отношений между объектами
Н. Р. Бухараев Введение в программирование на sql в среде субд ms visual FoxPro iconПрактикум по субд access 97. Введение. Сбором и накоплением данных, их корректировкой и сортировкой, отбором
Особенно это актуально для тех, кто работает в информационной сфере производства, где основным сырьем и продуктом
Н. Р. Бухараев Введение в программирование на sql в среде субд ms visual FoxPro iconПриложение 6 к приказу Министерства образования
...
Н. Р. Бухараев Введение в программирование на sql в среде субд ms visual FoxPro iconПрактична робота № Програмування лінійних обчислювальних процесів
Запустити Visual Basic. Після запуску Visual Basic на екрані з'явиться діало-гове вікно, у якому можна вибрати тип додатку. Вибираємо...
Н. Р. Бухараев Введение в программирование на sql в среде субд ms visual FoxPro iconДокументи
1. /САПР/КИБЕРНЕТИКА.docx
2. /САПР/Л 01 Основн_...

Н. Р. Бухараев Введение в программирование на sql в среде субд ms visual FoxPro iconVisual Basic Основы работы с базами данных
Умение обращаться с файлами данных чуть ли не одна из самых важных ступений в обучении программированию на Visual Basic! Здесь я...
Додайте кнопку на своєму сайті:
Документи


База даних захищена авторським правом ©te.zavantag.com 2000-2017
При копіюванні матеріалу обов'язкове зазначення активного посилання відкритою для індексації.
звернутися до адміністрації
Документи