Отправляет email-рассылки с помощью сервиса Sendsay

Создаем свой бизнес

Рассылка закрыта

При закрытии подписчики были переданы в рассылку "Секреты бизнеса. Предприниматели рассказывают..." на которую и рекомендуем вам подписаться.

Вы можете найти рассылки сходной тематики в Каталоге рассылок.

←   Июль 2005   →
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
Автор
Людмила Лунькова

Статистика

12.222 подписчиков
-21 за неделю
←   Все выпуски   →

Создаем свою информационную систему


Информационный Канал Subscribe.Ru

Создаем свою информационную систему

Выпуск 7.

Пришло много писем… И хочется начать с известной притчи.

 

Приятель Ходжи Насреддина как-то раз пришел к нему посоветоваться о деле. Изложив ему все, приятель в конце спросил: “Ну как? Разве я не прав?”
Ходжа заметил: “Ты прав, братец, ты прав…” На следующий день ничего не знавший об этом противник также пришел к Ходже. И он также рассказал ему дело, разумеется, в выгодном для себя свете.
“Ну, Ходжа, что ты скажешь? Разве я не прав?” – воскликнул он. И ему Ходжа ответил: “Конечно, ты прав…”
Случайно жена Насреддина слышала оба эти разговора и, вознамерившись пристыдить мужа, воскликнула:
“Эфенди, разве могут быть правы одновременно и истец и ответчик?”
Ходжа спокойно посмотрел на нее и сказал: “Да, жена, и ты тоже права…”

 

И Вы все правы. Мир крайне сложная штука. Но проблема не в этом.  Если у нас слишком много свободы, то очень часто оказывается, что мы просто не в состоянии сделать выбор, который приведет нас к правильному решению. Хочется всего и сразу. Это обыкновенная жадность и не надо её стесняться. Но выход искать надо. Поэтому мы просто вынуждены отказаться от движения по некоторым координатам. Тогда может оказаться, что не такое уж у нас бесконечное количество вариантов. Пока я предлагаю зафиксировать хотя бы самое общее архитектурное решение. И буду поступать также и в дальнейшем. Вы же должны понимать, что мы идем к конкретной реализации, а значит, от нашей свободы выбора, в конечном итоге, не останется ничего. Все «выборы» будут сделаны по мере продвижения по пути.

 

Нет… по мере прихода писем, понимаю, что все-таки правы не все.  Ну, вот спрашивает человек. Зачем, про генераторы разговаривать.  Приведите мне пример, хоть одной системы, которая их использует...

 

Знаете, какая аналогия приходит в голову. Приходит к братьям Райт человек и говорит: Ну, давайте, покажите мне хоть один аппарат тяжелее воздуха, который бы мог летать…   Ну, да откуда же взяться аппарату, если никто еще не летал. А теперь представьте, что у них в ангаре стоит готовый и испытанный самолет. Ну и кто это человек в их глазах? Правильно, полный ______________. (слово вставьте сами).

 

Но ситуация еще хуже. Мы с моим давним товарищем как раз на эту тему спорили. Понимают ли программисты, что все компиляторы, с которыми они работают, на самом деле и есть генераторы кода, или не понимают. А метаданными для этих генераторов являются программы, которые эти программисты сами и пишут. Вот и ответ. Понимают далеко не все.

 

Все хватит беллетристики.

 

Сегодня начнем разговор про самый нижний уровень. Собственно первое прощание с полной свободой.

 

ТС1-1  В базе данных идентификация строки данных должна однозначно осуществляться по паре  значений (Таблица, Значение поля- идентификатора).  

 

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

 

Сильные и слабые связи.

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

 

 

ТС1-2  Реализация сильных и слабых связей в базе данных должна существенно отличаться.

 

ТС1-3  Таблица может являться дочерней для одной и только для одной таблицы.

 

ТС1-4  Для сильных связей должен обязательно использоваться механизм встроенного контроля целостности ( внешние ключи)

 

Я понимаю, что трудно себе представить, о чем идет разговор. Но суть вот в чем. Каждый документ (или объект, если кому-то так больше нравится)  в системе представляет собой некую иерархию. Фактически речь идет о древовидной структуре (ТС1-3 ).  Мы как-бы разрезаем базу данных  на несколько сегментов. Каждый сегмент является отдельной более или менее самостоятельной сущностью. Древовидную структуру разрушить нельзя (ТС1-4), она остается целостной.  Это даст нам возможность на уровне объектных моделей  четко формализовать доступ к данным документа.

 

 

Из этих требований вытекают  требования к метаданным

 

ТМ1 Основной единицей описания является документ

 

TM2 Метаданные должны позволять описывать иерархическую структуру документа

 

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

 

 

Я думаю, что на сегодня мы закончим это выпуск, а в следующем посмотрим на пример реализации  какого-нибудь документа на уровне базы данных.

Ведущий рассылки: Михаил М. Баранов
bami@realbh.ru www.realbh.ru
Subscribe.Ru
Поддержка подписчиков
Другие рассылки этой тематики
Другие рассылки этого автора 		Подписан адрес:
Код этой рассылки: comp.soft.prog.murometz2 		Отписаться
Вспомнить пароль
В избранное