Концептуальное проектирование базы данных

СПИСОК ЛІТЕРАТУРИ

ПОСЛІДОВНИК

Стратегія конкурентного поводження послідовника полягає в тому, що він не намагається атакувати лідера, однак чітко охороняє свою частку ринку. Послідовник намагається утримувати своїх клієнтів, хоча і не відмовляється від одержання своєї частки на ринках, які створилися знову. Важливою рисою ведення бізнесу такої фірми є те, що вона досить високоприбуткова й у своїй ринковій стратегії зосереджує уваги на прибутку. Це веде її вбік від інтенсивної конкурентної боротьби.

ФІРМИ, ЯКІ ЗНАЮТЬ СВОЄ МІСЦЕ НА РИНКУ

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

Контрольні запитання

1. Використання концепції ланцюга цінностей для вироблення конкурентних стратегій.

2. Види конкурентних стратегій.

3. Позиція підприємства в конкурентному середовищі.

1.Герасимчук В. Г. Стратегічне управління підприємством. Навч.посібник.-К.:КНЕУ,2000

2.Гудзинський О. Д. Практикум з менеджменту в системі агробізнесу: ситуації і ділові ігри. –К.: Урожай, 1994.

3.Куденко Н. В.Стратегічний маркетинг: Навч. посібник.-К.:КНЕУ,1998.

4. Немцом В.Д. Довгань Л.Є.Стратегічний менеджмент: Навч. посібник.-К.: ТОВ “УВПК “Ексоб”,2001

5. Немцом В.Д. Довгань Л.Є. Менеджмент організацій: Навч. посібник. – К.:ТОВ “УВПК “Ексоб”,2001

6.Тарнавська Н.П., Пушкар Р.М. Менеджмент: Теорія та практика: Підручник для вузів. – Тернопіль: Карт-бланки, 1997.

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

Этап 1.1. Определение типов сущностей.

Этап 1.2. Определение типов связей.

Этап 1.3. Определение атрибутов и связывание их с типами сущно­стей и связей.

Этап 1.4. Определение доменов атрибутов.

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

Этап 1.6. Специализация или генерализация типов сущностей (необя­зательный этап).

Этап 1.7. Создание диаграммы "сущность-связь".

Этап 1.8. Обсуждение локальных концептуальных моделей данных с конечными пользователями.

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

Этап 2. Построение и проверка локальной логической модели данных на ос­нове представления о предметной области каждого из типов пользователей.

Этап 2.1. Преобразование локальной концептуальной модели данных

в локальную логическую модель.

Этап 2.2. Определение набора отношений исходя из структуры ло­кальной логической модели данных.

Этап 2.3. Проверка модели с помощью правил нормализации. Этап 2.4. Проверка модели в отношении транзакций пользователей. Этап 2.5. Создание диаграмм "сущность-связь". Этап 2.6. Определение требований поддержки целостности данных.

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

Этап 3. Создание и проверка глобальной логической модели данных.

Этап 3.1. Слияние локальных логических моделей данных в единую глобальную модель данных.

Этап 3.2. Проверка глобальной логической модели данных. Этап 3.3. Проверка возможностей расширения модели в будущем.

Этап 3.4. Создание окончательного варианта диаграммы "сущность-связь".

Этап 3.5. Обсуждение глобальной логической модели данных с поль­зователями.

Физическое проектирование базы данных (с использованием реляционной СУБД)

Этап 4. Перенос глобальной логической модели данных в среду целевой СУБД.

Этап 4.1. Проектирование основных таблиц в среде целевой СУБД.

Этап 4.2. Реализация бизнес-правил предприятия в среде целевой СУБД. Этап 5. Проектирование физического представления базы данных.

Этап 5.1. Анализ транзакций.

Этап 5.2. Выбор файловой структуры.

Этап 5.3. Определение вторичных индексов.

Этап 5.4. Анализ необходимости введения контролируемой избыточ­ности данных.

Этап 5.5. Определение требований к дисковой памяти. Этап 6. ^Разработка механизмов защиты.

Этап 6.1. Разработка пользовательских представлений (видов).

Этап 6.2. Определение прав доступа. Этап 7. Организация мониторинга и настройка функционирования системы.

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

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

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

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

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

В данном разделе вашему вниманию предлагается поэтапное руководство по кон­цептуальному проектированию баз данных.

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

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

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

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

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

• типы сущностей;

• типы связей;

• атрибуты;

• домены атрибутов;

• потенциальные ключи;

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

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

• Этап 1.1. Определение типов сущностей.

• Этап 1.2. Определение типов связей.

• Этап 1.3. Определение атрибутов и связывание их с типами сущностей и связей.

• Этап 1.4. Определение доменов атрибутов.

• Этап 1.5. Определение атрибутов, являющихся потенциальными и первичными ключами.

• Этап 1.6. Специализация или генерализация типов сущностей (необяза­тельный этап).

• Этап 1.7. Создание диаграммы "сущность-связь".

• Этап 1.8. Обсуждение локальных концептуальных моделей данных с поль­зователями.

Этап 1.1. Определение типов сущностей

Цель Определение основных типов сущностей, присутствующих в представле­нии данного пользователя о предметной области приложения.

Первый этап в построении локальной концептуальной модели данных состоит в определении основных объектов, которые могут интересовать пользователя. Эти объ­екты являются типами сущностей, входящих в модель (см. раздел 5.1.1). Один из методов идентификации сущностей состоит в изучении спецификаций по выполне­нию конкретных функций пользователя на данном предприятии. Из этих специфи­каций следует извлечь все используемые в них существительные или Сочетания су­ществительного и прилагательного (например, "личный номер", "фамилия работни­ка", "номер объекта недвижимости", "адрес объекта недвижимости", "арендная плата", "количество комнат"). Затем среди них выбираются самые крупные объекты (люди, города) или представляющие интерес концепции и исключаются все сущест­вительные, которые просто определяют другие объекты. Например, свойства "личный номер" и "фамилия работника" могут быть объединены в сводном объекте под названием "работник", тогда как свойства "номер объекта недвижимости", "адрес объекта недвижимости", "арендная плата" и "количество комнат" можно объ­единить в сущности под названием "объект недвижимости".

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

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

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

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

Дата добавления: 2014-01-04