Уровни моделей данных и основные типы поддерживающих их СУБД. Примеры

С т.з. проектирования БД (проектировщик – администратор БД) в рамках этапа анализа проводится подробное словесное описание объектов предметной области и реальных связей, к-ые присутствуют м/у описываемыми объектами. Ядром любой БД является модель дан-х. Модель дан-х предст-т собой мн-во стр-р дан-х, ограничений целостности и операций манипулирования дан-ми. С пом. модели дан-х могут быть представлены объекты предметной области и взаимосвязи м/у ними. 3 уровня моделей дан-х: 1)инфологическая модель дан-х - неформальное описание создаваемой БД, выполненное с использованием естественного языка, матем-ких формул, таблиц, графиков и др. средств, понятных всем людям, работающих над проектированием БД; отражает предметную область в виде совок-ти инф-ых объектов и их стр-рных связей. 2) даталогическая модель дан-х - модель, отражающая логические взаимосвязи м/у элементами дан-х безотносительно их содержания и физ-ой орг-ции. При этом она разрабатывается с учетом конкретной реализации СУБД, также с учетом специфики конкретной предметной области на основе ее инфол-кой модели. 3)физ.модель дан-х – опр-ет способы размещения дан-х в среде хранения и способы доступа к этим дан-м, которые поддерживаются на физическом уровне; описывает данные средствами конкретной СУБД. На рисунке изображены уровни моделей данных.

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

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

Сначала в БД стали испол-ть иерархические даталог-ие модели (Рис.4).

Иерархические СУБД поддерживают древовидную орг-цию инф-ции. Связи м/у записями выражаются в виде отношений предок/потомок, а у каждой записи есть ровно одна родительская запись. Это помогает поддерживать ссылочную целостность. Когда запись удаляется из дерева, все ее потомки также д.б. удалены. Иерархические БД имеют централизованную структуру, т.е. безопасность дан-х легко контролировать. К сожалению, опр-ые знания о физ-ом порядке хранения записей все же необходимы, т.к. отношения предок/потомок реализуются в виде физ-их указателей из одной записи на другую. Т.е. поиск записи осущ-ется методом прямого обхода дерева. Записи, расположенные в одной половине дерева, ищутся быстрее, чем в другой. Типичным представителем явл-ся Information Management System (IMS) фирмы IBM. (1968г.) До сих пор поддерж-ся много БД, что создает проблемы с переходом на новую технологию БД и на новую технику.

Сетевые модели также создавались для мало ресурсных ЭВМ. (Integrated Database Management System (IDMS) компании Cullinet Software, Inc., предназначенная для использования на машинах осн-го класса фирмы IBM под управлением бол-ва ОС).

Сетевая модель расширяет иерарх-ую модель СУБД, позволяя группировать связи м/у записями в мн-ва. С логической т.з. связь — это не сама запись. Связи лишь выражают отношения м/у записями. Как и в иерархической модели, связи ведут от родительской записи к дочерней, но на этот раз поддерживается множественное наследование. Следуя спецификации CODASYL, сетевая модель поддерживает DDL (Data Definition Language — язык определения данных) и DML (Data Manipulation Language — язык обработки данных). Это спец. языки, предназн-ые для опр-ния стр-ры БД и составления запросов. Несмотря на их наличие программист по-прежнему д.знать стр-ру БД. В сетевой модели допускаются отношения «многие ко многим», а записи не зависят друг от друга. При удалении записи удаляются и все ее связи, но не сами связанные записи.

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

В реляц-ой модели БД предст-т собой централизованное хранилище таблиц, обеспечивающее безопасный одновременный доступ к инф-ции со стороны многих польз-лей. В строках таблиц часть полей содержит дан-е, относящиеся непосредственно к записи, а часть — ссылки на записи др. таблиц. Т.о., связи м/у записями явл-тся неотъемлемым св-вом реляционной модели. В реляц-ой модели СУБД достигается инф-ая и стр-рная независ-ть. Записи не связаны м/у собой настолько, чтобы изменение одной из них затронуло остальные, а измененная стр-ра СУБД, БД не обязательно приводит к перекомпиляции работающих с ней приложений. В реляционных СУБД применяется язык SQL, позволяющий формулировать произвольные, нерегламентированные запросы. Это язык четвертого поколения, поэтому любой польз-ль может быстро научиться составлять запросы. К тому же, существует множество приложений, позволяющих строить логические схемы запросов в графическом виде. Все это происходит за счет ужесточения требований к производительности компьютеров. К счастью, современные вычислительные мощности более чем адекватны.

2 важных обстоятельства РМД: 1)модель явл-тся логической, т.е. отн-ия явл-тся логич-ми (абстрактными), а не физ-ми (хранимыми) стр-рами; 2)для реляционных БД верен инф-ый принцип: все инф-ое наполнение БД представлено одним и только одним способом, а именно — явным заданием значений атрибутов в кортежах отношений; в частности, нет никаких указателей (адресов), связывающих одно значение с другим; Достоинства: ●Простота и доступность понимания конечным польз-лем — единственной инф-ой конструкцией явл-тся таблица. ●При проектировании реляц-ой БД применяются строгие правила. ●Полная независимость дан-х. При изменении стр-ры РМД изменения, к-ые требуют произвести в прикладных программах, минимальны. Недостатки: ●Относительно низкая скорость доступа и большой объем внешней памяти. ●Трудность понимания стр-ры дан-х из-за появления большого кол-ва таблиц в рез-те логич-го проектирования. ●Далеко не всегда предметную область можно представить в виде совок-ти таблиц.

3. CALS – технологии. Понятие. Жизненный цикл и этапы проектирования базы данных.

CALS – класс ИТ, направленных на обеспечение безбумажной поддержки ЖЦ продукта (Continuous Acquisition and Life-Cycle Support). Это современный подход к проектированию и производству высокотехнологичной и наукоёмкой продукции, заключающийся в использовании компьютерной техники и современных информационных технологий на всех стадиях жизненного цикла изделия, обеспечивающая единообразные способы управления процессами и взаимодействия всех участников этого цикла: заказчиков продукции, поставщиков/производителей продукции, эксплуатационного и ремонтного персонала, реализованная в соответствии с требованиями системы международных стандартов, регламентирующих правила указанного взаимодействия преимущественно посредством электронного обмена данными. К ключевым областям CALS относят: ●реорганизацию предпринимательской деятельности; ●параллельное проектирование; ●электронный обмен дан-ми; ●интегрированную логистическую поддержку; ●многопольз-кую БД; ●международные стандарты. Ни одну из областей CALS нельзя рассматривать в отрыве от других. ПО орг-ции подключается к CALS-оболочке с пом. стандартного программного интерфейса SDAI (Standard Data Access Interface). Он обесп-ет элементарные операции с дан-ми типа “взять-положить” в соотв-вии с описанием протокола предметной области, производимом на языке EXPRESS. Обеспечив своё подключение через CALS оболочку, орг-ция вступает в мировое инф-ое CALS сообщество, и может взаимод-ть с любым его членом. Применение CALS-технологий позволяет существенно сократить объёмы проектных работ, так как описания многих составных частей оборудования, машин и систем, проектировавшихся ранее, хранятся в унифицированных форматах данных сетевых серверов, доступных любому пользователю технологий CALS. Существенно облегчается решение проблем ремонтопригодности, интеграции продукции в различного рода системы и среды, адаптации к меняющимся условиям эксплуатации, специализации проектных организаций и т. п. Предполагается, что успех на рынке сложной технической продукции будет немыслим вне технологий CALS. CALS-система представляет собой программно-технический комплекс в виде интегрированных ИТ поддержки всех этапов ЖЦ продукции, соответствующих требованиям CALS-стандартов.

В международных стандартах серии ISO 9004 (управление качеством продукции) введено понятие "ЖЦ Изделия" (петля качества). Данное понятие включает в себя след. этапы ЖЦ Изделия: маркетинг, поиск и изучение рынка; проектирование и/или разработка тех. требований к создаваемой продукции; материально-тех-ое снабжение; подготовка и разработка технологических процессов; произв-во; контроль, проведение испытаний и обследований; упаковка и хранение; реализация и/или распределение продукции; монтаж, эксплуатация; тех. помощь в обслуживании; утилизация после завершения использования продукции.

ЖЦ для ПО регламентирует стандарт ISO/IEC 12207. Стр-ра ЖЦ ПО по этому стандарту базируется на трех группах процессов:

−осн. процессы ЖЦ ПО (приобретение, поставка, разработка, эксплуатация, сопровождение);

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

−орг-ые процессы (упр-ие проектами, создание инфрастр-ры проекта, опр-ние, оценка и улучшение самого ЖЦ, обучение).

Основные процессы ЖЦ. (1)Приобретение. Процесс приобретения (как его называют в ГОСТ – “заказа”) определяет работы и задачи заказчика, приобретающего ПО или услуги, связанные с ПО, на основе контрактных отношений. Процесс приобретения состоит из следующих работ: 1)подготовка; 2)подготовка заявки на подряд; 3)подготовка и корректировка договора; 4)надзор за поставщиком; 5)приемка и закрытие договора. (2) Поставка. Процесс поставки, в свою очередь, определяет работы и задачи поставщика. Процесс включает следующие работы: 1)подготовка; 2)подготовка ответа; 3)подготовка договора; 4)планирование; 5)выполнение и контроль; 6)проверка и оценка; 7)поставка и закрытие договора. (3)Разработка. Процесс разработки определяет работы и задачи разработчика. Состоит из следующих работ: 1)подготовка процесса; 2)анализ требований к системе; 3)проект-ие системной архит-ры; 4)ан-з треб-ий к программным средствам; 5)проект-ие программной архитектуры; 6)тех. проект-ие программных средств; 7)программирование и тестирование программных средств; 8)сборка программных средств; 9)квалифик-ые испытания программных средств; 10)сборка системы; 11)квалифик-ые испытания системы; 12)ввод в действие программных средств; 13)обеспечение приемки программных средств. (4)Эксплуатация вкл-ет в себя работы по внедрению компонентов ПО в эксплуатацию, в том числе конфигурирование БД и рабочих мест пользователей, обеспечение эксплуатационной документацией, проведение обучения персонала и т.д., и непосредственно эксплуатацию, в том числе локализацию проблем и устранение причин их возникновения, модификацию ПО в рамках установленного регламента, подготовку предложений по совершенствованию, развитию и модернизации системы. (5)Сопровождение. Процесс разработки определяет работы и задачи, проводимые специалистами службы сопровождения. Процесс включает следующие работы: 1)подготовка процесса; 2)анализ проблем и изменений; 3)внесение изменений; 4) проверка и приемка при сопровождении; 5) перенос; 6) снятие с эксплуатации.

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

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

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

Существующие модели ЖЦ опр-ют порядок исполнения этапов в ходе разработки, а также критерии перехода от этапа к этапу. (1)каскадная модель (70-80г.г.) предполагает переход на следующий этап после полного окончания работ по предыдущему этапу. Каждый этап завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков. Достоинства: 1)на каждом этапе формируется законченный набор проектной документации, отвечающий критериям полноты и согласованности. 2)этапы работ выполняются в логичной последовательности. 3)возможно жесткое планирование сроков завершения работ и соответствующих затрат. Недостатки: 1)существенная задержка с получением конечного результата. 2)несоответствие разработанной системы ожиданиям заказчика. 3)примитивная автоматизация существующих производственных процессов. 4)недостатки разработанной системы: монолитность; централизованность; сложность в использовании. Каскадный подход хорошо зарекомендовал себя при построении ИС, для которых в самом начале разработки можно достаточно точно и полно сформулировать все требования

(2)поэтапная модель с промежуточным контролем. Итерационная модель разработки ИС с циклами обратной связи между этапами (1980-1985 гг.). Достоинство: межэтапные корректировки обеспечивают меньшую трудоемкость по сравнению с каскадной моделью. Недостатки: время жизни каждого из этапов растягивается на весь период разработки.

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

При создании БД ИС наиболее важными являются задачи, связанные с созданием правильной логической структуры дан-х, обеспеч-щей реш-ие всего набора требуемых задач. Процесс разработки БД: (1)Исследование предметной области - необходимо проводить в целом для разрабатываемой системы, частью к-ой явл-тся и БД. Цель - выделение значимых функций для разрабатываемой системы, их согласование, описание в терминах понятных как разработчику, так и будущему польз-лю. На этом этапе важно понять смысловое значение дан-х, обрабатываемых в системе, отделить ключевые понятия предметной области от маловажных и вообще несущ-ных для рассматр-мого случая. Рез-том проведения исследования предметной области должен стать перечень системных требований, спецификаций, бизнес-процессов, инф-ых потоков и их описание. Очень часто для этого применяются стандартные способы описания предметной области с испол-ием моделей DFD, SADT, UML. (2)Создание инфологической модели. Модель предст-т собой описание будущей БД, представленное с пом. естественного языка, формул, графиков, диаграмм, таблиц и других средств, понятных как разработчикам БД, так и обычным польз-лям. Назначение такой модели состоит в адекватном описании процессов, инф-ых потоков, функций системы с помощью общедоступного и понятного языка, что делает возможным привлечение экспертов предметной области, консультантов, польз-лей для обсуждения модели и внесения исправлений. В наст. время одним из наиболее широко распространенных подходов, применяемых при инфол-ом модел-нии, явл-тся подход, осн-ый на применении диаграмм «сущность-связь» (ER – Entity Relationship). (3)Создание даталогической модели. При датал-ом модел-ии испол-тся инфол-ая модель предметной области. При этом осн. задачей датал-го модел-ния явл-тся описание св-в понятий предметной области, их взаимосвязь и ограничения, накладываемые на дан-е. Датал-ая модель явл-тся начальным прототипом создаваемой БД. Датал-ая модель отражает стр-ру БД с учетом особ-тей модели дан-х. Рез-том создания датал-ой модели явл-ся модель, созданная с учетом выбранной модели дан-х, полученная путем преобразования инфол-ой модели с учетом опр-ых правил. (4)Создание физической модели. Это модель, опр-щая размещение дан-х на внешних носителях, методы доступа и технику индексирования. Она так же наз-тся внутр-ей моделью системы. Физ-ая орг-ция БД опр-ет способы размещения дан-х в среде хранения и способы физ-го доступа к этим дан-м.

Дата добавления: 2015-05-09