Реферат: Организация баз данных - текст реферата. Скачать бесплатно.
Банк рефератов, курсовых и дипломных работ. Много и бесплатно. # | Правила оформления работ | Добавить в избранное
 
 
   
Меню Меню Меню Меню Меню
   
Napishem.com Napishem.com Napishem.com

Реферат

Организация баз данных

Банк рефератов / Программирование

Рубрики  Рубрики реферат банка

закрыть
Категория: Реферат
Язык реферата: Русский
Дата добавления:   
 
Скачать
Microsoft Word, 3992 kb, скачать бесплатно
Заказать
Узнать стоимость написания уникального реферата

Узнайте стоимость написания уникальной работы

23 МИНИСТЕРСТВО ОБЩЕГО И ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ РОССИЙСКОЙ ФЕДЕ РАЦИИ Таганрогский государственный радиотехнический университет Кафедра вычислительной техники _________________________________________________________________________ Дистанционное обучение 1999 - 2000 учебный год О Т Ч Ё Т о выполнении прак тических заданий по курсу ОРГАНИЗАЦИЯ БАЗ ДАННЫХ студента группы ВД - 39 . Найденко Алексея Владимировича Ф.И.О . полность ю В в е д е н и е При проектировании программ выясняются запросы и пожелания клиента и определяется возможный подход к решению задачи . Задача анализируется . На основе этого анализа реализуется конкретная модель в конкретной программной среде . Результаты каждого этапа проектирования используются в качестве исходного материала следующего этапа. Анализируется текущая организация предприятия , выделяются проблемы для решения , определяются объекты отношения между ними , составляется «эскиз» текущей организации предприятия , разрабатывается модель с учетом конкретных условий ее функционирования. База данных ориентирована на определенную предметную область и организована на основе некоторого подмножества данных . Возможности баз данных полезны в областях , связанных с долговременным управлением информацией , таких как электронные библиотеки и хранилища данных. Предварительное планирование , подготовка данных, последовательность создания информационной модели При проектировании системы обработки данных больше всего нас интересует организация данных . Помочь понять организацию данных призвана информационная модель. Процесс создания информационной модели начинается с определения концептуальных требований ряда пользователей . Концептуальные требования могут определяться и для некоторых задач (приложений ), которые в ближайшее время реализовывать не планируется . Это может несколько повысить трудоемкость работы , однако поможет наиболее полно учесть все нюансы функциональности , требуемой для разрабатываемой системы , и снизит веро я тность переделки в дальнейшем . Требования отдельных пользователей должны быть представлены в едином «обобщенном представлении» . Последнее называют концептуальной моделью. · Объект – это абстракция множества предметов реального мира , обладающих одинаковыми характеристиками и законами поведения . Объект представляет собой типичный неопределенный экземпляр такого множества. Объекты объединяются в классы по общим характеристикам . Например , в предложении «Белый Дом является зданием» , «Белый Дом» представляет объ ект , а «здание» – класс . Классы обозначаются абстрактными существительными. · Класс – это множество предметов реального мира , связанных общностью структуры и поведением. Концептуальная модель представляет объекты и их взаимосвязи без указывания способов и х физического хранения. Таким образом , концептуальная модель является , по существу , моделью предметной области . При проектировании концептуальной модели все усилия разработчика должны быть направлены в основном на структуризацию данных и выявление взаимосв язей между ними без рассмотрения особенностей реализации и вопросов эффективности обработки . Проектирование концептуальной модели основано на анализе решаемых на этом предприятии задач по обработке данных . Концептуальная модель включает описания объектов и их взаимосвязей , пред ставляющих интерес в рассматриваемой предметной области и выявляемых в результате анализа данных . Имеются в виду данные , используемые как в уже разработанных прикладных программах , так и в тех , которые только будут реализованы. Прое ктирование концептуальной модели базы данных : Анализ данных : сбор основных данных (например , объекты , связи между объектами ). Определим первоначальные данные : Заявки - поступающие от магазинов на определённый период. Договора - заключаются с поставщиками н а определённый вид товара. Поставщики - организации или физические лица , с которыми заключаются договора на поставку товара. Заказчики - в основном магазины , а также предприятия и организации , подающие заказ на приобретение того или иного товара. Счета - ведутся на этапе заключения договором с поставщиками , а также с заказчиками. Накладные - создаются на основании получения заказа о заказчика , для отгрузки. Справки - получение /выдача различных справок как заказчику так и поставщику. Товар - присутствует н а основании заявки и договора с поставщиком. Определение взаимосвязей. Взаимосвязь выражает отображение или связь между двумя множествами данных . Различают взаимосвязи типа «один к одному» , «один ко многим» и «многие ко многим». Например , если заказчик про изводит заказ на покупку товара впервые , осуществляется первичная регистрация его данных и сведений о сделанном заказе . Если же заказчик производит заказ повторно , осуществляется регистрация только данного заказа . Вне зависимости от того , сколько раз данн ы й заказчик производил заказы , он имеет уникальный иденти фикационный номер (уникальный ключ заказа ). Информация о каждом заказчике включает наименование заказчика , адрес , телефон , факс , фамилию , имя , отчество , признак юридического лица и примечание . Таким образом , свойствами объекта Заказчик являются «уникальный ключ заказчика» , «наименование заказчика». Следующий представляющий для нас интерес объект — Товар . Этот объект имеет свойства «уникальный ключ товара» , «наименование товара». Второй рассматриваемый объект — Поставщик . Его свойствами являются «уникальный ключ поставщика» , «наименование поставщика». Третий рассматриваемый объект — Заказчик . Его свойствами являются «уникальный ключ заказчика» , «наименование заказчика». Взаимосвязь «один к одному» (меж ду двумя типами объектов ) Допус тим , в определенный момент времени один заказчик может сделать только один заказ . В этом случае между объектами Заказчик и Товар устанавливается взаимосвязь «один к одному». Взаимосвязь «один ко многим» (между двумя типами объектов ) В определенный момент времени один заказчик может стать обладателем несколь ких товаров , при этом несколько заказчиков не могут являться обладателями одного товара (на условии если заказчик не претендует на часть товара ). Взаимосвязь «один ко мно гим» можно обоз начить с помощью одинарной стрелки в направлении к «одному» и двойной стрелки в направлении ко «многим» .В этом случае одной записи данных первого объекта (его часто называют родительским или основным ) будет соответствовать несколько запис е й второго объекта (дочернего или подчиненного ). Взаимосвязь «один ко многим» очень распространена при разработке реляционных баз данных . В качестве родитель ского объекта часто выступает справочник , а в дочернем хранятся уникальные ключи для доступа к зап и сям справочника . В нашем примере в качестве такого справочника можно представить объект Заказчик , в котором хранятся сведения о всех заказчиках . При обращении к записи для определенного заказчика нам доступен список всех покупок , которые он сделал , и свед е ния о которых хранятся в объекте Товар . Взаимосвязь «один к одному» (между двумя свойствами ) Мы предполагаем , что ключ (номер ) магазина является его уникальным иденти фикатором , то есть он не изменяется и при последующих поступлениях заказов от данного ма газина . Если наряду с номером магазина в базе данных хранится и другой его уникальный идентификатор (например , адрес ), то между такими двумя уникальными идентификаторами существует взаимосвязь «один к одному». Взаимосвязь «один ко многим» (между двумя свой ствами ) Имя поставщика и его номер существуют совместно . Поставщиков с одинаковыми именами может быть много , но все они имеют различные номера . Каждому поставщику присваивается уникальный номер . Это означает , что данному номеру поставщика соответствует тол ько одно имя . Взаимосвязь «один ко многим» обозначается одинарной стрелкой в направлении к «одному» и двойной стрелкой в направлении ко «многим». Первоначальная схема данных Функциональная модель Исследование токов Данных Данные выявленные в ходе разработ ки Отдел обработки заявок Заявки Договора Договоров Поставщики Заказчики Ведение счетов Счета Погрузка Накладные Товар Инвентаризация Справки Определение объектов Выделим следующие объекты : 1. ТОВАР - ( Т ) ; 2. ЗАКАЗЧИ К - ( З ) ; 3. ПОСТАВЩИК - ( П ) ; 4. СЧЕТА - ( С ); 5. ДОГОВОР - ( Д ) ; 6. НАКЛАДНЫЕ - ( Н ) . Первоначальное графическое представление концептуальной модели Т З П С Н Д Задание первичных и альтернативных ключей , определение свойств объектов Для каждог о объекта определим свойства , которые будем хранить в БД . При этом необходимо учитывать тот факт , что при переходе от логической к физической модели данных может произойти усечение числа объектов . На самом деле , как правило , значительное число данных , нео б ходимых пользователю , может быть достаточно легко подсчитано в момент вывода информации . В то же время , в связи с изменением алгоритмов расчета или исходных величин , некоторые расчетные показатели приходится записывать в БД , чтобы гаранти рованно обеспечи т ь фиксацию их значений . Выбор показателей , которые обяза тельно следует хранить в БД , достаточно сложен . Нечасто можно найти однозначное решение этой проблемы , и в любом случае оно потребует тщатель ного изучения работы предприятия и анализа концептуально й модели. Свойства , включаемые в состав БД для рассматриваемой модели , приведены в табл. 1. Таблица 1. Свойства и первичные ключи объектов информационной модели. Объект Первичный ключ Свойства ТОВАР Уникальный ключ товара Уникальный ключ товара Наимено вание товара ЗАКАЗЧИК Уникальный ключ заказчика Уникальный ключ заказчика Наименование заказчика Юридическая принадлежность Ф.И.О . руководителя Адрес Телефон /факс Наименование товара Количество товара Предполагаемая цена ПОСТАВЩ ИК Уникальный ключ поставщика Уникальный ключ поставщика Наименование поставщика Юридическая принадлежность Ф.И.О . руководителя Адрес Телефон /факс Наименование товара Количество товара Дата изготовления Акцизная марка Расшифро вка штрих-кода Срок годности Вес Брутто Вес Нетто Цена за единицу Суммарная цена Вид упаковки Способ доставки СЧЕТА Номер счёта Номер счёта Дата продажи Наименование поставщика Адрес поставщика Юридическая принадлежность п. Наименование заказчика Адрес заказчика Юридическая принадлежность з. Наименование товара Количество товара Сумма НДС Сумма к оплате ДОГОВОР Номер договора Номер договора Дата заключения Номер счёта Наименование поставщи ка Адрес поставщика Юридическая принадлежность Наименование товара Количество товара Сумма НДС НАКЛАДНЫЕ Номер накладной Номер накладной Дата накладной Пометка об оплате Номер счёта Наименование заказчика Адрес заказчика Юридическая принадлежность Наименование товара Количество товара Сумма НДС Графическое представление первой таблицы С З П Т Н Д Приведение модели к требуемому 1 уровню нормальной формы Приведение модели к тр ебуемому уровню нормальной формы является основой построения реляционной БД . В процессе нормализации элементы данных группируются в таблицы , представ ляющие объекты и их взаимосвязи . Теория нормализации основана на том , что определенный набор таблиц облад а ет лучшими свойствами при включении , модификации и удалении данных , чем все остальные наборы таблиц , с помощью которых могут быть представлены те же данные . Введение нормализации отношений при разработке информационной модели обеспечивает минимальный объе м физической , то есть записанной на каком-либо носителе БД и ее макси мальное быстродействие , что впрямую отражается на качестве функционирова ния информационной системы . Нормализация информационной модели выпол няется в несколько этапов. Данные , представле нные в виде двумерной таблицы , являются первой нормальной формой реляционной модели данных . Первый этап нормализации заключается в образовании двумерной таблицы , содержащей все необходимые свойства информационной модели , и в выделении ключевых свойств . Оч е видно , что полученная весьма внушительная таблица будет содержать очень разнородную информацию . В этом случае будут наблю даться аномалии включения , обновления и удаления данных , так как при выполнении этих действий нам придется уделить внимание данным (в в одить или заботиться о том , чтобы они не были стерты ), которые не имеют к текущим действиям никакого отношения . Например , может наблюдаться такая парадок сальная ситуация. Отношение задано во второй нормальной форме , если оно является отношением в первой н ормальной форме и каждое свойство , не являю щийся первичным свойством в этом отношении , полностью зависит от любого возможного ключа этого отношения. Если все возможные ключи отношения содержат по одному свойству , то это отношение задано во второй нормальн ой форме , так как в этом случае все свойства , не являющиеся первичными , полностью зависят от возможных клю чей . Если ключи состоят более чем из одного свойства , отношение , заданное в первой нормальной форме , может не быть отношением во второй нормальной ф о рме . Приведение отношений ко второй нормальной форме заключается в обеспечении полной функциональной зависимости всех свойств от ключа за счет разбиения таблицы на несколько , в которых все имеющиеся свойства будут иметь полную функциональную зависимость о т ключа этой таблицы . В процессе приведения модели ко второй нормальной форме в основном исключаются аномалии дублирования данных. Отношение задано в третьей нормальной форме , если оно задано во второй нормальной форме и каждое свойство этого отношения , не являющийся первичным , не транзитивно зависит от каждого возможного ключа этого отношения. Транзитивная зависимость выявляет дублирование данных в одном отношении . Если А , В и С - три свойства одного отношения и С зависит от В , а В от А , то говорят , что С т ранзитивно зависит от А . Преобразование в третью нормальную форму происходит за счет разделения исходного отношения на два. Таблица 2. Свойства и первичные ключи измененных или добавленных объект ов информационной модели. Объект Первичный ключ Свойства ТОВАР Уникальный ключ товара Уникальный ключ товара Уникальный ключ поставщика Уникальный ключ заказчика Наименование товара Дата изготовления Акцизная марка Расшифровка штрих-кода Срок годности Вес Брутто Вес Нетто Цена за единицу Суммарная цена Вид упаковки ЗАКАЗЧИК Уникальный ключ заказчика Уникальный ключ заказчика Наименование заказчика Юридическая принадлежность Ф.И.О . руководителя Адрес Тел ефон /факс Предполагаемая цена ПОСТАВЩИК Уникальный ключ поставщика Уникальный ключ поставщика Наименование поставщика Юридическая принадлежность Ф.И.О . руководителя Адрес Телефон /факс СЧЕТА Номер счёта Номер счёта Дата продажи Уни кальный ключ товара НДС Сумма к оплате ДОГОВОР Номер договора Номер договора Дата заключения Уникальный ключ поставщика НАКЛАДНЫЕ Номер накладной Номер накладной Уникальный ключ заказчика Пометка об оплате Дата накладной Графическ ое представление второй таблицы З Н Т П Д С Табличная с определёнными связями , окончательная концептуальная модель . ТОВАР Уник . ключ поставщика Уник . ключ заказчика Наименование товара Дата изготовле ния Акцизная марка Расшиф . Штрих-кода ЗАКАЗЧИК Срок годности ПОСТАВЩИК Уник . ключ заказчика Вес Брутто Уник . ключ поставщика Наименов . Заказчика Вес Нетто Наименов . поставщика Юрид-ская . принад. Цена за единицу Юрид-ская . принад. Ф .И.О . руководителя Суммарная цена Ф.И.О . руководителя Адрес Вид упаковки Адрес Телефон /факс Уник . ключ товара Телефон /факс Предполагаемая цена Номер договора Номер накладной Дата заключения Пометка об оплате Дата накладной СЧЕТА Уник . ключ товара Номер счёта Дата продажи НДС Сумма к оплате Графическое представление концептуальной модели в третьей нормальной форме З Т П С Концептуальная модель переносится затем в модель данных , совместимую с выбранной СУБД . Возможно , что отраженные в концептуальной модели взаи мосвязи между объектами окажутся впоследствии нереализуемыми средствами выбранной СУБД . Это потребует изменения концептуальной модели . Версия концептуальной модели , котора я может быть обеспечена конкретной СУБД , называется логической моделью. Логическая модель отражает логические связи между элементами данных вне зависимости от их содержания и среды хранения . Логическая модель данных может быть реляционной , иерархической или сете вой . Пользователям выделяются подмножества этой логической модели , назы ваемые внешними моделями , отражающие их представления о предметной области . Внешняя модель соответствует представлениям , которые пользователи получают на осно ве логической моде л и , в то время как концептуальные требования отражают представления , которые пользователи первоначально желали иметь и которые легли в основу разработки концептуальной модели . Логическая модель отобра жается в физическую память , такую , как диск , лента или к акой-либо другой носитель информации. Иерархическая модель данных строится по принципу иерархии типов объектов , то есть один тип объекта является главным , а остальные , находящиеся на низших уровнях иерархии, — подчиненными . Между главным и подчинен ными об ъектами устанавливается взаимосвязь «один ко многим» . В то же время для каждого экземпляра главного объекта может быть несколько экземпляров подчиненных типов объектов . Взаимосвязи между объектами напоминают взаимосвязи в генеалогическом дереве за единств е нным исключением : для каждого порожденного (подчиненно го ) типа объекта может быть только один исходный (главный ) тип объекта. Итак , полученную концептуальную модель , будем считать логико-иерархической моделью данных . Потому что по моему мнению , больше пр еобразований не получится . Конечную модель можно считать оконченной. Физическая модель , определяющая размещение данных , методы доступа и технику индексирования , называется внутренней моделью системы. Внешние модели никак не связаны с типом физической памят и , в которой будут храниться данные , и с методами доступа к этим данным . Это положение отражает первый уровень независимости данных . С другой стороны , если концептуальная модель способна учитывать расширение требований к системе в будущем , то вносимые в не е изменения не должны оказывать влияния на существующие внешние модели . Это — второй уровень независимости данных . Построение логической модели обусловлено требованиями используемой СУБД . Поэтому при замене СУБД она также может измениться. С точки зрения п рикладного программирования независимость данных опреде ляется не техникой программирования , а его дисциплиной , т.е . для того чтобы при любом изменении системы избежать перекомпиляции приложения , рекомендуется не определять константы (постоянные значения д анных ) в программе . Лучшее решение состоит в передаче программе значений в качестве параметров. Все актуальные требования предметной области и адекватные им «скрытые» требования на стадии проектирования должны найти свое отражение в концеп туальной модели. Конечно , нельзя предусмотреть все возможные варианты использования и изменения базы данных . Но в большинстве предметных областей такие основные данные , как объекты и их взаимосвязи , относительно стабильны . Меняются только информационные требования , то ес т ь способы использования данных для получения информации. Степень независимости данных определяется тщательностью проектирования базы данных . Всесторонний анализ объектов предметной области и их взаимос вязей минимизирует влияние изменения требований к данн ым в одной программе на другие программы . В этом и состоит всеобъемлющая независимость данных. Основное различие между указанными выше тремя типами моделей данных (концептуальной , логической и физической ) состоит в способах представления взаимосвязей между объектами . При проектировании БД требуется различать взаимосвязи между объектами , между свойствами одного объекта и между свойствами различных объектов. В процессе проектирования объекты преобразуются в отношения , свойства в поля таблиц , методы – в процед уры , формы и т.д . (что и было произведено ). Правильно проведенный объектно-ориентированный анализ позволяет значительно облегчить работу. Таблица 3. Проект таблицы для физической модели. № п /п Наименование поля Примечание ТОВАР 1. Key_tovar Уникальный к люч товара 2. Key_postav Уникальный ключ поставщика 3. Key_zakaz Уникальный ключ заказчика 4. Name_tovar Наименование товара 5. Date Дата изготовления 6. Marka Акцизная марка 7. Kod Расшифровка штрих-кода 8. Srok_god Срок годности 9. Ves_b Вес Брут то 10. Ves_n Вес Нетто 11. Cena_1 Цена за единицу 12. Cena Суммарная цена 13. Upakovka Вид упаковки ЗАКАЗЧИК 1. Key_zakaz Уникальный ключ заказчика 2. Name_zakaz Наименование заказчика 3. Yrid_zakaz Юридическая принадлежность 4. FIO_zakaz Ф.И.О . руководителя 5. Adres_zakaz Адрес 6. Tel_zakaz Телефон /факс 7. Cena_z Предполагаемая цена 8. Number_N Номер накладной 9. Oplata Пометка об оплате 10. Date_N Дата накладной ПОСТАВЩИК 1. Key_poctav Уникальный ключ поставщика 2. Name_postav Наименова ние поставщика 3. Yrid_poctav Юридическая принадлежность 4. FIO_postav Ф.И.О . руководителя 5. Adres_postav Адрес 6. Tel_postav Телефон /факс 7. Number_D Номер договора 8. Date_Z Дата заключения СЧЕТА 1. Number_S Номер счёта 2. Date_P Дата продажи 3. Key_tovar Уникальный ключ товара 4. NDS НДС 5. Summa Сумма к оплате Одним из основных факторов , влияющих на производительность программ , которые взаимодействуют с базой данных , является способ хранения и доступа к данным . Обычно в дополнение к специа лизированным методам доступа в рамках внешней модели СУБД использует несколько методов доступа внутренней модели . Мы рассмотрим (по условию варианта ) индексно-последовательный метод доступа (ИМД ). Существует множество индексных методов доступа , в основе ко торых лежит принцип создания отдельного файла или структуры из статей значений действительного ключа . Статья действительного ключа называется статьёй индекса , а весь файл действительных ключей - индексом . Индексный файл значительно меньше собственно базы д анных , и , поскольку в оперативной памяти могут находиться многие из его статей , скорость поиска в нём гораздо выше. В индексно-последовательном методе доступа индексный файл всегда упорядочен по так называемому первичному ключу . Первичный ключ - главный ат рибут физической записи . По его значению идентифицируется физическая запись . До тех пор , пока это возможно , записи хранятся в той же логической последовательности , что и индекс (отсюда и название "индексно-последовательный метод доступа "). Приведём пример таблицы индексов и их связи с имеющимися файлами данных , согласно варианта. Таблица 4. Таблица индексного файла "ТОВАР " для индексно-последовательного метода доступа. Примечание (Доходя через индексы к файлу данных , посредством самого индекса считывается н аименование товара и далее вся информация по полям находящаяся в записи , согласно таблицы ТОВАР ). Индексный файл Блок 7 Значение Ключа Номер Блока Файл данных Блок 1 10 1 01 15 2 05 Индексный файл 10 Блок 10 Блок 2 Значение Номер 11 Ключа Блока 15 15 7 25 8 Блок 3 35 9 Блок 8 16 Индекс 2-го уровня Значение Номер 20 Ключа Блока 20 3 25 4 Блок 4 21 25 Блок 5 Блок 9 26 Значение Номер 30 Ключ а Блока 30 5 Блок 6 35 6 31 Индекс 1-го уровня 35 Уникальный ключ товара Наименование товара Уникальный ключ поставщика Уникальный ключ заказчика Дата изготовления Акцизная марка Расшифровка штрих-кода Срок годности Вес Брутто Вес Н етто Цена за единицу Суммарная цена Вид упаковки Форма «ГЛАВНАЯ КНОПОЧНАЯ ФОРМА» Option Compare Database Option Explicit Private Sub Form_Open(Cancel As Integer) ' Свертывание окна базы данных , инициализация формы. ' Переход на страницу кнопочной формы , отмеченную для использования по умолчанию. Me.Filter = "[ItemNumber] = 0 AND [Argument] = 'по умолчанию ' " Me.FilterOn = True End Sub Private Sub Form_Current() ' Обновление заголовка и заполнение списка команд. Me.Caption = Nz(Me![ItemText], "") FillOptions End Sub Private Sub FillOptions() ' Заполнение команд для страницы кнопочной формы. ' Число кнопок в форме. Const conNumButtons = 8 Dim dbs As Database Dim rst As Recordset Dim strSQL As String Dim intOption As Integer ' Установка фокус а на первую кнопку формы , скрытие всех кнопок формы , кроме первой. ' Поле с фокусом скрыть нельзя. Me![Option1].SetFocus For intOption = 2 To conNumButtons Me("Option" & intOption).Visible = False Me("OptionLabel" & intOption).V isible = False Next intOption ' Открытие таб . элементов кнопочной формы , поиск первого элемента текущей страницы формы. Set dbs = CurrentDb() strSQL = "SELECT * FROM [Элементы кнопочной формы ]" strSQL = strSQL & " WHERE [ItemNumber] > 0 AND [SwitchboardID]=" & Me![SwitchboardID] strSQL = strSQL & " ORDER BY [ItemNumber];" Set rst = dbs.OpenRecordset(strSQL) ' Вывод сообщения при отсутствии элементов на странице кнопочной формы. ' В остальных случаях - заполнение страницы элементами. If (rst.EOF) Then Me![OptionLabel1].Caption = "Элементы кнопочной формы отсутствуют " Else While (Not (rst.EOF)) Me("Option" & rst![ItemNumber]).Visible = True Me("OptionLabel" & rst![ItemNumber]).Visible = True Me("OptionLabel" & rst![ItemNumber]).Caption = rst![ItemText] rst.MoveNext Wend End If ' Закрытие набора записей и базы данных. rst.Close dbs.Close End Sub Private Function HandleButtonClick(intBtn As Integer) ' Эта функ . вызывается при нажатии кнопки . Аргумент intBtn указывает , какая кнопка была нажата. ' Константы для выполняемых команд. Const conCmdGotoSwitchboard = 1 Const conCmdOpenF ormAdd = 2 Const conCmdOpenFormBrowse = 3 Const conCmdOpenReport = 4 Const conCmdCustomizeSwitchboard = 5 Const conCmdExitApplication = 6 Const conCmdRunMacro = 7 Const conCmdRunCode = 8 ' Особая ошибка. Const conErrDoCmdCan celled = 2501 Dim dbs As Database Dim rst As Recordset On Error GoTo HandleButtonClick_Err ' Поиск записи , соответствующей нажатой кнопке , в таблице элементов кнопочной формы. Set dbs = CurrentDb() Set rst = dbs.OpenRecordset("Элементы кнопочной формы ", dbOpenDynaset) rst.FindFirst "[SwitchboardID]=" & Me![SwitchboardID] & " AND [ItemNumber]=" & intBtn ' Если нужная запись не найдена , вывод сообщения об ошибке и выход из функции. If (rst.NoMatch) Then MsgBox "Ошибка п ри чтении таблицы элементов кнопочной формы ." rst.Close dbs.Close Exit Function End If Select Case rst![Command] ' Переход к другой кнопочной форме. Case conCmdGotoSwitchboard Me.Filter = "[ItemNu mber] = 0 AND [SwitchboardID]=" & rst![Argument] ' Открытие формы в режиме добавления записей. Case conCmdOpenFormAdd DoCmd.OpenForm rst![Argument], , , , acAdd ' Открытие формы. Case conCmdOpenFormBrowse DoCmd.OpenForm rst![Argument] ' Открытие отчета. Case conCmdOpenReport DoCmd.OpenReport rst![Argument], acPreview ' Настройка кнопочной формы. Case conCmdCustomizeSwitchboard ' Обработка ситуации , когда диспетчер ' кнопочных форм не установлен ' (например , при сокращенной установке ). On Error Resume Next Application.Run "WZMAIN80.sbm_Entry" If (Err <> 0) Then MsgBox "Команда недоступна ." On Error GoTo 0 ' Обновление формы. Me.Filter = "[ItemNumber] = 0 AND [Argument] = 'по умолчанию ' " Me.Caption = Nz(Me![ItemText], "") FillOptions ' Выход из приложения. Case conC mdExitApplication CloseCurrentDatabase ' Запуск макроса. Case conCmdRunMacro DoCmd.RunMacro rst![Argument] ' Выполнение программы. Case conCmdRunCode Application.Run rst![Argument] ' Другие команды не поддерживаются. Case Else MsgBox "Неизвестная команда ." End Select ' Закрытие набора записей и базы данных. rst.Close dbs.Close HandleButtonClick_Exit: Exit Function HandleButtonClick_Err: ' Если выполнение прервано пользователем , сообщение об ошибке не выводится. ' Вместо этого выполнение продолжается со следующей строки. If (Err = conErrDoCmdCancelled) Then Resume Next Else MsgBox "Ошибка при выполнении команды .", vbCritical Resume HandleButtonClick_Exit End If End Function Форма «ЗАКАЗЧИК» Option Compare Database Option Explicit Private Sub Кнопка 18_Click() On Error GoTo Err_Кнопка 18_Click DoCmd.DoMenuItem acFormBar, acEditMenu, 8, , acMenuVer70 DoCmd.DoMenuItem acFormBar, acEditMenu, 6, , acMenuVer70 Exit_Кнопка 18_Click: Exit Sub Err_Кнопка 18_Click: MsgBox Err.Description Resum e Exit_Кнопка 18_Click End Sub Private Sub Кнопка 20_Click() On Error GoTo Err_Кнопка 20_Click Dim stDocName As String stDocName = "Запрос 2" DoCmd.OpenReport stDocName, acPreview Exit_Кнопка 20_Click: Exit Sub Err_Кнопка 20_Click: MsgBox Err.Description Resume Exit_Кнопка 20_Click End Sub Private Sub Кнопка 33_Click() On Error GoTo Err_Кнопка 33_Click Dim stDocName As String Dim stLinkCriteria As String stDocName = "Товары " DoCmd.OpenForm stDocName, , , stLinkC riteria Exit_Кнопка 33_Click: Exit Sub Err_Кнопка 33_Click: MsgBox Err.Description Resume Exit_Кнопка 33_Click End Sub Sub ПолеСоСписком 34_AfterUpdate() ' Поиск записи , соответствующей этому элементу управления. Me.RecordsetClone.FindFirst "[Name_zakaz] = '" & Me![ПолеСоСписком 34] & "'" Me.Bookmark = Me.RecordsetClone.Bookmark End Sub Форма «ПОСТАВЩИК» Option Compare Database Option Explicit Private Sub Кнопка 18_Click() On Error GoTo Err_Кнопка 18_Click DoCmd.DoMenuItem acFormBar, acEditMenu, 8, , acMenuVer70 DoCmd.DoMenuItem acFormBar, acEditMenu, 6, , acMenuVer70 Exit_Кнопка 18_Click: Ex it Sub Err_Кнопка 18_Click: MsgBox Err.Description Resume Exit_Кнопка 18_Click End Sub Private Sub Кнопка 20_Click() On Error GoTo Err_Кнопка 20_Click Dim stDocName As String stDocName = "Запрос 1" DoCmd.OpenReport stDocName, acPreview Exit _Кнопка 20_Click: Exit Sub Err_Кнопка 20_Click: MsgBox Err.Description Resume Exit_Кнопка 20_Click End Sub Форма «ТОВАР» Option Compare Database Option Explicit Sub ПолеСоСписком 18_AfterUpdate() ' Поиск записи , соответствующей этому элементу управления. Me.RecordsetClone.FindFirst "[Name_tovar] = '" & Me![ПолеСоСписком 18] & "'" Me.Bookmark = Me.RecordsetClone.Bookmark End Sub Private Sub Кнопка 25_Click() On Error GoTo Err_Кнопка 25_Click DoCmd.Close Exit_Кнопка 25_Click: Exit Sub Err_Кнопка 25_Click: MsgBox Err.Description Resume Exit_Кнопка 25_Click End Sub Форма «О ПРОГРАММЕ» Option Compare Database ' Сортировка базы данных для сравнения строк. Option Explicit ' Обязательное описание переменных перед применением. Private Sub Отмена _Click() ' Программа , созданная мастером кнопок. On Error GoTo Err_Cancel_Click ' Закрытие формы. DoCmd.Close Exit_Cancel_Click: Exit Sub Err_Cancel_Click: MsgBox Err.Description Resume Exit_Cancel_Click End Sub Private Sub ОК _Cl ick() On Error GoTo Err_OK_Click Dim strMsg As String, strTitle As String Dim intStyle As Integer ' Если отчет о продажах по годам не был открыт для просмотра или печати , возникает ошибка. ' (Перем . blnOpening имеет значение True, толь ко если для отчета произошло событие Open.) If Not Reports![Дата ].blnOpening Then Err.Raise 0 ' Скрытие формы. Me.Visible = False Exit_OK_Click: Exit Sub Err_OK_Click: strMsg = "Для использования формы нужно просматривать или печатать о тчет 'Продажи по годам ' из окна базы данных или конструктора ." intStyle = vbOKOnly strTitle = "Открытие из отчета " MsgBox strMsg, intStyle, strTitle Resume Exit_OK_Click End Sub Private Sub Кнопка 5_Click() On Error GoTo Err_Кнопка 5_Click DoCmd.Close Exit_Кнопка 5_Click: Exit Sub Err_Кнопка 5_Click: MsgBox Err.Description Resume Exit_Кнопка 5_Click End Sub Форма «ПОДЧИНЁННАЯ ФОРМА ТОВАРА» Option Compare Database Option Explicit Private Sub Кнопка 22_Click() On Error GoTo Err_Кно пка 22_Click DoCmd.DoMenuItem acFormBar, acEditMenu, 8, , acMenuVer70 DoCmd.DoMenuItem acFormBar, acEditMenu, 6, , acMenuVer70 Exit_Кнопка 22_Click: Exit Sub Err_Кнопка 22_Click: MsgBox Err.Description Resume Exit_Кнопка 22_Click End Sub Private Sub Кнопка 23_Click() On Error GoTo Err_Кнопка 23_Click DoCmd.DoMenuItem acFormBar, acEditMenu, 8, , acMenuVer70 DoCmd.DoMenuItem acFormBar, acEditMenu, 6, , acMenuVer70 Exit_Кнопка 23_Click: Exit Sub Err_Кнопка 23_Click: MsgBox Err.Descrip tion Resume Exit_Кнопка 23_Click End Sub ЗАПРОС 1 SELECT Товары .Name_tovar, Sum(Товары .Cena) AS Sum_Cena, Поставщик .Name_postav, Поставщик .Number_D, Поставщик .Date_Z FROM Поставщик INNER JOIN Товары ON Поставщик .Key_postav = Товары .Key_tovar WHERE ( ((Поставщик .Name_postav)=[Forms]![Поставщик ]![Name_postav])) GROUP BY Товары .Name_tovar, Поставщик .Name_postav, Поставщик .Number_D, Поставщик .Date_Z; ЗАПРОС 2 SELECT Заказчик .Name_zakaz, Заказчик .Adres_zakaz, Заказчик .Number_N, Заказчик .Date_N, Товары .Name_ tovar, Товары .Srok_god, Товары .Ves_b, Товары .Ves_n, Товары .Cena, Товары .Date FROM [Заказчик ] INNER JOIN Товары ON Заказчик .Name_tov = Товары .Name_tovar WHERE ((( Заказчик .Name_tov)=[Forms]![ Заказчик 1]![Name_tov])) GROUP BY Заказчик .Name_zakaz, Заказчик .Adre s_zakaz, Заказчик .Number_N, Заказчик .Date_N, Товары .Name_tovar, Товары .Srok_god, Товары .Ves_b, Товары .Ves_n, Товары .Cena, Товары .Date;
1Архитектура и строительство
2Астрономия, авиация, космонавтика
 
3Безопасность жизнедеятельности
4Биология
 
5Военная кафедра, гражданская оборона
 
6География, экономическая география
7Геология и геодезия
8Государственное регулирование и налоги
 
9Естествознание
 
10Журналистика
 
11Законодательство и право
12Адвокатура
13Административное право
14Арбитражное процессуальное право
15Банковское право
16Государство и право
17Гражданское право и процесс
18Жилищное право
19Законодательство зарубежных стран
20Земельное право
21Конституционное право
22Конституционное право зарубежных стран
23Международное право
24Муниципальное право
25Налоговое право
26Римское право
27Семейное право
28Таможенное право
29Трудовое право
30Уголовное право и процесс
31Финансовое право
32Хозяйственное право
33Экологическое право
34Юриспруденция
 
35Иностранные языки
36Информатика, информационные технологии
37Базы данных
38Компьютерные сети
39Программирование
40Искусство и культура
41Краеведение
42Культурология
43Музыка
44История
45Биографии
46Историческая личность
47Литература
 
48Маркетинг и реклама
49Математика
50Медицина и здоровье
51Менеджмент
52Антикризисное управление
53Делопроизводство и документооборот
54Логистика
 
55Педагогика
56Политология
57Правоохранительные органы
58Криминалистика и криминология
59Прочее
60Психология
61Юридическая психология
 
62Радиоэлектроника
63Религия
 
64Сельское хозяйство и землепользование
65Социология
66Страхование
 
67Технологии
68Материаловедение
69Машиностроение
70Металлургия
71Транспорт
72Туризм
 
73Физика
74Физкультура и спорт
75Философия
 
76Химия
 
77Экология, охрана природы
78Экономика и финансы
79Анализ хозяйственной деятельности
80Банковское дело и кредитование
81Биржевое дело
82Бухгалтерский учет и аудит
83История экономических учений
84Международные отношения
85Предпринимательство, бизнес, микроэкономика
86Финансы
87Ценные бумаги и фондовый рынок
88Экономика предприятия
89Экономико-математическое моделирование
90Экономическая теория

 Анекдоты - это почти как рефераты, только короткие и смешные Следующий
С соседом снизу мы заключили договор. Он не будет врубать громко музыку, а я не буду дарить теще скакалку.
Anekdot.ru

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

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

Смотрите также:


Банк рефератов - РефератБанк.ру
© РефератБанк, 2002 - 2016
Рейтинг@Mail.ru