Причины создания УБД
	Банников Н.А.	www.stikriz.narod.ru	Почта	На главную страницу

Краткое описание существующих баз данных

Базы данных нужны человеку для систематизации своих знаний. На основе этой систематизации он может создать новые знания. Так или иначе, любая база данных служит человеку именно для описания происшедших в прошлом событий и на основе знания этих событий помогает принять то или иное решение на будущее. Поясним эту мысль примерами. Начнем с простых случаев. К примеру, описание склада необходимо для знания наличия на складе товаров на основе ввода движения товара на склад и со склада. Иначе, человеку пришлось бы постоянно сверяться с реальным наличием, т.е. пересчитывать товар по нескольку раз на день перед выписыванием исходящей накладной. Как дополнительная и нужная функция может рассматриваться возможность статистического анализа расхода товара со склада по месяцам. К примеру, есть сезонные колебания расхода медикаментов. На основе таких наблюдений можно прогнозировать план закупок. Бухгалтерские программы позволяют в простейшем случае правильно заплатить налоги. Здесь мы видим классический пример генерации новых знаний, а именно о финансовом состоянии организации, на основе обработки проводок. Более сложным является случай рассмотрения баз знаний. База знаний может быть построена как мультимедийный справочник или как набор текстов и файлов другого формата, проиндексированных по определенным признакам в базе данных. Здесь стоит немного отвлечься и дать определение базы данных в моем понимании этого вопроса. База данных - это набор файлов определенного формата? Да, но не только. База данных - это средство доступа к таким файлам? Да, но не это главное. По моему мнению, база данных - это, прежде всего, хранилище объектов данных, т.е. набора возможных понятий или событий, описываемых базой данных, с возможностью поиска этих объектов по признакам. Неотъемлемой чертой базы данных является возможность связывания объектов между собой. Например, шапка накладной и ее содержание (включение), ИНН и реквизиты организации (ссылка), т.е. уникальное значение в одном из столбиков таблицы и одно или несколько значений из другой таблицы. Такие связи принято называть нормализацией базы данных, но об этом позже. Так вот, это лирическое отступление было мне необходимо для пояснения примера о базах знаний. Я считаю, и думаю, что Вы согласитесь, что базой данных можно считать не только таблицы, индексирующие файлы со знаниями разных форматов, но и сами эти файлы, потому, что они являются не типизированными хранилищами знаний в такой базе данных. Итак, в базах знаний мы накапливаем опыт прошлого. Потом человек может сам принять решение на основе этого опыта (типичный случай с мультимедийным справочником) или поставить задачу перед базой данных по поиску решения согласно сложившейся ситуации (найти закон, поясняющий правило оформления таможенной декларации и т.п.). Так происходит в программах справочного характера, например "Консультант плюс" и т.д. Как частный случай баз данных, можно рассматривать различные структурированные файлы, например словари для переводчиков, форматы файлов RTF, DOC, книги Microsoft Excel, файлы с письмами для почтовых Internet программ и т.д., жизненно важные функции баз данных, в которых реализуются за счет внутренних функций программ работающих с ними. Базы данных могут применяться как вспомогательное средство, позволяющее реализовать какую-то полезную функцию. Например, хранение настроек программы (реестр Microsoft Windows), Internet адресов для рассылки рекламы и т.д. Итак, мы рассмотрели различные базы данных. Этих примеров достаточно, чтобы оценить диапазон применений баз данных в современном мире. В дальнейшем, нас будет интересовать вопрос построения баз данных для принятия решений на основе хранящихся знаний в базе данных о прошлом. Это целый ряд бухгалтерских, складских программ, базы знаний, каталоги и т.д. и т.п.

Структура информационных систем.

Для построения информационных систем применяются базы данных, созданные вокруг ядра базы данных. Ядро реализуется вокруг прикладного API серверов баз данных или драйверов, например BDE фирмы Borland. Почему программисты строят свои базы данных именно таким образом? Этот вопрос скорее риторический. Дело в том, что работа с базой данных происходит, как правило, в многопользовательском режиме, т.е. программа должна быть сетевой. В связи с этим, необходимо обеспечить разделение прав доступа различным пользователям к данным, правильность завершения транзакций, т.е. ссылочную целостность, ограничения и другие правила, реализуемые через встроенные средства сервера базы данных. К тому же, должна быть обеспечена приемлемая производительность информационной системы. Это очень непростая задача, при реализации которой потребуется не одна тысяча человеко-часов труда программистов. К счастью, нет необходимости решать эту задачу снова и снова. Велосипед был однажды изобретен. Теперь программисты используют стандартные средства доступа к базам данных. Итак, в центре всей информационной системы стоит сервер базы данных. Он обеспечивает низкоуровневый доступ к таблицам базы данных, в которых и хранится информация об объектах базы данных. Ядром информационной системы в простейшем случае могут выступать несколько функций, реализованных в программе программистом. В современном мире чаще всего применяется сервер приложений для реализации ядра информационной системы. В распределенной вычислительной системе сервер приложений берет на себя функцию распределения нагрузки между серверами, которые в общем случае могут работать под разными операционными системами, или находится в разных географически местах. Сервер приложений - это мостик между программами-клиентами и одним или несколькими серверами базы данных. За счет сервера приложений можно снизить нагрузку на приложения пользователя и реализовать сложные правила объектной модели базы данных, которые трудно или нерационально реализовывать на стороне сервера базы данных. В результате, сервер приложений снижает трафик между сервером базы данных и компьютером клиента, повышая общую производительность информационной системы. Исходя из сказанного ранее, на приложение пользователя остается только реализация интерфейса. Такая структура информационной системы называется многозвенной, а приложение пользователя - тонким клиентом. Надо отметить, что в общем случае серверы приложений могут посылать команды друг другу, и взаимодействовать, таким образом, самым рациональным способом с географически удаленными серверами баз данных. Например, для получения отчета с большим количеством вычисляемых полей, нет необходимости делать несколько запросов к удаленной базе данных через Internet, если это может сделать сервер приложений, находящийся в непосредственной близости от сервера базы данных. Он и пошлет в ответ готовый отчет. Таким образом, только информационная система, построенная по принципу многозвенности, может удовлетворять наиболее полным образом условиям наивысшей производительности при полной коммуникабельности и распределенности вычислений. Система, построенная из нескольких отдельных модулей, выполняющих ряд определенных задач, к тому же, может быть проще модифицируемой. Так, при переходе на новую операционную систему пользователя, проще перекомпилировать только приложение пользователя, чем перекраивать весь проект. Или при необходимости добавить новую функцию, можно дополнить проект информационной системы, новым сервером приложений, не переделывая остальной части проекта. И т. д. и т.п.

Необходимые функции базы данных

Первой и самой важной функцией базы данных, является функция хранения информации. Информация должна хранится упорядоченно. Это необходимо для более быстрого и понятного пользователю доступа к ней. Упорядоченность информации в базе данных, помимо удобств доступа, может привести к значительному сокращению аппаратных ресурсов, необходимых для ее обслуживания. Упорядоченность достигается путем нормализации. Существуют пять уровней нормализации, но при определенных условиях достаточно соблюсти третий уровень нормализации, чтобы остальные уровни получились сами собой. Поясним это на примерах. В каждой базе данных должна быть хотя бы одна таблица, содержащая главный документ, например список накладных в программе оптовой торговли. Эта таблица имеет записи, ассоциируемые с шапками накладных. Т. к. не может быть двух абсолютно одинаковых накладных, то можно выделить столбики таблицы, которые в своем сочетании не похожи ни при каких обстоятельствах. Это могут быть, к примеру, дата, номер и поставщик для входящих накладных. Мы можем создать в такой таблице первичный ключ по этим полям. Теперь мы никогда не спутаем две накладные. В понимании нашей программы они будут разными, и если мы попытаемся завести накладную повторно, то получим сообщение об ошибке. Далее, мы будем заносить накладные от поставщиков, которых у нас ограниченное количество, во всяком случае, меньше, чем входящих накладных, значит поставщики могут повторяться. Не имеет смысла каждый раз в шапке накладной записывать все реквизиты поставщика (ИНН, банк, Кор. Счет и т.д.). Есть смысл вывести эту информацию в другую таблицу. Тогда нам достаточно только один раз завести информацию о поставщике, а потом только выбирать нужного поставщика из справочника. Это упростит наш труд, не говоря уже об экономии многих мегабайтов дискового пространства. Занося в справочник реквизиты организаций, мы скоро поймем, что эту же информацию можно использовать и для других целей, например, для формирования платежных поручений. Но платежи мы можем посылать не только поставщикам, а и в налоговые органы, и другим организациям за оказанные нам услуги, например, за коммунальные платежи. В скором времени, У Вас накопится множество организаций, которые не являются Вашими поставщиками. Поэтому есть смысл как-то отделить поставщиков от остальной части организаций. В терминах баз данных нам нужно создать новую таблицу, в которой мы будем хранить ссылки на поставщиков из таблицы с организациями. Это сократит затраты труда на поиск нужной организации. В новоиспеченной таблице можно хранить условия контракта, например срок отсрочки платежа, что характерно для поставщиков, но нехарактерно для организаций в целом. Далее, в каждой накладной есть список товара. Мы не знаем, сколько строчек займет весь список. В одной накладной их двадцать, в другой сто, или вообще одна. Поэтому список товара нужно хранить в отдельной таблице. Такое отношение называется одна ко многим, т.е. включение. Здесь нам и пригодится первичный индекс, созданный для шапок накладных. Такие же рассуждения можно применять и далее при построении базы данных. В результате, мы получим базу данных, состоящую из нескольких таблиц, в которых нет повторяющихся полей, кроме ссылок на другие таблицы. К тому же нам не придется дублировать ввод информации в базу данных. Поэтому работа с такой базой данных будет более осмысленной и предсказуемой, что важно для пользователя. Здесь мы вплотную подошли ко второй функции базы данных - ввод информации. Какую информацию будет вводить пользователь? Хорошая база данных построена из главного документа, справочников, из которых пользователь вводит информацию и нескольких полей для ручного ввода, например, текстов назначения платежа в платежных поручениях и суммы. База данных должна заполняться средствами, наиболее полно автоматизирующими этот процесс. Плохим тоном является ввод информации об одном объекте разными способами или в разных местах. Плохим тоном является ввод одной и той же информации в нескольких местах. Плохим тоном является ввод информации разрозненно, без поддержания общей структуры объекта. Дополним эти утверждения примерами. Представьте, что Вы заполняете шапку накладной. Вам нужно выбрать поставщика. Вы открываете справочник, а еще хуже, выпадающий список, а там нет нужного поставщика. Интерфейс должен давать возможность вставить нужного поставщика, не выходя из формы для ввода шапки накладной, иначе, при правильном построении ссылочной целостности программа запретит закрыть редактор без указания поставщика, и часть работы будет потеряна. Есть программы платежных поручений, которые не могут формировать сумму прописью. Пользователь уже ввел числовое значение суммы, а затем вынужден вводить еще и сумму прописью. Это плохо. А теперь перейдем ко всем знакомым Microsoft Excel. Вы можете ввести наименование товара, а затем должны выбрать ему единицу измерения. У каждого наименования должна быть прикреплена раз и навсегда единица измерения. Т.к. это одна из характерных характеристик товара. Из всего сказанного, становится понятно, что форма для ввода данных должна отслеживать наступление определенных событий и выполнять часть работы по вводу данных самостоятельно. Это может быть, к примеру, подсчет общей стоимости товара исходя из уже введенной цены, количества и процента наценки. И наоборот при изменении суммы, менять процент наценки. В последнее время, в связи с появлением богатых возможностей пользовательского интерфейса операционных систем, таких как Microsoft Windows или Mac Os, есть возможность закрепить в понимании пользователя действия над базами данных с ассоциациями таких же действий в реальном мире. Например, вставку товара в накладную можно организовать как процесс перетаскивания наименования товара из справочника товаров в накладную, что похоже на реальные действия кладовщика по перемещению товара на складе с полки в тару. Распространенной ошибкой является понуждение пользователя вводить всю информацию об объекте в одной форме. Я видел программу, которая заставляла пользователя вводить информацию о технологическом процессе в одной форме. Я насчитал более сорока полей ввода, оформленных разными цветами, на панелях с разной фактурой, к тому же внизу формы была еще одна таблица для ввода включаемой информации. Всегда лучше позволить пользователю вводить простые типы данных, такие как строчки, цифры, вычисляемые поля прямо в таблице, а такие данные как тексты, картинки, OLE объекты в отдельных формах для редактирования, тогда не только ускорится работа, но и меньше системных ресурсов будет необходимо приложению пользователя для выполнения операции редактирования данных. Однако, я согласен, что при вводе новой строки в таблицу бывает полезно создавать специальную форму, в которой будут указываться критичные к ссылочной целостности данные. Можно и запрещать пользователю перемещаться на другую строчку таблицы при неполном заполнении ее с выводом соответствующего сообщения об ошибке. К средствам редактирования относятся функции создания документов на основе шаблонов или копии уже созданного документа. Так проще создать платежное поручение на основе уже имеющегося, а затем исправить несколько полей в данных, и сохранить новый документ. Одной из основных функций базы данных является автоматизация. Под автоматизацией, как правило, понимают автоматическое создание выходных документов и пересчет данных, например печать накладной, счета фактуры и протокола согласования цен в складской программе для исходящей накладной. Или построение сверки на основе входящих накладных и платежных поручений для поставщика. Далее, нужно вспомнить о системах принятия решений. Информационная система должна позволять создавать статистические отчеты в реальном режиме времени о состоянии описываемого в базе данных процесса. Эта функция удобна для руководителей подразделений, которые могут прогнозировать поведение описываемой системы на основе статистических данных, полученных из базы данных. Собственно, описанные выше функции информационной системы являются джентльменским набором, которого достаточно в большинстве случаев. Из дополнительных функций необходимо упомянуть возможность поиска по нескольким взаимосвязанным характеристикам, например поиск платежного поручения по получателю и дате большей определенной. В единой информационной системе необходима возможность идентификации пользователя с целью ограничения доступа пользователя к определенным частям базы данных и введения информации о создателе документа и лиц, редактировавших его. Это придаст пользователям ощущение ответственности за выполняемые действия. Хорошая информационная система должна легко расширяться при необходимости добавления в нее новых возможностей. Расширяемость подразумевает элементы объектной ориентированности, встроенные в базу данных. Так, в бухгалтерской программе фирмы 1С есть ряд объектов, доступных для настройки, которые реализуют ядро базы данных. Настраивая эти объекты возможно вносить незначительные изменения в структуру базы данных, что продляет срок морального устаревания всей информационной системы. Одним из факторов расширяемости является возможность сочленять разнородные базы данных в единый комплекс. Такая возможность сейчас реализуется через дополнительные модули, которые по своей сути являются серверами приложений, или правильное построение базы данных по классическим реляционным законам. Последний случай затрудняется тем, что некоторые серверы базы данных не могут выполнить один SQL запрос к разным базам данных, тем более находящимся в географической удаленности друг от друга. Есть еще одна удобная функция в хорошей базе данных - это сквозное прохождение по документам. Например, Вы нашли нужный товар на складе, и удивились, что его осталось так мало, несмотря на недавнюю поставку. Программа должна позволять прямо из этого места посмотреть движение товара. Допустим, Вы нашли накладную, по которой было отгружено подозрительно много товара. Прямо из этого места Вы должны иметь возможность увидеть весь список накладной или просмотреть реквизиты получателя и реквизиты банка получателя и т.д. по цепочке. Для систем документооборота жизненно важным являются функции сохранения старых версий документов и истории прохождения документа в организации. Эта возможность не так тривиальна, как может показаться на первый взгляд. Приведем классический пример, который поставит в тупик большинство систем документооборота. К примеру, до перестройки партийность хранилась в булевом поле. Да - партийный (КПСС), нет - беспартийный. После перестройки партийность стала выбираться из списка или из справочника партий. Такое изменение в структуре базы данных вызовет необходимость написания новой программы в большинстве систем документооборота и полной потере информации о прошлой партийности. Или, к примеру, сотрудница вышла замуж и поменяла фамилию. Куда поместить ее старую фамилию? В правильных системах документооборота можно было бы создать новую папку с новыми документами в случае с партийностью и закрепить за новой учетной карточкой отдела кадров ссылку на старую в случае с фамилией. Такие изменения возможны только в программах с настраиваемой базой данных. Описанные выше функции в разных реализациях информационных систем имеют специфические черты, ориентированные на конкретное прикладное применения. Здесь рассматривались общие черты этих функций, поэтому я не претендую на полное их описание, однако показанное здесь не всегда реализовано в полном объеме в подавляющем большинстве программ.

Теоретические размышления об объектной ориентированности.

Весь мир, как бы, движется в сторону объектной ориентированности. Что же в ней такого привлекательного? Объектная ориентированность подразумевает наследование. Наследование - это возможность создания потомка от родителя, а значит и доступа к свойствам объекта потомка через описание свойств родителя, в случае с базами данных (полиморфизм). Процедура наследования - это возможность создания нового объекта из уже существующего путем добавления новых черт, присущих потомку поверх или в дополнение к существующим чертам родителя. Процедура наследования происходит один раз при создании объекта. Далее при создании новых записей используется описание этого объекта. Созданные записи не что иное как экземпляры, т.е. записи с полями, описанными в описании объекта. В данном случае рассматривается простое наследование. И я приверженец именно такого наследования, т.к. вместо создания объектов из двух и более родителей проще использовать включение. Включение может вылиться либо в ссылку (вычисляемое поле), либо в отношение один ко многим. Такая конструкция более подходит к базам данных, т.к. удовлетворяет реляционной модели. Одна из черт объектной ориентированности - это инкапсуляция. Методы объектов пригодятся для закулисной работы во время вставки и редактирования записи. Например, пересчитать сумму заказа при указании цены и количества, начальной инициализации полей при создании новой записи. Это все про наследование. Многие производители серверов баз данных декларируют присутствие объектной ориентированности в своих продуктах, но программисты не спешат использовать эти возможности. Почему? Дело в том, что практика показала, что это только маркетинговый трюк и не более того. К тому же трюк весьма запутанный и сложный в использовании. Самое большее, что могут такие серверы - это более быстрое создание новых таблиц на основе описания уже существующих. Чтобы не быть голословным, я приведу пример запроса к базе данных, который полностью возможен в объектно - ориентированной базе данных, и, по крайней мере, мне неизвестно, чтобы его можно было применить к какому-нибудь серверу баз данных. Допустим, Вы пришли в библиотеку, и хотите найти информацию о паровозах. В библиотечном каталоге хранятся карточки о статьях, журналах, книгах, выступлениях ораторов. В не объектно - ориентированной информационной системе, Вам придется произвести поиск по интересующей теме отдельно по всем возможным типам литературы. В объектно - ориентированной информационной системе, Вы выберете из всех типов данных тип литература, заполните поле тема словом паровоз, укажите, что нужно произвести поиск в потомках, и в ответ получите статьи, журналы, книги и выступления ораторов на эту тему. А теперь задание усложняется. При появлении, скажем в результате настройки программы (а без такой возможности Вам не удастся реализовать наследование, значит программа по определению не объектно - ориентированная) нового типа - сайт в Internet, Вы сможете без перекомпиляции программы выполнить такой же запрос, включая и по Internet. Вот более насущный пример использования наследования. Допустим, Вы прекратили все отношения с нерадивым поставщиком. Неплохо бы было отправить все документы, связанные с ним в архив. В объектно - ориентированной информационной системе Вы можете выбрать тип офисный документ с поставщиком, заполнить поле поставщик, и найти все документы, связанные с этим поставщиком, после чего отправить их в архив. Из всего выше сказанного понятно, что объектная ориентированность не является такой уж ненужной вещью. Кроме облегчения процесса настройки программы, она позволяет сократить трудозатраты пользователя. Но объектная ориентированность - это не только наследование. Далее я хочу поделиться с Вами моим пониманием теории двух Смитов.

Теория двух Смитов.

К теории двух Смитов я пришел самостоятельно - это недостаток моего образования, поэтому далее я буду повествовать в терминах, применяемых мной - так мне будет удобнее. К тому же моя идея более ориентирована на прикладную реализацию. До того, как я познакомился с рассуждениями Смитов, я называл свою теорию социальной, потому, что она идеально подходит для описания строения социумов, или нейронной, потому, что она представляется мне в пространстве как сгусток нейронов мозга.
Мы будем оперировать понятиями модели, типа, свойства, типа свойства или низкоуровневым типом свойства. Рассмотрим, для начала, простой пример с видеокамерой. У видеокамеры есть три светофильтра, которые, в идеале, могут пропускать только красный, синий и зеленый свет. Достаточно двадцать пять раз в секунду снимать информацию об отраженном свете от предмета, чтобы дать полную информацию о движении, цветовых свойствах этого предмета и освещенности окружающей среды. Применительно к базом данных, можно построить аналогию с таблицей, в которой есть три столбика с числовым типом. Пользователь вводит информацию о красной, синей и зеленой составляющей, тем самым, полностью описывая нужные нам свойства предмета. Эти столбики в сочетании с опытом работы пользователя (нужно, чтобы он не был дальтоником), как бы являются светофильтром. В них мы проецируем реальные свойства предмета, и получаем упрощенную модель предмета реального мира. Упрощения могут быть очень забавными, и зависят не от действительных свойств предмета, а от нашей потребности в описании предмета. Так, для описания человека, нам достаточно знать его Ф. И. О., год рождения, пол, род занятий, а не формулу его ДНК, а значит и строение его организма. Итак, нам необходимо хранилище связанных свойств, в которых мы будем описывать предмет реального мира по определенным нами же правилам, которые могут принимать самые разнообразные значения. С такой задачей хорошо справляется таблица базы данных. Она может хранить любые цифровые, строковые, текстовые, бинарные и т.д. данные. Итак, мы пришли к понятию типа, который содержит описание нескольких свойств, достаточных нам для описания необходимых свойств предмета или события реального мира, т.е. объекта.
Объект - наше понимание события или предмета реального мира, описанное нами в типе с помощью применения к нему упрощений, т.е. описания свойств объекта через свойства типа.
Тип - набор описаний свойств объекта, как мы их себе представляем. Это описание и есть переход от реальности к виртуальности объекта, или проецированием события или предмета реального мира в виртуальное пространство базы данных.
Свойство - выделенное нами характерное свойство объекта, достаточное для удобного нам восприятия объекта.
Это неформальные описания понятий, а теперь опишем их же с точки зрения программиста базы данных.
Объект -входные или выходные данные, воспринимаемые пользователем, и трансформируемые им либо из реально происшедшего события или существующего предмета в экземпляр типа (запись) базы данных, либо наоборот из экземпляра типа базы данных в действие, документ или другой предмет или команду, существующую в реальном мире.
Тип - описание правил создания экземпляра типа в базе данных, состоящее из описаний возможный значений свойств типа и правил работы с ними. Это неполное описание, т.к. мы пока не дошли до объектно - ориентированных свойств типа.
Свойство - составная часть типа, способная хранить свойства типа, трансформируемая применительно к базам данных в описание столбика таблицы базы данных.
Теперь придадим типу объкектную ориентированность. Тип должен воспринимать события, происходящие с базой данных, с ним можно выполнять определенные действия, выполнять определенные операции в базе данных. Поясним это примерами. При создании типа выполняется конструктор, правильно инициализирующий свойства типа. Например при создании платежного поручения, неплохо задать плательщика по умолчанию. При уничтожении типа вызывается деструктор, который может переместить копию документа в корзину или вообще отменить удаление записи при несоблюдении ссылочной целостности с выдачей соответствующего сообщения пользователю. Свойства типа могут принимать события происходящие при редактировании, например, нажатие и отпускание клавиши, переход фокуса ввода, вставка ссылки из справочника и т.д. Мы можем сопоставить этим событиям методы типа, которые будут автоматизировать ввод данных. Например, проверят выход значения за допустимые рамки, пересчитают сумму заказа исходя из цены и количества и т.д. Тип и свойство должны хранить ссылку на описание предка. Тогда мы сможем организовать полиморфную обработку потомков.
По моему мнению, люое свойство объекта можно описать небольшим количеством типов данных. Вот эти типы: ссылка, целое число, дробное число, строка, текст, бинарный тип, логический тип, дата, время, дата и время. Но средствами интерфейса пользователя удобно расширить этот список еще несколькими типами: форматированный текст, картинка, OLE обьект, денежный тип. Список можно расширять и дальше. О ссылке будет рассказано позже. Сейчас достаточно понять, что ссылка указывает на свойство другого типа и представляется пользователю как вычисляемое свойство.
Теперь, немного ассоциаций. Возьмем, к примеру, объект машина. Машина состоит из корпуса, двигателя, колес и т.д. Колеса состоят из обода, покрышки, камеры и т.д. Камера состоит из сбственно резиновой камеры и нипеля, нипель состоит : Здесь мы столкнулись с понятием модели. Модель состоит из нескольких типов, связанных между собой. Есть два способа связи. Первый организуется за счет ссылок. В типе машина можно создать свойство колесо - ссылка и количество колес - целое число. Колесо является ссылкой на другой тип. Пользователь может вставлять это свойство из справочника. Хотя, я бы создал тип ходовая часть и использовал его в типе машина, тогда можно было бы укомплектовать несколько видов ходовых частей машины двигателями, мостами, колесами, и представить их пользователю как шаблоны. Он, при комплектации машины, выбрал бы нужную ходовую часть. Так же можно поступить и с отделкой корпуса, например. Второй способ - это отношение один ко многим. Возьмем, к примеру, самолет перед взлетом. Вы знаете сколько пассажиров на борту будет? А вдруг кто-то опоздает. Я бы не взлся утверждать, что на борту будут только люди. Может мадам Иванова возьмет с собой любимого бульдога? А на него, кстати, тоже распространяется страховка. Более прагматичный пример. Вы оформляете заказ на ремонт жилого помещения. Нужно предусмотреть стоимость работ и материаллов. Материаллами выступают окна, двери, ролетты, линолеум и т.д. Стоимость ролет, к примеру, может быть посчитана исходя из затрат на ее изготовление и стоимости работы, стоимость окон и дверей аналогично, но окна, двери и ролетты комплектуются из деталей разного типа. Вы можете предусмотреть отношение один ко многим для окон, ролетт и дверей, где каждому окну, ролетте, двери соответствуют материаллы, из которых они изготовлены. Но, пользователь может что-то забыть указать или указать материалл для двери в ролетте. Приемлемым решением будет возможность иметь отношение один ко многим для заказа, в которорый поместить ролетты, двери и окна. У этих типов будут свойства, характерные и бязательные только для них. Итак, мы получили объект заказ, который проецируется в базу данных через модель заказ, которая состоит из типов шапка заказа, ролетта, дверь, окно. В свою очередь, ролетта может состоять из типов направляющие, короб, плащь, аксессуары(замок, пульт дистанционного управления и т.д.), связанных между собой ссылками и отношением один ко многим. Знатоки баз данных скажут, что я пропустил связь многие к одному, но это не совсем так. Ссылаясь на один и тот же плащь Вы можете создать несколько записей с ролеттами.
Действия над типами. Это могут быть самые разнообразные действия. Например, печать, пересчет квартального отчета или отправка факса. Все действия должны быть настраиваемыми для каждого типа отдельно.
Операции в базе данных. Это поиск, копирование, перемещение и т.д. Как правило, действия в базе данных жестко закодированны в программе и являются составной частью интерфейса пользователя, но они трансформируются в зависимости от описания типа. Так, поиск в потомках через свойства родителя возможен благодаря возможности наследования. Или, например, Вы хотите скопировать накладную в архив. Благодаря описанию модели накладной копироваться будет не только строчка с шапкой, но и все записи товара в накладной. Если Вы создадите новую модель, с другими типами, то программа без перекомпиляции и дополнительной настройки сможет проделать такой трюк и с ним, но возможность копирования в принципе закладывается уже на стадии разработки проекта информационной системы. Еще пример полезности объектной ориентированности. Допустим, у Вас есть справочник наименований и модель накладной. Тип строчка накладной имеет свойство наименование, которое является ссылкой на свойство наименование из справочника наименований. Вы можете организовать перетаскивание строчки из справочника в накладную, при этом будет создана новая строчка накладной, в которой наименование будет ссылаться на перетаскиваемую строчку. Такая возможность будет у любого типа сразу после создания, т.к. она запрограммирована в интерфейсе пользователя программистом информационной системы. Дадим последнее определение.
Модель - это тип или сочетание типов, путем связывания, описывающих сложный объект, который невозможно описать только одним типом.
Модели вкладываются друг в друга как матрешки. Например, модель офиса состоит из модели отдела кадров, бухгалтерии и отдела снабжения, бухгалтерия состоит из модели план счетов и справочников, справочники состоят из модели организаций, банки, поставщики и т.д.
Как видите, данные в базе данных должны иметь древовидную структуру. Нет ничего проще создания древовидной структуры данных. Для этого достаточно иметь таблицу с двумя полями: номер записи и владелец. Если Вы хотите вложить в запись другую, то нужно заполнить поле владелец значением поля номер записи, в которую Вы хотите вложить. Так организуется отношение один ко многим. Как видите, это отношение объективно присуще такой базе данных.
В результате мы получили два дерева: дерево наследования и дерево данных. Могу подкинуть ассоциацию. Дерево наследования похоже на иерархию народностей. Так все мы произошли от Адама и Евы, затем народы распространились на земле, некоторые из них породили другие народы, некоторые народы прекратили развитие и, возможно, исчезли. Дерево данных похоже на иерархию государств. Государства состоят из одного или нескольких народов, которые могут смешиваться или мигрировать, образуя новые государства. Государства имеют в своем составе области. Республики, края, штаты. Так в республике может быть несколько автономных областей, которые состоят из округов, которые состоят из районов, в которых проживают народности. Запись в базе данных можно ассоциировать то со всем миром, то с государством, то с республикой, то с народом и т.д., в зависимости от нашей точки зрения.

Концентрация мысли на теории Смитов.

Итак, Объект реального мира проецируется в базу данных через модель, которая может состоять из одного или нескольких типов, связанных между собой отношением один ко многим или ссылками. Типы могут иметь одно или несколько свойств. Свойства являются упрощенным описанием необходимых нам характеристик объекта, достаточным для восприятия пользователем. Тип имеет конструктор для инициализации свойств значениями по умолчанию, а так же деструктор для правильного удаления типа из базы данных. Каждое свойство может иметь методы, вызываемые при наступлении определенных событий при редактировании свойств. Над типами можно выполнять действия, предусмотренные в настройках базы данных. С типами можно производить стандартные операции, предусмотренные интерфейсом пользователя. Все эти возможности позволяют создать любую базу данных и модифицировать ее в дальнейшем исходя из потребностей прикладной задачи или изменений нашего представления об объекте. Все типы входят в дерево наследования и поддерживают полиморфизм и инкапсуляцию. Такая структура базы данных дает ощутимое преимущество, как для разработчиков базы данных, так и для пользователей, потому, что проще в эксплуатации и позволяет работать с данными более осмысленно и предсказуемо, что важно для пользователя.

Единое информационное пространство.

Красивый термин по настоящему не реализованный ни в одной информационной системе. Скорее офисный пакет Microsoft Office или Open Doc обладают этим свойством, чем набор разрозненных таблиц, разрозненных модулей и разрозненных документов, хранящихся в таких базах данных. Если Вы можете в одной программе вставить ссылку из справочника, формируемого в другой программе, то это еще не единое информационное пространство. Вот, если бы в одной программе Вы могли открыть любой документ, созданный в другой программе, и этот документ означал всегда одно и то же, то это и есть единое информационное пространство. Так ведут себя OLE документы. Вы можете в любой OLE документ вставить другой OLE документ, и всегда результат будет предсказуем и корректен. В отношении баз данных, единое информационное пространство должно выливаться в единое адресное пространство. Т.е. все данные должны храниться как бы в одной таблице. Все типы данных должны обрабатываться одними и теми же методами. Все типы отображаться в одинаковых формах, которые, однако, меняют свой внешний вид в зависимости от просматриваемого типа, но не до неузнаваемости, конечно. Единое информационное пространство - это когда Вы можете сидя в офисе получить документ из другой страны и вставить его в свою базу данных не думая о его структуре. А это значит, что с документом Вы должны получить описание модели, которое будет правильно воспринято вашей программой. Короче говоря, нужна база данных, в которую можно вставить любой тип данных. При этом ни количество таблиц, ни их структура не изменятся. Это может показаться парадоксальным, но как говорил А.С. Пушкин, гений (в смысле разум) парадоксов всегда друг. Итак, Единое информационное пространство - это, прежде всего, единое адресное пространство и одинаковая структура базы данных для любого типа, описанного в базе данных. Понятно, что удаленные географически базы данных не могут иметь единое адресное пространство, но можно заставить сервер приложения УБД преобразовывать адреса, как это было в Dos , к примеру, сегмент + смещение.

    Банников Н.А. www.stikriz.narod.ru почта 2000 г.