На основе концептуального проектирования. Концептуальное проектирование систем

Не много стоит построить небоскреб: знаний и умений - достаточно. Много стоит идея такого здания, которую можно реализовать в любых климатических условиях при возможных тектонических движениях земной коры: знаний и умений - будет явно недостаточно при этих (всего двух!), но кардинально существенных, условиях.

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

Статика и динамика систем

Современное концептуальное проектирование - это статика. Условия применения результатов интеллектуальной деятельности человека - это всегда динамика. Сама человека - это непрерывное развитие (динамика).

Сегодня уровень науки, технологий и знаний слишком мал, чтобы создавать динамичные системы. Если человек проектирует самолет: это, как минимум, мотор и два крыла. Если создает престижный автомобиль, то у авто будет кожаный салон и четыре колеса. О подводных лодках, истребителях и космических кораблях вовсе можно не говорить: инерция и жесткая конструкция делают их уязвимыми для любого динамичного, не обязательно «интеллектуального», снаряда.

Каждая новая техническая система - лучше предыдущей. Она впитывает опыт создания предшественниц, нивелирует допущенные ранее ошибки и просчеты. Со статикой результатов интеллектуальной деятельности человека привыкли мириться: другого выхода нет. Допускать допущенные просчеты в концептуальном проектировании новых технических, социальных и иных систем уже не принято.

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

Сбор и анализ информации

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

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

Сбор и анализ информации - это начало социальной или технической системы. Это сама по себе концепция начала работ. Всегда первичная информация собирается и изучается в контексте поставленной цели и решаемых задач. Всегда вторичная информация отражает все те же поставленные цели и задачи. Каждый новый этап - это концептуальное проектирование на новом витке развития знаний о достигнутом и достигаемом: о цели и решаемых задачах.

Статика и жесткое конструирование

Человек не всегда придает объективное значение своей деятельности. Дело вовсе не в том, что он к этому не стремится, просто часто он ставит перед собой одни цели, но достигает другие. Концептуальное проектирование существовало всегда, но «сознательно» человек к этому отнесся только с появлением компьютерной техники и программирования.

Между тем, ассоциации: «концепция = информационная система» не существует. Во всяком случае: об этом свидетельствует современное положение вещей.

Простой пример. Система электронного документооборота организации. Сколько лет создавались такие системы? Сколько таких систем разработано? Сколько научных конференций - состоялось, копий - сломано, бумаги - исписано? По сей день ни один из результатов «концептуального проектирования» систем документооборота не состоялся как концептуально исполненный.

Жесткие конструкции синтаксиса и семантики языков программирования. Четкое понимание, что формализовать динамику области применения и решаемой задачи человек не в силах: знаний и умений явно недостаточно. Результат: всякая модель формализации области применения и требуемой задачи обращается в статическую конструкцию.

Современный мир виртуальных технологий мало чем отличается от пирамиды Хеопса. Изменить что-либо в созданной информационной системе крайне сложно. Любое изменение чревато существенными затратами стороннего труда (разработчика, программиста, автора): сама информационная система ничего «для себя сделать не может».

Объективные законы физического мира

Естественное концептуальное проектирование, как пример создания идеальной системы, существовало всегда. Есть разница между тем, что человек делает, и что он понимает. Пирамида Хеопса не одинока в своем исполнении. Почти километр «изящных» железобетонных конструкций: небоскреб Бурдж-Халифа в Дубай (ОАЭ) - не единственное высотное сооружение. Аналогичных примеров можно привести множество: естественное концептуальное проектирование свойственно человеку, и человек это демонстрирует параллельно в различных регионах планеты в различных сферах социальной, производственной и духовной практики.

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

Теория решения изобретательских задач (ТРИЗ), одно из заметных достижений прошлого века, была выполнена одним человеком, но привлекла внимание многочисленных специалистов, которые развили и использовали ее в реальной практике.

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

ТРИЗ - заметное, но не монументальное достижение. Альтшуллер, Шапиро и тысячи их последователей внесли вклад в теорию, практику и изобретательское дело, но результат «ничтожен»: последователи и правообладатели, фантастические рассказы и статьи о сильном мышлении... в сравнении: Леонардо Да Винчи своими исследованиями полетов птиц и кардинально новой идеей: «не крыло должно махать, но аэроплан должен лететь» - прославился больше и украсил свои многочисленные концептуальные изобретения загадочной Джакондой.

Субъективные положения социального мира

ТРИЗ не строилась на фундаменте технического задания, а ее родоначальник Альтшуллер не руководствовался какими-либо методами выполнения работ. «Мастера» теории решения изобретательских задач и тысячи их учеников довольствовались малым:

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

С точки зрения общественного сознания, актуальности и полезности целевая установка ТРИЗ социально значима и имеет реальное практическое применение.

Автоматизировать процесс решения изобретательских задач, исключив из него «элементы случайности: внезапное и непредсказуемое озарение, слепой перебор и отбрасывание вариантов, зависимость от настроения и т. п» (цитата из "Википедии").

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

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

Обозначить - не значит использовать: концептуально о базовых постулатах ТРИЗ

Постулат «1»: нет разницы между естественной и искусственной системой, потому. как и то, и другое развивается не по определенным, а по объективным законам. То, что человек не познал или не понимает объективности законов Природы, ровным счетом для этих законов ничего не значит.

Постулат «2»: все системы развиваются, но причем здесь противоречия. Есть задача, есть необходимость ее концептуального проектирования, и есть проблема образования (квалификации) специалистов, задействованных в ее решении.

Постулат «3»: даже на пустом месте, которое обнаружили два квалифицированных специалиста в поисках одного противоречия, они сформулируют два десятка кардинально различных варианта решения.

Так было, есть и будет, пока уровень знаний и умений будет основываться на субъективном мнении, а не на объективных законах Природы.

Цели и задачи проектирования - это всегда важно, но гораздо важнее их концепция. Во всякой области применения развивающаяся естественная система или создаваемая человеком искусственная система есть нечто, обозначаемое целью, и спектр составляющих этого нечто, обозначаемый задачами. Есть требования, которые формулирует потребитель (заказчик), автор идеи.

Концептуальное проектирование (КП) - это динамика развития цели и составляющих ее задач, как способ движения к пониманию сути вещей, явлений и процессов. Человек сначала понимает, что нужно сделать, затем что-то делает и, переосмысливая созданное, пересматривает цель и составляющие ее задачи.

Методы и средства проектирования

Интересная особенность поисковой выдачи по запросу: «методы и средства концептуального проектирования»: 97 % результатов связаны с информационными системами, программированием, базами данных и другими направлениями в области компьютерного дела и информационных технологий; остальные 3 % придутся на «более практичные» сферы социальных и производственных потребностей: авиационные двигатели, производственные процессы, социальные или природоохранные проекты и другое.

Странная особенность человеческого менталитета, когда он приобретает знания и приближается к пониманию объективных законов Природы: ставить свои достижения на первое место, пренебрегать достижениями других людей и считать только свой собственный опыт определяющим критерием познания окружающей среды и влияния на нее.

Концептуальное проектирование: примеры из области разработки программного обеспечения.

1) В настоящее время принято выделять следующие методологии разработки ПО:

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

2) Основными этапами КП являются:

Предварительное проектирование.
Эскизное (рабочее или техно-рабочее) проектирование.
Изготовление, испытания и доводка опытного образца системы.

3) Есть два подхода к КП:

Первый подход включает формулирование, определение и интеграцию объектов высокого уровня, используемых для построения модели. Основное внимание при этом уделяется интеграции понятий (концепции), представляющих объекты.
Второй подход - моделирование сущностей. Моделирование и интеграция представлений пользователей в терминах диаграмм сущностей.

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

Объективный подход к проектированию

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

Наука и практика обязаны теории решения изобретательских задач. Это было на самом деле великое дело: систематизировать физические, химические, социальные и другие достижения, практические решения, изобретения, технологические процессы. Задача сформулировать системы физических эффектов или определить объективные закономерности - воистину актуальна, была всегда, и в современном мире ее актуальность стремительно растет.

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

Суть не в том, что такое цель, задача, средство или метод. В концептуальном контексте важен смысл, а не его формальное обозначение.

Человек и пчела

Менталитет венца Природы - человека по сей день не позволяет ему наделить иное живое существо интеллектом. Человек до сих пор не понимает, что его ровным счетом ничего не значит для объективных законов Природы.

Человек может считать, что действует сознательно и не понимать, что его мозг непрерывно делает что-то бессознательно, чтобы уже через три года ребенок после рождения начал, к примеру, выражать свои потребности словами, а к пяти годам строить пирамиды из кубиков, а к десяти годам мечтать о полетах на Луну или статусе известного композитора.

Концептуальное проектирование своего поведения пчела делает на автомате. Результат - есть польза пчелиной семье, окружающей среде и человеку. Пусть человек считает, что интеллектом пчела не обладает. Это ровным счетом ничего не значит.

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

При использовании спиральной модели:

- происходит накопление и повторное использование проектных решений, средств проектирования, моделей и прототипов информационной системы и информационной технологии;

- осуществляется ориентация на развитие и модификацию системы и технологии в процессе их проектирования;

- проводится анализ риска и издержек в процессе проектирования систем и технологий.

2.3.2. Концептуальное проектирование

Концепция информационной системы

В предыдущем разделе было показано (рис. 2.3.2), что трудовые и финансовые затраты постепенно растут в первых двух фазах жизненного цикла и резко возрастают в фазе практической реализации информационной системы. Между тем, ошибки, допущенные на первых двух этапах, порождают на последующих этапах трудные, часто неразрешимые проблемы, а также могут серьезно повлиять на стоимость, график работ и, в конечном итоге, на результаты работ в целом. С учетом излагаемых ниже причин имеются основания для выделения их в самостоятельный и специфический вид деятельности – концептуальное проектирование информационных систем. Результатом концептуального проектирования является концепция информационной системы , под которой будем понимать системно взаимосвязанную совокупность структурных решенийS ti S t , реализующих требуемое качество информационного обеспеченияQ t .

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

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

Определим задачу концептуального проектирования через его компоненты.

Объектом концептуального проектирования является существующее состояние информационной системы


Sc =(Sc	S c ),

где S c – состояние существующей информационной системы,S c		S с

соответственно организационно-техническое, функциональное и информационное структурные решения.

Субъект концептуального проектирования. По общепринятой в отече-

ственной технической литературе терминологии субъект концептуального проектирования следует именовать "разработчик" или "проектировщик". Однако представляется, что названные термины наилучшим образом отражают содержание детального (физического) проектирования. В части, касающейся разработки концепции информационных систем, более привлекателен современный термин "системный интегратор".

Система целей концептуального проектирования. Основная цель кон-

цептуального проектирования может быть сформулирована следующим образом: определение множества состояний информационной системы S t , реали-

зующих требуемый уровень качества информационного обеспечения Q t .

Концептуальное проектирование информационных систем является многоцелевым (оценка и сравнение отдельных целей в единых универсальных единицах невозможна). Поэтому цель концептуального проектирования представим вектором


			S ti= (S ti	S ti	S ti
		; S ti	– i -ое перспективное решение, соответственно:
где S ti	; S ti

- организационно-техническое (целевое состояние организационной и технической структур);

- процедурное (целевое состояние процедурной структуры);

- информационное (целевое состояние информационной структуры). Практическая активность . Для достижения целей концептуального про-

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

W i o ={w i o } – работы, направленные на совершенствование организационнотехнической структуры до состоянияS ti ;

W i p ={w i p } – работы, направленные на совершенствование функциональной структуры до состоянияS ti p ;

W i i ={w i i } – работы, направленные на совершенствование информационной структуры до состоянияS ti i .

Задача концептуального проектирования информационных систем.

Структуризация понятия концептуального проектирования и формализация его основных компонентов позволяет сформулировать в организационнотехнических терминах задачу концептуального проектирования информационных систем:

В выражении (3.8) S t – множество целевых в смысле выражения состояний информационной системы, вектор цели концептуального проектирования. За-

данные условия S * включают вектор текущего состояния информационной системыS с и множество допустимых операторовW , переводящих информацион-

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

< S с ,W ,S t >.

Подобное представление определяет концептуальное проектирование информационных систем как процесс постановки и решения задачи (3.9).

Современные подходы к концептуальному проектированию информационных систем

Проблема концептуального проектирования информационных систем: состояние и пути решения

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

- низкое качество информационного обеспечения;

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

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

Начиная с середины XX века в проектировании информационных систем наметилась общая тенденция – объектами проектирования стали большие и сложные информационные системы. Это привело к резкому росту наукоемкости и средней сложности проектов.

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

- рациональных (формальных) критериях и методах оценки существующего качества и требованиях к качеству перспективного информационного обеспечения;

- перечне приоритетных задач деятельности организаций, информационные процессы которых могут быть усовершенствованы на основе структурнопараметрических решений;

- целесообразной последовательности позадачного и попроцедурного совершенствования;

- соотношении организационных, технических, функциональных и информационных решений;

- необходимых финансовых, технических и других ресурсах;

- сроках проведения проектных работ;

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

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

- изучать конъюнктуру рынка;

- определять реальные цели проектов,

- находить требуемые финансовые и другие ресурсы, исполнителей и т.д. Кроме того, в силу новизны предметной области, отсутствия сколько-

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

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

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

Еще одним скрытым фактором, негативно влияющим на результаты проекта, является архаичность традиционного управленческого цикла, основным недостатком которого является неразвитость обратных связей (регулирования). Контроль результатов проекта осуществляется, по сути, после физической реализации информационной системы на основе субъективной оценки ("хорошо",

"плохо") состояния информационного обеспечения. Процедура согласования технического задания практически не выявляет и не корректирует эвристических ошибок, допущенных на предшествующих этапах, и является в известной мере формальной.

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

Особенности проблемы и условия концептуального проектирования информационных систем

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

Выделяют следующие особенности, определяемые сущностью проблемы совершенствования информационного обеспечения.

1. Рост требований и увеличение компетенции пользователей.

2. Собственная сложность конечных результатов проектной деятельности (проектов).

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

4. Необходимость осуществления предметной деятельности и, следовательно, и информационного обеспечения в условиях неопределенности целей и риска.

5. Необходимость непрерывного решения проблемы совершенствования информационного обеспечения.

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

7. Отсутствие формальных методов решения проблемы.

Особенности, определяемые современным состоянием проблемы.

1. Отсутствие системных разработок ("фрагментарность" решений). До настоящего времени вопросы разработки научно-методологической базы совершенствования информационного обеспечения находятся в начальной стадии.

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

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

3. Перманентно существующая организационная перестройка.

4. Динамичность информационных технологий, определяемая достижениями научно-технического прогресса.

4. Ошибки планирования и ценообразования.

5. Неадекватная сложности проблемы организация работ на местах. Количество и качество руководящих материалов, направляемых на места, не соответствует сложности и актуальности проблемы.

6. Ограниченное финансирование работ.

7. Наличие существующих информационных технологий, так или иначе обеспечивающих информационные потребности организаций.

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

в специфических условиях: иерархичность, территориальная распределенность организационной структуры и деятельности; многозадачность предметной деятельности; динамичность организационной структуры, условий функционирования и решаемых задач.

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

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

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

2. Свойственное для крупных организаций соперничество между функциональнымиподразделениямиможетпривестикнеоптимальностипроектныхрешений.

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

4. В связи со значительными размерами и организационной сложностью руководству организации или подразделений достаточно сложно уделять необходимое внимание текущим проблемам проекта. Серьезным и часто определяющим фактором является естественная для руководителей некомпетентность в данной сфере.

Специфика предметной деятельности обуславливает специфику информационного обеспечения: коллективное использование территориально распределенных информационных ресурсов; дискретность, разномасштабность, стохастичность протекающих информационных процессов; высокие требования к качеству всех процедур информационного процесса; отсутствие априорной информации о характеристиках информационных процессов, большой объем и разнородность обрабатываемой информации, сложность информационных связей; жесткая организационно-правовая детерминированность информационных процессов и ряд других факторов. Имеют место различные и зачастую противоречащие друг другу информационные потребности пользователей.

Условия концептуального проектирования. Совокупность изложенных особенностей совершенствования информационного обеспечения определяет ряд условий, при наличии которых в жизненном цикле проекта должна присутствовать развитая фаза концептуального проектирования:

1. Информационная система является большой и сложной. Проект представляет собой систему, состоящую из подсистем, которые должны быть объединены в единое функционально связанное целое.

2. Проект является технически сложным.

3. Необходимость финансового контроля на всех стадиях проекта.

4. Наличие ограничений в смете и календарных графиках.

5. Необходимость быстрого реагирования на изменения условий проекта.

6. Привлечение к проекту большого числа функциональных подразделений

и охват значительного числа видов работ.

7. Возможность серьезных изменений в организационной структуре.

8. Необходимость в больших закупках и поставках материалов, оборудования, услуг.

мость быстро-

серьезных

Техническая

в смете и

го реагирова-

изменений

сложность

календарном

негативных

ния на изме-

в структуре

воздействий

нения условий

УСЛОВИЯ НЕОБХОДИМОСТИ ПРОЕКТ

КОНЦЕПТУАЛЬНОГО ПРОЕКТИРОВАНИЯ

Рис. 2.3.3. Условия необходимости концептуального проектирования

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

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

Другими словами, необходима специальная технология концептуального проектирования, отвечающая следующим требованиям:

- целостность и системность реализуемого данной технологией процесса, который должен включать функционально полный набор компонентов "технологической цепочки";

- высокая степень расчленяемости процесса на стадии (процедуры), что и открывает возможность его технологизации;

- регулярность процесса и однозначность его стадий, что позволяет применять при их описании законы больших чисел и средних величин;

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

Предполагает выявление существующих связей между отдельными элементами данных и сопоставления таких отношений в организованном смысле слова. При проектирования базы данных существует несколько типов: концептуальное проектирование базы данных, логическое проектирование БД, физическое проектирование БД. Наиболее простым, является пожалуй логическое и физическое проектирование базы данных. Концептуальное проектирование баз данных — немного более неоднозначное, поскольку на этом этапе нет никакой прямой работы с . Сам процесс — это исключительно упражнение в выявлении соответствующих данных.
Две основные вещи, которые выявляются в концептуальном проектировании базы данных сущности и связи, то есть данные, являющиеся реальными объектами материального мира и отношений, сеть из связей, соединяющих одно юридическое лицо с другим неопределенное время. Здесь возникает центральное понятие этого типа конструкции: модель сущность-связь. Это не характеристика общей организации и структуры, которые будут присущи логической схеме базы данных; это её предшественник.

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

Заключительные соображения в развитии модели «сущность-связь» для концептуального проектирования баз данных относятся: назначение каждого наблюдаемого атрибута для конкретного домена и двойная проверка, чтобы убедиться, что всё в этой модели имеет смысл. Просмотрев всё, что влечет за собой поиск и отфильтровать все повторяющиеся данные, убедившись, что все атрибуты, связанные с правильными сущностями и отношениями между ними, подтверждают, что все связи в схеме не логичны. Если соединения не логичны в контексте реального мира, они должны быть логичными, по крайней мере, на абстрактном уровне.

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

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

Размещено на http://www.allbest.ru/

Министерство образования и науки Российской Федерации

Федеральное государственное бюджетное образовательное учреждение

высшего профессионального образования

Волгоградский Государственный Технический Университет

Факультет Подготовки Инженерных Кадров

Кафедра "Системы автоматизированного проектирования и поискового

конструирования"

Курсовая работа

По курсу "Концептуальное проектирование систем"

Выполнил: студент группы АУЗ-361с Тюляева И.А.

Проверил: ст. пр. Орлова Т. А.

Волгоград 2013 г

Введение

1) Проведение конструктивно-функционального анализа системы

1.Описание исходной системы

Объект исследования

Вербальное описание

Ограничения на исследования

Цель определения системы

Классификация системы

Конструктивно-функциональный анализ системы

Конструктивно-функциональная структура в графическом виде

2) Проведение функционально-физического анализа технических объектов

1. Функционально-физический анализ технических объектов

2. Потоково-функциональная структура

3) Проведение морфологического анализа и морфологического синтеза технического объекта

1.Описание технического объекта

2. Морфологический анализ технического объекта

2.1 Цель морфологического анализа

Морфологическая таблица

Общее количество возможных технических решений

Итоговое общее количество возможных технических решений

3. Морфологический синтез технического объекта

3.1 Цель морфологического синтеза

Таблица экспертных оценок

Синтез по одному критерию

Синтез по всем критериям

Заключение

Список использованных источников

Введение

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

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

В результате проведения данной работы студент должен узнать и научиться:

Основные особенности задач решаемых при проектировании технических объектов;

Применить научный подход к анализу и синтезу решений при проектировании технических объектов;

Использовать методы анализа и синтеза технических решений для построения автоматизированных систем проектирования технических объектов;

Ставить и решать задачи создания автоматизированных систем поддержки концептуального проектирования.

1) Проведение конструктивно-функционального анализа системы

Цель работы :

1. Описание исходной системы

1.1 Объект исследования

Объектом исследования является - электрокофемолка ударного типа. Определим объект как систему электроперемолки кофе без электронного регулятора.

1.2 Вербальное описание

Автоматизированная система электрокофемолки создана для обеспечения равномерности и интенсивности перемалывания. Особенностью системы электрокофемолки ударного действия является размол жареных зерен кофе с помощью вращающегося с большой скоростью ножа.

Отправителем (V 1) кофейных зерен (V 2) в системе является человек, он же является ответственным за подачу кофейных зерен в бункер для кофейного зерна и выгрузку полученного измельченного кофейного порошка из бункера для молотого кофе.

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

1.3 Ограничения на исследования

При исследовании данной системы не учитывается влияние внешней среды на объект исследования. В качестве внешней среды, непосредственно влияющей на исследуемую систему, рассматривается человек и кофейные зерна. Система предназначена для обеспечения равномерности и интенсивности перемалывания кофейных зерен, а также круп и орехов, размеры которых не должны препятствовать работе системы.

1.4 Цель определения системы

Исследование методов перемалывания кофейных зерен без использования ручного труда и дополнительного оборудования и техники, а также разработки эффективного комплектования данной системы.

2. Классификация системы

Исследуемая система относится к сложным техническим детерминированным системам.

Система является открытой системой, так как она взаимодействует с окружающей средой и не живая.

Система конкретная, потому что имеет больше 2-х элементов, которые являются объектами.

Автоматизированная электрокофемолка относится к искусственным физическим системам, так как создан человеком.

Описание системы объекта не может быть использовано для математической обработки данных, так как описывается абстрактно, то есть свойства описываются как переменные, а базовое свойство как параметр.

Каждый блок представляет собой одно состояние переменной. Когда наблюдаемые свойства проводятся при некотором значении параметра, то наблюдаемое свойство получает определённое проявление из множества проявлений свойств.

Любое свойство, относительно которого проводится наблюдение других свойств, называется базовым. Применительно к системе электрокофемолки ударного типа можно сделать вывод, что базовым свойством для нее будет являться объем перемолотых кофейных зерен.

3. Конструктивно -функциональный анализ системы

Таблица № 1. Конструктивно-функциональная структура

Элемент системы	Функции элемента
	Наименование	Вербальное описание
		Воздействует при открытии на Е 4 и прекращает воздействие при закрытии
		Перемалывает V 2 и передает результат работы под Е 3
	Бункер для кофейного зерна	V 1 засыпает V 2 в элемент Е 2, запускается Е 1
		Проталкивает V 2 к Е 7
	Блокирующее устройство	Фиксирует факт открытия и закрытия Е 0 , блокирует/ разблокирует Е 5
	Электродвигатель	Принимает сигнал от Е 6 , затем подаёт сигнал на запуск Е 1
	Включатель	Воздействует на Е 5 и прекращает воздействие при повторном нажатии V 1
	Бункер для молотого кофе	Хранит перемолотый V 2

4. Графическое представление

Рис. 1. Конструктивно-функциональная структура в графическом виде.

2) Проведение функционально-физического анализа технического объекта

Цель работы: изучение функционально-физический анализ автоматизированных систем и получение навыков работы с данным методом при проектировании автоматизированной системы.

1. Функционально-физический анализ технических объектов

Внешняя среда: V 1 - Человек, V 2 - Кофейные зерна.

Таблица №2: Функционально-физическая структура

Элемент системы	Физическая операция
	Наименование	Входное воздействие	Операция Колера	Выходное воздействие В
		Физическое Воздействие от V 1	Преобразование	Сигнал к Е 4
		Воздействие на V 2	Преобразование	Сигнал к Е 3
	Бункер для кофейного зерна	Физическое Воздействие от V 1 на V 2	Преобразование	Сигнал к Е 1
		Сигнал из Е 1	Перемещение	Передача V 2 к Е 7
	Блокирующее устройство	Положение Е 0	Преобразование	Сигнал к Е 5
	Электродвигатель	Сигнал из Е 4 и Е 6	Преобразование	Сигнал к Е 1
	Включатель	Физическое Воздействие от V 1	Преобразование	Сигнал к Е 5
	Бункер для молотого кофе	Задержка V 2	Перемещение	Хранение V2 с Последующей передачей на обработку

2. Потоко во - функциональная структура

Рис. 2. Потоково-функциональная структура в графическом виде.

3) Проведение морфологического анализа и морфологического синтеза технического объекта

Цель работы: изучение конструктивно-функционального анализа автоматизированных систем и получение навыков работы с данным методом при проектировании автоматизированной системы.

1. Описание технического объекта

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

Электро (от нов.-лат. electricus и др.-греч. ?лекфспн) - электр, блестящий металл; янтарь.

2. Морфологический анализ технического объекта

2.1 Цель морфологического анализа

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

Необходимо усовершенствовать рассматриваемую систему.

Требования: Необходимо увеличить надёжность и функциональность системы.

Цель: Увеличить точность фиксации и быстродействие.

2.2 Морфологическая таблица

конструктивный морфологический автоматизированный электрокофемолка

Таблица №3: Морфологическая таблица технического объекта.

Классификационные признаки	Варианты реализации классификационных признаков
	V 1 1 - сталь; V 1 2 - алюминий; V 1 3 - пластик;
	V 2 1 - сталь; V 2 2 - алюминий; V 2 3 - латунь;
Бункер для кофейного зерна	V 3 1 - сталь; V 3 2 - пластик;
	V 4 1 - поршневой; V 4 2 - гидравлический;
Блокирующее устройство	V 5 1 - кнопка; V 5 2 - контактная пластина; V 5 3 - фотоэлемент;
Включатель	V 6 1 - автоматический; V 6 2 - кнопка;
Бункер для молотого кофе	V 7 1 - сталь; V 7 2 - пластик;

2.3 Общее количеств

Общее количество возможных технических решений:

3 * 3 * 2 * 2 * 3 * 2 * 2 = 432

Для уменьшения числа возможных комбинаций можно отбросить следующие менее значимые классификационные признаки:

Бункер для кофейного зерна.

Бункер для молотого кофе.

Включатель.

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

2.4 Итоговое общее количеств о возможных технических решений

Таблица №4: Итоговая таблица.

Итоговое общее количество возможных технических решений:

3 * 3 * 2 * 2 = 36

3. Морфологический синтез технического объекта

3.1 Цель морфологического синтеза

На основе морфологической таблицы составленной на этапе морфологического анализа, необходимо обозначить такие решения, которые экономически оправданы и надёжны в работе.

3.2 Таблица экспертных оценок

Таблица №5: Таблица экспертных оценок технического объекта.

Наименование элемента	Оценка элементов по критериям
	Эффективность	Простота осуществления	Экономичность	Надежность
V 1 1 - сталь; V 1 2 - алюминий; V 1 3 - пластик
V 2 1 - сталь; V 2 2 - алюминий; V 2 3 - латунь;
V 4 1 - поршневой; V 4 2 - гидравлический;
Блокирующее устройство: V 5 1 - кнопка; V 5 2 - контактная пластина;

Весовые значимости критериев:

Эффективность - 0.3

Простота осуществления - 0.1

Экономичность - 0.2

Надежность - 0.4

3.3 Синтез по одному критерию

Синтез по критерию "Надёжность".

Наилучший вариант:

Материал ножа: V 2 1 - сталь;

3.4 Синтез по всем критериям

Таблица №6: Таблица синтеза по всем критериям.

Наилучший вариант:

Материал крышки: V 1 3 - пластик;

Материал ножа: V 2 1 - сталь;

Тип пресса: V 4 1 - поршневой;

Тип блокирующего устройства: V 5 2 - контактная пластина.

Заключение

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

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

Список использованных источников

http://www.4analytics.ru/metodi-analiza/metod-ekspertnix-ocenok.html

http://www.coffeepedia.ru/%D0%9A%D0%BE%D1%84%D0%B5%D0%BC%D0%BE%D0%BB%D0%BA%D0%B0

http://coffeetime.ru/production/cook/2007-04-16-624/

Размещено на Allbest.ru

Подобные документы

Сущность понятия "модель технического объекта" как ориентира для процесса проектирования. Характеристика диагностических и многоэлементных моделей технических объектов. Изучение свойств и характеристик, прогнозирование поведения проектируемых систем.

реферат , добавлен 13.10.2009

Общие характеристики показателей надежности. Взаимосвязь надежности и качества объекта. Что понимается под ресурсными испытаниями и с какой целью они проводятся. Достоинства и недостатки "дерева событий". Модернизация конструкции или технологии.

контрольная работа , добавлен 01.03.2011

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

реферат , добавлен 13.10.2009

Этапы развития ООО "КИНЕФ". Основные химические процессы, используемые при переработке нефти. Цели и назначение создания системы. Датчики ударного импульса. Принцип действия термопреобразователей сопротивления. Определение показателей надежности системы.

отчет по практике , добавлен 26.05.2015

Назначение и технологическая схема установки предварительного сброса воды (УПСВ). Функции и структура автоматизированной системы управления УПСВ, разработка ее уровней и выбор оборудования. Расчет надежности и технико-экономической эффективности системы.

дипломная работа , добавлен 29.09.2013

Место вопросов надежности изделий в системе управления качеством. Структура системы обеспечения надежности на базе стандартизации. Методы оценки и повышения надежности технологических систем. Предпосылки современного развития работ по теории надежности.

реферат , добавлен 31.05.2010

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

курсовая работа , добавлен 15.02.2017

Определения требований надежности и работоспособности системы промышленного тахометра ИЛМ1. Распределение требований ее надежности по различным подсистемам. Проведение анализа надежности системы и техногенного риска на основе методов надежности.

курсовая работа , добавлен 23.05.2013

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

контрольная работа , добавлен 16.04.2010

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

КОНСПЕКТ ОБЗОРНОЙ ЛЕКЦИИ

Для студентов специальности
Т1002 «Программное обеспечение информационных технологий»

(Л.В. Рудикова, к.ф.-м.н., доцент)

Вопрос 31. АРХИТЕКТУРА СУБД. РЕЛЯЦИОННАЯ МОДЕЛЬ ДАННЫХ

1. Понятие базы данных.

2. Трехуровневая архитектура базы данных.

3. Жизненный цикл базы данных.

4. Архитектура СУБД.

5. Реляционная модель данных.

6. Проектирование реляционных баз данных.

7. Нормальные формы отношений.

8. Реляционная алгебра.

1. Понятие базы данных.

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

Информационная система – автоматическая система, организующая данные и выдающая информацию.

Информационно-управляющая система – система, обеспечивающая информационную поддержку менеджмента.

Данные – разрозненные факты.

Информация – организованные и обработанные данные.

Под базой данных понимается множество взаимосвязанных элементарных групп данных (информации), которые могут обрабатываться одной или несколькими прикладными системами. Система базы данных состоит из базы данных; программного обеспечения общего назначения, которая называется системой управления базой данных (СУБД) , и служит для управления базой данных; соответствующего оборудования и людей.

Каждая СУБД должна удовлетворять следующим требованиям:

· обеспечивать пользователю возможность создавать новые БД и определять их схему (логическую структуру данных) с помощью специального языка - языка определения данных ; поддерживать разнообразные представления одних и тех же данных;

· позволять «запрашивать » данные и изменять их с помощью языка запросов , или языка манипулирования данными ; допускать интеграцию и совместное использование данных различными приложениями;

· поддерживать хранение очень больших массивов данных, измеряемых гигабайтами и более, в течение долгого времени, защищая их от случайной порчи и неавторизованного использования, а также - обеспечивать модификацию БД и доступ к данным путем запросов, т.е. гарантировать безопасность и целостность данных;

· контролировать доступ к данным одновременно для многих пользователей; исключать влияние запроса одного пользователя на запрос другого и не допускать одновременный доступ, который может испортить данные, т.е. гарантировать управление параллельным доступом к данным.

Система с базой данных состоит из следующих компонентов:

· Пользователи, т.е. люди, которые используют данные.

· Приложения, т.е. программы пользователей, которым требуются данные из системы.

· СУБД – программное обеспечение, которое управляет доступом к данным и обеспечивает указанные функциональные возможности системы с базой данных.

· Данные, т.е. строки, хранящиеся в файлах.

· Система-хост – компьютерная система, в которой хранятся файлы. Доступ к строкам данных осуществляется системой-хостом. Роль СУБД состоит в том, чтобы генерировать запросы, позволяющие использовать функциональные возможности системы управления файлами системы-хоста для обслуживания различных приложений. СУБД – это дополнительный уровень программного обеспечения, надстроенный над программным обеспечением системы-хоста.

Таким образом, систему с БД можно представить в виде следующей последовательности уровней:

На самом нижнем уровне находятся данные, хранящиеся в физических файлах (физическая память БД). На верхнем уровне – приложений с их собственными представлениями одних и тех же физических данных. Каждой представление БД – это определенная логическая структура, построенная из лежащих в основе физических данных. Чтобы обеспечить интерфейс между физической памятью БД и ее разнообразными логическими версиями (множеством поддерживаемых представлений) СУБД, в свою очередь должна состоять из нескольких уровней.

2. Трехуровневая архитектура базы данных.

Различие между логическим и физическим представлением данных официально признано в 1978 году, когда комитет ANSI / SPARC предложил обобщенную структуру систем баз данных. Эта структура получила название трехуровневой архитектуры. Три уровня архитектуры следующие: внутренний, концептуальный и внешний.

Внутренний уровень – это уровень, определяющий физический вид базы данных, наиболее близкий к физическому хранению и связан со способами сохранения информации на физических устройствах хранения. С данным уровнем связаны дисководы, физические адреса, индексы, указатели и т.д. За этот уровень отвечают проектировщики физической БД, которые решают, какие физические устройства будут хранить данные, какие методы доступа будут использоваться для извлечения и обновления данных и какие меры следует принять для поддержания или повышения быстродействия системы управления базами данных. Пользователи не касаются этого уровня.

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

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

Представления пользователей и приложений	Внешний уровень

Отображения

Концептуальная схема	Концептуальный уровень

Отображение	Внутренний уровень

Система-хост

Хранящиеся данные

Рис. Уровни СУБД

3. Жизненный цикл базы данных.

Процесс проектирования, реализации иподдержания системы базы данных называется жизненным циклом базы данных (ЖЦБД). Процедура создания системы называется жизненным циклом системы (ЖЦС).

Понимание и правильный подход к ЖЦБД очень важен и требует детального рассмотрения, так как в его основе лежит подход, ориентированный на данные . Элементы данных более стабильны, чем выполняемые функции системы. Создание правильной структуры данных требует сложного анализа классов единиц данных и отношений между ними. Если построить логичную схему базы данных, то в дальнейшем можно создать любое количество функциональных систем, использующих эту схему. Функционально-ориентированный подход можно применять лишь для создания временных систем, которые рассчитаны на недолгое время функционирования.

ЖЦБД состоит из следующих этапов:

1. Предварительное планирование – планирование БД, выполняемое в процессе разработки стратегического плана БД. В процессе планирования собирается следующая информация:

· какие прикладные программы используются, и какие функции они выполняют;

· какие файлы связаны с каждым из этих приложений;

· какие новые приложения и файлы находятся в процессе работы.

Данная информация помогает определить, как используется информация приложений, определить будущие требования к системе БД.

Информация этого этапа документируется в виде обобщенной модели данных.

2. Проверка осуществимости . Здесь определяется технологическая, операционная и экономическая осуществимость плана создания БД, т. е.:

· технологическая осуществимость – есть ли технология для реализации запланированной БД?

· операционная осуществимость – есть ли средства и эксперты, необходимые для успешного осуществления плана создания БД?

· экономическая целесообразность – можно ли определить выводы? Окупится ли запланированная система? Можно ли оценить издержки и выгоду?

3. Определение требований включает выбор целей БД, выяснение информационных требований к системе и требований к оборудованию и программному обеспечению. Таким образом, на данном этапе сбора данных и определения требований создаётся общая информационная модель , выражающаяся в следующих задачах:

· Определяются цели системы путём анализа информационных потребностей. Здесь также обязательно указывается, какую именно БД следует создавать (распределённую, целостную) и какие коммуникационные средства необходимы. Выходной документ – комментарий, описывающий цели системы.

· Определение пользовательских требований: документация в виде обобщённой информации (комментарии, отчёты, опросы, анкеты и т. д.); фиксация функций системы и определение прикладных систем, которые будут выполнять эти требования. Данные представляются в виде соответствующих документов.

· Определение общих требований к оборудованию и программному обеспечению, связанных с поддержанием желаемого уровня быстродействия. (Выяснение количества пользователей системы, числа входных сообщений в день, количество распечаток). Данная информация используется для выбора типов компьютеров и СУБД, объёма дисков, количества принтеров. Данные этого этапа излагаются в отчёте, содержащем примерные конфигурации оборудования и программного обеспечения.

· Разработка плана поэтапного создания системы, включающий выбор исходных приложений.

4. Концептуальное проектирование – создание концептуальной схемы БД. Спецификации разрабатываются в той степени, которая необходима для перехода к реализации.

Основным выходным документом является единая инфологическая модель (или схема БД на концептуальном уровне ). При разработке данной модели используются информация и функции, которые должна выполнить система, определённые на этапе сбора и определения требований к системе. На данном этапе желательно также определить: 1) правила для данных; 2) правила для процессов; 3) правила для интерфейса.

5. Реализация – процесс превращения концептуальной модели в функциональную БД. Он включает в себя следующие этапы.

1) Выбор и приобретение необходимой СУБД.

2) Преобразование концептуальной (инфологической) модели БД в логическую и физическую модель данных:

· на основе инфологической модели данных строится схема данных для конкретной СУБД, при необходимости реализуется денормализация БД с целью ускорения обработки запросов во всех критичных по времени приложениях;

· определяются, какие прикладные процессы необходимо реализовать в схеме данных как хранимые процедуры;

· реализовать ограничения, предназначенные для обеспечения целостности данных и реализации правил для данных;

· спроектировать и сгенерировать триггеры для реализации всех централизованно определённых правил для данных и правил целостности данных, которые не могут быть заданы как ограничения;

· разработать стратегию индексирования и кластеризации; выполнить оценку размеров всех таблиц, кластеров и индексов;

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

· разработать сетевую топологию БД и механизм бесшовного доступа к удалённым данным (реплицированная или распределённая БД).

3) Построение словаря данных, который определяет хранение определений структуры данных БД. Словарь данных также содержит информацию о полномочиях доступа, правилах защиты данных и контроля данных.

4) Заполнение базы данных.

5) Создание прикладных программ, контроль управления.

6) Обучение пользователей.

6. Оценка и усовершенствование схемы БД. Включает опрос пользователей с целью выяснения функциональных неучтенных потребностей. При необходимости вносятся изменения, добавление новых программ и элементов данных по мере изменения и расширения потребностей.

Таким образом, ЖЦБД включает в себя:

· Изучение предметной области и представление соответствующей документации (1-3).

· Построение инфологической модели (4).

· Реализация (5).

· Оценка работы и поддержка БД (6).

4. Архитектура СУБД.

Рис. Главные компоненты СУБД

Данные, метаданные - содержат не только данные, но и информацию о структуре данных (метаданные ). В реляционной СУБД метаданные включают в себя системные таблицы (отношения), имена отношений, имена атрибутов этих отношений и типы данных этих атрибутов.

Часто СУБД поддерживает индексы данных. Индекс - это структура данных, которая помогает быстро найти элементы данных при наличии части их значения (например, индекс, который находит кортежи конкретного отношения, имеющие заданное значение одного из атрибутов). Индексы - часть хранимых данных, а описания, указывающие, какие атрибуты имеют индексы - часть метаданных.

Менеджер памяти -получает требуемую информацию из места хранения данных и изменяет в нем информацию по требованию расположенных выше уровней системы.

В простых системах БД менеджером памяти может служить система файлов операционной системы. Однако для повышения эффективности, СУБД обычно осуществляет прямой контроль памяти. Менеджер памяти состоит из двух компонентов:

· Менеджер файлов контролирует расположение файлов на диске и получает блок или блоки, содержащие файлы, по запросу менеджера буфера (диск в общем случае делится на дисковые блоки - смежные области памяти, содержащие от 4000 до 16000 байт).

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

Процессор «запроса» - обрабатывает запросы и запрашивает изменения данных или метаданных. Он предлагает лучший способ выполнения необходимой операции и выдает соответствующие команды менеджеру памяти.

Процессор (менеджер) запросов превращает запрос или действие с БД, которые могут быть выполнены на очень высоком уровне (например, в виде запроса SQL ), в последовательность запросов на хранимые данные типа отдельных кортежей отношения или частей индекса на отношении. Часто самой трудной частью обработки запроса является его организация , т. е. выбор хорошего плана запроса или последовательности запросов к системе памяти, отвечающей на запрос.

Менеджер транзакций - отвечает за целостность системы и должен обеспечить одновременную обработку многих запросов, отсутствие интерференции запросов (сложение, min , max ) и защиту данных в случае выхода системы из строя. Он взаимодействует с менеджером запросов, т. к. должен знать, на какие данные воздействуют текущие запросы (для избежания конфликтных ситуаций), и может отложить некоторые запросы и операции для избежания конфликтов. Менеджер транзакций взаимодействует также с менеджером памяти, т. к. схемы защиты данных обычно включают в себя хранение файла регистрации изменений данных. При правильном порядке выполнения операции файл регистрации будет содержать запись изменений, поэтому можно заново выполнить даже те изменения, которые не достигли диска из-за сбоя в системе.

Типичные СУБД позволяют пользователю сгруппировать несколько запросов и/или изменений в одной транзакции. Транзакция - это группа операций, которые необходимо выполнить последовательно, как одно целое.

Как правило, система БД поддерживает одновременно множество транзакций. Именно правильное выполнение всех таких транзакций и обеспечивает менеджер транзакций . Правильное выполнение транзакций обеспечивается ACID -свойствами (atomicity , consistency , isolation , durability ):

· атомарность - выполнение либо всех транзакций, либо ни одной из них (например, изъятие денег из банкомата и внесение соответственного дебета в счет клиента должны быть единственной атомарной транзакцией, не допускается выполнение каждой из этих операций по отдельности);

· непротиворечивость - состояние, при котором данные соответствуют всем возможным ожиданиям (например, условие непротиворечивости для БД авиационных линий состоит в том, что ни одно из мест в самолете не бронируется для двух пассажиров);

· изоляция - при параллельном выполнении двух или более транзакций их результаты должны быть изолированы друг от друга. Одновременное выполнение двух транзакций одновременно не должно привести к результату, которого не было бы, если они выполнялись последовательно (например, при продаже билетов на один и тот же рейс в случае свободного последнего места при одновременном запросе двух агентов, запрос одного должен быть выполнен, другого - нет);

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

Рассмотрим также 3 типа обращения к СУБД:

1. Запросы - вопросы по поводу данных могут генерироваться двумя способами:

a) с помощью общего интерфейса запросов (например, реляционная СУБД допускает запросы SQL , которые передаются процессору запросов, а также получает ответы на них);

б) с помощью интерфейсов прикладных программ - запросы передаются через специальный интерфейс (через этот интерфейс нельзя передавать произвольные запросы);

2. Модификации - это операции по изменению данных. Они также могут выполняться либо с помощью общего интерфейса, либо через интерфейс прикладной программы;

3. Модификации схемы - это команды администраторов БД, которые имеют право изменять схему БД или создавать новую БД.

Архитектура клиент/сервер. Во многих вариантах современного ПО реализуется архитектура клиент/сервер : один процесс (клиент) посылает запрос для выполнения другому процессу (серверу). Как правило, БД часто разделяется на процесс сервера и несколько процессов клиента.

В простейшей архитектуре клиент/сервер вся СУБД является сервером, за исключением интерфейсов запроса, которые взаимодействуют с пользователем и посылают запросы или другие команды на сервер. Например, реляционная СУБД часто использует язык SQL для представления запросов от клиента к серверу. Затем сервер БД предоставляет клиенту ответ в виде таблицы (отношения). Существует тенденция увеличения нагрузки на клиента, т. к. при наличии множества одновременно работающих пользователей БД с сервером могут возникнуть проблемы.

5. Реляционная модель данных.

РМД некоторой предметной области представляет собой набор отношений, изменяющихся во времени. При создании информационной системы совокупность отношений позволяет хранить данные об объектах предметной области и моделировать связи между ними.

Отношение представляет собой двумерную таблицу, содержащую некоторые данные. Математически под N -арным отношением R понимают множество декартова произведения D 1 D 2 … D n множеств (доменов ) D 1, D 2 , …, D n (), необязательно различных:

R D 1 D 2 … D n ,

где D 1 D 2 … D n – полное декартово произведение, т.е. набор всевозможных сочетаний из n элементов каждое, где каждый элемент берется их своего домена.

Домен - это семантическое понятие. Домен можно рассматривать как подмножество значений некоторого типа данных имеющих определенный смысл. Домен характеризуется следующими свойствами:

· Домен имеет уникальное имя (в пределах базы данных).

· Домен определен на некотором простом типе данных или на другом домене.

· Домен может иметь некоторое логическое условие , позволяющее описать подмножество данных, допустимых для данного домена.

· Домен несет определенную смысловую нагрузку .

Атрибут отношения есть пара вида <Имя_атрибута: Имя_домена>. Имена атрибутов должны быть уникальны в пределах отношения. Часто имена атрибутов отношения совпадают с именами соответствующих доменов.

Отношение R , определенное на множестве доменов, содержит две части: заголовок и тело.

Заголовок отношения – это фиксированное количество атрибутов отношения:

Заголовок отношения описывает декартово произведение доменов, на котором задано отношение. Заголовок статичен, он не меняется во время работы с базой данных. Если в отношении изменены, добавлены или удалены атрибуты, то в результате получим уже другое отношение (пусть даже с прежним именем).

Тело отношения содержит множество кортежей отношения. Каждый кортеж отношения представляет собой множество пар вида <Имя_атрибута: Значение_атрибута>:

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

Отношение обычно записывается в виде:

или короче

или просто

Число атрибутов в отношении называют степенью (или -арностью ) отношения. Мощность множества кортежей отношения называют мощностью отношения.

Схемой отношения называется перечень имен атрибутов данного отношения с указанием домена, к которому они относятся:

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

Схемы двух отношений называются эквивалентными , если они имеют одинаковую степень и возможно такое упорядочение имен атрибутов в схемах, что на одинаковых местах будут находиться сравнимые атрибуты, то есть атрибуты, принимающие значения из одного домена:

Пусть – схема отношения . – схема отношения после упорядочения имен атрибутов. Тогда

Таким образом, для эквивалентных отношений выполняются следующие условия:

· Таблицы имеют одинаковое количество столбцов.

· Таблицы содержат столбцы с одинаковыми наименованиями.

· Столбцы с одинаковыми наименованиями содержат данные из одних и тех же доменов.

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

Все такие таблицы есть различные изображения одного и того же отношения.

Свойства отношений. Свойства отношений непосредственно следуют из приведенного выше определения отношения. В этих свойствах в основном и состоят различия между отношениями и таблицами.

· В отношении нет одинаковых кортежей .

· Кортежи не упорядочены (сверху вниз) .

· Атрибуты не упорядочены (слева направо) .

· Все значения атрибутов атомарны .

Рис. Схематическое изображение отношения

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

6. Проектирование реляционных баз данных.

При проектирование реляционной БД должны быть решены следующие проблемы:

1) С учетом семантики предметной области необходимо наилучшим способом представить объекты предметной области в виде абстрактной модели данных (даталогическое проектирование). Т.е. - определиться со схемой БД: из каких отношений должны состоять БД, какие атрибуты должны быть у этих отношений, каковы связи между отношениями.

2) Обеспечить эффективность выполнения запросов к базе данных (физическое проектирование БД).

После проведения этапа даталогического проектирования должны быть получены следующие результирующие документы:

· Построение корректной схемы данных ориентируясь на реляционную модель данных.

· Описание схемы БД в терминах выбранной СУБД.

· Описание внешних моделей в терминах выбранной СУБД.

· Описание декларативных правил поддержки целостности БД.

· Разработка процедур поддержки семантической целостности БД.

Итак, задача проектирования реляционной БД состоит в выборе схемы базы из множества альтернативных вариантов.

Корректной называется схема БД, в которой отсутствуют нежелательные зависимости между атрибутами отношений. Процесс разработки корректной схемы БД называется логическим проектированием .

Проектирование схемы БД можно выполнить двумя методами:

· Метод декомпозиции (разбиения) – исходное множество отношений, входящих в схему БД заменяется другим множеством отношений, являющихся проекциями исходных отношений! При этом число отношений возрастает.

· Метод синтеза – компоновка схемы БД из заданных исходных элементарных зависимостей между объектами предметной области.

Классическое проектирование БД связано с теорией нормализацией , которая основана на анализе функциональных зависимостей между атрибутами отношений. Функциональные зависимости определяют устойчивые отношения между объектами и их свойствами в рассматриваемой предметной области.

Метод декомпозиции представляет собой процесс последовательной нормализации схем отношений: каждая новая итерация соответствует нормальной форме более высокого порядка и обладает лучшими свойствами по сравнению с предыдущей. Т.о., изначально предполагается существование универсального отношения, содержащего все атрибуты БД, затем на основе анализа связей между атрибутами осуществляется (или – делается попытка осуществить) декомпозиция универсального отношения, т.е. переход к нескольким отношениям меньшей размерности, причем исходное отношение должно восстанавливаться с помощью операции естественного соединения.

Итак, каждой нормальной форме соответствует некоторый определенный набор ограничений, и отношений находится в некоторой нормальной форме, если удовлетворяет свойственному ей набору ограничений.

В теории реляционных БД обычно выделяют следующие нормальные формы:

первая нормальная форма (1 NF );

· вторая нормальная форма (2 NF );

· третья нормальная форма (3 NF );

· нормальная форма Байса-Кодда (BCNF );

· четвертая нормальная форма (4 NF );

· пятая нормальная форма или форма проекции - соединения (5 NF или PYNF ).

Основные свойства нормальных форм:

· каждая следующая нормальная форма в некотором смысле лучше предыдущей;

· при переходе к следующей нормальной форме свойства предыдущих нормальных свойств сохраняются.

Схемы БД называются эквивалентными , если содержание исходной БД можно получить естественным соединением отношений, входящих в результирующую схему, и при этом не появляется новых кортежей в исходной БД.

7. Нормальные формы отношений.

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

· Аномалии вставки (INSERT) – хранение в одном отношении разнородной информации.

· Аномалии обновления (UPDATE) –избыточность данных отношения из-за хранения разнородной.

· Аномалии удаления (DELETE) – хранение разнородной информации в одном отношении.

Следует учитывать также возникающие неопределенные ( NULL ) значения . В разных СУБД при выполнении различных операций (сравнение, объединение, сортировка, группировка и др.) два NULL -значения могут быть или не быть равными друг другу, по разному влиять на результат выполнения операций по определению средних значений и нахождения количества значений. Для исключения ошибок во многих СУБД существует возможность замены NULL -значения нулем при выполнении расчетов, объявление всех NULL -значений равными друг другу и т.п.

Нормализация – разбиение таблицы на несколько, которые обладают лучшими свойствами при обновлении, вставке и удалении данных. Т.е. нормализация представляет собой процесс последовательной замены таблицы ее полными декомпозициями до тех пор, пока все они не будут находиться в 5НФ, однако, на практике достаточно привести таблицы к НФБК.

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

Если заменить на время нормализации коды первичных (внешних) ключей, то следует рассмотреть 2 случая:

1. Таблица имеет составной первичный ключ, например и поле , которое функционально зависит от части этого ключа, например, от (от полного ключа не зависит). Рекомендуется сформировать другую таблицу, содержащую и ( – первичный ключ), и удалить из первоначальной таблицы:

Заменить , первичный ключ , ФЗ

на , первичный ключ

и , первичный ключ .

2. Таблица имеет первичный (возможный) ключ , поле , которое не является возможным ключом, но функционально зависит от , а также – другое неключевое поле , функционально зависящее от : . Рекомендуется сформировать таблицу содержащую и ( - первичный ключ), и – удалить из первоначальной таблицы: Следует заметить, что для проведения таких операций первоначально следует иметь, в качестве входных данных некоторые «большие» (универсальные) отношения.

Опр.1. Отношение находится в первой нормальной форме (1НФ) тогда и только тогда, когда ни одна из его строк не содержит в любом своем поле одного значения и ни одного из ключевых полей отношения не пусто.

По опр.1, любое отношение будет находиться в 1НФ, т.е. отношение, удовлетворяющее свойствам отношений: в отношении нет одинаковых кортежей; кортежи не упорядочены; атрибуты не упорядочены и различаются по наименованию; все значения атрибутов атомарны.

Опр.2. Отношение находится во второй нормальной форме (2НФ) тогда и только тогда, когда отношение находится в 1НФ и нет неключевых атрибутов, зависящих от части сложного ключа (т.е. все поля, не входящие в первичный ключ, связаны полной функциональной зависимостью с первичным ключом).

Если потенциальный ключ является простым, то отношение автоматически находится в 2НФ.

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

Атрибуты отношения называются взаимно-независимыми , если ни один из них не является функционально зависимым от другого.

Опр.3. Отношение находится в третьей нормальной форме (3НФ) тогда и только тогда, когда отношение находятся в 2НФ и все неключевые атрибуты взаимно независимы (т.е. ни одно из неключевые полей отношения не зависит функционально от любого другого неключевого поля).

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

При приведении отношений при помощи алгоритма нормализации к отношениям в 3НФ предполагается, что все отношения содержат один потенциальный ключ. Это не всегда верно. Бывают случаи, когда отношение может содержать несколько ключей.

Опр.4. Отношение находится в нормальной форме Байса-Кодда (НФБК) тогда и только тогда, когда детерминанты всех функциональных зависимостей являются потенциальными ключами (либо - если любая функциональная зависимость между его палями сводится к полной функциональной зависимости от возможного ключа).

Если отношение находится в НФБК, то оно автоматически находится в 3НФ, что следует из определения 4. Чтобы устранить зависимость от детерминантов, не являющихся потенциальными ключами, следует провести декомпозицию, вынося эти детерминанты и зависимые от них части в отдельное отношение.

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

Опр.5. Отношение находится в четвертой нормальной форме (4НФ) тогда и только тогда, когда отношение находится в НФБК и не содержит нетривиальных многозначных зависимостей.

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

Для устранения нетривиальных многозначных зависимостей можно декомпозировать исходное отношение на несколько новых.

Опр.6. Отношение находится в пятой нормальной форме (5НФ) тогда и только тогда, когда любая имеющаяся зависимость соединения является тривиальной.

Опр.6. тождественно также следует определению.

Опр.7. Отношение не находится в 5НФ, если в отношении найдется нетривиальная зависимость соединения.

Т.о. если в каждой полной декомпозиции все проекции исходного отношения содержат возможный ключ, можно сделать вывод о том, что отношение находится в 5НФ. Отношение, не имеющее ни одной полной декомпозиции также находится в 5НФ.

Не зная ничего о том, какие потенциальные ключи имеются в отношении и как взаимосвязаны атрибуты, нельзя утверждать, что данное отношение находится в 5НФ или в других нормальных формах.

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

Взаимно-независимые атрибуты – это атрибуты, не зависящие один от другого. Если в отношение существует несколько ФЗ, то каждый атрибут или набор атрибутов, от которого зависит другой атрибут, называется детерминантом отношения.

9. Реляционная алгебра.

Реляционная алгебра представляет собой основу доступа к реляционным данным. Основная цель алгебры – обеспечить запись выражений. Выражения могут использоваться для:

· определения области выборки , т.е. определения данных для их выбора, как результата операции выборки;

· определения области обновления , т.е. определения данных для их вставки, изменения или удаления, как результата операции обновления;

· определение (именованных) виртуальных отношений , т.е. представление данных для их визуализации через представления;

· определение снимка, т.е. определение данных для сохранения в виде «мгновенного снимка» отношения;

· определение правил безопасности, т.е. определение данных, для которых осуществляется контроль доступа;

· определение требований устойчивости, т.е. определение данных, которые входят в область для некоторых операций управления одновременным доступом;

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

В реализациях конкретных реляционных СУБД сейчас не используется в чистом виде ни реляционная алгебра, ни реляционное исчисление. Фактическим стандартом доступа к реляционным данным стал язык SQL (Structured Query Language).

Реляционная алгебра, определенная Коддом состоит из 8 операторов, составляющих 2 группы:

традиционные операции над множествами (объединение, пересечение, вычитание, декартово произведение);
специальные реляционные операции (выборка, проекция, соединение, деление).

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

Краткий обзор операторов реляционной алгебры.

Выборка – возвращает отношение, которое содержит все кортежи определенного отношения, удовлетворяющие некоторым условиям. Операция выборки называется также операцией ограничения (restrict - ограничение, сейчас чаще принимается выборка - SELECT ).

Проекция – возвращает отношение, содержащее все кортежи (т.е. - под кортежи) определенного отношения после исключения из него некоторых атрибутов.

Произведение – возвращает отношение, содержащее всевозможные кортежи, которые являются сочетанием двух кортежей, принадлежащих соответственно двум определенным отношениям.

Объединение – возвращает отношение, содержащее все кортежи, которые принадлежат или одному из двух определенных отношений, или обоим.

Пересечение – возвращает отношение, содержащее все кортежи, которые принадлежат одновременно двум определенным отношениям.

Вычитание – возвращает отношение, содержащее все кортежи, которые принадлежат первому из двух определенных отношений и не принадлежат второму.

Соединение (естественное) – возвращает отношение, кортежи которого - это сочетание двух кортежей (принадлежащих соответственно двум определенным отношениям), имеющих общее значение для одного или нескольких общих атрибутов этих двух отношений (и такие общие значения в результирующем кортеже появляются только один раз, а не дважды).

Деление – для двух отношений, бинарного и унарного, возвращает отношение, содержащее все значения одного атрибута бинарного отношения, которые соответствуют (в другом атрибуте) всем значениям в унарном отношении.

ЛИТЕРАТУРА

1. Дейт К.Дж. Введение в системы баз данных, 6-е издание: Пер. с англ. – К.; М.; СПб.: Издательский дом «Вильямс», 2000. – 848 с.

2. Конноли Т., Бегг К., Страчан А. Базы данных: проектирование, реализация и сопровождение. Теория и практика, 2-е изд.: Пер. с англ. – М.: Издательский дом «Вильямс», 2000. – 1120 с.

3. Карпова Т.С. Базы данных: модели, разработка, реализация. – СПб.: Питер, 2001. – 304 с.

4. Фаронов В.В., Шумаков П.В. Delphi 4. Руководство разработчика баз данных. – М.: «Нолидж», 1999. – 560 с.

5. Дж. Грофф, П.Вайнберг. SQL: Полное руководство: Пер. с англ. – К.: Издательская группа BHV, 2001. – 816 с.

6. Кен Гетц, Пол Литвин, Майк Гилберт. Access 2000. Руководство разработчика. Т.1, 2. Пер. с англ. – К.: Издательская группа BHV, 2000. – 1264 с, 912 c.

7. Маклаков С.В BPwin и EPwin. CASE-средства разработки информационных систем. – М.: ДИАЛОГ-МИФИ, 2001. – 304 с.

8. Ульман Д., Уидом Д. Введение в системы баз данных / Пер. с англ. – М.: «Лори», 2000. – 374 с.

9. Хомоненко А.Д., Цыганков В.М., Мальцев М.Г. Базы данных: Учебник для высших учебных заведений / Под ред. Проф. А.Д.Хомоненко. – Спб.: КОРОНА принт, 2000. – 416 с.