· Навигация по набору данных возможна только от первой записи, к последней. В наборе данных могут использоваться только навигационные методы First и Next. Попытка обращения к любому другому методу (Prior, Last) вызывает исключение.
· Набор данных не может сортироваться или фильтроваться (точнее, сортировка и фильтрация реализуется SQL – запросом, а не свойствами Filter, Filtered, IndexName).
· Клиент не может визуализировать данные в сетках TDBGrid.
· Набор данных не может редактироваться (их свойства CanModify всегда имеют значения False).
· К набору данных нельзя присоединить подстановочные столбцы.
· К набору данных нельзя использовать закладки и поиск записей методами Locate и Lookup.
· Наконец, по результатам выборки нельзя создать отчет главный –детальный, используя технологию RaveReports или компоненты вкладки QReport.
3.3 Информация о поставщиках и товарах ООО «Уралэнергоцентр»
Компания ООО «Уралэнергоцентр» является представительством крупных заводов Южной Кореи. Поставляют товар такие заводы, как OLYMPIACOLTD, HYSCOCOLTD, BOOSTERCOLTD.
Ассортимент товара:
· Паровыекотлы BOOSTER CO LTD;
· Вакуум – водогрейныхкотлов BOOSTER CO LTD;
· Отопительные котлы (на дизельном топливе и газовом топливе) OLYMPIACOLTD;
· Горелки OLYMPIA CO LTD;
· Насосы WILO;
· Металлопластиковые трубы HYSCOCOLTD;
· Компрессорные и пресс - фитинги;
· Шаровые краны HYSCOCOLTD;
· Радиаторов HYSCOCOLTD;
Клиентами компании ООО «Уралэнергоцентр» являются: торговые магазины, разнообразные компании, крупные заводы, фабрики и так далее.
Приведу в пример несколько фирм, с которыми тесно сотрудничает компания:
· ООО «Трионика», находящаяся по адресу: г. Екатеринбург, ул. Ленина 28, контактный телефон 8 (343) 210-10-10, E-mail:. Trionika@.ru
· ООО «Водяной», находящийся по адресу: г. Екатеринбург, ул. ул. Гагарина 10, контактный телефон 8 (343) 220-20-20, E-mail:. Vodyanoy@.ru
· ООО «Тепло», находящийся по адресу: г. Екатеринбург, ул. ул. Серова 55, контактный телефон 8 (343) 230-30-30, E-mail:. Teplo@.ru
3.4 Проектирование базы данных
Пример базы данных в этом дипломном проекте относится к демонстрации базы данных по товарообороту, система управления которой предназначена для автоматизации работы крупного оптового поставщика теплооборудования. В дипломном проекте я пытаюсь описать основные функции оптового поставщика и создать проект соответствующей базы данных.
Оптовый поставщик является промежуточным звеном между заводом (поставляющим оборудование) и магазинами (клиентами). Наличие этого звена выгодно тем и другим: завод, изготовив оборудование, отправляет значительную часть оптовому поставщику и, таким образом, не заботиться об отслеживание многочисленных связей с магазинами; магазины, в свою очередь, находят у оптового поставщика огромный ассортимент товара. На рисунке 6 отображены взаимосвязи между оптовым поставщиком и его партнерами.
Характерной особенностью является двусторонний обмен товаром, как с поставщиками, так и с покупателями. Это связано с тем, что большинство покупателей берут товар без предварительной оплаты, обязуясь реализовать их в определенный срок. По истечении этого срока магазин обязан оплатить взятый им товар и, возможно, вернуть не проданный товар оптовому поставщику. На таких же условиях берет продукцию оптовый поставщик у завода.
Итак, существует два вида документов, которыми обмениваются оптовый поставщик со своими партнерами: это накладные на отпуск, покупку или возврат оборудования и платежные извещения. В накладных указывается, кому, сколько и какого оборудования продано (или куплено). В платежных извещениях – суммы платежей и наименование партнера. Характерно, что в них обычно не указывается, за какое оборудование осуществляется платеж – система управления базами данных должна автоматически перераспределить сумму платежа на оборудование указанного в накладных, в соответствие с обычным правилом оплачиваются самые ранние накладные по мере их поступления.
Единицей хранящейся в БД информации является таблица. Каждая таблица представляет собой совокупность срок и столбцов, где строки соответствуют экземпляру объекта, конкретному событию или явлению, а столбцы – атрибутом (признакам, характеристикам, параметрам) этого объекта, события, явления. Ниже приведен пример таблицы, в которой содержится сведения о продаже товара со склада. Столбцы описывают, какие параметры, как дата продажи, название проданного товара, наиме6нование покупателя, количество проданного ему товара. Каждая строка держит сведения о кон6кретном событии – продажи товара покупателю. В терминах БД столбцы таблицы называются полями, а ее строки - записями.
| Дата | Наименование товара | Покупатель | Отпущено, шт. |
| 10.12.2006 | Паровой котел Booster | ООО «Водяной» | 2 |
| 10.01.2007 | Насосы Wilo | ООО «Водяной» | 10 |
| 12.04.2007 | Горелки Olimpia | ООО «Трионика» | 5 |
Рис.8. Таблица товар
Между отдельными таблицами БД могут существовать связи. Например, информации о покупатели в предыдущей таблицы может дополняться в другой таблице.
| Покупатель | Адрес | Телефон |
| ООО «Водяной» | г. Екатеринбург, ул. Ленина 28 | 8 (343) 210-10-10 |
| ООО «Трионика» | г. Екатеринбург, ул. Гагарина 10 | 8 (343) 220-20-20 |
Рис.9. Таблица покупатели
Базы данных, между отдельными таблицами, в которых существуют связи, называются реляционными (от relation – связь, отношение).
Связанные отношениями таблицы взаимодействуют по принципу главная (master) – детальная (detail). В нашем примере таблица 2, отпуска товаров – главная, а таблица 3 покупателей – детальная. Главную таблицу часто называют родительской, а детальную дочерней. Одна и та же таблица может быть главной по отношению к одной таблице базы данных и дочерней по отношению к другой.
В каждой таблице базы данных может существовать первичный ключ – поле или набор полей, однозначно идентифицирующий запись. Значение первичного ключа в таблице базы данных должно быть уникальным, то есть в таблице не должно существовать двух или более записей с одинаковым значением первичного ключа.
Первичные ключи облегчают установление связи между таблицами. В таблице 3 таким ключом может быть одноименное поле. Установив связь по первичному ключу, мы можем выяснить, что, например 10.12.2001 года со склада было отпущено 50 единиц «Паровых котлов BOOSTERCOLTD» покупателю ООО «Водяной», который расположен по адресу: г. Екатеринбург, ул. ул. Гагарина 10, контактный телефон 8 (343) 220-20-20, E-mail:. Vodyanoy @.ru.
Поскольку первичный ключ должен быть уникальным, для него могут использоваться не все поля таблицы. В приведенном примере название покупателя вряд ли может быть уникальным (ООО «Водяной» может существовать не только в Екатеринбурге, но и в любом другом городе), поэтому поле покупатель не может использоваться в качестве первичного ключа. Значительно более редким является совпадение телефонов у двух разных покупателей, поэтому поле телефон в большей степени подходит на роль первичного ключа. Если в таблице нет полей, значение которых уникальны, для создания первичного ключа в нее обычно вводят дополнительное числовое поле, значениями которого система управления базами данных может распоряжаться по своему усмотрению. Если, например, в таблицу добавить поле №, то она могла бы выглядеть так:
| № | Покупатель | Адрес | Телефон |
| 1 | ООО «Водяной» | г. Екатеринбург, ул. Лени на 28 | 8 (343) 210-10-10 |
| 2 | ООО «Трионика» | г. Екатеринбург, ул. Гагарина 10 | 8 (343) 220-20-20 |
Рис.10. Модифицированная таблица покупателей
Соответственно изменилась бы и связанная с ней таблица отпуска товаров.
| Дата | Наименование товара | Покупатель | Отпущено, шт. |
| 10.12.2006 | Паровой котел Booster | 1 | 2 |
| 10.01.2007 | Насосы Wilo | 1 | 10 |
| 12.04.2007 | Горелки Olimpia | 1 | 5 |
Рис.11. Таблица отпуска товара
Теперь в таблицы отпуска товаров в поле покупатель указывается значение первичного ключа, построенного по полю № таблицы покупателей, что позволяет установить однозначную связь между таблицами.
Индексы отличаются от первичных ключей тем, что не требуют непременной уникальности значений входящих в их состав полей. Они устанавливаются по полям, которые часто используются при поиске и сортировке данных: индексы помогут системе значительно быстрее найти нужные данные или отсортировать их в нужной последовательности.
После анализа особенностей автоматизируемой области деятельности, следует приступить к, возможно, самому важному этапу – проектированию будущей базы данных, которая заключается в определении состава полей ее таблиц и связей между таблицами. От того, насколько тщательно проведен анализ и насколько грамотно спроектирована база данных, то этого зависит эффективность будущей системы управления базами данных и ее полезность для пользователя.
В нашем случае анализ показывает, что в базе данных должно быть, как минимум пять таблиц. В таблице FIRMS будут храниться все нужные сведения о партнерах – с указанием юридического адреса, контактных лиц, телефонов и полного названия каждого партнера, в этой таблицы будет храниться суммарный долг каждого покупателя, который называется сальдо. Смотри таблицу 2.