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

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




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

^ IZDEL (K_IZDEL, IZDEL KHAR, ZENA_ED)

primary key (K_IZDEL);


KOMP (K_KOMP, KOMP, KHAR, ZENA_ED);

primary key (K_KOMP);


PSTV (K_PSTV, PSTV GOROD, ADR);

primary key (K_PSTV);


POKUP (K_POKUP, POKUP, GOROD, ADR);

primary key (K_POKUP);


SKLAD (N_SKLAD, FIO, K_KOMP, K_IZDEL, KOLVO, DATA_OPER);

foreign key (K_KOMP) references KOMP (K_KOMP);

foreign key (K_IZDEL) references IZDEL (K_IZDEL);


Проверка модели с помощью правил нормализации

На этом этапе необходимо проверить созданный для представления пользователя “начальник склада” приложения “Сборочное предприятие” набор отношений на соответствие всем требованиям процедуры нормализации отношений и включает следующие действия:

  • приведение к 1НФ, позволяющее удалить из отношений повторяющиеся группы атрибутов:

  • приведение ко 2НФ, позволяющее устранить частичную зависимость атрибутов от первичного ключа;

  • приведение к 3НФ, позволяющее удалить транзитивную зависимость атрибутов от первичного ключа;

  • приведение к нормальной форме Бойса-Кодда, позволяющее удалить из функциональных зависимостей оставшиеся аномалии


Чтобы убедиться, что каждое из отношений находятся, как минимум, в НФБК, проанализируем функциональные зависимости между этими отношениями.


^ IZDEL (K_IZDEL, IZDEL, KHAR, ZENA_ED)

Pr. key K_IZDEL

K_IZDELа IZDEL, KHAR, ZENA_ED;


KOMP (K_KOMP, KOMP, KHAR, ZENA_ED)

Pr. key K_KOMP

K_KOMPа KOMP, KHAR, ZENA_ED;


POKUP (K_POKUP, POKUP, GOROD, ADR);

Pr. key K_POKUP

K_POKUPа POKUP, GOROD, ADR;


PSTV (K_PSTV, PSTV, GOROD, ADR)

Pr. key K_PSTV

K_PSTVа PSTV, GOROD, ADR;


POST (N_POST, K_KOMP, K_PSTV, KOLVO, DATA_POST)

Pr. key N_POST

N_POSTа K_KOMP, K_PSTV, KOLVO, N_SKLAD, DATA_POST ;


OTGR (N_OTGR, K_IZDEL, K_POKUP, KOLVO, DATA_OTGR)

Pr. key N_OTGR

N_OTGR а K_IZDEL, K_POKUP, N_SKLAD, KOLVO, DATA_OTGR ;


SKLAD (N_SKLAD, FIO K_KOMP, K_DET, KOLVO, DATA_OPER);

N_SKLAD, K_KOMP, DATA_OPERа FIO, KOLVO;


Видим, что все эти отношения не содержат повторяющихся групп атрибутов и не имеют атрибутов, частично или транзитивно зависящих от первичных ключей этих отношений. Единственное, отношение SKLAD не находится в НФБК, но как мы видим оно не будет подвержено аномалиям обновления.


^ Спецификация требований представления пользователя “Менеджер по поставкам и по реализации”.


Требования к данным

1. Предприятие заключает договора на продажу готовых изделий с другими организациями.

2. Каждая такая организация является покупателем, информация о котором содержит сведения об уникальном номере, названии, городе и адресе.

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

^ 4. Сведения об изделиях содержат информацию о его уникальном номере, названии, характеристики и цене за единицу продукции.

5. Предприятие не все составляющие двигателя изготавливает само. Часть сырья и деталей оно закупает у других предприятий.

6. Эти предприятия являются поставщиками. В информацию и них входит уникальный номер, название, город и адрес.

7. В обязанности менеджера по поставкам входит заключение договора с поставщиками на поставку сырья и компонентов.

8. Каждый такой договор имеет уникальный номер, план поставки на год, распределение по всем месяцам и дате начала действия договора.

9. Каждая поставляемая деталь характеризуется кодом, названием, характеристикой и ценой за единицу продукции.


^ Построение локальной концептуальной модели данных для представления пользователя “менеджер по поставкам и по продаже”.


1. Определение типов сущностей

Договор DOGOVOR

Заказ ZAKAZ

Изделие IZDEL

Материалы KOMP

Покупатель POKUP

Поставщик PSTV


^ 2. Определение типов связей

Тип сущности Тип связи Тип сущности

ZAKAZ заключается с POKUP

DOGOVOR заключается с PSTV

IZDEL отпускаются по ZAKAZ

KOMP поставляются по DOGOVOR

Теперь определим кардинальности и уровень участия этих типов сущностей в вышеперечисленных связях.

Связь ZAKAZаPOKUP.

Каждый договор на продажу изделий заключается с покупателем. Связь типа 1:1. Сущность ZAKAZ участвует в связи полностью.


Связь IZDELаZAKAZ. Кардинальность связи 1:M. Поскольку одно и о же изделие может продаваться по разным договорам. Степень участия IZDEL в данной связи частичная.


Связь DOGOVORаPSTV. Кардинальность этой связи 1:1, так как каждый договор заключается только с одним поставщиком. Сущность DOGOVOR участвует в этой связи полностью.


Связь KOMPаDOGOVOR.

Кардинальность связи KOMPаDOGOVOR 1:M, так как одна и та же деталь может поставляться по нескольким договорам.


^ Определение атрибутов и связывание их с типами сущностей.


Тип сущности Атрибут

IZDEL K_IZDEL (код изделия )

IZDEL (наименование)

KHAR (характеристика)

ZENA_ED (цена за ед.)


POKUP K_POKUP (код покуп.)

POKUP (название)

GOROD (город)

ADR (адрес)


ZAKAZ N_ZAK (№ документа)

PLAN_GOD (план на год)

YAN, FEV, MART…

DATA_ZAK (дата начала договора)


PSTV K_PSTV

PSTV

GOROD

ADR


KOMP K_KOMP

KOMP

GOROD

ADR


DOGOVOR N_DOG (№ договора)

PLAN_GOD (план на год)

YAN, FEV, MART…

DATA_DOG (дата начала действия)


Определение атрибутов, являющихся потенциальными и первичными ключами.


^ Тип сущности Первичный ключ Потенц. ключ


PSTV K_PSTV GOROD, ADR

KOMP K_KOMP KOMP

DOGOVOR N_DOG

ZAKAZ N_ZAK

POKUP K_POKUP GOROD,ADR

IZDEL K_IZDEL IZDEL


Построение локальной логической модели данных для представления пользователя “менеджер по продаже и по поставкам”.


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


Определение набора отношений. Напомню, что на данном этапе создаются отношения, представляющие сущности и связи локальной логической модели данных представления пользователя “менеджер по продаже и по поставкам”. Связи между сущностями моделируются с помощью механизма первичных ключей и внешних ключей.


POKUP (K_POKUP, POKUP, GOROD, ADR)

^ Primary key K_POKUP


PSTV (K_PSTV, PSTV , GOROD, ADR)

Primary key K_PSTV


IZDEL (K_IZDEL , IZDEL, KHAR, ZENA_ED)

Primary key K_IZDEL


KOMP (K_KOMP, KOMP, KHAR, ZENA_ED)

Primary key K_KOMP


DOGOVOR (N_DOG, K_PSTV, K_KOMP, RLAN_GOD, YAN, FEV,…, DATA_DOG)

Primary key N_DOG


ZAKAZ (N_ZAK, K_POKUP, K_IZDEL, PLAN_GOD, YAN, FEV, …, DATA_DOG)

Primary key N_ZAK


Проверка модели с помощью правил нормализации


IZDEL (K_IZDEL, IZDEL, KHAR, ZENA_ED)

Pr. Key K_IZDEL

K_IZDELаIZDEL, KHAR, ZENA_ED


POKUP (K_POKUP, POKUP, GOROD, ADR)

Pr.key K_POKUP

K_POKUPаPOKUP, GOROD, ADR;


KOMP (K_KOMP, KOMP, KHAR, ZENA_ED)

Pr.key K_KOMP

K_KOMPа KOMP, KHAR, ZENA_ED ;


PSTV ( K_PSTV, PSTV, GOROD, ADR)

Pr. Key K_PSTV

K_PSTVа PSTV, GOROD, ADR;


DOGOVOR (N_DOG, K_KOMP, K_PSTV, PLAN_GOD, YAN, FEV,…, DATA_DOG)

Pr. key N_DOG

N_DOGа K_KOMP, K_PSTV, PLAN_GOD, YAN,…, DATA_DOG;


ZAKAZ (N_ZAK, K_IZDEL, K_POKUP, PLAN_GOD, YAN, FEV,…, DATA_DOG)

Pr. key N_ZAK

N_ZAK а K_IZDEL, K_POKUP, PLAN_GOD, YAN,…, DATA_DOG;


Таким образом, мы видим, что все три отношения не содержат ни повторяющихся групп, ни атрибутов, частично или транзитивно зависящих от первичных ключей этих отношений. Более того, каждая из сущностей имеет только один детерминант, который является первичным ключом в соответствующем отношении. В результате можно сделать вывод, что эти отношения находятся в НФБК.


^ Спецификация требований представления пользователя “начальник цеха”.


Требования к данным

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

  • В цехах-участках трудятся рабочие. Информация о каждом рабочем содержит сведения о его табельном номере, фио, должности, семейном положении и о дате приема на работу.

  • В цехах изготавливаются составляющие двигателя и сам двигатель, который характеризуются своим уникальным номером, названием, характеристикой, единицей измерения и ценой за единицу продукции.

  • В цехах-участках протекают различные операции, в которых участвуют детали (сырье) и изделия.

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

  • На каждом участке в ходе каждой операции по изготовлению составляющих двигателя расходуется определенное количество сырья.

  • Каждый рабочий имеет профессию и разряд.

  • На каждом участке входе операции по изготовлению изделия рабочим ведется учет его выработки

  • На каждом участке на операцию по изготовлению изделия рабочим с определенной профессией и разрядом затрачивается определенное количество времени.



^ Требования к транзакциям

К основным транзакциям, которые должны выполняться пользователем “начальник цеха” относятся следующие:

  • составление списка изделий , производимых на участках данного цеха

  • составление списка используемых компонентов

  • составление перечня операций , протекающих в цехе

  • поиск работников удовлетворяющих различным требованиям

  • составление списка расхода материала

  • учет выработки работников


Определение типов сущностей

работа начинается с определения основных типов сущностей исходя из имеющихся спецификаций. В спецификациях сущности обычно представлены как существительные . Анализ показывает , что основными сущностями , упоминаемыми в спецификациях  являются следующие:

^ ПОДРАЗДЕЛЕНИЯ ZECH

РАБОЧИЕ RABOT

ПРОФЕССИЯ PROF

РАЗРЯД TARIF

ИЗДЕЛИЯ IZDEL

МАТЕРИАЛЫ KOMP

ОПЕРАЦИИ OPER


Определение типов связей

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

^ Тип сущности Тип связи Тип сущности

RABOT обладает PROF

RABOT имеет TARIF

KOMP участвуют OPER

KOMP расходуется ZECH

KOMP расходуется на IZDEL

KOMP расходуется в OPER

IZDEL участвует OPER

IZDEL изготавливается в OPER

IZDEL изготавливается в ZECH

IZDEL изготавливается RABOT

PROF затрачивается на IZDEL

TARIF затрачивается на IZDEL


Определение степени участия и кардинальности каждого типа связи.

Связь IZDEL RABOT. Кардинальность данной связи M:N, так как в процессе изготовления изделий принимают участие не один рабочий.


Связь ^ IZDEL ZECH. Кардинальность этой связи также M:N, так как изделия изготавливаются во многих цехах.


Связь IZDELOPER. Кардинальность данной связи M:N, так как изделия проходят разную степень обработки в разных цехах.


Связь ZECH OPER. Кардинальность связи 1:M. В цехе протекает несколько операций.


Связь KOMP OPER (материалы расходуются в операциях) Кардинальность M:N.


Связь KOMPOPER (материалы участвуют в операциях) Связь типа 1:M, так как один и тот же материал может участвовать в разных операциях.


Связь RABOTPROF. Связь типа 1:1.Каждый рабочий имеет только одну профессию.

Связь RABOTTARIF. Кардинальность данной связи также 1:1, так как каждый рабочий имеет только один разряд.


^ Определение атрибутов сущностей

Тип сущности Атрибут

IZDEL K_IZDEL

IZDEL

KHAR

ED_IZM


KOMP K_KOMP

KOMP

KHAR

ED_IZM


RABOT TAB_N (таб. №)

FIO (ФИО)

SEM_POL (семейное положение)

DATA_ZACH (дата приема на работу)


OPER N_OPER (№ операции)

TARIF N_TARIF (№ разряда)

TARIF (часовая тарифная ставка)


PROF K_PROF (код проф.)

PROF (название)


Определение первичных ключей и потенциальных ключей.


Тип сущности Первичный ключ Потенц. Ключ

^ IZDEL K_IZDEL IZDEL

KOMP K_KOMP KOMP

RABOT TAB_N

TARIF N_TARIF TARIF

PROF K_PROF PROF

Построение и проверка локальной логической модели для представления пользователя “начальник цеха”.

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


^ Удаление сложных связей.

Прочитаем спецификацию N 9 : ’на каждом участке в ходе операции по изготовлению изделия рабочим ведется учет его выработки.’в этой связи участвуют четыре связи. Для удаления такой сложной связи объединим все эти сущности в промежуточную. И получим


RABOTVIRABOTKA. Тип связи 1:M.

IZDELVIRABOTKA. 1:M

^ OPERVIRABOTKA. 1:M

ZECHVIRABOTKA. 1:M


Спецификация N7: ‘На каждом участке в ходе каждой операции по изготовлению составляющих двигателя (т.е. изделий) расходуется определенное количество сырья (т.е. материала)


Объединив эти четыре сущности KOMP, IZDEL, OPER, ZECH в единую промежуточную сущность RASHOD (расход) мы тем самым удалим еще одну сложную связь. В замен старой связи получим 4 связи типа 1:M

^ KOMPRASHOD 1:M

IZDELRASHOD. 1:M

OPERRASHOD. 1:M

ZECHRASHOD.1:M


Спецификация N 10: ‘На каждом участке на каждую операцию по изготовлению изделия рабочим с определенной профессией и разрядом затрачивается определенное количество времени’.


Для получения бинарной связи объединим сущности PROF, TARIF, IZDEL, ZECH в одну сущность под названием ZATRATA (нормы затрат труда).


Определение набора отношений


Определим сначала сильные типы сущностей

^ IZDEL (K_IZDEL, IZDEL, KHAR, ED_IZM)

primary key K_IZDEL


KOMP (K_KOMP, KOMP, KHAR, ED_IZM)

Primary key K_KOMP


PROF (K_PROF, PROF)

Primary key K_PROF


TARIF (N_TARIF, TARIF)

Primary key N_TARIF


Сущность RABOT имеет две родительские сущности PROF и TARIF- поэтому в ее отношение следует поместить копии первичных ключей обеих этих сущностей. Получим:

^ RABOT (TAB_N, FIO, K_PROF, N_TARIF, SEM_POL, DATA_ZACH)

Primary key TAB_N

Для каждой слабой сущности в модели данных следует создать отношение, в которое в качестве внешнего ключа следует поместить первичные ключи всех ее родительских сущностей. В нашем случае это сущности RASHOD, VIRABOTKA, ZATRATA.

^ RASHOD (K_KOMP, K_IZDEL, N_OPER, N-ZECH, ED-IZM, NORMA)

primary key K_KOMP, N_OPER

foreign key K_KOMP, K_IZDEL, N_OPER, N_ZECH


ZATRATA (K_IZDEL, N_OPER, N_ZECH, K_PROF, N_TARIF DOPOLN, VREMYA_ED)

primary key K-IZDEL, N_OPER

foreign key K_IZDEL, N_OPER, N_ECH, K_PROF, N_TARIF


VIRABOTKA (N_ECH, K_IZDEL, N_OPER, TAB_N, KOLV_GOD, KOLVO_BR, PROC_BR, DATA_VIR)

Primary key TAB_N, DATA_VIR

foreign key N_ZECH, K_IZDEL, N_OPER, TAB_N


Проверка модели с помощью правил нормализации

Чтобы убедиться, что каждое из полученных отношений находится в НФБК, проанализируем функциональные зависимости между этими отношениями.

IZDEL ( ...)

K_IZDELIZDEL, KHAR, ED_IZM;

KOMP(...)

K_KOMPKOMP, KHAR, ED_IZM;


RABOT (...)

TAB_NFIO, K_PROF, N_TARIF, SEM_POL, DATA_ZACH;


TARIF (...)

N_TARIFTARIF


PROF (...)

K_PROFPROF;

Эти пять отношений находятся в НФБК, поэтому никаким аномалиям обновления они подвержены не будут. Что касается остальных отношений RASHOD, VIRABOTKA, ZATRATA, то хоть они и не нормализованы до НФБК также не будут подвержены вышеупомянутым аномалиям.


^ Спецификация требований для представления пользователя “бухгалтер”.


Требования к данным

  • Каждый сотрудник предприятия получает заработную плату.

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


Требования к транзакциям

  • Создание и редактирование записей о начислении заработной платы

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


^ Построение локальной концептуальной модели для пользователя “бухгалтер”


Определение сущностей

В спецификациях упоминаются следующие сущности:

^ СОТРУДНИКИ RABOT

РАЗРЯД TARIF

ЗАРПЛАТА ZARPLATA


Определение связей между сущностями

RABOTZARPLATA. Каждый сотрудник получает зарплату. Тип связи 1:M

RABOTTARIF. Каждый рабочий имеет разряд. Связь типа 1:1.Сущность RABOT участвует в этой связи полностью.


^ Определение атрибутов

Тип сущности Атрибут

RABOT TAB_N

FIO

POSITION

SEM_POL

DATA_ZACH


ZARPLATA SUM_NACH (начислено)

SUM_UDER (удержано)

VIDACHA (к выдаче)

DATA_VID (дата выдачи)


TARIF N_TARIF

TARIF


Определение первичных и потенциальных ключей

Тип сущности Первичный ключ Потен. ключ

^ RABOT TAB_N

TARIF N_TARIF TARIF

ZARPLATA


Как видим, сущность ZARPLATA не имеет первичного ключа, т.е. она является слабой сущностью. Ее первичный ключ частично или полностью зависит от сущности владельца.


^ Определение отношений. Так как в логической модели у нас нет никаких ‘лишних’ структур, то сразу можно перейти к определению отношений.


RABOT (TAB_N, FIO, POSITION, N_TARIF, SEM_POL, DATA_ZACH)

Primary key TAB_N; foreign key N_TARIF;


^ ZARPLATA (TAB_N, SUM_NACH, SUM_UDER, VIDACHA, DATA_VID);

primary key TAB_N, DATA_VID;

foreign key TAB_N;

В отношении правил нормализации первые два отношения находятся в НФБК, так как нет ни повторяющихся групп, ни атрибутов. Частично или полностью зависящих от первичного ключа и, более того, детерминанты отношений являются их первичными ключами. А что касается отношения ZARPLATA, хоть оно и не находится в НФБК аномалиям обновления подвержено не будет.


^ Слияние локальных логических моделей в единую глобальную модель данных.


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

  • Анализ имен сущностей и их первичных ключей

  • Анализ имен связей

  • Слияние общих сущностей из отдельных локальных моделей

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

  • Слияние общих связей из отдельных локальных представлений

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

Таким образом, мы имеем следующее:

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

^ IZDEL (K_IZDEL, IZDEL, ED_IZM, KHAR, ZENA_ED)

primary key K_IZDEL;


Глобальное представление сущности KOMP, полученное в результате слияния сущностей с таким именем из представлений начальник цеха, начальник склада, менеджер по продаже и по реализации.

^ KOMP (K_KOMP, KOMP, KHAR, ED_IZM, ZENA_ED)

primary key K_KOMP;


Глобальное представление сущности RABOT

RABOT ( TAB_N, FIO, K_PROF, N_TARIF, POSITION, SEM_POL, DATA_ZACH)

Primary key TAB_N;


Глобальное представление сущности ^ PSTV

PSTV (K_PSTV, PSTV, GOROD, ADRESS)

Primary key K_PSTV;


Глобальное представление сущности POKUP

POKUP (K_POKUP, POKUP, GOROD, ADRESS)

Primary key K_POKUP;



1 В англоязычном мире принято произносить это сокращение как "Сиквэл", в русскоязычном же традиционно прижилось произношение "Эс-Ку-Эль".

2 Под БД смешанного типа понимают реляционные, в целом, БД, способные хранить в таблицах объекты в качестве значений (в смысле ООП - не путать с OLE-объектами!).

3 Для компактности мы используем, в качестве стенографических, обозначения мат. логики: - "для всех, для каждого", - "существует,найдется", - "эквивалентно", - "если…,то…", -"и", -"или".

4 Реже употребляемый на практике количественный подход к классификации отношений предусматривает оценку чисел N,M - "N записей одной таблицы может находиться в данном отношении с M записями другой таблицы". Пропорцию N:M называют кардинальностью отношения.

5 Термин trigger - "спусковой крючок огнестрельного оружия" - подразумевает автоматический запуск такой процедуры при попытке модификации родительской таблицы.

6 Неявно подразумевается случай, когда данный человек переезжает в дом, информация о котором уже содержится в БД. Что делать в противном случае? И что делать с записью о доме, на которую перестали ссылаться какие-либо записи о людях? Отметьте, что уже этот простой пример порождает проблемы, не покрываемые стандартными вариантами согласования изменений.

7 Что, впрочем, касается в большей степени крупных серверных СУБД типа Oracle и MS SQL Server, а не таких СУБД клиентского типа, как рассматриваемая здесь Visual FoxPro.
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
При копіюванні матеріалу обов'язкове зазначення активного посилання відкритою для індексації.
звернутися до адміністрації
Документи