Лекция "Основные этапы разработки БД"

тема 3 вопрос 20 основные этапы разработки бд Основные этапы разработки БД Этап 1. Уточнение задач На первом этапе составляется список всех основных задач, которые в принципе должны решаться этим  приложением, ­ включая и те, которые не нужны сегодня, но могут появиться в будущем. Под  "основными" задачами понимаются функции, которые должны быть представлены в формах или отчетах  приложения. Этап 2. Последовательность выполнения задач Для того, чтобы приложение работало логично и удобно, лучше всего объединить основные задачи в  тематические группы и затем упорядочить задачи каждой группы так, чтобы они располагались в порядке  их выполнения. Может получиться так, что некоторые задачи будут связаны с разными группами или, что  выполнение некоторой задачи должно предшествовать выполнению другой, принадлежащей к иной группе. Этап 3. Анализ данных После формирования списка задач, наиболее важным этапом является составление подробного перечня  всех данных, необходимых для решения каждой задачи. Некоторые данные понадобятся в качестве  исходных и меняться не будут. Другие данные будут проверяться и изменяться в ходе выполнения задачи.  Некоторые элементы данных могут быть удалены или добавлены. И наконец, некоторые данные будут  получены с помощью вычислений: их вывод будет частью задачи, но в базу данных вноситься они не будут. Этап 4. Определение структуры данных После предварительного анализа всех необходимых элементов данных нужно упорядочить их по объектам и соотнести объекты с таблицами и запросами базы данных. Для реляционных баз данных типа Access  используется процесс, называемый нормализацией, в результате которого вырабатывается наиболее  эффективный и гибкий способ хранения данных. Этап 5. Разработка макета приложения и пользовательского интерфейса После задания структуры таблиц приложения, в Microsoft Access легко создать его макет с помощью форм и связать их между собой, используя несложные макросы или процедуры обработки событий.  Предварительный рабочий макет легко продемонстрировать заказчику и получить его одобрение еще до  детальной реализации задач приложения. Этап 6. Создание приложения В случае очень простых задач созданный макет является практически законченным приложением. Однако  довольно часто приходится писать процедуры, позволяющие полностью автоматизировать решение всех  намеченных в проекте задач. Поэтому, понадобится создать специальные связующие формы, которые  обеспечивают переход от одной задачи к другой. Этап 7. Тестирование и усовершенствование После завершения работ по отдельным компонентам приложения необходимо проверить  функционирование приложения в каждом из возможных режимов. Необходимо проверить работу  макросов, для этого использовав пошаговый режим отладки, при котором будет выполняться одна  конкретная макрокоманда. При использовании Visual Basic для приложений в вашем распоряжении  имеются разнообразные средства отладки, позволяющие проверить работу приложения, выявить и  исправить ошибки. По мере разработки автономных разделов приложения желательно передать их заказчику для проверки их  функционирования и получения мнения о необходимости внесения тех или иных изменений. После того  как заказчик ознакомится с работой приложения, у него практически всегда возникают дополнительные  предложения по усовершенствованию, какой бы тщательной не была предварительная проработка проекта. Пользователи часто обнаруживают, что некоторые моменты, о которых в процессе постановки задач, они  говорили как об очень важных и необходимых, на самом деле не играют существенной роли при  практическом использовании приложения. Выявление необходимых изменений на ранних стадиях  разработки приложения позволяет существенно сократить время на последующие переделки. Существуют два подхода при построении БД классический и современный. Архитектура СУБД. СУБД имеет многоуровневую структуру, в которой реализуется принцип  относительной независимости логической и физической организации данных. СУБД имеет два режима работы проектировочный и пользовательский. Рассматривается совокупность процедур проектирования централизованной БД, которые можно  объединить в четыре этапа. Этап формулирования и анализа требований, этап концептуального  проектирования, этап логического проектирования и этап физического проектирования. Основные этапы разработки БД. Разработка БД состоит из следующих этапов: уточнение задач,  последовательность выполнения задач, анализ данных, определение структуры данных, разработка макета  приложения и пользовательского интерфейса, создание приложения и тестирования. Разработка баз данных база данных является одним из основных компонентов любой информационной системы, поэтому при её  проектировании преследуются те же цели, что и при проектировании автоматизированной системы  управления (АСУ) предприятием, а этапы и стадии её создания практически совпадают с работами по  созданию АСУ. При разработке базы данных принято выделять следующие этапы, при помощи которых  осуществляется переход от предметной области к её конкретной реализации:∙ изучение предметной  области;∙ разработка моделей предметной области;∙ разработка логической модели данных;∙ разработка  физической модели данных;∙ разработка собственно базы данных.Изучение предметной области  заключается в выявлении существенных процессов и факторов, оказывающих определяющее влияние на  достижение целей внедрения информационной системы.Модель предметной области – это записанные  знания об объектах реального мира, которыми необходимо управлять наиболее рациональным образом.  Эти знания могут быть представлены как в чисто текстовом виде, так и с использованием методологий  структурного функционального моделирования ­ SADT, IDEF0, IDEF3, методологий и стандартов  описания состава, структуры и взаимосвязей используемой в деятельности предприятия информации –  IDEF1, DFD и соответствующих инструментальных case­средств – BPWin, AIO WIN, ProCap, ProSim,  SmartER.Логическая модель данных описывает понятия предметной области и их взаимосвязи и является  прототипом будущей базы данных. Логическая модель разрабатывается в терминах информационных  понятий, но без какой­либо ориентации на конкретную СУБД. Наиболее широко используемым средством  разработки логических моделей баз данных являются диаграммы «сущность­связь» ­ Entity­Relationship  (ER­диаграммы). Следует заметить, что логическая модель данных, представленная ER­диаграммами, в  принципе, может быть преобразована как в реляционную модель данных, так и в иерархическую, сетевую,  постреляционную.Физическая модель данных строится на базе логической модели и описывает данные уже средствами конкретной СУБД. Отношения, разработанные на стадии логического моделирования,  преобразуются в таблицы, атрибуты в столбцы, домены в типы данных, принятых в выбранной конкретной  СУБД. На этапах логического и физического моделирования, как правило, используется стандарт IDEF1X и case­средства ERWin или SmartER. Указанные инструментальные средства проектирования  поддерживают несколько десятков наиболее популярных СУБД. Результатом физического моделирования является генерация программного кода базы данных на соответствующем выбранной СУБД диалекте  структурированного языка запросов SQL. Несмотря на постоянно совершенствуемые возможности case­средств по автоматической генерации кода  баз данных, детальное её проектирование все­таки остается работой и заботой человека. Case­средства  помогают создать прототип базы данных, на котором строится её рабочая версия. Поскольку практически  любая база данных кроме таблиц содержит дополнительный программный код в виде триггеров и  хранимых процедур, которые пишутся на процедурных расширениях языка SQL или универсальном языке  программирования, то полностью автоматизировать её создание из логической модели пока не  представляется возможным, а может быть и нужным.Хранимые процедуры, основным назначением  которых является реализация бизнес процессов предметной области, – это процедуры и функции,  хранящиеся непосредственно в базе данных в откомпилированном виде, которые могут запускаться  непосредственно пользователем или прикладными программами, работающими с базой данных. Триггеры – это хранимые процедуры, связанные с некоторыми событиями, происходящими во время  работы базы данных. В качестве таких событий обычно выступают операции вставки, обновления и  удаления строк таблиц. Если в базе данных определен некоторый триггер, то он запускается  автоматически всегда при возникновении события. Важным является то, что пользователи не могут  обойти триггер, независимо от того, кто из них и каким образом инициировал запускающее его событие.  Основным назначением триггеров является автоматическая поддержка целостности базы данных, но они  могут использоваться и для реализации достаточно сложных ограничений, накладываемых предметной областью, например, с операцией вставки нового товара в накладную может быть связан триггер, который  проверяет наличие необходимого товара на складе и выполняет другие необходимые действия.