|
|
Проектирование информационной системы средствами CASE – технологий.2.2 Разработка концептуальной модели информационной системы.
обработки. Проектирование концептуальной модели основано на анализе задач, стоящих перед рекламным агентством. Концептуальная модель включает описания объектов и их взаимосвязей, представляющих интерес в рассматриваемой предметной области и выявляемых в результате анализа данных. Чтобы построить необходимую нам модель, мы привели все имеющиеся данные к третьей нормальной форме, в результате чего получили следующие сущности: · Блюда. · Виды блюд. · Персонал. · Должности. · Постоянные клиенты. · Заказы. Модель строим на логическом уровне (см. рис. 2). Из рисунка 2 видно, что в модели проставлены связи. Рассмотрим их подробнее: - Таблица «Виды блюд» и таблица «Блюда» - установлена связь «один-ко-многим» при помощи первичного ключа «Код вида»; - Таблица «Должности» и таблица «Персонал» - установлена связь «один-ко-многим» при помощи первичного ключа «Код должности»; - Таблица «Блюда» и таблица «Заказы» - установлена связь «один-ко-многим» при помощи первичного ключа «Код блюда»; - Таблица «Персонал» и таблица «Заказы» - установлена связь «один-ко-многим» при помощи первичного ключа «Код работника»; - Таблица «Постоянные клиенты» и таблица «Заказы» - установлена связь «один-ко-многим» при помощи первичного ключа «Код клиента».
Рис. 2. Концептуальная модель данных
Базы данных и программные средства их создания и ведения (СУБД) имеют многоуровневую архитектуру, представление о которой можно получить из рисунка 1.
Схема 1 - Многоуровневое представление данных БД под управлением СУБД
Различают концептуальный, внутренний и внешний уровни представления этих баз данных, которым соответствуют модели аналогичного назначения. Концептуальный уровень соответствует логическому аспекту представления данных предметной области в интегрированном виде. Концептуальная модель состоит из множества экземпляров различных типов данных, структурированных в соответствии с требованиями СУБД к логической структуре базы данных. Внутренний уровень отображает требуемую организацию данных в среде хранения и соответствует физическому аспекту представления данных. Внутренняя модель состоит из отдельных экземпляров записей, физически хранимых во внешних носителях. Внешний уровень поддерживает частные представления данных, требуемые конкретным пользователям. Внешняя модель является подмножеством концептуальной модели. Возможно пересечение внешних моделей по данным. Частная логическая структура данных для отдельного приложения (задачи) или пользователя соответствует внешней модели или подсхеме БД. С помощью внешних моделей поддерживается санкционированный доступ к данным БД приложений (ограничен состав и структура данных концептуальной модели БД, доступных в приложении, а так же заданы допустимые режимы обработки этих данных: ввод, редактирование, удаление, поиск). Проектирование базы данных состоит в построении комплекса взаимосвязанных данных. На рисунке 2 условно отображены этапы процесса проектирования базы данных.
Схема 2 - Этапы процесса проектирования базы данных Важнейшим этапом проектирования базы данных является разработка информационно-логической (инфологической) модели предметной области, не ориентированной СУБД. В инфологической модели средствами структур данных в интегрированном виде отражают состав и структуру данных, а также информационные потребности. Информационно-логическая (инфологическая) модель предметной области отражает предметную область в виде совокупности информационных объектов и их структурных связей. При связи один ко многим (1:М) одному экземпляру информации А соответствует 0, 1 или более экземпляров объекта В, но каждый экземпляр объекта В связан не более чем с одним экземпляром объекта А. Примером связи 1:М служит связь между информационными объектами Фамилия – Оклад: Фамилия Оклад В базе данных информация хранится в виде двумерных таблиц. Можно так же импортировать и связывать таблицы из других СУБД или систем управления электронными таблицами. Одновременно могут быть открыты 1024 таблицы. При определении необходимых таблиц базы данных необходимо обеспечить первые три нормальные формы, т.е. провести нормализацию. Одни и те же данные могут группироваться в таблицы (отношения) различными способами, т.е. возможна организация различных наборов отношений взаимосвязанных информационных объектов. Группировка атрибутов в отношениях должна быть рациональной, т.е. минимизирующей дублирование данных и упрощающей процедуры их обработки и обновления. Определённый набор отношений обладает лучшими свойствами при включении, модификации, удалении данных, чем все остальные возможные наборы отношений, если он отвечает требованиям нормализации отношений. Нормализация отношений – формальный аппарат ограничений на формирование отношений (таблиц), который позволяет устранить дублирование, обеспечивает непротиворечивость хранимых в базе данных, уменьшает трудозатраты на ведение (ввод, корректировку) базы данных. Е.Коддом выделены три нормальные формы отношений и предложен механизм, позволяющий любое отношение преобразовать к третьей (самой совершенной) нормальной форме. Первая нормальная форма. Отношение называется нормализованным или приведённым к первой нормальной форме, если все его атрибуты простые (далее неделимы). Преобразование отношения к первой нормальной форме может привести к увеличению количества реквизитов (полей) отношения и изменению ключа. Вторая нормальная форма. Чтобы рассмотреть вопрос приведения отношений ко второй нормальной форме, необходимо дать пояснения к таким понятиям, как функциональная зависимость и полная функциональная зависимость. Описательные реквизиты информационного объекта логически связаны с общим для них ключом, эта связь носит характер функциональной зависимости реквизитов. Функциональная зависимость реквизитов – зависимость, при которой в экземпляре информационного объекта определённому значению ключевого реквизита соответствует только одно значение описательного реквизита. Такое определение функциональной зависимости позволяет при анализе всех взаимосвязей реквизитов предметной области выделить самостоятельные информационные объекты. В качестве примера рассмотрим графическое изображение функциональных зависимостей реквизитов работников, приведенное на рисунке 5, на котором ключевой реквизит указан звёздочкой.
Рисунок 1 - Графическое изображение функциональной зависимости реквизитов В случае составного ключа вводится понятие функционально полной зависимости. Функционально полная зависимость не ключевых атрибутов заключается в том, что каждый не ключевой атрибут функционально зависит от ключа, но не находится в функциональной зависимости ни от какой части составного ключа. Отношение будет находиться во второй нормальной форме, если оно находится в первой нормальной форме, и каждый не ключевой атрибут функционально полно зависит от составного ключа. Третья нормальная форма. Понятие третьей нормальной формы основывается на понятии не транзитивной зависимости. Транзитивная зависимость наблюдается в том случае, если один из двух описательных реквизитов зависит от ключа, а другой описательный реквизит зависит от первого описательного реквизита. Отношение будет находиться в третьей нормальной форме, если оно находится во второй нормальной форме, и каждый не ключевой атрибут не транзитивно зависит от первичного ключа. Для устранения транзитивной зависимости описательных реквизитов необходимо провести “расщепление” исходного информационного объекта. В результате расщепления часть реквизитов удаляется из исходного информационного объекта и включается в состав других (возможно, вновь созданных) информационных объектов. Создаваемая база данных должна выполнять функции в интересах автоматизации выдачи данных об организации. Она должна иметь простой и наглядный пользовательский интерфейс, иметь минимальные системные требования. Целью работы является создание базы данных, обеспечивающей: быстрый ввод новых данных; хранения и поиск уже введённых данных; печать необходимого количества персональных отчётов. Данными являются: -фамилия, имя, отчество; -дата рождения; -адрес; -занимаемая должность; -должностной оклад; -количество фактических дней отработанных за месяц. Рассмотрев определенные выше задачи можно спроектировать основные таблицы базы данных. Для этого будем пользоваться средствами Database Desktop В этой среде создадим все необходимые таблицы для разрабатываемой базы данных. Атрибутами в этой таблице будет: Фамилия, Имя, Отчество, Дата принятия, Адрес, Телефон, Смены, Не выходы на работу, Ставка, зарплата.
  ЧТО ПРОИСХОДИТ, КОГДА МЫ ССОРИМСЯ Не понимая различий, существующих между мужчинами и женщинами, очень легко довести дело до ссоры...  Конфликты в семейной жизни. Как это изменить? Редкий брак и взаимоотношения существуют без конфликтов и напряженности. Через это проходят все...  ЧТО ПРОИСХОДИТ ВО ВЗРОСЛОЙ ЖИЗНИ? Если вы все еще «неправильно» связаны с матерью, вы избегаете отделения и независимого взрослого существования...  Система охраняемых территорий в США Изучение особо охраняемых природных территорий(ООПТ) США представляет особый интерес по многим причинам... Не нашли то, что искали? Воспользуйтесь поиском гугл на сайте:
|
