Среда разработки приложений баз данных. Как я создаю базу данных для своих приложений. Хаотическое проектирование баз данных
Федеральное агентство по образованию
Государственное образовательное учреждение высшего профессионального образования
«ЧЕЛЯБИНСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ»
Курсовая работа
Разработка приложений баз данных
Анализ предметной области
Описание предметной области и функции решаемых задач
В курсовой работе в соответствии с заданием автоматизируется деятельность отдела сбыта предприятия «Русская еда».
Предметом области автоматизации являются некоторые должностные функции отдела сбыта. В отделе сбыта имеется план выпуска готовой продукции составленный на три месяца. В соответствии с этим планом цеха выпускают продукцию, но фактический выпуск продукции зависит от многих факторов и может отличаться от планового. В отдел сбыта поступают также цеховые накладные, которые отражают фактический выпуск продукции и сдачу ее на определенные склады.
Задача отдела сбыта - сделать анализ выполнения плана сдачи изделий на склады. Для этого необходимо выбрать плановые и фактические данные за определенный период по определенному складу и проанализировать отклонение факта от плана.
На предприятии работают 3 цеха, в которых производится продукция. Ассортимент выпускаемой продукции приведен в таблице.
Таблица 1.
№ цехаНаименование цехаНаименование выпускаемой продукцииМинимальная единица выпускаЦена за единицу молоко 3.5%коробка 50 штук650,00р.1молочный молоко 4.0%коробка 50 штук700,00р. сливкикоробка 50 штук1 200,00р. колбаса варёнаяупаковка 50 штук2 500,00р.2колбасный колбаса копчёнаяупаковка 50 штук3 400,00р. сосискиупаковка 50 штук1 200,00р. судак консервированныйкоробка 50 банок670,00р.3рыбныйикра чёрнаякоробка 50 банок5 400,00р. икра краснаякоробка 50 банок5 370,00р.Выпущенная цехами продукция сдается на склады
Таблица 2. № складаНаименование склада1Склад № 12Склад № 23Склад № 3 Перечень входных (первичных) документов. В качестве первичных документов для решения данной задачи используются:
план выпуска изделий цехами список цеховых накладных Номер цехаНомер цеховой накладнойДата сдачи спецификация цеховой накладной Номер цехаНомер цеховой накладнойКод изделияКоличество Ограничение предметной области.
При разработке курсового проекта допускаются следующие ограничения: готовое изделие закреплено за одним складом готовой продукции и может выпускаться несколькими цехами. у готового изделия только одна единица измерения. один цех может выпускать несколько наименований изделий. на одном складе может храниться несколько наименований готовых изделий. выпуск цехом готовой продукции планируется помесячно. одно и то же изделие может быть запланировано к выпуску в разные месяцы. накладная цеха на сдачу готовой продукции на склад может содержать несколько наименований изделий, ее номер уникален только для одного цеха. Постановка задачи Организационно-экономическая сущность комплекса задач. Одной из основных проблем на предприятии является несоответствие планового количества выпуска продукции, который формируется в соответствии с заявками покупателей и фактического количества продукции, отгружаемой цехами на склады. Для решения этой проблемы необходимо своевременно (оперативно) получать информацию о наличии, нехватке или излишках продукции на складах по отношению к плану. Излишки залеживаются на складе, у них может быть превышен срок хранения, создаются неликвиды.
Описание выходной информации
Выходную информацию представим в виде отчетной формы.
Анализ выполнения плана сдачи изделий на склад _________________ МесяцНаименование изделияЕдиница измеренияКоличествоИзлишкиПланФакт Для получения этой формы используются данные первичных документов: список изделий; список складов; список цехов; план выпуска изделий цехами; список цеховых накладных; Описание входной информации. Входную информацию делят на условно-постоянную (справочники), сохраняющую свои значения на длительный период времени, и постоянно меняющуюся, то есть оперативно-учетную информацию. К условно-постоянной информации относятся: список выпускаемых изделий; список выпускающих цехов; список складов; справочник единиц измерения. К оперативно-учетной информации относятся: план выпуска изделий цехами; список цеховых накладных; спецификация цеховой накладной. Представим первичные документы с реквизитами в Таблице 3:
№ п/пНаименование документаРеквизиты1Список выпускаемых изделий1.Код изделия 2.Наименование изделия. 3.Код единицы измерения. 4.Цена. 5.Номер склада3Список складов1.Код склада. 2.Наименование склада.2Список цехов1.Код цеха. 2.Наименование цеха.4Справочник единиц измерения1.Код единицы измерения. 2.Наименование единицы измерения.5План выпуска изделий цехами1.Номер цеха. 2.Месяц выпуска. 3.Код изделия. 4.Количество6Список цеховых накладных1.Номер цеха. 2.Номер цеховой накладной. 3.Дата сдачи.7Спецификация цеховой накладной1.Номер цеха. 2.Номер цеховой накладной. 3.Код изделия. 4.Количество.
Проектирование базы данных
Выделение информационных объектов
Одним из наиболее сложных этапов в процессе проектирования базы данных является разработка таблиц, так как результаты, которые должна выдавать база данных (отчеты, выходные формы и др.) не всегда дают полное представление о структуре таблицы. Информация в таблице не должна дублироваться. Не должно быть повторений и между таблицами. Когда определенная информация храниться только в одной таблице, то и изменять ее придется только в одном месте. Это делает работу более эффективной, а также исключает возможность несовпадения информации в разных таблицах. Каждая таблица должна содержать информацию только на одну тему. Сведения на каждую тему обрабатываются намного легче, если содержаться они в независимых друг от друга таблицах. Каждая таблица содержит информацию на отдельную тему, а каждое поле в таблице содержит отдельные сведения по теме таблицы Для реализации связи данных из разных таблиц каждая таблица должна содержать поле или набор полей, которые будут задавать индивидуальное значение каждой записи в таблице. Такое поле или набор полей называют основным ключом. После распределения данных по таблицам и определения ключевых полей необходимо определить связи между таблицами. Таблица 4 Информационные объекты Информационный объектСоответствующий документРеквизитыКлючИзделияСписок выпускаемых изделийКод изделияДа Наименование изделияКод единицы измеренияЦена Номер складаЦехаСписок цеховНомер цехаДа Наименование цехаСкладыСписок складовНомер складДаНаименование складаЕдиница измеренияСправочник единиц измеренияКод единицы измеренияДа Наименование единицы измеренияПлан выпускаПлан выпуска изделий цехамиНомер цехаДаНомер месяцаДа Код изделияДа КоличествоЦеховые накладныеСписок цеховых накладныхНомер цехаДа Номер цеховой накладнойДа Дата сдачиСпецификации Спецификация цеховой накладнойНомер цехаДаНомер цеховой накладнойДа Код изделияДа КоличествоМесяцДля объекта «План выпуска»Номер месяцаДаНазвание месяца Информационно-логическое моделирование и определение связей между информационными объектами
Информационно-логическая модель - это модель данных, отображающая предметную область в виде совокупности информационных объектов и структурных связей между ними. Наша информационно-логическая модель будет иметь следующий вид:
Рис.1. Инфологическая модель
В результате разработки базы данных получили 8 информационных объектов. Определим тип связи в каждой паре этих инф. объектов. Единица измерения - Изделие Тип связи 1- ко многим, так как несколько изделий могут измеряться одной единицей измерения, но каждое изделие в данный момент измеряется одной единицей измерения. Связь между этими объектами - по реквизиту Код единицы измерения. Склады - Изделие Тип связи 1- ко многим, так как на одном складе может храниться несколько наименований готовых изделий. Связь - по реквизиту Номер склада. Изделия - План выпуска Тип связи 1- ко многим, так как одно изделие может быть запланировано для выпуска в разные месяцы, но каждое запланированное количество относится только к одному изделию в данном месяце. Связь по реквизиту Код изделия. Месяц - План выпуска Тип связи 1- ко многим, в каждом месяце составляется план выпуска изделий. Связь по реквизиту Номер месяца. Цеха - План выпуска Тип связи 1- ко многим, одному цеху запланирован выпуск в разные месяцы. Связь по реквизиту Номер цеха. Цеха - Цеховые накладные Цеха - Спецификации Тип связи 1- ко многим, один цех выписывает много накладных. Связь по реквизиту Номер цеха. Цеховые накладные - Спецификации Тип связи 1- ко многим, одна цеховая накладная может содержать несколько спецификаций на изделие. Связь по реквизитам - Номер цеховой накладной и номер цеха. Изделие - Спецификации Тип связи 1- ко многим, одно изделие выпускается не один раз, но данное выпущенное количество относится только к одному изделию. Связь по реквизиту Код изделия.
Логическая структура базы данных
Логическая структура реляционной базы данных является адекватным отображением полученной информационно-логической модели предметной области. Для канонической модели не требуется дополнительных преобразований. Каждый информационный объект модели данных отображается соответствующей реляционной таблицей. Структура реляционной таблицы определяется реквизитным составом соответствующего информационного объекта, где каждый столбец (поле) соответствует одному из реквизитов. Ключевые реквизиты образуют уникальный ключ реляционной таблицы. Для каждого столбца таблицы задается тип, размер данных и другие свойства. Топология проекта схемы данных практически совпадает с топологией информационно - логической модели. В рамках данной курсовой работы логическая структура базы данных будет иметь вид (рис.2.):
Рис.2. Логическая структура базы данных
Реализация базы данных в среде Microsoft Access
Для реализации спроектированной базы данных будем использовать одну из наиболее популярных систем управления базами данных для операционной системы Windows Microsoft Access. Данная СУБД входит в широко распространенный интегрированный пакет фирмы Microsoft Office и полностью совместима с программами этого пакета. Большим преимуществом MS Access является наличие средств разработки информационных систем для пользователей различной квалификации: от начинающих до профессионалов. СУБД MS Access ориентирована на работу со следующими объектами: Таблицы являются основным элементом всякой реляционной базы данных, предназначены для определения и хранения данных; Запросы служат источниками для построения других запросов, форм и отчетов. Запросы позволяют изменять и анализировать данные. Наиболее распространенный тип запроса - запрос на выборку - представляет собой набор правил, по которым отбираются данные из одной или нескольких связанных таблиц. Результаты выполнения запроса на выборку представляются в виде виртуальной таблицы. Формы - объект, предназначенный в основном для ввода данных, отображения их на экране или управления работой приложения. Есть возможность использовать формы для того, чтобы реализовать требования пользователя к представлению данных из запросов или таблиц, формы можно также распечатать. Отчеты - это средство для организации вывода данных на печать. С помощью отчета имеется возможность вывести необходимые сведения в нужном виде. Возможен предварительный просмотр отчета перед выводом на печать. Источниками данных для отчетов служат таблицы и запросы; Макросы - объект, представляющий собой структурированное описание одного или нескольких действий, которые, должен выполнить MS Access в ответ на определенное событие. Модули - это объекты, содержащие программы, написанные на языке Visual Basic for Applications (VBA). В рамках поставленной задачи нет необходимости создавать макросы и модули в спроектированной базе данных. Все объекты MS Access размещаются в одном файле на диске. MS Access имеет многооконный интерфейс, но одновременно может обрабатывать только одну базу данных. Для создания новой базы данных требуется запустить MS Access, выбрать режим «Новая база данных», ввести имя базы данных и выбрать место ее расположения на диске. Таблицами спроектированной БД являются информационные объекты, поля таблиц - реквизиты информационных объектов. Для заполнения входной информации необходимо будет спроектировать пользовательский интерфейс - формы: форма «Изделия» - для редактирования таблицы «Изделия»; форма «План выпуска» - для коррекции плана количества выпускаемых изделий; форма «Цеховые накладные», соединяющую таблицу «Цеховые накладные» и зависимую от «Цеховых накладных» таблицу «Спецификации цеховых накладных». Для реализации отчета «Анализ выполнения плана сдачи изделий на склад» достаточно будет выполнить один запрос на выборку месяца (таблица «месяц»), наименования изделия (таблица «Изделия»), единицы измерения (таблица «Единица измерения»), количества по плану (таблица «План выпуска»), количества по факту (таблица «Спецификации»), с добавлением столбца «излишки» с формулой вычитания. Создание таблиц и схема данных приложение база данный сбыт Существует несколько режимов создания таблиц (режим таблицы, конструктор, мастер таблицы, импорт таблиц, связь с таблицами из других баз данных). Наиболее универсальный путь создания таблицы - использование режима конструктора. Для создания таблицы в этом режиме необходимо определить поля таблицы. Каждое поле характеризуется именем, типом данных и свойствами. Имя поля не должно содержать специальных символов. В Microsoft Access возможно использование следующих типов данных: Текстовый - служит для хранения алфавитно-цифровой информации. Длина поля не должна превышать 255 символов; Поле MEMO - предназначен для хранения алфавитно-цифровой информации длиной до 65535 символов; Числовой - используется для числовых данных, участвующих в расчетах; Дата / время - дата и (или) время, лежащие в диапазоне от 100 до 9999 года; Денежный - применяется для денежных значений и числовых данных, используемых в математических расчетах, проводящихся с точностью до 15 знаков в целой и до 4 знаков в дробной части; Счетчик - служит для формирования уникальных последовательно возрастающих или случайных чисел, автоматически вводящихся в поле при добавлении каждой новой записи в таблицу. Значения полей типа Счетчик изменять нельзя; Логический - предназначен для логических значений (Да / Нет, Истина / Ложь). Длина логического поля - 1 бит; Поле объекта OLE - любой объект в двоичном формате (документ Word, таблица Excel, рисунок, звукозапись), связанный или внедренный в таблицу MS Access. Размер такого поля не дожжен превышать 1 Гбайт; Мастер подстановок - создает поле, в котором предлагается выбор значений из списка, или из поля со списком, содержащего набор постоянных значений или значений из другой таблицы. Выбор этого параметра в списке в ячейке запускает мастера подстановок, который определяет тип поля. Свойства полей задаются в нижней части окна конструктора таблицы на вкладке «Общие». Перечень свойств различен для каждого типа данных. Рассмотрим некоторые из них: Размер поля - ограничивает длину поля указанным количеством символов; Формат - указывает формат для даты и чисел; Число десятичных знаков - для денежных и числовых полей устанавливает количество десятичных знаков; Маска ввода - для текстовых полей и полей даты определяет шаблон, в соответствии с которым будут вводиться данные в поле; Индексированное поле - позволяет создать индекс, который будет служить для ускорения поиска и сортировки таблицы по данному полю. Индекс - это внутренняя служебная таблица, состоящая из двух столбцов: значения индексируемого поля и номера таблицы. Можно установить следующие свойства для индексов: а) «Да (допускаются совпадения)» - создается индекс, который включает совпадающие значения полей, б) «Да (совпадения не допускаются)» - создается индекс, базирующийся на уникальном значении поля, в) «Нет» - индекс не создается Таблица в MS Access обычно содержит первичный ключ. Для создания ключа нужно в конструкторе выбрать поле и назначить его ключевым через контекстное меню. ПолеТип данныхРазмер поляПервичный ключКод единицы измеренияЧисловой Длинное целоеДа Наименование единицы измеренияТекстовый50 Таблица «Изделия» ПолеТип данныхРазмер поляПервичный ключКод изделияЧисловой Длинное целоеДа Наименование изделияТекстовый100Код единицы измеренияЧисловойДлинное целоеЦена Денежный-Номер складаЧисловойБайт Таблица «Склады» ПолеТип данныхРазмер поляПервичный ключНомер складЧисловой БайтДа Наименование складаТекстовый20 Таблица «Месяц» ПолеТип данныхРазмер поляПервичный ключНомер месяцаЧисловой ЦелоеДа(совпадения не допускаются)Название месяца Текстовый20 Таблица «Цех» ПолеТип данныхРазмер поляПервичный ключНомер цехаЧисловой БайтДа Наименование цехаТекстовый30 Таблица «План выпуска» ПолеТип данныхРазмер поляПервичный ключНомер цехаЧисловойБайтДаНомер месяцаЧисловойЦелоеДаКод изделияЧисловой Длинное целоеДаКоличествоЧисловойДействительное (16)Таблица «Цеховые накладные»
ПолеТип данныхРазмер поляПервичный ключНомер цехаЧисловойБайтДа Номер цеховой накладнойЧисловойДлинное целоеДа Дата сдачиДата\время- Таблица «Спецификации» ПолеТип данныхРазмер поляПервичный ключНомер цехаЧисловойБайтДаНомер цеховой накладнойЧисловойДлинное целоеДаКод изделияЧисловой Длинное целоеДаКоличествоЧисловойДействительное (16)
Создаем схему данных в Microsoft Access:
Рис.3. Схема данных
Создание пользовательского интерфейса
Формы являются основным средством создания интерфейса пользователя, который обеспечивает наиболее удобный способ представления, просмотра, редактирования данных и управления ходом выполнения приложения. Основные функции форм - ввод данных, вывод и редактирование информации, управление ходом выполнения приложения, вывод сообщений, печать информации. Существуют следующие виды форм: Обычная - отображает одну запись источника данных; Многостраничная - предназначена для работы с источником данных, имеющим большое количество полей; Ленточная - показывает несколько записей источника данных, удобна для небольшого количества полей; Всплывающая - выводится на переднем плане экрана и позволяет работать с другими формами; Монопольная - не позволяет переключиться в другие формы, пока не будет закрыта; Подчиненная - хорошее средство для представления данных, находящихся на стороне «многие» отношения «один-ко-многим», внедряется в основную форму и всегда от нее зависит. Структурно форма состоит из трех разделов - заголовка, примечания и области данных. В разделах формы располагаются элементы управления. Любой элемент управления может быть помещен в форму при помощи панели элементов, которая отображается в конструкторе формы. Наиболее часто используемые элементы: (надпись) - служит для создания в форме постоянных надписей;
(поле) - элемент, который показывает значение из источника данных;
(поле со списком) - предназначено для создания в форме раскрывающихся списков;
(кнопка) - предназначена для создания в форме командных кнопок, выполняющих определенные действия;
(флажок) - элемент, позволяющий включать или выключать значение какого-нибудь параметра;
(подчиненная форма) - служит для внедрения подчиненной формы в основную.
Форму удобнее создавать при помощи мастера. На первом шаге необходимо выбрать источник данных и поля для формы. На втором шаге следует указать внешний вид проектируемой формы. Третий шаг - выбор стиля формы (фоновый рисунок для формы, формат шрифтов и цветовая гамма). На последнем шаге следует ввести имя формы, под которым она будет храниться в базе данных. Созданную при помощи мастера форму требуется доработать в режиме конструктора. Добавляем необходимые надписи, кнопки, подчиненные формы. В рамках курсовой работы созданы следующие формы:
Рис. 4. Изделия. Рис.5. План выпуска.
Форма «цеховые накладные» содержит подчиненную форму «Спецификации» Рис.6. Цеховые накладные.
Реализация отчета
Перед созданием отчета требуется сформировать запрос. Запросы являются важным инструментом в любых системах управления базами данных. Назначение запросов - в описании типов запросов. Запросы можно создавать как в режиме мастера запросов (тогда предстоит выбрать тип запроса), так и конструктором запросов. Существует четыре типа запросов в Microsoft Access: простые запросы на выборку отображают данные из одной или нескольких таблиц в виде таблицы; добавление параметра (условие отбора) допускается; перекрестные запросы собирают данные из одной или нескольких таблиц в формате, похожем на формат электронной таблицы, и используются для анализа данных; добавление параметра (условие отбора) допускается; запросы на изменение используются для создания новых таблиц из результатов запроса и для внесения изменений (добавления, удаления) в данные существующих таблиц; добавление параметра (условие отбора) допускается; запрос на поиск записей, которым не соответствует ни одна запись в подчиненной таблице. При помощи запросов в режиме мастера запроса (выбирая итоговый отчет запроса) возможно выполнение вычисления (сумма, среднее, минимум, максимум) с использованием выбранных данных. Для реализации отчета «Анализ выполнения плана сдачи изделий на склад №___» достаточно будет выполнить один запрос на выборку месяца (таблица «месяц»), наименования изделия (таблица «Изделия»), единицы измерения (таблица «Единица измерения»), количества по плану (таблица «План выпуска»), количества по факту (таблица «Спецификации»), с добавлением столбца «излишки» с формулой вычитания, а также с выборкой номера склада (таблица «склады») с условием отбора без вывода этого склада в результирующую таблицу. Для данного отчета запрос был создан с помощью конструктора: Рис.8. Результат запроса.
По разному количеству товара из спецификации видно, что судак консервированный сдавали на склад и в июле, и в сентябре по два раза.
Создание отчетов
Отчеты представляют собой наилучшее средство для представления информации из базы данных в виде печатного документа. Они предоставляют широкие возможности для группировки и вычисления промежуточных и общих итогов для больших наборов данных. Отчеты могут быть использованы для получения красиво оформленных счетов, заказов на покупку, почтовых наклеек, материалов для презентаций и других документов, которые могут понадобиться для успешного ведения бизнеса. В отчете имеются следующие области: заголовок - выводится только один раз в начале отчета; верхний и нижний колонтитулы - повторяются на каждом листе отчета, используются для отображения постоянной или периодической информации (дата отчета, номера страниц и т.д.); заголовки и примечания для групп - отображаются при выполнении группировки в отчете в начале и в конце каждой группы соответственно. В отчете можно создать до десяти уровней группировки; область данных - служит для ввода информативных строк отчета; примечание отчета - предназначен для вывода итоговой информации по отчету в целом, печатается один раз в конце отчета. Создание отчета, так же как и формы, удобнее выполнять при помощи мастера. После создания отчета его структуру можно изменить в режиме конструктора (исправить и отформатировать заголовки столбцов отчета, добавить или удалить поля и т.д.). В результате выполнения отчета получен его печатный вид. Анализ выполнения плана сдачи изделий на склад № 1, 2, 3 - рис.10-12. Поле «номер цеховой накладной» добавлено, чтобы было видно, что изделие могли сдать на склад два раза в месяц по двум разным накладным. Рис.9. Конструктор отчета
Рис.10. Анализ выполнения плана сдачи изделий на склад № 1 Рис.11. Анализ выполнения плана сдачи изделий на склад № 2
Рис.12. Анализ выполнения плана сдачи изделий на склад № 3
Список литературы
Тарасов В.Л. Работа с базами данных в среде Access , Учебное пособие/ НижГУ, Нижний Новгород, 2005. Шехтман В.Е. Базы данных, SQL Учебно-методическое пособие по дисциплинам "Базы данных", "Базы данных и экспертные системы", "Современная технология программирования SQL". / - НФИ КемГУ, Новокузнецк, 2006. Андреев В.А., Тупикина Е.Н., Системы управления базами данных(Microsoft Access), методические указания/ ДВГАЭУ, Владивосток, 2003. Вейскас Д. , Эффективная работа с ACCESS, учебное пособие/ СПб, 1996. Хомоненко А.Ф., Цыганков В.М., Мальцев М.Г. Базы данных, Учебник для ВУЗов/ Под ред. проф. А.Д.Хомоненко.- СПб.: КОРОНА принт, 2002.
30.04.2009 Алексей Ковязин
Реляционные базы данных проникли практически во все информационные системы, и, казалось бы, стали наиболее устоявшейся областью ИТ, где уже мало что можно изобрести, однако реальное положение дел далеко от идеального.
Реляционные базы данных применяются сегодня практически во всех приложениях, начиная от встроенных в мобильные и специальные устройства, Web-приложений и заканчивая системами управления предприятия. Проникновение баз данных во все виды приложений идет нарастающими темпами, а разработчики получают все более удобные в использовании инструменты и подходы. Может сложиться впечатление, что разработчики приложений для работы с базами данных являются наиболее «обеспеченной» прослойкой программистов, у которых есть инструменты на все случаи жизни, но это далеко не так. Компания Embarcadero Technologies, приобретя в 2008 году подразделение средств разработки CodeGear у компании Borland, объединила профессиональные средства разработки приложений и инструменты проектирования, средства разработки и управления базами данных, что позволило устранить имеющиеся проблемы как со стороны приложений, так и со стороны баз данных.
Хаотическое проектирование баз данных
В современной индустрии разработки программного обеспечения устоялось мнение, что определить требования к продукту перед началом проекта невозможно, и поэтому разработка должна быть адаптирована к их постоянному изменению. В результате появились процессы, основанные на итерациях, учитывающих изменение требований, а рефакторинг исходного кода стал неотъемлемой частью создания ПО. А что происходит в процессе итерационной разработки с базами данных? Изменение требований вынуждает корректировать схему базы данных, причем чаще всего это происходит непрозрачно, без анализа общей картины и зависимостей. Таблицы, поля, внешние ключи и ограничения создаются и изменяются хаотически, за ссылочной целостностью никто не следит, и никто не может точно сказать, чем же база данных на итерации N отличается от ее состояния на итерации N-1.
Фактически разработка баз данных сегодня ведется «заплаточным» методом, как во времена господства «водопадного» процесса, – в начале проекта «рисуется» некая модель базы, основанная на частичных требованиях, известных к данному моменту, затем генерируется физическая база данных, а дальше про модель забывают, производя изменения прямо в базе данных. Минусы такого подхода очевидны: обмен знаниями и понимание общей картины затруднены, а изменения непрозрачны, могут порождать противоречия в логике и схеме базы данных, которые останутся нераскрытыми до момента ввода программной системы в эксплуатацию, что приводит к очень большим убыткам. Современные разработчики приложений баз данных нуждаются в инструментах, приспособленных к итерационной разработке баз данных.
Первым и наиболее важным условием такой приспособленности является наличие полноценных возможностей обратного инжиниринга (reverse engineering, создание модели базы данных на основе анализа ее физической схемы) и прямого инжиниринга (forward engineering; создание и изменение физической схемы базы данных на основе модели). На практике это означает, что с помощью инструмента проектирования можно провести анализ схемы существующей базы данных, создать на ее основе модель базы, поменять модель и немедленно применить изменения, которые должны действительно корректно и непротиворечиво изменить схему базы данных, а не испортить или запутать ее.
Итерационный подход также подталкивает нас к необходимости создания подмоделей, связанных с конкретной итерацией. Выделение любых сущностей и их атрибутов в подмодель помогает разделить области ответственности как между разными разработчиками, так и между разными итерациями, гарантируя в то же время общую целостность модели. Естественно, нужна также возможность сравнения двух моделей, причем не в виде SQL-скриптов, а на уровне сущностей и атрибутов, чтобы видеть и полностью понимать вносимые при итерации изменения и их влияние на всю модель.
Разработчики приложений редко работают в одиночку, поэтому нуждаются в средствах совместной работы, но если на стороне разработки приложений с этим все в порядке, то совместная работа над базой данных обычно никак не поддерживается на уровне инструментальных средств. Совместная работа обязательно предполагает систему контроля версий: все версии моделей и физической схемы базы данных должны сохраняться в едином репозитории, обеспечивая возможности отката и сравнения схем с самого начала процесса разработки.
Разработка баз данных - дело не менее важное, чем разработка приложений, поэтому стратегическим направлением развития является обеспечение процесса разработки баз данных средствами контроля версий и управления требованиями, а также явная привязка этапов моделирования и модифицирования баз данных к итерациям и меняющимся требованиям программного проекта. Для решения перечисленных проблем и поддержки современного итерационного процесса разработки баз данных компания Embarcadero предлагает ER/Studio – инструмент проектирования, анализа, обратного и прямого инжиниринга, позволяющий осуществлять контроль версий моделей на базе собственного репозитория. В качестве средства контроля за изменениями метаданных в физических базах данных может использоваться инструмент Change Manager.
Разобщенность кода
Самой известной проблемой, сильно замедляющей процесс разработки приложений баз данных, является необходимость использовать разные средства для отладки кода приложения и SQL-кода в базе данных.
Рассмотрим простой пример. Предположим, что на Delphi разрабатывается приложение, которое вызывает хранимую процедуру в СУБД Oracle. Используя средства Delphi, разработчик приложения может в режиме отладки пошагово пройти до момента вызова SQL-запроса, увидеть передаваемые хранимой процедуре параметры и результат, который вернет процедура. Но что происходит внутри процедуры, когда она выполняется на сервере баз данных? Из среды разработки нашего приложения это невозможно определить – для этого надо загружать приложение для разработки SQL, которое имеет возможности для отладки хранимых процедур, а также показывает планы SQL-запросов, статистику их выполнения, позволяет просмотреть и изменить схему базы данных. Однако нельзя передать параметры из среды разработки приложения в среду разработки SQL, и приходится копировать их вручную, переключаясь из одного окна в другое. В средстве разработки приложений также невозможно увидеть детализированные результаты выполнения SQL-кода, такие как план запроса, статистика выполнения и т.д. Появление технологии кросс-языковой отладки позволило решить эти проблемы.
Первым продуктом Embarcadero, поддерживающим кросс-языковую отладку, является RapidSQL Developer (бывший PowerSQL), визуальная часть которого основана на технологии Eclipse и поэтому позволяет встраиваться в любую среду разработки на его базе (в том числе, конечно же, JBuilder) и осуществлять динамическую кросс-языковую отладку. Теперь в момент выполнения хранимой процедуры на сервере разработчик в рамках одного и того же инструмента автоматически переходит в полноценную среду отладки SQL-кода, способную отлаживать как обычные SQL-запросы, так и хранимые процедуры. Разработчик видит актуальные входные параметры запросов и хранимых процедур, получая возможность пошаговой отладки SQL-кода. Интеграция RapidSQL Developer в Eclipse-совместимые средства разработки – первый шаг интеграции разработки приложений и баз данных, на очереди обеспечение аналогичных возможностей для Delphi, C++ Builder и других средств разработки приложений от Embarcadero.
Мультиплатформные приложения баз данных
Особую проблему для разработчиков представляет разработка приложений баз данных, которые должны работать с несколькими СУБД. Например, банки и страховые компании обычно имеют несколько больших офисов и множество маленьких филиалов. Большинство бизнес-процессов, касающихся ввода оперативной информации и повседневного документооборота, совпадают и в головном офисе, и в филиалах, однако масштабы разные. Естественное желание сэкономить на стоимости лицензий промышленной СУБД для применения в филиалах приводит к мысли о том, что хорошо бы выбрать другую СУБД без смены приложения.
Опытные разработчики баз данных хорошо понимают суть возникающих здесь проблем: различие типов данных и диалектов SQL, отсутствие механизмов миграции и репликации между разными СУБД, сложность верификации миграции превращают написание и эксплуатацию приложений для разных СУБД в кошмар. Со стороны средств разработки приложений эту проблему пытаются решить за счет создания библиотек доступа к данным (dbExpress в Delphi и C++ Builder, ADO и ADO.Net от Microsoft), построенным на единых архитектурных принципах и методах доступа, а также путем применения многочисленных объектно-реляционных «оберток» (Object Relation Mapping, ORM) над реляционной логикой и структурой базы данных, генерирующих исходный код для работы с данными на основе анализа схемы базы данных и использующих механизм «адаптеров» для реализации протокола конкретной СУБД. Среди наиболее популярных ORM надо отметить Hibernate для Java и ActiveRecord в RubyOnRails, которые предоставляют объектно-ориентированный интерфейс к хранящимся в СУБД данным. Для Delphi существует аналогичный проект tiOPF, для C# – NHibernate.
Конечно, использование таких универсальных библиотек и наборов компонентов позволяет значительно сократить число рутинных операций в процессе мультиплатформной разработки баз данных. Однако этого недостаточно, когда речь идет о приложениях, использующих более сложные базы данных, в которых активно употребляется логика, заложенная в хранимых процедурах и триггерах, – для ее реализации, отладки и тестирования требуются отдельные инструменты, подчас совершенно разные для разных СУБД. Для разработки кроссплатформных приложений баз данных Embarcadero предлагает инструмент RapidSQL.
Все продукты Embarcadero для работы с базами данных поддерживают несколько платформ и основаны на ядре анализа схемы и статистики баз данных Thunderbolt. Каждая поддерживаемая СУБД и каждая конкретная версия СУБД имеют соответствующие ветки кода в ядре Thunderbolt, что позволяет максимально точно отображать схему базы данных на внутреннее представление в этом ядре и, самое главное, осуществлять корректные преобразования между представлением и реальными базами данных. Именно благодаря ядру Thunderbolt система RapidSQL позволяет разрабатывать качественный SQL-код для всех поддерживаемых платформ (Oracle, MS SQL, Sybase и различные варианты IBM DB2), а ER/Studio может осуществлять точный reverse- и forward-инжиниринг схем баз данных.
Если разрабатывается приложение для двух и более платформ или переносится существующее приложение с одной платформы на другую, то RapidSQL предоставит все необходимые инструменты для миграции схемы, пользователей и разрешений между разными СУБД. Конечно, RapidSQL автоматически не конвертирует процедуры на PL/SQL в T-SQL – для этого все еще требуется программист, однако инструмент обеспечивает единое окно для мультиплатформной разработки, унифицированные редакторы объектов схемы, пользователей и их прав, а также отладку SQL на всех поддерживаемых платформах. По утверждениям пользователей RapidSQL, в результате экономится до 70% времени, которое тратится на миграцию между разными СУБД.
Изменения в данных и схемах
Миграция с одной СУБД на другую невозможна без ее верификации. Кто и каким образом может гарантировать, что данные, перенесенные из одной СУБД в другую, действительно идентичны? Разные клиентские библиотеки, разные типы данных и разные кодировки превращают процесс сравнения данных в нетривиальную задачу.
В реальном мире на развертывании приложения и базы данных работа не заканчивается - идет сопровождение, появляются новые версии исполняемых файлов приложения и патчи к базе данных. Каким образом можно получить гарантии, что все необходимые обновления были применены к базе данных и что весь комплекс ПО заработает правильно?
Embarcadero разработала инструмент Change Manager, предназначенный для сравнения данных, схем и конфигураций баз данных. Сравнение происходит в рамках одной или нескольких СУБД, с автоматической проверкой соответствия между типами данных и формированием SQL-скриптов отличий, которые можно тут же применить для приведения баз в идентичное состояние. Модуль сравнения метаданных обеспечивает сравнение схем баз данных как между «живыми» базами данных, так и между базой данных и SQL-скриптом и генерирует скрипт отличий метаданных. Эта функциональность может быть использована не только для проверки баз данных на соответствие эталону, но и для организации регулярного процесса обновления баз данных, а также для проверки на неавторизованные изменения, скажем, в удаленных филиалах крупной организации. Аналогичная ситуация с конфигурационными файлами – Change Manager сравнивает конфигурационные файлы и позволяет обеспечить соответствие конфигурации развернутых приложений требованиям для данного ПО.
Производительность приложений баз данных
Как часто мы видим приложения, прекрасно работающие на небольших тестовых объемах данных, но на реальных объемах становящиеся неприемлемо медленными. Просчеты в требованиях, недостаточное тестирование на ранних стадиях, спешка в сдаче проекта - все это знакомые причины некачественной разработки приложений. Теоретики разработки ПО в этом случае предлагают заняться самоусовершенствованием и принципиальным улучшением качества программ, однако все практики знают, что заниматься переписыванием проекта иногда невозможно ни экономически, ни, в некоторых случаях, политически, а задачу оптимизации производительности надо решать любым способом.
Основная причина проблем с производительностью приложений баз данных лежит в неоптимизированных SQL-запросах и хранимых процедурах. Оптимизаторы современных баз данных достаточно мощные, однако и у них есть определенные границы возможностей, и, чтобы добиться хорошей производительности, нужно правильно составлять SQL-запросы, создавать (или удалять) дополнительные индексы, в определенных случаях денормализовывать базу данных, перекладывать часть логики на триггеры и хранимые процедуры.
На этапе разработки оптимизацию запросов можно проводить с помощью RapidSQL, который включает в себя модуль SQL Profiler, способный анализировать планы и генерировать подсказки по улучшению производительности SQL-запросов. Но что делать, если проблема возникает уже в процессе эксплуатации и не локализуется в определенном SQL-запросе? Если производительность падает в определенное время суток или, что еще неприятнее, проблема возникает на удаленной копии системы, в то время как на основном сервере все в порядке? Для таких случаев предназначен DBOptimizer – инструмент профилирования баз данных для Oracle, Microsoft SQL Server, Sybase и IBM DB2.
При запуске режима профилирования DBOptimizer собирает информацию о базе данных и среде выполнения, включая информацию о загрузке центрального процессора и другие параметры операционной системы, записывая ее в сессию профилирования. В результате получается список выполняющихся в любой заданный промежуток времени запросов, отсортированный по потребляемым ресурсам. Для каждого проблемного запроса можно увидеть его план, статистику выполнения и другие подробности. Более того, DBOptimizer также показывает подсказки-рекомендации по улучшению запроса применительно к конкретным СУБД.
Ящик с инструментами
Все упомянутые инструменты, хотя они и позволяют справиться с проблемами, используются на разных этапах жизненного цикла разработки баз данных. Довольно неудобно и накладно держать десяток приложений на все случаи жизни, которые могут понадобиться (а могут и не понадобиться) в процессе проектирования, разработки, миграции, оптимизации и эксплуатации баз данных.
Выпущенный в феврале 2009 года универсальный набор инструментов Emdacadero All-Access включает в себя необходимые инструменты для всех этапов разработки приложений баз данных: от ER/Studio до DBOptimizer, от Delphi и C++ Builder до DBArtisan. Лучше всего для описания All-Access подходит сравнение с ящиком для инструментов, который стоит дома у каждого рачительного хозяина. Возможно, не всеми инструментами пользуются каждый день, но разводной ключ на случай протечки должен быть всегда под рукой.
All-Access не навязывает программистам или архитекторам базы данных чужие роли, но предоставляет универсальный комплект инструментов, подходящий для всех ролей в процессе разработки приложений баз данных, от архитектора до тестировщика; предлагает всем членам команды разработчиков инструменты для всех этапов разработки баз данных, а также набор узкоспециализированных инструментов для оптимизации баз данных (DBOptimizer) и приложений (JOptimizer), позволяющих «расшить» узкие места. Пакет поддерживает несколько СУБД, что обеспечивает экономию средств.
Технические различия между технологиями объектно-ориентированных и реляционных баз данных привели к различию культур, до сих пор разделяющему сообщество управления данными и сообщество разработки. Что с этим делать дальше?
Создание приложений для работы с базами данных.
Базы данных используют, когда надо работать с большими объемами данных.
Реляционная база данных это набор таблиц, процедур и др. объектов, поддерживающих ее работу. Таблица имеет имя – идентификатор, по которому на нее можно сослаться. Пример таблицы данных о сотрудниках Pers :
|
Номер |
Отдел |
Фамилия |
Имя |
Отчество |
Год рождения |
Пол |
Характеристика |
Фотография |
|
Num |
Dep |
Fam |
Nam |
Par |
Year_b |
Sex |
Charact |
Photo |
|
Бухгалтерия |
Иванов |
Иван |
Иванович |
1950 |
||||
|
Цех 1 |
Петров |
Петр |
Петрович |
1960 |
||||
|
Цех 2 |
Сидоров |
Сидор |
Сидорович |
1955 |
||||
|
Цех 1 |
Иванова |
Ирина |
Ивановна |
1961 |
||||
Столбцы таблицы соответствуют характеристикам объектов – полям. Каждое поле характеризуется именем и типом хранящихся данных. Имя поля – это идентификатор, который используется в различных программах для манипуляции данными. Как и любой идентификатор, имя поля может состоять только из латинских букв, только из одного слова и т. д. (строка 2 в таблице).
Тип поля характеризует тип хранящихся в поле данных. Это могут быть строки, числа,булевы значения, большие тексты (например, характеристики сотрудников), изображения (фотографии сотрудников) и т.п.
Каждая строка таблицы соответствует одному из объектов. Она называется записью и содержит значения всех полей, характеризующих данный объект.
При построении таблиц баз данных важно обеспечить непротиворечивость информации. Обычно это делается введением ключевых полей – обеспечивающих уникальность каждой записи. Ключевым может быть одно или несколько полей. В приведенном примере можно было бы сделать ключевыми совокупность полей Fam, Nam, Par . Но в этом случае нельзя было бы заносить в таблицу сведения о полных однофамильцах, у которых совпадают фамилия, имя и отчество. Поэтому в таблицу введено первое поле Num – номер, которое можно сделать ключевым, обеспечивающим уникальность каждой записи.
При работе с таблицей пользователь или программа как бы скользит курсором по записям. В каждый момент времени есть некоторая текущая запись, с которой и ведется работа. Записи в таблицах данных могут располагаться без какого-либо порядка, просто в последовательности их ввода (появления новых сотрудников). Но когда таблицы предъявляются пользователю, они должны быть упорядочены. Пользователь может хотеть просматривать их в алфавитном порядке, или рассортированными по отделам, или по возрасту и т.п.
Для упорядочивания данных используется понятие индекса . Индекс показывает, в какой последовательности желательно просматривать таблицу. Он является как бы посредником между пользователем и таблицей:
Индексы могут быть первичными
и вторичными
.
Например, первичным индексом могут служить поля, отмеченные при создании базы
данных как ключевые. А вторичные индексы могут создаваться из других полей как
в процессе создания самой базы данных, так и позднее в процессе работы с ней.
Вторичным индексам присваиваются имена – идентификаторы, по которым их можно
использовать.
База данных обычно содержит не одну, а множество таблиц. Например, база данных
о некоторой организации может содержать таблицу имеющихся в ней подразделений
с характеристикой каждого из них.
Таблица Depс полями Dep
и Proisv
В связанных таблицах обычно одна выступает как главная , а другая или несколько других - как вспомогательные, управляемые главной. Главная и вспомогательные таблицы связываются друг с другом ключом . В качестве ключа могут выступать какие-то поля, присутствующие в обеих таблицах.
В примере головной может быть таблица Dep , вспомогательной Pers , а связываться они могут по полю Dep , присутствующему в обеих таблицах.
Каждой записи в главной таблице Dep соответствуют те записи вспомогательной таблицы Pers , в которых ключевое поле Dep с названием отдела совпадает с названием отдела в текущей записи главной таблицы. Иначе говоря, если в текущей записи главной таблицы в поле Dep написано «Бухгалтерия», то во вспомогательной таблице Pers выделяются все записи сотрудников бухгалтерии.
Создают базы данных и обрабатывают запросы к ним системы управления базами данных – СУБД: Paradox, Microsoft Access, FoxPro, Oracle, InterBase и т.д.
Разные СУБД по разному организуют и хранят базы данных. Paradox использует для каждой таблицы один файл. В Microsoft Access и InterBase несколько таблиц хранятся как один файл. В этом случае база данных – это имя файла с путем доступа к нему. Системы типа клиент/сервер (Sybase, Microsoft SQl, Oracle) хранят все данные на отдельном компьютере и общаются с клиентом посредством специального языка – SQL .
Для упорядочения обращения к базам данных используют псевдонимы баз данных. Псевдоним (alias) содержит всю информацию, необходимую для обеспечения доступа к базе данных. Эта информация сообщается только один раз при создании псевдонима. А приложение для связи с базой данных использует псевдоним. В этом случае приложению безразлично, где физически расположена база данных, а часто безразлична и СУБД, создавшая и обслуживающая эту базу данных. При смене системы каталогов, сервера и т.п. ничего в приложении переделывать не надо. Достаточно, чтобы администратор базы данных ввел соответствующую информацию в псевдоним.
Кеширование всех изменений означает, что все изменения данных, вставка новых записей, удаление существующих записей, проводимые пользователем, сначала делаются не в самой базе данных, а запоминаются в памяти во временной виртуальной таблице. И только по особой команде после всех проверок правильности вносимыхв таблицу данных пользователю предоставляется возможность или зафиксировать все эти изменения в базе данных, или отказаться от этого и вернуться к тому состоянию, которое было до начала редактирования.
Фиксация изменений в базе данных производится с помощью транзакций . Это совокупность команд, изменяющих базу данных. Пользователю предоставляется возможность завершить транзакцию или внесением всех изменений в реальную базу данных, или откатом от этого с возвратом к тому состоянию, которое было до начала транзакции.
Средства Delphi , предназначенные для разработки и эксплуатации приложений, использующих базы данных :
BDE (Borland Database Engine ) – машина баз данных Borland . Представляет собой набор DLL -библиотек, обеспечивающих низкоуровневый доступ к локальным и клиент-серверным БД. Должна устанавливаться на каждом компьютере, который использует приложения для работы с БД, написанные для Delphi .
SQL Links – драйверы для работы с удаленными серверами данных (MS SQL Server, Oracle)
BDE Administrator – утилита для установки псевдонимов (имен) баз данных, параметров БД и драйверов баз данных на конкретном компьютере. При работе с БД из приложения, созданного с помощью Delphi , доступ к базе данных производится по ее псевдониму. Параметры определяемой псевдонимом БД, действуют только для этой БД; параметры, установленные для драйвера БД, действуют для всех баз данных, использующих драйвер. Кроме того, можно произвести установку таких общих для всех БД параметров, как формат даты и времени, форматы представления числовых значений, используемый языковый драйвер и т.д.
Database Desktop (DBD ) – средство для создания, изменения и просмотра БД. Эта утилита прежде всего ориентирована на работу с таблицами локальных СУБД, например Paradox . Можно с некоторыми ограничениями создавать и просматривать таблицы баз данных, работающих под управлением серверов: InterBase, MS SQL Server, Oracle .
DBD позволяет программисту возможность сформировать запрос к БД методом QBE (Query By Example – запрос по образцу).
SQL Explorer – универсальная утилита, совмещающая многие функции BDE Administrator и DBD . С ее помощью можно создавать и просматривать псевдонимы БД, просматривать структуры и содержимое таблиц БД, формировать запросы к БД на языке SQL , создавать словари данных (шаблоны полей таблиц).
SQL Monitor – средство для трассировки выполнения SQL- запросов.
Невизуальные компоненты для работы с БД – служат для соединения приложения с таблицами БД в локальных и распределенных системах. Они расположены на странице Data Access палитры компонентов. С помощью невизуальных компонентов осуществляется подключение к базам данных, формирование запросов к ним, манипулирование таблицами.
Визуальные компоненты для работы с БД – предназначены для визуализации записей наборов данных или их отдельных полей. Эти компоненты расположены на странице Data Controls палитры компонентов. Они служат основным инструментом разработки пользовательского интерфейса доступа к данным.
Особенности программ для работы с БД.
Характерной особенностью созданных с помощью Delphi программ для работы с БД является непременное использование в них BDE (процессор реляционной базы данных Borland Database Engine , включенный в состав Delphi ) , которая осуществляет роль связующего моста между программой и БД.
 |
BDE берет на себя всю низкоуровневую работы по обеспечению клиентской программы нужными ей данными, поэтому в общем случае взаимодействие программы с данными происходит следующим образом:
BDE не является частью программы. В зависимости от типа СУБД она может размещаться на машине клиента или сервера.
Обычно между программой и BDE располагается слой компонентов, существенно упрощающих разработку программ. Невизуальные компоненты осуществляют непосредственную работу с BDE , и три из них (TTable, TQuery, TStoredProc) служат наборами данных, в то время как визуальные компоненты отображают поставляемые им данные и служат для создания удобного интерфейса пользователя. Между наборами данных и визуальными компонентами обязательно располагаются компоненты TDataSource , играющие роль клапанов, открывающих или закрывающих потоки данных, которыми обмениваются источники с визуальными компонентами (см рис.).
Некоторые поддерживаемые в Delphi типы БД.
Локальные и файл серверные БД.
В локальных БД базы данные располагаются на машине клиента. В файл серверных БД базы данные располагаются на сетевом файл-сервере.
Локальный вариант может обеспечить лишь однопользователький режим доступа к данным.
В файл-серверных БД данные располагаются на сетевом файл-сервере, который может быть доступен одновременно нескольким пользователям. Данные в БД хранятся в единственном экземпляре, а каждый клиент в каждый момент времени работает с некоторой локальной копией данных, причем управление данными целиком возлагается на клиентские программы. Именно они должны заботиться о синхронизации локальных копий данных на каждом клиентском месте с содержимым основной (и единственной) базы даных.
При выполнении запроса к БД, расположенной на файловом сервере, в действительности происходит запрос к локальной копии данных на компьютере пользователя. Поэтому перед выполнением запроса данные в локальной копии в полном объеме обновляются из реальной БД. Так, если таблица БД состоит из 10000 записей, а для выполнения запроса нужно только 10 записей, все равно клиенту передаются все 10000 записей. Таким образом серьезно загружается сеть.
Клиент-серверные БД.
В архитектуре клиент-сервер между BDE и базой данных появляется важное промежуточное звено – сервер БД (специальная программа, управляещая базой данных).
Клиент формирует запрос к серверу на языке запросов SQL (Structured Query Language – структурированный язык запросов), являющемсяпромышленным стандартом для реляционных баз данных. SQL -сервер обеспечивает интерпретацию запроса, его выполнение, формирование результата и выдачу этого результата клиенту. При этом ресурсы клиентского компьютера не участвуют в физическом выполнении запроса: клиентский компьютер лишь отсылает запрос к серверной БД и получает результат, после чего интерпретирует его необходимым образом и представляет пользователю. По сети передаытся только те данные, которые нужны клиенту.
При выполнении запросов сервером существенно повышается степень безопасности данных, поскольку правила целостности данных определяются на сервере и являются едиными для всех приложений, использующих эту БД. Мощный аппарат транзакций, поддерживаемый SQL- серверами, блокирует одновременное изменение одних и тех же данных различными пользователями и предоставляет возможность откатов к первоначальным значениям при внесении в БД изменений, закончившихся аварийно.
Создание и просмотр псевдонимов баз данных.
- С помощью DBD.
Обчно вызов Database Desktop включен в главное меню Delphi в раздел Tools . Если это не сделано можно включить его туда командой Tools|Configure Tools… (файл DBD32.exe ).
DBD позволяет создавать таблицы баз данных некоторых СУБД, задавать и изменять их структуру.
В можно создавать и просматривать псевдонимы, выполнив команду Tools|Alias Manager . При этом появляется окно Alias Manager :
При выборе псевдонима в списке Database Alias
автоматически
изменяется тип драйвера в выпадающем списке
- С помощью BDE Administrator .
- С помощью Database Explorer (SQL Explorer).
Вызов этой программы производится из главного меню Delphi командой Database| Explore.
|
|
- Tutorial
- Recovery Mode
Всем привет! Меня зовут Олег и я программист-любитель под Android. Любитель потому что в данный момент я зарабатываю деньги программированием в совсем другом направлении. А это хобби, которому я посвящаю свое свободное время. К сожалению у меня нет знакомых программистов под Android и все свои базовые знания я черпаю либо из книг, либо из интернета. Во всех тех книжках и статьях в интернете, которые я читал, созданию базы данных для приложения отводится крайне мало места и по сути все описание сводится к созданию класса являющегося наследником SQLiteOpenHelper
и последующему внедрению SQL кода в Java код. Если не считать, что мы получаем плохо читаемый код (а если в нашем приложении появляется больше 10 таблиц, то вспоминать все эти взаимосвязи между таблицами тот еще ад), то в принципе жить можно конечно, но как-то совершенно не хочется.
Забыл сказать самое главное, можно сказать что это моя проба пера тут. И так поехали.
О вечном вопросе: почему?
Почему в книгах и в статьях, посвященных программированию под Android, не описываются инструменты для проектирования архитектуры базы данных и какие-нибудь паттерны для работы с базами данных на этапе их создания я честно говоря не знаю. Казалось бы добавить всего пару страниц в книгу или написать отдельную статью (как делаю это я сейчас) проще простого - но нет. В этой статье, я кратко пройдусь по инструментам, которые я использую в своей работе и более подробно по коду который отвечает за начальное создание БД, который с моей точки зрения выглядит более читаемым и удобным.
Если в нашем приложении больше 5 таблиц, то уже было бы не плохо использовать какой-нибудь инструмент для визуального проектирования архитектуры БД. Поскольку для меня это хобби, то и использую я абсолютно бесплатный инструмент под названием Oracle SQL Developer Data Modeler (скачать его можно ).
Данная программа позволяет визуально рисовать таблицы, и строить взаимосвязи с ними. Многие ошибки проектирования архитектуры БД можно избежать при таком подходе проектирования (это я уже вам говорю как профессиональный программист БД). Выглядит это примерно так:
Спроектировав саму архитектуру, приступаем к более нудной части, заключающийся в созданий sql кода для создания таблиц. Для помощи в этом вопросе, я уже использую инструмент под названием SQLiteStudio (его в свою очередь можно скачать тут ).
Данный инструмент является аналогом таких известных продуктов как SQL Naviagator, Toad etc. Но как следует из названия, заточен он под работу с SQLite. Он позволяет визуально создать БД и получить DDL код создаваемых таблиц. Кстати, он также позволяет создавать представления (View), которые вы тоже при желании можете использовать в своем приложении. Не знаю насколько правильный подход использования представлений в программах для Android, но в одном из своих приложений я использовал их.
Собственно говоря я больше не каких сторонних инструментов не использую, и дальше начинается магия с Android Studio. Как я уже писал выше, если начать внедрять SQL код в Java код, то на выходе мы получим плохочитаемый, а значит и плохо расширяемый код. Поэтому я выношу все SQL инструкции во внешние файлы, которые у меня находятся в директории assets . В Android Studio выглядит это примерно так:
О директориях db и data
Внутри директории assets
я создал две директории db_01
и data_01
. Цифры в названиях директорий соответствуют номеру версии моей БД с которой я работаю. В директории db
у меня хранятся сами SQL скрипты создания таблиц. А в директории data
хранятся данные необходимые для начального заполнения таблиц.
Теперь давайте посмотрим на код внутри моего DBHelper который я использую в своих проектах. Сначала переменные класса и конструктор (тут без каких либо неожиданностей):
Private static final String TAG = "RoadMap4.DBHelper";
String mDb = "db_";
String mData = "data_";
Context mContext;
int mVersion;
public DBHelper(Context context, String name, int version) {
super(context, name, null, version);
mContext = context;
mVersion = version;
}
Теперь метод onCreate
и тут становится уже интереснее:
@Override
public void onCreate(SQLiteDatabase db) {
ArrayList
Логически он разделен на два цикла, в первом цикле я получаю список SQL - инструкций для создания БД и затем выполняю их, во втором цикле я уже заполняю созданные ранее таблицы начальными данными. И так, шаг первый:
Private ArrayList
Тут все достаточно просто, мы просто читаем содержимое файлов, и конкатенируем содержимое каждого файла в элемент массива. Обратите внимание, что я произвожу сортировку списка файлов, так как таблицы могут иметь внешние ключи, а значит таблицы должны создаваться в определенном порядке. Я использую нумерацию в название файлов, и с помощью нею и произвожу сортировку.
Private class QueryFilesComparator implements Comparator
С заполнением таблиц все веселей. Таблицы у меня заполняются не только жестко заданными значениями, но также значениями из ресурсов и UUID ключами (я надеюсь когда-нибудь прийти к сетевой версии своей программы, что бы мои пользователи могли работать с общими данными). Сама структура файлов с начальными данными выглядит так:
Несмотря на то, что файлы у меня имеют расширение sql, внутри не sql код а вот такая штука:
Prioritys
pri_id:UUID:UUID
pri_name:string:normal
pri_color:color:colorGreen
pri_default:int:1
prioritys
pri_id:UUID:UUID
pri_object:string:object_task
pri_name:string:hold
pri_color:color:colorBlue
pri_default:int:0
prioritys
pri_id:UUID:UUID
pri_object:string:object_task
pri_name:string:important
pri_color:color:colorRed
pri_default:int:0
prioritys
pri_id:UUID:UUID
pri_name:string:normal
pri_color:color:colorGreen
pri_default:int:1
prioritys
pri_id:UUID:UUID
pri_object:string:object_project
pri_name:string:hold
pri_color:color:colorBlue
pri_default:int:0
prioritys
pri_id:UUID:UUID
pri_object:string:object_project
pri_name:string:important
pri_color:color:colorRed
pri_default:int:0
Структура файла такая: я выполняю вызов функции split(":") применительно к строчке и если получаю что ее размер равен 1 то значит это название таблицы, куда надо записать данные. Иначе это сами данные. Первое поле это название поля в таблице. Второе поле тип, по которому я определяю что мне надо в это самое поле записать. Если это UUID - это значит мне надо сгенерировать уникальное значение UUID. Если string значит мне надо из ресурсов вытащить строковое значение. Если color, то опять-таки, из ресурсов надо вытащить код цвета. Если int или text, то я просто преобразую данное значение в int или String без каких либо телодвижений. Сам код выглядит вот так:
Private ArrayList
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru/
Введение
3. Модели организации данных
4. Реляционные базы данных
6. Инфологическая модель
7. Логическая модель
8. Структура таблиц
12. Создание таблиц
16. Создание отчетов
17. Листинг программы
Заключение
Список литературы
Введение
Для принятия обоснованных и эффективных решений в производственной деятельности, в управлении экономикой и в политике современный специалист должен уметь с помощью компьютеров и средств связи получать, накапливать, хранить и обрабатывать данные, представляя результат в виде наглядных документов. Поэтому, так важно уметь работать с базами данных.
База данных - это организованная структура, предназначенная для хранения информации. В современных базах данных хранятся не только данные, но и информация.
О Delphi говорят как о среде быстрого создания приложений. Это технология визуального программирования, т.е. пользователь оформляет свою будущую программу, и видит результаты своей работы еще до запуска самой программы. В принципе, сам процесс написания приложения разделяется на две части. Первый - программист располагает на окна своей программы необходимые элементы, позиционирует, устанавливает нужные размеры, меняет свойства. Второй - собственно, написание программного кода, описание свойств элементов, доступных только во время работы приложения, описание реакций на событие появление окна, нажатия на кнопку и др. Для задания каких-либо свойств элементу разрабатываемого приложения вовсе не обязательно писать массивные текстовые строки, достаточно изменить это свойство в инспекторе объектов (так называемом мониторе свойств выбранного элемента). Это изменение автоматически дополнит или модифицирует программный код.
Это большой плюс в визуальной технологии программирования. Создавая или модифицируя свой программный продукт, пользователь не зная или не обращая внимания на некоторые свойства элемента программы, а используя только необходимые, пишет полностью готовый рабочий продукт, порой выступающий на равных по сложности, с написанными на невизуальном редакторе.
Перед нами стоит задача составить базу данных, которая содержала бы данные об учебном плане учебного процесса. Заполнив базу данных, нужно провести выборочный анализ с помощью Sql-запросов.
база инфологический таблица программа
1. Общие требования к разработке приложений БД
База данных должна содержать
a. Таблицы, для хранения данных, не менее 3-х таблиц. Каждая таблица должна содержать не менее 10 записей.
b. Формы для удобного просмотра, ввода, редактирования и поиска данных, формирования и отображения запросов. На форме должны присутствовать пояснения, подсказки. При заполнении полей формы, для известных наборов значений использовать возможность выбора значений из списка. Формы должны быть по возможности связанными, для оптимизации навигации по записям. На форме по возможности должно располагаться максимум информации для пользователя. Предусмотреть обработку возникающих семантических ошибок.
c. Отчеты, содержащие все таблицы, формы, запросы
d. Меню для доступа к различным объектам базы данных
e. Справку, содержащую полное описание задания
2. Для программирования базы данных необходимо использовать дополнительную литературу по языку SQL, системе программирования DELPHI.
3. Перечень и способы самостоятельно решаемых задач
1. Анализ постановки задачи и предметной области.
2. Инфологическое проектирование, обоснование информационных объектов, доменов, атрибутов, связей, составление инфологической модели.
3. Логическое проектирование, построение и обоснование базовых отношений, нормализация.
4. Проектирование Sql-запросов.
5. Программирование структуры и общих функций в базе данных.
6. Проектирование БД в программной среде.
7. Разработка интерфейса программы.
8. Оформление пояснительной записки.
4. Критерии оценки полученных компетенций по курсовой работе
Критерии заполняются преподавателем при защите работы, приведенные в таблице 1. На основе средней оценки выставляется оценка за курсовую работу.
Таблица 1. Оценка компетенций
|
Название компетенций |
Объект оценивания |
||
|
Понимать требования и следовать им |
Полученные результаты(БД) (объем, структура, соответствие заданию) |
||
|
Письменная коммуникация |
Качество изложения в пояснительной записке, понятность, объем структура, соответствие заданию. |
||
|
Знать и применять элементы системы программирования DELPHI |
Компоненты приложения БД, ответы на вопросы о реализации БД |
||
|
Знать и применять элементы технологии БД |
Ответы на вопросы, связанные с проектированием, возможно в формате теста |
||
|
Понимать потребности в применении технологии БД |
Введение пояснительной записки |
||
|
Планирование работы, организация работы |
Сроки выполнения работ |
||
|
Самостоятельно решать задачи |
Перечень и способы самостоятельно решаемых задач |
||
|
Устная коммуникация |
Публичная защита БД |
||
|
Способность к анализу, синтезу |
Инфологическая, логическая модель БД |
||
|
Стремление к качеству результата |
Качество выполненных работ, эргономические показатели, качество функционирования. |
||
|
Способность порождать новые идеи |
Качество интерфейса, дополнительные функции БД, не учтенные в задании. |
||
|
Способность к управлению(поиску) информацией |
Количество информационных ресурсов, найденных и используемых в курсовой работе, количество консультантов. |
2. Основные понятия и классификация систем управления базами данных
База данных (БД)представляет собой совокупность структурированных данных, хранимых в памяти вычислительной системы и отображающих состояние объектов и их взаимосвязей в рассматриваемой предметной области.
Логическую структуру данных, хранимых в базе, называют моделью представления данных. К основным моделям представления данных (моделям данных) относятся иерархическая, сетевая, реляционная.
Система управления базами данных (СУБД) -- это комплекс языковых и программных средств, предназначенный для создания, ведения и совместного использования БД многими пользователями. Обычно СУБД различают по используемой модели данных. Так, СУБД, основанные на использовании реляционной модели данных, называют реляционными СУБД.
Для работы с базой данных зачастую достаточно средств СУБД. Однако если требуется обеспечить удобство работы с БД неквалифицированным пользователям или интерфейс СУБД не устраивает пользователей, то могут быть разработаны приложения. Их создание требует программирования. Приложение представляет собой программу или комплекс программ, обеспечивающих автоматизацию решения какой-либо прикладной задачи. Приложения могут создаваться в среде или вне среды СУБД -- с помощью системы программирования, использующей средства доступа к БД, к примеру, DelphiилиС++ Вuildег. Приложения, разработанные в среде СУБД, часто называют приложениями СУБД, а приложения, разработанные вне СУБД, -- внешними приложениями.
Словарь данных представляет собой подсистему БД, предназначенную для централизованного хранения информации о структурах данных, взаимосвязях файлов БД друг с другом, типах данных и форматах их представления, принадлежности данных пользователям, кодах защиты и разграничения доступа и т. п.
Информационные системы, основанные на использовании БД, обычно функционируют в архитектуре клиент-сервер. В этом случае БД размещается на компьютере-сервере, и к ней осуществляется совместный доступ.
Сервером определенного ресурса в компьютерной сети называется компьютер (программа), управляющий этим ресурсом, клиентом --компьютер (программа), использующий этот ресурс. В качестве ресурса компьютерной сети могут выступать, к примеру, базы данных, файлы, службы печати, почтовые службы.
Достоинством организации информационной системы на архитектуре клиент-сервер является удачное сочетание централизованного хранения, обслуживания и коллективного доступа к общей корпоративной информации с индивидуальной работой пользователей.
Согласно основному принципу архитектуры клиент-сервер, данные обрабатываются только на сервере. Пользователь или приложение формируют запросы, которые поступают к серверу БД в виде инструкций языкаSQL. Сервер базы данных обеспечивает поиск и извлечение нужных данных, которые затем передаются на компьютер пользователя. Достоинством такого подхода в сравнении предыдущим является заметно меньший объем передаваемых данных.
Выделяют следующие виды СУБД:
* полнофункциональные СУБД;
*серверы БД;
* средства разработки программ работы с БД.
Полнофункциональные СУБД представляют собой традиционные СУБД. К ним относятся dBase IV, Microsoft Access, Microsoft FoxProи др.
Серверы БД предназначены для организации центров обработки данных в сетях ЭВМ. Серверы БД обеспечивают обработку запросов клиентских программ обычно с помощью операторовSQL. Примерами серверов БД являются: MicrosoftSQL Server, Inter Baseи др.
В роли клиентских программ в общем случае могут использоваться СУБД, электронные таблицы, текстовые процессоры, программы электронной почты и др.
Средства разработки программ работы с БД могут использоваться для создания следующих программ:
* клиентских программ;
* серверов БД и их отдельных компонентов;
* пользовательских приложений.
По характеру использования СУБД делят на многопользовательские (промышленные) и локальные (персональные).
Промышленные, СУБД представляют собой программную основу для разработки автоматизированных систем управления крупными экономическими объектами. Промышленные СУБД должны удовлетворять следующим требованиям:
* возможность организации совместной параллельной работы многих пользователей;
* масштабируемость;
* переносимость на различные аппаратные и программные платформы;
* устойчивость по отношению к сбоям различного рода, в том числе наличие многоуровневой системы резервирования хранимой информации;
* обеспечение безопасности хранимых данных и развитой структурированной системы доступа к ним.
Персональные СУБД -- это программное обеспечение, ориентированное на решение задач локального пользователя или небольшой группы пользователей и предназначенное для использования на персональном компьютере. Это объясняет и их второе название -- настольные. Определяющими характеристиками настольных систем являются:
* относительная простота эксплуатации, позволяющая создавать на их основе работоспособные пользовательские приложения;
* относительно ограниченные требования к аппаратным ресурсам.
По используемой модели данных СУБД разделяют на иерархические, сетевые, реляционные, объектно-ориентированные и др. Некоторые СУБД могут одновременно поддерживать несколько моделей данных.
Для работы с данными, хранящимися в базе, используются следующие типы языков:
*язык описания данных -- высокоуровневый непроцедурный язык
декларативного типа, предназначенный для описания логической
структуры данных
* язык манипулирования данными -- совокупность конструкций, обеспечивающих выполнение основных операций по работе с данными: ввод, модификацию и выборку данных по запросам.
Названные языки в различных СУБД могут иметь отличия. Наибольшее распространение получили два стандартизованных языка:QBE-- язык запросов по образцу иSQL --структурированный язык запросов.QBE в основном обладает свойствами языка манипулирования данными,SQLсочетает в себе свойства языков обоих типов.
СУБД реализует следующие основные функции низкого уровня:
* управление данными во внешней памяти;
* управление буферами оперативной памяти;
* управление транзакциями;
* ведение журнала изменений в БД;
* обеспечение целостности и безопасности БД.
Реализация функции управления данными во внешней памяти обеспечивает организацию управления ресурсами в файловой системе ОС.
Необходимость буферизации данных обусловлена тем, что объем оперативной памяти меньше объема внешней памяти. Буферы представляют собой области оперативной памяти, предназначенные для ускорения обмена между внешней и оперативной памятью. В буферах временно хранятся фрагменты БД, данные из которых предполагается использовать при обращении к СУБД или планируется записать в базу после обработки.
Механизм транзакций используется в СУБД для поддержания целостности данных в базе. Транзакцией называется некоторая неделимая последовательность операций над данными БД, которая отслеживается СУБД от начала и до завершения. Если по каким-либо причинам (сбои и отказы оборудования, ошибки в программном обеспечении, включая приложение) транзакция остается незавершенной, то она отменяется.
Транзакции присущи три основных свойства:
* атомарность (выполняются все входящие в транзакцию операции или ни одна);
* сериализуемость(отсутствует взаимное влияние выполняемых в одно и то же время транзакций);
* долговечность (даже крах системы не приводит к утрате результатов зафиксированной транзакции).
Примером транзакции является операция перевода денег с одного счета на другой в банковской системе. Сначала снимают деньги с одного счета, затем начисляют их на другой счет. Если хотя бы одно из действий не выполнится успешно, результат операции окажется неверным и будет нарушен баланс операции.
Ведение журнала изменений выполняется СУБД для обеспечения надежности хранения данных в базе при наличии аппаратных и программных сбоев.
Обеспечение целостности БД составляет необходимое условие успешного функционирования БД, особенно при ее сетевом использовании. Целостность БД -- это свойство базы данных, означающее, что в ней содержится полная, непротиворечивая и адекватно отражающая предметную область информация. Целостное состояние БД описывается с помощью ограничений целостности в виде условий, которым должны удовлетворять хранимые в базе данные.
Обеспечение безопасности достигается в СУБД шифрованием данных, парольной защитой, поддержкой уровней доступа к базе данных и отдельным ее элементам (таблицам, формам, отчетам и др.).
3. Модели организации данных
В иерархической модели объекты-сущности и отношения предметной области представляются наборами данных, которые имеют древовидную (иерархическую) структуру. Иерархическая модель данных была исторически первой. На ее основе в конце 60-х -- начале 70-х годов были разработаны первые профессиональные СУБД.
Основное внимание в ограничениях целостности в иерархической модели уделяется целостности ссылок между предками и потомками с учетом основного правила: никакой потомок не может существовать без родителя.
Сетевая модель данных позволяет отображать разнообразные взаимосвязи элементов данных в виде произвольного графа. Сетевая БД состоит из набора записей и набора соответствующих связей. На формирование связи особых ограничений не накладывается. Если в иерархических структурах запись-потомок могла иметь только одну запись-предка, то в сетевой модели данных запись-потомок может иметь произвольное число записей-предков.
Достоинством сетевой мидели данных является возможность ее эффективной реализации. В сравнении с иерархической моделью сетевая модель предоставляет бульшие возможности в смысле допустимости образования произвольных связей.
Недостатком сетевой модели данных является высокая сложность и жесткость схемы БД, построенной на ее основе, а также сложность ее понимания обычным пользователем. Кроме того, в сетевой модели данных ослаблен контроль целостности связей из-за допустимости установления произвольных связей между записями.
Системы на основе сетевой модели не получили широкого распространения на практике.
Реляционная модель данных предложена сотрудником фирмы IВМ Эдгаром Коддом и основывается на понятии отношения (relation).
Отношение представляет собой множество элементов, называемых кортежами. Наглядной формой представления отношения является двумерная таблица.
С помощью одной таблицы удобно описывать простейший вид связей между данными, а именно: деление одного объекта, информация о котором хранится в таблице, на множество подобъектов, каждому из которых соответствует строка или запись таблицы.
Основными недостатками реляционной модели являются следующие: отсутствие стандартных средств идентификации отдельных записей и сложность описания иерархических и сетевых связей.
4. Реляционные базы данных
Реляционная модель данных (РМД) некоторой предметной области представляет собой набор отношений, изменяющихся во времени. При создании информационной системы совокупность отношений позволяет хранить данные об объектах предметной области и моделировать связи между ними. Термины РМД представлены в табл. 4.1
Таблица 4.1. Терминыреляционноймодели
|
Терминреляционной одели |
Эквивалентный |
||
|
Отношение |
|||
|
Схема отношения |
Строка заголовков столбцов таблицы (заголовок таблицы) |
||
|
Строка таблицы, запись |
|||
|
Сущность |
Описание свойств объекта |
||
|
Столбец, поле |
|||
|
Множество допустимых значений |
атрибута |
||
|
Первичный ключ |
Уникальный идентификатор |
||
|
Кардинальность |
Количество строк |
||
|
Количество столбцов |
Реляционная база данных представляет собой хранилище данных, содержащее набор двухмерных таблиц. Данные в таблицах должны удовлетворять следующим принципам:
1. Значения атрибутов должны быть атомарными (иными словами,
каждое значение, содержащееся на пересечении строки и колонки,
должно быть не расчленяемым на несколько значений).
2. Значения каждого атрибута должны принадлежать к одному и тому же типу.
3. Каждая запись в таблице уникальна.
4. Каждое поле имеет уникальное имя.
5. Последовательность полей и записей в таблице не существенна.
Отношение является важнейшим понятием и представляет собой двумерную таблицу, содержащую некоторые данные.
Сущность есть объект любой природы, данные о котором хранятся в базе данных. Данные о сущности хранятся в отношении.
Атрибуты представляют собой свойства, характеризующие сущность. В структуре таблицы каждый атрибут именуется и ему соответствует заголовок некоторого столбца таблицы.
Ключом отношения называется совокупность его атрибутов, однозначно идентифицирующих каждый из кортежей отношения. Иными словами, множество атрибутов К, являющееся ключом отношения, обладает свойством уникальности. Следующее свойство ключа -- не избыточность. То есть никакое из собственных подмножеств множества К не обладает свойством уникальности.
Каждое отношение всегда имеет комбинацию атрибутов, которая может служить ключом.
Возможны случаи, когда отношение имеет несколько комбинаций атрибутов, каждая из которых однозначно определяет все кортежи отношения. Все эти комбинации атрибутов являются возможными ключами отношения. Любой из возможных ключей может быть выбран как первичный.
Ключи обычно используют для достижения следующих целей:
Исключения дублирования значений в ключевых атрибутах (остальные атрибуты в расчет не принимаются);
Упорядочения кортежей. Возможно упорядочение по возрастанию или убыванию значений всех ключевых атрибутов, а также смешанное упорядочение (по одним -- возрастание, а по другим -- убывание);
Организации связывания таблиц.
Важным является понятие внешнего ключа. Внешний ключ можно определить как множество атрибутов одного отношения R2, значения которых должны совпадать со значениями возможного ключа другого отношения R1.
Атрибуты отношения К2, составляющие внешний ключ, не являются ключевыми для данного отношения.
С помощью внешних ключей устанавливаются связи между отношениями.
Проектирование баз данных информационных систем является достаточно трудоемкой задачей. Оно осуществляется на основе формализации структуры и процессов предметной области, сведения о которой предполагается хранить в БД. Различают концептуальное и схемно-структурное проектирование.
Концептуальное проектирование БД ИС является в значительной степени эвристическим процессом. Адекватность построенной в его рамках инфологической модели предметной области проверяется опытным путем, в процессе функционирования ИС.
Этапы концептуального проектирования:
* изучение предметной области для формирования общего представления о ней;
* выделение и анализ функций и задач разрабатываемой ИС;
* определение основных объектов-сущностей предметной области
и отношений между ними;
* формализованное представление предметной области.
При проектировании схемы реляционной БД можно выделить следующие процедуры:
* определение перечня таблиц и связей между ними;
* определение перечня полей, типов полей, ключевых полей каждой таблицы (схемы таблицы), установление связей между таблицами через внешние ключи;
* установление индексирования для полей в таблицах;
* разработка списков (словарей) для полей с перечислительными
данными;
* установление ограничений целостности для таблиц и связей;
* нормализация таблиц, корректировка перечня таблиц и связей. Проектирование БД осуществляется на физическом и логическом уровнях. Проектирование на физическом уровне реализуется средствами СУБД и зачастую автоматизировано.
Логическое проектирование заключается в определении числа и структуры таблиц, разработке запросов к БД, отчетных документов, создании форм для ввода и редактирования данных в БД и т. д.
Одной из важнейших задач логического проектирования БД является структуризация данных. Выделяют следующие подходы к проектированию структур данных:
* объединение информации об объектах-сущностях в рамках одной таблицы (одного отношения) с последующей декомпозицией на несколько взаимосвязанных таблиц на основе процедуры нормализации отношений;
* формулирование знаний о системе (определение типов исходных данных и взаимосвязей) и требований к обработке данных, получение с помощью СА5Е-системы готовой схемы БД или даже готовой прикладной информационной системы;
* осуществление системного анализа и разработкас труктурных моделей.
5. Назначение и принцип работы SQL
SQL (часто произносится как "сиквэл", сокращенное название от Structured Query Language) символизирует собой Структурированный Язык Запросов.
SQL является инструментом, предназначенным для обработки и чтения данных, содержащихся в компьютерной базе данных. Это язык который дает возможность эффективно создавать реляционные базы данных и работать с ними.
Мир баз данных становится все более и более единым, что привело к необходимости создания стандартного языка, который мог бы функционировать в большом количестве различных видов компьютерных сред. Стандартный язык позволит пользователям знающим один набор команд, использовать их чтобы создавать, отыскивать, изменять, и передавать информацию независимо от того работают ли они на персональном компьютере, сетевой рабочей станции, или на универсальной ЭВМ. Во все более и более взаимосвязанном компьютерном мире, пользователь, снабженный таким языком, имеет огромное преимущество в использовании и обобщении информации из ряда источников с помощью большого количества способов.
Как следует из названия, SQL является языком программирования, который применяется для организации взаимодействия пользователя с базой данных. На самом деле SQL работает только с базами данных реляционного типа.
6. Инфологическая модель
При создании инфологической модели была проанализирована предметная область заданной базы данных «Учебные планы, изучаемых дисциплин направления ПМИ». Было выделено 4 объекта: Учебный план, Дисциплина, Студент, Преподаватель, а также две дополнительные таблица, осуществляющие связь между студентами и дисциплинами, а также между преподавателями и дисциплинами. Объект Учебный план имеет атрибуты: Год создания, Номер учебного плана. Объект Дисциплина имеет такие атрибуты: Название дисциплины, Код дисциплины, Номер учебного плана, Количество часов лекций, Количество часов практик, Количество часов на лабораторные работы, Всего часов, Количество часов в неделю, Форма отчетности по дисциплине, Семестр изучения. Объект Судент имеет атрибуты: Номер зачетной книжки, ФИО. И объект Преподаватель имеет атрибуты: ФИО, Табельный номер, Кафедра, Должность, Телефон. Объекты Учебный план и Дисциплина связаны в отношении 1:n, объекты Дисциплина и Студент связаны отношением 1:n, и объекты Дисциплина и Преподаватель связаны отношением 1:n.
При описании инфологической модели использовались ER-диаграммы:
Рисунок 1
7. Логическая модель
Логическая модель описывает понятия предметной области, их взаимосвязь, а также ограничения на данные, налагаемые предметной областью.
Логическая модель данных является начальным прототипом будущей базы данных. Она строится в терминах информационных единиц, но без привязки к конкретной СУБД. Более того, логическая модель данных необязательно должна быть выражена средствами именно реляционной модели данных.
Для создания логической модели каждому объекту была поставлена в соответствие таблица, с определенным набором полей. Так как Объекты Дисциплина и Преподаватель связаны в отношении 1:n, то появляется дополнительная таблица для представления связи между объектами Дисциплина и Преподаватель: Преподает.
Всего у нас 4 объекта и следовательно будет 4 таблицы для их представления, объект Учебный план является только информационным, так как работа базы данных осуществляется только с одним учебным планом:
Но между двумя объектами имеется связь 1:n, поэтому нам необходимо ввести еще одну таблицу для представления связей между этими таблицами. Это будет таблица Преподает (Disciplina-Prepodavatel) и таблица Изучает(Disciplina- Student).
Представленную базу данных можно отнести к 5-ой нормальной форме, т.к. она относится к 3-ей нормальной форме и первичный ключ является простым. Логическая схема реализована в Microsoft Access.
Рисунок 2
8. Структура таблиц
Исходная база данных состоит из 5 таблиц (таблицу Учебные планы не считаем, так как используется один учебный план).
Расшифровка полей:
v Disciplina.db
Ш Nazv- название дисциплины, тип поля: String;
Ш Kod - уникальный код дисциплины: LongInt;
Ш Semestr - семестр, в котором она преподается: String;
Ш KolLeKCh - количество лекций по данной дисциплине: LongInt;
Ш KolPraktCh - количество практик по данной дисциплине: LongInt;
Ш KolLabRabCh - количество лекций по данной дисциплине: LongInt;
Ш VsegoCh - общее количество часов: LongInt;
Ш NomerYP - номер учебного плана, в котором содержится дисциплина: LongInt.
v Student.db
Ш NomerStudBileta - номер студенческого билета: LongInt;
Ш FIO - фамилия студента: ShortInt;
v Prepodaet.db (Disciplina-Prepodavatel)
Ш TabNomerPrepod - табельный номер преподавателя, который преподает соответствующую дисциплину: LongInt;
Ш FIO- ФИО преподавателя, который преподает соответствующую дисциплину: String.
v Prepod.db
Ш FIO - ФИО преподаваля: String;
Ш TabelNomerPrepodavatelya - уникальный табельный номер преподавателя: LongInt;
Ш Kafedra - кафедра, на которой он работает: String;
Ш Dolshnost - Должность преподавателя: String;
Ш Telefon- контактный телефон преподавателя: String.
v Izuchaet.db(Disciplina- Student)
Ш KodDiscip- код дисциплины: LongInt;
Ш NomerStudBileta - номер студенческого билета студента, изучающего дисциплину: LongInt;
Ш FIO- ФИО студента, который изучает соответствующую дисциплину: String;
Ш Ocenka - оценка студента по изучаемой дисциплине: LongInt;.
9. Проектирование SQL-запросов
1. Сформироватьсписок зачетов и экзаменов для каждого семестра.
select Nazv,FormaOtchet
where Semestr=:s and
(Disciplina.FormaOtchet="Зачет" or Disciplina.FormaOtchet="Экзамен") ;
2. Сформировать экзаменнационно-зачетные ведомости/ основные и дополнительные/ по каждому предмету.
Основная ведомость:
select Prepodaet.FIO,
Disciplina.ObsheeKolChVNed,Disciplina.Semestr,Izuchaet.FIO,Izuchaet.
Ocenka,Disciplina.Nazv
from Disciplina, Prepodaet,Izuchaet
where Disciplina.KodDiscip=Prepodaet.KodDiscip
and (Disciplina.FormaOtchet="Экзамен" or Disciplina.FormaOtchet="Зачет")
Дополнительная ведомость(для студентов, имеющих 2):
select Disciplina.Nazv,Prepodaet.FIO,
Disciplina.ObsheeKolChVNed,Izuchaet.FIO,Disciplina.Semestr,Izuchaet.Ocenka
from Izuchaet,Disciplina,Prepodaet
where Izuchaet.Ocenka="2"
and Disciplina.KodDiscip=Izuchaet.KodDiscip
and Disciplina.KodDiscip=Prepodaet.KodDiscip
and (Disciplina.FormaOtchet="Экзамен" or Disciplina.FormaOtchet="Зачет");
Update Disciplina
set ObsheeKolChVNed=VsegoCh/17;
4. Подготовить вкладыш для диплома каждого студента:
select Disciplina.Nazv, Izuchaet.Ocenka, Izuchaet.FIO
from Izuchaet, Disciplina
where Disciplina.KodDiscip=Izuchaet.KodDiscip
and Disciplina.FormaOtchet="Экзамен"
Select AVG(Ocenka) as SrBall
Order by SrBall desc;
5. Выдать список группы в порядке убывания среднего балла:
Select FIO, AVG(Ocenka) as SrBall
Order by SrBall desc;
10. Структура и функции системы
Курсовая работа состоит из одного проекта “Project1” и 13 модулей.
1. Unit1 - здесь хранится форма, которая представляет собой титульный лист. Используются компоненты: Memo, Button.
2. Unit2 - здесь хранится форма, которая представляет собой начальную страницу базы данных. Здесь используются компоненты: Button, Memo.
3. Unit3 - здесь хранится форма, которая содержит в виде вкладок все таблицы базы данных. Здесь используются компоненты: Memo, Button, TabSheet, Table, DBGrid, DBNavigator, Label, Query.
4. Unit4 - здесь хранится форма, на которой отображается задание. Здесь используются компоненты: Memo, Button.
5. Unit5 - здесь хранится форма, на которой отображается дополнительная экзаменационная ведомость. Здесь используются компоненты: Memo, Button, TabSheet, Table, DBGrid, DBNavigator, Label, Query.
6. Unit6 - здесь хранится форма, на которой отображается список экзаменов и зачетов. Здесь используются компоненты: Memo, Button, TabSheet, Table, DBGrid, DBNavigator, Label, Query.
7. Unit7 - здесь хранится форма, на которой отображается основная экзаменационная ведомость. Здесь используются компоненты: Memo, Button, TabSheet, Table, DBGrid, DBNavigator, Label, Query.
8. Unit8 - здесь хранится форма, на которой отображается список группы в порядке убывания. Здесь используются компоненты: Memo, Button, TabSheet, Table, DBGrid, DBNavigator, Label, Query.
9. Unit9 - здесь хранится форма, на которой отображается вкладыш в диплом. Здесь используются компоненты: Memo, Button, TabSheet, Table, DBGrid, DBNavigator, Label, Query.
10. Unit10 - здесь хранится форма, на которой отображается форма по заполнению электронной ведомости. Здесь используются компоненты: Memo, Button, TabSheet, Table, DBGrid, DBNavigator, Label, Query.
11. Unit11 - здесь хранится форма, на которой отображается меню. Здесь используются компоненты: Memo, Button, Label.
12. Unit12 - здесь хранится форма, на которой отображается отчет по созданию электронной экзаменационной ведомости. Здесь используются компоненты: Memo и Button, RVProject, RVQueryConnnection и Query.
13. Unit13 - здесь хранится форма, на которой отображается отчет по созданию вкладыша в диплом. Здесь используются компоненты: Memo и Button, RVProject, RVQueryConnnection и Query.
11. Руководство для пользователя
1. Запускаем проект. Перед нами появляется титульный лист курсовой работы
Рисунок 3
Здесь мы можем сразу войти в базу данных, а можем посмотреть задание и вернуться к этой форме. Выбираем «Показать задание»
2. Перед нами появляется окно с информацией по заданию курсовой работы
Рисунок 4
3. Возвращаемся назад, нажав на соответствующую кнопку и начинаем работу, нажав на кнопу предыдущего окна «Продолжить»
Рисунок 5
4. Ознакомившись с информацией на данной странице, нажимаем на кнопку «Вход»
Рисунок 6
Перед нами появляется окно, содержащее на вкладках всю информацию содержащуюся в базе данных. Здесь мы можем просмотреть список дисциплин, учебную группу, преподавателей, что изучают те или иные студенты и какой предмет преподают преподаватели.
5. Также с этого окна мы можем перейти к запросам. Нажимаем на соответствующую кнопку.
Рисунок 7
Здесь мы можем выбрать любой интересующий запрос просто нажав на соответствующую кнопку. Также здесь мы можем вернуться к таблицам и перейти к формированию электронного варианта экзаменационной ведомости.
6. Нажимаем на кнопку «Просмотреть список зачетов и экзаменов для каждого семестра»
Рисунок 8
Здесь необходимо ввести номер семестра и нажать на кнопку ниже, далее в окошке таблицы появится список экзаменов и зачетов для введенного вами семестра. С этого листа мы можем вернуться обратно к запросам.
7. Нажимаем на кнопку «Перейти к основной экзаменационной ведомости»
Здесь необходимо выбрать название дисциплины из выпадающего списка, затем ввести это название в окошечко под выпадающем списке и нажать на кнопку «Выполнить». Запрос покажет общее количество часов в неделю на изучение введенной вами дисциплины, а так же отобразит список студентов, изучающих данную дисциплину и их оценку за эту дисциплину. Внимание! Поле оценка заполняется на форме с таблицами внутри вкладки Студент-Дисциплина. Так же на этом листе можно сформировать дополнительную экзаменационную ведомость. Для студентов, имеющих оценку 2. С этого листа мы можем вернуться обратно к запросам.
Рисунок 9
8. Нажимаем на кнопку «Перейти к дополнительной экзаменационной ведомости»
Рисунок 10
Здесь мы можем увидеть студентов, имеющих оценку 2 по той или иной дисциплине. С этого листа мы можем вернуться обратно к запросам.
9. Нажимаем на кнопку «Сформировать вкладыш для диплома»
Рисунок 11
Здесь необходимо ввести ФИО выпускника, выбрав соответствующего студента из выпадающего списка. Далее нажать на клавишу. И тогда по запросу заполнится столбец «Дисциплина» списком изученных дисциплин на 5 лет обучения, а также появятся соответствующие им оценки. На этом же листе можно просмотреть электронную версию вкладыша, нажав на кнопку «Версия для печати». После просмотра данной версии необходимо просто закрыть открывшееся окно на красный крестик в правом верхнем углу экрана.
Рисунок 12
10. Нажимаем на кнопку «Прсмотреть список группы в порядке убывания среднего балла»
Рисунок 13
Здесь мы видим список группы и соответствующий каждому студенту средний балл, расположенный в порядке убывания. С этого листа мы можем вернуться обратно к запросам.
Рисунок 14
Выберем из выпадающего списка интересующую нас дисциплину, например, экономика и введем ее название в окошко под выпадающим списком. Далее нажмем кнопку выполнить и увидим фамилию преподавателя данной дисциплины.
Рисунок 16
Здесь мы видим название выбранной нами дисциплины, ФИО преподавателя этой дисциплины. А так же список студентов, которые изучали данную дисциплину. Для выхода из отчета просто нажмите на крестик в правом верхнем углу экрана. Возвращаемся на предыдущий лист. С этого листа мы можем вернуться обратно к запросам.
12. Создание таблиц
Для создания таблиц использовался утилит Database Desktop. Его можно запустить - Пуск/Программы/Borland Delphi 7/ Database Desktop. Необходимо настроить рабочий каталог утилиты. Выберете команду File/Working Directory и установите ваш рабочий каталог. Для создания таблицы выберете команду File/New/Table. Затем необходимо выбрать тип таблицы. Тип PARADOX 7 можно считать наилучшим для файл-серверных таблиц.
1. Создание таблицы YchebPlan(Учебный план):
Рисунок 17
5. Создание таблицы Disciplina(Дисциплина):
Рисунок 18
6. Создание таблицы Student:
Рисунок 19
7. Создание таблицы Prepodaet (Дисциплина-Преподаватель):
Рисунок 20
5. Создание таблицы Prepod (Преподаватель):
Рисунок 21
8. Создание таблицы Izuchaet (Дисциплина-Студент):
Рисунок 22
13. Создание приложения в Delphi
Для того чтобы создать новое приложение, нужно в меню File выбрать пункт New/Application. Появляется форма и модуль (в целом это называется проект), теперь можно помещать на форму необходимые компоненты. При необходимости можно создать еще форму (и не одну), для этого нужно в меню File выбрать пункт New/ Form.
1. Таблица. Заполнение данными. Отображение данных.
Для того чтобы отобразить таблицу на форме, нужно поместить на нее компоненты:
· Table (на вкладке BDE) - В инспекторе объектов на вкладке «Параметры» в свойстве Tablename выбрать нужную таблицу.
Рисунок 23
· DBGrid (на вкладке DataControls) - необходим для отображения таблицы на форме, в Инспекторе объектов в свойстве DataSource указать нужный источник данных.
Рисунок 24
· DBNavigator (на вкладке DataControls) - необходим для перемещения по записям таблицы. В инспекторе Объектов в свойстве DataSource указывается тот же источник данных, что и в DBGrid. Функции навигатора доступны при щелчке на его кнопках во время работы приложения, Компонент содержит 10 кнопок.
Рисунок 25
· DataSource (вкладка Data Access) - компонент промежуточного уровня, для доступа к данным. Служит посредником между таблицами СУБД и экранными элементами управления (DBGrid, DBNavigator).
Рисунок 26
14. Создание поля с информацией (Memo) и кнопок
На форму помещается компонент Memo, который располагается на вкладке Standard.
Рисунок 27
В инспекторе объектов на вкладке «Параметры» в свойстве Lines вводится необходимый для отображения текст
Рисунок 28
Создание кнопок.
Для корректного закрытия формы на нее помещается компонент Button, который располагается на вкладке Standard.
Рисунок 29
Для того чтобы кнопка работала необходимо в Обработчике событий OnClick указать:
procedure TForm1.N5Click(Sender: TObject);
begin
Form2.Show;
Form1.Close;
end;
15. Создание подписей к таблицам
Для подписи таблицы в курсовой работе был использован компонент Lable, расположенный на вкладке Standard. В Инспекторе Объектов в свойстве Caption нужно просто написать текст.
Рисунок 30
16. Создание выпадающего списка
Для выбора команды из имеющегося списка используется компонент ComboBox (выпадающий список). Его заполнение можно осуществить таким образом
В Инспекторе Объектов в свойстве Items необходимо написать:
Рисунок 31
16. Создание отчетов
Отчет создается с помощью инструмента QReports,который необходимо с начало подключать: Component->install packages->add открыть папку bin выбрать файл dclqrt70.bpl нажать OKи тогда появится вкладка с компонентами QReport. Используемые мной компоненты:
Таблица 2
17. Листинг программы
Описание проекта
program Project1;
uses
Forms,
Unit1 in "Unit1.pas" {Form1},
Unit2 in "Unit2.pas" {Form2},
Unit3 in "Unit3.pas" {Form3},
Unit4 in "Unit4.pas" {Form4},
Unit5 in "Unit5.pas" {Form5},
Unit6 in "Unit6.pas" {Form6},
Unit7 in "Unit7.pas" {Form7},
Unit8 in "Unit8.pas" {Form8},
Unit9 in "Unit9.pas" {Form9},
Unit10 in "Unit10.pas" {Form10},
Unit11 in "Unit11.pas" {Form11},
Unit12 in "Unit12.pas" {Form12},
Unit13 in "Unit13.pas" {Form13},
Unit14 in "Unit14.pas" {Form14};
{$R *.res}
begin
Application.Initialize;
Application.CreateForm(TForm1, Form1);
Application.CreateForm(TForm2, Form2);
Application.CreateForm(TForm3, Form3);
Application.CreateForm(TForm4, Form4);
Application.CreateForm(TForm5, Form5);
Application.CreateForm(TForm6, Form6);
Application.CreateForm(TForm7, Form7);
Application.CreateForm(TForm8, Form8);
Application.CreateForm(TForm9, Form9);
Application.CreateForm(TForm10, Form10);
Application.CreateForm(TForm11, Form11);
Application.CreateForm(TForm12, Form12);
Application.CreateForm(TForm13, Form13);
Application.CreateForm(TForm14, Form14);
Application.Run;
end.
Описание модуля Unit1
unit Unit1;
interface
uses
Dialogs, StdCtrls;
type
TForm1 = class(TForm)
Memo1: TMemo;
Button1: TButton;
Button2: TButton;
Button3: TButton;
private
{ Private declarations }
public
{ Public declarations }
end;
var
Form1: TForm1;
implementation
uses Unit2, Unit4, Unit6, Unit7, Unit5, Unit8, Unit9, Unit10;
{$R *.dfm}
procedure TForm1.Button3Click(Sender: TObject);
begin
Form2.show;
end;
procedure TForm1.Button2Click(Sender: TObject);
begin
Form1.Close;
end;
procedure TForm1.Button1Click(Sender: TObject);
begin
Form4.show;
end;
end.
Описание модуля Unit2
unit Unit2;
interface
uses
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
Dialogs, StdCtrls;
type
TForm2 = class(TForm)
Memo1: TMemo;
GroupBox1: TGroupBox;
Button1: TButton;
Button2: TButton;
procedure Button1Click(Sender: TObject);
procedure Button2Click(Sender: TObject);
private
{ Private declarations }
public
{ Public declarations }
end;
var
Form2: TForm2;
implementation
uses Unit3;
{$R *.dfm}
procedure TForm2.Button1Click(Sender: TObject);
begin
Form3.show;
Form2.Close;
end;
procedure TForm2.Button2Click(Sender: TObject);
begin
Form2.Close;
end;
Описание модуля Unit3
unit Unit3;
interface
uses
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
Dialogs, ComCtrls, ExtCtrls, DBCtrls, Grids, DBGrids, DB, DBTables,
StdCtrls, QuickRpt, QRCtrls;
type
TForm3 = class(TForm)
PageControl1: TPageControl;
TabSheet1: TTabSheet;
TabSheet2: TTabSheet;
TabSheet3: TTabSheet;
TabSheet4: TTabSheet;
TabSheet5: TTabSheet;
TabSheet6: TTabSheet;
DataSource1: TDataSource;
DataSource2: TDataSource;
DataSource3: TDataSource;
DataSource4: TDataSource;
Table1: TTable;
Table2: TTable;
Table3: TTable;
Table4: TTable;
DBGrid1: TDBGrid;
DBNavigator1: TDBNavigator;
DBGrid2: TDBGrid;
DBNavigator2: TDBNavigator;
DBGrid3: TDBGrid;
DBNavigator3: TDBNavigator;
DBGrid4: TDBGrid;
DBNavigator4: TDBNavigator;
DBGrid5: TDBGrid;
DBNavigator5: TDBNavigator;
DBGrid6: TDBGrid;
DBNavigator6: TDBNavigator;
Button1: TButton;
DataSource5: TDataSource;
DataSource6: TDataSource;
Table5: TTable;
Table6: TTable;
Query1: TQuery;
Button2: TButton;
Label1: TLabel;
Memo1: TMemo;
Label3: TLabel;
Button3: TButton;
procedure Button1Click(Sender: TObject);
procedure Button2Click(Sender: TObject);
procedure Button3Click(Sender: TObject);
private
{ Private declarations }
public
{ Public declarations }
end;
var
Form3: TForm3;
implementation
uses Unit5, Unit11;
{$R *.dfm}
procedure TForm3.Button1Click(Sender: TObject);
begin
Form11.show;
Form3.close;
end;
procedure TForm3.Button2Click(Sender: TObject);
begin
Query1.ExecSQL;
Form3.Refresh;
end;
procedure TForm3.Button3Click(Sender: TObject);
begin
Form3.close;
end;
Описание модуля Unit4
unit Unit4;
interface
uses
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
Dialogs, StdCtrls;
type
TForm4 = class(TForm)
Memo1: TMemo;
Button1: TButton;
procedure Button1Click(Sender: TObject);
private
{ Private declarations }
public
{ Public declarations }
end;
var
Form4: TForm4;
implementation
uses Unit1;
{$R *.dfm}
procedure TForm4.Button1Click(Sender: TObject);
begin
Form1.show;
end;
Описание модуля Unit 5
unit Unit5;
interface
uses
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
Dialogs, DB, DBTables, Grids, DBGrids, StdCtrls, Mask, DBCtrls, ExtCtrls;
type
TForm5 = class(TForm)
DataSource1: TDataSource;
DBGrid1: TDBGrid;
Query1: TQuery;
DBEdit1: TDBEdit;
DBEdit2: TDBEdit;
DBEdit3: TDBEdit;
Label1: TLabel;
Label2: TLabel;
Label3: TLabel;
Label4: TLabel;
DBNavigator1: TDBNavigator;
Button1: TButton;
procedure ComboBox1Change(Sender: TObject);
procedure Edit1Change(Sender: TObject);
procedure Button1Click(Sender: TObject);
private
{ Private declarations }
public
{ Public declarations }
end;
var
Form5: TForm5;
implementation
uses Unit11;
{$R *.dfm}
procedure TForm5.ComboBox1Change(Sender: TObject);
begin
Query1.Active:=true;
end;
procedure TForm5.Edit1Change(Sender: TObject);
begin
Query1.Open;
end;
procedure TForm5.Button1Click(Sender: TObject);
begin
Form11.show;
Form5.Close;
end;
Описание модуля Unit 6
unit Unit6;
interface
uses
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
Dialogs, DB, DBTables, Grids, DBGrids, StdCtrls, ExtCtrls, DBCtrls;
type
TForm6 = class(TForm)
Button1: TButton;
Edit1: TEdit;
DataSource1: TDataSource;
DBGrid1: TDBGrid;
Query1: TQuery;
Label1: TLabel;
DBNavigator1: TDBNavigator;
Label2: TLabel;
Memo1: TMemo;
Button2: TButton;
Label3: TLabel;
procedure Button1Click(Sender: TObject);
procedure Button2Click(Sender: TObject);
private
{ Private declarations }
public
{ Public declarations }
end;
var
Form6: TForm6;
implementation
uses Unit11;
{$R *.dfm}
procedure TForm6.Button1Click(Sender: TObject);
begin
Query1.Close;
if not Query1.Prepared then
Query1.Prepare;
if length (edit1.text)<>0 then
else
begin
Query1.Params.Value:=0;
end;
Query1.Open;
end;
procedure TForm6.Button2Click(Sender: TObject);
begin
Form11.show;
Form6.Close;
end;
Описание модуля Unit 7
unit Unit7;
interface
uses
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
Dialogs, StdCtrls, Grids, DBGrids, DBTables, DB, Mask, DBCtrls, ExtCtrls,
QRCtrls, QuickRpt;
type
TForm7 = class(TForm)
Label1: TLabel;
Label2: TLabel;
DataSource1: TDataSource;
Query1: TQuery;
Edit2: TEdit;
Button1: TButton;
DBEdit1: TDBEdit;
DBEdit2: TDBEdit;
Label3: TLabel;
DBGrid1: TDBGrid;
Label4: TLabel;
Label5: TLabel;
DBNavigator1: TDBNavigator;
Button2: TButton;
Label6: TLabel;
Label7: TLabel;
Memo1: TMemo;
ComboBox1: TComboBox;
Label8: TLabel;
Button3: TButton;
procedure Button1Click(Sender: TObject);
procedure Button2Click(Sender: TObject);
procedure Button3Click(Sender: TObject);
private
{ Private declarations }
public
{ Public declarations }
end;
var
Form7: TForm7;
implementation
uses Unit5, Unit11;
{$R *.dfm}
procedure TForm7.Button1Click(Sender: TObject);
begin
Query1.Close;
if not Query1.Prepared then
Query1.Prepare;
if length (edit2.text)<>0 then
Query1.Params.Value:=edit2.Text
else
begin
Query1.Params.Value:=0;
edit2.Text:="Введите название!";
end;
Query1.Open;
end;
procedure TForm7.Button2Click(Sender: TObject);
begin
Form5.show;
Form7.close;
end;
procedure TForm7.Button3Click(Sender: TObject);
begin
Form11.show;
Form7.close;
end;
Описание модуля Unit 8
unit Unit8;
interface
uses
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
type
TForm8 = class(TForm)
Label4: TLabel;
DataSource1: TDataSource;
Query1: TQuery;
DBGrid1: TDBGrid;
DBNavigator1: TDBNavigator;
Button1: TButton;
Memo1: TMemo;
procedure Button1Click(Sender: TObject);
private
{ Private declarations }
public
{ Public declarations }
end;
var
Form8: TForm8;
implementation
uses Unit11;
{$R *.dfm}
procedure TForm8.Button1Click(Sender: TObject);
begin
Form11.show;
Form8.close;
end;
Описание модуля Unit 9
unit Unit9;
interface
uses
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
Dialogs, Grids, DBGrids, DB, DBTables, StdCtrls, Mask, DBCtrls, ExtCtrls;
type
TForm9 = class(TForm)
Edit1: TEdit;
Query1: TQuery;
DataSource1: TDataSource;
DBGrid1: TDBGrid;
Button1: TButton;
Query2: TQuery;
DataSource2: TDataSource;
Button2: TButton;
DBEdit1: TDBEdit;
DBNavigator1: TDBNavigator;
Label1: TLabel;
Label2: TLabel;
Label3: TLabel;
Name: TComboBox;
Button3: TButton;
Memo1: TMemo;
Label4: TLabel;
Button4: TButton;
procedure Button1Click(Sender: TObject);
procedure Button2Click(Sender: TObject);
procedure Button3Click(Sender: TObject);
private
{ Private declarations }
public
{ Public declarations }
end;
var
Form9: TForm9;
implementation
uses Unit11, Unit13;
{$R *.dfm}
procedure TForm9.Button1Click(Sender: TObject);
begin
Query1.Close;
if not Query1.Prepared then
Query1.Prepare;
if length (edit1.text)<>0 then
Query1.Params.Value:=edit1.Text
else
begin
Query1.Params.Value:=0;
edit1.Text:="Введите имя выпускника!";
end;
Query1.Open;
end;
procedure TForm9.Button2Click(Sender: TObject);
begin
Query2.Close;
if not Query2.Prepared then
Query2.Prepare;
if length (edit1.text)<>0 then
Query2.Params.Value:=edit1.Text
else
begin
Query2.Params.Value:=0;
edit1.Text:="Введите номер семестра!";
end;
Query2.Open;
end;
procedure TForm9.Button3Click(Sender: TObject);
begin
Form11.show;
Form9.close;
end;
procedure TForm9.Button4Click(Sender: TObject);
begin
Form13.QuickRep1.Preview;
end;
Описание модуля Unit 10
unit Unit10;
interface
uses
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
Dialogs, ExtCtrls, QuickRpt, StdCtrls, DB, DBTables, Mask, DBCtrls,
Grids, DBGrids;
type
TForm10 = class(TForm)
Button1: TButton;
Query1: TQuery;
DataSource1: TDataSource;
DBEdit1: TDBEdit;
DBEdit2: TDBEdit;
Label1: TLabel;
Label2: TLabel;
Edit1: TEdit;
Button2: TButton;
Label3: TLabel;
ComboBox1: TComboBox;
Label4: TLabel;
Label5: TLabel;
Memo1: TMemo;
Label6: TLabel;
Label7: TLabel;
Button3: TButton;
procedure Button1Click(Sender: TObject);
procedure Button2Click(Sender: TObject);
procedure Button3Click(Sender: TObject);
private
{ Private declarations }
public
{ Public declarations }
end;
var
Form10: TForm10;
implementation
uses Unit3, Unit7, Unit12, Unit11;
{$R *.dfm}
procedure TForm10.Button1Click(Sender: TObject);
begin
Form12.QuickRep1.Preview;
end;
procedure TForm10.Button2Click(Sender: TObject);
begin
Query1.Close;
if not Query1.Prepared then
Query1.Prepare;
if length (edit1.text)<>0 then
Query1.Params.Value:=edit1.Text
else
begin
Query1.Params.Value:=0;
edit1.Text:="Введите название!";
end;
Query1.Open;
end;
procedure TForm10.Button3Click(Sender: TObject);
begin
Form11.show;
end;
Описание модуля Unit 11
unit Unit11;
interface
uses
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
Dialogs, StdCtrls;
type
TForm11 = class(TForm)
Button1: TButton;
Button2: TButton;
Button3: TButton;
Button4: TButton;
Button5: TButton;
Button6: TButton;
Memo1: TMemo;
Label1: TLabel;
Label2: TLabel;
Label3: TLabel;
Button7: TButton;
Label4: TLabel;
Label5: TLabel;
procedure Button2Click(Sender: TObject);
procedure Button1Click(Sender: TObject);
procedure Button4Click(Sender: TObject);
procedure Button3Click(Sender: TObject);
procedure Button5Click(Sender: TObject);
procedure Button6Click(Sender: TObject);
procedure Button7Click(Sender: TObject);
private
{ Private declarations }
public
{ Public declarations }
end;
var
Form11: TForm11;
implementation
Подобные документы
Создание таблиц и проектирование систем управления базами данных. Инфологическое проектирование. Реляционная схема базы данных. Прикладное значение систем: отчет о поставщиках и поставляемых ими товарах. Выписка о наличии товара в магазине.
курсовая работа , добавлен 01.12.2008
Разработка базы данных с информацией о сотрудниках, товарах, со справочником типов товаров средствами системы управления базами данных MySQL с помощью SQL-запросов. Разработка инфологической модели предметной области. Структура таблиц, полей базы данных.
контрольная работа , добавлен 13.04.2012
Процесс проектирования базы данных, разработка её логической структуры в соответствии с инфологической моделью предметной области. Работа с программой СУБД Access, свойства таблиц и их полей, создание межтабличных связей; инфологическое проектирование.
курсовая работа , добавлен 17.12.2009
Основные понятия базы данных и систем управления базами данных. Типы данных, с которыми работают базы Microsoft Access. Классификация СУБД и их основные характеристики. Постреляционные базы данных. Тенденции в мире современных информационных систем.
курсовая работа , добавлен 28.01.2014
Особенности разработки инфологической модели и создание структуры реляционной базы данных. Основы проектирования базы данных. Разработка таблиц, форм, запросов для вывода информации о соответствующей модели. Работа с базами данных и их объектами.
курсовая работа , добавлен 05.11.2011
Исследование характеристик и функциональных возможностей системы управления базами данных Microsoft Office Access. Определение основных классов объектов. Разработка базы данных "Делопроизводство". Создание таблиц, форм, запросов, отчетов и схем данных.
реферат , добавлен 05.12.2014
Тенденция развития систем управления базами данных. Иерархические и сетевые модели СУБД. Основные требования к распределенной базе данных. Обработка распределенных запросов, межоперабельность. Технология тиражирования данных и многозвенная архитектура.
реферат , добавлен 29.11.2010
Теоретические сведения и основные понятия баз данных. Системы управления базами данных: состав, структура, безопасность, режимы работы, объекты. Работа с базами данных в OpenOffice.Org BASE: создание таблиц, связей, запросов с помощью мастера запросов.
курсовая работа , добавлен 28.04.2011
Проектирование базы данных системы принятия, обработки и учёта заявок в отдел информационных технологий; разработка инфологической и даталогической моделей, реализация физической модели. Создание приложений для визуализации работы с базой данных.
дипломная работа , добавлен 25.01.2013
Выделение информационных объектов и их инфологическая модель. Логическая структура реляционной базы данных. Разработка таблиц в системе управления базами данных Access. Создание запросов, форм и отчетов в СУБД Access. Разработка приложения пользователя.