Учебная работа. Реферат: Проектирование баз данных 2

Учебная работа. Реферат: Проектирование баз данных 2

Содержание:

1.
Введение 2

2.
Проектирование базы данных 4

3.
бизнес-модель процесса проектирования базы данных: сбор и анализ входных данных 9

4.
Бизнес-модель процесса проектирования реляционной базы данных: создание логической модели базы данных 11

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

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

7.
Короткое рассмотрение задач сотворения серверного кода и подготовки скрипта 19

8.
Заключение 23

1. Введение

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

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

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

В эксплуатации база данных и ее свита должны удовлетворять набору требований по ряду укрупненных (встроенных) характеристик, таковых как:

· функциональность и адаптируемость;

· производительность обработки транзакций;

· пропускная способность;

· время реакции;

· сохранность.

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

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

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

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

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

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

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

процесс проектирования базы данных обхватывает несколько главных сфер.

Проектирование объектов базы данных (таблицы, представления, индексы, триггеры, хранимые процедуры, функции, пакеты) для представления данных предметной области в базе данных.

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

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

Проектирование баз данных под предназначение системы (умственный анализ данных, OLAP, OLTP и т.д.).

Понятно, что база данных:

· имеет свою внутреннюю архитектуру;

· имеет свое собственное лингвистическое содержание;

· действует в рамках некой наружной среды;

· имеет свои средства взаимодействия с наружной средой;

· работает на определенной программно-аппаратной платформе;

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

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

Типовая бизнес-модель процесса проектирования базы данных

процесс проектирования базы данных быть может представлен в виде модели бизнес-процессов. Бизнес-модель процесса проектирования дозволяет:

· показать личное Мировоззрение проектировщика баз данных на процесс проектирования определенной базы данных;

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

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

· просчитать продолжительность проектных работ (сделать временную модель проектирования).

Разглядим типовую бизнес-модель процесса проектирования базы данных. На рис. 3.1 приведена контекстная диаграмма процесса проектирования базы данных.

Рис. 3.1. Контекстная диаграмма процесса проектирования базы данных

Как видно из рисунка, на вход процесса проектирования базы данных подаются:

· информационная модель предметной области базы данных: диаграммы «сущность-связь» (ER-диаграммы);

· многофункциональная модель предметной области базы данных: бизнес-модель действий, диаграммы потока данных (DF-диаграммы), диаграммы состояний, — диаграммы актуальных циклов сущностей, спецификации на системы (требования), бизнес-правила;

· общесистемные требования и ограничения;

· задачки оборотного воздействия.

Могут быть представлены и остальные документы.

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

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

· физическая база данных;

· спецификация модулей приложений базы данных;

· план тестирования базы данных.

По просьбе быть может разработана и иная документация.

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

Рис. 3.2

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

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

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

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

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

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

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

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

3. бизнес-модель процесса проектирования базы данных: сбор и анализ входных данных

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

Рис. 3.3. Диаграмма декомпозициии процесса проектирования базы данных: 2-ой уровень. Сбор и анализ входных данных

Таковыми задачками являются:

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

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

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

· подготовка плана проектирования базы данных.

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

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

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

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

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

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

· нормализация сущностей предметной области:

· получить перечень атрибутов сути;

· найти многофункциональные зависимости (ФЗ) в сути;

· найти детерминанты сути;

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

· выполнить нормализацию сути (конвертировать суть в отношение);

· для приобретенного дела назначить первичные ключи;

· сформировать перечень кандидатов на наружные ключи, если нужно;

· сформировать бизнес-правила поддержки целостности сути, если нужно;

· нормализация отношений логической модели базы данных:

· найти степень связи сущностей;

· найти класс принадлежности сути к связи;

· восстановить отношение (разрешить связи);

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

· найти атрибуты связывающих отношений, если нужно;

· сформировать бизнес-правила поддержки целостности связей;

· проверка корректности логической модели реляционной базы данных:

· проверка отношений на соответствие обычной форме Бойса-Кодда;

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

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

· проверка на отсутствие незамкнутых связей;

· проверка на отсутствие одиночных отношений;

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

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

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

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

·

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

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

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

Рис. 3.5. бизнес-модель процесса нормализации сути

Рис. 3.6. бизнес-модель процесса нормализации дела

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

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

Организационная сторона решения проф задачки проектировщика баз данных — задачка сотворения физической модели реляционной базы данных. Основная цель решения данной задачки: конвертировать логическую модель реляционной базы данных в последовательность установок SQL для сотворения объектов реляционной базы данных. Таковым образом, проектировщик базы данных показывает дела логической модели реляционной базы данных (сути предметной области, выставленные в нормализованной форме на ER-диаграммах) в таблицы и индексы реляционной базы данных.

Эта задачка включает выполнение ряда неотклонимых поочередных процедур.

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

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

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

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

· найти ряд характеристик, связанных с нравом хранения таблицы в физической базе данных;

· найти ограничения на значения колонок, исходя из ряда бизнес-правил.

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

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

· идентифицировать первичные ключи каждой таблицы;

· выстроить индексы первичного ключа;

· найти наружные ключи в дочерних таблицах, если нужно;

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

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

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

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

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

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

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

· исходя из требований к способности всех транзакций к базе данных;

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

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

· для каждой критичной транзакции нужно оценить кардинальность каждой колонки, задействованной в транзакции и, по способности, кардинальность подборки;

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

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

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

7. Короткое рассмотрение задач сотворения серверного кода и подготовки скрипта

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

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

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

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

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

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

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

PL/SQL является таковым расширением SQL в СУБД Oracle 9i. Он дозволяет создавать серверный код в виде объектов реляционной базы данных, таковых, как хранимые процедуры, функции, пакеты и триггеры. Проектировщик реляционной базы данных, который употребляет для сотворения базы данных СУБД Oracle, имеет возможность разглядеть сотворения таковых объектов с целью сокращения сетевого трафика либо принять решение о переносе определенного размера обработки на , в особенности в тех вариантах, когда эта обработка производится весьма активно. к примеру, несколько строк различных таблиц проверяются перед вставкой новейшей строчки.

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

· принятие решения и создание хранимых процедур;

· принятие решения и создание функций;

· принятие решения и создание пакетов;

· принятие решения и создание триггеров.

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

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

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

требования по обеспечению возможных юзеров к базе данных и ее объектам, так именуемые требования сохранности базы данных;

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

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

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

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

· привязка разработанных объектов реляционной базы данных к характеристикам физического хранения базы данных при помощи сотворения особых объектов базы данных;

· создание инсталляционного скрипта;

· документирование базы данных.

Заключение.

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

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

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

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

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

Применена литература:

1. Корнеев В.В., Гараев А.Ф., Васютин С.И., Райх В.В

Базы данных. Умственная обработка инфы

М.: Нолидж, 2000

2. Туманов В.Е.

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

БИНОМ. Лаборатория познаний, веб-университет информационных технологий — ИНТУИТ.ру, 2007

]]>