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

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




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

^ ТАРИФЫ


- уникальный код условий труда и тарифный разряд работы;

- часовая тарифная ставка, в рублях


ПРОФЕССИИ


- уникальный код профессии;

- наименование профессии.


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


- номер цеха;

- наименование цеха или участка.


ПЛАН (производственный план предприятия)


  • код изделия;

  • распределение плана по всем месяцам - выпуск , в штуках, в январе, феврале и т.д.;

- дата начала действия плана.


ДОГОВОРЫ ( на поставку компонент)

- код поставщика;

- уникальный номер договора;

- код компонента - материала или покупной детали;

- единица измерения;

- план поставки на год, в шт.;

- распределение плана по всем месяцам - поставки в январе, феврале и т.д.;;

- дата начала действия договора.


РАБОТНИКИ (личный состав, штат предприятия)


- номер цеха;

- табельный номер рабочего;

- код профессии;

- разряд рабочего;

- часовая тарифная ставка;

- семейное положение;

- фамилия с инициалами.


ВЫРАБОТКА (учет выработки работников)


- номер цеха;

- номер участка;

- код изделия;

- номер операции;

- табельный номер работника;

- количество годных деталей;

- количество бракованных деталей;

- процент оплаты брака;

- дата выполнения работ.


ПОСТАВЩИКИ

- уникальный код поставщика;

- наименование поставщика;

- адрес поставщика.


ПОСТАВКА компонент

- номер склада;

- код поставщика;

- код компоненты;

- единица измерения;

- количество ;

- дата поступления;

- уникальный номер документа.


ОТГРУЗКА готовой продукции


- номер склада;

- код покупателя;

- код готового изделия;

- единица измерения;

- количество;

- дата отгрузки;

- уникальный номер документа.

ПОКУПАТЕЛИ

- уникальный код покупателя;

  • наименование;

  • город;

- почтовый адрес.


СКЛАДЫ


- номер склада;

- фамилия материально ответственного лица;

- код детали - компоненты или изделия;

- единица измерения;

- количество, имеющееся на складе;

- дата последней операции.


ЗАРПЛАТА (бухгалтерский учет начисления и удержания по зарплате)


- табельный номер работника;

- сумма начисления;

- сумма удержания;

- дата выдачи.


ЗАКАЗЫ (договоры на отгрузку готовой пpодукции покупателям)


- код покупателя;

- уникальный номер заказа;

- код изделия;

- единица измерения;

- план поставки на год, в шт.;

- распределение плана по всем месяцам - поставки в январе, феврале и т.д.;

  • дата начала действия договора.



Упражнение. Постройте формальную модель предприятия в форме базы данных, определив таблицы КОМПОНЕНТЫ, ИЗДЕЛИЯ и т.д., используя выделенные слова (код, наименование, характеристика, единица, цена и т.д.) в качестве имен полей (здесь и далее мы для удобства используем кириллические имена произвольной длины; если ваша СУБД не поддерживает соответствующие идентификаторы, используйте латинскую транскрипцию и сокращения). Выясните, какие поля (или группа полей) являются первичными и внешними ключами. Правила целостности и корректности значений полей и записей таблиц (в частности, допустимость неопределенных значений) определите самостоятельно, исходя из содержательного смысла таблиц и отношений.


Упражнение. Проведите в компьютерном классе деловую игру, распределив роли директора предприятия, бухгалтера, мастера, поставщика, заказчика и т.п. по предлагаемому или - выдуманному самостоятельно "сценарию":


Заказчик - директору: "По нашему договору №…, от …. ваше предприятие недопоставило … изделий "…". Если Вы не поставите требуемые изделия в течении … дней, мы обратимся в суд"

Директор - заказчику "Минутку-минутку, сейчас уточним…У меня почему-то стоит другая дата…"

Директор - кладовщику "Сколько у нас на складе изделий "…"? Не хватает?"

Директор - начальнику цеха "Сможем в течении … дней собрать недостающие .. штук изделий "…"?


Далее следуют обращения


  • начальника цеха на склад в поиске нужных компонент,

  • начальника цеха - к директору с просьбой повысить тарифные расценки за срочную работу,

  • директора - в бухгалтерию, с вопросом о финансовых возможностях предприятия выполнить эту просьбу,

  • директора к поставщикам с просьбой срочно поставить недостающие компоненты,

  • и т.д. - импровизируйте!


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


ЛИТЕРАТУРА.


  1. М.Нагао, Т.Катаяма, С.Уэмура. Структуры и базы данных – М.,Мир, 1986 – 196 с.

  2. М.Грабер. Введение в SQL

  3. А.Горев. Visual FoxPro 5.0. Книга для программистов – М., ТОО “Эдэль”, 1997 – 552 с.

  4. М.Антонович, Visual FoxPro для Windows, BINOM Publishers, 1996 – 688 с.

  5. М.Базиян. Использование Visual FoxPro 6. Вильямс, 2000 - 925 с.

  6. З.Пэддок, Дж.Петерсен, Р.Тэлмейдж. Visual FoxPro 6. Разработка корпоративных приложений. Изд-во ДМК 2000, 588 с.



Приложение1. Нормальные формы БД.


Приложение 2.

(выполнено, под руководством автора, студенткой А.Юсуповой в качестве одного из разделов дипломной работы)


^ Пример проектирования базы данных.


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

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

  • создание модели данных, способной поддерживать выполнение любых требуемых транзакций обработки данных

  • разработка предварительного варианта проекта, структура которого позволяет удовлетворить все основные требования, предъявляемые к производительности системы.


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

Нисходящий подход демонстрируется в концепции “сущность-связь” В этом случае работа начинается с идентификации сущностей и связей между ними, интересующих данную организацию в наибольшей степени. Например, сначала можно было бы идентифицировать сущности PSTV (поставщик) и KOMP (материалы), а затем установить между ними связь “поставляет” и лишь после этого определить связанные с ними атрибуты - например, PSTV (k_pstv, pstv, gorod, adress) и KOMP (k_komp, komp, ed_izm, khar, zena_ed).


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


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


Вторая фаза проектирования БД называется логическим проектированием БД. Ее цель состоит в создании логической модели данных для исследуемой части предприятия. Концептуальная модель данных, созданная на предыдущем этапе, уточняется и преобразуется в логическую модель данных. Логическая модель данных учитывает особенности выбранной модели организации данных в целевой СУБД (например, реляционная или сетевая). Если концептуальная модель данных не зависит от любых физических аспектов реализации, то логическая модель данных создается на ос6нове выбранной модели организации данных целевой СУБД. В процессе разработки логическая модель постоянно тестируется и проверяется на соответствие требованиям пользователей. Для проверки корректности логической модели данных используется метод нормализации. Нормализация гарантирует, что выведенные из соответствующей модели данных отношения не обладают избыточностью данных, способной вызвать аномалии обновления после их физической реализации.


^ Слияние представлений отдельных пользователей


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


^ Физическое проектирование является третьей фазой процесса создания проекта базы данных. Основной целью физического проектирования БД является описание способа физической реализации логического проекта БД. В случае реляционной модели данных под этим подразумевается следующее:

- создание набора реляционных таблиц и ограничений для них на основе информации , представленной в глобальной логической модели данных;

-определение конкретных структур хранения данных и методов доступа к ним, обеспечивающих оптимальную производительность системы с базой данных;

-разработка средств защиты создаваемой системы.


^ Пример разработки концептуального, логического и физического проекта базы данных “сборочное предприятие”.


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


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


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

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

  • На каждом из складов есть материально- ответственное лицо и грузчики.

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

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

  • Поставки на склад осуществляются поставщиками. Информация о поставщиках включает в себя код поставщика, название и адрес.

  • Со склада изделия отгружаются заказчикам (покупателям). В сведения о покупателях входят: код, название, адрес.

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


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

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

  • составление документа об отгрузке изделий

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

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


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


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

  • типы сущностей

  • типы связей

  • атрибуты

  • первичные ключи


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


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

^ СКЛАД SKLAD

ИЗДЕЛИЕ IZDEL

МАТЕРИАЛЫ И ДЕТАЛИ KOMP

ПОСТАВЩИКИ PSTV

ЗАКАЗЧИКИ POKUP

ДОКУМЕНТ О ПОСТАВКЕ POST

ДОКЕМЕНТ ОБ ОТГРУЗКЕ OTGR


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

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


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

POST осуществляется на SKLAD

POST осуществляется PSTV

OTGR делают на SKLAD

OTGR проводит POKUP

IZDEL отгружаются по OTGR

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


Определение кардинальности и уровня участи отдельных типов связей

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


Связь ^ POSTа SKLAD.

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

Связь ^ POSTа PSTV.

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

Связь OTGRаSKLAD.

В ходе аналогичных рассуждений получаем, что кардинальность данной связи 1:1, степень участия сущности SKLAD в связи OTGRаSKLAD частичная.

Связь OTGRаPOKUP.

Кардинальность 1:1. Сущность OTGR участвует в связи OTGRаPOKUP полностью.

Связь IZDELаOTGR.

Кардинальность 1:M. Сущность IZDEL участвует в данной связи частично.

Связь KOMPаPOST.

Кардинальность данной связи 1:M, так как поставляться может несколько видов материалов и компонентов. Сущность POST полностью занята в связи KOMPаPOST.


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

Следующим шагом является выделение атрибутов сущностей. Атрибут описывает некоторый аспект определенной сущности или связи.


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

PSTV K_PSTV (код поставщика)

PSTV (название )

GOROD (город)

ADR (адрес)

POKUP K_POKUP(код покупателя)

POKUP (название)

GOROD (город)

ADR (адрес)


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

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

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

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


KOMP K_KOMP ( код детали)

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

KHAR (характер.)

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

POST N_POST (№ пост.)

KOL_VO (кол-во)

DATA _POST (дата пост.)


OTGR N_OTGR (№ отгр.)

KOLVO (кол-во)

DATA_OTGR (дата отгр.)


SKLAD N_SKLAD (№ склада)

FIO (отв. лицо)

KOLVO (кол-во )

DATA_OPER (дата опер.)


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

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

^ IZDEL K_IZDEL IZDEL

KOMP K_KOMP KOMP

PSTV K_PSTV

POKUP K_POKUP

OTGR N_OTGR

POST N_POST

SKLAD N_SKLAD, K_KOMP, DATA_OPER


Определение набора отношений исходя из структуры локальной логической модели данных.

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


^ Сильные типы сущностей

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


^ Слабые типы сущностей

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


^ Бинарные связи типа 1:1

Для каждой присутствующей в логической модели данных бинарной связи типа 1:1, установленной между сущностями E1 и E2, надо переслать атрибуты первичного ключа сущности E1 в отношение, представляющее сущность E2. Эти атрибуты будут использоваться в нем в качестве внешнего ключа. Определение родительской и дочерней сущностей зависит от ограничений участия, наложенных на члены отношения E1 и E2. Сущность, которая частично участвует в связи, определяется как родительская, а та сущность, которая участвует в связи полностью определяется как дочерняя.


^ Бинарные связи типа 1:M

Для каждой бинарной связи типа 1:M, установленной в логической модели данных между сущностями E1 и E2, необходимо переслать копию атрибутов первичного ключа сущности E1 в отношение, представляющее сущность E2, где они будут играть роль внешнего ключа. Сущность, представляющая ’единичную’ сторону связи определяется как родительская. А сущность, представляющая ‘множественную ’ сторону - как дочерняя.


В результате окончательный вид отношений имеет следующий вид:

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

primary key N_POST;

foreign key (K_KOMP) references KOMP (K_KOMP);

foreign key (K_PSTV) references PSTV (K_PSTV);

foreign key (N_SKLAD) references SKLAD (N_SKLAD);


^ OTGR (N_OTGR, K_IZDEL, K_POKUP, KOLVO, N_SKLAD, DATA _OTGR)

primary key N_OTGR;

foreign key (K_IZDEL) references IZDEL (K_IZDEL);

foreign key (K_POKUP) references POKUP (K_POKUP);

foreign key (N_SKLAD) references SKLAD (N_SKLAD);

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
При копіюванні матеріалу обов'язкове зазначення активного посилання відкритою для індексації.
звернутися до адміністрації
Документи