Одним из наиболее распространенных сценариев в разработке приложений является отображение данных из БД на формеWindows Forms . Поэтому с учетом процессов, которые используются при работе с наборами данных, предлагаемыхMicrosoft (рис. 5.6.1-2), и с учетом того, что представленные задачи учебные, в примерах будем рассматривать следующие процессы:
Разработка БД.
Разработка приложения Windows:
создание проекта;
создание интерфейса пользователей;
создание подключения к данным базы данных и отображение их на форме
редактирование, проверка и сохранение данных в приложении;
разработка программного кода приложения.
Выполнение приложения.
Анализ результатов работы приложения.
5.6.3.1. Пример создания проекта «Пропуски» для работы с бд «DataBase1»
Задание:
В базу данных c именем « DataBase 1» в определенные дни поступают сведения о количестве пропущенных часов, которые имеют студенты по каждому из трех предметов, при этом доступна следующая информация:
дата проверки;
учебная группа;
фамилия студента;
год рождения;
число пропущенных часов по информатике;
число пропущенных часов по математике
число пропущенных часов по физике.
Необходимо создать проект с именем «Пропуски», который используя сведения из этой базы данных, вычисляет в какой день и по какому предмету имелось наибольшее число пропусков (указать также фамилию студента, имеющего такое число пропусков). Если таких дней несколько, то перечислить их все.
Создание базы данных «DataBase1»
Для создания таблицы с именем ПропЧасыСтудента необходимо создать ее структуру, которая будет иметь вид, приведенный на рис. 5.6.3-1.
Заполнение таблицы данными можно выполнить в режиме таблицы. После заполнения таблица ПропЧасыСтудента принимает вид, приведенный на рис.5.6.3-2.
Разработка приложения Windows для работы с БД Access «DataBase1»
Создание нового проекта.
Создать проект с именем Пропуски1 .
Создание интерфейса пользователей.
Создать интерфейс пользователей из одной формы, которая изображена на рис. 5.6.3-3.
Обратите внимание, что шаблон таблицы ПропЧасыСтудента отображается на форме только послеподключения набора данных приложения к базе данных DataBase1.
Подключение набора данных приложения к базе данных DataBase1 СУБД Access и отображение их на форме.
Процедура подключения приложения VS к данным в базе данныхСУБД Access может быть упрощена за счет использованияМастера Конфигурации источников данных . После завершения работыМастера данные в окнеИсточники данных становятся доступными для перетаскивания на формы.
Для создания набора данных при помощи Мастера настройки источника данных
необходимо:
В элементе Данные главного меню выбрать командуДобавить новый источник данных или Показать источники данных.
В результате в среде разработки появится окно Мастер настройки источника данных (р ис. 5.6.3-4).
– это новая функцияVisual Studio IDE , которая автоматически подготавливает программу наVisual Basic к получению информации из базы данных.Мастер запрашивает тип базы данных, с которой будет производиться соединение (локальная илиудаленная база данных ,Web-служба илиобъект данных, созданный вами), устанавливает соединение с данными, а затем создает в программе набор данных, который хранит выбранные таблицы и поля базы данных. Конечным результатом является то, что мастер открывает окноИсточник данных и заполняет его визуальным представлением каждого объекта базы данных, используемого в программе.
После выбора Источника данных для приложения –База данных и нажатия на клавишуДалее Мастер запрашиваетВыбор подключения БД (рис. 5.6.3-5).
В окне Выбор источника данных (Рис. 5.6.3-6) выбратьБД , являющуюся источником данных –Файл базы данных Access, а затем нажать на кнопкуДалее .
Мастер отобразит форму – Добавление подключения , который помогает установить соединение с базой данных, создав строку, которая называетсясвязывающей строкой (connection string) (рис. 5.6.3-7).
Связывающая строка содержит информацию, которая требуется VS для открытия и извлечения информации из файла базы данных. Она включает путь и имя файла, а также дополнительные данные, такие, как имя пользователя и пароль. По этой причине работа со связывающей строкой в окне Мастер настройки источника данных выполняется очень аккуратно, и вам следует позаботиться о ее защите от несанкционированного доступа при копировании исходных файлов с одного места в другое.
Таким образом, в окне Добавление подключения базы данныхвыбратьAccess Database File .
Ввести путь к файлу базы данных DataBase 1.mdb или щелкнуть кнопкуОбзор , чтобы найти этот файл, а затем нажать кнопкуОК .
Снова появится диалоговое окно Добавление подключения (Add Connection) , содержащее путь к базе данных.
Щелкнуть на кнопке Проверить подключение. Visual Studio попробует открыть указанный файл базы данных, используя связывающую строку, созданную мастером.
Щелкнуть на кнопке ОК , чтобы закрыть окно сообщения, а затем щелкнуть на кнопкеОК , чтобы закрыть диалоговое окноДобавление подключение (Add Connection) .Visual Studio снова отобразит окно Мастер настройки источника данных (рис. 5.6.3-8)
Чтобы отобразить готовую связывающую строку, щелкните в диалоговом окне на знаке «плюс» (+) рядом с элементом Строка подключений. Страница Мастера должна выглядеть примерно, так как на рис. 5.6.3-9.
Связывающая строка определяет провайдера.
Мастер отобразит предупреждение, указывающее, что была выбрана новая локальная база данных (Рис. 5.6.3-10)
Рис. 5.6.3-10
Чтобы избежать создания дополнительной копии базы данных, щелкните на кнопке Нет, а затем на кнопкеДалее .
При этом Мастер настройки источника данных задаст такой вопрос о сохранении и строки подключения.
По умолчанию выбрана опция сохранения связывающей строки, а, в качестве имени строки в данном примере предлагается «DataBase1ConnectionString ». Обычно следует сохранять эту строку в настроечном файле приложения по умолчанию, который доступен в окнеОбозреватель решений (Solution Explorer), так как в этом случае при изменении места расположения базы данных эту строку можно будет легко отредактировать без поиска ее в коде программы и последующей перекомпиляции приложения (Рис. 5.6.3-11).
Затем будет выдан запрос на выбор подмножества объектов базы данных, которые будут использоваться в данном проекте, как показано в окне Мастер настройки источника данных , изображенном на рис. 5.6.3-12.
Рис. 5.6.3-12
Visual Studio позволяет использовать не только всю базу данных, но и часть ее или объединение нескольких различных баз данных - это полезно при создании приложений, основанных на данных.
Для нашей задачи следует выбрать все таблицы (поставить соответствующие флажки в квадратике).
Чтобы добавить функциональность в приложение, то есть отобразить таблицы базы данных на форме необходимо их перетащить из окна Источник данных на форму.
Перетаскивание элементов из окна Источники данных в форму автоматически добавляет нужный код для заполнения набора данных в обработчик событийForm1_Load()(рис. 5.6.3-13).
Рис. 5.6.3-13
Редактирование, проверка и сохранение данных в приложении
После заполнения набора данных обычно производится добавление, редактирование или удаление данных перед их отправкой обратно источнику данных, другому процессу или приложению. Поскольку каждая запись в наборе данных представляется объектом DataRow, изменения набора данных выполняются посредством работы с отдельными строками.
В Windows Forms архитектура привязки к данным занимается отправкой изменений из элементов управления с привязкой к данным в набор данных, поэтому не требуется в явном виде обновлять набор данных при помощи собственного кода. Наборы данных поддерживают множество версий строк данных для нахождения изначальных записей в источнике данных. Перед выполнением обновления источника данных, возможно, потребуется проверить отдельные строки.
Изменение данных в DataSetпредставляет собой процесс управления фактическими данными в отдельных объектах, которые составляют набор данных. Изменение данных в таблицах данных подобно изменению данных в таблице любой базы данных – процесс может включать вставку, обновление и удаление записей таблицы.
Кроме изменения фактических данных, также можно запрашивать DataTableдля возвращения определенных строк данных, например, отдельных строк, определенных версий строк (исходные и предложенные), только измененных строк и строк, которые содержат ошибки.
Разработка программного кода приложения
C первой формой будет связан код, приведенный на рис. 5.6.3-14.
Delphi -- среда разработки, использует язык программирования Delphi (начиная с 7 версии язык в среде именуется Delphi, ранее -- Object Pascal), разработанный фирмой Borland и изначально реализованный в её пакете Borland Delphi, от которого и получил в 2003 году своё нынешнее название. Object Pascal, по сути является наследником языка Pascal с объектно-ориентированными расширениями.
Delphi - оптимальный инструмент для создания приложений для баз данных. Оптимальный, т.к. поддерживает технологию визуальной разработки, которая позволяет существенно сократить время разработки при сохранении хорошего качества и надежности программного продукта. Delphi в структуре языка позволяет избегать скрытых ошибок.
Особенности семейства Delphi 7:
*Среда быстрой разработки приложений, в которой интегрированы средства моделирования разработки и развертывания приложений электронной коммерции и Web-сервисов.
*Поддержка языков программирования для Win32 (Delphi и C/C++) и для.NET (Delphi и C#) в единой среде разработки, что позволяет упростить сопровождение и создание новых приложений Win32 и более легко освоить технологии.NET;
*Возможность как для разработчиков традиционных приложений под Windows, так и для разработчиков, использующих Java, разрабатывать приложения.NET без отказа от используемого инструментария, с сохранением навыков и с аналогичными концепциями программирования;
*Новая система шаблонов кода и другие нововведения среды разработки качественно улучшают работу с исходными текстами и повышают производительность разработки;
Microsoft SQL Server 2000 - это законченное предложение в области баз данных и анализа данных для быстрого создания масштабируемых решений электронной коммерции, бизнес-приложений и хранилищ данных.
Оно позволяет значительно сократить время выхода этих решений на рынок, одновременно обеспечивая масштабируемость, отвечающую самым высоким требованиям.
Пакет Delphi -- продолжение линии компиляторов языка Pascal корпорации Borland. Pascal как язык очень прост, а строгий контроль типов данных способствует раннему обнаружению ошибок и позволяет быстро создавать надежные и эффективные программы.
Разработка приложений баз данных является одной из наиболее востребованных возможностей среды программирования Delphi. Мощность и гибкость Delphi при работе с базами данных основана на низкоуровневом ядре - процессоре баз данных Borland Database Engine (BDE). Его интерфейс с прикладными программами называется Integrated Database Application Programming Interface (IDAPI). BDE позволяет осуществлять доступ к данным как с использованием традиционного record-ориентированного (навигационного) подхода, так и с использованием set-ориентированного подхода, используемого в SQL-серверах баз данных.
Библиотека объектов содержит набор визуальных компонент, значительно упрощающих разработку приложений для СУБД с архитектурой клиент-сервер. Объекты инкапсулируют в себя нижний уровень - Borland Database Engine.
Предусмотрены специальные наборы компонент, отвечающих за доступ к данным, и компонент, отображающих данные. Компоненты доступа к данным позволяют осуществлять соединения с БД, производить выборку, копирование данных, и т.п.
Компоненты визуализации данных позволяют отображать данные виде таблиц, полей, списков. Отображаемые данные могут быть текстового, графического или произвольного формата.
Таблицы сохраняются в базе данных. Некоторые СУБД сохраняют базу данных в виде нескольких отдельных файлов, представляющих собой таблицы (в основном, все локальные СУБД), в то время как другие состоят из одного файла, который содержит в себе все таблицы и индексы (InterBase).
Объекты БД в Delphi основаны на SQL и включают в себя полную мощь Borland Database Engine. В состав Delphi также включен Borland SQL Link, поэтому доступ к СУБД Oracle, Sybase, Informix и InterBase происходит с высокой эффективностью. Кроме того, Delphi включает в себя локальный сервер Interbase для того, чтобы можно было разработать расширяемые на любые внешние SQL-сервера приложения в офлайновом режиме.
Масштабируемость на практике -- одно и то же приложение можно использовать как для локального, так и для более серьезного клиент-серверного вариантов.
Хотя Delphi не имеет своего формата таблиц БД, она тем не менее обеспечивает мощную поддержку большого количества различных СУБД -- как локальных (например, dBase или Paradox), так и промышленных (например, Sybase или InterBase).
Федеральное агентство по образованию
Государственное образовательное учреждение высшего профессионального образования
«ЧЕЛЯБИНСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ»
Курсовая работа
Разработка приложений баз данных
Анализ предметной области
Описание предметной области и функции решаемых задач
В курсовой работе в соответствии с заданием автоматизируется деятельность отдела сбыта предприятия «Русская еда».
Предметом области автоматизации являются некоторые должностные функции отдела сбыта. В отделе сбыта имеется план выпуска готовой продукции составленный на три месяца. В соответствии с этим планом цеха выпускают продукцию, но фактический выпуск продукции зависит от многих факторов и может отличаться от планового. В отдел сбыта поступают также цеховые накладные, которые отражают фактический выпуск продукции и сдачу ее на определенные склады.
Задача отдела сбыта - сделать анализ выполнения плана сдачи изделий на склады. Для этого необходимо выбрать плановые и фактические данные за определенный период по определенному складу и проанализировать отклонение факта от плана.
На предприятии работают 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), позволяющих «расшить» узкие места. Пакет поддерживает несколько СУБД, что обеспечивает экономию средств.
Технические различия между технологиями объектно-ориентированных и реляционных баз данных привели к различию культур, до сих пор разделяющему сообщество управления данными и сообщество разработки. Что с этим делать дальше?
