технология проектирования ИС. Реферат на тему _Технологии проектирования ИС_. Лекция Технологии проектирования ис 1 Основные определения
 Скачать 0.49 Mb.
|
|
Определение атрибутов для каждой таблицы. Эта работа, как и создание E-R-диаграмм, делается с помощью специалистов фирмы, знающих особенности циркулирующей в ней информации и потребности пользователей. Можно перечислить некоторые правила при определении атрибутов. Назначение первичных ключей каждой таблице. Одним или двумя атрибутами в каждой таблице должны быть представлены первичные ключи. Для этого чаще всего используются цифровые ключи, например, номер счета, табельный номер работника, код товара, номер счет-фактуры и т.д. Обычно первичный ключ таблицы - это один из ее атрибутов. Однако для таблиц, представляющих отношения (*:*), он всегда состоит из двух атрибутов, которые представляют первичные ключи связанных этим отношением таблиц. Такой многоатрибутный ключ называется составным ключом. Например, первичный ключ таблицы "продажи-товары" будет состоять из атрибутов “номер счет-фактуры” (первичный ключ таблицы продаж) и “код товара” (первичный ключ таблицы товаров). Столбцы первичных ключей в таблицах 5.8 - 5.16. обозначены серым цветом. Назначение таблицам неключевых атрибутов. Некоторые атрибуты (например дата и сумма продажи) нужны для правильной обработки данных и требуются для отчетности. Другие атрибуты приписываются сущностям, чтобы обеспечить информацию для более эффективного управления ресурсами организации (например, табельный номер работника нужен не только чтобы начислять комиссионные, но и чтобы оценивать работу служащих). Каждый атрибут в таблице должен характеризовать первичный ключ или быть внешним ключом. Это правило уже обсуждалось, когда мы вводили понятия первичного и внешнего ключей при определении ограничений на структуру таблиц. Здесь оно означает, что вся информация, не описывающая непосредственно данную сущность, относится к другой сущности и находится в другой таблице, а внешний ключ обеспечивает ссылку на эту информацию. Например, в таблице платежей каждый платеж будет иметь атрибуты, описывающие его и только его - это номер (первичный ключ), дата, сумма платежа, но вместо указания плательщика, кассира и атрибутов счета в банке будут присутствовать внешние ключи - код клиента, табельный номер кассира и внутренний номер счета. Обратившись по этим ключам в соответствующие таблицы, всегда можно узнать, например, имя клиента и кассира, описание счета. По сути выполнение этого правила обеспечивает отсутствие избыточности в БД. В самом деле, если бы вместо кода клиента в таблице платежей присутствовало бы его описание, то фамилия Первушина, его адрес и кредитный лимит повторились бы два раза, поскольку он сделал две покупки. Реализация отношений (1:*). К этому этапу реляционная база данных полностью моделирует только отношения (*:*). Отношения (1:*) моделируются с помощью внешнего ключа. Для этого первичный ключ сущности, которая встречается в отношении один раз, используется как внешний ключ сущности множественной сущности. В нашем примере в табл.5.8. - 5.16 все внешние ключи предназначены для моделирования отношений (1:*). Убедитесь в этом, сопоставив набор таблиц 5.8. - 5.16. с E-R диаграммой на рисунке 5.4. Это произошло потому, что на диаграмме нет отношений (1:1). Реализация отношений (1:1). Отношения (1:1) между сущностями моделируются с помощью вставки в одну из связанных таблиц внешнего ключа, который служит первичным ключом другой таблицы. В принципе, вставлять внешний ключ можно в любую из таблиц, но если мы имеем дело с отношением (1:1) между двумя событиями, то внешний ключ вставляется в таблицу более позднего события. Итак, мы разобрали основные этапы моделирования данных с помощью реляционных баз данных. Знание основ этой работы необходимо экспертам организации, которые будут принимать участие в создании ИС в качестве консультантов и даже просто пользователей. 5.4. Разработка баз данных Разработка базы данных - поэтапный процесс, в котором можно выделить 6 стадий (рис.5.5.). Экспертам предприятия приходится участвовать в этом процессе почти на всех его стадиях. Планирование. Первая стадия - начальное планирование для определения потребностей и возможностей разработки новой системы. Цель - определить, является ли предлагаемая система технологически и экономически возможной. Если это так, то начинается новая стадия.  Рис. 5.5. Стадии разработки базы данных Определение требований включает определение области применения предлагаемой базы данных, основных требований к программному и аппаратному обеспечению, а также потребностей пользователей. Область применения определяется в консультациях с руководством предприятия и отражает информационные потребности организации, ее стратегические цели и задачи. После этого собирается информация о таких факторах, как число пользователей и ожидаемый объем операций, которые используются для определения основных требований к программному и аппаратному обеспечению новой системы. Данные о потребностях пользователей собираются различными методами, например, с помощью интервью или анкетирования. Эти данные используются для предварительного определения отдельных представлений пользователей (внешних подсхем), которые бы отражали как требования обработки операций, так и требования процесса принятия решений. При разработке базы данных приходится принимать во внимание несколько требований. Полнота. БД должна содержать все данные и отношения, нужные различным пользователям. Интересы пользователей и источников данных должны быть скоординированы. Адекватность. Собираться и храниться должны только полезные и относящиеся к делу данные. Актуальность. Хранимые данные должны постоянно обновляться, чтобы отразить текущее состояние дел. Точность. В БД не должно быть ошибок и неточностей. Доступность. Хранимые данные должны быть доступны для всех легальных пользователей в нужное им время. Эффективность. На хранение данных должно тратиться не очень много ресурсов, а время обновления, извлечения данных и эксплуатация БД должно быть приемлемым. Безопасность. БД должна быть защищена от потери данных, разрушения и несанкционированного доступа. Гибкость. Возможные изменения в жизни организации не должны приводить к полной замене БД. К сожалению, не всегда возможно добиться наилучших результатов по всем этим требованиям. Во многих случаях приходится идти на компромисс. Например, экономичность часто находится в противоречии с гибкостью и доступностью БД. Поэтому при разработке БД пытаются достичь возможного баланса между целями. Логическое проектирование. На этом этапе завершается разработка внешних схем БД. Требования различных пользователей и прикладных программ переводятся на язык концептуальной схемы, используя REA-модель и E-R-диаграммы. Часто на этом этапе выделяются подсистемы будущей БД, отвечающие за различные информационные нужды, например, подсистемы продаж, закупок, кадров, производства и т.д. Это делается для удобства разработки и эксплуатации БД. Кроме того, на этом этапе определяются первичные и вторичные ключи, разрабатывается справочник данных. Физическое проектирование состоит в переводе концептуальной разработки в физически существующие структуры хранения данных и работающих с ними программ. Здесь концептуальная схема переводится во внутреннюю, создается справочник данных, определяются способы физического хранения и доступа к БД, в том числе принимаются решения об использовании индексов. Внедрение и эксплуатация. Внедрение состоит в том, чтобы подготовить, инициировать и запустить все процессы, связанные с эксплуатацией базы данных. Это включает преобразование существующих данных в формат файлов новой базы данных, разработку новых прикладных программ и модификацию существующих, обучение пользователей, тестирование работы БД, переход на ее использование. Стадия эксплуатации включает не просто реальное использование БД, но и наблюдение за ее работой и выявлением неудовлетворенности пользователей, чтобы определить, что необходимо усовершенствовать.По различным причинам базы данных “стареют”, и если простой модификации становится недостаточно, то возникает потребность разработки новых принципов работы. На этом жизненный цикл БД начинается сначала. Роль экспертов организации. Эксперты организации должны быть вовлечены во все стадии разработки БД. На стадии планирования они предоставляют информацию для оценки возможностей и участвуют в принятии решения по этому вопросу. На стадии определения требований и логического проектирования они участвуют в определении информационных потребностей пользователей, разработке схем, словаря данных, мер контроля. Во время внедрения - в тестировании БД и прикладных программ. Наконец, при эксплуатации они используют БД и помогают принимать решения по ее управлению. Таблица 5.18 Факторы, исследуемые при инспекции после внедрения.
Последнее событие при разработке системы - утверждение пользователями отчета об инспектировании ИС. С этого момента управление системой передается в руки подразделения, занимающегося обработкой данных. Система начинает свою самостоятельную жизнь. Однако работа над новой системой на этом не завершается. Исследования практики применения ИС говорят, что в период разработки делается только 20-30% работы, остальные 70-80% остаются на долю обслуживания системы. Большая часть затрат на обслуживание - это затраты на модификацию программ и обновление различных компонентов ИС. Это происходит по разным причинам, к которым можно отнести исправление не обнаруженных ранее ошибок, усовершенствования системы, изменения в структуре и деятельности организации, изменения налогового и другого законодательства и т.п. |