> спецификация IE

Что это за зверь?

> CMDB соответственно (по методологии ITIL) - гвоздь системы - база конфигурационных едениц.

Типа того. Mission: To be responsible for the effective control of assets and support the efficient management of incidents, problems and changes, contributing to the cost effective delivery of quality services in the face of changing needs.

Задачу более конкретно сформулируйте. Полноценную CMDB для диплома писать - imho слишком много работы.

> Information Engineering в смысле

Понятнее не стало. Ссылку на спецификацию можно? С пояснениями, при чем здесь ITIL.

> структура БД всегда накатать мона

Полагаете?

> Куда тут конкретнее?!

Вы себе представляете, чем вообще оперирует CMDB? Большую картинку с компонентами ITIL видели? ;) Только для описания эксплуатации железок можно среднего размера базу данных написать. Вопрос-то простой: что нужно для диплома? Показать, что Вы знаете ITIL, реализовать какую-то конкретную спецификацию, показать элементарные связи между компонентами ITIL, описать как можно подробнее какую-то часть? Вы правильно заметили, что CMDB - это каркас. Связи с другими компонентами могут быть очень причудливыми.

Ваш вариант диаграммы - он на уровне концептуальной модели. Если Вашему руководителю этого достаточно - добавьте документирование и можно на этом заканчивать.

> у нас в инете не шибко много рускоязычной информации по этой теме

Да, у нас тоже. Читайте на английском, немецком, испанском, фразцузском, - что удобнее.

> самое главное чтоб концептуальный подход был

Так ITIL и есть концепция. ;) Что значит "концептуальный подход к концепции"? ;)

> вопрос - такая концептуальная схема подходит?

Концептуальной я ее назвал в том смысле, что подавляющее большинство сущностей, которые Вы используете, можно разбить на элементарные. Это не концептуальная схема в традиционном понимании.

На вопрос "подходит ли" ответить невозможно: нет начальной постановки задачи. А с точки зрения концепции ;) imho нет главного. Попробуйте взглянуть на схему со стороны. Что должно быть? Есть некое событие или сообщение (запрос, инцидент - не важно). Оно регистрируется в базе данных. У него есть связи с другими сущностями базы данных. В ответ на это событие (сообщение) может быть сгенерировано другое событие (сообщение; или последовательность событий (сообщений)), у которого тоже есть связи с другими сущностями. Эти события (и начальные, и сгенерированные) могут сопровождаться документами (вообще говоря, разного вида и формы; это к вопросу о документировании). Ваша база данных (ну, не Ваша, а CMDB) должна выполнять роль набора атрибутов связей для таких сообщений. Предложенная Вами структура данных хм... ну очень неудобна для этого. Придумайте несколько сообщений, близких к реальным, и Вам это станет очевидно.

> не собираюсь тут с HP OV тягаться

А что, это типа эталон? ;)

> имелось в виду, что база будет соответствовать ITIL (т.е. построена по этой
> методологии

Соответствует ли база данных ITIL - это политический вопрос. ;) Во-первых, об этом нельзя судить по одной компоненте. Во-вторых, даже и плохо спроектированная структура данных вполне может соответствовать ITIL.

> "характеристики типа оборудования"

Я бы на Вашем месте этого не делал.

> Почему?

Потому что велика вероятность закопаться в этом по уши. В типизации интерфейсов и совместимости, например (с учетом, вообще говоря, версий firmware). В регистрации багрепортов вендоров. Да много в чем. Так что imho если нет необходимости, лучше "характеристики типов оборудования" не трогать. Любое усложнение схемы - потенциальная дыра для дополнительных вопросов. ;)

> связи наверное неправильно построил

Да нет, явных ошибок на первый взгляд нет. Поищите готовые схемы CMDB; в пиринговых сетях должны быть. Сравните с Вашей схемой.

> почему такая схема не удобна

Я был должен явно добавить "in my humble opinion".

> Готовых нет

Извините за столь интимные подробности, но где-то год назад видел в ED2K две разных схемы. В виде pdf файлов с ER-диаграммой. Имен, к сожалению, не помню, но нашлись они легко; значит, либо ITIL, либо CMDB в названии упоминались. Одна схема совсем простая, вторая чуть сложнее. Вряд ли они одномоментно исчезли. ;)

> пытаюсь выяснить что конкретно не понравилось

Посмотрите на Вашу схему с точки зрения управления. Основная часть схемы - requests: линейная классификация; нет возможности задать конфиг; нет возможности связывания. Про пользователей как-то и говорить неудобно: вообще ничего нет. Ни штатного расписания, ни групп, ни ролей.

Сергей Орлик год или два назад перевел SWEBOK. Думаю, ссылка на эту работу есть в его блоге (ну, или googl'ом достаточно просто найти). Думаю, Вам будет полезно ее полистать. И еще, наверное, будет интересно посмотреть в том же google PMBOK+ITIL+mapping.

> я там еще поищу

Кстати, там по ITIL довольно много материалов было в свое время.

> что такое штатное расписание?

Предприятия - подразделения - сотрудники. Стандартная задача.

> Тут я вообще без коментариев

Кратенько резюме: PMBOK - управление проектами; несмотря на казалось бы абсолютно разную область применения, много общих моментов с ITIL.

Вот поэтому я и просил задачу сформулировать более конкретно. ;)

На самом деле imho даже весьма общее представление о стандартах, нотациях, рекомендациях и пр. - в кассу. И на защите сможете порадовать комиссию, да и в работе пригодится. Так что время потратили не зря. Успешной защиты.

> Защитил

Поздравляю.

> результат - простенькая БД

Важно, что теперь Вы понимаете, для чего это нужно и как это должно работать. А сложность - штука субъективная. ;)